翻訳者 | 陳俊

校正：孫淑娟

この記事では、Apache Kafka と Redpanda という 2 つのオープンソース データ ストリーミング テクノロジーを、クラウド ネイティブのリアルタイム処理機能の観点から比較し、プロジェクトでどちらを選択するかについて説明します。

現在、Apache Kafkaはデータストリーム処理分野のデファクトスタンダードとなっているだけでなく、類似製品の出現も促しています。Redpandaもその一つで、軽量でC++互換のKafka実装です。以下では、Apache KafkaとRedpandaの違い、そしてそれらがKafkaのエコシステム、ライセンス、そしてコミュニティの採用にどのような影響を与えるかについて解説します。

1. Apache Kafkaの成長曲線

Kafka 導入の成熟度に関しては、ほとんどの企業がさまざまな程度までは以下のプロセスを経てきました。

• 1 つまたはいくつかのユース ケースから始めて、そのビジネス価値をすぐに実証します。

• 最初のアプリケーションを本番環境にデプロイし、24 時間 365 日実行します。

• さまざまな分野、ビジネス部門、テクノロジー部門からのデータフローを最大限に活用します。

• 分散データセンターへの移行のための中央システム。

次のグラフは、Maven を使用して Kafka Java クライアント ライブラリをダウンロードする月間アクティブ ユーザーの増加曲線を示しています。

出典: ソナタイプ

多様なデータストリームの潜在的なユースケースとビジネス価値こそが、Kafka の導入曲線の継続的な成長を牽引する主な要因であることは明らかです。次の図は、Kafka の低レイテンシ、スケーラビリティ、信頼性、そして真の分離性によって、様々な業界が様々なビジネスシナリオで生み出す豊富なデータ価値を示しています。

2. Redpanda: Kafkaと互換性のあるデータストリーム

前のセクションでは、Kafkaの現状について概要を説明しました。次は、Kafka業界の新参者であるRedpandaについて見ていきましょう。

データ ストリーミング プラットフォームとして、Redpanda は自社の Web サイトで次のような市場ポジショニングと製品戦略を示しています。

• Go to Java: JVM も ZooKeeper も必要としないインフラストラクチャです。
• C++ で設計: この設計は、Apache Kafka よりも優れたパフォーマンスを提供することを目的としています。
• 単一バイナリ アーキテクチャ: 他のライブラリやノードに依存しません。
• 自己管理と自己修復: オンプレミスとクラウドの両方に導入できるシンプルでスケーラブルなアーキテクチャです。
• Kafka 互換: 既存のアプリケーション、ツール、統合された Kafka プロトコルに対するすぐに使用できるサポートを提供します。

3. プロジェクトに適したKafka実装を選択する方法

評価と定義を行うには、ビジネスケースの要件から始める必要があることがよくあります。これには、稼働時間、SLA、災害復旧戦略、エンタープライズサポート、運用ツール、マネージドクラウドサービス、メッセージング、データ収集、データ統合といった機能やアプリケーションが含まれます。以下では、オープンソースプロジェクトであるApache KafkaとRedpanda（Kafkaプロトコルの再実装）を比較し、お客様の具体的なニーズに基づいた評価と選択を支援します。

Redpanda と Apache Kafka は同じ高レベルの提案を共有しているので、まずはそれらの類似点を見てみましょう。

• データ ストリーム アプローチを使用して、大量のデータを継続的かつリアルタイムで処理します。
• 分散ストレージ層を使用して、アプリケーションとドメインを分離します。
• さまざまなデータ ソースやデータ シンクと統合できます。
• ストリーミング処理を使用してデータを相関させ、リアルタイムでアクションを実行します。
• 自己管理型の運用と、完全に管理されたクラウド製品を使用する機能の両方を提供します。

次に、Redpanda の機能を詳しく見てみましょう。

4. 導入オプション: 自己管理とクラウドサービス

今日、企業はデータフローへの飽くなきニーズを抱えています。多くの業界ではクラウドファースト戦略が採用されていますが、コスト、レイテンシ、セキュリティ要件の観点から、特定のワークロードはエッジで稼働させる必要があります。この問題に対処するには、Redpandaを自社で構成するか、「製品としてのRedpanda」を購入して自社環境に導入するかを選択できます。つまり、Redpandaを自社でホスティングするのではなく、Kubernetes（通常はベンダーの外部制御レイヤーを搭載）を使用するか、ベンダーが完全管理するクラウドサービスを活用して、自社環境内のデータレイヤーとしてRedpandaを導入することが可能です。

