©MIXI 一人SREが歩んだ Platform Engineering スモールスタート実践録 株式会社MIXI 井上 翔太 

©MIXI 自己紹介 名前：しょっさん
 X（旧: Twitter）/ mixi2：@syossan27
 所属：株式会社 MIXI
 活動：
 ● SRE Kaigi 実行委員長 ● SRE Magazine 編集長 ● ゆるSRE勉強会 共同運営 ● 一般社団法人 SREコネクト 代表理事 ● o11ycon コアスタッフ 

©MIXI Fanstaのご紹介 • スポーツ観戦ができる飲食店に特化した検索・予約サービス • スポーツ観戦できる飲食店をエリアやチーム、放映予定から検索し、予約できる • お店にとってはスポーツ観戦ができることを告知し、集客することができる ©Fansta 

©MIXI このセッションでは Platform Engineeringの必要性に気付き、 その実践をスモールチームで コツコツやっているお話をします 

©MIXI 背景 

©MIXI ４年前のお話 遡ること４年前・・・ ■ 2021/03〜 とある機能の実装の流れからインフラをちょこちょこと触るようになる ■ 2021/04〜 負荷計測・パフォーマンスチューニング、インフラ・デプロイフローの障害時調査な どのタスクに積極的に関わる ■ 〜2021/10 上記を続けながらアラートを追加したり整理したり、トイルを無くすように仕組み作 りをしたり、インシデント管理をしたり・・・ 

©MIXI あれ？これってSREってやつなんじゃない？　 

©MIXI 遊撃部隊 誕生！ 「SREの実践もしたい 」「開発リソースも足りないので開発しないといけない 」こ の２つの側面があり、単純にSREポジションとして名乗ることは避けました。 Misoca社様がやってらっしゃる「遊軍チーム 」の取り組みが これからやろうとしていることとしっくり来たのでお名前を拝借しました 

©MIXI 遊撃部隊 誕生！ 「SREの実践もしたい 」「開発リソースも足りないので開発しないといけない 」こ の２つの側面があり、単純にSREポジションとして名乗ることは避けました。 Misoca社様がやってらっしゃる「遊軍チーム 」の取り組みが これからやろうとしていることとしっくり来たのでお名前を拝借しました 2021/12 遊撃部隊 誕生！！ 

©MIXI 2023-03-09 Platform Engineering Meetup #1 参加 

©MIXI あれ？これって一部やってることが Platform Engineeringってやつなんじゃない？　 

©MIXI なぜPlatform Engineeringを 知らずに実践できていたのか？ 

©MIXI Platform EngineeringとSREの"交差点" Platform EngineeringとSRE、向いている方向が違うが重なるところがある Platform Engineering ：「ストリームアラインドチーム 」の方向を向いている SRE：「プロダクトの信頼性 」の方向を向いている Platform Engineering ：「開発者の生産性を下げるトイル 」をなくそうとする SRE：「信頼性を脅かすトイル 」をなくそうとする 各々がグラデーションを持ってタスクをこなす中で「トイル」という点においては 重なりを持つ。 

©MIXI "PE"の観点から遊撃活動を振り返り ゴールデンパスの整備 ● CI/CDパイプラインの整備 ● リリースプロセスの自動化 開発ワークフローの自動化と効率 化 ● プレビュー・開発環境の整備 ● 依存関係の管理 ● スクラムプロセスの自動化 セルフサービスの実現 ● QAチーム向け支援ツールの開発 ● 開発環境の可視化・利用管理 

©MIXI "PE"の観点から遊撃活動を振り返り 「ストリームアラインドチームが"価値"を提供するまでの間 で迷わないように道を舗装すること」を考えていた 必要最低限の基盤が整っており、とりあえず「リリースに間 に合わせた」といった状態 状況 思考 ゴールデンパスの整備 ● CI/CDパイプラインの整備 ● リリースプロセスの自動化 

©MIXI "PE"の観点から遊撃活動を振り返り ストリームアラインドチームが雑事に時間を割かないように 集中するための環境づくりをしたい！ 開発をより良くする環境づくりがされていない状況 新しく始めたスクラムもイベントに時間がかかったり・・・ 状況 思考 開発ワークフローの自動化と効率 化 ● プレビュー・開発環境の整備 ● 依存関係の管理 ● スクラムプロセスの自動化 

©MIXI "PE"の観点から遊撃活動を振り返り ストリームアラインドチーム・イネイブリングチームで作業 が完結する環境を作りたかった 特にケアされていない状況 状況 思考 セルフサービスの実現 ● QAチーム向け支援ツールの開発 ● 開発環境の可視化・利用管理 

