【レポート】AWS Summit Tokyo 2017：Oracle Database から Aurora & Redshift に移行するための実践ガイド #AWSSummit

AWS Summit Tokyo 2017

#Oracle

#レポート

#Amazon Aurora

#Amazon Redshift

#AWS

甲木洋介

2017.06.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

aws-summit-tokyo-2017-longlogo 2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪品川プリンスホテルアネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年06月01日に行われた『Oracle Database から Aurora & Redshift に移行するための実践ガイド』の内容をレポートします。

AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

(2017/06/16追記：)イベント公式の関連資料及び動画が公開されました。

AWS Summit Tokyo 2017 セッション資料・動画一覧 | AWS
関連資料(PDF)：ダウンロード
関連動画(YouTube)：

セッション概要

セッション登壇者と概要は以下の通りです。

スピーカー：
柴田竜典
アマゾンウェブサービスジャパン株式会社
技術統括本部ソリューションアーキテクト

セッション概要：
現在は Oracle Database を使っているものの、クラウドネイティブな Amazon Aurora や Amazon Redshift への移行を検討しているお客様向けに、AWS のマイグレーションサービスによってどこまで移行が簡易化できるのか、そして AWS のサービス以外のところでは、どのような点に注意する必要があるのかについて実践的な内容をご紹介します。

セッションレポート

自己紹介

柴田竜典 [シバタツ] @rewse
データベース関連の相談事何でも担当

AWSへの移行を機にRDBMSをAuroraに乗り換えたい
オンプレミスOracle Database(以下Oracle)をAWSにフォークリフティング(後述)したい

好きなAWSのサービス：S3

Oracleからの移行を検討しているお客様の声

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

などなど

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

業務部門 / アプリ開発部門

アプリケーションへの影響はどれくらいあるのだろうか
移行のための業務停止はできるだけ短くしたい

IT部門 / インフラ管理部門

業務部門に何をガイドしてよいのか分からない
従来の管理手法がどう変わるのだろうか
移行のための費用はあまりかけたくない

移行にあたって決めなくてはいけないこと

What?(対象システムは？)
Why?(移行理由は？)
How?(移行戦略は？)
Where?(移行先は？)
When?(期限は？)
Who?(担当者は？)

AWSの考えるクラウドへの6つの移行戦略

1. Re-Host(ホスト変更)

サーバーやアプリケーションをオンプレミス環境からクラウドにそのまま持ってくる
例：オンプレミスのOracleをそのままEC2に持ってくる

2. Re-Platform(プラットフォーム変更)

クラウド移行の一環として、プラットフォームのアップグレードを行う
例：オンプレミスのOracle 10gをEC2に構築した12cに移行する

3. Re-Purchase(買い換え)

クラウドに対応したライセンスまたはアプリケーションに買い換える
例：オンプレミスのOracleをライセンス込みのRDS for Oracleに買い換える

4. Refactor(書き換え)

クラウド環境で最適に動作するようにアプリケーションを書き換える
例：オンプレミスのOracleをAuroraやRedshiftに変更する

5. Retire(廃止)

サーバーやアプリケーションを廃止する
例：並行運用していた古いシステムをDBごとこのタイミングで廃止する

6. Retain(保持)

オンプレミス環境を引き続き使用する
例：Oracle9iに依存しているアップグレードできないパッケージアプリケーションがある

クラウド移行戦略を移行の複雑さで比較

本セッションではRefactorにフォーカスする

移行先を決める

本セッションでご紹介する移行先
- Redshift
- MySQL Compatible Database
- PostgreSQL Compatible Database

RDBMSの特性概要

OLTP向けなのかOLAP向けなのか特性がある
目標レスポンス時間から判断する
検索効率を上げるための仕掛けに違いがある
- 結合方法
- インデックス
- 制約
文法互換性にも気をつける

Statspack/AWRから現行ワークロードを評価し、特性を判断する
- Elapsed Time per Execの長さを測る
- 短い場合はMySQL系が向いている
- 長い場合はRedshiftが向いている

期限と担当者を決める

期限と担当者を決めるには、工数(移行先との違いの量)の見積が必要

AWSが提供する移行支援サービス

本セッションでは、AWS Database Migration Serviceについて紹介

AWS Data Migration Service(DMS)

AWS Data Migration Service(DMS)の特徴

使用が簡単
- 管理コンソールで数回クリックするだけ
最小限のダウンタイム
- オンラインでの継続的レプリケーション対応
豊富な対応プラットフォーム
- Oracle
- SQL Server
- SAP ASE
- MySQL
- MariaDB
- PostgreSQL
- Aurora
- Redshift
- S3
- MongoDB
- DynamoDB
簡単なセットアップ
- ソースDBへの変更はほぼ不要
- Oracleならログマイナーをオンにするだけ
高い信頼性
- マルチAZ可能なインスタンス
低コスト
- c4.largeインスタンスで0.196 USD/Hour

AWS Schema Conversion Tool(SCT)

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

AWS Schema Conversion Tool(SCT)の特徴

