Plartform TeamのないPlatform Engineering

Platform Engineering Meetup #10の登壇資料です。

Transcript

1. Platform Teamのない Platform Engineering 2024/09/24 Platform Engineering Meetup #10 株式会社ユーザベース　スピーダ事業部SRE 八代健太郎(@yashirook)
2. 2 自己紹介 • 略歴 ◦ 2015~2018: 物理系の研究 ◦ 2018~2020: SIerでKubernetesをはじめとするCNCFプ ロダクトの技術検証 ◦ 2020~現在：ユーザベースでSRE • 大阪在住 • Tech ◦ Kubernetes ◦ GCP • 激辛好き🌶🌶🌶
3. 3 ユーザベースについて
4. 4 開発組織とSREチーム 規模・在籍メンバー属性 ・ソフトウェアエンジニア ・SRE ・テストエンジニア ・機械学習エンジニア 約100名 開発チーム構成 各プロダクト・機能ごと に開発チームを作り、 ペアプロ・TDDで開発 ストリームアラインドチーム (開発チーム) Aチーム （4～5名） Bチーム （4～5名） Cチーム （4～5名） and more…（計20チームほど) SREチーム 全てのプロダクト開発に 横断的に関わる 組織図上のPlatform Teamは存在しない
5. SREチームのVision/Mission/Strategy 5 5 Platform Engineeringと重なるモチベーション
6. 6 スピーダ事業部における Platform Engineering | 01
7. 7 スピーダ事業のPlatform オンプレ VM 開発チーム SRE Platform システム変更の インターフェース （CI/CD, APIなど） Platform自体の運用・改善 インターフェースの 提供 変更のリリース
8. 8 • サービス利用者と開発者をユーザーと想定している • 基本的にはサービス利用者への価値を優先する ◦ 基盤の信頼性向上 ◦ SLI/SLOの運用 • とはいえ、開発チームの生産性を高める仕組みをつくることは重要 • 専任でないため必然的に限られたリソース の中で、開発者体験向上に取り組むことになる ◦ システム変更のインターフェース ◦ CI/CD 開発者体験向上 (Platform Engineering) への向き合い方 サービス利用者 開発者
9. 9 具体例①： Kubernetesに対する権限管理 | 02
10. 10 Kubernetesに対する権限管理の課題 過去開発チームは、クラスタの状態確認や運用を実施するにあたり、デプロイサーバーに SSHしてkubectlを実行 • 強い権限を持ち、誤操作に対する安全性や監査の観点でセキュリティリスクがある • 便利なCLIツールを利用しにくい デプロイサーバー 開発チーム SSH kubectl –context cluster-a <some-command> • いつか事故るよなぁ • 便利なツールが色々ある んだけどなぁ
11. 11 1つ目のリリース：ローカルからIAM認証で繋げるようにする ローカルからKubernetesにアクセスできるようにした • 本番はRO、開発はRWで最低限の安全性と監査を担保 ◦ 厳格な権限制御と個別チューニングは一旦実施しない ◦ Google WorkspaceのGroupに対して付与 • 便利kubectl pluginなどが使えて生産性向上の効果も見られた 開発チーム $ kubectx cluster-a $ kubectl <some-command> • ワークフローを大きく変えることなく 少し良くできたなぁ
12. 12 フィードバックを得る 開発チームの理解が深まった 今より少し良くするためには？ それをすべきか？ （相談） ある運用が従来通りできなくて、 従来の方法で実行せざるを得ない シーンがあるから SREにオペレー ションしてほしい（権限不足） （相談） コンテキスト違いの誤操作で 環境を壊してしまわないか心配 （権限過剰） （ペアプロ、ペアオペ） こんな運用で従来の方法を 使っちゃってるなぁ
13. 13 2つ目のリリース：デフォルト権限の弱化と権限突破 個別チームに最適化するのではなく、安全に倒した上で権限突破の仕組みを用意する • デフォルトは事故を防ぐを第一に • 必要な運用の際は権限突破の仕組みを利用して自分たちで対応 開発チーム $ kubectl rollout restart <deployment> 権限突破サービス 権限リクエスト 権限付与 監査ログの記録 JIT-access (OSS) ↓ Privileged Access Manager (GCP)
14. 14 振り返ってみて気づいた大事にしていたこと • 段階的に改善すること ◦ 小さな価値（MVP）のリリースを繰り返す ◦ 色々やりたくなる気持ちを抑えて、早い段階で価値 を届け、フィードバックを得る ◦ フィードバックを得る前にワークフローを大きく変更し ない • 継続的にフィードバックを受け取ること ◦ 開発チームとのペアプロ（反応をリアルに感じられ る） ◦ 気軽に話にきてもらう、能動的にフィードバックを求 める 小さな価値 ユーザーの 理解 SRE チーム 文脈 補強 意思 決定 フィード バック
15. 15 具体例②： Terraformによる パブリッククラウドの構成変更 | 03
16. 16 パブリッククラウドの変更に関する課題 過去開発チームは、パブリッククラウドを変更するときには、SREに依頼することで実施し ていた • 開発チームでコントロールできない待ちが発生してしまう • クラウドリソースに関するオーナーシップを持ちにくい • SREチームにとってもToil的な対応が課題に 開発チーム 依頼 Terraform CI/CD
17. 17 どうしますか？ • 慣れたインターフェース（ Kubernetesのマニフェスト等）で抽象化を用意する • 主なユースケースに対する Terraformのモジュールを用意する • Terraformを書くためのドキュメントや学習リソースを整備し、アナウンスして使ってもらう • etc… 小さな価値 ユーザーの 理解 SRE チーム 文脈 補強 意思 決定 フィード バック
18. 18 1つ目のリリース：積極的なペアプロ 開発チームとペアプロをするとこから始めた（形のないリリース） 開発チーム • 積極的にやろうとしてくれるな、計画の精度を高められて開発チームとし ても嬉しいのかも • HCLも割とシュッと書いてくれるな • みんなが使えるように舵を切ってもいいかも Terraform CI/CD 依頼 ペアプロでやってみ ませんか？ tfactionを利用
19. 19 2つ目のリリース：開発チームだけで書けるようにする ペアプロを繰り返すうちに、典型的なユースケースではもう開発チームだけで書けるという 感覚を得てきた • プルリクエストによる変更の受け付けを開始 • マージはSREチームメンバーがチェックした上で実施 開発チーム Terraform CI/CD PR レビュー・マージ CloudSQLのHA構成有効化 tfactionを利用
20. 20 これからのリリース？ • 認知負荷の軽減 ◦ 典型的なユースケースでは、開発チームが設定したい箇所が概ね見えているので、抽象化 ◦ 初めて/挑戦的なユースケースの抽象化はせず、ペアプロから始める • フローの安全・高速化 ◦ ガードレール ◦ Stateを切り離し、開発チームに閉じた範囲ではマージも可能に
21. 21 小規模にPlatform Engineeringを 実践することについて | 03
22. 22 文脈を踏まえて意思決定する 領域のベストプラクティスは意識するが、何の価値をつくり、届けるかは文脈を意識する • エクストリームプログラミング（アジャイル） ◦ ペアプロで開発を進めることが基本 ◦ 少しずつ改善する • マイクロサービス ◦ 担当領域に関わるコンポーネントのオーナーシップは開発チームが持つ • チーム間のコミュニケーション ◦ 口頭での同期的なコミュニケーションを優先する、すぐ直接話す
23. 23 理想とのギャップは常にある • 自分たちがやっていることはPlatform Engineeringと言えるのだろうか？ ◦ IDPやセルフサービスのAPIの構築例などに圧倒される • もっと生産性と、サービス品質を高くする抽象化を求めたくなる • ワークフローへの適合と、ベストプラクティス準拠のトレードオフ ◦ ワークフローを尊重しながら、納得感あるフローの改善に導くこと
24. 24 それでもあえて、Platform Engineeringだと言ってみる • プラットフォームをプロダクトのように扱う ◦ ユーザーに価値が届くこと ◦ ワークフローに適合すること ◦ ユーザー（開発者）から頻繁にフィードバックを得ながら、段階的に改善すること • 形あるプラットフォームにこだわらないこと ◦ ドキュメントもプラットフォーム 小規模なためできることは限られるが、小さな価値をしっかり届ける（使われるも のをつくる）。組織としてより投資する段階になったら、その経験は活きるはず。
25. 25 まとめ • Platform Engineering専任でないSREチームが、Platform Engineeringを実践 ◦ ユーザー（開発者）のペインを理解し、小さく価値を届ける ◦ コミュニケーションとフィードバックの繰り返し • 小規模でも始められるし、だからこそ始めやすい ◦ むしろ、実はやっていたことはPlatform Engineeringとも言えるかも？
26. 26 補足資料 | Appendix
27. 27 Terraformのペアプロをしてみて 小さな価値 組織における文脈 • 開発チームは外部依存を減らすことで、計画の精度が高まるんだなぁ • Terraformを書くというプロセスは、計画スキルと技術的興味などから受け入れら れるものなんだなぁ • スキル的にも十分適用可能だな