Infrastructure as Workflow：静的な Terraform の先へ

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Day 2 のクラウド運用を管理する。インフラをステートフルで長時間実行されるビジネスプロセスとして扱う。

「Infrastructure as Code」の限界：Day 1 と Day 2

私たちは Terraform（IaC）が大好きです。Terraform は「Day 1」のプロビジョニングという課題を解決しました。望ましい状態（EC2 インスタンス 10 台、RDS 1 つ、VPC 1 つ）を記述し、terraform apply を実行すれば、クラウドプロバイダーがそのとおりにしてくれます。静的なリソースにはこれで完璧です。宣言的で、冪等で、バージョン管理されています。モダンな DevOps の土台です。

しかしクラウド運用の現実として、複雑さが潜んでいるのは Day 2 です。Day 1 が結婚式なら、Day 2 は結婚生活です。Day 2 は リソース だけでなく プロセス の話です。時間とともに変化していくシステムの、生きたライフサイクルの話なのです。

重要なデータベースのアップグレードのライフサイクルを考えてみましょう。これは静的なイベントではなく、ワークフロー です。

1. 準備：安全のため、プライマリ DB のスナップショットを S3 に取得します。

2. 待機：スナップショットの完了を待つ必要があります。数 TB 規模の大きなデータベースでは 30〜45 分かかることがあります。

3. プロビジョニング：新しいエンジンバージョンを使い、スナップショットから新しい DB インスタンスを起動します。

4. 待機：新しいインスタンスが「Available」かつ「Healthy」になるまで待ちます。

5. マイグレーション：新しいインスタンスに接続し、スキーママイグレーションスクリプト（Flyway または Liquibase）を実行します。これには 1 時間かかることがあります。

6. 検証：データの整合性を確認するため、新しい DB に対して一連のスモークテストを実行します。

7. 切り替え：成功したら、DNS の CNAME を新しい DB を指すように更新します。

8. ロールバック：いずれかのステップが失敗した場合は、DNS を元に戻し、壊れたインスタンスを破棄する必要があります。

Terraform はこれには不向きです。 Terraform は宣言的であり、命令的ではありません。「30 分待つ」や「SQL スクリプトを実行して終了コードを確認する」には time_sleep や local-exec プロビジョナーという逃げ道がありますが、Terraform には永続的で再開可能、かつ承認でゲートされるプロセスモデルがありません。これに対処するため、チームはたいてい Terraform を Jenkins パイプライン、CircleCI ジョブ、Python スクリプトでラップします。このシリーズの前半で取り上げた「Glue Code Crisis」に逆戻りです — ただし今度はインフラ版です。これらのスクリプトは脆く、状態を持たず、4 時間かかる作業の途中で失敗すればデバッグはほぼ不可能です。

運用を永続的なワークフローとして扱う

SchemaBridge は、インフラ運用はビジネスワークフローである と考えています。インフラ運用には、決済処理フローと同じ要件があります。信頼性、監査可能性、状態管理、そしてエラーからの回復です。

Day 2 の運用を SchemaBridge に移すことで、クラウドのための 永続的なオーケストレーター の力を手に入れられます。

「コントロールプレーン」パターン：AWS、K8s、Terraform との統合

SchemaBridge は Terraform を置き換えるのではなく、オーケストレーションします。静的な世界と動的な世界を統合するために、コントロールプレーンパターン を使います。

1. トリガー：開発者がコードをコミットするか、開発者ポータルからワークフローの Webhook URL を呼び出して「Provision Dev Env」ワークフローを起動します。

2. プロビジョニング：SchemaBridge が Terraform Cloud API（または独自ランナーの HTTP エンドポイント）を呼び出し、物理リソースを作成する実行を開始します。SchemaBridge 自身が terraform をシェル経由で実行することはありません。ワークフロースクリプトは設計上、プロセスやファイルシステムにアクセスできない GraalVM サンドボックス内で実行されます。

