Как да спрем да се тревожим и да започнем да живеем без монолита

Всички ние обичаме историите. Харесва ни да разказваме за нашите минали победи, сражения или просто опит в работата, седнали край огъня.

Днес е точно такъв ден. И макар да не сте край огъня, имаме история за вас. Историята за това, как започнахме да работим с хранилището на Tarantool.

Някога в нашата компания имаше няколко „монолита“ и един общ „таваница“, към който тези монолити бавно, но сигурно приближаваха, ограничавайки полета на нашата компания и нашето развитие. И имаше ясна представа: един ден ще се ударим в този таван.

В момента при нас царува идеологията на разделяне на всичко и всякакво, от оборудвание до бизнес логиката. Вследствие на това, например, имаме две почти независими на мрежово ниво ДЦ. А тогава всичко беше съвсем различно.

В днешно време има множество инструменти и средства за прилагане на промени, като CI/CD, K8S и т.н. В „монолитното“ време обаче не ни трябваха толкова много чужди думи. Достатъчно беше просто да коригираме „хранимката“ в базата.

Но времето напредваше, и броят на запитванията напредваше заедно с него, понякога изстрелвайки RPS надвишаващи нашите възможности. При навлизането на пазара на страните от ОНД натоварването на процесора на БД на първия монолит не падаше под 90%, а RPS се задържаха на ниво 2400. И това не бяха просто малки селекции, а здрави запитвания с много проверки и JOIN, които можеха да пробягат през почти половината данни на фона на голям IO.

Когато на сцената започнаха да се появяват истински разпродажби по „Черен петък“, а Wildberries ги започнаха първи в Русия, ситуацията стана съвсем тъжна. Нали натоварването в такива дни нараства трикратно.
Ох, тези „монолитни времена“! Уверен съм, че и вие сте се сблъсквали с подобно нещо и все още не можете да разберете как е могло да се случи с вас.

Какво да се прави - модата засяга и технологиите. Още преди 5 години ни се наложи да преосмислим една от тези моди с наличния сайт на .NET и MS SQL-сервер, който грижливо съхраняваше цялата логика на самия сайт. Съхраняваше я толкова внимателно, че разпиляването на този монолит се оказа дълъг и съвсем не лесен процес.
Небольшо отстъпление.

На различни мероприятия казвам: «ако не сте нарязали монолита, значи не сте растели!» Интересно е вашето мнение по този въпрос, моля напишете го в коментарите.

И гръмът удари

Да се върнем към нашия «костер». За да разпределим натоварването на «монолитната» функционалност, решихме да разделим системата на микросервизи, основани на opensource технологии. Защото, понеже, мащабирането им е по-евтино. А осъзнаването, че ще ни се наложи да мащабираме (и доста), беше на 100 %. Тогава вече се беше получило да излезем на пазарите на съседни държави и броят на регистрациите, както и броят на поръчките, започна да нараства още повече.

Анализирайки първите кандидати за излизане от монолита в микросервизи, разбрахме, че в 80 % от случаите записите в тях са 99 % от back office системи, а четенето — от предната линия. Първо това засягаше две важни за нас подсистеми — потребителски данни и система за изчисляване на крайната стойност на стоките на базата на информация за допълнителни клиентски отстъпки и купони.

На правата на отстъпление. Сега е страшно да си представим, но освен гореспоменатите подсистеми, от нашия монолит бяха изнесени и продуктовите каталози, потребителската кошница, системата за търсене на продукти, системата за филтриране на продуктовите каталози и различни видове препоръчителни системи. За работата на всяка от тях съществуват отделни класове на строго специализирани системи, но в миналото всички те живееха в един “теремок”.

Планирахме да изнесем данните за нашите клиенти веднага на шардирина система. Изнасянето на функционалността по изчисляване на крайната стойност на стоките изискваше добра мащабируемост по четене, тъй като тя създаваше най-голямо натоварване по RPS и беше най-трудна за изпълнение за базата (много данни са включени в процеса на изчисления).

В резултат на това се роди схема, която добре се съчетава с Tarantool.

По това време за работа на микросервизите бяха избрани схеми с няколко ЦОД на виртуални и хардуерни машини. Както е показано на изображенията, бяха приложени варианти на репликации Tarantool както в режим master-master, така и master-slave.

Архитектура. Вариант 1. Сервиз на потребителите

В момента това са 24 шардове, във всеки от които по 2 инстанса (по един на всеки ДЦ), всички в режим мастър-мастър.

