ここがつらいよ物流マイクロサービス / this-is-the-hard-part-logistics-microservices

by hiroki sanada

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

© ZOZO, Inc. 6 1.1 システム間でステータスが不整合な状態になることがあったモノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker S3 図：新発送サービスでピックした時の流れ　※正常フローピック作業者ピック商品のステータスを「未ピック→ピック済み」に更新 SQS 発送DB MSK Connect MSK バックオフィス API Producer Batch 新バックオフィス（front） API Migrator Batch Consumer Batch

Slide 7

Slide 7 text

© ZOZO, Inc. 7 1.1 システム間でステータスが不整合な状態になることがあったモノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker S3 図：新発送サービスでピックした時の流れ　※正常フローピック作業者ピック商品のステータスを「未ピック→ピック済み」に更新ピック商品のステータスを「未ピック→ピック済み」に更新両方とも「ピック済み」にステータスが更新される SQS 発送DB MSK Connect MSK バックオフィス API Producer Batch 新バックオフィス（front） API Migrator Batch Consumer Batch

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあったリリース前移行過渡期移行完了既存モノリスでの作業率　：100% 新発送サービスでの作業率：0% 既存モノリスでの作業率　：80% → 40% 新発送サービスでの作業率：20% → 60% 既存モノリスでの作業率　：0% 新発送サービスでの作業率：100% 徐々に連携する発送の区分を増やしていき、新発送サービスでの作業を段階的に増やしている発送区分1 発送区分2 発送区分3 発送区分4 発送区分5 発送区分1 発送区分2 発送区分3 発送区分4 発送区分5 発送区分1 発送区分2 発送区分3 発送区分4 発送区分5 発送区分1 発送区分2 発送区分3 発送区分4 発送区分5 リリース

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© ZOZO, Inc. 14 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS） Consumer Worker S3 図：既存モノリスでピックした時の流れ SQS 発送DB MSK Connect MSK API Producer Batch API Migrator Batch Consumer Batch 2. 基幹DB ピック作業者ピック商品のステータスを「未ピック→ピック済み」に更新新発送サービスは「未ピック」のままバックオフィスピック商品のステータスは「未ピック」のまま 1.1 システム間でステータスが不整合な状態になることがあった新バックオフィス（front）

Slide 15

Slide 15 text

© ZOZO, Inc. 15 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS） Consumer Worker S3 図：既存モノリスでピックした時の流れ SQS 発送DB MSK Connect MSK API Producer Batch API Migrator Batch Consumer Batch 2. 基幹DB ピック作業者ピック商品のステータスを「未ピック→ピック済み」に更新新発送サービスは「未ピック」のままバックオフィスピック商品のステータスは「未ピック」のまま 1.1 システム間でステータスが不整合な状態になることがあった新バックオフィス（front）ここは連携していなかった

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© ZOZO, Inc. 19 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS） Consumer Worker S3 図：既存モノリスでピックした時の流れ SQS 発送DB MSK Connect MSK API Producer Batch API Migrator Batch Consumer Batch 2. 基幹DB 作業者ピック商品のステータスを「未ピック→ピック済み」に更新バックオフィス 1.1 システム間でステータスが不整合な状態になることがあった新バックオフィス（front）ピック

Slide 20

Slide 20 text

© ZOZO, Inc. 20 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS） Consumer Worker S3 図：既存モノリスでピックした時の流れ SQS 発送DB MSK Connect MSK API Producer Batch API Migrator Batch Consumer Batch 2. 基幹DB 作業者ピック商品のステータスを「未ピック→ピック済み」に更新バックオフィスピック商品のステータスを「未ピック→ピック済み」に更新新発送サービスも「ピック済み」に更新される ※イベントテーブルへの書き込みはしない 1.1 システム間でステータスが不整合な状態になることがあった新バックオフィス（front）ピック

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© ZOZO, Inc. 23 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker S3 図：新発送サービスへデータを連携する時の流れ SQS 発送DB MSK Connect MSK バックオフィス API Producer Batch API Migrator Batch Consumer Batch 全て定期実行のBatchなので合計10分前後かかっている 1.2 新発送サービスへのデータ連携にかかる時間が長い新バックオフィス（front）

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© ZOZO, Inc. 30 ■対策（検討中） ● 各バッチで並列処理できるようにする ● ワーカー(常時起動しているプロセス)っぽい挙動にしてみる（無限ループなど） ● バッチの実行間隔を短くする ● 既存モノリスから新発送サービスのAPIを叩いて同期的に連携する・・・最終的にはSQSではなくKafkaに寄せていくことを検討中（連携時間が早くなる＆アプリ側のロジックが簡単になりそう） 1.2 新発送サービスへのデータ連携にかかる時間が長い

Slide 31

Slide 31 text

© ZOZO, Inc. 31 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker S3 図：現実装 SQS 発送DB MSK Connect MSK API Producer Batch API Migrator Batch Consumer Batch SQSにいれていた部分を 1.2 新発送サービスへのデータ連携にかかる時間が長い新バックオフィス（front）バックオフィス

Slide 32

Slide 32 text

