順番どおりに、一度だけ、速く

• Airbridge は広告クリック・インストール・購入といったイベントをリアルタイムでマッチングするため、イベントを高速に処理するだけでなく、必要な順序で処理し、欠落や重複を防ぐことが重要。
• 従来は Kafka メッセージをマイクロバッチで取得し、イベント種別ごとに順次処理していた。
  • 順序は制御しやすかったが、先行するイベント処理を待つ間、他のワーカーがアイドル状態になっていた。
  • ワーカーごとの処理速度の差と hot partition が重なると、サーバーを増設しても処理速度が頭打ちになっていた。
• これを解決するために Project Differential を設計。
  • マイクロバッチをなくし、イベント種別ごとの Consumer が同じ Kafka topic を独立して読む。
  • 順序保証は topic 全体ではなく partition 単位で行い、順序が重要な同一ユーザーフローのイベントができるだけ同じ partition に入るように構成。
  • 後続の Consumer は先行する Consumer の処理位置を追い越せず、offset または event time 基準の安全距離を置く。
  • 先行する Consumer が処理しないメッセージは次の Consumer に渡して再利用し、バッファがいっぱいになると Kafka を直接読む Polling Mode に切り替える。
• 内部的には partition ごとに ConsumerSuite/PartitionedConsumerChain を置き、LimitedEventProcessor が先行 Consumer の checkpoint を越えないよう制御する。
  • CommitManager はバッファリング・非同期処理中でも、実際に完了した連続 offset だけを Kafka に commit するよう管理する。
• テスト運用でイベントの欠落・重複なく動作することを確認し、従来のマイクロバッチ方式に比べて 10倍以上処理速度が向上。
• 完全なグローバル順序を作る代わりに、実際のビジネスに必要な順序を best effort で守りながらスループットを確保した事例。
• 今後は構造の簡素化、Spot Instance 終了時に対応する adaptive flow control、順次処理そのものを減らすアーキテクチャ改善を検討中。