はじめに
DevOpsの実踐において、リードタイム（Lead Times）の短縮は継続的デリバリー（Continuous Delivery）の核心的な課題です。特に、SaaSモデルで29千億ドル規模の資産を監視し、多租戶のAWSアカウントアーキテクチャを管理するTofuLithでは、インフラ変更の効率化が業務の競爭力を左右しました。本記事では、TofuLithが実施したDevOps最適化の戦略と成果を解説し、Platform EngineeringとCNCF（Cloud Native Computing Foundation）の枠組みにおける実踐例を紹介します。
主な技術的課題と背景
核心的な問題
Terraformのインフラデプロイパイプラインがボトルネックとなり、インフラ変更のリードタイムが長引いていました。特に、以下の課題が顕在化していました：
- 並行処理制限：既存のサプライヤーは並行処理數に制限（最大10ワークスペース）
- 大規模なステートファイル：數千のリソースを管理するため、処理負荷が増加
- 分散された構成アーキテクチャ：Nest/DevNest/AccountFactoryなどの分散設計により、統一管理が困難
ビジネス特性
- SaaSモデルによる柔軟なスケーリングの必要性
- 多租戶アーキテクチャにおけるセキュリティと管理の複雑性
- リアルタイム監視と迅速なインフラ変更の要請
解決策と実裝
1. ワークスペースの分割戦略
分割の原則
- 変更頻度分析：GPTを用いて高頻度変更リソースを特定し、低頻度リソースを統合
- ビジネスロジックに基づく分割：アカウントベースライン、データ監視、エンジンサービス、結果サービス、SSOなどに分類
- 過度な微細化の迴避：アカウントベースラインとネットワーク設定は統合管理
成果
- 各テナントあたり29のワークスペースを実現
- 総數8,453のワークスペースを達成
- 並行処理能力を10から120に向上
2. サプライヤーとツールの最適化
サプライヤーの変更
- Scalaを採用し、使用量ベースの課金モデルに移行
ツールのアップグレード
- Terraform 1.5+のmoved blocks機能を活用
- 自社の構成ストレージと標準化モジュール（例：locals.tf）を構築
- 特化モジュール（例：Aurora Serverless）を開発
3. アーキテクチャとプロセスの改善
構成の標準化
- JSON Schemaによる層別構造（テナント→サービス→リソース）を定義
- ラベルとデータドッグイベントの統合を強制
リモートステート管理
- データソースを用いてリモートステートのクエリを削減
- ユニファイドモジュールリポジトリ（例：VPC/持久層モジュール）を構築
チーム構造の変革
- 保守チームを解散し、「あなたが構築するあなたが運用する」モデルを採用
- 50人のエンジニアチームに非開発者貢獻者を含む
成果とデータ
リードタイムの改善
- 90%のリードタイム削減（実証データの検証が必要）
貢獻者分析
- 2020年：4人 → 2022年：30人 → 2023年：45人
- 管理層の參加がプロセス簡素化を反映
エフェクティブ指標
- ヒートマップで一部ワークスペースの活動頻度が高め
- プロダクトチームが自主的にワークスペースを生成（平均2つ/プロダクト）
- 並行処理能力の向上（10→120）
キーテクノロジー実踐
ステートファイル管理
- moved blocksによるリソース移行
- スクリプトによるステートファイル変更パターンの分析
モジュール化設計
- 標準化されたルートモジュール構造
- 共通ロジックの封入（例：コミットIDの追跡）
継続的デリバリー
- 內部トレーニング（年次/半年次）の提供
- 領域特化知識庫（例：Terraformモジュール使用ガイド）の構築
今後の改善方向
- 自動化の最適化：非必須Terraform使用の削減（例：Lambdaデプロイの専用ツール化）
- ステートファイルの精簡：全ステートの保持の必要性評価
- パフォーマンスモニタリング：ワークスペース活動の熱點とリソース利用率の継続的分析
まとめ
TofuLithのDevOps最適化は、インフラ変更のリードタイム短縮と継続的デリバリーの実現に成功しました。ワークスペースの分割戦略、サプライヤーとツールの最適化、アーキテクチャの再設計を通じて、並行処理能力を大幅に向上させました。また、Platform Engineeringの原則に基づく構成標準化とチーム構造の変革により、柔軟なスケーリングとセキュリティを実現しました。今後の課題として、自動化のさらなる深化とステート管理の最適化が求められます。