Ameba CI/CD: Terraform and Argo CD Improvements

Transcript

1. 数万リソースのCI/CDを爆速に! Terraform・ArgoCD 改善の全記録 石川　雲 Kumo Ishikawa
2. •2023年11月中途入社 •横断組織 Service Reliability Group (SRG)所属 •Ameba Platform 担当 •得意領域 Security Multi-Tenant・Zero Trust・Runtime Monitoring CI/CD ArgoCD・FluxCD・Terraform PipeCD Contribute (Auth) 石川　雲　Kumo Ishikawa
3. 本セッションの内容 Ameba PlatformにおけるCI/CDの進化と運用改善 具体的には... ❏ CI/CDの構成 と2022年以降に顕在化した課題の解決 ❏ Terraform / ArgoCD / FluxCDの パフォーマンス最適化 事例 ❏ ArgoCD上の Resource Tracking と生成Resource の扱い ❏ CI/CD後の Workflow自動化 に向けた検討
4. 1.CI/CDの概要 2.CIの課題と解決 Terraformの処理最適化 3.CDの課題と解決 その1 ArgoCD・FluxCDの運用改善 その2 生成Resourceのステータス その3 Post Release Workflowの導入 4.まとめ
5. CI/CDの概要
6. 背景 Amebaシステム刷新 ❏ 2019年からオンプレミスからAWS移行 ❏ 共通開発者基盤Ameba Platformの立ち上げ ❏ 共通開発者基盤の一部: CI/CD基盤
7. 背景 Amebaシステム刷新 ❏ 2019年からオンプレミスからAWS移行 ❏ 共通開発者基盤Ameba Platformの立ち上げ ❏ 共通開発者基盤の一部: CI/CD基盤 今日の補足資料は 全てXで投稿する予定
8. CI/CD基盤の歴史 当初設計の主な要件(2019) ❏ 認知負荷を軽減できる技術選定 ❏ GitOps原則「レポジトリ = 状態」 ❏ シンプルなCI/CDトリガーとイベント設計 ❏ CI/CDパイプラインのコード化 ❏ 専属担当者を不要とする設計(全員が担当者)
9. CI/CDの構成 3つの部分 ❏ Product ❏ Shared ❏ Platform
10. CI/CDの構成 - CI (Product) CI (Product) ❏ Image Push ❏ ECRへ ❏ Test ❏ Code管理 CD (Product) ❏ Platformへ ❏ 手動実行 ❏ CDN操作 ❏ Schema操作
11. CI/CDの構成 - CI (Shared) CI (Shared) ❏ Terraform ❏ CDN ❏ DNS ❏ AWS ❏ GHA利用
12. CI/CDの構成 - CD(Platform) CD(Platform) ❏ FluxCD ❏ Image Tag ❏ ArgoCD ❏ KubeVela ❏ CR -> Raw
13. KubeVela: アプリケーション定義モデル KubeVelaとは ❏ OAMモデルを使用して開発者のデプロイを簡素化し、 拡張性を実現するツール ❏ 事前に定義したyamlで、必要なKuberentes Manifestを生成 する
14. CI/CDの構成 - 責任分界点 開発者(Product) ❏ Product Side ❏ Shared Side ❏ Terraform ❏ Manifest ❏ Platform Side ❏ ArgoCD 開発者(Platform) ❏ Shared Side ❏ Platform Side
15. CIの課題と解決
16. Terraformの構成(旧) Github Actions 構成 ❏ Plan/Apply全部On: Push ❏ Env Matrixで全環境を一括同時実行 ❏ 1環境に1Runner
17. Terraformの構成(旧) Github Actions 構成 ❏ Runnerで、モジュール単位ごとにマルチスレッドで実行 ❏ Runner内は1000行のシェルスクリプト
18. Terraformの構成(旧) tfstate State構成 ❏ S3 Backend利用 ❏ Workspace利用 ❏ Env名= Workspace名 ❏ マイクロサービス単位でState分け
19. Terraformの構成(旧) モジュール構成 ❏ Env/とModules/のクラシックな構成
20. Terraformの構成(旧) モジュール構成 ❏ マイクロサービス単位でモジュール分け ❏ Platformも単独のモジュール
21. Terraformの構成(旧) モジュール構成 ❏ 各マイクロサービスの各環境は独自のモジュールを利用 ❏ Env/<Service>以下はResource書かない
22. CIの課題 Platform利用者の声 ❏ PlanとApplyが非常に遅い ❏ 一部リソース(RDSなど)の適用が遅すぎる ❏ Applyの範囲が広すぎて、他のAppのDriftを適用してしまった
23. CIの課題 データで見てみると Plan ❏ 平均時間:741.2s (12.4min ) ❏ 中央値: 347.0s (5.8min ) ❏ p75: 363.0s (6.1min ) Apply ❏ 平均時間:387.4s (6.5min ) ❏ 中央値: 335.0s (5.6min ) ❏ p75: 417.0s (7.0min )
24. CIの課題 原因 ❏ 一部AWS側APIが遅い ❏ RDS・EC2などの変更自体は時間かかる ❏ リソースの増加とStateの肥大化 ❏ 不適切なCI構成 2022 2024 Platform Module 300KB~400KB 1.1MB~1.2MB MicroService Module (avg) 50KB~60KB 200KB~300KB
25. CIの課題 不適切なCI構成 一つのRunnerでService数のスレッ ド数で並列実行 ⇨ Runner CPU利用率常に100%
26. CIの課題と解決: Terraformの処理最適化
27. Terraformの速度を上げる方法 一般的な方法 遅いCloud Resourceの分離 ❏ 極端に遅いCloud Resourceは個別のモジュール・Terraform以外で管理 tfstateの分割 ❏ 使いやすい程度で分割(~500KB) 並列処理数を上げる ❏ Runner性能とリソース間依存/順序によって効果がない場合がある Providerダウンロード時間を減らす ❏ ProviderのCache設定
28. Terraformの速度を上げる方法 トリック Planファイルを利用してApply ❏ terraform apply -auto-approve xxx.tfplan ❏ Applyがとても速くなるが、tfplanの最新性を保つ必要がある Targetを指定する ❏ terraform apply -target="module.eks_addon" ❏ 単体ターゲットの定期実行に向いてる Refreshを無効化 ❏ terraform plan -refresh=false ❏ stateが大きい場合、ある程度時間を削減できる
29. Amebaでの対策 単体モジュールの速度ではなく、CI全体の実行速度にフォーカス 1. 現行モジュール分けを維持し、変更があったモジュールだけ Terraform操作を行う 2. モジュール単位でRunnerを分け て同時実行 3. その上で、単体モジュールの実行速度を上げる
30. Amebaでの対策 具体的には ❏ 一部Cloud ResourceをTerraformから廃止検討 ❏ EKS EC2 AutoScalingGroup、Karpenterへ移行 ❏ Auroraなどは検討中 ❏ Planファイルを利用してApply ❏ Runnerの上限まで並列処理数を上げる ❏ 大きいState: 10(Default) ❏ 小さいState: 30 ❏ Providerファイルのキャッシング
31. 構成図の変化
32. Amebaでの対策
33. Amebaでの対策
34. Amebaでの対策 差分発生した Moduleを対象 にMatrix生成
35. Amebaでの対策 Applyも同じ くMatrix生成
36. Amebaでの対策 Plan FileはArtifactで共 有
37. ドリフトによる遅延 一部のドリフトによってTerraformの実行が遅くなることもある ❏ EC2 Image ID (ASG) の自動変更 ❏ 適用すると10min~20minかかる ❏ 1週間に一度、このドリフトに遭遇する不幸が発生する
38. ドリフトによる遅延 対策 ❏ ドリフトを検知する定期実行Healthcheck ❏ EC2 AMI IDの自動変更が発生したら、Applyまで自動的に適用する
39. 改善結果 実行時間: 最大9割削減、平均7割削減を達成
40. 改善結果 改善前(2024/2) Plan ❏ 平均時間:741.2s (12.4min ) ❏ 中央値: 347.0s (5.8min ) ❏ p75: 363.0s (6.1min ) Apply ❏ 平均時間:387.4s (6.5min ) ❏ 中央値: 335.0s (5.6min ) ❏ p75: 417.0s (7.0min ) 改善後(2025/5) Plan ❏ 平均時間:234.0s (3.9min ) ❏ 中央値: 72.1s (1.2min ) ❏ p75: 117.6s (1.9min ) Apply ❏ 平均時間:251s (4.2min ) ❏ 中央値: 99.2s (1.7min ) ❏ p75:195.0s (3.3min ) 実行時間: 最大9割削減、平均7割削減を達成
41. Terraformに関するまとめ キーポイント ❏ 差分ベースで必要のModuleを絞る ❏ Runnerの並列化を利用する ❏ Runner単体の性能を最大限まで利用する
42. CDの課題と解決
43. CDの課題と解決　その1 ArgoCD・FluxCDの運用改善
44. CDの構成 CD(Platform) ❏ FluxCD ❏ Image Tag ❏ ArgoCD ❏ KubeVela ❏ CR -> Raw
45. CDの課題 ❏ ArgoCD: ❏ 同期が遅い ❏ ImagePush -> AutoSync -> Sync完了まで20~30分かかる ❏ 画面が遅い ❏ UI上、Filterをかけないと画面がフリーズして動かない ❏ FluxCD: ❏ FluxCDの動きが遅く、ImageTag更新が止まる
46. CDの課題 ArgoCD Core Componentの状態 ❏ ApplicationControllerは平常時でもカツカツ状態 ❏ CPU 95%、メモリ 90%使用(Limit) ❏ 2/3のRepoServerとRedis Proxyは1分単位で再起動繰り返す ❏ 全体Applicationの45%はProgressing・Status Unknown FluxCD Componentの状態 ❏ ECR更新のタイミングで、ImageXXXControllerがOOM Killedで再起動
47. CDの課題 原因: リソース総数の増加 ❏ リソース数合計: 10k(2022) -> 35k(2024) ❏ 1 MicroServiceのKubernetesリソース数 ❏ 平均: 100(2022) -> 500 (2024) ❏ 一部: 2000~3000
48. ArgoCDのパフォーマンス改善
49. ArgoCDのパフォーマンス改善 最も効果的な方法 ❏ 各コンポーネントの水平スケーリング ❏ パフォーマンス改善に大きく貢献: ApplicationControllerとRepoServer ❏ MonoRepo対策 ❏ 意外と軽視されがち
50. ArgoCDのパフォーマンス改善 水平スケーリング Application Controller ❏ Shardingの分割単位: クラスタ ❏ Shardへ自動・手動クラスタ指定 Repo Server・API Server ❏ スケールすることでパフォーマンス激的に改善 Redis ❏ 3つという前提 Dexなど ❏ スケールすると不整合が起きる
51. ArgoCDのパフォーマンス改善 MonoRepo問題とは ❏ MonoRepo運用 ❏ 複数のArgoCD Applicationが単一のGit Repoをポーリングしている ❏ 専用のManifest用Repo ❏ ArgoCD特性 ❏ 新しいコミットが同期されると、そのRepoに関する全てのキャッシュが再作成される ❏ MonoRepoの場合 ❏ デプロイ対象のManifestだけでなく、それ以外のManifestの変更があっても キャッシュが再作成される ❏ Repo内のAppが数十個以上の場合、パフォーマンスに大きな影響
52. ArgoCDのパフォーマンス改善 MonoRepo対策 ❏ Git Webhook ❏ Annotation: manifest-generate-paths
53. ArgoCDのパフォーマンス改善 パラメータチューニング Application Controller ❏ 調整(Reconcile)期間: デフォルト3min ❏ timeout.reconciliation ❏ 短すぎるとWorkQueueの処理待ち件数が滞留して常にピーク状態、適切に伸ばす ❏ Processor数: ❏ controller.status.processors (appRefreshQueue: Application状態監視) ❏ controller.operation.processors (appOperationQueue: Kubernetesリソース操作) ❏ 上げるとWorkQueueの処理効率が上がる ❏ 調整Jitter: ❏ timeout.reconciliation.jitter ❏ 複数Appの実行タイミングを乱数化、スパイク回避 ❏ timeout.reconciliationが3min, jitterが1minの場合: 調整間隔区間が[3min, 3min+1min]
54. ArgoCDのパフォーマンス改善 パラメータチューニング Repo Server ❏ キャッシュ期間: ❏ reposerver.repo.cache.expiration ❏ ディスクI/O効率に影響、短すぎるとTimeout発生、適切に伸ばす ❏ 並列数: ❏ --parallelismlimit ❏ Helm/KustomizeなどのManifest生成効率に影響、適切に上げる
55. Amebaの改善 Application Controller ❏ Reconcile Timeout: 3min -> 5min ❏ Processor数: status/operation 3倍 ❏ Reconcile Jitter: 1min (Reconcile Timeout: 5min~6min) ❏ Shareds: 1台運用 -> １クラスタ = １Shard運用 Repo Server ❏ キャッシュ期間: 24h -> 48h ❏ Replicas: 3 -> 6
56. 構成図の変化
57. 各Core Component(2022) 2022: デフォルトHA構成運用 ❏ ApplicationController ❏ HAデフォルト1台 ❏ RepoServer ❏ HAデフォルト3台 ❏ Redis ❏ HAデフォルト3台
58. 各Core Component(2024) 2024: 1 Shard = 1 Cluster
59. 改善結果 ArgoCD Work Queueの処理待ち件数と処理時間激減
60. 改善結果 ArgoCD Work Queueの処理待ち件数と処理時間激減 処理待ち件数がほぼ0に 処理時間が7割減
61. FluxCDのパフォーマンス改善
62. FluxCDのパフォーマンス改善 水平スケーリング ❏ 全Controller対象 ❏ Flux Custom Resourceを各Shardへアサイン ❏ 手動アサインしかない Amebaでは ❏ リソース量が多いAppを新しいShardに指定
63. 構成図の変化
64. 構成図の変化 2022: デフォルト構成 ❏ Reflector ❏ ECRのタグを監視し、ImagePolicy通りに記録 ❏ Automation ❏ ImageUpdateAutomation設定通り、Manifestのタグを更新
65. 構成図の変化 2024: リソース量が多いAppを新しいShardに指定
66. 構成図の変化 2024: リソース量が多いAppを新しいShardに指定 FluxCDのダウンタイムが0になった
67. CDの課題と解決　その2 生成Resourceのステータス
68. ArgoCD Applicationの構成 ❏ Delivery ❏ Service ❏ Generated
69. CDの課題 GitOps定義内の範囲: ❏ ArgoCD App ❏ KubeVela App(CR) GitOps定義外の範囲: ❏ Raw Resource ❏ KubeVela生成 Gitにないため、 Prune Statusになる
70. CDの課題 生成リソースのOutOfSync問題 ❏ ApplicationのStatusが OutOfSync に ❏ Prune対象とされるため、 削除されるリスク
71. CDの課題 ソリューションは二つ 1. Annotationを利用してPruneをスキップ 2. Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導
72. ソリューション 1 Annotationを利用してPruneをスキップ OutOfSyncの表記が変わらない PruneSkipped Statusになり、 Pruneされない 一部のリソースがOutOfSyncになって も、 全体のStatusがHealthy
73. ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 ❏ Tracking IDとは argocd.argoproj.io/tracking-id: <application-name>:<group>/<kind>:<namespace>/<name>
74. ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 ❏ Tracking IDとは ❏ 全てのリソースに一意的なTracking IDが存在 ❏ Tracking IDを間違って利用するリソースはNon SelfReferencing Resource
75. ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 1. Tracking IDを導入し、KubeVela Custom ResourceにTracking IDが生成 される 2. 生成ResourceにKubeVela Custom ResourceのAnnotationをコピー させる 3. 本来持つべきTracking IDと一致しない ため、NonSelfReferencingと判断される
76. ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 1. Tracking IDを導入し、KubeVela Custom ResourceにTracking IDが生成 される 2. 生成ResourceにKubeVela Custom ResourceのAnnotationをコピー させる 3. 本来持つべきTracking IDと一致しない ため、NonSelfReferencingと判断される
77. ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 1. Tracking IDを導入し、KubeVela Custom ResourceにTracking IDが生成 される 2. 生成ResourceにKubeVela Custom ResourceのAnnotationをコピー させる 3. 本来持つべきTracking IDと一致しない ため、NonSelfReferencingと判断される
78. ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 1. Tracking IDを導入し、KubeVela Custom ResourceにTracking IDが生成 される 2. 生成ResourceにKubeVela Custom ResourceのAnnotationをコピー させる 3. 本来持つべきTracking IDと一致しない ため、NonSelfReferencingと判断される Non Self-Referencing ResourceのStatusは Unknown UI表示のみ、Pruneされない
79. ソリューション 2 生成 App全体が OutOfSync
80. ソリューション 2 生成 見た目が 良くなった 運用者の 心理的負担を軽減する
81. ソリューション 2 推測 ❏ GitにないManifestに対するStatus Checkは、Application Controllerの負 荷増加と関係している可能性がある ❏ 意図的にUnknown Statusにすることで、負荷低減の可能性も考えられる 測るタイミングを逃してしまったので、知っている方がいれば教えてください
82. CDの課題と解決　その3 PostReleaseWorkflowの導入
83. CDの課題 PostSync問題 ❏ 当初設計: Sync後に何かを実行したい ❏ CDN Cache Purge ❏ Assets処理 ❏ ArgoCD Resource Hookでは解決できない ❏ ArgoCD Application単位、リソース単位ではない
84. CDの課題 GitOps定義内の範囲: ❏ ArgoCD App ❏ KubeVela App(CR) GitOps定義外の範囲: ❏ Raw Resource ❏ KubeVela生成 Resourcehook のトリガー単位 望ましい トリガー単位
85. ソリューション 検討したソリューション ❏ Argo Events・Argo Workflow (運用負荷が高い) ❏ ArgoCD Notification + Webhook Server (自由度が低い) ❏ KubeVela Application Workflow （バランス案、最終的に選定）
86. ソリューション Post Release Workflow
87. 構成図の変化
88. 従来のCD (Product) ❏ 手動実行 ❏ CDN操作 ❏ Schema操作
89. Post Release Workflow ❏ 手動実行 ❏ CDN操作 ❏ Schema操作 CDへ統合可能
90. ソリューション デメリット ❏ 複合条件が難しい ❏ 今後、人的リソース次第に、Argo Workflowの導入を検討中
91. まとめ
92. まとめ ❏ Ameba Platform CI/CDの全体像・細部まで紹介 ❏ CIとCDのパフォーマンスなどの改善 ❏ Terraform CIの高速化 ❏ ArgoCD/FluxCDのスケーリング・パラメータチューニング ❏ ArgoCD上生成リソースのステータスハンドリング ❏ ArgoCDとKubeVelaを活用したPost Release Workflow
93. 採用情報 26卒 本選考 中途採用(SRG)
94. ありがとうございました