Skip to content
←

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

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. 大規模ArgoCD運用の課題

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

主要ボトルネック

| コンポーネント | ボトルネック | 症状 |

| ---------------------- | ----------------------------------- | --------------------------------- |

| Application Controller | 単一インスタンスで全App処理 | Reconciliation遅延、高メモリ使用 |

| Repository Server | Gitクローンとマニフェスト生成の負荷 | 遅い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_info | Application状態情報 |

| argocd_app_sync_total | 総同期回数 |

| argocd_app_reconcile_count | Reconciliation回数 |

| argocd_app_reconcile_bucket | Reconciliation所要時間分布 |

**API Serverメトリクス：**

| メトリクス | 説明 |

| ------------------------------------------ | --------------------- |

| argocd_api_server_request_total | APIリクエスト総数 |

| argocd_api_server_request_duration_seconds | APIリクエスト処理時間 |

**Repo Serverメトリクス：**

| メトリクス | 説明 |

| ----------------------------------- | --------------------- |

| argocd_git_request_total | Gitリクエスト総数 |

| argocd_git_request_duration_seconds | Gitリクエスト処理時間 |

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戦略タイプ

| 戦略 | RPO | RTO | コスト |

| ---------------- | -------------- | ------------ | ---------- |

| 定期バックアップ | 時間単位 | 30分 ~ 1時間 | 低い |

| GitOps自己管理 | 0（GitがSSoT） | 10 ~ 20分 | 中程度 |

| Active-Standby | 0 | 5分未満 | 高い |

| Active-Active | 0 | 即時 | 非常に高い |

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環境を構築できます。

현재 단락 (1/304)

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

작성 글자: 0자원문 글자: 7,483자작성 단락: 0/304