Amazon Web Services ブログ

Category: AWS Database Migration Service

AWS DMS を使用した移行からのロールバック

AWS Database Migration Service (DMS) を使用してデータベースを新しいシステムに移行する場合、新しいシステムが想定どおりに機能しない場合に備えてフォールバック戦略を立てることが賢明です。概要として、移行からロールバックするためには、4 つの基本的な戦略があります。すなわち、基本的なフォールバック、フォールフォワード、デュアル書き込み、双方向レプリケーションです。特定の状況に応じて、これらの戦略の 1 つまたは複数を用いることができる場合があります。 この投稿では、各戦略を定義し、その戦略が適切であると思われる状況の概要を説明します。一般的には、データベースシステムの整合性を維持しながら、最小限の労力とコストを必要とする戦略または戦略の組み合わせをデプロイすべきです。 基本的なフォールバック ソース A からターゲット B に移行する場合の最も簡単なフォールバック戦略は、アプリケーションを元のソース A に戻すことです。この戦略は、あまり生じないかもしれませんが、以下の状況では合理的です。 読み取り専用システムを移行していて、新しいターゲットが新しいトランザクションを取得していない。 システムは「バッチ」タイプのシステムであり、新しいターゲットにまだトランザクションを適用していない。 古いシステムにロールバックした後は、新しいシステムでトランザクションを使用する必要がいない。(一部のロギングシステムはこのパターンである場合があります。) ロールバックの前または後に、新しいシステムで使用されたトランザクションを元のシステムに再生成またはコピーすることができる。(ロギングシステムまたは挿入のみのシステムは、このパターンである場合があります。) 元のシステムにロールバックした後、新しいシステムにトランザクションを適用する必要はない。 カットオーバーの前に、DMS タスクはデータを A から B にレプリケートします。B に「フリップ」されるアプリケーションは、引き続き A とインタラクションします。次の図は、このアーキテクチャを示しています。 カットオーバー時にレプリケーションタスクが停止し、アプリケーションがフリップされて B とインタラクションします。次の図は、この変更を示しています。 ロールバックが必要な場合、アプリケーションはフリップされて A に戻ります。B のカットオーバー後に発生した変更は、無視され、または失われます。下図を参照してください。 デュアル書き込み 場合によっては、移行の一環として、デュアル書き込み戦略が使用されます。たとえば、データベース A をデータベース B に移行する場合の状況を考えてみます。デュアル書き込み戦略では、両方のデータベースにトランザクションを同時に書き込むことができるようにアプリケーションコードを変更します。デュアル書き込み戦略の採用は、アプリケーションへの (通常は重要な) 変更を伴うため、より複雑で時間のかかるフォールバックアプローチの 1 つです。ただし、ターゲットデータベース B への書き込みを停止するだけなので、デュアル書き込み構成からのフォールバックは簡単です。次の状況では、デュアル書き込み戦略が適切な場合があります。 データが (おそらく顧客ごとに) 分割されており、アプリケーションの移行に段階的なアプローチを採用している。このシナリオでは、DMS を使用して新しいターゲットをハイドレートし、ソースと同期させます。カットオーバーでは通常、デュアル書き込み機能を有効にし、DMS […]

Read More

AWS DMS タスクのための AWS CloudFormation テンプレート作成の自動化

前回の記事、「Microsoft Excel を使用した AWS DMS タスクのための AWS CloudFormation テンプレートの作成」をさらに詳しく説明するこの記事では、データベース移行を迅速化することができる、同じツールの拡張機能を取り上げます。 この機能を実証するため、Python で記述された小型のコマンドラインツールをご紹介します。このツールは、入力としての使用するために、移行されるテーブルの名前、AWS DMS エンドポイントの Amazon リソースネーム (ARN)、および DMS レプリケーションインスタンスが含まれた CSV ファイルを取り込みます。正常に実行されたら、このツールは、必要な DMS タスクの AWS CloudFormation テンプレートを出力として生成します。ただし、このツールは DMS エンドポイントとレプリケーションインスタンスの作成には対応しません。 前提条件 このツールを使用するには、以下のリソースが必要となります。 Python (バージョン 2.7 以降)。Python 2.7.15 をインストールするには、Python.org のダウンロードページをご覧ください。 DMS のソースエンドポイントとターゲットエンドポイント、および DMS レプリケーションインスタンス。 CSV テンプレートの作成 最初に、作成する DMS タスクに関するすべての情報を CSV ファイルに取り込みます。以下は、DMS タスクを作成するために必要な項目のリストです。 DMS タスクの名前 ソースエンドポイント ターゲットエンドポイント 使用するレプリケーションインスタンス 移行するテーブルのスキーマ名 移行するテーブルの名前 […]

