Praktik terbaik Load Balancer Aplikasi Eksternal

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 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:

Mengonfigurasi ketersediaan tinggi dan failover

Untuk melindungi dari pemadaman infrastruktur regional atau global dan error konfigurasi, konfigurasikan ketersediaan tinggi dan failover multi-region menggunakan kebijakan pemilihan rute dan health check Cloud DNS:

  • Untuk Load Balancer Aplikasi eksternal global, deploy Load Balancer Aplikasi eksternal regional di beberapa region sebagai load balancer failover. Jika arsitektur Anda tidak mengandalkan load balancing backend global yang berbasis kapasitas, pilih strategi bypass global-ke-regional aktif-aktif, dengan Load Balancer Aplikasi eksternal global bertindak sebagai frontend edge di depan Load Balancer Aplikasi eksternal regional. Jika aplikasi Anda memerlukan load balancing backend global untuk mendistribusikan dan mengalihkan traffic di seluruh region berdasarkan kapasitas backend, terapkan strategi failover global-ke-regional aktif-pasif. Untuk mengetahui informasi selengkapnya, lihat Failover untuk Load Balancer Aplikasi eksternal global.
  • Untuk Load Balancer Aplikasi eksternal regional, deploy Load Balancer Aplikasi eksternal regional independen di beberapa region dan gunakan health check serta kebijakan pemilihan rute Cloud DNS untuk menerapkan failover region aktif-pasif atau pemilihan rute kedekatan aktif-aktif di seluruh region. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional.

Mengaktifkan caching 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 di-cache. Cloud CDN hanya meng-cache respons dengan konten yang dapat di-cache. Jika respons untuk suatu URL tidak di-cache, periksa header respons yang ditampilkan untuk URL tersebut, dan bagaimana 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, sebaiknya gunakan HTTP/3 yang merupakan protokol internet yang dibangun di atas IETF QUIC. HTTP/3 diaktifkan secara default di semua browser utama, Cronet Android, dan iOS. Untuk menggunakan HTTP/3 bagi aplikasi Anda, pastikan traffic UDP tidak diblokir atau dibatasi kapasitasnya di jaringan Anda dan HTTP/3 belum pernah 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. HTTPS dan HTTP/2 memerlukan beberapa overhead di awal untuk menyiapkan TLS.

Pemilihan protokol layanan backend

Pilihan protokol backend (HTTP, HTTPS, atau HTTP/2) memengaruhi latensi aplikasi dan bandwidth jaringan yang tersedia untuk aplikasi Anda. Misalnya, penggunaan HTTP/2 antara load balancer dan backend instance dapat memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP(S). Penggabungan koneksi, yaitu 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 saat transit. Dengan load balancer HTTP(S) eksternal, semua traffic yang menuju ke backend yang berada dalam jaringan VPC Google Cloud akan otomatis dienkripsi. Hal ini disebut enkripsi tingkat jaringan otomatis. Namun, enkripsi otomatis di level jaringan hanya tersedia untuk komunikasi dengan backend grup instance dan NEG zona. 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.

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, sebaiknya pilih masa aktif koneksi maksimum (misalnya, antara 10 dan 20 menit) dan/atau jumlah permintaan maksimum (misalnya, antara 1.000 dan 2.000 permintaan), setelah itu koneksi baru digunakan untuk permintaan baru. Koneksi lama akan ditutup setelah semua permintaan aktif yang menggunakannya selesai.

Hal ini memungkinkan aplikasi klien mendapatkan manfaat dari perubahan pada kumpulan backend, yang mencakup proxy load balancer dan pengoptimalan ulang jaringan yang diperlukan untuk melayani klien.

Kriteria pemilihan mode penyeimbangan

Untuk performa yang lebih baik, pertimbangkan untuk memilih grup backend untuk setiap permintaan baru berdasarkan backend yang paling responsif. Hal ini dapat dicapai dengan menggunakan mode balancing RATE. Dalam hal ini, grup backend dengan latensi rata-rata terendah pada permintaan terbaru, atau, untuk HTTP/2 dan HTTP/3, grup backend dengan permintaan yang belum terselesaikan paling sedikit, akan dipilih.

Mode load balancing UTILIZATION hanya berlaku untuk backend grup instance dan mendistribusikan traffic berdasarkan pemakaian instance VM dalam grup instance.

Mengonfigurasi afinitas sesi

Dalam beberapa kasus, mungkin akan bermanfaat jika backend yang sama menangani permintaan yang berasal dari pengguna akhir yang sama, atau terkait dengan pengguna akhir yang sama, setidaknya untuk jangka 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 ditentukan untuk seluruh resource layanan backend, dan bukan per backend. Namun, peta URL dapat mengarah ke beberapa layanan backend. Oleh karena itu, Anda tidak harus 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 dari aplikasi Anda menyajikan konten statis kepada banyak pengguna, kemungkinan besar aplikasi tersebut tidak akan mendapatkan manfaat dari afinitas sesi. Anda akan menggunakan layanan backend yang mendukung Cloud CDN untuk menyajikan respons yang di-cache.

Untuk mengetahui informasi selengkapnya, lihat afinitas sesi.