Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

標準ブローカーのベストプラクティス

フォーカスモード
標準ブローカーのベストプラクティス - Amazon Managed Streaming for Apache Kafka

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

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

このトピックでは、Amazon MSK を使用する際に従うべきいくつかのベストプラクティスの概要を説明します。Amazon MSK Replicator のベストプラクティスについては、「MSK レプリケーターを使用するためのベストプラクティス」を参照してください。

クライアント側の考慮事項

アプリケーションの可用性とパフォーマンスは、サーバー側の設定だけでなく、クライアントの設定にも依存します。

  • 高可用性を実現するためにクライアントを設定します。Apache Kafka のような分散システムで、信頼性と耐障害性に優れたメッセージングインフラストラクチャを維持するためには、高可用性の確保が不可欠です。ブローカーは、アップグレード、パッチ適用、ハードウェア障害、ネットワークの問題など、計画されたイベントと計画外のイベントの両方でオフラインになります。Kafka クラスターには、オフラインブローカーに対する寛容性があり、このため Kafka クライアントでは、ブローカーのフェイルオーバーを円滑に処理する必要があります。の詳細については、「」を参照してくださいApache Kafka クライアントのベストプラクティス

  • クライアント接続文字列に、各アベイラビリティーゾーンのブローカーが少なくとも 1 つ含まれていることを確認してください。クライアントの接続文字列に複数のブローカーが含まれていると、特定のブローカーが更新のためにオフラインになった場合にフェイルオーバーができるようになります。複数のブローカーで接続文字列を取得する方法については、「Amazon MSK クラスターのブートストラップブローカーを取得する」を参照してください。

  • パフォーマンステストを実行して、クライアント設定でパフォーマンス目標を達成できることを確認します。

サーバー側の考慮事項

クラスターの適切なサイズ設定: 標準ブローカーあたりのパーティション数

次の表は、標準ブローカーあたりの推奨パーティション数 (リーダーレプリカとフォロワーレプリカを含む) を示しています。推奨されるパーティション数は強制されないため、プロビジョニングされたすべてのトピックパーティションにトラフィックを送信するシナリオのベストプラクティスです。

ブローカーサイズ 推奨されるブローカーあたりのパーティション数 (リーダーとフォロワーのレプリカを含む) 更新オペレーションをサポートするパーティションの最大数
kafka.t3.small 300 300
kafka.m5.large、または kafka.m5.xlarge 1,000 1500
kafka.m5.2xlarge 2000 3000
kafka.m5.4xlargekafka.m5.8xlargekafka.m5.12xlargekafka.m5.16xlarge、 または kafka.m5.24xlarge 4000 6000
kafka.m7g.large、または kafka.m7g.xlarge 1,000 1500
kafka.m7g.2xlarge 2000 3000
kafka.m7g.4xlargekafka.m7g.8xlargekafka.m7g.12xlarge、または kafka.m7g.16xlarge 4000 6000

パーティション数が多いが、すべてのパーティション間でトラフィックを送信していない場合、高いパーティション数でクラスターが正常であることを検証するのに十分なテストとパフォーマンステストを実行している限り、ブローカーごとにより多くのパーティションをパックできます。ブローカーあたりのパーティション数が最大許容値を超え、クラスターが過負荷になった場合、次のオペレーションを実行できなくなります。

  • クラスター設定の更新

  • クラスターをより小さいブローカータイプに更新する

  • AWS Secrets Manager シークレットを SASL/SCRAM 認証を持つクラスターに関連付ける

パーティションの数が多くなると、CloudWatch および Prometheus スクレイピングで Kafka メトリクスの欠落を起こすことがあります。

パーティション数の選択に関するガイダンスについては、「Apache Kafka Supports 200K Partitions Per Cluster」を参照してください。また、独自のテストを実行して、ブローカーに適したサイズを決定することをお勧めします。さまざまなブローカータイプの詳細な情報については、「Amazon MSK ブローカータイプ」を参照してください。

クラスターの適切なサイズ設定: クラスターあたりの標準ブローカーの数

MSK プロビジョンドクラスターに適した数の標準ブローカーを決定し、コストを理解するには、「MSK サイジングと料金表」スプレッドシートを参照してください。このスプレッドシートは、同様のセルフマネージド型の EC2-based Apache Kafka クラスターと比較した、MSK プロビジョンドクラスターおよび Amazon MSK の関連コストのサイジングの見積もりを提供します。スプレッドシートの入力パラメータの詳細については、パラメータの説明にカーソルを合わせてください。このシートで提供される見積もりは保守的で、新しい MSK プロビジョニングクラスターの開始点となります。クラスターのパフォーマンス、サイズ、コストはユースケースによって異なるため、実際のテストで検証することが推奨されます。

