AquaSystems-DBMigration

Size: px

Start display at page:

Download "AquaSystems-DBMigration"

れいがすみだ
5 years ago
Views:

2 内容についての注意点本資料では 2017 年 9 5 時点のサービス内容および価格についてご説明しています最新の情報は AWS 公式ウェブサイト ( にてご確認ください資料作成には分注意しておりますが資料内の価格と AWS 公式ウェブサイト記載の価格に相違があった場合 AWS 公式ウェブサイトの価格を優先とさせていただきます価格は税抜表記となっています本居住者のお客様が東京リージョンを使する場合別途消費税をご請求させていただきます AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

3 紹介柴典 [ シバタツ ] データベース関連の相談ごと何でも担当 AWS への移を機に Aurora や Redshift に乗り換えたいオンプレミス商 DB 製品を AWS にフォークリフティングしたい好きな AWS のサービス : Aurora Redshift DMS

4 オンプレミスデータベースの移とは EC2 上にお客様が構築する AWS が提供するマネージド型 DB サービスを利する DB エンジンも変更してマネージド型 DB サービスを利するオンプレミス

5 データベースエンジンを変更せずに AWS に移したいお客様の声クラウドにシステム全体を移するためデータベースもクラウドに移したい障害復旧やパッチ適などの管理の間を減らしたいなどなど

6 データベースエンジンを変更して AWS に移したいお客様の声クラウドにシステム全体を移するのであれば RDBMS もクラウドネイティブなものにしたい RDBMS もオートスケールさせたいが商 DB が CPU ライセンスだとそれができない IT 予算の多くを商 DB ライセンスが占めているなどなど

7 移にあたっての不安や悩み業務部 / アプリ開発部アプリケーションへの影響はどれくらいあるのだろうか移のための業務停はできるだけ短くしたい IT 部 / インフラ管理部業務部に何をガイドしてよいのか分からない従来の管理法がどう変わるのだろうか移のための費はあまりかけたくない

8 移にあたって決めなくてはいけないこと 1. What? 対象システムは? 4. Where? 移先は? 2. Why? 移理由は? 3. How? 移戦略は? 5. When? 期限は? 6. Who? 担当者は?

9 AWS の考えるクラウドへの 6 つの移戦略 (1/3) Re-Host ホスト変更サーバーやアプリケーションをオンプレミス環境からクラウドにそのまま持ってくる Re-Platform プラットフォーム変更クラウド移の環としてプラットフォームのアップグレードをなうオンプレミスの PostgreSQL をそのまま EC2 に持ってくるオンプレミスの MySQL 5.5 を EC2 に構築した 5.6 に移する

10 AWS の考えるクラウドへの 6 つの移戦略 (2/3) Re-Purchase 買い換えクラウド対応したライセンスまたはアプリケーションに買い換える Refactor 書き換えクラウド環境で最適に動作するようにアプリケーションを書き換えるオンプレミスの Oracle をライセンス込みの RDS for Oracle に買い換えるオンプレミスの SQL Server を Aurora や Redshift に変更する

11 AWS の考えるクラウドへの 6 つの移戦略 (3/3) Retire 廃サーバーやアプリケーションを廃する Retain 保持オンプレミス環境を引きつづき使する平運していた古いシステムを DB ごとこのタイミングで廃する Oracle9i に依存しているアップグレードできないパッケージアプリケーションがある

12 クラウド移戦略を移の複雑さで較低い Retain 保持移の複雑さ Retire 廃 Re-Host ホスト変更 Re-Purchase 買い換え Re-Platform プラットフォーム変更い Refactor 書き換え

13 移にあたって決めなくてはいけないこと 1. What? 対象システムは? 4. Where? 移先は? 2. Why? 移理由は? 3. How? 移戦略は? 5. When? 期限は? 6. Who? 担当者は?

14 3 つの RDBMS の特性概要 Aurora MySQL Aurora PostgreSQL Redshift OLTP 性能 - OLAP 性能 - 標レスポンス時間数ミリ秒から数秒数ミリ秒から数分数秒から数時間結合法 *1 ネステッドループ *2 インデックス *1 制約 *1 B ツリー空間全 NOT NULL PK UNIQUE FK ネステッドループハッシュソートマージ B ツリー関数空間全ゾーンマップ NOT NULL PK UNIQUE FK CHECK ハッシュソートマージゾーンマップ NOT NULL *3 *1 移を前提としているため Oracle Database にない機能は記載省略 *2 Block Nested Loop 結合と Batched Key Access 結合を含む *3 PK UNIQUE FK は定義できるが強要されない

15 Statspack/AWR から現ワークロードを評価短時間の SQL が量に流れているのか時間の SQL が少量流れているのかを極める SQL ordered by Elapsed Time を調査 Elapsed Time は期間中の合計時間 Elapsed Time per Exec が短い = 短時間の SQL が量 Elapsed Time per Exec がい = 時間の SQL が少量 MySQL PostgreSQL Redshift ミリ秒秒数秒分数分時間

16 移にあたって決めなくてはいけないこと 1. What? 対象システムは? 4. Where? 移先は? 2. Why? 移理由は? 3. How? 移戦略は? 5. When? 期限は? 6. Who? 担当者は? 期限と担当者を決めるには数積もりが必要数 = 移先との違いの量

17 AWS が提供する移援サービス計画移運ディスカバリー設計変換移運最適化 AWS TCO Calculator AWS Application Discovery Service VM Import/Export AWS Server Migration Service AWS Database Migration Service AWS Schema Conversion Tool AWS Storage Gateway AWS Snowball VMware on AWS AWS CloudWatch AWS Config AWS CloudFormation AWS CloudTrail AWS Service Catalog AWS Trusted Advisor AWS サポート

18 AWS Database Migration Service とは既存のデータベースを最限のダウンタイムでマイグレーションするサービス同種はもちろん異種プラットフォームの移にも対応オンプレミス DB DB on EC2 DMS オンプレミス DB DB on EC2 RDS RDS S3 オンプレミス to オンプレミスは対応

19 移中もアプリケーションは稼働したままオンプレミス Oracle インターネット or VPN or Direct Connect DMS Aurora / Redshift 1. DMS を準備 2. DMS がソース DB とターゲット DB に接続 3. 対象のテーブルスキーマなどを選択アプリケーションユーザー 4. DMS がテーブルを作成しデータをロードしレプリケーション開始 5. 任意のタイミングでアプリケーションをターゲット DB 側に切り替え

20 AWS Database Migration Service の特徴最限のダウンタイムオンラインでの継続的レプリケーション対応簡単なセットアップソース DB への変更はほぼ不要使が簡単 MC で数回クリックするだけい信頼性マルチ AZ 可能なインスタンス豊富な対応プラットフォーム Oracle, Microsoft SQL Server, SAP ASE, MySQL, MariaDB, PostgreSQL, Aurora, Redshift, S3, MongoDB, DynamoDB 低コスト c4.large インスタンスで 0.196USD/ 時間

21 AWS Schema Conversion Tool とはソースDBのスキーマビューファンクションストアドプロシージャの部分を動的にターゲットDB 互換フォーマットに変換できるデスクトップアプリケーション

22 AWS Schema Conversion Tool の特徴動変換の補助動変換できない個所とその理由を明アプリケーション SQL に対応アプリケーションソースコードをスキャンして変換評価レポートの作成何割のオブジェクトが動変換可能かなどの PDF レポートを数クリックで作成でき変換数の事前積もりを補助豊富な対応プラットフォーム Oracle, Microsoft SQL Server, Teradata, Netezza, Greenplum, Vertica, MySQL, MariaDB, PostgreSQL, Aurora, Redshift

23 同種 DB 間でダウンタイムを最限に移ソース : オンプレミス EC2 RDS 上の Oracle AWS Database Migration Service ターゲット : RDS 上の Oracle ソース : オンプレミス EC2 RDS 上の MySQL AWS Database Migration Service ターゲット : Amazon Aurora

24 異なる DB 間でダウンタイムを最限に移ソース : オンプレミス EC2 RDS 上の Oracle AWS Schema Conversion Tool ターゲット : Amazon Aurora ソース : オンプレミス EC2 RDS 上の Oracle AWS Database Migration Service ターゲット : Amazon Aurora

25 データベースの統合ソース : オンプレミス EC2 RDS 上の複数の MySQL AWS Database Migration Service ターゲット : Amazon Aurora

26 継続的なデータレプリケーションソース : Amazon Aurora AWS Database Migration Service ターゲット : 異なるリージョンの Aurora テスト Aurora オンプレミス MySQL

27 AWS Database Migration Service 詳細

28 対応データベース詳細プラットフォームソースターゲット Oracle Database 10g R2, 11g, 12c 10g, 11g, 12c Microsoft SQL Server 2005, 2008, 2012, , 2008, 2012, 2014 SAP ASE 15.7 以降 15.7 以降 MySQL / MariaDB / Aurora 5.5 以降 5.5 以降 PostgreSQL 9.4 以降 9.3 以降 Redshift - すべて S3 - すべて MongoDB 2.6.x, 3.x - DynamoDB - すべて

29 設定の流れ 1. DMS インスタンスの作成 2. エンドポイントの設定 3. タスクの定義インスタンスサイズ VPC マルチ AZ パブリックアクセス ( ストレージサイズサブネットグループ AZ セキュリティグループ KMS キー ) ソースとターゲットそれぞれの RDBMS プラットフォームホスト名ポート SSL 有効無効ユーザー名パスワード移タイプ ( ターゲットテーブルが存在していた場合 LOB 対応最 LOB サイズログの有効化 ) 実

30 移タイプ既存のデータを移する (FullLoad) 現時点でソース DB にっているすべてのデータをターゲット DB に移するデータ変更のみをレプリケートする (Change Data Capture / CDC) ソース DB に対する変更データをキャプチャしターゲットに適するアプリケーションは稼働したまま移可能既存のデータを移して継続的な変更をレプリケート

31 FullLoad の仕組みターゲットが Redshift 以外 1. DMS インスタンスがソース DB から 8 テーブル並列に各テーブルから 1 万ずつ SELECT 2. 必要に応じて DMS インスタンスがデータを変換しターゲット DB に INSERT メモリーだけで処理しきれない場合は DMS インスタンスの EBS がスワップ領域として使われるがく 1 万 8 テーブルが DMS インスタンスのメモリーサイズを超える場合は読み取り数単位をさくデフォルト値でありユーザーが変更可能

32 Redshift への FullLoad の仕組み 1. DMS インスタンスがソース DB から 8 テーブル並列に各テーブルから 1 万ずつ SELECT 2. DMS インスタンスが必要に応じてデータを変換し Amazon S3 の専バケットに CSV として出 3. CSV ファイルが 1MB に達したら Redshift が S3 から COPY( ロード ) Redshift 中は COPY 時にテーブル単位で排他ロックを取る点に注意デフォルト値でありユーザーが変更可能

33 S3 as a Target を使した法 1. DMS インスタンスがソース DB から 8 テーブル並列に各テーブルから 1 万ずつ SELECT 2. DMS インスタンスが必要に応じてデータを変換し Amazon S3 に CSV として出 3. ユーザーが任意のタイミングで COPY または Spectrum を使して INSERT SELECT INSERT SELECT 時に ELT が可能デフォルト値でありユーザーが変更可能

34 CDC の仕組み 1. DMS インスタンスがソース DB のトランザクションログ ( バイナリログ WAL REDO ログ ) を 5 秒間隔でキャプチャ 2. DMS インスタンスが SQL に変換しトランザクション COMMIT 順にターゲット DB に実 3. ターゲット DB に接続できない遅い場合 or FullLoad が完了していない場合は DMS インスタンス内にキューイング

35 FullLoad と CDC を組み合わせた場合の動作 1. FullLoad 中のソースへの更新をキャプチャ 2. FullLoad が完了したテーブルごとにキューイングしていた 1. の更新を適 3. すべてのテーブルの FullLoad 完了後は単のテーブルの更新ではなくトランザクションとして更新を適

36 移時のソース DB の停法 1. ソース DB の停準備ができたタイミングでソース DB にマーカーのトランザクションを INSERT INSERT INTO options VALUES ('the_end', 'true'); COMMIT; 2. ターゲット DB でマーカーの到着を確認 SELECT value FROM options WHERE key = 'the_end'; 3. 確認できればマーカー以前のトランザクションはすべてターゲット DB に適されていることが保証される

37 RDBMS 純正 CSV アンローダーと CDC の組み合せ 1. ソースDBへの書き込みを時停 2. 時 ( 秒まで ) をメモ 3. RDBMS 純正 CSVアンローダーでアンロード開始 4. ソースDBへの書き込みを再開 5. CSVアンロード完了 6. ターゲットDBへCSVロードを実の時を指定してCDC 開始

38 トランザクションログのキャプチャに必要な条件 Oracle Database ARCHIVELOGモード and FORCE LOGGING サプリメンタルロギング Microsoft SQL Server MySQL MS-Replication or MS-CDC binlog_format=row のバイナリログ PostgreSQL 論理レプリケーション

39 東京リージョンでの料インスタンス + t2.micro: 0.028USD/ 時から c4.4large: 1.564USD/ 時までの 8 種類マルチ AZ の場合は 2 倍ストレージ + データ転送 0.138USD/GB/ マルチ AZ の場合は 2 倍受信 : 無料同 AZ 内への送信 : 無料別 AZ への送信 : 0.010USD/GB 別リージョンへの送信 : 0.090USD/GB インターネットへの送信 : 0.14USD/GB 以下

40 各 RDBMS プラットフォームによる制限 AWS Database Migration Service ユーザーガイドをご確認ください

41 DMS 以外の移法分な停時間を取れるはいソースとターゲットが同 DB エンジンはいダンプツールシンプルいいえいいえ CSV アンロードシンプルソースとターゲットが同 DB エンジンはい DB 純正のレプリケーションが組めるはいレプリケーション速いいえいいえ AWS DMS 柔軟

42 AWS Schema Conversion Tool 詳細

43 対応データベース詳細ソース Oracle Database 10.2 以降 SQL Server 2008 以降 MySQL 5.5 以降 PostgreSQL 9.1 以降 Greenplum 4.3 以降 Netezza 以降 Teradata 13 以降 Vertica 以降ターゲット Aurora (MySQL PostgreSQL) MySQL Oracle PostgreSQL Redshift Aurora (MySQL PostgreSQL) SQL Server MySQL PostgreSQL Redshift Aurora (PostgreSQL) MySQL PostgreSQL Aurora (MySQL) MySQL PostgreSQL Redshift Redshift Redshift Redshift

44 設定の流れ 1. デスクトップ環境にインストール 2. ソース DB の設定 3. スキーマの選択 4. 評価レポートの確認 5. ターゲット DB の設定 Window, Mac, Fedora, Ubuntu + JRE 8u45 以降プロジェクト名 OLTP or DW RDBMS プラットフォームホスト名ポートユーザー名パスワード SSL 有効無効 JDBC ドライバーのパスなど RDBMS プラットフォームホスト名ポートユーザー名パスワード SSL 有効無効 JDBC ドライバーのパスなど

45 メインビュー

46 評価レポートビューの Action Items タブ

47 データ移ビュー DMS タスクの作成と制御が可能

48 評価レポートビュー (1/2)

49 評価レポートビュー (2/2)

50 アプリケーション SQL の変換 (+) 結合 ROWNUM 関数の多くなど

51 マッピングルールの作成 SCT のデフォルトマッピングルールを変更可能データタイプの変更 INTEGER NUMBER(10,0) NUMERIC(10,0) オブジェクトを別スキーマに移動オブジェクトの名称変更プレフィックスの追加削除置換サフィックスの追加削除置換データベーススキーマテーブル列単位で設定

52 データ移エージェントソース DB のデータを CSV 形式でアンロードするエージェント S3 にアップロードするまで Redshift へ COPY するまで動化することも可能アンロードしたファイルを Snowboll などで AWS へ DMS では時間が掛かりすぎる場合の代替案現在対応しているソース DB: Greenplum Netezza Oracle Teradata Vertica

53 まとめ : DMS と SCT と組み合わせた移の順 1. SCT でテーブル定義と PK 制約を移 2. DMS で FullLoad と CDC 開始 3. FullLoad 完了後にセカンダリインデックスを定義 4. CDCLatency がさくなったタイミングでアプリからの書き込み停 ( ダウンタイム開始 ) 5. マーカーをソース DB に INSERT 6. マーカーのターゲット DB 到着を確認 7. アプリがターゲット DB に接続 ( ダウンタイム終了 )

Presentation Title Here

Presentation Title Here AWS Black Belt Online Seminar AWS Database Migration Service アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト柴田竜典 2017.09.19 自己紹介柴田竜典 [ シバタツ ] データベース関連の相談ごと何でも担当 AWS への移行を機に Aurora や Redshift に乗り換えたいオンプレミス商用 DB 製品を