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
Plartform TeamのないPlatform Engineering
Search
yashirook
September 24, 2024
Technology
2
350
Plartform TeamのないPlatform Engineering
Platform Engineering Meetup #10の登壇資料です。
yashirook
September 24, 2024
Tweet
Share
More Decks by yashirook
See All by yashirook
Istioならできる!サービスを支える柔軟なトラフィック制御
yashiro
1
1.4k
Other Decks in Technology
See All in Technology
Graph Database と Generative AI の素敵な関係
oracle4engineer
PRO
16
2.8k
とある事業会社にとっての Kaggler の魅力
hakubishin3
7
1.2k
WSUSが非推奨に!? Windowsの更新管理を改めて勉強する!
ebibibi
0
390
ドキュメントとの付き合い方を考える
leveragestech
2
160
UE5の雑多なテク
ryuichikawano
0
450
SageMaker学習のツボ / The Key Points of Learning SageMaker
cmhiranofumio
0
230
YAPC::Hakodateの映像記録を支える技術
godan
4
390
Binary Hacks Rebooted 私選ハック集
nullpo_head
1
310
コード✕AIーソフトウェア開発者のための生成AI実践入門~
yuhattor
4
890
ADRを運用して3年経った僕らの現在地
onk
PRO
13
6k
Do you know “Environment Variables” ?
akimiya
0
110
組織デバイスのための効率的なアプリケーション更新戦略
kenchan0130
0
370
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Designing Experiences People Love
moore
138
23k
Web Components: a chance to create the future
zenorocha
310
42k
The Cult of Friendly URLs
andyhume
77
6k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Thoughts on Productivity
jonyablonski
67
4.2k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Debugging Ruby Performance
tmm1
73
12k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Transcript
Platform Teamのない Platform Engineering 2024/09/24 Platform Engineering Meetup #10 株式会社ユーザベース スピーダ事業部SRE
八代健太郎(@yashirook)
2 自己紹介 • 略歴 ◦ 2015~2018: 物理系の研究 ◦ 2018~2020: SIerでKubernetesをはじめとするCNCFプ
ロダクトの技術検証 ◦ 2020~現在:ユーザベースでSRE • 大阪在住 • Tech ◦ Kubernetes ◦ GCP • 激辛好き🌶🌶🌶
3 ユーザベースについて
4 開発組織とSREチーム 規模・在籍メンバー属性 ・ソフトウェアエンジニア ・SRE ・テストエンジニア ・機械学習エンジニア 約100名 開発チーム構成 各プロダクト・機能ごと
に開発チームを作り、 ペアプロ・TDDで開発 ストリームアラインドチーム (開発チーム) Aチーム (4~5名) Bチーム (4~5名) Cチーム (4~5名) and more…(計20チームほど) SREチーム 全てのプロダクト開発に 横断的に関わる 組織図上のPlatform Teamは存在しない
SREチームのVision/Mission/Strategy 5 5 Platform Engineeringと重なるモチベーション
6 スピーダ事業部における Platform Engineering | 01
7 スピーダ事業のPlatform オンプレ VM 開発チーム SRE Platform システム変更の インターフェース (CI/CD,
APIなど) Platform自体の運用・改善 インターフェースの 提供 変更のリリース
8 • サービス利用者と開発者をユーザーと想定している • 基本的にはサービス利用者への価値を優先する ◦ 基盤の信頼性向上 ◦ SLI/SLOの運用 •
とはいえ、開発チームの生産性を高める仕組みをつくることは重要 • 専任でないため必然的に限られたリソース の中で、開発者体験向上に取り組むことになる ◦ システム変更のインターフェース ◦ CI/CD 開発者体験向上 (Platform Engineering) への向き合い方 サービス利用者 開発者
9 具体例①: Kubernetesに対する権限管理 | 02
10 Kubernetesに対する権限管理の課題 過去開発チームは、クラスタの状態確認や運用を実施するにあたり、デプロイサーバーに SSHしてkubectlを実行 • 強い権限を持ち、誤操作に対する安全性や監査の観点でセキュリティリスクがある • 便利なCLIツールを利用しにくい デプロイサーバー 開発チーム
SSH kubectl –context cluster-a <some-command> • いつか事故るよなぁ • 便利なツールが色々ある んだけどなぁ
11 1つ目のリリース:ローカルからIAM認証で繋げるようにする ローカルからKubernetesにアクセスできるようにした • 本番はRO、開発はRWで最低限の安全性と監査を担保 ◦ 厳格な権限制御と個別チューニングは一旦実施しない ◦ Google WorkspaceのGroupに対して付与
• 便利kubectl pluginなどが使えて生産性向上の効果も見られた 開発チーム $ kubectx cluster-a $ kubectl <some-command> • ワークフローを大きく変えることなく 少し良くできたなぁ
12 フィードバックを得る 開発チームの理解が深まった 今より少し良くするためには? それをすべきか? (相談) ある運用が従来通りできなくて、 従来の方法で実行せざるを得ない シーンがあるから SREにオペレー
ションしてほしい(権限不足) (相談) コンテキスト違いの誤操作で 環境を壊してしまわないか心配 (権限過剰) (ペアプロ、ペアオペ) こんな運用で従来の方法を 使っちゃってるなぁ
13 2つ目のリリース:デフォルト権限の弱化と権限突破 個別チームに最適化するのではなく、安全に倒した上で権限突破の仕組みを用意する • デフォルトは事故を防ぐを第一に • 必要な運用の際は権限突破の仕組みを利用して自分たちで対応 開発チーム $ kubectl
rollout restart <deployment> 権限突破サービス 権限リクエスト 権限付与 監査ログの記録 JIT-access (OSS) ↓ Privileged Access Manager (GCP)
14 振り返ってみて気づいた大事にしていたこと • 段階的に改善すること ◦ 小さな価値(MVP)のリリースを繰り返す ◦ 色々やりたくなる気持ちを抑えて、早い段階で価値 を届け、フィードバックを得る ◦
フィードバックを得る前にワークフローを大きく変更し ない • 継続的にフィードバックを受け取ること ◦ 開発チームとのペアプロ(反応をリアルに感じられ る) ◦ 気軽に話にきてもらう、能動的にフィードバックを求 める 小さな価値 ユーザーの 理解 SRE チーム 文脈 補強 意思 決定 フィード バック
15 具体例②: Terraformによる パブリッククラウドの構成変更 | 03
16 パブリッククラウドの変更に関する課題 過去開発チームは、パブリッククラウドを変更するときには、SREに依頼することで実施し ていた • 開発チームでコントロールできない待ちが発生してしまう • クラウドリソースに関するオーナーシップを持ちにくい • SREチームにとってもToil的な対応が課題に
開発チーム 依頼 Terraform CI/CD
17 どうしますか? • 慣れたインターフェース( Kubernetesのマニフェスト等)で抽象化を用意する • 主なユースケースに対する Terraformのモジュールを用意する • Terraformを書くためのドキュメントや学習リソースを整備し、アナウンスして使ってもらう
• etc… 小さな価値 ユーザーの 理解 SRE チーム 文脈 補強 意思 決定 フィード バック
18 1つ目のリリース:積極的なペアプロ 開発チームとペアプロをするとこから始めた(形のないリリース) 開発チーム • 積極的にやろうとしてくれるな、計画の精度を高められて開発チームとし ても嬉しいのかも • HCLも割とシュッと書いてくれるな •
みんなが使えるように舵を切ってもいいかも Terraform CI/CD 依頼 ペアプロでやってみ ませんか? tfactionを利用
19 2つ目のリリース:開発チームだけで書けるようにする ペアプロを繰り返すうちに、典型的なユースケースではもう開発チームだけで書けるという 感覚を得てきた • プルリクエストによる変更の受け付けを開始 • マージはSREチームメンバーがチェックした上で実施 開発チーム Terraform
CI/CD PR レビュー・マージ CloudSQLのHA構成有効化 tfactionを利用
20 これからのリリース? • 認知負荷の軽減 ◦ 典型的なユースケースでは、開発チームが設定したい箇所が概ね見えているので、抽象化 ◦ 初めて/挑戦的なユースケースの抽象化はせず、ペアプロから始める • フローの安全・高速化
◦ ガードレール ◦ Stateを切り離し、開発チームに閉じた範囲ではマージも可能に
21 小規模にPlatform Engineeringを 実践することについて | 03
22 文脈を踏まえて意思決定する 領域のベストプラクティスは意識するが、何の価値をつくり、届けるかは文脈を意識する • エクストリームプログラミング(アジャイル) ◦ ペアプロで開発を進めることが基本 ◦ 少しずつ改善する •
マイクロサービス ◦ 担当領域に関わるコンポーネントのオーナーシップは開発チームが持つ • チーム間のコミュニケーション ◦ 口頭での同期的なコミュニケーションを優先する、すぐ直接話す
23 理想とのギャップは常にある • 自分たちがやっていることはPlatform Engineeringと言えるのだろうか? ◦ IDPやセルフサービスのAPIの構築例などに圧倒される • もっと生産性と、サービス品質を高くする抽象化を求めたくなる •
ワークフローへの適合と、ベストプラクティス準拠のトレードオフ ◦ ワークフローを尊重しながら、納得感あるフローの改善に導くこと
24 それでもあえて、Platform Engineeringだと言ってみる • プラットフォームをプロダクトのように扱う ◦ ユーザーに価値が届くこと ◦ ワークフローに適合すること ◦
ユーザー(開発者)から頻繁にフィードバックを得ながら、段階的に改善すること • 形あるプラットフォームにこだわらないこと ◦ ドキュメントもプラットフォーム 小規模なためできることは限られるが、小さな価値をしっかり届ける(使われるも のをつくる)。組織としてより投資する段階になったら、その経験は活きるはず。
25 まとめ • Platform Engineering専任でないSREチームが、Platform Engineeringを実践 ◦ ユーザー(開発者)のペインを理解し、小さく価値を届ける ◦ コミュニケーションとフィードバックの繰り返し
• 小規模でも始められるし、だからこそ始めやすい ◦ むしろ、実はやっていたことはPlatform Engineeringとも言えるかも?
26 補足資料 | Appendix
27 Terraformのペアプロをしてみて 小さな価値 組織における文脈 • 開発チームは外部依存を減らすことで、計画の精度が高まるんだなぁ • Terraformを書くというプロセスは、計画スキルと技術的興味などから受け入れら れるものなんだなぁ •
スキル的にも十分適用可能だな
28