Plartform TeamのないPlatform Engineering

Slide 1

Slide 1 text

Platform Teamのない Platform Engineering 2024/09/24 Platform Engineering Meetup #10 株式会社ユーザベース　スピーダ事業部SRE 八代健太郎(@yashirook)

Slide 2

Slide 2 text

2 自己紹介 ● 略歴 ○ 2015~2018: 物理系の研究 ○ 2018~2020: SIerでKubernetesをはじめとするCNCFプロダクトの技術検証 ○ 2020~現在：ユーザベースでSRE ● 大阪在住 ● Tech ○ Kubernetes ○ GCP ● 激辛好き🌶🌶🌶

Slide 3

Slide 3 text

3 ユーザベースについて

Slide 4

Slide 4 text

4 開発組織とSREチーム規模・在籍メンバー属性・ソフトウェアエンジニア・SRE ・テストエンジニア・機械学習エンジニア約100名開発チーム構成各プロダクト・機能ごとに開発チームを作り、ペアプロ・TDDで開発ストリームアラインドチーム (開発チーム) Aチーム（4～5名） Bチーム（4～5名） Cチーム（4～5名） and more…（計20チームほど) SREチーム全てのプロダクト開発に横断的に関わる組織図上のPlatform Teamは存在しない

Slide 5

Slide 5 text

SREチームのVision/Mission/Strategy 5 5 Platform Engineeringと重なるモチベーション

Slide 6

Slide 6 text

6 スピーダ事業部における Platform Engineering | 01

Slide 7

Slide 7 text

7 スピーダ事業のPlatform オンプレ VM 開発チーム SRE Platform システム変更のインターフェース（CI/CD, APIなど） Platform自体の運用・改善インターフェースの提供変更のリリース

Slide 8

Slide 8 text

8 ● サービス利用者と開発者をユーザーと想定している ● 基本的にはサービス利用者への価値を優先する ○ 基盤の信頼性向上 ○ SLI/SLOの運用 ● とはいえ、開発チームの生産性を高める仕組みをつくることは重要 ● 専任でないため必然的に限られたリソースの中で、開発者体験向上に取り組むことになる ○ システム変更のインターフェース ○ CI/CD 開発者体験向上 (Platform Engineering) への向き合い方サービス利用者開発者

Slide 9

Slide 9 text

9 具体例①： Kubernetesに対する権限管理 | 02

Slide 10

Slide 10 text

10 Kubernetesに対する権限管理の課題過去開発チームは、クラスタの状態確認や運用を実施するにあたり、デプロイサーバーに SSHしてkubectlを実行 ● 強い権限を持ち、誤操作に対する安全性や監査の観点でセキュリティリスクがある ● 便利なCLIツールを利用しにくいデプロイサーバー開発チーム SSH kubectl –context cluster-a ● いつか事故るよなぁ ● 便利なツールが色々あるんだけどなぁ

Slide 11

Slide 11 text

11 1つ目のリリース：ローカルからIAM認証で繋げるようにするローカルからKubernetesにアクセスできるようにした ● 本番はRO、開発はRWで最低限の安全性と監査を担保 ○ 厳格な権限制御と個別チューニングは一旦実施しない ○ Google WorkspaceのGroupに対して付与 ● 便利kubectl pluginなどが使えて生産性向上の効果も見られた開発チーム $ kubectx cluster-a $ kubectl ● ワークフローを大きく変えることなく少し良くできたなぁ

Slide 12

Slide 12 text

12 フィードバックを得る開発チームの理解が深まった今より少し良くするためには？それをすべきか？（相談）ある運用が従来通りできなくて、従来の方法で実行せざるを得ないシーンがあるから SREにオペレーションしてほしい（権限不足）（相談）コンテキスト違いの誤操作で環境を壊してしまわないか心配（権限過剰）（ペアプロ、ペアオペ）こんな運用で従来の方法を使っちゃってるなぁ

Slide 13

Slide 13 text

13 2つ目のリリース：デフォルト権限の弱化と権限突破個別チームに最適化するのではなく、安全に倒した上で権限突破の仕組みを用意する ● デフォルトは事故を防ぐを第一に ● 必要な運用の際は権限突破の仕組みを利用して自分たちで対応開発チーム $ kubectl rollout restart 権限突破サービス権限リクエスト権限付与監査ログの記録 JIT-access (OSS) ↓ Privileged Access Manager (GCP)

Slide 14

Slide 14 text

14 振り返ってみて気づいた大事にしていたこと ● 段階的に改善すること ○ 小さな価値（MVP）のリリースを繰り返す ○ 色々やりたくなる気持ちを抑えて、早い段階で価値を届け、フィードバックを得る ○ フィードバックを得る前にワークフローを大きく変更しない ● 継続的にフィードバックを受け取ること ○ 開発チームとのペアプロ（反応をリアルに感じられる） ○ 気軽に話にきてもらう、能動的にフィードバックを求める小さな価値ユーザーの理解 SRE チーム文脈補強意思決定フィードバック