手動変換の補助
- 自動変換できなかった箇所とその理由を明示
評価レポートの作成
- 何割のオブジェクトが自動変換可能かなどのPDFレポートを数クリックで作成でき、変換工数の事前見積を補助
アプリケーションSQLに対応
- アプリケーションソースコードをスキャンして変換
豊富な対応プラットフォーム
- Oracle
- SQL Server
- Teradata
- Netezza
- Greenplum
- Vertica
- MySQL
- MariaDB
- PostgreSQL
- Aurora
- Redshift
機械的に変換できるSQLはSCTで対応
- Oracleの特殊結合(+)
- ROWNUM
- 関数の多く　など

(上の画像は、Javaのソースコードから変換の対象となるSQL文を抽出、変換している様子です)

評価レポート

画像中、緑は自動変換可能
- スキーマ、テーブル
グレーは手動対応が必要
- 制約がDISABLEになっている
- 移行先に制約のDISABLE機能がないので、手動対応が必要
赤は別の対応が必要
- BITMAPインデックスを使用しており、移行先に同等の機能がない

参考：[Aurora事例祭り]AWS Database Migration Service と Schema Conversion Tool の使いドコロ | Slideshare

Oracle DBとの違い

オブジェクトの主な違い
SELECTでの主な違い
DMLでの主な違い
データの移行
構築と運用

ここからの前提

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

Oracle RACからAurora MySQLへの移行事例

レコチョク様

全サービスで横断して使用している1000万会員のDB
DMS / SCTリリース前に手動で移行完了
移行した結果
- Auroraによる障害はこれまで0
- DBサーバ運用に工数をほとんど割かなくてよい
- 性能は問題なし(むしろ速くなった)

参考：Oracle racからaurora my sqlへの移行 | Slideshare

1. オブジェクトの主な違い

MySQLのシーケンス

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

参考：AUTO_INCREMENT の使用 | MySQL 5.6 リファレンスマニュアル

PostgreSQLのマテリアライズドビュー

リフレッシュは手動のフルリフレッシュのみ
読み取り専用のみ対応

参考：マテリアライズドビュー | PostgreSQL 9.6.2文書

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);

Redshift → PostgreSQLのdblink

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

MySQLとPostgreSQLのパーティショニング

MySQL
- RANGE, HASH, LIST, KEY
PostgreSQL
- RANGE, LIST
- サブパーティションとEXCHANGEは非対応

ストアドプロシージャ / ストアドファンクション

PostgreSQLのPL/pgSQLとMySQLのストアドルーチンは、PL/SQLに似ているが完全に同じではない

参考：Oracle PL/SQLからの移植 | PostgreSQL 9.6.2文書

RedshiftはPythonによるストアドファンクションのみ
Aurora MySQL、Aurora PostgreSQL、RedshiftはJavaプロシージャ非対応

2. SELECTでの主な違い

互換性がないとどうなるのか

文法エラーになる → エラーに地道に対応していけば良い
文法エラーが出ずに、結果が異なる → 想定している結果なのかも評価しないと非互換に気づかない

厄介なのは2.のパターン
- 一覧のバッチの最終結果しかなかったりすると、どのSQLで結果が変わってしまったのか調査が非常に大変
2大ポイントはNULLと空白

NULLと空文字の扱いの違いその1

INSERT INTO t1 (id, val) VALUES (1, '');
SELECT id FROM t1 WHERE val IS NULL;

Oracleの場合
- 空文字はNULLと同じ → id=1 が返る
MySQL, PostgreSQL, Redshiftの場合
- NULLと空文字を区別する → id=1 は返らない
対策はSQL文を''でGREPして抽出すること

NULLと空文字の扱いの違いその2

||(バーティカルライン)による結合とCONCAT関数による結合の違い

1. SELECT NULL || 'aws' FROM t1;
2. SELECT CONCAT(NULL, 'aws') FROM t1;

Oracleの場合
- NULLは空文字と同じ → aws が返る
MySQLの場合
1. || は論理OR演算子
2. CONCATは NULL が返る → COALESCEで対策
PostgreSQL, Redshiftの場合
1. || は NULL が返る → COALESCEで対策
2. CONCATは aws が返る
外部結合した後の||に特に注意！

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の場合
1. aws cloud
2. aws cloud
3. 5
MySQLの場合
1. awscloud
2. 3
PostgreSQL, Redshiftの場合
1. awscloud
2. aws cloud
3. 3
CHARをCONCATしている部分にRPADを追加する
```
CONCAT(RPAD(v, 5, ' '), 'cloud')
```

その他機会的に変換しにくい代表的な非互換

完全外部結合を使った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;

3. DMLでの主な違い

トランザクション分離レベル

Oracle Database
- デフォルトは READ COMMITTED
- READ UNCOMMITTED と REPEATABLE READ には非対応
MySQL(InnoDB)
- デフォルトは REPEATABLE READ
- Phantom Readは発生しない
- READ COMMITTED でも Non Repeatable Read(Fuzzy Read) は発生しない