Sebagian besar load balancer menggunakan pendekatan hashing round-robin atau berbasis alur untuk mendistribusikan traffic. Namun, load balancer yang menggunakan pendekatan ini dapat kesulitan beradaptasi saat lonjakan permintaan melebihi kapasitas penayangan yang tersedia. Artikel ini menjelaskan cara menggunakan Cloud Load Balancing untuk 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 implementasi 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 informasi selengkapnya tentang latensi, lihat Mengoptimalkan Latensi Aplikasi dengan Load Balancing.
Tantangan kapasitas dalam aplikasi global
Menskalakan aplikasi global dapat menjadi tantangan, terutama jika Anda memiliki anggaran IT yang terbatas dan beban kerja yang tidak dapat diprediksi dan berfluktuasi. Di lingkungan cloud publik seperti Google Cloud, fleksibilitas yang diberikan oleh fitur seperti penskalaan otomatis dan load balancing dapat membantu. Namun, pengoptimal ukuran memiliki beberapa batasan, seperti yang dijelaskan di bagian ini.
Latensi saat memulai instance baru
Masalah paling umum terkait penskalaan otomatis adalah aplikasi yang diminta belum siap menyalurkan 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 secara otomatis sama sekali. Misalnya, database sering kali memiliki kapasitas backend yang terbatas. Hanya jumlah frontend tertentu yang dapat mengakses database yang tidak diskalakan secara horizontal. Jika aplikasi Anda mengandalkan API eksternal yang hanya mendukung jumlah permintaan per detik yang terbatas, aplikasi tersebut juga tidak dapat diskalakan secara otomatis.
Lisensi non-elastis
Saat Anda menggunakan software berlisensi, lisensi tersebut sering kali membatasi Anda pada kapasitas maksimum yang telah ditetapkan. Oleh karena itu, kemampuan Anda untuk melakukan penskalaan otomatis mungkin dibatasi karena Anda tidak dapat menambahkan lisensi dengan cepat.
Headroom instance VM terlalu sedikit
Untuk memperhitungkan lonjakan traffic yang tiba-tiba, autoscaler harus menyertakan headroom yang memadai (misalnya, autoscaler 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 bottleneck penskalaan saat menghadapi lonjakan traffic, seperti kampanye iklan yang tiba-tiba meningkatkan permintaan. Anda perlu menyeimbangkan ukuran headroom berdasarkan seberapa tajam traffic Anda dan berapa lama waktu yang diperlukan instance VM baru untuk siap.
Kuota regional
Jika Anda mengalami lonjakan yang tidak terduga di suatu region, kuota resource yang ada mungkin membatasi jumlah instance yang dapat diskalakan di bawah level yang diperlukan untuk mendukung lonjakan saat ini. Pemrosesan 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 melalui server Google Front End (GFE) 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 dengan 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), dan hashing 5-tuple (berdasarkan IP sumber, IP tujuan, port sumber, port tujuan, dan protokol).
Dengan kedua algoritma ini, instance yang tidak sehat 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 lonjakan traffic yang tiba-tiba, traffic masih didistribusikan ke instance backend yang kelebihan kapasitas, sehingga menyebabkan peningkatan latensi yang drastis.
Beberapa load balancer mengizinkan aturan lanjutan dengan traffic yang melebihi kapasitas backend diteruskan ke kumpulan lain atau dialihkan ke situs statis. Hal ini memungkinkan Anda 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, pengalihan 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 jauh setelah TTL seharusnya berakhir di mana-mana. 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 melalui server GFE yang di-deploy di sebagian besar lokasi edge jaringan global Google. Saat ini, ada lebih dari 80 lokasi di seluruh dunia. Algoritme 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 salah satu GFE.
GFE saling terhubung melalui jaringan global Google. Data yang menjelaskan backend yang tersedia dan kapasitas penayangan yang tersedia untuk setiap resource beban berimbang terus didistribusikan ke semua GFE menggunakan bidang kontrol global.
Traffic ke alamat IP yang di-load balancing akan di-proxy ke instance backend yang ditentukan dalam konfigurasi Load Balancer Aplikasi eksternal menggunakan algoritma load balancing khusus yang disebut Waterfall menurut Region. Algoritma ini menentukan backend yang optimal untuk melayani permintaan dengan mempertimbangkan kedekatan instance dengan pengguna, beban yang masuk, serta kapasitas backend yang tersedia di setiap zona dan region. Terakhir, beban dan kapasitas di seluruh dunia juga diperhitungkan.
Load Balancer Aplikasi eksternal mendistribusikan traffic berdasarkan instance yang tersedia. Untuk menambahkan instance baru berdasarkan beban, algoritma ini berfungsi 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 tidak sama antarzona, zona akan dimuat sesuai dengan kapasitas penyaluran yang tersedia.
Dalam zona, permintaan tersebar secara merata di seluruh instance dalam 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 hal ini, dengan setiap region berkapasitas rendah dan dapat menangani beban dari pengguna yang paling dekat dengan region tersebut.
Traffic yang ditambahkan ke region lain
Jika seluruh region mencapai kapasitas seperti yang ditentukan oleh kapasitas penayangan yang ditetapkan di layanan backend, algoritma Waterfall menurut Region akan dipicu, dan traffic akan meluap ke region terdekat yang memiliki kapasitas yang tersedia. Saat setiap region mencapai kapasitas, traffic akan dialihkan ke region terdekat berikutnya, dan seterusnya. Kedekatan region dengan pengguna ditentukan oleh waktu perjalanan bolak-balik jaringan dari GFE ke backend instance.
Diagram berikut menunjukkan kelebihan traffic ke region terdekat berikutnya saat satu region menerima lebih banyak traffic daripada yang dapat ditanganinya secara regional.
Overflow lintas region karena backend tidak responsif
Jika health check menemukan bahwa lebih dari setengah backend di suatu region tidak responsif, GFE akan meluapkan beberapa traffic ke region terdekat berikutnya secara preventif. Hal ini dilakukan untuk menghindari kegagalan traffic sepenuhnya saat region menjadi tidak sehat. Kelebihan kapasitas ini terjadi meskipun kapasitas yang tersisa di region dengan backend yang tidak sehat sudah memadai.
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 mencapai atau melebihi kapasitas, traffic akan diseimbangkan sehingga setiap region memiliki tingkat luapan relatif yang sama dibandingkan dengan kapasitasnya. Misalnya, jika permintaan global melebihi kapasitas global sebesar 20%, traffic didistribusikan sedemikian rupa sehingga semua region menerima permintaan sebesar 20% di atas kapasitas regionalnya, sekaligus menjaga traffic selokal mungkin.
Diagram berikut menunjukkan aturan overflow global yang berlaku. Dalam hal ini, satu region menerima begitu banyak traffic sehingga tidak dapat didistribusikan sama sekali dengan kapasitas penayangan yang tersedia secara global.
Kelebihan sementara selama penskalaan otomatis
Penskalaan otomatis didasarkan pada batas kapasitas yang dikonfigurasi di setiap layanan backend dan menampilkan instance baru saat traffic mendekati batas kapasitas yang dikonfigurasi. Bergantung pada seberapa cepat tingkat permintaan meningkat dan seberapa cepat instance baru aktif, overflow ke region lain mungkin tidak diperlukan. Dalam kasus lain, overflow dapat bertindak sebagai buffering sementara hingga instance lokal baru online dan siap menayangkan traffic live. Jika kapasitas yang diperluas dengan autoscaling sudah memadai, semua sesi baru akan didistribusikan ke region terdekat.
Efek latensi dari overflow
Menurut algoritma Waterfall menurut Region, kelebihan kapasitas beberapa traffic oleh Load Balancer Aplikasi eksternal ke region lain dapat terjadi. Namun, sesi TCP dan traffic SSL masih dihentikan oleh GFE yang paling dekat dengan pengguna. Hal ini bermanfaat untuk latensi aplikasi; untuk mengetahui detailnya, lihat Mengoptimalkan Latensi Aplikasi dengan Load Balancing.
Praktik: 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 masalah kapasitas
Untuk membantu mengatasi tantangan yang telah dibahas sebelumnya, Load Balancer Aplikasi eksternal dan Load Balancer Jaringan proxy eksternal dapat melimpahkan 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 secara nominal lebih rendah, 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 pengatur skala tidak dapat menambahkan kapasitas dengan cukup cepat selama lonjakan traffic lokal, Load Balancer Aplikasi eksternal akan sementara melebihi kapasitas koneksi ke region terdekat berikutnya. Hal ini memastikan bahwa sesi pengguna yang ada di region asli ditangani dengan kecepatan optimal karena sesi tersebut tetap berada di backend yang ada, sementara sesi pengguna baru hanya mengalami sedikit peningkatan latensi. Segera setelah instance backend tambahan diskalakan ke atas di wilayah asli, traffic baru akan dialihkan lagi ke wilayah yang terdekat dengan pengguna.
Aplikasi dibatasi oleh kapasitas backend. Aplikasi yang tidak dapat diskalakan secara otomatis, tetapi tersedia di beberapa region, masih dapat meluap 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 berfungsi, jumlah maksimum instance ditetapkan ke jumlah maksimum lisensi di autoscaler.
Headroom VM terlalu sedikit. 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 kelebihan kapasitas ke region lain akan memastikan bahwa kapasitas global akan selalu memadai.
Kuota regional. Jika kuota resource Compute Engine tidak cocok dengan permintaan, kelebihan Application Load Balancer eksternal akan otomatis mengalihkan sebagian traffic ke region yang masih dapat diskalakan dalam 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 Dasar-Dasar Jaringan
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Aplikasi Eksternal
- Load Balancer Jaringan proxy eksternal