Category: Migration

 今回は、AWS Schema Conversion Tool (AWS SCT) 新バージョンをご紹介します。このバージョンには、テーブル値関数の変換のサポート、サーバーレベルの評価レポートへの追加情報などが含まれます。 AWS SCT とは、あるデータベースエンジン上の既存のデータベーススキーマを別のデータベースエンジン用に変換するためのツールです。リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon RDS に変換することができます。たとえば、MySQL や PostgreSQL などと互換性があるため、Amazon Aurora に変換できます。また、リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon Redshift に変換することも可能です。サポートされているすべてのソースおよびターゲットは、AWS SCT ドキュメントで確認できます。 以下に、この記事で説明するトピックの概要を示します。 Microsoft SQL Server から PostgreSQL へ – テーブル値関数の変換 SQL Server から PostgreSQL/MySQL へ – テーブル型変数の変換 SQL Server から PostgreSQL へ – MERGE ステートメントの実装 Oracle から […]

AWS Database Migration Service (AWS DMS) バージョン 2.4.3 についてご紹介します。これには、PostgreSQL 10 のネイティブパーティション表へデータを移行するサポートが含まれています。 この記事では、AWS DMS バージョン 2.4.3 を使用して Oracle パーティション表から PostgreSQL 10 のネイティブパーティション表へデータを移行する方法について説明します。これは特殊な設定をせずに行えます。AWS DMS と並行してパーティション表のスキーマ変換を実行するには、この変換をサポートするようになった AWS Schema Conversion Tool (AWS SCT) を使用できます。 PostgreSQL のパーティショニング パーティショニングは、論理的に 1 つの大きな表をより小さな物理的なピースに分割することを指します。パーティショニングにはいくつかの利点があります。 AWS DMS を使用してこの記事の説明に従ってパーティション表に移行する前に、PostgreSQL のパーティション表に精通している必要があります。PostgreSQL はバージョン 10 でネイティブパーティショニングサポートを導入しました。 以下は、Oracle パーティション表から PostgreSQL 10 ネイティブパーティション表にデータを移行する例です。ソースの Oracle パーティション表は、作成日の列に 3 つのパーティションが作成されます。すべてのパーティションは、それぞれの日付範囲の値に基づいてデータを保持します。 ステップ 1: レンジパーティション基準を使用して Oracle […]

Amazon RDS for MySQLでdelayed replicationをサポートしました。これにより、レプリカデータベースがソースデータベースより遅延する期間を設定できます。標準のMySQLレプリケーション設定では、ソースとレプリカの間の遅延が最小限に抑えられています。今回のアップデートで意図的な遅延を導入するオプションを選べるようになりました。 遅延は、人為的なエラーから復旧させる必要がある場合に非常に役立ちます。たとえば、誤ってプライマリデータベースからテーブルを削除した場合、レプリカで同じクエリを実行する必要はありません。テーブルが削除される直前でレプリケーションを停止し、レプリカをスタンドアロンインスタンスに昇格させることができます。このブログ記事では、delayed replicationを使用して、このようなシナリオから復旧させる方法をご紹介します。 次の図は、遅延が3600秒(1時間)に設定されたレプリカを人為的エラーから回復する方法を示しています。まず、レプリケーションを停止します。次に、ログの問題の箇所を見つけ、問題のクエリが実行される直前までトランザクションを実行し。最後に、レプリカをマスターに昇格させます。   前提条件 delayed replicationをチェックする前に、Amazon RDS for MySQLソースデータベースインスタンスでMySQL 5.6.40または5.7.22以降が必要です。また、インスタンスに接続するためのMySQLクライアントと、データベースにアクセスできる適切なセキュリティグループが必要です。 バイナリログを十分な時間保持していることを確認してください。バイナリログの詳細については、 MySQL Binary Logsを参照してください。次のコマンド例は、保持期限を24時間に設定する方法を示しています。 call mysql.rds_set_configuration(‘binlog retention hours’, 24);   シナリオの設定 既存のAmazon RDS for MySQLデータベースを既存のリードレプリカで使用するか、新しいデータベースを作成します。このブログ記事では、既存のRDS MySQLデータベースを利用し、新しい読み取りレプリカを作成します。 データベースの作成 MySQLインスタンス用のAmazon RDSをまだお持ちでない場合は、作成をしてください。クライアントマシンからのアクセスを許可するセキュリティグループを使用してデータベースを構成してください。作業したいMySQLデータベースがすでにある場合は、この手順をスキップしてください。 AWSマネージメントコンソール、AWS CLI、AWS SDK、またはAWS CloudFormationテンプレートを使用して、MySQLデータベース用のRDSを作成します。MySQLインスタンスの作成を支援する必要がある場合は、Create and Connect to a MySQL Database with Amazon RDSの手順に従ってください。次のスクリーンショットは、すでに設定されて使用可能な1つのデータベースインスタンスを示しています。 データベースに接続する マスターデータベース・インスタンスが作成されて使用可能になったら、そのデータベースインスタンスに接続します。Amazon EC2 Linuxマシンを使用している場合は、次のコマンドに示すように、いくつかの環境変数を設定して余分なタイピングを省くことができます。 export REGION=”us-west-2″ export […]

