Lambda 関数へカオスを注入する AWS Fault Injection Service の新機能

金融サービスなどの規制産業でのサーバーレス技術の利用が増加しています。この成長に伴い、堅牢な復元力の検証が求められています。信頼性と可用性の高いサーバーレスアプリケーションを検証するために、サーバーレスのためのカオスエンジニアリングが重要になっています。サーバーレスコンポーネントに意図的に障害や負荷を注入することで、チームは隠れた弱点を発見し、システムの耐障害性を検証できます。

これまで、AWS Lambda でカオス実験を行うためのオプションは 2 つありました:

コードを変更し、ランタイム固有のライブラリを使用する
Runtime API プロキシパターンを活用したセルフマネージドの Lambda 拡張機能を使用して障害を注入する

どちらの方法も AWS Fault Injection Service (AWS FIS) と統合するために、開発者の関与とコード管理が必要でした。
2024 年 10 月 30 日、AWS Lambda 関数をターゲットとする AWS FIS アクションがリリースされました。このネイティブ統合はプロキシパターンを活用しながら、お客様自身で拡張機能を管理する必要がなくなりました。これにより、AWS FIS の実験テンプレートのシンプルさと再利用性が向上し、サーバーレスカオス実験の管理負担が軽減されました。このブログ記事では、この新しいアプローチの仕組みと、Lambda 関数を対象としたカオス実験を大規模に実行する方法について説明します。

概要

AWS FIS は、実行環境内で別のプロセスとして実行される「カオス」の Lambda 拡張機能を使用して、AWS Lambda 関数に障害を注入します。この拡張機能は、呼び出しがランタイムに到達する前にインターセプトします。以前の記事「AWS Fault Injection Service と AWS Lambda を使用したカオス実験の自動化」で説明したように、拡張機能は関数呼び出しのリクエストとレスポンスのライフサイクルにフックします。 AWS マネージドの拡張機能により、実験テンプレートで直接 Lambda アクションとターゲットを定義できるため、プロセスが簡略化されます。
この統合により、タイミングを制御した実験を実行しやすくなります。Lambda 拡張機能を自分で管理する必要がなくなり、運用オーバーヘッドが削減されます。

仕組み

この新機能を説明・デモンストレーションするために、このブログ記事全体で 1 つのサンプルサーバーレスアプリケーションを使用します。このアプリケーションは、Amazon API Gateway、AWS Lambda、Amazon DynamoDB を使用して構築されており、注文を管理するためのシンプルな CRUD (Create, Read, Update, Delete) 機能を提供します。このデモ環境のコードは、aws-fis-actions-for-lambda の GitHub リポジトリで入手できます。

AWS FIS を使用して AWS Lambda 関数に障害を注入するには、2つのことが必要です：

FIS 管理拡張機能を Lambda 関数に追加し、環境変数で設定する
Lambda 関数をターゲットとするアクションを指定した FIS 実験テンプレートを作成する

実験を開始すると、AWS FIS は実験の設定を AWS アカウント内の Amazon Simple Storage Service (Amazon S3) バケットに書き込みます。AWS FIS 管理拡張機能は Amazon S3 から設定を読み取り、実験テンプレートで定義された障害を注入します。以下のセクションでは、このメカニズムと正しい設定方法についてさらに詳しく説明します。

AWS FIS Lambda アクション

FIS Lambdaアクションのローンチにより、FIS実験テンプレートで以下の3つのアクションが利用可能になりました：

開始遅延の追加: aws:lambda:invocation-add-delay
統合レスポンスの変更: aws:lambda:invocation-http-integration-response
呼び出しエラーの強制: aws:lambda:invocation-error

より詳細な説明については、AWS FIS の Lambda アクションリファレンスをご参照ください。

ターゲットの選択

FIS の実験では、Amazon Resource Names (ARN) 、またはタグを使用してターゲットの Lambda 関数を選択できます。

