All Products
Search
Document Center

Server Load Balancer:Praktik Perutean Sadar Beban

Last Updated:Jul 25, 2026

Dalam tutorial ini, Anda mengonfigurasi perutean sadar beban pada Application Load Balancer (ALB) Edisi Ekstensibel untuk mengoptimalkan distribusi lalu lintas bagi layanan inferensi AI generatif. Dengan mengumpulkan metrik backend secara real-time—seperti panjang antrian permintaan, pemanfaatan cache GPU, dan jumlah permintaan yang sedang berjalan—ALB mengarahkan permintaan ke replika dengan beban kerja lebih ringan, sehingga mengurangi latensi inferensi dan meningkatkan throughput keseluruhan.

Skenario

Perutean sadar beban cocok untuk skenario di mana instans backend memiliki perbedaan beban signifikan, biaya permintaan tidak merata, serta sensitivitas latensi yang tinggi. Skenario khas meliputi:

  • Layanan inferensi AI generatif — Permintaan inferensi LLM sangat bervariasi dalam hal biaya. Memori GPU, pemanfaatan cache KV, dan status antrian berfluktuasi secara real-time di berbagai instans. Perutean sadar beban mengirimkan permintaan ke instans dengan beban kerja lebih ringan, mencegah akumulasi pada instans yang kelebihan beban, serta mengurangi waktu hingga token pertama (TTFT) dan latensi ekor.

  • Beban backend tidak merata — Saat tugas-tugas berbiaya tinggi menyebabkan beberapa instans menjadi sangat sibuk, algoritma penjadwalan statis menurunkan performa pada instans tersebut. Perutean sadar beban mendeteksi beban secara real-time dan secara dinamis menghindari instans yang sangat sibuk, sehingga memperbaiki latensi ekor akibat ketidakseimbangan.

  • Kluster inferensi elastis berkonkurensi tinggi — Saat backend merupakan replika inferensi yang dideploy secara batch dalam kluster kontainer ACK atau ACS, perutean sadar beban mengoptimalkan distribusi permintaan di bawah tekanan tinggi pada kluster secara keseluruhan, mengurangi antrean ekstrem, dan meningkatkan throughput keseluruhan.

Arsitektur

Setelah permintaan klien mencapai instans ALB Edisi Ekstensibel, aturan pengalihan mengarahkan lalu lintas ke grup server yang dikaitkan dengan komponen perutean sadar beban. Node pengalihan ALB secara berkala mengumpulkan metrik real-time dari setiap backend dalam grup server. Komponen perutean sadar beban memberi skor dan mengurutkan backend berdasarkan metrik tersebut, dengan memprioritaskan backend yang memiliki beban paling rendah (skor terbaik). Jika beberapa backend memiliki skor optimal yang mirip, penjadwalan sekunder menggunakan algoritma weighted round-robin (WRR).

  • Instans ALB Edisi Ekstensibel — Menyediakan load balancing dan pengalihan lalu lintas. Node pengalihan juga menangani pengumpulan metrik backend.

  • Grup server — Mendukung tipe server dan tipe IP, serta dapat mencakup backend kontainer ACK atau ACS. Algoritma penjadwalan harus diatur ke weighted round-robin dan grup harus dikaitkan dengan Service Extension yang berisi komponen perutean sadar beban.

  • Service Extension — Menampung komponen perutean sadar beban. Berlaku setelah dikaitkan ke grup server.

  • Komponen perutean sadar beban — Plugin yang dibangun ke dalam rantai pengalihan ALB yang memberi skor dan mengurutkan backend berdasarkan metrik yang dikumpulkan oleh node pengalihan, lalu menghasilkan backend optimal untuk penjadwalan.

  • Layanan inferensi backend — Mengekspos metrik inferensi dalam format Prometheus (saat ini mendukung framework vLLM) untuk dikumpulkan oleh ALB.

