Amazon Aurora の PoC (概念実証) の実行

Aurora の PoC (概念実証) を設定して実行する方法について以下に説明します。PoC (概念実証) は、Aurora がアプリケーションに適合しているかどうかを判断するために実施する調査です。PoC (概念実証) は、独自のデータベースアプリケーションのコンテキストにおける Aurora の機能と、現在のデータベース環境に対する Aurora の適合性を理解するのに役立ちます。また、データの移動、SQL コードの移植、パフォーマンスのチューニングを行い、現在の管理手順を適応させるために必要となる労力の目安を提供します。

このトピックでは、PoC (概念実証) を実行するための大まかなステップと意思決定について、ステップバイステップの概要を以下に提供します。詳細な手順については、リンクに従って主題別の詳細なドキュメントを参照してください。

Aurora の PoC (概念実証) の概要

Amazon Aurora の PoC (概念実証) を実行すると、既存のデータや SQL アプリケーションを Aurora に移植するために何が必要であるかを判断できます。本番環境に特徴的なデータ量やアクティビティを使用して Aurora の重要な機能を広範に試します。この目的は、以前のデータベースインフラストラクチャでは対応できなくなった課題に対して、Aurora の強力な機能で対応できることを確認することにあります。PoC (概念実証) を完了すると、より大規模なパフォーマンスのベンチマークとアプリケーションのテストを行うための堅実な計画を立てることができます。この時点で、本番稼働用デプロイに必要な最大の作業項目が明らかになります。

以下のベストプラクティスに関するアドバイスを参考にして、ベンチマーク時の問題の原因となる一般的な間違いを避けることができます。ただし、このトピックでは、ベンチマークやパフォーマンスチューニングのステップバイステップのステップは提供しません。これらの手順は、ワークロードや実際に使用する Aurora 機能に応じて異なります。詳細については、「Aurora DB クラスターのパフォーマンスとスケーリングの管理」、「Amazon Aurora MySQL パフォーマンスの拡張」、「Amazon Aurora PostgreSQL のパフォーマンスとスケーリング」、「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」などのパフォーマンス関連のドキュメントを参照してください。

このトピックの説明は、貴社がコードを記述してスキーマを設計するアプリケーション、MySQL や PostgreSQL のオープンソースデータベースエンジンをサポートするアプリケーションに主に該当します。商用アプリケーションや、アプリケーションフレームワークで生成されたコードをテストする場合、貴社が柔軟に対応できず、一部のガイドラインを適用できないことがあります。このような場合は、アプリケーションのタイプに応じた Aurora のベストプラクティスや導入事例があるかどうかを AWS の担当者にお問い合わせください。

1. 目標を明確にする

PoC (概念実証) の一環として Aurora を評価する場合は、実施する測定の種類と成功の評価方法を選択します。

アプリケーションのすべての機能が Aurora と互換性があることを確認する必要があります。Aurora メジャーバージョンは、対応する MySQL および PostgreSQL のメジャーバージョンとワイヤ互換性があるため、これらのエンジン用に開発されたほとんどのアプリケーションは、Auroraとも互換性があります。ただし、その場合でも、アプリケーション別に互換性を検証する必要があります。

例えば、Aurora クラスターの設定時に選択するオプションのいくつかは、特定のデータベース機能を使用できるかどうか、使用すべきかどうかに影響します。まず、最も汎用的な Aurora クラスターであるプロビジョンドクラスターからスタートできます。次に、サーバーレスやパラレルクエリなどの特化された設定が、ワークロードに利点をもたらすかどうかを判断できます。

目標を明確にして定量化するには、以下の問いが役立ちます。

• Aurora はワークロードのすべての機能ユースケースをサポートするか?

• 必要なデータセットサイズやロードレベルは何であるか? このレベルまでスケールできるか?

• クエリスループットやレイテンシーの具体的な要件は何であるか? これらの要件を達成できるか?

• ワークロードの予定されたダウンタイムまたは予定外のダウンタイムの最小許容時間はどれくらいであるか? これを達成できるか?

• 業務効率に関して必要なメトリクスは何であるか? これらのメトリクスを正確にモニタリングできるか?

• Aurora は特定のビジネス目標 (コストの削減、デプロイの拡張、プロビジョニングのスピードなど) をサポートするか? これらの目標を定量化する方法があるか?

• ワークロードに関するすべてのセキュリティおよびコンプライアンス要件を満たすことができるか?

少し時間をかけて Aurora データベースエンジンとプラットフォームの機能に関する知識を深め、サービスドキュメントを確認します。必要な結果を達成するために役立つすべての機能に注目します。これらの機能の 1 つとしてワークロードの統合が挙げられます。詳細については、AWS Database Blog 記事「ワークロードの統合に向けた Amazon Aurora と MySQL の互換性の計画と最適化の方法」を参照してください。別の機能としては、需要に基づくスケーリングが挙げられます。詳細については、Amazon Aurora ユーザーガイド の「Aurora レプリカでの Amazon Aurora Auto Scaling」を参照してください。その他の機能として、パフォーマンスの向上やデータベース操作の簡素化などが挙げられます。

2. ワークロードの特性を理解する

意図したユースケースに則って Aurora を評価します。Aurora は、オンライントランザクション処理 (OLTP) ワークロードに適しています。別個のデータウェアハウスクラスターをプロビジョンせずに、リアルタイムの OLTP データを保持するクラスターでレポートを実行することもできます。ユースケースが上記のカテゴリに該当するかどうかは、以下の特性をチェックすることで判断できます。

