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 pembongkaran 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-kan ke backend. | Global |
| Load Balancer Jaringan passthrough eksternal | Mengizinkan traffic TCP/UDP yang menggunakan port apa pun untuk melewati load balancer. | Dikirimkan menggunakan teknologi Maglev Google untuk mendistribusikan traffic ke backend. | Regional |
Karena load balancer internal dan Traffic Director tidak mendukung traffic yang ditampilkan kepada pengguna, keduanya berada di luar cakupan artikel ini.
Pengukuran artikel ini menggunakan Paket Premium di Tingkat Layanan Jaringan 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, baca 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 sambungan fiber dibatasi oleh jarak dan kecepatan cahaya dalam fiber, yang sekitar 200.000 km per detik (atau 124.724 mil per detik).
Jarak antara Frankfurt, Jerman dan Council Bluffs, Iowa (wilayah us-central1), sekitar 7.500 km. Dengan fiber lurus di antara lokasi, latensi bolak-balik 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 fiber melewati perangkat aktif dan pasif di sepanjang jalurnya. Latensi yang diamati sekitar 1,5 kali lipat ideal, atau 112,5 md, menunjukkan konfigurasi yang mendekati 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
dari server web HTTP. Karena aplikasi ini 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 oleh 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 Tingkat Standar, traffic pengguna memasuki jaringan Google di PoP yang dekat dengan region tujuan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Tingkat Layanan Jaringan.
Tabel berikut menampilkan 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 pada grafik 500 permintaan pertama berikut:
Saat melakukan ping pada alamat IP VM, respons akan langsung berasal dari server web. Waktu respons dari server web lebih rendah dibandingkan dengan latensi jaringan (TTFB). Ini karena koneksi TCP baru dibuka untuk setiap permintaan HTTP. Tiga fase berjabatan awal diperlukan sebelum respons HTTP dikirim, seperti yang ditunjukkan pada diagram berikut. Oleh karena itu, latensi yang diamati mendekati dua kali lipat latensi ping.
Load Balancer Jaringan passthrough eksternal
Dengan Load Balancer Jaringan passthrough eksternal, permintaan pengguna masih 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 ini diteruskan tanpa perubahan pada 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, serta protokol. VM memproses IP load balancer dan menerima traffic tanpa diubah.
Tabel berikut menunjukkan hasil saat pengguna di Jerman menguji latensi untuk opsi load balancing jaringan.
| Metode | Hasil | Latensi minimum |
|---|---|---|
| Melakukan ping pada 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 berlangsung di dalam suatu region dan traffic hanya diteruskan, tidak ada dampak latensi yang signifikan dibandingkan dengan tanpa load balancing.
External load balancing
Dengan Load Balancer Aplikasi eksternal, traffic proxy GFE. 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 |
|---|---|---|
| Melakukan ping pada 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 bolak-balik sedikit lebih dari 1 md. Hasil ini mewakili latensi ke GFE terdekat, yang terletak 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 menggunakan protokol (ICMP) yang berbeda dengan
protokol komunikasi aplikasi (HTTP) Anda dapat menyesatkan.
Saat mengukur TTFB, permintaan awal menampilkan latensi respons yang serupa. Beberapa permintaan mencapai latensi minimum yang lebih rendah, yaitu 123 milidetik, seperti ditunjukkan dalam grafik berikut:
Dua perjalanan bolak-balik antara klien dan VM memerlukan waktu lebih dari 123 milidetik, bahkan dengan fiber lurus. Latensi lebih rendah karena GFE mem-proxy traffic. GFE mempertahankan koneksi persisten ke VM backend. Oleh karena itu, hanya permintaan pertama dari GFE tertentu ke backend tertentu yang memerlukan berjabatan tiga arah.
Setiap lokasi memiliki beberapa GFE. Grafik latensi menunjukkan beberapa lonjakan yang berfluktuasi saat traffic pertama kali mencapai setiap pasangan backend GFE. Kemudian, GFE 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 |
Jika aplikasi yang sehat melayani pengguna di region tertentu, GFE di region tersebut akan mempertahankan koneksi persisten yang terbuka ke semua backend penayangan. Oleh karena itu, pengguna di region tersebut mengalami penurunan latensi 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. 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 lebih sedikit latensi untuk aset kompleks daripada Load Balancer Jaringan passthrough eksternal karena lebih sedikit round-trip yang diperlukan sebelum respons selesai. Misalnya, ketika 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 1.341 md. Hal ini menghemat sekitar 5 perjalanan bolak-balik per permintaan. Koneksi persisten antara GFE dan backend yang aktif 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 SSL offload, dan hanya latensi ke PoP edge yang relevan. Bagi pengguna di Jerman, latensi minimum yang diamati adalah 201 md menggunakan Load Balancer Aplikasi eksternal, dibandingkan 525 md yang 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 lebih dari yang diamati dengan beralih ke Load Balancer Aplikasi eksternal. HTTP/2 didukung oleh browser saat ini yang menggunakan SSL/TLS. Bagi 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 menggunakan Load Balancer Aplikasi eksternal sebagai berikut:
Jika beberapa traffic yang Anda salurkan dapat di-cache, Anda dapat berintegrasi dengan Cloud CDN. Cloud CDN mengurangi latensi dengan menyalurkan aset 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 mendapatkan manfaat dari diskon biaya transfer data.
Jika konten bersifat statis, Anda dapat mengurangi beban di server web dengan menyajikan 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 Anda dapat mengurangi latensi karena load balancer secara otomatis mengarahkan pengguna ke region terdekat. Namun, jika aplikasi Anda terpusat sebagian, desain aplikasi tersebut untuk mengurangi jumlah perjalanan bolak-balik antar-regional.
Untuk mengurangi latensi di dalam aplikasi Anda, periksa semua panggilan prosedur jarak jauh (RPC) yang berkomunikasi antar-VM. Latensi ini biasanya terjadi saat aplikasi berkomunikasi antartingkat atau layanan. Alat seperti Cloud Trace dapat membantu Anda mengurangi latensi yang disebabkan oleh permintaan layanan 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 dekat dengan 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