کوبرنیٹس برائے ای کامرس اسکیلنگ: ٹریفک اسپائکس سے عالمی توسیع تک

بلیک فرائیڈے ٹریفک میں اضافے سے ای کامرس کے بوجھ میں منٹوں میں 10-50x اضافہ ہوسکتا ہے۔ روایتی سرور کا بنیادی ڈھانچہ کافی تیزی سے جواب نہیں دے سکتا۔ Kubernetes آٹو اسکیلنگ، خود شفا یابی، اور ٹریفک مینجمنٹ کی وہ صلاحیتیں فراہم کرتا ہے جن کی جدید ای کامرس پلیٹ فارمز کو خاموشی کے دوران ضرورت سے زیادہ فراہمی کے بغیر غیر متوقع مانگ کو سنبھالنے کی ضرورت ہے۔

یہ گائیڈ خاص طور پر ای کامرس کے کام کے بوجھ کے لیے Kubernetes فن تعمیر کا احاطہ کرتا ہے، فلیش سیلز کو ہینڈل کرنے سے لے کر ملٹی ریجن اسٹور فرنٹ بنانے تک جو 200ms سے کم میں کسٹمرز کو مقام سے قطع نظر پیش کرتے ہیں۔

اہم ٹیک ویز

• Horizontal Pod Autoscaler (HPA) ای کامرس سروسز کو 90 سیکنڈ سے کم میں 2 سے 200 پوڈز تک پیمانہ کر سکتا ہے۔
• ریٹ کو محدود کرنے والے انگریس کنٹرولرز ٹریفک میں اضافے کے دوران بیک اینڈ سروسز کی حفاظت کرتے ہیں۔
• ریاستی کام کے بوجھ (ڈیٹا بیسز، سرچ انڈیکس) کو اسٹیٹ لیس خدمات سے مختلف اسکیلنگ کی حکمت عملیوں کی ضرورت ہوتی ہے۔
• ملٹی ریجن کبرنیٹس کی تعیناتی عالمی کسٹمر بیسز کے لیے 60-80% تک تاخیر کو کم کرتی ہے۔

---

جب Kubernetes ای کامرس کے لیے معنی رکھتا ہے۔

Kubernetes ہمیشہ صحیح جواب نہیں ہوتا ہے۔ اس میں آپریشنل پیچیدگی کا اضافہ ہوتا ہے جو اسکیلنگ کی ضروریات کے مطابق ہونا ضروری ہے۔

فیصلہ میٹرکس

اگر آپ کا کاروبار ڈوکر کمپوز کالم میں آتا ہے، تو اس کے بجائے ہماری ڈوکر پروڈکشن تعیناتی گائیڈ دیکھیں۔

---

ای کامرس کے لیے کوبرنیٹس آرکیٹیکچر

کلسٹر لے آؤٹ

ایک ای کامرس Kubernetes کلسٹر میں عام طور پر یہ نام کی جگہیں ہوتی ہیں:

• storefront: فرنٹ اینڈ ایپلیکیشن پوڈز
• api: بیک اینڈ API سروسز
• workers: بیک گراؤنڈ جاب پروسیسرز (آرڈر پروسیسنگ، ای میل بھیجنا، انوینٹری سنک)
• data: ڈیٹا بیس، کیچز، اور سرچ انجن (یا منظم بیرونی خدمات)
• ingress: انگریس کنٹرولرز اور لوڈ بیلنسرز
• monitoring: Prometheus, Grafana, alerting

تعیناتی کی ترتیب

# 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"

---

آٹو اسکیلنگ کنفیگریشن

افقی پوڈ آٹو اسکیلر

# 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 پالیسی ہر 60 سیکنڈ میں پوڈ کو دوگنا کرنے کی اجازت دیتی ہے --- اچانک ٹریفک کی بڑھتی ہوئی وارداتوں سے نمٹنے کے لیے اہم ہے۔ scaleDown پالیسی قدامت پسند ہے (10% فی منٹ) تھریشنگ کو روکنے کے لیے۔

کلسٹر آٹو اسکیلر

