Sebagian besar load balancer menggunakan pendekatan hashing berbasis round-robin atau alur untuk mendistribusikan traffic. Namun, load balancer yang menggunakan pendekatan ini mungkin mengalami kesulitan dalam beradaptasi saat permintaan melonjak melebihi kapasitas penayangan yang tersedia. Artikel ini menjelaskan bagaimana penggunaan Cloud Load Balancing dapat mengatasi masalah ini dan mengoptimalkan kapasitas aplikasi global Anda. Hal ini sering kali menghasilkan pengalaman pengguna yang lebih baik dan biaya yang lebih rendah dibandingkan penerapan load balancing tradisional.
Artikel ini adalah bagian dari rangkaian praktik terbaik yang berfokus pada produk Cloud Load Balancing Google. Untuk tutorial yang menyertai artikel ini, lihat Pengelolaan Kapasitas dengan Load Balancing. Untuk mempelajari latensi lebih dalam, lihat Mengoptimalkan Latensi Aplikasi dengan Load Balancing.
Tantangan kapasitas dalam aplikasi global
Penskalaan aplikasi global dapat menjadi tantangan, terutama jika Anda memiliki anggaran IT yang terbatas serta workload yang tidak dapat diprediksi dan sangat penuh. Di lingkungan cloud publik seperti Google Cloud, fleksibilitas yang disediakan oleh fitur seperti penskalaan otomatis dan load balancing dapat membantu. Namun, penskala otomatis memiliki beberapa batasan, seperti yang dijelaskan di bagian ini.
Latensi dalam memulai instance baru
Masalah paling umum pada penskalaan otomatis adalah aplikasi yang diminta belum siap menyalurkan traffic Anda dengan cukup cepat. Bergantung pada image instance VM Anda, skrip biasanya harus dijalankan dan informasi dimuat sebelum instance VM siap. Biasanya perlu waktu beberapa menit sebelum load balancing dapat mengarahkan pengguna ke instance VM baru. Selama waktu tersebut, traffic didistribusikan ke instance VM yang ada, yang mungkin sudah melebihi kapasitas.
Aplikasi dibatasi oleh kapasitas backend
Beberapa aplikasi tidak dapat diskalakan otomatis sama sekali. Misalnya, database sering kali memiliki kapasitas backend yang terbatas. Hanya sejumlah frontend yang dapat mengakses database yang tidak diskalakan secara horizontal. Jika aplikasi Anda mengandalkan API eksternal yang hanya mendukung jumlah terbatas permintaan per detik, aplikasi juga tidak dapat diskalakan secara otomatis.
Lisensi tidak elastis
Saat menggunakan software berlisensi, lisensi Anda sering kali membatasi Anda pada kapasitas maksimum yang telah ditetapkan sebelumnya. Oleh karena itu, kemampuan Anda untuk melakukan penskalaan otomatis mungkin dibatasi karena Anda tidak dapat menambahkan lisensi dengan cepat.
Kapasitas instance VM terlalu sedikit
Untuk memperhitungkan burst traffic yang tiba-tiba, penskala otomatis harus menyertakan headroom yang cukup (misalnya, penskalaan otomatis dipicu saat mencapai 70% dari kapasitas CPU). Untuk menghemat biaya, Anda mungkin tergoda untuk menetapkan target ini lebih tinggi, seperti 90% kapasitas CPU. Namun, nilai pemicu yang lebih tinggi dapat menyebabkan bottleneck penskalaan saat dihadapkan dengan burst traffic, seperti kampanye iklan yang tiba-tiba meningkatkan permintaan. Anda perlu menyeimbangkan ukuran kapasitas berdasarkan lonjakan traffic dan waktu yang diperlukan untuk menyiapkan instance VM baru.
Kuota regional
Jika terjadi burst yang tidak terduga di suatu region, kuota resource yang ada mungkin membatasi jumlah instance yang dapat diskalakan hingga di bawah level yang diperlukan untuk mendukung burst saat ini. Proses peningkatan kuota resource dapat memerlukan waktu beberapa jam atau hari.
Mengatasi tantangan ini dengan load balancing global
Load Balancer Aplikasi eksternal dan Load Balancer Jaringan proxy eksternal adalah produk load balancing global yang di-proxy-kan melalui server Google Front End (GFE) yang disinkronkan secara global, sehingga memudahkan penanggulangan jenis tantangan load balancing ini. Produk-produk ini menawarkan solusi untuk mengatasi tantangan tersebut karena traffic didistribusikan ke backend secara berbeda dibandingkan di sebagian besar solusi load balancing regional.
Perbedaan tersebut dijelaskan di bagian berikut.
Algoritma yang digunakan oleh load balancer lain
Sebagian besar load balancer menggunakan algoritma yang sama untuk mendistribusikan traffic antar-backend:
- Round-robin. Paket didistribusikan secara merata di antara semua backend, terlepas dari sumber dan tujuan paket.
- Hashing. Alur paket diidentifikasi berdasarkan hash informasi traffic, termasuk IP sumber, IP tujuan, port, dan protokol. Semua traffic yang menghasilkan nilai hash yang sama akan mengalir ke backend yang sama.
Load balancing hashing adalah algoritma yang saat ini tersedia untuk Load Balancer Jaringan passthrough eksternal. Load balancer ini mendukung hashing 2 tuple (berdasarkan IP sumber dan tujuan), hashing 3 tuple (berdasarkan IP sumber, IP tujuan, dan protokol), serta hashing 5 tuple (berdasarkan IP sumber, IP tujuan, port sumber, port tujuan, dan protokol).
Dengan kedua algoritma ini, instance yang tidak responsif akan dikeluarkan dari distribusi. Namun, beban saat ini pada backend jarang menjadi faktor dalam distribusi beban.
Beberapa load balancer hardware atau software menggunakan algoritma yang meneruskan traffic berdasarkan metrik lain, seperti round-robin berbobot, beban terendah, waktu respons tercepat, atau jumlah koneksi aktif. Namun, jika beban meningkat melebihi tingkat yang diharapkan karena burst traffic tiba-tiba, traffic masih didistribusikan ke instance backend yang melebihi kapasitas, sehingga menyebabkan peningkatan latensi secara drastis.
Beberapa load balancer mengizinkan aturan lanjutan saat traffic yang melebihi kapasitas backend diteruskan ke kumpulan lain atau dialihkan ke situs statis. Hal ini memungkinkan Anda untuk menolak traffic ini secara efektif dan mengirim pesan "layanan tidak tersedia, coba lagi nanti". Beberapa load balancer memberi Anda opsi untuk memasukkan permintaan ke dalam antrean.
Solusi load balancing global sering diimplementasikan dengan algoritma berbasis DNS, yang melayani IP load balancing regional yang berbeda berdasarkan lokasi pengguna dan beban backend. Solusi ini menawarkan failover ke region lain untuk semua atau sebagian traffic untuk deployment regional. Namun, pada solusi berbasis DNS apa pun, failover biasanya memerlukan waktu beberapa menit, bergantung pada nilai time to live (TTL) entri DNS. Secara umum, sejumlah kecil traffic akan terus diarahkan ke server lama setelah masa berlaku TTL berakhir di mana saja. Oleh karena itu, load balancing global berbasis DNS bukanlah solusi optimal untuk menangani traffic dalam skenario burst.
Cara kerja Load Balancer Aplikasi eksternal
Load Balancer Aplikasi eksternal menggunakan pendekatan yang berbeda. Traffic di-proxy-kan melalui server GFE yang di-deploy di sebagian besar lokasi edge jaringan global Google. Saat ini, organisasi ini memiliki lebih dari 80 lokasi di seluruh dunia. Algoritma load balancing diterapkan di server GFE.
Load Balancer Aplikasi eksternal tersedia melalui satu alamat IP stabil yang diumumkan secara global di edge node, dan koneksi dihentikan oleh salah satu GFE.
GFE saling terhubung melalui jaringan global Google. Data yang mendeskripsikan backend yang tersedia dan kapasitas penayangan yang tersedia untuk setiap resource yang di-load balanced akan terus didistribusikan ke semua GFE menggunakan bidang kontrol global.
Traffic ke alamat IP yang di-load balanced di-proxy-kan ke backend instance yang ditentukan dalam konfigurasi Load Balancer Aplikasi eksternal menggunakan algoritma load balancing khusus yang disebut Waterfall berdasarkan Wilayah. Algoritma ini menentukan backend yang optimal untuk melayani permintaan dengan memperhitungkan kedekatan instance dengan pengguna, beban yang masuk, serta kapasitas backend yang tersedia di setiap zona dan region. Terakhir, beban dan kapasitas seluruh dunia juga diperhitungkan.
Load Balancer Aplikasi eksternal mendistribusikan traffic berdasarkan instance yang tersedia. Untuk menambahkan instance baru berdasarkan beban, algoritme bekerja sama dengan grup instance penskalaan otomatis.
Arus traffic dalam suatu wilayah
Dalam keadaan normal, semua traffic dikirim ke region yang paling dekat dengan pengguna. Selanjutnya, load balancing dijalankan sesuai dengan panduan berikut:
Dalam setiap region, traffic didistribusikan ke seluruh grup instance, yang dapat berada di beberapa zona sesuai dengan kapasitas setiap grup.
Jika kapasitas tidak setara di antara zona, zona dimuat secara proporsional dengan kapasitas penyaluran yang tersedia.
Dalam zona, permintaan didistribusikan secara merata di seluruh instance di setiap grup instance.
Sesi akan dipertahankan berdasarkan alamat IP klien atau nilai cookie, bergantung pada setelan afinitas sesi.
Kecuali jika backend menjadi tidak tersedia, koneksi TCP yang ada tidak akan pernah dipindahkan ke backend lain.
Diagram berikut menunjukkan distribusi beban dalam kasus ini, dengan setiap region berada dalam kapasitas dan dapat menangani beban dari pengguna yang paling dekat dengan region tersebut.
Traffic tambahan ke wilayah lain
Jika seluruh region mencapai kapasitas yang ditentukan oleh kapasitas penayangan yang ditetapkan dalam layanan backend, algoritme Waterfall menurut Region akan dipicu, dan traffic akan mengalir ke region terdekat yang memiliki kapasitas tersedia. Saat setiap region mencapai kapasitas, traffic akan berpindah ke region terdekat berikutnya, dan seterusnya. Kedekatan region dengan pengguna ditentukan oleh waktu round-trip jaringan dari GFE ke backend instance.
Diagram berikut menunjukkan tambahan ke region terdekat berikutnya jika satu region menerima lebih banyak traffic daripada yang dapat ditangani secara regional.
Overflow lintas regional karena backend yang tidak responsif
Jika health check mendapati bahwa lebih dari separuh backend di suatu region tidak responsif, GFE akan meneruskan beberapa traffic ke region terdekat berikutnya secara preemptive. Hal ini dilakukan untuk menghindari traffic benar-benar gagal karena region menjadi tidak sehat. Overflow ini terjadi meskipun sisa kapasitas di region dengan backend yang tidak responsif sudah cukup.
Diagram berikut menunjukkan mekanisme overflow yang berlaku karena sebagian besar backend di satu zona tidak responsif.
Semua region melebihi kapasitas
Jika traffic ke semua region berada pada atau di atas kapasitasnya, traffic akan diseimbangkan sehingga setiap region berada pada tingkat overflow relatif yang sama dibandingkan dengan kapasitasnya. Misalnya, jika permintaan global melebihi kapasitas global sebesar 20%, traffic akan didistribusikan sedemikian rupa sehingga semua region menerima permintaan sebesar 20% dari kapasitas regional mereka, sambil mempertahankan traffic selokal mungkin.
Diagram berikut menunjukkan aturan tambahan global ini yang berlaku. Dalam hal ini, satu region menerima begitu banyak traffic sehingga tidak dapat didistribusikan sama sekali dengan kapasitas penayangan yang tersedia secara global.
Overflow sementara selama penskalaan otomatis
Penskalaan otomatis didasarkan pada batas kapasitas yang dikonfigurasi pada setiap layanan backend dan memunculkan instance baru saat traffic mendekati batas kapasitas yang dikonfigurasi. Bergantung pada seberapa cepat level permintaan meningkat dan seberapa cepat instance baru terhubung ke internet, overflow ke region lain mungkin tidak diperlukan. Dalam kasus lain, overflow dapat bertindak sebagai buffering sementara hingga instance lokal baru online dan siap untuk menyalurkan traffic langsung. Jika kapasitas yang diperluas dengan penskalaan otomatis sudah memadai, semua sesi baru akan didistribusikan ke region terdekat.
Efek latensi dari overflow
Menurut algoritme Waterfall by Region, kelebihan beberapa traffic oleh Load Balancer Aplikasi eksternal ke region lain dapat terjadi. Namun, sesi TCP dan traffic SSL tetap dihentikan oleh GFE yang terdekat dengan pengguna. Hal ini bermanfaat bagi latensi aplikasi. Untuk mengetahui detailnya, lihat Mengoptimalkan Latensi Aplikasi dengan Load Balancing.
Langsung: Mengukur efek pengelolaan kapasitas
Untuk memahami cara overflow terjadi dan cara mengelolanya menggunakan load balancer HTTP, lihat tutorial Pengelolaan Kapasitas dengan Load Balancing yang menyertai artikel ini.
Menggunakan Load Balancer Aplikasi eksternal untuk mengatasi tantangan kapasitas
Untuk membantu mengatasi tantangan yang dibahas sebelumnya, Load Balancer Aplikasi eksternal dan Load Balancer Jaringan proxy eksternal dapat menambahkan kapasitas ke region lain. Untuk aplikasi global, merespons pengguna dengan latensi keseluruhan yang sedikit lebih tinggi akan menghasilkan pengalaman yang lebih baik daripada menggunakan backend regional. Aplikasi yang menggunakan backend regional memiliki latensi yang lebih rendah secara nominal, tetapi dapat menjadi kelebihan beban.
Mari kita tinjau kembali cara Load Balancer Aplikasi eksternal dapat membantu mengatasi skenario yang disebutkan di awal artikel:
Latensi dalam memulai instance baru. Jika penskala otomatis tidak dapat menambahkan kapasitas cukup cepat selama burst traffic lokal, Load Balancer Aplikasi eksternal akan menambahkan koneksi ke region terdekat berikutnya untuk sementara. Hal ini memastikan bahwa sesi pengguna yang ada di region asli ditangani dengan kecepatan optimal karena tetap berada di backend yang ada, sementara sesi pengguna baru hanya mengalami sedikit penurunan latensi. Segera setelah instance backend tambahan ditingkatkan skalanya di region asli, traffic baru akan dirutekan kembali ke region yang paling dekat dengan pengguna.
Aplikasi dibatasi oleh kapasitas backend. Aplikasi yang tidak dapat diskalakan otomatis, tetapi tersedia di beberapa region masih dapat ditambahkan ke region terdekat berikutnya jika permintaan di satu region melebihi kapasitas yang di-deploy untuk kebutuhan traffic biasa.
Lisensi non-elastis. Jika jumlah lisensi software terbatas, dan jika kumpulan lisensi di region saat ini telah habis, Load Balancer Aplikasi eksternal dapat memindahkan traffic ke region tempat lisensi tersedia. Agar hal ini berfungsi, jumlah maksimum instance ditetapkan ke jumlah maksimum lisensi di penskalaan otomatis.
Kapasitas VM terlalu sedikit. Kemungkinan overflow regional akan membantu menghemat biaya, karena Anda dapat menyiapkan penskalaan otomatis dengan pemicu penggunaan CPU yang tinggi. Anda juga dapat mengonfigurasi kapasitas backend yang tersedia di bawah setiap puncak regional, karena overflow ke region lain memastikan bahwa kapasitas global akan selalu memadai.
Kuota regional. Jika kuota resource Compute Engine tidak sesuai dengan permintaan, overflow Load Balancer Aplikasi eksternal akan otomatis mengalihkan sebagian traffic ke region yang masih dapat diskalakan sesuai kuota regionalnya.
Langkah selanjutnya
Halaman berikut memberikan informasi dan latar belakang selengkapnya tentang opsi load balancing Google:
- Tutorial Pengelolaan Kapasitas dengan Load Balancing
- Mengoptimalkan Latensi Aplikasi dengan Load Balancing
- Codelab Networking 101
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Aplikasi Eksternal
- Load Balancer Jaringan proxy eksternal