Read More

AWS DMS バージョン 3.1.3 を使用したデータ変換

AWS は最新の AWS Database Migration Service (AWS DMS) バージョン 3.1.3 の新しいデータ変換機能をサポートするようになりました。スキーマ、テーブル、および列の名前を変更し、Oracle ターゲットの個々の表領域名を指定し、そして任意のターゲット上のテーブルの主キーと一意キーを更新することができます。DMS バージョン 3.1.3 は、以下の新しいデータ変換機能をサポートしています。 明示的なテーブルマッピング Oracle のソースおよびターゲットの表領域の変換規則 Oracle のソースおよびターゲットの索引表領域の変換規則 主キーまたは一意キーのインデックスの定義 対象列のデータ型の変更 明示的なテーブルマッピング 以前の DMS バージョンでは、AWS マネジメントコンソールを使用してテーブルマッピングを実行したり、テーブル選択を指定したり、スキーマやテーブルのルールアクションを変換したりしていました。 バージョン 3.1.3 では、AWS DMS により明示的なテーブルの選択を行えます。明示的なテーブルマッピングルールを使用すると、サポートされている DMS ターゲットへの移行用に特定のソーステーブルを選択できます。また、より良い粒度のためにソースからテーブルのサブセットを除外します。明示的な選択規則を使用するときは、テーブルマッピングのスキーマ名とテーブル名にワイルドカード (%) を使用することはできません。 次の例では、ソースに 7 つのテーブルがあります。明示的な変換規則を使用すると、残りのテーブルを移行から除外する一方、DEPT テーブルのみを移行することを選択できます。 SQL> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_CATALOG LIKE %DEPT%’ TABLE_NAME —————————— HRDEPT DEVDEPT SUPPORTDEPT PMDEPT […]

Read More

AWS Database Migration Serviceのターゲットとしての Amazon Elasticsearch Service の導入

