Argo CD と Argo Workflows の概要・比較と導入ベストプラクティス

Argo CD の概要と主要コンポーネント

Argo CD は Git リポジトリの状態を Kubernetes クラスタに自動で同期させる宣言的 Continuous Delivery（CD）ツールです。GitOps の考え方に基づき、構成変更はすべて Git 上の Pull Request で管理できるため、監査性と可視性が高まります。本節では Application・ApplicationSet・UI / CLI の役割を整理し、実務での活用イメージを示します。

Application

Argo CD が扱う最小単位は Application オブジェクトです。

• 概要：Git リポジトリ（または Helm Chart）と対象 Kubernetes マニフェストを紐付け、リアルタイムで同期状態を監視します。
• 主な特徴
• 差分が自動的に UI に表示され、手作業の kubectl apply が不要です。
• 同期（Sync）やロールバックはワンクリック／コマンドで実行できます。
• 利用例
  yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
spec:
source:
repoURL: https://github.com/argoproj/guestbook.git
path: helm
destination:
server: https://kubernetes.default.svc
namespace: default
  上記の Application を作成すると、Argo CD はリポジトリの変更を検知し自動で Helm Chart をレンダリングしてデプロイします。

ApplicationSet

多数の環境やクラスタに対して同一パターンの Application を自動生成する拡張機能です。

• 概要：テンプレートと「ジェネレータ」の組み合わせで、動的に Application オブジェクトを作成します。
• 主なジェネレータ
• List：固定リストから生成
• ClusterGenerator：クラスター情報を自動取得
• GitDirectory：リポジトリ内のディレクトリ構造を元に展開
• 利用例（マルチクラスタ／環境別デプロイ）
  yaml
  apiVersion: argoproj.io/v1alpha1
  kind: ApplicationSet
  metadata:
  name: multi-env
  spec:
  generators:
  • list:
elements:
- env: dev
cluster: dev-cluster
- env: prod
cluster: prod-cluster
template:
metadata:
name: '{{env}}-guestbook'
spec:
source:
repoURL: https://github.com/argoproj/guestbook.git
path: helm
destination:
server: '{{cluster}}'
namespace: default
devとprod の2つのクラスタに対し、同一 Helm Chart を環境ごとの名前空間でデプロイします。

UI / CLI

Argo CD は Web UI と argocd CLI の二本柱で操作性を提供します。

• 概要：UI では差分・履歴・イベントが視覚的に確認でき、CLI はスクリプトや CI との連携に適しています。
• 主なコマンド例
• argocd app list … 登録アプリの一覧表示
• argocd app sync <app> … 手動同期実行
• argocd proj create <proj> … プロジェクト単位で権限を分離

ポイント：UI と CLI は相互に補完し合う設計となっているため、日常的なデリバリーは UI、緊急対応や自動化は CLI を使い分けると運用効率が向上します。

Argo Workflows の概要と主要コンポーネント

Argo Workflows は Kubernetes 上で汎用的なワークフロー（DAG）を実行できるエンジンです。データパイプラインやバッチ処理、機械学習のトレーニングジョブなど、幅広いユースケースに対応します。本節では WorkflowTemplate・CronWorkflow・Sensor・UI / CLI の特徴と実装例を解説します。

WorkflowTemplate

再利用可能なワークフロー定義の雛形です。

• 概要：パラメータ化されたテンプレートとして ClusterRole に保存し、複数の実行インスタンスが同一ロジックを共有できます。
• 利点
• 定義変更はテンプレートだけにすればよく、個別ジョブの修正が不要です。
• CI パイプラインから呼び出すことで、コードとワークフローの整合性が保たれます。
• 利用例（データ取得→前処理→学習）
  yaml
  apiVersion: argoproj.io/v1alpha1
  kind: WorkflowTemplate
  metadata:
  name: ml-pipeline
  spec:
  entrypoint: main
  arguments:
  parameters:
  - name: dataset
  value: default.csv
  templates:
  • name: main
