Pola arsitektur hybrid dan multi-cloud

Last reviewed 2024-11-27 UTC

Halaman ini memberikan tampilan satu halaman dari semua halaman di Membangun arsitektur hybrid dan multicloud menggunakan Google Cloud. Anda dapat mencetak halaman ini, atau menyimpannya dalam format PDF menggunakan fungsi cetak browser Anda dan memilih opsi Simpan sebagai PDF. Halaman ini tidak menyediakan panel daftar isi (ToC) 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. Bagian 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 multicloud terdiri dari bagian-bagian berikut:

• Membangun arsitektur hybrid dan multicloud: membahas perencanaan strategi untuk merancang penyiapan hybrid dan multicloud dengan Google Cloud.
• Pola arsitektur hybrid dan multicloud: membahas pola arsitektur umum yang dapat diadopsi sebagai bagian dari strategi hybrid dan multicloud (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 yang dapat diulang untuk menyusun beberapa komponen fungsional solusi, aplikasi, atau layanan teknologi 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 solusi teknologi. Demikian pula, aplikasi dapat terdiri dari beberapa tingkat fungsional, modul, atau layanan, dan masing-masing dapat merepresentasikan komponen fungsional dari arsitektur aplikasi. Arsitektur semacam ini dapat distandardisasi 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 API atau antarmuka 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 beban kerja atau komponen aplikasi yang terdistribusi. Artinya, mereka menjalankan aplikasi (atau komponen tertentu dari aplikasi tersebut) di lingkungan komputasi yang paling sesuai dengan pola. Dengan demikian, pola ini dapat memanfaatkan berbagai properti dan karakteristik lingkungan komputasi 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 Anda pilih, Anda harus menggunakan jenis arsitektur deployment yang sesuai. Arsitektur deployment adalah zonal, regional, multi-regional, atau global. Pilihan ini menjadi dasar untuk membangun arsitektur deployment khusus aplikasi. Setiap arketipe deployment menentukan kombinasi domain kegagalan yang memungkinkan aplikasi beroperasi. Domain kegagalan ini dapat mencakup satu atau beberapa Google Cloud zona atau region, dan dapat diperluas untuk menyertakan pusat data lokal atau domain kegagalan di penyedia cloud lain.

Seri ini berisi halaman berikut:

• Pola arsitektur terdistribusi

  • Pola hybrid bertingkat

  • Pola multicloud yang dipartisi

  • Pola hybrid dan multicloud Analytics

  • 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, pertama-tama pertimbangkan 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 Anda mempertimbangkan batasan, buat rencana untuk menghindari atau mengatasinya. Pastikan untuk mempertimbangkan kemampuan unik 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 efek 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 multicloud. Oleh karena itu, penting untuk menilai persyaratan latensi aplikasi Anda dan sensitivitasnya terhadap penundaan jaringan. Aplikasi yang dapat mentoleransi latensi lebih cocok untuk kandidat deployment terdistribusi awal di lingkungan hybrid atau multicloud.

Arsitektur status sementara versus akhir

Untuk menentukan ekspektasi dan potensi implikasi 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 menggunakan arsitektur hybrid atau multicloud dalam waktu lama atau secara permanen, Anda dapat mempertimbangkan untuk menggunakan Cloud Interconnect. Untuk mengurangi biaya transfer data keluar dan mengoptimalkan performa jaringan konektivitas hybrid, Cloud Interconnect memberikan diskon untuk biaya transfer data keluar yang memenuhi kondisi tarif transfer data yang didiskon.

Keandalan

Keandalan adalah pertimbangan utama saat merancang 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 penting untuk meningkatkan ketersediaan keseluruhan aplikasi. 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 butuhkan 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 antara komponen atau layanan, ketersediaan gabungan untuk aplikasi mungkin lebih tinggi atau lebih rendah daripada untuk layanan atau komponen individual. Untuk mengetahui informasi selengkapnya, lihat Ketersediaan komposit: menghitung ketersediaan keseluruhan infrastruktur cloud.

Untuk mencapai tingkat keandalan sistem yang Anda inginkan, tentukan metrik keandalan yang jelas dan rancang aplikasi agar dapat melakukan pemulihan mandiri dan mengatasi gangguan secara efektif di berbagai lingkungan. Untuk membantu Anda menentukan cara yang tepat untuk mengukur pengalaman pelanggan terhadap layanan Anda, lihat Menentukan keandalan berdasarkan sasaran pengalaman pengguna.

Konektivitas hybrid dan multicloud

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

Kemudahan dikelola

Alat pemantauan dan pengelolaan yang konsisten dan terpadu sangat penting untuk penyiapan hybrid dan multicloud yang berhasil (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, semakin rumit 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 dalam lingkungan multicloud memiliki metrik dan alat penagihan sendiri. Untuk memberikan visibilitas yang lebih baik dan dasbor terpadu, pertimbangkan untuk menggunakan alat pengelolaan dan pengoptimalan biaya multicloud. Misalnya, saat membangun solusi yang mengutamakan cloud di beberapa lingkungan cloud, produk, harga, diskon, dan alat pengelolaan setiap penyedia dapat menimbulkan 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 Google Cloud Blok Pengelolaan Biaya Cloud Looker, Anda dapat membuat tampilan terpusat dari biaya multicloud Anda. Tampilan ini dapat membantu memberikan tampilan pelaporan gabungan atas 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 efektif, 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 Google Cloud Well-Architected Framework: Pengoptimalan biaya.

Perpindahan data

Perpindahan 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. Google Cloud's comprehensive set of data movement options makes it possible for businesses to meet their specific needs and adopt hybrid and multicloud architectures without compromising simplicity, efficiency, or performance.

Keamanan

Saat memigrasikan aplikasi ke cloud, penting untuk mempertimbangkan kemampuan keamanan yang mengutamakan cloud seperti konsistensi, kemampuan pengamatan, dan visibilitas keamanan terpadu. Setiap penyedia layanan cloud publik memiliki pendekatan, praktik terbaik, dan kemampuan keamanan sendiri. Penting untuk menganalisis dan menyelaraskan kemampuan ini untuk membangun arsitektur keamanan fungsional yang standar. 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 peluang munculnya kerumitan pada arsitektur saat aplikasi atau volume traffic Anda meningkat. Selain itu, mendesain dan membangun 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 berbagai area dan mencakup berbagai elemen, seperti identitas, pengelolaan resource, keamanan, dan jaringan. Untuk mengetahui informasi selengkapnya, lihat Desain landing zone di Google Cloud.

Dokumen berikut dalam rangkaian ini menjelaskan pola arsitektur terdistribusi lainnya:

• Pola hybrid bertingkat
• Pola multicloud 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 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 kualitas baru, update software dapat dilakukan secara rutin. Karena aplikasi frontend biasanya mengandalkan aplikasi backend untuk menyimpan dan mengelola data—dan mungkin logika bisnis dan pemrosesan input pengguna—aplikasi ini sering kali stateless atau hanya mengelola volume data yang terbatas.

Agar dapat diakses dan digunakan, Anda dapat membangun 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 dalam pengelolaannya:

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

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

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

Menempatkan lapisan ini ke dalam penampung memisahkan kebutuhan teknisnya, seperti persyaratan penskalaan, dan membantu memigrasikannya dengan pendekatan bertahap. Selain itu, Anda dapat men-deploynya di layanan cloud yang independen terhadap platform yang dapat di-deploy di berbagai lingkungan, menggunakan pengelolaan otomatis, dan menskalakan dengan platform terkelola cloud, seperti Cloud Run atau Google Kubernetes Engine (GKE) Enterprise Edition. Selain itu, database yang dikelolaGoogle 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 semua komponen aplikasi backend yang ada di lingkungan komputasi pribadinya. Bergantung pada skala dan desain spesifik aplikasi, Anda dapat memigrasikan komponen aplikasi frontend berdasarkan kasus per kasus. Untuk informasi selengkapnya, lihat Bermigrasi ke Google Cloud.

Jika Anda memiliki aplikasi yang sudah ada dengan komponen backend dan frontend yang dihosting di lingkungan lokal, pertimbangkan batas arsitektur Anda saat ini. Misalnya, saat aplikasi Anda diskalakan dan tuntutan terhadap performa dan keandalannya meningkat, Anda harus mulai mengevaluasi apakah bagian aplikasi Anda harus di-refactor 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. Penting juga untuk mempertimbangkan biaya, waktu, dan risiko yang terlibat dalam migrasi tersebut.

Diagram berikut menunjukkan pola arsitektur hybrid bertingkat yang umum.

Dalam diagram sebelumnya, permintaan klien dikirim ke frontend aplikasi yang dihosting di Google Cloud. Selanjutnya, frontend aplikasi mengirimkan data kembali ke lingkungan lokal tempat backend aplikasi dihosting (idealnya melalui gateway API).

Dengan pola arsitektur hybrid bertingkat, Anda dapat memanfaatkan infrastruktur dan layanan globalGoogle 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 menyediakan infrastruktur secara berlebihan. Ada berbagai arsitektur yang dapat Anda gunakan untuk membangun dan menjalankan aplikasi web yang skalabel di Google Cloud. Setiap arsitektur memiliki kelebihan dan kekurangan untuk persyaratan yang berbeda.

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

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

Seiring waktu, jumlah aplikasi yang Anda deploy ke cloud publik dapat meningkat hingga Anda 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 secara lokal. Namun, jika berlaku dan mematuhi, penggunaan kemampuan Sensitive Data Protection 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 di hardware khusus yang disediakan dan dikelola oleh Google serta terpisah dari pusat data. Google Cloud Untuk memastikan Distributed Cloud memenuhi persyaratan Anda saat ini dan di masa mendatang, ketahui batasan Distributed Cloud jika dibandingkan dengan zona GKE berbasis cloud konvensional.

Kelebihan

Berfokus pada aplikasi frontend terlebih dahulu memiliki beberapa keuntungan, termasuk 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.
• Karena 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 tanpa status. Untuk mengetahui informasi selengkapnya, tonton video Cara mem-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/continuous deployment (CI/CD). Anda dapat menggunakan CI/CD untuk mengirim update secara efisien dan otomatis. Untuk mengetahui informasi selengkapnya, lihat CI/CD di Google Cloud.
• Frontend yang sensitif terhadap performa dengan beban traffic yang bervariasi dapat memperoleh manfaat besar dari load balancing, deployment multi-regional, kemampuan serverless, dan penskalaan otomatis yang didukung oleh deployment berbasis cloud (idealnya dengan arsitektur tanpa status).

• Dengan mengadopsi microservice dengan container 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 dalam 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 di mana setiap tim pengembangan dapat memilih teknologi dan kode yang mereka sukai.
  • 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:

  • Memisahkan 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 lain 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 membangun dan mengelola proxy API dalam model deployment hybrid. Untuk mengetahui informasi selengkapnya, lihat Arsitektur yang tidak terkait erat, termasuk arsitektur microservice dan monolitik bertingkat.

Praktik terbaik

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

Praktik terbaik untuk mengurangi kerumitan

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 tingkat throughput yang sesuai. Dari sudut pandang keamanan, komunikasi harus dikontrol dan memiliki perincian yang baik. Idealnya, Anda harus mengekspos komponen aplikasi menggunakan API yang aman. Untuk mengetahui informasi selengkapnya, lihat Egress dengan gerbang.

• Untuk meminimalkan latensi komunikasi antarlingkungan, pilih Google Cloud region yang secara geografis dekat dengan lingkungan komputasi pribadi tempat komponen backend aplikasi Anda dihosting. Untuk mengetahui 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 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 keGoogle Cloud dibandingkan dengan traffic keluar yang keluar dari Google Cloud. Namun, Anda harus mengetahui perkiraan volume transfer data keluar yang keluar dari 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 dapat mengurangi biaya 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 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 deploy gateway atau proxy API sebagai facade yang menyatukan, jika berlaku. Gateway atau proxy ini berfungsi sebagai titik kontrol terpusat dan melakukan tindakan berikut:

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

• Untuk memfasilitasi 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 Anda. Pendekatan ini memungkinkan migrasi workload bertahap ke Google Cloud dengan gangguan layanan minimal atau tanpa gangguan layanan, sehingga memastikan transisi yang lancar untuk layanan terdistribusi. Untuk mengetahui informasi selengkapnya, lihat Ringkasan grup endpoint jaringan konektivitas hybrid.

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

  • Menyediakan API berperforma tinggi dengan Apigee dan Cloud CDN, untuk mengurangi latensi, menghosting API secara global, dan meningkatkan ketersediaan untuk musim traffic puncak. Untuk mengetahui informasi selengkapnya, tonton video Menyediakan API berperforma tinggi dengan Apigee dan Cloud CDN di YouTube.
  • Terapkan pengelolaan traffic lanjutan.
  • Gunakan Cloud Armor sebagai layanan perlindungan DDoS dan keamanan jaringan untuk melindungi API Anda.
  • Mengelola load balancing yang efisien di seluruh gateway di beberapa region. Untuk mengetahui informasi selengkapnya, tonton video Securing APIs and Implementing multi-region failover with Private Service Connect and 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 antar-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.

• Deploy sistem CI/CD dan manajemen konfigurasi di cloud publik. Untuk mengetahui 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, perbedaan tersebut dapat menyebabkan kompleksitas tambahan.
• Memperlakukan API sebagai antarmuka backend 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, tersedia berbagai opsi, termasuk arsitektur monolitik, serverless, berbasis peristiwa, dan microservice. Untuk memilih arsitektur yang paling sesuai, nilai opsi ini secara menyeluruh berdasarkan persyaratan aplikasi Anda saat ini dan di masa mendatang. Untuk membantu Anda membuat keputusan arsitektur yang selaras dengan tujuan bisnis dan teknis Anda, 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 hybrid bertingkat, 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 dan kemudian bermigrasi ke Google Cloud pada waktu yang berbeda. Hal ini membantu ketika workload sangat bergantung pada workload lain dan tidak dapat dimigrasikan secara terpisah, atau untuk menggunakan portabilitas workload hibrida guna menggunakan resource terbaik yang tersedia di setiap lingkungan. Dalam semua kasus, GKE Enterprise dapat menjadi teknologi pendukung utama. Untuk 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 lokasi yang tidak memiliki dukungan penampungan atau memerlukan waktu dan resource yang signifikan untuk memodernisasi dalam jangka pendek.

    Untuk mengetahui informasi selengkapnya tentang mendesain dan memfaktorkan ulang aplikasi monolitik ke arsitektur microservice untuk 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 beragam kebutuhan penyimpanan data. Namun, pilihan ini sangat bergantung pada kasus penggunaan Anda. Untuk mengetahui informasi selengkapnya tentang opsi penyimpanan data untuk backend aplikasi berbasis konten dan modalitas yang efektif, lihat Opsi Penyimpanan Data untuk Aplikasi Web Berbasis Konten. Lihat juga Opsi database Anda, dijelaskan. Google Cloud

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 di lingkungan komputasi yang optimal yang memperhitungkan pendorong dan pertimbangan multicloud yang dibahas di bagian pertama seri ini.

Diagram berikut menunjukkan pola arsitektur multicloud yang dipartisi.

Pola arsitektur ini dapat dibangun dengan dua cara berbeda. Pendekatan pertama didasarkan pada deployment komponen aplikasi di lingkungan cloud publik yang berbeda. Pendekatan ini juga disebut sebagai arsitektur komposit dan merupakan pendekatan yang sama dengan pola arsitektur hybrid bertingkat. Namun, alih-alih menggunakan lingkungan lokal dengan cloud publik, lingkungan ini menggunakan setidaknya dua lingkungan cloud. Dalam arsitektur komposit, satu workload atau aplikasi menggunakan komponen dari lebih dari satu cloud. Pendekatan kedua men-deploy aplikasi yang berbeda di lingkungan cloud publik yang berbeda. 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 merger dan akuisisi antara dua perusahaan.
• Untuk meningkatkan fleksibilitas dan mengakomodasi beragam 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 dalam deployment multi-regional atau cloud global. Jika perusahaan diwajibkan untuk mematuhi peraturan residensi data di region atau negara tertentu, maka perusahaan tersebut harus memilih dari penyedia cloud yang tersedia di lokasi tersebut jika penyedia cloud utamanya tidak memiliki region cloud di sana.

Dengan pola arsitektur multicloud yang dipartisi, Anda dapat 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 membangun solusi untuk mengatasi kompleksitas multicloud dengan tata kelola, operasi, dan postur 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 menawarkan fleksibilitas untuk memigrasikan, membangun, dan mengoptimalkan portabilitas aplikasi di seluruh lingkungan multicloud sambil meminimalkan keterikatan, dan membantu Anda memenuhi persyaratan peraturan. Misalnya, Anda dapat menghubungkan Google Cloud dengan Oracle Cloud Infrastructure (OCI), untuk membangun 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 mengetahui informasi selengkapnya, lihat Google Cloud dan Oracle Cloud Infrastructure – 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 membangun 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 Pendorong, pertimbangan, strategi, dan pendekatan, penting untuk melakukan penilaian kelayakan yang mendetail terhadap setiap potensi manfaat. Penilaian Anda harus mempertimbangkan dengan cermat tantangan langsung atau tidak langsung yang terkait tantangan 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 awalnya.

Berikut adalah beberapa keuntungan utama pola arsitektur multicloud yang dipartisi:

• Dalam skenario di mana Anda mungkin perlu meminimalkan keterikatan pada satu penyedia cloud, Anda dapat mendistribusikan aplikasi ke beberapa penyedia cloud. Dengan demikian, Anda dapat mengurangi ketergantungan pada vendor secara relatif dengan kemampuan untuk mengubah paket (sampai batas tertentu) di seluruh penyedia cloud Anda. Open Cloud membantu menghadirkan kemampuan Google Cloud , seperti GKE Enterprise, ke berbagai lokasi fisik. Dengan memperluas kemampuan di lokasi, di beberapa cloud publik, dan di edge, platform ini memberikan fleksibilitas, ketangkasan, dan mendorong transformasi. Google Cloud

• Karena alasan peraturan, Anda dapat menyajikan 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 titik kehadiran. Pola ini sangat berguna saat menggunakan konektivitas multicloud 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, di mana aplikasi dan layanan kedua perusahaan dapat dihosting di lingkungan cloud publik yang berbeda.

Praktik terbaik

• Mulailah dengan men-deploy beban kerja yang tidak penting. Deployment awal ini di cloud sekunder kemudian dapat berfungsi sebagai pola untuk deployment atau migrasi di masa mendatang. Namun, pendekatan ini mungkin tidak berlaku dalam situasi ketika beban kerja tertentu secara hukum atau peraturan diwajibkan 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 CI/CD dan alat untuk deployment dan pemantauan konsisten di seluruh lingkungan cloud.
• Pilih pola arsitektur jaringan optimal yang memberikan solusi komunikasi 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 berjaring atau salah satu pola jaringan berpintu, berdasarkan persyaratan bisnis dan teknis spesifik Anda.
• Untuk memenuhi ekspektasi ketersediaan dan performa Anda, desain untuk ketersediaan tinggi (HA) end-to-end, latensi rendah, dan tingkat throughput yang sesuai.

• Untuk melindungi informasi sensitif, sebaiknya enkripsi 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 Cross-Cloud Interconnect.

• Jika Anda menggunakan beberapa CDN sebagai bagian dari pola arsitektur yang dipartisi 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, mungkin, biayanya.

• Perluas 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 mengetahui 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 deploy gateway atau proxy API sebagai facade yang menyatukan, jika berlaku. Gateway atau proxy ini berfungsi sebagai titik kontrol terpusat dan melakukan tindakan berikut:

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

• Dalam beberapa kasus berikut, penggunaan Cloud Load Balancing dengan gateway API 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 API Apigee di berbagai region.

  • Meningkatkan performa dengan Cloud CDN.

  • Menyediakan 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 mengetahui informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

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

Pola hybrid dan multicloud Analytics

Dokumen ini membahas bahwa tujuan pola hybrid dan multicloud analytics 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 hybrid dan multicloud analytics adalah untuk memanfaatkan pemisahan yang sudah ada ini dengan menjalankan beban kerja transaksional dan analisis di dua lingkungan komputasi yang berbeda. Data mentah diekstrak terlebih dahulu dari workload yang berjalan di lingkungan komputasi pribadi, lalu dimuat keGoogle Cloud, tempat data tersebut digunakan untuk pemrosesan analytics. Beberapa hasilnya mungkin dimasukkan kembali ke sistem transaksional.

Diagram berikut mengilustrasikan kemungkinan arsitektur secara konseptual dengan menunjukkan potensi 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 pemindahan data, 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 transportasi dasar pola analisis hybrid dan multicloud yang memerlukan transfer data bervolume 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, yang memindahkan data dari lingkungan komputasi pribadi atau cloud lain ke Google Cloud—mungkin tidak dikenai biaya.
• Workload analytics sering kali perlu memproses data dalam jumlah besar dan dapat mengalami lonjakan, 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 penyediaan peralatan komputasi secara berlebihan.
• Google Cloud menyediakan serangkaian layanan lengkap untuk mengelola data di sepanjang siklus prosesnya, mulai dari akuisisi awal hingga pemrosesan dan analisis hingga visualisasi akhir.
  • Layanan perpindahan data di Google Cloud menyediakan rangkaian produk lengkap untuk memindahkan, mengintegrasikan, dan mengubah data dengan lancar dalam berbagai cara.
  • Cloud Storage sangat cocok untuk mem-build data lake.

• Google Cloud membantu Anda memodernisasi dan mengoptimalkan platform data untuk mengatasi data silo. Menggunakan data lakehouse membantu menstandardisasi berbagai format penyimpanan. Lakehouse data juga dapat memberikan fleksibilitas, skalabilitas, dan ketangkasan yang diperlukan untuk membantu memastikan 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. Selain itu, alat 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 mengetahui 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 multicloud analytics, pertimbangkan praktik terbaik umum berikut:

• Gunakan pola jaringan peralihan untuk memungkinkan penyerapan data. Jika hasil analisis perlu dimasukkan kembali ke sistem transaksional, Anda dapat menggabungkan pola handover dan traffic keluar dengan akses terbatas.
• 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 kemudian 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 yang terkelola sepenuhnya dan mengutamakan cloud untuk membangun dan mengelola pipeline data.
• Untuk menemukan, mengklasifikasikan, dan melindungi aset data berharga Anda, pertimbangkan untuk menggunakan Google Cloud kemampuan Sensitive Data Protection, seperti teknik de-identifikasi. Teknik ini memungkinkan Anda menyamarkan, mengenkripsi, dan mengganti data sensitif—seperti informasi identitas pribadi (PII)—menggunakan kunci yang dibuat secara acak atau ditentukan sebelumnya, jika berlaku dan sesuai.

• Saat Anda 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 mengetahui informasi selengkapnya, lihat Migrasi ke Google Cloud: Mentransfer set data besar.

• Jika transfer atau pertukaran data antara Google Cloud dan cloud lain diperlukan dalam jangka panjang dengan volume traffic yang tinggi, Anda harus mengevaluasi penggunaan Google Cloud Cross-Cloud Interconnect untuk membantu Anda membangun konektivitas khusus bandwidth tinggi antaraGoogle 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 analytics, 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 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 edge hybrid, 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 memberikan 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.
• Proyek 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 modern. Misalnya, layanan yang mungkin menjalankan gateway API dalam container seperti Apigee Hybrid). Hal ini memungkinkan aplikasi dan sistem lama diintegrasikan dengan layanan yang dimodernisasi, seperti solusi IoT.

Praktik terbaik

Pertimbangkan rekomendasi berikut saat menerapkan pola arsitektur hybrid edge:

• 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 di 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 partnerGoogle Cloud untuk menyederhanakan penyediaan dan pengelolaan konektivitas yang 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 hybrid, Anda dapat menggunakan GKE Enterprise untuk arsitektur ini (jika container digunakan di seluruh lingkungan). Pertimbangkan opsi konektivitas yang memungkinkan yang harus 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 dapat bertahan selama gangguan konektivitas sementara keGoogle Cloud, jangan gunakan GKE Enterprise saat terputus dari Google Cloud sebagai mode kerja nominal. Untuk mengetahui informasi selengkapnya, lihat Dampak terputusnya koneksi sementara dari Google Cloud.
• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai layanan backend dan edge, sebaiknya deploy gateway atau proxy API sebagai facade terpadu jika memungkinkan. Gateway atau proxy ini berfungsi sebagai titik kontrol terpusat dan melakukan tindakan berikut:
  • Menerapkan langkah-langkah keamanan tambahan.
  • Melindungi aplikasi klien dan layanan lain dari perubahan kode backend.
  • Memfasilitasi jalur audit untuk komunikasi antara semua aplikasi lintas lingkungan dan komponen yang tidak terikat.
  • 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 lingkunganGoogle 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 dalam 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 mengandalkan deployment aplikasi yang sama secara redundan di beberapa lingkungan komputasi. Tujuan deployment ini 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 untuk lingkungan produksi dan datanya. Perubahan 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 mungkin tampak berisiko dan dapat menyimpang dari praktik terbaik yang ada atau dari upaya Anda untuk meminimalkan perbedaan di antara lingkungan Anda. Meskipun kekhawatiran tersebut dibenarkan, kekhawatiran tersebut tidak berlaku jika Anda membedakan tahapan 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. Hal ini juga dikenal sebagai pengujian beban.
• Pengujian bertahap atau deployment: Memverifikasi bahwa prosedur deployment berfungsi.
• Produksi: Merilis aplikasi baru atau yang 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 disamakan 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 harus 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 non-fungsional. 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 non-fungsional dari lingkungan lain.

Seperti yang diilustrasikan dalam diagram berikut, lingkungan pengujian dan pengembangan dibangun di atas 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 di-roll out ke lingkungan produksi setelah tahap pengujian. Namun, karena infrastruktur yang mendasari kedua lingkungan tidak identik, pendekatan pengujian beban performa ini tidak valid.

Skenario berikut dapat sangat 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 pendukung utama untuk pendekatan ini.
  • Memastikan portabilitas workload dan menghilangkan perbedaan antarlingkungan komputasi. Dengan mesh layanan zero trust, Anda dapat mengontrol dan mempertahankan pemisahan komunikasi yang diperlukan antara lingkungan yang berbeda.
• Jalankan lingkungan pengembangan dan pengujian fungsional di cloud publik. Lingkungan ini dapat setara secara fungsional dengan lingkungan lainnya, tetapi mungkin berbeda dalam aspek nonfungsional, seperti performa. Konsep ini diilustrasikan dalam diagram sebelumnya.
• Jalankan lingkungan untuk pengujian produksi, staging, serta performa (pengujian beban) dan keandalan di lingkungan komputasi pribadi, sehingga memastikan kesetaraan fungsional dan nonfungsional.

Pertimbangan Desain

• Kebutuhan bisnis: Setiap strategi deployment dan rilis untuk aplikasi memiliki kelebihan dan kekurangannya masing-masing. Untuk memastikan bahwa pendekatan yang Anda pilih sesuai dengan persyaratan spesifik Anda, dasarkan pilihan Anda pada penilaian menyeluruh terhadap kebutuhan dan batasan bisnis Anda.
• Perbedaan lingkungan: Sebagai bagian dari pola ini, tujuan utama penggunaan lingkungan cloud ini adalah untuk pengembangan dan pengujian. Status akhirnya 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 infrastruktur hardware, misalnya, sistem keamanan yang melakukan inspeksi traffic.
• Tata kelola: Untuk mengontrol apa yang boleh dikembangkan perusahaan Anda di cloud dan data apa yang dapat digunakan untuk pengujian, gunakan proses persetujuan dan tata kelola. 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 dapat diukur yang selaras dengan standar penjaminan 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 tetap memerlukan kemampuan redundan dan kemampuan untuk menguji berbagai skenario kegagalan. Persyaratan skenario kegagalan Anda dapat 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 memulai dan menghentikan lingkungan secara otomatis 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 berbagai lingkungan.

Praktik terbaik

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

• Tentukan persyaratan komunikasi aplikasi Anda, termasuk desain keamanan dan jaringan 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 komunikasi diperlukan di seluruh lingkungan, komunikasi harus dilakukan secara terkontrol.

• Strategi pengujian dan deployment aplikasi yang Anda pilih harus sesuai dengan tujuan dan persyaratan bisnis Anda. Hal ini dapat mencakup meluncurkan perubahan tanpa periode nonaktif atau menerapkan 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 mengetahui 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 container 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 mengetahui informasi selengkapnya, lihat Solusi DevOps di Google Cloud.

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

• 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 mengetahui informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

• Jika workload pengujian dan produksi dikelola oleh tim yang berbeda, penggunaan alat yang terpisah mungkin dapat diterima. Namun, penggunaan alat yang sama dengan izin melihat yang berbeda dapat membantu mengurangi upaya dan kompleksitas 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 enkripsi 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.

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

Produk OSS	Kompatibel dengan Google Cloud produk
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 dalam mempertimbangkan 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 serta menghindari titik tunggal kegagalan, Anda dapat meminimalkan risiko bencana alam yang memengaruhi infrastruktur lokal. Skenario kegagalan lainnya mencakup kegagalan sistem yang parah, serangan siber, atau bahkan kesalahan konfigurasi sistem.

Mengoptimalkan sistem agar dapat bertahan dari 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 mengetahui informasi selengkapnya tentang cara merancang dan mengoperasikan layanan yang andal di Google Cloud, lihat pilar keandalan Google Cloud Framework yang Dirancang dengan Baik dan blok penyusun keandalan di Google Cloud.

Pola arsitektur ini mengandalkan deployment aplikasi yang redundan di beberapa lingkungan komputasi. Dalam pola ini, Anda men-deploy aplikasi yang sama di beberapa lingkungan komputasi dengan tujuan untuk 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 terjadi 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 terjadi gangguan. Secara umum, strategi dan rencana DR sering kali 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: toleransi durasi kehilangan data (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 yang 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 didorong oleh analisis dampak bisnis. Misalnya, kerugian finansial yang dialami akibat downtime selama beberapa menit saja bagi organisasi layanan keuangan mungkin jauh lebih besar daripada 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 yaitu menggunakan lingkungan komputasi berbasis cloud publik untuk tujuan failover. Pendekatan ini adalah pendorong utama pola hybrid kelangsungan bisnis. Cloud bisa sangat menarik dari sudut pandang biaya, karena memungkinkan Anda menonaktifkan beberapa infrastruktur DR saat tidak digunakan. Untuk mendapatkan solusi DR dengan biaya yang lebih rendah, solusi cloud memungkinkan bisnis menerima potensi peningkatan nilai RPO dan RTO.

Diagram sebelumnya menggambarkan penggunaan cloud sebagai lingkungan failover atau pemulihan bencana untuk 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 versus 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 bisa mahal dengan komunikasi antar-cloud yang berkelanjutan.
  • Volume traffic bisa tinggi saat mereplikasi database.
  • TCO dan biaya pengelolaan infrastruktur jaringan antar-cloud.

Catatan: Untuk mengetahui informasi selengkapnya tentang cara Cross-Cloud Interconnect dapat membantu Anda menurunkan TCO dan mengurangi kompleksitas, lihat Pengumuman Cross-Cloud Interconnect: konektivitas 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 lokal guna membuat penyiapan hybrid. Untuk menghindari arsitektur ulang solusi cloud Anda, idealnya penyedia cloud kedua Anda harus menawarkan semua kapabilitas dan layanan yang diperlukan di dalam region.

Pertimbangan desain

• Ekspektasi DR: Target RPO dan RTO yang ingin dicapai bisnis Anda harus mendorong perencanaan pembangunan dan arsitektur DR Anda.
• 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 kemungkinan rehosting, refactoring, atau rearchitecting aplikasi Anda untuk menyediakan fungsi dan performa yang sama (atau lebih optimal) di lingkungan cloud.
• Desain dan bangun: Membangun zona landing hampir selalu menjadi prasyarat untuk men-deploy workload perusahaan di lingkungan cloud. Untuk 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 dapat dipicu oleh kegagalan fungsi atau sistem tertentu di situs utama.
  • Bagaimana failover ke lingkungan DR dipanggil? Apakah proses persetujuannya manual, atau dapat diotomatiskan untuk mencapai target RTO yang rendah?
  • Bagaimana mekanisme deteksi dan notifikasi 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 failover tersebut memenuhi ekspektasi RPO dan RTO Anda. Dengan begitu, Anda akan lebih yakin untuk memanggil DR jika diperlukan. Setiap kali perubahan atau pembaruan baru dilakukan pada proses atau solusi teknologi, lakukan pengujian lagi.

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

Kelebihan

Penggunaan Google Cloud untuk kelangsungan bisnis menawarkan beberapa keuntungan:

• Karena Google Cloud memiliki banyak region di seluruh dunia yang dapat dipilih, Anda dapat menggunakannya untuk mencadangkan atau mereplikasi data ke situs berbeda dalam benua yang sama. Anda juga dapat mencadangkan atau mereplikasi data ke situs di benua lain.
• 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 geo-redundansi untuk mendukung kelangsungan 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.
• Menyediakan satu atau beberapa opsi berikut untuk mengurangi belanja modal dan biaya operasional dalam 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 menyusutkan lingkungan DR sesuai kebutuhan.

Misalnya, diagram berikut menunjukkan aplikasi yang berjalan di lingkungan lokal (produksi) yang menggunakan komponen pemulihan diGoogle Cloud dengan Compute Engine, Cloud SQL, dan Cloud Load Balancing. Dalam skenario ini, database telah disediakan sebelumnya menggunakan database berbasis VM atau menggunakan database terkelola, seperti Cloud SQL, untuk pemulihan yang lebih cepat dengan replikasi data berkelanjutan. Google Cloud 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 harus menyediakan VM web dan aplikasi. Bergantung pada tingkat RTO yang ditargetkan dan kebijakan perusahaan, seluruh proses untuk memanggil DR, menyediakan workload di cloud, dan mengalihkan traffic dapat diselesaikan secara manual atau otomatis.

Untuk mempercepat dan mengotomatiskan penyediaan infrastruktur, pertimbangkan pengelolaan infrastruktur sebagai kode. Anda dapat menggunakan Cloud Build, yang merupakan layanan continuous integration, untuk menerapkan manifes Terraform secara otomatis ke lingkungan Anda. Untuk mengetahui 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 dan target RPO dan RTO yang diperlukan yang telah diidentifikasi:
  • Tentukan apakah mencadangkan data ke Google Cloud sudah cukup, 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 Anda.
  • Susun skenario DR yang berlaku untuk aplikasi dan data Anda sebagai bagian dari strategi DR yang dipilih.
• Pertimbangkan untuk menggunakan pola handover jika Anda hanya mencadangkan data. Jika tidak, pola berjaring mungkin merupakan 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 dari berbagai 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 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.

  • Mengizinkan 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 mengetahui informasi selengkapnya, lihat artikel Pemulihan dari bencana 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.

• Jadikan semua workload portabel saat menggunakan sistem standby. Semua beban kerja harus portabel (jika didukung oleh aplikasi dan memungkinkan) sehingga sistem tetap konsisten di seluruh lingkungan. Anda dapat menerapkan 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 agar 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 hybrid.

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

  • Meningkatkan ketersediaan dan ketahanan aplikasi dan layanan Anda.

  • Menyederhanakan 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 berbasis octoDNS untuk membantu Anda menyiapkan dan mengoperasikan lingkungan dengan beberapa penyedia DNS. Untuk mengetahui 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 gagal.

• Gunakan Cloud Load Balancing daripada 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 berbagai metrik, 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 dapat 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 lain yang memenuhi persyaratan Anda, termasuk target RPO dan RTO Anda.

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

• Enkripsi komunikasi saat transit. Untuk melindungi informasi sensitif, sebaiknya enkripsi 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 mengandalkan deployment aplikasi yang redundan di beberapa lingkungan komputasi. Tujuannya adalah untuk meningkatkan kapasitas, ketahanan, atau keduanya.

Meskipun Anda dapat mengakomodasi workload yang penuh burst di lingkungan komputasi berbasis pusat data dengan menyediakan resource yang berlebihan, pendekatan ini mungkin tidak hemat biaya. Dengan tugas batch, Anda dapat mengoptimalkan penggunaan dengan memaksimalkan eksekusinya selama jangka waktu yang lebih lama, meskipun penundaan tugas tidak praktis jika tugas tersebut dibatasi waktu.

Gagasan pola cloud bursting yaitu menggunakan lingkungan komputasi pribadi untuk beban dasar pengukuran dan melakukan burst ke cloud untuk sementara saat Anda membutuhkan kapasitas ekstra.

Dalam diagram sebelumnya, saat kapasitas data mencapai batasnya di lingkungan pribadi lokal, sistem dapat memperoleh kapasitas tambahan dari lingkunganGoogle Cloud jika diperlukan.

Pendorong utama pola ini adalah menghemat biaya serta mengurangi waktu dan upaya yang diperlukan untuk merespons perubahan persyaratan skala. Dengan pendekatan ini, Anda hanya membayar resource yang digunakan saat menangani beban tambahan. Artinya, Anda tidak perlu menyediakan infrastruktur secara berlebihan. Sebagai gantinya, Anda dapat memanfaatkan resource cloud sesuai permintaan dan menskalakannya agar sesuai dengan permintaan, serta metrik yang telah ditentukan sebelumnya. Dengan demikian, perusahaan Anda dapat menghindari gangguan layanan selama waktu permintaan puncak.

Persyaratan potensial untuk skenario cloud bursting adalah portabilitas workload. Jika Anda mengizinkan workload di-deploy ke beberapa lingkungan, Anda harus menghilangkan perbedaan antarlingkungan. Misalnya, Kubernetes memberi Anda kemampuan untuk mencapai konsistensi di tingkat workload di berbagai lingkungan yang menggunakan infrastruktur yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Arsitektur referensi lingkungan hybrid GKE Enterprise.

Pertimbangan desain

Pola cloud bursting berlaku untuk workload interaktif dan batch. Namun, saat menangani workload interaktif, Anda harus menentukan cara mendistribusikan permintaan di seluruh lingkungan:

• Anda dapat mengarahkan permintaan pengguna yang masuk ke load balancer yang berjalan di pusat data yang ada, lalu meminta load balancer mendistribusikan permintaan di seluruh resource lokal dan cloud.

  Pendekatan ini memerlukan load balancer atau sistem lain yang berjalan di pusat data yang ada untuk melacak resource yang dialokasikan di cloud. Load balancer atau sistem lain juga harus memulai peningkatan atau penurunan skala resource secara otomatis. Dengan menggunakan pendekatan ini, Anda dapat menonaktifkan semua resource cloud selama masa aktivitas rendah. Namun, penerapan mekanisme untuk melacak resource dapat melebihi kemampuan solusi load balancer Anda, sehingga meningkatkan kompleksitas secara keseluruhan.

• Daripada menerapkan mekanisme untuk melacak resource, Anda dapat menggunakan Cloud Load Balancing dengan backend grup endpoint jaringan (NEG) konektivitas hybrid. Anda menggunakan load balancer ini untuk merutekan permintaan klien internal atau permintaan klien eksternal ke backend yang berada di lokal dan di Google Cloud dan yang didasarkan pada metrik yang berbeda, seperti pemisahan traffic berbasis bobot. Anda juga dapat menskalakan backend berdasarkan kapasitas penyajian load balancing untuk workload di Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.

  Pendekatan ini memiliki beberapa manfaat tambahan, seperti memanfaatkan kemampuan perlindungan DDoS Google Cloud Armor, WAF, dan menyimpan konten ke dalam cache di edge cloud menggunakan Cloud CDN. Namun, Anda perlu menyesuaikan ukuran konektivitas jaringan hybrid untuk menangani traffic tambahan.

• Seperti yang dijelaskan dalam Portabilitas workload, aplikasi mungkin portabel ke lingkungan yang berbeda dengan perubahan minimal untuk mencapai konsistensi workload, tetapi itu tidak berarti bahwa aplikasi berperforma sama baiknya di kedua lingkungan. Perbedaan dalam komputasi yang mendasarinya, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, serta kedekatan dengan layanan dependen, biasanya menentukan performa. Melalui pengujian, Anda dapat memperoleh visibilitas yang lebih akurat dan memahami ekspektasi performa.

• Anda dapat menggunakan layanan infrastruktur cloud untuk membangun lingkungan guna menghosting aplikasi Anda tanpa portabilitas. Gunakan pendekatan berikut untuk menangani permintaan klien saat traffic dialihkan selama waktu permintaan puncak:

  • Gunakan alat yang konsisten untuk memantau dan mengelola kedua lingkungan ini.
  • Pastikan versi beban kerja konsisten dan sumber data Anda sudah terbaru.
  • Anda mungkin perlu menambahkan otomatisasi untuk menyediakan lingkungan cloud dan mengalihkan traffic saat permintaan meningkat dan workload cloud diharapkan menerima permintaan klien untuk aplikasi Anda.

• Jika Anda ingin menonaktifkan semua Google Cloud resource selama masa permintaan rendah, penggunaan kebijakan perutean DNS terutama untuk load balancing traffic mungkin tidak selalu optimal. Hal ini terutama karena:

  • Resource mungkin memerlukan waktu untuk diinisialisasi sebelum dapat melayani pengguna.
  • Perubahan DNS cenderung disebarkan secara perlahan di internet.

  Sebagai hasilnya:

  • Pengguna mungkin diarahkan ke lingkungan Cloud meskipun tidak ada resource yang tersedia untuk memproses permintaan mereka.
  • Pengguna mungkin terus dialihkan ke lingkungan lokal untuk sementara saat update DNS diterapkan di seluruh internet.

Dengan Cloud DNS, Anda dapat memilih kebijakan DNS dan kebijakan perutean yang sesuai dengan arsitektur dan perilaku solusi Anda, seperti kebijakan perutean DNS geolokasi. Cloud DNS juga mendukung health check untuk Load Balancer Jaringan passthrough internal, dan Load Balancer Aplikasi internal. Dalam hal ini, Anda dapat menggabungkannya dengan penyiapan DNS hibrida keseluruhan yang didasarkan pada pola ini.

Dalam beberapa skenario, Anda dapat menggunakan Cloud DNS untuk mendistribusikan permintaan klien dengan health check aktif Google Cloud, seperti saat menggunakan Load Balancer Aplikasi internal atau Load Balancer Aplikasi internal lintas region. Dalam skenario ini, Cloud DNS memeriksa kondisi keseluruhan Load Balancer Aplikasi internal, yang sendiri memeriksa kondisi instance backend. Untuk mengetahui informasi selengkapnya, lihat Mengelola kebijakan perutean DNS dan health check.

Anda juga dapat menggunakan split horizon Cloud DNS. Split horizon Cloud DNS adalah pendekatan untuk menyiapkan respons atau data DNS ke lokasi atau jaringan tertentu dari asal kueri DNS untuk nama domain yang sama. Pendekatan ini biasanya digunakan untuk memenuhi persyaratan saat aplikasi dirancang untuk menawarkan pengalaman pribadi dan publik, masing-masing dengan fitur unik. Pendekatan ini juga membantu mendistribusikan beban traffic di seluruh lingkungan.

Dengan mempertimbangkan hal ini, cloud bursting secara umum lebih baik untuk workload batch daripada workload interaktif.

Kelebihan

Keuntungan utama pola arsitektur cloud bursting meliputi:

• Cloud bursting memungkinkan Anda menggunakan kembali investasi yang ada di pusat data dan lingkungan komputasi pribadi. Penggunaan ulang ini dapat bersifat permanen atau berlaku hingga peralatan yang ada harus diganti, dan pada tahap ini Anda dapat mempertimbangkan migrasi penuh.
• Karena Anda tidak perlu lagi mempertahankan kapasitas berlebih untuk memenuhi permintaan puncak, Anda mungkin dapat meningkatkan penggunaan dan efektivitas biaya lingkungan komputasi pribadi Anda.
• Dengan cloud bursting, Anda dapat menjalankan tugas batch secara tepat waktu tanpa perlu menyediakan resource komputasi yang berlebihan.

Praktik terbaik

Saat menerapkan cloud bursting, pertimbangkan praktik terbaik berikut:

• Untuk memastikan bahwa workload yang berjalan di cloud dapat mengakses resource dengan cara yang sama seperti workload yang berjalan di lingkungan lokal, gunakan pola mesh dengan prinsip akses keamanan hak istimewa terendah. Jika desain workload memungkinkan, Anda dapat mengizinkan akses hanya dari cloud ke lingkungan komputasi lokal, bukan sebaliknya.
• Untuk meminimalkan latensi komunikasi antarlingkungan, pilih Google Cloud region yang secara geografis dekat dengan lingkungan komputasi pribadi Anda. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk pemilihan region Compute Engine.
• Saat menggunakan cloud bursting hanya untuk workload batch, kurangi permukaan serangan keamanan dengan menjaga kerahasiaan semua Google Cloud resource. Jangan izinkan akses langsung dari internet ke resource ini, meskipun Anda menggunakan load balancing eksternal untuk menyediakan titik entri ke workload. Google Cloud

• Pilih kebijakan DNS dan kebijakan perutean yang sesuai dengan pola arsitektur dan perilaku solusi yang ditargetkan.

  • Sebagai bagian dari pola ini, Anda dapat menerapkan desain kebijakan DNS secara permanen atau saat Anda memerlukan kapasitas tambahan menggunakan lingkungan lain selama waktu permintaan puncak.
  • Anda dapat menggunakan kebijakan perutean DNS geolokasi untuk memiliki endpoint DNS global bagi load balancer regional Anda. Taktik ini memiliki banyak kasus penggunaan untuk kebijakan perutean DNS geolokasi, termasuk aplikasi hybrid yang menggunakan Google Cloud bersama deployment lokal di mana region Google Cloud ada. Google Cloud Google Cloud

  • Jika perlu memberikan data yang berbeda untuk kueri DNS yang sama, Anda dapat menggunakan DNS split horizon—misalnya, kueri dari klien internal dan eksternal.

    Untuk mengetahui informasi selengkapnya, lihat arsitektur referensi untuk DNS hybrid

• Untuk memastikan perubahan DNS diterapkan dengan cepat, konfigurasikan DNS Anda dengan nilai time to live yang cukup singkat agar Anda dapat mengalihkan pengguna ke sistem standby saat Anda memerlukan kapasitas ekstra menggunakan lingkungan cloud.

• Untuk tugas yang tidak terlalu dibatasi waktu, dan tidak menyimpan data secara lokal, pertimbangkan penggunaan instance Spot VM, yang jauh lebih murah dibandingkan instance VM biasa. Namun, prasyaratnya adalah jika tugas VM di-preempt, sistem harus dapat memulai ulang tugas secara otomatis.

• Gunakan container untuk mencapai portabilitas workload jika berlaku. Selain itu, GKE Enterprise dapat menjadi teknologi pendukung utama untuk desain tersebut. Untuk mengetahui informasi selengkapnya, lihat Arsitektur referensi lingkungan hybrid GKE Enterprise.

• Pantau traffic apa pun yang dikirim dari Google Cloud ke lingkungan komputasi yang berbeda. Traffic ini akan dikenai biaya transfer data keluar.

• Jika Anda berencana menggunakan arsitektur ini dalam jangka panjang dengan volume transfer data keluar yang tinggi, pertimbangkan untuk menggunakan Cloud Interconnect. Cloud Interconnect dapat membantu mengoptimalkan performa konektivitas dan dapat mengurangi biaya transfer data keluar untuk traffic yang memenuhi kondisi tertentu. Untuk mengetahui informasi selengkapnya, lihat Harga Cloud Interconnect.

• Saat Cloud Load Balancing digunakan, Anda harus menggunakan kemampuan pengoptimalan kapasitas aplikasi jika berlaku. Dengan melakukannya, Anda dapat mengatasi beberapa tantangan kapasitas yang dapat terjadi dalam aplikasi yang didistribusikan secara global.

• Lakukan autentikasi terhadap orang yang menggunakan sistem Anda dengan membangun identitas bersama antarlingkungan, sehingga sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.

• Untuk melindungi informasi sensitif, sangat disarankan untuk mengenkripsi semua komunikasi selama pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid 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 selanjutnya

• Pelajari cara melakukan pendekatan arsitektur hybrid dan multicloud serta cara memilih workload yang sesuai.
• Cari tahu selengkapnya 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 berbagai arsitektur, termasuk aplikasi web e-commerce berbasis microservice menggunakan GKE, dan aplikasi web dinamis yang berbasis Serverless API.

---

1. Untuk mengetahui informasi selengkapnya tentang pertimbangan khusus wilayah, lihat Geografi dan wilayah.  ↩