分散メッセージングシステムを用いた新発送サービスのアーキテクチャ / Architecture of a New Shipping Service Using a Distributed Messaging System

こちらで発表した資料です
https://zozotech-inc.connpass.com/event/316086/

Transcript

1. 分散メッセージングシステムを用いた 新発送サービスのアーキテクチャ 株式会社ZOZO
 基幹システム本部 物流開発部 基幹リプレイスブロック 
 作田 航平 Copyright © ZOZO, Inc. 1 2024/06/25 ZOZO物流システムリプレイスの旅 〜序章〜 これまでとこれから
2. © ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック 作田 航平 2022年に株式会社ZOZOに新卒入社。 現在は、物流システムのリプレイスに従事。 趣味は、旅行、漫画、フットサル。 2
3. © ZOZO, Inc. 3 アジェンダ • 発送リプレイスの概要 • リプレイス後のシステム • リプレイス後のアーキテクチャ • リプレイスによって改善された点 • リプレイス後の課題 • まとめ
4. © ZOZO, Inc. 発送リプレイスの概要 4
5. © ZOZO, Inc. 5 発送リプレイスの概要 基幹システムは2004年からオンプレ上で稼働している 約20年間基本的なアーキテクチャを変えずに成長してきたため、現在は巨大なモノリスシステムに なっている
6. © ZOZO, Inc. 6 発送リプレイスの概要 どこかの機能または基幹DBで障害が発生すると他の機能にも影響を及ぼしてしまう 例）月初に経理機能の利用が急増すると、基幹DBに負荷がかかり発送機能のパフォーマンスが低下する
7. © ZOZO, Inc. 7 発送リプレイスの概要 基幹システムや基幹DBで障害が発生しても発送業務が影響を受けないことを目指し、リプレイスを開始 • TECH BLOG：モノリスからマイクロサービスへ-ZOZOBASEを支える発送システムリプレイスの取り組み • 前回のMeetup：モノリスからの脱却に向けた物流システムリプレイスの概要紹介

