Apache Kafka を拡張しようとしていますか? Apache Pulsar の使用を検討する

今日では、最も基本的な Web およびモバイル アプリケーションでさえ、大量のデータを消費しています。このデータを交換して処理するための鍵は、イベント ドリブン アーキテクチャに支えられたメッセージング システムです。

イベント駆動型システムにより、メッセージング ソリューションと処理をスケーラブルかつ非同期にすることができます。非同期システムは、各リクエストがバックグラウンドで処理されるため、より多くのリクエストを処理できます。

サーバーに対して要求が行われると、その要求はキューに追加され、そこでプロセッサがそれを読み取ります。これにより、組織は別のクラスターでリクエストを処理することにより、毎秒数十万、場合によっては数百万ものリクエストを大規模に受け入れるシステムを構築できます。

業界は、このイベント駆動型およびメッセージ駆動型の形式に従う、いくつかのメッセージ ブローカ システムとトピック駆動型のパブリッシュ/サブスクライブ(pub-sub) プラットフォームを作成しました。 Apache KafkaとApache Pulsar は、分散型メッセージ配信およびストリーミング システムの 2 つの広く使用されている例です。

Kafka と Pulsar はどちらも、何千もの接続されたクライアントへのメッセージ配信をスケーリングするために使用できる pub-sub パターンに基づいて構築されています。どちらも、メッセージが失われないようにするための永続ストレージ モデルを提供し、パーティションを使用してメッセージを保存および処理します。

Kafka と Pulsar は多くの点で似ていますが、特に大量のデータの管理、リアルタイム アプリケーションの作成、および大規模な開発において、いくつかの顕著な違いがあります。

Kafka には多くの利点がありますが、スケーラビリティと成長に対する Pulsar のサポートは比類のないものです。そして、成長のある時点で、Kafka の最適化を試みるのではなく、それをやめるのが最適な選択です。ここでは、Kafka と Pulsar の違いを比較し、Kafka を使用する場合のスケーラビリティの論理的な次のステップが Pulsar に切り替える方法を示します。

Apache Kafka アプリの課題

Kafka は、ソフトウェア アーキテクチャにおける分散 pub-sub パターンのデファクトです。 Kafka を使用する組織は、数千のメッセージを処理し、メッセージを複数のコンシューマーに同時にブロードキャストすることができます。

Kafkaにはいくつかの利点がありますが、スケーリングしようとすると特定の制限もあります。 Apache Kafka で構築されたアプリケーションをスケーリングしようとするときに直面するいくつかの課題を探ってみましょう。

ストレージの制限

Kafka のアーキテクチャは、Kafka でアプリケーションをスケーリングするときに直面する最初の課題であるストレージを生み出します。

ステートフル ブローカーは、組織が拡張が難しいと感じる最初の理由です。 Kafka のデータはリーダー ノードに保存され、データのパーティションはローカル ディスクに保存されます。データはノードに関連付けられており、Kafka のブローカーはステートフルです。これは、リーダー ノードが最大ストレージ容量に達すると、インフラストラクチャ ストレージが増やされない限り、クラスターはそれ以上のメッセージを受け入れることができないことを意味します。成長を続ける環境では、クラスターに複数のアップグレードが必要になるため、これは困難です。

この課題を克服する 1 つの方法は、非常に高価な大規模なストレージ クラスターを購入することです。

さらに、このアーキテクチャに基づいて、プラットフォームがストレージまたはメモリの最大制限に達すると、新しい着信メッセージを受け入れることができなくなります。これは、ビジネスに不可欠なアプリケーションにとって大きな損失につながる可能性があります。 Kafka のアーキテクチャは、多くのメッセージを受け入れてブロードキャストするように設計されています。長期的なデータ保存は優先事項ではありません。その結果、必要なストレージを提供できないため、Kafka アプリケーションのスケーリングは非常に困難です。

メッセージ処理のトラブル

Kafka には、アクティビティの監視、メッセージの処理、およびデータの永続化に必要な機能が含まれていないため、管理が困難です。

Kafka は、配信前にメッセージを変更する必要がないヘッドレス メッセージ ブロードキャスト システムに適しています。ただし、メッセージをコンシューマに転送する前に処理する必要があるとします。これには、追加のプラットフォームに依存する必要があり、Kafka でメッセージを処理することがより困難で複雑になります。

さらに、ストリーミング プラットフォームの各コンポーネントにはメンテナンスが必要であり、クラスター全体に適用される制限があるため、上記のような他のプラットフォームが関与すると、データ配信システムの複雑さが大幅に増加します。さらに、Kafka クラスターでは、データ要件が時間とともに増大するため、データとメッセージの永続性が制限されます。

複雑なクライアント ライブラリ

企業は主に、提供されるストリーミング サービスに Kafka を使用します。ストリーミング API は、独自のビジネス ケースをサポートするために、pub-sub メッセージ配信の上に記述されています。 Kafka Streams API は、企業顧客向けの高度な機能を提供するスタンドアロン製品です。 Kafka Streams の最も注目すべき機能であるtransactions は、企業がメッセージの流れによって生成される出力の一貫性を確保するのに役立ちます。このため、Kafka にはユース ケースごとに 2 つの個別の API があります。

たとえば、Kafka ストリーミング ライブラリを使用すると、企業はメッセージを「1 回だけ」配信できます。 Kafka と Pulsar の両方が提供する配信保証は次のとおりです。

• 少なくとも一度は
• せいぜい1回
• ちょうど 1 回

