非同期メッセージングサービスを使ったLINEメッセージ配信の改善/improve-oa-messaging-with-asynchronous-architecture

LINE STOREという、LINEの各デジタルアイテムを販売するWebアプリケーションを開発しています。
LINE STOREでは、多くの場面でLINE STOREの公式アカウントからユーザにメッセージ配信を行っています。
たとえば、ユーザがスタンプ購入後の購入完了通知やボーナスクレジット付与通知などです。

このメッセージ配信処理を、同期処理からメッセージングマイクロサービスを使った非同期処理に移行し、課題を改善したことを共有します。

以下イベントでの登壇資料です。
https://fortee.jp/jjug-ccc-2022-fall/proposal/e771a13a-75e2-4cd3-aaef-4c02eda1622b

Transcript

1. ⾮同期メッセージングサービスを使った LINEメッセージ配信の改善 Kazushi Hirai
2. ⾃⼰紹介 l LINE Fukuoka 株式会社 l 開発1室 Dev K team Manager l LINE STORE l Server-side Engineer l 2 kids l Interests/Hobbies l Exercising / Marathon l Twitter: @hkazushi0627 ฏҪ Ұ࢙ ,";64)*
   )*3"*
3. 発表の流れ l プロダクトと関連テクノロジーの紹介 l メッセージ配信の改善案と利点、⽋点 l ⾮同期メッセージングアーキテクチャとテクノロジースタック l 開発を⾏う上で⼯夫した点 アジェンダ
4. LINE STORE https://store.line.me l LINEの各デジタルアイテムを販売する 公式オンラインストア l LINEスタンプ/絵⽂字/着せかえ l マンガ、占い、LIVE、ゲーム などのLINE関連 サービスの⼀次通貨 l LINEスタンプ プレミアム、LINE MUSIC l 多くの決済⽅法サポート l クレジットカード、LINE Pay、PayPay、 キャリア決済 l テクノロジースタック l Java、Spring-MVC LINE STORE
5. l LINE公式アカウント経由でLINEメッセージを送る l LINE公式アカウント(Official account) = OA l LINE Messaging APIをコール l -*/&
   4503&Ͱͷ׆༻ྫ l 購⼊完了メッセージ、クレジットバック付与通知 l サブスクリプションの定期決済通知 l 新作、おすすめスタンプ通知 OA Message
6. l レイアウトを⾃由にカスタマイズできるメッセージ l JSONデータで構成 l LINE Messaging API の POST bodyに宛先(To)とJSONデータを設定 Flex message 省略
7. メッセージ配信の課題 購⼊完了後に、購⼊完了メッセージ、クレジットバック付与を通知する ケース Messaging APIがエラーになった場合の考慮不⾜ l コールバックレスポンスがエラーになる Messaging APIのレート制限の考慮不⾜ l 1アカウントごとに2,000QPSの制限 メッセージ配信の課題
8. Idea1: Try-catch 改善案1︓Try-catchの追加 Messaging APIのコールにTry-catchを追加。エラーになったときはcatchする。 対策 エラーになったときに、メッセージがロスト 処理が単純 エラーの頻度が少なければ、あとから⼿動で再送 するのもあり
9. Idea2: Add Retry Logic 改善案2︓リトライの追加 Messaging APIが成功するまでリトライする。 対策 失敗した場合もリトライで再送可能 リトライ回数に⽐例して、コールバックレスポンスが遅延 l 成功するまでレスポンスが返らない 最⼤リトライ回数の設定
10. Idea3: Retry asynchronously 改善案3︓⾮同期でリトライする 別スレッドを作成してリトライする。スレッドの終了は待たない。 対策 コールバックレスポンスはスレッド起動後、すぐに返却 コールバック完了は、あくまで受付完了 l Messaging APIの処理完了ではない 処理が複雑 リトライ中にアプリケーションが再起動されると 状態がロスト
11. Idea4: Build async message service 改善案4︓⾮同期マイクロサービスを追加 Messaging APIのコールとリトライを別のマイクロサービスに切り出す。 対策 Applicationの処理は単純 Queueで状態を管理 失敗時は、イベントを再度Queueに登録して リトライする
12. Async message architecture / Tech stack ⾮同期マイクロサービスアーキテクチャ/テクノロジースタック メッセージキュー l Apache Kafka l LINE共通のクラスタ。⾼信頼性。 l リトライ⽤トピック Consumer l Decatonを使⽤して開発
13. LINE Decaton l LINEのOSS https://github.com/line/decaton l Kafka Consumerライブラリ l パーティションをマルチスレッドで同時に処理 l リトライ機能 l レイトリミッター機能 Decaton 最⼤1時間のエラーに耐えられる ように設定 リトライ間隔と最⼤リトライ回数を設定 パーティションごとのQPSを設定 Message APIのレート制限 (2,000QPS) への対策
14. 開発を⾏う上で⼯夫した点 各コンポーネントの役割︓ Producer(Application) l Kafkaにイベント登録 Consumer l Messaging APIのコール l 失敗時のリトライ
15. 開発を⾏う上で⼯夫した点/課題 各コンポーネントの役割︓ Producer(Application) l Kafkaにイベント登録 Consumer l Messaging APIのコール l 失敗時のリトライ Consumerで⾏う メッセージごとにProducer、Consumerの開発が必要 Messaging APIのリクエスト=Flex Messageの作成はどこで⾏うべきか︖ 課題
16. 開発を⾏う上で⼯夫した点/対策 Producer(Application) l Kafkaにイベント登録 l Flex message作成 Consumer l Messaging APIのコール l 失敗時のリトライ messsage StoreOaPushMessageEvent { string messageId = 1; int channelId = 2; string serializedPushMessage = 3; Flex messageのJSONデータを Kafkaのイベントに設定 新しいメッセージ追加時もProducerの 開発のみで対応可能 対策 Kafkaイベント︓
17. 発表の流れ l プロダクトと関連テクノロジーの紹介 l メッセージ配信の改善案と利点、⽋点 l ⾮同期メッセージングアーキテクチャとテクノロジースタック l 開発を⾏う上で⼯夫した点 まとめ
18. THANK YOU!