Özel Yapıları Dağıtmak İçin Neden Sunucusuz Bilgi İşleme Geçtik?

Panumas nikhomkhai adlı kişinin Pexels'daki fotoğrafı

Performans pazarlamacılarını , Daha Az Endişelenmeden Daha Fazlasını Yapma konusunda güçlendirme taahhüdümüzün bir parçası olarak, TUNE'daki ekipler her zaman müşterilerimize hizmet etmenin yeni yollarını arıyor. Bu durumda, Çözüm Mühendisliği ekibimiz, platformumuzdaki özel yapıları nasıl dağıttıklarını ve desteklediklerini basitleştiren bir teknoloji keşfetti. Sonuç olarak, artık ihtiyaç duydukları çözümleri oluşturmak için daha fazla müşteriyle çalışarak daha fazla zaman (ve daha az para) harcayabilirler.

TUNE'da, ağların ve reklamcıların dijital pazarlama kampanyalarını, yayıncı ilişkilerini, ödemelerini ve daha fazlasını tek bir kod satırı yazmak zorunda kalmadan kutudan çıkar çıkmaz yönetmelerine olanak tanıyan esnek, kapsamlı bir performans pazarlama platformu sunmaktan gurur duyuyoruz. . Ancak bazen, tam olarak yönetilen diğer SaaS sistemlerinde olduğu gibi, müşterilerimiz yalnızca kolları sıvayıp eski kod düzenleyiciyi çalıştırarak elde edilebilecek özel yapılandırmalar, işlevler veya entegrasyonlar gerektirir. Yakın zamanda, bu çözümleri oluşturma şeklimizi değiştiren yeni bir teknolojiye geçiş yaptık: sunucusuz bilgi işlem.

Bu yazıda, özel geliştirme ile karşılaştığımız sorunları, sunucusuz derleme sürecimizi kurmak için attığımız adımları ve bu yeni metodolojinin maliyet ve ölçek zorluklarını nasıl çözdüğünü anlatacağım.

Zorluk: Özel Çözümlere Yönelik Talebi Karşılamak

TUNE'da Çözüm Mühendisliği ekibini ilk kurduğumuzda, her özel müşteri yapısını ayrı bir yapı olarak ele aldık. Bu yapıların çoğu, genellikle platformumuzda özel bir sayfa olarak dağıtılan bir ön uç bileşenine ve bir sunucu, bir veritabanı ve sunucuları güncel tutmak için gereken diğer herhangi bir altyapıdan oluşan bir arka uç bileşenine sahipti. -tarih ve çalışır durumda.

İlk başta, bu metodoloji bizim için çalıştı. Birkaç karmaşık özel yapıya sahip küçük, yalın bir ekibe sahip olarak, her yapı için farklı bir sunucu sağlama ve yapılandırma yöntemimiz bizim için çalıştı. Müşterilerimiz için harika deneyimler yaratmamızı sağladı.

Ancak yapı sayısı arttıkça sorunlarla karşılaşmaya başladık:

• Çok fazla sunucu! Tahmin edebileceğiniz gibi, yapı başına en az iki kutu sağlamak, çok fazla sunucuya sahip olmamıza neden oldu. Çok sayıda sunucu ve bunlara eşlik eden tüm sıkıntılar (güvenlik güncellemeleri ve yedeklemeler gibi) bize kabul etmek istediğimizden daha fazla zamana mal oluyordu.
• Bu sunucuları açık tutun. Her sunucunun kendi varlığı olduğu için, her sunucunun her zaman çalışır durumda ve çalışır durumda olduğundan emin olmaktan sorumluyduk.
• PHP bana göre değil. Yapılarımızın çoğu, temel bir Docker PHP görüntüsünden döndürülür. Ancak ekibimiz büyüdükçe, insanları bir Python sihirbazıyken müşteri yapılarını PHP 5.0'da yazmaya zorlamanın hiçbir anlam ifade etmediğini biliyorduk.
• Bu pahalılaşıyor. Tüm sunucularımız ec2/RDS üzerinde dağıtıldığında, önemli bir aylık maliyet görmeye başladık.
• Önce güvenlik. Bu hizmetler hassas müşteri verilerini işlediğinden, bu verilerin güvenliğini sağlamak için genel URL'lerimiz için bir kimlik doğrulama yöntemi sağlamamız gerekiyordu.
• Cron'lar zordur. Pek çok arka uç hizmeti cron komut dosyalarından oluşuyordu ve bunları yönetmenin etkili bir yolu yoktu.

