FutureCon2022_DBのデータ移行って何するの？

DBのデータ移行って何するの？
エンタープライズ系システムをクラウドリフトするときに考えること

Transcript

1. - 1 - FutureCon 2022 DBのデータ移行って何するの？ エンタープライズ系システムを クラウドリフトするときに考えること
2. - 2 - 自己紹介 山崎 悠希 Yamazaki Yuki ◼ 経歴 2016年 フューチャー株式会社に新卒入社。 新人研修を経て、流通小売系プロジェクトに配属。アプリ開発とデータベース運用を担当。 その後、2019年～2021年の2年間、大規模クラウドリフト案件でデータ移行リーダーを経験。 ◼ 関連キーワード #データベース #流通小売 #クラウド #データ移行 #海外旅行 #日曜農家
3. - 3 - 本日、お伝えしたいこと ◼ エンタープライズ系（以下、エンプラ系）システムのクラウドリフト案件で、 はじめてDBのデータ移行を任された際に、何を考えればいいのか。 何が重要な 観点なの？ どういったことを やらないといけ ないの？ こういう観点が 大事なのね！
4. - 4 - アジェンダ 1. 移行とは 2. 移行の種類 3. エンプラ系システムのDBデータ移行で考えること 4. 移行のステップ 1. 移行方法選定 2. 設計・構築 3. リハーサル 4. 本番 5. まとめ
5. - 5 - 移行とは ◼ 現行と新のギャップをどのように登るか。 現行 新 ＝ 登り方 移行 経営・業務改革 × IT改革
6. - 6 - 移行の種類 ◼ 移行は、「業務移行」「システム移行」「データ移行」の3種類に分解できる。 現行 新 現行業務 現行システム＋周辺 現行データ 新業務 新システム＋周辺 新データ 業務 移行 システム 移行 データ 移行
7. - 7 - 【補足】クラウドリフトとは ◼ 既存のオンプレミス環境で運用しているシステムをそのままクラウドに移行すること。 ➢ クラウドを活用したシステムにしていく上での最初のステップ。 クラウドリフト • IaaS活用 • 物理機器の撤廃 クラウドネイティブ • サーバレス化 • マイクロサービス • IaC導入 クラウドシフト • マネージドサービス活用 • 商用ソフトウェア置換え 本日のスコープ
8. - 8 - 私がやったこと ◼ 大手スーパーのクラウドリフト案件でエンプラ系システムのDBデータ移行をリーディング。 ➢ DB運用をやっていた経験から自ら手を挙げ立候補 → アサイン。 ➢ 対象のDBは24/365稼働、顧客のビジネスの根幹を支える全データを管理。 • 商品情報や店舗情報などのマスタデータ全般 ＋ 受発注、売上仕入や物流、メーカーや取引先など、外部や周辺 システムへのI/Fなどのトランデータの管理 ＋ 情報分析基盤の分析結果データを管理。 ➢ 総データ量は数十TB。1日のデータ更新量は数TBと、かなり大きな規模。
9. - 9 - エンプラ系システムのDBデータ移行で考えること ◼ エンプラ系システムをクラウドリフトする際の、DBデータ移行で考えることは以下の3つ。 ポイント① いかに業務影響を回避して移行するか いかに確実にデータを移行するか いかに必要十分なコスト（工数・費用）で移行するか ポイント② ポイント③
10. - 10 - データ移行のステップ ◼ エンプラ系DBのデータ移行のステップは以下の4つ。 ① 移行方法選定 ➢ データ移行の前提・制約事項、要件を整理し、移行方法を選定する。 ② 設計・構築 ➢ 移行用の環境とツール、移行手順を設計、構築する。 ③ リハーサル ➢ 実環境を利用してリハーサルを行い、手順や移行体制（シフト等）をブラッシュアップする。 ① 本番切替 ➢ 検証した移行手順を本番で実施し、データを移行する。 １ 2 3 4
11. - 11 - ◼ データ移行の前提・制約事項、要件を整理する。 ◼ データ移行の前提・制約事項になるもの ➢ PJの目的 • PJの目的がコスト圧縮であった場合、PJ達成による効果を最大化するため、コストをなるべく抑えるべき。 ➡ 現行資産を最大限に有効活用し、可能な限り追加のソフトウェア・ライセンス購入は回避。 ➢ システム停止の許容時間 • データの静止断面をつくるために、システム停止は大なり小なり発生。停止時間の精査が必要。 ➡ 業務を調整しても、半日～1日での本番切替完了は必須。データ移行に使える時間はもっと短い。 ➢ 移行元と移行先のシステム構成差分 • 移行元と移行先のDBや、同じDBを採用する場合でもそのバージョン差異の考慮が必要。 ➡ 移行前後で利用するDBは変わらず。バージョンもマイナーバージョンアップに留まったため、差分は少ない。 データ移行のステップ - 移行方法選定 -
12. - 12 - ◼ 「品質」「コスト」「移行時間」の観点で移行方法を選定する。 ➢ 品質 • 実績、情報量の多さや、サポート体制の充実度 ➢ コスト • 移行に伴って発生するハードウェア、ソフトウェア、ライセンスなどの購入費や開発工数 ➢ 移行時間 • データ移行にかかる所要時間 ◼ データ移行方法として、「バックアップデータ活用（物理バックアップ）」を選択。 データ移行のステップ - 移行方法選定 - No 移行方法の選択肢 例 品質 コスト 移行時間 1 クラウドベンダ移行ツール導入 AWS Data Migration Service AWS Snow Family 〇 〇 △ 2 DB純正移行ツール導入 Oracle Goldengate 〇 × ◎ 3 3rdパーティ移行ツール導入 Qlick Replicate（旧:Attunity Replicate） 〇 △ ◎ 4 バックアップデータ活用 物理バックアップ（RMANバックアップ、 アーカイブログバックアップ） ◎ 障害発生時に実績あり 情報も多数 ◎ 現行のバックアップ処理を 有効活用 〇 差分データの移行時間は かかるが許容範囲内 論理バックアップ（SQLダンプファイル） 〇 〇 △ ポイント① ポイント② ポイント③ 【再掲】DBデータ移行時のポイント
13. - 13 - 凡例 クラウド環境 オンプレミス環境 顧客データセンタ ◼ 移行用の環境とツール、移行手順を設計、構築する。 ➢ 現行本番環境や、移行先で先行して本番稼働するシステムへの影響を排除するため、移行用環境を構築。 ➢ 構成や手順はシンプル化＆自動化。 ➢ 移行時のみの環境になるため、固定費は削減するが、可用性はマネージドサービスを活用して担保。 データ移行のステップ - 設計・構築 - 移行元 移行先 本番DBサーバ 本番バックアップ 基盤 WAN網 ユーザー拠点 拠点 店舗 取引先 本番稼働後用 専用回線 移行用 専用回線 本番環境 本番DBサーバ 移行用環境 他システム サーバ群 セキュリティ基盤 中継サーバ マネージドサービスを 活用。コストをかけず 冗長化。 ・・・ 移行後の本番環境への通信経路 ・・・ データ移行の通信経路 ポイント① ポイント② ポイント③
14. - 14 - ◼ 実環境を利用してリハーサルを行い、手順や移行体制（シフト等）をブラッシュアップする。 ➢ 少しでもデータ移行時間を短くできる余地があれば、計画を大きく変えてでも検証する。 ➢ 業務移行や、システム移行の計画・手順との整合性や、他システムの計画・手順との整合性を確認・検証する。 ➢ リハーサルの工数は必要な工数。惜しまない。 データ移行のステップ - リハーサル - Aシステム 事前発注 事前データ移行 現行システム停止 最終断面移行・ バージョンアップ 新システム稼働 動作確認 移行後 整合性チェック 業務追いつき 通信経路切替、アプリ切替 Bシステム ・ ・ ・ データ移行 業務 移行 システム 移行 データ 移行 I/F連携再開 I/F停止 通信経路切替、アプリ切替 W時 X時 Y時 Z時 作業者：Aさん 確認者：Bさん 作業者：Eさん 確認者：Fさん V時 稼働後監視 稼働後監視 移行前チェック 作業者：Cさん 確認者：Dさん 作業者：Aさん 確認者：Bさん この部分を ブラッシュ アップ ポイント① ポイント② ポイント③
15. - 15 - ◼ ブラッシュアップした手順を（イレギュラーが発生しないことを祈りつつ）落ち着いてやるのみ。 ◼ 万が一、突発的な事態が起きたときは、まずは報告。落ち着いて対処する。 データ移行のステップ - 本番切替 -
16. - 16 - まとめ ◼ エンプラ系システムをクラウドリフトする際の、DBデータ移行で考えることは以下の3つ。 ポイント① いかに業務影響を回避して移行するか いかに確実にデータを移行するか いかに必要十分なコスト（工数・費用）で移行するか ポイント② ポイント③