リアルタイムデータストリーミングの選択肢：Apache Kafka と Pub/Sub の比較分析

はじめに

こんにちは、クラウドエース データソリューション部 の尾杉です。

ビッグデータの時代において、リアルタイムデータ処理やメッセージングシステムの重要性はますます高まっています。データのストリーミングやメッセージングにおいて、Apache Kafka と Google Cloud Pub/Sub は非常に人気のある選択肢です。しかし、これら 2 つのシステムは、設計思想、アーキテクチャ、機能面で異なる特徴を持っています。

Google Cloud では、2024 年 4 月に Apache Kafka 向けマネージドサービス Google Cloud Managed Service for Apache Kafka の提供を開始し、Google Cloud で Apache Kafka が使いやすい環境となりました。

本記事では、Apache Kafka と Google Cloud Pub/Sub の違いについて、概要から機能比較まで解説し、それぞれの強みとユースケースを明らかにします。

Apache Kafka とは

Apache Kafka（以下、Kafka） は、LinkedIn によって開発され、後に Apache Software Foundation に寄贈されたオープンソースの分散メッセージングシステムです。Kafka の主な目的は、大規模なリアルタイムデータストリームの処理と分析を可能にすることです。このシステムは、耐障害性とスケーラビリティに優れており、イベントストリームの高スループットと低レイテンシーでの処理を実現します。

Kafka の設計は Producer と Consumer という 2 種類のクライアントによって構成されています。Producer はイベントやメッセージを生成し、それを Kafka に書き込みます。一方、Consumer は Kafka からメッセージを読み取り、処理する役割を持っています。Producer と Consumer は疎結合であり、それぞれが独立して動作することが可能です。

メッセージは Topic に整理されます。さらに、Topic は複数の Partition に分割されており、各 Partition は Kafka クラスタ内の異なる Broker に分散して配置されます。これにより、Topic に対する並列的な書き込みと読み込みが可能となり、スループットの向上を図ることができます。

Kafka クラスタの管理には、ZooKeeper と kRaft の2 つの方式があります。しかし、Google Cloud Managed Service for Apache Kafka では、Zookeeper はサポートされておらず、 kRaft のみがサポートされています。

最新バージョンの Kafka では、 ZooKeeper は廃止の流れで、Kafka 自体がクラスタ管理機能を提供する KRaft への移行が推奨されています。これにより、Kafka はメタデータの管理やクラスタ調整を自身で行うようになり、従来の ZooKeeper の役割を不要にすることで、システムの運用が簡素化されます。

Google Cloud Pub/Sub とは

Google Cloud Pub/Sub（以下、Pub/Sub）は、 Google Cloud が提供するフルマネージドのリアルタイム メッセージングサービスであり、非同期でメッセージを交換する仕組みを提供します。Pub/Sub では、データの送信者である Publisher が特定の Topic にメッセージを発行し、その Topic にサブスクライブしている受信者の Subscriber が、Subscription を通じてメッセージを受信します。

Pub/Sub の特徴として、高いスケーラビリティ、可用性、信頼性が挙げられます。これにより、リアルタイムデータ処理、イベント駆動型アーキテクチャ、データパイプラインの構築など、さまざまなユースケースに対応可能です。また、Pub/Sub は自動スケーリングをサポートしており、トラフィックの増減に応じて自動的にスケールアウトまたはスケールインを行います。

さらに、Pub/Sub はメッセージの順序保証や重複排除機能が備わっており、メッセージングの一貫性を維持しつつ、データを処理することが可能です。これらの機能から、 Pub/Sub は Google Cloud でのメッセージングサービスとして、多くのアプリケーションで採用されています。

Kafka と Pub/Sub の用語比較表

