建築家の選択は、パルサーかカフカか?

導入

最近、私は Pulsar と Kafka の比較を調べています。ちょっと検索してみると、最も有名な 2 つのオープン ソース メッセージング システム間で「戦争」が続いていることがわかります。

Kafka ユーザーとして、私は Kafka のいくつかの問題に確かに困惑しており、Pulsar には非常に失望しています。それで、ようやく時間をかけて調査することができ、たくさんの調査をしました。この記事では、Pulsar の利点を強調し、Kafka よりも Pulsar を検討する理由をいくつか紹介します。ただし、製品の使用方法、サポート、コミュニティ、ドキュメントなどについては明確にしてください。 Kafka は明らかに Pulsar より優れているため、この記事で説明した利点のほとんどが自分のユースケースに適している場合にのみ Pulsar を検討してください。さあ始めましょう！

[[352185]]

Kafka の基礎

Kafka はメッセージング システムの王様です。これは 2011 年に LinkedIn によって作成され、Confluent のサポートにより広く配布されるようになりました。 Confluent は、スキーマ進化のための Schema Registry、他のデータ ソースからの簡単なストリーミングのための Kafka Connect など、オープン ソース コミュニティに多くの新機能とアドオンをリリースしました。データベースから Kafka、分散ストリーム処理用の Kafka Streams、最近では Kafka トピックに対する SQL のようなクエリ用の KSQL などがあります。また、多くのシステム用のコネクタも多数あります。詳細については、Confluent Platform をご覧ください。

Kafka は高速で、インストールが簡単で、非常に人気があり、幅広い範囲やユースケースに使用できます。 Apache Kafka は開発者の観点からは常に使いやすいものでしたが、運用面では混乱していました。それでは、Kafka の問題点のいくつかを見てみましょう。

> Kafka の例。出典: https://talks.rmoff.net/pZC6Za/slides

カフカの問題点

• ブローカーもデータを保存する結合アーキテクチャのため、Kafka のスケーリングは困難です。別のブローカーをスピンオフすると、トピックのパーティションとレプリカをコピーする必要があり、時間がかかります。
• テナントが完全に分離されたネイティブのマルチテナントはありません。
• ストレージは非常に高価になる可能性があり、データを長期間保存することは可能ですが、コストのためにほとんど使用されません。
• レプリカが同期しなくなった場合、メッセージが失われる可能性があります。
• スケーリングの問題を回避するために、ブローカー、トピック、パーティション、レプリカの数（計画されている将来の使用量の増加に対応するため）を事前に計画して計算する必要がありますが、これは非常に困難です。
• メッセージング システムのみが必要な場合、オフセットの使用は複雑になる可能性があります。
• クラスターの再バランス調整は、接続されたプロデューサーとコンシューマーのパフォーマンスに影響を与える可能性があります。
• MirrorMaker Geo レプリケーション メカニズムに問題があります。 Uber のような企業は、これらの問題を克服するために独自のソリューションを生み出しました。

ご覧のとおり、ほとんどの問題は運用面と関連しています。 Kafka はインストールが比較的簡単ですが、管理と調整が困難です。さらに、柔軟性と回復力はまだ十分ではありません。

パルサーの基礎

Pulsar は 2013 年に Yahoo によって作成され、2016 年に Apache Foundation に寄贈されました。現在、Pulsar は Apache のトップレベル プロジェクトとなっています。 Yahoo、Verizon、Twitter などの企業では、何百万ものメッセージを処理するために実稼働で使用されています。多くの機能があり、非常に柔軟性があります。 Kafka よりも高速で、実行コストが安いと言われています。 Kafka の問題点のほとんどを解決し、スケーリングを容易にすることを目的としています。

Pulsar は非常に柔軟性があります。 Kafka のような分散ログや、RabbitMQ のような純粋なメッセージング システムも可能です。複数のタイプのサブスクリプション、複数の配信保証、保持ポリシー、およびスキーマの進化を処理する複数の方法があります。機能も多数あります...

> Pulsar アーキテクチャ: https://pulsar.apache.org/docs/en/concepts-architecture-overview/

パルサーの特徴

