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.

重要

この機能はプレビュー機能として利用できます。プレビュー機能とは、開発者から早い段階でフィードバックを受けるために提供している Confluent Platform のコンポーネントのことです。この機能は、評価用、本稼働環境以外でのテスト用、あるいは Confluent にフィードバックを提供するために使用できます。

Cluster Linking とは

Cluster Linking を使用すると、直接クラスター間を接続して、一方のクラスターから他方のクラスターにトピックをミラーリングできます。Connect は必要ありません。Cluster Linking により、マルチデータセンター、マルチクラスター、およびハイブリッドクラウドのデプロイをはるかに簡単に構築できるようになります。

Replicator および MirrorMaker2 とは異なり、Cluster Linking では Connect を実行せずに一方のクラスターから他方のクラスターにメッセージを移動できるため、クラスター間でオフセットが確実に保持されます。これを、"バイト単位" のレプリケーションと呼びます。送信元上のどのようなデータも、送信先クラスターに正確にミラーリングされます。

Cluster Linking と Built-in Multi-Region Replication を組み合わせることで、可用性と耐久性が高い分散型のグローバルイベントファブリックを構築できます。Built-in Multi-Region Replication は、一部のトピックで自動クライアントフェイルオーバー（低 RTO）または RPO=0 が必要な場合に使用します。Cluster Linking は、ネットワークの品質に問題がある、データセンター間が非常に離れている、または RTO 目標でクライアントの再構成を許容できる場合に使用します。

注釈

送信先クラスターは Confluent Server を実行している必要があり、送信元クラスターには Confluent Server または Apache Kafka® 2.4 以降を使用できます。Cluster Linking は、プレビュー機能として Confluent Platform 6.0.0 に導入されています。

機能と比較

Cluster Linking には以下の機能があります。

  • クラスター間でオフセットを保持するため、システムのフェイルオーバーと合理化がより簡単になります。
  • 再圧縮を回避することでレプリケーションを高速化します。
  • データセンター間のデータ移動を減らすことでレプリケーションコストが削減され、大陸間クラスターの構築が可能になるため、専用の Built-in Multi-Region Replication ソリューションを低コストで補完できます。
  • Confluent Cloud の操作を簡素化および円滑化します。
  • ハイブリッドクラウドアーキテクチャ（ライトワンス、リードメニー）をサポートしています。Kafka と Cluster Linking を使用してインフラストラクチャ環境をブリッジすることで、モニタリング可能でセキュアな単一のシステムを構築できます。これにより、オンプレミスデプロイ、Confluent Cloud およびクラウドプロバイダーに対応するコスト効率に優れたトランスポートレイヤーが実現されます。
  • Cluster Linking と標準または Built-in Multi-Region Replication クラスターの組み合わせにより、Kafka のグローバルメッシュが実現します。距離が非常に遠く、ネットワーク許容値が異なる場合でも、目標復旧時間 （RTO）と 目標復旧時点 （RPO）を大幅に短縮できます。
  • 集約クラスターの基礎を構築できます。

サポート対象

  • Confluent Server が必要です。具体的には、送信元クラスターには Confluent Platform 5.4 以降（Apache Kafka® 2.4）、送信先クラスターには Confluent Platform 6.0.0 以降が必要です。
  • Confluent Platform 7.0.0 では、送信元クラスターと送信先クラスターの両方で、2.7 以上のブローカー間プロトコル（IBP）が必要です。Confluent Platform 6.1.x および 6.2.x では、2.7 の IBP をお勧めしますが必須ではありません。こうした以前のバージョンでも、2.4 以降の IBP は使用できます。下位の IBP からアップグレードする必要がある場合は、これをブローカーの inter.broker.protocol.version の値として設定できます。
  • すべての クライアント で正常に動作します。
  • Ansible および Kubernetes 用の Confluent と互換性があります。詳細については、Cluster Linking と Ansible の使用 と Cluster Linking と Confluent for Kubernetes の使用 を参照してください。
  • 認証と認可をサポートしています（「Cluster Linking のセキュリティ」を参照）。ただし、既知の制限 がいくつかあります。
  • 送信元クラスターには Kafka または Confluent Server を使用でき、送信先クラスターは Confluent Enterprise にバンドルされている Confluent Server である必要があります。
  • 送信元クラスターが Confluent Server の場合、Confluent Platform 5.4 以降である必要があります。送信元クラスターが Kafka の場合、Apache Kafka® 2.4 以降である必要があります（前述のように、どちらの場合も、Confluent Platform 7.0.0 より前のデプロイでは 2.4 以降の IBP が、また、Confluent Platform デプロイ 7.0.0 以降では 2.7 以降の IBP が必須となります）。
  • Confluent Platform 上のセルフマネージド型デプロイに加え、Cluster Linking は Confluent Cloud および ハイブリッドクラウドアーキテクチャ のマネージド型サービスとしても使用できます。

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

