Pola arsitektur hybrid dan multi-cloud

Last reviewed 2023-12-14 UTC

Halaman ini memberikan tampilan satu halaman dari semua halaman di Mem-build arsitektur hybrid dan multi-cloud menggunakan Google Cloud. Anda dapat mencetak halaman ini, atau menyimpannya dalam format PDF menggunakan fungsi cetak browser dan memilih opsi Simpan sebagai PDF. Halaman ini tidak menyediakan panel daftar isi (Daftar Isi) di sisi kanan.

Dokumen ini adalah dokumen kedua dari tiga dokumen dalam satu set. Bagian ini membahas pola arsitektur hybrid dan multi-cloud yang umum. Halaman ini juga menjelaskan skenario yang paling cocok untuk pola ini. Terakhir, dokumen ini memberikan praktik terbaik yang dapat Anda gunakan saat men-deploy arsitektur tersebut di Google Cloud.

Kumpulan dokumen untuk pola arsitektur hybrid dan multi-cloud terdiri dari bagian berikut:

• Membangun arsitektur hybrid dan multicloud: membahas perencanaan strategi untuk merancang penyiapan hybrid dan multicloud dengan Google Cloud.
• Pola arsitektur hybrid dan multi-cloud: membahas pola arsitektur umum yang akan diadopsi sebagai bagian dari strategi hybrid dan multi-cloud (dokumen ini).
• Pola arsitektur jaringan hybrid dan multicloud yang aman: membahas pola arsitektur jaringan hybrid dan multicloud dari perspektif jaringan.

Setiap perusahaan memiliki portofolio unik tentang workload aplikasi yang menempatkan persyaratan dan batasan pada arsitektur penyiapan hybrid atau multicloud. Meskipun harus mendesain dan menyesuaikan arsitektur untuk memenuhi batasan dan persyaratan ini, Anda dapat mengandalkan beberapa pola umum untuk menentukan arsitektur dasar.

Pola arsitektur adalah cara berulang untuk menyusun beberapa komponen fungsional dari solusi teknologi, aplikasi, atau layanan untuk membuat solusi yang dapat digunakan kembali yang memenuhi persyaratan atau kasus penggunaan tertentu. Solusi teknologi berbasis cloud sering kali terdiri dari beberapa layanan cloud yang berbeda dan terdistribusi. Layanan ini berkolaborasi untuk memberikan fungsi yang diperlukan. Dalam konteks ini, setiap layanan dianggap sebagai komponen fungsional dari solusi teknologi. Demikian pula, aplikasi dapat terdiri dari beberapa tingkat, modul, atau layanan fungsional, dan masing-masing dapat mewakili komponen fungsional arsitektur aplikasi. Arsitektur semacam itu dapat diseragamkan untuk menangani kasus penggunaan bisnis tertentu dan berfungsi sebagai pola dasar yang dapat digunakan kembali.

Untuk menentukan pola arsitektur secara umum untuk aplikasi atau solusi, identifikasi dan tentukan hal berikut:

• Komponen solusi atau aplikasi.
• Fungsi yang diharapkan untuk setiap komponen—misalnya, fungsi frontend untuk menyediakan antarmuka pengguna grafis atau fungsi backend untuk menyediakan akses data.
• Cara komponen berkomunikasi satu sama lain dan dengan sistem atau pengguna eksternal. Dalam aplikasi modern, komponen ini berinteraksi melalui antarmuka atau API yang jelas. Ada berbagai model komunikasi seperti asinkron dan sinkron, permintaan-respons, atau berbasis antrean.

Berikut adalah dua kategori utama pola arsitektur hybrid dan multicloud:

• Pola arsitektur terdistribusi: Pola ini mengandalkan deployment terdistribusi beban kerja atau komponen aplikasi. Artinya, pola ini menjalankan aplikasi (atau komponen tertentu dari aplikasi tersebut) di lingkungan komputasi yang paling sesuai dengan pola. Dengan demikian, pola dapat memanfaatkan berbagai properti dan karakteristik lingkungan komputasi yang terdistribusi dan saling terhubung.
• Pola arsitektur redundan: Pola ini didasarkan pada deployment workload yang redundan. Dalam pola ini, Anda men-deploy aplikasi yang sama dan komponennya di beberapa lingkungan komputasi. Tujuannya adalah untuk meningkatkan kapasitas performa atau ketahanan aplikasi, atau mereplikasi lingkungan yang ada untuk pengembangan dan pengujian.

Saat menerapkan pola arsitektur yang dipilih, Anda harus menggunakan arketipe deployment yang sesuai. Arketip deployment bersifat zonal, regional, multi-regional, atau global. Pemilihan ini membentuk dasar untuk membuat arsitektur deployment khusus aplikasi. Setiap arketipe deployment menentukan kombinasi domain kegagalan tempat aplikasi dapat beroperasi. Domain kegagalan ini dapat mencakup satu atau beberapa zona atau region Google Cloud, dan dapat diperluas untuk menyertakan pusat data lokal atau domain kegagalan Anda di penyedia cloud lainnya.

Seri ini berisi halaman berikut:

• Pola arsitektur terdistribusi

  • Pola hybrid bertingkat

  • Pola multi-cloud yang dipartisi

  • Pola hybrid dan multicloud analisis

  • Pola edge hybrid

• Pola arsitektur redundan

  • Pola hybrid lingkungan
  • Pola hybrid dan multicloud kelangsungan bisnis
  • Pola cloud bursting

Kontributor

Penulis: Marwan Al Shawi | Partner Customer Engineer

Kontributor lainnya:

• Saud Albazei | Customer Engineer, Application Modernization
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• Mark Schlagenhauf | Technical Writer, Networking
• Daniel Strebel | EMEA Solution Lead, Application Modernization
• Ammett Williams | Developer Relations Engineer

Pola arsitektur terdistribusi

Saat bermigrasi dari lingkungan komputasi non-hybrid atau non-multicloud ke arsitektur hybrid atau multicloud, pertimbangkan terlebih dahulu batasan aplikasi yang ada dan bagaimana batasan tersebut dapat menyebabkan kegagalan aplikasi. Pertimbangan ini menjadi lebih penting saat aplikasi atau komponen aplikasi Anda beroperasi secara terdistribusi di berbagai lingkungan. Setelah mempertimbangkan batasan, buat rencana untuk menghindari atau mengatasinya. Pastikan untuk mempertimbangkan kemampuan unik dari setiap lingkungan komputasi dalam arsitektur terdistribusi.

Catatan: Anda dapat menerapkan pola arsitektur yang berbeda ke aplikasi yang berbeda, berdasarkan kasus penggunaan dan persyaratannya. Artinya, Anda mungkin memiliki beberapa aplikasi dengan pola arsitektur hybrid dan multicloud yang berbeda yang beroperasi secara bersamaan.

Pertimbangan desain

Pertimbangan desain berikut berlaku untuk pola deployment terdistribusi. Bergantung pada solusi target dan tujuan bisnis, prioritas dan dampak dari setiap pertimbangan dapat bervariasi.

Latensi

Dalam pola arsitektur apa pun yang mendistribusikan komponen aplikasi (frontend, backend, atau microservice) di berbagai lingkungan komputasi, latensi komunikasi dapat terjadi. Latensi ini dipengaruhi oleh konektivitas jaringan hybrid (Cloud VPN dan Cloud Interconnect) dan jarak geografis antara situs lokal dan region cloud, atau antara region cloud dalam penyiapan multi-cloud. Oleh karena itu, penting untuk menilai persyaratan latensi aplikasi Anda dan sensitivitasnya terhadap penundaan jaringan. Aplikasi yang dapat mentolerir latensi adalah kandidat yang lebih cocok untuk deployment terdistribusi awal di lingkungan hybrid atau multicloud.

Arsitektur status sementara versus akhir

Untuk menentukan ekspektasi dan potensi implikasi apa pun terhadap biaya, skala, dan performa, penting untuk menganalisis jenis arsitektur yang Anda butuhkan dan durasi yang diinginkan sebagai bagian dari tahap perencanaan. Misalnya, jika Anda berencana untuk menggunakan arsitektur hybrid atau multi-cloud dalam waktu lama atau secara permanen, sebaiknya pertimbangkan untuk menggunakan Cloud Interconnect. Untuk mengurangi biaya transfer data keluar dan mengoptimalkan performa jaringan konektivitas campuran, Cloud Interconnect memberikan diskon biaya transfer data keluar yang memenuhi kondisi tarif transfer data yang didiskon.

Keandalan

Keandalan adalah pertimbangan utama saat merancang arsitektur sistem IT. Ketersediaan waktu aktif adalah aspek penting dari keandalan sistem. Di Google Cloud, Anda dapat meningkatkan ketahanan aplikasi dengan men-deploy komponen redundan aplikasi tersebut di beberapa zona dalam satu region, atau di beberapa region, dengan kemampuan pengalihan. Redundansi adalah salah satu elemen utama untuk meningkatkan ketersediaan aplikasi secara keseluruhan. Untuk aplikasi dengan penyiapan terdistribusi di seluruh lingkungan hybrid dan multicloud, penting untuk mempertahankan tingkat ketersediaan yang konsisten.

Untuk meningkatkan ketersediaan sistem di lingkungan lokal, atau di lingkungan cloud lainnya, pertimbangkan redundansi hardware atau software—dengan mekanisme failover—yang Anda perlukan untuk aplikasi dan komponennya. Idealnya, Anda harus mempertimbangkan ketersediaan layanan atau aplikasi di berbagai komponen dan infrastruktur pendukung (termasuk ketersediaan konektivitas hybrid) di semua lingkungan. Konsep ini juga disebut sebagai ketersediaan komposit aplikasi atau layanan.

Berdasarkan dependensi antar-komponen atau layanan, ketersediaan komposit untuk aplikasi mungkin lebih tinggi atau lebih rendah daripada untuk layanan atau komponen individual. Untuk informasi selengkapnya, lihat Ketersediaan gabungan: menghitung ketersediaan keseluruhan infrastruktur cloud.

Untuk mencapai tingkat keandalan sistem yang Anda inginkan, tentukan metrik keandalan yang jelas dan desain aplikasi untuk melakukan perbaikan mandiri dan bertahan dari gangguan secara efektif di berbagai lingkungan. Untuk membantu Anda menentukan cara yang sesuai untuk mengukur pengalaman pelanggan terhadap layanan Anda, lihat Menentukan sasaran keandalan.

Konektivitas hybrid dan multi-cloud

Persyaratan komunikasi antara komponen aplikasi terdistribusi akan memengaruhi pilihan Anda untuk opsi konektivitas jaringan hybrid. Setiap opsi konektivitas memiliki kelebihan dan kekurangan, serta driver tertentu yang perlu dipertimbangkan, seperti biaya, volume traffic, keamanan, dan sebagainya. Untuk informasi selengkapnya, lihat bagian pertimbangan desain konektivitas.

Kemudahan dikelola

Alat pengelolaan dan pemantauan yang konsisten dan terpadu sangat penting untuk menyukseskan penyiapan hybrid dan multicloud (dengan atau tanpa portabilitas workload). Dalam jangka pendek, alat ini dapat menambah biaya pengembangan, pengujian, dan operasi. Secara teknis, semakin banyak penyedia cloud yang Anda gunakan, maka semakin rumit pula pengelolaan lingkungan Anda. Sebagian besar vendor cloud publik tidak hanya memiliki berbagai fitur, tetapi juga memiliki berbagai alat, SLA, dan API untuk mengelola layanan cloud. Oleh karena itu, pertimbangkan keunggulan strategis arsitektur yang Anda pilih dengan potensi kompleksitas jangka pendek versus manfaat jangka panjang.

Biaya

