Altyapının eksiksiz bir şekilde elden geçirilmesi, herhangi bir teknoloji ekibinin üstlendiği en zorlu girişimlerden biridir. Çoğu zaman, belirli bir yığının arkasındaki ekip, pek çok öngörülemeyen duruma yol açacak şekilde ekipten ayrılmış olabilir. Ancak, mPharma'da durum böyle değildi, yıllar içinde sistemin kritik parçaları arasında yeterli bilgi aktarımına sahip olduk. Bu yazıda, çekirdek altyapımızı Marathon/Mesos'tan Kubernetes'e taşımayı nasıl başardığımızı paylaşmak istiyorum.

Yıllar boyunca, Afrika'daki bir hastanın sürekli artan ihtiyaçlarına dayalı olarak aktif olarak bir dizi ürün geliştiriyoruz. Birkaçını sıralamak gerekirse;

1. Modern eczane yönetimine yönelik tescilli uygulamamız Bloom'u başarıyla 9 ülkeye ölçeklendirdik (Bu makalenin yazıldığı tarih itibariyle bu sayı 10'a yükseldi).
2. Ayrıca reçetesiz (OTC) ilaçları çevrimiçi satın almak ve evinize teslim ettirmek için bir e-ticaret platformu olan myMutti'yi de kullanıma sunduk .
3. Ürünlerin depomuzdan Marketplace olarak bilinen ortak eczanelere ve hastanelere hareketini daha iyi takip etmek için bir depo ve lojistik uygulaması oluşturduk ve kullanıma sunduk.
4. Uyuşturucuları taşıma şeklimizi daha da dijitalleştirmek için bir son mil teslimat uygulaması başlattık.
5. Ayrıca mutti doktor programımızı geliştirmek için Bloom'un içinde teşhis verilerini toplamaya başladık .

Mühendislik ekibi yıllardır temel altyapımızı taşıma olasılığını düşünüyordu. Bununla birlikte, bir şirket olarak patlayıcı büyümemiz, temel altyapımızı yeniden icat etmek yerine yapı ürünlerine öncelik vermemize yol açtı. Ocak 2021'de, altyapımızı yeniden keşfetmemiz gerektiğini, aksi takdirde şirket ve ekip olarak yaşadığımız büyüme türünü destekleyemeyeceğimizi anladık.

mPharma'daki temel altyapı, yıllar boyunca farklı aşamalardan geçti, ancak bu, tamamen elden geçirme ve aynı zamanda altyapımızın şirketin ve bir bütün olarak ekibin büyümesiyle eşleşmesini sağlama konusundaki ilk girişimimizdi.

Tartışmalarımız, çözmeye çalıştığımız soruna odaklanarak başladı. Bu, belirli bir aracı seçerken önyargı unsurlarını azaltmamıza ve en iyi çözüme odaklanmamıza yardımcı oldu. Birbirimize sorduğumuz kilit soru, "Hangi yığının büyümemize yardımcı olacağı" idi. Beş temel alana odaklanarak başladık;
1. Ölçeklenebilirlik
2. Geliştirici Deneyimi
3. Topluluk Desteği
4. Güvenlik
5. Maliyet

Yukarıdakilere ve birkaç hararetli tartışmaya dayanarak Kubernetes ile gitmeyi seçtik.

Kubernetes nedir?

Kubernetes.io'ya göre , K8s olarak da bilinen Kubernetes, kapsayıcılı uygulamaların dağıtımını, ölçeklenmesini ve yönetimini otomatikleştirmek için açık kaynaklı bir sistemdir. Kolay yönetim ve keşif için bir uygulamayı oluşturan kapsayıcıları mantıksal birimler halinde gruplandırır. Kubernetes, Google'da üretim iş yüklerini çalıştırma konusundaki 15 yıllık deneyimi, topluluktan gelen türünün en iyisi fikir ve uygulamalarla birleştirir.

Geçiş Süreci

