はじめに

Global Solutions事業部の緒方です。
AWS re:Invent 2024に現地で参加しています。
今回は[ARC326 | Chaos engineering: A proactive approach to system resilience]に参加しましたので内容を紹介します。

AWS re:Invent 2024とは

AWSが主催する年次カンファレンスで、主にクラウドコンピューティングに関する最新情報を発表し、エンジニアに限らず様々なロールの人や様々な業種の企業が集う大規模イベントです。2024年は12月2日から12月6日にかけて、アメリカ・ラスベガスで開催されます。

セッション

セッション概要

ARC326 | Chaos engineering: A proactive approach to system resilience
Do you know if your system will behave as intended when exposed to underlying failures? In this session, explore how chaos engineering enables organizations to proactively identify system resilience weaknesses, improve operational excellence, and enhance incident response capabilities. Through real-world scenarios executed with the AWS Fault Injection Service (FIS), this session demonstrates the benefits of chaos engineering in action. Gain insights from BMW Group’s transformative journey, learning key lessons on scaling chaos engineering across the organization, and how BMW Group conducts large-scale chaos experiments in production, uncovering issues and fostering a culture of greater resilience and continuous improvement.

システムが根本的な障害にさらされたときに意図したとおりに動作するかどうか知っていますか? このセッションでは、カオスエンジニアリングによって組織がシステムの回復力の弱点を積極的に特定し、運用の卓越性を向上させ、インシデント対応能力を強化する方法について説明します。このセッションでは、AWS Fault Injection Service (FIS) を使用して実行される実際のシナリオを通じて、カオスエンジニアリングの実際のメリットを示します。BMW グループの変革の旅から洞察を得て、組織全体にカオスエンジニアリングを拡張するための重要な教訓を学び、BMW グループが本番環境で大規模なカオス実験を実施して問題を発見し、回復力と継続的な改善の文化を育む方法を学びます。

Uliana Stefanishyna, Software Development Engineer, Amazon

Hrvoje (Lex) Lukavski, Product Owner & Architect, BMW AG

Adrian Hornsby, Principal System Dev Engineer, Amazon Web Services

セッション内容

日本語表記ではこう書かれていました。

カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を持つためにシステム上で実験を行う訓練方法です。

カオスとは有名な話で、どこかで蝶々が飛んだらべつのどこかでいずれハリケーンが起こる、ってやつですね。バタフライエフェクト。

カオスエンジニアリングは仮定を検証して新しい知識を得るための方法論であると強調していました。

確証バイアスや可用性バイアスなど、システムの設計と運用に影響を与える多くのバイアスが人間にはあるとのことです。思い込みのことですね。

様々なライブラリやフレームワークのデフォルトのタイムアウトの例を示し、これを検証しないことでどのように問題を引き起こす可能性があるかを示しました。重要な点は、カオスエンジニアリングを使用すると、ランダムな障害を注入するだけでなく、仮定をテストして未知の問題を発見できるということです。

if you haven’t verified it, it’s probably broken

確認できていない場合は、たぶん壊れているね

1時間の計画外のダウンタイムがあった場合の損失額です。41%以上の企業が「15,088,700,000円」（2024/12/4時点の為替で1億5000万円くらい）の損失、すごい規模の話ですね。。

ヨーロッパのDORA (デジタルオペレーションレジリエンス法)などの規制要件により、企業がカオスエンジニアリングの実践を採用するようになっていると述べていました。これは組織がレジリエンス演習を実施して、システムが不安定な状況から回復できるようにすることが義務付けられているそうで、この規制により、金融業界や自動車業界がカオスエンジニアリングの最前線にいるそうです。 

カオスエンジニアリングにおける 3 つの障害のカテゴリについて。

・発生した障害がクローズドなのか、システム全体に連鎖するのか

・IAM ポリシー、KMS、その他のサービスなど、明らかな依存関係と隠れた依存関係の両方をすべて理解すること

・キャッシュの動作など、条件によってシステムの動作が大きく異なる可能性があること

アプリケーションの挙動を発見するためにAd-hoc Experimentationが簡単な方法だよと言っていました。

デモでは、通常稼働（と想定した）のアプリケーションの状態を前提に、FIS(Fault Injection Service)を使用して Elasticacheエンドポイントにてレイテンシを発生させて、リクエストが想定どおりに別のDynamoDBにフェイルオーバーしなかったことを確認していました。次に、適切なタイムアウトを設定するようコードを変更し、再度実験を行って想定した動作になっていることを確認していました。

GameDayに関して、Ad-hoc experimentationと比較して、カオスエンジニアリングの観点でより包括的なアプローチだそうです。

GameDayでは例として、AZ内の停電をFISで注入（インジェクション）し、マルチ AZ のため顧客への影響はない想定でしたが、アプリケーションで遅延と再試行が発生した、というものを挙げられていました。マルチAZだから大丈夫ですよーと安易に言っては危ないですね。

GameDayでは手順書の検証、電話応対、Ad-hoc experimentationでは見つけにくい隠れた依存関係や問題の発見に役立つそうです。

そしてGameDayはカオスエンジニアリングに対してより構造化されていて定期的なアプローチだそうです。

後半は、BMW のLex氏で、名前が呼びにくいからLexとしているそうです。

BMW のカオスエンジニアリングの取り組みについて、話がありました。

2300 万台を超えるコネクテッドカーがあり、毎日140億件のリクエストを処理しているそうです。すごい数ですね。。

テストでは、プラグを物理的に抜くなどのハード側から開始し、その後、クラウドのテストのためにFISを使用したそうです。

BMWは教訓としてチーム間のコラボ、リーダーシップのサポート、心理的安全性のある文化（失敗を学習の機会と見なす）の醸成の重要性を挙げられていました。

さいごに

障害に強い強靭なシステムをつくるためには、単なる障害を発生（注入）させるだけでなく、仮定をテストし、未知の問題を見つけることがいかに重要かということを思い知らされました。

特に、規制の流れは波及してくる可能性があるとおもいますので、カオスエンジニアリングがより注目されるかなと思いました。