Setiap penyedia layanan cloud di lingkungan multicloud memiliki metrik dan alat penagihannya sendiri. Untuk memberikan visibilitas dan dasbor terpadu yang lebih baik, pertimbangkan untuk menggunakan alat pengelolaan dan pengoptimalan biaya multi-cloud. Misalnya, saat membuat solusi cloud-first di beberapa lingkungan cloud, produk, harga, diskon, dan alat pengelolaan setiap penyedia dapat menyebabkan inkonsistensi biaya di antara lingkungan tersebut.

Sebaiknya gunakan satu metode yang telah teruji dengan baik untuk menghitung biaya penuh resource cloud, dan untuk memberikan visibilitas biaya. Visibilitas biaya sangat penting untuk pengoptimalan biaya. Misalnya, dengan menggabungkan data penagihan dari penyedia cloud yang Anda gunakan dan menggunakan Looker Cloud Cost Management Block Google Cloud, Anda dapat membuat tampilan terpusat untuk biaya multicloud. Tampilan ini dapat membantu memberikan tampilan pelaporan gabungan tentang pembelanjaan Anda di beberapa cloud. Untuk mengetahui informasi selengkapnya, lihat Strategi untuk mengoptimalkan pengelolaan biaya penagihan cloud secara efektif.

Sebaiknya gunakan praktik FinOps untuk membuat biaya terlihat. Sebagai bagian dari praktik FinOps yang kuat, tim pusat dapat mendelegasikan pengambilan keputusan untuk pengoptimalan resource kepada tim lain yang terlibat dalam project untuk mendorong akuntabilitas individu. Dalam model ini, tim pusat harus menstandarkan proses, pelaporan, dan alat untuk pengoptimalan biaya. Untuk mengetahui informasi selengkapnya tentang berbagai aspek pengoptimalan biaya dan rekomendasi yang harus Anda pertimbangkan, lihat Framework Arsitektur Google Cloud: Pengoptimalan biaya.

Perpindahan data

Pergerakan data adalah pertimbangan penting untuk strategi dan perencanaan arsitektur hybrid dan multicloud, terutama untuk sistem terdistribusi. Perusahaan perlu mengidentifikasi berbagai kasus penggunaan bisnis mereka, data yang mendukungnya, dan cara data diklasifikasikan (untuk industri yang diatur). Mereka juga harus mempertimbangkan bagaimana penyimpanan, berbagi, dan akses data untuk sistem terdistribusi di seluruh lingkungan dapat memengaruhi performa aplikasi dan konsistensi data. Faktor-faktor tersebut dapat memengaruhi aplikasi dan arsitektur pipeline data. Kumpulan lengkap opsi pemindahan data Google Cloud memungkinkan bisnis memenuhi kebutuhan spesifik mereka dan mengadopsi arsitektur hibrida dan multi-cloud tanpa mengorbankan kesederhanaan, efisiensi, atau performa.

Keamanan

Saat memigrasikan aplikasi ke cloud, penting untuk mempertimbangkan kemampuan keamanan cloud-first seperti konsistensi, visibilitas, dan visibilitas keamanan terpadu. Setiap penyedia cloud publik memiliki pendekatan, praktik terbaik, dan kemampuan keamanannya sendiri. Penting untuk menganalisis dan menyelaraskan kemampuan ini untuk membangun arsitektur keamanan standar dan fungsional. Kontrol IAM yang kuat, enkripsi data, pemindaian kerentanan, dan kepatuhan terhadap peraturan industri juga merupakan aspek penting dari keamanan cloud.

Saat merencanakan strategi migrasi, sebaiknya analisis pertimbangan yang disebutkan sebelumnya. Hal ini dapat membantu Anda meminimalkan kemungkinan memunculkan kompleksitas pada arsitektur seiring meningkatnya aplikasi atau volume traffic. Selain itu, mendesain dan membuat zona landing hampir selalu menjadi prasyarat untuk men-deploy workload perusahaan di lingkungan cloud. Zona landing membantu perusahaan Anda men-deploy, menggunakan, dan menskalakan layanan cloud dengan lebih aman di beberapa area dan mencakup berbagai elemen, seperti identitas, pengelolaan resource, keamanan, dan jaringan. Untuk informasi selengkapnya, lihat Desain zona landing di Google Cloud.

Dokumen berikut dalam rangkaian ini menjelaskan pola arsitektur terdistribusi lainnya:

• Pola hybrid bertingkat
• Pola multi-cloud yang dipartisi
• Pola hybrid dan multicloud Analytics
• Pola edge hybrid

Pola hybrid bertingkat

Komponen arsitektur aplikasi dapat dikategorikan sebagai frontend atau backend. Dalam beberapa skenario, komponen ini dapat dihosting untuk beroperasi dari lingkungan komputasi yang berbeda. Sebagai bagian dari pola arsitektur hybrid bertingkat, lingkungan komputasi berada di lingkungan komputasi pribadi di infrastruktur lokal dan di Google Cloud.

Komponen aplikasi frontend secara langsung diekspos ke pengguna atau perangkat akhir. Akibatnya, aplikasi ini sering kali sensitif terhadap performa. Untuk mengembangkan fitur dan peningkatan baru, update software dapat dilakukan secara rutin. Karena aplikasi frontend biasanya mengandalkan aplikasi backend untuk menyimpan dan mengelola data—dan mungkin logika bisnis serta pemrosesan input pengguna—aplikasi tersebut sering kali stateless atau hanya mengelola volume data yang terbatas.

Agar dapat diakses dan digunakan, Anda dapat mem-build aplikasi frontend dengan berbagai framework dan teknologi. Beberapa faktor utama untuk aplikasi frontend yang berhasil mencakup performa aplikasi, kecepatan respons, dan kompatibilitas browser.

Komponen aplikasi backend biasanya berfokus pada penyimpanan dan pengelolaan data. Dalam beberapa arsitektur, logika bisnis dapat digabungkan dalam komponen backend. Rilis baru aplikasi backend cenderung lebih jarang dibandingkan rilis untuk aplikasi frontend. Aplikasi backend memiliki tantangan berikut untuk dikelola:

• Menangani permintaan dalam jumlah besar
• Menangani volume data yang besar
• Mengamankan data
• Mempertahankan data terbaru dan yang diperbarui di semua replika sistem

Arsitektur aplikasi tiga tingkat adalah salah satu implementasi yang paling populer untuk membuat aplikasi web bisnis, seperti situs e-commerce yang berisi berbagai komponen aplikasi. Arsitektur ini berisi tingkatan berikut. Setiap tingkat beroperasi secara independen, tetapi saling terkait erat dan semuanya berfungsi bersama.

• Tingkat presentasi dan frontend web
• Tingkat aplikasi
• Akses data atau tingkat backend

Menempatkan lapisan ini ke dalam penampung akan memisahkan kebutuhan teknisnya, seperti persyaratan penskalaan, dan membantu memigrasikannya dalam pendekatan bertahap. Selain itu, layanan ini memungkinkan Anda men-deploynya di layanan cloud yang tidak bergantung pada platform yang dapat di-porting di seluruh lingkungan, menggunakan pengelolaan otomatis, dan diskalakan dengan platform terkelola cloud, seperti Cloud Run atau edisi Enterprise Google Kubernetes Engine (GKE). Selain itu, database terkelola Google Cloud seperti Cloud SQL membantu menyediakan backend sebagai lapisan database.

Catatan: Penerapan arsitektur ini dan definisi komponennya dapat bervariasi, bergantung pada apakah Anda memisahkan tingkat ke dalam sistem dan lapisan individual atau menggabungkannya.

Pola arsitektur hybrid bertingkat berfokus pada deployment komponen aplikasi frontend yang ada ke cloud publik. Dalam pola ini, Anda menyimpan komponen aplikasi backend yang ada di lingkungan komputasi pribadinya. Bergantung pada skala dan desain spesifik aplikasi, Anda dapat memigrasikan komponen aplikasi frontend kasus per kasus. Untuk mengetahui informasi selengkapnya, lihat Bermigrasi ke Google Cloud.

Jika Anda sudah memiliki aplikasi dengan komponen backend dan frontend yang dihosting di lingkungan lokal, pertimbangkan batas arsitektur saat ini. Misalnya, seiring aplikasi Anda diskalakan dan permintaan terhadap performa dan keandalannya meningkat, Anda harus mulai mengevaluasi apakah bagian aplikasi harus difaktorkan ulang atau dipindahkan ke arsitektur yang berbeda dan lebih optimal. Pola arsitektur hybrid bertingkat memungkinkan Anda memindahkan beberapa beban kerja dan komponen aplikasi ke cloud sebelum melakukan transisi lengkap. Anda juga harus mempertimbangkan biaya, waktu, dan risiko yang terlibat dalam migrasi tersebut.

Diagram berikut menunjukkan pola arsitektur hybrid bertingkat yang umum.

Pada diagram sebelumnya, permintaan klien dikirim ke frontend aplikasi yang dihosting di Google Cloud. Sebagai gantinya, frontend aplikasi mengirim data kembali ke lingkungan lokal tempat backend aplikasi dihosting (idealnya melalui gateway API).

Dengan pola arsitektur hybrid berlapis, Anda dapat memanfaatkan infrastruktur dan layanan global Google Cloud, seperti yang ditunjukkan dalam contoh arsitektur dalam diagram berikut. Frontend aplikasi dapat dijangkau melalui Google Cloud. Hal ini juga dapat menambahkan elastisitas ke frontend dengan menggunakan penskalaan otomatis untuk merespons permintaan penskalaan secara dinamis dan efisien tanpa kelebihan penyediaan infrastruktur. Ada berbagai arsitektur yang dapat Anda gunakan untuk mem-build dan menjalankan aplikasi web skalabel di Google Cloud. Setiap arsitektur memiliki kelebihan dan kekurangan untuk persyaratan yang berbeda.

Untuk informasi selengkapnya, tonton Tiga cara menjalankan aplikasi web skalabel di Google Cloud di YouTube. Untuk mempelajari lebih lanjut berbagai cara memodernisasi platform e-commerce Anda di Google Cloud, lihat Cara membangun platform commerce digital di Google Cloud.

Pada diagram sebelumnya, frontend aplikasi dihosting di Google Cloud untuk memberikan pengalaman pengguna multi-regional dan yang dioptimalkan secara global yang menggunakan load balancing, autoscaling, dan perlindungan DDoS global melalui Google Cloud Armor.

Seiring waktu, jumlah aplikasi yang Anda deploy ke cloud publik mungkin akan meningkat hingga Anda dapat mempertimbangkan untuk memindahkan komponen aplikasi backend ke cloud publik. Jika Anda memperkirakan akan melayani traffic yang berat, memilih layanan yang dikelola cloud dapat membantu Anda menghemat upaya engineering saat mengelola infrastruktur Anda sendiri. Pertimbangkan opsi ini kecuali jika batasan atau persyaratan mewajibkan hosting komponen aplikasi backend di infrastruktur lokal. Misalnya, jika data backend Anda tunduk pada pembatasan peraturan, Anda mungkin perlu menyimpan data tersebut di lokal. Namun, jika berlaku dan mematuhi kebijakan, menggunakan kemampuan Perlindungan Data Sensitif seperti teknik de-identifikasi, dapat membantu Anda memindahkan data tersebut jika diperlukan.

Dalam pola arsitektur hybrid bertingkat, Anda juga dapat menggunakan Google Distributed Cloud dalam beberapa skenario. Distributed Cloud memungkinkan Anda menjalankan cluster Google Kubernetes Engine pada hardware khusus yang disediakan dan dikelola oleh Google dan terpisah dari pusat data Google Cloud. Untuk memastikan bahwa Distributed Cloud memenuhi persyaratan saat ini dan mendatang, ketahui batasan Distributed Cloud jika dibandingkan dengan zona GKE berbasis cloud konvensional.

Kelebihan

Berfokus pada aplikasi frontend terlebih dahulu memiliki beberapa keuntungan, termasuk hal berikut:

• Komponen frontend bergantung pada resource backend dan terkadang pada komponen frontend lainnya.
• Komponen backend tidak bergantung pada komponen frontend. Oleh karena itu, mengisolasi dan memigrasikan aplikasi frontend cenderung tidak terlalu rumit dibandingkan memigrasikan aplikasi backend.
• Aplikasi frontend sering kali bersifat stateless atau tidak mengelola datanya sendiri, maka aplikasi tersebut cenderung tidak terlalu sulit untuk dimigrasikan dibandingkan backend.
  • Komponen frontend dapat dioptimalkan sebagai bagian dari migrasi untuk menggunakan arsitektur stateless. Untuk informasi selengkapnya, tonton Cara melakukan port aplikasi web stateful ke Cloud Run di YouTube.

Men-deploy aplikasi frontend yang sudah ada atau yang baru dikembangkan ke cloud publik menawarkan beberapa keuntungan:

• Banyak aplikasi frontend yang sering mengalami perubahan. Menjalankan aplikasi ini di cloud publik akan menyederhanakan penyiapan proses continuous integration/deployment berkelanjutan (CI/CD). Anda dapat menggunakan CI/CD untuk mengirim update secara efisien dan otomatis. Untuk informasi selengkapnya, lihat CI/CD di Google Cloud.
• Frontend yang sensitif terhadap performa dengan beban traffic yang bervariasi dapat sangat diuntungkan dari load balancing, deployment multi-regional, caching Cloud CDN, serverless, dan kemampuan penskalaan otomatis yang didukung oleh deployment berbasis cloud (idealnya dengan arsitektur stateless).

• Dengan mengadopsi microservice dengan penampung menggunakan platform yang dikelola cloud, seperti GKE, Anda dapat menggunakan arsitektur modern seperti microfrontend, yang memperluas microservice ke komponen frontend.

  Memperluas microservice biasanya digunakan dengan frontend yang melibatkan beberapa tim yang berkolaborasi pada aplikasi yang sama. Struktur tim semacam itu memerlukan pendekatan iteratif dan pemeliharaan berkelanjutan. Beberapa keuntungan menggunakan microfrontend adalah sebagai berikut:

  • Aplikasi ini dapat dibuat menjadi modul microservice independen untuk pengembangan, pengujian, dan deployment.
  • Hal ini memberikan pemisahan tempat setiap tim pengembangan dapat memilih teknologi dan kode pilihan mereka.
  • Hal ini dapat mendorong siklus pengembangan dan deployment yang cepat tanpa memengaruhi komponen frontend lainnya yang mungkin dikelola oleh tim lain.

• Baik mengimplementasikan antarmuka pengguna atau API, maupun menangani penyerapan data Internet of Things (IoT), aplikasi frontend dapat memanfaatkan kemampuan layanan cloud seperti Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine, atau Cloud Run.

• Proxy API yang dikelola cloud membantu:

  • Pisahkan API yang ditampilkan ke aplikasi dari layanan backend Anda, seperti microservice.
  • Melindungi aplikasi dari perubahan kode backend.
  • Mendukung arsitektur frontend berbasis API yang ada, seperti backend untuk frontend (BFF), microfrontend, dan lainnya.
  • Ekspos API Anda di Google Cloud atau lingkungan lainnya dengan menerapkan proxy API di Apigee.

Anda juga dapat menerapkan pola hybrid bertingkat secara terbalik, dengan men-deploy backend di cloud sambil menjaga frontend di lingkungan komputasi pribadi. Meskipun kurang umum, pendekatan ini paling cocok diterapkan saat Anda menangani frontend yang berat dan monolitik. Dalam kasus seperti itu, mungkin akan lebih mudah untuk mengekstrak fungsi backend secara iteratif, dan men-deploy backend baru ini di cloud.

Bagian ketiga dari seri ini membahas kemungkinan pola jaringan untuk mengaktifkan arsitektur tersebut. Apigee hybrid membantu sebagai platform untuk mem-build dan mengelola proxy API dalam model deployment hybrid. Untuk mengetahui informasi selengkapnya, lihat Arsitektur yang terikat longgar, termasuk arsitektur monolitik dan microservice bertingkat.

Praktik terbaik

Gunakan informasi di bagian ini saat Anda merencanakan arsitektur hybrid bertingkat.

Praktik terbaik untuk mengurangi kompleksitas

Saat Anda menerapkan pola arsitektur hybrid bertingkat, pertimbangkan praktik terbaik berikut yang dapat membantu mengurangi kompleksitas deployment dan operasional secara keseluruhan:

• Berdasarkan penilaian model komunikasi aplikasi yang diidentifikasi, pilih solusi komunikasi yang paling efisien dan efektif untuk aplikasi tersebut.

Karena sebagian besar interaksi pengguna melibatkan sistem yang terhubung di beberapa lingkungan komputasi, konektivitas yang cepat dan berlatensi rendah di antara sistem tersebut sangatlah penting. Untuk memenuhi ekspektasi ketersediaan dan performa, Anda harus mendesain untuk ketersediaan tinggi, latensi rendah, dan level throughput yang sesuai. Dari sudut pandang keamanan, komunikasi harus terperinci dan terkontrol. Idealnya, Anda harus mengekspos komponen aplikasi menggunakan API yang aman. Untuk mengetahui informasi selengkapnya, lihat Egress terkontrol.

• Untuk meminimalkan latensi komunikasi antarlingkungan, pilih region Google Cloud yang secara geografis dekat dengan lingkungan komputasi pribadi tempat komponen backend aplikasi Anda dihosting. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pemilihan region Compute Engine.
• Minimalkan dependensi tinggi antara sistem yang berjalan di lingkungan berbeda, terutama saat komunikasi ditangani secara sinkron. Dependensi ini dapat memperlambat performa, mengurangi ketersediaan secara keseluruhan, dan berpotensi menimbulkan biaya transfer data keluar tambahan.
• Dengan pola arsitektur hybrid bertingkat, Anda mungkin memiliki volume traffic masuk yang lebih besar dari lingkungan lokal yang masuk ke Google Cloud dibandingkan dengan traffic keluar yang keluar dari Google Cloud. Namun, Anda harus mengetahui volume transfer data keluar yang diperkirakan akan meninggalkan Google Cloud. 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 tagihan transfer data keluar untuk traffic yang memenuhi kondisi tertentu. Untuk mengetahui informasi selengkapnya, lihat Harga Cloud Interconnect.
• Untuk melindungi informasi sensitif, sebaiknya enkripsi semua komunikasi saat dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, Anda dapat menggunakan tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.

• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai backend, sebaiknya, jika memungkinkan, deploy gateway API atau proxy sebagai facade pemersatu. Gateway atau proxy ini berfungsi sebagai titik kontrol terpusat dan melakukan langkah-langkah berikut:

  • Menerapkan langkah keamanan tambahan.
  • Melindungi aplikasi klien dan layanan lainnya dari perubahan kode backend.
  • Memfasilitasi pelacakan audit untuk komunikasi antara semua aplikasi lintas lingkungan dan komponen yang dipisahkan.
  • Berfungsi sebagai lapisan komunikasi perantara antara layanan lama dan layanan yang dimodernisasi.
    • Apigee dan Apigee hybrid memungkinkan Anda menghosting dan mengelola gateway hybrid dan tingkat perusahaan di seluruh lingkungan lokal, edge, cloud lainnya, dan lingkungan Google Cloud.

• Untuk memfasilitasi pembuatan penyiapan hybrid, gunakan Cloud Load Balancing dengan konektivitas hybrid. Artinya, Anda dapat memperluas manfaat load balancing cloud ke layanan yang dihosting di lingkungan komputasi lokal. Pendekatan ini memungkinkan migrasi beban kerja bertahap ke Google Cloud dengan gangguan layanan minimal atau tanpa gangguan, sehingga memastikan transisi yang lancar untuk layanan terdistribusi. Untuk mengetahui informasi selengkapnya, lihat Ringkasan grup endpoint jaringan konektivitas hybrid.

• Terkadang, menggunakan gateway API, atau proxy dan Application Load Balancer secara bersamaan, dapat memberikan solusi yang lebih andal untuk mengelola, mengamankan, dan mendistribusikan traffic API dalam skala besar. Dengan menggunakan Cloud Load Balancing dengan API gateway, Anda dapat melakukan hal berikut:

  • Berikan API berperforma tinggi dengan Apigee dan Cloud CDN, untuk mengurangi latensi, menghosting API secara global, dan meningkatkan ketersediaan untuk musim puncak traffic. Untuk mengetahui informasi selengkapnya, tonton Menyediakan API berperforma tinggi dengan Apigee dan Cloud CDN di YouTube.
  • Terapkan pengelolaan traffic lanjutan.
  • Gunakan Google Cloud Armor sebagai layanan keamanan jaringan dan perlindungan DDoS untuk melindungi API Anda.
  • Kelola load balancing yang efisien di seluruh gateway di beberapa region. Untuk mengetahui informasi selengkapnya, tonton Mengamankan API dan Mengimplementasikan failover multi-region dengan Private Service Connect dan Apigee di YouTube.

• Gunakan pengelolaan API dan mesh layanan untuk mengamankan dan mengontrol komunikasi dan eksposur layanan dengan arsitektur microservice.

  • Gunakan Cloud Service Mesh untuk memungkinkan komunikasi layanan ke layanan yang mempertahankan kualitas layanan dalam sistem yang terdiri dari layanan terdistribusi tempat Anda dapat mengelola autentikasi, otorisasi, dan enkripsi antar-layanan.
  • Gunakan platform pengelolaan API seperti Apigee yang memungkinkan organisasi dan entitas eksternal Anda menggunakan layanan tersebut dengan mengeksposnya sebagai API.

• Bangun identitas bersama antarlingkungan agar sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.

• Men-deploy sistem CI/CD dan manajemen konfigurasi di cloud publik. Untuk informasi selengkapnya, lihat Pola arsitektur jaringan yang dicerminkan.

• Untuk membantu meningkatkan efisiensi operasional, gunakan alat dan pipeline CI/CD yang konsisten di seluruh lingkungan.

Praktik terbaik untuk arsitektur aplikasi dan workload individual

• Meskipun fokusnya terletak pada aplikasi frontend dalam pola ini, Anda harus tetap memperhatikan kebutuhan untuk memodernisasi aplikasi backend. Jika kecepatan pengembangan aplikasi backend jauh lebih lambat daripada aplikasi frontend, perbedaannya dapat menyebabkan kompleksitas tambahan.
• Memperlakukan API sebagai antarmuka backend akan menyederhanakan integrasi, pengembangan frontend, interaksi layanan, dan menyembunyikan kompleksitas sistem backend. Untuk mengatasi tantangan ini, Apigee memfasilitasi pengembangan dan pengelolaan gateway/proxy API untuk deployment hybrid dan multicloud.
• Pilih pendekatan rendering untuk aplikasi web frontend Anda berdasarkan konten (statis versus dinamis), performa pengoptimalan mesin telusur, dan ekspektasi tentang kecepatan pemuatan halaman.
• Saat memilih arsitektur untuk aplikasi web berbasis konten, berbagai opsi tersedia, termasuk arsitektur monolitik, serverless, berbasis peristiwa, dan microservice. Untuk memilih arsitektur yang paling cocok, nilai opsi ini secara menyeluruh berdasarkan persyaratan aplikasi Anda saat ini dan mendatang. Untuk membantu Anda membuat keputusan arsitektur yang selaras dengan tujuan bisnis dan teknis, lihat Perbandingan berbagai arsitektur untuk backend aplikasi web berbasis konten, dan Pertimbangan Utama untuk backend web.

