Amazon Aurora を使用して概念実証を作成する

お客様がクラウドに移行するにつれて、アプリケーションを実行する最良のツールを探しています。リレーショナルデータベースを検討するとき、Amazon Aurora はよく選択されます。Amazon Aurora が MySQL および PostgreSQL とワイヤー互換であり、どちらよりも高いスループットを提供できることを考えれば、これは驚くようなことではありません。Aurora は、標準 MySQL データベースのスループットを最大 5 倍、標準 PostgreSQL データベースのスループットを最大 3 倍提供します。

顧客は Aurora を調査しながら、Amazon Aurora がアプリケーションに適しているかどうかを確認するために、一般的に概念実証 (POC) を構築します。以下に、POC を作成する際に考慮する点をいくつか示します。

Amazon Aurora は正しいツールなのか？

データとデータベースについて考えるとき、重要な要素の 1 つはデータの速度です。一方では、データベースへの読み取りと書き込みの両方で、おそらく数千の接続と数十万の同時クエリでデータが非常に速く移動します。この速度では、クエリは通常、一度に比較的少数の行に影響します。さらに、データがこの速度でアクセスされるときは、レコードのようにクエリが一度に複数の列にアクセスするのが一般的です。このアクセスタイプでは、より実用的にデータを行単位で保存および取得することができます。このワークロードタイプの一般的な例は、オンライントランザクション処理 (OLTP) システムです。

一方では、データの速度が遅くなるにつれて、ほんの一握りの接続と並行して実行されている少数のクエリしかない可能性があります。ただし、ここでは、完全なテーブルのスキャンを含め、行の範囲が何倍も大きいことがよくあります。この速度でクエリは、おそらくテーブルの行すべてに集中するよりは、通常、より小さな列のサブセットに集中します。この方法では、より実用的にデータをカラムナ形式で保存します。さらに、遅い速度での書き込みパターンは大きく異なります。ほとんどのデータは、高速では定期的に一括で読み込まれ、より高速ではほぼ一定で個々に書き込まれます。このワークロードタイプの一般的な例は、データウェアハウジングまたはオンライン分析処理 (OLAP) システムです。

Amazon Aurora は、主に高速データを処理するために設計されました。ワークロードに応じて、単一 r4.16xlarge の Aurora クラスターでは、1 秒間で 600,000 を超える SELECT ステートメントを処理できます。このようなクラスターでは、1 秒間で 200,000 を超えるデータ操作言語 (DML) ステートメント (INSERT、UPDATE、DELETE など) を使用することもできます。Aurora は行ストアのデータベースで、大容量、高スループット、高度に並列化された OLTP ワークロードに最適です。

Aurora の優れたもう 1 つのシナリオは、ハイブリッドトランザクション/分析処理 (HTAP) ワークロードの実行です。Aurora は、(Aurora のドキュメントに記載されているとおり) 最大 15 個のレプリカをサポートできます。これらはそれぞれ、ライターから平均 10〜20 ミリ秒以内に実行されます。この機能により、OLTP 操作への影響を最小限に抑えながら、OLTP データをリアルタイムでクエリを実行できます。さらに、Aurora 並列クエリ機能のリリースにより、Aurora クラスター内の潜在的なストレージノード数千個を使用して、計算ノードに送信する前にデータを処理、絞り込み、集計することができます。

相当な低速データの場合、ワークロードは、カラムナストレージ形式およびその他の OLAP ワークロードにより適した機能から利益を得ます。この場合、AWS ポートフォリオには多数のツールが存在します。これらには、Amazon Redshift、Amazon EMR、および Amazon Athena が含まれます。多くのワークロードは、Aurora とこれらのツール 1 つ以上の組み合わせから利益を得ます。また、AWS Glue、AWS Database Migration Service、Amazon S3 へのインポートまたはエクスポート、他に多くの一般的な抽出、変換、読み込み (ETL) ツールを使用して、これらのツール間でデータを移動できます。

達成度を評価する方法

POC の一環として Amazon Aurora を評価するときは、達成度を評価する方法を事前に特定することが重要です。

互換性

これは明白なことだと思われるかもしれませんが、既存のアプリケーションに存在するすべての機能が Aurora と互換性があるか確認することは重要です。Aurora は MySQL 5.6 および MySQL 5.7、そして PostgreSQL 9.6 および PostgreSQL 10.4 ともワイヤー互換できます。これらのエンジンと互換性があるほとんどのアプリケーションは、Amazon Aurora とも互換性があります。ただし、各アプリケーションの互換性を検証することは重要です。

前提条件

