このドキュメントは、ユーザーが管理する Apache Kafka から Pub/Sub への移行を考えている担当者が、機能、料金、ユースケースを確認し、検討することを支援するものです。以降の各セクションでは、一般的な Kafka のユースケースを示し、Pub/Sub で同じ機能を実現するための実践的な指針を提供します。
Pub/Sub の概要
Pub/Sub は、非同期のメッセージング サービスです。Pub/Sub は、イベントを生成するサービスと、イベントを処理するサービスを分離します。Pub/Sub は、メッセージ指向のミドルウェア、またはストリーミング分析用のイベントの取り込みと配信のパイプラインとして使用できます。いずれの場合も、パブリッシャー アプリケーションがメッセージを作成してトピックへ送信します。サブスクライバー アプリケーションでは、トピックに対するサブスクリプションが作成されてメッセージが受信されます。サブスクリプションとは、特定のトピックに関するメッセージの受信に関心があることを示す名前付きエンティティです。
Pub/Sub は、すべての Google Cloud リージョンで動作します。Pub/Sub は、パブリッシャー トラフィックを、リソースのロケーション制限ポリシーの定めに従ってデータ ストレージが許可されている最も近い Google Cloud データセンターに転送します。
Pub/Sub は、Dataflow、Cloud Storage、Cloud Run などのさまざまな Google Cloud サービスと統合できます。こうしたサービスは、Pub/Sub にメッセージをパブリッシュできるデータソースとして機能するように構成することや、Pub/Sub からメッセージを受信できるデータシンクとして機能するように構成できます。
Kafka の概要
Apache Kafka はオープンソースの分散型イベント ストリーミング プラットフォームで、これを使用すると、アプリケーションはイベント ストリームのパブリッシュ、受信登録、保存、処理を行えます。Kafka サーバーは、クライアント アプリケーションがやり取りするマシンのクラスタとして実行され、イベントの読み取り、書き込み、処理を行います。Kafka は、アプリケーションの分離、メッセージの送受信、アクティビティのトラッキング、ログデータの集計、ストリームの処理に使用できます。
Kafka クラスタ内では、クラスタ内の一部のノードがブローカーとして指定されます。ブローカーはプロデューサーからメッセージを受信し、ディスクに保存します。保存されたメッセージはトピック別に整理され、クラスタ内の複数のブローカーにパーティショニングされます。トピックにパブリッシュされた新しいイベントは、トピックのいずれかのパーティションの末尾に追加されます。次に、コンシューマは、ディスクから読み取られてコンシューマに送信されたメッセージをブローカーから取得できます。
Kafka と Pub/Sub の違いについて
次の図は、Kafka と Pub/Sub のスケーリング方法の違いを示しています。
上の図では、各 M がメッセージを表しています。Kafka ブローカーは、メッセージの水平方向の行で表される、メッセージの複数の順序付きパーティションを管理します。コンシューマは、そのパーティションをホストするマシンに基づいて容量を持つ特定のパーティションからメッセージを読み取ります。Pub/Sub にはパーティションはなく、コンシューマは需要に応じて自動スケーリングするトピックから読み取ります。予想されるコンシューマ負荷の処理に必要とされるパーティションの数で各 Kafka トピックを構成します。Pub/Sub は、需要に応じて自動的にスケーリングされます。
機能の比較
次の表は、Apache Kafka の機能と Pub/Sub の機能を比較したものです。
| Apache Kafka | Pub/Sub | |
|---|---|---|
| メッセージの順序指定 | ○（パーティション内） | ○（トピック内） |
| メッセージの重複除去 | ○ | ○（Dataflow を使用） |
| プッシュ サブスクリプション | × | はい |
| デッドレター キュー （未処理のメッセージ キュー） |
バージョン 2.0 以降 | はい |
| 履歴 | ○ | × |
| メッセージ ストレージ | 利用可能なマシン ストレージによる制限のみ | 31 日間。 トピックは、確認応答されたメッセージを含む公開済みメッセージを最大 31 日間保持できます。これは、トピックの `message_retention_duration` プロパティで構成できます。 |
| メッセージの再生 | ○ | はい |
| 地域区分 | MirrorMaker を使用してローカル クラスタを複製可能 | 構成可能なメッセージ ストレージ ロケーションを使用したグローバル分散サービス |
| ロギングとモニタリング | セルフマネージド | Cloud Logging と Cloud Monitoring により自動化 |
| ストリーム処理 | ○（KSQL を使用） | ○（Dataflow を使用） |
Pub/Sub メッセージのストレージとリプレイについて
デフォルトでは、Pub/Sub は未確認のメッセージを最大 7 日間保持しますが、サブスクリプションの一番古いメッセージ（確認済みまたは未確認）の時期に応じて、確認済みメッセージも最大 7 日間保持するように Pub/Sub サブスクリプションを構成できます。確認済みメッセージを保持することで、タイムスタンプに基づいてこれらのメッセージの一部または全部をリプレイできます。タイムスタンプに基づいてメッセージをリプレイすると、タイムスタンプより後に受信したすべてのメッセージが未確認とマークされます。その場合、未確認メッセージは再配信されます。
サブスクリプションを事前に構成しなくても、オンデマンドで個別のサブスクリプションのスナップショットを作成できます。たとえば、新しいサブスクライバー コードをデプロイする際に、予期しない確認応答や誤った確認応答からの回復が必要になる可能性があるため、スナップショットを作成できます。
デッドレター トピックを使用した組み込みフェイルセーフ
Pub/Sub は、Kafka 2.0 のエラー処理と、Kafka Connect のデッドレター トピックの処理と同様の機能を備えています。メッセージが正常に配信されたことを Pub/Sub に通知するには、Pub/Sub トピックのサブスクライバーが、受信して処理するメッセージに対して確認応答します。サブスクライバーがメッセージをしばらく処理できない場合、Pub/Sub は、デッドレター トピックにこれらのメッセージを自動転送し、後でアクセスできるように保存できます。デッドレター トピックにメッセージを送信する前に Pub/Sub がメッセージを配信する回数は、構成できます。
Dataflow を使用した Pub/Sub メッセージの重複除去
Pub/Sub は、パブリッシュされたメッセージを、すべてのサブスクリプションに対して 1 回以上配信します。通常、複数回の配信に対応するには、メッセージの処理時にサブスクライバーがべき等である必要があります。既存のサブスクライバーがべき等にオペレーションを実施できない場合は、Dataflow にメッセージの重複除去を組み込む方法もあります。サブスクライバーのメッセージの重複率が高い場合は、メッセージが正しく確認応答されていないか、確認応答の期限が早すぎる可能性があります。
Pub/Sub でのメッセージの順序指定
Kafka サブスクライバー アプリケーションがメッセージの順序を当てにしている場合、順序指定キーを使用すると、Pub/Sub でこの要件に対応できます。現在は、特定のリージョンにパブリッシュされたメッセージの順序が保証されます。メッセージの順序指定を利用するには、パブリッシャーとサブスクライバーがロケーション エンドポイントを使用して正しいリージョンにメッセージを転送するようにします。
自己ホスト型とマネージド サービスの責任範囲について
次の表では、Kafka を使用した自己ホスト型の機能と、Pub/Sub を使用した Google が管理する機能を比較します。
| Apache Kafka | Pub/Sub | |
|---|---|---|
| 対象 | Kafka を他のロケーションに手動でデプロイする | 高可用性と低レイテンシを目的としてすべての Google Cloud リージョンにデプロイ済み |
| 障害復旧 | 独自のバックアップとレプリケーションを設計して維持する | Google で管理 |
| インフラストラクチャ管理 | 仮想マシン（VM）またはマシンを手動でデプロイして運用する。一貫したバージョニングとパッチを維持する必要がある。 | Google で管理 |
| 容量の計画 | ストレージとコンピューティングのニーズを事前に計画する | Google で管理 |
| サポート | なし | 24 時間対応の待機スタッフとサポート |
Pub/Sub メッセージのサイズ上限と回避策
Kafka と Pub/Sub はどちらも、小さなメッセージを大量に処理する場合に良好に動作します。Kafka ではメッセージ サイズにハードリミットが課されず、許可されるメッセージ サイズを構成できますが、Pub/Sub ではメッセージが 10 MB に制限されています。次の図に示すように、最初にオブジェクトを Cloud Storage に保存すると、より大きなペイロードを間接的に送信できます。
上の図は、パブリッシャーがオブジェクトを Cloud Storage に保存すると、その保存されたオブジェクトの URL を含むメッセージをパブリッシュすることを示しています。サブスクライバーが URL を含むメッセージを受信すると、Cloud Storage からファイルをダウンロードし、通常どおり処理を続行します。
Kafka と Pub/Sub の費用の比較
Pub/Sub で費用を見積もったり管理したりする方法は、Kafka とは異なります。オンプレミスまたはクラウド上の Kafka クラスタの費用には、マシン、ディスク、ネットワーク、受信メッセージと送信メッセージの費用のほか、これらのシステムおよび関連するインフラストラクチャの管理と維持にかかるオーバーヘッド費用が含まれます。Kafka クラスタの管理では多くの場合、マシンを手動でアップグレードしてパッチを適用する必要があり、クラスタ容量の計画が必要になります。また、障害復旧の実装には、広範な計画とテストが必要です。実際の総所有コスト（TCO）を決定するには、これらのさまざまな費用をすべて推測して集計する必要があります。
Pub/Sub の価格には、パブリッシャーとサブスクライバーからのデータ転送と、確認応答されていないメッセージを一時的に保存するための費用が含まれます。消費したリソースに対して正確に料金を支払い、アプリケーションの要件と予算に応じて容量を自動的にスケーリングします。
信頼性の設計
Pub/Sub は、すべての Google Cloud リージョンで実行されるグローバル マネージド サービスです。Pub/Sub トピックはグローバルです。つまり、これらのトピックは、Google Cloud のすべてのロケーションで表示し、アクセスできます。ただし、メッセージはパブリッシャーに最も近く、リソース ロケーション ポリシーで許可されている単一の Google Cloud リージョンに保存されます。したがって、1 つのトピックが Google Cloud 全体の複数のリージョンに保存されることがあります。Pub/Sub はゾーンの停止に対して耐障害性があります。リージョンが停止している間、そのリージョンに保存されているメッセージには、サービスが復元されるまでアクセスできない場合があります。可用性の要件に応じて、ロケーション サービス エンドポイントを使用して、リージョンが停止した場合にフェイルオーバー ポリシーを実装できます。
セキュリティと認証
Apache Kafka は、クライアント証明書ベースの認証、Kerberos、LDAP、ユーザー名とパスワードなど、複数の認証メカニズムをサポートしています。認可については、Kafka はアクセス制御リスト（ACL）を使用して、どのプロデューサーとコンシューマーがどのトピックにアクセスできるかを決定します。
Pub/Sub は、Google Cloud ユーザー アカウントとサービス アカウントの認証をサポートしています。Pub/Sub トピックとサブスクリプションに対するきめ細かいアクセス制御は、Google Cloud の Identity and Access Management（IAM）によって管理されます。ユーザー アカウントを使用する場合、Pub/Sub オペレーションはレート制限されます。大量のトランザクションを行う必要がある場合は、サービス アカウントを使用して Pub/Sub を操作できます。
Pub/Sub への移行の計画
Google Cloud への移行は、ワークロードの評価と基盤の構築から始めます。
Pub/Sub Kafka コネクタを使用した段階的な移行
Pub/Sub Kafka コネクタを使用すると、Kafka インフラストラクチャを Pub/Sub に段階的に移行できます。
特定のトピックのすべてのメッセージを Kafka から Pub/Sub に転送するように Pub/Sub コネクタを構成できます。次に、パブリッシャー アプリケーションが Kafka にメッセージをパブリッシュし続けながら、個々のサブスクライバー アプリケーションを更新して、それらのトピックに関するメッセージを Pub/Sub から受信できます。この段階的なアプローチでは、エラーとダウンタイムのリスクを最小限に抑えるよう、サブスクライバー アプリケーションの更新、テスト、モニタリングを繰り返し行います。
このセクションでは、このプロセスを 2 つの異なるフェーズに分けて可視化できる 2 つの図を示します。次の図は、移行フェーズ中の構成を示しています。
上の図では、現在のサブスクライバーが引き続き Kafka からメッセージを受信しており、Kafka ではなく Pub/Sub からメッセージを受信するようにサブスクライバーを 1 つずつ更新します。
特定のトピックのすべてのサブスクライバーが Pub/Sub からメッセージを受信するように更新されたら、そのトピックのパブリッシャー アプリケーションを更新して、Pub/Sub にメッセージをパブリッシュできます。その後、メッセージフローをエンドツーエンドでテストしてモニタリングし、設定を確認できます。
次の図は、すべてのサブスクライバーが Pub/Sub からメッセージを受信した後の構成を示しています。
時間の経過とともに、すべてのパブリッシャーが Pub/Sub に直接公開されるように更新され、移行が完了します。多くのチームが、このアプローチを使用してアプリケーションを並行して更新しています。Kafka は、正常に移行するために必要な期間だけ Pub/Sub と共存できます。
Pub/Sub のモニタリング
Kafka から Pub/Sub への移行中と移行後は、アプリケーションをモニタリングすることが重要です。Pub/Sub は Cloud Monitoring を使用して指標をエクスポートします。これにより、アプリケーションのパフォーマンス、稼働時間、全体的な健全性を可視化できます。たとえば、未配信メッセージの数をモニタリングすることで、サブスクライバーがメッセージのフローに確実に対応できるようにします。配信不能メッセージをモニタリングするには、確認応答されていない最も古いメッセージのタイムスタンプが特定のしきい値を超えたときにアラートを作成します。送信リクエスト数指標をモニタリングしてレスポンス コードを調べることで、Pub/Sub サービス自体の状態をモニタリングすることもできます。
次のステップ
- Pub/Sub を使用したストリーム分析。
- Pub/Sub API リファレンス。
- Pub/Sub Monitoring のドキュメント。
- クラウド インフラストラクチャの停止に対する障害復旧の設計。
- Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。