• マルチテナント機能が組み込まれているため、異なるチームが同じクラスターを使用し、互いに分離することができます。これにより、多くの管理上の課題が解決されます。分離、認証、承認、および割り当てをサポートします。
• 多層アーキテクチャ: Pulsar は、データ台帳として Apache BookKeeper を基盤とする特殊なデータ層にすべてのトピック データを保存します。ストレージとメッセージングを分離することで、クラスターのスケーリング、再バランス調整、保守に関する多くの問題が解決されます。また、信頼性も向上し、データ損失が事実上不可能になります。あるいは、データを読み取るときに、リアルタイムの取り込みに影響を与えずに Bookeeper に直接接続することもできます。たとえば、Presto を使用して KSQL と同様にトピックに対して SQL クエリを実行できますが、リアルタイムのデータ処理には影響しませんのでご安心ください。
• 仮想テーマ。 n 層アーキテクチャにより、トピックの数に制限はなく、トピックとそのストレージは分離されています。非永続的なトピックを作成することも可能です。
• N 層ストレージ。 Kafka の問題の 1 つは、ストレージが高価になる可能性があることです。したがって、「コールド」データを保存するために使用されることはほとんどなく、メッセージは頻繁に削除されます。そして、クライアントに対して透明なビューを提示します。クライアントは、すべてのメッセージがログに存在するかのように、最初から読み取ることができます。
• パルサー機能。簡単に導入でき、計算プロセスが軽量で、開発者に優しい API を備えており、独自のストリーム処理エンジン (Kafka など) を実行する必要はありません。
• セキュリティ: 組み込みプロキシ、マルチテナント セキュリティ、プラグ可能な認証などを備えています。
• 迅速な再バランス調整。パーティションは、再バランス調整が容易なセグメントに分割されます。
• サーバー側の重複排除と無効なフィールド。クライアントでこれを行う代わりに、圧縮中に重複排除を実行することもできます。
• 組み込みスキーマ レジストリ。複数の戦略をサポートしており、非常に使いやすいです。
• 地理的レプリケーションと組み込み検出。クラスターを複数のリージョンに複製するのは非常に簡単です。
• 統合されたロードバランサーと Prometheus メトリック。
• 複数の統合: Kafka、RabbitMQ など。
• GoLang、Java、Scala、Node、Python など多くのプログラミング言語をサポートしています。
• クライアントはシャーディングとデータのパーティション分割について知る必要はなく、これはサーバー側で透過的に実行されます。

> 機能一覧: https://pulsar.apache.org/

ご覧のとおり、Pulsar には興味深い機能が多数あります。

パルサーハンズオン

Pulsar を使い始めるのはとても簡単です。 JDK がインストールされていることを確認してください。

• Pulsar をダウンロードして解凍します:

 $ wget https://archive.apache.org/dist/pulsar/pulsar-2.6.1/apache-pulsar-2.6.1-bin.tar.gz

• コネクタをダウンロードします (オプション):

 $ wget https://archive.apache.org/dist/pulsar/pulsar-2.6.1/connectors/{connector}-2.6.1.nar

• narファイルをダウンロードしたら、そのファイルをpulsarディレクトリのconnectorsディレクトリにコピーします。
• パルサーを起動します!

 $ bin/pulsar スタンドアロン

Pulsar は、クラスターと対話するために使用できる pulsar-client と呼ばれる CLI ツールを提供します。

メッセージの生成:

 $ bin/pulsar-client は my-topic --messages "hello-pulsar" を生成します

メッセージを読む:

 $ bin/pulsar-client は my-topic -s "first-subscription" を消費します

Akka ストリームの例

クライアントの例として、Akka で Pulsar4s を使用しましょう。

まず、データ ストリームを消費するためのソースを作成する必要があります。必要なのは、要求に応じてコンシューマーを作成し、メッセージ ID を検索する関数だけです。

 val topic =トピック("persistent://standalone/mytopic")
 val consumerFn = () = > client.consumer(ConsumerConfig(トピック、サブスクリプション))

次に、consumerFn 関数を渡してソースを作成します。

 com.sksamuel.pulsar4s.akka.streams._ をインポートします
val pulsarSource =ソース(consumerFn、Some(MessageId.earliest))

