Kafka for Achitects １章、２章読書メモ

Posted at 2025-10-28

今日はこちら。１，２章読んで見たので残しておきたいことをメモる。

本の印象

各章の導入部分エンジニアやアーキテクトが議論するのがリアリティあって楽しい
- Kafkaなんだよそれ、使えるのかよ？→ 概念検証で俺はここが気になるんだ！みたいな気持ちの変わり様とか盛り上がってて楽しい
Kafkaの基本的な仕組みやパラメータを適度に説明してくれてるので、圧倒されることなくメンタルモデルが徐々にできていく構成がよい

以下、メモ

コミットログとしての役割： メッセージを永続的に、そして順序付けられた形で記録し続ける。
ランダムアクセスは不可： データベースのように特定のメッセージへランダムにアクセスすることはできない。データは順番に処理されることを前提として設計されている。

Kafkaが高速な並列処理を実現しつつ、データの順序性を保証するために導入している重要な概念が「トピック」「パーティション」「キー」。

トピック (Topic)： メッセージをグループ化する宛先であり、一意の名前で識別される。
パーティション (Partition)： トピック内のデータを分割し、並列処理を可能にする単位。
- メッセージの順序付けは、個々のパーティション内でのみ保証されます。トピック全体でのグローバルな順序付けはない。
- パーティションの数は、トピックを読む単一アプリケーションの並列処理の最大度を決定する（パーティションごとに最大1つのコンシューマインスタンス）。

メッセージにはキー、値、およびオプションのヘッダーが含まれる。この「キー」が順序性を担保する上で非常に重要。

要素	役割	詳細
キー	パーティショニングの決定	同じキーを持つメッセージは必ず同じパーティションにルーティングされる。
順序性の保持	例えば「顧客ID」をキーにすると、その顧客に関連する全てのイベントが同じパーティション内で処理され、順序と一貫性が維持される。
ログ圧縮	後述の「圧縮トピック」において、最新の値を識別するために使われる。

🔑 重要ポイント: キーはメッセージの一意性とは関係ない。複数のメッセージが同じキーを持つことは可能であり、それぞれが個別のエンティティとして処理されます。メッセージの順序が重要でない場合は、キーは省略できる。

コンシューマ側も、パーティションの概念に基づいて並列処理と順序性を管理する。

コンシューマグループ： 複数のコンシューマサービスインスタンスが形成するグループ。
排他制御： Kafkaは、各パーティションをコンシューマグループ内の「1つのコンシューマインスタンス」にのみ割り当てる。
- これにより、特定の顧客（キー）のすべての更新を必ず単一のインスタンスが処理し、データの順序と一貫性が保持される。
非同時処理の選択： 高い同時処理が必要ない場合、コンシューマグループ内のインスタンスが1つだけでも問題ない。

Kafkaの可用性と耐障害性は、レプリケーションの設定によって担保されます。

設定項目	推奨値/役割	補足事項
レプリケーション係数	ほとんどのシナリオで値 3が適切。	トピックごとに設定され、冗長性を確保するためにパーティションのレプリカ数を決定する。
ISR（同期レプリカ）の最小数	ほとんどのユースケースで値 2が十分。	リーダーを含む、同期状態にあると見なされる最小レプリカ数。この数を下回ると、メッセージの書き込みが停止または警告される。

⚠️ 注意点: デフォルトのパーティション数とレプリケーション係数は通常1のため、本番環境では必ず適切な値に設定すべき。パーティション数は設計上の選択であり、後で変更すると順序が乱れる可能性があるため、初期設計が重要。

Kafkaには「圧縮（Compacted）」トピックという特別な設定があり、特定のユースケースで役立つ。

目的： 各キーの最新のメッセージ（値）のみを保持する。
仕組み： ログ圧縮機能により、古いメッセージを定期的に削除し、常に最新の状態を維持する。キーをnullにすることはできない。
一般的なユースケース：
- ユーザープロファイルの最新の状態の維持。
- 現在の製品価格のキャッシュ。
- 時間の経過とともに変化する構成データの管理。
アクセス： 圧縮されていないトピックと同様、アクセスは順次行われる。ランダムアクセスはできない。

実際構築してアプリのせてみないとまだまだ実感できないこと多いですが、少なくとも起動時のログ見てほんの少し何やってるか意識できるようになったのでよし！