Тестове на продукция: Canary Deployment

Канарейка е малко птичка, която постоянно пее. Тези птички са чувствителни към метан и въглероден оксид. Дори и от малка концентрация на излишни газове в въздуха, те губят съзнание или умират. Златотърсачи и миньори взимали птички с тях: докато канарейките пеят, може да се работи, а ако замълчат — в мината има газ и е време да се напусне. Миньорите жертвали малката птичка, за да излязат от мините живи.

Подобна практика намира приложение и в IT. Например, при стандартната задача за внедряване на нова версия на услуга или приложение на продукция с предварително тестване. Тестовата среда може да бъде твърде скъпа, автоматизираните тестове не покриват всичко, което бихме искали, а не тестването и жертвата на качеството е рисково. Точно в тези случаи помага подходът Canary Deployment, при който мъничка част от реалния продукционен трафик се пуска на новата версия. Този подход помага безопасно да се провери новата версия на продукция, жертвайки малко в името на голямата цел. По-подробно за това как работи подходът, какви предимства носи и как да бъде реализиран, ще разкаже Андрей Маркелов (Andrey_V_Markelov), с примера за реализиране в компанията Infobip.

Андрей Маркелов — старши софтуерен инженер в Infobip, който вече 11 години се занимава с разработка на приложения на Java в областта на финансите и телекомуникациите. Разработва Open Source продукти, активно участва в Atlassian Community и пише плъгини за продуктите на Atlassian. Евангелист на Prometheus, Docker и Redis.

За компанията Infobip

Това е глобална телекомуникационна платформа, която позволява на банки, търговци на дребно, онлайн магазини и транспортни компании да изпращат съобщения на своите клиенти чрез SMS, push, имейли и гласови съобщения. В такъв бизнес е важна стабилността и надеждността, за да могат клиентите да получават съобщенията си навреме.

IT инфраструктурата на Infobip в цифри:

• 15 центрове за данни по целия свят;
• 500 уникални услуги в експлоатация;
• 2500 инстанции на услуги, което е много повече от броя на екипите;
• 4,5 Тбайт месечен трафик;
• 4,5 милиарда телефонни номера;

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

Версии

Типичният релиз при нас протича така. Например, имаме услуги A, B, C, D и E, всяка от които се разработва от отделен екип.

В даден момент екипът на услуга A решава да пусне нова версия, но екипите на услуги B, C, D и E не знаят за това. Има два варианта за действията на екипа на услуга A.

Ще проведе инкрементален релиз: първо ще замени една версия, а след това другата.

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

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

И така, какво искаме?

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

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

Проблеми при пускането

Клиентският трафик е непредсказуем. Невъзможно е да се предвиди, кога клиентският трафик ще бъде минимален. Не знаем къде и кога клиентите ще започнат своите кампании — може би тази нощ в Индия, а утре в Хонг Конг. С оглед на голямата разлика в часовите зони, пускането дори в 2 часа през нощта не гарантира, че клиентите няма да пострадат.

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

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

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

Не можем допускать даунтаймы!Неприемлемо! Имаме допустимо ниво на наличност (Error Budget), когато работим 99,99% от времето, например, а останалите проценти са "право на грешка". Постигането на 100% надеждност е невъзможно, но е важно постоянно да се следят сривовете и прекъсванията.

Класически решения

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

Да пиша тестове.Тестовете работят, но понякога съвсем не така, както иска бизнесът. Правенето на пари не е работа на тестовете.

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

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

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

Има и допълнителни сложности. За разработчика е стресиращо — да губи много време, за да провери всичко ръчно.

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

Smoke-тестове.

Още един начин да решим проблемите с деплоя. Нека разгледаме как работят smoke-тестовете на предишния пример, когато екип A иска да деплойне нова версия.

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

Вторият вариант — да деплойме с допълнителен хардуер. Екипът го тества на продукция, след това прехвърля и всичко работи.

Недостатъци на smoke-тестовете:

• Не можете доверять тестам. Къде да намерим същия трафик, както в продукцията? Може да се използва трафик от вчера или от преди седмица, но той не винаги съвпада с актуалния.
• Трудно е за поддържане. Ще трябва да поддържате тестови акаунти, постоянно да ги нулирате преди всяко разгръщане, когато активните записи се изпращат в хранилището. Това е по-сложно, отколкото да пишете тест в собствената си песенница.

Единственото предимство тук е възможността да проверите производителността.

Canary-релизите

Поради недостатъците на smoke тестовете започнахме да използваме canary-релизите.

