弾力性に優れたアーキテクチャの設計
このドメインで学ぶこと
このドメインでは、拡張しやすく疎結合のアーキテクチャの設計 (Amazon SQS、Amazon SNS、AWS Step Functions、Amazon EC2 Auto Scaling、Elastic Load Balancing) と、高可用性と耐障害性のアーキテクチャの設計 (マルチ AZ、マルチリージョン、バックアップと災害対策の戦略) を学びます。どこが止まっても全体が止まらない構成を、要件の RTO と RPO と費用から選ぶ問題が中心です。
重要ポイント
- 疎結合 - 処理の間に SQS のキューを置くと、片方が止まったり遅れたりしても他方は止まらない
- ファンアウト - 1 つのイベントを複数のシステムへ届けるなら、SNS のトピックから複数の SQS のキューへ
- 高可用性 - Auto Scaling グループと ALB を 2 つ以上の AZ に広げ、ヘルスチェックで異常なインスタンスを入れ替える
- データベース - RDS のマルチ AZ 配置は自動の切り替え、リードレプリカは読み取りの分散 (切り替えには昇格の操作が要る)
- マルチリージョン - Aurora Global Database、DynamoDB のグローバルテーブル、S3 のリージョン間のレプリケーション
- 災害対策の 4 つの戦略 - バックアップと復元、パイロットライト、ウォームスタンバイ、マルチサイトの順に RTO と RPO が短くなり費用は高くなる
用語と概念
Amazon SQS と Amazon SNS
SQS はメッセージを預かるキューで、処理する側が自分の速さで取り出します。1 つのメッセージは 1 つの処理する側が受け取ります。SNS は届いたメッセージを登録した全部の宛先へすぐに配る仕組みです。両方を組み合わせると、1 つのイベントを複数のシステムがそれぞれのキューで受け取れます。
Auto Scaling と Elastic Load Balancing
Amazon EC2 Auto Scaling は、決めた台数を保ち、負荷に合わせて台数を増減します。複数の AZ のサブネットを指定すると、AZ の障害のときも他の AZ でインスタンスを動かし続けます。Elastic Load Balancing は正常なインスタンスにだけ通信を振り分け、ヘルスチェックの結果を Auto Scaling の入れ替えに使えます。
→ Auto Scaling 用語集 / → Elastic Load Balancing 用語集 / → Auto Scaling の戦略
RDS のマルチ AZ とリードレプリカ
マルチ AZ 配置は別の AZ のスタンバイへ同期でデータを複製し、障害のときに自動で切り替えます。リードレプリカは非同期の複製で読み取りの負荷を分ける仕組みで、別のリージョンにも作れますが、切り替えには昇格の操作が要ります。目的が可用性か読み取りの性能かで選びます。
マルチリージョンの複製
リージョン全体の障害に備えるには、データを別のリージョンに複製します。Aurora は Aurora Global Database、DynamoDB はグローバルテーブル、S3 はリージョン間のレプリケーションが標準の方法です。自作の複製の仕組みより運用の負荷が低いため、試験でもこれらが正解になりやすい形です。
災害対策の 4 つの戦略と RTO / RPO
目標復旧時間 (RTO) は止まってから再開までの時間、目標復旧時点 (RPO) は失ってよいデータの時間の幅です。バックアップと復元は費用が低く復旧に時間が掛かり、パイロットライトはデータだけを複製してサーバーは災害のときに起動し、ウォームスタンバイは縮めた環境を常に動かし、マルチサイトは両方で常に処理を受けます。
Route 53 のルーティングポリシー
フェイルオーバーはヘルスチェックの結果でプライマリーとセカンダリーを切り替え、加重は決めた比率で振り分け、レイテンシーは利用者に近いリージョンを返し、位置情報は利用者の場所で行き先を決めます。障害のときの切り替えにはフェイルオーバーを使います。