Category: Migration*


Amazon Kinesis を用いた Databaseの継続的な変更

Emmanuel Espina は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。

このブログ記事では、Amazon Kinesis を使用して変更をストリーミングすることによって、中央リレーショナルデータベース を他のシステムと統合する方法について説明します。

次の図は、分散システムにおける一般的なアーキテクチャ設計を示しています。これには、「」と呼ばれる中央ストレージと、この中央ストレージを消費するいくつかの派生「衛星」システムが含まれます。

この設計アーキテクチャを使用して、リレーショナルデータベースを中央データストアとして使用し、このシステムのトランザクション機能を利用してデータの整合性を維持することができます。このコンテキストにおける派生システムは、この変化の事実の単一ソースを観察し、それらの変更を変換し、フィルタリングし、最終的にはその内部インデックスを更新する全文検索システムとすることができます。もう 1 つの例は、OLAP クエリに適した列形式ストレージです。一般に、中央リレーショナルシステムの個々の行を変更する際にアクションを取る必要のあるシステムは、派生データストアに適した候補となります。

これらの種類のアーキテクチャの単純な実装では、変更された行を検索するために派生システムが定期的にクエリを発行し、本質的に SELECT ベースのクエリで中央データベースをポーリングします。

このアーキテクチャのより優れた実装となるのが、非同期の更新ストリームを使用するアーキテクチャです。データベースには通常、行のすべての変更が格納されるトランザクションログがあるため、この変更のストリームが外部オブザーバシステムに公開されている場合、これらのシステムにこれらのストリームを添付して行の変更を処理およびフィルタリングできます。ここでは、中央データベースとして MySQL、メッセージバスとして Amazon Kinesis を使用して、このスキーマの基本的な実装をご紹介します。

通常、MYSQL バイナリログは、マスター上のすべての変更を読み取ってローカルに適用する読取りレプリカに公開されます。この記事では、変更をローカルデータベースに適用するのではなく、Amazon Kinesis ストリームに変更を公開する、一般化されたリードレプリカを作成します。

このメソッドの重要な点の 1 つは、コンシューマーが SQL クエリを受け取らないことです。SQL クエリは公開される可能性もありますが、一般的なオブザーバーは、SQL 互換のデータレプリカを維持しない限り、SQL にはあまり関心がありません。代わりに、変更されたエンティティ (行) を 1 つずつ受け取ります。このアプローチの利点は、コンシューマーが SQL を理解する必要はなく、事実の単一ソースは誰が変更を消費するのかを知る必要はないということにあります。これは、さまざまなチームが、必要なデータ形式で調整することなく作業できることを意味します。さらに都合がいいことに、Amazon Kinesis クライアントはが特定の時点から読む機能を備えているため、各コンシューマーは独自のペースでメッセージを処理します。これが、メッセージバスがシステムを統合するための結合されていない方法の 1 つとなる理由です。

この記事で使用されている例では、行フェッチャーは中央データベースに接続する通常の Python プロセスであり、リードレプリカをシミュレートします。

データベースは、Amazon RDS または MySQL の任意のインストールのいずれかになります。RDS の場合、フェッチャープロセスは RDS インスタンスホストにカスタムソフトウェアをインストールすることができないため、別のホスト (たとえば EC2) にインストールする必要があります。外部インストールの場合、フェッチャープロセスはデータベースと同じホストにインストールできます。

マスター MySQL インスタンスの準備

MySQL マスター (真実の単一のソース) は、それが通常のレプリケーションのマスターであるかのように設定する必要があります。個々の変更された行を受け取るには、Binlog を有効にして ROW 形式で作業する必要があります。(そうしないと、SQL クエリだけになってしまいます。)詳細については、MySQL サイトの「バイナリログ」を参照してください。

バイナリログを有効にするには、my.cnf 設定ファイルに次の 2 行を追加します。

log_bin=<path to binlog>
binlog_format=ROW

すべての接続 (たとえば、init_connect または JDBC などのデータベース API を使用) のグローバルまたはセッションレベルで、トランザクション分離レベルをコミット済み読み取りに設定することによって、行ベースのロギングを取得できます。

RDS (MySql 5.6+) を使用している場合は、簡単です。定期的なバックアップを有効にして (バックアップが有効になっていなければバイナリログは無効になります)、パラメータグループ変数 binlog_format を ROW に更新することによって、必要な設定を作成できます。(これは、パラメータグループの RDS ダッシュボードから行うことができます。)

アクセス権限の追加

RDS で作成されたデフォルトのユーザーを使用している場合は、既にこれらのアクセス許可がある可能性があります。そうでない場合は、REPLICATION SLAVE 権限を持つユーザーを作成する必要があります。詳細については、「レプリケーション用のユーザーの作成」を参照してください。

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

Amazon Kinesis ストリームの作成

Amazon Kinesis ストリームと boto3 クライアントの認証情報が必要です。クライアントの認証情報の詳細については、「Boto 3 ドキュメント」を参照してください。

Amazon Kinesis コンソールを開き、[ストリームの作成] を選択します。

使用するストリームの名前とシャード数を入力します。この例では、1 つのシャードがあります。

数分後、ストリームで行の変更を受け入れる準備が整います。

CLI ユーザーに権限を割り当てる

AWS Identity and Access Management (IAM) を使用して、このストリームにアクセスする CLI ユーザに権限を与えることができます。

この例では、そのユーザーは KinesisRDSIntegration です。ユーザーを作成したり、既存のユーザーを使用することはできますが、Amazon Kinesis ストリームへの書き込み権限を追加する必要があります。

ストリームに固有のポリシーを作成できます。この例では、Amazon Kinesis に完全にアクセスできるスタンダードポリシーを使用しています。

マスターに接続して変更を公開する

Python パブリッシャーが必要とするライブラリをインストールするには、次のコマンドを実行します。

pip install mysql-replication boto3

詳細な手順については、次を参照してください。

https://github.com/noplay/python-mysql-replication

https://boto3.readthedocs.io/en/latest/guide/quickstart.html

ここに、マジックを実行する Python スクリプトがあります。<HOST>、<PORT>、<USER>、<PASSWORD>、および <STREAM_NAME> の各変数を設定値に置き換えることを忘れないでください。

Python

 

import json

import boto3



from pymysqlreplication import BinLogStreamReader

from pymysqlreplication.row_event import (

  DeleteRowsEvent,

  UpdateRowsEvent,

  WriteRowsEvent,

)



def main():

  kinesis = boto3.client("kinesis")



  stream = BinLogStreamReader(

    connection_settings= {

      "host": "<HOST>",

      "port": <PORT>,

      "user": "<USER>",

      "passwd": "<PASSWORD>"},

    server_id=100,

    blocking=True,

    resume_stream=True,

    only_events=[DeleteRowsEvent, WriteRowsEvent, UpdateRowsEvent])



  for binlogevent in stream:

    for row in binlogevent.rows:

      event = {"schema": binlogevent.schema,

      "table": binlogevent.table,

      "type": type(binlogevent).__name__,

      "row": row

      }



      kinesis.put_record(StreamName="<STREAM_NAME>", Data=json.dumps(event), PartitionKey="default")

      print json.dumps(event)



if __name__ == "__main__":

   main()

このスクリプトは、変更された各行を JSON 形式でシリアル化された Amazon Kinesis レコードとして公開します。

メッセージを使用する

これで、変更されたレコードを使用する準備が整いました。あらゆるコンシューマーコードが動作します。この記事のコードを使用すると、次の形式でメッセージが表示されます。

{"table": "Users", "row": {"values": {"Name": "Foo User", "idUsers": 123}}, "type": "WriteRowsEvent", "schema": "kinesistest"}
{"table": "Users", "row": {"values": {"Name": "Bar user", "idUsers": 124}}, "type": "WriteRowsEvent", "schema": "kinesistest"}
{"table": "Users", "row": {"before_values": {"Name": "Foo User", "idUsers": 123}, "after_values": {"Name": "Bar User", "idUsers": 123}}, "type": "UpdateRowsEvent", "schema": "kinesistest"}

まとめ

