ワークフローとしてのインフラストラクチャ:静的なTerraformを超えて

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

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

「Infrastructure as Code」の限界:Day 1 対 Day 2

私たちはTerraform(IaC)を愛しています。それは「Day 1」のプロビジョニングの問題を解決しました。望ましい状態(EC2インスタンス10台、RDS1台、VPC1つ)を記述し、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はこれを表現できません。 それは宣言的であり、命令的ではないからです。「30分待つ」や「SQLスクリプトを実行して終了コードを確認する」といったことを扱う方法を知りません。これに対処するため、チームは通常、TerraformをJenkinsパイプライン、CircleCIジョブ、あるいはPythonスクリプトでラップすることになります。私たちは再び「グルーコードの危機」(Part 1)に戻ってきてしまいますが、今度はインフラストラクチャに対してです。これらのスクリプトは壊れやすく、ステートレスで、4時間かかる操作の途中で失敗したときにデバッグするのが不可能です。

運用を耐久性のあるワークフローとして扱う

SchemaBridgeでは、インフラストラクチャ運用はビジネスワークフローであると考えています。それらは決済処理フローと同じ要件、すなわち信頼性、監査可能性、状態管理、そしてエラーリカバリを持っています。

Day 2の運用をSchemaBridgeへ移行することで、クラウドのための耐久性のあるオーケストレーターの力を手に入れることができます。

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

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

1. トリガー: 開発者がコードをコミットするか、社内の開発者ポータル(Backstage)から手動で「Provision Dev Env」ワークフローをトリガーします。

2. プロビジョニング: SchemaBridgeがTerraform Cloud APIを呼び出す(あるいはSecure Worker内でterraform applyを実行する)ことで、物理的なリソースを作成します。

3. 待機: ワークフローは、実行が安全に「Applied」になるまでTerraform APIをポーリングします。クラウドの非同期的な性質を処理します。

4. プロビジョニング後の処理(「ロジック層」): インフラストラクチャが存在するようになると、SchemaBridgeは新しいKubernetesクラスタに接続し、DBマイグレーションを実行し、テストデータをシードし、受け入れテストを実行します。

このパターンにより、リソースはHCL(HashiCorp Configuration Language)で定義されたまま維持しつつ、運用ロジックはビジュアルグラフで定義することができます。

エフェメラル環境:開発者ベロシティの聖杯

現代のあらゆるエンジニアリングチームはエフェメラル環境――プルリクエスト(PR)ごとにプロダクションの完全なレプリカを用意すること――を望んでいます。これにより、真の隔離が実現され、mainにマージされる前にバグを防ぐことができます。

従来のアプローチが失敗するのは、クリーンアップが難しいからです。PR-123用のリソースを立ち上げたものの、開発者がPRをクローズし忘れたり、クリーンアップスクリプトが失敗したりします。「ゾンビRDSインスタンス」や「孤児化したロードバランサー」によって、クラウドの請求額が爆発的に増加します。

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

1. 開始: リソース(RDS、Redis、ECSサービス)を立ち上げる。

2. 待機: ワークフローは待機状態に入ります。PRがマージされるか、あらかじめ定義されたTTL(例:24時間)が経過するのを待ちます。

3. クリーンアップ: シグナルが到着するかタイマーが満了すると、ワークフローは自動的に目を覚まし、terraform destroy を実行します。

クリーンアップロジックが作成ロジックと同じ耐久性のあるワークフローインスタンスの一部であるため、忘れることは不可能です。たとえSchemaBridgeクラスタ全体が再起動しても、午後5時にPR-123の環境を破棄する必要があることを覚えています。これは「クラウドのためのガベージコレクション」です。

ケーススタディ:高頻度取引のためのゼロタッチBlue/Greenデプロイ

私たちは、マイクロ秒単位のダウンタイムもなくコアのマッチングエンジンを更新する必要があった、ある高頻度取引企業と協働しました。

課題

標準的なKubernetesローリングアップデートでは十分な安全性が確保できませんでした。なぜなら、トラフィックを切り替える前に、10分間ライブデータに対して新バージョンの財務的な正確性を検証する必要があったからです。彼らは複雑な「シャドウモード」デプロイを必要としていました。

SchemaBridgeによる解決策

彼らはSchemaBridgeで「Blue/Greenデプロイワークフロー」を構築しました。

