AI Session Notes - 2026-03-25

Apache Kafka の基本概念と Rails での活用

学んだこと

• Apache Kafka は分散イベントストリーミングプラットフォームで、Producer/Consumer/Topic/Broker/Partition が核心コンセプト
• Consumer は HTTP のように「リクエストを待つ」のではなく、自分から Broker にメッセージを取りに行く（pull 型 / poll モデル）
• Rails では karafka gem を使い、Web サーバー（puma）とは別プロセス（karafka server）で Consumer を常駐させる
• karafka.rb のルーティング設定は routes.rb に相当し、Topic と Consumer クラスを紐付ける

詳細

Consumer の動作モデル

HTTP（Rails Controller）とは根本的に異なり、Consumer は常駐プロセスがループで Kafka Broker を poll し、新しいメッセージがあれば取得して処理する。レスポンスを返す必要はなく、一方通行の処理になる。

Kafka のオフセットとエラー時のリトライ

学んだこと

• Kafka は各メッセージに連番（offset）を振り、Consumer は「どこまで処理したか」を commit する仕組み
• エラー時に offset を commit しなければ、次の poll で同じメッセージを再取得できる
• 配信保証には3段階ある：
• At-most-once: 処理前に commit → メッセージ消失の可能性
• At-least-once: 処理後に commit → 重複処理の可能性（一般的に採用）
• Exactly-once: トランザクション使用 → 複雑
• at-least-once では冪等性（idempotency）を持たせるか、イベントIDで重複チェックする
• 規定回数リトライしても失敗するメッセージは DLQ（Dead Letter Queue）に退避して後から調査できる

Kafka と SQS/SNS の違い

学んだこと

• Kafka: メッセージは消費後も保持期間まで残る（ログ型）。offset を戻せばリプレイ可能。1つの Topic を複数の Consumer Group が独立して読める（1対多が組み込み）
• SQS（Simple Queue Service）: 1対1のメッセージキュー。Consumer が処理したらメッセージは消える。リプレイ不可
• SNS（Simple Notification Service）: 1対多の通知配信。受け取ったメッセージのコピーを登録された全購読者に配る仲介役
• SQS は1対1の制約があるため、複数サービスにイベントを配信するには SNS + SQS の組み合わせが必要
• SNS がメッセージを受け取り、購読している各 SQS キューにコピーを配る
• Producer は SNS に1回送るだけで、送り先を知る必要がない（責任の分離）
• Kafka は1対多・リプレイが設計に組み込まれているので、SNS のような仲介役が不要

詳細

使い分けの判断基準

• 非同期ジョブ処理だけなら → SQS / Sidekiq で十分
• 1つのイベントを複数サービスで共有 → SNS + SQS / Pub/Sub
• イベント履歴の保持・リプレイ・大量ストリーム処理 → Kafka / Kinesis

AWS/GCP の対応サービス

カテゴリ	AWS	GCP
Kafka 相当	Amazon MSK / Kinesis	Cloud Pub/Sub
メッセージキュー	SQS	Cloud Tasks
通知配信	SNS	Cloud Pub/Sub（両方の役割を兼ねる）

メタ情報

• ツール: Claude Code
• 関連技術: Apache Kafka, Ruby on Rails, karafka, AWS SQS, AWS SNS, メッセージキュー, イベント駆動アーキテクチャ