Apache Kafka HDInsight クラスターのパフォーマンスの最適化Performance optimization for Apache Kafka HDInsight clusters

この記事では、HDInsight で Apache Kafka のワークロードのパフォーマンスを最適化するためのいくつかの提案を示します。This article gives some suggestions for optimizing the performance of your Apache Kafka workloads in HDInsight. プロデューサーとブローカーの構成の調整に焦点を当てています。The focus is on adjusting producer and broker configuration. パフォーマンスを測定するさまざまな方法があり、適用する最適化はビジネス ニーズによって異なります。There are different ways of measuring performance, and the optimizations that you apply will depend on your business needs.

アーキテクチャの概要Architecture overview

Kafka トピックを使用して、レコードを整理します。Kafka topics are used to organize records. レコードは、プロデューサーによって生成され、コンシューマーによって消費されます。Records are produced by producers, and consumed by consumers. プロデューサーは Kafka ブローカーにレコードを送信し、それからデータが格納されます。Producers send records to Kafka brokers, which then store the data. HDInsight クラスターの各ワーカー ノードが、Kafka のブローカーです。Each worker node in your HDInsight cluster is a Kafka broker.

トピックは、ブローカー間でレコードを分割します。Topics partition records across brokers. レコードの使用時に、パーティションあたり最大 1 つのコンシューマーを使用して、データの並列処理を実現できます。When consuming records, you can use up to one consumer per partition to achieve parallel processing of the data.

レプリケーションを使用して、ノード間でパーティションを複製します。Replication is used to duplicate partitions across nodes. これにより、ノード (ブローカー) が停止しても保護されます。This protects against node (broker) outages. レプリカのグループ間で、1 つのパーティションがパーティション リーダーとして指定されます。A single partition among the group of replicas is designated as the partition leader. プロデューサー トラフィックは、ZooKeeper によって管理された状態に基づいて、各ノードのリーダーにルーティングされます。Producer traffic is routed to the leader of each node, using the state managed by ZooKeeper.

シナリオの特定Identify your scenario

Apache Kafka のパフォーマンスには、スループットと待ち時間という 2 つの主要な側面があります。Apache Kafka performance has two main aspects – throughput and latency. スループットとは、アプリでデータを処理できる最大速度のことです。Throughput is the maximum rate at which data can be processed. 通常はスループットが高ければそれだけ良好です。Higher throughput is usually better. 待ち時間とは、データの格納または取得にかかる時間のことです。Latency is the time it takes for data to be stored or retrieved. 通常は待ち時間が短ければそれだけ良好です。Lower latency is usually better. スループット、待ち時間、およびアプリケーションのインフラストラクチャのコストの間での適切なバランスを見つけることは、困難な場合があります。Finding the right balance between throughput, latency and the cost of the application's infrastructure can be challenging. 高スループット、短い待ち時間、またはその両方が必要かどうかに基づいて、パフォーマンス要件はたいてい次の 3 つ一般的な状況の 1 つが当てはまります。Your performance requirements will likely match one of the following three common situations, based on whether you require high throughput, low latency, or both:

  • 高スループット、低待ち時間。High throughput, low latency. このシナリオでは、高スループットと低待ち時間 (最大 100 ミリ秒) の両方が必要です。This scenario requires both high throughput and low latency (~100 milliseconds). このタイプのアプリケーションは、たとえばサービス可用性監視です。An example of this type of application is service availability monitoring.
  • 高スループット、高待ち時間。High throughput, high latency. このシナリオでは、高スループット (最大 1.5 GBps) が必要ですが、長い待ち時間 (250 ミリ秒未満) を許容できます。This scenario requires high throughput (~1.5 GBps) but can tolerate higher latency (< 250 ms). このタイプのアプリケーションの例としては、セキュリティや侵入検出アプリケーションなどのほぼリアルタイム プロセスのテレメトリ データ インジェストがあります。An example of this type of application is telemetry data ingestion for near real-time processes like security and intrusion detection applications.
  • 低スループット、低待ち時間。Low throughput, low latency. このシナリオでは、リアルタイム処理に対して低待ち時間 (10 ミリ秒未満) が必要ですが、低スループットを許容できます。This scenario requires low latency (< 10 ms) for real-time processing, but can tolerate lower throughput. このタイプのアプリケーションの例としては、オンラインのスペル チェックと文法チェックがあります。An example of this type of application is online spelling and grammar checks.

