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

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

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

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

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

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

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

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

サーバー側の考慮事項

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

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 システム使用率という複合メトリクスを作成できます。複合メトリクスの平均 CPU 使用率が 60% に達したときにトリガーされるアラームを設定します。このアラームがトリガーされたら、以下のいずれかのオプションを使用してクラスターをスケーリングします。

  • オプション 1: 次に大きいサイズにブローカーサイズを更新します。クラスター内のブローカーサイズを更新すると、Amazon MSK はブローカーをローリング方式でオフラインにし、パーティションのリーダーシップを他のブローカーに一時的に再割り当てることに注意してください。

  • オプション 2: Expand ブローカーを追加して クラスター を拡張し、その後、パーティション再割り当てツールを使用して既存のパーティションを再割り当てしますkafka-reassign-partitions.sh。

その他の推奨事項

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

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

  • JMX スクレイプ間隔: Prometheus 機能でオープンモニタリングを有効にする場合、Prometheus ホスト設定(prometheus.yml)では 60 秒以上のスクレイプ間隔(scrape_interval: 60s)を使用することを推奨します。スクレイプ間隔を短くすると、クラスターの 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 のドキュメントの「クラスターの拡張」を参照してください。