Netflix, İnternet televizyonu pazarının lideridir - bu segmenti yaratan ve aktif olarak geliştiren şirket. Netflix, yalnızca dünyanın hemen her köşesinden ve ekranı olan her cihazdan erişilebilen kapsamlı film ve dizi kataloğuyla değil, aynı zamanda güvenilir altyapısı ve benzersiz mühendislik kültürüyle de tanınıyor.
Netflix'in karmaşık sistemleri geliştirmeye ve desteklemeye yönelik yaklaşımının net bir örneği DevOops 2019'da sunuldu - Netflix'te Geliştirme Direktörü. Nizhny Novgorod Devlet Üniversitesi Hesaplamalı Matematik ve Matematik Fakültesi mezunu. Lobachevsky, Sergey Netflix'teki Open Connect - CDN ekibinin ilk mühendislerinden biri. Video verilerini izlemek ve analiz etmek için sistemler kurdu, İnternet bağlantı hızını değerlendirmek için popüler bir hizmet olan FAST.com'u başlattı ve son birkaç yıldır Netflix uygulamasının kullanıcılar için mümkün olduğu kadar hızlı çalışmasını sağlamak için İnternet isteklerini optimize etmek üzerinde çalışıyor.
Rapor, konferans katılımcılarından en iyi değerlendirmeleri aldı ve sizin için bir metin versiyonu hazırladık.
Sergei raporunda ayrıntılı olarak konuştu
- istemci ile sunucu arasındaki İnternet isteklerinin gecikmesini neyin etkilediği hakkında;
- bu gecikmenin nasıl azaltılacağı;
- hataya dayanıklı sistemlerin nasıl tasarlanacağı, sürdürüleceği ve izleneceği;
- kısa sürede ve iş için minimum riskle sonuçlara nasıl ulaşılacağı;
- Sonuçların nasıl analiz edileceği ve hatalardan nasıl ders alınacağı.
Bu soruların yanıtlarına yalnızca büyük şirketlerde çalışanların ihtiyacı yok.
Sunulan ilke ve teknikler, İnternet ürünlerini geliştiren ve destekleyen herkes tarafından bilinmeli ve uygulanmalıdır.
Sırada konuşmacının bakış açısından anlatım yer alıyor.
İnternet hızının önemi
İnternet isteklerinin hızı doğrudan işle ilgilidir. Alışveriş Sektörünü Düşünün: 2009'da Amazon 100 ms'lik bir gecikmenin satışlarda %1'lik bir kayıpla sonuçlanacağı.
Giderek daha fazla mobil cihaz var, bunu mobil siteler ve uygulamalar takip ediyor. Sayfanızın yüklenmesi 3 saniyeden uzun sürerse kullanıcılarınızın yaklaşık yarısını kaybedersiniz. İLE Google, sayfanızın arama sonuçlarındaki yüklenme hızını dikkate alır: sayfa ne kadar hızlı olursa Google'daki konumu da o kadar yüksek olur.
Gecikmenin kritik olduğu finansal kurumlarda bağlantı hızı da önemlidir. 2015 yılında Hibernia Ağları Şehirler arasındaki gecikmeyi 400 ms azaltmak için New York ile Londra arasında 6 milyon dolarlık bir kablo hattı. 66 ms gecikme azalması için 1 milyon dolar hayal edin!
Göre 5 Mbit/s'nin üzerindeki bağlantı hızları artık tipik bir web sitesinin yükleme hızını doğrudan etkilememektedir. Ancak bağlantı gecikmesi ile sayfa yükleme hızı arasında doğrusal bir ilişki vardır:
Ancak Netflix tipik bir ürün değil. Gecikme ve hızın kullanıcı üzerindeki etkisi aktif bir analiz ve geliştirme alanıdır. Gecikmeye bağlı uygulama yükleme ve içerik seçimi vardır, ancak statik öğelerin yüklenmesi ve akış da bağlantı hızına bağlıdır. Kullanıcı deneyimini etkileyen temel faktörlerin analiz edilmesi ve optimize edilmesi, Netflix'teki birçok ekibin aktif bir geliştirme alanıdır. Hedeflerden biri Netflix cihazları ile bulut altyapısı arasındaki istek gecikmesini azaltmaktır.
Raporda Netflix altyapısı örneğini kullanarak özellikle gecikmeyi azaltmaya odaklanacağız. Karmaşık dağıtılmış sistemlerin tasarım, geliştirme ve işletim süreçlerine nasıl yaklaşılacağını pratik bir bakış açısıyla ele alalım ve operasyonel sorunları ve arızaları teşhis etmek yerine inovasyon ve sonuçlara nasıl zaman ayıracağımızı düşünelim.
Netflix'in İçinde
Netflix uygulamaları binlerce farklı cihaz tarafından desteklenmektedir. Bu uygulamalar, her biri ayrı istemci sürümleri oluşturan dört farklı ekip tarafından geliştirilmektedir. AndroidiOS, TV ve web tarayıcıları dahil olmak üzere birçok platformda kullanıyoruz. Ayrıca kullanıcı deneyimini iyileştirmek ve kişiselleştirmek için de yoğun çaba sarf ediyoruz. Bunu başarmak için yüzlerce A/B testini eş zamanlı olarak yürütüyoruz.
Kişiselleştirme, AWS bulutunda kişiselleştirilmiş kullanıcı verileri, sorgu gönderimi, telemetri, Büyük Veri ve Kodlama sağlayan yüzlerce mikro hizmet tarafından desteklenir. Trafik görselleştirmesi şuna benzer:
Solda giriş noktası var ve trafik, farklı arka uç ekipleri tarafından desteklenen yüzlerce mikro hizmet arasında dağıtılıyor.
Altyapımızın bir diğer önemli bileşeni, son kullanıcıya statik içerik (videolar, resimler, istemci kodu vb.) sunan Open Connect CDN'dir. CDN, özel sunucularda (OCA - Open Connect Appliance) bulunur. İçinde NGINX ve bir dizi hizmetle birlikte optimize edilmiş FreeBSD çalıştıran bir dizi SSD ve HDD sürücüsü vardır. Böyle bir CDN sunucusunun kullanıcılara mümkün olduğunca fazla veri gönderebilmesi için donanım ve yazılım bileşenlerini tasarlıyor ve optimize ediyoruz.
Bu sunucuların İnternet trafiği değişim noktasındaki (Internet eXchange - IX) “duvarı” şöyle görünür:
Internet Exchange, Internet servis sağlayıcılarına ve içerik sağlayıcılarına, Internet üzerinde daha doğrudan veri alışverişi yapmak üzere birbirleriyle "bağlantı kurma" yeteneği sağlar. Dünya çapında sunucularımızın kurulu olduğu yaklaşık 70-80 İnternet Exchange noktası bulunmaktadır ve bunların kurulumunu ve bakımını bağımsız olarak gerçekleştirmekteyiz:
Ayrıca, İnternet sağlayıcılarına doğrudan ağlarına kurdukları sunucuları da sunarak Netflix trafiğinin yerelleştirilmesini ve kullanıcılar için yayın kalitesini iyileştiriyoruz:
İstemcilerden CDN sunucularına video isteklerinin gönderilmesinden ve ayrıca sunucuların kendilerinin yapılandırılmasından (içerik, program kodu, ayarlar vb.) güncellenmesinden bir dizi AWS hizmeti sorumludur. İkincisi için ayrıca İnternet Exchange noktalarındaki sunucuları AWS'ye bağlayan bir omurga ağı da oluşturduk. Omurga ağı, ihtiyaçlarımıza göre tasarlayıp yapılandırabileceğimiz küresel bir fiber optik kablo ve yönlendirici ağıdır.
Üzerinde CDN altyapımız, yoğun saatlerde dünyadaki İnternet trafiğinin yaklaşık ⅛'ünü ve Netflix'in en uzun süre hizmet verdiği Kuzey Amerika'daki trafiğin ⅓'ünü sağlıyor. Etkileyici rakamlar, ancak benim için en şaşırtıcı başarılardan biri, tüm CDN sisteminin 150 kişiden az bir ekip tarafından geliştirilmesi ve sürdürülmesidir.
Başlangıçta CDN altyapısı video verilerini iletmek için tasarlandı. Ancak zamanla bunu AWS bulutundaki istemcilerden gelen dinamik istekleri optimize etmek için de kullanabileceğimizi fark ettik.
İnternet hızlandırma hakkında
Bugün Netflix'in 3 AWS bölgesi var ve buluta yönelik isteklerin gecikmesi, müşterinin en yakın bölgeden ne kadar uzakta olduğuna bağlı olacak. Aynı zamanda statik içerik sunmak için kullanılan birçok CDN sunucumuz var. Dinamik sorguları hızlandırmak için bu çerçeveyi kullanmanın bir yolu var mı? Ancak ne yazık ki bu istekleri önbelleğe almak imkansızdır; API'ler kişiselleştirilmiştir ve her sonuç benzersizdir.
CDN sunucusunda bir proxy oluşturalım ve onun üzerinden trafik göndermeye başlayalım. Daha hızlı mı olacak?
malzeme
Ağ protokollerinin nasıl çalıştığını hatırlayalım. Günümüzde İnternet'teki trafiğin çoğu, alt katman protokolleri TCP ve TLS'ye bağlı olan HTTP'leri kullanıyor. Bir istemcinin sunucuya bağlanabilmesi için el sıkışma yapması ve güvenli bir bağlantı kurabilmesi için istemcinin sunucuyla üç kez mesaj alışverişi yapması ve en az bir kez daha veri aktarımı yapması gerekir. Gidiş-dönüş başına gecikme (RTT) 100 ms olduğundan, ilk veri bitini almamız 400 ms sürecektir:
Sertifikaları CDN sunucusuna yerleştirirsek, CDN daha yakınsa istemci ile sunucu arasındaki el sıkışma süresi önemli ölçüde azaltılabilir. CDN sunucusunun gecikmesinin 30 ms olduğunu varsayalım. Daha sonra ilk bitin alınması 220 ms sürecektir:
Ancak avantajları burada bitmiyor. Bir bağlantı kurulduğunda TCP, tıkanıklık penceresini (bu bağlantı üzerinden paralel olarak iletebileceği bilgi miktarını) artırır. Bir veri paketi kaybolursa, TCP protokolünün klasik uygulamaları (TCP New Reno gibi) açık "pencereyi" yarı yarıya azaltır. Tıkanıklık penceresinin büyümesi ve kayıptan kurtulma hızı yine sunucudaki gecikmeye (RTT) bağlıdır. Bu bağlantı yalnızca CDN sunucusuna kadar giderse bu kurtarma daha hızlı olacaktır. Aynı zamanda paket kaybı, özellikle kablosuz ağlar için standart bir olgudur.
Kullanıcılardan gelen trafik nedeniyle özellikle yoğun saatlerde İnternet bant genişliği azalabilir ve bu da trafik sıkışıklığına neden olabilir. Ancak internette bazı isteklere diğerlerine göre öncelik vermenin bir yolu yoktur. Örneğin, ağı yükleyen "ağır" veri akışları yerine küçük ve gecikmeye duyarlı isteklere öncelik verin. Ancak bizim durumumuzda, kendi omurga ağımıza sahip olmak, bunu istek yolunun CDN ile bulut arasındaki kısmında yapmamıza olanak tanır ve bunu tamamen yapılandırabiliriz. Küçük ve gecikmeye duyarlı paketlere öncelik verildiğinden ve büyük veri akışlarının biraz daha geç gittiğinden emin olabilirsiniz. CDN müşteriye ne kadar yakınsa verimlilik o kadar artar.
Uygulama düzeyindeki protokollerin (OSI Düzey 7) gecikme üzerinde de etkisi vardır. HTTP/2 gibi yeni protokoller paralel isteklerin performansını optimize eder. Ancak yeni protokolleri desteklemeyen eski cihazlara sahip Netflix istemcilerimiz var. Tüm istemciler güncellenemez veya en iyi şekilde yapılandırılamaz. Aynı zamanda, CDN proxy'si ile bulut arasında tam kontrol vardır ve yeni, optimum protokolleri ve ayarları kullanma yeteneği vardır. Eski protokollerin etkisiz kısmı yalnızca istemci ile CDN sunucusu arasında çalışacaktır. Ayrıca, CDN ile bulut arasında önceden kurulmuş bir bağlantı üzerinden multipleks isteklerde bulunarak TCP düzeyinde bağlantı kullanımını iyileştirebiliriz:
Biz ölçeriz
Teorinin iyileştirmeler vaat etmesine rağmen, sistemi hemen üretime geçirmek için acele etmiyoruz. Bunun yerine öncelikle fikrin pratikte işe yarayacağını kanıtlamalıyız. Bunu yapmak için birkaç soruyu yanıtlamanız gerekir:
- hız: Proxy daha hızlı mı olacak?
- Güvenilirlik: Daha sık mı kırılacak?
- Karmaşa: Uygulamalara nasıl entegre edilir?
- Maliyet: Ek altyapıyı dağıtmanın maliyeti nedir?
İlk noktayı değerlendirme yaklaşımımızı ayrıntılı olarak ele alalım. Geri kalanı da benzer şekilde ele alınır.
İsteklerin hızını analiz etmek için, geliştirme için çok fazla zaman harcamadan ve üretimi kesintiye uğratmadan, tüm kullanıcılara ait verileri elde etmek istiyoruz. Bunun için birkaç yaklaşım var:
- RUM veya pasif istek ölçümü. Kullanıcılardan gelen mevcut isteklerin yürütme süresini ölçüyoruz ve tam kullanıcı kapsamı sağlıyoruz. Dezavantajı ise sinyalin pek çok faktörden dolayı, örneğin farklı istek boyutları, sunucu ve istemcideki işlem süreleri nedeniyle çok kararlı olmamasıdır. Ayrıca yeni bir konfigürasyonu üretimde herhangi bir etkisi olmadan test edemezsiniz.
- Laboratuvar testleri. İstemcileri simüle eden özel sunucular ve altyapı. Onların yardımıyla gerekli testleri yapıyoruz. Bu şekilde ölçüm sonuçları üzerinde tam kontrole ve net bir sinyale sahip oluyoruz. Ancak cihazların ve kullanıcı konumlarının tam kapsamı yoktur (özellikle dünya çapında hizmet ve binlerce cihaz modeli için destek söz konusu olduğunda).
Her iki yöntemin avantajlarını nasıl birleştirebilirsiniz?
Ekibimiz bir çözüm buldu. Uygulamamıza yerleştirdiğimiz küçük bir kod parçası (bir örnek) yazdık. Problar cihazlarımızdan tam kontrollü ağ testleri yapmamıza olanak sağlar. Bu şekilde çalışır:
- Uygulamayı yükleyip ilk aktiviteyi tamamladıktan kısa bir süre sonra problarımızı çalıştırıyoruz.
- İstemci sunucuya bir istekte bulunur ve test için bir "reçete" alır. Tarif, HTTP isteğinin yapılması gereken URL'lerin listesidir. Ayrıca tarif, istek parametrelerini de yapılandırır: istekler arasındaki gecikmeler, istenen veri miktarı, HTTP(ler) başlıkları vb. Aynı zamanda birkaç farklı tarifi paralel olarak test edebiliriz; bir konfigürasyon talep ederken hangi tarifin yayınlanacağını rastgele belirleriz.
- Prob başlatma zamanı, istemcideki ağ kaynaklarının etkin kullanımıyla çelişmeyecek şekilde seçilir. Temel olarak zaman, istemci aktif olmadığında seçilir.
- Tarifi aldıktan sonra müşteri, URL'lerin her birine paralel olarak istekte bulunur. Adreslerin her birine yapılan istek tekrarlanabilir - sözde. "nabız". İlk atışta bağlantı kurmanın ve veri indirmenin ne kadar sürdüğünü ölçüyoruz. İkinci darbede, önceden kurulmuş bir bağlantı üzerinden veri yüklemek için gereken süreyi ölçeriz. Üçüncüsünden önce bir gecikme ayarlayabilir ve yeniden bağlantı kurma hızını vb. ölçebiliriz.
Test sırasında cihazın elde edebileceği tüm parametreleri ölçüyoruz:
- DNS istek süresi;
- TCP bağlantı kurulum süresi;
- TLS bağlantısı kurulum süresi;
- verinin ilk baytını alma zamanı;
- toplam yükleme süresi;
- durum sonuç kodu.
- Tüm darbeler tamamlandıktan sonra örnek, analiz için tüm ölçümleri yükler.
Anahtar noktalar istemcideki mantığa minimum düzeyde bağımlılık, sunucuda veri işleme ve paralel isteklerin ölçümüdür. Böylece sorgu performansını etkileyen çeşitli faktörlerin etkisini izole edip test edebiliyor, bunları tek bir tarifte değiştirebiliyor ve gerçek müşterilerden sonuçlar elde edebiliyoruz.
Bu altyapının yalnızca sorgu performansı analizinden daha fazlası için yararlı olduğu kanıtlanmıştır. Şu anda dünyanın her köşesinden veri alan ve tam cihaz kapsamına sahip, saniyede 14'den fazla örnekle 6000 aktif tarifimiz var. Netflix benzer bir hizmeti üçüncü bir taraftan satın alsaydı, bunun maliyeti yılda milyonlarca dolara mal olurdu ve kapsama alanı çok daha kötü olurdu.
Teorinin pratikte test edilmesi: prototip
Böyle bir sistemle CDN proxy'lerinin istek gecikmesi üzerindeki etkinliğini değerlendirebildik. Şimdi ihtiyacınız var:
- bir proxy prototipi oluşturun;
- prototipi bir CDN'ye yerleştirin;
- istemcilerin belirli bir CDN sunucusundaki proxy'ye nasıl yönlendirileceğini belirlemek;
- Performansı proxy olmadan AWS'deki isteklerle karşılaştırın.
Görev, önerilen çözümün etkinliğini mümkün olduğu kadar çabuk değerlendirmektir. İyi ağ kitaplıklarının mevcut olması nedeniyle prototipi uygulamak için Go'yu seçtik. Bağımlılıkları en aza indirmek ve entegrasyonu basitleştirmek için her CDN sunucusuna prototip proxy'yi statik bir ikili dosya olarak kurduk. İlk uygulamada mümkün olduğunca standart bileşenler kullandık ve HTTP/2 bağlantı havuzu oluşturma ve istek çoğullama için küçük değişiklikler yaptık.
AWS bölgeleri arasında denge kurmak için, istemcileri dengelemek için kullanılanla aynı olan coğrafi bir DNS veritabanı kullandık. İstemci için bir CDN sunucusu seçmek amacıyla Internet Exchange (IX) sunucuları için TCP Anycast kullanıyoruz. Bu seçenekte tüm CDN sunucuları için tek IP adresi kullanıyoruz ve istemci en az IP hop sayısına sahip CDN sunucusuna yönlendirilecek. İnternet sağlayıcıları (ISP'ler) tarafından kurulan CDN sunucularında, TCP Anycast'i yapılandırmak için yönlendirici üzerinde kontrolümüz yoktur, bu nedenle kullanırız. , müşterileri video akışı için İnternet sağlayıcılarına yönlendirir.
Dolayısıyla üç tür istek yolumuz var: açık İnternet üzerinden buluta, IX'taki bir CDN sunucusu üzerinden veya bir İnternet sağlayıcısında bulunan bir CDN sunucusu aracılığıyla. Amacımız, isteklerin üretime nasıl gönderildiğiyle karşılaştırıldığında hangi yolun daha iyi olduğunu ve proxy'nin avantajının ne olduğunu anlamaktır. Bunu yapmak için aşağıdaki gibi bir örnekleme sistemi kullanıyoruz:
Yolların her biri ayrı bir hedef haline geliyor ve ne kadar zamanımız olduğuna bakıyoruz. Analiz için proxy sonuçlarını tek bir grupta birleştiriyoruz (IX ve ISP proxy'leri arasındaki en iyi zamanı seçiyoruz) ve bunları proxy olmadan buluta yapılan isteklerin zamanıyla karşılaştırıyoruz:
Gördüğünüz gibi sonuçlar karışıktı - çoğu durumda proxy iyi bir hızlanma sağlıyor, ancak durumun önemli ölçüde kötüleşeceği yeterli sayıda müşteri de var.
Sonuç olarak birkaç önemli şey yaptık:
- İstemcilerden buluta gelen isteklerin beklenen performansını bir CDN proxy aracılığıyla değerlendirdik.
- Gerçek müşterilerden, her tür cihazdan veri aldık.
- Teorinin %100 doğrulanmadığını ve CDN proxy'li ilk teklifin bizim için işe yaramayacağını fark ettik.
- Risk almadık; müşterilerimiz için üretim konfigürasyonlarını değiştirmedik.
- Hiçbir şey kırılmadı.
Prototip 2.0
Böylece çizim tahtasına geri dönün ve işlemi tekrar tekrarlayın.
Buradaki fikir, %100 proxy kullanmak yerine, her müşteri için en hızlı yolu belirleyeceğiz ve istekleri oraya göndereceğiz - yani müşteri yönlendirme adı verilen şeyi yapacağız.
Bu nasıl uygulanır? Sunucu tarafında mantığı kullanamıyoruz çünkü... Amaç bu sunucuya bağlanmaktır. Bunu istemcide yapmanın bir yolu olmalı. Ve ideal olarak, çok sayıda istemci platformuyla entegrasyon sorununu çözmemek için bunu minimum miktarda karmaşık mantıkla yapın.
Cevap DNS kullanmaktır. Bizim durumumuzda kendi DNS altyapımız var ve sunucularımızın otoriter olacağı bir domain bölgesi kurabiliyoruz. Bu şekilde çalışır:
- İstemci, api.netflix.xom gibi bir ana bilgisayarı kullanarak DNS sunucusuna istekte bulunur.
- İstek DNS sunucumuza ulaşır
- DNS sunucusu bu istemci için hangi yolun en hızlı olduğunu bilir ve ilgili IP adresini verir.
Çözümün ek bir karmaşıklığı daha var: Otoriter DNS sağlayıcıları müşterinin IP adresini görmüyor ve yalnızca istemcinin kullandığı özyinelemeli çözümleyicinin IP adresini okuyabiliyor.
Sonuç olarak, otoriter çözümleyicimiz bireysel bir müşteri için değil, özyinelemeli çözümleyiciye dayalı bir müşteri grubu için karar vermelidir.
Çözüm için, aynı örnekleri kullanırız, özyinelemeli çözümleyicilerin her biri için müşterilerden gelen ölçüm sonuçlarını toplarız ve bu grubu nereye göndereceğimize karar veririz - TCP Anycast kullanan IX üzerinden bir proxy, bir ISP proxy'si aracılığıyla veya doğrudan buluta.
Aşağıdaki sistemi elde ediyoruz:
Ortaya çıkan DNS yönlendirme modeli, istemcilerden buluta olan bağlantıların hızına ilişkin geçmiş gözlemlere dayanarak istemcileri yönlendirmenize olanak tanır.
Tekrar sorulması gereken soru şu: Bu yaklaşım ne kadar etkili olacak? Cevaplamak için yine prob sistemimizi kullanıyoruz. Bu nedenle, hedeflerden birinin DNS yönlendirmesinden gelen yönü takip ettiği, diğerinin ise doğrudan buluta (mevcut üretim) gittiği sunucu yapılandırmasını yapılandırıyoruz.
Sonuç olarak, sonuçları karşılaştırırız ve etkililiğe ilişkin bir değerlendirme elde ederiz:
Sonuç olarak birkaç önemli şey öğrendik:
- İstemcilerden buluta gelen isteklerin beklenen performansını DNS Direksiyonunu kullanarak değerlendirdik.
- Gerçek müşterilerden, her tür cihazdan veri aldık.
- Önerilen fikrin etkinliği kanıtlanmıştır.
- Risk almadık; müşterilerimiz için üretim konfigürasyonlarını değiştirmedik.
- Hiçbir şey kırılmadı.
Şimdi işin zor kısmına gelince; onu üretime alıyoruz
Artık kolay kısım bitti; çalışan bir prototip var. Artık işin zor kısmı, Netflix trafiğinin tamamı için 150 milyon kullanıcıya, binlerce cihaza, yüzlerce mikro hizmete ve sürekli değişen ürün ve altyapıya dağıtılacak bir çözüm başlatmak. Netflix sunucuları saniyede milyonlarca istek alır ve dikkatsiz eylemlerle hizmeti bozmak kolaydır. Aynı zamanda trafiği, İnternet'teki binlerce CDN sunucusu üzerinden, bir şeylerin sürekli olarak değiştiği ve en uygunsuz anda bozulduğu dinamik olarak yönlendirmek istiyoruz.
Tüm bunlarla birlikte ekipte sistemin geliştirilmesinden, devreye alınmasından ve tam desteğinden sorumlu 3 mühendis bulunmaktadır.
Bu nedenle dinlendirici ve sağlıklı uykudan bahsetmeye devam edeceğiz.
Geliştirmeye nasıl devam edilir ve tüm zamanınızı desteğe harcamazsınız? Yaklaşımımız 3 prensibe dayanmaktadır:
- Arızaların potansiyel ölçeğini (patlama yarıçapı) azaltıyoruz.
- Sürprizlere hazırlanıyoruz - testlere ve kişisel deneyime rağmen bir şeyin kırılmasını bekliyoruz.
- Zarif bozulma: Bir şey düzgün çalışmıyorsa, en verimli şekilde olmasa bile otomatik olarak düzeltilmelidir.
Bizim durumumuzda soruna bu yaklaşımla basit ve etkili bir çözüm bulabileceğimiz ve sistem desteğini önemli ölçüde basitleştirebileceğimiz ortaya çıktı. İstemciye küçük bir kod parçası ekleyebileceğimizi ve bağlantı sorunlarından kaynaklanan ağ isteği hatalarını izleyebileceğimizi fark ettik. Ağ hatası durumunda doğrudan buluta geri dönüş yapıyoruz. Bu çözüm, müşteri ekipleri için önemli bir çaba gerektirmiyor ancak bizim için beklenmedik arıza ve sürpriz riskini büyük ölçüde azaltıyor.
Elbette geri dönüşe rağmen geliştirme sırasında net bir disiplin izliyoruz:
- Örnek test.
- A/B testi veya Kanaryalar.
- Aşamalı kullanıma sunma.
Örneklerle yaklaşım açıklanmıştır; değişiklikler ilk önce özelleştirilmiş bir tarif kullanılarak test edilmiştir.
Kanarya testi için, sistemin değişikliklerden önce ve sonra nasıl çalıştığını karşılaştırabileceğimiz karşılaştırılabilir sunucu çiftleri almamız gerekiyor. Bunu yapmak için birçok CDN sitemizden karşılaştırılabilir trafik alan sunucu çiftlerini seçiyoruz:
Daha sonra değişiklikleri içeren yapıyı Canary sunucusuna yüklüyoruz. Sonuçları değerlendirmek için yaklaşık 100-150 metriği Kontrol sunucuları örneğiyle karşılaştıran bir sistem çalıştırıyoruz:
Canary testi başarılı olursa, bunu yavaş yavaş, dalgalar halinde yayınlarız. Her sitedeki sunucuları aynı anda güncellemiyoruz; sorunlar nedeniyle bir sitenin tamamını kaybetmek, kullanıcılar için hizmet üzerinde farklı konumlardaki aynı sayıda sunucuyu kaybetmekten daha önemli bir etkiye sahiptir.
Genel olarak bu yaklaşımın etkinliği ve güvenliği, toplanan ölçümlerin miktarına ve kalitesine bağlıdır. Sorgu hızlandırma sistemimiz için tüm olası bileşenlerden ölçümler topluyoruz:
- istemcilerden - oturum ve istek sayısı, geri dönüş oranları;
- vekil - isteklerin sayısı ve zamanına ilişkin istatistikler;
- DNS - isteklerin sayısı ve sonuçları;
- bulut kenarı - buluttaki isteklerin işlenmesi için sayı ve zaman.
Tüm bunlar tek bir işlem hattında toplanır ve ihtiyaçlara bağlı olarak hangi metriklerin gerçek zamanlı analize, hangilerinin daha ayrıntılı teşhis için Elasticsearch veya Büyük Veri'ye gönderileceğine karar veririz.
Biz izliyoruz
Bizim durumumuzda istemci ve sunucu arasındaki isteklerin kritik yolunda değişiklikler yapıyoruz. Aynı zamanda istemcideki, sunucudaki ve İnternet üzerinden giden farklı bileşenlerin sayısı da çok fazladır. Düzinelerce ekibin çalışması ve ekosistemdeki doğal değişiklikler sırasında istemci ve sunucuda sürekli değişiklikler meydana gelir. Ortadayız; sorunları teşhis ederken bizim de dahil olmamız ihtimali yüksektir. Bu nedenle, sorunları hızlı bir şekilde izole etmek için ölçümlerin nasıl tanımlanacağını, toplanacağını ve analiz edileceğini açıkça anlamamız gerekiyor.
İdeal olarak, tüm ölçüm ve filtre türlerine gerçek zamanlı olarak tam erişim. Ancak çok fazla ölçüm var, dolayısıyla maliyet sorunu ortaya çıkıyor. Bizim durumumuzda metrikleri ve geliştirme araçlarını şu şekilde ayırıyoruz:
Sorunları tespit etmek ve önceliklendirmek için kendi açık kaynaklı gerçek zamanlı sistemimizi kullanıyoruz и - görselleştirme için. Toplu metrikleri bellekte saklar, güvenilirdir ve uyarı sistemiyle bütünleşir. Yerelleştirme ve teşhis için Elasticsearch ve Kibana'daki günlüklere erişimimiz var. İstatistiksel analiz ve modelleme için Tableau'da büyük veri ve görselleştirme kullanıyoruz.
Görünüşe göre bu yaklaşımla çalışmak çok zor. Ancak metrikleri ve araçları hiyerarşik olarak düzenleyerek bir sorunu hızlı bir şekilde analiz edebilir, sorunun türünü belirleyebilir ve ardından ayrıntılı metrikleri derinlemesine inceleyebiliriz. Genelde arızanın kaynağını tespit etmek için yaklaşık 1-2 dakika harcıyoruz. Bundan sonra, teşhis konusunda belirli bir ekiple çalışıyoruz - onlarca dakikadan birkaç saate kadar.
Teşhis hızlı bir şekilde yapılsa bile bunun sık sık olmasını istemiyoruz. İdeal olarak, yalnızca hizmet üzerinde önemli bir etki olduğunda kritik bir uyarı alırız. Sorgu hızlandırma sistemimiz için aşağıdakileri bildirecek yalnızca 2 uyarımız var:
- Müşteri Geri Dönüş yüzdesi - müşteri davranışının değerlendirilmesi;
- yüzde Prob hataları - ağ bileşenlerinin kararlılık verileri.
Bu kritik uyarılar, sistemin kullanıcıların çoğunluğu için çalışıp çalışmadığını izler. İstek hızlandırmayı alamadıklarında kaç müşterinin geri dönüşü kullandığına bakıyoruz. Sistemde bir sürü değişiklik olmasına rağmen haftada ortalama 1'den az kritik uyarı alıyoruz. Bu bizim için neden yeterli?
- Proxy'miz çalışmazsa bir istemci geri dönüşü vardır.
- Sorunlara müdahale eden otomatik direksiyon sistemi bulunmaktadır.
İkincisi hakkında daha fazla ayrıntı. Deneme sistemimiz ve istemciden buluta giden istekler için en uygun yolu otomatik olarak belirleyen sistem, bazı sorunlarla otomatik olarak başa çıkmamıza olanak tanır.
Örnek yapılandırmamıza ve 3 yol kategorimize dönelim. Yükleme süresine ek olarak teslimat gerçeğine de bakabiliriz. Verileri yüklemek mümkün değilse, farklı yollardaki sonuçlara bakarak nerede ve neyin bozulduğunu ve istek yolunu değiştirerek bunu otomatik olarak düzeltip düzeltemeyeceğimizi belirleyebiliriz.
Örnekler:
Bu süreç otomatikleştirilebilir. Direksiyon sistemine dahil edin. Performans ve güvenilirlik sorunlarına nasıl yanıt vereceğini öğretin. Bir şeyler bozulmaya başlarsa, daha iyi bir seçenek varsa tepki verin. Aynı zamanda, istemcilerdeki geri dönüş sayesinde anında tepki verilmesi kritik değildir.
Böylece, sistem desteğinin ilkeleri şu şekilde formüle edilebilir:
- arıza ölçeğinin azaltılması;
- ölçümlerin toplanması;
- Yapabiliyorsak arızaları otomatik olarak onarırız;
- eğer yapamıyorsa sizi bilgilendiririz;
- Hızlı müdahale için kontrol panelleri ve önceliklendirme araç seti üzerinde çalışıyoruz.
Dersler öğrenildi
Bir prototip yazmak fazla zaman almaz. Bizim durumumuzda 4 ay sonra hazırdı. Bununla birlikte yeni ölçümler aldık ve geliştirmenin başlamasından 10 ay sonra ilk üretim trafiğini aldık. Daha sonra sıkıcı ve çok zorlu çalışma başladı: sistemi kademeli olarak ürünleştirin ve ölçeklendirin, ana trafiği taşıyın ve hatalardan ders alın. Ancak bu etkili süreç doğrusal olmayacaktır; tüm çabalara rağmen her şey tahmin edilemez. Yeni verileri hızla yinelemek ve bunlara yanıt vermek çok daha etkilidir.
Deneyimlerimize dayanarak aşağıdakileri önerebiliriz:
- Sezginize güvenmeyin.
Ekip üyelerimizin engin deneyimine rağmen sezgilerimiz bizi sürekli başarısızlığa uğrattı. Örneğin, CDN proxy kullanımından beklenen hızlanmayı veya TCP Anycast davranışını yanlış tahmin ettik.
- Üretimden veri alın.
En azından küçük miktardaki üretim verilerine mümkün olduğunca çabuk erişim sağlamak önemlidir. Laboratuvar koşullarında benzersiz vaka, konfigürasyon ve ortam sayısını elde etmek neredeyse imkansızdır. Sonuçlara hızlı erişim, olası sorunlar hakkında hızlı bir şekilde bilgi edinmenize ve bunları sistem mimarisinde dikkate almanıza olanak sağlayacaktır.
- Başkalarının tavsiyelerine ve sonuçlarına uymayın; kendi verilerinizi toplayın.
Veri toplama ve analiz etme ilkelerini takip edin ancak başkalarının sonuçlarını ve beyanlarını körü körüne kabul etmeyin. Kullanıcılarınız için tam olarak neyin işe yaradığını yalnızca siz bilebilirsiniz. Sistemleriniz ve müşterileriniz diğer şirketlerden önemli ölçüde farklı olabilir. Neyse ki analiz araçları artık mevcut ve kullanımı kolay. Alacağınız sonuçlar Netflix, Facebook, Akamai ve diğer şirketlerin iddia ettiği gibi olmayabilir. Bizim durumumuzda TLS, HTTP2 veya DNS isteklerindeki istatistiklerin performansı Facebook, Uber, Akamai'nin sonuçlarından farklıdır çünkü farklı cihazlarımız, istemcilerimiz ve veri akışlarımız vardır.
- Moda trendlerini gereksiz yere takip etmeyin ve etkinliğini değerlendirin.
Basit başlayın. İhtiyacınız olmayan bileşenleri geliştirmek için çok fazla zaman harcamaktansa, kısa sürede basit bir çalışma sistemi oluşturmak daha iyidir. Ölçümlerinize ve sonuçlarınıza göre önemli olan görevleri ve sorunları çözün.
- Yeni uygulamalara hazır olun.
Sorunların tamamını tahmin etmek zor olduğu gibi faydalarını ve uygulamalarını da önceden tahmin etmek zordur. Startup'lardan bir ipucu alın; onların müşteri koşullarına uyum sağlama yetenekleri. Sizin durumunuzda yeni sorunlar ve bunların çözümlerini keşfedebilirsiniz. Projemizde istek gecikmesini azaltmak için bir hedef belirledik. Ancak analiz ve tartışmalar sırasında proxy sunucuları da kullanabileceğimizi fark ettik:
- AWS bölgelerindeki trafiği dengelemek ve maliyetleri azaltmak;
- CDN kararlılığını modellemek için;
- DNS'yi yapılandırmak için;
- TLS/TCP'yi yapılandırmak için.
Sonuç
Raporda Netflix'in istemciler ile bulut arasındaki internet isteklerini hızlandırma sorununu nasıl çözdüğünü anlattım. Müşterilerden bir örnekleme sistemi kullanarak nasıl veri topluyoruz ve toplanan geçmiş verileri müşterilerden gelen üretim taleplerini İnternet'teki en hızlı yoldan yönlendirmek için nasıl kullanıyoruz? Bu görevi başarmak için ağ protokollerinin ilkelerini, CDN altyapımızı, omurga ağımızı ve DNS sunucularımızı nasıl kullanırız.
Ancak çözümümüz, Netflix olarak böyle bir sistemi nasıl uyguladığımızın yalnızca bir örneğidir. Bizim için ne işe yaradı? Raporumun sizler için uygulanan kısmı, takip ettiğimiz ve iyi sonuçlar elde ettiğimiz gelişim ve destek ilkeleridir.
Soruna çözümümüz size uymayabilir. Ancak kendi CDN altyapınız olmasa veya bizimkinden önemli ölçüde farklı olsa bile teori ve tasarım ilkeleri aynı kalır.
İş taleplerinin hızının önemi de önemini koruyor. Basit bir hizmet için bile bir seçim yapmanız gerekir: bulut sağlayıcıları, sunucu konumu, CDN ve DNS sağlayıcıları arasında. Seçiminiz müşterileriniz için İnternet sorgularının etkinliğini etkileyecektir. Ve bu etkiyi ölçüp anlamanız sizin için önemlidir.
Basit çözümlerle başlayın, ürünü nasıl değiştireceğinize dikkat edin. Müşterilerinizden, altyapınızdan ve işletmenizden gelen verilere dayanarak sisteminizi geliştirerek öğrenin ve geliştirin. Tasarım sürecinde beklenmeyen arızaların olasılığını düşünün. Ardından geliştirme sürecinizi hızlandırabilir, çözüm verimliliğini artırabilir, gereksiz destek yükünden kurtulabilir ve huzur içinde uyuyabilirsiniz.
bu yıl çevrimiçi formatta. DevOps'un babalarından biri olan John Willis'e sorular sorabilirsiniz!
Kaynak: habr.com
