「グルーコード」危機：なぜ分散ワークフロー・オーケストレーションは難しいのか

SchemaBridge Team · 2025-12-01 · Distributed Systems, Architecture, DevOps

APIの配管作業にエンジニアリングの時間を浪費するのをやめよう。2026年、断片化したシステムをスケールさせる鍵が、なぜ分散ワークフロー・オーケストレーションにあるのかを学ぶ。

アーキテクチャのボトルネック：静かなる生産性の殺し屋

シニア開発者やアーキテクトであれば、このサイクルを経験したことがあるはずです。あなたは「シンプルな」インテグレーション――Shopifyの注文をレガシーERPと同期させる――から始めます。50行のスクリプトを書き、Lambdaかcronジョブに包んで出荷します。1日目はうまく動きます。10日目もうまく動きます。しかし、やがて世界が変わります。Shopify APIにレートリミットが追加される。レガシーERPが午前2時にデータベースのロック競合を起こす。サードパーティの配送プロバイダーがJSONレスポンスの構造を変更する。

気がつけば、あなたの「ちょっとしたスクリプト」はミッションクリティカルなインフラの一部になっています。しかし、それはインフラとして作られたものではありません。スクリプトとして作られたものです。適切なエラーハンドリングを欠き、状態という概念を理解しておらず、組み込みのレジリエンスも持ちません。それが失敗するとき、静かに失敗するか、あるいはもっと悪いことに、部分的に失敗し――データを破損した状態のまま放置し、修復に何日もの手作業を要することになります。

3か月後、その50行のスクリプトは5,000行のモンスターへと変貌しています。今ではリトライを（無限ループを使って、まずいやり方で）処理し、3つの異なる場所（うち1つは容量オーバー）にログを吐き出し、本当のエラーを隠してしまうネストしたtry-exceptブロックを含んでいます。あなたのインフラ全体では、こうしたスクリプトが20個も稼働しています。それらはあなたの組織の「グルーコード」です。これはエンジニアリングではなく、後手に回った配管作業です。

これがグルーコード危機です。それはエンジニアリングの速度を静かに奪う殺し屋です。あなたはもはやビジネスに変化をもたらす機能を構築しているのではなく、データを漏らし、負荷下で詰まり、午前3時に破裂して最優秀のエンジニアを叩き起こすページングアラートを引き起こす、脆い「配管」を構築・保守しているのです。断片化したマイクロサービスと果てしないSaaS APIの世界において、永続的なオーケストレーションの戦略を持たなければ、あなたは事実上、速乾性セメントの基礎の上に家を建てているようなものです。1週間は頑丈に見えても、ひび割れは避けられません。

危機の歴史的な起源：CGI-BINからクラウドへ

なぜ私たちがこの危機に陥っているのかを理解するには、ソフトウェア・インテグレーションの歴史を振り返る必要があります。1990年代にはCGIスクリプトとPerlがありました。それらは、リクエストをレスポンスへと変換する、小さくステートレスなコマンドでした。それらは元祖「グルーコード」でした。当時としては素晴らしいものでしたが、現代のデジタルビジネスにおける複数ステップ・複数日にまたがるジャーニーを扱うことは、もともと想定されていませんでした。それらは、まだ常時稼働でグローバルに接続されてもいなかった世界における「撃ちっぱなし」のツールでした。

2000年代には、私たちはESB（エンタープライズ・サービス・バス）――TibcoやBizTalkのような巨大で重量級のミドルウェア――へと移行しました。それらは強力でしたが、恐ろしく複雑で高価でした。すべてを中央集権化しようとした結果、「バス・アーキテクト」というボトルネックが生まれました。あらゆる変更に委員会での会議が必要でした。バスは、それが解決するはずだったもの――単一障害点であり、組織的摩擦の巨大な発生源――そのものになってしまったのです。

2010年代には、私たちはESBを拒否し、マイクロサービスを選びました。REST APIと軽量なスクリプト（Python、Go、Node.js）へと移行したのです。私たちは自由を手に入れたと思っていました。しかし実際に起きたのは、複雑さを「バス」から「サービス間の空間」へと移しただけでした。単一の重量級ミドルウェアを、環境全体に散らばった何千もの小さく脆いスクリプトに置き換えたのです。今や私たちは、サービス数に対して複雑さがO(N^2)になる世界にいます。中央集権的なボトルネックを、分散されたカオスと交換してしまったのです。

