GameDayとは
起源はAWSが毎年行っているAWS re:inventの中で開催される行事の1つです。
チームを組んでクラウド・アプリケーションを襲う謎の障害や悪意のある攻撃に対処し、トラブルシューティング能力を競うコンテストとなっています。
のちに様々な企業が社内でも実施するようになり、今ではAWS Well-Architectedのセキュリティ項目でもその実施が推奨されています。
ゲームデーを実施する
- ゲームデーを実施する: さまざまな脅威について、インシデント対応イベントのシミュレーション (ゲームデー) を実施します。このゲームデーには、主要なスタッフや管理者を参加させてください。
- 教訓から学ぶ: ゲームデーの実行から得られた教訓は、プロセスを改善するためのフィードバックに含まれている必要があります。
GameDayの手順
今回社内で行なったGameDayの流れです。
1. 発生させる障害を決める
本来であれば、障害対応者たちはその内容を事前に知らされずに対応します。
しかし初回ということもあり、事前にチームで相談して発生させる障害を決めました。
話し合いの結果、今回はAWS側の障害で最も頻繁で有名なAvailability Zone(AZ)障害を選択しました。
2. 事前に障害対応のドキュメントを作成する
想定される障害に関しては、事前に対応手順をドキュメント(復旧手順書)にしておきます。
障害に関するドキュメントは、そのシステムにとって重要な仕様書です。
また、実際の障害発生時に、ベンダーのリファレンスからリソースを一から探したり、他のメンバーを呼んで議論することは、復旧が遅れる原因にもなります。
事前に整理された手順書を参考にしながら対応することで、障害対応のスピードとクオリティを大幅に向上させることができるのです。
3. 対応リソースごとにチーム分けをする
弊社のSREのオンコール対応は、2週間ごとに当番の一名が担当するシフト制です。
しかし、AZ障害のような大きな障害は、複数のリソースに影響を及ぼすので、一人で全てを復旧するには負担が大きいです。
なので今回は、影響のあるリソースごとに以下のように担当者を割り振りました。
- ECS: 2名
- RDS: 1名
- ElastiCache: 1名
4. 実際に障害を発生させる
本番で障害を発生させて可用性を測るカオスエンジニアリングとは違い、GameDayはチームのトラブルシューティング能力を測るのが目的です。
なので今回は、Production環境ではなくStaging環境で障害を発生させます。
Gremlinなどの障害発生ツールを使うのが理想ですが、今回はVPCの特定のAZのルートテーブルに紐づくサブネットをデタッチすることで、擬似的にAZ障害を再現します。
5. 障害に対応する
各自アラートに気付き次第、実際に障害対応を行います。
今回はリモートワーク下での実施ということもあり、各々の作業をSpatialChatというチャットツールで画面共有しながら行います。
また、障害対応中はスクリーンショットやSlackの特定のチャンネルへのメモなどで、できるだけログを残しておきます。
6. 反省会
各々の障害対応の内容を、オペレーションログ兼報告書として提出します。
また、ドキュメントの手順書通りに対応してうまくいったかどうかを照らし合わせ、内容に不備がないかを確認します。
事前準備
GameDay当日までに、以下の準備を行いました。
Staging環境の冗長化
できるだけProduction環境に近い構成で行うために、事前にStaging環境のリソースもProduction環境同様に冗長化させておきます。
今回は各リソースを複数のAZに配置するようにしました。
ドキュメントの作成
自分の担当ではないリソースのドキュメントを、各々事前に書いておきます。
また、不足の事態を再現するため、このドキュメントは当日はまで担当者は見れないように設定します。
GameDay当日
1. 障害を発生させる
障害発生担当の方が、VPCのルートテーブルからサブネットをデタッチしました。
2. メンバーを招集
Datadogのアラートに気づいたメンバーが緊急性の高い障害であると判断し、SpatialChatに集まるよう指示しました。
3. 障害対応
各々の作業画面を表示させて、それぞれ対応にあたりました。
ECSは担当が二人だったので、一方はドキュメントを見ながら指示を出し、もう一方はそれに従って作業をするようにしました。
4. 問題発生
RDSとElastiCacheとFargateはドキュメント通りに復旧できましたが、ECSのEC2インスタンスでは想定外の問題が起こりました。
ECSのEC2インスタンスは、aとcの二つのAZに冗長化させており、今回は障害が起きていない方のcにALBを一時的に寄せようとしました。
しかし、ALBは「最低二つのsubenetの指定が必要」「指定できるsubnetは各AZに一つだけ」という制約があったので、復旧には元々三つのAZが必要でした。
結果、ECSのEC2インスタンスの復旧に関しては、失敗という形に終わりました。
5. 反省会
よかったところ
- 事前にドキュメントを準備していたおかげで、スムーズに復旧ができた。
- 画面共有で作業を可視化することで、お互いの作業を助け合えた。
反省点
- ドキュメントがより詳細だとなおよかった(Terraformのファイルパスなど)。
- 他のメンバーへの作業確認を一部怠っていたところがある。
- 作業ログは時間ベースでもっと残しておくべきだった。
課題点
- 3AZでなければALBが復旧できないので、次回は3AZ状態で検証する。
- オンコール対応の場合、一人で全てのサービスを復旧できるかどうか。
- オンコール対応の場合、対象のサービスの復旧優先順位を事前に決めておく必要がある。
まとめ
今回のGameDayでは、チームの各サービスに対する理解度や、障害対応の手順などが再確認ができたことが大きいと思います。
次回は実際のRTOの計測のためにも、オンコール対応者のみで実施する予定です。