Переезд на новый ElasticSearch сразу тремя монолитамиАрхитектуры, масштабируемость
Ведущий-разработчик, team-lead проекта Автокредит в проекте Колёса. Стаж работы 11 лет.
Запустил проект Автокредит на сайте kolesa.kz. Этот проект первый в СНГ позволяет получить одобрение кредита на б/у авто за 1 минуту онлайн. Менее чем за год обработано уже 2 миллиона заявок на кредит.
Бывает случается так, что идея, которая кажется на первый взгляд хорошей, с течением времени оказывается далеко не самой удачной. Так, в 2012 году идея построить единый API для трёх наших проектов казалась вполне себе хорошей и логичной. Однако, с течением времени проекты стали развиваться, расти каждый в свою сторону, и в результате удерживать их в рамках единого API становилось всё труднее и труднее. API “оброс” специализированными методами и то, что он единый для всех проектов, стало всё больше мешать, нежели помогать.
Хранение и поиск объявлений в API организованы на базе связки MongoDB + ElasticSearch. Случилось так, что к моменту, когда вышла версия ElasticSearch 6.2 мы всё ещё сидели всеми тремя проектами на ElasticSearch 1.4. О том, что послужило триггером для распила API, и с какими проблемами мы столкнулись при переезде на новую версию elasticsearch и будет этот доклад.
Я расскажу:
1. о том, как организовано хранение и поиск объявлений в трёх проектах “Колёса”, “Крыша” и “Маркет”;
2. о том, с какими проблемами мы столкнулись при использовании ElasticSearch в едином API трёх монолитов;
3. почему единое API для трёх проектов – это плохо;
4. как мы переводили одновременно три монолита с ~41 млн объявлений без downtime с Elasticsearch 1.4 на Elasticsearch 6.2. Сколько это заняло времени, с какими проблемами мы столкнулись;
5. как переезд повлиял на нагрузку на железо;
6. почему не нужно копить технический долг.