1. Home
  2. Platform
  3. マルチ DC デプロイのアーキテクチャ
  4. Cluster Linking

Cluster Linking

Looking for Confluent Cloud Cluster Linking docs? You are currently viewing Confluent Platform documentation. If you are looking for Confluent Cloud docs, check out Cluster Linking on Confluent Cloud.

Cluster Linking とは

Cluster Linking を使用すると、クラスター間を直接接続して、一方のクラスターから他方のクラスターにトピックをミラーリングできます。Cluster Linking により、マルチデータセンター、マルチリージョン、およびハイブリッドクラウドのデプロイを簡単に構築できるようになります。セキュアでパフォーマンスに優れ、ネットワークレイテンシに対応できます。この機能は、Confluent Server および Confluent Cloud に組み込まれています。

Replicator および MirrorMaker 2 とは異なり、Cluster Linking では Connect を実行せずに一方のクラスターから他方のクラスターにメッセージを移動できます。また、同一の "ミラートピック" をグローバルに一致するオフセットで作成できます。これを、"バイト単位" のレプリケーションと呼びます。送信元トピックのメッセージは、送信先クラスターの同一のパーティションおよびオフセットで正確にミラーリングされます。

機能と比較

Cluster Linking は、一方の Kafka または Confluent クラスターから他方へトピックをレプリケートします。これによって以下の機能を提供します。

  • グローバルレプリケーション: 世界中のリージョンおよび大陸のデータおよびアプリケーションを統合できます。
  • ハイブリッドクラウド: プライベートクラウドのオンプレミスの Confluent Platform クラスターをパブリッククラウドの Confluent Cloud クラスターにリンクすることによって、クラウドへのブリッジをセキュア、スケーラブル、かつシームレスな方法で作成します。
  • HA/DR: マルチリージョンの高可用性およびディザスターリカバリ（"HA/DR"）戦略を構築します。この戦略では、トピックのデータとメタデータを別のクラスターにレプリケートすることによって、復旧時間の短縮（RTO）と最小のデータ損失（RPO）を実現します。
  • クラスター移行: 古いクラスターから新しい環境、リージョン、またはクラウドのクラスターに移行します。
  • 集約: 多数の小さいクラスターのデータを 1 つの集約クラスターに結合します。
  • データ共有: 異なるチーム間や異なる事業部門間、組織間でデータを交換します。

他の Kafka レプリケーションオプションに比べて、Cluster Linking には次の利点があります。

  • Confluent Server および Confluent Cloud に組み込まれているので、他のコンポーネント、コネクター、仮想マシン、またはカスタムプロセスに依存しません。
  • オフセットを含め、トピックの正確なミラーを作成するので、オフセット変換またはカスタムツール不要でシステムの移行、フェイルオーバー、合理化ができます。
  • REST API、CLI、Kubernetes CRD を介して動的にアップデートできます。
  • 圧縮されたメッセージの場合、バイト単位のレプリケーションによって展開と再圧縮を回避することで、スループットが高速化します。

サポート対象