スクリプトの心理学：なぜ私たちは脆い道を選び続けるのか

なぜ私たちはスクリプトを書き続けるのでしょうか？分散システムの落とし穴を知っているはずのシニアエンジニアでさえ、「永続的なオーケストレーター」よりも「クイックスクリプト」に頻繁に手を伸ばします。その理由は心理的なものです。

1. 「クイックウィン」という誤謬

ビジネスの関係者が新しいインテグレーションを求めるとき、彼らはそれを「昨日のうちに」欲しがります。スクリプトは速く感じられます。1時間で書けます。生産的な気分になれます。「チェックボックスにチェックを入れた」気になれます。しかし、これは偽りの生産性です。あなたは自分の将来のキャパシティに対して高金利のローンを組んでいるのです。今日4時間節約しても、来月には本番環境での部分的な障害のデバッグに40時間を費やすことになります。スクリプトは、長期的な安定性よりも短期的な指標を重視するエンジニアリングマネージャーにとって、依存性の高い麻薬のようなものです。

2. 分散システムにおけるダニング＝クルーガー効果

多くの開発者は「リトライなんて簡単だ」と信じています。API呼び出しをsleepタイマー付きのwhileループで包めば十分だと考えているのです。彼らはまだ、本物の本番環境で発生するリトライストーム、孤立したアイデンティティ、あるいは状態の破損を経験したことがありません。彼らは、自分自身の失敗対応能力に関して「過剰な期待のピーク」にいるのです。真の大規模障害を午前3時に経験するまで、彼らは分散状態がインフラレベルの解決策を必要とする問題であることに気づきません。

3. より良い作業単位の欠如

つい最近まで、私たちはオーケストレーションのための標準的な作業単位を持っていませんでした。「関数」はあり、「サービス」はありましたが、「ジャーニー」はなかったのです。SchemaBridgeは、その作業単位として永続的ワークフロー（Durable Workflow）を導入します。これにより、マシンの障害、ネットワークの分断、さらには人為的ミスをも生き延びる単一の永続的なエンティティとして、複数ステップにわたるジャーニーを表現できるようになります。

失敗の解剖学：なぜ「スクリプト」はスケールしないのか

10人のユーザーで機能するスクリプトが1万人で破綻するのには、分散システムの本質に内在する3つの主要な理由があります。これらの問題は「より良いコード」だけでは解決できません。インフラによって解決しなければならないのです。

1. 部分的成功の問題：「生焼け」の状態

分散システムにおいて、成功は二値的なものではありません。あなたのスクリプトが次の3つのステップを実行するとしましょう。1) Stripe経由で顧客に課金する。2) 社内の在庫データベースを更新する。3) SendGrid経由で確認メールを送信する。ステップ1の後にプロセスがクラッシュしたらどうなるでしょうか？

顧客への課金は完了していますが、在庫は依然として「在庫あり」のままであり、ユーザーには領収書もありません。これを生のコードで解決するには、複雑なサーガパターンを手動で書かなければなりません――事実上、すべての単一のスクリプトに対してミニオーケストレーターを書くことになります。課金が実行されたかどうかを確認し、在庫状況を確認し、ロールバックを処理しなければなりません。このボイラープレートが開発時間の80%を占め、それでも分散状態が難しいために20%は間違えてしまいます。

2. べき等性のギャップ：リトライの危険性

接続は不安定なものです。スクリプトがAPIからのタイムアウトを捕捉し、リトライします。しかし、もしAPIが実際には成功しており、単にレスポンスがタイムアウトしただけだったとしたらどうでしょうか？べき等性（Idempotency）がなければ、あなたのリトライは二重請求や重複出荷につながります。ほとんどの「グルーコード」開発者は、顧客が$500ではなく$5,000を請求される事態が初めて起きるまで、この問題を無視し続けます。

数十ものサービスにまたがるすべてのAPI呼び出しにべき等性キーを追加することは、一貫して管理できるチームがほとんどない、ロジスティクス上の負担です。100個のインテグレーションがあれば、キーを忘れる可能性のある場所が100か所あるということです。真のオーケストレーションエンジンはこれをインフラレベルで処理し、ワークフローのコンテキストに基づいてこれらのキーを自動的に生成・管理します。

8つの誤謬：失敗のための土台

