タダです.
先日, AWS の東京リージョンでの障害があったことは AWS 利用者のみなさんはご存知かと思います.今回の障害を踏まえ,今後の設計や運用にどう活かすかを考えたりチームで話し合ったりしていると思うのですが,僕も所属チームで振り返りをしました.その振り返りを踏まえ,自分なりに今回の障害から今後の設計と運用にどう活かしていくかをこの記事に残していきます.なお,記事で取り扱う考慮点以外にも考慮事項がある場合,ご指摘いただけるとありがたいです.
公式レポート
メディアの記事
piyolog さんの時系列や影響のあったサービスの記事
AWS CLI で振り返る AWS 障害時の各種ステータス確認方法
設計の考慮点
今回の障害を受けて設計時に検討が必要なキーフレーズとして以下を考えます.
- Availability Zone の冗長化(マルチAZ)
- ELBのスティッキーセッション
- ステートレス
- Design for Failure
Availability Zone の冗長化(マルチAZ)
AWS のネットワーク設計の重要な概念の1つである Availability Zone (データセンター群)を冗長化するのは今回のような特定の Availability Zone で障害が発生した時もシステムの稼働を継続させるために行います.
東京リージョンでは現状3つの Availability Zone が利用可能です.ただ,今回の障害においては 冗長化した Availability Zone(マルチAZ) に設定していても影響があったサービスがありました.3つの Availability Zone において影響があったかは公開されてないものの,システムの可用性を上げるために利用可能な Availability Zone は全て利用した設計を検討すべきでしょう.当然ながら Availability Zone を冗長化していれば万事安全ではなく,後述する復旧の手順・プロセスや承認フローを確立しておくのも合わせて大事だと考えます.
個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。
ELBのスティッキーセッション
今回の障害でも影響があったとレポートがあったスティッキーセッションですが,チーム内の振り返りでスティッキーセッションはできる限り使わず,ステートレスな設計を進めるべきだと話し合いました.ステートレスの話は後述するためここではスティッキーセッションの話を整理しておきます.
ロードバランサーのスティッキーセッションの効果は,セッション維持を固定のインスタンスで管理することです.今回の障害では特定の Availability Zone 1つで障害が発生して該当の Availability Zone に配置したサーバーは稼働できない状況に陥りました.そのため,セッション管理の維持は可能であれば,例えばデータベースやキャッシュサーバーに外出し管理する設計をできないかを検討しましょう.
AWS ドキュメント
ステートレス
チーム内の振り返りでスティッキーセッションを使わず,ステートレスな設計を使って EC2 を AutoScaling で構成していた場合復旧はインスタンスを入れ替えるだけで復旧できた事例がありました.ステートレスな設計をしておくことで復旧が簡易かつ,迅速に行えたことはとても有益な設計考慮点だと言えるのではないしょうか？ また,有名なThe Twelve-Factor Appにもステートレスが文脈に出てくるほどです.このような事実と設計思想からステートレスな設計が今後の設計で活かしていきたいと強く感じたポイントでした.改めてThe Twelve-Factor Appの思想も読み直します.
www.slideshare.net
Twelve-Factor App(日本語訳) 12factor.net
Design for Failure
クラウドと言えどもオンプレミスのデータセンター同様にサーバーがダウンしてしまうことはあるということを今回再認識された方は多いのではないでしょうか？ 障害が発生することを前提に設計する考えを Design for Failure(故障のための設計)と呼びますが,まさしくこの観点を入れる必要があります.この設計の考えを実現するには,如何に復旧する仕組みを入れるかがキモですが,自動復旧するように AutoScaling やAutoRecovery, CloudWatch Events などを取り入れて障害に強いアーキテクチャを検討しましょう.
Amazon EC2のイベント対応を楽にするためのアイデアと「Design for Failure」の考え方
運用の考慮点
今回の障害を受けて運用で検討が必要なキーフレーズとして以下を考えます.
- 障害検知
- バックアップの取得
- 復旧試験の実施
- カオスエンジニアリング
障害検知
一般的にサーバーの監視は各種サービスを使って管理していいると思いますが,今回のようなサービス基盤の障害を感知する手段をここでは整理します.AWS にはAWS Personal Health Dashboardで通知を受取り,障害を感知することが可能なので, CloudWatch Events と組み合わせて設定しましょう.障害だけでなく, EC2 のリタイアメントのイベントも通知可能です.
CloudWatch Events との統合
バックアップの取得
障害に対峙するために改めて AMI やスナップショットを取得し,復旧できるようにする仕組み化できていない部分がないかを見直しましょう.管理している AWS 環境によっては大量のリソース状況を網羅するのは容易ではないため,AWS Trusted Advidosr を使って確認するのもよいでしょう.
AWS Trusted Advidosr のベストプラクティス
復旧試験の実施
バックアップを取るだけでなく,どう復旧するかの復旧プロセスや組織内で復旧を誰がどのようにハンドリングするかの方針を確立し,復旧プロセスの試験も行うべきでしょう.復旧できてこそバックアップの効果がでます.そのためにも,バックアップを使って如何に復旧するかを試験してリリースするのが望ましいと考えます.
カオスエンジニアリング
障害を意図的に起こして対応する手法として,カオスエンジニアリングがあります.Netflix で実際に行われている手法です.詳細はまた別の記事で整理したいと思いますが,カオスエンジニアリングの目的は本番サービスで意図的に障害が発生しても復旧し,通常サービスを提供していけるかといった安定性・可用性向上のためです.リリースできたから OK ではなく,システムを育て続けるための手法の1つとして検討して良いかもしれません.なお,日本ではクックパッドさんがカオスエンジニアリングの実施宣言をした記事が有名ですね.
PRINCIPLES OF CHAOS ENGINEERING
Chaos Engineering やっていく宣言
まとめ
先日発生した AWS の Availability Zone 障害から今後の設計や運用に活かすための整理を行いました.クラウドといえどオンプレ同様にデータセンターで管理されているのだから障害は発生するし,障害が発生したからクラウドがダメでなく,クラウドの強みを活かすよう今回の経験を活かした改善活動に繋げたいですね.