「正確に 1 回」の配信により、メッセージごとに 1 つの関連付けられた出力が存在することが保証され、コンシューマーがクラッシュした場合にメッセージが処理されることが保証されます。ただし、これはConsumers APIでは不可能です。これにより、アプリケーションは Kafka クラスターのトピックからデータのストリームを読み取ることができるため、プラットフォームでほとんどの機能を作成する必要があります。これにより、ビジネスに必要なすべての機能に対して 1 つのクライアント ライブラリを使用することが難しくなり、大規模な作業では持続可能ではなくなります。

パルサーに入る

上で強調した Kafka の各制限について、 Pulsar には解決策があります。以下のセクションでは、パルサーの利点のいくつかを概説します。

永続的なデータ ストレージ

Pulsar は、Kafka が提供するメッセージ ストリーミングおよびパブリッシング機能を提供しますが、データを長期間保持する機能を追加します。

Pulsar は、Apache Bookkeeper を使用してデータ ストレージの永続性を提供します。ブックキーパーはデータを維持し、クラスター外でデータの永続性をオフロードするのに役立ちます。 AWS S3 などの他のデータ ストレージ メディアを使用してデータを保存し、ローカル ディスクの制限を超えてスケーリングすることができます。つまり、ストレージを気にせずにアプリケーションを簡単に拡張できます。

さらに、パルサーには、ホット ストレージ オプションとコールド ストレージ オプションの間でデータを移動するのに役立つ階層型ストレージ機能が含まれています。その後、データはビジネス ニーズに応じてコールド ストレージに保存できます。クラスターでは、ストレージ オプションのインフラストラクチャ サイズを継続的に変更する必要はありません。

Pulsar はまた、データのセグメントを不変にすることで、古いメッセージを Bookkeeper から安価なコールド ストレージ オプションに自動的に移動します。不変セグメントは安価なストレージに移動できるため、事実上、Pulsar は無限の量のデータを受け入れることができます。

開発者の経験

開発者の観点から見ると、Pulsar はすべての主要言語 (Java、Python、Go、および C#) 用の統合されたシンプルなクライアント ライブラリを提供します。ライブラリは、開発者がプラットフォームをすばやく使い始めるのに役立ちます。これは、アプリケーションを大規模に開発およびリリースする際に重要です。 Pulsar のバイナリ プロトコルは、必要に応じてクライアント ライブラリの機能を拡張し、ライブラリを成長に適したものにします。 (利用可能で公式にサポートされているPulsar クライアント ライブラリのリストは次のとおりです。 )

パルサー機能

Pulsar 関数は、開発者が Apache Heron、Apache Flink、または Apache Storm などのシステムをデプロイする必要なく、メッセージ ストリーム内のメッセージを処理できるカスタム コードを記述できるようにする、すぐに使用できる機能です。

Pulsar 関数は、サーバーレス コネクタ フレームワークの Pulsar IO で使用され、Pulsar との間のデータの移動を容易にします。このすぐに使えるシステムにより、Pulsar は Apache Cassandra などの外部 SQL および NoSQL データベースに接続できます。

さらに、このメッセージ処理はストリームネイティブです。つまり、メッセージはコンシューマーに配信される前にクラスター内で処理および変換されます。 Pulsar 関数は Pulsar メッセージング システムのコンピューティング インフラストラクチャであるため、開発者の生産性、トラブルシューティングの容易さ、運用の簡素化など、ビジネス レベルの目標をサポートします。これは、大規模な作業を行う際のアプリケーションとチームのパフォーマンスに不可欠な特性です。

スケーラビリティ

上記の機能とサービス、およびそれらのスケーラビリティへの影響に加えて、Pulsar は、企業のメッセージ ストリーミングとパブリッシングのニーズに対応するスケーラブルなオプションとなるさまざまな機能を提供します。

Pulsar の geo レプリケーション機能により、Pulsar は高度にスケーラブルになります。クラスターは、災害によってアプリケーションがダウンした場合に使用するために、データを世界中の複数の場所に複製します。レプリケーションは、同期および非同期でサポートされています。非同期レプリケーションは高速ですが、同期レプリケーションよりもデータ整合性の保証が少なくなります。

Pulsar は、トピックごとのブローカーの概念を使用して、同じブローカーがトピックのすべてのリクエストを確実に処理するようにします。 Pulsar アーキテクチャは、ブローカーベースのアプローチが Kafka クラスターと比較してシステムのパフォーマンスを向上させる方法を示しています。

まとめ

Kafka と Pulsar にはいくつかの類似点がありますが、使用するプラットフォームを選択する際 (特にスケーラビリティが必要な場合) に考慮する価値のある基本的な違いがいくつかあります。

Kafka のアーキテクチャ、ストレージ機能、および使いやすさには、組織の成長を妨げる可能性のある多くの課題があります。 Kafka クラスターを一定の範囲を超えてスケーリングしようとすると、費用がかかり、多くの場合、その価値よりも多くの問題が発生します。データを保存する方法からメッセージ変換をサポートする方法まで、Pulsar はスケーラビリティのために構築された次世代の統合された Kafka のチャレンジャーです。

Apache Pulsar 上に構築され、完全マネージド型サービスとして提供されるDataStax Astra Streaming について学びます。

メアリー・グリグルスキ著。 Mary は、DataStax のストリーミング開発者アドボケイトです。彼女は、Java、オープン ソース、およびクラウド ネイティブ、サーバーレス、イベント駆動型、マイクロサービス、リアクティブ アーキテクチャを含むクラウド テクノロジのコミュニティ アドボカシーとアウトリーチの開発に注力しています。