環境凍結という Toil を倒す -セルフサービス型 Ephemeral テスト環境の 設計と実践

マイクロサービスアーキテクチャを採用する組織では、結合テストのために複数のSTG環境を運用し、チーム間で環境を共有するのが一般的です。しかし環境数が増えるほど、あるチームがテスト中は他チームがデプロイできない「環境凍結」が常態化し、リリースリードタイムの増大・環境コストの肥大化・チーム間調整コストの増加といった問題に陥りがちです。SREの観点から見れば、これは典型的なToilであり、DORA指標におけるLead Time for ChangesとDeploy Frequencyを著しく悪化させます。
私たちも最大6つのSTG環境を運用していましたが、環境を増やすアプローチでは根本的な解決に至りませんでした。環境を追加するたびにコストは線形に増加し、構築に約2〜3週間を要し、ゴミデータの蓄積によりテストデータの品質も低下していました。

私たちはKTC全体の組織横断タスクフォースとして、「必要な時に作り、不要になったら消す」Ephemeral Environmentの実現に取り組みました。DBREチームによる本番データマスキング基盤の構築、本番に近いSTG環境のIaCを同期するセルフサービス型インフラプロビジョニング、テスト専用AWSアカウントによる環境分離の3つの柱により、環境構築リードタイムを劇的に削減し、環境凍結というToilを構造的に排除しました。

本セッションでは、マスキング基盤のアーキテクチャ設計、IaC同期によるテスト環境の再現手法、テスト専用AWSアカウント戦略を中心に、マイクロサービス構成でテスト環境の運用やToil削減に課題を抱えるSRE・クラウドインフラエンジニアが、自組織で検討を始められる実践的な知見を共有します。

Transcript

1. SRE NEXT 2026 環境凍結という Toil を倒す セルフサービス型 Ephemeral テスト環境の 設計と実践 CLOUD INFRA G 白井 裕二 DATABASE RELIABILITY · DBRE 陳 路銘 KINTO Technologies 2026
2. SPEAKERS 自己紹介
3. Introduction 会社紹介 COMPANY
4. COMPANY KINTO テクノロジーズ株式会社（KTC）について
5. COMPANY KTC における SRE/DBRE ・ Cloud Infrastructure の立ち位置
6. COMPANY 多数のプロダクトを、それぞれ別のチームが内製
7. 会社スローガン
8. TABLE OF CONTENTS 目次
9. PART 01 なぜ、環境凍結という Toil を倒す必要が あるのか？ システム間連携が多いプロダクトの 背景と課題。 BACKGROUND & CHALLENGES
10. BACKGROUND & CHALLENGES スローガン「リリースファースト」に立ち返る
11. BACKGROUND & CHALLENGES ボトルネックは テスト準備・実施 — システム間連携が複雑
12. BACKGROUND & CHALLENGES テスト準備中に起きていたこと
13. BACKGROUND & CHALLENGES 環境凍結の定義
14. BACKGROUND & CHALLENGES 環境凍結が発生することで発生する Lead Time
15. BACKGROUND & CHALLENGES 検証用環境を増やせば良いのか？
16. BACKGROUND & CHALLENGES 解決策 — 開発チーム専用環境を、開発者自身で用意する！
17. PART 02 セルフサービス型 Ephemeral テスト環境 の設計 2 つのプラットフォームで実現する。 SOLUTION
18. DESIGN OVERVIEW 問題整理: 2 つのボトルネック
19. DESIGN OVERVIEW セルフサービス型 Ephemeral テスト環境
20. PART 02 — 1 セルフサービス型 Ephemeral インフラ構築プラットフォーム 開発チーム自身が、環境を作って 消せるように。 CLOUD INFRASTRUCTURE
21. DESIGN OVERVIEW 全体設計方針
22. 非機能要件 安全性を担保する ①
23. 非機能要件 安全性を担保する ②
24. 機能要件 複数の同じシステムを構築可能にする ①
25. 機能要件 複数の同じシステムを構築可能にする ②
26. 機能要件 複数の同じシステムを構築可能にする ③
27. DESIGN OVERVIEW 非機能・機能要件の達成が、リードタイム短縮につながる
28. 業務要件 インフラ構築のリードタイムを下げる ①
29. 業務要件 インフラ構築のリードタイムを下げる ②
30. PROGRESS 自律的にインフラの構築・削除が可能に
31. PART 02 — 2 セルフサービス型 Ephemeral データ準備プラットフォーム 本番相当データを、短時間で安全に届ける。 DATA PREPARATION
32. DATA MASKING · DBRE 環境は作れた。では、データはどこから来るのか
33. DATA MASKING · DBRE 本番相当データを安全に届けるための 2 つの責務
34. DATA MASKING · DBRE — サブシステム① データを加工して届ける：マスク処理フロー
35. DATA MASKING · DBRE — サブシステム② 何をマスクすべきかを判断・管理する：データ区分台帳の管理フロー
36. DATA MASKING · DBRE テスト価値を壊さないマスキング設計
37. DATA MASKING · DBRE セキュリティ
38. DATA MASKING · DBRE マスキング基盤が担保したもの
39. DATA MASKING · DBRE 開発チームが自律的にテストデータを準備できる
40. DATA MASKING · DBRE データ側のまとめ — テストデータ準備は、もうボトルネックではない
41. PART 03 環境凍結という Toil を倒せたか？ RESULTS
42. Q 環境凍結という Toil は、倒せたのか？ A 「共有環境で 1 つの PJ がテスト中は他 PJ が待つ」 ——凍結を生む構造そのものを排除した。
43. セルフサービス型 Ephemeral テスト環境 Ephemeral テスト環境（インフラ＋本番相当データ）を主体的に用意できる。 支える 2 つの基盤
44. SUMMARY 目指したあるべき姿を、実現できた
45. CONCLUSION テスト準備フェーズの短縮が、リリースファーストにつながった
46. ありがとう ございました 環境凍結という Toil を、構造から倒していく。 ご質問は ask the speaker でお気軽に。