Category: AWS Database Migration Service

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

• AWS SCT をダウンロード。
• AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
• 米国西部（オレゴン）リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部（オレゴン）リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

スタックを起動して名前を付けるには、次のようにします。

1. AWSアカウントにまだログインしていない場合はログイン。
2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
   
4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
   
5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
   
6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
   

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

1. AWS Schema Conversion Tool を開始。
2. Fileから New Project を選択。New Project ダイアログが表示される。
   
   次のプロジェクト情報を追加。

   Project Name	プロジェクト名を入力。コンピュータにローカル保存される
   Location	ローカルプロジェクトファイルの保存先を入力
   Data Warehouse (OLAP)
   Source DB Engine	Oracle DW
   Target DB Engine	Amazon Redshift

3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
4. Oracle Database に接続するため、Connect to Oracle DW を選択。
   
   Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。
   
   以下の値をフォームに入力。

   Server name	<移行元EC2エンドポイントのDNS名>
   Server port	1521
   Oracle SID	XE
   User name	dms_sample
   Password	dms_sample
   Use SSL	チェックしない

5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
6. 移行元データベースに接続するため、OKを選択。
7. DMS_SAMPLEデータベースを選び、Nextを選択。
   
8. Database Migration Assessment Report を読み、Nextを選択。
   
   
9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。
   
   Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。
   
   以下の値をフォームに入力。

   Server name	移行先RedshiftエンドポイントのDNS名
   Server port	5439
   Database	dev
   User name	admin
   Password	CloudFormationで選ばれたパスワード
   Use SSL	チェックしない

10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

1. Viewを選び、Main View を選択。
   
2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト（右クリック）メニューを開き、Convert schema を選択。
   
3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
   
4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト（右クリック）メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
   
3. 「レプリケーションインスタンスの作成」ページが表示される。
   
   このページで以下の値を入力し、「次へ」を選択。

   名前	8から16文字のASCII文字によるレプリケーションインスタンスの名前（/、”、@を除く）
   説明	レプリケーションインスタンスの説明を入力
   インスタンスクラス	dms.t2.medium
   VPC	使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
   Multi-AZ	いいえ
   パブリックアクセス可能	チェック

4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

1. ソースエンドポイントに以下の値を設定。
   

   エンドポイント識別子	エンドポイントを識別するために使いたい名前を入力
   ソースエンジン	oracle
   サーバー名	<移行元EC2エンドポイントのDNS名>
   ポート	1521
   SSLモード	none
   ユーザー名	dms_sample
   パスワード	dms_sample

2. ターゲットエンドポイントに以下の値を設定。
   

   エンドポイント識別子	エンドポイントを識別するために使いたい名前を入力
   ソースエンジン	redshift
   サーバー名	<RedshiftエンドポイントのDNS名>
   ポート	5439
   SSLモード	none
   ユーザー名	admin
   パスワード	CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。

翻訳はソリューションアーキテクト柴田（シバタツ）が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。

データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。

AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。

すばらしい！ では、どこから始まれば良いのでしょう？

AWS SCT での移行手順

通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool とは からご覧ください。

この投稿ではSCTのイストールや構成については触れませんが、注意点は移行元と移行先のデータベースにSCTを接続するために、OracleとMySQLのドライバーをインストールする必要があることです。移行元のOracleに接続した後、スキーマのいずれかを右クリックしてアセスメントレポートを作成できます。アセスメントレポートはこのスキーマがどれくらいOracleからAuroraに自動変換されるのかと、自動変換後に残された作業量がどれくらいなのかの概要を教えてくれます。以下がレポートの例です。

アセスメントレポートに加えて、SCTは各オブジェクトがどれくらい正確に変換されるかも教えてくれます。もしあるオブジェクトが変換できない場合、SCTはその理由と、状況を改善するためのヒントを教えてくれます。

スキーマの100%がOracleからAuroraに変換されない場合、いくつかの方法で状況を改善できます。

• 移行元のOracleのデータベース上のオブジェクトを変更して、SCTでAuroraに変換できるようにする
• スキーマをひとまず変換し、SCTによって生成されたスクリプトを変更してからAuroraデータベースに適用する
• 変換できないオブジェクトを無視し、移行先でそれらを置き換えるか無視する。たとえば、Oracleのsys.dbms_randomパッケージを呼び出すファンクションがあるとします。このパッケージはAuroraには存在しません。この問題を解決するには以下のことができます。
  • ランダム値の生成をアプリケーションコードに移し、それをパラメーターとしてファンクションに渡します。この変更は、変換前の移行元データベースまたは変換後の移行先データベースで行うことができます。
  • SCTで生成されたコードを、MySQLに存在するRAND()ファンクションを使うように変更し、新しいコードをAuroraデータベースに適用します。

