Amazon Web Services ブログ

Category: Database*

AWS Database Migration Service (DMS)が一般公開に!利用可能リージョンも拡大

みなさんは、現在リレーショナルデータをオンプレミスの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は多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。1つのエンドポイント(※ソースもしくはターゲットのデータベースサーバ)は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 […]

Read More

Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。 フェイルオーバの優先順位は 指定した優先度 優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス 優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。 — 星野 (原文はこちら)

Read More