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

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

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

特徴 説明
マネージドサービスからの非同期実行 前回まで解説してきたS3へファイルアップロードした後のイベント駆動実行のように、AWSのマネージドサービスから非同期的に処理が実行されるケースでも使用される。API Gatewayから同期的にLambdaを呼び出す場合もあるが、サーバにかかる負荷を逃したいケースなどサーバレスが求められる場合は、非同期処理のかたちでLambdaを利用する機会も多くなる。非同期処理におけるエラーハンドリングで、マネージドサービスを活用して、しかるべき対象に適切なエラー通知を実装していく必要がある
リトライ/通知機能、マネージドサービス連携 AWS Lambdaで処理中に発生したエラーのハンドリング処理として、Lambda自体でリトライしたり、CloudWatchやSNS/SQSなど、さまざまなマネージドサービスと連携したりして通知することができる。通知先や内容によって適切に使い分けることが必要となる

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

イメージ

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

項番 説明
1 AWS Lambdaを同期的に呼び出す場合のエラーハンドリングパターン。LambdaはAPI Gatewayを介して、同期的に呼び出される
(1-a) AWS Lambdaを同期的に呼び出し、実行中にエラーが発生した場合、呼び出し元にエラーメッセージを通知する
(1-b) AWS Lambdaを同期的に呼び出し、実行中にエラーが発生した場合、CloudWatch Logsへエラーが出力される
(1-c) CloudWatch Logsへ特定のエラーが出力されたことを検知して、エラーの後処理を行う別のLambdaファンクションを実行する
(1-d) CloudWatch Logsへ出力されたメッセージをフックして、Mattermostなどのチャットコミュニケーションツールの特定のチャネルへ出力する
(1-e) システムの管理者や運用担当者がボット用のチャネルを通じて、通知されたエラーを確認する
2 AWS Lambdaが非同期的に呼び出される場合のエラーハンドリングパターン。前回までに解説した通り、S3へファイルアップロードされたイベントを契機に、Lambdaファンクションが呼び出される
(2-a) S3へファイルがアップロードされたことをイベントの契機として、Lambdaファンクションが実行される
(2-b) 非同期に呼び出されたAWS Lambdaの実行中にエラーが発生した場合、CloudWatch Logsへエラーが出力される
(2-c) 非同期に呼び出されたAWS Lambdaの実行中にエラーが発生した場合、エラー発生内容をアップロードしたユーザに通知するためにSQSへキューを送信する
(2-d) 非同期に呼び出されたAWS Lambdaの実行中にエラーが発生した場合、デッドレターキューを使って、Amazon SNSへ通知を行う
(2-e) デッドレターキューが通知するSNSトピックがエラー発生をシステム管理者や運用担当者へSMSで通知する
(2-f) デッドレターキューが通知するSNSトピックがエラー発生をシステム管理者や運用担当者へメールで通知する

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

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

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

種類 説明
ビジネスエラー アプリケーションのビジネスロジック上想定されるエラー(在庫がない、入力されたログインIDがないなど)。システム管理者や運用者による対処が不要で、エラーが発生した処理を実行したユーザにエラー内容を通知し、適切な対処やオペレーションを促す
システムエラー システムが正常稼働しているときには発生しない、もしくはシステム全体に影響を及ぼす致命的な問題が発生しているときのエラー(アプリケーションバグで発生したエラーやデータベースがダウンしているなど)。システム管理者や運用者による対処が必要であり、ユーザーにエラー内容を通知しても、ユーザー側では対処しようがないため、エラーが発生したことのみを通知し、コールセンターへの連絡や、時間をおいてからの再実行を促す

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

* * *

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

著者紹介


川畑 光平(KAWABATA Kohei) - NTTデータ
エグゼクティブ ITスペシャリスト ソフトウェアアーキテクト・デジタルテクノロジーストラテジスト(クラウド)

金融機関システム業務アプリケーション開発・システム基盤担当、ソフトウェア開発自動化関連の研究開発を経て、デジタル技術関連の研究開発・推進に従事。

Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。AWS Top Engineers & Ambassadors選出。

本連載の内容に対するご意見・ご質問は Facebook まで。