Ameba CI/CD: Terraform and Argo CD Improvements

by Kumo Ishikawa

Slide 1

Slide 1 text

数万リソースのCI/CDを爆速に! Terraform・ArgoCD 改善の全記録石川　雲 Kumo Ishikawa

Slide 2

Slide 2 text

•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

Slide 3

Slide 3 text

本セッションの内容 Ameba PlatformにおけるCI/CDの進化と運用改善具体的には... ❏ CI/CDの構成と2022年以降に顕在化した課題の解決 ❏ Terraform / ArgoCD / FluxCDのパフォーマンス最適化事例 ❏ ArgoCD上の Resource Tracking と生成Resource の扱い ❏ CI/CD後の Workﬂow自動化に向けた検討

Slide 4

Slide 4 text

1.CI/CDの概要 2.CIの課題と解決 Terraformの処理最適化 3.CDの課題と解決その1 ArgoCD・FluxCDの運用改善その2 生成Resourceのステータスその3 Post Release Workﬂowの導入 4.まとめ

Slide 5

Slide 5 text

CI/CDの概要

Slide 6

Slide 6 text

背景 Amebaシステム刷新 ❏ 2019年からオンプレミスからAWS移行 ❏ 共通開発者基盤Ameba Platformの立ち上げ ❏ 共通開発者基盤の一部: CI/CD基盤

Slide 7

Slide 7 text

背景 Amebaシステム刷新 ❏ 2019年からオンプレミスからAWS移行 ❏ 共通開発者基盤Ameba Platformの立ち上げ ❏ 共通開発者基盤の一部: CI/CD基盤今日の補足資料は全てXで投稿する予定

Slide 8

Slide 8 text

CI/CD基盤の歴史当初設計の主な要件(2019) ❏ 認知負荷を軽減できる技術選定 ❏ GitOps原則「レポジトリ = 状態」 ❏ シンプルなCI/CDトリガーとイベント設計 ❏ CI/CDパイプラインのコード化 ❏ 専属担当者を不要とする設計(全員が担当者)

Slide 9

Slide 9 text

CI/CDの構成 3つの部分 ❏ Product ❏ Shared ❏ Platform

Slide 10

Slide 10 text

CI/CDの構成 - CI (Product) CI (Product) ❏ Image Push ❏ ECRへ ❏ Test ❏ Code管理 CD (Product) ❏ Platformへ ❏ 手動実行 ❏ CDN操作 ❏ Schema操作

Slide 11

Slide 11 text

CI/CDの構成 - CI (Shared) CI (Shared) ❏ Terraform ❏ CDN ❏ DNS ❏ AWS ❏ GHA利用

Slide 12

Slide 12 text

CI/CDの構成 - CD(Platform) CD(Platform) ❏ FluxCD ❏ Image Tag ❏ ArgoCD ❏ KubeVela ❏ CR -> Raw

Slide 13

Slide 13 text

KubeVela: アプリケーション定義モデル KubeVelaとは ❏ OAMモデルを使用して開発者のデプロイを簡素化し、拡張性を実現するツール ❏ 事前に定義したyamlで、必要なKuberentes Manifestを生成する

Slide 14

Slide 14 text

CI/CDの構成 - 責任分界点開発者(Product) ❏ Product Side ❏ Shared Side ❏ Terraform ❏ Manifest ❏ Platform Side ❏ ArgoCD 開発者(Platform) ❏ Shared Side ❏ Platform Side

Slide 15

Slide 15 text

CIの課題と解決

Slide 16

Slide 16 text

Terraformの構成(旧) Github Actions 構成 ❏ Plan/Apply全部On: Push ❏ Env Matrixで全環境を一括同時実行 ❏ 1環境に1Runner

Slide 17

Slide 17 text

Terraformの構成(旧) Github Actions 構成 ❏ Runnerで、モジュール単位ごとにマルチスレッドで実行 ❏ Runner内は1000行のシェルスクリプト

Slide 18

Slide 18 text

Terraformの構成(旧) tfstate State構成 ❏ S3 Backend利用 ❏ Workspace利用 ❏ Env名= Workspace名 ❏ マイクロサービス単位でState分け

Slide 19

Slide 19 text

Terraformの構成(旧) モジュール構成 ❏ Env/とModules/のクラシックな構成

Slide 20

Slide 20 text

Terraformの構成(旧) モジュール構成 ❏ マイクロサービス単位でモジュール分け ❏ Platformも単独のモジュール

Slide 21

