翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
標準ブローカーのベストプラクティス
このトピックでは、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.4xlarge、 kafka.m5.8xlarge、 kafka.m5.12xlarge、 kafka.m5.16xlarge、 または kafka.m5.24xlarge |
4000 | 6000 |
kafka.m7g.large、または kafka.m7g.xlarge |
1,000 | 1500 |
kafka.m7g.2xlarge |
2000 | 3000 |
kafka.m7g.4xlarge、 kafka.m7g.8xlarge、 kafka.m7g.12xlarge、または kafka.m7g.16xlarge |
4000 | 6000 |
パーティション数が多く、スループットが低いユースケースで、すべてのパーティション間でトラフィックを送信していない場合は、クラスターがパーティション数が多いほど正常であることを確認するのに十分なテストとパフォーマンステストを実行している限り、ブローカーごとにより多くのパーティションをパックできます。ブローカーあたりのパーティション数が最大許容値を超え、クラスターが過負荷になった場合、次のオペレーションを実行できなくなります。
-
クラスター設定の更新
-
クラスターをより小さいブローカータイプに更新する
-
シー AWS Secrets Manager クレットを SASL/SCRAM 認証を持つクラスターに関連付ける
パーティションの数が多い CloudWatch と、Prometheus スクレイピングで Kafka メトリクスが欠落する可能性があります。
パーティション数の選択に関するガイダンスについては、「Apache Kafka Supports 200K Partitions Per Cluster
クラスターの適切なサイズ設定: クラスターあたりの標準ブローカーの数
MSK プロビジョニングされたクラスターに適したスタンダードブローカーの数を決定し、コストを理解するには、MSK「サイジングと料金
基盤となるインフラストラクチャが Apache Kafka のパフォーマンスにどのように影響するかを理解するには、 AWS 「 ビッグデータブログ」の「Apache Kafka クラスターのサイズを適切に設定してパフォーマンスとコストを最適化するためのベストプラクティス
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 の不一致の問題を回避 AdminClient するために最新の Kafka を使用する
Kafka バージョン 2.8.0 より前のバージョンと フラグを使用して Kafka AdminClient バージョン 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 フラグを使用できます。
高可用性クラスターの構築
MSK プロビジョニングされたクラスターが更新中 (ブローカーサイズや Apache Kafka バージョンを更新する場合など) または Amazon MSKがブローカーを置き換えるときに高可用性になるように、次の推奨事項を使用します。
-
3-AZ クラスターを設定します。
-
レプリケーション係数 (RF) が 3 以上であることを確認します。RF が 1 の場合、ローリング更新中にパーティションがオフラインになる可能性があり、RF が 2 の場合、データが失われる可能性があることに注意してください。
-
最小同期レプリカ (最小ISR) を最大 RF - 1 に設定します。RF と等しい最小値ISRは、ローリング更新中にクラスターへの生成を妨げる可能性があります。2 分のISR 1 では、1 つのレプリカがオフラインのときに 3 方向レプリケートされたトピックを使用できます。
CPU 使用状況のモニタリング
Amazon では、ブローカー ( と定義CPU User + CPU System) の合計CPU使用率を 60% 未満に維持することをMSK強くお勧めします。クラスターの合計の 40% 以上がCPU使用可能な場合、Apache Kafka は必要に応じてクラスター内のブローカー間でCPU負荷を再分散できます。これが必要な場合の一例として、Amazon がブローカーの障害MSKを検出して復旧する場合が挙げられます。この場合、Amazon はパッチ適用などの自動メンテナンスMSKを実行します。もう 1 つの例は、ユーザーがブローカーのサイズ変更またはバージョンアップグレードをリクエストする場合です。これら 2 つのケースでは、Amazon は一度に 1 つのブローカーをオフラインにするローリングワークフローをMSKデプロイします。リードパーティションを持つブローカーがオフラインになると、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 では、前の 2 つのオプションが不可能な場合にのみ、このオプションを使用することMSKを推奨しています。
その他の推奨事項：
-
ロードディストリビューションのプロキシとしてブローカーあたりの合計CPU使用率をモニタリングします。ブローカーのCPU使用率が一貫して一定でない場合、負荷がクラスター内に均等に分散されていない可能性があります。Cruise Control を使用して、パーティション割り当てによる負荷分散を継続的に管理することをお勧めします。
-
生成および消費レイテンシーをモニタリングします。レイテンシーの生成と消費は、CPU使用率に応じて直線的に増加する可能性があります。
-
JMX スクレイプ間隔: Prometheus 機能でオープンモニタリングを有効にする場合は、Prometheus ホスト設定 (prometheus.yml) に 60 秒以上のスクレイプ間隔 (scrape_interval: 60s) を使用することをお勧めします。スクレイプ間隔を短くすると、クラスターのCPU使用率が高くなる可能性があります。
ディスク容量のモニタリング
メッセージのディスク容量が不足しないようにするには、 KafkaDataLogsDiskUsedメトリクスを監視する CloudWatch アラームを作成します。このメトリクスの値が 85％ に達するか超える場合は、次の 1 つ以上のアクションを実行します。
-
Amazon MSKクラスターの自動スケーリング を使用します。「標準ブローカーの手動スケーリング」の説明に従って、ブローカーストレージを手動で増やすこともできます。
-
メッセージの保持期間またはログサイズを減らします。これを行う方法については、データ保持パラメータの調整 を参照してください。
-
未使用のトピックを削除します。
アラームをセットアップして使用する方法については、「Amazon CloudWatch アラームの使用」を参照してください。Amazon MSKメトリクスの完全なリストについては、「」を参照してくださいAmazon MSK Provisioned クラスターのモニタリング。
データ保持パラメータの調整
メッセージを消費しても、ログからは削除されません。定期的にディスク容量を解放するには、保持期間（メッセージをログに保持する期間）を明示的に指定できます。保存ログのサイズを指定することもできます。保持期間または保持ログのサイズのいずれかに達すると、Apache Kafka は、ログから非アクティブなセグメントの削除を開始します。
クラスターレベルで保持ポリシーを指定するには、log.retention.hours、log.retention.minutes、log.retention.ms、または log.retention.bytes のいずれかまたは複数のパラメータを設定します。詳細については、「カスタム Amazon MSK設定」を参照してください。
トピックレベルで保持パラメータを指定することもできます。
-
トピックごとに保持期間を指定するには、次のコマンドを使用します。
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.ms=DesiredRetentionTimePeriod -
トピックごとに保持ログのサイズを指定するには、次のコマンドを使用します。
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--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。例えば、新しいブローカーを追加してクラスターを拡張したり、ブローカーの削除のためにパーティションを移動したりすると、新しいブローカーにパーティションを再割り当てすることで、そのクラスターを再分散できるようになります。MSK プロビジョニングされたクラスターにブローカーを追加する方法については、「」を参照してくださいAmazon MSKクラスター内のブローカーの数を拡張する。MSK プロビジョニングされたクラスターからブローカーを削除する方法については、「」を参照してくださいAmazon MSKクラスターからブローカーを削除する。パーティション再割り当てツールの詳細については、Apache Kafka のドキュメントの「クラスターの拡張