基盤となるインフラストラクチャが Apache Kafka のパフォーマンスに与える影響を理解するには、 AWS ビッグデータブログの「パフォーマンスとコストを最適化するために Apache Kafka クラスターのサイズを適切に設定するためのベストプラクティス」を参照してください。このブログ記事では、スループット、可用性、レイテンシーの要件を満たすようにクラスターのサイズを設定する方法について説明しています。また、スケールアップとスケールアウトのタイミングなどの質問に対する回答や、本番クラスターのサイズを継続的に検証する方法に関するガイダンスも提供します。階層型ストレージベースのクラスターの詳細については、「Amazon MSK 階層型ストレージを使用して本稼働ワークロードを実行するためのベストプラクティス」を参照してください。

m5.4xl、m7g.4xl、またはそれ以上のインスタンスでクラスタースループットを最適化する

m5.4xl、m7g.4xl、またはそれ以上のインスタンスを使用する場合、num.io.threads および num.network.threads の設定を調整することで、MSK プロビジョンドクラスターのスループットを最適化できます。

Num.io.threads は、スタンダードブローカーがリクエストの処理に使用するスレッドの数です。スレッド数の追加 (最大値はインスタンスサイズとしてサポートされている CPU コアの数) をすることで、クラスターのスループットを向上させることができます。

Num.network.threads は、すべての受信リクエストを受信し、レスポンスを返すために標準ブローカーが使用するスレッドの数です。ネットワークスレッドは、着信リクエストをリクエストキューに入れ、io.threads で処理します。num.network.threads をインスタンスサイズとしてサポートされている CPU コア数の半分に設定すると、新しいインスタンスサイズを最大限に活用できます。

重要

num.network.threads を増やす場合は、先に num.io.threads を増やす必要があります。そうしないと、キューの飽和による輻輳が発生する可能性があります。

推奨される設定
インスタンスサイズ num.io.threads の推奨値 num.network.threads の推奨値

m5.4xl

16

8

m5.8xl

32

16

m5.12xl

48

24

m5.16xl

64

32

m5.24xl

96

48

m7g.4xlarge

16

8

m7g.8xlarge

32

16

m7g.12xlarge

48

24

m7g.16xlarge

64

32

トピック ID の不一致の問題を回避するための最新の Kafka AdminClient の使用

Kafka AdminClient バージョン 2.8.0 より前のバージョンと フラグを使用して Kafka バージョン 2.8.0 以降を使用して MSK プロビジョンドクラスターのトピックパーティション--zookeeperを増加または再割り当てすると、トピックの ID が失われます (エラー: はパーティションのトピック ID と一致しません)。--zookeeper フラグは Kafka 2.5 で非推奨になり、Kafka 3.0 以降では削除されているので注意してください。「Upgrading to 2.5.0 from any version 0.8.x through 2.4.x」を参照してください。

トピック ID の不一致を回避するには、Kafka 管理オペレーションに Kafka クライアントバージョン 2.8.0 以降を使用してください。または、2.5 以降のクライアントでは、--zookeeper フラグの代わりに --bootstrap-servers フラグを使用できます。

高可用性クラスターの構築

次の推奨事項を使用して、更新中 (ブローカーサイズや Apache Kafka バージョンを更新する場合など) または Amazon MSK がブローカーを置き換えるときに MSK プロビジョニングされたクラスターを高可用性にすることができます。

  • 3-AZ クラスターを設定します。

  • レプリケーション係数 (RF) が 3 以上であることを確認します。RF が 1 の場合、ローリング更新中にパーティションがオフラインになる可能性があり、RF が 2 の場合、データが失われる可能性があることに注意してください。

  • 最小同期レプリカ (minISR) を最大で RF - 1 に設定します。RF と同等の minISR は、ローリング更新中のクラスターへの生成を防止できます。minISR が 2 の場合、レプリカが 1 つオフラインになると、3 方向のレプリケートされたトピックを使用できるようになります。

CPU 使用率をモニタリングする

