Amazon Web Services ブログ

AWS Fault Injection Simulator と AWS CodePipeline を利用したカオス実験について

COVID-19 のパンデミックは、ここ数世代で私たちのテクノロジー・インフラにとって最大のストレステストであることが証明されました。在宅勤務や学校教育の影響もあり、インターネットのトラフィックは急激に増加しました。
パンデミック初期の数か月は混沌とした状況でしたが、本番環境におけるレジリエンスの価値を明確に示したとも言えます。将来、このような世界的な出来事に備えて、重要なシステムをより安全に構成するにはどうすればよいでしょうか。アプリケーションアーキテクチャのテストと検証には、よりモダンなアプローチが必要です。このような課題を解決する革新的なアプローチとして、カオスエンジニアリングが登場しました。

このブログでは、継続的インテグレーション/継続的デリバリー (CI/CD) プロセスの一部としてカオス実験を自動化するためのアーキテクチャパターンを紹介します。CI/CD パイプライン内でのカオス実験を自動化することで、複雑なリスクやモデル化された障害シナリオを、デプロイのたびにアプリケーション環境に対してテストできます。アプリケーションチームは、これらの実験の結果を使用して、アーキテクチャの改善に優先順位を付けることができます。これらの取り組みは、予測不可能な本番環境の運用について、チームに自信をもたらします。

AWS Fault Injection Simulator（FIS）は、AWS のワークロードに対してフォールトインジェクションを行うことができるマネージドサービスです。フォールトインジェクションは、カオスエンジニアリングの原則に基づいています。これらの実験では、障害イベントを発生させることでアプリケーションに負荷をかけ、アプリケーションにどのような影響があるか観測します。この情報を利用して、アプリケーションのパフォーマンスと回復力を向上させることができます。AWS FIS は、アプリケーションの問題点を明らかにするために、実環境を模擬した条件でカオス実験を設定・実行することができます。

AWS CodePipeline は、アプリケーションとインフラストラクチャを迅速かつ確実に更新できる、フルマネージド型の継続的デリバリーサービスです。AWS CodePipeline を使用することで、ビルド、テスト、リリースといったソフトウェアリリースプロセスをモデル化及び自動化し、各コードが変更された後即座にテストできます。各変更をステージングとリリースプロセスで実行することで、アプリケーションやインフラストラクチャのコードの品質を確保できます。

カオス実験の継続的実行

図1. カオスエンジニアリングを自動化するためのアーキテクチャパターンの全体概要

AWS FIS 実験の作成

まず、アプリケーションアーキテクチャのターゲットリソースに対して実行するアクション (アクションセット) を 1 つ以上設定して、 AWS FIS 実験テンプレートを作成します。ここでは、タグで識別される Amazon Elastic Container Service (ECS) クラスター内の Amazon EC2 インスタンスを停止するアクションを作成しました。ターゲットリソースは、リソース ID、フィルター、またはタグによって識別できます。実行するアクションの継続時間や前後のアクションをアクションパラメータとして設定することもできます。さらに、Amazon CloudWatch アラームを設定して、特定のしきい値または制限値に達すると、1 つまたは複数の実験を停止することができます。「Increase your e-commerce website reliability using chaos engineering and AWS Fault Injection Simulator」という記事では、Bastien Leblanc が、実験の停止条件として CloudWatch メトリクスのしきい値を設定する方法を紹介しています。

図2. AWS FIS 実験テンプレート

AWS Lambda を作成して AWS FIS の実験を開始

[設定] の [アクセス権限] セクションで、 Lambda 関数に AWS FIS 用の IAM ロールを作成/追加します。特定の AWS FIS の実験を開始するには、Lambda コードの ExperimentTemplateId パラメーターを使用します。Lambda コードを作成する際は、AWS FIS API リファレンスを参照してください。Lambda 関数をパイプラインに統合する場合、新しい AWS CodePipeline を作成することも、既存のものを使用することもできます。Lambda 関数を開始した時点で (デプロイステージの後)、新しいパイプラインステージが追加され、AWS FIS 実験が開始されます。

図3. AWS Lambda 関数内で AWS FIS 実験を呼び出し

図4. AWS CodePipeline における FIS-Experiment ステージ

