🥇Üretim üzerinde test: Canary Dağıtımı

Kanarya sürekli şarkı söyleyen küçük bir kuştur. Bu kuşlar metan ve karbon monoksite karşı hassastır. Havadaki küçük bir aşırı gaz konsantrasyonundan bile bilinçlerini kaybederler veya ölürler. Altın arayıcıları ve madenciler kuşları madene götürdüler: kanaryalar şarkı söylerken çalışabilirsin, eğer sessizsen - madende gaz var ve gitme zamanı. Madenciler, madenlerden canlı çıkabilmek için küçük bir kuşu kurban ettiler.

Benzer bir uygulama bilişimde de kendine yer bulmuştur. Örneğin, bir hizmetin veya uygulamanın yeni bir sürümünü, ondan önce test edilerek üretime dağıtma standart görevinde. Test ortamı çok pahalı olabilir, otomatik testler istediğiniz her şeyi kapsamaz ve test etmemek ve kaliteden ödün vermek risklidir. Gerçek üretim trafiğinin bir kısmının yeni sürüme yönlendirildiği Canary Deployment yaklaşımının kullanışlı olduğu yer burasıdır. yaklaşım yardımcı olur güvenli bir şekilde yeni sürümü kontrol et prodüksiyon için, büyük bir amaç için biraz fedakarlık yapmak. Yaklaşımın nasıl çalıştığı, neyin yararlı olduğu ve nasıl uygulanacağı hakkında daha fazla ayrıntı anlatacak Andrey Markelov (Andrey_V_Markelov), Infobip şirketindeki uygulama örneğinde.

Andrey Markelov - İnfobip'te Baş Yazılım Mühendisi, 11 yıldır finans ve telekomünikasyon alanında Java uygulamaları geliştirmektedir. Açık Kaynak ürünleri geliştirir, Atlassian Topluluğuna aktif olarak katılır ve Atlassian ürünleri için eklentiler yazar. Prometheus, Docker ve Redis'in Evangelisti.

İnfobip Hakkında

Bankaların, perakendecilerin, çevrimiçi mağazaların ve nakliye şirketlerinin müşterilerine SMS, push, mektup ve sesli mesaj yoluyla mesaj göndermelerini sağlayan küresel bir telekomünikasyon platformudur. Böyle bir işte, müşterilerin mesajları zamanında alabilmesi için istikrar ve güvenilirlik önemlidir.

Rakamlarla İnfobip Bilişim altyapısı:

dünya çapında 15 veri merkezi;
Operasyonda 500 benzersiz hizmet;
Komutlardan çok daha fazlası olan 2500 hizmet örneği;
4,5 TB aylık trafik;
4,5 milyar telefon numarası;

İş büyüyor ve bununla birlikte yayın sayısı da artıyor. harcamak Günde 60 sürümçünkü müşteriler daha fazla özellik ve güç istiyor. Ancak bu zordur - çok sayıda hizmet vardır, ancak çok az komut vardır. Üretimde hatasız çalışması gereken kodu hızlı bir şekilde yazmanız gerekir.

Salıverme

Tipik bir sürüm böyle gider. Örneğin A, B, C, D ve E servisleri var, bunların her biri ayrı bir ekip tarafından geliştiriliyor.

Bir noktada, A hizmeti ekibi yeni bir sürüm dağıtmaya karar verir, ancak B, C, D ve E hizmetleri ekiplerinin bundan haberi yoktur. Servis ekibi A'nın nasıl davranacağına ilişkin iki seçenek vardır.

Tutacak artımlı sürüm: önce bir sürümü, ardından ikincisini değiştirin.

Ancak ikinci bir seçenek daha var: komut ek kapasiteler ve makineler bulacak, yeni sürümü dağıtın ve ardından yönlendiriciyi değiştirin; sürüm, üretim için çalışmaya başlayacaktır.

Her durumda, sürüm test edilmiş olsa bile dağıtımdan sonra neredeyse her zaman sorunlar vardır. Manuel olarak test edebilirsiniz, otomatik olarak yapabilirsiniz, test edemezsiniz - her durumda sorunlar çıkacaktır. Bunları çözmenin en kolay ve en doğru yolu, çalışan sürüme geri dönmektir. Ancak o zaman hasarla, sebeplerle başa çıkabilir ve düzeltebilirsiniz.

Peki ne istiyoruz?

Sorunlara ihtiyacımız yok. Müşteriler onları bizden daha hızlı bulursa itibarlarına zarar verir. bu yüzden yapmalıyız sorunları müşterilerden daha hızlı bulun. Proaktif olarak çalışarak hasarı en aza indiririz.

Aynı zamanda, istiyoruz dağıtımı hızlandırmakböylece hızlı, kolay, doğal ve ekibin baskısı olmadan gerçekleşir. Mühendisler, DevOps mühendisleri ve programcılar korunmalıdır - yeni bir sürümün piyasaya sürülmesi streslidir. Ekip harcanabilir değil, çabalıyoruz insan kaynaklarının rasyonel kullanımı.

Dağıtım sorunları

İstemci trafiği tahmin edilemez. İstemci trafiğinin ne zaman en düşük seviyede olacağını tahmin etmek imkansızdır. Müşterilerin kampanyalarına nerede ve ne zaman başlayacaklarını bilmiyoruz - belki bu gece Hindistan'da, yarın Hong Kong'da. Büyük zaman farkı göz önüne alındığında, gece 2'de bile devreye alma müşterilerin etkilenmeyeceğini garanti etmez.

sağlayıcı sorunları. Haberciler ve sağlayıcılar ortaklarımızdır. Bazen yeni sürümlerin dağıtımı sırasında hatalara neden olan çökmeler olur.

Dağıtılmış ekipler. İstemci tarafını ve arka ucu geliştiren ekipler farklı zaman dilimlerindedir. Bu nedenle çoğu zaman kendi aralarında anlaşamazlar.

Veri merkezleri sahnede tekrar edilemez. Bir veri merkezinde 200 raf vardır - bunu bir sanal alanda yaklaşık olarak tekrarlayamazsınız bile.

Arıza sürelerikabul edilemez! Örneğin, zamanın %99,99'unda çalışırken bir Hata Bütçemiz var ve kalan yüzde "hata marjı". %100 güvenilirliğe ulaşmak imkansızdır, ancak düşmeleri ve arıza sürelerini sürekli olarak izlemek önemlidir.

Klasik çözümler

Hatasız kod yaz. Ben genç bir geliştiriciyken, yöneticiler bana hatasız yayınlama talebiyle yaklaştılar, ancak bu her zaman mümkün olmuyor.

Test yaz. Testler işe yarıyor ama bazen işin istediği şekilde olmuyor. Para kazanmak testlerin işi değil.

Sahnede test edin. İnfobip'teki 3,5 yıllık çalışma hayatım boyunca, sahnedeki halin üretimle en azından kısmen örtüştüğünü hiç görmedim.

Hatta bu fikri geliştirmeye çalıştık: önce aşamamız, ardından ön prodüksiyonumuz ve ardından ön prodüksiyonumuz vardı. Ancak bu da yardımcı olmadı - iktidarda bile eşleşmediler. Aşama ile temel işlevselliği garanti edebiliriz, ancak yük altında nasıl çalışacağını bilmiyoruz.

Sürüm, onu geliştiren kişi tarafından yapılır. Bu iyi bir uygulamadır: Birisi yorumun adını değiştirse bile hemen üretime ekler. Bu, sorumluluk geliştirmeye ve yapılan değişiklikleri unutmamaya yardımcı olur.

Ek komplikasyonlar da var. Bir geliştirici için her şeyi manuel olarak kontrol etmek için çok fazla zaman harcamak streslidir.

Kararlaştırılan Sürümler. Bu seçenek genellikle yönetim tarafından sunulur: "Her gün yeni sürümleri test edip ekleyeceğiniz konusunda anlaşalım." İşe yaramıyor: her zaman diğer herkesi bekleyen bir komut vardır ya da tam tersi.

Duman testleri

