ApacheKafka対ApachePulsar:選択方法

最近では、非常にスケーラブルなpub / subメッセージングは​​、実質的にApacheKafkaと同義です。Apache Kafkaは、処理用にApacheStormやApacheSparkなどを追加する場合でも、Apache Kafka自体が提供する処理ツールを使用する場合でも、分散ストリーミングアプリケーションの堅実でオープンソースの頼りになる選択肢であり続けます。しかし、カフカは町で唯一のゲームではありません。

Yahooによって開発され、現在はApache SoftwareFoundationプロジェクトであるApachePulsarは、ApacheKafkaが長年にわたって着用してきたメッセージングの頂点に立っています。Apache Pulsarは、開発者が比較的簡単にKafkaからPulsarに切り替えることができる互換性のあるAPIとともに、多くの状況でApacheKafkaよりも高速なスループットと低いレイテンシーの可能性を提供します。 

由緒ある頑丈なApacheKafkaと新興のApachePulsarのどちらを選ぶべきでしょうか?彼らのコアオープンソース製品と、コアメンテナのエンタープライズエディションがもたらすものを見てみましょう。

Apache Kafka

LinkedInによって開発され、2011年にオープンソースとしてリリースされたApache Kafkaは、広く普及しており、サービスバスやpub / subシステムをアーキテクチャに追加することを考えると、多くの人にとってデフォルトの選択肢になりつつあります。 Apache Kafkaのデビュー以来、Kafkaエコシステムは大幅に成長し、ApacheKafkaメッセージングでスキーマを適用するSchemeRegistry、データベースなどの他のデータソースからKafkaに簡単にストリーミングするKafka Connect、分散ストリーム処理用のKafka Streams、最近ではKSQLが追加されました。 Kafkaトピックに対してSQLのようなクエリを実行するため。 (Kafkaのトピックは、特定のチャネルの名前です。)

過去数年間に構築された多くのリアルタイムパイプラインの標準的なユースケースは、データをApache Kafkaにプッシュし、ApacheStormやApacheSparkなどのストリームプロセッサを使用してデータを取得し、実行して処理し、公開することでした。ダウンストリームで使用するために別のトピックに出力します。Kafka StreamsとKSQLを使用すると、いつでもApache Kafkaプロジェクトを離れることなく、すべてのデータパイプラインのニーズを処理できますが、もちろん、必要に応じて外部サービスを使用してデータを処理することもできます。

Apache Kafkaは、開発者の観点からは常に非常に友好的でしたが、運用上は混合バッグのようなものでした。小さなクラスターを起動して実行するのは比較的簡単ですが、大きなクラスターを維持することには問題が伴うことがよくあります(たとえば、Kafkaブローカーの障害後のリーダーパーティションの交換)。

さらに、MirrorMakerと呼ばれるユーティリティを介してマルチテナンシーをサポートするために採用されたアプローチは、SREに髪の毛を抜くための確実な方法でした。実際、MirrorMakerは、Uberのような企業がデータセンター間で複製するための独自のシステム(uReplicator)を作成したほどの問題と見なされています。 Confluentには、ApacheKafkaのエンタープライズ製品の一部としてConfluentReplicatorが含まれています。 MirrorMakerのセットアップを維持しなければならなかった人として言えば、Replicatorがオープンソースバージョンの一部ではないのは残念です。

ただし、運用面ですべてが悪いニュースというわけではありません。現在のApacheKafka 1.xシリーズでは、クラスターを実行する際の頭痛の種を減らすために多くの作業が行われています。最近、システムが200,000を超えるパーティションの大規模なクラスターをより合理化された方法で実行できるようにするいくつかの変更があり、Kafka Connectに「デッドレター」キューを追加するなどの改善により、データソースとシンクの問題を特定して回復できるようになりました。より簡単に。また、2019年にはKubernetesでApache Kafkaを実行するための本番レベルのサポートが見られる可能性があります(HelmチャートとKubernetesオペレーターを介して)。

2014年に、Kafkaの元の開発者の3人(Jun Rao、Jay Kreps、Neha Narkhede)がConfluentを結成しました。これは、前述のレプリケーター、コントロールセンター、追加のセキュリティプラグインなど、Confluentプラットフォームに追加のエンタープライズ機能を提供します。通常のサポートとプロフェッショナルサービスの提供。 Confluentには、クラウドサービスであるConfluent Cloudもあります。これは、クラスターを実行することによる運用上のオーバーヘッドの一部を自分で処理したくない場合に、Amazon WebServicesまたはGoogleCloudPlatformで実行されるフルマネージドのConfluentPlatformサービスです。

AWSにロックされ、Amazonサービスを使用している場合、Amazonは、AWSエコシステム内のフルマネージドKafkaサービスであるAmazon Managed Streaming for Kafka(MSK)のパブリックプレビューを導入していることに注意してください。(Amazon MSKConfluentと提携して提供されていないため、MSKを実行しても、Confluent Platformのすべての機能が得られるわけではなく、オープンソースのApache Kafkaで提供されている機能のみが得られることに注意してください。)

Apache Pulsar