Над базата данни (БД) се намират приложения, които достъпват реплики на БД. Приложенията работят с Tarantool чрез нашата персонализирана библиотека, която реализира интерфейса на Go-драйвера Tarantool. Тя вижда всички реплики и може да работи с мастера за четене и запис. По същество реализира модела replica set, в който е добавена логиката за избор на реплики, изпълнение на повторни опити, circuit breaker и rate limit.

Същевременно има възможност за конфигуриране на политиката за избор на реплика в разреза на шардите. Например, round-robin.

Архитектура. Вариант 2. Услуга за изчисление на крайната цена на продукта.

Преди няколко месеца голяма част от заявките за изчисление на крайната цена на продуктите преминаха на нова услуга, която принципно работи без бази данни, но известно време 100% от обработката беше извършвана от услуга с Tarantool под капака.

Базата данни на услугата съдържа 4 мастера, в които синхронизаторът събира данни, и всеки от тези мастери раздава данни на readonly-реплики чрез репликация. Всеки от мастерите има приблизително 15 такива реплики.

В и двете схеми, при недостъпност на един от центровете за данни (ДЦ), приложението може да получава данни от втория.

Следва да се отбележи, че в Tarantool репликацията е доста гъвкава и се конфигурира в runtime. В други системи понякога възникват затруднения. Например, при промяна на параметрите max_wal_senders и max_replication_slots в PostgreSQL е необходимо рестартиране на мастера, което в редица случаи може да доведе до прекъсвания на връзките между приложението и СУБД.

Търсете и ще намерите!

Защо не направихме "като нормалните хора", а избрахме нетипичен начин? Виждайки какво се счита за нормално. Мнозина изобщо правят клъстер от Mongo и го разпределят в три гео-разпределени ДЦ.

По това време вече имахме два проекта на Redis. Първият беше кеш, а вторият представляваше постоянна база данни за не особено критични данни. С него обаче се оказа доста сложно, отчасти по наша вина. Понякога доста големи обеми данни бяха в ключа и от време на време на сайта му ставаше зле. Тази система използвахме в master-slave вариант. Имаше много случаи, когато нещо се случваше с мастера и репликацията се проваляше.

Тоест Redis е добър за stateless задачи, а не за stateful. Възможно бе да решим повечето задачи, но само ако ставаше въпрос за key-value решения с няколко индекса. Но по това време Redis имаше сериозни проблеми с персистентността и репликацията. Освен това, имаше оплаквания относно производителността.

Размисляхме за MySQL и PostgreSQL. Но първият някак не се наложи при нас, а вторият сам по себе си е доста сложен продукт, и изграждането на прости услуги върху него би било нецелесообразно.
Опитвахме RIAK, Cassandra, дори графова база данни. Всички тези решения са достатъчно нишови и не са подходящи за роля на общ универсан инструмент за създаване на услуги.

В крайна сметка се спряхме на Tarantool.

Обърнахме се към него, когато беше на версия 1.6. Интересуваше ни симбиозата на key-value и функционалността на реляционна база данни. Има вторични индекси, транзакции и спейсове, това е като таблици, но не прости, в които може да се съхранява различен брой колонки. Но убиецът на функцията на Tarantool бяха вторичните индекси в комбинация с key-value и транзакционност.

Също така, отзивчивото русскоязично общество изигра роля, готово да помогне в чата. Активно го използвахме и буквално живеехме в чата. И не трябва да забравяме за приличната персистентност без явни недостатъци и проблеми. Ако погледнем нашата история с Tarantool, имахме много болки и проблеми с репликацията, но никога не загубихме данни по негова вина!

Внедряването започна трудно.

По това време основният ни стек за разработка беше .NET, за който нямаше конектор за Tarantool. Веднага започнахме да правим нещо на Go. С Lua също се получаваше добре. Главният проблем тогава беше с отстраняването на грешки: в .NET с това всичко беше чудесно, а след това да потъне в света на вградения Lua, когато имаш, освен логовете, никаква възможност за дебъг, беше трудно. Освен това, репликацията по някаква причина периодично се разпадна, трябваше да се запозная с архитектурата на Tarantool. Тук чата помогна, в по-малка степен — документацията, понякога гледахме и кода. По това време документацията беше така си така.

Така през последните месеци успяхме да съберем опит и да постигнем достойни резултати в работата с Tarantool. Създадохме в git еталонни разработки, които помогнаха при изграждането на нови микросервизи. Например, когато възникваше задача: да се направи нов микросервис, разработчикът поглеждаше изходния код на еталонното решение в репозиториума и създаването на новия не отнемаше повече от седмица.

