AWS Lambdaにおけるサーバレスエラーハンドリング(1)

前回は、S3へファイルアップロードした後の後続処理をAWS Lambdaを使ってサーバレスで実行するアプリケーションを実装しました。今回からは、AWS Lambdaでエラーが発生した場合のさまざまなエラーハンドリングの実装方法について解説していきます。

AWS Lambdaを使ったエラーハンドリング

サーバレスコンピューティングサービスであるLambdaを利用したエラーハンドリングは通常のアプリケーションで実装する場合と何が異なるのでしょうか？ 大きな特徴として、以下のようなものが挙げられます。

これを踏まえ、今回からは代表的なエラーハンドリングのパターンとして、以下の図のようなケースを解説していきます。

各ケースの詳細は以下の通りです。

次回以降、上記のケースをSpring Cloud FunctionやCloudFormationを使って構築する実装を順次解説してきますが、その前の前提として、本連載で取り扱うエラーの概念について説明します。

エラーの概念、対処の考え方

本連載では、エラーをビジネスエラーとシステムエラーの2種類に分けて取り扱います。これらは、TERASOLUNAガイドラインの「例外の種類」で述べられている「ビジネス例外」と「システム例外」とほぼ同義です。以下の表に、エラーの種類と基本的な対処方針についてまとめました。

エラーの種別により、通知するべき対象や内容は異なります。加えて、前節でも説明した通り、Lambdaではマネージドサービスを契機とした非同期処理などでユーザー側への通知処理が複雑化するケースがあります。また、通知を行う機能やマネージドサービスが複数存在し、通知する内容によって適した方式も変わってくるので、Lambdaで実装する処理の内容に応じて、適切なエラーハンドリング方法を選択するようにしましょう。

*　*　*

今回はLambdaファンクションのエラーハンドリングの特徴と代表的なパターン、エラーの概念／対処の考え方について説明しました。次回以降は、API GatewayとLambdaおよびSpringCloudFuntionを使って構築したLambdaを同期的に呼び出した場合に発生したエラーの取り扱い方や環境構築方法を解説します。