このドキュメントでは、Pub/Sub と Google Cloud Managed Service for Apache Kafka のどちらを選択するかについて説明します。Pub/Sub と Managed Service for Apache Kafka はどちらも、水平スケーリングが可能なマネージド メッセージング サービスであり、大量のワークロードを処理できます。
このドキュメントは、ストリーミング データとメッセージング ワークロードを処理するためのマネージド サービスを探しているデベロッパー、アーキテクト、意思決定者を対象としています。
Apache Kafka を実行するためのオプションは、パートナー サービスやセルフマネージド オープンソース ソフトウェアなど、複数あります。このドキュメントでは、これらのオプションについては説明しません。
Pub/Sub のコンセプトの概要については、Pub/Sub サービスの概要をご覧ください。
Managed Service for Apache Kafka のコンセプトの概要については、Managed Service for Apache Kafka の概要をご覧ください。
運用の容易さとポータビリティ
Pub/Sub と Managed Service for Apache Kafka のどちらを選択するかは、運用上のシンプルさと移植性のどちらを重視するかというトレードオフの判断となります。
Pub/Sub の運用の容易さ
Pub/Sub は、 Google Cloud インフラストラクチャを使用する、完全に管理されたサーバーレスのグローバル分散サービスです。ワークロードを処理するために自動的にスケーリングされるため、インフラストラクチャの管理について心配する必要はありません。Pub/Sub は、個々のトピックとサブスクリプションの容量を動的に調整します。パブリッシャーとサブスクライバーは、異なるトピックやサブスクリプションだけでなく、同じトピックやサブスクリプション内でも個別にスケーリングできます。
Pub/Sub は、複数のリージョン間でデータをシームレスに移動することもできます。つまり、パブリッシャーとサブスクライバーは最も近いリージョンに接続でき、残りの処理はサービスが行います。
Managed Service for Apache Kafka は、大量のデータを処理することもできます。ただし、クラスタサイズを管理し、トピックのスケーリングのニーズに基づいて他のいくつかのプロパティを構成する必要があります。最も重要なのは、トピックに割り当てるパーティションの数を検討することです。パーティションが多すぎると、リソースが無駄になる可能性があります。パーティションが少なすぎると、Kafka クラスタのブローカーに過負荷がかかる可能性があります。また、レイテンシとコンシューマーのファンアウトの要件に応じて、パーティションごとに構成する必要があるレプリカの数も考慮する必要があります。
Kafka デプロイは指定されたリージョンに関連付けられているため、リージョン間でデータを移動する場合は、サービス外でデータ移動を行う必要があります。データ移動の継続的な健全性を確保し、Kafka クラスタ内のトピックのニーズを満たすと、運用作業が増加します。
Managed Service for Apache Kafka のポータビリティ
Pub/Sub の自動スケーリングとグローバル データ分散により運用は容易になりますが、Apache Kafka API はより広く採用されています。
異なるオンプレミス環境またはクラウド プロバイダ環境で独立したメッセージング システムを使用する予定がある場合は、Managed Service for Apache Kafka を使用すると、アプリケーション全体でより一貫したエクスペリエンスを実現できます。これは、Kafka を標準化し、同じ API を使用して各環境の Kafka サービスと通信できるためです。
Pub/Sub をすべての環境で中央メッセージング システムとして使用することはできますが、Pub/Sub は独自の API を持つ個別のサービスであることを覚えておくことが重要です。特定の環境のメッセージング システムとやり取りする必要がある場合は、Managed Service for Apache Kafka を使用すると、より統一された開発エクスペリエンスを実現できます。
最適なサービス
さまざまな環境で一貫したエクスペリエンスが最も重要な場合は、Managed Service for Apache Kafka を選択します。ワークロードのスケーリングやリージョン間のデータ移動の構成を最小限に抑えることが目的の場合は、Pub/Sub が大きなメリットをもたらします。
次の要因が要件に該当する場合は、Pub/Sub を選択します。
Google Cloud内で運用の簡素化を優先します。
管理オーバーヘッドを最小限に抑えた、スケーラブルなサーバーレス ソリューションが必要です。
ワークロード サイズが予測できない、または変化している。Pub/Sub は、ワークロードのスループットが安定している場合にも効果的です。
単一の不良メッセージによるパイプラインの影響を最小限に抑えるために、メッセージごとの処理の追跡が必要です。Pub/Sub には、組み込みのデッドレター キュー（DLQ）と順序外メッセージ処理のサポートが用意されているため、問題のあるメッセージが発生した場合でもシステムを運用し続けることができます。
リージョン間のデータ集計が必要である。
パブリッシャーとサブスクライバーの独立したスケーリングが必要です。
次の要素が要件に当てはまる場合は、Managed Service for Apache Kafka を選択します。
複数のクラウド プロバイダまたはオンプレミス環境間のポータビリティが重要です。
Google Cloudに移行する既存の Kafka ワークロードがある。詳細については、既存の Kafka 設定に基づいて選択するをご覧ください。
トラフィック量が安定していて、変動が少ない。
容量管理を行う。
キーあたりの高スループットでメッセージの順序指定が必要である。
イベントログを信頼できる情報源としてイベント ソーシング パターンを使用する。
既存の Kafka 設定に基づいて選択する
すでに Kafka を使用しており、 Google Cloudでマネージドで安全かつ信頼性の高いソリューションをお探しの場合は、Managed Service for Apache Kafka をおすすめします。
すでに Kafka を実行していて、スケーラビリティが高く、自動スケーリングが可能なグローバル サービスのメリットを得るためにアプリケーションを書き換えることを検討している場合は、Pub/Sub をおすすめします。Kafka から Pub/Sub に移行するには、Kafka から Pub/Sub に移行するをご覧ください。
新しいワークロードや、 Google Cloudでのストリーミングを初めて使用するユーザーには、使いやすさの面から Pub/Sub をおすすめします。既存の Kafka ワークロードを最小限のコード変更でクラウドに移行する場合は、Managed Service for Apache Kafka が最適です。
Cloud プロダクトとの統合
Google Managed Service for Apache Kafka と Pub/Sub はどちらも、Dataflow、BigQuery、Cloud Storage などのさまざまなサービスと統合されています。 Google Cloud
マルチクラウド戦略が必要で、さまざまなクラウド プロバイダ間の移植性を優先する場合は、Managed Service for Apache Kafka の方が柔軟性が高くなります。これは、Kafka が Pub/Sub よりも幅広い範囲の Google Cloud 以外のシステムと統合されているためです。
機能の比較
前のセクションの概要レベルの決定基準が役に立たない場合は、特定の機能のサポートに基づいて選択できます。2 つの製品の詳細な比較については、次の表をご覧ください。
| 機能 | Pub/Sub | Managed Service for Apache Kafka |
|---|---|---|
| 使いやすさ | 設定と保守が容易 | 運用に手間がかかる |
| 費用モデル | 従量課金 | コンピューティングの容量ベースの料金 ネットワーキングとストレージの従量課金制。 |
| exactly-once 処理 | 単一の同時配信と強力な確認応答セマンティクスをサポートします。 | 1 つのトピックから読み取り、別のトピックに書き込む場合に、1 回限りの副作用をサポートします。 |
| スケーリング | 予測不可能なワークロードにも対応する、トピックあたり KB/秒から GB/秒までのシームレスな自動スケーリング。 | 手動構成が必要 |
| 順序付けられた配信 | キー内での順序付けが可能です。 きめ細かい順序指定キーあたり 1 MBps のスループット |
パーティション内の順序付けを提供します。 パーティションの最大スループット容量までのパーティションごとの順序付け。 |
| データの保持 | 31 日 | 無期限の保持 |
| エンドツーエンドのレイテンシ | エンドツーエンドのレイテンシは通常 100 ミリ秒程度 | 通常、適切な動作をするサブスクライバーの場合、10 ミリ秒程度です。 |
| リフト＆シフトのためのオープンソース Kafka の互換性 | いいえ | ○ |
| Identity and Access Management とセキュリティ | ○ | ○ |
| ネットワークの自動構成 | ○ | ○ |
| マルチクラウド: クラウド間で同一 | いいえ | ○ |
| 稼働時間に関する SLA | はい | ○ |
| データプレーンの SLA | はい | 現時点では停止されません |
| ロギングとモニタリング | ○ | ○ |
| ブローカー間のパーティションの再調整 | 該当なし | ○ |
| 自動容量 | Pub/Sub は、着信したメッセージのレートとサブスクライバーの需要に基づいて容量を動的に調整します。 | このサービスは、VM やストレージなどの基盤となるインフラストラクチャを管理します。パーティションの数やレプリケーション係数などの側面を制御します。 |
| 自動ストレージ管理 | ○ | ○ |
| 自動ソフトウェア アップグレード | ○ | ○ |
| カスタマー サポート | ○ | ○ |
| Kafka Connect サービス | 該当なし | ユーザー提供の Connect サービスを使用する |
| スキーマのサポート | ○ | ユーザー指定のスキーマ レジストリを使用する場合 |
| ks qIDB、KSQL と互換性があります | いいえ | ○ |
| OSS コネクタのサポート | Kafka コネクタと Flink コネクタの場合は「はい」 | いいえ |
| データレイクとデータ ウェアハウスとの統合 | ○ | ○ |