以下のユースケースは、示されている構成とアーキテクチャによって実現できます。これらのデプロイのデモについては、「Cluster Linking のデモ（Docker）」と「Cluster Linking のチュートリアル」を参照してください。

トピックデータ共有

ユースケース : 2 つの Kafka クラスター間で少数のトピックを共有します。

  • 送信元クラスター
  • 送信先クラスター

トピック共有の場合、データはクラスターリンクによって送信元クラスターから送信先クラスターに移動します。ミラートピックは、クラスターリンクに関連付けられます。送信先クラスターのコンシューマーは、ローカルにある読み取り専用のミラートピックを読み取り、送信元クラスターで生成されたメッセージを読み取ります。送信元クラスターの元のトピックがなんらかの理由で削除された場合は、そのトピックのミラーリングを停止して、送信先で読み取り/書き込みトピックに変換できます。

クラスター移行

ユースケース : オンプレミス Kafka クラスターから Confluent Cloud Kafka クラスターに移行する、または古いバージョンから新しいバージョンに移行します。ブローカーの Confluent Server を活用することでネイティブオフセットが保持されるため、他の Connect ベースの方法より Cluster Linking を使用する方がはるかに簡単です。

ハイブリッドクラウドアーキテクチャ

ユースケース : 少数のトピック用に実行されているデータファネルをオンプレミス環境から Confluent Cloud にデプロイします。Cluster Linking は、これを適切にサポートするネットワーク分断耐性アーキテクチャを提供します（ネットワーク接続が瞬間的に失われても、特定のクラスター上のデータに大きな影響を与えません）。一方、ストレッチクラスターでこれを行おうとする場合は、信頼性が高く堅牢なネットワークが必要になります。

既知の制限

  • Cluster Linking のプレビューを本稼働環境のユースケースに使用することは推奨されません。このプレビューでは一部の Kafka 機能がサポートされていません。
  • 送信元クラスターは Confluent Platform 5.4 以降（Apache Kafka® 2.4）で、送信先クラスター Confluent Platform 6.0.0 以降である必要があります。
  • トピック名の変更は現時点ではサポートされていません。したがって、送信元ピックと送信先のミラートピックは同じ名前である必要があります。
  • リンクは一方向です。単一のリンクで双方向レプリケーションを実現するように構成することはできません。これには 2 つのリンクを使用する必要があります。
  • 接続は送信先クラスターからのみ確立されます。送信元クラスターは送信先ブローカーからのインバウンド接続リクエストを受け付けるように構成されている必要があります。これにより、一部のセキュリティモデルに対応できます（すべてではありません）。
  • 現時点では、ディザスターリカバリは Cluster Linking では推奨されません。レプリケーションメカニズムはオフセット保持（バイト単位）ですが、信頼性の高いフェイルバックのサポートはまだ実装されていません。現時点では、Cluster Linking の最適なオプションは、別のクラスターへの "フェイルフォワード" です。
  • 集約トピックは現時点ではサポートされていません。複数のクラスターから 1 つのクラスターに複数のトピックを集約することはできません。現時点では、そのためには Confluent Replicator を引き続き使用してください。
  • すべての SSL キーストア、トラストストア、および Kerberos キータブファイルは、特定のクラスター内の各ブローカー上の同じ場所に格納されている必要があります。そのように格納されていないと、クラスターリンクが失敗する場合があります。
  • これまで Confluent Platform 6.0.0 から 6.2.x で使用できた ACL 移行（ACL 同期）は、セキュリティ上の脆弱性があるため削除されました。デプロイで ACL 移行を使用している場合は、無効にする必要があります。詳細については、「認可（ACL）」を参照してください。