AWS Database Migration Service (AWS DMS)の新しいターゲットをさらに—Amazon Elasticsearch Serviceへの新しいターゲットの追加を発表しました。これで、AWS DMSでサポートされているすべてのソースからAmazon Elasticsearch Service にデータを移行できます。この新しいターゲットのサポートで、データ統合パイプラインで DMSを使用し、ほぼリアルタイムで Amazon Elasticsearch Serviceにデータを複製できます。 Amazon Elasticsearch Serviceは、大規模かつ簡単にElasticsearchの展開、保護、操作が可能な完全に管理されたサービスです。本サービスは、オープンソースのElasticsearch API操作、管理されたKibana、およびLogstashと他のAWS serviceとの統合を提供します。これらの機能を使用すると、ログ分析、全文検索、アプリケーション監視、およびセキュリティ解析のユースケースをリアルタイムで検索、分析、視覚化することができます。 Amazon Elasticsearch Serviceを使用した検索は強力ですが、複数のデータストアからAmazon Elasticsearch Serviceへのデータの簡単な取得が可能にすることを考えていました。当社はある時点からのバルクデータのロードの可能性の確認を願っていました。また、必要に応じて転送中のデータの結合とマッピングを完全にサポートし、変更データがほぼリアルタイムで複製されるようにしたいと思っていました。AWS DMS は、現在 サポートされているソース からどのデータの移行にも役立ちます。DMSを使用すれば、必要なデータをより迅速かつ安全に移行できます。 データの分析と処理を実行したり、または電子商取引や検索サービスのビジネスに携わっている多くの大企業や技術ベンチャーは、すべてデータに関連しています。巨大なデータベースで直面する最も一般的な問題は、製品情報を検索する際の待ち時間に関連したものです。この遅延は、ユーザーエクスペリエンスの低下につながり、見込み客にそっぽを向かれることになります。データ量が増えるにつれて、大きなウェブページの応答時間の提供はさらに困難になっています。ユースケースはますます複雑になり、組織は数百万件、時には数十億件のデータベース記録を管理しているにもかかわらずつ、わずかなページの読み込み時間しか提供していません。この問題は、大きなデータセットの検索とフィルタリングによって悪化します。複雑で動的なフィルタを使用しても、数十億の記録をめくるために関連データベース(Oracle、SQL Serverなど)を拡張するには、多くの専門知識を必要とします。 今日のビジネスには、迅速に検索を促進するためにデータが格納される場所の代替案を探しています。これは、データの格納に関連データベースではなく、NoSQLを採用することで実現できます。Amazon Elasticsearchは、フルテキストの分散型NoSQLデータベースです。つまり、スキーマや表ではなく文書を使用するので、データのリアルタイム検索と分析が可能となります。人がこのシステムを高く評価しているのは、データに基づいた測定基準が即座に実行可能であるため、継続的に即座に理解できるためです。 以下は、Elasticsearchが性能に適している使用例です。 すべての行を索引付けし、これらのフィールドのブール値の組み合わせでフィールド検索を提供する 関連するフリーテキスト検索を提供する自然言語テキストによるネイティブ処理 関連した結果の提供 オートコンプリートと検索候補の提供 ファセット加工とファセットドリルダウンをサポート 地元検索のためのサポート日とGEOの場所 Amazon Elasticsearch Serviceは、検索エンジンの最良の情報に基づいて記録とソートされた結果を提供し、一般には素晴らしいです。おおよその回答を見つけることは、より伝統的なデータベースからAmazon ESを差別化するプロパティです。 要約すると、AWSは皆様のユースケースと要件に合わせたアプリケーションとデータベースの再構築の支援を目的としています。AWS DMSを使用してAmazon ESにデータの移行と複製のためのサポートの追加により、柔軟性は向上します。また、RDBMSからAmazon ESへのデータの移行の際に提供するアプローチは、あまり複雑ではありません。 Amazon Elasticsearch Serviceをターゲットとしてサポートする機能の一部は、以下のとおりです。 Amazon Elasticsearch Serviceの全バージョンがサポートされています。この文書に詳細があります。 […]

Read More

AWS Database Migration Service と AWS Schema Conversion Tool がソースとしての IBM Db2 LUW をサポート開始

AWS SCT がLinux、UNIX、Windows (LUW) 用の IBM Db2 からAWS上でサポートされているオープンソースデータベースにオブジェクトを変換できるようになりました。これには Amazon RDS for PostgreSQL と RDS for MySQL、Amazon Aurora (MySQL and PostgreSQL compatible) を含みます。同時に、AWS DMS のソースとしての IBM Db2 for LUW の一般リリースも発表します。この発表は、AWS DMS を使用して Db2 for LUW から AWS DMS でサポートされているすべてのターゲットに移行できることを意味します。これらの機能は、Db2 for LUW からクラウドへの移行に役立ちます。

Read More

AWS DMS を使用して Oracle ASM からAWSに移行する方法

このブログ記事では、ストレージインフラストラクチャが Oracle ASM のOracleソースエンドポイントでの AWS Database Migration Service (AWS DMS) の Change Data Capture (CDC) の使い方について説明します。

Oracle 自動ストレージ管理 (ASM) データベースフレームワークは、Oracleデータベースファイル用のボリュームマネージャとファイルシステムを提供し、シングルインスタンスの Oracle Database と Oracle Real Application Clusters (Oracle RAC) をサポートしています。ASMにはファイルシステムとデータベース内のボリュームを直接管理するためのツールがあります。これらのツールを使用すると、データベース管理者 (DBA) は標準的なOracle環境で使いなれたSQL文を使用してボリュームやディスクを制御できます。

Read More

分散型可用性グループを使用して、ハイブリッドMicrosoft SQL Serverソリューションを設計する方法