このブログ記事では、擬似リードレプリカと Amazon Kinesis を使用して、変更ストリームをデータベースのレコードに公開する方法を説明しました。多くのデータ指向の企業が、これに類似したアーキテクチャを使用しています。この記事で提供されている例は、実際の本番環境には対応していませんが、この統合スタイルを試して、エンタープライズアーキテクチャの拡張機能を改善するために使用できます。最も複雑な部分は、おそらく Amazon Kinesis の背後で既に解決されているものでしょう。接着剤の役割を果たすものを提供する必要があります。

その他のリソース

すべてのソフトウェアエンジニアがリアルタイムデータの統合抽象化について知っておくべきこと

Databus に搭載されているすべてのもの: LinkedIn のスケーラブルで一貫性のある変更データキャプチャプラットフォーム

 

大規模なデータベースをオープンソースデータベースへ移行する際のカテゴリ分けと優先度づけ

AWS Schema Conversion Tool (AWS SCT)AWS Database Migration Service (AWS DMS) はコマーシャルデータベースからAmazon RDSの様々なデータベースエンジンへの移行を簡単に行えるようにするツールです。 AWS SCTはプロプライエタリなデータベースをオープンソースデータベースへ移行する際に手助けを行います。移行元のデータベーススキーマや多くのカスタムコードを移行先のデータベースに適した形へ変換を行います。ツールが変換を行うカスタムコードには、ビュー、ストアード・プロシージャー、ストアード・ファンクションを含みます。一方、自動的に変換が出来ないものとしては、手動で変換が行いやすいように該当箇所を抽出します。AWS DMSはダウンタイムを最小限に抑えながら、簡単・安全にデータを移行することを可能にします。

データベースエンジンを変更することは大変な作業ですが、Amazon Auroraのようなスケーラブルでコスト効率がいいフルマネージドサービスの恩恵を受けやすくなる利点があり、移行を行う価値があります。AWS SCTとAWS DMSを用いることで、単一のデータベースからオープンソースへの移行を評価し、計画を行うことが容易になります。 AWT SCTアセスメントレポートを生成し、これらのツールを使用することで、データベースを移行することが、どのくらい簡単であるかということがおわかりになると思います。

以下のブログやビデオは、オープンソースデータベースへ移行するための情報の一例です。

もし、数百・数千のデータベースを持っていた場合は
評価レポートを作成し、1つ、2つ、またはさらに10のデータベースをオープンソースデータベースへ移行することは、簡単なプロセスです。 おそらく、どのアプリケーションが利用しているデータベースを最初に移動するか判断するための材料は十分お持ちだと思います。 組織内外で利用されている数百または数千のデータベースインスタンスがあり、十分なアプリケーションの知識がない場合はどうなるでしょうか?

集中管理されたIT部門では、管理するデータベースの数、バックアップのスケジュール設定などを一元管理することが出来ます。 しかし、大規模な動向を計画したり、分析のために優先順位を付けるための十分な詳細がないかもしれません。 この記事では、データベースポートフォリオを評価し、管理可能な移行のパイプラインに分解してプロセスを円滑に進めるための方法について説明します。

小さいプロジェクトのコラボレーション

1つの異種データベース移行の詳細なプロジェクト計画は、次の表に示すように12の手順で構成されます。

フェーズ 説明 フェーズ 説明
1 評価 7 システム全体で機能テスト
2 データベーススキーマ変換 8 パフォーマンステスト
3 アプリケーション変換/修正 9 結合とデプロイ
4 スクリプト変換 10 トレーニング
5 サードパーティアプリケーションとのインテグレーション 11 ドキュメントと変更管理
6 データ移行 12 リリース後のサポート

このブログの目的上、移行プロジェクトを計画するプロセスは、分析と計画、スキーマ移行、データ移行、アプリケーション移行、およびカットオーバーの5つの作業領域に分類できます。 移行の所要時間は、通常、移行およびテストのフェーズでどのくらいの時間を費やすかによって異なります。 いくつかの移行を並行して計画している場合は、どちらの移行が最も時間がかかるのか、最初に取り組むことができるのか、迅速に取り組むことができるのかを理解する必要があります。

CTWorkflow

オープンソースデータベースに移行する際に最初に分析するデータベースの優先順位付けは、データベース内で独自のコードがどれくらい使用されているかに左右されます。 使用しているプロプライエタリコードの量は、プロジェクトの移行段階でそれを変換してテストするのにかかる時間に影響します。 カテゴリーと基準を設定した後に、ディクショナリクエリを使用してデータベースをワークロード別に分類できます。

ワークロードを分類するためのフレームワーク

ワークロードは、通常、さらに分析するために5つのカテゴリに分類されます。 このブログでは、カテゴリ1〜3に焦点を当てます。

カテゴリ 1: (ODBC/JDBC)

ODBC(Open Database Connectivity)/ JDBC(Java Database Connectivity)を使用するアプリケーションは、 プロシージャ、ファンクション、トリガー、またはビューで独自のデータベースコードの利用量はとても少ないです。 アプリケーションロジックは、データベース外のコード(例えば、Java、Python、Ruby)にあるため簡単に別のデータベースに移行できます。

カテゴリ2: (独自データベースコードが少ないワークロード)

これらのワークロードでは、アプリケーションレベルのコード(Java、Python、Ruby、bashなど)と独自のデータベースコードを組み合わせて、JavaやPythonで扱いにくい機能を実行します。 経験則として、200未満のプロシージャ/ファンクションがこのカテゴリに分類されます。 高度な機能を使用する場合の許容範囲はさまざまです。 高度な機能を使用すると、ターゲットエンジンへのコードの自動変換が遅くなる可能性があります。 これらのワークロードでは、通常スキーマ設計はかなり簡単です。 テーブルやビューのような基本的なデータ構造を使用します。

カテゴリ3: (独自データベースコードが多いワークロード)

これらのワークロードは、独自のデータベースコードによって完全に実行され、多くの場合、高度な機能が使用されます。 これらのワークロードの多くは、1,000以上の独自の機能を備えています。 また、機能列、マテリアライズド・ビュー、リンクされたサーバーなどの高度なスキーマ機能も使用します。これらのワークロードの課題は、他のフレームワークに変換する際にに多くの作業時間を必要とすることです。 ソースコードで実行されるチューニングオプションは、変換しターゲットエンジンでテストを行う必要があるためです。

カテゴリ4: (ベンダ依存のワークロード)

これらのワークロードは、限定された商用エンジンのサポートのみで動作するフレームワークを使用します。 これらのワークロードをオープンソースに移行することは、アプリケーションを完全に再設計するか、現在サポートされていない高度な機能を必要とします。 機能は移行が非常に難しく、非常に多くの作業時間を消費します。

カテゴリ5: (レガシーワークロード)

これらのワークロードは独自のプログラミングインターフェイスを使用してプログラムを実行します。 例として、Oracle OCIアプリケーションなどが含まれます。 これらは従来のワークロードであることが多く、顧客はこれらのプログラムのソースコードを持っていない可能性があります。 めったに移行されることはありません。

ワークロードの優先度付け

データベースのインベントリを中央のリポジトリに保存しておくと、SQLやスクリプティング言語のような手持ちのツールを使用してポートフォリオ評価を自動化できます。

Oracle

Oracleデータベースの利用が多い場合は、PL / SQLブロックを使用してデータベース内のスキーマをループし、SELECT ANY DICTIONARYが付与されたユーザーに提供される情報を抽出できます。 SQL * Plusを使用し、不要なシステム・スキーマを除外し、コンマで区切られた値のセットをローカル・ファイルmigration_candidates.csvに追加します。 複数のデータベースに適用するには、bashスクリプトまたはプログラムを使用してインベントリシステムまたはファイルから読み込み、スクリプトを繰り返し実行し、同一ファイルに書き込みます。 こちらリポジトリーからOracle用のサンプル・スクリプトをダウンロードできます。

