В SSENSE ние бяхме ранните осиновители на Kubernetes. Започнахме нашето пътуване с микросервизи, като хоствахме услугите си върху него преди четири години, една година след първоначалното му пускане. Избрахме това решение заради мащабируемостта, гъвкавостта и възможностите, които предоставя. Нашият модел на трафик често се увеличава много внезапно поради промоции и екосистемата на Kubernetes може да ни предостави възможност да се увеличим много бързо, за да предоставим на нашите клиенти безпроблемно изживяване. Можем лесно да поддържаме увеличение от 20 пъти нормалното ни разпространение на трафика за 1 до 2 минути, като поддържаме нашите инфраструктурни разходи на техния минимум, когато тези пикове са намалели. Не всяка компания може да каже същото за своята инфраструктура.

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

Екосистемата Kubernetes

Сравнително лесно е да се сравни монолитно приложение, което работи на виртуален или физически сървър. Въз основа на моделите за достъп до вашето приложение – чрез регистрационни файлове, APM показатели или по друг начин – можете да пресъздадете нещо много подобно на реалния трафик, като използвате всеки вид популярен инструмент за сравнителен анализ. Можете да контролирате броя на едновременните потребители и да разгледате отблизо показателите на приложението си. Когато вашите табла за управление започнат да стават червени, вие имате добра представа за натоварването, което вашият монолит и неговите зависимости могат да понесат. Въз основа на тези резултати можете да поставите резервиране според вашия бюджет и разпоредби за трафик и да рестартирате своя бенчмарк, за да оцените вашите допускания.

Един от най-често срещаните начини за използване на Kubernetes е като го инсталирате в облака (напр.: AWS, Google Cloud и т.н.) и го накарате да използва различните услуги, за да управлява броя на сървърите — известни като възли — в клъстера което е необходимо за поддържане на товара. Обикновено ще зададете минимален и максимален брой възли, за да не нарушите бюджета си и да сте сигурни, че имате налични ресурси за upscale на pod. Това е много полезно, защото означава, че ще спестите разходи, когато нямате твърде голямо натоварване, и ще платите за това, от което се нуждаете, когато натоварването започне да се увеличава.

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

Сега, след като имаме еластичен клъстер за разгръщане на нашите микроуслуги, можем също така да зададем политики за Horizontal Pod Autoscaler (HPA), за да им позволим автоматично мащабиране въз основа на използването на процесора и паметта (има също персонализирани показатели, на които можете да увеличите мащаба, когато са инсталирани, но за тази статия нека се съсредоточим само върху процесора и паметта). Трябва да зададете минимален и максимален брой подове, както и тригера, който ще стартира автоматичното мащабиране. Например, искам моята микроуслуга винаги да има минимум 2 pods, но максимум 50 pods, и искам да надстроя, когато общото използване на процесора е над 60%. За повече информация относно HPA, предлагам да разгледате „раздела HPA на Kubernetes“.

Сега, как да сравните микроуслуга, която може да надгражда себе си в екосистема, която също може да направи същото?

Инструменти за наблюдение

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

  • Показатели за Kubernetes: CPU и памет, използвани от вашата услуга, брой подове, брой рестартирания, брой възли и тяхното използване.
  • Достъп до вашите показатели за зависимости: процесор, памет, мрежа, връзки на вашите хранилища за данни и закъснение за извикване на други услуги.
  • Мониторинг на ефективността на приложението (APM) за вашата услуга: латентност, брой грешки, Apdex резултат и др.

Инструменти за сравнителен анализ

Тази статия не предлага кои инструменти да използвате, всеки има различни случаи на употреба и всеки инструмент ще бъде полезен в определени ситуации. Ако никога не сте използвали инструмент за сравнителен анализ, ето списък с най-популярните:

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

Типове бенчмаркове

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

Бенчмарк за единичен под

Първият тип тест за ефективност, който трябва да изпълните, е с единична капсула. Не е включен Horizontal Pod Autoscaller. По този начин знаете точно как вашето приложение и неговите зависимости ще се държат при стрес. Ако се сблъсквате с проблеми при справянето със среден брой едновременни заявки с един под, можете да знаете със сигурност, че проблемите ще се увеличават, както и вашата услуга.

Добавяйте все повече и повече едновременни потребители, докато видите, че ресурсите на вашия pod достигат лимита си. Ако вашите зависимости не са причинили проблеми, това означава, че можете да мащабирате приложението си. Отбележете броя на едновременните потребители и сте готови за следващата стъпка!

Еталонен показател за няколко капсули

