Kafka から Pub/Sub への移行

このドキュメントは、ユーザーが管理する 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 は、データフロークラウド ストレージCloud Run などのさまざまな Google Cloud サービスと統合できます。こうしたサービスは、Pub/Sub にメッセージをパブリッシュできるデータソースとして機能するように構成することや、Pub/Sub からメッセージを受信できるデータシンクとして機能するように構成できます。

Kafka の概要

Apache Kafka はオープンソースの分散型イベント ストリーミング プラットフォームで、これを使用すると、アプリケーションはイベント ストリームのパブリッシュ、受信登録、保存、処理を行えます。Kafka サーバーは、クライアント アプリケーションがやり取りするマシンのクラスタとして実行され、イベントの読み取り、書き込み、処理を行います。Kafka は、アプリケーションの分離、メッセージの送受信、アクティビティのトラッキング、ログデータの集計、ストリームの処理に使用できます。

Kafka クラスタでは、クラスタ内の一部のノードがブローカーとして指定されています。ブローカーはプロデューサーからメッセージを受信し、ディスクに保存します。保存されたメッセージはトピック別に整理され、クラスタ内の複数のブローカーで分割されます。トピックにパブリッシュされた新しいイベントは、トピックのパーティションのいずれかの末尾に追加されます。コンシューマーは、ディスクから読み取られてコンシューマに送信されるブローカーからメッセージをフェッチできます。

Kafka と Pub/Sub の違いについて

次の図は、Kafka と Pub/Sub のスケーリング方法の違いを示しています。

パーティションを使用する Kafka と、パーティションを使用しない Pub/Sub のスケーリング方法。

上の図では、各 M がメッセージを表します。Kafka ブローカーは、メッセージの複数の順序付けされたパーティション(メッセージの水平行で表される)を管理します。コンシューマは、そのパーティションをホストするマシンに基づいて容量のある特定のパーティションからメッセージを読み取ります。Pub/Sub にはパーティションがなく、代わりにコンシューマは需要に応じて自動スケーリングされるトピックから読み取ります。各 Kafka トピックには、予想される消費者の負荷を処理するために必要なパーティションの数を構成します。Pub/Sub は需要に基づいて自動的にスケーリングされます。

機能の比較

次の表は、Apache Kafka の機能と Pub/Sub の機能を比較したものです。

Apache Kafka Pub/Sub
メッセージの順序指定 ○(パーティション内) ○(トピック内)
メッセージの重複除去 ○(Dataflow を使用)
プッシュ サブスクリプション ×
未処理のメッセージ キュー バージョン 2.0 以降
履歴 ×
メッセージ ストレージ 利用可能なマシン ストレージによる制限のみ 7 日間
メッセージ再生
Locality MirrorMaker を使用してローカル クラスタを複製可能 構成可能なメッセージ ストレージ ロケーションを使用したグローバル分散サービス
ロギングとモニタリング セルフマネージド Cloud LoggingCloud Monitoring により自動化
ストリーム処理 ○(KSQL を使用) ○(Dataflow を使用)

Pub/Sub メッセージのストレージとリプレイについて

デフォルトでは、Pub/Sub は確認応答されていないメッセージを最大 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 にオブジェクトを保存します。

上記の画像は、パブリッシャーが 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 コネクタを構成できます。次に、個々のサブスクライバーアプリケーションを更新して、Pub/Sub からそれらのトピックに関するメッセージを受信します。パブリッシャー アプリケーションは、Kafka にメッセージをパブリッシュし続けます。この段階的なアプローチにより、エラーとダウンタイムのリスクを最小限に抑えながら、サブスクライバー アプリケーションの更新、テスト、モニタリングを繰り返すことができます。

このセクションでは、このプロセスを 2 つの異なるフェーズで可視化する際に役立つ 2 つの図を示します。次の図は、移行フェーズ中の構成を示しています。

移行のステージ 1。

上の図では、現在のサブスクライバーが引き続き Kafka からメッセージを受信しており、Kafka ではなく Pub/Sub からメッセージを受信するようにサブスクライバーを 1 つずつ更新します。

特定のトピックに対するサブスクライバーがすべて Pub/Sub からメッセージを受信するように更新されたら、そのトピックのパブリッシャー アプリケーションを更新してメッセージを Pub/Sub にパブリッシュできます。その後、メッセージ フローをエンドツーエンドでテストしてモニタリングし、設定を確認できます。

次の図は、すべてのサブスクライバーが Pub/Sub からメッセージを受信した後の構成を示しています。

移行の第 2 段階

そのうち、すべてのパブリッシャーが Pub/Sub に直接公開されるように更新され、移行が完了します。多くのチームは、このアプローチを使用してアプリケーションを並行して更新しています。Kafka は、移行の成功に必要な期間だけ、Pub/Sub と共存できます。

Pub/Sub のモニタリング

Kafka から Pub/Sub への移行中および移行後に、アプリケーションをモニタリングすることが重要です。Pub/Sub は Cloud Monitoring を使用して指標をエクスポートします。これにより、アプリケーションのパフォーマンス、稼働時間、全体的な動作状況を可視化できます。たとえば、未配信のメッセージ数をモニタリングすることで、サブスクライバーがメッセージ フローに対応できているか確認できます。未配信のメッセージをモニタリングするには、最も古い未確認メッセージのタイムスタンプが特定のしきい値を超えたときにアラートを作成します。送信リクエスト数の指標をモニタリングしてレスポンス コードを調べることで、Pub/Sub サービス自体の正常性をモニタリングすることもできます。

次のステップ