SQL Server
SQL Serverデータベースの利用が多い場合は、SQLブロックを使用してデータベースから読み取り、MSDBおよびsysスキーマから選択する権限を持つユーザーに提供される情報を抽出できます。 SQL Serverデータベースに対してsqlcmdを使用してスクリプトを実行し、コンマ区切りの結果を取得して、ファイルシステムのローカルファイル(migration_candidates.csvなど)に書き込むことができます。 複数のデータベースに適用するには、PowerShellスクリプトまたはプログラムを使用してインベントリシステム、またはファイルから読み取り、同一ファイルに追加するスクリプトを繰り返し実行します。 こちらのリポジトリからSQL Serverのサンプルスクリプトをダウンロードできます。

スクリプトの出力のレビューとカテゴリー分け

すべてのデータベースから結果を取得したら、その結果をMicrosoft Excelまたは別のツールにロードして、データ内のパターンを探します。 次の例では、条件付きデータバーは、ワークロードを分類する際に検討する必要がある度合いを示します。 こちらのリポジトリからサンプルワークロードワークシートをダウンロードできます。

Reviewing-and-categorizing-script-output

カテゴリ 1

緑で強調表示されたいくつかのワークロードがカテゴリ1と見なされ、分析および移行のためにチームに割り当てる必要があります。 これらのワークロードには、移行が必要なコードオブジェクトがほとんどなく、独自の機能(リンクされたサーバー、ジョブ、索引ビューなど)をほとんど使用しないか、または使用しない単純なスキーマ(たとえば、表やビューの数が少ない)があります。

カテゴリ 2

前述のワークロード例では、黄色で強調表示されているカテゴリ2のワークロードがいくつかあることがわかります。これらのデータベースには、少なくともテストを行うために移行フェーズを延長する可能性のある、かなり多くのプロシージャーや多くの独自機能の利用があります。

カテゴリ 3

ワークロード例の1行目〜4行目には、カテゴリ3に分類されるオレンジ色のワークロードが表示されています。これらのデータベースは1,000以上のプロシージャーとファンクションがあり、複雑な構造とジョブやリンクサーバーなどの高度な機能を持っています。

チーム毎の課題

移行パイプラインの概要を確認したので、チームが作業にどのように取り組むか計画をすることができます。 次の例でチームAは、カテゴリ1の移行に重点を置いています。 彼らは迅速に幾つかの移行を完了、パイプラインを次々と移動させます。 チームBは、移行フェーズでは追加の時間を費やす必要があるカテゴリ2の移行を行い、チームCは、同じ時間枠でより複雑なカテゴリ3の移行の内1つを行うことになります。

各マイグレーションは、分析とスキーマ、データ、およびカットオーバーのためのアプリケーションの移行の計画までのすべての移行フェーズを実行します。 しかし、各チームは必要な作業量に基づいて異なるペースで動きます。

TeamComparison

まず、カテゴリ1の移行を対象にすることで、そこで学んだことを後のプロジェクトにすぐに反映させることができます。 大規模なプロジェクトを開始する場合は、拡大したプロジェクトに取り組む前に、チームに勢いを与えることになります。 すべてのプロジェクトを追跡し、作業のパイプラインを維持することで、チームの関与が維持され、全体の進捗状況に関連したステータスを把握することができます。 全体的な結果は、通常、プロジェクトの利害関係者にとって最大の関心事です。 こちらのリポジトリからサンプル計画シートをダウンロードできます。

まとめ

1つの作業としてオープンソースエンジンへの全体的な移行を見ると非常に難しい作業に感じるかもしれません。 作業を最初のハイレベルな評価段階で管理可能サイズに細分化し、最初に速移行可能な物をターゲットにし、全体的なステータスを報告することで、移行の作業パイプラインを管理しし、チームを時間通もしくは早期に作業を完了させることに集中させることができます。


About the Author

Wendy Neu has worked as a Data Architect with Amazon since January 2015. Prior to joining Amazon, she worked as a consultant in Cincinnati, OH helping customers integrate and manage their data from different unrelated data sources.

 

 

翻訳は星野が担当しました。原文はこちら

オートメーションを活用したCloudEndureによるAWSへの容易な移行

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。

オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。

オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。

ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式(リフト&シフト)に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。

ソリューションの概要

このブログ記事で説明するソリューションでは、CloudEndureAWS Database Migration Service(AWS DMS)を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス(Gogs)の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。

CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。

CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。

移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。

次の図は、この記事で取り上げる移行プロセスを示しています。

プロセスの仕組みは次のとおりです。

  1. Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。
  2. AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。
  3. CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。
  4. CloudEndureが初期同期を完了すると、Continuous Data Protection(CDP)エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 (この変数は、CloudEndureダッシュボードにインスタンス名として表示されます)。
  5. CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。
  6. CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。
    1. DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。
    2. Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。

      "Message": "{"instanceId": " i-0bb669daff4b1eea1","Pass": "True"}"

    3. CloudEndure Lambda関数は、CloudEndure Pass / Fail SNSトピックに登録されています。ラムダ関数は成功メッセージを探します。成功メッセージを受信すると、着信インスタンスIDに基づいてAmazon Machine Image(AMI)を作成し、AMI情報をAmazon SQSに送信します。 CloudWatchでLambda関数のステータスを追跡できます:
  7. CloudEndure.pyスクリプトは、移行されたインスタンスに関するメッセージをSQSキューに常にポーリングします。メッセージを受信すると、AMIが準備完了であるかどうかを確認します。準備ができたら、スクリプトはGogs CloudFormationテンプレートを起動し、AMI IDをパラメータとして渡します。 CloudFormationテンプレートは、次のような高可用性環境を展開します;

始めましょう

移行プロセスの仕組みが分かりましたので始めてみましょう。まず、CloudEndureでアカウントを設定する必要があります。アカウントをお持ちでない場合は、AWS SaaSサブスクリプションマーケットプレイスのCloudEndure Migration製品ページで登録できます。[1]

アカウントを設定し、CloudEndureのウェブサイトのスタートガイドに従ったら、以下のファイルに慣れておく必要があります。完全な解決策はGitHub上でより詳細に説明されています。

Ansibleプレイブック、変数、ファイル:

  • playbooks/files/CloudEndure.sh  – このファイルはCloudEndureが移行後のスクリプトを実行する/ boot/ce_conversionにデプロイされます。 GogがRDSを指すように再構成し、サービスをテストするために使用されます。
    • reinvent-ent312-source-instances.yml CloudFormationテンプレートは、このファイルのすべてのent312.five0.ninja
      を、Auto Scalingを使用して高可用性のGogs環境用のELBロードバランサを指し示すAmazon Route 53ドメインエイリアスに置き換えます。この値は、CloudFormationテンプレートのGogsDNSパラメータを介してテンプレートに渡されます。
  • playbooks/cloudendure_agent_install.yml
    • einvent-ent312-source-instances.yml CloudFormationテンプレートは、CloudEndure UserNameとパスワードをCloudEndureUserとCloudEndurePasswordのCloudFormationテンプレートのパラメータに基づいて、この「AnEure Playbook」の「Install CloudEndure」セクションに設定します。

CloudEndure.pyスクリプトで使用される移行スクリプトconfig.yml:

ファイルを編集して、次の情報を入力します。

  • username – CloudEndureのユーザー名
  • password – CloudEndureのパスワード
  • hosttomigrate – CloudEndureダッシュボードで移行するホストの名前。 CloudEndureが最初のレプリケーションプロセスを開始するまで、この値はダッシュボードで使用できません。
  • stackname –CloudFormationスタックの名前。 CloudFormationスタックに名前を付けるときに、CloudEndureBlogDemoのデフォルト値を変更することを選択した場合にのみ、これを変更してください。
  • keypairname – Gogs自動スケーリングスタックを起動するためのキーペア
  • gogsdns – Gogs自動スケーリング用にELBロードバランサにマップするRoute 53ドメインエイリアス

CloudFormation テンプレート:

  • reinvent-ent312-migrated-gogs.template
    • この値は、Gogs自動スケーリングのELBロードバランサにマップするRoute 53ドメインエイリアスです。パラメータGogsDNSNameは、CloudEndure.pyスクリプトの実行時にconfig.ymlのgogsdns値に基づいて渡されます。

AWS CloudFormationを使用してソリューションをデプロイする

