hacomonoの非同期ジョブ基盤 job-manager

アーキテクチャ選択の背景や意図

job-managerを構築して達成したかったことは以下です。

• マルチプロダクト実施に伴うSagaパターンの構築
• 既存ジョブ基盤の課題(コスト効率、流量調整、リトライ)解決
• 開発者自身でジョブ構築を可能にし、開発コストや運用負荷の減少

Sagaパターンを達成するためにワークフローツールのAWS StepFunctions(以下SFn)を使っています。
SFnの機能を使い流量調整やリトライ処理を導入しています。
SFnによって起動されるLambdaはAPIを叩くことだけを責務にすることで、流量調整やリトライを容易にしつつ、job-manager自体の運用コストを下げています。
サーバーレスを採用しているため、ECSを都度起動している既存ジョブ基盤よりもコスト効率が高いです。

SFn前段のLambdaでは主にジョブ対象のデータ収集とSFn起動を行っており、これらの処理はジョブ毎に柔軟に変更可能で様々なジョブ要件に耐えられるようにしています。
分散アーキテクチャの難しさには、Datadogを使った分散トレースやログ統合によるオブザーバビリティの向上によって対応しています。

現在の課題と今後の改善予定

1. コスト面の課題

実行頻度や実行対象が極端に多いジョブに対して、SFnとDatadogのコストが高額になってしまうことが課題です。
このコスト増はSFnの特性上、避けられない側面もあります。
そのため対策として、開発者自身にジョブのロジックを見直してもらう(実行回数の削減など)か、job-manager側を改良し、一度に処理するデータをより効率的に集約・最適化する、という2つの方向性を検討しています。

2. 統合テスト自動化の課題

SFnの分散Map機能はSFn Localなどのテストツールが未対応のため、エラーケースを網羅した統合テストの自動化が困難です。
手動テストの工数を削減すべく、今後はエラー等を返すモックAPIを構築し、テストの簡易化・自動化を検討しています。

◆執筆：有働開　@PbwBi