3月2日に大阪リージョンがフルリージョン化しました🎉

東京に続き国内2つめのリージョンとなりますが、いったいどっちを利用すれば…と疑問に思う方も多いはずです。そこで先日開催されたAWS Partner Summit 2021でのAWSパートナー向けの解説から、国内複数リージョンの使い分けについてレポートします。

大阪リージョンとは？

そもそもリージョンとは、地理的・ネットワーク的に独立したエリアのことを指します。AWSは世界を複数のリージョンに分け、リージョン単位でクラウドコンピューティングのサービスを提供しています。またAWSが提供するすべてのリージョンは、複数のアベイラビリティーゾーン（Availability Zone: AZ）と呼ばれるデータセンター群を持っています。

リージョンとリージョンの間は完全に分離されており、あるリージョンで障害が発生しても、他のリージョンに影響が及ばないように設計されています。このリージョンの独立性を利用して、片方のリージョンのバックアップとして地理的に離れたリージョンを利用する、といったシステム構成を災害復旧（ディザスターリカバリー： DR）対策として構築する場合があります。地理的に離れているので自然災害や公共電源の喪失の影響を受けにくい一方で、リージョンとの間の距離が遠ければ遠いほど通信遅延が発生します。

リージョン内に設置されている複数のAZもリージョンと同様地理的に独立しています。自然災害や公共電源の喪失などの影響を受けにくく、かつ通信のレイテンシーが遅くなりすぎない距離の範囲にそれぞれ立地しているため（だいたい100km以内と言われています）、万が一どこかのAZで障害が起きても他のAZに影響が出にくい構成となっています。そのため、障害対策や冗長化のために複数のAZを利用する「マルチAZ」という構成を取ることもあります。AZ同士は高速な専用線によって接続されているため、同じリージョン内であれば通信遅延を気にすることなくデータやリソースのやりとりがシームレスに行えます。

大阪リージョンの選定ポイント

大阪リージョンがフルリージョン化したことで、大阪リージョン単独で利用できるほかに、地理的に離れている東京リージョンと組み合わせることによってより手厚いDR対策が求められるような高度な要件も実現できるようになりました。

ここからは、日本国内で国内リージョンを使う場合「東京リージョン」と「大阪リージョン」どちらを使えばよいのかを選ぶ基準をユースケース別に3点ご紹介します。

1. 社内基盤として使う場合

社内基盤としてAWSを使う場合、「会社にとってどちらのリージョンが地理的に近いのか」を基準に選定します。

ただしこれはインターネット経由で利用するのではなく、専用線（AWS Direct Connect）を用いて接続する場合に限ります。日本のインターネットの主要な電気通信網は東京に一極集中しているため、大阪リージョンへインターネット経由で通信をしようとした場合、東京を通って大阪リージョンへ接続される可能性があります。そのため完全にネットワークの経路まで制御するためには、専用線でAWSの大阪リージョンと接続する必要があります。

専用線通信で重要なポイントは、専用線の速度は地理的な距離に依存している点です。単純に距離が近ければ近いほど速度が速くなるため、会社に近いリージョンを選定するのがおススメです。ちなみに、Direct Connectが存在しているロケーション（AWSへのアクセス中継地）はAWSのリージョンとは独立しています。仮に東京リージョンに大きな障害が起きたとしても、Direct Connectのロケーションに対する障害の影響は受けにくいとされています。

2. フロントエンドシステムとして使う場合

フロントエンドのシステムとして使う場合、事業会社や開発部隊からの距離は関係なく、どちらかというとWebサイトの一般的なユーザーが西日本と東日本どちらに多いのかにあわせるのがポイントです。つまりエンドユーザーの通信遅延に配慮する必要があります。

では単純に東京を選択すればよいのかといえばそうではなく、例えば大阪に拠点を構えている地元販売店のECサイトなどは、アクセス分析すると西日本のユーザーが多い、というケースがあるそうです。どの地域のエンドユーザーに対してネットワーク的なインパクトを出すのかを、Webサイトでやりたいことを加味した上で判断する必要があります。

3. 災害復旧対策として

東京リージョンと大阪リージョン、どちらかのリージョンをDR対策基盤として使いたい場合、まずは「複数のリージョンを使う必要があるか？」の検討が重要です。検討に重要なのが、RPO（Recovery Point Objective）とRTO（Recovery Time Objective）の要件です。

