[レポート] ARC326 : マルチリージョンでActive-Active構成アプリの設計パターン #reinvent

AWS re:Invent 2018 AR209 - Architecture Patterns for Multi-Region Active-Active Applications のセッションレポートです。

以下、公式の概要です。

Do you need your applications to extend across multiple regions? Whether for disaster recovery, data sovereignty, data locality, or extremely high availability, many AWS customers choose to deploy services across regions. Join us as we explore how to design and succeed with active-active multi-region architectures.

以下、スピーカーの方々です。

Amy Che - Principal Solutions Delivery Manager, AWS

Darin Briskman - Chief Evangelist, Database, Analytics, & ML, AWS

Christopher Lane - Enterprise Architect, Chick-fil-A

スライド

レポート

まず最初に秘訣を教えてくれます。「マルチリージョンでActive-Activeなんてするんじゃねー！、高いし、複雑だし、ログとかセキュリティとか、もう超大変！」と。。。そして、どうしてもActive-Activeにしたい理由はなんなのか、他に検討するべき設計はないのか紐解いていきます。

アジェンダ

• マルチリージョンでActive-Active構成アプリの設計したいんだよね？
• マルチリージョンによる事業の継続性
• シングルリージョンからマルチリージョンへの再設計について
• カスタマージャーニー：Click-fit-A社のマルチリージョンへの道

マルチリージョンでActive-Active構成アプリの設計したいんだよね？

• AWSは世界中にリージョンがあり、リージョンごとに複数のゾーンがある。1ゾーンには1つ以上のデータセンターによりできている。
• 電源もネットワークも別に用意している。どれかのゾーンが落ちてもサービスを継続できる設計になっている。
• つまりAWSは、高い可用性を維持することができるサービスである。
• シングルリージョンで、99.99%を実現できる。つまり、年間で52.56分停止することを許容できるならシングルでOK。
• さらに、S3、Aurora、DynamoDB、Kinesisなどのマネージドサービスは最初から複数ゾーンでの高い可用性を維持する設計がされている。
• ちなみに、今回Active-Activeのマルチーリージョンの定義は、2つ以上のリージョンでフルスタックのインフラを提供することとする。
• レプリカ作成時の遅延（3000kmで30ms）、テスト、複雑さ、コストなどの問題がある。
• そして、ほとんどのエラーはヒューマンエラーによるものである。

マルチリージョンによる事業の継続性

• 事業継続性や災害時のリカバリー
• あるリージョンのサービスがダウンしたときに、事業継続に必要な重要なシステムであれば、別のリージョンにアクセスすることで利用者は目的を達成できる。重要では無いシステムは普通に復旧を待ったほうがいい。

• 顧客の住んでいる地域における問題

• レイテンシーの削減
• 個人情報の取り扱いの解決（PIIとかGDPRとか）

実際のところ、マルチリージョンかそうでないかという白黒付ける話ではなく、事業の目的に応じたグレーゾーンのどこにするかが重要になる。

マルチリージョンアーキテクチャーは、Active-Active構成である必要はない。 結局のところ、事業継続において、データの損失と、復旧までの時間について、許容できるかの設計になる。

事業継続における4つの戦略について

バックアップとリストア（マルチリージョン）

S3やGlacierへのデータコピー、EBSのスナップショットなどを行って他リージョンにコピーする

パイロットライト（マルチリージョン）

どうしてもダウンタイムを作りたくない一部のビジネスアプリケーションについて、リージョン間で"バックアップ"しておく。障害発生時にDNSルーティングが切り替わり、止まっているサーバーを起動して、数分から数時間前のスタップショットデータを用いて暫定復旧させる。

ウォームスタンバイ（マルチリージョン）

どうしてもダウンタイムを作りたくないビジネスアプリケーションについて、リージョン間で"レプリケーション"しておく。レプリケーション先は、システム全体が動く最小構成にしておくことで、数分以内の復旧を実現する方法。

4つ目は、Active-Activeです。

どうやって再設計するか？

一番簡単なのはマルチリージョンバックアップでテストも簡単。パイロットライトはデータ損失は1時間ぐらいで24時間以内には復旧するはず。ウォームスタンバイは数分のデータ損失で1秒以下で場合によってはデータ損失は0になり、数分以内に復旧するはず。ここで、どうしても、ゼロダウンタイム（または数秒のダウン）とゼロデータロスを実現したいとき、Active-Activeを検討する。