次に、移行を詳しく見て、各ステップを実行してみましょう。このデモンストレーションでは、CloudFormationテンプレートは、AWSアカウントの別個の仮想プライベートクラウド(VPC)でソース環境を紡ぎ出し、同じアカウント内の宛先VPCに移行します。

まず、AWS CloudFormationテンプレートをAWSアカウントに展開する必要があります。
テンプレートをダウンロードして、独自の実装の出発点として使用することもできます。

テンプレートの選択」ページで、テンプレートURLのデフォルト設定を維持し、「次へ」を選択します。

デフォルトのスタック名のままにするか、スタックの名前を入力し、下のスクリーンショットごとに値を入力します。

Gogsを構成する際に必要なため、ソースデータベースのユーザー名とパスワードに設定した値に注意してください。次の2つの画面で「次へ」および「次へ」を選択し、「AWS CloudFormationがカスタム名でIAMリソースを作成する可能性があることを確認します」というチェックボックスをオンにして、「作成」を選択します。

CloudFormationがアカウント内のリソースを作成するまでには数分かかります。 {YourStackName} -SourceInstanceResourcesがCREATE_COMPLETEとマークされたスタックが表示されたら、ログインしてGogsを設定できます。

CloudFormationで作成したカスタムDMSタスクは、Gogs DBが存在するかどうかによって異なりますので、CloudFormationスタックが完了する前にGogsをインストールして設定する必要があります。 (この執筆時点では、CloudFormationはDMSリソースをサポートしていませんが、移行の特定の側面について自動化を構築するための具体的な方法の1つを示したいと思います。)

スタックの[出力]タブで、AnatileSourceInstanceを見つけます。 SSHを次のコマンドで値を使用してインスタンスに追加します。

ssh -i {KeyPairYouAssociatedWithTheStack}centos@{ValueFromAnsibleSourceInstance}

インスタンスにSSHしたら、次のコマンドを実行して、更新とCloudFormationのユーザーデータステップが完了していることを確認します。

sudo tail -f /var/log/cloud-init.log

クラウド・イニシエータがインスタンスのブートストラップを終了すると、以下のようなメッセージが表示されます。

Mar 7 18:30:29 ip-10-10-138-101 cloud-init: Cloud-init v. 0.7.5 finished at Tue, 07 Mar 2017 18:30:29 +0000. Datasource DataSourceEc2. Up 369.01 seconds

これでインスタンスへのキーペアを追加する必要があります。そのため、SSHを使用してソースインスタンスに使用したり、Gogを構成したりすることができます。ローカルマシン上で、鍵ペアを保存したディレクトリから、次のコマンドを使用して秘密鍵をクリップボードにコピーします。

cat {KeyPairYouAssociatedWithTheStack}.pem | pbcopy

Ansibleソースインスタンスで、次のコマンドを実行します。

vi key.pem

プライベートキーをviウィンドウに貼り付け、ファイルを保存します。次に、次のコマンドを実行してアクセス許可を変更します。

chmod 400 key.pem

次のコマンドを実行して、ssh-agentが有効になっていることを確認します。エージェントpidを受け取る必要があります(たとえば、Agent pid 417)。

eval `ssh-agent`

ssh-agentにSSH鍵を追加し、空のパスフレーズを入力するためにEnterキーを押します。

ssh-add key.pem 
今度は、あなたのソースGogs DBをAnsible経由でプロビジョニングできます:

ansible-playbook -i playbooks/hosts playbooks/database_provision.yml

ソースのGogsインスタンスをプロビジョニングします。

ansible-playbook -i playbooks/hosts playbooks/gogs_provision.yml

GogsがAnsible経由で設定されると、ログイン環境でGogsをログインして設定することができます。 CloudFormationのSourceInstanceResourcesスタックのOutputsタブにGogsSourceInstanceの値が必要です。

http://{ValueFromGogsSourceInstance}:3000

「Gogsのユーザーパスワード」フィールドに、CloudFormationのソースデータベースのユーザー名とパスワードから前述した値を入力します。

Gogsであなたの選択したユーザーとパスワードを登録することができます。このデモンストレーションの後半に注意してください。

CloudFormationのDMSスタックが完了したら、セットアップを調べることができます。レプリケーションインスタンスが表示されます。

送信元と宛先の両方のエンドポイントも表示されます。

データベース同期を実行するタスクも表示されます。

DMSの検証が終了したら、AnatileSourceInstance SSHウィンドウに戻り、次のコマンドを実行してApplication Discovery ServiceとCloudEndureをインストールします。

ansible-playbook -i playbooks/hosts playbooks/aws_cli_ads_agent_install.yml

ansible-playbook -i playbooks/hosts playbooks/cloudendure_agent_install.yml

CloudEndureダッシュボードにログインすると、サーバーが表示されます。 CloudEndureはAWSへの最初のブロックレベル同期を完了する過程にあるため、テストの準備が整っている、と表示されるまでに時間がかかることがあります。

CloudEndure DashboardのINSTANCE NAMEの値は、config.ymlファイルのhosttomigrate変数に設定する必要がある値です。
CloudEndure.pyスクリプトを実行して、移行を初期化します。

python scripts/CloudEndure.py

スクリプトの出力例を見るには、READMEを見てください。

スクリプトが終了すると、Lambda関数から作成されたAMIを使用して、AutoScalingと共に高可用性Gogs環境が表示されます。

高可用性のGogs環境がヘルスチェックに合格し、ELBロードバランサの背後でサービスを受けるには数分かかりますが、最終的には、ソース環境で作成したユーザー名を使ってサインインし、RDSを使用するように設定された移行済みGogs環境にアクセス可能です。これは、DMSタスクが移行元GogsデータベースをRDSに移行するのに成功したことを証明します。

サマリー

この記事では、オンプレミス環境からAWSへの移行をスピードアップするために、自動化とテストをツールキットに組み込む方法を示しました。慎重な計画と構成では、移行シナリオ全体で再利用できる一連のツールが用意されています。これにより、ワークロードをより迅速に移行できるようになり、移行後に期待どおりアプリケーションが動作しているという確信が得られます。

 

このブログの内容は、第三者の製品を推奨するものではありません。このブログは情報提供を目的としています。

[1]このブログ記事の手順に従う際に発生した費用については、あなたが責任を負います。

(翻訳は諸岡が担当しました。原文はこちら)

 

オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

  • AWS SCT をダウンロード
  • AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
  • 米国西部(オレゴン)リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部(オレゴン)リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

Launch Stack

スタックを起動して名前を付けるには、次のようにします。

  1. AWSアカウントにまだログインしていない場合はログイン。
  2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
  3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
    Specify Details
  4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
    I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
    Eventsタブ
  6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
    Outputsタブ

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

  1. AWS Schema Conversion Tool を開始。
  2. Fileから New Project を選択。New Project ダイアログが表示される。
    New Project dialog
    次のプロジェクト情報を追加。

    Project Name プロジェクト名を入力。コンピュータにローカル保存される
    Location ローカルプロジェクトファイルの保存先を入力
    Data Warehouse (OLAP)
    Source DB Engine Oracle DW
    Target DB Engine Amazon Redshift
  3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
  4. Oracle Database に接続するため、Connect to Oracle DW を選択。

    Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。

    以下の値をフォームに入力。

    Server name <移行元EC2エンドポイントのDNS名>
    Server port 1521
    Oracle SID XE
    User name dms_sample
    Password dms_sample
    Use SSL チェックしない
  5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
  6. 移行元データベースに接続するため、OKを選択。
  7. DMS_SAMPLEデータベースを選び、Nextを選択。
  8. Database Migration Assessment Report を読み、Nextを選択。

  9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。

    Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。

    以下の値をフォームに入力。

    Server name 移行先RedshiftエンドポイントのDNS名
    Server port 5439
    Database dev
    User name admin
    Password CloudFormationで選ばれたパスワード
    Use SSL チェックしない
  10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
  11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

  1. Viewを選び、Main View を選択。
  2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Convert schema を選択。
  3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
  4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

  1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
  2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
  3. 「レプリケーションインスタンスの作成」ページが表示される。

    このページで以下の値を入力し、「次へ」を選択。

    名前 8から16文字のASCII文字によるレプリケーションインスタンスの名前(/、”、@を除く)
    説明 レプリケーションインスタンスの説明を入力
    インスタンスクラス dms.t2.medium
    VPC 使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
    Multi-AZ いいえ
    パブリックアクセス可能 チェック
  4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

  1. ソースエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン oracle
    サーバー名 <移行元EC2エンドポイントのDNS名>
    ポート 1521
    SSLモード none
    ユーザー名 dms_sample
    パスワード dms_sample
  2. ターゲットエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン redshift
    サーバー名 <RedshiftエンドポイントのDNS名>
    ポート 5439
    SSLモード none
    ユーザー名 admin
    パスワード CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