モノリシックでミッションクリティカルなMicrosoft SQL ServerデータベースをオンプレミスからAWS(Amazon EC2ベースのSQL Server)に移行することは、しばしば困難な作業です。主な課題は次の通りです: 継続的なダウンタイム – ビジネスに悪影響を及ぼす可能性のあるカットオーバー中の継続的なダウンタイムウィンドウが発生する課題 データ同期の課題 – オンプレミスに配置されたデータベースとAWS上のデータベースを同期した状態に維持するための課題 柔軟性の欠如 – 移行のための段階的なアプローチを計画・実行する為の柔軟性を確保する課題 この記事では、重要なSQL ServerデータベースをAWSにリフト&シフト(またはリフト&トランスフォーム)するためのハイブリッドソリューションの構築方法について詳しく説明します。このソリューションでは、SQL Server 2016で導入された新しい機能である分散型可用性グループを使用します。この記事では、分散型可用性グループを使用して移行を制御し、柔軟性を高める段階的アプローチについても説明します。 分散型可用性グループの概要 分散型可用性グループは、2つの個別の可用性グループにまたがる特別なタイプの可用性グループ(AG)です。分散型可用性グループは複数の可用性グループの1つ(または複数のAGの中の1つ)と考えることができます。基礎となる可用性グループは、2つの異なるWindows Server Failover Cluster(WSFC)で構成されます。 分散型可用性グループアーキテクチャは、既存のオンプレミスWindows Server Failover Cluster(WSFC)をAWSに拡張するよりも効率的です。データは、オンプレミスのプライマリからAWS上の1つのレプリカ(フォワーダ)にのみ転送されます。フォワーダは、AWS上の他のリードレプリカにデータを送信する役割を担います。このアーキテクチャにより、オンプレミスとAWSの間のトラフィックフローが削減されます。 アーキテクチャ概要 次の図は、ソリューションの全体的なアーキテクチャを示しています。 図に示されているように、最初のWSFCクラスタ(WSFC1)はオンプレミスでホストされています。オンプレミス可用性グループ(AG1)はこのWSFCクラスタに配置されます。 2番目のWSFCクラスタ(WSFC2)はAWSでホストされます。 AWS可用性グループ(AG2)はこのWSFCクラスタに配置されます。 このユースケースでは、オンプレミスのSQL Serverインスタンスとデータベースは、従来の物理サーバーまたは仮想マシン(VM)によってホストされています。 AWSのSQL ServerインスタンスはAmazon EC2でホストされ、SQL ServerデータベースはAmazon EBSボリュームで構成されます。 AWS Direct Connectによって、オンプレミスからAWSへの専用ネットワーク接続を確立しています。 前述のアーキテクチャ図に示すように、オンプレミス可用性グループ(AG1)には2つのレプリカ(ノード)があります。これらの間のデータ転送は、自動フェイルオーバーを使用して同期します。オンプレミスレプリカの1つに障害が発生すると、AGは2番目のレプリカにフェールオーバーすることで、アプリケーションとユーザーはDBを使用できます。各可用性グループは、1つのプライマリレプリカと最大8つのセカンダリレプリカをサポートしています。高可用性の要件と拡張性のニーズに基づいて追加のレプリカを同期または非同期にする必要があるかどうかを判断します。 AWS可用性グループ(AG2)にも2つのレプリカがあり、それらの間のデータ転送は自動フェールオーバーで同期しています。 EC2インスタンスまたは1つのアベイラビリティゾーンに障害が発生すると、AGは別のアベイラビリティゾーンにある2番目のEC2インスタンスにフェールオーバーします。 このソリューションの一環として、分散型可用性グループを構成します。このグループには、オンプレミス可用性グループ(AG1)とAWS可用性グループ(AG2)の両方が含まれます。分散型可用性グループは、前述の図において赤い点線で示すように、データベースを非同期で同期させます。 フォワーダ(前述の図で緑文字で表されている)は、AWS内の他のリードレプリカにデータを送信する役割を担います。このデータ転送により、オンプレミスとAWS間のトラフィックフローが減少します。オンプレミスからAWSへのデータ転送はプライマリレプリカから一度だけ実施され、フォワーダは残りの伝播を処理します。 どの時点でも、書き込みに使用できるデータベースは1つだけです。残りのセカンダリレプリカデータベースは読み取り用に使用できます。前述のサンプルアーキテクチャ図では、社内のプライマリデータベースを読み取り/書き込み可能にし、AWSセカンダリデータベースを読み取りに使用できます。 AWSでリードレプリカを追加できることが重要なメリットです。この能力があれば、AWSへの移行に際して、読取り専用アプリをAWSに最初に移行することができます。また、データベースは、AWS上のアプリケーションとそのユーザーにも近くなります。 読み込みのワークロードをスケールアウトする場合は、AWSにさらに多くのリードレプリカを追加できますし、複数のアベイラビリティゾーンに配置することも可能です。このアプローチは、以下のアーキテクチャ図で表されます。この図では3つの異なるアベイラビリティゾーンに、それぞれリードレプリカを配置しています。 段階的な移行方法 分散型可用性アーキテクチャを使用することで、段階的な移行が可能となり、移行における柔軟性を高めることができます。 フェーズ1 この段階では、ほとんどの読取り専用アプリケーションをAWSに移行して、AWS上の読取り専用セカンダリデータベースにアクセスします。読み取り/書き込みを行うアプリケーションは、引き続きオンプレミスのプライマリ・データベースにアクセスします。 クラウド移行のこのフェーズでは、ストレステスト、機能テスト、およびデータベース作業負荷の回帰テストが重要な要素です。読取りワークロードをサポートするためにEC2インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。 […]