Redpandaの様々なデプロイメントオプションは、Apache KafkaのConfluentデプロイメントオプションと多少似ています。ただし、唯一の欠点は、RedpandaがクラウドサービスとエンタープライズレベルのSLAに関する公式ドキュメントを提供していないことです。

5. 独自のクラスターが付属（BYOC）

自己管理型データストリームクラスタとフルマネージドクラウドサービスの活用に加えて、3つ目の選択肢として、Bring Your Own Cluster（BYOC）があります。この選択肢では、エンドユーザーは、データセンターやクラウド内のVPCなど、ベンダーが部分的に管理するソリューションを自社のインフラストラクチャ内に導入できます。Redpandaのスローガンにあるように、「Redpandaクラスタはお客様のクラウドサービス内に常駐し、Redpandaによって完全に管理されます。そのため、お客様のデータはお客様の環境から外に出ることはありません。」もちろん、これにはいくつかの問題も潜んでいます。

• サプライヤーはどのようにしてデータセンターまたは VPC にアクセスできますか?
• クラスターをいつどのようにスケーリングするかを誰が決定しますか?
• バグを修正したりバージョンをアップグレードしたりするために、クラスターをいつ、どのようにデプロイする必要がありますか?
• SLA を保証するのは誰ですか? サプライヤーですか?
• 規制産業における安全管理とコンプライアンスをどのようにサポートできるでしょうか?
• サプライヤーが自社の環境で何をしているかをどうすれば知ることができますか?
• サードパーティのリスク評価をカスタマイズするにはどうすればよいですか?

上記の理由から、ユーザーはSaaS製品に責任を委ねるか、自ら管理するかのいずれかを選択します。一方、クラウドサービスプロバイダーは、多くの場合、自社の環境内でのみマネージドサービスを提供できます。

6. これはコミュニティ製品であると同時に商用製品でもあります。

Redpandaの販売アプローチは、Confluentのデータストリーム販売アプローチを反映しているようです。本番環境向けには無料のコミュニティエディションを提供しており、エンタープライズエディションでは階層型ストレージ、自動データバランス調整、24時間365日対応のエンタープライズサポートなどの機能が追加されています。

次に、Redpanda と Apache Kafka の技術的な違いについて詳しく説明します。

7. Kafkaプロトコルの互換性

API互換性を提供するために、RedpandaはKafkaプロトコルを再実装しています。しかし、これはKafkaそのものではないため、Kafkaエコシステムの他のコンポーネント（Kafka Connect、Kafka Streams、REST Proxy、Schema Registryなど）が、Kafkaプロトコルとその独自実装のみを使用する非Kafkaソリューションと統合された場合に、同じように動作することを保証することはできません。結局のところ、APIが100%互換性があっても、基盤となる動作は一部異なります。もちろん、これは必ずしもデメリットではありません。例えば、Redpandaはパフォーマンス最適化のためにC++の使用に重点を置いており、特定のパフォーマンスとメモリ状況では、C++はJavaやJVMよりも優れたパフォーマンスを発揮します。

現在、Apache Kafka には、データ統合用の Kafka Connect とストリーム処理用の Kafka Streams が含まれています。多くの Kafka 互換プロジェクトと同様に、Redpanda は製品から重要だが「役に立たない」部分を削除しています。そのため、100% のプロトコル互換性を謳っていても、Apache Kafka プロジェクトのすべてを再実装しているわけではありません。

8. 低レイテンシとベンチマーク

プロジェクトの開始時には、パフォーマンス要件を検討する必要があります。これには、Apache Kafka、Apache Pulsar、Redpandaを用いた概念実証（POC）テストの実施が含まれることがよくあります。パフォーマンスやスループットの「ベンチマーク」を恣意的に使用することは避けるべきです。これらのベンチマークは通常、特定の問題に対する設定の参考資料に過ぎません。同僚のJack Vanlightlyは、ベンチマークの概念を説明するために次の図を使用しました。ご参照ください。

出典: ジャック・ヴァンライトリー

