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

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

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

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

サーバー側の考慮事項

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

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

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

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

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

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

MSK プロビジョンド クラスター に適した標準ブローカーの数を決定し、コストを把握するには、 MSK サイジング設定および価格設定スプレッドシートを参照してください。このスプレッドシートは、MSK プロビジョンド クラスター のサイズ設定に関する見積もりと、Amazon MSK の関連コストを、同様の自己管理型 EC2 ベースの Apache Kafka クラスター と比較したものです。スプレッドシートの入力パラメータの詳細については、パラメータの説明にカーソルを合わせてください。このシートに記載されている見積もりは保守的なものであり、新しい MSK プロビジョンド クラスターの出発点となります。クラスターのパフォーマンス、サイズ、コストはユースケースによって異なるため、実際のテストで検証することが推奨されます。

基盤となるインフラストラクチャが Apache Kafka のパフォーマンスにどのように影響するかを理解するには、AWS ビッグデータブログの「Best practices for right-sizing your Apache Kafka clusters to optimize performance and cost」を参照してください。このブログ記事では、スループット、可用性、レイテンシーの要件を満たすようにクラスターのサイズを設定する方法について説明しています。また、スケールアップとスケールアウトの適切な選択時期といった疑問への回答や、本番環境クラスターのサイズを継続的に検証する方法に関するガイダンスも提供します。階層型ストレージベースのクラスターの詳細については、「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 コア数の半分に設定すると、新しいインスタンスサイズを最大限に活用できます。

次の表に、各インスタンスサイズの推奨設定を示します。

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

Kafka バージョン 2.8.0 以降を使用する MSK プロビジョンド クラスター に対して、Kafka AdminClient 2.8.0 未満のバージョンでトピックのパーティションを増やすか再割り当てするフラグ--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 がブローカーを置換する際に高可用性を維持できます。

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

Amazon MSK では、ブローカーの CPU 使用率 (CPU User + CPU System定義済み) を 60% 未満に維持することを強く推奨します。これにより、クラスターは、ブローカーの障害、パッチ適用、ローリングアップグレードなどの運用イベントを処理するのに十分な CPU ヘッドルームを保持できます。

Apache Kafka は、必要に応じてクラスター内のブローカー間で CPU 負荷を再分散できます。例えば、Amazon MSK がブローカーの障害を検出して復旧すると、パッチ適用などの自動メンテナンスが実行されます。同様に、ユーザーがブローカーのサイズ変更または、バージョンアップを要求した場合、Amazon MSK はローリングワークフローを開始し、ブローカーを 1 つずつオフラインにします。リードパーティションを持つブローカーがオフラインになると、Apache Kafka はパーティションのリーダーシップを再割り当てして、クラスター内の他のブローカーに作業を再配布します。このベストプラクティスに従うことで、これらの運用イベントに耐えられる十分な CPU ヘッドルームを確保できます。

Amazon CloudWatch metric mathを使用して複合メトリクス (CPU User + CPU System) を作成し、平均使用量が 60% を超えたときにトリガーするようにアラームを設定できます。トリガーされた場合、以下のいずれかのオプションを使用してクラスターのスケーリングを検討してください。

その他の推奨事項：

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

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

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

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

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

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

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

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

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

不正シャットダウンの後、ブローカーはログ復旧を実行するため、再起動に時間がかかることがあります。デフォルトでは、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 のドキュメントの「クラスターの拡張」を参照してください。