Prinsip penjadwalan

  1. Pengumpulan metrik — Node pengalihan secara berkala mengirim permintaan HTTP ke path pengumpulan backend (default /metrics) untuk mengumpulkan metrik. Saluran pengumpulan ini terpisah dari saluran pemeriksaan kesehatan. Jika pengumpulan metrik gagal untuk backend tertentu, backend tersebut dihapus dari penjadwalan. Jika pengumpulan gagal untuk semua backend, sistem kembali menggunakan weighted round-robin.

  2. Pemberian skor dan pengurutan — Setiap metrik penilaian dinormalisasi di seluruh himpunan backend, lalu diberi bobot dan dijumlahkan sesuai bobot yang dikonfigurasi untuk menghasilkan skor beban bagi setiap backend. Nilai metrik yang lebih rendah menunjukkan backend yang lebih idle, dan backend dengan skor lebih baik dipilih terlebih dahulu.

  3. Penjadwalan sekunder — Jika hasil pengurutan berisi beberapa backend dengan skor optimal yang mirip (tumpang tindih), weighted round-robin memilih di antara backend tersebut berdasarkan bobot. Jika tidak ada tumpang tindih, backend dengan skor terbaik dipilih langsung.

Perutean sadar beban mendukung metrik keputusan berikut secara default:

Metric

Type

Description

vLLM metric

TotalQueuedRequests (panjang antrian permintaan)

Gauge

Jumlah permintaan yang saat ini dalam antrian dan menunggu untuk diproses.

vllm:num_requests_waiting

KVCacheUtilization (pemanfaatan cache GPU)

Gauge

Persentase pemanfaatan cache KV saat ini yang digunakan untuk menyimpan hasil inferensi antara.

vllm:gpu_cache_usage_perc

RunningRequests (jumlah permintaan yang sedang berjalan)

Gauge

Jumlah permintaan yang sedang diproses.

vllm:num_requests_running

Prasyarat

  • Anda telah memperoleh akses pratinjau publik ALB Edisi Ekstensibel.

  • Anda telah membuat VPC (VPC1) di wilayah China (Shanghai), dengan vSwitch VSW1 di Zona B dan vSwitch VSW2 di Zona F.

  • Anda telah membuat kluster ACK dengan node GPU di VPC1 dan men-deploy layanan inferensi yang mengekspos metrik inferensi dalam format Prometheus. Topik ini menggunakan DeepSeek-R1-Distill-Qwen-1.5B yang dideploy dengan vLLM sebagai contoh. Layanan ini mendengarkan pada port 8000 dan mengekspos metrik di /metrics.

Prosedur

1. (Opsional) Deploy layanan inferensi contoh

