越境ビジネスのマルチリージョン災害対策：香港本番＋東京・シンガポール待機系、DBレプリケーションとフェイルオーバー実践

データセンター障害、回線障害、さらには海底ケーブル切断にも耐える越境ビジネスを作る現実的な方法は、マルチリージョン災害対策（DR）です。本番を香港に置き、東京・シンガポール・台北に常時レプリケーションされたウォームスタンバイを用意し、短いTTLのDNSまたはAnycastでトラフィックを切り替えます。IMIDCなら、CN2 GIAの香港サーバー（本番）、日本・台湾・シンガポールのサーバー（待機系）、自社IPブロックのBGP/Anycast広報まで1つのアカウントで揃います。

基本構成：本番1拠点・待機系1拠点・バックアップ保管庫

ポイント：同じ建物の同型サーバー2台より、独立して故障する3拠点のほうが強い。

• 本番（香港）：アプリ、DBプライマリ、ファイルストレージ。CN2 GIAで中国本土ユーザーに近く、ICP届出も不要（ただし内容は合法である必要あり）で、越境EC・SaaSに向いています。
• ウォームスタンバイ（東京・シンガポール・台北）：同一バージョンのソフト、読み取り専用のDBレプリカ、数分ごとのファイル同期、アプリは待機または読み取り専用で稼働。
• バックアップ保管庫（第3の拠点・事業者）：暗号化・世代管理されたresticスナップショット。レプリケーションは誤操作も即座に複製するため、DROP TABLEやランサムウェアから守れるのは時点バックアップだけです。

支払える範囲でRPO/RTOのレベルを決める

ポイント：購入前に「失ってよいデータ量（RPO）」と「止まってよい時間（RTO）」を決めましょう。

数値は実案件での設計目標であり保証ではありません。訓練で実測してください。まずIMIDCの日本VPSでレベル1から始め、売上に応じてレベル2へ移行する例が多くあります。

リージョン間のDBレプリケーション（MySQL／PostgreSQL）

ポイント：リージョン間は非同期かつTLS暗号化。30〜60msの回線で同期コミットにすると全書き込みが遅くなります。

MySQL 8＋GTID

# /etc/mysql/mysql.conf.d/dr.cnf  (Hong Kong primary: server_id=1, Tokyo standby: server_id=2)
[mysqld]
server_id                = 1
log_bin                  = mysql-bin
binlog_format            = ROW
gtid_mode                = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 604800

-- On the Hong Kong primary (203.0.113.10)
CREATE USER 'repl'@'198.51.100.20' IDENTIFIED BY 'change-me' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'198.51.100.20';

-- On the Tokyo standby (198.51.100.20), MySQL 8.0.23+, after loading a consistent dump
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='203.0.113.10', SOURCE_USER='repl', SOURCE_PASSWORD='change-me',
  SOURCE_AUTO_POSITION=1, SOURCE_SSL=1;
START REPLICA;
SET GLOBAL super_read_only = ON;
SHOW REPLICA STATUS\G   -- watch Seconds_Behind_Source

PostgreSQLストリーミングレプリケーション

# Primary (Hong Kong): pg_hba.conf
hostssl  replication  replicator  198.51.100.20/32  scram-sha-256

# Standby (Tokyo): clone the primary and start streaming
sudo systemctl stop postgresql
sudo -u postgres rm -rf /var/lib/postgresql/16/main/*
sudo -u postgres pg_basebackup -h 203.0.113.10 -U replicator \
     -D /var/lib/postgresql/16/main -R -X stream -C -S tokyo_slot -P
sudo systemctl start postgresql

# On the primary: check replication lag
sudo -u postgres psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"

ファイアウォールで3306／5432番は待機系IPのみに許可し、レプリカは読み取り専用に保ち、遅延がRPOを超えたらアラートを出します（例：Seconds_Behind_Sourceが60超、replay_lagが1分超）。

resticとrsyncでファイルと履歴を守る

ポイント：rsyncは待機系を最新に、resticは任意の時点へ戻せる履歴を残します。

# Nightly snapshot of files + DB dumps to a third location
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/hk-app
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init                                   # first run only
mysqldump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz
restic backup /var/www /etc /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%

# Every 5 minutes: mirror user uploads to the Tokyo standby
*/5 * * * * rsync -aH --delete -e "ssh -i /root/.ssh/dr_ed25519" /var/www/uploads/ [email protected]:/var/www/uploads/

rsync --deleteは削除も複製するため、ミラーはバックアップではありません。毎月1つのスナップショットを検証用VPSにリストアし所要時間を記録しましょう。それがレベル0の実際のRTOです。

トラフィック切替：低TTLのDNSか、自社IPブロックのAnycastか

ポイント：DNS切替は安価で簡単。自社/24のAnycastはDNSキャッシュの遅延がない一方、ASNとBGPの知識が必要です。

方式A：DNSフェイルオーバー

; Zone for example.com - keep the failover record on a short TTL
www.example.com.   60   IN  A   203.0.113.10    ; Hong Kong primary
; standby target  ->        198.51.100.20       ; Tokyo warm standby

