re:Invent 2023: VanguardがAWSレジリエンスライフサイクルで実現した運用改善
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Resilience lifecycle: A mental model for resilience on AWS (ARC312)
この動画では、AWSのPrincipal TechnologistであるClark Richeyと、VanguardのStacey BrownとYoni Ryabinskiが、AWSレジリエンスライフサイクルについて解説します。7兆ドル以上の運用資産を持つVanguardが、レジリエンシー向上のために行った具体的な取り組みを紹介。PTaaSやカオスエンジニアリングツールの開発、SREプラクティスの導入など、独自の施策によってインシデントを30%削減しながらデリバリーを5倍に増やした実例を学べます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
レジリエンスの重要性とAWSのアプローチ
こんにちは。皆さん、お集まりいただきありがとうございます。まず簡単な質問から始めたいと思います。この中で、組織のアプリケーションの開発、管理、保守を担当されている方で、そのアプリが停止すると組織に影響を与え、問題を引き起こす可能性がある方は何人いらっしゃいますか？はい、わかりました。では、手を挙げた方の中で、レジリエンスに必要なすべてのアクションを完全に把握していて、ライフサイクルのどこに当てはまるか、何に取り組む必要があるかを理解している方は何人いらっしゃいますか？ほとんど手が挙がっていませんね。それは良いことです。つまり、皆さんは適切なセッションに参加されているということです。
私はClark Richeyと申します。AWSのPrincipal Technologistを務めています。今日はVanguardのStacey BrownとYoni Ryabinskiと一緒に、先ほど触れた問題の解決に役立つであろうAWSレジリエンスライフサイクルについてお話しします。レジリエンスイコール収益です。これはGartnerが述べた大胆な主張ですが、事実です。世界で最もクールなアプリケーションをデプロイしたとしても、それがダウンしてしまえば意味がありません。それは会社にとって損失を意味します。
IDCの推計によると、Fortune 1000企業は計画外のダウンタイムにより、毎年15億から25億ドルの収益を失っているとのことです。これは相当な金額です。さらに、測定が難しい他のコストもあります。それは事業の評判への影響という目に見えないコストです。一度アプリケーションがダウンして顧客との信頼関係が損なわれると、それを修復するのは非常に困難で、その影響は長期間続く可能性があります。
AWSの共有責任モデルとレジリエンスライフサイクル
AWSと話をしたことがある方なら、このような図を見たことがあるでしょう。AWSでは共有責任モデルを重視しており、もちろんレジリエンスにも共有責任モデルがあります。それは本質的に2つの基本的なことに集約されます。AWSは「クラウドのレジリエンス」に責任を持ちます。これはどういう意味でしょうか？つまり、クラウドでアプリケーションを構築するために必要なすべてのサービスとインフラストラクチャのレジリエンスを確保する責任があるということです。これには、AWSのリージョンやアベイラビリティーゾーン、さらにはOutpostsやエッジロケーションなど、すべてがグローバルインフラストラクチャ上で動作しています。ネットワーキング、サーバー、ストレージ、さらにはアプリケーション構築に使用するAWSサービスなども含まれます。
一方、お客様は「クラウドにおけるレジリエンス」に責任を持ちます。これはどういう意味でしょうか？アーキテクチャの設計方法、ネットワーキングの管理方法、サービスクォータの管理方法、さらにはコードのデプロイ方法や本番環境で発生する可能性のある障害やその他のイベントの管理方法など、重要な選択をするのはお客様の責任です。データを安全にバックアップする方法も含めて、クラウド上でレジリエントな方法で構築することはすべてお客様の責任です。
今日は、AWSで長年にわたって構築してきたベストプラクティスに基づいて、クラウドでレジリエントなアーキテクチャを構築するために、ビジネスに適した決定を下せるよう、さまざまな活動について説明していきます。さらに良いことに、StaceyとYoniが登壇して、Vanguardでどのように実践しているかを紹介します。これこそが皆さんが本当に聞きたいことだと思います。
クラウド移行の利点と分散システムの課題
クラウドにアプリケーションを移行することには、確かに多くの利点があります。だからこそ私たちはそうするのです。既存のAWSサービスを活用することで、差別化されていない重労働の多くを取り除くことができ、より俊敏に開発やイノベーションを行うことができます。また、クラウドに存在する規模の経済を活用することで、自前のインフラを運用するよりもコストを削減できます。これらは素晴らしいことですが、人生の他のすべてと同様に、欠点や課題もあります。
分散システムは複雑で難しいものです。現代では、もちろんあらゆるものに標準がありますが、現実には常に標準の実装にはバリエーションがあることは皆さんご存知でしょう。クラウド全体に多数、おそらく何千ものコンピューターがある場合、可観測性の確保が極めて重要になります。
分散システムにおける可観測性の確保は非常に難しい課題です。複数のコンポーネントにまたがる、場合によっては多数のマシン上で、アプリケーションの適切な状態と重要な側面を監視する必要があります。また、システム内で発生するあらゆるイベントの下流および上流への影響を管理しなければなりません。
この複雑さのレベルは、分散システムにおける障害予測をはるかに困難にします。 分散システムの非常に単純化された例を見てみましょう。1つのクライアントが1つのサーバーに1つのメッセージを送信し、応答を得るという基本的なシナリオでさえ、複数の潜在的な障害ポイントがあることがわかります。クライアントがコードを正しく実行しない可能性や、間違ったコードがダウンロードされる可能性があります。ネットワークは途中のどこかで障害が発生する可能性があります。サーバーが致命的な障害を起こす可能性もあれば、設定変更を誤ったり、不具合のあるバージョンのコードをデプロイしたりする可能性もあります。
さて、実際の本番環境に近い、もっと複雑なシステムで10,000件のメッセージが一度に発生したらどうなるでしょうか。この複雑さは本当に難しい課題です。この話題に関する素晴らしい論文を私たちが書いていますので、分散システムの課題とその複雑さについてもっと詳しく知りたい方は、画面に表示されているQRコードからアクセスしてみてください。
AWSレジリエンスライフサイクルの概要
AWSでは、お客様からレジリエンスの向上についてよく質問を受けます。私たちは大規模な運用の課題を理解しているからこそ、AWS Resilience Lifecycle White Paperを開発しました。レジリエンスは目的地ではなく旅であり、一度達成して終わりというものではなく、継続的なプロセスであることを理解することが重要です。
ライフサイクルの各フェーズに入る前に、基盤的レジリエンスと継続的レジリエンスという2つの主要な概念について説明しましょう。基盤的レジリエンスとは、レジリエントなアーキテクチャを構築するための主要なサービスとガイドラインを指します。これには、アプリケーション用の高度にレジリエントなデータベースを構築するためのAurora マルチAZクラスターなどのAWSサービスが含まれます。 もう1つの例はAWS Resilience Hubで、これについては後ほど詳しく説明します。
基盤的レジリエンスには、基本的なガイドラインも含まれます。特に重要なのはAWS Well-Architected Frameworkです。このフレームワークには、レジリエントなシステムを構築するためのベストプラクティスと、AWSサービスを効果的に使用するためのガイダンスを提供する信頼性の柱が含まれています。一方、継続的レジリエンスは、レジリエントな運用を確保するために使用される組織の人、プロセス、システムに焦点を当てています。クラウド上でシステムのレジリエンスを維持するために、どのようにモニタリング、管理、観察、対応するかということです。
レジリエンスのライフサイクルは、目標設定、設計と実装、対応と学習、評価とテスト、運用の5つのフェーズで構成されています。これらの各フェーズについて、関連する活動と、各フェーズをサポートするAWSの基盤サービスについて説明します。各フェーズのポイントをいくつか紹介しますが、より詳細な情報については、ぜひホワイトペーパーを参照してください。
レジリエンスライフサイクルの実践と目標設定の重要性
レジリエンスのライフサイクル図は、皆さんにとって見覚えのあるものだと思います。典型的なソフトウェア開発ライフサイクルの図に似ていますが、これは意図的なものです。私たちは、これが皆さんの既存のプロセスと関連付けやすく、認識しやすいものであってほしいと考えています。実際、皆さんの組織で既に似たようなものが運用されているかもしれません。
レジリエンスのライフサイクルは、皆さんが理解しやすく、馴染みやすく、既存の開発プラクティスに簡単に統合できるものである必要があります。そのため、このライフサイクルは常に「目標設定」のフェーズから始めることが重要です。全く新しいアプリケーション、いわゆるグリーンフィールド開発の場合は、目標設定から始めるのが直感的で簡単です。しかし、既存のアプリケーションを運用していて、このライフサイクルの概念を適用したいと考えた場合でも、目標設定から始めることを強くお勧めします。その理由については、後ほど詳しくお話しします。
このライフサイクルを繰り返し進めていく中で、各フェーズの出力から得られた知見を目標設定に反映させ、目標を継続的に改善・評価し、その時々のビジネスニーズに適した取り組みを行っているかを確認します。ご覧のように、各ライフサイクルには多くのアクティビティがあります。 約束通り、それぞれについて詳しく説明しますが、全てのアクティビティは各フェーズで重要な成果を生み出し、組織や個々のアプリケーションにとってのレジリエンスの優先順位を特定するのに役立ちます。結果として、より良い運用プラクティスが得られ、既存の緩和策の状態や、失敗から学ぶ能力、そしてそれらを改善する方法について理解が深まることが期待できます。なぜなら、これは常に改善の旅だからです。
いくつかの重要なポイントがあります。まず、これは反復的なプロセスです。このライフサイクルを何度も何度も繰り返していきます。チームの規模によっては、チームの異なるメンバーが同時に異なるステージにいる可能性もあります。例えば、次のリリースのために設計・実装を行っているメンバーもいれば、現行リリースの運用を担当しているメンバーもいるかもしれません。これは全く普通のことです。また、各フェーズで同じレベルの成熟度を持つ必要も、必ずしもないでしょう。これは組織のニーズに基づいて評価し、必要に応じて時間をかけて成長させていくべきものです。
実際、ホワイトペーパーで紹介するプラクティスの全てを、全てのアプリケーションに対して実装することはないでしょう。おそらく必要ないでしょう。重要なのは、どのプラクティスが必要か、それらがエンジニアリングプラクティスにどう適合するか、そして最も重要なのは、それらがレジリエンスに関するビジネス目標の達成にどう役立つかを理解することです。さて、各ステップでのプラクティスについてお話しすると約束しましたので、それに入りましょう。目標設定です。 私にとって、これが最も重要なフェーズです。これは、アプリケーションのレジリエンスに関して、ビジネスが何を必要としているかを理解することに全てがかかっています。これが分からなければ、他のどこにも進むことはできません。
具体的な目標設定とRPO/RTOの重要性
お客様からよくこんな質問を受けます。こんな会話になるんです。「クラーク、もっとレジリエントになる方法を教えてほしい」と言われます。「いいですね、お手伝いできますよ。目標は何ですか？」と私が聞くと、「もっと」と返ってきます。「なるほど、もっとですね。でも、どのくらいもっとですか？何を達成したいんですか？」と聞くと、「より良く」と。まあ、確かに、それも一つの出発点ではあります。でも、これって私にロードトリップに誘われて、「クラーク、私が運転するから、どこかに行きたいんだ。道順を教えて」と言われているようなものです。「いいですね、どこに行きたいんですか？」と聞くと、「ここじゃない」と。方向は示せますが、それが正しいのか間違っているのか、誰にも分かりません。目的地を知らないと始まらないんです。レジリエンスも同じです。目標が必要なんです。
具体的な目標が必要です。よく話題に上がる指標は、RPO（Recovery Point Objective：目標復旧地点）とRTO（Recovery Time Objective：目標復旧時間）です。RPOは、何らかの障害が発生した場合に、潜在的にどれだけのデータを失う可能性があるかを指します。5分分のデータ、10分分、1時間分？これは自分で決める必要があります。RTOは、基本的にどれくらいの時間ダウンしても大丈夫かということです。何か壊滅的なことが起きた場合、ビジネスに重大な影響（財務的影響やブランドへの影響など）が出始めるまでにどれくらいダウンしても大丈夫でしょうか？これが2つの重要な指標で、今日は何度も触れることになります。
多くのお客様、特に何百何千ものアプリケーションを持つ大規模なお客様の場合、すべてのアプリケーションにRPOとRTOを設定するのは扱いきれなくなります。そこで、階層を作ります。ゴールド、シルバー、プラチナとか、1、2、3とか呼び方は何でもいいです。要は、いくつかの異なる階層を設定するということです。
これらの階層には、明確に定義された指標、RPO、RTO、場合によってはSLO（Service Level Objective：サービスレベル目標）やSLA（Service Level Agreement：サービスレベル合意）が設定されます。そして、アプリケーションをこれら3つか4つの階層のいずれかに分類します。これにより、すべてのアプリケーションに異なる指標を設定する代わりに、組織のレジリエンスを管理しやすくなります。多くのアプリケーションをお持ちの場合は、このような優先順位付けと階層化のアプローチを内部で検討してみてください。
設計・実装からテストまでのレジリエンス向上プロセス
このスライドまたはその変形を何度か目にすることになります。ここで、各段階で適用可能で利用できる基盤サービスを指摘します。目立つのは、「目標の設定」には何もないことです。なぜなら、目標の設定はビジネス運営の一部だからです。これは、あるアプリケーションが特定の方法で失敗した場合のビジネスへの影響を本当に理解し、分析するプロセスなのです。データ側はどうでしょうか？どれくらいの時間ダウンしても大丈夫ですか？その影響は？これは内部のビジネス演習です。これを手助けする魔法のサービスはありません。すべてが内部の仕組みに関わることなのです。
さて、設計と実装に移りましょう。ここには多くの活動があります。目標を設定したので、今度はそのレジリエンス目標を達成しつつ、アプリケーションが果たすべき他のすべての目的も満たすようにシステムを設計・実装していきます。ここでは、アーキテクチャに関して多くの重要な決定を下す必要があります。障害分離境界はどうするか。EC2のようなAWSのゾーンサービスを使ってアプリケーションをデプロイする必要があるか。その場合、単一のAvailability Zoneで十分なレジリエンスを確保できるか。それとも、より高い可用性が必要で、複数のAvailability Zoneにまたがってデプロイしたいか。極めて高い可用性が必要で、複数のリージョンにまたがる必要があるか。これらの決定を下さなければなりません。これらすべてにはトレードオフがあります。
どのような基盤サービスやガイドラインを使用して構築するか。例えば、Aurora Multi-AZクラスターを使用するか、それとも別のものを使用するか。コストやレジリエンス、エンジニアリングの面でどのような影響があるか。コードのデプロイや統合をどのように行うか。ロギングについてはどのような選択をするか。CloudWatchを使用するか、それとも別のものを使用するか。後でイベントが発生した場合に簡単に読めるよう、ログをどのようにフォーマットするか。これらすべてを目標に照らして十分に検討する必要があります。もちろん、これらに立ち返り、学び、そして必要に応じて変更を加えていくことになります。
設計と実装の段階では、多くのサービスが関わってきます。隣の空欄を埋めるかのように、たくさんあります。ここでいくつか特筆すべきものを挙げましょう。AWS Resilience Hub。素晴らしいので、二度書きました。これは素晴らしいサービスで、インフラストラクチャを取り込み、CloudFormationテンプレートやTerraform、あるいはタグ付けなどを使用して既存のデプロイされたリソースを扱うことができます。そしてツール内でレジリエンスポリシーを作成できます。もちろん、RPOとRTOを定義します。そしてそのポリシーをアプリケーションに割り当てます。すると、Resilience Hubが評価を実行し、インフラストラクチャを分析して、現在の構成でそのレジリエンス目標を達成できるかどうかを判断します。
達成できない場合は、ヒントや修正方法を提供してくれます。なぜ目標に到達できないのかを教えてくれます。また、CloudWatchアラームを構築するためのコードスニペットや、カオスエンジニアリングテストを構築するためのFault Injection Simulatorテンプレートなど、役立つものも提供してくれます。つまり、これは目標を達成するのに適したインフラストラクチャかどうかを早い段階から判断するのに役立つ、非常に優れたツールです。もちろん、AWS Well-Architected Frameworkとそのレジリエンスの柱は、先ほど話したベストプラクティスを実装するための基本的なガイドラインを提供します。
また、AWS X-Rayのようなものもあります。アプリケーション内でトレーシングを行い、重要なイベントやデータの移動などを監視したい場合、設計・実装段階でAWSトレーシングを導入できます。最後に挙げたいのはAWS Trusted Advisorです。これは、エンタープライズサポートを利用している人なら誰でも利用できる優れたサービスです。Trusted Advisorには何千ものベストプラクティスチェックが含まれており、システムを継続的に評価し、セキュリティやレジリエンスなどのベストプラクティスに従っていない領域を見つけ出します。
そして、それらの問題を浮き彫りにして注意を喚起することができます。また、修正のためのヒントを提供することで、問題を解決できます。あるいは、意識的にそのリスクを受け入れ、トレードオフを行って先に進むという判断もできます。
運用フェーズにおけるレジリエンス強化の取り組み
評価とテストは、アプリケーションの2つの異なる段階で行われます。1つは、実際にコードを本番環境にデプロイする前の「デプロイ前」の段階です。もう1つは、その後も継続して行われる「デプロイ後」の段階です。デプロイ前には、皆さんユニットテストや統合テストを行っていることと思います。2023年の今では、それはほぼ当たり前のことだと言えるでしょう。しかし、他の形式のテストも存在します。例えば、アプリケーションがパフォーマンスに敏感な場合はどうでしょうか？顧客が特定の応答時間を期待している場合はどうでしょうか？そのような場合、選択したインフラ、アーキテクチャの決定、実際のコードの組み合わせが、期待される時間内に適切に応答するかを確認するために、パフォーマンスベンチマークを行う必要があるかもしれません。
そして、負荷がかかった状態でもそれらは適切に機能するでしょうか？古典的な負荷テストとして、本番環境にデプロイして、顧客が使用している間に問題が発生したら対応する、というアプローチがあります。しかし、これはお勧めできません。そのため、事前に負荷テストを行うことをお勧めします。Fault injectionやGame daysは、カオスエンジニアリングの概念です。カオスエンジニアリングとは、システムの回復力を徹底的にテストするという考え方です。ここで言うシステムとは、技術的な部分だけでなく、人々とプロセスも含みます。つまり、継続的な回復力のことです。イベントに対応し、システムを管理するために使用する人々とプロセスのことです。
そこで、特定のタイプの障害が発生した場合にシステムがどのように反応するかについて、仮説を立てます。例えば、ネットワーク障害や、サーバーがダウンする、データが破損するなどの状況を想定します。そして、システムがそれにどのように対応するか、インシデントをどのように検出するか、どのように対応するか、システムの動作がどうなるか、そこからどのように回復するかを予測します。その後、テストを実行します。これらのテストは、コードがまだホワイトボード上にあり、キーボードにも触れていない段階で、机上演習として行うこともできます。これは本番環境に入る前の段階で非常に有用です。
または、AWS Fault Injection Simulatorのようなツールを使用して、実際の環境で障害をシミュレートし、何が起こるかを確認することもできます。そして当然ながら、その結果から学びます。何がうまくいき、何がうまくいかなかったかを分析します。そして、トレーシングについてですが、トレーシングが評価とテストの段階と、設計と実装の段階の両方に登場していることにお気づきかもしれません。これは意図的なものです。今日ここでいくつか見ていただきますし、ホワイトペーパーでもさらに多くの例を見ることができますが、複数のフェーズに登場するアクティビティがいくつかあります。そしてそれには十分な理由があります。
設計と実装の段階では、様々な選択をしました。その一つが、トレーシングが必要かどうかということでした。後々、アプリケーションでイベントが発生し、システムの管理やモニタリングを行う際に、そのレベルの詳細が必要になると思われる場合は、早い段階で選択し、コードに実装する必要があります。そうしておけば、評価とテストの段階で、その情報を使ってシステムの現在の健全性を評価し、それに基づいて判断を下すことができます。トレーシングは上手く機能しているか？多すぎないか？足りないか？
AWS Trusted Advisorは引き続き利用可能です。AWS Resilience Hubも非常に優れています。先ほど説明したすべての機能に加えて、自動化された形で実行してくれます。定期的に実行するようスケジュールを組んだり、コードのデプロイサイクルと連携させて、コードをデプロイするたびに実行したりすることができます。さらに、ドリフト検出機能も備わっています。つまり、環境に何か変更が加えられた場合、例えばCI/CDプロセスのような通常のインフラ進化プロセスの一環としてインフラに変更が加えられた場合や、誰かが単に変更を加えた場合、その変更を検知すると自動的に再評価を行います。
そして、その変更がアプリケーションのレジリエンスポリシーで定義されたRPOとRTOを満たす能力に悪影響を与えた場合、すぐに関係者に通知を開始します。これは非常に優れた機能です。もちろん、AWS X-Rayもここに登場しています。先ほど、なぜこれが重要かについて説明しました。AWS Fault Injection Simulatorは、カオスエンジニアリングテストを実行するためのツールで、ネットワークの障害やEC2サーバーの損失などをシミュレートしたい場合に使用します。
対応と学習：イベント管理とCorrection of Errors
Operateフェーズです。つまり、本番環境で稼働している状態です。 システムが稼働中には、確かに多くのタスクがあります。合成トラフィックは、問題が発生しそうな状況を事前に検知するための非常に優れたツールです。合成トラフィックの考え方は、本番環境で定期的にテストを実行し、安全な方法でユーザーの行動をシミュレートすることです。金融機関を運営している場合、実際に人々の口座からお金を引き出すわけではありません。代わりに、エンドユーザーの視点から見て、フロントエンドからサーバーやデータに至るまでの重要な機能がすべて、顧客が期待する時間内に、期待通りに反応し応答しているかを確認するために、主要なAPIにアクセスします。これにより、多くの場合、何か問題が発生し始めた際の最も早い警告を得ることができます。顧客から実際に電話がかかってくる前に警告を受けられるのです。
アラームについて言えば、全員が自分の役割を理解していることを確認する必要があります。アラームが鳴ったらどうするのか？顧客から「システムがダウンしている」という連絡が来る前に、アラームは鳴ったのでしょうか？残念ながら、必ずしもそうとは限りません。アラームが多すぎることはないでしょうか？時には、アラームが多すぎて、対応する能力がほとんどない場合もあります。設定が敏感すぎて、システムの正常な変動に対してもアラームが鳴ってしまい、誤報が発生することもあります。どのようなアラームがあり、それにどう対応するかを常に評価する必要があります。ここでも負荷テストが重要になる場合があります。また、運用プラクティスにおいて適切なことを継続して行っているかを確認するための運用レビューも重要です。
AWS Health Dashboardは、すべてのAWSサービスの状態と報告されたイベントを各リージョンで確認できる便利なツールです。アカウントにログインしてからダッシュボードにアクセスすると、実際に利用しているサービスだけに焦点を当てた見やすいビューが表示されます。これにより、本当に必要な情報に集中できます。さらに、Health APIを使用してプログラム的にアクセスすることもできますし、EventBridgeを使用して関連するヘルスイベントが発生した際にほぼリアルタイムで通知を受け取ることも可能です。
Amazon CloudWatchを使用してログを管理している場合、イベントが発生したときにログを開いて確認するのは一つの方法です。他のツールを使用してこれらのログを読み取ることもできますし、CloudWatch Insightsを使用してより詳細にログを検索することも可能です。さらに高度な検索機能が必要な場合は、ログをAmazon OpenSearch Serviceに送信することもできます。
対応と学習について。 システムには必ずイベントが発生します。レジリエンスとは、イベントの発生を防ぐことではなく、イベントが発生しても運用を継続できることを確保することです。イベントが発生しても、システムが大きく損なわれないか、まったく損なわれないか、あるいはむしろ対応できるかどうかが重要です。そして、これらのイベントにどのように対応するかも重要です。私たちは自動化を強く推奨しています。特定の種類の障害が発生したときに、それを識別し、ボタンをクリックするだけで修復手順を自動化できるような自動修復の仕組みを設定できれば、それは素晴らしいベストプラクティスです。これにより、実際の修復にかかる時間を短縮し、修復プロセスでの人為的ミスの可能性を減らすことができます。ただし、トレードオフもあります。実装が難しい場合もありますし、少し高価になる可能性もあります。そのため、これらのトレードオフを評価する必要があります。
イベント管理とエスカレーションについて。アラームが鳴り、問題が発生し始めたとき、誰が対応するのかを把握していますか？これがTier 1サポートの範囲を超えていて、エスカレーションが必要だと認識すべき時点はいつですか？エスカレーション先を全員が把握しており、その後何が起こるのかを理解していますか？9,000人もの人々がチャットルームで互いに叫び合うような状況にならずに、全員が明確にコミュニケーションを取れるようにイベントを管理するにはどうすればよいでしょうか？そのような状況は対応を大幅に遅らせる可能性があります。したがって、イベント管理のコミュニケーションを明確にすることが重要です。
ここで、Correction of Errorsについて少し触れたいと思います。これは、AWSで私たちが非常に重視していることで、社内でも常に実践しています。これは、イベントが発生したときに、関係者、エンジニア、事業部門など、関係するすべての人々が集まり、非難を避けて何が起こったかを検証することです。非難を避けることが重要です。その理由は次の通りです。
何かが起こりました。私たちはそれを乗り越え、修正しました。良い仕事をしたかもしれませんし、そうでなかったかもしれません。でも、今はもうその段階を過ぎています。もちろん、私たちが望むのは、それが二度と起こらないようにすることです。そのため、何が起こったのかを非常に正直に評価する必要があります。多くの場合、システムがダウンするのは誰かがミスをしたからです。1年ほど前に起きた大規模なFacebookの障害を覚えている人も多いでしょう。たった2回のキーストロークのミスで、数日間ダウンしてしまいました。こういうことは起こり得るのです。誰にでも起こり得ます。AWSでも同じようなことが起きています。
ここで重要なのは、「なぜそんなことをしたの？それは間違っていた」というようなことに焦点を当てないことです。それは役に立ちません。誰がやったかを皆が知っていても、その人が修正作業に参加していたとしても、それは何の解決にもなりません。代わりに理解しなければならないのは、私たちのシステムのどこに問題があったのか、プロセスがどのように彼らを失敗させたのか、なぜそのスクリプトを実行できてしまったのかということです。そのようなことが起こらないようにすべきだったのです。そのエラーが二度と起こらないように、誰もそのミスを繰り返せないように、プロセスをどのように修正できるでしょうか。これが健全な状態になる方法です。ですので、これは非常に重要なプロセスです。correction of errorsについて調査し、実施することを強くお勧めします。
AWSには、このようなプロセスを深く掘り下げるいくつかの他のプログラムもあります。 そして、もちろん、これらを支援するサービスも提供しています。AWS ConfigやAWS Systems Managerは、先ほど話した修正作業の一部を自動化するのに役立ちます。 そして、Route 53 Application Recovery Controller（略してARCと呼んでいます）は、まだ使ったことがない方にはぜひ調査をお勧めしたい素晴らしいツールです。これは基本的に、問題が発生し始めたときに、Availability ZoneやRegionなどの障害分離ゾーンからトラフィックを切り離すための、非常に信頼性の高いデータプレーンベースの操作を提供します。
さて、ここでStaceyとYoniに登場してもらい、Vanguardがこれらのコンセプトを活用してレジリエンスを向上させた実際の情報をお話しいただきます。Stacey、Yoni、お願いします。
Vanguardのレジリエンス戦略：背景と課題
ありがとうございます、Clark。こんにちは。Yoniとわたしはレジリエンスについてお話しできることをとてもうれしく思います。これは私たち二人にとって非常に大切なテーマです。私たちは現在、Vanguardで Technology Resiliency Organizationを率いており、ここ数年そのポジションにいます。しかし、始める前に、Vanguardについて少しお話しし、 レジリエンスがなぜそれほど重要なのかについて背景を説明させてください。
Vanguardは、世界中に5000万人以上の投資家を持つグローバルな投資運用会社です。投資家の皆様から信頼を寄せていただいている運用資産は7兆ドルを超えています。世界中に2万人のクルー（社内での呼び方です）がおり、18のグローバル拠点を展開しています。その中で、物理的な支店は持たずにデジタル企業として運営しています。Vanguardの核となるミッションは、すべての投資家のために立ち上がり、公平に扱い、投資成功の最高のチャンスを提供することです。
お客様にとってダウンタイムがゼロであることは非常に重要です。これは、資産を託してくださるお客様のためだけでなく、過去のような緊急対応ではなく、お客様向けの機能開発に集中する必要がある私たちのエンジニアにとっても極めて重要です。私たちは大規模で複雑なITシステムを運用しています。
Staceyが言及したように、私たちは数十年にわたってITを行ってきました。 現在、複数のクラウド環境で運用しており、各クラウド環境では様々な理由で複数のリージョンにデプロイしています。その理由の一部は地理的な近接性であり、一部は回復力のためです。オンプレミスでも複数のデータセンターを運用しています。そして、グローバル企業として、あらゆる地域に拠点を持つグローバルなプレゼンスを維持しています。
2015年に、私たちはパブリッククラウド戦略を採用し、 それ以来その方針を続けています。現在、ミッションクリティカルなアプリケーションの大半がパブリッククラウドで稼働しています。 私たちは非常に強力なモダナイゼーションのアジェンダを採用し、今日でもそれを成功裏に実行しています。完全にモダン化されるまでには、まだ数年かかると思います。
これにより、私たちにとって非常に複雑な環境が生まれました。レガシーなサービス、非常にモダンなサービス、そしてその中間のすべてが存在しています。その結果、複雑な環境が生まれ、 不安定さを引き起こし、お客様の体験を低下させることになりました。
Vanguardのレジリエンス向上への具体的な取り組み
では、私たちは何をしようとしていたのでしょうか？まず、社内外のクライアントにとってダウンタイムは許容できないものだと言いました。私たちは常にレジリエンシーに焦点を当ててきました。レジリエンシーの改善は進んでいましたが、それはサイロ化された形で行われていました。製品レベル、チームレベル、そして組織全体で個別に行われていたのです。それらは非常に反応的でした。私たちは何が起こったかに注目し、それらのサイロ内で個々の問題を修正することに集中していました。
この変革の時期に私たちが必要としたのは、さらに力を入れることでした。ライフサイクル全体を通じてすべてのチームを結集し、プロセス間のフィードバックループを確保することで、持続可能な企業全体の組織を作る必要がありました。私たちは、人、プロセス、そして私たちの規模の組織がこれを実行し、エラーから学ぶために必要な技術やシステムに焦点を当てていました。
これを実現するために、私たちはアーキテクチャオフィス、エンジニアリングオフィス、プロダクションアシュアランス、そしてオペレーションチームを集結させました。これにより、組織の視点からエンドツーエンドのライフサイクルを本当に見ることができ、クロスファンクショナルチームとして集まり、学びを共有し、ライフサイクル全体を通じて継続的に改善することができました。ここで私たちが言っていることは、Clarkが AWS のホワイトペーパーでレジリエンシー組織について述べていることと非常に密接に一致していることがわかります。私たちは少し前から始めましたが、ご覧の通り、ライフサイクルは焦点を当てるべき部分と非常によく似ており、全体的な基準を定義し設定しています。
ステップ1は組織を作ることでしたが、オペレーティングモデルにも焦点を当てる必要がありました。どのように運営していくのか？対応と学習、そしてライフサイクル全体を通じてフィードバックループが機能し続けることをどのように確保するのか？私たちは、反応的な消火モードから脱却する必要がありました。これは私たち全員が本当に得意になったものです。そして、ここにいる皆さんもそういう状況を経験したことがあると思いますが、私たちはそこから脱却する必要がありました。より良くなることに焦点を当てるために、プロアクティブな状態に移行する必要がありました。そして最終的には、それを根付かせる必要がありました。これは難しいことです。なぜなら、変革している最中にこれを行っているからです。つまり、プロアクティブな状態に移行しようとしている間も、実際には環境全体で発生している問題に対応し続けているのです。だから、時間と集中力が必要なのです。
私たちは、適切なレジリエンシーの基準とパターン、そして目標を設定することに焦点を当てました。それを見直す中で、いくつかの変更が必要でした。適切な方向性を設定し、アーキテクチャの設計とパターンがそれらの基準に合致しているかを確認する必要がありました。この過程で、いくつかの大きな決定と変更を行いました。それが完了したら、エンジニアと開発者に、デプロイメントパイプラインを通じて、利用可能なパターンと基準を活用しながら、それを向上させるためのツールとプロセスを提供する必要がありました。
次に、私たちは期待通りに運用していることを確認し、検証する必要がありました。必要に応じて標準やパターンに戻り、シフトする準備ができていることを確認し、対応して学ぶ必要がありました。Clarkが言及したように、システムから障害を完全に取り除くわけではありません。むしろ、システム障害に備え、学び、そのプロセス全体を通じて対応力を身につけ、復旧の準備を整え、MTTRを短縮していくのです。
レジリエンシー基準を理解する上で重要なのは、パフォーマンステストを実施することです。Vanguardでは以前からパフォーマンステストを行っており、ベンダーのツールを使用していましたが、需要に関してそのツールの能力の限界に達してしまいました。単純により多くの機能が必要でしたが、ベンダーからコスト効率よく得ることができませんでした。そこで、PTaaS（Performance Testing as a Service）と呼ばれる社内ツールを開発しました。これは基本的にLocustをベースにしたコントロールプレーンです。AWSでプロビジョニングできるインフラの限界まで、事実上無制限にスケールアップすることができます。このツールを使って、かなりの負荷をかけてきました。これにより、システムが大きな負荷にどのように反応するかを理解することができます。
さらに、カオスエンジニアリングのために利用可能な様々なツールを検討しましたが、一部のツールは私たちの環境に適していませんでした。
その結果、私たちのビジネスプロセスの文脈に特化した社内ツールを開発しました。このツールを使用することで、システムで発生する可能性のある障害を体験することができます。現在、このツールスイートには約20の実験が存在し、予想通り、それらはすべて災害や自然現象にちなんで名付けられています。
私たちは観測可能性スタックを強化しました。以前は、ロギングとアラートに頼っていました。分散トレーシングを導入したことで、視野が広がりました。これにより、システム内で障害が発生する場所をリアルタイムで本当に理解できるようになり、平均検出時間、そして平均修復時間を大幅に短縮することができました。 Stacyがポリシーエンジンについて言及しました。これは、RegoやOPAなどのオープンな技術や標準を使用して開発したツールで、ビジネス価値がパイプラインを通過する際にその価値を確認し、私たちが確立したレジリエンシー基準への準拠を確認することができます。これにより、パイプラインの早い段階で問題のあるものを失敗させ、通過するものが私たちの定義通りに真にレジリエントであることを確認できます。
私たちは、ステークホルダーに対して、重要なビジネスプロセスの健全性をリアルタイムで確認できる機能を提供したいと考えました。そこで、エンタープライズヘルスダッシュボードを作成しました。 ツールを持つことは良いことですが、全員がそれらのツールを使用する権限と意欲を持つ文化を持つことはさらに良いことです。そこで、私たちは変更リリース管理を変更し、レジリエンシーの文化に焦点を当てました。Stacyが言及したように、以前はチェックリストがありましたが、これは良いスタートではあるものの、スケーラブルではありません。私たちはより速く動き、より速く価値を提供したいと考えたので、リリース管理を完全に自動化しました。 ルールエンジンがこれを可能にしました。
私たちは、パフォーマンステストとカオステストを組み合わせ、ビルダーが安全な方法で障害を経験できるようにしました。複数の要因が重なったときに障害が発生するため、私たちはこの問題を強制的に引き起こしたいと考えました。負荷がかかっている状態で何かが失敗したらどうなるのか？ アプリケーションが障害からどれだけ速く回復できるか、あるいは回復できるかどうかを理解したいと考えました。時には負荷がかかっている状態で、サービスが圧倒されて介入するまで自力で回復できないことがあります。これを理解することは私たちにとって非常に重要でした。
この旅を進め、より多くの経験を積むにつれて、私たちの人々は専門家になりました。彼らを集め、他の人々に教え、お互いから学ぶ機会を提供することが重要でした。そこで、レジリエンシーチャンピオンネットワークを作りました。 私たちは全てのビルダーにSREプラクティスのトレーニングを行いたいと考え、Vanguardの全てのクルーメンバーが利用できる3段階のトレーニングカリキュラムを作成しました。また、エグゼクティブ向けの特別トラックも用意し、彼らもSREプラクティスに精通できるようにしました。
最後に、非常に権威のある賞を設けました。これまでに数チームにこの賞を授与しています。この賞は、オーナーシップメンタリティーにおいて卓越したチーム、つまり自分たちのサービスをこれまで以上に優れたものにし、真にレジリエントにする方法を見出したチームを表彰するものです。金銭的な報酬もありますが、それ以上に重要なのは自慢する権利です。
Vanguardのレジリエンス戦略の成果と今後の展望
では、現在どのような状況でしょうか？ 私たちは、反応的なアプローチから、予防的なアプローチ、そして根付いたプラクティスへと移行しました。これは一夜にして起こるものではなく、おそらく終わりがありません。成熟度が高まるにつれて、レジリエンシーの旅を継続的に見直す必要があります。私たちはチェックリストから、ポリシーを自動的にチェックし、エクスペリエンスを向上させることができる組み込みのポリシーエンジンへと進化しましたが、これで終わりではありません。私たちはこれを継続的に強化していく予定です。
これまでの成果と今後の注力点について話しましょう。ここ数年で、レジリエンシーが大幅に向上しました。信頼性と継続性が強化され、さらに重要なのは、システムに対する顧客とクルーの信頼が高まったことです。エラー対応よりも機能開発に注力できるようになりました。実際、デリバリーを5倍に増やしながら、重大インシデントを30%削減しました。安定性を高めるために変更凍結を実施していた時代は過去のものとなり、今では deployments を増やしながらインシデントを減らしています。
これは全て、エンジニアや開発者が手動のチェックリストや障害物なしに、より迅速に開発・デプロイできるよう統合されたコントロールが導入されたからです。observability に焦点を当て、本腰を入れて取り組みました。重要なのは、障害に備え、システムのどこで障害が発生しているかを把握し、対応の準備ができていることです。
この分野に注力した結果、Mean Time to Recovery (MTTR) を60%削減できたことを嬉しく思います。可用性、信頼性、回復性が向上し、先ほど述べたように顧客体験と満足度も向上しました。もう一つの大きな成果は、開発者がこのプロセスに関与することを実際に好むようになり、もはや production stops やコントロールに直面することがなくなったことです。彼らは喜んでテストに参加し、より迅速に進めるためのツールを使用しています。しかし、これで終わりではありません。ここにさらに注力し続ける必要があります。
来年注力するのは、採用のしやすさを継続的に改善することです。これを立ち止まって考えなければならないものではなく、システム全体に組み込まれたものにしたいと考えています。エンジニアや開発者にとってより採用しやすいものにしたいのです。そのために、ライブラリの消費を多く統合し、ツールのプログラム的な消費をより多く作成し、ツールのトレーニングの必要性を減らし、使用とデリバリーに集中できるようにしています。
observability は引き続き大きな焦点です。最先端のツールを使用していますが、それらは様々な場所や platform に分散しているため、チームはそれらの platform を横断して確認する必要があります。end-to-end journey を簡単に確認でき、システムの障害をより早く特定できるよう、単一の platform への統合を継続的に検討しています。policy engine も強化しています。標準をコード化し、開発ライフサイクルの早い段階でエンジニアにより多くの情報を提供し、途中で対応や調整ができるようにすることを継続的に検討しています。
そして、私たちは自社のプラクティスを見直しています。現在は主にアプリケーションに焦点を当てていますが、レジリエンシーのライフサイクル全体を通して、エンドツーエンドのクライアントジャーニーを継続的に検討していきたいと考えています。ここにあるQRコードをスキャンすると、どなたでもAWSのホワイトペーパーをご覧いただけます。このホワイトペーパーでは、Clarkが言及したライフサイクルと、Vanguardの取り組みの中で使用している多くの要素について詳しく説明しています。
本日は皆様の貴重なお時間をいただき、ありがとうございました。まだ完成途上ではありますが、レジリエンシーに関する私たちの取り組みをご紹介できて光栄です。ここで質疑応答の時間を設けさせていただきます。また、個別にお問い合わせいただいても構いません。ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion