この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
先日レポートした「【完全無料】AWS公式の専用線アクセス体験ハンズオンラボがごっつ良かった件」の興奮冷めやらぬ中、本日も行って来たのが、こちらになります。
データベースのマイグレーションも無料ハンズオンあるなんて全然知りませんでした。AWS懐深いでほんま。
普段業務でお客様とお話している中で、オンプレからAWSへのインフラ移行と合わせて、データベースの移行についても相談されることが非常に多いです。AWSには公式のDBマイグレーションのためのサービスとツール、DMS（Database Migration Service）とSCT（Schema Conversion Tool）が用意されており、今回はその使い方がメインのハンズオンとなります。
アプリケーションの基盤「データベース」の移行がテーマ。データはアプリの命！！
といわけで、こちらも非常に有用なハンズオンだったので、その様子を前のめり気味にお届け致します。
__ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 DBﾏｲｸﾞﾚｰｼｮﾝﾀﾞ ﾜｯｼｮｲ |_|＿| し'´Ｊ
データベースエンジニア向け体験ハンズオンとは？
データベースエンジニア向け体験ハンズオン （2018 年 5 月 24 日開催）
オンプレミス環境やクラウド環境からマネージド型データベースサービスへの移行を体験！
既存のデータベースのクラウド化を進める際には、当然ながら既存のデータベースから新しいデータベースに対してデータを移動する必要があります。 もちろん、データベースを切り替える前に一気にデータを移動することもできますし、並行運用してデータをコピーしながら新しいデータベース用のアプリケーションを開発することもできます。その際、データ移動のカギとなるのが、AWS Database Migration Service (DMS) です。
また、既存のデータベースを Amazon Aurora や RDS に移行する際、ソースとなるデータベースのスキーマやビュー、ストアドプロシージャ、関数などを移行先のデータベースで利用できる形に変換する必要もあります。そのためのツールが AWS Schema Conversion Tool (SCT) です。
今回のセミナーでは、実際に DMS/SCT を操作していただき、既存のデータベースから新しいデータベースにデータを移行するために必要なステップを学んでいただきます。
というわけで、データベースの移行において鍵となる「データ」「スキーマ」の移行を一気にやってしまおうという、欲張りなハンズオンです。もちろん、完全無料。
ハンズオン会場の様子
今回も会場は、AWSのオフィスがあるアルコタワー19階。専用線ハンズオンラボとは違い、入って右側のセミナールームが会場となってます。AWS関連のセミナーではよく使われているので、行ったことある人も多いんじゃないでしょうか。
めっさ、広い。スクリーンも全部で4個あります。
座席が可愛い。これ、テーブル部分が可動式になってて見た目以上に使いやすいんですよ。
電源もそこかしこに生えてます。
水の提供も有り。こういう心遣い、本当にありがたいです。
もちろんWi-Fiも完備ということで、前回も思いましたがハンズオンセミナーのファシリティ面快適すぎます。
講義「オンプレシステムのクラウドへの移行戦略/DR 戦略」
最初に、AWSジャパン エバンジェリスト亀田さんより、データベース移行戦略の概論をいただきます。ありがたや。AWSのイベントでは必ず（？）どこかで登壇されているので、お会いしたことがある人も多いんじゃないでしょうか。
ジーパンがイカツイ（普段はもっと攻めてるぜ、とのことでした）。
今回のハンズオンのメインテーマは「データベースの移行」ということで、その概論として、AWSにおけるデータストレージの概要や、制約、ユースケース、また既存システムから移行する際の各種移行パターンなどを詳しく説明していただきます。
特にクリティカルなポイントとなりがちな、「RDSでは要件満たせなくてEC2をつかうパターンもある」というところも、しっかりアラートをあげていただいてました。
ハンズオン参加者も、DMSやSCTというツールの機能を学ぶという目的以前に、ユースケースとしてそういった移行における課題感を持っているはずなので、そのあたりの背景をうまく埋めていただく講義として非常に参考になりました。
データベース 移行ハンズオン
いよいよ、ハンズオンが始まります。講師は、ソリューションアーキテクトの柴田さん。
最初に、今回利用する２つのツールについて、その概要を説明していただいたのち、ハンズオンが始まります。
- DMS（Database Migration Service）
- データベースのデータ移行をリアルタイムで実施するフルマネージドサービス
- 様々なデータソースとアウトプットDBに対応
- SCT（Schema Conversion Tool）
- 異種データベース間のスキーマを変換するJavaクライアントツール
- テーブルのDDLだけではなく、各種制約やファンクション、プロシージャの変換にも対応
- レポート出力機能で、マイグレーション難易度の事前評価も可能
ハンズオンの流れは概ね以下の通り。
- 全体構成の作成（CloudFormation利用）
- SCTによるスキーマ変換（Oracle → PostgreSQL）
- DMSによるデータ移行（Oracle → PostgreSQL）
ステップ1「全体構成の作成」
以下の構成を、自分で用意したAWSアカウント上で構築します。といっても、CloudFormationのスタックが用意されているので、それを流すだけ。自分の場合は、10分ほどでさくっと出来上がりました。
今回のハンズオンでは、データ移行元にRDS for Oracle、データ移行先にRDS for PostgreSQLを使います。異種データベースです。ホンマにこんなの簡単に移行できるんかいな。
EC2 Windowsは、スキーマ変換ツールであるSCTを利用するのに使います。DMSとは違って、SCTはクライアントJavaアプリなので、このEC2 WindowsにSCTをインストールして、スキーマ変換します。
慣れている人は、RDSをパブリック・アクセス可能にして、接続をセキュアな状態（SSLトンネリング）にしてクライアントのMacから、SCTを使うのもアリですね。
ステップ2「SCTによるスキーマ変換」
環境が一通り出来上がったら、Oracleに格納されたテーブルやProcedureyやらViewをPostgreSQLに実際に変換していきます。
SCTのインストール後、移行元データベース（Oracle）と移行先データベース（PostgreSQL）に接続します。接続した状態の画面はこんな感じ。左が移行元、右が移行先です。
で、実際にOracleのProcedureを変換した様子がこちら。全然文法が違うDBエンジンにおいて、こんな感じでプロシージャが変換されているのは感動します。これ無料やで。
Viewの変換の様子がこちら。Oracle独自の外部結合文法「(+)」が、PosgreSQLの（というかSQL標準の）「left outer join」に変換されています。
昔、SQLServerとOracleとMySQLの現場を行ったり来たりしていて、現場の文法の違いに愕然としていた自分には、隔世の感が湧き上がります。じみーに、DB間で文法違うんですよね。
また、最初に変換をかけた時に、移行元データベースにおいてスキーマ変換がエラーになったものなどについて、その内容をレポート出力できます。とりあえずこれをやっておくだけで、異種データベースへの移行障壁の事前調査ができてしまいます。
このSCT、普通のJavaクライアントツールなので、クライアントから接続でき、かつSCTが対応しているデータベースであればどこでも使えます。しかも完全無料。オンプレ間の異種データベース移行でもかなり有用だと思うので、気になる方は一度試してみると良いと思います。
AWS Schema Conversion Tool とは - AWS Schema Conversion Tool
ステップ3「DMSによるデータ移行」
ステップ2で、スキーマ変換を事前にやってテーブルを作っておいた後に、本丸、DMSを使ったデータの移行を実施します。
DMSはSCTは違い、AWS上のマネージドサービスなので、普通にAWSコンソールから作業します。DMSのタスクを作成し、移行元、移行先データベースへの接続設定をいれ、データベースの移行形式を決めてドーンとやると、みるみるうちにデータが移行されていきます。
これも簡単です。設定自体はハンズオン資料にのっとり、10分もあれば完了します。Webコンソール上で指定対象のテーブルが徐々に移行されていく様子を途中経過として見ることができます。
ハンズオンの中では、移行元データベースにデータを投入すると、5秒おきにデータが移行されていく内容を確認することもできます。
このDMSは、AWS上にデータ変換専用のインスタンスを構築しその中で処理を行います。なのでDMS自体はAWS上に構築する必要がありますが、この環境からアクセスできるところにDBがあれば、それがクラウドだろうが、インターネットVPN等で接続したオンプレのDBだろうがデータ移行が可能です。
AWS Database Migration Service（簡単、安全なデータベース移行）｜AWS
ハンズオン最中に講師の方やサポートの方に聞いてみました
すんなり移行できてしまったので、DMSやSCTの使い所のあれこれについて、サポートで入っていただいていたソリューションアーキテクトの方や講師の柴田さんにあれこれ質問してみました。
Q1「異種データベース間で、SCTを使わずいきなりDMSでデータ移行をしたらどうなるか？」
「DMSで対応して変換できるDDLもあり、その場合は自動的に変換されたスキーマでテーブルが作成される。ただ、変換内容を自分でカスタマイズすることはできない。
SCTであれば、移行先データベースにDDLを適用する前に、事前に変換されたDDLのSQLが生成されその内容を事前に確認できる。例えば、テーブルのデータ型の変換が自分の意図しない結果であった場合は、その変換結果に対して自分でカスタマイズができる。
SCTには、事前に変換結果の評価をレポートする機能もあり、異種間データベースの移行をサポートする機能が豊富にあるので、是非有効に活用していただきたい。」
Q2「同種データベース間で、DMSを利用するユースケースはあるか？」
「基本的に同種データベース間では、そのデータベース純正のレプリケーションツールの利用を推奨している。DMSでは内部構造的に、各種データベースの差分を吸収するため、一度データをDMS特有のデータ構造に変換していることから純正ツールに比べてどうしてもパフォーマンス的に不利になる。
利用できるユースケースとしては以下のケースが存在する。
- MySQL等で複数データベースに分散しシャーディングしたDBを１つのデータベースに集約
- MySQL5.7からAurora(5.6)への移行（純正レプリケーションツールではダウングレードが出来なかった）
これら、純正ツールにはなく、DMSにある機能を利用する場合には同種データベース間でも利用を検討するとよい。」
Q3「ぶっちゃけた話なんですが、SCTはWindows版とMac版で安定性の違いがあるか？」
「SCTはJavaアプリなので、基本的な違いはない。Windows、Mac、Ubuntu Linux、Fedora Linux、どれを使っていただいても同じ。」
Q4「すでにDMSでデータ移行をかけている移行元データベースに対して、テーブルの列追加をした場合、どうなるか？」
「列の追加程度なら、DMSで自動的に処理できる。移行元データベースのテーブルに列追加されたら、自動的に移行先データベースへも列が追加されてデータも移行される。」
などなど、非常に細かく丁寧に疑問に答えていただきました。この場をお借りして、講師の柴田さん、サポートのソリューションアーキテクトの方々、ありがとうございます。m(_ _)m
まとめ「限られた時間で集中してAWSにおけるデータ移行の基礎をガッチリおさえることができるハンズオン」
講義からハンズオンまで、4時間ギュッと凝縮されたハンズオンで、満足度は非常に高かったです。
DMSについては、Blackbelt資料などを事前に読み込んだりしてその概要はおさえているつもりだったんですが、やっぱりハンズオンで実際に手を動かすのとは、まーったく違いますね。脳みそへの残り具合というか浸透感というか。
実際自分で異種間データベースの移行を試そうとすると、環境用意してDB作ってデータ用意してと前準備がそれなりに必要ですが、そこはCloudFormation一発でドーン。後は、SCTやDMSの使い方に集中できます。今まで、SCTとDMSの使い分けのイメージが曖昧だったのですが、丁寧なハンズオンであれこれ手を動かしてみることで、それぞれのツールの特徴が腹に落ちました。
ハンズオンという形式は、普段の業務からは切り離された環境で集中して１つのテクノロジーを学ぶので、何かを最初に学習する時に非常に効率が良い方式だと思っています。今回のハンズオンでも、AWSにおけるデータ移行の概論やツールの概略の説明からハンズオンの内容が一貫しており、また、自分が？？？と思っているところをダイレクトに講師の方に質問できたので、非常に濃い時間を過ごすことができました。
次回開催はまだ未定？のようですが、データベースの移行を検討されている方は受けておいて絶対損はないハンズオンなので、是非一度参加してみると良いんじゃないでしょうか。
AWSのセミナーやイベントはこちらで確認可能です。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
4
