独自のバッチ-ストリーミング統合レイヤーを構築する際の隠れたコスト

Andrew Tan

独自のバッチ-ストリーミング統合レイヤーを構築する隠れたコスト

AI支援のコーディングにより、独自のデータパイプラインを構築することがこれまでになく安価に見えます。しかし、実際のコストは初期の構築にあるのではなく、メンテナンス、オンコールのローテーション、そして時間とともに複雑さが積み重なることにあります。

以下はよくある会話です：

エンジニアリングマネージャー: 「顧客分析プロジェクトのために新しいデータパイプラインが必要です。」

シニアエンジニア: 「それを構築できます。CursorとCopilotを使えば、コアロジックを数日で完成させることができます。」

EM: 「メンテナンスはどうしますか？」

SE: 「ただのPythonスクリプトとAirflowのオーケストレーションです。どれほど難しいでしょうか？」

3か月後、そのパイプラインを構築したエンジニアは休暇中で、パイプラインは静かに失敗しており、誰も顧客セグメントのカウントがソースシステムと一致しない理由を理解できません。「シンプルなPythonスクリプト」は2,400行に成長し、3つの異なるデータベースに触れ、ビジネスロジックが実際に何をするべきかについてのドキュメントは全くありません。

AIコーディング革命により、構築の決定はほとんど無料のように感じられます。しかし、変わっていないのは所有の決定であり、そこにこそ多くのコストが存在します。

正直な会計

チームが独自のData Integrationレイヤーを構築するコストを見積もるとき、通常は次のようなモデルを作成します：

12か月後の実際のスプレッドシートは次のようになります：

このギャップは、エンジニアが見積もりが下手だからではありません。スプレッドシートには、事前に見える作業しか記録されないからです。実際のコストは見えない形で蓄積されます：午前2時のページング、「一時的な修正」が恒久化すること、検出に数日かかる微細なデータ破損などです。

二重パイプライン問題

独自のバッチ-ストリーミングインフラストラクチャを構築するチームが直面する特定の障害モードがあります。それが分岐問題です。

まずはバッチから始めます。これは簡単です。毎時間実行されるジョブを書き、データを抽出し、変換し、どこかにロードします。うまく動作します。

次に、ビジネスからリアルタイムの要求が来ます。「このデータを数時間ではなく数秒で取得できますか？」

そこで、ストリーミングパイプラインを構築します。Kafka、あるいはFlinkやSpark Streamingを使うかもしれません。同じソースデータを消費し、同じ宛先に配信します。しかし、変換ロジックは異なります。ストリーミングには異なる制約、異なる状態管理、異なる障害モードがあります。バッチコードをそのまま移植することはできません。

これで、ほぼ同じことをする2つのパイプラインができました。バッチ結合が外部結合で、ストリーミング結合が内部結合であるため、あるいはバッチジョブが遅延データをストリーミングウィンドウとは異なる方法で処理するため、わずかに異なる結果を生成します。誰かがなぜ数字が一致しないのか尋ねたとき、両方のシステムをデバッグしなければなりません。

6か月後には、次のような状況になっています：

• メンテナンスが必要な2つのコードベース
• 監視が必要な2つのインフラストラクチャ
• 理解が必要な2つの障害モード
• 2つのオンコールローテーション（または非常に不満な1人）
• そして1つの持続的な疑問：なぜ1つのパイプラインだけではだめなのか？

正直な答え：バッチとストリーミングは本質的に異なるパラダイムであり、ほとんどのDIYスタックはそれらを統合するように構築されていないからです。

隠れた複雑性の乗数

明らかなコストを超えて、初期の見積もりには現れない3つの複雑性の乗数があります。

スキーマの進化

ソースシステムが変わります。列名が変更される。型が拡張される。新しいnullableフィールドが現れる。管理されたプラットフォームでは、これは処理されます。カスタムパイプラインでは、コードの変更、デプロイメント、そして下流の消費者を壊さなかったことを祈ることになります。

本当のコストは変更そのものではありません。それは調整です。このデータを消費するすべてのチームに通知し、スキーマを更新し、統合をテストし、何か問題があればロールバックすることです。2時間のコード変更が2週間のプロジェクトになります。

大規模な障害処理

単純なリトライループは簡単です。指数バックオフ、デッドレターキュー、いくつかのアラートを午後に構築することができます。

しかし、実際の障害処理はフラクタルです。宛先が1時間ダウンしたらどうなるか？メッセージが大きすぎる場合はどうなるか？スキーマの不一致が解析エラーを引き起こしたらどうなるか？同じイベントが2回配信されたらどうなるか？ネットワークの分断がスプリットブレインの状況を作り出したらどうなるか？