Langkah ini menyediakan layanan inferensi vLLM contoh yang mengekspos metrik Prometheus (menggunakan DeepSeek-R1-Distill-Qwen-1.5B sebagai contoh, dengan tipe instans ECS ecs.gn7i-c16g1.4xlarge). Layanan ini digunakan untuk pengumpulan metrik dan penjadwalan perutean sadar beban pada langkah-langkah berikutnya. Bagian uji verifikasi juga menggunakan model contoh ini untuk benchmarking. Jika Anda telah men-deploy layanan inferensi seperti yang dijelaskan di bagian Prasyarat, Anda dapat melewati langkah ini. Anda juga dapat merujuk ke Deploy layanan inferensi model besar Qwen.

  1. Siapkan model dan konfigurasikan volume penyimpanan. Setelah mengunduh model dan mengunggahnya ke OSS, rujuk ke Konfigurasi volume penyimpanan OSS untuk mengonfigurasi PV dan PVC (seperti example-oss-swap) untuk kluster, yang akan dimount oleh layanan inferensi untuk mengakses model. Menyimpan model di OSS dan menariknya melalui jaringan internal menghindari waktu lama yang diperlukan untuk unduhan melalui jaringan publik.

    # 1. Unduh model
    GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B.git
    cd DeepSeek-R1-Distill-Qwen-1.5B
    git lfs pull
    
    # 2. Unggah model ke OSS
    ossutil mkdir oss://<Your-Bucket-Name>/DeepSeek-R1-Distill-Qwen-1.5B
    ossutil cp -r ./DeepSeek-R1-Distill-Qwen-1.5B oss://<Your-Bucket-Name>/DeepSeek-R1-Distill-Qwen-1.5B
  2. Buat Deployment dan Service untuk layanan inferensi di kluster ACK. Konfigurasi berikut menjalankan layanan inferensi menggunakan vLLM dan mendeklarasikan anotasi pengumpulan Prometheus pada Pod, mengekspos endpoint metrik di /metrics pada port 8000.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: deepseek-r1-distill-qwen-1.5b
      name: deepseek-r1-distill-qwen-1.5b
      namespace: default
    spec:
      replicas: 4
      selector:
        matchLabels:
          app: deepseek-r1-distill-qwen-1.5b
      template:
        metadata:
          labels:
            app: deepseek-r1-distill-qwen-1.5b
          annotations:
            prometheus.io/path: /metrics
            prometheus.io/port: "8000"
            prometheus.io/scrape: "true"
        spec:
          volumes:
            - name: model
              persistentVolumeClaim:
                claimName: example-oss-swap
            - name: dshm
              emptyDir:
                medium: Memory
                sizeLimit: 30Gi
          containers:
          - command:
            - sh
            - -c
            - vllm serve /models/DeepSeek-R1-Distill-Qwen-1.5B --port 8000 --trust-remote-code --served-model-name deepseek-r1-distill-qwen-1.5b --gpu-memory-utilization 0.95 --enforce-eager
            image: registry-cn-hangzhou.ack.aliyuncs.com/dev/vllm:0.10.0
            env:
            - name: SAFETENSORS_FAST_GPU_TRANSFER
              value: "0"
            - name: SAFETENSORS_MAX_HEADER_LENGTH
              value: "10000000"
            name: vllm
            ports:
            - containerPort: 8000
            readinessProbe:
              tcpSocket:
                port: 8000
              initialDelaySeconds: 30
              periodSeconds: 30
            resources:
              limits:
                nvidia.com/gpu: "1"
            volumeMounts:
              - mountPath: /models/
                name: model
              - mountPath: /dev/shm
                name: dshm
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: deepseek-r1-distill-qwen-1-5b-v1
    spec:
      type: ClusterIP
      ports:
      - port: 8000
        protocol: TCP
        targetPort: 8000
      selector:
        app: deepseek-r1-distill-qwen-1.5b
  3. Setelah Pod siap, masuk ke salah satu Pod untuk memverifikasi bahwa endpoint metrik diekspos dengan benar. Respons harus berisi metrik seperti vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, dan vllm:num_requests_running.

    curl http://<Pod-IP>:8000/metrics

2. Buat instans ALB Edisi Ekstensibel

  1. Masuk ke Konsol ALB. Pilih wilayah China (Shanghai) dan klik Create ALB.

  2. Di halaman pembelian, lengkapi konfigurasi berikut dan klik Create Now.

    • Region: Pilih China (Shanghai).

    • Instance Network Type: Pilih Internet.

    • VPC dan Zone: Pilih VPC1, centang Shanghai Zone B dan Shanghai Zone F, lalu pilih VSW1 dan VSW2.

    • IP Version: Pilih IPv4.

    • Edition (Instance Fee): Pilih Extensible Edition.

  3. Di halaman Confirm Order, konfirmasi detail konfigurasi instans dan klik Activate Now.

3. Buat Service Extension dan tambahkan komponen perutean sadar beban