Akka ソースの具体化された値は Control のインスタンスであり、メッセージの消費を停止するために使用できる "close" メソッドを提供します。これで、通常どおり Akka Streams を使用してデータを処理できます。

受信機を作成するには:

 val topic =トピック("persistent://standalone/mytopic")
 val producerFn = () = > client.producer(ProducerConfig(トピック))
 com.sksamuel.pulsar4s.akka.streams._ をインポートします
val pulsarSink =シンク(producerFn)

完全な例は Pulsar4s から引用したものです:

パルサー関数の例

Pulsar 関数は、1 つ以上のトピックからのメッセージを処理し、変換して、結果を別のトピックに出力します。

> パルサー関数。出典: https://pulsar.apache.org/docs/en/functions-overview/

関数を記述するための 2 つのインターフェースから選択できます。

• 言語ネイティブ インターフェース: Pulsar 固有のライブラリや特別な依存関係は必要ありません。コンテキストにアクセスできません。 Java と Python のみがサポートされています。
• Pulsar Function SDK: Java/Python/Go で利用可能で、コンテキスト オブジェクトへのアクセスなど、より多くの機能を提供します。

言語ネイティブ インターフェイスの使用は非常に簡単で、メッセージを変換するための簡単な関数を記述するだけです。

 defプロセス(入力):
 "{}!" を返します。format(入力)

Python で記述されたこの単純な関数は、すべての受信文字列に感嘆符を追加し、結果の文字列をトピックに公開するだけです。

SDK を使用するには、依存関係をインポートする必要があります。たとえば、Go では次のように記述します。

パッケージメイン
輸入 （
 "コンテクスト"
 「fmt」
 「github.com/apache/pulsar/pulsar-function-go/pf」
 ） 
 
 function HandleRequest(ctx context.Context, in []byte) エラー {
 fmt.Println(文字列(in) + "!")
ゼロを返す
} 
 
関数main() {
 pf.Start(リクエストの処理)
 }

サーバーレス関数をクラスターに公開してデプロイするには、pulsar-admin CLI を使用します。 Python を使用する場合は、次のようにします。

 $ bin/pulsar-admin 関数を作成します\
 --py ~/router.py \
 --classname router.RoutingFunction \
 --テナントパブリック\
 --namespace デフォルト \
 --name ルート-フルーツ-野菜 \
 --inputs persistent://public/default/basket-items

Pulsar Functions の優れた機能の 1 つは、関数を公開するときに配信保証を設定できることです。

 $ bin/pulsar-admin 関数を作成します\
 --name 実際に 1 回だけ実行する関数 \
 --処理保証は EFFECTIVELY_ONCE

オプションは次のとおりです:

パルサーの利点

Kafka と比較した主な利点を見てみましょう。

• その他の機能: Pulsar 関数、マルチテナント、スキーマ レジストリ、n 層ストレージ、複数の使用および永続モードなど。
• 柔軟性の向上: 3 つのサブスクリプション タイプ (排他、共有、フェイルオーバー) により、1 つのサブスクリプションで複数のトピックを聴くことができます。永続オプション: 非永続 (高速)、永続、圧縮 (各メッセージの最後のキーのみ)。サーバー側の重複排除と無効化による配信保証はオプションです。多数の保持ポリシーと TTL。
• 拡張要件を事前に定義する必要はありません。
• キューイングとストリーミングをサポートします。つまり、RabbitMQ や Kafka のようなものになります。
• ストレージはプロキシから分離されているため、よりスケーラブルです。リバランスはより高速かつ信頼性が高くなります。
• 分離と n 層ストレージにより操作が簡単。管理者 REST API も優れています。
• プロキシに影響を与えずにストアを直接クエリするための Presto との SQL 統合。
• n 層自動ストレージ オプションを使用して、より安価に保管します。
• より高速: 多くのベンチマークでは、さまざまな状況でより優れたパフォーマンスが示されています。 Pulsar は、レイテンシが低く、スケーリング機能が優れていると主張しています。ただし、これは Confluent によって異議が唱えられているため、あまり鵜呑みにせず、独自のベンチマークを実行してください。
• Pulsar Functions は、メッセージング プラットフォームにサーバーレス コンピューティングをもたらします。
• 統合されたスキーマレジストリにより、スキーマの進化が容易になります。
• 統合されたロードバランサーと Prometheus メトリック。
• ジオレプリケーションはより適切に機能し、セットアップも簡単になります。 Pulsar には検出機能も組み込まれています。
• 作成できるトピックの数に制限はありません。
• Kafka と互換性があり、簡単に統合できます。