AWS は、AWS Identity and Access Management (IAM) や AWS Key Management Service (AWS KMS)　などのインフラストラクチャおよびサービスを保護する、セキュリティ機能を豊富に提供しています。AWS Data Migration Service (AWS DMS) を使うと、既存のデータベースから Amazon RDS にデータを簡単に自動移行することができます。その一環として、AWS DMS はいくつかの AWS セキュリティ機能を使用し、お客様にサービスを提供しています。例えば、DMS は他のセキュリティ機能の中でも、AWS KMS キーを使用した、静止状態でのデータベース接続およびデータ暗号化のための Secure Socket Layer (SSL) 暗号化を、すでにサポートしています。 それでも、クラウド内のデータベースに移行する際に、付加的な法令遵守の義務や特定のセキュリティポリシーに遭遇する企業もあります。こうした企業は、クラウド責任共有モデルの中でも、適切なデータ保護手段を利用する必要があります。このようなユーザーに、Baffle は最も重要なデータを保護する、列レベルの暗号化メカニズムを提供しています。企業は、DMS の使用中でもアプリケーションの変更を行わず、このメカニズムを実装できます。 アプリケーションを変更せずに暗号化できるこの機能により、既存のアプリケーションや新しいアプリケーションにデータのプライバシーを追加することが可能となります。バックエンド管理者またはサードパーティがアプリケーションデータにアクセスできないようにするのです。このアプリケーションの透過性とプライバシー保護は、DMS がデータベース間でデータを移行するのに使用するツールにまで及びます。これらのツールを使用すると、データを Amazon RDS に移行する際にデータを暗号化することができます。DMS とのカスタム統合なしでデータを暗号化でき、AWS への移行中および移行後にデータが公開されるリスクはほとんどありません。 このブログ記事では、Baffle の Advanced Data Protection ソリューションを使用して、RDS に移行するデータベースを暗号化する方法について解説します。Baffle のアプローチだと、データがクラウド上にある間に、メモリ内であろうと静止状態であろうと、確実にデータが保護されるようにします。以下に示すように、実際上、標準の DMS 移行ワークフローにはほとんど変更がありません。 […]

  Amazon RDS for Oracle および Oracle Active Data Guard スタンバイ向けの Binary Reader を、AWS Database Migration Service (AWS DMS) での移行のソースとしてサポートすることをお知らせします。 AWS DMS は、データベースを AWS に迅速かつ比較的安全に移行するのに役立ちます。AWS 内でデータを移行するのにも役立ちます。Oracle、Microsoft SQL Server、PostgreSQL など、最も広く使用されている商用データベースとオープンソースデータベースの間でデータを移行できます。このサービスでは、Oracle から Oracle のような同種移行をサポートします。また、Oracle から Amazon Aurora MySQL、Oracle から Amazon RDS for MySQL など、異なるデータベースプラットフォーム間の異種移行もサポートします。 今回のブログ記事では、Amazon RDS for Oracle で Binary Reader を備えた AWS DMS を使用する方法の概要をご紹介します。Oracle Active Data […]

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 からクラウドへの移行に役立ちます。

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group 私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。 しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか？ Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか？ Kepler Groupでは、インフラストラクチャの95％以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。   Global Fortune 100の例 私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。 今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。 このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました: データベースメンテナンスの負荷を低く抑える インフラストラクチャコストの制限 信頼性の高いバックアップおよびリカバリプロセスを確保する 前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました: v1.0：オンプレミスハードウェア上のLinuxでMySQLを実行する v2.0：Amazon EC2上のLinuxでMySQLを実行する v3.0：MySQLと互換性を持つAmazon Aurora 次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。   Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する 2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。 利点 この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。 チャレンジ しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。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文を使用してボリュームやディスクを制御できます。

