Panduan untuk layanan backend pengujian beban dengan Load Balancer Aplikasi

Saat mengintegrasikan layanan backend dengan Load Balancer Aplikasi, penting untuk mengukur performa layanan backend secara mandiri, jika tidak ada load balancer. Pengujian beban dalam kondisi terkontrol membantu Anda menilai kompromi perencanaan kapasitas antara berbagai dimensi performa, seperti throughput dan latensi. Karena perencanaan kapasitas yang cermat masih dapat meremehkan permintaan yang sebenarnya, sebaiknya gunakan pengujian beban untuk secara proaktif menentukan pengaruh terhadap ketersediaan layanan saat sistem berlebihan beban.

Sasaran pengujian beban

Uji beban standar mengukur perilaku layanan backend yang terlihat secara eksternal pada berbagai dimensi beban. Beberapa dimensi yang paling relevan dari pengujian ini adalah sebagai berikut:

• Throughput permintaan: Jumlah permintaan yang dilayani per detik.
• Permintaan serentak: Jumlah permintaan yang diproses secara serentak.
• Throughput koneksi: Jumlah koneksi yang dimulai oleh klien per detik. Sebagian besar layanan yang menggunakan Transport Layer Security (TLS) memiliki beberapa overhead transportasi jaringan dan negosiasi TLS yang terkait dengan setiap koneksi yang tidak bergantung pada pemrosesan permintaan.

• Koneksi serentak: Jumlah koneksi klien yang diproses secara serentak.

  Catatan: Jumlah ini mungkin lebih rendah daripada permintaan serentak karena klien HTTPS sering menggunakan kembali koneksi untuk beberapa permintaan. Perlu diperhatikan bahwa koneksi menggunakan resource sistem (seperti RAM dan handle file) meskipun tidak melayani permintaan.

• Latensi permintaan: Total waktu yang berlalu antara awal permintaan dan akhir respons.

• Tingkat error: Seberapa sering permintaan menyebabkan error, seperti error HTTP 5xx dan koneksi yang ditutup terlalu awal.

Untuk menilai kesehatan server yang sedang mengalami beban, prosedur uji beban juga dapat mengumpulkan metrik layanan internal berikut:

• Penggunaan resource sistem: Resource sistem, seperti CPU, RAM, dan handle file (soket), biasanya dinyatakan dalam persentase.

  Nilai penting metrik ini berbeda-beda bergantung pada cara layanan tersebut diimplementasikan. Aplikasi akan mengalami penurunan performa, penurunan beban, atau error saat resource habis. Oleh karena itu, penting untuk menentukan ketersediaan resource saat host mengalami beban berat.

• Penggunaan resource terbatas lainnya: Resource non-sistem yang dapat dihapus karena beban, seperti pada lapisan aplikasi.

  Beberapa contoh referensi tersebut antara lain:

  • Kumpulan thread atau proses pekerja yang terikat.
  • Untuk server aplikasi yang menggunakan thread, pembatasan jumlah thread pekerja yang beroperasi secara serentak adalah hal yang umum. Batas ukuran kumpulan thread berguna untuk mencegah kehabisan memori dan CPU, tetapi setelan default sering kali sangat konservatif. Batas yang terlalu rendah dapat mencegah penggunaan resource sistem yang memadai.
  • Beberapa server menggunakan kumpulan proses, bukan kumpulan thread. Misalnya, server Apache saat disiapkan dengan Model Multi-Pemrosesan Prefork, menetapkan satu proses ke setiap koneksi klien. Jadi, batas ukuran kumpulan menentukan batas atas pada konkurensi koneksi.
  • Layanan yang di-deploy sebagai frontend ke layanan lain yang memiliki kumpulan koneksi backend dengan ukuran terbatas.

Perencanaan kapasitas versus pengujian kelebihan beban

Alat pengujian beban membantu Anda mengukur berbagai dimensi penskalaan satu per satu. Untuk perencanaan kapasitas, tentukan nilai minimum beban untuk performa yang dapat diterima di beberapa dimensi. Misalnya, pertimbangkan untuk mengukur hal berikut, bukan mengukur batas absolut permintaan layanan secara keseluruhan:

• Tingkat permintaan saat layanan dapat melayani dengan latensi persentil ke-99 yang kurang dari jumlah milidetik yang ditentukan. Angka tersebut ditentukan oleh SLO layanan.
• Rasio permintaan maksimum yang tidak menyebabkan pemanfaatan resource sistem melebihi tingkat optimal. Perhatikan bahwa pemanfaatan yang optimal bervariasi menurut aplikasi dan dapat secara signifikan kurang dari 100%. Misalnya, pada pemanfaatan memori puncak 80%, aplikasi mungkin dapat menangani lonjakan beban minor dengan lebih baik dibandingkan jika pemakaian puncak berada pada 99%.

Meskipun menggunakan hasil uji beban untuk membuat keputusan perencanaan kapasitas penting, memahami perilaku layanan saat beban melebihi kapasitas juga sama pentingnya. Beberapa perilaku server yang sering dievaluasi menggunakan pengujian overload adalah sebagai berikut:

• Load-shedding: Jika menerima permintaan atau koneksi masuk yang berlebihan, layanan tersebut dapat merespons dengan memperlambat semua permintaan, atau dengan menolak beberapa permintaan untuk mempertahankan performa yang dapat diterima untuk permintaan yang tersisa. Kami merekomendasikan pendekatan yang kedua untuk mencegah waktu tunggu klien sebelum menerima respons dan untuk mengurangi risiko kehabisan memori dengan menurunkan konkurensi permintaan di server.

• Ketahanan terhadap kehabisan resource: Layanan umumnya menghindari error karena kehabisan resource karena sulit bagi permintaan yang tertunda untuk membuat progres lebih lanjut jika layanan mengalami error. Jika layanan backend memiliki banyak instance, keandalan instance individual sangat penting untuk ketersediaan layanan secara keseluruhan. Saat instance dimulai ulang dari error, instance lain mungkin mengalami lebih banyak beban, yang berpotensi menyebabkan kegagalan beruntun.

Pedoman pengujian umum

Saat menentukan kasus pengujian, pertimbangkan panduan berikut.

Catatan: Pedoman yang tercantum di bagian ini tidak berlaku untuk setiap layanan, dan daftar ini tidak lengkap. Untuk mengetahui informasi selengkapnya, lihat halaman praktik benchmark terbaik yang dikelola oleh project Envoy. Halaman ini berisi banyak saran yang relevan dengan pengujian beban layanan HTTPS apa pun.

Membuat pengujian berskala kecil

Buat pengujian skala kecil untuk mengukur batas performa server. Dengan kapasitas server yang berlebihan, ada risiko bahwa pengujian tidak akan menampilkan batas performa layanan itu sendiri, tetapi mungkin mengungkap bottleneck di sistem lain, seperti host klien atau lapisan jaringan.

Untuk hasil terbaik, pertimbangkan kasus pengujian yang menggunakan satu instance virtual machine (VM) atau Pod Google Kubernetes Engine (GKE) untuk menguji layanan secara independen. Untuk mencapai beban penuh di server, jika perlu, Anda dapat menggunakan beberapa VM. Namun, perlu diingat bahwa VM dapat mempersulit pengumpulan data performa.

Memilih pola pemuatan loop terbuka

Sebagian besar generator beban menggunakan pola loop tertutup untuk membatasi jumlah permintaan serentak dan menunda permintaan baru hingga permintaan sebelumnya selesai. Kami tidak merekomendasikan pendekatan ini karena klien produksi layanan mungkin tidak menunjukkan perilaku throttling tersebut.

Sebaliknya, pola open loop memungkinkan generator beban menyimulasikan beban produksi dengan mengirimkan permintaan pada kecepatan yang stabil, terlepas dari kecepatan respons server yang tiba.

Menjalankan pengujian menggunakan generator beban yang direkomendasikan

Kami merekomendasikan generator beban berikut untuk pengujian beban layanan backend:

Burung rajawali

Nighthawk adalah alat open source yang dikembangkan melalui koordinasi dengan project Envoy. Anda dapat menggunakannya untuk menghasilkan pemuatan klien, memvisualisasikan benchmark, dan mengukur performa server untuk sebagian besar skenario pengujian pemuatan layanan HTTPS.

Uji HTTP/1

Untuk menguji HTTP/1, gunakan perintah berikut:

nighthawk_client URI \
    --duration DURATION \
    --open-loop \
    --no-default-failure-predicates \
    --protocol http1 \
    --request-body-size REQ_BODY_SIZE \
    --concurrency CONCURRENCY \
    --rps RPS \
    --connections CONNECTIONS

Ganti kode berikut:

• URI: URI yang akan diukur
• DURATION: total waktu pengujian dalam detik
• REQ_BODY_SIZE: ukuran payload POST dalam setiap permintaan

• CONCURRENCY: jumlah total loop peristiwa serentak

  Jumlah ini harus sesuai dengan jumlah inti VM klien

• RPS: target rasio permintaan per detik, per loop peristiwa

• CONNECTIONS: jumlah koneksi serentak, per loop peristiwa