機能が重複しているように見えるプロジェクトをピックアップするというApacheSoftware Foundationの傾向を考えると(有向非巡回グラフデータ処理のニーズに合わせて、Apache Apex、Apache Flink、Apache Heron、Apache Samza、Apache Spark、またはApache Stormを希望しますか?)メッセージングニーズの信頼できるオプションとしてApacheKafkaを選択する前に、ApachePulsarがトップレベルのApacheプロジェクトになるという発表をすぐに過ぎてしまうことを許してください。しかし、ApachePulsarは一見の価値があります。

Apache PulsarはYahooで生まれました。そこでは、他のオープンソース製品が当時提供できなかった組織のニーズに対応するために作成されました。その結果、Pulsarは、ジオレプリケーションとマルチテナンシーを完全にサポートする数百万のトピックとパーティションを処理するためにゼロから構築されました。

裏では、ApachePulsarはストレージのニーズを維持するためにApacheBookKeeperを使用していますが、ひねりがあります。ApachePulsarには、階層型ストレージと呼ばれる機能があります。分散ログシステムの問題の1つは、データをログプラットフォームにできるだけ長く残したいが、ディスクドライブのサイズが無限ではないことです。ある時点で、これらのメッセージを削除するか、他の場所に保存するかを決定します。これらのメッセージは、将来必要になった場合にデータパイプラインを介して再生できる可能性があります。これは機能しますが、操作が複雑になる可能性があります。 Apache Pulsarは、階層型ストレージを介して、古いデータをAmazon S3、Google Cloud Storage、またはAzure Blog Storageに自動的に移動し、クライアントに透過的なビューを表示できます。クライアントは、すべてのメッセージがログに存在するかのように、時間の開始から読み取ることができます。

Apache Kafkaと同様に、Apache Pulsarはデータ処理用のエコシステムを成長させました(ただし、ApacheSparkおよびApacheStorm用のアダプターも提供します)。Pulsar IOは、ソースまたはシンクとして他のデータシステムに接続するためのKafka Connectと同等であり、PulsarFunctionsはデータ処理機能を提供します。SQLクエリは、FacebookのオープンソースのPrestoエンジン用のアダプターを使用して提供されます。

興味深い問題は、PulsarFunctionsとPulsarIOが、どこでも実行できる可能性のある別個のプロセスではなく、標準のPulsarクラスター内で実行されることです。これは柔軟性の低下ですが、運用の観点からは物事がはるかに簡単になります。(クラスターの外部で関数を実行するために悪用される可能性のあるローカル実行モードがありますが、ドキュメントには「これを行わないでください!」と書かれています)

Apache Pulsarは、クラスター内で関数を実行するさまざまな方法も提供します。これらは、個別のプロセス、Dockerコンテナー、またはブローカーのJVMプロセスで実行されるスレッドとして実行できます。これは、本番環境でKubernetesまたはMesosphere DC / OSをすでにサポートしているApachePulsarのデプロイモデルと連携しています。注意すべき点の1つは、Pulsar関数、Pulsar IO、およびSQLはApache Pulsarに比較的新しく追加されたものであるため、これらを使用する場合はいくつかの鋭いエッジを期待することです。

また、Javaのみの限定されたKafka互換のAPIラッパーがあるため、既存のApacheKafkaアプリケーションをApachePulsarインフラストラクチャに統合できる可能性があります。これは、実稼働ソリューションよりも探索的テストと中間移行計画におそらく適していますが、持っていると便利です。

Confluentと同様に、YahooのApache Pulsarの開発者(MatteoMerliとSijieGuo)は、Apache Heronの作成者(KarthikRamasamyとSanjeevKulkarni)とともに共同設立者であるスピンオフ会社Streamlioを設立しました。 。Streamlioのエンタープライズ製品には、クローズドソース管理コンソールに加えて、通常の商用サポートとプロフェッショナルサービスソリューションが含まれていますが、効率的で耐久性のあるマルチテナンシーサポートなどはコアオープンソース製品の一部です。

ApacheKafkaまたはApachePulsar?

Apache Kafkaは、成熟した、回復力のある、戦闘でテストされた製品です。ほぼすべての一般的な言語で記述されたクライアントと、KafkaConnectのさまざまなデータソースでサポートされている多数のコネクタがあります。 AmazonとConfluentがマネージドサービスを提供しているため、大規模なKafkaクラスターを簡単に起動、実行、保守できます。これは、これまでよりもはるかに簡単です。私は新しいプロジェクトでApacheKafkaを使い続けており、今後何年にもわたって使用する可能性があります。

ただし、最初からマルチテナントまたは地理的に複製する必要があるメッセージングシステムを構築する場合、または大規模なデータストレージのニーズがあり、さらにすべてのデータを簡単にクエリして処理する必要がある場合は、ずっと前に、私はApachePulsarのタイヤを蹴ることを提案します。これは、Apache Kafkaが苦労する可能性のあるいくつかのユースケースに確実に適合しますが、分散ログプラットフォームに必要なコア機能の観点からもうまく機能します。また、ドキュメントやStack Overflowの質問への回答に関して最先端を行くことを気にしないのであれば、はるかに優れています。