IaaS/SaaS管理における SREの実践 - SRE Kaigi 2026

SRE Kaigi2026で発表した資料です。

IaaS/SaaS管理におけるSREの実践
株式会社MIXI 多羽田 俊

https://2026.srekaigi.net/session/rooma-1120
当セッションでは、MIXI GROUP全体のIaaS/SaaS管理におけるSRE実践のリアルを紹介します。
少人数チームながら、プロジェクトの自律的な開発文化を活かしつつ、徹底した自動化と標準化で「ちょうど良い統制」を実現。
IaaSではTerraformによる組織管理、SaaSでは資産棚卸しツールの自動化でコスト最適化に挑戦しました。
SREの手法をどのように組織全体に対して適用し、信頼性と効率を高めたのか――その実践知をお伝えします。

Transcript

1. ©MIXI 2026/01/31 株式会社MIXI / 開発本部 / CTO室 / 開発基盤グループ 多⽻⽥ 俊 SRE Kaigi 2026 Room A 11:20 - 11:50 IaaS/SaaS管理における SREの実践
2. ©MIXI 2 ⽒名: 多⽻⽥ 俊（たばた しゅん）@bbq_all_stars 所属: 株式会社 MIXI 開発本部 CTO 室 開発基盤 グ ループ 経歴: • 前職では主に Web アプリケーションのバック エンド開発を中⼼に、フロントや iOS アプリの 開発も経験 • 現在は主に会社の基盤システムの設計から開発 ‧保守‧運⽤や、組織全体のクラウドやSaaS の運⽤を⾏う ⾃⼰紹介
3. ©MIXI 3 1. 組織の⽴ち位置 2. 組織運⽤における課題と解決のアプローチ 3. パターン①: Inner Source による権限移譲パターン 4. パターン②: ⾃動化 + Human-in-the-loop のパターン 5. まとめ 本⽇のお品書き
4. ©MIXI 4 開発本部 CTO室 開発基盤グループ 特定のプロダクト・ サービスに所属するエンジニア 横断的に複数のサービス・ プロジェクトに関わるエンジニア 開発基盤グループ
5. ©MIXI 5 背景 • ツールの増加（特にAIツール） • 管理作業の肥⼤化 • 「強い権限を持つ管理者」への依存 • 組織⽂化もあり、強く統制‧管理が⾏われて いなかった部分 • 雑に Slack メンションで管理者に依頼が⾶ん でくることもある 直⾯していた「組織運⽤の課題」
6. ©MIXI 6 　開発スピードの低下 • 申請 → 承認 → 作業待ち • リードタイムの発生 • 開発者の待ち時間が増加 　手作業の弊害 • オペレーションミス • 設定の属人化・ブラックボックス化 • 誰が何のために設定したか不明 トイルとリスクの構造
7. ©MIXI 7 SRE とは、サービスの信頼性を担保するために、 運⽤をソフトウェアエンジニアリングの⼿法を ⽤いて課題を解決すること これにより、⾃動化、トイルの削減を⽬指していく。
8. ©MIXI 8 解決のアプローチ Concept 「申請」から「Pull Request」へ • あらゆる管理操作を「コード（または設定 ファイル）」として表現する • インターフェースを GitHub (PR) に統⼀する 共通する狙い 透明性: 誰が‧いつ‧何を‧なぜ変更したかがGitに残る 安全性: 「Apply/実⾏」の前に必ず「Review/Merge」の プロセスを挟む
9. ©MIXI 9 今回の課題に対し、対象の性質に合わせて2つのパターンを使い分けた。 適⽤した2つのパターン パターン① : Inner Source による権限移譲 対象: 変更に組織管理者の承認が必要な IaaS/SaaS 主語: 主に「事業部」 がコードを書き、PRを作る 目的: ボトルネックの解消と、開発の自律化 パターン②: ⾃動化 + Human-in-the-loop 対象: 変更に組織管理者の承認が必要ない SaaS 主語: 「Bot(機械)」 がPRを作り、「⼈間」 が判 断する ⽬的: トイルの削減と、誤削除リスクの回避
10. ©MIXI パターン①: Inner Source による 権限移譲
11. ©MIXI 11 IAM Identity Center (旧SSO) とは • AWS Organization環境下の認証‧認可を統合 管理 • User / Account / Permission Set を定義 構造上の制約と課題 • Permission Set は組織の IAM Identity Center 管理アカウント 上のリソース • 課題: 事業部はOrganizationの管理アカウン ト権限がないため、Permission Setの作成‧ 変更は管理者に依頼するしかない AWS IAM Identity Center の概要と課題
12. ©MIXI 12 実現したいこと   事業部 • SSO 経由でログインできるユーザーの設定 • Permission Set の Policy のカスタマイズ • Permission Set、AWS アカウント、ユーザー の紐付け • ユーザーの設定変更の承認   組織管理者 • AWS アカウントと事業部の紐付けの承認
13. ©MIXI 13 実現したいこと   事業部 • SSO 経由でログインできるユーザーの設定 • Permission Set の Policy のカスタマイズ • Permission Set、AWS アカウント、ユーザー の紐付け • ユーザーの設定変更の承認   組織管理者 • AWS アカウントと事業部の紐付けの承認 Terraformによる分割管理 CODEOWNERSによる権限委譲 CODEOWNERSによる権限設定
14. ©MIXI 14 • .github/CODEOWNERS: ディレクトリと事業部の GitHub Team 承認権限の紐 付け • common/: 事業部情報から各種リソースを作成 • project_a, project_b.../: 各事業部が管理するTerraformディレクトリ リポジトリとディレクトリ構成 repository-structure .github/ └── CODEOWNERS # 権限紐付け common/ # [組織管理] ├── tfe.tf ├── oidc.tf └── variable.tf project_a/ # [事業部管理] ├── permission.tf └── variable.tf project_b/ # [事業部管理] └── ...
15. ©MIXI 15 GitHubの特定のパスに対して、必須承認者 or チーム を割り当てる機能。 これにより、特定のファイル/ディレクトリの PR の承認権限を委譲することができる。 CODEOWNERS .github/CODEOWNER # 組織管理者がオーナー /.github/ @octcat-org/admin /terraform/common/ @octcat-org/admin /terraform/modules/ @octcat-org/admin # 各事業部ディレクトリは、各事業部チームに委譲 /terraform/project-a/ @octcat-org/project-a-team /terraform/project-b/ @octcat-org/project-b-team ...
16. ©MIXI 16 • 組織管理者が承認するディレクトリ • 事業部のための HCP Terraform の workspace や、 Terraform に必要な権限を⽤意 • 構成: ◦ tfe.tf: workspace作成 ◦ tfc_oidc_iam_role.tf: workspace の plan / apply を実⾏するための IAM Role 作成 ◦ tfc_oidc_provider.tf: OIDC Federationの設定 ◦ variable.tf: 事業部とアカウント紐付け IAM Role の condition によって、 account_ids に設定し た AWS アカウントのみに対して操作できる権限を付与 common (組織管理部分) common/variable.tf locals = { divisions = { project_a = { account_ids = { "account-a" = "000000000000" "account-b" = "111111111111" ... } } project_b = { account_ids = { "account-c" = "222222222222" ... } } } ... }
17. ©MIXI 17 • 事業部が承認するディレクトリ • 個々のユーザーが、どういう policy で、どの AWS にアクセスするかを制御する • 構成: ◦ permission.tf: ▪ policy の定義 ▪ Permission Set の作成 ▪ Permission Set の作成、ユーザー、 AWS アカウントの紐付け設定 ◦ variable.tf 各事業部が管理するディレクトリ project_a/variable.tf locals = { accounts = { account-a = { policy-a = { users = [ "aaa@example.com", "bbb@example.com", ... ] } policy-b = { users = [ "ccc@example.com", ... ] } ... } account-b = { ... } ... } }
18. ©MIXI 18 全体のフロー 1. 初期セットアップ common/ • 事業部とAWSアカウントを紐付けるPR を作成 • 組織管理者が承認 • HCP Terraform workspace作成 2. ⽇常運⽤ projects/project_a/ • ユーザー変更のPRを作成 • 事業部メンバーが承認 → マージ • HCP Terraformが⾃動Apply 管理者は初期設定のみ。⽇常運⽤は事業部で完結。
19. ©MIXI 19 • Admin権限を渡すわけではない ◦ 事業部が触れるのはあくまで「定義ファイル」のみ • 技術的な安全装置 ◦ Stateの分離: 事業部ごとの workspace（State）が分かれているため、他事業部の設定を破壊できない ◦ OIDCのスコープ制限: 事業部 workspaceのIAM Roleは、common で許可されたAWSアカウントに対してのみ操作可能 ガードレールと安全性
20. ©MIXI 20 CNAPPソリューション「Wiz」への適⽤ • Wiz の Project と User 管理にも同様のスキームを適⽤ • 事業部管理のクラウドのセキュリティ情報を、事業部が⾃ 由に閲覧できるようにしたい • AWS管理のリポジトリ構成‧思想をそのまま横展開 Wiz での利⽤例
21. ©MIXI 21 Wiz の構成 Project • 複数のクラウドアカウントを束ねる単位 • 事業部ごとに Project を作成 • Project とクラウドアカウントの紐付け は、Wiz の管理者が確認したい User • 事業部ごとに User の作成と Project と User の紐付けを⾏う • 各 Project の User 管理は、事業部で 管理してもらいたい
22. ©MIXI 22 承認フローの分離 • projects/ (クラウド紐付け): セキュリティ管理者が承認 (勝⼿な紐付け防 ⽌) • users/ (ユーザー追加): 事業部が承認 (CODEOWNERSで委譲) ポイント: AWSの管理⽅法に加えて、GitHub Teamの管理も Terraformに追加。 Wiz の管理⽤のディレクトリ構成 repository-structure .github/CODEOWNERS github-teams/ # GitHub Team管理 projects/ # クラウド紐付け users/ # Userアサイン
23. ©MIXI 23 結果  時短 • 組織管理者の作業時間 の短縮 • リードタイムの短縮 • 作業待ち時間  効率化 • 組織管理者を作業から 解放 • 本質的な基盤改善に集 中  ガバナンス • 透明性の向上 • ブラックボックス → Git Log • チーム内相互レ ビューの⽂化
24. ©MIXI パターン②: ⾃動化 + Human-in-the-loop
25. ©MIXI 25 • 課題の性質 ◦ Terraform Providerが充実していない、またはAPIしかない ◦ 管理者の承認なしにユーザー追加は⾃由だが、適切に削除がされていないケース • ゾンビアカウント問題 ◦ SSOでログイン⾃体は防げるが、SaaS上にアカウントデータは残るケースがある ◦ 結果: 退職者が「アクティブユーザー」としてカウントされ、ライセンス課⾦が継続してしまう SaaS管理における問題
26. ©MIXI 26 ツール概要 アプローチ • 「作成（⼊⼝）」は各 事業部にお任せ • 「棚卸し（出⼝）」に 特化して中央管理する 処理フロー: • 定期実⾏ (GitHub Actions) • → 各SaaS API取得 • → ⼈事DB取得 • → 差分検知 • →退職者のリストの PR を作成 • →PRをマージすること で棚卸し Rust を採⽤ • 型安全性: 変更に強い 堅牢なコード • 運⽤: シングルバイナ リでGitHub Actions上 で軽快に動作
27. ©MIXI 27 ⾃動化の壁 • ⼈事DBには「⼈間」しかいない • しかしSaaS上には、CI/CD⽤や連携⽤の 「Botア カウント」 が多数存在する Risk • 機械的に差分削除すると、Botも消されてしまい、 開発ラインが⽌まる なぜ全⾃動削除しないのか？ (Bot問題)
28. ©MIXI 28 解決策 ツールは「削除を実⾏」するのではなく、「削除⽤設定 ファイルの変更PR」を作る。 運⽤フロー 1. 検知: ツールが退職候補者を diff.json に追加する PRを作成 2. 判断: 管理者がPRを確認 (Botが含まれていないか チェック) 3. 実⾏: マージをトリガーに実際の削除APIが叩かれる Human-in-the-loop の安全設計
29. ©MIXI 29 結果 時短 • 棚卸し作業時間の短縮 コスト • 不要ライセンスの定期開放 品質 • オペレーションミスの排除
30. ©MIXI まとめ
31. ©MIXI 31 適⽤した2つのパターン パターン①: Inner Source による権限移譲 • ⼿法: Terraform + CODEOWNERS • 役割: 「権限の委譲」と「⾃律的な設定」 • 成果: ボトルネック解消、リードタイム短 縮 パターン②: ⾃動化 + Human-in-the-loop • ⼿法: GitHub Actions + Human-in-the-loop • 役割: 「負債の排除」と「安全な⾃動化」 • 成果: コスト削減、ミスの根絶 共通点: インターフェースを GitHub (Pull Request) に統⼀した
32. ©MIXI 32 「ちょうど良い統制」の正体 ガチガチの統制 無法地帯のカオス 我々が⽬指したガバナンスの形 「コードによる標準化」 × 「PRと承認による相互監視」 • 誰が書いても同じ品質になり（標準化） • 変更履歴が残り、適切な⼈がチェックする（相互監視） これが、⾃律的なMIXIのカルチャーにフィットした。
33. ©MIXI 33 • ブラックボックスだった「管理業務」を、エンジニアリングによって透明化‧可視化した。 • 信頼性 (Reliability) は、システムだけでなく、組織のプロセス にも実装できる。 • ⼿作業を減らし、再現性を⾼め、回復可能（Revert可能）にする。 Infrastructure as Code から Operation as Code へ 組織管理を SRE しよう
34. ©MIXI