タスク名 タスク名を入力
ソースエンドポイント 使用する移行元エンドポイントを選択
ターゲットエンドポイント 使用する移行先エンドポイントを選択
レプリケーションインスタンス 使用するレプリケーションインスタンスを選択
移行タイプ Migrate existing data
作成時にタスクを開始 チェックする

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

Oracle Database を Amazon Aurora に移行する方法

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。

データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。

AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。

すばらしい! では、どこから始まれば良いのでしょう?

AWS SCT での移行手順

通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool とは からご覧ください。

この投稿ではSCTのイストールや構成については触れませんが、注意点は移行元と移行先のデータベースにSCTを接続するために、OracleとMySQLのドライバーをインストールする必要があることです。移行元のOracleに接続した後、スキーマのいずれかを右クリックしてアセスメントレポートを作成できます。アセスメントレポートはこのスキーマがどれくらいOracleからAuroraに自動変換されるのかと、自動変換後に残された作業量がどれくらいなのかの概要を教えてくれます。以下がレポートの例です。

Database Objects with Conversion Actions for Amazon Aurora

アセスメントレポートに加えて、SCTは各オブジェクトがどれくらい正確に変換されるかも教えてくれます。もしあるオブジェクトが変換できない場合、SCTはその理由と、状況を改善するためのヒントを教えてくれます。

Database Objects with Conversion Actions for Amazon Aurora

スキーマの100%がOracleからAuroraに変換されない場合、いくつかの方法で状況を改善できます。

  • 移行元のOracleのデータベース上のオブジェクトを変更して、SCTでAuroraに変換できるようにする
  • スキーマをひとまず変換し、SCTによって生成されたスクリプトを変更してからAuroraデータベースに適用する
  • 変換できないオブジェクトを無視し、移行先でそれらを置き換えるか無視する。たとえば、Oracleのsys.dbms_randomパッケージを呼び出すファンクションがあるとします。このパッケージはAuroraには存在しません。この問題を解決するには以下のことができます。
    • ランダム値の生成をアプリケーションコードに移し、それをパラメーターとしてファンクションに渡します。この変更は、変換前の移行元データベースまたは変換後の移行先データベースで行うことができます。
    • SCTで生成されたコードを、MySQLに存在するRAND()ファンクションを使うように変更し、新しいコードをAuroraデータベースに適用します。

その他の例として、一意の識別子を生成するためにOracleのシーケンスを使っているとします。Auroraはシーケンスをサポートしていないので、修正するために以下を実行してください。

  • 自動的に一意の識別子を生成するAuroraのauto-increment機能を使う。この方法で行く場合は、Auroraデータベースにスキーマを作成した後で、移行先のテーブルを変更するためのスクリプトを作成することをお勧めします。
  • 一意の識別を生成する何か別の方法(ファンクションや類似のもの)を作成し、シーケンスを参照している部分を新しいファンクションで置き換える。これは変換前に移行元のOracle上で実施することも、移行先のAuroraで実施することもできます。
  • 両方の手法を使う必要があるかもしれません。

一般的に、移行の一環としてSCTを使うための良い取り組み方には以下を含みます。

  • SCTアセスメントレポートを作成し、移行のギャップを埋める計画を立てる。もし移行候補となる複数のシステムがある場合は、どのシステムから最初に取り組むべきかの決定に役立ちます。
  • Action Items を確認し、変換に失敗した各項目の適切な処理を決定する。
  • 新しいAuroraデータベースに対してアプリケーションをテストしながら、AWS Database Migration Service と連携して新しいスキーマにデータをロードし、この処理を繰り返す

AWS DMS での移行手順

AWS DMS は移行元のOracleデータベースから移行先の新しいAuroraデータベースにデータをロードするときに使えます。DMSの素晴らしい点は、データを丸ごとロードすることに加えて、実行中のトランザクションをキャプチャして適用することです。カットオーバーの準備が整うまで、Oracleの移行元データベースとAuroraの移行先データベースを同期させつづけます。このアプローチによって、移行を完了させるために必要な停止時間を大幅に短縮することができます。DMSマイグレーションには、移行元エンドポイントであるOracle、移行先エンドポイントであるAurora、レプリケーションサーバー、タスクを含みます。

OracleからAuroraに移行するとき、既存データを移行し、進行中の更新をレプリケーションするタスクを構成したいでしょう。これにより、データ全体の移行中に実行されたトランザクションをキャプチャするようにDMSに指示します。データ全体がロードされると、DMSはキャプチャされたトランザクションの適用を開始し、OracleとAuroraのデーベースの同期を開始します。Auroraをカットオーバーする準備ができたら、アプリケーションを停止し、残ったトランザクションをDMSに適用させ、新しいAuroraデータベースに接続するアプリケーションを開始するだけです。

DMSを使用してOracleからAuroraに移行する場合、考慮すべき点がいくつかあります。

サプリメンタルロギング。 DMSが移行元のOracleから更新をキャプチャするにはサプリメンタルロギングを有効にする必要があります。詳細な手順については、DMSのマニュアルを参照してください。

DMSの3つのフェーズ。 データを移行し、進行中の更新をキャプチャするとき、DMSは3つのフェーズを経ています。

  • バルクロード: バルクロードフェーズで、DMSはn個のテーブルを一度にまとめてロードします。デフォルトでは n = 8 です。この値はDMSマネジメントコンソールまたは AWS CLI を利用して変更できます。
  • キャッシュされたトランザクションの適用: バルクロードフェーズにDMSは移行元データベースへの更新をキャプチャします。あるテーブルのバルクロードが完了すると、DMSはバルクロードの一部であるかのようにキャッシュされた更新をできるだけ速くそのテーブルに適用します。
  • トランザクションとしての適用: すべてのテーブルのバルクロードが完了すると、DMSはキャプチャされた更新を単一のテーブルの更新ではなく、トランザクションとして適用し始めます。

セカンダリインデックス。 状況によっては、性能上の理由からDMSのバルクロードフェーズにセカンダリインデックスを削除したくなるかもしれません。バルクフェーズ中にセカンダリインデックスの一部またはすべてを削除することを選ぶ場合は、移行を一時停止して、トランザクションとしての適用フェーズでそれらを追加しなおす必要があります。すべてのテーブルのフルロードが完了した後であれば、移行を安全に一時停止することができます。

外部キー、トリガーなど。 バルクロードはテーブル単位で行われるため、バルクロードやキャッシュされたトランザクションの適用フェーズでは移行先のAurora内の外部キーに違反する可能性があります。initstmt=SET FOREIGN_KEY_CHECKS=0 をAuroraエンドポイントの追加接続属性として加えることで、外部キー検査を無効にすることができます。一般的に、データのバルクロードを中断したり悪影響を与える可能性のあるものにどう対処するかの戦略を策定する必要があります。たとえば、問題を回避するために、移行のカットオーバーフェーズになるまでトリガーの実装を延期することができます。

データ型。 新しいデータベースエンジンに移行するときには、どのようなデータ型がサポートされているかと、移行元のデータ型を移行先の新しいデータ型にどう変更するかを理解することが重要です。これについては、移行元のOracleのデータ型移行先のAuroraのデータ型をマニュアルで確認すべきです。

性能。 移行の全体的な性能は、移行元のOracle内のデータ量、種類、分散に依存しています。 AWS Database Migration Service Best Practices ホワイトペーパーに移行性能を最適化するためのいくつかの推奨事項が載っています。