Permintaan pengumpulan metrik dikirim melalui HTTP 1.1 hanya menggunakan alamat IPv4. Backend IPv6 tidak didukung. Badan respons pengumpulan metrik untuk satu backend dibatasi hingga 10 KB secara default. Tempatkan metrik yang diperlukan (vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:num_requests_running) dalam 10 KB pertama output metrik. Untuk detail tambahan, lihat Limits.

  1. Di Konsol Service Extension, klik Create Service Extension. Di bagian Service Extension Configuration, masukkan Extension name seperti ext-load-aware-routing.

  2. Extension Type diatur ke Plug-in secara default. Dari dropdown Component name, pilih Load-Aware Routing. Lengkapi konfigurasi berikut dan klik Create.

    • Collection Configuration:

      • Host: Nilai header permintaan Host untuk permintaan pengumpulan metrik. Biarkan bidang ini kosong dalam contoh ini, artinya sistem menggunakan IP:Port masing-masing backend dalam grup server untuk pengumpulan.

      • Path: Path permintaan untuk pengumpulan metrik. Contoh ini menggunakan /metrics.

      • Response Timeout: Default adalah 5 detik.

      • Interval: Atur ke 1 detik.

    • Metric Configuration: Pilih ketiganya: Total Queued Requests, GPU Cache Utilization, dan Running Requests. Atur bobot masing-masing menjadi 100, 90, dan 80.

Komponen perutean sadar beban harus digunakan dengan grup server Server atau IP Address, dan tidak dapat ditambahkan ke Service Extension yang sama dengan komponen lain.

4. Buat grup server dan kaitkan Service Extension

Buat grup server untuk menampung replika inferensi backend dan kaitkan dengan Service Extension perutean sadar beban yang dibuat di Langkah 3.

  1. Di Konsol Grup Server, pilih wilayah China (Shanghai). Klik Create Server Group, lengkapi konfigurasi berikut, dan klik Create.

    • Server Group Type: Pilih IP Address.

    • Server Group Name: Masukkan nama kustom seperti sgp-load-aware.

    • VPC: Pilih VPC1.

    • Scheduling Algorithm: Gunakan default Weighted Round-robin. Perutean sadar beban hanya mendukung kombinasi dengan weighted round-robin.

    • Nonaktifkan Health Check.

      Dalam contoh ini, Pod backend tidak menyediakan antarmuka yang diperlukan untuk pemeriksaan kesehatan ALB. Jika pemeriksaan kesehatan diaktifkan, backend akan ditentukan tidak sehat, sehingga perutean sadar beban dilewati. Jika backend Anda menyediakan antarmuka pemeriksaan kesehatan, tetap aktifkan pemeriksaan kesehatan. Menonaktifkan tidak disarankan.
      Pengumpulan metrik dalam perutean sadar beban memiliki deteksi ketersediaan bawaan: backend yang metriknya tidak dapat dikumpulkan akan dihapus secara otomatis, memberikan kemampuan serupa dengan pemeriksaan kesehatan.
    • Pilih kotak centang For Extensible instances di bagian bawah halaman. Aktifkan Associate Service Extension dan Use Existing Service Extension. Pilih ext-load-aware-routing yang dibuat di Langkah 3.

  2. Setelah Server Group Created, klik Add Backend Servers. Di panel Add Backend Server, tambahkan alamat Pod dari layanan inferensi yang telah dideploy (dapat diperoleh dari daftar kluster ACK > Details > Network > Services). Klik Add IP Address untuk menambahkan beberapa entri, lalu klik Next.

  3. Di langkah Ports/Weights, atur Port ke 8000, pertahankan Weight pada nilai default, dan klik OK.

5. Buat listener

  1. Di Konsol ALB, klik ID instans target untuk membuka halaman Instance Details. Di tab Listener, klik Create Listener.

  2. Di langkah Configure Listener, atur Listener Protocol ke HTTP dan Listener Port ke 80. Di Advanced Settings, atur Connection Request Timeout ke 3600 detik. Lalu klik Next.

    Contoh ini menggunakan listener HTTP untuk menyederhanakan konfigurasi dan fokus pada verifikasi efek penjadwalan perutean sadar beban. Di lingkungan produksi, gunakan listener HTTPS dengan sertifikat yang dikonfigurasi untuk keamanan transport.
    Permintaan inferensi LLM (terutama saat menghasilkan banyak token output) dapat memakan waktu lama per respons. Jika waktu respons melebihi timeout permintaan default listener (60 detik), permintaan akan dihentikan sebelum waktunya. Contoh ini mengatur timeout permintaan menjadi 3600 detik untuk mencegah respons panjang terputus. Sesuaikan nilai ini berdasarkan durasi permintaan aktual Anda.
  3. Di langkah Select Server Group, pilih grup server sgp-load-aware yang dibuat di Langkah 4. Lalu klik Next.

  4. Di langkah Configuration Review, konfirmasi konfigurasi dan klik Submit.

