すべてのプロダクト
Search

このプロダクト

    Migration Hub:Alibaba Cloud 上のセルフマネージド Kafka クラスターへのセルフマネージド Kafka クラスターの移行

    ドキュメントセンター

    Migration Hub:Alibaba Cloud 上のセルフマネージド Kafka クラスターへのセルフマネージド Kafka クラスターの移行

    最終更新日:Nov 25, 2025

    1. シナリオ

    このソリューションは、別のクラウドプロバイダーまたはインターネットデータセンター (IDC) から Alibaba Cloud 上のセルフマネージド Kafka クラスターにセルフマネージド Kafka クラスターを移行する場合に適用されます。

    移行タイプはメタデータ移行です。

    2. 移行ツール

    1. MirrorMaker

    MirrorMaker は、クラスター間でデータをレプリケーションするために Apache Kafka が提供するツールです。2 つのバージョンがあります。

    • MirrorMaker 1: kafka-mirror-maker.sh スクリプトを使用して実装されます。メッセージの移行のみをサポートし、メタデータの同期はサポートしません。

    • MirrorMaker 2: connect-mirror-maker.sh スクリプトを使用して実装されます。メタデータとメッセージの両方の移行をサポートし、Kafka Connect フレームワークに依存します。

    使用する MirrorMaker のバージョンを決定するには、ソース Kafka のバージョンを確認します。connect-mirror-maker.sh ファイルが kafka/bin/ フォルダーに存在する場合は、MirrorMaker 2 を使用できます。それ以外の場合は、MirrorMaker 1 を使用します。

    3. 移行計画

    1. 移行フロー

    • インスタンスの作成: Alibaba Cloud ECS インスタンスにセルフマネージド Kafka クラスターをデプロイし、基本的な環境構成を完了します。

    • データ移行:

      • メタデータ移行: MirrorMaker 2 を使用して、Topic 構成、パーティション数、レプリカ数、アクセス制御リスト (ACL) 権限などのメタデータを同期します。

    • データ検証: Topic 数、パーティション数、メッセージ数、メッセージ内容の一貫性を検証します。

    2. データ移行計画

    2.1. MirrorMaker の使用

    移行の原則:

    MirrorMaker のコンシューマーモジュールとプロデューサーモジュールを使用して、ソース Kafka クラスターからメッセージをプルし、宛先 Kafka クラスターに書き込みます。このプロセスにより、データ同期が実現されます。

    前提条件:

    • ソース Kafka クラスターにアクセス可能であり、必要なネットワークポートを開く必要があります。

    • 宛先 Kafka クラスターがデプロイされ、実行中である必要があります。

    • MirrorMaker のバージョンがソース Kafka のバージョンと互換性があることを確認してください。

    リスクと注意事項:

    • データ移行中は、ネットワーク帯域幅、ディスク I/O、および Kafka クラスターのペイロードをモニターする必要があります。

    • ソース Kafka クラスターにコミットされていないトランザクションメッセージがある場合は、トランザクションの一貫性を確保する必要があります。

    利点:

    • 完全移行と増分移行をサポートし、大規模なデータ同期のニーズに対応します。

    • Topic ホワイトリストの指定など、構成を通じて移行範囲を柔軟にコントロールできます。

    3. データ検証計画

    3.1. メタデータ検証

    • kafka-topics.sh --describe コマンドを使用して、宛先クラスターの Topic 構成がソースクラスターと一致しているかどうかを確認できます。

    • パーティション数、レプリカ数、ACL 権限などのメタデータ情報を比較できます。

    4. 移行手順

    1. Alibaba Cloud RocketMQ コンソールの移行ツールを使用したメタデータとメッセージの移行

    移行は MirrorMaker を使用して実行されます。ツールは `kafka-mirror-maker.sh` で、`bin` フォルダーにあります。

    ステップ 1: コンシューマーとプロデューサーの構成

    移行の鍵は、MirrorMaker のコンシューマーとプロデューサーを構成することです。構成ファイルは `consumer.properties` と `producer.properties` で、`config` フォルダーにあります。

    `consumer.properties` ファイルは次のように構成されます:

    # 注: ここにソースクラスターのアドレスを構成します。
bootstrap.servers=172.20.77.74:9092 

# コンシューマーグループ ID
group.id=migration-group

auto.offset.reset=earliest

    `producer.properties` ファイルは次のように構成されます:

    # フォーマット: host1:port1,host2:port2 ...
# 注: ここに宛先クラスターのアドレスを構成します。
bootstrap.servers=172.20.77.91:9092

    ステップ 2: メタデータ移行の実行

    構成が完了したら、移行コマンドを実行できます。コマンド内:

    --whitelist: 移行する Topic のカンマ区切りリストを指定します。

    ./kafka-mirror-maker.sh --consumer.config ../config/consumer.properties --producer.config ../config/producer.properties --whitelist="migration-to-aliyun"

    ステップ 3: 移行ステータスのモニター

    • MirrorMaker ログ (logs/mirror-maker.log) を確認して、エラーがないことを確認できます。

    • kafka-topics.sh --list コマンドを使用して、宛先クラスターで Topic が正常に作成されたことを確認できます。

    5. データ検証手順

    1. メタデータ検証

    `kafka-topics.sh --describe --zookeeper <zk_host>` コマンドを使用して、ソースクラスターと宛先クラスターの Topic 構成を比較できます。 また、`kafka-acls.sh` コマンドを使用して、ACL 権限が同期されていることを確認することもできます。

    6. 移行に関する注意事項

    1. バージョンの互換性: プロトコルの違いによる移行の失敗を防ぐために、ソースと宛先の Kafka バージョンに互換性があることを確認してください。

    2. ネットワーク接続性: 中断を避けるために、移行中はソースクラスターと宛先クラスター間の安定したネットワーク接続を維持してください。

    3. データの一貫性: 移行中にソースデータを変更しないでください。または、増分同期を使用して一貫性を確保することもできます。

    4. リソースの予約: パフォーマンスのボトルネックを防ぐために、移行中に十分な CPU、メモリ、および帯域幅リソースを予約してください。

    5. ロールバック計画: 移行の失敗に対処するためのロールバック計画を作成します。たとえば、ソースデータを保持してサービスを迅速に回復できます。