e-Ticaret Ölçeklendirmesi için Kubernetes: Trafik Ani Artışlarından Küresel Genişlemeye

Kara Cuma trafiğindeki ani artışlar, e-Ticaret yükünü dakikalar içinde 10-50 kat artırabilir. Geleneksel sunucu altyapısı yeterince hızlı yanıt veremez. Kubernetes, modern e-Ticaret platformlarının, sessiz dönemlerde aşırı kaynak sağlamadan öngörülemeyen talebi karşılamak için ihtiyaç duyduğu otomatik ölçeklendirme, kendi kendini iyileştirme ve trafik yönetimi yeteneklerini sağlar.

Bu kılavuz, flaş satışların yönetilmesinden müşterilere konuma bakılmaksızın 200 ms'nin altında hizmet veren çok bölgeli vitrinler oluşturmaya kadar e-Ticaret iş yüklerine özel Kubernetes mimarisini kapsar.

Önemli Çıkarımlar

• Yatay Kapsül Otomatik Ölçekleyici (HPA), e-Ticaret hizmetlerini 90 saniyeden kısa sürede 2 ila 200 bölme arasında ölçeklendirebilir
• Hız sınırlamalı giriş denetleyicileri, trafik dalgalanmaları sırasında arka uç hizmetlerini korur
• Durum bilgisi olan iş yükleri (veritabanları, arama dizinleri), durum bilgisi olmayan hizmetlerden farklı ölçeklendirme stratejileri gerektirir
• Çok bölgeli Kubernetes dağıtımları, küresel müşteri tabanları için gecikmeyi %60-80 oranında azaltır

---

Kubernetes e-Ticaret için Anlamlı Olduğunda

Kubernetes her zaman doğru cevap değildir. Ölçeklendirme gereksinimleriyle haklı gösterilmesi gereken operasyonel karmaşıklığı artırır.

Karar Matrisi

İşletmeniz Docker Compose sütununda yer alıyorsa bunun yerine Docker üretim dağıtım kılavuzumuza bakın.

---

e-Ticaret için Kubernetes Mimarisi

Küme Düzeni

Bir e-Ticaret Kubernetes kümesi genellikle şu ad alanlarını içerir:

• storefront: Ön uç uygulama bölmeleri
• api: Arka uç API hizmetleri
• workers: Arka plan iş işlemcileri (sipariş işleme, e-posta gönderme, envanter senkronizasyonu)
• data: Veritabanları, önbellekler ve arama motorları (veya yönetilen harici hizmetler)
• ingress: Giriş denetleyicileri ve yük dengeleyiciler
• monitoring: Prometheus, Grafana, uyarı

Dağıtım Yapılandırması

# storefront-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
  namespace: storefront
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
        - name: storefront
          image: registry.example.com/storefront:v2.1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 1000m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: API_URL
              value: "http://api-service.api.svc.cluster.local:3001"
            - name: NODE_ENV
              value: "production"

---

Otomatik Ölçeklendirme Yapılandırması

Yatay Kapsül Otomatik Ölçekleyici

# storefront-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: storefront-hpa
  namespace: storefront
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: storefront
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

scaleUp politikası, bölmelerin her 60 saniyede bir ikiye katlanmasına izin verir; bu, ani trafik artışlarıyla başa çıkmak için kritik öneme sahiptir. scaleDown politikası, çarpmayı önlemek için muhafazakardır (dakikada %10).

Küme Otomatik Ölçekleyicisi

HPA bölmeleri ölçeklendirir ancak bölmelerin düğümlere ihtiyacı vardır. Otomatik Küme Ölçekleyici, bekleyen kapsül taleplerine göre düğümleri ekler ve kaldırır:

# cluster-autoscaler configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  balance-similar-node-groups: "true"
  skip-nodes-with-local-storage: "false"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"
  max-node-provision-time: "5m"

AWS EKS için düğüm gruplarını minimum/maksimum boyutlarla yapılandırın:

eksctl create nodegroup \
  --cluster ecommerce-prod \
  --name workers \
  --node-type t3.large \
  --nodes-min 3 \
  --nodes-max 20 \
  --node-volume-size 50 \
  --managed

---

Giriş ve Trafik Yönetimi

Nginx Giriş Denetleyicisi

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/rate-limit-window: "1m"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
    - hosts:
        - store.example.com
      secretName: store-tls
  rules:
    - host: store.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 3001
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront-service
                port:
                  number: 3000

Flaş Satışları Yönetme

Flaş satışlar ön ölçeklendirme gerektirir. Bilinen yüksek trafikli etkinlikler için yalnızca otomatik ölçeklendirmeye güvenmeyin:

# Pre-scale 2 hours before a flash sale
kubectl scale deployment storefront --replicas=20 -n storefront
kubectl scale deployment api --replicas=15 -n api
kubectl scale deployment order-worker --replicas=10 -n workers

# After the sale, let HPA scale down naturally

---

Kubernetes'te Veritabanı Ölçeklendirme

Yönetilen ve Kendi Kendine Barındırılan Veritabanları Karşılaştırması

Öneri: Üretim e-ticareti için yönetilen veritabanlarını kullanın. PostgreSQL'i Kubernetes'te çalıştırmanın getirdiği operasyonel yük çoğu işletme için haklı değildir.

Bağlantı Havuzu

# pgbouncer-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
  namespace: data
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: pgbouncer
          image: edoburu/pgbouncer:1.21.0
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: MAX_CLIENT_CONN
              value: "1000"
            - name: DEFAULT_POOL_SIZE
              value: "25"
            - name: POOL_MODE
              value: "transaction"

