セッションでお伝えすること - d1.awsstatic.com · 関連セッション: データベース移行アンチパターン現行db環境分析におけるアンチパターンとベストプラクティス

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

データベースの移行で考えなければならないこと

髙橋敏行

アマゾンウェブサービスジャパン

アライアンス技術本部パートナーソリューションアーキテクト

Twitterハッシュタグ #AWSInnovate


このセッションについて

• 対象

データベース移行に関わるエンジニア

• セッションでお伝えすること

• データベースの移行に関する考えるべきポイント

検討・検証内容

行うべきこと


自己紹介

髙橋敏行 (たかはしとしゆき)

技術統括本部パートナー技術本部

パートナーソリューションアーキテクト

主にパートナー様の育成・技術支援を担当

前職は外資系SW/HW/クラウドベンダーデータベースエンジニア

好きなAWSのサービス：Amazon RDS


Agenda

はじめに

データベース移行の全体像

移行の検討ポイントとタスク

データベース移行の支援策

まとめ



データベース移行の動機・きっかけ

• サーバーの保守切れ

• 運用コストの増加

• データセンターの見直し

• 他社事例から検討の必要など


データベース移行の動機・きっかけ

• サーバーの保守切れ

• 運用コストの増加

• データセンターの見直し

• 事例から検討の必要など


住信SBIネット銀行様：オンプレミスのOracle Database を Amazon Aurora へ移行

• 2019年3月4日 Webニュース• Oracle Database 11g 3ノードRAC から、

Amazon Aurora PostgreSQL 10 への移行を決定

• 機能/非機能/移行の観点で予備検討実施

• アプリケーションの書き換えにはコストがかかるが、リリース後３年で回収可能

出典）https://www.netbk.co.jp/wpl/NBGate/i900500CT/PD/corp_news_20190304

https://japan.zdnet.com/article/35133723/

性能：ピーク時のスループットが最大５０％向上

可用性：障害時は３０秒でフェイルオーバーが完了

コスト：８３％のランニングコスト削減

https://www.netbk.co.jp/wpl/NBGate/i900500CT/PD/corp_news_20190304

https://japan.zdnet.com/article/35133723/


Amazon Aurora

クラウドにあわせて再設計された MySQL, PostgreSQL と互換性のあるRDBMS

コマーシャルデータベースの性能と可用性を1/10のコストで

耐障害性、自己修復機能を兼ね備えたストレージ; 3 つのAZにわた

り、6 個のコピーを保持;Amazon S3への継続的な

バックアップ

フルマネージド

RDSを使ったマネージドサービス: ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、構成、バックアップといった

管理タスクからの解放

高い安全性

ネットワーク分離、保管時/通信の暗号化

優れた性能と拡張性

標準的な MySQL と比べて 5 倍、標準的な PostgreSQL と比べて

3 倍のスループットを実現; リードレプリカを最大 15 個追加

してスケールアウト可能

高可用性と耐久性


移行にあたっての不安や悩み

• データベースの移行に関して何を検討するのか

• 実際にどのような検証を行えばよいか

• 移行のために何を行わなければならないか



データベース移行のプロセス

検討設計変換移行運用最適化




机上検討やPoC机上の検討、PoCを通してDBマイグレーションが妥当かを検討

設計移行方式の設計や移行後の環境の設計を行う

変換SQLの抽出、書き換えを行い、単体テスト、結合テスト、総合性能試験を実施

移行移行テストを実施の上、データの移行と切り替え作業を行う

運用移行終了後のデータベースの運用

最適化キャパシティの見直し、コスト最適化など運用改善の実施

データベース移行アンチパターンその1北澤英崇（ソリューションアーキテクト）

移行要件と移行手法

データベース移行アンチパターンその2畔勝洋平（コンサルタント）

比較と検証

本セッション


関連セッション : データベース移行アンチパターン

現行DB環境分析におけるアンチパターンとベストプラクティス

その1

その2

データ移行方式選定におけるアンチパターンとべストプラクティス

DBエンジン選定におけるアンチパターンとべストプラクティス

PoCにおけるアンチパターンとベストプラクティス

北澤英崇

（ソリューション

アーキテクト）

移行要件と移行手法

畔勝洋平

（コンサルタント）

比較と検証



検討フェーズ


検討フェーズの概要

• 机上検討やPoCを実施

• 机上の検討、PoCを通してデータベース移行が妥当かを検討

机上検討

PoC + 工数見積もり

移行判断


移行判断までの流れ

机上検討移行先のクラウド環境で現行システムの要件が満たせるか、また、移行が実行可能なのかを机上で評価する。ノックアウト要素がないかを洗い出すのが重要な目的

PoC + 工数見積もり机上検討できない評価(性能)や、机上検討で洗い出されたリスク、実現性について実機検証を行う

机上検討とPoCの結果とコストを評価し、移行を実施するかを判断する

移行判断


データベース移行時の検討項目

性能• 現状の性能を維持

or 要件の見直し

• 費用への影響

可用性• 現状の可用性を維持

or 要件の見直し

• 費用への影響

移行性• エンジン変更の有無

• 停止可能な時間

コスト• ライセンスコスト

• インフラコスト

• 移行コスト

• 運用コスト


机上検討フェーズのタスクと流れ

情報収集

ヒアリング

現行環境情報収集現行DB環境分析

移行先環境のアーキテクチャ設計

設計・分析評価

移行先構成評価(ノックアウト評価)


机上検討フェーズのタスクタスク実施すること

要件ヒアリング制限事項、機能要件、非機能要件移行要件、運用要件をヒアリング

現行環境情報収集 OS情報、DB性能情報 (例: AWR、ASH)、DB設計書、データディクショナリ情報、システム構成情報、ネットワーク構成情報、運用設計書、運用コスト情報を収集

現行DB環境の分析 • 性能分析• DB製品の固有機能を使っているかの確認

移行環境のアーキテクチャ設計 • 移行先環境のデータベースエンジン候補• 移行先環境のアーキテクチャ検討• 移行方式の事前検討

非互換調査 • 現行アプリケーションの実行SQLの収集• SQL変換ツールによる自動変換率確認• エンジン変更に伴うアプリ書き換え範囲の調査

移行先構成の評価移行先環境のアーキテクチャがシステム要件を満たすか、実行可能性があるかを机上検討の範囲内で評価(ノックアウト評価)

情報収集

設計・分析

評価


机上検討フェーズのタスクの流れ

情報収集

ヒアリング






机上検討フェーズのタスクの流れ

情報収集

ヒアリング




ノックアウト要素がなければ PoC へ


運用要件移行要件

現行性能情報性能分析

製品固有機能利用確認

データベースエンジン選定新環境のアーキテクチャ設計

移行方式の事前検討

運用コスト情報・運用手順書

機能・非機能要件

構成情報・設計書

• AWS上で十分なリソースが確保できるか

• 各種要件が満たせるか機能要件可用性要件運用要件セキュリティ要件移行要件


PoC フェーズ


PoCフェーズのタスク

• データ移行検証

• SQL の書き換えと動作確認

• SQL 性能検証


PoCフェーズの検討ポイント

• データ移行検証

一部データの移行を試行

データが移行でき、移行前後でデータが一致するかどうかを確認

• SQL の書き換えと動作確認

SQL をサンプリングし、書き換え実施

SQL を実行し、正常終了するか、結果が同じか確認

• SQL 性能検証

SQL をサンプリングし、単体の実行性能を比較

一部アプリケーションのワークロードを負荷ツールで再現して、レスポンスとスループットを比較


設計フェーズ


移行設計フェーズのタスク

• 移行方式の策定

• 移行の詳細設計の策定

移行先システム設計

運用設計移行設計


移行設計フェーズの検討ポイント

• 移行方式の策定

• 停止時間データ移行時に移行元環境を停止することができるか、

稼働させたままにするのか

• 移行方法データを一括移行するか、

初期データ移行+差分データ移行とするか

• 切り戻し切り戻しを考慮する場合、

新環境のトランザクションを旧環境へどう反映させるか


移行方法の選択肢

十分な停止時間を取れるダンプツール

CSV アンロード

レプリケーション

AWS DatabaseMigration Service

ソースとターゲットが同一DBエンジン

ソースとターゲットが同一DBエンジン

DB純正のレプリケーションが

組める

はいはい

いいえいいえ

はいはい

いいえいいえ


AWS Database Migration Service (DMS)

既存のデータベースを最小限のダウンタイムでマイグレーションするサービス

同種はもちろん異種プラットフォームの移行にも対応

オンプレミスDB

DB on EC2

RDS

オンプレミスDB

DB on EC2

RDS

※オンプレミス to オンプレミスは非対応

DMS

S3


移行設計フェーズの検討ポイント

• 移行の詳細設計の策定

手順の作成

移行リハーサルの計画• テスト環境の移行手順の確認

• 本番環境を使用した移行のリハーサルを実施

• 運用設計の策定

手順の作成


変換フェーズ


変換フェーズのタスクと検討ポイント

• アプリケーションの書き換え自動変換ツールを利用した効率化の検討

• エンジン変更時の非互換ホワイトペーパーを活用した調査工数の削減

テストデータ準備SQLの抽出/書換え

単体テスト/結合テスト

総合性能テスト


移行支援ツール : AWS Schema Conversion Tool (SCT)

ソースDBのスキーマ、ビュー、

ストアドプロシージャ、

ファンクションの大部分を

自動的にターゲットDB

互換フォーマットに変換できる

無償のデスクトップアプリケーション


ホワイトペーパー : Database Migration Playbook

DBオブジェクトごとにどのように移行すれば良いかが記載された移行のベストプラクティス集

• Oracle to Amazon Aurora PostgreSQL

• Oracle to Amazon Aurora MySQL

• Oracle to Amazon Redshift

• SQL Server to Aurora MySQL

• SQL Server to Aurora PostgreSQL

https://aws.amazon.com/jp/dms/resources/

https://aws.amazon.com/jp/dms/resources/


変換フェーズのタスクと検討ポイント

• 単体テスト/結合テスト

• [DBエンジン変更を伴う場合] 注意するポイント

正常終了するか

期待される結果となるか (移行前後で異なる結果ではないか)

• 総合性能テスト• 注意するポイント

バッチ処理重要なバッチ処理がバッチウィンドウに収まるか

OLTP処理の負荷、並列度がピーク時ワークロードを再現したものか


運用フェーズ


運用フェーズのタスクと検討ポイント

運用改善

AWSでは柔軟なスケールがすぐに行える• スケールアップ : インスタンスサイズのアップ

• スケールアウト : 読み取り専用インスタンス作成で負荷分散


データベース移行のタスクフローチャート


データベース移行のタスクフローチャート机上検討

PoC + 工数見積もり

移行判断

移行先システム設計

テストデータ準備

移行実装

運用設計SQLの抽出/書換え

単体テスト/結合テスト

総合性能テスト移行テスト

移行

運用

移行設計



一般的なデータベース移行の流れ

アセスメント PoC DB移行


あいまいに検討した移行方式

どのようなPoCを実施すれば良いのか分からない

アセスメント PoC DB移行

PoCしたのに、プロジェクトで問題発生


Database Freedom プログラム

商用DB製品からAWSサービスへの移行を支援するプログラム

• エキスパートによる現行DBのワークロード分析

• エキスパートによる移行方式候補の選定を支援するワークショップ開催

• AWS利用料金を一部補填するクレジットの提供


ワークショップが提供するもの

アセスメントワークショップ PoC DB移行

• 移行対象システムの選定

• AWRレポートの分析、サイジング

• AWS Schema Conversion Tool 評価レポートの分析

• 移行先DBエンジン候補の選定、Dive Deep セッションの提供

• 移行方式候補の選定（ツール、ダウンタイム、切り替え方式）

• 移行リスク、PoCすべき点の抽出


AWSの導入、お問い合わせ等のご相談

AWSクラウド導入に関するご質問、お見積、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談下さい。

https://aws.amazon.com/jp/contact-us/aws-sales/

※「AWS 問い合わせ」で検索して下さい

https://aws.amazon.com/jp/contact-us/aws-sales/





机上検討やPoC机上の検討、PoCを通してDBマイグレーションが妥当かを検討

設計移行方式の設計や移行後の環境の設計を行う

変換SQLの抽出、書き換えを行い、単体テスト、結合テスト、総合性能試験を実施

移行移行テストを実施の上、データの移行と切り替え作業を行う

運用移行終了後のデータベースの運用

最適化キャパシティの見直し、コスト最適化など運用改善の実施


関連セッション

ストレージとデータベース（30分）- AWSomeday Online高橋敏行（ソリューションアーキテクト）、平賀博司（テクニカルトレーナー）

10月1日より公開

データベース移行アンチパターンその1 （30分）北澤英崇（ソリューションアーキテクト）


データベース移行アンチパターンその2（30分）畔勝洋平（コンサルタント）


Thank you!


髙橋敏行

@YukkiTakahashi

#AWSInnovate

Thank you!


Event info - https://amzn.to/JPEvents

Webinar - https://amzn.to/JPWebinar

Archive - https://amzn.to/JPArchive

https://amzn.to/JPEvents

https://amzn.to/JPWebinar

https://amzn.to/JPArchive

Documents

セッションでお伝えすること - d1.awsstatic.com · 関連セッション: データベース移行アンチパターン 現行db環境分析におけるアンチパターンとベストプラクティス

セッションでお伝えすること - d1.awsstatic.com · 関連セッション: データベース移行アンチパターン現行db環境分析におけるアンチパターンとベストプラクティス