Aurora serverless の仕組み

以下の概要では、Aurora serverless の仕組みについて説明します。

Aurora serverless の概要

Amazon Aurora serverless は、最も変化が激しく、要求の厳しいワークロードに適しています。用途の例としては、データベースの使用負荷が短時間の間だけ増大し、その後に軽いアクティビティが長時間続くか、またはアクティビティがまったく発生しなくなるケースが挙げられます。例えば、定期的に販売促進イベントを行う小売り、ゲーム、スポーツなどのウェブサイト、必要なときにレポートを作成するレポートデータベースなどがあります。また、開発やテスト環境、また、新しいアプリケーションでは急激に利用が増加することがあります。他にも多くが考えられますが、このようなケースに対してプロビジョニングされたモデルを使用しても、事前に容量を正しく指定できるとは限りません。また、過剰なプロビジョニングを行い、使用しない容量が生じた場合には、コストが高くなる可能性もあります。

一方で、プロビジョン済み Aurora クラスターは、安定したワークロードに適しています。プロビジョン済みクラスターでは、メモリサイズ、CPU パワー、I/O 帯域幅などが事前定義された DB インスタンスクラスを選択します。ワークロードが変更された場合、ライターとリーダーのインスタンスクラスを手動で変更します。プロビジョン済みモデルは、消費パターンが予想され、事前に容量を調整できる場合に有効です。クラスター内のライターとリーダーのインスタンスクラスを変更しながら、短時間の停止の発生が許容される場合は有効に機能します。

Aurora serverless は、すぐにスケーリング可能なサーバーレス DB クラスターをサポートするためにゼロから設計されています。また、Aurora serverless は、プロビジョン済みライターやリーダーと同レベルのセキュリティと分離を提供するように設計されています。このような側面は、マルチテナントのサーバーレスクラウド環境では非常に重要です。データベースのワークロードの変更に迅速に対応できるように、動的スケーリングメカニズムにはオーバーヘッドがほとんどありません。また、処理需要の劇的な増加に対応するための、十分な能力も備わっています。

Aurora serverless を使用することにより、各ライターとリーダーにある特定のデータベース容量の制約を受けずに Aurora DB クラスターを作成できます。お客様は、最小容量と最大容量の範囲を指定します。Aurora では、その容量範囲内のクラスター内の各 Aurora serverless ライターまたはリーダーをスケーリングします。各ライターまたはリーダーによって動的にスケーリングできるマルチ AZ クラスターを使用することで、動的スケーリングと高可用性を活用できます。

Aurora serverless では、最小容量と最大容量の仕様に基づいて、データベースリソースを自動的にスケーリングします。ほとんどのスケーリングイベントのオペレーションは、ライターまたはリーダーが同じホスト上で保持されるため、高速にスケーリングします。Aurora serverless ライターまたはリーダーが、あるホストから別のホストに移動するまれなケースでも、Aurora serverless では自動的に接続を管理します。データベースクライアントアプリケーションのコードやデータベースの接続文字列を変更する必要はありません。

Aurora serverless では、プロビジョン済みクラスターと同様に、ストレージ容量とコンピューティング性能は別々になっています。Aurora serverless 容量やスケーリングに言及した場合、増減するのは常にコンピューティング性能です。したがって、CPU やメモリの容量がスケールダウンしても、クラスターには数テラバイトのデータを格納できます。

プロビジョニングやデータベースサーバーを管理する代わりに、データベース容量を指定します。Aurora serverless の容量についての詳細は、「Aurora serverless の容量」を参照してください。各 Aurora serverless ライターまたはリーダーの実際の容量は、ワークロードによって時間とともに変化します。このメカニズムの詳細については、「Aurora serverless でのスケーリング」を参照してください。

Aurora DB クラスターの設定

Aurora DB クラスターごとに、Aurora serverless の容量およびプロビジョン済み容量、またはその両方を自由に組み合わせて選択できます。

混在設定クラスターと呼ばれる Aurora serverless とプロビジョン済み容量の両方を含むクラスターを設定できます。例えば、Aurora serverless ライターで利用可能な容量よりも、多くの読み取り/書き込み容量が必要だとします。この場合、非常に大きいプロビジョン済みライターを使用してクラスターをセットアップできます。その場合でも、引き続き Aurora serverless リーダーを使用できます。また、クラスターの書き込みワークロードは変化しているが、読み取りワークロードは安定しているとします。この場合、クラスターに 1 つの Aurora serverless ライターと 1 つまたは複数のプロビジョン済みリーダーをセットアップできます。