その他の例として、一意の識別子を生成するためにOracleのシーケンスを使っているとします。Auroraはシーケンスをサポートしていないので、修正するために以下を実行してください。

• 自動的に一意の識別子を生成するAuroraのauto-increment機能を使う。この方法で行く場合は、Auroraデータベースにスキーマを作成した後で、移行先のテーブルを変更するためのスクリプトを作成することをお勧めします。
• 一意の識別を生成する何か別の方法（ファンクションや類似のもの）を作成し、シーケンスを参照している部分を新しいファンクションで置き換える。これは変換前に移行元のOracle上で実施することも、移行先のAuroraで実施することもできます。
• 両方の手法を使う必要があるかもしれません。

一般的に、移行の一環としてSCTを使うための良い取り組み方には以下を含みます。

• SCTアセスメントレポートを作成し、移行のギャップを埋める計画を立てる。もし移行候補となる複数のシステムがある場合は、どのシステムから最初に取り組むべきかの決定に役立ちます。
• Action Items を確認し、変換に失敗した各項目の適切な処理を決定する。
• 新しいAuroraデータベースに対してアプリケーションをテストしながら、AWS Database Migration Service と連携して新しいスキーマにデータをロードし、この処理を繰り返す

AWS DMS での移行手順

AWS DMS は移行元のOracleデータベースから移行先の新しいAuroraデータベースにデータをロードするときに使えます。DMSの素晴らしい点は、データを丸ごとロードすることに加えて、実行中のトランザクションをキャプチャして適用することです。カットオーバーの準備が整うまで、Oracleの移行元データベースとAuroraの移行先データベースを同期させつづけます。このアプローチによって、移行を完了させるために必要な停止時間を大幅に短縮することができます。DMSマイグレーションには、移行元エンドポイントであるOracle、移行先エンドポイントであるAurora、レプリケーションサーバー、タスクを含みます。

OracleからAuroraに移行するとき、既存データを移行し、進行中の更新をレプリケーションするタスクを構成したいでしょう。これにより、データ全体の移行中に実行されたトランザクションをキャプチャするようにDMSに指示します。データ全体がロードされると、DMSはキャプチャされたトランザクションの適用を開始し、OracleとAuroraのデーベースの同期を開始します。Auroraをカットオーバーする準備ができたら、アプリケーションを停止し、残ったトランザクションをDMSに適用させ、新しいAuroraデータベースに接続するアプリケーションを開始するだけです。

DMSを使用してOracleからAuroraに移行する場合、考慮すべき点がいくつかあります。

サプリメンタルロギング。 DMSが移行元のOracleから更新をキャプチャするにはサプリメンタルロギングを有効にする必要があります。詳細な手順については、DMSのマニュアルを参照してください。

DMSの3つのフェーズ。 データを移行し、進行中の更新をキャプチャするとき、DMSは3つのフェーズを経ています。

• バルクロード: バルクロードフェーズで、DMSはn個のテーブルを一度にまとめてロードします。デフォルトでは n = 8 です。この値はDMSマネジメントコンソールまたは AWS CLI を利用して変更できます。
• キャッシュされたトランザクションの適用: バルクロードフェーズにDMSは移行元データベースへの更新をキャプチャします。あるテーブルのバルクロードが完了すると、DMSはバルクロードの一部であるかのようにキャッシュされた更新をできるだけ速くそのテーブルに適用します。
• トランザクションとしての適用: すべてのテーブルのバルクロードが完了すると、DMSはキャプチャされた更新を単一のテーブルの更新ではなく、トランザクションとして適用し始めます。

セカンダリインデックス。 状況によっては、性能上の理由からDMSのバルクロードフェーズにセカンダリインデックスを削除したくなるかもしれません。バルクフェーズ中にセカンダリインデックスの一部またはすべてを削除することを選ぶ場合は、移行を一時停止して、トランザクションとしての適用フェーズでそれらを追加しなおす必要があります。すべてのテーブルのフルロードが完了した後であれば、移行を安全に一時停止することができます。

