Opsi untuk load balancing
Bergantung pada jenis traffic yang dikirim ke aplikasi, Anda memiliki beberapa opsi untuk load balancing eksternal. Tabel berikut merangkum opsi Anda:
| Opsi | Deskripsi | Arus traffic | Cakupan |
|---|---|---|---|
| Load Balancer Aplikasi Eksternal | Mendukung traffic HTTP(S) dan fitur lanjutan, seperti pemetaan URL
dan offloading SSL Gunakan Network Load Balancer proxy eksternal untuk traffic non-HTTP di port tertentu. |
Sesi TCP atau SSL (TLS) dihentikan di Google Front Ends (GFE), di edge jaringan Google, dan traffic di-proxy ke backend. | Global |
| Load Balancer Jaringan passthrough eksternal | Memungkinkan traffic TCP/UDP menggunakan port apa pun untuk melewati load balancer. | Dikirim menggunakan teknologi Maglev Google untuk mendistribusikan traffic ke backend. | Regional |
Karena load balancer internal dan Cloud Service Mesh tidak mendukung traffic yang ditampilkan kepada pengguna, keduanya tidak termasuk dalam cakupan artikel ini.
Pengukuran dalam artikel ini menggunakan Paket Premium di Network Service Tiers karena load balancing global memerlukan tingkat layanan ini.
Mengukur latensi
Saat mengakses situs yang dihosting di us-central1, pengguna di Jerman menggunakan metode berikut untuk menguji latensi:
- Ping: Meskipun ping ICMP adalah cara umum untuk mengukur keterjangkauan server, ping ICMP tidak mengukur latensi pengguna akhir. Untuk mengetahui informasi selengkapnya, lihat Efek latensi tambahan dari Load Balancer Aplikasi eksternal.
- Curl: Curl mengukur Time To First Byte (TTFB). Berikan perintah
curlberulang kali ke server.
Saat membandingkan hasil, perhatikan bahwa latensi pada link fiber dibatasi oleh jarak dan kecepatan cahaya dalam fiber, yang kira-kira 200.000 km per detik (atau 124.724 mil per detik).
Jarak antara Frankfurt, Jerman dan Council Bluffs, Iowa (wilayah
us-central1), adalah sekitar 7.500 km. Dengan fiber langsung di antara
lokasi, latensi bolak-balik adalah sebagai berikut:
7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)
Kabel fiber optik tidak mengikuti jalur lurus antara pengguna dan pusat data. Cahaya pada kabel fiber melewati peralatan aktif dan pasif di sepanjang jalurnya. Latensi yang diamati sekitar 1,5 kali ideal, atau 112,5 md, menunjukkan konfigurasi yang hampir ideal.
Membandingkan latensi
Bagian ini membandingkan load balancing dalam konfigurasi berikut:
- Tanpa load balancing
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Aplikasi Eksternal atau Load Balancer Jaringan proxy Eksternal
Dalam skenario ini, aplikasi terdiri dari grup instance terkelola regional
server web HTTP. Karena aplikasi mengandalkan panggilan latensi rendah ke database pusat, server web harus dihosting di satu lokasi. Aplikasi
di-deploy di wilayah us-central1, dan pengguna didistribusikan
di seluruh dunia. Latensi yang diamati pengguna di Jerman dalam skenario ini
menggambarkan pengalaman pengguna di seluruh dunia.
Tanpa load balancing
Saat pengguna membuat permintaan HTTP, kecuali jika load balancing dikonfigurasi, traffic akan mengalir langsung dari jaringan pengguna ke virtual machine (VM) yang dihosting di Compute Engine. Untuk Paket Premium, traffic kemudian memasuki jaringan Google di titik kehadiran (PoP) edge yang dekat dengan lokasi pengguna. Untuk Tingkat Standar, traffic pengguna memasuki jaringan Google di PoP yang dekat dengan region tujuan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Network Service Tiers.
Tabel berikut menunjukkan hasil saat pengguna di Jerman menguji latensi sistem tanpa load balancing:
| Metode | Hasil | Latensi minimum |
|---|---|---|
| Melakukan ping ke alamat IP VM (Respons langsung dari server web) |
ping -c 5 compute-engine-vm PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms 64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms [...] --- compute-engine-vm ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms |
110 md |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
0.230 0.230 0.231 0.231 0.230 [...] 0.232 0.231 0.231 |
230 md |
Latensi TTFB stabil, seperti yang ditunjukkan dalam grafik berikut untuk 500 permintaan pertama:
Saat melakukan ping ke alamat IP VM, responsnya berasal langsung dari server web. Waktu respons dari server web minimal dibandingkan dengan latensi jaringan (TTFB). Hal ini karena koneksi TCP baru dibuka untuk setiap permintaan HTTP. Handshake tiga arah awal diperlukan sebelum respons HTTP dikirim, seperti yang ditunjukkan pada diagram berikut. Oleh karena itu, latensi yang diamati hampir dua kali lipat latensi ping.
Load Balancer Jaringan passthrough eksternal
Dengan Load Balancer Jaringan passthrough eksternal, permintaan pengguna tetap memasuki jaringan Google di PoP edge terdekat (di Paket Premium). Di region tempat VM project berada, traffic akan mengalir terlebih dahulu melalui Load Balancer Jaringan passthrough eksternal. Kemudian, VM tersebut akan diteruskan tanpa perubahan ke VM backend target. Load Balancer Jaringan passthrough eksternal mendistribusikan traffic berdasarkan algoritma hashing yang stabil. Algoritma ini menggunakan kombinasi port sumber dan tujuan, alamat IP, dan protokol. VM mendengarkan IP load balancer dan menerima traffic tanpa perubahan.
Tabel berikut menunjukkan hasil saat pengguna di Jerman menguji latensi untuk opsi load balancing jaringan.
| Metode | Hasil | Latensi minimum |
|---|---|---|
| Mengirim ping ke Load Balancer Jaringan passthrough eksternal |
ping -c 5 net-lb PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms [...] 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms --- net-lb ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms |
110 md |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s net-lb
0.231 0.232 0.230 0.230 0.232 [...] 0.232 0.231 |
230 md |
Karena load balancing dilakukan dalam region dan traffic hanya diteruskan, tidak ada dampak latensi yang signifikan dibandingkan dengan tidak memiliki load balancer.
External load balancing
Dengan Load Balancer Aplikasi eksternal, GFE akan mem-proxy traffic. GFE ini berada di edge jaringan global Google. GFE menghentikan sesi TCP dan terhubung ke backend di region terdekat yang dapat menyalurkan traffic.
Tabel berikut menunjukkan hasil saat pengguna di Jerman menguji latensi untuk opsi load balancing HTTP.
| Metode | Hasil | Latensi minimum |
|---|---|---|
| Mengirim ping ke Load Balancer Aplikasi eksternal |
ping -c 5 http-lb PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms --- http-lb ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms |
1 md |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s http-lb; done
0.309 0.230 0.229 0.233 0.230 [...] 0.123 0.124 0.126 |
123 md |
Hasil untuk Load Balancer Aplikasi eksternal sangat berbeda. Saat
mengirim ping ke Load Balancer Aplikasi eksternal, latensi bolak-balik sedikit lebih dari
1 md. Hasil ini menunjukkan latensi ke GFE terdekat, yang terletak di kota yang sama dengan pengguna. Hasil ini tidak mencerminkan latensi sebenarnya yang
dirasakan pengguna saat mencoba mengakses aplikasi yang dihosting di
region us-central1. Eksperimen yang menggunakan protokol (ICMP) yang berbeda dengan
protokol komunikasi aplikasi (HTTP) dapat menyesatkan.
Saat mengukur TTFB, permintaan awal menunjukkan latensi respons yang serupa. Beberapa permintaan mencapai latensi minimum yang lebih rendah, yaitu 123 md, seperti yang ditunjukkan pada grafik berikut:
Dua perjalanan bolak-balik antara klien dan VM memerlukan waktu lebih dari 123 md bahkan dengan fiber lurus. Latensi lebih rendah karena GFE melakukan proxy traffic. GFE mempertahankan koneksi persisten ke VM backend. Oleh karena itu, hanya permintaan pertama dari GFE tertentu ke backend tertentu yang memerlukan handshake tiga arah.
Setiap lokasi memiliki beberapa GFE. Grafik latensi menunjukkan beberapa lonjakan yang berfluktuasi saat pertama kali traffic mencapai setiap pasangan backend GFE. GFE kemudian harus membuat koneksi baru ke backend tersebut. Lonjakan ini mencerminkan hash permintaan yang berbeda. Permintaan berikutnya menunjukkan latensi yang lebih rendah.
Skenario ini menunjukkan pengurangan latensi yang dapat dialami pengguna di lingkungan produksi. Tabel berikut merangkum hasilnya:
| Opsi | Ping | TTFB |
|---|---|---|
| Tanpa load balancing | 110 md ke server web | 230 md |
| Load Balancer Jaringan passthrough eksternal | 110 md ke Load Balancer Jaringan passthrough eksternal dalam region | 230 md |
| Load Balancer Aplikasi Eksternal | 1 md ke GFE terdekat | 123 md |
Saat aplikasi yang sehat menayangkan pengguna di region tertentu, GFE di region tersebut akan mempertahankan koneksi persisten yang terbuka untuk semua backend penayangan. Oleh karena itu, pengguna di wilayah tersebut akan melihat pengurangan latensi pada permintaan HTTP pertama mereka jika pengguna berada jauh dari backend aplikasi. Jika pengguna berada dekat dengan backend aplikasi, mereka tidak akan melihat peningkatan latensi.
Untuk permintaan berikutnya, seperti mengklik link halaman, tidak ada peningkatan latensi karena browser modern mempertahankan koneksi persisten ke layanan. Ini berbeda dengan perintah curl yang dikeluarkan dari command line.
Efek latensi tambahan dari Load Balancer Aplikasi eksternal
Efek tambahan yang dapat diamati dengan Load Balancer Aplikasi eksternal bergantung pada pola traffic.
Load Balancer Aplikasi eksternal memiliki latensi yang lebih rendah untuk aset yang kompleks dibandingkan dengan Load Balancer Jaringan passthrough eksternal karena lebih sedikit perjalanan bolak-balik yang diperlukan sebelum respons selesai. Misalnya, saat pengguna di Jerman mengukur latensi melalui koneksi yang sama dengan mendownload file 10 MB berulang kali, latensi rata-rata untuk Load Balancer Jaringan passthrough eksternal adalah 1.911 md. Dengan Load Balancer Aplikasi eksternal, latensi rata-ratanya adalah 1.341 md. Hal ini menghemat sekitar 5 perjalanan bolak-balik per permintaan. Koneksi persisten antara GFE dan backend penayangan mengurangi efek TCP Slow Start.
Load Balancer Aplikasi eksternal secara signifikan mengurangi latensi tambahan untuk handshake TLS (biasanya 1–2 roundtrip tambahan). Hal ini karena Load Balancer Aplikasi eksternal menggunakan offloading SSL, dan hanya latensi ke PoP edge yang relevan. Untuk pengguna di Jerman, latensi minimum yang diamati adalah 201 md menggunakan Load Balancer Aplikasi eksternal, dibandingkan 525 md menggunakan HTTP(S) melalui Load Balancer Jaringan passthrough eksternal.
Load Balancer Aplikasi eksternal memungkinkan upgrade otomatis sesi yang ditampilkan kepada pengguna ke HTTP/2. HTTP/2 dapat mengurangi jumlah paket yang diperlukan, dengan menggunakan peningkatan protokol biner, kompresi header, dan multiplexing koneksi. Peningkatan ini dapat mengurangi latensi yang diamati bahkan lebih dari yang diamati dengan beralih ke Load Balancer Aplikasi eksternal. HTTP/2 didukung dengan browser saat ini yang menggunakan SSL/TLS. Untuk pengguna di Jerman, latensi minimum menurun lebih jauh dari 201 md menjadi 145 md saat menggunakan HTTP/2, bukan HTTPS.
Mengoptimalkan Load Balancer Aplikasi eksternal
Anda dapat mengoptimalkan latensi untuk aplikasi menggunakan Load Balancer Aplikasi eksternal sebagai berikut:
Jika sebagian traffic yang Anda kirimkan dapat disimpan dalam cache, Anda dapat berintegrasi dengan Cloud CDN. Cloud CDN mengurangi latensi dengan menayangkan aset secara langsung di edge jaringan Google. Cloud CDN juga menggunakan pengoptimalan TCP dan HTTP dari HTTP/2 yang disebutkan di bagian Efek latensi tambahan dari Load Balancer Aplikasi eksternal.
Anda dapat menggunakan partner CDN apa pun dengan Google Cloud. Dengan menggunakan salah satu partner CDN Interconnect Google, Anda akan mendapatkan diskon biaya transfer data.
Jika konten bersifat statis, Anda dapat mengurangi beban di server web dengan menayangkan konten langsung dari Cloud Storage melalui Load Balancer Aplikasi eksternal. Opsi ini digabungkan dengan Cloud CDN.
Men-deploy server web di beberapa region yang dekat dengan pengguna dapat mengurangi latensi karena load balancer secara otomatis mengarahkan pengguna ke region terdekat. Namun, jika aplikasi Anda sebagian terpusat, desain aplikasi tersebut untuk mengurangi jumlah perjalanan bolak-balik antar-regional.
Untuk mengurangi latensi di dalam aplikasi, periksa panggilan prosedur jarak jauh (RPC) yang berkomunikasi antar-VM. Latensi ini biasanya terjadi saat aplikasi berkomunikasi antar-tingkat atau layanan. Alat seperti Cloud Trace dapat membantu Anda mengurangi latensi yang disebabkan oleh permintaan penayangan aplikasi.
Karena Load Balancer Jaringan proxy eksternal didasarkan pada GFE, efeknya terhadap latensi sama seperti yang diamati dengan Load Balancer Aplikasi eksternal. Karena Load Balancer Aplikasi eksternal memiliki lebih banyak fitur daripada Load Balancer Jaringan proxy eksternal, sebaiknya gunakan Load Balancer Aplikasi eksternal untuk traffic HTTP(S).
Langkah berikutnya
Sebaiknya deploy aplikasi Anda di dekat sebagian besar pengguna. Untuk mengetahui informasi selengkapnya tentang berbagai opsi load balancing di Google Cloud, lihat dokumen berikut:
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Aplikasi Eksternal
- Load Balancer Jaringan proxy eksternal