Express ブローカーのベストプラクティス - Amazon Managed Streaming for Apache Kafka
クライアント側の考慮事項サーバー側の考慮事項

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

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

このトピックでは、Express ブローカーを使用する際に従うべきいくつかのベストプラクティスの概要を説明します。Express ブローカーには、高可用性と耐久性のために事前設定されています。デフォルトでは、データは 3 つのアベイラビリティーゾーンに分散され、レプリケーションは常に 3 に設定され、同期内の最小レプリカは常に 2 に設定されます。ただし、クラスターの信頼性とパフォーマンスを最適化するために考慮すべき要素はいくつかあります。

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

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

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

  • パフォーマンステストを実行して、ピーク負荷時にブローカーを再起動しても、クライアント設定でパフォーマンス目標を達成できることを確認します。クラスター内のブローカーは、MSK コンソールまたは MSK APIs を使用して再起動できます。

サーバー側の考慮事項

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

Express ベースのクラスターのブローカー数の選択は簡単です。各 Express ブローカーには、入出力用に定義されたスループット容量が付属しています。このスループットキャパシティをクラスターのサイズ設定の主な手段として使用する必要があります (次に、以下で説明するパーティションや接続数などの他の要因を考慮してください）。

たとえば、ストリーミングアプリケーションに 45 MBps のデータ入力 (書き込み) と 90 MBps のデータ出力 (読み取り) 容量が必要な場合は、スループットのニーズを満たすために 3 つの express.m7g.large ブローカーを使用できます。各 express.m7g.large ブローカーは、15 MBps の進入と 30 MBps の進入を処理します。Express ブローカーのサイズごとの推奨スループット制限については、次の表を参照してください。スループットが推奨制限を超えると、パフォーマンスが低下する可能性があるため、トラフィックを減らすか、クラスターをスケールする必要があります。スループットが推奨制限を超え、ブローカーごとのクォータに達すると、MSK はクライアントトラフィックをスロットリングして、それ以上の過負荷を防ぎます。

MSK サイジングと料金表のスプレッドシートを使用して、複数のシナリオを評価し、パーティション数などの他の要因を検討することもできます。

ブローカーあたりの推奨最大スループット
インスタンスサイズ イングレス (MBps) 出力 (MBps)

express.m7g.large

 15.6 31.2

express.m7g.xlarge

 31.2 62.5

express.m7g.2xlarge

 62.5 125.0

express.m7g.4xlarge

 124.9 249.8

express.m7g.8xlarge

 250.0 500.0

express.m7g.12xlarge

 375.0 750.0

express.m7g.16xlarge

 500.0 1000.0

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

ブローカー (CPU ユーザー + CPU システムとして定義) の合計 CPU 使用率を 60% 以下に維持することをお勧めします。クラスターの合計 CPU の少なくとも 40% が利用可能である場合、Apache Kafka は必要に応じてクラスター内のブローカー間で CPU 負荷を再分散できます。これは、計画的なイベントまたは計画外のイベントが原因で必要になる場合があります。計画されたイベントの例は、MSK がクラスター内のブローカーを一度に 1 つずつ再起動して更新するクラスターバージョンアップグレードです。予期しないイベントの例としては、ブローカーのハードウェア障害、または最悪の場合は AZ 内のすべてのブローカーが影響を受ける AZ 障害などがあります。パーティションリードレプリカを持つブローカーがオフラインになると、Apache Kafka はパーティションリーダーシップを再割り当てして、クラスター内の他のブローカーに作業を再配布します。このベストプラクティスに従うことで、このような運用イベントを許容するのに十分な CPU ヘッドルームをクラスター内に確保できます。

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

その他の推奨事項

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

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

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

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

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

  • クラスター設定の更新

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

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

多数のパーティションでクラスターをオーバーロードすると、CloudWatch および Prometheus スクレイピングで Kafka メトリクスが失われる可能性もあります。

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

各 Express ブローカーの推奨パーティション数 (リーダーレプリカとフォロワーレプリカを含む) については、「」を参照してくださいExpress ブローカーパーティションクォータ。推奨される数のパーティションは強制されず、プロビジョニングされたすべてのトピックパーティションにトラフィックを送信するシナリオのベストプラクティスです。

接続数をモニタリングする

ブローカーへのクライアント接続は、メモリや CPU などのシステムリソースを消費します。認証メカニズムに応じて、 をモニタリングして、該当する制限の範囲内にあることを確認する必要があります。接続に失敗した場合の再試行を処理するには、クライアント側で reconnect.backoff.ms 設定パラメータを設定できます。たとえば、クライアントが 1 秒後に接続を再試行する場合は、 reconnect.backoff.ms を に設定します1000。再試行の設定の詳細については、「Apache Kafka ドキュメント」を参照してください。

ディメンション クォータ

ブローカーあたりの最大 TCP 接続数 (IAM アクセスコントロール）

 3000

ブローカーあたりの最大 TCP 接続数 (IAM)

 100/秒

ブローカーあたりの最大 TCP 接続数 (非 IAM)

 MSK は、IAM 以外の認証の接続制限を適用しません。ただし、CPU やメモリの使用状況などの他のメトリクスをモニタリングして、過剰な接続が原因でクラスターが過負荷にならないようにする必要があります。

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

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