サーバーレスアプリケーション開発におけるエラーハンドリング

ワークフローパターンは、条件分岐を含むシーケンシャンルなステップの集合です。それらのハンドリングを一つのプログラムモジュールで実現しようとすると、条件判断や、エラーハンドリング、リトライ、などのビジネスロジック外の本質的ではないコードが多く記述されることになり、また単一のモジュールにすべての処理をまとめると、各々の処理が密結合になるリスクなどもあります。

こういったリスクを排除するために、ワークフローエンジンを利用し、各処理単位で独立したタスクに切り出したプログラムモジュールを組み合わせて、本質的ではないタスク間の連携処理については、ワークフローエンジンの設定や関数を利用することで、ワークフローが抱える複雑性を軽減させたりします。

切り出された各タスクは、本質的なビジネスロジック実行単位で独立していて、細かいプロビジョニングが可能になる点において、ワークフロー処理も、サーバーレスと相性の良いユースケースになります。

ステート分散ワークフローパターンにおける特性として、分散アプリケーションとステートの管理が挙げられます。

先程述べたように、ステート分散ワークフローパターンでは、緊密な結合を回避するために、処理単位で独立したタスクへの切り出しを行いますが、その事によってタスク間におけるデータベースの操作を行う際に、ACID 特性 の担保が難しくなる問題が発生します。例えば、EC サイトであれば、商品の購入のフローおいて、在庫の確保、ポイント利用の計算、決済の実施、を行うとなると、3 つのサービス間でアトミックにデータの変更をどのように行う必要があるかと思います。こういった問題への対策の一例として、タスクごとに異なるデータベースを参照する場合、2 フェーズ コミットなどの利用を行い、タスク間のデータ連携及びタスク間で共有されるデータの論理的な一貫性の維持を実現するなどの方法が取られてきました。

このように独立した複数のタスクを横断する処理フローにおいては、複数タスクを束ねるワークフロー全体として、各タスクが操作するデータ同士の論理的な整合性の担保と、各サービスにおけるロック時間の増大についての課題を抱えています。こういった課題への対応として、分散システムにおけるトランザクション処理におけるパターンの一つとして、Saga パターンがあります。

Saga パターンとは、大規模な分散アプリケーションでのトランザクション処理において、ステートの一貫性を維持しながら並列実行を実現するトランザクション処理手法であり、特にステート分散ワークフロー管理や長い処理の連鎖を必要とする場面で有用です。

Saga パターンはトランザクションの成功または失敗 (エラー) によって、2 つの異なる経路を辿ることができます。

エラーが発生した場合に前のトランザクションステップを元の状態に戻すための逆操作を実行する必要がありますが、その際にタスクをまたがった、トランザクションの管理を行う必要があります。その際にはトランザクションをロールバックする代わりに、補償トランザクションを実行して、正常系の処理を打ち消す処理 (git revert のようなイメージ) を実行することで、もとの状態に戻します。

このような Saga パターンにおいて、順序立てた処理の実行や、エラー発生時の補償トランザクションなどを実行する際の制御のアプローチとして、コレオグラフィー、オーケストレーションがあります。

それぞれが適するユースケースとして、コレオグラフィーはシステム内のコンポーネントが分散していて、自律的に動作する場合に適しており、一方オーケストレーションは中央で制御が必要で、トランザクションの一貫性や特定の実行順序が必要な場合に有用です。

ステート分散ワークフローのように、単一のトランザクションが長期間に亘り、多くのタスクを処理する必要がある場合は、オーケストレーション型のアプローチが適しています。本ブログにおいては、オーケストレーション型のアプローチを利用する際のユースケースについて説明します。

Saga オーケストレーション自体についての詳細については、公式の AWS Prescriptive Guidance の Saga・オーケストレーション の項や、 Building a serverless distributed application using a saga orchestration pattern のブログをご参照ください。

先程述べたように、オーケストレーション型の Saga パターンを実現するには、特定の実行順序の制御や、条件分岐を中央でワークフロー全体を制御するコンポーネントが必要になります。このような、ワークフローにおける各タスクの制御を実現するサービスとして AWS Step Functions があります。

Step Functions はサーバーレスのワークフロー管理サービスです。 Step Functions を利用することで、管理不要で信頼性の高いワークフローステートマシーンを利用することが可能です。ステートマシーン内では、具体的にワークフローの機能である、条件分岐や、繰り返し、例外処理はもちろん、組み込み関数 による文字列操作やハッシュ化、Base64 化など簡単なデータ操作が可能です。

