341-AWS SAP AWS 「理論・実践・一問道場」Aurora Serverless

type

status

date

slug

summary

理論

1. Auroraのスケーラビリティとコスト最適化

Aurora MySQLは、高可用性とパフォーマンスを提供するリレーショナルデータベースサービスですが、トラフィックが不規則で、負荷に応じた自動スケーリングが必要な場合、Aurora Serverlessが最適です。

Aurora Serverlessは、負荷に応じて自動的にスケールアップ・スケールダウンが可能で、通常の使用時間帯には自動的にリソースを拡張し、使用が少ない時間帯には縮小します。これにより、コストが無駄なく最適化されます。

2. Aurora Serverless v1とv2の違い

Aurora Serverless v1は、低負荷または変動する負荷を処理するために設計されています。自動的にスケールイン・スケールアウトしますが、起動時間に若干の遅延があります。

Aurora Serverless v2は、より短期間でのスケーリングを実現し、より継続的なパフォーマンスを提供します。特に変動の激しいワークロードに適しています。

3. AWSのコスト最適化のアプローチ

セービングプランやリザーブドインスタンスは、長期間にわたって予測可能なリソース使用を前提にコスト削減を実現しますが、トラフィックの変動が激しい場合は、使用するインスタンスやリソースの変更に柔軟に対応できるソリューションを選択することが重要です。

4. AWSのスケーラブルなサービス

Amazon ECS + AWS Fargate：コンテナ化されたアプリケーションにおいて、トラフィックの増減に応じて自動的にスケールするFargateは、無駄なリソースを排除し、コスト最適化に寄与します。

AWS Lambda：サーバーレスコンピューティングで、リクエストに応じて処理が実行され、使用した分だけ課金されるため、スケーリングに最適です。

5. AWSのデータベースのスケーリング戦略

書き込みが多く、不規則なトラフィックを持つアプリケーションには、Aurora Serverlessが理想的です。特に、データベースの容量やリソースの使用量を動的に調整できるため、ピーク時の負荷にも柔軟に対応可能です。

これらを理解しておくことで、アプリケーションのスケーリングに最適な選択肢を選び、コストを最適化できます。

実践

略

一問道場

質問 #341

ある企業が、AWSでのアプリケーションのコストを最適化する必要があります。このアプリケーションは、AWS Lambda関数とAmazon Elastic Container Service（Amazon ECS）のコンテナを使用しており、これらはAWS Fargate上で実行されています。アプリケーションは書き込みが多く、データはAmazon Aurora MySQLデータベースに格納されています。アプリケーションの負荷は一定ではなく、長時間使用されない時期があり、その後、トラフィックが急激に増加したり減少したりします。データベースはメモリ最適化されたDBインスタンスで実行されていますが、その負荷に対応できません。

ソリューションアーキテクトは、トラフィックの変動に対応できるスケーラブルなソリューションを設計する必要があります。

どのソリューションが最もコスト効果が高いですか？

A. データベースに追加のリードレプリカを追加する。インスタンスのセービングプランとRDSリザーブドインスタンスを購入する。

B. データベースを、複数の書き込みインスタンスを持つAurora DBクラスターに移行する。インスタンスのセービングプランを購入する。

C. データベースをAuroraグローバルデータベースに移行する。コンピュートセービングプランとRDSリザーブドインスタンスを購入する。

D. データベースをAurora Serverless v1に移行する。コンピュートセービングプランを購入する。

解説

この問題では、アプリケーションの負荷に応じたコスト効果の高いデータベースのスケーリングを求めています。アプリケーションの負荷が不規則であり、トラフィックが急激に増減するため、スケーラブルで費用対効果の高いソリューションが必要です。解説は以下の通りです：

A. データベースに追加のリードレプリカを追加する。インスタンスのセービングプランとRDSリザーブドインスタンスを購入する。

不適切: リードレプリカは読み取り専用で、書き込みが多いアプリケーションには効果的ではありません。また、リザーブドインスタンスは使用量が一定である場合にコスト削減を見込めますが、アプリケーションのトラフィックが不規則である場合には柔軟性が欠けます。

B. データベースを、複数の書き込みインスタンスを持つAurora DBクラスターに移行する。インスタンスのセービングプランを購入する。

不適切: 複数の書き込みインスタンスを持つAurora DBクラスターは高可用性を提供しますが、書き込みが多い場合でもトラフィックの変動に柔軟に対応するには不十分です。インスタンスのセービングプランはコスト削減には有効ですが、トラフィックの急増に対する対応力が限られています。

C. データベースをAuroraグローバルデータベースに移行する。コンピュートセービングプランとRDSリザーブドインスタンスを購入する。

不適切: Auroraグローバルデータベースは複数のリージョンにまたがるデータベースを提供し、災害復旧やグローバルなアクセス向けには有効ですが、トラフィックの急増に対してはスケーリングの柔軟性が不足しており、コスト効果が悪化します。

D. データベースをAurora Serverless v1に移行する。コンピュートセービングプランを購入する。

適切: Aurora Serverlessは、負荷に応じて自動でスケールアップおよびスケールダウンできるため、トラフィックの変動に柔軟に対応できます。特に書き込みが多い場合でも、リソースを必要なときだけプロビジョニングするため、コストを最適化できます。また、コンピュートセービングプランを購入すれば、固定のリソースを予測する場合にコスト削減が期待できます。

結論:

最もコスト効果が高いのはDです。Aurora Serverless v1は、アプリケーションのトラフィックの急激な変動に対応できるスケーラブルなソリューションを提供し、無駄なコストを削減できます。