• Dengan arsitektur microservice, Anda dapat menggunakan aplikasi dalam container dengan Kubernetes sebagai lapisan runtime umum. Dengan pola arsitektur hibrida bersusun, Anda dapat menjalankannya dalam salah satu skenario berikut:

  • Di kedua lingkungan (Google Cloud dan lingkungan lokal Anda).

    • Saat menggunakan container dan Kubernetes di seluruh lingkungan, Anda memiliki fleksibilitas untuk memodernisasi workload, lalu bermigrasi ke Google Cloud pada waktu yang berbeda. Hal ini membantu saat workload sangat bergantung pada workload lain dan tidak dapat dimigrasikan secara terpisah, atau untuk menggunakan portabilitas workload hybrid guna menggunakan resource terbaik yang tersedia di setiap lingkungan. Dalam semua kasus, GKE Enterprise dapat menjadi teknologi utama yang memungkinkan. Untuk mengetahui informasi selengkapnya, lihat Lingkungan hybrid GKE Enterprise.

  • Di lingkungan Google Cloud untuk komponen aplikasi yang dimigrasikan dan dimodernisasi.

    • Gunakan pendekatan ini jika Anda memiliki backend lama di lokal yang tidak memiliki dukungan containerisasi atau memerlukan waktu dan resource yang signifikan untuk dimodernisasi dalam jangka pendek.

    Untuk informasi selengkapnya tentang cara mendesain dan memfaktorkan ulang aplikasi monolitik menjadi arsitektur microservice guna memodernisasi arsitektur aplikasi web Anda, lihat Pengantar microservice.

• Anda dapat menggabungkan teknologi penyimpanan data bergantung pada kebutuhan aplikasi web Anda. Menggunakan Cloud SQL untuk data terstruktur dan Cloud Storage untuk file media adalah pendekatan umum untuk memenuhi berbagai kebutuhan penyimpanan data. Meskipun demikian, pilihannya sangat bergantung pada kasus penggunaan Anda. Untuk mengetahui informasi selengkapnya tentang opsi penyimpanan data untuk backend aplikasi yang berbasis konten dan modalitas yang efektif, lihat Opsi Penyimpanan Data untuk Aplikasi Web yang Berbasis Konten. Selain itu, lihat Opsi database Google Cloud Anda, secara mendetail

Pola multicloud yang dipartisi

Pola arsitektur multicloud yang dipartisi menggabungkan beberapa lingkungan cloud publik yang dioperasikan oleh penyedia layanan cloud yang berbeda. Arsitektur ini memberikan fleksibilitas untuk men-deploy aplikasi dalam lingkungan komputasi yang optimal yang memperhitungkan pendorong dan pertimbangan multi-cloud yang dibahas di bagian pertama serial ini.

Diagram berikut menunjukkan pola arsitektur multicloud yang dipartisi.

Pola arsitektur ini dapat dibuat dengan dua cara berbeda. Pendekatan pertama didasarkan pada deployment komponen aplikasi di berbagai lingkungan cloud publik. Pendekatan ini juga disebut sebagai arsitektur komposit dan merupakan pendekatan yang sama dengan pola arsitektur bertingkat hybrid. Namun, alih-alih menggunakan lingkungan lokal dengan cloud publik, setidaknya ada dua lingkungan cloud yang digunakan. Dalam arsitektur komposit, satu beban kerja atau aplikasi menggunakan komponen dari lebih dari satu cloud. Pendekatan kedua men-deploy aplikasi yang berbeda di berbagai lingkungan cloud publik. Daftar tidak lengkap berikut menjelaskan beberapa pendorong bisnis untuk pendekatan kedua:

• Untuk mengintegrasikan sepenuhnya aplikasi yang dihosting di lingkungan cloud yang berbeda-beda selama skenario penggabungan dan akuisisi antara dua perusahaan.
• Untuk mendorong fleksibilitas dan memenuhi berbagai preferensi cloud dalam organisasi Anda. Terapkan pendekatan ini untuk mendorong unit organisasi memilih penyedia cloud yang paling sesuai dengan kebutuhan dan preferensi spesifik mereka.
• Untuk beroperasi di deployment multi-regional atau cloud global. Jika perusahaan diwajibkan untuk mematuhi peraturan residensi data di region atau negara tertentu, mereka harus memilih dari penyedia cloud yang tersedia di lokasi tersebut jika penyedia cloud utama mereka tidak memiliki region cloud di sana.

Dengan pola arsitektur multicloud yang dipartisi, Anda dapat secara opsional mempertahankan kemampuan untuk mengalihkan workload sesuai kebutuhan dari satu lingkungan cloud publik ke lingkungan cloud publik lainnya. Dalam hal ini, portabilitas workload Anda menjadi persyaratan utama. Saat Anda men-deploy workload ke beberapa lingkungan komputasi, dan ingin mempertahankan kemampuan untuk memindahkan workload antarlingkungan, Anda harus menghilangkan perbedaan antarlingkungan. Dengan menggunakan GKE Enterprise, Anda dapat mendesain dan membuat solusi untuk mengatasi kompleksitas multi-cloud dengan postur tata kelola, operasi, dan keamanan yang konsisten. Untuk mengetahui informasi selengkapnya, lihat Multi-Cloud GKE.

Seperti yang disebutkan sebelumnya, ada beberapa situasi yang mungkin memiliki alasan bisnis dan teknis untuk menggabungkan Google Cloud dengan penyedia cloud lain dan mempartisi beban kerja di seluruh lingkungan cloud tersebut. Solusi multicloud memberi Anda fleksibilitas untuk memigrasikan, mem-build, dan mengoptimalkan portabilitas aplikasi di seluruh lingkungan multicloud sekaligus meminimalkan keterikatan, dan membantu Anda memenuhi persyaratan peraturan. Misalnya, Anda dapat menghubungkan Google Cloud dengan Oracle Cloud Infrastructure (OCI), untuk membuat solusi multicloud yang memanfaatkan kemampuan setiap platform menggunakan Cloud Interconnect pribadi untuk menggabungkan komponen yang berjalan di OCI dengan resource yang berjalan di Google Cloud. Untuk informasi selengkapnya, lihat Google Cloud dan Infrastruktur Oracle Cloud – memaksimalkan multicloud. Selain itu, Cross-Cloud Interconnect memfasilitasi konektivitas khusus bandwidth tinggi antara Google Cloud dan penyedia layanan cloud yang didukung lainnya, sehingga Anda dapat merancang dan membuat solusi multicloud untuk menangani volume traffic antar-cloud yang tinggi.

Kelebihan

Meskipun menggunakan arsitektur multicloud menawarkan beberapa manfaat bisnis dan teknis, seperti yang dibahas dalam Pengemudi, pertimbangan, strategi, dan pendekatan, Anda harus melakukan penilaian kelayakan mendetail dari setiap potensi manfaat. Penilaian Anda harus mempertimbangkan dengan cermat tantangan langsung atau tidak langsung yang terkait atau potensi hambatan, dan kemampuan Anda untuk mengatasinya secara efektif. Selain itu, pertimbangkan bahwa pertumbuhan jangka panjang aplikasi atau layanan Anda dapat menimbulkan kompleksitas yang mungkin lebih besar daripada manfaat awal.

Berikut adalah beberapa keuntungan utama pola arsitektur multicloud yang dipartisi:

• Dalam skenario saat Anda mungkin perlu meminimalkan komitmen terhadap satu penyedia cloud, Anda dapat mendistribusikan aplikasi di beberapa penyedia cloud. Akibatnya, Anda dapat mengurangi vendor lock-in secara relatif dengan kemampuan untuk mengubah paket (sejauh tertentu) di seluruh penyedia cloud. Open Cloud membantu menghadirkan kemampuan Google Cloud, seperti GKE Enterprise, ke berbagai lokasi fisik. Dengan memperluas kemampuan Google Cloud di infrastruktur lokal, di beberapa cloud publik, dan di edge, solusi ini memberikan fleksibilitas, ketangkasan, dan mendorong transformasi.

• Alasan peraturan ini membuat Anda dapat menayangkan segmen tertentu basis pengguna dan data dari negara tempat Google Cloud tidak memiliki region cloud.

• Pola arsitektur multicloud yang dipartisi dapat membantu mengurangi latensi dan meningkatkan kualitas pengalaman pengguna secara keseluruhan di lokasi tempat penyedia cloud utama tidak memiliki region cloud atau point of presence. Pola ini sangat berguna saat menggunakan konektivitas multi-cloud berkapasitas tinggi dan latensi rendah, seperti Cross-Cloud Interconnect dan CDN Interconnect dengan CDN terdistribusi.

• Anda dapat men-deploy aplikasi di beberapa penyedia cloud dengan cara yang memungkinkan Anda memilih di antara layanan terbaik yang ditawarkan oleh penyedia cloud lain.

• Pola arsitektur multicloud yang dipartisi dapat membantu memfasilitasi dan mempercepat skenario merger dan akuisisi, dengan aplikasi dan layanan dari dua perusahaan tersebut mungkin dihosting di lingkungan cloud publik yang berbeda.

Praktik terbaik

• Mulailah dengan men-deploy beban kerja yang tidak penting. Deployment awal di cloud sekunder ini kemudian dapat berfungsi sebagai pola untuk deployment atau migrasi mendatang. Namun, pendekatan ini mungkin tidak berlaku dalam situasi ketika beban kerja tertentu secara hukum atau peraturan diperlukan untuk berada di region cloud tertentu, dan penyedia cloud utama tidak memiliki region di wilayah yang diperlukan.
• Minimalkan dependensi antara sistem yang berjalan di berbagai lingkungan cloud publik, terutama saat komunikasi ditangani secara sinkron. Dependensi ini dapat memperlambat performa, mengurangi ketersediaan keseluruhan, dan berpotensi menimbulkan biaya transfer data keluar tambahan.
• Untuk menghilangkan perbedaan antarlingkungan, pertimbangkan untuk menggunakan container dan Kubernetes jika didukung oleh aplikasi dan memungkinkan.
• Pastikan pipeline dan alat CI/CD untuk deployment dan pemantauan konsisten di seluruh lingkungan cloud.
• Pilih pola arsitektur jaringan yang optimal yang memberikan solusi komunikasi yang paling efisien dan efektif untuk aplikasi yang Anda gunakan.
  • Komunikasi harus terperinci dan terkontrol. Gunakan API yang aman untuk mengekspos komponen aplikasi.
  • Pertimbangkan untuk menggunakan pola arsitektur mesh atau salah satu pola jaringan berpagar, berdasarkan persyaratan bisnis dan teknis spesifik Anda.
• Untuk memenuhi ekspektasi ketersediaan dan performa, desain untuk ketersediaan tinggi (HA) menyeluruh, latensi rendah, dan level throughput yang sesuai.

• Untuk melindungi informasi sensitif, sebaiknya enkripsi semua komunikasi saat dalam pengiriman.

  • Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia, berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cross-Cloud Interconnect.

• Jika Anda menggunakan beberapa CDN sebagai bagian dari pola arsitektur partisi multicloud, dan Anda mengisi CDN lain dengan file data besar dari Google Cloud, pertimbangkan untuk menggunakan link CDN Interconnect antara Google Cloud dan penyedia yang didukung untuk mengoptimalkan traffic ini dan, berpotensi, biayanya.

• Luaskan solusi pengelolaan identitas Anda antarlingkungan agar sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.

• Untuk menyeimbangkan permintaan secara efektif di Google Cloud dan platform cloud lain, Anda dapat menggunakan Cloud Load Balancing. Untuk informasi selengkapnya, lihat Merutekan traffic ke lokasi lokal atau cloud lain.

  • Jika volume transfer data keluar dari Google Cloud ke lingkungan lain tinggi, pertimbangkan untuk menggunakan Cross-Cloud Interconnect.

• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai backend, sebaiknya, jika memungkinkan, deploy gateway API atau proxy sebagai facade pemersatu. Gateway atau proxy ini berfungsi sebagai titik kontrol terpusat dan melakukan langkah-langkah berikut:

  • Menerapkan langkah keamanan tambahan.
  • Melindungi aplikasi klien dan layanan lainnya dari perubahan kode backend.
  • Memfasilitasi pelacakan audit untuk komunikasi antara semua aplikasi lintas lingkungan dan komponen yang dipisahkan.
  • Berfungsi sebagai lapisan komunikasi perantara antara layanan lama dan layanan yang dimodernisasi.
    • Apigee dan Apigee hybrid memungkinkan Anda menghosting dan mengelola gateway hybrid dan tingkat perusahaan di seluruh lingkungan lokal, edge, cloud lainnya, dan lingkungan Google Cloud.

• Dalam beberapa kasus berikut, penggunaan Cloud Load Balancing dengan API gateway dapat memberikan solusi yang andal dan aman untuk mengelola, mengamankan, dan mendistribusikan traffic API dalam skala besar di beberapa region:

  • Men-deploy failover multi-region untuk runtime Apigee API di berbagai region.

  • Meningkatkan performa dengan Cloud CDN.

  • Memberikan perlindungan WAF dan DDoS melalui Google Cloud Armor.

• Gunakan alat yang konsisten untuk logging dan pemantauan di seluruh lingkungan cloud jika memungkinkan. Anda dapat mempertimbangkan untuk menggunakan sistem pemantauan open source. Untuk informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

• Jika Anda men-deploy komponen aplikasi secara terdistribusi dengan komponen satu aplikasi di-deploy di lebih dari satu lingkungan cloud, lihat praktik terbaik untuk pola arsitektur hybrid bertingkat.

Pola hybrid dan multicloud analisis

Dokumen ini membahas bahwa tujuan pola hybrid dan multicloud analisis adalah untuk memanfaatkan pemisahan antara beban kerja transaksional dan analisis.

Dalam sistem perusahaan, sebagian besar workload termasuk dalam kategori berikut:

• Workload transaksional mencakup aplikasi interaktif seperti penjualan, pemrosesan keuangan, perencanaan sumber daya perusahaan, atau komunikasi.
• Workload analytics mencakup aplikasi yang mengubah, menganalisis, meningkatkan kualitas, atau memvisualisasikan data untuk membantu proses pengambilan keputusan.

Sistem analisis mendapatkan datanya dari sistem transaksional dengan membuat kueri API atau mengakses database. Di sebagian besar perusahaan, sistem analytics dan transaksi cenderung dipisahkan dan dikaitkan secara longgar. Tujuan pola multi-cloud dan hybrid analytics adalah untuk memanfaatkan pemisahan yang sudah ada ini dengan menjalankan beban kerja transaksional dan analisis di dua lingkungan komputasi yang berbeda. Data mentah diekstraksi terlebih dahulu dari workload yang berjalan di lingkungan komputasi pribadi, lalu dimuat ke Google Cloud, tempat data tersebut digunakan untuk pemrosesan analisis. Beberapa hasilnya mungkin dimasukkan kembali ke sistem transaksional.

Diagram berikut mengilustrasikan arsitektur yang mungkin secara konseptual dengan menampilkan kemungkinan pipeline data. Setiap jalur/panah mewakili kemungkinan opsi pipeline transformasi dan pemindahan data yang dapat didasarkan pada ETL atau ELT, bergantung pada kualitas data yang tersedia dan kasus penggunaan yang ditargetkan.

Untuk memindahkan data Anda ke Google Cloud dan mengoptimalkan manfaat dari data tersebut, gunakan layanan pergerakan data, yaitu rangkaian lengkap layanan penyerapan, integrasi, dan replikasi data.

Seperti yang ditunjukkan pada diagram sebelumnya, menghubungkan Google Cloud dengan lingkungan lokal dan lingkungan cloud lainnya dapat memungkinkan berbagai kasus penggunaan analisis data, seperti streaming data dan pencadangan database. Untuk mendukung transpor dasar pola analisis hybrid dan multi-cloud yang memerlukan volume transfer data yang tinggi, Cloud Interconnect dan Cross-Cloud Interconnect menyediakan konektivitas khusus ke penyedia cloud lokal dan lainnya.

Kelebihan

Menjalankan workload analytics di cloud memiliki beberapa keuntungan utama:

• Traffic masuk—memindahkan data dari lingkungan komputasi pribadi Anda atau cloud lain ke Google Cloud—mungkin tidak dikenai biaya.
• Workload analisis sering kali perlu memproses data dalam jumlah besar dan dapat mengalami bursting, sehingga sangat cocok untuk di-deploy di lingkungan cloud publik. Dengan menskalakan resource komputasi secara dinamis, Anda dapat memproses set data besar dengan cepat sambil menghindari investasi di muka atau harus menyediakan peralatan komputasi secara berlebihan.
• Google Cloud menyediakan berbagai layanan untuk mengelola data di sepanjang siklus prosesnya, mulai dari akuisisi awal hingga pemrosesan dan analisis hingga visualisasi akhir.
  • Layanan pemindahan data di Google Cloud menyediakan rangkaian lengkap produk untuk memindahkan, mengintegrasikan, dan mengubah data dengan lancar dengan berbagai cara.
  • Cloud Storage sangat cocok untuk mem-build data lake.

• Google Cloud membantu Anda memodernisasi dan mengoptimalkan platform data untuk memecah silo data. Penggunaan data lakehouse membantu menstandarkan berbagai format penyimpanan. Lakehouse data juga dapat memberikan fleksibilitas, skalabilitas, dan ketangkasan yang diperlukan untuk membantu memastikan bahwa data Anda menghasilkan nilai bagi bisnis Anda, bukan inefisiensi. Untuk mengetahui informasi selengkapnya, lihat BigLake.

• BigQuery Omni, menyediakan daya komputasi yang berjalan secara lokal ke penyimpanan di AWS atau Azure. Tindakan ini juga membantu Anda membuat kueri data Anda sendiri yang disimpan di Amazon Simple Storage Service (Amazon S3) atau Azure Blob Storage. Kemampuan analisis multicloud ini memungkinkan tim data mengurai silo data. Untuk informasi selengkapnya tentang cara membuat kueri data yang disimpan di luar BigQuery, lihat Pengantar sumber data eksternal.

Praktik terbaik

Untuk menerapkan pola arsitektur hybrid dan multi-cloud analisis, pertimbangkan praktik terbaik umum berikut:

• Gunakan pola jaringan handover untuk memungkinkan penyerapan data. Jika hasil analisis perlu dimasukkan kembali ke sistem transaksional, Anda dapat menggabungkan pola traffic keluar dengan akses terbatas dan handover.
• Gunakan antrean Pub/Sub atau bucket Cloud Storage untuk menyerahkan data ke Google Cloud dari sistem transaksional yang berjalan di lingkungan komputasi pribadi Anda. Antrean atau bucket ini dapat berfungsi sebagai sumber untuk pipeline dan workload pemrosesan data.
• Untuk men-deploy pipeline data ETL dan ELT, pertimbangkan untuk menggunakan Cloud Data Fusion atau Dataflow bergantung pada persyaratan kasus penggunaan spesifik Anda. Keduanya adalah layanan pemrosesan data berbasis cloud dan terkelola sepenuhnya untuk membuat dan mengelola pipeline data.
• Untuk menemukan, mengklasifikasikan, dan melindungi aset data berharga Anda, pertimbangkan untuk menggunakan kemampuan Perlindungan Data Sensitif Google Cloud, seperti teknik de-identifikasi. Teknik ini memungkinkan Anda menyamarkan, mengenkripsi, dan mengganti data sensitif—seperti informasi identitas pribadi (PII)—menggunakan kunci yang dihasilkan secara acak atau ditentukan sebelumnya, jika berlaku dan mematuhi kebijakan.
• Jika Anda sudah memiliki workload Hadoop atau Spark, pertimbangkan untuk memigrasikan tugas ke Dataproc dan memigrasikan data HDFS yang ada ke Cloud Storage.

• Saat melakukan transfer data awal dari lingkungan komputasi pribadi Anda ke Google Cloud, pilih pendekatan transfer yang paling sesuai dengan ukuran set data dan bandwidth yang tersedia. Untuk informasi selengkapnya, lihat Migrasi ke Google Cloud: Mentransfer set data besar.

• Jika transfer atau pertukaran data antara Google Cloud dan cloud lainnya diperlukan untuk jangka panjang dengan volume traffic tinggi, Anda harus mengevaluasi penggunaan Cross-Cloud Interconnect Google Cloud untuk membantu Anda membangun konektivitas khusus bandwidth tinggi antara Google Cloud dan penyedia layanan cloud lainnya (tersedia di lokasi tertentu).

• Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cross-Cloud Interconnect.

• Gunakan alat dan proses yang konsisten di seluruh lingkungan. Dalam skenario hybrid analisis, praktik ini dapat membantu meningkatkan efisiensi operasional, meskipun bukan prasyarat.

Pola edge hybrid

Untuk menjalankan workload di cloud, klien dalam beberapa skenario harus memiliki konektivitas internet yang cepat dan andal. Mengingat jaringan saat ini, persyaratan ini jarang menimbulkan tantangan untuk adopsi cloud. Namun, ada skenario saat Anda tidak dapat mengandalkan konektivitas berkelanjutan, seperti:

• Kapal pelayaran dan kendaraan lainnya mungkin hanya terhubung sesekali atau hanya memiliki akses ke link satelit berlatensi tinggi.
• Pabrik atau pembangkit listrik mungkin terhubung ke internet. Fasilitas ini mungkin memiliki persyaratan keandalan yang melebihi klaim ketersediaan dari penyedia internet mereka.
• Toko retail dan supermarket mungkin hanya terhubung sesekali atau menggunakan link yang tidak memberikan keandalan atau throughput yang diperlukan untuk menangani transaksi yang penting bagi bisnis.

Pola arsitektur edge hybrid mengatasi tantangan ini dengan menjalankan workload yang penting bagi waktu dan bisnis secara lokal, di edge jaringan, sekaligus menggunakan cloud untuk semua jenis workload lainnya. Dalam arsitektur hybrid edge, link internet adalah komponen tidak penting yang digunakan untuk tujuan pengelolaan dan untuk menyinkronkan atau mengupload data, sering kali secara asinkron, tetapi tidak terlibat dalam transaksi yang penting bagi waktu atau bisnis.

Kelebihan

Menjalankan workload tertentu di edge dan workload lainnya di cloud menawarkan beberapa keuntungan:

• Traffic masuk, yang memindahkan data dari edge ke Google Cloud, mungkin tidak dikenai biaya.
• Menjalankan workload yang penting bagi bisnis dan waktu di edge dapat membantu memastikan latensi rendah dan kemandirian. Jika konektivitas internet gagal atau tidak tersedia untuk sementara, Anda masih dapat menjalankan semua transaksi penting. Pada saat yang sama, Anda dapat memanfaatkan cloud untuk sebagian besar workload Anda.
• Anda dapat menggunakan kembali investasi yang ada dalam peralatan komputasi dan penyimpanan.
• Seiring waktu, Anda dapat secara bertahap mengurangi fraksi workload yang dijalankan di edge dan memindahkannya ke cloud, baik dengan mengolah aplikasi tertentu atau dengan melengkapi beberapa lokasi edge dengan link internet yang lebih andal.
• Project terkait Internet of Things (IoT) dapat menjadi lebih hemat biaya dengan melakukan komputasi data secara lokal. Hal ini memungkinkan perusahaan menjalankan dan memproses beberapa layanan secara lokal di edge, lebih dekat ke sumber data. Hal ini juga memungkinkan perusahaan mengirim data secara selektif ke cloud, yang dapat membantu mengurangi kapasitas, transfer data, pemrosesan, dan biaya keseluruhan solusi IoT.
• Edge computing dapat bertindak sebagai lapisan komunikasi perantara antara layanan lama dan layanan modern. Misalnya, layanan yang mungkin menjalankan gateway API dalam penampung seperti Apigee hybrid). Hal ini memungkinkan aplikasi dan sistem lama untuk berintegrasi dengan layanan yang dimodernisasi, seperti solusi IoT.