Amazon MSK では、ブローカーの合計 CPU 使用率 (CPU User + CPU System として定義) を 60% 未満に維持することを強く推奨しています。クラスターの合計 CPU の少なくとも 40% が利用可能である場合、Apache Kafka は必要に応じてクラスター内のブローカー間で CPU 負荷を再分散できます。これが必要な場合の1つの例は、Amazon MSK がブローカーの障害を検出して回復する場合です。この場合、Amazon MSK はパッチ適用などの自動メンテナンスを実行します。もう 1 つの例は、ユーザーがブローカーサイズの変更またはバージョンのアップグレードをリクエストする場合です。この 2 つのケースでは、Amazon MSK は一度に 1 つのブローカーをオフラインにするローリングワークフローをデプロイします。リードパーティションを持つブローカーがオフラインになると、Apache Kafka はパーティションのリーダーシップを再割り当てして、クラスター内の他のブローカーに作業を再配布します。このベストプラクティスに従うことで、このような運用イベントに耐えるのに十分な CPU ヘッドルームをクラスターに確保できます。

Amazon CloudWatch Metric Math を使用して、複合メトリクス (CPU User + CPU System) を作成できます。複合メトリクスの平均 CPU 使用率が 60% に達したときにトリガーされるアラームを設定します。このアラームがトリガーされたら、以下のいずれかのオプションを使用してクラスターをスケーリングします。

  • オプション 1 (推奨): 次に大きいサイズにブローカーサイズを更新します。例えば、現在のサイズが kafka.m5.large の場合、kafka.m5.xlarge を使用するようにクラスターを更新します。クラスター内のブローカーサイズを更新すると、Amazon MSK はブローカーをローリング方式でオフラインにし、パーティションのリーダーシップを他のブローカーに一時的に再割り当てることに注意してください。サイズの更新には、通常、ブローカーごとに 10 〜 15 分かかります。

  • オプション 2: ラウンドロビン書き込みを使用するプロデューサーからすべてのメッセージを取り込んでいる (つまり、メッセージにキーが設定されておらず、コンシューマーにとって順序は重要ではない) トピックがある場合は、ブローカーを追加してクラスターを拡張します。また、スループットが最も高い既存のトピックにパーティションを追加します。次に、kafka-topics.sh --describe を使用して、新しく追加されたパーティションが新しいブローカーに割り当てられていることを確認します。前のオプションと比較したこのオプションの主な利点は、リソースとコストをよりきめ細かく管理できることです。さらに、CPU ロードが 60% を大幅に超える場合は、このオプションを使用できます。これは、この形式のスケーリングでは通常、既存のブローカーのロードが増加しないためです。

  • オプション 3: ブローカーを追加して MSK プロビジョンドクラスターを拡張し、 という名前のパーティション再割り当てツールを使用して既存のパーティションを再割り当てしますkafka-reassign-partitions.sh。ただし、このオプションを使用する場合、パーティションが再割り当てされた後、クラスターはブローカーからブローカーにデータを複製するためにリソースを費やす必要があります。前の 2 つのオプションと比較すると、これにより、最初はクラスターのロードが大幅に増加する可能性があります。その結果、レプリケーションによって追加の CPU ロードとネットワーク トラフィックが発生するため、CPU 使用率が 70% を超える場合、Amazon MSK はこのオプションの使用を推奨しません。Amazon MSK は、前の2つのオプションが実行可能でない場合にのみ、このオプションを使用することをお勧めします。

その他の推奨事項:

  • ロード ディストリビューションのプロキシとして、ブローカーごとの合計 CPU 使用率をモニタリングします。ブローカーの CPU 使用率が一貫して不均一である場合は、ロードがクラスター内で均等に配信されていないことを示している可能性があります。Cruise Control を使用して、パーティション割り当てによる負荷分散を継続的に管理することをお勧めします。

  • 生成および消費レイテンシーをモニタリングします。レイテンシーの生成と消費は、CPU 使用率に比例して増加する可能性があります。

  • JMX スクレイプ間隔: Prometheus 機能を使用してオープンモニタリングを有効にする場合は、Prometheus ホスト設定 (prometheus.yml) で 60 秒以上のスクレイプ間隔 (scrape_interval: 60s) を使用することが推奨されます。スクレイプ間隔を短くすると、クラスターの CPU 使用率が高くなる可能性があります。

ディスク容量のモニタリング

メッセージ用のディスクスペースが不足しないようにするには、KafkaDataLogsDiskUsed メトリクスを監視する CloudWatch アラームを作成します。このメトリクスの値が 85% に達するか超える場合は、次の 1 つ以上のアクションを実行します。

