Cloud Load Balancing menyediakan mekanisme untuk mendistribusikan traffic pengguna ke beberapa instance aplikasi. Hal ini dilakukan dengan menyebarkan beban ke seluruh instance aplikasi dan memberikan performa aplikasi yang optimal kepada pengguna akhir. Halaman ini menjelaskan beberapa praktik terbaik untuk memastikan load balancer dioptimalkan untuk aplikasi Anda. Untuk memastikan performa yang optimal, sebaiknya bandingkan pola traffic aplikasi Anda.
Menempatkan backend di dekat klien
Semakin dekat pengguna atau aplikasi klien dengan workload Anda (backend load balancer), semakin rendah latensi jaringan di antara keduanya. Oleh karena itu, buat backend load balancer di region yang paling dekat dengan tempat Anda memperkirakan traffic pengguna akan tiba di frontend Google. Dalam banyak kasus, menjalankan backend di beberapa region diperlukan untuk meminimalkan latensi bagi klien di berbagai belahan dunia.
Untuk informasi selengkapnya, lihat topik berikut:
- Distribusi traffic untuk Load Balancer Aplikasi eksternal
- Praktik terbaik untuk pemilihan region Compute Engine
Mengaktifkan penyimpanan cache dengan Cloud CDN
Aktifkan Cloud CDN dan caching sebagai bagian dari konfigurasi Load Balancer Aplikasi eksternal global default Anda. Untuk mengetahui informasi selengkapnya, lihat Cloud CDN.
Saat Anda mengaktifkan Cloud CDN, mungkin perlu waktu beberapa menit sebelum respons mulai disimpan dalam cache. Cloud CDN hanya meng-cache respons dengan konten yang dapat disimpan dalam cache. Jika respons untuk URL tidak di-cache, periksa header respons yang ditampilkan untuk URL tersebut, dan cara cacheability dikonfigurasi untuk backend Anda. Untuk mengetahui detail selengkapnya, lihat pemecahan masalah Cloud CDN.
Pemilihan protokol aturan penerusan
Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, kami merekomendasikan HTTP/3 yang merupakan protokol internet yang dibuat di atas IETF QUIC. HTTP/3 diaktifkan secara default di semua browser utama, Cronet Android, dan iOS. Untuk menggunakan HTTP/3 untuk aplikasi Anda, pastikan traffic UDP tidak diblokir atau dibatasi kapasitasnya di jaringan Anda dan HTTP/3 sebelumnya tidak dinonaktifkan di Load Balancer Aplikasi eksternal global Anda. Klien yang belum mendukung HTTP/3, seperti browser lama atau library jaringan, tidak akan terpengaruh. Untuk informasi selengkapnya, lihat QUIC HTTP/3.
Untuk Load Balancer Aplikasi eksternal regional, kami mendukung HTTP/1.1, HTTPS, dan HTTP/2. HTTPS dan HTTP/2 memerlukan beberapa overhead awal untuk menyiapkan TLS.
Pemilihan protokol layanan backend
Pilihan protokol backend Anda (HTTP, HTTPS, atau HTTP/2) memengaruhi latensi aplikasi dan bandwidth jaringan yang tersedia untuk aplikasi Anda. Misalnya, menggunakan HTTP/2 antara load balancer dan instance backend dapat memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP(S). Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP(S), tidak tersedia dengan HTTP/2. Akibatnya, Anda mungkin melihat latensi backend yang tinggi karena koneksi backend dibuat lebih sering.
Protokol layanan backend juga memengaruhi cara traffic dienkripsi dalam pengiriman. Dengan load balancer HTTP(S) eksternal, semua traffic yang masuk ke backend yang berada dalam jaringan VPC Google Cloud akan otomatis dienkripsi. Hal ini disebut enkripsi tingkat jaringan otomatis. Namun, enkripsi tingkat jaringan otomatis hanya tersedia untuk komunikasi dengan grup instance dan backend NEG zonal. Untuk semua jenis backend lainnya, sebaiknya gunakan opsi protokol aman seperti HTTPS dan HTTP/2 untuk mengenkripsi komunikasi dengan layanan backend. Untuk mengetahui detailnya, lihat Enkripsi dari load balancer ke backend.
Durasi koneksi yang direkomendasikan
Kondisi jaringan berubah dan kumpulan backend dapat berubah berdasarkan beban. Untuk aplikasi yang menghasilkan banyak traffic ke satu layanan, koneksi yang berjalan lama tidak selalu merupakan penyiapan yang optimal. Daripada menggunakan satu koneksi ke backend tanpa batas waktu, sebaiknya pilih masa aktif koneksi maksimum (misalnya, antara 10 dan 20 menit) dan/atau jumlah maksimum permintaan (misalnya, antara 1.000 dan 2.000 permintaan), setelah itu koneksi baru akan digunakan untuk permintaan baru. Koneksi lama ditutup saat semua permintaan aktif yang menggunakannya selesai.
Hal ini memungkinkan aplikasi klien mendapatkan manfaat dari perubahan dalam kumpulan backend, yang mencakup proxy load balancer dan pengoptimalan ulang jaringan apa pun yang diperlukan untuk melayani klien.
Kriteria pemilihan mode balancing
Untuk performa yang lebih baik, pertimbangkan untuk memilih grup backend untuk setiap permintaan baru
berdasarkan backend yang paling responsif. Hal ini dapat dilakukan menggunakan
mode balancing RATE. Dalam hal ini, grup backend dengan latensi rata-rata
terendah selama permintaan terbaru, atau, untuk HTTP/2 dan HTTP/3, grup backend dengan
permintaan yang belum terselesaikan paling sedikit, akan dipilih.
Mode balancing UTILIZATION hanya berlaku untuk backend grup instance dan
mendistribusikan traffic berdasarkan penggunaan instance VM dalam grup
instance.
Mengonfigurasi afinitas sesi
Dalam beberapa kasus, mungkin akan lebih baik jika backend yang sama menangani permintaan yang berasal dari pengguna akhir yang sama, atau terkait dengan pengguna akhir yang sama, setidaknya selama jangka waktu yang singkat. Hal ini dapat dikonfigurasi menggunakan afinitas sesi, yaitu setelan yang dikonfigurasi di layanan backend. Afinitas sesi mengontrol distribusi koneksi baru dari klien ke backend load balancer. Anda dapat menggunakan afinitas sesi untuk memastikan bahwa backend yang sama menangani permintaan dari resource yang sama, misalnya, yang terkait dengan akun pengguna yang sama atau dari dokumen yang sama.
Afinitas sesi ditentukan untuk seluruh resource layanan backend, dan bukan berdasarkan backend. Namun, peta URL dapat mengarah ke beberapa layanan backend. Oleh karena itu, Anda tidak perlu menggunakan hanya satu jenis afinitas sesi untuk load balancer. Bergantung pada aplikasi, Anda dapat menggunakan layanan backend yang berbeda dengan setelan afinitas sesi yang berbeda. Misalnya, jika bagian aplikasi Anda menayangkan konten statis kepada banyak pengguna, bagian tersebut tidak akan mendapatkan manfaat dari afinitas sesi. Sebagai gantinya, Anda akan menggunakan layanan backend yang mendukung Cloud CDN untuk menayangkan respons yang di-cache.
Untuk mengetahui informasi selengkapnya, lihat afinitas sesi.