Amazon Web Services ブログ

Category: Migration

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

AWS Schema Conversion Toolでのスキーマ比較の紹介

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 […]

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

Schema Conversion Tool ブログシリーズ: ビルド 613 の新機能紹介

AWS Schema Conversion Tool (AWS SCT) は、データベースエンジン間で既存のデータベーススキーマを変換するのに役立ちます。リレーショナル OLTP スキーマまたはサポートされているデータウェアハウス OLAP スキーマから、Amazon RDS (たとえば、Amazon Aurora MySQL または Amazon Aurora PostgreSQL など) に変換できます。また、リレーショナル OLTP スキーマまたはサポートされているデータウェアハウス OLAP スキーマを Amazon Redshift に変換することもできます。サポートされているすべてのソースとターゲットについては、AWS のドキュメントを参照してください。 AWS SCT は 頻繁に更新されるツールの 1 つであり、新機能を組み込んだビルドがほぼ毎月リリースされます。機能リリースごとにリリースノートを提供していますが、それに加えて AWS SCT リリースのブログシリーズを開始し、各ビルドの重要な新機能を詳しく紹介していきます。 ロードマップはお客様の要望に基づいて構築されます。AWS SCT ユーザーとして、AWS SCT の新機能を確認したい場合は、こちらのブログ記事に自由にコメントしてください。お客様からのフィードバックをお寄せいただければ幸いです。また、AWS SCT 自体にフィードバックを残すこともできます (ヘルプに移動して [Leave feedback] を選択します)。 この記事では、本日リリースしたビルド 613 に含まれるいくつかの新機能を紹介します。このブログ記事で紹介する機能は次のとおりです。 Oracle から PostgreSQL […]

Read More

オンプレミス本番環境での大規模 SQL Server データベースを、Amazon EC2 へブートストラップする

このブログ記事では、PowerShell とネイティブの Microsoft SQL Server バックアップを使用して、オンプレミス SQL Server データベースを Amazon EC2 インスタンスに移行する方法について説明します。 原則として、オンプレミス SQL Server データベースを Amazon RDS に移行するために、できる限りのことを行うのがよいでしょう。この方法の詳細については、「Amazon RDS ユーザーガイド」、特にガイド内の SQL Server に関するトピックを参照してください。しかし、Amazon RDS がソリューションとして実行できない場合があります。だからこそ、あなたはこのブログ記事を読んでいるのかもしれません。 AWS では、オンプレミス SQL Server データベースを AWS に移行するためのたくさんの方法を用意しています。同種のデータベース移行には、ネイティブツールを使用することをお勧めします。異種間での移行、恐らく Amazon Aurora か Amazon RDS for PostgreSQL に移行する場合には、AWS Database Migration Service を使うのがよいでしょう。それ以外の場合は、ネイティブレプリケーションのオプションを使用してください。 この記事で説明するシナリオは、DBA チームが SQL .bak ファイルを Amazon S3 にアップロードするというケースです。カットオーバー時のダウンタイム中にチームが PowerShell ブートストラップスクリプトを実行すると、データベースが […]

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

AWS SCT と AWS DMS を使ってMySQLから Amazon Aurora に移行する方法

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。 データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。 一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。 多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。 このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。 同種間移行の方法 AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora […]

Read More

AWS Schema Conversion Tool によるTrimble社のデータベース移行を成功させた秘訣とは’s データベース移行の成功

Trimble 社の フィールドサービス管理部門 (FSM) でインフラストラクチャ運用部のディレクターである Todd Hofert 氏による寄稿。 状況 最近、 Trimble 社のフィールドサービス管理部門のインフラストラクチャ運用グループは、非公開でホストされている SaaS サービスをアマゾン ウェブ サービス (AWS) に移行する積極的な取り組みに着手しました。同部門は、ハードウェアのリフレッシュ、継続的なコスト削減の必要性、 AWS 上の同社の次世代プラットフォームと従来の商品を調和させたいという必要性に直面しました。これに対応して、 Trimble 社のインフラストラクチャチームは、データウェアハウスソリューションから始まる包括的な移行計画を策定しました。 コスト削減、可用性、スケーラビリティは、 AWS イニシアチブへの主な推進力でした。Trimble 社は、Oracle からオープンソースデータベースプラットフォームに移行することで、現在のライセンスコストを最適化することに決めました。また Trimble 社は、 Amazon RDS を使用してデータベースを動作させることで、信頼性を保証し、運用サポートの間接費を削減することにも力を入れました。 データベースの選択 Trimble 社の運用とデータベース開発チームは、 AWS チームを招き入れて、 Oracle から離れたデータベースプラットフォームへの移行に関する難易度を調べました。この評価の中心となったのは、 AWS Schema Conversion Tool (AWS SCT) 評価レポートでした。 Trimble 社のチームは AWS SCT を使用して、ソースである Oracle データベースと Amazon Relational […]

Read More