Topics、データ、スキーマ、コネクタ、アクセス制御、クライアントなど、あらゆる Kafka ソースからデータとインフラストラクチャを移行できます。当社のツールはクライアントを段階的に移行するため、アプリケーションは最小限の調整とダウンタイムで稼働し続けることができます。
移行作業で最も難しいのはレプリケーションではなく調整ですが、Confluent なら簡単です。クライアントがゲートウェイに接続すると、クラスタリンク機能がバックグラウンドでレプリケーションを実行し、準備が整ったらコマンドを1つ実行するだけで、大量の Topics を Confluent に移行できます。
レプリケーションの遅延を監視し、実行するタイミングを選びます。コマンドを実行するまで、切り替えは発生しません。
すべてのクライアントは、一度だけ単一の Confluent Gateway アドレスに再設定されます。それ以降は、ゲートウェイが認証情報を切り替え、クライアントを Confluent にルーティングするため、再起動や設定変更は一切不要です。
単一の Topic またはグループを移行します。クラスタリンクはオフセットを保持したままバイト単位で複製するため、コンシューマーは中断したところから処理を再開できます。
すべてのバイトがレプリケートされてラグがゼロになるまでトラフィックは保留され、その後にトピックが昇格されます。カットオーバーが完了するまでは、各移動を元に戻すことができます。
Confluent の移行ツールである KCP は、あらゆる Kafka Cluster で動作します。ソース環境をスキャンして移行を評価し、すべてのリソースを Confluent Cloud に移行します。
クライアントは、変更されることのない単一のゲートウェイエンドポイントに接続します。各トピックが昇格されると、ゲートウェイはそのトピックを Confluent にルーティングし始め、残りのトピックは引き続きソースに流れます。クライアントの変更も、ダウンタイムもありません。
Topics だけを移動して残りを放置するようなことはありません。KCP はシステム全体を移行します。各レイヤーは専用の Confluent コンポーネントによって処理され、自動的に調整されます。
| リソース | 対応担当 | 起こること |
|---|---|---|
| Topic とデータ | Cluster Linking | バイト単位でそのままコピーされ、コンシューマーの位置が保持されるため、アプリケーションは中断した箇所から再開できます。 |
| スキーマ | スキーマの移行 | データが移動する前に Confluent Schema Registry に登録されるため、アプリケーションが導入される時点でスキーマが用意されています。 |
| Connectors | Connect 移行ユーティリティ | サポート対象の Connector を構成と状態とともに Confluent 管理コネクターとして再作成します。 |
| アクセス制御 | ACL とアイデンティティマッピング | 既存のユーザー、ロール、ACL は Confluent のサービスアカウントと ACL にマッピングされます。 |
| アプリケーション | Migration Gateway | 接続先を一度変更するだけで、コードを変更することなく切り替えられ、再認証も代行されます。 |
| 費用ベースライン | 評価 | 実際の使用状況から現在の支出額を取得するため、移行前に比較対象となるベースラインを把握できます。 |
移行を計画 環境に関するいくつかの質問に答えることで、順序立てられた移行計画を入手できます。
環境を評価 現在のクラスターをスキャンして、すべてのリソースと現在のコストを確認できます。
詳しく相談 Confluent の移行スペシャリストとともに、お客様の固有のセットアップについて順を追って確認できます。