Confluent Platform の Cluster Linking ドキュメントをお探しですか? このページは Confluent Cloud における Cluster Linking の説明です。Confluent Platform のドキュメントをお探しの場合は、Confluent Platform の「Cluster Linking」をご覧ください。

Confluent Cloud での Cluster Linking¶

Cluster Linking とは¶

Confluent Cloud 上の Cluster Linking は、Confluent クラスター間でデータを移動するフルマネージド型のサービスです。プログラムによってトピックの完全なコピーを作成し、クラスター間でデータが同期された状態に保ちます。Cluster Linking は、以下の用途を目指した強力な Geo レプリケーションテクノロジです。

転送中のリアルタイムデータを核とするマルチクラウドかつグローバルなアーキテクチャ
異なるチーム間や異なる業種間のデータ共有
リージョンのクラウドプロバイダーが機能を停止した際の高可用性（HA）/ディザスターリカバリ（DR）
Apache Kafka® クラスターから Confluent Cloud へのデータとワークロードの移行

Confluent Cloud の Cluster Linking はフルマネージド型であるため、データフローを自分で管理したりチューニングしたりする必要はありません。その料金は使用量ベースであるため、マルチクラウド、マルチリージョンのコストを適切に管理することができます。Cluster Linking によって運用の負荷とクラウド転送料金が下がり、クラウドデータパイプラインのパフォーマンスと信頼性が向上します。

動作概念¶

Cluster Linking を使用すると、Confluent クラスター間でデータを直接ミラーリングできます。クラスターリンクは、リージョン、クラウド、業種、組織の垣根を超えて、送信元クラスターと送信先クラスターとの間で確立できます。送信元クラスターから送信先クラスターにレプリケートするトピックは自分で選択することができます。さらに、コンシューマーオフセットや ACL をミラーリングすることもできるため、クラスター間での Kafka コンシューマーの移動も容易です。

../../_images/cloud-cluster-linking-overview.ja.png

クラスター間には、1 回のコマンドまたは API 呼び出しでクラスターリンクを作成できます。クラスターリンクは、2 つのクラスターをつなぐ永続的なブリッジとしての機能を果たします。

confluent kafka link create tokyo-sydney
  --source-bootstrap-server pkc-867530.ap-northeast-1.aws.confluent.cloud:9092
  --source-cluster-id lkc-42492
  --api-key AP1K3Y
  --api-secret ********

クラスターリンク越しにデータをミラーリングするには、送信先クラスターにミラートピックを作成します。

confluent kafka mirror create clickstream.tokyo
   --link tokyo-sydney

../../_images/cloud-cluster-linking-mirror.ja.png

ミラートピックは、特殊なトピック、つまり対応する送信元トピックの読み取り専用コピーです。送信元トピックに対して生成されるすべてのメッセージは、ミラートピックに "バイト単位" でミラーリングされます。同じメッセージは、ミラートピック上の同じパーティション、同じオフセットに反映されるということです。ミラートピックは、他のトピックと同じように消費できます。

../../_images/cluster-link-mirror-topics-example.ja.png

クラスターリンクとミラートピックは、リージョン、クラウド、チーム、組織の違いを超えて、スケーラブルで一貫性のあるアーキテクチャを作成するための基本要素です。

Cluster Linking では、重要なメタデータがレプリケートされます。

Cluster Linking では、送信元トピックとミラートピックとの間でトピックの構成を同期することについてのベストプラクティスが適用されます（同期される構成と同期されない構成があります）。
必要であればコンシューマーオフセットの同期を有効にして、送信元トピックからミラートピック（ミラートピックのみを対象）にコンシューマーオフセットを同期したり、特定のコンシューマーグループを条件にフィルタリングしたりできます。
ACL の同期を有効にして、クラスター上の（ミラートピックに限らず）すべての ACL を同期できます。必要に応じてトピック名またはプリンシパル名を条件にフィルタリングできます。

これらの機能については、各種チュートリアルで取り上げています。

