データベースをAmazon Web Servicesに簡単に移行

今日では、企業はデータベースなしではクラウドに移行できません。ただし、クラウド上にはさまざまな種類のデータベースが存在します。企業はどのように選択すべきでしょうか?データベースをクラウドに移行する手順は何ですか?企業はさまざまなビジネスシナリオでどのように選択すべきでしょうか?この記事では、Amazon Web Services のさまざまな一般的なデータベース機能と、顧客のさまざまなビジネスニーズを満たす方法について紹介します。また、データベース移行事例を一覧表示し、データベースを簡単かつ便利にクラウドに移行する方法を説明します。

1. Amazon Web Services データベースの概要

インターネットが高度に発達したこの時代では、私たち一人ひとりがさまざまな情報を受け取ったり生み出したりしています。データの重要性はあらゆる分野に浸透し、あらゆる産業の発展と変化に欠かせない要素となっています。 WeChat、Alipay、Weibo など、私たちが日常的に使用するモバイル アプリケーションのデータはすべて、保存するためにデータベースを必要とします。アプリケーションによって使用するデータベースのカテゴリは異なり、同じアプリケーションでも複数のデータベースを同時に使用する場合があります。

データベースのないアプリケーションは、水のない魚のようなものです。これは、今日のインターネットにおけるデータベースの重要性を示しています。今日、世界で最も価値のある資源はもはや石油ではなく、データであると言っても過言ではありません。ビジネスの急速な発展とグローバル ビジネスに対する新たな需要の増加により、ローカルの従来のデータベースでは、急速に成長するビジネスをサポートできなくなりました。ローカル データベースをクラウドに移行する新しい方法を模索し、クラウド データベースの利点を活用して、ローカル データベースで発生するボトルネックの問題を解決する必要があります。

さまざまなクラウドベンダーが提供するデータベースの種類を比較したところ、Amazon Web Services が最も多様な種類のデータベースをユーザーに提供し、ほぼすべてのデータベース関連のアプリケーションシナリオに対応していることがわかりました。以下は、Amazon Web Services が提供するデータベースの種類を参照するためのリストです。その中でもリレーショナル データベースは最も豊富であり、最も広く使用されているデータベースでもあります。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

上記のデータベースは Amazon Web Services によって完全に管理されており、ユーザーは基盤となるハードウェア システムのアップグレードやメンテナンス、その他の関連タスクを管理する必要がありません。これは、独自に構築したデータベースではなく、完全に管理されたデータベースを使用することを推奨する理由でもあります。顧客のデータベースのクラウドへの移行を容易にするために、Amazon Web Services は、ユーザーが移行タスクを簡単、経済的、効率的に完了できるように、非常に便利な移行ツールである DMS も顧客に提供しています。

では、非常に多くの種類のデータベース、特にこれまで使用したことのない新しいデータベースがある場合、どのように選択すればよいのでしょうか?ビジネスシナリオに基づいて、どのデータベースを使用するかを分析する必要があります。以下では、Amazon Web Services データベースの使用シナリオについて簡単に紹介します。これにより、誰もがさまざまな Amazon Web Services データベースのアプリケーション シナリオを大まかに理解できるようになります。

さまざまな Amazon Web Services データベースのアプリケーション シナリオを事前に理解した後、さまざまな Amazon Web Services データベースの機能と、Amazon Web Services データベースがさまざまなビジネス シナリオでユーザーのニーズを満たす方法について詳しく説明します。

データベース ファミリ

リレーショナルデータベース

リレーショナル データベースは、非常に古い歴史を持つデータベースであり、現在ではさまざまなアプリケーションで最も広く使用されているデータベースです。さまざまなアプリケーションを使用する際にはユーザーを登録する必要があり、これらのユーザーデータはリレーショナル データベースに保存されます。電子商取引のウェブサイトで注文すると、その注文はリレーショナル データベースにも保存されます。私たちが訪問するウェブサイトのバックグラウンドデータもリレーショナルデータベースに保存されます。つまり、リレーショナル データベースはどこにでもあります。

