Oracle Database から Aurora & Redshift に移行するための実践ガイド

Size: px

Start display at page:

Download "Oracle Database から Aurora & Redshift に移行するための実践ガイド"

あいねたけすえ
6 years ago
Views:

Oracle Database から Aurora & Redshift に移行するための実践ガイドアマゾンウェブサービスジャパン株式会社柴田竜典

2 自己紹介柴田竜典シバタツデータベース関連の相談ごと何でも担当 AWSへの移行を機に RDBMSをAuroraに乗り換えたいオンプレミスOracleを AWSにフォークリフティングしたい好きなAWSのサービス:

3 Oracleからの移行を検討しているお客様の声クラウドにシステム全体を移行するのであれば RDBMSもクラウドネイティブなものにしたい RDBMSもオートスケールさせたいが CPUライセンスだとそれができない IT予算の多くを Oracleライセンスが占めているなどなど

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

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

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

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

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

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

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

11 本セッションでご紹介する移行先 Aurora MySQL RDS MariaDB PostgreSQL Oracle SQL Server Redshift on EC2 MySQL Compat. PostgreSQL Compat.

12 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 Oracle との文法互換性 *1 移行を前提としているため Oracle Database にない機能は記載省略 *2 Block Nested Loop 結合と Batched Key Access 結合を含む *3 PK UNIQUE FK は定義できるが強要されない

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

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

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

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

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

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

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

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

21 機械的に変換できるSQLはSCTで対応 (+) 結合 ROWNUM 関数の多くなど

評価レポート完全自動変換できるまたは手動変更工数ごとに色分けされたグラフなどを含んだレポート参考: https://www.slideshare.

22 評価レポート完全自動変換できるまたは手動変更工数ごとに色分けされたグラフなどを含んだレポート参考: auroraaws-database-migration-service-schema-conversion-tool

23 Oracle Database との違いのアジェンダ 1. オブジェクトの主な違い 2. SELECTでの主な違い 3. DMLでの主な違い 4. データの移行 5. 構築と運用

24 ここからの前提選択バイアスが掛かっているだけなのでご安心ください SCT や DMS 自動化できない部分または注意を要する部分だけを抽出しています Oracle Database にないが Aurora & Redshift にはある機能についてはこのセッションでは扱いません

25 Oracle RAC から Aurora MySQL への移行事例レコチョク様全サービスで横断して使用している 1000 万会員の DB DMS / SCT リリース前に手動で移行完了移行した結果 Aurora による障害はこれまでゼロ DB サーバー運用に工数をほとんど割かなくてよい性能は問題なし ( むしろ速くなった ) SlideShare: Oracle RAC から Aurora MySQL への移行

26 オブジェクトの主な違い

27 オブジェクトの主な違いインデックス *1 制約 *1 Aurora MySQL Aurora PostgreSQL Redshift B ツリー空間全文 NOT NULL PK UNIQUE FK B ツリー関数空間全文ゾーンマップ NOT NULL PK UNIQUE FK CHECK シーケンス AUTO_INCREMENT マテリアライズドビューフルリフレッシュデータベースリンク *3 パーティショニング RANGE LIST ゾーンマップ NOT NULL *2 ストアドプロシージャストアドルーチン PL/pgSQL など Python *1 移行を前提としているため Oracle Database にない機能は記載省略 *2 PK UNIQUE FK は定義できるが強要されない *3 Aurora ではない MySQL の場合は FEDERATED エンジンで代替可能 : ほぼ同様の機能があるもの

28 MySQL のシーケンス列に AUTO_INCREMENT 属性をつけその列に NULL または 0 を入れるまたは何も入れないとその列内の最大値 + 1 が入る CURRVAL に相当する値は LAST_INSERT_ID() 関数を使用直近の INSERT で採番された値を返す参考 :

29 PostgreSQL のマテリアライズドビューリフレッシュは手動のフルリフレッシュのみ読み取り専用のみ対応参考 :

30 PostgreSQLのデータベースリンク関数として実装されている SELECT * FROM dblink( 'dbname=mydb user=u1', 'select c1 from t1' ) AS t(c text); CREATE VIEW rt1 AS SELECT * FROM dblink('dbname=mydb', 'select c1 from t1') AS t(c text); 参考:

31 Redshift PostgreSQL の dblink Redshift dblink Aurora PostgreSQL アドホックな分析をする少数ユーザー用のデータウェアハウスとして Redshift を使用ダッシュボードを閲覧する多数ユーザー用のデータマートとして Aurora PostgreSQL を使用