3. 待機：永続的な Delay ステップで待ち、その後 Gateway ステップで Terraform の実行ステータスを確認します。ワークフローは非巡回グラフなので、無限のポーリングループの代わりに、待機と確認のステップを上限付きの回数だけ連結するか、Delay の後にワークフロー自身を再起動（re-spawn）させます — 当社の段階的ロールアウト用システムワークフローが使っているのと同じ再帰です。

4. プロビジョニング後処理（「ロジック層」）：インフラが存在するようになったら、SchemaBridge は DB マイグレーションの実行、テストデータの投入、受け入れテストの起動を行うエンドポイントを呼び出します — CI システムの API や、新しいクラスター内であなたが管理する小さな運用サービスなどです。

このパターンにより、リソースは HCL（HashiCorp Configuration Language）で定義したまま、運用ロジックはビジュアルグラフで定義できます。

エフェメラル環境：開発速度の聖杯

モダンなエンジニアリングチームはどこも エフェメラル環境 — Pull Request（PR）ごとの本番環境の完全なレプリカ — を求めています。これにより真の分離が実現し、バグが main にマージされる前に防げます。

従来のアプローチは、後片付けが難しいために失敗します。PR-123 用にリソースを起動しても、開発者が PR を閉じ忘れたり、クリーンアップスクリプトが失敗したりします。そしてクラウドの請求額は「ゾンビ RDS インスタンス」や「孤立したロードバランサー」で膨れ上がります。

SchemaBridge では、環境は ライフサイクルが定義されたワークフロー です。

1. 開始：プロビジョニング API を通じてリソース（RDS、キャッシュ、ECS サービス）を起動します。

2. 待機：永続的な Delay ステップが、作成時点で破棄をセットします — たとえば 24 時間の TTL です。待機中はワーカーもコンテナも占有せず、起床時刻は永続化されます。

3. クリーンアップ：タイマーが満了すると、ワークフローが起床し、プロビジョニング API を呼び出して環境を破棄します。「PR がマージされたらすぐに破棄する」場合は、Git プロバイダーのマージ Webhook を別の破棄用ワークフローに向け、両方が発火しても害がないよう破棄処理を冪等にしておきます。

破棄タイマーは環境を作成したのと同じ実行の中でセットされるため、忘れにくい のです。SchemaBridge クラスター全体が再起動しても、永続化されたタイマーは発火し、PR-123 の環境は予定どおり破棄されます。これは「クラウドのためのガベージコレクション」です。

例示シナリオ：レイテンシに敏感なサービスのためのノータッチ Blue/Green デプロイ

レイテンシに敏感なマッチングエンジンを運用し、1 マイクロ秒のダウンタイムも出さずにコアサービスを更新する必要があるチームを考えてみましょう。

課題

トラフィックを切り替える 前に、新バージョンの正確性をライブデータで 10 分間検証する必要がある場合、標準的な Kubernetes のローリングアップデートでは十分に安全とは言えません。複雑な「Shadow Mode」デプロイが必要になるでしょう。

SchemaBridge によるアプローチ

チームは SchemaBridge で「Blue/Green Deployment Workflow」を構築できます。

1. Green をデプロイ：新バージョンのエンジンを旧バージョンと並べて起動します（Green）。

2. シャドートラフィック：API Gateway を設定し、ライブトラフィックの汎用的なコピーを Green に送ります（fire-and-forget）。Green からのレスポンスはユーザーには返されず、記録されます。

3. 検証：10 分間の Delay の後、ワークフローは Green の記録済みレスポンスと、対応する Blue（本番）のレスポンスのサンプルを HTTP で取得し、JSONata で比較します。

4. 判定ポイント：条件付きエッジが比較結果に基づいてルーティングします。

5. 切り替え：ワークフローがロードバランサーを更新し、実際のユーザートラフィックを Green に切り替えます。

6. クリーンアップ：さらに 1 時間待ち（ロールバックを容易にするため）、その後 Blue を破棄します。

結果