Amazon Web Services のリレーショナル データベースといえば、Amazon Aurora を挙げなければなりません。 Aurora は、Amazon Web Services によってクラウド専用に構築されたクラウドネイティブ データベースです。 MySQL および PostgreSQL と互換性があります。優れたパフォーマンス、容易なスケーラビリティ、セキュリティ、容易な管理を備え、リレーショナル データベースのさまざまなアプリケーション シナリオをサポートできます。 Aurora は非常に使いやすく、次の機能も備えています。

• コスト効率: スループットは標準 MySQL の 5 倍、標準 PostgreSQL の 3 倍で、コストは商用データベースの 10 分の 1 にすぎません。
• スケーラビリティ: 共有ストレージに基づくマスター/スレーブ レプリケーションはレイテンシが低く、3 つのアベイラビリティ ゾーンにわたって最大 15 個の読み取り専用レプリカに拡張できます。
• 可用性と耐久性: フォールト トレラントな自己修復型ストレージ。 3 つのアベイラビリティ ゾーンにわたる 6 つのデータのコピー。 S3 への継続的なバックアップ。
• セキュリティ: VPC ネットワークの分離、静的/トランジット データの暗号化、ほとんどのリージョンのコンプライアンス要件への準拠。
• グローバル データベース: データベースは複数の Amazon Web Services リージョン間で同期的に複製され、データベースがユーザー側に配置され、低レイテンシ (通常のレイテンシは 1 秒未満) のローカル読み取りとリージョン間の災害復旧が可能になります。
• サーバーレス：基盤となるハードウェアの拡張を気にすることなく、ワークロードに応じて容量を自動的に拡張および縮小できるため、変動の激しいビジネスアプリケーションに適しています。

Aurora には従来のデータベースにはない多くの機能があり、リレーショナル データベースの第一選択肢となっています。ただし、データベースの種類を変更せず、既存のローカル データベースをクラウドに移行する場合、Amazon Web Services は、MySQL、MariaDB、PostgreSQL、SQL Server、Oracle などのリレーショナル データベースもユーザーに提供しています。お客様は、移行に同じデータベース エンジンを選択できます。さらに、これらのデータベースは Amazon Web Services の強力なインフラストラクチャと管理に依存しており、安全性と安定性も同様に優れています。

Aurora が本当に魅力的で、現在 SQL Server または Oracle を使用している場合はどうでしょうか?心配しないでください。Amazon Web Services は、スキーマ変換ツールと DMS という 2 つのサービスを顧客に提供しており、顧客がデータベース オブジェクトを評価および変換し、ローカル データベースを Aurora に非常に簡単に移行するのに役立ちます。

キーバリューデータベース

今日のインターネットの発展に伴い、データ テーブルはますます大きくなり、一部のアプリケーションでは高速な書き込みと読み取りが求められています。リレーショナル データベースではもはやニーズを満たすことができなくなったため、NoSQL データベースが誕生しました。パフォーマンスの問題を解決するために、リレーショナル クエリを必要とせず、高速な読み取りと書き込みを必要とする一部のアプリケーション データを NoSQL データベースに配置します。

Amazon Web Services では、顧客のニーズを考慮して、キー値ストレージとドキュメント ストレージをサポートする自社開発の NoSQL データベース Amazon DynamoDB も顧客に提供しています。特に、キーバリューストレージを中核としており、膨大なデータを扱う際に非常に強力なパフォーマンスを発揮します。これは Amazon Web Services によって完全に管理されているため、サーバーレス アーキテクチャの重要なメンバーでもあります。

• スケーラビリティ: テーブルを自動的にスケールアップおよびスケールダウンして容量を調整し、パフォーマンスを維持し、あらゆるレベルのリクエスト トラフィックに対応します。
• 高いパフォーマンス: 一般的なリクエストの場合、DynamoDB は 1 桁のミリ秒以内にリクエストを完了し、データ量が増加してもリクエストの処理速度が低下することはありません。
• 分散型: 分散型アーキテクチャ。テーブル内のデータは数百台のマシンに分散できます。

また、Amazon Web Services の公式チャンネルから、Mobvista が広告会社であることを知りました。また、Amazon Web Services のサービス、特に広告クリックに関するデータを多く使用しています。同社は DynamoDB データ ストレージを使用しており、2019 年には 1 日平均 600 億件、ピーク時には最大 1,000 億件の広告リクエストをサポートできます。このような膨大な数のリクエストはリレーショナル データベースではサポートできません。これは、このアプリケーション シナリオで DynamoDB がいかに強力であるかを示しています。

文書データベース

JSON データは無数にあり、非常に柔軟な形式であるため、データのスキーマを簡単に変更できます。軽量なデータ交換形式です。現在、最も広く使用されている API 標準は RESTfull API であり、その出力標準も JSON です。データ モデリングに JSON を使用することは、人間の言語のロジックと最も一致しています。上記のすべての使用シナリオでは、リレーショナル データベースでもキー値データベースでもない、JSON データを格納するためのドキュメント データベースが必要です。

ドキュメント データベースはどのようなアプリケーション シナリオで使用されますか? JSONデータの柔軟性により、ドキュメントデータはさまざまな分野に浸透しています。例えば、ゲームではユーザー情報や装備ポイントなどを保存します。物流においては、注文情報や注文ステータスを保存します。ソーシャルネットワーキングでは、ユーザー情報やユーザーが投稿した友人サークル情報を保存します。ライブ動画ではユーザー情報やギフト情報などを保存します。

顧客のこのような使用シナリオに対応するために、Amazon Web Services は顧客に DocumentDB データベースを提供しています。名前の通り、MongoDBと互換性のあるクラウドネイティブのドキュメントデータベースです。 DMS や mongodump/mongorestore などのネイティブ メソッドを使用して、既存の MongoDB データベースを Amazon Web Services に移行できます。

DocumentDB は非常にスケーラブルで、数分で最大 15 個の読み取りレプリカまで水平に拡張できます。垂直拡張も数分で、最大 768 GiB のメモリまで拡張できます。ストレージは自動的に拡張され、最大 64TB までサポートされます。これらの機能は、独自のデータベースを構築する場合には実現が困難です。

インメモリデータベース

最近では、アプリケーションはますます大きくなり、その多くが分散アーキテクチャやマイクロサービス アーキテクチャを採用し始めています。現時点では、ユーザー セッション情報を保存するためのリポジトリが必要です。そうしないと、ユーザーが頻繁にログイン状態になる可能性があります。一部のアプリケーションでは、データクエリ速度を向上させる必要があり、そのためにはデータベースにキャッシュレイヤーを追加する必要があります。上記のすべてのアプリケーション シナリオでは、インメモリ データベースが必要になります。

Amazon Web Services は、クラウド内で完全に管理されたインメモリデータベースである Amazon ElastiCache も顧客に提供しており、顧客はここにホットデータ、セッションデータ、メッセージデータ、ランキングデータなどを格納して、データアクセスを高速化できます。 Memcached と Redis の 2 つのストレージ エンジンをサポートしています。

• 極めて優れたパフォーマンス: 1 ミリ秒未満の応答時間を必要とする最も要求の厳しいアプリケーションをサポートできます。
• 簡単なスケーラビリティ: AWS マネジメントコンソールまたはシンプルな API を使用して、ユーザーはアプリケーションのニーズに基づいてキャッシュ クラスターにノードを追加したり、キャッシュ クラスターからノードを削除したりできます。
• セキュリティ: Amazon VPC をサポートし、ネットワーク分離を実行できます。セキュリティ グループを使用して、クラスターのアクセス権限を管理します。
• 高可用性: 2 ～ 6 個のノードをレプリケーションを使用してクラスターにグループ化できるため、何らかの理由で 1 つのノードに障害が発生しても、すべてのデータが失われることはありません。

グラフデータベース

当社にはリレーショナル データベース、キーバリュー データベース、インメモリ データベースがあり、基本的にほとんどのアプリケーションの日常的なニーズを満たすことができます。しかし、Amazon Web Services ではこれでは不十分です。ユーザーはパフォーマンスの問題やスキーマの変更の難しさにも直面していたため、Amazon Web Services はグラフ データベース Neptune を立ち上げました。

グラフデータベースはソーシャルネットワーク データの処理に非常に効率的であり、Amazon Neptune は大量のユーザー プロファイルとインタラクションを迅速かつ簡単に処理して、ソーシャル ネットワーク アプリケーションを構築できます。

時系列データベース

時系列データベースは、その名前が示すように、時間に関連するデータベースです。多くのデータクエリは期間に基づいているため、IoT および運用アプリケーションに適しています。そのため、Amazon Web Services は、時系列データの処理に特化して設計され、現在は登録済みのプレビュー バージョンである Amazon Timestream をユーザーに提供しています。

元帳データベース

元帳データベースの利用シナリオも分かりやすく、最も適したシナリオは「会計帳簿」です。 「元帳」は変更できず、すべての記録を改変することもできません。将来の参考のために忠実に記録されます。 Amazon Quantum Ledger Database が誕生しました。

これは「ブロックチェーン」に少し関連しているように聞こえますが、QLDB は集中型であるのに対し、「ブロックチェーン」は分散型です。そこで、Amazon Web Services には分散型データベースがあるのだろうかと疑問に思うかもしれません。答えは「はい」です。それが Amazon Managed Blockchain です。 Amazon Web Services に存在しないデータベースがどのようなものか想像するのは困難です。ユーザーが必要とするものもあれば、ユーザーが必要としないものもあります。全てが揃っていると言ってもいいでしょう。

移行ツール

私たちは、日常のアプリケーションのほぼすべてのニーズを満たす、数多くのデータベースと、さまざまなデータベースの使用シナリオと機能を紹介してきました。次に、これらのデータベースの使用方法と、現在ローカルで独自に構築したデータベースをクラウドに移行する方法を知りたいと思うはずです。ここでは、Amazon Web Services が提供する移行ツールである Amazon Database Migration Service と、DMS がどのようにしてお客様がクラウド内のデータベースにデータを簡単かつ効率的に移行できるようにするかを紹介します。

DMS も完全に管理されているため、移行タスクに集中できます。 DMS は、移行ソースとして複数のデータベースをサポートし、移行ターゲットとしても複数のデータベースをサポートします。次の表に、サポートされているデータベースの詳細を示します。

表からさまざまなデータベース エンジンを確認できます。 Amazon DMS は、MySQL から MySQL などの同種データベースの移行と、Oracle から MySQL などの異種データの移行をサポートしています。異種データベースの移行プロセス中に、Amazon Web Services は、Amazon SCT を使用してソース データベース スキーマとほとんどのオブジェクトをターゲット データベースと互換性のある形式に自動的に変換できるツールである Amazon Schema Conversion Tool もユーザーに提供します。

DMS の概要は、次の小さな機能に簡単にまとめることができます。

• 使いやすい
• ダウンタイムを最小限に抑える
• 継続的なデータレプリケーション
• 複数のデータソースのサポート
• 信頼性の高い操作

Amazon DMS は、データベースの複製と移行に最適なツールであり、ユーザーがデータベースのワークロードを Amazon Web Services に移行し、最小限のダウンタイムでデータベース エンジンを変更するのに役立ちます。 Amazon Web Services によると、Amazon DMS を使用して 20,000 個のデータベースが Amazon Web Services に移行されています。この製品の使用が広く成功している以上、データベースを Amazon Web Services に移行しない理由はありません。それでは、データベース移行の旅を始めましょう。