©MIXI Platform Engineeringを 知ってどう変わったか？ 

©MIXI "SRE × Platform Engineering"への挑戦 今までのSREのみの考え方から、よりPlatform Engineering を意識した活動への視点のシフト SREに基づいたサービスの信頼性向上を主軸とした活動と、 トイルの撲滅といった範疇での無自覚なPlatform Engineering Before After "点"の課題解決 "面"の課題解決 

©MIXI PEの実践① - Platform as Code IaCなどを含めたコード化が一切されておらず、ストリームアライ ンドチームが触るには非常に難しい状態であった PaCリポジトリを用意し、Terraformなどによるプラットフォーム 全体のコード化を行った 問題点 改善 

©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、デプロイに利用しているスクリプトなど も管理 一部についてはデプロイフローも実装 

©MIXI PEの実践② - 権限管理のセルフサービス化 PaCによって権限管理も触りやすい状態になったが、まだまだ権 限自体の認知負荷が高い状態であった IAM権限を付与するSlack botのAI機能の実装を行った 「どの権限を付与すればいいのか分からない」といった課題に対 して、AIが適切な権限を提示・付与することで解決 問題点 改善 

©MIXI PEの実践② - 権限管理のセルフサービス化 Slack bot × AIでの実現 Slack botにOpenAI API（Responses API）を組み込み、VectorStore / Function Callingで実装することで、自然言語でメンションによるIAMの権限付与を実現 

©MIXI PEの実践② - 権限管理のセルフサービス化 Slack bot × AIでの実現 Slack botにOpenAI API（Responses API）を組み込み、VectorStore / Function Callingで実装することで、自然言語でメンションによるIAMの権限付与を実現 ドキュメント検索もAIによる円滑化を目指し、実装中... 

©MIXI PEの実践③ - ゴールデンパスの進化 CI/CDパイプラインは存在し、「とりあえず動いてデプロイできる」状態だっ た ストリームアラインドチームにとってもブラックボックス化していた 問題点 改善 「開発者体験」と「信頼性」を軸に、ゴールデンパスの各要素を改良 CI/CD・セキュリティ・k8s/GKEなどで多くの改善を実施 

©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カスタムコントローラーの作成など 

©MIXI 振り返り 

©MIXI 小さなチームだからこそ出来たこと 一人で進めていけたのは「チームの大きさ」と「協力体制」 一人でPlatform Engineeringを進めていけたのはストリームアライ ンドチームの大きさが５〜６人で、つらみの共有が円滑にできた ストリームアラインドチームが非常に協力的で、仕組みの導入に理 解を示してくれた SREと同じく、チーム間でのコラボレーションを生むのは "対話" 

©MIXI そうは言っても・・・ 勿論、現実として出来なかったことや失敗したことなどが多くあります。 ■ リソースの限界 どうしても一人でやる場合、バックログは大量にストックされ優先順位付けを することが必須となります。 そのため、「 理想としてはやりたいが、急務ではない 」ものはどうしても優先 度が下げられ、もどかしい気持ちになることが多々ありました。 ■ "迷い"を解決する場が近くにない 周りにアイデアや設計の壁打ち相手がおらず、自分の視点だけで判断しなけれ ばならない難しさに厳しさを感じました。 「これをやらなくてよいのか？」「他にもよりスマートな解があるのでは？」 など迷いつつも、他の方の発信を参考に進めていました。 

©MIXI 一人でも戦える武器 - AIの福音 最近は、これらの問題に対してAIがサポートしてくれています。 ■ リソースの拡張 AIを並列実行させることで、限界はあれど大きくリソースを拡張させるこ とができるようになりました。広木大地さんが「 すべてのエンジニアは、 AIをメンバーに持つEMになる 」と仰っていましたが、まさしく一人でや るといった概念がAIによって希薄化してきています。 ■ 良き相談相手 AIは24時間いつでも・どれだけでも壁打ち相手となってくれます。 もちろん、全てを鵜呑みには出来ない部分はありますが、ある程度材料を 持ち寄って壁打ちをすると非常に示唆に富んだ回答をくれることが多いで す。 

©MIXI 明日から始める第一歩 Platform Engineeringは大規模チームや大規模組織だけのものではない 

©MIXI 明日から始める第一歩 Platform Engineeringは大規模チームや大規模組織だけのものではない ストリームアラインドチームとの対話をもとに第一歩を踏んでみる。 追い求めるのは「あるべき姿」ではなく、 「ストリームアラインドチームの開発者体験と生産性向上」 

©MIXI よちよちながらもPlatform Engineeringをやってみたお話でし た！ ご清聴ありがとうございました