この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
SRV425-R - [REPEAT] Best Practices for Building Multi-Region, Active-Active Serverless Applications
In this session, we walk through building and deploying a global-scale, multi-region, active-active serverless backend using Amazon Route 53 to route the traffic among AWS Regions, Amazon API Gateway, and AWS Lambda for the backend, and Amazon DynamoDB global tables for handling data storage at a global scale. We provide a demo and a hands-on coding opportunity.
セッション
可用性について
可用性について
- 可用性のパーセントとダウンタイムとの相関
| Availability | Downtime per year |
|---|---|
| 99% (2-nines) | 3日15時間 |
| 99.9% (3-nines) | 8時間45分 |
| 99.99% (4-nines) | 52分 |
| 99.999% (5-nines) | 5分 |
| 99.9999% (6-nines) | 31秒 |
並列を行なった可用性のパーセントとダウンタイムとの相関
A = 1 - (1 - Ax)2
| Componet | Availability | Downtime per year |
|---|---|---|
| 並列なし | 99% (2-nines) | 3日15時間 |
| ２並列 | 99.99% (4-nines) | 52分 |
| ３並列 | 99.9999% (6-nines) | 31秒 |
サーバーレスコンポーネント
サーバーレスで構築される場合、以下のサービスなどが該当します
- AWS Lambda
- Amazon API Gateway
- Kinesis
サーバーレスコンポーネントをなぜ使うのか？
- サーバーのプロビジョン、もしくは管理が不要
- スケールをすることができる
- アイドル状態では課金されない
- 可用性とフォールトトレランス（障害許容設計）がビルトインされている
なぜマルチリージョンで展開するのか
可用性を改善、Disaster Recovery(DR)などの観点から
例えば、Serviceの一つが障害が起きた時、トラフィックの増加を検知して別のゾーンにスイッチさせる。
- US West → US East
CAP Theorem
- 一貫性
データに一貫性があること。全てのノードで見たときに同じ状態であること。
- 可用性
常にリクセストが失敗しない
- パーティションの許容値
一部のノードがクラッシュした場合でも、サービスを期待通りに応答させる
最終的な一貫性をもつ
特定のデータ項目に対して新しい更新が行われない場合、最終的にその項目へのすべてのアクセスは最後に更新された値を返します。
今回のデモで利用する構成について
Amazon Route 53
安全で信頼できるグローバルネットワーク、Global routingとして利用。
Amazon Route 53 のスルーティングについて
- Amazon Route 53 でレイテンシーベースルーティング
- 複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする際に使用
- Amazon Route 53 でレイテンシーベースルーティングへ移行する
- 位置情報ルーティング
- リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する際に使用
- 加重ルーティングポリシー
- 指定した比率で複数のリソースにトラフィックをルーティングするのに使用
Amazon DynamoDB Global Tables
フルマネージドで、マルチマスター、マルチリージョンに対応したデータベース
- 高性能でグローバルに分散したアプリケーションをビルド
- ローカルで使用可能なテーブルへの読み込み時間が短い
- 多地域冗長性を備えたDisaster Prof
- セットアップが簡単で、アプリケーションの書き換えは不要
Demo
Amazon DynamoDB間でトラフィックをルーティングし、グローバル規模のマルチリージョンでのサーバーレスバックエンドの構築とデプロイを行われました。
- Amazon DynamoDB の Global Tables を作成
- DynamoDBからの読み込みを行う GET API の Health Check
- DynamoDBへの書き込みを行う POST API の Health Check
試しにステータスコード 400 をレスポンスとして返すコードを別のリージョンにデプロイ（そのリージョンで障害が起きた時の動きを想定）し、Unhealty状態になったとき、そのリージョンに対するデータの書き込みのトラフィックが別のリージョンでデプロイされたサービスに流されている様子がデモされていました。
まとめ
可用性を高めるために並列でマルチリージョンに展開するアプリの構成とデモを見ることができました。マルチリージョンでデプロイするための構成が備わっているサービスを組み合わせることで、サーバーレスアプリケーションが最小の構成で作成できることを感じました。
27