このようなワークフローは、デプロイのリスクを大幅に低減できる可能性があります。SRE チームはデプロイを起動したら席を離れることができ、ワークフローが自分たちの設計した検証と明示的なクリーンアップ経路を実行してくれると分かっています — リスクが高く頻度の低いリリースを、より安全で日常的なものに変えられるのです。

コスト管理：FinOps の「ワークフロー」

クラウドコストの最適化（FinOps）は、多くの場合、開発者にリソースを停止するよう催促し続ける手作業のプロセスです。SchemaBridge なら、このガバナンスを自動化できます。

Night Watchman パターン

毎晩 20:00 に実行される「Night Watchman」ワークフローをデプロイできます。

1. スキャン：運用 API（たとえばクラウド SDK をラップした小さな Lambda や社内サービス）に、非本番のタグが付いたすべてのリソースを問い合わせます。SchemaBridge は HTTP でこれと通信します。ネイティブの AWS コネクターはありません。

2. アクティビティ確認：同じエンドポイントに直近 1 時間の CPU 使用率を報告させ、5% 未満のリソースだけを残します。

3. 停止：アイドル状態なら、エンドポイントを呼び出してインスタンスを停止します（終了はしません）。

4. 通知：所有者に Slack メッセージを送ります：「コスト節約のため、あなたの開発マシンを一時停止しました。」

5. 再開：運用ツールから Webhook URL 経由でトリガーされる別の「start my box」ワークフローが、朝にインスタンスを再起動します。

このようなシンプルなワークフローで、アイドル状態の開発環境への支出を目に見えて減らし、忘れられたまま常時稼働している非本番リソースの継続的なコストを削減できます。

比較：Jenkins/GitLab CI と SchemaBridge による運用

| 機能 | CI/CD パイプライン（Jenkins） | SchemaBridge による運用 |

| :--- | :--- | :--- |

| 状態 | エグゼキューターに紐づく。長い待機中もリソースを占有 | 永続的（PostgreSQL に永続化され、再起動を乗り越える） |

| 期間 | 分〜時間 | 時間〜日（永続タイマー） |

| ロジック | スクリプト（Bash/Groovy） | ビジュアル（グラフ） |

| 承認 | パイプライン内の input ステップ | Approval ステップ（UI または API）、タイムアウト付き |

| 回復 | ステージからの再開 | 失敗したステップからの再試行 |

| 並列性 | エグゼキューター数に制限される | オートスケールするワーカーによるファンアウト（Spawner） |

運用自動化のためのエキスパート・チェックリスト

運用スタックをモダン化するには、次のヒューリスティクスに従ってください。

1. 待機をスクリプトに書かない：ALB を待つために bash で sleep 60 と書いているなら、やり方が間違っています。永続的な Delay ステップと、その後のステータスチェックを使いましょう。

2. まず削除を自動化する：作成ロジックの 前に クリーンアップロジックを書きましょう。すべての作成イベントに、対応する破棄経路があることを確認してください。

3. 承認ゲートを使う：リスクの高い操作では、ためらわずに人間をループに入れましょう。「Pause for Approval」はバグではなく機能です。

4. オペレーターを監査する：誰が 環境を起動したのか、なぜ なのかを記録しましょう。トリガー側から依頼者の ID をペイロードで渡してもらい、作成するすべてのリソースにそれを付与します。

5. 運用をコードとして扱う：運用ワークフローを、アプリケーションコードと同じようにバージョン管理しましょう。バンドルとしてエクスポートし、レビューのためにリポジトリに保管し、Deployments ページ（計画・レビュー・適用）または構成のインポートでデプロイします。

結論：クラウドはステートマシンである

あなたのインフラは、静的なサーバーの山ではなく、ビジネスの生きた構成要素です。インフラをステートマシンとして扱うことで、現在 SRE チームの時間を奪っている、複雑で多段階の運用手順を自動化できます。安全性と永続性を組み込んだまま、「チケットベースの運用」から「セルフサービスの運用」へと移行できるのです。

あわせて読みたい：コールドスタート神話：イベント向けに JVM を最適化する — 長時間稼働するワーカーがイベントごとのコールドスタートに勝る理由。

詳しく見る