Kafka 開発

Apache Kafka イベントストリーミングと分散メッセージングシステムの専門家です。Kafka ベースのアプリケーションを構築する際は、以下のベストプラクティスに従ってください。

コア原則

• Kafka は高スループット、フォールトトレランスなメッセージングのための分散イベントストリーミングプラットフォーム
• 従来の pub/sub とは異なり、Kafka はプルモデルを使用 - コンシューマーはパーティションからメッセージをプル
• スケーラビリティ、耐久性、必要に応じて exactly-once セマンティクスを考慮した設計
• 実装に TODO、プレースホルダー、欠落部分を残さない

アーキテクチャの概要

コアコンポーネント

• Topics: メッセージを整理するためのカテゴリ/フィード
• Partitions: トピック内の順序付けられた不変シーケンス、並列処理を実現
• Producers: メッセージをトピックに公開するクライアント
• Consumers: トピックからメッセージを読み取るクライアント
• Consumer Groups: 複数のコンシューマー間の消費を調整
• Brokers: データを保存してクライアントにサービスを提供する Kafka サーバー

重要な概念

• メッセージはパーティションに順序付けして追加される
• 各メッセージにはオフセット があります - パーティション内の一意の連番 ID
• コンシューマーは独自のカーソル(オフセット)を管理し、ストリームを何度でも読み取れる
• パーティションはスケーラビリティのためにブローカー全体に分散される

トピック設計

パーティショニング戦略

• パーティションキーを使用して、関連イベントを同じパーティションに配置
• 同じキーのメッセージは常に同じパーティションに送信される
• これにより関連イベントの順序が保証される
• キーを慎重に選択 - 不均等な分布はホットパーティションを引き起こす

パーティション数

• より多いパーティション = より多くの並列処理だがオーバーヘッドも増加
• 検討事項: 期待スループット、コンシューマー数、ブローカーリソース
• 同時実行を予期するコンシューマー数から開始
• パーティションは増やせますが減らすことはできません

トピック設定

• retention.ms: メッセージの保持期間(デフォルト 7 日)
• retention.bytes: パーティションごとの最大サイズ
• cleanup.policy: delete(古いデータを削除)または compact(キーごとに最新を保持)
• min.insync.replicas: 確認が必要な最小レプリカ数

プロデューサーのベストプラクティス

信頼性設定

acks=all               # すべてのレプリカが確認を待機
retries=MAX_INT        # 一時的な失敗時に再試行
enable.idempotence=true # 再試行時の重複メッセージを防止

パフォーマンスチューニング

• batch.size: 送信前にメッセージを蓄積(デフォルト 16KB)
• linger.ms: バッチ処理の待機時間(0 = 即座に送信)
• buffer.memory: 未送信メッセージのバッファリング用メモリ総量
• compression.type: gzip、snappy、lz4、または zstd で帯域幅を節約

エラーハンドリング

• 指数バックオフを使用した再試行ロジックを実装
• 再試行可能エラーと再試行不可能エラーを異なる方法で処理
• 送信失敗をログおよびアラート
• 繰り返し失敗するメッセージの場合 dead letter トピックを検討

パーティショナー

• デフォルト: キーのハッシュがパーティションを決定(null キー = ラウンドロビン)
• 特定のルーティング要件のためのカスタムパーティショナー
• ホットパーティションを回避するため均等分布を確保

コンシューマーのベストプラクティス

オフセット管理

• コンシューマーはオフセット経由で処理したメッセージを追跡
• auto.offset.reset: earliest(最初から開始)または latest(新しいメッセージのみ)
• 処理成功後にオフセットをコミット、その前ではなく
• exactly-once セマンティクスには enable.auto.commit=false を使用

コンシューマーグループ

• グループ内のコンシューマーはパーティションを共有(各パーティションは 1 つのコンシューマーへ)
• パーティション数よりコンシューマーが多い = 一部のコンシューマーがアイドル
• コンシューマーが参加/離脱するときにグループリバランスが発生
• リバランスを削減するため group.instance.id を使用して静的メンバーシップを実現

処理パターン

• パーティション内のメッセージを順序付けして処理
• パーティション間のメッセージの順序外配信を必要に応じて処理
• at-least-once 配信のためべき等処理を実装
• exactly-once には トランザクション処理を検討

タイムアウトと障害

• 処理タイムアウトを実装してスロー イベントを隔離
• タイムアウト時に、イベントをわきに置いて次のメッセージに進む
• すべての単一イベント処理よりシステム全体のパフォーマンスを優先
• すべての再試行に失敗したメッセージ用に dead letter キューを使用

エラーハンドリングと再試行

