Category: AWS Database Migration Service*


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

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]このブログ記事の手順に従う際に発生した費用については、あなたが責任を負います。

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