• 数十、数百、または数千の同時クライアントを伴う高い同時実行。

• 大量の低レイテンシークエリ (ミリ秒単位～秒単位)。

• 短い、リアルタイムのトランザクション。

• 高度に選択的なクエリパターン (インデックスベースのルックアップを使用)。

• HTAP の場合、Aurora のパラレルクエリを利用する分析クエリ。

データベースの選択に影響する主な要因の 1 つは、データの速度です。高速では、データが非常に頻繁に挿入されて更新されます。このようなシステムでは、数千の接続や数十万の同時クエリがデータベースに対して読み書きされる場合があります。高速システムのクエリは、通常、比較的少数の行に影響します。また、通常、同じ行の複数の列にアクセスします。

Aurora は、高速データを処理するように設計されています。ワークロードに応じて異なりますが、単一の r4.16xlarge DB インスタンスを持つ Aurora クラスターの場合、1 秒あたり 600,000 個を超える SELECT ステートメントを処理できます。ワークロードに応じて、このようなクラスターは、INSERT、UPDATE、および DELETE ステートメントを、1 秒あたり 200,000 回処理できます Aurora は行指向のストアデータベースであり、高ボリューム、高スループット、および高度にパラレル化された OLTP ワークロードに最適です。

また、Aurora は、OLTP ワークロードを処理する同じクラスターで、レポートクエリを実行することもできます。Aurora は最大 15 個のレプリカをサポートします。各レプリカは平均して、プライマリインスタンスの 10～20ミリ秒以内を消費します。アナリストは、データを別個のデータウェアハウスクラスターにコピーせずに、リアルタイムで OLTP データにクエリを実行できます。パラレルクエリ機能を使用する Aurora クラスターでは、処理、フィルター処理、および集約作業の多くを、広く分散された Aurora ストレージシステムにオフロードできます。

この計画フェーズで、Aurora の機能、他の AWS のサービス、AWS Management Console、および AWS CLI に関する知識を深めてください。また、これらが、PoC (概念実証) で使用予定の他のツールとどのように連携するかも確認します。

3. AWS Management Console または AWS CLI を試す

次のステップとして、AWS Management Console または AWS CLI の実践を通じ、これらのツールや Aurora に習熟します。

AWS Management Console を試す

Aurora データベースクラスターに関する以下の初期アクティビティでは、主とｓｈちえ、AWS Management Console 環境に慣れながら Aurora クラスターの設定と変更を試すことができます。MySQL 互換および PostgreSQL 互換のデータベースエンジンを Amazon RDS で使用している場合は、Aurora を使用する際にその知識を活かすことができます。

Aurora の共有ストレージモデルや機能 (レプリケーションやスナップショットなど) を利用することで、データベースクラスター全体を一種の自由に操作可能なオブジェクトとして扱うことができます。Aurora クラスターの容量は、PoC (概念実証) 中に頻繁に設定、削除、変更できます。容量、データベース設定、物理データレイアウトに関する初期の選択に縛られることはありません。

使用をスタートするには、空の Aurora クラスターを設定します。初期に試すプロビジョンド容量タイプとリージョンの場所を選択します。

SQL コマンドラインアプリケーションなどのクライアントプログラムを使用して、このクラスターに接続します。初期は、クラスターエンドポイントを使用して接続します。このエンドポイントに接続して、データ定義言語 (DDL) ステートメントや、抽出、変換、読み取り (ETL) プロセスなどの書き込みオペレーションを実行します。PoC (概念実証) の後半では、リーダーエンドポイントを使用してクエリが集中するセッションを接続します。これにより、クエリのワークロードがクラスター内の複数の DB インスタンスに分散されます。

Aurora レプリカの数を増やしてクラスターをスケールアウトします。詳しい手順については、「Amazon Aurora でのレプリケーション」を参照してください。AWS インスタンスクラスを変更することで DB インスタンスをスケールアップ/ダウンします。Aurora では、この種のオペレーションが簡素化されているため、システム容量に関する初期の見積りが不正確でも、すべてをやり直さずに後で調整できます。

スナップショットを作成して別のクラスターに復元します。

クラスターのメトリクスを調べて、時間の経過に伴うアクティビティと、メトリクスがクラスター内の DB インスタンスにどのように適用されるかを確認します。

初期の段階で以上のオペレーションを AWS Management Console で実行する方法に慣れることが役立ちます。Aurora で実行できるオペレーションを理解したら、これらのオペレーションを AWS CLI で自動化する手法に進みます。以下のセクションでは、PoC (概念実証) 時における以上のアクティビティの手順とベストプラクティスについて詳しく説明します。

AWS CLI を試す

デプロイと管理の手順は、PoC (概念実証) の設定段階においても自動化することをお勧めします。これを行うには、AWS CLI の使い方に慣れます (まだ慣れていない場合)。MySQL 互換および PostgreSQL 互換のデータベースエンジンを Amazon RDS で使用している場合は、Aurora を使用する際にその知識を活かすことができます。

通常、Aurora では、DB インスタンスのグループがクラスターとして編成されます。したがって、多くのオペレーションでは、どの DB インスタンスがクラスターに関連付けられているかを判断し、すべてのインスタンスに対して管理オペレーションをループで実行します。