Това бяха специални времена. Примерно, тогава можеше да се обърнеш към администратора на съседната маса и да попиташ: „Дай ми виртуалка“. След около тридесет минути машината вече беше у теб. Самият ти се свързваше, инсталираше всичко и трафикът ти се включваше.

Днес така вече не става: трябва да настроиш мониторинг на услугата, логване, да покриеш функционалността с тестове, да поръчаш виртуалка или доставки в Кубер и т.н. В крайна сметка, така ще е по-добре, макар и по-дълго и по-проблематично.

Разделяй и владей. Как е положението с Lua?

Имаше сериозна дилема: на някои екипи не им се получаваше надеждно да внедряват промени в услугата с голямо количество логика на Lua. Често това бе съпроводено с неработеща услуга.

Тоест разработчиците подготвят някаква промяна. Tarantool започва миграция, а репликата все още е със стария код; там пристига по репликацията някакъв DDL, нещо друго, и кодът просто се срине, защото това не е било предвидено. В резултат на това процедурата за обновление при администраторите беше записана на лист А4: спиране на репликацията, обновление на това, включване на репликацията, спиране тук, обновление там. Ужас!

В крайна сметка сега по-често се опитваме да не правим нищо на Lua. Просто с помощта на iproto (бинарен протокол за взаимодействие със сървъра) и това е. Възможно е, че това е недостатък на знанията на разработчиците, но от тази гледна точка системата е сложна.

Не винаги сляпо следваме този сценарий. Днес нямаме черно и бяло: или всичко е на Lua, или всичко е на Go. Вече разбираме как може да се комбинират, за да не получим проблеми с миграцията по-късно.

Къде сега има Tarantool?
Tarantool се използва в услугата за изчисление на крайната цена на стоките, като се вземат предвид купоните за отстъпка, известна още като "Промотайзер". Както вече споменах, в момента тя излиза от употреба: заменя я нов каталог услуга с предварително изчислени цени, но преди половин година всички изчисления се извършваха в "Промотайзера". Преди половината от логиката й беше написана на Lua. Преди две години услугата стана хранилище, а логиката беше пренаписана на Go, защото механиката на работа с отстъпките се промени и услугата не разполагаше с достатъчно производителност.

Една от най-критичните услуги е профилът на потребителя. Тоест всички потребители на Wildberries се съхраняват в Tarantool, а те са около 50 милиона. Системата е шардирована по ID на потребителя и е разпределена на няколко дата центрове с връзки през Go услугите.
Преди време лидерът по RPS беше "Промотайзер", достигаше до 6000 заявки. В един момент имахме 50-60 екземпляра. В момента лидер по RPS са профилите на потребителите, с приблизително 12000. В тази услуга се използва кастомно шардирование с разбивка по диапазони на потребителските ID. Услугата обслужва над 20 машини, но това е твърде много, планираме да намалим ресурсите, защото й стигат мощностите на 4-5 машини.

Услугата за сесии е наша първа услуга на vshard и Cartridge. Настройването на vshard и обновяването на Cartridge изискваха от нас определени усилия, но в крайна сметка всичко стана.

Услугата за показване на различни банери на сайта и в мобилното приложение беше една от първите, пуснати веднага на Tarantool. Тази услуга е забележителна с това, че е на около 6-7 години, все още е в употреба и никога не е била рестартирана. Използваше се репликация master-master. Никога нищо не е счупено.

Има пример за използване на Tarantool за функционалността на бързите справочници в складската система, за бързо проверяване на информация в определени случаи. Опитахме да използваме за това Redis, но данните в паметта заемат повече място, отколкото в Tarantool.

Услугите на листа за изчакване, клиентските абонаменти, модните в момента истории и отложените стоки също работят с Tarantool. Последната услуга заема около 120 ГБ в паметта. Това е най-обемната услуга от посочените.

Заключение

Благодарение на вторичните индекси в комбинация с key-value и транзакционността, Tarantool е отличен за архитектури, основани на микросервизи. Въпреки това, се сблъскахме с трудности, когато разгръщахме изменения в услуги с много логика на Lua — услугите често спираха да работят. Не успяхме да преодолеем това, и със времето достигнахме до различни комбинации от Lua и Go: знаем къде да използваме един език и къде — друг.

Какво още може да се прочете по темата

• Създаваме от нулата високо натоварено приложение на Tarantool habr.com/ru/company/mailru/blog/510440
• Надежден избор на лидер в Tarantool Cartridge habr.com/ru/company/mailru/blog/513912
• Telegram канал Tarantool с новини за продукта t.me/tarantool_news
• Обсъдете Tarantool в комюнити-чата t.me/tarantoolru

Източник: habr.com