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

マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング

teru0x1
July 09, 2024

マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング

Platform Engineering Kaigi 2024 Track A

teru0x1

July 09, 2024
Tweet

More Decks by teru0x1

Other Decks in Technology

Transcript

  1. 4 1. ubieformのリポジトリを開く 2. 右のようなファイルを作成 name: "genpaku" env: ["qa", "stg",

    "prd"] segment: "cpp" service_config: { manifest: { app: { main_container: { image_path: "asia-northeast1-docker.pkg.dev/ubie/genpaku" image_tag: "release-20240418-1" } } deploy: { pipelines: [ { envs: ["qa"] }, { envs: ["stg", "prd"] } ] } }
  2. 18 Today’s Topic 18 • この開発フローへ至るまでの経緯 • マルチクラスタ環境におけるプラットフォームの 課題 •

    Ubieプラットフォームでの解決法 • プラットフォームエンジニアリングのポイントと始 め方
  3. 22 Ubieのアーキテクチャ • マイクロサービス & モジュラモノリス • 60以上のマイクロサービス • 日本と北米にデプロイ

    • GKE & Istio上で稼働 ◦ 一部Cloud Run • 各環境ごとに ◦ 単一GCP Project, 単一GKEクラスタ (~2024/03)
  4. 23 Ubieの開発体制 • 50人ほど • 所有サービスの開発 • 所有サービスのインフラ構築・運用 • 所有サービスのインシデント

    レスポンス • 5人 • プラットフォームの構築・運用 • 個別サービスのインフラ運用支援 • サービス構築の支援・レビュー • インシデントレスポンスの支援
  5. 24 Ubieの開発における課題 • プラットフォームの構築・運用 • 個別サービスのインフラ運用支援 • サービス構築の支援・レビュー • インシデントレスポンスの支援

    • 扱う設定ファイルが多くて大変 ◦ 他サービスからコピペ、それでも大変 • 作成者によって品質・スタイルが違う ◦ 例: ラベルのフォーマットが違う • 問い合わせないと ◦ 設定ファイルの場所がわからない ◦ ログ、メトリクスの見方がわからない • 50人ほど • 所有サービスの開発 • 所有サービスのインフラ構築・運用 • 所有サービスのインシデント レスポンス
  6. 25 Ubieの開発における課題 • 個別のサービスの開発 • 個別のサービスのインフラ構築・運用 • 所有サービスのインシデント レスポンス •

    多数作成されるファイルのレビューが大変 • 問い合わせで忙殺 • 5人 • プラットフォームの構築・運用 • 個別サービスのインフラ運用支援 • サービス構築の支援・レビュー • インシデントレスポンスの支援
  7. 31 課題の整理 作成ファイル 多い ベスプラ 不明瞭 情報確認 大変 情報確認 さらに大変

    サービス品質 まばら クラスタ・メッシュ・デプ ロイ構成 複雑 作成ファイル さらに多い
  8. 33 生成されるファイル • Kubernetes ◦ Namespace ◦ Deployment ◦ Service

    ◦ ConfigMap ◦ Virtual Service ◦ Destination Rule ◦ …. • Google Cloud ◦ Cloud Deploy ▪ Delivery Pipeline ▪ Target ▪ Skaffold ◦ Cloud Run Config ◦ Cloud Workflow ◦ etc.. • Others ◦ GHA config ◦ BackStage config
  9. 35 ubieform - Input • CUE言語 ◦ 制約ベースの設定言語 ◦ スキーマにより構造化

    データの高度な検証が 容易 • ubieformでの利用 ◦ 利用者にCUEであること を意識させない ◦ Better JSONとして 利用 name: "genpaku" env: ["qa", "stg", "prd"] segment: "cpp" service_config: { manifest: { app: { main_container: { image_path: "example-docker.pkg.dev/ubie/genpaku" image_tag: "release-20240418-1" …
  10. 36 ubieform - Input • Single Source of Truth として機能

    ◦ 基本このファイルだけ扱う ◦ 生成時だけでなく、変更時も これを編集 • 大部分のフィールドはoptional ◦ 指定しない限り内部で生成 ▪ namespace name ▪ pipeline name ▪ PDB name: "genpaku" env: ["qa", "stg", "prd"] segment: "cpp" service_config: { manifest: { app: { main_container: { image_path: "asia-northeast1-docker.pkg.dev/ubie/genpaku" image_tag: "release-20240418-1" secret_names: ["genpaku-secret"] } } secrets: [ { name: "genpaku-secret" values: [ { key: "AUTH_GOOGLE_CLIENT_ID" value: "genpaku_AUTH_GOOGLE_CLIENT_ID" }, … ] }
  11. 37 template toolを作る上で • そもそも必要か? ◦ GitHub Template, Helm, Kustomizeの活用

    • 新ツール導入による認知負荷の上昇 ◦ ツール導入により下がる認知負荷 >> ツール導入により上がる認知負荷 にする • それなりの完成度になるまでチーム外へ展開しない ◦ 破壊的な変更を加える際の対応が大変
  12. 40 UbieHub • BackStageで構築されたサービスカタログ • BackStage: IDP(Internal Developer Portal)を構築用のOSSフレームワーク •

    UbieHubは今の所IDPと呼べるほど作り込まれ ていない ◦ IDPの1要素としてのサービスカタログ ◦ 関連するリンクが乗ってるだけ ◦ ただしこれで十分機能している
  13. 42 Developer Portalを作る上で • 小さく始める ◦ 特に重要なもの ▪ サービスカタログ ▪

    サービスに関連するリンク集 ◦ リンク集を作るだけでも大きな効果がある(後述) • フィードバックを得る ◦ アプリケーションエンジニアが見たい情報は本人が一番よく知ってる • サービスに関する情報は自動作成・更新
  14. 47 1. リンク集から始める • なぜ重要か? ◦ アプリケーションエンジニアの行動が変わる ▪ ログ・メトリクスをみる習慣がつく ▪

    インシデントレスポンスに参加しやすくなる → より自律分散なサービスの運用へ ◦ 作成にかかる手間が少ない
  15. 48

  16. 49 2. チームの所有物から始める • 新基盤・新ツールを試す時の心得 ◦ ドッグフーディング ◦ コミュニケーションコスト 低、失敗リスク

    低 • プラットフォームチームで管理している社内サービスがあるはず ◦ 例えばUbieHubのようなサービスカタログ • 顧客のトラフィックを受けるものは後回し
  17. 50 3. 協力者を探す • 何らかの仕組みを横展開しよう、となった時 ◦ どのチームの人に最初にお願いするか? • こういう人が狙い目 ◦

    SREやプラットフォームエンジニアの経験がある人 ◦ 社歴が長くて現行インフラに理解のある人 ◦ 仲のいい人 • 最初はバグがあったり、仕組みが変わったり、移行期固有の考慮点があったりと大変 ◦ コミュニケーションコストを下げるのが重要
  18. 51 4. 移行に責任を持つ • 「新基盤作ったよ!各チームのプロダクトは移行してね。移行ガイドもあるから後はよろしく!」 ◦ 新基盤が不便なら当然移行はされない ◦ 新基盤が素晴らしく便利でも移行される可能性は低い(と思う) ▪

    なぜか? • 現基盤でも普通に動いているから • 事業上重要なエピックを追うのに時間とエネルギーを注ぎたいから • じゃあ誰がやるのか? ◦ 新基盤を作ったプラットフォームチーム(ただし、組織の規模による) • 移行後も重要 ◦ ドキュメント、説明会、オフィスアワー、問い合わせ窓口の整備 ▪ ユーザーフレンドリーなものを作れば負担を減らせる
  19. 53