HA構成のArgoCD パフォーマンス最適化への道

Slide 1

Slide 1 text

HA構成のArgoCD パフォーマンス最適化への道石川雲(Kumo Ishikawa) 株式会社サイバーエージェントメディア統括本部サービスリライアビリティグループ(SRG) ishikawa_kumo@cyberagent.co.jp x: @ishikawa_kumo

Slide 2

Slide 2 text

自己紹介 ● 石川雲(いしかわくも) ● 2023年11月サイバーエージェント中途入社 ● 全社横断SRE組織に所属 ● 現在Ameba Platformチームで活動中本発表の記事版 ⇨ https://ca-srg.dev

Slide 3

Slide 3 text

1.ArgoCDについて 2.AmebaにおけるArgoCDの運用 3.ArgoCDのパフォーマンス問題 4.パフォーマンスに影響するパラメータ 5.シャーディング考察 6.改善の結果 7.まとめ

Slide 4

Slide 4 text

ArgoCDについて ArgoCD概要 ❏ Kubernetes向けの宣言型CDとGitOpsツール ❏ 2022/12 CNCF Graduated ❏ 現時点大人気

Slide 5

Slide 5 text

AmebaにおけるArgoCDの運用事業と歩むAmebaシステム刷新の道 https://cadc.cyberagent.co.jp /2022/program/the-road-to-a meba-system-renovation/ 運用開始: 2020年6月 ❏ Ameba刷新プロジェクト、Ameba Platform誕生 ❏ Ameba Platformについて

Slide 6

Slide 6 text

AmebaにおけるArgoCDの運用運用開始: 2020年6月 ❏ Ameba刷新プロジェクト、Ameba Platform誕生 ❏ AmebaBlogと周辺サービスのDelivery ❏ CI/CD刷新時、ArgoCD採択 ❏ 採択理由について: Findy Tools ArgoCD レビュー石川雲:「AmebaにおけるArgoCDの導入と運用」 https://findy-tools.io/product s/argo-cd/379/292 Findy-Tools: AmebaにおけるArgoCDの導入と運用

Slide 7

Slide 7 text

AmebaにおけるArgoCDの運用運用実態 ❏ クラスタ数: 5 ❏ アプリケーション数: 約250 ❏ リソース数: 35K ❏ 運用体制: 兼業2~3人 ❏ 利用者数: 約150人

Slide 8

Slide 8 text

AmebaにおけるArgoCDの運用パフォーマンス最適化前のArgoCD 略図

Slide 9

Slide 9 text

AmebaにおけるArgoCDの運用パフォーマンス最適化前のArgoCD HA構成 ❏ Application Controller: 1 ❏ CPU, Memory R/L: 1~2 core, 3~6 Gi ❏ Repository Server: 2 ❏ API Server: 2 ❏ Redis Server/Proxy: 3 ❏ その他: 1つずつ LastCommited: 2023/2

Slide 10

Slide 10 text

Ameba ArgoCDでのパフォーマンス問題

Slide 11

Slide 11 text

ArgoCDのパフォーマンス問題パフォーマンス問題に気づく定期開催のプラットフォームユーザ討論会でユーザの声 ❏ UI上、Filterをかけないと画面がフリーズして動かない ❏ UIが開けない時間帯がある ❏ ImagePush -> Deployまで20~30分かかる Platform管理者が確認したところ... ❏ 平常時ApplicationControllerはCPU1.9Core、メモリ5Gi使用 ❏ 半分のRepoServerとRedis Proxyは1分単位で再起動繰り返す ❏ 全体Applicationの45%はProgressing・Status Unknown

Slide 12

Slide 12 text

ArgoCDのパフォーマンス問題分析 ❏ ArgoCD専用監視がなかった ❏ リソース総数の増加によるPlatformの膨大化 ❏ リソース数: 10k(2022) -> 35k(2024) ⇨ 現行処理能力の限界 ❏ 数十名ユーザ直接利用 ❏ アクセス集中時間帯がある ⇨ たまに遅い原因 ❏ 各Application内リソース数が不均等 ❏ 1Applicationが100~2000 ⇨ 一部のApplication UIが極遅い原因 ❏ マルチクラスタ運用 ❏ 環境ごとにクラスタ分け、クラスタ間のリソース数・優先度が不均等 ❏ ⇨優先度に応じた負荷分散が必要

Slide 13

Slide 13 text

調査報告現時点のインターネット上の情報を網羅した * *日本語・英語・中国語のみ

Slide 14

Slide 14 text

コンポーネント概要 - argocd-server - api server + UI - application-controller - manifest deploy, reconciler - repo-server - git clone, manifest build 【ArgoCD🐙】ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組み https://hiroki-hasegawa.hatenablo g.jp/entry/2023/05/02/145115

Slide 15

Slide 15 text

