AmebaにおけるArgoCDの導入と運用

ツール導入前の課題

Ameba事業は長い歴史の中で、古い機能やシステムが多く残り、技術的負債を抱えていました。主な課題として、事業の継続に伴うシステムの肥大化と技術選定の複雑さによる認知負荷がありました。 これを受けて、Ameba刷新プロジェクトが2020年以降に立ち上がり、Ameba Platformの誕生とともにCI/CDの統一と再構築が重要な課題として取り組まれることになりました。詳細はこちらの記事をご参照ください。

目指していた状態

Ameba刷新プロジェクトのCI/CD部分では、以下のような理想的な状態を目指していました:

• 技術選定の統一化による認知負荷の軽減
  使用する技術をあらかじめ制限し、技術選定が複雑になりすぎないようにすることで、開発者の認知負荷を減らす

• 開発フローの統合とシンプル化
  全サービスで統一された開発フローを実現し、DeliveryおよびOperationで使用するツールやプロセスを統合する

• 「レポジトリの状態 = 現在の状態」を実現する
  GitOpsの原則に従い、常にレポジトリの内容がシステムの現在の状態と一致するようにすることで、可視性と透明性を向上させる

• シンプルなCI/CDトリガー
  開発者がCI/CDをトリガーできる操作を「アプリケーションコードのpush」に限定し、複雑な設定を不要にする

• パイプラインのコード化
  CI/CDパイプライン自体をコードとして定義することで、バージョン管理を可能にし、再利用性や保守性を向上させる

• 専属の担当者を不要にする設計
  運用や保守に専属の担当者が必要とならないよう、シンプルで自律的な設計を採用する

• Spinnaker
• ArgoCD
• FluxCD
• Brigade
• Tekton
• Screwdriver
• JenkinsX
• GoCD
• Concourse

導入と運用の簡素性

• 初期導入やアップグレード時の手間が少ないこと
• 本体の運用と操作が簡単で、UIとCLIの両方で管理可能
• CDプロセスの中核として機能し、外部コンポーネントへの依存が少ない
• 専属の担当者が必要とならないよう、自律性を持つ

機能の豊富さ

• 宣言型インフラストラクチャに対応
• Kubernetesマニフェストのデプロイ機能
• 差分検知と差分プレビュー
• 汎用テンプレートエンジンへの対応 (Helm/Kustomize)
• 多様な通知と認証機能
• スケーラビリティがある

コミュニティとサポートの活発度

• CNCFプロジェクトであること
• Github IssuesやPull Requestsの処理速度が速く、活力がある
• Platformチームの技術スタックに合致し、Issueの提起やコントリビュートが可能

ArgoCDの導入と管理が容易

• Bootstrapのプロセスが不要で、HA構成でも単一のYAMLファイルでデプロイ可能
  • FluxCDやSpinnakerなどは、導入やアップグレードが複雑
• UI用のLoadBalancerとKubernetesクラスタ以外の外部コンポーネントが不要で、全てがPod内で完結
  • (2020年当時の)Spinnakerでは通知機能やマニフェスト管理機能が弱く、追加のクラウドリソース(S3/Lambda/SNS)が必要だった

ArgoCDの優れたユーザー体験

• ArgoCDのUIは速度とわかりやすさが高評価
  • (2020年当時の)SpinnakerのUIはバグが多かった
  • FluxCDなどはUIがない
• Kubernetesへのデプロイというコア機能をデフォルトで持っている
  • ArgoCDはKubernetesへのデプロイに特化した設計
  • ConcourseやTektonのように、多くのTaskやPipelineリソースの定義を開発・テスト・管理する必要がある
• ArgoCDのデプロイスピードが速い
  • (2020年当時の)Spinnakerなどの汎用的なCDツールは、Kubernetes以外のリソースも管理するため、全体的に速度が遅い

ArgoCDの活発なコミュニティとPlatformチームとの親和性

• 2020年時点で既にIncubating Projectに昇格しており、最も期待されているCDプロジェクトだった
• 社内Platformチームの技術スタック(Go言語が多い)と親和性が高く、Issueを提起しやすい環境

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

• 導入から4年で完全なGitOpsを実現し、Ameba Platformのコアの1つとなった
• 全開発者がArgoCDのUIを熟練して操作できるようになり、認知負荷が大幅に軽減され、運用専任者がいなくても自律的に運用できる状態が整った
• 全環境へのデプロイが3分以内に完了するようになり、刷新前と比べて開発効率が大幅に向上

Private Github Enterprise Serverとの接続問題

開発用のGithubリポジトリは社内ネットワーク内のGithub Enterprise Serverを利用しており、ArgoCDコンポーネントがAWS上に存在していたため、リポジトリへの接続が問題となりました。SSHのプロキシレベルでの解決を試みましたが、結果として失敗しました。最終的に、全社のインフラ組織にGithub Enterprise ServerへのHTTPプロキシを用意してもらい、ArgoCDのNO_PROXYおよびHTTP(S)_PROXY設定で問題を解決しました。

CRDリソースとの互換性問題

• CRDリソースによるChildResourceのトラッキング
  Ameba Platformでは、Kubernetesマニフェストに関する認知負荷を減らすために、Open Application Model (KubeVela)を導入し、事前に定めたフォーマットとYAMLロジックでKubernetesマニフェストを生成・管理しています。そのため、ArgoCDが直接管理しているのはKubernetesマニフェストではなく、KubeVelaのApplicationリソースです。ArgoCDのUI上で安易にChild Resourceをトラッキング対象に追加すると、全体の差分表示やSync状態に影響を与えるため、instanceLabelKeyなどを活用し、ArgoCD UIでChildResourceも管理できるようにしました。
• ImageTagUpdate問題
  Open Application Modelの導入により、ArgoCD Image Updaterが使用できなくなりました。その代わりにFluxCDのImage Updaterを導入し、ArgoCDとFluxCDを組み合わせて運用しています。

パフォーマンス最適化問題

導入から数年が経過した後、Syncが遅い、UIが遅いという問題が顕在化し、HA構成の上でさらなるスケールアウト・アップが必要となりました。2024年10月時点では、ArgoCDのシャーディングアルゴリズムはマルチクラスタ間の負荷分散には適しておらず、手動でシャーディングを行っています。
また、運用の実態に合わせて、SyncとReconcileの周期やキャッシュサイズ・期間を見直し、全体のパフォーマンスを最適化しました。 パフォーマンス最適化の詳細は、こちらの記事をご参照ください。

Syncフローのカスタマイズ

Ameba Platformでは、責務分離とマイクロサービス対応のため、ArgoCD Applicationは大きめに設定しています。そのため、1つのArgoCD Applicationが複数のKubeVela Applicationを通じて、数十から数百単位のDeploymentを管理しています。この運用においては、ArgoCDのResource Hooks機能がKubeVela Application単位で操作できないため、KubeVela WorkflowとArgo Eventsを導入しました。