32 MySQL と PostgreSQL のパーティショニング MySQL RANGE HASH LIST KEY PostgreSQL RANGE LIST サブパーティションと EXCHANGE は非対応参考 :

33 ストアドプロシージャ / ストアドファンクション PostgreSQL の PL/pgSQL と MySQL のストアドルーチンは PL/SQL に似ているが完全に同じではない参考 : PostgreSQL 文書 : Oracle PL/SQL からの移植 Redshift は Python によるストアドファンクションのみ Aurora MySQL Aurora PostgreSQL Redshift は Java プロシージャ非対応参考 :

34 SELECT での主な違い

35 互換性がないとどうなるのか A) 文法エラーになるエラーに地道に対応していけば良い B) 文法エラーが出ずに結果が異なる想定している結果なのかも評価しないと非互換に気づかないやっかいなのはパターン B 一連のバッチの最終結果しかなかったりするとどの SQL で結果が変わってしまったのか調査が非常に大変

36 結果相違を起こしやすい2大ポイント NULLと空文字の扱いの違い CHARの埋められた空白の扱いの違い

37 NULLと空文字の扱いの違い (1/2) INSERT INTO t1 (id, val) VALUES (1, ''); SELECT id FROM t1 WHERE val IS NULL; Oracle Database MySQL PostgreSQL Redshift 空文字はNULLと同じ id=1が返る NULLと空文字を区別する id=1は返らない '' でgrep

38 NULLと空文字の扱いの違い (2/2) 1. SELECT NULL 'aws' FROM t1; 2. SECLECT CONCAT(NULL, 'aws') FROM t1; Oracle Database PostgreSQL Redshift NULLは空文字と同じ awsが返る 1. はNULLが返る COALESCEで対策 2. CONCATはawsが返る MySQL 1. は論理OR演算子 2. CONCATはNULLが返る COALESCEで対策外部結合したあとのに特に注意

39 CHAR の末尾に埋められた空白の扱いの違い CREATE TABLE t1 (v char(5)); INSERT INTO t1 values ('aws'); 1. SELECT v 'cloud' from t1; 2. SELECT CONCAT(v, 'cloud') from t1; 3. SELECT LENGTH(v) from t1; Oracle Database 1. aws cloud 2. aws cloud 3. 5 PostgreSQL Redshift 1. awscloud 2. aws cloud 3. 3 MySQL 2. awscloud 3. 3 CHAR を CONCAT している部分に RPAD を追加 CONCAT(RPAD(v, 5, ' '), 'cloud')

40 その他の機械的に変更しにくい代表的な非互換 Aurora MySQL Aurora PostgreSQL Redshift 結合方法 *1 ネステッドループ *2 ネステッドループハッシュソートマージ MERGE ON DUPLICATE KEY ON CONFLICT ヒント句 *1 索引結合順序 *3 索引スキャン方法結合方式結合順序 *4 ハッシュソートマージウインドウ関数完全外部結合パラレル実行 SELECT *1 移行を前提としているため Oracle Database にない機能は記載省略 *2 Block Nested Loop 結合と Batched Key Access 結合を含む *3 MySQL 5.7 からスキャン方法や結合方法にも対応 *4 pg_hint_plan 拡張モジュールによってサポート : ほぼ同様の機能があるもの

41 完全外部結合を使った MERGE 文の書き換え Oracle Database MERGE INTO t1 USING t2 ON (t1.c1 = t2.c1) WHEN MATCHED THEN UPDATE SET t1.c2 = t2.c2 WHEN NOT MATCHED THEN INSERT (t1.c1, t1.c2) VALUES (t2.c1, t2.c2); PostgreSQL Redshift CREATE TABLE t1_new AS SELECT CASE WHEN t1.c1 IS NOT NULL THEN t1.c1 ELSE t2.c1 END c1, CASE WHEN t2.c1 IS NOT NULL THEN t2.c2 ELSE t1.c2 END c2 FROM t1 FULL OUTER JOIN t2 ON t1.c1 = t2.c1;

42 DML での主な違い

43 トランザクション分離レベル (1/2) Oracle Database デフォルトは READ COMMITTED READ UNCOMMITTED と REPEATABLE READ には非対応 MySQL (InnoDB) デフォルトは REPEATABLE READ Phantom Read は発生しない READ COMMITTED でも Non Repeatable Read (Fuzzy Read) は発生しない参考 :

44 トランザクション分離レベル (2/2) PostgreSQL デフォルトは READ COMMITTED 4 つの分離レベルをすべてサポート Redshift SERIALIZABLE のみその他の 3 つのレベルは設定可能だが SERIALIZABLE のエイリアスになっている参考 :

