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.0.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]

脚注

[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

クラスター移行¶

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

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

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

Starting with Confluent Platform 7.0.1, source-initiated cluster links (recommended for ハイブリッドクラウドとクラウドへのブリッジ) can now be created with the REST API. Previous to Confluent Enterprise 7.0.1, only regular destination-initiated cluster links could be created with the REST API. Now both types of cluster links can be created with either the REST APIs or the kafka-cluster-links CLI.
Confluent Platform 7.0.x では、送信元開始クラスターリンクを一覧表示し、取得するための REST API 呼び出しに、パラメーター source_cluster_id で返される送信先クラスター 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 の使用はサポートされておらず、推奨されません。
Cluster Linking は現時点では KRaft では機能しません。Cluster Linking には ZooKeeper が必要です。
これまで Confluent Platform 6.0.0 から 6.2.x で使用できた ACL 移行（ACL 同期）は、セキュリティ上の脆弱性があるため削除されました。デプロイで ACL 移行を使用している場合は、無効にする必要があります。詳細については、「認可（ACL）」を参照してください。