8. © ZOZO, Inc. 8 発送リプレイスの概要 基幹システムの発送機能から発送業務に絞って別システム(=新発送サービス)に切り出すことを目指した 発送準備処理(注文データから発送ができるようにデータを作成する)は基幹システムに残したまま →発送準備が完了したデータを新発送サービスに送る必要がある 発送終了処理(注文ステータスの更新や発送完了メール、ヤマト運輸さんへの連携)も基幹システムに残す →新発送サービスで発送業務が完了したことを基幹DBに即時連携する必要がある
9. © ZOZO, Inc. 9 発送リプレイスの概要 目的：基幹システムや基幹DBで障害が発生しても発送業務が継続できること 要件 1. 基幹DBのデータを新発送サービスに送る 2. 新発送サービスでのイベントを基幹システム側に即時連携する 基幹システムと新発送サービスを疎結合にした上で双方向にデータのやりとりが必要
10. © ZOZO, Inc. 10 発送リプレイスの概要 目的：基幹システムや基幹DBで障害が発生しても発送業務が継続できること 要件 1. 基幹DBのデータを新発送サービスに送る 2. 新発送サービスでのイベントを基幹システム側に即時連携する 基幹システムと新発送サービスを疎結合にした上で双方向にデータのやりとりが必要 →新発送サービスをマイクロサービスとして構築し、基幹システムと非同期通信を行うために 　分散メッセージングシステムを導入
11. © ZOZO, Inc. リプレイス後のシステム 11
12. © ZOZO, Inc. 12 リプレイス後のシステム 目的を満たすために基幹DBに接続するモジュラーモノリスなシステムと新発送サービスを新規作成 分散メッセージングシステムであるSQSやMSKを使用して疎結合を実現
13. © ZOZO, Inc. 13 モジュラーモノリスなシステム 基幹DBにあるデータを参照・更新するための基盤（基幹システムには手を加えない） 現在は発送と入荷のモジュールを実装しており、モジュラーモノリスな構成になっている （入荷の話はこの後の上原の発表で）
14. © ZOZO, Inc. 14 新発送サービス 発送準備、ピック、梱包でコンテキスト（Javaでいうプロジェクト）を分けている そのため、テーブルも各コンテキストごとに用意している ピックや梱包作業はAPIを通して行われる
15. © ZOZO, Inc. リプレイス後のアーキテクチャ 15
16. © ZOZO, Inc. 16 リプレイス後のアーキテクチャ概略図 クライアントとやり取りを行うWeb Serverも 新規で作成した データの流れに沿って各アプリケーション　 を説明します
17. © ZOZO, Inc. 17 リプレイス後のアーキテクチャ概略図
18. © ZOZO, Inc. 18 リプレイス後のアーキテクチャ：producer batch 発送準備が完了したデータを基幹DBから取得し、SQS(Simple Queue Service)にキューイングしている • SQSの最大メッセージサイズは256KBなので、Java用拡張クライアントライブラリを使用して　 メッセージペイロードをS3に保存している（最大2GBまで） • 既存ロジックの複雑さはproducer batchで吸収 →基幹DBで障害が発生してもSQSに送信されているデータ分は発送業務が可能になる
19. © ZOZO, Inc. 19 リプレイス後のアーキテクチャ：consumer batch SQSから取得したメッセージをJavaのオブジェクトに変換し、Aurora MySQLの発送準備テーブルに保存 している • 同じデータを保存しないように重複排除の制御をしている • 処理できないメッセージはデッドレターキューに退避させる →要件1「基幹DBのデータを新発送サービスに送る」を満たせた
20. © ZOZO, Inc. 20 リプレイス後のアーキテクチャ概略図
21. © ZOZO, Inc. 21 リプレイス後のアーキテクチャ：migrator batch 発送準備テーブルから自コンテキストで必要なデータのみを取得・整形し、テーブルに保存している リプレイスにあたりテーブルを再設計しており、データ構造の違いをここで吸収している →バッチによって各コンテキストにデータが登録されると発送業務が始められる
22. © ZOZO, Inc. 22 リプレイス後のアーキテクチャ概略図
23. © ZOZO, Inc. 23 リプレイス後のアーキテクチャ：Web Server 各作業者は作業開始前にログインが必要 認証基盤は別チームによって新システムに切り出されているが、参照先が基幹DBとなっている →データをクラウドに移行するようにリプレイス中
24. © ZOZO, Inc. 24 リプレイス後のアーキテクチャ：API 各作業はWeb Server経由でAPIにリクエストされ、作業結果がイベントテーブルに書き込まれる 一部の処理で同期的に基幹DBを参照・更新したいケースがあり、モジュラーモノリスのAPIを呼び出して いる →情報の欠落が許容できる場合は基幹DBの影響を受けないようにエラーレスポンスが返ってきても　　　 リトライはしない
25. © ZOZO, Inc. 25 リプレイス後のアーキテクチャ概略図
26. © ZOZO, Inc. 26 リプレイス後のアーキテクチャ：MSK Connect イベントテーブルへの書き込みを検知し、MSK(Amazon Managed Streaming for Apache Kafka)に 変更ログをメッセージとして送信している • MSK ConnectのプラグインにはDebezium connector for MySQLを採用 • MySQLのbinlogを読み込み、データの変更を検知している
27. © ZOZO, Inc. 27 リプレイス後のアーキテクチャ：MSK Connect データ変更の検知(CDC：Change Data Capture)をするにあたり、DynamoDBなどの採用も検討した が書き込んだ内容をすぐ読み込む必要があったため、書き込みもRDSにしている • 前回のMeetup：モノリスからの脱却に向けた 物流システムリプレイスの概要紹介
28. © ZOZO, Inc. 28 リプレイス後のアーキテクチャ：consumer worker MSKに保存されているメッセージを受け取り、基幹DBのデータを更新する（worker：常時起動している プロセス） 受け取ったメッセージが処理できなかった場合はデッドレタートピックは用意せず、メッセージをその まま基幹DBに保存している（基幹DBに障害が発生している場合は同じメッセージを処理し続ける） • Tech Blog：Amazon MSKを用いてMySQLに対してChange Data Captureを実現する →要件2「新発送サービスでのイベントを基幹システム側に即時連携する」を満たせた
29. © ZOZO, Inc. リプレイスによって改善された点 29
30. © ZOZO, Inc. 30 リプレイスによって改善された点 • 疎結合になったので既存システムの影響を受けづらくなり、発送業務が続けられるようになった • 各作業のレスポンスが速くなった • ユニットテストやe2eテストによりデグレが起きにくいシステムになった • 改修範囲や影響範囲の特定がしやすくなった
31. © ZOZO, Inc. リプレイス後の課題 31
32. © ZOZO, Inc. 32 リプレイス後の課題 • 基幹DBのデータが必要になったときの改修が大変 • 作業開始できるようになるまで3つのバッチ処理が必要なので、発送準備からラグが発生している ◦ SQSではなくMSKに寄せていくことも検討中 • 認証機能は別システムになっているが基幹DBを参照しているので、障害発生時にログインが必要と なったユーザーは作業ができない
33. © ZOZO, Inc. 33 まとめ 分散メッセージングシステムを使用することで、基幹システムで障害が発生しても発送業務が継続でき るように疎結合な新システムが構築できた リプレイスは銀の弾丸ではないため全ての課題を解決できたわけではない 障害の分離には成功したが、マイクロサービス化によって新たな課題が生じたので現在も対応中 （今抱えている課題の詳細はこの後の真田の発表をお聞きください） まだリプレイスの途中で複数発送への対応や発送準備の移行などが残っており、必要があれば適切に アーキテクチャを変更していく