Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

18.08.2022

Дебаг, AWS Kinesis Firehose, sidekiq-unique-jobs

🐛🔍🔥 Сьогодні (та й вчора, та й позавчора) довго дебажив. Дебажив досить складний шлях перетворення даних, що проходить через декілька систем. Добре що це було на стейджингу, і що в нас є хелс-чек, який хоча б підказав, що щось поламане.

Окрім хелс-чеків, у складній системі перетворень важливо пам'ятати, де слаба ланка.

Технологія, яка не підводить: AWS Kinesis Firehose. Це такий безрозмірний приймач повідомлень, які він батчить та складає в базу. Зручно для ситуації, коли потрібне бути впевненим в масштабуванні. Колись на проєкті мільярди повідомлень в день збирали, і Firehose цілком спокійно їх обробляв. Ще Firehose добре порається з помилками на боці бази, а саме вміє спробувати завантаження декілька разів, та в разі остаточної невдачі складає помилкові записи на S3. Та й моніторінг у нього зручний і прозорий. Дуже класна технологія і недорога - близько $0.03 за ГБ даних.

Технологія, яка підвела вже не раз: гем sidekiq-unique-jobs. Він запобігає подвійному запуску завдання за допомогою запираючих записів у Redis. Але, в разі катастрофічного виходу ці записи можуть залишитись назавжди, і наступного разу завдання ніколи не запуститься. А якщо не налаштувати правильно вихід sidekiq при зупинці сервісу, то катастрофічним буде кожний вихід. Через це ми пройшли минулого разу коли це трапилось. Цього разу ще додав Time-To-Live. Раджу без Time-To-Live для лок-записів навіть не починати з цим гемом.