dag:
tasks:
- name: fetch
template: fetch-data
- name: preprocess
dependencies: [fetch]
template: preprocess-data
- name: train
dependencies: [preprocess]
template: train-model

実行時はargo submit --from workflowtemplate=ml-pipeline -p dataset=mydata.csv のようにパラメータだけ変えて呼び出します。

CronWorkflow

時間ベースでワークフローを定期実行するリソースです。

• 概要：Kubernetes の CronJob と同様の CRON 表記でスケジュールを設定できます。
• 主な特徴
• 実行履歴が UI に蓄積され、失敗時は自動リトライポリシーを設定可能です。
• スケジューラは軽量で、数千件規模の定期ジョブでも安定して稼働します（2024 年時点の最新安定版 v4.5 が対応）。
• 利用例（毎日 02:00 の集計バッチ）
  yaml
apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
name: daily-report
spec:
schedule: "0 2 * * *"
workflowSpec:
entrypoint: report
templates:
- name: report
container:
image: python:3.9
command: ["python", "/scripts/report.py"]

Sensor

外部システムからのイベントをトリガーにワークフローを起動します。

• 概要：GitHub、Slack、Prometheus などの通知を受け取り、対応する Workflow を自動生成できます。
• 利点
• GitOps と併用すればコード変更時にテスト・デプロイがシームレスに実行されます。
• 複数のイベントソースを1つの Sensor に集約でき、管理負荷が低減します。
• 利用例（PR マージで CI ワークフロー起動）
  yaml
  apiVersion: argoproj.io/v1alpha1
  kind: Sensor
  metadata:
  name: github-pr-sensor
  spec:
  dependencies:
  • name: github-pr
    eventSourceName: github
    eventName: pull_request
    triggers:
  • template:
name: ci-workflow
k8s:
groupVersionResource:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
operation: create
source:
resource:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: ci-
spec:
entrypoint: run-tests


UI / CLI

Argo Workflows は専用の Web UI と argo CLI を提供し、DAG の可視化とスクリプト実行を支援します。

• 概要：UI ではノード間の依存関係が色分けされ、実行中・成功・失敗が一目で把握できます。CLI は argo submit, argo get, argo delete などのコマンドで自動化に適しています。
• 主な操作例
• argo list … 現在実行中または完了したワークフロー一覧
• argo resume <wf> … 一時停止状態から再開

GitOps デリバリーと汎用ワークフローオーケストレーションの比較

Argo CD と Argo Workflows は同一プロジェクトに属しますが、目的と設計思想が異なります。本節では「対象領域」と「実装スタイル」の二軸で比較し、導入判断の指針を示します。

目的別の違い（CD と汎用パイプライン）

Argo CD は インフラ構成 の状態同期に特化し、Argo Workflows は 任意のジョブフロー を柔軟に組み立てます。

• 結論：マイクロサービスの本番デプロイは Argo CD が適切で、ETL・機械学習バッチは Argo Workflows が最適です。
• 理由
• Argo CD は Git を唯一の真実（source of truth）として扱い、環境ドリフトを自動検出します。
• Argo Workflows は DAG によるデータフローと条件分岐が得意で、外部 API 呼び出しや複雑な計算ロジックも記述可能です。

宣言的アプローチ vs スクリプト駆動型設計

Argo CD は 完全宣言的（Git の PR が唯一の変更経路）で、Argo Workflows は テンプレートベースながら手続き的要素 を持ちます。

• 結論：監査やロールバックが重視されるインフラ構成は宣言的に管理し、ビジネスロジックやデータ処理はスクリプト駆動で実装するとバランスが取れます。
• 具体例
• フィーチャーフラグ追加は ApplicationSet のパラメータ行を追加するだけで完了。
• データベースマイグレーションや外部システム連携は WorkflowTemplate の script ステップで実装。

現行バージョンに基づくベストプラクティス

以下では 2024 年時点の安定版（Argo CD v2.9、Argo Workflows v4.5）を前提に、パフォーマンス向上と運用効率化 のポイントをまとめます。

Argo CD のベストプラクティス

