2024/06/28 Findy開発生産性Conference 株式会社スリーシェイク 長谷川広樹 @Hiroki_IT github.com/hiroki-it hiroki-hasegawa.hatenablog.jp はてな マルチプロダクトの巨大組織で マイクロサービス開発を支える CICDプラットフォーム設計

どうも、一般男性 なんらかのエンジニア です (※各方面に配慮した結果) インフラ領域のお仕事 ・サービスメッシュ (Istio ← 推し❤) ・IaC (Kubernetes, Helm, Terraform) ・CICD (GitLab CI, ArgoCD) ・監視 (Prometheus, Fluentd, Grafana, Kiali) ・クラウド (AWS, ちょいGoogle Cloud) アプリ領域のお仕事 ・分散トレース (OpenTelemetry＠gRPC, Go, Nginx) あー肩書きほしいわー せや！ 一般男性でいくやでー 󰬿 弊社長 駄目です 󰘋 Findyさん えーっと 本当によろしい...？ ワイ

プラットフォームエンジニアリングで 生産性を支える話をするよ󰺖

国内売上高で最大規模のどデカいIT企業 (フィンテック部門) の事例 ● 複数のチーム (計数百人以上) が独立したフィンテック系プロダクトを開発中 ● プラットフォームチームが、プロダクトチームの開発を支えている

プラットフォームチームがマイクロサービス開発を支えている プロダクトチーム マイクロサービスアーキテクチャを開発する エンジニアチームからなる ⚫ 複数アプリチーム (マイクロサービス開発) ⚫ 単一SREチーム プラットフォームチーム アプリとインフラの両方の領域から 各プロダクトチームを横断的に支える ⚫ アプリエンジニア ⚫ SRE (プロダクト側のSREチームにも所属) 今回は、“CICD標準化” の取り組みの話

マルチプロダクトの巨大組織には 生産性の課題があるのよ󰣹

マルチプロダクト、やっぱつれぇわ… 各プロダクトチーム間にはコミュニケーションの溝があり 標準化されていない知見がたくさんある 各プロダクトチームで車輪の再発明が起こるため 組織全体での生産性が低い

マイクロサービスアーキテクチャでも 生産性の課題があるのよ󰣹

ポリレポ、やっぱつれぇわ… ポリレポでは、マイクロサービスの数だけ運用する設定ファイルが増える レビューの負荷が高くなるため、プロダクトチームでの生産性が低い

まずはコミュニケーションで 課題を解決していき󰜭

プラットフォーム設計導入のためにステークホルダーを巻き込んでいく ステークホルダーと横断的にコミュニケーションし、よりよく設計導入できる ( “コミュニケーション” もプラットフォームエンジニアリングの要素だよ！)

次は技術で 課題を解決していき󰜭

CICDパイプラインの全体像 マイクロサービス アプリリポジトリ CIパイプライン マイクロサービス K8sリポジトリ CIパイプライン (今回ちょい紹介) CDパイプライン (今回ちょい紹介)

K8sリポジトリのCIパイプラインの詳細 お披露目しちゃう󰗨

各KubernetesリポジトリのCIパイプラインで静的解析を自動化 Helmチャート ✅ Helmチャート構造の誤り マニフェスト ✅ 文法の誤り ✅ 非推奨API Version ❌ ベストプラクティス違反 ✅ 脆弱性 gitlab-commentで レビューコメントとして通知

gitlab-commentでレビューを自動化 GitLab CI上で実行した静的解析の処理結果を整形し、レビューコメントととして通知 (GitHubの場合、例えば “github-comment” を使ってね！) 参考: github.com/yuyaban/gitlab-comment

CIパイプラインを各マイクロサービスに横断的に提供 GitLab CIの “include” 機能で、任意でルールを無効化できるCIパイプラインを提供 (GitHub Actionsの場合、例えば “reusable workflow” 機能を使ってね！) 参考: docs.gitlab.com/ee/ci/yaml/includes.html

各マイクロサービスに提供するCIファイル こんな実装になってるよ󰡅

共有リポジトリの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

配布先リポジトリの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” に格下げ (任意)

CDパイプラインの詳細 お披露目しちゃう󰗨

ArgoCDを各プロダクトに横断的に提供 (発表時点でプロダクトが16個) SREの仕事 所属プロダクトチームの ArgoCDをデプロイ マイクロサービス開発者の仕事 SRE管理のArgoCDから マイクロサービスをデプロイ Namespacedスコープモードで ArgoCDをプロダクト単位に分離し マルチプロダクトの横断を実装 参考: hiroki-hasegawa.hatenablog.jp/entry/2023/08/18/110646

各プロダクトでマイクロサービスのデプロイを自動化 とあるプロダクトのEKSクラスター マイクロサービスアーキテクチャの３領域 ⚫ マイクロサービス、BFF (バックエンド) ⚫ フロントエンドアプリ ⚫ SREツール デプロイのために操作するApplication App of Appsパターンの採用によって 各チームが独立してデプロイできる ⚫ バックエンドチーム用のApplication ⚫ フロントエンドチーム用のApplication ⚫ SREチーム用のApplication

　　俺は止まんねぇからよ... 　　　　　　止まるんじゃねぇぞ...

CDパイプラインが止まると、デプロイも止まってしまう ・異なるAZへPod分散 ・Balloon Podテクニック ・監視 ・不適切なNodeからの退避 ・Node Graceful Shutdown ・Nodeオートスケーリング ・AWS料金の自動最適化 今後も増える (現在16個) プロダクトの生産性 中長期的に安定的に支える 採用中のプラクティス など盛りだくさん

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数が非常に多くなる

まとめ

プラットフォーム設計導入のために横断的コミュニケーションが必要 　ステークホルダーとの 横断的コミュニケーション 必要不可欠 知見を標準化できる プラットフォームを 設計導入したい

プラットフォームエンジニアリングでマルチプロダクトの生産性を支える プラットフォームが 各プロダクトチーム間の 知見を標準化 マルチプロダクト課題の 車輪の再発明を防ぎ 生産性を支える

プラットフォームエンジニアリングで各マイクロサービスの生産性を支える 各マイクロサービスに 任意でルールを無効化できる CIパイプラインを横断的提供 ポリレポ課題の レビューの負荷を減らして 生産性を支える

最後に 僕の背中パネルに拍手をくださった方々、勇気をもらいました