EIKON Technology

logo Eikon
Menu

Cloud Spanner

Google Cloud

Menyederhanakan Disaster Recovery dengan Cloud Spanner

Disaster recovery sama pentingnya dengan perlindungan data bagi aplikasi penting perusahaan. Perencanaannya harus mampu melindungi aplikasi (dan data di dalamnya) dari bencana alam serta insiden yang disebabkan oleh manusia, seperti pengiriman bug yang bisa menyebabkan timbulnya bad data. Bagaimana perencanaan disaster recovery yang ideal untuk mengatasi insiden? RPO dan RTO Photo Credit: Google Cloud Blog Sebagai bagian dari rencana, pemilik aplikasi harus mempertimbangkan kedua RPO (Recovery Point Objective), yang berkaitan dengan usia data siap dipulihkan serta RTO (Recovery Time Objective), yang berhubungan dengan total waktu yang disiapkan untuk mengembalikan aplikasi setelah insiden. Baca juga: Model Deployment Google Cloud untuk Cloud Spanner Emulator Cloud Spanner CPU sebagai strategi disaster recovery Cloud Spanner merupakan database relasional yang terkelola sepenuhnya dengan skala tak terbatas, konsistensi kuat, dan ketersediaan hingga 99,999%. Layanan ini menyediakan replikasi yang transparan dan sinkron di seluruh zona dengan konfigurasi regional. Juga, konfigurasi multi-region di seluruh region. Secara inheren, arsitektur Cloud Spanner mengatasi beberapa penyebab insiden yang harus diatasi oleh solusi disaster recovery konvensional. Terlepas dari ketersediaan tinggi yang ditawarkan Cloud Spanner, pemilik aplikasi tetap membutuhkan perlindungan data. Sebab, masih ada kemungkinan kesalahan pengguna atau bug aplikasi yang dapat menyebabkan salah simpan nilai ke dalam database. Sebagai solusi, Cloud Spanner menawarkan backup/restore dan point-in-time recovery. Optimalisasi backup Cloud Spanner Pencadangan Cloud Spanner konsisten secara transaksional. Itu berarti, saat pencadangan dibuat, pencadangan menangkap konten database yang tepat (seperti timestamp pencadangan atau timestamp komit transaksi granularity mikrodetik). Arsitektur ini memastikan bahwa semua data terkait transaksi yang dilakukan disertakan dalam pencadangan. Namun semua pembaruan sebagian yang masih terkait dengan transaksi tidak terikat dikecualikan. Pemulihan point-in-time memungkinkan pemulihan dari timestamp yang dipilih pengguna (dengan semantik yang sama sebagai cadangan). Photo Credit: Google Cloud Blog Katakanlah Anda punya database 10 TB yang mendukung suatu aplikasi penting perusahaan. Maka Anda bisa secara teratur mengambil cadangan sebagai bagian dari rencana disaster recovery. Di banyak sistem, mencadangkan database besar bisa makan waktu berjam-jam dan dapat meningkatkan beban CPU sehingga berdampak buruk. Photo Credit: Google Cloud Blog Cloud Spanner telah memecahkan masalah ini dengan CPU Optimized Backups. Dengan fitur ini, Cloud Spanner memisahkan sumber daya CPU yang digunakan untuk instances database pelanggan dari sumber daya CPU yang digunakan untuk pembuatan cadangan. Keuntungan menggunakan Cloud Spanner CPU sebagai solusi disaster recovery Pelanggan tak perlu lagi menyediakan kapasitas komputasi tambahan. Jadi, ruang kepala CPU bisa digunakan untuk pencadangan. Beban CPU pada instances pelanggan karena pencadangan berkurang hampir nol. Artinya, tidak ada dampak buruk terhadap beban kerja produksi saat pencadangan. Pekerjaan batch yang membuat cadangan dapat diskalakan secara independen dari jumlah server di instances pelanggan. Sistem file yang mendasarinya sangat terdistribusi dan memungkinkan bandwidth baca yang pada dasarnya tidak terbatas. Dengan CPU Optimized Backups, ukuran pekerjaan pencadangan dipisahkan menurut ukuran instances pelanggan, sehingga memungkinkan pencadangan untuk database besar mencapai ukuran yang sangat besar (berpotensi, ribuan mesin). Hal lain yang perlu diperhatikan Photo Credit: Freepik Kinerja backup bergantung pada berbagai faktor, termasuk beberapa faktor khusus seperti detail skema. Oleh karenanya, tidak ada estimasi performa yang sangat spesifik. Meskipun begitu, diketahui bahwa sebagian besar pencadangan database biasanya selesai dalam waktu satu hingga dua jam (termasuk database berukuran ratusan TB). CPU Optimized Backups melanjutkan tradisi inovasi teknis dalam perlindungan data Cloud Spanner dan pemulihan bencana. Fungsionalitas pemulihan yang ada memanfaatkan pencadangan per zona untuk mengaktifkan pemulihan cepat tanpa penyalinan data lintas zona. Point-in-time memungkinkan pemulihan yang fleksibel. Meski begitu, tidak ada perubahan harga pencadangan dengan CPU Optimized Backups. Baca juga: Membongkar Mitos Seputar Cloud Spanner Cloud Spanner merupakan database NewSQL yang menggabungkan skalabilitas dan ketersediaan tinggi NoSQL dengan model relasional, dukungan transaksional, dan SQL RDBMS. Arsitektur ini tersedia di Google Cloud Platform sejak tahun 2017 lalu. Dengan menggunakan Google Cloud Platform, Anda pun bisa menikmati seluruh kemudahan Cloud Spanner dalam menyederhanakan disaster recovery plan. Lindungi keamanan data perusahaan Anda dari berbagai potensi risiko dengan Google Cloud. Dapatkan Google Cloud hanya di EIKON Technology, reseller resmi produk-produk Google untuk Indonesia. Untuk informasi selengkapnya, silakan klik di sini!