例えば、Aurora クラスターの作成などのステップを自動化し、スケールアップしてインスタンスのサイズを大きくしたり、スケールアウトして DB インスタンス数を増やしたりできます。これにより、PoC (概念実証) のステージを繰り返し、Aurora クラスターの異なる種類や異なる設定で what-if シナリオを試すことができます。

インフラストラクチャのデプロイツール (AWS CloudFormation など) の機能と制限を確認します。PoC (概念実証) のコンテキストで実行するアクティビティが、本番稼働用として適していないことが判明する場合があります。例えば、AWS CloudFormation による変更動作では、新しいインスタンスを作成して現在のもの (データを含む) を削除します。この動作の詳細については、AWS CloudFormation ユーザーガイドの「スタックのリソースの更新動作」を参照してください。

4. Aurora クラスターを作成する

Aurora では、what-if シナリオを試すために、DB インスタンスをクラスターに追加し、これらの DB インスタンスをより強力なインスタンスクラスにスケールアップできます。また、構成設定が異なる複数のクラスターを作成して、同じワークロードをパラレルして実行することもできます。Aurora では、DB クラスターを非常に柔軟に設定、削除、および再設定できます。このため、これらの手法を PoC (概念実証) プロセスの初期ステージで身に付けることが役立ちます。Aurora クラスターの一般的な作成手順については、「Amazon Aurora DB クラスターの作成」を参照してください。

可能であれば、以下の設定を使用してクラスターをスタートします。このステップをスキップするのは、特定のユースケースを決めている場合に限ります。例えば、特化された種類の Aurora クラスターがユースケースで必要な場合は、このステップをスキップできます。また、特定のデータベースエンジンとバージョンの組み合わせが必要な場合にも、スキップできます。

• [Easy create (簡易作成)] を無効にします。PoC (概念実証) では、同じクラスターやわずかに異なるクラスターを後で作成できるように、すべての選択した設定を把握しておくことをお勧めします。

• 最新の DB エンジンバージョンを使用します。データベースエンジンとバージョンのこれらの組み合わせは、Aurora の他の機能との互換性が高く、本番アプリケーションとしてカスタマーに広く使用されています。

  • Aurora MySQL バージョン 3.x (MySQL 8.0 互換)

  • Aurora PostgreSQL バージョン 15.x または 16.x

• [開発/テスト] テンプレートを選択します。このオプションは、PoC (概念実証) のアクティビティでは重要ではありません。

• [DB instance class (DB インスタンスクラス)] で、[Memory optimized classes (メモリ最適化クラス)] を選択し、[xlarge] インスタンスクラスのいずれかを選択します。インスタンスクラスは、スケールアップ/ダウンできます。

• [Multi-AZ Deployment (マルチ AZ 配置)] で、[Create an Aurora Replica or リーダー node in a different AZ (別の AZ に Aurora レプリカまたはリーダーノードを作成)] を選択します。Aurora の最も役立つ機能の多くでは、複数の DB インスタンスを持つクラスターを使用します。すべての新しいクラスターは、最低 2 つの DB インスタンスで常にスタートするのが合理的です。2 つ目の DB インスタンスに別のアベイラビリティーゾーンを使用することで、複数の異なる高可用性シナリオをテストできます。

• DB インスタンスに名前を付ける場合は、一般的な命名規則に従います。クラスターの DB インスタンスを「ライター」として参照しないようにします。これらのロールは、必要に応じて、複数の異なる DB インスタンスが引き受ける場合があるためです。clustername-az-serialnumber (myprodappdb-a-01 など) を使用することをお勧めします。これらの名前は、DB インスタンスとその配置を一意に識別します。

• Aurora クラスターのバックアップの保存期間を [高] に設定します。保存期間を長くすると、最大 35 日間にわたってポイントインタイムリカバリ (PITR) を実行できます。DDL やデータ操作言語 (DML) のステートメントを伴うテストを実行したら、データベースを既知の状態にリセットできます。データを間違えて削除または変更した場合は、復旧することもできます。

• クラスターの作成時に、追加の復旧、ログ記録、モニタリング機能を有効にします。[バックトラック]、[Performance Insights]、[モニタリング]、および [ログのエクスポート] のすべてのオプションをオンにします。これらの機能を有効にすると、ワークロードのバックトラック、拡張モニタリング、Performance Insights などの機能の適合性をテストできます。PoC (概念実証) 中に、簡単にパフォーマンスを調査してトラブルシューティングを実行することもできます。

5. スキーマを設定する

Aurora クラスターで、アプリケーション用のデータベース、テーブル、インデックス、外部キーなどのスキーマオブジェクトを設定します。別の MySQL 互換または PostgreSQL 互換のデータベースシステムから移行する場合、これは簡単明快なステージとなります。使い慣れている同じ SQL 構文やコマンドラインまたは他のクライアントアプリケーションをデータベースエンジンで使用します。

クラスターで SQL ステートメントを発行するには、そのクラスターエンドポイントを見つけて、その値を接続パラメータとしてクライアントアプリケーションに渡します。クラスターエンドポインは、クラスターの詳細ページの [Connectivity (接続)] タブで見つけることができます。クラスターエンドポイントには、[書き込み] というラベルが付いています。[リーダー] というラベルが付いた他のエンドポイントは、読み取り専用接続であり、レポートや他の読み取り専用クエリを実行するエンドユーザーに渡すことができます。クラスターへの接続問題のヘルプについては、「Amazon Aurora DB クラスターへの接続」を参照してください。

スキーマやデータを別のデータベースシステムから移植する場合は、この時点でスキーマの変更を行う必要があります。これらのスキーマの変更は、Aurora の SQL 構文や機能と一致させる必要があります。この時点で、特定の列、制約、トリガーなどのスキーマオブジェクトを除外できます。これは、Aurora との互換性のために、これらのオブジェクトの手直しが必要な場合に特に役立つ場合があります。ただし、PoC (概念実証) の目的には重要ではありません。

基盤となるエンジンが Aurora のものとは異なるデータベースシステムから移行する場合は、AWS Schema Conversion Tool (AWS SCT) を使用してプロセスを簡素化することを検討してください。詳細については、AWS Schema Conversion Tool ユーザーガイドを参照してください。移行および移植アクティビティの一般的な詳細については、AWS ホワイトペーパー「Amazon Aurora へのデータベースの移行」を参照してください。

このステージでは、スキーマ設定に非効率が存在するかどうかを評価できます。例えば、インデックス作成戦略や他のテーブル構造 (パーティショニングされたテーブルなど) の非効率を評価します。このような非効率は、アプリケーションのデプロイ先のクラスターに複数の DB インスタンスや重いワークロードがあると、増幅される場合があります。このようなパフォーマンス面の微調整を今すぐ行うか、後でフルベンチマークテストなどのアクティビティ時に行うかを判断します。

6. データをインポートする

PoC (概念実証) では、以前のデータベースシステムからデータ全体または代表的なサンプルをインポートします。可能であれば、テーブルごとに少なくとも一部のデータを設定します。これにより、すべてのデータ型とスキーマ機能の互換性をテストできます。基本的な Aurora 機能を実行したら、データ量をスケールアップします。PoC (概念実証) が完了するまでに、正確な結論を引き出せるだけのサイズのデータセットを使用して、ETL ツール、クエリ、およびワークロード全体をテストする必要があります。

物理または論理的なバックアップデータを Aurora にインポートするには、いくつかの手法を利用できます。詳細については、PoC (概念実証) で使用するデータベースエンジンに応じて、「Amazon Aurora MySQL DB クラスターへのデータの移行」または「PostgreSQL と互換性がある Amazon Aurora にデータを移行する」を参照してください。

検討している ETL ツールやテクノロジーを試します。どれがニーズに最適であるかを判断します。スループットと柔軟性の両方を検討します。例えば、ETL ツールによっては 1 回の転送を実行するものと、古いシステムから Aurora への継続的なレプリケーションを実行するものがあります。

MySQL 互換システムから Aurora MySQL に移行する場合は、ネイティブのデータ転送ツールを使用できます。PostgreSQL 互換システムから Aurora PostgreSQL に移行する場合も同様です。基盤となるエンジンが Aurora のものとは異なるデータベースシステムから移行する場合は、AWS Database Migration Service (AWS DMS) を試すことができます。AWS DMS の詳細については、AWS Database Migration Service ユーザーガイドを参照してください。

移行および移植アクティビティの詳細については、AWS ホワイトペーパー「Aurora 移行ハンドブック」を参照してください。

7. SQL コードを移植する

SQL および関連アプリケーションを試すには、ケース別に異なる労力レベルが必要になります。特に、MySQL 互換/PostgreSQL 互換システムまたは別の種類から移行する場合は、労力レベルが異なります。

• RDS for MySQL や RDS for PostgreSQL から移行する場合、SQL の変更は小規模であり、Aurora で元の SQL コードを試して必要な変更を手動で反映できます。

• 同様に、MySQL や PostgreSQL と互換性があるオンプレミスデータベースから移行する場合は、元の SQL コードを試して手動で変更を反映できます。

• 別の商用データベースから移行する場合、SQL に必要な変更はより広範囲に及びます。このような場合は、AWS SCT の使用を検討します。

このステージでは、スキーマ設定に非効率が存在するかどうかを評価できます。例えば、インデックス作成戦略や他のテーブル構造 (パーティショニングされたテーブルなど) の非効率を評価します。このようなパフォーマンス面の微調整を今すぐ行うか、後でフルベンチマークテストなどのアクティビティ時に行うかを判断します。

アプリケーションでデータベース接続ロジックを検証できます。Aurora の分散処理を利用するには、必要に応じて、読み取りオペレーションと書き込みオペレーションに別個の接続を使用します。また、クエリオペレーションには比較的短いセッションを使用します。接続の詳細については、「9. Aurora に接続する」を参照してください

プロダクションデータベースの問題を回避するために妥協やトレードオフが必要であったかどうかを考えます。PoC (概念実証) のスケジュール内に、スキーマの設計とクエリを改善するための時間を組み入れます。パフォーマンス、運用コスト、スケーラビリティを簡単に改善できるかどうかを判断するには、元のアプリケーションと変更後のアプリケーションを異なる Aurora クラスターでパラレル実行します。

移行および移植アクティビティの詳細については、AWS ホワイトペーパー「Aurora 移行ハンドブック」を参照してください。

8. 構成設定を指定する

