ファンアウトを極める:大規模で耐久性のある冪等なワークフローを構築する

SchemaBridge Team · 2025-12-15 · Scalability, Idempotency, Orchestration

データ損失なしに1万件以上の子タスクを処理する。Spawner頂点を深掘りする。

1万件の壁:ループが死に至る場所

すべての開発者はループを書いたことがあります。Javaのforループであれ、JavaScriptの.map()であれ、Pythonのlist comprehensionであれ、ロジックは同じです。項目のリストを受け取り、それぞれに対して何かを行う。これはデータ処理の最もシンプルな形です。10項目の規模なら些細なことです。100項目の規模でも管理可能です。しかし、数千、そしてやがて数百万という規模の境界を越えると、この素朴なループはアプリケーションの信頼性とスケーラビリティにとって絶対的な死の罠と化します。

分散システムの世界では、ローカルなループは単一障害点です。10項目から1万項目へ移行すると、複雑さは単に線形に増加するのではなく、複雑性の壁に突き当たります。この壁は、メモリ管理、ネットワークレイテンシ、そしてコードを実行しているマシンの避けられない故障という、冷徹な現実によって築かれています。「ロジック」について考えることをやめ、「物理法則」と戦うことになるのです。

ローカルループの限界:なぜ`Promise.all`はプレスケールなのか

素朴な実装では、巨大なJSONペイロード――例えば1万件の注文が入った日次のCSVや、CRMからのバッチエクスポート――を受け取り、下流サービスへのAPI呼び出しをループで包んでしまうかもしれません。現代のJavaScript開発者なら、Promise.all()を使ってすべてを並列に発火させるかもしれません。これはプレスケール開発者が犯す最初の過ちです。

大規模になると、これは3つの重大な理由から大惨事となります。

1. メモリ枯渇:静かなるクラッシャー

1万件の複雑なオブジェクトをメモリに読み込むと、ワーカーが簡単にクラッシュしてしまいます。各オブジェクトがわずか10KBだとしても、生データだけで100MBになり、メモリを多く消費するランタイムでは500MB以上に膨れ上がる可能性があります。これは、最初の項目が処理される前にプロセスを殺してしまう、即座の「メモリ不足(OOM)」エラーです。

2. 実行タイムアウト:時計は刻み続ける

ほとんどのプラットフォームには厳格な制限があります。ループが1万回のAPI呼び出しを行い、各呼び出しがわずか100msかかるとすると、スクリプトの完了にはおよそ17分かかります。並列化したとしても、依然としてその単一コンテナのリソース制限とオーバーヘッドに縛られます。最後の項目が処理される前にプラットフォームによって終了させられ、システムは不確定な状態のまま残されてしまいます。

Spawnerの登場:マネージドで耐久性のあるファンアウト

SchemaBridgeでは、専用のSpawner頂点でこれを解決しました。Spawnerは単なるループではありません。それは分散オーケストレーションプリミティブです。ファンアウトをそれ自体マネージドなシステムとして扱い、汗ひとつかかずに任意の数のワーカーにまたがってスケールするよう設計されています。

Spawnerの実際の仕組み:並列分割

Spawnerはリストの取り込みと項目の実行を分離(デカップリング)します。これは負担をあなたのコードから私たちのインフラストラクチャへと移す、重要なアーキテクチャ上の転換です。

1. 耐久性のある発行: すべての項目について、一意な「子ワークフロー」イベントをSchemaBridgeの耐久性のあるタスクキューへ発行します。各発行はアトミックな操作であり、キューにコミットされるか失敗するかのいずれかであり、決して中途半端なイベントを生み出しません。

2. 意図の永続化: 各発行は親ワークフローの状態履歴(DynamoDB)に記録されます。Spawnerノードがループの途中で停止しても、新しいノードは履歴を参照し、正確に最後の項目から発行を再開するため、重複もスキップもゼロになります。

3. ライフサイクルの独立性: 各子項目はエンジン内の第一級市民になります。それぞれ独自のID、独自のリトライポリシー、独自のロギング、独自の状態を持ちます。501番目の項目が失敗しても、502番目の項目の成功を妨げることはありません。1つの巨大で壊れやすいバッチの代わりに、1万件の個別トランザクションの粒度を手に入れることができます。

並列性の経済学:マネージドなスケーリングがコストを削減する理由

15分間、重量級のシングルスレッドワーカーを走らせるのはコストがかかります。高メモリインスタンスの費用を支払うだけでなく、コードがAPIレスポンスを待つ間の「アイドル時間」にも費用を支払っていることになります。ネットワークI/Oの待ち時間のために課金対象のCPUサイクルを無駄にしているのです。

SchemaBridgeのSpawnerモデルでは、水平方向の効率性へと移行します。

