第8回のオンライン輪読会に備えて読んだ内容を自分なりにまとめておく。
今回の記事はこちら。
[期待/予想する内容]
この記事の目次は次のとおりである。
- はじめに：アベイラビリティーゾーンの役割
- 静的安定性
- 静的安定性パターン
- 内部の詳細：Amazon EC2 内の静的安定性
- まとめ
またしても目次がシンプル、そして静的安定性という言葉に全然馴染みがない。これは……完全に勘に頼るしか予想できない。
サイトのOGPの説明みても、単にアベイラビリティーゾーンを使います、くらいしか分からない。
「静的安定性」……アベイラビリティーゾーンと関係がある、ということくらいしか分からない。アベイラビリティーゾーンを使用した、とあるから、当然使用しないパターンもあるんだろうな。例えばもっと小さいレベルの、2台のマシンだけに分散させてるくらいの。
静的ってなんだろう？対義語は動的安定性？動的だったら、オートスケーリングとかで、インスタンスを追加して安定性を高めるとか、そういう話だろうか。対して、静的……あ、アベイラビリティーゾーンを増やして、どちらか落ちても大丈夫、安定してますよってこと……かなあ？
リージョンをまたぐようなのは静的安定性にはつながらないんだろうか？
「静的安定性パターン」……パターンってついただけで、タイトルから読み取れる情報があまり増えていない。アベイラビリティーゾーンの使い方なんて、2つ使うか3つ使うか、みたいな数の違いくらいしかないんじゃないのかな……。
「内部の詳細：Amazon EC2 内の静的安定性」……EC2内の、ってどういうことだろう。1つのEC2インスタンスは1つのアベイラビリティーゾーンに配置するから、複数使えなくて、高可用性を目指すには複数インスタンスを複数のアベイラビリティーゾーンに配置するしかないはず……。分からない。
EC2は実は複数アベイラビリティーゾーンに分散されていた？いや、それはないか……。
[記事の要約]
次に、実際に記事を読んだ内容を箇条書きでまとめる。
はじめに：アベイラビリティーゾーンの役割
- 非常に高い可用性が必要なサービス→依存関係が損なわれても復元力を維持する設計
- このような復元力を実現するためのパターン＝静的安定性（static stability）
- 依存関係が損なわれても、システム全体が動作し続ける（古い情報のみで）
- アベイラビリティーゾーンとは
静的安定性
- 障害発生時に別のAZにスケールアップするのは効果的ではない
- 障害への対応に依存している＝静的安定性に欠ける
- 静的に安定している＝AZが損なわれても新しいEC2インスタンスなしでサービス提供できるように過剰にプロビジョニングされている
- EC2はこの原則にしたがって設計されている
- EC2にはコントロールプレーン（CP：リソースの追加/変更/削除）とデータプレーン（DP：インスタンスの各種動作）がある
- CPの障害がDPに影響しないように作られている
- CPとDPを分離することが高可用性にとって重要
- CPの可用性よりDPの可用性が顧客には重要：CPの方が可動部が多く、障害確率が高い
- DPは通常CPと比べて数桁大きい規模で動作する
- なぜAZ障害時にインスタンス追加が効果的でないか？：依存が多い
- CPの復旧パスへの依存
- アプリケーション固有の依存：ランタイムのダウンロード、認証情報取得など
- DPの障害時にはCPも正しく動作しない可能性大
静的安定性パターン
- アクティブ-アクティブ・パターン：HTTPSの負荷分散
- ステートレスなサービスを3以上のAZにデプロイ
- 1AZに障害があっても残りで対応可能
- (3AZなら)各AZが負荷テストしたレベルの66%で動作するようにする
- AZ障害時にスケールアップ・アクションは不要
- アクティブ-スタンバイ・パターン：RDB
- ステートフルなサービスはリーダー（プライマリノード）を必要とする
- スタンバイ候補を別AZに配置し、将来のリーダーとする
- 障害時にインフラの操作は不要：DNS名の再ポイントのみ
内部の詳細：Amazon EC2 内の静的安定性
- EC2のデプロイ
- デプロイカレンダーに基づき異なるAZには別の日にデプロイされる
- デプロイのベストプラクティス：ワンボックス（＝1つのサーバー？）、1/Nのサーバー、とデプロイ範囲を拡大していく
- 一方で、EC2では、AZ境界も意識してデプロイする：障害がAZを超えない
- パケットフロー
- ネットワークトラフィックがAZ内にとどまる設計
- AZ独立性を確保することで、利用者がリージョン内の高可用性システムを利用できるようにしている
- リージョナルサービス
- ALB@AZ-1b + EC2フリート（1a+1b+1c）
- シンプルでいい設計
- ただし、AZの独立性を提供するためのビルディングブロックである場合は不適合
- ゾーンサービス
- AZごとにサービスを構築する
- リージョナルの場合よりもAZ障害を回避できる可能性が高い
- 例）DPの一部であるEC2 NAT Gateway
- ゾーンサービスの問題点
- より複雑になりコストがかかる（が、そのおかげで高可用）
- DRのため、データの耐久性については、AZ間レプリケーションが必要
- リージョナルパターン
- ゾーンパターン
まとめ
- 静的安全性の鍵は障害発生前に予測すること
- AZがかけても十分となるように過剰にプロビジョニングするべし
- EC2の一部はリージョナルサービスではなくゾーンサービスとして構築されている
[予想のふりかえりなど]
AZをたくさん使って可用性を高める、事前にプロビジョニングして障害に備える、という点では静的安定性を理解できていたように思う。
ただ、背景となっている、ゾーンサービスを利用することで得られるネットワークトラフィックの安定性や、AZ障害回避というメリットについては十分に理解できていなかった。
ここまで大規模なサービスを構築する機会が今後の自分にあるかどうかは分からないし、AWS利用者としてサービスを利用する分には、ゾーンサービスはあまり意識しなくても良い内容に思える（むしろ、ALB＋フリート形式とかでAZを効率的に利用していく側なので）。
[まとめ]
- 「The Amazon Builder's Library」の『アベイラビリティーゾーンを使用した静的安定性』を読んだ
- データプレーン障害時にはコントロールプレーンにも問題がある可能性が高いので、事前にプロビジョニングしておくことで安定性を高めるべし
- アベイラビリティーゾーン独立性の原則を有効にするために、ネットワークなどのインフラはそれぞれのアベイラビリティーゾーンごとに提供されている
これで8/13記事を読んだことになる。あと5つ！
引き続きAmazon Builder's Library読んでいくぞ。
