GitHub Actions vs Argo Workflows: CI vs K8s エンジン
これらは異なる問題を解決します。Argo Workflows は Kubernetes ネイティブの DAG エンジンで、GitHub Actions は git イベント駆動のCIです。
Argo Workflows はコンテナベースの DAG を Kubernetes 上で実行し、データ/ML パイプラインによく使われます。GitHub Actions はリポジトリイベントで起動する CI/CD です。両者はときに比較されるため、それぞれがどこに合うかを示します。
| GitHub Actions | Argo Workflows | |
|---|---|---|
| 主な用途 | git イベントでの CI/CD | K8s 上のコンテナ DAG / バッチ |
| 設定 | .github/workflows/*.yml | Workflow の CRD (YAML) |
| ホスティングモデル | GitHubホスト型またはセルフホスト | 自前の Kubernetes クラスタで実行 |
| トリガーモデル | Push、PR、schedule、dispatch | API、イベント、schedule、sensors |
| エコシステム | Actions Marketplace | Argo エコシステム (Events、CD) |
| メンテナンス | 低 (マネージドランナー) | K8s 上で自分で運用 |
異なる仕事
Kubernetes に属する重い並列コンテナ DAG (ML トレーニング、ETL) には Argo Workflows を使いましょう。コード変更で起動する build/test/deploy には GitHub Actions を使いましょう。多くのチームは両方を動かします。
設定と運用
Argo は Kubernetes ネイティブで、fan-out/fan-in のバッチ処理に強力ですが、クラスタとコントローラーは自分で運用します。Actions はマネージドで git 中心、大規模なマーケットプレイスを持ちます。
マネージドランナーが合う場面
CI が GitHub Actions で、バッチジョブだけが Argo を必要とするなら、CI は Actions のままにし、そのコストをマネージドランナー (例: Latchkey) で削減しましょう。GitHubホスト型より約70%低く、ウォームプールと自己修復リトライを備えます。
結論
Kubernetes ネイティブなバッチ/DAG 処理には Argo Workflows を、コード起動の CI/CD には GitHub Actions を選びましょう。両者は競合するより補完し合います。マネージドランナーは Actions 側を安価に保ちます。