Monolitinizi mikro hizmetlere dönüştürmek için aylar harcadınız ve sonunda herkes düğmeyi çevirmek için bir araya geldi. İlk web sayfasına gidiyorsunuz... ve hiçbir şey olmuyor. Yeniden yüklüyorsunuz - ve yine iyi bir şey yok, site o kadar yavaş ki birkaç dakika yanıt vermiyor. Ne oldu?
Jimmy Bogard konuşmasında gerçek hayattaki bir mikro hizmet felaketi üzerine bir "post-mortem" yürütecek. Keşfettiği modelleme, geliştirme ve üretim sorunlarını ve ekibinin yeni dağıtılmış monoliti nasıl yavaşça akıl sağlığının nihai resmine dönüştürdüğünü gösterecek. Tasarım hatalarını tamamen önlemek mümkün olmasa da, nihai ürünün güvenilir bir dağıtılmış sistem haline gelmesini sağlamak için en azından sorunları tasarım sürecinde erken tespit edebilirsiniz.
Herkese merhaba, ben Jimmy ve bugün mikro hizmetler oluştururken büyük felaketlerden nasıl kaçınabileceğinizi duyacaksınız. Bu, gemisinin buzdağına çarpmasını önlemek için yaklaşık bir buçuk yıl çalıştığım bir şirketin hikayesi. Bu hikayeyi doğru bir şekilde anlatmak için zamanda geriye gitmemiz ve bu şirketin nereden başladığı ve BT altyapısının zaman içinde nasıl büyüdüğü hakkında konuşmamız gerekecek. Bu felakette masum olanların isimlerini korumak için bu şirketin adını Bell Bilgisayar olarak değiştirdim. Bir sonraki slaytta bu tür şirketlerin BT altyapısının 90'ların ortalarında nasıl göründüğü gösteriliyor. Bu, bir bilgisayar donanımı mağazasının işletilmesine yönelik büyük, evrensel, hataya dayanıklı HP Tandem Ana Çerçeve sunucusunun tipik mimarisidir.
Tüm siparişleri, satışları, iadeleri, ürün kataloglarını ve müşteri tabanını yönetecek bir sistem kurmaları gerekiyordu, bu nedenle o dönemde en yaygın ana bilgisayar çözümünü seçtiler. Bu dev sistem, şirkete ait her türlü bilgiyi, mümkün olan her şeyi barındırıyordu ve her işlem bu ana bilgisayar üzerinden yapılıyordu. Bütün yumurtalarını aynı sepette tutuyorlardı ve bunun normal olduğunu düşünüyorlardı. Burada yer almayan tek şey mail order katalogları ve telefonla sipariş vermektir.
Zamanla sistem büyüdükçe büyüdü ve içinde büyük miktarda çöp birikti. Ayrıca COBOL dünyadaki en etkileyici dil olmadığından sistem büyük, yekpare bir çöp parçası haline geldi. 2000 yılına gelindiğinde pek çok şirketin tüm işlerini yürüttükleri web sitelerinin olduğunu gördüler ve ilk ticari dot-com web sitelerini kurmaya karar verdiler.
İlk tasarım oldukça hoş görünüyordu ve üst düzey bir site olan bell.com'dan ve bireysel uygulamalar için bir dizi alt alan adından oluşuyordu: katalog.bell.com, hesaplar.bell.com, siparişler.bell.com, ürün arama search.bell. com. Her alt alan adı ASP.Net 1.0 çerçevesini ve kendi veritabanlarını kullanıyordu ve hepsi sistemin arka ucuyla iletişim kuruyordu. Bununla birlikte, tüm siparişler, tüm çöplerin kaldığı tek bir büyük ana bilgisayar içinde işlenmeye ve yürütülmeye devam etti, ancak ön uç, bireysel uygulamalara ve ayrı veritabanlarına sahip ayrı web siteleriydi.
Yani sistemin tasarımı düzenli ve mantıklı görünüyordu ancak gerçek sistem bir sonraki slaytta gösterildiği gibiydi.
Tüm öğeler birbirlerine yapılan çağrılara, erişilen API'lere, yerleşik üçüncü taraf dll'lere ve benzerlerine yönelikti. Sürüm kontrol sistemlerinin başka birinin kodunu alıp projenin içine ittiği ve ardından her şeyin bozulduğu sık sık yaşandı. MS SQL Server 2005, bağlantı sunucuları kavramını kullanıyordu ve slaytta okları göstermesem de, veritabanlarının her biri birbiriyle de konuşuyordu, çünkü çeşitli veritabanlarından elde edilen verilere dayalı tablolar oluşturmakta yanlış bir şey yok.
Artık sistemin farklı mantıksal alanları arasında bir miktar ayrım olduğu için, bunlar dağınık kir damlaları haline geldi ve en büyük çöp parçası hâlâ ana bilgisayarın arka ucunda kaldı.
İşin komik yanı, bu ana bilgisayarın Bell Computers'ın rakipleri tarafından yapılmış olması ve bakımının hâlâ onların teknik danışmanları tarafından yapılmasıydı. Uygulamalarının yetersiz performansına ikna olan şirket, uygulamalardan kurtulmaya ve sistemi yeniden tasarlamaya karar verdi.
Mevcut uygulama 15 yıldır üretimdeydi ve bu ASP.Net tabanlı uygulamalar için bir rekordu. Hizmet dünyanın her yerinden sipariş kabul etti ve bu tek uygulamadan elde edilen yıllık gelir bir milyar dolara ulaştı. Kârın önemli bir kısmı bell.com web sitesinden elde edildi. Kara Cuma günlerinde site üzerinden verilen siparişlerin sayısı birkaç milyona ulaştı. Ancak mevcut mimari herhangi bir gelişmeye izin vermiyordu, çünkü sistem elemanlarının katı ara bağlantıları pratik olarak hizmette herhangi bir değişiklik yapılmasına izin vermiyordu.
En ciddi sorun, küresel şirketlerde böyle bir ticaret planının çok yaygın olmasına rağmen, bir ülkeden sipariş verememek, başka bir ülkede ödeme yapıp üçüncüye gönderememekti. Mevcut web sitesi böyle bir şeye izin vermediğinden bu siparişleri kabul edip telefonla vermek zorunda kaldılar. Bu, şirketin mimariyi değiştirmeyi, özellikle de mikro hizmetlere geçmeyi giderek daha fazla düşünmesine yol açtı.
Benzer bir sorunu nasıl çözdüklerini görmek için diğer şirketlere bakarak akıllıca olanı yaptılar. Bu çözümlerden biri, bir API ve harici bir veritabanı aracılığıyla birbirine bağlanan mikro hizmetlerden oluşan Netflix hizmet mimarisiydi.
Bell Bilgisayar yönetimi, belirli temel ilkelere bağlı kalarak böyle bir mimari oluşturmaya karar verdi. İlk olarak, paylaşılan bir veritabanı yaklaşımı kullanarak veri tekrarını ortadan kaldırdılar. Hiçbir veri gönderilmedi; tam tersine ihtiyacı olan herkesin merkezi bir kaynağa gitmesi gerekiyordu. Bunu izolasyon ve özerklik izledi; her hizmet diğerlerinden bağımsızdı. Kesinlikle her şey için Web API'sini kullanmaya karar verdiler; veri almak veya başka bir sistemde değişiklik yapmak istiyorsanız, bunların hepsi Web API aracılığıyla yapılıyordu. Son büyük şey, rakiplerin donanımını temel alan "Bell" ana bilgisayarının aksine "Bell on Bell" adı verilen yeni bir ana bilgisayardı.
Böylece 18 ay boyunca sistemi bu temel ilkeler etrafında kurdular ve üretim öncesi aşamaya getirdiler. Hafta sonundan sonra işe dönen geliştiriciler bir araya gelerek yeni sistemin bağlı olduğu tüm sunucuları açtılar. 18 aylık çalışma, yüzlerce geliştirici, en modern Bell donanımı - ve olumlu sonuç yok! Bu birçok insanı hayal kırıklığına uğrattı çünkü bu sistemi dizüstü bilgisayarlarında birçok kez çalıştırdılar ve her şey yolundaydı.
Bütün paralarını bu sorunu çözmeye harcayacak kadar akıllıydılar. Anahtarlı en modern sunucu raflarını kurdular, gigabit optik fiber kullandılar, inanılmaz miktarda RAM'e sahip en güçlü sunucu donanımını kullandılar, hepsini bağladılar, yapılandırdılar - ve yine hiçbir şey yapmadılar! Daha sonra sebebin zaman aşımı olabileceğinden şüphelenmeye başladılar, bu yüzden tüm web ayarlarına, tüm API ayarlarına girdiler ve tüm zaman aşımı yapılandırmasını maksimum değerlere güncellediler, böylece yapabilecekleri tek şey oturup bir şeyin olmasını beklemekti. Siteye. Web sitesi nihayet yüklenene kadar beklediler, beklediler ve 9 buçuk dakika beklediler.
Daha sonra mevcut durumun detaylı bir şekilde analiz edilmesi gerektiğini anladılar ve bizi davet ettiler. Öğrendiğimiz ilk şey, 18 aylık geliştirme süreci boyunca tek bir gerçek "mikro" yaratılmadığıydı; her şey daha da büyüdü. Bunun ardından felaketin nedenini anlamak için “geriye dönük” ya da “hüzünlü retrospektif” olarak da bilinen, “suçlama fırtınası” olarak da bilinen, “beyin fırtınasına” benzeyen bir otopsi yazmaya başladık.
Elimizde birkaç ipucu vardı; bunlardan biri API çağrısı sırasında trafiğin tamamen doygunluğuydu. Monolitik bir hizmet mimarisi kullandığınızda tam olarak neyin yanlış gittiğini hemen anlayabilirsiniz çünkü arızaya neden olabilecek her şeyi rapor eden tek bir yığın izlemeniz olur. Bir grup hizmetin aynı API'ye eşzamanlı olarak erişmesi durumunda, tek bir isteği inceleyebileceğiniz ve uygulanması sırasında ne olduğunu öğrenebileceğiniz WireShark gibi ek ağ izleme araçlarını kullanmak dışında izi takip etmenin bir yolu yoktur. Böylece bir web sayfası aldık ve bulmacanın parçalarını bir araya getirmek, ona çeşitli çağrılar yapmak ve her birinin neye yol açtığını analiz etmek için neredeyse 2 hafta harcadık.
Bu resme bak. Bu, harici bir isteğin hizmetten geri dönen birçok dahili çağrı yapmasını istediğini gösterir. Her dahili çağrının, bu talebe bağımsız olarak hizmet verebilmek için ek atlamalar yaptığı ortaya çıktı, çünkü gerekli bilgileri elde etmek için başka hiçbir yere dönemez. Bu resim anlamsız bir çağrı dizisi gibi görünüyor, çünkü harici istek ek hizmetleri çağırıyor, o da diğer ek hizmetleri çağırıyor ve bu neredeyse sonsuza kadar devam ediyor.
Bu şemadaki yeşil renk, servislerin birbirini aradığı yarım daireyi gösterir - A servisi B servisini, B servisi C servisini çağırır ve tekrar A servisini çağırır.Sonuç olarak "dağıtılmış kilitlenme" elde ederiz. Tek bir istek, binlerce ağ API çağrısı yarattı ve sistemde yerleşik hata toleransı ve döngü koruması bulunmadığından, bu API çağrılarından biri bile başarısız olsa istek başarısız olacaktı.
Biraz matematik yaptık. Her API çağrısının 150 ms'yi aşmayan bir SLA'sı ve %99,9 çalışma süresi vardı. Bir istek 200 farklı çağrıya neden oldu ve en iyi durumda sayfa 200 x 150 ms = 30 saniyede gösterilebilir. Doğal olarak bu iyi bir şey değildi. %99,9 çalışma süresini 200 ile çarptığımızda %0 kullanılabilirlik elde ederiz. Bu mimarinin en başından beri başarısızlığa mahkum olduğu ortaya çıktı.
Geliştiricilere 18 aylık çalışmanın ardından bu sorunu nasıl fark edemediklerini sorduk. Yalnızca çalıştırdıkları kod için SLA'yı saydıkları, ancak hizmetleri başka bir hizmeti çağırdığında bu süreyi SLA'larında saymadıkları ortaya çıktı. Tek bir süreçte başlatılan her şey 150 ms değerine bağlıydı ancak diğer hizmet süreçlerine erişim, toplam gecikmeyi birçok kez artırdı. Öğrenilen ilk ders şuydu: "SLA'nızın kontrolü sizde mi, yoksa SLA mı sizin kontrolünüz altında?" Bizim durumumuzda ikincisiydi.
Keşfettiğimiz bir sonraki şey, Peter Deitch ve James Gosling tarafından formüle edilen dağıtılmış hesaplama kavram yanılgıları kavramını bildikleri, ancak ilk kısmını görmezden geldikleriydi. “Ağ güvenilirdir”, “sıfır gecikme” ve “sonsuz verim” ifadelerinin kavram yanılgısı olduğunu belirtmektedir. Diğer kavram yanılgıları arasında “Ağ güvenlidir”, “Topoloji asla değişmez”, “Her zaman tek bir yönetici vardır”, “Veri aktarım maliyeti sıfırdır” ve “Ağ homojendir” ifadeleri yer almaktadır.
Hata yaptılar çünkü hizmetlerini yerel makinelerde test ettiler ve hiçbir zaman harici hizmetlerle bağlantı kurmadılar. Yerel olarak geliştirirken ve yerel önbellek kullanırken hiçbir zaman ağ atlamalarıyla karşılaşmadılar. 18 aylık geliştirme süreci boyunca, dış hizmetlerin etkilenmesi durumunda ne olabileceğini bir kez olsun merak etmediler.
Bir önceki resimdeki servis sınırlarına bakarsanız hepsinin yanlış olduğunu görebilirsiniz. Hizmet sınırlarının nasıl tanımlanacağı konusunda tavsiyelerde bulunan pek çok kaynak var ve çoğu, bir sonraki slayttaki Microsoft gibi, bunu yanlış yapıyor.
Bu resim “Mikro hizmetler nasıl oluşturulur” konulu MS blogundan alınmıştır. Bu basit bir web uygulamasını, bir iş mantığı bloğunu ve bir veritabanını gösterir. İstek doğrudan gelir, muhtemelen web için bir sunucu, iş için bir sunucu ve veritabanı için bir sunucu vardır. Trafiği artırırsanız resim biraz değişecektir.
Trafiği iki web sunucusu arasında dağıtmak için bir yük dengeleyici, web hizmeti ile iş mantığı arasında bulunan bir önbellek ve iş mantığı ile veritabanı arasında başka bir önbellek geliyor. Bu tam olarak Bell'in 2000'li yılların ortalarında yük dengeleme ve mavi/yeşil dağıtım uygulaması için kullandığı mimaridir. Bir süreye kadar her şey yolunda gitti, çünkü bu plan monolitik bir yapıya yönelikti.
Aşağıdaki resimde MS'in monolitten mikro hizmetlere geçmeyi (ana hizmetlerin her birini ayrı mikro hizmetlere bölmeyi) nasıl önerdiği gösterilmektedir. Bell bu planın uygulanması sırasında bir hata yaptı.
Tüm hizmetlerini, her biri birçok bireysel hizmetten oluşan farklı katmanlara ayırdılar. Örneğin, web hizmeti içerik oluşturma ve kimlik doğrulama için mikro hizmetleri içeriyordu; iş mantığı hizmeti, siparişleri ve hesap bilgilerini işlemek için mikro hizmetlerden oluşuyordu; veritabanı, özel verileri içeren bir grup mikro hizmete bölünmüştü. Hem web, iş mantığı hem de veritabanı durum bilgisi olmayan hizmetlerdi.
Ancak bu resim tamamen yanlıştı çünkü şirketin BT kümesi dışındaki hiçbir iş birimini haritalandırmıyordu. Bu plan dış dünyayla herhangi bir bağlantıyı hesaba katmıyordu, dolayısıyla örneğin üçüncü taraf iş analitiğinin nasıl elde edileceği açık değildi. Ayrıca, daha fazla para kazanmak için mümkün olduğu kadar çok insanı yönetmeye çalışan bireysel çalışanların kariyerlerini geliştirmek için icat edilmiş çeşitli hizmetlerin de bulunduğunu belirtmek isterim.
Mikro hizmetlere geçmenin, dahili N katmanlı fiziksel katman altyapılarını alıp Docker'ı buna yapıştırmak kadar kolay olduğuna inanıyorlardı. Geleneksel N katmanlı mimarinin neye benzediğine bir göz atalım.
4 seviyeden oluşur: UI kullanıcı arayüzü seviyesi, iş mantığı seviyesi, veri erişim seviyesi ve veritabanı. Daha ilerici olan, iki orta düzeyin etki alanı nesneleri ve bir depo olduğu DDD (Etki Alanı Odaklı Tasarım) veya yazılım odaklı mimaridir.
Bu mimaride farklı değişim alanlarına, farklı sorumluluk alanlarına bakmaya çalıştım. Tipik bir N-katmanlı uygulamada, yapıya yukarıdan aşağıya doğru dikey olarak nüfuz eden farklı değişim alanları sınıflandırılır. Bunlar, ekibim tarafından gerçekleştirilen Katalog, bireysel bilgisayarlarda gerçekleştirilen Yapılandırma ayarları ve Ödeme kontrolleridir.
Bu şemanın özelliği, bu değişim alanlarının sınırlarının yalnızca iş mantığı düzeyini etkilememesi, aynı zamanda veritabanına da uzanmasıdır.
Hizmet olmanın ne anlama geldiğine bakalım. Bir hizmet tanımının 6 karakteristik özelliği vardır; bu yazılım:
- belirli bir kuruluş tarafından oluşturulmuş ve kullanılmış;
- sistem içerisinde belirli türdeki bilgilerin içeriğinden, işlenmesinden ve/veya sağlanmasından sorumludur;
- belirli operasyonel ihtiyaçları karşılamak için bağımsız olarak inşa edilebilir, konuşlandırılabilir ve çalıştırılabilir;
- anlaşmalara veya sözleşmeye bağlı garantilere dayalı olarak bilgi sağlayarak tüketicilerle ve diğer hizmetlerle iletişim kurar;
- kendisini yetkisiz erişime ve bilgilerini kaybolmaya karşı korur;
- arızaları bilgi hasarına yol açmayacak şekilde ele alır.
Bütün bu özellikler tek kelimeyle “özerklik” olarak ifade edilebilir. Hizmetler birbirinden bağımsız çalışır, belirli kısıtlamaları karşılar ve insanların ihtiyaç duydukları bilgileri alabileceği sözleşmeleri tanımlar. Kullanımı apaçık olan belirli teknolojilerden bahsetmedim.
Şimdi mikro hizmetlerin tanımına bakalım:
- Mikro hizmetin boyutu küçüktür ve belirli bir sorunu çözmek için tasarlanmıştır;
- Mikro hizmet özerktir;
- Mikro hizmet mimarisi oluşturulurken şehir planlama metaforu kullanılır. Bu, Sam Newman'ın Building Microservices adlı kitabındaki tanımdır.
Sınırlı Bağlamın tanımı Eric Evans'ın Etki Alanına Dayalı Tasarım kitabından alınmıştır. Bu, hacimsel mimari modellerle çalışan, bunları farklı Sınırlı Bağlamlara bölen ve aralarındaki etkileşimleri açıkça tanımlayan bir mimari tasarım merkezi olan DDD'deki temel modeldir.
Basitçe söylemek gerekirse Sınırlı Bağlam, belirli bir modülün kullanılabileceği kapsamı belirtir. Bu bağlamda, örneğin iş alanınızda görülebilecek, mantıksal olarak birleştirilmiş bir model vardır. Siparişlerle ilgilenen personele “müşteri kimdir” diye sorarsanız bir tanım, satışla ilgilenenlere sorarsanız başka bir tanım, icracılar da size üçüncü bir tanım verir.
Yani Sınırlı Bağlam, hizmetlerimizin tüketicisinin ne olduğuna dair net bir tanım yapamıyorsak, bu terimin anlamından bahsedebileceğimiz sınırları tanımlayalım ve ardından bu farklı tanımlar arasındaki geçiş noktalarını tanımlayalım diyor. Yani, sipariş verme açısından bir müşteriden bahsediyorsak, bu şu ve bu anlamına gelir, satış açısından ise bu şu ve bu anlamına gelir.
Mikro hizmetin bir sonraki tanımı, iş süreci bileşenlerinin çevreye "sızmasını" önleyerek her türlü iç operasyonun kapsüllenmesidir. Daha sonra, SLA'lardan dönen sözleşmeler fikriyle temsil edilen "harici etkileşimler veya harici iletişimler için açık sözleşmelerin tanımı" geliyor. Son tanım, bir hücrenin veya hücrenin metaforudur; bu, bir mikro hizmet içindeki bir dizi işlemin tamamen kapsanması ve dış dünyayla iletişim için alıcıların burada bulunması anlamına gelir.
Bell Computers'taki adamlara şöyle dedik: "Yarattığınız kaosun hiçbirini düzeltemeyiz çünkü bunu yapacak paranız yok, ancak her şeyin daha iyi olmasını sağlamak için yalnızca bir hizmeti düzelteceğiz. algı." Bu noktada tek servisimizi, isteklere 9 buçuk dakikadan daha hızlı yanıt verecek şekilde nasıl düzelttiğimizi anlatarak başlayacağım.
22:30 dk.
Devamı çok yakında...
Bazı reklamlar
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com