Slide 21 text

Terraformの構成(旧) モジュール構成 ❏ 各マイクロサービスの各環境は独自のモジュールを利用 ❏ Env/以下はResource書かない

Slide 22

Slide 22 text

CIの課題 Platform利用者の声 ❏ PlanとApplyが非常に遅い ❏ 一部リソース(RDSなど)の適用が遅すぎる ❏ Applyの範囲が広すぎて、他のAppのDriftを適用してしまった

Slide 23

Slide 23 text

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 )

Slide 24

Slide 24 text

CIの課題原因 ❏ 一部AWS側APIが遅い ❏ RDS・EC2などの変更自体は時間かかる ❏ リソースの増加とStateの肥大化 ❏ 不適切なCI構成 2022 2024 Platform Module 300KB~400KB 1.1MB~1.2MB MicroService Module (avg) 50KB~60KB 200KB~300KB

Slide 25

Slide 25 text

CIの課題不適切なCI構成一つのRunnerでService数のスレッド数で並列実行 ⇨ Runner CPU利用率常に100%

Slide 26

Slide 26 text

CIの課題と解決: Terraformの処理最適化

Slide 27

Slide 27 text

Terraformの速度を上げる方法一般的な方法遅いCloud Resourceの分離 ❏ 極端に遅いCloud Resourceは個別のモジュール・Terraform以外で管理 tfstateの分割 ❏ 使いやすい程度で分割(~500KB) 並列処理数を上げる ❏ Runner性能とリソース間依存/順序によって効果がない場合がある Providerダウンロード時間を減らす ❏ ProviderのCache設定

Slide 28

Slide 28 text

Terraformの速度を上げる方法トリック Planファイルを利用してApply ❏ terraform apply -auto-approve xxx.tfplan ❏ Applyがとても速くなるが、tfplanの最新性を保つ必要がある Targetを指定する ❏ terraform apply -target="module.eks_addon" ❏ 単体ターゲットの定期実行に向いてる Refreshを無効化 ❏ terraform plan -refresh=false ❏ stateが大きい場合、ある程度時間を削減できる

Slide 29

Slide 29 text

Amebaでの対策単体モジュールの速度ではなく、CI全体の実行速度にフォーカス 1. 現行モジュール分けを維持し、変更があったモジュールだけ Terraform操作を行う 2. モジュール単位でRunnerを分けて同時実行 3. その上で、単体モジュールの実行速度を上げる

Slide 30

Slide 30 text

Amebaでの対策具体的には ❏ 一部Cloud ResourceをTerraformから廃止検討 ❏ EKS EC2 AutoScalingGroup、Karpenterへ移行 ❏ Auroraなどは検討中 ❏ Planファイルを利用してApply ❏ Runnerの上限まで並列処理数を上げる ❏ 大きいState: 10(Default) ❏ 小さいState: 30 ❏ Providerファイルのキャッシング

Slide 31

Slide 31 text

構成図の変化

Slide 32

Slide 32 text

Amebaでの対策

Slide 33

Slide 33 text

Amebaでの対策

Slide 34

Slide 34 text

Amebaでの対策差分発生した Moduleを対象にMatrix生成

Slide 35

Slide 35 text

Amebaでの対策 Applyも同じくMatrix生成

Slide 36

Slide 36 text

Amebaでの対策 Plan FileはArtifactで共有

Slide 37

Slide 37 text

ドリフトによる遅延一部のドリフトによってTerraformの実行が遅くなることもある ❏ EC2 Image ID (ASG) の自動変更 ❏ 適用すると10min~20minかかる ❏ 1週間に一度、このドリフトに遭遇する不幸が発生する

Slide 38

Slide 38 text

ドリフトによる遅延対策 ❏ ドリフトを検知する定期実行Healthcheck ❏ EC2 AMI IDの自動変更が発生したら、Applyまで自動的に適用する

Slide 39

Slide 39 text

改善結果実行時間: 最大9割削減、平均7割削減を達成

Slide 40

Slide 40 text

