Argo Workflows 導入レビュー：バッチ運用・保守の課題解決と成果
参考になった
0
株式会社MonotaRO / Myoungki Song
SRE
導入の背景・解決したかった問題
導入背景
バッチ運用・保守における共通的な課題を解決するため、コンテナ基盤として基盤プロダクトを導入し、各開発チームへの提供を目指しました。
共通の課題
バッチ処理自体の複雑性
- バッチ処理のロジックが複雑化しており、特にEnd of Life（EOL）対応や仕様変更時の手間が大きな負担となっている。また、モダナイズやコンテナ化の必要性は認識されているものの、「どのように開発・運用を進めるべきか」という具体的な指針や知見が不足している。
- バッチ処理のロジックが複雑化しており、特にEnd of Life（EOL）対応や仕様変更時の手間が大きな負担となっている。また、モダナイズやコンテナ化の必要性は認識されているものの、「どのように開発・運用を進めるべきか」という具体的な指針や知見が不足している。
運用方法のばらつきによる煩雑さ
- 各チームでバッチ処理に使用しているツールや運用方法が統一されておらず、ジョブの管理方法や実行スケジュールの運用がチームごとに異なる状況にある。このため、管理作業が煩雑になり、結果として運用・保守コストが増大している。
- 各チームでバッチ処理に使用しているツールや運用方法が統一されておらず、ジョブの管理方法や実行スケジュールの運用がチームごとに異なる状況にある。このため、管理作業が煩雑になり、結果として運用・保守コストが増大している。
ジョブ実行状況の可視性やリカバリ対応の欠如
- ジョブの実行ステータスをリアルタイムで把握できる仕組みが不足しており、失敗時のリトライや対応が効率的に行えない。
- ジョブの実行ステータスをリアルタイムで把握できる仕組みが不足しており、失敗時のリトライや対応が効率的に行えない。
VMやクラスタの運用負荷
- バッチ処理を実行するための従来型のVMやクラスタの維持・管理が運用チームに大きな負荷をかけている。
比較検討したサービス
- Cadence (Uber)
- Nomad (HashiCorp)
- DigDag
- JobSet
比較した軸
評価軸として、現在運用されているバッチの機能要件および非機能要件をリスト化しました。その上で、すべての要件を網羅的に解決できるかという点を主要な観点とし、さらに以下の項目で比較検討を行いました。
- 開発時期
- GitHubスター数
- 依存ライブラリ（Requirements）
- VMからの移行難易度
- Kubernetesへのインストール容易性
- （Web）UIの有無
- スケーラビリティ
- CRON互換性
- DAGサポート
- テナントごとの権限設定による、他チームからのジョブ閲覧および操作の排他性
選定理由
充実したGUI機能
- バッチジョブリストの可視化やジョブのリトライ、一時停止（suspend）など、必要な操作をわかりやすいGUI上で簡単に実施可能。
- バッチジョブリストの可視化やジョブのリトライ、一時停止（suspend）など、必要な操作をわかりやすいGUI上で簡単に実施可能。
柔軟で多様なワークフロー実装
- 複数ステップのジョブやジョブ間の依存関係の管理、条件付きロジックの組み込みなど、複雑なワークフローを柔軟かつ多様に設計できる。
- 複数ステップのジョブやジョブ間の依存関係の管理、条件付きロジックの組み込みなど、複雑なワークフローを柔軟かつ多様に設計できる。
ジョブの進行状況追跡とデバッグの容易さ
- cronに基づくスケジュールで実行されるジョブの進行状況やエラーの追跡が簡単で、デバッグ作業効率を向上できる。また、これに限らず、ログやメトリック、イベントを活用することで、環境全体のモニタリングやデバッグがしやすい点も大きな利点です。
- cronに基づくスケジュールで実行されるジョブの進行状況やエラーの追跡が簡単で、デバッグ作業効率を向上できる。また、これに限らず、ログやメトリック、イベントを活用することで、環境全体のモニタリングやデバッグがしやすい点も大きな利点です。
パラメータとテンプレート機能の充実
- 柔軟なパラメータ設定とテンプレート化によるジョブロジックの再利用が可能で、開発効率と運用効率を大幅に向上できる。
- 柔軟なパラメータ設定とテンプレート化によるジョブロジックの再利用が可能で、開発効率と運用効率を大幅に向上できる。
活発なコミュニティと他のコンポーネントとの親和性
- 活動的なコミュニティによる信頼性の高さに加え、Argo CDとの連携が可能で、システム全体の拡張性を確保できる。
- 活動的なコミュニティによる信頼性の高さに加え、Argo CDとの連携が可能で、システム全体の拡張性を確保できる。
Argo Workflowsは、これら豊富な機能や利点を持つことから、複雑なジョブ管理や効率的なワークフロー構築を求めるプロジェクトに適しているツールとして選びました。
導入の成果
GUIの導入による可読性の劇的な向上
- ジョブの実行状態をグラフ形式で可視化し、ログ確認も容易になりました。
- ジョブリストと実行状況、スケジュール状況を一覧で把握可能になりました。
テンプレート化によるロジックのモジュール化と再利用性の確保
- 機能単位でのモジュール化が実現し、ロジックの再利用が可能になりました。
- 受け入れテストなどの各種テストを単体で実行できるようになりました。
Steps・DAGの活用によるプロセス管理の最適化
- 複雑なプロセスを持つジョブを、StepsやDAGによってより単純化し、拡張性の高い構造にすることができました。
- 複雑なプロセスを持つジョブを、StepsやDAGによってより単純化し、拡張性の高い構造にすることができました。
自動復旧機能（Retry）の実装
- ジョブが失敗した場合でも、失敗したプロセスから再実行できるようになり、復旧が容易になりました。
- ジョブが失敗した場合でも、失敗したプロセスから再実行できるようになり、復旧が容易になりました。
Datadogとの連携による監視体制の強化
- メトリクス収集とアラート設定を一元管理できるようになりました。
- メトリクス収集とアラート設定を一元管理できるようになりました。
Argo Eventsとの連携
- 外部イベントをトリガーとしたジョブ実行など、イベント駆動型のワークフローを実現しました。
導入時の苦労・悩み
- マルチテナント環境におけるインストール方法の選択（Cluster Install or Managed Namespace Install）
導入当時、マルチテナント環境の導入事例や解説記事が見当たらなかったため、両方の方式（Cluster Install と Managed Namespace Install）をPoC（概念実証） として試行しました。その詳細については、以下の弊社の Tech Blog にて解説しておりますので、ご参照ください。
https://tech-blog.monotaro.com/entry/2025/06/26/090000
- RBAC権限の不足（argo-workflows-* Roleのみでは不十分）
Argo Workflows のデプロイ時に設定される argo-workflows-* Roleだけでは、GUIでの操作に必要な権限が不足しており、一部の操作が実行できない事象が発生しました。この課題の詳細と対応策についても、上記の弊社の Tech Blog にて解説しております。
- スケジュールジョブの実行漏れ
可用性を高めるために High-Availability（HA） 構成を適用していたにもかかわらず、実際の運用中にスケジュールジョブの実行漏れが発生しました。
【原因】
startingDeadlineSeconds の設定値を誤って解釈していたためです。「0」に設定した場合、デッドラインなし（無限）となり、リーダー切り替え時に遅延したジョブを必ず再実行すると想定していました。しかし、再現テストの結果、この設定値ではリーダー切り替え時のジョブの再実行は行われないことが判明しました。
【対応】
startingDeadlineSeconds に「0」より大きい値を設定することで、この問題を解決することができました。
導入に向けた社内への説明
上長・チームへの説明
【チームからの主要なフィードバック】
導入推進時、チームからは主に以下の点について代替案の提示を求められました。
- KubernetesのCronJobで十分ではないか？
- ArgoCDでもジョブのリスト表示、ログ確認、単体実行などの機能があるが、なぜ別のツール（Argo Workflows）の導入が必要なのか？
【費用対効果と導入の優位性の説明】
これらのフィードバックに対し、私たちは主に以下の機能的優位性をアピールし、費用対効果を説明しました。
- Argo Workflows GUIの圧倒的な利便性:
- ジョブのリスト化、実行状況の確認、およびログ参照を容易にする専用GUI（グラフィカルユーザーインターフェース） の優位性を強調しました。
- 複雑なロジックの実装簡素化:
- Steps/DAGなど、複雑なワークフローをよりシンプルに、かつ容易に実装できる機能を提示しました。
- 既存認証基盤との親和性:
- ArgoCDの認証・認可の仕組みをそのまま利用できるため、セキュリティを担保しつつ導入が容易であり、実装コストが低い点を強調しました。
活用方法
アーキテクチャ選定の意図や工夫、背景
Kubernetes（K8s） および Argo Workflows を採用し、その管理・運用をコンテナ基盤チームが担うことで、以下の目標達成を目指しました。
開発負荷の軽減と生産性の向上: 開発者がインフラ運用に関する負担から解放され、本来の開発業務に集中できる環境を提供します。具体的には、デプロイ、ロギング、モニタリングといった DevOpsのOperation領域をコンテナ基盤サービスとして開発チームに適用できるようにします。
ジョブ運用の安全性と効率化: 既存の課題を解決・改善し、複数チームがより容易に、かつ安全にジョブを運用できる基盤を構築します。
セキュリティと隔離性の確保: マルチテナント環境においても、各チームのジョブを論理的に隔離し、他チームからの閲覧および操作を厳格に禁止します。
普段どのような使い方をしているか
各チームは、分離された専用環境で各自のジョブをデプロイしています。
ジョブの実行と管理: Argo Workflows を用いて、ジョブのスケジュール設定、手動実行、および実行状況の確認などを日常的に実施しています。
パフォーマンス監視と運用（常時）: ジョブのメトリクスは Datadog に一元収集されており、各チームが独自のモニタリングやアラート設定を行うことで、常時監視できる体制を維持しています。
よく使う機能
- Argo-workflows GUI
- ジョブのリスト化により、実行状況の把握が容易です。
- テストジョブや失敗したジョブを単発で（再）実行できます。
- Template
- 再利用可能なロジックをテンプレートとして定義し、ワークフローに組み込んで再利用できます。単体での実行も可能なため、テストコードを実装し、単発実行やワークフロー内での利用の両方に活用できます。
- Steps / DAG
- 複雑なロジックや長時間稼働するジョブをマイクロサービス化できます。これにより、復旧作業が大幅に容易になります。
- Artifacts
- S3などの外部ストレージへのInput/Output（入出力）処理を容易に実現できます。
- Suspend
- 弊社のBlue/Greenクラスタアップデート時など、ジョブの切り替え（旧クラスタから新クラスタへの移行）が必要な際に、切り替え作業を大幅に簡素化できます。
ツールの良い点
Kubernetesネイティブであること
- RBAC（ロールベースアクセス制御）、ロギング、モニタリングなど、Kubernetesのネイティブな機能を活用した設定や運用が可能です。
- RBAC（ロールベースアクセス制御）、ロギング、モニタリングなど、Kubernetesのネイティブな機能を活用した設定や運用が可能です。
豊富な主要機能
- 前述したテンプレート機能やDAG、Suspendといった独自の主要機能群により、複雑なワークフローを効率的かつ安全に管理できます。
ツールの課題点
ドキュメントの不足（情報収集の困難性）:
公式ドキュメントだけでは情報が見つからないことがあり、Issue（GitHubなど）やWeb検索を通じて情報を収集したり、実際に動作検証を行わなければ特定の設定や挙動が確認できないケースが散見されました。
ツールを検討されている方へ
Kubernetes（K8s） 上でジョブの運用や管理を検討されている方にとって、本ツールは極めて優れており、最適なソリューションの一つであると考えます。
今後の展望
UXの改善余地や、軽微なマイナーバグが散見される状況です。しかし、今後も継続的にバージョンアップが行われ、これらの課題が改善されていくことを期待しています。
株式会社MonotaRO / Myoungki Song
SRE
株式会社MonotaRO / Myoungki Song
SRE