プロデューサーの構成Producer configurations

次のセクションでは、Kafka プロデューサーのパフォーマンスを最適化するために、最も重要な構成プロパティの一部を強調表示します。The following sections will highlight some of the most important configuration properties to optimize performance of your Kafka producers. すべての構成プロパティの詳細な説明については、プロデューサーの構成に関する Apache Kafka のドキュメントを参照してください。For a detailed explanation of all configuration properties, see Apache Kafka documentation on producer configurations.

バッチ サイズBatch size

Apache Kafka のプロデューサーは、単一のストレージ パーティションに格納される 1 単位として送信される、メッセージのグループ (バッチと呼ばれる) をアセンブルします。Apache Kafka producers assemble groups of messages (called batches) which are sent as a unit to be stored in a single storage partition. バッチ サイズは、そのグループを送信する前になければならないバイト数を意味します。Batch size means the number of bytes that must be present before that group is transmitted. batch.size パラメーターを増やすと、ネットワークと IO 要求からのオーバーヘッドの処理が減るため、スループットを向上させることができます。Increasing the batch.size parameter can increase throughput, because it reduces the processing overhead from network and IO requests. 負荷が低く、バッチ サイズが大きくなると、プロデューサーはバッチの準備が完了するのを待機するため、Kafka の送信待ち時間が増える可能性があります。Under light load, increased batch size may increase Kafka send latency as the producer waits for a batch to be ready. 負荷が高い場合は、スループットを向上させて待ち時間を減らすために、バッチ サイズを増やすことをお勧めします。Under heavy load, it's recommended to increase the batch size to improve throughput and latency.

プロデューサーが必要な確認Producer required acknowledgements

プロデューサーが必要な acks 構成では、書き込み要求が完了したと見なされる前に、パーティション リーダーによって要求される確認の数を判別します。The producer required acks configuration determines the number of acknowledgments required by the partition leader before a write request is considered completed. この設定はデータの信頼性に影響し、01、または-1 の値を取ります。This setting affects data reliability and it takes values of 0, 1, or -1. -1 は、書き込みが完了する前に、確認をすべてのレプリカから受け取る必要があることを意味します。The value of -1 means that an acknowledgement must be received from all replicas before the write is completed. acks = -1 を設定すると、データ損失に対する保証は高くなりますが、待ち時間が長くなりスループットが低下することにもなります。Setting acks = -1 provides stronger guarantees against data loss, but it also results in higher latency and lower throughput. アプリケーションの要件によりさらに高いスループットが求められる場合は、acks = 0 または acks = 1 の設定を試みてください。If your application requirements demand higher throughput, try setting acks = 0 or acks = 1. 一部のレプリカを確認しないと、データの信頼性が低くなる可能性があることに留意してください。Keep in mind, that not acknowledging all replicas can reduce data reliability.

圧縮Compression

Kafka プロデューサーは、メッセージをブローカーに送信する前に圧縮するように構成できます。A Kafka producer can be configured to compress messages before sending them to brokers. compression.type 設定は、使用する圧縮コーデックを指定します。The compression.type setting specifies the compression codec to be used. サポートされている圧縮コーデックは、「gzip」、「snappy」、「lz4」です。Supported compression codecs are “gzip,” “snappy,” and “lz4.” 圧縮には利点があり、ディスク容量の制限がある場合には考慮する必要があります。Compression is beneficial and should be considered if there's a limitation on disk capacity.

