Modern web, medya içeriği olmadan neredeyse düşünülemez: neredeyse her büyükannenin bir akıllı telefonu vardır, herkes sosyal ağlardadır ve bakımdaki kesintiler şirketler için maliyetlidir. İşte şirketin hikayesinin bir metni donanım çözümü kullanarak fotoğrafların dağıtımını nasıl organize ettiğini, süreçte hangi performans sorunlarıyla karşılaştığını, bunlara neyin sebep olduğunu ve bu sorunların Nginx tabanlı bir yazılım çözümü kullanılarak her düzeyde hata toleransını sağlarken nasıl çözüldüğünü anlattı (). Oleg'in hikayesinin yazarlarına teşekkür ediyoruz Konferansta deneyimlerini paylaşan Efimova ve Alexandra Dymova .
— Fotoğrafları nasıl sakladığımız ve önbelleğe aldığımız hakkında küçük bir girişle başlayalım. Bunları sakladığımız bir katmanımız ve fotoğrafları önbelleğe aldığımız bir katmanımız var. Aynı zamanda, yüksek bir hile oranı elde etmek ve depolama üzerindeki yükü azaltmak istiyorsak, bireysel bir kullanıcının her fotoğrafının bir önbellekleme sunucusunda olması bizim için önemlidir. Aksi takdirde, sahip olduğumuz sunucu sayısı kadar disk takmak zorunda kalırız. Hile oranımız %99 civarında yani depolama alanımızdaki yükü 100 kat azaltıyoruz ve bunu yapabilmek için 10 yıl önce tüm bunlar yapılırken 50 sunucumuz vardı. Buna göre bu fotoğrafların servis edilebilmesi için esas olarak bu sunucuların hizmet verdiği 50 adet harici alana ihtiyacımız vardı.
Doğal olarak hemen şu soru ortaya çıktı: Sunucularımızdan biri çöker ve kullanılamaz hale gelirse trafiğin ne kadarını kaybederiz? Piyasada neler olduğuna baktık ve tüm sorunlarımızı çözecek bir donanım almaya karar verdik. Seçim, F5 ağ şirketinin (bu arada yakın zamanda NGINX, Inc.'i satın aldı) çözümüne düştü: BIG-IP Yerel Trafik Yöneticisi.
Bu donanım parçasının (LTM) yaptığı şey: harici bağlantı noktalarında demir yedekliliği yapan ve bazı ayarlarda ağ topolojisine göre trafiği yönlendirmenize olanak tanıyan ve sağlık kontrolleri yapan bir demir yönlendiricidir. Bu donanımın programlanabilmesi bizim için önemliydi. Buna göre belirli bir kullanıcıya ait fotoğrafların belirli bir önbellekten nasıl servis edildiğinin mantığını anlatabiliriz. Nasıl görünüyor? İnternete tek bir etki alanından, tek IP'den bakan, SSL boşaltma yapan, http isteklerini ayrıştıran, IRule'dan bir önbellek numarası seçen, nereye gidileceğini ve trafiğin oraya gitmesini sağlayan bir donanım parçası vardır. Aynı zamanda sağlık kontrolleri de yapıyor ve bazı makinelerin kullanılamaması durumunda trafiğin tek bir yedek sunucuya gitmesini sağladık. Yapılandırma açısından elbette bazı nüanslar var, ancak genel olarak her şey oldukça basit: bir kart kaydediyoruz, belirli bir sayının ağdaki IP'mize yazışması, 80 numaralı bağlantı noktalarını dinleyeceğimizi söylüyoruz ve 443, eğer sunucu kullanılamıyorsa, trafiği yedek olana, bu durumda 35'inciye göndermeniz gerektiğini söylüyoruz ve bu mimarinin nasıl sökülmesi gerektiğine dair bir sürü mantık açıklıyoruz. Tek sorun donanımın programlandığı dilin Tcl olmasıydı. Eğer bunu hatırlayan varsa... bu dil, programlamaya uygun bir dilden daha salt yazılabilir bir dildir:
Ne elde ettik? Altyapımızın yüksek kullanılabilirliğini sağlayan, tüm trafiğimizi yönlendiren, sağlık açısından fayda sağlayan ve adil çalışan bir donanım aldık. Üstelik oldukça uzun bir süredir çalışıyor: Son 10 yılda bu konuda herhangi bir şikayet olmadı. 2018'in başında zaten saniyede yaklaşık 80 bin fotoğraf gönderiyorduk. Bu, her iki veri merkezimizden de yaklaşık 80 gigabit trafik anlamına geliyor.
Ancak ...
2018'in başında listelerde çirkin bir tabloyla karşılaştık: Fotoğraf gönderme süresi açıkça artmıştı. Ve bize uymayı bıraktı. Sorun şu ki, bu davranış yalnızca trafiğin yoğun olduğu zamanlarda görülebiliyordu; şirketimiz için bu, Pazar'dan Pazartesi'ye kadar olan gecedir. Ancak geri kalan zamanlarda sistem her zamanki gibi davrandı, herhangi bir başarısızlık belirtisi yoktu.
Ancak yine de sorunun çözülmesi gerekiyordu. Olası darboğazları tespit edip gidermeye başladık. Her şeyden önce elbette harici uplink'leri genişlettik, dahili uplink'lerin tam bir denetimini gerçekleştirdik ve olası tüm darboğazları bulduk. Ancak bütün bunlar bariz bir sonuç vermedi, sorun ortadan kalkmadı.
Bir başka olası darboğaz da fotoğraf önbelleklerinin performansıydı. Ve sorunun belki de onlardan kaynaklandığına karar verdik. Performansı genişlettik; özellikle fotoğraf önbelleklerindeki ağ bağlantı noktaları. Ancak yine belirgin bir gelişme görülmedi. Sonunda LTM'nin performansına çok dikkat ettik ve burada grafiklerde üzücü bir tablo gördük: tüm CPU'ların üzerindeki yük düzgün bir şekilde azalmaya başlıyor, ancak sonra aniden sabit bir noktaya geliyor. Aynı zamanda LTM, durum kontrollerine ve yukarı bağlantılara yeterli düzeyde yanıt vermeyi durdurur ve bunları rastgele kapatmaya başlar, bu da ciddi performans düşüşüne yol açar.
Yani sorunun kaynağını tespit ettik, darboğazı tespit ettik. Geriye ne yapacağımıza karar vermek kalıyor.
Yapabileceğimiz ilk ve en bariz şey LTM'nin kendisini bir şekilde modernize etmektir. Ancak burada bazı nüanslar var, çünkü bu donanım oldukça benzersiz, en yakın süpermarkete gidip satın almayacaksınız. Bu ayrı bir sözleşmedir, ayrı bir lisans sözleşmesidir ve çok zaman alacaktır. İkinci seçenek, kendiniz düşünmeye başlamak, kendi bileşenlerinizi kullanarak, tercihen açık erişimli bir program kullanarak kendi çözümünüzü bulmaktır. Geriye kalan tek şey bunun için tam olarak neyi seçeceğimize ve bu sorunu çözmek için ne kadar zaman harcayacağımıza karar vermek, çünkü kullanıcılar yeterli fotoğraf alamıyor. Dolayısıyla tüm bunları dün diyebileceğimiz çok çok hızlı bir şekilde yapmamız gerekiyor.
Görev kulağa "bir şeyi mümkün olduğu kadar çabuk ve sahip olduğumuz donanımı kullanarak yapmak" gibi geldiğinden, düşündüğümüz ilk şey, çok güçlü olmayan bazı makineleri önden çıkarmak, oraya nasıl yapılacağını bildiğimiz Nginx'i koymaktı. Çalışın ve donanımın kullandığı mantığın aynısını uygulamaya çalışın. Yani aslında donanımlarımızı bıraktık, yapılandırmamız gereken 4 sunucu daha kurduk, onlar için harici alanlar oluşturduk, tıpkı 10 yıl önce olduğu gibi... Bu makineler düşerse kullanılabilirliği biraz kaybettik ama daha da azıyla kullanıcılarımızın sorununu yerel olarak çözdüler.
Buna göre mantık aynı kalıyor: Nginx'i kuruyoruz, SSL boşaltma yapabiliyor, yönlendirme mantığını bir şekilde programlayabiliyoruz, yapılandırmalardaki sağlık kontrollerini yapabiliyoruz ve daha önce sahip olduğumuz mantığı basitçe kopyalayabiliyoruz.
Yapılandırmaları yazmak için oturalım. İlk başta her şey çok basit görünüyordu, ancak ne yazık ki her görev için kılavuz bulmak çok zor. Bu nedenle, "Nginx'in fotoğraflar için nasıl yapılandırılacağını" Google'da aramanızı önermiyoruz: hangi ayarlara dokunulması gerektiğini gösteren resmi belgelere bakmak daha iyidir. Ancak belirli parametreyi kendiniz seçmek daha iyidir. O zaman her şey basit: sahip olduğumuz sunucuları tanımlıyoruz, sertifikaları tanımlıyoruz... Ama aslında en ilginç olanı yönlendirme mantığının kendisidir.
İlk başta bize, ne kadar yukarı akışa ihtiyacımız olduğunu açıklamak için ellerimizi veya bir jeneratör kullanarak, içindeki fotoğraf önbelleğimizin sayısıyla eşleştirerek basitçe konumumuzu tanımlıyormuşuz gibi göründü; her yukarı akışta trafiğin gitmesi gereken sunucuyu belirtiyoruz. go ve bir yedekleme sunucusu - ana sunucu mevcut değilse:
Ama muhtemelen her şey bu kadar basit olsaydı, eve gider ve hiçbir şey söylemezdik. Ne yazık ki, genel olarak uzun yıllar süren geliştirme süreci boyunca yapılan ve bu duruma tamamen uygun olmayan varsayılan Nginx ayarlarıyla... yapılandırma şuna benzer: eğer bazı yukarı akış sunucularında bir istek hatası veya zaman aşımı varsa, Nginx her zaman trafiği bir sonrakine geçirir. Üstelik ilk arızadan sonra 10 saniye içinde sunucu da hem yanlışlıkla hem de zaman aşımı nedeniyle kapatılacaktır - bu hiçbir şekilde yapılandırılamaz bile. Yani, yukarı akış yönergesindeki zaman aşımı seçeneğini kaldırırsak veya sıfırlarsak, Nginx bu isteği işlemese ve pek iyi olmayan bir hatayla yanıt verse de sunucu kapanacaktır.
Bunu önlemek için iki şey yaptık:
a) Nginx'in bunu manuel olarak yapmasını yasakladılar - ve ne yazık ki bunu yapmanın tek yolu maksimum başarısızlık ayarlarını yapmaktır.
b) diğer projelerde arka plan sağlık kontrolleri yapmamıza olanak tanıyan bir modül kullandığımızı hatırladık; buna göre, bir kaza durumunda aksama süresinin minimum düzeyde olması için oldukça sık sağlık kontrolleri yaptık.
Ne yazık ki, hepsi bu kadar değil, çünkü kelimenin tam anlamıyla bu planın çalışmasının ilk iki haftası, TCP sağlık kontrolünün de güvenilmez bir şey olduğunu gösterdi: yukarı akış sunucusunda Nginx veya D durumundaki Nginx olmayabilir ve bu durumda çekirdek bağlantıyı kabul edecek, sağlık kontrolü başarılı olacak ancak çalışmayacaktır. Bu nedenle, bunu hemen sağlık kontrolü http ile değiştirdik, belirli bir tane yaptık, eğer 200 döndürürse, bu komut dosyasında her şey çalışır. Ek mantık yapabilirsiniz - örneğin, sunucuların önbelleğe alınması durumunda, dosya sisteminin doğru şekilde bağlanıp bağlanmadığını kontrol edin:
Ve bu bize uygun olurdu, ancak şu anda devre donanımın yaptığını tamamen tekrarladı. Ama daha iyisini yapmak istedik. Önceden, bir yedekleme sunucumuz vardı ve bu muhtemelen pek iyi değil, çünkü yüz sunucunuz varsa, o zaman birkaçı aynı anda arızalandığında, bir yedekleme sunucusunun yükle başa çıkması pek mümkün değildir. Bu nedenle rezervasyonu tüm sunuculara dağıtmaya karar verdik: basitçe ayrı bir yukarı akış daha yaptık, tüm sunucuları hizmet verebilecekleri yüke göre belirli parametrelerle oraya yazdık, daha önce yaptığımız sağlık kontrollerinin aynısını ekledik:
Bir yukarı akış içinde başka bir yukarı akışa gitmek imkansız olduğundan, doğru, gerekli fotoğraf önbelleğini kaydettiğimiz ana yukarı akışın mevcut olmaması durumunda, geri dönüş için error_page üzerinden geçmemiz gerektiğinden emin olmak gerekiyordu. yedeklemenin yukarı akışına gittiğimiz yer:
Kelimenin tam anlamıyla dört sunucu ekleyerek, şunu elde ettik: yükün bir kısmını değiştirdik - yükü LTM'den bu sunuculara kaldırdık, standart donanım ve yazılımı kullanarak aynı mantığı orada uyguladık ve bu sunucuların alabileceği bonusu hemen aldık. ölçeklendirilebilir, çünkü ihtiyaç duyulan kadar tedarik edilebilirler. Tek olumsuz şey, harici kullanıcılar için yüksek kullanılabilirliği kaybetmiş olmamızdır. Ama o anda bunu feda etmek zorunda kaldık çünkü sorunun bir an önce çözülmesi gerekiyordu. Böylece yükün bir kısmını kaldırdık, o zamanlar yaklaşık %40'tı, LTM iyi hissettirdi ve kelimenin tam anlamıyla sorun başladıktan iki hafta sonra, saniyede 45 bin değil 55 bin istek göndermeye başladık. Aslında %20 oranında büyüdük; bu açıkça kullanıcıya vermediğimiz trafiktir. Ve bundan sonra, yüksek dış erişilebilirliği sağlamak için kalan sorunun nasıl çözüleceğini düşünmeye başladılar.
Bunun için hangi çözümü kullanacağımızı tartıştığımız bir süre durakladık. Evde yazılan bazı komut dosyaları, dinamik yönlendirme protokolleri yardımıyla DNS kullanarak güvenilirliği sağlamak için öneriler vardı... birçok seçenek vardı, ancak fotoğrafların gerçekten güvenilir bir şekilde teslim edilmesi için başka bir katman eklemeniz gerektiği zaten belli oldu. bunu izleyecek. Bu makinelere fotoğraf yönetmenleri adını verdik. Güvendiğimiz yazılım Keepalived'dı:
Öncelikle Keepalived'in içeriği nedir? Bunlardan ilki, ağ kullanıcıları tarafından yaygın olarak bilinen, ağ ekipmanında bulunan ve istemcilerin bağlandığı harici IP adresine hata toleransı sağlayan VRRP protokolüdür. İkinci bölüm, fotoğraf yönlendiricileri arasında dengeleme yapmak ve bu düzeyde hata toleransını sağlamak için IPVS, IP sanal sunucusudur. Ve üçüncüsü sağlık kontrolleri.
İlk bölümle başlayalım: VRRP - neye benziyor? İstemcilerin bağlandığı dns badoocdn.com'da girişi olan belirli bir sanal IP vardır. Bir noktada, bir sunucuda bir IP adresimiz var. Canlı tutma paketleri, VRRP protokolünü kullanan sunucular arasında çalışır ve ana öğenin radardan kaybolması durumunda (sunucu yeniden başlatıldığında veya başka bir şey olduğunda), yedekleme sunucusu bu IP adresini otomatik olarak alır; herhangi bir manuel işlem gerekmez. Ana ve yedekleme arasındaki fark esas olarak önceliktir: Ne kadar yüksek olursa, makinenin ana makine olma şansı da o kadar artar. Çok büyük bir avantaj, IP adreslerini sunucunun kendisinde yapılandırmanıza gerek olmamasıdır; bunları yapılandırmada tanımlamanız yeterlidir ve IP adresleri bazı özel yönlendirme kurallarına ihtiyaç duyuyorsa, bu, doğrudan yapılandırmada aşağıdaki komut kullanılarak açıklanır: VRRP paketinde açıklananla aynı söz dizimi. Bilmediğiniz hiçbir şeyle karşılaşmazsınız.
Bu pratikte neye benziyor? Sunuculardan biri arızalanırsa ne olur? Master ortadan kaybolduğu anda yedeğimiz reklam almayı bırakır ve otomatik olarak master olur. Bir süre sonra ana öğeyi onardık, yeniden başlattık, Keepalived'ı yükselttik - reklamlar yedeklemeden daha yüksek önceliğe sahip olarak gelir ve yedekleme otomatik olarak geri döner, IP adreslerini kaldırır, herhangi bir manuel işlem yapılmasına gerek yoktur.
Böylece harici IP adresinin hata toleransını sağlamış olduk. Bir sonraki kısım, harici IP adresinden gelen trafiği zaten sonlandırmakta olan fotoğraf yönlendiricilerine bir şekilde dengelemektir. Dengeleme protokollerinde her şey oldukça açık. Bu ya basit bir hepsini bir kez deneme işlemidir ya da biraz daha karmaşık şeylerdir, wrr, liste bağlantısı vb. Bu temel olarak belgelerde açıklanmıştır, özel bir şey yoktur. Ama teslimat yöntemi... Burada neden bunlardan birini seçtiğimize daha yakından bakacağız. Bunlar NAT, Doğrudan Yönlendirme ve TUN'dur. Gerçek şu ki, sitelerden hemen 100 gigabit trafik sağlamayı planladık. Tahmin ederseniz 10 gigabit karta ihtiyacınız var değil mi? Bir sunucuda 10 gigabit kart zaten en azından bizim "standart ekipman" konseptimizin kapsamı dışındadır. Sonra sadece trafiği dağıtmadığımızı, fotoğraf da verdiğimizi hatırladık.
Özel olan ne? — Gelen ve giden trafik arasında çok büyük fark. Gelen trafik çok küçük, giden trafik ise çok büyük:
Bu grafiklere baktığınızda yönetmenin şu anda saniyede yaklaşık 200 MB aldığını, bunun çok sıradan bir gün olduğunu görebilirsiniz. Saniyede 4,500 MB geri veriyoruz, oranımız yaklaşık 1/22. 22 çalışan sunucuya giden trafiği tam olarak sağlamak için yalnızca bu bağlantıyı kabul eden bir sunucuya ihtiyacımız olduğu zaten açık. Doğrudan yönlendirme algoritmasının yardımımıza geldiği yer burasıdır.
Nasıl görünüyor? Fotoğraf yönetmenimiz, tablosuna göre bağlantıları fotoğraf yönlendiricilerine aktarıyor. Ancak fotoğraf yönlendiricileri, dönüş trafiğini doğrudan İnternet'e gönderir, istemciye gönderir, fotoğraf yönlendiricisinden geri gitmez, böylece minimum sayıda makineyle tam hata toleransı ve tüm trafiğin pompalanmasını sağlıyoruz. Yapılandırmalarda şuna benziyor: algoritmayı belirliyoruz, bizim durumumuzda bu basit bir rr, doğrudan yönlendirme yöntemini sağlıyoruz ve ardından kaç taneye sahip olduğumuz tüm gerçek sunucuları listelemeye başlıyoruz. Bu trafiği belirleyecek olan şey. Orada bir veya iki sunucumuz daha varsa veya birkaç sunucumuz varsa, böyle bir ihtiyaç ortaya çıkar - bu bölümü sadece config'e ekliyoruz ve çok fazla endişelenmeyin. Gerçek sunucular açısından, fotoğraf yönlendirici açısından bu yöntem en az yapılandırmayı gerektirir, belgelerde mükemmel bir şekilde açıklanmıştır ve orada hiçbir tuzak yoktur.
Özellikle güzel olan, böyle bir çözümün yerel ağın radikal bir şekilde yeniden tasarlanmasını gerektirmemesi, bu bizim için önemliydi, bunu minimum maliyetle çözmemiz gerekiyordu. Eğer bakarsanız , sonra neye benzediğini göreceğiz. Burada 443 numaralı bağlantı noktasında belirli bir sanal sunucumuz var, dinliyor, bağlantıyı kabul ediyor, çalışan tüm sunucular listeleniyor ve bağlantının aynı olduğunu, alındığını veya verildiğini görebilirsiniz. Aynı sanal sunucudaki istatistiklere bakarsak, gelen paketlerimiz, gelen bağlantılarımız var ama giden bağlantılarımız kesinlikle yok. Giden bağlantılar doğrudan istemciye gider. Tamam, dengesini bozmayı başardık. Peki, fotoğraf yönlendiricilerimizden biri arızalanırsa ne olur? Sonuçta demir demirdir. Çekirdek paniğine girebilir, bozulabilir, güç kaynağı yanabilir. Herhangi bir şey. Bu nedenle sağlık kontrollerine ihtiyaç duyulmaktadır. Bağlantı noktasının nasıl açık olduğunu kontrol etmek kadar basit veya iş mantığını bile kontrol edecek evde yazılmış bazı komut dosyalarına kadar daha karmaşık bir şey olabilirler.
Ortada bir yerde durduk: Belirli bir konuma https isteğimiz var, komut dosyası çağrılıyor, 200. yanıtla yanıt verirse, bu sunucuda her şeyin yolunda olduğuna, canlı olduğuna ve oldukça açılabileceğine inanıyoruz. kolayca.
Bu yine pratikte nasıl görünüyor? Bakım için sunucuyu kapatalım - örneğin BIOS'u güncelleyelim. Günlüklerde hemen bir zaman aşımı yaşıyoruz, ilk satırı görüyoruz, ardından üç denemeden sonra "başarısız" olarak işaretleniyor ve listeden kaldırılıyor.
VS basitçe sıfıra ayarlandığında ikinci bir davranış seçeneği de mümkündür, ancak fotoğraf döndürülürse bu iyi çalışmaz. Sunucu açılır, Nginx oradan başlar, sağlık kontrolü bağlantının çalıştığını, her şeyin yolunda olduğunu hemen anlar ve sunucu listemizde belirir ve yük hemen ona uygulanmaya başlar. Görev yöneticisinin herhangi bir manuel işlem yapmasına gerek yoktur. Sunucu gece yeniden başlatıldı - izleme departmanı bizi bu konuda geceleri aramıyor. Size bunun olduğunu, her şeyin yolunda olduğunu bildirdiler.
Böylece, az sayıda sunucunun yardımıyla oldukça basit bir şekilde harici hata toleransı sorununu çözdük.
Söylenmesi gereken tek şey, tüm bunların elbette izlenmesi gerektiğidir. Ayrı olarak, uzun zaman önce yazılmış bir yazılım olan Keepalivede'nin, hem DBus, SMTP, SNMP hem de standart Zabbix aracılığıyla kontroller kullanarak onu izlemenin birçok yoluna sahip olduğu unutulmamalıdır. Ayrıca, neredeyse her hapşırıkta nasıl mektup yazılacağını kendisi biliyor ve dürüst olmak gerekirse, bir noktada onu kapatmayı bile düşündük, çünkü herhangi bir trafik geçişi, her IP bağlantısı için açılma, açılma için çok sayıda mektup yazıyor, ve benzeri . Tabii eğer çok sayıda sunucu varsa o zaman bu harflere boğulabilirsiniz. Standart yöntemleri kullanarak fotoğraf yönlendiricilerindeki nginx'i izliyoruz ve donanım izleme ortadan kalkmadı. Elbette iki şey daha tavsiye ederiz: birincisi, harici sağlık kontrolleri ve kullanılabilirlik, çünkü her şey işe yarasa bile, aslında, harici sağlayıcılarla ilgili sorunlar veya daha karmaşık bir şey nedeniyle kullanıcılar fotoğraf alamıyor olabilir. Her zaman başka bir ağda, Amazon'da veya başka bir yerde, sunucularınıza dışarıdan ping atabilecek ayrı bir makine tutmaya değer ve aynı zamanda karmaşık makine öğreniminin nasıl yapılacağını bilenler için anormallik tespitini veya basit izlemeyi kullanmaya değer. en azından taleplerin keskin bir şekilde düşüp düşmediğini veya tam tersine arttığını takip etmek için. Aynı zamanda faydalı da olabilir.
Özetleyelim: Aslında, bir noktada artık bize uymayan demir kaplı çözümü, her şeyi aynı yapan, yani HTTPS trafiğinin sonlandırılmasını ve daha akıllı yönlendirmeyi sağlayan oldukça basit bir sistemle değiştirdik. gerekli sağlık kontrolleri. Bu sistemin kararlılığını arttırdık, yani her katman için hâlâ yüksek kullanılabilirliğe sahibiz, ayrıca her katmanda hepsini ölçeklendirmenin oldukça kolay olması avantajına da sahibiz, çünkü bu standart yazılımla standart donanımdır, yani , olası sorunların teşhisini basitleştirdik.
Sonunda ne elde ettik? 2018 Ocak tatilinde sorun yaşadık. Bu şemayı devreye aldığımız ilk altı ayda, tüm trafiği LTM'den çıkarmak için tüm trafiğe genişlettik, sadece bir veri merkezindeki trafiği 40 gigabit'ten 60 gigabit'e çıkardık ve aynı zamanda 2018 yılının tamamında saniyede neredeyse üç kat daha fazla fotoğraf gönderebildik.
Kaynak: habr.com