Kafka でディスク満杯を管理する方法 - E-MapReduce - Alibaba Cloud ドキュメントセンター

このトピックでは、Kafka クラスターのディスク領域が満杯になった場合に O&M 操作を実行する方法について説明します。このトピックでは、E-MapReduce (EMR) Kafka 2.4.1 を使用します。

ビジネスシナリオ

Kafka はログデータをディスクに保存します。ディスク領域が満杯になると、そのディスク上の Kafka ログディレクトリはオフラインになります。この場合、ディスク上のパーティションレプリカは読み書きできなくなります。これにより、パーティションの可用性とフォールトトレランスが低下します。リーダーパーティションレプリカが他のブローカーに移行されるため、他のブローカーの負荷が増加します。したがって、ディスク領域が満杯になった場合は、できるだけ早く問題を解決する必要があります。

概要

このトピックでは、Kafka クラスターのディスク領域が満杯になった場合に使用できる O&M ポリシーを、満杯になったディスクのモニタリングと回復という 2 つの観点から説明します。

満杯になったディスクのモニタリング

Kafka サービス：CloudMonitor コンソールで EMR Kafka クラスターの OfflineLogDirectoryCount メトリックにアラートルールを設定することで、オフラインのログディレクトリをリアルタイムで検出できます。

ディスク全体の復旧

ディスク上の Kafka ログディレクトリがオフラインになった場合は、まずディスク領域が満杯になっていないか確認する必要があります。

ログディレクトリのディスク領域が枯渇した場合、以下の O&M 戦略を検討してください：

ディスクのサイズ変更：クラウドディスクのサイズを変更してディスク容量を増やします。この方法は、ブローカーがアタッチされたクラウドディスクを使用するシナリオに適しています。詳細については、「ディスクのサイズ変更による回復」をご参照ください。
ノード内パーティション移行：満杯になったディスクから同じノード上の他のディスクにパーティションを移行します。これは、ブローカーノード上でディスク使用率が不均衡なシナリオに適しています。詳細については、「ノード内パーティション移行による回復」をご参照ください。
データクリーンアップ：満杯になったディスクからログデータを削除します。この方法は、古いデータを安全に削除できる場合に適用されます。詳細については、「データクリーンアップによる回復」をご参照ください。

ディスクのサイズ変更

説明

ブローカー上のディスク領域が満杯になった場合、このポリシーを使用してディスク領域を増やし、関連する要件を満たします。このポリシーの利点は、操作が簡単でリスクが低く、ディスク領域不足の問題を迅速に解決できることです。

シナリオ

このポリシーは、ディスクがブローカーにアタッチされているシナリオに適用されます。

手順

E-MapReduce コンソールでブローカーノードのデータディスクのサイズを変更します。詳細については、「ディスクのサイズ変更」をご参照ください。

ブローカー内でのパーティション移行

説明

ブローカー上のディスク領域が満杯になると、そのディスク上の Kafka ログディレクトリはオフラインになります。その結果、kafka-reassign-partitions.sh ツールを使用してパーティションを移行することはできません。この場合、ブローカーがデプロイされている Elastic Compute Service (ECS) インスタンスで操作を実行して、パーティションレプリカデータをブローカーの他のディスクに移動し、対応する Kafka データディレクトリ内のメタデータを変更できます。これにより、ディスク領域不足の問題を解決できます。

シナリオ

このポリシーは、満杯になったディスクと使用率が比較的低いディスクが存在するため、ブローカー上でディスク使用率が不均衡なシナリオに適用されます。

注意事項

この方法は、同じノード内のディスク間でのパーティション移行のみをサポートします。
パーティションの移行はディスクに I/O ホットスポットを引き起こし、クラスターのパフォーマンスに影響を与える可能性があります。各移行のデータサイズと持続時間がサービスに与える影響を評価する必要があります。
この方法は非標準の操作を伴うため、本番クラスターに適用する前に、対応する Kafka バージョンでテストしてください。

手順

ディスク領域が満杯になると、そのディスク上の Kafka ログディレクトリはオフラインになります。この場合、kafka-reassign-partitions.sh ツールを使用してパーティションを移行することはできません。このセクションでは、ファイルを直接移動し、Kafka 関連のメタデータを変更することでパーティションを移行する非標準の操作方法について説明します。

テスト用のトピックを作成します。
1. SSH を使用してソース Kafka クラスターのマスターノードにログインします。詳細については、「クラスターへのログイン」をご参照ください。
2. 次のコマンドを実行して、テスト用のトピックを作成します。パーティションレプリカはブローカー 0 とブローカー 1 に分散されます。
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --replica-assignment 0:1 --create
```
  次のコマンドを実行して、トピックの詳細を表示できます。
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
  返された情報から、ブローカー 0 が In-Sync Replicas (ISR) リストに含まれていることがわかります。
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 0       Replicas: 0,1   ISR: 0,1
```

次のコマンドを実行して、データ書き込みをシミュレートします。

kafka-producer-perf-test.sh --topic test-topic --record-size 1000 --num-records 600000000 --print-metrics --throughput 10240 --producer-props linger.ms=0 bootstrap.servers=core-1-1:9092

