|
この記事はJesse Andersonが執筆しました。StreamNativeが翻訳・編集しました。この記事では、3つの実際のユースケースを例に、CTOの観点からKafkaとPulsarを技術的な側面から比較します。所要時間は約8分です。 Apache PulsarについてApache Pulsarは、Apache Software Foundationのトップレベルプロジェクトです。メッセージング、ストレージ、軽量な機能コンピューティングを統合した、次世代のクラウドネイティブ分散メッセージングプラットフォームです。コンピューティングとストレージを分離したアーキテクチャを採用し、マルチテナント、永続ストレージ、複数のデータセンターにまたがるクロスリージョンデータレプリケーションをサポートし、強力な一貫性、高スループット、低レイテンシ、高スケーラビリティといったストリーミングデータストレージの特性を備えています。 GitHub アドレス: http://github.com/apache/pulsar/ 新しいテクノロジーを評価する際、経営幹部は通常、中間管理職、アーキテクト、データエンジニアとは異なる視点から評価します。経営幹部は、ベンチマーク結果や製品サポート機能だけでなく、新しいテクノロジーの長期的な信頼性、それが企業にもたらす競争優位性、そして市場投入までの期間短縮やコスト削減の可能性も考慮します。 私はビッグデータ研究所のマネージングディレクターを務めており、技術評価が私の業務の主要部分を占めています。私たちは、企業がビジネスニーズに基づいて最適な技術を選択し、導入できるよう支援しています。ベンダーと提携していないため、クライアントは様々な技術を客観的に評価できる私たちの能力を特に高く評価しています。 この記事では、CTOの観点からApache PulsarとApache Kafkaを比較します。理論的な比較だけでは意味がなく、意思決定の助けにはなりません。真に重要なのは、実際のユースケースです。そこでこの記事では、一般的な実際のユースケース（シンプルなメッセージング、複雑なメッセージング、高度なメッセージング）を通してPulsarとKafkaを比較します。これらのシナリオにおけるPulsarとKafkaのパフォーマンスを検証することで、それぞれのパフォーマンスと利点をより深く理解し、最終的にはより情報に基づいた意思決定につなげることができます。 シンプルなメッセージングのユースケースこれまでメッセージング システムを使用したことのない会社が、メッセージをコピーすることなく、シンプルなメッセージング システムを介して場所 A から場所 B にメッセージを送信する必要があるとします。 PulsarとKafkaのビジネスケースを徹底的に調査した結果、データアーキテクトチームは、このユースケースにおいてPulsarもKafkaも明確な優位性を持たないという結論に至りました。さらに、このユースケースは短期的には大きく変化する可能性は低いと考えています。 このような単純なメッセージングのユースケースでは、PulsarとKafkaのどちらにも絶対的な優位性がないということに私も同意します。純粋に技術的な観点から言えば、PulsarとKafkaはこのラウンドでは同点なので、コストのみを検討することができます。両者の運用コストと従業員のトレーニングコストはどれくらいでしょうか？KafkaまたはPulsarサービスプロバイダーの価格設定基準に基づいて比較するつもりです。費用を比較する際には、優れたサービスプロバイダーを選択すると、運用コストと従業員のトレーニングコストをある程度削減することもできます。Kafkaのクラウドサービスプロバイダーについては、Kafka API（Azure） [1]を使用するConfluent Cloud [2] 、MSK（AWS） [3] 、およびEvent Hubs [4]を参考にしました。Pulsarのクラウドサービスプロバイダーについては、StreamNative Cloud [5]を選択しました。 比較結果安全上の理由から、Kafka API を選択しました。現在、Kafka API またはそのトランスポートプロトコルを使用する非 Kafka ブローカーをサポートするテクノロジーはいくつかあります。Kafka API を使用することで、非 Kafka ブローカーは Kafka のトランスポートプロトコルをサポートする新しいライブラリを追加できるため、Kafka API との互換性が確保され、テクノロジーオプションの多様性が最大限に高まります。例えば、Kafka API 実装を再コンパイルして変更したり、Pulsar ブローカーを使用して Kafka のプロトコル (KOP) を解析し、Pulsar を Kafka のバックエンドとして使用したりできます。 ユニットコストを比較した結果、費用対効果の高いオプションを選択しました。Kafka APIはバックエンドの品質を保証し、バックエンド間のデータ移動に影響を与えず、リスクを効果的に軽減します。コミュニティが低調であったり、テクノロジーが流行していなかったりしても、当社の利用には影響しません。 複雑なメッセージの使用例ある企業が複雑なメッセージングシステムを必要としているとします。世界中からのデータを処理する必要があるため、地域間レプリケーションをサポートする必要があります。この企業は長年にわたりメッセージングシステムを使用しており、リアルタイムシステムの複雑さをある程度理解しており、現在のメッセージングシステムの欠点も認識しています。したがって、この企業がメッセージングシステムに求める要件は、高度なメッセージ配信と複雑なメッセージ機能に対応できることです。 データアーキテクトチームは、株主や事業部門と共に、現在および将来のニーズについて詳細に議論しました。最終的な結論は、PulsarとKafkaにはそれぞれ利点があるというものでした。また、ユースケースとデータ量は時間とともに増加すると確信していました。 この状況では、PulsarとKafkaは互角です。適切な判断を下すには、それぞれのユースケースを徹底的に調査することが不可欠です。 地域間レプリケーションKafka は、プライベート（高価）なクロスリージョンレプリケーションとオープンソース（アドオン）なクロスリージョンレプリケーションの両方のソリューションを提供しています。プライベートなクロスリージョンレプリケーションは組み込み機能ですが、高価です。オープンソースソリューション（MirrorMaker）は本質的にはデータレプリケーションですが、組み込み機能ではないため、運用オーバーヘッドが増加します。 Pulsarは、オープンソースのクロスリージョンレプリケーション機能を内蔵し、複雑なレプリケーション戦略をサポートします。ユースケースとデータ量の増加が進む企業にとって、クロスリージョンレプリケーション戦略を内蔵したPulsarは、紛れもなく最適な選択肢です。 リージョン間のレプリケーションには、Pulsar を選択しました。複雑なメッセージ企業が新しいメッセージングプラットフォームに移行するにつれ、メッセージングシステムはこれらの新しいユースケースに対応できることが望ましいとされています。データアーキテクトチームは、様々なプラットフォームを調査し、最適なソリューションを模索してきました。現在のメッセージングシステムでは、処理エラーが発生した場合、メッセージを再生成して手動で再試行する必要があるため、メッセージ遅延を導入することが理想的です。さらに、現在のメッセージングシステムのスキーマ実装機能には改善の余地があり、異なるチームが異なるスキーマ実装を選択すると、チーム間のコラボレーションが著しく困難になります。 Kafkaにはデッドレターキュー機能が組み込まれていないため、メッセージ処理に失敗した場合は手動で処理するか、再試行するようにコードを修正する必要があります。また、Kafkaには遅延メッセージ送信のメカニズムも組み込まれていないため、処理が複雑になり、時間がかかります。さらに、Kafkaにはスキーマ実装メカニズムが組み込まれていないため、クラウドサービスプロバイダーは異なるスキーマソリューションを提供しています。 Pulsarにはデッドレターキュー機能が組み込まれています。メッセージ処理が失敗し、否定応答（Negative ACK）を受信した場合、Pulsarは自動的に再試行しますが、再試行回数には制限があります。Pulsarは遅延メッセージ送信もサポートしており、遅延時間を設定できます。Pulsarはスキーマレベルが高いため、スキーマ登録機能が組み込まれており、Pulsar APIもネイティブにスキーマをサポートしています。 複雑なメッセージの場合は、Pulsar を選択します。高度なメッセージングアーキテクチャに対する理解が深まるにつれ、リソースを均等に分散させるためには、同じトピックのデータをループで送信し、ソートによってメッセージが整然と並べられるようにする必要があることがわかりました。 Kafka は特定のコンシューマーにメッセージを配信できません。コンシューマーが消費対象ではないメッセージを受信した場合、それらのメッセージが正しく消費されるようにするためには、別のトピックに再送信するしかありません。しかし、これはデータの冗長性を引き起こし、利用コストを増加させます。そのため、特定のコンシューマーにメッセージを送信するためのルーティングルールを定義できる製品が必要です。 Pulsarブローカーは、定義されたルーティングルールに従って、トピックから指定されたコンシューマーに異なるメッセージを送信できます。Pulsarブローカーは、追加の作業なしで簡単に目的を達成します。 高度なメッセージングには、Pulsar を選択します。展開とコミュニティPulsar と Kafka を完全に比較するには、それぞれのデプロイメント数とコミュニティ プロファイルも確認する必要があります。 サービス市場の観点から見ると、Kafka にはより多くのプロバイダーと、Kafka 製品を販売・サポートするチームがあります。Kafka と Pulsar はどちらも活発なオープンソースコミュニティを有していますが、Kafka のコミュニティはより大規模です。 利用市場の観点から見ると、KafkaとPulsarはどちらも大企業の大規模な本番環境に導入されており、Kafkaを本番環境に導入している企業の数はKafkaをはるかに上回っています。 ユーザー数で言えば、Kafkaの方がユーザー数が多いです。しかし、データエンジニアリングチームは、KafkaユーザーはPulsarを簡単に習得できると考えています。 サービスサポートとコミュニティの観点から、私たちはKafkaを選択しました。しかし、Pulsarコミュニティが急速に成長していることは注目に値します。 比較結果このユースケースでは Pulsar と Kafka の両方に明確な利点と欠点があるため、意思決定プロセスは大幅に難しくなります。 Pulsar はコミュニティとデプロイメントの面で追いつくことができ、Kafka は製品機能の充実に努めることができます。 決定を下す前に、この会社が最も重視するテクノロジーの側面、そしてテクノロジーに関して最も保守的な選択をする必要があるかどうかをまとめてみましょう。過去の経験から、新しいオープンソーステクノロジーはより多くの驚きをもたらす傾向があるため、Pulsarを選択する傾向が強いです。 Kafka を選択するということは、ビジネススポンサーに対し、このユースケースに対応できないことを正直に伝えるリスクを受け入れることを意味します。たとえ多額のクロスリージョンレプリケーションライセンスを支払ったとしても、顧客のニーズを確実に満たせるとは限りません。ビジネスチームは最終的に、実装の開発、改良、テストに相当な時間（場合によっては数か月）を費やす必要があるかもしれません。 Pulsar を選択することで、ビジネススポンサーに対して「すべてがコントロールされています」と伝えることができます。Pulsar の組み込み機能は徹底的にテストされているため、チームは短期間で導入を完了できます。 このシナリオでは、Kafka API の独自の機能は必要ないため、Kafka プロトコル (KOP) をサポートする Pulsar Broker は使用せず、代わりに Kafka API の必要な機能をすべてサポートする Pulsar API を選択しました。 決定理由は以下の通りです。Pulsarを選択することにより、ビジネスリクエストを優先的に処理できるため、開発チームは他の問題の解決ではなくコーディングに専念できます。Pulsarを選択するにあたり、Pulsarコミュニティとそのプロバイダーの開発状況も常に把握しています。 Kafka を選択するという保守的な決定を下す場合、特定のユースケースでは Kafka が実現不可能な場合があることを受け入れる必要があります。類似のユースケースについては、適切なソリューションを採用します。これには、プロジェクトのタイムラインを調整して、意図したソリューションの実装に十分な時間を確保したり、運用チームに連絡して、意図したソリューションの実装にかかるオーバーヘッドを許容できるかどうかを確認したりすることが含まれます。 高度なメッセージングのユースケースある企業が既に複数のメッセージングシステムとキューイングシステムを使用しているとします。運用、アーキテクチャ、そしてオーバーヘッドの観点から、単一のシステムへの移行は必要だと考えています。同時に、運用コストも削減したいと考えています。 データ アーキテクト チームは、現在および将来のニーズに関して株主や事業部門と詳細に議論した結果、Pulsar と Kafka にはそれぞれ独自の利点があると結論付けました。 キューとメッセージ最大の課題はRabbitMQシステムでした。RabbitMQを使って大量のメッセージを送信していたため、負荷を処理できなくなっていました。そこでRabbitMQのコードを微調整し、メッセージをメモリにバッファリングし、負荷管理のために新しいクラスタを作成し続けました。しかし、私たちが必要としていたのは回避策ではなく、膨大な量のメッセージを処理できるシステムでした。 データアーキテクトがこのユースケースを検討した結果、新しいシステムはメッセージストリーミングとキューモデルの両方を同時に処理できる必要があるという結論に達しました。メッセージ処理にはRabbitMQを引き続き使用するだけでなく、より高度なメッセージング技術も必要でした。 Kafka はメッセージパッシングに優れ、大規模なメッセージストリームを処理できますが、キューは処理できません。開発チームは様々なソリューションを試すことができますが、単一のシステムで処理するという目標は達成できません。キューのユースケースを処理するには、Kafka クラスターと RabbitMQ クラスターの両方が必要です。Kafka クラスターはバッファとして機能し、RabbitMQ クラスターの過負荷を効果的に防ぎます。しかし、Kafka は RabbitMQ をネイティブにサポートしていないため、Kafka と RabbitMQ 間でデータを移動するには、プロバイダーと提携するか、独自のコードを作成する必要があります。 Pulsarは、キューとメッセージを同一クラスタ内で処理でき、クラスタのスケーリングもサポートしています。Pulsarは、すべてのメッセージフローモデルとキューモデルを1つのクラスタに統合できます。ユーザーはRabbitMQコードを引き続き使用でき、PulsarはRabbitMQコネクタをサポートしています。また、StreamNativeがブローカー内で開発したAoP（AMQPプロトコル処理プラグイン） [6] （Apacheライセンス）を使用することもできます。 RabbitMQのコードの使用を中止する場合は、Pulsar APIをご利用ください。Pulsar APIはRabbitMQと同じキューイング機能を備えています。ユーザーはそれに応じてコードを修正する必要があります。作業量は元のコードの構造と詳細によって異なります。修正後は、コードの評価とテストも必要になります。 キュー モデルとメッセージ フロー モデルに関しては、Pulsar を選択します。事前予約データアーキテクトはデータ使用状況を分析した結果、最初の使用後、99.99%のデータが読み取られていないことを発見しました。しかし、メッセージは1週間保持するという保守的な戦略を採用することにしました。データを1週間保存するという決定はしましたが、運用コストを過度に増加させたくなかったのです。階層型ストレージにより、データをローカルに保存し、その他のデータをS3にオフロードできるため、長期データ保持のコストを削減できます。 Kafka チームは階層型ストレージを開発中ですが、Kafka は現在この機能をサポートしていません。一部のサービスプロバイダーはプライベート階層型ストレージを提供していますが、本番環境で直接使用できるかどうかは不明です。 階層型ストレージはPulsarのネイティブ機能であり、本番環境で直接使用できます。既に複数の企業がこの機能を本番環境に導入しています。 階層型ストレージにはPulsarを選択しました。Kafkaは階層型ストレージに多大な投資を行っており、この機能の重要性は明らかです。 ルーティングトピックデータを細分化するために複数のトピックを使用するため、新しいシステムでは多数のトピックが作成される予定です。データアーキテクトは、当初は10万個のトピックが必要で、時間の経過とともに50万個に増加すると見込んでいます。 Kafka クラスターはサポートできるパーティションの数に制限があり、各トピックには少なくとも 1 つのパーティションが必要です。Kafka はサポートできるトピックの数を増やしていますが、これらの新機能はまだリリースされていません。さらに、Kafka には名前空間とマルチテナンシーがないため、トピックベースのリソースシャーディングは不可能です。数十万ものトピックを同じ名前空間に保存する必要があるからです。 実際、一部の企業はKafkaクラスターを使用してさらに多くのトピックを保存し、リソースシャーディングを実装しています。しかし、単一クラスターの使用を放棄し、それに伴う追加コストが発生しています。 Pulsarは数百万のトピックの保存をサポートしており、この機能はすでにリリースされ、本番環境に導入されています。Pulsarは名前空間とマルチテナントをサポートしているため、ユーザーはトピックごとにリソースクォータを設定でき、コストを削減できます。 トピックとしては、Pulsar を選択しました。ルーティングこの企業は以前RabbitMQを使用していたと想定されるため、その設計では一般的にブローカールーティングメカニズムを使用して、あるトピックから別のトピックにデータを転送します。例えば、世界規模のデータを格納するトピックがある場合、RabbitMQブローカーはそれを国別に整理されたトピックとして処理します。 データアーキテクトチームは、メッセージングシステム内の単一のトピックを使用して世界中のデータを保存する方法を徹底的に調査しました。その結果、受信データの量が増えるにつれて、下流のコンシューマーが処理できなくなることがわかりました。下流の各システムでデータをデシリアライズ、検査、破棄するプロセスは煩雑で、時間と労力を要しました。 Kafka はすべてのデータを単一のトピックに保存します。しかし、フィルタリングする必要があるデータ量が増加したり、クラスターが過負荷になったりすると、このアプローチは非現実的になります。グローバルトピックからデータを読み取ってさらに処理を行うには、通常、水平スケーリング（コンシューマー数の増加）が必要になります。ユーザーには、カスタムコンシューマー/プロデューサーの作成、Kafka Streams プログラムの作成、独自の KSQL の使用という 3 つの選択肢しかありません。 Pulsarは、Pulsar Functionsまたはカスタムコンシューマー/プロデューサーメソッドを使用したルーティングをサポートしており、グローバルトピックからデータを読み取り、国ごとに特定のトピックに保存することができます。独立したトピックを使用することで、コンシューマーはオンデマンドでトピックを購読し、関連するメッセージのみを受信できます。 ルーティングに関しては、Pulsar を選択します。最終決定時間は最終決定に影響を与える重要な要素です。Kafka が Pulsar に追いつく時間はあるでしょうか？データエンジニアが Kafka ソリューションを実装する時間はあるでしょうか？待つことで、企業は機会を逃し、新しいユースケースの追加が遅れ、ビジネス開発に影響を及ぼします。 最終決定： Pulsar を選択しました。 十分な時間的余裕を持って決定：新アーキテクチャの導入を延期する。Kafka に6ヶ月の猶予を与え、Pulsar のパフォーマンスを上回れるかどうか確認する。上回れる場合は、これらの新機能を本番環境でテストし、安定性を評価する。Kafka が大幅な改善をもたらさない場合、依然として Pulsar を選択する。 結論この記事で紹介した3つのユースケースは、いずれも私が実際に業務で遭遇した事例です。この記事で紹介したソリューションが皆様の参考となり、具体的なユースケースに基づいた技術評価の実施に役立つことを願っています。 |
