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

前編 に引き続き、条件分岐を含む実行単位の長いシーケンシャンルなステップの集合であるワークフローが今回もテーマになります。ただし前回と異なる点として、大規模データ処理用途でのワークフローとしてのケースについて紹介します。

おそらく皆様が聞き馴染みがある言葉としては、バッチ処理と言われる一括大規模データ処理に当たるものが今回のテーマの対象になり、分析用途などの大量データ、大規模処理、高負荷計算といったキーワードで語られるユースケースがそれに当たります。

具体例を上げると、複数の販売チャネルで販売を行っている小売店での、販売経路ごと (例：ネット、モバイル、電話、FAX) の注文データを日次や週次で集めて、データのクレンジングを行い、集計し、DWH にローディングする、BI ツールで分析するなどのフローなどが考えられます。

1 つ目は、並列分散処理において必要な結果を得るための許容できるエラー率を定めることです。並列分散処理の中で1 つでもエラーが出るたびに処理を中断させて修正を行っていると、せっかくコストを掛けて並列実行を行っているにも関わらず、最終的な結果が出るまでの期間が後ろ倒しになってしまいます。

とはいえ、設定やコードの修正が必要なエラーやインフラの一時的な障害によって大量のエラーが出ていて、明らかに意味のない処理をしている場合に最後まで処理を実行すると、不要なコンピューティングコストを支払うことになります。これらのトレードオフを考慮し、必要な結果を得るための許容できるエラー率を定めることが重要です。

2 つ目は再開時に重複する処理を極力行わないことで、無駄なコスト及び時間を圧縮することになります。先程述べたように、エラーとして処理を中断させるさせた際に、その原因が一時的なものであり、リトライによってカバーできるものであれば、再実行することで回復出来ます。従来のエラーハンドリングで頻繁に出ていたリトライは、大規模データ処理においても当然有効で、計算結果としては正しい結果が得られます。しかしながら、一回あたりの所要時間またはコストが膨大に必要とされる大規模分析においては、安易なワークロード全体としてのリトライを実施するのはビジネス観点で許容できないシーンが多いです。

例えば 1 億件のデータ処理において、大部分が成功していたり分散処理自体は完了しているのにも関わらず、エラーによるワークフロー全体をリトライし、再度 1 億件全件のデータ処理が行われるのは合理的とは言えません。そのため、失敗した箇所からの再開や、また分散処理内におけるエラーの場合は失敗したデータのみのリトライ制御を行うことがポイントとなります。

まとめると大規模データ処理におけるエラーハンドリングで重要なことは、システム要件に応じて、許容できるエラー率や数のしきい値を定めることと、エラーが発生した際にも、失敗した箇所から処理を再開し、それまでの処理結果を活用することとなります。

具体的に説明すると、従来は以下の図のように、データ分割のためのプログラムを自前で用意し、1 万並列の子ワークフローの生成を自前で実施し、結果の集約のためのプログラムを自前で用意する必要がありました。

Distributed Map を使うと、以下の図のように、本来やりたかった子ワークフロー内のビジネスロジックのみの記述で 分散並列処理 を実現することが出来ます。

このように、大規模データ処理を行うとなると Hadoop や Spark の利用が必要となり、専用の文法を身につける必要がありましたが、アドホックに比較的簡易な分散処理を行いたいだけのためだけに、Hadoop や Sparkを 学ぶのは Too Much なケースにおいては、Distributed Map を用いることで容易に簡易的な大規模データ処理を行えます。

Distributed Mode の利用方法としては、Map State で Processing mode を Distributed にするだけです。

分散処理の中でエラー比率を管理して、必要に応じた処理の中断をするのはオーケストレーターである Step Functions が持つ機能で実現可能です。設定についてもコンソール上の Workflow Studio から可能となっており、ユーザーが決めることは、以下の図のように比率またはエラーアイテム数に応じた分散処理全体としてのエラーのしきい値を定めるだけです。以下の画像は 5% を許容できるエラーのしきい値としています。

上記の 5% のしきい値の設定を行った上で、しきい値超えたエラーが発生した際には、以下のように途中で実行が中断されます。

Step Functions は Web API パターン で紹介したワークフロー全体のリトライとは別に、失敗した箇所から再開する「リドライブ」と呼ぶ機能があります。通常のリトライであれば、ワークフロー全体を先頭から再度実行する挙動になりますが、リドライブ を利用することで、失敗した箇所から実行を再開することが可能です。

これによって分散処理や外部 API 呼び出しなど再実行を避けたい処理が含まれるワークフローにおいて、再実行を避けたいステップが完了した後に、一時的なエラーによってワークフロー全体としての処理が失敗してしまった場合でも、それらの処理を再実行する必要なく、完了した後のエラーが発生した箇所から再開することが可能です。