İşlem havuzu modundaki PgBouncer, yüzlerce uygulama bölmesinin sınırlı bir veritabanı bağlantısı havuzunu paylaşmasına olanak tanır. Bağlantı havuzu olmadan, 50 API bölmesine ölçeklendirme 50 x 20 = 1.000 veritabanı bağlantısı gerektirecektir; bu da çoğu PostgreSQL örneğini zorlayacaktır.

Daha fazla veritabanı ölçeklendirme stratejisi için veritabanı ölçeklendirme kılavuzumuza bakın.

---

Çok Bölgeli Dağıtım

Mimarlık

Çok bölgeli bir e-Ticaret Kubernetes dağıtımı şunları kullanır:

1. Bölgesel kümeler: Her bölgedeki bağımsız Kubernetes kümeleri
2. Global yük dengeleyici: Kullanıcıları en yakın bölgeye yönlendirir (AWS Global Accelerator, Cloudflare)
3. Veritabanı çoğaltma: Bir bölgede birincil, diğerlerinde okuma kopyaları
4. CDN: Dünya çapındaki uç konumlardan sunulan statik varlıklar

Gecikme Etkisi

Çok bölgeli dağıtım, uluslararası müşteriler için gecikmeyi %60-90 oranında azaltarak dönüşüm oranlarını doğrudan artırır. Araştırmalar, her 100 ms gecikme azalmasının e-Ticaret dönüşümünü %1,1 artırdığını gösteriyor.

---

Kubernetes e-Ticaretini İzleme

Temel Kontrol Panelleri

1. İş metrikleri: Dakika başına sipariş sayısı, alışveriş sepeti dönüşüm oranı, saat başına gelir
2. Uygulama metrikleri: İstek gecikmesi (P50, P95, P99), hata oranı, etkin oturumlar
3. Altyapı ölçümleri: Pod CPU/bellek, düğüm kullanımı, HPA etkinliği
4. Veritabanı ölçümleri: Bağlantı sayısı, sorgu gecikmesi, çoğaltma gecikmesi

# prometheus-servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: api
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

---

Sıkça Sorulan Sorular

Kubernetes'in geleneksel barındırmayla karşılaştırıldığında maliyeti ne kadardır?

Kubernetes altyapısının maliyeti, kontrol düzlemi maliyetleri, yük dengeleyici ücretleri ve düğüm ek yükü nedeniyle eşdeğer çıplak donanım veya basit bulut bulut sunucularından %20-40 daha fazladır. Bununla birlikte, otomatik ölçeklendirme genellikle toplam harcamayı %30-50 oranında azaltır çünkü yoğun olmayan saatlerde en yüksek kapasite için ödeme yapmazsınız. Değişken trafiğe sahip çoğu e-Ticaret işletmesi için net etki, %10-25 oranında maliyet azalmasıdır.

Odoo'yu Kubernetes'te çalıştırabilir miyiz?

Evet, ancak uyarılarla. Odoo'nun dosya deposu, birden fazla kopya çalıştırırken paylaşılan kalıcı depolama (EFS, NFS) gerektirir. Oturumları Redis'e dışsallaştırmadığınız sürece oturum benzeşimi gereklidir. Veritabanı bağlantıları PgBouncer aracılığıyla havuzda toplanmalıdır. Çoğu Odoo dağıtımı için Docker Compose veya ECS daha basit ve yeterlidir. Kubernetes, 200'den fazla eşzamanlı kullanıcıya sahip büyük Odoo dağıtımları için mantıklıdır.

Kubernetes yükseltmelerini kesinti olmadan nasıl hallederiz?

Kontrol düzlemi yükseltmelerini gerçekleştiren yönetilen bir Kubernetes hizmetini (EKS, GKE, AKS) kullanın. Düğüm yükseltmeleri için sürekli bir strateji kullanın: bir düğümü kordon altına alın, bölmelerini boşaltın (diğer düğümlere yeniden planlarlar), düğümü yükseltin, kordonunu açın. Uygun kapsül kesinti bütçeleri ile bu tamamen otomatiktir ve sıfır kesinti süresine sahiptir.

Üretim e-ticareti için minimum küme boyutu nedir?

Orta boyutlu bir e-Ticaret platformu için minimum üretim kümesi: Uygulama iş yükleri için 3 düğüm (t3.large veya eşdeğeri) ve ayrıca yönetilen bir veritabanı örneği. Bu, yoğun saatlerde otomatik ölçeklendirme için yeterli alana sahip yaklaşık 500 eş zamanlı kullanıcıyı yönetir. Toplam altyapı maliyeti: ayda yaklaşık 500-800$.

---

Sırada Ne Var?

Kubernetes ölçeklendirmenin temelini sağlar ancak altyapı yapbozunun yalnızca bir parçasıdır. Eksiksiz bir e-Ticaret işlemleri platformu için bunu CI/CD en iyi uygulamaları, CDN optimizasyonu ve yük testi ile birleştirin.

Kubernetes danışmanlığı ve e-Ticaret ölçeklendirme stratejisi için ECOSIRE ile iletişime geçin veya Kubernetes'te yönetilen başsız ticaret için Shopify entegrasyon hizmetlerimizi keşfedin.

---

ECOSIRE tarafından yayınlandı - işletmelerin e-Ticaret altyapısını küresel olarak ölçeklendirmesine yardımcı oluyor.