6. Konfigurasi resolusi DNS

Arahkan domain kustom Anda ke nama DNS instans ALB melalui rekaman CNAME agar klien dapat mengakses ALB melalui domain kustom Anda.

Contoh ini menggunakan DNS Alibaba Cloud. Untuk domain yang tidak didaftarkan di Alibaba Cloud, Anda harus terlebih dahulu menambahkan domain ke konsol DNS.

  1. Di Konsol ALB, salin Domain Name instans target.

  2. Masuk ke Konsol DNS. Di kolom Actions domain target, klik Settings. Di halaman Settings, klik Add Record.

  3. Tambahkan rekaman CNAME dengan informasi berikut, lalu klik OK.

    • Record Type: Pilih CNAME.

    • Hostname: Masukkan awalan domain seperti test. Jika domain root Anda adalah example.com, domain untuk mengakses ALB adalah test.example.com.

    • Query Source dan TTL: Pertahankan nilai default.

    • Record Value: Masukkan nama DNS instans ALB.

  4. Di kotak dialog Change Resource Record Confirmation yang muncul, konfirmasi informasi resolusi dan klik OK.

7. Uji verifikasi

Gunakan tool benchmarking vllm bench serve untuk menjalankan uji stres terhadap backend. Untuk menghindari gangguan dari lebar pita jaringan publik, latensi, dan jitter terhadap hasil pengujian, contoh ini menjalankan benchmark dari lingkungan jaringan internal dalam VPC yang sama dengan ALB: Pod benchmark khusus dideploy (hanya menginstal tool vLLM dan memount model yang sama, tanpa menjalankan layanan inferensi) sebagai klien pengujian, terpisah dari backend yang diuji, untuk menghindari konsumsi sumber daya inferensi atau mengganggu pengumpulan metrik.

Dengan mengatur target konkurensi yang jauh melebihi batas performa layanan, GPU backend berjalan di bawah beban ekstrem. Hal ini memvalidasi apakah perutean sadar beban dapat mengoptimalkan distribusi permintaan, mengurangi antrean ekstrem, dan mempercepat throughput keseluruhan.

Pengalihan Kubernetes Service

Jalankan benchmark terhadap Kubernetes Service dari layanan inferensi backend. Service mendistribusikan koneksi secara merata ke semua replika inferensi tanpa mendeteksi beban real-time.

Ganti --host dengan ClusterIP Service (dapat diperoleh dari daftar kluster ACK > Details > Network > Services).

vllm bench serve \
  --backend vllm \
  --model /models/DeepSeek-R1-Distill-Qwen-1.5B \
  --served-model-name deepseek-r1-distill-qwen-1.5b \
  --trust-remote-code \
  --dataset-name random \
  --random-prefix-len 1000 \
  --random-input-len 3000 \
  --random-output-len 3000 \
  --random-range-ratio 0.2 \
  --num-prompts 3000 \
  --max-concurrency 600 \
  --host <Service-ClusterIP> \
  --port 8000 \
  --endpoint /v1/completions \
  --save-result \
  2>&1 | tee benchmark_svc.txt

Perutean sadar beban ALB

Jalankan benchmark terhadap instans ALB. Perutean sadar beban menjadwalkan permintaan di seluruh replika inferensi yang sama berdasarkan beban real-time.

Ganti --host dengan alamat IP virtual (VIP) instans ALB (dapat diperoleh dari halaman produk instans). Pertahankan semua parameter lainnya sama.