移行方法

すべてのデータベースには独自のバックアップおよび復元ツールがあります。これらのツールを使用すると、オフラインでデータを簡単に移行できますが、主にデータの量に応じて長いダウンタイムが発生します。ダウンタイムを最小限に抑える必要がある場合は、DMS が最適な選択肢です。以下に、さまざまな移行方法がビジネスに与える影響を大まかに示します。実際の状況に応じて選択できます。

2. クラウド上でのデータベース移行の実践

移行ソリューション

当社では、ローカル データ センターにさまざまな自社構築データベースを保有しています。データベースをクラウドに移行する場合、クラウド内のデータベースをどのように選択すればよいでしょうか?以下に簡単なリストをまとめました。さまざまなシナリオに応じて適切なソリューションを選択できます。

• 既存のアプリケーション
  • MySQL ---> Amazon Aurora for MySQL、RDS for MySQL
  • PostgreSQL ---> Amazon Aurora for PostgreSQL、RDS for PostgreSQL
  • MariaDB ---> MySQL 用 Amazon Aurora、MariaDB 用 RDS
  • Oracle ---> Amazon SCT による複雑性要因の検出 ---> Amazon Aurora、RDS for Oracle
  • SQL Server ---> Amazon SCT を使用して複雑性要因を検出する ---> Amazon Aurora、RDS for SQL Server
  • MongoDB ---> ドキュメントDB
• 新しいアプリケーション
  • リレーションシップ機能が必要ない場合 ---> Amazon DynamoDB
  • リレーションシップクラスの機能が必要な場合 ---> Amazon Aurora
• メモリ保存/キャッシュ
  • Redis ---> Amazon ElasticCache
  • Memcached ---> Amazon ElasticCache
• 時系列データ
  • Amazon Timestream (プレビューにサインアップ)
• 各アプリケーション、暗号検証可能性、中央の信頼できる機関への変更を追跡する
  • Amazon Quantum Ledger データベース

移行に関する注意事項

データベースはあらゆるアプリケーションの主要コンポーネントの 1 つであるため、移行は慎重に行う必要があります。データベースのサイズ、データベース内のテーブルのサイズ、およびデータベース スキーマを知っておく必要があります。

Amazon DMS を使用すると、Amazon Web Services へのデータの移行が簡単になります。まず、Amazon Web Services 環境でレプリケーションインスタンスを作成し、Amazon DMS がソースデータベースエンドポイントとターゲットデータベースエンドポイントを接続します。移行が開始されると、Amazon DMS はテーブルを作成し、データをロードし、データベースを同期します。レプリケーション タスク全体は、レプリケーション インスタンスによって実行されます。より大きな構成のレプリケーション インスタンスを作成することをお勧めします。

Amazon DMS を使用して移行を実行するための大まかなプロセスは次のとおりです。

1. ターゲット データベースを作成します。
2. スキーマをコピーします。
3. Amazon DMS レプリケーションインスタンスを作成します。
4. ソース データベースとターゲット データベースのエンドポイントを定義します。
5. 移行タスクを作成して実行します。

MySQL データを Aurora MySQL に移行する

このケースは、比較的単純な同種データベースの移行です。移行ソリューションは 3 つあります。 mysqldump を直接使用してデータをエクスポートし、それを Aurora にインポートすることができます。これは、データ量が少ないデータベースに適しています。もう 1 つの方法は、データベースのソース ファイルを S3 ストレージ バケットに直接コピーすることです。 Xtrabackup を使用してデータベースをバックアップし、S3 に転送してから、これらのファイルを使用して Aurora データベースに復元できます。これは比較的大量のデータに適しています。ただし、両方のデータベースはオフラインで送信されるため、移行にはダウンタイムが必要です。

