翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # データベース **Topics** + [リンクサーバーを使用して Amazon EC2 上のMicrosoft SQL サーバーからオンプレミスの Microsoft SQL Server テーブルにアクセスする](access-on-premises-microsoft-sql-server-tables-from-microsoft-sql-server-on-amazon-ec2-using-linked-servers.md) + [リードレプリカを使用して Amazon RDS Customの Oracle PeopleSoft に HA を追加](add-ha-to-oracle-peoplesoft-on-amazon-rds-custom-by-using-a-read-replica.md) + [Oracle から PostgreSQL への部分的なデータベース移行に関するオブジェクトの依存関係を分析する](multilevel-object-analysis-for-database-migration-from-oracle-to-postgresql.md) + [SQL Server データベースを AWS 上の MongoDB Atlas に移行する際のクエリパフォーマンスを評価する](assess-query-performance-for-migrating-sql-server-databases-to-mongodb-atlas-on-aws.md) + [IaC 原則を使用して Amazon Aurora Global Database のブルー/グリーンデプロイを自動化する](p-automate-blue-green-deployments-aurora-global-databases-iac.md) + [間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md) + [AWS Lambda および Task Scheduler を使用して、Amazon EC2 で実行されている SQL Server Express エディションのデータベースタスクを自動化する](automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.md) + [DR Orchestrator Framework を使用してクロスリージョンのフェイルオーバーとフェイルバックを自動化](automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.md) + [Systems Manager と EventBridge を使用した SAP HANA データベースの自動バックアップ](automatically-back-up-sap-hana-databases-using-systems-manager-and-eventbridge.md) + [Python アプリケーションを使用して Amazon DynamoDB の PynamoDB モデルと CRUD 関数を自動的に生成する](automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.md) + [クラウドカストディアンを使用して Amazon RDS へのパブリックアクセスをブロック](block-public-access-to-amazon-rds-by-using-cloud-custodian.md) + [を使用して Amazon RDS for Microsoft SQL Server の Windows 認証を設定する AWS Managed Microsoft AD](configure-windows-authentication-for-amazon-rds-using-microsoft-ad.md) + [Amazon DynamoDB へのクロスアカウントアクセスを設定する](configure-cross-account-access-to-amazon-dynamodb.md) + [AWS 上の SQL Server の Always On アベイラビリティグループで読み取り専用ルーティングを構成する](configure-read-only-routing-in-an-always-on-availability-group-in-sql-server-on-aws.md) + [pgAdmin の SSH トンネルを使用して接続](connect-by-using-an-ssh-tunnel-in-pgadmin.md) + [JSON Oracleクエリを PostgreSQL データベース SQL に変換](convert-json-oracle-queries-into-postgresql-database-sql.md) + [を使用してアカウント間で Amazon DynamoDB テーブルをコピーする AWS Backup](copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.md) + [カスタム実装を使用してアカウント間で Amazon DynamoDB テーブルをコピー](copy-amazon-dynamodb-tables-across-accounts-using-a-custom-implementation.md) + [Amazon RDS と Amazon Aurora の詳細なコストと使用状況レポートを作成する](create-detailed-cost-and-usage-reports-for-amazon-rds-and-amazon-aurora.md) + [Terraform を使用して SQL Server フェイルオーバークラスターインスタンスを Amazon EC2 および Amazon FSx にデプロイする](deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.md) + [Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL で Oracle PL/SQL 連想配列をエミュレートする](emulate-oracle-plsql-associative-arrays-in-aurora-and-rds-postgresql.md) + [Amazon RDS の PostgreSQL DB インスタンスに対して暗号化された接続を有効にする](enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.md) + [既存の Amazon RDS for PostgreSQL DB インスタンスを暗号化する](encrypt-an-existing-amazon-rds-for-postgresql-db-instance.md) + [起動時に Amazon RDS データベースの自動タグ付けを強制する](enforce-automatic-tagging-of-amazon-rds-databases-at-launch.md) + [DynamoDB テーブルのコストをオンデマンドで見積る](estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.md) + [Amazon DynamoDB テーブルのストレージコストを推定](estimate-storage-costs-for-an-amazon-dynamodb-table.md) + [AWR レポートを使用して Oracle データベースの Amazon RDS エンジンサイズを推定](estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.md) + [AWS DMS を使用して Amazon RDS for SQL Server テーブルを S3 バケットにエクスポートする](export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.md) + [Aurora PostgreSQL の動的 SQL ステートメントの匿名ブロックを処理](handle-anonymous-blocks-in-dynamic-sql-statements-in-aurora-postgresql.md) + [DynamoDB でのタグ付けの強制を支援](help-enforce-dynamodb-tagging.md) + [AWS DMS と Amazon Aurora によるクロスリージョンディザスタリカバリの実装](implement-cross-region-disaster-recovery-with-aws-dms-and-amazon-aurora.md) + [100 個以上の引数を持つ Oracle 関数とプロシージャを PostgreSQL に移行](migrate-oracle-functions-and-procedures-that-have-more-than-100-arguments-to-postgresql.md) + [Redis ワークロードを AWS 上の Redis Enterprise Cloud に移行](migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.md) + [同じホスト名の SAP HSR を使用して SAP HANA を AWS に移行します](migrate-sap-hana-to-aws-using-sap-hsr-with-the-same-hostname.md) + [を使用して Microsoft SQL Server Always On 可用性グループを移行する AWS Application Migration Service](migrate-microsoft-sql-server-always-on-group-using-mgn.md) + [分散可用性グループを使用して SQL Server を AWS に移行する](migrate-sql-server-to-aws-using-distributed-availability-groups.md) + [でリレーショナルデータベースを MongoDB Atlas に移行する AWS](migrate-relational-database-to-mongodb-atlas.md) + [でセルフホスト MongoDB 環境を MongoDB Atlas に移行する AWS](migrate-a-self-hosted-mongodb-environment-to-mongodb-atlas-on-the-aws-cloud.md) + [AWS DMS を使用して Oracle データベースを Amazon DynamoDB に移行する](migrate-an-oracle-database-to-amazon-dynamodb-using-aws-dms.md) + [SharePlex と AWS DMS を使用して、Oracle 8i または 9i から Amazon RDS for Oracle に移行](migrate-from-oracle-8i-or-9i-to-amazon-rds-for-oracle-using-shareplex-and-aws-dms.md) + [オンプレミス MySQL データベースを Amazon EC2 に移行する](migrate-an-on-premises-mysql-database-to-amazon-ec2.md) + [暗号化されていない Amazon Aurora インスタンスをモニタリングする](monitor-amazon-aurora-for-instances-without-encryption.md) + [Amazon CloudWatch を使用して Oracle GoldenGate ログを監視する](monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.md) + [Amazon RDS for Oracle で Oracle Database エンタープライズエディションから標準エディション 2 へリプラットフォームする](replatform-oracle-database-enterprise-edition-to-standard-edition-2-on-amazon-rds-for-oracle.md) + [Precisely Connect を使用してメインフレームデータベースを AWS にレプリケート](replicate-mainframe-databases-to-aws-by-using-precisely-connect.md) + [Lambda と Secrets Manager を使用して Amazon RDS for PostgreSQL と Aurora PostgreSQL のジョブをスケジュールする](schedule-jobs-for-amazon-rds-for-postgresql-and-aurora-postgresql-by-using-lambda-and-secrets-manager.md) + [オンプレミスの SMTP サーバーとデータベースメールを使用して、Amazon RDS for SQL Server データベースインスタンスに通知を送信します。](send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.md) + [AWS の IBM Db2 に SAP のディザスタリカバリをセットアップ](set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.md) + [Terraform を使用してデータベース移行用の CI/CD パイプラインを設定する](set-up-ci-cd-pipeline-for-db-migration-with-terraform.md) + [FSx for Windows File Server を使用して Amazon EC2 で Microsoft SQL Server フェイルオーバークラスターをセットアップする](microsoft-sql-failover-cluster-on-amazon-ec2.md) + [Amazon RDS Custom でアクティブスタンバイデータベースを使用して Oracle E-Business Suite の HA/DR アーキテクチャを設定する](set-up-an-ha-dr-architecture-for-oracle-e-business-suite-on-amazon-rds-custom-with-an-active-standby-database.md) + [IBM Db2、SAP、Sybase、およびその他のデータベースから の MongoDB Atlas にデータをストリーミングする AWS](stream-data-from-ibm-db2-to-mongodb-atlas.md) + [Amazon RDS Custom for Oracle 上の Oracle PeopleSoft アプリケーションの移行ロール](transition-roles-for-an-oracle-peoplesoft-application-on-amazon-rds-custom-for-oracle.md) + [アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする](unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.md) + [ワークロード別のデータベース移行パターン](databases-database-migration-patterns-by-workload-pattern-list.md) + [その他のパターン](databases-more-patterns-pattern-list.md) # リンクサーバーを使用して Amazon EC2 上のMicrosoft SQL サーバーからオンプレミスの Microsoft SQL Server テーブルにアクセスする *Amazon Web Services、Tirumala Dasari、Eduardo Valentim* ## 概要 このパターンは、リンクサーバーを使用して Amazon Elastic Compute Cloud (Amazon EC2) Windows または Linux インスタンスで実行またはホストされている Microsoft SQL Server データベースから、Microsoft Windows 上で実行されているオンプレミスの Microsoft SQL Server データベーステーブルにアクセスする方法を示しています。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Amazon Linux AMI で実行されている Microsoft SQL Server を使用した Amazon EC2 (Amazon Machine Image) + オンプレミスのMicrosoft SQL サーバー (Windows) サーバーと Windows または Linux の EC2 インスタンス間の AWS Direct Connect **製品バージョン** + SQL Server 2016 以降 ## アーキテクチャ **ソーステクノロジースタック** + Windows 上で稼働するオンプレミスのMicrosoft SQL サーバーデータベース + Windows AMI または Linux AMI 上で動作するMicrosoft SQL サーバーを搭載した Amazon EC2 **ターゲットテクノロジースタック** + Amazon Linux AMI で実行されている Microsoft SQL Server を使用した Amazon EC2 + Windows AMI で実行されている Microsoft SQL Server を使用した Amazon EC2 ソースとターゲットのデータベースアーキテクチャ ![\[AWS クラウド architecture with VPC, availability zones, and hybrid environment connecting to on-premises database.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8e4a3222-0850-4980-8028-c710dcdb9186/images/fa157992-0ed9-46e1-8059-0cbbb74a98ec.png) ## ツール + 「[Microsoft SQL Server Management Studio (SSMS)](https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver16)」は、SQL Server インフラストラクチャを管理するための統合環境です。SQL Server とやり取りする豊富なスクリプトエディタを備えた、ユーザーインターフェイスとツールグループを備えています。 ## エピック ### Windows SQL Server の SQL Server の認証モードを Windows に変更します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSMS 経由で Windows SQL サーバーに接続します。 | | DBA | | Windows SQL Server インスタンスのコンテンツ (右クリック) メニューから、SQL Server の認証モードを Windows に変更します。 | | DBA | ### Windows MSSQL サービスを再起動します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SQL サービスを再起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/access-on-premises-microsoft-sql-server-tables-from-microsoft-sql-server-on-amazon-ec2-using-linked-servers.html) | DBA | ### Windows SQL Server で新しいログイン情報を作成し、アクセスするデータベースを選択します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | [セキュリティ] タブで、[ログイン] のコンテンツ (右クリック) メニューを開き、新しいログインを選択します。 | | DBA | | [全般] タブで [SQL Server 認証] を選択し、ユーザー名を入力し、パスワードを入力してパスワードを確認して、次回のログイン時にパスワードを変更するオプションをオフにします。 | | DBA | | [サーバーロール] タブで [公開] を選択します。 | | DBA | | [User Mapping] タブで、アクセスするデータベースとスキーマを選択し、データベースを強調表示してデータベースロールを選択します。 | public と db\$1datareader を選択して、データベーステーブルのデータにアクセスします。 | DBA | | 「OK」を選択してユーザーを作成します。 | | DBA | ### Windows SQL サーバー IP を Linux SQL Server ホストファイルに追加します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターミナルウィンドウから Linux SQL Server ボックスに接続します。 | | DBA | | /etc/hosts ファイルを開き、SQL Server がインストールされている Windows マシンの IP アドレスを追加します。 | | DBA | | ホストファイルを保存します。 | | DBA | ### Linux SQL サーバー上にリンクサーバーを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ストアドプロシージャ master.sys.sp\$1addlinkedserver と master.dbo.sp\$1addlinkedsrvlogin を使用してリンクサーバーを作成します。 | これらのストアドプロシージャの使用方法の詳細については、「*追加情報*」セクションを参照してください。 | DBA、開発者 | ### 作成したリンクサーバーとデータベースを SSMS で検証します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSMS の Linux SQL Server では、リンクサーバーに移動して更新してください。 | | DBA | | 左側のペインで、作成したリンクサーバーとカタログを展開します。 | 選択した SQL Server データベースがテーブルとビューとともに表示されます。 | DBA | ### Windows SQL サーバーデータベーステーブルにアクセスできることを確認してください。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSMS クエリウィンドウで、「select top 3 \$1 from [sqllin].dms\$1sample\$1win.dbo.mlb\$1data」というクエリを実行します。 | FROM 句は computer.database.schema.table という 4 つの部分からなる構文を使用していることに注意してください (例えば、[sqllin] .master.sys.databases から「SQL2 データベース」という名前を選択)。この例では、ホストファイルに SQL2 のエイリアスを作成したので、角括弧の間に実際の NetBIOS 名を入力する必要はありません。実際の NetBIOS 名を使用する場合は、AWS ではデフォルトで Win-xxxx などの NetBIOS 名が使用され、SQL Server ではダッシュ付きの名前には角括弧が必要であることに注意してください。 | DBA、開発者 | ## 関連リソース + 「[Linux 上の SQL サーバーのリリースノート](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-release-notes?view=sql-server-2017)」    ## 追加情報 ストアドプロシージャを使用してリンクサーバーを作成する SSMS は Linux SQL Server 用のリンクサーバーの作成をサポートしていないため、以下のストアドプロシージャを使用して作成する必要があります。 ``` EXEC master.sys.sp_addlinkedserver @server= N'SQLLIN' , @srvproduct= N'SQL Server'     EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SQLLIN',@useself=N'False',@locallogin=NULL,@rmtuser=N'username',@rmtpassword='Test123$' ``` 注 1: Windows SQL Server で以前に作成したサインイン認証情報をストアドプロシージャ `master.dbo.sp_addlinkedsrvlogin` に入力します。 注 2: `@server` の名前 `SQLLIN` とホストファイルエントリ名 `172.12.12.4 SQLLIN` は同じでなければなりません。 このプロセスを使用して、以下のシナリオで、リンクサーバーを作成できます。 + (このパターンで指定されているように) リンクサーバーを経由して Linux SQL サーバーから Windows SQL サーバーへ + リンクサーバーを経由して Windows SQL サーバーから Linux SQL サーバーへ + Linux SQL サーバーからリンクサーバー経由で別の Linux SQL サーバーへ # リードレプリカを使用して Amazon RDS Customの Oracle PeopleSoft に HA を追加 *Amazon Web Services、sampath kathirvel* ## 概要 Amazon Web Services (AWS) で「[Oracle PeopleSoft](https://www.oracle.com/applications/peoplesoft/)」エンタープライズリソースプランニング (ERP) ソリューションを実行するには、「[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/)」または「[Amazon RDS Custom for Oracle](https://aws.amazon.com/rds/custom/)」を使用できます。これらは、基盤となるオペレーティングシステムとデータベース環境へのアクセスを必要とするレガシー、カスタムおよびパッケージ化されたアプリケーションをサポートします。移行を計画する際に考慮すべき主な要素については、「AWS 規範ガイダンス」の「[Oracle データベースの移行戦略](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/strategies.html)」を参照してください。 この執筆時点では、「RDS Custom for Oracle」は「[マルチ AZ](https://aws.amazon.com/blogs/aws/multi-az-option-for-amazon-rds-oracle/)」オプションをサポートしていませんが、ストレージ・レプリケーションを使用するHAソリューションとして、「[Amazon RDS for Oracle](https://aws.amazon.com/rds/oracle/)」で利用できます。代わりに、このパターンでは、プライマリデータベースの物理的なコピーを作成して管理するスタンバイデータベースを使用して HA を実現します。このパターンは、Oracle Data Guard を使用してリードレプリカをセットアップし、HA を使って Amazon RDS Custom で PeopleSoft アプリケーションデータベースを実行するステップに焦点を当てます。 同様に、このパターンで、リードレプリカを読み取り専用モードに変更されます。リードレプリカを読み取り専用モードに変更すると、他にも次のような利点があります。 + 読み取り専用のワークロードをプライマリデータベースからオフロードします。 + Oracle Active Data Guard機能によりスタンバイデータベースから正常なブロックを取得することで、破損したブロックを自動的に修復できます。 + Far Sync機能により、REDOログの長距離転送に伴うパフォーマンスのオーバーヘッドなしに、リモート・スタンバイ・データベースを同期状態に保つことができます。 レプリカを読み取り専用モードで使用するには「[Oracle Active Data Guard](https://www.oracle.com/assets/technology-price-list-070617.pdf)」オプションが必要ですが、これは Oracle Database Enterprise Edition の別途ライセンスされた機能であるため、追加料金がかかります。 ## 前提条件と制限事項 **前提条件** + Amazon RDS Customに既存の PeopleSoft アプリケーション。アプリケーションがない場合は、「[Oracle PeopleSoft を Amazon RDS Customに移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-oracle-peoplesoft-to-amazon-rds-custom.html)」というパターンを参照してください。 + 単一の PeopleSoft アプリケーション層。ただし、このパターンを複数のアプリケーション層で機能するように調整できます。 + Amazon RDS Customには 8 GB 以上のスワップスペースが設定されています。 + リードレプリカを読み取り専用モードに変換し、レポートタスクをスタンバイにオフロードすることに使用するための Oracle Active Data Guard データベースライセンス。詳細については、「[Oracle Technology Commercial Price List](https://www.oracle.com/corporate/pricing/#technology)」を参照してください。 制限事項 + 「[RRDS Custom for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits.html#custom-reqs-limits.limits)」の一般的な制限事項とサポートされていない構成 + [Amazon RDS Custom for Oracle リードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html#custom-rr.limitations)に関連する制限 **製品バージョン** + Amazon RDS Custom でサポートされている Oracle データベースのバージョンについては、「[RDS Custom for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.html#Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.ora)」を参照してください。 + Amazon RDS Customでサポートされている Oracle データベースインスタンスクラスについては、「[RDS Custom for Oracle用 DB インスタンスクラスサポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits.html#custom-reqs-limits.instances)」を参照してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon RDS Custom for Oracle + AWS Secrets Manager + Oracle Active Data Guard + Oracle PeopleSoft アプリケーション **ターゲットアーキテクチャ** 以下の図は、Amazon RDS Custom DB インスタンスと Amazon RDS Customリードレプリカを示しています。リードレプリカは Oracle Active Data Guard を使用して別のアベイラビリティーゾーンにレプリケートします。リードレプリカを使用して、プライマリデータベースの読み取りトラフィックをオフロードし、またはレポートを作成することもできます。 ![\[VPC には、AWS Secrets Manager、Amazon EFS、アプリケーション層およびデータベース層が含まれます。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7df4b2d0-b833-4ba3-98e4-a178db395d9d/images/463aefbe-70ad-4cd3-9ddc-0d8347e848c6.png) AWS で Oracle PeopleSoft を使用する代表的なアーキテクチャについては、「[AWS で可用性の高い PeopleSoft アーキテクチャの設定](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html)」を参照してください。 ## ツール **AWS サービス** + 「[Amazon RDS Custom for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-custom-oracle.html)」は、基盤となるオペレーティングシステムとデータベース環境へのアクセスを必要とするレガシーアプリケーション、カスタムアプリケーション、パッケージアプリケーション向けのマネージドデータベースサービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。このパターンでは、`RDS_DATAGUARD` のためシークレット名 `do-not-delete-rds-custom-+<>+-dg` を含むデータベースユーザーパスワードを Secrets Manager から取得できます。 その他のツール + 「[Oracle Data Guard](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/preface.html#GUID-B6209E95-9DA8-4D37-9BAD-3F000C7E3590)」 は、スタンバイデータベースの作成、保守、管理とモニタリングに役立ちます。 ## ベストプラクティス データ損失ゼロ（RPO=0）を目指すには、`MaxAvailability` Data Guard保護モードとREDO転送 `SYNC+NOAFFIRM` 設定を使用してパフォーマンスを向上させてください。データベース保護モードの選択に関する詳細については、*追加情報*のセクションを参照してください。 ## エピック ### リードレプリカの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リードレプリカの作成 | Amazon RDS カスタム DB インスタンスのリードレプリカを作成するには [Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)にある指示に従い、作成した Amazon RDS Custom DB インスタンスをソースデータベースとして使用します (*前提条件*のセクションを参照)。デフォルトでは、Amazon RDS Custom リードレプリカは物理スタンバイとして作成され、マウントされた状態になります。これにより、Oracle Active Data Guard ライセンスへのコンプライアンスが確保されます。このパターンには、マルチテナントコンテナデータベース (CDB) または非 CDB インスタンスを設定するためのコードを含んでいます。 | DBA | ### Oracle Data Guard の保護モードをMaxAvailabilityに変更します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライマリデータベースで Data Guard ブローカ設定にアクセスします。 | この例では、Amazon RDS Customリードレプリカは `RDS_CUSTOM_ORCL_D` 非 CDB インスタンスと `RDS_CUSTOM_RDSCDB_B` CDB インスタンスに使用されます。非 CDB のデータベースは `orcl_a` (プライマリ) と `orcl_d` (スタンバイ) です。CDB のデータベース名は `rdscdb_a` (プライマリ) と `rdscdb_b` (スタンバイ) です。RDS Custom リードレプリカには、直接接続することも、プライマリデータベース経由で接続することもできます。データベースのネットサービス名は、`$ORACLE_HOME/network/admin` ディレクトリにある `tnsnames.ora` ファイルにあります。RDS Custom for Oracle は、これらのエントリをプライマリデータベースとリードレプリカに自動的に入力します。`RDS_DATAGUARD` ユーザーのパスワードは、シークレット名とともに AWS Secrets Manager に保存されます `do-not-delete-rds-custom-+<>+-dg`。Secrets Manager から取得した SSH (セキュアシェル) キーを使用して RDS カスタムインスタンスに接続する方法の詳細については、「[SSH を使用して RDS Custom DB インスタンスに接続する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating.html#custom-creating.ssh)」を参照してください。Data Guard コマンドライン (`dgmgrl`) から Oracle Data Guard ブローカ設定にアクセスするには、次のコードを使用します。非 CDB
$ dgmgrl RDS_DATAGUARD@RDS_CUSTOM_ORCL_D
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Fri Sep 30 22:44:49 2022
Version 19.10.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "ORCL_D"
Connected as SYSDG.
DGMGRL> 
DGMGRL> show database orcl_d
Database - orcl_d
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Average Apply Rate: 11.00 KByte/s
Instance(s):
ORCL
SUCCESS
DGMGRL>
**CDB**
-bash-4.2$ dgmgrl C##RDS_DATAGUARD@RDS_CUSTOM_RDSCDB_B
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Jan 11 20:24:11 2023
Version 19.16.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "RDSCDB_B"
Connected as SYSDG.
DGMGRL>
DGMGRL> show database rdscdb_b
Database - rdscdb_b
  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 2.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    RDSCDB
Database Status:
SUCCESS
DGMGRL>
| DBA | | プライマリノードから DGMGRL に接続して、ログ転送設定を変更します。 | REDO 転送設定 `SYNC+NOAFFIRM` に対応するログ転送モードを `FastSync` に変更します。ロールの切り替え後も設定が有効であることを確認するには、プライマリデータベースとスタンバイデータベースの両方の設定を変更してください。非 CDB
DGMGRL>
DGMGRL> edit database orcl_d set property logxptmode=fastsync;
Property "logxptmode" updated
DGMGRL> show database orcl_d LogXptMode;
LogXptMode = 'fastsync'
DGMGRL> edit database orcl_a set property logxptmode=fastsync;
Property "logxptmode" updated
DGMGRL> show database orcl_a logxptmode;
LogXptMode = 'fastsync'
DGMGRL>
**CDB**
DGMGRL> edit database rdscdb_b set property logxptmode=fastsync;DGMGRL> edit database rdscdb_b set property logxptmode=fastsync;
Property "logxptmode" updated
DGMGRL> show database rdscdb_b LogXptMode;
  LogXptMode = 'fastsync'
DGMGRL> edit database rdscdb_a set property logxptmode=fastsync;
Property "logxptmode" updated
DGMGRL> show database rdscdb_a logxptmode;
  LogXptMode = 'fastsync'
DGMGRL>
| DBA | | 保護モードをMaxAvailabilityに変更します。 | 保護モードを `MaxAvailability` プライマリノードから `DGMGRL` に接続することによる保護モードに変更します。非 CDB
DGMGRL> edit configuration set protection mode as maxavailability;
Succeeded.
DGMGRL> show configuration;
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_a - Primary database
orcl_d - Physical standby database 
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 38 seconds ago)
DGMGRL>
**CDB**
DGMGRL> show configuration
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_a - Primary database
    rdscdb_b - Physical standby database 
Fast-Start Failover:  Disabled
Configuration Status:
SUCCESS   (status updated 57 seconds ago)
DGMGRL>
| DBA | ### レプリカのステータスをマウントから読み取り専用に変更し、再実行適用を有効にします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スタンバイデータベースへの再実行適用を停止します。 | リードレプリカはデフォルトで `MOUNT` モードで作成されます。読み取り専用モードで開くには、まずプライマリまたはスタンバイノードから `DGMGRL` に接続して再実行適用を無効にする必要があります。非 CDB
DGMGRL> show database orcl_dDGMGRL> show database orcl_d
Database - orcl_d
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 11.00 KByte/s
Real Time Query: OFF
Instance(s):
ORCL
Database Status:
SUCCESS
DGMGRL> edit database orcl_d set state=apply-off;
Succeeded.
DGMGRL> show database orcl_d
Database - orcl_d
Role: PHYSICAL STANDBY
Intended State: APPLY-OFF
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 42 seconds (computed 1 second ago)
Average Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
ORCL
Database Status:
SUCCESS
DGMGRL>
**CDB**
DGMGRL> show configurationDGMGRL> show configuration
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_a - Primary database
    rdscdb_b - Physical standby database 
Fast-Start Failover:  Disabled
Configuration Status:
SUCCESS   (status updated 57 seconds ago)
DGMGRL> show database rdscdb_b;
Database - rdscdb_b
  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 2.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    RDSCDB
Database Status:
SUCCESS
DGMGRL> edit database rdscdb_b set state=apply-off;
Succeeded.
DGMGRL> show database rdscdb_b;
Database - rdscdb_b
  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-OFF
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: (unknown)
  Real Time Query:    OFF
  Instance(s):
    RDSCDB
Database Status:
SUCCESS
| DBA | | リードレプリカインスタンスを読み取り専用モードでオープンします。 | TNS エントリを使用してスタンバイデータベースに接続し、プライマリまたはスタンバイノードから接続して読み取り専用モードで開きます。非 CDB
$ sqlplus RDS_DATAGUARD@RDS_CUSTOM_ORCL_D as sysdg
-bash-4.2$ sqlplus RDS_DATAGUARD@RDS_CUSTOM_ORCL_D as sysdg
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Sep 30 23:00:14 2022
Version 19.10.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Enter password: 
Last Successful login time: Fri Sep 30 2022 22:48:27 +00:00
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.10.0.0.0
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
SQL> alter database open read only;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
SQL>
**CDB**
-bash-4.2$ sqlplus C##RDS_DATAGUARD@RDS_CUSTOM_RDSCDB_B as sysdg
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jan 11 21:14:07 2023
Version 19.16.0.0.0
Copyright (c) 1982, 2022, Oracle.  All rights reserved.
Enter password: 
Last Successful login time: Wed Jan 11 2023 21:12:05 +00:00
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.16.0.0.0
SQL> select name,open_mode from v$database;
NAME   OPEN_MODE
--------- --------------------
RDSCDB   MOUNTED
SQL> alter database open read only;
Database altered.
SQL> select name,open_mode from v$database;
NAME   OPEN_MODE
--------- --------------------
RDSCDB   READ ONLY
SQL>
| DBA | | リードレプリカインスタンスで 再実行適用を有効にします。 | プライマリまたはスタンバイノードから `DGMGR` L を使用して、リードレプリカインスタンスで 再実行適用を有効にします。非 CDB
$ dgmgrl RDS_DATAGUARD@RDS_CUSTOM_ORCL_D
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Fri Sep 30 23:02:16 2022
Version 19.10.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "ORCL_D"
Connected as SYSDG.
DGMGRL> 
edit database orcl_d set state=apply-on;
DGMGRL> edit database orcl_d set state=apply-on;
Succeeded.
DGMGRL> show database orcl_d
Database - orcl_d
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Average Apply Rate: 496.00 KByte/s
Real Time Query: ON
Instance(s):
ORCL
Database Status:
SUCCESS
DGMGRL>
**CDB**
-bash-4.2$ dgmgrl C##RDS_DATAGUARD@RDS_CUSTOM_RDSCDB_B-bash-4.2$ dgmgrl C##RDS_DATAGUARD@RDS_CUSTOM_RDSCDB_B
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Jan 11 21:21:11 2023
Version 19.16.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "RDSCDB_B"
Connected as SYSDG.
DGMGRL> edit database rdscdb_b set state=apply-on;
Succeeded.
DGMGRL> show database rdscdb_b           
Database - rdscdb_b
  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 35.00 KByte/s
  Real Time Query:    ON
  Instance(s):
    RDSCDB
Database Status:
SUCCESS
DGMGRL> show database rdscdb_b   
Database - rdscdb_b
  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 16.00 KByte/s
  Real Time Query:    ON
  Instance(s):
    RDSCDB
Database Status:
SUCCESS
DGMGRL>
| DBA | ## 関連リソース + 「[Amazon RDS を Oracle PeopleSoft Database として設定](https://d1.awsstatic.com/whitepapers/configuring-amazon-rds-as-peoplesoft-database.pdf)」AWS ホワイトペーパー) + [Oracle Data Guard Broker ガイド](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/index.html) (Oracle リファレンスドキュメント) + 「[Oracle Data Guard 概要および管理](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/index.html)」(Oracleのリファレンスドキュメント) ## 追加情報 データベース保護モードを選択 Oracle Data Guardには、可用性、保護、パフォーマンスの要件に基づいてData Guard環境を構成するための 3 つの保護モードが用意されています。次の表は、これら 3 つのモードをまとめたものです。 | | | 保護モード | 転送設定を再実行 | 説明 | | --- |--- |--- | | 最高のパフォーマンス | `ASYNC` | プライマリデータベースで発生するトランザクションでは、再実行データが非同期的に送信され、スタンバイデータベースの再実行ログに書き込まれます。したがって、パフォーマンスへの影響は最小限に控えられます。非同期のログ配布のため、`MaxPerformance` はRPO=0 を指定できません。 | | 最大限の保護 | `SYNC+AFFIRM` | プライマリデータベース上のトランザクションでは、トランザクションが確認される前に、再実行データが同期的に転送され、ディスク上のスタンバイデータベース再実行ログに書き込まれます。スタンバイデータベースが使用できなくなった場合、プライマリデータベースは自動的にシャットダウンし、トランザクションが確実に保護されます。 | | 最大限の可用性 | `SYNC+AFFIRM` | これは、スタンバイ・データベースから確認応答が受信されない場合を除いて、`MaxProtection` モードと似ています。この場合は、再実行ストリームを同期化されたスタンバイ・データベースにに再び書き込めるようになるまで、プライマリデータベースの可用性を維持する `MaxPerformance` モードになっているかのように動作します。 | | `SYNC+NOAFFIRM` | プライマリデータベース上のトランザクションでは、再実行はスタンバイデータベースに同期的に転送され、プライマリデータベースは再実行がスタンバイディスクに書き込まれるのではなく、スタンバイデータベースで再実行が受信されたことを確認するのみです。このモード (`FastSync` とも呼ばれる) は、複数の同時障害が発生する特殊なケースではデータが失われる可能性がありますが、パフォーマンス上のメリットがあります。 | RDS Custom for Oracle のリードレプリカは、Oracle Data Guard のデフォルトの保護モードでもある最大パフォーマンス保護モードで作成されます。最大パフォーマンスモードは、プライマリデータベースへのパフォーマンスへの影響を最小限に抑え、秒単位で測定される目標復旧時点 (RPO) の要件を満たすのに役立ちます。 データ損失ゼロ (RPO=0) の目標を達成するには、パフォーマンスを向上させるために、Oracle Data Guard保護モードをREDO転送の `SYNC+NOAFFIRM` 設定で `MaxAvailability` にカスタマイズできます。プライマリ・データベースでのコミットは、対応する REDO ベクトルがスタンバイ・データベースに正常に転送された後にのみ確認されるため、プライマリ・インスタンスとレプリカ間のネットワーク遅延は、コミットに敏感なワークロードにとって極めて重要です。リードレプリカを `MaxAvailability` モードで実行するようにカスタマイズした場合のパフォーマンスへの影響を評価するために、ワークロードの負荷テストを実施することをお勧めします。 リードレプリカをプライマリデータベースと同じアベイラビリティーゾーンにデプロイすると、リードレプリカを別のアベイラビリティーゾーンにデプロイする場合よりもネットワークレイテンシーが低くなります。ただし、プライマリとリードコピーインスタンスの両方が影響を受けるため、同じ可用性ゾーンにマスターインスタンスとリードコピーを配備してもHA要件を満たすことができない場合があります。 # Oracle から PostgreSQL への部分的なデータベース移行に関するオブジェクトの依存関係を分析する *Amazon Web Services、Anuradha Chintha* ## 概要 このパターンでは、部分的な Oracle データベースを Amazon Relational Database Service (Amazon RDS) または Amazon Aurora PostgreSQL に移行するときに、システムの依存関係を体系的に識別および管理することの重要性について説明します。部分的な移行では、元のデータベースからのデータベースオブジェクトとデータのサブセットのみが移行されますが、ソースデータベースでは移行されていないコンポーネントに依存するアプリケーションを引き続き運用および提供します。 アップストリームとダウンストリームの依存関係と緊密に結合したアプリケーションを持つ大規模なデータベースを処理する場合は、移行の範囲を特定して分析する必要があります。部分的な移行を開始するには、テーブル、トリガー、ビュー、ストアドプロシージャ、関数、パッケージなどのスコープオブジェクトを特定します。スコープ識別プロセスは、以下の包括的なアプローチに従って進めます。 + 第 1 レベルのスコープオブジェクトは、アプリケーションコードと重要なモジュール固有のジョブの直接参照によって識別されます。 + 第 2 レベルのオブジェクトは、包括的な依存関係分析によって導出されます。 システムのさまざまな部分がどのように相互作用するかを理解すると、データベースコンポーネントを移動するための正しい順序をより適切に計画し、移行失敗のリスクを減らすことができます。次の表に、さまざまなタイプの依存関係分析を示します。 | | | 分析タイプ | 焦点 | 目的 | | --- |--- |--- | | オブジェクトの依存関係 | テーブルビューストアドプロシージャ関数トリガ | データベースオブジェクトとその階層構造間の関係を識別する | | セグメントの依存関係 | 外部キー関係プライマリキーチェーンクロススキーマリファレンス | データ関係をマッピングし、参照整合性を維持する | | セキュリティ依存関係 | ユーザーアクセス許可ロール階層オブジェクト権限 | 適切なアクセスコントロールの移行とセキュリティメンテナンスを行う | | アクセスパターン | 読み込みオペレーション書き込みオペレーション | データベースインタラクションパターンを決定する | ソースシステムとターゲットシステム間の一貫性を維持するには、移行期間中にデータ同期メカニズムを確立します。また、ソース Oracle データベースとターゲット PostgreSQL データベースの両方でデータ分散を処理するように、アプリケーションコードと関数を変更する必要があります。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Oracle データベース (ソース) + Amazon RDS または Amazon Aurora PostgreSQL (ターゲット) **製品バージョン** + Oracle 19c 以降 + PostgreSQL 16 以降 ## アーキテクチャ **ソーステクノロジースタック** + Oracle 19c 以降 **ターゲットテクノロジースタック** + Amazon RDS または Amazon Aurora PostgreSQL **ターゲットアーキテクチャ** 次の図は、オンプレミスの Oracle データベースから Amazon RDS for Oracle への移行プロセスを示しています。これには以下が含まれます。 + 依存関係の特定 + AWS Schema Conversion Tool (AWS SCT) を使用したデータベースコードとオブジェクトの移行 + AWS Database Migration Service (AWS DMS) を使用したデータの移行 + を使用した変更データキャプチャ (CDC) による継続的な変更のレプリケート AWS DMS 詳細については、 AWS ドキュメントの[「 AWS Database Migration Service との統合 AWS Schema Conversion Tool](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_DMSIntegration.html)」を参照してください。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/90160825-3199-4382-95a8-ad63139c5c89/images/b09c36a4-27fa-412e-877e-57a31bcce0dc.png) ## ツール **AWS のサービス** + Oracle の [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html) を活用することで、 AWS クラウド上で Oracle リレーショナルデータベースのセットアップ、運用、スケーリングができます。 + 「Amazon Aurora」はクラウド用に構築されたフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + AWS Schema Conversion Tool (AWS SCT) は、ソースデータベーススキーマとカスタムコードの大部分をターゲットデータベースと互換性のある形式に自動的に変換することで、異種データベースの移行をサポートします。 + [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) を使用すると、データストアを に移行する AWS クラウド か、クラウドとオンプレミスのセットアップの組み合わせ間で移行できます。 **その他のサービス** + [Oracle SQL Developer](https://www.oracle.com/database/technologies/appdev/sqldeveloper-landing.html) は、従来のデプロイとクラウドベースのデプロイの両方で Oracle データベースの開発と管理を簡素化する統合開発環境です。このパターンでは、[SQL\$1Plus](https://docs.oracle.com/cd/B19306_01/server.102/b14357/qstart.htm) を使用できます。 ## ベストプラクティス Oracle データベースのプロビジョニングと移行に関するベストプラクティスについては、「[Best practices for migrating to Amazon RDS for Oracle](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/best-practices.html)」をご確認ください。 ## エピック ### オブジェクト依存関係の識別 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オブジェクトテーブルを作成します。 | アプリケーションの機能に不可欠なオブジェクトを特定し、`DEPENDENT_ANALYSIS_BASELINE` という名前のテーブルを作成します。各オブジェクトのレコードをテーブルに追加します。サンプルは「*追加情報*」セクションからご確認ください。 | データエンジニア、DBA | | データベースプロシージャを作成します。 | `DBA_DEPENDENCIES` テーブルのデータを使用して、オブジェクトの依存関係を双方向 (前後) で分析する `sp_object_dependency_analysis` という名前のストアドプロシージャを作成します。サンプルは「*追加情報*」セクションからご確認ください。 | データエンジニア、DBA | | プロシージャを実行します。 | 新しいオブジェクトの依存関係が見つからなくなるまで、連続する各レベルでスクリプトを実行します。すべての依存関係とレベルが `DEPENDENT_ANALYSIS_BASELINE` テーブルに保存されます。 | DBA、データエンジニア | ### セグメントレベルの依存関係のプロシージャを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 依存関係テーブルを作成します。 | `REFERENTIAL_ANALYSIS_BASELINE` という名前のセグメントレベルの依存関係テーブルを作成します。すべてのオブジェクトレベルの依存関係が検出されたら、`DBA_CONSTRAINT` テーブルをクエリして `DEPENDENT_ANALYSIS_BASELINE` の親テーブルを確認します。ベースラインテーブルが他のテーブルによって参照される依存関係を除外します。バックフィルは、これらの関係を処理します。スクリプトの例を次に示します。
CREATE TABLE REFERENTIAL_ANALYSIS_BASELINE
(CHILD_OWNER VARCHAR2(50 BYTE),
CHILD_NAME VARCHAR2(100 BYTE),
PARENT_OWNER VARCHAR2(50 BYTE),
PARENT_NAME VARCHAR2(50 BYTE),
REFERENCE_PATH VARCHAR2(1000 BYTE));
| データエンジニア、DBA | | データベースプロシージャを作成します。 | `SP_OBJECT_REFERENTIAL_ANALYSIS` というプロシージャを作成し、識別されたすべてのオブジェクトの参照分析を生成します。サンプルは「*追加情報*」セクションからご確認ください。 | データエンジニア、DBA | | プロシージャを実行します。 | 手順を実行して、参照依存関係を取得します。`REFERENTIAL_ANALYSIS_BASELINE` で参照分析オブジェクトの詳細を生成します。 | データエンジニア、DBA | ### 読み取りと書き込みを行うオブジェクトを特定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 読み取りおよび書き込みオブジェクトのテーブルを作成します。 | 次のスクリプトを使用して、`TABLE_WRITE_OBJECT_DETAILS` という名前の読み取りオブジェクトテーブルと `TABLE_READ_OBJECT_DETAILS` という名前の書き込みオブジェクトテーブルを作成します。
CREATE TABLE TABLE_READ_OBJECT_DETAILS
(OWNER VARCHAR2(50 BYTE),
TAB_NAME VARCHAR2(50 BYTE),
READER_OWNER VARCHAR2(50 BYTE),
READER_NAME VARCHAR2(50 BYTE),
READER_TYPE VARCHAR2(50 BYTE));
CREATE TABLE TABLE_WRITE_OBJECT_DETAILS
(TABLE_NAME VARCHAR2(100 BYTE),
WRITEOBJ_OWNER VARCHAR2(100 BYTE),
WRITEOBJ_NAME VARCHAR2(100 BYTE),
WRITEOBJ_TYPE VARCHAR2(100 BYTE),
LINE VARCHAR2(100 BYTE),
TEXT VARCHAR2(4000 BYTE),
OWNER VARCHAR2(50 BYTE));
| データエンジニア、DBA | | 分析のためのプロシージャを作成します。 | 読み取りオブジェクトと書き込みオブジェクトをそれぞれ分析するためのプロシージャ `SP_READER_OBJECTS_ANALYSIS` と `SP_WRITER_OBJECTS_ANALYSIS` を作成します。これらのプロシージャは、パターンマッチングを使用して関連オブジェクトを検索します。サンプルは「*追加情報*」セクションからご確認ください。 | データエンジニア、DBA | | プロシージャを実行します。 | プロシージャを実行して、依存オブジェクトを識別します。 | DBA、データエンジニア | ### データベース権限を確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 権限を確認するためのテーブルを作成します。 | 権限分析を行う `OBJECT_PRIVS_ANALYSIS` という名称のテーブルを作成します。`DEPENDENT_ANALYSIS_BASELINE` テーブルでオブジェクト権限を再帰的にキャプチャするには、次のスクリプトを使用します。
CREATE TABLE OBJECT_PRIVS_ANALYSIS
(OWNER VARCHAR2(50 BYTE),
OBJECT_NAME VARCHAR2(50 BYTE),
USER_NAME VARCHAR2(50 BYTE),
PRIVS VARCHAR2(50 BYTE));
| データエンジニア、DBA | | 権限を確認するためのプロシージャを作成します。 | `SP_OBJECT_PRIVS_ANALYSIS` という名称のプロシージャを作成します。識別されたオブジェクトの権限分析を生成します。サンプルは「*追加情報*」セクションからご確認ください。 | DBA、データエンジニア | | プロシージャを実行します。 | プロシージャを実行し、`OBJECT_PRIVS_ANALYSIS` テーブルにキャプチャします。 | DBA、データエンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | ディクショナリテーブルにアクセスできない | 分析オブジェクトを作成したユーザーが DBA テーブルにアクセスできることを確認します。 | ## 関連リソース **AWS ドキュメント** + [Amazon RDS および Aurora ドキュメント](https://docs.aws.amazon.com/rds/) + [Oracle database 19c to Amazon Aurora PostgreSQL migration playbook](https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-postgresql-migration-playbook/chap-oracle-aurora-pg.html) + [とは AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/) + [What is the AWS Schema Conversion Tool?](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/) **その他のドキュメント** + [Oracle データベースオブジェクト](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Database-Objects.html) ## 追加情報 **`DEPENDENT_ANALYSIS_BASELINE` のスクリプト** ``` CREATE TABLE DEPENDENT_ANALYSIS_BASELINE (OWNER VARCHAR2(128 BYTE) NOT NULL ENABLE, OBJECT_NAME VARCHAR2(128 BYTE) NOT NULL ENABLE, OBJECT_TYPE VARCHAR2(20 BYTE), DEPEDNCY_LEVEL NUMBER, PROJECT_NEED VARCHAR2(20 BYTE), CATAGORY VARCHAR2(4000 BYTE), COMMENTS VARCHAR2(4000 BYTE), CATAGORY1 CLOB, COMMENTS1 CLOB, CUSTOMER_COMMENTS VARCHAR2(1000 BYTE), BACKFILL_TO_GUS VARCHAR2(1000 BYTE), BACKFILL_NEAR_REAL_TIME_OR_BATCH VARCHAR2(1000 BYTE), PK_EXISTS VARCHAR2(3 BYTE), UI_EXISTS VARCHAR2(3 BYTE), LOB_EXISTS VARCHAR2(3 BYTE), MASTER_LINK VARCHAR2(100 BYTE), CONSTRAINT PK_DEPENDENT_ANALYSIS_BASELINE PRIMARY KEY (OWNER,OBJECT_NAME,OBJECT_TYPE)); ``` **`SP_WRITER_OBJECTS_ANALYSIS` のプロシージャ** ``` CREATE OR REPLACE PROCEDURE SP_WRITER_OBJECTS_ANALYSIS IS BEGIN EXECUTE IMMEDIATE 'TRUNCATE TABLE TABLE_WRITE_OBJECT_DETAILS'; FOR I IN (SELECT OWNER, OBJECT_NAME FROM DEPENDENT_ANALYSIS_BASELINE WHERE OBJECT_TYPE = 'TABLE') LOOP INSERT INTO TABLE_WRITE_OBJECT_DETAILS(OWNER, TABLE_NAME, WRITEOBJ_OWNER, WRITEOBJ_NAME, WRITEOBJ_TYPE, LINE, TEXT) SELECT DISTINCT I.OWNER, I.OBJECT_NAME, OWNER WRITEOBJ_OWNER, NAME, TYPE, LINE, TRIM(TEXT) FROM DBA_SOURCE WHERE UPPER(TEXT) LIKE '%' || I.OBJECT_NAME || '%' AND (UPPER(TEXT) LIKE '%INSERT%' || I.OBJECT_NAME || '%' OR UPPER(TEXT) LIKE '%UPDATE%' || I.OBJECT_NAME || '%' OR UPPER(TEXT) LIKE '%DELETE%' || I.OBJECT_NAME || '%' OR UPPER(TEXT) LIKE '%UPSERT%' || I.OBJECT_NAME || '%' OR UPPER(TEXT) LIKE '%MERGE%' || I.OBJECT_NAME || '%') AND UPPER(TEXT) NOT LIKE '%PROCEDURE%' AND UPPER(TEXT) NOT LIKE 'PROCEDURE%' AND UPPER(TEXT) NOT LIKE '%FUNCTION%' AND UPPER(TEXT) NOT LIKE 'FUNCTION%' AND UPPER(TEXT) NOT LIKE '%TRIGGER%' AND UPPER(TEXT) NOT LIKE 'TRIGGER%' AND UPPER(TRIM(TEXT)) NOT LIKE '%AFTER UPDATE%' AND UPPER(TRIM(TEXT)) NOT LIKE 'BEFORE UPDATE%' AND UPPER(TRIM(TEXT)) NOT LIKE 'BEFORE INSERT%' AND UPPER(TRIM(TEXT)) NOT LIKE 'AFTER INSERT%' AND UPPER(TRIM(TEXT)) NOT LIKE 'BEFORE DELETE%' AND UPPER(TRIM(TEXT)) NOT LIKE 'AFTER DELETE%' AND UPPER(TRIM(TEXT)) NOT LIKE '%GGLOGADM.GG_LOG_ERROR%' AND (TRIM(TEXT) NOT LIKE '/*%' AND TRIM(TEXT) NOT LIKE '--%' ) AND (OWNER, NAME, TYPE) IN (SELECT OWNER, NAME, TYPE FROM DBA_DEPENDENCIES WHERE REFERENCED_NAME = I.OBJECT_NAME); END LOOP; END; ``` **`SP_READER_OBJECTS_ANALYSIS` のスクリプト** ``` CREATE OR REPLACE PROCEDURE SP_READER_OBJECTS_ANALYSIS IS BEGIN EXECUTE IMMEDIATE 'TRUNCATE TABLE TABLE_READ_OBJECT_DETAILS'; FOR I IN (SELECT OWNER, OBJECT_NAME FROM DEPENDENT_ANALYSIS_BASELINE WHERE OBJECT_TYPE = 'TABLE') LOOP INSERT INTO TABLE_READ_OBJECT_DETAILS SELECT DISTINCT i.owner, i.object_name, owner, name, type FROM dba_dependencies WHERE referenced_name = I.OBJECT_NAME AND referenced_type = 'TABLE' AND type NOT IN ('SYNONYM', 'MATERIALIZED VIEW', 'VIEW') AND (owner, name, type) NOT IN ( SELECT DISTINCT owner, trigger_name, 'TRIGGER' FROM dba_triggers WHERE table_name = I.OBJECT_NAME AND table_owner = i.owner UNION ALL SELECT DISTINCT owner, name, type FROM dba_source WHERE upper(text) LIKE '%' || I.OBJECT_NAME || '%' AND (upper(text) LIKE '%INSERT %' || I.OBJECT_NAME || '%' OR upper(text) LIKE '%UPDATE% ' || I.OBJECT_NAME || '%' OR upper(text) LIKE '%DELETE %' || I.OBJECT_NAME || '%' OR upper(text) LIKE '%UPSERT %' || I.OBJECT_NAME || '%' OR upper(text) LIKE '%MERGE %' || I.OBJECT_NAME || '%') AND upper(text) NOT LIKE '%PROCEDURE %' AND upper(text) NOT LIKE 'PROCEDURE %' AND upper(text) NOT LIKE '%FUNCTION %' AND upper(text) NOT LIKE 'FUNCTION %' AND upper(text) NOT LIKE '%TRIGGER %' AND upper(text) NOT LIKE 'TRIGGER %' AND upper(trim(text)) NOT LIKE 'BEFORE INSERT %' AND upper(trim(text)) NOT LIKE 'BEFORE UPDATE %' AND upper(trim(text)) NOT LIKE 'BEFORE DELETE %' AND upper(trim(text)) NOT LIKE 'AFTER INSERT %' AND upper(trim(text)) NOT LIKE 'AFTER UPDATE %' AND upper(trim(text)) NOT LIKE 'AFTER DELETE %' AND (trim(text) NOT LIKE '/*%' AND trim(text) NOT LIKE '--%')); END LOOP; END; ``` **`SP_OBJECT_REFERENTIAL_ANALYSIS` のスクリプト** ``` CREATE OR REPLACE PROCEDURE SP_OBJECT_REFERENTIAL_ANALYSIS IS BEGIN EXECUTE IMMEDIATE 'TRUNCATE TABLE REFERENTIAL_ANALYSIS_BASELINE'; INSERT INTO REFERENTIAL_ANALYSIS_BASELINE WITH rel AS ( SELECT DISTINCT c.owner, c.table_name, c.r_owner r_owner, (SELECT table_name FROM dba_constraints WHERE constraint_name = c.r_constraint_name AND owner = c.r_owner) r_table_name FROM dba_constraints c WHERE constraint_type = 'R' AND c.owner NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y') AND c.r_owner NOT IN (SELECT username FROM dba_users WHERE oracle_maintained = 'Y')), tab_list AS ( SELECT OWNER, object_name FROM DEPENDENT_ANALYSIS_BASELINE WHERE UPPER(OBJECT_TYPE) = 'TABLE') SELECT DISTINCT owner child_owner, table_name child, r_owner parent_owner, r_table_name parent, SYS_CONNECT_BY_PATH(r_table_name, ' -> ') || ' -> ' || table_name PATH FROM rel START WITH (r_owner, r_table_name) IN (SELECT * FROM tab_list) CONNECT BY NOCYCLE (r_owner, r_table_name) = ((PRIOR owner, PRIOR table_name)) UNION SELECT DISTINCT owner child_owner, table_name child, r_owner parent_owner, r_table_name parent, SYS_CONNECT_BY_PATH(table_name, ' -> ') || ' -> ' || r_table_name PATH FROM rel START WITH (owner, table_name) IN (SELECT * FROM tab_list) CONNECT BY NOCYCLE (owner, table_name) = ((PRIOR r_owner, PRIOR r_table_name)); END; ``` **`SP_OBJECT_PRIVS_ANALYSIS` のスクリプト** ``` CREATE OR REPLACE PROCEDURE SP_OBJECT_PRIVS_ANALYSIS IS V_SQL VARCHAR2(4000); V_CNT NUMBER; BEGIN V_SQL := 'TRUNCATE TABLE OBJECT_PRIVS_ANALYSIS'; EXECUTE IMMEDIATE V_SQL; FOR I IN (SELECT OWNER, OBJECT_NAME FROM DEPENDENT_ANALYSIS_BASELINE WHERE OBJECT_TYPE = 'TABLE') LOOP INSERT INTO OBJECT_PRIVS_ANALYSIS(OWNER, OBJECT_NAME, USER_NAME, PRIVS) WITH obj_to_role AS ( SELECT DISTINCT GRANTEE role_name, DECODE(privilege, 'SELECT', 'READ', 'REFERENCE', 'READ', 'INSERT', 'WRITE', 'UPDATE', 'WRITE', 'DELETE', 'WRITE', privilege) privs FROM DBA_TAB_PRIVS t, DBA_ROLES r WHERE OWNER = I.OWNER AND TYPE = 'TABLE' AND TABLE_NAME = I.OBJECT_NAME AND t.GRANTEE = r.ROLE AND r.ROLE IN (SELECT ROLE FROM DBA_ROLES WHERE ORACLE_MAINTAINED = 'N') ) SELECT I.OWNER, I.OBJECT_NAME, grantee, privs FROM ( -- Recursively Role to User mapping with privilege SELECT DISTINCT grantee, privs FROM (SELECT rp.granted_role, rp.grantee, privs, (SELECT DECODE(COUNT(*), 0, 'ROLE', 'USER') FROM (SELECT 'User' FROM DBA_users WHERE username = rp.GRANTEE)) grantee_type FROM DBA_role_privs rp, obj_to_role r WHERE rp.granted_role = r.role_name AND grantee IN ((SELECT USERNAME FROM DBA_USERS WHERE ORACLE_MAINTAINED = 'N') UNION (SELECT ROLE FROM DBA_ROLES WHERE ORACLE_MAINTAINED = 'N')) AND granted_role IN (SELECT ROLE FROM DBA_ROLES WHERE ORACLE_MAINTAINED = 'N') START WITH granted_role IN (SELECT DISTINCT role_name FROM obj_to_role) CONNECT BY granted_role = PRIOR grantee) WHERE grantee_type = 'USER' ) UNION ( -- Direct Object grants to User SELECT I.OWNER, I.OBJECT_NAME, GRANTEE, DECODE(privilege, 'SELECT', 'READ', 'REFERENCE', 'READ', 'INSERT', 'WRITE', 'UPDATE', 'WRITE', 'DELETE', 'WRITE', privilege) privs FROM DBA_TAB_PRIVS, DBA_USERS WHERE GRANTEE = USERNAME AND OWNER = I.OWNER AND TYPE = 'TABLE' AND TABLE_NAME = I.OBJECT_NAME ) ORDER BY 2 DESC; END LOOP; END; ``` **`SP_OBJECT_DEPENDENCY_ANALYSIS` のプロシージャ** ``` CREATE OR REPLACE PROCEDURE SP_OBJECT_DEPENDENCY_ANALYSIS (v_level NUMBER) IS TYPE typ IS RECORD ( schema VARCHAR2(100), obj_type VARCHAR2(100), obj_name VARCHAR2(100), path VARCHAR2(5000) ); TYPE array IS TABLE OF typ; l_data array; c SYS_REFCURSOR; l_errors NUMBER; l_errno NUMBER; l_msg VARCHAR2(4000); l_idx NUMBER; l_level NUMBER; BEGIN l_level := v_level + 1; OPEN c FOR WITH obj_list AS ( SELECT owner schema_name, object_type, object_name FROM DEPENDENT_ANALYSIS_BASELINE WHERE depedncy_level = v_level ), fw_dep_objects AS ( SELECT level lvl, owner, name, type, referenced_owner, referenced_name, referenced_type, SYS_CONNECT_BY_PATH(name, ' -> ') || ' -> ' || referenced_name PATH FROM dba_dependencies START WITH (owner, CASE WHEN type = 'PACKAGE BODY' THEN 'PACKAGE' ELSE type END, name) IN (SELECT schema_name, object_type, object_name FROM obj_list) CONNECT BY NOCYCLE (owner, type, name) = ((PRIOR referenced_owner, PRIOR referenced_type, PRIOR referenced_name)) ), bw_dep_objects AS ( SELECT level lvl, owner, name, type, referenced_owner, referenced_name, referenced_type, SYS_CONNECT_BY_PATH(name, ' <- ') || ' <- ' || referenced_name PATH FROM dba_dependencies START WITH (referenced_owner, CASE WHEN referenced_type = 'PACKAGE BODY' THEN 'PACKAGE' ELSE referenced_type END, referenced_name) IN (SELECT schema_name, object_type, object_name FROM obj_list) CONNECT BY NOCYCLE (referenced_owner, referenced_type, referenced_name) = ((PRIOR owner, PRIOR type, PRIOR name)) ) SELECT * FROM ( (SELECT DISTINCT referenced_owner schema, referenced_type obj_type, referenced_name obj_name, path FROM fw_dep_objects) UNION (SELECT DISTINCT owner schema, type obj_type, name obj_name, path FROM bw_dep_objects) ) WHERE schema IN (SELECT username FROM all_users WHERE oracle_maintained = 'N') ORDER BY obj_type; LOOP FETCH c BULK COLLECT INTO l_data LIMIT 100; BEGIN FORALL i IN 1..l_data.count SAVE EXCEPTIONS INSERT INTO DEPENDENT_ANALYSIS_BASELINE ( owner, object_name, object_type, catagory, depedncy_level, project_need, comments ) VALUES ( l_data(i).schema, l_data(i).obj_name, CASE WHEN l_data(i).obj_type = 'PACKAGE BODY' THEN 'PACKAGE' ELSE l_data(i).obj_type END, 'level ' || l_level || ' dependency', l_level, '', 'from dependency proc' || l_data(i).path ); EXCEPTION WHEN OTHERS THEN l_errors := sql%bulk_exceptions.count; FOR i IN 1..l_errors LOOP l_errno := sql%bulk_exceptions(i).error_code; l_msg := SQLERRM(-l_errno); l_idx := sql%bulk_exceptions(i).error_index; UPDATE DEPENDENT_ANALYSIS_BASELINE SET catagory1 = catagory1 || ', found in level' || l_level || ' dependent of ' || l_data(l_idx).path, comments1 = comments1 || ', from dependency proc exception ' || l_data(i).path WHERE owner = l_data(l_idx).schema AND object_name = l_data(l_idx).obj_name AND object_type = l_data(l_idx).obj_type; END LOOP; END; EXIT WHEN c%NOTFOUND; END LOOP; CLOSE c; END; ``` # SQL Server データベースを AWS 上の MongoDB Atlas に移行する際のクエリパフォーマンスを評価する *Battulga Purevragchaa、Amazon Web Services* *PeerIslands US Inc、Krishnakumar Sathyanarayana* *MongoDB、Babu Srinivasan* ## 概要 このパターンは、MongoDB にほぼ現実世界のデータを読み込み、可能な限り本番シナリオに近い状態で MongoDB クエリのパフォーマンスを評価するための指針となります。評価では、リレーショナルデータベースから MongoDB への移行を計画する際に役立つ情報を得ることができます。このパターンでは、「[PeerIslandsテストデータジェネレーターとパフォーマンスアナライザー](https://tools.peerislands.io/)」を使用してクエリのパフォーマンスをテストします。 このパターンは、Microsoft SQL Server を MongoDB に移行する場合に特に役立ちます。スキーマ変換を実行したり、現在の SQL Server インスタンスから MongoDB にデータをロードしたりするのは非常に複雑になる可能性があるためです。代わりに、実際の移行を開始する前に、ほぼ現実世界のデータを MongoDB にロードし、MongoDB のパフォーマンスを理解し、スキーマ設計を微調整することができます。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + 「[MongoDB](https://www.mongodb.com/docs/atlas/getting-started/)」アトラスに精通していること + MongoDB スキーマ + 一般的なクエリパターン **制限事項** + データのロード時間とパフォーマンスは、MongoDB クラスターインスタンスのサイズによって制限されます。実際のパフォーマンスを理解するために、本番環境での使用が推奨されるインスタンスを選択することをお勧めします。 + PeerIslandsのテストデータジェネレーターとパフォーマンスアナライザーは現在、オンラインのデータロードとクエリのみをサポートしています。オフラインのバッチ処理 (Spark コネクタを使用して MongoDB にデータをロードするなど) はまだサポートされていません。 + PeerIslandsのテストデータジェネレーターとパフォーマンスアナライザーは、コレクション内のフィールドリレーションをサポートしています。コレクション間の関係はサポートしていません。 製品エディション + このパターンは 「[MongoDB アトラス](https://www.mongodb.com/atlas)」と「[MongoDB エンタープライズアドバンスド](https://www.mongodb.com/products/mongodb-enterprise-advanced)」の両方をサポートします。 ## アーキテクチャ **ターゲットテクノロジースタック** + MongoDB アトラスまたは MongoDB エンタープライズアドバンス アーキテクチャ ![\[SQL Server データベースを AWS の MongoDB Atlas に移行するためのクエリパフォーマンスを評価するアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/25f0ab73-d587-4bd0-9fc0-ac675d5aa349/images/717caae4-d52e-4c78-bb7d-2ecb5acccd42.png) PeerIslandsのテストデータジェネレーターとパフォーマンスアナライザーは、JavaとAngularを使用して構築され、生成されたデータをAmazon Elastic Block Store (Amazon EBS) に保存します。このツールは、テストデータ生成とパフォーマンステストの 2 つのワークフローで構成されています。 + テストデータ生成では、生成する必要のあるデータモデルを JSON で表現したテンプレートを作成します。テンプレートを作成したら、負荷生成設定の定義に従ってターゲットコレクションにデータを生成できます。 + パフォーマンステストでは、プロファイルを作成します。プロファイルは、作成、読み取り、更新、削除 (CRUD) 操作、集約パイプライン、各操作の加重、各段階の所要時間を設定できる多段階のテストシナリオです。プロファイルを作成したら、構成に基づいてターゲットデータベースでパフォーマンステストを実行できます。 PeerIslandsのテストデータジェネレーターとパフォーマンスアナライザーは、データをAmazon EBSに保存するため、ピアリング、許可リスト、プライベートエンドポイントなど、MongoDBがサポートする接続メカニズムを使用してAmazon EBSをMongoDBに接続できます。デフォルトでは、このツールには運用コンポーネントは含まれていません。ただし、必要に応じて Amazon マネージドサービス for Prometheus、Amazon Managed Grafana、Amazon CloudWatch、および AWS Secrets Manager を使用して設定できます。 ## ツール + 「[PeerIslands テストデータジェネレーターとパフォーマンスアナライザー](https://tools.peerislands.io/)」には 2 つのコンポーネントが含まれています。Test Data Generator コンポーネントを使用すると、MongoDB スキーマに基づいて、顧客固有の現実世界のデータを生成できます。このツールは完全にUI主導型で、豊富なデータライブラリを備えているため、MongoDBで数十億のレコードを迅速に生成できます。このツールには、MongoDB スキーマのフィールド間の関係を実装する機能もあります。Performance Analyzer コンポーネントを使用すると、顧客固有のクエリや集計を生成し、MongoDB で現実的なパフォーマンステストを実行できます。Performance Analyzer を使用すると、特定のユースケースに合わせた豊富な負荷プロファイルとパラメーター化されたクエリを使用して MongoDB のパフォーマンスをテストできます。 ## ベストプラクティス 以下のリソースを参照してください。 + 「[MongoDB スキーマ設計のベストプラクティス](https://www.mongodb.com/developer/products/mongodb/mongodb-schema-design-best-practices/)」 (MongoDB 開発者ウェブサイト) + 「[AWS に MongoDB アトラスをデプロイする際のベストプラクティス](https://www.mongodb.com/presentation/best-practices-of-deploying-mongodb-atlas-on-aws)」 (MongoDB ウェブサイト) + 「[AWS PrivateLink を使用して MongoDB Atlas データプレーンにアプリケーションを安全に接続する](https://aws.amazon.com/blogs/apn/connecting-applications-securely-to-a-mongodb-atlas-data-plane-with-aws-privatelink/)」 (AWS ブログ記事) + 「[MongoDB パフォーマンスのベストプラクティスガイド](https://www.mongodb.com/basics/best-practices)」 (MongoDB ウェブサイト) ## エピック ### ソースデータを理解する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 現在の SQL Server ソースのデータベースフットプリントを理解します。 | 現在の SQL Server フットプリントを把握します。これは、データベースの `INFORMATION` スキーマに対してクエリを実行することで実現できます。テーブルの数と各テーブルのサイズを決定します。各テーブルに関連付けられているインデックスを分析します。SQL 分析の詳細については、PeerIslands ウェブサイトの「[SQL2Mongo: データ移行の道のり](https://engineering.peerislands.io/sql2mongo-data-migration-journey-fec91a421d60)」というブログ記事を参照してください。 | DBA | | ソーススキーマを理解します。 | テーブルスキーマとデータのビジネス表現 (郵便番号、名前、通貨など) を決定します。既存のエンティティ関係 (ER) 図を使用するか、既存のデータベースから ER 図を生成します。詳細については、PeerIslandsウェブサイトのブログ記事「[SQL2Mongo: データ移行の道のり](https://engineering.peerislands.io/sql2mongo-data-migration-journey-fec91a421d60)」を参照してください。 | DBA | | クエリパターンを理解します。 | 使用する SQL クエリのトップ 10 を文書化します。データベースにある **performance\$1schema.events\$1statements\$1summary\$1by\$1digest** テーブルを使用すると、上位のクエリを理解できます。詳細については、PeerIslandsウェブサイトのブログ記事「[SQL2Mongo: データ移行の道のり](https://engineering.peerislands.io/sql2mongo-data-migration-journey-fec91a421d60)」を参照してください。 | DBA | | SLA のコミットメントを理解します。 | データベース運用のターゲットサービスレベルアグリーメント (SLA) を文書化します。一般的な測定値には、クエリの待ち時間や 1 秒あたりのクエリ数などがあります。測定値とその目標は通常、非機能要件 (NFR) 文書に記載されています。 | DBA | ### MongoDB スキーマを定義する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターゲットスキーマを定義します。 | ターゲット MongoDB スキーマのさまざまなオプションを定義します。詳細については、MongoDB のドキュメントの「[Schemas](https://www.mongodb.com/docs/atlas/app-services/schemas/)」を参照してください。テーブルリレーションに基づいたベストプラクティスとデザインパターンを検討します。 | MongoDB エンジニア | | ターゲットクエリパターンを定義します。 | MongoDB クエリとアグリゲーションパイプラインを定義します。これらのクエリは、SQL Server ワークロードについてキャプチャした上位クエリと同等です。MongoDB アグリゲーションパイプラインを構築する方法を理解するには、「[MongoDB のドキュメント](https://www.mongodb.com/docs/manual/core/aggregation-pipeline/)」を参照してください。 | MongoDB エンジニア | | MongoDB インスタンスタイプを定義します。 | テストに使用するインスタンスのサイズを決定します。詳細については、「[MongoDB のドキュメント](https://www.mongodb.com/docs/atlas/sizing-tier-selection/)」を参照してください。 | MongoDB エンジニア | ### ターゲットデータベースの準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MongoDB アトラスクラスターをセットアップします。 | AWS で MongoDB クラスターをセットアップするには、「[MongoDB ドキュメント](https://www.mongodb.com/docs/atlas/tutorial/create-new-cluster/)」の指示に従ってください。 | MongoDB エンジニア | | ターゲットデータベースにユーザーを作成します。 | 「[MongoDB ドキュメント](https://www.mongodb.com/docs/atlas/connect-to-database-deployment/)」の指示に従って、MongoDB Atlas クラスターにアクセスとネットワークセキュリティを設定します。 | MongoDB エンジニア | | AWS で適切なロールを作成し、Atlasのロールベースのアクセス制御を設定します。 | 必要に応じて、「[MongoDB](https://www.mongodb.com/docs/atlas/security/set-up-unified-aws-access/)」ドキュメントの指示に従って追加のユーザーを設定します。AWS のロールを使って[認証と認可](https://www.mongodb.com/docs/atlas/security/config-db-auth/)を設定します。 | MongoDB エンジニア | | MongoDB アトラスアクセス用のコンパスを設定します。 | ナビゲーションとアクセスを容易にするため、「[MongoDB Compass GUI ユーティリティ](https://www.mongodb.com/products/compass)」を設定します。 | MongoDB エンジニア | ### テストデータジェネレーターを使用してベースロードを設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストデータジェネレーターをインストールします。 | 「[PeerIsland テストデータジェネレーター](https://github.com/PeerIslands/loadgen_binary)」をご使用の環境にインストールします。 | MongoDB エンジニア | | 適切なデータを生成するようにテストデータジェネレーターを設定します。 | データライブラリを使用してテンプレートを作成し、MongoDB スキーマの各フィールドに固有のデータを生成します。詳細については、「[MongoDB データジェネレーターとパフォーマンス」 を参照してください。「アナライザー](https://vimeo.com/570068857)」ビデオ。 | MongoDB エンジニア | | テストデータジェネレーターを水平方向にスケールする必要な負荷を生成します。 | 作成したテンプレートを使用して、必要な並列処理を設定して、ターゲットコレクションに対する負荷生成を開始します。必要なデータを生成するための時間枠とスケールを決定します。 | MongoDB エンジニア | | MongoDB アトラスでロードを検証します。 | MongoDB アトラスに読み込まれたデータを確認します。 | MongoDB エンジニア | | MongoDB で必要なインデックスを生成します。 | クエリパターンに基づいて、必要に応じてインデックスを定義します。詳細については、「[MongoDB のドキュメント](https://www.mongodb.com/docs/manual/applications/indexes/)」を参照してください。 | MongoDB エンジニア | ### パフォーマンステストを実施します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パフォーマンス・アナライザーでロード・プロファイルを設定します。 | Performance Analyzer でパフォーマンステストプロファイルを作成するには、特定のクエリとそれに対応する加重、テスト実行時間、ステージを設定します。詳細については、「[MongoDB データジェネレーターとパフォーマンス」を参照してください。「アナライザー](https://vimeo.com/570068857)」ビデオ。 | MongoDB エンジニア | | パフォーマンステストを実行します。 | 作成したパフォーマンステストプロファイルを使用して、必要な並列処理を設定して、ターゲットコレクションに対するテストを開始します。パフォーマンステストツールを水平方向にスケールして、MongoDB Atlas に対してクエリを実行します。 | MongoDB エンジニア | | テスト結果を記録します。 | クエリの P95、P99 のレイテンシーを記録します。 | MongoDB エンジニア | | スキーマとクエリパターンを調整します。 | インデックスとクエリパターンを変更して、パフォーマンスの問題に対処します。 | MongoDB エンジニア | ### プロジェクトを閉じる | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 一時的な AWS リソースをシャットダウンします。 | テストデータジェネレーターとパフォーマンスアナライザーに使用した一時リソースをすべて削除します。 | AWS 管理者 | | パフォーマンステストの結果を更新します。 | MongoDB クエリのパフォーマンスを理解し、それを SLA と比較します。必要に応じて、MongoDB スキーマを微調整し、プロセスを再実行します。 | MongoDB エンジニア | | プロジェクトを完了します。 | プロジェクトを終了し、フィードバックを提供します。 | MongoDB エンジニア | ## 関連リソース + GitHub リポジトリ:「[S3 からアトラス](https://github.com/mongodb-partners/S3toAtlas)」 + スキーマ:「[MongoDB](https://www.mongodb.com/developer/products/mongodb/mongodb-schema-design-best-practices/)」スキーマのデザイン + アグリゲーションパイプライン:「[MongoDB](https://www.mongodb.com/docs/manual/core/aggregation-pipeline/)」アグリゲーションパイプライン + MongoDB アトラスのサイジング:「[サイジング層の選択](https://www.mongodb.com/docs/atlas/sizing-tier-selection/)」 + ビデオ:「[MongoDB データジェネレーター](https://vimeo.com/570068857)」とパフォーマンス analyzer + リファレンス:「[MongoDB ドキュメンテーション](https://www.mongodb.com/docs/)」 + チュートリアル:****「[MongoDB developer guide](https://www.mongodb.com/docs/develop-applications/)」、「[MongoDB Jumpstart](https://www.youtube.com/playlist?list=PL4RCxklHWZ9v2lcat4oEVGQhZg6r4IQGV)」 + AWS Marketplace: ****「[MongoDB Atlas on AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=c9032c7b-70dd-459f-834f-c1e23cf3d092)」 + AWS パートナーソリューション:「****[MongoDB Atlas on AWS Reference Deployment](https://aws.amazon.com/quickstart/architecture/mongodb-atlas/)」 その他のリソース: + 「[SQL 分析](https://engineering.peerislands.io/sql2mongo-data-migration-journey-fec91a421d60)」 + 「[MongoDB デベロッパーコミュニティフォーラム](https://www.mongodb.com/community/forums/)」 + 「[MongoDB パフォーマンスチューニングに関する質問](https://www.mongodb.com/developer/products/mongodb/performance-tuning-tips/)」 + 「[アトラスとRedshift によるオペレーショナル分析](https://github.com/mongodb-partners/Atlas_to_Redshift)」 + 「[MongoDB アトラスと AWS Elastic Beanstalk によるアプリケーションのモダナイゼーション](https://github.com/mongodb-partners/MEANStack_with_Atlas_on_AWS_EB)」 # IaC 原則を使用して Amazon Aurora Global Database のブルー/グリーンデプロイを自動化する *Amazon Web Services、Ishwar Chauthaiwale、ANKIT JAIN、Ramu Jagini* ## 概要 [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) で重要なワークロードを実行する組織では、データベースの更新、移行、スケーリング作業の管理が課題となる場合があります。確実にこれらのオペレーションをダウンタイムなしでシームレスに実行することは、サービスの可用性を維持し、ユーザーの中断を回避する上で不可欠です。 ブルー/グリーンデプロイ戦略は、ブルー (現在の環境) とグリーン (新しい環境) の 2 つの同一の環境を同時に実行できるようにすることで、この課題に対するソリューションを提供します。ブルー/グリーン戦略を使用することで、リスクとダウンタイムを最小限に抑えながら、変更の実装、テストの実行、環境間のトラフィックの切り替えを行うことができます。 このパターンは、Infrastructure as Code (IaC) の原則を使用して、Aurora Global Detabase のブルー/グリーンデプロイプロセスを自動化するのに役立ちます。[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)、[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、および [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) を使用して、ブルー/グリーンデプロイを簡素化します。信頼性を向上させるために、レプリケーションにグローバルトランザクション識別子 (GTID) を使用します。GTID ベースのレプリケーションは、バイナリログ (binlog) レプリケーションと比較して、環境間のデータ整合性とフェイルオーバー機能が向上します。 **注記** このパターンは、Aurora MySQL 互換エディションの Global Database クラスターを使用していることを前提としています。代わりに Aurora PostgreSQL 互換を使用している場合は、MySQL コマンドに相当する PostgreSQL を使用してください。 本パターンの手順に従うことで、以下の操作が可能です。 + グリーン Aurora Global Database をプロビジョニングする: CloudFormation テンプレートを使用して、既存のブルー環境をミラーリングするグリーン環境を作成します。 + GTID ベースのレプリケーションを設定する: ブルー環境とグリーン環境が同期された状態を維持するように GTID レプリケーションを設定します。 + トラフィックをシームレスに切り替える: Route 53 と Lambda を使用して、完全同期後にブルー環境からグリーン環境にトラフィックを自動的に切り替えます。 + デプロイを確定する: グリーン環境がプライマリデータベースとして完全に動作していることを検証してから、レプリケーションを停止して一時的なリソースをクリーンアップします。 このパターンのアプローチには、次の利点があります。 + 重要なデータベースの更新または移行中のダウンタイムが短縮される: 自動化により確実に、サービスの中断を最小限に抑えながら、環境間のスムーズな移行を行います。 + 迅速なロールバックが可能になる: トラフィックがグリーン環境に切り替わった後に問題が発生した場合は、ブルー環境にすばやく戻り、サービスの継続性を維持できます。 + テストと検証が強化される: グリーン環境は、ライブのブルー環境に影響を与えずに完全にテストできるため、本番環境でエラーが発生する可能性が低くなります。 + データ整合性が確保される: GTID ベースのレプリケーションがブルー環境とグリーン環境の同期を維持し、移行中のデータ損失や不整合を防ぎます。 + ビジネス継続性が維持される: ブルー/グリーンデプロイを自動化すると、更新や移行中にサービスを使用できる状態が維持されることで、長時間の停止や財務上の損失を回避できます。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + ソース Aurora MySQL 互換 Global Database クラスター (ブルー環境)。Global Database は、高可用性とディザスタリカバリを実現するマルチリージョン設定を提供します。Global Database クラスターを設定する手順については、[Aurora ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)を参照してください。 + ソースクラスターで有効な [GTID ベースのレプリケーション](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-replication-gtid.html)。 **制限事項** + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページから、サービスのリンクを選択してご確認ください。 **製品バージョン** + Aurora MySQL 互換 8.0 以降 ## アーキテクチャ ![\[GTID レプリケーションを使用した異なるリージョンのブルー環境とグリーン環境の同期。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/19922266-c2e5-460b-9a0f-22e6d6736094/images/7a8c3095-7904-4080-906f-0c403c289a4f.png) この図表は、以下を示すものです: + グローバルデータベースのセットアップ: Aurora グローバルデータベースクラスターは、2 つのクラスターに戦略的にデプロイされます AWS リージョン。この設定により、地理的分散とリージョンの冗長性が実現し、ディザスタリカバリ機能が強化されます。 + プライマリリージョンからセカンダリリージョンへのレプリケーション: 論理レプリケーションメカニズムにより、プライマリリージョンからセカンダリリージョンへのシームレスなデータ同期が保証されます。このレプリケーションは、地理的距離全体で最小限のレイテンシーでデータ整合性を維持します。 + クラスター間の GTID ベースのレプリケーション: GTID ベースのレプリケーションは、ブループライマリクラスターとグリーンプライマリクラスター間のトランザクションの整合性と順序付けられたデータフローを維持し、信頼性の高いデータ同期を保証します。 + ブループライマリからセカンダリへのレプリケーション: 論理レプリケーションは、ブループライマリクラスターとそのセカンダリクラスター間に堅牢なデータパイプラインを確立します。このレプリケーションにより、継続的なデータ同期と高可用性が実現します。 + Route 53 DNS 設定: Route 53 ホストゾーンレコードは、すべてのブルーおよびグリーンクラスターデータベースエンドポイントの DNS 解決を管理します。この設定は、シームレスなエンドポイントマッピングを提供し、フェイルオーバーシナリオ中の効率的なトラフィックルーティングを可能にします。 ## ツール **AWS サービス** + 「[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)」はクラウド用に構築されたフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、 AWS リソースをモデル化してセットアップできるため、リソースの管理に費やす時間が減り、 が実行されるアプリケーションに集中する時間が増えます AWS。必要なすべての AWS リソースを記述するテンプレートを作成すると、CloudFormation がそれらのリソースのプロビジョニングと設定を処理します。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。  + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 ## ベストプラクティス Route 53 の[ブルー/グリーンデプロイ戦略](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html)、[GTID ベースのレプリケーション](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-replication-gtid.html)、[加重ルーティングポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-weighted.html)の理解を深められるように、 AWS ドキュメントを徹底的に確認することをお勧めします。この知識は、データベース移行の効果的な実装と管理、データ整合性の確保、トラフィックルーティングの最適化に不可欠です。これらの AWS 機能とベストプラクティスを包括的に理解することで、将来の更新を処理し、ダウンタイムを最小限に抑え、回復力のある安全なデータベース環境を維持する準備が整います。 このパターン AWS のサービス に を使用するためのガイドラインについては、次の AWS ドキュメントを参照してください。 + [Amazon Aurora MySQL のベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html) + [CloudFormation  ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html) のベストプラクティス + [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) + [Amazon Route 53 のベストプラクティス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices.html) ## エピック ### グリーン環境を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブルークラスターからスナップショットバックアップを作成します。 | ブルー/グリーンデプロイでは、グリーン環境は現在の (ブルー) データベース環境と同一の新バージョンを表します。グリーン環境を使用して、更新を安全にテストし、変更を検証し、安定性を確保してから、本番環境のトラフィックを切り替えます。これは、ライブ環境の中断を最小限に抑えながらデータベースの変更を実装するためのステージング基盤として機能します。グリーン環境を作成するには、まず Aurora MySQL 互換 Global Database にプライマリ (ブルー) クラスターのスナップショットを作成します。このスナップショットは、グリーン環境を作成するための基盤として機能します。スナップショットを作成するために以下を実行します:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)または、 AWS Command Line Interface (AWS CLI) を使用してスナップショットを作成することもできます。
aws rds create-db-cluster-snapshot --db-cluster-snapshot-identifier blue-green-demo --db-cluster-identifier ex-global-cluster --region eu-west-1
スナップショットが正常に完了したことを確認してから、次のステップに進みます。 | DBA | | グローバルデータベースとそのリソースの CloudFormation テンプレートを生成します。 | CloudFormation IaC ジェネレーターは、既存の AWS リソースから CloudFormation テンプレートを生成するのに役立ちます。この機能を使用して、既存の Aurora MySQL 互換グローバルデータベースとその関連リソースの CloudFormation テンプレートを作成します。このテンプレートは、サブネットグループ、セキュリティグループ、パラメータグループ、およびその他の設定を構成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html) | DBA | | グリーン環境の CloudFormation テンプレートを変更します。 | グリーン環境の設定を反映するように CloudFormation テンプレートをカスタマイズします。これには、グリーン環境がブルークラスターとは独立して動作するようにリソース名と識別子を更新することが含まれます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)`SnapshotIdentifier` プロパティを使用して DB クラスターを復元する場合は、`GlobalClusterIdentifier`、`MasterUsername`、`MasterUserPassword` などのプロパティを指定しないでください。 | DBA | | CloudFormation スタックをデプロイして、グリーン環境のリソースを作成します。 | このステップでは、カスタマイズされた CloudFormation テンプレートをデプロイして、グリーン環境のリソースを作成します。CloudFormation スタックをデプロイするために以下を実行します:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)CloudFormation で、グリーン環境リソースを作成するプロセスが開始されます。このプロセスは完了までに数分かかることがあります。 | DBA | | CloudFormation のスタックとリソースを検証します。 | CloudFormation スタックのデプロイが完了したら、グリーン環境が正常に作成されたことを確認する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)検証後、ブルー環境からのレプリケーションなど、グリーン環境の設定を進める準備が整います。 | DBA | ### GTID ベースレプリケーションを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ブルークラスターの GTID 設定を確認します。 | GTID は、ブルー環境とグリーン環境間でデータをレプリケートするための信頼性の高い方法を提供します。[GTID ベースのレプリケーション](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-replication-gtid.html)は、ブルー環境内のすべてのトランザクションに一意の識別子を割り当てることで、回復力の高い簡素化されたアプローチを提供します。この方法により、環境間のデータ同期がシームレスで一貫性があり、従来のバイナリログレプリケーションよりも容易に管理できるものになります。レプリケーションを設定する前に、ブルークラスターで確実に GTID ベースのレプリケーションが適切に有効になっているようにする必要があります。このステップにより、ブルー環境の各トランザクションが一意に追跡され、グリーン環境でレプリケートできることが保証されます。GTID が有効であることを確認するため以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)これらの設定により、ブルー環境での今後のすべてのトランザクションの GTID 追跡が有効になります。これらの設定の確認後に、レプリケーションの設定を開始できます。 | DBA | | レプリケーションユーザーを作成します。 | ブルー環境からグリーン環境にデータをレプリケートするには、ブルークラスターに専用のレプリケーションユーザーを作成する必要があります。このユーザーは、レプリケーションプロセスの管理を担当します。レプリケーションユーザーを設定するため以下を実行します:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)このユーザーは、2 つの環境間でデータをレプリケートするために必要なアクセス許可を持つようになりました。 | DBA | | グリーンクラスターで GTID ベースのレプリケーションを設定します。 | 次のステップでは、GTID ベースのレプリケーション用にグリーンクラスターを設定します。この設定により、グリーン環境は確実に、ブルー環境で発生するすべてのトランザクションを継続的にミラーリングするようになります。グリーンクラスターを設定するため以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html) | DBA | | グリーンクラスターでレプリケーションを開始します。 | これで、レプリケーションプロセスを開始できます。グリーンクラスターで、次のコマンドを実行します。
START SLAVE;
これで、グリーン環境はデータの同期と、ブルー環境からのトランザクションの受信と適用を開始できるようになります。 | DBA | | レプリケーションプロセスを検証します。 | グリーン環境がブルークラスターからデータを正確にレプリケートしていることを検証するため以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)すべてのインジケータが正しい場合、GTID ベースのレプリケーションはスムーズに機能し、グリーン環境はブルー環境と完全に同期されています。 | DBA | ### トラフィックをブルーからグリーンクラスターに切り替えます。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Route 53 加重ルーティングポリシーを設定します。 | ブルー環境とグリーン環境間のデータ整合性を検証したら、ブルークラスターからグリーンクラスターへトラフィックを切り替えることができます。この移行はスムーズである必要があります。また、ダウンタイムを最小限に抑え、アプリケーションのデータベースの整合性を確保する必要もあります。これらの要件を満たすため、DNS ルーティングに Route 53 を使用し、Lambda を使用してトラフィックの切り替えを自動化します。さらに、明確に定義されたロールバックプランにより、問題が発生した場合にブルークラスターに戻すことができるようにします。最初のステップは、Route 53 で加重ルーティングを設定することです。加重ルーティングを使用すると、ブルークラスターとグリーンクラスター間のトラフィックの分散を制御し、ある環境から別の環境にトラフィックを徐々に移行できます。加重ルーティングを設定するために以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)加重ルーティングポリシーの詳細については、[Route 53 ドキュメント](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-weighted.html)を参照してください。 | AWS DevOps | | Lambda 関数をデプロイして、レプリケーションラグをモニタリングします。 | グリーン環境がブルー環境と完全に同期されるようにするため、クラスター間のレプリケーションラグをモニタリングする Lambda 関数をデプロイします。この関数で、レプリケーションステータス、特に **Seconds\$1Behind\$1Master** メトリクスをチェックして、グリーンクラスターがすべてのトラフィックを処理する準備ができているかどうかを判断できます。使用できる Lambda 関数の例を次に示します。
import boto3

def check_replication_lag(event, context):
    client = boto3.client('rds')
    response = client.describe_db_instances(DBInstanceIdentifier='green-cluster-instance')
    replication_status = response['DBInstances'][0]['ReadReplicaDBInstanceIdentifiers']
    if replication_status:
        lag = replication_status[0]['ReplicationLag']
        return lag
    return -1
この関数はレプリケーションのラグをチェックし、値を返します。ラグがゼロの場合、グリーンクラスターはブルークラスターと完全に同期しています。 | AWS DevOps | | Lambda を使用して DNS の重み調整を自動化します。 | レプリケーションのラグがゼロになったら、いよいよすべてのトラフィックをグリーンクラスターに切り替えます。この移行を自動化するには、トラフィックの 100% をグリーンクラスターに送信するように Route 53 の DNS 重みを調整する別の Lambda 関数を使用します。トラフィックの切り替えを自動化する Lambda 関数の例を次に示します。
import boto3

def switch_traffic(event, context):
    route53 = boto3.client('route53')
    lag = check_replication_lag(event, context)
    if lag == 0:
        response = route53.change_resource_record_sets(
            HostedZoneId='YOUR_HOSTED_ZONE_ID',
            ChangeBatch={
                'Changes': [
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': 'db.example.com',
                            'Type': 'CNAME',
                            'SetIdentifier': 'GreenCluster',
                            'Weight': 100,
                            'TTL': 60,
                            'ResourceRecords': [{'Value': 'green-cluster-endpoint'}]
                        }
                    },
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': 'db.example.com',
                            'Type': 'CNAME',
                            'SetIdentifier': 'BlueCluster',
                            'Weight': 0,
                            'TTL': 60,
                            'ResourceRecords': [{'Value': 'blue-cluster-endpoint'}]
                        }
                    }
                ]
            }
        )
        return response
この関数はレプリケーションラグをチェックし、ラグがゼロのときに Route 53 DNS の重みを更新して、トラフィックを完全にグリーンクラスターに切り替えます。** **カットオーバープロセス中にブルークラスターで大量の書き込みトラフィックが発生した場合は、カットオーバー中の書き込みオペレーションを一時的に停止することを検討してください。これにより、レプリケーションが追いつき、ブルークラスターとグリーンクラスター間のデータの不整合を防ぐことができるようになります。 | AWS DevOps | | トラフィックの切り替えを検証します。 | Lambda 関数が DNS の重みを調整した後、すべてのトラフィックがグリーンクラスターに転送され、切り替えが成功したことを確認する必要があります。検証するために以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)すべてが期待どおりに動作していたら、トラフィックの切り替えは完了です。 | AWS DevOps | | 問題が発生した場合は、変更をロールバックします。 | トラフィックの切り替え後に問題が発生した場合に備えて、ロールバック計画を立てることが不可欠です。必要に応じてブルークラスターにすばやく戻る方法は、次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)このロールバック計画を実装することで、予期しない問題が発生した場合にユーザーの中断を最小限に抑えることができます。 | AWS DevOps | ### GTID ベースのレプリケーションを検証して停止する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | グリーンクラスターで GTID ベースのレプリケーションを停止します。 | ブルー環境からグリーン環境にトラフィックを切り替えたら、移行の成功を検証し、グリーンクラスターが期待どおりに機能していることを確認する必要があります。さらに、グリーン環境がプライマリデータベースとして機能するようになったため、ブルークラスターとグリーンクラスター間の GTID ベースのレプリケーションを停止する必要もあります。これらのタスクを完了することで、環境が安全で、合理化された、継続的な運用向けに最適化されたものになります。レプリケーションを停止するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)レプリケーションを停止すると、グリーンクラスターは完全に独立した状態になり、ワークロードのプライマリデータベース環境として機能します。 | DBA | | リソースをクリーンアップします。 | ブルークラスターからグリーンクラスターへの移行中に作成された一時的または未使用のリソースをクリーンアップすることで、環境は最適化された、安全な、コスト効率の高い状態を維持できます。クリーンアップには、セキュリティ設定の調整、最終バックアップの取得、不要なリソースの廃止などが含まれます。リソースをクリーンアップするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/p-automate-blue-green-deployments-aurora-global-databases-iac.html)リソースをクリーンアップすることで、安全で合理化された環境を維持し、コストを削減し、必要なインフラストラクチャだけが残るようにします。 | AWS DevOps | ## 関連リソース CloudFormation: + [CloudFormation ユーザーガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) + [CloudFormation  ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html) のベストプラクティス + [IaC ジェネレーターを使用して既存のリソースからテンプレートを生成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/generate-IaC.html) + [アプリケーション全体を にインポート CloudFormation](https://aws.amazon.com/blogs/devops/import-entire-applications-into-aws-cloudformation/)する (AWS ブログ記事) Amazon Aurora: + [Amazon Aurora ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Welcome.html) + [Amazon Aurora DB クラスターの管理](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Aurora.html) ブルー/グリーンデプロイ戦略: + [Overview of Amazon Aurora Blue/Green Deployments](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html) GTID ベースのレプリケーション: + [GTID ベースレプリケーションを使用する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-replication-gtid.html) (Amazon RDS ドキュメント) AWS Lambda: + [AWS Lambda デベロッパーガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) Amazon Route 53: + [Amazon Route 53 デベロッパーガイド](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + [加重ルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-weighted.html) MySQL クライアントツール: + [PyMYSQL](https://github.com/PyMySQL/PyMySQL) # 間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント *Parag Nagwekar、Arun Chandapillai (Amazon Web Services)* ## 概要 このパターンは、 AWS Step Functions と を使用して、異なる 間で Amazon Relational Database Service (Amazon RDS) DB インスタンスをレプリケート、追跡、ロールバック AWS アカウント するプロセスを自動化する方法を示しています AWS Lambda。この自動化を利用すると、組織の規模に関係なく、パフォーマンスへの影響や運用上のオーバーヘッドなしに RDS DB インスタンスの大規模なレプリケーションを実行できます。また、このパターンを使用して、組織が必須のデータガバナンス戦略やコンプライアンス要件に準拠し、さまざまな AWS アカウント と 間でデータをレプリケートして冗長化することもできます AWS リージョン。Amazon RDS データの大規模なクロスアカウントレプリケーションは、非効率的でエラーが発生しやすい手動プロセスであり、コストも時間もかかりますが、このパターンの自動化は、クロスアカウントレプリケーションを安全、効果的、効率的に実現するのに役立ちます。 ## 前提条件と制限 **前提条件** + 2 つ AWS アカウント + ソースで稼働している RDS DB インスタンス AWS アカウント + 送信先の RDS DB インスタンスのサブネットグループ AWS アカウント + ソースで作成 AWS アカウント され、送信先アカウントと共有される AWS Key Management Service (AWS KMS) キー (ポリシーの詳細については、このパターンの[追加情報](#automate-the-replication-of-amazon-rds-instances-across-aws-accounts-additional)セクションを参照してください）。 + AWS KMS key 送信先アカウントのデータベースを暗号化 AWS アカウント する送信先の 。 **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページから、サービスのリンクを選択してご確認ください。 **製品バージョン** + Python 3.9 (使用 AWS Lambda) + PostgreSQL 11.3、13.x、14.x ## アーキテクチャ **テクノロジースタック** + Amazon Relational Database Service (Amazon RDS) + Amazon Simple Notification Service (Amazon SNS) + AWS Key Management Service (AWS KMS) + AWS Lambda + AWS Secrets Manager + AWS Step Functions **ターゲットアーキテクチャ** 次の図は、Step Functions を使用して、ソースアカウント (アカウント A) からターゲットアカウント (アカウント B) への RDS DB インスタンスのスケジュールされたオンデマンドレプリケーションを調整するためのアーキテクチャを示しています。 ![\[Step Functions を使用し、レプリケート元アカウントとレプリケート先アカウント間で Amazon RDS DB インスタンスをレプリケートします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6310ad9b-1b1a-4a67-b684-ef605fef3e87/images/001550bb-cf6b-493d-9de9-0229a43753a1.png) ソースアカウント (図のアカウント A) では、Step Functions ステートマシンが以下を実行します。 1. アカウント A の RDS DB インスタンスからスナップショットを作成します。 1. アカウント A AWS KMS key から を使用してスナップショットをコピーして暗号化します。転送中の暗号化を確保するために、DB インスタンスが暗号化されているかどうかにかかわらず、スナップショットは暗号化されます。 1. アカウント B にスナップショットへのアクセス権を付与することで、アカウント B と DB スナップショットを共有します。 1. SNS トピックに通知をプッシュし、SNS トピックがアカウント B の Lambda 関数を呼び出します。 宛先アカウント (図のアカウント B) では、Lambda 関数が Step Functions ステートマシンを実行して以下を調整します。 1. 共有スナップショットをアカウント A からアカウント B にコピーし、アカウント A AWS KMS key から を使用して最初にデータを復号してから、アカウント B AWS KMS key の を使用してデータを暗号化します。 1. Secrets Manager からシークレットを読み取り、現在の DB インスタンスの名前を取得します。 1. AWS KMS key Amazon RDS の新しい名前とデフォルトを使用して、スナップショットから DB インスタンスを復元します。 1. 新しいデータベースのエンドポイントを読み取り、Secrets Manager のシークレットを新しいデータベースエンドポイントで更新します。次に、以前の DB インスタンスにタグを付けて後で削除できるようにします。 1. データベースの最新の N 個のインスタンスを保持し、他のすべてのインスタンスを削除します。 ## ツール **AWS のサービス** + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベースをセットアップ、運用、スケーリングできます。 + [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。 + [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。 + [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、Lambda 関数とその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[Crossaccount RDS Replication](https://github.com/aws-samples/aws-rds-crossaccount-replication)」リポジトリで利用できます。 ## エピック ### ワンクリック AWS アカウント で 全体の RDS DB インスタンスのレプリケーションを自動化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation スタックをソースアカウントにデプロイする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-replication-of-amazon-rds-instances-across-aws-accounts.html) | クラウド管理者、クラウドアーキテクト | | CloudFormation スタックをデスティネーションアカウントにデプロイする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-replication-of-amazon-rds-instances-across-aws-accounts.html) | クラウドアーキテクト、DevOps エンジニア、クラウド管理者 | | 宛先アカウントで RDS DB インスタンスが作成されたことを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-replication-of-amazon-rds-instances-across-aws-accounts.html) | クラウド管理者、クラウドアーキテクト、DevOps エンジニア | | Lambda 関数を SNS トピックにサブスクライブする。 | 送信先アカウント AWS Command Line Interface (アカウント B AWS CLI) の Lambda 関数をソースアカウント (アカウント A) の SNS トピックにサブスクライブするには、次の () コマンドを実行する必要があります。アカウント A で、次のコマンドを実行します。
aws sns add-permission \
--label lambda-access --aws-account-id  \
--topic-arn  \
--action-name Subscribe ListSubscriptionsByTopic
アカウント B で、次のコマンドを実行します。
aws lambda add-permission \
--function-name  \
--source-arn  \
--statement-id function-with-sns \
--action lambda:InvokeFunction \
--principal sns.amazonaws.com
アカウント B で、次のコマンドを実行します。
aws sns subscribe \
--protocol "lambda" \
--topic-arn  \
--notification-endpoint
| クラウド管理者、クラウドアーキテクト、DBA | | ソースアカウントの RDS DB インスタンスを宛先アカウントと同期する。 | ソースアカウントで Step Functions ステートマシンを起動して、オンデマンドデータベースレプリケーションを開始します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-replication-of-amazon-rds-instances-across-aws-accounts.html)スケジュールに従って自動的にレプリケーションを実行できるようにスケジューラは用意されていますが、スケジューラはデフォルトではオフになっています。スケジューラーの Amazon CloudWatch ルールの名前は、宛先アカウントの CloudFormation スタックの **[リソース]** タブにあります。CloudWatch イベントルールを変更する方法については、CloudWatch ドキュメントの「[Deleting or Disabling a CloudWatch Events Rule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Delete-or-Disable-Rule.html)」を参照してください。 | クラウドアーキテクト、DevOps エンジニア、クラウド管理者 | | 必要に応じて、データベースを以前のコピーのいずれかにロールバックする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-replication-of-amazon-rds-instances-across-aws-accounts.html) | クラウド管理者、DBA、DevOps エンジニア | ## 関連リソース + [クロスリージョンリードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.CrossRegionReadReplicas.html) (Amazon RDS ドキュメント) + [ブルー/グリーンデプロイ (](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.html)Amazon RDS ドキュメント) ## 追加情報 次のポリシー例を使用して、 AWS KMS key を共有できます AWS アカウント。 ``` { "Version": "2012-10-17", "Id": "cross-account-rds-kms-key", "Statement": [ { "Sid": "Enable user permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow administration of the key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::root" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::root", "arn:aws:iam:::root" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey", "kms:CreateGrant" ], "Resource": "*" } ] } ``` # AWS Lambda および Task Scheduler を使用して、Amazon EC2 で実行されている SQL Server Express エディションのデータベースタスクを自動化する *Subhani Shaik (Amazon Web Services)* ## 概要 このパターンでは、SQL Server Express Edition (SQL Server の無料バージョン) でデータベースタスクをスケジュールし管理する方法について紹介します。ただし、SQL Server Express Edition には、自動化されたデータベースオペレーションを処理する SQL Server エージェントサービスは付いていません。このパターンでは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されている SQL Server Express Edition でデータベースタスクを自動化する代わりに、Task Scheduler と Lambda を使用する方法について説明します。 [Task Scheduler](https://learn.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-start-page) は、ルーチンタスクの自動実行を容易にする組み込みの Windows システムユーティリティです。自動化されたオペレーションをスケジュールし管理するための仕組みを提供して、反復的なプロセスに手動で介入する必要性をなくします。[AWS Lambda](https://aws.amazon.com/lambda/) は、イベントに応じてコードを自動で実行するサーバーレスコンピューティングサービスで、基盤となるインフラストラクチャの管理は不要です。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Amazon Virtual Private Cloud (Amazon VPC) を使って作成された仮想プライベートクラウド (VPC) + Windows Server の Amazon EC2 インスタンス + Windows Server の Amazon EC2 インスタンスにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリューム + [SQL Server Express Edition](https://www.microsoft.com/en-us/download/details.aspx?id=101064) バイナリ **制限事項** + SQL Server Express Edition の機能の制限については、[Microsoft のウェブサイト](https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2019?view=sql-server-ver16)を参照してください。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 **製品バージョン** + SQL Server Express Edition を使用できる SQL Server 2016 以降 ## アーキテクチャ 次の図は、SQL Server Express Edition をインストールした状態で実行されている Amazon EC2 インスタンスを示したものです。インスタンスには、リモートデスクトッププロトコル (RDP) クライアントまたは からアクセスできます AWS Systems Manager Session Manager。 AWS Key Management Service (AWS KMS) は Amazon EBS ボリュームのデータ暗号化を処理して、data-at-restセキュリティを確保します。インフラストラクチャには、Lambda 関数の実行のためのアクセスコントロールを提供し、アクセス許可を管理する AWS Identity and Access Management (IAM) も含まれています。Lambda 関数は Amazon Simple Storage Service (Amazon S3) に保管されています。 ![\[プライベートサブネットにインストールされた SQL Server Express Edition を使って実行されている Amazon EC2 インスタンス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3af2174d-bf49-4e43-86f7-34759e5eea84/images/3a37dcb8-10af-42f2-8ff1-fab4f87eb646.png) ## ツール **AWS のサービス** + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html) は、Amazon EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、任意の量のデータを保存、保護、取得する上で役立つクラウドベースのオブジェクトストレージサービスです。 + [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) はフルマネージド AWS Systems Manager 型のツールです。Session Manager を使用することで、Amazon EC2 インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシン (VM) を管理できます。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 **その他のツール** + [Microsoft SQL Server Management Studio (SSMS)](https://learn.microsoft.com/en-us/ssms/download-sql-server-management-studio-ssms) は、SQL Server コンポーネントへのアクセス、設定、管理など、SQL Server を管理するためのツールです。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。こちらを使用すると、[AWS クラウド](https://aws.amazon.com/developer/language/python/) でのアプリケーションの構築、タスクの自動化、サービスの開発を行うことができます。 + [Task Scheduler](https://learn.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-start-page) は、コンピュータでルーチンタスクを自動的にスケジュールするできる Microsoft のツールです。 ## ベストプラクティス + [Amazon EC2 のベストプラクティス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html) + [Amazon EC2 に Microsoft SQL Server をデプロイするためのベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-ec2-best-practices/welcome.html) + [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) + [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) ## エピック ### Amazon EC2 インスタンスを作成し、SQL Server Express Edition をインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EC2 インスタンスをデプロイします。 | Amazon EC2 インスタンスを作成するには、Amazon EC2 コンソールを開き ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/))、Windows Server で使用できるインスタンスのリストから [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html) を選択します。詳細については、 AWS ドキュメント[のAmazon EC2 インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)」を参照してください。 | DBA、AWS DevOps | | SQL Server Express Edition をインストールする | SQL Server Express Edition をインストールするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html) | DBA、AWS DevOps | ### 自動化されたデータベースメンテナンスタスクを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ルーチンタスクを特定する。 | 自動化したいルーチンタスクを特定します。例えば、以下のようなタスクは自動化できる可能性があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html) | DBA | | SQL スクリプトを作成する。 | SQL スクリプトを作成するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html) | DBA | | アクセス許可を設定する。 | アクセス許可を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html) | DBA | ### Task Scheduler を使用してタスクを自動化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | バッチファイルを作成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html)
sqlcmd -S servername -U username -P password -i
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html)

@echo off
sqlcmd -S [ServerName] -d [DatabaseName] -U username -P password -i "PathToSQLScript\Script.sql" -o "PathToOutput\Output.txt"
| AWS DevOps, DBA | | Task Scheduler でタスクを作成する。 | Task Scheduler でタスクを作成するには、次のステップに従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html)タスクを手動で実行するには、新たに作成したタスクを右クリックし、**[実行]** を選択します。 | DBA | | タスクのステータスを表示する。 | Task Scheduler でタスクのステータスを表示するには、次のステップに従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html) | DBA、AWS DevOps | ### でタスクを自動化する AWS Lambda | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソリューションを実装する。 | このパターンのソリューションを実装するには、次のステップに従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.html) | AWS DevOps、DevOps エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Lambda の問題 | の使用時に発生する可能性のあるエラーや問題のヘルプについては AWS Lambda、 AWS ドキュメントの[「Lambda での問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/lambda-troubleshooting.html)」を参照してください。 | ## 関連リソース + [Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/) + [AWS Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/with-eventbridge-scheduler.html) + [AWS Lambda 料金](https://aws.amazon.com/lambda/pricing/) + [Task Scheduler for developers](https://learn.microsoft.com/en-us/windows/win32/taskschd/task-scheduler-start-page) (Microsoft ウェブサイト) # DR Orchestrator Framework を使用してクロスリージョンのフェイルオーバーとフェイルバックを自動化 *Amazon Web Services、Jitendra Kumar、Pavithra Balasubramanian、Oliver Francis* ## 概要 本パターンでは、[DR Orchestrator Framework](https://docs.aws.amazon.com/prescriptive-guidance/latest/automate-dr-solution-relational-database/dr-orchestrator-framework-overview.html) を使用して、エラーが発生しやすい手動ステップをオーケストレーションおよび自動化し、Amazon Web Services (AWS) リージョン全体でディザスタリカバリを実行する方法について説明します。本パターンでは以下のデータベースがカバーされています。 + Amazon Relational Database Service (Amazon RDS) for MySQL、Amazon RDS for PostgreSQL、または Amazon RDS for MariaDB + Amazon Aurora MySQL 互換エディションまたは Amazon Aurora PostgreSQL 互換エディション (一元化されたファイルを使用) + Amazon ElastiCache (Redis OSS) DR Orchestrator Framework の機能を実際に使ってみるため、2 つの DB インスタンスまたはクラスターを作成します。プライマリは にあり AWS リージョン `us-east-1`、セカンダリは にあります`us-west-2`。これらのリソースを作成するには、[aws-cross-region-dr-databases](https://github.com/aws-samples/aws-cross-region-dr-databases) GitHub リポジトリの `App-Stack`フォルダにある AWS CloudFormation テンプレートを使用します。 ## 前提条件と制限事項 **一般的な前提条件** + プライマリとセカンダリの両方にデプロイされた DR オーケストレーターフレームワーク AWS リージョン + [Amazon Simple Storage Service](https://aws.amazon.com/s3/) バケット + 2 つのサブネットと AWS セキュリティグループを持つ [Virtual Private Cloud (VPC)](https://aws.amazon.com/vpc/) **エンジンに固有の前提条件** + **Amazon Aurora** – 少なくとも 1 つの Aurora グローバルデータベースを 2 つで利用できる必要があります AWS リージョン。`us-east-1` をプライマリリージョンとして、`us-west-2` をセカンダリリージョンとして使用できます。 + **Amazon ElastiCache (Redis OSS)** – ElastiCache グローバルデータストアは 2 つで利用できる必要があります AWS リージョン。`use us-east-1` をプライマリリージョンとして、`us-west-2` をセカンダリリージョンとして使用できます。 **Amazon RDS の制限事項** + DR Orchestrator Framework は、フェイルオーバーまたはフェイルバックの実行前にレプリケーションラグをチェックしません。レプリケーションラグは手動でチェックする必要があります。 + このソリューションは、1 つのリードレプリカを持つプライマリデータベースインスタンスを使用してテストされています。複数のリードレプリカを使用する場合は、本番環境に実装する前にソリューションを十分にテストします。 **Aurora の制限事項** + 機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョンによって異なります。クロスリージョンレプリケーションの機能およびリージョンの可用性の詳細については、「[クロスリージョンリードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.CrossRegionReadReplicas.html)」を参照してください。 + Aurora グローバルデータベースには、サポートされている Aurora DB インスタンスクラスと の最大数に関する特定の設定要件があります AWS リージョン。詳細については、「[Amazon Aurora Global Database の構成要件](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html#aurora-global-database.configuration.requirements)」を参照してください。 + このソリューションは、1 つのリードレプリカを持つプライマリデータベースインスタンスを使用してテストされています。複数のリードレプリカを使用する場合は、本番環境に実装する前にソリューションを十分にテストします。 **ElastiCache の制限事項** + Global Datastore と ElastiCache の設定要件のリージョンの可用性については、ElastiCache ドキュメントの「[前提条件と制限](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastores-Getting-Started.html)」を参照してください。 **Amazon RDS** **製品バージョン** Amazon RDS は、以下のエンジンバージョンをサポートしています。 + **MySQL** – Amazon RDS は、[MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html) 8.0 および MySQL 5.7 バージョンを実行している DB インスタンスをサポートしています。 + **PostgreSQL** – Amazon RDS for PostgreSQL のサポートされているバージョンについては、「[利用可能な PostgreSQL データベースバージョン](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.DBVersions)」を参照してください。 + **MariaDB** – は、以下のバージョンの [MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MariaDB.html) を実行する DB インスタンスをサポートしています。 + MariaDB 10.11 + MariaDB 10.6 + MariaDB 10.5 **Aurora 製品バージョン** + MySQL 5.7 と互換性のある Aurora MySQL の場合、Amazon Aurora Global Database のスイッチオーバーにはバージョン 2.09.1 以降のマイナーバージョンが必要になります。 詳細については、「[Amazon Aurora Global Database の制限](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database.limitations)」を参照してください。 **ElastiCache (Redis OSS) 製品バージョン** Amazon ElastiCache (Redis OSS) は、次の Redis バージョンをサポートしています。 + Redis 7.1 (拡張) + Redis 7.0 (拡張) + Redis 6.2 (拡張) + Redis 6.0 (拡張) + Redis 5.0.6 (拡張) 詳細については、「[Supported ElastiCache (Redis OSS) version](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastores-Getting-Started.html)」を参照してください。 ## アーキテクチャ **Amazon RDS** **アーキテクチャ** Amazon RDS のアーキテクチャには、以下のリソースが含まれています。 + クライアントの読み取り/書き込みアクセス権限を持つプライマリリージョン (`us-east-1`) で作成された、プライマリ Amazon RDS DB インスタンス + クライアントの読み取り専用アクセス権限を持つセカンダリリージョン (`us-west-2`) で作成された Amazon RDS リードレプリカ + プライマリとセカンダリ両方のリージョンにデプロイされた DR オーケストレーターフレームワーク ![\[1 つの AWS アカウントにある 2 つのリージョン RDS アーキテクチャの図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d39561f-924e-4b3e-8175-c5c3cab163bd/images/ad217033-600c-40da-929c-b9f9aecb4c2c.png) 図に示す内容は以下のとおりです。 1. プライマリインスタンスとセカンダリインスタンス間の非同期レプリケーション 1. プライマリリージョンのクライアントの読み取り/書き込みアクセス 1. セカンダリリージョンのクライアントの読み取り専用アクセス **Aurora のアーキテクチャ** Amazon Aurora のアーキテクチャには、以下のリソースが含まれています。 + アクティブライターエンドポイントを使用してプライマリリージョン (`us-east-1`) で作成されたプライマリ Aurora DB クラスター + 非アクティブライターエンドポイントを持つセカンダリリージョン (`us-west-2`) で作成された Aurora DB クラスター + プライマリとセカンダリ両方のリージョンにデプロイされた DR オーケストレーターフレームワーク ![\[1 つの AWS アカウントにある 2 つのリージョンの Aurora デプロイの図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d39561f-924e-4b3e-8175-c5c3cab163bd/images/524ec002-5aa7-47b2-8c8d-6d1a3b535e9e.png) 図に示す内容は以下のとおりです。 1. プライマリクラスターとセカンダリクラスター間の非同期レプリケーション 1. アクティブライターエンドポイントを持つプライマリ DB クラスター 1. 非アクティブライターエンドポイントを持つセカンダリ DB クラスター **ElastiCache (Redis OSS) のアーキテクチャ** Amazon ElastiCache (Redis OSS) のアーキテクチャには以下のリソースが含まれています。 + 2 つのクラスターで作成された ElastiCache (Redis OSS) グローバルデータストア 1. プライマリリージョンのプライマリクラスター (`us-east-1`) 1. セカンダリリージョン (`us-west-2`) のセカンダリクラスター + 2 つのクラスター間の TLS 1.2 暗号化を使用した Amazon クロスリージョンリンク + プライマリとセカンダリ両方のリージョンにデプロイされた DR オーケストレーターフレームワーク ![\[Amazon クロスリージョンリンクを使用した 2 つのリージョンの ElastiCache デプロイの図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d39561f-924e-4b3e-8175-c5c3cab163bd/images/cf6620a0-dd42-4042-8dc2-012bf514ffc0.png) **自動化とスケール** DR Orchestrator Framework はスケーラブルで、複数の AWS データベースのフェイルオーバーまたはフェイルバックを並行してサポートします。 次のペイロードコードを使用して、アカウント内の複数の AWS データベースをフェイルオーバーできます。この例では、3 つの AWS データベース (Aurora MySQL 互換または Aurora PostgreSQL 互換などの 2 つのグローバルデータベース、および 1 つの Amazon RDS for MySQL インスタンス) が DR リージョンにフェイルオーバーします。 ``` { "StatePayload": [ { "layer": 1, "resources": [ { "resourceType": "PlannedFailoverAurora", "resourceName": "Switchover (planned failover) of Amazon Aurora global databases (MySQL)", "parameters": { "GlobalClusterIdentifier": "!Import dr-globaldb-cluster-mysql-global-identifier", "DBClusterIdentifier": "!Import dr-globaldb-cluster-mysql-cluster-identifier" } }, { "resourceType": "PlannedFailoverAurora", "resourceName": "Switchover (planned failover) of Amazon Aurora global databases (PostgreSQL)", "parameters": { "GlobalClusterIdentifier": "!Import dr-globaldb-cluster-postgres-global-identifier", "DBClusterIdentifier": "!Import dr-globaldb-cluster-postgres-cluster-identifier" } }, { "resourceType": "PromoteRDSReadReplica", "resourceName": "Promote RDS for MySQL Read Replica", "parameters": { "RDSInstanceIdentifier": "!Import rds-mysql-instance-identifier", "TargetClusterIdentifier": "!Import rds-mysql-instance-global-arn" } } ] } ] } ``` ## ツール **AWS サービス** + 「[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)」はクラウド用に構築されたフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/) は、 AWS クラウドにある分散したインメモリキャッシュ環境のセットアップ、管理、スケールに役立ちます。このパターンでは、Amazon ElastiCache (Redis OSS) を使用します。 + [AWS Lambda](https://aws.amazon.com/lambda/) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。このパターンでは、Lambda 関数は AWS Step Functions によってステップの実行に使用されます。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。このパターンは、Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB をサポートしています。 + [AWS SDK for Python (Boto3)](https://aws.amazon.com/sdk-for-python/) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立ちます AWS のサービス。このパターンでは、Boto3 API はデータベースインスタンスまたはグローバルデータベースとの通信に使用されます。 + [AWS Step Functions](https://aws.amazon.com/step-functions/) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。このパターンでは、Step Functions ステートマシンを使用して、データベースインスタンスまたはグローバルデータベースの、クロスリージョンフェイルオーバーとフェイルバックをオーケストレーションして実行します。 **コードリポジトリ** このパターンのコードは、GitHub の [aws-cross-region-dr-databases](https://github.com/aws-samples/aws-cross-region-dr-databases/tree/main/App-Stack) リポジトリで入手できます。 ## エピック ### DR オーケストレーターフレームワークをインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリのクローン作成 | リポジトリを複製するには、次のコマンドを実行します。
git clone https://github.com/aws-samples/aws-cross-region-dr-databases.git
| AWS DevOps、AWS 管理者 | | Lambda 関数コードを .zip ファイルアーカイブにパッケージ化します。 | Lambda 関数のアーカイブファイルを作成して、DR Orchestrator Framework の依存関係を含めます。
cd /DR-Orchestration-artifacts

bash scripts/deploy-orchestrator-sh.sh
| AWS 管理者 | | S3 バケットを作成します。 | DR Orchestrator Framework を最新の設定で保存するには S3 バケットが必要です。2 つの S3 バケットを作成します。1 つはプライマリリージョン (`us-east-1`)、もう 1 つはセカンダリリージョン (`us-west-2`) です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.html)`xxxxxx` をランダムな値に置き換えて、バケット名を一意にします。 | AWS 管理者 | | サブネットとセキュリティグループを選択します。 | プライマリリージョン (`us-east-1`) とセカンダリリージョン (`us-west-2`) の両方で、VPC に Lambda 関数をデプロイするための 2 つのサブネットと 1 つのセキュリティグループを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.html) | AWS 管理者 | | DR Orchestrator のパラメータファイルを更新します。 | `/DR-Orchestration-artifacts/cloudformation` フォルダで、次の DR Orchestrator パラメータファイルを更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.html)次のパラメータ値を使用して、`x` と `y` をリソースの名前に置き換えます。
[
    {
         "ParameterKey": "TemplateStoreS3BucketName",
         "ParameterValue": "dr-orchestrator-xxxxxx-us-east-1"
    },
    {
        "ParameterKey": "TemplateVPCId",
        "ParameterValue": "vpc-xxxxxx"
    },
    {
        "ParameterKey": "TemplateLambdaSubnetID1",
        "ParameterValue": "subnet-xxxxxx"
    },
    {
        "ParameterKey": "TemplateLambdaSubnetID2",
        "ParameterValue": "subnet-yyyyyy"
    },
    {
        "ParameterKey": "TemplateLambdaSecurityGroupID",
        "ParameterValue": "sg-xxxxxxxxxx"
    }
 ]
| AWS 管理者 | | DR Orchestrator Framework コードを S3 バケットにアップロードします。 | このコードは、ローカルディレクトリよりも S3 バケットにアップロードする方が安全です。すべてのファイルとサブフォルダを含む `DR-Orchestration-artifacts` ディレクトリを S3 バケットにアップロードします。コードをアップロードするには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.html) | AWS 管理者 | | DR オーケストレーターフレームワークをプライマリリージョンにデプロイします。 | 次のコマンドを実行し、DR Orchestrator Framework をプライマリリージョン (`us-east-1`) にデプロイします。
cd /DR-Orchestration-artifacts/cloudformation

aws cloudformation deploy \
--region us-east-1 \
--stack-name dr-orchestrator \
--template-file Orchestrator-Deployer.yaml \
--parameter-overrides file://Orchestrator-Deployer-parameters-us-east-1.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
| AWS 管理者 | | DR Orchestrator Framework をセカンダリリージョンにデプロイします。 | セカンダリリージョン (`us-west-2`) で、次のコマンドを実行します。
cd /DR-Orchestration-artifacts/cloudformation

aws cloudformation deploy \
--region us-west-2 \
--stack-name dr-orchestrator \
--template-file Orchestrator-Deployer.yaml \
--parameter-overrides file://Orchestrator-Deployer-parameters-us-west-2.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
| AWS 管理者 | | デプロイメントを確認する。 | CloudFormation コマンドが正常に実行されると、次の出力が返されます。
Successfully created/updated stack - dr-orchestrator
または、 CloudFormation コンソールに移動し、`dr-orchestrator`スタックのステータスを確認できます。 | AWS 管理者 | ### データベースインスタンスまたはクラスターを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースサブネットとセキュリティグループを作成します。 | VPC で、プライマリ (`us-east-1`) リージョンとセカンダリ (`us-west-2`) リージョンの両方に、DB インスタンスまたはグローバルデータベース用に 2 つのサブネットと 1 つのセキュリティグループを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cross-region-failover-and-failback-by-using-dr-orchestrator-framework.html) | AWS 管理者 | | プライマリ DB インスタンスまたはクラスターの、パラメータファイルを更新します。 | `/App-Stack` フォルダで、プライマリリージョンのパラメータファイルを更新します。**Amazon RDS**`RDS-MySQL-parameter-us-east-1.json` ファイルで、作成したリソースの名前を付けて `SubnetIds` と `DBSecurityGroup` を更新します。
{
  "Parameters": {
    "SubnetIds": "subnet-xxxxxx,subnet-xxxxxx",
    "DBSecurityGroup": "sg-xxxxxxxxxx",
    "MySqlGlobalIdentifier":"rds-mysql-instance",
    "InitialDatabaseName": "mysqldb",
    "DBPortNumber": "3789",
    "PrimaryRegion": "us-east-1",
    "SecondaryRegion": "us-west-2",
    "KMSKeyAliasName": "rds/rds-mysql-instance-KmsKeyId"
  }
}
**Amazon Aurora** `Aurora-MySQL-parameter-us-east-1.json` ファイルで、作成したリソースの名前を付けて `SubnetIds` と `DBSecurityGroup` を更新します。
{
  "Parameters": {
    "SubnetIds": "subnet1-xxxxxx,subnet2-xxxxxx",
    "DBSecurityGroup": "sg-xxxxxxxxxx",
    "GlobalClusterIdentifier":"dr-globaldb-cluster-mysql",
    "DBClusterName":"dbcluster-01",
    "SourceDBClusterName":"dbcluster-02",
    "DBPortNumber": "3787",
    "DBInstanceClass":"db.r5.large",
    "InitialDatabaseName": "sampledb",
    "PrimaryRegion": "us-east-1",
    "SecondaryRegion": "us-west-2",
    "KMSKeyAliasName": "rds/dr-globaldb-cluster-mysql-KmsKeyId"
  }
}
**Amazon ElastiCache (Redis OSS)**`ElastiCache-parameter-us-east-1.json` ファイルで、作成したリソースの名前を付けて `SubnetIds` と `DBSecurityGroup` を更新します。
{
  "Parameters": {
    "CacheNodeType": "cache.m5.large",
    "DBSecurityGroup": "sg-xxxxxxxxxx",
    "SubnetIds": "subnet-xxxxxx,subnet-xxxxxx",
    "EngineVersion": "5.0.6",
    "GlobalReplicationGroupIdSuffix": "demo-redis-global-datastore",
    "NumReplicas": "1",
    "NumShards": "1",
    "ReplicationGroupId": "demo-redis-cluster",
    "DBPortNumber": "3788",
    "TransitEncryption": "true",
    "KMSKeyAliasName": "elasticache/demo-redis-global-datastore-KmsKeyId",
    "PrimaryRegion": "us-east-1",
    "SecondaryRegion": "us-west-2"
  }
}
| AWS 管理者 | | DB インスタンスまたはクラスターをプライマリリージョンにデプロイします。 | インスタンスまたはクラスターをプライマリリージョン (`us-east-1`) にデプロイするには、データベースエンジンに基づいて次のコマンドを実行します。**Amazon RDS**
cd /App-Stack

aws cloudformation deploy \
--region us-east-1 \
--stack-name rds-mysql-app-stack \
--template-file RDS-MySQL-Primary.yaml \
--parameter-overrides file://RDS-MySQL-parameter-us-east-1.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
**Amazon Aurora**
cd /App-Stack

aws cloudformation deploy \
--region us-east-1 \
--stack-name aurora-mysql-app-stack \
--template-file Aurora-MySQL-Primary.yaml \
--parameter-overrides file://Aurora-MySQL-parameter-us-east-1.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
**Amazon ElastiCache (Redis OSS)**
cd /App-Stack

aws cloudformation deploy \
--region us-east-1 --stack-name elasticache-ds-app-stack \
--template-file ElastiCache-Primary.yaml \
--parameter-overrides file://ElastiCache-parameter-us-east-1.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
CloudFormation リソースが正常にデプロイされたことを確認します。 | AWS 管理者 | | セカンダリ DB インスタンスまたはクラスターのパラメータファイルを更新します。 | `/App-Stack` フォルダで、セカンダリリージョンのパラメータファイルを更新します。**Amazon RDS**`RDS-MySQL-parameter-us-west-2.json` ファイルで、作成したリソースの名前を付けて `SubnetIDs` と `DBSecurityGroup` を更新します。を、プライマリ DB インスタンスの CloudFormation スタックの **Outputs** セクションから`MySQLKmsKeyId`取得した の値`PrimaryRegionKMSKeyArn`で更新します。
{
  "Parameters": {
    "SubnetIds": "subnet-aaaaaaaaa,subnet-bbbbbbbbb",
    "DBSecurityGroup": "sg-cccccccccc",
    "MySqlGlobalIdentifier":"rds-mysql-instance",
    "InitialDatabaseName": "mysqldb",
    "DBPortNumber": "3789",
    "PrimaryRegion": "us-east-1",
    "SecondaryRegion": "us-west-2",
    "KMSKeyAliasName": "rds/rds-mysql-instance-KmsKeyId",
    "PrimaryRegionKMSKeyArn":"arn:aws:kms:us-east-1:xxxxxxxxx:key/mrk-xxxxxxxxxxxxxxxxxxxxx"
  }
}
**Amazon Aurora**`Aurora-MySQL-parameter-us-west-2.json` ファイルで、作成したリソースの名前を付けて `SubnetIDs` と `DBSecurityGroup` を更新します。を、プライマリ DB インスタンスの CloudFormation スタックの **Outputs** セクションから`AuroraKmsKeyId`取得した の値`PrimaryRegionKMSKeyArn`で更新します。
{
  "Parameters": {
    "SubnetIds": "subnet1-aaaaaaaaa,subnet2-bbbbbbbbb",
    "DBSecurityGroup": "sg-cccccccccc",
    "GlobalClusterIdentifier":"dr-globaldb-cluster-mysql",
    "DBClusterName":"dbcluster-01",
    "SourceDBClusterName":"dbcluster-02",
    "DBPortNumber": "3787",
    "DBInstanceClass":"db.r5.large",
    "InitialDatabaseName": "sampledb",
    "PrimaryRegion": "us-east-1",
    "SecondaryRegion": "us-west-2",
    "KMSKeyAliasName": "rds/dr-globaldb-cluster-mysql-KmsKeyId"
  }
}
**Amazon ElastiCache (Redis OSS)**`ElastiCache-parameter-us-west-2.json` ファイルで、作成したリソースの名前を付けて `SubnetIDs` と `DBSecurityGroup` を更新します。を、プライマリ DB インスタンスの CloudFormation スタックの **Outputs** セクションから`ElastiCacheKmsKeyId`取得した の値`PrimaryRegionKMSKeyArn`で更新します。
{
  "Parameters": {
    "CacheNodeType": "cache.m5.large",
    "DBSecurityGroup": "sg-cccccccccc",
    "SubnetIds": "subnet-aaaaaaaaa,subnet-bbbbbbbbb",
    "EngineVersion": "5.0.6",
    "GlobalReplicationGroupIdSuffix": "demo-redis-global-datastore",
    "NumReplicas": "1",
    "NumShards": "1",
    "ReplicationGroupId": "demo-redis-cluster",
    "DBPortNumber": "3788",
    "TransitEncryption": "true",
    "KMSKeyAliasName": "elasticache/demo-redis-global-datastore-KmsKeyId",
    "PrimaryRegion": "us-east-1",
    "SecondaryRegion": "us-west-2"
  }
}
| AWS 管理者 | | DB インスタンスまたはクラスターをセカンダリリージョンにデプロイします。 | データベースエンジンに基づいて、次のコマンドを実行します。**Amazon RDS**
cd /App-Stack

aws cloudformation deploy \
--region us-west-2 \
--stack-name rds-mysql-app-stack \
--template-file RDS-MySQL-DR.yaml \
--parameter-overrides file://RDS-MySQL-parameter-us-west-2.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
**Amazon Aurora**
cd /App-Stack

aws cloudformation deploy \
--region us-west-2 \
--stack-name aurora-mysql-app-stack \
--template-file Aurora-MySQL-DR.yaml \
--parameter-overrides file://Aurora-MySQL-parameter-us-west-2.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
**Amazon ElastiCache (Redis OSS)**
cd /App-Stack

aws cloudformation deploy \
--region us-west-2 \
--stack-name elasticache-ds-app-stack \
--template-file ElastiCache-DR.yaml \
--parameter-overrides file://ElastiCache-parameter-us-west-2.json \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM CAPABILITY_IAM \
--disable-rollback
CloudFormation リソースが正常にデプロイされたことを確認します。 | AWS 管理者 | ## 関連リソース + [のデータベースのディザスタリカバリ戦略 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-disaster-recovery/welcome.html) (AWS 規範ガイダンス戦略) + [でリレーショナルデータベースの DR ソリューションを自動化する AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/automate-dr-solution-relational-database/dr-orchestrator-framework-overview.html) (AWS 規範ガイダンスガイド) + [Amazon Aurora Global Database の使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) + [グローバルデータストア AWS リージョン を使用した 間のレプリケーション](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html) + [でリレーショナルデータベースの DR ソリューションを自動化する AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/automate-dr-solution-relational-database/introduction.html) (AWS 規範ガイダンスガイド) # Systems Manager と EventBridge を使用した SAP HANA データベースの自動バックアップ *Ambarish Satarkar、Gaurav Rath (Amazon Web Services)* ## 概要 このパターンでは、AWS Systems Manager、Amazon EventBridge、Amazon Simple Storage Service (Amazon S3)、および AWS Backint Agent for SAP HANA エージェント を使用して SAP HANA データベースのバックアップを自動化する方法を説明します。 このパターンでは、`BACKUP DATA` コマンドを使用するシェルスクリプトベースのアプローチが可能になり、多数のシステムにまたがるオペレーティングシステム (OS) インスタンスごとにスクリプトやジョブ設定を管理する必要がなくなります。 | | | 注: 2023 年 4 月の時点で、AWS Backup は、Amazon Elastic Compute Cloud (Amazon EC2) での SAP HANA データベースのサポートを発表しました。詳細については、「[Amazon EC2 インスタンスのバックアップでの SAP HANA データベース](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-saphana.html)」を参照してください。組織のニーズに応じて、AWS Backup サービスを使用して SAP HANA データベースを自動的にバックアップすることも、このパターンを使用することもできます。 | | --- | ## 前提条件と制限事項 **前提条件** + Systems Manager 向けに設定されているマネージド型 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで、サポート対象のリリースを含む既存の SAP HANA インスタンス (実行中) + Systems Manager エージェント (SSM エージェント) 2.3.274.0 以降のバージョンがインストール済み + パブリックアクセスが有効になっていない S3 バケット　　 + `hdbuserstore` という名前の `SYSTEM` キー + オートメーションランブックをスケジュールどおりに実行するための AWS Identity and Access Management (IAM) ロール　 + `AmazonSSMManagedInstanceCore` と `ssm:StartAutomationExecution` ポリシーは Systems Manager Automation サービスロールにアタッチされます。 **機能制限** + AWS Backint Agent for SAP HANA は重複排除をサポートしていません。 + AWS Backint Agent for SAP HANA はデータ圧縮をサポートしていません。 **製品バージョン** AWS Backint Agent は、以下のオペレーティングシステムでサポートされています。 + SUSE Linux Enterprise Server + SUSE Linux Enterprise Server for SAP + Red Hat Enterprise Linux for SAP AWS Backint Agent では、以下のデータベースがサポートされています。　  + SAP HANA 1.0 SP12 (シングルノードとマルチノード) + SAP HANA 2.0 以降 (シングルノードとマルチノード) ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Backint Agent + Amazon S3 + AWS Systems Manager + Amazon EventBridge + SAP HANA **ターゲットアーキテクチャ** 次の図は、AWS Backint Agent、S3 バケット、Systems Manager と EventBridge をインストールするスクリプトを示しています。これらのスクリプトは、コマンド ドキュメントを使用して定期的なバックアップをスケジュールします。 ![\[定期的なバックアップをスケジュールするためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0aa22a27-d100-483d-95f9-c3101f40402c/images/201d2b9a-b88e-4432-82cd-240b81da981e.png) **自動化とスケール** + Systems Manager Automation ランブックを使用すると、複数の AWS Backint Agent をインストールできます。 + Systems Manager ランブックを実行するたびに、ターゲットの選択に基づいて、*n* 個の SAP HANA インスタンスまでスケールできます。 + EventBridge は SAP HANA のバックアップを自動化できます。　 ## ツール + 「[AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)」は、既存のワークフローと統合して、設定ファイルで指定した S3 バケットに SAP HANA データベースをバックアップするスタンドアロン アプリケーションです。AWS Backint Agent は SAP HANA データベースの完全バックアップ、増分バックアップ、差分バックアップをサポートしています。SAP HANA データベースサーバーで実行され、バックアップとカタログが SAP HANA データベースから AWS Backint Agent に転送されます。 + [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースからのデータに接続するために使用できるサーバーレスのイベントバスサービスです。EventBridge は、アプリケーション、Software as a Service (SaaS) アプリケーション、および AWS サービスからのリアルタイムデータのストリームを、AWS Lambda 関数、API デスティネーションを使用した HTTP 呼び出しエンドポイント、または他のアカウントのイベントバスなどのターゲットに配信します。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)は、オブジェクトストレージを提供します。Simple Storage Service (Amazon S3) を使用すると、いつでもウェブ上の任意の場所から任意の量のデータを保存および取得できます。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、AWS 上のインフラストラクチャを可視化し、制御するためのサービスです。Systems Manager コンソールを使用すると、複数の AWS サービスからの運用データを表示し、AWS リソース全体の運用タスクを自動化できます。 **コード** このパターンのコードは、「[aws-backint-automated-backup](https://github.com/aws-samples/aws-backint-automated-backup)」GitHub リポジトリで利用できます。 ## エピック ### hdbuserstore キーシステムを作成します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | hdbuserstore キーシステムを作成します | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-back-up-sap-hana-databases-using-systems-manager-and-eventbridge.html) | AWS 管理者、SAP HANA 管理者 | ### AWS Backint Agent のインストール | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS Backint Agent のインストール | AWS Backint Agent ドキュメントの[「 AWS Backint Agent for SAP HANA のインストールと設定」](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-installing-configuring.html)の手順に従ってください。 | AWS 管理者、SAP HANA 管理者 | ### Systems Manager コマンドのドキュメントを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Systems Manager コマンドのドキュメントを作成する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-back-up-sap-hana-databases-using-systems-manager-and-eventbridge.html) | AWS 管理者、SAP HANA 管理者 | ### 定期的にバックアップをスケジュールします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon EventBridge を使用して定期バックアップをスケジュールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-back-up-sap-hana-databases-using-systems-manager-and-eventbridge.html)S3 バケットパスから,バックアップの完了を確認できます。 
 s3:////usr/sap//SYS/global/hdb/backint/DB_/
SAP HANA バックアップカタログからバックアップを確認することもできます。　 | AWS 管理者、SAP HANA 管理者 | ## 関連リソース + 「[AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)」 + 「[AWS Backint Agent for SAP HANA のインストールと設定](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-installing-configuring.html)] # Python アプリケーションを使用して Amazon DynamoDB の PynamoDB モデルと CRUD 関数を自動的に生成する *Vijit Vashishtha、Dheeraj Alimchandani、Dhananjay Karanjkar (Amazon Web Services)* ## 概要 Amazon DynamoDB データベースオペレーションを効率的に実行するために、エンティティと作成、読み取り、更新、削除 (CRUD) オペレーション関数を要求するのが一般的です。PynamoDB は Python 3 をサポートする Python ベースのインターフェイスです。また、Amazon DynamoDB Transactions のサポート、属性値の自動シリアル化と逆シリアル化、Flask や Django などの一般的な Python フレームワークとの互換性などの機能も提供します。このパターンは、PynamoDB モデルと CRUD オペレーション関数の自動作成を合理化するライブラリを提供するため、Python と DynamoDB を使用する開発者に役立ちます。データベーステーブルに不可欠な CRUD 関数を生成する一方で、Amazon DynamoDB テーブルから PynamoDB モデルと CRUD 関数をリバースエンジニアリングすることもできます。このパターンは、Python ベースのアプリケーションを使用してデータベースオペレーションを簡素化するように設計されています。 このソリューションの主要な機能は次のとおりです。 + **JSON スキーマから PynamoDB モデル** – JSON スキーマファイルをインポートして Python で PynamoDB モデルを自動的に生成します。 + **CRUD 関数の生成** – DynamoDB テーブルで CRUD オペレーションを実行する関数を自動的に生成します。 + **DynamoDB からのリバースエンジニアリング** – PynamoDB オブジェクトリレーショナルマッピング (ORM) を使用して、既存の Amazon DynamoDB テーブルの PynamoDB モデルと CRUD 関数をリバースエンジニアリングします。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Python バージョン 3.8 以降が[ダウンロード](https://www.python.org/downloads/)およびインストールされている + Jinja2 バージョン 3.1.2 以降が[ダウンロード](https://pypi.org/project/Jinja2/#files)およびインストールされている + ORM を生成する Amazon DynamoDB テーブル + AWS Command Line Interface (AWS CLI)、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み + PynamoDB バージョン 5.4.1 以降が[インストール済み](https://pynamodb.readthedocs.io/en/stable/tutorial.html#installation) ## アーキテクチャ **ターゲットテクノロジースタック** + JSON スクリプト + Python アプリケーション + PynamoDB モデル + Amazon DynamoDB データベースインスタンス **ターゲットアーキテクチャ** ![\[Python アプリを使用して、DynamoDB テーブルから CRUD 関数と PynamoDB モデルを生成します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/74cc4c73-5c8b-448d-98fb-b681cfa5f860/images/c2c367d6-d88a-4f49-8571-89160539eb08.png) 1. 入力 JSON スキーマファイルを作成します。この JSON スキーマファイルは、PynamoDB モデルの作成元および CRUD 関数の作成先となるそれぞれの DynamoDB テーブルの属性を表します。これには、次の 3 つの重要なキーが含まれています。 + `name` – ターゲット DynamoDB テーブルの名前。 + `region` – テーブル AWS リージョン がホストされている 。 + `attributes` – [パーティションキー](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey) (*ハッシュ属性*とも呼ばれます)、[ソートキー](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey)、[ローカルセカンダリインデックス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI.html)、[グローバルセカンダリインデックス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html)、[非キー属性](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.TablesItemsAttributes)など、ターゲットテーブルの一部である属性。このツールは、アプリケーションがターゲットテーブルから直接キー属性を取得するため、入力スキーマが非キー属性のみを提供することを想定しています。JSON スキーマファイルで属性を指定する方法の例については、このパターンの「[追加情報](#automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application-additional)」セクションを参照してください。 1. Python アプリケーションを実行し、JSON スキーマファイルを入力として指定します。 1. Python アプリケーションは、JSON スキーマファイルを読み取ります。 1. Python アプリケーションは、DynamoDB テーブルに接続し、スキーマとデータ型を取得します。アプリケーションは [describe\$1table](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/dynamodb/client/describe_table.html) オペレーションを実行して、テーブルのキー属性とインデックス属性を取得します。 1. Python アプリケーションは、JSON スキーマファイルと DynamoDB テーブルの属性を組み合わせます。Jinja テンプレートエンジンを使用し、PynamoDB モデルと対応する CRUD 関数を生成します。 1. PynamoDB モデルにアクセスし、DynamoDB テーブルで CRUD オペレーションを実行します。 ## ツール **AWS のサービス** + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 **その他のツール** + [Jinja](https://jinja.palletsprojects.com/en/) は、テンプレートを最適化された Python コードにコンパイルする拡張可能なテンプレートエンジンです。このパターンでは、Jinja を使用し、テンプレート内にプレースホルダーとロジックを埋め込むことで動的コンテンツを生成します。 + [PynamoDB](https://pynamodb.readthedocs.io/en/stable/) は、Amazon DynamoDB 用の Python ベースのインターフェイスです。 + 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。 **コードリポジトリ** このパターンのコードは、GitHub [Auto-generate PynamoDB models and CRUD functions](https://github.com/aws-samples/amazon-reverse-engineer-dynamodb) リポジトリで入手できます。このリポジトリは、コントローラーパッケージとテンプレートの 2 つの主要部分に分かれています。 *コントローラーパッケージ* コントローラー Python パッケージには、PynamoDB モデルと CRUD 関数の生成に役立つ主要なアプリケーションロジックが含まれています。以下の要素が含まれます。 + `input_json_validator.py` – この Python スクリプトは入力 JSON スキーマファイルを検証し、ターゲット DynamoDB テーブルのリストと各テーブルに必要な属性を含む Python オブジェクトを作成します。 + `dynamo_connection.py` – このスクリプトは DynamoDB テーブルへの接続を確立し、`describe_table` オペレーションを使用して PynamoDB モデルの作成に必要な属性を抽出します。 + `generate_model.py` – このスクリプトには、入力 JSON スキーマファイルと `describe_table` オペレーションに基づいて PynamoDB モデルを作成する Python クラス `GenerateModel` が含まれています。 + `generate_crud.py` – JSON スキーマファイルで定義されている DynamoDB テーブルの場合、このスクリプトは `GenerateCrud` オペレーションを使用して Python クラスを作成します。 *テンプレート* この Python ディレクトリには、次の Jinja テンプレートが含まれています。 + `model.jinja` – この Jinja テンプレートには、PynamoDB モデルスクリプトを生成するためのテンプレート式が含まれています。 + `crud.jinja` – この Jinja テンプレートには、CRUD 関数スクリプトを生成するためのテンプレート式が含まれています。 ## エピック ### 環境をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リポジトリのクローン作成 | 次のコマンドを入力して、[Auto-generate PynamoDB models and CRUD functions](https://github.com/aws-samples/amazon-reverse-engineer-dynamodb) リポジトリのクローンを作成します。
git clone https://github.com/aws-samples/amazon-reverse-engineer-dynamodb.git
| アプリ開発者 | | Python 環境をセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.html) | アプリ開発者 | ### PynamoDB モデルと CRUD 関数を生成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | JSON スキーマファイルを変更します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.html) | アプリ開発者 | | Python アプリケーションを実行します。 | 次のコマンドを入力して PynamoDB モデルと CRUD 関数を生成します。ここで、`` は JSON スキーマファイルの名前です。
python main.py --file
| アプリ開発者 | ### PynamoDB モデルと CRUD 関数を検証する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 生成された PynamoDB モデルを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.html) | アプリ開発者 | | 生成された CRUD 関数を検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.html) | アプリ開発者 | ## 関連リソース + [Amazon DynamoDB のコアコンポーネント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html) (DynamoDB ドキュメント) + [DynamoDB でのセカンダリインデックスを使用したデータアクセス性の向上](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html) (DynamoDB ドキュメント) ## 追加情報 **JSON スキーマファイルの属性例** ``` [ { "name": "test_table", "region": "ap-south-1", "attributes": [ { "name": "id", "type": "UnicodeAttribute" }, { "name": "name", "type": "UnicodeAttribute" }, { "name": "age", "type": "NumberAttribute" } ] } ] ``` # クラウドカストディアンを使用して Amazon RDS へのパブリックアクセスをブロック *Abhay Kumar、Dwarika Patra (Amazon Web Services)* ## 概要 多くの組織がワークロードとサービスを複数のクラウドベンダーで実行しています。このようなハイブリッドクラウド環境では、個々のクラウドプロバイダーが提供するセキュリティに加えて、クラウドインフラストラクチャには厳格なクラウドガバナンスが必要です。Amazon Relational Database Service (Amazon RDS) のようなクラウドデータベースは、アクセスや許可に関する脆弱性がないか監視する必要がある重要なサービスの1つです。セキュリティグループを設定することで Amazon RDS データベースへのアクセスを制限できますが、2 つ目の保護レイヤーを追加してパブリックアクセスなどのアクションを禁止することもできます。パブリックアクセスをブロックすると、一般データ保護規則 (GDPR)、Health Insurance Portability and Accountability Act (HIPAA)、米国国立標準技術研究所 (NIST)、Payment Card Industry Data Security Standard (PCI DSS) に準拠するのに役立ちます。 Cloud Custodian は、Amazon RDS などの Amazon Web Services (AWS) リソースにアクセス制限を適用するために使用できるオープンソースのルールエンジンです。Cloud Custodian では、定義されたセキュリティおよびコンプライアンス基準に照らして環境を検証するルールを設定できます。Cloud Custodian を使用すると、セキュリティポリシー、タグポリシーの順守、未使用リソースのガベージコレクション、コスト管理を実現することで、クラウド環境を管理できます。Cloud Custodian を使用すると、単一のインターフェイスでハイブリッドクラウド環境にガバナンスを実装できます。例えば、Cloud Custodian インターフェイスを使用して AWS および Microsoft Azure とやり取りし AWS Config、 AWS セキュリティグループや Azure ポリシーなどのメカニズムを使用する労力を減らすことができます。 このパターンでは、 で Cloud Custodian AWS を使用して Amazon RDS インスタンスにパブリックアクセシビリティの制限を適用する手順を示します。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + 「[キーペア](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-creds-create)」 + AWS Lambda インストール済み ## アーキテクチャ 次の図は、Amazon RDS での Cloud Custodian によるポリシーのデプロイ AWS Lambda、`CreateDBInstance`イベント AWS CloudTrail の開始、Lambda 関数設定の `PubliclyAccessible` false を示しています。 ![\[AWS で Cloud Custodian を使用して Amazon RDS インスタンスへのパブリックアクセスを制限します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/90f9537e-9365-4da2-8a28-da0ff374743c/images/6d04ca3b-6aa4-4c62-ade9-8b7474928c5e.png) ## ツール **AWS のサービス** + [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) は、 のガバナンス、コンプライアンス、運用リスクを監査するのに役立ちます AWS アカウント。 + [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベースをセットアップ、運用、スケーリングできます。 その他のツール + 「[Cloud Custodian](https://cloudcustodian.io/)」 は、多くの組織がパブリッククラウドアカウントの管理に使用しているツールとスクリプトを 1 つのオープンソースツールに統合します。ポリシーの定義と実施にはステートレスなルールエンジンを使用し、クラウドインフラストラクチャの指標、構造化された出力、詳細なレポート機能を備えています。サーバーレスランタイムと緊密に統合されているため、運用上のオーバーヘッドを低く抑えながらリアルタイムの修復と対応が可能です。 ## エピック ### のセットアップ AWS CLI | タスク | 説明 | 必要なスキル | | --- | --- | --- | | をインストールします AWS CLI。 | をインストールするには AWS CLI、 [AWS ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)の指示に従います。 | AWS 管理者 | | AWS 認証情報を設定します。 | や使用する AWS リージョン 出力形式など AWS、 が操作 AWS CLI に使用する設定を構成します。
$>aws configure
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]:
Default output format [None]:
詳細については、[AWS のドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)を参照してください。 | AWS 管理者 | | IAM ロールを作成します。 | Lambda 実行ロールを使用して IAM ロールを作成するには、次のコマンドを実行します。
aws iam create-role --role-name lambda-ex --assume-role-policy-document '{"Version": "2012-10-17",		 	 	 "Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}
| AWS DevOps | ### クラウドカストディアンをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラウドカストディアンをインストールします。 | ご使用のオペレーティングシステムと環境に Cloud Custodian をインストールするには、「[Cloud Custodian ドキュメント](https://cloudcustodian.io/docs/quickstart/index.html#install-cc)」 の指示に従ってください。 | DevOps エンジニア | | クラウドカストディアンスキーマをチェックします。 | ポリシーを実行できる Amazon RDS リソースの完全なリストを確認するには、以下のコマンドを使用します。
custodian schema aws.rds
| DevOps エンジニア | | クラウドカストディアンポリシーを作成します。 | *Cloud Custodian ポリシーファイル*にあるコードを YAML 拡張子を使用して[追加情報](#block-public-access-to-amazon-rds-by-using-cloud-custodian-additional)セクションに保存します。 | DevOps エンジニア | | パブリックにアクセス可能なフラグを変更するクラウドカストディアンアクションを定義します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/block-public-access-to-amazon-rds-by-using-cloud-custodian.html) | DevOps エンジニア | | リサルの実行を行います。 | (オプション) リソースに対してアクションを実行せずに、ポリシーによってどのリソースが識別されているかを確認するには、以下のコマンドを使用します。
custodian run -dryrun .yaml -s
| DevOps エンジニア | ### ポリシーをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda を使用してポリシーをデプロイします。 | ポリシーを実行する Lambda 関数を作成するには、次のコマンドを使用します。
custodian run -s policy.yaml
その後、このポリシーは イベントによって開始されます AWS CloudTrail `CreateDBInstance`。その結果、 AWS Lambda は条件に一致するインスタンス`false`のパブリックアクセス可能なフラグを に設定します。 | DevOps エンジニア | ## 関連リソース + [AWS Lambda website](https://aws.amazon.com/lambda/) + [Amazon RDS ウェブサイト](https://aws.amazon.com/rds/) + [Cloud Custodian のドキュメント](https://cloudcustodian.io/docs/quickstart/index.html) ## 追加情報 クラウドカストディアンポリシー (YAML ファイル) ``` policies: - name: "block-public-access" resource: rds description: | This Enforcement blocks public access for RDS instances. mode: type: cloudtrail events: - event: CreateDBInstance # Create RDS instance cloudtrail event source: rds.amazonaws.com ids: requestParameters.dBInstanceIdentifier role: arn:aws:iam::1234567890:role/Custodian-compliance-role filters: - type: event key: 'detail.requestParameters.publiclyAccessible' value: true actions: - type: set-public-access state: false ``` c7n リソース rds.py ファイル ``` @actions.register('set-public-access') class RDSSetPublicAvailability(BaseAction): schema = type_schema( "set-public-access", state={'type': 'boolean'}) permissions = ('rds:ModifyDBInstance',) def set_accessibility(self, r): client = local_session(self.manager.session_factory).client('rds') waiter = client.get_waiter('db_instance_available') waiter.wait(DBInstanceIdentifier=r['DBInstanceIdentifier']) client.modify_db_instance( DBInstanceIdentifier=r['DBInstanceIdentifier'], PubliclyAccessible=self.data.get('state', False)) def process(self, rds): with self.executor_factory(max_workers=2) as w: futures = {w.submit(self.set_accessibility, r): r for r in rds} for f in as_completed(futures): if f.exception(): self.log.error( "Exception setting public access on %s \n %s", futures[f]['DBInstanceIdentifier'], f.exception()) return rds ``` **Security Hub CSPM 統合** Cloud Custodian を [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) と統合して、セキュリティ検出結果を送信し、修復アクションを試みることができます。詳細については、[「 とのクラウドカストディアン統合の発表 AWS Security Hub CSPM](https://aws.amazon.com/blogs/opensource/announcing-cloud-custodian-integration-aws-security-hub/)」を参照してください。 # を使用して Amazon RDS for Microsoft SQL Server の Windows 認証を設定する AWS Managed Microsoft AD *Ramesh Babu Donti (Amazon Web Services)* ## 概要 このパターンは、 AWS Directory Service for Microsoft Active Directory () を使用して SQL Server インスタンスの Amazon Relational Database Service (Amazon RDS) の Windows 認証を設定する方法を示していますAWS Managed Microsoft AD。Windows 認証を使用すると、ユーザーはデータベース固有のユーザー名とパスワードではなく、ドメイン認証情報を使用して RDS インスタンスに接続できるようになります。 Windows 認証を有効にするには、新しい RDS SQL Server データベースの作成時に設定するか、または既存のデータベースインスタンスに Windows 認証を追加します。データベースインスタンスは と統合 AWS Managed Microsoft AD され、SQL Server データベースにアクセスするドメインユーザーに一元的な認証と認可を提供します。 このように設定することで、既存の Active Directory インフラストラクチャを生かしてセキュリティが強化され、ドメインユーザーの個別のデータベース認証情報を管理する必要がなくなります。 ## 前提条件と制限 **前提条件** + 適切なアクセス許可 AWS アカウント を持つアクティブな + 以下を含む仮想プライベートクラウド (VPC): + 設定済みのインターネットゲートウェイとルートテーブル + パブリックサブネットの NAT ゲートウェイ (インターネットアクセスが必要なインスタンスの場合) + AWS Identity and Access Management (IAM) ロール: + 次の AWS 管理ポリシーを持つドメインロール。 + `AmazonSSMManagedInstanceCore` を有効にするには AWS Systems Manager + インスタンスをディレクトリに結合するアクセス許可を付与するための `AmazonSSMDirectoryServiceAccess` + RDS 拡張モニタリングロール (拡張モニタリングが有効になっている場合) + セキュリティグループ: + Active Directory 通信ポートを許可するディレクトリサービスセキュリティグループ + RDP `3389` とドメイン通信を許可する Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループ + 許可されたソースからの SQL Server ポート `1433` を許可する RDS セキュリティグループ + ネットワーク接続: + サブネット間の DNS 解決とネットワーク接続が適切であること **制限事項** + RDS for SQL Server AWS Managed Microsoft AD で AWS リージョン をサポートする方法については、[「リージョンとバージョンの可用性](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html#USER_SQLServerWinAuth.RegionVersionAvailability)」を参照してください。 + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。 ## アーキテクチャ **ソーステクノロジースタック** + オンプレミス Active Directory または AWS Managed Microsoft AD **ターゲットテクノロジースタック** + Amazon EC2 + Amazon RDS for Microsoft SQL Server + AWS Managed Microsoft AD **ターゲットアーキテクチャ** ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e02f6059-6631-46f6-819c-5961af7ba4ae/images/1aa50e3b-b4f6-4d44-9f9e-6cbb248a159c.png) このアーキテクチャには、以下の項目が含まれます。 + Amazon EC2 インスタンスを AWS Managed Microsoft AD ドメインに結合する IAM ロール。 + データベースの管理とテスト用の Amazon EC2 Windows インスタンス + アベイラビリティーゾーン間で Amazon RDS インスタンスと内部リソースをホストするプライベートサブネットを持つ Amazon VPC + ネットワークアクセス制御のためのセキュリティグループ: + 許可されたソースからの SQL Server ポート `1433` へのインバウンドアクセスを制御する Amazon RDS セキュリティグループ + ポート `3389` とドメインの通信ポートを介して RDP アクセスを管理する Amazon EC2 セキュリティグループ + ポート `53`、`88`、`389`、`445` を介した Active Directory 通信用の Directory Services セキュリティグループ + AWS Managed Microsoft AD は、Windows リソースに一元化された認証および認可サービスを提供します。 + Windows 認証が有効になっているプライベートサブネット内の Amazon RDS for SQL Server データベースインスタンス ## ツール **AWS のサービス** + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + Amazon Relational Database Service (Amazon RDS) を使用して、 AWS クラウドでリレーショナルデータベースをセットアップ、運用、スケーリングできます。 + [AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) には、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS) for SQL Server、Amazon FSx for Windows File Server AWS のサービス など、他の で Microsoft Active Directory (AD) を使用する複数の方法が用意されています。 + [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) は、ディレクトリ対応のワークロードと AWS リソースが で Microsoft Active Directory を使用できるようにします AWS クラウド。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 **その他のサービス** + [Microsoft SQL Server Management Studio (SSMS)](https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms) は、SQL Server コンポーネントへのアクセス、設定、管理など、SQL Server を管理するためのツールです。 ## ベストプラクティス + 一般的なベストプラクティスについては、「[Amazon RDS のベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html)」を参照してください。 ## エピック ### 設定 AWS Managed Microsoft AD | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ディレクトリタイプの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | ディレクトリ情報の設定 | **[ディレクトリ情報]** セクションで、必要な情報を入力し、オプションの値を保持します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | VPC とサブネットの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | ディレクトリを確認して作成する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | ### Amazon EC2 インスタンスを作成して設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Windows 用の AMI の設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | ネットワーク設定の指定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | ストレージの設定 | 必要に応じて Amazon EBS ボリュームを設定します。 | DBA、DevOps エンジニア | | 高度な詳細を設定し、インスタンスを起動する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | ### Windows 認証を使用した RDS for SQL Server の作成と設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースを作成し、エンジンオプションを設定する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | テンプレートの選択 | 要件を満たすサンプルテンプレートを選択します。 | DBA、DevOps エンジニア | | データベース設定の指定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | インスタンスの設定 | **[インスタンス設定]** セクションの **[DB インスタンスクラス]** で、要件を満たすインスタンスサイズを選択します。 | DBA、DevOps エンジニア | | ストレージの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | 接続の設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | Windows 認証の設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | モニタリングの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html)注意: さまざまなプロセスまたはスレッドが CPU をどのように使用しているかを確認するには、各種メトリクスが役立ちます。**[エラーログ]** が有効になっている場合は、エラーログを Amazon CloudWatch にエクスポートすることもできます。 | DBA、DevOps エンジニア | | その他の設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | コストを確認してデータベースを作成する | **[月額コストの見積もり]** セクションを確認し、**[データベースの作成]** を選択します。 | DBA、DevOps エンジニア | ### データベースアクセスとテスト接続を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Windows マシンへの接続 | Windows マシンに接続し、SQL Server Management Studio を起動します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | SSMS 接続の設定 | Windows 認証を使用してデータベース接続を設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | セキュリティ設定の指定 | SSMS バージョン 20 以降に必要なセキュリティパラメータを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | | Windows ログインの作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html)
CREATE LOGIN [\] FROM WINDOWS;
GO
| DBA、DevOps エンジニア | | Windows 認証をテストする | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-windows-authentication-for-amazon-rds-using-microsoft-ad.html) | DBA、DevOps エンジニア | ## 関連リソース + [の作成 AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) + [Amazon EC2 Windows インスタンスを に結合する AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html) + [Amazon RDS での Kerberos 認証でサポートされているリージョンと DB エンジン](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.html) + [What is SQL Server Management Studio (SSMS)?](https://learn.microsoft.com/en-us/ssms/sql-server-management-studio-ssms) # Amazon DynamoDB へのクロスアカウントアクセスを設定する *Amazon Web Services、Shashi Dalmia、Imhoertha Ojior、Esteban Serna Parra* ## 概要 このパターンでは、リソースベースのポリシーを使用して、Amazon DynamoDB へのクロスアカウントアクセスを設定する手順を説明します。DynamoDB を使用するワークロードでは、セキュリティの脅威を最小限に抑え、コンプライアンス要件を満たすために、[ワークロード分離戦略](https://aws.amazon.com/solutions/guidance/workload-isolation-on-aws/?did=sl_card&trk=sl_card)を使用するケースが増えています。ワークロード分離戦略を実装するには、 AWS Identity and Access Management (IAM) アイデンティティベースのポリシーを使用して DynamoDB リソースへのクロスアカウントおよびクロスリージョンアクセスが必要になることがよくあります。これには、IAM アクセス許可の設定と、 間の信頼関係の確立が含まれます AWS アカウント。 [DynamoDB のリソースベースのポリシー](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html)は、クロスアカウントワークロードのセキュリティ体制を大幅に簡素化します。このパターンでは、別のアカウントの DynamoDB データベーステーブルにデータを書き込む AWS アカウント ように 1 つの で AWS Lambda 関数を設定する方法を示すステップとサンプルコードを示します。 ## 前提条件と制限 **前提条件** + 2 つの がアクティブです AWS アカウント。このパターンでは、これらのアカウントを*アカウント A* と*アカウント B* と呼びます。 + AWS Command Line Interface (AWS CLI) [をインストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)し、アカウント A にアクセスするように[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)して、DynamoDB テーブルを作成します。このパターンの他のステップでは、IAM、DynamoDB、および Lambda コンソールの使用手順について説明します。 AWS CLI 代わりに を使用する場合は、両方のアカウントにアクセスするように設定してください。 **制限事項** + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。 ## アーキテクチャ 次の図は、単一アカウントアーキテクチャを示しています。 AWS Lambda、Amazon Elastic Compute Cloud (Amazon EC2)、DynamoDB はすべて同じアカウントにあります。このシナリオでは、Lambda 関数と Amazon EC2 インスタンスは DynamoDB にアクセスできます。DynamoDB テーブルへのアクセスを許可するには、IAM でアイデンティティベースのポリシーを作成するか、DynamoDB でリソースベースのポリシーを作成します。 ![\[IAM アクセス許可を使用して、同じアカウントの DynamoDB テーブルにアクセスする。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bfc32fe8-5db0-4cac-a30f-b870a1a82875/images/cbb009eb-422d-4833-a1bc-0c571d83c21f.png) 次の図は、マルチアカウントのアーキテクチャを示しています。ある のリソースが別のアカウントの DynamoDB テーブルにアクセス AWS アカウント する必要がある場合は、DynamoDB でリソースベースのポリシーを設定して、必要なアクセスを許可する必要があります。例えば、次の図では、リソースベースのポリシーを使用して、アカウント A の DynamoDB テーブルへのアクセスがアカウント B の Lambda 関数に許可されています。 ![\[リソースベースのポリシーを使用して、別のアカウントの DynamoDB テーブルにアクセスする。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bfc32fe8-5db0-4cac-a30f-b870a1a82875/images/9f9165a8-b767-4427-a2ae-31b5b8c83326.png) このパターンでは、Lambda と DynamoDB 間のクロスアカウントアクセスについて説明します。両方のアカウントに適切なアクセス許可 AWS のサービス が設定されている場合、他の にも同様の手順を使用できます。例えば、アカウント A の Amazon Simple Storage Service (Amazon S3) バケットへのアクセスを Lambda 関数に許可する場合は、Amazon S3 で[リソースベースのポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)を作成し、アカウント B の [Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)にアクセス許可を追加します。 ## ツール **AWS のサービス** + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、AWS リソースの使用を認証および認可されたユーザーを制御することで、AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 **Code** このパターンでは、アカウント B の Lambda 関数を設定して、アカウント A の DynamoDB テーブルへの書き込みを行う方法を示すサンプルコードを「[追加情報](#configure-cross-account-access-to-amazon-dynamodb-additional)」セクションに用意しています。このコードは、説明とテストのみを目的としたものです。このパターンを本番環境に実装する場合は、サンプルコードを参照用に使用し、自分の環境に合わせてカスタマイズしてください。 ## ベストプラクティス + DynamoDB ドキュメントの「[DynamoDB リソースベースのポリシーに関するベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-best-practices.html)」に従ってください。 + 最小特権の原則に従い、タスクの実行に必要最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 ## エピック ### アカウント B で Lambda 関数の IAM ポリシーとロールを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アカウント B でポリシーを作成する | この IAM ポリシーは、アカウント A の DynamoDB テーブルの [PutItem](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html) アクションを許可します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html) | AWS 全般 | | アカウント A でロールを作成する | アカウント B の Lambda 関数は、この IAM ロールを使用して、アカウント A の DynamoDB テーブルにアクセスします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)ロールの作成の詳細については、「[IAM ドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。 | AWS 全般 | | ロールの ARN を書き留めておきます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html) | AWS 全般 | ### アカウント A でDynamoDB テーブルを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB テーブルを作成します。 | DynamoDB テーブルを作成するには、次の AWS CLI コマンドを使用します。
 aws dynamodb create-table \
    --table-name Table-Account-A \
    --attribute-definitions \
      AttributeName=category,AttributeType=S \
      AttributeName=item,AttributeType=S \
    --key-schema \
      AttributeName=category,KeyType=HASH \
      AttributeName=item,KeyType=RANGE \
    --provisioned-throughput \
      ReadCapacityUnits=5,WriteCapacityUnits=5 \
    --resource-policy \
      '{         
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {                    
               "Sid": "Statement1",
               "Effect": "Allow",
               "Principal": {
                  "AWS": "arn:aws:iam:::role/"
               },
               "Action": "dynamodb:PutItem",
               "Resource": "arn:aws:dynamodb:::table/Table-Account-A"
            }            
         ]
      }'
このコードサンプルでは、以下を置き換えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)`create-table` ステートメントでリソースベースのポリシー設定を指定するには、`--resource-policy` フラグを使用します。このポリシーは、アカウント A の DynamoDB テーブルの ARN を参照します。テーブルの作成の詳細については、「[DynamoDB のドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html)」を参照してください。 | AWS 全般 | ### アカウント B で Lambda 関数を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB にデータを書き込むLambda 関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)Lambda 関数の作成についての詳細は、「[Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/getting-started-create-function.html)」を参照してください。 | AWS 全般 | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースの削除 | このパターンで作成されたリソースに関連するコストが発生しないようにするには、以下を実行して、これらのリソースを削除します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html) | AWS 全般 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Lambda 関数を作成すると、`ResourceNotFoundException` エラーが表示される | アカウント A の AWS リージョン と ID が正しく入力されていることを確認します。これらは DynamoDB テーブルの ARN の一部です。 | ## 関連リソース + 「[DynamoDB の使用を開始する](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html)」(DynamoDB ドキュメント) + [最初の Lambda 関数を作成する](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) (Lambda ドキュメント) + [DynamoDB 用のリソースベースのポリシーを使用する](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html) (DynamoDB ドキュメント) + 「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」(IAM ドキュメント) + 「[クロスアカウントポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」(IAM ドキュメント) + 「[IAM JSON ポリシー要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」(IAM ドキュメント) ## 追加情報 「サンプルコード」 ``` import boto3 from datetime import datetime dynamodb_client = boto3.client('dynamodb') def lambda_handler(event, context): now = datetime.now().isoformat() data = dynamodb_client.put_item(TableName='arn:aws:dynamodb:::table/Table-Account-A', Item={"category": {"S": "Fruit"},"item": {"S": "Apple"},"time": {"S": now}}) return data ``` **注記** DynamoDB クライアントがインスタンス化されると、テーブル名の代わりに DynamoDB テーブルの ARN が提供されます。これは、Lambda 関数が実行時に正しい DynamoDB テーブルに接続するために必要です。 # AWS 上の SQL Server の Always On アベイラビリティグループで読み取り専用ルーティングを構成する *Subhani Shaik (Amazon Web Services)* ## 概要 このパターンでは、読み取り専用ワークロードをプライマリレプリカからセカンダリレプリカにオフロードすることで、SQL Server Always On のスタンバイセカンダリレプリカを使用する方法について説明します。 データベースミラーリングには 1 対 1 のマッピングがあります。セカンダリデータベースを直接読み取ることはできないため、スナップショットを作成する必要があります。Always On アベイラビリティグループ機能は Microsoft SQL Server 2012 で導入されました。それ以降のバージョンでは、読み取り専用ルーティングなどの主要な機能が導入されています。Always On アベイラビリティグループでは、レプリカモードを読み取り専用に変更することで、セカンダリレプリカからデータを直接読み取ることができます。 Always On アベイラビリティグループソリューションは、高アベイラビリティ (HA)、ディザスタリカバリ (DR)、およびデータベースミラーリングの代替手段をサポートします。Always On アベイラビリティグループはデータベースレベルで機能し、一連のユーザーデータベースのアベイラビリティを最大化します。 SQL Server は読み取り専用ルーティングメカニズムを使用して、受信した読み取り専用接続をセカンダリ読み取りレプリカにリダイレクトします。そのためには、接続文字列に次のパラメータと値を追加する必要があります。 + `ApplicationIntent=ReadOnly` + `Initial Catalog=` ## 前提条件と制限 **前提条件** + 仮想プライベートクラウド (VPC)、2つのアベイラビリティーゾーン、プライベートサブネット、およびセキュリティグループを使用するアクティブな AWS アカウント + [SQL Server 2019 Enterprise Edition Amazon Machine Image](https://aws.amazon.com/marketplace/pp/prodview-btjcozd246p6w) を搭載し、[インスタンスレベルで構成された Windows サーバーフェイルオーバークラスター (WSFC)](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/ec2-fci.html) 機能、AWS Directory Service for Microsoft Active Directory の `tagechtalk.com` という名のディレクトリの一部であるプライマリノード (`WSFCNODE1`) とセカンダリノード (`WSFCNODE2`) 間のSQL Server レベルで構成された Always On アベイラビリティグループを備えた 2 台のAmazon Elastic Compute Cloud (Amazon EC2) マシン + セカンダリレプリカで `read-only` を許可するように構成された 1 つ以上のノード + Always On アベイラビリティグループに対して `SQLAG1` と名付けられたリスナー + 2 つのノードに対して同じサービスアカウントで実行されている SQL Server データベースエンジン + SQL Server Management Studio (SSMS) + `test` という名のテストデータベース **製品バージョン** + SQL Server 2014 およびそれ以降 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EC2 + AWS Managed Microsoft AD + Windows **ターゲットアーキテクチャ** 次の図は、Always On アベイラビリティグループ (AG) リスナーが、接続内に `ApplicationIntent` パラメータを含むクエリを適切なセカンダリノードにリダイレクトする方法を示しています。 ![\[Amazon EFS を使用したノード 1 WSFC とノード 2 WSFC の 2 つのアベイラビリティーゾーン間の 3 つのステッププロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/19b5937b-da10-4c74-8619-fdcb758f2211/images/f9ba0f89-7dc2-4f4c-8eee-bef56968ad2d.png) 1. Always On アベイラビリティグループリスナーにリクエストが送信されます。 1. 接続文字列に `ApplicationIntent` パラメータがない場合、リクエストはプライマリインスタンスに送信されます。 1. 接続文字列に `ApplicationIntent=ReadOnly` が含まれる場合、リクエストは読み取り専用ルーティング構成でセカンダリインスタンス、つまり Always On アベイラビリティグループの WSFC に送信されます。 ## ツール ** サービス** + [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) により、ディレクトリ対応型ワークロードと AWS リソースが、AWS クラウドの Microsoft Active Directory を使用できるようになります。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 + [Amazon FSx](https://docs.aws.amazon.com/fsx/?id=docs_gateway) は、業界標準の接続プロトコルをサポートし、AWS リージョン全体で高いアベイラビリティとレプリケーションを提供するファイルシステムを提供します。 **その他のサービス** + SQL Server Management Studio (SSMS) は、SQL Server インスタンスを接続、管理、および管理するためのツールです。 + sqlcmd はコマンドラインユーティリティです。 ## ベストプラクティス Always On アベイラビリティグループの詳細については、[SQL Server ドキュメント](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver16)を参照してください。 ## エピック ### 読み取り専用ルーティングの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | レプリカを読み取り専用に更新します。 | プライマリレプリカとセカンダリレプリカの両方を読み取り専用に更新するには、SSMS からプライマリレプリカに接続し、「*追加情報*」セクションの*ステップ 1* コードを実行します。 | DBA | | ルーティング URL を作成する。 | 両方のレプリカのルーティング URL を作成するには、「*追加情報*」セクションの*ステップ 2* コードを実行します。このコードでは、`tagechtalk.com` は AWS Managed Microsoft AD ディレクトリの名前です。 | DBA | | ルーティングリストを作成する。 | 両方のレプリカのルーティングリストを作成するには、「*追加情報*」セクションのステップ 3 コードを実行します。 | DBA | | ルーティングリストを検証します。 | SQL Server Management Studio からプライマリインスタンスに接続し、「*追加情報*」セクションの*ステップ 4* コードを実行してルーティングリストを検証します。 | DBA | ### 読み取り専用ルーティングのテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ApplicationIntent パラメータを使用して接続します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-read-only-routing-in-an-always-on-availability-group-in-sql-server-on-aws.html) | DBA | | フェイルオーバーを実行する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/configure-read-only-routing-in-an-always-on-availability-group-in-sql-server-on-aws.html) | DBA | ### sqlcmd コマンドラインユーティリティを使用して接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | sqlcmd を使用して接続します。 | sqlcmd から接続するには、コマンドプロンプトの [*追加情報*] セクションから*ステップ 5* のコードを実行します。接続後、次のコマンドを実行して、接続されているサーバー名を表示します。
SELECT SERVERPROPERTY('ComputernamePhysicalNetBios') .
出力には現在のセカンダリレプリカ名 (`WSFCNODE1`) が表示されます。 | DBA | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | リスナーの作成が失敗し、「WSFC クラスターはネットワーク名リソースをオンラインにできませんでした」というメッセージが表示された。 | 詳細については、Microsoft のブログ記事「[リスナーの作成が失敗し、「WSFCクラスターはネットワーク名リソースをオンラインにできませんでした」というメッセージが表示される](https://techcommunity.microsoft.com/t5/sql-server-support-blog/create-listener-fails-with-message-the-wsfc-cluster-could-not/ba-p/318235)」を参照してください。 | | 他のリスナーの問題やネットワークアクセスの問題などの潜在的な問題。 | Microsoft ドキュメントの「[Always On アベイラビリティグループ構成のトラブルシューティング (SQL Server)](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/troubleshoot-always-on-availability-groups-configuration-sql-server?view=sql-server-ver16)」を参照してください。 | ## 関連リソース + [Always On アベイラビリティグループの読み取り専用ルーティングの構成](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-read-only-routing-for-an-availability-group-sql-server?view=sql-server-ver16) + [Always On アベイラビリティグループ構成のトラブルシューティング (SQL Server)](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/troubleshoot-always-on-availability-groups-configuration-sql-server?view=sql-server-ver16) ## 追加情報 **ステップ 1. レプリカを読み取り専用に更新する** ``` ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE1' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)) GO ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE2' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)) GO ``` **ステップ 2. ルーティング URL を作成する** ``` ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE1' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://WSFCNode1.tagechtalk.com:1433')) GO ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE2' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://WSFCNode2.tagechtalk.com:1433')) GO ``` **ステップ 3. ルーティングリストを作成する** ``` ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE1' WITH (PRIMARY_ROLE(READ_ONLY_ROUTING_LIST=('WSFCNODE2','WSFCNODE1'))); GO ALTER AVAILABILITY GROUP [SQLAG1] MODIFY REPLICA ON N'WSFCNODE2' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('WSFCNODE1','WSFCNODE2'))); GO ``` **Step 4. ルーティングリストを検証する** ``` SELECT AGSrc.replica_server_name AS PrimaryReplica, AGRepl.replica_server_name AS ReadOnlyReplica, AGRepl.read_only_routing_url AS RoutingURL , AGRL.routing_priority AS RoutingPriority FROM sys.availability_read_only_routing_lists AGRL INNER JOIN sys.availability_replicas AGSrc ON AGRL.replica_id = AGSrc.replica_id INNER JOIN sys.availability_replicas AGRepl ON AGRL.read_only_replica_id = AGRepl.replica_id INNER JOIN sys.availability_groups AV ON AV.group_id = AGSrc.group_id ORDER BY PrimaryReplica ``` **ステップ 5. SQL コマンドユーティリティ** ``` sqlcmd -S SQLAG1,1433 -E -d test -K ReadOnly ``` # pgAdmin の SSH トンネルを使用して接続 *Jeevan Shetty、Bhanu Ganesh Gudivada (Amazon Web Services)* ## 概要 セキュリティの原因で、データベースをプライベートサブネットに配置することは常に良いことです。データベースに対するクエリは、Amazon Web Services (AWS) クラウドのパブリックサブネットにある Amazon Elastic Compute Cloud (Amazon EC2) 要塞ホストを介して接続することにより実行できます。これには、開発者やデータベース管理者が一般的に使用する pgAdmin や DBeaver などのソフトウェアを Amazon EC2 ホストにインストールする必要があります。 Linux サーバーで pgAdmin を実行し、ウェブブラウザーからアクセスするには、追加の依存関係のインストール、権限の設定、および構成が必要です。 代替のソリューションとして、開発者またはデータベース管理者は pgAdmin を使用して PostgreSQL データベースに接続し、ローカルシステムから SSH トンネルを有効化します。このアプローチでは、pgAdmin はデータベースに接続する前に、パブリックサブネットの Amazon EC2 ホストを仲介ホストとして使用します。「*アーキテクチャ*」セクションの図は、この設定を示します。 **注記** PostgreSQL データベースにアタッチされたセキュリティグループが Amazon EC2 ホストからのポート 5432 での接続を許可していることを確保します。 ## 前提条件と制限事項 **前提条件** + 既存の AWS アカウント + パブリックサブネットとプライベートサブネットを備えた、仮想プライベートクラウド (VPC) + セキュリティグループがアタッチされた EC2 インスタンス + セキュリティグループがアタッチされた Amazon Aurora PostgreSQL 互換エディションデータベース + トンネルをセットアップするための Secure Shell (SSH) キーペア **製品バージョン** + pgAdmin バージョン 6.2\$1 + Amazon Aurora PostgreSQL 互換エディションバージョン 12.7\$1 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EC2 + Amazon Aurora PostgreSQL 互換 **ターゲットアーキテクチャ** 次の図表では、pgAdmin と SSH トンネルを使用して、インターネットゲートウェイ経由で EC2 インスタンスに接続し、そのEC2 インスタンスがデータベースに接続する方法を示しています。 ![\[SSH トンネルを使用した pgAdmin は、インターネットゲートウェイを介して、データベースに接続する EC2 インスタンスに接続します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7d25d570-5685-4f1a-bef0-212e257cb589/images/4556d930-f9b3-4b65-be5d-d40dd9437d5a.png) ## ツール **AWS サービス** + 「[Amazon Aurora PostgreSQL 互換エディション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)」は、PostgreSQL デプロイのセットアップ、運用、スケーリングに役立つ、フルマネージド型のACID準拠のリレーショナルデータベースエンジンです。 + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 **その他のサービス** + 「[pgAdmin](https://www.pgadmin.org/)」は、PostgreSQLのオープンソース管理ツールです。データベースオブジェクトの作成、管理、使用を支援するグラフィカルインターフェイスを提供します。 ## エピック ### 接続を作成するには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サーバーを作成 | pgAdmin で**作成**を選択し、次に**サーバー**を選択します。サーバーを登録し、接続を設定し、サーバーダイアログを使用して SSH トンネリング経由で接続する pgAdmin の設定に関するその他のヘルプについては、「*関連リソース*」セクションのリンクを参照してください。 | DBA | | サーバーの名前を入力します。 | ［**一般**］タブで、名前を入力します。 | DBA | | データベースの詳細を入力します。 | ［**接続タブ**］で、次の値を入力します：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-by-using-an-ssh-tunnel-in-pgadmin.html) | DBA | | Amazon EC2 サーバーの詳細を入力します。 | ［**SSH トンネル**］タブで、パブリックサブネットにある Amazon EC2 インスタンスの詳細を指定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/connect-by-using-an-ssh-tunnel-in-pgadmin.html) | DBA | | 保存して接続します。 | ［**保存**］を選択してセットアップを完了し、次に SSH トンネルを使用して Aurora PostgreSQL 互換データベースに接続します。 | DBA | ## 関連リソース + 「[サーバーダイアログ](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html)」 + 「[DNS サーバーに接続する](https://www.pgadmin.org/docs/pgadmin4/latest/connect_to_server.html)」 # JSON Oracleクエリを PostgreSQL データベース SQL に変換 *Pinesh Singal、Lokesh Gurram (Amazon Web Services)* ## 概要 オンプレミスからAmazon Web Services (AWS) クラウドに移行するためのこの移行プロセスでは、AWS Schema Conversion Tool (AWS SCT) を使用して Oracle データベースのコードを PostgreSQL データベースに変換します。ほとんどのコードは AWS SCT によって自動的に変換されます。ただし、JSON 関連の Oracle クエリは自動的に変換されません。 Oracle 12.2 バージョン以降、Oracle Database は JSON ベースのデータを行ベースのデータに変換するのに役立つさまざまな JSON 関数をサポートしています。ただし、AWS SCT は JSON ベースのデータを PostgreSQL でサポートされている言語に自動的に変換しません。 この移行パターンは、主に、`JSON_OBJECT`、`JSON_ARRAYAGG`、`JSON_TABLE`などの関数を使用する JSON 関連の Oracle クエリを Oracle データベースから PostgreSQL データベースに手動で変換することに重点を置いています。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント。 + オンプレミスの Oracle データベースインスタンス (稼働中) + PostgreSQL または Amazon Aurora PostgreSQL 互換エディションデータベースインスタンス (稼働中) の Amazon Relational Database Service (Amazon RDS) **制限事項** + JSON 関連のクエリには、固定の`KEY`と`VALUE`形式が必要です。この形式を使用しないと、間違った結果が返されます。 + JSON構造の変更により、結果セクションに新しい`KEY`と`VALUE`のペアが追加された場合、SQLクエリで対応するプロシージャまたは関数を変更する必要があります。 + JSON 関連の関数の中には、以前のバージョンの Oracle と PostgreSQL でサポートされていますが、機能が少ないものもあります。 **製品バージョン** + インメモリデータベース (バージョン 12.1 以降) + Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換バージョン 9.5 以降 + AWS SCT 最新バージョン (バージョン 1.0.664 を使用してテスト済み) ## アーキテクチャ **ソーステクノロジースタック** + バージョン 19c の Oracle データベースインスタンス **ターゲットテクノロジースタック** + Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換データベースインスタンス (バージョン 13) **ターゲットアーキテクチャ** ![\[説明は図のとおりです。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5e2c3b07-9ef5-417f-b049-bcea58f2c3ec/images/2ff8b00b-8849-4ef1-9be1-579f7b51be10.png) 1. AWS SCT と JSON 関数コードを使用して、ソースコードを Oracle から PostgreSQL に変換します。 1. この変換により、PostgreSQL がサポートするマイグレーションされた.sql ファイルが生成されます。 1. 変換されていない Oracle JSON ファンクションコードを PostgreSQL JSON ファンクションコードに手動で変換します。 1. ターゲット Aurora PostgreSQL 互換の DB インスタンスで.sql ファイルを実行します。 ## ツール **AWS サービス** + [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html) はフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + 「[AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html)」は、ソースデータベーススキーマとカスタムコードの大部分をターゲットデータベースと互換性のある形式に自動的に変換することで、異種データベース移行をサポートします。 **その他のサービス** + 「[Oracle SQL Developer](https://www.oracle.com/database/technologies/appdev/sqldeveloper-landing.html)」は、従来のデプロイとクラウドベースのデプロイの両方で Oracle データベースの開発と管理を簡素化する統合開発環境です。 + pgAdminまたはDBeaver。「[pgAdmin](https://www.pgadmin.org/)」はPostgreSQL用のオープンソース管理ツールです。データベースオブジェクトの作成、管理、使用を支援するグラフィカルインターフェイスを提供します。「[DBeaver](https://dbeaver.io/)」は汎用データベースツールです。 ## ベストプラクティス Oracle・クエリでは、この`JSON_TABLE`関数を使用する場合、デフォルトで`CAST`タイプが使用されます。ベストプラクティスは、PostgreSQLでも`CAST`を使用し、二重の大なり文字(`>>`)を使用することです。 詳細については、「*追加情報*」セクションの「*Postgres\$1SQL\$1read\$1JSON*」を参照してください。 ## エピック ### Oracle データベースと PostgreSQL データベースに JSON データを生成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | JSON データを Oracle データベースに保存します。 | Oracle データベースにテーブルを作成し、その`CLOB`列に JSON データを格納します。 「*追加情報*」セクションにある「*Oracle\$1Table\$1Creation\$1Insert\$1Script*」を使用してください。 | 移行エンジニア | | JSON データを PostgreSQL データベースに保存します。 | PostgreSQL データベースにテーブルを作成し、その`TEXT`列に JSON データを格納します。「*追加情報*」セクションにある「*Postgres\$1Table\$1Creation\$1Insert\$1Script*」を使用してください。 | 移行エンジニア | ### JSON を行形式に変換します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle データベースの JSON データを変換します。 | JSON データを行フォーマットに読み込むための Oracle SQL クエリを記述します。詳細と構文例については、「*追加情報*」セクションの「*Oracle\$1SQL\$1READ\$1JSON*」を参照してください。 | 移行エンジニア | | PostgreSQL データベース上の JSON データを変換します。 | JSON データを ROW フォーマットに読み込むための PostgreSQL クエリを記述します。詳細と構文例については、「*追加情報*」セクションの「*Postgres\$1SQL\$1Read\$1JSON*」を参照してください。 | 移行エンジニア | ### SQL クエリを使用して JSON データを手動で変換し、JSON 形式で出力を報告します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle SQL クエリの集計と検証を行います。 | JSON データを手動で変換するには、Oracle SQL クエリで結合、集約、検証を実行し、出力を JSON 形式でレポートします。「*追加情報*」セクションの「*Oracle\$1SQL\$1JSON\$1Aggregation\$1Join*」にあるコードを使用してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/convert-json-oracle-queries-into-postgresql-database-sql.html) | 移行エンジニア | | Postgres SQL クエリの集計と検証を行います。 | JSON データを手動で変換するには、PostgreSQL クエリで結合、集約、検証を実行し、出力を JSON 形式でレポートします。「*追加情報*」セクションの「*Postgres\$1SQL\$1JSON\$1Aggregation\$1Join*」にあるコードを使用してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/convert-json-oracle-queries-into-postgresql-database-sql.html) | 移行エンジニア | ### Oracle プロシージャを JSON クエリを含む PostgreSQL 関数に変換します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle プロシージャ内の JSON クエリを行に変換します。 | サンプル Oracle プロシージャでは、前述の Oracle クエリと、「*追加情報*」セクションの「*oracle\$1Procedure\$1With\$1Json\$1Query*」にあるコードを使用してください。 | 移行エンジニア | | JSON クエリを含む PostgreSQL 関数を行ベースのデータに変換します。 | PostgreSQL 関数の例については、以前の PostgreSQL クエリと、「*追加情報*」セクションの「*Postgres\$1function\$1with\$1Json\$1Query*」にあるコードを使用してください。 | 移行エンジニア | ## 関連リソース + [Oracle JSON 関数](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/adjsn/generation.html) + [PostgreSQL JSON 関数](https://www.postgresql.org/docs/13/functions-json.html) + [Oracle JSON 関数の例](https://oracle-base.com/articles/12c/sql-json-functions-12cr2) + [PostgreSQL JSON 関数の例](https://dba.stackexchange.com/questions/69655/select-columns-inside-json-agg) + [AWS Schema Conversion Tool](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) ## 追加情報 JSON コードを Oracle データベースから PostgreSQL データベースに変換するには、次のスクリプトを順番に使用してください。 **1. Oracle\$1Table\$1Creation\$1Insert\$1Script** ``` create table aws_test_table(id number,created_on date default sysdate,modified_on date,json_doc clob); REM INSERTING into EXPORT_TABLE SET DEFINE OFF; Insert into aws_test_table (ID,CREATED_ON,MODIFIED_ON,json_doc) values (1,to_date('02-AUG-2022 12:30:14','DD-MON-YYYY HH24:MI:SS'),to_date('02-AUG-2022 12:30:14','DD-MON-YYYY HH24:MI:SS'),TO_CLOB(q'[{ "metadata" : { "upperLastNameFirstName" : "ABC XYZ", "upperEmailAddress" : "abc@gmail.com", "profileType" : "P" }, "data" : { "onlineContactId" : "032323323", "displayName" : "Abc, Xyz", "firstName" : "Xyz", "lastName" : "Abc", "emailAddress" : "abc@gmail.com", "productRegistrationStatus" : "Not registered", "positionId" : "0100", "arrayPattern" : " -'", "a]') || TO_CLOB(q'[ccount" : { "companyId" : "SMGE", "businessUnitId" : 7, "accountNumber" : 42000, "parentAccountNumber" : 32000, "firstName" : "john", "lastName" : "doe", "street1" : "retOdertcaShr ", "city" : "new york", "postalcode" : "XY ABC", "country" : "United States" }, "products" : [ { "appUserGuid" : "i0acc4450000001823fbad478e2eab8a0", "id" : "0000000046", ]') || TO_CLOB(q'[ "name" : "ProView", "domain" : "EREADER", "registrationStatus" : false, "status" : "11" } ] } }]')); Insert into aws_test_table (ID,CREATED_ON,MODIFIED_ON,json_doc) values (2,to_date('02-AUG-2022 12:30:14','DD-MON-YYYY HH24:MI:SS'),to_date('02-AUG-2022 12:30:14','DD-MON-YYYY HH24:MI:SS'),TO_CLOB(q'[{ "metadata" : { "upperLastNameFirstName" : "PQR XYZ", "upperEmailAddress" : "pqr@gmail.com", "profileType" : "P" }, "data" : { "onlineContactId" : "54534343", "displayName" : "Xyz, pqr", "firstName" : "pqr", "lastName" : "Xyz", "emailAddress" : "pqr@gmail.com", "productRegistrationStatus" : "Not registered", "positionId" : "0090", "arrayPattern" : " -'", "account" : { "companyId" : "CARS", "busin]') || TO_CLOB(q'[essUnitId" : 6, "accountNumber" : 42001, "parentAccountNumber" : 32001, "firstName" : "terry", "lastName" : "whitlock", "street1" : "UO 123", "city" : "TOTORON", "region" : "NO", "postalcode" : "LKM 111", "country" : "Canada" }, "products" : [ { "appUserGuid" : "ia744d7790000016899f8cf3f417d6df6", "id" : "0000000014", "name" : "ProView eLooseleaf", ]') || TO_CLOB(q'[ "domain" : "EREADER", "registrationStatus" : false, "status" : "11" } ] } }]')); commit; ``` **2。Postgres\$1テーブル\$1作成\$1挿入\$1スクリプト** ``` create table aws_test_pg_table(id int,created_on date ,modified_on date,json_doc text); insert into aws_test_pg_table(id,created_on,modified_on,json_doc) values(1,now(),now(),'{ "metadata" : { "upperLastNameFirstName" : "ABC XYZ", "upperEmailAddress" : "abc@gmail.com", "profileType" : "P" }, "data" : { "onlineContactId" : "032323323", "displayName" : "Abc, Xyz", "firstName" : "Xyz", "lastName" : "Abc", "emailAddress" : "abc@gmail.com", "productRegistrationStatus" : "Not registered", "positionId" : "0100", "arrayPattern" : " -", "account" : { "companyId" : "SMGE", "businessUnitId" : 7, "accountNumber" : 42000, "parentAccountNumber" : 32000, "firstName" : "john", "lastName" : "doe", "street1" : "retOdertcaShr ", "city" : "new york", "postalcode" : "XY ABC", "country" : "United States" }, "products" : [ { "appUserGuid" : "i0acc4450000001823fbad478e2eab8a0", "id" : "0000000046", "name" : "ProView", "domain" : "EREADER", "registrationStatus" : false, "status" : "11" } ] } }'); insert into aws_test_pg_table(id,created_on,modified_on,json_doc) values(2,now(),now(),'{ "metadata" : { "upperLastNameFirstName" : "PQR XYZ", "upperEmailAddress" : "pqr@gmail.com", "profileType" : "P" }, "data" : { "onlineContactId" : "54534343", "displayName" : "Xyz, pqr", "firstName" : "pqr", "lastName" : "Xyz", "emailAddress" : "a*b**@h**.k**", "productRegistrationStatus" : "Not registered", "positionId" : "0090", "arrayPattern" : " -", "account" : { "companyId" : "CARS", "businessUnitId" : 6, "accountNumber" : 42001, "parentAccountNumber" : 32001, "firstName" : "terry", "lastName" : "whitlock", "street1" : "UO 123", "city" : "TOTORON", "region" : "NO", "postalcode" : "LKM 111", "country" : "Canada" }, "products" : [ { "appUserGuid" : "ia744d7790000016899f8cf3f417d6df6", "id" : "0000000014", "name" : "ProView eLooseleaf", "domain" : "EREADER", "registrationStatus" : false, "status" : "11" } ] } }'); ``` **3. Oracle \$1SQL\$1Read\$1JSON** 次のコードブロックは、Oracle JSON データを行形式に変換する方法を示しています。 クエリと構文の例 ``` SELECT JSON_OBJECT( 'accountCounts' VALUE JSON_ARRAYAGG( JSON_OBJECT( 'businessUnitId' VALUE business_unit_id, 'parentAccountNumber' VALUE parent_account_number, 'accountNumber' VALUE account_number, 'totalOnlineContactsCount' VALUE online_contacts_count, 'countByPosition' VALUE JSON_OBJECT( 'taxProfessionalCount' VALUE tax_count, 'attorneyCount' VALUE attorney_count, 'nonAttorneyCount' VALUE non_attorney_count, 'clerkCount' VALUE clerk_count ) ) ) ) FROM (SELECT tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number, SUM(1) online_contacts_count, SUM(CASE WHEN tab_data.position_id = '0095' THEN 1 ELSE 0 END) tax_count, SUM(CASE WHEN tab_data.position_id = '0100' THEN 1 ELSE 0 END) attorney_count, SUM(CASE WHEN tab_data.position_id = '0090' THEN 1 ELSE 0 END) non_attorney_count, SUM(CASE WHEN tab_data.position_id = '0050' THEN 1 ELSE 0 END) clerk_count FROM aws_test_table scco,JSON_TABLE ( json_doc, '$' ERROR ON ERROR COLUMNS ( parent_account_number NUMBER PATH '$.data.account.parentAccountNumber', account_number NUMBER PATH '$.data.account.accountNumber', business_unit_id NUMBER PATH '$.data.account.businessUnitId', position_id VARCHAR2 ( 4 ) PATH '$.data.positionId' ) ) AS tab_data INNER JOIN JSON_TABLE ( '{ "accounts": [{ "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }, { "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }] }', '$.accounts[*]' ERROR ON ERROR COLUMNS ( parent_account_number PATH '$.parentAccountNumber', account_number PATH '$.accountNumber', business_unit_id PATH '$.businessUnitId') ) static_data ON ( static_data.parent_account_number = tab_data.parent_account_number AND static_data.account_number = tab_data.account_number AND static_data.business_unit_id = tab_data.business_unit_id ) GROUP BY tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number ); ``` JSON ドキュメントはデータをコレクションとして保存します。各コレクションは`KEY`と`VALUE`のペアを持つことができます。すべての`VALUE`は、入れ子になっている`KEY`と`VALUE`のペアを持つことができます。以下の表は、JSON文書から特定の`VALUE`を読み取るための情報を提供します。 | | | キー | 値の取得に使用する階層またはパス | 値 | | --- |--- |--- | | `profileType` | `metadata` -> `profileType` | P | | `positionId` | `data` -> `positionId` | 0100 | | `accountNumber` | `data` -> account -> `accountNumber` | 42000 | 前の表では、`KEY``profileType`は`metadata``KEY`の`VALUE`です。`KEY``positionId`は`data``KEY`の`VALUE`です。`KEY``accountNumber`は`account``KEY`の`VALUE`、`account``KEY`は`data``KEY`の`VALUE`です。 *JSON ドキュメントの例* ``` { "metadata" : { "upperLastNameFirstName" : "ABC XYZ", "upperEmailAddress" : "abc@gmail.com", "profileType" : "P" }, "data" : { "onlineContactId" : "032323323", "displayName" : "Abc, Xyz", "firstName" : "Xyz", "lastName" : "Abc", "emailAddress" : "abc@gmail.com", "productRegistrationStatus" : "Not registered", "positionId" : "0100", "arrayPattern" : " -", "account" : { "companyId" : "SMGE", "businessUnitId" : 7, "accountNumber" : 42000, "parentAccountNumber" : 32000, "firstName" : "john", "lastName" : "doe", "street1" : "retOdertcaShr ", "city" : "new york", "postalcode" : "XY ABC", "country" : "United States" }, "products" : [ { "appUserGuid" : "i0acc4450000001823fbad478e2eab8a0", "id" : "0000000046", "name" : "ProView", "domain" : "EREADER", "registrationStatus" : false, "status" : "11" } ] } } ``` *JSON ドキュメントから選択したフィールドを取得するために使用される SQL クエリ* ``` select parent_account_number,account_number,business_unit_id,position_id from aws_test_table aws,JSON_TABLE ( json_doc, '$' ERROR ON ERROR COLUMNS ( parent_account_number NUMBER PATH '$.data.account.parentAccountNumber', account_number NUMBER PATH '$.data.account.accountNumber', business_unit_id NUMBER PATH '$.data.account.businessUnitId', position_id VARCHAR2 ( 4 ) PATH '$.data.positionId' )) as sc ``` 前のクエリでは、`JSON_TABLE`は JSON データを行形式に変換する Oracle の組み込み関数です。JSON\$1TABLE 関数には、JSON 形式のパラメータが必要です。 `COLUMNS`の各項目はあらかじめ定義された`PATH`を持ち、そこで与えられた`KEY`に適切な`VALUE`が行の形式で返されます。 *前のクエリの結果* | | | 親口座番号 | 口座番号 | ビジネスユニット ID | ポジション ID | | --- |--- |--- |--- | | 32000 | 42000 | 7 | 0100 | | 32001 | 42001 | 6 | 0090 | **4. Postgres\$1sql\$1read\$1JSON** ****クエリと構文の例 ``` select * from ( select (json_doc::json->'data'->'account'->>'parentAccountNumber')::INTEGER as parentAccountNumber, (json_doc::json->'data'->'account'->>'accountNumber')::INTEGER as accountNumber, (json_doc::json->'data'->'account'->>'businessUnitId')::INTEGER as businessUnitId, (json_doc::json->'data'->>'positionId')::VARCHAR as positionId from aws_test_pg_table) d ; ``` Oracle では、`PATH`は特定の`KEY`および`VALUE`を識別するために使用されます。しかし、PostgreSQLはJSONから`KEY`と`VALUE`を読み取るために`HIERARCHY`モデルを使用します。`Oracle_SQL_Read_JSON`で述べたのと同じJSONデータが、以下の例でも使われています。 *CAST タイプの SQL クエリは使用できない* (強制的に`CAST`と入力すると、クエリは失敗し、構文エラーが発生します)。 ``` select * from ( select (json_doc::json->'data'->'account'->'parentAccountNumber') as parentAccountNumber, (json_doc::json->'data'->'account'->'accountNumber')as accountNumber, (json_doc::json->'data'->'account'->'businessUnitId') as businessUnitId, (json_doc::json->'data'->'positionId')as positionId from aws_test_pg_table) d ; ``` 大なり演算子(`>`)を1つ使うと、その`KEY`に定義された`VALUE`が返されます。例： `KEY`: `positionId`、そして `VALUE`: `"0100"` 1 つの大なり演算子 (`>`) を使用する場合、`CAST`型は使用できません。 *CAST 型の SQL クエリは許可されます* ``` select * from ( select (json_doc::json->'data'->'account'->>'parentAccountNumber')::INTEGER as parentAccountNumber, (json_doc::json->'data'->'account'->>'accountNumber')::INTEGER as accountNumber, (json_doc::json->'data'->'account'->>'businessUnitId')::INTEGER as businessUnitId, (json_doc::json->'data'->>'positionId')::varchar as positionId from aws_test_pg_table) d ; ``` タイプ`CAST`を使用するには、二重大なり演算子を使用する必要があります。1 つの大なり演算子を使用すると、クエリは定義された`VALUE`を返します (例えば`KEY`：`positionId`、および`VALUE`：`"0100"`) を返します。二重大なり演算子 (`>>`) を使用すると、その`KEY`に定義されている実際の値(二重引用符なしの`KEY`：`positionId`、および`VALUE`：`0100`など) が返されます。 前のケースでは、`parentAccountNumber`は`INT`に`CAST`と入力し、`accountNumber`は`INT`に`CAST`と入力し、`businessUnitId`は`INT`に`CAST`と入力し、`positionId`は`VARCHAR`に`CAST`と入力します。 次の表は、1 つの大なり演算子 (`>`) と二重大なり演算子 (`>>`) の役割を説明するクエリ結果を示しています。 最初の表のクエリでは、1 つの大なり演算子 (`>`) を使用しています。各列は JSON 型で、別のデータ型に変換することはできません。 | | | 親アカウント番号 | AccountNumber | ビジネスユニット ID | ポジション ID | | --- |--- |--- |--- | | 2003565430 | 2003564830 | 7 | 0100 | | 2005284042 | 2005284042 | 6 | 0090 | | 2000272719 | 2000272719 | 1 | 0100 | 2 番目のテーブルでは、クエリは二重大なり演算子 (`>>`) を使用しています。各列は列の値に基づいて`CAST`型をサポートします。たとえば、この場合は `INTEGER` と指定します。 | | | 親アカウント番号 | AccountNumber | ビジネスユニット ID | ポジション ID | | --- |--- |--- |--- | | 2003565430 | 2003564830 | 7 | 0100 | | 2005284042 | 2005284042 | 6 | 0090 | | 2000272719 | 2000272719 | 1 | 0100 | **5。Oracle\$1SQL\$1JSON \$1Aggregation\$1Join** サンプルクエリ ``` SELECT JSON_OBJECT( 'accountCounts' VALUE JSON_ARRAYAGG( JSON_OBJECT( 'businessUnitId' VALUE business_unit_id, 'parentAccountNumber' VALUE parent_account_number, 'accountNumber' VALUE account_number, 'totalOnlineContactsCount' VALUE online_contacts_count, 'countByPosition' VALUE JSON_OBJECT( 'taxProfessionalCount' VALUE tax_count, 'attorneyCount' VALUE attorney_count, 'nonAttorneyCount' VALUE non_attorney_count, 'clerkCount' VALUE clerk_count ) ) ) ) FROM (SELECT tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number, SUM(1) online_contacts_count, SUM(CASE WHEN tab_data.position_id = '0095' THEN 1 ELSE 0 END) tax_count, SUM(CASE WHEN tab_data.position_id = '0100' THEN 1 ELSE 0 END) attorney_count, SUM(CASE WHEN tab_data.position_id = '0090' THEN 1 ELSE 0 END) non_attorney_count, SUM(CASE WHEN tab_data.position_id = '0050' THEN 1 ELSE 0 END) clerk_count FROM aws_test_table scco,JSON_TABLE ( json_doc, '$' ERROR ON ERROR COLUMNS ( parent_account_number NUMBER PATH '$.data.account.parentAccountNumber', account_number NUMBER PATH '$.data.account.accountNumber', business_unit_id NUMBER PATH '$.data.account.businessUnitId', position_id VARCHAR2 ( 4 ) PATH '$.data.positionId' ) ) AS tab_data INNER JOIN JSON_TABLE ( '{ "accounts": [{ "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }, { "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }] }', '$.accounts[*]' ERROR ON ERROR COLUMNS ( parent_account_number PATH '$.parentAccountNumber', account_number PATH '$.accountNumber', business_unit_id PATH '$.businessUnitId') ) static_data ON ( static_data.parent_account_number = tab_data.parent_account_number AND static_data.account_number = tab_data.account_number AND static_data.business_unit_id = tab_data.business_unit_id ) GROUP BY tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number ); ``` 行レベルのデータを JSON 形式に変換するために、Oracle には、`JSON_OBJECT`、`JSON_ARRAY`、`JSON_OBJECTAGG`、`JSON_ARRAYAGG`などの組み込み関数があります。 + `JSON_OBJECT`は、`KEY`と`VALUE`の 2 つのパラメータを受け入れます。`KEY`パラメータは本質的にハードコーディングされているか、静的である必要があります。`VALUE`パラメータはテーブル出力から導出されます。 + `JSON_ARRAYAGG`は`JSON_OBJECT`をパラメーターとして受け入れます。これにより、`JSON_OBJECT`要素のセットをリストとしてグループ化できます。たとえば、複数のレコード (データセット内の複数の`KEY`と`VALUE`ペア) を持つ`JSON_OBJECT`要素がある場合、`JSON_ARRAYAGG`はデータセットを追加してリストを作成します。データ構造言語によると、`LIST`は要素のグループです。このコンテキストでは、`LIST`は`JSON_OBJECT`要素のグループです。 次の例は、1 つの`JSON_OBJECT`要素を示しています。 ``` { "taxProfessionalCount": 0, "attorneyCount": 0, "nonAttorneyCount": 1, "clerkCount": 0 } ``` 次の例には、2 つの`JSON_OBJECT`要素が示され、`LIST`が角括弧 (`[ ]`) で示されています。 ``` [ { "taxProfessionalCount": 0, "attorneyCount": 0, "nonAttorneyCount": 1, "clerkCount": 0 } , { "taxProfessionalCount": 2, "attorneyCount": 1, "nonAttorneyCount": 3, "clerkCount":4 } ] ``` *SQL クエリの例* ``` SELECT JSON_OBJECT( 'accountCounts' VALUE JSON_ARRAYAGG( JSON_OBJECT( 'businessUnitId' VALUE business_unit_id, 'parentAccountNumber' VALUE parent_account_number, 'accountNumber' VALUE account_number, 'totalOnlineContactsCount' VALUE online_contacts_count, 'countByPosition' VALUE JSON_OBJECT( 'taxProfessionalCount' VALUE tax_count, 'attorneyCount' VALUE attorney_count, 'nonAttorneyCount' VALUE non_attorney_count, 'clerkCount' VALUE clerk_count ) ) ) ) FROM (SELECT tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number, SUM(1) online_contacts_count, SUM(CASE WHEN tab_data.position_id = '0095' THEN 1 ELSE 0 END ) tax_count, SUM(CASE WHEN tab_data.position_id = '0100' THEN 1 ELSE 0 END ) attorney_count, SUM(CASE WHEN tab_data.position_id = '0090' THEN 1 ELSE 0 END ) non_attorney_count, SUM(CASE WHEN tab_data.position_id = '0050' THEN 1 ELSE 0 END ) clerk_count FROM aws_test_table scco, JSON_TABLE ( json_doc, '$' ERROR ON ERROR COLUMNS ( parent_account_number NUMBER PATH '$.data.account.parentAccountNumber', account_number NUMBER PATH '$.data.account.accountNumber', business_unit_id NUMBER PATH '$.data.account.businessUnitId', position_id VARCHAR2 ( 4 ) PATH '$.data.positionId' ) ) AS tab_data INNER JOIN JSON_TABLE ( '{ "accounts": [{ "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }, { "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }] }', '$.accounts[*]' ERROR ON ERROR COLUMNS ( parent_account_number PATH '$.parentAccountNumber', account_number PATH '$.accountNumber', business_unit_id PATH '$.businessUnitId') ) static_data ON ( static_data.parent_account_number = tab_data.parent_account_number AND static_data.account_number = tab_data.account_number AND static_data.business_unit_id = tab_data.business_unit_id ) GROUP BY tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number ); ``` *前の SQL クエリの出力例* ``` { "accountCounts": [ { "businessUnitId": 6, "parentAccountNumber": 32001, "accountNumber": 42001, "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 0, "nonAttorneyCount": 1, "clerkCount": 0 } }, { "businessUnitId": 7, "parentAccountNumber": 32000, "accountNumber": 42000, "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 1, "nonAttorneyCount": 0, "clerkCount": 0 } } ] } ``` **6。 Postgres\$1SQL\$1JSON \$1Aggregation\$1Join** PostgreSQL の組み込み関数`JSON_BUILD_OBJECT`と`JSON_AGG`が、行レベルのデータを JSON 形式に変換します。 PostgreSQL `JSON_BUILD_OBJECT`および`JSON_AGG`はOracle`JSON_OBJECT`および`JSON_ARRAYAGG`と同等です。 サンプルクエリ ``` select JSON_BUILD_OBJECT ('accountCounts', JSON_AGG( JSON_BUILD_OBJECT ('businessUnitId',businessUnitId ,'parentAccountNumber',parentAccountNumber ,'accountNumber',accountNumber ,'totalOnlineContactsCount',online_contacts_count, 'countByPosition', JSON_BUILD_OBJECT ( 'taxProfessionalCount',tax_professional_count ,'attorneyCount',attorney_count ,'nonAttorneyCount',non_attorney_count ,'clerkCount',clerk_count ) ) ) ) from ( with tab as (select * from ( select (json_doc::json->'data'->'account'->>'parentAccountNumber')::INTEGER as parentAccountNumber, (json_doc::json->'data'->'account'->>'accountNumber')::INTEGER as accountNumber, (json_doc::json->'data'->'account'->>'businessUnitId')::INTEGER as businessUnitId, (json_doc::json->'data'->>'positionId')::varchar as positionId from aws_test_pg_table) a ) , tab1 as ( select (json_array_elements(b.jc -> 'accounts') ->> 'accountNumber')::integer accountNumber, (json_array_elements(b.jc -> 'accounts') ->> 'businessUnitId')::integer businessUnitId, (json_array_elements(b.jc -> 'accounts') ->> 'parentAccountNumber')::integer parentAccountNumber from ( select '{ "accounts": [{ "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }, { "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }] }'::json as jc) b) select tab.businessUnitId::text, tab.parentAccountNumber::text, tab.accountNumber::text, SUM(1) online_contacts_count, SUM(CASE WHEN tab.positionId::text = '0095' THEN 1 ELSE 0 END) tax_professional_count, SUM(CASE WHEN tab.positionId::text = '0100' THEN 1 ELSE 0 END) attorney_count, SUM(CASE WHEN tab.positionId::text = '0090' THEN 1 ELSE 0 END) non_attorney_count, SUM(CASE WHEN tab.positionId::text = '0050' THEN 1 ELSE 0 END) clerk_count from tab1,tab where tab.parentAccountNumber::INTEGER=tab1.parentAccountNumber::INTEGER and tab.accountNumber::INTEGER=tab1.accountNumber::INTEGER and tab.businessUnitId::INTEGER=tab1.businessUnitId::INTEGER GROUP BY tab.businessUnitId::text, tab.parentAccountNumber::text, tab.accountNumber::text) a; ``` *前述のクエリの出力例* OracleとPostgreSQLからの出力はまったく同じです。 ``` { "accountCounts": [ { "businessUnitId": 6, "parentAccountNumber": 32001, "accountNumber": 42001, "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 0, "nonAttorneyCount": 1, "clerkCount": 0 } }, { "businessUnitId": 7, "parentAccountNumber": 32000, "accountNumber": 42000, "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 1, "nonAttorneyCount": 0, "clerkCount": 0 } } ] } ``` **7. JSON クエリ付きの Oracle\$1Procedure\$1** このコードは Oracle プロシージャを JSON SQL クエリを含む PostgreSQL 関数に変換します。クエリが JSON を行に置き換える方法と、その逆の方法を示しています。 ``` CREATE OR REPLACE PROCEDURE p_json_test(p_in_accounts_json IN varchar2, p_out_accunts_json OUT varchar2) IS BEGIN /* p_in_accounts_json paramter should have following format: { "accounts": [{ "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }, { "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }] } */ SELECT JSON_OBJECT( 'accountCounts' VALUE JSON_ARRAYAGG( JSON_OBJECT( 'businessUnitId' VALUE business_unit_id, 'parentAccountNumber' VALUE parent_account_number, 'accountNumber' VALUE account_number, 'totalOnlineContactsCount' VALUE online_contacts_count, 'countByPosition' VALUE JSON_OBJECT( 'taxProfessionalCount' VALUE tax_count, 'attorneyCount' VALUE attorney_count, 'nonAttorneyCount' VALUE non_attorney_count, 'clerkCount' VALUE clerk_count ) ) ) ) into p_out_accunts_json FROM (SELECT tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number, SUM(1) online_contacts_count, SUM(CASE WHEN tab_data.position_id = '0095' THEN 1 ELSE 0 END) tax_count, SUM(CASE WHEN tab_data.position_id = '0100' THEN 1 ELSE 0 END) attorney_count, SUM(CASE WHEN tab_data.position_id = '0090' THEN 1 ELSE 0 END) non_attorney_count, SUM(CASE WHEN tab_data.position_id = '0050' THEN 1 ELSE 0 END) clerk_count FROM aws_test_table scco,JSON_TABLE ( json_doc, '$' ERROR ON ERROR COLUMNS ( parent_account_number NUMBER PATH '$.data.account.parentAccountNumber', account_number NUMBER PATH '$.data.account.accountNumber', business_unit_id NUMBER PATH '$.data.account.businessUnitId', position_id VARCHAR2 ( 4 ) PATH '$.data.positionId' ) ) AS tab_data INNER JOIN JSON_TABLE ( p_in_accounts_json, '$.accounts[*]' ERROR ON ERROR COLUMNS ( parent_account_number PATH '$.parentAccountNumber', account_number PATH '$.accountNumber', business_unit_id PATH '$.businessUnitId') ) static_data ON ( static_data.parent_account_number = tab_data.parent_account_number AND static_data.account_number = tab_data.account_number AND static_data.business_unit_id = tab_data.business_unit_id ) GROUP BY tab_data.business_unit_id, tab_data.parent_account_number, tab_data.account_number ); EXCEPTION WHEN OTHERS THEN raise_application_error(-20001,'Error while running the JSON query'); END; / ``` *プロシージャを実行する* 次のコードブロックでは、以前に作成した Oracle プロシージャを、プロシージャへの JSON 入力例とともに実行する方法を説明します。また、このプロシージャの結果または出力も表示されます。 ``` set serveroutput on; declare v_out varchar2(30000); v_in varchar2(30000):= '{ "accounts": [{ "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }, { "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }] }'; begin p_json_test(v_in,v_out); dbms_output.put_line(v_out); end; / ``` *プロシージャ出力* ``` { "accountCounts": [ { "businessUnitId": 6, "parentAccountNumber": 32001, "accountNumber": 42001, "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 0, "nonAttorneyCount": 1, "clerkCount": 0 } }, { "businessUnitId": 7, "parentAccountNumber": 32000, "accountNumber": 42000, "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 1, "nonAttorneyCount": 0, "clerkCount": 0 } } ] } ``` **8. JSON クエリ付きポストグレス関数** 関数の例 ``` CREATE OR REPLACE FUNCTION f_pg_json_test(p_in_accounts_json text) RETURNS text LANGUAGE plpgsql AS $$ DECLARE v_out_accunts_json text; BEGIN SELECT JSON_BUILD_OBJECT ('accountCounts', JSON_AGG( JSON_BUILD_OBJECT ('businessUnitId',businessUnitId ,'parentAccountNumber',parentAccountNumber ,'accountNumber',accountNumber ,'totalOnlineContactsCount',online_contacts_count, 'countByPosition', JSON_BUILD_OBJECT ( 'taxProfessionalCount',tax_professional_count ,'attorneyCount',attorney_count ,'nonAttorneyCount',non_attorney_count ,'clerkCount',clerk_count )))) INTO v_out_accunts_json FROM ( WITH tab AS (SELECT * FROM ( SELECT (json_doc::json->'data'->'account'->>'parentAccountNumber')::INTEGER AS parentAccountNumber, (json_doc::json->'data'->'account'->>'accountNumber')::INTEGER AS accountNumber, (json_doc::json->'data'->'account'->>'businessUnitId')::INTEGER AS businessUnitId, (json_doc::json->'data'->>'positionId')::varchar AS positionId FROM aws_test_pg_table) a ) , tab1 AS ( SELECT (json_array_elements(b.jc -> 'accounts') ->> 'accountNumber')::integer accountNumber, (json_array_elements(b.jc -> 'accounts') ->> 'businessUnitId')::integer businessUnitId, (json_array_elements(b.jc -> 'accounts') ->> 'parentAccountNumber')::integer parentAccountNumber FROM ( SELECT p_in_accounts_json::json AS jc) b) SELECT tab.businessUnitId::text, tab.parentAccountNumber::text, tab.accountNumber::text, SUM(1) online_contacts_count, SUM(CASE WHEN tab.positionId::text = '0095' THEN 1 ELSE 0 END) tax_professional_count, SUM(CASE WHEN tab.positionId::text = '0100' THEN 1 ELSE 0 END) attorney_count, SUM(CASE WHEN tab.positionId::text = '0090' THEN 1 ELSE 0 END) non_attorney_count, SUM(CASE WHEN tab.positionId::text = '0050' THEN 1 ELSE 0 END) clerk_count FROM tab1,tab WHERE tab.parentAccountNumber::INTEGER=tab1.parentAccountNumber::INTEGER AND tab.accountNumber::INTEGER=tab1.accountNumber::INTEGER AND tab.businessUnitId::INTEGER=tab1.businessUnitId::INTEGER GROUP BY tab.businessUnitId::text, tab.parentAccountNumber::text, tab.accountNumber::text) a; RETURN v_out_accunts_json; END; $$; ``` 関数を実行する ``` select f_pg_json_test('{ "accounts": [{ "accountNumber": 42001, "parentAccountNumber": 32001, "businessUnitId": 6 }, { "accountNumber": 42000, "parentAccountNumber": 32000, "businessUnitId": 7 }] }') ; ``` 関数の出力 次の出力は、Oracle プロシージャ出力に似ています。違いは、この出力がテキスト形式であることです。 ``` { "accountCounts": [ { "businessUnitId": "6", "parentAccountNumber": "32001", "accountNumber": "42001", "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 0, "nonAttorneyCount": 1, "clerkCount": 0 } }, { "businessUnitId": "7", "parentAccountNumber": "32000", "accountNumber": "42000", "totalOnlineContactsCount": 1, "countByPosition": { "taxProfessionalCount": 0, "attorneyCount": 1, "nonAttorneyCount": 0, "clerkCount": 0 } } ] } ``` # を使用してアカウント間で Amazon DynamoDB テーブルをコピーする AWS Backup *Ramkumar Ramanujam (Amazon Web Services)* ## 概要 で Amazon DynamoDB を使用する場合の一般的なユースケースは AWS、開発、テスト、またはステージング環境の DynamoDB テーブルを、本番環境のテーブルデータにコピーまたは同期することです。標準的な方法として、環境ごとに異なる AWS アカウントを使用します。  AWS Backup は、DynamoDB、Amazon Simple Storage Service (Amazon S3) などのデータのクロスリージョンおよびクロスアカウントバックアップと復元をサポートしています AWS のサービス。このパターンでは、 AWS Backup クロスアカウントバックアップと復元を使用して DynamoDB テーブルをコピーする手順を示します AWS アカウント。 ## 前提条件と制限事項 **前提条件** + の同じ組織に属する 2 AWS アカウント つのアクティブな AWS Organizations + 両方のアカウントに DynamoDB テーブルを作成するためのアクセス許可 + AWS Identity and Access Management ボールトを作成および使用する (IAM) AWS Backup アクセス許可 **制限事項** + ソースとターゲットは、 の同じ組織の一部 AWS アカウント である必要があります AWS Organizations。 ## アーキテクチャ **ターゲットテクノロジースタック** + AWS Backup  + Amazon DynamoDB **ターゲットアーキテクチャ** ![\[図に基づく、バックアップ保管庫間でのテーブルのコピーについての説明\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ef6e7393-edb6-4744-be26-43f1cbff9de9/images/fa9f3f2f-7a01-4093-9bd5-fc355e57ba67.png) 1. ソースアカウントのバックアップボールトに DynamoDB テーブル AWS Backup バックアップを作成します。 1. バックアップをターゲットアカウントのバックアップ保管庫にコピーします。 1. ターゲットアカウントのバックアップ保管庫からバックアップを使用して、ターゲットアカウントに DynamoDB テーブルを復元します。 **自動化とスケール** を使用して AWS Backup 、バックアップを特定の間隔で実行するようにスケジュールできます。 ## ツール + [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) は、データ保護をクラウド、クラウド AWS のサービス、オンプレミス間で一元化および自動化するためのフルマネージドサービスです。このサービスを使用すると、バックアップポリシーを設定し、 AWS リソースのアクティビティを 1 か所でモニタリングできます。これにより、以前はサービスごとに実行していたバックアップタスクが自動化および統合されるため、カスタムスクリプトや手動プロセスを作成する必要がなくなります。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスであり、シームレスなスケーラビリティを備えた高速で予測可能なパフォーマンスを提供します。 ## エピック ### ソースアカウントとターゲットアカウントの AWS Backup 機能を有効にする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB およびクロスアカウントバックアップの高度な特徴量を有効化する | ソースとターゲットの両方で AWS アカウント、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.html) | AWS DevOps、移行エンジニア | ### ソースアカウントとターゲットアカウントにバックアップ保管庫を作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | バックアップ保管庫の作成 | ソースとターゲットの両方で AWS アカウント、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.html)ソースアカウントとターゲットアカウント間で DynamoDB テーブルバックアップをコピーする場合、ソースとターゲットの両方のバックアップ保管庫の ARN が必要になります。 | AWS DevOps、移行エンジニア | ### バックアップ保管庫を使用してバックアップと復元を行います。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースアカウントで、DynamoDB テーブルバックアップを作成します。 | ソースアカウントの DynamoDB テーブルのバックアップを作成するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.html)新しいバックアップジョブが作成されます。 バックアップジョブのステータスをモニタリングするには、 AWS Backup **Jobs** ページで Backup **Jobs **タブを選択します。このタブには、アクティブ、進行中、および完了状態のすべてのバックアップジョブが一覧表示されます。 | AWS DevOps、DBA、移行エンジニア | | バックアップをソースアカウントからターゲットアカウントにコピーします。 | バックアップジョブが完了した後、DynamoDB テーブルのバックアップをソースアカウントのバックアップ保管庫からターゲットアカウントのバックアップ保管庫にコピーします。バックアップ保管庫をソースアカウントにコピーするには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.html) | AWS DevOps、移行エンジニア、DBA | | ターゲットアカウントのバックアップを復元します。 | ターゲットで AWS アカウント、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.html) | AWS DevOps、移行エンジニア | ## 関連リソース + [DynamoDB AWS Backup での の使用](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorksAWS.html) + [でのバックアップコピーの作成 AWS アカウント](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html) + [AWS Backup 料金](https://aws.amazon.com/backup/pricing/) # カスタム実装を使用してアカウント間で Amazon DynamoDB テーブルをコピー *Ramkumar Ramanujam (Amazon Web Services)* ## 概要 Amazon Web Services (AWS) で Amazon DynamoDB を使用する場合、通常のユースケースは、開発、テスト、またはステージング環境の DynamoDB テーブルを本番環境のテーブルデータにコピーまたは同期することです。標準的な方法として、環境ごとに異なる AWS アカウントを使用します。 DynamoDB が AWS Backup を使用したクロスアカウントバックアップに適用されます。AWS Backup を使用する際に関連するストレージコストについては、[AWS Backup 料金表](https://aws.amazon.com/backup/pricing/)を参照してください。AWS Backup を使用してアカウントをコピーする場合、ソースアカウントとターゲットアカウントは AWS Organizations 組織の一部である必要があります。AWS Glue などの AWS サービスを使用してクロスアカウントのバックアップと復元を行うソリューションは他にもあります。ただし、これらのソリューションを使用すると、デプロイして管理する AWS サービスの数が増えるため、アプリケーションのフットプリントが増加します。  Amazon DynamoDB Streamsを使用して、ソースアカウントのテーブルの変更をキャプチャすることもできます。次に、AWS Lambda 関数を開始し、ターゲットアカウントのターゲットテーブルに対応する変更を加えることができます。ただし、このソリューションは、ソーステーブルとターゲットテーブルを常に同期させる必要があるユースケースにも当てはまります。データが頻繁に更新される開発、テスト、ステージング環境には適用されない場合があります。 このパターンでは、Amazon DynamoDB テーブルをあるアカウントから別のアカウントにコピーするカスタムソリューションを実装する手順を示します。このパターンでは、C\$1、Java、Python などの一般的なプログラミング言語を使用して実装できます。[AWS SDK](https://aws.amazon.com/tools/) に適用されている言語を使用することを推薦します。 ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + 両方のアカウントの DynamoDB テーブル + AWS Identity and Access Management (IAM) ロールとポリシー + C\$1、Java、Python などの一般的なプログラミング言語を使用して Amazon DynamoDB テーブルにアクセスする方法に関する知識 **制限事項** このパターンでは、約 2 GB 以下の DynamoDB テーブルに適用されます。接続やセッションの中断、調整、障害や再試行を処理するロジックを追加すれば、サイズの大きいテーブルにも使用できます。 ソーステーブルから項目を読み取る DynamoDB スキャンオペレーションは、1 回の呼び出しで最大 1 MB のデータしか取得できません。2 GB を超える大きなテーブルでは、この制限によりテーブル全体のコピーを実行する合計時間が長くなる可能性があります。 ## アーキテクチャ 次の図は、ソースとターゲットの AWS アカウント間のカスタム実装を示しています。IAM ポリシーとセキュリティトークンは、カスタム実装で使用されます。データはソースアカウントの Amazon DynamoDB から読み取られ、ターゲットアカウントの DynamoDB に書き込まれます。 ![\[カスタム実装を使用してコピーするためのソースおよびターゲットアカウントのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ba8175be-9809-4c2e-b2d1-6b9180ed056c/images/d9d4c2c8-ff04-443f-9137-e37b8e23ccb5.png) **自動化とスケール** このパターンでは、サイズが約 2 GB と小さい DynamoDB テーブルに適用されます。  このパターンを大きなテーブルに適用するには、以下の問題に対処します。 + テーブルコピー操作中は、異なるセキュリティトークンを使用して 2 つのアクティブセッションが維持されます。テーブルコピー操作にトークンの有効期限よりも時間がかかる場合は、セキュリティトークンを更新するロジックを設定する必要があります。  + 十分な読み込みキャパシティーユニット (WCU) と書き込みキャパシティーユニット (WCU) がプロビジョニングされていない場合、ソーステーブルまたはターゲットテーブルの読み込みまたは書き込みが制限される可能性があります。これらの例外を必ずキャッチして処理します。  + その他の障害や例外を処理し、再試行メカニズムを導入して、コピー操作が失敗したところから再試行または続行できるようにします。 ## ツール **ツール** + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) – Amazon DynamoDB は、フルマネージド NoSQL データベースサービスであり、シームレスなスケーラビリティを備えた高速で予測可能なパフォーマンスを提供します。  + 必要な追加ツールは、実装に選択したプログラミング言語によって異なります。たとえば、C\$1 を使用する場合、Microsoft Visual Studio と次の NuGet パッケージが必要になります。 + `AWSSDK` + `AWSSDK.DynamoDBv2` **コード** 次の Python コードスニペットは、Boto3 ライブラリを使用して DynamoDB テーブルを削除して再作成します。 IAM ユーザーの `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` は長期的な認証情報であるため、使用しません。プログラムで AWS のサービスにアクセスする場合は使用しません。一時的な認証情報についての詳細は、「*IAM ユーザーガイド*」を参照してください。 次のコードスニペットで使用されている `AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY` 、および `TEMPORARY_SESSION_TOKEN` は AWS Security Token Service (AWS STS) から取得された一時的な認証情報です。 ``` import boto3 import sys import json #args = input-parameters = GLOBAL_SEC_INDEXES_JSON_COLLECTION, ATTRIBUTES_JSON_COLLECTION, TARGET_DYNAMODB_NAME, TARGET_REGION, ... #Input param: GLOBAL_SEC_INDEXES_JSON_COLLECTION #[{"IndexName":"Test-index","KeySchema":[{"AttributeName":"AppId","KeyType":"HASH"},{"AttributeName":"AppType","KeyType":"RANGE"}],"Projection":{"ProjectionType":"INCLUDE","NonKeyAttributes":["PK","SK","OwnerName","AppVersion"]}}] #Input param: ATTRIBUTES_JSON_COLLECTION #[{"AttributeName":"PK","AttributeType":"S"},{"AttributeName":"SK","AttributeType":"S"},{"AttributeName":"AppId","AttributeType":"S"},{"AttributeName":"AppType","AttributeType":"N"}] region = args['TARGET_REGION'] target_ddb_name = args['TARGET_DYNAMODB_NAME'] global_secondary_indexes = json.loads(args['GLOBAL_SEC_INDEXES_JSON_COLLECTION']) attribute_definitions = json.loads(args['ATTRIBUTES_JSON_COLLECTION']) # Drop and create target DynamoDB table dynamodb_client = boto3.Session( aws_access_key_id=args['AWS_ACCESS_KEY_ID'], aws_secret_access_key=args['AWS_SECRET_ACCESS_KEY'], aws_session_token=args['TEMPORARY_SESSION_TOKEN'], ).client('dynamodb') # Delete table print('Deleting table: ' + target_ddb_name + ' ...') try: dynamodb_client.delete_table(TableName=target_ddb_name) #Wait for table deletion to complete waiter = dynamodb_client.get_waiter('table_not_exists') waiter.wait(TableName=target_ddb_name) print('Table deleted.') except dynamodb_client.exceptions.ResourceNotFoundException: print('Table already deleted / does not exist.') pass print('Creating table: ' + target_ddb_name + ' ...') table = dynamodb_client.create_table( TableName=target_ddb_name, KeySchema=[ { 'AttributeName': 'PK', 'KeyType': 'HASH' # Partition key }, { 'AttributeName': 'SK', 'KeyType': 'RANGE' # Sort key } ], AttributeDefinitions=attribute_definitions, GlobalSecondaryIndexes=global_secondary_indexes, BillingMode='PAY_PER_REQUEST' ) waiter = dynamodb_client.get_waiter('table_exists') waiter.wait(TableName=target_ddb_name) print('Table created.') ``` ## ベストプラクティス **一時認証情報** セキュリティのベストプラクティスとして、プログラムで AWS サービスにアクセスするときは、IAM ユーザーの `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` を使用することは避けてください。これらは長期的な認証情報であるためです。AWS サービスにプログラムからアクセスするには、常に一時的な認証情報を使用します。 例として、開発者は開発中にアプリケーションの IAM ユーザーの `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` をハードコーディングしますが、変更をコードリポジトリにプッシュする前にハードコードされた値の削除に失敗します。これらの公開された認証情報は、意図しないユーザーや悪意のあるユーザーによって使用される可能性があり、深刻な問題を引き起こす可能性があります (特に公開された認証情報に管理者権限がある場合)。これらの公開後、これらの認証情報を IAM コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、直ちに無効化または削除する必要があります。 AWS サービスにプログラムでアクセスするための一時的な認証情報を取得するには、AWS STS を使用します。一時的な認証情報は、指定された時間 (15 分から 36 時間まで) のみ有効です。一時的な認証情報の最大許容期間は、ロール設定やロールチェーンなどの要因によって異なります。AWS STS の詳細については、[ドキュメント](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)を参照してください。 ## エピック ### DynamoDB テーブルのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB テーブルを作成します。 | ソースとターゲットの両方の AWS アカウントで、インデックスを使用して DynamoDB テーブルを作成します。キャパシティプロビジョニングをオンデマンドモードに設定します。これにより、DynamoDB はワークロードに基づいて読み取り/書き込みキャパシティーを動的にスケーリングできます。 あるいは、4000 の RCU と 4000 WCU のプロビジョニングされたキャパシティを使用することもできます。 | アプリ開発者、DBA、移行エンジニア | | ソーステーブルにデータを入力します。 | ソースアカウントの DynamoDB テーブルにテストデータを入力します。テストデータが 50 MB 以上あると、テーブルコピー中に消費される RCU の最大値と平均値を確認するのに役立ちます。その後、必要に応じてキャパシティプロビジョニングを変更できます。 | アプリ開発者、DBA、移行エンジニア | ### DynamoDB テーブルにアクセスするための認証情報をセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースとターゲットの DynamoDB テーブルにアクセスするための IAM ロールを作成します。 | ソースアカウントの DynamoDB テーブルにアクセス (読み取り) する権限を持つ IAM ロールをソースアカウントで作成します。ソースアカウントをこのロールの信頼できるエンティティとして追加します。ターゲットアカウントの DynamoDB テーブルへのアクセス (作成、読み取り、更新、削除) 権限を持つ IAM ロールをターゲットアカウントで作成します。 ターゲットアカウントをこのロールの信頼できるエンティティとして追加します。 | アプリ開発者、AWS DevOps | ### アカウントから別のアカウントにテーブルデータをコピー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールの一時認証情報を取得します。 | ソースアカウントで作成した IAM ロールの一時認証情報を取得します。ターゲットアカウントで作成された IAM ロールの一時認証情報を取得します。IAM ロールの一時認証情報を取得する 1 つの方法は、AWS CLI から AWS STS を使用します。
aws sts assume-role --role-arn arn:aws:iam:::role/ --role-session-name  --profile
適切な AWS プロファイル (ソースアカウントまたはターゲットアカウントに対応) を使用します。一時的なセキュリティ認証情報の使用方法の詳細については、以下を参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-a-custom-implementation.html) | アプリ開発者、移行エンジニア | | ソースとターゲットの DynamoDB アクセス用に DynamoDB クライアントを初期化します。 | AWS SDK によって提供される DynamoDB クライアントを、ソースとターゲットの DynamoDB テーブル用に初期化します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-a-custom-implementation.html)IAM の一時認証情報を使用してリクエストを行う方法についての詳細は、[AWS ドキュメント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) を参照してください。 | アプリ開発者 | | ターゲットテーブルをドロップして再作成。 | ターゲットアカウントの DynamoDB クライアントを使用して、ターゲットアカウントのターゲット DynamoDB テーブル (およびインデックス) を削除して再作成します。DynamoDB テーブルからすべてのレコードを削除すると、プロビジョニングされた WCU が消費されるため、コストのかかる操作です。テーブルを削除して再作成することで、このような追加コストを回避できます。テーブルを作成した後でもインデックスを追加できますが、これには 2 ～ 5 分ほど時間がかかります。テーブルの作成中に インデックスコレクションを `createTable` 呼び出しに渡すことで、インデックスを作成することがより効率的になります。 | アプリ開発者 | | テーブルコピーを実行します。 | すべてのデータがコピーされるまで、次の手順を繰り返します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-a-custom-implementation.html)詳細については、「*添付ファイル*」セクションで、C\$1 のリファレンス実装 (テーブルの削除、作成、入力用) を参照してください。テーブル設定の JavaScript オブジェクト表記 (JSON) ファイルの例も添付されています。 | アプリ開発者 | ## 関連リソース + [Amazon DynamoDB ドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) + [AWS アカウント内での IAM ユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) + [AWS SDK](https://aws.amazon.com/tools/) + [AWS リソースを使用した一時的な認証情報の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) ## 追加情報 このパターンでは、C\$1 を使用して 200,000 項目 (平均項目サイズは 5 KB、テーブルサイズは 250 MB) の DynamoDB テーブルをコピーするために実装されました。ターゲット DynamoDB テーブルは、4000 RCU と 4000 WCU のキャパシティーをプロビジョニングして設定されました。 テーブルの削除と再作成を含むテーブルコピー操作 (ソースアカウントからターゲットアカウントへ) には 5 分かかりました。消費されたキャパシティユニットの総容量：30,000 RCU と約 400,000 WCU。 DynamoDB キャパシティモードの詳細については、AWS ドキュメントの[読み取り/書き込みキャパシティモード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html) を参照してください。 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、[attachment.zip](samples/p-attach/ba8175be-9809-4c2e-b2d1-6b9180ed056c/attachments/attachment.zip) ファイルを解凍してください。 # Amazon RDS と Amazon Aurora の詳細なコストと使用状況レポートを作成する *Amazon Web Services、Lakshmanan Lakshmanan、Sudarshan Narasimhan* ## 概要 このパターンは、「[ユーザー定義のコスト割り当てタグ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)」を設定して Amazon Relational Database Service (Amazon RDS) または Amazon Aurora クラスターの使用コストを追跡する方法を示しています。これらのタグを使用して、複数のディメンションにわたるクラスターの詳細なコストと使用状況レポートを AWS Cost Explorer で作成できます。たとえば、チーム、プロジェクト、またはコストセンターレベルで使用コストを追跡し、Amazon Athena でデータを分析できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + 1 つ以上の「[Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)」または「[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.CreateInstance.html)」インスタンス **制限事項** タグ付けの制限については、「[AWS Billing ユーザーガイド](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/allocation-tag-restrictions.html)」を参照してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon RDS または Amazon Aurora + AWS コストと使用状況レポート + AWS Cost Explorer + Amazon Athena ワークフローとアーキテクチャ タグ付けと分析ワークフローは次のステップで構成されます。 1. データエンジニア、データベース管理者、または AWS 管理者は、Amazon RDS または Aurora クラスターのユーザー定義のコスト配分タグを作成します。 1. AWS 管理者がタグを有効化します。 1. タグはメタデータを AWS Cost Explorer に報告します。 1. データエンジニア、データベース管理者、または AWS 管理者が「[毎月のコスト配分レポート](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html#allocation-viewing)」を作成します。 1. データエンジニア、データベース管理者、または AWS 管理者が Amazon Athena を使用して月次コスト配分レポートを分析します。 次の図は、Amazon RDS または Aurora インスタンスの使用コストを追跡するためにタグを適用する方法を示しています。   ![\[タグを適用してデータベースインスタンスとクラスターの使用コストを追跡します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eab5001d-5115-4aa6-bdd2-23063b08b262/images/63292b18-01d6-4523-b8ac-2c3b12b11b84.png) 次のアーキテクチャ図は、コスト配分レポートを Amazon Athena と統合して分析する方法を示しています。 ![\[Athena でのコスト配分レポートのクエリ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eab5001d-5115-4aa6-bdd2-23063b08b262/images/9c028405-1e93-4f6a-a0e5-36154e2b8eab.png) 毎月のコスト配分レポートは、指定した Amazon S3 バケットに保存されます。「*エピック*」セクションで説明したように、AWS CloudFormation テンプレートを使用して Athena をセットアップすると、テンプレートは AWS Glue クローラー、AWS Glue データベース、Amazon Simple Notification System (Amazon SNS) イベント、AWS Lambda 関数、Lambda 関数のための AWS Identity and Access Management (IAM) ロールなど、いくつかの追加リソースを割り当てます。新しいコストデータファイルが S3 バケットに到着すると、イベント通知を使用してこれらのファイルを Lambda 関数に転送して処理します。Lambda 関数は AWS Glue クローラージョブを開始して、AWS Glue データカタログのテーブルを作成または更新します。次に、このテーブルを使用して Athena のデータをクエリします。   ## ツール + 「[Amazon Athena](https://aws.amazon.com/athena/)」は、Amazon S3 内のデータを標準 SQL を使用して簡単に分析できるインタラクティブなクエリサービスです。 + 「[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)」はクラウド用に構築されたフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + 「[AWS CloudFormation](https://aws.amazon.com/cloudformation/)」は、AWS とサードパーティのリソースを簡単にモデル化、プロビジョニング、管理できるコードとしての infrastructure as code (IaC) サービスです。 + 「[AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)」を使用すると、AWS コストと使用状況を表示および分析できます。 ## エピック ### Amazon RDS または Aurora クラスターのタグを作成してアクティブ化する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS または Aurora クラスター用のユーザー定義のコスト配分タグを作成します。 | 新規または既存の Amazon RDS または Aurora クラスターにタグを追加するには、「*Amazon Aurora ユーザーガイド*」の「[タグの追加、一覧表示、削除](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.html#Tagging.HowTo)」の手順に従ってください。Amazon Aurora クラスターをセットアップする方法については、「*Amazon Aurora ユーザーガイド*」の「[MySQ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.Aurora.html)L」と「[PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.html)」の指示を参照してください。 | AWS 管理者、データエンジニア、DBA | | ユーザー定義のコスト配分タグを有効にします。 | 「*AWS 請求ユーザーガイド*」の「[ユーザー定義のコスト配分タグの有効化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)」の手順に従ってください。 | AWS 管理者 | ### コストと使用状況レポートの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターのコストと使用状況レポートを作成して設定する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-detailed-cost-and-usage-reports-for-amazon-rds-and-amazon-aurora.html)データは 24 時間後に利用可能になります。 | アプリオーナー、AWS管理者、DBA、一般AWS、データエンジニア | ### コストと使用状況のレポートデータを分析します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | コストと使用状況のレポートデータを分析します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-detailed-cost-and-usage-reports-for-amazon-rds-and-amazon-aurora.html)
select status from cost_and_usage_data_status
詳細については、「*AWS コストと使用状況レポートユーザーガイド*」の「[Amazon Athena クエリの実行](https://docs.aws.amazon.com/cur/latest/userguide/cur-ate-run.html)」を参照してください。SQL クエリを実行する際には、ドロップダウンリストから正しいデータベースが選択されていることを確認してください。 | アプリオーナー、AWS管理者、DBA、一般AWS、データエンジニア | ## 関連リソース **リファレンス** + 「[AWS CloudFormation テンプレートを使用してAthena をセットアップする](https://docs.aws.amazon.com/cur/latest/userguide/use-athena-cf.html)」(推奨) + 「[Athena の手動セットアップ](https://docs.aws.amazon.com/cur/latest/userguide/cur-ate-manual.html)」 + 「[Amazon Athena クエリの実行](https://docs.aws.amazon.com/cur/latest/userguide/cur-ate-run.html)」 + 「[他のリソースへのレポートデータのロード](https://docs.aws.amazon.com/cur/latest/userguide/cur-query-other.html)」 **チュートリアルと動画** + 「[Amazon Athena を使用したコストと使用状況レポートの分析](https://youtu.be/KEeJEZTYE8E)」(YouTube ビデオ) # Terraform を使用して SQL Server フェイルオーバークラスターインスタンスを Amazon EC2 および Amazon FSx にデプロイする *Mark Hudson と Matt Burgess、Amazon Web Services* ## 概要 このパターンでは、Terraform を使用して、Amazon Elastic Compute Cloud (Amazon EC2) 上の Windows Server フェイルオーバークラスター (WSFC) ノード全体に SQL Server フェイルオーバークラスターインスタンス (FCIs) をデプロイします。さらに、このパターンでは、データとログファイルに Amazon FSx 共有ストレージを使用します。 SQL Server データベースが に移行する場合 AWS、最初の選択肢は Amazon RDS for SQL Server です。ただし、Amazon RDS for SQL Server が適していない場合があり、SQL Server を高可用性アーキテクチャの Amazon EC2 にデプロイする必要があります。このソリューションでは、SQL Server FCI が WSFC ノード全体にインストールされます。 このパターンに含まれる Terraform モジュールでは、最大 2 つの Amazon EC2 SQL Server インスタンスをプロビジョニングします。Amazon FSx for Windows File Server ファイルシステムはクォーラム監視として機能し、共有データとログファイルを保存します。設定されたインスタンスの数に関係なく、SQL Server インスタンスノードは常に FCI クラスターを作成して結合し、環境のパリティを確保します (通常は、開発環境用に 1 つのインスタンス、本番環境用に 2 つのインスタンスが設定されています)。高可用性のために 2 つのノードを使用する設定の場合、内部 Network Load Balancer がプロビジョニングされます。Network Load Balancer は、FCI クラスターに設定されたヘルスプローブを使用して、プライマリのノードを特定します。 ## 前提条件と制限事項 **前提条件** + アクティブ AWS アカウント。 + 個別のアベイラビリティーゾーンに 2 つのサブネットを持つ Amazon Virtual Private Cloud (Amazon VPC)。 + Amazon VPC の [DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/DHCPOptionSet.html)。Active Directory ドメイン名に解決するようにドメイン名を設定し、Active Directory ドメインコントローラーを指すようにドメインと NetBIOS ネームサーバーを設定します。詳細については、「[追加情報](#deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx-additional)」の「*VPC の設定*」を参照してください。 + AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD). + カスタム Amazon マシンイメージ (AMI) 詳細については、「[追加情報](#deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx-additional)」の「*AMI の設定*」を参照してください。 + SQL Server ISO イメージを含む Amazon Simple Storage Service (Amazon S3) バケット。この前提条件は、提供された `component.yaml` ファイルと [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html) を使用してカスタム AMI を構築する場合にのみ必要です。 + AWS Key Management Service (AWS KMS) 暗号化キー。 + デフォルトでは、SQL Server は Developer エディションのプロダクトキーを使用してインストールされます。本番システムでは、関連する変数によってモジュールに渡された有効なプロダクトキーを使用してください。 **制限事項** + このソリューションには AWS Managed Microsoft ADが必要です。ただし、必要に応じて、代わりにセルフマネージド Active Directory 実装を使用できます。これを行うには、含まれている Amazon FSx Terraform モジュールを変更して `active_directory_id` 属性を削除します。次に、[Terraform ドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/fsx_windows_file_system)の記載に従って、セルフマネージド Active Directory に必要な 4 つの属性を追加します。 + SQL Server は、混合モード認証を使用するように設定されています。必要に応じて、Windows のみの認証を使用できます。そのためには、提供されたユーザーデータスクリプトで、`setup.exe` コマンドに渡された `/SECURITYMODE` および `/SAPWD` パラメータを削除します。`sql_accounts.tf` ファイルを削除し、`instances.tf` ファイルを変更して `sql_sa_password` エントリを削除することができます。 + デプロイされたクラスターを削除するときは、対応する仮想コンピュータオブジェクトと、Active Directory 内の個々のコンピュータオブジェクトを削除する必要があります。オブジェクトを削除するには、Active Directory 管理ツールを使用します。 + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。 **製品バージョン** このソリューションは次のバージョンでテスト済みです。 + Windows Server 2019 + SQL Server 2019 + [Terraform v0.13.0](https://developer.hashicorp.com/terraform/language/v1.1.x/upgrade-guides/0-13) ## アーキテクチャ **ソーステクノロジースタック** + SQL Server **ターゲットテクノロジースタック** + Amazon EC2 を使用した WSFC ノード上の SQL Server FCI + Amazon FSx for Windows File Server + Amazon S3 バケット + AWS Secrets Manager + AWS Managed Microsoft AD + AWS KMS + AWS Identity and Access Management (IAM) **ターゲットアーキテクチャ** このソリューション用のアーキテクチャを次の図に示します。 ![\[Amazon EC2 の Windows Server フェイルオーバークラスターノードに SQL Server フェイルオーバークラスターインスタンスをデプロイするアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/45f3ab19-d240-4353-ab6e-f6e565f537a4/images/0bff16f2-94e7-4e86-91ea-7ab5f3725620.png) 図に示す内容は以下のとおりです。 + EC2 インスタンスに AWS KMS および Secrets Manager へのアクセスを提供する IAM ロール + 2 つのアベイラビリティーゾーンにまたがるプライベートサブネットの Amazon EC2 インスタンスにデプロイされた 2 つの SQL Server ノード + アクティブな SQL Server インスタンスへの接続を容易にする Network Load Balancer (単一ノードクラスターのセットアップ時にはデプロイされません) + SQL Server ノードによって共有ストレージ用に両方のプライベートサブネットにデプロイされた Amazon FSx for Windows File Server ファイルシステム + Active Directory と SQL Server の認証情報と設定を保存するための Secrets Manager + SQL Server インストールイメージを保存するための Amazon S3 バケット + AWS Managed Microsoft AD for Windows 認証 + AWS KMS 暗号化キーを作成するための **自動化とスケール** [GitHub リポジトリ](https://github.com/aws-samples/cluster-amazon-elastic-compute-cloud-amazon-fsx-microsoft-sql-server)にある Terraform モジュールを使用して、ターゲットアーキテクチャのデプロイを自動化できます。`terraform.tfvars` ファイルを変更して、環境に固有の変数値を含める必要があります。Amazon S3 バケット、 AWS Managed Microsoft AD コンポーネント、 AWS KMS 暗号化キー、および一部のシークレットは、このデプロイの前提条件であり、Terraform コードには含まれていません。 ## ツール **AWS のサービス** + [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) は、ディレクトリ対応のワークロードと AWS リソースが で Microsoft Active Directory を使用できるようにします AWS クラウド。このパターンでは、 AWS Managed Microsoft AD は Windows Server および SQL Server 認証、DNS に使用されます。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。このパターンでは、SQL Server フェイルオーバークラスターインスタンスは Amazon EC2 インスタンスにインストールされます。 + [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html) は、カスタマイズされたサーバーイメージの作成、管理、デプロイを自動化するのに役立ちます。 + [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) は、Windows Server でフルマネージド共有ストレージを提供します。このパターンでは、FSx for Windows File Server は SQL Server データおよびログファイルとクォーラム監視用の共有ストレージを提供します。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。このパターンでは、Secrets Manager シークレット、Amazon Elastic Block Store (Amazon EBS) ボリュームの SQL Server ストレージ、および FSx for Windows File Server ファイルシステムを暗号化するために使用されます。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。このパターンでは、SQL Server をインストールして実行するための Active Directory 認証情報、`sa` ユーザー認証情報、およびデータベース接続情報が Secrets Manager に保存されます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。このパターンでは、Amazon S3 バケットを使用して SQL Server のインストールイメージを保存します。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 ******その他のツール** + [Microsoft SQL Server FCI](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver15) は Windows Server クラスターノード全体にインストールされます。さらに、複数のサブネットにインストールできます。このパターンでは、SQL Server FCI インスタンスは WSFC ノード全体にインストールされます。 + [Terraform](https://www.terraform.io/) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ infrastructure as code (IaC) ツールです。このパターンでは、Terraform を使用してリソースを作成し、SQL Server FCI インスタンスを設定します。 + [Windows Server フェイルオーバークラスタリング](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver15)は、SQL Server などのホストされるサーバーアプリケーションの高可用性をサポートするインフラストラクチャ機能を提供します。このパターンでは、FCI ノードは WSFC 機能を使用して、インスタンスレベルで冗長性を通じてローカルの高可用性を提供します。 **コードリポジトリ** このパターンのコードは、GitHub の [cluster-amazon-elastic-compute-cloud-amazon-fsx-microsoft-sql-server](https://github.com/aws-samples/cluster-amazon-elastic-compute-cloud-amazon-fsx-microsoft-sql-server) リポジトリで入手できます。このリポジトリでは、次のリソースを入手できます。 + ソリューションの概要と追加のインストールおよび使用状況情報を提供する `README.md` ファイル + このパターンのコンポーネントをプロビジョニングするための Terraform 設定ファイルのベースセットと Amazon FSx 固有のモジュール + Amazon EC2 ユーザーデータスクリプトとして実行されるインスタンスセットアップスクリプト + Image Builder がカスタム AMI の作成に使用できる `component.yam`l ファイル ## ベストプラクティス **セキュリティとパッチ適用** + AMI の前提条件であるインストールと設定は、SQL Server FCI クラスターをデプロイするための最小要件です。組織の基準とセキュリティ要件に準拠するには、追加のソフトウェアと設定が必要になる場合があります。 + デプロイ後、Windows に継続的にパッチを適用します。実行中のインスタンスに直接パッチを適用するか、最新の Windows パッチを使用して新しい AMI を作成し、新しい AMI を使用してインスタンスを (一度に 1 つずつ) 置き換えます。 は、最新のオペレーティングシステムパッチ、ドライバー、起動エージェントを含む新しい Windows AMIs を毎月 AWS リリースします。新しいインスタンスを起動する際、または独自のカスタムイメージを作成する際は、最新の AMI を確認してください。 + Amazon EC2 インスタンスは、すべての送信トラフィックを許可するように設定されています。本番環境にデプロイする場合、セキュリティグループのアウトバウンドルールを設定して、このトラフィックを必要な送信先に制限する必要があります。 + FSx for Windows File Server ファイルシステムは、ファイル共有とファイルおよびフォルダへのアクセスの監査ログを自動的に記録し、環境での要件である場合は目的の宛先に配信することができます。 + Secrets Manager シークレットを定期的に自動でローテーションします。Amazon EC2 インスタンスのキーペアについては、「[AWS Secrets Manager を使用して SSH キーペアを安全に保管およびローテーションする方法](https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-manager-securely-store-rotate-ssh-key-pairs/)」で説明されている自動ローテーションソリューションを検討してください。Active Directory 認証情報と SQL Server の `sa` 認証情報シークレットについては、パスワード管理のポリシーに従って自動ローテーションを設定します。 **Active Directory の管理** + FCI クラスターの一部として、Windows は Active Directory でコンピュータ名オブジェクト (CNO) を生成します。CNO は DNS リクエストに応答し、アクティブな SQL ノードにトラフィックを転送します。この Active Directory 提供の DNS を使用することはお勧め*しません*。TTL が高すぎて妥当なフェイルオーバー時間が得られず、多くの場合、新しいプライマリ IP アドレスが反映されるまでに 5 分以上かかります。一方、高可用性のインストールでは、内部 Network Load Balancer は 30 秒以内にフェイルオーバーするように設定されています。 + クラスターを作成するには、Active Directory のドメイン管理者が必要です。この要件は、クラスターオブジェクトの作成と Active Directory でのアクセス許可の変更に必要なアクセス許可が昇格されているためです。ただし、SQL Server サービスはドメイン管理者として実行する必要はありません。そのため、この目的のために 2 番目の Active Directory ユーザーを作成することをお勧めします。ただし、サービスがドメイン管理者ユーザーとして実行される場合は、このユーザーを削除できます。その場合、ドメイン管理者ユーザーは、このパターンの一部として作成された Active Directory 管理者グループに追加する必要があります。 ## エピック ### クラスター認証情報を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アクティブディレクトリグループを作成する。 | で AWS Managed Microsoft AD、次のグループを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.html)詳細については、 AWS ドキュメント[の「グループの作成 AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_create_group.html)」を参照してください。 | AD 管理者 | | Active Directory ユーザーを作成する。 | で AWS Managed Microsoft AD、次のユーザーを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.html)詳細については、 AWS ドキュメント[の AWS Managed Microsoft AD 「 ユーザーの作成](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html)」を参照してください。 | AD 管理者 | | Active Directory 認証情報をシークレットに追加する。 | Secrets Manager を使用して 4 つのシークレットを作成し、次の情報を保存します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.html)詳細については、 AWS ドキュメント[の「 AWS Secrets Manager シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。 | AWS 管理者 | ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Windows AMI を作成する。 | 前提条件となるソフトウェアと設定を含むカスタム Windows AMI を作成します。詳細については、「[追加情報](#deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx-additional)」を参照してください。 | AWS 管理者、AWS DevOps | | Terraform をインストールします。 | Terraform をインストールするには、[Terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli) ウェブサイトの指示に従ってください。 | AWS DevOps | | リポジトリをクローン作成します。 | このパターンの[リポジトリ](https://github.com/aws-samples/cluster-amazon-elastic-compute-cloud-amazon-fsx-microsoft-sql-server)のクローンを作成します。詳細については、GitHub ウェブサイトの「[リポジトリをクローンする](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | AWS DevOps | ### クラスターをインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Terraform 変数を変更する。 | 指定された `terraform.tfvars` ファイルを更新して、すべての変数を環境に適した値に設定します。例えば、`domain_group_administrators` 変数と `domain_group_rdp_users` 変数を更新して、Active Directory ドメイン名と前に作成した Active Directory グループの名前を使用します。 | AWS DevOps | | Terraform を初期化します。 | 提案されたデプロイを確認するには、リポジトリのルートに移動します。Terraform コマンドラインインターフェイス (CLI) を使用して `terraform init` を実行し、次に `terraform plan` を実行します。 | AWS DevOps | | リソースをデプロイする。 | SQL クラスターと関連リソースをデプロイするには、Terraform CLI を使用して `terraform apply` を実行します。 | AWS DevOps、AWS 管理者 | | デプロイを検証する。 | デプロイを検証するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.html) | DBA、AWS システム管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | Terraform のプロビジョニングは完了しましたが、Windows Failover Cluster Manager はクラスターの作成が完了しているか、クラスターが操作不能な状態であるかを示していません。 | リソースのインストール全体とクラスターの設定には 45～60 分かかる場合があります。Terraform が完了したら、ユーザーデータスクリプトを完了まで実行する必要があります。そのためには、複数回の再起動が必要です。進行状況をモニタリングするために、`C:\` ドライブの `Checkpoints` ディレクトリと `C:\Program Data\Microsoft SQL Server\150\Log` の SQL Server インストールログを使用できます。完了すると、**Installation Complete** メッセージが `C:\ProgramData\Amazon\EC2-Windows\Launch\Log\UserdataExecution.log` ファイルに書き込まれます。 | | 機能しているクラスターをプロビジョニングした後、Terraform を使用してクラスターを削除したり再作成したりすることはできません。Terraform は完了しますが、クラスターは正しく設定されません。 | プロビジョニングプロセスの一環として、マシンと仮想オブジェクトを Active Directory および Active Directory DNS に登録します。Amazon EC2 クラスターノードとクラスターノード用のコンピュータ名が存在する場合、FCI は正しく初期化できず、プロビジョニングが失敗します。この問題を解決するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.html) | ## 関連リソース **AWS ドキュメント** + [Image Builder を使用してカスタムイメージを作成する](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-images.html) + [KMS キーを作成する](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) + [汎用バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) + [キーポリシーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) + [の作成 AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) ## 追加情報 **Terraform モジュール情報** このモジュールでは、AMI 設定とユーザーデータ設定を組み合わせて、最適なプロビジョニング時間と安定性の組み合わせが得られるようにします。プロビジョニング中、Windows では複数回の再起動と待機が必要です。チェックポイントメソッドは、永続ユーザーデータの再起動中に無限ループから保護するために実装されています。ユーザーデータは永続化するように設定されています。そのため、ユーザーデータ設定スクリプトはべき等になるように開発され、そうあり続ける必要があります。べき等性は、更新プロセスを合理化し、FCI クラスターの再参加または再作成のための手動設定を行わずに、更新サイクル中にインスタンスをスワップアウトできるようにするものです。 **SQL Server 接続文字列とフェイルオーバークラスタリング** モジュールは、このデータベースの接続文字列で使用するエンドポイントアドレスを含むシークレットを発行します。シークレット名は `{environment_name}/sqlserver/{cluster_name}/endpoint` という形式に従います。ノードが 1 つだけ使用されるインストールでは、これは Amazon EC2 インスタンス SQL Server インターフェイスの IP アドレスであると想定できます。高可用性インストール (2 つのインスタンス) では、これは内部 Network Load Balancer の DNS 名であると想定できます。 このモジュールでは、フェイルオーバークラスタリング仮想 IP はサポートされていません。仮想 IP を動作させるには、同じサブネット内に配置する必要があります。では AWS、1 つのサブネットを複数のアベイラビリティーゾーンにまたがることはできません。そのため、仮想 IP を使用した場合、このモジュールの能力を高可用性とみなすことはできません。 各 Amazon EC2 インスタンスには、3 つのプライベート IP アドレスが割り当てられます。使用方法は次のようになります。 + **ネットワークトラフィック用のプライマリ IP** – 送信トラフィック用ソース IP です。 + **FCI 通信** – フェイルオーバークラスターの状態および同期を維持するために使用されます。 + **SQL Server (TCP ポート 1433)** – リスナーであり、ハートビートトラフィックをリッスンしてプライマリのインスタンスを判断します。 **VPC の構成** [前提条件](#deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx-prereqs)には、DNS 解決に Active Directory を使用するように設定された DHCP オプションセットが一覧表示されます。ただし、この前提条件は必須要件ではありません。必須要件は、EC2 インスタンスが Active Directory ドメイン名を解決できることです。この要件を満たすには、 Amazon Route 53 Resolver エンドポイントを使用するなど、他の方法を使用できます。詳細については、[「Directory Service の DNS 解決と Amazon Route 53 Resolver の統合](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-your-directory-services-dns-resolution-with-amazon-route-53-resolvers/)」(AWS ブログ記事) を参照してください。 **AMI の設定** このパターンで使用される AMI には、以下の前提条件となるソフトウェアと設定が含まれている必要があります。 1. SQL Server 2019 のインストールファイルを `C:\SQL_Install_media` にダウンロードして展開します。 1. 次の Windows 機能をインストールします。 + `Install-WindowsFeature Failover-Clustering` + `Install-WindowsFeature RSAT-AD-PowerShell` + `Install-WindowsFeature RSAT-AD-Tools` + `Install-WindowsFeature RSAT-Clustering-Mgmt` + `Install-WindowsFeature RSAT-Clustering-PowerShell` + `Install-WindowsFeature RSAT-Clustering-CmdInterface` 1. 次のように Windows ファイアウォールを無効にします。 + `Get-NetFirewallProfile | Set-NetFirewallProfile -Enabled False` 1. 次のように CredSSP 認証方法を有効にします (`` を組織の Windows ドメイン名に置き換えます)。 + `Enable-WSManCredSSP -Role "Server" -Force` + `Enable-WSManCredSSP -Role "Client" -DelegateComputer *..com -Force` 1. 次のレジストリキーを設定します。 + NTLM 認証情報を許可します。 + `HKLM:\Software\Policies\Microsoft\Windows\CredentialsDelegation` + 名前: `AllowFreshCredentialsWhenNTLMOnly` + 値: 1 + 型: `REG_DWORD` + ローカルドメインコンピュータに PowerShell の NTLM の使用を許可します。 + パス: `HKLM:\Software\Policies\Microsoft\Windows\CredentialsDelegation\AllowFreshCredentialsWhenNTLMOnly` + 名前: `1` + 値: `wsman/*..com` + 型: `REG_SZ` 1. [PowerShell Gallery](https://learn.microsoft.com/en-us/powershell/gallery/overview?view=powershellget-3.x) を次のようにセットアップします。 + `[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12` + `Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force` + `Set-PSRepository -Name PSGallery -InstallationPolicy Trusted` 1. 次の Windows PowerShell モジュール`*` をインストールします。 + `Install-Module -Name ComputerManagementDsc` + `Install-Module -Name FailOverClusterDsc` + `Install-Module -Name PSDscResources` + `Install-Module -Name xSmbShare` + `Install-Module -Name xActiveDirectory` + `Install-Module -Name SqlServer` Image Builder を使用して AMI を作成するには、Image Builder ドキュメントの「[Create an image pipeline using the EC2 Image Builderconsole wizard](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)」の手順に従います。前の前提条件でレシピのコンポーネントを作成するには、次の手順を実行します。 1. [GitHub リポジトリ](https://github.com/aws-samples/cluster-amazon-elastic-compute-cloud-amazon-fsx-microsoft-sql-server)の `ami ` フォルダから [component.yaml](https://github.com/aws-samples/cluster-amazon-elastic-compute-cloud-amazon-fsx-microsoft-sql-server/blob/main/ami/component.yaml) ファイルをダウンロードします。 1. コンテンツを新しい Image Builder コンポーネントにコピーします。 1. 以下のプレースホルダーをお客様の情報で更新します。 + `` – Active Directory ドメイン名 + `` – SQL Server イメージを含む Amazon S3 バケットの名前 # Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL で Oracle PL/SQL 連想配列をエミュレートする *Amazon Web Services、Rajkumar Raghuwanshi、Bhanu Ganesh Gudivada、Sachin Khanna* ## 概要 このパターンでは、[Amazon Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/) および [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/) 環境で、空のインデックス位置を持つ Oracle PL/SQL 連想配列をエミュレートする方法について説明します。また、それぞれが移行中に空のインデックス位置を処理する方法に関して、Oracle PL/SQL 連想配列と PostgreSQL 配列の違いについても説明します。 PostgreSQL は、Oracle データベースの移行時に `aws_oracle_ext` 関数により空のインデックス位置を処理する操作の代わりに使用できるものです。このパターンでは、追加の列を使用してインデックス位置を保存し、ネイティブ PostgreSQL 機能を組み込みながら、Oracle によるスパース配列の処理を維持します。 **Oracle** Oracle では、コレクションを空として初期化し、配列に `NULL` 要素を追加する `EXTEND` コレクションメソッドを使用して入力できます。`PLS_INTEGER` によってインデックス付けされた PL/SQL 連想配列を使用する場合、`EXTEND` メソッドでは `NULL` 要素が連続で追加されますが、要素は非連続のインデックス位置で初期化することもできます。明示的に初期化されていないインデックス位置は空のままとなります。 この柔軟性により、要素を任意の位置に入力できるスパース配列構造が可能になります。`FIRST` および `LAST` 境界と一緒に `FOR LOOP` を使用してコレクションを反復処理する場合、初期化された要素 (`NULL` または値を定義) のみが処理され、空の位置はスキップされます。 **PostgreSQL (Amazon Aurora および Amazon RDS)** PostgreSQL は、空の値を `NULL` 値とは異なる方法で処理します。空の値は、1 バイトのストレージを使用する個別のエンティティとして保存されます。配列に空の値がある場合、PostgreSQL は空でない値と同様にシーケンシャルインデックス位置を割り当てます。ただし、シーケンシャルインデックス作成には追加の処理が必要です。システムでは、空の位置を含むすべてのインデックス付き位置を反復処理する必要があるためです。これにより、従来の配列の作成はスパースデータセットでは非効率になります。 **AWS Schema Conversion Tool** [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/) は通常、`aws_oracle_ext` 関数を使用して Oracle から PostgreSQL への移行を処理します。このパターンでは、ネイティブ PostgreSQL 機能を使用する代替アプローチを提案します。これは、PostgreSQL 配列タイプと追加の列を組み合わせてインデックス位置を保存するものです。システムでは、インデックス列のみを使用して配列を反復処理できるようになります。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + 管理者権限を持つ AWS Identity and Access Management (IAM) ユーザー。 + Amazon RDS または Aurora PostgreSQL 互換のインスタンス。 + リレーショナルデータベースの基本的な理解。 **制限事項** + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページから、サービスのリンクを選択してご確認ください。 **製品バージョン** このパターンは次のバージョンでテスト済みです。 + Amazon Aurora PostgreSQL 13.3 + Amazon RDS for PostgreSQL 13.3 + AWS SCT 1.0.674 + Oracle 12c EE 12.2 ## アーキテクチャ **ソーステクノロジースタック** + オンプレミスの Oracle データベース **ターゲットテクノロジースタック** + Amazon Aurora PostgreSQL + Amazon RDS for PostgreSQL **ターゲットアーキテクチャ** ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a62d038c-ca3c-41e1-aa7e-74282d2e54f4/images/13aacf00-655a-4149-a4e7-42b66dbea4e1.png) 図に示す内容は以下のとおりです。 + ソース Amazon RDS for Oracle データベースインスタンス + Oracle 関数を PostgreSQL に相当する関数に変換 AWS SCT するための を備えた Amazon EC2 インスタンス + Amazon Aurora PostgreSQL と互換性のあるターゲットデータベース ## ツール **AWS サービス** + 「[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)」はクラウド用に構築されたフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + [Amazon Aurora PostgreSQL 互換エディション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)は、PostgreSQL デプロイのセットアップ、運用、スケーリングに役立つ、フルマネージド型のACID準拠のリレーショナルデータベースエンジンです。 + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケールできます。 + [Oracle 向け Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html) を使用すると、 AWS クラウドで Oracle リレーショナルデータベースをセットアップ、運用、スケールできます。 + [PostgreSQL 向け Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html) を使用して、 AWS クラウドで PostgreSQL リレーショナルデータベース (DB) をセットアップ、運用、スケールできます。 + [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) は、ソースデータベーススキーマとカスタムコードの大部分をターゲットデータベースと互換性のある形式に自動的に変換することで、異種データベースの移行をサポートします。 **その他のツール** + [Oracle SQL Developer](https://www.oracle.com/database/technologies/appdev/sqldeveloper-landing.html) は、従来のデプロイとクラウドベースのデプロイの両方で Oracle データベースの開発と管理を簡素化する統合開発環境です。 + 「[pgAdmin](https://www.pgadmin.org/)」 は PostgreSQL 用のオープンソース管理ツールです。データベースオブジェクトの作成、管理、使用を支援するグラフィカルインターフェイスを提供します。このパターンでは、pgAdmin は RDS for PostgreSQL データベースインスタンスに接続し、データをクエリします。または、psql コマンドラインクライアントを使用することもできます。 ## ベストプラクティス + データセットの境界とエッジシナリオをテストします。 + 範囲外のインデックス条件にエラー処理を実装することを検討してください。 + スパースデータセットのスキャンを避けるためにクエリを最適化します。 ## エピック ### Oracle 連想配列の動作 (ソース) | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle でソース PL/SQL ブロックを作成する。 | 次の連想配列を使用するソース PL/SQL ブロックを Oracle で作成します。
DECLARE
    TYPE country_codes IS TABLE OF VARCHAR2(100) INDEX BY pls_integer;
    cc country_codes;
    cc_idx NUMBER := NULL;
BEGIN
    cc(7) := 'India';
    cc(3) := 'UK';
    cc(5) := 'USA';
    cc(0) := 'China';
    cc(-2) := 'Invalid';
    dbms_output.put_line('cc_length:' || cc.COUNT);
    IF (cc.COUNT > 0) THEN
        cc_idx := cc.FIRST;
        FOR i IN 1..cc.COUNT LOOP
            dbms_output.put_line('cc_idx:' || cc_idx || ' country:' || cc(cc_idx));
            cc_idx := cc.next(cc_idx);
        END LOOP;
    END IF;
END;
| DBA | | PL/SQL ブロックを実行する。 | Oracle でソース PL/SQL ブロックを実行します。連想配列のインデックス値の間にギャップがある場合、そのギャップにはデータが保存されません。そのため、Oracle ループはインデックス位置を介してのみイテレーションできます。 | DBA | | 出力の確認 | 非連続の間隔で 5 つの要素が配列 (`cc`) に挿入されました。配列数を次の出力に示します。
cc_length:5
cc_idx:-2 country:Invalid
cc_idx:0 country:China
cc_idx:3 country:UK
cc_idx:5 country:USA
cc_idx:7 country:India
| DBA | ### PostgreSQL の連想配列の動作 (ターゲット) | タスク | 説明 | 必要なスキル | | --- | --- | --- | | PostgreSQL でターゲット PL/pgSQL ブロックを作成する。 | 次の連想配列を使用するターゲット PL/pgSQL ブロックを PostgreSQL で作成します。
DO $$
DECLARE
    cc character varying(100)[];
    cc_idx integer := NULL;
BEGIN
    cc[7] := 'India';
    cc[3] := 'UK';
    cc[5] := 'USA';
    cc[0] := 'China';
    cc[-2] := 'Invalid';
    RAISE NOTICE 'cc_length: %', ARRAY_LENGTH(cc, 1);
    IF (ARRAY_LENGTH(cc, 1) > 0) THEN
        FOR i IN ARRAY_LOWER(cc, 1)..ARRAY_UPPER(cc, 1)
        LOOP
            RAISE NOTICE 'cc_idx:% country:%', i, cc[i];
        END LOOP;
    END IF;
END;
$$;
| DBA | | PL/pgSQL ブロックを実行する。 | ターゲット PL/pgSQL ブロックを PostgreSQL で実行します。連想配列のインデックス値の間にギャップがある場合、そのギャップにはデータが保存されません。そのため、Oracle ループはインデックス位置を介してのみイテレーションできます。 | DBA | | 出力の確認 | インデックス位置間のギャップには `NULL` が保存されるため、配列の長さは 5 を超えています。次の出力に示すように、ループは 10 回のイテレーションを完了して、配列内の 5 つの値を取得します。
cc_length:10
cc_idx:-2 country:Invalid
cc_idx:-1 country:
cc_idx:0 country:China
cc_idx:1 country:
cc_idx:2 country:
cc_idx:3 country:UK
cc_idx:4 country:
cc_idx:5 country:USA
cc_idx:6 country:
cc_idx:7 country:India
| DBA | ### Oracle の連想配列の動作をエミュレートする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 配列とユーザー定義型を使用してターゲット PL/pgSQL ブロックを作成する。 | パフォーマンスを最適化し、Oracle の機能に合わせるには、インデックス位置と対応するデータの両方を保存するユーザー定義型を作成します。このアプローチでは、インデックスと値との直接的な関連付けを維持することにより、不要なイテレーションを減らします。
DO $$
DECLARE
    cc country_codes[];
    cc_append country_codes := NULL;
    i record;
BEGIN
    cc_append.idx = 7;
    cc_append.val = 'India';
    cc := array_append(cc, cc_append);
    cc_append.idx = 3;
    cc_append.val = 'UK';
    cc := array_append(cc, cc_append);
    cc_append.idx = 5;
    cc_append.val = 'USA';
    cc := array_append(cc, cc_append);
    cc_append.idx = 0;
    cc_append.val = 'China';
    cc := array_append(cc, cc_append);
    cc_append.idx = - 2;
    cc_append.val = 'Invalid';
    cc := array_append(cc, cc_append);
    RAISE NOTICE 'cc_length: %', ARRAY_LENGTH(cc, 1);
    IF (ARRAY_LENGTH(cc, 1) > 0) THEN
        FOR i IN (
            SELECT
                *
            FROM
                unnest(cc)
            ORDER BY
                idx)
                LOOP
                    RAISE NOTICE 'cc_idx:% country:%', i.idx, i.val;
                END LOOP;
    END IF;
END;
$$;
| DBA | | PL/pgSQL ブロックを実行する。 | ターゲット PL/pgSQL ブロックを実行します。連想配列のインデックス値の間にギャップがある場合、そのギャップにはデータが保存されません。そのため、Oracle ループはインデックス位置を介してのみイテレーションできます。 | DBA | | 出力の確認 | 次の出力に示すように、ユーザー定義型には、入力されたデータ要素のみが保存されます。そのため、配列の長さは値の数と一致します。その結果、`LOOP` イテレーションは存在するデータのみを処理するように最適化されるため、空の位置を追跡する必要はありません。
cc_length:5
cc_idx:-2 country:Invalid
cc_idx:0 country:China
cc_idx:3 country:UK
cc_idx:5 country:USA
cc_idx:7 country:India
| DBA | ## 関連リソース **AWS ドキュメント** + [AWS データベースブログ](https://aws.amazon.com/blogs/database/) + [Oracle to Aurora PostgreSQL migration playbook](https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-postgresql-migration-playbook/chap-oracle-aurora-pg.html) **その他のドキュメント** + [Oracle associative arrays](https://docs.oracle.com/en/database/oracle/oracle-database/23/lnpls/associative-arrays.html#GUID-8060F01F-B53B-48D4-9239-7EA8461C2170) + [PostgreSQL array functions and operators](https://www.postgresql.org/docs/current/functions-array.html) + [PostgreSQL user-defined types](https://www.postgresql.org/docs/current/sql-createtype.html) # Amazon RDS の PostgreSQL DB インスタンスに対して暗号化された接続を有効にする *Amazon Web Services、Rohit Kapoor* ## 概要 Amazon Relational Database Service (Amazon RDS) は PostgreSQL DB インスタンスの SSL 暗号化をサポートしています。SSL を使用して、アプリケーションと Amazon RDS for PostgreSQL DB インスタンスとの間の PostgreSQL 接続を暗号化できます。デフォルトでは、Amazon RDS for PostgreSQL は SSL/TLS を使用し、すべてのクライアントが SSL/TLS 暗号化を使用して接続することを想定しています。Amazon RDS for PostgreSQL は TLS バージョン 1.1 および 1.2 をサポートします。 このパターンは、Amazon RDS for PostgreSQL DB インスタンスに対して暗号化された接続を有効にする方法を示しています。同じプロセスを使用して、Amazon Aurora PostgreSQL 互換エディションの暗号化接続を有効化できます。 ## 前提条件と制限事項 + アクティブな AWS アカウント + [Amazon RDS for PostgreSQL DB インスタンス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_RDS_Configuring.html) + [SSL バンドル](https://www.postgresql.org/docs/current/ssl-tcp.html) ## アーキテクチャ ![\[Amazon RDS の PostgreSQL DB インスタンスに対して暗号化された接続を有効にする\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4f87c6a3-b4ff-4248-96d3-a4a498659735/images/ccc5c880-1191-4c12-a255-6908b96b96a5.png) ## ツール + [pgAdmin](https://www.pgadmin.org/) は、オープンソースの PostgreSQL 向けの管理・開発プラットフォームです。pgAdmin を使用すると、Linux、Unix、macOS、および Windows で PostgreSQL 10 以降のデータベースオブジェクトを管理できます。 + [PostgreSQL エディタ](https://wiki.postgresql.org/wiki/PostgreSQL_Clients) は、クエリを作成、開発、実行したり、要件に応じてコードを編集したりする際に役立つ、よりユーザーフレンドリーなインターフェイスを提供します。 ## ベストプラクティス + セキュアでないデータベース接続をモニタリングします。 + データベースアクセス権を確認します。 + バックアップとスナップショットが保管中の場合に暗号化されていることを確認します。 + データベースアクセスをモニタリングします。 + 無制限のアクセスグループを避けてください。 + [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) で通知機能を強化しましょう。 + ポリシーの遵守状況を定期的にモニタリングします。 ## エピック ### 信頼できる証明書をダウンロードして信頼ストアにインポートする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 信頼できる証明書をコンピュータにロードします。 | コンピュータの信頼されたルート証明機関ストアに証明書を追加するには、次の手順に従います。(これらの手順では、例として Windows Server を使用しています)。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html) | DevOps エンジニア、移行エンジニア、DBA | ### 強制的に SSL 接続する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | パラメータグループを作成し、rds.force\$1ssl パラメータを設定します。 | PostgreSQL DBインスタンスにカスタムパラメータグループがある場合は、パラメータグループを編集し、`rds.force_ssl` を 1 に変更します。DB インスタンスが `rds.force_ssl` を有効にしていないデフォルトのパラメータグループを使用している場合は、新しいパラメータグループを作成します。新しいパラメータグループは Amazon RDS API を使用するか、以下の手順に従って手動で変更できます。パラメータグループを作成するには：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html)パラメータグループを PostgreSQL DB インスタンスに関連付けるには：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html)詳細については、「 [Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithDBInstanceParamGroups.html)」を参照してください。 | DevOps エンジニア、移行エンジニア、DBA | | 強制的に SSL 接続するようにします。 | 移行元の Amazon RDS for PostgreSQL インスタンスに接続します。SSL を使用しない接続は拒否され、エラーメッセージが表示されます。詳細については、「 [Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Requiring)」を参照してください。 | DevOps エンジニア、移行エンジニア、DBA | ### SSL 拡張機能のインストール | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSL 拡張機能をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html)詳細については、「 [Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html)」を参照してください。 | DevOps エンジニア、移行エンジニア、DBA | ### PostgreSQL クライアントを SSL 向けに設定します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SSL 向けにクライアントを設定します。 | SSL を使用すると、TLS プロトコルを使用する暗号化接続をサポートする PostgreSQL サーバーを起動できます。サーバーは、同じ TCP ポート上の標準接続と SSL 接続をリッスンし、SS Lを使用するかどうかを接続クライアントとネゴシエートします。デフォルトでは、このクライアントオプションは有効になっています。psql クライアントを使用している場合：　[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html)他の PostgreSQL クライアントの場合:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html)これらのクライアントについては、以下のページを確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.html) | DevOps エンジニア、移行エンジニア、DBA | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | SSL 証明書をダウンロードできません。 | ウェブサイトへの接続を確認してから、証明書をローカルコンピュータにダウンロードしてください。 | ## 関連リソース + 「[Amazon RDS for PostgreSQL ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html)」 + 「[PostgreSQL DB インスタンスで SSL を使用する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html)」 (Amazon RDS ドキュメント) + 「[SSL による TCP/IP 接続のセキュリティ保護](https://www.postgresql.org/docs/9.1/ssl-tcp.html)」 (PostgreSQL ドキュメント) + 「[SSL を使用する](https://jdbc.postgresql.org/documentation/ssl/)」 (JDBC ドキュメント) # 既存の Amazon RDS for PostgreSQL DB インスタンスを暗号化する *Amazon Web Services、Piyush Goyal、Shabana Raghu、Yaser Raja* ## 概要 このパターンでは、AWS クラウドの Amazon Relational Database Service (Amazon RDS) for PostgreSQL DB インスタンスを最小のダウンタイムで暗号化する方法を説明しています。このプロセスは、Amazon RDS for MySQL DB インスタンスでも機能します。　 Amazon RDS DB インスタンスの暗号化は、DB インスタンスの作成時に有効にすることができますが、作成後に暗号化を有効にすることはできません。ただし、DB インスタンスのスナップショットを作成し、そのスナップショットの暗号化済みコピーを作成すると、暗号化されていない DB インスタンスに暗号化を追加できます。この暗号化されたスナップショットから DB インスタンスを復元することで、元の DB インスタンスの暗号化されたコピーを取得できます。プロジェクトがこのアクティビティの間（少なくとも書き込みトランザクションの場合）ダウンタイムを許可されている場合は、これがすべての作業になります。DB インスタンスの暗号化された新しいコピーが使用可能になると、アプリケーションを新しいデータベースに接続できます。　 ただし、プロジェクトでこのアクティビティによる大幅なダウンタイムが許容されない場合は、ダウンタイムを最小限に抑えるための代替アプローチが必要です。　 このパターンでは、AWS Database Migration Service (AWS DMS) を使用してデータを移行し、継続的に複製します。これにより、新しい暗号化されたデータベースへのカットオーバーを最小限のダウンタイムで行うことができます。  Amazon RDS の暗号化された DB インスタンスでは、Amazon RDS DB インスタンスをホストしているサーバーでデータを暗号化するために、業界標準の AES-256 暗号化アルゴリズムを使用します。データが暗号化されると、Amazon RDS はパフォーマンスの影響を最小限に抑えながら、データへのアクセスと復号化の認証を透過的に処理します。暗号化を使用するために、データベースのクライアントアプリケーションを変更する必要はありません。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + 暗号化されていないAmazon RDS for PostgreSQL DB インスタンス + AWS DMS タスクの使用経験 (作成、変更、または停止) (AWS DMS ドキュメントの「[AWS DMS タスクの使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html)」を参照) + データベースを暗号化するための AWS Key Management Service (AWS KMS) に関する知識 ([AWS KMS ドキュメント](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)を参照) **機能制限** + Amazon RDS DB インスタンスの暗号化は、DB インスタンスの作成時にのみ有効にすることができます。作成後に暗号化を有効にすることはできません。 + [ログに記録されていないテーブル](https://www.postgresql.org/docs/current/sql-createtable.html)のデータは、スナップショットを使用しても復元されません。詳細については、「[PostgreSQL を使用するためのベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html#CHAP_BestPractices.PostgreSQL)」を参照してください。 + 暗号化されていない DB インスタンスのリードレプリカを暗号化することや、暗号化されている DB インスタンスのリードレプリカを暗号化しないようにすることはできません。 + 暗号化されていないバックアップやスナップショットを、暗号化された DB インスタンスに復元することはできません。 + AWS DMS はシーケンスを自動的に転送しないため、これを処理するには追加の手順が必要です。 詳細については、Amazon RDS ドキュメントの「[Amazon RDS 暗号化 DB インスタンスの制限事項](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html#Overview.Encryption.Limitations)」を参照してください。 ## アーキテクチャ **ソースアーキテクチャ** + 暗号化されていない RDS DB インスタンス **ターゲット アーキテクチャ** + 暗号化されていない RDS DB インスタンス + ターゲット RDS DB インスタンスは、ソース RDS DB インスタンスの DB スナップショットコピーを復元することによって作成されます。 + AWS KMS キーは、スナップショットの復元中の暗号化に使用されます。 + AWS DMS レプリケーションタスクを使用してデータを移行します。 ![\[プロセスは AWS DMS を使用して、既存の Amazon RDS for PostgreSQL DB インスタンスを新しい DB に暗号化します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/820d17c0-0eed-4ed9-9f43-cbada081d924/images/44dd8420-d89d-466e-b7fb-1bdafab8f7f9.png) ## ツール **暗号化を有効化するためのツール:** + 暗号化のための AWS KMS キー – 暗号化された DB インスタンスを作成するときは、カスタマーマネージドキーまたは Amazon RDS の AWS マネージドキーを選択して、DB インスタンスを暗号化できます。カスタマーマネージドキーのキー識別子を指定しない場合、Amazon RDS は新しい DB インスタンスに AWS マネージドキーを使用します。Amazon RDS は、Amazon RDS 用の AWS マネージドキーを AWS アカウントに作成します。AWS アカウントには、AWS リージョンごとに Amazon RDS の AWS マネージドキーがあります。Amazon RDS の暗号化に KMS キーを使用する方法の詳細については、「[Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)」を参照してください。 **継続的なレプリケーションに使用されるツール**: + AWS DMS - AWS Database Migration Service (AWS DMS) を使用して、ソース DB からターゲット DB に変更を複製します。ダウンタイムを最小限に抑えるために、ソース DB とターゲット DB を同期させることが重要です。AWS DMS の設定とタスクの作成については、「[AWS DMS のドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」を参照してください。 ## エピック ### ソース DB インスタンスのスナップショットを作成し、暗号化します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソース PostgreSQL DB インスタンスの詳細を確認します。 | Amazon RDS コンソールで、ソース PostgreSQL DB インスタンスを選択します。[**設定**] タブで、インスタンスの暗号化が有効になっていないことを確認します。画面の図については、「[追加情報](#encrypt-an-existing-amazon-rds-for-postgresql-db-instance-additional)」セクションを参照してください。 | DBA | | DB スナップショットを作成します。 | 暗号化するインスタンスの DB スナップショットを作成します。スナップショットを作成するのにかかる時間は、データベースのサイズによって異なります。手順については、Amazon RDS ドキュメントの「[DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)」を参照してください。 | DBA | | スナップショットを暗号化します。　 | Amazon RDS コンソールのナビゲーションペインで、[**スナップショット**] を選択し、作成した DB スナップショットを選択します。[**アクション**] では、[**スナップショットのコピー**] を選択します。対応するフィールドで、送信先の AWS リージョンと DB スナップショットのコピー名を指定します。[**暗号化を有効にする**] チェックボックスを選択します。[**マスターキー**] では、DB スナップショットの暗号化に使用する KMS キー識別子を指定します。[**スナップショットをコピー**] を選択します。詳細については、Amazon RDS のドキュメントの「[スナップショットのコピー](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html)」を参照してください。 | DBA | ### ターゲット DB インスタンスを準備します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DB スナップショットを復元します。 | Amazon RDS コンソールで、[**スナップショット**] タブを選択します。作成した暗号化スナップショットを選択します。[**アクション**]、[**スナップショットの復元**] の順に選択します。**DB インスタンス識別子**として、新しい DB インスタンスの一意の名前を入力します。インスタンスの詳細を確認してから、[**DB インスタンスの復元**] を選択します。新しい、暗号化された DB インスタンスがスナップショットから作成されます。詳細については、Amazon RDS ドキュメントの「[DB スナップショットからの復元](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html)」を参照してください。 | DBA | | AWS DMS を使用してデータを移行します。 | AWS DMS コンソールで、AWS DMS タスクを作成します。[**移行タイプ**] では、[**既存のデータを移行して進行中の変更を複製する**] を選択します。[**タスク設定**] の [**ターゲットテーブル作成モード**] では、[**切り詰め**] を選択します。詳細については、AWS DMS ドキュメントの「[タスクの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html)」を参照してください。 | DBA | | データ検証を有効にします。 | [**タスク設定**] で、[**検証を有効にする**] を選択します。これにより、ソースデータとターゲットデータを比較して、データが正確に移行されたことを確認できます。  | DBA | | ターゲット DB インスタンスの制約を無効にします。 | ターゲット DB インスタンスで、[トリガーと外部キーの制約をすべて無効](https://www.postgresql.org/docs/current/sql-altertable.html)にしてから、AWS DMS タスクを開始します。トリガーと外部キーの制約を無効にする詳細については、[AWS DMS ドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.PostgreSQL.html)を参照してください。 | DBA | | データを検証します。 | フルロードが完了したら、ターゲット DB インスタンスのデータを検証して、ソースデータと一致するかどうかを確認します。詳細については、AWS DMS ドキュメントの「[AWS DMS のデータ検証](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)」を参照してください。 | DBA | ### ターゲット DB インスタンスへのカットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソース DB インスタンスに対する書き込み操作を停止します。 | ソース DB インスタンスでの書き込み操作を停止して、アプリケーションのダウンタイムを開始できるようにします。AWS DMS がパイプライン内のデータのレプリケーションを完了したことを検証します。ターゲット DB インスタンスで、トリガーと外部キーを有効にします。 | DBA | | データベースシーケンスの更新 | ソースデータベースにシーケンス番号が含まれている場合は、ターゲットデータベースのシーケンスを検証して更新します。 | DBA | | アプリケーションのエンドポイントを設定します。 | アプリケーション接続で、新しい Amazon RDS DB インスタンスのエンドポイントを使用するように設定します。現在、DB インスタンスは暗号化されています。 | DBA、アプリ所有者 | ## 関連リソース + 「[AWS DMS タスクの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html)」  + 「[Amazon CloudWatch を使用したレプリケーション タスクのモニタリング](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch)」 + 「[AWS DMS タスクのモニタリング](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html)」 + 「[Amazon RDS 暗号化キーを更新する](https://aws.amazon.com/premiumsupport/knowledge-center/update-encryption-key-rds/)」 ## 追加情報 ソース PostgreSQL DB インスタンスの暗号化の確認: ![\[ソース PostgreSQL DB インスタンスの概要ページには、ストレージに対して暗号化が有効になっていないというメッセージが表示されます。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/820d17c0-0eed-4ed9-9f43-cbada081d924/images/d53d1dab-b5c2-452d-b823-ba3d6508ad15.png) このパターンに関するその他の注意事項: + `rds.logical_replication` パラメータを 1 に設定して、PostgreSQL でのレプリケーションを有効にします。 **重要な注意:** レプリケーションスロットは、ファイルが外部から (たとえば `pg_recvlogical` によって) 消費されるまで、抽出、変換、ロード(ETL)ジョブを介して、あるいは AWS DMS 経由で先書きログ (WAL) ファイルを保持します。`rds.logical_replication` パラメータ値を 1 に設定すると、AWS DMS は `wal_level`、`max_wal_senders`、`max_replication_slots`、および `max_connections` パラメータを設定します。論理レプリケーションスロットが存在するが、replicationスロットによって予約された WAL ファイルにコンシューマが存在しない場合、トランザクション ログ ディスクの使用量が増加し、使用可能なストレージ容量が継続的に減少することがあります。この問題を解決するための詳細情報と手順については、AWS サポートナレッジセンターの「[Amazon RDS for PostgreSQL で "デバイスに空き領域がありません" や "DiskFull" というエラーが発生する理由を知りたいです。](https://aws.amazon.com/premiumsupport/knowledge-center/diskfull-error-rds-postgresql/)」を参照してください。 + DB スナップショットを作成した後、ソース DB インスタンスに加えたスキーマの変更は、ターゲット DB インスタンスには反映されません。 + 暗号化された DB インスタンスを作成したら、その DB インスタンスで使用されている KMS キーを変更することはできません。したがって、暗号化された DB インスタンスを作成する前に、KMS キーの要件を必ず確認してください。 + AWS DMS タスクを実行する前に、ターゲット DB インスタンスのトリガーと外部キーを無効にする必要があります。タスクが完了した後、これらを再度有効にすることができます。 # 起動時に Amazon RDS データベースの自動タグ付けを強制する *Amazon Web Services、Susanne Kangnoh、Archit Mathur* ## 概要 Amazon Relational Database Service (Amazon RDS) は、Amazon Web Services (AWS) クラウドでリレーショナルデータベースを簡単にセットアップし、運用し、拡張することのできるウェブサービスです。業界スタンダードのリレーショナルデータベース向けに、費用対効果に優れたエクステンションを備え、一般的なデータベース管理タスクを管理します。 タグ付けを使用すると、さまざまな方法で AWS リソースを分類できます。リレーショナルデータベースのタグ付けは、アカウントに多数のリソースがあり、特定のリソースをすばやく識別する場合に便利です。Amazon RDS タグを使用して、RDS DB インスタンスにカスタムメタデータを追加できます。　 各タグは、ユーザー定義のキーと値で構成されます。組織の要件に適合する一貫したタグのセットを作成することをお勧めします。 このパターンでは、RDS DB インスタンスのモニタリングとタグ付けに役立つ AWS CloudFormation テンプレートについて説明します。このテンプレートは、AWS CloudTrail **CreateDBInstance** イベントをモニタリングする Amazon CloudWatch Events イベントを作成します。(CloudTrail は、Amazon RDS の API コールをイベントとしてキャプチャします。) このイベントを検出すると、定義したタグキーと値を自動的に適用する AWS Lambda 関数を呼び出します。テンプレートでは、Amazon Simple Notification Service (Amazon SNS) を使用して、インスタンスがタグ付けされたという通知も送信されます。 ## 前提条件と制限事項 **前提条件** + アクティブな AWS アカウント + Amazon Simple Storage Service (Amazon S3) バケットに、Lambda コードをアップロードします。 + タグ付けの通知を受信するメールアドレス **制限事項** + このソリューションは、CloudTrail の **CreateDBInstance** イベントをサポートします。他のイベントの通知は作成されません。 ## アーキテクチャ **ワークフローアーキテクチャ** ![\[Workflow diagram showing AWS のサービス interaction for RDS instance creation and notification.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5541bc1e-e00f-4b5a-94b7-bb1808b5591a/images/ec0bcf92-f986-4af3-bfe7-d2c5e04051c5.png) **自動化とスケール** + AWS CloudFormation テンプレートは、さまざまな AWS リージョンとアカウントに複数回使用できます。各リージョンまたはアカウントで、テンプレートを 1 回実行するだけで済みます。 ## ツール **AWS サービス** + [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) – AWS CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、および運用とリスクの監査を行えるように支援する AWS のサービスです。ユーザー、ロール、または AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録されます。  + [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) – Amazon CloudWatch Events は、AWS リソースの変更を説明するシステムイベントのほぼリアルタイムのストリームを配信します。CloudWatch Events は、運用上の変更が生じると同時にそれらを認識して対応し、環境に応答するためのメッセージを送信する、機能をアクティブ化する、変更を行う、および状態情報を収集することによって、必要に即した是正措置を講じます。  + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。課金は実際に消費したコンピューティング時間に対してのみ発生します。コードが実行されていない場合、料金は発生しません。 + [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html) — Amazon Simple Storage Service (Amazon S3) は、拡張性の高いオブジェクトストレージサービスで、ウェブサイト、モバイルアプリケーション、バックアップ、データレイクなど、幅広いストレージソリューションに使用できます。 + [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) –Amazon Simple Notification Service (Amazon SNS) は、アプリケーション、エンドユーザー、およびデバイスでクラウドから通知を瞬時に送受信できるようにするウェブサービスです。  **コード** このパターンには、次の 2 つのファイルを含む添付ファイルが含まれます。 + `index.zip`は、このパターンの Lambda コードを含む圧縮ファイルです。 + `rds.yaml` は、Lambda コードをデプロイする CloudFormation テンプレートです。 これらのファイルの使用方法については、「*エピック*」セクションを参照してください。 ## エピック ### Lambda コードをデプロイします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットにコードをアップロードします。 | 新しい S3 バケットを作成するか、既存の S3 バケットを使用して、添付 `index.zip` ファイル (Lambda コード) をアップロードします。このバケットは、モニタリングするリソース (RDS DB インスタンス) と同じ AWS リージョンに存在する必要があります。 | クラウドアーキテクト | | CloudFormation テンプレートをデプロイする。 | S3 バケットと同じ AWS リージョンで Cloudformation コンソールを開き、添付ファイルで提供されている `rds.yaml` ファイルをデプロイします。次のエピックでは、テンプレートパラメータの値を指定します。 | クラウドアーキテクト | ### CloudFormation テンプレートのパラメータを入力します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケット名を入力します。 | 最初のエピックで作成または選択した S3 バケットの名前を入力します。この S3 バケットには,Lambda コードの.zip ファイルが含まれており、CloudFormation テンプレートおよびモニタリングする RDS DB インスタンスと同じ AWS リージョンに存在する必要があります。 | クラウドアーキテクト | | S3 キーを入力します。 | S3 バケット内の Lambda コードの.zip ファイルの場所を、先頭にスラッシュを付けずに指定します (例えば、`index.zip`、`controls/index.zip`)。 | クラウドアーキテクト | | メールアドレスを入力します。 | 違反の通知を受信するメールアドレスを入力します。 | クラウドアーキテクト | | ログレベルを指定します。 | ログ記録レベルと詳細レベルを定義します。`Info` アプリケーションの進行状況に関する詳細な情報メッセージを指定し、デバッグのみに使用されます。`Error` それでもアプリケーションの実行を継続できるエラーイベントを指定します。`Warning` 潜在的に危険有害な状況を示します。 | クラウドアーキテクト | | RDS DB インスタンスのタグキーと値を入力します。 | RDS インスタンスに自動適用したい必須のタグキーと値を入力します。詳細については、AWS ドキュメントの「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.html)」を参照してください。 | クラウドアーキテクト | ### サブスクリプションを確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メールサブスクリプションを確認します。 | テンプレートが正常にデプロイされると、指定されたメールアドレスにサブスクリプションのメールメッセージが送信されます。インスタンスがタグ付けされたときに通知を受信するには、このメールのサブスクリプションを確認する必要があります。 | クラウドアーキテクト | ## 関連リソース + 「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)」 (Amazon S3 ドキュメント) + 「[Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.html)」 (Amazon Aurora ドキュメント) + 「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/upload-objects.html)」 (Amazon S3 ドキュメント) + 「[AWS CloudTrail を使用して AWS API コールでトリガーする CloudWatch Events ルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) (Amazon CloudWatch ドキュメント) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/5541bc1e-e00f-4b5a-94b7-bb1808b5591a/attachments/attachment.zip)」 # DynamoDB テーブルのコストをオンデマンドで見積る *Moinul Al-Mamun、Amazon Web Services* ## 概要 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) は、ペタバイトスケールでもミリ秒単位 1 桁のレイテンシーを実現する NoSQL トランザクションデータベースです。この Amazon Web Services (AWS) のサーバーレスサービスは、一貫したパフォーマンスとスケーラビリティにより人気が高まっています。 基盤となるインフラストラクチャをプロビジョニングする必要はありません。1 つのテーブルが最大でペタバイトまで増加する可能性があります。 オンデマンドキャパシティモードでは、アプリケーションがテーブルに対して実行するデータの読み取りと書き込みに対して、リクエストごとに料金を支払います。AWS の料金は、1 か月あたりの累積読み取りリクエスト単位 (RRU) と書き込みリクエスト単位 (WRU) に基づいています。DynamoDB では、1 か月にわたるテーブルサイズの継続的なモニタリングに基づいてストレージ料金が決定されます。ポイントインタイムリカバリ (PITR) による継続的バックアップのサポートを提供します。DynamoDB では、1 か月にわたる PITR 対応テーブルサイズの継続的なモニタリングに基づいてバックアップ料金が決定されます。 プロジェクトの DynamoDB コストの見積もりでは、製品ライフサイクルのさまざまな段階で消費される RRU、WRU、およびストレージの値を計算することが重要です。大まかなコスト見積もりには [AWS 料金見積りツール](https://calculator.aws/#/createCalculator/DynamoDB)を使用できますが、テーブルに必要な RRU、WRU、およびストレージ要件のおおよその値を提供する必要があります。プロジェクトの開始時に、これらの値を見積もるのが難しい場合があります。AWS 料金見積りツールでは、データの増加率や項目サイズは考慮されません。また、ベーステーブルおよびグローバルセカンダリインデックス (GSI) の読み取りと書き込みの回数は個別に考慮されません。AWS 料金見積りツールを使用するには、これらすべての要素を見積もり、WRU、RRU、ストレージサイズの大まかな数値を想定してコストを見積もる必要があります。 このパターンは、DynamoDB の基本的なコスト要因（書き込み、読み取り、ストレージ、バックアップ、リカバリの費用など）を見積もるメカニズムと再利用可能な Microsoft Excel テンプレートが提供されます。AWS 料金見積りツールよりも詳細で、ベーステーブルと GSI の要件を個別に検討します。また、項目データの月次増加率を考慮して、3 年間の費用を予測します。 ## 前提条件と制限事項 **前提条件** + DynamoDB と DynamoDB データモデル設計に関する基本的な知識 + DynamoDB の料金、WRU、RRU、ストレージ、バックアップとリカバリに関する基本的な知識 (詳細については、「[オンデマンドキャパシティの料金](https://aws.amazon.com/dynamodb/pricing/on-demand/)」を参照してください) + DynamoDB のデータ、データモデル、項目サイズに関する知識 + DynamoDB GSI に関する知識 **機能制限** + テンプレートではおおよその計算のみで、すべての構成に適応はしていません。より正確な見積もりを得るには、ベーステーブルと GSI の各項目のサイズを個別に試算する必要があります。　 + より正確な見積もりでは、各項目の書き込み (挿入、更新、削除) 回数と読み取り回数の平均を考慮する必要があります。 + このパターンでは、固定データ増加の仮定に基づいて、今後数年間の書き込み、読み取り、ストレージ、バックアップ、リカバリ費用のみの見積もりが可能です。 ## ツール **AWS サービス** + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。 **その他のツール** + [AWS 料金見積りツール](https://calculator.aws/#/createCalculator/DynamoDB)は、ユースケースの見積りを作成するために使用できるウェブベースの計画ツールです。 ## ベストプラクティス コストを低く抑えるには、次の DynamoDB 設計のベストプラクティスを考慮してください。 + [パーティションキーの設計](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-uniform-load.html) — カーディナリティの高いパーティションキーを使用して負荷を均等に分散します。 + [隣接関係リストの設計パターン](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html) — この設計パターンは、一対多および多対多リレーションシップを管理する場合に使用します。 + [スパースインデックス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-indexes-general-sparse-indexes.html) — GSI にはスパースインデックスを利用します。GSI を作成する際、パーティションキーおよびソートキー (オプション) を指定します。対応する GSI パーティションキーを含むベーステーブルの項目だけが、スパースインデックスに表示されます。これにより GSI を小さく抑えることができます。 + [インデックスの多重定義](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-gsi-overloading.html) — さまざまなタイプの項目のインデックス作成に、同じ GSI を使用します。 + [GSI 書き込みシャーディング](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-indexes-gsi-sharding.html) — うまくシャーディングしてパーティション全体にデータを分散することで、クエリを効率的かつ高速に行うことができます。 + [大きなアイテム](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html) — テーブル内にメタデータのみを保存し、blob を Amazon S3 に保存し、リファレンスを DynamoDB に保持します。大きな項目を複数の項目に分割し、ソートキーを使用して効率的にインデックスを作成します。 設計のベストプラクティスについての詳細は、[Amazon DynamoDB の「デベロッパーガイド」](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)を参照してください。 ## エピック ### DynamoDB データモデルから項目情報を抽出します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 項目サイズを取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.html) | データエンジニア | | 書き込み費用を見積もります。 | オンデマンドキャパシティモードでの書き込み費用を見積もるには、1 か月に消費される WRU の値を測定する必要があります。そのため、以下の要素を考慮する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.html)詳細については、「追加情報」セクションをご覧ください。 | データエンジニア | | 読み取り費用を見積もります。 | オンデマンドモードでの読み取り費用を見積もるには、まず 1 か月に消費される RRU の値を測定する必要があります。そのため、以下の要素を考慮する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.html) | データエンジニア、アプリ開発者 | | ストレージのサイズと費用を見積もります。 | 最初に、テーブルの項目サイズに基づいて、月間平均ストレージ要件を見積もります。次に、ストレージサイズに AWS リージョンの GB あたりのストレージ料金を掛けてストレージ費用を計算します。 書き込み費用を見積もるためのデータを既に入力している場合は、ストレージサイズの計算のためにデータを再度入力する必要はありません。それ以外の場合、ストレージサイズの見積りでは、以下の要素を考慮する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.html) | データエンジニア | ### Excel テンプレートに項目とオブジェクトの情報を入力します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 添付ファイルセクションから Excel テンプレートをダウンロードし、ユースケーステーブルに合わせて調整します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.html) | データエンジニア | | Excel テンプレートに情報を入力します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-cost-of-a-dynamodb-table-for-on-demand-capacity.html)テンプレートには、情報、メタデータ、リレーションシップの 3 つの項目またはエンティティが含まれます。2 つの GSI があります。ユースケースに合わせて、さらに項目が必要な場合は、新しい行を作成してください。さらに GSI が必要な場合は、既存の GSI ブロックをコピーして貼り付け、必要な数の GSI ブロックを作成します。次に、「合計」列と「合計」列の計算を調整します。 | データエンジニア | ## 関連リソース **リファレンス** + 「[Amazon DynamoDB のオンデマンドキャパシティ料金表](https://aws.amazon.com/dynamodb/pricing/on-demand/)」 + 「[DynamoDB 用の AWS 料金見積りツール](https://calculator.aws/#/createCalculator/DynamoDB)」 + 「[DynamoDB を使用した設計とアーキテクチャに関するベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)」 + 「[DynamoDB の使用開始](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html)」 **ガイドとパターン** + 「[Amazon DynamoDB によるデータのモデリング](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-data-modeling/)」 + 「[Amazon DynamoDB テーブルのストレージ費用を見積もる](https://apg-library.amazonaws.com/content/9b74399d-9655-47ee-b9b3-de46b65bc4e3)」 ## 追加情報 **費用計算の例** DynamoDB データモデルの設計では、1 つの製品について 3 つの項目が表示され、平均項目サイズは 4 KB です。DynamoDB ベーステーブルに新しい製品を追加すると、項目数 x (項目サイズ/1 KB 書き込み単位) = 3 x (4/1) = 12 WRU が消費されます。この例では、1 KB を書き込むと、製品は 1 WRU を消費します。　  **費用計算の例** RRU の見積もりを求めるには、各項目の 1 か月にわたる読み取り回数の平均を考慮してください。たとえば、情報項目は 1 か月に平均で 10 回読み取られ、メタデータ項目は 2 回、リレーションシップアイテムは 5 回読み取られます。このテンプレート例では、すべてのコンポーネントの合計 RRU = 毎月作成される新しいコンポーネントの数 x コンポーネントあたりの RRU = 1,000 万 x 17 RRU = 1 か月あたり 1 億 7,000 万 RRU です。　 毎月、新しいもの (コンポーネントまたは製品) が追加され、製品の総数は時間の経過に伴い増えていきます。そのため、RRU の要件も時間に伴い増加していきます。　 + 最初の 1 か月の RRU の消費量は 1 億 7,000 万になります。　 + 2 か月目の RRU の消費量は 2 x 1 億 7,000 万 = 3 億 4,000 万になります。　 + 3 か月目の RRU の消費量は 3 x 1 億 7,000 万 = 5 億 1,000 万になります。　 次のグラフは、毎月の RRU 消費量と費用予測を示しています。　 ![\[コストよりも急激に増加する RRU の消費量。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1797b48f-a183-4f25-811f-44921c3a48ee/images/3505bfc8-694d-4acc-8585-cd71258fa315.png) 注意：グラフ内の料金は説明の目的でのみ使用されています。ユースケースに適応した正確な予測を作成するには、AWS 料金ページを確認し、その料金を Excel シートに入力してください。 **ストレージ、バックアップ、リカバリ費用の計算例** DynamoDB ストレージ、バックアップ、リカバリはすべて相互に接続されています。バックアップはストレージに関係し、リカバリはバックアップサイズに関係します。テーブルのサイズが大きくなると、それに対応するストレージ、バックアップ、およびリカバリの費用も比例して増加します。 *ストレージのサイズと費用* ストレージ費用は、データの増加率に応じて時間の経過に伴い増加していきます。例えば、ベーステーブルと GSI にあるコンポーネントまたは製品の平均サイズが 11 KB で、データベーステーブルに毎月 1,000 万個の新しい製品が追加されると仮定します。その場合、DynamoDB テーブルのサイズは (11 KB x 1000 万) /1024/1024 = 1 か月あたり 105 GB 増加します。最初の月のテーブルストレージのサイズは 105 GB になり、2 か月目には 105 \$1 105 = 210 GB というようになります。　 + 最初の月には、AWS リージョンのストレージ費用は 105 GB x 1 GB あたりのストレージ料金になります。  + 2 か月目には、お住まいのリージョンのストレージ費用は 210 GB x 1 GB あたりのストレージ料金になります。 + 3 か月目には、そのリージョンのストレージ費用は 315 GB x 1 GB あたりのストレージ料金になります。　 今後 3 年間のストレージサイズと費用については、「*ストレージサイズと予測*」セクションを参照してください。 バックアップの費用 バックアップの費用は、データの増加率に応じて時間の経過に伴い増加していきます。ポイントインタイムリカバリ (PITR) による継続的なバックアップを有効にする場合、継続的なバックアップの料金は、ストレージの月間平均 GB 単位に基づいて課金されます。1 か月あたりの平均バックアップサイズは、テーブルのストレージサイズと同じですが、実際のサイズは若干異なる場合があります。新しい製品が毎月追加されるため、ストレージの合計サイズとバックアップサイズは時間の経過の伴い増加していきます。例えば、最初の月の平均バックアップサイズは 105 GB でしたが、2 か月目には 210 GB に増える可能性があります。 + 最初の月のバックアップ費用は、お使いの AWS リージョンの連続バックアップ料金 (GB あたり 105 GB x) になります。  + 2 か月目のバックアップ費用は、お住まいのリージョンの 1 GB あたり 210 GB/月 x 継続バックアップ料金になります。 + 3 か月目のバックアップ費用は、お住まいのリージョンの 1 GB あたりの継続バックアップ料金が 315 GB/月 \$1 になります。 + 以降も同様になります バックアップ費用は、「*ストレージサイズとコストの予測*」セクションのグラフに含まれています。 リカバリ費用 PITR を有効にした状態で継続的なバックアップを行う場合、リカバリ操作料金はそのサイズに基づいて計算されます。リカバリするたびに、リカバリデータのギガバイト数に基づいて支払いが発生します。テーブルのサイズが大きく、1 か月に複数回リカバリを実行すると、コストが高くなります。 リストア費用を見積もるために、この例では毎月月末に PITR 復元を実行することを想定しています。この例では、月間平均バックアップサイズをその月のリカバリデータサイズとして使用しています。最初の月の平均バックアップサイズは 105 GB で、月末の復元データサイズは 105 GB です。2 か月目は 210 GB になり、以降も同様になります。 リカバリ費用は、データの増加率に応じて時間の経過に伴い増加していきます。 + 最初の月には、105 GB x AWS リージョンの GB あたりの復元料金になります。  + 2 か月目のリカバリ費用は、210 GB \$1 お住まいのリージョンの GB あたりの復元料金になります。 + 3 か月目のリカバリ費用は、315 GB \$1 お住まいのリージョンの GB あたりの復元料金になります。 詳細については、Excel テンプレートの [ストレージ、バックアップ、リカバリ] タブと次のセクションのグラフを参照してください。 *ストレージのサイズとコストの予測* テンプレートでは、実際の課金ストレージサイズは、標準テーブルクラスの毎月 25 GB の無料利用枠を差し引いて計算されます。シートには、月次値ごとに分割された予測グラフが表示されます。 次のグラフの例では、今後 36 か月間の月間ストレージサイズ (GB)、請求可能なストレージ費用、オンデマンドバックアップ費用、およびリカバリ費用を予測しています。コストの見積り グラフから、ストレージ、バックアップ、リカバリの費用は、ストレージサイズの増加に比例して増加することが分かります。 ![\[ストレージサイズは 3,000 を上回り、コストは 1,000 未満です。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1797b48f-a183-4f25-811f-44921c3a48ee/images/fd9f06d0-bc9c-4b4e-8cbd-3e527fe09e88.png) 注意：グラフ内の料金は説明の目的でのみ使用されています。ユースケースに適応した正確な料金を作成するには、AWS 料金ページを確認し、その料金を Excel シートに入力してください。 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/1797b48f-a183-4f25-811f-44921c3a48ee/attachments/attachment.zip)」 # Amazon DynamoDB テーブルのストレージコストを推定 *Moinul Al-Mamun、Amazon Web Services* ## 概要 Amazon DynamoDB は、ペタバイトスケールでもミリ秒単位 1 桁のレイテンシーを実現する NoSQL トランザクションデータベースです。のこの一般的なサーバーレスサービスは、一貫したパフォーマンスとスケーラビリティ AWS を提供します。ストレージをプロビジョニングする必要はなく、単一のテーブルは最大でペタバイト単位の規模まで拡張できます。  DynamoDB は、1 か月間にわたってテーブルのサイズを継続的にモニタリングしてストレージ料金を決定します。 AWS その後、 はストレージの平均サイズをギガバイト単位で請求します。テーブルが時間の経過とともに大きくなればなるほど、ストレージコストも増加します。ストレージコストを計算するには「[AWS 料金見積りツール](https://calculator.aws/#/createCalculator/DynamoDB)」を使用できますが、グローバルセカンダリインデックス (GSI) を含むテーブルのおおよそのサイズを提供する必要があります。プロジェクトの開始時には、見積もることは非常に困難です。また、 AWS 料金計算ツールでは、データの増加率は考慮されません。 このパターンでは、DynamoDB ストレージのサイズとコストを計算するためのメカニズムと、再利用可能な Microsoft Excel テンプレートを提供します。ベーステーブルと GSI のストレージ要件を別々に考慮します。個々のアイテムのサイズと時間の経過に伴うデータの増加率を考慮して、ストレージサイズを計算します。  見積もりを求めるには、次の 2 つの情報をテンプレートに挿入します： + ベーステーブルと GSI の個々の項目サイズ (キロバイト) + 1ヶ月間に、テーブルに追加できる新しいオブジェクトまたは製品の平均数 (例、1,000 万) このテンプレートは、次の例に示すように、今後 3 年間のストレージとコストの予測グラフを生成します。 ![\[低い線はコストでゆっくりと上昇し、高い線はストレージでより速く上昇します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9b74399d-9655-47ee-b9b3-de46b65bc4e3/images/c0436252-cc42-4ea3-ac50-c0455aece39d.png) ## 前提条件と制限事項 **前提条件** + DynamoDB に関する基本的な知識 (DynamoDB のストレージと料金設定を含む) + DynamoDB のデータ、データモデル、項目サイズに関する知識 + DynamoDB グローバルセカンダリインデックス (GSI) に関する知識 **機能制限 ** + このテンプレートでは、おおよその計算が可能ですが、すべての構成に適しているわけではありません。より正確な推定を行うには、ベーステーブルと GSI の各項目のサイズを個別に測定する必要があります。  + このパターンでは、固定データ増加の仮定に基づいて、今後数年間のストレージサイズとコストのみを見積もることができます。 ## ツール **AWS サービス** + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。 **その他のツール** + [AWS 料金計算ツールは](https://docs.aws.amazon.com/pricing-calculator/latest/userguide/what-is-pricing-calculator.html)、 AWS ユースケースの見積りを作成するために使用できるウェブベースの計画ツールです。 ## エピック ### DynamoDB データモデルから項目情報を抽出します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 項目サイズを取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-storage-costs-for-an-amazon-dynamodb-table.html) | データエンジニア | | 1ヶ月間に追加されたオブジェクトの数を取得します。 | 1ヶ月間に DynamoDB テーブルに追加されるコンポーネントまたはオブジェクトの平均数を推定します。 | データエンジニア | ### Excel テンプレートに項目とオブジェクトの情報を入力します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Excel スプレッドシートをダウンロードして調整する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-storage-costs-for-an-amazon-dynamodb-table.html) | データエンジニア | | エクセルのテンプレートに情報を入力します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-storage-costs-for-an-amazon-dynamodb-table.html) | データエンジニア | ## 関連リソース + Amazon DynamoDB の[オンデマンドキャパシティの料金](https://aws.amazon.com/dynamodb/pricing/on-demand/) + [AWS DynamoDB の料金計算ツール](https://calculator.aws/#/createCalculator/DynamoDB) ## 追加情報 添付のテンプレートでは、Standard ストレージテーブルクラスのストレージサイズとコストのみを予測していることに注意してください。ストレージコストの予測に基づき、個々のアイテムのサイズと製品またはオブジェクトの増加率を考慮して、次が推定できっます： + データエクスポートコスト + バックアップとリカバリコスト + データストレージの要件。 **Amazon DynamoDB データストレージのコスト** DynamoDB はテーブルサイズの継続的監視を行って、ストレージ料金を決定します。DynamoDB は、データの RAW バイトサイズと有効化した特徴量に応じて、項目あたりのストレージオーバーヘッドを加算して、請求対象データのサイズを測定します。詳細については、「[Amazon DynamoDB 開発者ガイド](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/CapacityUnitCalculations.html)」を参照してください。  データストレージの料金は、テーブルクラスによって異なります。DynamoDB スタンダードテーブルクラスを使用している場合、毎月保存される最初の 25 GB は無料です。の標準および標準低頻度アクセステーブルクラスのストレージコストの詳細については AWS リージョン、[「オンデマンドキャパシティの料金](https://aws.amazon.com/dynamodb/pricing/on-demand/)」を参照してください。 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/9b74399d-9655-47ee-b9b3-de46b65bc4e3/attachments/attachment.zip)」 # AWR レポートを使用して Oracle データベースの Amazon RDS エンジンサイズを推定 *Amazon Web Services、Abhishek Verma、Eduardo Valentim* ## 概要 Oracle データベースを Amazon Relational Database Service (Amazon RDS) または Amazon Aurora に移行する場合、ターゲットデータベースの CPU、メモリ、ディスク I/O を計算することが重要な要件です。Oracle 自動ワークロードリポジトリ (AWR) レポートを分析することにより、ターゲットデータベースに必要なキャパシティを推定できます。このパターンでは、AWR レポートを使用して、これらの値を推定する方法を説明します。 ソース Oracle データベース は、オンプレミスで、または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされることが可能です。あるいは、Amazon RDS for Oracle DB インスタンス でも可能です。ターゲットデータベースは、Amazon RDS または Aurora データベースのどれでも構いません。 **注記** ターゲットのデータベースエンジンが Oracle の場合、キャパシティの推定がより正確になります。その他の Amazon RDS データベースでは、データベースアーキテクチャの違いによりエンジンサイズが異なる場合があります。 Oracle データベースを移行する前にパフォーマンステストを実行することを推奨します。 ## 前提条件と制限 **前提条件** + AWR レポートをダウンロードするには、Oracle データベースエンタープライズエディションライセンスと Oracle 診断パックライセンスが必要です。 **製品バージョン** + バージョン 11g (バージョン 11.2.0.3.v1 以降）および 12.2、18c、19c までのすべての Oracle Database エディション。 + このパターンでは、OracleエンジニアドシステムズやOracleクラウドインフラストラクチャ（OCI）が、カバーされていません。 ## アーキテクチャ **ソーステクノロジースタック** 次のいずれかです: + オンプレミスの Oracle データベース + EC2 インスタンス上の Oracle データベース + Amazon RDS for Oracle DB インスタンス。 **ターゲットテクノロジースタック** + Amazon RDS データベース または Amazon Aurora クラスター **ターゲット アーキテクチャ** 完全な移行プロセスについては、「[AWS DMS と AWS SCT を使用して Oracle データベースを Aurora PostgreSQL に移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-oracle-database-to-aurora-postgresql-using-aws-dms-and-aws-sct.html)」のパターンを参照してください。 **自動化とスケール** 移行する 複数の Oracle データベースがあり、追加のパフォーマンスメトリクスを使用したい場合、ブログ記事「[Oracle のパフォーマンスメトリックスに基づきAmazon RDS インスタンスを大規模に適切なサイズ](https://aws.amazon.com/blogs/database/right-sizing-amazon-rds-instances-at-scale-based-on-oracle-performance-metrics/)」 で説明されている手順に従ってプロセスを自動化できます。 ## ツール + 「[Oracle 自動ワークロードリポジトリ (AWR)](https://docs.oracle.com/en-us/iaas/performance-hub/doc/awr-report-ui.html)」 は Oracle データベースにビルドインされているリポジトリです。システム・アクティビティとワークロード・データを定期的に収集して保存し、自動データベース診断モニター (ADDM) によって分析します。AWR は、システムパフォーマンスデータのスナップショットを定期的に(デフォルトでは 60 分ごと) 作成し、その情報を保存します(デフォルトでは最大 8 日間)。 AWR のビューとレポートを使用して、このデータを分析できます。 ## ベストプラクティス + ターゲットデータベースのリソース要件を計算するために、単一の AWR レポート、複数の AWR レポート、または動的 AWR ビューを使用できます。ピークロードの時に、複数の AWR レポートを使用して、ピーク時のロードを処理するのに必要なリソースを推定することを推奨します。さらに、動的ビューでは、リソース要件をより正確に計算することを支援するデータポイントがより多く提供されます。  + IOPSの推定は移行する予定のデータベースについてのみ行い、他のデータベースやそのディスクを使うプロセスについては行いません。 + データベースが使用する I/O の量を計算するには、AWR レポートのロードプロファイルセクションの情報を使用しないでください。その代わり、可能な場合は、 I/O プロファイルセクションを使用するか、インスタンスアクティビティステータスセクションに飛んで、物理的な読み書き操作の合計値を確認します。 + CPU 使用率を推定する場合、オペレーティングシステム (OS) の統計の代わりに、データベースメトリクスメソッドを使用することをお勧めします。理由は、それがデータベースのみが使用する CPU に基づいているためです。(OS 統計情報には他のプロセスによる CPU 使用量も含まれます。) 移行後のパフォーマンスを向上させるには、ADDM レポートの CPU 関連の推奨事項も確認する必要があります。 + 適切なインスタンスタイプを決定する際には、特定のインスタンスサイズの I/O スループット制限 (Amazon Elastic Block Store (Amazon EBS) のスループットとネットワークスループット) を考慮します。 + 移行前にパフォーマンステストを実行して、エンジンサイズを検証します。 ## エピック ### レポートを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWR レポートを有効にします。 | レポートを有効にするには、「[Oracle ドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/18/tgdba/gathering-database-statistics.html#GUID-26D359FA-F809-4444-907C-B5AFECD9AE29)」の手順に従ってください。 | DBA | | 保持期間を確認します。 | AWR レポートの保持期間を確認するには、次のクエリを使用します。
SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;
| DBA | | スナップショットを生成します。 | AWR スナップショットの間隔がピークワークロードの急増を捉えるほどきめ細かくない場合、AWR レポートを手動で生成できます。手動 AWR スナップショットを生成するには、次のクエリを使用します。
SQL> EXEC dbms_workload_repository.create_snapshot;
| DBA | | 最近のスナップショットをチェックします。 | 最近の AWR スナップショットを確認するには、次のクエリを使用します。
SQL> SELECT snap_id, to_char(begin_interval_time,'dd/MON/yy hh24:mi') Begin_Interval,
 to_char(end_interval_time,'dd/MON/yy hh24:mi') End_Interval
 FROM dba_hist_snapshot
 ORDER BY 1;
| DBA | ### ディスク I/O 要件を推定します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メソッドを選択します。 | IOPS は、ストレージデバイスの 1 秒あたりの入力操作と出力操作の標準的な尺度であり、読み取り操作と書き込み操作の両方が含まれます。 オンプレミスデータベースを AWS に移行する場合、データベースが使用するピークディスク I/O を決定する必要があります。 次の方法を使用して、ターゲットデータベースのディスク I/O を推定することができます:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)次のステップでこの 4 つのメソッドについて説明します。 | DBA | | オプション 1: 負荷プロファイルを使用します。 | 次のテーブルでは、AWR レポートのロードプロファイルセクションの例を示しています。より正確な情報を取得するには、ロードプロファイルの代わりに、オプション 2 (I/O プロファイル) またはオプション 3 (インスタンスアクティビティ統計データ) を使用することをおすすめします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)この情報に基づいて、IOPS とスループットを次のように計算できます：* IOPS = 読み取りI /O リクエスト: \$1 書き込み I/O リクエスト = 3,586.8 \$1 574.7 = 4134.5** スループット = 物理読み取り (ブロック) \$1 物理的書き込み (ブロック) = 13,575.1 \$1 3,467.3 = 17,042.4*Oracle のブロックサイズが 8 KB なので、合計スループットは次のように計算できます:* メガバイト単位の合計スループットは、 17042.4 \$1 8 \$1 024 / 1024 / 1024 = 133.2 MB*負荷プロファイルを使用してインスタンスサイズを推定しないでください。それは、インスタンスのアクティビティ統計や I/O プロファイルほど正確ではありません。 | DBA | | オプション 2: インスタンスアクティビティ統計を使用します。 | 12c 以前のバージョンの Oracle Database を使用している場合、AWR レポートのインスタンスアクティビティ統計セクションを使用して IOPS とスループットを推定できます。次の表に、この構文の例を示します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)この情報に基づいて、合計 IOPS とスループットを次のように計算できます：* 合計 IOPS = 3,610.28 \$1 757.11 = 4367 ** 合計 Mbps = 114,482,426.26 \$1 36,165,631.84 = 150648058.1/ 1024 / 1024 = 143 Mbps* | DBA | | オプション 3: I/O プロファイルを使用します。 | Oracle Database 12c では、AWR レポートに I/O Profiles セクションが含まれています。このセクションでは、すべての情報が 単一のテーブルに表示され、データベースのパフォーマンスに関するより正確なデータが得られます。次の表に、この構文の例を示します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)このテーブルでは、スループットと合計 IOPS について次の値を示します：*　　　スループット = 143 MBPS (5 行目の 2 列目の合計とラベル付きから)** IOPS = 4,367.4 (最初の行の リクエストの合計 とラベル付き、2　番目の列)* | DBA | | オプション 4: AWR ビューを使用します。 | AWR ビューを使用しても、同じ IOPS とスループット情報が表示されます。この情報を取得するには、次のクエリを使用します： 
break on report
 compute sum of Value on report
 select METRIC_NAME,avg(AVERAGE) as "Value"
 from dba_hist_sysmetric_summary
 where METRIC_NAME in ('Physical Read Total IO Requests Per Sec','Physical Write Total IO Requests Per Sec')
 group by metric_name;
| DBA | |   | 1 秒あたり | トランザクションあたり | 実行あたり | 呼び出しあたり | | --- |--- |--- |--- |--- | | **DB 時間: ** | 26.6 | 0.2 | 0.00 | 0.02 | | **DB CPU:** | 18.0 | 0.1 | 0.00 | 0.01 | | **バックグラウンド CPU:** | 0.2 | 0.0 | 0.00 | 0.00 | | **やり直しのサイズ (バイト):** | 2,458,539.9 | 17,097.5 |   |   | | **ロジカルリード (ブロック):** | 3,371,931.5 | 23,449.6 |   |   | | **ブロック変更:** | 21,643.5 | 150.5 |   |   | | **物理的読み取り (ブロック):** | 13,575.1 | 94.4 |   |   | | **物理的書き込み (ブロック):** | 3,467.3 | 24.1 |   |   | | **読み取り IO リクエスト:** | 3,586.8 | 24.9 |   |   | | **書き込み IO リクエスト:** | 574.7 | 4.0 |   |   | | **読み取り IO (MB):** | 106.1 | 0.7 |   |   | | **書き込み IO (MB):** | 27.1 | 0.2 |   |   | | **IM スキャン行:** | 0.0 | 0.0 |   |   | | **セッションのロジカル読み取り IM:** |   |   |   |   | | **ユーザーの呼び出し:** | 1,245.7 | 8.7 |   |   | | **解析 (SQL):** | 4,626.2 | 32.2 |   |   | | **ハード解析 (SQL):** | 8.9 | 0.1 |   |   | | **SQL ワークエリア (MB):** | 824.9 | 5.7 |   |   | | **ログオン:** | 1.7 | 0.0 |   |   | | **実行 (SQL):** | 136,656.5 | 950.4 |   |   | | **ロールバック：** | 22.9 | 0.2 |   |   | | **トランザクション：** | 143.8 |   |   |   | | 統計 | Total | 1 秒あたり | トランザクションあたり | | --- |--- |--- |--- | | **物理的読み取り、IO リクエストの合計** | 2,547,333,217 | 3,610.28 | 25.11 | | **物理的読み取りの合計バイト数** | 80,776,296,124,928 | 114,482,426.26 | 796,149.98 | | **物理的書き込みのI/O リクエストの合計数** | 534、198、208 | 757.11 | 5.27 | | **物理的書き込みの合計バイト数** | 25,517,678,849,024 | 36,165,631.84 | 251,508.18 | |   | 1 秒あたりの読み取り\$1書き込み | 1 秒あたりの読み取り数 | 1 秒あたりの書き込み数 | | --- |--- |--- |--- | | **リクエスト合計：** | 4,367.4 | 3,610.3 | 757.1 | | **データベースリクエスト:** | 4,161.5 | 3,586.8 | 574.7 | | **最適化されたリクエスト:** | 0.0 | 0.0 | 0.0 | | **やり直しリクエスト:** | 179.3 | 2.8 | 176.6 | | **合計 (MB):** | 143.7 | 109.2 | 34.5 | | **データベース (MB):** | 133.1 | 106.1 | 27.1 | | **最適化された合計 (MB):** | 0.0 | 0.0 | 0.0 | | **やり直し (MB):** | 7.6 | 2.7 | 4.9 | | **データベース (ブロック):** | 17,042.4 | 13,575.1 | 3,467.3 | | **バッファキャッシュ経由 (ブロック):** | 5,898.5 | 5,360.9 | 537.6 | | **ダイレクト (ブロック):** | 11,143.9 | 8,214.2 | 2,929.7 | ### CPU 要件の推定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メソッドを選択します。 | ターゲットデータベースに必要な CPU は、次の 3 つの方法で推定することができます:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)使用されるコアを確認する場合、OS 統計の代わりに、データベースメトリクスメソッドを使用することを推奨します。理由は、移行を計画しているデータベースのみが使用する CPU に基づいているためです。(OS 統計情報には他のプロセスによる CPU 使用量も含まれます。) 移行後のパフォーマンスを向上させるには、ADDM レポートの CPU 関連の推奨事項も確認する必要があります。CPU 世代に基づいて、要件を推定することもできます。異なる世代の CPU を使用している場合、ホワイトペーパー「[ワークロードパフォーマンスを最適化するための vCPUs 数の謎を解き明かす](https://d1.awsstatic.com/whitepapers/Demystifying_vCPUs.df200b766578b75009ad8d15c72e493d6408c68a.pdf)」の手順に従うことで、必要なターゲットデータベースを推定することができます。 | DBA | | オプション 1: 利用可能なコアに基づいて要件を推定します。 | AWR レポートで:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)使用可能なコア数は次の 2 つの方法のいずれかで推定できます：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)**OS コマンドを使用して使用可能なコア数を推定するには**次のコマンドを使用して、プロセッサのコアをカウントします。
$ cat /proc/cpuinfo |grep "cpu cores"|uniq
cpu cores    : 4
cat /proc/cpuinfo | egrep "core id|physical id" | tr -d "\n" | sed s/physical/\\nphysical/g | grep -v ^$ | sort | uniq | wc -l
以下のコマンドを使用して、プロセッサのソケット数をカウントします。
grep "physical id" /proc/cpuinfo | sort -u
  physical id     : 0
  physical id     : 1
  **nmon** と **sar** などの OS コマンドを使用して CPU 使用率を抽出することを推奨しません。この理由は、これらの計算には他のプロセスの CPU 使用率が含まれて、データベースが使用する実際の CPU 使用率を反映していない可能性があるためです。**AWR レポートを使用して使用可能なコアを推定するには**AWR レポートの最初のセクションから CPU 使用率を導き出すこともできます。以下はレポートからの抜粋です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)この例では、CPU 数は 80 で、これは論理 (仮想) CPU であることを示しています。また、この構成には 2 つのソケットがあり、各ソケットに 1 つの物理プロセッサ (合計で 2 つの物理プロセッサ) があり、物理プロセッサまたはソケットごとに 40 コアがあることも確認できます。  | DBA | | オプション 2: OS 統計を使用して CPU 使用率を推定します。 | OS で(**sar**やその他のホスト OS ユーティリティを使用して)、またはAWR レポートのオペレーティングシステム統計セクションから IDLE/ (IDLE\$1BUSY) 値をレビューすることで、OS の CPU 使用率統計をチェックできます。**v\$1osstat** から直接消費された CPU の秒数を確認できます。AWR レポートと Statspack レポートでも、オペレーティングシステム統計セクションでこのデータが表示されます。同じボックスに複数のデータベースがある場合、BUSY\$1TIME の **v\$1ossta**t 値はすべて同じになります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)システムに他の CPU 使用者がいない場合は、次の式を使用して CPU 使用率を計算します:* 使用率 = ビジータイム/合計時間** ビジータイム = 要件 = v\$1osstat.Busy\$1Time** C = 合計時間 (ビジー\$1アイドル)** C = 容量 = v\$1OSTAT.Busy\$1Time \$1 v\$1OSTAT.Idle\$1Time**   使用率 = BUSY\$1TIME / (BUSY\$1TIME \$1 IDLE\$1TIME)**      = -1,305,569,937/(1,305,569,937 \$1 4,312,718,839)**      = 23% 利用* | DBA | | オプション 3: データベースメトリクスを使用して CPU 使用率を推定します。 | システム内で複数のデータベースが実行されている場合、レポートの先頭に表示されるデータベースメトリックを使用できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)CPU 使用率メトリクスを取得するには、次の式を使用します:* データベースの CPU 使用率 (使用可能な CPU パワーの%) = CPU 時間 /N UM\$1CPUS / 経過時間*CPU 使用率は *CPU 時間*で表され、CPU の待機時間の代わりに、 CPU に費やされた時間を示します。この計算結果は次のようになります：* = 312,625.40/11,759.64/80 = CPU の 33% が使用されています** コア数 (33%) \$1 80 = 26.4 コア** 合計コア数 = 26.4 \$1 (120%) = 31.68 コア*これら 2 つの値のうち大きい方を使用して、Amazon RDS または Aurora DB インスタンスの CPU 使用率を計算できます。IBM AIX では、計算された使用率はオペレーティングシステムまたはデータベースの値と一致しません。これらの値は、他のオペレーティングシステムでは一致します。 | DBA | | DB Name | DB Id | インスタンス | Inst num | 起動時間 | リリース | RAC | | --- |--- |--- |--- |--- |--- |--- | | XXXX | | XXXX | 1 | 2020年 9月5日 23:09 | 12.1.0.2.0 | いいえ | | **ホスト名** | **プラットフォーム** | **Cpus** | **コア** | **ソケット** | **メモリ (GB)** | | ＜host\$1name＞ | Linux x86 64 ビット | 80 | 80 | 2 | 441.78 | | 統計 | 値 | 最終値 | | --- |--- |--- | | **FREE\$1MEMORY\$1BYTES** | 6,810,677,248 | 12,280,799,232 | | **INACTIVE\$1MEMORY\$1BYTES** | 175、627、333、632 | 160、380、653、568 | | **SWAP\$1FREE\$1BYTES** | 17,145,614,336 | 17,145,872,384 | | **BUSY\$1TIME** | 1,305,569,937 |   | | **IDLE\$1TIME** | 4,312,718,839 |   | | **IOWAIT\$1TIME** | 53,417,174 |   | | **NICE\$1TIME** | 29,815 |   | | **SYS\$1TIME** | 148,567,570 |   | | **USER\$1TIME** | 1,146,918,783 |   | | **LOAD** | 25 | 29 | | **VM\$1IN\$1BYTES** | 593,920 |   | | **OUT\$1BYTES** | 327,680 |   | | **PHYSICAL\$1MEMORY\$1BYTES** | 474、362、417、152 |   | | **NUM\$1CUPS** | 80 |   | | **NUM\$1CPU\$1CORES** | 80 |   | | **NUM\$1CPU\$1SOCKETS** | 2 |   | | **GLOBAL\$1RECEIVE\$1SIZE\$1MAX** | 4,194,304 |   | | **GLOBAL\$1SEND\$1SIZE\$1MAX** | 2,097,152 |   | | **TCP\$1RECEIVE\$1SIZE\$1DEFAULT** | 87,380 |   | | **TCP\$1RECEIVE\$1SIZE\$1MAX** | 6,291,456 |   | | **TCP\$1RECEIVE\$1SIZE\$1MIN** | 4,096 |   | | **TCP\$1SEND\$1SIZE\$1DEFAULT** | 16,384 |   | | **TCP\$1SEND\$1SIZE\$1MAX** | 4,194,304 |   | | **TCP\$1SEND\$1SIZE\$1MIN** | 4,096 |   | |   | スナップ ID | スナップタイム | セッション | カーソル/セッション | | --- |--- |--- |--- |--- | | **スナップを開始:** | 184662 | 2020年 9月28日 09:00:42 | 1226 | 35.8 | | **エンドスナップ:** | 185446 | 2020年 10月6日 13:00:20 | 1876 | 41.1 | | **経過時間: ** |   | 11,759.64 (分) |   |   | | **DB 時間:** |   | 312,625.40 (分) |   |   | ### メモリ要件の推定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メモリ統計情報を使用してメモリ要件を推定します。 | ソースデータベースのメモリを計算し、それをターゲットデータベースでマッチさせるのに、AWR レポートを使用できます。また、コストを節約するのに、既存のデータベースのパフォーマンスを確認してメモリ要件を減らすか、パフォーマンスを向上させるために要件を増やす必要もあります。それには、AWR の応答時間とアプリケーションのサービスレベルアグリーメント (SLA) を詳細に分析する必要があります。Oracle のシステムグローバルエリア (SGA) とプログラムグローバルエリア (PGA) の使用量の合計を、Oracle の推定メモリ使用率として使用します。OS に さらに20% を追加して目標メモリサイズ要件を決定します。Oracle RAC では、すべての RAC ノードの推定メモリ使用率の合計を使用して、合計メモリを減らします。理由は、メモリが共通ブロックに格納されるためです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)* 使用中のインスタンスメモリの合計 = SGA \$1 PGA = 220 GB \$1 45 GB = 265 GB*バッファーの 20% を追加:* 合計インスタンスのメモリ = 1.2 \$1 265 GB = 318 GB*SGA と PGA がホストメモリの 70% を占めるため、必要な合計メモリ量は次のようになります: *　　ホストメモリの総容量 = 318/0.7 = 464 GB*Amazon RDS for Oracle に移行すると、PGA と SGA は事前定義された計算式に基づいて事前に計算されます。事前に計算された値が、推定値に近いことを確保します。 | DBA | | Buffer Nowait %: | 99.99 | Redo NoWait %: | 100.00 | | --- |--- |--- |--- | | **Buffer Hit %:** | 99.84 | **インメモリソート %:** | 100.00 | | **ライブラリー %:** | 748.77 | **ソフト解析 %:** | 99.81 | | **Execute to Parse %:** | 96.61 | **ラッチヒット %:** | 100.00 | | **Parse CPU to Parse Elapsd %:** | 72.73 | **Non-Parse CPUの率 %:** | 99.21 | | **フラッシュキャッシュのヒット率 %:** | 0.00 |   |   | |   | 開始 | 修了 | | --- |--- |--- | | **ホストメモリ (MB):** | 452,387.3 | 452,387.3 | | **SGAの使用 (MB):** | 220,544.0 | 220,544.0 | | **PGA 使用量 (MB):** | 36,874.9 | 45,270.0 | ### ターゲットデータベースの DB インスタンスタイプを決定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ディスク I/O、CPU、メモリの見積もりに基づいて DB インスタンスタイプを決定します。 | 前のステップの見積もりに基づいて、ターゲットの Amazon RDS または Aurora データベースの容量は次のようになるはずです:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)ターゲットの Amazon RDS または Aurora データベースでは、これらの値を db.r5.16xlarge インスタンスタイプにはマッピングできます。このインスタンスタイプは 32 コアのキャパシティ、512 GB の RAM、13,600 Mbps のスループットがあります。 詳細については、AWS ブログ記事「[Oracle のパフォーマンスメトリクスに基づく Amazon RDS インスタンスを大規模に適切なサイズ](https://aws.amazon.com/blogs/database/right-sizing-amazon-rds-instances-at-scale-based-on-oracle-performance-metrics/)」を参照してください。 | DBA | ## 関連リソース + 「[Aurora DB インスタンスクラス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html)」 (Amazon Aurora ドキュメント) + 「[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」 (Amazon RDS ドキュメント) + 「[AWS マイナーツール](https://github.com/tmuth/AWR-Miner/blob/master/release/5.0.8/AWR-Miner-capture-5.0.8/awr_miner.sql)」 (GitHub リポジトリ) # AWS DMS を使用して Amazon RDS for SQL Server テーブルを S3 バケットにエクスポートする *Amazon Web Services、Subhani Shaik* ## 概要 SQL Server 用 Amazon Relational Database Service (Amazon RDS) は、Amazon Web Services (AWS) クラウド上の他の DB エンジンにリンクされたサーバーへのデータのロードをサポートしていません。代わりに、AWS Database Migration Service (AWS DMS) を使用して Amazon RDS for SQL Server テーブルを Amazon Simple Storage Service (Amazon S3) バケットにエクスポートできます。これにより、データは他の DB エンジンで利用できるようになります。 AWS DMS は、AWS にデータベースを簡単かつ安全に移行します。移行中でもソースデータベースが完全に維持され、このデータベースを利用するアプリケーションのダウンタイムは最小限に抑えられます。AWS DMS は、広く普及しているほとんどの商用データベースとオープンソースデータベース間のデータ移行にご利用いただけます。 このパターンでは、AWS DMS エンドポイントの構成時に AWS Secrets Manager を使用します。Secrets Manager は、アプリケーション、サービス、IT リソースへのアクセスに必要なシークレットの保護に役立ちます。このサービスを使うと、ライフサイクルを通じてデータベース認証情報、API キー、その他のシークレットをローテーション、管理、取得することができます。ユーザーとアプリケーションは Secrets Manager を呼び出すことでシークレットを取得できるため、機密情報をハードコーディングする必要がなくなります。Secrets Manager には、Amazon RDS、Amazon Redshift、Amazon DocumentDB の統合機能が組み込まれたシークレットローテーションが用意されています。また、このサービスは API キーや OAuth トークンなど、他のタイプのシークレットにも拡張できます。Secrets Manager を使用すると、AWS クラウド、サードパーティサービス、およびオンプレミスのリソースに対するきめ細かな権限設定やシークレットローテーション監査の一元化を通して、シークレットへのアクセスを制御できます。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント。 + S3 バケット + 仮想プライベートクラウド (VPC) + DB サブネット + Amazon RDS for SQL Server + Amazon RDS インスタンスに代わって S3 バケットへのアクセス (オブジェクトのリスト、取得、および配置) を行う AWS Identity and Access Management (IAM) ロール。 + RDS インスタンスの認証情報を保存する Secrets Manager。 ## アーキテクチャ **テクノロジースタック** + Amazon RDS for SQL Server + AWS DMS + Amazon S3 + AWS Secrets Manager **ターゲットアーキテクチャ** 次の図は、AWS DMS を使用して Amazon RDS インスタンスから S3 バケットにデータをインポートするアーキテクチャを示しています。 ![\[説明は図の下にあります。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/7ba5756d-44a5-4aa3-97b6-fa3684ae6ce6/images/90f918e1-3ec2-4434-82b8-3ff4ad340fb9.png) 1. ソースエンドポイントを介してソース Amazon RDS インスタンスに接続する AWS DMS 移行タスク 1. ソース Amazon RDS インスタンスからデータをコピーする 1. ターゲットエンドポイントを介してターゲット S3 バケットに接続する AWS DMS 移行タスク 1. コピーしたデータを CSV (カンマ区切り値) 形式で S3 バケットにエクスポートする ## ツール AWS サービス + 「[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」 を使用して、データストアを AWS クラウドへ、またはクラウドセットアップとオンプレミスセットアップの組み合わせの間に移行します。 + 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。 **その他のサービス** + 「[Microsoft SQL Server Management Studio (SSMS)](https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver16)」 は、SQL Server コンポーネントへのアクセス、設定、管理など、SQL Server を管理するためのツールです。 ## エピック ### Amazon RDS for SQL Server インスタンスの構成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS for SQL Server インスタンスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | | インスタンスの認証情報を設定する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | | インスタンスクラス、ストレージ、自動スケーリング、可用性を構成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | | VPC、サブネットグループ、パブリックアクセス、セキュリティグループを指定します。 | 必要に応じて [**VPC**]、[**DB サブネットグループ**]、[**VPC セキュリティグループ**] を選択し、Amazon RDS インスタンスを作成します。次のようなベストプラクティスに従ってください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | | モニタリング、バックアップ、メンテナンスを構成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | ### データベースと例データのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テーブルを作成し、例データをロードします。 | 新しいデータベース内にテーブルを作成します。[*追加情報*] セクションのサンプルコードを使用して、テーブルにデータをロードします。 | DBA、DevOps エンジニア | ### 認証情報の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | シークレットを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html)このシークレットは AWS DMS ソースエンドポイントに使用されます。 | DBA、DevOps エンジニア | ### データベースと S3 バケット間のアクセスを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS にアクセスするための IAM ロールを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | ### S3 バケットの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを作成する。 | Amazon RDS for SQL Server からのデータを保存するには、コンソールで [**S3**] を選択し、[**バケットの作成**] を選択します。S3 バケットがパブリックにアクセス可能でないことを確認します。 | DBA、DevOps エンジニア | ### AWS DMS と S3 バケット間のアクセスを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS DMS が Amazon S3 にアクセスするための IAM ロールを作成します。 | AWS DMS が S3 バケットのオブジェクトをリスト、取得、および配置できるようにする IAM ロールを作成します。 | DBA、DevOps エンジニア | ### AWS DMS を構成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS DMS ソースエンドポイントを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | | AWS DMS ターゲットエンドポイントを作成する。 | **ターゲットエンドポイント**を作成し、**ターゲットエンジン**として Amazon S3 を選択します。先に作成した IAM ロールの S3 バケット名とフォルダ名を指定します。 | DBA、DevOps エンジニア | | AWS DMS レプリケーションインスタンスを作成する。 | 同じ VPC、サブネット、セキュリティグループで AWS DMS レプリケーションインスタンスを作成します。インスタンスクラスのオプションの選択に関する詳細については、[ のドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html#CHAP_ReplicationInstance.Types.Deciding)を参照してください。 | DBA、DevOps エンジニア | | AWS DMS 移行タスクを作成します。 | Amazon RDS for SQL Server から S3 バケットにデータをエクスポートするには、データベース移行タスクを作成します。[Migration type (移行タイプ)] で **[Migrate existing data (既存のデータを移行する)]** を選択します。作成した AWS DMS エンドポイントとレプリケーションインスタンスを選択します。 | DBA、DevOps エンジニア | ### データを S3 バケットにエクスポートする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベース移行タスクを実行します。 | データベース移行タスクを開始して、SQL Server テーブルデータをエクスポートします。このタスクでは、Amazon RDS for SQL Server のデータを CSV 形式で S3 バケットにエクスポートします。 | DBA、DevOps エンジニア | ### リソースをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースを削除します。 | 追加コストが発生しないように、コンソールを使用して次の順序でリソースを削除します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.html) | DBA、DevOps エンジニア | ## 関連リソース + [AWS DMS](https://aws.amazon.com/dms/) + [Amazon S3](https://aws.amazon.com/s3/) + [Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/) + [Amazon S3 統合](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/oracle-s3-integration.html) ## 追加情報 データベースとテーブルを作成し、例データを読み込むには、次のコードを使用します。 ``` --Step1: Database creation in RDS SQL Server CREATE DATABASE [Test_DB] ON PRIMARY ( NAME = N'Test_DB', FILENAME = N'D:\rdsdbdata\DATA\Test_DB.mdf' , SIZE = 5120KB , FILEGROWTH = 10%) LOG ON ( NAME = N'Test_DB_log', FILENAME = N'D:\rdsdbdata\DATA\Test_DB_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%) GO --Step2: Create Table USE Test_DB GO Create Table Test_Table(ID int, Company Varchar(30), Location Varchar(20)) --Step3: Load sample data. USE Test_DB GO Insert into Test_Table values(1,'AnyCompany','India') Insert into Test_Table values(2,'AnyCompany','USA') Insert into Test_Table values(3,'AnyCompany','UK') Insert into Test_Table values(4,'AnyCompany','Hyderabad') Insert into Test_Table values(5,'AnyCompany','Banglore') ``` # Aurora PostgreSQL の動的 SQL ステートメントの匿名ブロックを処理 *Amazon Web Services、Anuradha Chintha* ## 概要 注: Amazon Cloud Directory は新規顧客に公開されなくなりました。クラウドディレクトリの代替方法については、[Amazon DynamoDB ](https://aws.amazon.com/dynamodb/)と [Amazon Neptune](https://aws.amazon.com/neptune/) を参照してください。ユースケースに適した代替案の選択、またはその他の質問については、 にお問い合わせください[AWS サポート](https://aws.amazon.com/support/)。 このパターンでは、動的 SQL ステートメントで匿名ブロックを処理する場合に発生するエラーを回避する方法を示しています。AWS Schema Conversion Tool を使用して、Oracle データベースを Aurora PostgreSQL 互換エディションデータベースに変換するとエラーメッセージが表示されます。このエラーを回避するには、`OUT` バインド変数の値を知っている必要がありますが、SQL ステートメントの実行後まで `OUT` のバインド変数の値を知ることはできません。。このエラーは、AWS Schema Conversion Tool (AWS SCT) が動的 SQL ステートメント内部のロジックを理解していないことが原因です。AWS SCT は PL/SQL コード (つまり、関数、プロシージャ、パッケージ) の動的 SQL ステートメントを変換できません。 ## 前提条件と制限 **前提条件 ** + アクティブなAWS アカウント。 + 「[Aurora PostgreSQL データベース (DB) インスタンス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html)」 + [Oracle DV インスタンスの Amazon Relational Database Service (Amazon RDS)の起動](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html) + 「[PostgreSQL インタラクティブターミナル (psql)](https://www.postgresql.org/docs/current/app-psql.html)」 + 「[SQL \$1Plus](https://docs.oracle.com/cd/B14117_01/server.101/b12170/qstart.htm)」 + ターゲットデータベースにある `AWS_ORACLE_EXT` のスキーマ (「[AWS SCT 拡張パック](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_ExtensionPack.html)」の一部) + 「[AWS Schema Conversion Tool (AWS SCT)](https://aws.amazon.com/dms/schema-conversion-tool/)」 の最新バージョンおよび必要なドライバー ## アーキテクチャ **ソーステクノロジースタック** + オンプレミスの Oracle データベース 10.g 以降のバージョン **ターゲットテクノロジースタック** + Amazon Aurora PostgreSQL + Amazon RDS for PostgreSQL + AWS Schema Conversion Tool (AWS SCT) **移行アーキテクチャ** 次の図表は、AWS SCT と Oracle `OUT` のバインド変数を使用して、アプリケーションコードをスキャンして埋め込み SQL ステートメントを探し、そのコードを Aurora データベースが使用することができる互換性のある形式に変換する方法を示しています。 ![\[AWS SCT と Oracle OUT のバインド変数の使用に関するアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ada89410-b866-4d39-af9c-021be6cc6ae5/images/7c004981-2ed0-4b67-989f-54d8691712ca.png) この図表は、次のワークフローを示しています： 1. Aurora PostgreSQL をターゲットデータベースとして使用して、ソースデータベースの AWS SCT レポートを生成します。 1. 動的 SQL コードブロック (AWS SCT がエラーを発生させたブロック) 内の、匿名ブロックを特定します。 1. コードブロックを手動で変換し、ターゲットデータベースにコードをデプロイします。 ## ツール **AWS サービス** + 「[Amazon Aurora PostgreSQL 互換エディション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)」は、PostgreSQL デプロイのセットアップ、運用、スケーリングに役立つ、フルマネージド型のACID準拠のリレーショナルデータベースエンジンです。 + 「[OracleのAmazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)」 によって、AWS クラウドで Oracleリレーショナルデータベースをセットアップ、運用、スケーリングができます。 + 「[AWS Schema Conversion Tool (AWS SCT)](https://aws.amazon.com/dms/schema-conversion-tool/)」 によって、ソースデータベーススキーマと大部分のデータベースコードオブジェクトを、ターゲットデータベースと互換性のある形式に自動的に変換することで、異種データベースの移行を予測可能にします。 **その他のツール** + 「[pgAdmin](https://www.pgadmin.org/)」を使用して、データベースサーバーに接続して操作できます。 + 「[Oracle SQL Developer](https://www.oracle.com/database/sqldeveloper/)」 は、Oracle データベース内のデータベースを開発および管理するために使用できる統合開発環境です。このパターンには 「[SQL \$1Plus](https://docs.oracle.com/cd/B19306_01/server.102/b14357/qstart.htm)」または Oracle SQL Developer のいずれも使用できます。 ## エピック ### Oracle ソースデータベースを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS または Amazon EC2 で Oracle インスタンスを作成します。 | Amazon RDS で Oracle DB インスタンスを作成するには、Amazon RDS ドキュメントの 「[Oracle DB インスタンスの作成と Oracle DB インスタンスのデータベースへの接続](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.Oracle.html)」を参照してください。Amazon Elastic Compute Cloud (Amazon EC2) で Oracle DB インスタンスを作成するには、AWS 規範ガイダンス ドキュメントの 「[Oracle向けAmazon EC2](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/ec2-oracle.html)」を参照してください。 | DBA | | 移行のデータベーススキーマとオブジェクトを作成します。 | Amazon Cloud Directory を使用して、データベーススキーマを作成することができます。詳細については、クラウドディスカバリドキュメントの 「[スキーマの作成](https://docs.aws.amazon.com/clouddirectory/latest/developerguide/getting_started_create_schema.html)」 を参照してください。 | DBA | | インバウンドとアウトバウンドのセキュリティグループを設定します。 | セキュリティグループを作成して設定するには、Amazon RDS ドキュメントの「[セキュリティグループによるアクセス制御](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html)」を参照してください。 | DBA | | データベースが実行されていることを確認します。 | データベースのステータスを確認するには、Amazon RDS ドキュメントの「[Amazon RDS イベントの表示](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ListEvents.html)」 を参照してください。 | DBA | ### ターゲットの Aurora PostgreSQL データベースを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS に Aurora PostgreSQL インスタンスを作成します。 | Aurora PostgreSQL インスタンスを作成するには、Amazon RDS ドキュメントの「[ DB クラスターを作成して Aurora PostgreSQL DB クラスターのデータベースに接続](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.html)」 を参照してください。 | DBA | | インバウンドとアウトバウンドのセキュリティグループを設定します。 | セキュリティグループを作成および設定するには、Aurora ドキュメントの「[セキュリティグループの設定によりVPCのDBクラスターへのアクセスを提供する](https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/CHAP_SettingUp_Aurora.html#CHAP_SettingUp_Aurora.SecurityGroup)」 を参照してください。 | DBA | | Aurora PostgreSQL データベースが実行されていることを確認します。 | データベースのステータスを確認するには、Aurora ドキュメントの「[Amazon RDS イベントの表示](https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/USER_ListEvents.html)」を参照してください。 | DBA | ### AWS SCT のセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS SCTをソースデータベースに接続する。 | AWS SCT をソースデータベースに接続するには、AWS SCT ドキュメントの「[ソースとして PostgreSQL に接続する](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.Connecting)」を参照してください。 | DBA | | AWS SCT をターゲットデータベースに接続します。 | AWS SCT をターゲットデータベースに接続するには、 AWS スキーマ変換ツールユーザーガイドの「[AWS スキーマ変換ツールとは?](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html)」を参照してください。 | DBA | | AWS SCT でデータベーススキーマを変換し、自動変換されたコードを SQL ファイルとして保存します。 | AWS SCT の変換されたファイルを保存するには、 AWS スキーマ変換ツールユーザーガイドの「[AWS SCT での変換済みスキーマの保存と適用](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Converting.html#CHAP_Converting.SaveAndApply)」を参照してください。 | DBA | ### コードの移行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 手動変換用の SQL ファイルを取得します。 | AWS SCT で変換されたファイルで、手動変換が必要な SQL ファイルを引き出します。 | DBA | | スクリプトを更新します。 | SQL ファイルを手動で更新します。 | DBA | ## 関連リソース + 「[Amazon RDS](https://aws.amazon.com/rds/)」 + 「[Amazon Aurora の特徴量](https://aws.amazon.com/rds/aurora/postgresql-features/)」 ## 追加情報 次のサンプルコードは、Oracle ソースデータベースの設定方法を示しています： ``` CREATE or replace PROCEDURE calc_stats_new1 ( a NUMBER, b NUMBER, result out NUMBER) IS BEGIN result:=a+b; END; / ``` ``` set serveroutput on ; DECLARE a NUMBER := 4; b NUMBER := 7; plsql_block VARCHAR2(100); output number; BEGIN plsql_block := 'BEGIN calc_stats_new1(:a, :b,:output); END;'; EXECUTE IMMEDIATE plsql_block USING a, b,out output; DBMS_OUTPUT.PUT_LINE('output:'||output); END; ``` 次のサンプルコードは、ターゲット Aurora PostgreSQL データベースの設定方法を示しています: ``` w integer, x integer) RETURNS integer AS $BODY$ DECLARE begin return w + x ; end; $BODY$ LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION test_pg.init() RETURNS void AS $BODY$ BEGIN if aws_oracle_ext.is_package_initialized ('test_pg' ) then return; end if; perform aws_oracle_ext.set_package_initialized ('test_pg' ); PERFORM aws_oracle_ext.set_package_variable('test_pg', 'v_output', NULL::INTEGER); PERFORM aws_oracle_ext.set_package_variable('test_pg', 'v_status', NULL::text); END; $BODY$ LANGUAGE plpgsql; DO $$ declare v_sql text; v_output_loc int; a integer :=1; b integer :=2; BEGIN perform test_pg.init(); --raise notice 'v_sql %',v_sql; execute 'do $a$ declare v_output_l int; begin select * from test_pg.calc_stats_new1('||a||','||b||') into v_output_l; PERFORM aws_oracle_ext.set_package_variable(''test_pg'', ''v_output'', v_output_l) ; end; $a$' ; v_output_loc := aws_oracle_ext.get_package_variable('test_pg', 'v_output'); raise notice 'v_output_loc %',v_output_loc; END ; $$ ``` # DynamoDB でのタグ付けの強制を支援 *Amazon Web Services、Mansi Suratwala* ## 概要 このパターンは、事前定義の Amazon DynamoDB タグがAmazon Web Services (AWS) クラウドの DynamoDB リソースから見つからず、または削除された場合、自動通知を設定します。  DynamoDB は、高速で予測可能なパフォーマンスとスケーラビリティを実現するフルマネージド NoSQL データベースサービスです。DynamoDB では、分散データベースの運用とスケーリングに伴うユーザーの管理上の負担を軽減できます。DynamoDB を使用して、ハードウェアのプロビジョニング、セットアップと構成、レプリケーション、ソフトウェアパッチ適用、クラスタースケーリングなどを配慮しなくても良いです。 このパターンでは、Amazon CloudWatch Events イベントと AWS Lambda 関数を作成する AWS CloudFormation テンプレートを使用します。このイベントでは、AWS CloudTrail を使用して、新規または既存の DynamoDB タグ情報を監視します。定義済みのタグが見つからない、または削除された場合、CloudWatch は Lambda 関数をトリガーし、違反を通知する Amazon Simple Notification Service (Amazon SNS) 通知を送信します。  ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + バケットLambda 関数を実行するための Python スクリプトを含む Lambda .zip ファイルの、Amazon Simple Storage Service (Amazon S3) **制限事項** + このソリューションは、`TagResource`または `UntagResource` のCloudTrail イベントが発生した場合にのみ機能します。他のイベントの通知は作成されません。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon DynamoDB + AWS CloudTrail + Amazon CloudWatch + AWS Lambda + Amazon S3 + Amazon SNS **ターゲット アーキテクチャ** ![\[DynamoDB タグがない場合、Amazon SNS 通知を送信するための Lambda 関数と CloudWatch イベントがトリガーされます。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/638d2b87-e031-4a53-8677-2d62e563746b/images/acc448c5-c39b-40b7-94c0-3534d2e725d7.png) **自動化とスケール** AWS CloudFormation テンプレートは、さまざまな AWS リージョンとアカウントに複数回使用できます。各リージョンまたはアカウントで、テンプレートを 1 回実行するだけで済みます。 ## ツール **ツール** + 「[Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) 」 — DynamoDBは、フルマネージド NoSQL データベースサービスであり、シームレスなスケーラビリティを備えた高速で予測可能なパフォーマンスを提供します。  + 「[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」 — CloudTrailは、AWS アカウントのガバナンス、コンプライアンス、および運用とリスクの監査について支援する AWS のサービスです。ユーザー、ロール、または AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録されます。  + 「[Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)」 — CloudWatch Events は、AWS リソースでの変更を説明するシステムイベントのほぼリアルタイムのストリームを提供します。  + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) – Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。  + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)」 — Amazon Simple Storage Service (Amazon S3) は、拡張性の高いオブジェクトストレージサービスで、ウェブサイト、モバイルアプリケーション、バックアップ、データレイクなど、幅広いストレージソリューションに使用できます。 + [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) –Amazon Simple Notification Service (Amazon SNS) は、アプリケーション、エンドユーザー、およびデバイスでクラウドから通知を瞬時に送受信できるようにするウェブサービスです。  **コード** + プロジェクトの .zip ファイルは添付ファイルとして入手できます。 ## エピック ### S3 バケットを定義 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを削除します。 | Amazon S3 コンソールで、先頭にスラッシュを含まない一意の名前で S3 バケットを選択、作成します。この S3 バケットは Lambda コードの.zip ファイルをホストします。S3 バケットは、監視対象の DynamoDB リソースと同じ AWS リージョンに存在している必要があります。 | クラウドアーキテクト | ### S3 バケットに Lambda コードをアップロードします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットに Lambda コードをアップロードします。 | 「*添付ファイル*」セクションにある Lambda コードの .zip ファイルを S3 バケットにアップロードします。S3 バケットは、監視中の DynamoDB リソースと同じリージョンに存在している必要があります。 | クラウドアーキテクト | ### AWS CloudFormation テンプレートをデプロイする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS CloudFormation のテンプレートをデプロイします。 | AWS CloudFormation コンソールで、*添付ファイル*セクションで提供されている AWS CloudFormation テンプレートをデプロイします。次のエピックでは、パラメータの値を提供します。 | クラウドアーキテクト | ### AWS CloudFormation テンプレートのパラメータを入力します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットに名前を付けます。 | 最初のエピックで作成または選択した S3 バケットの名前を入力します。 | クラウドアーキテクト | | Amazon S3 キーを指定します。 | S3 バケット内の Lambda コードの .zip ファイルの場所を、先頭にスラッシュを付けずに指定します (例: `/.zip`)。 | クラウドアーキテクト | | E メールアドレスを提供 | Amazon SNS 通知を受信するための有効なメールアドレスを指定します。 | クラウドアーキテクト | | ログ記録のレベルを定義します。 | Lambda 関数のロギングレベルと頻度を定義します。 `Info` アプリケーションの進行状況に関する詳細な情報メッセージを指定します。 `Error` それでもアプリケーションの実行を継続できるエラーイベントを指定します。 `Warning` 潜在的に有害な状況を示します。 | クラウドアーキテクト | | 必要な DynamoDB タグキーを入力します。 | タグは必ず、それらの間にスペースを入れずにカンマで区切ります(例: `ApplicationId,CreatedBy,Environment,Organization`)。CloudWatch Events イベントはこれらのタグを検索し、見つからない場合は通知を送信します。 | クラウドアーキテクト | ### サブスクリプションを確認します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サブスクリプションを確認します。 | テンプレートが正常にデプロイされると、指定したメールアドレスに購読メールメッセージが送信されます。違反通知を受信するには、このEメールサブスクリプションを確認する必要があります。 | クラウドアーキテクト | ## 関連リソース + 「[S3 バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)」 + [ファイルを S3 バケットにアップロードする](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/upload-objects.html)  + [DynamoDB でのタグ付けのリソース](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.Operations.html) + [AWS CloudTrail を使用して AWS API コールでトリガーする CloudWatch Events ルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/638d2b87-e031-4a53-8677-2d62e563746b/attachments/attachment.zip)」 # AWS DMS と Amazon Aurora によるクロスリージョンディザスタリカバリの実装 *Mark Hudson、Amazon Web Services* ## 概要 自然災害または人為的災害はいつでも発生する可能性があり、特定の AWS リージョンで実行されているサービスとワークロードの可用性に影響を与える可能性があります。リスクを軽減するには、AWS サービスに組み込まれているクロスリージョン機能を組み込んだディザスタリカバリ (DR) 計画を立てる必要があります。本質的にクロスリージョン機能を備えていない AWS サービスの場合、DR プランは AWS リージョン間のフェイルオーバーを処理するソリューションも提供する必要があります。 このパターンでは、1 つのリージョンにある 2 つの Amazon Aurora MySQL対応版データベースクラスターを含むディザスタリカバリ設定について説明します。DR 要件を満たすため、データベースクラスターは Amazon Aurora Global Database機能を使用するように設定されており、1 つのデータベースが複数の AWS リージョンにまたがっています。AWS Database Migration Service (AWS DMS) タスクはローカルリージョン内のクラスター間でデータをレプリケートします。ただし、AWS DMS は現在、リージョン間のタスクフェイルオーバーをサポートしていません。このパターンには、この制限を回避し、両方のリージョンで AWS DMS を個別に設定するために必要なステップが含まれています。 ## 前提条件と制限事項 **前提条件** + 「[Amazon Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraFeaturesRegionsDBEngines.grids.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase)」をサポートするプライマリ AWS リージョンとセカンダリ AWS リージョンを選択しました。 + プライマリリージョンの 1 つのアカウントにある 2 つの独立した Amazon Aurora MySQL 対応版データベースクラスター。 + Database インスタンスクラスは db.r5 以上 (推奨) + 既存のデータベースクラスター間で継続的なレプリケーションを実行するプライマリリージョンの AWS DMS タスク。 + データベースインスタンスを作成するための要件を満たすための DR リージョンのリソースが整っている。VPC での DB インスタンスの操作の詳細については、「[VPC でDB インスタンスを使用する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html)」を参照してください。 **制限事項** + Amazon Aurora Global Databaseの制限の全リストについては、「[Amazon Aurora Global Databaseの制限事項](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database.limitations)」を参照してください。 **製品バージョン** + Amazon Aurora MySQL 互換エディション 5.7 または 8.0 詳細については、「[Amazon Auroraバージョン](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.html)」を参照してください。 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon Aurora MySQL 互換エディションのグローバルデータベースクラスター + AWS DMS **ターゲットアーキテクチャ** 次の図は、2 つの AWS リージョン用のグローバルデータベースを示しており、1 つにはプライマリのメインデータベースとレポーターデータベース、および AWS DMS レプリケーションがあり、もう 1 つにはセカンダリのメインデータベースとレポーターデータベースがあります。 ![\[クロスリージョングローバルデータベースのアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b01f5043-fcb5-4b1e-b79f-999792e89bed/images/3785384c-ed01-454f-b58c-fa09d223d57b.png) **自動化とスケール** AWS CloudFormation を使用して、仮想プライベートクラウド (VPC)、サブネット、パラメータグループなどの前提となるインフラストラクチャをセカンダリリージョンに作成できます。AWS CloudFormation を使用して DR リージョンにセカンダリクラスターを作成し、グローバルデータベースに追加することもできます。CloudFormation テンプレートを使用してプライマリリージョンでデータベースクラスターを作成した場合は、それらを更新するか、追加のテンプレートを追加してグローバルデータベースリソースを作成できます。詳細については、「[2 つの DB インスタンスを持つ Amazon Aurora DB クラスターの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbcluster.html#aws-resource-rds-dbcluster--examples)」と「[Aurora MySQL 用のグローバルデータベースクラスターの作成](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-globalcluster.html#aws-resource-rds-globalcluster--examples)」を参照してください。 最後に、フェイルオーバーイベントとフェイルバックイベントが発生した後に、CloudFormation を使用してプライマリリージョンとセカンダリリージョンに AWS DMS タスクを作成できます。詳細については、「[AWS::DMS::ReplicationTask](https://docs.amazonaws.cn/en_us/AWSCloudFormation/latest/UserGuide/aws-resource-dms-replicationtask.html)」を参照してください。 ## ツール + [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html) はフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL との互換性があります。このパターンでは Amazon Aurora MySQL–Compatible Edition を使用しています。 + [Amazon Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) は、グローバルに分散されたアプリケーション向けに設計されています。1 つの Amazon Aurora Global Databaseが複数の AWS リージョンにまたがる場合があります。データベースのパフォーマンスに影響を与えずにデータを複製します。また、各リージョンで低レイテンシーで高速なローカル読み取りが可能になり、リージョン全体の障害からのディザスタリカバリが可能になります。 + [AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) では、1 回限りの移行または継続的なレプリケーションが可能です。継続的なレプリケーションタスクにより、ソースデータベースとターゲットデータベースの同期が保たれます。セットアップ後、進行中のレプリケーションタスクはソースの変更を最小限のレイテンシーでターゲットに継続的に適用します。データの検証や変換などの AWS DMS のすべての機能は、どのレプリケーションタスクでも利用できます。 ## エピック ### プライマリリージョンの既存のデータベースクラスターを準備します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースクラスターパラメータグループを変更します。 | 既存のデータベースクラスターパラメータグループで、`binlog_format`パラメータを「**行**」の値に設定して行レベルのバイナリロギングを有効にします。AWS DMS では、継続的なレプリケーションまたは変更データキャプチャ (CDC) を実行する場合、MySQL 互換データベースの行レベルのバイナリロギングが必要です。詳細については、「[AWS が管理する MySQL 対応データベースを AWS DMS のソースとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.AmazonManaged)」を参照してください。 | AWS 管理者 | | データベースのバイナリログの保持期間を更新します。 | エンドユーザーデバイスにインストールした MySQL クライアントまたは Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用して、Amazon Relational Database Service (Amazon RDS) が提供する次のストアドプロシージャを実行します。ここで、`XX`はログを保持する時間数です。
call mysql.rds_set_configuration('binlog retention hours', XX)
次のコマンドを実行してこの設定を確認します。
call mysql.rds_show_configuration;
AWS が管理する MySQL 互換データベースは、バイナリログをできるだけ早く消去します。したがって、保持期間は、AWS DMS タスクが実行される前にログが消去されないように十分な長さにする必要があります。通常は 24 時間で十分ですが、この値は DR リージョンで AWS DMS タスクをセットアップするのに必要な時間に基づいている必要があります。 | DBA | ### プライマリリージョンの既存の AWS DMS タスクを更新する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS DMS タスクの ARN を記録します。 | Amazon リソースネーム (ARN) を使用して、後で使用できるようにAWS DMS タスク名を取得します。AWS DMS タスク ARN を取得するには、コンソールでタスクを表示するか、次のコマンドを実行します。
aws dms describe-replication-tasks
ARN は次のようになります。
arn:aws:dms:us-east-1::task:AN6HFFMPM246XOZVEUHCNSOVF7MQCLTOZUIRAMY
最後のコロンの後の文字は、後のステップで使用されるタスク名に対応しています。 | AWS 管理者 | | 既存の AWS DMS タスクを変更してチェックポイントを記録します。 | AWS DMS は情報を含むチェックポイントを作成し、レプリケーションエンジンは変更ストリームの復旧ポイントを確認します。チェックポイント情報を記録するには、コンソールで次のステップを実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-cross-region-disaster-recovery-with-aws-dms-and-amazon-aurora.html) | AWS 管理者 | | チェックポイント情報を検証します。 | クラスターのライターエンドポイントに接続された MySQL クライアントを使用して、レポーターデータベースクラスターの新しいメタデータテーブルをクエリし、そのテーブルが存在し、レプリケーション状態情報が含まれていることを確認します。以下のコマンドを実行してください。
select * from awsdms_control.awsdms_txn_state;
ARN のタスク名は、この表の`Task_Name`列にあるはずです。 | DBA | ### 両方の Amazon Aurora クラスターを DR リージョンに拡張する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DR リージョンに基本インフラを作成します。 | Amazon Aurora クラスターの作成とアクセスに必要な基本コンポーネントを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-cross-region-disaster-recovery-with-aws-dms-and-amazon-aurora.html)両方のパラメータグループの設定がプライマリリージョンの設定と一致していることを確認します。 | AWS 管理者 | | 両方の Amazon Aurora クラスターに DR リージョンを追加します。 | メインクラスターとレポーターの Amazon Aurora クラスターにセカンダリージョン (DR リージョン) を追加します。詳細については、「[Amazon Aurora Global DatabaseにAWS リージョンを追加](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html#aurora-global-database-attaching)」を参照してください。 | AWS 管理者 | ### フェイルオーバーを実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS DMS タスクを停止します。 | プライマリリージョンの AWS DMS タスクはフェイルオーバーが発生すると正しく機能しなくなるため、エラーを回避するために停止する必要があります。 | AWS 管理者 | | マネージドフェイルオーバーを実行してください。 | メインデータベースクラスターの DR リージョンへのマネージドフェイルオーバーを実行します。詳細については、「[Amazon Aurora Global Databaseのマネージドプラン済みフェイルオーバーを実行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)」を参照してください。メインデータベースクラスターのフェイルオーバーが完了したら、レポーターデータベースクラスターで同じアクティビティを実行します。 | AWS 管理者、データベース管理者 | | メインデータベースにデータをロードします。 | DR データベースクラスター内のメインデータベースのライターノードにテストデータを挿入します。このデータは、レプリケーションが正常に機能していることを確認するために使用されます。 | DBA | | AWS DMS レプリケーションインスタンスを作成します。 | DR リージョンに AWS DMS レプリケーションインスタンスを作成するには、「[レプリケーションインスタンスの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)」を参照してください。 | AWS 管理者、データベース管理者 | | AWS DMS ソースおよびターゲットエンドポイントを作成します。 | DR リージョンに AWS DMS ソースエンドポイントとターゲットエンドポイントを作成するには、「[ソースエンドポイントとターゲットエンドポイントの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Endpoints.Creating.html)」を参照してください。ソースは、メインデータベースクラスターのライターインスタンスを指している必要があります。ターゲットは、Reporter Database クラスターのライターインスタンスを指します。 | AWS 管理者、データベース管理者 | | レプリケーションチェックポイントを取得します。 | レプリケーションチェックポイントを取得するには、MySQL クライアントを使用して DR リージョンのレポーターデータベースクラスターのライターノードに対して以下を実行してメタデータテーブルをクエリします。
select * from awsdms_control.awsdms_txn_state;
表で、2 番目のエピックで取得したプライマリリージョンに存在する AWS DMS タスクの ARN に対応する task\$1name 値を見つけます。 | DBA | | AWS DMS タスクを作成します。 | コンソールを使用して、DR リージョンに AWS DMS タスクを作成します。タスクでは、「**データ変更のみ複製**」の移行方法を指定します。詳細については、「[タスクの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html)」を参照してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-cross-region-disaster-recovery-with-aws-dms-and-amazon-aurora.html)AWS DMS タスクの「**移行タスクを開始する**」設定を「**作成時に自動**」に設定します。 | AWS 管理者、データベース管理者 | | AWS DMS タスクの ARN を記録します。 | ARN を使用して、後で使用するための AWS DMS タスク名を取得します。AWS DMS タスク ARN を取得するには、次のコマンドを実行します。
aws dms describe-replication-tasks
| AWS 管理者、データベース管理者 | | 複製されたデータを検証します。 | DR リージョンのレポーターデータベースクラスターにクエリを実行して、メインデータベースクラスターに読み込んだテストデータが複製されていることを確認します。 | DBA | ### フェイルバックを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS DMS タスクを停止します。 | DR リージョンの AWS DMS タスクは、フェイルバックが発生すると正しく機能しなくなるため、エラーを回避するために停止する必要があります。 | AWS 管理者 | | マネージドフェイルバックを実行してください。 | メインデータベースクラスターをプライマリリージョンにフェイルバックします。詳細については、「[Amazon Aurora Global Databaseのマネージドプラン済みフェイルオーバーを実行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)」を参照してください。メインデータベースクラスターのフェイルバックが完了したら、レポーターデータベースクラスターで同じアクティビティを実行します。 | AWS 管理者、データベース管理者 | | レプリケーションチェックポイントを取得します。 | レプリケーションチェックポイントを取得するには、MySQL クライアントを使用して DR リージョンのレポーターデータベースクラスターのライターノードに対して以下を実行してメタデータテーブルをクエリします。
select * from awsdms_control.awsdms_txn_state;
表で、4 番目のエピックで取得した DR リージョンに存在する AWS DMS タスクの ARN に対応する`task_name`値を見つけます。 | DBA | | AWS DMS ソースとターゲットのエンドポイントを更新します。 | データベースクラスターがフェイルバックしたら、プライマリリージョンのクラスターをチェックして、どのノードがライターインスタンスであるかを判断します。次に、プライマリリージョンの既存の AWS DMS ソースエンドポイントとターゲットエンドポイントがライターインスタンスを指していることを確認します。そうでない場合は、ライターインスタンスのドメインネームシステム (DNS) 名でエンドポイントを更新します。 | AWS 管理者 | | AWS DMS タスクを作成します。 | コンソールを使用して、プライマリリージョンに AWS DMS タスクを作成します。タスクでは、「**データ変更のみ複製**」の移行方法を指定します。詳細については、「[タスクの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html)」を参照してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-cross-region-disaster-recovery-with-aws-dms-and-amazon-aurora.html) | AWS 管理者、データベース管理者 | | AWS DMS タスク Amazon リソースネーム (ARN) を記録します。 | ARN を使用して、後で使用するための AWS DMS タスク名を取得します。AWS DMS タスク ARN を取得するには、次のコマンドを実行します。
aws dms describe-replication-tasks
タスク名は、別のマネージドフェイルオーバーを実行するときや DR シナリオ中に必要になります。 | AWS 管理者、データベース管理者 | | AWS DMS タスクを削除します。 | プライマリリージョンの元の (現在停止している) AWS DMS タスクと、セカンダリリージョンの既存の AWS DMS タスク (現在停止中) を削除します。 | AWS 管理者 | ## 関連リソース + [Amazon Aurora DB クラスターの設定](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraSettingUp.html) + [Amazon Aurora Global Database の使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) + [Amazon Aurora MySQL の操作](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.html) + [ AWS DMS レプリケーション インスタンスを使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html) + [AWS DMS エンドポイントの使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Endpoints.html) + [AWS DMS タスクでの作業](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html) + [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) ## 追加情報 この例では Amazon Aurora Global Databaseを DR に使用しています。これは、目標復旧時間 (RTO) が 1 秒、目標復旧時点 (RPO) が 1 分未満であるためです。どちらも従来の複製ソリューションよりも低く、DR シナリオに最適です。 Amazon Aurora Global Databaseには、他にも次のような多くの利点があります。 + ローカルレイテンシーによるグローバル読み取り — 世界中の消費者は、ローカルリージョンの情報にローカルレイテンシーでアクセスできます。 + スケーラブルなセカンダリ Amazon Aurora DB クラスター — セカンダリクラスターは個別にスケーリングでき、最大 16 の読み取り専用レプリカを追加できます。 + プライマリからセカンダリの Amazon Aurora DB クラスターへの迅速なレプリケーション-Aurora Global Database によるレプリケーションは、プライマリ DB クラスターのパフォーマンスにほとんど影響しません。これはストレージレイヤーで発生し、クロスリージョンレプリケーションのレイテンシーは通常 1 秒未満です。 このパターンでは、レプリケーションにも AWS DMS を使用します。Amazon Aurora データベースにはリードレプリカを作成できるため、レプリケーションプロセスと DR セットアップを簡素化できます。ただし、データ変換が必要な場合や、ターゲットデータベースがソースデータベースにない追加のインデックスを必要とする場合に、AWS DMS は複製によく使用されます。 # 100 個以上の引数を持つ Oracle 関数とプロシージャを PostgreSQL に移行 *Amazon Web Services、Srinivas Potlachervoo* ## 概要 このパターンでは、100 を超える引数を持つ Oracle データベースの関数とプロシージャを PostgreSQL に移行する方法を示しています。例えば、このパターンを使用して Oracle の関数とプロシージャを以下の PostgreSQL 互換の AWS データベースサービスのいずれかに移行できます。 + PostgreSQL の Amazon Relational Database Service (Amazon RDS) + Amazon Aurora PostgreSQL 互換エディション PostgreSQLには、100 個以上の引数を持つ関数やプロシージャが適用されません。回避策として、ソース関数の引数と一致するタイプフィールドを持つ新しいデータ型を定義できます。次に、カスタムデータ型を引数として使用する PL/pgSQL 関数を作成して実行できます。 ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + 「[Amazon RDS Oracle Database DB インスタンス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html)」 + 「[Amazon RDS for PostgreSQL DB インスタンス](https://aws.amazon.com/getting-started/hands-on/create-connect-postgresql-db/)」 または 「[Aurora PostgreSQL 互換 DB インスタンス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.html)」 **製品バージョン** + Amazon RDS Oracle DB インスタンス バージョン 10.2 以降 + Amazon RDS PostgreSQL DB インスタンス バージョン 9.4 以降、または Aurora PostgreSQL 互換 DB インスタンスバージョン 9.4 以降 + Oracle SQL Developer バージョン 18 以降 + pgAdmin バージョン 4 以降 ## アーキテクチャ **ソーステクノロジースタック** + Amazon RDS Oracle DB インスタンス バージョン 10.2 以降 **ターゲットテクノロジースタック** + Amazon RDS PostgreSQL DB インスタンス バージョン 9.4 以降、または Aurora PostgreSQL 互換 DB インスタンス バージョン 9.4 以降 ## ツール **AWS サービス** + 「[PostgreSQL の Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html)」 を使用して、AWS クラウドで PostgreSQL リレーショナルデータベース (DB) をセットアップ、運用、スケーリングができます。 + 「[Amazon Aurora PostgreSQL 互換エディション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)」は、PostgreSQL デプロイのセットアップ、運用、スケーリングに役立つ、フルマネージド型のACID準拠のリレーショナルデータベースエンジンです。 **その他のサービス** + 「[Oracle SQL Developer](https://www.oracle.com/database/technologies/appdev/sqldeveloper-landing.html)」 は、従来のデプロイとクラウドベースのデプロイの両方で Oracle データベースの開発と管理を簡素化する統合開発環境です。 + 「[pgAdmin](https://www.pgadmin.org/)」は PostgreSQL のオープンソース管理ツールです。データベースオブジェクトの作成、管理、使用を支援するグラフィカルインターフェイスを提供します。 ## ベストプラクティス 作成するデータ型が、ソース Oracle 関数またはプロシージャに含まれる型フィールドと一致することを保証します。 ## エピック ### 100 個以上の引数を持つ Oracle の関数またはプロシージャを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 100個以上の引数を持つ既存の Oracle/plSQL 関数またはプロシージャを作成または識別する。 | 100個以上の引数を持つ Oracle/PLSQL 関数またはプロシージャを作成します。-または-100個以上の引数を持つ既存の Oracle/plSQL 関数またはプロシージャを特定します。詳細については、Oracle データベースのドキュメントのセクション 「[14.7 関数作成ステートメント](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/lnpls/CREATE-FUNCTION-statement.html#GUID-B71BC5BD-B87C-4054-AAA5-213E856651F2)」 と 「[14.11 プロシージャステートメントの作成](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/lnpls/CREATE-PROCEDURE-statement.html#GUID-5F84DB47-B5BE-4292-848F-756BF365EC54)」 を参照してください。 | Oracle/PL/SQL の知識 | | Oracle/PLSQL 関数またはプロシージャをコンパイルします。 | Oracle/PLSQL 関数またはプロシージャをコンパイルします。詳細については、Oracle データベースドキュメントの「[関数のコンパイル](https://docs.oracle.com/cd/E37097_01/doc.42/e35128/GUID-6B7B6F82-616D-4915-82BE-D4AE7F59CF37.htm#AEUTL165)」を参照してください。 | Oracle/PL/SQL に関する知識 | | Oracle/plSQL 関数を実行します。 | Oracle/PLSQL 関数またはプロシージャを実行します。次に、出力を保存します。 | Oracle/PL/SQL の知識 | ### ソース関数またはプロシージャの引数と一致する新しいデータ型を定義します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | PostgreSQL で新しいデータ型を定義します。 | ソース Oracle 関数、またはプロシージャの引数と同じフィールドをすべて含む、新しいデータ型を PostgreSQL で定義します。詳細については、PostgreSQL のドキュメントの「[型の作成](https://www.postgresql.org/docs/current/sql-createtype.html)」 を参照してください。 | PostgreSQL PL/pgSQL の知識 | ### 新しい型引数を含む PostgreSQL 関数を作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 新しいデータ型を含む PostgreSQL 関数を作成します。 | 新しい `TYPE` 引数を含む PostgreSQL 関数を作成します。サンプル関数を確認するには、このパターンの「**追加情報**」セクションを参照してください。 | PostgreSQL PL/pgSQL の知識 | | PostgreSQL 関数をコンパイルします。 | PostgreSQL で関数をコンパイルします。新しいデータ型フィールドがソース関数またはプロシージャの引数と一致すれば、関数は正常にコンパイルされます。 | PostgreSQL PL/pgSQL の知識 | | PostgreSQL 関数を実行します。 | PostgreSQL 関数を実行します。 | PostgreSQL PL/pgSQL の知識 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 関数は、次のエラーを返します：**エラー:「」付近の構文エラー** | 関数のステートメントが、すべてセミコロン (`;`) で終わっていることを確認してください。 | | 関数は、次のエラーを返します：**エラー:「」が既知の変数ではありません** | 関数ボディで使用されている変数が、関数の `DECLARE` セクションに確実にリストされているようにします。 | ## 関連リソース + 「[Amazon Aurora PostgreSQL との連携](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html)」 (* Amazon Aurora ユーザーガイド*) + 「[型の作成](https://www.postgresql.org/docs/11/sql-createtype.html)」(PostgreSQL ドキュメント) ## 追加情報 **タイプ引数を含むPostgreSQL関数の例** ``` CREATE OR REPLACE FUNCTION test_proc_new ( IN p_rec type_test_proc_args ) RETURNS void AS $BODY$ BEGIN /* ************** The body would contain code to process the input values. For our testing, we will display couple of values. *************** */ RAISE NOTICE USING MESSAGE = CONCAT_WS('', 'p_acct_id: ', p_rec.p_acct_id); RAISE NOTICE USING MESSAGE = CONCAT_WS('', 'p_ord_id: ', p_rec.p_ord_id); RAISE NOTICE USING MESSAGE = CONCAT_WS('', 'p_ord_date: ', p_rec.p_ord_date); END; $BODY$ LANGUAGE plpgsql COST 100; ``` # Redis ワークロードを AWS 上の Redis Enterprise Cloud に移行 *Amazon Web Services、Antony Prasad Thevaraj* *Redis、Srinivas Pendyala* ## 概要 このパターンでは、Redis ワークロードをAmazon Web Services (AWS) 上の Redis Enterprise Cloud に移行するための大まかなプロセスについて説明します。移行手順について説明し、使用可能なツールの選択に関する情報を提供し、各ツールを使用する場合の利点、欠点、手順について説明します。Redis からワークロードを移行する際にさらにサポートが必要な場合は、Redis プロフェッショナルサービスをご利用いただくこともできます。 Redis OSS または Redis Enterprise Software をオンプレミスで実行している場合、データセンターで Redis データベースを管理することによる多大な管理オーバーヘッドと運用上の複雑さをよくご存知でしょう。ワークロードをクラウドに移行することで、この運用上の負担を大幅に軽減し、Redis が提供する完全にホストされたサービスとしてのデータベース (DBaaS) である「[Redis Enterprise Cloud](https://redis.com/redis-enterprise-cloud/overview/)」を活用できます。この移行により、99.999% の可用性、アーキテクチャのシンプルさ、拡張性などの最新の Redis Enterprise Cloud on AWS 機能を利用しながら、ビジネスの俊敏性を高め、アプリケーションの信頼性を向上させ、全体的なコストを削減できます。 Redis Enterprise Cloud は、金融サービス、小売、医療、ゲームの分野だけでなく、不正検出、リアルタイムインベントリ、請求処理、セッション管理のソリューションを必要とするユースケースにも応用できる可能性があります。Redis Enterprise Cloud を使用して AWS リソースに接続できます。例えば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されているアプリケーションサーバーや、AWS Lambda サービスとしてデプロイされているマイクロサービスに接続できます。 ## 前提条件と制限事項 引き受け + 現在、クラウドに移行したいオンプレミスのデータベースシステムを運用しています。 + 以下を含むワークロードの移行要件を確認しました。 + データ整合性の要件 + インフラストラクチャとシステム環境の要件 + データマッピングと変換の要件 + 機能テストの要件 + パフォーマンステストの要件 + 検証要件 + 定義済みのカットオーバー戦略 + 移行に必要なスケジュールとコストの見積もりを評価しました。 + 要件は、作業の範囲と、移行の一環として特定したシステムやデータベースを考慮に入れています。 + 実行責任者、説明責任者、協議先、報告先 (RACI) マトリックスで、ステークホルダーとその役割と責任を特定しました。 + すべての利害関係者から必要な合意と承認を受けています。 コスト 既存のソースデータベースの技術仕様 (メモリサイズ、スループット、合計データサイズなど) に応じて、Redis ソリューションアーキテクトは Redis Enterprise Cloud 上のターゲットシステムのサイジングを行うことができます。 一般的な料金情報については、Redis ウェブサイトの「[Redis 料金](https://redis.com/redis-enterprise-cloud/pricing)」を参照してください。 人材とスキル 移行プロセスには以下の役割と責任があります。 | | | ロール | 説明 | 必要なスキル | | --- |--- |--- | | 移行ソリューションアーキテクト | 移行戦略の定義、計画、実装に関する専門知識を持つテクニカルアーキテクト | ソースシステムとターゲットシステムに関する技術レベルおよびアプリケーションレベルの理解、クラウドへのワークロード移行の経験 | | データアーキテクト | さまざまなデータベースのデータソリューションの定義、実装、提供において幅広い経験を持つテクニカルアーキテクト | 構造化データと非構造化データのデータモデリング、企業向けデータベースの実装に関する深い理解と経験 | | Redis ソリューションアーキテクト | 適切なユースケースに最適なサイズの Redis クラスターの設計をアーキテクトできるテクニカルアーキテクト | さまざまなユースケースに対応する Redis ソリューションの設計とデプロイに関する専門知識 | | クラウドソリューションアーキテクト | クラウドソリューション、特に AWS のソリューションをより深く理解しているテクニカルアーキテクト | クラウド向けソリューションの設計に関する専門知識、ワークロードの移行、アプリケーションのモダナイゼーションの経験 | | エンタープライズアーキテクト | 組織の技術情勢を完全に理解し、future ロードマップについて共通のビジョンを持ち、組織内のすべてのチームで標準化されたアーキテクチャのベストプラクティスを実践および確立するテクニカルアーキテクト | TOGAF などのソフトウェアアーキテクチャ認定資格、基本的なソフトウェアエンジニアリングスキル、ソリューションアーキテクチャ、エンタープライズアーキテクチャの専門知識 | | IT エンジニアまたは DevOps エンジニア | インフラストラクチャの問題点の監視、メンテナンスタスクの実行、必要に応じた更新など、インフラストラクチャの作成と保守を担当するエンジニア。 | オペレーティングシステム、ネットワーク、クラウドコンピューティングなど、さまざまなテクノロジーに関する深い知識、Python、Bash、Rubyなどのプログラミング言語や、Docker、Kubernetes、Ansibleなどのツールに精通していること | ## アーキテクチャ 移行オプション 次の図は、オンプレミス (Redis ベースまたはその他) のデータソースを AWS に移行するためのオプションを示しています。Redis データベース (RDB) ファイルを Amazon Simple Storage Service (Amazon S3) にエクスポートしたり、Redis レプリケーション機能を使用したり、AWS DMS を使用したりするなど、選択できるいくつかの移行ツールを示しています。 ![\[オンプレミスのデータソースを AWS 上の Redis エンタープライズクラウドに移行するためのオプション\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/384309f6-7218-4a46-83a5-f37ff95c8832/images/4b242a29-d283-49a3-aaea-a970813db6be.png) 1. オンプレミスデータソース: MySQL、PostgreSQL、Oracle、SQL Server、MariaDB など、Redis に基づいていないデータベース。  1. オンプレミスデータソース:Redis OSS や Redis エンタープライズソフトウェアなどの Redis プロトコルベースのデータベース。 1. Redis ベースのデータベースからデータを移行する最も簡単な方法は、RDB ファイルをエクスポートし、ターゲットの Redis Enterprise Cloud on AWS にインポートすることです。 1. また、Redis のレプリケーション機能 (`ReplicaOf`) を使用してソースからターゲットにデータを移行することもできます。 1. データ移行要件にデータ変換が含まれる場合は、Redis 入出力ツール (RIOT) を使用してデータを移行できます。 1. または、AWS Database Migration Service (AWS DMS) を使用して、SQL ベースのデータベースからのデータを移行できます。  1. データをターゲット Redis Enterprise Cloud on AWS に正常に移行するには、AWS DMS の仮想プライベートクラウド (VPC) ピアリングを使用する必要があります。 **ターゲットアーキテクチャ** 次の図は、Redis Enterprise Cloud on AWS の一般的なデプロイアーキテクチャと、このアーキテクチャを主要な AWS サービスでどのように使用できるかを示しています。 ![\[AWS 上の Redis エンタープライズクラウドのデプロイアーキテクチャと AWS サービスとの併用\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/384309f6-7218-4a46-83a5-f37ff95c8832/images/f1351537-e710-4a68-8768-89d44870150f.png) 1. Redis Enterprise Cloud on AWS によってサポートされているビジネスアプリケーションに接続できます。 1. ビジネスアプリケーションは、自分の AWS アカウント、そのアカウント内の VPC で実行できます。 1. Redis Enterprise Cloud のデータベースエンドポイントを使用してアプリケーションに接続できます。例としては、EC2 インスタンスで実行されるアプリケーションサーバー、AWS Lambda サービスとしてデプロイされたマイクロサービス、Amazon Elastic Container Service (Amazon ECS) アプリケーション、Amazon Elastic Kubernetes Service（Amazon EKS）アプリケーションなどが含まれます。 1. VPC で実行されるビジネスアプリケーションには、Redis Enterprise Cloud VPC への VPC ピア接続が必要です。これにより、ビジネスアプリケーションはプライベートエンドポイントを介して安全に接続できます。 1. Redis Enterprise Cloud on AWS は、AWSにDBaaAWS としてデプロイされたインメモリNoSQLデータベースプラットフォームであり、Redisによって完全に管理されています。 1. Redis エンタープライズクラウドは、Redis が作成した標準 AWS アカウントの VPC 内にデプロイされます。 1. セキュリティ上の理由から、Redis Enterprise Cloud はプライベートエンドポイントとパブリックエンドポイントの両方からアクセスできるプライベートサブネットにデプロイされます。クライアントアプリケーションをプライベートエンドポイントの Redis に接続することをお勧めします。パブリックエンドポイントを使用する予定の場合は、「[TLS を有効](https://docs.redis.com/latest/rc/security/database-security/tls-ssl/)」にしてクライアントアプリケーションと Redis Enterprise Cloud 間のデータを暗号化することを強くお勧めします。 Redis の移行方法論は、AWS 規範ガイダンスのウェブサイトの「[組織を動員して大規模な移行を加速する](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/overview.html)」で説明されている AWS 移行方法論と一致しています。 **自動化とスケール** 移行のための環境設定タスクは、AWS Landing Zone とコードとしての infrastructure as code (IaC) テンプレートを使用して自動化し、自動化と拡張を行うことができます。これらについては、このパターンの「[エピック](#migrate-redis-workloads-to-redis-enterprise-cloud-on-aws-epics)」セクションで説明しています。 ## ツール データ移行要件に基づいて、さまざまな技術オプションから選択して、データを Redis Enterprise Cloud on AWS に移行できます。以下の表は、これらのツールの説明と比較です。 | | | ツール | 説明 | 利点 | 欠点 | | --- |--- |--- |--- | | 「[RDB のエクスポート](https://docs.redis.com/latest/rc/api/examples/back-up-and-import-data/)」と「[インポート](https://docs.redis.com/latest/rc/databases/import-data/)」 | ソース (Redis OSS や Redis エンタープライズソフトウェアなど) データベースから RDB ファイルの形式でデータをエクスポートします。データベースが Redis OSS クラスターを通じて提供されている場合は、各マスターシャードを RDB にエクスポートします。その後、すべての RDB ファイルを 1 回の手順でインポートします。ソースデータベースが OSS クラスターに基づいているが、ターゲットデータベースが OSS Cluster API を使用していない場合は、標準の Redis クライアントライブラリを使用するようにアプリケーションのソースコードを変更する必要があります。データ変換要件または論理データベースのマージには、より複雑なプロセスが必要です。これについては、この表の後半の「*論理データベースのマージ*」で説明しています。 | シンプルRDB 形式のデータをソースとしてエクスポートできるあらゆる Redis ベースのソリューション (Redis OSS や Redis エンタープライズソフトウェアを含む) で動作します。簡単なプロセスでデータ整合性を実現します。 | データ変換要件に対応しておらず、論理的なデータベース統合もサポートしていない。データセットが大きいと時間がかかる。デルタ移行がサポートされていないと、ダウンタイムが長くなる可能性があります。 | | 「[Redis レプリケーション機能](https://docs.redis.com/latest/rs/databases/import-export/replica-of/)」(アクティブ/パッシブ) | Redis OSS、エンタープライズソフトウェア、またはエンタープライズクラウドデータベースから Redis Enterprise Cloud データベースにデータを継続的に複製できます。初回同期後、Redis レプリケーション機能 (`ReplicaOf`) はデルタ移行を実行します。つまり、アプリケーションのダウンタイムはほとんど発生しません。Redis のレプリケーション機能はアクティブ/パッシブな方法で使用することを目的としています。ターゲットはパッシブであると想定され、完全に再同期 (ソースデータベースからフラッシュおよび同期) されます。そのため、ソースとターゲットを切り替えるのはやや複雑です。OSS クラスターのすべてのマスターシャードをソースとして指定することで、Redis OSS クラスターから標準のクラスター化された Redis Enterprise Cloud データベースに複製できます。ただし、Redis レプリケーション機能では最大 32 のソースデータベースを使用できます。 | 連続レプリケーション (初期データロードとそれに続くデルタ) をサポートします。ダウンタイムはほとんどありません (レプリケーションの遅延により異なります)。データの整合性を確保します。 | アクティブなサイトは 1 つだけなので、サイト間の切り替えはより複雑です。OSS クラスターから移行する場合、最大 32 のマスターシャードをサポートします。 | | AWS DMS | AWS DMS を使用して、サポートされているソースデータベースからターゲットの Redis データストアへ、最小限のダウンタイムでデータを移行することができます。詳細については、AWS DMS ドキュメントの「[AWS DMS のターゲットとしての Redis の使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Redis.html)」を参照してください。 | NoSQL と SQL の両方のデータソースの移行をサポートします。AWS の他のサービスともうまく連携しています。ライブマイグレーションと変更データキャプチャ (CDC) のユースケースをサポートします。 | Redis のキー値には% などの特殊文字を含めることはできません。行やフィールド名に特殊文字を含むデータの移行はサポートされていません。フルラージバイナリオブジェクト (LOB) モードはサポートしていません。 | | 論理データベースマージ | 特殊なデータベースマージ要件では、カスタムデータ移行ソリューションが必要になる場合があります。例えば、Redis OSS には 4 つの論理データベース (`SELECT 0..3`) があっても、データを複数の Redis Enterprise Cloud データベースに移動する代わりに 1 つのデータベースエンドポイントを使用したい場合があります。Redis Enterprise は選択可能な論理データベースをサポートしていないため、ソースデータベースの物理データモデルを変換する必要があります。例えば、各データベースインデックスをプレフィックス (`0` から `usr`、`1` から `cmp` など) にマップし、移行スクリプトまたは抽出、変換、ロード (ETL) ツールを使用して RDB ファイルを出力し、ターゲットデータベースにインポートできます。 | カスタムスクリプトを使用して、ターゲットシステムへの移行中のデータのシェーピングをきめ細かく制御できます。  | 移行を完了しないことにした場合、特に新しいデータをソースシステムにロールバックする必要がある場合、ロールバックは非常に困難になる可能性があります。1 回限りの移行のための 1 回限りのソリューションを構築することが目標の場合、構築コストが高くなる可能性があります。移行要件が頻繁に変わると、コード、インフラストラクチャ、開発時間、その他の分野のメンテナンスコストが高くなる可能性があります。  | さらに、AWS の次のツールとサービスを使用できます。 評価および検出ツール: + 「[Migration Evaluator](https://aws.amazon.com/migration-evaluator/)」 アプリケーションおよびサーバー移行ツール: + AWS Application Migration Service 「[データベース移行ツール](https://aws.amazon.com/solutions/database-migrations/)」: + 「[AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html)」 + 「[AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)」 「[データ移行ツール](https://aws.amazon.com/cloud-data-migration/)」: + [AWS Storage Gateway](https://aws.amazon.com/storagegateway/) + [AWS DataSync](https://aws.amazon.com/datasync/) + [AWS Direct Connect](https://aws.amazon.com/directconnect/) + [AWS Snowball](https://aws.amazon.com/snowball/) + [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/) AWS パートナーソリューション: + 「[AWS 移行コンピテンシーパートナー](https://aws.amazon.com/migration/partner-solutions/)」 ## エピック ### 検出と評価のタスクを完了してください。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ワークロードを特定します。 | 移行したいワークロードの候補を特定します。移行するワークロードを選択する前に、以下を検討してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html)ビジネスへの影響が最大で、リスクが最小限になるワークロードを選択するのが理想的です。プロセス全体を反復的に行い、少しずつ移行してください。 | データアーキテクト、ビジネスチャンピオン、移行プロジェクトスポンサー | | データソースと要件を特定し、データモデルを設計します。 | Redis はワークショップを実施して、発見までの時間を短縮し、プロジェクトの移行計画を定義しています。このワークショップの一環として、Redis チームはデータソースとソースデータモデルの要件を特定し、それらを Redis Enterprise Cloud でどのように改造できるかを分析します。Redis 移行チーム (プロフェッショナルサービス) は、組織と共に詳細なデータモデル設計演習を行います。この演習の一環として、Redis チームは次のことを行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | Redis ソリューションアーキテクト | | ソースデータベースの特性を特定します。 | ソース環境とターゲット環境で使用されている Redis 製品を特定してください。例えば、次のようになります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | データアーキテクト | | 現在のシステム SLA とその他のサイジング指標を収集します。 | スループット (1 秒あたりのオペレーション)、レイテンシー、データベースごとの全体的なメモリサイズ、および高可用性 (HA) 要件で表される現在のサービスレベルアグリーメント (SLA) を決定します。 | データアーキテクト | | ターゲットシステムの特性を特定します。 | 以下の質問に対する答えを決めてください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | データアーキテクト、Redis ソリューションアーキテクト (オプション) | | 依存関係を確認します。 | 移行する現在のシステムのアップストリームとダウンストリームの依存関係を特定します。移行作業が、依存する他のシステム移行と連動していることを確認してください。例えば、他のビジネスアプリケーションをオンプレミスから AWS クラウドに移行することを計画している場合は、それらのアプリケーションを特定し、プロジェクトの目標、タイムライン、利害関係者に基づいて調整します。 | データアーキテクト、エンタープライズアーキテクト | | 移行ツールを特定します。 | データ移行要件 (ソースデータやダウンタイム要件など) に応じて、前述の「[ツール](#migrate-redis-workloads-to-redis-enterprise-cloud-on-aws-tools)」セクションで説明したどのツールでも使用できます。さらに、次のことが行えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | 移行ソリューションアーキテクト、Redis ソリューションアーキテクト | | コンティンジェンシープランを作成します。 | 移行中に問題が発生した場合に備えて、ロールバックするための緊急時対応計画を立ててください。 | プロジェクト管理、アーキテクトを含む技術チーム | ### セキュリティとコンプライアンスのタスクを完了してください。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Redis 管理コンソールをセキュリティで保護します。 | 管理コンソールを保護するには、「[Redis](https://redis.io/docs/latest/operate/oss_and_stack/management/security/)」ドキュメントの指示に従ってください。 | IT インフラストラクチャ管理者 | | Redis データベースを保護します。 | Redis ドキュメントの以下のページを参照してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | | | セキュアな Redis クラウド API。 | 「[API を有効化する](https://docs.redis.com/latest/rc/api/get-started/enable-the-api/)」と、Redis Cloud アカウントのすべての所有者の「[API キーを管理](https://docs.redis.com/latest/rc/api/get-started/manage-api-keys/)」できます。API のセキュリティ機能の概要については、Redis ウェブサイトの「[API 認証ドキュメント](https://docs.redis.com/latest/rc/api/get-started/)」を参照してください。 | IT インフラストラクチャ管理者 | ### 新環境のセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS に新しい環境を設定します。 | このタスクには以下が含まれます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | IT エンジニアまたは DevOps エンジニア | | 移行アーキテクチャをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html)これで、実際のデータ移行パイプラインを実行してテストできます。 | IT エンジニアまたは DevOps エンジニア | ### ネットワークを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 接続を確立します。 | オンプレミスインフラストラクチャと AWS クラウドリソース間の接続を確立します。この機能を実現するには、セキュリティグループ、AWS Direct Connect、およびその他のリソースを使用してください。詳細については、AWS ウェブサイトの「[データセンターを AWS に接続](https://aws.amazon.com/getting-started/hands-on/connect-data-center-to-aws/)」を参照してください。 | IT エンジニアまたは DevOps エンジニア | | VPC ピアリングの設定 | ビジネスアプリケーションを実行する VPC (または移行ツールや AWS DMS レプリケーションサーバーを実行する EC2 インスタンス) と Redis Enterprise Cloud を実行する VPC との間で VPC ピアリングを確立します。手順については、Amazon VPC ドキュメントの「[Amazon VPC の使用開始](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html)」を、Redis ドキュメントの「[VPC ピアリングの有効化](https://docs.redis.com/latest/rc/security/vpc-peering/)」を参照してください。 | IT エンジニアまたは DevOps エンジニア | ### データを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データ移行ツールを選択してください。 | 「[ツール](#migrate-redis-workloads-to-redis-enterprise-cloud-on-aws-tools)」セクションのテーブルで、これらのツールの説明、長所、短所を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html)次の行には、各ツールに関連するデータ移行タスクが説明されています。 | 移行ソリューションアーキテクト | | オプション 1: RDB のエクスポートとインポートを使用する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html)詳細については、「[Redis ドキュメント](https://docs.redis.com/latest/rc/databases/import-data/)」を参照してください。 | 移行ソリューションアーキテクト、Redis ソリューションアーキテクト | | オプション 2: Redis のレプリケーション機能 (アクティブ/パッシブ) を使用します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html)詳細については、「[Redis ドキュメント](https://docs.redis.com/latest/rs/databases/import-export/replica-of/)」を参照してください。 | 移行ソリューションアーキテクト、Redis ソリューションアーキテクト | | オプション 3: AWS DMS を使用する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.html) | 移行ソリューションアーキテクト、Redis ソリューションアーキテクト | | オプション 4: 論理的なデータベースマージを使用する。 | このオプションでは、ソースデータベースの物理データモデルを変換し、RDB ファイルを生成できる移行スクリプトまたは ETL ツールを使用します。Redis プロフェッショナルサービスは、必要に応じてこのステップを支援します。 | 移行ソリューションアーキテクト、Redis ソリューションアーキテクト | ### アプリケーションを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プロジェクト管理のスケジュールと目標を調整する。 | アプリケーションレイヤーの移行プロジェクトの目標、マイルストーン、タイムラインを Redis データ移行プロジェクトの目標と一致させてください。 | プロジェクト管理 | | テストアクティビティを調整します。 | アプリケーションレイヤーを AWS クラウドに移行して最新化したら、アプリケーションレイヤーを新しく移行した Redis Enterprise Cloud on AWS にポイントしてテストします。 | テスト | ### テスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | テストプランを実装します。 | 実装フェーズで開発されたデータ移行ルーチンとスクリプトを、テスト要件に従ってサイトで実行します。 | テスト | | テストデータの品質 | データを移行した後、データ品質をテストします。 | テスト | | 機能をテストします。 | データクエリとアプリケーション層をテストして、アプリケーションがソースシステムと同じレベルで動作していることを確認します。 | テスト | ### カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | カットオーバーの決定を下してください。 | アプリケーションレベルとデータベースレベルのテストがすべて完了したら、エグゼクティブリーダーシップチームと利害関係者は、テストチームが確認した最終結果に基づいて、AWS の新しい環境に移行するかどうかの最終決定を下します。 | プロジェクト管理、ビジネスチャンピオン | | AWS クラウドに切り替えます。 | すべてが整っていることを確認したら、アプリケーション層を新しく移行したデータを指し、クライアントは AWS 上の新しい Redis Enterprise Cloud システムに基づいて実行されている新しいアプリケーション層を指します。 | IT または DevOps エンジニア、データアーキテクト、移行ソリューションアーキテクト、Redis ソリューションアーキテクト | ## 関連リソース Redis リソース + 「[Redis エンタープライズクラウド-ドキュメント](https://docs.redis.com/latest/rc/)」 + 「[RIOT](https://github.com/redis-developer/riot)」ツール (GitHub リポジトリ) + 「[テラフォームプロバイダー](https://registry.terraform.io/providers/RedisLabs/rediscloud/latest)」(ダウンロード) 「**AWS リソース**」 + 「[デモマイグレーション](https://aws.amazon.com/getting-started/tutorials/)」 + 「[AWS パートナーソリューション](https://aws.amazon.com/quickstart/)」 + [ドキュメント](https://docs.aws.amazon.com/index.html) + [ブログ記事](https://aws.amazon.com/blogs/database/category/migration/) + 「[ホワイトペーパー](https://aws.amazon.com/whitepapers/)」 + [チュートリアルと動画](https://aws.amazon.com/getting-started/tutorials/) + 「[AWS クラウド移行](https://aws.amazon.com/cloud-migration/)」 + [AWS 規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/) ## 追加情報 Redis ワークロードを AWS クラウドに移行するための標準的なセキュリティ要件について、詳細は AWS ウェブサイトの「[Best Practices for Security, Identity, and Compliance](https://aws.amazon.com/architecture/security-identity-compliance/)」および Redis ウェブサイトの「[Redis Trust Center](https://trust.redis.io/)」をご確認ください。 # 同じホスト名の SAP HSR を使用して SAP HANA を AWS に移行します *Amazon Web Services、Pradeep Puliyampatta* ## 概要 SAP HANA の Amazon Web Services (AWS) への移行は、バックアップと復元、エクスポートとインポート、SAP HANA システムレプリケーション (HSR) など、複数のオプションを使用して実行できます。どのオプションを選択するかは、ソースとターゲットの SAP HANA データベース間のネットワーク接続、ソースデータベースのサイズ、ダウンタイムの考慮事項、およびその他の要因によって異なります。  SAP HANA ワークロードをAWSに移行するための SAP HSR オプションは、ソースシステムとターゲットシステム間のネットワークが安定しており、SAP が SAP HSR のネットワークスループット要件として規定しているように、データベース全体 （SAP HANA DBレプリケーションスナップショット） を1日以内に完全にレプリケートできる場合にうまく機能します。このアプローチによるダウンタイム要件は、ターゲット AWS 環境でのテイクオーバー、SAP HANA DB バックアップ、移行後タスクの実行に限定されます。 SAP HSR は、プライマリ (ソース) システムとセカンダリ (ターゲット) システム間のレプリケーショントラフィックに、異なるホスト名 (異なる IP アドレスにマップされたホスト名) の使用をサポートしています。そのためには、`global.ini`の`[system_replication_hostname_resolution]`セクションで特定のホスト名セットを定義してください。このセクションでは、プライマリサイトとセカンダリサイトのすべてのホストを各ホストで定義する必要があります。詳細な設定手順については、「[SAP ドキュメンテーション](https://help.sap.com/viewer/eb3777d5495d46c5b2fa773206bbfb46/1.0.12/en-US/c0cba1cb2ba34ec89f45b48b2157ec7b.html)」を参照してください。 この設定で重要な 1 つは、プライマリシステムのホスト名はセカンダリシステムのホスト名と異なっていなければならないということです。そうしないと、次のようなエラーが発生する可能性があります。 + `"each site must have a unique set of logical hostnames"` + `"remoteHost does not match with any host of the source site. All hosts of source and target site must be able to resolve all hostnames of both sites correctly"` ただし、移行後のステップの数は、ターゲット AWS 環境で同じ SAP HANA DB ホスト名を使用することで減らすことができます。  このパターンは、SAP HSR オプションを使用するときに、ソース環境とターゲット環境で同じホスト名を使用する場合の回避策となります。このパターンでは、SAP HANA ホスト名の名前変更オプションを使用できます。SAP HSR のホスト名が一意になるように、ターゲット SAP HANA DB に一時的なホスト名を割り当てます。移行によってターゲット SAP HANA 環境でのテイクオーバーマイルストーンが完了すると、ターゲットシステムのホスト名をソースシステムのホスト名に戻すことができます。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + 仮想プライベートクラウド (VPC) と、仮想プライベートネットワーク (VPN) エンドポイントまたはルーターを備えています。 + AWS Client VPN または は、ソースからターゲットにファイルを転送するように AWS Direct Connect 設定されています。 + ソース環境とターゲット環境の両方にある SAP HANA データベース。ターゲット SAP HANA DB パッチレベルは、同じ SAP HANA プラットフォームエディション内のソース SAP HANA DB パッチレベル以上である必要があります。例えば、HANA 1.0 システムと HANA 2.0 システムの間でレプリケーションを設定することはできません。詳細については、SAP ノート：1999880 — よくある質問：SAP HANA システムレプリケーションの質問 15 を参照してください。 + ターゲット環境の SAP アプリケーションサーバー。 + ターゲット環境の、Amazon Elastic Block Store (Amazon EBS) ボリューム。 **制限事項** 次の SAP ドキュメントリストは、SAP HANA の動的階層化やスケールアウト移行に関する制約など、この回避策に関連する既知の問題について説明しています。 + 2956397 — SAP HANA データベースシステムの名前を変更できませんでした + 2222694 — HANA システムの名前を変更しようとすると、「ソースファイルは元の sidadm ユーザーによって所有されていません (uid = xxxx)」というエラーが表示される + 2607227 — hdblcm： 登録\$1名前変更\$1システム：SAP HANA インスタンスの名前変更に失敗した + 2630562 — HANA ホスト名の名前変更に失敗し、HANA が起動しない + 2935639 — sr\$1register が global.ini セクションの system\$1replication\$1hostname\$1resolution で指定されているホスト名を使用していない + 2710211 — エラー：ソースシステムとターゲットシステムの論理ホスト名が重複している + 2693441 — エラーにより SAP HANA システムの名前を変更できなかった + 2519672 — HANA プライマリとセカンダリのシステム PKI、SSFS データ、キーが異なるか、確認できない + 2457129 — 動的階層化がランドスケープの一部である場合、SAP HANA システムホストの名前変更が許可されない + 2473002 — HANA システムレプリケーションによるスケールアウトシステムの移行 (スケールアウト SAP HANA システムでのこのホスト名変更アプローチの使用には、SAP による制限はありません。 ただし、この手順は個々のホストで繰り返す必要があります。 このアプローチには、他のスケールアウト移行の制限も適用されます。) **製品バージョン** + このソリューションは SAP HANA DB プラットフォームエディション 1.0 と 2.0 に適用されます。 ## アーキテクチャ **ソースセットアップ** SAP HANA データベースがソース環境にインストールされます。すべての SAP アプリケーションサーバー接続と DB インターフェイスは、クライアント接続に同じホスト名を使用します。次の図は、`hdbhost`ソースホスト名とそれに対応する IP アドレスの例を示しています。 ![\[IP アドレス 10.1.2.1 の企業データセンターの SAP HANA DB ソース hdbhost。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/004781c1-96df-43dd-a52e-ed1db5bdf9ef/images/a1b28c3a-93b7-4f82-a5da-81008b74c9ae.png) **ターゲットセットアップ** AWS クラウド ターゲット環境は、同じホスト名を使用して SAP HANA データベースを実行します。AWS のターゲット環境には以下が含まれます。 + SAP HANA データベース + SAP アプリケーションサーバー + EBS ボリューム ![\[IP アドレス 172.16.2.1 の AWS クラウドの SAP HANA DB ターゲット hdbhost。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/004781c1-96df-43dd-a52e-ed1db5bdf9ef/images/7f45d7aa-9b80-4413-bec9-1616492b650c.png) **中間設定** 次の図では、 AWS ソースとターゲットのホスト名が一意`temp-host`になるように、ターゲット環境のホスト名を一時的に に変更しています。移行がターゲット環境上でテイクオーバーマイルストーンを完了すると、ターゲットシステムの仮想ホスト名は元の名前`hdbhost`を使用してリネームされます。 中間設定には、以下のオプションのいずれかが含まれます。 + AWS Client VPN クライアント VPN エンドポイントを使用する + Direct Connect ルーターへの接続 ![\[temp-host IP アドレス 172.31.5.10 の AWS クラウドシステムをターゲットにするソースシステム。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/004781c1-96df-43dd-a52e-ed1db5bdf9ef/images/e2794477-2e8f-4974-bca3-2275f6809fce.png) AWS ターゲット環境の SAP アプリケーションサーバーは、レプリケーションのセットアップ前またはテイクオーバー後にインストールできます。ただし、レプリケーションをセットアップする前にアプリケーションサーバーをインストールしておくと、インストール中のダウンタイムの短縮、高可用性の設定、およびバックアップに役立ちます。 ## ツール **AWS のサービス** + [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html) は、オンプレミスネットワークの AWS リソースとリソースに安全にアクセスできるマネージドクライアントベースの VPN サービスです。 + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) は、標準イーサネット光ファイバケーブルを介して内部ネットワークを Direct Connect ロケーションにリンクします。この接続を使用すると、ネットワークパス内のインターネットサービスプロバイダーをバイパスして AWS のサービス、パブリックに直接仮想インターフェイスを作成できます。 + [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで使用するブロックレベルストレージのボリュームを提供します。EBS ボリュームの動作は、未初期化のブロックデバイスに似ています。これらのボリュームは、デバイスとしてインスタンスにマウントできます。 **その他のツール** + [SAP アプリケーションサーバー](https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/47/a032c0305e0b3ae10000000a42189d/content.htm?no_cache=true) — SAP アプリケーションサーバーは、プログラマーがビジネスロジックを表現する方法を提供します。SAP アプリケーションサーバーは、ビジネスロジックに基づいてデータ処理を実行します。実際のデータは、別のコンポーネントであるデータベースに格納されます。  + 「[SAP HANA コックピット](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/da25cad976064dc0a24a1b0ee9b62525.html)」と「[SAP HANA スタジオ](https://help.sap.com/viewer/a2a49126a5c546a9864aae22c05c3d0e/2.0.00/en-US/c831c3bbbb571014901199718bf7edc5.html)」 — SAP HANA コックピットと SAP HANA Studio はどちらも SAP HANA データベースへの管理インターフェイスを提供します。SAP HANA Studio では、SAP HANA 管理コンソールは SAP HANA データベース管理に関連するコンテンツを提供するシステムビューです。  + [SAP HANA システムレプリケーション](https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.04/en-US) — SAP HANA システムレプリケーション (SAP HSR) は、SAP HANA データベースをレプリケートするために SAP が提供している標準手順です。SAP HSR に必要な実行ファイルは、SAP HANA サーバーカーネル自体に含まれています。 ## エピック ### ソース環境とターゲット環境を準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SAP HANA データベースをインストールして構成します。 | ソース環境とターゲット環境で、SAP HANA DB が SAP HANA のベストプラクティスに従ってインストールおよび構成されていることを確認します。詳細については、[「SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana.pdf)」を参照してください。 | SAP 基本管理 | | IP アドレスをマップします。 | ターゲット環境では、一時的なホスト名が内部 IP アドレスに割り当てられていることを確認します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-sap-hana-to-aws-using-sap-hsr-with-the-same-hostname.html) | AWS 管理 | | ターゲットホスト名を解決します。 | セカンダリ SAP HANA DB で、`/etc/hosts`ファイル内の関連するホスト名を更新して、SAP HANA レプリケーションネットワークのホスト名 (`hdbhost`と`temp-host`) が両方解決されていることを確認します。 | Linux アドミニストレーション | | ソースとターゲットの SAP HANA データベースをバックアップします。 | SAP HANA Studio または SAP HANA コックピットを使用して SAP HANA データベースのバックアップを実行します。 | SAP 基本管理 | | エクスチェンジシステム PKI 証明書。 | (SAP HANA 2.0 以降にのみ適用) プライマリデータベースとセカンダリデータベースの間のファイルシステム (SSFS) ストア内のシステム公開鍵基盤 (PKI) セキュアストア内の証明書を交換します。詳細については、SAP Note 2369981 — SAP HANA システムレプリケーションによる認証に必要な設定手順を参照してください。 | SAP 基本管理 | ### ターゲット SAP HANA データベースの名前を変更します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターゲットクライアント接続を停止します。 | ターゲット環境で SAP アプリケーションサーバーとその他のクライアント接続をシャットダウンします。 | SAP 基本管理 | | ターゲット SAP HANA DB の名前を一時的なホスト名に変更します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-sap-hana-to-aws-using-sap-hsr-with-the-same-hostname.html)SAP HANA DBの停止と開始は`hdblcm`によって制御されます。  | SAP 基本管理 | | レプリケーションネットワークを割り当てる。 | ソースシステムの`global.ini`ファイルの`[system_replication_hostname_resolution]`ヘッダーの下に、ソースとターゲットのレプリケーションネットワークの詳細を指定します。次に、エントリをターゲットシステム上の`global.ini`ファイルにコピーします。 | SAP 基本管理 | | プライマリでのレプリケーションを有効にします。 | 次のコマンドを実行して、ソース SAP HANA DB でレプリケーションを有効にします。 
hdbnsutil -sr_enable --name=siteA
| SAP 基本管理 | | ターゲット SAP HANA データベースをセカンダリシステムとして登録します。 | ターゲット SAP HANA DB を SAP HSR のソースとなるセカンダリシステムとして登録するには、「**非同期**」レプリケーションを選択します。 
(sid)adm $> HDB stop
(sid)adm $> hdbnsutil -sr_register –name=siteB –remotehost=hdbhost /
--remoteInstance=00 –replicationMode=async –operationMode=logreplay
(sid)adm $> HDB start
または、登録する`–online`オプションを選択できます。その場合は、SAP HANA DB を停止して起動する必要はありません。 | SAP 基本管理 | | 同期を検証します。 | ソース SAP HANA DB で、すべてのログがターゲットシステムに適用されていることを確認します (非同期レプリケーションであるため)。レプリケーションを確認するには、ソース上で以下のコマンドを実行します。
(sid)adm $> cdpy
(sidadm $> python systemReplicationStatus.py
| SAP 基本管理 | | ソース SAP アプリケーションと SAP HANA データベースをシャットダウンします。 | 移行カットオーバー中に、ソースシステム (SAP アプリケーションと SAP HANA データベース) をシャットダウンします。 | SAP 基本管理 | | ターゲットでテイクオーバーを実行します。 | AWS 上のターゲットでテイクオーバーを実行するには、コマンド`hdbnsutil -sr_takeover`を実行します。 | SAP 基本管理 | | ターゲット SAP HANA DB で、レプリケーションをオフにします。 | レプリケーションメタデータをクリアするには、コマンド`hdbnsutil -sr_disable`を実行してターゲットシステム上のレプリケーションを停止します。 これは SAP の「Note 2693441 - Failed to rename an SAP HANA System due to error」に準拠しています。 | SAP 基本管理 | | ターゲット SAP HANA データベースをバックアップします。 | テイクオーバーが成功したら、SAP HANA DB の完全バックアップを実行することをお勧めします。 | SAP 基本管理 | ### ターゲットシステムの元のホスト名に戻す。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ターゲットの SAP HANA DB ホスト名を元のホスト名に戻します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-sap-hana-to-aws-using-sap-hsr-with-the-same-hostname.html)必要に応じて、他のオプションを検証できます。ただし、ホスト名の変更と SID の変更を混同しないように注意してください (SAP Note 2598814 — hdblcm： SID の名前変更が失敗する)。 | SAP 基本管理 | | HD ユーザーストアを調整します。 | `hdbuserstore`の詳細をソース`schema/user`の詳細に合わせて調整します。詳細な手順については、[SAP のドキュメント](https://help.sap.com/viewer/b3ee5778bc2e4a089d3299b82ec762a7/2.0.02/en-US/ddbdd66b632d4fe7b3c2e0e6e341e222.html?q=hdbuserstore)を参照してください。 このステップを検証するには、コマンド`R3trans -d`を実行します。結果には SAP HANA データベースへの接続が成功したことが反映されているはずです。 | SAP 基本管理 | | クライアント接続を開始します。 | ターゲット環境で SAP アプリケーションサーバーとその他のクライアント接続を起動します。 | SAP 基本管理 | ## 関連リソース **SAP リファレンス** SAP ドキュメンテーションリファレンスは SAP によって頻繁に更新されます。最新情報を入手するには、SAP Note 2407186 — SAP HANA の高可用性に関するハウツーガイドとホワイトペーパーを参照してください。 追加のSAPメモ + 2550327 — SAP HANA システムの名前を変更する方法 + 1999880 — よくある質問：SAP HANA システムレプリケーション + 2078425 — SAP HANA プラットフォームライフサイクル管理ツール (hdblcm) のトラブルシューティングノート + 2592227 — HANA システムの FQDN サフィックスの変更 + 2048681 — SSH または ルート認証情報なしで、複数のホストシステムで SAP HANA プラットフォームのライフサイクル管理管理タスクを実行する *SAP ドキュメント* + [System Replication Network Connection](https://help.sap.com/docs/SAP_HANA_PLATFORM/4e9b18c116aa42fc84c7dbfd02111aba/47190b425eb1433697b026ecd46ff5f9.html) + [システムレプリケーションのホスト名解決](https://help.sap.com/viewer/eb3777d5495d46c5b2fa773206bbfb46/1.0.12/en-US/c0cba1cb2ba34ec89f45b48b2157ec7b.html) **AWS リファレンス** + [SAP HANA を他のプラットフォームから に移行する AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/migrating-hana-hana-to-aws.html) ## 追加情報 ホスト名のリネーム活動の一部として`hdblcm`によって実行された変更は、以下の詳細ログに集約されます。 ![\[プロセスが temp-host で停止し、hdbhost で開始され、SAP HANA DB システムの名前が変更されたことを示すコード。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/004781c1-96df-43dd-a52e-ed1db5bdf9ef/images/9e0c11ca-6555-484f-9639-107f60f725f5.png) # を使用して Microsoft SQL Server Always On 可用性グループを移行する AWS Application Migration Service *Amazon Web Services、Sreenivas Nettem、Bharath Kumar Pammi Ramesh、Anantharaman Seshadri、Gireesh Sreekantan* ## 概要 AWS Application Migration Service (AWS MGN) は、 の既存の環境をリホストするための推奨ツールです。これにより AWS クラウド、お客様はオンプレミスのデータセンターから離れることができます。このパターンは、MGN AWS を使用して Microsoft SQL Server Always On 可用性グループで Windows クラスターを移行するプロセスの概要を示しています。 ## 前提条件と制限 **前提条件** + アクティブ AWS アカウント。 + MGN オーケストレーションの AWS Identity and Access Management (IAM) AWS ロール。 + ソースデータベースサーバー (SQL Server Always On 可用性グループ) へのアクセス権。 + DNS 名を保持する AWS ランディングゾーンの Active Directory。 + Active Directory へのネットワーク通信を遮断したステージングサブネット。 + Active Directory と通信できるターゲットサブネット。 + ターゲットサブネット内の Windows クラスター用の予約済み IP アドレス 2 個 (各アベイラビリティーゾーンに 1 個)。 + ターゲットサブネット内の SQL Always On リスナー用の予約済み IP アドレス 2 個 (各アベイラビリティーゾーンに 1 個)。 **製品バージョン** + Windows Server 2012 以降 + SQL Server 2012 以降 ## アーキテクチャ **ソーステクノロジースタック** Microsoft Windows クラスター (オンプレミスの物理マシンまたは仮想マシン) および Microsoft SQL Server Always On 可用性グループ **ターゲットテクノロジースタック** Amazon EC2 Windows インスタンス **ターゲットアーキテクチャ** ![\[AWS MGN を使用して SQL Server Always On 可用性を移行するための AWS アーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/aa94040b-5ecf-42f9-90e3-929d0fa5e715/images/0b85c613-51df-475b-9598-3da3f9cd47c6.png) ## ツール *AWS のサービス* + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) は、アプリケーションを に変更 AWS クラウド なしで最小限のダウンタイムでリホスト (リフトアンドシフト) するのに役立ちます。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 *その他のツール* + [Microsoft SQL Server Management Studio (SSMS)](https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms) は、SQL Server コンポーネントへのアクセス、設定、管理など、SQL Server を管理するためのツールです。 ## ベストプラクティス MGN については、 AWS [「 のベストプラクティス AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/best_practices_mgn.html)」を参照してください。 ## エピック ### ターゲットアカウントを準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MGN AWS を初期化します。 | ターゲットで AWS MGN を初期化します AWS リージョン。これにより、必要な IAM ロールとポリシーが作成されます。詳しくは「[コンソールでアプリケーション移行サービスを初期化する](https://docs.aws.amazon.com/mgn/latest/ug/mgn-initialize-console.html)」を参照してください。 | クラウド管理者 | | レプリケーションテンプレートと起動テンプレートを作成します。 | MGN AWS で使用するレプリケーションテンプレートと起動テンプレートを設定します。詳細については、 AWS ドキュメント[の「 テンプレートの設定](https://docs.aws.amazon.com/mgn/latest/ug/mgn-initialization-templates.html)」を参照してください。 | クラウド管理者 | | 通信ポートを許可します。 | MGN AWS のネットワーク通信を有効にするには、TCP ポート 443 および 1500 経由のトラフィックを許可します。詳細については、 AWS ドキュメントの[「Application Migration Service のネットワーク要件](https://docs.aws.amazon.com/mgn/latest/ug/Network-Requirements.html)」を参照してください。 | クラウド管理者、ネットワーク管理者 | ### ソースサーバーを準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MGN AWS の前提条件を確認します。 | ソースサーバーが AWS MGN エージェントのインストールの前提条件を満たしていることを確認します。詳細については、 AWS ドキュメントの[「インストール要件](https://docs.aws.amazon.com/mgn/latest/ug/installation-requirements.html)」を参照してください。 | 移行エンジニア | | MGN エージェントをインストール AWS します。 | AWS MGN エージェントをソースサーバーにインストールします。インストール中に、サーバーを移行 AWS リージョン する を選択します。インストール後、エージェントはサービスと通信してレプリケーションを開始します。詳細については、[「Windows サーバーへの AWS レプリケーションエージェントの](https://docs.aws.amazon.com/mgn/latest/ug/windows-agent.html)インストール」を参照してください。 | 移行エンジニア | | ソースサーバーのステータスを確認します。 | AWS MGN コンソールで、ソースサーバーのステータスを確認します。レプリケーションが開始すると、サーバーに **[テスト準備完了]** の表示が出ます。エラーが発生した場合は、MGN AWS ドキュメントの[「通信エラーのトラブルシューティング](https://docs.aws.amazon.com/mgn/latest/ug/Troubleshooting-Communication-Errors.html)」を参照してください。 | クラウド管理者、移行エンジニア | | レプリケーション設定を最適化します。 | SQL Always On クラスターは、プライマリサーバーからセカンダリサーバーへの高 I/O 同期レプリケーションを使用します。レプリケーションを最適化し、停止時間を低減するには、SQL Always On サーバーごとに[専用のレプリケーションサーバー](https://docs.aws.amazon.com/mgn/latest/ug/replication-settings-template.html)を使用します。データベースが 5 TB を超える場合は、デフォルトの **t3.small** ではなく **m5.large** など、より大きなインスタンスサイズのレプリケーションサーバーを使用することを検討してください。 | クラウド管理者、移行エンジニア | | 起動テンプレートを更新します。 | [[起動設定]](https://docs.aws.amazon.com/mgn/latest/ug/launch-settings.html) を更新し、SQL Always On サーバーのサブネットを選択します。SQL Always On クラスターサーバーは、高可用性 AWS アベイラビリティーゾーン のために異なる に分散されます。 | 移行エンジニア、移行リード | | 起動設定を更新します。 | サイズとパフォーマンス要件に基づいて、[起動設定] でインスタンスタイプと 1 秒あたりの入出力オペレーション (IOPS) を更新します。(オプション) [起動設定] で既存の Elastic Network Interface を選択します。 | 移行エンジニア、移行リード | ### カットオーバーをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ソースサーバーを確認します。 | AWS MGN コンソールで、ソースサーバーのステータスが**テスト準備完了**であることを確認します。 | クラウド管理者、移行エンジニア | | テストインスタンスを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-microsoft-sql-server-always-on-group-using-mgn.html) | クラウド管理者、移行エンジニア | | 接続とデータベースの整合性をテストします。 | テストインスタンスの接続とデータベースの整合性をテストします。次に、MGN AWS コンソールでソースサーバーを**カットオーバー準備完了**としてマークします。 | クラウド管理者、移行エンジニア | ### 移行前タスク | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースの整合性をテストします。 | テストを実施することで、ソースのデータベースに整合性の問題がないことを、移行前に確認できます。`DBCC CHECKDB` を実行して `WITH_PHYSICAL_ONLY` を指定します。このチェックを `WITH_PHYSICAL_ONLY` なしで実行すると、ソースのパフォーマンスに問題が生じる場合があります。データベースの整合性を維持するために、週次でデータベースのフルチェックを実行してください。これらのコマンドは、潜在的な破損を検出し、データベースの論理的および物理的な整合性をチェックします。ページ、行、インデックス、システムテーブルなどのデータベースの構造を検証します。 | データエンジニア、DBA | | リンクされたサーバーへの接続をテストします。 | 既存のすべてのサーバー間の接続をテストし、そのステータスを文書化します。これにより、リンク済みのサーバーが移行後も期待どおりに動作することを確認できます。 | データエンジニア、DBA | | バックアップを確認します。 | ソースバックアップの整合性を確認します。 | データエンジニア、DBA | ### AWS MGN カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SQL Server とクラスターサービスを停止します。 | すべての SQL クラスターノードで SQL Server および Microsoft クラスターサービスを停止します。 | DBA、移行エンジニア | | サーバーを確認します。 | AWS MGN コンソールで、ソースサーバーのステータスが**カットオーバー準備完了**であり、データレプリケーションのステータスが**正常**であることを確認します。 | 移行エンジニア | | カットオーバーを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-microsoft-sql-server-always-on-group-using-mgn.html)詳細については、MGN AWS ドキュメント[の「カットオーバーインスタンスの起動](https://docs.aws.amazon.com/mgn/latest/ug/launch-cutover-gs.html)」を参照してください。 | 移行エンジニア | | 起動したサーバーをテストします。 | 起動した Amazon EC2 インスタンスにログインし、クラスターの状態を検証します。サーバーが正しいサブネットにあり、インスタンスサイズと IOPS 設定が正しく、監視サーバーにアクセスできることを確認します。 | DBA、移行エンジニア | ### データベースカットオーバー後のタスク | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスター IP アドレスを更新します。 | ターゲットサブネット内に用意しておいた 2 つの IP アドレスを使用して、Windows クラスターのクラスター IP アドレスを更新してください。詳しくは「[フェイルオーバークラスターインスタンスの IP アドレスの変更](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/change-the-ip-address-of-a-failover-cluster-instance?view=sql-server-2016)」を参照してください。 | DBA、移行エンジニア | | Always On 可用性グループのリスナー IP を更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-microsoft-sql-server-always-on-group-using-mgn.html) | DBA、移行エンジニア | | 接続を確認します。 | SSMS を使用して Always On 可用性グループリスナーに接続し、接続が成功していることを確認します。 | DBA、移行エンジニア | | Always On 可用性グループの正常性を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-microsoft-sql-server-always-on-group-using-mgn.html) | DBA、移行エンジニア | | エラーログを確認します。 | エラーログを開き、SQL Server インスタンスにエラー報告がないかどうかを確認してください。すべてのデータベースが復旧済みであることを確認します。 | DBA、移行エンジニア | | リンクされたサーバーをテストします。 | リンクされたサーバーの接続をテストします。接続に問題がある場合は、ターゲットサーバーとポートにアクセスできることを確認してください。 | DBA、移行エンジニア | ### カットオーバーを確定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | カットオーバーを確定します。 | ターゲット SQL Always On クラスターを検証したら、MGN AWS コンソールを使用してカットオーバー[を確定](https://docs.aws.amazon.com/mgn/latest/ug/launch-cutover-gs.html#revert-finalize-cutover-gs)します。これにより、ソースサーバーからのデータレプリケーションが停止し、レプリケーションサーバーからデータが破棄されます。また、レプリケーションサーバーと関連するリソースも削除されます。 | クラウド管理者、移行エンジニア | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | AWS MGN のトラブルシューティング | 一般的な問題と解決策については、MGN ドキュメントの[「トラブルシューティング](https://docs.aws.amazon.com/mgn/latest/ug/troubleshooting.html)と[よくある質問](https://docs.aws.amazon.com/mgn/latest/ug/FAQ.html) AWS 」セクションを参照してください。 | ## 関連リソース *AWS リソース* + [Option-1 リホスト - AWS Application Migration Service (AWS)](https://catalog.us-east-1.prod.workshops.aws/workshops/c6bdf8dc-d2b2-4dbd-b673-90836e954745/en-US/04-application-migration/01-mgn) + [とは AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) *SQL Server リソース* + [SQL Server Management Studio (SSMS) とは](https://learn.microsoft.com/en-us/ssms/sql-server-management-studio-ssms) ## 追加情報 ワークロードを に移行するための標準セキュリティ要件については AWS クラウド、 AWS ウェブサイトの[「セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス](https://aws.amazon.com/architecture/security-identity-compliance/)」を参照してください。 # 分散可用性グループを使用して SQL Server を AWS に移行する *Amazon Web Services、Praveen Marthala* ## 概要 Microsoft SQL Server Always On 可用性グループは、SQL Server に高可用性 (HA) およびディザスタリカバリ (DR) ソリューションを提供します。可用性グループは、読み取り/書き込みトラフィックを受け入れるプライマリレプリカと、読み取りトラフィックを受け入れる最大 8 つのセカンダリレプリカで構成されます。可用性グループは 2 つ以上のノードで構成される Windows Server フェールオーバークラスター (WSFC) 上に構成されます。 Microsoft SQL Server Always On 分散可用性グループは、2 つの独立した WFSC 間で 2 つの別々の可用性グループを構成するソリューションを提供します。分散可用性グループに含まれる可用性グループは、同じデータセンター内にある必要はありません。1 つの可用性グループをオンプレミスに配置し、もう 1 つの可用性グループを別のドメインの Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上の Amazon Web Services (AWS) クラウドに配置できます。  このパターンは、分散可用性グループを使用して、既存の可用性グループの一部であるオンプレミスの SQL Server データベースを、Amazon EC2 に可用性グループが設定された SQL Server に移行する手順の概要を示しています。このパターンに従うことで、カットオーバー中のダウンタイムを最小限に抑えながら、データベースを AWS クラウドに移行できます。データベースは、カットオーバー直後から AWS で高い可用性を発揮します。このパターンを使用して、同じバージョンの SQL Server を維持したまま、基盤となるオペレーティングシステムをオンプレミスから AWS に変更することもできます。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + AWS Direct Connect または AWS Site-to-Site VPN + オンプレミスと AWS の 2 つのノードに同じバージョンの SQL Server がインストールされている **製品バージョン** + SQL Server バージョン 2016 以降) + SQL Server Enterprise Edition ## アーキテクチャ **ソーステクノロジースタック** + オンプレミスで Always On 可用性グループを使用する Microsoft SQL Server データベース **ターゲットテクノロジースタック** + AWS クラウド上の Amazon EC2 にある Always On アベイラビリティグループを備えた Microsoft SQL Server データベース **移行アーキテクチャ** ![\[オンプレミスと AWS の可用性グループで同期レプリケーションを使用する SQL Server。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6e229e30-9b11-4ccb-bccd-cbe6601139c0/images/79ee7911-d68f-4db7-9b94-113dcf09c28b.png) 用語 + WSFC 1 — オンプレミスの WSFC + WSFC 2 — AWS クラウド上の WSFC + AG 1 — WSFC 1 にある最初のアベイラビリティグループ + AG 2 — WSFC 2 にある 2 番目のアベイラビリティグループ + SQL Server プライマリレプリカ — AG 1 のノードで、すべての書き込みのグローバルプライマリと見なされます。 + SQL Server フォワーダー — SQL Server プライマリレプリカからデータを非同期で受信する AG 2 のノード + SQL Server セカンダリレプリカ — プライマリレプリカまたはフォワーダーからデータを同期的に受信する AG 1 または AG 2 のノード ## ツール + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html), ―標準イーサネット光ファイバケーブルを介して、内部ネットワークを AWS Direct Connect ロケーションにリンクします。この接続を使用すると、パブリック AWS サービスに*仮想インターフェイス*を直接作成できるため、ネットワークパスのインターネットサービスプロバイダーを回避できます。 + 「[Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/concepts.html)」— Amazon Elastic Compute Cloud (Amazon EC2) は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。Amazon EC2 を使用して必要な分だけ仮想サーバーを起動し、スケールアウトまたはスケールインできます。 + [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) — AWS Site-to-Site VPN は、Site-to-Site 仮想プライベートネットワークの作成をサポートします。AWS で起動するインスタンスと独自のリモートネットワーク間でトラフィックを渡すように VPN を設定できます。 + [マイクロソフトSQLサーバー管理スタジオ](https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms?view=sql-server-ver15) — マイクロソフトSQLサーバー管理スタジオ(SSMS) は、SQL Server インフラストラクチャを管理するための統合環境です。SQL Server とやり取りする豊富なスクリプトエディターを備えたユーザーインターフェイスとツールグループを備えています。 ## エピック ### AWS に 2 つ目のアベイラビリティグループを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS に WSFC を作成します。 | HA 用に 2 つのノードを備えた Amazon EC2 インスタンスに WSFC 2 を作成します。このフェールオーバークラスターを使用して、AWS に 2 つ目の可用性グループ (AG 2) を作成します。 | システム管理者、システム運用管理者 | | WSFC 2 に 2 つ目の可用性グループを作成します。 | SSMS を使用して、WSFC 2 の 2 つのノードに AG 2 を作成します。WSFC 2 の最初のノードがフォワーダーとして機能します。WSFC 2 の 2 番目のノードは AG 2 のセカンダリレプリカとして機能します。この段階では、AG 2 にはデータベースはありません。これが分散可用性グループの設定の出発点です。 | DBA、開発者 | | AG 2 で復旧オプションなしでデータベースを作成します。 | オンプレミス可用性グループ (AG 1) のデータベースをバックアップします。 復旧オプションなしで、AG 2 のフォワーダーとセカンダリレプリカの両方にデータベースを復元します。データベースを復元するときは、データベースデータファイルとログファイルを保存するのに十分なディスク容量がある場所を指定します。この段階では、データベースは復元中の状態です。これらは AG 2 または分散可用性グループには含まれておらず、同期も行われていません。 | DBA、開発者 | ### 分散可用性グループの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AG 1 に分散可用性グループを作成します。 | AG 1 に分散可用性グループを作成するには、`DISTRIBUTED`オプションを指定して`CREATE AVAILABILITY GROUP`を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-sql-server-to-aws-using-distributed-availability-groups.html) | DBA、開発者 | | AG 2 に分散可用性グループを作成します。 | AG 2 に分散可用性グループを作成するには、`DISTRIBUTED`オプションを指定して`ALTER AVAILABILITY GROUP`を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-sql-server-to-aws-using-distributed-availability-groups.html)分散可用性グループは AG 1 と AG 2 の間に作成されます。AG 2 のデータベースは、AG 1 から AG 2 へのデータフローに参加するようにまだ設定されていません。 | DBA、開発者 | | AG 2 のフォワーダーとセカンダリレプリカにデータベースを追加します。 | AG 2 のフォワーダーとセカンダリレプリカの両方で`SET HADR``AVAILABILITY GROUP`オプションを指定して`ALTER DATABASE`を使用して、データベースを分散可用性グループに追加します。 これにより、AG 1 と AG 2 のデータベース間の非同期データフローが開始されます。 グローバルプライマリは書き込みを行い、AG 1 のセカンダリレプリカにデータを同期的に送信し、AG 2 のフォワーダーにデータを非同期で送信します。AG 2 のフォワーダーは、AG 2 のセカンダリレプリカに同期的にデータを送信します。 | DBA、開発者 | ### AG 1 と AG 2 間の非同期データフローを監視します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DMV と SQL サーバーログを使用します。 | 動的管理ビュー (DMV) と SQL Server ログを使用して、2 つの可用性グループ間のデータフローの状態を監視します。 監視の対象となる DMV には、`sys.dm_hadr_availability_replica_states`と`sys.dm_hadr_automatic_seeding`があります。フォワーダー同期の状態については、フォワーダーの SQL Server ログで「*同期状態*」を監視します。 | DBA、開発者 | ### 最終移行のためのカットオーバーアクティビティを実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライマリレプリカへのすべてのトラフィックを停止します。 | AG 1 のプライマリレプリカへの受信トラフィックを停止して、データベースへの書き込みアクティビティが発生せず、データベースを移行できる状態にします。 | アプリ所有者、開発者 | | AG 1 の分散可用性グループの可用性モードを変更します。 | プライマリレプリカで、分散可用性グループのアベイラビリティモードを同期に設定します。 アベイラビリティモードを同期に変更すると、データは AG 1 のプライマリレプリカから AG 2 のフォワーダーに同期的に送信されます。 | DBA、開発者 | | 両方の可用性グループの LSN を確認します。 | AG 1 と AG 2 の両方の最新のログシーケンス番号 (LSN) を確認します。AG 1 のプライマリレプリカでは書き込みが行われていないため、データは同期されており、両方の可用性グループの最後の LSN は一致しているはずです。 | DBA、開発者 | | AG 1 をセカンダリロールに更新します。 | AG 1 をセカンダリロールに更新すると、AG 1 はプライマリレプリカのロールを失い、書き込みを受け付けなくなり、2 つの可用性グループ間のデータフローが停止します。 | DBA、開発者 | ### 2 番目の可用性グループへのフェイルオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AG 2 に手動でフェールオーバーします。 | AG 2 のフォワーダーで、データが失われないように分散可用性グループを変更します。AG 1 と AG 2 の最後の LSN が一致することは既に確認済みなので、データ損失は問題になりません。AG 2 のフォワーダでのデータ損失を許可すると、AG 1 と AG 2 の役割が変わります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-sql-server-to-aws-using-distributed-availability-groups.html) | DBA、開発者 | | AG 2 の分散可用性グループの可用性モードを変更します。 | AG 2 のプライマリレプリカで、アベイラビリティモードを非同期に変更します。これにより、AG 2 から AG 1 へのデータ移動が、同期から非同期に変更されます。このステップは、AG 2 と AG 1 の間でネットワーク遅延が発生してもそれを回避するために必要であり、データベースのパフォーマンスには影響しません。 | DBA、開発者 | | 新しいプライマリレプリカへのトラフィックの送信を開始します。 | AG 2 のリスナー URL エンドポイントを使用してデータベースにトラフィックを送信するように接続文字列を更新します。AG 2 は、AG 2 の独自のセカンダリレプリカにデータを送信するとともに、書き込みを受け付けて AG 1 のフォワーダーにデータを送信するようになりました。データは AG 2 から AG 1 に非同期的に移動します。 | アプリ所有者、開発者 | ### カットオーバー後のアクティビティの実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 分散可用性グループを AG 2 にドロップします。 | 予定された時間だけ移行を監視します。次に、AG 2 に分散可用性グループをドロップして、AG 2 と AG 1 の間の分散可用性グループの設定を削除します。これにより、分散可用性グループの設定が削除され、AG 2 から AG 1 へのデータフローが停止します。 この時点で、AG 2 は AWS での可用性が高く、プライマリレプリカは書き込みを行い、セカンダリレプリカは同じ可用性グループ内にあります。 | DBA、開発者 | | オンプレミスサーバーを廃止します。 | AG 1 の一部である WSFC 1 のオンプレミスサーバーの使用を停止します。 | システム管理者、システム運用管理者 | ## 関連リソース + [分散可用性グループ](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/distributed-groups.html) + [SQL Docs： 分散可用性グループ](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups?view=sql-server-ver15) + [SQL Docs： Always On 可用性グループ：高可用性と災害復旧のためのソリューション](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver15) # でリレーショナルデータベースを MongoDB Atlas に移行する AWS *Battulga Purevragchaa、Igor Alekseev (Amazon Web Services)* *Babu Srinivasan (MongoDB)* ## 概要 このパターンでは、SQL Server、MySQL、PostgreSQL などのリレーショナルデータベースから AWS クラウドの MongoDB Atlas に移行する手順について説明します。[MongoDB Relational Migrator](https://www.mongodb.com/products/relational-migrator) を使用することで、リレーショナルデータベースから MongoDB Atlas へのデータ移行を迅速に行うことができます。 このパターンは、 AWS 「 規範ガイダンス」ウェブサイトの[「 での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/)」ガイドに付属しています。ここでは、そのガイドで説明されている移行シナリオの 1 つの実装手順について説明します。その他の移行シナリオについては、 AWS 「 規範ガイダンス」ウェブサイトの以下のパターンを参照してください。 + [でセルフホスト MongoDB 環境を MongoDB Atlas に移行する AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-a-self-hosted-mongodb-environment-to-mongodb-atlas-on-the-aws-cloud.html) + [IBM Db2、SAP、Sybase、およびその他のデータベースから の MongoDB Atlas にデータをストリーミングする AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/stream-data-from-ibm-db2-to-mongodb-atlas.html) このパターン は、[AWS System Integrator (SI) パートナー](https://aws.amazon.com/managed-services/partners/)と AWS ユーザーを対象としています。 ## 前提条件と制限 **前提条件** + MongoDB Atlas に移行するソースリレーショナルデータベース (Oracle Database、SQL Server、PostgreSQL、MySQL、SAP/Sybase ASE など)。 + リレーショナルデータベース、MongoDB Atlas、および に精通していること AWS のサービス。このパターンでは、移行ステップの一部を大まかに説明します。今後のバージョン更新で詳細が追加される予定です。 **製品バージョン** + MongoDB バージョン 5.0 以降 ## アーキテクチャ 次の図は、リレーショナルデータベース管理システム (RDBMS) データベースから AWSの MongoDB Atlas への移行を示しています。 ![\[RDBMS から AWS 上の MongoDB Atlas に移行するためのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4e3ea0f1-21e8-4641-a9ee-732355f20baf/images/8eacf3ec-f480-4912-9002-6a50800fe9bf.png) さまざまな使用シナリオをサポートする MongoDB Atlas リファレンスアーキテクチャについては、 AWS 「 規範ガイダンス」ウェブサイトの[「 での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/architecture.html)」を参照してください。 ## ツール + [MongoDB Atlas](https://www.mongodb.com/atlas) は、MongoDB データベースをクラウドにデプロイおよび管理するためのフルマネージド型 Database as a Service (DBaaS) です。 + [MongoDB Relational Migrator](https://www.mongodb.com/products/relational-migrator) は、従来のリレーショナルデータベースから MongoDB へのデータのスムーズな移行を実現します。これにより、変換プロセスを自動化し、リレーショナルデータベースの構造化データモデルを MongoDB が提供する柔軟なドキュメント形式に変換できます。Relational Migrator は、データの整合性と関係性を維持し、移行を簡素化します。組織は、既存のデータ知識を維持しつつ、MongoDB が提供するスケーラビリティ、パフォーマンス、汎用性を活用することが可能になります。 ## ベストプラクティス で MongoDB を使用するためのベストプラクティスについては AWS、 [AWS パートナーネットワークブログ](https://aws.amazon.com/blogs/apn/tag/mongodb-atlas/)の投稿を参照してください。 ## エピック ### 発見と評価 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リレーショナルデータベースのパラメータとサイズを決定します。 | Relational Migrator からの推奨値と `db.stats()` からの合計インデックススペースに関する情報を使用し、ワーキングセットのサイズを見積もります。データスペースの一部が頻繁にアクセスされると仮定します。このタスクには約 1 週間かかりそうです。この記事とこのエピックの他のストーリーの詳細と例については、「[関連リソース](#migrate-relational-database-to-mongodb-atlas-resources)」セクションをご確認ください。 | アプリ所有者、DBA | | ネットワーク帯域幅要件を見積もります。 | ネットワーク帯域幅要件を見積もるには、平均ドキュメントサイズに 1 秒あたりに提供されるドキュメント数を掛けます。基準として、クラスター上のノードが負担する最大トラフィックを考慮に入れます。クラスターからクライアントアプリケーションへのダウンストリームのデータ転送速度を計算するには、一定期間に返されたドキュメントの合計を使用します。アプリケーションがセカンダリノードから読み取る場合は、このドキュメントの合計数を、読み取り操作を実行できるノード数で割ります。データベースの平均ドキュメントサイズを求めるには、`db.stats().avgObjSize` コマンドを使用してください。このタスクには通常 1 日かかります。 | DBA | | Atlas 層を選択します。 | [MongoDB ドキュメント](https://www.mongodb.com/docs/atlas/sizing-tier-selection/)の指示に従い、正しい Atlas クラスター階層を選択してください。 | DBA | | カットオーバーを計画します。 | アプリケーションのカットオーバーを計画します。 | DBA、アプリ所有者 | ### で新しい MongoDB Atlas 環境を設定する AWS | タスク | 説明 | 必要なスキル | | --- | --- | --- | | で新しい MongoDB Atlas クラスターを作成します AWS。 | MongoDB Atlas で、**[クラスターの構築]** を選択します。**新しいクラスターの作成**ダイアログボックスで、クラウドプロバイダー AWS として を選択します。 | DBA | | AWS リージョン および グローバルクラスター設定を選択します。 | Atlas クラスター AWS リージョン で使用できる のリストから を選択します。必要に応じてグローバルクラスタを設定します。 | DBA | | クラスター階層を選択します。 | お好みのクラスター階層を選択します。階層の選択によって、メモリ、ストレージ、IOPS の仕様などの要素が決まります。 | DBA | | 追加のクラスター設定を構成します。 | MongoDB のバージョン、バックアップ、暗号化オプションなどのクラスター設定を追加して行います。これらのオプションの詳細については、「[関連リソース](#migrate-relational-database-to-mongodb-atlas-resources)」セクションを参照してください。 | DBA | ### セキュリティとコンプライアンスを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アクセスリストを設定します。 | Atlas クラスターに接続するには、プロジェクトのアクセスリストにエントリを追加する必要があります。Atlas は、TLS/SSL を使用することで、データベースの仮想プライベートクラウド (VPC) への接続を暗号化します。プロジェクトのアクセスリスト設定やこのエピックのストーリー詳細については、「[関連リソース](#migrate-relational-database-to-mongodb-atlas-resources)」セクションを参照してください。 | DBA | | ユーザーの認証と認可を行います。 | MongoDB Atlas クラスターにアクセスするデータベースユーザーを作成して認証する必要があります。プロジェクト内のクラスターにアクセスするには、ユーザーはそのプロジェクトに所属している必要があり、複数のプロジェクトに属していてもいいです。 | DBA | | カスタムロールを作成します。 | (オプション) Atlas では、必要な権限セットが組み込み型 Atlas データベースのユーザー権限ではカバーできない場合に、カスタムロールの作成をサポートしています。 | DBA | | VPC ピアリングを設定します。 | (オプション) Atlas は、 上の他の [VPC との VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)をサポートしています AWS。 VPCs | AWS 管理者 | | AWS PrivateLink エンドポイントをセットアップします。 | (オプション) AWS を使用して でプライベートエンドポイントを設定できます AWS PrivateLink。詳細については、[Amazon VPC のドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)参照してください。 | AWS 管理者 | | 2 要素認証を有効にします。 | (オプション) Atlasは、ユーザーがAtlasアカウントへのアクセスを制御できるようにする 2 要素認証 (2FA) をサポートしています。 | AWS 管理者 | | LDAP によるユーザー認証と認可を設定します。 | (オプション) Atlasは、Lightweight Directory Access Protocol (LDAP) によるユーザー認証および認可の実行をサポートします。 | DBA | | 統合 AWS アクセスを設定します。 | (オプション) Atlas Data Lake やカスタマーキー管理を使用した保管時の暗号化など、一部の Atlas 機能は、認証に AWS Identity and Access Management (IAM) ロールを使用します。 | AWS 管理者 | | を使用して保管時の暗号化を設定します AWS KMS。 | (オプション) Atlas は、 AWS Key Management Service (AWS KMS) を使用してストレージエンジンとクラウドプロバイダーのバックアップを暗号化することをサポートしています。 | AWS 管理者 | | クライアント側のフィールドレベルの暗号化を設定します。 | (オプション) Atlas は、フィールドの自動暗号化を含む、クライアント側のフィールドレベルの暗号化をサポートします。 | AWS 管理者 | ### データを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MongoDB Relational Migrator をアクセスリストに追加します。 | Relational Migrator をソースデータベースのアクセスリストに追加します。これにより、ソース環境がターゲットの Atlas クラスターに接続する準備に役立ちます。 | DBA | | リレーショナルデータベースオブジェクトを評価します。 | MongoDB Relational Migrator を起動し、リレーショナルデータベースに接続します。評価を開始します。 | DBA | | 移行パターンを受け入れるか、ビジネス要件に基づいて変更します。 | 初期評価とパフォーマンスパラメータに基づいて Relational Migrator が推奨するデータベースのパターンを受け入れるか、ビジネス要件に基づき変更を加えます。 | DBA | | MongoDB Atlas でターゲットのレプリカセットを起動します。 | MongoDB Atlas でターゲットのレプリカセットを起動します。Relational Migrator で **[移行準備完了]** を選択します。 | DBA | ### 操作統合の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MongoDB Atlas クラスターに接続します。 | MongoDB Atlas クラスター接続が意図したとおりに動作することを確認します。 | アプリ所有者 | | クラスターデータと対話します。 | クラスターデータを確認します。 | DBA | | クラスターをモニタリングします。 | クラスターが正しく設定されていることを確認します。 | DBA | | クラスターデータをバックアップし、復元します。 | クラスターデータのバックアップを定期的にスケジュールします。 | DBA | ## 関連リソース 特に明記されていない限り、以下のリンクはすべて MongoDB ドキュメントのウェブページに移動します。 **移行ガイド** + [での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/) (AWS 規範ガイダンス) 発見と評価 + 「[メモリ](https://docs.atlas.mongodb.com/sizing-tier-selection/#memory)」 + 「[Atlas サンプルデータセットによるサイジングの例](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#example--the-service-sample-data-sets)」 + 「[モバイルアプリケーションのサイジング例](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#example--mobile-app)」 + 「[ネットワークトラフィック](https://docs.atlas.mongodb.com/sizing-tier-selection/#network-traffic)」 + 「[クラスターの自動スケーリング](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#cluster-auto-scaling)」 + 「[Atlas サイジングテンプレート](https://view.highspot.com/viewer/5f438f47a4dfa042e97130c5)」 セキュリティとコンプライアンスの設定 + 「[IP アクセスリストエントリの設定](https://docs.atlas.mongodb.com/security/ip-access-list/)」 + [データベースユーザーの設定](https://docs.atlas.mongodb.com/security-add-mongodb-users/) + [Atlas UI へのアクセスの設定](https://docs.atlas.mongodb.com/organizations-projects/) + [カスタムデータベースロールの設定](https://docs.atlas.mongodb.com/security-add-mongodb-roles) + [データベースユーザーの設定](https://docs.atlas.mongodb.com/security-add-mongodb-users/#atlas-user-privileges) + 「[ネットワークピアリング接続の設定](https://docs.atlas.mongodb.com/security-vpc-peering/)」 + [Atlas のプライベートエンドポイントについて学ぶ](https://docs.atlas.mongodb.com/security-private-endpoint/) + [多要素認証オプションの管理](https://docs.atlas.mongodb.com/security-two-factor-authentication/) + 「[LDAP によるユーザー認証と認可の設定](https://docs.atlas.mongodb.com/security-ldaps/)」 + 「[Atlas データレイク](https://docs.mongodb.com/datalake/)」 + 「[顧客キー管理による静的暗号化](https://docs.atlas.mongodb.com/security-kms-encryption/)」 + [ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) (IAM ドキュメント) + 「[クライアント側のフィールドレベルの暗号化の設定](https://docs.mongodb.com/manual/core/security-client-side-encryption)」 + [自動暗号化](https://docs.mongodb.com/manual/core/security-automatic-client-side-encryption)  + [MongoDB Atlas のセキュリティコントロール](https://webassets.mongodb.com/_com_assets/cms/MongoDB_Atlas_Security_Controls-v7k3rbhi3p.pdf) + [MongoDB トラストセンター](https://www.mongodb.com/cloud/trust) + [クラスターのセキュリティ機能の設定](https://docs.atlas.mongodb.com/setup-cluster-security/) **AWS** **上に新しい MongoDB Atlas 環境を設定する** + 「[クラウドプロバイダーとリージョン](https://docs.atlas.mongodb.com/cloud-providers-regions/)」 + [グローバルクラスターの管理](https://docs.atlas.mongodb.com/global-clusters/) + [クラスター階層の選択](https://www.mongodb.com/docs/atlas/manage-clusters/#select-cluster-tier) + [追加の設定](https://docs.atlas.mongodb.com/cluster-additional-settings/) + [Atlas の使用開始](https://docs.atlas.mongodb.com/getting-started/) + [Atlas UI へのアクセスの設定](https://docs.atlas.mongodb.com/organizations-projects/) **データを移行する** + [データを移行またはインポートする](https://www.mongodb.com/docs/atlas/import/) **クラスターのモニタリング** + [クラスターをモニタリングする](https://docs.atlas.mongodb.com/monitoring-alerts/) オペレーションの統合 + 「[クラスターへの接続](https://docs.atlas.mongodb.com/connect-to-cluster/)」 + [データを操作する](https://docs.atlas.mongodb.com/data-explorer/) + [クラスターをモニタリングする](https://docs.atlas.mongodb.com/monitoring-alerts/) + [データのバックアップ、復元、アーカイブ](https://docs.atlas.mongodb.com/backup-restore-cluster/) # でセルフホスト MongoDB 環境を MongoDB Atlas に移行する AWS *Battulga Purevragchaa、Igor Alekseev (Amazon Web Services)* *Babu Srinivasan (MongoDB)* ## 概要 このパターンでは、セルフマネージド MongoDB 環境 (MongoDB Community Server、Enterprise Server、Enterprise Advanced、mLab、または任意のマネージド MongoDB クラスターを含む) から AWS クラウド上の MongoDB Atlas に移行するためのステップについて説明します。「[Atlas ライブマイグレーションサービス](https://www.mongodb.com/cloud/atlas/migrate)」を使用して、MongoDB から MongoDB Atlas へのデータ移行を加速します。 このパターンは、 AWS 「 規範ガイダンス」ウェブサイトの[「 での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/)」ガイドに付属しています。ここでは、そのガイドで説明されている移行シナリオの 1 つの実装手順について説明します。その他の移行シナリオについては、 AWS 「 規範ガイダンス」ウェブサイトの次のパターンを参照してください。 + [でリレーショナルデータベースを MongoDB Atlas に移行する AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-relational-database-to-mongodb-atlas.html) + [で IBM Db2、SAP、Sybase、およびその他のデータベースから MongoDB Atlas にデータをストリーミングする AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/stream-data-from-ibm-db2-to-mongodb-atlas.html) このパターンは、[AWS Systems Integrator (SI) パートナー](https://aws.amazon.com/managed-services/partners/)と AWS ユーザーを対象としています。 ## 前提条件と制限 **前提条件** + MongoDB Atlas に移行するソースの MongoDB Enterprise Advanced、Community Server、またはその他のセルフマネージド MongoDB 環境。 + MongoDB、MongoDB Atlas、および に精通していること AWS のサービス。このパターンでは、移行ステップの一部を大まかに説明します。今後のバージョン更新で詳細が追加される予定です。 **製品バージョン** + MongoDB バージョン 6.0.13 以降 ## アーキテクチャ 次の図は、MongoDB Enterprise Advanced データベースと MongoDB Community データベースから AWS上の MongoDB Atlas にデータを移行するために使用される Atlas Live Migration Service を示しています。最小限のダウンタイムと継続的なデータ同期で大規模かつ複雑なデータベースを MongoDB Atlas に移行する必要がある場合は、このサービスを使用します。このパターンでは、Atlas Live Migration Service を使用します。 ![\[MongoDB Atlas Live Migration Service を使用したデータ移行。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/52cdb923-64ff-4ee2-b129-93b9a139e24b/images/372134c4-ba47-4e48-bd0d-8b43017773b8.png) 次の図は、保護された[AWS PrivateLink](https://aws.amazon.com/privatelink/)接続 AWS を介して MongoDB Enterprise Advanced データベースと MongoDB MongoDB Community データベースから 上の MongoDB Atlas にデータを移行するためにも使用できる MongoDB ミラーサービス (`mongomirror`) を示しています。オンプレミスの MongoDB と MongoDB Atlas 間の継続的なデータレプリケーションの場合には、`mongomirror` を使用します。このツールはディザスタリカバリや段階的移行には最適ですが、このパターンの範囲外です。 ![\[mongomirror ツールを使用してデータを移行する。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/52cdb923-64ff-4ee2-b129-93b9a139e24b/images/53488a9b-2210-4b3d-b517-b618c1e0182c.png) さまざまな使用シナリオをサポートする MongoDB Atlas リファレンスアーキテクチャの詳細については、 AWS 「 規範ガイダンス」ウェブサイトの[「 での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/architecture.html)」を参照してください。 ## ツール + [MongoDB Atlas](https://www.mongodb.com/atlas) は、MongoDB データベースをクラウドにデプロイおよび管理するためのフルマネージド型 Database as a Service (DbaaS) です。 + [Atlas Live Migration Service](https://www.mongodb.com/cloud/atlas/migrate) は、データベースを Atlas に移行するのに役立つ無料の MongoDB ユーティリティです。このサービスは、カットオーバーまで、ソースデータベースを移行先データベースと同期させます。カットオーバーの準備ができたら、アプリケーションインスタンスを停止し、デスティネーションの Atlas クラスターを指定して再起動します。このサービスにアクセスするには、MongoDB Atlas クラスターから **[Database options]** を選択します。 + [mongomirror](https://www.mongodb.com/docs/atlas/import/mongomirror/) は、既存の MongoDB レプリカセットから MongoDB Atlas レプリカセットにデータを手動で移行するためのツールです。`mongomirror` を使用すると、既存のレプリカセットやアプリケーションをシャットダウンする必要はなく、ユーザーやロールのデータをインポートしたり、構成データベースをコピーしたりする必要もありません。[MongoDB ドキュメント](https://www.mongodb.com/docs/atlas/import/mongomirror/#download-mongomirror)から `mongomirror` をダウンロードできます。 ## ベストプラクティス で MongoDB を使用するためのベストプラクティスについては AWS、 [AWS パートナーネットワークブログ](https://aws.amazon.com/blogs/apn/tag/mongodb-atlas/)の投稿を参照してください。 ## エピック ### 発見と評価 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターサイズを決定します。 | `db.stats()` からの合計インデックススペースに関する情報を使用してワーキングセットのサイズを見積もります。データスペースの一部が頻繁にアクセスされると仮定します。または、独自の仮定に基づいてメモリ要件を見積もることもできます。このタスクには約 1 週間かかりそうです。本エピックの本ストーリーおよび他のストーリーの詳細と例については、「[関連リソース](#migrate-a-self-hosted-mongodb-environment-to-mongodb-atlas-on-the-aws-cloud-resources)」セクションをご確認ください。 | DBA、アプリ所有者 | | ネットワーク帯域幅要件を見積もります。 | ネットワーク帯域幅要件を見積もるには、平均ドキュメントサイズに 1 秒あたりに提供されるドキュメント数を掛けます。基準として、クラスター上のノードが負担する最大トラフィックを考慮に入れます。クラスターからクライアントアプリケーションへのダウンストリームのデータ転送速度を計算するには、一定期間に返されたドキュメントの合計を使用します。アプリケーションがセカンダリノードから読み取る場合は、このドキュメントの合計数を、読み取り操作を実行できるノード数で割ります。データベースの平均ドキュメントサイズを求めるには、`db.stats().avgObjSize` コマンドを使用してください。このタスクには通常 1 日かかります。 | DBA | | Atlas 層を選択します。 | [MongoDB ドキュメント](https://www.mongodb.com/docs/atlas/sizing-tier-selection/)の指示に従い、正しい Atlas クラスター階層を選択してください。 | DBA | | カットオーバーを計画します。 | アプリケーションのカットオーバーを計画します。 | DBA、アプリ所有者 | ### AWS に新しい MongoDB Atlas 環境を設定します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | で新しい MongoDB Atlas クラスターを作成します AWS。 | Atlas にログインし、プロジェクトの **[Overview]** ページを開きます。**[Create]** ボタンを選択して、クラスターを作成します。詳細については、 [MongoDB のドキュメント](https://www.mongodb.com/docs/atlas/tutorial/deploy-free-tier-cluster/)をご参照ください。 | DBA | | AWS リージョン および グローバルクラスター設定を選択します。 | Atlas クラスター AWS リージョン で使用できる のリストから を選択します。必要に応じてグローバルクラスタを設定します。詳細については、 [MongoDB のドキュメント](https://www.mongodb.com/docs/atlas/tutorial/deploy-free-tier-cluster/#select-your-preferred-region.)をご参照ください。 | DBA | | クラスター階層を選択します。 | お好みのクラスター階層を選択します。階層の選択によって、メモリ、ストレージ、IOPS の仕様などの要素が決まります。 | DBA | | 追加のクラスター設定を構成します。 | MongoDB のバージョン、バックアップ、暗号化オプションなどのクラスター設定を追加して行います。これらのオプションの詳細については、「[関連リソース](#migrate-a-self-hosted-mongodb-environment-to-mongodb-atlas-on-the-aws-cloud-resources)」セクションを参照してください。 | DBA | ### セキュリティとコンプライアンスを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ユーザーの認証と認可を行います。 | MongoDB Atlas クラスターにアクセスするデータベースユーザーを作成して認証する必要があります。プロジェクト内のクラスターにアクセスするには、ユーザーはそのプロジェクトに属し、複数のプロジェクトに属している必要があります。Atlas は AWS Identity and Access Management (IAM) に基づく認証もサポートしています。詳細については、 [MongoDB のドキュメント](https://www.mongodb.com/docs/atlas/security/aws-iam-authentication/#set-up-authentication-with-aws-iam)をご参照ください。 | DBA | | カスタムロールを作成します。 | (オプション) Atlas では、必要な権限セットが組み込み型 Atlas データベースのユーザー権限ではカバーできない場合に、カスタムロールの作成をサポートしています。 | DBA | | VPC ピアリングを設定します。 | (オプション) Atlas は、他の VPCs との[仮想プライベートクラウド (VPC) ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)をサポートしています AWS。 | AWS 管理者 | | AWS PrivateLink エンドポイントをセットアップします。 | (オプション) AWS を使用して、 でプライベートエンドポイントを設定できます AWS PrivateLink。詳細については、[Amazon VPC のドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)参照してください。 | AWS 管理者 | | 2 要素認証を有効にします。 | (オプション) Atlasは、ユーザーがAtlasアカウントへのアクセスを制御できるようにする 2 要素認証 (2FA) をサポートしています。 | AWS 管理者 | | LDAP によるユーザー認証と認可を設定します。 | (オプション) Atlasは、Lightweight Directory Access Protocol (LDAP) によるユーザー認証および認可の実行をサポートします。 | AWS 管理者 | | 統合 AWS アクセスを設定します。 | (オプション) Atlas Data Lake やカスタマーキー管理による静的暗号化などを含む一部の Atlas 機能では、認証に IAM ロールを使用します。 | AWS 管理者 | | を使用して保管時の暗号化を設定します AWS KMS。 | (オプション) Atlas は、 AWS Key Management Service (AWS KMS) を使用してストレージエンジンとクラウドプロバイダーのバックアップを暗号化することをサポートしています。 | AWS 管理者 | | クライアント側のフィールドレベルの暗号化を設定します。 | (オプション) Atlas は、フィールドの自動暗号化を含む、クライアント側のフィールドレベルの暗号化をサポートします。 | AWS 管理者 | ### データを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MongoDB Atlas でターゲットのレプリカセットを選択します。 | ターゲット Atlas クラスターに移動し、省略記号 (...) ボタンを選択します。クラスターリストでは、このボタンはクラスター名の下に表示されます。クラスターの詳細では、ボタンは右側の **[Connect]** ボタンと **[Configuration]** ボタンの横に表示されます。詳細については、 [MongoDB のドキュメント](https://www.mongodb.com/docs/atlas/import/c2c-pull-live-migration/#procedure)をご参照ください。 | DBA | | Atlas Live Migration Service をアクセスリストに追加します。 | Atlas Live Migration Service を AWS ソースクラスターのアクセスリストに追加します。これにより、ソース環境がターゲットの Atlas クラスターに接続する準備に役立ちます。 | DBA | | Atlas Live Migration Service を使用して移行を実行します。 | **[Start migration]** を選択します。**[Prepare to Cutover]** ボタンが緑色に変わったら、カットオーバーを実行します。Atlas クラスタのパフォーマンスメトリクスを確認してください。すべてのアプリケーションレイヤーでデータベース接続を更新し、新しいデータベースを指すようにすることを検討してください。 | DBA | ### 操作統合の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MongoDB Atlas クラスターに接続します。 | MongoDB Atlas クラスター接続が意図したとおりに動作することを確認します。 | アプリ所有者 | | クラスターデータと対話します。 | クラスターデータをテストします。 | DBA | | クラスターをモニタリングします。 | クラスターが正しく設定されていることを確認します。 | DBA | | クラスターデータをバックアップし、復元します。 | クラスターデータのバックアップを定期的にスケジュールします。 | DBA | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | エラー: 指定されたソースに到達できませんでした | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-a-self-hosted-mongodb-environment-to-mongodb-atlas-on-the-aws-cloud.html) | | エラー: ホスト名を解決できませんでした | 指定されたホスト名の IP アドレスが見つかりません。指定されたホスト名が正しく、パブリックにアクセス可能であることを確認します。 | | その他のエラー | その他のエラーが発生した場合は、[ライブ移行 (プル) のトラブルシューティング](https://www.mongodb.com/docs/atlas/import/live-import-troubleshooting/)に関する MongoDB ドキュメントを参照してください。 | ## 関連リソース 特に明記されていない限り、以下のリンクはすべて MongoDB ドキュメントのウェブページに移動します。 **移行ガイド** + [での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/) (AWS 規範ガイダンス) **レガシー移行** + [旧バージョンの MongoDB の移行](https://www.mongodb.com/docs/atlas/legacy-migration/) 発見と評価 + 「[メモリ](https://docs.atlas.mongodb.com/sizing-tier-selection/#memory)」 + 「[Atlas サンプルデータセットによるサイジングの例](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#example--the-service-sample-data-sets)」 + 「[モバイルアプリケーションのサイジング例](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#example--mobile-app)」 + 「[ネットワークトラフィック](https://docs.atlas.mongodb.com/sizing-tier-selection/#network-traffic)」 + 「[クラスターの自動スケーリング](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#cluster-auto-scaling)」 + 「[Atlas サイジングテンプレート](https://view.highspot.com/viewer/5f438f47a4dfa042e97130c5)」 セキュリティとコンプライアンスの設定 + 「[IP アクセスリストエントリの設定](https://docs.atlas.mongodb.com/security/ip-access-list/)」 + [データベースユーザーの設定](https://docs.atlas.mongodb.com/security-add-mongodb-users/) + [Atlas UI へのアクセスの設定](https://docs.atlas.mongodb.com/organizations-projects/) + [カスタムデータベースロールの設定](https://docs.atlas.mongodb.com/security-add-mongodb-roles) + [データベースユーザーの設定](https://docs.atlas.mongodb.com/security-add-mongodb-users/#atlas-user-privileges) + 「[ネットワークピアリング接続の設定](https://docs.atlas.mongodb.com/security-vpc-peering/)」 + [Atlas のプライベートエンドポイントについて学ぶ](https://docs.atlas.mongodb.com/security-private-endpoint/) + [多要素認証オプションの管理](https://docs.atlas.mongodb.com/security-two-factor-authentication/) + 「[LDAP によるユーザー認証と認可の設定](https://docs.atlas.mongodb.com/security-ldaps/)」 + 「[Atlas データレイク](https://docs.mongodb.com/datalake/)」 + 「[顧客キー管理による静的暗号化](https://docs.atlas.mongodb.com/security-kms-encryption/)」 + [ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) (IAM ドキュメント) + 「[クライアント側のフィールドレベルの暗号化の設定](https://docs.mongodb.com/manual/core/security-client-side-encryption)」 + [自動暗号化](https://docs.mongodb.com/manual/core/security-automatic-client-side-encryption)  + [MongoDB Atlas のセキュリティコントロール](https://webassets.mongodb.com/_com_assets/cms/MongoDB_Atlas_Security_Controls-v7k3rbhi3p.pdf) + [MongoDB トラストセンター](https://www.mongodb.com/cloud/trust) + [クラスターのセキュリティ機能の設定](https://docs.atlas.mongodb.com/setup-cluster-security/) **AWS** **上に新しい MongoDB Atlas 環境を設定する** + 「[クラウドプロバイダーとリージョン](https://docs.atlas.mongodb.com/cloud-providers-regions/)」 + [グローバルクラスターの管理](https://docs.atlas.mongodb.com/global-clusters/) + [クラスター階層の選択](https://www.mongodb.com/docs/atlas/manage-clusters/#select-cluster-tier) + [追加の設定](https://docs.atlas.mongodb.com/cluster-additional-settings/) + [Atlas の使用開始](https://docs.atlas.mongodb.com/getting-started/) + [Atlas UI へのアクセスの設定](https://docs.atlas.mongodb.com/organizations-projects/) **データを移行する** + [データを移行またはインポートする](https://www.mongodb.com/docs/atlas/import/) **クラスターのモニタリング** + [クラスターをモニタリングする](https://docs.atlas.mongodb.com/monitoring-alerts/) オペレーションの統合 + 「[クラスターへの接続](https://docs.atlas.mongodb.com/connect-to-cluster/)」 + [データを操作する](https://docs.atlas.mongodb.com/data-explorer/) + [クラスターをモニタリングする](https://docs.atlas.mongodb.com/monitoring-alerts/) + [データのバックアップ、復元、アーカイブ](https://docs.atlas.mongodb.com/backup-restore-cluster/) **トレーニング** + [Live Migration with MongoDB Atlas](https://learn.mongodb.com/courses/live-migration-with-mongodb-atlas) ## 追加情報 詳細については、MongoDB ドキュメントの次のトピックを参照してください。 + サーバーレスインスタンスにデータを移動するには、[Compass を使用してデータをエクスポートおよびインポート](https://www.mongodb.com/docs/compass/current/import-export/)するか、セルフマネージドツールを使用してデータを移行します。詳細については、[サーバーレスインスタンスの制限事項](https://www.mongodb.com/docs/atlas/reference/serverless-instance-limitations/)を参照してください。 + Atlas の新しいクラスターにデータをロードするには、「[Atlas へのデータのロード](https://www.mongodb.com/docs/atlas/sample-data/#std-label-sample-data)」を参照してください。 + テスト目的でクラスターのコピーを作成するには、[「自己管理型配置のバックアップメソッド](https://www.mongodb.com/docs/manual/core/backups/)」を参照してください。 + 移行するアプリケーションでほぼ継続的なアップタイムが必要な場合は、[MongoDB サポート](https://www.mongodb.com/docs/atlas/support/#std-label-request-support)に連絡して、アップタイム要件とクラスター設定を共有してください。 + 詳細については、「[データの移行またはインポート](https://www.mongodb.com/docs/atlas/import/)」を参照してください。 # AWS DMS を使用して Oracle データベースを Amazon DynamoDB に移行する *Amazon Web Services、Rambabu Karnena* ## 概要 このパターンでは、AWS Database Migration Service ([AWS DMS](https://aws.amazon.com/dms/)) を使用して Oracle データベースを [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) に移行する手順を、順を追って説明します。対象は次の 3 種類のソースデータベースです。 + オンプレミスの Oracle データベース + Amazon Elastic Compute Cloud ([Amazon EC2](https://aws.amazon.com/ec2/)) 上の Oracle Database + Amazon DB インスタンス用 Amazon Relational Database Service ([Amazon RDS](https://aws.amazon.com/rds/)) この概念実証では、このパターンは Amazon RDS for Oracle DB インスタンスからの移行に焦点を当てています。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Amazon RDS for Oracle データベースに接続するアプリケーション + ソース Amazon RDS for Oracle データベースにプライマリキーとサンプルデータを使用して作成されたテーブル **制限** + プロシージャ、関数、パッケージ、トリガーなどの Oracle データベースオブジェクトは、Amazon DynamoDB ではこれらのデータベースオブジェクトをサポートしていないため、移行の対象にはなりません。 **製品バージョン** + このパターンは、AWS DMS でサポートされている Oracle データベースのすべてのエディションとバージョンに適用されます。詳細については、「[Using an Oracle database as a source for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html)」および「[Using an Amazon DynamoDB database as a target for AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.DynamoDB.html)」を参照してください。最も包括的なバージョンと機能サポートするため、最新バージョンを使用することをお勧めします。 ## アーキテクチャ **ソーステクノロジースタック** + Amazon RDS for Oracle DB インスタンス、Amazon EC2 上の Oracle、またはオンプレミス Oracle データベース **ターゲットテクノロジースタック** + Amazon DynamoDB **AWS データ移行アーキテクチャ** ![\[データは Oracle DB から AWS DMS、そして Amazon DynamoDB に移動します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/463fc7d4-ec8d-473b-8c7f-1df31800ee03/images/180e7340-3887-455d-a591-b5850e22770a.png) ## ツール + 「[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」 を使用して、データストアを AWS クラウドへ、またはクラウドセットアップとオンプレミスセットアップの組み合わせの間に移行します。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。このパターンでは Amazon RDS for Oracle を使用します。 ## エピック ### 移行を計画する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | VPC を作成します。 | AWS アカウントで、仮想プライベートクラウド (VPC) とプライベートサブネットを作成します。 | システム管理者 | | セキュリティグループとネットワークアクセス制御リストを作成します。 | 詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)を参照してください。 | システム管理者 | | Amazon RDS for Oracle DB インスタンスを設定して起動します。 | 詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html)を参照してください。 | DBA、システム管理者 | ### データを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB にアクセスするための IAM ロールを作成します。 | AWS Identity and Access Management (IAM) コンソールで、ロールを作成し、ポリシー `AmazonDynamoDBFullAccess to it` をアタッチして、AWS DMS をサービスとして選択します。 | システム管理者 | | 移行用の AWS DMS レプリケーションインスタンスを作成します。 | レプリケーションインスタンスは、ソースデータベースと同じアベイラビリティゾーンおよび VPC に存在する必要があります。 | システム管理者 | | AWS DMS でソースエンドポイントとターゲットエンドポイントを作成します。 | ソースデータベースのエンドポイントを作成するには、次の 2 つのオプションがあります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-an-oracle-database-to-amazon-dynamodb-using-aws-dms.html)ターゲットデータベースのエンドポイントを作成するには、前のタスクの Amazon リソースネーム (ARN) を選択して DynamoDB にアクセスします。 | システム管理者 | | AWS DMS タスクを作成して、ソース Oracle データベーステーブルを DynamoDB にロードします。 | ソースとターゲットのエンドポイント名、および前のステップのレプリケーションインスタンスを選択します。タイプは全負荷でもかまいません。Oracle スキーマを選択し、**%** を指定してすべてのテーブルを選択します。 | システム管理者 | | DynamoDB の表を検証します。 | 移行結果を表示するには、DynamoDB コンソールの左側のナビゲーションペインから **[テーブル]** を選択します。 | DBA | ### アプリケーションを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションコードを変更します。 | DynamoDB に接続してデータを取得するには、アプリケーションコードを更新します。 | アプリ所有者、DBA、システム管理者 | ### カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DynamoDB を使用するようにアプリケーションクライアントを切り替えます。 | | DBA、アプリ所有者、システム管理者 | ### プロジェクトを閉じる | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS リソースをシャットダウンします。 | 例えば、Amazon RDS for Oracle インスタンス、DynamoDB、および AWS DMS レプリケーションインスタンスをシャットダウンします。 | DBA、システム管理者 | | メトリクスを収集します。 | 指標には、移行にかかる時間、手作業とツールが実行した作業の割合、コスト削減などが含まれます。 | DBA、アプリ所有者、システム管理者 | ## 関連リソース + [AWS Database Migration Service and Amazon DynamoDB: What You Need to Know](https://aws.amazon.com/blogs/database/aws-database-migration-service-and-amazon-dynamodb-what-you-need-to-know/) (ブログ投稿) + 「[AWS DMSのソースとして Oracle データベースを使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html)」 + [Using an Amazon DynamoDB database as a target for AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.DynamoDB.html) + [Best Practices for Migrating from RDBMS to Amazon DynamoDB](https://docs.aws.amazon.com/whitepapers/latest/best-practices-for-migrating-from-rdbms-to-dynamodb/welcome.html) (ホワイトペーパー) # SharePlex と AWS DMS を使用して、Oracle 8i または 9i から Amazon RDS for Oracle に移行 *Amazon Web Services、Ramu Jagini* ## 概要 このパターンでは、オンプレミスの Oracle 8i または 9i データベースを、 Oracle データベースの Amazon Relational Database Service (Amazon RDS) に移行する方法について説明してます。このパターンを使用して、Quest SharePlex を同期レプリケーションに使用すると、ダウンタイムを短縮して移行を完了できます。 AWS Database Migration Service (AWS DMS) はソース環境として Oracle 8i または 9i が適用されないため、移行には中間 Oracle データベースインスタンスを使用する必要があります。「[SharePlex 7.6.3](https://www.quest.com/community/shareplex/f/forum/20700/where-can-download-7-6-3-or-support-9i-shareplex)」 を使用して、以前の Oracle データベースバージョンから新しい Oracle データベースバージョンに複製できます。中間 Oracle データベースインスタンスは SharePlex 7.6.3 のターゲットとして互換性があり、AWS DMS またはそれ以降の SharePlex リリースのソースとしても適用されます。この適用により、Amazon RDS for Oracle ターゲット環境へのデータの以降のレプリケーションが可能になります。 いくつかの廃止されたデータ型や特徴量が、Oracle 8i または 9i から最新バージョンの Oracle Database への移行に影響する可能性があることを考慮します。この影響を軽減するために、このパターンでは Oracle 11.2.0.4 を中間データベースバージョンとして使用し、Amazon RDS for Oracle ターゲット環境への移行前にスキーマコードを最適化します。 ## 前提条件と制限事項 **前提条件** + アクティブなAWS アカウント + オンプレミス環境のソース Oracle 8i または 9i データベース + Amazon Elastic Compute Cloud (Amazon EC2) でのステージングの「[Oracle Database 12c Release 2](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/index.html)」 (12CR2) + Quest SharePlex 7.6.3 (商用グレード) **制限事項** + [RDS for Oracle の制限事項](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Oracle.Concepts.limitations.html) **製品バージョン** + ソースデータベース用の Oracle 8i または 9i + ステージングデータベースの Oracle 12CR2 (Amazon RDS for Oracle バージョンと一致する必要があります) + ターゲットデータベースの Oracle 12CR2 以降 (Amazon RDS for Oracle) ## アーキテクチャ **ソーステクノロジースタック** + Oracle 8i または 9i データベース + SharePlex **ターゲットテクノロジースタック** + Amazon RDS for Oracle **移行アーキテクチャ** 次の図表では、オンプレミス環境から AWS クラウドの Oracle 8i または 9i データベースをオンプレミス環境から AWS クラウドの Amazon RDS for Oracle DB インスタンスに移行する方法を示します。 ![\[オンプレミスの Oracle データベースを Amazon RDS on AWS に移行するためのワークフローです。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6e07d586-fd74-4f3d-8e81-79dd55c445c3/images/36e1a5ff-908b-4cb7-96f7-997eb105f1d6.png) この図表は、次のワークフローを示しています: 1. Oracle ソースデータベースをアーカイブログモード、強制ロギング、および補足ロギングでイネーブルにします。 1. リカバリマネージャー (RMAN) のポイントインタイムリカバリと 「[FLASHBACK\$1SCN](https://docs.oracle.com/database/121/SUTIL/GUID-D408B112-1A81-4F68-BEFF-7403A9588DDB.htm#SUTIL849)」 を使用して Oracle ステージングデータベースを Oracle ソースデータベースから復元します。 1. `FLASHBACK_SCN` (RMAN で使用されている) を使用して、 Oracle ソースデータベースから REDO ログを読み取るように SharePlex を設定します。 1. SharePlex レプリケーションを開始して、Oracle ソースデータベースから Oracle ステージングデータベースにデータを同期します。 1. EXPDP と `FLASHBACK_SCN` を伴うIMPDP を使用して Amazon RDS for Oracle のターゲットデータベースを復元します。 1. `FLASHBACK_SCN` (EXPDP で使われている) を使用して、AWS DMS とそのソースタスクを Oracle ステージングデータベースとして設定し、Amazon RDS for Oracle をターゲットデータベースとして設定します。 1. AWS DMS タスクを開始して、Oracle ステージングデータベースから Oracle ターゲットデータベースにデータを同期します。 ## ツール + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + 「[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」 を使用して、データストアを AWS クラウドへ、またはクラウドセットアップとオンプレミスセットアップの組み合わせの間に移行します。 + 「[Quest SharePlex](https://support.quest.com/shareplex/11.0/technical-documents)」 は、ダウンタイムを最小限に抑え、データ損失なしでデータを移動できる Oracle 間のデータ複製ツールです。 + 「[リカバリマネージャー (RMAN)](https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmquick.htm)」 は、データベースのバックアップとリカバリのタスクを実行する Oracle データベースクライアントです。データベースファイルのバックアップ、リストア、リカバリを大幅に簡素化します。 + 「[データパンプエクスポート](https://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_export.htm#SUTIL823)」 を使用して、データとメタデータをダンプファイルセットと呼ばれるオペレーティングシステムファイルのセットにアップロードできます。ダンプファイルセットは、「[データパンプインポート](https://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_import.htm#SUTIL300)」 ユーティリティまたは 「[DBMS\$1DATAPUMP](https://docs.oracle.com/database/121/ARPLS/d_datpmp.htm#ARPLS356)」 パッケージでのみインポートできます。 ## エピック ### Amazon EC2 に SharePlex と Oracle ステージングデータベースをセットアップします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | EC2 インスタンスを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-from-oracle-8i-or-9i-to-amazon-rds-for-oracle-using-shareplex-and-aws-dms.html) | Oracle 管理 | | ステージングデータベースを準備します。 | Oracle 8i または 9i データベースソース環境から RMAN バックアップを取得して、Oracle 12CR2 のアップグレードとして復元できるように Oracle ステージングデータベースを準備します。詳細については、Oracle ドキュメントの「[Oracle 9i リカバリマネージャーユーザーズガイド](https://docs.oracle.com/cd/B10500_01/server.920/a96566/toc.htm)」 と「[データベースバックアップ およびリカバリーユーザーズガイド](https://docs.oracle.com/database/121/BRADV/rcmcomre.htm#BRADV8005)」 を参照してください。 | Oracle 管理 | | SharePlex を設定します。 | SharePlex ソースをオンプレミスの Oracle 8i または 9i データベースとして設定し、ターゲットを Amazon EC2 でホストされている Oracle 12CR2 ステージングデータベースとして設定します。 | SharePlex、Oracle管理 | ### ターゲット環境として Amazon RDS for Oracleを設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle DB インスタンスを作成します。 | Amazon RDS for Oracle データベースを作成し、Oracle 12CR2 をデータベースに接続します。詳細については、Amazon RDS ドキュメントの「[Oracle DB インスタンスを作成して Oracle DB インスタンスのデータベースに接続](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.Oracle.html)」を参照してください。 | DBA | | Amazon RDS for Oracle をステージングデータベースから復元します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-from-oracle-8i-or-9i-to-amazon-rds-for-oracle-using-shareplex-and-aws-dms.html)詳細については、Oracle ドキュメントの「[54 DBMS\$1DATAPUMP](https://docs.oracle.com/en/database/oracle/oracle-database/21/arpls/DBMS_DATAPUMP.html#GUID-AEA7ED80-DB4A-4A70-B199-592287206348)」を参照してください。 | DBA | ### AWS DMS のセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースのエンドポイントを作成します。 | Oracle ステージングデータベース用のソースエンドポイントと、 Amazon RDS for Oracle データベースのターゲットエンドポイントを作成します。詳細については、 AWS ナレッジセンターの「[AWS DMS を使用してソースエンドポイントまたはターゲットエンドポイントを作成する方法](https://aws.amazon.com/premiumsupport/knowledge-center/create-source-target-endpoints-aws-dms/)」 を参照してください。 | DBA | | レプリケーションインスタンスを作成します。 | AWS DMS を使用して、Oracle ステージングデータベースの Amazon RDS for Oracle データベースへのレプリケーションインスタンスを起動します。詳細については、AWS ナレッジセンターの「[AWS DMS レプリケーションインスタンスを作成する方法](https://aws.amazon.com/premiumsupport/knowledge-center/create-aws-dms-replication-instance/)」 を参照してください。 | DBA | | レプリケーションタスクを作成します。 | EXPDP から `FLASHBACK_SCN` を使用して、変更データキャプチャ (CDC) の AWS DMS レプリケーションタスクを作成します (全ロードは EXPDP ですでに行われているため)。 詳細については、AWS DMSのドキュメントの「[タスクを作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html) 」を参照してください。 | DBA | ### Amazon RDS for Oracle へのカットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションワークロードを停止します。 | 予定されているカットオーバー期間中、アプリケーションサーバーとそのアプリケーションを停止します。 | アプリ開発者、DBA | | オンプレミスの Oracle ステージングデータベースと EC2 インスタンスの同期を検証します。 | オンプレミスのソースデータベースでいくつかのログスイッチを実行して、SharePlex レプリケーションインスタンスから Amazon EC2 の Oracle ステージングデータベースへのレプリケーションタスクのすべてのメッセージが掲示されていることを確認します。詳細については、Oracle ドキュメントの「[6.4.2 ログファイルの切り替え](https://docs.oracle.com/database/121/ADMQS/GUID-E30B4C65-2AC7-4A44-A58C-D3C121EB152F.htm#ADMQS12075)」 を参照してください。 | DBA | | Oracle ステージングデータベースと Amazon RDS for Oracle データベースとの同期を検証します。 | すべての AWS DMS タスクに遅延やエラーがないことを確認し、タスクの検証状態を確認します。 | DBA | | SharePlex と Amazon RDS のレプリケーションを停止します。 | SharePlex と AWS DMS の両方のレプリケーションにエラーが表示されない場合、両方のレプリケーションを停止します。 | DBA | | アプリケーションを Amazon RDS に再マップします。 | Amazon RDS for Oracle エンドポイントの詳細をアプリケーションサーバーとそのアプリケーションと共有し、それからアプリケーションを起動して業務を再開します。 | アプリ開発者、DBA | ### AWS ターゲット環境のテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | AWS で Oracle ステージングデータベース環境をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-from-oracle-8i-or-9i-to-amazon-rds-for-oracle-using-shareplex-and-aws-dms.html) | SharePlex、Oracle管理 | | Amazon RDS 環境をテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/migrate-from-oracle-8i-or-9i-to-amazon-rds-for-oracle-using-shareplex-and-aws-dms.html)詳細については、Amazon RDS ドキュメントの「[Amazon RDS for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html)」 を参照してください。 | Oracle 管理 | ## 関連リソース + 「[自信を持って移行](https://aws.amazon.com/cloud-migration/)」 + 「[Amazon EC2](https://aws.amazon.com/ec2/)」 + 「[Amazon RDS for Oracle](https://aws.amazon.com/rds/oracle/)」 + 「[AWS Database Migration Service](https://aws.amazon.com/dms/)」 + 「[AWS DMS 移行のデバッグ: 問題が発生した場合の対処方法 (パート 1)](https://aws.amazon.com/blogs/database/debugging-your-aws-dms-migrations-what-to-do-when-things-go-wrong-part-1/)」 + 「[AWS DMS 移行のデバッグ: 問題が発生した場合の対処方法 (パート 2)](https://aws.amazon.com/blogs/database/debugging-your-aws-dms-migrations-what-to-do-when-things-go-wrong-part-2/)」 + 「[AWS DMS 移行のデバッグ: 問題が発生した場合の対処法」 「(パート 3)](https://aws.amazon.com/blogs/database/debugging-your-aws-dms-migrations-what-to-do-when-things-go-wrong-part-3/)」 + 「[SharePlex によるデータベースレプリケーション](https://aws.amazon.com/marketplace/pp/B07943W4MJ)」 + 「[SharePlex: あらゆる環境に対応するデータベースレプリケーション](https://www.youtube.com/watch?v=ygS_ouUaNus)」 # オンプレミス MySQL データベースを Amazon EC2 に移行する *Amazon Web Services、Lorenzo Mota* ## 概要 このパターンは、オンプレミス MySQL データベースを Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上の MySQL データベースに移行するガイダンスを提供します。このパターンでは、移行に AWS Database Migration Service (AWS DMS) または **mysqldump** などのネイティブ MySQL ツールを使用する方法について説明します。MySQL DB インスタンスへの完全なデータベース移行に焦点を当てています。 このパターンは主に DBA とソリューションアーキテクトを対象としています。大小の規模のプロジェクト、テストフェーズ、または最終的な移行フェーズで使用できます。このパターンを本番環境で使用する前に、少なくとも 1 つのテストサイクルを実行することをお勧めします。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + オンプレミスデータセンターの MySQL ソースデータベース  **製品バージョン** + MySQL バージョン 5.5 以降 + Amazon EC2 がサポートしているターゲットオペレーティングシステムについては、「[Amazon EC2 よくある質問](https://aws.amazon.com/ec2/faqs/)」を参照してください。 ## アーキテクチャ **ソーステクノロジースタック** + オンプレミス MySQL データベース **ターゲットテクノロジースタック** + Amazon EC2 の MySQL データベースインスタンス **AWS データ移行方法** + AWS DMS + [mysqldump](https://dev.mysql.com/doc/refman/en/mysqldump.html) などのネイティブ MySQL ツール、または [Percona XtraBackup](https://www.percona.com/mysql/software/percona-xtrabackup) などのサードパーティーツール **ターゲットアーキテクチャ** 次の図は、カットオーバー後のターゲットの Amazon EC2 実装を示しています。 ![\[スタンバイ MySQL DB インスタンスへのレプリケーションを備えた Amazon EC2 上の MySQL DB インスタンス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d22b3e25-4d3b-4bd7-ad07-501748d67752/images/34cab6f9-9107-4c3b-98ec-a6d7fa9f298a.png) **AWS データ移行アーキテクチャ** AWS DMS を使用する: 次の図は、カットオーバーまでターゲット MySQL データベースに完全および増分の変更を送信 AWS DMS するための に基づくデータ移行ワークフローを示しています。オンプレミスから へのネットワーク接続は、SQL クライアントの要件 AWS に依存し、このパターンの範囲外です。 ![\[AWS DMS を使用して、Amazon EC2 のターゲット MySQL DB にデータを送信します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d22b3e25-4d3b-4bd7-ad07-501748d67752/images/c906c45d-fac5-4bb9-b8c8-55e2f9f05fd8.png) *他の MySQL ツールの使用:* 次の図は、MySQL ツールを使用してオンプレミスデータベースからエクスポートダンプファイルを生成するデータ移行ワークフローを示しています。これらのファイルは Amazon Simple Storage Service (Amazon S3) に移動され、カットオーバー前にターゲット MySQL データベースにインポートされます。オンプレミスから へのネットワーク接続は、SQL クライアントの要件 AWS に依存し、このパターンの範囲外です。 ![\[ネイティブ MySQL ツールを使用して、Amazon EC2 のターゲット MySQL DB にデータを送信します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d22b3e25-4d3b-4bd7-ad07-501748d67752/images/18e88877-7879-4a99-b985-25c56bf7c35f.png) 注記: + ダウンタイムに関する考慮事項と最終カットオーバーのデータベースのサイズに応じて、 AWS DMS または別の変更データキャプチャ (CDC) ツールを使用してカットオーバー時間を最小限に抑えることができます。などの CDC ツールを使用すると AWS DMS、数分でターゲットデータベースに移行できます。  + データベースのサイズとネットワークレイテンシーによって短いカットオーバー移行期間が許容される場合は、**mysqldump** を使用したオフライン戦略で十分です (おおよその時間を把握するためにテストを実行することをお勧めします)。 + 通常、 経由の CDC 戦略には、オフラインオプションよりも多くのモニタリングと複雑さ AWS DMS が必要です。 ## ツール **AWS サービス** + [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) は、複数のソースデータベースとターゲットデータベースをサポートしています。でサポートされている MySQL ソースデータベースとターゲットデータベースの詳細については AWS DMS、「 [のソースとして MySQL 互換データベース AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html)を使用する」および「 [のターゲットとして MySQL 互換データベースを使用する AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html)」を参照してください。ソースデータベースが でサポートされていない場合は AWS DMS、別の方法を選択してデータを移行する必要があります。 **その他のツール** + [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) は、バックアップまたは移行の目的で MySQL データベースからダンプファイルを作成する MySQL ユーティリティです。 + [Percona XtraBackup](https://www.percona.com/mysql/software/percona-xtrabackup) は、MySQL データベースでノンブロッキングバックアップを実行するためのオープンソースユーティリティです。 ## エピック ### 移行を計画する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースのバージョンを検証します。 | ソースデータベースとターゲットデータベースのバージョンを検証します。でサポートされている MySQL のバージョンについては AWS DMS、 AWS DMS ドキュメントの[「 のソース AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.Sources.html)」と「 [のターゲット AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.Targets.html)」を参照してください。 | DBA | | ターゲットオペレーティングシステムを識別します。 | ターゲットオペレーティングシステムのバージョンを特定します。Amazon EC2 がサポートしているターゲットオペレーティングシステムのリストについては、「[Amazon EC2 よくある質問](https://aws.amazon.com/ec2/faqs/)」を参照してください。 | DBA、システム管理者 | | ハードウェア要件を特定します。 | MySQL 互換性リストと容量要件に基づき、[ターゲットサーバーインスタンス](https://aws.amazon.com/rds/instance-types/)のハードウェア要件を特定します。 | DBA、システム管理者 | | ストレージ要件を特定します。 | ターゲットデータベースのストレージタイプと容量を特定します。 | DBA、システム管理者 | | ネットワーク要件を特定します。 | レイテンシーや帯域幅などのネットワーク要件を特定します。 | DBA、システム管理者 | | ターゲットインスタンスタイプを選択します。 | 容量、ストレージ機能、ネットワーク機能に基づいて、[ターゲットインスタンスタイプ](https://aws.amazon.com/rds/instance-types/)を選択します。 | DBA、システム管理者 | | セキュリティ要件を特定します。 | ソースとターゲットのデータベースのネットワークまたはホストアクセスのセキュリティ要件を特定します。 | DBA、システム管理者 | | ユーザーを識別します。 | MySQL ソフトウェアインストールのオペレーティングシステムユーザーのリストを特定します。詳細については、[MySQL ドキュメント](https://dev.mysql.com/doc/mysql-security-excerpt/en/access-control.html)を参照してください。 | DBA、システム管理者 | | バックアップ戦略を決定します。 | | DBA | | 可用性の要件を決定します。 | | DBA | | アプリケーションの移行またはスイッチオーバー戦略を特定します。 | | DBA、システム管理者 | ### インフラストラクチャを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 仮想プライベートクラウド (VPC) とサブネットを作成する。 | ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ、サブネットを設定します。詳細については、Amazon VPC ドキュメントの「[VPC の設定オプション](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc-options.html)」を参照してください。 | システム管理者 | | セキュリティグループとネットワークアクセスコントロールリスト (ACL) を作成します。 | 要件に応じて、ポート (MySQL のデフォルトは 3306) と CIDR 範囲、または特定の IP を設定します。 | システム管理者 | | EC2 インスタンスを設定して起動します。 | 手順については、Amazon EC2 ドキュメントの「[Amazon EC2 インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)」を参照してください。 | システム管理者 | ### MySQL ソフトウェアをインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ユーザーおよびグループを作成します。 | サーバーおよびデータベースへのアクセスが必要なオペレーティングシステムユーザーとグループを作成します。詳細は、MySQL ドキュメントの「[アクセスコントロールおよびアカウントマネジメント](https://dev.mysql.com/doc/refman/en/access-control.html)」を参照してください。 | DBA、システム管理者 | | MySQL をダウンロードします。 | MySQL ソフトウェアをダウンロードします。手順とバイナリについては、MySQL ドキュメントの「[Installing MySQL](https://dev.mysql.com/doc/refman/en/installing.html)」を参照してください。 | DBA、システム管理者 | | MySQL を EC2 インスタンスにインストールし、サーバーを設定します。 | EC2 インスタンスに接続して MySQL ソフトウェアをインストールします。詳細については、Amazon EC2 ドキュメントの「[EC2 インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect.html)」を参照してください。 | DBA、システム管理者 | ### データ移行 – オプション 1 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ネイティブ MySQL またはサードパーティーツールを使用してデータを移行します。 | このオプションでは、ネイティブ MySQL ツールまたはサードパーティーツールを使用して、データベースオブジェクトとデータを移行します。手順については、[mysqldump](https://dev.mysql.com/doc/refman/en/mysqldump.html) または [Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/2.4/index.html) (物理的な移行の場合) のドキュメントを参照してください。これらのツールの使用の詳細については、 AWS ブログ記事[MySQL の Amazon RDS for MySQL または Amazon Aurora MySQL への移行オプション MySQL](https://aws.amazon.com/blogs/database/migration-options-for-mysql-to-amazon-rds-for-mysql-or-amazon-aurora-mysql/)」を参照してください。 | DBA | ### データ移行 – オプション 2 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | を使用してデータを移行します AWS DMS。 | 詳細については、 AWS DMS ドキュメントの [「 の高レベルビュー AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.HighLevelView.html)」を参照してください。 | DBA | ### カットオーバーを準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | オブジェクト数を収集します。 | ソースデータベースと新しいターゲットデータベースからオブジェクト数を収集します。ターゲットデータベースの不一致がある場合は修正します。 | DBA | | 依存関係を確認します。 | 他のデータベースとの間の依存関係 (リンク) がまだ有効であり、正しく機能していることを確認します。 | DBA | | テストします。 | テストサイクルの場合は、クエリテストを実行し、メトリクスを収集し、問題がある場合は修正します。 | DBA | ### カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クライアントを移動します。 | アプリケーションクライアントを新しいインフラストラクチャに切り替ます。 | DBA、アプリ所有者、システム管理者 | | サポートを提供します。 | 機能アプリケーションテスト中にサポートします。 | DBA | ### プロジェクトを閉じる | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをシャットダウンします。 | AWS DMS レプリケーションインスタンスおよびその他の一時 AWS リソースをシャットダウンします。 | DBA、システム管理者 | | プロジェクト文書を確認します。 | プロジェクト文書を確認して検証する。 | DBA、アプリ所有者、システム管理者 | | メトリクスを収集します。 | 移行時間、ツールによる変更と比較した手動変更の割合、コスト削減などのメトリクスを収集します。 | DBA、アプリ所有者、システム管理者 | | プロジェクトを終了します。 | 移行プロジェクトを終了し、フィードバックを提供します。 | DBA、アプリ所有者、システム管理者 | | ソースデータベースを廃止します。 | オンプレミス MySQL データベースを廃止します。 | DBA、システム管理者 | ## 関連リソース **リファレンス** + 「[Amazon EC2 ドキュメント](https://docs.aws.amazon.com/ec2/)」 + [AWS DMS ドキュメント](https://docs.aws.amazon.com/dms/) + 「[Amazon EC2 の料金](https://aws.amazon.com/ec2/pricing/)」 + [AWS DMS Step-by-Stepのチュートリアル](https://docs.aws.amazon.com/dms/latest/sbs/DMS-SBS-Welcome.html) + [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) + [Percona XtraBackup](https://www.percona.com/mysql/software/percona-xtrabackup) **チュートリアルと動画** + [の開始方法 AWS DMS](https://aws.amazon.com/dms/getting-started/) + [Amazon EC2 のご紹介 – Elastic クラウドサーバーと AWSでのホスティング](https://www.youtube.com/watch?v=TsRBftzZsQo) (ビデオ) # 暗号化されていない Amazon Aurora インスタンスをモニタリングする *Amazon Web Services、Mansi Suratwala* ## 概要 このパターンは、Amazon Web Services (AWS) CloudFormation テンプレートを提供して、暗号化をオンにせずに Amazon Aurora インスタンスが作成されたときに自動通知を設定するためにデプロイできます。 Aurora はフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。Aurora では、既存のアプリケーションのほとんどを変更せずに、ほんの少しのワークロードで MySQL のスループットの 5 倍、PostgreSQL のスループットの 3 倍を実現します。 CloudFormation テンプレートは Amazon CloudWatch Events イベントと AWS Lambda 関数を作成します。このイベントでは、AWS CloudTrail を使用して 任意のAurora インスタンスの作成や既存インスタンスの特定時点での復元をモニタリングします。Cloudwatch Events は、暗号化が有効になっているかどうかをチェックする Lambda 関数を呼び出します。暗号化が有効になっていない場合、Lambda 関数から Amazon Simple Notification Service (Amazon SNS) 通知が送信されます。  ## 前提条件と制限事項 前提条件 + アクティブなAWS アカウント **機能制限 ** + このサービスコントロールは Amazon Aurora インスタンスでのみ機能します。他のAmazon Relational Database Service (Amazon RDS) インスタンスをサポートしません。 + CloudFormation テンプレートは、`CreateDBInstance`** **と `RestoreDBClusterToPointInTim`**e** にのみデプロイする必要があります。  **製品バージョン** + Amazon Aurora でサポートされている PostgreSQL のバージョン + Amazon Aurora でサポートされている MySQL バージョン ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon Aurora + AWS CloudTrail + Amazon CloudWatch + AWS Lambda + Amazon Simple Storage Service (Amazon S3) + Amazon SNS **ターゲット アーキテクチャ** ![\[CloudTrail CloudWatch Events、Lambda、SNS メッセージを呼び出す暗号化を用いない Aurora 起動。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/de1528b8-a5a4-4c66-8ab3-7d9863572cbc/images/7dcab41a-d805-4bb0-99d1-1dcef37c4e55.png) **自動化とスケール** CloudFormation テンプレートは、さまざまな国/地域とアカウントに複数回使用できます。各リージョンまたはアカウントで 1 回のみ実行できます。 ## ツール **ツール** + 「[Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html)」— Amazon Aurora はフルマネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。 + 「[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」— AWS CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、および運用とリスクの監査を管理します。ユーザー、ロール、または AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録されます。  + 「[Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)」— Amazon CloudWatch Events は、AWS リソースの変更を説明するシステムイベントのほぼリアルタイムのストリームを提供します。  + 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。  + 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)」—「Amazon Simple Storage Service (Amazon S3)」は、スケーラビリティの高いオブジェクトストレージサービスで、ウェブサイト、モバイルアプリケーション、バックアップとデータレイクなど、幅広いストレージソリューションに使用できます。 + 「[Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」—「Amazon Simple Notification Service (Amazon SNS)」は、Lambda、HTTP、Eメール、モバイルプッシュ通知とモバイルテキストメッセージ (SMS) を使用してメッセージを配信するマネージドサービスです。  **コード** プロジェクトの .zip ファイルは添付ファイルとして入手できます。 ## エピック ### Lambda スクリプト用の S3 バケットを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットを定義します。 | Amazon S3 コンソールを開き、S3 バケットを選択、または作成します。この S3 バケットは Lambda コードの.zip ファイルをホストします。S3 バケットは、Aurora と同じ国/地域に存在する必要があります。S3 バケット名の先頭にスラッシュを含めることはできません。 | クラウドアーキテクト | ### S3 バケットに Lambda コードをアップロードします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda コードをアップロードします。 | *[添付ファイル]* セクションにある Lambda コードの .zip ファイルを S3 バケットにアップロードします。 | クラウドアーキテクト | ### CloudFormation のテンプレートを入手するには | タスク | 説明 | 必要なスキル | | --- | --- | --- | | CloudFormation のテンプレートをデプロイします。 | CloudFormation コンソールで、このパターンへの添付ファイルとして提供されている `RDS_Aurora_Encryption_At_Rest.yml` CloudFormation テンプレートをデプロイします。次のエピックでは、テンプレートパラメータの値を指定します。 | クラウドアーキテクト | ### CloudFormation テンプレートのパラメータを入力します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケット名を指定します。 | 最初のエピックで作成または選択した S3 バケットの名前を入力します。 | クラウドアーキテクト | | S3 キーを指定します。 | S3 バケットの Lambda コードの .zip ファイルの場所を、先頭にスラッシュを付けずに指定します (例: `/.zip`)。 | クラウドアーキテクト | | Eメールアドレスを入力します。 | Amazon SNS 通知を受信するための有効な Eメールアドレスを指定します。 | クラウドアーキテクト | | ログ記録のレベルを定義します。 | Lambda 関数のロギングレベルと頻度を定義します。 `Info` アプリケーションの進行状況に関する詳細な情報メッセージを指定します。 `Error` それでもアプリケーションの実行を継続できるエラーイベントを指定します。 `Warning` 潜在的に有害な状況を示します。 | クラウドアーキテクト | ### サブスクリプションを確認 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サブスクリプションを確認します。 | テンプレートが正常にデプロイされると、指定されたメールアドレスに購読メールメッセージが送信されます。通知を受信するには、このメールのサブスクリプションを確認する必要があります。  | クラウドアーキテクト | ## 関連リソース + 「[S3 バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)」 + 「[S3 バケットへのファイルアップロード](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/upload-objects.html)」  + [Amazon Aurora DB クラスターの作成](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.CreateInstance.html) + 「[AWS CloudTrail を使用して AWS API コールでトリガーする CloudWatch Events ルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)」 ## アタッチメント このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/de1528b8-a5a4-4c66-8ab3-7d9863572cbc/attachments/attachment.zip)」 # Amazon CloudWatch を使用して Oracle GoldenGate ログを監視する *Amazon Web Services、Chithra Krishnamurthy* ## 概要 Oracle GoldenGate は、Oracle データベース用の Amazon Relational Database Service (Amazon RDS) または Amazon Elastic Compute Cloud (Amazon EC2) でホストされている Oracle データベース間のリアルタイムレプリケーションを提供しています。一方向レプリケーションと双方向レプリケーションの両方をサポートしています。 Oracle GoldenGate をレプリケーションに使用する場合は、Oracle GoldenGate プロセスが稼働していて、ソースデータベースとターゲットデータベースが同期していることを確認してください。 このパターンでは、GoldenGate エラーログの Amazon CloudWatch モニタリングを実装する手順と、レプリケーションを迅速に再開するための適切なアクションを実行できるような、`STOP` または `ABEND` など特定のイベントの通知を送信するようにアラームを設定する方法について説明します。 ## 前提条件と制限事項 前提条件 + GoldenGate は EC2 インスタンスにインストールし設定されているため、これらの EC2 インスタンスで CloudWatch モニタリングをセットアップできます。AWS リージョン全体で GoldenGate をモニタリングして双方向レプリケーションを行う場合は、GoldenGate プロセスが実行されている各 EC2 インスタンスに CloudWatch エージェントをインストールする必要があります。 制限事項 + このパターンでは、CloudWatch を使用して GoldenGate プロセスをモニタリングする方法を説明します。CloudWatch は、レプリケーション中のレプリケーションラグやデータ同期の問題をモニタリングしません。「[GoldenGate のドキュメント](https://docs.oracle.com/en/middleware/goldengate/core/19.1/index.html)」で説明されているように、レプリケーションラグやデータ関連のエラーをモニタリングするには、別の SQL クエリを実行する必要があります。 **製品バージョン** + このドキュメントは、Linux x86-64 上の Oracle 用 Oracle GoldenGate 19.1.0.0.4 の実装を基にしています。ただし、このソリューションは GoldenGate のすべての主要バージョンに適用できます。 ## アーキテクチャ **ターゲットテクノロジースタック** + EC2 インスタンスにインストールされた Oracle 用 GoldenGate バイナリ + Amazon CloudWatch + Amazon Simple Notification Service (Amazon SNS) **ターゲットアーキテクチャ** ![\[AWS 上の GoldenGate ログをモニタリングするためのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/973a71d5-b6b3-4a2b-813e-cb4d8fd51ba5/images/1781aa9b-77b3-40c4-bc54-3cb91400899c.png) ## ツール **AWS サービス** + [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、このようなパターンで GoldenGate エラーログをモニタリングするために使用されるモニタリングサービスです。 + [Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) は、このようなパターンでメール通知を送信するために使用されるメッセージ通知サービスです。 その他のツール + 「[Oracle GoldenGate](https://docs.oracle.com/en/middleware/goldengate/core/19.1/index.html)」は、Oracle データベース用の Amazon RDS for Oracle または Amazon EC2 でホストされている Oracle データベースに使用できるデータレプリケーションツールです。 ハイレベルな実装ステップ 1. CloudWatch エージェント用に AWS Identity and Access Management (IAM) ロールを作成します。 1. GoldenGate エラーログが生成される EC2 インスタンスに IAM ロールを添付します。 1. EC2 インスタンスに CloudWatch エージェントをインストールします。 1. CloudWatch エージェント設定ファイルの `awscli.conf` と `awslogs.conf` を設定します。 1. CloudWatch エージェントを起動します。 1. ロググループにメトリックスフィルタを作成します。 1. Amazon SNS をセットアップします。 1. 次に、メトリクスフィルターのアラームを作成します。Amazon SNS は、これらのフィルタがイベントをキャプチャするとメールアラートを送信します。 詳細な手順については、次のセクションを参照してください。 ## エピック ### ステップ 1. CloudWatch エージェント用の IAM ロールを作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | IAM ロールの作成 | AWS リソースへのアクセスには権限が必要なので、各サーバーが CloudWatch エージェントを実行するのに必要な権限を含む IAM ロールを作成します。IAM ロールを作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html) | AWS 全般 | ### ステップ 2. GoldenGate EC2 インスタンスに IAM ロールを添付 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GoldenGate エラーログが生成される EC2 インスタンスに IAM ロールを添付します。 | GoldenGate によって生成されたエラーログは CloudWatch に入力してモニタリングする必要があるため、ステップ 1 で作成した IAM ロールを GoldenGate が実行されている EC2 インスタンスに添付する必要があります。IAM ロールをインスタンスにアタッチするには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html) | AWS 全般 | ### ステップ 3 ～ 5。Goldengate EC2 インスタンスに CloudWatch Logs エージェントをインストールして設定します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GoldenGate EC2 インスタンスに CloudWatch エージェントをインストールします。 | エージェントをインストールするには、以下のコマンドを実行します。
sudo yum install -y awslogs
| AWS 全般 | | エージェント設定ファイルを編集します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html) | AWS 全般 | | CloudWatch エージェントを起動します。 | エージェントを開始するには、次のコマンドを実行します。
$ sudo service awslogsd start
エージェントを起動した後、CloudWatch コンソールでロググループを表示できます。ログストリームにはファイルのコンテンツが含まれています。 | AWS 全般 | ### ステップ 6. ロググループのメトリクスフィルターの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | キーワードの「ABEND」と「STOPPED」のために、メトリックスフィルターを作成します。 | ロググループのメトリックスフィルタを作成すると、エラーログでフィルタが特定されるたびに、アラームが起動し、Amazon SNS 設定に基づき、メール通知が送信されます。メトリックスフィルターを作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html) | CloudWatch | ### ステップ 7. Amazon SNS をセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SNS トピックを作成します。 | このステップでは、Amazon SNS を設定して、メトリックスフィルタのアラームを作成します。SNS トピックを作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html) | Amazon SNS | | サブスクリプションを作成します。 | トピックのサブスクリプションを作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html)Amazon SNS がウェブブラウザを開き、サブスクリプション ID とともにサブスクリプションの確認を表示します。 | Amazon SNS | ### ステップ 8. メトリックスフィルタの通知を送信するアラームを作成します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SNS トピック用のアラームを作成します。 | ロググループのメトリクスフィルターに基づいてアラームを作成するには[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html)これらの手順を実行すると、モニタリングしている GoldenGate エラーログファイル (`ggserr.log`) でこれらのパターンが検出されるたびに、電子メール通知が届きます。 | CloudWatch | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | GoldenGate エラーログからのログストリームは CloudWatch に流れません。 | `/etc/awslogs/awslogs.conf` ファイルを確認して、ファイル名、ロググループ名、日付/時刻の形式を確認します。`ggserror.log` の日付形式と一致する日付/時刻を指定する必要があります。そうしないと、ログストリームは CloudWatch に流れません。 | ## 関連リソース + 「[Amazon CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」 + 「[CloudWatch エージェントを使用したメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)」 + 「[Amazon SNS のドキュメント](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」 # Amazon RDS for Oracle で Oracle Database エンタープライズエディションから標準エディション 2 へリプラットフォームする *Lanre (Lan-Ray) showunmi と Tarun Chawla、Amazon Web Services* ## 概要 Oracle Database エンタープライズエディション (EE) は、多くの企業でアプリケーションを実行する人気の選択肢です。ただし、アプリケーションによっては Oracle Database EE の機能をほとんどまたは全く使用しないため、莫大なライセンスコストが発生する正当性が欠落しています。Amazon RDS に移行するときに、このようなデータベースを Oracle Database 標準エディション 2 (SE2) にダウングレードすることで、コスト削減を実現できます。 このパターンは、オンプレミスから [Amazon RDS for Oracle](https://aws.amazon.com/rds/oracle/) に移行する際に Oracle Database EE から Oracle Database SE2 にダウングレードする方法を説明しています。このパターンに示されている手順は、EE Oracle データベースが既に Amazon RDS または [Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)」(Amazon EC2) インスタンスで実行中の場合にも適用されます。 詳細については、[Oracle データベースを AWS の標準エディション 2 へのダウングレードの評価](https://docs.aws.amazon.com/prescriptive-guidance/latest/evaluate-downgrading-oracle-edition/welcome.html)方法に関する AWS 規範ガイダンスガイドを参照してください。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + Oracle Database エンタープライズエディション + [Oracle SQL Developer](https://www.oracle.com/database/sqldeveloper/) または SQL\$1Plus など、Oracle データベースで SQL コマンドを接続および実行するクライアントツール + 評価を実行するデータベースユーザー。例えば、次のいずれか。 + [AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) 評価を実行する十分な[特権](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Source.Oracle.html#CHAP_Source.Oracle.Permissions)があるユーザー + Oracle データベースディクショナリテーブルで SQL クエリを実行する十分な特権があるユーザー + データベース移行を実行するデータベースユーザー。例えば、次のいずれか。 + [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)を実行する十分な[特権](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html#CHAP_Source.Oracle.Self-Managed)があるユーザー + [Oracle Data Pump のエクスポートとインポートを実行する十分な権限](https://docs.oracle.com/database/121/SUTIL/GUID-8B6975D3-3BEC-4584-B416-280125EEC57E.htm#SUTIL807)があるユーザー + [Oracle GoldenGate を実行する十分な特権](https://docs.oracle.com/goldengate/1212/gg-winux/GIORA/user_assignment.htm#GIORA546)があるユーザー **制限** + Amazon RDS for Oracle には最大データベースサイズがあります。詳細については、[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)を参照してください。 **製品バージョン** 本書で説明する一般的な論理は、Oracle の 9i 以降のバージョンに適用されます。サポートされているセルフマネージドデータベースと Amazon RDS for Oracle データベースのバージョンについては、[AWS DMSドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html)を参照してください。 AWS SCT がサポートされていない場合に、機能の使用状況を特定するには、ソースデータベースで SQL クエリを実行します。AWS DMS と Oracle Data Pump がサポートされていない Oracle の旧バージョンから移行するには、[Oracle エクスポートユーティリティとインポートユーティリティ](https://docs.oracle.com/cd/B19306_01/server.102/b14215/exp_imp.htm)を使用します。 サポートされているバージョンとエディションの最新リストについては、 AWS ドキュメントの [Oracle on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html) を参照してください。価格設定とサポートされているインスタンスクラスの詳細については、[Amazon RDS for Oracle の価格設定](https://aws.amazon.com/rds/oracle/pricing/)を参照してください。 ## アーキテクチャ **ソーステクノロジースタック** + オンプレミスまたは Amazon EC2 で実行中の Oracle Database エンタープライズエディション **ネイティブ Oracle ツールを使用したターゲットテクノロジースタック** + Oracle Database SE2 を実行中の Amazon RDS for Oracle ![\[オンプレミスの Oracle DB から Amazon RDS に移行する 3 段階のプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a1b28050-9bab-4de6-b2a9-b97b3e5070bd/images/bf765c5b-4b12-4a8c-b27c-c5e0bd605dd1.png) 1. Oracle Data Pump を使用してデータをエクスポートします。 1. データベースリンクで Amazon RDS にダンプファイルをコピーします。 1. Oracle Data Pump を使用して Amazon RDS にダンプファイルをインポートします。 **AWS DMS を使用したターゲットテクノロジースタック** + Oracle Database SE2 を実行中の Amazon RDS for Oracle + AWS DMS ![\[AWS DMS を使用してオンプレミスの Oracle DB から Amazon RDS に移行する 4 段階のプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a1b28050-9bab-4de6-b2a9-b97b3e5070bd/images/fef4eced-1acb-4303-baaa-5c1c29650935.png) 1. Oracle Data Pump と FLASHBACK\$1SCN を使用してデータをエクスポートします。 1. データベースリンクで Amazon RDS にダンプファイルをコピーします。 1. Oracle Data Pump を使用して Amazon RDS にダンプファイルをインポートします。 1. AWS DMS [変更データキャプチャ (CDC)](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Task.CDC.html) を使用します。 ## ツール AWS サービス + 「[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」 を使用して、データストアを AWS クラウドへ、またはクラウドセットアップとオンプレミスセットアップの組み合わせの間に移行します。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。このパターンでは Amazon RDS for Oracle を使用します。 + [AWS SCT](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html)** ** は、ソース Oracle データベースのデータベーススキーマをAmazon RDS for Oracle と互換性のある形式に自動的に評価、変換、コピーするプロジェクトベースのユーザーインターフェイスを提供します AWS SCT を使用すると、ライセンスタイプを Oracle のエンタープライズから標準エディション 2 に変更することで実現できる潜在的なコスト削減を分析できます。AWS SCT レポートの **ライセンス評価とクラウドサポート**セクションには、使用中の Oracle 機能に関する詳細情報が表示されるため、Amazon RDS for Oracle への移行時に情報に基づき決定できます。 **その他のツール** + ネイティブ Oracle インポートとエクスポートのユーティリティは、Oracle データの Oracle データベース内外への移動をサポートします。Oracle は、[オリジナルのエクスポートとインポート](https://docs.oracle.com/cd/B19306_01/server.102/b14215/exp_imp.htm) (以前のリリースの場合) と [Oracle Data Pump のエクスポートとインポート](https://docs.oracle.com/cd/B19306_01/server.102/b14215/part_dp.htm#CEGJCCHC) (Oracle Database 10g リリース 1 以降で使用可能) という 2 つのタイプのデータベースのインポートとエクスポートユーティリティを提供しています。 + [Oracle GoldenGate](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.OracleGoldenGate.html) は、リアルタイムレプリケーション機能を提供しているため、初回のロード後にターゲットデータベースを同期できます。このオプションは、稼働開始時のアプリケーションのダウンタイムの削減に役立ちます。 ## エピック ### 移行前の評価をする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アプリケーションのデータベース要件を検証します。 | アプリケーションを Oracle Database SE2 上で実行することが認定されていることを確認します。ソフトウェアベンダー、開発者に直接確認、またはアプリケーションドキュメントを参照します。 | アプリ開発者、DBA、アプリ所有者 | | EE 機能の使用状況をデータベースで直接調査します。 | EE 機能の使用を確認するには、以下のいずれかを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replatform-oracle-database-enterprise-edition-to-standard-edition-2-on-amazon-rds-for-oracle.html) | アプリ所有者、DBA、アプリ開発者 | | 運用アクティビティの EE 機能の用途を特定します。 | データベースまたはアプリケーション管理者は、運用アクティビティの EE のみの機能に頼る場合があります。一般的な例には、オンライン保守アクティビティ (インデックスの再構築、テーブルの移動) 、バッチジョブによる並列処理の使用などがあります。このような依存関係は、できる限り操作を変更することで軽減できます。これらの機能の用途を特定し、コストと利点の比較に基づき決定します。[Oracle Database EE と SE2 の機能の比較](https://docs.aws.amazon.com/prescriptive-guidance/latest/evaluate-downgrading-oracle-edition/compare-features.html)表をガイドとして使用して、Oracle Database SE2 で使用できる機能を特定します。 | アプリ開発者、DBA、アプリ所有者 | | EE Oracle データベースのワークロードパターンを確認します。 | Oracle Database SE2 は、いつでも使用量を最大 16 の CPU スレッドに自動的に制限します。お使いの Oracle EE データベースに Oracle Diagnostic Pack の使用ライセンスが付与されている場合は、自動ワークロードリポジトリ (AWR) ツールまたは DBA\$1HIST\$1\$1 ビューを使用してデータベースのワークロードパターンを分析し、SE2 にダウングレードしたときに 16 CPU スレッドの最大制限がサービスレベルに悪影響を及ぼすかどうかを判断します。評価は、処理が日末、月末、または年末など、アクティビティのピーク期間を対象とするようにします。 | アプリ所有者、DBA、アプリ開発者 | ### AWS にターゲットインフラストラクチャを準備する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ネットワークインフラストラクチャをデプロイして設定します。 | [仮想プライベートクラウド (VPC) とサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)、[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)、[ネットワークアクセスコントロールリスト](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)を作成します。 | AWS 管理者、クラウドアーキテクト、ネットワーク管理者、DevOps エンジニア | | Amazon RDS for Oracle SE2 データベースをプロビジョニングします。 | ターゲットの [Amazon RDS for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.Oracle.html) SE2 データベースをプロビジョニングして、アプリケーションのパフォーマンス、可用性、セキュリティ要件を満たします。本稼働のワークロードにはマルチ AZ 設定をお勧めします。ただし、移行パフォーマンスを向上させるため、[マルチ AZの有効化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/create-multi-az-db-cluster.html)をデータ移行後まで延期できます。 | クラウド管理者、クラウドアーキテクト、DBA、DevOps エンジニア、AWS 管理者 | | Amazon RDS 環境をカスタマイズします。 | カスタム[パラメータ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)と[オプション](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithOptionGroups.html)を設定し、追加[監視](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MonitoringOverview.html)を有効化します。詳細については、[Amazon RDS for Oracle に移行するためのベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/best-practices.html)を参照してください。 | AWS 管理者、AWS システム管理者、クラウド管理者、DBA、クラウドアーキテクト | ### 移行ドライラン、アプリケーションテストを実行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データを移行 (ドライラン) します。 | 特定の環境に最適なアプローチを使用して、ソース Oracle EE データベースから Amazon RDS for Oracle SE2 データベースインスタンスにデータを移行します。サイズ、複雑性、使用可能ダウンタイムウィンドウなどの要因に基づき移行戦略を選択します。次のいずれか、または組み合わせを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replatform-oracle-database-enterprise-edition-to-standard-edition-2-on-amazon-rds-for-oracle.html) | DBA | | ターゲットデータベースを検証します。 | データベースストレージとコードオブジェクトの移行後の検証を実行します。移行ログを確認し、特定された問題を修正します。詳細については、ガイド [AWS クラウドへの Oracle データベースの移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/best-practices.html#post-import)を参照してください。 | DBA | | アプリケーションをテストします。 | アプリケーション管理者およびデータベース管理者は、機能テスト、パフォーマンステスト、運用テストを適宜実施する必要があります。詳細については、[Amazon RDS for Oracle に移行するためのベストプラクティス](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/best-practices.html#test-migration)を参照してください。最後に、ステークホルダーからテスト結果の承認を得ます。 | アプリ開発者、アプリ所有者、DBA、移行エンジニア、移行リード | ### カットオーバー | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Oracle データベース EE からのデータをリフレッシュします。 | アプリケーションの可用性要件に基づきデータのリフレッシュ方法を選択します。詳細については、[AWS への Oracle Database の移行戦略](https://docs.aws.amazon.com/whitepapers/latest/strategies-migrating-oracle-db-to-aws/data-migration-methods.html)の移行方法を参照してください。例えば、継続的なレプリケーションを搭載した Oracle GoldenGate または AWS DMS などのツールを使用して、ダウンタイムほぼゼロを達成できます。ダウンタイム期間が許可する場合は、Oracle Data Pump またはオリジナルのエクスポート/インポートユーティリティなどのオフラインメソッドを使用して、最終データカットオーバーを実行できます。 | アプリ所有者、カットオーバーリード、DBA、移行エンジニア、移行リード | | アプリケーションをターゲットデータベースインスタンスにポイントします。 | Amazon RDS for Oracle SE2 データベースを指すアプリケーションと他のクライアントの接続パラメータを更新します。 | アプリ開発者、アプリ所有者、移行エンジニア、移行リード、カットオーバーリード | | 移行後のアクティビティを実行します。 | マルチ AZ の有効化、データ検証、その他のチェックなど、データ移行後のタスクを実行します。 | DBA、移行エンジニア | | カットオーバー後の監視を実行します。 | [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/monitoring-cloudwatch.html)、[Amazon RDS Performance Insights](https://aws.amazon.com/rds/performance-insights/) などのツールを使用して Amazon RDS for Oracle SE2 データベースを監視します。 | アプリ開発者、アプリ所有者、AWS 管理者、DBA、移行エンジニア | ## 関連リソース **AWS 規範ガイダンス** + 「[AWS クラウドへの Oracle データベースの移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/welcome.html)」 (ガイド) + [Oracle データベースの標準エディション 2 へのダウングレードを評価する](https://docs.aws.amazon.com/prescriptive-guidance/latest/evaluate-downgrading-oracle-edition/welcome.html)（ガイド） + [オンプレミス Oracle データベースを Amazon RDS for Oracle へ移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle.html?did=pg_card&trk=pg_card) (パターン) + [Oracle Data Pump を使用してオンプレミス Oracle データベースを Amazon RDS for Oracle へ移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle-using-oracle-data-pump.html?did=pg_card&trk=pg_card) (パターン) **ブログ記事** + [AWS DMS を使用したダウンタイムほぼゼロでの Oracle データベースの移行](https://aws.amazon.com/blogs/database/migrating-oracle-databases-with-near-zero-downtime-using-aws-dms/) + [Amazon RDS for Oracle を使用した Oracle SE のパフォーマンス管理の分析](https://aws.amazon.com/blogs/database/analyzing-performance-management-in-oracle-se-using-amazon-rds-for-oracle/) + [Amazon RDS for Oracle による Oracle SE の SQL 計画の管理](https://aws.amazon.com/blogs/database/managing-your-sql-plan-in-oracle-se-with-amazon-rds-for-oracle/) + [Oracle 標準エディションでのテーブルパーティションの実装: パート 1](https://aws.amazon.com/blogs/database/implementing-table-partitioning-in-oracle-standard-edition-part-1/) # Precisely Connect を使用してメインフレームデータベースを AWS にレプリケート *Lucio Pereira、Sayantan Giri、Balaji Mohan、Amazon Web Services* ## 概要 このパターンでは、Precisely Connect を使用してメインフレームデータベースから Amazon データストアにほぼリアルタイムでデータをレプリケーションする手順の概要を示しています。Amazon Managed Streaming for Apache Kafka (Amazon MSK) によるイベントベースのアーキテクチャと、クラウド内のカスタムデータベースコネクタを実装して、スケーラビリティ、耐障害性、パフォーマンスを向上させます。 Precisely Connect は、従来のメインフレームシステムからデータをキャプチャしてクラウド環境に統合するレプリケーションツールです。データは、低レイテンシーで高スループットの異種データパイプラインによるほぼリアルタイムのメッセージフローを使用して、変更データキャプチャ (CDC) を通じてメインフレームから AWS に複製されます。  このパターンには、マルチリージョンのデータ複製とフェールオーバールーティングによる回復力のあるデータパイプラインの災害復旧戦略も含まれます。 ## 前提条件と制限 **前提条件** + AWS クラウドに複製する既存のメインフレームデータベース (IBM DB2、IBM 情報管理システム (IMS)、仮想ストレージアクセスメソッド (VSAM) など) + アクティブなAWS[アカウント](https://aws.amazon.com/account/) + 企業環境から AWS への [AWS Direct Connect](https://aws.amazon.com/directconnect/) または [AWS 仮想プライベートネットワーク (AWS VPN)](https://aws.amazon.com/vpn/) + レガシープラットフォームからアクセス可能なサブネットを備えた[仮想プライベートクラウド](https://aws.amazon.com/vpc/) ## アーキテクチャ **ソーステクノロジースタック** 次のデータベースのうち少なくとも 1 つを含むメインフレーム環境 + IBM IMS データベース + IBM DB2 データベース + VSAM ファイル **ターゲットテクノロジースタック** + Amazon MSK + Amazon Elastic Kubernetes Service (Amazon EKS) と Amazon EKS Anywhere + Docker + 次のような AWS リレーショナルまたは NoSQL データベース： + Amazon DynamoDB + Oracle の Amazon Relational Database Service (Amazon RDS)、Amazon RDS for PostgreSQL、または Amazon Aurora + Amazon ElastiCache for Redis + Amazon Keyspaces (Apache Cassandra 向け) **ターゲット アーキテクチャ** *メインフレームデータの AWS データベースへのレプリケーション* 次の図表では、メインフレームデータを DynamoDB、Amazon RDS、Amazon ElastiCache、Amazon Keyspaces などの AWS データベースに複製する方法を示しています。レプリケーションは、オンプレミスのメインフレーム環境では Precisely Capture and Publisher を使用し、オンプレミスの分散環境の Amazon EKS Anywhere では Precisely Dispatcher を使用し、AWS クラウドでは Precisely Apply Engine とデータベースコネクタを使用して、ほぼリアルタイムで行われます。  ![\[メインフレームデータの AWS データベースへのレプリケーション\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/17ac53b7-86d5-4a8c-a55f-56b6338a1af3/images/777dd7da-48ed-4510-b8fa-9041be042671.png) この図表は、次のワークフローを示しています: 1. Precisely Capture は CDC ログからメインフレームデータを取得し、そのデータを内部の一時ストレージに保持します。 1. Precisely Publisher は内部データストレージの変更を監視し、TCP/IP 接続を介して CDC レコードを Precisely Dispatcher に送信します。 1. Precisely Dispatcher はパブリッシャーから CDC レコードを受信し、Amazon MSK に送信します。発送者は、ユーザー設定と複数のワーカータスクに基づいて Kafka キーを作成し、データを平行でプッシュします。レコードが Amazon MSK に保存されると、発想者はパブリッシャーに確認応答を送り返します。 1. Amazon MSK は CDC レコードをクラウド環境に保持します。トピックのパーティションサイズは、使用するトランザクション処理システム (TPS) のスループット要件によって異なります。Kafka キーは、さらなる変換やトランザクションの順序付けには必須です。 1. Precisely Apply Engine は Amazon MSK からの CDC レコードを受信し、ターゲットデータベースの要件に基づいてデータを (フィルタリングやマッピングなどによって) 変換します。Precisely SQD スクリプトにはカスタマイズされたロジックを追加できます。(SQD は Precisely 独自の言語です)。Precisely Apply エンジンは、各 CDC レコードを Apache Avro または JSON 形式に変換し、要件に基づいてさまざまなトピックに配信します。 1. ターゲット Kafka トピックは、ターゲットデータベースに基づいて複数のトピックの CDC レコードを保持し、Kafka は定義済みの Kafka キーに基づいてトランザクションの順序付けを容易にします。パーティションキーは対応するパーティションと連動し、順次処理をサポートします。  1. データベースコネクタ (カスタマイズされた Java アプリケーション) は Amazon MSK の CDC レコードを受信し、ターゲットデータベースに保存します。 1. 要件に基づいて、ターゲットデータベースを選択できます。このパターンでは NoSQL データベースとリレーショナルデータベースをサポートします。 ディザスタリカバリ ビジネス継続性は組織の成功の鍵です。AWS クラウドは高可用性 (HA) とディザスタリカバリ (DR) を実現する機能を提供し、組織のフェイルオーバープランとフォールバックプランをサポートします。このパターンでは、アクティブ/パッシブの DR 戦略に従い、RTO と RPO の要件を満たす DR 戦略を実装するための大まかなガイダンスを提供します。 次の図は、 のワークフローです。 ![\[メインフレームデータを AWS に複製するためのディザスタリカバリワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/17ac53b7-86d5-4a8c-a55f-56b6338a1af3/images/9cccba7a-7a25-411e-829f-7cd5a7a20ab4.png) 図に示す内容は以下のとおりです。 1. AWS リージョン 1 で障害が発生した場合、半自動フェイルオーバーが必要です。リージョン 1 で障害が発生した場合、システムは Precisely Dispatcher をリージョン 2 に接続するためのルーティング変更を開始する必要があります。  1. Amazon MSK はリージョン間のミラーリングを通じてデータを複製します。そのため、フェイルオーバー時には、リージョン 2 の Amazon MSK クラスターをプライマリリーダーに昇格させる必要があります。  1. Precisely Apply Engine とデータベースコネクタは、どのリージョンでも動作するステートレスアプリケーションです。  1. データベースの同期は、ターゲットデータベースによって異なります。例えば、DynamoDB はグローバルテーブルを使用でき、ElastiCache はグローバルデータストアを使用できます。 *データベースコネクタによる低レイテンシーで高スループットの処理* このパターンでは、データベースコネクタが重要なコンポーネントです。コネクタはリスナーベースのアプローチに従い、Amazon MSK からデータを収集し、ミッションクリティカルなアプリケーション (階層 0 と 1) の高スループットで低レイテンシーの処理を通じてトランザクションをデータベースに送信します。次の図は、このプロセスを示したものです。 ![\[データベースコネクタを使用して AWS でメインフレームデータを複製\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/17ac53b7-86d5-4a8c-a55f-56b6338a1af3/images/79479634-becb-4212-bbfc-1a3b17ae1bed.png) このパターンでは、マルチスレッド処理エンジンを通じてシングルスレッドで消費するカスタマイズされたアプリケーションの開発をサポートします。 1. コネクタのメインスレッドは Amazon MSK の CDC レコードを消費し、スレッドプールに送信して処理します。 1. スレッドプールのスレッドは CDC レコードを処理し、ターゲットデータベースに送信します。 1. すべてのスレッドがビジー状態の場合、CDC レコードはスレッドキューによって保留されます。 1. メインスレッドは、スレッドキューからすべてのレコードがクリアされるのを待って、Amazon MSK にオフセットをコミットします。 1. 子スレッドは障害を処理します。処理中に障害が発生した場合、失敗したメッセージは DLQ (デッドレターキュー) トピックに送信されます。 1. 子スレッドは、メインフレームのタイムスタンプに基づいて条件付き更新 (DynamoDB ドキュメントの[条件式](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html) を参照) を初期化し、データベースの重複や順序の狂った更新を回避します。 マルチスレッド機能を備えた Kafka コンシューマーアプリケーションを実装する方法については、Confluent ウェブサイトのブログ投稿[Apache Kafka コンシューマーによるマルチスレッドメッセージ消費](https://www.confluent.io/blog/kafka-consumer-multi-threaded-messaging/) を参照してください。 ## ツール **AWS サービス** + 「[Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html)」 は、Apache Kafka を使ってストリーミングデータを処理するアプリケーションを、構築および実行することを支援するフルマネージドサービスです。 + [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) は、 で Kubernetes を実行する際に役立ちます。独自の Kubernetes コントロールプレーンまたはノードをインストールおよび維持する必要はありません。 + [Amazon EKS Anywhere](https://anywhere.eks.amazonaws.com/docs/) を使用すると、自社のデータセンターで実行される Kubernetes クラスターをデプロイ、使用、管理できます。 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。 + [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/) は、AWS クラウドのインメモリ分散キャッシュ環境のセットアップ、管理、スケーリングに役立ちます。 + [Amazon Keyspaces (Apache Cassandra に向け)](https://docs.aws.amazon.com/keyspaces/latest/devguide/what-is-keyspaces.html) は、AWS クラウドの Cassandra ワークロードの移行、実行、スケーリングを支援するマネージド型データベースサービスです。 その他のツール + [Precisely Connect](https://www.precisely.com/product/precisely-connect/connect) は、VSAMデータセットやIBMメインフレームデータベースなどの従来のメインフレームシステムのデータを次世代のクラウドおよびデータプラットフォームに統合します。 ## ベストプラクティス + 最適なパフォーマンスとコストのバランスを取るために、Kafka パーティションとマルチスレッドコネクタの最適な組み合わせを検出します。Precisely Capture インスタンスと Dispatcher インスタンスが複数あると、MIPS (1 秒あたり百万命令) の消費量が増えるため、コストが増加する可能性があります。 + データ操作や変換のロジックをデータベースコネクタに追加しません。そのためには、マイクロ秒単位の処理時間を実現する Precisely Apply エンジンを使用します。 + 接続を頻繁にウォームアップして待ち時間を短縮するために、データベースコネクターでデータベースへのリクエストまたはヘルスチェックコール (*ハートビート*) を定期的に作成します。 + スレッドプール検証ロジックを実装して、スレッドキュー内の保留中のタスクを把握し、すべてのスレッドが完了するまで待ってから次の Kafka ポーリングを行います。これにより、ノード、コンテナ、またはプロセスがクラッシュした場合にデータが失われることを回避します。 + ヘルスエンドポイントを通じてレイテンシーメトリクスを公開し、ダッシュボードやトレースメカニズムを通じてオブザーバビリティ機能を強化します。 ## エピック ### ソース環境 (オンプレミス) の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メインフレームプロセス (バッチまたはオンラインユーティリティ) を設定して、メインフレームデータベースから CDC プロセスを開始します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | メインフレームエンジニア | | メインフレームデータベースのログストリームを有効にします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | メインフレーム DB スペシャリスト | | キャプチャーコンポーネントを使用して CDC レコードをキャプチャします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | メインフレームエンジニア、Precisely Connect SME | | キャプチャコンポーネントをリッスンするようにパブリッシャーコンポーネントを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | メインフレームエンジニア、Precisely Connect SME | | オンプレミスの分散環境で Amazon EKS Anywhere をプロビジョニングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | DevOps エンジニア | | 発想者コンポーネントを分散環境にデプロイして設定し、AWS クラウドにトピックを公開します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | DevOpsエンジニア、Precisely Connect SME | ### ターゲット環境 (AWS) の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 指定された AWS リージョンに Amazon EKS クラスターをプロビジョニングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | DevOps エンジニア、ネットワーク管理者 | | MSK クラスターをプロビジョニングし、該当する Kafka トピックを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | DevOps エンジニア、ネットワーク管理者 | | レプリケーションされた Kafka トピックを聞くように Apply Engine コンポーネントを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | Precisely Connect SME | | AWS クラウドで DB インスタンスをプロビジョニングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | データエンジニア、DevOps エンジニア | | Apply Engine が公開するトピックを聞くためのデータベースコネクタを設定してデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | アプリ開発者、クラウドアーキテクト、データエンジニア | ### 事業継続とディザスタリカバリの設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ビジネスアプリケーションのディザスタリカバリの目標を定義します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | クラウドアーキテクト、データエンジニア、アプリオーナー | | 定義した RTO/RPO に基づいてディザスタリカバリ戦略を設計します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | クラウドアーキテクト、データエンジニア | | ディザスタリカバリのクラスタと構成をプロビジョニングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | DevOpsエンジニア、ネットワーク管理者、クラウドアーキテクト | | ディザスタリカバリ の CDC パイプラインをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/replicate-mainframe-databases-to-aws-by-using-precisely-connect.html) | アプリオーナー、データエンジニア、クラウドアーキテクト | ## 関連リソース 「**AWS リソース**」 + [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) + [Amazon DynamoDB による条件式](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html) + [Amazon EKS](https://docs.aws.amazon.com/eks/index.html) + [Amazon EKS Anywhere](https://anywhere.eks.amazonaws.com/docs/) + [Amazon ElasticCache](https://docs.aws.amazon.com/elasticache/index.html) + [Amazon Keyspaces](https://docs.aws.amazon.com/keyspaces/?icmpid=docs_homepage_databases) + [Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/getting-started.html) + [Amazon RDS と Amazon Aurora](https://docs.aws.amazon.com/rds/index.html) + [Amazon VPC](https://docs.aws.amazon.com/vpc/index.html) **Precisely Connect リソース** + [Precisely Connect の概要](https://www.precisely.com/product/precisely-connect/connect) + [Precisely Connect による変更データキャプチャ](https://help.precisely.com/r/Connect-CDC-SQData/4.1/en-US/Connect-CDC-SQData-Installation/Connect-CDC-SQData-Architecture) **コンフルエントリソース** + [Apache Kafka コンシューマーによるマルチスレッドメッセージ消費](https://www.confluent.io/blog/kafka-consumer-multi-threaded-messaging/) # Lambda と Secrets Manager を使用して Amazon RDS for PostgreSQL と Aurora PostgreSQL のジョブをスケジュールする *Yaser Raja、Amazon Web Services* ## 概要 オンプレミスデータベースと Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされているデータベースの場合、データベース管理者は **cron** ユーティリティを使用してジョブをスケジュールすることがよくあります。 例えば、データ抽出用のジョブやデータ消去用のジョブは、**cron** を使用して簡単にスケジュールできます。これらのジョブでは、通常、データベースの認証情報はハードコーディングされるか、プロパティファイルに保存されます。ただし、Amazon Relational Database Service (Amazon RDS) または Amazon Aurora PostgreSQL 互換エディションに移行すると、ホストインスタンスにログインして **cron** ジョブをスケジュールすることができなくなります。  このパターンでは、 AWS Lambda と を使用して AWS Secrets Manager 、移行後に Amazon RDS for PostgreSQL および Aurora PostgreSQL 互換データベースのジョブをスケジュールする方法について説明します。  ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換データベース **制限** + ジョブは Lambda 関数のタイムアウト制限である 15 分以内に完了する必要があります。その他の制限については、[AWS Lambda のドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/limits.html)をご覧ください。 + Job コードは [Lambda がサポートする言語](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)で記述する必要があります。 ## アーキテクチャ **ソーステクノロジースタック** このスタックには、Bash、Python、Java などの言語で記述されたジョブが含まれています。データベースの認証情報はプロパティファイルに保存され、ジョブは Linux **cron** を使用してスケジュールされます。 **ターゲットテクノロジースタック** このスタックには、Secrets Manager に保存されている認証情報を使用してデータベースに接続し、アクティビティを実行する Lambda 関数があります。Lambda 関数は、Amazon CloudWatch Events を使用してスケジュールされた間隔で開始されます。 **ターゲットアーキテクチャ** ![\[RDS DB インスタンスのジョブをスケジュールする Lambda 関数を開始する CloudWatch イベント。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8e0d1c90-0599-4909-a800-26a89b87f686/images/61f9ca34-9157-4565-96ba-5234d389ac2a.png) ## ツール + [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) は、 AWS リソースの変更を記述するシステムイベントのほぼリアルタイムのストリームを提供します。すぐに設定できる簡単なルールを使用して、ルールに一致したイベントを 1 つ以上のターゲット関数またはストリームに振り分けることができます。CloudWatch Events が発生すると、運用上の変更が認識されます。オペレーションの変更に応答し、必要に応じて、応答メッセージを環境に送り、機能をアクティブ化し、変更を行い、状態情報を収集することによって、修正アクションを実行します。CloudWatch Events を使用して、**cron式** や **rate式**により特定の時間に自己トリガーする自動アクションをスケジュールすることもできます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) はサーバーのプロビジョニングや管理をする必要がなく、コードを実行できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。使用したコンピューティング時間に対してのみお支払いいただきます- コードが実行中でなければ料金はかかりません。Lambda を使用すれば、実質どのようなタイプのアプリケーションやバックエンドサービスでも管理を必要とせずに実行できます。Lambda は、高可用性コンピューティングインフラストラクチャ上でコードを実行し、サーバーとオペレーティングシステムのメンテナンス、容量のプロビジョニングと自動スケーリング、コードのモニタリング、ロギングを含むすべてのコンピューティングリソースを管理します。必要なのは、[Lambda がサポートする言語](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)のいずれかでコードを提供することのみです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、アプリケーション、サービス、および IT リソースへアクセスするためのシークレットの保護に役立ちます。データベース認証情報、API キー、その他のシークレットをライフサイクル全体にわたって簡単にローテーション、管理、取得できます。ユーザーとアプリケーションは Secrets Manager API を呼び出してシークレットを取得するため、機密情報をプレーンテキストでハードコーディングする必要がなくなります。Secrets Manager には、Amazon RDS、Amazon Redshift、Amazon DocumentDB の統合機能が組み込まれたシークレットローテーションが用意されています。このサービスは API キーや OAuth トークンなど、他のタイプのシークレットにも拡張できます。Secrets Manager を使用すると、きめ細かなアクセス許可を使用してシークレットへのアクセスを制御し、シークレットローテーションを一元的に監査して AWS クラウド、、サードパーティーのサービス、オンプレミスのリソースを監査できます。 ## エピック ### Secrets Manager にデータベース認証情報を保存する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数用のデータベースユーザーを作成します。 | アプリケーションのさまざまな部分に別々のデータベースユーザーを使用することをお勧めします。cron ジョブ用に別のデータベースユーザーが既に存在する場合は、そのユーザーを使用してください。それ以外の場合は、新しいデータベースユーザーを作成します。詳細については、[PostgreSQL ユーザーとロールの管理](https://aws.amazon.com/blogs/database/managing-postgresql-users-and-roles/)」(AWS ブログ記事) を参照してください。 | DBA | | Secrets Manager でデータベース認証情報をシークレットとして保存します。 | 「[AWS Secrets Manager データベースシークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_database_secret.html)」(Secrets Manager ドキュメント) の指示に従います。 | DevOps、DBA | ### Lambda 関数のコードを作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda がサポートするプログラミング言語を選択してください。 | サポートされている言語のリストについては、「[Lambda ランタイム](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)」(Lambda ドキュメント) を参照してください。 | 開発者 | | Secrets Manager からデータベース認証情報を取得するロジックを記述します。 | サンプルコードについては、「 [を使用して Lambda 関数にデータベース認証情報を安全に提供する方法 AWS Secrets Manager](https://aws.amazon.com/blogs/security/how-to-securely-provide-database-credentials-to-lambda-functions-by-using-aws-secrets-manager/)」(AWS ブログ記事) を参照してください。 | 開発者 | | スケジュールされたデータベースアクティビティを実行するロジックを記述します。 | オンプレミスで使用しているスケジューリングジョブの既存のコードを Lambda 関数に移行します。詳細については、「[Lambda 関数のデプロイ](https://docs.aws.amazon.com/lambda/latest/dg/lambda-deploy-functions.html)」(Lambda ドキュメント) を参照してください。 | 開発者 | ### コードをデプロイして Lambda 関数を作成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数デプロイパッケージを作成します。 | このパッケージには、コードとその依存関係が含まれます。詳細については、「[デプロイパッケージ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html)」(Lambda ドキュメント) を参照してください。 | 開発者 | | Lambda 関数の作成 | Lambda コンソールで、**[関数の作成]** を選択し、関数名を入力し、ランタイム環境を選択して、**[関数の作成]** を選択します。 | DevOps | | デプロイパッケージをアップロードする | 作成した Lambda 関数を選択し、設定を開きます。コードをコードセクションに直接記述することも、デプロイパッケージをアップロードすることもできます。パッケージをアップロードするには、**[Function code]** セクションに移動し、**[コードエントリタイプ]** を選択して.zip ファイルをアップロードし、パッケージを選択します。 | DevOps | | Lambda 関数を要件に合わせて設定します。 | 例えば、**Timeout** パラメータを Lambda 関数にかかると予想される時間に設定できます。詳細については、「[関数オプションの設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html) (Lambda ドキュメント)」を参照してください。 | DevOps | | Lambda 関数ロールが Secrets Manager にアクセスするためのアクセス権限を設定します。 | 手順については、[「 AWS Lambda 関数でシークレットを使用する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)」(Secrets Manager ドキュメント) を参照してください。 | DevOps | | Lambda 関数をテストします。 | Lambda 関数を手動で開始して、期待どおりに機能することを確認します。 | DevOps | ### CloudWatch イベントを使用して Lambda 関数をスケジュールします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数をスケジュールに従って実行するルールを作成します。 | CloudWatch イベントを使用して Lambda 関数をスケジュールします。手順については、「[Schedule Lambda functions using CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html)」(CloudWatch イベントチュートリアル) を参照してください。 | DevOps | ## 関連リソース + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) + [Lambda の使用開始](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) + [イベントでトリガーする CloudWatch Events のルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) + [AWS Lambda 制限](https://docs.aws.amazon.com/lambda/latest/dg/limits.html) + [サーバーレスアプリケーションから AWS データベースをクエリする](https://aws.amazon.com/blogs/database/query-your-aws-database-from-your-serverless-application/) (ブログ記事) # オンプレミスの SMTP サーバーとデータベースメールを使用して、Amazon RDS for SQL Server データベースインスタンスに通知を送信します。 *Amazon Web Services、Nishad Mankar* ## 概要 「[データベースメール](https://learn.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail?view=sql-server-ver16)」 (Microsoft ドキュメント) は、簡易メール転送プロトコル (SMTP) サーバーを使用して Microsoft SQL Server データベースから通知や警告などの電子メールメッセージを送信します。Microsoft SQL Server 用 Amazon Relational Database Service (Amazon RDS) のドキュメントには、Amazon Simple Email Service (Amazon SES) をデータベースメールの SMTP サーバーとして使用する方法が記載されています。詳細については、「[Amazon RDS for SQL Server でのデータベースメールの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.DBMail.html)」を参照してください。代替設定として、このパターンでは、オンプレミスの SMTP サーバーをメールサーバーとして使用して Amazon RDS for SQL Server データベース (DB) インスタンスから E メールを送信するようにデータベースメールを設定する方法を説明します。 ## 前提条件と制限 **前提条件** + アクティブなAWS アカウント + SQL Server のスタンダードエディションまたはエンタープライズエディションを実行する Amazon RDS DB インスタンス + オンプレミスの SMTP サーバーの IP アドレスまたはホスト名 + SMTP サーバーの IP アドレスから Amazon RDS for SQL Server DB インスタンスへの接続を許可するインバウンド 「[セキュリティグループルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#working-with-security-group-rules)」 + オンプレミスネットワークと Amazon RDS DB インスタンスを含む仮想プライベートクラウド (VPC) 間の接続 (「[AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)」 接続など) 機能制限 + SQL Server のエクスプレスエディションはサポートされていません。 + 制限に関する詳細については、Amazon RDS ドキュメントの *Amazon RDS for SQL Server Database Mail の使用*に関する「[制限](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureSupport.Limits)」を参照してください。 製品バージョン + 「[RDS でサポートされる SQL Server バージョン](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport)」 のスタンダードエディションとエンタープライズエディション ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon RDS for SQL Server データベースインスタンス + Amazon Route 53 転送ルール + データベースメール + オンプレミスの SMTP サーバー + Microsoft SQL Server Management Studio (SSMS) **ターゲットアーキテクチャ** 次の図は、このパターンのターゲットアーキテクチャを示しています。データベースインスタンスに関する通知またはアラートを開始するイベントまたはアクションが発生すると、Amazon RDS for SQL Server はデータベースメールを使用して E メール通知を送信します。データベースメールはオンプレミスの SMTP サーバーを使用して E メールを送信します。 ![\[Amazon RDS for SQL Server は、オンプレミスの SMTP サーバーを使用してユーザーに E メール通知を送信します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e5599724-43cf-4fe1-8c5a-8fca1a424993/images/47efb12f-3505-4a60-ac43-194a176e71c8.png) ## ツール AWS サービス + 「[Microsoft SQL サーバーの Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html)」 を使用して、AWS クラウドで SQL サーバーリレーショナルデータベースをセット、運用、スケーリングすることを支援します。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 その他のツール + 「[データベースメール](https://learn.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail)」 は、通知やアラートなどの E メールメッセージを SQL Server データベースエンジンからユーザーに送信するツールです。 + 「[Microsoft SQL Server Management Studio (SSMS)](https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-ssms)」 は、SQL Server コンポーネントへのアクセス、設定、管理など、SQL Server を管理するためのツールです。このパターンでは、SSMS を使用して SQL コマンドを実行し、Amazon RDS for SQL Server DB インスタンスにデータベースメールを設定します。  ## エピック ### オンプレミスの SMTP サーバーとのネットワーク接続を有効にします。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | RDS DB インスタンスからマルチ AZ を削除します。 | マルチゾーン RDS DB インスタンスを使用している場合は、マルチ AZ インスタンスをシングル AZ インスタンスに変換します。データベースメールの設定が完了したら、DB インスタンスをマルチ AZ 配置に戻します。次に、プライマリノードとセカンダリノードの両方に、データベースメールの設定が実行します。説明については、「[Microsoft SQL Server DB インスタンスからのマルチ AZ の削除](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html#USER_SQLServerMultiAZ.Removing)」 を参照してください。 | DBA | | Amazon RDS エンドポイントまたは IP アドレスの許可リストを、オンプレミスの SMTP サーバー上に作成します。 | SMTP サーバーは AWS ネットワークの外部にあります。オンプレミスの SMTP サーバーで、Amazon RDS インスタンスまたは Amazon RDS でホストされている Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのアウトバウンドエンドポイントまたは IP アドレスと通信することを許可する許可リストを作成します。この手順は組織によって異なります。DB インスタンスエンドポイントの詳細については、「[DB インスタンスのエンドポイントとポート番号の検索](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.html#sqlserver-endpoint)」 を参照してください。 | DBA | | ポート 25 の制限を解除します。 | デフォルトでは、AWS は EC2 インスタンスのポート 25 を制限します。ポート 25 の制限を解除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.html) | AWS 全般 | | Route 53 ルールを追加して、SMTP サーバーの DNS クエリを解決します。 | Route 53 を使用して、AWS リソースとオンプレミスの SMTP サーバー間の DNS クエリを解決します。DNS クエリを SMTP サーバードメイン (`example.com` など) に転送するルールを作成する必要があります。手順については、Route 53 ドキュメントの 「[転送ルールの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html#resolver-rules-managing-creating-rules)」 を参照してください。 | ネットワーク管理者 | ### Amazon RDS for SQL Server DB インスタンスでのデータベースメールのセットアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | データベースメールを有効化します。 | データベースメールのパラメータグループを作成し、`database mail xps` パラメータを `1` に設定し、データベースメールパラメータグループをターゲット RDS DB インスタンスに関連付けます。手順については、Amazon RDS ドキュメントの 「[データベースメールの有効化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.DBMail.html#SQLServer.DBMail.Enable)」 を参照してください。この説明の「*データベースメールの設定*」セクションには進まないでください。オンプレミスの SMTP サーバーの設定は Amazon SES とは異なります。 | DBA | | DB インスタンスに接続します。 | 踏み台ホストから、Microsoft SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server データベースインスタンスに接続します。説明については、「[Microsoft SQL Server データベースエンジンを実行する DB インスタンスに接続する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.html)」 を参照してください。エラーが発生した場合は、「[関連リソース](#send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail-resources)」 セクションの「接続トラブルシューティングに関する参考資料」を参照してください。 | DBA | | プロファイルを作成します。 | SSMS で、以下の SQL ステートメントを入力してデータベースメールプロファイルを作成します。以下の値を置き換えます:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.html)このストアドプロシージャとその引数の詳細については、Microsoft のドキュメントの 「[sysmail\$1add\$1profile\$1sp](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profile-sp-transact-sql)」 を参照してください。
EXECUTE msdb.dbo.sysmail_add_profile_sp
 @profile_name = 'SQL Alerts profile',
 @description = 'Profile used for sending outgoing notifications using OM SMTP Server.';
| DBA | | プリンシパルをプロファイルに追加します。 | 次の SQL ステートメントを入力して、パブリック・プリンシパルまたはプライベート・プリンシパルをデータベース・メール・プロファイルに追加します。*プリンシパル* は、SQL Server リソースをリクエストできるエンティティです。以下の値を置き換えます:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.html)このストアドプロシージャとその引数の詳細については、Microsoft のドキュメントの 「[sysmail\$1add\$1profile\$1sp](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-principalprofile-sp-transact-sql)」 を参照してください。
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
 @profile_name = 'SQL Alerts profile',
 @principal_name = 'public',
 @is_default = 1 ;
| DBA | | アカウントを作成します。 | 以下の SQL ステートメントを入力して、データベースメールアカウントを作成します。以下の値を置き換えます:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.html)このストアドプロシージャとその引数の詳細については、Microsoft 「[のドキュメントの sysmail\$1add\$1account\$1sp](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-account-sp-transact-sql)」 を参照してください。
EXECUTE msdb.dbo.sysmail_add_account_sp
 @account_name = 'SQL Alerts account',
 @description = 'Database Mail account for sending outgoing notifications.',
 @email_address = 'xyz@example.com',
 @display_name = 'xyz@example.com',
 @mailserver_name = 'test_smtp.example.com',
 @port = 25,
 @enable_ssl = 1,
 @username = 'SMTP-username',
 @password = 'SMTP-password';
| DBA | | プロファイルにアカウントを追加します。 | 以下の SQL ステートメントを入力して、データベースメールアカウントをデータベースメールプロファイルに追加します。以下の値を置き換えます:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.html)このストアドプロシージャとその引数の詳細については、Microsoft のドキュメントの 「[sysmail\$1add\$1profileaccount\$1sp](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profileaccount-sp-transact-sql)」 を参照してください。
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
 @profile_name = 'SQL Alerts profile',
 @account_name = 'SQL Alerts account',
 @sequence_number = 1;
| DBA | | (オプション) RDS DB インスタンスにマルチ AZ を追加します。 | マルチ AZ をデータベースミラーリング (DBM) または AlwaysOn 可用性グループ (AG) で追加する場合は、「[Microsoft SQL Server DB インスタンスへのマルチ AZ の追加](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html#USER_SQLServerMultiAZ.Adding)」 を参照してください。 | DBA | ## 関連リソース + 「[Amazon RDS for SQL Server でのデータベースメールの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.DBMail.html)」 (Amazon RDS ドキュメント) + 「[添付ファイルの処理](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.DBMail.html#SQLServer.DBMail.MAZ)」 (Amazon RDS ドキュメント) + 「[SQL Server DB インスタンスへのトラブルシューティング接続](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.html#USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting)」 (Amazon RDS ドキュメント) + 「[Amazon RDS DB インスタンス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Connecting)」に接続できない (Amazon RDS ドキュメント) # AWS の IBM Db2 に SAP のディザスタリカバリをセットアップ *Amazon Web Services、Ambarish Satarkar、Debasis Sahoo* ## 概要 このパターンでは、Amazon Web Services（AWS）クラウドで稼働する IBM Db2 をデータベースプラットフォームとして使用する、SAP ワークロードのディザスタリカバリ（DR）システムをセットアップする手順の概要を示します。目的は、ディザスタが発生した場合でも、事業を継続できる低コストのソリューションを提供することです。 このパターンでは、「[パイロットライト方式](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)」 を使用します。AWS にパイロットライト DR を実装することで、ダウンタイムを削減し、ビジネスの継続性を維持できます。パイロットライトアプローチは、SAP システムやスタンバイ Db2 データベースなど、本番環境と同期する最小限の DR 環境を AWS に設定することに重点を置いています。 このソリューションはスケーラブルです。必要に応じて本格的なディザスタリカバリ環境に拡張できます。 ## 前提条件と制限 **前提条件** + レプリケーションインスタンスは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されます。 + IBM Db2 データベース + SAP 製品可用性マトリックス (PAM) が適用されるオペレーティングシステム + 本番データベースホストとスタンバイデータベースホストで異なる物理データベースホスト名 + 各 AWS リージョンでは、「[クロスリージョンレプリケーション (CRR)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)」 が有効になっている Amazon Simple Storage Service (Amazon S3) バケット **製品バージョン** + IBM Db2 データベースバージョン 11.5.7 以降 ## アーキテクチャ **ターゲットテクノロジースタック** + Amazon EC2 + Amazon Simple Storage Service (Amazon S3) + Amazon Virtual Private Cloud (VPC ピアリング) + Amazon Route 53 + IBM Db2 高可用性ディザスタリカバリ (HADR) **ターゲットアーキテクチャ** このアーキテクチャーは、データベースプラットフォームとして Db2 を使用する SAP ワークロード用の DR ソリューションを実装します。本番データベースは AWS リージョン 1 にデプロイされ、スタンバイデータベースは 2 番目のリージョンにデプロイされます。スタンバイデータベースは DR システムを指します。Db2 Database には、複数のスタンバイデータベース (最大 3 つ) が適用されます。Db2 HADR を使用して DR データベースを設定し、本番データベースとスタンバイデータベース間のログ配布を自動化します。 リージョン 1 が使用できなくなるようなディザスタが発生した場合、DR リージョンのスタンバイデータベースが本番データベースの役割を引き継ぎます。SAP アプリケーションサーバーは、目標復旧時間 (RTO) の要件を満たすために、事前に構築することも、「[AWS エラスティックディザスタリカバリ](https://aws.amazon.com/disaster-recovery/)」 や Amazon マシンイメージ (AMI) を使用して構築することもできます。このパターンでは AMI を使用します。 Db2 HADR は、本番がプライマリサーバーとして機能し、すべてのユーザーがそのサーバーに接続されます。本番とスタンバイのセットアップを実装しています。すべてのトランザクションがログファイルに書き込まれ、TCP/IP を使用してスタンバイサーバーに転送されます。スタンバイサーバーは、転送されたログレコードをロールフォワードしてローカルデータベースを更新します。これにより、本番サーバーとの同期が保持されます。 VPC ピアリングは、本番リージョンと DR リージョンのインスタンスが相互に通信できるようにするために使用されます。Amazon Route 53 は、エンドユーザーをインターネットアプリケーションにルーティングします。 ![\[クロスリージョンレプリケーションのAWSのDb2\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/06edfa4c-0827-4d05-95cf-2d2651e74323/images/e77c1e4e-36f3-4af4-89d0-8eec72348f0a.png) 1. リージョン 1 にアプリケーションサーバーの 「[AMI を作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)」し、その AMI をリージョン 2 に「[コピーします](https://repost.aws/knowledge-center/copy-ami-region)」 。ディザスタが発生した場合、AMI を使用してリージョン 2 のサーバーを起動します。 1. 本番データベース (リージョン 1) とスタンバイデータベース (リージョン 2) の間で Db2 HADR レプリケーションを設定します。 1. ディザスタが発生した時、本番インスタンスに合わせて EC2 インスタンスタイプを変更します。 1. リージョン 1 では、`LOGARCHMETH1` が `db2remote: S3 path` に設定されます。 1. リージョン 2 では、`LOGARCHMETH1` が `db2remote: S3 path` に設定されます。 1. クロスリージョンレプリケーションは S3 バケット間で実行されます。 ## ツール ** サービス** + 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。 + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。このパターンでは、「[VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)」を使用します。 ## ベストプラクティス + ネットワークは HADR のレプリケーションモードを決定する上で重要な役割を果たします。AWS リージョン間の DR には、Db2 HADR ASYNC モードまたは SUPERASYNC モードを使用することを推奨します。  + Db2 HADR のレプリケーションモードの詳細については、「[IBM のドキュメント](https://ibm.github.io/db2-hadr-wiki/hadrSyncMode.html#Description_of_the_Modes)」 を参照してください。 + 既存の SAP システムの「[新しい AMI を作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)」するには、AWS マネジメントコンソールまたはAWS コマンドラインインターフェイス (AWS CLI) を使用できます。その後、AMI を使用して既存の SAP システムを復元したり、クローンを作成したりできます。 + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) は、Amazon EC2 インスタンスおよび他の AWS リソースの一般的なメンテナンスとデプロイのタスクを簡略化します。 + AWS では、AWS のインフラストラクチャとアプリケーションを監視および管理するための複数のネイティブサービスを提供します。Amazon CloudWatch や AWS CloudTrail などのサービスを使用して、基盤となるインフラストラクチャと API オペレーションをそれぞれ監視できます。詳細については、「[SAP on AWS — IBM Db2 HADR with Pacemaker](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)」 を参照してください。 ## エピック ### 環境の準備 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | システムとログをチェックします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | ### サーバーとレプリケーションをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | SAP サーバーとデータベースサーバーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html)ロールフォワード保留状態は、フルバックアップの復元後にデフォルトで設定されます。ロールフォワード保留状態は、データベースが復元中で、何らかの変更を適用する必要がある可能性があることを示します。詳細については、「[IBM ドキュメント](https://www.ibm.com/docs/en/db2/11.5?topic=commands-rollforward-database)」を参照してください。 | SAP ベーシス管理者 | | 設定を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | | 本番 DB から DR DB へのレプリケーションを設定します (ASYNC モードを使用)。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | ### DR フェイルオーバータスクをテスト | タスク | 説明 | 必要なスキル | | --- | --- | --- | | DR テストの本番ビジネスのダウンタイムを計画します。 | DR フェイルオーバーシナリオをテストするために、必ず本番環境で必要な業務停止時間を計画するようにします。 | SAP ベーシス管理者 | | テストユーザーを作成します。 | DR ホストで検証できるテストユーザー (または任意のテスト変更) を作成して、DR フェイルオーバー後のログの複製を確認します。 | SAP ベーシス管理者 | | コンソールで、本番環境の EC2 インスタンスを停止します。 | このステップでは、ディザスタシナリオを想定して不適切なシャットダウンが開始されます。 | AWS システム管理者 | | DR EC2 インスタンスを要件に合わせてスケールアップします。 | EC2 コンソールで、DR リージョンのインスタンスタイプを変更します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | | テイクオーバーを初期化します。 | DR システム (`host2`) から、テイクオーバープロセスを開始し、DR データベースをプライマリとして起動します。
db2 takeover hadr on database  by force
オプションとして、以下のパラメータを設定して、インスタンスタイプに基づいてデータベースのメモリ割り当てを自動的に調整できます。`INSTANCE_MEMORY` の値は、Db2 データベースに割り当てられるメモリの専用部分に基づいて決定できます。
db2 update db cfg for  using INSTANCE_MEMORY  IMMEDIATE;
db2 get db cfg for  | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; 
db2 update db cfg for  using self_tuning_mem ON IMMEDIATE;
次のコマンドを使用して変更を確認します。
db2 get db cfg for  | grep -i MEMORY
db2 get db cfg for  | grep -i self_tuning_mem
| SAP ベーシス管理者 | | DR リージョンで SAP のアプリケーションサーバーを起動します。 | 本番システムで作成した AMI を使用して、DR リージョンに「[新しい追加のアプリケーションサーバーを起動](https://aws.amazon.com/premiumsupport/knowledge-center/launch-instance-custom-ami/)」 します。 | SAP ベーシス管理者 | | SAP アプリケーションを起動する前に検証を行います。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | | DR システムで SAP アプリケーションを起動します。 | `adm` ユーザーを使用して、 DR システムで SAP アプリケーションを起動します。次のコードを使用したら、`XX` が SAP ABAP SAP セントラルサービス (ASCS)を表し、`YY` がSAPアプリケーションサーバーのインスタンス数を表します。
sapconrol -nr XX -function StartService 
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService 
sapconrol -nr YY -function StartSystem
| SAP ベーシス管理者 | | SAP 検証を実行します。 | DR テストとして実施され、エビデンスを提供したり、DR 領域へのデータ複製の成功を確認したりします。 | テストエンジニア | ### DR フェイルバックタスクの実行 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 本番環境の SAP サーバーとデータベースサーバーを起動します。 | コンソールで、SAP と本番システムのデータベースをホストするEC2インスタンスを起動します。 | SAP ベーシス管理者 | | 本番データベースを起動し、HADR を設定します。 | 本番システム (`host1`) にログインし、以下のコマンドを使用して DB がリカバリモードになっていることを確認します。
db2start
db2 start HADR on db P3V as standby
db2 connect to
HADRの状態が `connected` であることを確認します。レプリケーションステータスが `peer` であるはずです。
db2pd -d  -hadr
データベースに不一致がなく、`connected` と `peer` のステータスではない場合、現在アクティブなデータベース (DR リージョンの `host2`)とデータベースを同期(`host1` で)するために、バックアップと復元が必要になることがあります。その場合、DB バックアップを `host2` DR のリージョンのデータベースから `host1` 本番リージョンのデータベースに復元します。 | SAP ベーシス管理者 | | データベースを本番リージョンにフェイルバックします。 | 通常の業務シナリオでは、このステップがスケジュール済みのダウンタイムに実行されます。DR システムで実行されているアプリケーションが停止され、データベースが本番リージョン (リージョン 1) にフェイルバックされ、本番リージョンからのオペレーションが再開されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | | SAP アプリケーションを起動する前に検証を行います。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 管理者、SAP ベーシス管理者 | | SAP アプリケーションを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP ベーシス管理者 | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | HADR 関連の問題をトラブルシューティングするためのキーログファイルとコマンド | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | | Db2 UDB の HADR 問題のトラブルシューティングに関する SAP ノート | 「[SAP ノート 1154013-DB6:HADR 環境のDBの問題](https://service.sap.com/sap/support/notes/1154013)」 を参照してください。(このノートにアクセスするには SAP ポータルの認証情報が必要です)。 | ## 関連リソース + 「[AWS 上の Db2 データベースのディザスタリカバリアプローチ](https://aws.amazon.com/blogs/architecture/disaster-recovery-approaches-for-db2-databases-on-aws/)」 (ブログ記事) + 「[SAP on AWS — ペースメーカー搭載の IBM Db2 HADR](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)」 + 「[DB2 データベース間で HADR レプリケーションをセットアップするステップバイステップの手順](https://www.ibm.com/support/pages/step-step-procedure-set-hadr-replication-between-db2-databases)」 + 「[DB2 HADR ウィキ](https://ibm.github.io/db2-hadr-wiki/index.html)」 ## 追加情報 このパターンを使用して、Db2 データベースで稼働している SAP システムのディザスタリカバリシステムを設定できます。ディザスタの時、定義された目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件の範囲でビジネスを継続できる必要があります: + **RTO** とは、サービスが中断してから復旧するまでに経過した時間の、許容される最大値のことです。これにより、サービスが使用不可のときに許容される時間枠が決まります。 + **RPO** とは、データが最後に復旧した時点を起点とする経過時間の、許容される最大値のことです。これにより、最後の回復時点からサービスが中断されるまでの間に許容できるデータ損失の程度が決まります。 HADR に関するよくある質問については、「[SAP ノート \$11612105-DB6: Db2 高可用性ディザスタリカバリ (HADR) に関する FAQ](https://launchpad.support.sap.com/#/notes/1612105)」 を参照してください。(このノートにアクセスするには SAP ポータルの認証情報が必要です)。 # Terraform を使用してデータベース移行用の CI/CD パイプラインを設定する *Amazon Web Services、Rahul Sharad Gaikwad 博士、Ashish Bhatt、Aniket Dekate、Ruchika Modi、Tamilselvan P、Nadeem Rahaman、Aarti Rajput、Naveen Suthar* ## 概要 このパターンでは、信頼性が高く自動化された方法でデータベース移行を管理するための継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを確立します。Infrastructure as Code (IaC) ツールである Terraform を使用して、必要なインフラストラクチャのプロビジョニング、データの移行、スキーマの変更のカスタマイズを行うプロセスについて説明します。 具体的には、このパターンでは、オンプレミスの Microsoft SQL Server データベースを AWSの Amazon Relational Database Service (Amazon RDS) に移行する CI/CD パイプラインを設定します。このパターンを使用して、仮想マシン (VM) または別のクラウド環境にある SQL Server データベースを Amazon RDS に移行することもできます。 このパターンは、データベースの管理とデプロイに関連する以下の問題に対処します。 + 手動のデータベースデプロイは時間がかかり、エラーが発生しやすく、環境間の一貫性がありません。 + インフラストラクチャのプロビジョニング、データ移行、スキーマの変更を調整することは、複雑で管理が難しい場合があります。 + 本稼働システムでは、データの整合性を確保し、データベースの更新中のダウンタイムを最小限に抑えることが重要です。 このパターンには次の利点があります。 + データベース移行用の CI/CD パイプラインを実装することで、データベースの変更の更新とデプロイのプロセスを合理化します。これにより、エラーのリスクが軽減され、環境間の一貫性が確保され、ダウンタイムを最小限に抑えられます。 + 信頼性、効率、連携の向上に役立ちます。市場投入までの時間を短縮し、データベースの更新中のダウンタイムを減らすことができます。 + データベース管理に最新の DevOps プラクティスを採用しやすくなります。これにより、ソフトウェアのデリバリープロセスの俊敏性、信頼性、効率性が向上します。 ## 前提条件と制限 **前提条件** + アクティブな AWS アカウント + ローカルマシンにインストールされた Terraform 0.12 以降 (手順については、[Terraform のドキュメント](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)を参照してください) + HashiCorp の Terraform AWS Provider バージョン 3.0.0 以降 (このプロバイダーの [GitHub リポジトリ](https://github.com/hashicorp/terraform-provider-aws)を参照) + 最小特権 AWS Identity and Access Management (IAM) ポリシー (ブログ記事[「最小特権 IAM ポリシーを記述するためのテクニック](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)」を参照) ## アーキテクチャ このパターンでは、データベース移行プロセス用の完全なインフラストラクチャを提供する次のアーキテクチャを実装します。 ![\[オンプレミス SQL Server データベースを AWS の Amazon RDS に移行するための CI/CD パイプラインアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/87845d9f-8e6e-4c51-b9ee-9e7833671d05/images/a1e95458-419a-4de9-85ef-b17d8340700a.png) このアーキテクチャの詳細は以下のとおりです。 + ソースデータベースは、オンプレミスか、仮想マシン (VM) 上にあるか、別のクラウドプロバイダーによってホストされている SQL Server データベースです。この図は、ソースデータベースがオンプレミスデータセンターにあることを前提としています。 + オンプレミスデータセンターと AWS は、VPN または AWS Direct Connect 接続を介して接続されます。これにより、ソースデータベースと AWS インフラストラクチャ間の安全な通信が可能になります。 + ターゲットデータベースは、データベースプロビジョニングパイプラインを使用して の仮想プライベートクラウド (VPC) AWS 内でホストされる Amazon RDS データベースです。 + AWS Database Migration Service (AWS DMS) はオンプレミスデータベースを にレプリケートします AWS。これは、ソースデータベースのターゲットデータベースへの複製を設定するために使用されます。 次の図は、さまざまなレベルのデータベース移行プロセスでセットアップされたインフラストラクチャを示しています。これには、プロビジョニング、 AWS DMS セットアップ、検証が含まれます。 ![\[オンプレミスから AWS への移行プロセスの CI/CD パイプラインの詳細。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/87845d9f-8e6e-4c51-b9ee-9e7833671d05/images/3aca17e5-6fd7-4317-b578-ab5e485c6efb.png) このプロセスでは、次のことが行われます。 + 検証パイプラインはすべてのチェックを検証します。必要なすべての検証が完了すると、統合パイプラインは次のステップに進みます。 + DB プロビジョニングパイプラインは、データベース用に提供された Terraform コードに対して Terraform アクションを実行するさまざまな AWS CodeBuild ステージで構成されます。これらのステップが完了すると、ターゲット AWS アカウントにリソースがデプロイされます。 + AWS DMS パイプラインは、テストを実行し、IaC を使用して移行を実行するための AWS DMS インフラストラクチャをプロビジョニングするさまざまな CodeBuild ステージで構成されます。 ## ツール **AWS のサービス および ツール** + [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はフルマネージド型の継続的統合サービスであり、このサービスにより、ソースコードをコンパイルし、テストを実行し、デプロイ可能なソフトウェアパッケージを作成できます。 + [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) はフルマネージド型の継続的デリバリーサービスで、アプリケーションとインフラストラクチャの更新を迅速かつ高い信頼性で行うために、パイプラインのリリースを自動化します。 + [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベースをセットアップ、運用、スケーリングできます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、スケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。 + [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) を使用すると、データストアを に移行する AWS クラウド か、クラウドとオンプレミスのセットアップの組み合わせ間で移行できます。 **その他のサービス** + [Terraform](https://www.terraform.io/) は HashiCorp の IaC ツールであり、クラウドおよびオンプレミスのリソースの作成と管理を支援します。 **コードリポジトリ** このパターンのコードは、GitHub 内の [Database Migration DevOps Framework using Terraform samples](https://github.com/aws-samples/aws-terraform-db-migration-framework-samples) リポジトリで入手できます。 ## ベストプラクティス + データベース移行の自動テストを実装して、スキーマの変更とデータの整合性の正確性を確認します。これには、ユニットテスト、統合テスト、エンドツーエンドテストが含まれます。 + データベースの堅牢なバックアップおよび復元戦略を、特に移行前に実装します。これにより、データの整合性が確保され、障害が発生した場合にフォールバックオプションが提供されます。 + 移行中に障害や問題が発生した場合にデータベースの変更を元に戻すための堅牢なロールバック戦略を実装します。これには、以前のデータベースの状態にロールバックしたり、個々の移行スクリプトを元に戻したりすることが含まれます。 + データベース移行の進行状況とステータスを追跡するため、モニタリングとログ記録のメカニズムを設定します。これにより、問題をすばやく特定して解決できます。 ## エピック ### ローカルワークステーションをセットアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ローカルワークステーションに Git をセットアップして構成します。 | [Git ドキュメント](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)の手順に従って、ローカルワークステーションに Git をインストールして設定します。 | DevOps エンジニア | | プロジェクトフォルダを作成し、GitHub リポジトリからファイルを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-ci-cd-pipeline-for-db-migration-with-terraform.html) | DevOps エンジニア | ### ターゲットアーキテクチャをプロビジョニングする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 必須パラメータを更新します。 | `ssm-parameters.sh` ファイルには、必要な AWS Systems Manager パラメータがすべて保存されます。これらのパラメータは、プロジェクトのカスタム値で設定できます。ローカルワークステーションの `setup/db-ssm-params` フォルダで、`ssm-parameters.sh` ファイルを開き、CI/CD パイプラインを実行する前にこれらのパラメータを設定します。 | DevOps エンジニア | | Terraform の設定を初期化します。 | `db-cicd-integration` フォルダで次のコマンドを入力し、Terraform 設定ファイルを含む作業ディレクトリを初期化します。
terraform init
| DevOps エンジニア | | Terraform プランをプレビューしてください。 | Terraform プランを作成するには、以下のコマンドを入力します。
terraform plan -var-file="terraform.sample"
Terraform は設定ファイルを評価して、宣言されたリソースのターゲット状態を判断します。次に、ターゲットの状態を現在の状態と比較し、プランを作成します。 | DevOps エンジニア | | プランを検証してください。 | プランを確認し、ターゲットの AWS アカウントアカウントで必要なアーキテクチャが設定されていることを確認します。 | DevOps エンジニア | | ソリューションのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-ci-cd-pipeline-for-db-migration-with-terraform.html) | DevOps エンジニア | ### デプロイメントを確認する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | デプロイを検証する。 | `db-cicd-integration` パイプラインのステータスを確認して、データベースの移行が完了していることを確認します。1. にサインインし AWS マネジメントコンソール、[AWS CodePipeline コンソール](https://console.aws.amazon.com/codesuite/codepipeline/home)を開きます。2. ナビゲーションペインで **[Pipelines]** (パイプライン) を選択します。3. `db-cicd-integration` パイプラインを選択します。4. パイプライン実行が正常に完了したことを検証します。 | DevOps エンジニア | ### 使用後にインフラストラクチャをクリーンアップする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | インフラストラクチャをクリーンアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-ci-cd-pipeline-for-db-migration-with-terraform.html) | DevOps エンジニア | ## 関連リソース **AWS ドキュメント** + [Terraform 製品の開始方法](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/getstarted-Terraform.html) Terraformのドキュメント + [Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli) + [Terraform のバックエンド設定](https://developer.hashicorp.com/terraform/language/backend) + [Terraform AWS プロバイダーのドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) # FSx for Windows File Server を使用して Amazon EC2 で Microsoft SQL Server フェイルオーバークラスターをセットアップする *Amazon Web Services、Sweta Krishna および Ramesh Babu Donti* ## 概要 フェイルオーバークラスターインスタンス (FCI) を備えた Microsoft SQL Server Standard Edition は、SQL Server Enterprise よりもコスト効率の高い代替手段を提供できます。SQL FCI をセットアップするには、ノード間の共有ファイルストレージが必要です。[Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/)は、アベイラビリティーゾーン間で自動的かつ同期的にレプリケートする、フルマネージドストレージを提供します。Amazon FSx は、汎用ファイル共有用の組み込みデータ重複排除を使用してストレージコストを削減し、サードパーティーソリューションを維持する必要性を排除します。Amazon FSx は以下の内容もサポートします。 + 前払い料金や契約は不要で、使用した分だけ支払います。 + FSx を使用して FCI を手動でセットアップし、共有ストレージにします。 + SQL クラスターのファイル共有監視手段に FSx を使用します。 + Amazon FSx for Windows File Server は、継続的に利用可能なファイル共有のための Server Message Block (SMB) 3.0 をサポートしており、SQL Server FCI のデプロイに適しています。 ## 前提条件と制限 **前提条件** + アクティブな [AWS アカウント](https://aws.amazon.com/account/)。 + Amazon Virtual Private Cloud (Amazon VPC) リソース、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、セキュリティグループ、および AWS Identity and Access Management (IAM) ロールを作成および管理するためのアクセス許可。 + AWS Managed Microsoft AD または独自のオンプレミス Active Directory。 + フェイルオーバークラスターをセットアップするために[必要なアクセス許可](https://learn.microsoft.com/en-us/windows-server/failover-clustering/configure-failover-cluster-accounts)を持つ Active Directory ドメインユーザー。 + 安全なハイブリッド接続のための SQL Server FCI および [Microsoft Active Directory ポート](https://docs.aws.amazon.com/whitepapers/latest/access-workspaces-with-access-cards/ip-address-and-port-requirements.html)のセキュリティグループルール。 + SQL ノード間で適切なアクセス許可が設定された、Active Directory for SQL Server の[サービスアカウント](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver16#sql-server-failover-cluster-instance)。 + フェイルオーバークラスター内の Amazon FSx for Windows File Server。 + SQL Server インストールバイナリ。 **制限事項** + 一部の AWS のサービス は、すべてで利用できるわけではありません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページから、サービスのリンクを選択してご確認ください。 **製品バージョン** + Amazon EC2 for Windows Server 2012 R2 以降 + 現在のすべての Windows Server バージョンを含む Amazon FSx for Windows File Server + 共有ストレージの代替手段としての Amazon FSx for NetApp ONTAP + SQL Server 2012/2016/2019/2022 ## アーキテクチャ **テクノロジースタック** + Amazon EC2 + Amazon FSx for Windows File Server + Amazon VPC + AWS Directory Service + AWS Systems Manager + IAM **ターゲットアーキテクチャ** 次の図は、Amazon FSx for Windows File Server を使用した Amazon EC2 での Microsoft SQL Server FCI のアーキテクチャの概要を示しています。 ![\[Amazon FSx for Windows File Server を使用した Amazon EC2 での Microsoft SQL Server FCI のアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/208bf64a-8fef-4019-944a-723372450885/images/ba0c9169-9536-41c3-ae8e-7264dcc3e1ad.png) **ネットワークインフラストラクチャ** + Amazon VPC は、3 つのアベイラビリティーゾーンにまたがるネットワークコンテナを提供します。 + プライベートサブネットは、リソースをデプロイするために、各アベイラビリティーゾーンに分離されたサブネットを提供します。 **コンピューティングレイヤー** + Amazon EC2 には、Windows Server フェイルオーバークラスター (WSFC) の一部としてアベイラビリティーゾーン 1 にデプロイされた SQL Server クラスターノード 1 が含まれています。 + Amazon EC2 には、WSFC の一部としてアベイラビリティーゾーン 2 にデプロイされた SQL Server クラスターノード 2 が含まれています。 + WSFC クラスターは、フェイルオーバー機能のために両方の SQL Server ノードを接続します。 **Amazon FSx for Windows File Server のストレージレイヤー** **マルチ AZ FSx デプロイ (アベイラビリティーゾーン 1 と 2 にまたがる)** + アベイラビリティーゾーン 1 のプライマリ FSx ファイルシステムは、アクティブな SQL Server データとログファイルをホストします。 + アベイラビリティーゾーン 2 のセカンダリ FSx ファイルシステムは、自動フェイルオーバー機能を提供します。 + SQL Server データベースの両方のクラスターノードからアクセスできる、SMB ファイル共有 (\$1\$1fsx.domain\$1sqlshare)。 **シングル AZ FSx デプロイ (AZ3 内)** + アベイラビリティーゾーン 3 の Amazon FSx ファイルサーバー監視は、クラスタークォーラム監視として機能します。 + ファイル共有監視 (`\\fsx.domain\witness`) はクラスタークォーラムを維持し、スプリットブレインのシナリオを防止します。 **ディレクトリサービス** + AWS Managed Microsoft AD は、クラスター機能に必要な Windows 認証とドメインサービスを提供します。 **高可用性機能** + マルチ AZ コンポーネントは、アベイラビリティーゾーン間で耐障害性を提供します。 + FSx スタンバイファイルサーバーは、プライマリサーバーに障害が発生した場合に自動フェイルオーバーを提供します。 + ファイル共有監視は、アベイラビリティーゾーン 3 でクラスタークォーラム管理を提供し、障害発生時にクラスターが適切に機能するようにします。 + ドメインは、シームレスな Windows 認証 AWS Managed Microsoft AD のために と統合されています。 ## ツール **AWS のサービス** + [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。 + [Amazon FSx](https://docs.aws.amazon.com/fsx/?id=docs_gateway) は、業界標準の接続プロトコルをサポートし、 AWS リージョン全体で高い可用性とレプリケーションを提供するファイルシステムを提供します。 + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。 + [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) は、ディレクトリ対応のワークロードと AWS リソースが で Microsoft Active Directory を使用できるようにします AWS クラウド。 + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。 + [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。 ## ベストプラクティス + データベースインスタンスをプライベートサブネットに配置して、インターネットからパブリックにアクセスできないようにしながら、 に接続 AWS のサービス して更新を実行できるようにします。 + 一般的なベストプラクティスについては、「[Best Practices for Deploying Microsoft SQL Server on Amazon EC2](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-ec2-best-practices/welcome.html)」を参照してください。 + PowerShell を使用して Amazon FSx for Windows File Server を管理するには、「[Administering FSx for Windows file systems](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/administering-file-systems.html)」を参照してください。 ## エピック ### SQL Server 用の Amazon EC2 ノードを作成および設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 名前とタグを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | Windows AMI を選択します。 | SQL Server の要件を満たす Windows 用の Amazon マシンイメージ (AMI) を選択します。 | DBA | | インスタンスのタイプを選択します。 | 要件を満たす Amazon EC2 インスタンスタイプを選択します。 | DBA | | キーペアを使用します。 | キーペアを使用すると、インスタンスに安全に接続できます。インスタンスを起動する前に、選択したキーペアにアクセスできることを確認してください。 | DBA | | ネットワーク設定を構成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | [ネットワークの詳細設定] を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | ストレージを設定します。 | 必要な合計ストレージを設定し、必要なストレージタイプを選択します。 | DBA | | 高度な詳細を設定し、インスタンスを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | ノード 2 を作成します。 | これらのステップを繰り返して、ノード 2 を作成して設定します。 | DBA | ### ノード 1 と 2 に Windows Server フェイルオーバークラスターをインストールして設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ノード 1 にログインします。 | 管理者として、Windows Amazon EC2 インスタンスにログインします。 | DBA | | ノード 1 に FCI 機能をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html)
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | ノード 2 にログインします。 | 管理者として、Windows Amazon EC2 インスタンスにログインします。 | DBA | | ノード 2 に FCI 機能をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html)
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | 新しいノードをクラスターに追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | クラスターをオンラインにします。 | クラスターをオンラインにするには、両方のノードの静的 IP アドレスを更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | クラスターを検証します。 | **[Failover Cluster Manager]** に移動し、クラスターコアリソースがオンラインであることを確認します。 | DBA | ### ノード 1 と 2 に SQL Server をインストールする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | サーバーにログインします。 | 管理者として Amazon EC2 インスタンスにログインします。 | DBA | | SQL バイナリをマウントします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | | | フェイルオーバークラスターにノード 2 を追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | ### Amazon FSx ファイル共有監視を設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クォーラム設定を構成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/microsoft-sql-failover-cluster-on-amazon-ec2.html) | DBA | | DNS の詳細を取得します。 | Amazon FSx コンソールで、**[マネージド AD]**、**[アタッチ]** の順に選択します。DNS は次の形式である必要があります。`\\example.example.net\share` | DBA | | ファイル共有監視を設定します。 | **[Amazon FSx ファイル共有パス]**、**[完了]** の順に選択します。 | DBA | ## 関連リソース **AWS リソース** + [Amazon FSx for Windows File Server](https://www.youtube.com/watch?v=IMDWTIShlyI) (ビデオ) + [Deep dive on Amazon FSx for Windows File Server](https://www.youtube.com/watch?v=_x_Geur93oc) (ビデオ) + [Amazon EBS マルチアタッチを使用して SQL Server フェイルオーバークラスターを Windows Server にデプロイする方法](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) (AWS ブログ記事) + [Amazon FSx for Windows File Server を使用して Microsoft SQL Server の高可用性デプロイを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) (AWS ブログ記事) + [Amazon FSx for NetApp ONTAP を使用した SQL Server の高可用性デプロイ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/) (AWS ブログ記事) + 「[Microsoft SQL Server で FSx for Windows File Server を使用する](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/sql-server.html)」 + [FSx for Windows File Server とは](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) **その他のリソース** + [フェイルオーバークラスターを作成する](https://learn.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster?pivots=windows-admin-center) ## 追加情報 **ファイル共有監視を設定する** Amazon FSx セキュリティグループにインバウンド接続を許可するルールを追加して、両方のノードからファイルシステムに接続していることを確認します。SMB ポートを許可する必要があります。例えば、DNS 名が `\\example.example.com\share` の場合は `\\example.example.com\share` を使用します。Always On 可用性クラスターのファイル共有監視にも同じ値を使用します。ファイル共有監視を設定するには、次の手順を実行します。 1. RDP を使用して、Amazon EC2 インスタンスに接続します。 1. **[Failover Cluster Manager]** に移動します。 1. コンテキスト (右クリック) メニューを開き、**[その他のアクション]** を選択します。 1. **[クラスタークォーラム設定を構成]** を選択します。 1. [**次へ**] を選択します。 1. **[クォーラム設定]** を選択し、ファイル共有監視を設定します。 1. DNS 名を指定します。 1. 概要を確認し、**[完了]** を選択します。ファイル共有監視は、**[クラスターコア]** リソースセクションでオンラインになっている必要があります。 # Amazon RDS Custom でアクティブスタンバイデータベースを使用して Oracle E-Business Suite の HA/DR アーキテクチャを設定する *Simon Cunningham、Jaydeep Nandy、Nitin Saxena、Amazon Web Services* ## 概要 このパターンでは、Amazon Relational Database Service (Amazon RDS) Custom で Amazon RDS Custom リードレプリカデータベースを別の Amazon Web Services (AWS) アベイラビリティーゾーンに設定し、それをアクティブなスタンバイデータベースに変換することで、高可用性 (HA) とディザスタリカバリ (DR) を実現する Oracle E-Business ソリューションを構築する方法について説明します。Amazon RDS Custom リードレプリカの作成は、AWS マネジメントコンソールを通じて完全に自動化されています。 このパターンでは、HA/DR アーキテクチャの一部にもなり得るアプリケーション層や共有ファイルシステムを追加する手順については説明していません。これらのトピックの詳細については、Oracle サポートに関する注意事項の 1375769.1、1375670.1、および 1383621.1（セクション 5、「*クローニングの詳細オプション*」）を参照してください。(アクセスには [Oracle サポート](https://support.oracle.com/portal/)アカウントが必要です。) E-Business Suite システムを Amazon Web Services (AWS) の単層、シングル AZ アーキテクチャに移行するには、「[Oracle E-Business Suite を Amazon RDS Custom に移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-oracle-e-business-suite-to-amazon-rds-custom.html)」というパターンを参照してください。 Oracle E-Business Suite は、財務、人事、サプライチェーン、製造などの企業全体のプロセスを自動化するためのエンタープライズリソースプランニング (ERP) ソリューションです。クライアント、アプリケーション、データベースという 3 層のアーキテクチャで構成されています。以前は、E-Business Suite データベースを自己管理型の [Amazon Elastic Compute Cloud (Amazon EC2) インスタンス](https://aws.amazon.com/ec2/)で実行する必要がありましたが、[Amazon RDS Custom](https://aws.amazon.com/rds/custom/) の恩恵を受けることができるようになりました。  ## 前提条件と制限 **前提条件** + Amazon RDS Custom にインストールされている既存の E-Business Suite。「[Oracle E-Business Suite を Amazon RDS Customに移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-oracle-e-business-suite-to-amazon-rds-custom.html)」のパターンを参照してください。 + リードレプリカを読み取り専用に変更し、それを使用してレポートをスタンバイにオフロードする場合は、「[Oracle Active Data Guardデータベースライセンス](https://www.oracle.com/corporate/pricing/)」 （*Oracle Technology の商用価格表を参照*）が必要です。 **制限事項** + [Amazon RDS Custom 上の Oracle データベース](https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/custom-reqs-limits.html#custom-reqs-limits.limits)に関する制限とサポートされていない構成 + [Amazon RDS Custom for Oracle リードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html#custom-rr.limitations)に関連する制限 **製品バージョン** Amazon RDS Custom がサポートする Oracle Database のバージョンとインスタンスクラスについては、「[Amazon RDS Custom for Oracle の要件と制限](https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/custom-reqs-limits.html)」を参照してください。 ## アーキテクチャ 次の図は、アクティブ/パッシブのセットアップに複数のアベイラビリティーゾーンとアプリケーション層を含む E-Business Suite on AWS の代表的なアーキテクチャを示しています。データベースは Amazon RDS Custom DB インスタンスと Amazon RDS Custom リードレプリカを使用します。リードレプリカは Active Data Guard を使用して、別のアベイラビリティーゾーンに複製します。リードレプリカを使用して、プライマリデータベースの読み取りトラフィックをオフロードし、またはレポートを作成することもできます。 ![\[Oracle E-Business Suite on AWS のマルチ AZ アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a17947e8-56b1-4d92-91df-096c02ff4c19/images/ffdaa2d4-123b-44a0-8d52-b1352a4eee44.png) 詳細については、Amazon RDS ドキュメントの「[Amazon RDS Custom for Oracle 用リードレプリカの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html)」を参照してください。  Amazon RDS Custom リードレプリカは、デフォルトではマウント状態で作成されます。ただし、読み取り専用のワークロードの一部をスタンバイデータベースにオフロードしてプライマリデータベースの負荷を軽減したい場合は、「[エピック](#set-up-an-ha-dr-architecture-for-oracle-e-business-suite-on-amazon-rds-custom-with-an-active-standby-database-epics)」セクションの手順に従って、マウントされたレプリカのモードを手動で読み取り専用に変更できます。一般的な使用例は、スタンバイデータベースからレポートを実行することです。読み取り専用に変更するには、アクティブ/スタンバイデータベースライセンスが必要です。  AWS でリードレプリカを作成すると、システムは Oracle Data Guard ブローカーを内部で使用します。 この設定は、以下のように自動的に生成され、最大パフォーマンスモードで設定されます。 ``` DGMGRL> show configuration Configuration - rds_dg Protection Mode: MaxPerformance Members: vis_a - Primary database vis_b - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 58 seconds ago) ``` ## ツール **AWS サービス** + 「[Amazon RDS Custom for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-custom-oracle.html)」は、基盤となるオペレーティングシステムとデータベース環境へのアクセスを必要とするレガシーアプリケーション、カスタムアプリケーション、パッケージアプリケーション向けのマネージドデータベースサービスです。データベース管理のタスクとオペレーションを自動化し、データベース管理者としてデータベース環境とオペレーティングシステムへのアクセスおよびカスタマイズを可能にします。  **その他のツール** + Oracle Active Data Guard は、スタンバイデータベースの作成と管理に役立ちます。このパターンでは、Oracle Data Guard を使用して Amazon RDS Custom 上にアクティブ スタンバイデータベースを設定します。 ## エピック ### リードレプリカの作成 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS Custom DB インスタンスのリードレプリカを作成します。 | リードレプリカを作成するには、「[Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)」の指示に従い、作成した Amazon RDS Custom DB インスタンス (「[前提条件](#set-up-an-ha-dr-architecture-for-oracle-e-business-suite-on-amazon-rds-custom-with-an-active-standby-database-prereqs)」セクションを参照) をソースデータベースとして使用します。デフォルトでは、Amazon RDS Custom リードレプリカは物理スタンバイとして作成され、マウントされた状態になります。これにより、Oracle Active Data Guard ライセンスへのコンプライアンスが確保されます。リードレプリカを読み取り専用モードに変換するには、次の手順に従います。 | DBA | ### リードレプリカを読み取り専用のアクティブスタンバイに変更します。 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon RDS Custom リードレプリカに接続します。 | 以下のコマンドを使用して、物理スタンバイデータベースをアクティブスタンバイデータベースに変換します。 これらのコマンドには、Oracle のアクティブスタンバイライセンスが必要です。ライセンスを取得するには、Oracle の担当者にお問い合わせください。
$ sudo su - rdsdb
-bash-4.2$ sql
SQL> select process,status,sequence# from v$managed_standby;

PROCESS    STATUS        SEQUENCE#
--------- ------------ ----------
ARCH       CLOSING            3956
ARCH       CONNECTED             0
ARCH       CLOSING            3955
ARCH       CLOSING            3957
RFS        IDLE                  0
RFS        IDLE               3958
MRP0       APPLYING_LOG       3958
SQL> select name, database_role, open_mode from v$database;

NAME       DATABASE_ROLE    OPEN_MODE
--------- ---------------- --------------------
VIS        PHYSICAL STANDBY MOUNTED
SQL> alter database recover managed standby database cancel;
Database altered.
Open the standby database
SQL> alter database open;
Database altered.
SQL> select name, database_role, open_mode from v$database;

NAME       DATABASE_ROLE    OPEN_MODE
--------- ---------------- --------------------
VIS        PHYSICAL STANDBY READ ONLY
| DBA | | リアルタイムログを適用することで、メディアリカバリを開始します。 | リアルタイムログ適用機能を有効にするには、以下のコマンドを使用します。これらのコマンドはスタンバイ (リードレプリカ) をアクティブスタンバイデータベースとして変換して検証するため、接続して読み取り専用クエリを実行できます。
SQL>   alter database recover managed standby database using current logfile disconnect from session;
Database altered
| DBA | | データベースのステータスをチェックします。 | データベースのステータスを確認するには、次のコマンドを使用します。
SQL> select name, database_role, open_mode from v$database;
NAME      DATABASE_ROLE    OPEN_MODE
--------- ---------------- --------------------
VIS       PHYSICAL STANDBY READ ONLY WITH APPLY
| DBA | | REDO 適用モードをチェックします。 | REDO 適用モードを確認するには、次のコマンドを使用します。
SQL> select process,status,sequence# from v$managed_standby;
PROCESS    STATUS        SEQUENCE#
--------- ------------ ----------
ARCH       CLOSING            3956
ARCH       CONNECTED             0
ARCH       CLOSING            3955
ARCH       CLOSING            3957
RFS        IDLE                  0
RFS        IDLE               3958
MRP0       APPLYING_LOG       3958
 
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
| DBA | ## 関連リソース + 「[Oracle E-Business Suite を Amazon RDS Customに移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-oracle-e-business-suite-to-amazon-rds-custom.html)」 (AWS 規範ガイダンス) + 「[「Amazon RDS Customでの作業](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-custom.html)」 (Amazon RDS ドキュメント) + 「[Amazon RDS Custom for Oracle リードレプリカの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html)」 (Amazon RDS ドキュメント) + 「[Amazon RDS Custom for Oracle — データベース環境における新しい制御機能](https://aws.amazon.com/blogs/aws/amazon-rds-custom-for-oracle-new-control-capabilities-in-database-environment/)」 (AWS ニュース ブログ) + 「[Oracle E-Business Suite on AWS への移行](https://d1.awsstatic.com/whitepapers/migrate-oracle-e-business-suite.pdf)」 (AWS ホワイトペーパー) + 「[AWS での Oracle E-Business Suite アーキテクチャ](https://docs.aws.amazon.com/whitepapers/latest/overview-oracle-e-business-suite/oracle-e-business-suite-architecture-on-aws.html)」 (AWS ホワイトペーパー) # IBM Db2、SAP、Sybase、およびその他のデータベースから の MongoDB Atlas にデータをストリーミングする AWS *Battulga Purevragchaa、Igor Alekseev (Amazon Web Services)* *Babu Srinivasan (MongoDB)* ## 概要 このパターンでは、IBM Db2 およびその他のデータベース (メインフレームデータベースや Sybase など) から AWS クラウド上の MongoDB Atlas にデータを移行する手順について説明します。[AWS Glue](https://aws.amazon.com/glue/) を使用して、MongoDB Atlas へのデータ移行を高速化します。 このパターンは、 AWS 「 規範ガイダンス」ウェブサイトの[「 での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/)」ガイドに付属しています。ここでは、そのガイドで説明されている移行シナリオの 1 つの実装手順について説明します。その他の移行シナリオについては、 AWS 「 規範ガイダンス」ウェブサイトの次のパターンを参照してください。 + [でセルフホスト MongoDB 環境を MongoDB Atlas に移行する AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-a-self-hosted-mongodb-environment-to-mongodb-atlas-on-the-aws-cloud.html) + [でリレーショナルデータベースを MongoDB Atlas に移行する AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-relational-database-to-mongodb-atlas.html) このパターン は、[AWS マネージドサービスパートナー](https://aws.amazon.com/managed-services/partners/)と AWS ユーザーを対象としています。 ## 前提条件と制限 **前提条件** + MongoDB Atlas に移行するソースデータベース (SAP、Sybase、IBM Db2 など)。 + SAP、Sybase、IBM Db2、MongoDB Atlas、 などのデータベースに精通していること AWS のサービス。 **製品バージョン** + MongoDB バージョン 5.0 以降 ## アーキテクチャ 次の図は、、Amazon Kinesis Data Streams AWS Glue Studio、および MongoDB Atlas を使用したバッチデータのロードとデータストリーミングを示しています。 このリファレンスアーキテクチャでは AWS Glue Studio 、 を使用して抽出、変換、ロード (ETL) パイプラインを作成し、データを MongoDB Atlas に移行します。は MongoDB Atlas と AWS Glue クローラー 統合され、データガバナンスを容易にします。データは、Amazon Kinesis Data Streams を使用して MongoDB Atlas にバッチで移植するか、ストリーミングすることができます。 **一括データロード** ![\[バッチモードでの MongoDB Atlas へのデータ移行。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/805a376f-35f4-44cc-b4b0-8bf4d95c1e5d/images/68d87202-95ba-4e2a-9b3b-27dd6db6165e.png) バッチデータ移行の詳細については、 AWS ブログ記事「[Compose your ETL jobs for MongoDB Atlas with AWS Glue](https://aws.amazon.com/blogs/big-data/compose-your-etl-jobs-for-mongodb-atlas-with-aws-glue/)」を参照してください。 **データストリーミング** ![\[データストリーミングモードでの MongoDB Atlas へのデータ移行。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/805a376f-35f4-44cc-b4b0-8bf4d95c1e5d/images/b007a116-f463-418f-9721-647d80177e3b.png) さまざまな使用シナリオをサポートする MongoDB Atlas リファレンスアーキテクチャについては、 AWS 「 規範ガイダンス」ウェブサイトの[「 での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/architecture.html)」を参照してください。 ## ツール ●      [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) はフルマネージド型の ETL サービスです。これにより、データストアとデータストリーム間でのデータの分類、整理、強化、移動を確実に行うことができます。 ●      [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) は、データレコードの大量のストリームをリアルタイムで収集し、処理するのに役立ちます。 ●      [MongoDB Atlas](https://www.mongodb.com/atlas) は、MongoDB データベースをクラウドにデプロイおよび管理するためのフルマネージド型 Database as a Service (DbaaS) です。 ## ベストプラクティス ガイドラインについては、MongoDB GitHub リポジトリにある「[MongoDB のベストプラクティスガイド](https://github.com/mongodb-partners/mongodb_atlas_as_aws_bedrock_knowledge_base/blob/main/data/MongoDB_Best_Practices_Guide.pdf)」を参照してください。 ## エピック ### 発見と評価 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターサイズを決定します。 | `db.stats()` からの合計インデックススペースに関する情報を使用してワーキングセットのサイズを見積もります。データスペースの一部が頻繁にアクセスされると仮定します。または、独自の仮定に基づいてメモリ要件を見積もることもできます。このタスクには約 1 週間かかりそうです。この記事とこのエピックの他のストーリーの詳細と例については、「[関連リソース](#stream-data-from-ibm-db2-to-mongodb-atlas-resources)」セクションのリンクを参照してください。 | MongoDB DBA、アプリケーションアーキテクト | | ネットワーク帯域幅要件を見積もります。 | ネットワーク帯域幅要件を見積もるには、平均ドキュメントサイズに 1 秒あたりに提供されるドキュメント数を掛けます。基準として、クラスター上のノードが負担する最大トラフィックを考慮に入れます。クラスターからクライアントアプリケーションへのダウンストリームのデータ転送速度を計算するには、一定期間に返されたドキュメントの合計を使用します。アプリケーションがセカンダリノードから読み取る場合は、このドキュメントの合計数を、読み取り操作を実行できるノード数で割ります。データベースの平均ドキュメントサイズを求めるには、`db.stats().avgObjSize` コマンドを使用してください。このタスクには通常 1 日かかります。 | MongoDB DBA | | Atlas 層を選択します。 | [MongoDB ドキュメント](https://www.mongodb.com/docs/atlas/manage-clusters/)の指示に従い、正しい Atlas クラスター階層を選択してください。  | MongoDB DBA | | カットオーバーを計画します。 | アプリケーションのカットオーバーを計画します。 | MongoDB DBA、アプリケーションアーキテクト | ### AWS に新しい MongoDB Atlas 環境を設定します | タスク | 説明 | 必要なスキル | | --- | --- | --- | | で新しい MongoDB Atlas クラスターを作成します AWS。 | MongoDB Atlas **で、クラスターの構築**を選択し、クラウドプロバイダー AWS として を選択します。 | MongoDB DBA | | AWS リージョン および グローバルクラスター設定を選択します。 | Atlas クラスター AWS リージョン で使用できる のリストから を選択します。必要に応じてグローバルクラスタを設定します。 | MongoDB DBA | | クラスター階層を選択します。 | お好みのクラスター階層を選択します。階層の選択によって、メモリ、ストレージ、IOPS の仕様などの要素が決まります。 | MongoDB DBA | | 追加のクラスター設定を構成します。 | MongoDB のバージョン、バックアップ、暗号化オプションなどのクラスター設定を追加して行います。これらのオプションの詳細については、「[関連リソース](#stream-data-from-ibm-db2-to-mongodb-atlas-resources)」セクションを参照してください。 | MongoDB DBA | ### セキュリティとコンプライアンスを設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | アクセスリストを設定します。 | Atlas クラスターに接続するには、[プロジェクトのアクセスリスト](https://www.mongodb.com/docs/atlas/setup-cluster-security/#configure-security-features-for-clusters)にエントリを追加する必要があります。Atlasは、Transport Layer Security (TLS) / Secure Sockets Layer (SSL) を使用して、データベースの仮想プライベートクラウド (VPC) への接続を暗号化します。プロジェクトのアクセスリストの設定やこのエピックのストーリーの詳細については、「[関連リソース](#stream-data-from-ibm-db2-to-mongodb-atlas-resources)」セクションのリンクを参照してください。  | MongoDB DBA | | ユーザーの認証と認可を行います。 | MongoDB Atlas クラスターにアクセスするデータベースユーザーを作成して認証する必要があります。プロジェクト内のクラスターにアクセスするには、ユーザーはそのプロジェクトに属し、複数のプロジェクトに属している必要があります。 AWS Identity and Access Management (IAM) で認可を有効にすることもできます。詳細については、MongoDB のドキュメントの「[IAM による認証を設定する](https://www.mongodb.com/docs/atlas/security/aws-iam-authentication/#set-up-authentication-with-aws-iam)」を参照してください。 | MongoDB DBA | | カスタムロールを作成します。 | (オプション) Atlas では、組み込みの Atlas データベースユーザー権限で必要な権限セットがカバーできない場合に[カスタムロール](https://www.mongodb.com/docs/atlas/reference/custom-role-actions/)を作成できます。 | MongoDB DBA | | VPC ピアリングを設定します。 | (オプション) Atlas では、他の AWS VPC との [VPC ピアリング](https://www.mongodb.com/docs/atlas/security-vpc-peering/#set-up-a-network-peering-connection)がサポートされます。 | MongoDB DBA | | AWS PrivateLink エンドポイントをセットアップします。 | (オプション) を使用して AWS でプライベートエンドポイントを設定できます[AWS PrivateLink](https://www.mongodb.com/docs/atlas/security-private-endpoint/)。 | MongoDB DBA | | 2 要素認証を有効にします。 | (オプション) Atlasは、ユーザーがAtlasアカウントへのアクセスを制御できるようにする 2 要素認証 (2FA) をサポートしています。 | MongoDB DBA | | LDAP によるユーザー認証と認可を設定します。 | (オプション) Atlasは、Lightweight Directory Access Protocol (LDAP) によるユーザー認証および認可の実行をサポートします。 | MongoDB DBA | | 統合 AWS アクセスを設定します。 | (オプション) Atlas データレイクや顧客キー管理による静的暗号化などを含む一部の Atlas 機能では、認証に IAM ロールを使用します。 | MongoDB DBA | | を使用して保管時の暗号化を設定します AWS KMS。 | (オプション) Atlas は、 AWS Key Management Service (AWS KMS) を使用してストレージエンジンとクラウドプロバイダーのバックアップを暗号化することをサポートしています。 | MongoDB DBA | | CSFLE を設定します。 | (オプション) Atlas では、フィールドの自動暗号化を含む、[クライアント側のフィールドレベルの暗号化 (CSFLE)](https://www.mongodb.com/docs/upcoming/core/csfle/#client-side-field-level-encryption) がサポートされます。  | MongoDB DBA | ### データを移行する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | MongoDB Atlas でターゲットのレプリカセットを起動します。 | MongoDB Atlas でターゲットのレプリカセットを起動します。Atlas ライブマイグレーションサービスで、「**移行する準備ができました**」を選択します。 | MongoDB DBA | | AWS Glue と MongoDB Atlas の接続を確立します。 | AWS Glue クローラー を使用して MongoDB Atlas (ターゲットデータベース) AWS Glue に接続します。このステップにより、ターゲット環境の移行準備ができます。詳細については、[AWS Glue のドキュメント](https://docs.aws.amazon.com/glue/latest/dg/console-connections.html)を参照してください。 | MongoDB DBA | | ソースデータベースまたはソースストリーム AWS Glue との の接続を確立します。 | これにより、ターゲット環境の移行準備ができます。 | MongoDB DBA | | データ変換を設定します。 | 従来の構造化スキーマから MongoDB の柔軟なスキーマにデータを移行するための変換ロジックを設定します。 | MongoDB DBA | | データを移行します。 | AWS Glue Studioで移行をスケジュールします。 | MongoDB DBA | ### 操作統合の設定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | クラスターに接続します。 | MongoDB Atlas クラスターに接続します。 | アプリ開発者 | | データを操作します。 | クラスターデータと対話します。 | アプリ開発者 | | クラスターをモニタリングします。 | MongoDB Atlas クラスターをモニタリングします。 | MongoDB DBA | | データをバックアップおよび復元します。 | クラスターデータをバックアップし、復元します。 | MongoDB DBA | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | 問題が発生した場合 | MongoDB Atlas CloudFormation Resources リポジトリの「[トラブルシューティング](https://github.com/mongodb/mongodbatlas-cloudformation-resources/tree/master#troubleshooting)」を参照してください。 | ## 関連リソース 特に明記されていない限り、以下のリンクはすべて MongoDB ドキュメントのウェブページに移動します。 **移行ガイド** + [での MongoDB Atlas への移行 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-atlas/) (AWS 規範ガイダンス) 発見と評価 + 「[メモリ](https://docs.atlas.mongodb.com/sizing-tier-selection/#memory)」 + 「[Atlas サンプルデータセットによるサイジングの例](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#example--the-service-sample-data-sets)」 + 「[モバイルアプリケーションのサイジング例](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#example--mobile-app)」 + 「[ネットワークトラフィック](https://docs.atlas.mongodb.com/sizing-tier-selection/#network-traffic)」 + 「[クラスターの自動スケーリング](https://www.mongodb.com/docs/atlas/sizing-tier-selection/#cluster-auto-scaling)」 + 「[Atlas サイジングテンプレート](https://view.highspot.com/viewer/5f438f47a4dfa042e97130c5)」 セキュリティとコンプライアンスの設定 + 「[IP アクセスリストエントリの設定](https://docs.atlas.mongodb.com/security/ip-access-list/)」 + [データベースユーザーの設定](https://docs.atlas.mongodb.com/security-add-mongodb-users/) + [Atlas UI へのアクセスの設定](https://docs.atlas.mongodb.com/organizations-projects/) + [カスタムデータベースロールの設定](https://docs.atlas.mongodb.com/security-add-mongodb-roles) + [データベースユーザーの設定](https://docs.atlas.mongodb.com/security-add-mongodb-users/#atlas-user-privileges) + 「[ネットワークピアリング接続の設定](https://docs.atlas.mongodb.com/security-vpc-peering/)」 + [Atlas のプライベートエンドポイントについて学ぶ](https://docs.atlas.mongodb.com/security-private-endpoint/) + [多要素認証オプションの管理](https://docs.atlas.mongodb.com/security-two-factor-authentication/) + 「[LDAP によるユーザー認証と認可の設定](https://docs.atlas.mongodb.com/security-ldaps/)」 + 「[Atlas データレイク](https://docs.mongodb.com/datalake/)」 + 「[顧客キー管理による静的暗号化](https://docs.atlas.mongodb.com/security-kms-encryption/)」 + [ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) (IAM ドキュメント) + 「[クライアント側のフィールドレベルの暗号化の設定](https://docs.mongodb.com/manual/core/security-client-side-encryption)」 + [自動暗号化](https://docs.mongodb.com/manual/core/security-automatic-client-side-encryption)  + [MongoDB Atlas のセキュリティコントロール](https://webassets.mongodb.com/_com_assets/cms/MongoDB_Atlas_Security_Controls-v7k3rbhi3p.pdf) + [MongoDB トラストセンター](https://www.mongodb.com/cloud/trust) + [クラスターのセキュリティ機能の設定](https://docs.atlas.mongodb.com/setup-cluster-security/) **AWS** **上に新しい MongoDB Atlas 環境を設定する** + 「[クラウドプロバイダーとリージョン](https://docs.atlas.mongodb.com/cloud-providers-regions/)」 + [グローバルクラスターの管理](https://docs.atlas.mongodb.com/global-clusters/) + [クラスター階層の選択](https://www.mongodb.com/docs/atlas/manage-clusters/#select-cluster-tier) + [追加の設定](https://docs.atlas.mongodb.com/cluster-additional-settings/) + [Atlas の使用開始](https://docs.atlas.mongodb.com/getting-started/) + [Atlas UI へのアクセスの設定](https://docs.atlas.mongodb.com/organizations-projects/) **データを移行する** + [データを移行またはインポートする](https://www.mongodb.com/docs/atlas/import/) **クラスターのモニタリング** + [クラスターをモニタリングする](https://docs.atlas.mongodb.com/monitoring-alerts/) オペレーションの統合 + 「[クラスターへの接続](https://docs.atlas.mongodb.com/connect-to-cluster/)」 + [データを操作する](https://docs.atlas.mongodb.com/data-explorer/) + [クラスターをモニタリングする](https://docs.atlas.mongodb.com/monitoring-alerts/) + [データをバックアップ、復元、およびアーカイブする](https://docs.atlas.mongodb.com/backup-restore-cluster/) **GitHub リポジトリ** + [を使用して MongoDB Atlas にデータをストリーミングする AWS Glue](https://github.com/mongodb-partners/Stream_Data_into_MongoDB_AWS_Glue?tab=readme-ov-file#troubleshooting) # Amazon RDS Custom for Oracle 上の Oracle PeopleSoft アプリケーションの移行ロール *Amazon Web Services、sampath kathirvel* ## 概要 Amazon Web Services (AWS) で [Oracle PeopleSoft](https://www.oracle.com/applications/peoplesoft/) エンタープライズリソースプランニング (ERP) ソリューションを実行するには、[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) または [Amazon RDS Custom for Oracle](https://aws.amazon.com/rds/custom/) を使用できます。これらは、基盤となるオペレーティングシステム (OS) とデータベース環境へのアクセスを必要とするレガシー、カスタム、およびパッケージ化されたアプリケーションをサポートします。移行を計画する際に考慮すべき主な要素については、「AWS 規範ガイダンス」 の「[Oracle データベースの移行戦略](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-oracle-database/strategies.html)」を参照してください。 このパターンは、読み込みレプリカデータベースを備えたプライマリデータベースとして Amazon RDS Custom で実行されている PeopleSoft アプリケーションデータベースの Oracle Data Guard スイッチオーバーまたはロール移行を実行するステップに焦点を当てています。このパターンには、[ファストスタートフェイルオーバー (FSFO)](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/using-data-guard-broker-to-manage-switchovers-failovers.html#GUID-D26D79F2-0093-4C0E-98CD-224A5C8CBFA4) を構成するステップが含まれています。このプロセス中、Oracle Data Guard 構成内のデータベースは引き続き新しい役割で機能します。Oracle Data Guard のスイッチオーバーの一般的なユースケースとしては、ディザスタリカバリ（DR）ドリル、データベースの定期メンテナンスアクティビティ、[スタンバイファーストパッチ適用](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/upgrading-patching-downgrading-oracle-data-guard-configuration.html#GUID-A5226768-DB6B-4714-BB9A-0A3EF17A01C8)ローリングパッチなどがあります。詳細については、ブログ記事「[Amazon RDS Custom のデータベースパッチのダウンタイムを削減する](https://aws.amazon.com/blogs/database/reduce-database-patching-downtime-in-amazon-rds-custom-for-oracle-using-oracle-data-guard-standby-first-patch-apply/)」を参照してください。 ## 前提条件と制限事項 **前提条件** + [読み込みレプリカパターンを使用して Amazon RDS Custom でOracle PeopleSoft に HA を追加する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/add-ha-to-oracle-peoplesoft-on-amazon-rds-custom-by-using-a-read-replica.html)」パターンを完了する。 **機能制限** + [RDS Custom for Oracle](https://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/custom-reqs-limits.html#custom-reqs-limits.limits) で制限されている構成およびサポートされていない構成 + [Amazon RDS Custom for Oracle リードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-rr.html#custom-rr.limitations)に関連する制限 **製品バージョン** + Amazon RDS Custom でサポートされている Oracle データベースのバージョンについては、「[RDS Custom for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.html#Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.ora)」を参照してください。 + Amazon RDS Customでサポートされている Oracle データベースインスタンスクラスについては、「[RDS Custom for Oracle用 DB インスタンスクラスサポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits.html#custom-reqs-limits.instances)」を参照してください。 ## アーキテクチャ **テクノロジースタック** + Amazon RDS Custom for Oracle **ターゲットアーキテクチャ** 次の図は、Amazon RDS Custom DB インスタンスと Amazon RDS Custom 読み込みレプリカを示しています。Oracle Data Guard は、DR のフェイルオーバー中にロールを移行します。 ![\[プライマリ RDS Custom DB インスタンスとリードレプリカデータベースに対する Oracle Data Guard のスイッチオーバー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/da3b011c-1668-4de4-9079-0982888a74b4/images/4e2a2f3b-b5bd-44b7-9b5a-13a663ee3be6.png) AWS で Oracle PeopleSoft を使用する代表的なアーキテクチャについては、「[AWS で可用性の高い PeopleSoft アーキテクチャの設定](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/set-up-a-highly-available-peoplesoft-architecture-on-aws.html)」を参照してください。 ## ツール ** サービス** + [Amazon RDS Custom for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/working-with-custom-oracle.html) は、基盤となる OS とデータベース環境へのアクセスを必要とするレガシー、カスタム、およびパッケージアプリケーション向けのマネージドデータベースサービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。このパターンでは、シークレット名 `do-not-delete-rds-custom-+<>+-dg` を使用して Secrets Manager から `RDS_DATAGUARD` のデータベースユーザーパスワードを取得します。 **その他のサービス** + [Oracle Data Guard](https://docs.oracle.com/en/database/oracle/oracle-database/21/sbydb/introduction-to-oracle-data-guard-concepts.html#GUID-5E73667D-4A56-445E-911F-1E99092DD8D7) は、スタンバイ・データベースの作成、保守、管理、モニタリングに役立ちます。このパターンでは、ロールの移行に Oracle Data Guard Maximum Performance を使用します（[Oracle Data Guard のスイッチオーバー](https://docs.oracle.com/database/121/DGBKR/sofo.htm#DGBKR330)）。 ## ベストプラクティス 本番環境へのデプロイでは、オブザーバーインスタンスをプライマリノードやリードレプリカノードとは別の 3 番目のアベイラビリティゾーンで起動することをお勧めします。 ## エピック ### ロールの移行を開始する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライマリとレプリカの両方のデータベースの自動化を一時停止する。 | RDS Custom の自動化フレームワークはロール移行プロセスを妨げませんが、Oracle Data Guard のスイッチオーバー中は自動化を一時停止することをお勧めします。RDS Custom データベースの自動化を一時停止して再開するには、「[RDS Custom 自動化の一時停止と再開](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-managing.html#custom-managing.pausing)」の手順に従ってください。 | クラウド管理者、DBA | | Oracle Data Guard のステータスをチェックします。 | Oracle Data Guard のステータスを確認するには、プライマリデータベースにログインします。このパターンには、マルチテナントコンテナデータベース (CDB) または 非 CDB インスタンスを使用するコードが含まれています。**非 CDB**
-bash-4.2$ dgmgrl RDS_DATAGUARD@RDS_CUSTOM_ORCL_A
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Nov 28 20:55:50 2022
Version 19.10.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "ORCL_A"
Connected as SYSDG.
DGMGRL> show configuration
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_a - Primary database
orcl_d - Physical standby database 
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 59 seconds ago)
DGMGRL>
**CDB**
CDB-bash-4.2$ dgmgrl C##RDS_DATAGUARD@RDS_CUSTOM_RDSCDB_A
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Jan 18 06:13:07 2023
Version 19.16.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "RDSCDB_A"
Connected as SYSDG.
DGMGRL> show configuration
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_a - Primary database
    rdscdb_b - Physical standby database 
Fast-Start Failover:  Disabled
Configuration Status:
SUCCESS   (status updated 52 seconds ago)
DGMGRL>
| DBA | | インスタンスロールを検証します。 | AWS マネジメントコンソール にサインインして、Amazon RDS コンソールを開きます。データベースの [**レプリケーション**] セクションの [**接続とセキュリティ**] タブで、プライマリとレプリカのインスタンスロールを確認します。プライマリロールは Oracle Data Guard プライマリデータベースと一致し、レプリカロールは Oracle Data Guard のフィジカルスタンバイデータベースと一致する必要があります。 | クラウド管理者、DBA | | スイッチオーバーを実行します。 | スイッチオーバーを実行するには、プライマリノードから `DGMGRL` に接続します。**非 CDB**
DGMGRL> switchover to orcl_d;
Performing switchover NOW, please wait...
Operation requires a connection to database "orcl_d"
Connecting ...
Connected to "ORCL_D"
Connected as SYSDG.
New primary database "orcl_d" is opening...
Operation requires start up of instance "ORCL" on database "orcl_a"
Starting instance "ORCL"...
Connected to an idle instance.
ORACLE instance started.
Connected to "ORCL_A"
Database mounted.
Database opened.
Connected to "ORCL_A"
Switchover succeeded, new primary is "orcl_d"
DGMGRL>
**CDB**
DGMGRL> switchover to rdscdb_b
Performing switchover NOW, please wait...
New primary database "rdscdb_b" is opening...
Operation requires start up of instance "RDSCDB" on database "rdscdb_a"
Starting instance "RDSCDB"...
Connected to an idle instance.
ORACLE instance started.
Connected to "RDSCDB_A"
Database mounted.
Database opened.
Connected to "RDSCDB_A"
Switchover succeeded, new primary is "rdscdb_b"
| DBA | | Oracle Data Guard の接続を検証します。 | スイッチオーバー後、プライマリノードから `DGMGRL` へのOracle Data Guard の接続を確認します。**非 CDB**
DGMGRL> show configuration;
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_d - Primary database
orcl_a - Physical standby database 
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 60 seconds ago)
DGMGRL> 

DGMGRL> show configuration lag;
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_d - Primary database
orcl_a - Physical standby database 
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 44 seconds ago)
DGMGRL>
**CDB**
DGMGRL> show configuration
DGMGRL> show configuration
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_b - Primary database
    rdscdb_a - Physical standby database 
Fast-Start Failover:  Disabled
Configuration Status:
SUCCESS   (status updated 52 seconds ago)
DGMGRL> 

DGMGRL> show configuration lag
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_b - Primary database
    rdscdb_a - Physical standby database 
               Transport Lag:      0 seconds (computed 0 seconds ago)
               Apply Lag:          0 seconds (computed 0 seconds ago)
Fast-Start Failover:  Disabled
Configuration Status:
SUCCESS   (status updated 53 seconds ago)
DGMGRL>
| DBA | | Amazon RDS コンソールでインスタンスロールを検証します。 | ロールの切り替えを実行すると、Amazon RDS コンソールで、 [**データベース**] の [**接続とセキュリティ**] タブの [**レプリケーション**] セクションに新しいロールが表示されます。**[レプリケーションの状態]** が空から **[レプリケーション中]** に更新されるまでに数分かかる場合があります。 | DBA | ### FSFO を構成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | スイッチオーバーをリセットします。 | スイッチオーバーをプライマリノードに再設定します。 | DBA | | オブザーバーをインストールして起動する。 | オブザーバープロセスは `DGMGRL` クライアントコンポーネントで、通常はプライマリデータベースやスタンバイデータベースとは別のマシンで動作します。オブザーバー用の ORACLE HOME インストールは、Oracle Client Administrator でもかまいませんし、Oracle Database エンタープライズエディションまたはパーソナルエディションのいずれかをインストールすることも可能です。ご使用のデータベースリリースに合わせたオブザーバーのインストールについては、「[オブザーバーのインストールと起動](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/using-data-guard-broker-to-manage-switchovers-failovers.html#GUID-11EF3897-8FCA-4A54-B63B-E8C1668AE21B)」を参照してください。オブザーバープロセスのハイアベイラビリティー構成には、次の操作を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/transition-roles-for-an-oracle-peoplesoft-application-on-amazon-rds-custom-for-oracle.html)Oracle 12c リリース 2 以降では、最大 3 つのオブザーバーをデプロイできます。1 つのオブザーバーがプライマリオブザーバーで、残りはバックアップオブザーバーです。プライマリオブザーバーに障害が発生すると、バックアップオブザーバーの 1 つがプライマリの役割を果たします。 | DBA | | オブザーバーホストから DGMGRL に接続します。 | オブザーバーホストには、プライマリデータベース接続とスタンバイデータベース接続用の `tnsnames.ora` エントリが構成されています。データ損失が [FFastStartFailOverLagLimit](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/oracle-data-guard-broker-properties.html) 構成 (秒単位) の範囲内であれば、maximum performance 保護モードで FSFO を有効にできます。ただし、データ損失をゼロ (RPO=0) にするには maximum availability 保護モードを使用する必要があります。**非 CDB**
DGMGRL> show configuration;
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_a - Primary database
orcl_d - Physical standby database 
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 58 seconds ago)
DGMGRL> show configuration lag
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_a - Primary database
orcl_d - Physical standby database 
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 5 seconds ago)
DGMGRL>
**CDB**
-bash-4.2$ dgmgrl C##RDS_DATAGUARD@RDS_CUSTOM_RDSCDB_A
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Jan 18 06:55:09 2023
Version 19.16.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
Welcome to DGMGRL, type "help" for information.
Password:
Connected to "RDSCDB_A"
Connected as SYSDG.
DGMGRL> show configuration
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_a - Primary database
    rdscdb_b - Physical standby database 
Fast-Start Failover:  Disabled
Configuration Status:
SUCCESS   (status updated 18 seconds ago)
DGMGRL>
| DBA | | スタンバイデータベースをフェイルオーバーターゲットに変更します。 | プライマリノードまたはオブザーバーノードから 1 つのスタンバイデータベースに接続します。(構成には複数のスタンバイデータベースがあってもかまいませんが、この時点で接続する必要があるのは 1 つだけです)。**非 CDB**
DGMGRL> edit database orcl_a set property FastStartFailoverTarget='orcl_d';
Property "faststartfailovertarget" updated
DGMGRL> edit database orcl_d set property FastStartFailoverTarget='orcl_a';
Property "faststartfailovertarget" updated
DGMGRL> show database orcl_a FastStartFailoverTarget;
FastStartFailoverTarget = 'orcl_d'
DGMGRL> show database orcl_d FastStartFailoverTarget;
FastStartFailoverTarget = 'orcl_a'
DGMGRL>
**CDB**
DGMGRL> edit database orcl_a set property FastStartFailoverTarget='rdscdb_b';
Object "orcl_a" was not found
DGMGRL> edit database rdscdb_a set property FastStartFailoverTarget='rdscdb_b';
Property "faststartfailovertarget" updated
DGMGRL> edit database rdscdb_b set property FastStartFailoverTarget='rdscdb_a';
Property "faststartfailovertarget" updated
DGMGRL> show database rdscdb_a FastStartFailoverTarget;
  FastStartFailoverTarget = 'rdscdb_b'
DGMGRL> show database rdscdb_b FastStartFailoverTarget;
  FastStartFailoverTarget = 'rdscdb_a'
DGMGRL>
| DBA | | DGMGRL への接続にファストスタートフェイルオーバーのしきい値を構成します。 | Oracle 19c のデフォルト値は 30 秒で、最小値は 6 秒です。値を小さくすると、フェイルオーバー時の目標復旧時間 (RTO) が短くなる可能性があります。値を高くすると、プライマリデータベースで不必要なフェイルオーバーの一時エラーが発生する可能性が低減されます。RDS Custom for Oracle 自動化フレームワークは、データベースの状態をモニタリングし、数秒ごとに修正アクションを実行します。そのため、FastStartFailoverThreshold は 10 秒より大きい値に設定することをお勧めします。次の例では、しきい値を 35 秒に構成しています。**非 CBD または CDB**
DGMGRL> edit configuration set property FastStartFailoverThreshold=35;
Property "faststartfailoverthreshold" updated
DGMGRL> show configuration FastStartFailoverThreshold;
FastStartFailoverThreshold = '35'
DGMGRL>
| DBA | | プライマリノードまたはオブザーバーノードから DGMGRL に接続して FSFO を有効にします。 | データベースで[フラッシュバックデータベース](https://docs.oracle.com/en/database/oracle/oracle-database/19/rcmrf/FLASHBACK-DATABASE.html#GUID-584AC79A-40C5-45CA-8C63-DED3BE3A4511)が有効になっていない場合は、警告メッセージ `ORA-16827` が表示されます。オプションのフラッシュバックデータベースは、[FastStartFailoverAutoReinstate](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/oracle-data-guard-broker-properties.html#GUID-824E97C0-EEB0-4E1B-BD4A-F5AE282CEA28) 構成プロパティが `TRUE` (デフォルト) に構成されている場合、障害が発生したプライマリデータベースをフェイルオーバー前のある時点まで自動的に復元するのに役立ちます。**非 CDB**
DGMGRL> enable fast_start failover;
Warning: ORA-16827: Flashback Database is disabled
Enabled in Zero Data Loss Mode.
DGMGRL> 
DGMGRL> show configuration
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_a - Primary database
Warning: ORA-16819: fast-start failover observer not started
orcl_d - (*) Physical standby database 
Warning: ORA-16819: fast-start failover observer not started
Fast-Start Failover: Enabled in Zero Data Loss Mode
Configuration Status:
WARNING (status updated 29 seconds ago)
DGMGRL>
**CDB**
DGMGRL> enable fast_start failover;
Warning: ORA-16827: Flashback Database is disabled
Enabled in Zero Data Loss Mode.
DGMGRL> show configuration;
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_a - Primary database
    Warning: ORA-16819: fast-start failover observer not started
    rdscdb_b - (*) Physical standby database 
Fast-Start Failover: Enabled in Zero Data Loss Mode
Configuration Status:
WARNING   (status updated 11 seconds ago)
DGMGRL>
| DBA | | FSFO モニタリング用のオブザーバーを起動し、ステータスを確認します。 | FSFO を有効にする前でも後でもオブザーバーを起動できます。FSFO がすでに有効になっている場合、オブザーバーはただちにプライマリおよびターゲットのスタンバイデータベースの状態と接続のモニタリングを開始します。FSFO が有効になっていない場合、オブザーバーは FSFO が有効になるまでモニタリングを開始しません。オブザーバーを起動すると、前の `show configuration` コマンドで確認したように、プライマリ DB 構成がエラーメッセージなしで表示されます。**非 CDB**
DGMGRL> start observer;
[W000 2022-12-01T06:16:51.271+00:00] FSFO target standby is orcl_d
Observer 'ip-10-0-1-89' started
[W000 2022-12-01T06:16:51.352+00:00] Observer trace level is set to USER

DGMGRL> show configuration
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_a - Primary database
orcl_d - (*) Physical standby database 
Fast-Start Failover: Enabled in Zero Data Loss Mode
Configuration Status:
SUCCESS (status updated 56 seconds ago)
DGMGRL> 

DGMGRL> show observer
Configuration - rds_dg
Primary: orcl_a
Active Target: orcl_d
Observer "ip-10-0-1-89" - Master
Host Name: ip-10-0-1-89
Last Ping to Primary: 1 second ago
Last Ping to Target: 1 second ago
DGMGRL>
**CDB**
DGMGRL> start observer;
Succeeded in opening the observer file "/home/oracle/fsfo_ip-10-0-1-56.dat".
[W000 2023-01-18T07:31:32.589+00:00] FSFO target standby is rdscdb_b
Observer 'ip-10-0-1-56' started
The observer log file is '/home/oracle/observer_ip-10-0-1-56.log'.

DGMGRL> show configuration
Configuration - rds_dg
  Protection Mode: MaxAvailability
  Members:
  rdscdb_a - Primary database
    rdscdb_b - (*) Physical standby database 
Fast-Start Failover: Enabled in Zero Data Loss Mode
Configuration Status:
SUCCESS   (status updated 12 seconds ago)
DGMGRL> 

DGMGRL> show observer;
Configuration - rds_dg
  Primary:            rdscdb_a
  Active Target:      rdscdb_b
Observer "ip-10-0-1-56" - Master
  Host Name:                    ip-10-0-1-56
  Last Ping to Primary:         1 second ago
  Last Ping to Target:          2 seconds ago
DGMGRL>
| DBA | | フェイルオーバーを検証します。 | このシナリオでは、プライマリ EC2 インスタンスを手動で停止することでフェイルオーバーテストを実行できます。EC2 インスタンスを停止する前に、構成に基づいて `tail` コマンドを使用してオブザーバーログファイルをモニタリングします。`DGMGRL` を使用してスタンバイデータベース `orcl_d` にユーザー `RDS_DATAGUARD` でログインし、Oracle Data Guard のステータスを確認します。`orcl_d` が新しいプライマリデータベースであることが表示されるはずです。このフェイルオーバーテストシナリオでは、`orcl_d` は非 CDB のデータベースです。フェイルオーバー前は、フラッシュバックデータベースは `orcl_a` で有効になっていました。元のプライマリデータベースがオンラインに戻り、`MOUNT` の状態で起動すると、オブザーバーはそのデータベースを新しいスタンバイデータベースに復元します。復元されたデータベースは、新しいプライマリデータベースの FSFO ターゲットとして機能します。詳細はオブザーバーログで確認できます。
DGMGRL> show configuration
Configuration - rds_dg
Protection Mode: MaxAvailability
Members:
orcl_d - Primary database
Warning: ORA-16824: multiple warnings, including fast-start failover-related warnings, detected for the database
orcl_a - (*) Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: Enabled in Zero Data Loss Mode
Configuration Status:
WARNING (status updated 25 seconds ago)
DGMGRL>
`observer.log` の出力例を次に示します。
$ tail -f /tmp/observer.log
Unable to connect to database using rds_custom_orcl_a
[W000 2023-01-18T07:50:32.589+00:00] Primary database cannot be reached.
[W000 2023-01-18T07:50:32.589+00:00] Fast-Start Failover threshold has expired.
[W000 2023-01-18T07:50:32.590+00:00] Try to connect to the standby.
[W000 2023-01-18T07:50:32.590+00:00] Making a last connection attempt to primary database before proceeding with Fast-Start Failover.
[W000 2023-01-18T07:50:32.591+00:00] Check if the standby is ready for failover.
[S002 2023-01-18T07:50:32.591+00:00] Fast-Start Failover started...
2023-01-18T07:50:32.591+00:00
Initiating Fast-Start Failover to database "orcl_d"...
[S002 2023-01-18T07:50:32.592+00:00] Initiating Fast-start Failover.
Performing failover NOW, please wait...
Failover succeeded, new primary is "orcl_d"
2023-01-18T07:55:32.101+00:00
[S002 2023-01-18T07:55:32.591+00:00] Fast-Start Failover finished...
[W000 2023-01-18T07:55:32.591+00:00] Failover succeeded. Restart pinging.
[W000 2023-01-18T07:55:32.603+00:00] Primary database has changed to orcl_d.
[W000 2023-01-18T07:55:33.618+00:00] Try to connect to the primary.
[W000 2023-01-18T07:55:33.622+00:00] Try to connect to the primary rds_custom_orcl_d.
[W000 2023-01-18T07:55:33.634+00:00] The standby orcl_a needs to be reinstated
[W000 2023-01-18T07:55:33.654+00:00] Try to connect to the new standby orcl_a.
[W000 2023-01-18T07:55:33.654+00:00] Connection to the primary restored!
[W000 2023-01-18T07:55:35.654+00:00] Disconnecting from database rds_custom_orcl_d.
[W000 2023-01-18T07:55:57.701+00:00] Try to connect to the new standby orcl_a.
ORA-12170: TNS:Connect timeout occurred
| DBA | ### Oracle PeopleSoft アプリケーションとデータベース間の接続を構成する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | プライマリデータベースでサービスを作成して開始します。 | プライマリデータベースエンドポイントとスタンバイデータベースエンドポイントの両方を含む TNS エントリを構成に使用することで、ロールの移行中にアプリケーション構成が変更されるのを防ぐことができます。読み取り/書き込みワークロードと読み取り専用ワークロードの両方をサポートする 2 つのロールベースのデータベースサービスを定義できます。次の例では、`orcl_rw` はプライマリデータベースでアクティブな読み取り/書き込みサービスです。`orcl_ro` は読み取り専用モードで開かれた、スタンバイデータベースでアクティブな読み取り専用サービスです。
SQL> select name,open_mode from v$database;
NAME OPEN_MODE
--------- --------------------
ORCL READ WRITE
SQL> exec dbms_service.create_service('orcl_rw','orcl_rw');
PL/SQL procedure successfully completed.
SQL> exec dbms_service.create_service('orcl_ro','orcl_ro');
PL/SQL procedure successfully completed.

SQL> exec dbms_service.start_service('orcl_rw');
PL/SQL procedure successfully completed.
SQL>
| DBA | | スタンバイデータベースでサービスを起動する。 | 読み取り専用のスタンバイデータベースでサービスを起動するには、次のコードを使用します。
SQL> select name,open_mode from v$database;
NAME OPEN_MODE
--------- --------------------
ORCL READ ONLY WITH APPLY
SQL> exec dbms_service.start_service('orcl_ro');
PL/SQL procedure successfully completed.
SQL>
| DBA | | プライマリ DB の再起動時にサービスを自動的に開始します。 | プライマリデータベースの再起動時にサービスを自動的に開始するには、次のコードを使用します。
SQL> CREATE OR REPLACE TRIGGER TrgDgServices after startup on database
DECLARE
db_role VARCHAR(30);
db_open_mode VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE, OPEN_MODE INTO db_role, db_open_mode FROM V$DATABASE;
IF db_role = 'PRIMARY' THEN
DBMS_SERV 2 ICE.START_SERVICE('orcl_rw');
END IF;
IF db_role = 'PHYSICAL STANDBY' AND db_open_mode LIKE 'READ ONLY%' THEN
DBMS_SERVICE.START_SERVICE('orcl_ro');
END IF;
END;
/ 
Trigger created.
SQL>
| DBA | | 読み取り/書き込みデータベースと読み取り専用データベース間の接続を構成します。 | 次のアプリケーション構成例を読み取り/書き込み接続と読み取り専用接続に使用できます。
ORCL_RW = (DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=devpsftdb.******.us-west-2.rds.amazonaws.com)(PORT=1521))
(ADDRESS = (PROTOCOL = TCP)(HOST=psftread.******.us-west-2.rds.amazonaws.com)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME = orcl_rw))
)
ORCL_RO = (DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST=devpsftdb.******.us-west-2.rds.amazonaws.com)(PORT=1521))
(ADDRESS = (PROTOCOL = TCP)(HOST=psftread.******.us-west-2.rds.amazonaws.com)(PORT=1521))
)
(CONNECT_DATA=(SERVICE_NAME = orcl_ro))
)
| DBA | ## 関連リソース + [Amazon RDS Custom for Oracle でData Guardのハイアベイラビリティを有効にする](https://d1.awsstatic.com/whitepapers/enabling-high-availability-with-data-guard-on-amazon-rds-custom-for-oracle.pdf) (AWS テクニカルガイド) + [Amazon RDS を Oracle PeopleSoft Databaseとして構成する](https://d1.awsstatic.com/whitepapers/configuring-amazon-rds-as-peoplesoft-database.pdf) (AWS ホワイトペーパー) + [Oracle Data Guard Broker ガイド](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/index.html) (Oracle リファレンスドキュメント) + [Data Guard の概要および管理 ](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/index.html)(Oracle リファレンスドキュメント) + [Oracle Data Guard 固有の FAN および FCF 構成要件](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/using-data-guard-broker-to-manage-switchovers-failovers.html#GUID-DFFDAA2B-A889-49AD-AB85-747D73FF0FF5) (Oracle リファレンスドキュメント) # アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする *Andrew Kamel、Amazon Web Services* ## 概要 アプリケーションをテストするときは、テスト環境に本番データを使用すると便利です。本番データを使用することで、開発中のアプリケーションをより正確に評価できます。 このパターンは、本番環境の Amazon Redshift クラスターから、Amazon Web Services (AWS) の開発環境の Amazon Simple Storage Service (Amazon S3) バケットにデータを抽出します。 このパターンは、以下を含む開発用アカウントと本番稼働用アカウントの両方のセットアップを段階的に行います。 + 必要なリソース + AWS Identity and Access Management (IAM) ロール + Amazon Redshift 接続をサポートするためのサブネット、セキュリティグループ、仮想プライベートクラウド (VPC) のネットワーク調整 + アーキテクチャをテストするための Python ランタイムを使用する AWS Lambda 関数の例 Amazon Redshift クラスターへのアクセスを許可するために、このパターンは AWS Secrets Manager を使用して関連する認証情報を保存します。Amazon Redshift クラスターの場所がわからなくても、Amazon Redshift クラスターに直接接続するために必要なすべての情報を取得できます。さらに、[シークレットの使用をモニタリング](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)できます。 Secrets Manager に保存されるシークレットには、Amazon Redshift クラスターのホスト、データベース名、ポート、および関連する認証情報が含まれます。 このパターンを使用する際のセキュリティ上の考慮事項については、「[ベストプラクティス](#unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3-best-practices)」セクションを参照してください。 ## 前提条件と制限事項 **前提条件** + 本番稼働用アカウントで[実行している Amazon Redshift クラスター](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) + 開発用アカウントで[作成した S3 バケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) + 開発用アカウントと本番稼働用アカウント間の [VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html)と、それに応じて[調整されたルートテーブル](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) + 両方のピア接続された VPC の[有効な DNS ホスト名および DNS 解決](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) **制限事項** + クエリするデータの量によっては、Lambda 関数がタイムアウトする場合があります。 実行に Lambda の最長タイムアウト (15 分) よりも時間がかかる場合は、Lambda コードに非同期アプローチを使用します。このパターンのコード例では、Python 用の [psycopg2](https://github.com/psycopg/psycopg2) ライブラリを使用していますが、psycopg2 は現在非同期処理をサポートしていません。 + 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」ページを参照して、サービスのリンクを選択します。 ## アーキテクチャ 次の図は、開発用アカウントと本番稼働用アカウントが含まれるターゲットアーキテクチャを示しています。 ![\[開発用アカウントの Lambda VPC と本番稼働用アカウントの Amazon Redshift VPC。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5c83c617-3a85-4aea-a7a7-930f406d1cef/images/fa4d01df-483d-4454-9711-b391ebbe4629.png) この図表は、次のワークフローを示しています: 1. 開発用アカウントの Lambda 関数は、本番稼働用アカウントの Secrets Manager の Amazon Redshift 認証情報にアクセスするために必要な IAM ロールを引き受けます。 次に、Lambda 関数は Amazon Redshift クラスターのシークレットを取得します。 1. 開発用アカウントの Lambda 関数は、この情報を使用して、ピア接続された VPC を介して本番稼働用アカウントの Amazon Redshift クラスターに接続します。 次に、Lambda 関数はアンロードコマンドを送信して、本番稼働用アカウントの Amazon Redshift クラスターでクエリを実行します。 1. 本番稼働用アカウントの Amazon Redshift クラスターは、開発用アカウントの S3 バケットにアクセスするための関連する IAM ロールを引き受けます。 Amazon Redshift クラスターは、クエリされたデータを開発用アカウントの S3 バケットにアンロードします。 **Amazon Redshift からのデータのクエリ** 次の図は、Amazon Redshift 認証情報を取得して Amazon Redshift クラスターに接続するために使用するロールを示しています。ワークフローは Lambda 関数が開始します。 ![\[アカウント間でロールを引き受けるための 3 ステップのプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5c83c617-3a85-4aea-a7a7-930f406d1cef/images/ab25b72c-773c-4d58-9012-4a3755c181ff.png) この図表は、次のワークフローを示しています: 1. 開発用アカウントの `CrossAccount-SM-Read-Role` は、本番稼働用アカウントの `SM-Read-Role` を引き受けます。 1. `SM-Read-Role` ロールは、アタッチされているポリシーを使用して Secrets Manager からシークレットを取得します。 1. 認証情報は、Amazon Redshift クラスターにアクセスにする際に使用されます。 **Simple Storage Service (Amazon S3) へのデータのアップロード** 次の図表は、データを抽出して Amazon S3 にアップロードするためのクロスアカウント読み取り/書き込みプロセスを示しています。ワークフローは Lambda 関数が開始します。パターンは [Amazon Redshift の IAM ロールを連鎖](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html#authorizing-redshift-service-chaining-roles)します。Amazon Redshift クラスターから送信されるアンロードコマンドは、`CrossAccount-S3-Write-Role` を引き受け、次に `S3-Write-Role` を引き受けます。このロールの連鎖により、Amazon Redshift は Amazon S3 にアクセスできるようになります。 ![\[認証情報の取得、Amazon Redshift へのアクセス、Amazon S3 へのデータのアップロードを行うロール。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5c83c617-3a85-4aea-a7a7-930f406d1cef/images/d2982fc6-1d12-4f9d-9493-a99ce691d693.png) このワークフローには、次の手順が含まれます。 1. 開発用アカウントの `CrossAccount-SM-Read-Role` は、本番稼働用アカウントの `SM-Read-Role` を引き受けます。 1. `SM-Read-Role` は、Secrets Manager から Amazon Redshift 認証情報を取得します。 1. Lambda 関数は、Amazon Redshift クラスターに接続し、クエリを送信します。 1. Amazon Redshift クラスターは `CrossAccount-S3-Write-Role` を引き受けます。 1. `CrossAccount-S3-Write-Role` は、開発用アカウントの `S3-Write-Role` を引き受けます。 1. クエリ結果は、開発用アカウントの S3 バケットにアンロードされます。 ## ツール **AWS のサービス** + [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。 + [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。 + [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/getting-started.html) は、AWS クラウド内でのフルマネージド型、ペタバイト規模のデータウェアハウスサービスです。 + [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。 + [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。 **コードリポジトリ** このパターンのコードは、GitHub 内の「[unload-redshift-to-s3-python](https://github.com/aws-samples/unload-redshift-to-s3-python/)」リポジトリで入手できます。 ## ベストプラクティス **セキュリティについての免責事項** このソリューションを実装する前に、以下の重要なセキュリティ上の推奨事項を検討してください。 + 開発用アカウントと本番稼働用アカウントを接続すると、スコープが拡大し、全体的なセキュリティ体制が低下する可能性があることに注意してください。このソリューションは一時的にのみデプロイし、必要なデータを抽出してから、すぐにデプロイされたリソースを破棄することを推奨します。リソースを破棄するには、Lambda 関数を削除し、このソリューション用に作成された IAM ロールとポリシーを削除し、アカウント間で付与されたネットワークアクセス権を取り消す必要があります。 + データを本番環境から開発環境にコピーする前に、セキュリティチームとコンプライアンスチームに相談してください。個人を特定できる情報 (PII)、保護対象医療情報 (PHI)、その他の機密データや規制対象データは、通常、この方法でコピーしてはいけません。公開されている非機密情報 (ショップのフロントエンドからの公開株式データなど) のみをコピーしてください。本番データの使用ではなく、可能な限り、データのトークン化や匿名化、または合成テストデータの生成を検討してください。[AWS セキュリティ原則](https://docs.aws.amazon.com/en_us/wellarchitected/2022-03-31/framework/sec-design.html)の 1 つは、データからユーザーを遠ざけることです。つまり、デベロッパーは本番稼働用アカウントでオペレーションを実行してはいけません。 + 開発アカウントの Lambda 関数は本番環境の Amazon Redshift クラスターからデータを読み取ることができるため、Lambda 関数へのアクセスを制限してください。 + 本番環境の中断を避けるには、次の推奨事項を実装します。 + テストと開発アクティビティには、別の専用開発アカウントを使用します。 + 厳格なネットワークアクセス制御を実装し、アカウント間の必要なトラフィックのみに制限します。 + 本番環境とデータソースへのアクセスをモニタリングし、監査します。 + 関連するすべてのリソースとサービスに対して、最小特権のアクセス制御を実装します。 + AWS Secrets Manager シークレットや IAM ロールのアクセスキーなどの認証情報を定期的に確認して更新します。 + この記事で使用されているサービスについては、次のセキュリティドキュメントを参照してください。 + [AWS Lambda セキュリティ](https://docs.aws.amazon.com/lambda/latest/dg/lambda-security.html) + [Amazon Redshift のセキュリティ](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html) + [Amazon S3 セキュリティ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security.html) + [AWS Secrets Manager セキュリティ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security.html) + [IAM セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) セキュリティは、本番データとリソースにアクセスする際の最優先事項です。常にベストプラクティスに従い、最小特権のアクセス制御を実装し、セキュリティ対策を定期的に見直して更新してください。 ## エピック ### Amazon Redshift からデータをクエリする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Amazon Redshift クラスター用のシークレットを作成します。 | Amazon Redshift クラスター用のシークレットを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | Secrets Manager にアクセスするロールを作成します。 | ロールを作成するには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | ### データを Simple Storage Service (Amazon S3) にアップロードする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | S3 バケットにアクセスするためのロールを作成します。 | S3 バケットにアクセスするためのロールを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | Amazon Redshift ロールを作成します。 | Amazon Redshift ロールを作成するには、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | ### Lambda 関数をデプロイします | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数をデプロイします。 | ピア接続された VPC に Lambda 関数をデプロイするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | ### アーキテクチャをテストする | タスク | 説明 | 必要なスキル | | --- | --- | --- | | 必要なリソースをインポートします。 | 必要なリソースをインポートするには、次のコマンドを実行します。
import ast
import boto3
import psycopg2
import base64
from botocore.exceptions import ClientError
| アプリ開発者 | | Lambda ハンドラー関数を実行します。 | Lambda 関数は、クロスアカウントアクセスと一時的な認証情報管理に AWS Security Token Service (AWS STS) を使用します。関数は AssumeRole API オペレーションを使用して、`sm_read_role` IAM ロールのアクセス許可を一時的に引き受けます。Lambda 関数を実行するには、次のコード例を使用します。
def lambda_handler(event, context):
    sts_client = boto3.client('sts')

    # Secrets Manager Configurations
    secret_name = "redshift_creds"
    sm_region = "eu-west-1"
    sm_read_role = "arn:aws:iam::PROD_ACCOUNT_NUMBER:role/SM-Read-Role"

    # S3 Bucket Configurations
    s3_bucket_path = "s3://mybucket/"
    s3_bucket_region = "eu-west-1"
    s3_write_role = "arn:aws:iam::DEV_ACCOUNT_NUMBER:role/S3-Write-Role"

    # Redshift Configurations
    sql_query = "select * from category"
    redshift_db = "dev"
    redshift_s3_write_role = "arn:aws:iam::PROD_ACCOUNT_NUMBER:role/CrossAccount-S3-Write-Role"

    chained_s3_write_role = "%s,%s" % (redshift_s3_write_role, s3_write_role)

    assumed_role_object = sts_client.assume_role(
        RoleArn=sm_read_role,
        RoleSessionName="CrossAccountRoleAssumption",
        ExternalId="YOUR_EXTERNAL_ID",
    )
    credentials = assumed_role_object['Credentials']

    secret_dict = ast.literal_eval(get_secret(credentials, secret_name, sm_region))
    execute_query(secret_dict, sql_query, s3_bucket_path, chained_s3_write_role, s3_bucket_region, redshift_db)

    return {
        'statusCode': 200
    }
| アプリ開発者 | | シークレットを取得します。 | Amazon Redshift シークレットを取得するには、次のコード例を使用します。
def get_secret(credentials, secret_name, sm_region):
    # Create a Secrets Manager client
    session = boto3.session.Session()
    sm_client = session.client(
        service_name='secretsmanager',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken'],
        region_name=sm_region
    )

    try:
        get_secret_value_response = sm_client.get_secret_value(
            SecretId=secret_name
        )
    except ClientError as e:
        print(e)
        raise e
    else:
        if 'SecretString' in get_secret_value_response:
            return get_secret_value_response['SecretString']
        else:
            return base64.b64decode(get_secret_value_response['SecretBinary'])
| アプリ開発者 | | アンロードコマンドを実行します。 | S3 バケットにデータをアンロードするには、次のコード例を使用します。
def execute_query(secret_dict, sql_query, s3_bucket_path, chained_s3_write_role, s3_bucket_region, redshift_db):
    conn_string = "dbname='%s' port='%s' user='%s' password='%s' host='%s'" \
                  % (redshift_db,
                     secret_dict["port"],
                     secret_dict["username"],
                     secret_dict["password"],
                     secret_dict["host"])

    con = psycopg2.connect(conn_string)

    unload_command = "UNLOAD ('{}') TO '{}' IAM_ROLE '{}' DELIMITER '|' REGION '{}';" \
        .format(sql_query,
                s3_bucket_path + str(datetime.datetime.now()) + ".csv",
                chained_s3_write_role,
                s3_bucket_region)

    # Opening a cursor and run query
    cur = con.cursor()
    cur.execute(unload_command)

    print(cur.fetchone())
    cur.close()
    con.close()
| アプリ開発者 | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | Lambda 関数の削除 | 予期しないコストが発生しないようにするには、リソースと、開発用アカウントと本番稼働用アカウント間の接続を削除します。Lambda 関数を削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | IAM ロールとポリシーを削除します。 | 開発用アカウントと本番稼働用アカウントから IAM ロールとポリシーを削除します。開発用アカウントで、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html)本番稼働用アカウントで、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | Secrets Manager でシークレットを削除します。 | シークレットを削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | VPC ピアリングとセキュリティグループに関するルールを削除します。 | VPC ピアリングとセキュリティグループに関するルールを削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | データを S3 バケットから削除します。 | データを Amazon S3 から削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | AWS KMS キーをクリーンアップします。 | 暗号化用のカスタム AWS KMS キーを作成した場合は、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | | Amazon CloudWatch Logs を確認して削除します。 | CloudWatch Logs を削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.html) | DevOps エンジニア | ## 関連リソース + [Amazon CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) + 「[IAM ドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」 + [Lambda ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) + [Amazon Redshift ドキュメント](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html) + 「[Amazon S3 ドキュメント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)」 + [AWS Secrets Manager ドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) + [AWS セキュリティ原則](https://docs.aws.amazon.com/en_us/wellarchitected/2022-03-31/framework/sec-design.html) ## 追加情報 Amazon Redshift から Amazon S3 にデータをアンロードした後、Amazon Athena を使用してデータを分析できます。 [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/getting-started.html) はビッグデータを分析できるクエリサービスであり、大量のデータにアクセスする必要がある場合に便利です。Athena は、サーバーやデータベースをプロビジョニングしなくても使用できます。Athena は複雑なクエリをサポートしており、さまざまなオブジェクトでクエリを実行できます。 ほとんどの と同様に AWS のサービス、Athena を使用する主な利点は、複雑さを増すことなくクエリを実行する方法に大きな柔軟性があることです。Athena を使用すると、データ型を変更することなく、CSV や JSON などのさまざまなデータ型を Amazon S3 でクエリできます。外部を含むさまざまなソースからデータをクエリできます AWS。Athena を使用すると、サーバーを管理する必要がないため、複雑さを軽減できます。Athena は、クエリを実行する前にデータをロードしたり変更したりすることなく、Amazon S3 から直接データを読み取ります。 # ワークロード別のデータベース移行パターン **Topics** + [IBM](databases-database-migration-patterns-by-workload-ibm-pattern-list.md) + [Microsoft](databases-database-migration-patterns-by-workload-microsoft-pattern-list.md) + [該当なし](databases-database-migration-patterns-by-workload-notapplicable-pattern-list.md) + [オープンソース](databases-database-migration-patterns-by-workload-open-source-pattern-list.md) + [Oracle](databases-database-migration-patterns-by-workload-oracle-pattern-list.md) + [SAP](databases-database-migration-patterns-by-workload-sap-pattern-list.md) # IBM **Topics** + [AWS DMS を使用して Db2 データベースを Amazon EC2 から Aurora MySQL 互換のデータベースに移行する](migrate-a-db2-database-from-amazon-ec2-to-aurora-mysql-compatible-by-using-aws-dms.md) + [ログ配信を使用して Db2 for LUW を Amazon EC2 に移行することで、システム停止時間を短縮する](migrate-db2-for-luw-to-amazon-ec2-by-using-log-shipping-to-reduce-outage-time.md) + [高可用性ディザスタリカバリ機能を備えた Db2 for LUW を Amazon EC2 に移行する](migrate-db2-for-luw-to-amazon-ec2-with-high-availability-disaster-recovery.md) + [AWS DMS と AWS SCT を使用して IBM Db2 on Amazon EC2 から Aurora PostgreSQL 互換に移行する](migrate-from-ibm-db2-on-amazon-ec2-to-aurora-postgresql-compatible-using-aws-dms-and-aws-sct.md) + [IBM WebSphere アプリケーションサーバーから Amazon EC2 の Apache Tomcat に移行](migrate-from-ibm-websphere-application-server-to-apache-tomcat-on-amazon-ec2.md) + [IBM Db2、SAP、Sybase、およびその他のデータベースから の MongoDB Atlas にデータをストリーミングする AWS](stream-data-from-ibm-db2-to-mongodb-atlas.md) # Microsoft **Topics** + [Microsoft ワークロードの検出と AWS への移行を加速](accelerate-the-discovery-and-migration-of-microsoft-workloads-to-aws.md) + [リンクサーバーを使用して Amazon EC2 上のMicrosoft SQL サーバーからオンプレミスの Microsoft SQL Server テーブルにアクセスする](access-on-premises-microsoft-sql-server-tables-from-microsoft-sql-server-on-amazon-ec2-using-linked-servers.md) + [SQL Server データベースを AWS 上の MongoDB Atlas に移行する際のクエリパフォーマンスを評価する](assess-query-performance-for-migrating-sql-server-databases-to-mongodb-atlas-on-aws.md) + [AWS Lambda および Task Scheduler を使用して、Amazon EC2 で実行されている SQL Server Express エディションのデータベースタスクを自動化する](automate-database-tasks-in-sql-server-express-edition-running-on-amazon-ec2.md) + [Microsoft SQL Server から Amazon Aurora PostgreSQL 互換エディションへのデータベース移行をサポートするように Python と Perl アプリケーションを変更する](change-python-and-perl-applications-to-support-database-migration-from-microsoft-sql-server-to-amazon-aurora-postgresql-compatible-edition.md) + [AWS 上の SQL Server の Always On アベイラビリティグループで読み取り専用ルーティングを構成する](configure-read-only-routing-in-an-always-on-availability-group-in-sql-server-on-aws.md) + [を使用して Amazon RDS for Microsoft SQL Server の Windows 認証を設定する AWS Managed Microsoft AD](configure-windows-authentication-for-amazon-rds-using-microsoft-ad.md) + [Microsoft Excel と Python を使用して AWS DMS タスク用の AWS CloudFormation テンプレートを作成](create-aws-cloudformation-templates-for-aws-dms-tasks-using-microsoft-excel-and-python.md) + [Terraform を使用して SQL Server フェイルオーバークラスターインスタンスを Amazon EC2 および Amazon FSx にデプロイする](deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.md) + [AWS DMS を使用して Microsoft SQL Server データベースを Amazon S3 にエクスポートする](export-a-microsoft-sql-server-database-to-amazon-s3-by-using-aws-dms.md) + [AWS DMS を使用して Amazon RDS for SQL Server テーブルを S3 バケットにエクスポートする](export-amazon-rds-for-sql-server-tables-to-an-s3-bucket-by-using-aws-dms.md) + [SQL Server から PostgreSQL に移行する際に、PII データに SHA1 ハッシュを実装する](implement-sha1-hashing-for-pii-data-when-migrating-from-sql-server-to-postgresql.md) + [EC2 Windows インスタンスを AWS Managed Services アカウントに取り込み、移行](ingest-and-migrate-ec2-windows-instances-into-an-aws-managed-services-account.md) + [FSx for Windows File Server を使用して Amazon EC2 で Microsoft SQL Server フェイルオーバークラスターをセットアップする](microsoft-sql-failover-cluster-on-amazon-ec2.md) + [メッセージキューを Microsoft Azure Service Bus から Amazon SQS に移行](migrate-a-messaging-queue-from-microsoft-azure-service-bus-to-amazon-sqs.md) + [AWS DMS を使用して Microsoft SQL Server データベースを Amazon EC2 から Amazon DocumentDB に移行します](migrate-a-microsoft-sql-server-database-from-amazon-ec2-to-amazon-documentdb-by-using-aws-dms.md) + [AWS DMS と AWS SCT を使用して Microsoft SQL Server データベースを Aurora MySQL に移行](migrate-a-microsoft-sql-server-database-to-aurora-mysql-by-using-aws-dms-and-aws-sct.md) + [.NET アプリケーションを Microsoft Azure App Serviceから AWS Elastic Beanstalk に移行](migrate-a-net-application-from-microsoft-azure-app-service-to-aws-elastic-beanstalk.md) + [オンプレミスの Microsoft SQL Server データベースを Amazon EC2 に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-ec2.md) + [オンプレミス Microsoft SQL Server データベースを Amazon RDS for SQL Server に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-rds-for-sql-server.md) + [リンクされたサーバーを使用して、オンプレミス Microsoft SQL Server データベースを Amazon RDS for SQL Server に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-rds-for-sql-server-using-linked-servers.md) + [ネイティブバックアップと復元メソッドを使用して、オンプレミスの Microsoft SQL サーバーデータベースを Amazon RDS for SQL Server に移行](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-rds-for-sql-server-using-native-backup-and-restore-methods.md) + [AWS DMS を使用してオンプレミス Microsoft SQL Server データベースを Amazon Redshift に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-redshift-using-aws-dms.md) + [AWS SCT データ抽出エージェントを使用して、オンプレミス Microsoft SQL Server データベースを Amazon Redshift に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-redshift-using-aws-sct-data-extraction-agents.md) + [オンプレミス Microsoft SQL Server データベースを、Linux を実行中の Amazon EC2 上の Microsoft SQL Server に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-microsoft-sql-server-on-amazon-ec2-running-linux.md) + [Rclone を使用して Microsoft Azure Blob から Amazon S3 にデータを移行する](migrate-data-from-microsoft-azure-blob-to-amazon-s3-by-using-rclone.md) + [appcmd.exe を使用して IIS がホストするアプリケーションを Amazon EC2 に移行する](migrate-iis-hosted-applications-to-amazon-ec2-by-using-appcmd.md) + [を使用して Microsoft SQL Server Always On 可用性グループを移行する AWS Application Migration Service](migrate-microsoft-sql-server-always-on-group-using-mgn.md) + [オンプレミスの Microsoft SQL Server データベースを Amazon EC2 に移行する](migrate-microsoft-sql-server-to-amazon-ec2-using-aws-mgn.md) + [でリレーショナルデータベースを MongoDB Atlas に移行する AWS](migrate-relational-database-to-mongodb-atlas.md) + [分散可用性グループを使用して SQL Server を AWS に移行する](migrate-sql-server-to-aws-using-distributed-availability-groups.md) + [ACM を使用して Windows SSL 証明書をApplication Load Balancer に移行](migrate-windows-ssl-certificates-to-an-application-load-balancer-using-acm.md) + [AWS Cloud でオンプレミスワークロードをリホストする: 移行チェックリスト](rehost-on-premises-workloads-in-the-aws-cloud-migration-checklist.md) + [Microsoft SQL サーバーを AWS クラウドに移行した後に接続エラーを解決する](resolve-connection-errors-after-migrating-microsoft-sql-server-to-the-aws-cloud.md) + [オンプレミスの SMTP サーバーとデータベースメールを使用して、Amazon RDS for SQL Server データベースインスタンスに通知を送信します。](send-notifications-for-an-amazon-rds-for-sql-server-database-instance-by-using-an-on-premises-smtp-server-and-database-mail.md) + [Terraform を使用してデータベース移行用の CI/CD パイプラインを設定する](set-up-ci-cd-pipeline-for-db-migration-with-terraform.md) + [Amazon FSx を使用して SQL Server Always On FCI 向けのマルチ AZ インフラストラクチャをセットアップする](set-up-multi-az-infrastructure-for-a-sql-server-always-on-fci-by-using-amazon-fsx.md) # 該当なし **Topics** + [へのリホスト移行中にファイアウォールリクエストの承認プロセスを作成する AWS](create-an-approval-process-for-firewall-requests-during-a-rehost-migration-to-aws.md) + [既存の Amazon RDS for PostgreSQL DB インスタンスを暗号化する](encrypt-an-existing-amazon-rds-for-postgresql-db-instance.md) + [Amazon DynamoDB テーブルのストレージコストを推定](estimate-storage-costs-for-an-amazon-dynamodb-table.md) + [AWS DMS と Amazon Aurora によるクロスリージョンディザスタリカバリの実装](implement-cross-region-disaster-recovery-with-aws-dms-and-amazon-aurora.md) # オープンソース **Topics** + [Python アプリケーションを使用して Amazon DynamoDB の PynamoDB モデルと CRUD 関数を自動的に生成する](automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.md) + [pgAdmin の SSH トンネルを使用して接続](connect-by-using-an-ssh-tunnel-in-pgadmin.md) + [Aurora PostgreSQL-Compatible でのアプリケーションユーザーとロールの作成](create-application-users-and-roles-in-aurora-postgresql-compatible.md) + [Amazon RDS の PostgreSQL DB インスタンスに対して暗号化された接続を有効にする](enable-encrypted-connections-for-postgresql-db-instances-in-amazon-rds.md) + [AWS SCT と AWS DMS を使用して Amazon RDS for Oracle を Amazon RDS for PostgreSQL に移行する AWS CLI CloudFormation](migrate-amazon-rds-for-oracle-to-amazon-rds-for-postgresql-with-aws-sct-and-aws-dms-using-aws-cli-and-aws-cloudformation.md) + [ネイティブツールを使用して オンプレミスの MariaDB Amazon RDS for MariaDB に移行する](migrate-an-on-premises-mariadb-database-to-amazon-rds-for-mariadb-using-native-tools.md) + [オンプレミス MySQL データベースを Amazon EC2 に移行する](migrate-an-on-premises-mysql-database-to-amazon-ec2.md) + [オンプレミス MySQL データベースを Amazon RDS for MySQL に移行する](migrate-an-on-premises-mysql-database-to-amazon-rds-for-mysql.md) + [オンプレミス MySQL データベースを Aurora MySQL に移行する](migrate-an-on-premises-mysql-database-to-aurora-mysql.md) + [オンプレミス PostgreSQL データベースを Aurora PostgreSQL に移行する](migrate-an-on-premises-postgresql-database-to-aurora-postgresql.md) + [Couchbase Server データベースを Amazon EC2 に移行する](migrate-couchbase-server-ec2.md) + [IBM WebSphere アプリケーションサーバーから Amazon EC2 上の Apache Tomcat への自動スケーリングによる移行](migrate-from-ibm-websphere-application-server-to-apache-tomcat-on-amazon-ec2-with-auto-scaling.md) + [SharePlex と AWS DMS を使用して、Oracle 8i または 9i から Amazon RDS for Oracle に移行](migrate-from-oracle-8i-or-9i-to-amazon-rds-for-oracle-using-shareplex-and-aws-dms.md) + [pglogic を使用して Amazon EC2 上の PostgreSQL から Amazon RDS for PostgreSQL に移行する](migrate-from-postgresql-on-amazon-ec2-to-amazon-rds-for-postgresql-using-pglogical.md) + [AWS App2Container を使用したオンプレミスの Java プリケーションの AWS への移行](migrate-on-premises-java-applications-to-aws-using-aws-app2container.md) + [Percona XtraBackup、Amazon EFS、Amazon S3 を使用してオンプレミスの MySQL データベースを Aurora MySQL に移行する](migrate-on-premises-mysql-databases-to-aurora-mysql-using-percona-xtrabackup-amazon-efs-and-amazon-s3.md) + [Oracle 外部テーブルを Amazon Aurora PostgreSQL 互換に移行](migrate-oracle-external-tables-to-amazon-aurora-postgresql-compatible.md) + [100 個以上の引数を持つ Oracle 関数とプロシージャを PostgreSQL に移行](migrate-oracle-functions-and-procedures-that-have-more-than-100-arguments-to-postgresql.md) + [Redis ワークロードを AWS 上の Redis Enterprise Cloud に移行](migrate-redis-workloads-to-redis-enterprise-cloud-on-aws.md) + [暗号化されていない Amazon Aurora インスタンスをモニタリングする](monitor-amazon-aurora-for-instances-without-encryption.md) + [RHEL ソースサーバーを再起動した後、SELinux を無効にせずに AWS レプリケーションエージェントを自動的に再起動する](restart-the-aws-replication-agent-automatically-without-disabling-selinux-after-rebooting-a-rhel-source-server.md) + [Lambda と Secrets Manager を使用して Amazon RDS for PostgreSQL と Aurora PostgreSQL のジョブをスケジュールする](schedule-jobs-for-amazon-rds-for-postgresql-and-aurora-postgresql-by-using-lambda-and-secrets-manager.md) + [pg\$1transport を使用して 2 つの Amazon RDS DB インスタンス間でPostgreSQL データベースを転送する](transport-postgresql-databases-between-two-amazon-rds-db-instances-using-pg-transport.md) + [アカウント間で Amazon Redshift クラスターから Amazon S3 にデータをアンロードする](unload-data-from-amazon-redshift-cross-accounts-to-amazon-s3.md) # Oracle **Topics** + [リードレプリカを使用して Amazon RDS Customの Oracle PeopleSoft に HA を追加](add-ha-to-oracle-peoplesoft-on-amazon-rds-custom-by-using-a-read-replica.md) + [JSON Oracleクエリを PostgreSQL データベース SQL に変換](convert-json-oracle-queries-into-postgresql-database-sql.md) + [Oracle の VARCHAR2 (1) データ型を Amazon Aurora PostgreSQL のブールデータ型に変換](convert-varchar2-1-data-type-for-oracle-to-boolean-data-type-for-amazon-aurora-postgresql.md) + [PostgreSQL 互換の Aurora グローバルデータベースを使用して Oracle DR をエミュレート](emulate-oracle-dr-by-using-a-postgresql-compatible-aurora-global-database.md) + [Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL で Oracle PL/SQL 連想配列をエミュレートする](emulate-oracle-plsql-associative-arrays-in-aurora-and-rds-postgresql.md) + [AWR レポートを使用して Oracle データベースの Amazon RDS エンジンサイズを推定](estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.md) + [Aurora PostgreSQL の動的 SQL ステートメントの匿名ブロックを処理](handle-anonymous-blocks-in-dynamic-sql-statements-in-aurora-postgresql.md) + [Oracle SQL Developer と AWS SCT を使用して Amazon RDS for Oracle から Amazon RDS for PostgreSQL に段階的に移行](incrementally-migrate-from-amazon-rds-for-oracle-to-amazon-rds-for-postgresql-using-oracle-sql-developer-and-aws-sct.md) + [Aurora PostgreSQL 互換のファイルエンコーディングを使用して BLOB ファイルを TEXT にロード](load-blob-files-into-text-by-using-file-encoding-in-aurora-postgresql-compatible.md) + [AWS DMS を使用して Amazon RDS for Oracle を Amazon RDS for PostgreSQL に移行します](migrate-amazon-rds-for-oracle-to-amazon-rds-for-postgresql-in-ssl-mode-by-using-aws-dms.md) + [Amazon RDS for Oracle データベースを別の に移行 AWS アカウント し、 AWS リージョン を使用して継続的なレプリケーション AWS DMS を行う](migrate-an-amazon-rds-for-oracle-database-to-another-aws-account-and-aws-region-using-aws-dms-for-ongoing-replication.md) + [Oracle Data Pump を使用してオンプレミスの Oracle データベースを Amazon EC2 に移行する](migrate-an-on-premises-oracle-database-to-amazon-ec2-by-using-oracle-data-pump.md) + [Logstash を使用して、オンプレミス Oracle データベースを Amazon OpenSearch Service へ移行する](migrate-an-on-premises-oracle-database-to-amazon-opensearch-service-using-logstash.md) + [AWS DMS と AWS SCT を使用してオンプレミスの Oracle データベースを Amazon RDS for MySQL に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-mysql-using-aws-dms-and-aws-sct.md) + [オンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle.md) + [データベースリンクを経由した直接 Oracle Data Pump Import を使用して、オンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle-by-using-direct-oracle-data-pump-import-over-a-database-link.md) + [Oracle Data Pump を使用してオンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle-using-oracle-data-pump.md) + [Oracle バイスタンダーと AWS DMS を使用して、オンプレミスの Oracle データベースを Amazon RDS for PostgreSQL に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-postgresql-by-using-an-oracle-bystander-and-aws-dms.md) + [オンプレミスの Oracle データベースを Oracle Amazon EC2 に移行する](migrate-an-on-premises-oracle-database-to-oracle-on-amazon-ec2.md) + [AWS DMS と AWS SCT を使用して、Oracle データベースを Amazon EC2 から Amazon RDS for MariaDB に移行する](migrate-an-oracle-database-from-amazon-ec2-to-amazon-rds-for-mariadb-using-aws-dms-and-aws-sct.md) + [AWS DMS を使用して Oracle データベースを Amazon EC2 から Amazon RDS for Oracle に移行する](migrate-an-oracle-database-from-amazon-ec2-to-amazon-rds-for-oracle-using-aws-dms.md) + [AWS DMS を使用して Oracle データベースを Amazon DynamoDB に移行する](migrate-an-oracle-database-to-amazon-dynamodb-using-aws-dms.md) + [Oracle GoldenGate フラットファイルアダプタを使用して Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-oracle-database-to-amazon-rds-for-oracle-by-using-oracle-goldengate-flat-file-adapters.md) + [AWS DMS と AWS SCT を使用して Oracle データベースを Amazon Redshift に移行する](migrate-an-oracle-database-to-amazon-redshift-using-aws-dms-and-aws-sct.md) + [AWS DMS と AWS SCT を使用して Oracle データベースを Aurora PostgreSQL に移行](migrate-an-oracle-database-to-aurora-postgresql-using-aws-dms-and-aws-sct.md) + [Oracle Data Pump と AWS DMS を使用して Oracle JD Edwards EnterpriseOne データベースを AWS に移行します](migrate-an-oracle-jd-edwards-enterpriseone-database-to-aws-by-using-oracle-data-pump-and-aws-dms.md) + [AWS DMS を使用して Oracle パーティションテーブルを PostgreSQL に移行](migrate-an-oracle-partitioned-table-to-postgresql-by-using-aws-dms.md) + [AWS DMS を使用して Oracle PeopleSoft データベースを AWS に移行する](migrate-an-oracle-peoplesoft-database-to-aws-by-using-aws-dms.md) + [オンプレミスの Oracle データベースから Aurora PostgreSQL にデータを移行する](migrate-data-from-an-on-premises-oracle-database-to-aurora-postgresql.md) + [Amazon RDS for Oracle から Amazon RDS for MySQL に移行する](migrate-from-amazon-rds-for-oracle-to-amazon-rds-for-mysql.md) + [マテリアライズドビューと AWS DMS を使用して Oracle 8i または 9i から Amazon RDS for PostgreSQL に移行](migrate-from-oracle-8i-or-9i-to-amazon-rds-for-postgresql-using-materialized-views-and-aws-dms.md) + [SharePlex と AWS DMS を使用して、Oracle 8i または 9i から Amazon RDS for PostgreSQL に移行](migrate-from-oracle-8i-or-9i-to-amazon-rds-for-postgresql-using-shareplex-and-aws-dms.md) + [Oracle GoldenGate を使用して Oracle Database から Amazon RDS for PostgreSQL に移行](migrate-from-oracle-database-to-amazon-rds-for-postgresql-by-using-oracle-goldengate.md) + [AWS DMS と AWS SCT を使用して Oracle on Amazon EC2 から Amazon RDS for MySQL に移行する](migrate-from-oracle-on-amazon-ec2-to-amazon-rds-for-mysql-using-aws-dms-and-aws-sct.md) + [Amazon ECS で Oracle WebLogic から Apache Tomcat (ToMee) に移行する](migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs.md) + [関数ベースのインデックスを Oracle から PostgreSQL に移行する](migrate-function-based-indexes-from-oracle-to-postgresql.md) + [レガシーアプリケーションを Oracle Pro\$1C から ECPG に移行する](migrate-legacy-applications-from-oracle-pro-c-to-ecpg.md) + [Oracle CLOB 値を AWS 上の PostgreSQL の個々の行に移行](migrate-oracle-clob-values-to-individual-rows-in-postgresql-on-aws.md) + [Oracle Database のエラーコードを Amazon Aurora PostgreSQL-Compatible データベースに移行する](migrate-oracle-database-error-codes-to-an-amazon-aurora-postgresql-compatible-database.md) + [エクステンションを使用して Oracle のネイティブ関数を PostgreSQL に移行](migrate-oracle-native-functions-to-postgresql-using-extensions.md) + [Oracle PeopleSoft を Amazon RDS Custom に移行](migrate-oracle-peoplesoft-to-amazon-rds-custom.md) + [Oracle ROWID 機能を AWS の PostgreSQL に移行](migrate-oracle-rowid-functionality-to-postgresql-on-aws.md) + [Oracle SERIALLY\$1REUSABLE プラグマパッケージを PostgreSQL に移行](migrate-oracle-serially-reusable-pragma-packages-into-postgresql.md) + [仮想生成列をOracleから PostgreSQL に移行](migrate-virtual-generated-columns-from-oracle-to-postgresql.md) + [Amazon CloudWatch を使用して Oracle GoldenGate ログを監視する](monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.md) + [Oracle から PostgreSQL への部分的なデータベース移行に関するオブジェクトの依存関係を分析する](multilevel-object-analysis-for-database-migration-from-oracle-to-postgresql.md) + [Amazon RDS for Oracle で Oracle Database エンタープライズエディションから標準エディション 2 へリプラットフォームする](replatform-oracle-database-enterprise-edition-to-standard-edition-2-on-amazon-rds-for-oracle.md) + [Amazon RDS Custom でアクティブスタンバイデータベースを使用して Oracle E-Business Suite の HA/DR アーキテクチャを設定する](set-up-an-ha-dr-architecture-for-oracle-e-business-suite-on-amazon-rds-custom-with-an-active-standby-database.md) + [Aurora PostgreSQL-Compatible で Oracle UTL\$1FILE 機能をセットアップする](set-up-oracle-utl_file-functionality-on-aurora-postgresql-compatible.md) + [Amazon RDS Custom for Oracle 上の Oracle PeopleSoft アプリケーションの移行ロール](transition-roles-for-an-oracle-peoplesoft-application-on-amazon-rds-custom-for-oracle.md) + [Oracle から Amazon Aurora PostgreSQL への移行後にデータベースオブジェクトを検証する](validate-database-objects-after-migrating-from-oracle-to-amazon-aurora-postgresql.md) # SAP **Topics** + [Systems Manager と EventBridge を使用した SAP HANA データベースの自動バックアップ](automatically-back-up-sap-hana-databases-using-systems-manager-and-eventbridge.md) + [AWS DMS を使用して SAP ASE から Amazon RDS for SQL Server）に移行する](migrate-from-sap-ase-to-amazon-rds-for-sql-server-using-aws-dms.md) + [AWS SCT と AWS DMS を使用して Amazon EC2 上の SAP ASE を Amazon Aurora PostgreSQL 互換の Amazon Aurora PostgreSQL 互換に移行します](migrate-sap-ase-on-amazon-ec2-to-amazon-aurora-postgresql-compatible-using-aws-sct-and-aws-dms.md) + [同じホスト名の SAP HSR を使用して SAP HANA を AWS に移行します](migrate-sap-hana-to-aws-using-sap-hsr-with-the-same-hostname.md) + [AWS の IBM Db2 に SAP のディザスタリカバリをセットアップ](set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.md) # その他のパターン **Topics** + [Amazon EKS コンテナから Amazon Neptune データベースにアクセスする](access-amazon-neptune-database-from-amazon-eks-container.md) + [Athena による Amazon DynamoDB テーブルへのアクセス、クエリ、結合](access-query-and-join-amazon-dynamodb-tables-using-athena.md) + [EC2 インスタンスを AMS アカウントの S3 バケットへの書き込みアクセスを許可](allow-ec2-instances-write-access-to-s3-buckets-in-ams-accounts.md) + [Amazon Athena と Amazon Quick Sight を使用してネストされた JSON データを分析および視覚化する](analyze-and-visualize-nested-json-data-with-amazon-athena-and-amazon-quicksight.md) + [AWS Batch を使用して Amazon RDS for PostgreSQL DBインスタンスのバックアップを自動化します](automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch.md) + [DynamoDB TTL を使用して項目を Amazon S3 に自動的にアーカイブする](automatically-archive-items-to-amazon-s3-using-dynamodb-ttl.md) + [暗号化されていない Amazon RDS DB インスタンスとクラスターを自動的に修正する](automatically-remediate-unencrypted-amazon-rds-db-instances-and-clusters.md) + [AWS Systems Manager メンテナンスウィンドウを使用して Amazon RDS DB インスタンスを自動的に停止および起動する](automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.md) + [MongoDB Atlas を含む AWS ランディングゾーンを構築する](build-aws-landing-zone-that-includes-mongodb-atlas.md) + [AWS Mainframe Modernization と を使用して COBOL Db2 プログラムを構築する AWS CodeBuild](build-cobol-db2-programs-mainframe-modernization-codebuild.md) + [Amazon DataZone を使用してエンタープライズデータメッシュを構築する AWS CDK AWS CloudFormation](build-enterprise-data-mesh-amazon-data-zone.md) + [Microsoft SQL Server から Amazon Aurora PostgreSQL 互換エディションへのデータベース移行をサポートするように Python と Perl アプリケーションを変更する](change-python-and-perl-applications-to-support-database-migration-from-microsoft-sql-server-to-amazon-aurora-postgresql-compatible-edition.md) + [Python を使用して AWS 上で EBCDIC データを ASCII に変換および解凍する](convert-and-unpack-ebcdic-data-to-ascii-on-aws-by-using-python.md) + [Teradata NORMALIZE 時間的特徴量を Amazon Redshift SQL に変換](convert-the-teradata-normalize-temporal-feature-to-amazon-redshift-sql.md) + [Teradata RESET WHEN 特徴量を Amazon Redshift SQL に変換](convert-the-teradata-reset-when-feature-to-amazon-redshift-sql.md) + [Oracle の VARCHAR2 (1) データ型を Amazon Aurora PostgreSQL のブールデータ型に変換](convert-varchar2-1-data-type-for-oracle-to-boolean-data-type-for-amazon-aurora-postgresql.md) + [Aurora PostgreSQL-Compatible でのアプリケーションユーザーとロールの作成](create-application-users-and-roles-in-aurora-postgresql-compatible.md) + [Microsoft Excel と Python を使用して AWS DMS タスク用の AWS CloudFormation テンプレートを作成](create-aws-cloudformation-templates-for-aws-dms-tasks-using-microsoft-excel-and-python.md) + [で Kinesis Data Streams と Firehose を使用して Amazon S3 に DynamoDB レコードを配信する AWS CDK](deliver-dynamodb-records-to-amazon-s3-using-kinesis-data-streams-and-amazon-data-firehose-with-aws-cdk.md) + [Amazon EC2 にプライベート静的 IP を使用して Cassandra クラスターをデプロイしてリバランスを回避する](deploy-a-cassandra-cluster-on-amazon-ec2-with-private-static-ips-to-avoid-rebalancing.md) + [Terraform を使用して Amazon EKS に CockroachDB クラスターをデプロイする](deploy-cockroachdb-on-eks-using-terraform.md) + [RAG と ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する](develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.md) + [PostgreSQL 互換の Aurora グローバルデータベースを使用して Oracle DR をエミュレート](emulate-oracle-dr-by-using-a-postgresql-compatible-aurora-global-database.md) + [IBM Db2 データベースで Amazon S3 への DB2 ログアーカイブを直接有効にする](enable-db2-logarchive-directly-to-amazon-s3-in-ibm-db2-database.md) + [Amazon RDS for SQL Server で透過的なデータ暗号化を有効にする](enable-transparent-data-encryption-in-amazon-rds-for-sql-server.md) + [AWS DMS を使用して Microsoft SQL Server データベースを Amazon S3 にエクスポートする](export-a-microsoft-sql-server-database-to-amazon-s3-by-using-aws-dms.md) + [SQL Server から PostgreSQL に移行する際に、PII データに SHA1 ハッシュを実装する](implement-sha1-hashing-for-pii-data-when-migrating-from-sql-server-to-postgresql.md) + [Oracle SQL Developer と AWS SCT を使用して Amazon RDS for Oracle から Amazon RDS for PostgreSQL に段階的に移行](incrementally-migrate-from-amazon-rds-for-oracle-to-amazon-rds-for-postgresql-using-oracle-sql-developer-and-aws-sct.md) + [Aurora PostgreSQL 互換のファイルエンコーディングを使用して BLOB ファイルを TEXT にロード](load-blob-files-into-text-by-using-file-encoding-in-aurora-postgresql-compatible.md) + [AWS Secrets Manager を使用して認証情報を管理](manage-credentials-using-aws-secrets-manager.md) + [AWS DMS を使用して Db2 データベースを Amazon EC2 から Aurora MySQL 互換のデータベースに移行する](migrate-a-db2-database-from-amazon-ec2-to-aurora-mysql-compatible-by-using-aws-dms.md) + [AWS DMS を使用して Microsoft SQL Server データベースを Amazon EC2 から Amazon DocumentDB に移行します](migrate-a-microsoft-sql-server-database-from-amazon-ec2-to-amazon-documentdb-by-using-aws-dms.md) + [AWS DMS と AWS SCT を使用して Microsoft SQL Server データベースを Aurora MySQL に移行](migrate-a-microsoft-sql-server-database-to-aurora-mysql-by-using-aws-dms-and-aws-sct.md) + [AWS DMS を使用して Amazon RDS for Oracle を Amazon RDS for PostgreSQL に移行します](migrate-amazon-rds-for-oracle-to-amazon-rds-for-postgresql-in-ssl-mode-by-using-aws-dms.md) + [AWS SCT と AWS DMS を使用して Amazon RDS for Oracle を Amazon RDS for PostgreSQL に移行する AWS CLI CloudFormation](migrate-amazon-rds-for-oracle-to-amazon-rds-for-postgresql-with-aws-sct-and-aws-dms-using-aws-cli-and-aws-cloudformation.md) + [Amazon RDS DB インスタンスを別の VPC またはアカウントに移行する](migrate-an-amazon-rds-db-instance-to-another-vpc-or-account.md) + [Amazon RDS for Oracle データベースを別の に移行 AWS アカウント し、 AWS リージョン を使用して継続的なレプリケーション AWS DMS を行う](migrate-an-amazon-rds-for-oracle-database-to-another-aws-account-and-aws-region-using-aws-dms-for-ongoing-replication.md) + [Amazon Redshift クラスターを中国の AWS リージョンに移行する](migrate-an-amazon-redshift-cluster-to-an-aws-region-in-china.md) + [ネイティブツールを使用して オンプレミスの MariaDB Amazon RDS for MariaDB に移行する](migrate-an-on-premises-mariadb-database-to-amazon-rds-for-mariadb-using-native-tools.md) + [オンプレミスの Microsoft SQL Server データベースを Amazon EC2 に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-ec2.md) + [オンプレミス Microsoft SQL Server データベースを Amazon RDS for SQL Server に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-rds-for-sql-server.md) + [リンクされたサーバーを使用して、オンプレミス Microsoft SQL Server データベースを Amazon RDS for SQL Server に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-rds-for-sql-server-using-linked-servers.md) + [ネイティブバックアップと復元メソッドを使用して、オンプレミスの Microsoft SQL サーバーデータベースを Amazon RDS for SQL Server に移行](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-rds-for-sql-server-using-native-backup-and-restore-methods.md) + [AWS DMS を使用してオンプレミス Microsoft SQL Server データベースを Amazon Redshift に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-redshift-using-aws-dms.md) + [AWS SCT データ抽出エージェントを使用して、オンプレミス Microsoft SQL Server データベースを Amazon Redshift に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-amazon-redshift-using-aws-sct-data-extraction-agents.md) + [オンプレミス Microsoft SQL Server データベースを、Linux を実行中の Amazon EC2 上の Microsoft SQL Server に移行する](migrate-an-on-premises-microsoft-sql-server-database-to-microsoft-sql-server-on-amazon-ec2-running-linux.md) + [オンプレミス MySQL データベースを Amazon RDS for MySQL に移行する](migrate-an-on-premises-mysql-database-to-amazon-rds-for-mysql.md) + [オンプレミス MySQL データベースを Aurora MySQL に移行する](migrate-an-on-premises-mysql-database-to-aurora-mysql.md) + [Oracle Data Pump を使用してオンプレミスの Oracle データベースを Amazon EC2 に移行する](migrate-an-on-premises-oracle-database-to-amazon-ec2-by-using-oracle-data-pump.md) + [Logstash を使用して、オンプレミス Oracle データベースを Amazon OpenSearch Service へ移行する](migrate-an-on-premises-oracle-database-to-amazon-opensearch-service-using-logstash.md) + [AWS DMS と AWS SCT を使用してオンプレミスの Oracle データベースを Amazon RDS for MySQL に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-mysql-using-aws-dms-and-aws-sct.md) + [オンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle.md) + [データベースリンクを経由した直接 Oracle Data Pump Import を使用して、オンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle-by-using-direct-oracle-data-pump-import-over-a-database-link.md) + [Oracle Data Pump を使用してオンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-oracle-using-oracle-data-pump.md) + [Oracle バイスタンダーと AWS DMS を使用して、オンプレミスの Oracle データベースを Amazon RDS for PostgreSQL に移行する](migrate-an-on-premises-oracle-database-to-amazon-rds-for-postgresql-by-using-an-oracle-bystander-and-aws-dms.md) + [オンプレミスの Oracle データベースを Oracle Amazon EC2 に移行する](migrate-an-on-premises-oracle-database-to-oracle-on-amazon-ec2.md) + [オンプレミス PostgreSQL データベースを Aurora PostgreSQL に移行する](migrate-an-on-premises-postgresql-database-to-aurora-postgresql.md) + [オンプレミスの ThoughtSpot Falcon データベースを Amazon Redshift に移行する](migrate-an-on-premises-thoughtspot-falcon-database-to-amazon-redshift.md) + [AWS DMS と AWS SCT を使用して、Oracle データベースを Amazon EC2 から Amazon RDS for MariaDB に移行する](migrate-an-oracle-database-from-amazon-ec2-to-amazon-rds-for-mariadb-using-aws-dms-and-aws-sct.md) + [AWS DMS を使用して Oracle データベースを Amazon EC2 から Amazon RDS for Oracle に移行する](migrate-an-oracle-database-from-amazon-ec2-to-amazon-rds-for-oracle-using-aws-dms.md) + [Oracle GoldenGate フラットファイルアダプタを使用して Oracle データベースを Amazon RDS for Oracle に移行する](migrate-an-oracle-database-to-amazon-rds-for-oracle-by-using-oracle-goldengate-flat-file-adapters.md) + [AWS DMS と AWS SCT を使用して Oracle データベースを Amazon Redshift に移行する](migrate-an-oracle-database-to-amazon-redshift-using-aws-dms-and-aws-sct.md) + [AWS DMS と AWS SCT を使用して Oracle データベースを Aurora PostgreSQL に移行](migrate-an-oracle-database-to-aurora-postgresql-using-aws-dms-and-aws-sct.md) + [Oracle Data Pump と AWS DMS を使用して Oracle JD Edwards EnterpriseOne データベースを AWS に移行します](migrate-an-oracle-jd-edwards-enterpriseone-database-to-aws-by-using-oracle-data-pump-and-aws-dms.md) + [AWS DMS を使用して Oracle パーティションテーブルを PostgreSQL に移行](migrate-an-oracle-partitioned-table-to-postgresql-by-using-aws-dms.md) + [AWS DMS を使用して Oracle PeopleSoft データベースを AWS に移行する](migrate-an-oracle-peoplesoft-database-to-aws-by-using-aws-dms.md) + [Couchbase Server データベースを Amazon EC2 に移行する](migrate-couchbase-server-ec2.md) + [オンプレミスの Oracle データベースから Aurora PostgreSQL にデータを移行する](migrate-data-from-an-on-premises-oracle-database-to-aurora-postgresql.md) + [Starburst AWS クラウド を使用してデータを に移行する](migrate-data-to-the-aws-cloud-by-using-starburst.md) + [ログ配信を使用して Db2 for LUW を Amazon EC2 に移行することで、システム停止時間を短縮する](migrate-db2-for-luw-to-amazon-ec2-by-using-log-shipping-to-reduce-outage-time.md) + [高可用性ディザスタリカバリ機能を備えた Db2 for LUW を Amazon EC2 に移行する](migrate-db2-for-luw-to-amazon-ec2-with-high-availability-disaster-recovery.md) + [Amazon RDS for Oracle から Amazon RDS for MySQL に移行する](migrate-from-amazon-rds-for-oracle-to-amazon-rds-for-mysql.md) + [カウチベースサーバーから AWS 上のカウチベースカペラへの移行](migrate-from-couchbase-server-to-couchbase-capella-on-aws.md) + [AWS DMS と AWS SCT を使用して IBM Db2 on Amazon EC2 から Aurora PostgreSQL 互換に移行する](migrate-from-ibm-db2-on-amazon-ec2-to-aurora-postgresql-compatible-using-aws-dms-and-aws-sct.md) + [マテリアライズドビューと AWS DMS を使用して Oracle 8i または 9i から Amazon RDS for PostgreSQL に移行](migrate-from-oracle-8i-or-9i-to-amazon-rds-for-postgresql-using-materialized-views-and-aws-dms.md) + [SharePlex と AWS DMS を使用して、Oracle 8i または 9i から Amazon RDS for PostgreSQL に移行](migrate-from-oracle-8i-or-9i-to-amazon-rds-for-postgresql-using-shareplex-and-aws-dms.md) + [Oracle GoldenGate を使用して Oracle Database から Amazon RDS for PostgreSQL に移行](migrate-from-oracle-database-to-amazon-rds-for-postgresql-by-using-oracle-goldengate.md) + [AWS DMS と AWS SCT を使用して Oracle on Amazon EC2 から Amazon RDS for MySQL に移行する](migrate-from-oracle-on-amazon-ec2-to-amazon-rds-for-mysql-using-aws-dms-and-aws-sct.md) + [pglogic を使用して Amazon EC2 上の PostgreSQL から Amazon RDS for PostgreSQL に移行する](migrate-from-postgresql-on-amazon-ec2-to-amazon-rds-for-postgresql-using-pglogical.md) + [AWS DMS を使用して SAP ASE から Amazon RDS for SQL Server）に移行する](migrate-from-sap-ase-to-amazon-rds-for-sql-server-using-aws-dms.md) + [関数ベースのインデックスを Oracle から PostgreSQL に移行する](migrate-function-based-indexes-from-oracle-to-postgresql.md) + [レガシーアプリケーションを Oracle Pro\$1C から ECPG に移行する](migrate-legacy-applications-from-oracle-pro-c-to-ecpg.md) + [オンプレミスの Microsoft SQL Server データベースを Amazon EC2 に移行する](migrate-microsoft-sql-server-to-amazon-ec2-using-aws-mgn.md) + [オンプレミスの Cloudera ワークロードを AWS 上の Cloudera データプラットフォームに移行する](migrate-on-premises-cloudera-workloads-to-cloudera-data-platform-on-aws.md) + [Percona XtraBackup、Amazon EFS、Amazon S3 を使用してオンプレミスの MySQL データベースを Aurora MySQL に移行する](migrate-on-premises-mysql-databases-to-aurora-mysql-using-percona-xtrabackup-amazon-efs-and-amazon-s3.md) + [Oracle ビジネスインテリジェンス 12c をオンプレミスサーバーから AWS クラウドに移行](migrate-oracle-business-intelligence-12c-to-the-aws-cloud-from-on-premises-servers.md) + [Oracle CLOB 値を AWS 上の PostgreSQL の個々の行に移行](migrate-oracle-clob-values-to-individual-rows-in-postgresql-on-aws.md) + [Oracle Database のエラーコードを Amazon Aurora PostgreSQL-Compatible データベースに移行する](migrate-oracle-database-error-codes-to-an-amazon-aurora-postgresql-compatible-database.md) + [Oracle 外部テーブルを Amazon Aurora PostgreSQL 互換に移行](migrate-oracle-external-tables-to-amazon-aurora-postgresql-compatible.md) + [エクステンションを使用して Oracle のネイティブ関数を PostgreSQL に移行](migrate-oracle-native-functions-to-postgresql-using-extensions.md) + [Oracle PeopleSoft を Amazon RDS Custom に移行](migrate-oracle-peoplesoft-to-amazon-rds-custom.md) + [Oracle ROWID 機能を AWS の PostgreSQL に移行](migrate-oracle-rowid-functionality-to-postgresql-on-aws.md) + [Oracle SERIALLY\$1REUSABLE プラグマパッケージを PostgreSQL に移行](migrate-oracle-serially-reusable-pragma-packages-into-postgresql.md) + [AWS SCT と AWS DMS を使用して Amazon EC2 上の SAP ASE を Amazon Aurora PostgreSQL 互換の Amazon Aurora PostgreSQL 互換に移行します](migrate-sap-ase-on-amazon-ec2-to-amazon-aurora-postgresql-compatible-using-aws-sct-and-aws-dms.md) + [仮想生成列をOracleから PostgreSQL に移行](migrate-virtual-generated-columns-from-oracle-to-postgresql.md) + [組織間でのデータ共有を目的として、最小実行可能データスペースを設定する](minimum-viable-data-space-share-data-organizations.md) + [Amazon ElastiCache クラスターの保存時の暗号化をモニタリングする](monitor-amazon-elasticache-clusters-for-at-rest-encryption.md) + [Amazon Athena を使用して SQL で Amazon DynamoDB テーブルをクエリする](query-amazon-dynamodb-tables-sql-amazon-athena.md) + [トラステッドコンテキストを使用して、AWS の Db2 フェデレーションデータベースのユーザーアクセスを保護し、合理化する](secure-and-streamline-user-access-in-a-db2-federation-database-on-aws-by-using-trusted-contexts.md) + [AWS で可用性の高い PeopleSoft アーキテクチャを設定する](set-up-a-highly-available-peoplesoft-architecture-on-aws.md) + [Aurora PostgreSQL-Compatible で Oracle UTL\$1FILE 機能をセットアップする](set-up-oracle-utl_file-functionality-on-aurora-postgresql-compatible.md) + [PGO を使用して Amazon EKS での PostgreSQL デプロイを合理化する](streamline-postgresql-deployments-amazon-eks-pgo.md) + [大規模な Db2 z/OS データを CSV ファイルで Amazon S3 に転送する](transfer-large-scale-db2-z-os-data-to-amazon-s3-in-csv-files.md) + [pg\$1transport を使用して 2 つの Amazon RDS DB インスタンス間でPostgreSQL データベースを転送する](transport-postgresql-databases-between-two-amazon-rds-db-instances-using-pg-transport.md) + [Oracle から Amazon Aurora PostgreSQL への移行後にデータベースオブジェクトを検証する](validate-database-objects-after-migrating-from-oracle-to-amazon-aurora-postgresql.md)