Tweet
Tweet

Slide 1

Slide 1 text

データベースの移行方式を
 検討した話
 株式会社ZOZO
 SRE部 / ZOZOSREブロック
 堀口　真
 
 Copyright © ZOZO, Inc. 1

Slide 2

Slide 2 text

© ZOZO, Inc. 株式会社ZOZO
 SRE部 ZOZOSREブロック 
 堀口　真
 2018年旧ZOZOテクノロジーズ（現ZOZO）入社。 
 参照系機能のクラウド移行に従事。 
 現在はZOZOTOWN SREとDBREを兼務し、オンプレ基盤のリ プレイス案件やZOZOTOWNの基幹DBの運用・保守を担当。 ゴルフ好き
 
 2

Slide 3

Slide 3 text

© ZOZO, Inc. https://zozo.jp/
 3 ● ファッションEC
 ● 1,500以上のショップ、8,900以上のブランドの取り扱い 
 ● 常時95万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品 を掲載（2023年6月末時点） 
 ● ブランド古着のファッションゾーン「ZOZOUSED」や 
 コスメ専門モール「ZOZOCOSME」、靴の専門モール 
 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 
 「ZOZOVILLA」を展開
 ● 即日配送サービス
 ● ギフトラッピングサービス
 ● ツケ払い など


Slide 4

Slide 4 text

© ZOZO, Inc. 4 基幹データベースのリプレイス


Slide 5

Slide 5 text

© ZOZO, Inc. 5 基幹データベースのリプレイス HW保守期限が終了すること、およびSQL Server 2012がEOLを迎えることか ら、HWの更改、OSバージョンアップ、SQLserverのバージョンアップを実施し ました。 ※詳しくはこちらのテックブログをご覧ください https://techblog.zozo.com/entry/replace-zozo-databases

Slide 6

Slide 6 text

© ZOZO, Inc. 6 基幹データベースとは


Slide 7

Slide 7 text

© ZOZO, Inc. 7 基幹データベースとは 基幹データベース（以下基幹DB）とは、ZOZOTOWNのサービスの中核をなす マスターDB群であり、数百台のWEBサーバから直接Read/Writeのアクセスを 受け付けます。 格納されるデータ種別によって6種類のデータベースに分割されており、各デー タベースのワークロードは全く異なるものとなります。

Slide 8

Slide 8 text

© ZOZO, Inc. 8 基幹データベースとは DB
 格納されるデータ FrontDB
 セール情報 ショップニュース 会員情報 クーポン情報 ファッションまとめ 注文情報 メンバー情報 ポイント履歴 在庫情報 BackDB
 商品系情報 ショップ、ブランド系情報 拠点情報 メルマガ ReportDB
 分析系情報 BatchDB
 人気順情報 検索系 コーディネイト系 ReadonlyDB
 商品詳細情報
 DmsDB
 データ連携中継用 EtcDB
 上記以外のデータ

Slide 9

Slide 9 text

© ZOZO, Inc. 9 基幹データベースとは 基幹DBはオンプレミスなサーバ上のSQL Serverで稼働しています。 各データベース間のデータ連携は、SQL Serverのトランザクションレプリケーション 機能により実現しており、網の目のような連携ルートが存在します。 BackDB FrontDB EtcDB BatchDB DmsDB CartDB ReportDB

Slide 10

Slide 10 text

© ZOZO, Inc. 10 移行方式の検討


Slide 11

Slide 11 text

© ZOZO, Inc. 11 移行方式の検討 基幹DBをリプレイスするにあたってまず初めに考えたことは、移行方式でし た。 最初に移行方式から考えた理由はいくつかありますが一番の理由は ZOZOTOWNを何時間止めるのか を決めるためでした。

Slide 12

Slide 12 text

© ZOZO, Inc. 12 移行方式の検討 移行方式によってサービス停止の有無・その時間が決まってきます。 ● オンライン移行はできないか？ ● 最小の停止時間で行うためには？ ● 失敗時のリスクが最も少ないのは？ 上記３点を最初に検討しました。

Slide 13

Slide 13 text

© ZOZO, Inc. 13 オンライン移行はできないか？


Slide 14

Slide 14 text

© ZOZO, Inc. 14 オンライン移行はできないか？ オンライン移行を可能とするためには以下を満たす必要があります。 ● クライアントサーバからの接続切替が瞬時にできること ● データにロストや矛盾が発生しないこと

Slide 15

Slide 15 text

© ZOZO, Inc. 15 オンライン移行はできないか？ クライアントサーバは数百台が稼働しており、トラフィックの合間を縫って同じタ イミングで接続を切り替えることは不可能でした。 旧DB更新するクライアントがいれば、新DBを更新するクライアントが両立して しまうのは避けられません。 案としてクライアントサーバ側で新旧DBにダブルライトするよう修正を入れるこ とも考えましたが、DBアクセス箇所が膨大で断念しました。

Slide 16

Slide 16 text