AWS FIS は、qualifier (修飾子) を通じて Lambda 関数の障害注入を正確に制御できます。修飾子を指定することで、Lambda 関数の特定のバージョンまたはエイリアスをターゲットにすることができます。空のままにすると、FIS はバージョンやエイリアスに関係なくすべての呼び出しをターゲットにします。バージョン番号またはエイリアスを含めると、FIS は $LATEST エイリアスを含む、その特定のバージョンまたはエイリアスへの呼び出しのみに影響を与えます。

AWS FIS マネージド拡張機能

AWS FIS マネージド拡張機能は、AWS Lambda レイヤーとして実装されたサーバーレスカオスエンジニアリングの重要なコンポーネントです。AWS は、サポートされている各リージョンの個別の AWS 管理アカウントを通じて、このレイヤーを公開しています。ARM および x86 バージョンの ARN には、ドキュメントと AWS Systems Manager Parameter Store を通じてアクセス可能で、IaC、CI/CD パイプライン、または手動プロセスを使用して Lambda 関数と簡単かつ安全に統合できます。

この拡張機能の有効性は、Lambda 実行環境のライフサイクルとの統合に起因します。関数のランタイムとそれに続く呼び出しの前に初期化を行うことで、最初の関数呼び出しの前に進行中の FIS 実験と設定を確認できます。
パフォーマンスへの影響を最小限に抑えるため、拡張機能は Amazon S3 から非同期でポーリングを行い、初期化時と関数実行と並行してキャッシュします。この非同期のアプローチにより、関数実行時間への影響が最小限に抑えられます。さらに、拡張機能は実験状態に基づいて動作を最適化する適応型ポーリング戦略を採用しています。

スロー・ポーリング

実験が実行されていない場合、拡張機能はスロー・ポーリングを開始します。

このモードでは、より長い間隔（デフォルト 60 秒）となり、通常の Lambda 実行中の運用オーバーヘッドを最小限に抑えます。 Lambda 呼び出しは影響を受けることなく継続され、拡張機能は潜在的な実験に備えた状態を維持します。

ファスト・ポーリング

FIS Lambda 拡張機能がアクティブな実験を検出すると、ファスト・ポーリングタイマーを開始し、FIS実験設定で定義された障害の注入を開始します。

ファスト・ポーリングタイマーの間隔は 20 秒に固定されています。

この短い間隔により、以下が確保されます：

実験設定に基づく迅速な障害注入
実験終了時の通常運用への素早い復帰

このデュアルモード戦略により、通常運用時の影響を最小限に抑えながら、アクティブな実験中の高い応答性を実現し、AWS FIS を使用したサーバーレスカオスエンジニアリングの効率性を高めています。

障害注入の判断

各 Lambda 関数呼び出しの開始時に、拡張機能は確率判定を行います。この確率判定はキャッシュされ、設定されたアクションとその呼び出し確率を考慮して、個々の障害アクションごとに判断するために使用されます。呼び出し確率 (invocation percentage) は、1 回の呼び出しでアクションが実行される可能性を意味する設定値です。各障害アクションは、関数ハンドラーの実行前または後に順番に評価されます。

評価は、現在キャッシュされている設定状態に基づいて行われます。拡張機能は設定を非同期でポーリングするため、関数呼び出し中に状態が変更される可能性があります。つまり、開始時と終了時に障害を注入する実験（例：aws:lambda:invocation-add-delay とaws:lambda:invocation-http-integration-response）がある場合、一方が適用され、他方は適用されない可能性があります。

Lambda 関数の設定

FIS 拡張機能をレイヤーとして AWS Lambda 関数に追加した後、以下の環境変数を設定する必要があります：

AWS_FIS_CONFIGURATION_LOCATION

これは、AWS FIS が設定配布に使用する S3 バケットの ARN に設定します（’/’デリミタとオプションのキー名プレフィックスを含む）。

例：

arn:aws:s3:::my-config-distribution-bucket/
arn:aws:s3:::my-config-distribution-bucket/FisConfigs/

この変数値は、拡張機能が障害設定を取得する場所を指示します。AWS FIS は、ターゲットとなる Lambda 関数からこの値を照会して、障害設定をどこに書き込むかを判断します。

