Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

makoto-horiguchi

October 03, 2023
Tweet

More Decks by makoto-horiguchi

Other Decks in Technology

Transcript

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

    検討した話

    株式会社ZOZO

    SRE部 / ZOZOSREブロック

    堀口 真


    Copyright © ZOZO, Inc.
    1

    View full-size slide

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

    SRE部 ZOZOSREブロック 

    堀口 真

    2018年旧ZOZOテクノロジーズ(現ZOZO)入社。

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

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


    2

    View full-size slide

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

    3
    ● ファッションEC

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

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

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

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

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

    「ZOZOVILLA」を展開

    ● 即日配送サービス

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

    ● ツケ払い など


    View full-size slide

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


    View full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

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

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

    View full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    少なくするためには?


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. © ZOZO, Inc.
    31
    まとめ


    View full-size slide

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

    View full-size slide