ブローカー 0 のログディレクトリの権限を変更します。
1. マスターノードで、emr-user アカウントに切り替えます。
```
su emr-user
```
2. パスワードなしで対応するコアノードにログインします。
```
ssh core-1-1
```
3. sudo を使用して root 権限を取得します。
```
sudo su - root
```
4. 次のコマンドを実行して、パーティションが配置されているディスクを見つけます。
```
sudo find / -name test-topic-0
```
  次の応答は、パーティションが /mnt/disk4/kafka/log ディレクトリにあることを示しています。
```
/mnt/disk4/kafka/log/test-topic-0
```
5. 次のコマンドを実行して、ブローカー 0 のログディレクトリの権限を 000 に設定します。これにより、ディレクトリが書き込み不可になるディスクエラーをシミュレートします。
```
sudo chmod 000 /mnt/disk4/kafka/log
```
6. 次のコマンドを実行して、test-topic のステータスを確認します。
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
  返された情報から、ブローカー 0 が ISR リストから除外されたことがわかります。
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 1       Replicas: 0,1   ISR: 1
```
ブローカー 0 の Kafka サービスを停止します。
EMR コンソールでブローカー 0 の Kafka サービスを停止します。
次のコマンドを実行して、ブローカー 0 の test-topic のパーティションを同じノード上の別のディスクに移動します。
```
mv /mnt/disk4/kafka/log/test-topic-0 /mnt/disk1/kafka/log/
```
メタデータファイルを変更します。
ソースディレクトリ /mnt/disk4/kafka/log と送信先ディレクトリ /mnt/disk1/kafka/log のメタデータファイルのうち、変更が必要なのは replication-offset-checkpoint と recovery-point-offset-checkpoint です。
- replication-offset-checkpoint ファイルを変更します。test-topic に関連するエントリを元のログディレクトリの replication-offset-checkpoint ファイルからターゲットログディレクトリの replication-offset-checkpoint ファイルに移動し、ファイル内のエントリ数を変更します。変更後の replication-offset-checkpoint ファイルでは、最初の行の 0 はバージョン番号、2 行目の 18 はファイル内のエントリの総数 (これは実際のエントリ行数と一致する必要があります)、最後の行の test-topic 0 4901378 は移行されたパーティションのオフセットレコードです。サンプルコンテンツ：
```
0
18
__consumer_offsets 22 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 9 0
__consumer_offsets 35 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 47 0
__consumer_offsets 2 0
__consumer_offsets 14 0
__consumer_offsets 45 0
__consumer_offsets 10 0
__consumer_offsets 4 0
__consumer_offsets 17 0
__consumer_offsets 30 0
__consumer_offsets 36 0
__consumer_offsets 48 0
test-topic 0 4901378
```
- recovery-point-offset-checkpoint ファイルを変更します。test-topic のエントリを元のログディレクトリの recovery-point-offset-checkpoint ファイルから送信先ログディレクトリの recovery-point-offset-checkpoint ファイルに移動し、送信先ファイルのエントリの総数を更新します。以下は、変更後の recovery-point-offset-checkpoint ファイルの例です。この例では、2 行目の 13 はエントリの総数であり、test-topic 0 4952628 は移行された test-topic のエントリです：
```
0
13
__consumer_offsets 22 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 9 0
__consumer_offsets 35 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 47 0
__consumer_offsets 2 0
__consumer_offsets 14 0
test-topic 0 4952628
__consumer_offsets 45 0
__consumer_offsets 10 0
```
次のコマンドを実行して、ソースブローカー 0 のログディレクトリに正しい権限を復元します。
```
sudo chmod 755 /mnt/disk4/kafka/log
```
ブローカー 0 の Kafka サービスを開始します。
EMR コンソールでブローカー 0 の Kafka サービスを開始します。
次のコマンドを実行して、クラスターのステータスが正常であることを確認します。
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```

ログのクリア

説明

ブローカー上のディスク領域が満杯になった場合、十分なディスク領域が解放されるまで、ビジネスログデータを最も古いデータから最新のデータの順に削除します。Kafka クラスターの内部トピックのデータは削除できません。

シナリオ

このポリシーは、満杯になったディスクから古いビジネスログデータを削除できるシナリオに適用されます。

データの保持期間が変更されない場合、ディスクはすぐに満杯になる可能性があります。したがって、このポリシーは通常、特別な状況によりデータが急増するシナリオに適用されます。

注意事項

名前がアンダースコア (_) で始まるトピックのデータは削除できません。

手順

影響を受けるマシンにログインします。
満杯になったディスクを見つけ、不要なビジネスデータを削除します。
データクリーンアップについては、以下の原則に従ってください：
- 不要なデータ損失を避けるため、Kafka のデータディレクトリを直接削除しないでください。
- 大量の領域を消費しているか、不要になったトピックを特定します。これらのトピック内の選択されたパーティションについて、最も古いログセグメントから削除を開始します。これには、各セグメントの .log、.index、および .timeindex ファイルの削除が含まれます。__consumer_offsets や _schema などの内部トピックのデータは削除しないでください。
影響を受けるブローカーで Kafka サービスを再起動して、ログディレクトリをオンラインに戻します。