Dağıtım sorunlarımızı çözmenin başka bir yolu. Önceki örnekte, A ekibi yeni bir sürümü dağıtmak istediğinde duman testlerinin nasıl çalıştığını düşünün.

İlk olarak, ekip üretime bir eşgörünüm dağıtır. Modellerden örneğe gönderilen mesajlar gerçek trafiği simüle edernormal günlük trafiği eşleştirmek için. Her şey yolundaysa, ekip yeni sürümü kullanıcı trafiğine geçirir.

İkinci seçenek dağıtmaktır ekstra demir ile. Ekip bunu üretim için test eder, ardından geçiş yapar ve her şey çalışır.

Duman testlerinin dezavantajları:

Testlere güvenilemez. Üretim ile aynı trafiği nereden alabilirim? Dün veya bir hafta önce kullanabilirsiniz, ancak her zaman mevcut olanla eşleşmez.
Bakımı zor. Aktif kayıtlar havuza gönderildiğinde, test hesapları tutmanız, her dağıtımdan önce bunları sürekli olarak sıfırlamanız gerekecektir. Bu, kendi sanal alanınızda bir test yazmaktan daha zordur.

Buradaki tek bonus performans kontrol edilebilir.

Kanarya bültenleri

Duman testlerindeki eksiklikler nedeniyle kanarya salımı kullanmaya başladık.

Madencilerin gaz seviyesini belirtmek için kanaryaları nasıl kullandığına benzer bir uygulama, BT'de yolunu buldu. izin verdik yeni sürüme biraz gerçek üretim trafiğiHizmet Düzeyi Sözleşmesini (SLA) karşılamaya çalışırken. SLA, yılda bir kez (veya başka bir süre için) kullanabileceğimiz "hata yapma hakkımızdır". Her şey yolunda giderse, daha fazla trafik ekleyeceğiz. Değilse, önceki sürümleri iade edeceğiz.

Uygulama ve nüanslar

Kanarya salınımlarını nasıl uyguladık? Örneğin, bir müşteri grubu hizmetimiz aracılığıyla mesaj gönderir.

Dağıtım şu şekildedir: dengeleyicinin (1) altından bir düğümü kaldırırız, sürümü değiştiririz (2) ve ayrı ayrı bir miktar trafiğe izin veririz (3).

Genel olarak, bir kullanıcı mutsuz olsa bile gruptaki herkes mutlu olacaktır. Her şey yolundaysa, tüm sürümleri değiştiririz.

Çoğu durumda mikro hizmetlerin nasıl göründüğünü şematik olarak göstereceğim.

Hizmet Keşfi ve iki hizmet daha var: S1N1 ve S2. İlk hizmet (S1N1), başladığında Service Discovery'yi bilgilendirir ve Service Discovery bunu hatırlar. İki düğümlü (S2N1 ve S2N2) ikinci hizmet de başladığında Service Discovery'yi bilgilendirir.

Birincisi için ikinci hizmet bir sunucu olarak çalışır. İlki, Service Discovery'den sunucuları hakkında bilgi ister ve bunu aldığında onları arar ve kontrol eder (“sağlık kontrolü”). Kontrol ettiğinde, onlara mesaj gönderecek.

Birisi ikinci hizmetin yeni bir sürümünü dağıtmak istediğinde, Service Discovery'ye ikinci düğümün bir kanarya düğümü olacağını söyler: konuşlandırma şimdi gerçekleşeceği için ona daha az trafik gönderilir. Kanarya düğümünü dengeleyicinin altından kaldırıyoruz ve ilk hizmet ona trafik göndermiyor.

Sürümü değiştiriyoruz ve Service Discovery ikinci düğümün artık kanarya olduğunu biliyor - ona daha az yük verebilirsiniz (%5). Her şey yolundaysa, versiyonu değiştirir, yükleri iade eder ve çalışmaya devam ederiz.

Tüm bunları uygulamak için şunlara ihtiyacımız var:

