Pengelolaan database multicloud: Arsitektur, kasus penggunaan, dan praktik terbaik

Last reviewed 2024-03-06 UTC

Dokumen ini menjelaskan arsitektur deployment, kasus penggunaan, dan praktik terbaik untuk pengelolaan database multi-cloud. Fitur ini ditujukan bagi arsitek dan engineer yang mendesain dan menerapkan aplikasi stateful di dalam dan di berbagai clouds.

Arsitektur aplikasi multi-cloud yang mengakses database bergantung pada kasus penggunaan. Tidak ada satu arsitektur aplikasi stateful yang dapat mendukung semua kasus penggunaan multicloud. Misalnya, solusi database terbaik untuk kasus penggunaan cloud bursting berbeda dengan solusi database terbaik untuk aplikasi yang berjalan serentak di beberapa lingkungan cloud.

Untuk cloud publik seperti Google Cloud, ada berbagai teknologi database yang sesuai dengan kasus penggunaan multicloud tertentu. Untuk men-deploy aplikasi di beberapa region dalam satu cloud publik, salah satu opsi adalah dengan menggunakan database multi-regional cloud publik, yang dikelola penyedia, seperti Spanner. Untuk men-deploy aplikasi agar portabel di seluruh cloud publik, database yang tidak bergantung pada platform mungkin menjadi pilihan yang lebih baik, seperti PostgreSQL.

Dokumen ini memperkenalkan definisi dari aplikasi database stateful yang diikuti dengan analisis kasus penggunaan database multicloud. Halaman ini kemudian menyajikan detail kategorisasi sistem database untuk arsitektur deployment multicloud berdasarkan kasus penggunaannya.

Dokumen ini juga memperkenalkan pohon keputusan untuk memilih database yang menjelaskan titik-titik keputusan utama untuk memilih teknologi database yang sesuai. Bagian ini diakhiri dengan diskusi tentang praktik terbaik untuk pengelolaan database multi-cloud.

Istilah dan definisi utama

Bagian ini menyediakan terminologi dan menentukan aplikasi database stateful generik yang digunakan dalam dokumen ini.

Terminologi

• Cloud publik. Cloud publik menyediakan infrastruktur multi-tenant (umumnya global) dan layanan yang dapat digunakan pelanggan untuk menjalankan workload produksi mereka. Google Cloud adalah cloud publik yang menyediakan banyak layanan terkelola, termasuk GKE, GKE Enterprise, dan database terkelola.
• Hybrid cloud. Hybrid cloud adalah kombinasi cloud publik dengan satu atau beberapa pusat data lokal. Pelanggan hybrid cloud dapat menggabungkan layanan lokal mereka dengan layanan tambahan yang disediakan oleh cloud publik.
• Multicloud. Multi-cloud adalah kombinasi dari beberapa cloud publik dan pusat data lokal. Hybrid cloud adalah subset dari multicloud.
• Lokasi deployment. Lokasi infrastruktur adalah lokasi fisik yang dapat men-deploy dan menjalankan beban kerja, termasuk aplikasi dan database. Misalnya, di Google Cloud, lokasi deployment adalah zona dan region. Pada tingkat abstrak, region atau zona cloud publik dan pusat data lokal adalah lokasi deployment.

Aplikasi database stateful

Untuk menentukan kasus penggunaan multicloud, arsitektur aplikasi database stateful umum digunakan dalam dokumen ini, seperti yang ditunjukkan dalam diagram berikut.

Diagram tersebut menampilkan komponen berikut:

• Database. Database dapat berupa database tunggal, multi-instance, atau database terdistribusi, yang di-deploy di node komputasi atau tersedia sebagai layanan yang dikelola cloud.
• Layanan aplikasi. Layanan ini digabungkan sebagai aplikasi yang mengimplementasikan logika bisnis. Layanan aplikasi dapat berupa salah satu dari hal berikut:
  • Microservice di Kubernetes.
  • Proses terperinci yang berjalan di satu atau beberapa virtual machine.
  • Aplikasi monolitik di satu virtual machine besar.
  • Kode serverless di fungsi Cloud Run atau Cloud Run. Beberapa layanan aplikasi dapat mengakses database. Anda dapat men-deploy setiap layanan aplikasi beberapa kali. Setiap deployment layanan aplikasi adalah instance layanan aplikasi tersebut.
• Klien aplikasi. Klien aplikasi mengakses fungsionalitas yang disediakan oleh layanan aplikasi. Klien aplikasi dapat berupa salah satu dari berikut ini:
  • Klien yang di-deploy, tempat kode dijalankan yaitu di mesin, laptop, atau ponsel.
  • Klien yang tidak di-deploy, tempat kode klien berjalan di browser. Instance klien aplikasi selalu mengakses satu atau beberapa instance layanan aplikasi.

Dalam konteks diskusi database multicloud, abstraksi arsitektur aplikasi stateful terdiri dari database, layanan aplikasi, dan klien aplikasi. Dalam implementasi aplikasi, faktor-faktor seperti penggunaan sistem operasi atau bahasa pemrograman yang digunakan dapat bervariasi. Namun, detail ini tidak memengaruhi pengelolaan database multi-cloud.

Antrean dan file sebagai layanan penyimpanan data

Ada banyak resource persistensi yang tersedia bagi layanan aplikasi untuk mempertahankan data. Resource ini mencakup database, antrean, dan file. Setiap resource persistensi menyediakan model data penyimpanan dan pola akses yang dikhususkan untuk model ini. Meskipun antrean, sistem pesan, dan sistem file digunakan oleh aplikasi, bagian berikut, secara khusus berfokus pada database.

Meskipun pertimbangan yang sama untuk faktor-faktor seperti lokasi deployment, pembagian status, replikasi sinkron, dan asinkron untuk database multicloud juga berlaku untuk antrean dan file, diskusi tersebut berada di luar cakupan dokumen ini.

Jaringan

Dalam arsitektur aplikasi stateful generik (ditunjukkan lagi dalam diagram berikut), setiap panah di antara komponen mewakili hubungan komunikasi melalui koneksi jaringan. Misalnya, klien aplikasi mengakses layanan aplikasi.

Koneksi dapat berada dalam satu zona maupun di seluruh zona, region, atau cloud. Koneksi dapat muncul di antara kombinasi lokasi deployment. Dalam lingkungan multicloud, berjejaring di seluruh cloud menjadi pertimbangan penting dan ada beberapa opsi yang dapat Anda gunakan. Untuk mengetahui informasi selengkapnya tentang cara berjejaring di seluruh cloud, lihat Menghubungkan ke Google Cloud: penjelasan tentang opsi jaringan Anda.

Pada kasus penggunaan dalam dokumen ini, hal berikut diasumsikan:

• Koneksi jaringan yang aman ada di antara cloud.
• Database dan komponen-komponennya dapat saling berkomunikasi.

Dari perspektif non-fungsional, ukuran jaringan, dalam hal ini berarti throughput dan latensi, dapat memengaruhi latensi dan throughput database. Dari perspektif fungsional, jaringan umumnya tidak memiliki pengaruh apapun.

Kasus penggunaan database multicloud

Bagian ini menampilkan pilihan kasus penggunaan yang paling umum untuk pengelolaan database multi-cloud. Untuk kasus penggunaan ini, diasumsikan bahwa ada konektivitas jaringan yang aman antara cloud dan node database.

Migrasi aplikasi

Dalam konteks pengelolaan database multi-cloud, migrasi aplikasi mengacu pada migrasi aplikasi, semua layanan aplikasi, dan database dari cloud saat ini ke cloud target. Ada banyak alasan mengapa sebuah perusahaan memutuskan untukmemigrasikan aplikasi, misalnya, untuk menghindari situasi kompetitif dengan penyedia cloud, memodernisasi teknologi, atau menurunkan total biaya kepemilikan (TCO).

Tujuan migrasi aplikasi adalah untuk menghentikan produksi di cloud saat ini dan melanjutkan produksi di cloud target setelah migrasi selesai. Layanan aplikasi harus berjalan di cloud target. Untuk menerapkan layanan tersebut, pendekatan lift and shift dapat digunakan. Dalam pendekatan ini, kode yang sama di-deploy di cloud target. Untuk mengimplementasikan kembali layanan ini, teknologi cloud modern yang tersedia di cloud target dapat digunakan.

Dari perspektif database, pertimbangkan pilihan alternatif berikut untuk migrasi aplikasi:

• Database lift and shift: Jika mesin database yang sama tersedia di cloud target, database dapat diangkat dan digeser untuk membuat deployment yang identik di cloud target.
• Database lift and move untuk pengelolaan setara: Database yang dikelola sendiri dapat dimigrasikan ke versi terkelola dari mesin database yang sama jika cloud target menyediakannya.
• Modernisasi database: Cloud yang berbeda menawarkan teknologi database yang berbeda. Database yang dikelola oleh penyedia cloud memiliki keunggulan, seperti perjanjian tingkat layanan (SLA) yang lebih ketat, skalabilitas, dan pemulihan dari bencana secara otomatis.

Terlepas dari strategi deployment, migrasi database adalah proses yang memakan waktu karena adanya kebutuhan untuk memindahkan data dari cloud saat ini ke cloud target. Meskipun Anda dapat mengikuti pendekatan ekspor dan impor yang menimbulkan periode nonaktif, migrasi periode nonaktif minimal atau nol lebih disarankan. Pendekatan ini meminimalkan periode nonaktif aplikasi dan memiliki efek paling sedikit terhadap perusahaan dan pelanggannya. Namun, biasanya memerlukan penyiapan migrasi yang lebih rumit karena melibatkan pemuatan awal, replika yang sedang berlangsung, pemantauan, validasi terperinci, dan sinkronisasi saat beralih. Untuk mendukung skenario penggantian, Anda perlu menerapkan mekanisme replikasi terbalik, untuk menyinkronkan perubahan kembali ke database sumber setelah beralih ke database target.

Pemulihan dari bencana

Pemulihan dari bencana (disaster recovery) mengacu pada kemampuan aplikasi untuk terus menyediakan layanan ke klien aplikasi selama pemadaman layanan region. Untuk memastikan pemulihan dari bencana, aplikasi harus di-deploy setidaknya ke dua region dan siap dieksekusi kapan saja. Dalam produksi, aplikasi berjalan di region utama. Namun, jika terjadi pemadaman, region sekunder akan menjadi region utama. Berikut ini berbagai model kesiapan dalam pemulihan dari bencana:

• Model hot standby. Aplikasi di-deploy ke dua region atau lebih (primer dan sekunder), dan aplikasi berfungsi sepenuhnya di setiap region. Jika region utama gagal, aplikasi di region sekunder dapat segera menerima traffic klien aplikasi.
• Model cold standby. Aplikasi ini berjalan di region utama, tetapi siap untuk memulai di region sekunder (tetapi tidak berjalan). Jika region utama gagal, aplikasi akan dimulai di region sekunder. Pemadaman aplikasi akan terjadi hingga aplikasi dapat berjalan dan menyediakan semua layanan aplikasi ke klien aplikasi.
• Model no standby. Dalam model ini, kode aplikasi siap di-deploy, tetapi belum di-deploy di region sekunder (sehingga tidak menggunakan resource yang di-deploy). Jika region utama mengalami pemadaman, deployment pertama pada aplikasi harus berada di region sekunder. Deployment ini menempatkan aplikasi dalam status yang sama dengan cold standby, yang berarti aplikasi tersebut harus dimulai. Dalam pendekatan ini, pemadaman aplikasi menjadi lebih lama dibandingkan dengan kasus cold standby karena deployment aplikasi harus dilakukan terlebih dahulu, termasuk membuat resource cloud.

Dari perspektif database, model kesiapan yang dibahas dalam daftar sebelumnya sesuai dengan pendekatan database berikut:

• Database yang disinkronkan secara transaksi. Database ini sesuai dengan model hot standby. Setiap transaksi di region utama di-commit dalam koordinasi sinkron di region sekunder. Saat region sekunder menjadi region utama selama pemadaman, database akan konsisten dan segera tersedia. Dalam model ini, batas titik pemulihan (RPO) dan batas waktu pemulihan (RTO) keduanya adalah nol.
• Database yang direplikasi secara asinkron. Database ini juga sesuai dengan model hot standby. Karena replikasi database dari region utama ke region sekunder bersifat asinkron, ada kemungkinan bahwa jika region utama gagal, beberapa transaksi dapat direplikasi ke region sekunder. Meskipun database di region sekunder siap menerima beban produksi, database tersebut mungkin tidak memiliki data terbaru. Karena alasan ini, aplikasi dapat kehilangan transaksi yang tidak dapat dipulihkan. Dengan adanya risiko tersebut, pendekatan ini memiliki RTO nol, tetapi RPO-nya lebih besar dari nol.
• Database nonaktif. Database ini sesuai dengan model cold standby. Database ini dibuat tanpa data apa pun. Jika region utama gagal, data harus dimuat ke database nonaktif. Untuk memungkinkan tindakan ini, pencadangan reguler harus diambil di region utama dan ditransfer ke region sekunder. Pencadangan dapat bersifat penuh atau inkremental, tergantung dukungan yang dimiliki mesin database. Dalam kedua kasus tersebut, database disetel kembali ke cadangan terakhir, dan, dari perspektif aplikasi, banyak transaksi dapat hilang dibandingkan dengan region utama. Meskipun pendekatan ini mungkin hemat biaya, keuntungan ini dimitigasi oleh risiko bahwa semua transaksi sejak pencadangan terakhir yang tersedia mungkin akan hilang karena status database tidak diperbarui.
• Tidak ada database. Model ini setara dengan kasus model no standby. Region sekunder tidak memiliki database yang terinstal, dan jika region utama gagal, database harus dibuat. Setelah dibuat, seperti dalam kasus database nonaktif, database harus dimuat dengan data sebelum tersedia untuk aplikasi.

Pendekatan pemulihan dari bencana yang dibahas dalam dokumen ini juga berlaku apabila cloud primer dan sekunder yang digunakan daripada region primer dan sekunder. Perbedaan utamanya adalah karena heterogenitas jaringan antar-cloud, latensi antar-cloud dapat meningkat dibandingkan dengan jarak jaringan antar-region dalam satu cloud. Perbedaan lainnya mungkin berasal dari fitur dan setelan default yang berbeda dari database terkelola dari berbagai penyedia cloud.

Kemungkinan kegagalan keseluruhan cloud lebih kecil daripada kemungkinan kegagalan region. Namun, akan berguna bagi perusahaan untuk memiliki aplikasi yang di-deploy di dua cloud. Pendekatan ini dapat membantu melindungi perusahaan dari kegagalan, atau membantunya memenuhi peraturan bisnis maupun industri.

Pendekatan pemulihan dari bencana lainnya adalah dengan memiliki region primer dan sekunder serta cloud primer dan sekunder. Dengan pendekatan ini, perusahaan dapat memilih proses pemulihan dari bencana terbaik untuk mengatasi situasi kegagalan. Agar aplikasi dapat berjalan, baik region sekunder maupun cloud sekunder dapat digunakan, bergantung pada tingkat keparahan pemadaman.

Cloud bursting

Cloud bursting mengacu pada konfigurasi yang memungkinkan peningkatan skala traffic klien aplikasi di berbagai lokasi deployment. Aplikasi burst saat permintaan kapasitas meningkat dan lokasi standby menyediakan kapasitas tambahan. Lokasi utama mendukung traffic reguler, sedangkan lokasi standby dapat memberikan kapasitas tambahan jika traffic klien aplikasi meningkat melebihi yang dapat didukung oleh lokasi utama. Baik lokasi utama maupun standby memiliki instance layanan aplikasi yang di-deploy.

Cloud bursting diterapkan di seluruh cloud, dengan satu cloud merupakan cloud utama dan cloud selanjutnya adalah cloud standby. Layanan ini digunakan dalam konteks hybrid cloud untuk meningkatkan sejumlah resource komputasi di pusat data lokal dengan resource cloud computing yang elastis di cloud publik.

Opsi berikut tersedia untuk mendukung database:

• Deployment lokasi utama. Dalam deployment ini, database hanya di-deploy di lokasi utama dan bukan di lokasi standby. Saat aplikasi melakukan bursting, aplikasi yang berada dalam lokasi standby akan mengakses database di lokasi utama.
• Deployment lokasi utama dan standby. Deployment ini mendukung lokasi utama dan standby. Instance database di-deploy di kedua lokasi dan diakses oleh instance layanan aplikasi di lokasi tersebut, terutama dalam kasus bursting. Seperti dalam Pemulihan dari bencana di dalam dan di seluruh cloud, kedua database ini dapat disinkronkan secara transaksional, atau disinkronkan secara asinkron. Pada sinkronisasi asinkron, mungkin terjadi penundaan. Jika update dilakukan di lokasi standby, update ini harus diterapkan kembali ke lokasi utama. Jika update serentak mungkin untuk dilakukan di kedua lokasi, resolusi konflik harus diterapkan.

Cloud bursting adalah kasus penggunaan umum dalam hybrid cloud untuk meningkatkan kapasitas di pusat data lokal. Ini juga termasuk pendekatan yang dapat digunakan di seluruh cloud publik ketika data harus berada di dalam suatu negara. Jika cloud publik hanya memiliki satu region di satu negara, bisa saja terjadi burst ke region cloud publik yang berbeda di negara yang sama. Pendekatan ini memastikan bahwa data tetap berada di dalam negara sambil tetap mengatasi batasan resource di region cloud publik.

Penggunaan layanan cloud terbaik di kelasnya

Beberapa aplikasi memerlukan produk dan layanan cloud khusus yang tidak tersedia di satu cloud. Misalnya, aplikasi mungkin melakukan pemrosesan logika bisnis atas data bisnis di satu cloud, dan analisis data bisnis di cloud lain. Dalam kasus penggunaan ini, bagian pemrosesan logika bisnis dan bagian analisis aplikasi di-deploy ke cloud yang berbeda.

Dari perspektif pengelolaan data, kasus penggunaannya adalah sebagai berikut:

• Data yang dipartisi. Setiap bagian aplikasi memiliki database-nya sendiri (partisi terpisah) dan tidak ada database yang terhubung secara langsung satu sama lain. Aplikasi yang mengelola data menulis data apa pun yang harus tersedia di kedua database (partisi) sebanyak dua kali.
• Database yang direplikasi secara asinkron. Jika data dari satu cloud harus tersedia di cloud lain, hubungan replikasi asinkron mungkin saja sesuai. Misalnya, jika aplikasi analisis memerlukan set data yang sama atau subset set data untuk aplikasi bisnis, set data tersebut dapat direplikasi di antara cloud.
• Database yang disinkronkan secara transaksi. Jenis database ini memungkinkan Anda membuat data tersedia untuk kedua bagian aplikasi. Setiap update dari setiap aplikasi selalu konsisten secara transaksional dan langsung tersedia untuk kedua database (partisi). Database yang disinkronkan secara transaksional secara efektif berfungsi sebagai satu database terdistribusi.

Layanan terdistribusi

Layanan terdistribusi di-deploy dan dieksekusi di dua lokasi deployment atau lebih. Anda dapat men-deploy semua instance layanan ke semua lokasi deployment. Selain itu, Anda dapat men-deploy beberapa layanan di semua lokasi, dan beberapa layanan hanya di salah satu lokasi, berdasarkan faktor seperti ketersediaan hardware atau beban terbatas yang diperkirakan.

Data dalam database yang disinkronkan secara transaksional, konsisten di semua lokasi. Oleh karena itu, database tersebut adalah opsi terbaik untuk men-deploy instance layanan ke semua lokasi deployment.

Saat Anda menggunakan database yang direplikasi secara asinkron, ada risiko item data yang sama diubah di dua lokasi deployment secara bersamaan. Untuk menentukan mana dua perubahan yang bertentangan yang merupakan status konsistensi akhir, strategi penyelesaian konflik harus diterapkan. Meskipun menerapkan strategi penyelesaian konflik mungkin dilakukan, hal ini tidak selalu mudah, dan ada kalanya intervensi manual diperlukan untuk memulihkan data ke kondisi yang konsisten.

Relokasi dan failover layanan terdistribusi

Jika seluruh region cloud gagal, pemulihan bencana akan dimulai. Jika satu layanan dalam aplikasi database stateful gagal (bukan region atau keseluruhan aplikasi), layanan tersebut harus dipulihkan dan dimulai ulang.

Pendekatan awal untuk pemulihan dari bencana (disaster recovery) adalah memulai ulang layanan yang gagal di lokasi asli deployment (pendekatan mulai ulang langsung). Teknologi seperti Kubernetes secara otomatis memulai ulang layanan berdasarkan konfigurasinya.

Namun, jika pendekatan mulai ulang ini tidak berhasil, alternatifnya adalah memulai ulang layanan di lokasi sekunder. Layanan mungkin gagal beralih dari lokasi utamanya ke lokasi sekunder. Jika aplikasi di-deploy sebagai satu kumpulan layanan terdistribusi, failover dari satu layanan dapat terjadi secara dinamis.

Dari perspektif database, memulai ulang layanan di lokasi asli deployment tidak memerlukan deployment database tertentu. Saat layanan dipindahkan ke lokasi deployment alternatif dan layanan tersebut mengakses database, model kesiapan yang sama akan berlaku seperti yang telah dibahas dalam Layanan terdistribusi sebelumnya dalam dokumen ini.

Jika layanan dipindahkan untuk sementara, dan jika latensi yang lebih tinggi dapat diterima untuk perusahaan selama relokasi, layanan tersebut dapat mengakses database di seluruh lokasi deployment. Meskipun dipindahkan, layanan terus mengakses database dengan cara yang sama seperti dari lokasi asli deployment.

Deployment yang bergantung pada konteks

Secara umum, satu deployment aplikasi digunakan untuk melayani semua klien aplikasi termasuk semua layanan dan database aplikasi-nya. Namun, ada beberapa kasus penggunaan yang luar biasa. Deployment aplikasi tunggal hanya dapat melayani subset klien (berdasarkan kriteria tertentu), yang berarti diperlukan lebih dari satu deployment aplikasi. Setiap deployment melayani subset klien yang berbeda, dan semua deployment sama-sama melayani semua klien.

Contoh kasus penggunaan untuk deployment yang bergantung pada konteks adalah sebagai berikut:

• Saat men-deploy aplikasi multi-tenant dimana satu aplikasi di-deploy untuk semua tenant kecil, aplikasi lain di-deploy untuk setiap 10 tenant sedang, dan satu aplikasi di-deploy untuk setiap tenant premium.
• Saat ada kebutuhan untuk memisahkan pelanggan, misalnya, pelanggan bisnis dan pelanggan pemerintah.
• Saat pemisahan lingkungan pengembangan, staging, dan produksi diperlukan.

Dari perspektif database, satu database dapat di-deploy untuk setiap deployment aplikasi dalam strategi deployment one-to-one. Seperti yang ditunjukkan pada diagram berikut, strategi ini adalah pendekatan mudah tempat data yang dipartisi dibuat karena setiap deployment memiliki set data sendiri.

Diagram di atas menunjukkan hal berikut:

• Pengaturan tiga deployment aplikasi.
• Setiap dataset memiliki database masing-masing.
• Tidak ada data yang dibagikan di antara deployment.

Dalam banyak situasi, deployment one-to-one adalah strategi yang paling tepat. Namun, ada beberapa alternatif lain.

Dalam kasus multi-tenancy, tenant mungkin akan dipindahkan. Tenant kecil dapat berubah menjadi tenant sedang dan harus dipindahkan ke aplikasi lain. Oleh karena itu, deployment database secara terpisah memerlukan migrasi database. Jika database terdistribusi di-deploy dan digunakan oleh semua deployment secara bersamaan, maka semua data tenant berada dalam satu sistem database. Oleh karena itu, pemindahan tenant antar-database tidak memerlukan migrasi database. Diagram berikut menunjukkan contoh jenis database ini:

Diagram di atas menunjukkan hal berikut:

• Tiga deployment aplikasi.
• Semua deployment menggunakan satu database yang terdistribusi.
• Aplikasi dapat mengakses semua data di setiap deployment.
• Tidak ada partisi data yang diterapkan.

Jika perusahaan sering memindahkan tenant sebagai bagian dari operasi siklus proses, replikasi database dapat menjadi alternatif yang berguna. Dalam pendekatan ini, data tenant direplikasi antar database sebelum migrasi tenant dilakukan. Oleh karena itu, database independen digunakan untuk berbagai deployment aplikasi dan hanya disiapkan untuk replikasi tepat sebelum dan selama migrasi tenant berlangsung. Diagram berikut menunjukkan replikasi sementara antara dua deployment aplikasi selama migrasi tenant.

Diagram sebelumnya menunjukkan tiga deployment aplikasi dengan tiga database terpisah yang menyimpan data yang terkait dengan masing-masing deployment. Untuk memigrasikan data dari satu database ke database lainnya, migrasi database sementara dapat disiapkan.

Portabilitas aplikasi

Portabilitas aplikasi memastikan bahwa aplikasi dapat di-deploy ke lokasi deployment yang berbeda, terutama cloud yang berbeda. Portabilitas ini memastikan bahwa aplikasi dapat dimigrasikan kapan saja, tanpa perlu rekayasa ulang khusus migrasi atau pengembangan aplikasi tambahan untuk menyiapkan migrasi aplikasi.

Untuk memastikan portabilitas aplikasi, Anda dapat menggunakan salah satu pendekatan berikut, yang akan dijelaskan lebih lanjut di bagian ini:

• Portabilitas berbasis sistem
• Kompatibilitas API
• Portabilitas berbasis fungsi

Portabilitas berbasis sistem menggunakan komponen teknis yang sama dengan yang digunakan di semua kemungkinan deployment. Untuk memastikan portabilitas berbasis sistem, setiap teknologi harus tersedia di semua lokasi deployment potensial. Misalnya, jika database seperti PostgreSQL adalah kandidat, ketersediaannya di semua lokasi deployment potensial harus diverifikasi untuk jangka waktu yang diharapkan. Hal yang sama berlaku untuk semua teknologi lainnya misalnya, bahasa pemrograman dan teknologi infrastruktur. Seperti yang ditunjukkan dalam diagram berikut, pendekatan ini menetapkan sekumpulan fungsi umum di semua lokasi deployment berdasarkan teknologi.

Diagram di atas menunjukkan deployment aplikasi portabel ketika aplikasi mengharapkan sistem database yang sama persis di setiap lokasi tempatnya di-deploy. Karena sistem database yang sama digunakan di setiap lokasi, aplikasi tersebut bersifat portabel. Aplikasi dapat memperkirakan bahwa sistem database yang sama persis akan digunakan di seluruh deployment. Oleh karena itu, antarmuka dan perilaku sistem database yang sama persis dapat diasumsikan.

Dalam konteks database, dalam sistem kompatibilitas API, klien menggunakan library akses database tertentu (misalnya, library klien MySQL) untuk memastikan bahwa klien dapat terhubung ke implementasi yang sesuai yang mungkin tersedia di lingkungan cloud. Diagram berikut mengilustrasikan kompatibilitas API.

Diagram di atas menunjukkan portabilitas aplikasi berdasarkan API sistem database, bukan sistem database. Meskipun sistem database bisa saja berbeda di setiap lokasi, API yang ditampilkan sama dan memiliki fungsi yang sama. Aplikasi ini portabel karena dapat mengasumsikan API yang sama di setiap lokasi, meskipun sistem database yang mendasarinya adalah teknologi database yang berbeda.

Dalam portabilitas berbasis fungsi, teknologi yang berbeda di cloud yang berbeda dapat digunakan untuk memberikan fungsi yang sama. Misalnya, Anda mungkin dapat membatasi penggunaan database pada model relasional. Karena setiap sistem database relasional dapat mendukung aplikasi, sistem database yang berbeda pada versi yang berbeda dapat digunakan di cloud yang berbeda tanpa memengaruhi portabilitas aplikasi. Kelemahan dari portabilitas berbasis fungsi adalah bahwa fungsi ini hanya dapat menggunakan bagian-bagian model database yang didukung oleh semua sistem database relasional. Sebagai ganti sistem database yang kompatibel dengan semua cloud, model database harus digunakan. Diagram berikut menunjukkan contoh arsitektur untuk portabilitas berbasis fungsi.

Seperti yang ditunjukkan pada diagram sebelumnya, API sistem database dan sistem database mungkin berbeda di setiap lokasi. Untuk memastikan portabilitas, aplikasi hanya boleh menggunakan bagian-bagian dari setiap sistem database dan setiap API yang tersedia di setiap lokasi. Karena hanya sebagian dari setiap sistem database yang biasanya tersedia di setiap lokasi, aplikasi harus membatasi penggunaannya untuk subset tersebut.

Guna memastikan portabilitas untuk semua opsi di bagian ini, arsitektur yang lengkap harus di-deploy secara terus-menerus ke semua lokasi target. Semua kasus pengujian unit dan sistem harus dijalankan terhadap deployment ini. Hal ini menjadi persyaratan penting agar perubahan infrastruktur dan teknologi dapat dideteksi dan ditangani lebih awal.

Pencegahan dependensi vendor

Pencegahan dependensi vendor (keterikatan) membantu mengurangi risiko dependensi pada teknologi dan vendor tertentu. Ini cukup mirip dengan portabilitas aplikasi. Pencegahan dependensi vendor berlaku untuk semua teknologi yang digunakan, bukan hanya layanan cloud. Misalnya, jika MySQL digunakan sebagai sistem database dan diinstal pada mesin virtual di cloud, maka tidak ada dependensi dari perspektif cloud, tetapi ada dependensi pada MySQL. Aplikasi yang portabel di seluruh cloud mungkin masih bergantung pada teknologi yang disediakan oleh vendor yang berbeda dengan cloud.

Untuk mencegah ketergantungan vendor, semua teknologi harus dapat diganti. Dengan demikian, abstraksi yang menyeluruh dan terstruktur untuk semua fungsi aplikasi diperlukan agar setiap layanan aplikasi dapat diimplementasikan kembali ke basis teknologi yang berbeda tanpa memengaruhi cara aplikasi diimplementasikan. Dari perspektif database, abstraksi ini dapat dilakukan dengan memisahkan penggunaan model database dari sistem pengelolaan database tertentu.

Sistem pengelolaan database produksi yang ada

Meskipun banyak aplikasi multicloud yang dikembangkan dengan sistem database sebagai bagian dari desainnya, banyak perusahaan mengembangkan aplikasi multicloud sebagai bagian dari upaya modernisasi aplikasi mereka. Aplikasi ini dikembangkan dengan asumsi bahwa aplikasi yang baru dirancang dan diterapkan dapat mengakses database yang ada.

Ada banyak alasan untuk tidak menggabungkan database yang ada ke dalam upaya modernisasi. Mungkin terdapat fitur spesifik yang digunakan yang tidak tersedia dari sistem database lain. Perusahaan mungkin memiliki database dengan proses pengelolaan yang kompleks dan sudah stabil, sehingga peralihan ke sistem yang berbeda menjadi tidak praktis atau tidak ekonomis. Di sisi lain, perusahaan dapat memilih untuk memodernisasi aplikasi pada fase pertama, dan memodernisasi database pada fase kedua.

Ketika perusahaan menggunakan sistem database yang sudah ada, desainer aplikasi multicloud harus memutuskan apakah aplikasi tersebut akan menjadi satu-satunya database yang digunakan, atau apakah sistem database yang berbeda perlu ditambahkan untuk deployment dengan lokasi berbeda. Misalnya, jika database digunakan di infrastruktur lokal dan aplikasi juga perlu dijalankan di Google Cloud, mereka perlu mempertimbangkan apakah layanan aplikasi yang di-deploy di Google Cloud akan mengakses database di infrastruktur lokal. Sebagai alternatif, jika database kedua harus di-deploy di Google Cloud dan untuk layanan aplikasi yang berjalan secara lokal.

Jika database kedua di-deploy di Google Cloud, kasus penggunaannya mungkin sama dengan kasus penggunaan yang dibahas dalam Cloud bursting atau Distributed services. Dalam kedua kasus tersebut, diskusi database yang sama berlaku seperti pada bagian ini. Namun, fungsi ini terbatas pada fungsi lintas lokasi yang dapat didukung oleh database lokal yang ada misalnya, sinkronisasi dan replikasi.

Pola deployment

Kasus penggunaan yang dibahas dalam dokumen ini menimbulkan pertanyaan umum dari perspektif database: jika database berada di lebih dari satu lokasi deployment, bagaimana hubungan mereka?

Jenis utama hubungan (pola deployment), yang akan dibahas di bagian selanjutnya adalah sebagai berikut:

• Dipartisi tanpa dependensi lintas-database
• Replikasi searah asinkron
• Replikasi dua arah dengan resolusi konflik
• Sistem terdistribusi yang disinkronkan secara aktif-aktif

Anda dapat memetakan setiap kasus penggunaan dalam dokumen ini ke satu atau beberapa dari empat pola deployment.

Dalam diskusi berikut, diasumsikan bahwa klien mengakses layanan aplikasi secara langsung. Bergantung pada kasus penggunaan, load balancer mungkin diperlukan untuk mengarahkan akses klien secara dinamis ke aplikasi, seperti yang ditampilkan dalam diagram berikut.

Dalam diagram sebelumnya, load balancer cloud mengarahkan panggilan klien ke salah satu lokasi yang tersedia. Load balancer memastikan bahwa kebijakan load balancing diterapkan dan klien diarahkan ke lokasi aplikasi serta database-nya yang benar.

Dipartisi tanpa dependensi lintas-database

Pola deployment ini adalah yang paling sederhana dari semua pola yang dibahas dalam dokumen ini: setiap lokasi atau cloud memiliki database dan database tersebut berisi set data yang dipartisi yang tidak saling bergantung. Item data hanya disimpan dalam satu database. Setiap partisi data berada di database-nya sendiri. Contoh untuk pola ini adalah aplikasi multi-tenant tempat set data berada di salah satu atau database lainnya. Diagram berikut menunjukkan dua aplikasi yang dipartisi sepenuhnya.

Seperti yang ditunjukkan diagram sebelumnya, aplikasi di-deploy di dua lokasi, masing-masing bertanggung jawab atas partisi seluruh set data. Setiap item data hanya berada di salah satu lokasi, untuk memastikan set data yang dipartisi tanpa replikasi di antara keduanya.

Pola deployment alternatif untuk database yang dipartisi adalah tempat set data dipartisi sepenuhnya tetapi masih disimpan dalam database yang sama. Hanya ada satu database yang berisi seluruh set data. Meskipun disimpan dalam database yang sama, set data benar-benar terpisah (dipartisi) dan perubahan pada satu set data tidak menyebabkan perubahan pada set data lainnya. Diagram berikut menunjukkan dua aplikasi yang menggunakan satu database.

Diagram di atas menunjukkan hal berikut:

• Dua deployment aplikasi yang keduanya menggunakan database yang sama, yaitu di lokasi pertama.
• Setiap aplikasi dapat mengakses semua data dalam deployment karena set data tidak dipartisi.

Replikasi searah asinkron

Pola deployment ini memiliki database utama yang mereplikasi ke satu atau beberapa database sekunder. Database sekunder dapat digunakan untuk akses baca, tetapi aplikasi harus memperhitungkan potensi keterlambatan replikasi. Contoh untuk pola ini adalah saat database terbaik untuk kasus penggunaan tertentu digunakan sebagai database utama dan database sekunder digunakan untuk analisis. Diagram berikut menunjukkan dua aplikasi yang mengakses database yang direplikasi secara searah.

Seperti yang ditunjukkan diagram di atas, salah satu dari dua database tersebut adalah replika database lainnya. Panah dalam diagram menunjukkan arah replikasi: data dari sistem database di lokasi 1 direplikasi ke sistem database di lokasi 2.

Replikasi dua arah dengan resolusi konflik

Pola deployment ini memiliki dua database utama yang direplikasi secara asinkron satu sama lain. Jika data yang sama ditulis secara bersamaan ke setiap database (misalnya, kunci utama yang sama), konflik tulis-tulis dapat terjadi. Dengan adanya risiko ini, maka harus ada penyelesaian konflik untuk menentukan status mana yang merupakan status terakhir selama replikasi. Pola ini dapat digunakan dalam situasi saat kemungkinan konflik tulis-tulis jarang terjadi. Diagram berikut menunjukkan dua aplikasi yang mengakses database yang direplikasi secara dua arah.

Seperti yang ditunjukkan diagram di atas, setiap database direplikasi ke database lainnya. Kedua replikasi bersifat independen satu sama lain, seperti yang ditunjukkan dalam diagram oleh dua panah biru yang terpisah. Karena dua replikasi bersifat independen, konflik dapat terjadi jika secara kebetulan item data yang sama diubah oleh masing-masing aplikasi dan direplikasi secara serentak. Oleh karena itu, resolusi konflik harus dilakukan.

Sistem terdistribusi yang disinkronkan secara aktif-aktif

Pola deployment ini memiliki satu database yang memiliki penyiapan aktif-aktif (juga utama-utama). Dalam penyiapan aktif-aktif, update data di database utama akan konsisten secara transaksional dan direplikasi secara sinkron. Contoh kasus penggunaan untuk pola ini adalah komputasi terdistribusi. Diagram berikut menunjukkan dua aplikasi yang mengakses database primer-utama yang disinkronkan sepenuhnya.

Seperti yang ditunjukkan diagram sebelumnya, pengaturan ini memastikan bahwa setiap aplikasi selalu mengakses status terakhir yang konsisten, tanpa penundaan atau risiko konflik. Perubahan di satu database langsung tersedia di database lainnya. Setiap perubahan akan tercermin di kedua database saat commit transaksi yang berubah terjadi.

Kategorisasi sistem database

Tidak semua sistem pengelolaan database dapat digunakan dengan baik untuk pola deployment yang dibahas dalam dokumen ini. Bergantung pada kasus penggunaan, Anda mungkin hanya dapat menerapkan satu pola deployment atau kombinasi pola deployment hanya dengan subset sistem database.

Pada bagian berikut ini, sistem database yang berbeda dikategorikan dan dipetakan ke empat pola deployment.

Anda dapat mengategorikan database menurut berbagai dimensi, seperti model data, arsitektur internal, model deployment, dan jenis transaksi. Pada bagian berikut ini, untuk tujuan pengelolaan database multi-cloud, dua dimensi yang digunakan yaitu:

• Arsitektur deployment. Arsitektur terkait cara sistem pengelolaan database di-deploy ke resource cloud (misalnya, compute engine atau dikelola cloud).
• Model distribusi. Model distribusi yang didukung sistem database (seperti, instance tunggal atau terdistribusi sepenuhnya).

Kedua dimensi ini merupakan dimensi paling relevan dalam konteks kasus penggunaan multicloud dan dapat mendukung empat pola deployment yang berasal dari kasus penggunaan database multicloud. Kategorisasi populer didasarkan pada model data yang didukung oleh sistem manajemen database. Beberapa sistem hanya mendukung satu model (misalnya, model grafik). Sedangkan sistem lain mendukung beberapa model data secara bersamaan (misalnya, model relasional dan dokumen). Namun, dalam konteks pengelolaan database multi-cloud, kategorisasi ini tidak relevan karena aplikasi multi-cloud dapat menggunakan model data apa pun untuk deployment multi-cloudnya.

Sistem database berdasarkan arsitektur deployment

Pengelolaan database multi-cloud mencakup empat kelas utama arsitektur deployment untuk sistem pengelolaan database berikut:

• Database cloud bawaan. Database cloud bawaan dirancang, dibangun, dan dioptimalkan agar dapat digunakan dengan teknologi cloud. Misalnya, beberapa sistem database menggunakan Kubernetes sebagai platform implementasinya dan menggunakan fungsionalitas Kubernetes. CockroachDB dan YugaByte adalah contoh dari jenis database ini. Mereka dapat di-deploy ke cloud mana pun yang mendukung Kubernetes.
• Database yang dikelola penyedia cloud. Database yang dikelola penyedia cloud dibangun pada teknologi khusus penyedia cloud dan merupakan layanan database yang dikelola oleh penyedia cloud tertentu. Spanner, Bigtable dan AlloyDB untuk PostgreSQL adalah contoh dari jenis database ini. Database yang dikelola penyedia cloud hanya tersedia di cloud penyedia cloud dan tidak dapat diinstal maupun dijalankan di tempat lain. Namun, AlloyDB untuk PostgreSQL sepenuhnya kompatibel dengan PostgreSQL.
• Database pra-cloud. Database pra-cloud sudah ada sebelum teknologi cloud dikembangkan (terkadang untuk waktu yang lama) dan biasanya dijalankan pada hardware dan virtual machine (VM) bare metal. PostgreSQL, MySQL, dan SQL Server adalah contoh dari jenis database ini. Sistem ini dapat berjalan di cloud apa pun yang mendukung VM atau hardware bare metal yang diperlukan.
• Database yang dikelola partner cloud. Beberapa cloud publik memiliki partner database yang menginstal dan mengelola database pelanggan di cloud publik. Dengan adanya alasan ini, pelanggan tidak perlu mengelola database tersebut sendiri. MongoDB Atlas dan MariaDB adalah contoh dari jenis database ini.

Ada beberapa varian dari kategori utama ini. Misalnya, vendor database yang mengimplementasikan database yang di-build untuk cloud mungkin juga menyediakan penginstalan pada teknologi yang dibuat untuk cloud dan penawaran terkelola kepada pelanggan di cloud yang disediakan vendor mereka. Pendekatan ini setara dengan vendor yang menyediakan cloud publik yang hanya mendukung database mereka sebagai layanan tunggal.

Database pra-cloud juga dapat berada dalam container dan dapat di-deploy ke dalam cluster Kubernetes. Namun, database ini tidak menggunakan fungsionalitas khusus Kubernetes seperti penskalaan, multi-layanan, atau deployment multi-pod.

Vendor database dapat bermitra dengan lebih dari satu penyedia cloud publik secara bersamaan, sehingga menawarkan database mereka sebagai database yang dikelola partner cloud di lebih dari satu cloud publik.

Sistem database menurut model distribusi

Sistem pengelolaan database yang berbeda diimplementasikan sesuai dengan model distribusi dalam arsitektur database. Berikut ini adalah model untuk database:

• Instance tunggal. Instance database tunggal berjalan pada satu VM atau satu container dan berfungsi sebagai sistem terpusat. Sistem ini mengelola semua akses database. Karena instance tunggal tidak dapat terhubung ke instance lainnya, sistem database tidak mendukung replikasi.
• Multi-instance aktif-pasif. Dalam arsitektur umum ini, beberapa instance database saling ditautkan. Penautan yang paling umum adalah hubungan pasif aktif dimana satu instance merupakan instance database aktif yang mendukung baik instance maupun penulisan dan pembacaan. Satu atau beberapa sistem pasif bersifat hanya baca, dan menerima semua perubahan database dari sistem utama baik secara sinkron maupun asinkron. Sistem pasif dapat memberikan akses baca. Aktif-pasif juga disebut sebagai sekunder primer atau replika sumber.
• Multi-instance aktif-aktif. Dalam arsitektur yang relatif tidak umum ini, setiap instance adalah instance yang aktif. Dalam hal ini, setiap instance dapat mengeksekusi transaksi baca dan tulis, serta memberikan konsistensi data. Oleh karena itu, untuk mencegah inkonsistensi data, semua instance selalu disinkronkan.
• Multi-instance aktif-aktif dengan resolusi konflik. Ini juga termasuk dalam sistem yang relatif tidak umum. Setiap instance tersedia untuk akses tulis dan baca, tetapi database disinkronkan dalam mode asinkron. Pembaruan serentak pada item data yang sama diizinkan, sehingga menyebabkan status tidak konsisten. Kebijakan penyelesaian konflik harus menentukan negara bagian mana yang merupakan status konsisten terakhir.
• Sharding multi-instance. Sharding didasarkan pada pengelolaan partisi data (yang terpisah). Instance database terpisah mengelola setiap partisi. Distribusi ini bersifat skalabel karena lebih banyak shard yang dapat ditambahkan secara dinamis dari waktu ke waktu. Namun, kueri lintas sharding bisa saja tidak memungkinkan karena fungsi ini tidak didukung oleh semua sistem.

Semua model distribusi yang dibahas di bagian ini dapat mendukung sharding dan dapat menjadi sistem yang di-sharding. Namun, tidak semua sistem dirancang untuk menyediakan opsi sharding. Sharding adalah konsep skalabilitas dan umumnya tidak relevan dengan pemilihan database arsitektur di lingkungan multi-cloud.

Model distribusi untuk database yang dikelola partner dan cloud berbeda. Karena database ini terikat dengan arsitektur penyedia cloud, sistem ini mengimplementasikan arsitektur berdasarkan lokasi deployment berikut:

• Sistem zona. Sistem database terkelola menurut zona terikat dengan zona. Jika zona tersedia, sistem database juga akan tersedia. Namun, jika zona menjadi tidak tersedia, database tersebut tidak dapat diakses.
• Sistem regional. Database yang dikelola regional terikat dengan region dan dapat diakses jika setidaknya satu zona dapat diakses. Kombinasi zona apa pun tidak akan dapat diakses.
• Sistem lintas region. Sistem lintas-regional dikaitkan dengan dua atau beberapa region dan berfungsi dengan baik jika setidaknya satu region tersedia.

Sistem lintas regional juga dapat mendukung sistem lintas-cloud jika database dapat diinstal di semua cloud yang ingin digunakan oleh perusahaan.

Terdapat alternatif lain untuk arsitektur database terkelola yang dibahas di bagian ini. Sistem regional dapat berbagi disk di antara dua zona. Jika salah satu dari dua zona tersebut tidak dapat diakses, sistem database dapat terus berada di zona yang tersisa. Namun, jika pemadaman layanan memengaruhi kedua zona, sistem database tidak akan tersedia meskipun zona lain mungkin masih sepenuhnya online.

Memetakan sistem database ke pola deployment

Tabel berikut menjelaskan hubungan antara pola deployment dan arsitektur deployment yang dibahas dalam dokumen satu dengan lainnya. Kolom menyatakan kondisi yang diperlukan agar kombinasi dapat terwujud, berdasarkan pola deployment dan arsitektur deployment.

Arsitektur deployment	Pola deployment
	Dipartisi tanpa dependensi lintas-database	Replikasi searah asinkron	Replikasi dua arah dengan resolusi konflik	Sistem terdistribusi yang disinkronkan secara aktif-aktif
Database cloud bawaan	Memungkinkan untuk semua cloud yang menyediakan teknologi cloud bawaan yang digunakan oleh sistem database. Jika database yang sama tidak tersedia, sistem database yang berbeda dapat digunakan.	Database cloud yang menyediakan replikasi.	Database cloud yang menyediakan replikasi dua arah.	Database cloud yang menyediakan sinkronisasi utama-utama.
Database yang dikelola penyedia cloud	Sistem database mungkin berbeda di cloud yang berbeda.	Replika tidak harus berupa database yang dikelola penyedia cloud (lihat Peran teknologi migrasi database dalam pola deployment).	Hanya dalam cloud, bukan di seluruh cloud, jika database menyediakan replikasi dua arah.	Hanya dalam satu cloud, bukan di seluruh cloud, jika database menyediakan sinkronisasi primer-utama.
Database pra-cloud	Sistem database bisa saja sama atau berbeda di cloud yang berbeda.	Replikasi dapat dilakukan di beberapa cloud.	Sistem database menyediakan replikasi dua arah dan resolusi konflik.	Sistem database menyediakan sinkronisasi utama-utama.
Database yang dikelola partner cloud	Sistem database mungkin berbeda di cloud yang berbeda. Jika partner menyediakan sistem database terkelola di semua cloud yang diperlukan, database yang sama dapat digunakan.	Replika tidak harus berupa database yang dikelola penyedia cloud. Jika partner menyediakan sistem database terkelola di semua cloud yang diperlukan, database yang sama dapat digunakan.	Sistem database menyediakan replikasi dua arah dan resolusi konflik.	Sistem database menyediakan sinkronisasi utama-utama.

Jika sistem database tidak menyediakan replikasi bawaan, teknologi replikasi database mungkin dapat digunakan. Untuk informasi selengkapnya, lihat Peran teknologi migrasi database dalam pola deployment.

Tabel berikut menghubungkan pola deployment dengan model distribusi. Kolom tersebut menyatakan kondisi yang memungkinkan kombinasi tersebut diberikan pola deployment dan model distribusi.

Model distribusi	Pola deployment
	Dipartisi tanpa dependensi lintas-database	Replikasi searah asinkron	Replikasi dua arah dengan resolusi konflik	Sistem terdistribusi yang disinkronkan secara aktif-aktif
Instance tunggal	Dapat dilakukan dengan sistem database yang sama atau berbeda di cloud yang terlibat.	Tidak berlaku	Tidak berlaku	Tidak berlaku
Multi-instance aktif-pasif	Memungkinkan dengan sistem database yang sama atau berbeda di cloud yang terlibat.	Replikasi dapat terjadi di seluruh cloud.	Replikasi dapat terjadi di seluruh cloud.	Tidak berlaku
Multi-instance aktif-aktif	Memungkinkan dengan sistem database yang sama atau berbeda di cloud yang terlibat.	Tidak berlaku	Tidak berlaku	Sinkronisasi dapat dilakukan di seluruh cloud.
Multi-instance aktif-aktif dengan resolusi konflik	Memungkinkan dengan sistem database yang sama atau berbeda di cloud yang terlibat.	Tidak berlaku	Tidak berlaku	Berlaku jika replikasi dua arah memungkinkan di seluruh cloud.

Beberapa implementasi model distribusi yang menambahkan abstraksi tambahan berdasarkan teknologi database yang mendasarinya tidak memiliki model distribusi yang terintegrasi di dalamnya, misalnya sistem aktif-aktif, Postgres-BDR. Sistem tersebut disertakan dalam tabel sebelumnya di kategori masing-masing. Dari perspektif multi-cloud, cara penerapan model distribusi tidak relevan.

Migrasi dan replikasi database

Bergantung pada kasus penggunaan, perusahaan mungkin perlu memigrasikan database dari satu lokasi deployment ke lokasi deployment lainnya. Selain itu, untuk pemrosesan downstream, Anda mungkin perlu mereplikasi data untuk database ke lokasi lain. Di bagian berikut, migrasi database dan replikasi database dibahas dengan lebih mendetail.

Migrasi database

Migrasi database digunakan ketika database dipindahkan dari satu lokasi deployment ke lokasi lainnya. Misalnya, database yang berjalan di pusat data lokal dimigrasikan untuk berjalan di cloud. Setelah migrasi selesai, database akan dihentikan di pusat data lokal.

Pendekatan utama untuk migrasi database adalah sebagai berikut:

• Lift-and-shift. VM dan disk yang menjalankan instance database akan disalin ke lingkungan target apa adanya. Setelah disalin, file tersebut akan dimulai dan migrasi selesai.
• Ekspor dan impor serta pencadangan dan pemulihan. Pendekatan ini menggunakan fungsionalitas sistem database untuk mengeksternalkan database dan membuatnya kembali di lokasi target. Ekspor/impor biasanya didasarkan pada format ASCII, sedangkan pencadangan dan pemulihan didasarkan pada format biner.
• Migrasi tanpa periode nonaktif. Dalam pendekatan ini, database dimigrasikan saat sistem aplikasi mengakses sistem sumber. Setelah pemuatan awal, perubahan akan ditransmisikan dari sumber ke database target menggunakan teknologi change data capture (CDC). Aplikasi akan mengalami periode nonaktif sejak dihentikan di sistem database sumber, hingga aplikasi dimulai ulang pada sistem database target setelah migrasi selesai.

Migrasi database menjadi relevan dalam kasus penggunaan multicloud saat database dipindahkan dari satu cloud ke cloud lainnya, atau dari satu jenis mesin database ke mesin database lainnya.

Migrasi database adalah proses multifaset. Untuk mengetahui informasi selengkapnya, lihat Migrasi database: Konsep dan prinsip (Bagian 1) dan Migrasi database: Konsep dan prinsip (Bagian 2).

Teknologi database bawaan dapat digunakan untuk melakukan migrasi database—misalnya, ekspor dan impor, pencadangan dan pemulihan, atau protokol replikasi bawaan. Jika sistem sumber dan target adalah sistem database yang berbeda, teknologi migrasi adalah opsi terbaik untuk migrasi database. Database Migration Service, Striim dan Debezium adalah contoh teknologi migrasi database.

Replikasi database

Replikasi database mirip dengan migrasi database. Namun, selama replikasi database, sistem database sumber tetap berada di tempatnya selagi setiap perubahan ditransmisikan ke database target.

Replikasi database adalah proses berkelanjutan yang mengirimkan perubahan dari database sumber ke database target. Ketika proses ini bersifat asinkron, perubahan akan tiba di database target setelah penundaan singkat. Jika proses ini sinkron, perubahan pada sistem sumber akan dilakukan pada sistem target pada saat yang sama dan transaksi yang sama.

Selain mereplikasi sumber ke database target, praktik yang umum adalah mereplikasi data dari database sumber ke sistem analisis target.

Seperti halnya migrasi database, jika protokol replikasi tersedia, teknologi database bawaan dapat digunakan untuk replikasi database. Jika tidak ada protokol replikasi bawaan, Anda dapat menggunakan teknologi replikasi seperti Striim atau Debezium.

Peran teknologi migrasi database dalam pola deployment

Teknologi database bawaan untuk mengaktifkan replikasi umumnya tidak tersedia saat sistem database yang berbeda digunakan dalam pola deployment, misalnya replikasi asinkron (heterogen). Sebagai gantinya, teknologi migrasi database dapat di-deploy untuk memungkinkan replikasi semacam ini. Beberapa sistem migrasi ini juga menerapkan replikasi dua arah.

Jika teknologi replikasi atau migrasi database tersedia untuk sistem database yang digunakan dalam kombinasi yang ditandai sebagai "Tidak berlaku" dalam Tabel 1 atau Tabel 2 dalam artikel Memetakan sistem database ke pola deployment, maka kemungkinan Anda dapat menggunakannya untuk replikasi database. Diagram berikut menunjukkan pendekatan untuk replikasi database menggunakan teknologi migrasi.

Pada diagram sebelumnya, database di lokasi 1 direplikasi ke database di lokasi 2. Sebagai ganti replikasi sistem database langsung, server migrasi di-deploy untuk mengimplementasikan replikasi. Pendekatan ini digunakan untuk sistem database yang tidak memiliki fungsi replikasi database yang terintegrasi ke dalam implementasinya dan perlu mengandalkan sistem yang terpisah dari sistem database untuk mengimplementasikan replikasi.

Pemilihan database multicloud

Kasus penggunaan database multicloud yang digabungkan dengan kategorisasi sistem database membantu Anda memutuskan database mana yang tepat untuk kasus penggunaan tertentu. Misalnya, untuk menerapkan kasus penggunaan di Portabilitas aplikasi, ada dua opsi. Opsi pertama adalah memastikan bahwa mesin database yang sama tersedia di semua cloud. Pendekatan ini mengaktifkan portabilitas sistem. Opsi kedua adalah memastikan model data dan antarmuka kueri yang sama tersedia untuk semua cloud. Meskipun sistem database mungkin berbeda, portabilitas disediakan pada antarmuka fungsional.

Pohon keputusan di bagian berikut menunjukkan kriteria pengambilan keputusan untuk kasus penggunaan database multi-cloud dalam dokumen ini. Pohon keputusan menyarankan database terbaik untuk dipertimbangkan pada setiap kasus penggunaan.

Praktik terbaik untuk sistem database yang ada

Jika sistem database sedang dalam tahap produksi, keputusan harus diambil untuk menentukan apakah sistem database akan dipertahankan atau diganti. Diagram berikut menunjukkan pertanyaan yang perlu diajukan dalam proses keputusan Anda:

Pertanyaan dan jawaban dalam pohon keputusan adalah sebagai berikut:

• Apakah sistem database sedang dalam produksi?
  • Jika tidak ada sistem database yang sedang dalam tahap produksi, pilih sistem database (langsung pada bagian Keputusan tentang pengelolaan database multi-cloud).
  • Jika sistem database sedang dalam tahap produksi, evaluasi apakah sistem tersebut harus dipertahankan.
• Jika sistem database sedang dalam tahap produksi, evaluasi apakah sistem tersebut harus dipertahankan.
  • Jika sistem database harus dipertahankan, keputusan harus dibuat dan proses keputusan sudah selesai.
  • Jika sistem database harus diubah atau jika keputusan masih diambil, pilih sistem database (langsung ke bagian Keputusan tentang pengelolaan database multi-cloud).

Keputusan tentang pengelolaan database multi-cloud

Pohon keputusan berikut ditujukan untuk kasus penggunaan dengan persyaratan database multi-lokasi (termasuk deployment database multi-cloud). Solusi ini menggunakan pola deployment sebagai dasar untuk kriteria pengambilan keputusan.

Pertanyaan dan jawaban dalam pohon keputusan adalah sebagai berikut:

• Apakah data dipartisi dalam database berbeda tanpa dependensi lintas-database?
  • Jika iya, sistem database yang sama atau berbeda dapat dipilih untuk setiap lokasi.
  • Jika tidak, lanjutkan ke pertanyaan berikutnya.
• Apakah replikasi searah asinkron diperlukan?
  • Jika iya, maka evaluasi apakah sistem replikasi database dapat diterima.
    • Jika iya, pilih sistem database yang sama atau berbeda yang kompatibel dengan sistem replikasi.
    • Jika tidak, pilih sistem database yang dapat mengimplementasikan model distribusi pasif aktif.
    • Jika tidak, lanjutkan ke pertanyaan berikutnya.
• Pilih sistem database dengan instance yang disinkronkan.
  • Apakah resolusi konflik dapat diterima?
    • Jika iya, pilih sistem database replikasi dua arah atau sistem database aktif-aktif.
    • Jika tidak, pilih sistem aktif-aktif.

Jika lebih dari satu kasus penggunaan multicloud yang diimplementasikan, perusahaan harus memutuskan apakah akan menggunakan satu sistem database untuk mendukung semua kasus penggunaan, atau beberapa sistem database.

Jika perusahaan ingin menggunakan satu sistem database untuk mendukung semua kasus penggunaan, sistem dengan sinkronisasi terbaik adalah pilihan yang tepat. Misalnya, jika replikasi searah diperlukan serta instance yang disinkronkan, maka pilihan terbaik adalah instance yang disinkronkan.

Hierarki kualitas sinkronisasi (dari yang terbawah hingga yang terbaik) adalah sebagai berikut: terpartisi, replikasi searah, replikasi dua arah, dan replikasi yang disinkronkan sepenuhnya.

Praktik terbaik terkait deployment

Bagian ini menyoroti praktik terbaik yang harus diikuti ketika memilih database untuk migrasi atau pengembangan aplikasi multi-cloud.

Sistem pengelolaan database yang ada

Ada baiknya Anda mempertahankan database dan tidak melakukan perubahan pada sistem database, kecuali jika diperlukan oleh kasus penggunaan tertentu. Untuk perusahaan yang telah menerapkan sistem pengelolaan database yang telah stabil dan memiliki proses pengembangan, operasional, dan pemeliharaan yang efektif, sebaiknya hindari membuat perubahan.

Kasus penggunaan bursting cloud yang tidak memerlukan sistem database di cloud mungkin tidak memerlukan perubahan database. Kasus penggunaan lainnya adalah replikasi asinkron ke lokasi deployment yang berbeda dalam cloud yang sama atau ke cloud lainnya. Untuk kasus penggunaan ini, pendekatan yang tepat adalah menerapkan tolok ukur dan memverifikasi bahwa komunikasi lintas lokasi serta komunikasi lintas lokasi dan latensi memenuhi persyaratan aplikasi saat mengakses database.

Sistem database sebagai layanan Kubernetes

Jika sebuah perusahaan mempertimbangkan untuk menjalankan sistem database dalam Kubernetes sebagai layanan berdasarkan StatefulSets, maka faktor-faktor berikut harus dipertimbangkan:

• Apakah database menyediakan model database yang dibutuhkan oleh aplikasi.
• Faktor non-fungsional yang menentukan cara operasionalisasi diimplementasikan dalam sistem database sebagai layanan Kubernetes, misalnya cara penskalaan dilakukan (penskalaan naik dan turun), cara pengelolaan pencadangan dan pemulihan, dan bagaimana pemantauan disediakan oleh sistem. Untuk membantu mereka memahami persyaratan sistem database berbasis Kubernetes, perusahaan harus menggunakan pengalaman mereka dengan database sebagai titik perbandingan.
• Ketersediaan tinggi dan pemulihan dari bencana (disaster recovery). Untuk memberikan ketersediaan tinggi, sistem harus terus beroperasi saat zona dalam suatu region gagal. Database harus dapat melakukan failover dengan cepat dari satu zona ke zona lainnya. Dalam skenario kasus terbaik, database memiliki instance yang berjalan di setiap zona yang sepenuhnya disinkronkan untuk RTO dan RPO nol.
• Pemulihan dari bencana (disaster recovery) untuk mengatasi kegagalan suatu wilayah (atau cloud). Dalam skenario ideal, database terus beroperasi di region kedua dengan RPO dan RTO nol. Dalam skenario yang kurang ideal, database di region sekunder mungkin tidak sepenuhnya tercakup dalam semua transaksi dari database utama.

Untuk menentukan cara terbaik menjalankan database dalam Kubernetes, evaluasi database secara lengkap adalah pendekatan yang tepat, terutama jika sistem harus sebanding dengan sistem produksi di luar Kubernetes.

Sistem database yang tidak bergantung pada Kubernetes

Aplikasi yang diimplementasikan sebagai layanan di Kubernetes tidak selalu diperlukan untuk menjalankan database di Kubernetes secara bersamaan. Ada banyak alasan mengapa sistem database perlu dijalankan di luar Kubernetes, misalnya, proses yang telah ditetapkan, pengetahuan produk dalam perusahaan, atau ketidaktersediaan. Baik penyedia cloud maupun database yang dikelola partner cloud sesuai dengan kategori ini.

Menjalankan database di Compute Engine merupakan hal yang mungkin dan bisa dilakukan. Saat memilih sistem database, sebaiknya lakukan evaluasi database secara lengkap untuk memastikan bahwa semua persyaratan untuk aplikasi terpenuhi.

Dari perspektif desain aplikasi, penggabungan koneksi adalah pertimbangan desain yang penting. Layanan aplikasi yang mengakses database mungkin menggunakan kumpulan koneksi secara internal. Menggunakan gabungan koneksi baik untuk efisiensi dan mengurangi latensi. Permintaan diambil dari kumpulan, tanpa harus dimulai, dan tidak perlu menunggu koneksi dibuat. Jika skala aplikasi ditingkatkan dengan menambahkan instance layanan aplikasi, setiap instance akan membentuk kumpulan koneksi. Jika praktik terbaik diikuti, setiap kumpulan akan membuat sekumpulan koneksi minimum. Setiap kali instance layanan aplikasi lain dibuat untuk penskalaan aplikasi, koneksi ditambahkan ke database. Dari perspektif desain, karena database tidak dapat mendukung koneksi tanpa batas, penambahan koneksi harus dikelola untuk menghindari kelebihan beban.

Sistem database terbaik versus portabilitas sistem database

Saat memilih sistem database, biasanya perusahaan memilih sistem database terbaik untuk memenuhi persyaratan aplikasi. Dalam lingkungan multi-cloud, database terbaik di setiap cloud dapat dipilih, dan dapat dihubungkan satu sama lain berdasarkan kasus penggunaan. Jika sistem ini berbeda, setiap replikasi satu arah atau dua arah memerlukan upaya yang signifikan. Pendekatan ini mungkin dibenarkan jika manfaat dari penggunaan sistem terbaik lebih besar daripada upaya yang diperlukan untuk menerapkannya.

Namun, praktik yang baik adalah dengan mempertimbangkan dan mengevaluasi secara serentak pendekatan untuk sistem database yang tersedia di semua cloud yang diperlukan. Meskipun database seperti itu mungkin tidak seefisien pilihan terbaik, akan jauh lebih mudah untuk mengimplementasikan, mengoperasikan, dan memelihara sistem tersebut.

Evaluasi sistem database serentak menunjukkan kelebihan dan kekurangan kedua sistem database tersebut, sehingga memberikan dasar yang kuat untuk pemilihan.

Replikasi sistem database bawaan versus eksternal

Untuk kasus penggunaan yang memerlukan sistem database di semua lokasi deployment (zona, region, atau cloud), replikasi merupakan fitur yang penting. Replikasi dapat berupa replikasi aktif-aktif asinkron, dua arah, atau disinkronkan sepenuhnya. Tidak semua sistem database mendukung semua bentuk replikasi ini.

Untuk sistem yang tidak mendukung replikasi sebagai bagian dari replikasi implementasi sistemnya, sistem seperti Striim dapat digunakan untuk melengkapi arsitektur (seperti yang telah dibahas dalam Migrasi database).

Praktik terbaiknya adalah dengan mengevaluasi sistem pengelolaan database alternatif untuk mengetahui kelebihan dan kekurangan dari sistem yang memiliki replikasi bawaan atau sistem yang memerlukan teknologi replikasi.

Teknologi kelas ketiga juga berperan dalam kasus ini. Kelas ini menyediakan add-on ke sistem database yang ada untuk menyediakan replikasi. Salah satu contohnya adalah MariaDB Galera Cluster. Jika proses evaluasi mengizinkan, mengevaluasi sistem ini adalah praktik yang baik.

Langkah selanjutnya

• Pelajari pola dan praktik hybrid dan multicloud.
• Baca tentang pola untuk menghubungkan penyedia layanan cloud lain dengan Google Cloud.
• Pelajari arsitektur pemantauan dan logging untuk deployment hybrid dan multicloud di Google Cloud.
• Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.

Kontributor

Penulis: Alex Cârciu | Solutions Architect