Kafka	Pub/Sub	説明
Broker	なし	Kafka クラスタ内のサーバーで、メッセージを格納および配信等のリクエストを受け、レスポンスを返す役割を担う。Pub/Sub では、Broker は存在せず、 Publisher がメッセージを発行する。
Producer	Publisher	メッセージを Topic に送信するクライアント。
Consumer	Subscriber	Topic からメッセージを受信するクライアント。
Consumer Group	なし	Kafka では、複数の Consumer を 1 つのグループにまとめ、メッセージ読み出しの負荷分散を行う。
Topic	Topic	メッセージのカテゴリまたはストリームで、メッセージが格納される単位。Kafkaでも Pub/Sub でも同様の意味を持つ。
Partition	Partition	Topic 内のメッセージを分割し、分散処理を可能にする。ただし、Pub/Sub は順序指定配信の場合に限る。
なし	Subscription	Topic からメッセージを受け取る方法を定義する。
Offset	ackIds	offset は、Kafka の各 Partition 内のメッセージが順序付けられた位置を示す識別子。ackIds は、Pub/Sub では、メッセージの処理完了を確認するための識別子。

Kafka と Pub/Sub の機能比較

Kafka と Pub/Sub は、それぞれの機能と特性にいくつかの違いがあります。以下では、両サービスの機能、コスト面での違いを比較し、それぞれのユースケースに最適な選択をするための情報を提供します。

機能面の比較

配信元と配信先のサポート

• Kafka と Pub/Sub の両方がリアルタイムデータの配信元と配信先として機能しますが、 その性能は Kafka の場合はクラスタの容量など構成に依存しています。一方、Pub/Sub はデフォルトで高いスループットを持ち、Google Cloud のインフラストラクチャに基づいてスケーラビリティを提供します。

データ変換とフィルタリング

• Kafka は Kafka Streams や Connect API を利用してデータ変換、フィルタリングが可能です。ただ、Google Cloud では、いくつかのテンプレートが提供されており、Dataflow を使用して Kafka から BigQuery にデータを書き込むといったことが、簡単にできます。Pub/Sub は Cloud Functions や Dataflow などの Google Cloud サービスを使用して、データ変換とフィルタリング機能を提供します。特に、Pub/Sub には Pub/Sub to BigQuery などの多彩なテンプレートが揃っており、これを活用することで、簡単にデータ変換やフィルタリングを行うことが可能です。

再試行ポリシーとリトライ

• Kafka は手動またはカスタムの再試行ポリシーを提供し、Producer および Consumer の設定で細かく制御できますが、Pub/Sub はビルトインの再試行ポリシーを提供し、設定が容易です。また、Kafka は無制限のリトライ設定が可能であるのに対し、Pub/Sub は設定の範囲に制限があります。

順序保証とメッセージのレプリケーション

• Kafka は Partition ごとの順序保証とクラスター内でのレプリケーションをサポートします。Pub/Sub もオプションで順序保証が可能で、複数のゾーン間でのレプリケーションを提供します。ただし、レプリケーションは 1 つのリージョン内でのみ行われます。

セキュリティと暗号化

• 両サービスとも、顧客管理の暗号鍵（以下、CMEK）とGoogle が管理する暗号鍵（以下、GMEK）を利用したデータ暗号化をサポートしています。両サービスともデフォルトは GMEK になります。

運用と保守

• Kafka は高度な設定が可能ですが、Topic レベルでの構成設定など専門知識が必要です。一方、Pub/Sub は直感的に操作しやすく、専門知識が少なくても運用が可能な印象を受けます。

Kafka と Pub/Sub の主要機能の比較表

