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

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

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

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

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

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

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

• 15 дата центрови в цял свят;
• 500 уникални услуги в експлоатация;
• 2500 копия на услуги, което е много повече от броя на екипите;
• 4,5 TB месечен трафик;
• 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 релизите.

Практика, подобна на това как миньорите използвали канарите за индикация на нивото на газовете, намери своето място и в ИТ. Пускаме малко истински продуктивен трафик на новата версия, като се опитваме да се вместим в Споразумението за ниво на услуга (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. Тази нода винаги получава по-малко трафик и започваме деплоя с нея. При проблеми ще сравним нейната работа преди деплоя и по време на него. Например, ако грешките са се увеличили 2 пъти, значи и щетата е нараснала 2 пъти.

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