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

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

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

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

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

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

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

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

Какво да правиш - модата е присъща на технологиите. Преди около 5 години трябваше да преосмислим един от тези модове под формата на съществуващ сайт на .NET и MS SQL сървър, който внимателно съхраняваше цялата логика на самия сайт. Пазех го толкова внимателно, че рязането на такъв монолит се оказа дълго и никак лесно удоволствие.
Малко отклонение.

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

Звук от гръм

Да се ​​върнем към нашия "огън". За да разпределим натоварването на „монолитната“ функционалност, решихме да разделим системата на микроуслуги, базирани на технологии с отворен код. Защото като минимум те са по-евтини за мащабиране. И имахме 100% разбиране, че ще трябва да мащабираме (и то много). В крайна сметка вече беше възможно да се навлезе на пазарите на съседните страни и броят на регистрациите, както и броят на поръчките, започнаха да растат още по-силно.

След като анализирахме първите кандидати за напускане на монолита към микроуслугите, разбрахме, че 80% от писането в тях идва от бек офис системите и четенето от фронт офиса. На първо място, това се отнасяше до няколко важни за нас подсистеми - потребителски данни и система за изчисляване на крайната цена на стоките въз основа на информация за допълнителни клиентски отстъпки и купони.

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

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

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

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

Архитектура. Вариант 1. Потребителска услуга

В момента има 24 шарда, всеки от които има 2 екземпляра (по един за всеки DC), всички в режим master-master.

Върху базата данни има приложения, които имат достъп до реплики на база данни. Приложенията работят с Tarantool чрез нашата персонализирана библиотека, която имплементира интерфейса на драйвера Tarantool Go. Тя вижда всички реплики и може да работи с майстора, за да чете и пише. По същество той прилага модела на набор от реплики, който добавя логика за избор на реплики, извършване на повторни опити, прекъсвач на веригата и ограничение на скоростта.

В този случай е възможно да се конфигурира политиката за избор на реплика в контекста на фрагменти. Например кръгъл робин.

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

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

Сервизната база данни се състои от 4 главни, в които синхронизаторът събира данни, и всяка от тези главни репликационни разпределя данни към реплики само за четене. Всеки майстор има приблизително 15 такива реплики.

Или в първата, или във втората схема, ако един DC е недостъпен, приложението може да получава данни във втория.

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

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

Защо не го направихме „като нормалните хора“, а избрахме нетипичен начин? Зависи какво се счита за нормално. Много хора обикновено правят клъстер от Mongo и го разпространяват в три георазпределени DC.

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

Тоест Redis е добър за задачи без състояние, а не за такива със състояние. По принцип това позволява решаването на повечето проблеми, но само ако те са решения ключ-стойност с двойка индекси. Но Redis по това време беше доста тъжен с постоянството и репликацията. Освен това имаше оплаквания относно производителността.

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

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

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

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

Изпълнението започна трудно

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

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

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

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

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

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

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

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

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

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

Една от най-критичните услуги е потребителският профил. Тоест, всички потребители на Wildberries се съхраняват в Tarantool и има около 50 милиона от тях.Система, разделена на потребителски идентификатор, разпределена в няколко DC, свързани към Go услуги.
Според RPS, Promoter някога е бил лидер, достигайки 6 хиляди заявки. В един момент имахме 50-60 броя. Сега лидерът в RPS са потребителски профили, около 12 хил. Тази услуга използва персонализирано шардинг, разделено на диапазони от потребителски идентификатори. Сервизът обслужва над 20 машини, но това е твърде много, планираме да намалим заделените ресурси, тъй като капацитетът от 4-5 машини е достатъчен за нея.

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

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

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

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

Заключение

Благодарение на вторичните индекси, комбинирани с ключ-стойност и транзакционност, 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

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