RPOは障害発生時、過去の「どの時点まで」のデータを復旧させるかの目標値です。「昨夜の状態」に復旧できればいいRPOの場合は「最長1日」、1時間前に復旧が必要であればRPOは「最長1時間」と考えます。RTO（Recovery Time Objective）とは、障害発生時「どのくらいの時間で」復旧させるかの目標値です。言い換えると、「システム停止やサービス中断が許される時間」になります。これらの目標値は短ければ短いほど、目標を達成するためのシステム構成を実現するためにかかるコストが高くなります。そのため費用対効果をきちんと見定めた上で、構成を考える必要があります。

DR対策の場合、片方のリージョンは国内で片方のリージョンを海外にする、という組み合わせの選択肢も存在します。東京リージョンと大阪リージョンは直線距離にして約400km離れています。DR対策の要件で600km以上など、400kmを超える地理的距離が必要な場合は、ソウルやシンガポール、オーストラリアなどのリージョンの組み合わせが選択肢として浮上してきます。

また複数リージョン構成においては、通信遅延も考慮しなくてはいけません。東京リージョンと大阪リージョン間の通信遅延は実測約8msと言われています。AZ間の通信遅延は1msと言われている手前、人間の体感的にも8msはそれほど大した差ではないのでは？とも思いますが、この差はTCPプロトコルの動きを考えると見逃せないものになります。TCPプロトコルで通信を確立させるとき3ウェイハンドシェイクが行われます。つまりすべての通信遅延がデフォルトで3倍になるということです。そこにプロトコルごとの通信遅延が加えられると、その差は人間が体感できる遅延として現れると言われています。そのため東京と大阪をまたいだ完全な冗長化構成は、実現は難しい可能性がある、といった声もあるそうです。

ここからは、AWSが想定しているDR対策の構成を4パターン紹介します。あとに行くにつれてRPO／RTOの時間が短く、コストが高くなります。

バックアップ・リストア

まず1つめは、本番サイトとは別に、DRサイトを純粋にバックアップとして使用する構成です。

バックアップデータを定期的にDRサイトとなるリージョンへレプリケーションすることで、被災時にデータの可用性を確保できます。この構成で注意したいのが、災害時にDRサイト上でバックデータをもとにサイトを復元する場合です。例えば本番サイトとして利用していた東京リージョンに大規模障害が発生し、DRサイト上にバックアップしておいたデータをもとにWebサイトを大阪リージョン上で復旧させるとします。そうなった場合、同じようなことを考えた東京リージョンのユーザーが大阪リージョンへ大量に流れ込むとリソースを早いものがちで奪い合うことになる可能性が出てきます。

万が一に対して確実に備えるのであれば、要件に応じて「オンデマンドキャパシティ予約」や「ゾーンリザーブドインスタンス」でのキャパシティ予約を検討するのが望ましいとされています。

パイロットライト

2つめはDRサイトをバックアップとして利用しつつも、データベースなどの主要なアプリケーションで起動に時間がかかるものはDRサイト上で同期させておく構成です。こちらも先ほどと同様リソースの枯渇が懸念されるため、キャパシティ予約も視野に入れるのが望ましいです。

ウォームスタンバイ

3つめは、本番サイトと同一機能を提供しているシステムを、最小構成でDRサイトに構築し、平時から起動状態にしておく構成です。これによりRTO／RPOは短くなりますが、常にスタンバイさせておくのでパイロットライトよりも費用がかかります。また、本番環境と同等の負荷を一気には担えないため、災害時には迅速にスケールアップを図る必要がありますが、こちらもリソースの枯渇が懸念されます。

ホットスタンバイ

4つめは本番サイトとほぼ同じ環境を構築しておき、障害が起きたらAmazon Route 53を利用して単純に切り替える構成です。この構成の場合、通常構成の2倍のコストが常時発生するため、そこまでやる必要があるのかは費用対効果と相談して要検討する必要があります。

---

いかがでしたでしょうか。

当社がAWS上で提供するサービスにおいても、東京リージョンだけでなく、大阪リージョンの活用も踏まえたサービス展開を予定しています。

大阪リージョンの活用で高い可用性の実現が期待できる一方で、AWSから提供されている資料などを参考にしつつ、費用対効果などビジネス要件の視点から慎重な導入検討が必要です。