Bu zorluklar ortaya çıkarken, müşteri yapılarımıza arka uç işlevselliği sağlamak için daha basit, daha uygun maliyetli bir yol bulmamız gerektiğini biliyorduk. Ancak çok fazla tartışmadan ve bir çözüm için net bir öncünün olmamasından sonra, fikirlerimiz tükenmeye başlamıştı. (Ayrıca, çılgınca büyüyen yeni özel yapılara olan talep ile zaman kesinlikle bizden yana değildi.)

Çözüm: Kurtarma için Sunucusuz Bilgi İşlem

Sunucusuz bilgi işlemi duymadıysanız, ilk duyduğumuzda aynı şeyi merak ediyor olabilirsiniz. Sunucu olmadan kodu nasıl çalıştırabilirsiniz? (Endişelenme; temel programlama anlayışınız hala doğru ve hayır, bunu yazmadan önce mutlu saatler özelini kötüye kullanmadık.)

"Sunucusuz" , yeni bir teknoloji için gerçekten kafa karıştırıcı bir terimdir, çünkü - aptal olmayalım - kesinlikle hala bir sunucu yürütme kodu vardır. Peki sunucusuz tam olarak nedir ?

Sunucusuz bilgi işlem , bulut sağlayıcısının sunucu olarak hareket ettiği ve makine kaynaklarının tahsisini dinamik olarak yönettiği bir bulut bilgi işlem yürütme modelidir. - Vikipedi

Sunucusuz bulut çözümleri, sunucularla ilgili sorunları düşünmeden uygulamalar ve hizmetler oluşturmanıza ve çalıştırmanıza olanak tanır. Esasen sunucusuz bilgi işlem, en iyi yaptığınız şeyi yapmanıza olanak tanır: kod yazma.

Sunucusuz Kurulum Süreci

Sunucusuz teknolojinin nasıl çalıştığının özünü size göstermek için, bu işlevi kurmak için kullandığımız adımların üzerinden geçeceğim.

Not: Sunucusuz işlevselliğe sahip birçok bulut sağlayıcısı vardır. Bu örnekte AWS Lambda kullanıyoruz .

1. 1. İlk olarak, yeni bir Lambda işlevi oluşturun ve “ Planlar ” öğesini seçin. Ardından, anahtar kelime alanına “ http ” yazın ve Python veya Node mikro hizmet-http-uç noktasını seçin. (Taslaklar, geliştirmeyi daha hızlı hale getirmek için önceden hazırlanmış kod bloklarıdır. Bu ne kadar harika?) Bir seçim yaptıktan sonra, “ Yapılandır ” a tıklayın .
      

      AWS Lambda'da bir işlev nasıl yapılandırılır.

      
   2. Bir işlev adı ve rol ekleyin. Ardından , “ API Anahtarıyla Aç ” güvenlik seçeneğiyle bir API Ağ Geçidi tetikleyicisi seçin . Bu API ağ geçidi, Lambda işlevinizi tetikleyecek genel bir URL sağlayacaktır. API anahtarının eklenmesi, şiddetle tavsiye edilen bir kimlik doğrulama yöntemi sağlar.
      

      AWS Lambda'da açık bir API ağ geçidi anahtarı ayarlama.

   3. Fonksiyonu oluşturduktan sonra artık kodunuz için konfigürasyonlar yapabilirsiniz. Gördüğünüz gibi, plan size bir Dinamo tablosuyla etkileşime girmenize izin veren harika bir giriş noktası kancası verdi (eğer bir veritabanı eklemek istiyorsanız). Genel URL yüklendiğinde lambda_handler altında ne varsa yürütülür. Bir de veritabanı eklediğimiz için Dinamo'ya gidelim ve bir tane oluşturalım.
      

      AWS Lambda'da Dinamo veritabanı tablosu oluşturma.

   4. Dinamo tablosu oluşturulduktan sonra, bu Lambda işlevine genel bir URL'den bir çağrı yapalım. İşlevinize geri dönün ve üstteki “ API Ağ Geçidi ” simgesine tıklayın. Uç noktanın ve API anahtarının sizin için zaten oluşturulduğunu görmelisiniz.
      

      AWS Lambda işlevlerinde API Ağ Geçidi simgesi nerede bulunur.

   5. Şimdi terminali açın ve “ x-api-key” başlığının altına API anahtarını ekleyin, ardından TableName sorgu dizesi parametresinin altına oluşturduğunuz tablo adını ekleyin.
      

      Bitirmek için terminalde anahtarınızı ve veritabanı adınızı girin.

