MigrationFromCommercialDB

Size: px

Start display at page:

Download "MigrationFromCommercialDB"

よりおさだい
4 years ago
Views:

商データベースから PostgreSQL への移の勘どころアマゾンウェブサービスジャパン株式会社データベースソリューションアーキテクト柴典 2017 年 7

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

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

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

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

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

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

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

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

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

11 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 移を前提としているため商データベースにない機能は記載省略 *2 Block Nested Loop 結合と Batched Key Access 結合を含む *3 PK UNIQUE FK は定義できるが強要されない

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

13 パフォーマンスデータコレクションから現ワークロードを評価短時間の SQL が量に流れているのか時間の SQL が少量流れているのかを極めるクエリ統計の履歴レポートを調査総実時間ごとの上位クエリの実ごとの平均実時間実ごとの平均実時間が短い = 短時間の SQL が量実ごとの平均実時間がい = 時間の 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 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 サポート

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

17 移中もアプリケーションは稼働したままオンプレミス商 DB インターネット or VPN or Direct Connect DMS Aurora 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 商データベースとの違いのアジェンダ 1. オブジェクトの主な違い 2. SELECTでの主な違い 3. DMLでの主な違い 4. 構築と運

24 ここからの前提選択バイアスが掛かっているだけなのでご安ください SCT や DMS 動化できない部分または注意を要する部分だけを抽出しています商 DB にはないが 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 シーケンス列の属性オブジェクトマテリアライズドビューフルリフレッシュデータベースリンク *3 パーティショニング RANGE LIST ゾーンマップ NOT NULL *2 ストアドプロシージャストアドルーチン PL/pgSQL など Python *1 移を前提としているため商 DB にない機能は記載省略 *2 PK UNIQUE FK は定義できるが強要されない *3 Aurora ではない MySQL の場合は FEDERATED エンジンで代替可能 : ほぼ同様の機能があるもの

28 PostgreSQL のシーケンスオブジェクトとして実装されている CREATE SEQUENCE seq...; PK として使う場合 nextval 関数の戻り値を INSERT する INSERT INTO t VALUES (nextval('seq'), value); 現在の値を取得したい場合 currval 関数を使う SELECT currval('seq'); 参考 :

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 PostgreSQL のパーティショニング RANGE LIST サブパーティションには対応 EXCHANGE / SWITCH には対応参考 :

33 PostgreSQL のストアドプロシージャ PostgreSQL の PL/pgSQL は PL/SQL や T-SQL に似ているが完全に同じではない参考 : PostgreSQL 書 : Oracle PL/SQL からの移植 Aurora PostgreSQL は 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 SQL Server PostgreSQL 空字は NULL と同じ id=1 が返る NULL と空字を区別する id=1 は返らない

38 NULL と空字の扱いの違い (2/2) 1. SELECT NULL 'aws' FROM t1; 2. SECLECT CONCAT(NULL, 'aws') FROM t1; Oracle Database NULL は空字と同じ aws が返る SQL Server 1. ではなく + 2. CONCAT は NULL が返る COALESCE で対策 PostgreSQL Redshift 1. は NULL が返る COALESCE で対策 2. CONCAT は aws が返る

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 SQL Server 2. awscloud 3. LEN() で 3

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

41 完全外部結合を使った MERGE 文の書き換え Oracle SQL Server 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 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 には対応 SQL Server デフォルトは READ COMITTED 4 つの分離レベルをすべてサポート

44 トランザクション分離レベル (2/2) PostgreSQL デフォルトは READ COMMITTED 4 つの分離レベルをすべてサポート MySQL (InnoDB) デフォルトは REPEATABLE READ Phantom Read は発しない READ COMMITTED でも Non Repeatable Read (Fuzzy Read) は発しない参考 :

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

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

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

48 構築と運

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

50 まとめ

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

52 商データベースからの移事例まもなくオンライン公開予定

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