各エッジケースには処理が必要です。各ハンドラーにはテストが必要です。各テストにはメンテナンスが必要です。「単純なリトライロジック」は、チームの誰も深い専門知識を持っていない分散システムの懸念に成長します。

可観測性のギャップ

パイプラインが稼働しているかどうか、ソースに追いついているかどうか、イベントが処理されているかドロップされているか、レイテンシーはどのくらいか、エラーレートはどのくらいか、100万イベントあたりのコストはどのくらいかを知る必要があります。

この可視性を構築することは、単にメトリクスのエンドポイントを追加することではありません。適切なメトリクスを設計し、ダッシュボードを構築し、適切なアラートを設定し（騒がしすぎず、静かすぎず）、チームにそれを解釈する訓練をすることです。それは、構築し、維持し、デバッグするための別のシステムです。

実際に構築することが理にかなう場合

公平に言いたいと思います。独自の統合レイヤーを構築することが正しい選択となる状況もあります。

非常に具体的な要件がある場合 — 通常のベンダーでは対応できない、特殊なデータフォーマット、カスタムのセキュリティ制約、特異なデプロイメント環境など。

それを実現するチームがいる場合 — Kafkaを大規模に運用した経験があり、exactly-onceセマンティクスを理解し、午前3時にbackpressureの問題をデバッグしたことがある分散システムエンジニアがいる場合。

それが本当の差別化要因である場合 — データ処理レイヤーが単なるインフラではなく、あなたの製品の中核である場合。単なるパイプラインを構築しているのではなく、競争優位を築いているのです。

ベンダーのコストが構築コストを超える規模である場合 — ただし、「構築コスト」に含まれるものについては正直であるべきです。ほとんどのチームは2〜3倍過小評価しています。

その他のほとんどの人にとっては、所有コスト全体を考慮に入れると、通常は購入する方が有利です。

実際に重要なベンダー評価

ベンダーを比較する際、機能マトリックスから始めるのは間違いです。ほとんどのプラットフォームは、紙の上では似たような能力を持っています。重要なのは運用モデルです。

午前2時の問題をどのように処理するか？ 本番環境で何かが壊れたとき、誰が呼び出されるのか？あなたのチームが彼らのインフラをデバッグするのか、それとも彼らのチームがあなたのパイプラインをデバッグするのか？

離れる場合の移行パスはどうなっているか？ データパイプラインは粘着性があります。あなたのロジックを抽出して他の場所に移動するのにかかるコストを理解してください。

バッチとStreamingを統合しているか？ それとも結局、他の誰かのインフラで2つのパイプラインを持つことになるのか？

実際のTCOはどうか？ トレーニング、統合時間、必要な機能を待つコスト、プラットフォーム管理に費やされるエンジニアリング時間の機会コストを含めて考慮してください。

layline.io の位置付け

これは偏りのない見解だとは言いません。layline.io では、正直に評価を行い、構築することが正しい選択ではないと判断したチームのために特化したプラットフォームを構築しました。

基本的な考え方は、バッチ処理とストリーミング処理は別々のData Pipelineであるべきではないということです。それらは同じWorkflows、同じツール、同じチームであるべきです。リアルタイムが必要なときに、再構築するのではなく、設定を調整するだけで済みます。

運用上の負担は私たちが担います。スキーマの進化、障害処理、可観測性 — それはプラットフォームの仕事であり、あなたの仕事ではありません。あなたのチームは、分散システムの配管ではなく、ビジネスロジックに集中します。

自分で構築するよりも安価かどうか？それは、構築コストをどれだけ正直に評価するかによります。開発に2週間かかると見積もって、それで終わりとするなら、おそらく違います。オンコールのローテーション、メンテナンスの負担、スキーマのドリフトによるインシデント、そしてエンジニアが製品機能を構築しないことによる機会損失を含めるなら、通常はそうです。

問うべき質問

チームが構築に取り掛かる前に、次のことを尋ねてください。

「もしこれを自分たちで構築するなら、6か月後に壊れたとき、午前2時のページを誰が所有するのか？そして、その人は何にサインアップしているのかを理解しているのか？」

答えが明確で、全員がそのコミットメントを理解しているなら、構築を進めましょう。もし躊躇があったり、「後で考えよう」という答えなら、正直に計算をしてください。その数字に驚くかもしれません。

Andrew Tan はシリアルアントレプレナーであり、layline.io の創設者です。スケールでバッチおよびリアルタイムのワークロードを処理するエンタープライズデータ処理インフラを構築しています。