dengeleme;
izlemeçünkü her kullanıcının ne beklediğini ve hizmetlerimizin nasıl çalıştığını ayrıntılı olarak bilmek önemlidir;
sürüm analiziyeni versiyonun üretimde ne kadar iyi çalışacağını anlamak;
otomasyon - dağıtım sırasını yazıyoruz (dağıtım işlem hattı).

dengeleme

Düşünmemiz gereken ilk şey bu. İki dengeleme stratejisi vardır.

En basit seçenek ne zaman bir düğüm her zaman kanaryadır. Bu düğüm her zaman daha az trafik alır ve dağıtımı ondan başlatırız. Sorun olması durumunda, dağıtımdan önceki ve dağıtım sırasındaki çalışmalarını karşılaştıracağız. Örneğin 2 kat daha fazla hata varsa, hasar 2 kat artmıştır.

Kanarya düğümü dağıtım işlemi sırasında ayarlanır. Dağıtım sona erdiğinde ve kanarya düğümü durumunu ondan kaldırdığımızda, trafik dengesi geri yüklenecektir. Daha az araba ile adil bir dağıtım elde edeceğiz.

İzleme

Kanarya salmalarının temel taşı. Bunu neden yaptığımızı ve hangi ölçümleri toplamak istediğimizi tam olarak anlamalıyız.

Hizmetlerimizden topladığımız ölçüm örnekleri.

Hata sayısı, günlüklere yazılanlar. Bu, her şeyin olması gerektiği gibi çalıştığının açık bir göstergesidir. Genel olarak, bu iyi bir ölçümdür.
Sorgu Yürütme Süresi (gecikme). Herkes bu metriği izler çünkü herkes hızlı çalışmak ister.
Kuyruk boyutu (verim)
Saniyedeki başarılı yanıt sayısı.
Tüm isteklerin %95'inin yürütme süresi.
İş ölçümleri: bir işletmenin belirli bir süre veya kullanıcı kaybında ne kadar para kazandığı. Yeni versiyonumuz için bu ölçümler, mühendisler tarafından eklenenlerden daha önemli olabilir.

En popüler izleme sistemlerindeki metrik örnekleri.

Sayaç. Bu, örneğin hata sayısı gibi artan bir değerdir. Bu metriğin enterpolasyonunu yapmak ve grafiği incelemek kolaydır: dün 2 hata vardı ve bugün 500, yani bir şeyler ters gitti.

Dakikadaki veya saniyedeki hata sayısı, Counter kullanılarak hesaplanabilecek en önemli göstergedir. Bu veriler, sistemin uzaktan nasıl çalıştığının net bir resmini verir. Üretim sisteminin iki versiyonu için saniyedeki hata sayısı grafiği örneğini ele alalım.

İlk versiyonda birkaç hata vardı, belki de denetim işe yaramadı. İkinci versiyonda, her şey çok daha kötü. Sorunların olduğunu kesin olarak söyleyebiliriz, bu yüzden bu sürümü geri almalıyız.

ölçer. Metrikler Counter'a benzer, ancak artabilen veya azalabilen değerleri kaydediyoruz. Örneğin, sorgu yürütme süresi veya kuyruk boyutu.

Grafik bir gecikme örneğini göstermektedir. Grafik, sürümlerin benzer olduğunu, onlarla çalışabileceğinizi gösteriyor. Ancak yakından bakarsanız, değerin nasıl değiştiğini görebilirsiniz. Kullanıcılar eklendiğinde sorgu yürütme süresi artarsa, sorunların olduğu hemen anlaşılır - daha önce durum böyle değildi.

Özet. İşletmeler için en önemli göstergelerden biri yüzdelik dilimlerdir. Metrik gösteriyor ki vakaların %95'i sistemimiz istediğimiz gibi çalışıyor. Bir yerde sorun varsa kabul edebiliriz çünkü genel gidişatı, her şeyin ne kadar iyi ya da kötü olduğunu anlıyoruz.

Araçlar

ELK Yığını. Elasticsearch'ü kullanarak canary'yi uygulayabilirsiniz - olaylar meydana geldiğinde ona hatalar yazarız. En basit API çağrısıyla, herhangi bir zamanda hata sayısını alabilir ve geçmiş segmentlerle karşılaştırabilirsiniz: GET /applg/_cunt?q=level:errr.