Praktik terbaik

Pertimbangkan rekomendasi berikut saat menerapkan pola arsitektur edge hybrid:

• Jika komunikasi bersifat searah, gunakan pola traffic masuk dengan akses terbatas.
• Jika komunikasi bersifat dua arah, pertimbangkan pola traffic keluar dan masuk dengan akses terbatas.
• Jika solusi terdiri dari banyak situs jarak jauh edge yang terhubung ke Google Cloud melalui internet publik, Anda dapat menggunakan solusi WAN (SD-WAN) yang ditentukan software. Anda juga dapat menggunakan Network Connectivity Center dengan router SD-WAN pihak ketiga yang didukung oleh partner Google Cloud untuk menyederhanakan penyediaan dan pengelolaan konektivitas aman dalam skala besar.
• Minimalkan dependensi antara sistem yang berjalan di edge dan sistem yang berjalan di lingkungan cloud. Setiap dependensi dapat mengurangi keuntungan keandalan dan latensi penyiapan hybrid edge.
• Untuk mengelola dan mengoperasikan beberapa lokasi edge secara efisien, Anda harus memiliki solusi pemantauan dan bidang pengelolaan terpusat di cloud.
• Pastikan pipeline CI/CD beserta alat untuk deployment dan pemantauan konsisten di seluruh lingkungan cloud dan edge.
• Pertimbangkan untuk menggunakan container dan Kubernetes jika berlaku dan memungkinkan, untuk memisahkan perbedaan di antara berbagai lokasi edge dan juga antara lokasi edge dan cloud. Karena Kubernetes menyediakan lapisan runtime umum, Anda dapat mengembangkan, menjalankan, dan mengoperasikan workload secara konsisten di seluruh lingkungan komputasi. Anda juga dapat memindahkan workload antara edge dan cloud.
  • Untuk menyederhanakan penyiapan dan operasi campuran, Anda dapat menggunakan GKE Enterprise untuk arsitektur ini (jika container digunakan di seluruh lingkungan). Pertimbangkan opsi konektivitas yang mungkin ada yang Anda miliki untuk menghubungkan cluster GKE Enterprise yang berjalan di lingkungan lokal atau edge ke Google Cloud.
• Sebagai bagian dari pola ini, meskipun beberapa komponen GKE Enterprise mungkin bertahan selama gangguan konektivitas sementara ke Google Cloud, jangan gunakan GKE Enterprise saat terputus dari Google Cloud sebagai mode kerja nominal. Untuk informasi selengkapnya, lihat Dampak pemutusan koneksi sementara dari Google Cloud.
• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai layanan backend dan edge, sebaiknya, jika berlaku, deploy gateway API atau proxy sebagai facade pemersatu. Gateway atau proxy ini berfungsi sebagai titik kontrol terpusat dan melakukan langkah-langkah berikut:
  • Menerapkan langkah keamanan tambahan.
  • Melindungi aplikasi klien dan layanan lainnya dari perubahan kode backend.
  • Memfasilitasi pelacakan audit untuk komunikasi antara semua aplikasi lintas lingkungan dan komponen yang dipisahkan.
  • Berfungsi sebagai lapisan komunikasi perantara antara layanan lama dan layanan yang dimodernisasi.
    • Apigee dan Apigee Hybrid memungkinkan Anda menghosting dan mengelola gateway hybrid dan tingkat perusahaan di seluruh lingkungan lokal, edge, cloud lainnya, dan lingkungan Google Cloud.
• Bangun identitas bersama antarlingkungan agar sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.
• Data yang dipertukarkan antarlingkungan mungkin bersifat sensitif, maka pastikan semua komunikasi dienkripsi selama pengiriman menggunakan tunnel VPN, TLS, atau keduanya.

Pola hybrid lingkungan

Dengan pola arsitektur hybrid lingkungan, Anda mempertahankan lingkungan produksi workload di pusat data yang ada. Kemudian, Anda menggunakan cloud publik untuk lingkungan pengembangan dan pengujian, atau lingkungan lainnya. Pola ini bergantung pada deployment aplikasi yang sama secara redundan di beberapa lingkungan komputasi. Tujuan deployment adalah untuk membantu meningkatkan kapasitas, fleksibilitas, dan ketahanan.

Saat menilai workload mana yang akan dimigrasikan, Anda mungkin mendapati kasus saat menjalankan aplikasi tertentu di cloud publik memunculkan tantangan:

• Batasan wilayah hukum atau peraturan mungkin mengharuskan Anda menyimpan data di negara tertentu.
• Persyaratan pemberian lisensi pihak ketiga mungkin mencegah Anda mengoperasikan software tertentu di lingkungan cloud.
• Aplikasi mungkin memerlukan akses ke perangkat hardware yang hanya tersedia secara lokal.

Dalam kasus tersebut, tidak hanya pertimbangkan lingkungan produksi, tetapi semua lingkungan yang terlibat dalam siklus proses aplikasi, termasuk sistem pengembangan, pengujian, dan staging. Batasan ini sering kali berlaku pada lingkungan produksi dan datanya. Pengujian ini mungkin tidak berlaku untuk lingkungan lain yang tidak menggunakan data sebenarnya. Hubungi departemen kepatuhan organisasi Anda atau tim yang setara.

Diagram berikut menunjukkan pola arsitektur hybrid lingkungan yang umum:

Menjalankan sistem pengembangan dan pengujian di lingkungan yang berbeda dengan sistem produksi Anda mungkin tampak berisiko dan dapat menyimpang dari praktik terbaik yang sudah ada atau dari upaya Anda untuk meminimalkan perbedaan antara lingkungan. Meskipun dibenarkan, kekhawatiran tersebut tidak berlaku jika Anda membedakan tahap proses pengembangan dan pengujian:

Meskipun proses pengembangan, pengujian, dan deployment berbeda untuk setiap aplikasi, proses ini biasanya melibatkan variasi tahap berikut:

• Pengembangan: Membuat kandidat rilis.
• Pengujian fungsional atau pengujian penerimaan pengguna: Memverifikasi bahwa kandidat rilis memenuhi persyaratan fungsional.
• Pengujian performa dan keandalan: Memverifikasi bahwa kandidat rilis memenuhi persyaratan nonfungsi. Pengujian ini juga dikenal sebagai pengujian beban.
• Pengujian staging atau deployment: Memverifikasi bahwa prosedur deployment berfungsi.
• Produksi: Merilis aplikasi baru atau yang telah diupdate.

Menjalankan lebih dari satu tahap ini dalam satu lingkungan jarang terjadi, sehingga setiap tahap biasanya memerlukan satu atau beberapa lingkungan khusus.

Catatan: Istilah lingkungan staging sering kali dikacaukan dengan lingkungan pengujian.

Tujuan utama lingkungan pengujian adalah untuk menjalankan pengujian fungsional. Tujuan utama lingkungan staging adalah untuk menguji apakah prosedur deployment aplikasi Anda berfungsi sebagaimana mestinya. Pada saat rilis mencapai lingkungan staging, pengujian fungsi Anda seharusnya sudah selesai. Staging adalah langkah terakhir sebelum Anda men-deploy software ke deployment produksi.

Untuk memastikan bahwa hasil pengujian bermakna dan berlaku untuk deployment produksi, kumpulan lingkungan yang Anda gunakan selama siklus proses aplikasi harus memenuhi aturan berikut, sejauh mungkin:

• Semua lingkungan setara secara fungsional. Artinya, arsitektur, API, dan versi sistem operasi dan library setara, dan sistem berperilaku sama di seluruh lingkungan. Kesetaraan ini menghindari situasi saat aplikasi bekerja di satu lingkungan tetapi gagal di lingkungan lain, atau saat kerusakan tidak dapat direproduksi.
• Lingkungan yang digunakan untuk pengujian performa dan keandalan, staging, dan produksi setara secara nonfungsional. Artinya, performa, skala, dan konfigurasinya, serta cara pengoperasian dan pemeliharaannya, sama atau hanya berbeda dalam cara yang tidak signifikan. Jika tidak, pengujian performa dan staging tidak akan berguna.

Secara umum, tidak masalah jika lingkungan yang digunakan untuk pengembangan dan pengujian fungsi berbeda secara nonfungsional dari lingkungan lain.

Seperti yang diilustrasikan dalam diagram berikut, lingkungan pengujian dan pengembangan di-build di Google Cloud. Database terkelola, seperti Cloud SQL, dapat digunakan sebagai opsi untuk pengembangan dan pengujian di Google Cloud. Pengembangan dan pengujian dapat menggunakan mesin dan versi database yang sama di lingkungan on-premise, yang secara fungsional setara, atau versi baru yang diluncurkan ke lingkungan produksi setelah tahap pengujian. Namun, karena infrastruktur dasar dari kedua lingkungan tersebut tidak identik, pendekatan ini untuk pengujian beban performa tidak valid.

Skenario berikut dapat cocok dengan pola hybrid lingkungan:

• Capai kesetaraan fungsional di semua lingkungan dengan mengandalkan Kubernetes sebagai lapisan runtime umum jika berlaku dan memungkinkan. Edisi Google Kubernetes Engine (GKE) Enterprise dapat menjadi teknologi utama yang memungkinkan pendekatan ini.
  • Pastikan portabilitas workload dan abstraksi perbedaan antar-lingkungan komputasi. Dengan zero trust service mesh, Anda dapat mengontrol dan mempertahankan pemisahan komunikasi yang diperlukan di antara berbagai lingkungan.
• Jalankan lingkungan pengembangan dan pengujian fungsional di cloud publik. Lingkungan ini secara fungsional setara dengan lingkungan lainnya, tetapi mungkin berbeda dalam aspek nonfungsional, seperti performa. Konsep ini diilustrasikan dalam diagram sebelumnya.
• Jalankan lingkungan untuk pengujian produksi, staging, performa (pengujian beban), dan keandalan di lingkungan komputasi pribadi, sehingga memastikan kesetaraan fungsional dan nonfungsi.

Pertimbangan Desain

• Kebutuhan bisnis: Setiap strategi deployment dan rilis untuk aplikasi memiliki kelebihan dan kekurangannya sendiri. Untuk memastikan bahwa pendekatan yang Anda pilih sesuai dengan persyaratan spesifik Anda, dasari pilihan Anda pada penilaian menyeluruh terhadap kebutuhan dan batasan bisnis Anda.
• Perbedaan lingkungan: Sebagai bagian dari pola ini, tujuan utama menggunakan lingkungan cloud ini adalah untuk pengembangan dan pengujian. Status akhir adalah menghosting aplikasi yang diuji di lingkungan lokal pribadi (produksi). Untuk menghindari pengembangan dan pengujian kemampuan yang mungkin berfungsi seperti yang diharapkan di lingkungan cloud dan gagal di lingkungan produksi (di lokasi), tim teknis harus mengetahui dan memahami arsitektur dan kemampuan kedua lingkungan tersebut. Hal ini mencakup dependensi pada aplikasi lain dan pada infrastruktur hardware—misalnya, sistem keamanan yang melakukan inspeksi traffic.
• Pemerintahan: Untuk mengontrol apa yang diizinkan perusahaan Anda untuk dikembangkan di cloud dan data apa yang dapat digunakan untuk pengujian, gunakan proses persetujuan dan pemerintahan. Proses ini juga dapat membantu perusahaan Anda memastikan bahwa perusahaan tidak menggunakan fitur cloud apa pun di lingkungan pengembangan dan pengujian yang tidak ada di lingkungan produksi lokal.
• Kriteria keberhasilan: Harus ada kriteria keberhasilan pengujian yang jelas, telah ditentukan sebelumnya, dan terukur yang selaras dengan standar jaminan kualitas software untuk organisasi Anda. Terapkan standar ini ke aplikasi apa pun yang Anda kembangkan dan uji.
• Redundansi: Meskipun lingkungan pengembangan dan pengujian mungkin tidak memerlukan keandalan sebanyak lingkungan produksi, lingkungan tersebut masih memerlukan kemampuan redundan dan kemampuan untuk menguji berbagai skenario kegagalan. Persyaratan skenario kegagalan Anda mungkin mendorong desain untuk menyertakan redundansi sebagai bagian dari lingkungan pengembangan dan pengujian Anda.

Kelebihan

Menjalankan workload pengembangan dan pengujian secara fungsional di cloud publik memiliki beberapa keuntungan:

• Anda dapat otomatis memulai dan menghentikan lingkungan sesuai kebutuhan. Misalnya, Anda dapat menyediakan seluruh lingkungan untuk setiap commit atau permintaan pull, mengizinkan pengujian berjalan, lalu menonaktifkannya lagi. Pendekatan ini juga menawarkan keuntungan berikut:
  • Anda dapat mengurangi biaya dengan menghentikan instance virtual machine (VM) saat tidak aktif, atau dengan menyediakan lingkungan hanya sesuai permintaan.
  • Anda dapat mempercepat pengembangan dan pengujian dengan memulai lingkungan sementara untuk setiap permintaan pull. Tindakan ini juga mengurangi overhead pemeliharaan dan mengurangi inkonsistensi di lingkungan build.
• Menjalankan lingkungan ini di cloud publik membantu membangun pemahaman dan kepercayaan diri terhadap cloud dan alat terkait, yang dapat membantu memigrasikan workload lain. Pendekatan ini sangat membantu jika Anda memutuskan untuk mempelajari Portabilitas workload menggunakan container dan Kubernetes—misalnya, menggunakan GKE Enterprise di seluruh lingkungan.

Praktik terbaik

Agar berhasil menerapkan pola arsitektur hybrid lingkungan, pertimbangkan rekomendasi berikut:

• Tentukan persyaratan komunikasi aplikasi Anda, termasuk desain jaringan dan keamanan yang optimal. Kemudian, gunakan pola jaringan yang diduplikasi untuk membantu Anda mendesain arsitektur jaringan guna mencegah komunikasi langsung antara sistem dari lingkungan yang berbeda. Jika diperlukan di seluruh lingkungan, komunikasi harus dilakukan dengan cara yang terkontrol.

• Strategi pengujian dan deployment aplikasi yang Anda pilih harus selaras dengan tujuan dan persyaratan bisnis Anda. Hal ini mungkin melibatkan peluncuran perubahan tanpa periode nonaktif atau penerapan fitur secara bertahap ke lingkungan atau grup pengguna tertentu sebelum rilis yang lebih luas.

• Untuk membuat workload menjadi portabel dan menghilangkan perbedaan antara lingkungan, Anda dapat menggunakan container dengan Kubernetes. Untuk informasi selengkapnya, lihat arsitektur referensi lingkungan hybrid GKE Enterprise.

• Buat rantai alat umum yang berfungsi di seluruh lingkungan komputasi untuk men-deploy, mengonfigurasi, dan mengoperasikan workload. Dengan menggunakan Kubernetes, Anda mendapatkan konsistensi ini.

• Pastikan pipeline CI/CD konsisten di seluruh lingkungan komputasi, dan kumpulan biner, paket, atau penampung yang sama persis di-deploy di seluruh lingkungan tersebut.

• Saat menggunakan Kubernetes, gunakan sistem CI seperti Tekton untuk mengimplementasikan pipeline deployment yang di-deploy ke cluster dan berfungsi di seluruh lingkungan. Untuk informasi selengkapnya, lihat Solusi DevOps di Google Cloud.

• Untuk membantu Anda merilis aplikasi yang aman dan andal secara berkelanjutan, masukkan keamanan sebagai bagian integral dari proses DevOps (DevSecOps). Untuk mengetahui informasi selengkapnya, lihat Mengirimkan dan mengamankan aplikasi yang ditayangkan ke internet dalam waktu kurang dari satu jam menggunakan Toolkit Dev(Sec)Ops.

• Gunakan alat yang sama untuk logging dan pemantauan di seluruh Google Cloud dan lingkungan cloud yang sudah ada. Pertimbangkan untuk menggunakan sistem pemantauan open source. Untuk informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

• Jika workload pengujian dan produksi dikelola oleh tim yang berbeda, penggunaan alat terpisah mungkin dapat diterima. Namun, penggunaan alat yang sama dengan izin tampilan yang berbeda dapat membantu mengurangi kompleksitas dan upaya pelatihan Anda.

• Saat Anda memilih layanan database, penyimpanan, dan pesan untuk pengujian fungsional, gunakan produk yang memiliki padanan terkelola di Google Cloud. Mengandalkan layanan terkelola membantu mengurangi upaya administratif dalam mempertahankan lingkungan pengembangan dan pengujian.

• Untuk melindungi informasi sensitif, sebaiknya mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia yang didasarkan pada solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.

Tabel berikut menunjukkan produk Google Cloud yang kompatibel dengan produk OSS umum.