ユースケース¶

Confluent Cloud には、マルチクラウド、マルチリージョン、ハイブリッドの機能が備わっています。そうした機能のいくつかについては、チュートリアルにデモが紹介されています。

グローバルなマルチクラウドの複製: リージョンおよびクラウド間でリアルタイムデータを移動して集約します。リアルタイムデータの地理的位置情報の読み取りを可能にすることで、Kafka イベントの Content Delivery Network（CDN）のような機能をパブリッククラウド、プライベートクラウド、エッジの全体にわたって実現できます。
データ共有 - 他のチーム、事業部門、組織とデータをリアルタイムで共有します。
データ移行 - クラスター間でデータとワークロードを移行します。
ディザスターリカバリと高可用性 - ディザスターリカバリクラスターを作成しておき、機能停止が生じたとき、そのクラスターにフェイルオーバーします。

Cluster Linking のミラーリングスループット（クラスターからのデータの読み取りまたはクラスターへのデータの書き込みに使用される帯域幅）には、ご利用の CKU 単位の制限が適用されます。

サポートされるクラスタータイプ¶

クラスターリンクは、"送信元クラスター" から "送信先クラスター" にデータを送信します。サポートされるクラスタータイプを以下の表に示します。

The source cluster can be Kafka or Confluent Server or Confluent Cloud running version 2.4 of the inter.broker.protocol (IBP); the destination cluster must be either a Confluent Cloud dedicated cluster or Confluent Server, which is bundled with Confluent Enterprise.

サポート対象外のクラスタータイプとその他の制限については、「制限」を参照してください。

送信元クラスターのオプション	送信先クラスターのオプション
インターネットネットワーキングを備えた専用 Confluent Cloud クラスタースタンダード Confluent Cloud クラスターベーシック Confluent Cloud クラスター	インターネットネットワーキングを備えた専用 Confluent Cloud クラスター
Apache Kafka® 2.4+ or Confluent Platform 5.4+ with public internet IP addresses on all brokers	インターネットネットワーキングを備えた専用 Confluent Cloud クラスター
Confluent Platform 7.0+ (even behind a firewall)	インターネットネットワーキングを備えた専用 Confluent Cloud クラスター
インターネットネットワーキングを備えた専用 Confluent Cloud クラスタースタンダード Confluent Cloud クラスターベーシック Confluent Cloud クラスター	Confluent Platform 7.0+ (even behind a firewall)

クラスタータイプを確認する方法¶

Confluent Cloud クラスターのタイプとエンドポイントのタイプを確認するには、以下の手順に従います。

Confluent Cloud にログオンします。
環境を選択します。
クラスターを選択します。

クラスターのサマリーカードにクラスタータイプが表示されます。

または、クラスターをクリックして、左側のメニューから Cluster settings を選択する方法もあります。"Cluster type" のサマリーカードにクラスタータイプが表示されます。

専用クラスターの Cluster settings から Networking タブをクリックしてエンドポイントのタイプを確認します。Networking タブがあるのは専用クラスターのみです。ベーシッククラスターとスタンダードクラスターには必ずインターネットネットワーキングがあります。ネットワークは、最初に専用クラスターを作成する際に定義します。

料金¶

Cluster Linking を使用する Confluent Cloud クラスターは、クラスターリンクの数およびクラスターとの間のミラーリングスループットの量に基づいて請求されます。

メトリクスを使用してコストを追跡するためのガイドラインを含め、Cluster Linking の請求方法の詳しい内訳については、「Confluent Cloud の請求」の「Cluster Linking」を参照してください。

Confluent Cloud の料金全般については、ウェブサイトに記載されています。Confluent Cloud の料金ページを参照してください。

プレビュー機能について¶

Confluent Cloud の Cluster Linking は一般提供が開始されています。ただし、以下の項目については、開発者からの早期フィードバックを得るため、プレビューモードでの導入となります。これらのメトリクスは、評価、非本稼働環境でのテスト、あるいは Confluent へのフィードバックの提供を目的として使用される場合があります。プレビュー機能に関するご意見、ご質問、ご提案を clusterlinking@confluent.io までお寄せください。お待ちしております。

io.confluent.kafka.server/cluster_link_mirror_topic_count
io.confluent.kafka.server/cluster_link_mirror_topic_bytes
io.confluent.kafka.server/cluster_link_mirror_topic_offset_lag

概要¶

初めて Cluster Linking をご利用になる方のために、以下、次のステップに向けた推奨事項をいくつか紹介します。

チュートリアル¶

まずチュートリアルに取り組んでみましょう。それぞれユースケースに対応しています。

ミラートピック¶

オリジナル（送信元）トピックを反映する読み取り専用の "ミラートピック" は、Cluster Linking の基本要素です。この特殊なタイプのトピックとそのしくみの詳細解説については、「Mirror Topics」を参照してください。

コマンドと前提条件¶

送信元クラスターからのリンクは、送信先クラスターで confluent kafka link コマンドを使用して作成できます。プレビュー期間中にチュートリアルを実行するには、以下の前提条件の手順が必要となります。

Confluent Cloud で Cluster Linking を試すには、以下のようにします。

Confluent Cloud をインストールします（まだインストールしていない場合）。
- ウェブからインストールする代わりに、ターミナルウィンドウから 2 つのコマンドを実行することでも簡単に Confluent Cloud を入手できます（どちらのコマンドも、~/.local/bin は必要に応じて別のディレクトリに置き換えてください）。
```
curl -L --http1.1 https://cnfl.io/ccloud-cli | sh -s -- -b ~/.local/bin
```
```
export PATH=~/.local/bin:$PATH;
```
- Confluent Cloud 全般の情報については、「Confluent Cloud を使用した Apache Kafka のクイックスタート」を参照してください。
Confluent Cloud にログオンします。

Cluster Linking コマンドの最新バージョンを確実に使用するために Confluent CLI をアップデートします。詳細については、クイックスタートの「Confluent CLI の最新バージョンの取得」を参照してください。

confluent kafka link コマンドには、以下のサブコマンドまたはフラグがあります。

コマンド	説明
`create`	新しいクラスターリンクを作成します。
`delete`	以前に作成されたクラスターリンクを削除します。
`describe`	既存のクラスターリンクの詳細を表示します。
`list`	既存のクラスターリンクをリスト表示します。
`update`	既存のクラスターリンクのプロパティをアップデートします。

confluent kafka mirror コマンドには、以下のサブコマンドまたはフラグがあります。

コマンド	説明
`describe`	ミラートピックの詳細を表示します。
`failover`	ミラートピックをフェイルオーバーします。
`list`	クラスターに含まれるミラートピックまたは指定されたクラスターリンク下のミラートピックをすべてリスト表示します。
`pause`	ミラートピックを一時停止します。
`promote`	ミラートピックをプロモートします。
`resume`	既存のクラスターリンクのプロパティをアップデートします。

チュートリアルに従って Cluster Linking を実際に使ってみます。コマンドのデモについては、チュートリアルを参照してください。

CLI の高度なヒント¶

Confluent Cloud CLI コマンドのリストは、こちらでご覧いただけます。以下に、コマンドラインワークフローの時間短縮につながる一般的な戦略をいくつか紹介します。

コマンド出力をテキストファイルに保存する¶

絶えず情報を追跡するために、Confluent Cloud のコマンド出力をテキストファイルに保存します。そのようにする場合は、後でファイルを削除するか、セキュリティコードだけをより安全なストレージに移動するなどして、API キーとシークレットを必ず保護してください。コマンド出力をファイルにリダイレクトするには、次のどちらかの方法を使用します。情報を整理するために手動で見出しを追加することができます。

