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
290
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
Discovering AI Models
picardparis
4
3.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
0
160
コンポーネントテストの手法と その効果を考える
yotahada3
8
1.1k
1000万DL人を支えるiAEONアプリ:完全停止を防ぐ耐障害性の設計/iAEON app supporting 10 million users
aeonpeople
5
2.2k
サーバーレスAPIのパフォーマンステストとアプリの未来
nagix
5
2.9k
k6を活用した再現性・拡張性の高い負荷試験基盤の構築
biwashi
8
2.3k
AI前提のサービス運用ってなんだろう?
ryuichi1208
6
1.3k
横断組織として考える共通DBの課題解決 〜 桃園の誓いアーキテクチャ 〜 / Addressing Shared Database Challenges as Cross-Team: “Peach Garden Oath” Architecture
4geru
1
490
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
ham0215
4
720
GraphQLを安全に使うためにやっていること
hayashikengo
1
170
SRE改善サイクルはチームを超えて - ダッシュボードを眺める会の取り組み/SRE improvement cycle across teams
aeonpeople
1
160
Next.js のページ遷移を全力で止める
ypresto
12
4.2k
Featured
See All Featured
The Language of Interfaces
destraynor
154
24k
Fantastic passwords and where to find them - at NoRuKo
philnash
48
2.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
19k
VelocityConf: Rendering Performance Case Studies
addyosmani
322
23k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
620
A Philosophy of Restraint
colly
202
16k
[RailsConf 2023] Rails as a piece of cake
palkan
48
4.7k
Typedesign – Prime Four
hannesfritz
39
2.3k
Learning to Love Humans: Emotional Interface Design
aarron
271
40k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
Designing the Hi-DPI Web
ddemaree
278
34k
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