Checklist peluncuran ini memberikan daftar pertimbangan yang perlu dilakukan sebelum meluncurkan aplikasi produksi di Spanner. Panduan ini tidak dimaksudkan untuk menjadi panduan yang lengkap, tetapi berfungsi untuk menyoroti pertimbangan utama untuk meminimalkan risiko, mengoptimalkan performa, dan memastikan keselarasan dengan tujuan bisnis dan operasional, sehingga menawarkan pendekatan sistematis untuk menghadirkan deployment Spanner yang lancar dan andal.
Checklist ini dibagi menjadi beberapa bagian berikut:
- Desain, pengembangan, pengujian, dan pengoptimalan
- Migrasi (opsional)
- Deployment
- Pengoptimal kueri dan pengelolaan statistik
- Pemulihan dari bencana
- Keamanan
- Logging dan pemantauan
- Library klien
- Dukungan
- Pengelolaan biaya
Desain, pengembangan, pengujian, dan pengoptimalan
Mengoptimalkan desain skema, transaksi, dan kueri sangat penting untuk menggunakan arsitektur terdistribusi Spanner demi performa dan skalabilitas tinggi. Pengujian menyeluruh dan skala produksi yang ketat memastikan sistem dapat menangani beban kerja dunia nyata, beban puncak, dan operasi serentak, sekaligus meminimalkan risiko hambatan atau kegagalan dalam produksi.
Kotak centang | Aktivitas |
---|---|
❑ |
Desain skema dengan mempertimbangkan skalabilitas dan arsitektur terdistribusi Spanner. Ikuti praktik terbaik seperti
memilih kunci utama dan indeks yang sesuai untuk menghindari hotspot dan
pertimbangkan pengoptimalan seperti penyisipan tabel untuk data terkait. Tinjau
Praktik terbaik desain skema
untuk memastikan skema mendukung performa dan skalabilitas tinggi
di bawah beban kerja yang diharapkan.
|
❑ |
Mengoptimalkan transaksi dan kueri untuk meminimalkan penguncian dan memaksimalkan
performa. Gunakan mode transaksi Spanner, seperti
baca-tulis dengan penguncian, hanya baca yang kuat, dan pernyataan
DML terpartisi, untuk menyeimbangkan konsistensi, throughput, dan latensi. Minimalkan
cakupan penguncian dengan menggunakan
transaksi hanya baca
untuk kueri, batching
untuk throughput DML maksimum atau
pernyataan DML berpartisi untuk
update dan penghapusan skala besar. Saat bermigrasi dari sistem dengan
tingkat isolasi yang berbeda (misalnya, PostgreSQL atau MySQL),
gunakan transaksi untuk menghindari hambatan performa. Untuk mengetahui informasi selengkapnya, lihat Transaksi.
|
❑ |
Lakukan pengujian beban yang ketat dalam skala besar untuk memvalidasi desain skema,
perilaku transaksi, dan performa kueri. Simulasikan skenario puncak dan
konkurensi tinggi yang meniru beban aplikasi dunia nyata,
termasuk berbagai bentuk transaksi dan pola kueri. Evaluasi
latensi dan throughput dalam kondisi ini untuk mengonfirmasi bahwa
desain database dan topologi instance memenuhi persyaratan performa.
Gunakan pengujian beban secara berulang selama pengembangan untuk mengoptimalkan dan
memperbaiki penerapan.
|
❑ |
Perluas pengujian beban untuk mencakup semua layanan yang berinteraksi, bukan hanya
aplikasi yang terisolasi. Simulasikan perjalanan pengguna yang komprehensif
bersama dengan proses paralel, seperti pemuatan batch atau tugas
administrasi yang mengakses database. Jalankan pengujian pada konfigurasi instance Spanner produksi, pastikan driver dan layanan pengujian beban selaras secara geografis dengan topologi deployment produksi yang dimaksud. Pendekatan holistik ini mengidentifikasi potensi konflik terlebih dahulu dan memastikan performa database yang lancar selama operasi di dunia nyata.
|
❑ |
Untuk memastikan performa kueri yang dapat diprediksi, gunakan versi pengoptimal yang telah diuji untuk beban kerja. Secara default,
database Spanner menggunakan versi pengoptimal kueri terbaru.
Evaluasi versi pengoptimal baru secara rutin
dalam lingkungan yang terkontrol, dan perbarui versi default hanya setelah
mengonfirmasi kompatibilitas dan peningkatan performa. Untuk mengetahui informasi selengkapnya, lihat
Ringkasan pengoptimal kueri.
|
❑ |
Pastikan statistik pengoptimal kueri
up-to-date untuk mendukung rencana eksekusi kueri yang efisien.
Meskipun statistik diperbarui secara otomatis, pertimbangkan untuk
membuat paket statistik baru secara manual
dalam skenario seperti modifikasi data skala besar (misalnya, penyisipan,
pembaruan, atau penghapusan massal), penambahan indeks baru, atau perubahan skema.
Memastikan statistik pengoptimal kueri tetap terbaru sangat penting untuk
mempertahankan performa kueri yang optimal.
|
Migrasi (opsional)
Migrasi database adalah proses komprehensif yang memerlukan analisis mendalam tentang spesifikasi setiap perjalanan migrasi. Pertimbangkan hal berikut dalam strategi migrasi Anda:
Kotak centang | Aktivitas |
---|---|
❑ |
Buat prosedur operasi standar (SOP) yang mendetail untuk
pengalihan migrasi. Hal ini mencakup langkah-langkah untuk peluncuran aplikasi,
pengalihan database, dan otomatisasi untuk meminimalkan intervensi manual.
Identifikasi dan komunikasikan potensi periode nonaktif kepada pemangku kepentingan jauh-jauh hari. Terapkan mekanisme pemantauan dan pemberitahuan yang andal untuk melacak
proses migrasi secara real-time dan mendeteksi anomali dengan cepat.
Pastikan proses pengalihan mencakup pemeriksaan validasi untuk mengonfirmasi integritas data dan kemampuan aplikasi setelah migrasi.
|
❑ |
Siapkan rencana penggantian yang mendetail untuk kembali ke sistem sumber jika terjadi masalah kritis selama migrasi. Uji prosedur
penggantian di lingkungan staging untuk memastikan keandalannya,
dan dapat dieksekusi dengan periode nonaktif minimal. Tentukan kondisi dengan jelas
yang akan memicu penggantian dan pastikan tim dilatih untuk menjalankan
rencana ini dengan cepat dan efisien.
|
Deployment
Perencanaan deployment yang tepat memastikan bahwa konfigurasi Spanner memenuhi persyaratan workload untuk ketersediaan, latensi, dan skalabilitas, sekaligus memperhitungkan pertimbangan geografis dan operasional. Menyelaraskan ukuran, pengelolaan resource, skenario failover, dan otomatisasi akan meminimalkan risiko, memastikan performa yang optimal, dan mencegah batasan resource atau gangguan selama operasi penting.
Kotak centang | Aktivitas |
---|---|
❑ |
Pastikan konfigurasi instance Spanner Anda
(baik regional, dual-region, atau multi-regional) sesuai dengan
persyaratan ketersediaan dan latensi workload aplikasi Anda, sekaligus
mempertimbangkan aspek geografis. Hitung kapasitas
komputasi target berdasarkan ukuran penyimpanan, pola traffic, dan
batas penggunaan yang direkomendasikan,
sambil memastikan kapasitas yang memadai untuk gangguan zona atau regional. Buat rencana untuk
lonjakan traffic dengan mengaktifkan penskalaan otomatis.
Anda dapat menetapkan batas atas untuk kapasitas komputasi guna menetapkan pengamanan biaya. Untuk mengetahui informasi selengkapnya, lihat
Kapasitas komputasi, node, dan unit pemrosesan.
|
❑ |
Jika Anda menggunakan konfigurasi instance multi-region atau dual-region,
pilih region utama yang meminimalkan latensi untuk penulisan aplikasi
dari layanan yang di-deploy di lokasi yang paling sensitif terhadap latensi.
Uji implikasi berbagai region pemimpin pada latensi operasi,
dan sesuaikan untuk mengoptimalkan performa aplikasi. Rencanakan skenario
failover dengan memastikan topologi aplikasi dapat beradaptasi dengan
perubahan wilayah pemimpin selama pemadaman regional. Untuk mengetahui informasi selengkapnya, lihat
Mengubah region paling dominan dalam database.
|
❑ |
Konfigurasi tag dan label dengan tepat untuk kejelasan operasional dan
pelacakan resource Google Cloud. Gunakan tag untuk mengelompokkan instance menurut
lingkungan atau jenis beban kerja. Gunakan label untuk metadata yang membantu analisis biaya dan pengelolaan izin. Untuk mengetahui informasi selengkapnya, lihat
Mengontrol akses dan mengatur instance dengan tag.
|
❑ |
Evaluasi apakah pemanasan Spanner diperlukan,
terutama untuk layanan yang mengharapkan traffic tinggi dan tiba-tiba saat peluncuran.
Pengujian latensi di bawah beban awal yang tinggi dapat mengungkapkan kebutuhan untuk pemanasan sebelum peluncuran guna memastikan performa yang optimal. Jika pemanasan
diperlukan, buat beban buatan. Untuk mengetahui informasi selengkapnya, lihat
Menyiapkan database sebelum peluncuran aplikasi.
|
❑ |
Tinjau batas dan kuota Spanner sebelum deployment.
Jika perlu, minta peningkatan kuota di konsol Google Cloud untuk menghindari batasan selama periode puncak. Perhatikan batas ketat (misalnya,
jumlah maksimum tabel per database) untuk mencegah masalah setelah deployment. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
|
❑ |
Gunakan alat otomatisasi seperti Terraform untuk menyediakan dan mengelola
instance Spanner Anda, sehingga memastikan konfigurasi efisien
dan bebas error. Untuk pengelolaan skema, pertimbangkan penggunaan alat seperti
Liquibase
untuk menghindari penghapusan skema yang tidak disengaja selama pembaruan. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Terraform dengan Spanner.
|
Pemulihan dari bencana
Menetapkan strategi pemulihan dari bencana (DR) yang andal sangat penting untuk melindungi data, meminimalkan periode nonaktif, dan memastikan kelangsungan bisnis selama terjadi kegagalan yang tidak terduga. Pengujian prosedur pemulihan secara rutin dan otomatisasi pencadangan membantu memastikan kesiapan operasional, kepatuhan terhadap tujuan pemulihan, dan perlindungan data yang andal yang disesuaikan dengan kebutuhan organisasi.
Kotak centang | Aktivitas |
---|---|
❑ |
Tentukan strategi pemulihan dari bencana yang komprehensif untuk
Spanner yang mencakup perlindungan data, tujuan
pemulihan, dan skenario kegagalan. Tetapkan batas waktu pemulihan (RTO) dan batas titik pemulihan (RPO) yang jelas dan selaras dengan persyaratan kelangsungan bisnis. Tentukan frekuensi pencadangan, kebijakan retensi, dan gunakan pemulihan point-in-time (PITR) untuk meminimalkan kehilangan data jika terjadi kegagalan. Tinjau
Ringkasan pemulihan dari bencana
untuk mengidentifikasi alat dan teknik yang tepat guna memastikan kepatuhan terhadap
ketersediaan, keandalan, dan keamanan untuk aplikasi Anda. Untuk mengetahui informasi selengkapnya, lihat laporan resmi Solusi perlindungan dan pemulihan data di Spanner.
|
❑ |
Buat dokumentasi mendetail untuk prosedur pencadangan dan pemulihan,
termasuk panduan langkah demi langkah untuk berbagai skenario pemulihan.
Uji prosedur ini secara rutin untuk memastikan kesiapan operasional dan memvalidasi persyaratan RTO dan RPO. Pengujian harus menyimulasikan kondisi dan skenario kegagalan di dunia nyata untuk mengidentifikasi kesenjangan dan meningkatkan proses pemulihan. Untuk mengetahui informasi selengkapnya, lihat Ringkasan pemulihan.
|
❑ |
Terapkan jadwal pencadangan otomatis untuk memastikan perlindungan data yang konsisten dan andal. Konfigurasi setelan frekuensi dan retensi agar sesuai dengan kebutuhan bisnis dan kewajiban peraturan. Gunakan
fitur penjadwalan pencadangan Spanner untuk mengotomatiskan
pembuatan, pengelolaan, dan pemantauan pencadangan. Untuk mengetahui informasi selengkapnya,
lihat Membuat dan mengelola jadwal pencadangan.
|
❑ |
Sesuaikan prosedur failover dengan
topologi konfigurasi instance
aplikasi Anda untuk meminimalkan dampak latensi jika terjadi gangguan. Uji skenario pemulihan dari bencana, pastikan aplikasi dapat beroperasi secara efisien saat region pemimpin dipindahkan ke region failover. Untuk mengetahui informasi selengkapnya, lihat Mengubah region paling dominan dalam database.
|
Pengoptimal kueri dan pengelolaan statistik
Mengelola versi dan statistik pengoptimal kueri penting untuk mempertahankan performa kueri yang dapat diprediksi dan efisien. Menggunakan versi yang telah diuji dan memperbarui statistik memastikan stabilitas, mencegah perubahan performa yang tidak terduga, dan mengoptimalkan rencana eksekusi kueri, terutama selama modifikasi data atau skema yang signifikan.
Kotak centang | Aktivitas |
---|---|
❑ |
Secara default, database Spanner menggunakan versi pengoptimal kueri terbaru. Untuk memastikan performa kueri yang dapat diprediksi, gunakan
versi pengoptimal yang telah diuji untuk beban kerja. Evaluasi versi pengoptimal baru secara rutin dalam lingkungan yang terkontrol, dan perbarui versi default hanya setelah mengonfirmasi kompatibilitas dan peningkatan performa. Untuk mengetahui informasi
selengkapnya, lihat
Ringkasan pengoptimal kueri.
|
❑ |
Pastikan statistik pengoptimal kueri
up-to-date untuk mendukung rencana eksekusi kueri yang efisien.
Meskipun statistik diperbarui secara otomatis, pertimbangkan untuk
membuat paket statistik baru secara manual
dalam skenario seperti modifikasi data skala besar (misalnya, penyisipan,
pembaruan, atau penghapusan massal), penambahan indeks baru, atau perubahan skema.
Memastikan statistik pengoptimal kueri tetap terbaru sangat penting untuk
mempertahankan performa kueri yang optimal.
|
❑ |
Dalam skenario tertentu, seperti setelah penghapusan massal atau saat pembuatan statistik baru dapat memengaruhi performa kueri secara tidak terduga, sebaiknya sematkan paket statistik tertentu. Hal ini memberikan
performa kueri yang konsisten hingga paket baru dapat dibuat dan
diuji. Tinjau secara rutin kebutuhan untuk menyematkan statistik dan hapus sematan setelah paket yang diperbarui divalidasi. Untuk mengetahui informasi selengkapnya, lihat
Paket statistik pengoptimal kueri.
|
Keamanan
Penerapan langkah-langkah kontrol akses sangat penting untuk melindungi data sensitif dan mencegah akses tidak sah di Spanner. Dengan menerapkan akses hak istimewa terendah, kontrol akses terperinci (FGAC), dan perlindungan penghapusan database, Anda dapat meminimalkan risiko, memastikan kepatuhan, dan mengamankan aset penting dari tindakan yang tidak disengaja atau berbahaya.
Kotak centang | Aktivitas |
---|---|
❑ |
Tinjau dan terapkan kebijakan Identity and Access Management (IAM)
dengan mengikuti prinsip hak istimewa terendah untuk semua pengguna dan akun
layanan yang mengakses database Anda. Tetapkan hanya izin
yang diperlukan untuk melakukan tugas tertentu dan audit izin kontrol akses secara rutin
untuk memastikan kepatuhan terhadap model ini. Gunakan
akun layanan dengan hak istimewa minimal untuk proses otomatis guna
mengurangi risiko akses yang tidak sah. Untuk mengetahui informasi selengkapnya, lihat
Ringkasan IAM.
|
❑ |
Jika aplikasi memerlukan akses terbatas ke baris, kolom, atau sel tertentu dalam tabel, terapkan kontrol akses terperinci (FGAC). Rancang dan terapkan kebijakan akses bersyarat berdasarkan atribut pengguna atau nilai data untuk menerapkan aturan akses terperinci. Tinjau dan perbarui kebijakan ini secara rutin agar selaras dengan persyaratan keamanan dan kepatuhan yang terus berkembang. Untuk mengetahui informasi selengkapnya, lihat
Ringkasan kontrol akses terperinci.
|
❑ |
Terapkan jadwal pencadangan otomatis untuk memastikan perlindungan data yang konsisten dan andal. Konfigurasi setelan frekuensi dan retensi agar sesuai dengan kebutuhan bisnis dan kewajiban peraturan. Gunakan
fitur penjadwalan pencadangan Spanner untuk mengotomatiskan
pembuatan, pengelolaan, dan pemantauan pencadangan. Untuk mengetahui informasi selengkapnya,
lihat Membuat dan mengelola jadwal pencadangan.
|
❑ |
Aktifkan perlindungan penghapusan database untuk mencegah penghapusan yang tidak disengaja atau
tidak sah. Gabungkan hal ini dengan kontrol IAM yang ketat untuk membatasi hak istimewa penghapusan ke sejumlah kecil pengguna atau akun layanan tepercaya. Selain itu, konfigurasikan alat otomatisasi infrastruktur seperti Terraform untuk menyertakan pengamanan terhadap penghapusan database yang tidak disengaja. Pendekatan berlapis ini meminimalkan risiko terhadap aset data penting. Untuk mengetahui informasi selengkapnya, lihat
Mencegah penghapusan database yang tidak disengaja.
|
Logging dan pemantauan
Logging dan pemantauan yang efektif sangat penting untuk mempertahankan visibilitas ke dalam operasi database, mendeteksi anomali, dan memastikan kesehatan sistem. Dengan menggunakan log audit, pelacakan terdistribusi, dasbor, dan pemberitahuan proaktif, Anda dapat mengidentifikasi dan menyelesaikan masalah dengan cepat, mengoptimalkan performa, dan memenuhi persyaratan kepatuhan.
Kotak centang | Aktivitas |
---|---|
❑ |
Aktifkan logging audit untuk merekam informasi mendetail tentang aktivitas database. Konfigurasi tingkat log audit dengan tepat berdasarkan
persyaratan kepatuhan dan operasional untuk memantau pola akses dan
mendeteksi anomali secara efektif. Perhatikan bahwa log audit dapat menjadi besar, terutama untuk permintaan DATA_READ dan DATA_WRITE karena semua pernyataan SQL dan DML dicatat untuk permintaan masing-masing tersebut. Untuk mengetahui informasi selengkapnya, lihat
Log audit Spanner.
Merutekan log ini ke bucket log yang ditentukan pengguna memungkinkan Anda mengoptimalkan biaya retensi log (30 hari pertama tidak dikenai biaya) dan mengontrol akses log secara terperinci menggunakan tampilan log. |
❑ |
Kumpulkan metrik sisi klien dengan menginstrumentasi logika aplikasi Anda
dengan OpenTelemetry untuk mendistribusikan pelacakan dan kemampuan pengamatan. Siapkan
instrumentasi OpenTelemetry untuk merekam rekaman aktivitas dan metrik dari
Spanner, sehingga memastikan visibilitas end-to-end ke dalam performa
aplikasi dan interaksi database. Untuk mengetahui informasi selengkapnya, lihat
Mengambil metrik sisi klien kustom menggunakan OpenTelemetry.
|
❑ |
Buat dan konfigurasi metrik pemantauan untuk memvisualisasikan kueri
performa, latensi, pemakaian CPU, dan penggunaan penyimpanan.
Gunakan metrik ini untuk pelacakan real-time dan analisis historis performa database. Untuk mengetahui informasi selengkapnya, lihat
Memantau instance dengan Cloud Monitoring.
|
❑ |
Tentukan pemberitahuan pemantauan berbasis nilai minimum untuk metrik penting guna
mendeteksi dan mengatasi masalah secara proaktif. Konfigurasi pemberitahuan untuk
kondisi seperti latensi kueri tinggi, ketersediaan penyimpanan rendah, atau
lonjakan traffic yang tidak terduga. Integrasikan pemberitahuan ini dengan alat respons insiden untuk tindakan cepat. Untuk mengetahui informasi selengkapnya, lihat
Membuat pemberitahuan untuk metrik Spanner.
|
Library klien
Mengonfigurasi pemberian tag operasi, kumpulan sesi, dan kebijakan percobaan ulang sangat penting untuk mengoptimalkan performa, men-debug masalah, dan mempertahankan ketahanan di Spanner. Langkah-langkah ini meningkatkan kemampuan observasi, mengurangi latensi, dan memastikan penanganan yang efisien terhadap permintaan workload dan error sementara, menyelaraskan perilaku sistem dengan persyaratan aplikasi.
Kotak centang | Aktivitas |
---|---|
❑ |
Konfigurasi library klien untuk menggunakan permintaan kueri dan
tag transaksi yang bermakna. Anda dapat menggunakan tag permintaan dan transaksi untuk
memahami kueri, pembacaan, dan transaksi Anda.
Sebagai praktik terbaik, gunakan metadata kontekstual seperti komponen aplikasi, jenis permintaan, atau konteks pengguna, dalam tag Anda untuk memungkinkan penelusuran bug dan introspeksi yang lebih baik. Pastikan tag terlihat dalam statistik dan log kueri untuk memfasilitasi analisis performa dan pemecahan masalah. Untuk mengetahui informasi selengkapnya, lihat
Memecahkan masalah dengan tag permintaan dan tag transaksi.
|
❑ |
Optimalkan pengelolaan sesi dengan mengaktifkan penggabungan sesi di library
klien. Konfigurasi setelan kumpulan, seperti sesi minimum dan maksimum, agar sesuai dengan permintaan workload sekaligus meminimalkan latensi. Pantau penggunaan sesi secara teratur untuk menyesuaikan parameter ini dan memastikan bahwa kumpulan sesi memberikan manfaat performa yang konsisten. Untuk mengetahui informasi selengkapnya, lihat Sesi.
|
❑ |
Dalam skenario yang jarang terjadi, parameter library klien default untuk percobaan ulang,
termasuk upaya maksimum dan interval backoff eksponensial, perlu
dikonfigurasi untuk menyeimbangkan ketahanan dengan performa. Uji kebijakan ini secara menyeluruh untuk memastikan kebijakan tersebut sesuai dengan kebutuhan aplikasi.
Untuk mengetahui informasi selengkapnya, lihat
Mengonfigurasi waktu tunggu dan percobaan ulang kustom.
|
Dukungan
Untuk meminimalkan waktu henti dan dampak, tentukan peran dan tanggung jawab insiden yang jelas untuk memastikan respons yang cepat dan terkoordinasi terhadap masalah terkait Spanner. Untuk mengetahui informasi selengkapnya, lihat Mendapatkan dukungan.
Kotak centang | Aktivitas |
---|---|
❑ |
Buat framework respons insiden yang jelas, yang menentukan peran dan
tanggung jawab untuk semua anggota tim yang terlibat dalam mengelola
insiden terkait Spanner. Tentukan peran insiden seperti
Komandan Insiden, Pemimpin Komunikasi, dan Pakar Materi (SME)
untuk memastikan koordinasi dan komunikasi yang efisien selama
insiden. Mengembangkan dan mendokumentasikan proses untuk mengidentifikasi, melakukan eskalasi,
melakukan mitigasi, dan menyelesaikan masalah. Ikuti praktik terbaik yang diuraikan dalam
Google SRE Workbook on Incident Response
dan Managing Incidents.
Lakukan pelatihan dan simulasi respons insiden secara rutin untuk memastikan
kesiapan dan meningkatkan kemampuan tim dalam mengelola skenario
bertekanan tinggi secara efektif.
|
Pengelolaan biaya
Menerapkan strategi pengelolaan biaya seperti penskalaan otomatis dan pencadangan inkremental memastikan penggunaan resource yang efisien dan penghematan biaya yang signifikan. Menyelaraskan penyediaan resource dengan permintaan workload dan mengoptimalkan lingkungan non-produksi akan mengurangi pengeluaran lebih lanjut sekaligus mempertahankan performa dan fleksibilitas.
Kotak centang | Aktivitas |
---|---|
❑ |
Evaluasi dan beli CUD untuk Spanner guna menurunkan biaya
pada workload yang dapat diprediksi. Komitmen ini dapat memberikan penghematan yang signifikan dibandingkan dengan harga sesuai permintaan. Menganalisis pola penggunaan historis untuk menentukan komitmen DA yang optimal. Untuk mengetahui informasi selengkapnya, lihat Diskon abonemen dan Harga Spanner.
|
❑ |
Pantau pemanfaatan kapasitas komputasi dan sesuaikan resource yang disediakan
untuk mempertahankan tingkat pemanfaatan CPU yang direkomendasikan. Penyediaan resource komputasi yang berlebihan dapat menyebabkan biaya yang tidak perlu, sementara penyediaan yang kurang dapat memengaruhi performa. Ikuti
pedoman penggunaan CPU Spanner maksimum yang direkomendasikan untuk memastikan penyelarasan resource yang hemat biaya.
|
❑ |
Aktifkan penskalaan otomatis untuk menyesuaikan kapasitas komputasi secara dinamis berdasarkan
permintaan workload. Hal ini memastikan performa yang optimal selama beban puncak
sekaligus mengurangi biaya selama periode aktivitas rendah. Konfigurasi kebijakan penskalaan dengan batas atas dan bawah untuk mengontrol biaya dan menghindari penskalaan berlebih. Untuk mengetahui informasi selengkapnya, lihat
Ringkasan penskalaan otomatis.
|
❑ |
Gunakan cadangan inkremental untuk mengurangi biaya penyimpanan cadangan.
Cadangan inkremental hanya menyimpan perubahan data sejak pencadangan terakhir. Hal ini
mengurangi persyaratan penyimpanan secara signifikan dibandingkan dengan pencadangan penuh.
Sertakan cadangan inkremental dalam strategi pencadangan Anda. Untuk mengetahui informasi selengkapnya, lihat Pencadangan inkremental.
|
❑ |
Mengoptimalkan biaya untuk lingkungan non-produksi dengan memilih konfigurasi instance yang paling optimal dan menghentikan penyediaan resource saat lingkungan tidak digunakan. Misalnya, mengecilkan ukuran lingkungan yang tidak penting setelah jam kerja atau mengotomatiskan penskalaan resource untuk skenario pengembangan dan pengujian. Pendekatan ini meminimalkan biaya sekaligus mempertahankan
fleksibilitas operasional.
|