出力をファイルにリダイレクトするには、Linux 構文（<command> > notes.txt など）で最初のコマンドを実行してメモファイルを作成し、その後は <command> >> notes.txt を実行して出力を追記します。
出力をファイルに送信したうえで、画面にも表示するには（推奨）、<command> | tee notes.txt を使用して最初のコマンドを実行し、ファイルを作成します。その後は、tee コマンドと -a フラグを使用して追記します（例: <command> | tee -a notes.txt）。

コマンドで使用するデータを構成ファイルに保存する¶

API キーとシークレット、クラスターリンクの詳細な構成、Confluent Cloud の外部のクラスターに対するセキュリティ認証情報を保存するための構成ファイルを作成します。その例については、トピックデータの共有に関するチュートリアルの「（通常は省略可能）config ファイルの使用」およびディザスターリカバリに関するチュートリアルの「クラスターリンクの作成」を参照してください。

環境変数にリソース情報を保存する¶

シェルの環境変数に権限やクラスターデータを保存することでコマンドラインのワークフローを効率化できます。API キーとシークレット、リソース（クラスター、サービスアカウント、環境の ID など）、ブートストラップサーバーを変数に保存して、Confluent のコマンドで使用します。

たとえば、次のようにして環境とクラスターの変数を作成します。

export CLINK_ENV=env-200py
export USA_EAST=lkc-qxxw7
export USA_WEST=lkc-1xx66

それらをコマンドで使用するには、次のようにします。

$ confluent environment use $CLINK_ENV
Now using "env-200py" as the default (active) environment.

$ confluent kafka cluster use $USA_EAST
Set Kafka cluster "lkc-qxxw7" as the active cluster for environment "env-200py".

以上のことを踏まえてコマンドを記述する¶

以下に示したのは、クラスター、API キー、シークレットの環境変数を作成し、link.config というファイルにクラスターリンクの構成の詳細を保存したという前提で、"east-west-link" という名前のクラスターリンクを変数と構成ファイルを使用して作成する例です。

confluent kafka link create east-west-link \
  --cluster $DESTINATION_ID  \
  --source-cluster-id $ORIG_ID \
  --source-bootstrap-server $ORIG_BOOT  \
  --config-file link.config

制限¶

このセクションでは、クラスタータイプ、クラスター管理、パフォーマンスの観点からサポートと既知の制限について詳しく取り上げます。

クラスターのタイプとネットワーク¶

現在サポートされているクラスタータイプは、「サポートされるクラスタータイプ」に記載されています。

ネットワークタイプが Transit Gateway、VPC ピアリング、Privatelink、VNet ピアリングのいずれかに該当する Confluent Cloud クラスターでは、Cluster Linking がサポートされません。プライベートネットワークに接続された Confluent Cloud クラスターでの Cluster Linking の使用をご希望の場合、Confluent アカウントチームにお問い合わせいただくか、メール（clusterlinking@confluent.io）にて詳しい情報を入手してください。

5 つを超える送信元クラスターから 1 つの送信先クラスターへのデータの集約は現在、Cluster Linking ではサポートされません。

ACL の同期¶

Cluster Linking の主要な機能として、クラスター間で ACL を同期することができます。これは、移行やフェイルオーバーの目的でクライアントをクラスター間で移動する場合に便利です。ただし Confluent Cloud のクラスターでは、そのクラスター自体と同じ Confluent Cloud 組織にあるサービスアカウント向けにしか ACL を作成できません。このため、実質的に、ACL の同期は同じ Confluent Cloud 組織にある 2 つの Confluent Cloud クラスターの間でのみ機能するものとなります。

ACL の同期は、Confluent Platform と Confluent Cloud、または Apache Kafka® と Confluent Cloud のような、異なる組織にある 2 つの Confluent Cloud クラスターの間では使用できません。

As a general rule, do not include in the sync filter ACLs that are managed independently on the destination cluster. This is to prevent cluster link migration from deleting ACLs that were added specifically on the destination and should not be deleted. See also, クラスターリンクの動作の構成 and Syncing ACLs from Source to Destination Cluster.

重要

一時的な既知の制限: ACL の同期を使用する場合、送信元クラスターで削除された ACL が送信先クラスターで削除されていることを手動で確認する必要があります。送信元クラスターで ACL が作成または削除されると、ACL の同期機能がその変更を送信先クラスターに伝搬します。しかし、送信元クラスターでの ACL の削除が送信先クラスターに同期されないことがまれに発生します。このため当面は、ACL の同期機能を使用する場合、送信元クラスターで ACL を削除する際はそのつど、該当の ACL が送信先クラスターでも削除されていることを確認する必要があります。クラスターリンクによって削除されていない場合は、送信先クラスターの ACL を手動で削除してください。

管理の制限¶

クラスターリンクの作成と管理は、送信先クラスターで行う必要があります。
クラスターリンクは、インターネットネットワーキングを備えた Confluent Cloud 専用クラスタータイプの送信先クラスターでのみ作成できます。
In Confluent Platform 7.0.0, source initiated cluster links (recommended for hybrid cloud) cannot be created with the REST API; they must be created with the kafka-cluster-links CLI. Regular, destination initiated cluster links can be created with either the REST API or kafka-cluster-links CLI.
In Confluent Platform 7.0.x, REST API calls to list and get source-initiated cluster links will have their destination cluster IDs returned under the parameter source_cluster_id.
ミラートピックは、他のトピックとまったく同じように、クラスターのトピック制限、パーティション制限、ストレージ制限にカウントされます。
クラスターリンクには、送信先クラスターのトピック数とパーティション数を上限として、トピックまたはパーティションをいくつでも割り当てることができます。
送信先となるターゲットクラスターには、最大 5 つのクラスターリンクを設定できます。つまり、送信先クラスターにデータをレプリケートできるクラスターリンクは 5 つまでです。1 つのクラスターに必要なクラスターリンクが 5 つを超える場合は、Confluent サポートにお問い合わせください。
本質的に、1 つのミラートピックに割り当てることができるのは、1 つのクラスターリンクと、そのミラートピックにデータをレプリケートする 1 つの送信元トピックのみです。逆に、1 つのトピックの送信先となるミラートピックの数に制限はありません。
コンシューマーグループオフセットの同期、ACL の同期、トピック構成の同期に使用される同期プロセスの頻度はユーザーが構成できます。これらの同期を実行できる頻度は、1 秒（設定はミリ秒単位であるため 1000 ms）につき 1 回までです。同期の実行頻度をもっと長くすることはできますが、1000 ms より短くすることはできません。

Kafka transactions such as "exactly once" semantics not supported on mirror topics¶

Cluster Linking is not integrated with Kafka transactions, including "exactly once" semantics. Using Cluster Linking to mirror topics that contain transactions or exactly once semantics is not supported and not recommended.

パフォーマンスの制限¶

スループット

Cluster Linking のスループットは、データレプリケーションの 1 秒あたりのバイト数で表されます。次のパフォーマンスファクターと制限が適用されます。

Cluster Linking のスループット（データレプリケーションの 1 秒あたりのバイト数）は、送信先クラスターにおける生成の制限（"受信" または "書き込み" の制限）に加味されます。ただし、Kafka クライアントからの生成は、Cluster Linking による書き込みよりも優先されます。そのため、これらは Metrics API に別個のメトリクスとして公開されています。つまり、Kafka クライアントによる書き込みは received_bytes、Cluster Linking による書き込みは cluster_link_destination_response_bytes です。
Cluster Linking は、Kafka コンシューマーと同じように送信元クラスターから消費します。スループット（データレプリケーションの 1 秒あたりのバイト数）は、コンシューマーのスループットと同じように扱われます。Cluster Linking は、送信元クラスターのクォータやハード制限、ソフト制限にカウントされます。したがって、Kafka クライアントによる読み取りと Cluster Linking による読み取りは、Metrics API の同じメトリック（sent_bytes）に反映されます。
Cluster Linking は、CKU のスループットを限界まで使い切ることができます。クラスター間の物理的な距離が、Cluster Linking のパフォーマンスのファクターとなります。Confluent はクラスターリンクをモニタリングして、そのパフォーマンスを最適化します。Replicator や Kafka MirrorMaker 2 とは異なり、Cluster Linking には、固有のスケーリング（つまり、タスク）はありません。パフォーマンスを高めるためにクラスターリンクをスケールアップしたりスケールダウンしたりする必要はありません。