リアルタイムのオンラインデータベース移行には、Amazon DMS を使用する必要があります。以下では、MySQL データベースから Aurora にデータをリアルタイムに移行する方法を説明します。ソース データベースには、Amazon RDS、EC2 上に独自に構築したデータベース、または別のクラウド ベンダーの MySQL データベースを使用できます。以下では、デモンストレーションのために EC2 上で独自に構築したデータを使用することを選択したため、すべての操作は Amazon us-east-1 リージョンで行われます。

1. ソースデータベースを構成する

ソースデータベースはすでにあります。データ移行のために、読み取り専用権限を持つ一時アカウントを作成できます。ここでは、デモ用に読み取り/書き込み権限を持つアカウントを使用します。

2. Auroraデータベースを作成する

まず、Amazon Web Services コンソールでターゲット データベースとして Aurora MySQL データベースを作成します。ここではデータベース作成を主に紹介するわけではないので、作成プロセスについてはここでは説明しません。作成が完了したら、データベース アドレス、アカウント パスワードを記録する必要があります。もちろん、セキュリティ上の理由から、移行用の一時アカウントを作成することもできます。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

3. レプリケーションインスタンスを作成する

Amazon DMS レプリケーションインスタンスは、ソースとターゲット間の実際のデータ移行を実行します。レプリケーション インスタンスはデータ移行全体を担当し、変更されたデータをキャッシュするため、インスタンスが大きいほどパフォーマンスが向上し、移行時間が短縮されます。 Amazon DMS コンソールを開き、「レプリケーションインスタンスの作成」を選択します。ネットワークの制限に注意してください。レプリケーション インスタンスは両方のデータベースに接続できる必要があります。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

4. MySQLエンドポイントを作成する

Amazon DMS コンソールのナビゲーションペインで、[エンドポイント] を選択します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

5. Auroraエンドポイントを作成する

ターゲットエンドポイントの記述が簡単になります。 Amazon RDS なので、確認するだけです。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

6. 移行タスクを作成する

移行タスクでは、既存のデータをコピーし、変更されたデータを継続的にコピーする移行タイプを選択します。ソース データベースで binlog ログ記録を有効にすることを忘れないでください。

テーブル マッピング オプションで、移行するテーブルを DMS に指示することを選択します。移行プロセス中に、テーブル名を変換することもできます。ここでは、データベース全体を完全にコピーすることを選択します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

7. 移行タスクを監視する

しばらく待つと、タスクの詳細でデータ移行が完了し、ターゲット データベースのデータ チェックに問題がないことがわかります。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

DMS を介してデータベースを Amazon Web Services に移行するには、いくつかの簡単な手順を実行するだけで済み、ソース データベースで変更されたデータはターゲット データベースにリアルタイムで更新されることがわかります。

SQL Server データベースを Aurora MySQL に移行する

このケースは異種データベースの移行です。スキーマ変換には Amazon SCT を使用します。 Amazon DMS は RDS から RDS への移行をサポートしているため、今回のソースデータベース SQL Server は Amazon RDS for SQL Server (Enterprise Edition) となります。

スキーマ変換

1.ローカルコンピュータにAmazon SCTをインストールする

コンピュータに Amazon SCT ツールをインストールする必要があります。また、SQL Server に接続するための JDBC ドライバーと Aurora MySQL 用の JDBC ドライバーもインストールする必要があります。

ドライバーのダウンロードアドレスについては、公式ドキュメント https://docs.aws.amazon.com/zh_cn/SchemaConversionTool/latest/userguide/CHAP_Installing.html#CHAP_Installing.JDBCDrivers を参照してください。

次に、SCT を起動し、ダウンロードした JDBC ドライバーを構成します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

2. 移行プロジェクトを作成する

Amazon SCT を開き、新しいプロジェクトの作成を選択して、ソースおよびターゲットのデータ エンジンを選択します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

