Trafik deseni
Durumlu oturum, lansman ve etkinlik zirvesi
- Oturum belirli sunucuda yaşar
- Eşleştirme yerleştirmeyi belirler
- Eşzamanlı oda sayısı ana ölçü
Çözüm senaryosu
Oyun sunucuları ve oturum yükü için referans mimari
Oyuncu bir oturuma girdiğinde o oturum belirli bir sunucuda yaşar. Yerleştirme eşleştirme servisine aittir.
- Ana karar
- Oturum yerleştirmesini kimin yaptığı
- Bilinçli eksik
- Bu mimaride yük dengeleyici kullanılmaz
- Ayrı şerit
- Varlık indirmesi oyun trafiğinden ayrı planlanır
Genel bakış
Oyun iş yükü neden durumsuz mimariden ayrılır?
Bu senaryonun belirleyici özelliği oturumun durumlu olmasıdır. Oyuncu odaya girdiğinde oturum belirli bir sunucu sürecinde yaşar ve sonraki paketler aynı sürece gider. Yerleştirme eşleştirme servisine aittir. Oturum sunucuları eşzamanlı oda sayısına göre ızgara olarak planlanır. Yama ve içerik paketleri nesne depolamadan indirilir; indirme trafiği oyun trafiğinden ayrı bütçelenir. Oda sunucusu İstanbul (tr-ist-01) ve Ankara (tr-ank-01) bölgelerinden planlanır.
Tipik iş yükü profili
Oturum yapışkan, indirme yığın halinde
Oyun trafiği ile indirme trafiği aynı ölçüyü paylaşmaz. Oyun paketleri küçük ve sürekliyken varlık indirmeleri lansman ve yama günlerinde yığılır. Oturum verisi bellekte kaldığı için depolama hacmi küçük kalır. Profil bu yüzden eşzamanlı oda sayısını kapasitenin temel ölçüsü olarak alır.
Veri hacmi
Oturum verisi küçük, varlık paketi büyük
- Oturum durumu bellekte
- Yama ve içerik nesne depolamada
- İndirme trafiği lansmanda yığılır
Gecikme ve uyum
Gidiş dönüş süresi tek kritik eksen
- Oyun trafiğinde gidiş dönüş süresi
- İndirme trafiğinde verim
- Oyuncu verisi senaryonun gereksinimi
Kapasite eşzamanlı oda sayısıyla planlanır. Oda sunucusu İstanbul (tr-ist-01) ve Ankara (tr-ank-01) arasından seçilir.
Referans mimari
Izgara üstte, varlık şeridi altta
Diyagram iki kata ayrılır: üstte altı odalık oturum ızgarası, altta varlık dağıtım şeridi. Eşleştirme servisi ızgaraya yerleştirme yapar; zirvede açılan altıncı oda kesikli çizilir. İki kat arasında bağ yoktur, çünkü indirme yolu ile oyun yolu birbirini beklememelidir. Kesikli çizilen oturum yapışkanlığı oku, oyuncunun sonraki paketlerinin aynı sürece döndüğünü gösterir.
Kullanılan PortvMind Cloud servisleri
Dört servis: giriş, oturum, varlık ve indirme
Floating IP girişi sabitler, Compute eşleştirme ve oda sunucularını taşır, Object Storage varlık paketlerini tutar, Network Data Transfer indirme bütçesini görünür kılar. Durumlu oturumda yerleştirme eşleştirme servisine aittir.
Floating IP
İstemcinin bağlandığı genel adres sabit kalır, arkasındaki süreç değişir.
Compute
Eşleştirme servisi ve oda sunucuları ayrı profillerde aynı servisten gelir.
Object Storage
Yama ve içerik paketleri oyun sunucusundan değil buradan indirilir.
Network Data Transfer
İndirme trafiği oyun trafiğinden ayrı bir bütçe kalemi olarak izlenir.
Her servis sayfası bu senaryoya geri bağlanır; bağlantı iki yönde de aynı listeden üretilir. Tüm Servisler
Değerlendirme kriterleri
Yerleştirme, ölçü, şerit ve bütçe
Tablo yerleştirmenin sahibini, kapasitenin hangi ölçüyle hesaplandığını, varlık indirmelerinin ayrı şeritte olup olmadığını ve lansman trafiğinin bütçelenip bütçelenmediğini sorar. İlk satırın cevabı diğer altı senaryodan ayrıldığı yerdir: karar dağıtım katmanında değil, uygulamanın kendisindedir. Kalan üç satır kapasite planını, şerit ayrımını ve indirme bütçesini lansman öncesinde sabitler.
| Kriter | Sorulan soru | Bu senaryodaki cevap |
|---|---|---|
| Yerleştirme sahibi | Oyuncuyu hangi bileşen bir sunucuya yerleştiriyor? | Eşleştirme servisi — oturum durumlu olduğu için karar yük dengeleyiciye bırakılmaz. |
| Kapasite ölçüsü | Kapasite düğüm üzerinden mi, oda üzerinden mi hesaplanıyor? | Eşzamanlı oda sayısı üzerinden; ızgara bu ölçüye göre büyütülür. |
| Varlık dağıtımı | Yama ve içerik paketleri oyun sunucusundan mı indiriliyor? | Hayır — varlık şeridi ayrıdır; indirme oyun trafiğinin gecikmesini etkilemez. |
| Çıkış bütçesi | Lansman indirmeleri ayrı bütçelendi mi? | Evet — indirme trafiği oyun trafiğinden ayrı izlenir; hacim kurumun kendi ölçümüyle belirlenir. |
Oyuncu verisi stüdyonun mimari gereksinimleri arasında planlanır.
İlgili rehberler ve dokümantasyon
Varlık deposu ve koruma okumaları
Nesne depolamanın varlık dağıtımına uyarlanması ve yedekleme planı rehberlerde işlenir. Bucket kurulumu ile operasyon adımları dokümantasyonda anlatılır. Eşleştirme mantığı uygulamanın kendisindedir.
Rehberler
- Object Storage Mimarisi: Block Storage'dan Farkı Nedir?
Object Storage, veriyi dosya sistemi blokları yerine veri, benzersiz bir anahtar ve metadata içeren bağımsız nesneler olarak bucket'larda saklar. Uygulamalar bu nesnelere genellikle HTTP tabanlı S3 uyumlu API üzerinden erişir. Block Storage ise sunucuya bir disk hacmi sunar; işletim sistemi bu hacim üzerinde dosya sistemi veya veritabanı çalıştırır. Medya, yedek, arşiv ve veri gölü için nesne modeli; işletim sistemi diskleri, veritabanları ve düşük gecikmeli rastgele okuma ve yazma isteyen iş yükleri için blok modeli değerlendirilir.
- Bulut Yedekleme Nedir? Kurumsal Yedekleme Nasıl Planlanır?
Bulut yedekleme, sunucu, volume ve uygulama verinizin planlı kopyalarını saklar. PortvMind Cloud Backup ile yedekleri panelden oluşturur, izler ve geri yüklersiniz. Snapshot hızlı geri dönüş içindir; kalıcı koruma Backup ile sağlanır.
Rehberler
- Object Storage ve S3 API
Bucket ve dosya kullanımı için Discuss’ta yayımlanan rehber.
- Nasıl Yapılır Rehberleri
GPU, VKE, ağ, güvenlik ve Terraform senaryoları için toplulukta yayımlanan uygulamalı rehberler.
Diğer çözüm senaryoları
- Kamu
Tek kontrollü giriş, iç içe sınır ve belge arşivinin saklanması.
- Üretim ve Endüstri
Saha ile bulut arasında tek yönlü köprü ve zirvesiz sürekli akış.
- Yapay Zekâ ve Veri
Eğitim penceresi, checkpoint hacmi ve çıkarım yolu ayrı ayrı planlanır.
Oturum yerleştirmesini ve varlık şeridini birlikte kuralım.
Eşzamanlı oda hedefinizi, yama ritminizi ve mevcut eşleştirme mantığınızı paylaşın; ızgara planını ve indirme bütçesini mimari görüşmede birlikte çıkaralım.