接続

Cluster Linking の接続は、クラスターの接続制限にカウントされます。

リクエストレート

Cluster Linking は、送信元クラスターのリクエストレート制限にカウントされるリクエストの一因となります。

よくある質問¶

クラスターリンクの追加は、送信元クラスターにおけるコンシューマーのスロットリングにつながりますか。¶

はい。その可能性はあります。クラスターリンクを追加することは、auto.offset.reset=earliest の新しいコンシューマーを追加することと似ています。そのため、クラスターリンクがプッシュするクラスターの消費量の合計がクラスターの消費スループットクォータを上回った場合、他のコンシューマーがスロットルされる可能性があります。これは、クラスターリンクが発揮できるスループット、ミラーリングしようとするデータの量、別途確保されている消費容量によっても異なります。

既存のトピックデータをミラーリングする場合、その履歴データを取得するために、クラスターリンクには最初、消費の "急増" が生じることに留意してください。データの状態が追い付くと、送信元トピックに対する生成速度と同じレベルにまで消費速度が下がります（ただし、クラスターリンクが生成のスループットに対処できることが前提です）。

クラスターリンクの追加は、送信先クラスターの既存のプロデューサーのスロットリングにつながりますか¶

いいえ。そのようなことはありません。Cluster Linking による送信先への書き込みよりも、Kafka クライアントのプロデューサーの方が優先されます。

既知の問題¶

送信元トピックを削除する場合の考慮事項¶

アクティブなミラートピックの送信元トピックは削除しないでください。削除すると Cluster Linking に問題が生じるおそれがあります。ベストプラクティスとして、以下の手順に従ってください。

削除しようとしている送信元トピックから読み取りを行うアクティブなミラートピックを、promote コマンドまたは failover コマンドで停止または削除します。
これで送信元トピックを安全に削除できます。

詳細については、「ミラートピック」の「送信元トピックの削除」を参照してください。

送信元クラスターが利用できない状態にある一方、昇格されたトピックまたはフェイルオーバートピックへのアクセスも制限される¶

以前はミラートピックであったものの promote または failover コマンドによって停止されたトピックが、既知の問題により表示できません。

当初ミラートピックを作成したクラスターリンクが、その送信元クラスターに到達できなくなると、そのミラートピックは SOURCE_UNAVAILABLE ステートになります（これは正常な動作です）。

この状態になると、このリンクによって作成されて、その後停止されたトピックのステータスが STOPPED から SOURCE_UNAVAILABLE に変わります。既にミラートピックではなくなっていたとしても同様です。

この間違ったステータスが反映されるのは、CLI、REST API、Metrics API からの読み取りコマンドの出力です。
Confluent Cloud Console には、これらのトピックが、通常のトピックであったとしてもミラートピックとして表示されます。そのためユーザーは、これらのトピックの構成をコンソールで編集することができません。
それでも、これらのトピックは通常のトピックとして機能します。生成と消費には影響しません。スキーマはスキーマレジストリで変更できます。Confluent Cloud CLI および REST API を使用してトピックの構成を編集でき、また、トピックを削除することができます。

回避策: この状態からシステムを復旧するには、クラスターリンクを削除するか、または送信元クラスターが利用可能な状態に戻るまで待ってください。

PAUSED または SOURCE_UNAVAILABLE ステータスのミラートピックで生じる不明なラグ¶

SOURCE_UNAVAILABLE ステータスまたは PAUSED ステータスのミラートピックを CLI や API で見ると、ラグ（Max Per Partition Mirror Lag）が 0 として表示されます。実際にはラグは不明であり、0 ではない可能性があります。