Aurora Serverless v2 を使用する - Amazon Aurora
Aurora Serverless v2 ユースケースAurora Serverless v2 の利点

Aurora Serverless v2 を使用する

Aurora Serverless v2 は、Amazon Aurora 用のオンデマンドのオートスケーリング設定です。Aurora Serverless v2 によって、ワークロードをモニタリングし、データベースの容量を調整するプロセスを自動化しやすくなります。容量は、アプリケーションの需要に応じて自動的に調整されます。DB クラスターが消費するリソースに対してのみ課金されます。このように、Aurora Serverless v2 によって予算内に収め、使用しないコンピュータリソースに対して料金を支払うことを避けるのに役立ちます。

この種の自動化は、マルチテナントデータベース、分散型データベース、開発、テストシステムなど、さらにワークロードが大きく変動し、予測不可能な環境において特に有効です。

トピック

Aurora Serverless v2 ユースケース

Aurora Serverless v2 は、多くのタイプのデータベースワークロードをサポートしています。その対象は、開発環境やテスト環境から、予測不可能なワークロードのあるウェブサイトやアプリケーション、高い拡張性と可用性を必要とする最も要求の厳しいビジネスクリティカルなアプリケーションまで多岐にわたります。

Aurora Serverless v2 は、以下のユースケースに特に役立ちます。

  • 変動するワークロード - 突然で予測不可能なアクティビティの増加が発生するようなワークロードを実行している場合。雨が降り出したときにアクティビティが急増 (サージ) するトラフィックサイトなどが該当します。別のケースとして、販売や特別なプロモーションを行うことで、トラフィックが増加する e コマースサイトがあります。Aurora Serverless v2 では、アプリケーションのピーク時に必要なロードに合わせて、データベースの容量がオートスケーリングされ、アクティビティのサージが終了した時点でスケールダウンして元に戻ります。Aurora Serverless v2 を導入することで、ピーク容量や平均容量に合わせてプロビジョニングする必要はなくなります。最悪の状況に対応するために容量の上限を指定でき、その容量は必要な場合以外使用されません。

    Aurora Serverless v2 のスケーリングの詳細度は、データベースのニーズに合わせて容量を細かく調整しやすくします。プロビジョン済みクラスターの場合、スケールアップには、完全に新しい DB インスタンスを追加する必要があります。Aurora Serverless v1 クラスターの場合、スケールアップするには、クラスターの Aurora 容量単位 (ACU) の数を 16 から 32、32 から 64 のように 2 倍にする必要があります。一方、Aurora Serverless v2 では、あと少しだけ容量が必要な場合、ACU を半分追加できます。ワークロードの増加に対応するために追加が必要な容量によって、0.5、1、1.5、2、または半分の ACU を追加できます。また、ワークロードが減少し、その容量が不要になった場合、0.5、1、1.5、2、または追加した半分の ACU を削除できます。

  • マルチテナントアプリケーション - Aurora Serverless v2 を使用することで、フリート内のアプリケーションごとのデータベース容量を、ユーザーが個別に管理する必要はなくなります。個々のデータベース容量は、Aurora Serverless v2 により自動的に管理されます。

    テナントごとにクラスターを作成できます。これにより、クローン、スナップショットリストア、Aurora グローバルデータベースなどの機能を使用して、テナントごとに高可用性と災害対策を強化できます。

    各テナントには、時間帯、時期、プロモーションイベントなどに応じて、繁忙期と休止期間が設定される場合があります。各クラスターには、広い範囲で容量を指定できます。これにより、アクティビティの少ないクラスターでは DB インスタンスの料金を最小限に抑えることができます。どのクラスターでも、アクティビティの高い期間に対応できるように迅速にスケールアップできます。

  • 新しいアプリケーション - 現在デプロイ中で、必要な DB インスタンスサイズが明確でない、新しいアプリケーション。Aurora Serverless v2 を使用して、1 つまたは複数の DB インスタンスでクラスターを設定し、アプリケーションの容量の要件に応じてデータベースをオートスケーリングできます。

  • 複合用途のアプリケーション – オンライントランザクション処理 (OLTP) アプリケーションを使用しているが、クエリトラフィックが定期的に急増することがある場合。クラスター内の Aurora Serverless v2 DB インスタンスに昇格階層を指定することで、リーダー DB インスタンスがライター DB インスタンスと独立してスケーリングして、追加のロードを処理できるようにクラスターを構成できます。使用率の急増が収まったら、リーダー DB インスタンスによってライター DB インスタンスの容量に合わせてスケールダウンします。

  • 容量計画 – 通常、クラスター内のすべての DB インスタンスの DB インスタンスクラスを変更して、データベース容量を調整するか、ワークロードに最適なデータベース容量を検証します。Aurora Serverless v2 では、この管理オーバーヘッドを回避できます。ワークロードを実行し、DB インスタンスが実際にスケールする量をチェックすることで、適切な最小容量と最大容量を決定できます。

    既存の DB インスタンスを、プロビジョン済みから Aurora Serverless v2 に、または Aurora Serverless v2 からプロビジョン済みに変更できます。このような場合、新しいクラスターや新しい DB インスタンスを作成する必要はありません。

    Aurora グローバルデータベースでは、セカンダリクラスターには、プライマリクラスターと同程度の容量は必要ない場合があります。Aurora Serverless v2 セカンダリクラスター内の DB インスタンスを使用できます。これにより、セカンダリリージョンが昇格してアプリケーションのワークロードを引き継いだ場合に、クラスターの容量をスケールアップできます。

  • 開発とテスト — 最も要求の厳しいアプリケーションの実行に加えて、開発環境やテスト環境にも Aurora Serverless v2 を使用できます。Aurora Serverless v2 により、バースト db.t* DB インスタンスクラスを使用する代わりに、最小容量が小さい DB インスタンスを作成できます。最大容量を大きく設定することで、これらの DB インスタンスのメモリが不足せず、大量のワークロードを実行できます。データベースが使用されていない場合は、すべての DB インスタンスがスケールダウンすることで、不要な料金が発生しないようにします。

    ヒント

    環境やテスト環境で Aurora Serverless v2 を便利に使用できるように、AWS Management Console では、新しいクラスターを作成する場合に Easy create ショートカットを提供しています。開発/テストオプションを選択した場合、Aurora では Aurora Serverless v2 DB インスタンスと、開発およびテストシステム向けに一般的な容量範囲のクラスターを作成します。

