re:Invent 2024: Fidelity InvestmentsのChaos Engineeringによる信頼性向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Fidelity Investments: Building for mission-critical resilience (FSI318)
この動画では、Fidelity InvestmentsがAWSで重要な取引システムを運用する中で、Chaos Engineeringを大規模に導入した事例が紹介されています。Failure Mode and Effects Analysis (FMEA)を活用して障害モードを分析し、AWS Fault Injection ServiceやAWS Systems Managerを組み合わせた「Chaos Buffet」システムを構築しました。特にAWS Lambdaの障害テストについて、Lambda layersを活用した独自の手法から、最終的にAWS Fault Injection Serviceのネイティブサポートに至るまでの進化が詳しく解説されています。3,000以上のアプリケーションでChaos Engineeringを実践した結果、Mean Time To Resolution (MTTR)が大幅に改善され、クラウド移行を進めながらもシステムの信頼性を高めることに成功しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Chaos Engineeringによるレジリエンス向上：Fidelity Investmentsの事例
おはようございます。Amazon Web Servicesの Technical Account Managerを務めております Joe Choと申します。本日は、Fidelity InvestmentsのSVP兼Head of SRE and Production ServicesのKeith Blizardをお迎えできることを大変嬉しく思います。このセッションでは、Fidelity Investmentsが最も重要なアプリケーションをいかにして構築し、可能な限り高い回復力で運用しているかについてお話しさせていただきます。
まず初めに、おそらく皆様の多くが直面している、そして本日ここにいらっしゃる理由となっている課題についてお話しします。銀行取引、証券取引、医療、行政など、最も重要なミッションクリティカルなアプリケーションを24時間365日運用しなければならない一方で、私たちの周りや時にはシステム内部でも障害が発生します。この問題にどう対処すべきでしょうか。その後、Keithが大規模なChaos engineeringの導入によってこの課題にどう取り組んだかについてお話しします。続いて、AWS Fault Injection Serviceが、KeithとFidelity Investmentsと協力してこのプラットフォームを開発した経緯についてご説明します。実際の機能と、両社がどのように進化したかについて詳しく掘り下げていきます。最後に、私たちが得た教訓と成果を共有し、ここにいらっしゃる皆様にその学びを活かしていただければと思います。
Fidelity InvestmentsのAWSクラウド移行と直面した課題
では、私たちのストーリーから始めましょう。2019年、Fidelity Investmentsは取引システムの中核を担うOrder Management SystemをAWSに移行しました。これには複数の要因がありました。少額取引や手数料無料化といった新しい市場動向により、取引価値が増加しました。また、その頃にはGameStopのミーム株現象により、予測不可能なほど取引量が劇的に増加しました。このような取引量の増加により、プラットフォームの運用コストが多くの人々の最大の関心事となりました。取引環境と顧客の期待は急速に進化していました。誰もが高性能なモバイルデバイスを持ち、そこから取引ができるようになっています。私自身もAmazonの社員として、Fidelity Investmentsのパーソナルファイナンスサービスを利用する顧客の一人です。
Fidelityはクラウドを採用する一方で、オンプレミスにも多大な投資を行っています。クラウドで構築するものが、オンプレミスの環境、さまざまな事業部門、異なる注文タイプ、そして最も重要な取引の継続性にも対応することを確実にしたいと考えています。私や皆様のような顧客がボタンを押したとき、確実に実行され、顧客が完全な信頼を持てることを保証したいのです。キャパシティ、スケーラビリティ、コスト最適化、市場投入までのスピード、ハイブリッドクラウド、そして何よりもクラウドによってサポートされる24時間365日のリアルタイム運用が、Fidelityが追求していたテーマであり、これらのニーズに対応するために示されたAWSサービスが使用されました。
前のスライドでご覧いただいたように、Amazon EKSとAmazon EC2 Auto Scalingがキャパシティとコスト効率を提供しました。しかしそれは同時に、チームが新しいことを学ぶ必要があることも意味していました。クラウドのキャパシティ管理、メモリ割り当ての定義、スケーリングポリシー、リトライポリシー、発生する遅延への対処方法などです。Fidelityは開発環境を非常にアジャイルにしたいと考え、分離されたエージェントアーキテクチャのために、Amazon EKSやAmazon MSKと共にサーバーレスのAWS Lambdaを使用しました。しかしそれは単純に変更が増えることを意味し、アプリケーションの重要性を考えると、それぞれの変更を慎重かつ徹底的に評価しテストする必要がありました。ハイブリッドクラウドでは、もはやハードウェアの近くで作業することはできないため、新しいスキルを習得する必要がありました。
最適化、実験、トラブルシューティングなどのスキルは、異なる方法で学ぶ必要がありました。システムの重要性を考慮して、マルチリージョンアーキテクチャを選択しました。そのため、リージョン間でのプロセスの仕組みや、障害発生時の動作など、マルチリージョン環境での運用方法についても理解する必要がありました。何よりも、継続的なレジリエンスが最重要課題でした。
Amazon.comのDr. Werner Vogelsの有名な言葉をご存知でしょう。 実際のところ、私たちにはコントロールできない障害が発生するものです。少し脱線しますが、先ほど5分前にAV機器のセットアップで問題が発生し、テクニカルスタッフがトラブルシューティングを行っているのを目にした方もいらっしゃるかもしれません。予測不可能でしたよね？私は実際、スマートフォンをタイマーとして使おうと考えていました。こういったことは起こりうるのです。計画していなくても、私たちの制御外のことが起きて、システムに影響を与えるのです。
制御できないことだけでなく、私たちが制御できること、つまり変更も問題となります。私の尊敬する人物の一人であるWilliam Pollardは、 変更なくしてイノベーションはないと述べています。皆さんがここにいるのは、イノベーションを起こすためです。今週はまさにそのためのものです。しかし現実には、皆さんもご存じの通り、変更によって時にシステムは壊れてしまいます。
では、私たちは何をすべきでしょうか？変更を止めることはできません。今朝のキーノートでも触れられたように、リスクを取らなければなりません。 問題は、私たちがコントロールできない事象がシステムを壊す可能性があり、さらに私たちがコントロールできる事象である変更も同様にシステムを壊す可能性があるということです。私たちは何をすべきでしょうか？どうすれば安心して眠れるのでしょうか？願わくば、枕元にPagerを置かずに済むことを。
古代中国の将軍Sun Tzuの有名な言葉を皆さんもご存じでしょう。敵を知り己を知れば百戦危うからず。しかし今朝は、このフレーズをレジリエンスの観点から読み直してみましょう。 失敗モードを知り、システムとその依存関係を知れば、百のインシデントも恐れることはありません。もし他の会議に行かなければならない方がいれば、これだけは覚えておいてください。これこそが私にとってのレジリエンスです。これがChaos Engineeringの本質なのです。
私たちの目の前で、セッション開始5分前に機器が故障するといったような、私たちに影響を与えるイベントを止めることはできません。 しかし、これらの依存関係を学び、そのようなイベントが私たちのシステムにとって何を意味するのかを理解することはできます。確かに変化を抑制することはできません。抑制してしまうと、すぐに時代遅れになってしまいます。ですが、その変化が私たちのシステムに対して何を意味するのかを理解することはできます。そうすることで、すべてのインシデントがなくなるとは約束できませんが、インシデントの発生は確実に減少すると考えています。
Continuous Resilienceサイクルとカオスエンジニアリングの本質
Continuous Resilienceサイクルは、皆さんの多くがすでに実践されているものだと思います。 これが現在の私たちのIT運用の姿です。目標を設定し、設計して実装し、構築したものを評価してテストします。本番環境で運用し、運用しながら新しいことを学び、学んだことに対応して、そのサイクルが繰り返されます。数週間前に米国大統領選挙がありましたが、なんとも興味深い時代ですね。おそらくこのイベント中に、市場の取引量を見て、スケーリングポリシーが十分ではなかったことに気付かれたかもしれません。そこで、責任追及ではなく、ギャップを理解してそれに対応するために、ポストモーテムやRoot Cause Analysisを実施されたかもしれません。
これは良いことです - これらから学び、継続していくべきです。しかし、私が今日ここで提起したい課題は：左にシフトできないだろうか？ということです。これはよく出てくる用語だと承知していますが、文字通り、先ほど説明した元のサイクルの中で、本番環境で起こる前の、より早い段階で学習することができないでしょうか？そして、これこそがChaos Engineeringの本質なのです。
Chaos Engineerとして、私たちは科学者のような存在だと考えています。私たちはシステムを研究します。もし私が生物学者なら、研究室で何らかの物質を研究しているかもしれません。技術者として、私たちはアーキテクチャやアプリケーションを研究します。生物学者が顕微鏡を使って研究するように、私たちの観察ツールはCloudWatchやCloudTrailのようなものです。科学者として、私たちは仮説を立てます - 米国選挙のようなスケーリングイベントが発生した場合、ノードは適切にスケールするだろうか？顧客は大丈夫だと思うが、確信は持てない。これこそが私たち科学者のすることなのです。
私たちは未知のものを追求します。これはテストとは異なります。テストは既知のことを検証することです。つまり、ノードのスケーリングについて - 追加ノードがあれば、スケールすると考え、それを確認することは良いことです。Resilienceテストは継続すべきことです。しかし、スケールした後はどうなるのでしょうか？周辺システムにどのような影響があるのでしょうか？ギャップはないのでしょうか？私たちが追求しているのは、そのような未知の部分です。それらは、私たちが立てた仮説に対して行いたい実験なのです。
私たちは責任ある科学者です。生物学者としての経験に立ち返ると、例えば研究室でウイルス性の危険な物質を研究している場合、その実験が制御不能になることは絶対に避けたいものです - 次のゾンビ黙示録を引き起こすようなことは避けたいわけです。Chaos Engineeringでは、文字通りシステムを破壊するので本質的に危険が伴います。そのため、適切な安全装置とガードレールを備えた実験を構築する必要があります。
これは素晴らしいのですが、そもそもどこから始めればいいのでしょうか？どんな実験を行うべきか疑問に思うかもしれません。幸いなことに、FMEAとして知られる便利な手法があります。私の理解では、これは製造業から生まれた数十年前からある手法ですが、今日でも、クラウドコンピューティングプラットフォームにおいても価値のある手法です。これ自体で1時間ほどの別の講演になりそうなので、ここではエッセンスだけお話しします。基本的には、システム内の各機能を特定し、その機能がどのように失敗する可能性があるかという故障モードを考えます。それぞれの故障モードについて、その影響と深刻度、原因、発生確率、そして制御と検出能力について考えます。
簡単な例を挙げて説明しましょう。例えば、更新機能があるとします。この更新機能はどのように失敗する可能性があるでしょうか？まず、完全に失敗する - つまり更新されないという可能性があります。1から5のスケールで、5が最悪として、その深刻度はどの程度でしょうか？機能が本来の目的を果たせないわけですから、かなり深刻です - 深刻度5です。もう一つの失敗パターンとして、機能は更新されるものの遅延が発生する場合があります。その影響はどうでしょうか？リアルタイムシステムなのでこれはかなり深刻です。下流に影響を与える可能性があるので、ここでも深刻度は5です。
次に、原因について考えます - これらの故障モードの原因は何でしょうか？更新失敗の場合、スロットリング制限に達した可能性があります。その可能性はどのくらいでしょうか？実は私はAWS Trusted Advisorを積極的に活用しており、それを追跡しています。さらにチームは常にSLAを監視しています。そのため、実際にこれが起こる確率はかなり低いと考えています。遅延応答についてはどうでしょうか？これはAWS Lambda関数なのですが、おそらくLambda関数に十分なメモリを割り当てていないため、少し遅くなっているのかもしれません。これが起こる確率はどうでしょうか？私はこれを厳密にテストしています - これはレジリエンステストであってChaos実験ではありません。テストを行い、必要なメモリ量を正確に把握しているので、これが起こる確率も低いと考えています。
そして、完全な更新失敗に対する制御と検出について考えます。どの程度検出できるでしょうか？これはかなり単純です。tryループがあり、500などのエラーコードを探し、リトラクトを出力します。検出は十分簡単なので、ここでのリスクは1です。では遅延応答についてはどうでしょうか？戻りコードは200です - 更新自体は成功していますが、単に遅延しているだけです。これを検出する良い方法があるかどうか確信が持てません。おそらく事後的な検出になるでしょう。あまり良くありません。そのため深刻度は4となります。
私はこの分析を行います。実際にはこれは簡略化されたバージョンです。より成熟したアプローチを取る場合は、依存関係や所有者などの追加フィールドがあります。チームとしてこれを実施し、1日かけて取り組むことをお勧めします。2つの成果が得られると考えています。1つ目は、1日の終わりには、チームがシステムについてより深い理解を得て、共通の認識を持つことができます。全員が同じページにいることになります。そして2つ目は、1日の終わりには、すべての機能と故障モード、リスクの優先順位付けという素晴らしい成果物が得られます。これがあなたのResilience programの計画となります。
Fidelity InvestmentsのChaos Engineering実践：成熟度モデルと実装
これは素晴らしく聞こえますが、中には「これは学術的で、きれいな色使いで、LinkedInのブログには良い内容かもしれないけど、実用的なのか？」と考える方もいるかもしれません。しかし、Fidelity Investmentsはこれを大規模に展開しています。それでは、Keith Blizardをお迎えしましょう。みなさん、ありがとうございます。私はre:Inventが大好きです。今回で11回目の参加になりますが、毎回素晴らしい人々とつながりを持ち、新しい知見を得ることができています。
本日は、Joeが説明した「なぜ」に対する「どのように」と「何を」について少しお話ししたいと思います。彼が言及した「すべてのものは壊れる」という概観について考えてみると、その通りなんです。私は15年間クラウドコンピューティングに携わってきましたが、様々な問題や障害を経験してきて、それは確実に起こるものだと言えます。そのため、最も重要な側面は、どのように準備し、またシステムがどのように相互作用するかを理解するための実践をどのようにスケールさせるかということです。
私はこのGartnerのスライドが気に入っています。引用元は明記していますが、Gartnerから拝借しました。というのも、特にシニアリーダーの方々は、クラウドの障害について話すとき、左下のような全クラウドがダウンするような事態を想像しがちだからです。この会場の皆さんに言うのも気が引けますが、そういうことは起こりません。もしそうなったら、誰もの日常生活が大変なことになってしまいます。確かに地域的な障害は発生し、時には非常に深刻な影響を及ぼすこともありました。昨日のKeynoteでも触れられていたように、Amazonは製品にRegional resiliencyをネイティブに組み込み、active-active-activeパスや優れたRegional failover機能を実現するために多くの時間を費やしています。
私がFidelityで推進し、また皆さんにもお勧めしているのは、右側の大きな円です。これらはコンポーネントと領域で、Joeが話したFMEA分析は、これらの領域を理解し、環境全体のResiliencyを推進するためのコントロールを構築していくための手法です。今日は少しの時間を使って、なぜ私たちが今これを行っているのか、そして私たちにとってどのような意味があるのか、そしてどのように変化したのかについてお話ししたいと思います。
振り返ってみますと、私たちは8年間にわたってクラウドを活用してきました。これは素晴らしい旅でした。少なくとも私がFidelityにいた間、クラウドトランスフォーメーションに関する技術、焦点、重要性は、その成功に不可欠でした。Fidelityの歴史を振り返ると、金融サービス業界におけるテクノロジーカンパニーとして、以前は私たちはハードウェアにレジリエンシーを組み込んでいました。インフラレベルのレジリエンシーに基づいた、非常に優れたシステムを構築し、可能な限り堅牢にしていました。クラウドへの移行に伴い、その考え方を変える必要がありました。Joeが指摘したように、すべてのものは壊れ、すべては失敗します。レイテンシーの問題、EBSの障害、RDSの障害、IAMの障害など、さまざまなコンポーネントで問題が発生します。そして私たちの journey を通じて、現在では1800個のAWSアカウントを持ち、アプリケーション全体の75%がパブリッククラウドで稼働する大規模な環境となっています。
私が特に注目しているのは、下の2つの数字です。重要なシステムについては、後ほど成熟度の観点から説明するカオステストの異なるレベルを、通常のリリースプロセスで実行することを求めるガイドラインを確立しました。今日は、その実現方法について少しお話しし、その後、Joeに引き継いで、より多くの障害シナリオをカバーするために行ったパートナーシップについて説明してもらいます。
私は対話を始めるための手段として成熟度モデルを使い始めました。これは個々の現状を判断することが目的ではなく、進むべき異なるフェーズについて議論することが重要です。特にオンプレミスからパブリッククラウドへの移行を始める多くの人々は、コンポーネントに関して年に1、2回のフェイルオーバーテストを計画するレベル1から始めます。これは通常、良い道筋、あるいはハッピーパスと呼ばれるもので、すべてのコンポーネントとチームが揃っており、進められることを確認するための練習を行います。
ここ数年で私たちが移行してきたフェーズは、レベル1とレベル2への推進です。これには、インフラレベルの障害とアプリケーションレベルの障害を組み合わせて、チームが簡単にそれらのタスクを実行できるようにすることが含まれます。適切なリトライロジックはありますか？エコシステム全体で適切なしきい値と制限を設定していますか？私たちの例で見るアプリケーションの多くは、単純なアプリケーションとデータベースの組み合わせではありません。10から100のマイクロサービスが相互に接続されたコレクションであり、ビジネスプロセスフローがどこにあるかを理解する必要があります。それらのマイクロサービスの1つに影響が出た場合、それが全体のビジネスプロセスにどのような影響を与えるのか、お客様が実際に何を見ることになるのか、そして効果的に回復できるのかを知る必要があります。
私たちはChaos Buffetというシステムを構築しました。これは、それらの障害を実行するためのさまざまな方法を抽象化したものです。JoeがAWS Fault Injection Serviceについて今日説明しますが、それやその他のオープンソースの機能を活用して、CI/CDパイプラインで共通の実験とテンプレートを通じて障害を実行し、環境全体で再現可能な使用を促進しています。すべての開発者がエキスパートである必要はありません。共通のテンプレートを通じて再現性を高め、開発チームやスクワッドがテストしたい設定プロファイルを理解し、提供する方法として活用しています。複数のパブリッククラウドやオンプレミス環境にまたがって実行を推進するメカニズムを構築する必要がありました。
AWS Fault Injection ServiceとLambdaを活用したカオス実験の実装
Squadが実際に必要なのは、実験の右側にある設定を埋めることだけです。これには、アプリケーションの成功、失敗、そして適切な実行時のレスポンスタイムを理解するためのObservableリンクと、しきい値の設定が含まれます。これらのChaosテストを実行する際には、Performance EngineeringとPerformance Testingのシナリオと組み合わせて、システムに負荷をかける必要があります。つまり、Joeが先ほど説明したFaultと、個々のサービスという2つの異なる側面のコンポーネントを統合するのです。これを機能させるには、それらのサービスのFaultをテストするための適切なレベルの設定が必要です。
ここで、私たちとAWSとのパートナーシップが非常に強力な力を発揮しています。私たちは、システムをテストするために必要な様々なサービスについてフィードバックを提供してきました。AWS Fault Injection Serviceがロードマップを作成する際には、私たちが活用したいFaultのタイプについてフィードバックとガイダンスを提供しています。
Joeが先ほど説明したOrder Management Systemを見てみると、 ここに高可用性のマルチリージョン、マルチAZトランザクションシステムの論理アーキテクチャが示されています。このアーキテクチャを効果的に構成してセットアップするために、初期の段階で多くの時間と労力を費やしました。Regional Recovery、Queue、そしてすべてのデータを確実に保持できるようにするなど、ベストプラクティスに従って実装されています。しかし、私たちにとって不足していたもの、そして昨年のre:Inventでチームと話し合ったのは、AWS Lambdaをテストする方法がなかったということです。
私は本当にAWS Lambdaが大好きです。Lambdaは、数年前にAmazonがリリースした素晴らしい機能の1つで、コードを実行して変更を加えることができます。しかし、コードを更新せずにそのサービスにネイティブにFaultを組み込むのは本当に難しかったのです。私たちは、コード自体にライブラリを組み込むのではなく、システムをテストできるようにしたかったのです。なぜなら、このようなシステムではLambdaがデータの同期に使用されており、Lambdaでエラー率が高かったり、ダウンしていたり、レイテンシーが高かったりした場合に、ビジネスプロセスフローにどのような影響があるのかを理解する必要があったからです。これが、パートナーシップの重要な領域でした。
ありがとう、Keith。ご覧の通り、AWS Fault Injection ServiceはFidelityの構築における中核的なパートナーであり重要なコンポーネントでした。 Keithが先ほどデモンストレーションしたシステムでは、先ほど説明した取引システムのような任意のアプリケーションに対して、ご覧いただいた実験テンプレートを使用して多数の実験が可能です。これらの実験は、決して網羅的なリストではありませんが、その特定の取引システムに適用可能な代表的なリストです。Amazon EC2、キャパシティに関するAmazon EKS、そしてKeithがマルチリージョンアーキテクチャで示したDynamoDBのグローバルテーブルについては、レプリケーションの一時停止実験やLambdaに関する実験も含まれています。
先ほどのFISを使用したLatencyの例は単なる例示ではなく、Keithが言及した通り、私たちが一緒に取り組んだ実際のユースケースでした。 Keithが指摘したように、昨年のこの時期にはLambdaはFISでネイティブにサポートされているサービスではありませんでした。そこで、どのように構築するか考えました。Lambdaは私の大好きなサービスの一つです。私にとって、これはクラウドコンピューティングの象徴です - サーバーレスコンピューティング、コードアスアサービス、ファンクションアスアサービス - 本質的にはコードそのものです。
考えてみると、どんなコードにも通常2つのレイヤーがあります。 基盤となる部分、ライブラリ、アセットがあり、それをビジネスロジックから分離します。これは一般的なコードでも行いますし、Lambdaでも同様です。Lambdaには、まさにこれを可能にする非常に便利な仕組みがあり、適切にもLambda layersと呼ばれています。設定やアセット、必要なものをLambda layerに入れ、実際のビジネスコードとは分離するのです。これにより、クリーンな分離が可能になるだけでなく、Lambda layerを異なるFunctionで再利用することもできます。
これは素晴らしいことなので、どこに障害を注入するか考えました。Keithが述べたように、私たちは障害を実際のコードから分離しておきたいと考えていました。 Invent and Simplifyは、ここでの私のお気に入りのLeadership Principleです。最もシンプルだけれど効果的な解決策として - 単純にLambda faultをLayerに入れることにしました。Keithが言及したように、ユースケースの1つはLatencyです。これはリアルタイムのトレーディングシステムなので、どうやってLatencyをエミュレートするか？それは文字通り単純なSleep関数です - ここでもInvent and Simplifyです。
そのLambda faultをSleepさせたり、また出力などの他の障害も用意しています。これから数分間、Latencyエミュレーションについてお話しします。このようにLambda faultをLayerに入れ、実際のビジネスロジックのコードは別にしています。
これで何が達成できたのでしょうか？並列のパイプラインができました。必ずしもこうする必要はありません - Latencyをエミュレートするために、Sleep関数を直接コードに入れたり、Chaos Monkeyをコードに挿入したりすることもできます。しかし、そうするとコードが乱雑になり、もしChaosを削除し忘れたままプロダクションにプッシュしてしまったら、履歴書を書き直す時が来たということになります。この方法なら、実際の機能コードとChaos開発という2つの並列プロセスを持つことができます。ちなみに、私がお見せしたLatencyに関する特定のFaultは、 GitHub AWS samplesにありますので、ぜひご覧ください。非常にシンプルですが、機能的で、他のLambda layersやFaultも用意されています。
この仕組みについて、もう一歩踏み込んで説明させていただきます。とてもシンプルな仕組みです。まず、Lambdaパッケージを作成します。これは単純に、Sleepファンクションやその他エミュレートしたい機能を、基本的にPythonパッケージにまとめたものです。ステップ1として、シンプルなLambda CLIコマンドを使ってレイヤーを公開します。これを実行すると、IAMに割り当てられたARNを持つAWSリソースとなり、配布が可能になります。実験を開始する際は、Lambda CLI APIを呼び出してレイヤーをアタッチします。実験を行い、終了したらCLIを再度呼び出してレイヤーを削除します。
ただし、これは先ほど触れなかったアドホックなカオス実験の方法です。私たちは企業として、再現可能で、キュレーションされた、自動化された実験を必要としています。 AWS Systems Managerは、まさにそれを可能にします。Systems Managerについては別のセッションで詳しく扱うべき内容ですが、多くの機能や特徴があります。今回のコンテキストでは、自動化の側面に焦点を当てたいと思います。右側のスクリーンショットは、SSMドキュメント（runbook）を示しています。これにはスクリプティングを含む様々なパラメータを設定できます。そのスクリプティング部分では、先ほどお見せした3番目のステップ、つまりLambda APIを呼び出してレイヤーをアタッチし、その後削除する処理を行っています。実験に必要なパラメータ（Sleepファンクションの実行時間であるレイテンシー、事前に作成したLambdaレイヤー、ターゲットとなるLambdaファンクション）を受け取ります。
Chaos Engineeringの成果と今後の展望：金融サービス業界への適用
AWS Fault Injection Service（FIS）は、2つの異なる方法でAWSサービスをサポートしています。Amazon EC2、Amazon RDS、Amazon EKSなどのネイティブにサポートされているサービスがあり、FISから直接呼び出すことができます。また、AWS Systems Managerを呼び出すこともできます。ご覧の通り、Systems Managerは非常に柔軟なスクリプト環境なので、それを活用しました。FIS実験を作成し、コンソール画面で先ほどのSSMドキュメントを呼び出し、必要なパラメータを入力するだけで完了します。
なぜこのような方法を取るのか、単にSSMドキュメントを呼び出せばいいのではないか、と思われる方もいるでしょう。確かにそれも可能です。しかし、この方法では、マネージド型のカオスエンジニアリングプラットフォームを手に入れることができます。FISはAmazon CloudWatchと緊密に統合されています。繰り返しになりますが、私たちは科学者です。観察とデータ収集が必要不可欠です。冒頭で触れた生物学の例に戻りますが、実験を行っても、データを取らず、記録を残さなければ、何の意味があるでしょうか？FISとCloudWatchの緊密な統合により、すべてのデータを収集することができます。数枚前のスライドで、左上のChaos Buffetのキーポイントとしてデータ収集の部分を示しましたが、これが重要なのです。この1週間を通じてご覧いただいたように、データは金です。そして、私たちは責任ある科学者として、実験が制御不能になることは避けたいと考えています。
AWS Fault Injection Serviceにはゾンビの大量発生は起こりません。停止条件を設定できるからです。停止条件は単純なCloudWatchアラームで、ノード数、CPU、メモリなど、様々な条件でトリガーできます。実験に停止条件を設定することで、実験を停止する大きな赤いボタンを手に入れることができます。これにより、完全にキュレーションされた、責任あるカオス実験が可能になります。
では、ここまでで何が達成できたのでしょうか？KeithとチームがAWS Lambdaでカオス実験をどのように行うかを尋ねたとき、これが今年の第2四半期に私たちが提供したソリューションです。Chaos Buffetチームがそのようなレイヤーを作成し、ドキュメントも作成して管理しています。開発者たちはこれらの実験にすべてアクセスできます。YAMLテンプレートファイルからわかるように、開発者はChaos Buffetに送信する実験を定義でき、それがAWS Fault Injection Serviceを呼び出し、さらにAWS Systems Managerを呼び出して実験を実行します。これは素晴らしいのですが、よく考えてみると、まだかなりの作業が必要です。FidelityはLambdaレイヤーとAWS Systems Managerドキュメントの作成と管理を行わなければなりません。
そこで彼らは、もっとシンプルで効率的にできないかと尋ねてきました。今週見てきたように、私たちの製品の進化は主にお客様の要件によって推進されています。そこで私たちは、今年の10月、実際にはハロウィンの10月31日に、AWS Fault Injection ServiceがLambdaをネイティブにサポートするようにしました。今では、AWS Fault Injection Service実験を呼び出すだけで、私が説明したすべてのことが既に完了しています。必要に応じて、AWS Systems Managerドキュメントを使用することもできます。実際、これが裏側で行われていることです。実験を修正したり、独自の実験を作成したりすることももちろん可能です。しかし今では、特にレイテンシーや出力に関する実験であれば、すべてネイティブにサポートされています。
では、ここで何を達成したのでしょうか？私たちは、開発され、管理され、統制され、検証され、そして保護された実験のライブラリを本質的に作り上げました。カオスエンジニアリングを実施したいものの、リソースや時間がなかったチームでもこれを使用できますし、経験が不足していたり実験の実施に不安を感じていたりするチームでも、安全にこのプラットフォームを採用できるようになりました。Keithの先ほどのスライドでご覧いただいたように、私たちは多くのアプリケーションチームを支援し、3,000以上のアプリケーションが実験の一環としてこのシステムを使用するようになりました。
それは素晴らしいことです。3,000という数字は素晴らしく聞こえます。しかし、科学者としての視点に立ち返ると、いくら実験をしても、その実験から何も学ばなければ、何を達成したことになるでしょうか？そこで、学びと成果について共有させていただきます。 Fidelityがこのプロセスを通じて得た学びは、主に4つの領域に分類できます：障害からの回復、システムパフォーマンス、需要への対応、そして影響範囲の削減 - 技術的には、リトライ、メモリ割り当て、スケーリング、タイムアウトです。これらを見ると、主にテーマ別の設定項目であることがわかります。
冒頭で共有した継続的改善サイクルに話を戻しましょう。皆さんの会社でクラスターをデプロイするよう求められたとします。自動化ポリシーを決める必要があります - どのようなスケーリングポリシーを設定し、どんな数値を実際に入れるべきでしょうか？ベストプラクティスを参考にしたり、システムの経験を活かしたり、計算をしたり、私の雇用を維持するために（笑）お気に入りのSolutions Architectに相談したりするかもしれません。しかし、最初に本番環境にプッシュするとき、それは結局のところ教育を受けた推測であり、システムとそれらの数値が本番環境に投入され、米国選挙のような状況に直面するまで、本当の適切な数値は分からないものです。しかし、私たちはシフトレフトを目指しています。Fidelityは大規模なカオスエンジニアリングを実施することで、問題が発生する前にこれらの気づきを得ることができました。
これらの実験と結果の多くは、非常に実践的なものであることがお分かりいただけると思います。これは単なる学術的な演習ではなく、実際のシステムに適用できる実践的な改善点なのです。Fidelityはどのようにして、どの実験を行うべきか判断したのでしょうか？先ほど触れたように、彼らはFailure Mode and Effects Analysisを実践していました。そのため、どのギャップを追求すべきか、どの未知の部分に取り組むべきかを、ロードマップ上で正確に特定することができ、その結果がここに表れています。
Resilience Engineeringに対して計画的かつ具体的に取り組むことで、このような結果を得ることができます。 ITの専門家として、このグラフは皆さんを笑顔にするはずです。黄色の線はChaos Coverageの投資に応じた推移を、ピンクの線はFidelity InvestmentsのMTTR（Mean Time To Resolution）を示しており、劇的な効果が見て取れます。さらに注目すべき点は、この期間中にFidelityはより多くのアプリケーションをクラウドに移行したにもかかわらず、MTTRが依然として低下し続けているということです。
私たちはこの結果を見て、満足し、自画自賛することもできます。しかし、William Pollardの言葉に立ち返れば、私たちは革新を続けたいのです。現状に甘んじて満足するのではなく、学び続けたいのです。では、次は何をするのでしょうか？ すべてのアプリケーションで100%のChaos Coverageを達成します。広く浅くではなく、深い範囲までカバーしたいのです。先ほどLambdaのFailure Modeについて特に話しましたが、システムにはさらに多くのFailure Modeが存在します。そのため、より多くのFailure Mode機能を理解し、開発するために、皆さんとさらなるパートナーシップを築きたいと考えています。
Sun Tzuの教えにあるように、より多くのFailure Modeを理解すればするほど、より良い準備ができます。また、各チーム間でのChaos Engineeringの成熟度を高めていきたいと考えています。私たちが学んだことを民主化したいのです。私たちのような大規模な組織では、チームによって成熟度が異なります。先ほどお見せしたようなグラフを、すべてのアプリケーションチームが持てるようにしたいと考えています。最後に、もう少し率直なお話をさせていただきます。私は金融サービス業界に携わっており、ここに来る前も、銀行やヘッジファンドなど、一生金融サービスの世界にいました。金融サービス業界には、「Chaos Engineeringは私たちには向いていない - メディアエンターテインメント向けかもしれない」という考えが少しあります。確かに、Netflixがこの分野を開拓しました - ちなみに、この会場にいらっしゃるNetflixの方々、ありがとうございます。
しかし、「私は取引や銀行業務、資産運用を行っているが、本当にこれができるのだろうか？」と考えているなら、私はこう主張したいと思います。最も厳格なレジリエンス要件を持ち、多くの規制を受け、単なるビジネスアプリケーションではなく世界経済を動かす社会的機能を担うアプリケーションを運用している私たちこそ、Chaos Engineeringやこのような実践を単に適切なものとして扱うだけでなく、基盤として位置づける責任があるのです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion