Dokumen ini adalah yang kedua dari tiga dokumen dalam kumpulan. Kursus ini membahas pola arsitektur hybrid dan multicloud yang umum. Contoh ini juga menjelaskan skenario yang paling sesuai untuk pola tersebut. Terakhir, panduan ini menyediakan 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 konfigurasi 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 yang aman hybrid dan multicloud: membahas pola arsitektur jaringan hybrid dan multicloud dari perspektif jaringan.

Setiap perusahaan memiliki portofolio workload aplikasi unik yang menetapkan persyaratan dan batasan pada arsitektur konfigurasi 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 dari solusi teknologi, aplikasi, atau layanan untuk membuat solusi yang dapat digunakan kembali yang memenuhi persyaratan atau kasus penggunaan tertentu. Solusi teknologi berbasis cloud sering kali terdiri dari beberapa layanan cloud yang berbeda dan terdistribusi. Layanan ini berkolaborasi untuk memberikan fungsi yang diperlukan. Dalam konteks ini, setiap layanan dianggap sebagai komponen fungsional dari solusi teknologi. Demikian pula, aplikasi dapat terdiri dari beberapa tingkat, modul, atau layanan fungsional, dan masing-masing dapat merepresentasikan komponen fungsional arsitektur aplikasi. Arsitektur tersebut dapat distandarkan untuk mengatasi kasus penggunaan bisnis tertentu dan berfungsi sebagai pola dasar yang dapat digunakan kembali.

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

• Komponen dari solusi atau aplikasi.
• Fungsi yang diharapkan untuk setiap komponen—misalnya, fungsi frontend untuk menyediakan antarmuka pengguna grafis atau fungsi backend guna menyediakan akses data.
• Cara komponen berkomunikasi satu sama lain dan dengan sistem atau pengguna eksternal. Dalam aplikasi modern, komponen ini berinteraksi melalui antarmuka atau API yang terdefinisi dengan baik. 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 bergantung pada deployment workload atau komponen aplikasi yang terdistribusi. Artinya, perangkat tersebut menjalankan aplikasi (atau komponen tertentu dari aplikasi tersebut) di lingkungan komputasi yang paling sesuai dengan polanya. Dengan melakukan hal tersebut, pola tersebut dapat memanfaatkan berbagai properti dan karakteristik dari lingkungan komputasi yang terdistribusi dan saling terhubung.
• Pola arsitektur yang redundan: Pola ini didasarkan pada deployment workload yang redundan. Dalam pola-pola ini, Anda men-deploy aplikasi yang sama beserta komponennya di beberapa lingkungan komputasi. Tujuannya adalah untuk meningkatkan kapasitas performa atau ketahanan aplikasi, atau untuk mereplikasi lingkungan yang sudah ada untuk pengembangan dan pengujian.

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

Seri ini berisi halaman berikut:

• Pola arsitektur terdistribusi

  • Pola hybrid bertingkat

  • Pola multicloud berpartisi

  • Pola hybrid dan multicloud Analytics

  • Pola edge hybrid

• Pola arsitektur yang redundan

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

Kontributor

Penulis: Marwan Al Shawi | Partner Customer Engineer

Kontributor lainnya:

• Saud Albazei | Customer Engineer, Modernisasi Aplikasi
• Anna Berenberg | Rekan Teknik
• Marco Ferrari | Arsitek Solusi Cloud
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Arsitek Solusi Cloud
• Mark Schlagenhauf | Penulis Teknis, Networking
• Daniel Strebel | Pemimpin Solusi EMEA, Modernisasi Aplikasi
• Ammett Williams | Developer Relations Engineer

Pola arsitektur terdistribusi

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

Pertimbangan desain

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

Latensi

Pada 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 antar-region cloud dalam penyiapan multicloud. Oleh karena itu, sangat penting untuk menilai persyaratan latensi aplikasi Anda dan sensitivitasnya terhadap keterlambatan jaringan. Aplikasi yang dapat menoleransi latensi merupakan kandidat yang lebih cocok untuk deployment terdistribusi awal dalam lingkungan hybrid atau multicloud.

Arsitektur status sementara versus final

Untuk menentukan ekspektasi dan potensi implikasi biaya, skala, dan performa, penting untuk menganalisis jenis arsitektur yang Anda perlukan dan durasi yang diinginkan sebagai bagian dari tahap perencanaan. Misalnya, jika Anda berencana menggunakan arsitektur hybrid atau multicloud dalam waktu lama atau secara permanen, sebaiknya pertimbangkan 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 kecepatan transfer data berdiskon.

Keandalan

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

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

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

Untuk mencapai tingkat keandalan sistem yang Anda inginkan, tentukan metrik keandalan yang jelas dan desain aplikasi untuk memulihkan sendiri dan menahan gangguan secara efektif di berbagai lingkungan. Untuk membantu Anda menentukan cara yang tepat untuk mengukur pengalaman pelanggan atas layanan, lihat Menentukan sasaran keandalan.

Konektivitas hybrid dan multicloud

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

Kemudahan dikelola

Alat pengelolaan dan pemantauan yang konsisten dan terpadu sangat penting untuk penyiapan hybrid dan multicloud yang sukses (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 kompleks pengelolaan lingkungan. Sebagian besar vendor cloud publik tidak hanya memiliki fitur yang berbeda-beda, tetapi juga memiliki beragam alat, SLA, dan API untuk mengelola layanan cloud. Oleh karena itu, pertimbangkan keuntungan strategis arsitektur yang dipilih terhadap potensi kompleksitas jangka pendek versus manfaat jangka panjang.

Biaya

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

Sebaiknya miliki satu metode yang terdefinisi 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 Blok Pengelolaan Biaya Cloud Looker dari Google Cloud, Anda dapat membuat tampilan terpusat biaya multicloud Anda. Tampilan ini dapat membantu memberikan tampilan pelaporan gabungan dari pembelanjaan Anda di beberapa cloud. Untuk mengetahui informasi selengkapnya, lihat Strategi untuk mengoptimalkan pengelolaan biaya penagihan cloud secara efektif.

Sebaiknya gunakan juga praktik FinOps untuk memperjelas biaya. Sebagai bagian dari praktik FinOps yang kuat, tim pusat dapat mendelegasikan pengambilan keputusan untuk pengoptimalan resource kepada tim lain yang terlibat dalam suatu project guna mendorong akuntabilitas individual. 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 sebaiknya Anda pertimbangkan, lihat Framework Arsitektur Google Cloud: Pengoptimalan biaya.

Perpindahan data

Pergerakan data adalah pertimbangan penting untuk perencanaan arsitektur serta strategi hybrid dan multicloud, terutama untuk sistem terdistribusi. Perusahaan perlu mengidentifikasi berbagai kasus penggunaan bisnis mereka, data yang mendukung mereka, dan cara data diklasifikasikan (untuk industri yang diatur oleh hukum). 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 mungkin memengaruhi aplikasi dan arsitektur pipeline data. Rangkaian opsi perpindahan data yang komprehensif dari Google Cloud memungkinkan bisnis memenuhi kebutuhan spesifik mereka dan mengadopsi arsitektur hybrid dan multicloud tanpa mengorbankan kesederhanaan, efisiensi, atau performa.

Keamanan

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

Saat merencanakan strategi migrasi, sebaiknya Anda menganalisis pertimbangan yang disebutkan sebelumnya. Elemen ini dapat membantu Anda meminimalkan peluang memperkenalkan kompleksitas pada arsitektur seiring meningkatnya volume traffic atau aplikasi. Selain itu, merancang dan membangun zona landing hampir selalu merupakan 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 zona landing di Google Cloud.

Dokumen dalam seri ini menjelaskan pola arsitektur terdistribusi lainnya:

• Pola hybrid bertingkat
• Pola multicloud berpartisi
• 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 dioperasikan dari lingkungan komputasi yang berbeda. Sebagai bagian dari pola arsitektur hibrida bertingkat, lingkungan komputasi berada di lingkungan komputasi pribadi lokal dan di Google Cloud.

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

Agar dapat diakses dan digunakan, Anda dapat membangun aplikasi frontend dengan berbagai framework dan teknologi. Beberapa faktor utama untuk keberhasilan aplikasi frontend meliputi performa aplikasi, kecepatan respons, dan kompatibilitas browser.

Komponen aplikasi backend biasanya fokus pada penyimpanan dan pengelolaan data. Dalam beberapa arsitektur, logika bisnis mungkin disertakan dalam komponen backend. Rilis baru aplikasi backend cenderung lebih jarang daripada rilis untuk aplikasi frontend. Aplikasi backend memiliki tantangan berikut yang harus dikelola:

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

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

• Tingkat presentasi dan frontend web
• Tingkat aplikasi
• Tingkat backend atau akses data

Menempatkan lapisan ini ke dalam container akan memisahkan kebutuhan teknis mereka, seperti persyaratan penskalaan, dan membantu memigrasikannya dalam pendekatan bertahap. Selain itu, Anda dapat men-deploy-nya di layanan cloud agnostik platform yang dapat portable di seluruh lingkungan, menggunakan pengelolaan otomatis, dan melakukan penskalaan dengan platform yang dikelola cloud, seperti Cloud Run atau edisi Google Kubernetes Engine (GKE) Enterprise. Selain itu, database yang dikelola Google Cloud seperti Cloud SQL membantu menyediakan backend sebagai lapisan database.

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

Jika Anda sudah memiliki aplikasi dengan komponen backend dan frontend yang dihosting di lingkungan lokal, pertimbangkan batasan arsitektur Anda saat ini. Misalnya, saat aplikasi Anda diskalakan dan permintaan pada performa dan keandalannya meningkat, Anda harus mulai mengevaluasi apakah bagian dari aplikasi Anda harus difaktorkan ulang atau dipindahkan ke arsitektur yang berbeda dan lebih optimal. Dengan pola arsitektur hibrida bertingkat, Anda dapat mengalihkan beberapa workload dan komponen aplikasi ke cloud sebelum melakukan transisi lengkap. Sangat penting untuk mempertimbangkan biaya, waktu, dan risiko yang terlibat dalam migrasi tersebut.

Diagram berikut menunjukkan pola arsitektur hibrida bertingkat standar.

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

Dengan pola arsitektur hibrida bertingkat, Anda dapat memanfaatkan infrastruktur Google Cloud dan layanan global, seperti ditunjukkan dalam contoh arsitektur dalam diagram berikut. Frontend aplikasi dapat dijangkau melalui Google Cloud. Platform ini juga dapat menambahkan elastisitas ke frontend dengan menggunakan penskalaan otomatis untuk merespons permintaan penskalaan secara dinamis dan efisien tanpa menyediakan infrastruktur yang berlebihan. Ada berbagai arsitektur yang dapat digunakan untuk membangun dan menjalankan aplikasi web skalabel di Google Cloud. Setiap arsitektur memiliki kelebihan dan kekurangan untuk persyaratan yang berbeda.

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

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

Seiring waktu, jumlah aplikasi yang Anda deploy ke cloud publik dapat meningkat ke titik di mana Anda dapat mempertimbangkan untuk memindahkan komponen aplikasi backend ke cloud publik. Jika Anda memperkirakan akan melayani traffic yang tinggi, memilih layanan yang dikelola cloud dapat membantu menghemat upaya engineering saat mengelola infrastruktur Anda sendiri. Pertimbangkan opsi ini kecuali jika ada batasan atau persyaratan yang mewajibkan hosting komponen aplikasi backend secara lokal. Misalnya, jika data backend Anda tunduk pada pembatasan peraturan, Anda mungkin harus menyimpan data tersebut secara lokal. Namun, jika berlaku dan mematuhi kebijakan, 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 di beberapa skenario. Dengan Cloud Terdistribusi, Anda dapat menjalankan cluster Google Kubernetes Engine pada hardware khusus yang disediakan dan dikelola oleh Google serta terpisah dari pusat data Google Cloud. Untuk memastikan bahwa Cloud Terdistribusi memenuhi persyaratan Anda saat ini dan di masa mendatang, ketahui batasan Cloud Terdistribusi jika dibandingkan dengan zona GKE berbasis cloud konvensional.

Kelebihan

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

• Komponen frontend bergantung pada resource backend dan terkadang pada komponen frontend lainnya.
• Komponen backend tidak bergantung pada komponen frontend. Oleh karena itu, mengisolasi dan memigrasikan aplikasi frontend cenderung tidak begitu kompleks dibandingkan memigrasikan aplikasi backend.
• Karena aplikasi frontend sering kali bersifat stateless atau tidak mengelola data sendiri, aplikasi tersebut cenderung tidak terlalu sulit untuk dimigrasikan dibandingkan backend.
  • Komponen frontend dapat dioptimalkan sebagai bagian dari migrasi untuk menggunakan arsitektur stateless. Untuk mengetahui informasi selengkapnya, tonton 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 dengan cara yang efisien dan otomatis. Untuk mengetahui informasi lebih lanjut, lihat CI/CD di Google Cloud.
• Frontend yang sensitif terhadap performa dengan beban traffic yang beragam dapat memanfaatkan load balancing, deployment multi-regional, penyimpanan cache Cloud CDN, serverless, dan penskalaan otomatis yang dimungkinkan oleh deployment berbasis cloud (idealnya dengan arsitektur stateless).

• 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 pada aplikasi yang sama. Struktur tim semacam itu membutuhkan pendekatan berulang dan pemeliharaan berkelanjutan. Beberapa keuntungan menggunakan microfrontend adalah sebagai berikut:

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

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

• Proxy API yang dikelola Cloud membantu:

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

Anda juga dapat menerapkan pola hibrida bertingkat secara terbalik, dengan men-deploy backend di cloud, sekaligus mempertahankan frontend di lingkungan komputasi pribadi. Meskipun kurang umum, pendekatan ini paling baik diterapkan saat Anda menangani frontend monolitik dan kelas berat. Dalam kasus tersebut, 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 memungkinkan arsitektur semacam itu. Apigee Hybrid berguna sebagai platform untuk membangun dan mengelola proxy API dalam model deployment hybrid. Untuk mengetahui informasi selengkapnya, lihat Arsitektur yang dikaitkan secara longgar, termasuk arsitektur monolitik dan microservice bertingkat.

Praktik terbaik

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

Praktik terbaik untuk mengurangi kerumitan

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

• 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 latensi rendah antara sistem tersebut 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 terperinci dan terkontrol. Idealnya, Anda harus mengekspos komponen aplikasi menggunakan API yang aman. Untuk mengetahui informasi selengkapnya, lihat Traffic keluar dengan gerbang.

• Untuk meminimalkan latensi komunikasi antar-lingkungan, pilih region Google Cloud yang secara geografis dekat dengan lingkungan komputasi pribadi tempat komponen backend aplikasi Anda dihosting. Untuk mengetahui informasi selengkapnya, baca Praktik terbaik untuk pemilihan region Compute Engine.
• Minimalkan dependensi tinggi antarsistem yang berjalan di lingkungan berbeda, terutama jika komunikasi ditangani secara sinkron. Dependensi ini dapat memperlambat performa, menurunkan ketersediaan keseluruhan, dan berpotensi menimbulkan biaya transfer data keluar tambahan.
• Dengan pola arsitektur hibrida bertingkat, Anda mungkin memiliki volume traffic masuk yang lebih besar dari lingkungan lokal yang masuk ke Google Cloud dibandingkan dengan traffic keluar yang keluar dari Google Cloud. Meskipun demikian, Anda harus mengetahui perkiraan volume transfer data keluar yang akan keluar dari Google Cloud. Jika ingin 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 Anda mengenkripsi semua komunikasi saat dalam pengiriman. Jika enkripsi diperlukan pada lapisan konektivitas, Anda dapat menggunakan tunnel VPN, VPN HA melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.

• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai backend, sebaiknya, jika memungkinkan, untuk men-deploy gateway atau proxy API sebagai faade penggabungan. Gateway atau proxy ini bertindak sebagai titik kontrol terpusat dan melakukan tindakan berikut:

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

• Untuk memfasilitasi pembentukan konfigurasi 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 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. Dengan menggunakan Cloud Load Balancing dengan gateway API, Anda dapat melakukan beberapa hal berikut:

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

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

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

• Tetapkan identitas umum antarlingkungan sehingga sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.

• Men-deploy CI/CD dan sistem 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 workload individual dan arsitektur aplikasi

• Meskipun fokusnya terletak pada aplikasi frontend dalam pola ini, tetaplah mengetahui kebutuhan untuk memodernisasi aplikasi backend Anda. Jika kecepatan pengembangan aplikasi backend jauh lebih lambat daripada aplikasi frontend, perbedaannya dapat menyebabkan kompleksitas tambahan.
• Memperlakukan API sebagai antarmuka backend akan menyederhanakan integrasi, pengembangan frontend, interaksi layanan, dan menyembunyikan kompleksitas sistem backend. Untuk mengatasi tantangan ini, Apigee memfasilitasi pengembangan dan pengelolaan gateway/proxy API untuk deployment hybrid dan multicloud.
• Pilih pendekatan rendering untuk aplikasi web frontend Anda berdasarkan konten (statis versus dinamis), performa pengoptimalan mesin telusur, dan ekspektasi tentang kecepatan pemuatan halaman.
• Saat memilih arsitektur untuk aplikasi web berbasis konten, 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 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 berbagai lingkungan, Anda memiliki fleksibilitas untuk memodernisasi workload lalu bermigrasi ke Google Cloud pada waktu yang berbeda. Hal ini dapat membantu ketika beban kerja sangat bergantung pada hal lain dan tidak dapat dimigrasikan satu per satu, atau menggunakan portabilitas workload hybrid untuk menggunakan resource terbaik yang tersedia di setiap lingkungan. Dalam semua kasus, GKE Enterprise dapat menjadi teknologi pendukung yang penting. Untuk mengetahui informasi selengkapnya, lihat lingkungan hybrid GKE Enterprise.

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

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

    Untuk mengetahui informasi selengkapnya tentang mendesain dan memfaktorkan ulang aplikasi monolitik ke arsitektur microservice untuk memodernisasi arsitektur aplikasi web, lihat Pengantar microservice.

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

Pola multicloud yang dipartisi

Pola arsitektur cloud yang dipartisi menggabungkan beberapa lingkungan cloud publik yang dioperasikan oleh berbagai penyedia layanan cloud. Arsitektur ini memberikan fleksibilitas untuk men-deploy aplikasi di lingkungan komputasi yang optimal yang memperhitungkan driver multicloud dan pertimbangan yang dibahas di bagian pertama dari rangkaian ini.

Diagram berikut menunjukkan pola arsitektur multicloud yang dipartisi.

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

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

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

Seperti yang telah disebutkan, ada beberapa situasi yang mungkin menyebabkan alasan bisnis dan teknis untuk menggabungkan Google Cloud dengan penyedia cloud lain dan untuk mempartisi workload di seluruh lingkungan cloud tersebut. Solusi multicloud menawarkan fleksibilitas untuk memigrasikan, membangun, dan mengoptimalkan portabilitas aplikasi di seluruh lingkungan multicloud sambil meminimalkan ketergantungan, 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 OKI dengan resource yang berjalan di Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Infrastruktur Google Cloud dan Oracle Cloud, yang memaksimalkan multicloud. Selain itu, Cross-Cloud Interconnect memfasilitasi konektivitas khusus bandwidth tinggi antara Google Cloud dan penyedia layanan cloud lain yang didukung, sehingga Anda dapat merancang dan membangun solusi multicloud untuk menangani volume traffic antar-cloud yang tinggi.

Kelebihan

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

Berikut adalah beberapa keuntungan utama dari pola arsitektur multicloud yang dipartisi:

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

• Untuk alasan peraturan, Anda dapat melayani segmen basis pengguna tertentu dan data dari negara tempat Google Cloud tidak memiliki region cloud.

• Pola arsitektur cloud 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 berguna terutama 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 lainnya.

• Pola arsitektur cloud yang dipartisi dapat membantu memfasilitasi dan mempercepat skenario penggabungan dan akuisisi, saat aplikasi dan layanan kedua perusahaan tersebut mungkin dihosting di lingkungan cloud publik yang berbeda.

Praktik terbaik

• Mulailah dengan men-deploy workload yang tidak signifikan. Deployment awal di cloud sekunder ini dapat berfungsi sebagai pola untuk deployment atau migrasi mendatang. Namun, pendekatan ini mungkin tidak berlaku dalam situasi ketika workload tertentu secara hukum atau secara regulasi 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, menurunkan ketersediaan keseluruhan, dan berpotensi menimbulkan biaya transfer data keluar tambahan.
• Untuk menghilangkan perbedaan antarlingkungan, pertimbangkan untuk menggunakan container dan Kubernetes jika didukung oleh aplikasi dan memungkinkan.
• Pastikan pipeline dan alat CI/CD untuk deployment dan pemantauan konsisten di seluruh lingkungan cloud.
• Pilih pola arsitektur jaringan optimal yang memberikan solusi komunikasi paling efisien dan efektif untuk aplikasi yang sedang Anda gunakan.
  • Komunikasi harus terperinci dan terkontrol. Menggunakan API yang aman untuk mengekspos komponen aplikasi.
  • Pertimbangkan untuk menggunakan pola arsitektur mesh atau salah satu pola jaringan yang dibatasi, berdasarkan persyaratan bisnis dan teknis khusus Anda.
• Untuk memenuhi ekspektasi ketersediaan dan performa, buat desain untuk ketersediaan tinggi (HA) end-to-end, latensi rendah, dan tingkat throughput yang sesuai.

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

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

• Jika Anda menggunakan beberapa CDN sebagai bagian dari pola arsitektur berpartisi multicloud Anda, 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, kemungkinan juga, biayanya.

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

• Untuk menyeimbangkan permintaan secara efektif di Google Cloud dan platform cloud lainnya, gunakan Cloud Load Balancing. Untuk mengetahui informasi selengkapnya, lihat Mengarahkan traffic ke lokasi lokal atau cloud lainnya.

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

• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai backend, sebaiknya, jika memungkinkan, untuk men-deploy gateway atau proxy API sebagai faade penggabungan. Gateway atau proxy ini bertindak sebagai titik kontrol terpusat dan melakukan tindakan berikut:

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

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

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

  • Meningkatkan performa dengan Cloud CDN.

  • Memberikan perlindungan WAF dan DDoS melalui Google Cloud Armor.

• Gunakan alat yang konsisten untuk logging dan pemantauan di berbagai lingkungan cloud jika memungkinkan. Anda dapat mempertimbangkan untuk menggunakan sistem pemantauan {i>open source<i}. Untuk mengetahui informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

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

Pola hybrid dan multicloud Analytics

Dokumen ini membahas bahwa tujuan pola analisis hybrid dan multicloud adalah memanfaatkan pemisahan antara beban kerja transaksi 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, analisis dan sistem transaksi cenderung terpisah dan dikaitkan secara longgar. Tujuan pola analytics hybrid dan multicloud adalah memanfaatkan pemisahan yang sudah ada sebelumnya dengan menjalankan workload transaksi dan analisis di dua lingkungan komputasi yang berbeda. Data mentah pertama kali diekstrak dari workload yang berjalan di lingkungan komputasi pribadi, lalu dimuat ke Google Cloud, tempat data tersebut digunakan untuk pemrosesan analisis. Beberapa hasilnya kemudian dapat dimasukkan kembali ke sistem transaksional.

Diagram berikut mengilustrasikan kemungkinan arsitektur secara konseptual dengan menunjukkan pipeline data potensial. Setiap jalur/panah mewakili kemungkinan opsi pipeline transformasi dan perpindahan 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 memperoleh manfaat dari data tersebut, gunakan layanan perpindahan data, yang merupakan rangkaian lengkap layanan penyerapan, integrasi, dan replikasi data.

Seperti yang ditunjukkan dalam 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 volume transfer data yang tinggi, Cloud Interconnect dan Cross-Cloud Interconnect menyediakan konektivitas khusus ke penyedia lokal dan penyedia cloud lainnya.

Kelebihan

Menjalankan workload analytics di cloud memiliki beberapa keuntungan utama:

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

• Google Cloud membantu Anda memodernisasi dan mengoptimalkan platform data untuk mengurai data silo. Penggunaan lakehouse data akan membantu menstandarkan berbagai format penyimpanan. Teknologi ini juga dapat memberikan fleksibilitas, skalabilitas, dan ketangkasan yang diperlukan untuk membantu memastikan bahwa data 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. Alat ini juga membantu Anda membuat kueri data Anda sendiri yang tersimpan di Amazon Simple Storage Service (Amazon S3) atau Azure Blob Storage. Kemampuan analisis multicloud ini memungkinkan tim data mengurai data silo. 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 analisis, pertimbangkan praktik terbaik umum berikut:

• Gunakan pola jaringan pengalihan untuk mengaktifkan penyerapan data. Jika hasil analisis perlu dimasukkan kembali ke sistem transaksional, Anda dapat menggabungkan pola pengalihan dan traffic keluar yang dibatasi.
• 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 merupakan layanan pemrosesan data yang terkelola sepenuhnya dan cloud-first untuk membangun dan mengelola pipeline data.
• Untuk menemukan, mengklasifikasikan, dan melindungi aset data Anda yang berharga, pertimbangkan untuk menggunakan kemampuan Sensitive Data Protection Google Cloud, 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 yang telah ditentukan sebelumnya, jika berlaku dan mematuhi kebijakan.
• Jika Anda sudah memiliki workload Hadoop atau Spark, pertimbangkan untuk memigrasikan tugas ke Dataproc dan memigrasikan data HDFS yang ada ke Cloud Storage.

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

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

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

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

Pola edge hybrid

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

• Kapal yang bepergian di laut dan kendaraan lain mungkin hanya terhubung sekali-kali atau hanya memiliki akses ke sambungan 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 beban waktu dan workload yang penting bagi bisnis secara lokal, di edge jaringan, sambil menggunakan cloud untuk semua jenis workload lainnya. Dalam arsitektur hybrid edge, link internet adalah komponen tidak penting yang digunakan untuk tujuan pengelolaan dan untuk menyinkronkan atau mengupload data, sering kali secara asinkron, tetapi tidak terlibat dalam waktu atau transaksi yang penting bagi bisnis.

Kelebihan

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

• Traffic masuk—memindahkan data dari edge ke Google Cloud—mungkin tidak dikenai biaya.
• Menjalankan workload yang bersifat penting bagi bisnis dan waktu di edge membantu memastikan latensi rendah dan kecukupan diri. Jika konektivitas internet gagal atau tidak tersedia untuk sementara, Anda tetap dapat menjalankan semua transaksi penting. Pada saat yang sama, Anda dapat memperoleh manfaat dari penggunaan cloud untuk sebagian besar dari keseluruhan 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 mengerjakan ulang aplikasi tertentu maupun dengan melengkapi beberapa lokasi edge dengan link internet yang lebih andal.
• Project terkait Internet of Things (IoT) dapat menjadi lebih hemat biaya dengan melakukan komputasi data secara lokal. Dengan demikian, perusahaan dapat menjalankan dan memproses beberapa layanan secara lokal di edge, yang lebih dekat dengan sumber data. Solusi ini juga memungkinkan perusahaan untuk secara selektif mengirim data ke cloud, sehingga dapat membantu mengurangi kapasitas, transfer data, pemrosesan, dan biaya keseluruhan dari solusi IoT.
• Edge computing dapat berfungsi sebagai lapisan komunikasi menengah antara layanan lama dan yang dimodernisasi. Misalnya, layanan yang mungkin menjalankan gateway API dalam container seperti Apigee Hybrid). Dengan demikian, aplikasi dan sistem lama dapat berintegrasi dengan layanan yang dimodernisasi, seperti solusi IoT.

Praktik terbaik

Pertimbangkan rekomendasi berikut saat menerapkan pola arsitektur hybrid edge:

• Jika komunikasi bersifat searah, gunakan pola masuk yang dibatasi.
• Jika komunikasi bersifat dua arah, pertimbangkan pola traffic keluar dengan gerbang dan akses masuk terbatas.
• Jika solusinya terdiri dari banyak situs edge remote yang terhubung ke Google Cloud melalui internet publik, Anda dapat menggunakan solusi software-defined WAN (SD-WAN). Anda juga dapat menggunakan Network Connectivity Center dengan router SD-WAN pihak ketiga yang didukung oleh partner Google Cloud untuk menyederhanakan penyediaan dan pengelolaan konektivitas aman dalam skala besar.
• Minimalkan dependensi antara sistem yang berjalan di edge dan sistem yang berjalan di lingkungan cloud. Setiap dependensi dapat mengurangi keuntungan keandalan dan latensi penyiapan hybrid edge.
• Untuk mengelola dan mengoperasikan beberapa lokasi edge secara efisien, Anda harus memiliki bidang pengelolaan terpusat dan solusi pemantauan di cloud.
• Pastikan bahwa pipeline CI/CD beserta alat untuk deployment dan pemantauan konsisten di seluruh lingkungan cloud dan edge.
• Pertimbangkan untuk menggunakan container dan Kubernetes jika memungkinkan dan memungkinkan, untuk menghilangkan perbedaan di antara berbagai lokasi edge serta 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 kemungkinan opsi konektivitas yang Anda miliki untuk menghubungkan cluster GKE Enterprise yang berjalan di lingkungan edge atau lokal Anda ke Google Cloud.
• Sebagai bagian dari pola ini, meskipun beberapa komponen GKE Enterprise mungkin tidak stabil selama gangguan konektivitas sementara ke Google Cloud, jangan gunakan GKE Enterprises saat koneksinya terputus dari Google Cloud sebagai mode kerja nominal. Untuk mengetahui informasi selengkapnya, lihat Dampak pemutusan sementara dari Google Cloud.
• Untuk mengatasi inkonsistensi dalam protokol, API, dan mekanisme autentikasi di berbagai layanan backend dan edge, sebaiknya, jika memungkinkan, men-deploy gateway atau proxy API sebagai faade penggabungan. Gateway atau proxy ini bertindak sebagai titik kontrol terpusat dan melakukan tindakan berikut:
  • Menerapkan langkah-langkah keamanan tambahan.
  • Melindungi aplikasi klien dan layanan lainnya dari perubahan kode backend.
  • Memfasilitasi jejak audit untuk komunikasi antara semua aplikasi lintas lingkungan dan komponen yang dipisahkan.
  • Bertindak sebagai lapisan komunikasi perantara antara layanan lama dan yang dimodernisasi.
    • Apigee dan Apigee Hybrid memungkinkan Anda menghosting serta mengelola gateway hybrid dan tingkat perusahaan di seluruh lingkungan lokal, edge, cloud lainnya, dan lingkungan Google Cloud.
• Tetapkan identitas umum antarlingkungan sehingga sistem dapat melakukan autentikasi dengan aman di seluruh batas lingkungan.
• Karena data yang dipertukarkan antarlingkungan mungkin sensitif, pastikan semua komunikasi dienkripsi dalam pengiriman menggunakan tunnel VPN, TLS, atau keduanya.

Pola hybrid lingkungan

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

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

• Batasan yurisdiksi 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 seperti itu, pertimbangkan tidak hanya lingkungan produksi, tetapi semua lingkungan yang terlibat dalam siklus proses aplikasi, termasuk pengembangan, pengujian, dan sistem staging. Batasan ini sering berlaku untuk lingkungan produksi dan datanya. Kebijakan tersebut mungkin tidak berlaku untuk lingkungan lain yang tidak menggunakan data aktual. Hubungi departemen kepatuhan organisasi Anda atau tim yang setara.

Diagram berikut menunjukkan pola arsitektur hibrid lingkungan umum:

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

Meskipun proses pengembangan, pengujian, dan deployment berbeda untuk setiap aplikasi, proses tersebut 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 nonfungsional. Pengujian ini juga dikenal sebagai pengujian beban.
• Pengujian bertahap atau deployment: Memverifikasi apakah 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.

Tujuan utama lingkungan pengujian adalah untuk menjalankan pengujian fungsional. Tujuan utama dari lingkungan staging adalah untuk menguji apakah prosedur deployment aplikasi Anda berfungsi sebagaimana mestinya. Pada saat rilis mencapai lingkungan staging, pengujian fungsional Anda harus selesai. Staging adalah langkah terakhir sebelum 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 memungkinkan:

• Semua lingkungan setara secara fungsional. Artinya, arsitektur, API, serta 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 kerusakan tidak dapat direproduksi.
• Lingkungan yang digunakan untuk pengujian performa dan keandalan, staging, serta produksi setara secara tidak berfungsi. Artinya, performa, skala, dan konfigurasinya, serta cara pengoperasian dan pemeliharaannya sama, atau hanya berbeda dalam hal yang tidak signifikan. Jika tidak, pengujian performa dan staging tidak akan berguna.

Secara umum, tidak masalah jika lingkungan yang digunakan untuk pengujian pengembangan dan fungsional berbeda secara non-fungsional dengan lingkungan lainnya.

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

Skenario berikut sangat cocok dengan pola campuran lingkungan:

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

Pertimbangan Desain

• Kebutuhan bisnis: Setiap strategi deployment dan rilis untuk aplikasi memiliki kelebihan dan kekurangan masing-masing. Untuk memastikan pendekatan yang Anda pilih selaras dengan persyaratan spesifik Anda, dasarkan pilihan Anda pada penilaian menyeluruh terhadap kebutuhan dan kendala bisnis Anda.
• Perbedaan lingkungan: Sebagai bagian dari pola ini, sasaran utama penggunaan lingkungan cloud ini adalah untuk pengembangan dan pengujian. Status terakhir 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 (lokal), tim teknis harus mengetahui dan memahami arsitektur serta kemampuan kedua lingkungan tersebut. Hal ini mencakup dependensi pada aplikasi lain dan pada infrastruktur hardware—misalnya, sistem keamanan yang melakukan pemeriksaan 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 untuk tidak menggunakan fitur cloud apa pun di lingkungan pengembangan dan pengujian yang tidak ada di lingkungan produksi lokal Anda.
• Kriteria keberhasilan: Harus ada kriteria keberhasilan pengujian yang jelas, telah ditetapkan, dan terukur yang sesuai dengan standar jaminan kualitas software untuk organisasi Anda. Terapkan standar ini ke aplikasi apa pun yang Anda kembangkan dan uji.
• Redundansi: Meskipun lingkungan pengembangan dan pengujian mungkin tidak memerlukan keandalan sebanyak lingkungan production, lingkungan tersebut tetap memerlukan kemampuan yang redundan dan kemampuan untuk menguji berbagai skenario kegagalan. Persyaratan skenario kegagalan 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 saat diperlukan. 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 on demand.
  • Anda dapat mempercepat pengembangan dan pengujian dengan memulai lingkungan sementara untuk setiap permintaan pull. Cara ini juga mengurangi overhead pemeliharaan dan mengurangi inkonsistensi di lingkungan build.
• Menjalankan lingkungan ini di cloud publik membantu membangun pemahaman dan keyakinan terhadap cloud dan alat terkait, yang dapat membantu memigrasikan workload lain. Pendekatan ini sangat membantu jika Anda memutuskan untuk mempelajari Portabilitas beban kerja menggunakan container dan Kubernetes, misalnya menggunakan GKE Enterprise di seluruh lingkungan.

Praktik terbaik

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

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

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

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

• Bangun rantai alat umum yang bekerja di seluruh lingkungan komputasi untuk men-deploy, mengonfigurasi, dan mengoperasikan workload. Penggunaan Kubernetes akan memberi Anda konsistensi ini.

• Pastikan pipeline CI/CD konsisten di seluruh lingkungan komputasi, dan sekumpulan 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 bekerja di seluruh lingkungan. Untuk mengetahui informasi selengkapnya, lihat Solusi DevOps di Google Cloud.

• Untuk membantu Anda dengan rilis aplikasi yang aman dan andal secara berkelanjutan, gabungkan keamanan sebagai bagian integral dari proses DevOps (DevSecOps). Untuk informasi selengkapnya, lihat Mengirim dan mengamankan aplikasi yang terhubung ke internet dalam waktu kurang dari satu jam menggunakan Dev(Sec)Ops Toolkit.

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

• Jika tim yang berbeda mengelola beban kerja pengujian dan produksi, penggunaan alat terpisah mungkin dapat diterima. Namun, penggunaan alat yang sama dengan izin lihat yang berbeda dapat membantu mengurangi upaya dan kerumitan 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 Anda mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan pada lapisan konektivitas, tersedia berbagai opsi berdasarkan solusi konektivitas hibrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN HA melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.

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

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

Pola hybrid dan multicloud kelangsungan bisnis

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

Mengoptimalkan sistem untuk mengatasi 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 beroperasi, keamanan, dan pengalaman pengguna. Untuk mengetahui informasi selengkapnya tentang cara merancang dan mengoperasikan layanan andal di Google Cloud, lihat pilar keandalan Framework Arsitektur Google Cloud dan elemen penyusun keandalan di Google Cloud.

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

Disaster recovery (DR) dianggap sebagai bagian dari kelangsungan bisnis, yang secara eksplisit berfokus untuk memastikan bahwa sistem IT yang mendukung fungsi bisnis penting dapat beroperasi sesegera mungkin setelah terjadinya 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: tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). Untuk mendapatkan panduan lebih lanjut tentang penggunaan Google Cloud untuk mengatasi pemulihan dari bencana, baca Panduan perencanaan pemulihan dari bencana.

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

Keputusan untuk memilih strategi atau pola DR harus didorong oleh analisis dampak bisnis. Misalnya, kerugian finansial yang timbul akibat periode nonaktif selama beberapa menit saja untuk organisasi jasa keuangan dapat jauh melebihi biaya penerapan sistem DR. Namun, bisnis di industri lain mungkin mengalami periode nonaktif selama berjam-jam tanpa efek bisnis yang signifikan.

Saat Anda menjalankan sistem yang sangat penting di pusat data lokal, salah satu pendekatan DR adalah mempertahankan sistem standby di pusat data kedua di region yang berbeda. Namun, pendekatan yang lebih hemat biaya adalah menggunakan lingkungan komputasi berbasis cloud publik untuk tujuan failover. Pendekatan ini adalah pendorong utama pola hibrida kelangsungan bisnis. Dari segi biaya, cloud bisa sangat menarik karena memungkinkan Anda menonaktifkan sebagian infrastruktur DR saat tidak digunakan. Untuk mencapai solusi DR 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 dari bencana pada lingkungan lokal.

Varian yang kurang umum (dan jarang diperlukan) dari pola ini adalah pola cloud kontinuitas 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 apa yang ditawarkan oleh deployment multi-region.

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

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

Jika data Anda harus tetap berada di negara Anda untuk memenuhi persyaratan peraturan, penggunaan penyedia cloud kedua yang juga tersedia di negara Anda sebagai DR dapat menjadi pilihan. Penggunaan penyedia cloud kedua tersebut mengasumsikan bahwa tidak ada opsi untuk menggunakan lingkungan lokal untuk membangun konfigurasi hybrid. Untuk menghindari arsitektur ulang solusi cloud, idealnya penyedia cloud kedua Anda harus menawarkan semua kemampuan dan layanan yang diperlukan di region.

Pertimbangan desain

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

• Pemanggilan DR: Desain dan proses DR Anda harus mempertimbangkan pertanyaan-pertanyaan berikut:

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

  Validasi jawaban Anda atas pertanyaan ini melalui pengujian.

• Pengujian: Uji dan evaluasi failover secara menyeluruh untuk DR. Pastikan failover tersebut memenuhi ekspektasi RPO dan RTO Anda. Melakukan hal tersebut dapat membuat Anda lebih percaya diri untuk memanggil DR saat diperlukan. Setiap kali ada perubahan atau pembaruan baru 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 beban kerja 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 yang berbeda di 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 terpisah. Data yang disimpan dalam 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 yang lebih cepat, dengan RPO yang lebih rendah, objek yang disimpan di dual-region dapat secara opsional menggunakan replikasi turbo di seluruh region tersebut.
  • Replikasi multi-region juga menyediakan redundansi di beberapa region, dengan menyimpan data Anda dalam batas geografis multi-region.
• Memberikan satu atau beberapa opsi berikut untuk mengurangi biaya modal dan biaya operasional untuk membuat DR:
  • Instance VM yang dihentikan hanya dikenai biaya penyimpanan dan jauh lebih murah daripada menjalankan instance VM. Artinya, Anda dapat meminimalkan biaya pemeliharaan sistem cold standby.
  • Dengan model bayar per penggunaan Google Cloud, Anda hanya membayar untuk kapasitas penyimpanan dan komputasi yang benar-benar Anda gunakan.
  • Kemampuan elastisitas, seperti penskalaan otomatis, memungkinkan Anda menskalakan atau mengecilkan lingkungan DR secara otomatis sesuai kebutuhan.

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

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

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

Praktik terbaik

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

• Buat rencana pemulihan dari bencana yang mendokumentasikan infrastruktur Anda beserta prosedur failover dan pemulihan.
• Pertimbangkan tindakan berikut berdasarkan analisis dampak bisnis Anda serta target RPO dan RTO yang diperlukan:
  • Tentukan apakah pencadangan data ke Google Cloud sudah memadai, atau apakah Anda perlu mempertimbangkan strategi DR lain (sistem cold, warm, atau hot standby).
  • 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 Anda pilih.
• Pertimbangkan untuk menggunakan pola handover jika Anda hanya mencadangkan data. Jika tidak, pola meshed mungkin merupakan opsi yang bagus 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 tumpah. Jika Anda mereplikasi data secara dua arah di seluruh lingkungan, Anda mungkin akan terpapar 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 tersebut tidak tersedia dan memiliki akses eksklusif ke data. Hal ini dapat menyebabkan modifikasi data yang bertentangan. Ada dua cara umum untuk menghindari masalah {i>split-brain<i}:

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

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

    Dengan database SQL, Anda dapat menghindari masalah pemecahan masalah dengan membuat instance utama asli tidak dapat diakses sebelum klien mulai menggunakan instance utama baru. Untuk mengetahui informasi selengkapnya, lihat 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.

• Menjadikan semua workload portabel saat menggunakan sistem standby. Semua workload harus portabel (jika didukung oleh aplikasi dan memungkinkan) agar sistem tetap konsisten di seluruh lingkungan. Pendekatan ini dapat dicapai dengan mempertimbangkan container dan Kubernetes. Dengan edisi Google Kubernetes Engine (GKE) Enterprise, Anda dapat menyederhanakan build dan operasinya.

• 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 secara cepat dengan mengonfigurasi DNS dengan waktu aktif yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby ketika 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 guna membuat arsitektur load balancing global untuk berbagai kasus penggunaan, termasuk penyiapan hybrid.

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

  • Tingkatkan ketersediaan serta ketahanan aplikasi dan layanan Anda.

  • Sederhanakan deployment atau migrasi aplikasi hybrid yang memiliki dependensi di 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, bukan load balancer hardware, untuk mendukung beberapa skenario yang terjadi saat menggunakan pola arsitektur ini. Permintaan klien internal atau permintaan klien eksternal dapat dialihkan ke lingkungan utama atau lingkungan DR berdasarkan metrik yang berbeda, seperti pemisahan traffic berdasarkan bobot. Untuk mengetahui informasi selengkapnya, baca 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 kebutuhan Anda, termasuk target RPO dan RTO.

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

• Mengenkripsi komunikasi saat transit. Untuk melindungi informasi sensitif, sebaiknya enkripsi semua komunikasi saat dalam pengiriman. Jika enkripsi diperlukan di lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN 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 menangani berbagai jenis workload yang burst: tugas batch atau CI/CD.

Pola arsitektur ini bergantung pada deployment aplikasi yang redundan di beberapa lingkungan komputasi. Tujuannya adalah untuk meningkatkan kapasitas, ketahanan, atau keduanya.

Meskipun Anda dapat mengakomodasi workload yang burst di lingkungan komputasi berbasis pusat data dengan penyediaan resource yang berlebihan, pendekatan ini mungkin tidak hemat biaya. Dengan tugas batch, Anda dapat mengoptimalkan penggunaan dengan memperpanjang eksekusinya selama jangka waktu yang lebih lama, meskipun menunda tugas tidak akan praktis jika tugas tersebut mendesak.

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

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

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

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

Pertimbangan desain

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

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

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

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

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

• Seperti yang dijelaskan dalam Portabilitas beban kerja, aplikasi mungkin dapat dipindahkan ke lingkungan yang berbeda dengan perubahan minimal untuk mencapai konsistensi beban kerja. Namun, bukan berarti aplikasi memiliki performa yang sama di kedua lingkungan. Perbedaan dalam komputasi dasar, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, beserta kedekatannya dengan layanan dependen, biasanya akan menentukan performa. Melalui pengujian, Anda dapat memiliki visibilitas yang lebih akurat dan memahami ekspektasi performa.

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

  • Gunakan alat yang konsisten untuk memantau dan mengelola kedua lingkungan ini.
  • Pastikan pembuatan versi workload yang konsisten dan sumber data Anda adalah yang terkini.
  • Anda mungkin perlu menambahkan otomatisasi untuk menyediakan lingkungan cloud dan mengubah rute traffic saat permintaan meningkat dan beban kerja cloud diperkirakan akan menerima permintaan klien untuk aplikasi Anda.

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

  • Resource mungkin memerlukan beberapa waktu untuk diinisialisasi sebelum dapat ditayangkan kepada pengguna.
  • Pembaruan DNS cenderung disebarluaskan secara perlahan di internet.

  Sebagai hasilnya:

  • Pengguna mungkin dirutekan ke lingkungan Cloud meskipun tidak ada resource yang tersedia untuk memproses permintaan mereka.
  • Pengguna mungkin tetap dirutekan ke lingkungan lokal untuk sementara, sementara update DNS diterapkan di seluruh internet.

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

Dalam beberapa skenario, Anda dapat menggunakan Cloud DNS untuk mendistribusikan permintaan klien dengan health check di Google Cloud, seperti saat menggunakan Load Balancer Aplikasi internal atau Load Balancer Aplikasi internal lintas region. Dalam skenario ini, Cloud DNS memeriksa respons keseluruhan Load Balancer Aplikasi internal, yang akan memeriksa respons instance backend secara otomatis. Untuk informasi selengkapnya, lihat Mengelola kebijakan pemilihan rute DNS dan health check.

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

Dengan pertimbangan ini, cloud bursting umumnya lebih cocok untuk menangani banyak workload daripada workload interaktif.

Kelebihan

Keuntungan utama dari pola arsitektur cloud bursting meliputi:

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

Praktik terbaik

Saat menerapkan cloud bursting, pertimbangkan praktik terbaik berikut:

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

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

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

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

    Untuk mengetahui informasi lebih lanjut, lihat arsitektur referensi untuk DNS hybrid

• Untuk memastikan perubahan DNS disebarkan dengan cepat, konfigurasikan DNS Anda dengan waktu aktif nilai yang cukup singkat sehingga Anda dapat mengalihkan pengguna ke sistem standby saat Anda memerlukan kapasitas tambahan menggunakan lingkungan cloud.

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

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

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

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

• Saat Cloud Load Balancing digunakan, Anda harus menggunakan kemampuan pengoptimalan kapasitas aplikasi jika memungkinkan. Cara ini dapat membantu Anda mengatasi beberapa tantangan kapasitas yang dapat terjadi pada aplikasi yang didistribusikan secara global.

• Lakukan autentikasi orang yang menggunakan sistem Anda dengan menetapkan identitas umum antarlingkungan, sehingga sistem dapat melakukan autentikasi dengan aman melintasi batas lingkungan.

• Untuk melindungi informasi sensitif, sangat direkomendasikan untuk mengenkripsi semua komunikasi dalam pengiriman. Jika enkripsi diperlukan pada lapisan konektivitas, berbagai opsi tersedia berdasarkan solusi konektivitas hybrid yang dipilih. Opsi ini mencakup tunnel VPN, VPN HA melalui Cloud Interconnect, dan MACsec untuk Cloud Interconnect.

Pola arsitektur hybrid dan multicloud: Langkah selanjutnya

• Pelajari cara menggunakan 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 Aketipe Deployment untuk Aplikasi Cloud.

• Pelajari lebih lanjut pola pengujian dan deployment aplikasi yang umum digunakan.

• Pelajari lebih lanjut 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 API serverless.