マイナビニュースマイナビ

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

【連載】

AWSで作るクラウドネイティブアプリケーションの応用

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

[2021/03/12 09:00]川畑 光平 ブックマーク ブックマーク

前回は、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 まで。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

一覧はこちら

連載目次

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で TECH+ の人気記事をお届けします
注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
Google Workspaceをビジネスで活用する
ニューノーマル時代のオウンドメディア戦略
ミッションステートメント
教えてカナコさん! これならわかるAI入門
AWSではじめる機械学習 ~サービスを知り、実装を学ぶ~
Kubernetes入門
SAFeでつくる「DXに強い組織」~企業の課題を解決する13のアプローチ~
AWSで作るマイクロサービス
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

会員登録(無料)

ページの先頭に戻る