Redpandaのベンチマークを見ると、Kafkaは高スループットのプロデューサー向けに構築されていないことに気付くかもしれません。まさにこの点において、Redpandaはスループットの点でKafkaを上回っています。そもそも、1GB/秒のユースケースで、これほど高いスループットを実現するためにプロデューサーを4つしか作成しない人がいるでしょうか？ベンチマークだけではすべてが明らかになるわけではないことは明らかです。多くの場合、私たち自身でテストと実験を行う必要があります。

9. ソフトリアルタイム vs. ハードリアルタイム

リアルタイムパフォーマンスについて話すとき、通常はデータ処理パイプラインがエンドツーエンドの伝送に少なくとも数ミリ秒かかることを意味します。これは実際にはソフトリアルタイムの一種であり、Apache Kafka、Apache Pulsar、Redpanda、Azure Event Hubs、Apache Flink、Amazon Kinesisなどのプラットフォームはこのように実装されています。では、ハードリアルタイムとは何でしょうか？

ハードリアルタイムには、遅延ゼロでピーク負荷のない確定的なネットワークが必要です。典型的なシナリオとしては、製造、自動車、ロボット工学、証券取引における組み込みシステム、フィールドバス、PLCなどが挙げられます。「Time-Sensitive Networking (TSN)」というキーワードで検索すると、さらに詳しい情報が得られます。KafkaとRedpandaは、この種のOT（運用技術）ではなく、IT（情報技術）に適していることは明らかです。OT分野では、C言語やRust言語のみで構築された組み込みソフトウェアを使用する必要があることがよくあります。

10. ZooKeeperは不要

Redpandaのもう一つのユニークな特徴は、JVMではなくC++を使用していることに加え、ZooKeeperと2つの複雑な分散システムを必要としないことです。もちろん、KIP-500に準拠したKafkaは、ZooKeeperなしで本番環境にデプロイすることも可能です。

RedpandaのZooKeeperレス・データストリーミングは、スケーラビリティと信頼性の面でKafkaを大きく上回り、非常に使いやすいという利点があります。しかし、新しいZooKeeperレス・アーキテクチャは、本番環境に導入されるまでにはまだ時間がかかり、新しいKafkaクラスターでのみサポートされています。今年中にダウンタイムとデータ損失ゼロの移行シナリオをサポートできるようになると期待されますが、成熟したソフトウェア製品であるため、厳格なリリースサイクルが適用されます。

11. Redpandaのデータフロー

C++実装のおかげで、Redpandaは軽量かつ効率的です。これは、ハードウェアが限られているエッジコンピューティング環境では非常に実用的です。JVMベースのKafkaエンジンと比較して、Redpandaはより高度なデータストリーミングユースケースのメッセージキューとして使用でき、完全なエンドツーエンドのデータパイプラインをターゲットとすることができます。さらに、RedpandaはApache Kafkaよりもレイテンシスパイクが低いです。もちろん、単一のKafkaブローカーを展開するエッジユースケースでは、産業用PC（IPC）が4～8GBのメモリを提供できる場合、Kafkaやその他のテクノロジーを中心としたデータストリーミングプラットフォーム全体を展開できます。

12. クラスタ間データレプリケーション

今日では、様々なアプリケーションで複数のKafkaクラスターを利用することが一般的です。災害復旧、集約、データ主権、オンプレミスからクラウドへの移行といったユースケースでは、国や地域に応じて異なるタイプのデータストリームクラスターが必要になります。

クラスター間レプリケーションは、Apache Kafka の不可欠な要素です。MirrorMaker 2（Kafka Connect ベース）は、このようなユースケースをサポートします。もちろん、Confluent Replicator や Cluster Linking といったベンダーが提供する高度な独自ツールを活用すれば、オフセット同期などの操作のための追加インフラストラクチャを必要とせずに、データレプリケーションのユースケースをより便利かつ信頼性の高いものにすることができます。

下の図に示すように、Kafkaエコシステム内のデータフローは、分散型データグリッドの基盤として最適です。さらに、RedpandaはデータレプリケーションにKafkaのMirrormakerを利用することもできます。

13. Apache KafkaとRedpandaの機能以外の違い

