翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 標準 ブローカーのベストプラクティス
このトピックでは、Amazon MSK を使用する際に従うべきいくつかのベストプラクティスの概要を説明します。Amazon MSK Replicator のベストプラクティスについては、「[MSK レプリケーターの使用に関するベストプラクティス](msk-replicator-best-practices.md)」を参照してください。
## クライアント側の考慮事項
アプリケーションの可用性とパフォーマンスは、サーバー側の設定だけでなく、クライアントの設定にも依存します。
+ クライアントを高可用性に対応するように設定してください。Apache Kafka のような分散システムで、信頼性と耐障害性に優れたメッセージングインフラストラクチャを維持するためには、高可用性の確保が不可欠です。ブローカーは、計画的なイベントと計画外のイベントの両方でオフラインになります。例としては、アップグレード、パッチ適用、ハードウェア障害、ネットワーク問題などが挙げられます。Kafka クラスターには、オフラインブローカーに対する寛容性があり、このため Kafka クライアントでは、ブローカーのフェイルオーバーを円滑に処理する必要があります。詳細については、[Apache Kafka クライアントのためのベストプラクティス](bestpractices-kafka-client.md) を参照してください。
+ クライアント接続文字列に、各アベイラビリティーゾーンのブローカーが少なくとも 1 つ含まれていることを確認してください。クライアントの接続文字列に複数のブローカーが含まれていると、特定のブローカーが更新のためにオフラインになった場合にフェイルオーバーができるようになります。複数のブローカーで接続文字列を取得する方法については、「[Amazon MSK クラスターのブートストラップブローカーを取得する](msk-get-bootstrap-brokers.md)」を参照してください。
+ パフォーマンステストを実行して、クライアント設定でパフォーマンス目標を達成できることを確認します。
## サーバー側の考慮事項
### クラスターの適切なサイズ設定: 標準ブローカーあたりのパーティション数
以下の表は、Standard ブローカーごとに推奨されるパーティション数 (リーダーおよびフォロワーレプリカを含む) を示しています。推奨される数のパーティションは強制されず、プロビジョニングされたすべてのトピックパーティションにトラフィックを送信するシナリオのベストプラクティスです。
| ブローカーサイズ | 推奨されるブローカーあたりのパーティション数 (リーダーとフォロワーのレプリカを含む) | 更新オペレーションをサポートするパーティションの最大数 |
| --- | --- | --- |
| 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 |
パーティション数が高く、スループットが低いユースケースで、すべてのパーティションにトラフィックを送信していない場合は、クラスターがパーティション数が多い状態でも正常であることを検証するために十分なテストとパフォーマンステストを実行している限り、ブローカーごとにより多くのパーティションをパックできます。ブローカーあたりのパーティション数が最大許容値を超え、クラスターが過負荷状態になると、以下の操作を実行できなくなります:
+ クラスター設定の更新
+ クラスターをより小さいブローカータイプに更新する
+ SASL/SCRAM 認証を持つクラスターに AWS Secrets Manager シークレットを関連付ける
パーティションの数が多くなると、CloudWatch および Prometheus スクレイピングで Kafka メトリクスの欠落を起こすことがあります。
パーティション数の選択に関するガイダンスについては、「[Apache Kafka Supports 200K Partitions Per Cluster](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions)」を参照してください。また、独自のテストを実行して、ブローカーに適したサイズを決定することをお勧めします。さまざまなブローカータイプの詳細な情報については、「[Amazon MSK ブローカー タイプ](broker-instance-types.md)」を参照してください。
### クラスターの適正サイズ設定: クラスターあたりの標準ブローカー数
MSK プロビジョンド クラスター に適した標準ブローカーの数を決定し、コストを把握するには、[ MSK サイジング設定および価格設定](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK)スプレッドシートを参照してください。このスプレッドシートは、MSK プロビジョンド クラスター のサイズ設定に関する見積もりと、Amazon MSK の関連コストを、同様の自己管理型 EC2 ベースの Apache Kafka クラスター と比較したものです。スプレッドシートの入力パラメータの詳細については、パラメータの説明にカーソルを合わせてください。このシートに記載されている見積もりは保守的なものであり、新しい MSK プロビジョンド クラスターの出発点となります。クラスターのパフォーマンス、サイズ、コストはユースケースによって異なるため、実際のテストで検証することが推奨されます。
基盤となるインフラストラクチャが Apache Kafka のパフォーマンスにどのように影響するかを理解するには、 AWS ビッグデータブログの「[Apache Kafka クラスターのサイズを適正化してパフォーマンスとコストを最適化するためのベストプラクティス](https://aws.amazon.com/blogs/big-data/best-practices-for-right-sizing-your-apache-kafka-clusters-to-optimize-performance-and-cost/)」を参照してください。このブログ記事では、スループット、可用性、レイテンシーの要件を満たすようにクラスターのサイズを設定する方法について説明しています。また、スケール*アップ*とスケール*アウト*の適切な選択時期といった疑問への回答や、本番環境クラスターのサイズを継続的に検証する方法に関するガイダンスも提供します。階層型ストレージベースのクラスターの詳細については、[「Amazon MSK 階層型ストレージを使用して本稼働ワークロードを実行するためのベストプラクティス](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/)」を参照してください。
### 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 バージョン 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](https://kafka.apache.org/documentation.html#upgrade_2_5_0)」を参照してください。
トピック ID の不一致を回避するには、Kafka 管理オペレーションに Kafka クライアントバージョン 2.8.0 以降を使用してください。または、2.5 以降のクライアントでは、`--zookeeper` フラグの代わりに `--bootstrap-servers` フラグを使用できます。
### 高可用性クラスターの構築
以下の推奨事項に従うことで、MSK プロビジョニング済みクラスターが更新時 (例:ブローカーサイズや Apache Kafka バージョンの更新時)や Amazon 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 ヘッドルームを保持できます。
Apache Kafka は、必要に応じてクラスター内のブローカー間で CPU 負荷を再分散できます。例えば、Amazon MSK がブローカーの障害を検出して復旧すると、パッチ適用などの自動メンテナンスが実行されます。同様に、ユーザーがブローカーのサイズ変更または、バージョンアップを要求した場合、Amazon MSK はローリングワークフローを開始し、ブローカーを 1 つずつオフラインにします。リードパーティションを持つブローカーがオフラインになると、Apache Kafka はパーティションのリーダーシップを再割り当てして、クラスター内の他のブローカーに作業を再配布します。このベストプラクティスに従うことで、これらの運用イベントに耐えられる十分な CPU ヘッドルームを確保できます。
**注記**
CPU 使用率をモニタリングするときは、合計 CPU 使用率には `CPU User` および `CPU System` 以外の要素も含まれていることに注意してください。`iowait`、`irq`、`softirq` および `steal` などの他のカテゴリも、全体的な CPU アクティビティに影響します。したがって、CPU アイドル *は必ずしも等しくない* と `100% - CPU User - CPU System`なるわけではありません。
[Amazon CloudWatch metric math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)を使用して複合メトリクス (`CPU User + CPU System`) を作成し、平均使用量が 60% を超えたときにトリガーするようにアラームを設定できます。トリガーされた場合、以下のいずれかのオプションを使用してクラスターのスケーリングを検討してください。
+ オプション 1 (推奨): 次に大きいサイズに[ブローカーサイズを更新](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-type.html)します。例えば、現在のサイズが `kafka.m5.large` の場合、`kafka.m5.xlarge` を使用するようにクラスターを更新します。クラスター内のブローカーサイズを更新すると、Amazon MSK はブローカーをローリング方式でオフラインにし、パーティションのリーダーシップを他のブローカーに一時的に再割り当てることに注意してください。サイズの更新には、通常、ブローカーごとに 10 〜 15 分かかります。
+ オプション 2: ラウンドロビン書き込みを使用するプロデューサーからすべてのメッセージを取り込んでいる (つまり、メッセージにキーが設定されておらず、コンシューマーにとって順序は重要ではない) トピックがある場合は、ブローカーを追加して[クラスターを拡張](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-count.html)します。また、スループットが最も高い既存のトピックにパーティションを追加します。次に、`kafka-topics.sh --describe` を使用して、新しく追加されたパーティションが新しいブローカーに割り当てられていることを確認します。前のオプションと比較したこのオプションの主な利点は、リソースとコストをよりきめ細かく管理できることです。さらに、CPU ロードが 60％ を大幅に超える場合は、このオプションを使用できます。これは、この形式のスケーリングでは通常、既存のブローカーのロードが増加しないためです。
+ オプション 3: ブローカーを追加して MSK プロビジョンドクラスターを拡張し、その後、`kafka-reassign-partitions.sh`という名前のパーティション再割り当てツールを使用して既存のパーティションを再割り当てします。ただし、このオプションを使用する場合、パーティションが再割り当てされた後、クラスターはブローカーからブローカーにデータを複製するためにリソースを費やす必要があります。前の 2 つのオプションと比較すると、これにより、最初はクラスターのロードが大幅に増加する可能性があります。その結果、レプリケーションによって追加の CPU ロードとネットワーク トラフィックが発生するため、CPU 使用率が 70％ を超える場合、Amazon MSK はこのオプションの使用を推奨しません。Amazon MSK は、前の2つのオプションが実行可能でない場合にのみ、このオプションを使用することをお勧めします。
その他の推奨事項：
+ ロード ディストリビューションのプロキシとして、ブローカーごとの合計 CPU 使用率をモニタリングします。ブローカーの CPU 使用率が一貫して不均一である場合は、ロードがクラスター内で均等に配信されていないことを示している可能性があります。パーティション割り当てによる負荷配信を継続的に管理するには、[クルーズコントロール](https://docs.aws.amazon.com//msk/latest/developerguide/cruise-control.html)の使用をお勧めします。
+ 生成および消費レイテンシーをモニタリングします。レイテンシーの生成と消費は、CPU 使用率に比例して増加する可能性があります。
+ **JMX スクレイプ間隔**: [Prometheus 機能](https://docs.aws.amazon.com/msk/latest/developerguide/open-monitoring.html)を使用してオープンモニタリングを有効にする場合は、Prometheus ホスト設定 (prometheus.yml) で 60 秒以上のスクレイプ間隔 (scrape\$1interval: 60s) を使用することが推奨されます。スクレイプ間隔を短くすると、クラスターの CPU 使用率が高くなる可能性があります。
### ディスク容量のモニタリング
メッセージ用のディスクスペースが不足しないようにするには、`KafkaDataLogsDiskUsed` メトリクスを監視する CloudWatch アラームを作成します。このメトリクスの値が 85％ に達するか超える場合は、次の 1 つ以上のアクションを実行します。
+ [Amazon MSK クラスターの自動スケーリング](msk-autoexpand.md) を使用します。「[標準ブローカーの手動スケーリング](manually-expand-storage.md)」の説明に従って、ブローカーストレージを手動で増やすこともできます。
+ メッセージの保持期間またはログサイズを減らします。これを行う方法については、[データ保持パラメータの調整](#bestpractices-retention-period) を参照してください。
+ 未使用のトピックを削除します。
アラームの設定と使用方法については、「[Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。Amazon MSK メトリクスの完全なリストについては「[Amazon MSK プロビジョニングされたクラスターをモニタリングする](monitoring.md)」を参照してください。
### データ保持パラメータの調整
メッセージを消費しても、ログからは削除されません。定期的にディスク容量を解放するには、保持期間 (メッセージをログに保持する期間) を明示的に指定できます。保存ログのサイズを指定することもできます。保持期間または保持ログのサイズのいずれかに達すると、Apache Kafka は、ログから非アクティブなセグメントの削除を開始します。
クラスターレベルで保持ポリシーを指定するには、`log.retention.hours`、`log.retention.minutes`、`log.retention.ms`、または `log.retention.bytes` のいずれかまたは複数のパラメータを設定します。詳細については、「[カスタム Amazon MSK 設定](msk-configuration-properties.md)」を参照してください。
トピックレベルで保持パラメータを指定することもできます。
+ トピックごとに保持期間を指定するには、次のコマンドを使用します。
```
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 つのスレッドのみを使用してこの復旧を実行します。例えば、数千のパーティションがある場合、ログ復旧が完了するまでに数時間かかる可能性があります。ログ復旧を高速化するには、設定プロパティ [https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html) を使用してスレッド数を増やすことが推奨されます。これを 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 の主な特徴および概念](operations.md)」を参照してください。
### 転送中の暗号化を有効にする
転送中の暗号化とその有効化方法については、「[転送中の Amazon MSK 暗号化](msk-encryption.md#msk-encryption-in-transit)」を参照してください。
### パーティションの再割り当て
同じ MSK プロビジョニング済みクラスター上でパーティションを別のブローカーに移動するには、`kafka-reassign-partitions.sh`という名前のパーティション再割り当てツールを使用できます。安全なオペレーションのために、1 回の`kafka-reassign-partitions`呼び出しで 10 個を超えるパーティションを再割り当てしないことをお勧めします。例えば、新しいブローカーを追加してクラスターを拡張したり、ブローカーの削除のためにパーティションを移動したりすると、新しいブローカーにパーティションを再割り当てすることで、そのクラスターを再分散できるようになります。MSK プロビジョニング済みクラスターにブローカーを追加する方法については、「[Amazon MSK クラスター内のブローカーの数を拡張する](msk-update-broker-count.md)」を参照してください。MSK プロビジョニング済みクラスターからブローカーを削除する方法については、「[Amazon MSK クラスターからブローカーを削除する](msk-remove-broker.md)」を参照してください。パーティション再割り当てツールの詳細については、Apache Kafka のドキュメントの「[クラスターの拡張](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion)」を参照してください。