Andrew Tanによる
昨年のカンファレンスで、あるデータアーキテクト — フォーチュン500、ビッグチーム、真剣な予算 — が私を呼び止め、今では何度も聞いたことのある話をしてくれました。
彼らは14か月をかけてKafkaに移行しました。新しいチームを雇い、新しいインフラを立ち上げ、全く新しいオンコール体制を構築しました。すべてを行いました。
ローンチから6か月後、彼らは静かにパイプラインの半分をバッチに戻しました。
Kafkaは壊れませんでした。正常に動作していました。問題はそれよりも単純でした：誰もリアルタイムデータを使用していなかったのです。ダッシュボードは依然として午前9時にチェックされ、レポートは週次で実行され、MLモデルは夜間に再トレーニングされました。彼らは食料品店に行くためにフォーミュラ1カーを作ったようなものでした。
千の移行を生んだカンファレンストーク
通常、こうして始まります。チームの誰かがカンファレンストークを見ます — おそらくYouTubeで2倍速で — FAANGのエンジニアがリアルタイムパイプラインを説明します。毎秒数十億のイベント。サブミリ秒のレイテンシー。ダッシュボードがマトリックスのように更新されます。
そのエンジニアはインスパイアされてオフィスに戻ります。「これをやるべきだ。」チームはうなずきます。CTOは四半期のロードマップに「リアルタイム」という言葉を愛しています。Jiraのエピックが生まれます。
誰も尋ねません：この建物の誰かが、今日よりも速くデータを必要としているのか？
「それがあればいいな」ではなく、「それがもっとモダンに聞こえる」でもなく、特定の人が、特定の決定を下す際に、データが1時間古いのではなく1秒古いことで、測定可能な悪化があるのか？
10回中9回、正直な答えはノーです。そして1回のイエスの場合、それは通常1つのパイプラインであり、プラットフォーム全体ではありません。
食料品リスト
何かを移行する前に、リストを作成してください。本気です — スプレッドシートを開いてください。各パイプラインについて、3つの質問に答えてください：
このデータを消費するのは誰か？ 名前。チーム。システム。消費者を名指しできない場合、そのパイプラインは存在する必要がないかもしれませんし、ましてやリアルタイムである必要はありません。
彼らはそれをどう使い、いつ使うのか？ 答えが「毎朝ダッシュボードをチェックする」や「金曜日にレポートにフィードする」であれば、Streamingは結果を変えません。同じ水のために配管を高価にしているだけです。
このデータが1時間遅れたら何が壊れるか？1日遅れたら？ これはバッチとStreamingを実際に分ける唯一の質問です。どちらの答えも「特に何もない」なら、バッチのワークロードがStreamingのコスチュームを着ているだけです。
ほとんどのチームは、パイプラインの80％がバッチで完全に問題ないことを発見します。残りの20％が興味深い部分です。
速度が実際に重要な場所
一部のデータは本当に腐ります。ワインではなく牛乳のように。
不正検出は明らかな例です。クレジットカード取引が5分後にフラグされても、それは不正検出ではなく、不正通知です。お金はすでに失われています。不正のパイプラインがバッチで実行されている場合、謝罪の手紙を書く代わりにドアをブロックしています。
私たちの不正検出ソリューションは、サブ100msのレイテンシーでリアルタイムスコアリングを行います。
運用アラート — IoTセンサーがタービンの過熱を知らせる場合、その情報の賞味期限は秒単位です。ここでの毎時バッチジョブは遅いだけでなく、怠慢です。
競争市場での価格設定と在庫。競合他社が30秒ごとに価格を更新し、あなたが6時間ごとに更新する場合、競争しているのではなく、観戦しているだけです。
複数消費者のイベントストリームでは、経済が複合されます。1つのKafkaトピックが3つの下流システムにフィードする場合、同じデータベースから引っ張る3つの別々のバッチジョブよりも安価です。Streamingは速度ではなく、アーキテクチャの優雅さを通じてその価値を証明します。
パターンは次の通りです：どのケースでも、遅延には特定の、測定可能なコストがあります。漠然とした感覚ではなく、数字です。
Jiraエピックに載らないコスト
Streamingインフラストラクチャには、ベンダースライドでは素晴らしく見えるが、Q3の実績ではひどい価格モデルがあります。
24/7で動作します。 バッチジョブは4時間動作し、休みます。Streamingジョブは一日中、夜中、週末、祝日も動作します。データ量が同じでも、コンピュートの請求は異なります。あるチームは、月額$2,000のバッチ設定から、同じデータを処理し、同じ場所に届け、同じペースで消費するために、月額$11,000のStreamingに移行しました。
デバッグは考古学から量子物理学に変わります。 バッチジョブが失敗すると、スタックトレース、悪いレコード、明確な再実行パスが得られます。Streamingジョブが間違った出力を生成すると、まったく「失敗」しないかもしれません。ただ静かに下流にゴミを送り続け、誰かが収益ダッシュボードが変だと気づくまで3日かかります。
スキーマの変更は外交交渉になります。 バッチでは、コードをバージョン管理し、履歴データでテストし、プッシュします。Streamingでは、フィールドを変更することは、ライブシステム上で全てのプロデューサーとコンシューマーを同時に調整することを意味します。順序を間違えると、午前2時にデータ破損をデバッグすることになります。
オンコール税は現実です。 コンシューマーラグ、パーティションスキュー、ブローカーフェイルオーバー — これらは珍しいエッジケースではなく、火曜日です。チームがすでに手一杯の場合、Streamingは問題を解決しません。それを倍増させます。
実際に役立つフレームワーク
ここで私が推奨するのは、適切な人々が部屋にいるときに約2時間かかります。
ステップ1: 決定を名付ける。 各パイプラインについて、それがサポートする具体的なビジネス決定を特定します。「分析」ではなく、実際の決定です。「この取引を承認または拒否する。」「このSKUを再注文する。」「メンテナンスクルーに警告する。」名付けられない場合、バッチで十分です。
ステップ2: 決定のタイミングを計る。 その決定はどのくらいの頻度で行われますか？毎秒？毎時？毎週月曜日？パイプラインのペースを決定のペースに合わせます。毎日の決定に対するサブ秒の配信は無駄です。
ステップ3: 遅延の価格を設定する。 1時間の遅延がどれだけのコストになるか、ドルで表します。これは最も難しく、最も重要な質問です。答えが「わからない」または「おそらく何もない」場合、Streamingのユースケースはありません。Streamingの願望があります。
ステップ4: 1つから始める。 最も明確な遅延コストを持つパイプラインを選びます。それを移行します。バッチバージョンと並行してフルサイクルを実行します。比較します。壊れたものを修正します。それから拡大するかどうかを決定します。
このプロセスをうまく行うチームは通常、2〜3のStreamingパイプラインと15のバッチパイプラインを持ちます。このプロセスをスキップするチームは、18のStreamingパイプライン、燃え尽きたオプスチーム、そして6か月後に静かにバッチに戻る移行を持ちます。
それはどちらか一方ではない
ほとんどのStreamingベンダーが教えてくれないことは、最良のデータアーキテクチャは退屈であるということです。それらはすべてStreamingでもすべてバッチでもありません。それらは、データが実際に何をする必要があるかに基づいて、パイプラインごとに選ばれたミックスです。
レポートにはバッチ。MLトレーニングにはバッチ。「日次」で十分で、シンプルさがオプスのオーバーヘッドを月に$8,000節約する場合にはバッチ。
不正にはStreaming。運用アラートにはStreaming。遅延にドル記号が付いている数少ないパイプラインにはStreaming。
これがまさに私たちがlayline.ioをこのように構築した理由です。それはバッチとStreamingの両方を同じプラットフォームで処理します — 同じWorkflows、同じツール、同じチーム。1つの世界を選んで他を放棄する必要はありません。持っているものから始め、リアルタイムをその価値があるところに追加し、意味があるところにバッチを保持します。リップアンドリプレースはありません。どちらか一方もありません。
アーキテクチャの図はカンファレンストークで勝つことはありません。しかし、チームは午後5時に帰宅し、オンコールのローテーションは実際に夜中に眠ります。
それがスケールする退屈さです。
どのパイプラインがリアルタイムに属し、どのパイプラインがバッチで完全に問題ないかを評価している場合、layline.ioは単一のプラットフォームで両方を実行できるため、インフラストラクチャをコミットする前にビジネスケースを検証できます。あなたの特定のアーキテクチャについてお問い合わせください。
Andrew Tanはシリアルアントレプレナーであり、layline.ioの創設者であり、バッチとリアルタイムのワークロードをスケールで処理するエンタープライズデータ処理インフラを構築しています。