2 つの一般的に使用される圧縮コーデック gzipsnappy で、gzip のほうが圧縮率が高いため、CPU 負荷は高くなりますがディスク使用量は少なくなります。Among the two commonly used compression codecs, gzip and snappy, gzip has a higher compression ratio, which results in lower disk usage at the cost of higher CPU load. snappy コーデックは圧縮率は低く、CPU のオーバーヘッドは少なくて済みます。The snappy codec provides less compression with less CPU overhead. ブローカーのディスクまたはプロデューサーの CPU の制限事項に基づいて、使用するコーデックを決定できます。You can decide which codec to use based on broker disk or producer CPU limitations. gzipsnappy に比べて、5 倍の速度でデータを圧縮できます。gzip can compress data at a rate five times higher than snappy.

データ圧縮を使用すると、ディスクに格納できるレコードの数が増加します。Using data compression will increase the number of records that can be stored on a disk. プロデューサーとブローカーによって使用されている圧縮形式の間で不一致がある場合には、CPU のオーバーヘッドが増える可能性もあります。It may also increase CPU overhead in cases where there is a mismatch between the compression formats being used by the producer and the broker. データは送信する前に圧縮し、処理する前に圧縮を解除する必要があります。as the data must be compressed before sending and then decompressed before processing.

ブローカー設定Broker settings

次のセクションでは、Kafka ブローカーのパフォーマンスを最適化するための、いくつかの最も重要な設定を強調表示します。The following sections will highlight some of the most important settings to optimize performance of your Kafka brokers. すべてのブローカーの設定の詳細な説明については、「Apache Kafka documentation on producer configurations」(プロデューサー構成に関する Apache Kafka ドキュメント) を参照してください。For a detailed explanation of all broker settings, see Apache Kafka documentation on producer configurations.

ディスクの数Number of disks

ストレージ ディスクの IOPS (1 秒あたりの入出力操作) および 1 秒あたりの読み取り/書き込みバイト数が限られています。Storage disks have limited IOPS (Input/Output Operations Per Second) and read/write bytes per second. 新しいパーティションを作成する際に、Kafka は、使用可能なディスク間で負荷を分散するために、既存のパーティションが最も少ないディスクに新しい各パーティションを格納します。When creating new partitions, Kafka stores each new partition on the disk with fewest existing partitions to balance them across the available disks. ストレージ戦略にも関わらず、各ディスク上で何百ものパーティションのレプリカを処理するときに、Kafka は使用可能なディスク スループットを容易に飽和させてしまう可能性があります。Despite storage strategy, when processing hundreds of partition replicas on each disk, Kafka can easily saturate the available disk throughput. ここでのトレードオフは、スループットとコストでの間のものです。The tradeoff here is between throughput and cost. アプリケーションがより高いスループットを必要とする場合は、ブローカーごとにより多くのマネージド ディスクを持つクラスターを作成します。If your application requires greater throughput, create a cluster with more managed disks per broker. HDInsight では、実行中のクラスターへのマネージド ディスクの追加は現在サポートしていません。HDInsight does not currently support adding managed disks to a running cluster. マネージド ディスクの数を構成する方法の詳細については、「HDInsight 上の Apache Kafka 用に記憶域とスケーラビリティを構成する」を参照してください。For more information on how to configure the number of managed disks, see Configure storage and scalability for Apache Kafka on HDInsight. クラスター内のノードのストレージ スペースを増やすことでコストがどのような影響を受けるかを理解します。Understand the cost implications of increasing storage space for the nodes in your cluster.

トピックとパーティションの数。Number of topics and partitions