なぜグルーコードが失敗するのかを本当に理解するには、Sun MicrosystemsのPeter Deutschらによって最初に提唱された分散コンピューティングの8つの誤謬に立ち返る必要があります。これらは、あらゆる開発者がネットワーク対応のコードを書き始めたときに最初に抱く誤った前提です。それらはエンジニアリングにおける「偽りの楽園」です。

1. ネットワークは信頼できる：そんなことはありません。パケットは失われ、ルーターは再起動し、ケーブルは切断されます。クラウド環境では、大規模になれば毎日のように断続的なネットワーク障害が起きると想定すべきです。

2. レイテンシはゼロである：そんなことはありません。最速のグローバル光ファイバー網であっても、数千回の呼び出しにわたって積み重なるミリ秒単位の遅延が発生します。この遅延はジッターがあり予測不可能であり、ローカルでデバッグしようとすると消えてしまう競合状態を引き起こします。

3. 帯域幅は無限である：そんなことはありません。大きなペイロードはあなたの配管を詰まらせ、タイムアウトを引き起こします。クラウドプロバイダーには厳格な帯域幅の割り当てもあり、警告なしにあなたの「グルーコード」をスロットリングします。

4. ネットワークは安全である：そんなことはありません。中間者攻撃、DNSポイズニング、そして漏洩したトークンは常に存在する脅威です。適切に隔離されていなければ、あなたの「グルーコード」スクリプトは資格情報窃取の格好の標的です。

5. トポロジーは変化しない：変化します。ロードバランサーは移り変わり、ノードは死に、IPアドレスは再利用されます。スクリプトの「ハードコードされたIP」は時限爆弾です。

6. 管理者は一人である：そんなことはありません。あなたはAWS、Cloudflare、そしてスタック内のあらゆるSaaSプロバイダーの意のままです。彼らがAPIを変更すれば、あなたのスクリプトが真っ先に犠牲になります。

7. 転送コストはゼロである：そんなことはありません。大規模にJSONをシリアライズ・デシリアライズすることには、現実のCPUとメモリのコストがかかります。あなたのPythonスクリプトは、時間の40%をjson.loads()だけに費やしています。

8. ネットワークは均質である：そんなことはありません。あなたのスタックはLinux、Windows、JVM、Node、そしてレガシーなSOAPサービスの混合体です。この景観全体にわたって一定の挙動を期待するのは幻想です。

技術的深掘り：イベントソーシングとDynamoDBのスケーラビリティ

永続的なオーケストレーションエンジンを構築する上で最も難しい部分の一つが、状態の永続化の管理です。10万件のワークフローが同時に実行され、各ワークフローが10ステップを実行するとすれば、数分ごとに100万件のデータベース書き込みが発生することになります。

DBのボトルネック

従来のリレーショナルデータベース（Postgres、MySQL）は、いずれこの負荷に耐えきれなくなります。workflow_historyテーブルにおけるインデックス競合が主要なボトルネックとなります。SchemaBridgeは永続化のパーティショニングを用いてこれを解決します。

1. ワークフローIDによるパーティショニング：異なるワークフローの履歴を、標準的なNoSQLストレージ（DynamoDB）全体に分散させます。これにより、単一のパーティションがグローバルなトラフィックの全負荷を背負うことがなくなります。特定のワークフローに関するすべてのイベントは同一のパーティションに着地し、そのジャーニーに対して強い一貫性を提供します。

2. 追記専用の実行ログ：パフォーマンスに関わる経路では、ワークフローのレコードを決して「更新」しません。イベントソーシングのパターンを用いて、新しいイベントをその履歴に追記するだけです。これにより、書き込みは非常に効率的で競合のない操作へと変わります。また、あらゆるアクションに対する不変の監査証跡も提供されます。

3. イベントリプレイ：ワーカーがワークフローを引き受けると、イベントの履歴を再生することで状態をリハイドレートします。これにより、クラッシュと再起動の後であっても、メモリ上の状態が常に永続的な真実と一致することが保証されます。

ガバナンスの空白：配管は誰のものか

技術的課題の先には、文化的な課題――ガバナンスの空白――が存在します。従来のマイクロサービス・アーキテクチャでは、所有権はサイロ化されています。「プロダクトサービス」チームは製品データベースを所有します。「配送サービス」チームはFedExインテグレーションを所有します。

しかし、それらの間の橋は誰が所有するのでしょうか？

たいてい、誰も所有していません。「グルーコード」スクリプトは、応急処置を必要とした開発者によって書かれ、その後は放置されます。それが壊れると、プロダクトチームは配送チームを責め、配送チームはAPIプロバイダーを責めます。ビジネスプロセスが実際にどう接続されているかについての、中央集権的な「真実の源」は存在しません。

