Sebagian besar load balancer menggunakan pendekatan hashing berbasis aliran atau round-robin untuk mendistribusikan traffic. Namun, load balancer yang menggunakan pendekatan ini dapat mengalami kesulitan beradaptasi saat permintaan melonjak melampaui kapasitas penayangan yang tersedia. Artikel ini menjelaskan cara 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 dengan 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 mengetahui pembahasan mendalam tentang latensi, lihat Mengoptimalkan Latensi Aplikasi dengan Load Balancing.
Tantangan kapasitas dalam aplikasi global
Menskalakan aplikasi global bisa menjadi tantangan, terutama jika Anda memiliki anggaran IT terbatas dan beban kerja yang tidak dapat diprediksi dan bergejolak. 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 tidak siap menayangkan traffic Anda dengan cukup cepat. Bergantung pada image instance VM, 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 yang dibatasi oleh kapasitas backend
Beberapa aplikasi tidak dapat diskalakan otomatis sama sekali. Misalnya, database sering kali memiliki kapasitas backend yang terbatas. Hanya sejumlah frontend tertentu yang dapat mengakses database yang tidak diskalakan secara horizontal. Jika aplikasi Anda mengandalkan API eksternal yang hanya mendukung sejumlah kecil permintaan per detik, aplikasi juga tidak dapat diskalakan otomatis.
Lisensi non-elastis
Saat Anda menggunakan software berlisensi, lisensi Anda sering kali membatasi Anda pada kapasitas maksimum yang telah ditetapkan. Oleh karena itu, kemampuan penskalaan otomatis Anda mungkin dibatasi karena Anda tidak dapat menambahkan lisensi secara langsung.
Ruang kosong instance VM terlalu kecil
Untuk memperhitungkan lonjakan traffic yang tiba-tiba, penskala otomatis harus menyertakan ruang kosong yang memadai (misalnya, penskala otomatis dipicu pada 70% 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 hambatan penskalaan saat menghadapi lonjakan traffic, seperti kampanye iklan yang tiba-tiba meningkatkan permintaan. Anda perlu menyeimbangkan ukuran ruang kosong berdasarkan seberapa sering traffic Anda mengalami lonjakan dan berapa lama waktu yang dibutuhkan instance VM baru Anda untuk siap.
Kuota regional
Jika Anda mengalami lonjakan yang tidak terduga di suatu region, kuota resource yang ada mungkin membatasi jumlah instance yang dapat Anda skalakan di bawah tingkat yang diperlukan untuk mendukung lonjakan saat ini. Pemrosesan peningkatan kuota resource Anda 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 melalui server Front End (GFE) Google yang disinkronkan secara global, sehingga mempermudah mitigasi jenis tantangan load balancing ini. Produk ini menawarkan solusi untuk tantangan tersebut karena traffic didistribusikan ke backend secara berbeda daripada di sebagian besar solusi load balancing regional.
Perbedaan ini dijelaskan di bagian berikut.
Algoritma yang digunakan oleh load balancer lain
Sebagian besar load balancer menggunakan algoritma yang sama untuk mendistribusikan traffic di antara backend:
- Round-robin. Paket didistribusikan secara merata di antara semua backend terlepas dari sumber dan tujuan paket.
- Hashing. Aliran 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 sehat 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 di atas tingkat yang diharapkan karena burst traffic yang tiba-tiba, traffic tetap didistribusikan ke instance backend yang kelebihan kapasitas, sehingga menyebabkan peningkatan latensi yang drastis.
Beberapa load balancer memungkinkan aturan lanjutan yang mengarahkan traffic yang melebihi kapasitas backend ke pool lain atau mengalihkan traffic ke situs statis. Dengan demikian, Anda dapat menolak traffic ini secara efektif dan mengirim pesan "layanan tidak tersedia, coba lagi nanti". Beberapa load balancer memberi Anda opsi untuk menempatkan permintaan dalam antrean.
Solusi load balancing global sering kali diimplementasikan dengan algoritma berbasis DNS, yang menayangkan 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, 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 TTL seharusnya berakhir di mana pun. Oleh karena itu, load balancing global berbasis DNS bukanlah solusi optimal untuk menangani traffic dalam skenario lonjakan.
Cara kerja Load Balancer Aplikasi eksternal
Load Balancer Aplikasi eksternal menggunakan pendekatan yang berbeda. Traffic di-proxy melalui server GFE yang di-deploy di sebagian besar lokasi edge jaringan global Google. Saat ini, ada 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 node edge, dan koneksi dihentikan oleh GFE mana pun.
GFE saling terhubung melalui jaringan global Google. Data yang menjelaskan backend yang tersedia dan kapasitas penayangan yang tersedia untuk setiap resource yang di-load balance didistribusikan secara berkelanjutan ke semua GFE menggunakan bidang kontrol global.
Traffic ke alamat IP yang di-load balance di-proxy ke instance backend yang ditentukan dalam konfigurasi Load Balancer Aplikasi eksternal menggunakan algoritma load balancing khusus yang disebut Waterfall by Region. Algoritma ini menentukan backend yang optimal untuk melayani permintaan dengan mempertimbangkan kedekatan instance dengan pengguna, beban masuk, serta kapasitas backend yang tersedia di setiap zona dan region. Terakhir, beban dan kapasitas di seluruh dunia juga dipertimbangkan.
Load Balancer Aplikasi eksternal mendistribusikan traffic berdasarkan instance yang tersedia. Untuk menambahkan instance baru berdasarkan beban, algoritma ini bekerja bersama dengan grup instance penskalaan otomatis.
Aliran traffic dalam suatu region
Dalam keadaan normal, semua traffic dikirim ke region yang terdekat dengan pengguna. Load balancing kemudian dilakukan sesuai dengan panduan berikut:
Dalam setiap region, traffic didistribusikan di seluruh grup instance, yang dapat berada di beberapa zona sesuai dengan kapasitas setiap grup.
Jika kapasitas antar-zona tidak sama, zona dimuat sesuai dengan kapasitas penyaluran yang tersedia.
Dalam zona, permintaan didistribusikan secara merata ke instance di setiap grup instance.
Sesi dipertahankan berdasarkan alamat IP klien atau nilai cookie, bergantung pada setelan afinitas sesi.
Kecuali jika backend tidak tersedia, koneksi TCP yang ada tidak akan pernah dipindahkan ke backend yang berbeda.
Diagram berikut menunjukkan distribusi beban dalam kasus ini, di mana setiap region memiliki kapasitas yang cukup dan dapat menangani beban dari pengguna yang paling dekat dengan region tersebut.
Overflow traffic ke region lain
Jika seluruh region mencapai kapasitas sebagaimana ditentukan oleh kapasitas penayangan yang ditetapkan di layanan backend, algoritma Waterfall menurut Region dipicu, dan traffic diluapkan ke region terdekat yang memiliki kapasitas yang tersedia. Saat setiap region mencapai kapasitas, traffic akan diluapkan ke region terdekat berikutnya, dan seterusnya. Kedekatan region dengan pengguna ditentukan oleh waktu perjalanan pulang pergi jaringan dari GFE ke backend instance.
Diagram berikut menunjukkan peluapan ke region terdekat berikutnya saat satu region menerima lebih banyak traffic daripada yang dapat ditangani secara regional.
Overflow lintas regional karena backend yang tidak responsif
Jika health check mendeteksi bahwa lebih dari setengah backend di suatu region tidak responsif, GFE akan secara preventif meluapkan sebagian traffic ke region terdekat berikutnya. Hal ini terjadi untuk menghindari kegagalan traffic sepenuhnya saat region menjadi tidak sehat. Overflow ini terjadi meskipun kapasitas yang tersisa di region dengan backend yang tidak sehat sudah cukup.
Diagram berikut menunjukkan mekanisme overflow yang berlaku, karena sebagian besar backend di satu zona tidak sehat.
Semua wilayah di atas kapasitas
Jika traffic ke semua region berada pada atau di atas kapasitas, traffic akan diseimbangkan sehingga setiap region berada pada tingkat luapan 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% di atas kapasitas regionalnya, sekaligus menjaga traffic tetap bersifat lokal sebisa mungkin.
Diagram berikut menunjukkan aturan peluapan global ini berlaku. Dalam kasus 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 di setiap layanan backend dan memunculkan instance baru saat traffic mendekati batas kapasitas yang dikonfigurasi. Bergantung pada seberapa cepat tingkat permintaan meningkat dan seberapa cepat instance baru diaktifkan, overflow ke region lain mungkin tidak diperlukan. Dalam kasus lain, overflow dapat bertindak sebagai buffer sementara hingga instance lokal baru aktif dan siap melayani traffic langsung. Jika kapasitas yang diperluas oleh penskalaan otomatis sudah cukup, semua sesi baru akan didistribusikan ke region terdekat.
Efek latensi karena overflow
Menurut algoritma Waterfall by Region, overflow beberapa traffic oleh Load Balancer Aplikasi eksternal ke region lain dapat terjadi. Namun, sesi TCP dan traffic SSL tetap dihentikan oleh GFE terdekat dengan pengguna. Hal ini bermanfaat untuk latensi aplikasi; untuk mengetahui detailnya, lihat Mengoptimalkan Latensi Aplikasi dengan Load Balancing.
Latihan: Mengukur efek pengelolaan kapasitas
Untuk memahami cara terjadinya overflow 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 meluapkan kapasitas ke region lain. Untuk aplikasi global, merespons pengguna dengan latensi keseluruhan yang sedikit lebih tinggi menghasilkan pengalaman yang lebih baik daripada menggunakan backend regional. Aplikasi yang menggunakan backend regional memiliki latensi yang lebih rendah secara nominal, tetapi aplikasi tersebut dapat mengalami kelebihan beban.
Mari kita tinjau kembali bagaimana 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 dengan cukup cepat selama lonjakan traffic lokal, Load Balancer Aplikasi eksternal akan mengalihkan koneksi sementara ke region terdekat berikutnya. Hal ini memastikan bahwa sesi pengguna yang ada di wilayah asli ditangani dengan kecepatan optimal karena tetap berada di backend yang ada, sementara sesi pengguna baru hanya mengalami sedikit peningkatan latensi. Segera setelah instance backend tambahan di-scale up 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 diluapkan 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 ini berfungsi, jumlah maksimum instance ditetapkan ke jumlah maksimum lisensi di autoscaler.
Ruang VM terlalu kecil. Kemungkinan overflow regional 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 mencukupi.
Kuota regional. Jika kuota resource Compute Engine tidak sesuai dengan permintaan, peluapan Load Balancer Aplikasi eksternal akan otomatis mengalihkan sebagian traffic ke region yang masih dapat melakukan penskalaan dalam kuota regionalnya.
Langkah berikutnya
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 Jaringan 101
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Aplikasi Eksternal
- Load Balancer Jaringan proxy eksternal