手順をおさらいすると、

  1. SCTアセスメントレポートを使用して課題の概要を知ることができます。Auroraへの移行候補が複数ある場合は、どれから最初に取り組むべきかの決定に役立ちます。
  2. 処理の前後に必要となるかもしれない移行手順を洗い出すために、DMSを使用して移行先スキーマの作成とロードを実践します。
  3. 移行先のシステムでアプリケーションをテストして、新しい環境で期待通りに動作することを確認します。負荷やネットワーク環境を含む本番環境と同等の構成でテストしてみてください。
  4. スキーマの生成、データのロード、後処理の手順の適用、移行元と移行先システムの同期、カットオーバーに必要な手順などの実際の移行を実践します。
  5. SCTもDMSをシステム全体を一度に移行することを求めません。システムを短期間で効率的に移行するため、また必要であれば再構築するために、これらのツールを使用することができます。

実際の移行を開始する前に、SCTとDMSの両方のドキュメントを通して読むことをお勧めします。また、Step-by-Step ウォークスルーAWS Database Migration Service Best Practices ホワイトペーパー を読むこともお勧めします。

ツールの使い方を知るためにサンプルデータベースを使用したいのであれば、AWS GitHub リポジトリ で見つけることができます。

この投稿は特定の状況に必要な可能性のあるすべての手順や考慮事項を解説するものではありませんが、SCTとDMSを使用してプロプライエタリなOracleデータベースの足かせをどう緩められるかについての良いアイデアを提供しました。それでは幸せな移行を!


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は How to Migrate Your Oracle Database to Amazon Aurora です。

AWS Server Migration Service – クラウドへのサーバー移行が簡単に!

これはAhmed Omranのゲストポストです。 AhmedはAWSのMigration Solutions Architectです。

大規模構成におけるオンプレミスサーバーの移行は、自動化、スケジューリング、少ない帯域幅の消費や移行時間の短縮を調整することなしに行うことはできません。

この記事では、AWS Server Migration Service(AWS SMS)を使用して、オンプレミスのワークロードをAWSに効率的に移行する方法を段階的に説明します。

AWS Server Migration Serviceとは何ですか?

2016年10月、エンドツーエンドのサーバー移行プロセスを簡素化する目的でAWS SMS を紹介しました。 AWS SMS は現在、仮想アプライアンスを使用したエージェントレスサービスとしてのオンプレミス仮想マシン(VMs)の移行をサポートしています。 AWS SMSには、次の主要な利点があります:

  • ライブサーバーボリュームのAWSへのレプリケーションを順次自動化することにより、カットオーバー時のサーバーダウンタイムを削減します。
  • 費用対効果の高い方法で大規模サーバーの移行を行います。
  • 広く使用されている多くのオペレーティングシステムをサポートします。
  • 使いやすいUIを使用して、サーバー移行の進捗状況を管理および追跡します。

AWS SMSは、VMware 環境からAWSへの大規模マイグレーションを計画している場合に重要な考慮事項となる、ダウンタイム、エージェントレスツール、順次レプリケーション、およびカットオーバー前のアプリケーションテストなどに対する理想的なソリューションです。

AWS SMSは、サーバーの移行に使用する無料のサービスです。 Amazon EBS スナップショットAmazon S3など、移行プロセス中に使用されたストレージリソースにのみ支払います。