Aurora serverless によってすべての容量が管理される DB クラスターをセットアップすることもできます。これを行うには、新しいクラスターを作成し、最初から Aurora serverless を使用します。または、Aurora serverless で既存のクラスター内でプロビジョン済みのすべての容量を置き換えることができます。例えば、古いバージョンのエンジンからのアップグレードパスには、プロビジョン済みライターで開始して、Aurora serverless ライターで置き換えが必要なものもあります。Aurora serverless で新しい DB クラスターを作成するか、または既存の DB クラスターを Aurora serverless に切り替える手順の詳細については、「Aurora serverless DB クラスターの作成」および「プロビジョン済みライターまたはリーダーを Aurora serverless に変換する」を参照してください。

DB クラスターで Aurora serverless をまったく使用しない場合、DB クラスター内のすべてのライターとリーダーはプロビジョン済みになります。これは、ほとんどのユーザーがよく知っている、最も古く、最も一般的な種類の DB クラスターです。実際に、Aurora Serverless の前には、このような種類の Aurora DB クラスターには特別な名前はありませんでした。プロビジョン済み容量は一定です。料金は比較的簡単に予測できます。ただし、必要な容量を事前に予測する必要があります。場合によっては、予測が不正確だったり、容量のニーズが変わったりすることもあります。このような場合、DB クラスターがプロビジョニングされない (希望よりも遅い)、またはオーバープロビジョニング (必要以上に高価) になる可能性があります。

Aurora serverless の容量

Aurora serverless の単位は Aurora 容量単位 (ACU).です。Aurora serverless の容量は、プロビジョン済みクラスターに使用する DB インスタンスクラスと関連性はありません。

