Andrew Tanによる
ニアリアルタイムと実際のリアルタイムの違い、そしてそのギャップが思った以上にコストをかける理由
€4.7百万の遅延
ある大手ヨーロッパの小売業者は、2024年のブラックフライデーに€4.7百万を失いました。ウェブサイトがクラッシュしたわけでも、在庫がなくなったわけでもありません。彼らの「リアルタイム」在庫システムが4時間遅れていたためです。
340,000人の顧客がすでに売り切れた商品の注文をしました。システムは在庫があると表示していましたが、倉庫にはありませんでした。矛盾が表面化した時には、すでに手遅れでした。返金が行われ、カスタマーサービスは圧倒され、ブランドの評判は傷つきました。事後分析で明らかになったのは、パイプラインがリアルタイム用に設計されていなかったということでした。それは「ニアリアルタイム」として設計されており、建築レビューでは技術的に聞こえた区別が、実際には生産において壊滅的な結果を招いたのです。
この話のバージョンを何度も聞いたことがあります。「リアルタイム」が約束するものと、ほとんどのシステムが提供するものの間のギャップは、多くのチームが認識しているよりも広いのです。そして、顧客の期待が加速するにつれて、そのギャップは狭まるどころか広がっています。
フォーミュラ1のピットストップのように、リアルタイムデータ処理には精密さ、調整、適切なインフラが必要です。
「リアルタイム」が実際に意味すること（そしてしないこと）
業界はこの水を濁しています。3つのカテゴリーが同じラベルの下で混同されています。
バッチは更新間隔が数時間または数日です。夜間のETLジョブや週次レポートがこれに当たります。明確な境界、予測可能なウィンドウ、よく理解された失敗モードがあります。
ニアリアルタイムは更新間隔が数分です。システムは5分、15分、30分ごとにチェックします。ほとんどの「リアルタイムダッシュボード」はここに該当します。多くのユースケースに適していますが、最も重要なものには適していません。
リアルタイムは秒またはサブ秒です。イベントが発生し、システムが知り、下流のアクションが即座にトリガーされます。
小売業者にはリアルタイムの問題はありませんでした。彼らにはニアリアルタイムシステムがリアルタイムとしてマーケティングされており、その違いを誰も疑問視しなかったため、4百万ユーロの損失を被ったのです。
シフトを促す3つの力
Amazon効果。顧客はすべてが即座に行われることを期待しています。技術的要件を分析したからではなく、それが期待されるように訓練されてきたからです。2022年のShopifyの12,000人の消費者を対象とした調査では、73%がチェックアウト、在庫、出荷の更新をリアルタイムで期待していることがわかりました。「1時間以内」ではなく、リアルタイムです。
運用ウィンドウが縮小しています。取引後の不正検出は検出ではなく通知です。お金はすでに失われています。バッチ品質レポートを待つ製造ラインは、誰かが気づくまで何時間も不良品を生産します。遅延のコストは、ほとんどのスプレッドシートが捉えるよりも速く複利で増加します。
競争圧力。競合他社が30秒ごとに価格を更新し、あなたが6時間ごとに更新する場合、あなたは競争しているのではなく、観戦しています。これは理論的な話ではありません。eコマースプラットフォーム、旅行アグリゲーター、金融サービス。これらの分野で勝利している企業は、リアルタイムデータインフラを戦略的優先事項とし、技術的な必需品ではないとしています。
制御なしのスピードは危険です。リアルタイムシステムは、速度を処理しながら精度と信頼性を維持する必要があります。
隠れた複雑さ
バッチからストリーミングへの移行は見た目よりも難しいです。表面上は単純に見えますが、待つ代わりに即座に反応します。しかし、内部ではすべてが変わります。
状態管理。バッチジョブは境界のあるデータセットを処理します。開始時に入力サイズがわかります。ストリーミングは境界のないストリームを処理します。ウィンドウを追跡し、遅れて到着するデータを処理し、順序が異なる可能性のあるイベント間で状態を管理する必要があります。
正確に一度の処理。バッチジョブを誤って2回実行すると、重複した出力が得られ、それを修正して進むことができます。ストリーミングパイプラインを2回実行すると、顧客に二重請求し、在庫を二重にカウントし、システムに二重通知します。意味論が以前とは異なる方法で重要になります。
Backpressure。ソースがシンクよりも速く生成する場合はどうなりますか？バッチでは、これは遅いジョブとして現れます。ストリーミングでは、メッセージがドロップされ、連鎖的な失敗が発生し、システムが応答を停止することがあります。
これらは珍しいエッジケースではありません。これが日常です。この複雑さを過小評価するチームは、デモでは機能するが、本番では失敗するパイプラインを持つことになります。
良い例
良く設計されたリアルタイムシステムには共通の特性があります。
デフォルトでの回復力。後付けではありません。システムはコンポーネントが失敗することを想定し、動作を続けます。サーキットブレーカー。優雅な劣化。負荷を軽減するための制限付きキュー。
観測可能。毎秒数千のイベントを処理するパイプラインで何が起こっているかを知る必要があります。重要なメトリクス。システムを通じてイベントを追跡するトレーシング。コンポーネントの失敗だけでなく、症状に基づいてアラートを発すること。
成長対応。1分間に1万件のイベントを処理するシステムは、再設計なしで1千万件を処理できるべきです。水平スケーリング。パーティション対応の設計。単一の競合ポイントがないこと。
アクセス可能。リアルタイムデータ統合は、分散システムの博士号を必要とすべきではありません。ツールは存在します。ドキュメントは明確です。概念は学習可能です。チームは四半期ではなく、数日で生産的になるべきです。
この最後のポイントは他のものよりも重要です。リアルタイムインフラストラクチャで成功するチームは、最も洗練された技術を持つチームではありません。既存のチームが運用できるように十分にアプローチしやすくしたチームです。
アクセシビリティのギャップ
2つの層の市場が形成されています。第1層：専用のストリーミングチームを持ち、Kafkaの専門知識を持ち、パーティションのリバランスと正確に一度のセマンティクスを理解するインフラエンジニアを持つ企業。第2層：リアルタイムが試みるには複雑すぎると感じているため、バッチに留まっている他のすべての企業。
これは逆です。リアルタイムデータ統合はバッチ処理と同じくらいアクセス可能であるべきです。同じチーム。同じスキルレベル。同じ生産までの時間。技術はそこにあります。欠けているのはパッケージングです。チームが複雑さを処理しなくても済むようにするツールです。
layline.ioでは、第2層のために構築しています。バッチとストリーミングの両方を同じインターフェースで処理する統合されたWorkflows。組み込みの回復力と観測性。自動的にスケーリングが行われます。ストリーミングを簡単にすることが目標ではありません。それは複雑であり、そうでないふりをすることは誰の助けにもなりません。目標はそれをアクセス可能にすることです。
リアルタイムデータを必要とする小売業者、製造業者、金融サービス企業はすでに優秀なチームを持っています。彼らは異なる人々を必要としているのではありません。より良いツールを必要としているのです。
Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムの両方のワークロードをスケールで処理するエンタープライズデータ処理インフラストラクチャを構築しています。