基本的な機能の互換性が確立されたら、実際にアプリケーションが実行される条件をレプリケートすることが重要です。たとえば、一般的に個人ユーザーのノート PC から VPN 接続を介して AWS に至るまで、テスト対象のアプリケーションが実行される可能性は低いです。アプリケーションは同じ AWS リージョンおよびおそらく同じ VPC の Amazon EC2 インスタンスで実行される傾向が強いです。つまり、POC も同じ AWS リージョンと VPC の EC2 インスタンスから実行することが重要です。実稼働アプリケーションが、複数のアベイラビリティーゾーンにわたって複数の EC2 インスタンスで実行される場合もあります。その場合、POC アーキテクチャにも反映させる必要があります。

ワークロード

環境が適切に構成されたら、次にワークロード自体を検討する必要があります。稼働中に予想されるワークロードの正確なレプリカを常に実行することはできませんが、POC で使用されるワークロードは、少なくとも稼働中に予想される重要な側面を反映する必要があります。たとえば、実際のワークロードが HTAP ワークロードであるとします。この場合、OLTP の実行は、起動時に予想される分析クエリを考慮していないため、不十分になります。

達成度の評価

環境と実際のワークロードに稼働が反映されるようになったため、次の手順はアプリケーションのパフォーマンスを測定することです。特定のアーキテクチャにおける Aurora の役割は、データを保存、変更、および取得することです。したがって、達成度を評価する重要な評価基準は、これらの能力を反映します。次の 2 つの質問に答える必要があります。

Aurora が 1 秒間に処理するクエリ数はいくらですか？
- 1 秒あたりの読み取り数
- 1 秒あたりの書き込み数
Aurora が特定のクエリを処理するのに、平均どのくらいの時間がかかりますか？
- 読み取りレイテンシー
- 書き込みレイテンシー

これを判断する最も簡単な方法は、次の図に示すように、特定の Aurora クラスターで Amazon RDS コンソールを調べることです。

これらの特定のメトリックは、クエリを読み取り (SELECT) と書き込み (DML 文) に分類します。そして、「1 秒間のクエリ数はいくらですか？」と「クエリを実行するのに、どのくらいの時間がかかりますか？」という質問に答えます。特定のワークロードでは、システムのトランザクションスループットを評価するために、コミットスループットとコミットレイテンシー、両方のメトリックが役に立つことがあります。

これらの各メトリックに必要な特定値はアプリケーションごとに異なるため、メトリックの初期値を確立することが重要です。これらの初期数値は、アプリケーションが今日ホストされている場所に基づいて、すでに存在している可能性があります。初期値が存在しない場合は、稼働中に予想されるワークロードを実行すると、良い開始点になります。たとえば、同じユーザー数でワークロードを実行するとします。

サイジング

リソースのオーバープロビジョニングを行わずにアプリケーションでピーク時のパフォーマンスを確保するには、Aurora クラスターでインスタンスの適切なサイズを決定することが重要です。良い開始点は、今日の稼働中にアプリケーションが実行されているのと同様の CPU およびメモリ容量を持つインスタンスサイズを選択することです。そのインスタンスサイズでワークロードのスループットとレイテンシーの数値を収集したら、インスタンスを次に大きいサイズにスケールアップすることをお勧めします。このサイズで、スループットとレイテンシーの数値が向上するかどうかを確認します。さらに、スケールダウンして、レイテンシーとスループットの数値が同じままなのかを確認します。もちろん、目標は、可能な限り最低限のインスタンスと最低限のレイテンシーで最大のスループットを得ることです。

パラメータ:

オンプレミス環境を使用する多くのお客様は、パフォーマンスを向上させるためにデフォルトの MySQL または PostgreSQL パラメーターを変更します。Amazon Aurora は MySQL および PostgreSQL とワイヤー互換性がありますが、独自の Aurora ストレージアーキテクチャを使用するため、多くのパラメーターが適用されなくなりました。さらに、他のパラメーターは、標準 MySQL または PostgreSQL で予想されるものとは異なる影響を与える可能性があります。そのため、デフォルト設定から始めることをお勧めします。次に、調整が必要な特定の問題が見つかった場合は、その時点でパラメーターを変更します。

結論

POC プロセスのこの時点で、OLTP または HTAP で予想されるワークロードに基づいて、Aurora が正しいツールであるかどうかを判断できます。適切な POC 設計に関する基本、そして最も重要なパフォーマンスの観点から達成度を決める方法を定義しました。

Aurora についてさらに詳しく知りたい場合は、AWS データベースブログで Aurora の最新ブログ記事を読むことができます。フィードバックを提供したり、質問をしたり、機能強化をリクエストしたりすることをご希望の方は、メールでご連絡ください。

著者について

Steve Abraham はアマゾンウェブサービスのプリンシパルソリューションアーキテクトです。 AWS の顧客と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。

Amazon Web Services ブログ