こんにちは、GxPの平山です。
この記事はグロースエクスパートナーズ Advent Calendar 2023の18日目です。
例年、内容が長めになってしまい反省しているのですが、今回も無駄に長いかもしれません…なるべくシンプルにまとめたいと思います。
はじめに
GxPにジョインして以降、バックエンドの開発、保守、運用を行っておりますが、今年は特にバッチ処理系の障害に苦しめられた1年だったなと思いました。
メール通知系のバッチアプリの予期せぬダウンにより、処理がスタックしてしまったり、逆に同じメールを何度も通知してしまったり…。
障害の復旧作業、改善を行いつつ、設計の重要性、難しさを改めて痛感しました。
救いを求めて（？）インターネットをさまよっていたところ、MSのドキュメントにてバックグランドジョブに関するガイダンスが公開されており、非常にためになる情報がまとめられていました。
今回はこちらで紹介されていた「Scheduler Agent Supervisor パターン」について、実際に自分で構築してみて得た学び、感じたことを紹介したいと思います。
Scheduler Agent Supervisor パターン
- バックグラウンドジョブに関するデザインパターンで、タスク内の処理（アクション）に失敗した場合に、復旧、是正といった操作を自動で行う。
- Scheduler、Agent、Supervisorと呼ばれるアクターによって構成されており、それぞれ以下の様な役割で動作する。
- Scheduler … タスクを構成する手順（アクション）の順序などを調整する。ある手順にリモート サービスまたはリソースへのアクセスが必要な場合、Scheduler は非同期/応答パターンによって Agent を呼び出す。
- Agent … リモートサービスの呼び出し、またはタスク内の手順によって参照されるリモート リソースへのアクセスをカプセル化する。
- Supervisor … Scheduler によって実行されているタスク内の手順の状態を定期的に監視し、いずれかの手順が失敗した場合に、その手順を復旧するか、適切な是正アクションを実行する。
- 状態ストアにタスクの進行状況、各手順の状態に関する情報を保持しておき、Schedulerによる手順の調整、Supervisorのタスクの状況管理、復旧に使用する。
詳しい解説は以下のMSのページにありますので、是非ご覧ください。
今回はこちらの記事にある例（eコマースシステムの注文に対するバッググラウンドジョブ）を実装、構築してみようと思います。
システム構成
記事にあるシステム構成のうち、赤枠の範囲（タスクの実行とSupervisorによる状態ストア監視）をAzure上で構築してみました。
各アプリについては、Azure Container Apps ジョブとしてデプロイしました。
役割に応じて、スケジュールトリガーとイベントトリガーを使用して構築しました。
状態ストアはAzure SQL Database を使用し、メッセージキューはQueue Storageを使用しました。
処理フロー
SchedulerとAgentによるタスクの処理は以下の流れで進みます。
①Schedulerによるタスクの起動
②Agentによるリモートサービス呼び出し
③Schedulerによる処理完了の記録
今回はSupervisorによる復旧、エラー処理を試したいので、注文ID（1以上の整数）が3の倍数の場合、リモートサービスがアホになって失敗するしくみにしています。
また上記とは別に、Supervisor が定期的に状態ストアの監視、復旧・停止処理 を行います。
失敗が3回に達した時点で、ステータスを「20.エラー」に更新し、処理を完全に中断させます。
プログラム
こちらで公開しております。
詳細については、後日Readmeにまとめたいと思います。
動かしてみる
実際に動かして、状態ストア（DB）、メッセージキュー（Queue Storage）の状態を順番に確認します。
[事前準備]状態ストアにレコード追加
Scheduler起動のため、状態ストアにレコードを手動で記録しています。
レコードのステータスは「0.保留中」です。
①Schedulerによるタスクの起動
「0.保留中」のレコードが、「1.処理中」になり、処理が開始されます。
CompleteByに完了期限を設定しています。
LockedByには処理を実行するSchedulerのインスタンス IDが設定されます（今回は1環境しかないため固定値を設定）
Agent呼び出しのため、Queue Storageにメッセージが登録されます。
②Agentによるリモートサービス呼び出し
Schedulerからの処理要求に対して処理を行います。
処理に成功した注文IDに関するメッセージがQueueに登録されます。
リモートサービスの呼び出しに失敗したものについては、特に何もしません。
この時点では状態ストアへの変更なども通知されません。
③Schedulerによる処理完了の記録
Agentから正常終了した注文IDが返却されるので、状態ストアのレコードのステータスを「10.処理済」に更新します。
Ⓧ Supervisorによる状態ストアの監視、復旧・停止処理
「1.処理中」ステータスのレコードのうち、完了期限をすぎたものがSupervisorによってステータス「0.保留中」に更新されます。
次回のScheduler起動時に、上記更新したレコードに対して再度処理が起動します。
以降は同様の流れで、3回失敗するまでリトライが実行されます。
今回はリモートサービスが失敗を続けるため、最終的にSupervisorがステータスを「20.エラー」に更新し、Schedulerによる起動の対象外となります。
実際に作ってみて
- Supervisor で復旧をコントロールできるため、都合の良いタイミングや内容での復旧を実現でき、信頼性の向上を図れると感じました。
- 今回は単純なリトライのみの検証でしたが、より複雑なタスクについては、途中からの再実行であったり、一部操作の切り戻しなどを、Supervisorを起点としてより柔軟に実装できると感じました。
- 再実行に伴って、同じ操作を再度実行することになった場合に、結果が異なることのないよう、やはり冪等（同じ処理を何度行っても、最終的な結果が同じとなる）であることが重要だと感じました。
- メール送信のような、同じ処理を再実行してしまうことが逆に困る様なケースについては、成功した結果の記録をこまめに行うことや、ログを詳細に記録しておくこと、可能であれば重複除去ロジックを組み込むといった対策が重要だなと感じました。
- 冒頭で話した障害に関しては、実際にログを詳細に残す改修を行い、復旧時の余分な再送信を防ぐことができるようになりました。
まとめ
今回はMSのバックグラウンドジョブのガイドラインに掲載されていたScheduler Agent Supervisorパターンを構築してみました。
システムを設計する上で、目的を達成することに意識がいきがちですが、運用していくなかで障害が発生することは必ずといってよいほど発生します。
昨今のシステム開発では分散アーキテクチャを構築することも多く、ネットワークやリモートサービスなど様々な要因で予期せぬエラーが起こりうる可能性があります。
エラーが起きることを前提に、どのように復旧するかを設計時に考慮できているかどうかで、システムの信頼性が高まるのだと改めて感じました。