Produk OSS	Kompatibel dengan produk Google Cloud
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Redis Cluster, Redis, Memcached	Memorystore
Network File System (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise

Pola hybrid dan multicloud kelangsungan bisnis

Faktor utama yang mendorong pertimbangan kelangsungan bisnis untuk sistem penting adalah membantu organisasi menjadi tangguh dan melanjutkan operasi bisnisnya selama dan setelah peristiwa kegagalan. Dengan mereplikasi sistem dan data di beberapa region geografis dan menghindari titik tunggal kegagalan, Anda dapat meminimalkan risiko bencana alam yang memengaruhi infrastruktur lokal. Skenario kegagalan lainnya mencakup kegagalan sistem yang parah, serangan keamanan siber, atau bahkan error konfigurasi sistem.

Mengoptimalkan sistem agar dapat menahan kegagalan sangat penting untuk membangun kelangsungan bisnis yang efektif. Keandalan sistem dapat dipengaruhi oleh beberapa faktor, termasuk, tetapi tidak terbatas pada, performa, ketahanan, ketersediaan waktu aktif, keamanan, dan pengalaman pengguna. Untuk informasi selengkapnya tentang cara merancang dan mengoperasikan layanan yang andal di Google Cloud, lihat kolom keandalan dari Framework Arsitektur Google Cloud dan elemen penyusun keandalan di Google Cloud.

Pola arsitektur ini bergantung pada deployment aplikasi yang redundan di beberapa lingkungan komputasi. Dalam pola ini, Anda men-deploy aplikasi yang sama di beberapa lingkungan komputasi dengan tujuan meningkatkan keandalan. Kelangsungan bisnis dapat didefinisikan sebagai kemampuan organisasi untuk melanjutkan fungsi atau layanan bisnis utamanya pada tingkat yang dapat diterima yang telah ditentukan sebelumnya setelah peristiwa yang mengganggu.

Pemulihan dari bencana (DR) dianggap sebagai bagian dari kelangsungan bisnis, yang secara eksplisit berfokus pada memastikan bahwa sistem IT yang mendukung fungsi bisnis penting beroperasi sesegera mungkin setelah gangguan. Secara umum, strategi dan rencana DR sering membantu membentuk strategi kelangsungan bisnis yang lebih luas. Dari sudut pandang teknologi, saat Anda mulai membuat strategi pemulihan dari bencana, analisis dampak bisnis Anda harus menentukan dua metrik utama: tujuan titik pemulihan (RPO) dan batas waktu pemulihan (RTO). Untuk panduan lebih lanjut tentang penggunaan Google Cloud untuk mengatasi pemulihan dari bencana, lihat Panduan perencanaan pemulihan dari bencana.

Makin kecil nilai target RPO dan RTO, makin cepat layanan dapat pulih dari gangguan dengan kehilangan data minimal. Namun, hal ini menyiratkan biaya yang lebih tinggi karena berarti membangun sistem redundan. Sistem redundan yang mampu melakukan replikasi data mendekati real-time dan beroperasi pada skala yang sama setelah peristiwa kegagalan, meningkatkan kompleksitas, overhead administratif, dan biaya.

Keputusan untuk memilih strategi DR atau pola harus didasarkan pada analisis dampak bisnis. Misalnya, kerugian finansial yang timbul bahkan dari downtime beberapa menit untuk organisasi jasa keuangan mungkin jauh melebihi biaya penerapan sistem DR. Namun, bisnis di industri lain mungkin mengalami periode nonaktif selama berjam-jam tanpa dampak bisnis yang signifikan.

Saat Anda menjalankan sistem yang sangat penting di pusat data lokal, salah satu pendekatan DR adalah mempertahankan sistem standby di pusat data kedua di region yang berbeda. Namun, pendekatan yang lebih hemat biaya adalah menggunakan lingkungan komputasi berbasis cloud publik untuk tujuan failover. Pendekatan ini adalah pendorong utama pola hybrid kelangsungan bisnis. Cloud dapat sangat menarik dari sudut pandang biaya, karena memungkinkan Anda menonaktifkan beberapa infrastruktur DR saat tidak digunakan. Untuk mendapatkan solusi DR dengan biaya lebih rendah, solusi cloud memungkinkan bisnis menerima potensi peningkatan nilai RPO dan RTO.

Diagram sebelumnya mengilustrasikan penggunaan cloud sebagai lingkungan pemulihan dari bencana atau kegagalan ke lingkungan lokal.

Varian yang kurang umum (dan jarang diperlukan) dari pola ini adalah pola multi-cloud kelangsungan bisnis. Dalam pola tersebut, lingkungan produksi menggunakan satu penyedia cloud dan lingkungan DR menggunakan penyedia cloud lain. Dengan men-deploy salinan workload di beberapa penyedia cloud, Anda dapat meningkatkan ketersediaan melebihi kemampuan deployment multi-region.

Mengevaluasi DR di beberapa cloud dibandingkan menggunakan satu penyedia cloud dengan region yang berbeda memerlukan analisis menyeluruh terhadap beberapa pertimbangan, termasuk hal berikut:

• Kemudahan dikelola
• Keamanan
• Kelayakan secara keseluruhan.
• Biaya
  • Potensi biaya transfer data keluar dari lebih dari satu penyedia cloud dapat mahal dengan komunikasi antar-cloud yang berkelanjutan.
  • Mungkin ada volume traffic yang tinggi saat mereplikasi database.
  • TCO dan biaya pengelolaan infrastruktur jaringan antar-cloud.

Catatan: Untuk informasi selengkapnya tentang cara Cross-Cloud Interconnect dapat membantu Anda menurunkan TCO dan mengurangi kompleksitas, lihat Mengumumkan Cross-Cloud Interconnect: konektivitas yang lancar ke semua cloud Anda.

Jika data Anda harus tetap berada di negara Anda untuk memenuhi persyaratan peraturan, menggunakan penyedia cloud kedua yang juga berada di negara Anda sebagai DR dapat menjadi opsi. Penggunaan penyedia cloud kedua tersebut mengasumsikan bahwa tidak ada opsi untuk menggunakan lingkungan on-premise guna membuat penyiapan hybrid. Untuk menghindari pembuatan ulang arsitektur solusi cloud, sebaiknya penyedia cloud kedua Anda menawarkan semua kemampuan dan layanan yang diperlukan di region.

Pertimbangan desain

• Ekspektasi DR: Target RPO dan RTO yang ingin dicapai bisnis Anda harus mendorong arsitektur DR dan perencanaan build.
• Arsitektur solusi: Dengan pola ini, Anda perlu mereplikasi fungsi dan kemampuan yang ada di lingkungan lokal untuk memenuhi ekspektasi DR Anda. Oleh karena itu, Anda perlu menilai kelayakan dan kemampuan rehosting, pemfaktoran ulang, atau re-arsitektur aplikasi untuk memberikan fungsi dan performa yang sama (atau lebih dioptimalkan) di lingkungan cloud.
• Mendesain dan mem-build: Mem-build zona landing hampir selalu menjadi prasyarat untuk men-deploy workload perusahaan di lingkungan cloud. Untuk mengetahui informasi selengkapnya, lihat Desain zona landing di Google Cloud.

• Pemanggilan DR: Penting bagi desain dan proses DR Anda untuk mempertimbangkan pertanyaan berikut:

  • Apa yang memicu skenario DR? Misalnya, DR mungkin dipicu oleh kegagalan fungsi atau sistem tertentu di situs utama.
  • Bagaimana failover ke lingkungan DR dipanggil? Apakah ini proses persetujuan manual, atau dapat diotomatiskan untuk mencapai target RTO yang rendah?
  • Bagaimana mekanisme notifikasi dan deteksi kegagalan sistem harus dirancang untuk memanggil failover sesuai dengan RTO yang diharapkan?
  • Bagaimana traffic dialihkan ke lingkungan DR setelah kegagalan terdeteksi?

  Validasi jawaban Anda atas pertanyaan-pertanyaan ini melalui pengujian.

• Pengujian: Uji dan evaluasi failover ke DR secara menyeluruh. Pastikan hal tersebut memenuhi ekspektasi RPO dan RTO Anda. Tindakan ini dapat memberi Anda lebih banyak keyakinan untuk memanggil DR jika diperlukan. Setiap kali perubahan atau update baru dilakukan pada solusi teknologi atau proses, lakukan pengujian lagi.

• Keterampilan tim: Satu atau beberapa tim teknis harus memiliki keterampilan dan keahlian untuk mem-build, mengoperasikan, dan memecahkan masalah beban kerja produksi di lingkungan cloud, kecuali jika lingkungan Anda dikelola oleh pihak ketiga.

Kelebihan

Penggunaan Google Cloud untuk kelangsungan bisnis menawarkan beberapa keuntungan:

• Google Cloud memiliki banyak region di seluruh dunia yang dapat dipilih, Anda dapat menggunakannya untuk mencadangkan atau mereplikasi data ke situs lain dalam benua yang sama. Anda juga dapat mencadangkan atau mereplikasi data ke situs di benua yang berbeda.
• Google Cloud menawarkan kemampuan untuk menyimpan data di Cloud Storage dalam bucket dual-region atau multi-region. Data disimpan secara redundan di setidaknya dua region geografis yang terpisah. Data yang disimpan di bucket dual-region dan multi-region direplikasi di seluruh region geografis menggunakan replikasi default.
  • Bucket dual-region menyediakan redundansi geografis untuk mendukung kontinuitas bisnis dan rencana DR. Selain itu, untuk mereplikasi lebih cepat, dengan RPO yang lebih rendah, objek yang disimpan di dual-region dapat secara opsional menggunakan replikasi turbo di seluruh region tersebut.
  • Demikian pula, replikasi multi-region memberikan redundansi di beberapa region, dengan menyimpan data Anda dalam batas geografis multi-region.
• Memberikan satu atau beberapa opsi berikut untuk mengurangi belanja modal dan biaya operasional guna membangun DR:
  • Instance VM yang dihentikan hanya dikenai biaya penyimpanan dan jauh lebih murah daripada instance VM yang berjalan. Artinya, Anda dapat meminimalkan biaya pemeliharaan sistem standby cold.
  • Model bayar per penggunaan Google Cloud berarti Anda hanya membayar kapasitas penyimpanan dan komputasi yang benar-benar Anda gunakan.
  • Kemampuan elastisitas, seperti penskalaan otomatis, memungkinkan Anda secara otomatis menskalakan atau memperkecil lingkungan DR sesuai kebutuhan.

Misalnya, diagram berikut menunjukkan aplikasi yang berjalan di lingkungan lokal (produksi) yang menggunakan komponen pemulihan di Google Cloud dengan Compute Engine, Cloud SQL, dan Cloud Load Balancing. Dalam skenario ini, database disediakan sebelumnya menggunakan database berbasis VM atau menggunakan database terkelola Google Cloud, seperti Cloud SQL, untuk pemulihan yang lebih cepat dengan replikasi data berkelanjutan. Anda dapat meluncurkan VM Compute Engine dari snapshot yang telah dibuat sebelumnya untuk mengurangi biaya selama operasi normal. Dengan penyiapan ini, dan setelah peristiwa kegagalan, DNS harus mengarah ke alamat IP eksternal Cloud Load Balancing.

Agar aplikasi dapat beroperasi di cloud, Anda perlu menyediakan VM web dan aplikasi. Bergantung pada tingkat RTO yang ditargetkan dan kebijakan perusahaan, seluruh proses untuk memanggil DR, menyediakan beban kerja di cloud, dan mengubah rute traffic, dapat diselesaikan secara manual atau otomatis.

Untuk mempercepat dan mengotomatiskan penyediaan infrastruktur, pertimbangkan untuk mengelola infrastruktur sebagai kode. Anda dapat menggunakan Cloud Build, yang merupakan layanan continuous integration, untuk menerapkan manifes Terraform secara otomatis ke lingkungan Anda. Untuk informasi selengkapnya, lihat artikel Mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps.

Praktik terbaik

Saat Anda menggunakan pola kelangsungan bisnis, pertimbangkan praktik terbaik berikut:

• Buat rencana pemulihan dari bencana yang mendokumentasikan infrastruktur Anda beserta prosedur failover dan pemulihan.
• Pertimbangkan tindakan berikut berdasarkan analisis dampak bisnis Anda dan target RPO dan RTO yang diperlukan yang diidentifikasi:
  • Tentukan apakah pencadangan data ke Google Cloud sudah memadai, atau apakah Anda perlu mempertimbangkan strategi DR lain (sistem standby cold, warm, atau hot).
  • Tentukan layanan dan produk yang dapat Anda gunakan sebagai elemen penyusun untuk rencana DR.
  • Buat skenario DR yang berlaku untuk aplikasi dan data sebagai bagian dari strategi DR yang Anda pilih.
• Pertimbangkan untuk menggunakan pola handover jika Anda hanya mencadangkan data. Atau, pola mesh mungkin menjadi opsi yang baik untuk mereplikasi arsitektur jaringan lingkungan yang ada.
• Minimalkan dependensi antara sistem yang berjalan di lingkungan berbeda, terutama saat komunikasi ditangani secara sinkron. Dependensi ini dapat memperlambat performa dan mengurangi ketersediaan keseluruhan.

• Hindari masalah split brain. Jika mereplikasi data secara dua arah di seluruh lingkungan, Anda mungkin akan terkena masalah split-brain. Masalah split-brain terjadi saat dua lingkungan yang mereplikasi data secara dua arah kehilangan komunikasi satu sama lain. Pemisahan ini dapat menyebabkan sistem di kedua lingkungan menyimpulkan bahwa lingkungan lain tidak tersedia dan bahwa sistem tersebut memiliki akses eksklusif ke data. Hal ini dapat menyebabkan modifikasi data yang bertentangan. Ada dua cara umum untuk menghindari masalah split-brain:

  • Menggunakan lingkungan komputasi ketiga. Lingkungan ini memungkinkan sistem memeriksa kuorum sebelum mengubah data.

  • Izinkan modifikasi data yang bertentangan untuk direkonsiliasi setelah konektivitas dipulihkan.

    Dengan database SQL, Anda dapat menghindari masalah split-brain dengan membuat instance utama asli tidak dapat diakses sebelum klien mulai menggunakan instance utama baru. Untuk informasi selengkapnya, lihat Pemulihan dari bencana (disaster recovery) database Cloud SQL.

• Pastikan sistem CI/CD dan repositori artefak tidak menjadi titik tunggal kegagalan. Saat satu lingkungan tidak tersedia, Anda tetap harus dapat men-deploy rilis baru atau menerapkan perubahan konfigurasi.

• Buat semua workload bersifat portabel saat menggunakan sistem standby. Semua beban kerja harus dapat dipindah-pindah (jika didukung oleh aplikasi dan memungkinkan) sehingga sistem tetap konsisten di seluruh lingkungan. Anda dapat mencapai pendekatan ini dengan mempertimbangkan container dan Kubernetes. Dengan menggunakan edisi Google Kubernetes Engine (GKE) Enterprise, Anda dapat menyederhanakan build dan operasi.

• Integrasikan deployment sistem standby ke dalam pipeline CI/CD Anda. Integrasi ini membantu memastikan bahwa versi dan konfigurasi aplikasi konsisten di seluruh lingkungan.

• Pastikan perubahan DNS diterapkan dengan cepat dengan mengonfigurasi DNS Anda dengan nilai time to live yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby saat terjadi bencana.

• Pilih kebijakan DNS dan kebijakan perutean yang sesuai dengan arsitektur dan perilaku solusi Anda. Selain itu, Anda dapat menggabungkan beberapa load balancer regional dengan kebijakan perutean DNS untuk membuat arsitektur load balancing global untuk berbagai kasus penggunaan, termasuk penyiapan campuran.

• Gunakan beberapa penyedia DNS. Saat menggunakan beberapa penyedia DNS, Anda dapat:

  • Tingkatkan ketersediaan dan ketahanan aplikasi dan layanan Anda.

  • Sederhanakan deployment atau migrasi aplikasi hybrid yang memiliki dependensi di seluruh lingkungan lokal dan cloud dengan konfigurasi DNS multi-penyedia.

    Google Cloud menawarkan solusi open source berdasarkan octoDNS untuk membantu Anda menyiapkan dan mengoperasikan lingkungan dengan beberapa penyedia DNS. Untuk informasi selengkapnya, lihat DNS publik multi-penyedia menggunakan Cloud DNS.

• Gunakan load balancer saat menggunakan sistem standby untuk membuat failover otomatis. Perlu diingat bahwa hardware load balancer dapat mengalami kegagalan.

• Gunakan Cloud Load Balancing, bukan load balancer hardware, untuk mendukung beberapa skenario yang terjadi saat menggunakan pola arsitektur ini. Permintaan klien internal atau permintaan klien eksternal dapat dialihkan ke lingkungan utama atau lingkungan DR berdasarkan metrik yang berbeda, seperti pemisahan traffic berbasis bobot. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.

• Pertimbangkan untuk menggunakan Cloud Interconnect atau Cross-Cloud Interconnect jika volume transfer data keluar dari Google Cloud ke lingkungan lain tinggi. 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.

• Pertimbangkan untuk menggunakan solusi partner pilihan Anda di Google Cloud Marketplace untuk membantu memfasilitasi pencadangan data, replikasi, dan tugas lainnya yang memenuhi persyaratan Anda, termasuk target RPO dan RTO.

• Uji dan evaluasi skenario pemanggilan DR untuk memahami seberapa mudah aplikasi dapat pulih dari peristiwa bencana jika dibandingkan dengan nilai RTO target.

• Mengenkripsi komunikasi saat dalam proses pengiriman. Untuk melindungi informasi sensitif, sebaiknya mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.

Pola cloud bursting

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 berada 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 telah diperbarui.
  • 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.

Pola arsitektur hybrid dan multicloud: Langkah berikutnya

• Pelajari cara melakukan pendekatan terhadap arsitektur hybrid dan multicloud serta cara memilih workload yang sesuai.
• Cari tahu lebih lanjut tentang pola arsitektur jaringan yang sesuai untuk pola arsitektur hybrid dan multicloud yang dipilih.
• Pelajari lebih lanjut Arketipe Deployment untuk Aplikasi Cloud.
• Pelajari cara mendesain dan men-deploy aplikasi web e-commerce menggunakan arsitektur yang berbeda, termasuk aplikasi web e-commerce berbasis microservice menggunakan GKE, dan aplikasi web dinamis yang berbasis Serverless API.