vllm bench serve \
  --backend vllm \
  --model /models/DeepSeek-R1-Distill-Qwen-1.5B \
  --served-model-name deepseek-r1-distill-qwen-1.5b \
  --trust-remote-code \
  --dataset-name random \
  --random-prefix-len 1000 \
  --random-input-len 3000 \
  --random-output-len 3000 \
  --random-range-ratio 0.2 \
  --num-prompts 3000 \
  --max-concurrency 600 \
  --host <ALB-VIP> \
  --port 80 \
  --endpoint /v1/completions \
  --save-result \
  2>&1 | tee benchmark_alb.txt

Perbandingan metrik utama antara kedua pendekatan adalah sebagai berikut. Data di bawah ini berasal dari lingkungan pengujian dalam contoh ini dan hanya sebagai referensi. Hasil aktual bergantung pada lingkungan Anda sendiri.

Metric

Pengalihan Kubernetes Service

Perutean Sadar Beban ALB

P99 TTFT (ms)

71872,40

60504,53

Rata-rata TTFT (ms)

12709,49

12043,91

Median TTFT (ms)

7156,46

5492,57

Throughput token total (token/detik)

18285,60

18784,43

Durasi benchmark (detik)

959,95

935,97

Dengan jumlah backend yang sama, perutean sadar beban secara signifikan mengurangi waktu hingga token pertama (TTFT) dengan menjadwalkan permintaan secara preferensial ke replika yang beban kerjanya lebih ringan. Dalam pengujian ini, P99 TTFT menurun sekitar 16% dan Median TTFT menurun sekitar 23%, sementara throughput keseluruhan sedikit meningkat dan distribusi latensi permintaan menjadi lebih stabil.

Informasi lebih lanjut

Tagihan

  • ALB Edisi Ekstensibel — Saat ini dalam pratinjau publik dan tersedia gratis.

  • Kluster ACK dan instans GPU — Layanan inferensi backend berjalan pada node GPU di kluster ACK. Penagihan mengikuti aturan harga Container Service dan instans ECS yang sesuai. Jika dibuat untuk tujuan pengujian, gunakan instans pay-as-you-go dan segera lepas setelah selesai.

  • Biaya domain dan resolusi DNS publik — Selain biaya domain dari penyedia domain Anda, konfigurasi resolusi DNS publik di Alibaba Cloud dikenai biaya resolusi otoritatif publik.

Batasan

  • Permintaan pengumpulan metrik dikirim menggunakan HTTP 1.1 melalui alamat IPv4. Backend IPv6 saat ini tidak didukung.

  • Badan respons pengumpulan metrik untuk satu backend dibatasi hingga 10 KB secara default. Konten yang melebihi batas ini akan dibuang, yang dapat menyebabkan pengumpulan metrik tidak lengkap. Perutean sadar beban hanya menggunakan tiga metrik: vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, dan vllm:num_requests_running. Tempatkan metrik ini dalam 10 KB pertama output metrik untuk memastikan pengumpulan yang tepat.

FAQ

Setelah mengaktifkan perutean sadar beban, distribusi permintaan sama seperti weighted round-robin?

Verifikasi pengaturan berikut:

  • Algoritma penjadwalan — Algoritma penjadwalan grup server diatur ke weighted round-robin.

  • Asosiasi Service Extension — Grup server dikaitkan dengan benar ke Service Extension yang berisi komponen perutean sadar beban.

  • Eksposur metrik — Backend mengekspos metrik vLLM dengan benar di path pengumpulan metrik. Jika pengumpulan metrik gagal, perutean sadar beban kembali menggunakan weighted round-robin.

  • Pemeriksaan kesehatan — Verifikasi apakah status pemeriksaan kesehatan normal. Saat diaktifkan, backend yang gagal pemeriksaan kesehatan dihapus dan dilewati oleh penjadwalan sadar beban. Saat semua backend tidak sehat, perutean sadar beban sepenuhnya kembali ke weighted round-robin.