ターゲット選択で qualifier (修飾子) が指定されている場合、AWS FIS は明示的に指定された各バージョンまたはエイリアスの AWS_FIS_CONFIGURATION_LOCATION の値を検査し、それぞれの場所に書き込みます。qualifier が指定されていない場合、FISは書き込み場所を決定するために $LATEST の設定のみをチェックします。ターゲットリストに含まれていないAWS_FIS_CONFIGURATION_LOCATION の値を持つバージョン（環境変数はバージョン固有のものです）には、障害設定が送信されません。

AWS_LAMBDA_EXEC_WRAPPER

AWS_LAMBDA_EXEC_WRAPPER 環境変数の値を/opt/aws-fis-bootstrapに設定します。

注意

この変数は、FIS Lambda レイヤーが追加された後にのみ設定し、レイヤーを削除する前に解除する必要があります。レイヤーがインストールされていない状態でこの変数を設定すると、すべての関数呼び出しで 500 エラーが発生します。

AWS_FIS_EXTENSION_METRICS

埋め込みメトリックフォーマット（EMF）ログを出力したい場合は、AWS_FIS_EXTENSION_METRICS 環境変数を all に設定します。デフォルトでは、拡張機能は EMF ログを出力せず、AWS_FIS_EXTENSION_METRICS は none がデフォルト値となっています。

実験

サンプル CRUD アプリケーションを含む aws-fis-actions-for-lambda GitHub リポジトリは、AWS FIS Lambda アクションを使用した実験テンプレートを提供しています。開始するにはリポジトリの README を参照してください。

実験 1

実験テンプレート Lambda Latency Injection Fault は、10 分間、100 % の呼び出しに対して 2 秒の起動遅延を発生させます。これにより、すべての呼び出しが通常以上の起動遅延を持つ場合に、サーバーレスの CRUD API がどのように動作するかを理解できます。この実験では、タグベースのターゲット選択を使用し、タグ FISExperimentReady = Yes を持つすべての Lambda 関数が選択されます。

障害注入の影響を測定するために、Artillery と呼ばれる負荷試験ソリューションを使用します。このツールによりオーダーの作成と取得のためのリクエストを送信します。実行手順は README の Run the experiment から確認してください。load-generation-config.ymlを編集し、必要に応じて実験期間やリクエスト数を変更できます。 Artillery のメトリクスは Amazon CloudWatch に公開されます。クライアントサイドの動作を表す Artillery メトリクス、API Gateway メトリクス、Lambda メトリクスは、単一の可観測性ダッシュボードで可視化できるよう、あらかじめ設定されています。

サンプルアプリケーションをデプロイした後、AWS コンソールで CloudWatch に移動し、ダッシュボードを選択すると、追加の 2 秒の遅延の影響を受けた関数呼び出しを確認できます。

実験 2

この API 実行の成功に影響を与える障害が発生した場合の動作を理解するために、Modify Function Output Fault という実験テンプレートを作成しました。このテンプレートアクションは、10 分間、AWS Lambda 呼び出しの 100 % に対して HTTP ステータスコード 500 を注入します。

注意点として、preventExecution のパラメータを true に設定すると、AWS Lambda は起動されるものの、意図した機能（Amazon DynamoDBの更新）を実行せずに、設定された statusCode を返します。

まとめ

AWS FIS Lambda アクションにより、カオスエンジニアリングの形で障害注入実験を適用することで、ワークロードの回復力を定期的に検証することが容易になりました。これにより、コードを変更し開発者を関与させることなく、AWS Well-Architected Framework のベストプラクティスに従うことができます。

このブログ記事では、サーバーレスアプリケーションの回復力を強化する新機能の概要と、使用方法について説明しました。サンプルアプリケーションをデプロイして実践した場合は、リポジトリの README ファイルのガイダンスに従ってクリーンアップすることを忘れないでください。

AWS FIS Workshop もご覧ください。このワークショップは、サーバーレスカオス実験のセットアップや、他のAWS サービスにわたる様々な障害注入シナリオについて、包括的なガイドを提供しています。

—

本記事の翻訳はソリューションアーキテクト新谷が担当しました。原文はこちらです。

Amazon Web Services ブログ