Google Cloud

Membongkar Mitos Seputar Cloud Spanner

Cloud Spanner merupakan sebuah database untuk level perusahaan yang menawarkan skalabilitas tak terbatas dengan tingkat ketersediaan hingga mencapai 99,999%. Database ini juga tidak memerlukan jendela pemeliharaan dan menerapkan antarmuka PostgreSQL yang familier. Secara garis besar, Cloud Spanner menggabungkan manfaat dari database relasional dengan skalabilitas yang tak tertandingi dan ketersediaan non-relasional. Dengan beragam kegunaan tersebut tidak mengherankan jika pengguna Cloud Spanner sering salah berasumsi. Artikel kali ini akan membahas beberapa “kesalahpahaman” umum terkait Cloud Spanner yang sering ditemukan. Mari simak bersama. Spanner hanya bisa digunakan untuk workload skala besar Cloud Spanner memang dikenal memiliki skalabilitas tak terbatas. Kapabilitas tersebut kemudian menimbulkan asumsi bahwa database tersebut hanya bisa digunakan untuk proyek dengan workload skala besar. Namun benarkah demikian? Ada banyak sekali perusahaan besar yang menggunakan Cloud Spanner. Salah satu contohnya, Uber. Dengan layanan yang begitu luas, jelas workload Uber pun besar sehingga tidak mengherankan jika menggunakan Spanner. Meski begitu, pada kenyataannya ada beberapa perusahaan dengan skala lebih kecil yang menggunakan Spanner seperti Google Password Manager. Tool tersebut memang tidak memiliki workload besar, namun tetap memerlukan Spanner karena para pengguna jelas tidak bisa menoleransi downtime saat mereka harus menggunakan password. Spanner terlalu mahal Photo Credit: Piqsels Saat Anda mempertimbangkan biaya database, perhatikanlah TCO (Total Cost of Ownership) dan nilai yang ditawarkannya alih-alih hanya melihat harga mentah. Spanner memberikan nilai yang signifikan kepada pelanggan dari perhitungan tersebut serta hal-hal penting lainnya seperti ketersediaan, performa harga, dan pengurangan biaya operasional. Dengan Spanner, Anda tidak perlu khawatir lagi dengan masalah keamanan, ketersediaan, dan keandalan data lagi. Terlebih kini sudah ada penawaran Granular Instance Sizing yang memungkinkan Anda untuk bisa memulai layanan hanya dengan US$65/bulan, Baca juga: Lebih Jauh Mengenai Autoscaling pada Bigtable dan Analisis Penghematan Biayanya Saat menggunakan Spanner Anda harus memilih antara skala, konsistensi, dan latensi Hal ini sebenarnya bergantung pada masing-masing kasus penggunaan dan konfigurasi instance. Jadi, pengguna bisa menggunakan Spanner tanpa harus memilih salah satu di antara skala,, konsistensi, dan latensi. Untuk memberikan konsistensi data yang kuat, Cloud Spanner menggunakan skema replikasi sinkron berbasis Paxos. Sedangkan agar latensi rendah, multi-wilayah Spanner dirancang dengan cermat dalam konfigurasi geografis yang memastikan bahwa replika dapat berkomunikasi dengan cukup cepat. Antarmuka Spanner sulit dipahami Spanner menawarkan fleksibilitas untuk berinteraksi dengan database melalui SQL berdasarkan standar ANSI 2011 serta melalui antarmuka REST atau gRPC API. Baru-baru ini, Cloud Spanner juga memperkenalkan antarmuka PostgreSQL. Antarmuka PostgreSQL menyediakan subset yang kaya dari dialek SQL PostgreSQL open-source, termasuk sintaks query umum, fungsi, dan operator. Ini mendukung kumpulan inti tipe data PostgreSQL open-source, sintaks DDL, dan tampilan skema informasi. Satu-satunya cara untuk mencapai observabilitas data adalah dengan Spanner Console Photo Credit: Piqsels Client library Spanner saat ini sudah mendukung Pelacakan dan Metrik dari OpenCensus. Kapabilitas ini memberikan wawasan mengenai kondisi internal klien dan membantu Anda untuk melakukan debug pada masalah produksi. Misalnya, pelacakan dan metrik dari sisi klien menyertakan informasi terkait sesi dan juga transaksi. Spanner juga mendukung penerima OpenTelemetery, yang menyediakan cara mudah bagi Anda untuk memproses dan memvisualisasikan metrik dari tabel Sistem Cloud Spanner dan mengekspornya ke APM (Application Monitoring) pilihan Anda. Hal tersebut juga mencakup kombinasi open-source dari database deret waktu seperti Prometheus yang digabungkan dengan dashboard Grafana. Bisa juga berupa penawaran komersial seperti Splunk, Dynatrace, AppDyamics, hingga NewRelic. ​​Baca juga: Register Domain Lebih Mudah dengan GA Cloud Domain Cloud Spanner merupakan sebuah database dengan skalabilitas raksasa yang dibangun dalam jaringan Google Cloud. Database ini menawarkan tingkat latensi rendah, keamanan tinggi, dan ketangguhan layanan untuk penggunanya yang tersebar di seluruh dunia. Sebelum menggunakan Cloud Spanner, ada baiknya Anda juga menerapkan komputasi awan Google Cloud untuk kinerja yang optimal. Ingin sistem penyimpanan data yang lebih baik lagi? Pilih paket solusi Cloud yang disesuaikan dengan kebutuhan perusahaan Anda. Dapatkan segera hanya di EIKON Technology, reseller resmi Google untuk Indonesia. Untuk konsultasi dengan tim EIKON Technology, silakan klik di sini!

Scroll to Top