Slide 15

Slide 15 text

15 具体例②： Terraformによるパブリッククラウドの構成変更 | 03

Slide 16

Slide 16 text

16 パブリッククラウドの変更に関する課題過去開発チームは、パブリッククラウドを変更するときには、SREに依頼することで実施していた ● 開発チームでコントロールできない待ちが発生してしまう ● クラウドリソースに関するオーナーシップを持ちにくい ● SREチームにとってもToil的な対応が課題に開発チーム依頼 Terraform CI/CD

Slide 17

Slide 17 text

17 どうしますか？ ● 慣れたインターフェース（ Kubernetesのマニフェスト等）で抽象化を用意する ● 主なユースケースに対する Terraformのモジュールを用意する ● Terraformを書くためのドキュメントや学習リソースを整備し、アナウンスして使ってもらう ● etc… 小さな価値ユーザーの理解 SRE チーム文脈補強意思決定フィードバック

Slide 18

Slide 18 text

18 1つ目のリリース：積極的なペアプロ開発チームとペアプロをするとこから始めた（形のないリリース）開発チーム ● 積極的にやろうとしてくれるな、計画の精度を高められて開発チームとしても嬉しいのかも ● HCLも割とシュッと書いてくれるな ● みんなが使えるように舵を切ってもいいかも Terraform CI/CD 依頼ペアプロでやってみませんか？ tfactionを利用

Slide 19

Slide 19 text

19 2つ目のリリース：開発チームだけで書けるようにするペアプロを繰り返すうちに、典型的なユースケースではもう開発チームだけで書けるという感覚を得てきた ● プルリクエストによる変更の受け付けを開始 ● マージはSREチームメンバーがチェックした上で実施開発チーム Terraform CI/CD PR レビュー・マージ CloudSQLのHA構成有効化 tfactionを利用

Slide 20

Slide 20 text

20 これからのリリース？ ● 認知負荷の軽減 ○ 典型的なユースケースでは、開発チームが設定したい箇所が概ね見えているので、抽象化 ○ 初めて/挑戦的なユースケースの抽象化はせず、ペアプロから始める ● フローの安全・高速化 ○ ガードレール ○ Stateを切り離し、開発チームに閉じた範囲ではマージも可能に

Slide 21

Slide 21 text

21 小規模にPlatform Engineeringを実践することについて | 03

Slide 22

Slide 22 text

22 文脈を踏まえて意思決定する領域のベストプラクティスは意識するが、何の価値をつくり、届けるかは文脈を意識する ● エクストリームプログラミング（アジャイル） ○ ペアプロで開発を進めることが基本 ○ 少しずつ改善する ● マイクロサービス ○ 担当領域に関わるコンポーネントのオーナーシップは開発チームが持つ ● チーム間のコミュニケーション ○ 口頭での同期的なコミュニケーションを優先する、すぐ直接話す

Slide 23

Slide 23 text

23 理想とのギャップは常にある ● 自分たちがやっていることはPlatform Engineeringと言えるのだろうか？ ○ IDPやセルフサービスのAPIの構築例などに圧倒される ● もっと生産性と、サービス品質を高くする抽象化を求めたくなる ● ワークフローへの適合と、ベストプラクティス準拠のトレードオフ ○ ワークフローを尊重しながら、納得感あるフローの改善に導くこと

Slide 24

Slide 24 text

24 それでもあえて、Platform Engineeringだと言ってみる ● プラットフォームをプロダクトのように扱う ○ ユーザーに価値が届くこと ○ ワークフローに適合すること ○ ユーザー（開発者）から頻繁にフィードバックを得ながら、段階的に改善すること ● 形あるプラットフォームにこだわらないこと ○ ドキュメントもプラットフォーム小規模なためできることは限られるが、小さな価値をしっかり届ける（使われるものをつくる）。組織としてより投資する段階になったら、その経験は活きるはず。

Slide 25

Slide 25 text

25 まとめ ● Platform Engineering専任でないSREチームが、Platform Engineeringを実践 ○ ユーザー（開発者）のペインを理解し、小さく価値を届ける ○ コミュニケーションとフィードバックの繰り返し ● 小規模でも始められるし、だからこそ始めやすい ○ むしろ、実はやっていたことはPlatform Engineeringとも言えるかも？

Slide 26

Slide 26 text

26 補足資料 | Appendix

Slide 27

Slide 27 text

27 Terraformのペアプロをしてみて小さな価値組織における文脈 ● 開発チームは外部依存を減らすことで、計画の精度が高まるんだなぁ ● Terraformを書くというプロセスは、計画スキルと技術的興味などから受け入れられるものなんだなぁ ● スキル的にも十分適用可能だな