各 ACU では、約 2 ギビバイト (GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。この測定単位を使用して、データベース容量範囲 (最小と最大) を指定します。Aurora serverless は、0 ACU から 256 ACU までの容量を提供します。最小容量が 0 ACU の場合、ワークロードが実行されていないときは、クラスターは 0 にスケールされます。ServerlessDatabaseCapacity および ACUUtilization メトリクスは、データベースが実際に使用している容量と、その容量が指定された範囲内のどこに位置するかを判断するのに役立ちます。

いつどんな場合でも、各 Aurora serverless DB ライターまたはリーダーは容量を持っています。容量は、ACU を示す浮動小数点数で表されます。容量は、ライターまたはリーダーがスケーリングするごとに増減します。この値は毎秒測定されます。Aurora serverless を使用する予定の各 DB クラスターに、各 Aurora serverless ライターまたはリーダーの間でスケーリングできる最小容量および最大容量の値である容量範囲を定義します。各 Aurora serverlessDB クラスターのライターまたはリーダーでは、容量範囲は同じです。Aurora serverless ライターまたはリーダーは、それぞれの範囲内の容量を持っています。

次の表は、Aurora MySQL および Aurora PostgreSQL でサポートされている Aurora serverless の容量範囲とエンジンバージョンを示しています。

Aurora serverless のプラットフォームバージョンは、パフォーマンス、スケーリング機能、または機能の改善を表します。Amazon Aurora は、クラスターレベルでプラットフォームバージョンの割り当てを自動的に管理します。すべての新しいクラスター、データベースの復元、および新しいクローンは、AWS リージョンで利用可能な最新のプラットフォームバージョンで起動します。新しいプラットフォームバージョンが利用可能になると、クラスターを停止して再起動するか、ブルー/グリーンデプロイを使用して、以前のプラットフォームバージョンの既存のクラスターを最新のプラットフォームバージョンに直接アップグレードできます。Amazon Aurora は、最新の改善点をすべて活用できるように、最新のプラットフォームバージョンにアップグレードすることをお勧めします。

次の表は、Aurora serverless プラットフォームバージョン別の ACU 範囲とパフォーマンス特性を示しています。

プラットフォームバージョン 1、2、および 3 は、Aurora serverless がサポートされているすべてのリージョンで利用できます。プラットフォームバージョン 4 は、次のリージョンで利用できます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (マレーシア)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、南米 (サンパウロ)、AWS GovCloud (米国東部)、AWS GovCloud (米国西部)。

どのプラットフォームバージョンでクラスターが実行されているかは、AWS マネジメントコンソールの [インスタンス設定] セクションで確認できます。または DBCluster の ServerlessV2PlatformVersion を表示することで API 経由で確認できます。

自動一時停止機能をサポートする Aurora serverless バージョンでは、定義可能な Aurora serverless の最小容量は 0 ACU です。最大容量値以下であれば、それ以上の数値を指定できます。最小容量を小さい量に設定することで、低ロードの DB クラスターでは最小限のコンピューティングリソースを消費できます。同時に、直ちに接続を受け入れ、ビジーになったらスケールアップする準備ができています。

各 DB ライターまたはリーダーがバッファプール内のアプリケーションのワーキングセットを保持できる最小値に設定することをお勧めします。これにより、アイドル中にバッファプールの内容が破棄されることはありません。最小容量値を選択する際のすべての考慮事項については、「クラスターに Aurora serverless の最小容量設定を選択する」を参照してください。最大容量値を選択する際のすべての考慮事項については、「クラスターに Aurora serverless の最大容量設定を選択する」を参照してください。

マルチ AZ 配置でのリーダーの設定方法に応じて、その容量はライターの容量に関連付けることも、独立させることもできます。これを行う方法については、「Aurora serverless でのスケーリング」を参照してください。

Aurora serverless のモニタリングでは、DB クラスター内のライターとリーダーの容量値を経時的に測定します。データベースが最小容量にスケールダウンしない場合は、最小値の調整やデータベースアプリケーションの最適化などのアクションを実行できます。データベースが常に最大容量に達している場合は、最大容量を増やすなどのアクションを実行できます。また、データベースアプリケーションを最適化し、クエリのロードをより多くのリーダーに分散させることもできます。

Aurora serverless 容量の料金は ACU の時間で測定されます。Aurora serverless 料金の計算方法については、「Aurora 料金のページ」をご覧ください。

クラスター内のライターとリーダーの合計数が n であるとします。この場合、クラスターは、データベースオペレーションを実行していないときにおよそ n x minimum ACUs を消費します。Aurora 自体がモニタリングやメンテナンスオペレーションを行うことで、わずかなロードがかかることがあります。そのクラスターでは、データベースを全容量で実行しても n x maximum ACUs を超える消費はしません。

適切な最小と最大の ACU 値の選択の詳細については、「Aurora クラスターの Aurora serverless での容量範囲の選択」を参照してください。また、指定した ACU の最小値と最大値は、Aurora serverless の 一部の Aurora 設定パラメータ動作方法に影響します。容量範囲と設定パラメータ間のやり取りの詳細については、「Aurora serverless のパラメータグループを使用する」を参照してください。

Aurora serverless でのスケーリング

Aurora では、各 Aurora serverless ライターやリーダーの CPU、メモリ、ネットワークなどのリソースの使用率を継続的に追跡しています。これらの測定値を総称してロードと呼びます。ロードには、アプリケーションによって実行されるデータベースオペレーションが含まれます。また、データベースサーバーと Aurora 管理タスクのバックグラウンド処理も含まれます。これらのいずれかによって容量が制約されると、Aurora serverless がスケールアップします。また、スケールアップすることで解決可能なパフォーマンスの問題を検出した場合、Aurora serverless もスケールアップします。「Aurora serverless の重要な Amazon CloudWatch メトリクス」および「パフォーマンスインサイトで Aurora serverless のパフォーマンスをモニタリングする」の手順で、リソース使用率と Aurora serverless のスケーリングの影響をモニタリングできます。

ロードは、DB クラスターのライターとリーダーによって異なる場合があります。ライターは、CREATE TABLE、ALTER TABLE、DROP TABLE のようなすべてのデータ定義言語 (DDL) ステートメントを処理します。ライターは、INSERT および UPDATE のようなすべてのデータ操作言語 (DML) ステートメントも処理します。リーダーは、SELECT クエリのような読み取り専用ステートメントを処理できます。

スケーリングは、データベースの Aurora serverless 容量を増減するオペレーションです。Aurora serverless には、各ライターとリーダーに ACU で測定された独自の現在の容量値を持っています。Aurora serverless は、現在の容量が小さすぎてロードを処理できない場合に、ライターまたはリーダーをより大きな容量にスケールアップします。ライターまたはリーダーの現在の容量が必要以上に大きい場合、小さい容量にスケールダウンします。

Aurora serverless は容量を段階的に増やすことができます。ワークロードの需要が、ライターやリーダーの現在のデータベース容量に達し始めると、Aurora serverless はそのライターまたはリーダーの ACU の数を増やします。Aurora serverless は、消費されるリソースに対し最適なパフォーマンスを実現するために必要な増分で、容量をスケールアップします。スケーリングは 0.5 ACU という小さい増分で行われます。現在の容量が大きいほど、スケーリングの増分が大きくなり、そのため、スケーリングがより高速になります。

Aurora serverless のスケーリングは高頻度、詳細、無停止であるため、AWS マネジメントコンソールで離散的なイベントが発生することはありません。代わりに、ServerlessDatabaseCapacity や ACUUtilization のような Amazon CloudWatch メトリクスを測定し、その最小値、最大値、平均値を経時的に追跡できます。Aurora メトリクスの詳細については、「Amazon Aurora クラスターでのメトリクスのモニタリング」を参照してください。Aurora serverless のモニタリングに関するヒントについては、「Aurora serverless の重要な Amazon CloudWatch メトリクス」を参照してください。

リーダーを関連付けられたライターの容量に追従させることも、ライターから独立してスケールさせることも選択できます。これを行うには、そのリーダーの昇格階層を指定します。

昇格階層の詳細については、「Aurora serverless リーダーの昇格階層の選択」を参照してください。

Aurora serverless では、データベースの接続中、SQL トランザクション処理中、テーブルロック中、一時テーブルの使用中にスケーリングできます。Aurora serverless は、スケーリングを開始するためにクワイエットポイントを待ちません。スケーリングによって、進行中のデータベースオペレーションが中断されることはありません。

ワークロードで単一のライターと単一のリーダーで使用できるよりも多くの読み取り容量が必要な場合、クラスターに 複数の Aurora serverless リーダーを追加できます。各 Aurora serverless リーダーは、DB クラスターに指定した最小から最大の容量値でスケーリングできます。クラスターのリーダーエンドポイントを使用して、読み取り専用のセッションをリーダーに送信し、ライターのロードを軽減できます。

Aurora serverless がスケーリングを実行するどうか、また、スケーリング開始後の速度は、クラスターの最小および最大 ACU 設定によって異なります。さらに、リーダーとライターが一緒にスケーリングするように設定されているか、ライターとは独立してスケーリングするように設定されているかによって異なります。Aurora serverless のスケーリング影響を受ける要因の詳細については、「Aurora serverless でのパフォーマンスとスケーリング」を参照してください。

ゼロへのスケーリング

Aurora MySQL および Aurora PostgreSQL の最近のバージョンでは、Aurora serverless ライターとリーダーは 0 ACU までスケールダウンできます。この機能は、自動一時停止と再開、または自動一時停止と呼ばれます。最小容量に 0 または 0 以外の値を指定することで、この動作を許可するかどうかを選択できます。Aurora serverless インスタンスが一時停止するまでの待機時間を選択することもできます。この機能を持つバージョンについての詳細は、「Aurora serverless の容量」を参照してください。この機能を効果的に使用する方法については、「Aurora serverless の自動一時停止と再開によるゼロ ACU へのスケーリング」を参照してください。

Aurora MySQL および Aurora PostgreSQL の旧バージョンでは、アイドル状態の Aurora serverless ライターとリーダーはクラスターに指定した最小 ACU 値にスケールダウンできますが、0 ACU までスケールダウンすることはできません。その場合、容量範囲を設定する際に 0 ACU を選択肢として使用できません。

Aurora serverless の容量を持つ DB クラスターがしばらく必要ない場合、プロビジョンド DB クラスターと同様にクラスター全体を停止および開始できます。この手法は、一度に何時間も必要とされず、クラスターの再開速度が重要ではない開発システムとテストシステムに最適です。クラスターの停止/開始機能は、すべての Aurora serverless バージョンで使用できます。その機能の詳細については、「Amazon Aurora DB クラスターの停止と開始」を参照してください。

Aurora serverless と高可用性

Aurora DB クラスターの高可用性を確立する方法として、マルチ AZ DB クラスターにすることがあります。マルチ AZ Aurora DB クラスターは、複数のアベイラビリティーゾーン (AZ) で常に利用可能なコンピューティング性能を持っています。この設定により、大規模な機能停止が発生した場合でも、データベースを稼働し続けます。Aurora は、ライターや AZ 全体に影響を及ぼす問題が発生した場合、自動的にフェイルオーバーを実行します。Aurora serverless では、ライターの容量と、待機しているコンピューティング性能のスケールアップとスケールダウンを選択できます。これにより、2 番目の AZ のコンピューティング性能は、いつでも現在のワークロードを引き継ぐことができます。同時に、データベースがアイドル状態になると、すべての AZ のコンピューティング性能をスケールダウンすることができます。AWS リージョン での Aurora の動作の仕組みとアベイラビリティーゾーンの詳細については、「Aurora DB インスタンスの高可用性」を参照してください。

Aurora serverless マルチ AZ 機能は、ライターに加えてリーダーも使用します。Aurora serverless では、リーダーへのサポートが新たに導入されました。Aurora DB クラスターには、3 つの AZ にわたる最大 15 の Aurora serverless リーダーを追加できます。

クラスター全体または AWS リージョン全体に影響を及ぼす問題が発生した場合でも、可用性を維持する必要があるビジネスクリティカルなアプリケーションには、Aurora グローバルデータベースを設定できます。災害対策の間、Aurora serverless 容量を使用することで、セカンダリクラスターに引き継ぐことができます。また、データベースがビジー状態でないときは、スケールダウンできます。Aurora グローバルデータベースについての詳細は、「Amazon Aurora Global Database の使用」を参照してください。

Aurora serverless は、フェイルオーバーなどの高可用性を実現するためにプロビジョン済みのものと同じように動作します。詳細については、「Amazon Aurora の高可用性」を参照してください。

Aurora serverless クラスターで最大の可用性を確保するとします。ライターに加えてリーダーを作成することもできます。リーダーを昇格階層 0 または 1 に割り当てると、リーダーの最小容量は現在のライター容量 (プロビジョニングされたライターの場合はライターのメモリサイズ) と一致します。そうすれば、フェイルオーバーが発生した場合にも、リーダーがライターを引き継ぐことができます。

クラスターがトランザクションの処理を継続するのと同時に、ビジネスの四半期レポートを実行するとします。Aurora serverless リーダーをクラスターに追加し、2 ～ 15 の昇格階層に割り当てると、そのリーダーに直接接続してレポートを実行できます。レポートクエリのメモリ負荷と CPU の負荷量に応じて、そのリーダーはワークロードに対応できるようにスケールアップできます。レポートが終了すると、再びスケールダウンできます。

Aurora serverless とストレージ

各 Aurora DB クラスターのストレージは、3 つの AZ に分散したすべてのデータの 6 つのコピーで構成されます。この組み込みデータレプリケーションは、DB クラスターにライター以外にリーダーが含まれているかどうかにかかわらず適用されます。そうすれば、クラスターのコンピューティング性能に影響を与える問題からも、データを保護できます。

Aurora serverless ストレージには、「」で説明したものと同じように信頼性と耐久性を有しています。Amazon Aurora ストレージこれは、Aurora DB クラスターのストレージは、コンピューティング性能によって Aurora serverless を使用しても、プロビジョン済みのものを使用しても同じように動作するためです。

Aurora クラスターの設定パラメータ

プロビジョン済み DB クラスターとして、Aurora serverless 容量のクラスターと同じクラスターおよびデータベースの設定パラメータをすべて調整できます。ただし、容量に関連する一部のパラメータは、Aurora serverless については取り扱いが異なります。混合設定クラスターでは、それらの容量に関連するパラメータに指定したパラメータ値は、プロビジョン済みライターおよびリーダーに引き続き適用されます。

ほとんどすべてのパラメータは、Aurora serverless ライターとリーダーに対して、プロビジョン済みのものと同じように動作します。例外として、Aurora がスケーリング中に自動的に調整する一部のパラメータと、Aurora が最大容量設定に応じて固定値で保持するパラメータがあります。

例えば、バッファキャッシュ用に予約されているメモリ量は、ライターまたはリーダーがスケールアップすると増加し、スケールダウンすると減少します。そうすれば、データベースがビジー状態でないときにメモリを解放できます。逆に、Aurora では、最大容量設定に基づいて、自動的に適切な最大接続数を設定します。そうすれば、ロードが低下して Aurora serverless がスケールダウンしても、アクティブな接続が切断されません。Aurora serverless による特定のパラメータの取り扱いについての詳細は、「Aurora serverless のパラメータグループを使用する」を参照してください。