ArgoCDコンポーネント - argocd-server - api server + UI - application-controller - manifest deploy, reconciler - repo-server - git clone, manifest build 【ArgoCD🐙】ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組み https://hiroki-hasegawa.hatenablo g.jp/entry/2023/05/02/145115

Slide 16

Slide 16 text

パフォーマンスに影響するパラメータパフォーマンスを表す 2つのメトリクス 1. Work Queueの処理時間 2. Work Queueの深さ 6つのパラメータ 1. SyncとReconcileの頻度 2. Controller Processor数 3. Repo キャッシュ時間 4. Helm/Kustomizeの使用 5. MonoRepoの使用 6. レプリカ数

Slide 17

Slide 17 text

パフォーマンスに影響するパラメータパフォーマンスを表す 2つのメトリクス(Datadogの場合) 1. argocd.app_controller. workqueue.work.duration .seconds.bu cket ❏ キュー内で一つのアイテムの処理時間 2. argocd.app_controller. workqueue.depth ❏ 未処理のアイテム数必要に応じて他のメトリクス(Redis/Git/API/Kubectl Exec)

Slide 18

Slide 18 text

パフォーマンスに影響するパラメータキューの種類 ❏ app_operation_processing_queue / appOperationQueue ❏ operation processor数で決まる ❏ ApplicationのSync実行 ❏ app_reconciliation_queue / appRefreshQueue ❏ status processor数で決まる ❏ ApplicationのReconcile実行 ❏ project_reconciliation_queue / projectRefreshQueue

Slide 19

Slide 19 text

パフォーマンスに影響するパラメータパフォーマンスを表す 2つのメトリクス 1. Work Queueの深さ 2. Work Queueの処理速度 6つのパラメータ 1. Reconcileの頻度 2. Controller Processor数 3. Repo キャッシュ時間 4. Helm/Kustomizeの使用 5. MonoRepoの使用 6. レプリカ数

Slide 20

Slide 20 text

パフォーマンスに影響するパラメータ 1. Reconcileの頻度 ❏ 頻度が高い -> 前の処理が終わらない -> WorkQueue(reconciliation)の消化が間に合わない -> Controller負荷高 -> 遅い ❏ 適切に設定することで、平常時Controller負荷低減 2. Controller Processor数 ❏ WorkQueueの処理能力(デフォルトApplication 400対応) ❏ 一説: 効果はKubeClient QPS/Burstと関係あり

Slide 21

Slide 21 text

パフォーマンスに影響するパラメータ 3. Repo キャッシュ時間 ❏ 短すぎるとRepo Server i/o timeoutエラー発生しやすい ❏ 長すぎるとVolume過剰使用 ❏ バランス: 適切なキャッシュ時間 4. Helm/Kustomizeの使用 ❏ Helm/Kustomize使う場合、RepoServer負荷高 ❏ 並列数減 -> 負荷減 -> 処理が遅い -> Timeout(90s)エラー発生 ❏ バランス: RepoServer並列数調整・実行Timeout調整

Slide 22

Slide 22 text

パフォーマンスに影響するパラメータ 5. MonoRepoの使用 ❏ マニフェスト生成: Repo内同時処理可能のApplication数が1 ❏ 対策: 並列処理有効化 ❏ キャッシュ: Repo更新したらキャッシュが消える ❏ 対策: Manifest Paths Annotation指定 6. レプリカ数 ❏ 処理能力が足りない: Repo・API・Controller ❏ Repo/API: Deployment ❏ Controller: StatefulSet(Sharding)

Slide 23

Slide 23 text

シャーディングについて深掘り

Slide 24

Slide 24 text

シャーディング考察 ❏ Application Controllerの水平スケーリング ❏ マルチクラスタまたはメモリ使用が高い場合向け ❏ 以下の設定が必須 ❏ spec.replicas = n ❏ env: ARGOCD_API_SERVER_REPLICAS = n ❏ レプリカ変更で再起動 ❏ 自動・手動シャーディング

Slide 25

Slide 25 text

シャーディング考察前提: シャーディングの分割単位はクラスタ ⇨クラスタ間のリソース数・優先度が不均等な場合、要注意 ⇧Amebaはこれに該当

Slide 26

Slide 26 text

シャーディング考察シャーディングアルゴリズム(手動指定も可能) ❏ Legacy(v1.8以降) ❏ ClusterIDのハッシュでShard決定 ❏ シンプルさを優先するなら ❏ Round-Robin(v2.8以降, Alpha) ❏ ClusterIDでソート後、均等にShard決定 ❏ (クラスタ数において)均等な負荷分散を求めるなら ❏ Consistent-Hash(v2.12以降, Alpha) ❏ 特殊ハッシュでShard決定 ❏ (クラスタ数)変更に対する耐性と安定性を求めるなら

Slide 27

Slide 27 text

シャーディング考察実験A(Shard数3 < クラスタ数5) SHAR D RESOURCES COUNT CLUSTER COUNT 0 15372 (123%) 2 1 21936 (176%) 3 2 0 (0%) 0 Legacy Round-Robin Consistent-Has h SHAR D RESOURCES COUNT CLUSTER COUNT 0 12122 (98%) 1 1 21939 (177%) 3 2 3165 (26%) 1 SHAR D RESOURCES COUNT CLUSTER COUNT 0 12534 (134%) 2 1 18871 (202%) 2 2 5938 (64%) 1

Slide 28

Slide 28 text

シャーディング考察実験A(Shard数3 < クラスタ数5) 　　　　　全てのアルゴリズムは最適解だと言えない SHAR D RESOURCES COUNT CLUSTER COUNT 0 15372 (123%) 2 1 21936 (176%) 3 2 0 (0%) 0 Legacy Round-Robin Consistent-Has h SHAR D RESOURCES COUNT CLUSTER COUNT 0 12122 (98%) 1 1 21939 (177%) 3 2 3165 (26%) 1 SHAR D RESOURCES COUNT CLUSTER COUNT 0 12534 (134%) 2 1 18871 (202%) 2 2 5938 (64%) 1

Slide 29

Slide 29 text

シャーディング考察 SHARD RESOURCES COUNT CLUSTER COUNT 0 2767 (37%) 1 1 9827 (132%) 1 2 9330 (125%) 1 3 9390 (126%) 1 4 5930 (80%) 1 Round-Robin 実験B(Shard数5 = クラスタ数5) 1 Shard メモリ: 700Mi~1Gi使用 ⇨リソースの浪費

Slide 30

Slide 30 text

シャーディング考察最終案: 手動Shard指定 ➢ 1Shardのリソース数最大値が10K ➢ 全てのShard利用率の理想は80%~130% ➢ 優先度高いクラスタに専用Shard SHARD RESOURCES COUNT CLUSTER COUNT 0 9390 (127%) 1 1 9523 (125%) 1 2 9474 (124%) 2 3 7702 (93%) 1 Manual

Slide 31

Slide 31 text

シャーディング考察実際に使ってみた結果一日何回もピーク

Slide 32

Slide 32 text

シャーディング考察実際に使ってみた結果一日何回もピーク処理時間減

Slide 33

Slide 33 text

シャーディング考察実際に使ってみた結果 177%の Shardが再起動

Slide 34

Slide 34 text

シャーディング考察実際に使ってみた結果

Slide 35

Slide 35 text

シャーディング考察注意 ❏ Shard計算はStatic ❏ Replicaの追加・削除時、StatefulSet再起動してShard再計算 ❏ 動的にしたい場合: Dynamic Cluster Distribution機能(v2.9, Alpha) ❏ StatefulSet -> Deployment、Replicaの追加・削除時自動再計算 ❏ Shardが停止した場合、そのShardのタスクは他のShardに引き継がれない ❏ 負荷の適切設定と監視

Slide 36

Slide 36 text

改善の結果パフォーマンス最適化後のArgoCD HA構成 ❏ Application Controller: 1 -> 4 ❏ CPU, Memory R/L: 1~2 core -> 200m~500m core, 3Gi~6Gi -> 500Mi~1 Gi ❏ Repository Server: 2 -> 4 ❏ API Server: 2 -> 4 ❏ Redis Server/Proxy: 3 ❏ その他: 1つずつ

Slide 37

Slide 37 text

改善の結果 Amebaの各パラメータの設定 ❏ Reconcile間隔: 3m -> 5m ❏ Jitter: 1m ❏ RepoCache時間: 24h -> 48h ❏ Controller⇨Repo Timeout: 1m -> 3m ❏ Repo Exec Timeout: 90s -> 180s ❏ Helm並列化: false -> true ❏ Controller Processors: 2x ❏ status 20-> 40 operation 10 -> 20 ❏ ARGOCD_K8S_CLIENT_QPS: 50 -> 100 ❏ ARGOCD_K8S_CLIENT_BURST: 100 -> 200

Slide 38

Slide 38 text

改善の結果パフォーマンス最適化前のArgoCD HA構成図

Slide 39

Slide 39 text

改善の結果パフォーマンス最適化後のArgoCD HA構成図

Slide 40

Slide 40 text

改善の結果 ❏ ArgoCD UI上０error 、描画速度 20%ほど上昇 ❏ Progressing率: 45% -> 2% ❏ Sync開始から終了まで平均 1min以内

Slide 41

Slide 41 text

まとめ ❏ ArgoCDの大規模運用ならチューニング必須 ❏ キャッシュ関連・Reconcile頻度関連・並列化関連 ❏ まだ改善の余地がある ❏ Server-side Pagination でUI速度の大幅改善が期待できそう ❏ 特定Shardに対応するために、Redisが過負荷 ❏ 2.13から改善される

Slide 42

Slide 42 text

ありがとうございました