Contents
Kafkaトピックとパーティションの基礎知識
Kafkaを運用するエンジニアにとって、トピックとパーティションの理解はシステム設計の核となる知識です。トピックはメッセージの種類を区別し、パーティションは並列処理を可能にする構造で、両者の設定ミスがパフォーマンス低下や障害につながるケースがあります。本記事では、プロダクション環境での設計指針からトラブルシューティングまで、実務に即した情報を解説します。
トピックとパーティションの役割
Kafkaのトピックは、メッセージを分類するための logical container（論理的コンテナ）です。これに対して、パーティションはトピック内の物理的なデータ分割単位であり、並列処理やスケーラビリティを実現します。
重要な設計ポイント:
- パーティション数が多すぎるとディスクI/Oに負荷がかかる
- 少なすぎるとスループットのボトルネックとなる可能性がある
- レプリケーションは障害耐性を確保するための必須要素（ISR: In-Sync Replicasなど）
プロダクション環境での重要性
トピックとパーティションの設計は、システム全体の信頼性や拡張性に直結します。例えば、リアルタイム分析用のトピックでは数百以上のパーティションが設定される一方、重要な運用データ向けトピックでは冗長性を重視したレプリケーションを採用するケースがあります。
| 項目 | 値 | 補足 |
|---|---|---|
| 適切なパーティション数 | 50〜200程度 | ワークロードに応じて調整が必要 |
| レプリケーション因子の標準値 | 3 | 単一ノード障害への耐性を確保 |
トピック作成時の基本パラメータ設定
トピックを作成する際には、num.partitionsとreplication.factorという2つの主要なパラメータを正しく設定する必要があります。これらの値の選定ミスが将来的な運用に深刻な影響を与えるため、慎重な決め方を心がけましょう。
num.partitionsの適切な値
num.partitionsはトピック内のパーティション数を指定します。このパラメータは「将来のスケーリング可能性」を考慮して設定することが重要です。
具体的な設計指針:
- 初期値は5〜10で設定し、ワークロードに応じて増やす（追加は可能だが削除は困難）
- パーティション数が増えると、Consumerの並列処理能力も向上するが、ディスクI/Oやネットワーク負荷も増加
- 毎日1TB以上のデータを扱う場合、100〜500パーティションが目安
replication.factorの決定要因
replication.factorはレプリケーション数を設定するパラメータです。プロダクション環境では最小3を推奨します。
| レプリケーション因子 | 信頼性 | コスト |
|---|---|---|
| 1 | 低 | 安い |
| 2 | 中 | 中程度 |
| 3 | 高 | 高め |
注意: レプリケーション因子を3に設定する場合、クラスター内に少なくとも3つのブローカーが存在している必要があります。
パーティション数設計の指針
パーティション数はスケーラビリティとパフォーマンスのトレードオフで設計する必要があります。このセクションでは、具体的な算出方法とケーススタディを紹介します。
スケーラビリティとパフォーマンスのトレードオフ
パーティション数が増えることで、並列処理能力は向上しますが、以下のような課題も生じます:
- パーティションごとにメタデータを管理する負荷（ZooKeeperへのアクセス増加）
- Consumerグループの再バランス時のオーバーヘッド
- 同一トピック内のメッセージ順序を保証できない点
ワークロードに応じた最適値の算出方法
以下のようなステップで最適なパーティション数を設計できます:
- ピーク時のデータ量（例：1秒あたり10GB）を算出
- 単一パーティションが処理可能なスループット（例：50MB/s）を確認
- パーティション数 = ピークデータ量 ÷ 単一パーティション容量
例:
ピーク時データ量: 10GB/s → 10,000MB/s
単一パーティション処理能力: 50MB/s
→ パーティション数 = 200
ケーススタディ（仮想事例）
ある大規模企業では、リアルタイム分析向けトピックの設計として、128パーティションを採用しました。これによりConsumerグループが40ノードで並列処理可能となり、解析処理時間を40%削減する効果がありました。
コマンドラインでのトピック設定手順
Kafkaではkafka-topics.shコマンドを使用してトピックを管理できます。以下に基本的な作業手順と実際の運用例を紹介します。
kafka-topics.shの基本構文
|
1 2 3 4 5 |
bin/kafka-topics.sh --bootstrap-server <host>:9092 \ --create --topic <トピック名> \ --partitions <パーティション数> \ --replication-factor <レプリケーション因子> |
実環境での作業例
ステップ1: ツールの場所を確認する
|
1 2 3 |
$ ls bin/kafka-topics.sh bin/kafka-topics.sh |
ステップ2: トピックを作成（例：user_events）
|
1 2 3 4 5 |
bin/kafka-topics.sh --bootstrap-server kafka1:9092 \ --create --topic user_events \ --partitions 8 \ --replication-factor 3 |
ステップ3: 作成確認（リストコマンド使用）
|
1 2 3 |
bin/kafka-topics.sh --bootstrap-server kafka1:9092 \ --list |
動的再設定によるパーティション数変更
運用中のトピックに対して、kafka-topics.shの--alterオプションでパーティション数を増やすことができます。ただし、いくつかの制限や注意点があります。
--alterオプションの使用方法
|
1 2 3 4 |
bin/kafka-topics.sh --bootstrap-server kafka1:9092 \ --alter --topic user_events \ --partitions 16 |
動作メカニズム:
- 新しいパーティションが追加され、既存データはリバランスされる（Consumerの再起動が必要）
- パーティション数の削除は不可能（レプリケーションも含む）
再設定時の注意点
| 注意事項 | 説明 |
|---|---|
| オフピーク時間帯に実施すること | 高負荷時に再設定すると、Consumerが一時的に停止する可能性あり |
| レプリケーション因子を変更しないこと | それにより障害耐性が低下する可能性がある |
プロダクション環境での冗長性設計
高可用性を確保するためには、レプリケーション戦略と監視・フェイルオーバー対策の両方が必要です。以下に具体的な設定例とメトリクスを紹介します。
レプリケーション戦略の選定
- 同期型レプリケーション（ISR：In-Sync Replicas）は障害発生時のデータ損失を最小限に抑える
- 非同期型はパフォーマンス向上が見込めるが、障害リスクが高くなる
| レプリケーションタイプ | 時間ラグ | 信頼性 |
|---|---|---|
| 同期型（ISR） | 無し | 高 |
| 非同期型 | 有り | 中 |
監視・フェイルオーバー対策
以下のようなメトリクスを監視する必要があります:
UnderReplicatedPartitions（レプリケーションが不足しているパーティション数）ISRSize（ISRのサイズ。1以下の場合は障害リスクあり）LeaderElectionRateAndNum（リーダー選出回数が増加＝クラスター不安定）
重要: レプリケーション因子を3に設定している場合でも、ISRが2以下になるとレプリケーションエラーが発生する可能性があるため、定期的な監視が必要です。