# Health check from a third location (cron every minute)
#!/bin/sh
if ! curl -fsS --max-time 5 https://www.example.com/healthz >/dev/null; then
  echo "$(date -u) primary check failed" >> /var/log/dr-check.log
  # after 3 consecutive failures: alert on-call, then switch the A record
  # via your DNS provider's API (manual approval recommended)
fi

TTLは少なくとも前日までに60秒へ下げておきます。リゾルバやアプリによっては長くキャッシュするため、旧IPへの通信が数分残ります。DBを先に昇格し、次にDNSを切り替えます。

# PostgreSQL standby -> primary
sudo -u postgres psql -c "SELECT pg_promote();"
# MySQL standby -> primary
mysql -e "STOP REPLICA; RESET REPLICA ALL; SET GLOBAL super_read_only=OFF; SET GLOBAL read_only=OFF;"

方式B：自社IPブロックでAnycast／BGP

自社の/24（またはIMIDCからのリース）とASNがあれば、IMIDCが香港と東京でBGPセッションを用意できます。香港からは通常広報、東京からはAS-path prependを付けて広報し、香港の障害時や経路撤回時には東京へ収束します。クライアントのIPは変わりません。事前に両オリジンのROAを作成してください。

# BIRD 2 on the Tokyo standby: announce your own /24, made less preferred
protocol bgp imidc_tokyo {
  local as 64500;                       # your ASN
  neighbor 198.51.100.1 as 64501;       # session details provided by IMIDC
  ipv4 {
    import none;
    export filter {
      if net = 203.0.113.0/24 then {
        bgp_path.prepend(64500); bgp_path.prepend(64500);
        accept;
      }
      reject;
    };
  };
}
# Failover drill: stop the Hong Kong session  ->  birdc disable imidc_hk

アジアの海底ケーブル障害シナリオ

ポイント：サーバー停止だけでなく経路劣化にも備えること。地震や船の錨、地域的な事案で複数のアジア・アジア欧州間ケーブルが同時に損傷した例があります（2006年の台湾・恒春地震、2024年の紅海ケーブル切断など）。

平常時から両拠点で主要顧客地域へのmtrを取り、正常な経路を把握しておきましょう。

四半期ごとに切替訓練を行う

ポイント：試していない待機系は計画ではなく願望です。

1. メンテナンス時間を告知し、デプロイを凍結。
2. レプリカ遅延がほぼ0であることを確認し、本番への書き込みを停止。
3. 待機系を昇格、DNSまたはBGPを切替え、スモークテスト（ログイン、注文、決済コールバック、管理画面）。
4. 実際のRPO（最終取引の有無）とRTO（復旧までの分数）を記録。
5. 旧本番を新レプリカとして再構築し、同じ手順で切り戻し。
6. 想定外の事項をすべて手順書へ：ハードコードIP、FW許可リスト、決済事業者のIPホワイトリスト、二重実行されたcron。

最適なIMIDC構成の選び方

ポイント：「1時間停止したときの損失」でレベルを選びます。

• 小規模ショップ・ブログ：香港CN2 GIA VPS（月額$18から）＋別のIMIDC拠点へのrestic。
• 成長中のEC・SaaS：香港専用サーバー（月額$139から）＋日本VPS（月額$28から）でレプリカ常時稼働。
• 売上の中核プラットフォーム：香港と東京または台北に同等の専用サーバー、DNS切替、四半期訓練。
• 全拠点で同じIP：自社ASN＋保有またはリースの/24を、IMIDCのBGP/Anycastで2拠点以上から広報。

シンガポール拠点、VPSと専用サーバーの混在構成、既存サーバーの移行が必要な場合は、IMIDC営業がカスタム構成を提案し、無料移行にも対応します。

よくある質問

香港CN2 GIAの本番と東京・シンガポールの待機系をまとめて提供している事業者は？

IMIDCは香港・東京・シンガポール・台北にデータセンターを持ち、本番と待機系を1つのアカウントで契約・サポートできます。香港は中国電信CN2 GIAルートで、シンガポールは営業経由で構成します。

DRにはDNS切替とAnycastのどちらがよいですか？

DNS切替はどのIPでも使え運用も簡単ですが、キャッシュにより切替が1分〜数分遅れます。自社/24のAnycastはIPが変わらずBGPで収束しますが、ASN・ROA・BGPの知識が必要です。IMIDCはBGPセッションとIPv4リースを提供できます。

DBレプリケーションだけでバックアップになりますか？

なりません。削除や破損も数秒で待機系に複製されます。第3の拠点に暗号化・世代管理されたスナップショット（resticなど）を保管し、定期的にリストアを試験してください。

本番と待機系はどれくらい離すべきですか？

電力網・建物・台風の進路を共有しない距離、理想的にはケーブル陸揚げ地点も異なる場所です。香港と東京またはシンガポールの組み合わせが一般的で、決定前にmtrで実際の経路を確認しましょう。

次のステップ

本番には香港専用サーバーまたは香港CN2 GIA VPS、待機系には日本VPSや台湾専用サーバーをご検討ください。自社IPのAnycastはBGP/Anycast、シンガポールやカスタムDR設計はIMIDC営業またはチケットからご相談ください。