400 社の企業を対象とした調査に基づく Gremlin の 2021 年カオス エンジニアリングの現状レポートでは、高可用性とカオス エンジニアリングの頻繁な使用の間に相関関係があることが示されています。
カオスエンジニアリングとは、サービスの耐障害性をテストするために、意図的に障害を注入する手法です。AWSのCTO、ワーナー・フォーゲルス氏が先月のre:Inventで述べたところによると、AWSは今年初めに、このカオスエンジニアリングの独自バージョンである「Fault Injection Service」を導入する予定です。
カオスエンジニアリング企業 Gremlin による新しい調査には、DevOps と可観測性分野の企業である Dynatrace、Epsagon、Grafana Labs、LaunchDarkly、PagerDuty の協力があり、中小企業から大企業までさまざまな規模の企業から回答者が集まりました。
回答者の70%以上は、ソフトウェア・サービス企業、または銀行・金融サービス業界の技術者からのものでした。58%がワークロードの半分以上をパブリッククラウドで運用していると回答し、AWSが38%を占め、これにGoogleとMicrosoftがそれぞれ12%で続きました。「使用しているデータベースは何ですか？」という質問に対しては、回答者のMySQLまたはPostgreSQLがそれぞれ22%、MongoDBが16%、DynamoDBが14%、Cassandraが5%と回答しました。OracleまたはSQL Serverのユーザーにはどのような影響があったのか、また複数のデータベースマネージャーを使用しているユーザー（おそらくほとんどの組織で大多数を占める）が調査でどのように扱われたのかは不明です。
AWSはCloudShellでAzureとGCPに追いつき、意図的に混乱を招いている
続きを読む
調査によると、回答者の57.5%が99.5%以上の「平均可用性」を達成しているものの、大半は月に1～10件の「重大度の高いインシデント」が発生しており、平均解決時間（MTTR）は75%以上のケースで1時間を超えていると報告しています。発生する可能性のある問題としては、不具合のあるコードのデプロイ、依存関係の問題、構成エラーなどが挙げられ、頻度はこの順になっています。
レポートの核心は、99.99%の可用性と1時間未満のMTTRを達成したトップパフォーマーが、他のグループと何が違うのかを検証するセクションです。調査の出典を考えると当然ですが、このグループは他のグループよりも多くのカオス実験を実施しており、23%が週ごとまたは毎日カオス実験を実施しています。一方、最もパフォーマンスの低いグループ（99%未満の可用性）では、同じ実験を行ったグループが10.8%でした。
ただし、この統計から多くの結論を導き出すのは慎重な判断が必要です。これらのトップパフォーマーは、オートスケーリングの利用率（65% vs. 43%）、DNSフェイルオーバーまたはElastic IPの利用率（49% vs. 24%）、ロードバランサーの利用率（77% vs. 71%）、マルチリージョンレジリエンスの利用率（アクティブ/アクティブ：38% vs. 19%、アクティブ/パッシブ：46% vs. 30%）も高くなっています。
アクティブ/アクティブ構成では、複数のリージョンのデプロイメントがライブであり、障害発生時に引き継ぐことができますが、アクティブ/パッシブ構成では、別のリージョンのデプロイメントが必要に応じて使用できる状態になっています。
もう 1 つの回復力技術はサーキットブレーカー パターンです。このパターンでは、サービスが過負荷になったり障害が発生したりした場合に、さらなる問題を引き起こす可能性のある再試行を繰り返すのではなく、通話が自動的に代替サービスに切り替えられます。最高のパフォーマンスを誇る企業の 32 % がサーキットブレーカーを使用していますが、最もパフォーマンスの低い企業ではわずか 16 % です。
他にも、データベースのレプリケーション、リトライロジック（最初の失敗で諦めずに再試行するアプリケーション）、機能強化を一部の顧客に展開するといった選択的なロールアウト、動的コンテンツに障害が発生した場合に備えたページのキャッシュ、定期的なヘルスチェックの実行といった一般的な手法が挙げられます。これらの事例すべてにおいて、これらの手法を使用している企業は、使用していない企業よりも平均してダウンタイムが少なくなっています。
これらのレジリエンス対策には、まず導入のためのクラウドインフラ、次に設定に必要な管理時間とスキルといったコストがかかります。このレポートを解釈する別の方法は、レジリエンスへの投資額が大きいほど、レジリエンスが向上するということです。データは確かに、カオスエンジニアリングの活用度が高いほどレジリエンスが高いことを示していますが、トップパフォーマーが実施している他の対策と比較して、カオスエンジニアリングがレジリエンス向上の要因としてどの程度評価されているかは不明です。
しかし、大規模組織の方が混沌を好むと考えるのは誤りです。レポートによると、この手法が最も多く利用されているのは従業員数5,001人から10,000人の企業で、70%以上が何らかの形でこの手法を利用しています。大規模組織、小規模組織ともに、この手法の利用率は低いようです。
組織は本番システムにカオスを注入するリスクを負っているでしょうか？ かなりの少数（34%）がまさにそうしています。それ以外の組織では、カオステストはステージングシステムや開発システムに限って実施されています。本番環境に障害を注入することはリスクを伴いますので、注意が必要なのは当然です。
とはいえ、開発システムでのレジリエンス テストの有効性は限られています。開発システムは、本番環境と同じ規模であったり、同じ使用パターンであったりする可能性が低いためです。回答者の 11 % は、「何か問題が発生するかもしれないという恐れ」からカオス エンジニアリングを敬遠しています。
レジリエンスは困難であり、コストもかかります。カオスエンジニアリングは、近々登場するAWSサービスが示すように、ますます普及しつつあります。しかし、他の一般的な技術の全てに取って代わるものではありません。カオスエンジニアリングは、それらを置き換えることを目的としているのではなく、それらが実際に機能することを示すことを目的としているのです。®
