シナジーマーケティングにおけるArgo CDの導入と運用

導入の背景

シナジーマーケティング株式会社では、当社が管理するSaaS製品「Synergy!」のインフラ基盤としてAWS EKSを採用しています。
Kubernetesの運用はオンプレミス環境の頃から比較的早い段階で取り組んでおり、AWSへのクラウド移行後もkubectlの適用スクリプトとOSSツールを組み合わせた独自のデプロイ基盤を継続して運用してきました。 その後、全社的な生成AI活用を推進するため、AIコーディングアシスタント(GitHub Copilot)が統合されたGitHubへの移行を行いました。それに伴い独自の仕組みを見直す必要があり、デプロイの仕組みも広く採用されている標準的なツールへ刷新することを検討しました。

ツール導入前の課題

• デプロイがkubectlスクリプトと複数のOSSツールを組み合わせた独自の仕組みに依存しており、運用の属人化が課題となっていました。
• GitHubへの移行に伴い、デプロイの仕組みもあわせて刷新する必要がありました。

どのような状態を目指していたか

• 独自スクリプトへの依存を解消し、標準的なツールを採用することで運用の属人化を排除することを目指していました。

• GitHub Actions
• Flux CD

• EKS上での運用実績 — EKS上での豊富な採用実績があり、Kubernetesのマニフェスト管理と親和性が高いこと
• 運用の属人化の排除 — 独自スクリプトに依存せず、広く採用されている標準的な仕組みであること

• デファクトなため — GitOpsツールの中でArgo CDはFlux CDと並ぶ主要OSSですが、GUIの充実度・コミュニティの規模・採用事例の多さでデファクトスタンダードとしての地位が高く、情報収集のしやすさが見込めました。
• キャッチアップコストの抑制 — GUIによる状態確認・操作が可能なため、CRD（ApplicationやAppProject）の学習は必要なものの、チームメンバーが運用に慣れるまでのコストをFlux CDより低く抑えられると判断しました。

改善したかった課題はどれくらい解決されたか

• それぞれのチームによって管理されていたスクリプトでの運用から、全チームでArgo CDによるデプロイが実現できました。

どのような成果が得られたか

• クラスター全体のアプリケーション状態をGUIから俯瞰できるようになりました。「全体が見える」という可視性の向上が最大の成果であり、トラブルシューティングが大幅に容易になりました。
• デプロイ間の依存関係に起因するエラーをGUIから俯瞰できるため、問題を発見しやすくなりました。

• Argo CDが独自に提供するApplicationやAppProjectといった概念・リソースを理解する必要がありました。
• 既存のディレクトリ構成をArgo CDのベストプラクティスに合わせるか、既存の構成を活かすかを検討する必要がありました。移行スピードを優先し、既存構成を活かす方針で進めました。

今回は導入スピードを重視して既存の構成をできるだけ活かす形で移行しました。 デプロイの自動化やチャットツールとの連携、チーム内でのArgo CDの習熟を進めていきます。