Read More

Database Migration Playbook が公開されました!

Database Migration Playbooks(Amazon Web Services と NAYA Tech の共同プロジェクト)とは、異種間データベース移行計画を成功させるためのベストプラクティスに焦点を当てた一連のガイドです。このプレイブックは、AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Servies (AWS DMS) を含む、既存の自動化および半自動化されたAmazonデータベース移行ソリューションおよびツールを補完するものです。

「Oracle to Amazon Aurora Migration」プレイブックの初版では、Oracle 11g と12cのデータベース機能とスキーマオブジェクトを Amazon Aurora with PostgreSQL compatibility に移行するためのベストプラクティスに重点を置いています。移行するためには、PostgreSQLデータベースエンジン自体に組み込まれている機能と、様々なAWSサービスやソリューションの両方を使用しています。

Read More

AWS Database Migration Service のログ管理

AWS DMS を完全に管理できるように、レプリケーションインスタンスの移行ログを管理する機能をAWSは導入しました。この機能を使用することで、特定のレプリケーションインスタンスの各タスク用のログがどれくらいストレージを消費しているかを確認することもできます。さらに、この機能を利用すると、あなたが都合の良いときにログファイルをパージできます。

Read More

AWS Database Migration Service を使用した Amazon RDS for SQL Server の継続的なレプリケーションの紹介

AWS Database Migration Service (AWS DMS) とAmazon RDS for SQL Server が新たに Amazon RDS for SQL Server からの継続的なレプリケーションをサポートするという新機能を発表できることを嬉しく思います。AWS DMSは、データベースをAWSに迅速かつより安全に移行できるサービスです。また、AWS内のデータ移行にも使用できます。Oracle、Microsoft SQL Server、PostgreSQLなど、広く普及している商用およびオープンソースデータベース間でデータを移行できます。このサービスはSQL ServerからSQL Serverのような同エンジン間の移行と、SQL ServerからAmazon Aurora MySQLまたはSQL ServerからAmazon RDS for MySQLなどの異なるデータベースプラットフォーム間の移行の両方が可能です。 この記事では、Microsoft SQL Server からの継続的なレプリケーションプロセスの概要を簡単に説明します。また、MS-CDC(SQL Serverでの変更データキャプチャ)とAWS DMSを使用して、Amazon RDS for SQL Serverからの継続的な変更をストリーミングするための新機能も紹介します。   背景 AWS DMSは異なるエンジン間の移行(SQL ServerからMySQLへの移行など)用に設計されています。ただし、同エンジン間(SQL ServerからSQL Serverなど)の移行もサポートしています。これまではソースインスタンスで実際に行われていた変更にアクセスする必要がありました。 主キーを持つテーブルの場合、AWS DMSはデフォルトで以下のように使用されるように設計されています。 1.SQL Serverから進行中の変更を移行するタスクを設定すると、AWS DMSは最初に次のコマンドを使用してトランザクションレプリケーション用のデータベースを有効にします。 use master exec sp_replicationdboption […]

Read More