tolgacelik.net
Tüm yazılar
·3 dk

On-prem'den AWS + Kubernetes'e: 20+ microservice'lik bir iGaming platformunun geçişi

10.000+ eşzamanlı oyuncuya hizmet veren platformun 2023 yeniden inşasından notlar — polyglot stack, Istio mesh ve gerçekten işe yarayan kararlar.

kubernetesawsmigrationistioigamingdistributed-systems

2023'te, 10.000+ eşzamanlı oyuncuya hizmet veren çok oyunculu bir masa oyunu platformunun on-prem bir datacenter'dan AWS + Kubernetes tabanlı cloud-native bir mimariye taşınmasının teknik sahipliğini ve liderliğini üstlendim. Sistem Java, .NET Core, PHP, Python, Node.js ve React ile yazılmış 20+ microservice'ten oluşuyor ve bugün tamamen AWS üzerinde canlı çalışıyor.

Bu yazı dürüst bir retrospektif: ne yaptık, hangi kararlar gerçekten işe yaradı, neleri farklı yapardık.

Başlangıç durumu

Yıllar içinde organik büyümüş polyglot bir platform:

  • Java (Spring) — ana oyun sunucuları ve uzun ömürlü backend servislerin büyük kısmı
  • .NET Core — bazı oyun-server varyantları ve API servisleri
  • Python — asenkron consumer servisler (matchmaking, ödeme, fraud kontrolü)
  • PHP (Laravel/Lumen) — legacy admin ve araçlar
  • Node.js — birkaç real-time facade
  • React + AngularJS + Vue — istemciler ve operasyonel paneller

Veri katmanı:

  • MySQL — transactional veri
  • MongoDB — session state ve esnek doküman
  • Redis (Pub/Sub + HashMap) — real-time broadcast ve hot cache
  • RabbitMQ — asenkron fabric
  • Memcached — okuma ağırlıklı hesaplanmış yanıtlar

Bunlar bare-metal VM'ler üzerinde el yapımı servis orkestrasyonuyla çalışıyordu. Stabildi, ama ölçeklemek datacenter'ı aramak demekti.

Neden yeniden inşa, basit taşıma neden değil

İki seçeneğimiz vardı:

  1. Mevcut VM'leri EC2'ye kaldırıp devam etmek.

  2. Gerçek izolasyon, autoscaling ve doğru operasyonel araçlarla Kubernetes + Istio'ya yeniden inşa etmek.

  3. seçenek ilk 3 ay daha hızlı, sonrası için sonsuza kadar daha yavaş olurdu. 2. seçeneği tercih ettik — "Kubernetes cool" olduğu için değil, yeni iş gereksinimleri (live-ops kampanyaları, segment bazlı rollout, bölgesel gecikme) bare-metal VM'lerin ciddi özel iş olmadan sağlayamayacağı yetenekler gerektirdiği için. Kubernetes + Istio bunları birincil primitive olarak sunuyordu.

Doğru gidenler

Istio ile servisler arası TLS ve trafik yönetimi. Her yerde mutual TLS, bedava. Canary rollout'lar reverse-proxy yeniden kurmak yerine tek bir VirtualService değişikliği oldu.

Her servise bir Helm chart, servisin yanında versiyonlandı. Dev ekipleri kendi chart'larını sahiplendi. Rutin deploy'larda merkez platform ekibi darboğazı yok.

Redis Pub/Sub kaldı. Onu "modernize etme" adına managed stream platformuna geçirme hevesimiz vardı. Geçmedik. Redis Pub/Sub bizim trafik şeklimizde kanıtlanmıştı, geçişin kendisi zaten yeterince riskliydi — broadcast fabric'i de değiştirmek akıl dışıydı.

RabbitMQ da kaldı. Aynı mantık. AWS managed servisleri iyi, ama onların üzerinde bizim spesifik operasyonel kasımız olmadan "iyi" net negatifti geçiş sırasında.

Farklı yapardık dedikleriniz

Gözlemlenebilirlik maliyetini hafife aldık. Geçiş öncesi sistemde servis başına özel dashboard'lar ve ortak Sentry vardı. Kubernetes yüzey alanını katlıyor — pod'lar gelip gidiyor, IP'ler değişiyor, loglar container'lara dağılıyor. Tutarlı bir logging ve tracing geleneğini geçişin ortasında geri dönüp kurmak zorunda kaldık. Önce gözlemlenebilirlik hikayesini kurun, sonra compute hikayesini.

Chart + CI/CD'nin servis-başı sahipliği doğruydu, dil runtime'ın servis-başı özgürlüğü yanlıştı. Çok fazla küçük varyasyon. Sonra standartlaştırdık ama borcunu ödedik.

Sistem bugün nasıl görünüyor

  • Tüm servisler AWS EKS üzerinde, Istio arkasında.
  • Özel metriklerle (eşzamanlı oyun odası sayısı, CPU değil) horizontal pod autoscaling.
  • Kubernetes katmanında değil, routing katmanında blue/green.
  • Sentry + ELK ile gözlemlenebilirlik.
  • Jenkins ile CI, Actions'a doğru hareket.

Sistem canlı. Mimarisini, stabilitesini ve gelişimini hâlâ sahipleniyorum.

Aynı yolculuğa çıkacaksanız

İki tavsiye:

  1. Kodu değil kontratı yeniden inşa edin. Geçiş, servislerin birbirine verdiği sözleri yeniden şekillendirmek için bir bahane. Kullanın. Kötü arayüzleri taşımayın.

  2. Sadece yükü değil, insanları da taşıyın. Bare-metal için ops becerileri ≠ Kubernetes için ops becerileri. Eğitim ve shadowing, araç seçiminden daha önemli.

Baktığın bir geçiş var mı? Bana yaz — karşılaştırmaya açığım.

PaylaşLinkedInX
Bir sonraki yazı doğrudan kutuna düşsün

Distributed sistemler, üretim stabilitesi, AI destekli geliştirme üzerine uzun yazılar. Spam yok, çıkmak kolay.

Sadece e-posta. Bu sunucuda saklanır. Hiçbir yerde paylaşılmaz, satılmaz.

Yorumlar

Henüz yorum yok. İlk yorumu sen bırak.

Yorum bırak

Hiçbir yerde gösterilmez. Sadece gerekirse cevap vermek için.