それぞれ SQL Server および Amazon Aurora データベースに接続します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

移行するデータベースをチェックし、右クリックして「レポートの作成」を選択します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

レポートをチェックして問題がないか確認してください。問題がなければ、そのまま変換を進めることができます。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

MySQL がサポートしていないストアド プロシージャに遭遇しました。ここでは無視しますが、データベースに詳しい人が修正してください。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

3. スキーマ変換

問題が解決したら、スキーマを変換できます。前と同様に、データベースを右クリックして「スキーマの変換」を選択します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

実行後、ターゲット データベースに変換されたスキーマがすぐに表示されます。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

データ移行

SQL Server のデータ移行では、継続的なレプリケーションを行わない 1 回限りの移行を選択します。継続的なレプリケーションの構成プロセスは少し複雑で、ソース データベースの構成が必要になります。継続的なレプリケーションが必要なユーザーは、Amazon Web Services の公式ドキュメントを参照して構成できます。

1. レプリケーションインスタンスを作成する

DMS コンソールを開き、レプリケーション インスタンスを作成します。ネットワークの状態にも注意してください。レプリケーション インスタンスは、ソース データベースとターゲット データベースをリンクする必要があります。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

2. Amazon DMSのソースエンドポイントとターゲットエンドポイントを作成する

ターミナルノードを作成したら、まずテストを実行して接続が成功していることを確認します。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

3. 移行タスクを作成する

以下の表に従って移行タスクを構成できます。

テーブル マッピングに関しては、テーブル名を変換せずに次のように設定して、タスクを作成できます。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

4. ターゲットデータベースのデータを確認する

ご覧のとおり、移行タスクは完了し、データが転送されました。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

これまでに、異種データベースの移行は完了しました。プロセス全体は同種データベースの移行よりも面倒ですが、全体的には比較的簡単です。 DMS は完全に管理され、従量課金制で、グラフィカル インターフェイスを使用します。これは、データベースをクラウドに移行するための強力なツールです。データベースをクラウドに移行するには、DMS を使用することをお勧めします。

結論

Amazon Web Services データベースの利点

多くのクラウドベンダーの中で、なぜ Amazon Web Services データベース サービスを選択するのでしょうか? Amazon Web Services 独自の利点は何ですか?主に以下の点をまとめます。

コスト優位性

自社で構築したデータを使用するには、まず企業がサーバーを購入するために一定の金額を支払う必要があり、一部の商用データベースの認証には別途料金を支払う必要があります。顧客が Amazon Web Services の自社開発データベースに移行すれば、高価な商用データベースライセンスを購入したり、サーバーを購入するために多額の費用を費やす必要がなくなります。クラウドでは、顧客は従量課金制で支払うだけで済みます。そのため、多くの企業はデータベースを Amazon Web Services に移行することで多額の費用を節約しています。

Amazon Web Services の最近の発表から、Amazon Web Services が Samsung のデータを商用データベース Oracle から Aurora に移行し、Samsung の月間データベース コストを 44% 削減し、Samsung のデータベース運用をより安定させるのに役立ったことがわかります。

完全管理

上記のデータベースはすべて、Amazon Web Services の完全マネージド型データベースです。完全に管理されているということは、運用とメンテナンスが不要であることを意味します。まず、お客様はハードウェアのライフサイクル、システム パッチの更新、高可用性の展開、バックアップなどを維持する必要がありません。データベースを拡張する必要がある場合は、マウス ボタンを数回クリックするだけで済みます。これは非常に便利であり、DBA は複雑なデータベース操作と保守から解放され、データベースのパフォーマンス チューニングに集中できるようになります。

グローバルな優位性

これまでは、高速で安定した安全なリージョン間データレプリケーションを実現するために、非常に複雑な技術的手段に頼り、多額の費用を費やし、ある程度の可用性を犠牲にする必要がありました。今では、Amazon クラウド テクノロジーでマウスを数回クリックするだけで実行できます。

