Slide 1
Slide 1 text
マルチクラスタの認知負荷に立ち向かう！
Ubieのプラットフォームエンジニアリング
Platform Engineering kaigi 2024
Teruya Ono
Slide 2
Slide 2 text
2
あなたはUbieのアプリケーションエンジニアです。
ローカルで開発してきたマイクロサービスを
社内で運用しているインフラに乗せる日がやってきました。
Slide 3
Slide 3 text
3
1. ubieformのリポジトリを開く
Slide 4
Slide 4 text
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"]
}
]
}
}
Slide 5
Slide 5 text
5
1. ubieformのリポジトリを開く
2. 右のようなファイルを作成
3. PRを投げてレビューが通ればマージする
Slide 6
Slide 6 text
6
1. ubieformのリポジトリを開く
2. 右のようなファイルを作成
3. PRを投げてレビューが通ればマージする
4. 別のリポジトリに複数ファイルが生成され
自動でマージされるので見守る
Slide 7
Slide 7 text
7
5. しばらく待つとSlackに通知が飛んでくる
Slide 8
Slide 8 text
8
5. しばらく待つとSlackに通知が飛んでくる
6. STGのデプロイが終わると承認が要求される
Slide 9
Slide 9 text
9
5. しばらく待つとSlackに通知が飛んでくる
6. STGのデプロイが終わると承認が要求される
7. 動作確認が済んだらリンク先の承認を押す
Slide 10
Slide 10 text
10
5. しばらく待つとSlackに通知が飛んでくる
6. STGのデプロイが終わると承認が要求される
7. 動作確認が済んだらリンク先の承認を押す
8. サービスが起動した！
Slide 11
Slide 11 text
11
さらにある日...
genpakuに通信するサービスを開発・運用するチームから問い合わせがありました
「genpakuを呼び出した時、たまに500エラーが返ってくるから調査してほしい」
Slide 12
Slide 12 text
12
1. UbieHubというサイトを開く
Slide 13
Slide 13 text
13
1. UbieHubというサイトを開く
2. サービスリストの中にgenpakuがいつの間に
か追加されてるので開く
Slide 14
Slide 14 text
14
3. Linksからapp logsのリンクを踏む
app logs
Slide 15
Slide 15 text
15
3. Linksからapp logsのリンクを踏む
4. Cloud Loggingからエラーをチェック
Slide 16
Slide 16 text
16
3. Linksからapp logsのリンクを踏む
4. Cloud Loggingからエラーをチェック
5. Grafana Dashboardリンクからダッシュボードに
移動し、メトリクスもチェック
Grafana
Dashboard
Slide 17
Slide 17 text
17
3. Linksからapp logsのリンクを踏む
4. Cloud Loggingからエラーをチェック
5. Grafana Dashboardリンクからダッシュボードに
移動し、メトリクスもチェック
6. エラーの特定、無事バグの修正完了！
Slide 18
Slide 18 text
18
Today’s
Topic
18
● この開発フローへ至るまでの経緯
● マルチクラスタ環境におけるプラットフォームの
課題
● Ubieプラットフォームでの解決法
● プラットフォームエンジニアリングのポイントと始
め方
Slide 19
Slide 19 text
19
自己紹介
小野 輝也(Ono Teruya)
● SRE/Platform Engineer@Ubie
● Like
○ Google Cloud
○ Golang
@teru0x1
Slide 20
Slide 20 text
20
Ubieについて
Slide 21
Slide 21 text
21
Introduction
&
Challenges
Slide 22
Slide 22 text
22
Ubieのアーキテクチャ
● マイクロサービス & モジュラモノリス
● 60以上のマイクロサービス
● 日本と北米にデプロイ
● GKE & Istio上で稼働
○ 一部Cloud Run
● 各環境ごとに
○ 単一GCP Project, 単一GKEクラスタ
(~2024/03)
Slide 23
Slide 23 text
23
Ubieの開発体制
● 50人ほど
● 所有サービスの開発
● 所有サービスのインフラ構築・運用
● 所有サービスのインシデント
レスポンス
● 5人
● プラットフォームの構築・運用
● 個別サービスのインフラ運用支援
● サービス構築の支援・レビュー
● インシデントレスポンスの支援
Slide 24
Slide 24 text
24
Ubieの開発における課題
● プラットフォームの構築・運用
● 個別サービスのインフラ運用支援
● サービス構築の支援・レビュー
● インシデントレスポンスの支援
● 扱う設定ファイルが多くて大変
○ 他サービスからコピペ、それでも大変
● 作成者によって品質・スタイルが違う
○ 例: ラベルのフォーマットが違う
● 問い合わせないと
○ 設定ファイルの場所がわからない
○ ログ、メトリクスの見方がわからない
● 50人ほど
● 所有サービスの開発
● 所有サービスのインフラ構築・運用
● 所有サービスのインシデント
レスポンス
Slide 25
Slide 25 text
25
Ubieの開発における課題
● 個別のサービスの開発
● 個別のサービスのインフラ構築・運用
● 所有サービスのインシデント
レスポンス
● 多数作成されるファイルのレビューが大変
● 問い合わせで忙殺
● 5人
● プラットフォームの構築・運用
● 個別サービスのインフラ運用支援
● サービス構築の支援・レビュー
● インシデントレスポンスの支援
Slide 26
Slide 26 text
26
マルチクラスタへ
● マルチクラスタ・マルチプロジェクト構成への移行計画
○ 法令・ガイドラインへの準拠コスト低減
○ セキュリティ・プライバシーリスクの低減
○ 可用性の向上、インシデント時の影響範囲の縮小
Slide 27
Slide 27 text
27
マルチクラスタへ
● マルチクラスタ・マルチプロジェクト構成への移行計画
○ 法令・ガイドラインへの準拠コスト低減
○ セキュリティ・プライバシーリスクの低減
○ 可用性の向上、インシデント時の影響範囲の縮小
どのクラスタにデプロイすべきだろう？
クラスタ間通信はどう設定すれば良い？
ログはどのプロジェクトで確認できる？
Slide 28
Slide 28 text
28
課題の整理
作成ファイル
多い
サービス品質
まばら
サービス品質
まばら
クラスタ・メッシュ・
デプロイ構成
複雑
情報確認
大変
情報確認
さらに大変
作成ファイル
さらに多い
Slide 29
Slide 29 text
29
2本の柱で対抗
ubieform
サービステンプレートツール
サービスに必要な設定（k8s manifest,
デプロイ設定など）を生成
UbieHub
サービスカタログ
サービスに関する情報を集約
Slide 30
Slide 30 text
30
ubieform
30
Slide 31
Slide 31 text
31
課題の整理
作成ファイル
多い
ベスプラ
不明瞭
情報確認
大変
情報確認
さらに大変
サービス品質
まばら
クラスタ・メッシュ・デプ
ロイ構成
複雑
作成ファイル
さらに多い
Slide 32
Slide 32 text
32
ubieform
Slide 33
Slide 33 text
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
Slide 34
Slide 34 text
34
ubieform - Deploy Flow
Slide 35
Slide 35 text
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"
…
Slide 36
Slide 36 text
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"
},
…
]
}
Slide 37
Slide 37 text
37
template toolを作る上で
● そもそも必要か？
○ GitHub Template, Helm, Kustomizeの活用
● 新ツール導入による認知負荷の上昇
○ ツール導入により下がる認知負荷 >> ツール導入により上がる認知負荷 にする
● それなりの完成度になるまでチーム外へ展開しない
○ 破壊的な変更を加える際の対応が大変
Slide 38
Slide 38 text
38
UbieHub
38
Slide 39
Slide 39 text
39
課題の整理
作成ファイル
多い
ベスプラ
不明瞭
ベスプラ
不明瞭
クラスタ・メッシュ・デプロイ
構成
複雑
情報確認
大変
作成ファイル
さらに多い
情報確認
さらに大変
Slide 40
Slide 40 text
40
UbieHub
● BackStageで構築されたサービスカタログ
● BackStage: IDP(Internal Developer
Portal)を構築用のOSSフレームワーク
● UbieHubは今の所IDPと呼べるほど作り込まれ
ていない
○ IDPの1要素としてのサービスカタログ
○ 関連するリンクが乗ってるだけ
○ ただしこれで十分機能している
Slide 41
Slide 41 text
41
UbieHub - Architecture
Slide 42
Slide 42 text
42
Developer Portalを作る上で
● 小さく始める
○ 特に重要なもの
■ サービスカタログ
■ サービスに関連するリンク集
○ リンク集を作るだけでも大きな効果がある（後述）
● フィードバックを得る
○ アプリケーションエンジニアが見たい情報は本人が一番よく知ってる
● サービスに関する情報は自動作成・更新
Slide 43
Slide 43 text
43
Result
Slide 44
Slide 44 text
44
結果
● マルチクラスタ移行にubieformを利用
○ ほぼ全てのサービスがubieformで管理され、UbieHubで確認できるようになった
● 複雑度が上がった一方で、サービス構築の手間は減少した
○ 「以前と比較してサービス構築の大変さは半減した」と答えた開発者が多かった
Slide 45
Slide 45 text
45
Key
Takeaways
45
Slide 46
Slide 46 text
46
1. リンク集から始める
2. チームの所有物から始める
3. 協力者を探す
4. 移行に責任を持つ
Slide 47
Slide 47 text
47
1. リンク集から始める
● なぜ重要か？
○ アプリケーションエンジニアの行動が変わる
■ ログ・メトリクスをみる習慣がつく
■ インシデントレスポンスに参加しやすくなる
→ より自律分散なサービスの運用へ
○ 作成にかかる手間が少ない
Slide 48
Slide 48 text
48
Slide 49
Slide 49 text
49
2. チームの所有物から始める
● 新基盤・新ツールを試す時の心得
○ ドッグフーディング
○ コミュニケーションコスト 低、失敗リスク 低
● プラットフォームチームで管理している社内サービスがあるはず
○ 例えばUbieHubのようなサービスカタログ
● 顧客のトラフィックを受けるものは後回し
Slide 50
Slide 50 text
50
3. 協力者を探す
● 何らかの仕組みを横展開しよう、となった時
○ どのチームの人に最初にお願いするか？
● こういう人が狙い目
○ SREやプラットフォームエンジニアの経験がある人
○ 社歴が長くて現行インフラに理解のある人
○ 仲のいい人
● 最初はバグがあったり、仕組みが変わったり、移行期固有の考慮点があったりと大変
○ コミュニケーションコストを下げるのが重要
Slide 51
Slide 51 text
51
4. 移行に責任を持つ
● 「新基盤作ったよ！各チームのプロダクトは移行してね。移行ガイドもあるから後はよろしく！」
○ 新基盤が不便なら当然移行はされない
○ 新基盤が素晴らしく便利でも移行される可能性は低い（と思う）
■ なぜか？
● 現基盤でも普通に動いているから
● 事業上重要なエピックを追うのに時間とエネルギーを注ぎたいから
● じゃあ誰がやるのか？
○ 新基盤を作ったプラットフォームチーム（ただし、組織の規模による）
● 移行後も重要
○ ドキュメント、説明会、オフィスアワー、問い合わせ窓口の整備
■ ユーザーフレンドリーなものを作れば負担を減らせる
Slide 52
Slide 52 text
52
1. リンク集から始める
2. チームの所有物から始める
3. 協力者を探す
4. 移行に責任を持つ
Slide 53
Slide 53 text
53