外部キー、トリガーなど。 バルクロードはテーブル単位で行われるため、バルクロードやキャッシュされたトランザクションの適用フェーズでは移行先のAurora内の外部キーに違反する可能性があります。initstmt=SET FOREIGN_KEY_CHECKS=0 をAuroraエンドポイントの追加接続属性として加えることで、外部キー検査を無効にすることができます。一般的に、データのバルクロードを中断したり悪影響を与える可能性のあるものにどう対処するかの戦略を策定する必要があります。たとえば、問題を回避するために、移行のカットオーバーフェーズになるまでトリガーの実装を延期することができます。

データ型。 新しいデータベースエンジンに移行するときには、どのようなデータ型がサポートされているかと、移行元のデータ型を移行先の新しいデータ型にどう変更するかを理解することが重要です。これについては、移行元のOracleのデータ型と移行先のAuroraのデータ型をマニュアルで確認すべきです。

性能。 移行の全体的な性能は、移行元のOracle内のデータ量、種類、分散に依存しています。 AWS Database Migration Service Best Practices ホワイトペーパーに移行性能を最適化するためのいくつかの推奨事項が載っています。

手順をおさらいすると、

1. SCTアセスメントレポートを使用して課題の概要を知ることができます。Auroraへの移行候補が複数ある場合は、どれから最初に取り組むべきかの決定に役立ちます。
2. 処理の前後に必要となるかもしれない移行手順を洗い出すために、DMSを使用して移行先スキーマの作成とロードを実践します。
3. 移行先のシステムでアプリケーションをテストして、新しい環境で期待通りに動作することを確認します。負荷やネットワーク環境を含む本番環境と同等の構成でテストしてみてください。
4. スキーマの生成、データのロード、後処理の手順の適用、移行元と移行先システムの同期、カットオーバーに必要な手順などの実際の移行を実践します。
5. SCTもDMSをシステム全体を一度に移行することを求めません。システムを短期間で効率的に移行するため、また必要であれば再構築するために、これらのツールを使用することができます。

実際の移行を開始する前に、SCTとDMSの両方のドキュメントを通して読むことをお勧めします。また、Step-by-Step ウォークスルー と AWS Database Migration Service Best Practices ホワイトペーパー を読むこともお勧めします。

ツールの使い方を知るためにサンプルデータベースを使用したいのであれば、AWS GitHub リポジトリ で見つけることができます。

この投稿は特定の状況に必要な可能性のあるすべての手順や考慮事項を解説するものではありませんが、SCTとDMSを使用してプロプライエタリなOracleデータベースの足かせをどう緩められるかについての良いアイデアを提供しました。それでは幸せな移行を！

翻訳はソリューションアーキテクト柴田（シバタツ）が担当しました。原文は How to Migrate Your Oracle Database to Amazon Aurora です。

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。

先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email や テキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。

お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。

レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。

さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS コンソール、AWS DMS API を使って、そのカテゴリをサブスクライブできます。サブスクライブすることにより、そのカテゴリに関するイベントが起きた際に、通知されます。例えば、特定のレプリケーションインスタンスについての “creation(作成)”カテゴリをサブスクライブした場合、レプリケーションインスタンスが作成されているなどのような、レプリケーションインスタンスに影響を与える creation に関連したイベントが起きた際はいつでも通知がなされます。

下記の一覧は、現時点で DMS レプリケーションインスタンスについてサブスクライブできるカテゴリを示しています。

• Configuration change(設定変更)—レプリケーションインスタンスの設定が変更されています
• Creation(作成)—レプリケーションインスタンスが作成されています
• Deletion(削除)—レプリケーションインスタンスが削除されています
• Maintenance(メンテナンス)—レプリケーションインスタンスのオフラインメンテナンスが実行中です
• Low storage—レプリケーションインスタンスの空きストレージが少なくなっています
• Failover(フェイルオーバー)—Multi-AZ インスタンスのフェイルオーバーに関連するイベント。フェイルオーバーの有効化、開始、完了など。
• Failure(失敗)—レプリケーションインスタンスで、ストレージ障害やネットワーク障害が発生しました

下記の一覧は、現時点で DMS レプリケーションタスクについてサブスクライブできるカテゴリを示しています。

• State change— レプリケーションタスクが開始もしくは停止されました
• Creation(作成)—レプリケーションタスクが作成されました
  Deletion(削除)—レプリケーションタスクが削除されました
• Failure(失敗)—レプリケーションタスクが失敗しました

AWS DMS によるイベントとイベントカテゴリの一覧は、ドキュメントのイベントと通知の使用を参照してください。

AWS DMS イベントをサブスクライブするには、以下の通り行います。