Aurora の PoC (概念実証) の一環として、データベースの設定パラメータを見直すこともできます。MySQL や PostgreSQL の構成設定は、現在の環境のパフォーマンスやスケーラビリティに応じて、すでにチューニングされている場合があります。Aurora のストレージサブシステムは、高速のストレージサブシステムを備えた分散型のクラウドベース環境に適応するようにチューニングされています。そのため、多くの以前のデータベースエンジン設定は該当しません。初期の実験は Aurora のデフォルトの構成設定で実施することをお勧めします。現在の環境の設定を再適用するのは、パフォーマンスやスケーラビリティのボトルネックが生じた場合のみとします。この主題に関心がある場合は、AWS データベースブログの記事「Aurora ストレージエンジンの紹介」で詳細を参照してください。

Aurora では、特定のアプリケーションやユースケースの最適な構成設定を簡単に再利用できます。DB インスタンスごとに別個の設定ファイルを編集せずに、パラメータセットを管理し、クラスター全体や DB インスタンス別に割り当てます。例えば、タイムゾーンの設定はクラスター内のすべての DB インスタンスに適用されます。ページのキャッシュサイズ設定は DB インスタンス別に調整できます。

デフォルトのパラメータセットのいずれかを使用してスタートし、微調整する必要があるパラメータにのみ変更を適用します。パラメータグループの使用の詳細については、「Amazon Aurora の DB クラスターパラメータと DB インスタンスパラメータ」を参照してください。Aurora クラスターに適用される、または適用されない構成設定については、使用しているデータベースエンジンに応じて「Aurora MySQL 設定パラメータ」または「Amazon Aurora PostgreSQL のパラメータ」を参照してください。

9. Aurora に接続する

初期のスキーマやデータを設定したり、サンプルクエリを実行したりする場合に、Aurora クラスター内の複数の異なるエンドポイントに接続できます。どのエンドポイントを使用するかは、オペレーションが読み取りであるか (SELECT ステートメントなど)、書き込みであるか (CREATE や INSERT ステートメントなど) に応じて異なります。Aurora クラスターでワークロードを増やして Aurora 機能を試す場合、アプリケーションで各オペレーションを適切なエンドポイントに割り当てることが重要です。

書き込みオペレーション用のクラスターエンドポイントを使用すると、クラスター内で読み取り/書き込み機能を持つ DB インスタンスに常に接続されます。デフォルトでは、Aurora クラスター内で読み取り/書き込み機能を持つ DB インスタンスは 1 つのみです。この DB インスタンスは、プライマリインスタンスと呼ばれます。プライマリインスタンスが使用不能になると、Aurora はフェイルオーバー機構をアクティブ化して別の DB インスタンスをプライマリとして昇格させます。

同様に、SELECT ステートメントをリーダーエンドポイントに振り向けると、処理クエリの作業がクラスター内の複数の DB インスタンスに分散されます。各リーダー接続は、ラウンドロビン DNS 解像度を使用して異なる DB インスタンスに割り当てられます。ほとんどのクエリ作業を読み取り専用の DB Aurora レプリカで処理することで、プライマリインスタンスに対する負荷が減り、プライマリインスタンスの解放された容量ーで DDL ステートメントや DML ステートメントを処理できます。

これらのエンドポイントを使用すると、ハードコードされたホスト名に対する依存が減り、アプリケーションは DB インスタンスの障害から迅速に復旧できます。

注記

Aurora では、独自に作成したカスタムエンドポイントも使用できます。通常、これらのエンドポイントは PoC (概念実証) に不要です。

Aurora レプリカはレプリカラグを伴います。ただし、通常、ラグは 10～20 ミリ秒です。レプリケーションラグをモニタリングして、それがデータの整合性要件の範囲内であるかどうかを判断できます。場合によっては、読み取りクエリで強力な読み取りの整合性 (書き込み直後の読み取りの整合性) が必要になることがあります。このような場合は、リーダーエンドポイントを使用せずに、引き続きクラスターエンドポイントを使用できます。

分散型のパラレル実行で Aurora の機能を最大限に活用するには、接続ロジックの変更が必要になる場合があります。目的は、すべての読み取りリクエストをプライマリインスタンスに送信するのを避けることにあります。読み取り専用の Aurora レプリカはスタンバイしています。すべての同じデータを使用し、SELECT ステートメントを処理する準備ができています。オペレーションの種類別に適切なエンドポイントを使用するようにアプリケーションロジックのコードを記述します。以下の一般的なガイドラインに従ってください。

• すべてのデータベースセッションに 1 つのハードコードされた接続文字列を使用するのを避けます。

• できれば、DDL ステートメントや DML ステートメントなどの書き込みオペレーションをクライアントアプリケーションコードの関数で囲います。これにより、オペレーションの種類別に異なる接続を使用できます。

• クエリオペレーションのための個別の関数を作成します。Aurora は、リーダーエンドポイントへの新しい接続ごとに異なる Aurora レプリカを割り当てることで、読み取りが集中するアプリケーションの負荷を分散します。

• クエリのセットを使用するオペレーションでは、関連するクエリの各セットが終了したら、リーダーエンドポイントへの接続を閉じて再び開きます。この機能をソフトウェアスタックで使用できる場合は、接続プーリングを使用します。クエリを複数の異なる接続に振り向けると、Aurora はクラスター内の複数の DB インスタンスに読み取りワークロードを分散しやすくなります。

Aurora の接続の管理とエンドポイントの一般的な情報については、「Amazon Aurora DB クラスターへの接続」を参照してください。この主題の詳細については、「Aurora MySQL データベース管理者のハンドブック - 接続管理」を参照してください。

10. ワークロードを実行する

