067-AWS SAP AWS 「理論・実践・一問道場」Aurora DB　アカウント間　移行

type

status

date

slug

summary

理論

デプロイメントパッケージとは

AWS Lambda 関数の実行に必要なコードや依存関係をまとめたアーカイブファイル（通常 .zip ファイル）のこと。

構成要素

コード: Lambda 関数で実行するスクリプト。

依存関係: 必要なライブラリやモジュール。

補助リソース（任意）: 設定ファイルや証明書。

作成手順

コードと依存関係を準備。

ディレクトリにまとめて圧縮（例: zip -r deployment-package.zip .）。

アップロード方法

AWS マネジメントコンソール

AWS CLI（例: aws lambda update-function-code）

AWS SDK

デプロイメントパッケージは、Lambda 環境でコードを動作させるための重要な基盤です。

AWS Lambda と Aurora の移行

1. AWS Lambda の移行

デプロイメントパッケージ:

Lambda関数は、コードとその依存関係をまとめた「デプロイメントパッケージ（.zip）」を使用して移行する。
ソースアカウントからデプロイメントパッケージをダウンロードし、ターゲットアカウントで新しいLambda関数を作成。

アクセス許可の移行:

移行元のアカウントからターゲットアカウントへLambda関数のアクセス許可や環境変数を再設定する必要がある。

2. Amazon Aurora の移行

スナップショットの利用:

Auroraデータベースの移行には、DBスナップショットを使用する方法が一般的。スナップショットを作成し、それをターゲットアカウントと共有。
自動バックアップ機能を利用して、最小限のダウンタイムで移行。

データベースのクローン:

Auroraクラスターは、クローン機能を使用して簡単に別のアカウントに複製可能。

3. AWS Resource Access Manager (AWS RAM)

リソースの共有:

AWS RAMを使用することで、複数のAWSアカウント間でリソース（Lambda関数やAuroraデータベース）を共有できる。
アカウント間でリソースのアクセス許可を設定し、ターゲットアカウントに移行後の管理権限を付与。

4. ダウンタイムの最小化

最小限のダウンタイム:

Auroraのスナップショットやクローン機能を使用して、データベースの移行中でもアプリケーションの可用性を維持。
Lambda関数の新規作成や設定変更により、移行中のサービス停止時間を最小化。

移行後のテスト:

新しいアカウントでLambda関数やAuroraデータベースを移行後、動作確認とテストを行い、アプリケーションの安定性を確認。

これらの手法を用いることで、AWS環境でのサービス移行を効率的かつ低ダウンタイムで実施することができます。

実践

AWSアカウント間でRDS Auroraを移行する方法　~ダウンタイム・データ欠損無し~ - ヘヴィメタル・エンジニアリング

AWSアカウントを超えたAuroraの移行について書きました。ポイントはダウンタイムなし、データ欠損なしです。ドキュメントにはない情報多数なので参考にしていただければと。

https://xkenshirou.hatenablog.com/entry/2020/07/12/110500

クロスリージョン・クロスアカウントで Aurora Serverless v2 の移行を検証してみた | DevelopersIO

EC/CRMプラットフォーム prismatix のSREチームではインフラやアプリケーションを安定稼働させるため、より良い新しいアーキテクチャの検討なども行っています。その取り組みの中で、4月に一般公開された Aurora Serverless v2 の検証を行ったのでご紹介します。

https://dev.classmethod.jp/articles/prismatix-aurora-serverless-v2/

AWS RAM および Amazon Aurora を使用したクロスアカウントのクローン作成 - Amazon Aurora

Amazon Web Services (AWS) Amazon Aurora (Aurora) ドキュメント。Aurora はフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。Aurora は、マネージド型データベースサービスである Amazon Relational Database Service (Amazon RDS) の一部です。Amazon RDS は、クラウドでリレーショナルデータベースを簡単に設定、運用、および拡張することができるウェブサービスです。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.Cross-Account.html

ベスト

[AWS] Resource Access Manager で Amazon Aurora（MySQL）のクロスアカウントクローンを作成する | DevelopersIO