RedpandaとApache Kafkaのどちらかを選択する際には、技術的な評価が優先されることが多いです。しかし、ライセンス、導入曲線、総所有コスト（TCO）といった機能以外の要素も、データストリーミングプラットフォームの構築を成功させる上で、同様に重要な要素となる場合があります。

1) ライセンス

Apache Kafka は非常に寛容な Apache License 2.0 を採用しているため、クラウドサービスプロバイダーを含む誰もが、このフレームワークを使用して社内アプリケーション、商用製品、クラウドサービスを構築できます。コミッターとコントリビューターは、さまざまな企業や個人から選出できます。

一方、Redpandaはより厳格なソースコード公開ライセンス（BSL）の下でリリースされています。これは、クラウドサービスプロバイダーがRedpandaの成果物をサービスとして無料で提供することを防ぐことを目的としています。意図は良いものですが、様々なコミュニティやベンダーによる広範な採用を制限しています。KafkaなどのApacheプロジェクトと比較すると、外部の貢献者、コミッター、そして他のベンダーがこの技術を選択する可能性ははるかに低いです。もちろん、これはRedpandaの採用曲線にも大きな影響を与えています。

2) 成熟度、コミュニティ、エコシステム

Kafkaは、包括的なドキュメント、大規模な専門家コミュニティ、そして幅広いツールサポートを誇ります。操作も非常にシンプルです。現在、オンラインコース、書籍、ミートアップ、セミナーなど、ローカルおよびオンラインのKafkaリソースからお選びいただけます。

Redpandaは全く新しい製品であり、実装も異なります。ベンダーが提供するもの以外にドキュメントは限られており、専門家によるサポートもないため、Redpandaのウェブサイトにある機能リストをよくご確認ください。例えば、RedpandaのRBAC（ロールベースアクセス制御）に関するドキュメントには、「RedpandaコンソールのRBACは、コンソールユーザーのアクセスのみを管理し、Kafka APIを介してやり取りするクライアントのアクセスは管理しません。Kafka APIへのアクセスを制限するには、Kafka ACLを使用する必要があります」と記載されています。また、数年前のApache Pulsarユーザーのように、製品機能のマーケティングに惑わされないようご注意ください。

3) 総所有コストとビジネス価値

TCOには、製品やクラウドサービスの購入コストだけが含まれるわけではありません。ご存知のとおり、データストリーミングプラットフォームには、運用と統合のための専任エンジニアに加え、アプリケーション構築のための高額なプロジェクトマネージャー、アーキテクト、開発者が必要です。

Redpandaは「C++の方がCPUリソースをより効率的に利用できる」と主張しているのをよく耳にするかもしれません。しかし、問題はKafkaが実際にはCPU依存になることは少なく、むしろI/Oによる制限が大きいということです。RedpandaとKafkaのネットワークとディスク要件はほぼ同等であるため、インフラストラクチャのTCOという点ではRedpandaとKafkaに大きな違いはないと言えるでしょう。

14. Redpanda を選ぶべきなのはどんなときですか?

Apache Kafka の代わりに?

以下の状況では、Apache Kafka よりも Redpanda を優先して評価および検討できます。

運用チームはJVMログを処理・分析できないため、C++インフラストラクチャが必要となります。ただし、これはメッセージングの中核部分のみを対象としており、データ統合、データ処理、その他Kafkaエコシステムの機能は対象外です。

微妙なパフォーマンスの違いは重要ですが、厳密なリアルタイム パフォーマンスは必要ありません。

ラップトップおよび自動テスト環境でのシンプルで軽量な開発。

15. 要約

この記事では、Apache KafkaとRedpandaのどちらを選ぶべきかについて、技術的観点と非機能的観点の両方から考察します。一般的に、エンタープライズグレードのソリューション、フルマネージドクラウドサービス、幅広いエコシステム（多様なコネクタやデータ処理機能など​​）を必要とし、10ミリ秒のレイテンシと複数のp99ピークを許容できる場合、Apache KafkaはRedpandaよりも信頼性の高い選択肢となる可能性があります。

オリジナルリンク: https://dzone.com/articles/when-to-choose-redpanda-instead-of-apache-kafka

翻訳者紹介

51CTOのコミュニティエディターであるJulian Chenは、ITプロジェクトの実装において10年以上の経験を有しています。社内外のリソースとリスクの管理に長けており、ネットワークと情報セキュリティに関する知識と経験の普及に注力しています。