392-AWS SAP AWS 「理論・実践・一問道場」データベースのメモリエラー

type

status

date

slug

summary

理論

1. API Gatewayとキャッシュ

API Gatewayは、REST APIを管理するためのサービスで、クライアントからのリクエストをLambda関数やバックエンドサービスにルーティングします。API Gatewayには、エッジ最適化エンドポイントやリージョナルエンドポイントがあり、これらは主にレイテンシーやスケーラビリティの最適化に使用されます。

キャッシュの有効化は、同じデータを繰り返し取得する場合に効果的です。API Gatewayのキャッシュ機能を使用すると、データベースの呼び出し頻度を減らし、レイテンシーを改善できます。

2. データベースのスケーラビリティとパフォーマンス

Amazon Aurora Serverlessは、需要に応じてスケーラブルにリソースを調整できるデータベースですが、頻繁なクエリが発生する環境では、スケールアップだけでは十分な効果が得られない場合があります。

読み取り専用レプリカや、クエリキャッシュを使用することで、データベースの読み取り負荷を分散し、パフォーマンスを向上させることができます。

3. ElastiCacheの利用

Amazon ElastiCacheは、メモリ内キャッシュサービスで、RedisやMemcachedをサポートしています。頻繁にアクセスされるデータをキャッシュすることで、データベースへの負荷を軽減し、レスポンス時間を短縮できます。

Redisは、高速でスケーラブルなインメモリデータストアであり、リアルタイムアプリケーションに最適です。Lambda関数でElastiCacheを使用することで、データベースの呼び出しを最小化し、キャッシュからデータを取得することが可能になります。

4. APIのトラフィック管理

スロットリング（API Gatewayのレート制限）は、リクエスト数を制限してシステムの過負荷を防ぐ手法ですが、リクエストの効率性を改善するためにはキャッシュを利用した方が効果的です。

トラフィックのピーク時にスロットリングを行うこともできますが、根本的な問題はデータベースのリクエスト数であり、スロットリングだけでは問題解決にはなりません。

結論

データベースのパフォーマンス向上には、キャッシュの利用が最も効果的です。ElastiCacheを用いて繰り返し実行されるクエリ結果をキャッシュし、データベースへのアクセスを削減することで、アプリケーションの効率を大幅に改善できます。また、API Gatewayやスロットリングはパフォーマンス改善には役立つが、キャッシュの使用が最も効率的です。

データベースのメモリエラーとは、データベースが要求された処理を実行するために十分なメモリを確保できず、処理が失敗する現象です。これにより、データベースが遅延したり、応答できなくなったりすることがあります。

実践

略

一問道場

質問 #392

あるレンタカー会社が、モバイルアプリにデータを提供するためにサーバーレスのREST APIを構築しました。このアプリは、以下で構成されています：

Amazon API Gateway API（リージョナルエンドポイント）

AWS Lambda関数

Amazon Aurora MySQL Serverless DBクラスター

最近、このAPIをパートナー企業のモバイルアプリに公開した結果、リクエスト数が大幅に増加し、断続的にデータベースのメモリエラーが発生するようになりました。

APIトラフィックの分析によると、クライアントが短期間に同じクエリに対して複数回のHTTP GETリクエストを送信していることがわかりました。トラフィックは営業時間中に集中し、特に休日やイベント時にピークを迎えます。

会社は追加の使用量をサポートする能力を向上させる必要がありますが、ソリューションに伴うコストの増加を最小限に抑えたいと考えています。

この要件を満たす戦略はどれですか？

選択肢

A. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変換し、プロダクションステージでキャッシュを有効化する。

B. Amazon ElastiCache for Redisを実装して、データベース呼び出しの結果をキャッシュに保存する。Lambda関数を修正してキャッシュを使用するようにする。

C. Aurora Serverless DBクラスターの構成を変更して、利用可能なメモリの最大値を増やす。

D. API Gatewayのプロダクションステージでスロットリングを有効にし、レートとバースト値を設定してリクエスト数を制限する。

解説

この問題では、サーバーレスREST APIのパフォーマンスとスケーラビリティを改善し、コストの増加を最小限に抑えつつ、増加したトラフィックを処理する方法を求めています。ここで重要なのは、データベースへの負荷を軽減し、リクエストの効率を向上させることです。以下は、選択肢の解説です。

A. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変換し、プロダクションステージでキャッシュを有効化する。

エッジ最適化エンドポイントは、ユーザーがどこからアクセスしても低遅延でAPIを提供するためにCloudFrontを利用するものです。しかし、キャッシュ機能を有効にすること自体はリクエストの負荷軽減に寄与しますが、このケースでは主にデータベースの負荷を軽減する必要があります。そのため、API Gatewayのエンドポイント変更とキャッシュ機能の設定は、データベースの負荷軽減にはあまり効果的ではありません。

不適切な選択肢です。

B. Amazon ElastiCache for Redisを実装して、データベース呼び出しの結果をキャッシュに保存する。Lambda関数を修正してキャッシュを使用するようにする。

Amazon ElastiCache for Redisは、高速なインメモリデータストアであり、データベースの結果をキャッシュして繰り返しのリクエストに対応することで、データベースの負荷を軽減します。この戦略は、同じクエリに対する繰り返しリクエストが多いため、非常に効果的です。Lambda関数がElastiCacheを利用して結果を取得できるようにすることで、データベースの呼び出し頻度を減らし、パフォーマンスを向上させることができます。

適切な選択肢です。

C. Aurora Serverless DBクラスターの構成を変更して、利用可能なメモリの最大値を増やす。

Aurora Serverlessはスケーラブルなデータベースサービスですが、メモリの増加だけではこの問題に対処するには不十分です。メモリ不足が原因ではなく、同じクエリへの頻繁なアクセスが問題であるため、メモリの増加では根本的な解決になりません。データベースの性能改善には、キャッシュの利用がより効果的です。

不適切な選択肢です。

D. API Gatewayのプロダクションステージでスロットリングを有効にし、レートとバースト値を設定してリクエスト数を制限する。

スロットリングはリクエストの量を制限する手段であり、トラフィックの過負荷を防ぐことはできますが、根本的な問題（同じクエリが繰り返し実行されること）には対処できません。スロットリングはトラフィックを制限する方法であって、キャッシュによる効率的なデータ処理とは異なります。

不適切な選択肢です。

結論

データベースへの呼び出しを効率化し、リソースの無駄を減らすためには、結果をキャッシュすることが最も効果的です。したがって、B. ElastiCache for Redisを利用するのが最も適切な選択肢です。

以下は、選択肢AとBの簡潔な比較です：

要素	A: API Gateway キャッシュ	B: Amazon ElastiCache for Redis
目的	APIレスポンスのキャッシュ	データベースクエリ結果のキャッシュ
効果	APIレスポンスを高速化	データベースの負荷を軽減
コスト	比較的低い	追加コストがかかる
データベースの負荷軽減	限定的	効果的に軽減
スケーラビリティ	限界あり	高いスケーラビリティ

結論：

AはAPIレスポンスの高速化に有効。

Bはデータベース負荷の軽減に有効。