1. Amazon SNS トピックを作成します。このトピックには、どんなタイプの通知を受け取りたいか、受け取るアドレスや電話番号を設定します。
2. AWS マネジメントコンソール、AWS CLI, もしくは AWS DMS API を通じて、AWS DMS イベント通知のサブスクライブを行います。
3. AWS DMS のイベント通知を受け取るための承認メールもしくは SMS メッセージを受け取り、E メール、SMS メッセージ内のリンクをクリックして、サブスクライブの確認を行います。

サブスクライブしたことを確認すると、AWS DMS コンソールの Event Subscriptions セクションにて、お客様のサブスクリプションのステータスが更新されます。

そして、イベント通知の受信が開始されます。

コンソールを使ったテーブルマッピングについての詳細は、DMS ドキュメントを参照ください。

AWS Database Migration Service 全般に関する詳細は、こちらのウェブサイトを参照ください。

AWS Database Migration Service について初めてブログ (AWS Database Migration Service) を投稿したのは 1 年ほど前のことです。その時点で AWS ユーザー 1,000 人がすでに AWS への移行の一部として同サービスを使用していました。簡単に説明すると、AWS Database Migration Service とスキーマ変換ツール (SCT) は、AWS のお客様が高価な独自のデータベースやデータウェアハウスから、リレーショナルデータをよりコスト効率の良い Amazon Aurora、Amazon Redshift、MySQL、MariaDB、PostgreSQL といったクラウドベースのデータベースやデータウェアハウスに、ダウンタイムを最低限に抑えた状態で移行できるようにサポートします。ユーザーの皆様からは、その柔軟性とコスト効率に優れた点において良い評価を頂いています。たとえば Amazon Aurora に移行すると、商用データベースに掛かる 10 分の 1 のコストで MySQL と PostgreSQL との互換性を持つデータベースにアクセスすることができます。Expedia、Thomas Publishing、Pega、Veoci といった企業による使用事例は AWS Database Migration Services Customer Testimonials でご覧いただけます。

独自の移行数 20,000 件
AWS のお客様は、これまでに AWS Database Migration Service を使用して 20,000 件もの独自のデータベースを AWS に移行しており、現在もその数は上昇する一方です (2016 年 9 月の移行数は 10,000 件を記録)。昨年はいくつもの新機能を DMS と SCT に追加しました。概要は次をご覧ください。

• 2016 年 3 月 – 8 つの AWS リージョンで一般提供を開始しました。
• 2016 年 5 月 – 移行ターゲットとして Redshift を追加しました。
• 2016 年 7 月 – 継続的なレプリケーション用の高可用性アーキテクチャを提供しました。
• 2016 年 7 月 – 移行ソースおよびターゲットとした SSL が有効なエンドポイント & Sybase のサポートを提供しました。
• 2016 年 8 月 – Asia Pacific (Mumbai)、Asia Pacific (Seoul)、South America (Brazil) リージョンを追加しました。
• 2016 年 10 月 – US East (Ohio) リージョンを追加しました。
• 2016 年 12 月 – Oracle SSL 接続のサポートを提供しました。
• 2016 年 12 月 – Canada (Central) と Europe (London) リージョンを追加しました。
• 2017 年 1 月 – イベントとイベントサブスクリプションのサポートを追加しました。
• 2017 年 2 月 – Oracle と Teradata データウェアハウスから Amazon Redshift への移行をサポートしました。

詳細
移行を始めるには、まず最近のオンラインセミナーなどを参考にして詳細情報をご覧ください。シャードからスケールアップへの移行 – 複数の独立した要素にわたりデータベースをシャードし、それぞれを別のホストで実行するなどして、リレーショナルワークロードに対応できるようにスケールアウトする方法を選択したお客様もいらっしゃいます。そうしたお客様は、移行の一環として 2 つ以上のシャードを 1 つの Aurora インスタンスにまとめ、複雑さを軽減し信頼性を高めながらコスト節約を実現しています。この方法を行うには、こちらのブログ記事とオンラインセミナーの録画、プレゼンテーションをご覧ください。Oracle や SQL Server から Aurora への移行 – その他のお客様は Oracle や SQL Server といった商用データベースから Aurora に移行しています。この方法を行うには、こちらのプレゼンテーションとオンラインセミナーの録画を併せてご覧ください。AWS Database Blog ではその他にも多数の役に立つブログを公開しています。

