データベースの移行方式を検討した話

Transcript

1. データベースの移行方式を

   検討した話

   株式会社ZOZO

   SRE部 / ZOZOSREブロック

   堀口　真

   

   Copyright © ZOZO, Inc.
   1
   

   View Slide

2. © ZOZO, Inc.
   株式会社ZOZO

   SRE部 ZOZOSREブロック 

   堀口　真

   2018年旧ZOZOテクノロジーズ（現ZOZO）入社。
   

   参照系機能のクラウド移行に従事。
   

   現在はZOZOTOWN SREとDBREを兼務し、オンプレ基盤のリ
   プレイス案件やZOZOTOWNの基幹DBの運用・保守を担当。
   ゴルフ好き

   

   2
   

   View Slide

3. © ZOZO, Inc.
   https://zozo.jp/

   3
   ● ファッションEC

   ● 1,500以上のショップ、8,900以上のブランドの取り扱い
   

   ● 常時95万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品
   を掲載（2023年6月末時点）
   

   ● ブランド古着のファッションゾーン「ZOZOUSED」や
   

   コスメ専門モール「ZOZOCOSME」、靴の専門モール
   

   「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン
   

   「ZOZOVILLA」を展開

   ● 即日配送サービス

   ● ギフトラッピングサービス

   ● ツケ払い など

   

   View Slide

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

   

   View Slide

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

   View Slide

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

   

   View Slide

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

   View Slide

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

   DmsDB
 データ連携中継用
   EtcDB
 上記以外のデータ
   

   View Slide

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

   View Slide

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

    

    View Slide

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

    View Slide

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

    View Slide

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

    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

23. © ZOZO, Inc.
    23
    失敗時のリスクを

    少なくするためには？

    

    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

31. © ZOZO, Inc.
    31
    まとめ

    

    

    View Slide

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

    View Slide

33. View Slide