Not. tercüme: Ağustos ayının başında Red Hat, hizmet kullanıcılarının önceki aylarda karşılaştığı erişilebilirlik sorunlarının çözümü hakkında kamuoyuna konuştu. (şirketin CoreOS'un satın alınmasıyla birlikte aldığı konteyner görüntüleri kayıt defterine dayanmaktadır). Bu hizmete olan ilginiz ne olursa olsun, şirketin SRE mühendislerinin kazanın nedenlerini teşhis etmek ve ortadan kaldırmak için izlediği yol öğreticidir.
19 Mayıs'ta sabahın erken saatlerinde (Doğu Yaz Saati, EDT) quay.io hizmeti çöktü. Kaza, hem quay.io tüketicilerini hem de quay.io'yu yazılım oluşturmak ve dağıtmak için bir platform olarak kullanan Açık Kaynak projelerini etkiledi. Red Hat her ikisinin de güvenine değer veriyor.
SRE mühendislerinden oluşan bir ekip hemen olaya müdahale etti ve Quay hizmetini mümkün olan en kısa sürede istikrara kavuşturmaya çalıştı. Ancak bunu yaparken müşteriler yeni görseller gönderme yeteneğini kaybettiler ve yalnızca ara sıra mevcut görselleri çekebildiler. Bilinmeyen bir nedenden dolayı quay.io veritabanı, hizmetin tam kapasiteye ölçeklendirilmesinin ardından engellendi.
«Ne değişti?" - bu gibi durumlarda genellikle sorulan ilk soru budur. Sorundan kısa bir süre önce OpenShift Dedicated kümesinin (quay.io'yu çalıştıran) 4.3.19 sürümüne güncellenmeye başladığını fark ettik. quay.io, Red Hat OpenShift Dedicated (OSD) üzerinde çalıştığından, düzenli güncellemeler rutindi ve hiçbir zaman sorun yaratmadı. Üstelik geçtiğimiz altı ay boyunca Quay kümelerini hizmette herhangi bir kesinti olmaksızın birkaç kez yükselttik.
Biz hizmeti geri yüklemeye çalışırken, diğer mühendisler yazılımın önceki sürümüyle yeni bir OSD kümesi hazırlamaya başladılar, böylece bir şey olursa, üzerindeki her şeyi dağıtabilirlerdi.
Sorun kaynağı çözümlemesi
Başarısızlığın ana belirtisi, on binlerce veritabanı bağlantısının çığ gibi büyümesiydi ve bu da MySQL örneğini fiilen çalışamaz hale getirdi. Bu da sorunun teşhis edilmesini zorlaştırdı. SRE ekibinin sorunu değerlendirmesine yardımcı olmak için istemcilerden gelebilecek maksimum bağlantı sayısına bir sınır belirledik. Veritabanında herhangi bir olağandışı trafik fark etmedik: Aslında isteklerin çoğu okundu ve yalnızca birkaçı yazıldı.
Ayrıca veri tabanı trafiğinde bu çığa neden olabilecek bir düzen belirlemeye çalıştık. Ancak günlüklerde herhangi bir model bulamadık. OSD 4.3.18'e sahip yeni kümenin hazır olmasını beklerken quay.io bölmelerini başlatmaya çalışmaya devam ettik. Küme tam kapasiteye ulaştığında veritabanı donuyordu. Bu, tüm quay.io bölmelerine ek olarak RDS örneğinin de yeniden başlatılması gerektiği anlamına geliyordu.
Akşama doğru hizmeti salt okunur modda stabilize ettik ve veritabanı üzerindeki yükü azaltmak için mümkün olduğunca çok sayıda gerekli olmayan işlevi (örneğin, ad alanı çöp toplama) devre dışı bıraktık. Donmalar durduruldu ama nedeni hiçbir zaman bulunamadı. Yeni OSD kümesi hazırdı ve hizmeti, bağlı trafiği taşıdık ve izlemeye devam ettik.
Quay.io yeni OSD kümesinde istikrarlı bir şekilde çalıştı, bu nedenle veritabanı günlüklerine geri döndük ancak tıkanmaları açıklayacak bir korelasyon bulamadık. OpenShift mühendisleri, Red Hat OpenShift 4.3.19'daki değişikliklerin Quay'de sorunlara neden olup olmayacağını anlamak için bizimle birlikte çalıştı. Ancak hiçbir şey bulunamadı ve Sorunu laboratuvar koşullarında yeniden oluşturmak mümkün olmadı.
İkinci başarısızlık
28 Mayıs'ta, EDT öğleden kısa bir süre önce quay.io aynı belirtiyle tekrar çöktü: veritabanı engellendi. Ve yine tüm çabamızı soruşturmaya harcadık. Her şeyden önce hizmeti geri yüklemek gerekiyordu. Fakat bu sefer RDS'yi yeniden başlatmak ve quay.io bölmelerini yeniden başlatmak hiçbir şey yapmadı: Başka bir bağlantı çığı üssü alt üst etti. Ama neden?
Quay Python ile yazılmıştır ve her bölme tek bir yekpare kap gibi çalışır. Konteyner çalışma zamanı birçok paralel görevi aynı anda çalıştırır. Kütüphaneyi kullanıyoruz gevent altında gunicorn Web isteklerini işlemek için. Quay'e bir istek geldiğinde (kendi API'miz veya Docker'ın API'si aracılığıyla), bu isteğe bir gevent çalışanı atanır. Genellikle bu çalışanın veritabanıyla iletişim kurması gerekir. İlk başarısızlıktan sonra gevent çalışanlarının veritabanına varsayılan ayarları kullanarak bağlandığını keşfettik.
Önemli sayıda Quay bölmesi ve saniyede binlerce gelen istek göz önüne alındığında, çok sayıda veritabanı bağlantısı teorik olarak MySQL örneğini bunaltabilir. İzleme sayesinde Quay'in saniyede ortalama 5 bin talebi işlediği biliniyordu. Veritabanına bağlantı sayısı yaklaşık olarak aynıydı. 5 bin bağlantı RDS örneğimizin yetenekleri dahilindeydi (onbinlerce olduğu söylenemez). Bazı nedenlerden dolayı bağlantı sayısında beklenmedik artışlar yaşandıancak gelen taleplerle herhangi bir korelasyon fark etmedik.
Bu sefer sorunun kaynağını bulup ortadan kaldırmaya ve kendimizi yeniden başlatmayla sınırlamamaya kararlıydık. Quay kod tabanına Her çalışanın veritabanına olan bağlantı sayısını sınırlamak için değişiklikler yapıldı Gevent. Bu sayı, konfigürasyonda bir parametre haline geldi: Yeni bir konteyner görüntüsü oluşturmadan, bunu anında değiştirmek mümkün hale geldi. Kaç bağlantının gerçekçi bir şekilde ele alınabileceğini bulmak için, bir hazırlama ortamında birkaç test gerçekleştirdik ve bunun yük testi senaryolarını nasıl etkileyeceğini görmek için farklı değerler ayarladık. Sonuç olarak, keşfedildi ki Bağlantı sayısı 502 bini aştığında Quay 10 hatası vermeye başlıyor.
Bu yeni sürümü hemen üretime dağıttık ve veritabanı bağlantı programını izlemeye başladık. Geçmişte üs yaklaşık 20 dakika sonra kilitleniyordu. Sorunsuz geçen 30 dakikanın ardından umudumuz vardı, bir saat sonra ise güvenimiz vardı. Siteye gelen trafiği yeniden sağladık ve ölüm sonrası analize başladık.
Engellemeye yol açan sorunu atlatmayı başardıktan sonra, gerçek nedenlerini öğrenemedik. OpenShift 4.3.19'daki herhangi bir değişiklikle ilgili olmadığı doğrulandı çünkü aynı şey daha önce Quay ile sorunsuz çalışan 4.3.18 sürümünde de yaşandı.
Açıkça kümede gizlenen başka bir şey vardı.
Detaylı çalışma
Quay.io, veritabanına altı yıl boyunca sorunsuz bir şekilde bağlanmak için varsayılan ayarları kullandı. Ne değişti? Bunca zamandır quay.io'daki trafiğin istikrarlı bir şekilde arttığı açıktır. Bizim durumumuzda, bağlantı çığını tetikleyen bir eşik değerine ulaşılmış gibi görünüyordu. İkinci başarısızlıktan sonra veritabanı günlüklerini incelemeye devam ettik ancak herhangi bir model veya belirgin bir ilişki bulamadık.
Bu arada SRE ekibi, Quay'in talep gözlemlenebilirliği ve genel hizmet sağlığı üzerinde iyileştirmeler üzerinde çalışıyor. Yeni ölçümler ve kontrol panelleri devreye alındı, Quay'in hangi bölümlerinin müşterilerden en çok talep gördüğünü gösteriyor.
Quay.io 9 Haziran'a kadar gayet iyi çalıştı. Bu sabah (EDT) veritabanı bağlantılarının sayısında yine önemli bir artış gördük. Bu sefer kesinti yaşanmadıçünkü yeni parametre bunların sayısını sınırladı ve MySQL verimini aşmalarına izin vermedi. Ancak yaklaşık yarım saat boyunca birçok kullanıcı quay.io'nun yavaş performansını fark etti. Eklenen izleme araçlarını kullanarak mümkün olan tüm verileri hızlı bir şekilde topladık. Aniden bir model ortaya çıktı.
Bağlantılardaki artıştan hemen önce Uygulama Kayıt API'sine çok sayıda istek yapıldı. Uygulama Kaydı, quay.io'nun az bilinen bir özelliğidir. Helm grafikleri ve kapsayıcılar gibi şeyleri zengin meta verilerle saklamanıza olanak tanır. Çoğu quay.io kullanıcısı bu özellik ile çalışmaz ancak Red Hat OpenShift bunu aktif olarak kullanır. OpenShift'in bir parçası olan OperatorHub, tüm operatörleri Uygulama Kayıt Defterinde saklar. Bu operatörler, OpenShift iş yükü ekosisteminin ve iş ortağı merkezli işletim modelinin (2. Gün operasyonları) temelini oluşturur.
Her OpenShift 4 kümesi, kuruluma uygun operatörlerin bir kataloğunu yayınlamak ve halihazırda kurulu olanlara güncellemeler sağlamak için yerleşik OperatorHub'daki operatörleri kullanır. OpenShift 4'ün popülaritesinin artmasıyla birlikte dünya çapında üzerinde bulunan kümelerin sayısı da arttı. Bu kümelerin her biri, quay.io içindeki Uygulama Kayıt Defterini arka uç olarak kullanarak yerleşik OperatorHub'u çalıştırmak için operatör içeriğini indirir. Sorunun kaynağını ararken, OpenShift'in popülaritesi giderek arttıkça, nadiren kullanılan quay.io işlevlerinden birinin yükünün de arttığı gerçeğini gözden kaçırdık..
Uygulama Kaydı istek trafiğinin bazı analizlerini yaptık ve kayıt koduna göz attık. Veritabanına yapılan sorguların en iyi şekilde oluşturulmaması nedeniyle hemen eksiklikler ortaya çıktı. Yük az olduğunda sorun yaratmıyorlardı ancak yük arttığında sorun kaynağı haline geliyorlardı. App Registry'nin artan yüke iyi yanıt vermeyen iki sorunlu uç noktası olduğu ortaya çıktı: Birincisi depodaki tüm paketlerin bir listesini sağladı, ikincisi ise pakete ilişkin tüm blob'ları döndürdü.
Sebeplerin ortadan kaldırılması
Sonraki hafta, Uygulama Kayıt Defterinin kodunu ve ortamını optimize etmeye çalıştık. Açıkça etkisiz olan SQL sorguları yeniden düzenlendi ve gereksiz komut çağrıları ortadan kaldırıldı tar (bloblar her alındığında çalıştırıldı), mümkün olan her yere önbellekleme eklendi. Daha sonra kapsamlı performans testleri gerçekleştirdik ve Uygulama Kayıt Defterinin hızını değişikliklerden önce ve sonra karşılaştırdık.
Daha önce yarım dakikaya kadar süren API istekleri artık milisaniyeler içinde tamamlanıyor. Sonraki hafta değişiklikleri üretime uyguladık ve o zamandan beri quay.io istikrarlı bir şekilde çalışıyor. Bu süre zarfında App Registry uç noktasında trafikte birkaç keskin artış yaşandı, ancak yapılan iyileştirmeler veritabanı kesintilerini önledi.
Ne öğrendik?
Herhangi bir hizmetin kesinti süresini önlemeye çalıştığı açıktır. Bizim durumumuzda, son kesintilerin quay.io'yu daha iyi hale getirmeye yardımcı olduğuna inanıyoruz. Paylaşmak istediğimiz birkaç önemli ders öğrendik:
- Hizmetinizi kimin ve nasıl kullandığına ilişkin veriler asla gereksiz değildir. Quay "yeni çalıştığı" için trafiği optimize etmek ve yükü yönetmek için asla zaman harcamak zorunda kalmadık. Tüm bunlar, hizmetin süresiz olarak ölçeklenebileceği sahte bir güvenlik duygusu yarattı.
- Hizmet çöktüğünde, onu tekrar çalışır duruma getirmek en önemli önceliktir.. Quay, ilk kesinti sırasında kilitli bir veritabanından muzdarip olmaya devam ettiğinden, standart prosedürlerimiz amaçlanan etkiyi yaratmadı ve bunları kullanarak hizmeti geri yükleyemedik. Bu, tüm çabaları işlevselliği geri yüklemeye odaklamak yerine, temel nedeni bulma umuduyla verileri analiz etmek ve toplamak için zaman harcanması gereken bir duruma yol açtı.
- Her hizmet özelliğinin etkisini değerlendirin. Müşteriler Uygulama Kaydını nadiren kullanıyordu, bu nedenle ekibimiz için bir öncelik değildi. Bazı ürün özellikleri çok az kullanıldığında, hataları nadiren ortaya çıkar ve geliştiriciler kodu izlemeyi bırakır. Bunun böyle olması gerektiği yanılgısına kapılmak kolaydır; ta ki aniden bu işlev kendisini büyük bir olayın merkezinde bulana kadar.
Sırada ne var?
Hizmetin istikrarını sağlamak için çalışmalar hiç durmuyor ve sürekli geliştiriyoruz. Quay.io'daki trafik hacimleri artmaya devam ederken, müşterilerimizin güvenini kazanmak için elimizden gelen her şeyi yapma sorumluluğumuzun olduğunun bilincindeyiz. Bu nedenle şu anda aşağıdaki görevler üzerinde çalışıyoruz:
- Birincil RDS örneğinde sorun olması durumunda hizmetin uygun trafiği işlemesine yardımcı olmak için salt okunur veritabanı kopyalarını dağıtın.
- Bir RDS örneğini güncelleme. Mevcut sürümün kendisi sorun değil. Bunun yerine, (başarısızlık sırasında takip ettiğimiz) yanlış izi ortadan kaldırmak istiyoruz; Yazılımın güncel tutulması ileride yaşanabilecek kesintilerde bir etkeni daha ortadan kaldıracaktır.
- Kümenin tamamında ek önbelleğe alma. Önbelleğe almanın veritabanı üzerindeki yükü azaltabileceği alanları aramaya devam ediyoruz.
- Quay.io'ya kimin ve neden bağlandığını görmek için bir web uygulaması güvenlik duvarı (WAF) ekleme.
- Bir sonraki sürümden itibaren Red Hat OpenShift kümeleri, Uygulama Kayıt Defterini terk edecek ve yerine quay.io'da bulunan konteyner görüntülerine dayalı Operatör Katalogları'nı kullanacak.
- Uygulama Kayıt Defteri'nin uzun vadeli değişimi, Açık Konteyner Girişimi (OCI) yapı spesifikasyonlarına yönelik destek olabilir. Şu anda yerel Quay işlevi olarak uygulanıyor ve spesifikasyonun kendisi tamamlandığında kullanıcıların kullanımına sunulacak.
Yukarıdakilerin tümü, küçük bir "startup tarzı" ekipten olgun, SRE odaklı bir platforma geçerken Red Hat'in quay.io'ya devam eden yatırımının bir parçasıdır. Müşterilerimizin çoğunun (Red Hat dahil!) günlük işlerinde quay.io'ya güvendiğini biliyoruz ve son kesintiler ve devam eden iyileştirme çabaları konusunda mümkün olduğunca şeffaf olmaya çalışıyoruz.
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- «'.
Kaynak: habr.com