Amazon Web Services ブログ

Category: Migration

MySQLデータベースをAuroraへ移行する方法をマスターする

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への移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました: かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス […]

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

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