はじめに
こんにちは。DevRelブロックの@wirohaです。6月25日に「ZOZO物流システムリプレイスの旅〜序章〜これまでとこれから」を開催しました。ZOZOのエンジニアが物流システムリプレイス開発事例を紹介するイベントです。
登壇内容まとめ
弊社から次の3名が登壇しました。各発表はYouTubeにアップロードしてありますので、見逃した方やもう一度見たい方はぜひご覧ください。
| コンテンツ | 登壇者 |
|---|---|
| 分散メッセージングシステムを用いた新発送サービスのアーキテクチャ | 作田 航平 |
| ここがつらいよ 物流マイクロサービス | 真田 洋輝 |
| リプレイスを安心安全に 〜段階的リプレイスと等価比較〜 | 上原 駿 |
分散メッセージングシステムを用いた新発送サービスのアーキテクチャ
作田からは発送サービスのアーキテクチャについて、リプレイス前後の比較やメリット・課題などを発表しました。分散メッセージングシステムを使用することで、基幹システムで障害が発生しても発送業務が継続できるように疎結合な新システムが構築できました。一方すべての課題を解決できたわけではなく、今後の課題も紹介されました。
ここがつらいよ 物流マイクロサービス
真田からは物流マイクロサービスのつらいポイントにフォーカスした発表を行いました。実際に遭遇した課題とその対策を紹介し、Xでも「ありそう」「リアル」といった反響をいただきました。イレギュラーフローも含めた現場運用の理解やバランス感覚が必要で、物流システムの特性を感じました。
当日はたくさんの質問をいただきました。その中で回答できなかったものについて、回答を掲載します。
Q：ダウンフラグONはサーキットブレイカーのようなものですか？
A：ダウンフラグ（サーキットブレーカーでいう状態）を自動で更新するか手動で更新するかの違いはありますが、同じようなものです。障害発生時にサーキットブレーカーのように通信自体を遮断するかどうかについてはまだ検討中ですが、障害発生時用の挙動に切り替わる点は同じです。
リプレイスを安心安全に 〜段階的リプレイスと等価比較〜
上原からは入荷リプレイスの概要と進め方について発表しました。入荷はもし止まってしまうとさまざまな業務に影響が出る重要な部分です。既存課題の解決をしながら安全にリプレイスするため、フェーズを分けて段階的に進めることにしました。旧実装と新実装後で等価比較する仕組みにより、安全にリプレイスを進めることができていました。
こちらの発表に関しても、当日いただいた質問への補足回答をいたします。
Q：モジュラモノリスのアプリケーションを複数人で開発する中で苦労されたエピソードがあれば教えてください。
A：モジュラーモノリス内には、発送と入荷があり、テストデータの準備に苦労しました。というのも発送と入荷の開発は、それぞれのチームに分かれており、お互いの開発状況をあまり把握しておらず、入荷用にデータを修正したり、逆に発送用にデータを修正したりしなくてはならないなどがありました。
Q：具体的にどういう部分（テーブルなど）が原因で基幹DBから分離ができないのでしょうか？
A：具体的には在庫などでしょうか。在庫増減などは複雑な部分（ZOZOTOWNや発送などが関わる）なので、分離は難しいと考えました。
最後に
今回はたくさんの方にご参加いただき、ありがとうございました。質問も多数寄せられ、関心の高さが伺えました。今後もさまざまな分野でイベントを開催していきますので、ぜひご参加ください。
ZOZOでは一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は以下のリンクからぜひご応募ください。