アラームの設定と使用方法については、「Amazon CloudWatch アラームの使用」を参照してください。Amazon MSK メトリクスの完全なリストについては「Amazon MSK プロビジョンドクラスターのモニタリング」を参照してください。

データ保持パラメータの調整

メッセージを消費しても、ログからは削除されません。定期的にディスク容量を解放するには、保持期間(メッセージをログに保持する期間)を明示的に指定できます。保存ログのサイズを指定することもできます。保持期間または保持ログのサイズのいずれかに達すると、Apache Kafka は、ログから非アクティブなセグメントの削除を開始します。

クラスターレベルで保持ポリシーを指定するには、log.retention.hourslog.retention.minuteslog.retention.ms、または log.retention.bytes のいずれかまたは複数のパラメータを設定します。詳細については、「カスタム Amazon MSK 設定」を参照してください。

トピックレベルで保持パラメータを指定することもできます。

  • トピックごとに保持期間を指定するには、次のコマンドを使用します。

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod
  • トピックごとに保持ログのサイズを指定するには、次のコマンドを使用します。

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

トピックレベルで指定する保持パラメータは、クラスターレベルのパラメータよりも優先されます。

不正シャットダウン後のログ復旧の高速化

不正シャットダウンの後、ブローカーはログ復旧を実行するため、再起動に時間がかかることがあります。デフォルトでは、Kafka はログディレクトリごとに 1 つのスレッドのみを使用してこの復旧を実行します。例えば、数千のパーティションがある場合、ログ復旧が完了するまでに数時間かかる可能性があります。ログ復旧を高速化するには、設定プロパティ num.recovery.threads.per.data.dir を使用してスレッド数を増やすことが推奨されます。これを CPU コアの数に設定できます。

Apache Kafka メモリのモニタリング

Apache Kafka が使用するメモリをモニタリングすることが推奨されます。そうしないと、クラスターを使用できなくなる可能性があります。

Apache Kafka が使用するメモリ量を判別するために、HeapMemoryAfterGC メトリクスをモニタリングできます。HeapMemoryAfterGC は、ガベージコレクション後に使用されている合計ヒープメモリの割合 (%) です。HeapMemoryAfterGC が 60% を上回った場合にアクションを実行する CloudWatch アラームを作成することが推奨されます。

メモリ使用量を減らすために実行できるステップはさまざまです。これらは Apache Kafka の設定方法によって異なります。例えば、トランザクションメッセージ配信を使用する場合、Apache Kafka 設定の transactional.id.expiration.ms 値を 604800000 ミリ秒から 86400000 ミリ秒に (7 日から 1 日に) 減らすことができます。これにより、各トランザクションのメモリフットプリントが減ります。

MSK 以外のブローカーを追加しない

ZooKeeper ベースの MSK プロビジョンドクラスターの場合、Apache ZooKeeper コマンドを使用してブローカーを追加すると、これらのブローカーは MSK プロビジョンドクラスターに追加されず、Apache ZooKeeper にはクラスターに関する誤った情報が含まれます。これにより、データが失われる可能性があります。サポートされている MSK プロビジョンドクラスターオペレーションについては、「」を参照してくださいAmazon MSK の主な機能と概念

転送中の暗号化を有効にする

転送中の暗号化とその有効化方法については、「転送中の Amazon MSK 暗号化」を参照してください。

パーティションの再割り当て

パーティションを同じ MSK プロビジョンドクラスター上の異なるブローカーに移動するには、 という名前のパーティション再割り当てツールを使用できますkafka-reassign-partitions.sh。安全なオペレーションのために、1 回のkafka-reassign-partitions呼び出しで 10 個を超えるパーティションを再割り当てしないことをお勧めします。例えば、新しいブローカーを追加してクラスターを拡張したり、ブローカーの削除のためにパーティションを移動したりすると、新しいブローカーにパーティションを再割り当てすることで、そのクラスターを再分散できるようになります。MSK プロビジョンドクラスターにブローカーを追加する方法については、「」を参照してくださいAmazon MSK クラスター内のブローカーの数を拡張する。MSK プロビジョンドクラスターからブローカーを削除する方法については、「」を参照してくださいAmazon MSK クラスターからブローカーを削除する。パーティション再割り当てツールの詳細については、Apache Kafka のドキュメントの「クラスターの拡張」を参照してください。

このページの内容

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.