改善結果改善前(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割削減を達成

Slide 41

Slide 41 text

Terraformに関するまとめキーポイント ❏ 差分ベースで必要のModuleを絞る ❏ Runnerの並列化を利用する ❏ Runner単体の性能を最大限まで利用する

Slide 42

Slide 42 text

CDの課題と解決

Slide 43

Slide 43 text

CDの課題と解決　その1 ArgoCD・FluxCDの運用改善

Slide 44

Slide 44 text

CDの構成 CD(Platform) ❏ FluxCD ❏ Image Tag ❏ ArgoCD ❏ KubeVela ❏ CR -> Raw

Slide 45

Slide 45 text

CDの課題 ❏ ArgoCD: ❏ 同期が遅い ❏ ImagePush -> AutoSync -> Sync完了まで20~30分かかる ❏ 画面が遅い ❏ UI上、Filterをかけないと画面がフリーズして動かない ❏ FluxCD: ❏ FluxCDの動きが遅く、ImageTag更新が止まる

Slide 46

Slide 46 text

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で再起動

Slide 47

Slide 47 text

CDの課題原因: リソース総数の増加 ❏ リソース数合計: 10k(2022) -> 35k(2024) ❏ 1 MicroServiceのKubernetesリソース数 ❏ 平均: 100(2022) -> 500 (2024) ❏ 一部: 2000~3000

Slide 48

Slide 48 text

ArgoCDのパフォーマンス改善

Slide 49

Slide 49 text

ArgoCDのパフォーマンス改善最も効果的な方法 ❏ 各コンポーネントの水平スケーリング ❏ パフォーマンス改善に大きく貢献: ApplicationControllerとRepoServer ❏ MonoRepo対策 ❏ 意外と軽視されがち

Slide 50

Slide 50 text

ArgoCDのパフォーマンス改善水平スケーリング Application Controller ❏ Shardingの分割単位: クラスタ ❏ Shardへ自動・手動クラスタ指定 Repo Server・API Server ❏ スケールすることでパフォーマンス激的に改善 Redis ❏ 3つという前提 Dexなど ❏ スケールすると不整合が起きる

Slide 51

Slide 51 text

ArgoCDのパフォーマンス改善 MonoRepo問題とは ❏ MonoRepo運用 ❏ 複数のArgoCD Applicationが単一のGit Repoをポーリングしている ❏ 専用のManifest用Repo ❏ ArgoCD特性 ❏ 新しいコミットが同期されると、そのRepoに関する全てのキャッシュが再作成される ❏ MonoRepoの場合 ❏ デプロイ対象のManifestだけでなく、それ以外のManifestの変更があってもキャッシュが再作成される ❏ Repo内のAppが数十個以上の場合、パフォーマンスに大きな影響

Slide 52

Slide 52 text

ArgoCDのパフォーマンス改善 MonoRepo対策 ❏ Git Webhook ❏ Annotation: manifest-generate-paths

Slide 53

Slide 53 text

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]

Slide 54

Slide 54 text

ArgoCDのパフォーマンス改善パラメータチューニング Repo Server ❏ キャッシュ期間: ❏ reposerver.repo.cache.expiration ❏ ディスクI/O効率に影響、短すぎるとTimeout発生、適切に伸ばす ❏ 並列数: ❏ --parallelismlimit ❏ Helm/KustomizeなどのManifest生成効率に影響、適切に上げる

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

構成図の変化

Slide 57

Slide 57 text

各Core Component(2022) 2022: デフォルトHA構成運用 ❏ ApplicationController ❏ HAデフォルト1台 ❏ RepoServer ❏ HAデフォルト3台 ❏ Redis ❏ HAデフォルト3台

Slide 58

Slide 58 text

各Core Component(2024) 2024: 1 Shard = 1 Cluster

Slide 59

Slide 59 text

改善結果 ArgoCD Work Queueの処理待ち件数と処理時間激減

Slide 60

Slide 60 text

改善結果 ArgoCD Work Queueの処理待ち件数と処理時間激減処理待ち件数がほぼ0に処理時間が7割減

Slide 61

Slide 61 text

FluxCDのパフォーマンス改善

Slide 62

Slide 62 text

FluxCDのパフォーマンス改善水平スケーリング ❏ 全Controller対象 ❏ Flux Custom Resourceを各Shardへアサイン ❏ 手動アサインしかない Amebaでは ❏ リソース量が多いAppを新しいShardに指定

Slide 63

Slide 63 text

構成図の変化

Slide 64

Slide 64 text

構成図の変化 2022: デフォルト構成 ❏ Reﬂector ❏ ECRのタグを監視し、ImagePolicy通りに記録 ❏ Automation ❏ ImageUpdateAutomation設定通り、Manifestのタグを更新

Slide 65

Slide 65 text

構成図の変化 2024: リソース量が多いAppを新しいShardに指定

Slide 66

Slide 66 text

