Opsi untuk load balancing
Bergantung pada jenis traffic yang dikirim ke aplikasi Anda, Anda memiliki beberapa opsi untuk load balancing eksternal. Tabel berikut merangkum opsi Anda:
| Opsi | Deskripsi | Alur traffic | Cakupan |
|---|---|---|---|
| Load Balancer Aplikasi Eksternal | Mendukung traffic HTTP(S) dan fitur lanjutan, seperti pemetaan URL
dan pelepasan SSL Gunakan Load Balancer Jaringan 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 | Mengizinkan 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 menghadap pengguna, keduanya tidak tercakup dalam 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 jangkauan 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). Kirim perintah
curlberulang kali ke server.
Saat membandingkan hasil, perlu diketahui bahwa latensi pada link serat optik dibatasi oleh jarak dan kecepatan cahaya dalam serat optik, 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), kira-kira 7.500 km. Dengan serat optik langsung antara
lokasi, latensi pulang-pergi adalah sebagai berikut:
7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)
Kabel serat optik tidak mengikuti jalur lurus antara pengguna dan pusat data. Cahaya pada kabel serat optik melewati peralatan aktif dan pasif di sepanjang jalurnya. Latensi yang diamati sekitar 1,5 kali lipat dari latensi 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 region us-central1, dan pengguna didistribusikan di seluruh dunia. Latensi yang diamati pengguna di Jerman dalam skenario ini menggambarkan apa yang mungkin dialami 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 Paket 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 |
|---|---|---|
| Ping 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 500 permintaan pertama berikut:
Saat melakukan ping ke alamat IP VM, respons akan langsung berasal 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 dalam 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 (dalam Paket Premium). Di region tempat VM project berada, traffic mengalir terlebih dahulu melalui Load Balancer Jaringan passthrough eksternal. Kemudian, permintaan 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 memproses IP load balancer dan menerima traffic tanpa diubah.
Tabel berikut menunjukkan hasil saat pengguna di Jerman menguji latensi untuk opsi network-load-balancing.
| Metode | Hasil | Latensi minimum |
|---|---|---|
| Ping 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 terjadi dalam region dan traffic hanya diteruskan, tidak ada dampak latensi yang signifikan dibandingkan dengan tidak memiliki load balancer.
Load balancing eksternal
Dengan Load Balancer Aplikasi eksternal, GFE mem-proxy traffic. GFE ini berada di edge jaringan global Google. GFE menghentikan sesi TCP dan terhubung ke backend di region terdekat yang dapat melayani traffic.
Tabel berikut menunjukkan hasil saat pengguna di Jerman menguji latensi untuk opsi load balancing HTTP.
| Metode | Hasil | Latensi minimum |
|---|---|---|
| Ping 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
melakukan ping ke Load Balancer Aplikasi eksternal, latensi pulang pergi sedikit di atas
1 md. Hasil ini menunjukkan latensi ke GFE terdekat, yang berada di
kota yang sama dengan pengguna. Hasil ini tidak mencerminkan latensi sebenarnya yang dialami 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 dalam grafik berikut:
Dua perjalanan pulang pergi antara klien dan VM membutuhkan waktu lebih dari 123 md bahkan dengan serat optik langsung. Latensinya lebih rendah karena GFE memproksi 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 traffic mencapai setiap pasangan backend GFE untuk pertama kalinya. 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 berfungsi baik melayani pengguna di region tertentu, GFE di region tersebut mempertahankan koneksi persisten yang terbuka ke semua backend yang melayani. Oleh karena itu, pengguna di region tersebut akan merasakan latensi yang lebih rendah pada permintaan HTTP pertama mereka jika pengguna berada jauh dari backend aplikasi. Jika pengguna berada di dekat backend aplikasi, pengguna tidak akan melihat peningkatan latensi.
Untuk permintaan berikutnya, seperti mengklik link halaman, tidak ada peningkatan latensi karena browser modern mempertahankan koneksi persisten ke layanan. Hal 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 kompleks dibandingkan dengan Load Balancer Jaringan passthrough eksternal karena lebih sedikit perjalanan pulang pergi 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 1911 md. Dengan Load Balancer Aplikasi eksternal, latensi rata-ratanya adalah 1341 md. Hal ini menghemat sekitar 5 perjalanan pulang pergi 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 perjalanan pulang pergi tambahan). Hal ini karena Load Balancer Aplikasi eksternal menggunakan pelepasan 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 dengan 525 md menggunakan HTTP(S) melalui Load Balancer Jaringan passthrough eksternal.
Load Balancer Aplikasi eksternal memungkinkan upgrade otomatis sesi yang menghadap pengguna ke HTTP/2. HTTP/2 dapat mengurangi jumlah paket yang diperlukan, dengan menggunakan peningkatan dalam protokol biner, kompresi header, dan multiplexing koneksi. Peningkatan ini dapat mengurangi latensi yang diamati lebih banyak daripada 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 lanjut dari 201 md menjadi 145 md saat menggunakan HTTP/2, bukan HTTPS.
Mengoptimalkan Load Balancer Aplikasi eksternal
Anda dapat mengoptimalkan latensi untuk aplikasi dengan menggunakan Load Balancer Aplikasi eksternal sebagai berikut:
Jika sebagian traffic yang Anda sajikan dapat di-cache, Anda dapat berintegrasi dengan Cloud CDN. Cloud CDN mengurangi latensi dengan menyajikan 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 mana pun dengan Google Cloud. Dengan menggunakan salah satu partner CDN InterconnectGoogle, Anda akan mendapatkan manfaat dari biaya transfer data yang didiskon.
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, desainlah aplikasi tersebut untuk mengurangi jumlah perjalanan pulang pergi antar-region.
Untuk mengurangi latensi di dalam aplikasi, periksa panggilan prosedur jarak jauh (RPC) yang berkomunikasi antar-VM. Latensi ini biasanya terjadi saat aplikasi berkomunikasi antar-tingkatan 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, efek pada latensi sama dengan yang diamati pada 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 Anda. 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