© ZOZO, Inc. 32 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：kafkaに寄せた場合の新発送サービスへの連携イメージ発送DB MSK Connect MSK API Producer Batch API Migrator Batch (Worker) Consumer Batch (Worker) 1.2 新発送サービスへのデータ連携にかかる時間が長い新発送サービス側はメッセージ駆動でデータを取り込む新バックオフィス（front）バックオフィス

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© ZOZO, Inc. 35 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker S3 図：新発送サービスへデータを持っていく時の流れ SQS 発送DB MSK Connect MSK API Producer Batch API Migrator Batch Consumer Batch データを持ってくるのに3バッチ起動している 1.3 連携データを増やす改修コストが高い新バックオフィス（front）バックオフィス

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© ZOZO, Inc. 42 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※正常フローこの備品(カゴ) 使います作業者発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使います 1.4 基幹DBの影響を受けないことを意識しすぎた新バックオフィス（front）

Slide 43

Slide 43 text

© ZOZO, Inc. 43 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※正常フローこの備品(カゴ) 使います作業者備品を「使用中」状態にする発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います OK 1.4 基幹DBの影響を受けないことを意識しすぎた OK 新バックオフィス（front）

Slide 44

Slide 44 text

© ZOZO, Inc. 44 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※正常フローこの備品(カゴ) 使います作業者備品を「使用中」状態にする基幹DBの備品テーブルのステータスを「使用中」に更新し作業する発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います OK OK 1.4 基幹DBの影響を受けないことを意識しすぎた OK 新バックオフィス（front）

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© ZOZO, Inc. 46 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※基幹DBがダウンしてる場合この備品(カゴ) 使います作業者発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います DBダウン中 1.4 基幹DBの影響を受けないことを意識しすぎた新バックオフィス（front）

Slide 47

Slide 47 text

© ZOZO, Inc. 47 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※基幹DBがダウンしてる場合この備品(カゴ) 使います作業者備品を「使用中」状態にできない発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います DBダウン中 NG 1.4 基幹DBの影響を受けないことを意識しすぎた新バックオフィス（front）

Slide 48

Slide 48 text

© ZOZO, Inc. 48 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※基幹DBがダウンしてる場合この備品(カゴ) 使います作業者備品を「使用中」状態にできない基幹DBがダウンしていても作業は止めたくないので、備品を使用してOKとレスポンスしている発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います DBダウン中 NG OK 1.4 基幹DBの影響を受けないことを意識しすぎた新バックオフィス（front）

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© ZOZO, Inc. 50 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※クエリタイムアウトが発生した場合作業者発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）クエリタイムアウト

Slide 51

Slide 51 text

© ZOZO, Inc. 51 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※クエリタイムアウトが発生した場合作業者 DB負荷が高いだけで、ダウンしてるわけではない発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使いますクエリタイムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）

Slide 52

Slide 52 text

© ZOZO, Inc. 52 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※クエリタイムアウトが発生した場合作業者 DB負荷が高いだけで、ダウンしてるわけではない基幹DBがダウンしているわけではないが、タイムアウトになったときもOKとレスポンスしていた発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使います OK この備品使いますクエリタイムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

© ZOZO, Inc. 56 ■課題基幹DBを更新せずに備品を使うと不整合な状態になるので、後々手動補正が必要になる数日に1回程度の頻度でタイムアウトがおきている（詳細は省きますが、基幹DBを使用している以上は一旦しょうがない）クエリタイムアウト(10s)に関しては、再度実行したり少し時間を置くと解消する可能性が高い 1.4 基幹DBの影響を受けないことを意識しすぎた不必要な手動補正がそこそこの頻度で発生

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

© ZOZO, Inc. 59 ■対策（予定）基幹DBがダウンしているかどうかの状態を管理する環境変数を、新発送サービス側で持つその状態によって新発送サービス側の挙動を制御する 1.4 基幹DBの影響を受けないことを意識しすぎた本当に基幹DBがダウンしている時のみ不整合な状態を許容し処理を継続できるようにする ※平常時：補正コスト > 作業を止めないメリット ※DBダウン時：補正コスト < 作業を止めないメリット

Slide 60

Slide 60 text

© ZOZO, Inc. 60 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※基幹DBダウンフラグ=ON 作業者発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使います DBダウン中 NG 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）備品を「使用中」状態にできないダウンフラグ ON

Slide 61

Slide 61 text

© ZOZO, Inc. 61 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※基幹DBダウンフラグ=ON 作業者基幹DBダウンフラグ=ONの場合はOKとレスポンスする発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使います OK この備品使います DBダウン中 NG 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）備品を「使用中」状態にできないダウンフラグ ON

Slide 62

Slide 62 text

© ZOZO, Inc. 62 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※基幹DBダウンフラグ=OFF 作業者発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使いますこの備品使いますクエリタイムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）備品を「使用中」状態にできない OFF ダウンフラグ

Slide 63

Slide 63 text

© ZOZO, Inc. 63 モノリス新発送サービス（AWS）既存モノリス（オンプレミス）モジュラーモノリス（AWS）基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※基幹DBダウンフラグ=OFF 作業者基幹DBダウンフラグ=OFFの場合はNGとレスポンスする発送DB MSK Connect MSK バックオフィス API API この備品使いますこの備品使います NG この備品使いますクエリタイムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎたこの備品(カゴ) 使います新バックオフィス（front）備品を「使用中」状態にできない OFF ダウンフラグ

Slide 64

Slide 64 text

Slide 65

Slide 65 text

© ZOZO, Inc. 65 ● サービス間でデータをやり取りする部分での課題が多く露呈した ○ 連携速度、改修コスト、整合性等 ○ 1つのDBで処理していたプロセスを分離・非同期化するのはやはり大変 ● イレギュラーフローも含め現場運用に対する深い理解が必要 ● 要件によっては必ず他サービス(DB)に影響を受けないようにすればよいわけではない ○ どのような状態だと影響を受けないようにするかの見極めが重要 2. まとめ