Cluster Linking は、Confluent Server に含まれています。Confluent Platform の Cluster Linking に対しては、Confluent Enterprise の エンタープライズ（契約プラン）ライセンス の料金以外に追加料金や他のライセンス料金はかかりません。Cluster Linking の要件とサポートされる機能は以下のとおりです。

  • 送信先クラスターで Confluent Platform 7.x.x の Confluent Server 送信先クラスターが必要です。
  • すべての クライアント で正常に動作します。
  • 送信元クラスターで 2.4 以降、送信先クラスターで 2.7 以降のブローカー間プロトコル（IBP）が必要です。具体的には、現在の Confluent Platform 7.x.x バージョンでは、送信元クラスターの IBP が 2.7 以前の場合、送信先の IBP は 2.7 である必要があります。送信元クラスターの IBP が 2.8 以降の場合、送信先の IBP は 2.7 以降にすることができます。Confluent Platform 7.x.x を使用するクラスターでサポートされていないのは、これらのパラメーター以外で送信元と送信先の IBP が一致しない場合です。アップグレードに関するガイドについては、「7.1.x へのアップグレード手順」を参照してください。
  • Confluent Platform の送信先クラスターのブローカーに password.encoder.secret を設定する必要があります。このプロパティを動的に設定する方法については、「パスワード構成の動的なアップデート」を参照してください。
  • Confluent for Kubernetes にカスタムリソースが組み込まれています。
  • Ansible と互換性があります。詳細については、「Cluster Linking と Ansible の使用」を参照してください。
  • 「Cluster Linking のセキュリティ」に記載されている認証と認可をサポートしています。
  • 送信元クラスターには Kafka、Confluent Server、または Confluent Cloud を使用できます。送信先クラスターは、Confluent Enterprise にバンドルされている Confluent Server である必要があります。
  • Confluent Platform 上のセルフマネージド型デプロイに加え、Cluster Linking は Confluent Cloud および ハイブリッドクラウド のマネージド型サービスとしても使用できます。
送信元 送信先
Confluent Platform 5.4 以降 Confluent Platform 7.0.0 以降
Confluent Cloud Confluent Platform 7.0.0 以降
Kafka 2.4 以降 Confluent Platform 7.0.0 以降
Confluent Platform 5.4 以降 Confluent Cloud [1]
Confluent Cloud Confluent Cloud [1]
Kafka 2.4 以降 Confluent Cloud [1]
Confluent Platform 7.0.0 以降 Confluent Platform 7.0.0 以降
Confluent Platform 7.0.0 以降 Confluent Cloud

脚注

[1](1, 2, 3) サポート対象の Confluent Cloud の送信元と送信先の組み合わせについては、「Confluent Cloud でのクラスターリンク」を参照してください。

アップグレードに関する注意事項

  • Confluent Platform 6.2.0 から 7.0.0 以降のバージョンにアップグレードする場合は、$CONFLUENT_HOME/server.properties で acl.sync.enabled が true に設定されていることを確認してください（デフォルトは false であるため、このプロパティが指定されてない場合は false に設定していることになります）。アップグレード時に acl.sync.enabled が true に設定されている場合、既存のクラスターリンクは "failed"（ステートは LINK_FAILED）としてマークされます。

ユースケースとアーキテクチャ

以下のユースケースは、示されている構成とアーキテクチャによって実現できます。

ハイブリッドクラウド

ユースケース: オンプレミス環境からクラウド環境への永続的でシームレスなブリッジを簡単に作成できます。データセンターの Confluent Platform クラスターとパブリッククラウドの Confluent Cloud クラスター間のクラスターリンクは、単一のセキュアでスケーラブルなハイブリッドデータブリッジとして機能し、数百のトピック、アプリケーション、データシステムで使用できます。Cluster Linking は、オンプレミスのインフラストラクチャとクラウドの間で起こりうる高いレイテンシや予測できないネットワークの可用性を許容でき、再接続から自動的に回復します。Cluster Linking では、ファイアウォールに穴を開けたり特別な IP フィルターを設定したりしなくても、データセンターとクラウド間のデータを双方向でレプリケートできます。これは、データセンターが常にアウトバウンド接続であるためです。Cluster Linking は、バイト単位でグローバルに一致するデータコピーを作成します。オフセットが保持されており、オンプレミスのアプリケーションをクラウドに簡単に移行できます。Cluster Linking は Confluent Platform に組み込まれており、管理用の追加コンポーネントを必要としません。

../../_images/clusterlinking-usecase-hybrid.ja.png

ディザスターリカバリ

