Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング
Search
teru0x1
July 09, 2024
Technology
4
3.3k
マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング
Platform Engineering Kaigi 2024 Track A
teru0x1
July 09, 2024
Tweet
Share
More Decks by teru0x1
See All by teru0x1
ブラウザの外側でWasmを使おう
teru0x1
0
290
スタブサーバ自動生成ツール 〜負荷試験をもっと楽に〜
teru0x1
0
1.6k
バッチシステムをクラウドネイティブにするために考えたこと
teru0x1
17
8k
クラウド環境をFargateに 移行して得た知見
teru0x1
0
1.4k
Goと定数 DMM.go #3
teru0x1
0
2.5k
はてなインターン2020成果発表
teru0x1
0
1k
入門QUIC
teru0x1
0
470
【衝撃】Archlinuxをインストールした結果がヤバすぎた!
teru0x1
0
61
Docker講習会
teru0x1
0
120
Other Decks in Technology
See All in Technology
どちらを使う?GitHub or Azure DevOps Ver. 24H2
kkamegawa
0
720
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
110
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
240
[Ruby] Develop a Morse Code Learning Gem & Beep from Strings
oguressive
1
150
2024年にチャレンジしたことを振り返るぞ
mitchan
0
130
統計データで2024年の クラウド・インフラ動向を眺める
ysknsid25
2
840
OpenAIの蒸留機能(Model Distillation)を使用して運用中のLLMのコストを削減する取り組み
pharma_x_tech
4
550
Amazon VPC Lattice 最新アップデート紹介 - PrivateLink も似たようなアップデートあったけど違いとは
bigmuramura
0
190
祝!Iceberg祭開幕!re:Invent 2024データレイク関連アップデート10分総ざらい
kniino
2
260
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
2
270
Snykで始めるセキュリティ担当者とSREと開発者が楽になる脆弱性対応 / Getting started with Snyk Vulnerability Response
yamaguchitk333
2
180
Postman と API セキュリティ / Postman and API Security
yokawasa
0
200
Featured
See All Featured
Thoughts on Productivity
jonyablonski
67
4.4k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
BBQ
matthewcrist
85
9.4k
Facilitating Awesome Meetings
lara
50
6.1k
Scaling GitHub
holman
458
140k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Visualization
eitanlees
146
15k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.1k
Making the Leap to Tech Lead
cromwellryan
133
9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Transcript
マルチクラスタの認知負荷に立ち向かう! Ubieのプラットフォームエンジニアリング Platform Engineering kaigi 2024 Teruya Ono
2 あなたはUbieのアプリケーションエンジニアです。 ローカルで開発してきたマイクロサービスを 社内で運用しているインフラに乗せる日がやってきました。
3 1. ubieformのリポジトリを開く
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"] } ] } }
5 1. ubieformのリポジトリを開く 2. 右のようなファイルを作成 3. PRを投げてレビューが通ればマージする
6 1. ubieformのリポジトリを開く 2. 右のようなファイルを作成 3. PRを投げてレビューが通ればマージする 4. 別のリポジトリに複数ファイルが生成され 自動でマージされるので見守る
7 5. しばらく待つとSlackに通知が飛んでくる
8 5. しばらく待つとSlackに通知が飛んでくる 6. STGのデプロイが終わると承認が要求される
9 5. しばらく待つとSlackに通知が飛んでくる 6. STGのデプロイが終わると承認が要求される 7. 動作確認が済んだらリンク先の承認を押す
10 5. しばらく待つとSlackに通知が飛んでくる 6. STGのデプロイが終わると承認が要求される 7. 動作確認が済んだらリンク先の承認を押す 8. サービスが起動した!
11 さらにある日... genpakuに通信するサービスを開発・運用するチームから問い合わせがありました 「genpakuを呼び出した時、たまに500エラーが返ってくるから調査してほしい」
12 1. UbieHubというサイトを開く
13 1. UbieHubというサイトを開く 2. サービスリストの中にgenpakuがいつの間に か追加されてるので開く
14 3. Linksからapp logsのリンクを踏む app logs
15 3. Linksからapp logsのリンクを踏む 4. Cloud Loggingからエラーをチェック
16 3. Linksからapp logsのリンクを踏む 4. Cloud Loggingからエラーをチェック 5. Grafana Dashboardリンクからダッシュボードに
移動し、メトリクスもチェック Grafana Dashboard
17 3. Linksからapp logsのリンクを踏む 4. Cloud Loggingからエラーをチェック 5. Grafana Dashboardリンクからダッシュボードに
移動し、メトリクスもチェック 6. エラーの特定、無事バグの修正完了!
18 Today’s Topic 18 • この開発フローへ至るまでの経緯 • マルチクラスタ環境におけるプラットフォームの 課題 •
Ubieプラットフォームでの解決法 • プラットフォームエンジニアリングのポイントと始 め方
19 自己紹介 小野 輝也(Ono Teruya) • SRE/Platform Engineer@Ubie • Like
◦ Google Cloud ◦ Golang @teru0x1
20 Ubieについて
21 Introduction & Challenges
22 Ubieのアーキテクチャ • マイクロサービス & モジュラモノリス • 60以上のマイクロサービス • 日本と北米にデプロイ
• GKE & Istio上で稼働 ◦ 一部Cloud Run • 各環境ごとに ◦ 単一GCP Project, 単一GKEクラスタ (~2024/03)
23 Ubieの開発体制 • 50人ほど • 所有サービスの開発 • 所有サービスのインフラ構築・運用 • 所有サービスのインシデント
レスポンス • 5人 • プラットフォームの構築・運用 • 個別サービスのインフラ運用支援 • サービス構築の支援・レビュー • インシデントレスポンスの支援
24 Ubieの開発における課題 • プラットフォームの構築・運用 • 個別サービスのインフラ運用支援 • サービス構築の支援・レビュー • インシデントレスポンスの支援
• 扱う設定ファイルが多くて大変 ◦ 他サービスからコピペ、それでも大変 • 作成者によって品質・スタイルが違う ◦ 例: ラベルのフォーマットが違う • 問い合わせないと ◦ 設定ファイルの場所がわからない ◦ ログ、メトリクスの見方がわからない • 50人ほど • 所有サービスの開発 • 所有サービスのインフラ構築・運用 • 所有サービスのインシデント レスポンス
25 Ubieの開発における課題 • 個別のサービスの開発 • 個別のサービスのインフラ構築・運用 • 所有サービスのインシデント レスポンス •
多数作成されるファイルのレビューが大変 • 問い合わせで忙殺 • 5人 • プラットフォームの構築・運用 • 個別サービスのインフラ運用支援 • サービス構築の支援・レビュー • インシデントレスポンスの支援
26 マルチクラスタへ • マルチクラスタ・マルチプロジェクト構成への移行計画 ◦ 法令・ガイドラインへの準拠コスト低減 ◦ セキュリティ・プライバシーリスクの低減 ◦ 可用性の向上、インシデント時の影響範囲の縮小
27 マルチクラスタへ • マルチクラスタ・マルチプロジェクト構成への移行計画 ◦ 法令・ガイドラインへの準拠コスト低減 ◦ セキュリティ・プライバシーリスクの低減 ◦ 可用性の向上、インシデント時の影響範囲の縮小
どのクラスタにデプロイすべきだろう? クラスタ間通信はどう設定すれば良い? ログはどのプロジェクトで確認できる?
28 課題の整理 作成ファイル 多い サービス品質 まばら サービス品質 まばら クラスタ・メッシュ・ デプロイ構成
複雑 情報確認 大変 情報確認 さらに大変 作成ファイル さらに多い
29 2本の柱で対抗 ubieform サービステンプレートツール サービスに必要な設定(k8s manifest, デプロイ設定など)を生成 UbieHub サービスカタログ サービスに関する情報を集約
30 ubieform 30
31 課題の整理 作成ファイル 多い ベスプラ 不明瞭 情報確認 大変 情報確認 さらに大変
サービス品質 まばら クラスタ・メッシュ・デプ ロイ構成 複雑 作成ファイル さらに多い
32 ubieform
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
34 ubieform - Deploy Flow
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" …
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" }, … ] }
37 template toolを作る上で • そもそも必要か? ◦ GitHub Template, Helm, Kustomizeの活用
• 新ツール導入による認知負荷の上昇 ◦ ツール導入により下がる認知負荷 >> ツール導入により上がる認知負荷 にする • それなりの完成度になるまでチーム外へ展開しない ◦ 破壊的な変更を加える際の対応が大変
38 UbieHub 38
39 課題の整理 作成ファイル 多い ベスプラ 不明瞭 ベスプラ 不明瞭 クラスタ・メッシュ・デプロイ 構成
複雑 情報確認 大変 作成ファイル さらに多い 情報確認 さらに大変
40 UbieHub • BackStageで構築されたサービスカタログ • BackStage: IDP(Internal Developer Portal)を構築用のOSSフレームワーク •
UbieHubは今の所IDPと呼べるほど作り込まれ ていない ◦ IDPの1要素としてのサービスカタログ ◦ 関連するリンクが乗ってるだけ ◦ ただしこれで十分機能している
41 UbieHub - Architecture
42 Developer Portalを作る上で • 小さく始める ◦ 特に重要なもの ▪ サービスカタログ ▪
サービスに関連するリンク集 ◦ リンク集を作るだけでも大きな効果がある(後述) • フィードバックを得る ◦ アプリケーションエンジニアが見たい情報は本人が一番よく知ってる • サービスに関する情報は自動作成・更新
43 Result
44 結果 • マルチクラスタ移行にubieformを利用 ◦ ほぼ全てのサービスがubieformで管理され、UbieHubで確認できるようになった • 複雑度が上がった一方で、サービス構築の手間は減少した ◦ 「以前と比較してサービス構築の大変さは半減した」と答えた開発者が多かった
45 Key Takeaways 45
46 1. リンク集から始める 2. チームの所有物から始める 3. 協力者を探す 4. 移行に責任を持つ
47 1. リンク集から始める • なぜ重要か? ◦ アプリケーションエンジニアの行動が変わる ▪ ログ・メトリクスをみる習慣がつく ▪
インシデントレスポンスに参加しやすくなる → より自律分散なサービスの運用へ ◦ 作成にかかる手間が少ない
48
49 2. チームの所有物から始める • 新基盤・新ツールを試す時の心得 ◦ ドッグフーディング ◦ コミュニケーションコスト 低、失敗リスク
低 • プラットフォームチームで管理している社内サービスがあるはず ◦ 例えばUbieHubのようなサービスカタログ • 顧客のトラフィックを受けるものは後回し
50 3. 協力者を探す • 何らかの仕組みを横展開しよう、となった時 ◦ どのチームの人に最初にお願いするか? • こういう人が狙い目 ◦
SREやプラットフォームエンジニアの経験がある人 ◦ 社歴が長くて現行インフラに理解のある人 ◦ 仲のいい人 • 最初はバグがあったり、仕組みが変わったり、移行期固有の考慮点があったりと大変 ◦ コミュニケーションコストを下げるのが重要
51 4. 移行に責任を持つ • 「新基盤作ったよ!各チームのプロダクトは移行してね。移行ガイドもあるから後はよろしく!」 ◦ 新基盤が不便なら当然移行はされない ◦ 新基盤が素晴らしく便利でも移行される可能性は低い(と思う) ▪
なぜか? • 現基盤でも普通に動いているから • 事業上重要なエピックを追うのに時間とエネルギーを注ぎたいから • じゃあ誰がやるのか? ◦ 新基盤を作ったプラットフォームチーム(ただし、組織の規模による) • 移行後も重要 ◦ ドキュメント、説明会、オフィスアワー、問い合わせ窓口の整備 ▪ ユーザーフレンドリーなものを作れば負担を減らせる
52 1. リンク集から始める 2. チームの所有物から始める 3. 協力者を探す 4. 移行に責任を持つ
53