HPA پھلیوں کو ترازو کرتا ہے، لیکن پھلیوں کو نوڈس کی ضرورت ہوتی ہے۔ کلسٹر آٹو اسکیلر زیر التواء پوڈ مطالبات کی بنیاد پر نوڈس کو شامل اور ہٹاتا ہے:

# 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 کے لیے، نوڈ گروپس کو کم سے کم/زیادہ سے زیادہ سائز کے ساتھ ترتیب دیں:

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

---

داخلہ اور ٹریفک مینجمنٹ

Nginx Ingress کنٹرولر

# 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

فلیش سیلز کو ہینڈل کرنا

فلیش سیلز پری اسکیلنگ کی ضرورت ہوتی ہے۔ معروف ہائی ٹریفک واقعات کے لیے اکیلے آٹو اسکیلنگ پر انحصار نہ کریں:

# 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 میں PostgreSQL چلانے کا آپریشنل اوور ہیڈ زیادہ تر کاروباروں کے لیے جائز نہیں ہے۔

کنکشن پولنگ

# 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"

ٹرانزیکشن پولنگ موڈ میں پی جی باؤنسر سینکڑوں ایپلیکیشن پوڈز کو ڈیٹا بیس کنکشن کے محدود پول کو شیئر کرنے کی اجازت دیتا ہے۔ کنکشن پولنگ کے بغیر، 50 API پوڈز کو اسکیل کرنے کے لیے 50 x 20 = 1,000 ڈیٹا بیس کنکشنز کی ضرورت ہوگی، جو کہ زیادہ تر PostgreSQL مثالوں پر مشتمل ہے۔

ڈیٹابیس اسکیلنگ کی مزید حکمت عملیوں کے لیے، ہماری ڈیٹا بیس اسکیلنگ گائیڈ دیکھیں۔

---

کثیر علاقائی تعیناتی۔

فن تعمیر

ایک کثیر علاقائی ای کامرس Kubernetes تعیناتی استعمال کرتا ہے:

1. علاقائی کلسٹر: ہر علاقے میں آزاد Kubernetes کلسٹرز
2. گلوبل لوڈ بیلنسر: صارفین کو قریب ترین علاقے تک پہنچاتا ہے (AWS گلوبل ایکسلریٹر، کلاؤڈ فلیئر)
3. ڈیٹا بیس کی نقل: ایک علاقے میں بنیادی، دوسرے علاقے میں نقلیں پڑھیں
4. CDN: جامد اثاثے جو دنیا بھر کے کنارے والے مقامات سے پیش کیے جاتے ہیں۔

تاخیر کا اثر

| صارف کا مقام | واحد علاقہ (US-East) | ملٹی ریجن | |---------------|---------------| | نیویارک | 20ms | 20ms | | لندن | 120ms | 25ms | | سنگاپور | 250ms | 30ms | | سڈنی | 300ms | 35ms |

کثیر علاقائی تعیناتی بین الاقوامی صارفین کے لیے 60-90% تک تاخیر کو کم کرتی ہے، براہ راست تبادلوں کی شرح کو بہتر بناتی ہے۔ مطالعات سے پتہ چلتا ہے کہ تاخیر میں کمی کے ہر 100ms سے ای کامرس کی تبدیلی میں 1.1% اضافہ ہوتا ہے۔

---

کبرنیٹس ای کامرس کی نگرانی

ضروری ڈیش بورڈز

1. کاروباری میٹرکس: آرڈرز فی منٹ، کارٹ کی تبدیلی کی شرح، فی گھنٹہ آمدنی
2. ایپلیکیشن میٹرکس: تاخیر کی درخواست کریں (P50, P95, P99)، خرابی کی شرح، فعال سیشنز
3. انفراسٹرکچر میٹرکس: Pod CPU/میموری، نوڈ کا استعمال، HPA سرگرمی
4. ڈیٹا بیس میٹرکس: کنکشن کی گنتی، استفسار میں تاخیر، نقل میں وقفہ

# 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

---

اکثر پوچھے گئے سوالات

روایتی ہوسٹنگ کے مقابلے Kubernetes کی قیمت کتنی ہے؟