項目	Kafka	Pub/Sub	主要差分
サポート対象（転送元）	Producer（イベントを書き込むクライアントアプリケーション）。 例：サーバーのログ、ユーザーの購入履歴、IoT のセンサーデータなど	Publisher（データ例はKafkaと同様）	Pub/Sub はデフォルトで割り当て上限あり
サポート対象（転送先）	Consumer（イベントを読み取り、処理するクライアントアプリケーション）。 例：データ分析基盤、データ保存基盤など	Subscriber（データ例はKafkaと同様）	同上
データ変換処理	直接的な変換はサポート外。 Dataflow や、Kafka API（ Streams や Connect ） を使用してデータ処理が可能	直接的な変換はサポート外。 Cloud Functions や Dataflow を使用してデータ変換が可能	Kafka は独自 API でのデータ変換が可能。Pub/Sub は Google Cloud のサービスを利用
リトライ	・Producer 側リトライ処理 retries で指定された回数、および構成パラメーター delivery.timeout.ms で指定された時間に達するまで、メッセージを自動的に再送信する。この時間を超えると、メッセージ送信はタイムアウトになり、失敗する。詳細はこちら ・Consumer 側リトライ処理 手動オフセット管理で可能。コンシューマーがメッセージを読み込むとき、処理が成功したメッセ－ジのオフセットのみを手動でコミットすることで、失敗したコミットを再試行可能。	・Publisher 側リトライ処理 サブスクリプションの再試行ポリシーでは、即時再配信または指数バックオフの 2 つが選択可能。 ・Subscriber 側リトライ処理 Pub/Sub クライアント ライブラリがパブリッシュ リクエストを再試行可能。以下の再試行設定がある。 - 初期リクエストのタイムアウト - 再試行遅延 - 合計タイムアウト	Kafka は手動で細かく制御可能
1 回限りの配信	サポートあり。デフォルトは少なくとも 1 回の配信。 詳細はこちら	pull サブスクリプションタイプのみサポートあり。デフォルトは少なくとも 1 回の配信。 詳細はこちら	Pub/Sub はサブスクリプションタイプの制限あり
転送順序	Partition 内での順序保証	デフォルトでは順序保証なし。ただし、オプション設定で順序保証が可能。	Pub/Sub はオプションで順序保証が可能
転送可能容量	クラスタの構成、Broker の数、Partition の数などに依存	基本的に無制限。メッセージサイズ、属性数、属性キーサイズ、属性値サイズの制限あり	Pub/Sub は無制限だが、サイズ制限あり
サブスクリプションタイプ	poll 方式 ( pull )。 時間間隔で polling 設定できるので、pull ベースになっている。push はなし。 詳細はこちら	以下の 4 つの方式がある。 ・pull ・push ・BigQuery のサブスクリプション ・Cloud Storage のサブスクリプション 詳細はこちら	Pub/Sub の方が選択肢が多い
メッセージレプリケーション	クラスタ内で Leader Replica と Follower Replica を使用し、レプリケーションファクターによって高可用性と耐障害性を実現。 詳細はこちら	Pub/Sub では、3 つのゾーンを使用してデータを保存。少なくとも 2 つのゾーンに対する同期レプリケーションが保証。レプリケーションはゾーン内でのみ行われる。 詳細はこちら	Kafka はクラスタ内でのレプリケーション、Pub/Sub は複数のゾーン間でのレプリケーション
メッセージ確認応答トラッキング	Consumer によるオフセット管理で実装。手動で管理する必要がある。	確認応答のトラッキングは自動。メッセージごとに処理が終わったことを確認するため、ACK が Subscriber から返ってくるかトラッキングする。	Kafka は手動管理、Pub/Sub は自動
タスク/メッセージの保持期間	Topic のデフォルト保持期間は約 1 日。メッセージのデフォルト保持期間は 7 日間。設定によって変更可能。	Topic でのメッセージ保持期間は最大 31 日。Subscription の確認応答がなければデフォルトで 7 日間保持。設定で延長可能。	Pub/Sub の方が長期間のメッセージ保持が可能
タスク/メッセージの最大サイズ	デフォルトで約 1MB（設定で拡張可能）。大規模なメッセージには制限がある。	メッセージサイズは 10MB。	Pub/Sub の方がメッセージサイズが大きい
データ暗号化	Google 管理の暗号鍵（デフォルト）または顧客管理の暗号鍵（CMEK）を使用してメッセージを暗号化可能。セキュリティにおいて柔軟性がある。	同左	差異なし
認証・認可	IAM 経由の認証	同左	差異なし

Kafka と Pub/Sub の料金比較

