Kafkaの面接では、データがログの中をどう流れるかを理解しているかが問われます。トピックがどのようにパーティションに分割されるのか、どの範囲で順序が保証されるのか、コンシューマーがどうやって処理を分担するのか、障害が起きたときに何が起こるのか、といった点です。ラグ、重複、データ損失に関するシナリオ問題はよく出ます。これらは実運用で実際に直面する問題だからです。
以下に22問と回答をまとめました。デフォルト値などの詳細はKafkaのバージョンによって異なるため、使用中のバージョンを確認する旨を伝えましょう。
基本概念
1. Kafkaとは何で、何に使われますか？
Kafkaは分散型でレプリケーションされたコミットログです。プロデューサーがトピックにレコードを追記し、コンシューマーがそれぞれのペースで読み取ります。イベントストリーミング、ログやメトリクスのパイプライン、サービスの疎結合、分析システムへのデータ供給、ストリーム処理などに使われます。
2. トピック、パーティション、オフセットとは何ですか？
トピックは名前を付けたレコードのストリームです。各トピックはパーティションに分割され、各パーティションは順序付けられた追記専用のログです。パーティション内の各レコードにはオフセットがあり、これは位置を識別する連番です。オフセットが一意になるのはパーティション内だけです。
3. パーティションは順序にどう影響しますか？
Kafkaが順序を保証するのはパーティション内だけです。同じキーを持つレコードはデフォルトで同じパーティションに送られるため、互いの順序が保たれます。パーティションをまたぐと順序はありません。ある顧客のすべてのイベントを順序どおりに扱いたい場合は、顧客IDをキーにします。
4. ブローカーとは何で、コントローラーは何をしますか？
ブローカーはパーティションを保存し、クライアントに応答するKafkaサーバーです。クラスターには複数のブローカーがあります。そのうち1つがコントローラーとして動作し、クラスターのメタデータとパーティションのリーダーシップを管理します。新しいKafkaのバージョンでは、このメタデータ管理にZooKeeperではなく、組み込みの合意形成機構であるKRaftを使います。
5. レプリケーションはどう機能しますか？
各パーティションにはレプリケーション係数があります。1つのレプリカがリーダーとなり読み書きを処理し、残りはそれをコピーするフォロワーです。同期レプリカ（ISR）は、リーダーに追いついているレプリカです。リーダーが故障すると、ISRの中から新しいリーダーが選ばれます。
プロデューサー
6. acks設定にはどんな意味がありますか？
| acks | 意味 | トレードオフ |
|---|---|---|
| 0 | プロデューサーは一切の確認応答を待たない | 最速だが、データを失う可能性がある |
| 1 | リーダーは書き込み後に確認応答する | リーダーがレプリケーション前に故障するとデータを失う可能性がある |
| all | リーダーはすべての同期レプリカを待つ | 最も強い耐久性、レイテンシは高くなる |
耐久性のある書き込みには、acks=allを使い、min.insync.replicasを少なくとも2に設定し、レプリケーション係数を3にします。
7. プロデューサーからの重複メッセージを避けるにはどうしますか？
冪等プロデューサー（enable.idempotence=true）を有効にします。これにより、パーティション内でのリトライに起因する重複をブローカーが破棄できます。複数のパーティションやトピックにまたがる書き込みをアトミックに行う必要がある場合は、トランザクションを使います。
8. プロデューサーはどうやってパーティションを選びますか？
キーを指定すると、デフォルトのパーティショナーがそれをハッシュしてパーティションを選びます。キーがない場合、プロデューサーはレコードをパーティション全体に分散させます（最近のバージョンでは、バッチを効率的に埋めるためにスティッキーな方式を使います）。カスタムパーティショナーを書くこともできます。
9. プロデューサーのスループットに影響するものは何ですか？
バッチ処理（batch.size、linger.ms）、圧縮（lz4やzstdなど）、パーティション数、そしてacksです。バッチを大きくし圧縮すると、通常は多少のレイテンシと引き換えにスループットが上がります。
コンシューマー
10. コンシューマーグループとは何ですか？
トピックの読み取り作業を分担するコンシューマーの集合です。各パーティションは、ある時点でグループ内の1つのコンシューマーに割り当てられます。そのため、グループ内で有効に働けるコンシューマーの数はパーティション数によって制限され、余ったコンシューマーは待機状態になります。
11. リバランスの間には何が起こりますか？
コンシューマーが参加または離脱したとき、あるいはパーティションが変更されたときに、グループはパーティションを再割り当てします。従来のリバランスでは、この処理の間は消費が一時停止します。協調リバランス（Cooperative Rebalancing）と静的メンバーシップ（Static Membership）は、この中断を軽減します。頻繁なリバランスは、処理に時間がかかりすぎる（max.poll.interval.ms）コンシューマーや、ハートビートを逃したコンシューマーが原因であることがよくあります。
12. オフセットはどのようにコミットされますか？
コンシューマーは、次に読むレコードのオフセットをコミットし、それが内部トピックに保存されます。自動コミットは簡単ですが、処理が完了する前にコミットしてしまう可能性があります。処理後に手動でコミットすれば、「完了」とは何かを自分で制御できます。
13. at-most-once、at-least-once、exactly-once とはどういう意味ですか？
- At-most-once: 処理の前にオフセットをコミットします。クラッシュするとレコードが失われる可能性があります。
- At-least-once: 処理してからコミットします。クラッシュすると再処理が発生するため、重複が起こり得ます。
- Exactly-once: 効果が一度だけ発生します。Kafkaでは、冪等プロデューサー、トランザクション、read_committed コンシューマーを使うことでKafka内部では実現可能です。外部システムに書き込む場合は、通常、冪等な書き込みかキーによる重複排除が必要です。
良い回答では、「exactly once」は副作用がどこで発生するかに依存すると述べます。
14. 必ず失敗するポイズンメッセージにはどう対処しますか？
エラーを捕捉し、限られた回数だけ再試行し、それでも失敗したら詳細を付けてそのレコードをデッドレタートピックに送り、オフセットをコミットして処理を続行します。誰かが調査できるように、デッドレタートピックに対してアラートを設定します。
運用とシナリオ
15. コンシューマーラグが増大しています。どう診断しますか？
- どのパーティションにラグがあるかを確認します。1つのパーティションだけならキーの偏りが疑われます。全体にラグがあるなら、処理が遅いかコンシューマーが少なすぎるということです。
- レコードあたりの処理時間と、データベースなどの下流呼び出しを確認します。
- 頻繁なリバランスが起きていないか確認します。
- プロデューサーのレートが上がっていないか確認します。
- コンシューマーを増やす（パーティション数まで）、処理を高速化する、バッチ処理にする、パーティションを増やす、といった方法で対処します。
16. パーティション数はいつ増やすべきですか？
現在のコンシューマーでは提供できない並列性が必要なとき、またはパーティションあたりのスループットが限界になっているときです。注意が必要なのは、パーティションを追加すると新しいレコードのキーとパーティションの対応が変わるため、その変更をまたいでキーの順序が崩れる可能性があることです。順序が重要な場合は、パーティション数をあらかじめ設計しておきましょう。
17. データはどのように保持され、ログコンパクションとは何ですか？
デフォルトでは、Kafkaは時間またはサイズ（retention.ms、retention.bytes）に基づいて古いセグメントを削除します。ログコンパクションを使うと、Kafkaは各キーについて少なくとも最新の値を保持し、これはチェンジログやテーブルのようなトピックに適しています。null値（トゥームストーン）は、そのキーの削除を意味します。
18. ブローカーが故障したらどうなりますか？
そのブローカーがリーダーを務めていたパーティションは、ISRから新しいリーダーを選出します。クライアントはメタデータを更新して処理を続けます。同期レプリカが利用できない場合、アンクリーンリーダー選出を許可しない限り、そのパーティションは利用できなくなります。許可するとデータ損失のリスクがあります。
19. Kafkaクラスターをどのように保護しますか？
転送中の暗号化にはTLS、認証にはSASL（SCRAMやOAuthなど）または相互TLS、トピックとグループに対する認可にはACL、そしてネットワーク制御を用います。必要に応じて、機密性の高いフィールドはアプリケーション層で暗号化します。
20. Kafkaをどのように監視しますか？
重要なシグナルは、コンシューマーラグ、複製不足のパーティション、オフラインのパーティション、リクエストレイテンシ、ディスク使用量、ISRの縮小・拡大率です。これらはJMXメトリクスやPrometheus、Grafanaなどのツールを通じて収集します。
設計に関する質問
21. RabbitMQやSQSのようなメッセージキューではなく、Kafkaを選ぶのはどのようなときですか？
高いスループット、過去のイベントの再生、同じストリームを読む複数の独立したコンシューマー、またはストリーム処理が必要なときはKafkaを選びます。メッセージ単位のルーティング、単純なタスクキュー、あるいはパーティションを管理したくない場合は、従来型のキューを選びます。
22. 注文イベントのパイプラインを設計してください。
「注文は注文IDをキーにした orders トピックに送るので、ある注文のイベントは順序が保たれます。ブローカーは3台以上、レプリケーションファクターは3、acks=all、そして冪等プロデューサーを使います。請求、在庫、分析のコンシューマーはそれぞれ独自のグループを使います。請求の書き込みは注文IDによって冪等にし、失敗したレコードはデッドレタートピックに送り、グループごとにラグを監視します。パーティション数はピークスループットと想定コンシューマー数から、成長の余地を残して決めます。」
準備の方法
可能であれば、ローカルで Kafka を起動し、プロデューサーとコンシューマーグループを書き、コンシューマーを1つ停止してリバランスを観察しましょう。遅いコンシューマーなど、意図的に何かを壊してラグを確認します。解決したデータパイプラインの問題について、実際の体験を1つ用意しておきましょう。関連トピックについては、Databricks とシステムデザイン面接のガイドをご覧ください。
配信保証について声に出して説明する練習をしましょう。ここが答えが曖昧になりやすいポイントです。模擬面接とその記録を取れば、どこが弱点かが見えてきます。ライブ面接での AI ツールの使用については、必ず雇用主のルールに従ってください。
YesToTheOfferでKafka面接の回答を練習しましょう
模擬技術面接を実施し、配信保証について声に出して説明し、後でトランスクリプトを確認します。30分無料、サブスクリプション不要。