1. Greenのデプロイ: 既存のバージョンと並行して、新バージョンのエンジン(Green)を立ち上げる。

2. シャドウトラフィック: APIゲートウェイ(Part 9)を構成し、ライブトラフィックの汎用コピーをGreenへ送信する(fire-and-forget)。Greenからのレスポンスはユーザーには送信されませんが、キャプチャされます。

3. 検証: ワークフローは10分間Greenのログを監視しました。JSONataを使用して、GreenとBlue(ライブバージョン)の財務的な出力を比較しました。

4. 判断ポイント:

5. 切り替え: ワークフローはロードバランサーを更新し、実際のユーザートラフィックをGreenへ切り替える。

6. クリーンアップ: (容易なロールバックのために)さらに1時間待機してからBlueを破棄する。

結果

彼らはデプロイリスクをほぼゼロにまで低減しました。SREチームはデプロイをトリガーしてランチに行くことができました。複雑な検証、監視、ロールバックのロジックをワークフローが自動的に処理してくれることを分かっていたからです。彼らは週1回のデプロイから、1日10回のデプロイへと移行しました。

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

クラウドコストの最適化(FinOps)は、しばしば開発者に「電源を切って」と促し続ける手動プロセスになりがちです。SchemaBridgeを使えば、このガバナンスを自動化できます。

ナイトウォッチマンパターン

毎晩午後8時に実行される「ナイトウォッチマン」ワークフローをデプロイできます。

1. スキャン: 非本番タグの付いたすべてのリソースを特定する。

2. アクティビティの確認: 過去1時間のCPU使用率が5%未満かどうかをCloudWatchメトリクスで確認する。

3. シャットダウン: アイドル状態であれば、インスタンスを停止する(終了はしない)。

4. 通知: オーナーにSlackメッセージを送信する。「コスト削減のため開発用のマシンを一時停止しました。再開はこちらをクリック。」

5. 再開: 翌朝開発者がボタンをクリックすると、シグナル(Part 7)がワークフローを目覚めさせ、インスタンスを再び起動する。

このシンプルなワークフローにより、あるエンタープライズ顧客はAWS EC2のコストを月額$40,000節約しました。

比較:Jenkins/GitLab CI 対 SchemaBridge Operations

| 特徴 | CI/CDパイプライン(Jenkins) | SchemaBridge Operations |

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

| 状態 | エフェメラル(再起動で消失) | 耐久性あり(何年でも保持) |

| 期間 | 分/時間 | 日/週/月 |

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

| 承認 | 基本的(UIボタン) | リッチ(Slack/Email/Webhooks/モバイル) |

| リカバリ | 最初からリトライ | 失敗地点から再開 |

| 並列性 | エグゼキュータによる制限 | サーバーレススケーリング(Part 3) |

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

運用スタックを近代化するには、以下のヒューリスティクスに従ってください。

1. 待機をスクリプト化しない: ALBを待つためにbashでsleep 60を書いているなら、それは間違ったやり方です。耐久性のあるワークフローでポーリングループを使いましょう。

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

3. 承認ゲートを使う: リスクの高いアクションに人間をループに入れることを恐れないでください。「承認待ちの一時停止」は不具合ではなく機能です。

4. オペレーターを監査する: 誰がその環境をトリガーし、なぜそうしたのかを記録しましょう。ワークフローのコンテキストを使って、リクエスト者のUser_IDでリソースにタグ付けしてください。

5. 運用をコードとして扱う: アプリケーションコードと同じように運用ワークフローをバージョン管理しましょう。SchemaBridgeのgit統合を使って、デプロイロジックへの変更をレビューしてください。

まとめ:クラウドはステートマシンである

あなたのインフラストラクチャは静的なサーバーの山ではなく、ビジネスの生きて呼吸するコンポーネントです。それをステートマシンとして扱うことで、現在SREチームの人生を消費している複雑な多段階の運用作業を自動化できます。安全性と耐久性を組み込んだまま、「チケットベースの運用」から「セルフサービス運用」へと移行できます。

Part 12では「コールドスタート神話」を取り上げ、サーバーをウォームに保つことなくサーバーレスイベントアーキテクチャでミリ秒未満のレイテンシを達成する方法を見ていきます。

詳しく見る