Aplikasi internet dapat mengalami fluktuasi penggunaan yang ekstrem. Meskipun sebagian besar aplikasi perusahaan tidak menghadapi tantangan ini, banyak perusahaan harus menangani berbagai jenis workload yang burst: tugas batch atau CI/CD.
Pola arsitektur ini bergantung pada deployment aplikasi yang redundan di beberapa lingkungan komputasi. Tujuannya adalah untuk meningkatkan kapasitas, ketahanan, atau keduanya.
Meskipun Anda dapat mengakomodasi workload yang burst di lingkungan komputasi berbasis pusat data dengan penyediaan resource yang berlebihan, pendekatan ini mungkin tidak hemat biaya. Dengan tugas batch, Anda dapat mengoptimalkan penggunaan dengan memperpanjang eksekusinya selama jangka waktu yang lebih lama, meskipun menunda tugas tidak akan praktis jika tugas tersebut mendesak.
Gagasan pola cloud bursting yaitu menggunakan lingkungan komputasi pribadi untuk beban dasar pengukuran dan melakukan burst ke cloud untuk sementara saat Anda membutuhkan kapasitas ekstra.
Dalam diagram sebelumnya, jika kapasitas data mencapai batasnya di lingkungan pribadi lokal, sistem dapat memperoleh kapasitas ekstra dari lingkungan Google Cloud saat diperlukan.
Pendorong utama dari pola ini adalah menghemat uang dan mengurangi waktu dan upaya yang diperlukan untuk merespons perubahan persyaratan skala. Dengan pendekatan ini, Anda hanya membayar resource yang digunakan saat menangani beban tambahan. Artinya, Anda tidak perlu menyediakan infrastruktur secara berlebihan. Sebagai gantinya, Anda dapat memanfaatkan resource cloud on-demand dan menskalakannya agar sesuai dengan permintaan, serta metrik yang telah ditentukan. Oleh karena itu, perusahaan Anda mungkin menghindari gangguan layanan selama waktu permintaan puncak.
Persyaratan potensial untuk skenario cloud bursting adalah portabilitas workload. Saat mengizinkan workload di-deploy ke beberapa lingkungan, Anda harus memisahkan perbedaan di antara lingkungan. Misalnya, Kubernetes memberi Anda kemampuan untuk mencapai konsistensi pada tingkat workload di berbagai lingkungan yang menggunakan infrastruktur berbeda. Untuk mengetahui informasi selengkapnya, lihat arsitektur referensi lingkungan hybrid GKE Enterprise.
Pertimbangan desain
Pola cloud bursting berlaku untuk workload interaktif dan batch. Namun, saat menangani workload interaktif, Anda harus menentukan cara mendistribusikan permintaan di seluruh lingkungan:
Anda dapat merutekan permintaan pengguna yang masuk ke load balancer yang berjalan di pusat data yang ada, lalu meminta load balancer mendistribusikan permintaan di seluruh resource lokal dan cloud.
Pendekatan ini memerlukan load balancer atau sistem lain yang berjalan di pusat data yang ada untuk melacak juga resource yang dialokasikan di cloud. Load balancer atau sistem lainnya juga harus memulai peningkatan skala atau penurunan skala resource secara otomatis. Dengan pendekatan ini, Anda dapat menonaktifkan semua resource cloud selama periode aktivitas rendah. Namun, penerapan mekanisme untuk melacak resource dapat melebihi kemampuan solusi load balancer, sehingga meningkatkan kompleksitas secara keseluruhan.
Daripada menerapkan mekanisme untuk melacak resource, Anda dapat menggunakan Cloud Load Balancing dengan grup endpoint jaringan (NEG) konektivitas hybrid. Anda menggunakan load balancer ini untuk merutekan permintaan klien internal atau permintaan klien eksternal ke backend yang berada di infrastruktur lokal dan di Google Cloud, serta yang didasarkan pada berbagai metrik, seperti pemisahan traffic berdasarkan bobot. Anda juga dapat menskalakan backend berdasarkan kapasitas inferensi load balancing untuk workload di Google Cloud. Untuk mengetahui informasi selengkapnya, baca Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.
Pendekatan ini memiliki beberapa manfaat tambahan, seperti memanfaatkan kemampuan perlindungan DDoS Google Cloud Armor, WAF, dan penyimpanan cache konten di edge cloud menggunakan Cloud CDN. Namun, Anda perlu menyesuaikan konektivitas jaringan hybrid untuk menangani traffic tambahan.
Seperti yang dijelaskan dalam Portabilitas beban kerja, aplikasi mungkin dapat dipindahkan ke lingkungan yang berbeda dengan perubahan minimal untuk mencapai konsistensi beban kerja. Namun, bukan berarti aplikasi memiliki performa yang sama di kedua lingkungan. Perbedaan dalam komputasi dasar, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, beserta kedekatannya dengan layanan dependen, biasanya akan menentukan performa. Melalui pengujian, Anda dapat memiliki visibilitas yang lebih akurat dan memahami ekspektasi performa.
Anda dapat menggunakan layanan infrastruktur cloud untuk membangun lingkungan yang menghosting aplikasi Anda tanpa portabilitas. Gunakan pendekatan berikut untuk menangani permintaan klien saat traffic dialihkan selama waktu permintaan puncak:
- Gunakan alat yang konsisten untuk memantau dan mengelola kedua lingkungan ini.
- Pastikan pembuatan versi workload yang konsisten dan sumber data Anda adalah yang terkini.
- Anda mungkin perlu menambahkan otomatisasi untuk menyediakan lingkungan cloud dan mengubah rute traffic saat permintaan meningkat dan beban kerja cloud diperkirakan akan menerima permintaan klien untuk aplikasi Anda.
Jika Anda ingin menonaktifkan semua resource Google Cloud selama permintaan rendah, penggunaan kebijakan perutean DNS yang utamanya untuk load balancing traffic mungkin tidak selalu optimal. Hal ini utamanya karena:
- Resource mungkin memerlukan beberapa waktu untuk diinisialisasi sebelum dapat ditayangkan kepada pengguna.
- Pembaruan DNS cenderung disebarluaskan secara perlahan di internet.
Sebagai hasilnya:
- Pengguna mungkin dirutekan ke lingkungan Cloud meskipun tidak ada resource yang tersedia untuk memproses permintaan mereka.
- Pengguna mungkin tetap dirutekan ke lingkungan lokal untuk sementara, sementara update DNS diterapkan di seluruh internet.
Dengan Cloud DNS, Anda dapat memilih kebijakan DNS dan kebijakan perutean yang sesuai dengan arsitektur dan perilaku solusi Anda seperti kebijakan perutean DNS geolokasi. Cloud DNS juga mendukung health check untuk Load Balancer Jaringan passthrough internal, dan Load Balancer Aplikasi internal. Dalam hal ini, Anda dapat menyertakannya dengan keseluruhan konfigurasi DNS hybrid yang didasarkan pada pola ini.
Dalam beberapa skenario, Anda dapat menggunakan Cloud DNS untuk mendistribusikan permintaan klien dengan health check di Google Cloud, seperti saat menggunakan Load Balancer Aplikasi internal atau Load Balancer Aplikasi internal lintas region. Dalam skenario ini, Cloud DNS memeriksa respons keseluruhan Load Balancer Aplikasi internal, yang akan memeriksa respons instance backend secara otomatis. Untuk informasi selengkapnya, lihat Mengelola kebijakan pemilihan rute DNS dan health check.
Anda juga dapat menggunakan Cloud DNS split cakrawala. Split horizontal Cloud DNS adalah pendekatan untuk menyiapkan respons atau data DNS ke lokasi atau jaringan tertentu dari originator kueri DNS untuk nama domain yang sama. Pendekatan ini biasanya digunakan untuk memenuhi persyaratan saat aplikasi dirancang untuk menawarkan pengalaman pribadi dan publik, yang masing-masing memiliki fitur unik. Pendekatan ini juga membantu mendistribusikan beban traffic di seluruh lingkungan.
Dengan pertimbangan ini, cloud bursting umumnya lebih cocok untuk menangani banyak workload daripada workload interaktif.
Kelebihan
Keuntungan utama dari pola arsitektur cloud bursting meliputi:
- Dengan Cloud Bursting, Anda dapat menggunakan kembali investasi yang sudah ada di pusat data dan lingkungan komputasi pribadi. Penggunaan ulang ini dapat bersifat permanen atau berlaku hingga peralatan yang ada harus diganti. Setelah itu, Anda dapat mempertimbangkan migrasi penuh.
- Karena tidak perlu lagi mempertahankan kapasitas berlebih untuk memenuhi permintaan puncak, Anda mungkin dapat meningkatkan penggunaan dan efektivitas biaya lingkungan komputasi pribadi.
- Dengan Cloud Bursting, Anda dapat menjalankan tugas batch secara tepat waktu tanpa perlu menyediakan resource komputasi yang berlebihan.
Praktik terbaik
Saat menerapkan cloud bursting, pertimbangkan praktik terbaik berikut:
- Untuk memastikan workload yang berjalan di cloud dapat mengakses resource dengan cara yang sama seperti workload yang berjalan di lingkungan lokal, gunakan pola meshed dengan prinsip akses keamanan dengan hak istimewa terendah. Jika desain workload memungkinkannya, Anda hanya dapat mengizinkan akses dari cloud ke lingkungan komputasi lokal, bukan sebaliknya.
- Untuk meminimalkan latensi komunikasi antarlingkungan, pilih region Google Cloud yang secara geografis dekat dengan lingkungan komputasi pribadi Anda. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk pemilihan region Compute Engine.
- Saat menggunakan cloud bursting hanya untuk workload batch, kurangi permukaan serangan keamanan dengan menjaga kerahasiaan semua resource Google Cloud. Larang semua akses langsung dari internet ke resource ini, meskipun Anda menggunakan load balancing eksternal Google Cloud untuk menyediakan titik entri ke workload.
Pilih Kebijakan perutean dan kebijakan DNS yang sesuai dengan pola arsitektur Anda dan perilaku solusi yang ditargetkan.
- Sebagai bagian dari pola ini, Anda dapat menerapkan desain kebijakan DNS secara permanen atau saat memerlukan kapasitas tambahan menggunakan lingkungan lain selama waktu permintaan puncak.
- Anda dapat menggunakan kebijakan perutean DNS geolokasi untuk memiliki endpoint DNS global bagi load balancer regional. Taktik ini memiliki banyak kasus penggunaan untuk kebijakan perutean DNS geolokasi, termasuk aplikasi hybrid yang menggunakan Google Cloud bersama dengan deployment lokal yang mencakup region Google Cloud.
Jika perlu menyediakan data yang berbeda untuk kueri DNS yang sama, Anda dapat menggunakan DNS split cakrawala—misalnya, kueri dari klien internal dan eksternal.
Untuk mengetahui informasi lebih lanjut, lihat arsitektur referensi untuk DNS hybrid
Untuk memastikan perubahan DNS disebarkan dengan cepat, konfigurasikan DNS Anda dengan waktu aktif nilai yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby saat Anda memerlukan kapasitas tambahan menggunakan lingkungan cloud.
Untuk tugas yang tidak terlalu mendesak, dan tidak menyimpan data secara lokal, pertimbangkan untuk menggunakan instance Spot VM, yang jauh lebih murah daripada instance VM biasa. Namun, prasyaratnya adalah jika tugas VM di-preempt, sistem harus dapat memulai ulang tugas secara otomatis.
Gunakan container untuk mencapai portabilitas beban kerja jika berlaku. Selain itu, GKE Enterprise dapat menjadi teknologi pendukung utama untuk desain tersebut. Untuk mengetahui informasi selengkapnya, lihat arsitektur referensi lingkungan hybrid GKE Enterprise.
Pantau traffic apa pun yang dikirim dari Google Cloud ke lingkungan komputasi yang berbeda. Traffic ini dikenai biaya transfer data keluar.
Jika Anda berencana menggunakan arsitektur ini dalam jangka panjang dengan volume transfer data keluar yang tinggi, pertimbangkan untuk menggunakan Cloud Interconnect. Cloud Interconnect dapat membantu mengoptimalkan performa konektivitas dan dapat mengurangi biaya transfer data keluar untuk traffic yang memenuhi kondisi tertentu. Untuk mengetahui informasi selengkapnya, lihat harga Cloud Interconnect.
Saat Cloud Load Balancing digunakan, Anda harus menggunakan kemampuan pengoptimalan kapasitas aplikasi jika memungkinkan. Cara ini dapat membantu Anda mengatasi beberapa tantangan kapasitas yang dapat terjadi pada aplikasi yang didistribusikan secara global.
Lakukan autentikasi orang yang menggunakan sistem Anda dengan menetapkan identitas umum antarlingkungan, sehingga sistem dapat melakukan autentikasi dengan aman melintasi batas lingkungan.
Untuk melindungi informasi sensitif, sangat direkomendasikan untuk mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan pada lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN HA melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.