AWS Schema Conversion Tool（AWS SCT）は、データベースの移行を予測しやすくします。これは、ソースデータベーススキーマとほとんどのデータベースコードオブジェクトを、ターゲットデータベースと互換性のあるフォーマットに、自動的に変換することで行います。 AWS SCTの新機能を発表し、同種のデータベース移行（つまり、OracleからOracleへの移行など）のためのスキーマ比較と同期が可能になることを嬉しく思います。スキーマ比較機能を使用すると、ソースデータベースからターゲットデータベースへのデータベーススキーマの比較や移行、変更が容易になります。 スキーマ比較は、Oracle、Microsoft SQL Server、PostgreSQL、およびMySQLと連携します。スキーマ比較は、これらのエンジンのすべての変種（オンプレミス、Amazon EC2、Amazon RDS、およびAmazon Aurora）と互換性があります。 スキーマ比較がなぜ必要なんですか？ これらのシナリオでは、スキーマ比較が必要です： AWSへの移行中にスキーマ比較機能を使用すると、社内運用データベースとAWSデータベースを同期させた状態に保つことができます。 開発、テスト、パフォーマンステスト、およびプロダクションを含む、すべての環境でデータベーススキーマを同期させることができます スキーマ比較は、メタデータの変更を伝達することで、アプリケーションのバージョンをアップグレードするときに役立ちます。 スキーマ比較は、ローカルスキーマ変更を共有データベースに伝達する際のチーム開発を支援します。 スキーマ比較を使用すると、スキーマの変更をスクリプトとして抽出し、ユーザーが移行スクリプトとロールバックスクリプトを作成できるようになります。また、ソースコントロールシステムの下にスクリプトを保存することもできます。 サポートされているデータベース これらのデータベース変換のために、スキーマ比較を使用できます： OracleからOracle、バージョン12.1.0.2.0、11.1.0.7.0、11.2.0.1.0 SQL ServerからSQL Server、バージョン2016、2014、2012、2008 R2、2008 PostgreSQLからPostgreSQLやPostgreSQLとの互換性があるAurora、バージョン9.6、9.5.9、9.5.4 MySQLからMySQL、バージョン5.6.36、5.7.17、5.5 スキーマ比較機能は、ターゲットデータベースのバージョンがソースデータベースのバージョンと同じかそれ以上の場合にのみ機能します。たとえば、ソースがOracleでバージョンが11.2.0.4の場合、この機能は対象のOracleデータベースがバージョン11.2.0.4か、それ以上の場合にのみ機能します。 SCTでこの機能を使用する方法 次のセクションでこの機能の使用方法を学びます。 スキーマ設定の比較 AWS SCTでは、現在のプロジェクト設定ページでスキーマ比較オプションを見つけることができます。スキーマ比較の設定は、[プロジェクト設定]ページの[スキーマの比較]タブで指定します。 2つのスキーマを比較するには 2つのスキーマを比較するには、次のステップを実行します： 既存のAWS SCTプロジェクトを開くか、プロジェクトを作成してソースエンドポイントとターゲットエンドポイントに接続します。 比較するスキーマを選択します。 コンテキスト（右クリック）メニューを開き、[スキーマ比較]を選択します。 AWS SCTは、オブジェクトのアイコンに黒丸を追加することによって、2つのスキーマ間で異なるオブジェクトを表示します。 ターゲット変更を適用する スキーマ比較の結果は、単一のオブジェクト、単一のカテゴリのオブジェクト、またはスキーマ全体に適用できます。これを行うには、AWS SCTで、結果を適用するカテゴリ、オブジェクト、またはスキーマの横にあるボックスを選択します。ソースデータベースからターゲットデータベースへの変更を適用するには、[ターゲットを適用]を選択します。 データベース上でスクリプト作成が成功したことを示すために、影響を受けるオブジェクトのアイコンが黒くなります。 エラーのあるオブジェクトを示すため、赤いエクスクラメーションマークがオブジェクトアイテムに表示されます。 機能の制限 すべてのスキーマを複製するサポートは、同種の移行でのみ使用できます。データとスキーマの順序付けは、特に同じオブジェクトが複数回変更された場合には、厳密には保証されません。また、スキーマの移行はユーザー、ロールなどを移行しません。 まとめ AWS SCTを使用すると、スキーマの変更をソースデータベースからターゲットデータベースに比較して移行し、データベースの稼働を続けることができます。この記事では、この機能を活用してAWSへのデータ移行を支援する方法について説明しました。 AWS SCTまたはAWS […]

モノリシックでミッションクリティカルな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インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。 […]