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

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

Transcript

1. ここがつらいよ 物流マイクロサービス 株式会社ZOZO
 基幹システム本部 物流開発部 発送基盤開発ブロック
 真田洋輝 Copyright © ZOZO, Inc. 1 ZOZO物流システムリプレイスの旅 〜序章〜 これまでとこれから
2. © ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 発送基盤開発ブロック 真田 洋輝 2021年8月に株式会社ZOZOに中途入社。 発送機能の開発・運用保守を担当するチームに所属し、 現在は物流システムのリプレイスに従事。 趣味は、フットサル、筋トレ。 2
3. © ZOZO, Inc. 3 アジェンダ 1. つらいポイント 1.1. システム間でステータスが不整合な状態になることがあった 1.2. 新発送サービスへのデータ連携にかかる時間が長い 1.3. 連携データを増やす改修コストが高い 1.4. 基幹DBの影響を受けないことを意識しすぎた 2. まとめ
4. © ZOZO, Inc. 4 アジェンダ 1. つらいポイント 1.1. システム間でステータスが不整合な状態になることがあった 1.2. 新発送サービスへのデータ連携にかかる時間が長い 1.3. 連携データを増やす改修コストが高い 1.4. 基幹DBの影響を受けないことを意識しすぎた 2. まとめ
5. © ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあった ピック作業を例にすると
6. © 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
7. © 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
8. © ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあった どのような問題があったか？
9. © ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあった どのような問題があったか？ の前に「既存モノリス→新発送サービス」への 移行フローについて補足
10. © 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 リリース
11. © ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあった どのような問題があったか？ の話にもどると
12. © ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあった ▪課題 新発送サービスで作業するようにした区分については、既存モノリスでは作業し ない想定だったが、イレギュラーで既存モノリスでも作業する場面があった
13. © ZOZO, Inc. 1.1 システム間でステータスが不整合な状態になることがあった ▪課題 新発送サービスで作業するようにした区分については、既存モノリスでは作業し ない想定だったが、イレギュラーで既存モノリスでも作業する場面があった その場合、新発送サービス側のステータスを更新できない
14. © 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）
15. © 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） ここは連携 していなかった
16. © ZOZO, Inc. 16 ▪対策 既存モノリスでピック出来ないようにする（画面に表示しないようにする） 1.1 システム間でステータスが不整合な状態になることがあった
17. © ZOZO, Inc. 17 ▪対策 既存モノリスでピック出来ないようにする（画面に表示しないようにする） とはいえ、既存モノリスでピックしたい場面も出てくるので... 1.1 システム間でステータスが不整合な状態になることがあった
18. © ZOZO, Inc. 18 ▪対策 既存モノリスでピック出来ないようにする（画面に表示しないようにする） とはいえ、既存モノリスでピックしたい場面も出てくるので... 1.1 システム間でステータスが不整合な状態になることがあった 双方向通信になってしまうが「既存モノリス→新発送サービス」 へ同期的にステータスを連携させる （新発送サービスへの移行過渡期にのみ必要なので、期間限定で容認する）
19. © 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） ピック
20. © 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） ピック
21. © ZOZO, Inc. 21 アジェンダ 1. つらいポイント 1.1. システム間でステータスが不整合な状態になることがあった 1.2. 新発送サービスへのデータ連携にかかる時間が長い 1.3. 連携データを増やす改修コストが高い 1.4. 基幹DBの影響を受けないことを意識しすぎた 2. まとめ
22. © ZOZO, Inc. 1.2 新発送サービスへのデータ連携にかかる時間が長い 連携に何分かかっているかというと
23. © 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）
24. © ZOZO, Inc. 1.2 新発送サービスへのデータ連携にかかる時間が長い 10分って長いの？？
25. © ZOZO, Inc. 1.2 新発送サービスへのデータ連携にかかる時間が長い 長くないと思っていたが、長かった...
26. © ZOZO, Inc. 26 ▪課題 開発段階では10分前後かかっても問題ないと思っていた 1.2 新発送サービスへのデータ連携にかかる時間が長い
27. © ZOZO, Inc. 27 ▪課題 開発段階では10分前後かかっても問題ないと思っていた 実際に運用していく中で、迅速に連携しないと困る場面があることが発覚 1.2 新発送サービスへのデータ連携にかかる時間が長い
28. © ZOZO, Inc. 28 ▪課題 開発段階では10分前後かかっても問題ないと思っていた 実際に運用していく中で、迅速に連携しないと困る場面があることが発覚 1.2 新発送サービスへのデータ連携にかかる時間が長い 10分だと長い （遅くとも3分以内には連携したい）
29. © ZOZO, Inc. 29 ▪対策（検討中） • 各バッチで並列処理できるようにする • ワーカー(常時起動しているプロセス)っぽい挙動にしてみる （無限ループなど） • バッチの実行間隔を短くする • 既存モノリスから新発送サービスのAPIを叩いて同期的に連携する ・・・ 1.2 新発送サービスへのデータ連携にかかる時間が長い
30. © ZOZO, Inc. 30 ▪対策（検討中） • 各バッチで並列処理できるようにする • ワーカー(常時起動しているプロセス)っぽい挙動にしてみる （無限ループなど） • バッチの実行間隔を短くする • 既存モノリスから新発送サービスのAPIを叩いて同期的に連携する ・・・ 最終的にはSQSではなくKafkaに寄せていくことを検討中 （連携時間が早くなる＆アプリ側のロジックが簡単になりそう） 1.2 新発送サービスへのデータ連携にかかる時間が長い
31. © 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） バック オフィス
32. © 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） バック オフィス
33. © ZOZO, Inc. 33 アジェンダ 1. つらいポイント 1.1. システム間でステータスが不整合な状態になることがあった 1.2. 新発送サービスへのデータ連携にかかる時間が長い 1.3. 連携データを増やす改修コストが高い 1.4. 基幹DBの影響を受けないことを意識しすぎた 2. まとめ
34. © ZOZO, Inc. 1.3 連携データを増やす改修コストが高い 新発送サービスにデータを持ってくるまでに 何個のバッチが起動していたか？
35. © 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） バック オフィス
36. © ZOZO, Inc. 36 ▪課題 新発送サービスで使いたいデータが1つ増えたら... 1.3 連携データを増やす改修コストが高い
37. © ZOZO, Inc. 37 ▪課題 新発送サービスで使いたいデータが1つ増えたら... 1.3 連携データを増やす改修コストが高い ３バッチ改修する必要がある。（改修コストが高い）
38. © ZOZO, Inc. 38 ▪対策 根本的な解決策はまだ思いついてないです... 1.3 連携データを増やす改修コストが高い
39. © ZOZO, Inc. 39 ▪対策 根本的な解決策はまだ思いついてないです... 検討中 • 既存モノリスで管理しているが発送業務でのみしか使わないマスターは、 新発送サービスでもマスターを管理するようにする（一時的なマスタの2 重管理を許容） • 必要なデータしか連携していなかったが、発送関連のデータは要否にかか わらずある程度連携しておく 1.3 連携データを増やす改修コストが高い
40. © ZOZO, Inc. 40 アジェンダ 1. つらいポイント 1.1. システム間でステータスが不整合な状態になることがあった 1.2. 新発送サービスへのデータ連携にかかる時間が長い 1.3. 連携データを増やす改修コストが高い 1.4. 基幹DBの影響を受けないことを意識しすぎた 2. まとめ
41. © ZOZO, Inc. 1.4 基幹DBの影響を受けないことを意識しすぎた ピック準備（備品※ 確保）の作業を例にすると ※備品：ピックした商品をいれるカゴのようなもの
42. © ZOZO, Inc. 42 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※正常フロー この備品(カゴ) 使います 作業者 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います 1.4 基幹DBの影響を受けないことを意識しすぎた 新バック オフィス （front）
43. © ZOZO, Inc. 43 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※正常フロー この備品(カゴ) 使います 作業者 備品を「使用中」状態 にする 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います OK 1.4 基幹DBの影響を受けないことを意識しすぎた OK 新バック オフィス （front）
44. © ZOZO, Inc. 44 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※正常フロー この備品(カゴ) 使います 作業者 備品を「使用中」状態 にする 基幹DBの備品テーブルのステータスを「使用中」に更新し作業する 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います OK OK 1.4 基幹DBの影響を受けないことを意識しすぎた OK 新バック オフィス （front）
45. © ZOZO, Inc. 1.4 基幹DBの影響を受けないことを意識しすぎた 基幹DBがダウンしていると
46. © ZOZO, Inc. 46 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※基幹DBがダウンしてる場合 この備品(カゴ) 使います 作業者 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います DBダウン中 1.4 基幹DBの影響を受けないことを意識しすぎた 新バック オフィス （front）
47. © ZOZO, Inc. 47 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※基幹DBがダウンしてる場合 この備品(カゴ) 使います 作業者 備品を「使用中」状態 にできない 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います DBダウン中 NG 1.4 基幹DBの影響を受けないことを意識しすぎた 新バック オフィス （front）
48. © ZOZO, Inc. 48 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※基幹DBがダウンしてる場合 この備品(カゴ) 使います 作業者 備品を「使用中」状態 にできない 基幹DBがダウンしていても作業は止めたくないので、 備品を使用してOKとレスポンスしている 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います DBダウン中 NG OK 1.4 基幹DBの影響を受けないことを意識しすぎた 新バック オフィス （front）
49. © ZOZO, Inc. 1.4 基幹DBの影響を受けないことを意識しすぎた 基幹DBがダウンしていなくても タイムアウトすると
50. © ZOZO, Inc. 50 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※クエリタイムアウトが発生した場合 作業者 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います 1.4 基幹DBの影響を受けないことを意識しすぎた この備品(カゴ) 使います 新バック オフィス （front） クエリタイ ムアウト
51. © ZOZO, Inc. 51 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※クエリタイムアウトが発生した場合 作業者 DB負荷が高いだけで、 ダウンしてるわけではない 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います クエリタイ ムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎた この備品(カゴ) 使います 新バック オフィス （front）
52. © ZOZO, Inc. 52 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ ※クエリタイムアウトが発生した場合 作業者 DB負荷が高いだけで、 ダウンしてるわけではない 基幹DBがダウンしているわけではないが、 タイムアウトになったときもOKとレスポンスしていた 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います OK この備品 使います クエリタイ ムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎた この備品(カゴ) 使います 新バック オフィス （front）
53. © ZOZO, Inc. 53 ▪課題 基幹DBを更新せずに備品を使うと不整合な状態になるので、後々手動補正が必要になる 1.4 基幹DBの影響を受けないことを意識しすぎた
54. © ZOZO, Inc. 54 ▪課題 基幹DBを更新せずに備品を使うと不整合な状態になるので、後々手動補正が必要になる 数日に1回程度の頻度でタイムアウトがおきている （詳細は省きますが、基幹DBを使用している以上は一旦しょうがない） 1.4 基幹DBの影響を受けないことを意識しすぎた
55. © ZOZO, Inc. 55 ▪課題 基幹DBを更新せずに備品を使うと不整合な状態になるので、後々手動補正が必要になる 数日に1回程度の頻度でタイムアウトがおきている （詳細は省きますが、基幹DBを使用している以上は一旦しょうがない） クエリタイムアウト(10s)に関しては、再度実行したり少し時間を置くと解消する可能 性が高い 1.4 基幹DBの影響を受けないことを意識しすぎた
56. © ZOZO, Inc. 56 ▪課題 基幹DBを更新せずに備品を使うと不整合な状態になるので、後々手動補正が必要になる 数日に1回程度の頻度でタイムアウトがおきている （詳細は省きますが、基幹DBを使用している以上は一旦しょうがない） クエリタイムアウト(10s)に関しては、再度実行したり少し時間を置くと解消する可能 性が高い 1.4 基幹DBの影響を受けないことを意識しすぎた 不必要な手動補正がそこそこの頻度で発生
57. © ZOZO, Inc. 57 ▪対策（予定） 基幹DBがダウンしているかどうかの状態を管理する環境変数を、 新発送サービス側で持つ 1.4 基幹DBの影響を受けないことを意識しすぎた
58. © ZOZO, Inc. 58 ▪対策（予定） 基幹DBがダウンしているかどうかの状態を管理する環境変数を、 新発送サービス側で持つ その状態によって新発送サービス側の挙動を制御する 1.4 基幹DBの影響を受けないことを意識しすぎた
59. © ZOZO, Inc. 59 ▪対策（予定） 基幹DBがダウンしているかどうかの状態を管理する環境変数を、 新発送サービス側で持つ その状態によって新発送サービス側の挙動を制御する 1.4 基幹DBの影響を受けないことを意識しすぎた 本当に基幹DBがダウンしている時のみ 不整合な状態を許容し処理を継続できるようにする ※平常時 ：補正コスト > 作業を止めないメリット ※DBダウン時：補正コスト < 作業を止めないメリット
60. © ZOZO, Inc. 60 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※基幹DBダウンフラグ=ON 作業者 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います DBダウン中 NG 1.4 基幹DBの影響を受けないことを意識しすぎた この備品(カゴ) 使います 新バック オフィス （front） 備品を「使用中」状態 にできない ダウンフラグ ON
61. © 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
62. © ZOZO, Inc. 62 モノリス 新発送サービス（AWS） 既存モノリス （オンプレミス） モジュラーモノリス （AWS） 基幹DB Consumer Worker 図：新発送サービスでピック準備（備品確保）する時の流れ　※基幹DBダウンフラグ=OFF 作業者 発送DB MSK Connect MSK バック オフィス API API この備品 使います この備品 使います この備品 使います クエリタイ ムアウト NG 1.4 基幹DBの影響を受けないことを意識しすぎた この備品(カゴ) 使います 新バック オフィス （front） 備品を「使用中」状態 にできない OFF ダウンフラグ
63. © 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 ダウンフラグ
64. © ZOZO, Inc. 64 アジェンダ 1. つらいポイント 1.1. システム間でステータスが不整合な状態になることがあった 1.2. 新発送サービスへのデータ連携にかかる時間が長い 1.3. 連携データを増やす改修コストが高い 1.4. 基幹DBの影響を受けないことを意識しすぎた 2. まとめ
65. © ZOZO, Inc. 65 • サービス間でデータをやり取りする部分での課題が多く露呈した ◦ 連携速度、改修コスト、整合性等 ◦ 1つのDBで処理していたプロセスを分離・非同期化するのはやはり大変 • イレギュラーフローも含め現場運用に対する深い理解が必要 • 要件によっては必ず他サービス(DB)に影響を受けないようにすればよいわけで はない ◦ どのような状態だと影響を受けないようにするかの見極めが重要 2. まとめ
66. © ZOZO, Inc. 66 最後に
67. © ZOZO, Inc. 67 つらいポイントの紹介をしましたが
68. © ZOZO, Inc. 68 つらいポイントの紹介をしましたが もちろん、マイクロサービス化して良い面もありました （既存システムの影響を受けづらくなった等）
69. © ZOZO, Inc. 69 また、基幹システムの運用部署としては挑戦的なプロジェクトだった 　
70. © ZOZO, Inc. 70 また、基幹システムの運用部署としては挑戦的なプロジェクトだった つらいポイント＝挑戦した結果