ArgoCDとアプリワークロードのクラスタ分離

本稿はJCB Advent Calendar 2025の12月15日の記事です。

JDEPはKubernetes向けのCDツール、ArgoCDを採用しています。
これまでArgoCDはアプリケーションワークロードが稼働するクラスタと同一のクラスタ内に構成されていました。 しかし、サービスのさらなる安定性を考慮し、ArgoCDおよび周辺ツールをアプリケーション用クラスタから切り離し、専用クラスタへ移行を行いました。

本記事では、移行に至った背景と課題、分離後の構成、得られたメリットについて紹介します。

背景と課題

移行前、ArgoCDは東京リージョンのクラスタ(以降、メインクラスタ)内で、アプリケーションワークロードと同居する形で稼働していました。 しかし、アプリケーションの増加に伴いArgoCDのメトリクス（リソース消費）が増加傾向にあり、提供サービスへの影響が懸念されていました。こうした状況から「アプリケーションと管理プレーン(ArgoCD等)は明確にクラスタを分けた方が良いのではないか」という意見が挙がりました。
この意見を受けて分離構成の検討を行ったところ、同一クラスタでの稼働は以下のリスクや課題が潜んでいることがわかりました。

  1. リソースの競合
    アプリケーションの増加に伴い、ArgoCDの管理負荷が増大し、CPUやメモリの使用量が増加傾向にありました。 同一クラスタ内でリソースを共有している以上、ArgoCDの負荷が同じクラスタ内で稼働しているアプリケーションに悪影響を与えるリスクが存在していました。

  2. 作業時の影響範囲
    ArgoCDのアップグレードや設定変更等のメンテナンス作業を行う際、万が一トラブルが発生すると同一クラスタ上のアプリケーションに影響が及ぶ可能性がありました。

  3. 障害影響範囲
    機能が単一クラスタに集中していることにより、メインクラスタが単一障害点となっていました。 クラスタ障害が発生した場合、アプリケーションが停止するだけでなく、その復旧を担うべきArgoCDも同時に共倒れとなり、復旧作業が困難になるリスクを抱えていました。

新アーキテクチャ概要

これらの課題を解決するため、管理プレーンを物理的に別クラスタへ切り出す構成変更を行いました。

また、ArgoCDだけでなく「差分監査ジョブ」も今回の移行対象としました。
このジョブはシステムに意図しない変更がないかを定期的に監視するツールです。 アプリケーションのデプロイには直接関係ない独立したツールであるため、ArgoCD同様に新クラスタへ移行しました。

移行前の構成

移行後の構成

移行前はArgoCD、監査ツール、アプリワークロードが同一クラスタに混在していました。 移行後の図において、赤い枠線で囲んでいるのが管理プレーン用の新クラスタです。
JDEPは2リージョン構成をとっていますが、今回の変更により、大阪リージョンと同様に東京のメインクラスタにおいても、ArgoCDが外部からアプリケーションクラスタを操作する構成へ統一されました。
また、新クラスタでは新たにManaged prometheusの使用を開始しました。これについては後述いたします。

技術的な変更点

クラスタの種類の変更
メインクラスタではStandardクラスタを使用していましたが、ArgoCDの分離先となる管理用クラスタには、GKE Autopilotを採用しました。

ArgoCDはあくまで管理ツールであり、その土台となるクラスタ自体の管理(ノードのスケーリングやGKEバージョンのメンテナンス等)に運用工数を割くのは本質的ではありません。 管理コストを最小限に抑えるため、フルマネージドな運用が可能となるAutopilotを選択しました。

なお、ArgoCD自体の動作やインターフェースに変更はなく、開発者から見た使い勝手は維持されています。

監視方法
メインクラスタではDatadog Agentを展開し、監視を行っています。 しかし、Autopilotクラスタに対して同様の構成を取るには課題がありました。
Autopilotはノード構成が自動管理されるため、ワークロードに合わせて小さいサイズのノードが多数立ち上がる傾向があります。 Datadogはノード（ホスト）単位の課金であるため、ノード数が増加しやすいAutopilotではコストが高騰する懸念がありました。

代替として、Managed Prometheusを採用しました。
Autopilotに標準統合されているManaged Prometheusを利用してメトリクスを収集し、Google Cloud Integrationを通じてDatadogへ連携する構成としました。 これにより、Agentレスでコストを抑えつつ、運用者は従来通りDatadog Monitorでの監視・通知を一元的に行える環境を実現しました。

移行によるメリット

構成変更により、以下のメリットが得られました。

  • 管理の分離と可用性の向上
    ArgoCDに負荷の増加や障害が発生しても、アプリケーションクラスタで稼働中のサービスへの直接的な影響を最小限に抑えることができました。

  • 運用効率の向上
    ArgoCDや日次監査ツールのアップグレードやメンテナンスを、アプリクラスタへの影響を考慮することなく実施できるようになりました。専用クラスタ内で完結するため、日中のメンテナンスも心理的ハードルが低下しました。

  • 障害影響範囲の切り分け
    ArgoCD等の管理プレーンとアプリワークロードをクラスタで分離することで、クラスタ障害時の影響範囲を小さくすることができました。

終わりに

クラスタを分離することで運用リスクの低減と安定性の向上されました。 今後も信頼性の高いプラットフォーム提供に努めてまいります。

最後になりましたが、JCBでは我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧下さい。

本文および図表中では、「™」、「®」を明記しておりません。 Google Cloud, GCPならびにすべてのGoogleの商標およびロゴはGoogle LLCの商標または登録商標です。 記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。

©JCB Co., Ltd. 20︎21