Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

❓ はてなぶろぐ記事: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

長谷川 広樹

June 28, 2024
Tweet

More Decks by 長谷川 広樹

Other Decks in Programming

Transcript

  1. どうも、一般男性 なんらかのエンジニア です (※各方面に配慮した結果) インフラ領域のお仕事 ・サービスメッシュ (Istio ← 推し❤) ・IaC

    (Kubernetes, Helm, Terraform) ・CICD (GitLab CI, ArgoCD) ・監視 (Prometheus, Fluentd, Grafana, Kiali) ・クラウド (AWS, ちょいGoogle Cloud) アプリ領域のお仕事 ・分散トレース (OpenTelemetry@gRPC, Go, Nginx) あー肩書きほしいわー せや! 一般男性でいくやでー 󰬿 弊社長 駄目です 󰘋 Findyさん えーっと 本当によろしい...? ワイ
  2. プラットフォームチームがマイクロサービス開発を支えている プロダクトチーム マイクロサービスアーキテクチャを開発する エンジニアチームからなる ⚫ 複数アプリチーム (マイクロサービス開発) ⚫ 単一SREチーム プラットフォームチーム

    アプリとインフラの両方の領域から 各プロダクトチームを横断的に支える ⚫ アプリエンジニア ⚫ SRE (プロダクト側のSREチームにも所属) 今回は、“CICD標準化” の取り組みの話
  3. 共有リポジトリの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
  4. 配布先リポジトリの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” に格下げ (任意)
  5. 各プロダクトでマイクロサービスのデプロイを自動化 とあるプロダクトのEKSクラスター マイクロサービスアーキテクチャの3領域 ⚫ マイクロサービス、BFF (バックエンド) ⚫ フロントエンドアプリ ⚫ SREツール

    デプロイのために操作するApplication App of Appsパターンの採用によって 各チームが独立してデプロイできる ⚫ バックエンドチーム用のApplication ⚫ フロントエンドチーム用のApplication ⚫ SREチーム用のApplication
  6. CDパイプラインが止まると、デプロイも止まってしまう ・異なるAZへPod分散 ・Balloon Podテクニック ・監視 ・不適切なNodeからの退避 ・Node Graceful Shutdown ・Nodeオートスケーリング

    ・AWS料金の自動最適化 今後も増える (現在16個) プロダクトの生産性 中長期的に安定的に支える 採用中のプラクティス など盛りだくさん
  7. 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数が非常に多くなる