Какие есть механизмы для ограничения записи согласно потолку 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, проверяя не превышен ли порог - выйдет дорого из-за потенциального простоя функции.
конкретно в этом случае -
шарить коннекшн пул между разными лямбдами нельзя, но вроде (хотя пока писал - возникли сомнения, так что я бы перепроверил) можно шарить существующий коннекшн между последовательными вызовами одной и той-же лямбды. При значительной нагрузке он будет закрыватся/открыватся только в момент пересоздания контейнера с лямбдой (раз минут в 10-15). Но а так - вроде только ограничивать кол-во лямбд между сксом и базой. Хотя если нагрузка стабильная - дешевле будет туда воткнуть ecs/eks контейнеры с лимитом по макс. кол-ву. И хай работают.
ну и в принципе - метрики с базы есть в клаудвотче, можно реально использовать ecs/eks контейнеры со скейлингом который будет учитывать И кол-во сообщений в скс, И метрики с базы. чтоб выгребать с скса максимально быстро, но при этом не убить базу.
Роман Мирр , подскажи, на что в данном выборе инструментов можно будет легко мигрировать, aws lambda и aws sos разве доступны как приложение для установки у себя?
тоже хотел спросить, почему выбор к примеру не пал на in memory nosql базу данных, с каким-нибудь gateway с резервированием?
но топикекастер не сказал ничего про требования к базе данных и запросам к хранимым данным, нужна ли какая то сложная логика и индексы, какой объем данных и т.п.
Не понял при чем тут DynamoDB. Если на то пошла речь, тогда брать что-нибудь типа InfuxDB или других TSDB.
здоровые на голову люди не используют.
А по другому нельзя было написать?
RateLimit/Throttling настраивается на самом apigateway.
Да, я знаю. Но таким образом мы потеряем метрики с устройств. А у нас задача не перегрузить СУБД и не потерять метрики при кратковременном всплеске обращений. А Throttling больше от DoS подходит.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, DynamoDB предоставит практически безлимитную пропускную способность в зависимости от настройки, конечно. Поэтому все эти пляски с бубном на счет "не перегрузить" базу можно будет просто спустить в унитаз. Кроме того, DynamoDB. находится в экосистеме AWS и интегрирован с огромным числом других инструментов. Это типовое решение в AWS Serverless подходе. И других опций у вас просто нет на самом деле.
Иван Шумов, ну, есть различные соображения по использованию AWS, да и не только. Самое важное - контролировать расходы на инфраструктуру. Нельзя просто так доверить AWS масштабировать как ей хочется. Иначе можно обанкротиться.
И, разумеется, нужно быть наименее зависимыми от их услуг.
Пляски с бубном нужны для экономии средств.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, в тот момент когда было произнесено название AWS Lambda - вы получаете полую жесткую зависимость от вендора. Serverless невозможен к легковесному переносу какие бы фреймворки в виде https://www.serverless.com не существовали по причине того что Serverless это одновременно огромная группа сервисов и особенностей инфраструктуры на которой оно работает.
Что до бюджета то необходимо запускать тесты и рассчитывать стоимость решения чтобы не обанкротиться. Ну или хотябы в первом приближении посчитать на калькуляторе, но судя из уровня понимания AWS на данный момент - это непосильная для вас задача. Даже при моем опыте с AWS это может занимать часы и множество перепроверок рассчетов.
Нагрузку же всегда можно просчитать.
Если же вы хотите контроля масштабирования то определитесь зачем оно вам. Если для того чтобы сократить расходы то вы сразу попадете в ловушку по тому что Serverless предполагает что 99.(9)% ресурсов вы не имеете возможности контролировать. В этом весь смысл данной архитектуры. Но за это вы получаете бонус в отсутствии почти полной потребности в расходах в поддержку и безопасность с мониторингом. Оно закладывается в стоимость. Ну и сокращает Time To Market.
Полный контроль над масштабированием требует сегодня навыком контейнеризации, тяжелые обвесы мониторинга и высокую сеньорность команды, что очень сильно влияет на стартовые расходы на проект и отодвигает дату его релиза.
Добро пожаловать в реальный мир без магии в розовых единорогов
Иван Шумов, увы, я рассчитывал на получение ответа насчет
регулировки трафика, получаемого с очередей
А не речей про неограниченные возможности масштабирования.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, а как давать ответ на вопрос, который сам себе противоречит "мы хотим не положить базу, но мы не хотим потерять приходящие метрики". Узкое горлышко в данном вопросе - база и все что не является ее масштабированием в данном вопросе не имеет никакого значения, включая финансовую составляюшщую
А если невозможно контролировать, то лучше было так сразу и написать.
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, это входит в концепции serverless в которой делается решение. Если нет даже такого базового понимания то вы куда вообще полезли? Решение надо считать со всех сторон и иметь достаточную компетенцию.
Я не повар и всей кухни Авс могу не знать, конечно.
А если бы речь шла об абстрактной очереди, то как бы ограничивал темп потребления сообщений?
Написано
Иван Шумов
@inoise Куратор тега Amazon Web Services
Роман Мирр, тут только опция контроллировать потребление сообщений на уровне consumer. Но проблему это не решает по тому что если база выдерживает нагрузки ниже чем скорость поступления новых сообщений то лопнет уже очередь, а не база. Так что сама идея не имеет смысла
Простой