構成図の変化 2024: リソース量が多いAppを新しいShardに指定 FluxCDのダウンタイムが0になった

Slide 67

Slide 67 text

CDの課題と解決　その2 生成Resourceのステータス

Slide 68

Slide 68 text

ArgoCD Applicationの構成 ❏ Delivery ❏ Service ❏ Generated

Slide 69

Slide 69 text

CDの課題 GitOps定義内の範囲: ❏ ArgoCD App ❏ KubeVela App(CR) GitOps定義外の範囲: ❏ Raw Resource ❏ KubeVela生成 Gitにないため、 Prune Statusになる

Slide 70

Slide 70 text

CDの課題生成リソースのOutOfSync問題 ❏ ApplicationのStatusが OutOfSync に ❏ Prune対象とされるため、削除されるリスク

Slide 71

Slide 71 text

CDの課題ソリューションは二つ 1. Annotationを利用してPruneをスキップ 2. Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導

Slide 72

Slide 72 text

ソリューション 1 Annotationを利用してPruneをスキップ OutOfSyncの表記が変わらない PruneSkipped Statusになり、 Pruneされない一部のリソースがOutOfSyncになっても、全体のStatusがHealthy

Slide 73

Slide 73 text

ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 ❏ Tracking IDとは argocd.argoproj.io/tracking-id: :/:/

Slide 74

Slide 74 text

ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 ❏ Tracking IDとは ❏ 全てのリソースに一意的なTracking IDが存在 ❏ Tracking IDを間違って利用するリソースはNon SelfReferencing Resource

Slide 75

Slide 75 text

ソリューション 2 Tracking IDを導入して、意図的にNon SelfReferencing Resourceに誘導 1. Tracking IDを導入し、KubeVela Custom ResourceにTracking IDが生成される 2. 生成ResourceにKubeVela Custom ResourceのAnnotationをコピーさせる 3. 本来持つべきTracking IDと一致しないため、NonSelfReferencingと判断される

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

ソリューション 2 生成 App全体が OutOfSync

Slide 80

Slide 80 text

ソリューション 2 生成見た目が良くなった運用者の心理的負担を軽減する

Slide 81

Slide 81 text

ソリューション 2 推測 ❏ GitにないManifestに対するStatus Checkは、Application Controllerの負荷増加と関係している可能性がある ❏ 意図的にUnknown Statusにすることで、負荷低減の可能性も考えられる測るタイミングを逃してしまったので、知っている方がいれば教えてください

Slide 82

Slide 82 text

CDの課題と解決　その3 PostReleaseWorkﬂowの導入

Slide 83

Slide 83 text

CDの課題 PostSync問題 ❏ 当初設計: Sync後に何かを実行したい ❏ CDN Cache Purge ❏ Assets処理 ❏ ArgoCD Resource Hookでは解決できない ❏ ArgoCD Application単位、リソース単位ではない

Slide 84

Slide 84 text

CDの課題 GitOps定義内の範囲: ❏ ArgoCD App ❏ KubeVela App(CR) GitOps定義外の範囲: ❏ Raw Resource ❏ KubeVela生成 Resourcehook のトリガー単位望ましいトリガー単位

Slide 85

Slide 85 text

ソリューション検討したソリューション ❏ Argo Events・Argo Workflow (運用負荷が高い) ❏ ArgoCD Notification + Webhook Server (自由度が低い) ❏ KubeVela Application Workflow （バランス案、最終的に選定）

Slide 86

Slide 86 text

ソリューション Post Release Workﬂow

Slide 87

Slide 87 text

構成図の変化

Slide 88

Slide 88 text

従来のCD (Product) ❏ 手動実行 ❏ CDN操作 ❏ Schema操作

Slide 89

Slide 89 text

Post Release Workﬂow ❏ 手動実行 ❏ CDN操作 ❏ Schema操作 CDへ統合可能

Slide 90

Slide 90 text

ソリューションデメリット ❏ 複合条件が難しい ❏ 今後、人的リソース次第に、Argo Workﬂowの導入を検討中

Slide 91

Slide 91 text

まとめ

Slide 92

Slide 92 text

まとめ ❏ Ameba Platform CI/CDの全体像・細部まで紹介 ❏ CIとCDのパフォーマンスなどの改善 ❏ Terraform CIの高速化 ❏ ArgoCD/FluxCDのスケーリング・パラメータチューニング ❏ ArgoCD上生成リソースのステータスハンドリング ❏ ArgoCDとKubeVelaを活用したPost Release Workﬂow