ステートフルなオーケストレーションの隠れたコスト

SchemaBridge Team · 2026-02-02 · Distributed Systems, Immutable Infrastructure, Orchestration, Anti-Patterns, Reliability

「シンプルな」社内ツールが最大の信頼性リスクになり得る理由と、イミュータブルインフラのパターンをアプリケーションロジックに適用して身を守る方法。

マイクロサービスの世界では、私たちは疎結合に執着します。キューを使い、イベント駆動アーキテクチャを採用し、モノリスを分割します。それなのに、オーケストレーションエンジンの内部では、分散システムの大罪をしばしば犯しています。ステートフルなループを書いてしまう のです。

SchemaBridge では最近、コアとなるシステムワークフロー、つまり私たち自身の段階的ロールアウトを駆動するワークフローを全面的に見直しました。その過程で、多くのエンジニアリング組織を悩ませているのと同じアンチパターンに直面しました。これは単なるリリースノートの話ではなく、イミュータブルインフラストラクチャ の原則をアプリケーション層に適用する試みです。

「ループ」というアンチパターン

古典的な「ポーラー」を考えてみましょう：

while not deployment.is_ready():
    sleep(60)
    check_status()

このコードは安定した世界を前提にしています。ポーリングするプロセスが永遠に生き続けると仮定しているのです。実際には、これは 分散モノリス の産物です。長い同期的な待機のあいだ状態をメモリに保持するプロセスは脆弱です。ホストが再起動したり呼び出しがハングしたりすると、その状態を失うか、誰にも監視されない「ゾンビ」として残り続け、障害モードは予測不能になります。

解決策：再帰的チェイニング

私たちは内部の while ループから、関数型プログラミングで使われる 継続渡しスタイル（Continuation Passing Style） に似た 再帰的実行モデル へと移行しました。

イミュータブルなロジック：正規化ハッシュによるバージョニング

バージョニングは難しいことで有名です。ワークフロー定義を更新したとき、すでに実行中のものはどうなるのでしょうか。

SchemaBridge のワークフローバージョンはイミュータブルです。デプロイは新しいバージョンを作成し、実行は開始時のバージョンに紐づけられます。私たちが追加したのは 正規化 DSL ハッシュ です。インポートされたすべてのワークフロー定義は正規化された JSON 形式にシリアライズされてハッシュ化され、そのハッシュがワークフローとともに保存されます（dslHash）。

このハッシュは、以前は意外なほど答えにくかった問い、つまり ロジックは本当に変わったのか？ に答えてくれます。設定のインポートや私たち自身のシステムワークフローのブートストラップが、すでに本番稼働中のものとハッシュが一致する定義に出会うと、再デプロイではなく no-op を計画します。また、ソース定義から乖離した本番ワークフローは、ハッシュを比較することで検出できます。

「ゴッドモード」を封じる

最後に、社内ツールのセキュリティに取り組みました。社内の「クリーンアップ」スクリプトに root 権限を与えるのはよくあることですが、これは 最小権限の原則 に反します。

私たちの社内「Gradual Rollout」ツールは、操作対象のワークフローをハードコードされた論理 ID で特定していたため、誤ったワークフローを指定して上書きしてしまいやすい状態でした。これを2つの方法で修正しました：

結論

オーケストレーションが sleep() に依存しているなら、あなたはクラウドと戦っていることになります。

再帰、イミュータビリティ、最小権限 を取り入れることで、「希望頼み」のオーケストレーションから、状態を検査でき、影響範囲を限定できるオーケストレーションへと移行できます。

参考資料：

詳しく見る