© ZOZO, Inc. 16 オンライン移行はできないか？ 一瞬でも新旧のDBを交互に更新してしまう状況が発生してしまう以上、オンラ インでの移行は諦めざるを得ず、サービスを停止することにより一時的にDBへ のアクセスをゼロにするための静止点を作る必要がありました。

Slide 17

Slide 17 text

© ZOZO, Inc. 17 最小の停止時間で行うためには？


Slide 18

Slide 18 text

© ZOZO, Inc. 18 最小の停止時間で行うためには？ 静止点を設けるためサービス停止は行うとして、今度は停止時間を最小化する ためにはどうしたらよいか？を検討しました。 サービス停止時間＝旧DBと新DBでデータを一致させるための作業時間

Slide 19

Slide 19 text

© ZOZO, Inc. 19 最小の停止時間で行うためには？ データ同期の方法について、いくつか案を出し最善のものを選定するという作 業に入りました。検討した案は以下となります。 案 時間 メリット デメリット SQL Serverのbcp機能による export/import 長い 作業が分かりやすく、トラブル 発生時の中断・リトライ作業が 容易 テーブル数が多いため並列で作 業しても時間かかる。Indexの drop/createなど作業が多い SQL Serverの機能によるバックアップ/リ ストア 普通 DB単位で全てリストアされる ためストアドやシノニムなども 最新化され安全 レプリケーションの整合性が取 れなくなるためリストア後にレプ リケーションを再作成する必要 がある SQL Serverのレプリケーションによるリア ルタイム同期 短い 旧DBの更新がリアルタイムで 新DBに連携されるためデータ 移行作業自体が不要 旧DBから見ると2倍のレプリ ケーションルートが作成されるた め現行環境のシステム負荷が不 安

Slide 20

Slide 20 text

© ZOZO, Inc. 20 最小の停止時間で行うためには？ それぞれのメリット・デメリットの比較を行い、検討した結果、SQL Serverの機 能によるバックアップ/リストア でデータ移行を行うことに決定しました。

Slide 21

Slide 21 text

© ZOZO, Inc. 21 最小の停止時間で行うためには？ また移行当日の作業時間を極小化するため、一番時間のかかるフルリストア は２日前に作業を実施し、その後移行当日までに更新された差分データについ てはトランザクションログを細かく適用していくことで、新旧DBのデータ同期を 行いました。 トランザクションログの適用はジョブを作成することで自動化しました。

Slide 22

Slide 22 text

© ZOZO, Inc. 22 最小の停止時間で行うためには？ リストアの仕組み

Slide 23

Slide 23 text

© ZOZO, Inc. 23 失敗時のリスクを
 少なくするためには？
 


Slide 24

Slide 24 text

© ZOZO, Inc. 24 失敗時のリスクを少なくするためには？ リスクとして考えていたのは大きく以下の２点でした。 ● 作業中のトラブルによりサービス停止時間が長引くこと ● サービス開始後に大量のリクエストを捌ききれずにDBがダウンすること

Slide 25

Slide 25 text

© ZOZO, Inc. 25 失敗時のリスクを少なくするためには？ この２つを同時に解決するために取った方法は、２段階リリースでした。 DBを２つのグループに分割し移行日を分けることで、問題が発生した際の影響 範囲を縮小しました。

Slide 26

Slide 26 text

© ZOZO, Inc. 26 失敗時のリスクを少なくするためには？

Slide 27

Slide 27 text

© ZOZO, Inc. 27 失敗時のリスクを少なくするためには？

Slide 28

Slide 28 text

© ZOZO, Inc. 28 失敗時のリスクを少なくするためには？ ２段階リリース方式を取ることにより、それぞれのサービス停止時間を短縮する ことが可能となり、ZOZOTOWNのアクセスが少ない夜間帯に作業を完了させ ることができました。

Slide 29

Slide 29 text

© ZOZO, Inc. 29 失敗時のリスクを少なくするためには？ ただし２段階リリースにもデメリットがありました。 ● システム構成に影響 ● 切替作業にあたる大勢のメンバーの負担増

Slide 30

Slide 30 text

© ZOZO, Inc. 30 失敗時のリスクを少なくするためには？ 先に述べた通り、各DB間のデータ連携はSQL Serverのトランザクションレプリ ケーションにより実現してます。 フェーズ１では新DBと旧DB間でレプリケーションを張ることになります。 これがSQL Serverのバージョン互換性に抵触したため、データ中継用に一時 的な中間インスタンスを構築することになりました。

Slide 31

Slide 31 text

© ZOZO, Inc. 31 まとめ
 


Slide 32

Slide 32 text

© ZOZO, Inc. 32 まとめ ● 移行方式を工夫することでサービス停止時間を縮小することが可能 ● 移行方式によってはシステム構成に影響が及ぶことがあるので最初に検 討すべき ● 移行リスク低減のための段階リリースのすすめ

Slide 33

Slide 33 text

No content