アドテク本部の成尾です。

9/6 に開かれた GCP Next 2016 Tokyo では Spotify が Apache Kafka から Cloud Pub/Sub に載せ替えたという事例がありましたが
実際に性能や機能の面でどのような違いがあるのか気になった事もあり
今回は、GCP の Cloud Pub/Sub について調べてみました。

 

Kafka と Cloud Pub/Subの違い

Kafka は自前で環境を用意し、設定をし、運用をしていく必要がある。（その分柔軟に設定が可能）
Cloud Pub/Sub はマネージドサービスのため設定に柔軟性はないが運用の必要がない。
ここまでは、あえて言わなくても皆さんご存知かと思いますが
調べて行って主に気になった点としては以下の通りです。

ログの保存期間

• Kafka 7 日間（ただし設定で増やせる）
• Cloud Pub/Sub 7 日間固定

 

順序の保証

• Kafka はメッセージの順番が保証されている
• Cloud Pub/Subはメッセージの順番が保証されていない（IDやPayloadを利用してアプリ側での対応が必要になる）

 

認証のサポート

• Kafka は Version 0.9 から kerberos を利用した認証がある（それ以前の Version ではない）
• Cloud Pub/Sub は IAM を利用した認証がある

 

レプリケーション（耐障害性）

• Kafka は MirrorMaker を利用して可能、ただし2つのClusterでレプリケーションがどこまで終わっているか保証がない
• Cloud Pub/Sub は複数のゾーン、複数のサーバーで取られているので気にする必要がない（必ずメッセージが到達することを保証）

 

SLA

• Kafka は存在しない（自前管理のため）
• Cloud Pub/Sub は SLO (Service Level Objective) として月の稼働率 99.95%

 

アクセス方法

• Kafka は Java で書かれた API または kafka RPC client をラップした各種クライアントを必要とする（Confluent の REST Proxy が存在する、また Kafka Version 0.9 からは Kafka Connect による REST API が可能なようです）
• Cloud Pub/Sub は REST API でアクセスが可能

 

パフォーマンス

• Kafka は運用するハードウェア、台数に依存する（Spotify によると当時 Version 0.8 を利用していて、頭打ちとなる上限では要求仕様を満たせなかった）
• Cloud Pub/Sub は Default で秒間 10,000 メッセージ、リクエストし上限をあげると 1,000,000 メッセージ以上（Spotify の検証では秒間 2,000,000 メッセージ を叩き出している）

 

メッセージ最大サイズ

• Kafka はデフォルトで 約 1MB（10000000 bytes） （複数の設定項目変更で上げられるがどこかで上限があるはずなので後日検証します）
• Cloud Pub/Sub は 10 MB

 

その他

• Cloud Pub/Sub は GCP 内に限定されずアクセスが可能で、データ自体も暗号化されています。

 

Cloud Pub/Sub アーキテクチャ

※ https://cloud.google.com/pubsub/docs/overview より抜粋

事前に管理画面より作成した Topic に対してメッセージを送信します。
受け取る Subscriber 側は複数の Topic から受け取ることもできますし
同じメッセージを複数の Subscriber で受け取ることも可能です。
また受け取る方法としては Push, Pull どちらかを Topic に設定し選択可能です。

 

Push, Pullの違い

※ https://cloud.google.com/pubsub/docs/subscriber より抜粋

 

Push では Cloud Pub/Sub が受け取ったメッセージを Subscriber にほとんど遅延なく送ってもらえますが
受け取るエンドポイントに関しては https のみとなり
Web上に公開されている（アクセス制限のない状態）が必要となります。

Pull では Cloud Pub/Sub に対して Get 要求を Pub/Sub API から行い、メッセージを取得します。

どちらのケースでも デフォルトで 10 秒以内に ack を返すことで完了し、ない場合には最大で 7日間再送されます。
（設定で 600 秒までを Subscriber 側で指定できます）

 

gPRC

gRPC はオープンソースの RPC フレームワークです。
Google 社内で 10年以上にわたって構築されていた Stubby フレームワークの成果に基づいているそうです。

HTTP/2 と プロトコルバッファを利用し、多重リクエストの高速処理などを実現することにより
利用しない場合と比べて 4倍のスループット、1/4 の CPU 使用率となり、結果として 10 倍以上の効果があると
Google 側が検証した結果が出ていますが、まだアルファリリースで本番利用は推奨されていません。

これが早く本番利用も推奨となると嬉しいですね

 

まとめ

メッセージの順序を保証しない、メッセージ保持期間が 7日に限定される、メッセージ最大サイズが 10MB
などいくつか利用していく上で気をつけないといけないポイントはありますが
何より機能、運用面やパフォーマンスを考えると、選択肢として含めても良いかと思います。

Cloud DataFlow との連携についても Cloud Pub/Sub 紹介ページでされている通り
ストリーミング処理が必要となるケースでは必要性を感じました。

気になった方は、一度試して、 Pricing 含めて導入を検討してはいかがでしょう。