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

by Kohei Sakuta

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© ZOZO, Inc. 8 発送リプレイスの概要基幹システムの発送機能から発送業務に絞って別システム(=新発送サービス)に切り出すことを目指した発送準備処理(注文データから発送ができるようにデータを作成する)は基幹システムに残したまま →発送準備が完了したデータを新発送サービスに送る必要がある発送終了処理(注文ステータスの更新や発送完了メール、ヤマト運輸さんへの連携)も基幹システムに残す →新発送サービスで発送業務が完了したことを基幹DBに即時連携する必要がある

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© ZOZO, Inc. 10 発送リプレイスの概要目的：基幹システムや基幹DBで障害が発生しても発送業務が継続できること要件 1. 基幹DBのデータを新発送サービスに送る 2. 新発送サービスでのイベントを基幹システム側に即時連携する基幹システムと新発送サービスを疎結合にした上で双方向にデータのやりとりが必要 →新発送サービスをマイクロサービスとして構築し、基幹システムと非同期通信を行うために　分散メッセージングシステムを導入

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© ZOZO, Inc. 18 リプレイス後のアーキテクチャ：producer batch 発送準備が完了したデータを基幹DBから取得し、SQS(Simple Queue Service)にキューイングしている ● SQSの最大メッセージサイズは256KBなので、Java用拡張クライアントライブラリを使用して　メッセージペイロードをS3に保存している（最大2GBまで） ● 既存ロジックの複雑さはproducer batchで吸収 →基幹DBで障害が発生してもSQSに送信されているデータ分は発送業務が可能になる

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© ZOZO, Inc. 26 リプレイス後のアーキテクチャ：MSK Connect イベントテーブルへの書き込みを検知し、MSK(Amazon Managed Streaming for Apache Kafka)に変更ログをメッセージとして送信している ● MSK ConnectのプラグインにはDebezium connector for MySQLを採用 ● MySQLのbinlogを読み込み、データの変更を検知している

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© ZOZO, Inc. 28 リプレイス後のアーキテクチャ：consumer worker MSKに保存されているメッセージを受け取り、基幹DBのデータを更新する（worker：常時起動しているプロセス）受け取ったメッセージが処理できなかった場合はデッドレタートピックは用意せず、メッセージをそのまま基幹DBに保存している（基幹DBに障害が発生している場合は同じメッセージを処理し続ける） ● Tech Blog：Amazon MSKを用いてMySQLに対してChange Data Captureを実現する →要件2「新発送サービスでのイベントを基幹システム側に即時連携する」を満たせた

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© ZOZO, Inc. 33 まとめ分散メッセージングシステムを使用することで、基幹システムで障害が発生しても発送業務が継続できるように疎結合な新システムが構築できたリプレイスは銀の弾丸ではないため全ての課題を解決できたわけではない障害の分離には成功したが、マイクロサービス化によって新たな課題が生じたので現在も対応中（今抱えている課題の詳細はこの後の真田の発表をお聞きください）まだリプレイスの途中で複数発送への対応や発送準備の移行などが残っており、必要があれば適切にアーキテクチャを変更していく

Slide 34

Slide 34 text

No content