Практиката, подобна на тази, каквато миньорите използвали канарки за индикация на нивата на газ, намери своя израз и в IT. Пускаме малко истински производствен трафик на новата версия, като се опитваме да спазим Service Level Agreement (SLA). SLA е нашето "право на грешка", което можем да използваме веднъж годишно (или за някакъв друг период). Ако всичко е наред, ще добавим повече трафик. Ако не — ще върнем предишните версии.

Реализация и нюанси

Как реализирахме canary-релизите? Например, група от клиенти изпраща съобщения през нашия сервис.

Разгръщането протича така: сваляме един възел от балансировщика (1), променяме версията (2) и отделно пускаме малко трафик (3).

В общи линии, в групата ще са доволни всички, дори ако един потребител не е. Ако всичко е наред — сменяме всички версии.

Ще покажа схемата, как изглежда за микросервисите в повечето случаи.

Има Service Discovery и два допълнителни сървиса: S1N1 и S2. Първият сървиз (S1N1) уведомява Service Discovery, когато стартира, а Service Discovery го запомня. Вторият сървиз с два възела (S2N1 и S2N2) също уведомява Service Discovery при стартирането.

Вторият сървиз за първия функционира като сървър. Първият запитва Service Discovery за информация относно своите сървъри, а когато получава — ги намира и проверява («health check»). Когато направи проверка, изпраща им съобщения.

Когато някой иска да разгръща новата версия на втория сървиз, той уведомява Service Discovery, че вторият възел ще бъде canary-възел: към него ще бъде изпращан по-малко трафик, защото ще премине разгръщане. Сваляме canary-възела от балансировщика и първият сървиз не му изпраща трафик.

Променяме версията и Service Discovery знае, че втората нода вече е canary — можем да й даваме по-малко натоварване (5%). Ако всичко е наред, сменяме версията, възстановяваме натоварването и продължаваме напред.

За да реализираме всичко това, имаме нужда от:

• балансиране;
• мониторинг, тъй като е важно да знаем какво очаква всеки потребител и как детайлно работят нашите услуги;
• анализ на версиите, за да разберем колко добре новата версия ще функционира в производствена среда;
• автоматизацията — пишем последователност за внедряване (deployment pipeline).

Балансиране

Това е първото, за което трябва да помислим. Има две стратегии за балансиране.

Най-простият вариант, при който една нода винаги е canary. Тази нода винаги получава по-малко трафик и започваме внедряването от нея. В случай на проблеми ще сравним работата й преди внедряването и по време на него. Например, ако грешките се увеличат два пъти, значи и щетите са нараснали два пъти.

Canary-нода се задава по време на внедряването. Когато внедряването приключи и й бъде отнет статусът canary, балансът на трафика ще бъде възстановен. С по-малко машини получаваме честно разпределение.

Мониторинг

Крайната основа на canary релизите. Трябва точно да разберем защо го правим и какви метрики искаме да съберем.

Примери за метрики, които събираме от нашите услуги.

• Брой грешки, които се записват в логовете. Това е очевиден показател, че всичко работи както трябва. Въобще, това е добра метрика.
• Време за изпълнение на заявките (latency). Тази метрика се следи от всички, защото всички искат да работят бързо.
• Размер на опашката (throughput).
• Брой успешни отговори в секунда.
• Времето за изпълнение на 95% от всички заявки.
• Бизнес метрики: колко пари печели бизнесът за определено време или отлив на потребители. Тези метрики за нашата нова версия могат да бъдат по-важни от тези, които добавят инженерите.

Примери за метрики в повечето популярни системи за мониторинг.

Counter. Това е някаква растяща величина, например броя на грешките. Тази метрика е лесна за интерполация и изучаване на график: вчера имаше 2 грешки, а днес 500, значи нещо не е наред.

Броят на грешките в минута или секунда, е най-важният показател, който може да се изчисли с помощта на Counter. Тези данни дават ясна представа за работата на системата на разстояние. Нека да разгледаме график на броя на грешките в секунда за две версии на производствената система.

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

Gauge. Метриките са подобни на Counter, но записваме стойности, които могат както да се увеличават, така и да намаляват. Например, времето за изпълнение на заявките или размерът на опашката.

На графика е показан пример за време за отговор (latency). По графика се вижда, че версиите са подобни и могат да се използват. Но ако погледнете внимателно, можете да забележите как величината се променя. Ако времето за изпълнение на заявките се увеличава с добавянето на потребители, моментално е ясно, че има проблеми — преди това не беше така.

Summary. Един от най-важните показатели за бизнеса е перцентилите. Метриката показва, че в 95% от случаите нашата система работи така, както искаме. Можем да се примирим с проблеми на някои места, защото разбираме общата тенденция, колко добре или зле е всичко.