既存のプロビジョニング済みワークロードに Aurora Serverless v2 を使用

プロビジョン済みクラスターで既に Aurora アプリケーションが実行されているとします。リーダー DB インスタンスとして、1 つまたは複数の Aurora Serverless v2 DB インスタンスを追加することにより、Aurora Serverless v2 によってアプリケーションがどのように動作するか確認できます。リーダー DB インスタンスのスケールアップとスケールダウンの頻度を確認できます。Aurora フェイルオーバーメカニズムを使用して、Aurora Serverless v2 DB インスタンスをライターに昇格させ、読み取り/書き込みワークロードの処理方法を確認できます。これにより、クライアントアプリケーションが使用するエンドポイントを変更することなく、最小限のダウンタイムで切り替えが可能です。既存のクラスターを Aurora Serverless v2 に変換する手順の詳細については、「Aurora Serverless v2 への移行」を参照してください。

Aurora Serverless v2 の利点

Aurora Serverless v2 は、可変または「スパイキー」ワークロードを対象としています。このような予測不可能なワークロードでは、データベース容量を変更するタイミングを計画するのが難しい場合があります。また、容量を迅速に変更するために、DB インスタンスの追加や DB インスタンスクラスの変更など、使い慣れたメカニズムでは十分ではない場合があります。Aurora Serverless v2 には、このようなユースケースに役立つ以下のような利点があります。

  • プロビジョニングよりも簡単な容量管理 – Aurora Serverless v2ワークロードの変化に応じて DB インスタンスのサイズを計画したり、DB インスタンスのサイズを変更したりするための労力を削減します。また、クラスター内のすべての DB インスタンスの容量を一定に維持するための労力が削減されます。

  • 高アクティビティ時のスケーリングを高速かつ簡単に実行 – Aurora Serverless v2クライアントトランザクションやワークロード全体を中断することなく、必要に応じてコンピューティング性能とメモリ容量をスケーリングします。Aurora Serverless v2 でリーダー DB インスタンスを使用できることで、垂直方向のスケーリングに加え、水平方向のスケーリングも利用できます。Aurora グローバルデータベースを使用できるということは、Aurora Serverless v2 の読み取りワークロードを複数の AWS リージョン に分散できるということです。この機能は、プロビジョン済みクラスターのスケーリングメカニズムよりも便利です。また、Aurora Serverless v1 のスケーリング機能よりも高速で、詳細になっています。

  • アクティビティの少ない期間の費用対効果が高い – Aurora Serverless v2 DB インスタンスのオーバープロビジョニングを回避するのに役立ちます。Aurora Serverless v2 DB インスタンスのスケールアップ時に、リソースをきめ細かい単位で追加します。消費したデータベースリソースのみ料金をお支払いいただきます。Aurora Serverless v2 リソースの使用量は、秒単位で計測します。これにより、DB インスタンスがスケールダウンすると、削減されたリソース使用量がすぐに登録されます。

  • プロビジョニングと同等以上の機能 — Aurora Serverless v2 で Aurora の多くの機能を使用できます。なお、Aurora Serverless v1 では利用できません。例えば、Aurora Serverless v2 と指定すると、リーダー DB インスタンス、グローバルデータベース、AWS Identity and Access Management(IAM) データベース認証、パフォーマンスインサイトが使用できます。また、Aurora Serverless v1 の場合よりも多くの設定パラメータを使用することもできます。

    特に Aurora Serverless v2 では、プロビジョン済みクラスターによって、以下機能を活用できます。

    • リーダー DB インスタンス – Aurora Serverless v2 では、リーダー DB インスタンスを活用して水平方向にスケーリングできます。クラスターに 1 つまたは複数のリーダー DB インスタンスが含まれている場合、ライター DB インスタンスに問題が発生した場合に、クラスターはすぐにフェイルオーバーできます。これは、Aurora Serverless v1 では使用できない機能です。

    • マルチ AZ クラスター — クラスターの Aurora Serverless v2 DB インスタンスは、複数のアベイラビリティーゾーン (AZ) に分散できます。マルチ AZ クラスターを設定することで、AZ 全体に影響する問題が発生するようなまれなケースでも、ビジネスの継続性を確保できます。これは、Aurora Serverless v1 では使用できない機能です。

    • グローバルデータベース — Aurora Serverless v2 を Aurora グローバルデータベースと組み合わせて使用することで、災害対策用として他の AWS リージョン にクラスターの読み取り専用のコピーを追加で作成できます。

    • RDS Proxy – Amazon RDS Proxy を使用すると、アプリケーションでデータベース接続をプールおよび共有して、アプリケーションのスケーリング能力を向上させることができます。

  • Aurora Serverless v1 より高速、詳細で、中断が少ないスケーリング – Aurora Serverless v2 によって、より速くスケールアップ、スケールダウンできます。スケーリングでは、ACU の数を 2 倍または半分にする代わりに、0.5 ACU という少ない単位で容量を変更できます。スケーリングは通常、処理を一度も中断することなく行われます。スケーリングでは、Aurora Serverless v1 のように注意しなければならないイベントは発生しません。クワイエットポイントを待つ必要はなく、SQL ステートメントの実行中やトランザクションが開いている間にスケーリングを行うことができます。