再試行戦略

• 処理試行ごとに複数回の実行時再試行を許可
• 例: redrive ごとに 3 回の実行時再試行、最大 5 回の redrive = 合計 15 回の再試行
• 実行時再試行は通常 99% の障害をカバー
• 再試行を使い果たしたら dead letter キューにルーティング

Dead Letter トピック

• 処理できないメッセージ用に専用 DLT を作成
• オリジナルのトピック、パーティション、オフセット、エラー詳細を含める
• システム的な問題を示すパターンについて DLT を監視
• DLT から手動または自動の再試行を実装

スキーマ管理

スキーマレジストリ

• Confluent Schema Registry をスキーマ管理に使用
• プロデューサーはシリアライゼーション中に登録スキーマに対してデータを検証
• スキーマ不一致は例外を発生させ、形式が正しくないデータを防止
• プロデューサーとコンシューマーの共通リファレンスを提供

スキーマ進化

• 前方互換性と後方互換性のためスキーマを設計
• デフォルト値を持つオプショナルフィールドを追加して後方互換性を実現
• フィールドの削除または名前変更を回避
• スキーマバージョニングとマイグレーション戦略を使用

Kafka Streams

状態管理

• ログコンパクションを実装して各キーの最新バージョンを保持
• 定期的に状態ストアから古いデータを削除
• 状態ストアのサイズとアクセスパターンを監視
• スケールに適したストレージバックエンドを使用

ウィンドウイング操作

• 順序外イベントと歪んだタイムスタンプを処理
• 適切な時間抽出とウォーターマーク手法を使用
• 遅延到着データ用のグレース期間を設定
• ユースケースに基づいてウィンドウタイプを選択(タンブリング、ホップ、スライディング、セッション)

セキュリティ

認証

• クライアント認証に SASL/SSL を使用
• SASL メカニズムをサポート: PLAIN、SCRAM、OAUTHBEARER、GSSAPI
• 転送中の暗号化のため SSL を有効化
• 認証情報を定期的にローテーション

認可

• きめ細かなアクセス制御に Kafka ACL を使用
• プリンシパルごとに必要最小限の権限を付与
• トピック別に読み取り/書き込み権限を分離
• アクセスパターンを定期的に監査

監視と可観測性

主要メトリクス

• Producer: record-send-rate、record-error-rate、batch-size-avg
• Consumer: records-consumed-rate、records-lag、commit-latency
• Broker: under-replicated-partitions、request-latency、disk-usage

ラグ監視

• コンシューマーラグ = 最後に生成されたオフセット - 最後にコミットされたオフセット
• 高ラグはコンシューマーが追いつけないことを示す
• ラグの上昇傾向にアラート
• コンシューマーをスケール または処理を最適化

分散トレーシング

• メッセージヘッダーでトレースコンテキストを伝播
• エンドツーエンドトレーシングに OpenTelemetry を使用
• プロデューサーとコンシューマーのスパンを相関付け
• パイプライン全体のメッセージジャーニーを追跡

テスト

ユニットテスト

• 隔離されたテスト用に Kafka クライアントをモック
• シリアライゼーション/デシリアライゼーションロジックをテスト
• パーティショニングロジックを検証
• エラーハンドリングパスをテスト

統合テスト

• 埋め込み Kafka または Testcontainers を使用
• プロデューサーからコンシューマーへの完全なフローをテスト
• 使用される場合は exactly-once セマンティクスを検証
• リバランスシナリオをテスト

パフォーマンステスト

• 本番に近いメッセージレートでロードテスト
• コンシューマーのスループットとラグの動作をテスト
• 負荷下でのブローカーリソース使用を検証
• 障害と復旧シナリオをテスト

一般的なパターン

イベントソーシング

• すべての状態変化を不変イベントとして保存
• イベントをリプレイして状態を再構築
• スナップショット用にログコンパクションを使用
• タイムトラベルデバッグを有効化

CQRS(コマンド・クエリ責任分離)

• 書き込み(コマンド)と読み取り(クエリ)モデルを分離
• イベントストアとして Kafka を使用
• イベントから読み取り最適化プロジェクションを構築
• 結果整合性を適切に処理

Saga パターン

• サービス間の分散トランザクションを調整
• 各サービスが次のステップ用にイベントを公開
• ロールバック用に補償トランザクションを実装
• saga インスタンスを追跡するために相関 ID を使用

変更データキャプチャ (CDC)

• データベース変更を Kafka イベントとしてキャプチャ
• Debezium または同様の CDC ツールを使用
• リアルタイムデータ同期を有効化
• イベント駆動型統合を構築