Amazon Auroraには、起動しているDBクラスタのクローンを高速に作成する機能があります。この、高速クローンがクロスアカウントでも作成可能になっていましたので試してみました。

https://dev.classmethod.jp/articles/aws-resource-access-manager-aurora/

Amazon Auroraのクロスアカウントクローン作成を自動化する | DevelopersIO

Amazon Auroraでクロスアカウントクローン作成の自動化を検証する機会がありましたので手順をまとめておきます。ただし、自動化については現状標準機能では対応していないのでLambdaとEventBridgeを組み合わせてスケジュール実行させることで実現させています。下記がザックリやることイメージです。

https://dev.classmethod.jp/articles/aurora-cross-account-clone-auto/

一問道場

質問 #67

ある企業が「Source」という名前のAWSアカウントでアプリケーションを運用しています。このアカウントはAWS Organizations内の組織に属しています。以下の条件でアプリケーションが動作しています：

AWS Lambda関数を使用しており、在庫データをAmazon Auroraデータベースに保存しています。

アプリケーションはデプロイメントパッケージを使用してLambda関数をデプロイしています。

Auroraの自動バックアップが設定されています。

この企業は、Lambda関数とAuroraデータベースを「Target」という新しいAWSアカウントに移行したいと考えています。

アプリケーションは重要なデータを処理するため、ダウンタイムを最小限に抑える必要があります。

どのソリューションがこの要件を満たしますか？

A. SourceアカウントからLambda関数のデプロイメントパッケージをダウンロードします。このデプロイメントパッケージを使用して、Targetアカウントで新しいLambda関数を作成します。自動化されたAurora DBクラスターのスナップショットをTargetアカウントと共有します。

B. SourceアカウントからLambda関数のデプロイメントパッケージをダウンロードします。このデプロイメントパッケージを使用して、Targetアカウントで新しいLambda関数を作成します。AWS Resource Access Manager（AWS RAM）を使用してAurora DBクラスターをTargetアカウントと共有します。TargetアカウントにAurora DBクラスターをクローンする権限を付与します。

C. AWS Resource Access Manager（AWS RAM）を使用して、Lambda関数とAurora DBクラスターをTargetアカウントと共有します。TargetアカウントにAurora DBクラスターをクローンする権限を付与します。

D. AWS Resource Access Manager（AWS RAM）を使用して、Lambda関数をTargetアカウントと共有します。自動化されたAurora DBクラスターのスナップショットをTargetアカウントと共有します。

解説

正しい解答: B

理由:

この問題では、AWS Lambda関数とAuroraデータベースの移行を効率的かつ最小限のダウンタイムで行う方法を求められています。

Lambda関数の移行:

ソースアカウントからLambda関数のデプロイメントパッケージをダウンロードし、それをターゲットアカウントで利用して新しいLambda関数を作成する方法が正しいです。

Auroraデータベースの移行:

Aurora DBクラスターをそのままAWS Resource Access Manager（AWS RAM）を使って共有し、ターゲットアカウントにクローンの作成を許可する方法が最も効率的で正しいです。

Auroraのスナップショットを共有する方法もありますが、クローンを作成することにより、ターゲットアカウントで新しいインスタンスを作成する方が、移行中の可用性を維持しやすいため、ダウンタイムを最小化できます。

選択肢の詳細

Lambda関数の移行方法は適切ですが、Auroraの自動バックアップを共有するだけでは、スナップショットやクローンの作成手順が不足しています。バックアップを共有するだけでは移行の成功には不十分です。

正解です。Lambda関数の移行にデプロイメントパッケージを使用し、AuroraのDBクラスターをRAMで共有し、ターゲットアカウントでクローン作成を許可する方法が、効率的でダウンタイムを最小化できます。

Lambda関数の移行にAWS RAMを使う方法は適切ではなく、デプロイメントパッケージを使った方法が一般的です。

Auroraのスナップショットを共有する方法は正しいですが、Lambda関数の移行方法に関してはAWS RAMを使うのは不適切です。

結論:

B が最も効率的でダウンタイムを最小化できる方法であり、正しい解答です。