Сега, когато имате добра представа за натоварването, което вашата услуга може да поеме, е време да увеличите това ограничение, за да идентифицирате прага, при който вашите зависимости ще започнат да се провалят при вас. Започнете, като ръчно мащабирате услугата си до две групи, след което изпълнете същия скрипт за сравнение, както за първата фаза, със същия брой едновременни потребители. Увеличете броя на подовете и броя на едновременните потребители и повторете, докато не започнете да виждате някакво ниво на влошаване на резултатите. Това ще означава, че сте достигнали капацитета на вашите зависимости. Обърнете внимание на едновременния брой потребители, броя на подовете и максималния брой заявки в секунда, които вашето приложение може да достигне. Винаги е добре да дадете тази информация на други услуги, които ще ви се обадят (вътрешно).

Ако числата, които сте отбелязали, са напълно подходящи за вас и представляват натоварване, което вероятно никога няма да достигнете, вие сте готови със сесията си за сравнителен анализ. Използвайте броя на капсулите, които достигнете, и го намалете с една. Това води до вашата максимална стойност за вашия HPA. Минималната стойност винаги трябва да бъде от две капсули като най-добра практика, когато Kubernetes премества капсули от възли към възли, за да оптимизира ресурсите.

Ако максималният трафик, който вашата услуга може да обработи, не е достатъчен за очакваното количество натоварване, което ще получи, е време да се върнете към бялата дъска и да направите промени в дизайна си. Можете или да добавите кеширане (или в паметта, или като използвате друга услуга като Redis), да използвате настройка само за запис Leader + множество последователи за четене за вашата база данни, да използвате различен тип хранилище за данни като NoSQL или да децентрализирате някои процеси в други микроуслуги. Има много различни решения. Използвайте този, който ще отговаря на вашите нужди от услуги.

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

В зависимост от архитектурата, която сте избрали, за да може вашето приложение да обработва повече трафик, някои облачни услуги предлагат хранилища за данни, които също могат да се мащабират. Което означава, че можете практически да мащабирате безкрайно, стига бюджетът ви да може да го поеме. Когато се сблъскате с тази ситуация, изпълнявайте сравнителни тестове, докато достигнете ниво на трафик, при което става много трудно да получите и задайте текущата конфигурация на хранилището за данни като своя максимум (напр.: максимален брой последователи). Прочетете внимателно раздела за цените на избраното от вас хранилище за данни и поставете ограничения, които няма да надхвърлят бюджета ви. Веднъж направих настройка без сървър, използвайки AWS API Gateway + Lambda + DynamoDB, която може лесно да обработва 10 000 заявки в секунда. Може да се мащабира „безкрайно“, но накрая има цена, която трябва да се плати.

HPA бенчмаркове

На този етап знаете колко натоварване може да поеме една капсула и колко капсули можете да мащабирате, преди да започне да се срива. Сега следващият въпрос е: от кои тригери се нуждае вашето HPA, за да мащабира вашата услуга? Ако зададете твърде ниски тригери, малка промяна в трафика ще направи услугата ви почти безпроблемна и може да се окаже, че плащате за повече ресурси, отколкото е необходимо. От друга страна, ако зададете тези тригери твърде високо, може да не мащабирате достатъчно бързо, за да поддържате пик и да изпитате прекъсване.

За да проведете този тип тест, проверете кой тип ресурси се увеличава най-много, когато правите вашите сравнителни тестове (CPU или памет). След това, в зависимост от резултатите, задайте тригер, който прецените, че ще има смисъл. На този етап задаването на перфектния номер е най-вече опит и грешка. Ако вашият инструмент за сравнителен анализ го поддържа, опитайте се да увеличите натоварването за определен период от време. Да имаш 500 едновременни потребители за една секунда е много малко вероятен сценарий, но за 2 или 3 минути е много по-вероятно. Това ще демонстрира как приложението ви ще надгражда при по-реалистични сценарии. Увеличете или намалете съответно своя праг на задействане.

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

Показатели за издаване

След като сте настроили фино приложението си за производителност, какво ще кажете за устойчивостта? Когато пускате на Kubernetes с конфигурацията Rolling Update, можете всъщност да изберете скоростта, с която да замените старите подове с нови. Това е много полезно, за да поддържате приложението си работещо, докато актуализирате услугата си. Добра практика е да проведете някои тестове за това поведение.

