9.10. Kafka および ZooKeeper ストレージの設定

Streams for Apache Kafka を適切に機能させるには、効率的なデータストレージインフラストラクチャーが不可欠です。ブロックストレージを使用することを強く推奨します。Streams for Apache Kafka は、ブロックストレージでの使用についてのみテストされています。NFS などのファイルストレージはテストされておらず、動作するという保証はありません。

ブロックストレージには、以下のいずれかのオプションを選択します。

一時データストレージは一時的なものです。ノード上のすべての Pod は、ローカルの一時ストレージスペースを共有します。データは、それを使用する Pod が実行されている限り保持されます。Pod が削除されると、データは失われます。ただし、Pod は高可用性環境でデータを回復できます。

その一時的な性質のため、一時ストレージは開発とテストにのみ推奨されます。

一時ストレージは emptyDir ボリュームを使用してデータを保存します。Pod がノードに割り当てられると、emptyDir ボリュームが作成されます。sizeLimit プロパティーを使用して、emptyDir のストレージの合計量を設定できます。

一時ストレージを使用するには、Kafka または ZooKeeper リソースのストレージタイプ設定を ephemeral に設定します。ノードプールを使用している場合は、個々のノードプールのストレージ設定で ephemeral を指定することもできます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: ephemeral
    # ...
  zookeeper:
    storage:
      type: ephemeral
    # ...

/var/lib/kafka/data/kafka-logIDX

永続的なデータストレージは、システムが中断した場合でもデータを保持します。永続的なデータストレージを使用する Pod の場合、データは Pod の障害や再起動後も保持されます。永続的な性質のため、実稼働環境には永続ストレージを推奨します。

Streams for Apache Kafka で永続ストレージを使用するには、Kafka または ZooKeeper リソースのストレージ設定に persistent-claim を指定します。ノードプールを使用している場合は、個々のノードプールのストレージ設定で persistent-claim を指定することもできます。

Pod が Persistent Volume Claim (PVC) を使用して Persistent Volume (PV) 上でストレージ要求を行うようにリソースを設定します。PV は、オンデマンドで作成され、それを使用する Pod から独立したストレージボリュームを表します。PVC は、Pod の作成時に必要なストレージの量を要求します。PV の基盤となるストレージインフラストラクチャーを理解する必要はありません。PV がストレージ基準に一致する場合、PVC は PV にバインドされます。

ストレージタイプを指定するには、次の 2 つのオプションがあります。

実稼働環境では、次のように設定することを推奨します。

永続ストレージには、次の設定オプションもあります。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 2
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
    # ...
  zookeeper:
    storage:
      type: persistent-claim
      size: 1000Gi
    # ...

# ...
storage:
  type: persistent-claim
  size: 500Gi
  class: my-storage-class
# ...

selector を使用して、SSD などの特定の機能を提供するラベル付き永続ボリュームを指定します。

# ...
storage:
  type: persistent-claim
  size: 1Gi
  selector:
    hdd-type: ssd
  deleteClaim: true
# ...

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  labels:
    app: my-cluster
  name: my-cluster
  namespace: myproject
spec:
  # ...
  kafka:
    replicas: 3
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
        class: my-storage-class
        overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
      # ...
  # ...
  zookeeper:
    replicas: 3
    storage:
      deleteClaim: true
      size: 100Gi
      type: persistent-claim
      class: my-storage-class
      overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
  # ...

/var/lib/kafka/data/kafka-logIDX

クラスターで使用される永続ボリュームは、ストレージインフラストラクチャーがサポートしている限り、データ損失のリスクなしにサイズ変更できます。Streams for Apache Kafka は、ストレージのサイズを変更する設定の更新に従って、ストレージインフラストラクチャーに変更を指示します。ストレージ拡張は、persistent-claim ボリュームを使用する Streams for Apache Kafka クラスターでサポートされています。

ストレージの削減は、ブローカーごとに複数のディスクを使用する場合にのみ可能です。ディスク上のすべてのパーティションを同じブローカー内の他のボリューム (ブローカー内) または同じクラスター内の他のブローカー (クラスター内) に移動した後、ディスクを削除できます。

JBOD ストレージを使用すると、複数のディスクまたはボリュームを使用するように Kafka クラスターを設定できます。このアプローチにより、Kafka ブローカーのデータストレージ容量が増え、パフォーマンスが向上する可能性があります。JBOD 設定は 1 つ以上のボリュームによって定義され、各ボリュームは 一時 または 永続 ボリュームのいずれかになります。JBOD ボリューム宣言のルールおよび制約は、一時および永続ストレージのルールおよび制約と同じです。たとえば、プロビジョニング後に永続ストレージのボリュームのサイズを縮小できません。また、タイプが ephemeral の場合は、sizeLimit の値を変更することはできません。

JBOD ストレージを使用するには、Kafka リソースのストレージタイプ設定を jbod に設定します。ノードプールを使用している場合は、個々のノードプールのストレージ設定で jbod を指定することもできます。

volumes プロパティーを使用すると、JBOD ストレージアレイまたは設定を設定するディスクを記述できます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
  # ...

JBOD ボリュームが作成されると、ID を変更することはできません。JBOD 設定からボリュームを追加または削除できます。

/var/lib/kafka/data-id/kafka-logidx

この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターにボリュームを追加する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。

この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターからボリュームを削除する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。JBOD ストレージには、常に 1 つのボリュームが含まれている必要があります。

階層化ストレージは、ログセグメントを別のストレージシステムに移動することで、Kafka データを管理するための柔軟なアプローチを導入します。たとえば、頻繁にアクセスされるデータに対してブローカー上のブロックストレージの使用を組み合わせ、データのアクセス性と耐久性を損なうことなく、古いデータやアクセス頻度の低いデータをブロックストレージから Amazon S3 などのよりコスト効率が高くスケーラブルなリモートストレージソリューションにオフロードできます。

階層化ストレージでは、Kafka とリモートストレージシステム間の通信を処理するために Kafka の RemoteStorageManager インターフェイスの実装が必要です。これは、Kafka リソースの設定によって有効になります。Streams for Apache Kafka は、カスタムの階層化ストレージが有効な場合、Remote Log Metadata Management (RLMM) に Kafka の TopicBasedRemoteLogMetadataManager を使用します。RLMM は、リモートストレージに関連するメタデータを管理します。

カスタムの階層化ストレージを使用するには、次の手順を実行します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    tieredStorage:
      type: custom 1
      remoteStorageManager: 2
        className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager
        classPath: /opt/kafka/plugins/tiered-storage-s3/*
        config:
          storage.bucket.name: my-bucket 3
          # ...
    config:
      rlmm.config.remote.log.metadata.topic.replication.factor: 1 4
  # ...