Cloud Load Balancing menyediakan mekanisme untuk mendistribusikan traffic pengguna ke beberapa instance aplikasi. Mereka melakukannya 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 gunakan benchmark pola traffic aplikasi Anda.
Menempatkan backend di dekat klien
Semakin dekat aplikasi pengguna atau 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 mengantisipasi traffic pengguna tiba di Google Front End. Dalam banyak kasus, menjalankan backend di beberapa region diperlukan untuk meminimalkan latensi ke 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 cache 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 di-cache. Cloud CDN hanya menyimpan respons dengan konten yang dapat disimpan dalam cache. Jika respons untuk URL tidak di-cache, periksa header respons mana yang ditampilkan untuk URL tersebut, dan bagaimana kemampuan cache dikonfigurasi untuk backend Anda. Untuk mengetahui detail selengkapnya, lihat pemecahan masalah Cloud CDN.
Pilihan protokol aturan penerusan
Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, sebaiknya gunakan HTTP/3 yang merupakan protokol internet yang dibuat berdasarkan IETF QUIC. HTTP/3 diaktifkan secara default di semua browser utama, Android Cronet, 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 atau library jaringan lama, tidak akan terpengaruh. Untuk mengetahui informasi selengkapnya, lihat HTTP/3 QUIC.
Untuk Load Balancer Aplikasi eksternal regional, kami mendukung HTTP/1.1, HTTPS, dan HTTP/2. Baik HTTPS maupun HTTP/2 memerlukan beberapa overhead di 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 lebih banyak koneksi TCP ke instance daripada HTTP(S). Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP(S), saat ini 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 saat transit. Dengan load balancer HTTP(S) eksternal, semua traffic yang menuju ke backend yang berada dalam jaringan VPC Google Cloud otomatis dienkripsi. Enkripsi ini disebut enkripsi tingkat jaringan otomatis. Namun, enkripsi tingkat jaringan otomatis hanya tersedia untuk komunikasi dengan grup instance dan backend NEG zona. Untuk semua jenis backend lainnya, Google Cloud merekomendasikan agar Anda menggunakan opsi protokol yang 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 mungkin 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 hingga 20 menit) dan/atau jumlah maksimum permintaan (misalnya, antara 1.000 hingga 2.000 permintaan), setelah itu koneksi baru akan digunakan untuk permintaan baru. Koneksi lama ditutup ketika semua permintaan aktif yang menggunakannya selesai.
Hal ini memungkinkan aplikasi klien mendapatkan manfaat dari perubahan di 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 mana yang paling responsif. Hal ini dapat dilakukan menggunakan
mode penyeimbangan RATE. Dalam hal ini, grup backend dengan latensi rata-rata terendah
daripada permintaan terbaru, atau, untuk HTTP/2 dan HTTP/3, grup backend dengan
permintaan yang paling sedikit, akan dipilih.
Mode penyeimbangan UTILIZATION hanya berlaku untuk backend grup instance dan mendistribusikan traffic berdasarkan penggunaan instance VM dalam grup instance.
Mengonfigurasi afinitas sesi
Dalam beberapa kasus, backend yang sama mungkin bermanfaat untuk menangani permintaan yang berasal dari pengguna akhir yang sama, atau terkait dengan pengguna akhir yang sama, setidaknya untuk periode waktu yang singkat. Hal ini dapat dikonfigurasi menggunakan afinitas sesi, setelan yang dikonfigurasi pada 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, terkait dengan akun pengguna yang sama atau dari dokumen yang sama.
Afinitas sesi ditetapkan untuk seluruh resource layanan backend, bukan per 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 yang digunakan, Anda dapat menggunakan layanan backend yang berbeda dengan setelan afinitas sesi yang berbeda. Misalnya, jika ada bagian dari aplikasi Anda yang menayangkan konten statis kepada banyak pengguna, afinitas sesi kemungkinan tidak akan mendapatkan manfaat. Sebagai gantinya, Anda harus menggunakan layanan backend berkemampuan Cloud CDN untuk menampilkan respons yang di-cache.
Untuk mengetahui informasi selengkapnya, lihat afinitas sesi.