ExperimentTemplateId パラメータは、Lambda 関数設定のキー/値の「環境変数」として定義することもできます。これは、関数コードを調整することなく AWS FIS 実験テンプレートを変更できるため便利です。本番環境にデプロイする過程で複数の環境に ExperimentTemplateId を動的に注入することで、同じ Lambda 関数コードを利用できます。

デプロイされたアプリケーションでのFIS実験結果の検証

AWS CodePipeline にてデプロイ完了後も継続的にフォールトインジェクションを実行することで、解決すべき複雑な障害条件について学ぶことができます。通知ルールを用いることで、AWS FIS 実験中のアプリケーションのユーザーエクスペリエンスと可用性についてテストすることができます。AWS CodePipeline では、Amazon Simple Nortification Service (SNS) トピックまたはチャットボットと統合できます。CloudWatch Synthetics は、他の AWS FIS 実験を行いながら、候補となるアプリケーションの UI/UX テストを自動化したい場合に使用できます。

図5. AWS コードパイプラインの通知ルール設定

サマリー

AWS CodePipeline と AWS FIS を組み合わせることで、簡単にアプリケーションアーキテクチャのカオス実験を自動化することができます。CI/CD パイプラインの中でフォールトインジェクションを自動化することの利点は次のとおりです。

  • アプリケーションの耐障害性要件を満たすことに関して、自信を得ることができます。AWS CodePipeline を使った既存のC I/CD パイプラインの中で、テストおよび実験の自動化に対してよりモダンなアプローチを採用しています。
  • アプリケーションに対する未知のリスク(Unknowns)に対して理解を深めることができます。すべてのテスト結果はチームにとって価値と学習の機会を提供します。これらの結果を活用して、アプリケーションの要件に基づいて、うまくいっている点や改善が必要な点、許容できる点を把握します。
  • CI/CD 内でアーキテクチャの適合性を継続的に評価することで、各機能やコンポーネントのイテレーション (短期間で開発を繰り返すこと) がアプリケーションのレジリエンシーに与える影響を検証できます。

しかし、アプリケーションで表面化したリスクを発見し、修正し、文書化することだけがカオス実験の自動化の唯一の価値という訳ではありません。アラートやアラーム、モニタリング、通知などの運用方法を常に検証することで、さらなる信頼性を得ることができます。

AWS FIS を活用し、実験に必要な条件を再現して制御された反復可能な実験を定義することで、運用手順やランブックを改善することができます。この実験を CI/CD パイプラインで自動化することで、運用手法のフィードバックループを継続的に確保できます。

  • AWS FIS のその他の実験例を確認したい場合は、AWS サンプル GitHub をご覧ください。
  • AWS FIS に関するその他のブログ投稿はこちら（AWS FIS に関する英語版ブログ投稿はこちら）

(本記事は 2021/08/10 に投稿された Chaos Testing with AWS Fault Injection Simulator and AWS CodePipeline を翻訳した記事です。翻訳はソリューションアーキテクト河角が担当しました。)

Matt Chastain

Matt Chastainは、ペンシルベニア州チェスター郡を拠点とするAWSソリューションアーキテクトです。技術業界で20年のベテランとして、システムの複雑性の緩和やビジネス価値を促進するアーキテクチャソリューションを設計することを楽しんでいます。仕事以外では、ゴルフ、水耕栽培、妻のジェシカと娘のエマ、オリビア、ソフィアと過ごす時間を楽しんでいます。

Jennifer Moran

Jennifer Moranは、ニューヨークを拠点とするAWSソリューションアーキテクトです。ソフトウェア開発、アジャイルリーダーシップ、DevOpsなど、多くの技術分野で働いてきた多様な経歴を持っています。技術的な課題に対する創造的なソリューションの設計を支援することに喜びを感じています。旅行や家族とのアウトドアも好きな趣味のひとつです。

Pavankumar Kasani

Pavankumar Kasaniは、ニューヨークを拠点とするAWSソリューションアーキテクトです。AWSクラウド上でスケーラブルかつ適切に設計され、モダナイズされたソリューションの設計を支援することに情熱を注いでいます。仕事以外では、家族と過ごす時間、クリケット、卓球、そしてキッチンで新しいレシピを試すことが好きです。