Skip to content
Published on

[ArgoCD] 高可用性とスケーラビリティ：大規模クラスタ運用

🇰🇷KO🇺🇸EN🇯🇵JA
Split View
Authors

1. 大規模ArgoCD運用の課題

数百から数千のApplicationを管理する大規模環境では、ArgoCDのデフォルト構成では限界に達する可能性があります。

主要ボトルネック

コンポーネントボトルネック症状
Application Controller単一インスタンスで全App処理Reconciliation遅延、高メモリ使用
Repository ServerGitクローンとマニフェスト生成の負荷遅いSync、高CPU使用
Redisキャッシュデータの増大メモリ不足、接続遅延
API Server多数のユーザー同時接続UIレスポンス遅延、APIタイムアウト

2. HAアーキテクチャ

基本HA構成

                   Load Balancer
                        |
            +-----------+-----------+
            |           |           |
        API Server  API Server  API Server
        (replica 1) (replica 2) (replica 3)
            |           |           |
            +-----------+-----------+
                        |
                  Redis (Sentinel HA)
                        |
            +-----------+-----------+
            |           |           |
        Repo Server Repo Server Repo Server
        (replica 1) (replica 2) (replica 3)
            |
    App Controller (sharded)
    Shard 0 | Shard 1 | Shard 2

API Server HA

API Serverはステートレスなので、単にreplica数を増やして水平スケーリングします：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-server
  namespace: argocd
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: argocd-server
                topologyKey: kubernetes.io/hostname

3. Application Controllerシャーディング

シャーディングの概念

Application Controllerはデフォルトで単一インスタンスですべてのApplicationを処理します。大規模環境では複数のControllerインスタンスがApplicationを分散処理するシャーディングを適用します。

シャーディング設定

# argocd-cmd-params-cm ConfigMap
data:
  controller.sharding.algorithm: round-robin

StatefulSet基盤シャーディング

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: argocd-application-controller
  namespace: argocd
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: application-controller
          env:
            - name: ARGOCD_CONTROLLER_REPLICAS
              value: '3'

シャーディングアルゴリズム

Round-Robin（推奨）：

Applicationのハッシュをシャード数で割って割り当て
  App A -> hash(A) % 3 = Shard 0
  App B -> hash(B) % 3 = Shard 1
  App C -> hash(C) % 3 = Shard 2

Legacy：

クラスタベースのシャーディング
  クラスタ1の全App -> Shard 0
  クラスタ2の全App -> Shard 1
  クラスタ3の全App -> Shard 2

Leader Election

各Shard内で1つのControllerのみがアクティブになります。KubernetesのLeaseリソースを使用します：

Shard 0: Controller Pod A (Leader) + Pod D (Standby)
Shard 1: Controller Pod B (Leader) + Pod E (Standby)
Shard 2: Controller Pod C (Leader) + Pod F (Standby)

4. Repository Serverスケーリング

水平スケーリング

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
  namespace: argocd
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: repo-server
          resources:
            requests:
              cpu: '1'
              memory: '1Gi'
            limits:
              cpu: '2'
              memory: '2Gi'

キャッシュ最適化

env:
  - name: ARGOCD_REPO_SERVER_CACHE_EXPIRATION
    value: '24h'
  - name: ARGOCD_EXEC_TIMEOUT
    value: '180s'

Gitクローン最適化

env:
  - name: ARGOCD_GIT_SHALLOW_CLONE_DEPTH
    value: '1'
  - name: ARGOCD_GIT_REQUEST_TIMEOUT
    value: '60s'
  - name: ARGOCD_REPO_SERVER_PARALLELISM_LIMIT
    value: '10'

専用ボリューム

大規模リポジトリを処理するための一時ボリューム設定：

spec:
  template:
    spec:
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 10Gi
      containers:
        - name: repo-server
          volumeMounts:
            - name: tmp
              mountPath: /tmp

5. Redis HA

Redis Sentinel構成

redis-ha:
  enabled: true
  haproxy:
    enabled: true
    replicas: 3
  redis:
    replicas: 3
  sentinel:
    enabled: true
    replicas: 3

Redis Sentinelアーキテクチャ

             HAProxy (Load Balancer)
                    |
        +-----------+-----------+
        |           |           |
    Sentinel 1  Sentinel 2  Sentinel 3
        |           |           |
        +-----------+-----------+
                    |
        +-----------+-----------+
        |           |           |
    Redis Master  Redis Slave  Redis Slave

Redisメモリ最適化

data:
  redis.conf: |
    maxmemory 2gb
    maxmemory-policy allkeys-lru
    save ""
    appendonly no

外部マネージドRedisの使用

マネージドRedis（ElastiCache、Cloud Memorystoreなど）を使用できます：

data:
  redis.server: 'my-redis.xxxx.cache.amazonaws.com:6379'
  redis.tls: 'true'

6. パフォーマンスチューニング

Application Controllerチューニング

env:
  - name: ARGOCD_RECONCILIATION_TIMEOUT
    value: '300s'
  - name: ARGOCD_APP_RESYNC_PERIOD
    value: '180s'
  - name: ARGOCD_SELF_HEAL_TIMEOUT_SECONDS
    value: '5'
  - name: ARGOCD_APP_STATE_CACHE_EXPIRATION
    value: '1h'
  - name: ARGOCD_K8S_CLIENT_QPS
    value: '50'
  - name: ARGOCD_K8S_CLIENT_BURST
    value: '100'

