Elastis Load Balancer (ELB) adalah salah satu komponen arsitektur utama untuk aplikasi di dalam cloud AWS. Selain penskalaan otomatis, ini memungkinkan dan menyederhanakan salah satu tugas paling penting dari arsitektur aplikasi kami: menskalakan ke atas dan ke bawah dengan ketersediaan tinggi.
Elastis Load Balancing secara otomatis mendistribusikan lalu lintas aplikasi yang masuk di beberapa aplikasi, microservices, dan kontainer yang dihosting pada instance Amazon EC2.
Salah satu dari banyak keuntungan menggunakan ELB adalah fakta bahwa itu elastis, yang berarti akan secara otomatis menskala untuk memenuhi lalu lintas masuk Anda. Jika Anda seorang administrator sistem atau insinyur DevOps menjalankan load balancer sendiri, maka Anda perlu khawatir tentang penskalaan penskalaan skala dan memungkinkan ketersediaan tinggi. Dengan ELB, Anda dapat membuat load balancer dan mengaktifkan penskalaan dinamis hanya dengan beberapa klik.
Sejak pertama kali dirilis pada tahun 2009, Elastic Load Balancer telah menambahkan banyak perbaikan dan fitur. Aplikasi Load Balancer (ALB) adalah langkah maju yang logis dalam mengembangkan kemungkinan load balancing di dalam cloud AWS. Dengan tambahan ini, load balancer asli telah diganti namanya menjadi Classic Load Balancer, dan masih tersedia untuk digunakan di dalam cloud AWS. Dalam pos ini, kita akan memeriksa fitur Penyeimbang Beban Aplikasi dibandingkan dengan yang asli, menunjukkan cara memantau ALB.
Elastic Load Balancing
Elastic Load Balancer (ELB) adalah salah satu komponen arsitektur utama untuk banyak aplikasi di dalam AWS cloud. Selain penskalaan otomatis, ini mengaktifkan dan menyederhanakan salah satu tugas terpenting arsitektur aplikasi kami: meningkatkan dan menurunkan skala dengan ketersediaan tinggi.
Elastic Load Balancing secara otomatis mendistribusikan lalu lintas aplikasi yang masuk ke beberapa aplikasi, layanan mikro, dan kontainer yang dihosting pada instans Amazon EC2. Salah satu dari banyak keuntungan menggunakan ELB adalah fakta bahwa ELB bersifat elastis (yaitu dapat diubah), yang berarti ELB akan secara otomatis menskalakan ke memenuhi lalu lintas masuk Anda.
Jika Anda seorang administrator sistem atau insinyur DevOps yang menjalankan penyeimbang beban sendiri, Anda juga harus memikul beban penskalaan penyeimbang beban dan mengaktifkan ketersediaan tinggi. Dengan ELB, Anda dapat membuat penyeimbang muatan dan mengaktifkan penskalaan dinamis hanya dengan beberapa klik.
Application Load Balancer vs. Classic Load Balancer
Selain Load Balancer Aplikasi, load balancer lain, jaringan atau load balancing klasik, mendistribusikan lalu lintas berdasarkan pada layer 3 dan 4.
Penyeimbang Beban Klasik adalah penyeimbang berbasis sambungan tempat permintaan diteruskan oleh penyeimbang beban tanpa “melihat ke” salah satu dari permintaan ini. Mereka hanya diteruskan ke bagian backend.
ALB bekerja pada model OSI Layer 7 dan memungkinkan distribusi lalu lintas ke arah backend berdasarkan informasi di dalam header permintaan HTTP. Dengan Load Balancer Aplikasi, koneksi diakhiri di ALB, dan ada koneksi koneksi ke arah contoh backend.
Ada kemungkinan untuk membuka beberapa koneksi menuju contoh backend, dan koneksi tersebut digunakan untuk meneruskan permintaan. Juga, Anda dapat memodifikasi header. Yang paling penting (dan berbeda dengan Classic Load Balancers), header berisi kolom X-forwarded-for yang berisi alamat IP klien.
Perbandingan Fitur
| Feature | Classic Load Balancer | Application Load Balancer |
| Protocols | HTTP, HTTPS, TCP, SSL | HTTP, HTTPS |
| Platforms | EC2-Classic, EC2-VPC | EC2-VPC |
| Sticky sessions (cookies) | YES (you can provide your own application cookie) | Load balancer generated |
| Back-end server authentication | YES | NO |
| Back-end server encryption | YES | YES |
| Idle connection timeout | YES | YES |
| Connection draining | YES | YES |
| Cross-zone load balancing | YES | Always enabled |
| Health checks | YES | YES (Improved) |
| CloudWatch metrics | YES | YES (Improved) |
| Access logs | YES | YES (Improved) |
| Path-based routing | NO | YES |
| Route to multiple ports on a single instance | NO | YES |
| HTTP/2 support | NO | YES |
| Websockets support | NO | YES |
| Load balancer deletion protection | NO | YES |
Aplikasi Load Balancer memungkinkan perutean berbasis konten dan memungkinkan permintaan dialihkan ke berbagai aplikasi di balik satu keseimbangan beban tunggal. Meskipun Penyeimbang Beban Klasik tidak melakukannya, satu ELB dapat menghosting satu aplikasi. ALB bukan penyeimbang Beban Klasik yang disempurnakan. Itu dibuat di platform yang benar-benar baru. Seperti Classic Load Balancer, ALB adalah platform load balancing yang sepenuhnya terkelola, terukur, dan sangat tersedia.
Berkat fitur routing berbasis jalur, Anda dapat menambahkan hingga 10 aplikasi berbeda di belakang satu ALB. Selain itu, ALB menyediakan dukungan asli untuk microservices dan arsitektur berbasis kontainer. Dengan Classic Load Balancer, Anda hanya bisa menggunakan satu port dalam satu waktu, sementara instance ALB memungkinkan Anda untuk mendaftar dengan banyak port. Untuk mendukung fungsionalitas baru yang ditambahkan di dalam ALB, beberapa jenis sumber daya baru ditambahkan, termasuk kelompok sasaran, target, dan aturan.
ALB dan Classic Load Balancer memiliki pendengar yang menentukan protokol dan port, di mana penyeimbang beban mendengarkan koneksi yang masuk. Setiap load balancer harus memiliki setidaknya satu pendengar dan mendukung hingga 10 pendengar. Aturan routing (berbasis konten, routing berbasis jalur) didefinisikan pada pendengar.
Grup target adalah pengelompokan target yang logis di balik load balancer dan mereka dapat eksis secara independen dari load balancer dan dapat ditambahkan ke dalamnya jika diperlukan. Target mewakili target load balancing logis, dan ini dapat berupa instance EC2, microservices, atau aplikasi berbasis kontainer. Target tunggal dapat didaftarkan dengan beberapa kelompok sasaran.
Aturan menyediakan hubungan antara pendengar dan kelompok sasaran dan terdiri dari kondisi dan tindakan. Setiap aturan mewakili kondisi dan tindakan yang ingin kita ikuti. Saat ini, hanya satu tindakan yang didukung: meneruskan permintaan ke aksi grup target yang ditentukan. Jika tidak ada aturan yang ditemukan, permintaan akan mengikuti aturan default, yang meneruskan permintaan ke grup target default.
Monitoring Application Load Balancer (ALB)
Aplikasi Load Balancer adalah layanan yang dikelola sepenuhnya, yang artinya Anda tidak memiliki opsi untuk mengakses SSH untuk melihat apa yang terjadi. Pemantauan ALB terdiri dari dua bagian: CloudWatch Metrics & Alarms, dan log akses.
Metrik CloudWatch tersedia di load balancing dan tingkat grup target.
Ada beberapa load balancing CloudWatch metrik yang harus Anda pantau.
– HealthHost Count: menunjukkan jumlah contoh yang sehat di setiap Zona Ketersediaan.
– Latency: mengukur waktu yang berlalu (dalam detik) dari saat permintaan diteruskan ke bagian backend, ke saat respons dari bagian backend.
– Rejected Connection Count: Karena ALB tidak menggunakan antrean lonjakan seperti Penyeimbang Beban Klasik, penting untuk memperhatikan metrik Penghitungan Sambungan yang Ditolak. Ini adalah jumlah koneksi yang ditolak karena load balancer tidak dapat membuat sambungan ke target kesehatan untuk merutekan permintaan.
– Access logs: Log akses disimpan ke penyimpanan S3. Log akses untuk ALB dihasilkan setiap lima menit. Anda harus membayar biaya S3 tetapi Anda tidak akan membayar transfer data ke S3. Log akses “akhirnya konsisten,” yang berarti file-file tersebut dapat dihasilkan tidak berurutan.
AWS tidak menjamin bahwa setiap permintaan akan ditulis ke log akses. Beberapa catatan mungkin hilang, Amazon mengatakan:
“Permintaan Load Balancing log elastis dengan basis upaya terbaik.”
Log akses berisi jenis permintaan (HTTP, HTTP / 2, dll.) Dan stempel waktu yang ditinggalkan oleh ALB oleh zona waktu UTC, pengidentifikasi ELB, alamat IP, dan port klien, yang mengirim permintaan, alamat IP, dan target port contoh bahwa permintaan diarahkan ke.
Selain itu, log akses berisi informasi tentang request_processing_time, target_processing_time, dan response_processing_time. Aplikasi Load Balancer membutuhkan sejumlah waktu untuk menerima dan meneruskan permintaan ke klien; ini disebut response_processing_time.
Di dalam log akses, Anda dapat melihat data tentang status kode dan target_status_code, yang dihasilkan oleh instance di balik load balancing dan elb_status_code yang dihasilkan oleh load balancing.
Ada dua kode respons yang berbeda karena mungkin terjadi bahwa load balancer tidak menerima respons oleh instance backend, target waktu habis, dan kemudian harus mengirim respons HTTP kembali ke klien yang berisi kode status. Selain itu, Anda memiliki data tentang lalu lintas, recived_bytes, dan sent_bytes, yang mewakili jumlah data yang diterima oleh load balancer dari sisi klien dan jumlah data yang dikirimnya kembali.
Log akses berisi permintaan HTTP asli, protokol user_agent, ssl_chiper, dan ssl_ serta data tentang grup target, target_group_arn, ke mana permintaan diarahkan.
Harga Application Load Balancer
Penetapan harga Load Balancer Aplikasi agak tidak jelas. Anda membayar setiap jam saat Load Balancer Aplikasi Anda berjalan dan Anda juga membayar untuk jumlah Unit Kapasitas Balancing Beban yang tidak terpakai (LCU).
Jumlah unit kapasitas dibagi dalam tiga dimensi. Dimensi pertama adalah koneksi baru. Untuk masing-masing dari 25 koneksi baru per detik, Anda mengkonsumsi 1 LCU. Dimensi kedua adalah untuk koneksi aktif. Untuk 3.000 sambungan aktif per menit, Anda mengonsumsi 1 LCU. Dimensi ketiga adalah untuk bandwidth. Untuk 2,22 Mbps, Anda mengonsumsi 1 LCU.
Penting untuk menunjukkan bahwa Anda akan ditagih hanya untuk dimensi yang paling sering Anda gunakan. Dengan kata lain, jika aplikasi Anda menerima banyak permintaan baru, dimensi yang dominan adalah koneksi baru dan Anda akan dikenakan biaya untuk ALB sesuai dengan dimensi itu. Jika Anda memiliki banyak transfer data file besar, dimensi dominan adalah bandwidth. Jika Anda menggunakan WebSockets, dimensi yang dominan adalah koneksi aktif.
Beberapa aplikasi pada satu ALB dapat menghemat banyak uang. Dengan cara ini, kami akan mengurangi biaya per jam sambil mempertahankan jumlah data yang diterima sama.
Akhir kata
Selain penghematan biaya, Application Load Balancer menawarkan lebih banyak fitur dan fleksibilitas dibandingkan dengan Penyeimbang Beban Klasik. Namun ada beberapa pengecualian. Misalnya, jika Anda akan menggunakan TCP / SSL atau EC2-Classic, maka Anda harus menggunakan Penyeimbang Beban Klasik.
Untuk semua kasus penggunaan lainnya, Amazon merekomendasikan penggunaan Load Balancer Aplikasi.
Semoga bermanfaat….
*** dikutip dari CloudAcademy