Bu ölçekteki herhangi bir geçiş genellikle hizmet aksama sürelerine yol açar, amacımız ya bunu tamamen ortadan kaldırmak ya da oluşumunu en aza indirmekti. İlk adımımız, bir proje lideri tarafından yönetilen bir proje ekibi oluşturmaktı. Proje lideri, geçişin uçtan uca yönetimini ele almaktan ve ilgili tüm paydaşların farklı girişimlerin ilerlemesinden haberdar olmasını sağlamaktan sorumluydu. Bunlardan bazıları;
1. Ek sunucuları döndürmenin ek maliyeti ne olacak?
2. Geliştirme iş akışında kesintilere yol açmadan uygulamaları kolayca Kubernetes'e dağıtmanın en iyi yolu nedir?
3. Dağıtım başarısını nasıl ölçeceğiz?
4. Geçişten sonra trafiği eski sunucularımızdan yeni sunucularımıza verimli bir şekilde nasıl geçireceğiz?

Ek sunucuları döndürmenin ek maliyeti ne olacak?

Ekip olarak ana odak noktalarımızdan biri maliyetleri azaltmaktır çünkü bu tasarruflar, mPharma'nın hastalara daha düşük ilaç maliyeti sunabilen bir şirket olarak tercüme edilmesini sağlar. Kavram kanıtı (POC) projeleri için bir programları olup olmadığını öğrenmek için bulut sağlayıcımızla konuşmaya başladık. İstikrarlı bir konuma gelene kadar bulut sağlayıcımızın taşıma maliyetimizi karşılamasını sağlamayı başardık. Bu nedenle, geçişimizin ilk birkaç haftasında esasen 0 ABD doları harcadık.

Geliştirme iş akışında kesintilere neden olmadan uygulamaları kolayca Kubernetes'e dağıtmanın en iyi yolu nedir?

Mühendislerin yazılım geliştirme yaşam döngüsünü kesintiye uğratmadan bu geçişi yapmanın bir yolunu istedik. Unutulmaması gereken en önemli nokta, geçiş sırasında hastalar için ürünler geliştirmeye devam etmemiz ve işin endişe verici bir hızla büyümeye devam etmesidir. Bu geçişten önce, tüm hizmetlerimizde dağıtım yönergelerini içeren bir .yaml dosyası vardı. Yeni bir konuşlandırma yönergesi seti yazmakla mühendislere aşırı yük bindirmek istemedik. Bu, dağıtım betiğimizi GitLab'da merkezileştirmeye karar vermemizi sağladı. Bu betik içinde, kodu hem Marathon/Mesos'a hem de Kubernetes'e dağıtan bölümlerimiz vardı. Bu, mühendislerin çalışmalarının bu geçiş döneminde etkilenmemesini sağladı.

Geçişten sonra trafiği eski sunucularımızdan yeni sunucularımıza verimli bir şekilde nasıl geçireceğiz?

Bu, geçiş stratejimizin en zorlu ve en zor aşamasıydı. Odak noktamız, hangi yolun hizmet kalitesinde herhangi bir aksamaya yol açmayacağıydı. Trafiği yeni sunuculara geçirmek bizim için zordu çünkü bu geçişi yaparken kimlik doğrulama ve yetkilendirmeyi nasıl yaptığımızı elden geçirdik. Bu da kademeli geçiş yapmamızı imkansız hale getirdi. Tüm hizmetleri aynı anda taşımak zorunda kaldık. Birkaç tartışmadan sonra, bu kararı vermek için trafik verilerini kullanmaya yöneldik. Trafik geçişi yapmak için en iyi zamana karar vermek için uygulamalarımıza giden trafiğe baktık. API ağ geçidimizden gelen verilere baktıktan sonra Cumartesi gecesine karar verdik. Bunun nedeni Pazar günleri ağımızda daha az trafik görmemizdi, dolayısıyla herhangi bir kesinti çok küçük bir patlama yarıçapına sahip olacak. İletişim sürtüşmelerini azaltmak için ofisten çalışmayı da tercih ettik. Elimizdeki görevin kolay olmayacağını bildiğimiz için bir sürü pizza sipariş ettik. 23:00 pm GMT'de trafik geçişini yapmaya başladık.