1. Git 管理の徹底 – values.yaml や Helm Chart は必ずリポジトリでバージョン管理し、ApplicationSet の GitDirectory ジェネレータで自動取得させます。
2. Project 単位で RBAC を分離 – 環境（dev / prod）ごとに Project を作成し、権限を最小化します。
3. Sync Policy の明示的設定 – 自動同期は automated: { prune: true, selfHeal: true } としておくとドリフト復旧が自動化されます。

Argo Workflows のベストプラクティス

1. parallelism の上限設定 – 大規模バッチでは spec.parallelism を明示し、クラスター全体のリソース競合を防止します。
2. アーティファクトキャッシュ活用 – 中間成果物は S3 互換ストレージに保存し、同一 DAG 内で再利用すると実行時間が短縮されます。
3. retryStrategy の導入 – 外部 API が不安定なステップには retryStrategy: { limit: 5, backoff: { duration: "10s", factor: 2 } } を設定し、リトライによる耐障害性を高めます。

実務シナリオ別導入ガイドと相互補完パターン

マルチクラスターデプロイ

概要：オンプレミス・パブリッククラウドの複数クラスターへ同一アプリを展開します。

1. ApplicationSet の ClusterGenerator で各クラスター情報を取得。
2. テンプレートに共通 Helm Chart を指定し、環境ごとの values.yaml を GitDirectory から注入。
3. デプロイ後は Argo Workflows の CronWorkflow でクラスタ別リソース使用率を定期収集し、Slack 通知（Sensor 経由）することで運用可視性を確保。

CI パイプライン統合

概要：GitHub Actions と連携し、コード変更からデプロイまでの一貫フローを実装します。

1. PR マージ時に GitHub Action が argocd app sync <app> を呼び出し、本番環境へ自動同期。
2. 同時に argo submit --from workflowtemplate=ci-tests で統合テストワークフローを実行。
3. テスト結果は GitHub のステータスチェックとして返却し、失敗時はマージがブロックされます。

バッチ処理・ETL

概要：データ取得 → 前処理 → 集計 → レポート生成 を定期実行します。

1. CronWorkflow に全体 DAG を記述し、各ステップはコンテナイメージで実装。
2. 前処理完了後に Sensor が Argo CD の ApplicationSet をトリガーし、生成したデータを格納する ConfigMap を自動更新。
3. UI で DAG 実行状況と Argo CD の同期状態を同時に監視できるダッシュボードを構築します。

CD とワークフローの連携パターン

目的：アプリケーションデプロイ後にデータベースマイグレーションやキャッシュリフレッシュが必要なケース。

1. Application の SyncHook（ポストシンク）で argo submit --from workflowtemplate=migration-wf を実行。
2. Migration ワークフローが完了すると、Argo CD が自動的に次のデプロイステージ（Blue‑Green）へ遷移します。

このように Argo CD が「何を」デプロイするかを管理し、 Argo Workflows が「その後に実行すべきロジック」を柔軟に組み立てる ことで、エンドツーエンドの GitOps パイプラインが完成します。

運用面の比較と選定チェックリスト

導入判断は機能だけでなく、運用コストや組織体制との適合性も重要です。以下の表とチェックリストで比較ポイントを整理します。

選定チェックリスト（実務向け）

1. 対象は「状態同期」か「ジョブ実行」か – 前者は Argo CD、後者は Argo Workflows。
2. マルチクラスタ展開が必要か – ApplicationSet の有無で判断。
3. 定期バッチ／ETL が中心か – CronWorkflow と Sensor が鍵になる。
4. 既存 CI ツールとの連携要件 – CLI の利用頻度と API 呼び出しの容易さを比較。
5. 認証基盤（OIDC/SAML）への統合 – 両ツールとも対応だが、Project / WorkflowTemplate の権限設計を検討。

結論：単体で完結できる要件はそれぞれのツールで実装し、相互補完が必要なシナリオ（例：デプロイ後にバッチ処理）ではハイブリッド構成を採用すると、可観測性・自動化・保守性すべての面で最適化できます。