ユースケース: プライマリクラスターで停止または災害が発生した場合に、フェイルオーバーに利用できるディザスターリカバリ（"DR"）クラスターを作成します。Cluster Linking は、データ、メタデータ、トピック構成、コンシューマーオフセットを同期した DR クラスターを維持します。これによって目標復旧時点（"RPO"）と目標復旧時間（"RTO"）を短縮できます。通常は数分間です。DR 用の Cluster Linking では、費用のかかるネットワーク、複雑な管理、追加のソフトウェアコンポーネントは不要です。また、Cluster Linking は、オフセットを保持し、コンシューマーオフセットを同期します。これにより、カスタムコードやインターセプターを用意しなくても、すべての言語のコンシューマーアプリケーションがフェイルオーバーして、停止した時点に最も近いポイントから再開できるので、ダウンタイムが短くなります。

../../_images/clusterlinking-usecase-dr.ja.png

グローバルレプリケーション

ユースケース: 事業を展開している大陸およびリージョン間でデータをストリーミングします。すべてのリージョンのデータを統一して、グローバルなリアルタイムイベントメッシュを作成します。異なるリージョンのデータを集約して、ビジネスを強力に支援するリアルタイムのアプリケーションおよび分析を推進します。リアルタイムデータの位置情報の読み取りを可能にすることで、パブリッククラウド、プライベートクラウド、エッジのすべてで Kafka イベントの Content Delivery Network（CDN）のような役割を果たすことができます。

../../_images/clusterlinking-usecase-global.png

データ共有

ユースケース: チーム間の高い独立性や効率的な運用管理を実現できるパターンで、異なるチーム、事業部門、組織間でデータを共有します。Cluster Linking は、消費側のチームのクラスターに関連データを同期したミラーコピーを維持します。この独立性により、消費側のチームは、生成側のチームのクラスターに影響を与えずに、数百のコンシューマーアプリケーション、ストリーム処理アプリケーション、およびデータシンクをスケールアップできます。生成側のチームの負荷は追加コンシューマー 1 つ分と同じです。生成側のチームは、消費側のチームが読み取りを許可されているトピックにアクセスするためのセキュリティ認証情報を発行するだけです。その後、消費側のチームはクラスターリンクを作成でき、これを制御、モニタリング、管理します。

../../_images/clusterlinking-usecase-datasharing.ja.png

クラスター移行

ユースケース : オンプレミスの Kafka または Confluent Platform クラスターから Confluent Cloud クラスターに、あるいは古いインフラストラクチャから新しいインフラストラクチャに、短いダウンタイムでデータ損失なくシームレスに移行します。Cluster Linking でネイティブオフセットが保持され、コンシューマーオフセットは同期されているので、準備ができれば、すべてのコンシューマーアプリケーションを古いクラスターから新しいクラスターに切り替えることができます。トピックは、1 つずつ、またはバッチごとに移行できます。Cluster Linking は、トピックの作成、構成、同期を処理します。

../../_images/clusterlinking-usecase-migration.ja.png

Cluster Linking

Because Cluster Linking fetches data from source topics, the first scaling unit to inspect is the number of partitions in the source topics. Having enough partitions lets Cluster Linking mirror data in parallel. Having too few partitions can make Cluster Linking bottleneck on partitions that are more heavily used.

In a Confluent Platform or Apache Kafka® cluster, you can scale Cluster Linking throughput as follows:

  • On the cluster link configurations, change the number of fetcher threads or change the fetch size to get better batching.
  • Improve the cluster’s maximum throughput by scaling the brokers vertically or horizontally.
  • Use the options listed under Cluster Link Replication Configurations to tune cluster link performance, which helps scale cluster link throughput.

In Confluent Cloud, Cluster Linking scales with the ingress and egress quotas of your cluster. Cluster Linking is able to use all remaining bandwidth in a cluster’s throughput quota: 150 MB/s per CKU egress on a Confluent Cloud source cluster or 50 MB/s per CKU ingress on a Confluent Cloud destination cluster, whichever is hit first. Therefore, to scale Cluster Linking throughput, simply adjust the number of CKUs on either the source, the destination, or both.