Prometheus. İnfobip'te kendini iyi gösterdi. Etiketler kullanıldığı için çok boyutlu metrikleri uygulamanıza olanak tanır.

Kullanabiliriz level, instance, service, bunları tek bir sistemde birleştirin. yardım ile offset örneğin bir hafta önceki değerin değerini tek bir komutla görebilirsiniz. GET /api/v1/query?query={query}Nerede {query}:

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

Sürüm Analizi

Birkaç sürüm oluşturma stratejisi vardır.

Yalnızca kanarya düğümlerinin ölçümlerini görüntüleyin. En basit seçeneklerden biri: yeni bir sürüm dağıtın ve yalnızca işi inceleyin. Ancak mühendis şu anda günlükleri incelemeye başlarsa, sayfaları sürekli olarak gergin bir şekilde yeniden yüklerse, o zaman bu çözüm diğerlerinden farklı değildir.

Kanarya düğümü diğer herhangi bir düğümle karşılaştırılır. Bu, tam trafikte çalışan diğer örneklerle bir karşılaştırmadır. Örneğin, küçük trafikte işler daha kötüyse veya gerçek örneklerden daha iyi değilse, bir şeyler ters gidiyor demektir.

Kanarya düğümü geçmişte kendisiyle karşılaştırılır. Kanaryaya tahsis edilen düğümler geçmiş verilerle karşılaştırılabilir. Örneğin, bir hafta önce her şey yolundaysa, o zaman mevcut durumu anlamak için bu verilere odaklanabiliriz.

Otomasyon

Mühendisleri manuel karşılaştırmadan kurtarmak istiyoruz, bu nedenle otomasyon uygulamak önemlidir. Dağıtım boru hattı genellikle şöyle görünür:

başlayalım;
düğümü dengeleyicinin altından çıkarın;
bir kanarya düğümü kurmak;
dengeleyiciyi sınırlı miktarda trafikle açın;
Biz karşılaştırın.

Bu aşamada uyguladığımız otomatik karşılaştırma. Nasıl görünebileceği ve konuşlandırmadan sonra neden doğrulamadan daha iyi olduğu konusunda Jenkins'ten bir örneğe bakalım.

Bu Groovy'ye giden boru hattı.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Burada döngüde yeni düğümü bir saatliğine karşılaştıracağımızı belirledik. Kanarya işlemi henüz işlemi bitirmediyse, işlevi çağırırız. Her şeyin yolunda olup olmadığını bildiriyor: def isOk = compare(srv, canary, time, base, offset, metrics).

Her şey yolundaysa - sleep DEFAULT SLEEP, örneğin, bir saniye ve devam edin. Değilse, çıkın — dağıtım başarısız oldu.

Metriğin açıklaması. İşlevin nasıl görünebileceğini görelim compare DSL örneğinde.

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

Diyelim ki hata sayısını karşılaştırıyoruz ve son 5 dakikadaki saniyedeki hata sayısını bilmek istiyoruz.

İki değerimiz var: temel ve kanarya düğümleri. Kanarya düğümünün değeri geçerli olandır. Temel - baseValue diğer herhangi bir kanarya dışı düğümün değeridir. Deneyim ve gözlemlerimize dayanarak belirlediğimiz formüle göre değerleri birbirimizle karşılaştırıyoruz. eğer değer canaryValue kötüyse dağıtım başarısız olur ve geri alırız.

Bütün bunlar neden gerekli?

Bir kişi yüzlerce ve binlerce ölçümü kontrol edemezözellikle hızlı yapmak için. Otomatik karşılaştırma, tüm metrikleri kontrol etmenize yardımcı olur ve sorunları size hızlı bir şekilde bildirir. Uyarının zamanlaması çok önemlidir: son 2 saniye içinde bir şey olduysa, hasar 15 dakika önce olduğu kadar büyük olmayacaktır. Birisi bir sorun fark edip desteğe yazana ve geri almamız için bize destek verene kadar müşteri kaybedebilirsiniz.