• シャーディングしたシステムを Aurora で統合しリソース消費を低減 -「シャーディングしたシステムを 1 つの Aurora インスタンスに統合したり、Aurora で実行しているシャード数を減らすことでコストを節約できることがあります。このブログでは、まさにその方法を説明しています。」
• Oracle データベースを Amazon Aurora に移行 – 「このブログでは AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、商用データベースを Amazon Aurora に移行しやすくするための概要を提供しています。このブログ記事では Oracle から MySQL との互換性がある Amazon Aurora への移行に焦点を当てました。」
• AWS スキーマ変換ツールと AWS Database Migration Service を使用しているクロスエンジンデータベースレプリケーション -「AWS SCT はソースデータベーススキーマを自動変換することで異種データベースを移行しやすくします。さらに、AWS SCT はビューや関数など大方のカスタムコードをターゲットデータベースと互換性のある形式に変換します。」
• データベースの移行—移行前に知っておくべきことは? -「おめでとうございます! データベースをクラウドに移行するように、上司や CIO を説得できたようですね。もしかすると、ご自身が上司または CIO なのかもしれませんが、どちらにせよバンドワゴン効果をぜひご活用ください。率先してデータベースを移行するユーザーは稀です。ここでのポイントは、ご利用されているアプリケーションを新しい環境やプラットフォーム、テクノロジー (アプリケーションの更新) に移行することです。
• データベース移行のスクリプト -「AWS DMS コンソールまたは AWS CLI、AWS SDK を使用してデータベース移行を実施できます。このブログでは AWS CLI での移行に注目します。」

マニュアルには 5 つの便利なガイドが含まれています。

• アマゾン ウェブ サービスにデータベースを移行する
• AWS Database Migration Service を使用してオンプレミスの Oracle データベースを Amazon Aurora に移行する
• AWS Database Migration Service を使用して Amazon RDS Oracle データベースを Amazon Aurora に移行する
• MySQL との互換性があるデータベースを AWS に移行する
• MySQL との互換性があるデータベースを Amazon Aurora に移行する

ハンズオンラボもご提供しています。参加するには登録が必要です。（ハンズオンラボは英語のみの場合があります。）

ではサミットでお会いしましょう
DMS チームは今後開催予定の AWS サミットにいくつも参加する予定です。皆さんに直接お会いしてデータベース移行について語り合えることを楽しみにしています。

— Jeff;

みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか？それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか？

もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです！去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。

AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動（例：OracleからAurora）といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。

DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。１つのエンドポイント（※ソースもしくはターゲットのデータベースサーバ）はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません（AWS上で稼動するデータベースを別のVPC上に移すようなケース）。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか（インターネットVPNを使うことも可能です）、AWS Direct Connectで接続することが可能です。

データベースをマイグレーションする

数クリックでマイグレーションをセットアップすることが可能です！ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。

AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。（AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています）

コンソールにはマイグレーションプロセスのオーバービューが表示されています:

Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します:

このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです（訳注：オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります）:

レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。（正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました）

そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data（既存データの一括ロード）”,”migrate and then replicate（一括コピーをした後に、継続的に差分レプリケーション）”,”replicate going forward（差分レプリケーションのみ実行）”の３種類から選択が可能です。

Task Settingsをクリックすることで、追加のオプションを選択可能です（LOBというのはラージオブジェクトのことです):

マイグレーションタスクが準備完了になりました。タスクを選択してStart/Resumeボタンを押すことですぐに実行することが可能です:

実行中の状況を確認することが可能です。また表へのアクセスの統計情報(Table statistics)によって、何が起こっているのかを把握することが可能です（この図はテスト用の表を使った結果なので、あまりエキサイティングな図ではないですが）:

 ここまで来たら、あとはデータの正当性をチェックし、アプリケーションを新しいエンドポイントに向けるだけです。上記は一括ロードの例ですが、継続的なレプリケーション(ongoing replication)を選択することも可能です。

AWS Database Migration Serviceは多様なオプションを提供しており、上記はあくまで少し機能を紹介したに過ぎません。例えば、特定の表だけをマイグレーションしたり、複数の異なるレプリケーションタスクを作成し、それぞれ個別に実行することも可能です。DMSのドキュメントを読まれることを強く推奨します。マイグレーションを始めて行う人向けの良いガイドになっています。

多くのデータベースを移行する必要があり、作業を自動化したい場合は、AWS Command Line Interface (CLI) もしくはDatabase Migration Service APIを利用することができます。

費用と稼動リージョン

AWS Database Migration Serviceは US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) の各リージョンに存在します。そして本日より利用可能です！（私達は他のリージョンへの拡張を今後数ヶ月で検討しています）

— Jeff;

原文：https://aws.amazon.com/jp/blogs/aws/aws-database-migration-service/

翻訳：下佐粉　昭（@simosako）