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

Transcript

1. HA構成のArgoCD パフォーマンス最適化への 道 石川雲(Kumo Ishikawa) 株式会社サイバーエージェント メディア統括本部 サービスリライアビリティグループ(SRG) ishikawa_kumo@cyberagent.co.jp x: @ishikawa_kumo
2. 自己紹介 • 石川 雲(いしかわ くも) • 2023年11月サイバーエージェント中途入社 • 全社横断SRE組織に所属 • 現在Ameba Platformチームで活動中 本発表の記事版 ⇨ https://ca-srg.dev
3. 1.ArgoCDについて 2.AmebaにおけるArgoCDの運用 3.ArgoCDのパフォーマンス問題 4.パフォーマンスに影響するパラメータ 5.シャーディング考察 6.改善の結果 7.まとめ
4. ArgoCDについて ArgoCD概要 ❏ Kubernetes向けの宣言型CDとGitOpsツール ❏ 2022/12 CNCF Graduated ❏ 現時点大人気
5. AmebaにおけるArgoCDの運用 事業と歩むAmebaシステム刷 新の道 https://cadc.cyberagent.co.jp /2022/program/the-road-to-a meba-system-renovation/ 運用開始: 2020年6月 ❏ Ameba刷新プロジェクト、Ameba Platform誕生 ❏ Ameba Platformについて
6. 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の導入と運用
7. AmebaにおけるArgoCDの運用 運用実態 ❏ クラスタ数: 5 ❏ アプリケーション数: 約250 ❏ リソース数: 35K ❏ 運用体制: 兼業2~3人 ❏ 利用者数: 約150人
8. AmebaにおけるArgoCDの運用 パフォーマンス最適化前のArgoCD 略図
9. 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
10. Ameba ArgoCDで の パフォーマンス問題
11. ArgoCDのパフォーマンス問題 パフォーマンス問題に気づく 定期開催のプラットフォームユーザ討論会でユーザの声 ❏ UI上、Filterをかけないと画面がフリーズして動かない ❏ UIが開けない時間帯がある ❏ ImagePush -> Deployまで20~30分かかる Platform管理者が確認したところ... ❏ 平常時ApplicationControllerはCPU1.9Core、メモリ5Gi使用 ❏ 半分のRepoServerとRedis Proxyは1分単位で再起動繰り返す ❏ 全体Applicationの45%はProgressing・Status Unknown
12. ArgoCDのパフォーマンス問題 分析 ❏ ArgoCD専用監視がなかった ❏ リソース総数の増加によるPlatformの膨大化 ❏ リソース数: 10k(2022) -> 35k(2024) ⇨ 現行処理能力の限界 ❏ 数十名ユーザ直接利用 ❏ アクセス集中時間帯がある ⇨ たまに遅い原因 ❏ 各Application内リソース数が不均等 ❏ 1Applicationが100~2000 ⇨ 一部のApplication UIが極遅い原因 ❏ マルチクラスタ運用 ❏ 環境ごとにクラスタ分け、クラスタ間のリソース数・優先度が不均等 ❏ ⇨優先度に応じた負荷分散が必要
13. 調査報告 現時点のインターネット上の情報を網羅した * *日本語・英語・中国語のみ
14. コンポーネント概要 - 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
15. 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
16. パフォーマンスに影響するパラメータ パフォーマンスを表す 2つのメトリクス 1. Work Queueの処理時間 2. Work Queueの深さ 6つのパラメータ 1. SyncとReconcileの頻度 2. Controller Processor数 3. Repo キャッシュ時間 4. Helm/Kustomizeの使用 5. MonoRepoの使用 6. レプリカ数
17. パフォーマンスに影響するパラメータ パフォーマンスを表す 2つのメトリクス(Datadogの場合) 1. argocd.app_controller. workqueue.work.duration .seconds.bu cket ❏ キュー内で一つのアイテムの処理時間 2. argocd.app_controller. workqueue.depth ❏ 未処理のアイテム数 必要に応じて他のメトリクス(Redis/Git/API/Kubectl Exec)
18. パフォーマンスに影響するパラメータ キューの種類 ❏ app_operation_processing_queue / appOperationQueue ❏ operation processor数で決まる ❏ ApplicationのSync実行 ❏ app_reconciliation_queue / appRefreshQueue ❏ status processor数で決まる ❏ ApplicationのReconcile実行 ❏ project_reconciliation_queue / projectRefreshQueue
19. パフォーマンスに影響するパラメータ パフォーマンスを表す 2つのメトリクス 1. Work Queueの深さ 2. Work Queueの処理速度 6つのパラメータ 1. Reconcileの頻度 2. Controller Processor数 3. Repo キャッシュ時間 4. Helm/Kustomizeの使用 5. MonoRepoの使用 6. レプリカ数
20. パフォーマンスに影響するパラメータ 1. Reconcileの頻度 ❏ 頻度が高い -> 前の処理が終わらない -> WorkQueue(reconciliation)の消化が間に合わない -> Controller負荷高 -> 遅い ❏ 適切に設定することで、平常時Controller負荷低減 2. Controller Processor数 ❏ WorkQueueの処理能力(デフォルトApplication 400対応) ❏ 一説: 効果はKubeClient QPS/Burstと関係あり
21. パフォーマンスに影響するパラメータ 3. Repo キャッシュ時間 ❏ 短すぎるとRepo Server i/o timeoutエラー発生しやすい ❏ 長すぎるとVolume過剰使用 ❏ バランス: 適切なキャッシュ時間 4. Helm/Kustomizeの使用 ❏ Helm/Kustomize使う場合、RepoServer負荷高 ❏ 並列数減 -> 負荷減 -> 処理が遅い -> Timeout(90s)エラー発生 ❏ バランス: RepoServer並列数調整・実行Timeout調整
22. パフォーマンスに影響するパラメータ 5. MonoRepoの使用 ❏ マニフェスト生成: Repo内同時処理可能のApplication数が1 ❏ 対策: 並列処理有効化 ❏ キャッシュ: Repo更新したらキャッシュが消える ❏ 対策: Manifest Paths Annotation指定 6. レプリカ数 ❏ 処理能力が足りない: Repo・API・Controller ❏ Repo/API: Deployment ❏ Controller: StatefulSet(Sharding)
23. シャーディングについて深掘 り
24. シャーディング考察 ❏ Application Controllerの水平スケーリング ❏ マルチクラスタまたはメモリ使用が高い場合向け ❏ 以下の設定が必須 ❏ spec.replicas = n ❏ env: ARGOCD_API_SERVER_REPLICAS = n ❏ レプリカ変更で再起動 ❏ 自動・手動シャーディング
25. シャーディング考察 前提: シャーディングの分割単位は クラスタ ⇨クラスタ間のリソース数・優先度が 不均等な場合、要注意 ⇧Amebaはこれに該当
26. シャーディング考察 シャーディングアルゴリズム(手動指定も可能) ❏ Legacy(v1.8以降) ❏ ClusterIDのハッシュでShard決定 ❏ シンプルさを優先するなら ❏ Round-Robin(v2.8以降, Alpha) ❏ ClusterIDでソート後、均等にShard決定 ❏ (クラスタ数において)均等な負荷分散を求めるなら ❏ Consistent-Hash(v2.12以降, Alpha) ❏ 特殊ハッシュでShard決定 ❏ (クラスタ数)変更に対する耐性と安定性を求めるなら
27. シャーディング考察 実験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
28. シャーディング考察 実験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
29. シャーディング考察 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使用 ⇨リソースの浪費
30. シャーディング考察 最終案: 手動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
31. シャーディング考察 実際に使ってみた結果 一日何回 もピーク
32. シャーディング考察 実際に使ってみた結果 一日何回 もピーク 処理 時間減
33. シャーディング考察 実際に使ってみた結果 177%の Shardが 再起動
34. シャーディング考察 実際に使ってみた結果
35. シャーディング考察 注意 ❏ Shard計算はStatic ❏ Replicaの追加・削除時、StatefulSet再起動してShard再計算 ❏ 動的にしたい場合: Dynamic Cluster Distribution機能(v2.9, Alpha) ❏ StatefulSet -> Deployment、Replicaの追加・削除時自動再計算 ❏ Shardが停止した場合、そのShardのタスクは他のShardに 引き継がれない ❏ 負荷の適切設定と監視
36. 改善の結果 パフォーマンス最適化後の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つずつ
37. 改善の結果 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
38. 改善の結果 パフォーマンス最適化前のArgoCD HA構成図
39. 改善の結果 パフォーマンス最適化後のArgoCD HA構成図
40. 改善の結果 ❏ ArgoCD UI上 ０error 、描画速度 20%ほど上昇 ❏ Progressing率: 45% -> 2% ❏ Sync開始から終了まで平均 1min以内
41. まとめ ❏ ArgoCDの大規模運用ならチューニング必須 ❏ キャッシュ関連・Reconcile頻度関連・並列化関連 ❏ まだ改善の余地がある ❏ Server-side Pagination でUI速度の大幅改善が期待できそう ❏ 特定Shardに対応するために、Redisが過負荷 ❏ 2.13から改善される
42. ありがとうございました