İşlem tamamlandıysa ve her şey yolundaysa, diğer tüm düğümleri otomatik olarak konuşlandıracağız. Bu süre zarfında mühendisler hiçbir şey yapmıyor. Ancak kanaryayı fırlattıklarında hangi ölçüleri alacaklarına, karşılaştırmayı ne kadar süreyle yapacaklarına, hangi stratejiyi kullanacaklarına karar verirler.

Sorun varsa kanarya düğümünü otomatik olarak geri alırız, önceki sürümler üzerinde çalışırız ve bulduğumuz hataları düzeltiriz. Metriklere göre, yeni sürümdeki hasarı bulmak ve görmek kolaydır.

engeller

Tabii ki, bunu uygulamak kolay değil. Her şeyden önce, ihtiyacınız var genel izleme sistemi. Mühendislerin kendi ölçütleri, destek ve analistlerin farklı ölçütleri vardır ve işletmelerin üçüncü ölçütleri vardır. Ortak sistem, iş ve geliştirmenin konuştuğu ortak dildir.

Pratikte test edilmesi gerekiyor metrik kararlılık. Kontrol etmek anlamanıza yardımcı olur kaliteyi sağlamak için gereken minimum ölçüm seti nedir?.

Bu nasıl başarılır? Canary-service'i dağıtım sırasında kullanmayın. Eski sürüme, herhangi bir zamanda herhangi bir özel düğümü alabilen ve konuşlandırmadan trafiği azaltabilen belirli bir hizmet ekliyoruz. Karşılaştırdıktan sonra: Hataları inceleriz ve kaliteye ulaştığımızda o çizgiyi ararız.

Kanarya salmalarından nasıl faydalandık?

Hatalardan kaynaklanan hasar yüzdesi en aza indirildi. Dağıtım hatalarının çoğu, bazı verilerdeki veya önceliklerdeki tutarsızlıklardan kaynaklanır. Bu tür hatalar çok daha azdır çünkü sorunu ilk saniyelerde çözebiliriz.

Optimize edilmiş ekip çalışması. Yeni başlayanların “hata yapma hakkı” vardır: hata yapma korkusu olmadan üretime geçebilirler, ek bir inisiyatif, çalışmak için bir teşvik vardır. Bir şeyi kırarlarsa, o zaman kritik olmayacak ve hata yapan kovulmayacak.

otomatik dağıtım. Bu artık eskisi gibi manuel bir süreç değil, gerçek bir otomatik süreç. Ama daha uzun sürüyor.

Vurgulanan önemli metrikler. İşletme ve mühendislerden başlayarak tüm şirket, ürünümüzde neyin gerçekten önemli olduğunu, örneğin kullanıcıların çıkışı ve girişi gibi hangi metriklerin olduğunu anlıyor. Süreci kontrol ediyoruz: Daha verimli para kazandıracak bir sistem oluşturmak için metrikleri test ediyor, yenilerini tanıtıyor, eskilerinin nasıl çalıştığını görüyoruz.

Bize yardımcı olan pek çok harika uygulamamız ve sistemimiz var. Buna rağmen bize yardımcı olacak bir sistemimiz olsa da olmasa da profesyonel olmaya ve işimizi iyi yapmaya çalışıyoruz.

Mühendislik yaklaşımları ve uygulamaları - TechLead Conf'un ana odak noktası. Teknik mükemmelliğe giden yolda başarıya ulaştıysanız ve size bu konuda neyin yardımcı olduğunu anlatmaya hazırsanız, — rapor için başvurmak.
yapmayı planlıyoruz Teknik Lider Konf 8 Haziran Konferansa katılım konusunda karar vermenin artık zor olduğunu anlıyoruz. Ancak aynı zamanda karantinanın profesyonel iletişimi ve gelişimi durdurmak için bir sebep olmadığına inanıyoruz. Bu nedenle, her durumda, teknik liderin görevlerini ve bunları çözme yaklaşımlarını tartışmanın bir yolunu bulacağız - gerekirse çevrimiçi olacağız ve orada ağ kuracağız!

Kaynak: habr.com