45 MySQL (InnoDB) 独自のロックレコードロック + ギャップロック = ネクストキーロック SELECT FOR UPDATE での範囲検索などの場合範囲外の次のキーまでロックする READ COMMITTED の場合ギャップロックは取得しない参考: /refman/ 5.6/ja/innodb-record-level-locks.html mysql_lock_r2.pdf SELECT id FROM t1 WHERE id BETWEEN 10 AND 20 FOR UPDATE; ギャップロック 40 レコードロック

46 PostgreSQL と Redshift の VACUUM (1/2) PostgreSQL と Redshift では DELETE された行と関連するインデックスの領域は即座には再利用されない PostgreSQL と Redshift では UPDATE は古い行の DELETE + 新しい行の INSERT として実行される DELETE / UPDATE が多いワークロードでは VACUUM コマンドによって不要な領域を解放する必要がある参考 :

47 PostgreSQL と Redshift の VACUUM (2/2) PostgreSQL VACUUM 排他ロックを取得しない OS には領域を戻さないデフォルトは自動実行 VACUUM FULL OS に領域を戻す排他テーブルロックを取得する IO 負荷が非常に高い Redshift VACUUM [FULL] 不要な領域の解放と未ソートデータのソート VACUUM DELETE ONLY 不要な領域の解放のみ VACUUM REINDEX インターリーブソートキーのメンテナンス IO 負荷が非常に高い

48 Aurora PostgreSQL のVACUUM Command: pgbench -i -s 2000 F 90 通常のPostgreSQLに比べて Aurora PostgreSQL のVACUUMは高速

49 構築と運用

50 マネージド型 RDBMS なので構築と運用は容易にインストール数クリックで完了災対サイト Redshift 除くセレクトボックスから選択するだけで複数 DC 冗長構成スケールアップ / スケールアウト数クリックで完了バックアップ / リストア 1 クリックでスナップショット取得 / 復旧ハードウェア障害起動しなおすだけで復旧バージョンアップセレクトボックスから選択するだけ参考 :

51 まとめ

52 移行にあたって決めなくてはいけないこと 1. What? 対象システムは? 2. Why? 移行理由は? スケーラビリティやコスト削減 3. How? 移行戦略は? リファクタリング 4. Where? 移行先は? SQL ordered by Elapsed Time 5. When? 期限は? 6. Who? 担当者は? 主な差分のご紹介

53 オンプレミスOracleからの移行事例 AWSパートナー事例大全集 Vol.2 にて 15社の移行事例が掲載パミール3Fの EXPO展示会場にて配布中

54 Amazon Web Services ブログで今すぐ公開 Oracle Database を Amazon Aurora に移行する方法オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行 oracle-database-from-on-premises-or-amazon-ec2- instances-to-amazon-redshift/

55 最後に移行するシステムの順序を決定する要素複雑かどうかミッションクリティカルかどうか得られる利益が大きいかどうかデータベースの移行で得られる利益は大きいお客様の実際のシステムを対象としたアセスメントや AWS パートナーのご紹介も可能ですのでいつでもご相談ください

56 Thank You! アマゾンウェブサービスジャパン株式会社柴田竜典シバタツ

57 本セッションの Feedback をお願いします受付でお配りしたアンケートに本セッションの満足度やご感想などをご記入くださいアンケートをご提出いただきました方にはもれなく素敵な AWS オリジナルグッズをプレゼントさせていただきますアンケートは受付パミール 3F の EXPO 展示会場内にて回収させて頂きます

58 AWS ソリューション Day 2017: Database Day - すでに始まっている! クラウドへのデータベース移行とデータレイクを軸としたビッグデータ活用 - Database Day とは? ユーザー企業 / パートナー / AWS による導入事例や活用動向また技術情報をご紹介する IT 部門 ( エンジニア / 管理者など ) 向けのカンファレンス開催日時 / 会場 2017 年 7 月 5 日 ( 水 ) 10:00-17:30 (9:30 開場予定 ) 大崎ブライトコアホール (JR 大崎駅より徒歩 5 分 ) セッション基調講演 + 2 トラック構成ブレイクアウトセッショントラック 1: データベース移行トラック 2: データレイクお申込み

MigrationFromCommercialDB

MigrationFromCommercialDB 商データベースから PostgreSQL への移の勘どころアマゾンウェブサービスジャパン株式会社データベースソリューションアーキテクト柴典 2017 年 7 5 #AWSDBDay 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 紹介柴典 [ シバタツ ] データベース関連の相談ごと何でも担当