Оверинжиниринг на пустом месте. DynamoDB, Kinesis, Spark, бигдата.

Ранее я рассказывал про то как можно бросить стартап в болото, занявшись построением совершенно ненужных архитектур. Сегодня расскажу и еще одном таком безумстве.

У нас была задача — рассылать пользователям напоминания о событиях. Человек приходил на сайт, регистрировался, выбирал временной слот. За день до события нужно было ему присылать письмо-напоминание. Вот такая простая задача. Шёл 2015 год.

Что мы делаем? Ну, база данных у нас DynamoDB. Схему тогда спроектировали таким образом, что нельзя было просто так получить информацию о временных слотах одним запросом. Я уже не помню, почему не сделали нормальную схему но тогда это был не вариант. Так же, по причине которую я не помню, мы не использовали GSI, хотя они были у нас в других таблицах. Решили сделать ход конём — стрим изменений таблицы мы подписали на Kinesis, и сделали процессор, который брал события из стрима, смотрел на таймслот и писал эту информацию в виде json-файла на S3 в папку, соответствующую дате события. Таким образом, по мере создания события у нас на S3 появлялись соответствующие записи. Если пользователь отменял — то запись мы естественно удаляли.

Итак, у нас была Dynamo таблица, стрим с таблицы, Kinesis и S3 с JSON-файлами партицированными (разоложенными) по папочкам.

Оставался один вопрос — как именно теперь доставать нужные файлы и получать собственно емейлы пользователей.

На сцену выходит бигдата! Я взял Spark — ведь он умеет читать JSON и даже делать SQL-запросы поверх него! Я могу просто указать спарку нужный S3 бакет и сказать select name, email from bookings where date = "...." после чего дернуть другой микросервис чтобы тот послал письма. Так и сделал, и самое удивительное, что это заработало! Но была проблема: спарк нужно было запускать каким-то образом по расписанию. AWS тогда еще не изобрел cron, кубернетиса у нас не было, поэтому кто-то нашел скедулер, который запускал джобы на ECS. На вход он принимал JSON дефиниции джобы, можно было указывать крон и по этому крону он запускал контейнеры. Вроде все круто!

Но нашлась одна неприятность. Дело в том, что тогда Spark не так-то просто подружить с S3. Из коробки это не работало, нужно было собирать свой дистрибутив спарка с нужными библиотеками от AWS. Эту ценную информацию я почерпнул из статьи в блоге Grammarly, которую сейчас уже даже не смог нагуглить. В итоге я форкаю спарк, добавляю свои зависимости, делаю на это CI/CD.

Делаю CI/CD на скедулер, на джоб дефинишены, пишу на это всё CFN-шаблоны, разворачиваю это на дев и qa короче как-то оно начинает работать, фух.

На всё про всё я потратил наверное месяц времени? Может меньше, дело было давно, уже не помню.

Сейчас бы я сделал эту задачу за час. Таблица в постгресе и крон-джоба которая пробегается и рассылает что надо.

Вместо этого мы сделали крутой пайплайн из динамо который пишет в кинезис который пишет в s3 который читает спарк который запускается по крону с помощью скала-поделки развернутой на двух машинах. И это я еще не рассказал про микросервисы. Целый сука космолёт вместо одного SQL-запроса! Тогда это казалось очень весёлым и интересным, но щас я ловлю лютый кринж от воспоминаний.

До продакшена это так и не доехало и всю эту систему выбросили через пол-года.

"Бигдата" крутится—лавеха мутится.


Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred