予約済みディスク使用量について
作成されたトピックとパーティションで Event Streams インスタンスの使用可能なストレージがどのように使用されるか、および適用する構成設定について説明します。
まず、 Event Streams インスタンスの定義済みストレージが使用可能なストレージであることに注意することが重要です。 つまり、すべてのトピックの複製係数が 3 に設定されているため、使用可能なストレージから取得されるのではなく、レプリカによって使用されるストレージについて心配する必要はありません。 これにより、状況がシンプルになり、それらのメッセージの保存をストレージ使用量にマップする方法を計画することができます。
Kafka がデータを保管する方法について
Kafka では、ユーザーはトピックの保存制限を構成できます。
retention.bytes 構成は、トピックの各パーティションのメッセージに割り振られる合計バイト数です。 この値を超えると、 Kafka は最も古いメッセージを削除します。 例えば、通常は 1 日 200 MB のメッセージを単一パーティション・トピックに送信し、それらを 5 日間保持する場合は、 retention.bytes を 1 GB (200 MB x 5 日) に設定します。
これが 10 区画を超える場合は、 retention.bytes = 100 MB (1 GB/ 10 区画) に設定します。
内部的に、Kafka は各パーティションをログ・セグメントに分割します。 この場合も、 log.segment.sizeというプロパティーを設定できます。デフォルトは 512 MB です。 Kafka が最も古いメッセージを削除すると言及した場合、実際には最も古いログ・セグメントが削除されます。 このため、 Kafka は、 retention.bytes 構成を満たすために必要なログ・セグメントの数に加えて、1 つの追加ログ・セグメント用のスペースを保持する必要があります。
以下の例を参照してください。
retention.bytes = 1 GB
log.segment.size = 512 MB
Kafka needs approximately 1.5 GB per partition for the topic storage.
retention.bytes = 100 MB
log.segment.size = 512 MB
Kafka needs approximately 1 GB per partition for the topic storage.
索引のパーティションごとに追加のストレージが必要です。 ログ・セグメントごとに、Kafka は 2 つの 索引も格納します。 これらのサイズは segment.index.sizeによって定義されます。これも構成可能であり、デフォルトは 10 MB です。 参照用に、索引によって使用されるストレージは次のように計算されます。
2 x number.of.log.segments x segment.index.size
ここで
number.of.log.segments = floor(retention.bytes/log.segment.size) + 1
Event Streams によるストレージの管理
トピックの作成、パーティションの作成、トピック構成の変更などのトピック管理操作を実行する場合、 Event Streams は、操作を満たすために十分なストレージが使用可能であることを確認します。 これを行うために、 Event Streams は、以下の方法を使用して各トピックの「予約済みサイズ」を計算します。
cleanup.policy
が compact
に設定されているトピックの場合、各パーティションで消費される予約済みサイズは常に 1 GB です。 トピックの cleanup.policy
が compact
に設定されている場合、 retention.bytes
または retention.ms
のトピック設定に使用される値は無視されます。
cleanup.policy
が delete
または compact, delete
に設定されているトピックの場合、各パーティションで消費される予約済みサイズは次のように計算されます。
Reserved size = retention.bytes + log.segment.size + (2 x segment.index.size x number.of.log.segments)
ここで
number.of.log.segments = floor(retention.bytes/log.segment.size) + 1
予約済みストレージのパーセンテージの合計は、 ibm_eventstreams_instance_reserved_disk_space_percent メトリック によって IBM Cloud Monitoring にも表示されます。
新規トピックの作成、または既存のトピックへのパーティションの追加の要求は、 Event Streams インスタンス用に構成されたストレージの予約済みストレージの合計量が 90% を超える場合、拒否されます。 [1] 拒否された要求は、インスタンスの予約済みストレージ制限に達したことを示す PolicyViolation エラーを受け取ります。 予約済みストレージの制限に達した場合は、トピックをさらに作成する前に、トピックを削除するか、インスタンス用に構成されているストレージの量を増やす必要があります。
Kafka のストレージ要件が更新されると、予約済みサイズの計算が将来変更される可能性があります。
例
はっきりしない影響として、 Kafka は、トピック構成によっては、予想よりも多くのストレージを予約する可能性があります。 以下の例を参照してください。
-
retention.bytes が 1 GB で、ログ・セグメント・サイズが 512 MB のトピック:
パーティションが 1 つの場合、約 1.5 GB のストレージが予約されます。
この場合、予約サイズは保存サイズよりかなり大きくなります。 -
retention.bytes が 50 GB で、ログ・セグメント・サイズが 512 MB のトピック:
パーティションが 1 つの場合、約 50.5 GB のストレージが予約されます。
この場合、予約サイズは保存サイズに非常に近くなります。
-
retention.bytes が 1 GB で、ログ・セグメント・サイズが 128 MB のトピック:
パーティションが 1 つの場合、約 1.1 GB のストレージが予約されます。
この場合、予約サイズは保存サイズに非常に近くなります。
-
Event Streams は、内部管理機能のために、また削除に適格なログ・セグメントの操作可能予約として、インスタンスに割り当てられたストレージの一部を使用します。 ↩︎