並列実行: 1万件のタスクを1,000台のワーカーに分散させることができます。高価なマシン1台での15分を、安価なマシン1,000台での1分に変えることができます。
影響範囲の縮小: 1つのワーカーの障害は、他の999台に影響を与えません。従来のループでは、1つの項目でのメモリリークや未処理の例外が、1万項目すべての実行を殺してしまう可能性があります。

このアーキテクチャは、従来の長時間実行されるバッチスクリプトと比較してコンピューティングコストの削減をもたらしながら、桁違いの信頼性向上と100倍の可観測性を提供します。

分散ファンアウトにおけるExactly-Onceセマンティクス(EOS)

ファンアウトパターンにおける最大のハードルは冪等性です。Spawnerノードがループの途中で停止し、置き換えられた場合、最初の1,000件を再発行しないことをどう保証するのでしょうか?

SchemaBridgeは耐久性のある状態追跡を用いてこれに対処します。

発行ガード: 子タスクを発行する前に、エンジンは耐久性のある履歴を確認し、そのIDを持つイベントがすでに記録されているかを確認します。このチェックはキューへの書き込みの前にDynamoDBに対して行われます。
冪等性パススルー: (稀なネットワークパーティションが原因で)子タスクがワーカーによって2回受信された場合、実行エンジンは重複したIDを検出し、余分なリクエストを破棄します。

これにより、開発者が状態チェックのコードを一行も書くことなく、大規模でのExactly-Once処理が実現します。分散整合性が簡単に実現できるのです。

フォレンジックレポート:100万件の障害

私たちは最近、100万件の台帳エントリの重要なマイグレーションを行っていたフィンテック企業と協働しました。彼らは従来のPythonスクリプトを使うことを選びました。12時間かかる実行の途中で、VPN切断が発生しました。スクリプトはクラッシュしました。

リカバリ(高くつく方法)

3人のシニアエンジニアが復旧に48時間を要しました。彼らは宛先データベースをスキャンし、数百件のレコードを手動で照合しなければなりませんでした。

リカバリ(SchemaBridgeの方法)

1週間後、彼らはSchemaBridgeを使って別の100万件を実行しました。同じVPN切断が発生しました。

1. 耐久性のある一時停止: Spawnerはワーカーキューに到達できなくなったため、単に発行を停止しました。「待機」状態に入りました。

2. 自動再開: VPNが復旧すると、Spawnerは内部状態を確認し、50万番目の項目まで完了していたことを把握し、直ちに50万1番目の項目を発行しました。

3. 人間による可視性: チームはダッシュボード上でリアルタイムに進捗バーが再開するのを見守りました。コードは一行も書かれず、データベースクエリも一切手動で実行されることなく、マイグレーションは完璧に完了しました。

詳細比較:実世界でのスケーリングモデル

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

大規模オーケストレーションのためのエキスパートチェックリスト

大規模なファンアウトを設計する際は、私たちのDevRelチームによる以下の経験則に従ってください。

1. 並列度を厳密に定義する: データベースを保護するため、常にmax_concurrencyの上限を設定してください。低い値(例:10)から始め、下流の健全性を監視しながら増やしていきます。

2. 項目単位の失敗は正常であると想定する: リスト内の各項目が独立してリトライできるようにしてください。部分的な失敗による副作用をクリーンアップするため、項目ごとのSagaを使いましょう。

3. 「ロングテール」レイテンシを監視する: ダッシュボードを使って、平均よりも10倍長くかかる0.1%の項目を特定しましょう。これらは通常、最も複雑なエッジケースやデータベースロックのターゲットです。

4. 決定論的なIDを活用する: 再起動から保護するため、常にエンジン組み込みの連番IDを使いましょう。高並列のファンアウトにおいて、一意性のためにタイムスタンプに頼ってはいけません。

まとめ:スケーリングはインフラストラクチャの問題である

ファンアウトを極めるとは、より良いループを書くことではなく、分散を前提としたアーキテクチャ設計をすることです。反復、発行、永続化の複雑さをインフラストラクチャへ移すことで、「部分的な失敗」のリスクを排除し、10件を扱うのと同じ安全性で数百万件を扱えるパイプラインを構築できます。

2026年、スケーリングはもはや恐怖や48時間のフォレンジック調査の源であってはならず、設定によって解決済みの問題であるべきです。SchemaBridgeは不可能だったループを可能にし、昨日の技術的負債を抱えることなく、明日のグローバルスケールのシステムを構築できるようにします。

Part 4では「冪等性エンジン」を深掘りし、任意の数の並列ブランチにまたがって分散トランザクションを安全に保つ数学的パターンを探ります。ハッシュ衝突理論と、運用オーバーヘッドなしに「Exactly-Once」を保証する方法を見ていきます。