Aplikasi internet dapat mengalami fluktuasi penggunaan yang ekstrem. Meskipun sebagian besar aplikasi perusahaan tidak menghadapi tantangan ini, banyak perusahaan harus berurusan dengan berbagai jenis workload yang penuh burst: tugas batch atau CI/CD.
Pola arsitektur ini bergantung pada deployment aplikasi yang redundan di beberapa lingkungan komputasi. Sasarannya adalah meningkatkan kapasitas, ketahanan, atau keduanya.
Meskipun Anda dapat mengakomodasi workload yang penuh 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 memaksimalkan eksekusinya selama jangka waktu yang lebih lama, meskipun penundaan tugas tidak praktis jika tugas tersebut dibatasi waktu.
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.
Pada diagram sebelumnya, saat kapasitas data mencapai batasnya di lingkungan lokal, sistem dapat memperoleh kapasitas tambahan dari lingkungan Google Cloud jika diperlukan.
Pendorong utama pola ini adalah menghemat biaya dan mengurangi waktu serta 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, dan metrik yang telah ditentukan. Akibatnya, perusahaan Anda dapat menghindari gangguan layanan selama waktu permintaan puncak.
Persyaratan potensial untuk skenario cloud bursting adalah portabilitas workload. Jika Anda mengizinkan workload di-deploy ke beberapa lingkungan, Anda harus menghilangkan perbedaan antarlingkungan. Misalnya, Kubernetes memberi Anda kemampuan untuk mencapai konsistensi di tingkat beban kerja di berbagai lingkungan yang menggunakan infrastruktur yang berbeda. Untuk 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 mengarahkan 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 juga melacak resource yang dialokasikan di cloud. Load balancer atau sistem lain juga harus memulai peningkatan atau penurunan skala resource secara otomatis. Dengan pendekatan ini, Anda dapat menonaktifkan semua resource cloud selama masa aktivitas rendah. Namun, menerapkan mekanisme untuk melacak resource dapat melebihi kemampuan solusi load balancer Anda, sehingga meningkatkan kompleksitas secara keseluruhan.
Daripada menerapkan mekanisme untuk melacak resource, Anda dapat menggunakan Cloud Load Balancing dengan backend grup endpoint jaringan (NEG) konektivitas hybrid. Anda menggunakan load balancer ini untuk merutekan permintaan klien internal atau permintaan klien eksternal ke backend yang terletak di lokasi dan di Google Cloud dan didasarkan pada metrik yang berbeda, seperti pemisahan traffic berbasis bobot. Anda juga dapat menskalakan backend berdasarkan kapasitas penyaluran load balancing untuk workload di Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.
Pendekatan ini memiliki beberapa manfaat tambahan, seperti memanfaatkan kemampuan perlindungan DDoS, WAF, dan menyimpan konten ke dalam cache di edge cloud menggunakan Cloud CDN. Namun, Anda perlu menentukan ukuran konektivitas jaringan hybrid untuk menangani traffic tambahan.
Seperti yang disoroti dalam Portabilitas beban kerja, aplikasi mungkin dapat ditransfer ke lingkungan yang berbeda dengan perubahan minimal untuk mencapai konsistensi beban kerja, tetapi itu tidak berarti bahwa aplikasi berperforma sama di kedua lingkungan. Perbedaan komputasi yang mendasarinya, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, beserta kedekatan dengan layanan dependen, biasanya menentukan performa. Melalui pengujian, Anda dapat memiliki visibilitas yang lebih akurat dan memahami harapan performa.
Anda dapat menggunakan layanan infrastruktur cloud untuk membuat lingkungan guna menghosting aplikasi 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 beban kerja yang konsisten dan bahwa sumber data Anda aktual.
- Anda mungkin perlu menambahkan otomatisasi untuk menyediakan lingkungan cloud dan mengalihkan traffic saat permintaan meningkat dan workload cloud diharapkan menerima permintaan klien untuk aplikasi Anda.
Jika Anda ingin menonaktifkan semua resource Google Cloud selama masa permintaan rendah, menggunakan kebijakan perutean DNS terutama untuk load balancing traffic mungkin tidak selalu optimal. Hal ini terutama karena:
- Resource mungkin memerlukan waktu beberapa saat untuk melakukan inisialisasi sebelum dapat melayani pengguna.
- Pembaruan DNS cenderung disebarkan secara perlahan melalui internet.
Sebagai hasilnya:
- Pengguna mungkin diarahkan ke lingkungan Cloud meskipun tidak ada resource yang tersedia untuk memproses permintaan mereka.
- Pengguna mungkin terus dirutekan ke lingkungan lokal sementara waktu saat update DNS diterapkan di seluruh internet.
Dengan Cloud DNS, Anda dapat memilih kebijakan DNS dan kebijakan perutean yang selaras 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 menggabungkannya dengan penyiapan DNS hibrida keseluruhan 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 kondisi keseluruhan Load Balancer Aplikasi internal, yang juga memeriksa kondisi instance backend. Untuk mengetahui informasi selengkapnya, lihat Mengelola kebijakan perutean dan health check DNS.
Anda juga dapat menggunakan split horizon Cloud DNS. Split horizon 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 mengatasi persyaratan saat aplikasi dirancang untuk menawarkan pengalaman pribadi dan publik, masing-masing dengan fitur unik. Pendekatan ini juga membantu mendistribusikan beban traffic di seluruh lingkungan.
Dengan pertimbangan ini, cloud bursting secara umum lebih baik untuk workload batch daripada workload interaktif.
Kelebihan
Keuntungan utama pola arsitektur cloud bursting meliputi:
- Cloud bursting memungkinkan Anda menggunakan kembali investasi yang ada di pusat data dan lingkungan komputasi pribadi. Penggunaan ulang ini dapat bersifat permanen atau berlaku hingga peralatan yang ada harus diganti, dan pada tahap ini Anda dapat mempertimbangkan migrasi penuh.
- Karena Anda 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 bahwa workload yang berjalan di cloud dapat mengakses resource dengan cara yang sama seperti workload yang berjalan di lingkungan lokal, gunakan pola mesh dengan prinsip akses keamanan hak istimewa terendah. Jika desain workload memungkinkannya, Anda dapat mengizinkan akses hanya dari cloud ke lingkungan komputasi on-premise, 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. Jangan izinkan akses langsung dari internet ke resource ini, meskipun Anda menggunakan load balancing eksternal Google Cloud untuk menyediakan titik entri ke beban kerja.
Pilih kebijakan DNS dan kebijakan perutean yang sesuai dengan pola arsitektur dan perilaku solusi yang ditargetkan.
- Sebagai bagian dari pola ini, Anda dapat menerapkan desain kebijakan DNS secara permanen atau saat Anda memerlukan kapasitas tambahan menggunakan lingkungan lain selama waktu permintaan puncak.
- Anda dapat menggunakan kebijakan perutean DNS geolokasi untuk memiliki endpoint DNS global untuk load balancer regional. Taktik ini memiliki banyak kasus penggunaan untuk kebijakan perutean DNS geolokasi, termasuk aplikasi campuran yang menggunakan Google Cloud bersama dengan deployment lokal tempat region Google Cloud berada.
Jika perlu memberikan data yang berbeda untuk kueri DNS yang sama, Anda dapat menggunakan DNS split horizon—misalnya, kueri dari klien internal dan eksternal.
Untuk informasi selengkapnya, lihat arsitektur referensi untuk DNS campuran
Untuk memastikan perubahan DNS diterapkan dengan cepat, konfigurasikan DNS Anda dengan nilai time to live yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby saat Anda memerlukan kapasitas tambahan menggunakan lingkungan cloud.
Untuk tugas yang tidak terlalu dibatasi waktu, dan tidak menyimpan data secara lokal, pertimbangkan untuk menggunakan instance Spot VM, yang jauh lebih murah dibandingkan instance VM biasa. Namun, prasyaratnya adalah jika tugas VM di-preempt, sistem harus dapat memulai ulang tugas secara otomatis.
Gunakan container untuk mencapai portabilitas workload jika berlaku. Selain itu, GKE Enterprise dapat menjadi teknologi utama yang memungkinkan desain tersebut. Untuk 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 akan 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 mungkin 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 berlaku. Tindakan ini dapat membantu Anda mengatasi beberapa tantangan kapasitas yang dapat terjadi dalam aplikasi yang didistribusikan secara global.
Lakukan autentikasi terhadap orang yang menggunakan sistem Anda dengan membuat identitas bersama antarlingkungan sehingga sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.
Untuk melindungi informasi sensitif, sangat disarankan untuk mengenkripsi semua komunikasi selama pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas campuran yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.