この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。
当エントリでは2017年06月01日に行われた『Oracle Database から Aurora & Redshift に移行するための実践ガイド』の内容をレポートします。
(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インデックスを使用しており、移行先に同等の機能がない
Oracle DBとの違い
- オブジェクトの主な違い
- SELECTでの主な違い
- DMLでの主な違い
- データの移行
- 構築と運用
ここからの前提
- 選択バイアスが掛かっているだけなのでご安心下さい
- SCTやDMSでは自動化できない部分または注意を要する部分だけを抽出しています
- Oracle DatabaseにはないがAurora & Redshiftにはある機能については、このセッションでは扱いません
Oracle RACからAurora MySQLへの移行事例
レコチョク様
- 全サービスで横断して使用している1000万会員のDB
- DMS / SCTリリース前に手動で移行完了
- 移行した結果
- Auroraによる障害はこれまで0
- DBサーバ運用に工数をほとんど割かなくてよい
- 性能は問題なし(むしろ速くなった)
1. オブジェクトの主な違い
MySQLのシーケンス
- 列にAUTO_INCREMENT属性をつけ、その列にNULLまたは0を入れる、または何も入れないと、その列内の最大値+1が入る
- CURRVALに相当する値はLAST_INSERT_ID()関数を使用する
- 直近のINSERTで採番された値を返す
PostgreSQLのマテリアライズドビュー
- リフレッシュは手動のフルリフレッシュのみ
- 読み取り専用のみ対応
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に似ているが完全に同じではない
- 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の場合
- || は論理OR演算子
- CONCATは NULL が返る → COALESCEで対策
- PostgreSQL, Redshiftの場合
- || は NULL が返る → COALESCEで対策
- 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の場合
- aws cloud
- aws cloud
- 5
- MySQLの場合
- awscloud
- 3
- PostgreSQL, Redshiftの場合
- awscloud
- aws cloud
- 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) は発生しない
- PostgreSQL
- デフォルトは READ COMMITTED
- 4つの分離レベルを全てサポート
- Redshift
- SERIALIZABLEのみ
- その他の3つのレベルは設定可能だが、SERIALIZABLEのエイリアスになっている
MySQL(InnoDB)独自のロック
PostgreSQLとRedshiftのVACUUM
- PostgreSQLとRedshiftでは、DELETEされた行と関連するインデックスの領域は即座には再利用されない
- PostgreSQLとRedshiftでは、UPDATEは古い行のDELETE + 新しい行のINSERTとして実行される
- DELETE / UPDATEが多いワークロードでは、VACUUMコマンドによって不要な領域を開放する必要がある
PostgreSQLのVACUUMにおける挙動
- VACUUM
- 排他ロックを取得しない
- OSには領域を戻さない
- デフォルトは自動実行
- VACUUM FULL
- OSに領域を戻す
- 排他テーブルロックを取得する
- I/O負荷が非常に高い
RedshiftのVACUUMにおける挙動
- VACUUM [FULL]
- 不要な領域の開放と未ソートデータのソート
- VACUUM DELETE ONLY
- 不要な領域の開放のみ
- VACUUM REINDEX
- インターリーブソートキーのメンテナンス
- I/O負荷が非常に高い
Aurora PostgreSQLのVACUUM
5. 構築と運用
マネージド型RDBMSなので、構築と運用は容易に
- インストール
- 数クリックで完了
- 災害対策サイト(除くRedshift)
- セレクトボックスから選択するだけで、複数DC冗長構成
- スケールアップ / スケールアウト
- 数クリックで完了
- バックアップ / リストア
- 1クリックでスナップショット取得 / 復旧
- ハードウェア障害
- 起動し直すだけで復旧
- バージョンアップ
- セレクトボックスから選択するだけ
まとめ
本セッションでは以下について触れました
- Why?(移行理由は？)
- スケーラビリティやコスト削減
- How?(移行戦略は？)
- リファクタリング
- Where?(移行先は？)
- SQL orderd by Elapsed Time
- Who?(担当者は？)
- 主な差分のご紹介
パートナー事例大全集 vol.2(15社の移行事例掲載)配布中
関連ブログ公開
- Oracle Database を Amazon Aurora に移行する方法 | Amazon Web Services ブログ
- オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行 | Amazon Web Services ブログ
最後に……
- 移行するシステムの順序を決定する要素
- 複雑かどうか
- ミッションクリティカルかどうか
- 得られる利益が大きいかどうか
- データベースの起動で得られる利益は大きい
お客様のシステムを対象としたアセスメントやAWSパートナーのご紹介も可能ですので、いつでもご相談下さい
感想
ご覧の通り、非常に中身の濃い、知見に富んだセッションでした。移行を検討されている場合には必読の情報満載だと思います。それでは、また。
5
