Sunucusuzluk, sunucuların fiziksel olarak yokluğuyla ilgili değildir. Bu bir konteyner katili ya da geçici bir trend değil. Bu, bulutta sistem oluşturmaya yönelik yeni bir yaklaşımdır. Bugünkü yazımızda Sunucusuz uygulamaların mimarisine değineceğiz, Sunucusuz servis sağlayıcının ve açık kaynak projelerin nasıl bir rol oynadığını görelim. Son olarak Serverless kullanmanın sorunlarından bahsedelim.
Bir uygulamanın (veya hatta bir çevrimiçi mağazanın) sunucu bölümünü yazmak istiyorum. Bu bir sohbet, içerik yayınlama hizmeti veya yük dengeleyici olabilir. Her durumda, pek çok baş ağrısı olacak: Altyapıyı hazırlamanız, uygulama bağımlılıklarını belirlemeniz ve ana bilgisayar işletim sistemi hakkında düşünmeniz gerekecek. Daha sonra monolitin geri kalanının çalışmasını etkilemeyen küçük bileşenleri güncellemeniz gerekecektir. Yük altında ölçeklendirmeyi unutmayalım.
Gerekli bağımlılıkların önceden yüklendiği ve kapların birbirlerinden ve ana işletim sisteminden izole edildiği geçici kapları alırsak ne olur? Monoliti, her biri diğerlerinden bağımsız olarak güncellenebilen ve ölçeklendirilebilen mikro hizmetlere böleceğiz. Kodu böyle bir konteynere yerleştirerek her türlü altyapı üzerinde çalıştırabilirim. Zaten daha iyi.
Kapsayıcıları yapılandırmak istemiyorsanız ne olur? Uygulamayı ölçeklendirmeyi düşünmek istemiyorum. Hizmetin yükü minimum düzeydeyken boşta çalışan konteynerler için ödeme yapmak istemiyorum. Kod yazmak istiyorum. İş mantığına odaklanın ve ürünleri ışık hızında pazara sunun.
Bu tür düşünceler beni sunucusuz bilişime yöneltti. Bu durumda sunucusuz demek sunucuların fiziksel yokluğu değil, altyapı yönetimi sıkıntılarının yokluğu.
Buradaki fikir, uygulama mantığının bağımsız işlevlere bölünmesidir. Bir etkinlik yapısına sahiptirler. Her işlev bir “mikro görevi” gerçekleştirir. Geliştiricinin yapması gereken tek şey, işlevleri bulut sağlayıcının sağladığı konsola yüklemek ve bunları olay kaynaklarıyla ilişkilendirmektir. Kod, talep üzerine otomatik olarak hazırlanmış bir kapta yürütülecek ve yalnızca yürütme süresi için ödeme yapacağım.
Şimdi uygulama geliştirme sürecinin nasıl görüneceğini görelim.
Geliştirici tarafından
Daha önce bir çevrimiçi mağaza başvurusu hakkında konuşmaya başlamıştık. Geleneksel yaklaşımda sistemin ana mantığı monolitik bir uygulama ile gerçekleştirilir. Ve uygulamanın bulunduğu sunucu, yük olmasa bile sürekli çalışıyor.
Sunucusuz ortama geçmek için uygulamayı mikro görevlere bölüyoruz. Her biri için kendi fonksiyonumuzu yazıyoruz. Fonksiyonlar birbirinden bağımsızdır ve durum bilgisini (durumsuz) saklamaz. Hatta farklı dillerde yazılmış bile olabilirler. Bunlardan biri "düşerse" uygulamanın tamamı durmayacaktır. Uygulama mimarisi şöyle görünecek:
Sunucusuz'da işlevlere bölünme, mikro hizmetlerle çalışmaya benzer. Ancak bir mikro hizmet çeşitli görevleri gerçekleştirebilir ve bir işlevin ideal olarak bir görevi yerine getirmesi gerekir. Görevin istatistikleri toplamak ve bunları kullanıcının isteğine göre görüntülemek olduğunu düşünelim. Mikro hizmet yaklaşımında, bir görev iki giriş noktasına sahip bir hizmet tarafından gerçekleştirilir: yazma ve okuma. Sunucusuz bilişimde bunlar birbiriyle alakası olmayan iki farklı fonksiyon olacaktır. Örneğin istatistikler indirildiğinden daha sık güncelleniyorsa geliştirici bilgi işlem kaynaklarından tasarruf sağlar.
Sunucusuz işlevlerin servis sağlayıcı tarafından belirlenen kısa bir süre (zaman aşımı) içinde yürütülmesi gerekir. Örneğin AWS için zaman aşımı süresi 15 dakikadır. Bu, uzun ömürlü işlevlerin gereksinimlere uyacak şekilde değiştirilmesi gerektiği anlamına gelir; Sunucusuz'u günümüzün diğer popüler teknolojilerinden (konteynerler ve Hizmet Olarak Platform) ayıran şey budur.
Her fonksiyona bir olay atadık. Bir olay, bir eylemin tetikleyicisidir:
Olay
Fonksiyonun gerçekleştirdiği eylem
Depoya bir ürün resmi yüklendi.
Resmi sıkıştırın ve bir dizine yükleyin
Veritabanındaki fiziksel mağaza adresi güncellendi
Haritalara yeni bir konum yükleme
Müşteri malların parasını öder
Ödeme işlemini başlat
Olaylar HTTP istekleri, veri akışı, mesaj kuyrukları vb. olabilir. Olay kaynakları, verilerdeki değişiklikler veya oluşumlardır. Ayrıca işlevler bir zamanlayıcı tarafından tetiklenebilir.
Mimari geliştirildi ve uygulama neredeyse sunucusuz hale geldi. Daha sonra servis sağlayıcıya gidiyoruz.
Sağlayıcı tarafından
Sunucusuz bilgi işlem genellikle bulut hizmet sağlayıcıları tarafından sunulur. Farklı şekilde adlandırılırlar: Azure İşlevleri, AWS Lambda, Google Bulut İşlevleri, IBM Bulut İşlevleri.
Hizmeti sağlayıcının konsolu veya kişisel hesabı aracılığıyla kullanacağız. İşlev kodu aşağıdaki yollardan biriyle indirilebilir:
- web konsolu aracılığıyla yerleşik düzenleyicilere kod yazın,
- kodu içeren arşivi indirin,
- genel veya özel git depolarıyla çalışın.
Burada işlevi çağıran olayları ayarlıyoruz. Etkinlik setleri farklı sağlayıcılar için farklılık gösterebilir.
Sağlayıcı, altyapısında Hizmet Olarak İşlev (FaaS) sistemini oluşturdu ve otomatikleştirdi:
- İşlev kodu, sağlayıcı tarafında depolanır.
- Bir olay meydana geldiğinde, hazırlanan ortama sahip konteynerler otomatik olarak sunucuya dağıtılır. Her işlev örneğinin kendi yalıtılmış kapsayıcısı vardır.
- Depolamadan fonksiyon konteynere gönderilir, hesaplanır ve sonucu döndürür.
- Paralel olayların sayısı artıyor, konteynırların sayısı artıyor. Sistem otomatik olarak ölçeklenir. Kullanıcılar işleve erişmezse işlev devre dışı kalacaktır.
- Sağlayıcı, konteynerlerin boşta kalma süresini ayarlar - bu süre zarfında konteynerde işlevler görünmezse, imha edilir.
Bu şekilde Sunucusuz'u kutudan çıkarıyoruz. Hizmet için kullandıkça öde modelini kullanarak ve yalnızca kullanılan işlevler için ve yalnızca kullanıldıkları süre için ödeme yapacağız.
Geliştiricilere hizmeti tanıtmak için sağlayıcılar 12 aya kadar ücretsiz test sunuyor ancak toplam hesaplama süresini, aylık istek sayısını, fonları veya güç tüketimini sınırlıyor.
Bir sağlayıcıyla çalışmanın temel avantajı altyapı (sunucular, sanal makineler, konteynerler) konusunda endişelenmeme yeteneğidir. Sağlayıcı ise FaaS'ı hem kendi geliştirmelerini hem de açık kaynak araçlarını kullanarak uygulayabilir. Onlar hakkında daha fazla konuşalım.
Açık kaynak tarafından
Açık kaynak topluluğu son birkaç yıldır Sunucusuz araçlar üzerinde aktif olarak çalışıyor. Pazarın en büyük oyuncuları aynı zamanda sunucusuz platformların geliştirilmesine de katkıda bulunuyor:
- Google geliştiricilere açık kaynak aracını sunuyor - . Geliştirilmesine IBM, RedHat, Pivotal ve SAP katıldı;
- IBM Sunucusuz bir platformda çalıştı daha sonra Apache Vakfı'nın bir projesi haline gelen;
- Microsoft platform kodunu kısmen açtı .
Sunucusuz çerçeveler yönünde de geliştirmeler devam etmektedir. и önceden hazırlanmış Kubernetes kümelerinin içine dağıtılır, hem Kubernetes hem de Docker Swarm ile çalışır. Çerçeve bir tür denetleyici görevi görür; istek üzerine küme içinde bir çalışma ortamı hazırlar ve ardından orada bir işlev başlatır.
Çerçeveler, aracı ihtiyaçlarınıza uyacak şekilde yapılandırmak için yer bırakır. Böylece Kubeless'te geliştirici, işlevin yürütülmesi zaman aşımını yapılandırabilir (varsayılan değer 180 saniyedir). Fisyon, soğuk başlatma problemini çözmek amacıyla bazı konteynerlerin sürekli çalışır durumda tutulmasını öneriyor (ancak bu, kaynak kesintisi maliyetlerine yol açıyor). OpenFaaS her zevke ve renge uygun bir dizi tetikleyici sunar: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT'ler ve diğerleri.
Başlamak için talimatlar çerçevelerin resmi belgelerinde bulunabilir. Onlarla çalışmak, bir sağlayıcıyla çalışmaya göre biraz daha fazla beceriye sahip olmayı gerektirir; bu, en azından CLI aracılığıyla bir Kubernetes kümesi başlatma yeteneğidir. En fazla diğer açık kaynak araçlarını ekleyin (örneğin, Kafka kuyruk yöneticisi).
Sunucusuz ile nasıl çalışırsak çalışalım (bir sağlayıcı aracılığıyla veya açık kaynak kullanarak), Sunucusuz yaklaşımın bir takım avantaj ve dezavantajlarına sahip olacağız.
Avantajları ve dezavantajları açısından
Sunucusuz, ekiplerin tek bir platforma bağlı kalmadan çok dilli modda çalışabileceği bir konteyner altyapısı ve mikro hizmet yaklaşımı fikirlerini geliştirir. Bir sistem oluşturmak basitleştirilmiştir ve hataların düzeltilmesi daha kolaydır. Mikro hizmet mimarisi, sisteme monolitik bir uygulamadan çok daha hızlı bir şekilde yeni işlevler eklemenizi sağlar.
Sunucusuz, geliştirme süresini daha da azaltır, geliştiricinin yalnızca uygulamanın iş mantığına ve kodlamasına odaklanmasına olanak tanır. Sonuç olarak, gelişmelerin pazara sunulma süresi kısalır.
Bonus olarak yük için otomatik ölçeklendirme alıyoruz. ve yalnızca kullanılan kaynaklar için ve yalnızca kullanıldıkları anda ödeme yaparız.
Her teknoloji gibi Sunucusuzun da dezavantajları vardır.
Örneğin soğuk başlangıç süresi böyle bir dezavantaj olabilir (JavaScript, Python, Go, Java, Ruby gibi diller için ortalama 1 saniyeye kadar).
Bir yandan, gerçekte soğuk başlatma süresi birçok değişkene bağlıdır: işlevin yazıldığı dil, kitaplık sayısı, kod miktarı, ek kaynaklarla iletişim (aynı veritabanları veya kimlik doğrulama sunucuları). Geliştirici bu değişkenleri kontrol ettiği için başlatma süresini azaltabilir. Ancak öte yandan geliştirici, konteynerin başlangıç zamanını kontrol edemez; her şey sağlayıcıya bağlıdır.
Bir işlev önceki bir etkinlik tarafından başlatılan kapsayıcıyı yeniden kullandığında, soğuk başlatma sıcak başlangıca dönüşebilir. Bu durum üç durumda ortaya çıkacaktır:
- istemciler hizmeti sıklıkla kullanıyorsa ve işleve yapılan çağrıların sayısı artıyorsa;
- sağlayıcı, platform veya çerçeve bazı kapsayıcıları her zaman çalışır durumda tutmanıza izin veriyorsa;
- geliştirici işlevleri bir zamanlayıcıda çalıştırıyorsa (örneğin her 3 dakikada bir).
Birçok uygulama için soğuk başlatma sorun değildir. Burada hizmetin türünü ve görevlerini geliştirmeniz gerekir. Bir saniyelik başlatma gecikmesi, bir iş uygulaması için her zaman kritik değildir ancak tıbbi hizmetler için kritik hale gelebilir. Bu durumda sunucusuz yaklaşım muhtemelen artık uygun olmayacaktır.
Sunucusuzun bir sonraki dezavantajı, bir işlevin kısa ömrüdür (işlevin yürütülmesi gereken zaman aşımı).
Ancak uzun ömürlü görevlerle çalışmanız gerekiyorsa hibrit bir mimari kullanabilirsiniz; Sunucusuz'u başka bir teknolojiyle birleştirin.
Tüm sistemler Sunucusuz düzeni kullanarak çalışamayacaktır.
Bazı uygulamalar yürütme sırasında verileri ve durumu saklamaya devam edecektir. Bazı mimariler yekpare kalacak, bazı özellikler ise uzun ömürlü olacak. Ancak (bulut teknolojileri ve ardından konteynerler gibi) Sunucusuz, büyük geleceği olan bir teknolojidir.
Bu bağlamda Sunucusuz yaklaşımı kullanma konusuna sorunsuz bir şekilde geçmek istiyorum.
Uygulama yönünden
2018 için Sunucusuz kullanım yüzdesi . Teknolojiyi halihazırda hizmetlerinde uygulayan şirketler arasında Twitter, PayPal, Netflix, T-Mobile, Coca-Cola gibi pazar devleri yer alıyor. Aynı zamanda, Sunucusuzun her derde deva olmadığını, belirli bir dizi sorunu çözmeye yönelik bir araç olduğunu anlamalısınız:
- Kaynak kesinti süresini azaltın. Az sayıda çağrının olduğu servisler için sürekli sanal makine bulundurmanıza gerek yoktur.
- Verileri anında işleyin. Resimleri sıkıştırın, arka planları kesin, video kodlamasını değiştirin, IoT sensörleriyle çalışın, matematiksel işlemler gerçekleştirin.
- Diğer hizmetleri birbirine “yapıştırın”. Dahili programlara sahip Git deposu, Slack'te Jira ve takvim ile sohbet botu.
- Yükü dengeleyin. Buraya daha yakından bakalım.
Diyelim ki 50 kişinin çektiği bir servis var. Altında zayıf donanıma sahip bir sanal makine var. Zaman zaman hizmetin üzerindeki yük önemli ölçüde artıyor. O zaman zayıf donanım başa çıkamaz.
Yükü örneğin üç sanal makineye dağıtacak bir dengeleyiciyi sisteme dahil edebilirsiniz. Bu aşamada yükü doğru bir şekilde tahmin edemediğimiz için belirli miktarda kaynağı “yedek” olarak çalışır durumda tutuyoruz. Ve kesinti için fazla para ödüyoruz.
Böyle bir durumda hibrit bir yaklaşımla sistemi optimize edebiliriz: yük dengeleyicinin arkasında bir sanal makine bırakır ve işlevlerin bulunduğu Sunucusuz Uç Noktaya bir bağlantı koyarız. Yük eşiği aşarsa dengeleyici, istek işlemenin bir kısmını devralan işlev örneklerini başlatır.
Böylece Sunucusuz, çok sayıda isteğin çok sık değil, yoğun bir şekilde işlenmesinin gerekli olduğu yerlerde kullanılabilir. Bu durumda birden fazla fonksiyonu 15 dakika çalıştırmak, bir sanal makine veya sunucunun sürekli bakımını yapmaktan daha karlı olur.
Sunucusuz bilgi işlemin tüm avantajları nedeniyle, uygulamadan önce öncelikle uygulama mantığını değerlendirmeli ve Sunucusuz'un belirli bir durumda hangi sorunları çözebileceğini anlamalısınız.
Sunucusuz ve Selectel
Selectel'de zaten kontrol panelimiz aracılığıyla. Şimdi kendi FaaS platformumuzu oluşturuyoruz. Geliştiricilerin, sorunlarını kullanışlı ve esnek bir arayüz aracılığıyla Sunucusuz kullanarak çözebilmelerini istiyoruz.
İdeal FaaS platformunun ne olması gerektiği ve Sunucusuz'u projelerinizde nasıl kullanmak istediğiniz konusunda fikirleriniz varsa bunları yorumlarda paylaşın. Platformu geliştirirken isteklerinizi dikkate alacağız.
Makalede kullanılan malzemeler:
Kaynak: habr.com