SchemaBridgeは、インテグレーションをグローバルな資産にすることでこれを解決します。

生物学的なメタファー：神経系としてのソフトウェア

私たちは、ソフトウェアがもはや静的なツールの寄せ集めではなく、生きた神経系であるような世界へと向かっています。生物学的な神経系では、信号は指（センサー）から脳（ロジック）へと伝わり、筋肉（アクション）へと戻っていきます。経路の一部が塞がれても、システムは適応します。反射があります。記憶があります。

永続的なオーケストレーションは、エンタープライズの神経系です。それは、断片化したサービス群を、単一のまとまりある有機体であるかのように感じさせてくれます。

1. 反射：自動リトライは、脳（開発者）を巻き込むことなく小さな「痛み」（タイムアウト）を処理します。システムは自動的に自らを負傷から守ります。

2. 記憶：永続的な状態保存により、システム全体が「気絶」した（クラスター全体の障害）としても、自分が何をしていたかを正確に覚えており、目覚めた際にその続きを再開します。あらゆる思考は安定したストレージに保存されています。

3. 意識：ビジュアルなオブザーバビリティ（第8回参照）により、組織のまさに「鼓動」をリアルタイムで確認できます。エラーのログや、成功の流れをその瞬間に見ることができます。

ケーススタディ：5,000万ドルの照合メルトダウン

この危機の深刻さを理解するために、私たちが最近協業したフィンテック企業の事例を考えてみましょう。彼らは、社内台帳と複数の銀行パートナーとの間で日々のトランザクションを照合するために、大量のPythonスクリプト群を使用していました。

障害

ある金曜日、銀行パートナーがSFTPサーバーの暗号化設定を更新しました。Pythonスクリプトはクラッシュしませんでした――単に接続に失敗し、例外を捕捉し、その日の照合を「保留中」として「静かに」マークしただけでした。ビジュアルなダッシュボードが存在しなかったため、この障害は3日間気づかれませんでした。

月曜日までに、その不一致は5,000万ドルにまで膨れ上がっていました。財務監査官が呼び出され、CEOに報告が入り、エンジニアリングチームは照合のタイムラインを手作業で再構築するために丸1週間を費やさなければなりませんでした。そのスクリプトは「ハッピーパス」では完璧に機能していましたが、「自己修復」能力もゼロ、「ビジュアルな真実」もゼロだったのです。

SchemaBridgeへの移行

この大惨事の後、彼らは照合ロジックをSchemaBridgeへと移行しました。その違いは天と地ほどでした。6か月後に同様の接続の問題が発生した際、ゲートウェイ頂点は即座に永続的な失敗を経験しました。ダッシュボードは赤く変わりました。Slackアラートが発報されました。エンジニアリングチームは2分以内にその失敗を確認しました。彼らは設定を修正し、「再開」をクリックし、誰かが気づく前に会社の財務上の真実は復元されていました。

エラーフリーなオーケストレーションのための推奨リソース

永続的実行の技術を極めたいのであれば、次の厳選された読書リストをお勧めします。

結論：アーキテクトへの新たな使命

グルーコード危機とは、移行期における一つの兆候です。私たちは「サイロとスクリプト」の世界から、「つながったエコシステム」の世界へと移行しつつあります。この新しい世界では、サービス間の接続は、サービスそのものと同じくらい重要です。

アーキテクトとしてのあなたの使命は、もはや信頼できるサービスを構築することだけではなく、信頼できる接続を構築することです。グルーコードは信頼性の対極にあるものです。それは一時的なパッチでありながら、必然的に恒久的な負担となります。今こそ、脆い配管を作るのをやめ、デジタル神経系を構築し始めるときです。

SchemaBridgeのような永続的なオーケストレーションエンジンを採用することで、あなたはエンジニアリングの未来を取り戻すことになります。自身の状態を認識し、失敗に対してレジリエントで、組織全体から可視化されたシステムを構築することになるのです。これこそが、あなたの速度を取り戻し、長く続くシステムを構築する方法です。

これは、「橋を架ける」をテーマにした全15回シリーズの第1回です。来週は第2回「速度のための設計」と、スキーマレスなイベント取り込みおよび遅延バインディング革命の力について探求します。ぜひご期待ください。

詳しく見る