スキーマ、データ、および構成設定が済んだら、ワークロードを実行することでクラスターを試すことができます。本番稼働用ワークロードの主な要素をミラーリングする PoC (概念実証) のワークロードを使用します。sysbench や TPC-C などの合成ベンチマークを使用せずに、常に実際のテストやワークロードを使用してパフォーマンスに関する意思決定を行うことをお勧めします。その際は、独自のスキーマ、クエリパターン、使用ボリュームに基づく測定値をできるだけ収集します。

可能な限り、アプリケーションが実行される実際の条件を再現します。例えば、アプリケーションコードは、一般的に Aurora クラスターと同じ AWS リージョンと Virtual Private Cloud (VPC) の Amazon EC2 インスタンスで実行します。本番稼働用アプリケーションが複数のアベイラビリティーゾーンにまたがる複数の EC2 インスタンスで実行される場合は、PoC (概念実証) の環境も同じように設定します。AWS リージョンの詳細については、Amazon RDS ユーザーガイドの「リージョンとアベイラビリティーゾーン」を参照してください。Amazon VPC サービスの詳細については、Amazon VPC ユーザーガイドの「Amazon VPC とは」を参照してください。

アプリケーションの基本的な機能が動作することを確認し、Aurora を通じてデータにアクセスできたら、Aurora クラスターの機能を試すことができます。同時接続とロードバランシング、同時実行トランザクション、自動レプリケーションなどの機能を試すことができます。

この時点までには、データ転送機構に慣れているはずなので、サンプルデータを増やしてテストを実行できます。

このステージでは、メモリの制限や接続の制限などの構成設定を変更した結果を確認できます。「8. 構成設定を指定する」で試した手順を再度参照してください。

スナップショットの作成や復元などの機構を試すこともできます。例えば、AWS インスタンスクラスを変えたり、AWS レプリカの数を変えたりしてクラスターを作成できます。次に、各クラスターで、スキーマとすべてのデータを含む同じスナップショットを復元できます。このサイクルの詳細については、「DB クラスタースナップショットの作成」と「DB クラスターのスナップショットからの復元」を参照してください。

11. パフォーマンスを測定する

当領域のベストプラクティスでは、すべての適切なツールとプロセスが、ワークロードオペレーション中の異常な動作をすばやく隔離するように設定されていることを確認します。また、これらのツールやプロセスが該当する原因を確実に特定できるように設定されていることを確認します。

[モニタリング] タブを参照することで、常にクラスターの現在の状態を確認したり、時間の経過に伴う傾向を調べたりできます。このタブは、Aurora クラスターや DB インスタンスごとにコンソールの詳細ページから利用できます。Amazon CloudWatch モニタリングサービスのメトリクスがグラフ形式で表示されます。メトリクスは、名前、DB インスタンス、および期間をフィルターとして絞り込むことができます。

[モニタリング] タブで使用できるオプションを増やすには、クラスター設定で拡張モニタリングと Performance Insights を有効にします。これらのオプションは、クラスターの設定時に選択しなかった場合、後で有効にすることもできます。

パフォーマンスを測定するには、Aurora クラスター全体のアクティビティを示すグラフに主に依存します。Aurora レプリカ間で負荷や応答時間が類似しているかどうかを確認できます。読み取り/書き込みプライマリインスタンスと読み取り専用 Aurora レプリカの間で作業がどのように分担されているかも確認できます。複数の DB インスタンス間に不均衡がある場合や、1 つの DB インスタンスにのみ影響する問題がある場合は、該当するインスタンスについて [モニタリング] で調査できます。

本番稼働用アプリケーションをエミュレートするように環境と実際のワークロードを設定したら、Aurora がどれだけ適切に動作しているかを測定できます。ここで最も重要な問いは以下のとおりです。

• Aurora で処理している 1 秒あたりのクエリ数は? オペレーションの種類別の数については、[スループット] メトリクスで確認できます。

• Aurora で特定のクエリを処理する平均所要時間は? オペレーションの種類別の数については、[レイテンシー] メトリクスで確認できます。

スループットとレイテンシーのメトリクスを表示するには、Amazon RDS コンソールで特定の Aurora クラスターの [モニタリング] タブを確認します。次のスクリーンショットは、[モニタリング] タブの [選択レイテンシー]、[DML レイテンシー]、[選択スループット]、および [DML スループット] メトリクスの例を示しています。

できれば、これらのメトリクスのベースライン値を現在の環境で確立します。これができない場合は、本番稼働用アプリケーションと同等のワークロードを実行して Aurora クラスターでベースラインを構築します。例えば、同数の同時ユーザーおよびクエリを使用して Aurora ワークロードを実行します。次に、異なるインスタンスクラス、クラスターサイズ、構成設定などを試すたびに、どのように値が変わるかを確認します。

スループットの数値が期待より低い場合は、ワークロードのデータベースパフォーマンスに影響する要因をさらに調査します。同様に、レイテンシーの数値が期待より高い場合は、さらに調査します。これを行うには、DB サーバーのセカンダリメトリクス (CPU やメモリ など) をモニタリングします。DB インスタンスがその制限に近づいているかどうかを確認できます。同時実行クエリやより大きなテーブルに対するクエリなどを処理するための DB インスタンスの追加の容量を確認することもできます。

ヒント

想定範囲から外れているメトリクス値を検出するには、CloudWatch のアラームを設定します。

