re:Invent 2024: AWSのインシデント対応と分析 - Tech CallからCOEまで
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - The incident is over: Now what? (ARC207)
この動画では、AWSのインシデント対応とその後の分析について、AWS内部の具体的な取り組みが紹介されています。Tech CallやSupport Callの運営方法、Command Centerの活用、そしてPost Mortemの実施方法など、インシデント発生時の実践的なプロセスが詳しく解説されています。特に興味深いのは、AWS全体で水曜日の朝2時間をかけて1000人規模で実施される運用会議の存在と、そこでのCOE（Correction of Error）の共有方法です。また、インシデントから得られた知見をZonal shiftやAdaptive Retryなどの具体的な製品やSDKの機能として昇華させている事例も紹介されており、組織的な学びをスケールさせる方法論が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
インシデント対応とPost Mortemの概要：AWSの取り組み
みなさん、こんにちは。本日は、インシデント対応とインシデント後の分析についてお話しさせていただきます。このトークには2つの主な目的があります。1つ目は、AWSのお客様として、時にはAWS側のインシデントに巻き込まれることがあるかもしれないということです。AWS Health Dashboardを使用したり、AWS Supportと協力したりする機会があるかもしれません。そこで、そういった状況でAWS側で何が起きているのかについて、より詳しい背景をご説明したいと思います。2つ目は、皆様も恐らく自社のお客様向けにサービスを提供されているため、独自のインシデント対応を行っているはずです。私たちの取り組みについて詳しくご紹介することで、皆様のビジネスでも活用できるテクニックを見つけていただければと思います。
本日は、Gavinと一緒にお話しさせていただきます。GavinはAWSで約13年間、Senior Principal Engineerとして、Load BalancingからDNS、そして最近ではApplication Recovery Controllerまで、様々なチームで働いてきました。さらに重要なのは、GavinはAWS Call Leader（後ほど説明しますが、インシデントコマンダーのような役割です）を務めているということです。Giorgioは、AWS Support組織のPrincipalとして働いています。私たちの2つのチームは、インシデント発生時に協力して対応します。私のグループが問題の緩和に取り組む一方で、Giorgioのチームは私たちと協力して状況を理解し、お客様とコミュニケーションを取り、できるだけ早く通常の状態に戻れるよう支援します。
では、本日のアジェンダを見ていきましょう。 まず、少し告白させていただきます。アブストラクトは6ヶ月前に書いたのですが、実際にスライドの作成に取り掛かってみると、イベントの管理方法について説明せずに、イベント後の対応について話すのは非常に難しいことに気づきました。そこで、まずイベントのトリガーから解決までの流れについて説明します。その後、Post Mortem（振り返り）のフェーズから、アクションアイテムの定義と実装までをカバーします。3つ目のパートでは、チームが行ったPost Mortemを組織全体に展開し、会社の一部だけでなく、組織全体の学びの機会とする方法についてお話しします。
AWSのインシデント検知と初期対応プロセス
最初のフェーズは、イベント自体です。まず最初にやるべきことは、検知し、全員を招集し、イベントの緩和に取り組むことです。 おそらく皆様の組織と同様に、私たちのサービスチームもメトリクスやアラームを持ち、サービスを監視しています。 また、一般的にCanaryまたは合成モニタリングと呼ばれるものも使用しています。つまり、アプリケーションが生成するメトリクスだけを信頼するのではなく、常にお客様を模倣するCanaryを使用して、カスタマーエクスペリエンスが適切であることを確認しています。
少し異なる点で、皆様にとって馴染みがないかもしれないのが、Aggregate Alarmと呼ばれるものです。AWSのリージョン内には、お客様向けのサービスだけでも数百存在します。これらはすべて共通のネットワーク、共通のDNSインフラストラクチャ、認証・認可などに依存しています。そのため、複数のサービスが同時に影響を受ける問題が発生することがあります。20のチームが同時にアラームを受け取り、それらが全て関連している場合に、各チームが個別に調査を始めるのは大きな時間の無駄になります。そこで、このAggregate Alarm検知システムを使用して、全員を1つのコールに集め、協調して問題の診断を行うようにしています。
さらに、間接的な指標というものがあり、これらをCustomer-driven metricsと呼んでいます。その一例がトラフィックの傾向分析です。エラーや障害を探すのではなく、特定のサービスが、その時間帯や曜日に想定される量のトラフィックを受けているかどうかを確認します。もう1つのさらに間接的な指標として、サポートへの問い合わせ数を追跡しています。お客様が突然、あるサービスの潜在的な問題について問い合わせを始めた場合、そのサービスが意図通りに動作しているかどうかを確認する必要があるという良い指標となります。
AWSにまつわる伝説によると、2008年か2009年頃、DublinからSeattleを訪れていたエンジニアが、金曜日にフラストレーションを感じていたそうです。週末を一人で過ごすことになり、AWS全体のダッシュボードを作ろうと決心しました。2009年当時のAWSは今よりもずっと小規模でしたが、彼はホテルの一室で週末をかけてそれを作り始めました。
週末にホテルの一室で作り始められたこのダッシュボードは、それ以来、私たちが維持・開発を続けています。これがAWS全体を可視化するための中核となりました。ここでお見せしているのは、やや引きで表示され、少しぼかしてありますが、AWS全体を見渡すトップレベルのダッシュボードで、各サービスの3～5個の主要メトリクスを表示しています。ここでの目的は問題を見つけることです。1つのサービスに問題がある場合、そのサービスチームが対処するでしょう。しかし、複数のサービスが影響を受けている場合は、すぐに行動を起こし、全員を調整するための会議を開く必要があります。
時々、単一のサービスで問題が発生することがありますが、基本的にはそれらのチームが自身で対処します。場合によっては私たちに支援を求めることもありますが、それは問題ありません。また、他のチームの関与が必要になることもあります。Incident Responseとして私たちが本当に注力しているのは、複数のサービスに影響が及ぶ問題です。このダッシュボードと併用する自動化システムを使用して、数分以内にイベントを検出します。自動的にIncident Response primaryとサポートチームを招集し、影響を受けるほとんどまたはすべてのサービスチームを集めます。重要度に応じてCall leaderを配置し、通常は基盤となるサービスのオーナーである「usual suspects」のグループにもページングを送ります。
サービス側では、人々を集めて調整することで、できるだけ早くイベントを終息させるため、復旧時間の短縮に努めています。 サポート側では、お客様とのコミュニケーションとソリューションのガイダンス提供に焦点を当てた、同様の会議と対応を開始します。サポート組織の上級メンバーとサービスリーダーシップによって運営され、1つの重要な目標があります：お客様の復旧を早めることです。私たちのサービス復旧を待つよりも、お客様自身のアクションで早期に問題から抜け出せるケースがあり、進行中のイベントとお客様の状況に関連した、正確でタイムリーなガイダンスを提供したいと考えています。
Tech CallとSupport Callの運営：AWSの危機管理体制
AWSのサービスリーダーやCall Leaderからよく聞かれる典型的な言葉は「直列ではなく並列で調査を行う」というものです。20人がCallに参加していて誰かが「原因はXだと思う」と言うと、全員がXに群がってしまいます。そこで私たちは規律を持って「いいえ、まずは各自が自分のサービスを確認し、複数の仮説を並行して検証していきましょう」と言わなければなりません。 Call LeaderとIncident Responseが運営するTech Callでは、根本原因の追究よりも、まず影響の軽減に重点を置いています。そこには多くのエチケットがあり、社員は入社時にそれを学ぶ必要があります。
基本的なルールの1つは、Callではミュートにすることです。100人がCallに参加すると、誰か1人がミュートを忘れて家族と会話したり、コーヒー豆を挽いたり、ヘリコプターに搭乗したりする可能性が非常に高くなります。最近では、誰が話しているかを確認してミュートできるビデオ会議システムが導入され、状況は劇的に改善されました。 時には、1つのチームが十分な帯域幅を確保して、複雑な問題について内部で話し合う必要が出てくることもあります。 また、私たちはチケットシステムにTech Ticketを作成しており、これがインシデント全体を通じての記録として機能します。これは非常に重要な、改ざん不可能なインシデントの記録となります。
これらのCallでは「その観察結果をTicketに記載してもらえますか？」という言葉がよく聞かれます。誰かがCallで非常に洞察力のある発言をした際、その情報とコンテキストを失わないようにするためです。 これらはTicketからのスナップショットです - ここでは誰かが遭遇した例外を投稿しています。 これは別のエントリーで、特定の時刻にロールバックを開始したことを記録しています。タイムスタンプが付いているので、全員がロールバックの進行状況を追跡できます。 ここでは誰かがグラフのスナップショットを投稿しており、これはTicketに永久に保存されるので、どのグラフを見ていたのかを正確に知ることができます。 そしてこれは、誰かが何が起きているのかについて仮説を立てているエントリーです。ここで私たちが行っているのは、後のために共感を保存することです。これは、インシデント後の分析において、当時何を考えていたかの良い記録を持つことが非常に重要だからです。
AWS Supportのコールについて簡単に見てみましょう。これはAWS Event Management and Engineeringというチームが運営しています。最近の組織再編後、彼らはイベントの運営と顧客とのコミュニケーションに関するすべてを上から下まで担当しています。彼らはStatus Dashboardと関連するツール群の所有チームです。
このCallで主に行うのは、ケースのトレンドを監視することです。これは非常にシンプルな指標です。Tech Callが適切な事項を調査しているかを確認するため、サービスごとに何件のケースが発生しているかを把握し、また、社内での調査内容が顧客が実際に見ているものと一致していることを確認するため、顧客からのインパクトレポートを確認します。 このCallのもう1つの重要な役割は、外部とのコミュニケーションです。これまでに皆さんが目にしたイベントに関するすべてのコミュニケーションは、ここで草案が作成され、定義されています。何をいつ伝えるかを決定し、発信前にコンテンツを相互に確認します。
冒頭で述べたように、私たちは復旧ガイダンスに取り組んでいます。というのも、インシデント発生時に私たちが提供できるガイダンスを、お客様が非常に重視していることがわかったからです。時には、故障しかけているインスタンスを停止して置き換えるといった、とてもシンプルな対応で済むこともあります。時にはより複雑な切り替え作業が必要になることもありますが、お客様は私たちの提案に耳を傾け、アドバイスを待っています。また、私たちは障害が発生しているリソースの切り離しや、サービスの切り替え、そして後ほど説明する私たち自身のサービスに関する緩和策の実行など、一般的なベストプラクティスも提供しています。
最後に、私たちは大規模な影響を持ち、大多数のお客様に有効な項目に焦点を当てて、スケールを意識して作業を行っています。ただし、特殊な状況や条件を持つお客様のケースもあり、そういった場合には適切なエンジニアとマッチングさせて支援できるようにしています。私たちは発生している例外的な状況すべてに目を光らせています。このコールは当然、Tech Callと常に連携しており、スタッフが両方のコールを行き来したり、同時に参加したりしています。
ここでCommand Centerについてご紹介したいと思います。Command Centerは、私たちのオールインワンサポートツールの第3世代です。ここで見ていただいているのは、イベントを追跡するモジュールです。コンテンツの横にメタデータが表示されており、イベントの内容、影響を受けているサービスやリージョン、開始時間などが確認できます。先ほど言及したケースメトリクスも表示されており、Supportケースだけでなく、ソーシャルメディアでの言及や、そういったチャネルを通じてお客様から連絡があった場合の状況も追跡しています。画面の右側に表示されているのは、参加したり対応に加わったりするSupportエンジニアに概要を提供するもので、30秒で状況を把握し、どこに情報があるかを確認できるようになっています。
インシデント時のコミュニケーション戦略
このような特定の通知は、Supportエンジニアが見るSupportケース管理パネルの横に表示され、可能な限り効果的にすべてのお客様をサポートできるようになっています。それでは、イベントコミュニケーションについてもう少し掘り下げてみましょう。私たちは長年の経験から、インシデント時のコミュニケーションはバランスの問題だということを学びました。ここには3つの重要な要素があります。1つ目は正確性です。私たちは関連する情報のみを伝えたいと考えています。お客様は私たちの通知を受け取ると、チームを招集してイベントへの対応を開始します。そのため、私たちが情報を発信する際は、お客様がアクションを取る必要があり、かつ正確な情報を伝えたい場合に限ります。
あるサービスで問題が発生していると伝える場合は、本当に問題が継続していることを確認したり、正しいサービスを特定したりすることを徹底しています。2つ目の要素は、お客様から聞いている「十分な詳細情報の提供が重要」という点です。これにより、お客様は自身で判断を下し、イベントについての理解を深めることができます。3つ目は明らかですが、スピードです。情報をできるだけ早く発信したいと考えています。私たちが把握している情報をできるだけ早くすべてのお客様に届けることで、エンゲージメントを改善し、双方で同じ調査を行うことを避けることができます。私たちは通常、1つ目と3つ目の要素を優先し、イベントが発生していることが確実になった時点で、できるだけ早く通知を送信するようにしています。正確性に関して、時間とともに興味深い技術的アプローチを取り入れてきました。それは、パブリックのStatus Dashboardですべての情報を投稿する方式から、よりパーソナライズされたダッシュボードを使用する方式への移行です。ご存じかもしれませんが、これは基本的にアカウント固有のヘルスイベントビューで、影響を受けているお客様のみをターゲットにすることができます。
現在、問題の調査を開始した時点で顧客に通知できるオプションの開発を進めています。これは、特定のリージョンのサービスで起こりうる事象について調査を開始したことを知らせるシンプルな通知のようなものです。このような通知は多少ノイズが多くなる可能性があり、フィルタリングが必要になるかもしれませんが、顧客が自身のモニタリングの一環としてこのシグナルを活用できるようにしたいと考えています。
コミュニケーションは単一のストリームではありません。適切なメッセージを適切なオーディエンスに届けることが重要です。社内には2種類のオーディエンスがいます。1つは、社内のサービス名や専門用語、内部コンポーネントに精通した技術者です。この層には生のアップデートを提供します。これはTech Ticketそのものか、その要約版で、フィルタリングは行わず、非常に迅速に共有されます。もう1つは、顧客をサポートするフィールドチーム向けの定期的な情報提供です。Account ManagerやResolution Architectが顧客から連絡を受けた際に、有用な情報を提供できるよう、状況の要約と整理された情報を定期的に配信します。Technical Account Managerがこの種の情報の主なユーザーです。
外部向けには、サービスのステータスだけでなく、対応方法に関する推奨事項や、現状、今後の計画、調査中の根本原因についての定期的なアップデートも提供するようにしています。 Tech Callに話を戻すと、その間私たちは問題の緩和に取り組んでいます。よく耳にする質問の1つが「その変更はまだロールバックしていないのか？」というものです。先ほど述べたように、エンジニアは事象の詳細や根本原因の解明に非常に興味を持っており、制止しないと長時間それに費やしてしまいます。私もエンジニアなのでその気持ちはよくわかりますが、Callでの優先事項は問題の緩和です。
インシデント緩和と根本原因分析：AWSの対応プロセス
私たちには準備された一連の対処法があります。その1つが、障害からの切り離しです。例えば、10台のホストがあり、そのうち1台の指標がおかしい場合、すぐにそのホストを切り離します。躊躇する必要はありません。1台のホストを失っても対応できることはわかっています。また、指標がおかしく、特定のAvailability Zoneが少し異常に見える場合、すぐにそのゾーンから全てを移動させ、問題が解決するか確認します。 2つ目の対応は、進行中の変更を全てロールバックすることです。Amazonのネットワークエンジニアやデプロイメントチームなど、全てのチームが即座にロールバック可能な状態であることが求められています。全ての変更管理ツールにはロールバック計画が含まれており、それが問題の原因かどうかまだわからなくても、すぐにロールバックすることが期待されています。
3つ目の対応は、特に1つのサービスに問題が絞り込まれた場合、まだ原因がわからなくてもそのサービスを再起動することです。例えば、フリートの1台のホストにログインして再起動し、改善が見られれば、同じ方法でフリートを再起動します。これは根本原因がまだわからなくても、できるだけ早くイベントを終わらせて正常な状態に戻すために非常に効果的です。また、プロアクティブなスケールアップもしばしば有効です。バックログが蓄積され、イベント周辺で負荷が増加する可能性が高いため、準備が整っていて安全に実行できる場合は、スケールアップして緩和時間を短縮することが有効です。
最後の手段として、必要な場合はサービス自体に変更を加えます。これは本番環境でコード変更を行うという、よりリスクの高い選択肢です。できれば避けたいところですが、必要であれば実施します。 問題を緩和した後は、血圧が正常に戻り始め、アドレナリンも落ち着いてきますが、それでも集中力を保つ必要があります。 ここで問題となるのは、この問題が再び発生するリスクがあるかどうかです。まず最初に、Giorgioのチームと協力して、私たちの対応策について顧客の同意を得られているかを確認します。メトリクスは良好を示していますが、本当に問題ないのか確認する必要があります。その後、根本原因の究明と再発リスクの評価を行います。
関連するデプロイメントパイプラインをすべて停止します。特に1つのデプロイメントが問題の場合、そのコードが他の場所に展開されないようにパイプラインを停止します。問題をさらに悪化させないように、多くの場合、問題の緩和前でもChange Managementを停止します。同じ問題の影響を受ける可能性のある他のシステムも確認します。私たちの場合、最も一般的な懸念は、このコードが他のリージョンに展開されているか、あるいはまさに展開されようとしているかどうかなので、それが起きていないことを確認します。
コールの終わりに近づくと、ラップアップの前に、 安全性と安定性を確保するための短期的な修正について話し合います。一般的なアプローチとして、コール中に発見したメトリクスに追加のアラームを設定し、同じことが再び起きた場合に素早く発見できるようにします。COE（root cause analysisタイプのドキュメント）を割り当てます。 調査中のヒープダンプやコアファイルなど、保存すべきデータやログを探します。これらのアーティファクトは、後のRoot Cause Analysisで非常に重要になるため、確実に保存します。追加のフォローアップアクションを探し、 次のステップについて合意し、コールを終了します。
Post Mortem（COE）の作成と実施：学びを活かすAWSの取り組み
この段階で緊急事態は収束し、イベントは解決され、 顧客から対応の確認を得て、状況は正常に戻ります。ここから、レビュー、Postmortem、そして私たちが呼ぶCOEを通じて、何が起きたかを振り返り、将来に向けた計画を立て始めます。 これらの作業には、いくつかの原則があります。1つ目は共感を持って臨むことです。共感には2つの意味があります：影響を受けたチームのための安全な場所を作り、失敗や経験を共有できると感じられるようにすることです。彼らは非難されるためではなく、全員が学ぶために参加しているのです。共感のもう1つの側面は、イベント発生時に彼らが持っていた知識に自分を置いて、効果的なPostmortemを実施することです。
AWSでは、 Postmortemが分散的な取り組みになるようにしています。イベント中に、改善の機会がある、あるいは何か異なることをする必要があるチームを見つけた場合、それらのチームにCOEを割り当てます。AmazonやAWSの1つのイベントで、最大10〜15のチームが関わることも珍しくありません。チームはオプトアウトすることができます。つまり、Postmortemを検討するよう要請されますが、妥当な理由があれば却下することができます。
COEの作成者としては、一般的に障害が発生したコンポーネントに最も近いチームメンバーが執筆を担当します。これは、特に長年運用されているシステムについて学ぶ良い機会であり、そのサービスやサブシステムがどのように動作するかについて、チームが完全かつ深い理解を持っていることを確認する機会でもあります。チームとしては、学び、好奇心を持つ機会となります。新しいメンバーを含む様々な経験年数のメンバーがいるチームでは、協力することで、サービスの動作原理や特定の設計が採用された理由について学ぶことができます。
組織としては、COEは文書化された形で簡単に共有できるため、学びを共有する上で重要です。また、見落とされがちな側面として、一般向けのサービスを提供している場合でも、社内チームの依存関係にある場合でも、Postmortemは信頼を取り戻す機会となります。内部または外部のお客様に対して、何が起きたのかを理解し、真の根本原因を特定し、再発防止のための強力な対策を実施していることを信頼してもらいたいのです。
それでは、COEはどのように構成されているのでしょうか？まず、影響の概要から始まります。私たちの影響の概要は、内部と外部の視点を組み合わせたものです。チームがサービスとイベントについて把握していること、そしてこのチームのお客様がイベント中に経験したことをまとめます。次にRoot Cause Analysisがあり、単一の根本原因を特定する傾向がありますが、実際には、すべてのイベントが複数の根本原因の組み合わせであることがわかっています。
イベント中に、障害とは直接関係のない動作 - 私たちが認識していなかったことやギャップを発見することがあります。これらの観察事項や学びは、解決に直接関係なくても、COEに記録する傾向にあります。そして、これから詳しく説明するAction Itemsがあります。全体として、同じトリガーが同じイベントや障害状態につながらないようにするために実施する対策のリストです。
いくつかのセクションを詳しく見てみましょう。最初は検出です - 私たちは非常に自己批判的になり、検出時間に満足しているかどうかを理解しようとします。第一の質問は：イベントを十分早く検出できたか？システムが意図した通りに動作していないことを、適切な時間内に検出できたか？答えがノーの場合、なぜそうだったのか、そしてそれについて何ができるのかを深く掘り下げます。
2番目の領域は、インシデント発生中のパフォーマンスについてです。インシデント中でも、私たちの対応がシステムにどのような影響を与え、解決にどう役立っているかを理解するための適切な可観測性を確保していたかを確認したいと考えています。3番目の領域は、少し視野を広げて、この特定の障害状態だけでなく、同様の症状を持つ類似の事象が発生した場合に、それを検知できる自信があるかどうかを確認することです。
依存関係は、私たちが多くの時間を投資するもう一つの領域です。システム間の内部または外部の相互依存関係は非常に一般的です。インシデントが私たちのサービスではなく、私たちが運用しているサービスの依存関係によって引き起こされた場合、まず、その依存関係を意図した通りに使用していたかどうかを確認します。依存関係やシステムは、レイテンシーや可用性の観点からパフォーマンスの約束を持って設計されているため、私たちが適切な期待を持っていたかを確認したいのです。次に、その依存関係が意図した通りに機能したかを検証します - その依存関係は、私たちがそれを使用することを決めた際の約束を守っていたでしょうか？最後に、その障害モードを予期すべきだったかどうかを検討します。100%の可用性を持つ依存関係は非常に稀で、各依存関係やサービスには特定の障害モードがあります。私たちはそれらすべてをカバーし、対処するか、あるいはそれらの障害モードの1つが発生した時にサービスがどのように振る舞うかを理解しておく必要があります。
ここで少し持論を展開させていただきたいので、あらかじめお詫びしておきます。Five Whysという手法をご存知の方はどれくらいいらっしゃいますか？実際に使用している方、あるいは好ましく思っていない方は何人いらっしゃいますか？私自身、この手法に対して複雑な思いを抱いています。短く簡潔で、誰もが意味を理解できる便利な用語やフレーズではありますが、文字通りに解釈すると、私の経験では上手くいかないことが多いのです。まず第一に、多くの場合、5つのWhyで止めるべきではありません。Whyは線形の分析であってはならず、リンクリストではなく、ツリー構造であるべきです。
例として、少し作り話ですが、実際にあったかもしれないシナリオを見てみましょう。なぜAPIコールが失敗したのか？フリート内の1台のホストが500エラーを返していた。なぜホストが500エラーを返したのか？ホストがストレージボリュームに書き込めなかった。なぜEBSにストレージボリュームを書き込めなかったのか？なぜEBSに問題があったのか？さて、5つのWhyを完了しましたが、おそらく良い結果は得られていません。このアプローチでは、アクションアイテムはまだ十分ではありません。
Five Whysを超えて：AWSの根本原因分析アプローチ
これが最善のアプローチではないかもしれませんが、より良いアプローチとしては、まず最初の質問により詳細を加えることです。具体的である必要があります：なぜ45分間にわたってAPIコールの3%が失敗したのか？これは、より深く考えるように意図的に表現されています。
100台のホストのうち1台が500エラーを返していました。なぜそのホストは500エラーを返したのでしょうか？以前に調査した分岐に沿って考えると、これはボリュームの問題だということがわかります。しかし、もう1つ考えるべき分岐があります：なぜヘルスチェックは障害が発生したホストをサービスから除外しなかったのでしょうか？ 調査の結果、ヘルスチェックのロジックの設定ミスで、より深いチェックが必要な場所でTCP Health Checkを使用していたことがわかりました。なぜヘルスチェックの設定が間違っていたのでしょうか？これはサービステンプレートの問題で、テンプレート自体に誤りがあったため、すべてのサービスにその設定が展開されていたのです。これは非常に重要な発見でした。
なぜ問題が45分間も続いたのでしょうか？オペレーターは最初の30分間は対応できない状態だったため、何も対処できませんでした。なぜオペレーターは対応できなかったのでしょうか？アラームの設定が5%のエラー率に設定されており、これがSLOと整合していなかったためです。ここでも新たなアクションアイテムが 見つかりました。なぜキャパシティの1%の障害が3%のAPI障害率を引き起こしたのでしょうか？これは少し奇妙です。Load Balancerは Least Connectionsアルゴリズムを使用するように設定されていました。ホストで障害が発生すると、正常時よりも応答が速くなることがあり、Least Connectionsは障害が発生しているホストにより多くの作業を割り当てる傾向があります。これにより、不釣り合いに高い障害率が発生したのです。
なぜLoad BalancerでLeast Connectionsを使用するように設定されていたのでしょうか？これは実は設計上の決定でした。当時、私たちはこれについて検討し、それなりの理由がありました。これは共感の物語の一部です。今では変更を検討するかもしれませんが、当時の設計判断の理由を理解することが重要です。この時点で、外部イベントコミュニケーションの第二幕、つまりRoot Cause Analysis（根本原因分析）の準備が整いました。私たちはこれをRCAと呼んでいますが、AWSではEvent Analysisとも呼んでいます。
RCAを作成する際の原則をいくつか紹介します：まず、 RCAの作成時には顧客視点を重視します。顧客がイベント中に何を経験したのか、どのようにサービスに影響があったのか、私たちのパフォーマンスがどのように影響を受けたのかを、明確に説明することから始めます。 これもまた、品質とスピードのバランスの問題です。必要な詳細をすべて収集するには時間がかかり、完璧な分析を提供するには数ヶ月かかる可能性があります。私たちは適切なバランスを取ることを心がけており、通常は数日で提供するようにしています。私たちの基準は、何が起こったのかを十分に理解し、対応策を完全に把握し、期限付きの高レベルなアクションアイテムに合意できた時点で公開することです。
私たちは不必要な複雑さを積極的に排除するよう努めています。ご想像の通り、AWSは非常に深い層状の依存関係を持つシステムですが、この複雑さをそのまま顧客に投げかけたくはありません。ストーリーラインや顧客の理解に必要な要素を損なわない範囲で、可能な限り抽象化を試みています。技術用語を削除し、できるだけシンプルにするか、顧客が理解している概念に結びつけるよう努めています。例えば、私たちがCellsやサービスの障害を分離するメカニズムについて外部に説明し始めてからは、それが顧客間で共通知識となったため、その用語を積極的に使用するようになりました。そして再度強調しますが、RCAを作成する際には、これが単に 好奇心を満たしたり、イベント中に何が起こったかを説明したりする機会だけではないことを十分認識しています。これは顧客の信頼を取り戻す唯一の機会なのです。私たちは、何が起こったかを完全に理解していること、イベント中の対応について適切に内省を行ったこと、そして同様のイベントの再発を防ぐための適切なアクションアイテムを持っていることを、顧客に確信してもらいたいと考えています。このドキュメントを公開した後は、すべてが計画のフェーズに移ります。
大まかに言って、アクションアイテムには3つのカテゴリーがあります。1つ目は短期的なアイテムで、通常数時間で対応可能なもので、私たちは24時間体制でこれらを実施しています。これらは、Gavinが言及していた、実施されるまでイベントを終了とみなさないアクションアイテムです。一般的に、イベントの即時再発を防ぐことに重点を置いており、運用負荷を大幅に増加させる可能性があります。アラームの感度を上げたり、Runbookを変更したりすることもありますが、これらは短期的な対応としては十分でも、より良い解決策が必要です。
2つ目のカテゴリーは中期的なアクションアイテムです。これらは数日、数週間、あるいは数ヶ月で実施され、より安定した解決策で、多くの場合は完全に自動化された解決策となります。同じトリガーが発生しても、最初に起きたような形でイベントが再発しないようにします。そして3つ目のカテゴリーは長期的なアクションアイテムで、システム全体の変更を推進し、障害の原因を完全に排除するものです。「ハムスターをより速く走らせるだけではいけない」という実際の引用があり、これは長期的なアクションアイテムに取り組む際の考え方を表しています。
長期的なアクションアイテムは2つの力のバランスの上に成り立っています。1つは、私たちのお客様、あなたのお客様、そして依存関係にある方々にとって扱いやすい、段階的な改善を実現することです。もう1つは、イノベーションや再発明を通じてシステム全体の変更を推進することです。これは完全に新しいServiceを構築し、お客様に移行をお願いするようなケースです。現実の世界では、これらのバランスを取ることが重要です。なぜなら、2番目のカテゴリーは往々にして非現実的なタイムラインを持っているからです。システムの古いバージョンと新しいバージョンが並行して存在し、新バージョンの本番リリース時期が不明確なまま、古いバージョンには誰も手を付けたがらない、そんな経験のない人はいないでしょう。新しいものの立ち上げが遠い将来になる場合は、古いバージョンへの対応計画を確実に立てることが重要です。なぜなら、最終的には適切な期間内に障害の再発を防ぐ必要があるからです。
インシデントからの学びを組織全体に展開：AWSの知見共有と製品開発
これらを実施し、適切な計画を立てたら、実際のアイテムの実装に取り掛かります。私たちはいくつかの原則を念頭に置いて実施しています。1つ目は、これらの計画が変更される可能性があることを十分に理解しているということです。初期フェーズはすべて仮説的なものです。テストせずに解決策を定義し、ハイレベルな計画を立てようとしています。実装段階で、より良い方法があることに気付いたり、当初の計画が実際には機能しないことが分かったりすることもあります。私たちは計画に柔軟性を持たせ、新しい情報が入手できた時点で適切な変更を行うことを厭いません。
これを実施する際、ETAを守ることが極めて重要です。簡単なことではありませんが、計画の変更は常に納期を意識して行う必要があります。小さな調整は問題ありません。数ヶ月の期間を要するコミットメントで数日の遅延があっても文句を言う人はいませんが、1ヶ月で完了するはずだったアイテムを数年先に延期することはできません。そして3つ目の原則は、クローズドループに関するものです。イベントを緩和した後、お客様が本当にその緩和策を実感できているかを確認します。繰り返しになりますが、計画を定義している段階では仮説的なもので、その時点で得られる最善の知識に基づいて作業を進めています。その後、コードを書き、Runbookを変更し、プロセスを変更することで実装を行います。その時点で、計画が機能すると確信しています。しかし、修正が機能していることを検証するまでは完了とは見なしません。そのため、Game Dayと呼ばれる検証を実施し、トリガーを再現して、最初に発生したような事象が再発しないことを確認します。
実装が完了したと判断するのは、テストを実施した後に限ります。これまでに立てた前提条件が正しいことを、テストと検証を通じて確認してはじめて完了とみなす、というマインドセットを持つことは非常に重要だと考えています。
第三のフェーズでは、特定のプロダクトを担当する小規模なチーム内でCOE（Correction of Error）を作成した後のアクションアイテムに取り組みます。ここで重要なのは、これらの学びを無駄にせず、AWS全体で活用することです。他の10のチームが同じことを後から学ぶことがないように、組織全体でこれらの知見を展開することを目指しています。
皆さんの中には、AWSが毎週水曜日の朝に2時間かけてAWS全体のオペレーション会議を開催していることをご存知の方もいるかもしれません。この会議には1000人近くが参加しており、一見奇妙に思えるかもしれませんが、非常にコストのかかる会議である一方で、非常に価値のある会議でもあります。個人的に、インシデントを楽しみにしているとは言いたくないのですが、不思議なことに、ある意味そうなのです。なぜなら、これらのインシデントから、そしてこれらのイベント中に注意を払うことで、AWSについてより多くのことを学べるからです。これらのインシデントの際こそ、他のどの時よりもAWSを改善する機会が多いのです。
AWSの上級職の人々が集まる部屋を想像してみてください。月曜日の夜のキーノートをご覧になった方はご存知かもしれませんが、Peter DeSantisやDave Brownもこの会議に参加して意見を述べています。私たちが通常行うのは、組織全体から2、3件の興味深いCOE、つまり誰もが学べるようなものを選んで詳細に検討することです。Principal EngineerやDistinguished Engineerたちが、以前に同様の問題を経験し、他のサービスで実装した解決策を共有することもあります。チーム内だけでCOEを検討する場合には得られないようなレベルのフィードバックを得ることができます。
ここで安全な環境を提供することは非常に重要です。多くの上級職の人々がいる中で、比較的若手のエンジニアがCOEを発表することもあります。実際、私たちのやり方では、若手エンジニアにとってこれは良い機会となっています。安全な環境を作り、発表するエンジニアに対して思いやりを持って接することが重要です。なぜなら、そうしないと、人々が萎縮してしまい、適切な学びを得ることが非常に困難になってしまうからです。
この会議は学びに関するものですが、私たちはどのように学びをスケールさせているのでしょうか？まず一つ目に挙げられるのが、人材教育です。私たちは多くのスタッフの週2時間を投資して、組織の知見を構築し、これらの失敗から学んでいます。通常、これらのミーティングから、あるチームだけでなく、多くのチームが同じ問題を抱えていることが分かった場合、AWS全体でプログラムを実行して、この問題を修正したり、ライブラリをアップグレードしたり、リトライの動作を変更したりする必要があるかもしれません。
これはかなりコストのかかるプロセスなので、できれば避けたいところです。しかし、変更が必要な500のチームにチケットを切り、プログラムマネージャーが3ヶ月かけてそれを確実に実施するというのは、非常に効果的な方法です。私たちが望ましいと考えているのは、集中的な変更を行うことです。この会議の主役は、Builder Tools、Load Balancingプラットフォーム、DNSプラットフォーム、そして他のチームが依存している重要なコンポーネントを担当している人々です。なぜなら、彼らは多くの場合、他のユーザーに影響を与えることなく、全体的な動作を大きく改善できる変更を行うことができるからです。理想的には、パイプラインを通じて全員が近いうちに使用することになるコードの一部を変更するなど、高いレバレッジポイントを見つけて変更を行います。また、組織全体の文化構築と知見の蓄積についても言及しました。
これらはテネット（基本原則）の例です。私たちは実際にテネットを体系化し始めましたが、これらの会話を通じて長年にわたり、頭の中で徐々に形作られてきたものだと思います。AWSの中で特に重要視されているテネットの一つは、皆さんのビジネスには当てはまらないかもしれませんが、AWS全体で「障害が複数のRegionに影響を与えてはならない」ということです。これは私たちにとって非常に重要なテネットであり、この会議でその情報が共有されます。私たちはテネットを体系化し始め、そしてポイントは、私たち全員がこれに同意しているということです。
この会議中にこれについて議論することはありません。なぜなら、私たちは既に理解しているからです。また、私たちは「お客様より先に障害を検知すべき」という別のテネットにも従うことを目指しています。水曜の朝のミーティングでは、これについて議論の余地はありません。水曜の朝に問題を起こして反応を得たいのなら、このテネットに異議を唱えてみるといいでしょう。これは私たち全員が受け入れている周知のテネットです。ミーティングに入る前から、お客様から問題の指摘を受けた場合は、COEにその旨を記載することになっています。
ここで自動化によるスケーリングの例を見てみましょう。Gavinは内部的な分散型の変更について話しましたが、同じ原則の外部向けの解釈としてこのツールも持っています。皆さんもご存知のTrusted Advisorは、アカウント内のアンチパターンや問題があると思われる事項を確認します。ここで関連する2つのカテゴリがあります。1つは「アクション推奨」と呼ばれる赤のカテゴリで、対応が必要だと考えられる場合に表示されます。例えば、多要素認証が設定されていないルートアカウントは、そのような状態を望んでいる可能性は極めて低いため、赤チェックとなります。また、「レビュー推奨」という中間的なカテゴリもあります。例えば、シングルAZのデータベースを検出した場合、そのリソースが意図的にシングルAZなのか、設定ミスなのかを確認するようフラグを立てます。
私たちには豊富な経験があります。皆さんご存知の通り、DNSは非常に複雑です。私たちは独自のコントロールプレーンとデータプレーンを複数バージョン運用していましたが、ある時点でそれらの知見をまとめて、Amazon Route 53というサービスを生み出すことにしました。現在では社内のほぼすべての場所で使用しており、お客様も様々なユースケースで活用しています。 もう一つ同様の例が、ロードバランシングプラットフォームです。私たちは何度も改良を重ね、大規模なロードバランシングインフラの運用で得た長年の知見をすべて集約し、皆さんがご存知のApplication Load BalancerとNetwork Load Balancerという製品を作り上げました。
大規模なTLS証明書のローテーションの複雑さに悩まされたことがない人はいないでしょう。年に一度、証明書を切り替えるためのカレンダーリマインダーを設定している方もいるかもしれません。あるいは、専任のPMがスプレッドシートで全社の証明書ローテーションの進捗を管理するようなプログラムを運用している組織もあるでしょう。私たちにもそういった経験がありました。その後、AWS Certificate Managerの前身となる社内バージョンを経て、最終的にAWS Certificate Managerというサービスを構築しました。これは組織全体の証明書の追跡、確認、ローテーション設定を一元的に管理できる統合的なサービスです。
私の担当分野に近いものの一つに、Zonal shiftというツールがあります。2011年にAWSに入社した時、私たちにはAZから退避するための社内ツールがありました。一連のCOEとイベントの分析を通じて、理想的ではない点がいくつかあることに気付き始め、それを修正したいと考えました。すべてのお客様やサービスをカバーできておらず、迅速にゾーンから退避する機能が不十分でした。改善が必要だと認識する一方で、お客様からもゾーンからの退避方法について質問を受けるようになりました。お客様自身で構築するのが難しい、あるいはコストがかかりすぎるという声があったのです。これらの知見がZonal shiftの開発につながりました。
複数のイベントを通じて、リトライストームが発生するパターンを観察しました。慎重な検討の結果、リトライロジックに大幅な改善の余地があることが分かりました。これらの改善を数年かけてSDKに実装しました。すべてのお客様がこれらのSDKを使用しているため、このようなイベントへの対処が劇的に改善されました。この改善は、全員がイベントを詳しく検証し、何が起きているのかを深く考察した上位レベルの運用会議から生まれたものです。
Zonal shiftをご存じない方のために説明させていただきます。これは、3つのゾーンにトラフィックを振り分け、その背後にデータベースがある可能性のある、シンプルなNetwork Load Balancerのセットアップで動作するツールです。AZ3で問題が発生した場合、Zonal shiftを使用すると1回のAPI呼び出しでトラフィックを迂回させることができます。このツールはすべてのApplication Load BalancerとNetwork Load Balancerで無料で利用可能です。これにより、トラフィックをAZ1とAZ2に振り替えることができ、最大3日間継続できます。インシデントの調査中や、そのゾーンでのデプロイメント中に数時間使用することもあります。私たちも社内で広く使用しており、以前の古いツールの大部分を置き換えています。
SDKのリトライに関する私の失敗談をお話しさせていただきます。私がAmazonに入社した当時、コードにおけるリトライの概念についてあまり深く考えておらず、エラー処理も適切に行っていませんでした。最初に書いたコードではAPIを1回だけ呼び出すようにしていて、1万回実行すると99.9%は成功しましたが、残りの場合はチケットを発生させる厄介な失敗となっていました。 最初にリトライロジックを実装した際は、推奨されていない即時リトライのパターンを使用していました。失敗するとすぐにリトライを試み、サービスに対して急激な連続アクセスを行うことになります。これが1万のクライアントで同時に実行されることを考えると、問題が明らかになります。
次のバージョンではリトライの間にスリープを入れるようにしました。これは改善されましたが、まだ理想的ではありませんでした。 5秒から10秒の間に、より多くのクライアントがリトライモードに入ると、問題のあるサービスへの負荷が指数関数的に増加してしまいました。これが、広く知られている指数関数的バックオフという手法につながりました。1秒後、2秒後、4秒後、8秒後というように、徐々に遅くなっていくリトライです。 しかし、これでもまだ十分ではありませんでした。クライアントが失敗した瞬間から同期してリトライすることに気づきました - 全員が1秒後、2秒後、4秒後にリトライするのです。そこで、リトライをばらつかせるためにJitterを導入し、できるだけ優しくアクセスするようにしましたが、これでもまだ最適ではありませんでした。
Corrections of Errorプロセスとイベント分析を通じて、私たちはAdaptive Retryを開発しました。このアプローチでは、許可されたリトライの予算を管理し、リトライが成功した場合にのみその予算を補充します。リトライが失敗した場合は、プールを補充しません。これにより、リトライが成功していない場合に不要な負荷の増加を防ぎ、struggling中のサービスへの負荷を抑制します。通常の負荷は継続して送信しますが、サービスの障害による負荷の膨張を防ぎ、より容易な回復を可能にします。 このトピックについてより詳しく知りたい方は（私が簡単にしか触れていませんが）、Mark Brookerがre:Inventで講演を行います。ただし、どの日かは覚えていません。
現在、このAdaptive Retryの仕組みはAWS SDKに組み込まれているので、SDKを使用している方は既により優しいアクセスを行っています。SDKをアップグレードして、Adaptive Retryを有効にしてください。
インシデント対応の重要ポイント：AWSの経験から得た教訓
今日、この会場を出る際に覚えておいていただきたいことがいくつかあります。 Tech Callに関する最初の重要なポイントは、組織全体で「参加することは良いことだ」という合意があるということです。迅速に人々を通話に参加させることは問題なく、リーダーやVPがページングを受けることも問題ありません。もしあなたが組織のリーダーであれば、ページングを受けることを厭わず、深夜2時の通話で不機嫌にならないことが重要です。追加の支援を求めてページングした人々に感謝を示してください。これにより、人々は罰せられるのではなく、むしろ追加の支援を求めることが奨励され、復旧時間に大きな影響を与えます。
2つ目のポイントは、何か問題が発生していると確信を持った時点で、できるだけ早くコミュニケーションを取ることをお勧めします。まずはお客様に通知を出すことを心がけてください。詳細な情報は後から追加で提供することができますが、確信が持てた時点で最初の通知を出すようにしましょう。 また先ほど触れましたが、エンジニアは根本原因の究明に夢中になりがちです。これらのCallでは規律を持って、まず影響緩和を優先することが重要です。根本原因の究明は後回しになるかもしれませんが、Mitigationが最優先なのです。
次のポイントは、教訓を一度だけで終わらせないことです。あるチームが何か間違いを犯して学んだとしても、その学びを単一のチームだけにとどめてしまうのは大きな過ちです。組織全体で学びを共有し、インシデントに直接関わっていないチームでもそのような問題を予防できるようにすることが非常に重要で、実際の運用も大幅に改善されます。 また、これらのインシデントを振り返る際は共感を持って検証することについても話しました。これには2つの側面があります。1つは、困難な判断を迫られた関係者に対して、思いやりを持って人道的に接することです。もう1つは、設計時とインシデント発生時の両方において、なぜその判断が下されたのか、どのような情報があったのか、なかったのかを理解するという意味での共感です。
最後のポイントは、Tenetsを共有することです。組織全体が従うべき、簡潔で明確なルールや原則を少数定めることが重要です。これには2つの利点があります。1つ目は覚えやすいということで、新人エンジニアが初日に学んで永久に記憶に留めることができます。2つ目は、密接に協力していないチームでも同じ方向に進めるよう、判断の基準として役立つということです。何が正しい選択なのか迷った時に、定められたTenetsを参照することで、全員の進むべき道を示すことができます。
ご参加ありがとうございました。この後、会場の後方で質問を受け付けています。別会場でご覧の方や、オンデマンドで後日ご覧になっている方は、フォローアップの質問やディスカッションがございましたら、お気軽にメールでお問い合わせください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion