Ikhtisar
Ringkasan
Jaringan pengiriman aplikasi digunakan untuk merilis aplikasi, menerapkan pemulihan bencana, dan memberikan perlindungan. Server Load Balancer (SLB) adalah komponen utama dalam jaringan pengiriman aplikasi. Keluarga SLB mencakup Network Load Balancer (NLB) Lapisan 4, Application Load Balancer (ALB) Lapisan 7, dan Classic Load Balancer (CLB). Sebagai gateway cloud-native dari Alibaba Cloud, SLB merupakan salah satu komponen terpenting dalam jaringan pengiriman aplikasi. Topik ini menjelaskan cara memilih, menerapkan, dan menggunakan SLB untuk membangun jaringan pengiriman aplikasi yang efisien tinggi.
Istilah
Virtual Private Cloud (VPC): VPC adalah jaringan pribadi kustom yang dapat Anda buat di Alibaba Cloud. VPC terisolasi secara logis satu sama lain pada Lapisan 2. Anda dapat membuat dan mengelola instance layanan cloud di dalam VPC, seperti Elastic Compute Service (ECS), Server Load Balancer (SLB), dan ApsaraDB RDS.
Alamat IP Virtual (VIP): VIP adalah alamat IP yang tidak ditetapkan ke komputer atau antarmuka jaringan tertentu. VIP dapat dialokasikan secara dinamis ke server fisik atau perangkat berbeda untuk menyeimbangkan beban dan menerapkan ketersediaan tinggi serta redundansi.
Pemutusan DNS: Selama migrasi jaringan atau alih bencana, pemutusan DNS memungkinkan lalu lintas jaringan bermigrasi dari server yang ada ke server baru atau layanan berdasarkan rekaman DNS yang diperbarui. Pemutusan DNS digunakan untuk memastikan kontinuitas layanan selama migrasi.
CNAME: Rekaman CNAME adalah jenis rekaman DNS yang memetakan nama domain ke nama domain lainnya. Setelah rekaman CNAME dikonfigurasi, server DNS mengarahkan permintaan ke nama domain tujuan (CNAME) dari nama domain alias, lalu mengembalikan alamat IP dari nama domain tujuan yang dikonfigurasi dalam rekaman A.
Application Load Balancer (ALB): ALB adalah layanan Alibaba Cloud yang beroperasi di lapisan aplikasi, dioptimalkan untuk menyeimbangkan lalu lintas melalui HTTP, HTTPS, dan Quick UDP Internet Connections (QUIC). ALB bersifat elastis, mampu memproses volume besar lalu lintas Lapisan 7 sesuai permintaan, serta mendukung routing kompleks. Terintegrasi dengan layanan cloud-native lainnya, ALB dirancang sebagai gerbang Ingress cloud-native untuk Alibaba Cloud.
Network Load Balancer (NLB): NLB adalah layanan penyeimbangan beban Lapisan 4 yang ditujukan untuk era Internet of Everything (IoE). NLB menawarkan performa ultra-tinggi dan dapat diskalakan secara otomatis sesuai permintaan. Instance NLB mendukung hingga 100 juta koneksi bersamaan, ideal untuk layanan yang memerlukan konkurensi tinggi.
Classic Load Balancer (CLB): CLB mendistribusikan lalu lintas jaringan masuk ke beberapa server backend berdasarkan aturan pengalihan. CLB membantu meningkatkan performa dan ketersediaan aplikasi Anda.
Network Intelligence Service (NIS): NIS menyediakan serangkaian alat AIOps untuk mengelola siklus hidup penuh jaringan cloud, mulai dari perencanaan hingga operasi dan pemeliharaan jaringan. Contohnya, Anda dapat menggunakan NIS untuk analisis lalu lintas, inspeksi jaringan, pemantauan kinerja, diagnostik, analisis jalur, serta pembuatan topologi. NIS membantu mengoptimalkan arsitektur jaringan, meningkatkan efisiensi operasi dan pemeliharaan, serta mengurangi biaya operasional jaringan.
CloudMonitor: CloudMonitor merupakan layanan pemantauan untuk sumber daya dan aplikasi Internet.
Bandwidth Internet Bersama: Bandwidth Internet Bersama mendukung berbagi bandwidth dan multiplexing bandwidth dalam wilayah. Setelah Anda membuat instance Bandwidth Internet Bersama di suatu wilayah, Anda dapat menambahkan elastic IP addresses (EIPs) di wilayah tersebut ke instance Bandwidth Internet Bersama. EIP dapat berbagi instance Bandwidth Internet Bersama, mengurangi biaya bandwidth Internet.
Prinsip desain
Untuk memastikan rilis aplikasi yang cepat, andal, dan aman, kami sarankan Anda mempertimbangkan prinsip-prinsip berikut saat merancang jaringan pengiriman aplikasi:
Kinerja: Pastikan kinerja jaringan pengiriman aplikasi dapat menahan throughput, jumlah koneksi baru, jumlah koneksi bersamaan, dan jumlah permintaan per detik (QPS) selama jam sibuk.
Skalabilitas: Pastikan jaringan pengiriman aplikasi dapat diskalakan masuk atau keluar berdasarkan volume bisnis, dan rancang model penetapan harga yang tepat.
Stabilitas: Pastikan jaringan pengiriman aplikasi dilengkapi dengan arsitektur yang kuat dan mekanisme pemulihan bencana yang kuat untuk memastikan rilis aplikasi yang stabil.
Keamanan: Pastikan jaringan pengiriman aplikasi mendukung perlindungan di lapisan aplikasi, transmisi, dan jaringan.
Observabilitas: Pastikan jaringan pengiriman aplikasi mendukung metrik dimensi penuh dan pencatatan, yang membantu Anda memantau jaringan secara real-time dan melakukan analitik serta pemecahan masalah.
Kami sarankan Anda menggabungkan prinsip-prinsip desain sebelumnya dengan kinerja dan fitur SLB yang dibutuhkan oleh sistem aplikasi Anda dan skenario bisnis untuk memilih layanan dan solusi penerapan yang sesuai.
Desain utama
Pilih layanan SLB
Saat memilih layanan SLB, fokus pada kemampuan utama berikut: kinerja (kapasitas dan fitur), stabilitas, skalabilitas, dan keamanan.
Prasyarat
Tentukan jenis load balancer yang dibutuhkan oleh sistem aplikasi Anda, seperti load balancer Lapisan 4 atau Lapisan 7.
Item perbandingan | ALB | NLB | CLB |
Posisi layanan |
|
|
|
Jika sistem aplikasi Anda memerlukan penyeimbangan beban di Lapisan 4, pilih NLB atau CLB.
Jika sistem aplikasi Anda memerlukan penyeimbangan beban di Lapisan 7, pilih ALB atau CLB.
Metrik kinerja utama
Tentukan metrik kinerja yang dibutuhkan oleh sistem aplikasi Anda dan pilih layanan SLB yang sesuai.
Item Perbandingan | ALB | NLB | CLB |
Arsitektur dan Kinerja |
|
|
|
Kemampuan Pengalihan |
|
|
|
Tipe Server Backend |
|
|
|
Kemampuan O&M |
|
|
|
Integrasi Cloud-Native |
| Mendukung integrasi dengan Container Service for Kubernetes (ACK) dan ACK Serverless (versi 1.24 dan lebih baru). | Harus digunakan bersama layanan kontainer seperti Container Service for Kubernetes (ACK) dan Serverless Kubernetes (ASK). |
Skenario Umum |
|
|
|
Kapasitas
Jika sistem aplikasi Anda memerlukan penyeimbangan beban Lapisan 4, skalabilitas tinggi, dan jumlah koneksi baru atau koneksi bersamaan yang tinggi, kami sarankan Anda memilih NLB.
Jika sistem aplikasi Anda memerlukan penyeimbangan beban Lapisan 7, skalabilitas tinggi, dan jumlah QPS yang tinggi, kami sarankan Anda memilih ALB.
Jika sistem aplikasi Anda memerlukan performa penyeimbangan beban moderat di Lapisan 4 atau Lapisan 7, kami sarankan Anda memilih CLB.
Fitur yang Didukung
Jika sistem aplikasi Anda memiliki persyaratan tinggi untuk offloading SSL untuk lalu lintas TCP di Lapisan 4, pengendalian aliran dalam kasus lonjakan lalu lintas, dan dukungan cloud-native, kami sarankan Anda memilih NLB.
Jika sistem aplikasi Anda memiliki persyaratan tinggi untuk routing dan gateway ingress cloud-native di Lapisan 7, kami sarankan Anda memilih ALB.
Jika sistem aplikasi Anda memiliki persyaratan moderat untuk fitur Lapisan 4 atau Lapisan 7, kami sarankan Anda memilih CLB.
Metrik stabilitas utama
ALB, NLB, dan CLB menggunakan arsitektur dan mekanisme pemulihan bencana yang berbeda. Sebelum memilih layanan SLB, kami sarankan Anda menentukan kemampuan pemulihan bencana yang dibutuhkan oleh sistem aplikasiAnda.
Zona Aktif Ganda
ALB dan NLB mendukung penyebaran multi-zona. Jika wilayah sistem aplikasi Anda mendukung dua zona atau lebih, kami sarankan Anda memilih setidaknya dua zona untuk memastikan ketersediaan tinggi layanan. ALB dan NLB menyediakan layanan menggunakan nama domain. Nama domain alias dipetakan ke nama domain NLB atau ALB berdasarkan rekaman CNAME. Lalu lintas bisnis dijadwalkan ke VIP dari instance ALB atau NLB di zona yang dipilih. Jika sebuah zona gagal, pemutusan DNS dipicu di zona tersebut untuk memigrasikan lalu lintas ke zona lain guna menerapkan pemulihan bencana. Mekanisme ini memastikan bahwa lalu lintas dapat beralih secara otomatis ke zona sehat jika salah satu zona gagal. Pemulihan bencana memastikan kontinuitas layanan dan ketersediaan tinggi.
Zona Primer/Sekunder
Penyebaran dual-zone CLB didukung di sebagian besar wilayah. Instance CLB semacam itu diterapkan di dua zona. Secara default, zona primer diaktifkan. Jika zona primer gagal, CLB dapat beralih ke zona sekunder dalam 30 detik untuk memulihkan layanan. Saat zona primer pulih, CLB secara otomatis beralih kembali ke zona primer.
CatatanPemulihan bencana zona untuk CLB diimplementasikan antara zona primer dan sekunder. CLB hanya beralih ke zona sekunder ketika seluruh kluster CLB dalam zona primer sepenuhnya tidak tersedia karena faktor seperti pemadaman listrik atau kegagalan konektivitas di zona primer. Alih bencana tidak dipicu jika hanya satu instance di zona primer gagal.
Kesimpulannya, NLB dan ALB diterapkan di beberapa zona untuk mendukung kemampuan pemulihan bencana yang lebih tinggi dibandingkan CLB, yang diterapkan di dua zona. Satu instance SLB dapat diterapkan di setidaknya dua zona untuk meningkatkan ketersediaan tinggi sistem dan kemampuan pemulihan bencana. Selain itu, alih bencana yang lebih cepat didukung. Anda dapat menghapus rekaman DNS zona yang rusak untuk merespons kegagalan dengan cepat dan menangani masalah. Kami sarankan Anda memilih layanan SLB berdasarkan kinerja dan stabilitas yang dibutuhkan oleh sistem aplikasi Anda. Jika sistem aplikasi Anda memiliki persyaratan tinggi untuk ketersediaan tinggi, NLB dan ALB lebih cocok karena mereka mendukung penyebaran multi-zona.
Metrik skalabilitas utama
Manfaat langsung dari skalabilitas adalah penskalaan keluar cepat selama jam sibuk. Anda dikenai biaya untuk jumlah sumber daya yang sebenarnya digunakan, yang mencegah biaya tinggi akibat pemborosan sumber daya. Saran:
ALB dan NLB mendukung kapasitas tinggi dan performa tinggi. Jika Anda memilih ALB atau NLB untuk sistem aplikasi Anda, kami sarankan Anda menggunakan metode pengukuran pay-by-LCU untuk membayar sumber daya yang sebenarnya Anda gunakan.
CLB mendukung metode pengukuran pay-by-specification dan pay-by-LCU. Jika Anda memilih CLB untuk sistem aplikasi Anda, kami sarankan Anda menggunakan metode pengukuran pay-by-LCU untuk membayar sumber daya yang sebenarnya Anda gunakan.
Metrik keamanan utama
ALB, NLB, dan CLB mendukung fitur yang berbeda. Kami sarankan Anda menentukan persyaratan keamanan sistem aplikasi Anda sebelum memilih layanan SLB.
Penyeimbangan Beban Lapisan 7: Perlindungan Terhadap Serangan Web
Untuk melindungi sistem aplikasi Anda dari serangan web, kami sarankan Anda memilih ALB. Instance ALB dengan WAF terintegrasi dengan Web Application Firewall (WAF) 3.0 di tingkat layanan.
WAF 3.0 terintegrasi dengan ALB melalui modul SDK, dan menggunakan SDK untuk mengekstraksi lalu lintas untuk deteksi dan perlindungan. Metode integrasi ini menawarkan manfaat berikut:
Pengalihan: WAF tidak meneruskan lalu lintas, untuk mencegah masalah inkompatibilitas atau ketidakstabilan akibat lapisan pengalihan tambahan, atau peningkatan latensi jaringan.
Penyebaran: Anda tidak perlu mengubah pengaturan DNS, sertifikat, port, atau algoritma back-to-origin. Proses integrasi dengan WAF sederhana.
Penyeimbangan Beban Lapisan 4: Enkripsi pada Lapisan Transmisi
Jika sistem aplikasi Anda memerlukan penyeimbangan beban Lapisan 4 dan enkripsi untuk lalu lintas SSL over TCP, disarankan untuk memilih NLB.
NLB mendukung pendengar TCP/SSL yang dapat melakukan offloading SSL untuk lalu lintas TCP. Lalu lintas terenkripsi didekripsi menjadi teks biasa dan diteruskan ke server backend, menyederhanakan konfigurasi server backend, mengurangi beban kerja, serta meningkatkan efisiensi kerja.
Terapkan layanan SLB
Setelah Anda memilih layanan SLB, Anda perlu fokus pada kinerja, stabilitas, dan keamanan saat menerapkan layanan SLB.
Metrik kinerja utama
Kapasitas Instance
Instance ALB dan NLB mendukung performa tinggi dan skalabilitas. Jika sistem aplikasi Anda perlu menahan lonjakan lalu lintas yang diperkirakan, seperti kegiatan promosi, kami sarankan Anda menghubungi manajer akun Anda terlebih dahulu untuk mengevaluasi apakah performa dan skalabilitas instance Anda dapat menahan lonjakan lalu lintas.
Sebuah instance CLB mendukung spesifikasi yang sama dengan tipe instance S3.large, yang mendukung maksimum 1.000.000 koneksi, 100.000 koneksi baru, dan 50.000 QPS, baik Anda menggunakan metode pengukuran pay-by-specification atau pay-by-LCU. Kami sarankan Anda memilih metode pengukuran, tipe instance, dan jumlah instance berdasarkan pola lalu lintas dan skala bisnis sistem aplikasi Anda.
Bandwidth Internet
Instance ALB dan NLB yang menghadap Internet menggunakan EIP untuk menyediakan layanan Internet.
Jika pola lalu lintas sistem aplikasi Anda relatif stabil, kami sarankan Anda menggunakan instance Bandwidth Internet Bersama pay-by-bandwidth, dan tentukan nilai bandwidth maksimum.
Jika sistem aplikasi Anda mengalami fluktuasi lalu lintas yang besar, kami sarankan Anda menggunakan instance Bandwidth Internet Bersama pay-by-dominant-traffic dan tentukan nilai bandwidth maksimum. Metode pengukuran pay-by-dominant-traffic hanya menagih transfer data dalam arah dominan dalam satu siklus penagihan.
CatatanBandwidth maksimum EIP pay-by-data-transfer adalah 200 Mbit/s. Untuk memastikan sumber daya bandwidth yang cukup untuk sistem aplikasi Anda, kami sarankan Anda menambahkan instance SLB Anda ke instance Bandwidth Internet Bersama.
Jika Anda menggunakan CLB, Anda dapat mengaitkan EIP dengan instance CLB internal-facing, atau menggunakan instance CLB yang menghadap Internet. Namun, jika Anda ingin mengaktifkan multiplexing bandwidth untuk beberapa instance SLB dan mempertahankan alamat IP eksklusif untuk setiap instance SLB, kami sarankan Anda membuat instance CLB internal-facing dan mengaitkannya dengan EIP. Kemudian, tambahkan instance CLB ke instance Bandwidth Internet Bersama.
Metrik stabilitas utama
Zona Instance
Jika Anda menggunakan ALB, pilih setidaknya dua zona, dan terapkan server backend di zona yang sama dengan instance ALB. Namun, ALB tidak mendukung penonaktifan pengalihan lintas zona. Setelah VIP dari instance ALB menerima permintaan klien, instance ALB meneruskan permintaan ke server backend di semua zona, bukan zona dari VIP.
Jika Anda menggunakan NLB, pilih setidaknya dua zona dan terapkan server backend di zona yang sama dengan instance NLB. Anda dapat menonaktifkan pengalihan lintas zona untuk instance NLB Anda. Setelah VIP dari instance NLB Anda menerima permintaan klien, instance NLB meneruskan permintaan ke server backend di zona instance NLB.
Jika Anda menggunakan CLB, terapkan instance CLB dan server backend di zona primer yang sama untuk mencegah pengalihan lintas zona.
Pemeriksaan Kesehatan pada Server Backend
Kami sarankan Anda mengaktifkan pemeriksaan kesehatan untuk instance SLB Anda untuk memantau ketersediaan server backend. Jika server backend dinyatakan tidak sehat, SLB berhenti meneruskan permintaan ke server backend dan mendistribusikan permintaan berikutnya ke server backend yang sehat. Setelah server backend yang tidak sehat pulih, ALB mendistribusikan permintaan ke server backend tersebut. Fitur pemeriksaan kesehatan mencegah titik kegagalan tunggal (SPOF) yang disebabkan oleh server backend yang tidak sehat dan meningkatkan ketersediaan layanan. ALB, NLB, dan CLB mendukung pemeriksaan kesehatan TCP dan HTTP.
Pengendalian Aliran pada Pendengar
Untuk mencegah efek avalan yang disebabkan oleh lonjakan lalu lintas tak terduga yang melebihi kapasitas server backend, kami sarankan Anda mengaktifkan pengendalian aliran pada pendengar SLB. Dalam kasus lonjakan lalu lintas, pengendalian aliran hanya mengizinkan permintaan yang tidak melebihi kapasitas server backend.
ALB Pengendalian QPS
Anda dapat mengendalikan total QPS atau QPS per klien untuk pendengar ALB. Pengendalian QPS per klien membatasi permintaan berdasarkan alamat IP klien sumber. Anda dapat mengaktifkan kedua metode pengendalian atau salah satu metode pengendalian.
Pengendalian NLB untuk koneksi baru per detik (CPS)
Anda dapat mengendalikan jumlah maksimum CPS baru di setiap zona (VIP) untuk pendengar NLB.
Metrik keamanan utama
Kontrol Akses Berbasis Daftar Putih atau Daftar Hitam
ALB dan NLB dapat ditambahkan ke grup keamanan. Anda dapat mengaktifkan kontrol akses untuk instance ALB atau NLB dengan menambahkannya ke grup keamanan. Untuk informasi lebih lanjut, lihat Tambahkan instance ALB ke grup keamanan dan Tambahkan instance NLB ke grup keamanan.
CLB mendukung daftar kontrol akses (ACL) untuk pendengar. ACL dapat berfungsi sebagai daftar putih atau daftar hitam. Anda dapat mengonfigurasi daftar putih atau daftar hitam untuk pendengar yang berbeda:
Daftar putih: Hanya permintaan dari alamat IP atau blok CIDR dalam ACL yang diteruskan. Daftar putih berlaku untuk skenario di mana Anda ingin mengizinkan permintaan hanya dari alamat IP tertentu.
Daftar hitam: Semua permintaan dari alamat IP atau blok CIDR dalam daftar hitam ditolak. Daftar hitam berlaku untuk skenario di mana Anda ingin memblokir akses dari alamat IP tertentu.
Kebijakan Keamanan TLS Kustom
Untuk penyeimbangan beban Lapisan 7, ALB menyediakan beberapa kebijakan keamanan TLS yang umum digunakan untuk meningkatkan keamanan layanan yang menggunakan HTTPS. ALB juga memungkinkan Anda mengonfigurasi kebijakan keamanan TLS kustom. Misalnya, Anda dapat menentukan versi TLS yang ingin Anda gunakan, atau menonaktifkan paket cipher TLS tertentu.
Untuk skenario penyeimbangan beban Lapisan 4 yang memerlukan offloading SSL untuk lalu lintas TCP, NLB menyediakan beberapa kebijakan keamanan TLS yang umum digunakan untuk meningkatkan keamanan layanan. Anda dapat memilih kebijakan keamanan TLS sistem atau mengonfigurasi kebijakan keamanan TLS kustom untuk melindungi sistem aplikasi Anda.
CatatanCLB tidak mendukung kebijakan keamanan TLS kustom.
Otentikasi Timbal Balik
Dalam skenario HTTPS, instance ALB standar, ALB dengan WAF, NLB, dan CLB mendukung otentikasi timbal balik untuk membantu sistem aplikasi Anda memenuhi persyaratan kepatuhan keamanan. Dalam skenario offloading SSL untuk lalu lintas TCP, NLB juga mendukung otentikasi timbal balik guna meningkatkan keamanan komunikasi. Untuk informasi lebih lanjut, lihat Konfigurasikan otentikasi timbal balik pada pendengar HTTPS, Gunakan NLB untuk mengaktifkan offloading SSL over TCP (otentikasi timbal balik), dan Konfigurasikan otentikasi timbal balik pada pendengar HTTPS.
Bekerja dengan layanan SLB
Saat Anda bekerja dengan layanan SLB, perhatikan metrik observabilitas utama.
Metrik observabilitas utama
Pemantauan
Jika sistem aplikasi Anda mengalami masalah konektivitas jaringan, seperti timeout permintaan dan pengendalian aliran lalu lintas, atau Anda perlu mengetahui beban kerja pada instance SLB Anda, Anda dapat melihat metrik pemantauan instance SLB Anda. Untuk informasi lebih lanjut, lihat Metrik Pemantauan NLB, Metrik Pemantauan ALB, dan Metrik Pemantauan CLB.
Logging
SLB mendukung log operasi dan log akses. Untuk informasi lebih lanjut, lihat Log ALB, Log NLB, Log Akses, dan Lihat Log Operasi.
Log operasi mencatat operasi yang dilakukan pada instance SLB.
Log akses mencatat informasi detail tentang permintaan yang dikirim ke instance SLB Lapisan 7, termasuk waktu permintaan, alamat IP klien, latensi, jalur permintaan, dan waktu respons server. Anda dapat menganalisis log akses untuk mengetahui perilaku dan distribusi geografis klien serta melakukan pemecahan masalah.
NIS
Selain fitur pemantauan dan pencatatan NLB, ALB, dan CLB, kami sarankan Anda mengaktifkan NIS untuk meningkatkan observabilitas jaringan pengiriman aplikasi Anda.
Praktik terbaik
Seperti yang dijelaskan di bagian sebelumnya, ALB dan NLB mendukung performa, stabilitas, skalabilitas, keamanan, dan observabilitas yang lebih tinggi. Di antara CLB, ALB, dan NLB, kami sarankan Anda menggunakan ALB atau NLB untuk membangun jaringan pengiriman aplikasi. Praktik terbaik berikut menjelaskan beberapa solusi untuk membangun jaringan pengiriman aplikasi dalam empat skenario berbeda.
Jaringan pengiriman aplikasi intra-wilayah
Dalam jaringan pengiriman aplikasi intra-wilayah, instance SLB dan server backend berada di wilayah yang sama.
SLB Lapisan 4
Desain Utama:
Stabilitas
Pilih minimal dua zona untuk instance NLB Anda dan pastikan instance NLB serta server backend berada di zona yang sama.
Anda dapat menonaktifkan pengalihan lintas zona untuk instance NLB.
Tentukan apakah perlu mengaktifkan pengendalian koneksi baru sesuai kebutuhan bisnis Anda. Pengendalian ini membantu mencegah efek avalan akibat lonjakan lalu lintas tak terduga.
Kami sarankan Anda mengaktifkan pemeriksaan kesehatan untuk server backend.
Kinerja
Kami sarankan Anda mengaitkan instance NLB yang menghadap Internet dengan instance Bandwidth Internet Bersama, serta memilih metode pengukuran yang tepat antara pay-by-dominant-traffic dan pay-by-bandwidth berdasarkan pola lalu lintas Anda.
Keamanan
Tentukan apakah perlu menambahkan instance NLB Anda ke grup keamanan berdasarkan persyaratan keamanan sistem aplikasi Anda. Jika menggunakan pendengar TCP/SSL, tentukan apakah perlu menggunakan kebijakan keamanan TLS kustom dan apakah perlu mengaktifkan otentikasi timbal balik.
SLB Lapisan 7
Desain utama:
Stabilitas
Pilih setidaknya dua zona untuk instance ALB Anda dan terapkan instance ALB serta server backend di zona yang sama.
Tentukan apakah Anda perlu mengaktifkan pengendalian QPS untuk mencegah efek avalan yang disebabkan oleh lonjakan lalu lintas tak terduga.
Kami sarankan Anda mengaktifkan pemeriksaan kesehatan untuk server backend.
Kinerja
Kami sarankan Anda mengaitkan instance ALB yang menghadap Internet dengan instance Bandwidth Internet Bersama dan memilih metode pengukuran yang tepat antara pay-by-dominant-traffic dan pay-by-bandwidth berdasarkan pola lalu lintas Anda.
Keamanan
Tentukan apakah Anda perlu menambahkan instance NLB Anda ke grup keamanan, mengonfigurasi kebijakan keamanan TLS kustom, dan mengaktifkan otentikasi timbal balik berdasarkan persyaratan keamanan sistem aplikasi Anda.
Jaringan pengiriman aplikasi antar-wilayah
Dalam jaringan pengiriman aplikasi antar-wilayah, instance SLB dan server backend berada di wilayah yang berbeda.
Seperti yang ditunjukkan pada gambar berikut, jaringan pengiriman aplikasi antar-wilayah dibangun berdasarkan NLB atau ALB. Jaringan pengiriman aplikasi mendukung akses terdekat dan pemulihan bencana lintas wilayah. Untuk informasi lebih lanjut tentang cara menerapkan jaringan pengiriman aplikasi antar-wilayah, lihat Tentukan server backend yang berlokasi di VPC di wilayah berbeda untuk ALB dan Tambahkan server backend di VPC ke NLB lintas wilayah.
Jaringan pengiriman aplikasi IPv6
Pilih layanan SLB
Jika Anda ingin menggunakan SLB untuk membangun jaringan pengiriman aplikasi IPv6, kami sarankan Anda memilih layanan SLB berdasarkan skenario, seperti komunikasi end-to-end melalui IPv6 dan konversi IPv6-ke-IPv4.
Skenario 1: Komunikasi End-to-End Melalui IPv6
NLB dan ALB mendukung server backend IPv6. Permintaan IPv6 diteruskan ke server backend melalui IPv6 untuk memungkinkan komunikasi end-to-end IPv6. CLB tidak mendukung server backend IPv6.
Skenario 2: Konversi IPv6-ke-IPv4
NLB, ALB, dan CLB mendukung konversi IPv6-ke-IPv4. Permintaan IPv6 diteruskan ke server backend melalui IPv4. Dengan cara ini, sistem aplikasi mendukung akses dari permintaan IPv6.
Karena NLB dan ALB mendukung komunikasi end-to-end melalui IPv6 dan konversi IPv6-ke-IPv4, kami sarankan Anda memilih NLB atau ALB untuk membangun jaringan pengiriman aplikasi IPv6.
Selain itu, NLB dan ALB menyediakan instance dual-stack yang mendukung alamat IPv4 dan IPv6. Anda dapat menggunakan instance NLB atau ALB dual-stack untuk membangun jaringan pengiriman aplikasi yang mendukung IPv4 dan IPv6. CLB tidak mendukung instance dual-stack. Jika Anda ingin jaringan pengiriman aplikasi Anda mendukung IPv4 dan IPv6, Anda perlu membuat instance IPv4 dan instance IPv6. Kami sarankan Anda memilih NLB atau ALB, yang mendukung arsitektur sederhana untuk jaringan pengiriman aplikasi.
Terapkan layanan SLB
Saat Anda menerapkan jaringan pengiriman aplikasi IPv6, kami sarankan Anda fokus pada stabilitas, keamanan, skalabilitas, observabilitas, dan kemampuan layanan mandiri.
Komunikasi End-to-End melalui IPv6
Langkah 1: Aktifkan IPv6 untuk instance VPC NLB atau ALB.
Langkah 2: Buat instance NLB atau ALB dengan mode dual-stack.
Langkah 3: Jika Anda ingin alamat IPv6 instance NLB atau ALB memiliki akses Internet, aktifkan bandwidth Internet untuk alamat IPv6 pada gateway IPv6 dari VPC tempat instance NLB atau ALB diterapkan.
Langkah 4: Buat grup server untuk instance NLB atau ALB dan aktifkan IPv6.
Konversi IPv6-ke-IPv4
Terapkan instance NLB atau ALB
Langkah 1: Aktifkan IPv6 untuk VPC instance NLB atau ALB.
Langkah 2: Buat instance NLB atau ALB dual-stack.
Langkah 3: Jika Anda ingin alamat IPv6 instance NLB atau ALB Anda memiliki akses Internet, aktifkan bandwidth Internet untuk alamat IPv6 pada gateway IPv6 dari VPC tempat instance NLB atau ALB diterapkan.
Langkah 4: Buat grup server untuk instance NLB atau ALB. Anda tidak perlu mengaktifkan IPv6.
Terapkan instance CLB
Buat instance CLB IPv6. Hanya instance CLB yang menghadap Internet yang mendukung IPv6. Selesaikan konfigurasi instance CLB.