「複数のチームが独自にデプロイ手順を持っており、運用の標準化ができない」というご相談を、ここ一年で複数いただいております。Kubernetes自体は導入済みでありながら、CI/CDパイプラインの設計やデプロイ運用が個別チームの裁量に委ねられている、というケースです。

このような状況に対する解として、近年はGitOpsの考え方が広く受け入れられてきました。本記事では、Argo CDを用いた実装例とあわせて、GitOps導入時に検討すべき論点を整理いたします。

01. なぜGitOpsなのか

GitOpsの基本的な考え方は、「システムの望ましい状態をGitリポジトリで宣言的に管理し、実環境を継続的にそれに収束させる」というものです。デプロイメントは「Gitリポジトリへのコミット」という単一の動作に統一されます。

従来のCI/CDでは、CIサーバから本番環境へのkubectl apply等を実行することが一般的でしたが、これにはいくつかの課題がありました。CIサーバが本番環境への強い権限を持つこと、デプロイの実行履歴がCIサーバ側に分散すること、現在の実環境の状態とリポジトリの宣言が乖離しても検知できないこと、などです。

GitOpsはこれらの課題に対する明確な解を提示しました。Pull型のデプロイメントにより、本番環境内部のエージェント(Argo CD等)がリポジトリを監視し、差分を検知して環境を収束させます。

02. Argo CD導入の最初の判断

Argo CDの導入を検討する際、まず決定すべきは「マルチクラスタ管理を行うか、クラスタごとに独立して導入するか」です。

当社の経験では、5クラスタ程度までであればクラスタごとの独立導入で十分です。それ以上の規模になると、中央のArgo CDから複数クラスタを管理する構成 (Hub-and-Spoke型) が運用効率の面で優位になります。

ただし、Hub-and-Spoke構成にはセキュリティ境界の議論が必要です。中央クラスタが各クラスタへの強い権限を持つことになるため、中央クラスタ自体のセキュリティ要件が大きく上がります。

03. アプリケーションのリポジトリ構成

GitOps導入で最も議論になるのは、リポジトリの構成です。代表的な選択肢は以下の三つです。

当社では、組織規模が小さいうちはApp+Config分離方式を、複数事業部にまたがる組織にはPer-App方式をお勧めしております。判断基準は「ひとつの変更を実装する際の作業範囲」をどう設定したいかです。

04. シークレット管理の現実的な解

GitOpsを採用する際の最大の壁は、シークレット情報の扱いです。「Gitリポジトリで宣言的に管理する」という思想と、「シークレットをリポジトリに含めない」という原則がぶつかります。

現実的な解として、当社では以下のいずれかを採用しております。

各方式に運用上の長所と短所がございます。シークレットの更新頻度、運用チームの規模、既存のシークレット管理基盤の有無を踏まえて選定いただくとよいでしょう。

05. 段階的な導入戦略

大規模な組織では、GitOpsを一度に全アプリケーションへ展開することは現実的ではありません。当社では、以下の段階での導入をお勧めしております。

  1. パイロット選定: 比較的小規模で、ステークホルダーが限定的なアプリケーションを一つ選び、まず本番環境までArgo CDで運用する。
  2. 運用パターンの確立: パイロットを通じて、リポジトリ構成・シークレット管理・通知設定・ロールバック手順を確立する。
  3. 横展開: 確立したパターンを、サービス単位で順次展開する。すべてを揃えるよりも、サービスごとの優先順位を尊重する。
  4. 標準化: 全サービスでの導入が完了した段階で、リポジトリテンプレートやポリシー (Open Policy Agent等) を整備し、新規サービスの立ち上げ手順を標準化する。

まとめ

GitOpsは、複数チームによるKubernetes運用を標準化する強力な手段ですが、その導入には組織側の論点(リポジトリ構成、シークレット管理、移行計画)が大きく影響します。技術選定だけではなく、運用設計まで踏み込んだ検討が必要です。

GitOps導入のご相談、Argo CDのPoC支援、リポジトリ設計につきましては、お問い合わせフォームよりお気軽にご連絡くださいませ。

高
高橋 美咲
CTO / Platform Engineering Lead