Dağıtım başarısını nasıl ölçeceğiz?

Adını az duyduğunuz ekiplerden biri de Kalite Güvence ve SRE ekibimizdir. Bu iki ekip, ürettiğimiz ürünlerin en yüksek standartları karşılamasını sağlar. Ancak, Isaac gibi, QA lideri her zaman "Ürünlerin kalitesi sadece QA ekibinin sorumluluğunda değildir" diyecektir. Her şeyin sorunsuz çalıştığından emin olmak için taşıma sonrasında uygulamanın farklı bölümlerini test etmek için hep birlikte çalışmaya karar verdik. Vurgulamayı başaramadığım bir başka önemli alan da, üretime geçmeden önce test ve sahne ortamlarımızı Kubernetes'e taşımamızdı. Bu bize her şeyin uygun şekilde test edildiği ve beklendiği gibi çalıştığı konusunda güven verdi.

Dersler öğrenildi

1. Kullanım ölçütlerine dikkat etmemek

Kubernetes'e dağıttıktan kısa bir süre sonra, uygulama kapalı kalma süreleriyle ilgili olarak kullanıcılarımız tarafından bildirilen bir dizi sorun fark ettik. Uygulamalarımızı taşırken, maliyet düşürücü önlemlere odaklandık, belirli bir kapsayıcıya tahsis edilebilecek bellek ve CPU miktarını sınırladık. Bu, bir bellek veya CPU sınırına ulaştıklarında kapların ölmesine veya yeniden başlatılmasına yol açtı. Bizim için önemli bir ders, eski altyapımızdaki konteyner kullanım ölçümlerine dikkat etmemek ve her bir hizmete kaynakları nasıl tahsis edeceğimize karar vermek için bunu kullanmaktı.

2. Hizmetlerin hizmet sahipleri tarafından yanlış yapılandırılması

Fark ettiğimiz bir başka hata da hizmet sahipleri tarafından yapılan yanlış yapılandırmalar oldu. Servisler için ortam değişkenlerinin ayarlanmasında mühendislerin hata yapmasına yol açan çok sayıda manuel çalışma vardı. Bu, aktif olarak üzerinde çalıştığımız ve hata sayısını sınırlamak için değişkenleri yönetmenin en iyi yolunu bulmaya çalıştığımız bir konu.

3. Birim Eksikliği ve Uçtan Uca Test

Eski altyapımızda kimlik doğrulamayı nasıl ele aldığımız ve mümkün olan en kısa sürede geçiş yapma gereği nedeniyle, CI/CD ardışık düzenimizde birim testini ve uçtan uca testi atladık. Bu, yakalanacak birkaç hataya yol açtı. Başka bir geçiş yapmamız durumunda, bu aşamanın CI/CD sürecine dahil edilmesini her zaman sağlayacağız.

4. Geçiş trafiği:

Eski ve yeni altyapımız arasında geçiş trafiği farklı şekilde ele alınabilirdi. Trafiğin %100'ünü değiştirmek yerine, patlama yarıçapını azaltmak için kademeli olarak yapmaya odaklanabilirdik.

Ekip, geçişin hizmet kalitesinde bir bozulmaya yol açmamasını sağlamaya ve ayrıca müşterilerimizin etkileşimde bulunduğu ürünleri oluşturmaya/iyileştirmeye odaklandığından bu makaleyi yazmak yaklaşık 6 ay sürdü. İşletme içindeki ve dışındaki farklı kilit paydaşlarla etkileşimden yola çıkarak, geçişin başarılı olduğunu söyleyeceğim. Müşterilerimize daha iyi hizmet vermek ve mPharma'nın sağlık alanında yaptığı devasa altyapı yatırımından hastaların yararlanmasını kolaylaştırmak için hizmetlerimizi geliştirmeye devam ediyoruz.