Amazon MSK クラスターへの移行 - Amazon Managed Streaming for Apache Kafka
Apache Kafka クラスターを Amazon MSK に移行する1 つの Amazon MSK クラスターから別のクラスターに移行するMirrorMaker 1.0 のベストプラクティスMirrorMaker 2.* の利点

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon MSK クラスターへの移行

MSK クラスターの移行には、Amazon MSK Replicator を使用できます。Amazon MSK Replicator とは を参照してください。または、Apache MirrorMaker 2.0 を使用して、非 MSK クラスターから Amazon MSK クラスターに移行することもできます。これを行う方法の例については、「 を使用してオンプレミスの Apache Kafka クラスターを Amazon MSK に移行する MirrorMaker」を参照してください。の使用方法については MirrorMaker、Apache Kafka ドキュメントの「クラスター間のデータのミラーリング」を参照してください。可用性の高い設定 MirrorMaker で を設定することをお勧めします。

MirrorMaker を使用して MSK クラスターに移行する際に実行する手順の概要

  1. 宛先 MSK クラスターを作成します

  2. 送信先クラスターと同じ Amazon VPC 内の Amazon EC2 インスタンス MirrorMaker から開始します。

  3. MirrorMaker ラグを検査します。

  4. が MirrorMaker 追いついたら、MSK クラスターブートストラップブローカーを使用してプロデューサーとコンシューマーを新しいクラスターにリダイレクトします。

  5. をシャットダウンします MirrorMaker。

Apache Kafka クラスターを Amazon MSK に移行する

CLUSTER_ONPREM という名前の Apache Kafka クラスターがあるとします。そのクラスターには、トピックとデータが入力されます。そのクラスターを CLUSTER_AWSMSK という名前の新しく作成された Amazon MSK クラスターに移行する場合、この手順では、実行する必要のあるステップの概要を示します。

既存の Apache Kafka クラスターを Amazon MSK に移行するには

  1. CLUSTER_AWSMSK で、移行するすべてのトピックを作成します。

    このステップ MirrorMaker では、適切なレプリケーションレベルで移行するトピックが自動的に再作成されないため、 を使用することはできません。CLUSTER_ONPREM で持っていたのと同じレプリケーション係数とパーティション数を使用して、Amazon MSK でトピックを作成できます。また、異なるレプリケーション係数とパーティション数を使用してトピックを作成することもできます。

  2. への読み取りアクセス権CLUSTER_ONPREMと書き込みアクセス権を持つインスタンス MirrorMaker から開始しますCLUSTER_AWSMSK。

  3. 以下のコマンドを実行して、すべてのトピックをミラーリングします。

    <path-to-your-kafka-installation>/bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'

    このコマンドでは、config/mirrormaker-consumer.properties は、CLUSTER_ONPREM のブートストラップブローカーを指します。例えば、bootstrap.servers=localhost:9092 です。また、 は CLUSTER_ のブートストラップブローカーconfig/mirrormaker-producer.propertiesを指しますAWSMSK。例えば、 ですbootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092。

  4. バックグラウンドで MirrorMaker 実行し続け、新しいデータはすべて CLUSTER_ONPREM. MirrorMaker mirrors を引き続き使用します。

  5. ミラーリングの進行状況を確認するには、各トピックの最後のオフセットと MirrorMaker が消費している現在のオフセットの間の遅延を調べます。

    MirrorMaker はコンシューマーとプロデューサーのみを使用していることに注意してください。したがって、kafka-consumer-groups.sh ツールを使用して遅延をチェックすることができます。コンシューマーグループ名を検索するには、group.id の mirrormaker-consumer.properties ファイル内を検索し、その値を使用します。ファイルにそのようなキーがない場合は、作成することができます。たとえば、group.id=mirrormaker-consumer-group を設定します。

  6. がすべてのトピックのミラーリング MirrorMaker を完了したら、すべてのプロデューサーとコンシューマーを停止し、 を停止します MirrorMaker。次に、プロデューサーおよびコンシューマーブートストラップブローカーの値を変更して、プロデューサーとコンシューマーを CLUSTER_AWSMSK クラスターにリダイレクトします。CLUSTER_AWSMSK のすべてのプロデューサーとコンシューマーを再起動します。

1 つの Amazon MSK クラスターから別のクラスターに移行する

Apache MirrorMaker 2.0 を使用して、非 MSK クラスターから MSK クラスターに移行できます。たとえば、Apache Kafka の 1 つのバージョンから別のバージョンに移行できます。これを行う方法の例については、「 を使用してオンプレミスの Apache Kafka クラスターを Amazon MSK に移行する MirrorMaker」を参照してください。または、Amazon MSK Replicator を使用して MSK クラスターの移行を行うこともできます。Amazon MSK Replicator の詳細については、「MSK レプリケーター」を参照してください。

