AWS Lambdaのプログラミング

第8章. 高度なAWS Lambda

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

本書の終盤にさしかかり、本番環境に耐えうるアプリケーションを作り始めるにあたって重要なLambdaのエラー処理、スケーリング、そして、いつも使うわけではないが、必要な時に必要で重要なLambdaの機能を学ぶ時が来た。

エラー処理

もちろん、現実の世界に戻れば、うまくいかないこともある。有用な本番アプリケーションやアーキテクチャは、コードのエラーであれ、依存するシステムのエラーであれ、エラーが発生した場合に対処する必要がある。

AWS Lambdaは "プラットフォーム "であるため、エラーに関しても一定の制約や振る舞いがある。このセクションでは、どのような種類のエラーが、どのようなコンテキストで起こりうるのか、そしてどのようにエラーを処理できるのかについて掘り下げていく。 言語メモとして、我々はエラーと 例外という言葉を、Javaの世界で2つの用語の間に生まれるニュアンス抜きで、同じ意味で使っている。

エラーの種類

Lambdaを使用する場合、発生する可能性のあるエラーにはいくつかの種類がある。 主なものは、イベントの処理を通じて発生する可能性のある時間から大まかに並べると以下のようになる：

1. Lambda関数の初期化エラー（コードの読み込み、ハンドラの位置、関数のシグネチャに問題がある）。

2. 入力を指定された関数パラメータにパースする際のエラー

3. 外部の下流サービス（データベースなど）との通信エラー。

4. Lambda関数内で発生したエラー（そのコード内か、メモリ不足の問題のような直接的な環境内のいずれか）。

5. 関数のタイムアウトによるエラー

エラーを処理済みエラーと未処理エラーに分ける方法もある。

例えば、下流のマイクロサービスとHTTPで通信し、エラーを投げる場合を考えてみよう。 この場合、Lambda関数内でエラーをキャッチし、そこで処理する（ハンドリングエラー）こともできるし、エラーを環境に伝播させる（アンハンドリングエラー）こともできる。

あるいは、Lambdaのコンフィギュレーションで間違ったメソッド名を指定したとしよう。 この場合、Lambda関数のコードでエラーをキャッチすることができないため、常にアンハンドリングエラーとなる。

もし、コード内でエラーを処理するのであれば、Lambdaはエラー処理戦略とは関係ない。 必要であれば、標準エラーにログを記録することもできるが、第7章で見たように、Lambdaに関する限り、標準エラーは標準出力と同じように扱われ、標準エラーに内容が送信されてもアラームは発生しない。

したがって、Lambdaでのエラー処理に伴うニュアンスは、捕捉されない例外を介してLambdaの実行時にコードからバブルアウトするエラーや、コードの外部で発生するエラーなど、処理されないエラーに関するものばかりだ。 これらのエラーはどうなるのだろうか？ 興味深いことに、これは、これから検証するように、そもそもLambda関数のトリガーとなるイベントソースの種類に大きく依存する。

Lambdaエラー処理の様々な振る舞い

Lambda 、呼び出しのトリガーとなったイベント・ソースによって、エラーの処理内容を分けている。すべてのイベント・ソースは、第5章でリストアップしたイベント・ソース・タイプのいずれかに分類される（表5-1）：

• 同期イベントソース（APIゲートウェイなど） ...