Компания по прокату автомобилей создала бессерверный REST API, используемый ее мобильным приложением. Стек использует Amazon API Gateway с региональной конечной точкой, AWS Lambda и кластер Amazon Aurora MySQL Serverless DB. После открытия доступа для партнеров объем запросов резко возрос и вызвал периодические ошибки памяти базы данных. Журналы показывают, что многие клиенты отправляют повторяющиеся HTTP GET-запросы для идентичных запросов через короткие промежутки времени. Трафик концентрируется в рабочее время с пиками в праздничные дни. Компания хочет поддерживать возросшую нагрузку, минимизируя рост затрат. Какой подход соответствует этим требованиям?

Правильный ответ — преобразование региональной конечной точки API Gateway в оптимизированную для периферии и включение кэширования на производственной стадии. Это решение наиболее эффективно, поскольку кэширование в API Gateway позволяет обслуживать повторяющиеся GET-запросы из кэша, снижая нагрузку на Lambda и Aurora Serverless. Оптимизированная для периферии конечная точка использует CloudFront для глобального распределения трафика, уменьшая задержки и повышая доступность, что важно при росте трафика. Реализация Amazon ElastiCache for Redis также является хорошим вариантом для кэширования, но API Gateway кэширование проще в реализации и часто достаточна для снижения нагрузки на базу данных при повторяющихся GET-запросах. Увеличение максимальной памяти Aurora Serverless может временно решить проблему, но не устраняет причину повторяющихся запросов и может значительно увеличить затраты. Включение регулирования в API Gateway будет отклонять запросы, что не является желаемым поведением, когда компания хочет поддерживать возросшую нагрузку.