現在、米国東部(米国バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、EU(アイルランド)、アジア太平洋(シドニー)、アジア太平洋(東京)、アジア太平洋(ソウル) 、アジア太平洋地域(ムンバイ)でサービスが利用可能です。

どのように機能するのですか?

AWS SMS を使用してワークロードを移行する手順を説明する前に、移行プロセス自体とAWS SMS がどのように処理するかについて詳しく説明します。

移行プロセスは、次の図に示すように、4つの段階に分かれています。

AWS SMS 移行プロセスの概要

AWS SMS の最終出力はAmazon Machine Image(AMI)です。移行プロセスは、ジョブが終了されるまで(あなたが消去するか、または90日後に自動的に終了するまで)、各レプリケーションの実行ごとにAMIを生成します。

移行段階は、調整された複製頻度で反復されます。各レプリケーションの実行間隔の最短時間は12時間で、最大時間は24時間です。この反復サイクルの有効期間は90日です。その後、レプリケーションジョブは終了します。

移行するVMのグループを選択できます。 SMS は、アカウントごとに最大50の同時VM移行をサポートします。

AWS SMS はどのように使用しますか?

AWS SMSには、移行プロセスのワークフローを調整するコネクターが必要です。このコネクターは、vCenter にデプロイされます。

SMS コネクタを展開する前に、環境がAWSのSMS要件を満たし、正しいファイアウォール設定をしていることを確認してください。 DHCP、DNS、HTTPS、ICMP、およびNTPサービスのステートフルな送信接続を許可するようにファイアウォールを再設定できないと、展開に失敗する可能性があります。

また、AWS SMS のドキュメントに記載されているように、AWS SMS 用の適切なポリシーと権限を持つvCenterサービスアカウントとIAMユーザーを作成する必要があります。

Server Migration Connector仮想アプライアンスを展開する

Server Migration Connectorは、VMware 環境へデプロイするためにOVA形式で提供されている、事前設定されたFreeBSD仮想マシンです。 AWS からConnector の最新バージョンをダウンロードできます。

Server Migration Connector をダウンロードしたら、デプロイのための十分な権限を持つvCenterにログインします。

インベントリからvCenterのコンテキスト(右クリック)メニューを開き、OVF テンプレートの展開を選択します。

 

ソースの選択ページで、ソースOVFテンプレートが存在する場所を指定し、次へを選択します。

確認の詳細 ページで、OVF テンプレートに関する情報を確認し、 次へを選択します。

アプライアンスは、シンプロビジョニングの場合は5.9 GB、シックプロビジョニングの場合は299.0 GBのサイズ容量でデプロイされます。実稼働環境では、シックプロビジョニングを推奨します。

名前とフォルダの選択ページで、アプライアンス名と配置場所を指定します。

リソースの選択ページで、OVF テンプレートを展開したいクラスタ、ホスト、vAPP、またはリソースプールを選択します。

ストレージの選択ページで、仮想ディスク形式からThick Provisioned Lazy Zeroedを選択し、OVF テンプレートをデプロイする必要があるデータストアを選択します。

セットアップネットワークページでネットワークマッピングを設定するために、 宛先 ドロップダウンメニューからネットワークを選択し、 次へ をクリックします。

準備完了ページで、すべての構成設定を確認し、展開後に電源をオンにして、完了を選択します。

コネクターを構成する前に、Server Migration ConnectorがvCenterとESXiホストのFQDNを解決できることを確認してください。

ネットワーク設定の再設定が必要な場合、コネクタアプライアンスコンソールにログインし、Advanced Network Configurationガイドに従います。

コネクターの構成

WebブラウザーでIPアドレスを指定し、Connector VM にアクセスし、セットアップ・ウィザードを開きます。

今すぐ開始を選択します。

 

使用許諾契約書を確認し、条件に同意する場合はチェックボックスを選択し、次へを選択します。

コネクターのパスワードを作成します。

ネットワーク情報 ページで、ネットワーク情報を確認し、 次へ を選択します。

ログを自動的にアップロードし、AWS Server Migration Serviceの自動アップグレードに参加するかどうかを確認して決定します。

AWS Regionについては、リストから希望のリージョンを選択します。

AWS 資格情報には、前提条件のステップで作成したIAMユーザーのIAMアクセスキー秘密鍵キー入力します。

vCenter Service Accountには、vCenter のホスト名、ユーザー名、およびパスワードを入力します。

vCenter 証明書を受け入れたら、登録を完了し、コネクター構成ダッシュボードを表示します。

コネクター ページで、登録したコネクターが表示されていることを確認します。

コネクターページは4つのセクションに分かれています:

  • AWS Server Migration Service セクションには、AWSアクセスキー、シークレットアクセスキー、およびvCenterログインなど、編集可能な設定が用意されています。
  • General Healthセクションには、ヘルスチェックと接続ステータスが表示されます。
  • アクション セクションでは、SMS 管理者パスワードを変更し、コネクターの登録を解除できます。常に最新のアップデートを適用する場合は、自動アップグレードアクションを有効にします。
  • サポートセクションでは、ログをダウンロードしたり、問題を報告したり、ドキュメントを確認したりすることができます。

これで、サーバーインベントリをインポートして、移行イベントを編成して自動化する準備が整いました。

サーバーカタログをインポートする

コネクターがインストールされ、正しく登録されたら、AWS SMS コンソールにアクセスし、コネクター、サーバーカタログのインポートを選択して、サーバーの完全なリストを収集します。サーバーカタログが完全に取り込まれ、表に表示されるまでには時間がかかることがあります。

注:サーバーカタログはいつでも再インポートまたはクリアできます。

移行ジョブを作成する

移行ジョブを開始する前に、データストアに一時スナップショットのための十分な領域があることを確認し、選択したVMにISOが接続されていないことを確認します。

AWS SMS コンソールで、 レプリケーションジョブレプリケーションジョブの作成を選択し、ウィザードに従います。

テーブルから複製するサーバーを選択し、次へを選択します。

レプリケーションジョブから作成されるAMIのライセンスタイプを選択します。 LinuxサーバーはBring Your Own License(BYOL)のみを使用でき、WindowsサーバーはAWS提供のライセンスまたはBYOLを使用できます。完了したら、次へを選択します。

レプリケーションジョブ設定を構成し、次へをクリックします。レプリケーションの実行をすぐに開始させることも、後の日時から、現在の時刻から最大30日後に開始するようにスケジュールすることもできます。

Replicate server every ドロップダウンリストから目的のオプションを選択して複製頻度を選択できます。複製の最小頻度は12時間で、最大は24時間です。つまり、選択したサーバーのポイントインタイムレプリカを最小でも12時間ごとに作成できます。

設定を確認します。設定が正しい場合は、作成を選択します。表示されていない場合は、前へを選択して適切なページに戻り、設定を変更します。

AWS SMSコンソールの レプリケーションジョブ ページで、すべてのレプリケーションジョブを表示できます。 1つのレプリケーションジョブを選択すると、 ジョブの詳細パネルにレプリケーションジョブの詳細が表示されます。

前のスクリーンショットからわかるように、移行が開始され、VMDK がAmazon S3にアップロードされる第2段階にあります。

vCenter 画面から移行タスクのステータスを確認すると、開始されたスナップショットとOVFテンプレートが転送用にエクスポートされたことがわかります。

転送後、移行プロセスは第3段階になり、VMDK をAmazon Elastic Block Store(Amazon EBS)のスナップショットに変換します。

変換が完了すると、移行プロセスは最終ステージになり、この複製実行のポイントインタイムコピーのAMIを作成します。

AWS SMS コンソールのレプリケーションジョブ、実行履歴タブから、各レプリケーション実行で使用可能なすべてのAMIを表示できます。

実際のカットオーバーの前にテストする

オンプレミスアプリケーションを廃止する前に、アプリケーションをテストする機会があります。レプリケーション頻度に応じて、多数のポイントインタイムレプリカをテストしてから、差分の最後のレプリケーションジョブをスケジュールできます。

インスタンスを起動するには、前の手順で示したように実行履歴を開き、レプリケーションジョブを選択して、テストしたいインスタンスの起動を選択します。ウィザードに従って、インスタンスの種類の選択、インスタンスの構成、ストレージの追加、インスタンスのタグ付け、およびセキュリティグループの構成を行います。

実際のカットオーバー

テストを完了して実際のカットオーバーを実行することを決定したら、すべてのIOPを休止し、増分レプリケーションジョブを開始してから、AMIを起動します。 AWS SMS は増分レプリケーションを使用するため、以前のレプリケーション実行からの変更に応じて、カットオーバー時間は最小限になります。

レプリケーションジョブの削除

移行が正常に完了し、移行されたVMが正しく構成されて実行されたら、レプリケーションジョブを削除してオンプレミスデータセンターからAWSへのレプリケーションを停止できます。 AWS SMS コンソールの レプリケーションジョブページで、ジョブを選択し、アクションレプリケーションジョブの削除を選択します。

まとめ

この記事では、AWS Server Migration Serviceのメリットと機能について説明しました。また、SMS Connectorのインストールと構成の方法を説明し、稼働中のワークロードをオンプレミスデータセンターからAWSに移行するための移行プロセスの4つの段階について、ダウンタイムを最小限に抑える方法を説明しました。また、実際のカットオーバーの前に複数のポイントインタイムレプリカをテストする機能についても説明しました。

このブログ記事に関するコメントがある場合は、この記事のコメントセクションに投稿してください。あなたからの便りを楽しみにしています。

AWS Service Migration Serviceを開始する方法の詳細については、当社のWebサイトをご覧ください。

(翻訳は諸岡が担当しました。原文はこちら)

 

新発表 – AWS Server Migration Service

私は、我々の顧客の多くが直面している状況を強調するために、歴史的な写真を使用するのが好きです。お客様はデータ移行のために長期のメンテナンス期間を取ることができずに、ITインフラ基盤をAWSクラウドへ移行する必要があります。何故ならこれらのアプリケーションはミッションクリティカルであり、負荷の高いデータ処理指向であり、ギガバイト又はテラバイト級のデータを単に移動するためにシステム停止をすることは実用的ではないからです。airplane

新サービス

本日、私はAWS Server Migration Serviceについてお話したいと思います。

このサービスは、既存の仮想化されたアプリケーションをAmazon EC2に移行するプロセスを簡素化、合理化します。図に示された使用例のIT機器をサポートするために、長期のメンテナンス期間を必要とすることなく、ライブ仮想マシン(VMs)をクラウドへ順次レプリケーションすることができます。あなたは既存のサーバー群の順次移行を自動化、スケジュール設定、トラッキングができ、数十、数百に及ぶボリュームの大規模移行のプロセスや実行を簡略化することができます。

system

あなたは、AWS Management Console、AWSコマンドラインインターフェイス(CLI)、移行APIから、レプリケーションのプロセスを完全にコントロールすることができます。移行のためWindowsまたはLinuxサーバーを選択した後、あなたのアプリケーション利用パターンとネットワーク帯域を最小化するのに最もふさわしいレプリケーション頻度を選択することができます。舞台裏では、AWS Server Migration Serviceは、サーバー群をクラウドへレプリケートし、新たなAmazon Machine Image(AMI)を作成します。あなたは、コンソールから各レプリケーションジョブのステータスを追跡することができます。各増分同期は新規AMIを生成し、あなたの実際のカットオーバーに先立って移行されたサーバー群のテストが可能です。

Server Migration Serviceの使用の流れ

あなたは、実際の移行プロセスを開始する前に、AWS Server Migration Service Connectorをダウンロードし、設定しておく必要があります。Connectorは既存の仮想化環境内で稼働しますがマイグレーション自体はエージェントレス型で稼働するため、エージェントを各サーバーに導入する際のトラブルを低減します。あなたが大規模な組織、および/または複数の仮想環境を持っている場合は、コネクタの複数のコピーを展開することができます。コネクタは、既存の環境内からアクセスできるウェブUIを持っています。あなたが使用許諾契約をクリックした後、あなたは、パスワードを作成し、ローカルネットワークの設定を構成し、その他幾つかの設定を行います。 次に、SMS、S3、及びSNSのAPIにアクセスできるように、AWSアカウントまたはIAMユーザーCredentialを持ったConnectorを準備する必要があります。 もしあなたがIAMユーザーを使用する場合は、適切なIAMロールを作成する必要があります。(ユーザガイドにサンプルが含まれています)

Connectorが起動・稼働している間、AWS管理コンソールにログインし、Server Migration Serviceを操作し、そのサービスに登録されているすべてのConnectorの一覧が参照できます。各Connectorからサーバーカタログをインポートすることができ、サーバーのインベントリ情報を調べることができます。

1

それからレプリケーションする幾つかのサーバーを選択し、「Create replication jobs」をクリックします。次にサーバーのライセンスタイプ(オンデマンドまたはBYOL)を選択します。

2

それによって、あなたはすぐにレプリケーションを開始するか、将来の日時に開始するかを選択することができます。また、レプリケーション間隔を選択することもできます。

3

あなたが設定の確認、承認をした後、ダッシュボードでレプリケーションのジョブをすべて参照することができます。

4

独立したジョブを実行することも可能です。

5

それぞれの順次実行の後、作成されたAMIが表示されます。

6

「Launch instance」をクリックし、EC2インスタンスタイプを選択、そして移行サーバーの受け入れテストの実施となります。

 

今すぐ利用可能

AWS Server Migration Serviceは、米国東部(バージニア北部)、欧州(アイルランド)、およびアジアパシフィック(シドニー)の地域で利用可能になり、本日から利用可能です。サービスの利用は無料ですが、レプリケーション・プロセス中に使用したS3ストレージ、およびマイグレーションが完了した際に作成されるEBSからスナップショットの使用料がかかります。

-Jeff; (翻訳は諸岡が担当しました。原文はこちら)

 

AWS Application Discovery Service アップデート – VMware のエージェントレス検出

既存の環境を詳しく調べたり、状況の識別、そしてシステムやアプリケーションをクラウドに問題なく移行するために必要な情報と可視性を提供できるように設計された AWS Application Discovery Service については、今年すでにブログで紹介しました (詳しくは過去のブログ New – AWS Application Discovery Service – Plan Your Cloud Migration をご覧ください)。ブログで解説した検出プロセスでは、既存の各ホストで実行できる小規模で軽量なエージェントを使用しています。このエージェントはバックグランドで関連性のあるシステム情報を収集し、確認用にローカルで保管してからポート 443 の安全な接続状態で Application Discovery Service
にアップロードします。この情報は AWS Key Management Service (KMS) が保護する暗号化したリポジトリで処理、相関、保管されます。仮想化環境で各ゲストオペレーティングシステムにエージェントをインストールすることは、計画上またはその他の理由により実践的とは言い難い場合があります。このエージェントは、広範に渡る Windows バージョンや Linux ディストリビューションで実行することができますが、過去にリリースされた Windows を使用していたり、Linux の稀なディストリビューションが混ざっている可能性は無視できません。

新しいエージェントレス検出
AWS Application Discovery Service のメリットを多くの AWS のお客様に提供するため、新しいエージェントレス検出オプションを本日リリース致しました。VMware vCenter 環境で仮想マシン (VM) を実行している場合は、この新しいオプションを使用して各ゲストにエージェントをインストールする必要なく、関連性のあるシステム情報を収集できます。代わりにオンプレミスアプライアンスを VCenter で読み込み、その中でゲスト VM を検出できるようにします。どのオペレーティングシステムを使用していても、vCenter アプライアンスはシステムパフォーマンス情報や、各 VM のリソース使用率をキャプチャするようになっています。ただし、VM の内容詳細を見ることはできないので、インストールされているソフトウェアや、どのようなネットワーク依存関係があるのか確認することはできません。移行を計画する上で既存の VM を詳しく調べる必要がある場合は、必要に応じて Application Discovery エージェントをインストールしてください。エージェントレス検出はエージェントベースモデルと同様に情報を収集してローカルに保管するので、Application Discovery Service
に送信する前に確認することができます。情報をアップロードしたら AWS Command Line Interface (CLI) を使用して詳しく見ることができます。例えば、describe-configurations コマンドを使用して特定のゲストの設定情報を確認することができます。

検出したデータを CSV 形式ファイルでエクスポートし、移行計画を立てる上で利用することも可能です。本機能の詳細については export-configurations コマンドについてお読みください。

エージェントレス検出の開始方法
ご利用を開始されるには、まずこちらでサインアップしてください。その後、vCenter アプライアンスのインストール用リンクをお送りします。

Jeff

New – AWS Application Discovery Service – クラウド移行計画

1980年代半ばを振り返ると、私はウォールストリートに配置されたシステムを手掛けていました。多くのプロジェクトの制約により、マンハッタンにある高いデータセンターで、数えきれないほどの時間を費やして、デバッグのほとんどをオンサイトで行う必要がありました。データセンターは高層フロア全体を占めていました。

そこでの業務の終わりが近づいたころ、私は非公式のフロアツアーをしてみました。数十年に渡って調達され続けたハードウェアとソフトウェアのおかげで、シアトルにあるリビングコンピュータ博物館と同じくらい面白かったです。有名なブランドとモデルのハードウェアのほとんどがあり、不可解かつ複雑な配線で全体がつながっており、更新や変更作業には非常に不安がつきまとうような、関係者内でのみ理解できる情報とともに置かれていました。

今日では、多くのお客様が上述したようなレガシーな環境の大部分をAWSクラウドへ移行する計画があり、時間をかけて詳細を検討しています!

Application Discovery Service
AWS Application Discovery Service新しいAWS Application Discovery Service (シカゴで開催されたAWS Summitで最初の発表)は、現行環境を調査し、何が起こっているかを見極め、既存のアプリケーションのクラウド移行を成功させるために必要な情報を可視化します。

このサービスはAWS Cloud Adoption Frameworkの重要な部分です。このフレームワークはお客様のクラウドジャーニーを支援します。とりわけ、移行ステップの概要を記載します:

  1. 現在のIT資産を評価
  2. 調査と計画策定
  3. 構築
  4. 稼働

Application Discovery Serviceは、手作業でやる場合には時間がかかり退屈で複雑な処理を自動化するもので、ステップ2に焦点を当てています。

The Discovery Agent
始めるためには、移行元ホストに小型で軽量なエージェントをインストールするだけです。このエージェントは以下のシステム情報を収集します:

  • インストールされたアプリケーションとパッケージ
  • 実行中のアプリケーションとプロセス
  • TCP v4/v6 接続
  • カーネル種別とバージョン
  • カーネル構成
  • カーネルモジュール
  • CPUとメモリーの使用率
  • プロセスの生成と終了のイベント
  • ディスクとネットワークのイベント
  • TCP/UDPのリスニングポートと関連するプロセス
  • NIC情報
  • DNS、DHCPやActive Directoryの利用

このエージェントはオンライン、オフラインどちらでも実行できます。オフライン実行の場合、上述のリストにある情報を収集し、お客様が確認できるようローカルに保存します。 オンライン実行の場合、ポート443を使ったセキュアな接続でApplication Discovery Serviceに情報をアップロードします。この情報は、CLIコマンドとAPI関数の新しいセットによりアクセスできるリポジトリーに保存された後、関連付けられ、処理されます。

エージェントは、Ubuntu 14、Red Hat 6-7、CentOS 6-7、そしてWindows (Server 2008 R2、Server 2012、Server 2012 R2)上で実行可能です。今後オプションを追加する予定もあるので、お客様が必要とするものをぜひ教えてください。

Application Discovery Service CLI
Application Discovery Serviceには、エージェントによって収集された情報を照会するために利用できるCLIもあります。これはサンプルです:

describe-agents – 実行中のエージェントの一覧表示

start-data-collection – データ収集プロセスの開始

list-servers – 収集対象ホストの一覧表示

list-connections – 収集対象ホストで作成されたネットワーク接続の一覧表示。このコマンド(および記載していない他のいくつか)は、アプリケーションの依存関係を特定し、マップするのに役立ちます

Application Discovery Service APIs
いくつかの新しいAPI関数を使って、アップロードされた情報に注釈をつけたり、呼び出したりすることができます:

ListConfigurations – 検出対象ホストのサーバー、プロセス、接続の検索

DescribeConfigurations – 検出対象ホストの詳細情報の取得

CreateTags – 検出対象ホストに分類目的でのタグを追加

DeleteTags – 検出対象ホストからタグを削除

ExportConfigurationsApplication Discovery Service パートナーの分析および移行ツールを使ったオフライン処理と可視化のために、収集した情報をCSV形式でエクスポート

アプリケーションのインベントリーとネットワークの依存関係も、それぞれに適切な優先順位の決定や移行したいアプリケーションを決定するのに役立ちます。

今すぐ利用可能
AWS Application Discovery Serviceは、APNパートナーAWSプロフェッショナルサービスを通じて利用可能です。詳細は、Application Discovery Service User GuideApplication Discovery Service API Referenceを参照してください。

Jeff;

翻訳はPartner SA 河原が担当しました。原文はこちらです。