♾️ マルチプロダクトの組織でマイクロサービスアーキテクチャを支えるCICDプラットフォーム設計

"Findy開発生産性Conference" の発表資料です✊🏻

生産性を支えるためのプラットフォームエンジニアリング事例として、以下の３つの取り組みを紹介しました！

・プラットフォーム設計導入のために、横断的コミュニケーションが必要である
・プラットフォームエンジニアリングで、マルチプロダクトの生産性を支える
・プラットフォームエンジニアリングで、各マイクロサービスの生産性を支える

❓ はてなぶろぐ記事：https://hiroki-hasegawa.hatenablog.jp/entry/2024/07/01/120000

🐦 ツイート：https://x.com/Hiroki__IT/status/1806559579180011572

✍🏻 社内レポート：https://note.3-shake.com/n/n8efac1be167d

🗣️ 発表文字起こし：https://findy-code.io/engineer-lab/dev-productivity-con-2024-3shake

Transcript

1. 2024/06/28 Findy開発生産性Conference 株式会社スリーシェイク 長谷川広樹 @Hiroki_IT github.com/hiroki-it hiroki-hasegawa.hatenablog.jp はてな マルチプロダクトの巨大組織で マイクロサービス開発を支える CICDプラットフォーム設計
2. どうも、一般男性 なんらかのエンジニア です (※各方面に配慮した結果) インフラ領域のお仕事 ・サービスメッシュ (Istio ← 推し❤) ・IaC (Kubernetes, Helm, Terraform) ・CICD (GitLab CI, ArgoCD) ・監視 (Prometheus, Fluentd, Grafana, Kiali) ・クラウド (AWS, ちょいGoogle Cloud) アプリ領域のお仕事 ・分散トレース (OpenTelemetry＠gRPC, Go, Nginx) あー肩書きほしいわー せや！ 一般男性でいくやでー 󰬿 弊社長 駄目です 󰘋 Findyさん えーっと 本当によろしい...？ ワイ
3. プラットフォームエンジニアリングで 生産性を支える話をするよ󰺖
4. 国内売上高で最大規模のどデカいIT企業 (フィンテック部門) の事例 • 複数のチーム (計数百人以上) が独立したフィンテック系プロダクトを開発中 • プラットフォームチームが、プロダクトチームの開発を支えている
5. プラットフォームチームがマイクロサービス開発を支えている プロダクトチーム マイクロサービスアーキテクチャを開発する エンジニアチームからなる ⚫ 複数アプリチーム (マイクロサービス開発) ⚫ 単一SREチーム プラットフォームチーム アプリとインフラの両方の領域から 各プロダクトチームを横断的に支える ⚫ アプリエンジニア ⚫ SRE (プロダクト側のSREチームにも所属) 今回は、“CICD標準化” の取り組みの話
6. マルチプロダクトの巨大組織には 生産性の課題があるのよ󰣹
7. マルチプロダクト、やっぱつれぇわ… 各プロダクトチーム間にはコミュニケーションの溝があり 標準化されていない知見がたくさんある 各プロダクトチームで車輪の再発明が起こるため 組織全体での生産性が低い
8. マイクロサービスアーキテクチャでも 生産性の課題があるのよ󰣹
9. ポリレポ、やっぱつれぇわ… ポリレポでは、マイクロサービスの数だけ運用する設定ファイルが増える レビューの負荷が高くなるため、プロダクトチームでの生産性が低い
10. まずはコミュニケーションで 課題を解決していき󰜭
11. プラットフォーム設計導入のためにステークホルダーを巻き込んでいく ステークホルダーと横断的にコミュニケーションし、よりよく設計導入できる ( “コミュニケーション” もプラットフォームエンジニアリングの要素だよ！)
12. 次は技術で 課題を解決していき󰜭
13. CICDパイプラインの全体像 マイクロサービス アプリリポジトリ CIパイプライン マイクロサービス K8sリポジトリ CIパイプライン (今回ちょい紹介) CDパイプライン (今回ちょい紹介)
14. K8sリポジトリのCIパイプラインの詳細 お披露目しちゃう󰗨
15. 各KubernetesリポジトリのCIパイプラインで静的解析を自動化 Helmチャート ✅ Helmチャート構造の誤り マニフェスト ✅ 文法の誤り ✅ 非推奨API Version ❌ ベストプラクティス違反 ✅ 脆弱性 gitlab-commentで レビューコメントとして通知
16. gitlab-commentでレビューを自動化 GitLab CI上で実行した静的解析の処理結果を整形し、レビューコメントととして通知 (GitHubの場合、例えば “github-comment” を使ってね！) 参考: github.com/yuyaban/gitlab-comment
17. CIパイプラインを各マイクロサービスに横断的に提供 GitLab CIの “include” 機能で、任意でルールを無効化できるCIパイプラインを提供 (GitHub Actionsの場合、例えば “reusable workflow” 機能を使ってね！) 参考: docs.gitlab.com/ee/ci/yaml/includes.html
18. 各マイクロサービスに提供するCIファイル こんな実装になってるよ󰡅
19. 共有リポジトリのCIファイル (例: ベストプラクティス違反テストのpolaris) # 先に、gitlab-comment のインストールや Helm チャートの展開を実施 .polaris: stage: test image: quay.io/fairwinds/polaris:master variables: MISSING_POD_DISRUPTION_BUDGET: danger # ルールのデフォルトの重要度を設定 script: - | cat << EOF > polaris-config.yaml checks: # Workloadの “PodDisruptionBudget” の作成し忘れルール missingPodDisruptionBudget: ${MISSING_POD_DISRUPTION_BUDGET} # 重要度を各リポジトリで上書き可能 (任意) EOF - | # polarisの実行時に、重要度が “danger” 以上のルールを検証 ./gitlab-comment exec -k test \ -- polaris audit --config polaris-config.yaml --audit-path manifest.yaml --severity danger
20. 配布先リポジトリのCIファイル (例: ベストプラクティス違反テストのpolaris) GitLab CIテンプレートで、各マイクロサービスに提供する include: - project: shared-repository # 共有リポジトリを指定 ref: master file: - shared-ci.yml # CIファイルをincludeする stages: - build - test # 先に、gitlab-commentのインストールやHelmチャートの展開を実施 # マニフェストのベストプラクティス違反を検証 polaris: extends: .polaris stage: test variables: missingPodDisruptionBudget: warning # 無効化したいルールの重要度を “danger” から “warning” に格下げ (任意)
21. CDパイプラインの詳細 お披露目しちゃう󰗨
22. ArgoCDを各プロダクトに横断的に提供 (発表時点でプロダクトが16個) SREの仕事 所属プロダクトチームの ArgoCDをデプロイ マイクロサービス開発者の仕事 SRE管理のArgoCDから マイクロサービスをデプロイ Namespacedスコープモードで ArgoCDをプロダクト単位に分離し マルチプロダクトの横断を実装 参考: hiroki-hasegawa.hatenablog.jp/entry/2023/08/18/110646
23. 各プロダクトでマイクロサービスのデプロイを自動化 とあるプロダクトのEKSクラスター マイクロサービスアーキテクチャの３領域 ⚫ マイクロサービス、BFF (バックエンド) ⚫ フロントエンドアプリ ⚫ SREツール デプロイのために操作するApplication App of Appsパターンの採用によって 各チームが独立してデプロイできる ⚫ バックエンドチーム用のApplication ⚫ フロントエンドチーム用のApplication ⚫ SREチーム用のApplication
24. 　　俺は止まんねぇからよ... 　　　　　　止まるんじゃねぇぞ...
25. CDパイプラインが止まると、デプロイも止まってしまう ・異なるAZへPod分散 ・Balloon Podテクニック ・監視 ・不適切なNodeからの退避 ・Node Graceful Shutdown ・Nodeオートスケーリング ・AWS料金の自動最適化 今後も増える (現在16個) プロダクトの生産性 中長期的に安定的に支える 採用中のプラクティス など盛りだくさん
26. application-controllerのレプリカ数を “N+1” にして可用性を高める application-controllerは レプリカ当たり 400 個まで ApplicationをReconcile可 App数 1~400 個 なら N+1 でレプリカ数は 2 個 参考: https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/#argocd-application-controller App数 401~800 個 なら N+1 でレプリカ数は 3 個 プロダクトによっては 実行環境が多く App数が非常に多くなる
27. まとめ
28. プラットフォーム設計導入のために横断的コミュニケーションが必要 　ステークホルダーとの 横断的コミュニケーション 必要不可欠 知見を標準化できる プラットフォームを 設計導入したい
29. プラットフォームエンジニアリングでマルチプロダクトの生産性を支える プラットフォームが 各プロダクトチーム間の 知見を標準化 マルチプロダクト課題の 車輪の再発明を防ぎ 生産性を支える
30. プラットフォームエンジニアリングで各マイクロサービスの生産性を支える 各マイクロサービスに 任意でルールを無効化できる CIパイプラインを横断的提供 ポリレポ課題の レビューの負荷を減らして 生産性を支える
31. 最後に 僕の背中パネルに拍手をくださった方々、勇気をもらいました