On-prem'den AWS Kubernetes'e Transformation'ın Oyunbozanları

2023'te 20+ microservice'ten oluşan multiplayer oyun platformunu on-prem datacenter'dan AWS + Kubernetes mimarisine taşıdık. Plan belgesinde her şey net görünüyordu: şu servisleri şu sıraya göre taşı, Helm chart yaz, EKS'e pushla, trafiği kaydır. Gerçek hiç böyle olmadı.

Bu yazıda plan belgelerinde gözükmeyen, bizi gerçekten yavaşlatan 7 şeyi anlatacağım. Eğer benzer bir transformation planlıyorsanız, bu listeye önceden bakın.

1. Observability geçişi migration'dan önce bitmeli

On-prem'deyken dashboard'larımız servis başına özel kurulmuştu. Grafana sevgisi yok, her servisin kendi izleme sayfası vardı. Kubernetes'e geçince birden:

• Pod'lar dinamik geliyor gidiyor
• Log'lar kısa ömürlü container'larda kayboluyor
• Eski dashboard'ların referansları çalışmıyor

Yani aynı anda 20 servisi taşıyoruz ve gözlemlenebilirlik altyapısını sıfırdan kuruyoruz. Kötü bir kombinasyon.

Ders: önce merkezi logging (bizde ELK), tracing (Jaeger), metric toplamı (Prometheus). Bunları tüm servisler için çalışır hale getir. Sonra migration başlat. Sırası ters olursa migration sırasında "ne oluyor, kimse bilmiyor" durumu 2-3 haftanı yer.

2. JVM warm-up, Kubernetes'te readiness probe

Spring tabanlı Java servislerimiz çalışmaya başlarken ilk 30 saniye JIT warm-up yapıyor. Kubernetes pod'u başlattığı an, TCP port açık olduğu an, o pod trafiği alır. Ama Java henüz hazır değildir.

Sonuç: her scale-up olayında ilk gelen trafik yavaş yanıt alıyordu. Kullanıcı bunu "sistem yavaş" olarak gördü.

Çözüm: readiness probe, sadece portu değil, uygulama seviyesinde bir warm-up endpoint'ini de kontrol ediyor. JVM warm up olmadan pod "ready" sayılmıyor.

Bu, teoride planında olmayan ama uygulamada her Java servisinde yapılması gereken şey. Eğer JVM tabanlı bir şey taşıyorsanız, readiness probe'unu özel yazın.

3. Database'i Kubernetes'in DIŞINDA tut

Bu cümle tartışılabilir ama bizde net bir karar: RDS MySQL ve DocumentDB cluster'lar Kubernetes dışında, managed. Kubernetes sadece stateless workload için.

Sebep: Kubernetes'te DB çalıştırmak mümkün ama operasyonel karmaşa çok. Storage, backup, failover, monitoring, upgrade — hepsi senin sorumluluğun. Managed DB hizmetlerinde bunlar genelde zaten halledilmiş.

Migration sırasında "DB'yi de Kubernetes'e taşıyalım, tek yer" temptasyonu vardı. Dirençlendik. Doğru karardı.

4. Service mesh'i günün birinde ekleyemezsin

Istio'yu migration'ın başında eklemek bir karardı. Migration bittiğinde sonradan eklemek çok daha zor. Sebep:

• Her servise sidecar enjekte etmek runtime karakteri değiştiriyor
• mTLS açılınca auth davranışı değişiyor
• Traffic splitting için tüm deploy yol'u yeniden inceleniyor

Bir service mesh ekleyeceksen migration sırasında gelsin. Sonradan ayrı bir migration olur, çok daha pahalı.

5. DNS ve servis keşfi, Kubernetes vs on-prem arasında köprü sırasında

Migration tek seferde değildi — 6 ay boyunca bazı servisler on-prem'de, bazıları AWS'de, birbirleriyle konuşuyordu.

Burada en kritik konu servis keşfi. On-prem servis AWS'deki servise nasıl ulaşır? AWS'deki servis on-prem'deki MySQL'i nasıl bulur?

Bizde:

• VPN tünel on-prem ↔ AWS VPC arasında
• On-prem tarafta kendi DNS'imiz, AWS tarafta Route53
• Crossover ismi için (örn. game-server.internal) her iki tarafta da çözünebilir kayıtlar

Bu tip bir köprü kurulumu kurmadan önce "basit" gibi görünüyor. Kurarken 3 haftanı yer.

6. Maliyet kontrolü, ilk aydan itibaren

AWS'de maliyet fark ettiğinde çok geç olur. İlk ay faturası "olur bu kadar", ikinci ay "bekle ne?", üçüncü ay "kimse bu EBS volume'u delete etmemiş, 6 ay fatura geldi."

Migration'ın İLK GÜNÜ şunları kur:

• Cost Explorer'a günlük uyarı
• Tag strategy (her kaynak en azından team, service, env tag'li)
• Unused resource script (haftada bir çalışsın, zombie olanları listeler)

Sonra kurmak 3 kat zor, çünkü 10 bin kaynak birikmiştir.

7. Ekip, kodu sonradan sahiplenir

En önemli gerçek: Migration'ı Kubernetes'i ilk bilen kişiler yönetir. Ama uygulamayı günün sonunda sahiplenecek olan dev ekipleri.

Bizde olan şu: Ben ve 2-3 kişilik platform ekibi ilk 3 ay migration'ı pushluyorduk. 4. ayda "bir servis yavaşladı" olunca dev ekip Helm chart'ına bakamıyordu, bizim üzerimize kaldı. Hem migration yapıyoruz, hem operasyonu çekiyoruz. Tükenmişlik yakın.

Çözüm: migration sırasında her servisin sahibi olan ekip chart'ı kendi yazsın, PR yapsın, deploy etsin. Platform ekibi rehberlik eder, ama teslim eder. Başlangıçta yavaş görünür, 3 ay sonra gerçekten dağıtılmış bir sahiplik oluşur.

Sonuç

Cloud native transformation "teknik bir iş" olarak düşünülür ama aslında 3 boyutu var: teknik, insan, süreç. Teknik kısım çözülür — dökümantasyon bol, örnekler bol. İnsan ve süreç kısımları yazılmaz, kurulur.

Bu 7 maddede hiçbir teknoloji seçimi yok. Hepsi ekip + süreç. O yüzden plan belgelerinde yer almıyor — yazılamıyor çünkü. Ama gerçek işin çoğu buradaydı.

Migration başarısının en iyi göstergesi, migration bittikten 6 ay sonra ekibin refahı. Herkes yorgunsa, bir şey yanlış gitmiş demektir.