最適な Aurora クラスターサイズと容量を評価する場合は、リソースを過剰にプロビジョニングせずに、アプリケーションのピークパフォーマンスを達成する設定を確認できます。1 つの重要な要素は、Aurora クラスター内の DB インスタンスの適切なサイズを確認することです。まず、現在の本番環境と類似した CPU およびメモリ容量を持つインスタンスサイズを選択します。このインスタンスサイズで、ワークロードのスループットとレイテンシーの数値を収集します。次に、インスタンスを次のより大きなサイズにスケールアップします。スループットとレイテンシーの数値が改善したかどうかを確認します。また、サイズをスケールダウンして、スループットとレイテンシーの数値が同じままであるかどうかを確認します。目標は、できる限り最小のインスタンスで最高のスループットと最低のレイテンシーを達成することにあります。

ヒント

Aurora クラスターおよび関連する DB インスタンスのサイズを変更して、既存の容量で突然の想定外のトラフィックスパイクを十分に処理できるようにします。ミッションクリティカルなデータベースの場合は、少なくとも 20% のスペア CPU とメモリ容量を残します。

ウォームな安定した状態でデータベースパフォーマンスを測定できるほどの時間にかけて、パフォーマンステストを実行します。この安定した状態に達するまでに数分または数時間にわたり、ワークロードを実行する必要がある場合もあります。実行のスタート時には、通常、いくらかの変動があります。この変動が発生するのは、各 Aurora レプリカが処理対象の SELECT クエリに応じてキャッシュをウォームアップするためです。

Aurora は、複数の同時実行ユーザーおよびクエリが関わるトランザクションワークロードで最適に動作します。最適なパフォーマンスに応じた負荷を駆動していることを確認するには、マルチスレッドを使用するベンチマークを実行するか、パフォーマンステストの複数のインスタンスを同時に実行します。数百または数千の同時実行クライアントスレッドを使用してパフォーマンスを測定します。本番環境で想定される同時実行スレッドの数をシミュレートします。スレッド数を増やして追加のストレステストを実行し、Aurora のスケーラビリティを測定することもできます。

12. Aurora の高可用性を試す

Aurora の主要な機能では、高可用性を使用します。これらの機能には、自動レプリケーション、自動フェイルオーバー、自動バックアップとポイントインタイム復元、クラスターに DB インスタンスを追加する機能などが含まれます。このような機能の安全性と信頼性は、ミッションクリティカルなアプリケーションにとって重要です。

これらの機能を評価するには考え方を変える必要があります。これまでのアクティビティ (パフォーマンスの測定など) では、すべてが正常に動作した場合を想定して、システムのパフォーマンスを確認しました。高可用性のテストでは、最悪の動作を想定する必要があります。様々な障害 (めったに発生しない障害も含めて) を検討する必要があります。システムが正常かつ迅速に復旧することを確認するために、意図的に問題を作り出す場合もあります。

ヒント

概念実証の段階では、同じ AWS インスタンスクラスを使用して Aurora クラスター内のすべての DB インスタンスを設定します。これにより、DB インスタンスをオフラインにして障害をシミュレートする場合に、パフォーマンスやスケーラビリティの大きな変更なしに、Aurora の可用性の機能を試すことができます。

Aurora クラスターごとに少なくとも 2 つのインスタンスを使用することをお勧めします。Aurora クラスターの DB インスタンスは、最大 3 つのアベイラビリティーゾーン (AZ) にまたがることができます。初期の 2 つまたは 3 つの DB インスタンスのそれぞれを異なる AZ に配置します。より大きなクラスターを使い始めた場合は、AWS リージョンのすべての AZ に DB インスタンスを分散します。これにより、耐障害性機能が強化されます。問題が AZ 全体に影響する場合でも、Aurora は別の AZ の DB インスタンスにフェイルオーバーできます。実行するクラスター内のインスタンス数が 3 つを超えている場合は、3 つすべての AZ にできるだけ均等に DB インスタンスを分散します。

ヒント

Aurora クラスターのストレージは、DB インスタンスから独立しています。各 Aurora クラスターのストレージは常に 3 つの AZ にまたがります。

高可用性機能をテストする場合は、テストクラスター内の各 DB インスタンスの容量を必ず同じサイズにします。これにより、1 つの DB インスタンスが別のインスタンスに取って代わった場合に、パフォーマンスやレイテンシーなどに想定外の変更が起きないようにします。

障害の条件をシミュレートして高可用性機能をテストする方法については、「障害挿入クエリを使用した Amazon Aurora MySQL のテスト」を参照してください。

PoC (概念実証) における 1 つの目的は、DB インスタンスの最適な数と、これらの DB インスタンスの最適なインスタンスクラスを確認することにあります。これには、高可用性の要件とパフォーマンスの要件の間でバランスを取る必要があります。

Aurora では、クラスター内の DB インスタンス数が増えるほど、高可用性の利点が大きくなります。DB インスタンス数が増えるほど、読み取りが集中するアプリケーションのスケーラビリティも向上します。Aurora は、SELECT クエリのための複数の接続を、読み取り専用の Aurora レプリカ間で分散することができます。

一方、DB インスタンス数を制限すると、プライマリノードからのレプリケーショントラフィックが減少します。レプリケーショントラフィックは、ネットワークの帯域幅を消費します。これは全体的なパフォーマンスとスケーラビリティに伴う別の側面です。したがって、書き込みが集中する OLTP アプリケーションの場合、多数の小さい DB インスタンスを使用しないで、少数の大きな DB インスタンスを使用することを優先します。