Инструменти

ELK Stack. Реализирането на canary може да стане чрез Elasticsearch — записваме в него грешките, когато настъпват събития. С прост API извикване можем да получим броя на грешките във всеки един момент и да ги сравним с предишни периоди: GET /applg/_cunt?q=level:errr.

Prometheus. Добре се представи в Infobip. Позволява реализирането на многомерни метрики, тъй като се използват етикети.

Можем да използваме level, instance, service, да ги комбинираме в една система. С помощта на offset можем да видим, например, стойността на величината преди една седмица само с една команда GET /api/v1/query?query={query}, където {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Анализ на версиите

Има няколко стратегии за анализ на версиите.

Да наблюдаваме метриките само на canary-нода. Един от най-простите варианти: внедряваме нова версия и изучаваме само нейното функциониране. Но ако инженерът в това време започне да разглежда логовете, постоянно нервно презареждайки страниците, то това решение не се различава от останалите.

Canary-нода се сравнява с всяка друга нода. Това е сравнение с други инстанси, които работят на пълен трафик. Например, ако с малък трафик нещата са по-зле или не по-добре, отколкото на реалните инстанси, значи нещо не е наред.

Canary-нода се сравнява със себе си в миналото. Нодовете, определени за canary, могат да бъдат сравнени с исторически данни. Например, ако всичко е било наред преди седмица, можем да се опрем на тези данни, за да разберем текущата ситуация.

Автоматизацията

Искаме да освободим инженерите от ръчно сравнение, затова е важно да реализираме автоматизация. Процесът на деплой (deployment pipeline) обикновено изглежда така:

• старт;
• премахваме нода от балансера;
• създаваме canary-нода;
• включваме балансера с ограничено количество трафик;
• сравняваме.

На този етап реализираме автоматично сравнение. Как може да изглежда и защо е по-добре от проверка след деплой, ще разгледаме на примера от Jenkins.

Това е pipeline към Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary неуспешен, необходимо е да се върнем обратно"  
        return false
    }
}

Тук в цикъла задаваме, че ще сравняваме новата нода в течение на час. Ако canary процесът все още не е завършен — извикваме функцията. Тя съобщава дали всичко е наред или не: def isOk = compare(srv, canary, time, base, offset, metrics).

Ако всичко е наред — sleep DEFAULT SLEEP, например, за секунда, и продължаваме. Ако не — излизаме, деплойът не е успешен.

Описание на метриката. Да видим как може да изглежда функцията compare в примера на DSL.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

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

Имаме две стойности: базова и canary-нода. Стойността на canary-нода е текущата. Базовата е baseValue — това е стойността на всяка друга не canary-нода. Сравняваме стойностите помежду си по формула, която поставяме въз основа на опита и наблюденията си. Ако стойността canaryValue е лоша, деплойът не е успешен и се връщаме назад.

Защо всичко това е необходимо?

Човек не може да провери стотици и хиляди метрики, още по-малко да направи това бързо. Автоматичното сравнение помага да се проверят всички метрики и бързо уведомява за проблеми. Времето за уведомление е критично: ако нещо се е случило в последните 2 секунди, вредата ще бъде по-малка, отколкото ако е станало 15 минути по-рано. Докато някой забележи проблема, напише на поддръжка и поддръжката ни да върне, можем да загубим клиенти.

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

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

Препятствия

Реализирането на това, разбира се, не е лесно. Първо, необходимо е обща система за мониторинг. Инженерите имат свои метрики, поддръжката и аналитиците — други, бизнесът — трети. Общата система е общ език, на който говорят бизнесът и разработката.

Необходимо е да проверим на практика стабилността на метриките. Проверка помага да се разбере, какъв минимален набор от метрики е необходим, за да се осигури качество.

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

Каква полза получихме от canary-версии

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

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

Автоматизирахме деплой. Това вече не е ръчен процес, както преди, а истински автоматизиран. Но той отнема повече време.

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

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

Инженерни подходи и практики — основният фокус на конференцията TechLead Conf. Ако сте постигнали успехи на пътя към техническото съвършенство и сте готови да споделите какво ви е помогнало, — подайте заявление за доклад.

Планираме да проведем TechLead Conf на 8 юни. Разбираме, че сега е трудно да се вземат решения относно участието в конференцията. Но в същото време смятаме, че карантината не е причина да спираме професионалната комуникация и развитие. Затова по всяка вероятност ще намерим начин да обсъдим въпросите на технологичния лидер и подходите за решаването им — ако е необходимо, ще преминем в онлайн и ще разширим нетуъркинга там!

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