Какие есть механизмы для ограничения записи согласно потолку IOPS?
====================================================================

 Знакомлюсь с инфраструктурой облачных вычислений AWS и в частности с построением масштабируемых приложений с большой нагрузкой при помощи FaaS.  

На одном из интервью была дана задача разработать архитектуру некоторого сервиса для регистрации метрик, полученных от множества IoT устройств и записи в некоторую БД для последующей аналитики.  

  

Желательно не использовать специализированные сервисы AWS, такие как MSK (Kafka) и других, для работы с IoT, для того чтобы можно было легко мигрировать на другие облачные провайдеры.  

  

Собрал такую схему:  

API Gateway -> Lambda -> SQS -> Lambda -> DB.  

  

В моей схеме одна из проблем это открытие-закрытие соединения к БД. Это можно решить использованием общего connection pool. Правда, не знаю как делается общий pool для всех лямбда-функций.  

  

Другая проблема связана с тем, что чтобы СУБД не рухнула под натиском запросов записи (даже с учетом записи в batch) из-за ограничений IOPS. Поэтому я вижу только что можно как-то пробовать регулировать получение сообщений с очереди SQS.  

  

Есть ли какие-то общепринятые практики для регулировки трафика, получаемого с очередей, чтобы не превышать порог IOPS при записи в СУБД?  

Предположим, я эмпирическим путем определяю , что при 1000 лямбда-функций СУБД выдерживает нагрузку 5к IOPS.  

Использовать в лямбда-функции механизм rate limit, проверяя не превышен ли порог - выйдет дорого из-за потенциального простоя функции. 

 В мире serverless традиционные базы здоровые на голову люди не используют. Берем DynamoDB. Можно ещё почитать про их TimeStream.  

  

RateLimit/Throttling настраивается на самом apigateway.