Kafka と Pub/Sub の料金を比較するために、具体的な料金例を用いて比較表を作成しました。以下の比較では、東京リージョン（asia-northeast1）での料金を基にしています。

1. 料金体系の概要

Kafka

• クラスタ料金: CPU とメモリの使用量に基づく従量課金。
• ストレージ料金: 使用したストレージの量に基づく従量課金。
• データ転送料金（ネットワーク料金）: リージョン内外のデータ転送に基づく従量課金。

Pub/Sub

• メッセージ送信料金: パブリッシュされたメッセージのデータ量に基づく従量課金。
• メッセージ受信料金: サブスクライブされたメッセージのデータ量に基づく従量課金。
• ストレージ料金: メッセージの保持期間に基づく従量課金。

Kafka と Pub/Sub の料金比較表

項目	Kafka	Pub/Sub
クラスタ料金	$0.0765/slot-hour（vCPU + RAM）	N/A
メッセージ送信料金	N/A	初期 1GB/月 までは無料、それ以降は $40/TiB（約 $0.04/GB）
メッセージ受信料金	N/A	初期 1GB/月 までは無料、それ以降は $40/TiB（約 $0.04/GB）
ストレージ料金	ローカルストレージ: $0.221/GiB-month 長期保管: $0.115/GiB-month	$0.27/GiB-month
データ転送料金（ネットワーク料金）	$0.01/GiB（外部ネットワークへのデータ転送）	$0.12 ～ $0.23/GiB（リージョン外のデータ転送）

2. 具体例を使ったシナリオ比較

シナリオ1: 低トラフィックアプリケーション

• 使用条件:
  • 1vCPU、4GB RAM の小規模クラスタ
  • 10GB/月 のメッセージ送信と受信
  • 20GB のデータ保持（7日間）

項目	Kafka	Pub/Sub
クラスタ料金	約 $55.08/月	N/A
ストレージ料金	約 $2.3/月（20GB の長期保管）	約 $5.4/月（20GB の保持）
メッセージ送信/受信料金	N/A	約 $0.80（月10GB 送信・受信）
合計	約 $57.38/月	約 $6.2/月

シナリオ2: 高トラフィックアプリケーション

• 使用条件:
  • 4vCPU、16GB RAM の中規模クラスタ
  • 5TB/月 のメッセージ送信と受信
  • 200GB のデータ保持（30 日間）

項目	Kafka	Pub/Sub
クラスタ料金	約 $220.32/月	N/A
ストレージ料金	約 $23.0/月（200GB の長期保管）	約 $54/月（200GB の保持）
メッセージ送信/受信料金	N/A	約 $400/月（5TB 送信・受信）
合計	約 $243.32/月	約 $454/月

上記より、Kafka は、低トラフィックでは比較的高コストになりますが、高トラフィックの場合はコスト効率が良くなることから、大規模なリアルタイムデータ処理に向いていることが分かります。
Pub/Sub は、軽量でシンプルなメッセージングサービスであり、データ送信・受信量が少ない場合や、シンプルなメッセージングニーズにはコスト効率が高いです。ただし、高トラフィックの場合データ転送料金が増加するため、合計コストが高くなる可能性があります。

おわりに

本記事では、Google Cloud で利用できる 2 つの主要なメッセージングサービスである Kafka と Pub/Sub の機能、およびコスト面での違いを詳細に比較しました。

Kafka は、規模の大きいエンタープライズレベルのデータストリーミング要件に対して、高度な制御と柔軟性を提供する一方で、構成の複雑さから専門的な知識が求められることがあります。これに対し、Pub/Sub は、シンプルでスケーラブルなソリューションを提供し、迅速な設定と運用が可能です。どちらのサービスも高い可用性と信頼性を持ち、それぞれの強みを活かして、異なるユースケースに最適化されたデータ処理とメッセージングを提供します。

リアルタイムデータ処理の世界では、これらのツールの重要性は増すことが考えられます。読者の皆様に最適なプロダクト選定が行えるよう、本記事が役立つことを願っています。