Active-Activeのパターン

Read Local, Write Global

読み込みは近場のリージョンで、書き込みはシングルリージョンにする方法。これでデータの衝突は無くなる。書き込みのレイテンシは数百msになるけど、多くのアプリは読み込みが多いから良い戦略のはず。例えば、ユーザー登録をするようなシステムの場合に有効です。

Read Local, Write Partitioned

読み込みは近場のリージョンで、書き込みも近場のリージョン。ただし、ユーザーが移動したら近場のリージョンで読み書きする。ユーザーが登録したときのいつも使う地域と、たまに利用する地域のパーティションを分けておいて定期的に片方向に同期をとることで実際の運用の問題は少なくなる。

Read Local, Write Local

読み書きをローカルで行い、常に同期をとっておく。問題があるのは、同時に同じレコードを更新するようなアプリケーションの場合。データが衝突したときの挙動を考えておく必要がある。リージョン間で距離が離れているのでデータの衝突がおきる可能性を消すことはできない。

ということで、AWSのマネージドサービスを活用しましょう。

• S3を使って99.999999999%の可用性を確保する。場合によってはリージョン間でコピーする。
• EBSを使って高速コピーしつつ、リージョン間で差分のスナップショットを取る。
• DynamoDBのグローバルテーブルを用いて、フルマネージドのマルチリージョン＆マルチマスターのデータベースを利用する。
• RDSとAuroraのクロスリージョンのレプリカを利用する。

リージョン間の通信について

• VPC + VPN とりあえず自前でVPNをするときは、VPN用のインスタンスを用意する必要がある。
• リージョン間 VPC Peering AWSのバックボーンを使ってVPC同士をつなぐ。VPN用のインスタンスが不要になる。 *マルチリージョン マルチVPC ハブ&スポーク型の構成でつなぐ。

Route 53（DNS）

• レイテンシベースのルーティング
• 地域ベースのルーティング
• 障害発生時のフェイルオーバー

NLB（ネットワークロードバランサー）

• NLB + リージョン間VPC Peering IPベースのターゲット指定で通信することができる。ターゲットグループを作ってフェイルオーバーできる。

Global Accelarator

• マルチリージョン（シングルリージョンもOK）で、NLB、ALB、EIPを使うときに、1つのグローバルでスタティックなIPアドレスを割り振ることができるようになった。TCPとUDPに対応していて、セキュアでトラフィック制御に対応してる。

どうやって管理するか？

マルチリージョンに対応したマネージドサービスをうまく活用して更に自動化することで省力化を図る。

• AWS CloudFormation StackSetsによるテンプレ作成
• AWS Config rulesによる統一された制限や構成監視の自動化
• AWS System Manager automationによるパッチ適用の自動化
• AWS System Manager inventoryによる構成データ集約の自動化
• Amazon CloudWatch Logsによるログの集約とチェックの自動化

Click-fit-A社の事例

• 現在の構成 DynamoDBのグローバルテーブル、Route 53の地域ルーティング、データベースのクロスリージョンレプリカ、Elastic Beanstalkによるアプリ管理、VPC Peeringなどを活用しています。

• 未来の構成 DynamoDBのグローバルテーブル、Route 53の地域ルーティング、データベースのグローバルテーブル、マネージドKubernatesによる高速化、マイクロサービスのルーティング、DevOpsプロセスの導入などをしています。

最後に

ビジネスの目的に合わせたパターンの提示から始まり、パターン毎の特徴と課題を明らかにしたうえで、課題を解決するAWSのマネージドサービスを紹介し、最後に顧客事例という、セッションの王道ともいえる流れで十分に理解することができました。AWS re:Inventのセッションは、大学の授業のような教育的な学びや気づきが多数あります。ビジネスを立ち上げたあとにぶつかる課題を先回りしてマネージドサービスとして次々と展開してくれているので、エンジニアはコアコードと事業に集中することができますね。

追伸、全て書きあげた後に、にしざわさんとレポートが被っていて心が折れかけたけど、そのまま公開します！ｗ