Например, можете да кажете на Kubernetes да разгръща нови подове със скорост от 50%, където ще замени половината от вашата под наведнъж (вижте параметъра maxUnavailable). Докато правите това, вашата услуга ще работи с половината от капацитета си. Може ли все още да се справи с текущото натоварване по този начин? За да тествате това, изпълнете бенчмарк с голямо въздействие и задействайте внедряване. Вижте какво се случва. Засегната ли е латентността на вашите услуги? Увеличен ли е броят на грешките? Ако е така, трябва да го намалите до много по-малък брой и да преконфигурирате теста. Но това ще направи процеса на внедряване много по-дълъг. Колко време отнема актуализирането на всички подове с много малък брой „Maxunavailable“? Приемливо ли е това време? Не е? Повишете го малко и повторете теста, докато получите идеалния праг, който отговаря на вашите нужди.

Бенчмаркинг с трети страни

В някои случаи ще трябва да сравните услуги, които се обаждат директно на трети страни (напр.: доставчици на имейл услуги, шлюзове за плащане и т.н.). Доколкото е възможно, трябва да се обадите на тези служби, за да сте сигурни, че и те могат да се справят с товара. Ако не можете да направите това по някаква причина, проверете дали имат режим на пясъчник, който можете да използвате, за да се подигравате на тези обаждания. Като алтернатива, ако не можете да ги извикате в бенчмарк, превключете приложението си в режим на бенчмарк и се подиграйте на повикването, направено към третата страна, като добавите произволно количество латентност. Това количество закъснение трябва да се намери, като първо се извика техният API. Ако обаждането отнема около 500 ms, добавете произволно количество латентност между 400 ms и цяла секунда. Няма да можете да се уверите, че могат да се справят с вашия трафик, но ще имате представа как вашата услуга ще реагира при висок трафик с допълнителното забавяне, което трета страна може да добави.

Опашки за сравнителен анализ

Често имаме микроуслуги, които се използват като работни, четещи от опашка и изпълняващи някаква логика. През повечето време тези видове услуги никога не се сравняват, но всъщност трябва да бъдат. Когато тестваме локално, в QA или с нормален поток от събития в производството, такива работници вършат работата си доста добре. Но какво се случва, когато има скок на събитията? Какво ще стане, ако поради импортиране или масова актуализация, направена от друга услуга, която задейства събития, за които вашата услуга е абонирана, получите хиляди събития за обработка и обработката ще отнеме 5 минути, 15 минути или дори повече от час ? Приемливо ли е за вашата услуга? Може ли да създаде условия на състезание между човешките действия и резултатите от обработката на тези събития? Ако не виждате никакъв проблем, това е добре, но в противен случай как можем да го тестваме?

За тези тестове ще трябва да имате някои скриптове за създаване на фалшиви събития във вашата опашка. Опитайте се да се уверите, че вашият работник не обработва нищо друго освен вашия тест и нека вашите регистрационни файлове са активирани в режим на информация или отстраняване на грешки. Можете да използвате времевия печат на вашия журнал, за да знаете времето между първото и последното обработено събитие и да определите общото време за обработка. Уверете се, че опашката ви е празна и изпратете партида от събития от това, което смятате за малко за вашата услуга. Например, ако знам, че услугата ми отнема известно време, за да обработи всяко събитие, бих започнал с партида от 100 събития и ще замеря времето. След като приключите, отбележете резултатите и опитайте отново с група от 200 събития и след това с 300, за да сте сигурни, че времето за обработка е линейно (обикновено е така, ако имате един работник). Въз основа на резултатите вече можете да знаете, че ако има партида от 5000 събития, това ще отнеме X време. Достатъчно ли е това време за вашата услуга и бизнес процеса, който изпълнява?

Ако не сте добре с резултатите, можете да добавите още работници и да опитате отново бенчмарковете, но сега трябва да внимавате и със зависимостите, които използва. Добавянето на повече работници ще има ли ефект върху това? Това е още една серия от тестове за отговор на този въпрос!

Услуга с тестове за множество процеси

В зависимост от технологиите, използвани във вашата услуга, възможно е да използвате някакъв вид уеб сървър или система за контрол на процеси, която ще създаде услугата ви няколко пъти в рамките на една и съща група. Например, ако имаме API на Python, един от най-често срещаните модели е да имаме GUnicorn пред него, за да гарантираме, че винаги работи, а също и да добавим възможността да имаме няколко работници едновременно. Това би означавало, че вашият API може да бъде умножен по 5, ако сте го конфигурирали така. Но тогава как да разберете колко работници (или процеси) да изпълнявате паралелно? С повече процеси идва нуждата от повече ресурси по отношение на процесора и паметта; по-добре ли е да имате по-големи капсули, които управляват по-голям брой работници? Или по-малки капсули, работещи само с няколко? За да откриете това, върнете се към вашия сравнителен тест за единична капсула и направете някои експерименти. Започнете с един работник и намерете най-доброто количество CPU и памет, за да изпълните нуждите му, и след това започнете да добавяте повече работници и ресурси. Всяка технология и приложение е уникално и няма магическа формула за намиране на перфектните стойности. Ще трябва да направите предположения и да ги тествате, като използвате различни количества ресурси.