Step Functions は実行タイプとして、標準ワークフローと Express ワークフローの 2 種類があります。標準ワークフローはレスポンスを期待しない非同期のワークフローの際に利用され、複雑性が高く、長時間実行 (最大１年) されるようなワークフローが必要なユースケースで利用されます。一方 Express ワークフローは、ハイトラフィックのイベント処理ワークロードの場合や、クライアントがレスポンスを期待する、同期的なマイクロサービスアーキテクチャを採用したシステムの実行に利用されます。

ステート分散ワークフローでは、長時間の実行を許容する必要があるため、標準ワークフローを用いることが推奨されます。以降は標準ワークフローを対象に説明します。

エラーハンドリングは、サーバーレスワークフロー管理ツールである AWS Step Functions でアプリケーションの信頼性を高める重要な要素です。本記事では、Step Functions を使用してエラーハンドリングを実現する方法を解説します。具体的には、ステートマシンの呼び出し側とステートマシン内でのエラーハンドリング方法に焦点を当てます。

非同期的に起動される標準ワークフローにおける呼び出し時のエラーのハンドリングの特徴として、呼び出しが完了したあとの処理は、非同期である特性上制御できないため、基本的に呼び出し時のみ可能になります。

• ステートマシンの定義の問題 (例: Choice 状態に一致するルールがない)。
• タスクの失敗 (例: AWS Lambda 関数の例外)。
• 一時的な問題 (例: クラウド上のネットワーク障害やサービスの障害)。

Step Functions でワークフローを構築する際に、正常系の処理のフローのみ実装され、エラー処理のタブについては未設定となっているステートマシンになりがちですが、品質の高いワークフローを実現するためには、すべてのエラーが発生する可能性があるすべてのステートにおいて、エラーハンドリングの実装が必要です。ここではステートマシン内でのエラーハンドリングの設定方法と、その際の考慮点について説明します。

ステートマシン内でのエラーハンドリング手法は主に 2 つで、リトライを行うか、エラーのキャッチを行い、適切なステートへフォールバックするかのどちらかになります。

リトライの詳細な定義や、フォールバック先の設定はコンソール上から可能となっており、ユーザーが最も考慮すべきポイントは、どのエラーにおいて、どちらのハンドリングを行うかという点になります。エラーの種類としては、Step Functions で発生するエラーと、タスク内で発生するエラーの 2 種類になります。どちらのエラーに対しても、文字列による完全一致によるパターンマッチになります。Step Functions で発生するエラーについては、組み込み文字列を定義されており、コンソール上からリスト形式で選択することが可能です。すべて States. プレフィックスが付いています。以下のドキュメントのエラー名一覧もご参照ください。

Step Functions のエラー処理 - AWS Step FunctionsStep Functions のエラー処理 »

このように、Step Functions のコンソールで提供されているエラー処理のタブをしっかりと設定するだけで、基本的なエラーハンドリングを実現することができます。

ステート分散ワークフローのステートマシン内におけるエラーハンドリングの考慮点の中でも重要なポイントとして、補償トランザクションフローにおけるエラーハンドリングがあります。

ステートマシン内でのエラーハンドリングは、正常フローにおけるエラーハンドリングと補償トランザクションフローにおけるエラーハンドリングと、2 種類のエラーハンドリングを行う必要があります。正常フローにおけるエラーハンドリングは、リトライによる対応か、エラーをキャッチして、異常系のステートフローに遷移し、補償トランザクションを実行するかのどちらかです。この補償トランザクション自体がエラーハンドリングである側面もありながらも、そこでもエラーが発生する可能性も考慮する必要があります。

補償トランザクション内でのエラーは、ロールバック処理が完了しないことを意味するため、システムとしてのデータの不整合につながります。このような例外的なイベントへの対応にも、当然リトライによる解決は試みるものの、それでもリカバリーできない事象の場合は、更にそのためのフローに入るなどということはなく、人的な運用によるカバーが必要になります。そのために異常系フローにおける補償トランザクションのエラーハンドリングは、リトライの実施と、エラーをキャッチして、イベントの退避、及び通知を行います。イベント駆動のデータ加工、連携処理パターン で紹介したように、データの破棄・退避を行うためには、Amazon SQS や Amazon SNS を利用したイベントを退避させるためのステートを設定してください。