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 mengandalkan deployment aplikasi yang redundan di beberapa lingkungan komputasi. Tujuannya adalah untuk meningkatkan kapasitas, ketahanan, atau keduanya.
Meskipun Anda dapat mengakomodasi workload yang penuh burst di lingkungan komputasi berbasis pusat data dengan menyediakan 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.
Dalam diagram sebelumnya, saat kapasitas data mencapai batasnya di lingkungan pribadi lokal, sistem dapat memperoleh kapasitas tambahan dari lingkunganGoogle Cloud jika diperlukan.
Pendorong utama pola ini adalah menghemat biaya serta 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 melakukan penyediaan berlebih pada infrastruktur. Sebagai gantinya, Anda dapat memanfaatkan resource cloud sesuai permintaan dan menskalakannya agar sesuai dengan permintaan, serta metrik yang telah ditentukan sebelumnya. Dengan demikian, 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 workload di berbagai lingkungan yang menggunakan infrastruktur yang 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 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 melacak resource yang dialokasikan di cloud. Load balancer atau sistem lain juga harus memulai peningkatan atau penurunan skala resource secara otomatis. Dengan menggunakan pendekatan ini, Anda dapat menonaktifkan semua resource cloud selama masa aktivitas rendah. Namun, penerapan 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 berada di lokal dan di Google Cloud dan yang didasarkan pada metrik yang berbeda, seperti pemisahan traffic berbasis bobot. Anda juga dapat menskalakan backend berdasarkan kapasitas penyajian 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 Google Cloud Armor, WAF, dan menyimpan konten ke dalam cache di edge cloud menggunakan Cloud CDN. Namun, Anda perlu mengukur konektivitas jaringan hybrid untuk menangani traffic tambahan.
Seperti yang dijelaskan dalam Portabilitas workload, aplikasi mungkin portabel ke lingkungan yang berbeda dengan perubahan minimal untuk mencapai konsistensi workload, tetapi itu tidak berarti bahwa aplikasi berperforma sama baiknya di kedua lingkungan. Perbedaan dalam komputasi yang mendasarinya, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, serta kedekatan dengan layanan dependen, biasanya menentukan performa. Melalui pengujian, Anda dapat memperoleh visibilitas yang lebih akurat dan memahami ekspektasi performa.
Anda dapat menggunakan layanan infrastruktur cloud untuk membangun lingkungan guna 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 versi beban kerja konsisten dan sumber data Anda sudah terbaru.
- 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 Google Cloud resource selama masa permintaan rendah, penggunaan kebijakan perutean DNS terutama untuk load balancing traffic mungkin tidak selalu optimal. Hal ini terutama karena:
- Resource mungkin memerlukan waktu untuk diinisialisasi sebelum dapat melayani pengguna.
- Perubahan DNS cenderung disebarkan secara perlahan di internet.
Sebagai hasilnya:
- Pengguna mungkin dirutekan ke lingkungan Cloud meskipun tidak ada resource yang tersedia untuk memproses permintaan mereka.
- Pengguna mungkin terus dialihkan ke lingkungan lokal untuk sementara saat 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 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 aktif 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 sendiri memeriksa kondisi instance backend. Untuk mengetahui informasi selengkapnya, lihat Mengelola kebijakan perutean DNS dan health check.
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 asal kueri DNS untuk nama domain yang sama. Pendekatan ini biasanya digunakan untuk memenuhi 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 mempertimbangkan hal 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 Anda.
- 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 memungkinkan, Anda dapat mengizinkan akses hanya dari cloud ke lingkungan komputasi lokal, bukan sebaliknya.
- Untuk meminimalkan latensi komunikasi antarlingkungan, pilih Google Cloud region 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 Google Cloud resource. Jangan izinkan akses langsung dari internet ke resource ini, meskipun Anda menggunakan load balancing eksternal untuk menyediakan titik entri ke workload. Google Cloud
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 bagi load balancer regional Anda. Taktik ini memiliki banyak kasus penggunaan untuk kebijakan perutean DNS geolokasi, termasuk aplikasi hybrid yang menggunakan Google Cloud bersama deployment lokal di mana region Google Cloud ada. Google Cloud Google Cloud
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 mengetahui informasi selengkapnya, lihat arsitektur referensi untuk DNS hybrid
Untuk memastikan perubahan DNS diterapkan dengan cepat, konfigurasikan DNS Anda dengan nilai time to live yang cukup singkat agar Anda dapat mengalihkan pengguna ke sistem standby saat Anda memerlukan kapasitas ekstra menggunakan lingkungan cloud.
Untuk tugas yang tidak terlalu dibatasi waktu, dan tidak menyimpan data secara lokal, pertimbangkan penggunaan 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 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 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 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 berlaku. Dengan melakukannya, Anda dapat mengatasi beberapa tantangan kapasitas yang dapat terjadi dalam aplikasi yang didistribusikan secara global.
Lakukan autentikasi terhadap orang yang menggunakan sistem Anda dengan membangun 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 hibrida yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.