Пълни бенчмаркове от край до край

Сега, след като имате множество микроуслуги, които са тествани и са готови да поемат всякакво натоварване, как целият ви клъстер Kubernetes ще понесе удара? Това упражнение изисква много повече координация и подготовка. Ще ви трябват членове на екипа, които са напълно посветени за определен период от време, за да управляват различните аспекти на този тип тестове.

Първо, ще трябва да пресъздадете трафика за всички ваши публично достъпни крайни точки (напр. уебсайт, публичен API, мобилни приложения и т.н.) от пиков период от време. След това трябва да създадете тестов пакет, който ще може да копира този трафик. След като това бъде направено, ще ви трябва друг клъстер от сървъри — или един сървър с много ресурси — така че вашият бенчмарк сам по себе си не засяга ресурсите на целевия клъстер. Планирайте времева рамка като половин ден или дори цял ден с целия отдел, където всяка услуга трябва да бъде конфигурирана „като производство“. Трябва да уведомите всички, че тяхната тестова среда ще бъде нестабилна за този период от време — особено вашия QA екип. Както направихте с предишните сравнителни тестове, следвайте същия принцип, за да тествате итеративно, като увеличавате броя на едновременните потребители при всеки тест и за да сте сигурни, че всички групи се връщат към минималния си брой групи, когато започнете нов тест. Един от често срещаните проблеми, с които може да се сблъскате, е, че някои услуги не могат да бъдат мащабирани, защото вече няма достатъчно възли в клъстера. Ако случаят е такъв и това се отразява на изживяването на клиентите ви, може да искате да запазите минималния брой възли малко по-висок, когато знаете предварително кога ще настъпят пикове на трафика - например по време на маркетингова кампания или специална промоция.

Предлагам да правите това упражнение веднъж на всяко тримесечие, за да сте сигурни, че производителността не е повлияна от най-новите версии.

Индекси, цели и споразумения за ниво на обслужване

Цялата тази работа и експерименти са необходими, за да се постави правилното наблюдение и сигнали. Не искате да бъдете събуждани през нощта на всеки 5 минути, защото вашите прагове за наблюдение са твърде ниски. Освен това не искате шефът ви да ви се обажда, защото вашите прагове са били твърде високи и сега услугата ви е влошена и оказва влияние върху клиентското изживяване. Експериментите за сравнителен анализ ще ви помогнат да разберете перфектно услугата си и да зададете правилния праг. Показателите, които събирате с различните налични инструменти за наблюдение, ще ви помогнат да дефинирате SLI (индикатори за ниво на обслужване), като средната ви латентност, процентът на грешки и резултатът на Apdex. Въз основа на тези индикатори вече можете да дефинирате цели като „никога средното забавяне на услугата да не надвишава 500 ms“ или „винаги да има процент грешки под 0,5%“. Можете да използвате такива цели, за да организирате рефактори за прилагане на нови архитектурни модели, които ще ви помогнат да спазвате целите. Освен това, ако предлагате платен API, можете да установите споразумения за ниво на обслужване (SLA), където можете да определите компенсация, ако услугата ви прекъсва твърде често. Например, можете да имате цел, казвайки, че услугата ви ще работи през 99,99% от времето и ако тя е под това число, ще дадете отстъпка на клиентите си. Сравнителният анализ на вашата услуга ще ви помогне да определите целите и да разберете дали можете да ги постигнете.

Заключение

Както можете да видите, услугите за сравнителен анализ в среда, която се мащабира автоматично в облака, може да бъде много трудно. Има много различни настройки и конфигурации, които трябва да се вземат на сериозно, за да сте сигурни, че винаги предлагате най-добрата производителност. Също така, не просто сравнявайте, след като услугата е завършена. Изпълнявайте редовно сравнителни тестове, когато има основни актуализации на кода, актуализации на зависимости и също актуализации на клъстери. Може да не получите същите резултати и ако случаят е такъв, можете наистина бързо да реагирате, преди това да се превърне в проблем в производството. Практиката прави перфектния!

Редакционни рецензии от Deanna Chow, Liela Touré и Prateek Sanyal.

Искате ли да работите с нас? Щракнете тук, за да видите всички отворени позиции в SSENSE!