2 Nisan 2024 Salı

Sancılı Bir Geçis Hikayesi (AWS -> GCP)

     S.A. Arkadaşlar,

    Bugün size çok sancı çektiğimiz bir geçiş hikayesinden bahsetmek istiyorum. Amazon tarafında çalışan kısmi stabil ortamı Google ortamına taşımak ve burada çektiğimiz ve hala da çekiyor olduğumuz problemlei anlatmak istiyoruz. Ben devops'cu (platform olarak da kullandım yazı içerisinde) değilim, onların karşılaştıkları problemler muhtelemen çok daha fazladır, fakat yazılım tarafında karşılaşıp devops ekibi ile dirsek temasında bulunarak çözdüğümüz problemlerden bahsedeceğiz. Emeği geçen tüm arkadaşlara teşekkürlerimi de borcumu bilirim. Hazırsak başlayalım.

     Öncelikle nasıl bir sisteme sahip olduğumuzdan bahsetmek istiyorum. 12 mikroservis, 2 gateway, 2 private Nuget kütühanesi, 2 adet de son kullanıcıya ait servsimiz (uygulamamız) var. Bununla birlikte arka tarafta postgre, mongodb, elastic, redis ve rabbitmq gibi bağımlılıklarımız var. Bunların hepsini göz önüne alıp taşımak bizim için büyük bir riskti, bunu neden mi yapıyoruz peki, olay tamamen duygusal :) Bunun yanında ben de açıkçası İsrail'e verdiği açık destekten dolayı taşıma işine baya mutlu oldum. Google sanki destek vermiyor mu diyeceksiniz, ben açık beyan ettiğini duymadım açıkçası.
    
    Burada bazı teknik noktalara değinecek olsam da yazı daha çok genel süreç boyunca neler yaşadık, nasıl sancılar çektik, hala karşılaşmaya devam ettiğimiz problemler var mı gibi sorulara daha çok odaklanacağız. Çünkü bu geçiş gerçekten bir süreç, şu bu geçişi tamamlamış olsak da yaptık oldu demek için biraz daha gözyaşı dökmemiz gerekiyor...

    Ayrıntılara girmeden önce elektrikl şarj istasyonu işi yaptığımızı ve Türkiye'nin farklı yerinde IoT cihazlarımızın olduğunu söylemekte fayda var. Açıkçası beni de en çok korkutan nokta buydu. Çünkü bu cihazların güvenlik sebebiyle belirli bir süre sonra yapılan istekler cevap bulmadığında kendini kapatıyor ve bize de tahmin ederseniz ki muzzam bir operasyon maliyeti çıkarıyor. Bunun sancılarını şuradaki yazıda paylaşmıştık, dileyen bir göz atabilir.

    Unutmadan söyleyeyim, bu canlı geçişi yapmadan önce de uzun bir süre GCP test ortamında kullandık, birçok problemi de burada tespit edip çözdük, burada da oldukça güzel işler çıkardık, tüm bunları yaparken ekip farklı birçok iş de yaptığı için bölünmeler, kafa karışıklıklar, stresli zamanlar alıp başını gidiyor. Bir de üstten de gelen hadi artık geçelim konusundan hiç bahsetmiyorum :)

    Büyük gün gelip çatmadan önce yaptığım en kritik işlerden biri servislerin doğru bir şekilde fakat çok yavaş çalışması idi. Fiziksel cihaz testlerimizi (araba şarj etme, ödeme alma, şarj bitirme ...) yapıyoruz, her şey yolunda ama şarjın durumun gösterilmesi veya benzer birçok akışta yavaşlık var. Biz kod aynı kod diyoruz, platform ekibi servisler aynı şekilde ayağa kaldırıldı diyor. Bu dönemlerde platform ekibi ile sık sık birlikte çalışıp hataları tespit etmeye çalışıyorduk (onların tarafında anlatacak muhtemelen anlatacak daha çok şey vardır). Bu bahsettiğimz durumda her servis çağrısında yaklaşık 1dk'lık muazzam bir bekleyiş olduğunu tespit ettik ve servislerin bu haliyle ilgili otomatik bir bekleme süresi vardı o kaldırıldı. Testlerimizi yapmaya devam ettik, o bekleme süresi tüm servisler genelinde 19-20 sn civarına düştü. Bu bizi çok mutlu etse de hala yeterli değildi. Burada ilginç olan nokta ise ilk istek 19-20 sn sürer iken aradan gelen isteklerde her şey mükemmel gözüküyordu. Platform ekibine ısrarla burada dikkat etmemiz gereken bir durum olduğunu söylesek de onların açısından her şey normal gözüküyordu. Ayağa kalkan servisler mi o arada düşüyor ya da ne olabilir diye bakarken instance'leri en az 1 tane her zaman ayakta olacak şekilde ayarladık. Freeze (dondurma) özellikleri vardı, onları iptal ettik yine de bu problem çözülmedi. Tamam vazgeçtik bulamıyoruz dedikten 2 saat sonra platform bize bir değişiklik yaptığını ve test etmemizi rica ettiler. Ve gerçekten problem çözülmüştü, heyecanle ne yaptıklarını sorduğumda AWS tarafında varsayılan olarak gelen "cpu allocation always" burada "istek başına" ayarlı idi. O yüzden ilk istek yavaş sonrasındakiler hızlı oluyordu. Bunu da aktif ettikten sonra artık bütün her şey hazırdı, tabii bizim gözümüzde :)

    Canlı geçiş öncesinde bizi engelleyen 1-2 konuya değinip uzunca bir paragraf oldu, fakat sonrası hiç mi sıkıntı çıkmadı, çıkmaz olur mu :)

    Veritabanlarını taşıma işlemi geçiş toplantısında tamamlanmıştı. Postgresql ve mongodb'leri kontrol ettiğimizde veriler doğru bir şekilde geliyordu. Zaten daha önce benzer işlemleri yaptığımız için çok sıkıntı yaşamadık. Zaten o arada tüm servisleri de kapattığımız için verileri alıp taşımak çok da zor olmadı. Taa ki sabaha kadar. Sabah ilk gelen mesaj toplam kazancın dün ile aynı olmadığıyla ile ilgiliydi. Oysa veritabanı taşınmıştı, kontrol etmiştik, ne değişti :) Mongodb tarafında veriyi taşırken üzerine yazıldığı için bir yerde maalesef karışıklık olmuştu ve güncellenen bazı veriler kaybolmuştu. Bu çok büyük sorun olsa da gün içinde buna da müdahele ederek bunu çözmeyi başardık (biraz sancılıydı ama oralar pek girmiyorum :) ). Bununla ilgili neden böyle, bir daha olmaması için neler yapmalıyız noktalarımızı aldıktan sonra hayatımıza devam ettik.

    Biraz da canlı geçişi sonrası çıkan ve üzerinde çalıştığımız birkaç noktaya değinmek istiyoruz.

    Burada gelen ilk şikayet "İşlemler" sayfasının geç gelmesi idi. İncelemeleri yaptığımızda gerçekten de yavaşlık var. Koda baktığımızda refactor edilmesi gereken noktalar olduğunu tespit ettik, bununla ilgili çalışmalara başladık, fakat daha önce aynı kod nasıl hızlı çalışıyordu kısmıyla ilgili de platform ekibi çalışmaya devam ediyor. 

    IoT cihazlarımızın olduğundan bahsetmiştik, bizim adımıza en büyük sevinç burada cihazları kaybetmeden yeni ortama başarılı bir şekilde aktarabilmekti. Burada da ufak bir problem yaşadık, eski ortam ayakta olduğu sürece cihazlar eskiye istek atmaya devam ediyordu (yönlendirme yapmamıza rağmen). Yani log'lar hala AWS'ye gelmeye devam ediyordu. Amazon'daki tüm servisleri durduktan sonra cihazlar artık doğru yere istek atıyordu (Fizikzel sebeplerden dolayı resetleme işlemi yapamıyoruz). Neyse ki bu çözüm işe yaradı ve korktuğumuz gibi cihazlarda kopma olmadı. An itibariyle burada 1 güzel 1 kötü durumumuz var. Kötü olan kısım cihazlarda anlık kopmalar meydana geliyor. Bunlar şarj işlemi yapmaya engel değil fakat sahadan bazen 2 kere denedikten sonra şarj işlemi başladı gibi geri dönüşler alıyoruz. Güzel olan ise daha önce cihazlar koptuğunda (socket aborted olduğunda) bunlar genelde başarılı bir şekilde hazır hale gelmiyordu (bununla ilgili geliştirmeyi yapmış olsak da bazen ilgili servise reset atmamız gerekiyordu), fakar amazon sonrası artık cihazlarımız bu bahsettiğim kopmalar olsa dahi kısa sürede hazır hale dönebiliyor (bu da nedenini an itibariyle bulamadığımız ama bizi mutlu eden bir durum)

    Aws üzerinde tuttuğumuz başka bir yapı şirket için kullandığımız NuGet paketleriydi. Bununla ilgili dotnet projelerinde yaşadığımız sıkıntılar dolayısıyla şirketteki diğer projelerde bunları GitHub üzerine taşımıştık. Aws'yi kapatınca biz de bunları hızlıca GitHub üzerine aldık. Hem konfigurasyon açısından hem maddi hem de uyumluluk açısından çok daha iyi olduğunu söyleyebiliriz.

    Yukarıda acısıyla tatlısıyla ve muhtemelen birçok unuttuğum/atladığım nokta ile geçişi gerçekleştirdik ve bazı noktalara bakmaya da devam ediyoruz. Bu geçiste ne öğrendik veya öncesinde neler yapsaydık daha az problem yaşardık diye 2-3 nokta paylaşıp yazıyı bitirmek istiyorum. 

    Öncelikle veritabanı taşımaları sonrası bunların son halini iyice kontrol etmek iyi olurdu. Bu olayı ucuz kurtardık ama daha can yakıcı olabilirdi.

    Burada maalesef biraz dikkatsiz davrandık. Geçiş sonrası olabilecek problemler için ekibe gerekli vpn kurulması iyi olurdu. Biz hatalarla karşılaşmaya başladıktan sonra bunları hızlıca kurduk, çok sıkıtnı değil ama olsa daha iyi olurdu.

    Testleri yaparken de olsa "test" branşlarına direkt olarak kod göndermemeliydik, bu da yukarıda bahsettiğim yazıda canımı sıkan bir olay oldu.

    Tüm bu geçişi yapmamız bize acısıyla tatlısıyla çok şey öğretti. Uzun yıllardır sektörüde çalışıyor olmama rağmen böyle bir tecrübeyi daha önce hiç yaşamamıştım. Yukarıdaki geçişin asıl sebebini söylemiştik, ama her ne kadar 2 platformun da birbirlerine göre avantaj ve dezavantajları olsa da Google'un arayüz ve kullanımı daha estetik ve kolay olduğunu düşünüyoruz. Her şeye bu geçişi yapabildiğimiz için ekip arkadaşlarıma tekrar teşekkür ederim.

    Yazıyı aşağıdaki hadis-i şerif ile bitirelim.

    “Tevbe sona ermedikçe hicret de sona ermez. Güneş battığı yerden doğmadıkça da tevbe sona ermez.” (Ebû Dâvûd, Cihâd, 2)



Hiç yorum yok:

Yorum Gönder