はじめに
秋葉原ラボでは大規模データ処理基盤の研究・開発・運用を行っており、データの転送や解析システムのHubとしてPubsubシステムの重要性が高まっている。
Pubsubメッセージングモデルは、非同期メッセージングパラダイムの一種であり、メッセージの送信者（出版側）が特定の受信者（購読側）を想定せずにメッセージを送るようプログラムされたものである（wikipedia）。Pubsubモデルを用いることでシステムアーキテクチャにおいてコンポーネント同士を疎結合にし、高スケーラビリティを実現するメッセージングパターンである。このモデルに基づいたソリューションは既に複数存在するが、今回は特に注目されているApache KafkaやGoogle Cloud Pub/Subを紹介し、システム面で重要と思われる機能を比較する。
Kafkaは、分散Pubsubメッセージキューを中心にした高スループット・低レイテンシを実現するストリーム処理プラットフォームである。元々LinkedIn社で開発されApache Projectに寄贈されて以降、多くの会社で使用されている。
現在Kafkaの主なサポートをしているのはConfluent社注1である。
Google Cloud Pub/Subは、Googleが提供する低レイテンシやセキュリティ等のエンタープライズ向けの機能を重要視したPubsubシステムである。Google Cloud Platform(以下GCP)で提供しているサービスの一つであるため、GCPの提供するサービスと容易に連携できる。また、GCPからだけではなく外部のシステムからも利用可能である。
図1にあるGoogle Cloud Pub/Subは、概念やメッセージングの仕組みでApache Kafkaと大きな違いはないが、機能面でいくつか相違点がある。
機能比較
※ Apache Kafkaのバージョンは 0.10.1
※ Cloud Pub/Subの情報は2016/11/11現在に基づく
データレベル
| Kafka | Cloud Pub/Sub | |
|---|---|---|
| ログ保存期間 | ユーザが設定可能
（デフォルトで7日間） |
7日間固定 |
| 転送セマンティクス | 設定によって様々なセマンティクス実現が可能 | at-least-once |
| 転送順序 | パーティション毎で保障される | 順序保障はない。 |
| データアクセス方法 | Javaクライアント注2
Kafka RPC
|
幾つかの言語のクライアントが用意されている注3 |
| Subscriber | Pull方式
group.idを指定することで同じデータを参照することが可能 |
Pull方式とPush方式で選択可能
subscriptionを指定することで同じデータを参照することが可能 |
システムレベル
| Kafka | Cloud Pub/Sub | |
|---|---|---|
| DISASTER RECOVERY/REPLICATION | replication factorを指定することでクラスタ内のレプリカ数を設定可能
クラスタ間でtopicを複製するときはMirrorMakerを利用 |
ユーザが意識せずに自動的にレプリケーションが行われる 全メッセージは、幾つかのリージョンにまたがってレプリケーションされる SLAによると「SLO of at least 99.95%」 |
| LOG COMPACTION | deleteかcompactか設定可能deleteの場合、TTLよりも古いデータを削除し、compactの場合、keyごとにまとめる | 設定不可 |
| クォータ注4 | 設定可能(デフォルトは9223372036854775807) | オペレーションによりデフォルトクォータ値が定まる。 |
| セキュリティ | Kerberos/TLS認証（Kafka 0.9から）
実行データ（data in motion）の送受信はTLSによる暗号化は可能である。 保存データ（data at rest）の暗号化は、ユーザの実装が必要となる。 |
Google CloudのIAM経由の認証
エンドポイント間のデータは暗号化されHTTPS経由で送られる |
| モニタリング | KafkaのメトリクスはJMX経由で取得
LinkedInのKafka Monitor: 監視やクラスタのテスト LinkedInのBurrow: ログの欠損を監視 Datadog等の監視ソリューションによるパフォーマンス監視
|
API経由でexportされたmetricsをStackdriverで監視 |
エコシステム
Cloud Pub/Sub
Google Cloud Platformのシステムであるため、Cloud Storage, Cloud Logs, Cloud Monitoring等のCloud Platformシステムと連携されている。Pubsubの強みを活かし、Apache Kafkaのコアであるデータストリーム処理もCloud Dataflow/Apache Beamを用いて可能である。
Kafka
一方、Kafkaは元々特定のシステムとの連携を目指していない、且つOSSであるため、様々なプロジェクトとのインテグレーションができる。
Kafka Connect
Kafka ConnectはKafkaと既存のデータストアやアプリケーションを繋ぐ役割を持つ高スケーラビリティ・高信頼性フレームワークである。Kafka ConnectにはSourceとSinkの二種類のConnectorがあり、Source Connectorを起動しておくことで自動的にデータストアからKafkaにデータを貯めることが可能になりSink Connectorを起動しておくことでKafkaからデータストアやアプリケーションへデータを流すことができる。
現在数多くのシステムとのconnectorが開発されており、Kafka connectorより参照できる。
ストリーム処理
- Kafka Streams
- Kafkaで提供されているJavaライブラリ
- シンプルなストリーム処理を直ぐに実現でき、より複雑な処理を行うプラットフォームのコアコンポーネントにもなる
- Apache Samza
- Kafkaを中心に据えたハイレベル分散ストリーム処理フレームワーク
- Hadoop Yarn上で動作するため高い耐障害性を実現することが可能
- その他
- 上記の以外にも、Apache Flink, Apex, Ignite, Storm, Spark等の汎用性の高いフレームワークとの統合可。詳しくはこちらを参照。
まとめ
Big/Fast Dataが求めれる今日、Pubsubは多くのシステムに不可欠なコンポーネントになるため、今回機能比較を行ったApache KafkaとGoogle Cloud Pub/Sub以外も幾つかのPubsubシステムが存在している。
- Amazon Kinesis Stream
- Amazon Web Serviceが提供しているPubsubサービス
- セマンティクスは「at least once」を保証
- Amazon Kinesis Client Library(KCL)を利用してKinesisとデータ連携を実現することが可能
- DistributedLog
- Pubsubシステムではないが、安定した分散ログ処理を可能としPubsubシステムの構築を容易にする
- Kafkaとの相違点は、“A Technical Review of Kafka and DistributedLog”参照
他は、Redis PubSub、RabbitMQ PubSubなどがある。
また、Cloud Pub/SubやApache Kafkaを比較すると、細かい相違点を除けば、クラウドvsオンプレという運用の違いが大きい。そのため、価格の比較は難しいと思われるが、Cloud Pub/Subの場合、オペレーション数＋ストレージ＋ネットワークで計算される。また、昨今Apache Kafkaのクラウド化の進化が見られる。IBM Message HubやCloudKafkaはその例の一つである。
注1: LinkedInのKafka開発チームがスピンアウトして立ち上げた会社
注2: 最初からJVM中心のプロジェクトだったため
注3: RESTのラッパー
注4: マルチテナントのクラスタに於いて、特定のサービスがブローカーやネットワークリソースを独占しないように、クライアント(グループ)別にクォータ（転送バイトレートの上限）を設けることで制限ことが可能