一人SREが歩んだPlatform Engineeringスモールスタート実践録 ~ クラウドネイティブ会議版 ~

クラウドネイティブ会議の登壇資料です

Transcript

1. ©MIXI 一人SREが歩んだ Platform Engineering スモールスタート実践録 株式会社MIXI 井上 翔太
2. ©MIXI 自己紹介 名前：しょっさん X（旧: Twitter）/ mixi2：@syossan27 所属：株式会社 MIXI 活動： • SRE Kaigi 実行委員長 • SRE Magazine 編集長 • ゆるSRE勉強会 共同運営 • 一般社団法人 SREコネクト 代表理事 • クラウドネイティブ会議 Co-chair
3. ©MIXI このセッションでは Platform Engineeringの必要性に気付き、 その実践をスモールチームで コツコツやっているお話をします
4. ©MIXI このセッションでは Platform Engineeringの必要性に気付き、 その実践をスモールチームで コツコツやっているお話をします やっていた
5. ©MIXI 背景
6. ©MIXI ５年前のお話 遡ること５年前・・・ ▪ 2021/03〜 アプリケーション側の実装を中心に仕事をしていたが、 とある機能の実装の流れからインフラをちょこちょこと触るようになる ▪ 2021/04〜 負荷計測・パフォーマンスチューニング、インフラ・デプロイフローの障害時調査な どのタスクに積極的に関わる ▪ 〜2021/10 上記を続けながらアラートを追加したり整理したり、トイルを無くすように仕組み作 りをしたり、インシデント管理をしたり・・・
7. ©MIXI あれ？これってSREってやつなんじゃない？　
8. ©MIXI あれ？これってSREってやつなんじゃない？　 → SREポジションの立ち上げを行う
9. ©MIXI 2023-03-09 Platform Engineering Meetup #1 参加
10. ©MIXI あれ？これって一部やってることが Platform Engineeringってやつなんじゃない？　
11. ©MIXI 疑問
12. ©MIXI なぜPlatform Engineeringを 知らずに実践できていたのか？
13. ©MIXI Platform EngineeringとSREの"交差点" Platform EngineeringとSRE、向いている方向が違うが重なるところがある Platform Engineering ：「ストリームアラインドチーム 」の方向を向いている SRE：「プロダクトの信頼性 」の方向を向いている Platform Engineering ：「開発者の認知負荷を上げるトイル 」をなくそうとする SRE：「信頼性を脅かすトイル 」をなくそうとする 各々がグラデーションを持ってタスクをこなす中で「トイル」という点においては 重なりを持つ。
14. ©MIXI "Platform Engineering"の観点から活動を振り返り ゴールデンパスの整備 • CI/CDパイプラインの整備 • リリースプロセスの自動化 開発ワークフローの自動化と効率 化 • プレビュー・開発環境の整備 • 依存関係の管理 • スクラムプロセスの自動化 セルフサービスの実現 • QAチーム向け支援ツールの開発 • 開発環境の可視化・利用管理
15. ©MIXI "Platform Engineering"の観点から活動を振り返り 「ストリームアラインドチームが"価値"を提供するまでの間 で迷わないように道を舗装すること」を考えていた 必要最低限の基盤が整っており、とりあえず「リリースに間 に合わせた」といった状態 状況 思考 ゴールデンパスの整備 • CI/CDパイプラインの整備 • リリースプロセスの自動化
16. ©MIXI "Platform Engineering"の観点から活動を振り返り ストリームアラインドチームが雑事に時間を割かないように 集中するための環境づくりをしたい！ 開発をより良くする環境づくりがされていない状況 新しく始めたスクラムもイベントに時間がかかったり・・・ 状況 思考 開発ワークフローの効率化 • プレビュー・開発環境の整備 • 依存関係の管理 • スクラムプロセスの自動化
17. ©MIXI "Platform Engineering"の観点から活動を振り返り ストリームアラインドチーム・イネイブリングチームで作業 が完結する環境を作りたかった 特にケアされていない状況 状況 思考 セルフサービスの実現 • QAチーム向け支援ツールの開発 • 開発環境の利用状況可視化機能の開発
18. ©MIXI Platform Engineeringを 知ってどう変わったか？
19. ©MIXI "SRE × Platform Engineering"への挑戦 今までのSREのみの考え方から、よりPlatform Engineering を意識した活動への視点のシフト SREに基づいたサービスの信頼性向上を主軸とした活動と、 トイルの撲滅といった範疇での無自覚なPlatform Engineering Before After "点"の課題解決 "面"の課題解決
20. ©MIXI PEの実践① - Platform as Code IaCなどを含めたコード化が一切されておらず、ストリームアライ ンドチームが触るには非常に難しい状態であった PaCリポジトリを用意し、Terraformなどによるプラットフォーム 全体のコード化を行った 問題点 改善
21. ©MIXI PEの実践① - Platform as Code Terraformを利用したIaCの導入 開発・ステージング・本番環境に跨ったGKE・IAM・Cloud Run・Cloud Run functions・Cloud Storageなどの各種Google CloudリソースをTerraformで管理 Google Cloudには gcloudを利用した既存リソースのbulk export があり、 これを利用しながらコード化 Platformに関するコードも管理 GHA、Slack botや、Chrome Extension、デプロイに利用しているスクリプトなど も管理 一部についてはデプロイフローも実装
22. ©MIXI PEの実践② - 権限管理のセルフサービス化 PaCによって権限管理も触りやすい状態になったが、まだまだ権 限自体の認知負荷が高い状態であった IAM権限を付与するSlack botのAI機能の実装を行った 「どの権限を付与すればいいのか分からない」といった課題に対 して、AIが適切な権限を提示・付与することで解決 問題点 改善
23. ©MIXI PEの実践② - 権限管理のセルフサービス化 Slack bot × AIでの実現 Slack botにOpenAI API（Responses API）を組み込み、VectorStore / Function Callingで実装することで、自然言語でメンションによるIAMの権限付与を実現
24. ©MIXI PEの実践② - 権限管理のセルフサービス化 Slack bot × AIでの実現 Slack botにOpenAI API（Responses API）を組み込み、VectorStore / Function Callingで実装することで、自然言語でメンションによるIAMの権限付与を実現 ドキュメント検索もAIによる円滑化を目指し、実装しておりましたが頓挫
25. ©MIXI PEの実践③ - ゴールデンパスの進化 CI/CDパイプラインは存在し、「とりあえず動いてデプロイできる」状態だっ た ストリームアラインドチームにとってもブラックボックス化していた 問題点 改善 「開発者体験」と「信頼性」を軸に、ゴールデンパスの各要素を改良 CI/CD・セキュリティ・k8s/GKEなどで多くの改善を実施
26. ©MIXI PEの実践③ - ゴールデンパスの進化 Workload Identityの導入 Workload Identityを導入し、k8s podやGHAなどでセキュアな認証を実現 サービスアカウントキー管理が不要になり、セキュリティ上のリスクを排除 CI/CD体験の向上 E2Eテストの導入、ArgoCDのSelf-managed化によるアップグレードの簡略化、 ArgoCD Notificationsの導入によるデプロイ状況の通知、テストカバレッジの整備、静 的解析ツールの導入（GraphQL Inspectorによる破壊的変更の検出、kubeconformによ るmanifest validation）、etc… k8s/GKEの安定化 Instance GroupでのNodeを通じたトラフィックルーティングから、Network Endpoint Groupを利用したPodへのルーティングへ変更（ コンテナネイティブ負荷分散 ） 問題への対処療法としてのk8sカスタムコントローラーの作成など
27. ©MIXI 振り返り
28. ©MIXI 小さなチームだからこそ出来たこと 一人で進めていけたのは「チームの大きさ」と「協力体制」 一人でPlatform Engineeringを進めていけたのはストリームアライ ンドチームの大きさが５〜６人で、つらみの共有が円滑にできた ストリームアラインドチームが非常に協力的で、仕組みの導入に理 解を示してくれた SREと同じく、チーム間でのコラボレーションを生むのは "対話"
29. ©MIXI そうは言っても・・・ 勿論、現実として出来なかったことや失敗したことなどが多くあります。 ▪ リソースの限界 どうしても一人でやる場合、バックログは大量にストックされ優先順位付けを することが必須となります。 そのため、「 理想としてはやりたいが、急務ではない 」ものはどうしても優先 度が下げられ、もどかしい気持ちになることが多々ありました。 ▪ "迷い"を解決する場が近くにない 周りにアイデアや設計の壁打ち相手がおらず、自分の視点だけで判断しなけれ ばならない難しさに厳しさを感じました。 「これをやらなくてよいのか？」「他にもよりスマートな解があるのでは？」 など迷いつつも、他の方の発信を参考に進めていました。
30. ©MIXI 一人でも戦える武器 - AIの福音 最近は、これらの問題に対してAIがサポートしてくれています。 ▪ リソースの拡張 AIを並列実行させることで、限界はあれど大きくリソースを拡張させるこ とができるようになりました。広木大地さんが「 すべてのエンジニアは、 AIをメンバーに持つEMになる 」と仰っていましたが、まさしく一人でや るといった概念がAIによって希薄化してきています。 ▪ 良き相談相手 AIは24時間いつでも・どれだけでも壁打ち相手となってくれます。 もちろん、全てを鵜呑みには出来ない部分はありますが、ある程度材料を 持ち寄って壁打ちをすると非常に示唆に富んだ回答をくれることが多いで す。
31. ©MIXI 実践してみた気付き Platform Engineeringは大規模チームや 大規模組織だけのものではない
32. ©MIXI 実践してみた気付き ストリームアラインドチームとの対話をもとに 第一歩を踏んでみる。 追い求めるのは「あるべき姿」ではなく、 「ストリームアラインドチームの開発者体験と生産性向上」 Platform Engineeringは大規模チームや 大規模組織だけのものではない
33. ©MIXI よちよちながらもPlatform Engineeringをやってみたお話でし た！ ご清聴ありがとうございました