【AWS・Lambda】エラーハンドリングの基礎 ~ Design for Failure ~

はじめに

Lambdaのエラーハンドリングについて、
『AWS Japan Summit Online 2020』のオンラインセッションで学んだ [ Design for Failure ] の考え方をまとめます。

Lambdaの実行中には様々なエラーが予想されます。
それらに適切に対応するためのデザインが必要です。

Lambda関数は、エラーを受け取ると基本的に複数回リトライを行います。
不要なリトライは、膨大なログデータを発生させたり、無限にリトライし続けることで膨大な料金になってしまうことも考えられます。

そのため、エラーに適切な対処ができるようあらかじめ準備していかなければなりません。

エラーへの対処には、主に以下3つの方法が考えられます。

1~3のそれぞれを詳しく見ていきましょう。

無駄なリトライはトラブルの元です。リトライ設計を適切に考える必要があります。

リトライ設計で考慮するポイントは以下の通りです。

イベントソース（つまりLambdaにイベントを渡す元）によって、制御で考慮するポイントが異なります。

エラーが不要に伝播することも、避けなければなりません。
主に、以下２点に注意して設計を行います。

以下２点について忘れずに設定を行うことで対策が可能です。
処理結果による分岐が可能になるからです。

緊急停止の仕組みをあらかじめ構築しておき対策します。

エラー時のデータ不整合への対策を行います。
データの不整合には以下の２つのケースが考えられます。

バッチ（複数のレコード処理）を起動中にエラーが発生すると、すでに完了済みのレコードについても再度リトライが発生するなどのケースです。

以下２点について忘れずに設定を行うことで対策が可能です。

一つのLambdaで複数のリソースを更新する場合があります。

例えば、一つのLambdaでDynamoDBとAuroraの両方を更新するケースなどです。

DynamoDBの更新は成功したが、Auroraの更新が失敗した場合、確定したDynamoDBのデータ変更を取り消してリトライする仕組みが必要です。

データ変更の取り消しとは、成功した処理の逆の処理を行うことです。（反対処理）

反対処理の実装を全てのロジックに行うと、膨大な記述が必要です。
そのため、ステートマシンを利用した制御が推奨されています。

AWS Step Functionsを活用し、個別の関数を組み合わせたワークフローとして実装します。

エラーへの対処として以下3つのポイントがありました。

また、これらを実現するために、
疎結合な小さなコンポーネントの組み合わせで処理を実装することが大切です。