Catatan: Tanda no-default-failure-predicates baru. Gunakan build Nighthawk terbaru untuk mengujinya.

Lihat contoh berikut:

nighthawk_client http://10.20.30.40:80 \
    --duration 600 --open-loop --no-default-failure-predicates \
    --protocol http1 --request-body-size 5000 \
    --concurrency 16 --rps 500 --connections 200

Output dari setiap pengujian memberikan histogram latensi respons. Dalam contoh dari dokumentasi Nighthawk, perhatikan bahwa latensi persentil ke-99 adalah sekitar 135 mikrodetik.

Initiation to completion
    samples: 9992
    mean:    0s 000ms 113us
    pstdev:  0s 000ms 061us

    Percentile  Count       Latency
    0           1           0s 000ms 077us
    0.5         4996        0s 000ms 115us
    0.75        7495        0s 000ms 118us
    0.8         7998        0s 000ms 118us
    0.9         8993        0s 000ms 121us
    0.95        9493        0s 000ms 124us
    0.990625    9899        0s 000ms 135us
    0.999023    9983        0s 000ms 588us
    1           9992        0s 004ms 090us

Uji HTTP/2

Untuk menguji HTTP/2, gunakan perintah berikut:

nighthawk_client URI \
    --duration DURATION \
    --open-loop \
    --no-default-failure-predicates \
    --protocol http2 \
    --request-body-size REQ_BODY_SIZE \
    --concurrency CONCURRENCY \
    --rps RPS \
    --max-active-requests MAX_ACTIVE_REQUESTS \
    --max-concurrent-streams MAX_CONCURRENT_STREAMS

Ganti kode berikut:

• URI: URI yang akan diukur
• DURATION: total waktu pengujian dalam detik
• REQ_BODY_SIZE: ukuran payload POST dalam setiap permintaan

• CONCURRENCY: jumlah total loop peristiwa serentak

  Jumlah ini harus sesuai dengan jumlah inti VM klien

• RPS: target rasio permintaan per detik untuk setiap loop peristiwa

• MAX_ACTIVE_REQUESTS: jumlah maksimum permintaan aktif serentak untuk setiap loop peristiwa

• MAX_CONCURRENT_STREAMS: jumlah maksimum streaming serentak yang diizinkan pada setiap koneksi HTTP/2

Lihat contoh berikut:

nighthawk_client http://10.20.30.40:80 \
    --duration 600 --open-loop --no-default-failure-predicates \
    --protocol http2 --request-body-size 5000 \
    --concurrency 16 --rps 500 \
    --max-active-requests 200 --max-concurrent-streams 1

ab (alat tolok ukur Apache)

ab adalah alternatif yang kurang fleksibel untuk Nighthawk, tetapi tersedia sebagai paket di hampir setiap distribusi Linux. ab hanya direkomendasikan untuk pengujian cepat dan sederhana.

Untuk menginstal ab, gunakan perintah berikut:

• Di Debian dan Ubuntu, jalankan sudo apt-get install apache2-utils.
• Pada distribusi berbasis RedHat, jalankan sudo yum install httpd-utils.

Setelah Anda menginstal ab, gunakan perintah berikut untuk menjalankannya:

ab -c CONCURRENCY \
    -n NUM_REQUESTS \
    -t TIMELIMIT \
    -p POST_FILE URI

Ganti kode berikut:

• CONCURRENCY: jumlah permintaan serentak yang harus dijalankan
• NUM_REQUESTS: jumlah permintaan yang akan dijalankan
• TIMELIMIT: jumlah detik maksimum untuk dihabiskan pada permintaan
• POST_FILE: file lokal yang berisi payload HTTP POST
• URI: URI yang akan diukur

Lihat contoh berikut:

ab -c 200 -n 1000000 -t 600 -P body http://10.20.30.40:80

Perintah dalam contoh sebelumnya mengirimkan permintaan dengan konkurensi 200 (pola loop tertutup), dan berhenti setelah 1.000.000 (satu juta) permintaan atau 600 detik waktu berlalu. Perintah tersebut juga menyertakan konten file body sebagai payload HTTP POST.

Perintah ab menghasilkan histogram latensi respons yang mirip dengan yang seperti Nighthawk, tetapi resolusinya terbatas ke milidetik, bukan mikrodetik:

Percentage of the requests served within a certain time (ms)
    50%     7
    66%     7
    75%     7
    80%     7
    90%    92
    95%   121
    98%   123
    99%   127
    100%  156 (longest request)

Langkah selanjutnya

• Pengelolaan kapasitas dengan load balancing