MirrorMaker 1.0 のベストプラクティス

このベストプラクティスのリストは MirrorMaker 1.0 に適用されます。

  • 送信先クラスター MirrorMaker で を実行します。この方法では、ネットワークの問題が発生しても、メッセージはソースクラスターで引き続き使用できます。ソースクラスター MirrorMaker で を実行し、イベントがプロデューサーでバッファリングされ、ネットワークに問題がある場合、イベントが失われる可能性があります。

  • 転送中に暗号化が必要な場合は、ソースクラスターで実行します。

  • コンシューマーの場合は、auto.commit.enabled=false を設定します

  • プロデューサーの場合は、以下を設定します。

    • max.in.flight.requests.per.connection=1

    • retries=Int.Max_Value

    • acks=all

    • max.block.ms = Long.Max_Value

  • 生産者のスループットが高い場合:

    • メッセージのバッファリングとメッセージバッチの入力 — buffer.memory、batch.size、linger.ms を調整します

    • ソケットバッファの調整 — receive.buffer.bytes、send.buffer.bytes

  • データ損失を回避するには、ソースで自動コミットをオフにします。これにより、 はコミットを制御 MirrorMaker できます。通常、送信先クラスターから ack を受信した後に行われます。プロデューサーに acks=all があり、レプリケート先クラスターに min.insync.replicas が 1 つ以上設定されている場合、 MirrorMaker コンシューマーがソースでオフセットをコミットする前に、メッセージは宛先の複数のブローカーに保持されます。

  • 順序が重要な場合は、再試行を 0 に設定できます。また、本番環境では、最大インフライト接続数を 1 に設定して、バッチが途中で失敗した場合に、送信されるバッチが順不同でコミットされないようにします。このようにして、送信される各バッチは、次のバッチが送信されるまで再試行されます。max.block.ms が最大値に設定されておらず、プロデューサーバッファがいっぱいになると、（他の設定によっては）データが失われる可能性があります。これは、消費者をブロックし、バックプレッシャーすることができます。

  • 高スループット

    • buffer.memory を増やします。

    • バッチサイズを大きくします。

    • linger.ms を調整して、バッチがいっぱいになるようにします。これにより、圧縮率が向上し、ネットワーク帯域幅の使用率を削減して、クラスター上のストレージの使用量が少なくなります。これにより、保存期間が向上します。

    • CPU とメモリの使用状況をモニタリングします。

  • 高いコンシューマースループット

    • MirrorMaker プロセスあたりのスレッド/コンシューマーの数を増やす — num.streams。

    • 高可用性を実現するためにスレッドを増やす前に、最初にマシン間で MirrorMaker プロセスの数を増やします。

    • 最初に同じマシンでプロセスの数を増やし、次に別のマシン (同じグループ ID) で MirrorMaker プロセスの数を増やします。

    • スループットが非常に高いトピックを分離し、個別の MirrorMaker インスタンスを使用します。

  • 管理と構成

    • Chef AWS CloudFormation や Ansible などの および設定管理ツールを使用します。

    • Amazon EFS マウントを使用して、すべての Amazon EC2 インスタンスからすべての構成ファイルにアクセスできるようにします。

    • コンテナを使用すると、インスタンスの MirrorMakerスケーリングと管理が容易になります。

  • 通常、 でプロデューサーを飽和させるには複数のコンシューマーが必要です MirrorMaker。したがって、複数のコンシューマーを設定します。まず、高可用性を実現するために、異なるマシンにそれらを設定します。次に、各パーティションのコンシューマーを持つように個々のマシンをスケールアップし、コンシューマーをマシン間で均等に分散させます。

  • スループットの取り込みと配信を高くするには、受信バッファと送信バッファのデフォルトが低すぎる可能性があるため、受信バッファと送信バッファを調整します。パフォーマンスを最大化するには、ストリーム (num.streams) の総数 MirrorMaker が、送信先クラスターにコピーしようとしているすべてのトピックパーティションと一致することを確認してください。

MirrorMaker 2.* の利点

  • Apache Kafka Connect フレームワークとエコシステムを利用します。

  • 新しいトピックとパーティションを検出します。

  • クラスター間でトピック構成を自動的に同期します。

  • 「アクティブ/アクティブ」クラスターペアと、任意の数のアクティブクラスターをサポートします。

  • 複数のデータセンターやクラスターでの end-to-end レプリケーションレイテンシーなどの新しいメトリクスを提供します。

  • クラスター間でコンシューマーを移行するために必要なオフセットを放出し、オフセット変換用のツールを提供します。

  • 各 1.* プロセスの低レベルのプロデューサー/コンシューマープロパティと比較して、複数のクラスターとレプリケーションフローを MirrorMaker 1 か所で指定するための高レベルの設定ファイルをサポートします。