Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
FutureCon2022_DBのデータ移行って何するの?
Search
YamazakiYuki
July 19, 2022
Technology
0
430
FutureCon2022_DBのデータ移行って何するの?
DBのデータ移行って何するの?
エンタープライズ系システムをクラウドリフトするときに考えること
YamazakiYuki
July 19, 2022
Tweet
Share
Other Decks in Technology
See All in Technology
「ふりかえりのふりかえり」をふりかえり、実のあるふりかえりにする
naitosatoshi
0
220
コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える / Scalable and Secure Infrastructure as Code Pipeline for a Compound Startup
yuyatakeyama
3
2.5k
〜小さく始めて大きく育てる〜データ分析基盤の開発から活用まで
kniino
0
2k
アクセシビリティを考慮したUI/CSSフレームワーク・ライブラリ選定
yajihum
0
160
HEXA OSINT CTF V3 作戦会議
meow_noisy
0
110
巨大なテーブルのテーブル定義を無停止で安全に誰でも変更できるようにする / Table-definitions-for-huge-tables-can-be-modified-by-anyone-safely-and-non-disruptively
freee
1
740
疲弊しない!AWSセキュリティ統制の考え方 #devio_osakaday1
masahirokawahara
6
5.9k
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
24
5.2k
小さな開発会社がWebサービスを作る理由
polidog
PRO
1
160
ユーザーストーリーのレビューを自動化したみたの
bun913
1
330
[PlatformCon 24] Platform Orchestrators: The Missing Middle of Internal Developer Platforms?
danielbryantuk
1
180
Databricksを活用してDELISH KITCHENのレシピレコメンドを開発した話
furu8
0
250
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
76
41k
Producing Creativity
orderedlist
PRO
336
39k
KATA
mclloyd
14
12k
Building a Modern Day E-commerce SEO Strategy
aleyda
16
6.4k
Building Your Own Lightsaber
phodgson
98
5.7k
Raft: Consensus for Rubyists
vanstee
132
6.2k
Testing 201, or: Great Expectations
jmmastey
27
6.3k
BBQ
matthewcrist
80
8.7k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
Web Components: a chance to create the future
zenorocha
305
41k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
The Illustrated Children's Guide to Kubernetes
chrisshort
29
46k
Transcript
- 1 - FutureCon 2022 DBのデータ移行って何するの? エンタープライズ系システムを クラウドリフトするときに考えること
- 2 - 自己紹介 山崎 悠希 Yamazaki Yuki ◼ 経歴
2016年 フューチャー株式会社に新卒入社。 新人研修を経て、流通小売系プロジェクトに配属。アプリ開発とデータベース運用を担当。 その後、2019年~2021年の2年間、大規模クラウドリフト案件でデータ移行リーダーを経験。 ◼ 関連キーワード #データベース #流通小売 #クラウド #データ移行 #海外旅行 #日曜農家
- 3 - 本日、お伝えしたいこと ◼ エンタープライズ系(以下、エンプラ系)システムのクラウドリフト案件で、 はじめてDBのデータ移行を任された際に、何を考えればいいのか。 何が重要な 観点なの? どういったことを
やらないといけ ないの? こういう観点が 大事なのね!
- 4 - アジェンダ 1. 移行とは 2. 移行の種類 3. エンプラ系システムのDBデータ移行で考えること
4. 移行のステップ 1. 移行方法選定 2. 設計・構築 3. リハーサル 4. 本番 5. まとめ
- 5 - 移行とは ◼ 現行と新のギャップをどのように登るか。 現行 新 = 登り方
移行 経営・業務改革 × IT改革
- 6 - 移行の種類 ◼ 移行は、「業務移行」「システム移行」「データ移行」の3種類に分解できる。 現行 新 現行業務 現行システム+周辺
現行データ 新業務 新システム+周辺 新データ 業務 移行 システム 移行 データ 移行
- 7 - 【補足】クラウドリフトとは ◼ 既存のオンプレミス環境で運用しているシステムをそのままクラウドに移行すること。 ➢ クラウドを活用したシステムにしていく上での最初のステップ。 クラウドリフト •
IaaS活用 • 物理機器の撤廃 クラウドネイティブ • サーバレス化 • マイクロサービス • IaC導入 クラウドシフト • マネージドサービス活用 • 商用ソフトウェア置換え 本日のスコープ
- 8 - 私がやったこと ◼ 大手スーパーのクラウドリフト案件でエンプラ系システムのDBデータ移行をリーディング。 ➢ DB運用をやっていた経験から自ら手を挙げ立候補 → アサイン。
➢ 対象のDBは24/365稼働、顧客のビジネスの根幹を支える全データを管理。 • 商品情報や店舗情報などのマスタデータ全般 + 受発注、売上仕入や物流、メーカーや取引先など、外部や周辺 システムへのI/Fなどのトランデータの管理 + 情報分析基盤の分析結果データを管理。 ➢ 総データ量は数十TB。1日のデータ更新量は数TBと、かなり大きな規模。
- 9 - エンプラ系システムのDBデータ移行で考えること ◼ エンプラ系システムをクラウドリフトする際の、DBデータ移行で考えることは以下の3つ。 ポイント① いかに業務影響を回避して移行するか いかに確実にデータを移行するか いかに必要十分なコスト(工数・費用)で移行するか
ポイント② ポイント③
- 10 - データ移行のステップ ◼ エンプラ系DBのデータ移行のステップは以下の4つ。 ① 移行方法選定 ➢ データ移行の前提・制約事項、要件を整理し、移行方法を選定する。
② 設計・構築 ➢ 移行用の環境とツール、移行手順を設計、構築する。 ③ リハーサル ➢ 実環境を利用してリハーサルを行い、手順や移行体制(シフト等)をブラッシュアップする。 ① 本番切替 ➢ 検証した移行手順を本番で実施し、データを移行する。 1 2 3 4
- 11 - ◼ データ移行の前提・制約事項、要件を整理する。 ◼ データ移行の前提・制約事項になるもの ➢ PJの目的 •
PJの目的がコスト圧縮であった場合、PJ達成による効果を最大化するため、コストをなるべく抑えるべき。 ➡ 現行資産を最大限に有効活用し、可能な限り追加のソフトウェア・ライセンス購入は回避。 ➢ システム停止の許容時間 • データの静止断面をつくるために、システム停止は大なり小なり発生。停止時間の精査が必要。 ➡ 業務を調整しても、半日~1日での本番切替完了は必須。データ移行に使える時間はもっと短い。 ➢ 移行元と移行先のシステム構成差分 • 移行元と移行先のDBや、同じDBを採用する場合でもそのバージョン差異の考慮が必要。 ➡ 移行前後で利用するDBは変わらず。バージョンもマイナーバージョンアップに留まったため、差分は少ない。 データ移行のステップ - 移行方法選定 -
- 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 - 凡例 クラウド環境 オンプレミス環境 顧客データセンタ ◼ 移行用の環境とツール、移行手順を設計、構築する。 ➢
現行本番環境や、移行先で先行して本番稼働するシステムへの影響を排除するため、移行用環境を構築。 ➢ 構成や手順はシンプル化&自動化。 ➢ 移行時のみの環境になるため、固定費は削減するが、可用性はマネージドサービスを活用して担保。 データ移行のステップ - 設計・構築 - 移行元 移行先 本番DBサーバ 本番バックアップ 基盤 WAN網 ユーザー拠点 拠点 店舗 取引先 本番稼働後用 専用回線 移行用 専用回線 本番環境 本番DBサーバ 移行用環境 他システム サーバ群 セキュリティ基盤 中継サーバ マネージドサービスを 活用。コストをかけず 冗長化。 ・・・ 移行後の本番環境への通信経路 ・・・ データ移行の通信経路 ポイント① ポイント② ポイント③
- 14 - ◼ 実環境を利用してリハーサルを行い、手順や移行体制(シフト等)をブラッシュアップする。 ➢ 少しでもデータ移行時間を短くできる余地があれば、計画を大きく変えてでも検証する。 ➢ 業務移行や、システム移行の計画・手順との整合性や、他システムの計画・手順との整合性を確認・検証する。 ➢
リハーサルの工数は必要な工数。惜しまない。 データ移行のステップ - リハーサル - Aシステム 事前発注 事前データ移行 現行システム停止 最終断面移行・ バージョンアップ 新システム稼働 動作確認 移行後 整合性チェック 業務追いつき 通信経路切替、アプリ切替 Bシステム ・ ・ ・ データ移行 業務 移行 システム 移行 データ 移行 I/F連携再開 I/F停止 通信経路切替、アプリ切替 W時 X時 Y時 Z時 作業者:Aさん 確認者:Bさん 作業者:Eさん 確認者:Fさん V時 稼働後監視 稼働後監視 移行前チェック 作業者:Cさん 確認者:Dさん 作業者:Aさん 確認者:Bさん この部分を ブラッシュ アップ ポイント① ポイント② ポイント③
- 15 - ◼ ブラッシュアップした手順を(イレギュラーが発生しないことを祈りつつ)落ち着いてやるのみ。 ◼ 万が一、突発的な事態が起きたときは、まずは報告。落ち着いて対処する。 データ移行のステップ - 本番切替
-
- 16 - まとめ ◼ エンプラ系システムをクラウドリフトする際の、DBデータ移行で考えることは以下の3つ。 ポイント① いかに業務影響を回避して移行するか いかに確実にデータを移行するか いかに必要十分なコスト(工数・費用)で移行するか
ポイント② ポイント③
None