代表的な Aurora クラスターでは、1 つの DB インスタンス (プライマリインスタンス) ですべての DDL ステートメントと DML ステートメントを処理します。他の DB インスタンス (Aurora レプリカ) は、SELECT ステートメントのみを処理します。各 DB インスタンスが正確に同じ量の作業を行うわけではありませんが、クラスター内のすべての DB インスタンスに同じインスタンスクラスを使用することをお勧めします。これにより、障害が発生して、Aurora が読み取り専用 DB インスタンスの 1 つを新しいプライマリインスタンスとして昇格させた場合、このプライマリインスタンスの容量は以前と同じになります。

同じクラスター内の DB インスタンス間で異なる容量ーを使用する必要がある場合は、DB インスタンスのフェイルオーバー階層を設定します。これらの階層は、フェイルオーバー機構で Aurora レプリカを昇格させる順番を決定します。DB インスタンスが他の DB インスタンスより大きいか、より小さいほど、より低いフェイルオーバー階層に配置します。これにより、これらのインスタンスの昇格順位は後回しになります。

Aurora のデータ復旧機能 (自動ポイントインタイプ復元、手動スナップショットと復元、クラスターのバックトラッキングなど) を試します。必要に応じて、スナップショットを他の AWS リージョンにコピーしたり、他の AWS リージョン内に復元したりして、DR シナリオを模倣します。

貴社の目標復旧時間 (RTO)、目標復旧時点 (RPO)、地理的冗長性に関する要件を確認します。ほとんどの組織では、これらの項目を災害対策という大まかなカテゴリに一括しています。このセクションで説明した Aurora の高可用性機能を災害対策プロセスのコンテキストで評価し、RTO と RPO の要件を満たしていることを確認します。

13. 次のステップ

PoC (概念実証) プロセスが正常に完了したら、想定されるワークロードに基づいて Aurora が適切なソリューションであることを確認します。これまでのプロセス全体を通じて、Aurora が実際の運用環境でどのように動作するかを確認し、成功の条件に照らして測定を行いました。

Aurora を使用してデータベース環境を起動して稼動中の状態になったら、より詳細な評価ステップに移動して、最終的な移行と本番稼働用デプロイに備えることができます。実際の状況に応じて、これらの他のステップは PoC (概念実証) プロセスに含まれる場合と含まれない場合があります。移行および移植アクティビティの詳細については、AWS ホワイトペーパー「Aurora 移行ハンドブック」を参照してください。

また、別のステップとして、本番環境のセキュリティ要件を満たすように設計された、ワークロード関連のセキュリティ設定を検討します。Aurora クラスターのマスターユーザー認証情報に対するアクセスを保護するために、どの制御を実装するかを計画します。Aurora クラスターに保存されたデータに対するアクセス制御でデータベースユーザーが果たすロールと責任を定義します。アプリケーション、スクリプト、およびサードパーティー製のツールやサービスに対するデータベースアクセス要件を考慮します。AWS Secrets Manager や AWS Identity and Access Management (IAM) 認証などの AWS のサービスや機能を試します。

この時点では、Aurora でベンチマークテストを実行するための手順とベストプラクティスを理解しているはずです。追加のパフォーマンスチューニングが必要であることが判明する場合があります。詳細については、「Aurora DB クラスターのパフォーマンスとスケーリングの管理」、「Amazon Aurora MySQL パフォーマンスの拡張」、「Amazon Aurora PostgreSQL のパフォーマンスとスケーリング」および「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。追加のチューニングを行う場合は、PoC (概念実証) 中に収集したメトリクスをよく理解していることを確認してください。次のステップとして、構成設定、データベースエンジン、およびデータベースバージョンの異なるオプションを選択して新しいクラスターを作成できます。または、特定のユースケースのニーズを満たすために特化された種類の Aurora クラスターを作成できます。

例えば、ハイブリッドトランザクション/分析処理 (HTAP) アプリケーション用の Aurora パラレルクエリクラスターを試すことができます。災害対策の目的またはレイテンシーを短縮する目的で、広範な地理的分散が不可欠である場合は、Aurora のグローバルデータベースを試すことができます。ワークロードが断続的である場合や、開発/テストシナリオで Aurora を使用している場合は、Aurora Serverless のクラスターを試すことができます。

本番稼働用クラスターでは、大量の着信接続の処理が必要になる場合もあります。これらの処理の詳細については、AWS ホワイトペーパーのAurora MySQL データベース管理者のハンドブック - 接続管理を参照してください。

概念実証が完了し、ユースケースが Aurora に適していないと判断した場合は、以下に示す他の AWS のサービスを検討します。

• 純粋に分析的なユースケースの場合、OLAP ワークロードにより適した列ストレージ形式や他の機能をワークロードに有効に利用できます。このようなユースケースに対応する AWS サービスには、次のものがあります。

  • Amazon Redshift

  • Amazon EMR

  • Amazon Athena

• 多くのワークロードは、Aurora と上記サービスの 1 つ以上との組み合わせから利点を得られます。これらのサービス間でデータを移動するには、以下を使用できます。

  • AWS Glue

  • AWS DMS

  • Amazon S3 からのインポート (Amazon Aurora ユーザーガイド を参照)

  • Amazon S3 へのエクスポート (Amazon Aurora ユーザーガイド を参照)

  • その他多くの一般的な ETL ツール