リソース除外設定

不要なリソースをモニタリングから除外してパフォーマンスを向上：

# argocd-cm ConfigMap
data:
  resource.exclusions: |
    - apiGroups:
        - ""
      kinds:
        - "Event"
      clusters:
        - "*"
    - apiGroups:
        - "metrics.k8s.io"
      kinds:
        - "*"
      clusters:
        - "*"
    - apiGroups:
        - "coordination.k8s.io"
      kinds:
        - "Lease"
      clusters:
        - "*"

API Rate Limiting

Kubernetes APIサーバーへの負荷を制御：

env:
  - name: ARGOCD_K8S_CLIENT_QPS
    value: '50'
  - name: ARGOCD_K8S_CLIENT_BURST
    value: '100'

7. モニタリング

Prometheusメトリクス

Application Controllerメトリクス：

メトリクス説明
argocd_app_infoApplication状態情報
argocd_app_sync_total総同期回数
argocd_app_reconcile_countReconciliation回数
argocd_app_reconcile_bucketReconciliation所要時間分布

API Serverメトリクス：

メトリクス説明
argocd_api_server_request_totalAPIリクエスト総数
argocd_api_server_request_duration_secondsAPIリクエスト処理時間

Repo Serverメトリクス：

メトリクス説明
argocd_git_request_totalGitリクエスト総数
argocd_git_request_duration_secondsGitリクエスト処理時間

ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-metrics
  namespace: argocd
spec:
  selector:
    matchLabels:
      app.kubernetes.io/part-of: argocd
  endpoints:
    - port: metrics
      interval: 30s

アラートルール

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: argocd-alerts
spec:
  groups:
    - name: argocd
      rules:
        - alert: ArgoCDAppDegraded
          expr: argocd_app_info{health_status="Degraded"} > 0
          for: 5m
          labels:
            severity: warning

        - alert: ArgoCDAppSyncFailed
          expr: increase(argocd_app_sync_total{phase="Error"}[10m]) > 0
          for: 1m
          labels:
            severity: critical

        - alert: ArgoCDReconciliationSlow
          expr: histogram_quantile(0.99, argocd_app_reconcile_bucket) > 60
          for: 10m
          labels:
            severity: warning

8. 災害復旧（Disaster Recovery）

バックアップ戦略

# ArgoCD全体設定バックアップ
argocd admin export > argocd-backup.yaml

# 個別リソースバックアップ
kubectl get applications -n argocd -o yaml > applications-backup.yaml
kubectl get appprojects -n argocd -o yaml > projects-backup.yaml
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=repository -o yaml > repos-backup.yaml
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster -o yaml > clusters-backup.yaml

復元手順

# 1. ArgoCDインストール
kubectl create namespace argocd
kubectl apply -n argocd -f install.yaml

# 2. 設定復元
kubectl apply -f argocd-cm-backup.yaml
kubectl apply -f argocd-rbac-cm-backup.yaml

# 3. 資格情報復元
kubectl apply -f repos-backup.yaml
kubectl apply -f clusters-backup.yaml

# 4. プロジェクトとApplication復元
kubectl apply -f projects-backup.yaml
kubectl apply -f applications-backup.yaml

GitOpsでArgoCDを管理

ArgoCD自体をGitOpsで管理すると災害復旧が簡素化されます：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-self
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/argocd-config.git
    targetRevision: HEAD
    path: argocd
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      selfHeal: true

DR戦略タイプ

戦略RPORTOコスト
定期バックアップ時間単位30分 ~ 1時間低い
GitOps自己管理0（GitがSSoT）10 ~ 20分中程度
Active-Standby05分未満高い
Active-Active0即時非常に高い

9. 大規模運用チェックリスト

100+ Application環境

  • Controller replica: 2-3（シャーディング）
  • Repo Server replica: 2-3
  • Redis HA: Sentinel構成
  • API Server replica: 2-3
  • リソース除外設定を適用
  • キャッシュ有効期限の最適化

500+ Application環境

  • Controller replica: 3-5（シャーディング）
  • Repo Server replica: 3-5
  • Redis HA: Sentinel + メモリ最適化
  • クラスタ別API Rate Limitingを適用
  • モニタリングアラートの設定
  • 定期バックアップの自動化

1000+ Application環境

  • Controller replica: 5+（シャーディング）
  • Repo Server replica: 5+（専用ボリューム）
  • 外部マネージドRedisを使用
  • ApplicationSetで管理複雑度を削減
  • マルチArgoCDインスタンスの検討
  • 専用モニタリングダッシュボードの構築

10. まとめ

ArgoCDの高可用性とスケーラビリティの核心要素：

  1. Controllerシャーディング：StatefulSet基盤のApplication分散処理
  2. Repo Serverスケーリング：水平拡張 + キャッシュ最適化 + Gitクローン最適化
  3. Redis HA：Sentinel構成またはマネージドRedisの使用
  4. パフォーマンスチューニング：リソース除外、API Rate Limiting、Reconciliation周期の調整
  5. モニタリング：Prometheusメトリクス + Grafanaダッシュボード + アラートルール
  6. 災害復旧：定期バックアップ + GitOps自己管理 + DR戦略

これらの要素を段階的に適用することで、数千のApplicationを安定的に管理するArgoCD環境を構築できます。

Discuss on Twitter • View on GitHub