Andrew Tanによる
ストリーム処理アプローチの実用的な比較 — レイテンシー、運用の複雑さ、そして実際に正しい選択を決定するチーム適合性をカバー
終わらない会議
昨年、私はKafkaについて数ヶ月間議論していたチームと会議室に座っていました。データをストリーミングするかどうかではなく、その決定はすでに下されていました。彼らは、3人のインフラエンジニアを雇うことなく、実際にKafkaを本番環境で運用できるかどうかを議論していました。
アーキテクトはKafkaが大好きでした。彼は以前の会社でそれを使用しており、その能力を知っていました。エンジニアリングマネージャーは懐疑的でした。彼女は、消費者グループの調整に四半期を費やしても、正確な一度だけのセマンティクスを得られなかったチームのポストモーテムを読んでいました。CTOはただ出荷したかったのです。プロジェクトはすでに予定より遅れていました。
3時間目には、昼食が必要だということ以外は何も合意に至っていませんでした。
これがKafkaの決定の要約です。それは技術の問題ではありません。それは適合性の問題です。Kafkaは、人々が認めるよりも頻繁に正しい答えです。また、人々が認めるよりも頻繁に間違った答えです。違いは機能マトリックスにはありません。それは、あなたのチームが実際に得意なこと、あなたのワークロードが実際に必要とすること、そして運用上所有することをいとわないことにあります。
Kafkaが実際に得意なこと
多くの比較がこの部分を飛ばしてしまうので、まずKafkaが非常に得意なことから始めましょう：
Kafkaは分散イベントログです。その核心のスーパーパワーは、スケールでの耐久性です。Kafkaに毎秒何百万ものイベントを投入し、それらをクラスター全体に分散させ、複数の消費者から順番に読み戻すことができます。消費者が速いか遅いかは気にしません。クラッシュして再起動しても気にしません。イベントは期限が切れるまでそこに残ります。
これにより、以下の場合にKafkaが適した選択肢となります：
- 中央神経系が必要な場合: 複数のチームが同じイベントを消費する必要があります。マーケティングはクリックストリームを必要とし、分析は集計を必要とし、運用はアラートを必要とします。Kafkaはプロデューサーを消費者から切り離すので、各チームはデプロイメントを調整することなく自分のペースで読むことができます。
- 耐久性がレイテンシーよりも重要な場合: Kafkaは最速のメッセージブローカーではありません。ほとんどのユースケースには十分速いですが、マイクロ秒が重要な高頻度取引を行っている場合は、他を探すでしょう。Kafkaが輝くのは、イベントが一度確認されると、複数のディスク障害やノードクラッシュを生き延びることを保証することです。
- チームがすでに分散システムを理解している場合: Kafkaは忘れ去られるマネージドサービスではありません。Confluent Cloudのようなマネージドオファリングでも、パーティションのリバランス、消費者グループの調整、オフセット管理、レプリケーションが失敗する微妙な方法を理解する人が必要です。これらの人々がいる場合、Kafkaは力を倍増させます。いない場合、それは時間の無駄です。
Kafkaが高価になるところ
Kafkaの隠れたコストはライセンスではありません。それは運用の専門知識です。
私は、Kafkaを本番で安定させるのに9ヶ月を費やしたチームと話しました。ソフトウェアが悪いからではありません—それは優れています—しかし、運用の表面積が非常に大きいからです。遅延を監視し、パーティションをバランスし、バッチサイズを調整し、スキーマの進化を管理し、午前2時に消費者のリバランスをデバッグする必要があります。これらは一度きりのセットアップタスクではありません。それらは継続的な運用責任です。
ストリーム処理レイヤーは別の次元を追加します。Kafka自体はイベントログです。これらのストリームを変換、集約、または結合したい場合は、ストリームプロセッサが必要です：Kafka Streams、Flink、ksqlDB、またはSpark Streaming。これらのそれぞれは、それ自体が重要な技術です。あなたは単にKafkaを運用しているのではありません。ストリーミングスタックを運用しているのです。
これは小規模なチームにとって痛みを伴う決定です。彼らはリアルタイム処理を望んでいます。彼らはイベント駆動型アーキテクチャを必要としています。しかし、彼らにはKafkaクラスターとFlinkジョブクラスターを監視するプラットフォームエンジニアリングチームがいません。彼らにはAPIとデータベースも維持する5人のバックエンドエンジニアがいます。
layline.ioが異なること
私たちはまさにそのような状況にあるチームのためにlayline.ioを構築しました。Kafkaが悪いからではなく、完全なKafka + ストリームプロセッサスタックが多くのワークロードにとって過剰であり、それを選択するチームにとってリソース不足だからです。
layline.ioは統合データ処理プラットフォームです。バッチとストリーミングの両方のワークロードを同じWorkflows、同じビジュアルデザイナー、同じ運用モデルで処理します。バッチETLとリアルタイムストリーミングのために別々のツールは必要ありません。別々の専門知識を持つ別々のチームも必要ありません。
主な違いは3つに集約されます：
1. 運用の抽象化
Kafkaではインフラを運用しています。layline.ioではWorkflowsを運用しています。プラットフォームはパーティショニング、状態管理、チェックポイント、backpressureを自動的に処理します。パイプラインを視覚的に設計し、デプロイし、同じインターフェースで監視します。運用の表面積ははるかに小さいです。
これはlayline.ioが「複雑さのないKafka」という意味ではありません。エンジンは多くの同じ分散システムの問題を内部で処理します。違いは、それを自分で処理する必要がないということです。専任のインフラエンジニアがいないチームにとって、これは数週間で出荷することと数四半期で出荷することの違いです。
2. 統一されたバッチとストリーミング
ほとんどの現実の環境では両方が必要です。リアルタイムの不正検出が必要です。また、日次の調整レポートも必要です。ストリーミングアラートが必要です。また、月次の分析エクスポートも必要です。
Kafka中心のスタックでは、通常、2つの別々のシステムが必要になります：ストリーミング用のKafka + Flink、バッチ用のAirflowまたはdbt。2つのコードベース。2つの運用モデル。2つの専門知識のセット。
layline.ioは同じプラットフォームで両方を実行します。同じワークフローがバッチファイルやストリーミングトピックを処理できます。同じチームが両方を構築し運用できます。ストリーミングとバッチのチームを別々に正当化するほど大きくない組織にとって、これは大きな簡素化です。
3. ビジュアルワークフローデザイン
これは機能のように聞こえますが、実際にはコラボレーションの問題です。データパイプラインがJavaやScalaで書かれ、Gitリポジトリに存在する場合、それを変更できるのはそれを書いたエンジニアだけです。ビジネスアナリスト、データサイエンティスト、運用チームはブロックされます。
layline.ioのVisual Workflow Designerはデータフローを明示的にします。非エンジニアでも読めます。エンジニアは、何千行ものストリーム処理コードを探し回ることなくそれを変更できます。実際には、ビジネスロジックを理解している人とインフラを維持する人の間の誤解が少なくなります。
決定フレームワーク
実際の選択について私が考える方法は次のとおりです。
Kafkaを選ぶとき
- 複数のチームが独立して消費する会社全体のイベントバスが必要
- 深いKafka運用経験を持つエンジニアがいる（または雇える）
- 別のバッチスタックをすでに運用しており、両方を維持することを気にしない
- ワークロードが主にイベントストリーミングで、比較的単純な変換を伴う
- 耐久性とデカップリングが生産までの時間よりも重要
layline.ioを選ぶとき
- バッチとストリーミングの両方が必要で、両方に対応する1つのプラットフォームが欲しい
- チームが小さく、インフラ運用に専念するエンジニアを割り当てられない
- パイプラインが複雑な変換、強化、ルーティングを含む
- ビジネスチームと技術チームがパイプラインデザインで協力する必要がある
- 生産までの時間と運用の簡素化が生のスループットと同じくらい重要
両方を一緒に使用するとき
- Kafkaがすでに中央のイベントログであるが、その上でWorkflowsを構築するためのよりアクセスしやすいレイヤーが必要
- Kafkaを耐久性のあるメッセージバスとして維持しつつ、layline.ioを複雑なストリーム処理、変換、バッチオーケストレーションに使用したい
このハイブリッドパターンは人々が思っているよりも一般的です。Kafkaはイベントを耐久的に移動するのに優れています。layline.ioはそれらを処理するのに優れています。両者はお互いをきれいに補完します。
実際の例
私たちが関わった中規模のフランチャイズは、まさにこの決定を下しました。彼らは不正検出をリアルタイムに拡張していました。イベントは支払いプロセッサから来ており、顧客データベースからの強化が必要で、200ミリ秒以内にリスクスコアリングをトリガーする必要がありました。
彼らの最初の計画はKafka + Flinkでした。アーキテクチャはホワイトボード上ではクリーンに見えました。しかし、3ヶ月後、彼らはFlinkのチェックポイント調整とKafkaの消費者遅延のデバッグに80％の時間を費やし、実際の不正ロジックに20％の時間を費やしていることに気付きました。
彼らはハイブリッドアプローチに切り替えました。Kafkaはイベントログとして残りました—それはすでに彼らの支払いプロセッサと統合されていました。layline.ioは強化、スコアリング、アラートワークフローを処理しました。チームはインフラにほとんどの時間を費やすことから、不正モデルにほとんどの時間を費やすことに移行しました。
興味深い部分は？彼らのレイテンシーは増加しませんでした。場合によっては減少しました。なぜなら、予測不可能性を追加する運用火災と戦っていなかったからです。変わったのは、彼らのエンジニアリング努力がどこに向けられたかです。
多くのチームが犯す間違い
私が見る最大の間違いは、ベンチマークや機能リストに基づいて技術を選ぶことです。
Kafkaはベンチマークでlayline.ioを生のスループットで打ち負かします。唯一の基準が毎秒のイベント数であるなら、Kafkaが勝ちます。しかし、生のスループットがプロジェクトの成功を決定するわけではありません。成功を決定するのは、チームがシステムを構築し、運用し、数年間にわたって進化させることができるかどうかです。
私は、「Netflixが使用しているから」という理由でKafkaを選び、その後Netflixのプラットフォームエンジニアリング組織を持っていないために苦労するチームを見てきました。学びやすいからという理由で軽量ツールを選び、エンタープライズグレードの耐久性が必要になったときに壁にぶつかるチームも見てきました。
正しい質問は「どちらが優れているか？」ではありません。正しい質問は「私たちのチーム、制約、タイムラインを考慮した場合、どちらが私たちにとってより良いか？」です。
結論
Kafkaは素晴らしいエンジニアリングの成果です。適切なチームと適切なワークロードにとって、それは無類のものです。しかし、それは普遍的な答えではなく、それが多くのチームに多くの寝不足の夜をもたらしたことを装うことはできません。
layline.ioは、リアルタイムデータ処理を必要としながら、完全なKafka + Flinkスタックの運用オーバーヘッドを正当化できない多くの中間層のチームのために存在します。彼らはストリーム処理の結果を必要としていますが、分散システムの専門家になる必要はありません。
どちらのツールも銀の弾丸ではありません。どちらも設計されたことに優れています。芸術は、どちらがあなたの現実に合っているかを知ることです。
次のステップ
ストリーム処理プラットフォームを評価している場合、最良の次のステップは簡単な監査です。上位3つのユースケースをリストアップします。レイテンシー要件を見積もります。チームの運用帯域幅について正直に評価します。それから、他の誰かが行ったベンチマークではなく、実際のワークロードに対して候補をテストします。
layline.ioがリアルタイムとバッチワークロードを同じプラットフォームでどのように処理するかを見たい場合、Community Editionは無料で探索できます。既存のKafkaトピックやデータソースに対してプロトタイプを構築し、運用経験を直接比較できます。
Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムの両方のワークロードをスケールで処理するエンタープライズデータ処理インフラを構築するシリアルアントレプレナーです。
