サーバーレスアプリケーション開発におけるエラーハンドリング ~ ワークフローパターン後編 ~

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

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

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

大規模データ処理は、その回ごとに処理をするべきデータ量が変動するため、必要なリソース量が異なることに加え、基本的に 1 日に 1 回などの頻度での実行のため、動いていない期間が多いことから、リソース量の制御の柔軟性とそれに応じたコスト発生である課金体系というメリットを強く受けられるサーバーレスに適したユースケースになります。

先程述べた通り大規模データ処理は、大量データ、並列分散処理、高負荷計算をするようなワークフローです。 ワークフローパターン前編 で紹介したステート分散ワークフローパターンとの違いとしては、ステートレスであること、マシンリソースや実行時間を大量に必要とすることが挙げられます。

大規模データ処理のケースではいわゆる MapReduce のような手法で、データを並列処理されるものが多くあります。MapReduce は、大量のデータを分割して、それぞれのマシンに振り分けを行い、定められた処理を実行し、結果を一箇所に集約する処理で、多くのケースではマシンを複数台立てることで、コストを掛けながら処理完了までの時間を短縮させるトレードオフの意思決定を行います。つまり大量のコンピュティングリソースまたは、長期間の処理時間が必要になります。このような大規模データ処理におけるエラーハンドリングで考慮すべきポイントは 2 つあります。

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

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

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

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

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

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

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

一方しきい値内に収まったときは、そのまま成功のフローとして処理が進みます。

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

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

参考として、以下の許容可能なエラーのしきい値である 5% を超えて、失敗となったワークフローにて検証を行います。画像は、692 個のデータがエラーとなり、2,710 個のデータが未処理である結果を表しています。こちらのワークフローに対してリドライブを実行したのが次の画像です。

エラーとなった 692 個のデータと、未処理の 2,710 個のデータを対象に再度処理が実行され、エラーとなったワークフローのデータ数が 310 個であり、許容可能なエラーのしきい値である 5% を下回ったため、成功として処理されています。

以下の画像がワークフローとしての実行履歴です。

このようにリドライブは、ワークフロー全体の観点から見て、失敗した箇所からの再開や、また分散処理内におけるエラーの場合は失敗したデータのみのリトライ制御を行うことで、失敗時点までのフロー処理の結果を活用することができるようになり、効率的なリトライを用意に実現することができます。

大磯 直人
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト

インターネット・Web サービスを提供されるお客様に対して技術支援を行っています。好きな食べ物は 肉・寿司・ラーメン です。空き時間は永遠に YouTube を見ています。好きな AWS サービスは AWS StepFunctions です。