Checklist peluncuran ini memberikan daftar pertimbangan yang perlu dilakukan sebelum meluncurkan aplikasi produksi di Spanner. Panduan ini tidak bertujuan untuk menjadi panduan yang lengkap, tetapi berfungsi untuk menyoroti pertimbangan utama guna meminimalkan risiko, mengoptimalkan performa, dan memastikan penyelarasan dengan sasaran bisnis dan operasional, serta menawarkan pendekatan sistematis untuk memberikan 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 untuk performa dan skalabilitas tinggi. Pengujian menyeluruh dan skala produksi yang ketat memastikan sistem dapat menangani beban kerja, beban puncak, dan operasi serentak di dunia nyata, sekaligus meminimalkan risiko bottleneck atau kegagalan dalam produksi.
Kotak centang | Aktivitas |
---|---|
❑ |
Buat 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 interleaving tabel untuk data terkait. Tinjau
Praktik terbaik desain skema
untuk memastikan skema mendukung performa dan skalabilitas tinggi
dalam beban kerja yang diharapkan.
|
❑ |
Optimalkan transaksi dan kueri untuk penguncian minimal dan performa
maksimum. Gunakan mode transaksi Spanner, seperti
pernyataan DML terpartisi, operasi baca-tulis yang mengunci, dan hanya-baca yang kuat, untuk menyeimbangkan konsistensi, throughput, dan latensi. Minimalkan
cakupan penguncian dengan menggunakan
transaksi hanya baca
untuk kueri, pengelompokan
untuk throughput DML maksimum, atau
pernyataan DML berpartisi untuk
pembaruan dan penghapusan skala besar. Saat bermigrasi dari sistem dengan
tingkat isolasi yang berbeda (misalnya, PostgreSQL atau MySQL),
gunakan transaksi untuk menghindari bottleneck performa. Untuk informasi selengkapnya,
lihat Transaksi.
|
❑ |
Lakukan pengujian beban berskala besar yang ketat untuk memvalidasi desain skema,
perilaku transaksi, dan performa kueri. Simulasikan skenario puncak dan
konkurensi tinggi yang meniru beban aplikasi di 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
meningkatkan penerapan.
|
❑ |
Luaskan pengujian beban untuk mencakup semua layanan yang berinteraksi, bukan hanya
aplikasi terisolasi. Simulasikan perjalanan pengguna yang komprehensif
bersama proses paralel, seperti pemuatan batch atau tugas
administrasi yang mengakses database. Jalankan pengujian pada konfigurasi instance
Spanner produksi, memastikan driver dan layanan pengujian beban
selaras secara geografis dengan topologi deployment produksi yang dimaksudkan. 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 menguji beban kerja. Secara default, database Spanner menggunakan versi pengoptimal kueri terbaru.
Evaluasi versi pengoptimal baru
secara berkala di lingkungan terkontrol, dan perbarui versi default hanya setelah
mengonfirmasi kompatibilitas dan peningkatan performa. Untuk mengetahui informasi
selengkapnya, lihat
Ringkasan pengoptimal kueri.
|
❑ |
Pastikan statistik pengoptimal kueri
sudah yang terbaru 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.
Menjaga statistik pengoptimal kueri tetap terbaru sangat penting untuk mempertahankan performa kueri yang optimal.
|
Migrasi (opsional)
Migrasi database adalah proses komprehensif yang memerlukan pemahaman mendalam tentang detail setiap perjalanan migrasi. Pertimbangkan hal berikut dalam strategi migrasi Anda:
Kotak centang | Aktivitas |
---|---|
❑ |
Buat prosedur operasi standar (SOP) mendetail untuk
peralihan migrasi. Hal ini mencakup langkah-langkah untuk peluncuran aplikasi,
pengalihan database, dan otomatisasi untuk meminimalkan intervensi manual.
Identifikasi dan sampaikan potensi periode nonaktif kepada pemangku kepentingan jauh
sebelumnya. Terapkan mekanisme pemantauan dan pemberitahuan yang andal untuk melacak
proses migrasi secara real-time dan mendeteksi anomali dengan segera.
Pastikan proses pengalihan menyertakan pemeriksaan validasi untuk mengonfirmasi integritas data dan kemampuan aplikasi setelah migrasi.
|
❑ |
Siapkan rencana penggantian mendetail untuk kembali ke sistem sumber jika
terjadi masalah kritis selama migrasi. Uji prosedur penggantian
di lingkungan staging untuk memastikan bahwa prosedur tersebut andal,
dan dapat dieksekusi dengan periode nonaktif minimal. Tentukan dengan jelas kondisi
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 beban kerja untuk ketersediaan, latensi, dan skalabilitas, sekaligus mempertimbangkan pertimbangan geografis dan operasional. Menyelaraskan ukuran, pengelolaan resource, skenario failover, dan otomatisasi akan meminimalkan risiko, memastikan performa yang optimal, dan mencegah keterbatasan atau pemadaman resource selama operasi penting.
Kotak centang | Aktivitas |
---|---|
❑ |
Pastikan konfigurasi instance Spanner Anda (baik regional, dual-region, maupun multi-region) sesuai dengan persyaratan latensi dan ketersediaan workload aplikasi, sekaligus mempertimbangkan pertimbangan geografis. Hitung kapasitas komputasi target berdasarkan ukuran penyimpanan yang diharapkan, pola traffic, dan batas penggunaan yang direkomendasikan, untuk memastikan kapasitas yang memadai untuk pemadaman zona atau regional. Buat rencana untuk
puncak traffic dengan mengaktifkan penskalaan otomatis.
Anda dapat menetapkan batas atas untuk kapasitas komputasi guna menetapkan pengamanan biaya. Untuk informasi selengkapnya, lihat
Kapasitas komputasi, node, dan unit pemrosesan.
|
❑ |
Jika Anda menggunakan konfigurasi instance multi-region atau region ganda,
pilih region pemimpin yang meminimalkan latensi untuk operasi tulis aplikasi
dari layanan yang di-deploy di lokasi yang paling sensitif terhadap latensi.
Uji implikasi berbagai region pemimpin terhadap latensi operasi,
dan sesuaikan untuk mengoptimalkan performa aplikasi. Rencanakan skenario
failover dengan memastikan bahwa topologi aplikasi dapat beradaptasi dengan
perubahan region pemimpin selama pemadaman regional. Untuk mengetahui informasi selengkapnya, lihat
Mengubah region pemimpin database.
|
❑ |
Konfigurasikan 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 informasi selengkapnya, lihat
Mengontrol akses dan mengatur instance dengan tag.
|
❑ |
Evaluasi apakah pemanasan Spanner diperlukan,
terutama untuk layanan yang mengharapkan traffic tiba-tiba dan tinggi saat diluncurkan.
Pengujian latensi pada beban awal yang tinggi mungkin mengungkapkan kebutuhan untuk melakukan pemanasan pra-peluncuran guna memastikan performa yang optimal. Jika pemanasan
diperlukan, buat beban buatan. Untuk 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, tabel maksimum 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, sehingga memastikan konfigurasi efisien
dan bebas error. Untuk pengelolaan skema, pertimbangkan untuk menggunakan alat seperti
Liquibase
untuk menghindari penghapusan skema yang tidak disengaja selama update. Untuk 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 kegagalan yang tidak terduga. Pengujian prosedur pemulihan dan otomatisasi pencadangan secara rutin membantu memastikan kesiapan operasional, kepatuhan terhadap tujuan pemulihan, dan perlindungan data yang andal yang disesuaikan dengan kebutuhan organisasi.
Kotak centang | Aktivitas |
---|---|
❑ |
Menentukan 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 disaster recovery
untuk mengidentifikasi alat dan teknik yang tepat guna memastikan kepatuhan terhadap
ketersediaan, keandalan, dan keamanan untuk aplikasi Anda. Untuk informasi
selengkapnya, lihat
laporan resmi Solusi pemulihan dan perlindungan 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
validasi 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. Konfigurasikan 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.
|
❑ |
Selaraskan prosedur failover dengan
topologi konfigurasi instance aplikasi Anda
untuk meminimalkan dampak latensi jika terjadi pemadaman layanan. Uji skenario pemulihan dari bencana, yang memastikan 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 terus memperbarui statistik akan 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 tempat beban kerja telah diuji. Evaluasi
secara rutin versi pengoptimal baru
di lingkungan terkontrol, dan perbarui versi default hanya setelah
mengonfirmasi kompatibilitas dan peningkatan performa. Untuk mengetahui informasi
selengkapnya, lihat
Ringkasan pengoptimal kueri.
|
❑ |
Pastikan statistik pengoptimal kueri
sudah yang terbaru 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.
Menjaga 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 melepas semat setelah
paket yang diupdate divalidasi. Untuk informasi selengkapnya, lihat
Paket statistik pengoptimal kueri.
|
Keamanan
Mengimplementasikan langkah-langkah kontrol akses sangatlah 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 melindungi 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 informasi selengkapnya, lihat
ringkasan IAM.
|
❑ |
Jika aplikasi memerlukan akses terbatas ke baris, kolom, atau sel tertentu dalam tabel, terapkan kontrol akses terperinci (FGAC). Mendesain dan menerapkan 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 kepatuhan dan keamanan yang terus berkembang. Untuk mengetahui informasi selengkapnya, lihat
Ringkasan kontrol akses terperinci.
|
❑ |
Terapkan jadwal pencadangan otomatis untuk memastikan perlindungan data yang konsisten dan
andal. Konfigurasikan 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 sekumpulan pengguna atau akun layanan tepercaya dalam jumlah kecil. Selain itu, konfigurasikan alat otomatisasi infrastruktur
seperti Terraform untuk menyertakan pengamanan terhadap penghapusan database Anda
yang tidak disengaja. Pendekatan berlapis ini meminimalkan risiko terhadap
aset data penting. Untuk informasi selengkapnya, lihat
Mencegah penghapusan database yang tidak disengaja.
|
Logging dan pemantauan
Logging dan pemantauan yang efektif sangat penting untuk mempertahankan visibilitas terhadap operasi database, mendeteksi anomali, dan memastikan kondisi 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 mengambil informasi mendetail tentang aktivitas database. Konfigurasikan level log audit dengan tepat berdasarkan
persyaratan kepatuhan dan operasional untuk memantau pola akses dan
mendeteksi anomali secara efektif. Perhatikan bahwa log audit mungkin menjadi besar, terutama untuk permintaan DATA_READ dan DATA_WRITE karena semua pernyataan SQL dan DML dicatat ke dalam log untuk permintaan tersebut. Untuk 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 melengkapi logika aplikasi Anda
dengan OpenTelemetry untuk mendistribusikan pelacakan dan visibilitas. Siapkan
instrumentasi OpenTelemetry untuk mengambil trace dan metrik dari
Spanner, yang memastikan visibilitas menyeluruh ke performa aplikasi
dan interaksi database. Untuk informasi selengkapnya, lihat
Mengambil metrik sisi klien kustom menggunakan OpenTelemetry.
|
❑ |
Buat dan konfigurasikan metrik pemantauan untuk memvisualisasikan performa kueri, latensi, penggunaan CPU, dan penggunaan penyimpanan.
Gunakan metrik ini untuk pelacakan real-time dan analisis historis performa database. Untuk informasi selengkapnya, lihat
Memantau instance dengan Cloud Monitoring.
|
❑ |
Menentukan pemberitahuan pemantauan berbasis nilai minimum untuk metrik penting guna
mendeteksi dan mengatasi masalah secara proaktif. Konfigurasikan pemberitahuan untuk kondisi seperti latensi kueri yang tinggi, ketersediaan penyimpanan yang rendah, atau lonjakan traffic yang tidak terduga. Integrasikan pemberitahuan ini dengan alat respons insiden untuk tindakan cepat. Untuk 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, memecahkan masalah proses debug, dan mempertahankan ketahanan di Spanner. Langkah-langkah ini meningkatkan visibilitas, mengurangi latensi, dan memastikan penanganan yang efisien terhadap permintaan beban kerja dan error sementara, sehingga menyelaraskan perilaku sistem dengan persyaratan aplikasi.
Kotak centang | Aktivitas |
---|---|
❑ |
Konfigurasikan library klien untuk menggunakan permintaan kueri dan tag transaksi yang bermakna. Anda dapat menggunakan tag permintaan dan transaksi untuk
mengembangkan pemahaman tentang kueri, pembacaan, dan transaksi.
Sebagai praktik terbaik, gunakan metadata kontekstual seperti komponen aplikasi, jenis permintaan, atau konteks pengguna, dalam tag Anda untuk mengaktifkan proses debug dan introspeksi yang ditingkatkan. Pastikan tag terlihat dalam statistik dan log
kueri untuk memfasilitasi analisis dan pemecahan masalah performa. Untuk informasi selengkapnya, lihat
Memecahkan masalah dengan tag permintaan dan tag transaksi.
|
❑ |
Optimalkan pengelolaan sesi dengan mengaktifkan penggabungan sesi di library
klien. Konfigurasikan setelan kumpulan, seperti sesi minimum dan maksimum, untuk mencocokkan permintaan beban kerja sekaligus meminimalkan latensi. Pantau penggunaan sesi secara rutin untuk menyesuaikan parameter ini dan memastikan bahwa kumpulan sesi memberikan manfaat performa yang konsisten. Untuk 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 bahwa kebijakan tersebut sesuai dengan kebutuhan aplikasi.
Untuk informasi selengkapnya, lihat
Mengonfigurasi waktu tunggu dan percobaan ulang kustom.
|
Dukungan
Untuk meminimalkan periode nonaktif dan dampaknya, tentukan peran dan tanggung jawab insiden yang jelas untuk memastikan respons yang cepat dan terkoordinasi terhadap masalah terkait Spanner. Untuk 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. Tetapkan peran insiden seperti
Incident Commander, Communications Lead, dan Subject Matter Experts
(SME) untuk memastikan koordinasi dan komunikasi yang efisien selama
insiden. Mengembangkan dan mendokumentasikan proses untuk mengidentifikasi, mengeskalasikan,
memitigasi, dan menyelesaikan masalah. Ikuti praktik terbaik yang diuraikan dalam
Workbook SRE Google tentang Respons Insiden
dan Mengelola Insiden.
Lakukan pelatihan dan simulasi respons insiden secara rutin untuk memastikan
kesiapan dan meningkatkan kemampuan tim dalam mengelola skenario tekanan tinggi
secara efektif.
|
Pengelolaan biaya
Menerapkan strategi pengelolaan biaya seperti diskon abonemen (CUD), penskalaan otomatis, dan pencadangan inkremental memastikan pemanfaatan resource yang efisien dan penghematan biaya yang signifikan. Menyelaraskan penyediaan resource dengan permintaan beban kerja dan mengoptimalkan lingkungan non-produksi akan lebih mengurangi pengeluaran 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. Analisis pola penggunaan historis untuk menentukan komitmen CUD yang optimal. Untuk mengetahui informasi selengkapnya, lihat Diskon abonemen dan Harga Spanner.
|
❑ |
Pantau penggunaan kapasitas komputasi dan sesuaikan resource yang disediakan untuk mempertahankan tingkat penggunaan CPU yang direkomendasikan. Penyediaan resource komputasi yang berlebihan dapat menyebabkan biaya yang tidak perlu, sedangkan 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 beban kerja. Hal ini memastikan performa yang optimal selama beban puncak
sekaligus mengurangi biaya selama periode aktivitas rendah. Konfigurasikan kebijakan penskalaan dengan batas atas dan bawah untuk mengontrol biaya dan menghindari penskalaan berlebih. Untuk informasi selengkapnya, lihat
Ringkasan penskalaan otomatis.
|
❑ |
Gunakan cadangan tambahan untuk mengurangi biaya penyimpanan cadangan.
Cadangan inkremental hanya menyimpan perubahan data sejak pencadangan terakhir. Hal ini
secara signifikan mengurangi persyaratan penyimpanan dibandingkan dengan pencadangan penuh.
Gabungkan pencadangan inkremental ke dalam strategi pencadangan Anda. Untuk informasi
selengkapnya, lihat
Pencadangan inkremental.
|
❑ |
Optimalkan biaya untuk lingkungan non-produksi dengan memilih konfigurasi instance yang paling optimal dan membatalkan penyediaan resource saat lingkungan tidak digunakan. Misalnya, turunkan ukuran lingkungan yang tidak penting
setelah jam kerja atau otomatiskan penskalaan resource untuk skenario
pengembangan dan pengujian. Pendekatan ini meminimalkan biaya sekaligus mempertahankan
fleksibilitas operasional.
|