ہوائی جہاز کی لاگت، لوڈ بیلنس کی فیس، اور نوڈ اوور ہیڈ کی وجہ سے Kubernetes انفراسٹرکچر کی لاگت مساوی ننگی دھات یا سادہ کلاؤڈ مثالوں سے 20-40% زیادہ ہے۔ تاہم، آٹو اسکیلنگ عام طور پر کل اخراجات کو 30-50% تک کم کرتی ہے کیونکہ آپ آف پیک اوقات کے دوران زیادہ سے زیادہ صلاحیت کے لیے ادائیگی نہیں کر رہے ہیں۔ متغیر ٹریفک والے زیادہ تر ای کامرس کاروباروں کا خالص اثر لاگت میں 10-25% کمی ہے۔

کیا ہم Kubernetes پر Odoo چلا سکتے ہیں؟

ہاں، لیکن انتباہات کے ساتھ۔ Odoo کے فائل اسٹور کو ایک سے زیادہ نقلیں چلاتے وقت مشترکہ مستقل اسٹوریج (EFS, NFS) کی ضرورت ہوتی ہے۔ سیشن وابستگی کی ضرورت ہے جب تک کہ آپ سیشنز کو Redis میں خارج نہ کریں۔ ڈیٹا بیس کنکشنز کو PgBouncer کے ذریعے جمع کیا جانا چاہیے۔ Odoo کی زیادہ تر تعیناتیوں کے لیے، Docker Compose یا ECS آسان اور کافی ہے۔ Kubernetes 200+ سمورتی صارفین کے ساتھ بڑی Odoo تعیناتیوں کے لیے معنی خیز ہے۔

ہم بغیر ٹائم ٹائم کے Kubernetes اپ گریڈ کو کیسے ہینڈل کرتے ہیں؟

ایک منظم Kubernetes سروس (EKS, GKE, AKS) کا استعمال کریں جو کنٹرول ہوائی جہاز کے اپ گریڈ کو ہینڈل کرتی ہے۔ نوڈ اپ گریڈ کرنے کے لیے، ایک رولنگ حکمت عملی کا استعمال کریں: ایک نوڈ کو کورڈن کریں، اس کے پوڈز کو نکالیں (وہ دوسرے نوڈس پر دوبارہ شیڈول کرتے ہیں)، نوڈ کو اپ گریڈ کریں، اسے غیر منظم کریں۔ مناسب پوڈ ڈسٹرکشن بجٹ کے ساتھ، یہ مکمل طور پر خودکار اور صفر ڈاؤن ٹائم ہے۔

پروڈکشن ای کامرس کے لیے کلسٹر کا کم از کم سائز کیا ہے؟

درمیانے سائز کے ای کامرس پلیٹ فارم کے لیے کم از کم پروڈکشن کلسٹر: ایپلیکیشن ورک بوجھ کے لیے 3 نوڈس (t3.large یا مساوی)، نیز ایک منظم ڈیٹا بیس مثال۔ یہ تقریباً 500 ہم وقت صارفین کو ہینڈل کرتا ہے جس میں چوٹیوں کے دوران آٹو اسکیلنگ کی گنجائش ہوتی ہے۔ بنیادی ڈھانچے کی کل لاگت: تقریباً $500-800 فی مہینہ۔

---

آگے کیا آتا ہے۔

Kubernetes provides the scaling foundation, but it is only one piece of the infrastructure puzzle. ایک مکمل ای کامرس آپریشنز پلیٹ فارم کے لیے اسے CI/CD بہترین طریقوں، CDN آپٹیمائزیشن، اور لوڈ ٹیسٹنگ کے ساتھ جوڑیں۔

ECOSIRE سے رابطہ کریں Kubernetes کی مشاورت اور ای کامرس اسکیلنگ کی حکمت عملی کے لیے، یا ہماری Shopify انٹیگریشن سروسز کو Kubernetes پر منظم ہیڈ لیس کامرس کے لیے دریافت کریں۔

---

ECOSIRE کی طرف سے شائع کیا گیا -- کاروباروں کو عالمی سطح پر ای کامرس کے بنیادی ڈھانچے کی پیمائش میں مدد کرنا۔