Andrew Tanによる
誰も移行予算に含めない費用 — そしてリアルタイム化の実際の価格がソフトウェアライセンスとは関係ない理由
最初の接触で生き残れなかった予算
私が知っているあるエンジニアリングのVPは、チームのバッチからストリーミングへの移行に180,000ドルの予算を組んでいました。それは12ヶ月前のことです。最後に話したとき、そのプロジェクトは640,000ドルを消費しており、まだ本番まで6週間かかる状態でした。
何が起こったのでしょうか？詐欺ではありません。従来の意味でのスコープの拡大でもありません。彼らは単にベンダーの見積もりに現れない費用を考慮しなかったのです：Kafkaエンジニアを雇うための6週間の遅れ、誰も新しいパイプラインを信頼していなかったためにバッチとストリーミングを並行して実行するのに費やした3ヶ月、ストリーミング集計がバッチレポートと異なる数値を出したときにCFOが気づいた緊急のコンサルティング契約。
ソフトウェア自体は安価でした。隠れた費用が彼らを食い尽くしました。
私はこのパターンがあらゆる規模の企業で繰り返されるのを見てきました。チームはインフラとライセンスの予算を組みます。しかし、不確実性、再作業、1つのシステムがもう1つに置き換わる間の運用税の予算は組みません。彼らが何が起こっているのかを理解する頃には、プロジェクトは予算オーバーか、期待以下の成果になっています — 時にはその両方です。
バッチからストリーミングに移行する際に実際に費用がかかるのはこれです。
費用#1: まだ持っていない才能
バッチエンジニアリングとストリームエンジニアリングは、大工仕事と家具作りが関連しているように関連しています。同じ原材料ですが、完全に異なる技術です。
あなたの既存のチームはcronスケジュール、テーブルスキャン、開始、実行、終了するジョブの安心感を知っています。ストリーミングは、イベント時間で考え、無限の状態を管理し、決して停止しないシステムをデバッグすることを求めます。あなたのエンジニアの中にはすぐに適応する人もいるでしょう。他の人はそうではありません — それは彼らが悪いエンジニアだからではなく、分散ストリーム処理が本当に難しく、誰もがそれを専門にしたいわけではないからです。
これにより、3つの形で隠れた費用が発生します：
採用: ロンドンやニューヨークのシニアストリーム処理エンジニアの基本給は現在160,000ドルから220,000ドルで、その専門分野の平均採用期間は4ヶ月です。もし2人必要なら、彼らが本番コードを1行も書く前に、給与でほぼ50万ドルになります。
トレーニング: 既存のエンジニアは、新しい概念を学ぶ必要があります：ウォーターマーキング、コンシューマーラグ、パーティションの偏り、ステートフルオペレーター、少なくとも一度対正確に一度。これらは午後のワークショップのトピックではありません。生産性が通常より低く、ミスが通常より高価な数ヶ月の実践的な学習です。
離職: 一部の優秀なバッチエンジニアは移行中に退職します — それは彼らがストリーミングを学べないからではなく、分散システムの専門家になるためにサインアップしたわけではないからです。彼らはデータ作業が好きでした。彼らはまだそれを楽しんでいる場所に行くでしょう。
ほとんどの移行計画の「才能」の予算項目はトレーニングをカバーしています。採用の遅れ、失われた生産性、予期しない離職はほとんどカバーしていません。
費用#2: 並行運用期間
これについて十分に話されていません。バッチを単にオフにしてストリーミングをオンにすることはできません。あなたの仕事を大切にするなら。
ある期間 — 通常は3〜6ヶ月、時にはそれ以上 — 両方のシステムを実行します。バッチパイプラインは、誰もが信頼するレポートを生成し続けます。ストリーミングパイプラインはその横で実行され、理論的には一致するはずの結果を生成しますが、少なくとも最初はそうではありません。
これはインフラの倍増を意味します。監視の倍増。アラートの倍増。そして、エンジニアのチームが新しい機能を構築する代わりに、2つの数字を調整する日々を過ごします。
私が関わったあるeコマース会社は、8ヶ月間並行システムを運用しました。彼らのバッチスタックはクラウドコンピュートで月額約4,200ドルかかりました。彼らのストリーミングスタックは月額7,800ドルかかりました。8ヶ月間、彼らは両方に支払いました。それだけでインフラだけで96,000ドルです — 火曜日の注文のストリーミングカウントがバッチカウントから347ずれている理由を調査するのに費やされたエンジニアリング時間は別として。
並行期間はオプションではありません。それは保険です。しかし、すべての保険と同様に高価であり、ほとんどのチームはその保険料を過小評価しています。
費用#3: データ考古学
あなたのバッチパイプラインには、何年にもわたって蓄積されたビジネスロジックが含まれています。午前2時に実行される400行のPythonスクリプトのどこかに、2019年の価格例外のために存在する結合条件があります。なぜそれがあるのか誰も文書化していません。それを書いた人は2021年に去りました。しかし、それを削除すると、収益の数字が0.3%変動し、財務部が怒りのメールを送ってきます。
ストリーミングへの移行は、これらのアーティファクトをすべて理解することを意味します。コードを単に移植することはできません。ロジックは連続イベント処理のために再実装する必要があり、それはまずそれが何をしているのか、なぜそれをしているのかを理解することを意味します。これはデータ考古学です — 退屈で、遅く、正確に見積もることが不可能です。なぜなら、掘り始めるまで何が見つかるかわからないからです。
私がアドバイスしたある金融サービス会社は、単一のパイプラインに5週間を費やしました。ストリーミング実装は3日間かかりました。バッチバージョンが特定のコーナーケースの出力を生成する理由を理解するのに他の32日間かかりました。ビジネスロジックは、4年間にわたって3人の異なる人によって書かれたストアドプロシージャにエンコードされており、「Q2のバグ修正」といったコメントがあるだけで、さらなる説明はありませんでした。
費用#4: 運用の複雑さ税
バッチパイプラインは目に見えて失敗します。ジョブがクラッシュします。アラートが届きます。それを修正します。それを再実行します。何が起こったのか誰もが理解しています。
ストリーミングパイプラインは微妙に失敗します。コンシューマーラグが数時間かけて蓄積します。ステートストアが成長してメモリ制限に達します。ウォーターマークが漂流し、突然ウィンドウ集計が遅延イベントを落とし始めます。気づいたときには、半日間わずかに間違った結果を生成していました。
運用ツールも異なります。ジョブが終了したかどうかを監視するだけではありません。レイテンシー分布、スループットの傾斜、Backpressure信号、ステートストアのサイズを監視しています。既存のランブックは適用されません。既存のアラートは新しい故障モードをキャッチしません。
この運用の成熟度を構築するには時間とミスが必要です。ストリーミングパイプラインが6時間にわたってイベントの2%を静かにドロップした最初のとき、あなたはより良い可観測性に多額の投資をするでしょう。それは必要な費用です。しかし、最初の予算にはほとんど含まれていません。
費用#5: 誰も測定しない機会費用
あなたの最高のエンジニアがパーティションの再バランスをデバッグし、バッチとストリーミングの出力を調整している間、彼らは他の作業をしていません。機能要求が積み重なります。技術的負債が蓄積します。競合他社は、あなたのチームが移行に没頭していなければ構築していたであろうものを出荷します。
これは最も測定が難しく、最も無視しやすい費用です。これには請求書はありません。しかし、それは現実です。
あるSaaS会社は、ストリーミング移行中にすべての新しいデータ製品開発を9ヶ月間停止しました。終了したときには、技術的に印象的なリアルタイムパイプラインを構築していました — しかし、その間に主要な競合他社は3つの分析機能を出荷し、市場シェアを獲得しました。移行は技術的には成功でしたが、戦略的には遅れでした。
なぜ過小評価し続けるのか
問題の一部はベンダーメッセージングです。ストリーミングプラットフォームは目的地を売ります：リアルタイムの洞察、即時の反応、競争上の優位性。彼らは旅を宣伝しません：採用、並行システム、考古学、運用の学習曲線。
もう一つの部分は楽観バイアスです。すべてのエンジニアリングチームは、自分たちが例外になると信じています。彼らのコードはクリーンです。彼らのチームは賢いです。彼らの要件は単純です。時にはそれが真実です。通常はそうではありません。
その結果、予算化されたコストと実際のコストの間に持続的なギャップが生じます。私は2:1、3:1、さらには5:1の比率を見てきました。誰かが不誠実だったからではなく、実際のコストがすでにコミットした後でしか見えないからです。
正直に予算を立てる方法
これらの費用を排除することはできませんが、それを考慮に入れることはできます。私がチームにアドバイスする方法は次のとおりです：
インフラの見積もりに40%のバッファを追加します。並行期間、テスト環境、シャドウデプロイメント — これらはすべて、正確に予測できないコンピュートとストレージを追加します。
最低でも6ヶ月の二重運用を予算に組み込みます。早く終わったら祝ってください。そうでなければ、CFOにオーバーランを説明する必要はありません。
開始前にストリーミングスペシャリストを1人雇用または契約してください。詰まった後で彼らを呼び込むコストは高いです。3ヶ月の誤ったスタートの後で彼らを呼び込むコストはさらに高いです。
一部のパイプラインはバッチのままにしておくことを受け入れます。すべてがリアルタイムから利益を得るわけではありません。日次レポート、履歴分析、MLトレーニングパイプライン — これらはしばしばバッチに適したワークロードであり、移行コストを正当化しません。何を移行しないかを明示的にしてください。
移行を考える別の方法
これをうまく処理するチームには1つの特徴があります：それを移行としてではなく、能力の追加として見ています。
「バッチからストリーミングに移行している」のではなく、「価値を生む場所にストリーミングを追加し、まだ機能している場所にバッチを保持している」と言います。これは言葉遊びのように聞こえますが、経済を完全に変えます。すべてを移動することにコミットするのではなく、各パイプラインをそのメリットに基づいて評価できます：レイテンシー要件、複雑さ、ビジネス価値、移行コスト。
一部のパイプラインは移動します。一部は移動しません。移動するものはその投資を正当化します。残るものは不要なコストを生み出しません。
ここで統一プラットフォームが重要です。バッチとストリーミングのために別々のツールを使用している場合、すべてのパイプラインが移行の圧力にさらされます。なぜなら、2つのプラットフォームを維持することは高価だからです。もし同じプラットフォームで両方のモデルを実行できるなら — 同じWorkflows、同じチーム、同じ運用アプローチ — 圧力は消えます。価値を生む場所にリアルタイムストリーミングを追加し、すでに機能している場所にバッチをそのままにしておきます。
これがlayline.ioに組み込んだアプローチです。バッチが悪いからではなく — それはしばしば正しい — 1つのアプローチを選び、他を放棄することが人工的なコストとリスクを生むからです。夜に安心して眠れるチームは、海を沸かそうとしなかったチームです。
結論
バッチからストリーミングに切り替える隠れたコストはソフトウェアではありません。それは他のすべてです：雇う必要のある人々、並行して運用する必要のあるシステム、発掘する必要のあるレガシーロジック、構築する必要のある運用の成熟度、インフラに集中している間に失う機会です。
それを予算に組み込み、考慮し、実際に移動する必要のあるパイプラインとそうでないものを正直に見極めてください。
目標はどこでもリアルタイムになることではありません。目標は、破産せずにリアルタイムが重要な場所でリアルタイムになることです。
次に何をするか
バッチからストリーミングへの移行を計画している場合は、正直な監査から始めてください。トップ10のパイプラインをリストアップします。それぞれについて、レイテンシーの実際のコストは何か？移行の推定努力は何か？運用の複雑さの追加は何か？
もし特定のパイプラインの移行が数字で正当化されない場合、それをそのままにしておいてください。リアルタイムが測定可能なビジネス価値を生む2つまたは3つにエネルギーを集中してください。
プラットフォームを評価しているチームには、layline.ioのCommunity Editionが無料で利用できます。既存のバッチWorkflowの横でストリーミングパイプラインをプロトタイプし、予算をコミットする前に運用の現実を確認できます。
Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムの両方のワークロードをスケールで処理するエンタープライズデータ処理インフラを構築する連続起業家です。
