通知基盤におけるKafka活用事例 / Kafka Case Study on the Notification Platform

イベント名：Money Forward Tech Day 2024
登壇日：2024年9月20日
登壇者：Ayumi Tamai
説明：弊社では、マネーフォワード クラウドのサービスと通知基盤間のコミュニケーションにKafkaを利用しています。本セッションでは、Kafkaを用いた通知基盤の設計、スキーマ管理、監視について紹介します。
イベントURL：https://techday.moneyforward-dev.jp/2024/

Transcript

1. 通知基盤におけるKafka活用事例 Kafka Case Study on the Notification Platform
2. • 2023- 業務基盤開発本部 MyPageグループ ◦ Business Platform Development Department – My Page Group • 2020-2023 HR本部 人事管理グループ ◦ HR Department – HRIS Group • 2020 マネーフォワード入社 ◦ Joined Money Foward 玉井 あゆみ Ayumi Tamai
3. マネーフォワード クラウド 通知基盤 Money Forward Cloud Notification Platform 💙
4. 通知基盤開発の背景 Why Notification Platform?
5. Challenges in Implementing the Notification Feature 通知機能実装における現状の課題 ユーザーは各プロダクト上で通知を設定する Customers set up notifications for each product 各プロダクトが各通知方法 を提供する Each product provides its own notification channel
6. 通知基盤導入後の姿 After Introduction of the Notification Platform 各プロダクトが通知基盤に通知を送信 Each product sends notifications to the notification platform ユーザーは一箇所で通知設定を管理する Customers set up notifications in one place
7. 通知基盤の存在意義 Reasons Why We Need a Notification Platform • 通知設定と配信における一貫した ユーザー体験 • マネーフォワード クラウド (MFC) 各プロダクトでの開発コスト削減 • Consistent user experience for notification setting & delivery • Reduction of development costs for Money Forward Cloud (MFC) products
8. Kafkaの紹介 What is Kafka?
9. Kafkaの仕組み – 郵便配達の例 How Kafka Works – Example of Postal Delivery
10. Offset = パーティション内で一意の、メッセージの ID Unique ID for a message in a partition Kafkaの仕組み How Kafka Works
11. • Produceとconsumeが疎結合 ◦ 伝統的なMQ（Point-to-point 通信）と異なり、produceさ れたメッセージを複数の consumerが受け取れる • スケーラビリティ • 耐障害性・データの堅牢性 • 特定のインフラベンダーに依存し ない Kafkaの利点 Benefits of Kafka • Producing and consuming are loosely coupled ◦ Multiple consumers can receive a produced message unlike a traditional MQ (point-to-point communication) • Scalability • Fault tolerance, data durability • Independent on infrastructure vendors
12. • Steep learning curve • High initial setup cost for Kafka clusters • 学習コストが高い • Kafkaクラスターの初期セットアッ プが大変 Kafka導入の課題 Challenges of Kafka Adoption
13. 通知基盤の設計 v1 Architecture of the Notification Platform v1
14. 通知基盤の設計 v1 Architecture of the Notification Platform v1
15. 各チームの責任 v1 Responsibility of Each Team v1
16. 通知基盤を使ってください。 Please use the notification platform Producerは自分で実装してください！ We don’t help you implement the producer 󰠁
17. Kafkaよく分からないなぁ…… I don’t quite understand Kafka 新しいこと勉強する余裕ないよ…… I don’t have enough time to learn new tech 🤦
18. Kafka HTTP Proxy 🤝
19. Kafka HTTP Proxy = Produce API • Abstraction of the process to produce messages to a Kafka Topic ◦ Kafka producer client implementation ◦ Business logic specific to our company • On the producer side, messages can be produced from an HTTP client instead of a Kafka client • Kafka Topicにメッセージを produceする処理の抽象化 ◦ Kafka producerクライアント の実装 ◦ 弊社特有のビジネスロジック • Producer側では、Kafka clientの 代わりにHTTP clientからメッセー ジをproduceできる
20. Example – Kafka Producer Client
21. Example – HTTP Client for Kafka HTTP Proxy
22. 利点 • 学習コストの削減 • 開発コストの削減 対価 • 処理能力の低下：一括produceが できない Benefits • Reduction of learning curve • Reduction of development cost Cost • Decline in performance capability: producer batching cannot be used Kafka HTTP Proxy – 利点と対価 Kafka HTTP Proxy – Cost and Benefits
23. POST /produce_notification { “producer_id”: “AwesomeApp”, “user_id”: “123”, “message”: “Hello!”, "timestamp": "2024-01-01T00:00:01" } • 簡単にメッセージをproduceする ためのインターフェース (OpenAPI) • Interface to easily produce messages (OpenAPI) Kafka HTTP Proxy – 機能要件 (1) Kafka HTTP Proxy – Functional Requirements (1)
24. EventID 通知のトリガーとなったイベントのID（ULID推奨） ID of the event that triggered the notification (ULID is preferable) ProducerID 異なるproducer間で識別子が衝突することを防ぐ Avoids ID collision between different producers • Message delivery guarantee ◦ Generating a unique ID for deduplication • メッセージ到達保証 ◦ 重複排除に使うユニークなID 生成 Kafka HTTP Proxy – 機能要件 (2) Kafka HTTP Proxy – Functional Requirements (2) AwesomeApp-123-01D78XYFJ1PRM1WPBCBT3VHMNV UserID
25. • Message order guarantee ◦ Partitioning strategy ◦ Partition key (user ID) • メッセージ順序保証 ◦ パーティショニング戦略 ◦ パーティションキー (user ID) Kafka HTTP Proxy – 機能要件 (3) Kafka HTTP Proxy – Functional Requirements (3)
26. • Message format validation (Protocol Buffers) • メッセージ形式のバリデーション (Protocol Buffers) Kafka HTTP Proxy – 機能要件 (4) Kafka HTTP Proxy – Functional Requirements (4)
27. • エラーハンドリング ◦ Produceに失敗した場合のエ ラーを同期的に返却する ◦ KafkaのエラーをHTTPステー タスコードに変換 ◦ プロダクト側でデータ整合性 を保つために有効 • Error handling ◦ Synchronously return errors when failed to produce a message ◦ Convert Kafka errors to HTTP status codes ◦ Useful for ensuring data consistency on the product side Kafka HTTP Proxy – 機能要件 (5) Kafka HTTP Proxy – Functional Requirements (5)
28. Kafka HTTP Proxy – 非機能要件 Kafka HTTP Proxy – Non-functional Requirements • 高可用性（冗長性） ◦ 単一障害点にならないこと ◦ Multi-AZ • スケーラビリティ・パフォーマンス ◦ ロードバランシング ◦ オートスケーリング • 監視とログ • High availability (redundancy) ◦ Never introducing a single point of failure ◦ Multi-AZ • Scalability and performance ◦ Load balancing ◦ Auto scaling • Monitoring and logging
29. Consumerの監視 Monitoring of Consumers
30. Amazon MSK metrics + Datadog 1. max_offset_lag: トピック内全 パーティションにおけるlag（処理 待ち件数）の最大値 2. bytes_out_per_sec: あるトピッ クで1秒あたりにconsumeしたバイ ト数 3. Produceからconsumeまでにかか る時間 4. Consumeから処理完了までにかか る時間 Kafka Consumerの監視 Monitoring of a Kafka Consumer Amazon MSK metrics + Datadog 1. max_offset_lag: The maximum offset lag (the number of waiting messages) across all partitions in a topic 2. bytes_out_per_sec: The byte size consumed per second in a topic 3. Producer-to-consumer latency 4. Consumer-to-processing latency
31. Consumerの信頼性保証 Ensuring Consumer Reliability
32. • Poison pill = Kafkaのトピックに produceされたが、何回consume しても必ず失敗するレコード – Confluent.io（発表者訳） “Poison Pill” への対処 How to Address “a Poison Pill?” • Poison pill = “a record that has been produced to a Kafka topic and always fails when consumed, no matter how many times it is attempted.” – Confluent.io
33. • Consumerアプリケーションが無効 なメッセージの内容をdead letter queue (DLQ) に保管する • Consumerアプリケーションがプロ ダクトチームに、DLQにメッセー ジ送信があることを知らせる • プロダクトチームはDLQを確認 し、手動でリトライする ※DLQのメッセージは自動リトライで きないため “Poison Pill” への対処 How to Address “a Poison Pill?” • The consumer application stores the invalid contents in the dead letter queue (DLQ henceforth) • The consumer application notifies the product team about the DLQ • The product teams check the DLQ and retry producing manually Note: DLQ messages cannot be retried automatically
34. HTTP Proxy & DLQを備えた通知基盤の設計 v2 Architecture of the Notification Platform v2 with HTTP Proxy & DLQ
35. Architecture of the Notification Platform v2
36. 各チームの責任 v1 Responsibility of Each Team v1
37. 各チームの責任 v2 Responsibility of Each Team v2
38. 通知基盤を使ってください。 Please use the notification platform. Kafkaの複雑な部分は私たちが引き受けます！ We'll handle the complex parts of Kafka for you! 󰠁
39. 🤩 これなら簡単かも！ This might be easy!
40. 課題と今後の展望 Challenges and Future Prospects
41. 課題 Challenges 1. Consumerで処理に失敗したメッ セージのリトライすることを保証 しつつ、後続のメッセージの処理 を続けるには？ 2. まだ本番運用していないので、潜 在的なパフォーマンスの問題があ るかもしれない 3. どの程度の抽象化をプロダクト向 けに提供するのが適切か？ 1. How to guarantee that a consumer properly retries a failed message without blocking the processing of subsequent messages? 2. Not in production use yet; there may be potential performance issues 3. What is the right level of abstraction to present to the product teams?
42. 今後の展望 Future Prospects 弊社マネーフォワードにおいて • Kafka利用を拡大する • Kafka利用者の開発者体験を標準化 する ◦ 全社横断のKafka HTTP proxy ◦ OSSの導入 ◦ Schema Registryの導入 At Money Forward, • Expand the adoption of Kafka • Standardize the developer experience of Kafka users ◦ Consider a company-wide generic Kafka HTTP proxy a ◦ Adopt an OSS ◦ Adopt schema registries
43. Q&A
44. Kafkaの選定理由 • 資料前半「Kafkaの利点」を参照 • マネーフォワード クラウドの 「基盤サービスにおける設計ガイ ドライン」 ◦ ガイドライン：複数プロダク トが利用する基盤では、イベ ントストリーミングにKafkaを 使用する ◦ 理由：イベントストリーミン グサービスを統一すること で、プロダクト開発チームの 負担を減らすため Why We Adopt Kafka • Ref. "Benefits of Kafka" in the first half of the document • "The Design Guidelines for Platform Services" of Money Forward Cloud ◦ Guideline: For platforms used by multiple products, use Kafka for event streaming. ◦ Reason: To reduce the burden on product development teams by standardizing the event streaming service.