Kafka のプロデューサーは、トピックに書き込みます。Kafka producers write to topics. Kafka のコンシューマーは、トピックから読み取ります。Kafka consumers read from topics. トピックは、ディスク上のデータ構造であるログに関連付けられます。A topic is associated with a log, which is a data structure on disk. Kafka は、プロデューサーからのレコードをトピック ログの末尾に追加します。Kafka appends records from a producer(s) to the end of a topic log. トピック ログは、複数ファイルに分散する多数のパーティションで構成されます。A topic log consists of many partitions that are spread over multiple files. これらのファイルは、同様に、複数の Kafka クラスター ノードに分散します。These files are, in turn, spread across multiple Kafka cluster nodes. コンシューマーは各自の間隔で Kafka トピックから読み取り、トピック ログ内で位置 (オフセット) を選択できます。Consumers read from Kafka topics at their cadence and can pick their position (offset) in the topic log.

Kafka の各パーティションはシステム上のログ ファイルであり、プロデューサー スレッドは同時に複数のログに書き込むことができます。Each Kafka partition is a log file on the system, and producer threads can write to multiple logs simultaneously. 同様に、各コンシューマー スレッドはメッセージを 1 つのパーティションから読み取るので、複数のパーティションからの使用が並列で処理されます。Similarly, since each consumer thread reads messages from one partition, consuming from multiple partitions is handled in parallel as well.

パーティション密度 (ブローカーごとのパーティションの数) を増やすことで、メタデータ操作に関連し、パーティションのリーダーとそのフォロワーの間のパーティション要求/応答ごとのオーバーヘッドが追加されます。Increasing the partition density (the number of partitions per broker) adds an overhead related to metadata operations and per partition request/response between the partition leader and its followers. まだ流れるデータがない場合であっても、パーティションのレプリカは引き続きリーダーからデータをフェッチします。これによりネットワーク経由での要求の送受信のための追加の処理が発生します。Even in the absence of data flowing through, partition replicas still fetch data from leaders, which results in extra processing for send and receive requests over the network.

HDInsight の Apache Kafka クラスター 1.1 以上では、レプリカを含め、ブローカーごとに最大 1,000 個のパーティションを持つことをお勧めします。For Apache Kafka clusters 1.1 and above in HDInsight, we recommend you to have a maximum of 1000 partitions per broker, including replicas. ブローカーごとのパーティションの数を増やすと、スループットが低下し、トピックが使用不可になる場合もあります。Increasing the number of partitions per broker decreases throughput and may also cause topic unavailability. Kafka パーティションのサポートの詳細については、バージョン 1.1.0 でサポートされるパーティションの数の増加に関する公式の Apache Kafka ブログの投稿を参照してください。For more information on Kafka partition support, see the official Apache Kafka blog post on the increase in the number of supported partitions in version 1.1.0. トピックの変更の詳細については、「Apache Kafka: modifying topics」(Apache Kafka: トピックを変更する) を参照してください。For details on modifying topics, see Apache Kafka: modifying topics.

レプリカの数Number of replicas

高いレプリケーション係数により、パーティションのリーダーとフォロワーの間で追加の要求が発生します。Higher replication factor results in additional requests between the partition leader and followers. 結果として、高いレプリケーション係数によりさらに多くのディスクと CPU が追加の要求の処理に使用されるため、書き込みの待ち時間は長くなりスループットは低下します。Consequently, a higher replication factor consumes more disk and CPU to handle additional requests, increasing write latency and decreasing throughput.

Azure HDInsight では、Kafka には、少なくとも 3 倍のレプリケーションを使用することをお勧めします。We recommend that you use at least 3x replication for Kafka in Azure HDInsight. ほとんどの Azure リージョンは 3 つの障害ドメインがありますが、2 つの障害ドメインしかないリージョンでは、ユーザーは 4 倍のレプリケーションを使用する必要があります。Most Azure regions have three fault domains, but in regions with only two fault domains, users should use 4x replication.

レプリケーションの詳細については、「Apache Kafka: レプリケーション」と「Apache Kafka: レプリケーション係数を増やす」を参照してください。For more information on replication, see Apache Kafka: replication and Apache Kafka: increasing replication factor.

次の手順Next steps