注釈

On the destination cluster, Cluster Linking write takes lower priority than Kafka clients producing to that cluster; Cluster Linking will be throttled first.

Confluent proactively monitors all cluster links in Confluent Cloud and will perform tuning when necessary. If you find that your cluster link is not hitting these limits even after a full day of sustained traffic, contact Confluent Support.

See also, recommended guidelines for Confluent Cloud.

既知の制限とベストプラクティス

  • Confluent Platform 7.0.0 では、送信元開始クラスターリンク（ハイブリッドクラウドを推奨）を REST API で作成できません。kafka-cluster-links CLI で作成する必要があります。通常の送信先開始クラスターリンクは、REST API と kafka-cluster-links CLI のどちらでも作成できます。
  • Confluent Platform 7.1 以降では、送信元開始クラスターリンクを一覧表示して取得するための REST API 呼び出しでは、送信先クラスター ID がパラメーター destination_cluster_id で返されます。（これは以前のリリースからの変更点です。以前は source_cluster_id で返されていました。）
  • すべての SSL キーストア、トラストストア、および Kerberos キータブファイルは、特定のクラスター内の各ブローカー上の同じ場所に格納されている必要があります。そのように格納されていないと、クラスターリンクが失敗する場合があります。別の方法として、クラスターリンク構成で、PEM 証明書をインラインで構成 できます。
  • ファイル（SSL キーストア、トラストストア、Kerberos keytab ファイル）に保存されているクラスターリンク構成は、/tmp に保管しないでください。/tmp のファイルが削除され、一部のブローカーでリンクとミラーが無効なステートになる可能性があるためです。
  • Confluent Control Center は、Confluent Platform クラスターと Control Center が REST Proxy API v3 に接続されている場合はミラートピックのみを正しく表示します。v3 の Confluent REST API に接続されていない場合、Control Center は、ミラートピックを通常のトピックとして表示します。このため、メッセージの生成や構成の編集など、実際はミラートピックでは利用できない機能を表示することがあります。v3 の REST API 用にこれらのクラスターを構成する方法については、「Control Center の必須構成」を参照してください。
  • 前提条件はコンテキストによって異なるため、チュートリアルまたはユースケースごとに提供されます。チュートリアルは、トピックデータの共有 と ハイブリッドクラウドとクラウドへのブリッジ に関するものが用意されています。セキュアなセットアップのための追加要件は、「Cluster Linking のセキュリティ」に記載されています。
  • Cluster Linking は、"厳密に 1 回" のセマンティクスを含む Kafka トランザクションと統合されていません。トランザクションや "厳密に 1 回" のセマンティクスが含まれるミラートピックへの Cluster Linking の使用はサポートされておらず、推奨されません。
  • Confluent Platform 7.0.x 以前（非 KRaft）を実行する送信元クラスターと、KRaft モードで実行する送信先クラスターとの間の Cluster Linking はサポートされていません。リンク作成は成功する可能性がありますが、最終的に接続は失敗します。この問題を回避するために、送信元クラスターでは Confluent Platform バージョン 7.1.0 以降を実行する必要があります。Confluent Platform 送信元クラスターから Confluent Cloud 送信先クラスターへのリンクがある場合は、送信元クラスターを Confluent Platform 7.1.0 以降にアップグレードすることでこの問題を回避してください。
  • これまで Confluent Platform 6.0.0 から 6.2.x で使用できた ACL 移行（ACL 同期）は、セキュリティ上の脆弱性があるため Confluent Platform 7.0.0 で削除されましたが、その後、脆弱性が解決され、Confluent Platform 7.1.0 で再導入されました。7.1.0 より前のデプロイで ACL 移行を使用している場合は、それを無効にするか、7.1.x にアップグレードする必要があります。詳細については、「認可（ACL）」を参照してください。