パルサーの問題

Pulsar は完璧ではありませんが、Kafka が人気があるのには理由があります。Kafka は 1 つのことだけをうまくこなします。 Pulsar は、あまりにも多くの領域に対処しようとしていますが、いずれか 1 つの領域を超えることはありません。 Pulsar の問題点をいくつかまとめてみましょう。

• 人気度: Pulsar はそれほど人気が​​ありません。サポート、ドキュメント、実際の使用方法が不足しています。大規模な組織にとって、これは大きな問題です。
• n 層アーキテクチャのため、Bookkeeper などの追加のコンポーネントが必要になります。
• プラットフォーム内にはストリーミング アプリケーションに対する適切なサポートがありません。 Pulsar 関数は、より単純であり、リアルタイムのストリーム処理用に設計されていないという点で、Kafka Streams とは異なります。ステートフル処理は実行できません。
• Kafka と比較すると、プラグインとクライアントが少なくなります。さらに、Pulsar スキルを持っている人が少ないため、内部で習得する必要があります。
• クラウドでのサポートは少なくなります。 Confluent はマネージド クラウドを提供しています。

Confluent には Pulsar と Kafka の比較があり、そこでさらに詳しく説明されています。このブログでは、Kafka と Pulsar に関するいくつかの質問にも答えていますが、これらの質問には偏りがある可能性があることに注意してください。

パルサーの使用例

Pulsar は幅広いユースケースに使用できます。

• パブリッシュ/サブスクライブキューメッセージング
• 分散ログ
• 永続的なイベントストレージのためのイベントソースレッジ
• マイクロサービス
• SQL分析
• サーバーレス関数

Pulsar を検討すべきなのはいつですか?

• RabbitMQ のようなキューと、Kafka のようなストリーム プロセッサが必要です。
• 単純な地理的レプリケーションが必要です。
• マルチテナントは必須であり、各チームのアクセス権限を確保する必要があります。
• すべてのメッセージを長期間保存する必要があり、別のストレージにオフロードしたくない。
• パフォーマンスが重要な場合、ベンチマークでは Pulsar がより低いレイテンシと高いスループットを提供することが示されています。
• ローカルで実行しており、Kafka の設定経験はありませんが、Hadoop の経験は多少あります。

なお、クラウドの場合は、クラウドベースのソリューションを検討してください。クラウド プロバイダーには、特定のユース ケースをカバーするさまざまなサービスがあります。たとえば、キュ​​ー メッセージングの場合、クラウド プロバイダーは Google pub/sub などの多くのサービスを提供しています。分散ログには、Confluent Cloud または AWS Kinesis があります。クラウドプロバイダーは非常に優れたセキュリティも提供します。 Pulsar の利点は、単一のプラットフォームで多くの機能を提供できることです。チームによっては、これをマイクロサービスのメッセージング システムとして使用する場合もあれば、データ処理用の分散ログとして使用する場合もあります。

結論は

私はカフカの大ファンなので、Pulsar にとても興味があります。競争は良いことであり、イノベーションを促進します。

Kafka は、世界中で大きな成功を収めた、成熟した、回復力のある、実戦でテストされた製品です。それがない会社は想像できません。しかし、Kafka は自身の成功の犠牲者になりつつあると私は考えています。Kafka は、多くの大企業をサポートする必要があったため、急成長によって機能開発が遅くなっているのです。 ZooKeeper 依存関係などの重要な機能を削除するのに時間がかかりすぎました。これにより、Pulsar のようなツールが繁栄する余地が生まれました。 Kafka のいくつかの問題を修正し、さらに機能を追加します。

しかし、Pulsar はまだ非常に未熟なので、生産に投入する前には細心の注意を払う必要があります。 Pulsar を組織に導入する前に、分析、ベンチマーク、調査を実行し、概念実証を作成します。小規模から始めて、Kafka から移行する前に概念実証を行い、完全な移行を決定する前に影響を評価します。