Bu kadar! Artık bir veritabanına bağlı çalışan, güvenli bir arka ucunuz var. Tek gereken beş kolay adımdı.

Sunucusuz Bilgi İşlem Zorluklarımızı Nasıl Ele Aldı?

Şimdi size sunucusuz yapıların nasıl kurulacağını gösterdiğimize göre, bir göz atalım ve bu bulut tabanlı modelin kontrol listemize göre nasıl bir performans gösterdiğini görelim.

• Çok fazla sunucu! Sunucusuz … yani artık sunucu yok, değil mi?
• Bu sunucuları açık tutun. Sunucusuz bilgi işlem, bulut sağlayıcısı tarafından yönetildiğinden, sunucularınızı izlemek için bu sağlayıcıların (savaşta sertleştirilmiş, kanıtlanmış yöntemleriyle birlikte) avantajından yararlanırsınız. Sherlock Holmes oynamak isteyenler için, Cloudwatch'daki işleviniz tarafından tüm sunucu günlüklerinin çıktısını da görebilirsiniz .
• PHP bana göre değil. Sunucusuz modeller, C#, Python, NodeJS, Go ve hatta Java ile yazmanıza olanak tanır.
• Bu pahalılaşıyor. Sunucusuz çözümlerde maliyetler, yürütme süresine (100 milisaniyede) ve aktarılan veri miktarına göre ölçülür. Sunucularınızın boşta kaldığı süreyi içeren aylık ödemenin aksine, yalnızca kullandığınız kadar ödersiniz. 100 ms yürütme başına 0,000000208 ABD Doları gibi düşük maliyetlerle sunucusuz bilgi işlem, size önemli miktarda nakit tasarrufu sağlayabilir.
• Önce güvenlik. Sunucusuz güvenli mi? Yerleşik bir API anahtarı kimlik doğrulama sistemi ile, bahse girersiniz.
• Cron'lar zordur. Yerel olarak Cloudwatch üzerine kurulu bir cron yönetim sistemi ile, sadece bir zaman aralığı belirleyin ve bunu unutun. Cloudwatch, tüm günlük kaydı ve yürütme işlemlerini gerçekleştirir.

Son düşünceler

TUNE'daki Çözüm Mühendisliği ekibi için sunucusuz bilişime geçiş oyunun kurallarını değiştirdi. Kullanım kolaylığı, maliyet tasarrufu ve çevik dostu özellikleri, tüm yeni müşteri yapılarını ele alma şeklimizi değiştirdi. Sunucusuz bulut tabanlı çözümler, sunucu tarafı bilgi işlem dünyasını değiştirecek şekilde ayarlanmıştır. Sizi bilmem ama kesin olan bir şey var: TUNE Çözümleri Mühendislik ekibi hazır.

TUNE platformu ve sunduğumuz özel geliştirme hizmetleri hakkında daha fazla bilgi edinmek için Profesyonel Hizmetler sayfamızı ziyaret edin .