Amazon Web Services は現在、世界中の 24 の地理的リージョンで 77 のアベイラビリティゾーンと 180 のエッジサイトを運営しており、Amazon Web Services の対応するグローバルデータベースの基本的なサポートを提供しています。 Amazon Web Services の強力なインフラストラクチャを活用し、現在、遅延が通常 1 秒を超えないグローバル同期をサポートする 3 つのデータベースがあり、ほとんどの現在のアプリケーションのニーズを満たすことができます。

リレーショナルデータベースのグローバル同期のニーズに対応するため、Amazon Aurora Global Database を使用すると、リージョン間でデータベースを簡単にデプロイでき、リージョン間でデータを簡単に複製して更新の競合を解決できるため、ユーザーはアプリケーションのビジネスロジックに集中できます。

Amazon Web Services では、Amazon DynamoDB グローバルテーブルも提供しています。これは DynamoDB のグローバル カバレッジに基づいて構築されており、マルチリージョン、マルチマスター テーブル機能を備えているため、グローバルに分散されたアプリケーションで高速なローカル読み取りおよび書き込みパフォーマンスを実現でき、ユーザーに完全に管理されたマルチリージョン、マルチマスターのキー値型データベースを提供します。

多くの組織が Redis を活用して世界中のユーザーに低レイテンシーのアクセスを提供しているため、Amazon Web Services (AWS) は顧客のニーズにさらに応えるために Redis 用の Amazon ElastiCache Global Datastore をリリースしました。グローバル キャッシュ データベースは、ユーザーにリージョン間のデータ レプリケーションを提供します。これにより、あるリージョンでデータを書き込むと同時に他のリージョンでデータを読み取ることができるため、キャッシュされたデータがユーザーの近くに配置され、ネットワークの待ち時間が短縮され、アプリケーションの応答性が向上します。

経験と提案

もちろん、データベースの移行は、特にデータベースをパブリック クラウドに移行する場合は、大規模で複雑なプロジェクトです。データベースの知識に加えて、ネットワーク、ストレージ、仮想化など、パブリック クラウドに関する一連の知識も理解する必要があります。ただし、クラウドへのデータベースの移行を複雑なタスクと見なすだけでなく、データベースを最適化する機会と見なす必要があります。では、移行プロセス中の注意事項と提案は何でしょうか?

ダウンタイムを許容する一部のアプリケーションでは、この部分のデータに対してオフライン移行を使用することをお勧めします。全体的な操作は比較的シンプルで高速であり、問​​題が発生する可能性も低くなります。

ビジネスでオンライン移行が必要な場合は、移行に DMS を使用することをお勧めします。データベースを切り替える前に、ソース データベースへの書き込みを停止し、データがターゲット データベースに完全に同期された後にデータベースを切り替えることに注意してください。

移行するデータの量が多い場合は、より大きな構成のレプリケーション インスタンスを選択することをお勧めします。これにより、レプリケーション速度が向上します。

データベース エンジンを変換する場合、スキーマ変換に SCT を使用すると、ターゲット データベースでサポートされていない領域がいくつか発生する可能性があります。これらの領域を変更するには、まず DBA スタッフに連絡し、満足のいく結果が得られたら変換してください。

Amazon Web Services ハッカソンに参加するための秘密は近日中に公開されます。 8 月 14 日午後 8 時に、Amazon Web Services の専門家が秘密を共有します。ライブ放送アドレス: http://live.bilibili.com/21988917

PS: Amazon Web Services クラウド コンピューティング コミュニティが設立されました。ここでは、Amazon Web Services クラウド コンピューティングの最新の開発についてすぐに理解し、関連する技術情報を入手できるようお手伝いします。グループに参加する場合は、QR コードをスキャンして [Amazon Web Services] と返信してください。 24 時間以内にグループへの参加が承認されます。