Ringkasan alat Autoscaler

Halaman ini memperkenalkan alat Autoscaler untuk Spanner (Autoscaler), yaitu alat open source yang dapat Anda gunakan sebagai alat pendamping untuk Spanner. Alat ini memungkinkan Anda meningkatkan atau mengurangi kapasitas komputasi secara otomatis di satu atau beberapa instance Spanner berdasarkan jumlah kapasitas yang digunakan.

Untuk mengetahui informasi selengkapnya tentang penskalaan di Spanner, lihat Penskalaan otomatis Spanner. Untuk mengetahui informasi tentang cara men-deploy alat Autoscaler, lihat referensi berikut:

• Men-deploy alat Autoscaler per project atau terpusat untuk Spanner
• Men-deploy alat Autoscaler terdistribusi untuk Spanner

Halaman ini menyajikan fitur, arsitektur, konfigurasi, dan topologi deployment Autoscaler. Topik yang melanjutkan seri ini akan memandu Anda dalam deployment Autoscaler di setiap topologi yang berbeda.

Autoscaler

Alat Autoscaler berguna untuk mengelola penggunaan dan performa deployment Spanner Anda. Untuk membantu Anda menyeimbangkan kontrol biaya dengan kebutuhan performa, alat Autoscaler memantau instance Anda dan secara otomatis menambahkan atau menghapus node atau unit pemrosesan untuk membantu memastikan bahwa instance tersebut tetap berada dalam parameter berikut:

• Nilai maksimum yang direkomendasikan untuk penggunaan CPU.

• Batas yang direkomendasikan untuk penyimpanan per node

  ditambah atau dikurangi margin yang dapat dikonfigurasi.

Dengan menggunakan deployment Spanner penskalaan otomatis, infrastruktur Anda dapat beradaptasi dan diskalakan secara otomatis untuk memenuhi persyaratan beban dengan sedikit atau tanpa intervensi. Penskalaan otomatis juga menyesuaikan ukuran infrastruktur yang disediakan, yang dapat membantu Anda mengurangi biaya.

Arsitektur

Bagian ini menjelaskan komponen Autoscaler dan tujuannya masing-masing secara lebih mendetail.

Arsitektur alat Autoscaler terdiri dari Cloud Scheduler , dua topik Pub/Sub, dua fungsi Cloud Run , dan Firestore . Cloud Monitoring API digunakan untuk mendapatkan metrik penggunaan CPU dan penyimpanan untuk instance Spanner.

Cloud Scheduler

Dengan menggunakan Cloud Scheduler, Anda menentukan seberapa sering alat Autoscaler memverifikasi nilai minimum metrik penskalaan instance Spanner Anda. Tugas Cloud Scheduler dapat memeriksa satu atau beberapa instance secara bersamaan. Anda dapat menentukan jadwal tugas sebanyak yang diperlukan.

Fungsi Cloud Run polling

Fungsi Cloud Run Poller bertanggung jawab untuk mengumpulkan dan memproses metrik deret waktu untuk satu atau beberapa instance Spanner. Poller memproses data metrik untuk setiap instance Spanner terlebih dahulu sehingga hanya titik data yang paling relevan yang dievaluasi dan dikirim ke fungsi Scaler Cloud Run. Prapemrosesan yang dilakukan oleh fungsi Poller Cloud Run juga menyederhanakan proses mengevaluasi nilai minimum untuk instance Spanner regional, dual-region, dan multi-region.

Fungsi Cloud Run Scaler

Fungsi Cloud Run Scaler mengevaluasi titik data yang diterima dari fungsi Cloud Run Poller dan menentukan apakah Anda perlu menyesuaikan jumlah node atau unit pemrosesan dan jika ya, berapa banyak. Fungsi Cloud Run membandingkan nilai metrik dengan nilai minimum, ditambah atau dikurangi margin yang diizinkan, dan menyesuaikan jumlah node atau unit pemrosesan berdasarkan metode penskalaan yang dikonfigurasi. Untuk mengetahui detail selengkapnya tentang metode penskalaan, lihat Fitur autoscaler.

Alur operasional

Bagian ini menjelaskan model operasional alat Autoscaler, seperti yang ditunjukkan dalam diagram arsitektur berikut.

1. Anda menentukan jadwal, waktu, dan frekuensi tugas penskalaan otomatis di Cloud Scheduler.
2. Pada jadwal yang Anda tentukan, Cloud Scheduler akan mengirim pesan yang berisi payload JSON dengan parameter konfigurasi alat Autoscaler untuk satu atau beberapa instance Spanner ke topik Pub/Sub Polling.
3. Saat pesan dipublikasikan ke topik Polling, instance fungsi Cloud Run Poller akan dibuat untuk menangani pesan.
4. Fungsi Cloud Run Poller membaca payload pesan dan membuat kueri Cloud Monitoring API untuk mengambil metrik penggunaan untuk setiap instance Spanner.
5. Untuk setiap instance Spanner yang dihitung dalam pesan, fungsi Poller akan mengirim satu pesan ke topik Pub/Sub Penskalaan, yang berisi metrik dan parameter konfigurasi untuk menilai instance Spanner tertentu.

6. Untuk setiap pesan yang dikirim ke topik Scaler, fungsi Cloud Run Scaler melakukan hal berikut:

   1. Membandingkan metrik instance Spanner dengan nilai minimum yang dikonfigurasi, ditambah atau dikurangi margin yang dapat dikonfigurasi.

   Anda dapat mengonfigurasi margin sendiri, atau menggunakan nilai default. 1. Menentukan apakah instance harus diskalakan. 1. Menghitung jumlah node atau unit pemrosesan yang akan digunakan untuk penskalaan instance berdasarkan metode penskalaan yang dipilih.

7. Fungsi Scaler Cloud Run mengambil waktu saat instance terakhir kali diskalakan dari Firestore dan membandingkannya dengan waktu saat ini, untuk menentukan apakah penskalaan ke atas atau ke bawah diizinkan berdasarkan periode cooldown.

8. Jika periode tunggu yang dikonfigurasi telah berlalu, fungsi Cloud Run Scaler akan mengirim permintaan ke Instance Spanner untuk menskalakan ke atas atau ke bawah.

Sepanjang alur, alat Autoscaler menulis ringkasan rekomendasi dan tindakannya ke Cloud Logging untuk pelacakan dan audit.

Terlepas dari topologi deployment yang Anda pilih, keseluruhan operasi alat Autoscaler tetap sama.

Fitur autoscaler

Bagian ini menjelaskan fitur utama alat Autoscaler.

Mengelola beberapa instance

Alat Autoscaler dapat mengelola beberapa instance Spanner di beberapa project. Instance multi-regional, region ganda, dan regional semuanya memiliki nilai minimum penggunaan yang berbeda yang digunakan saat penskalaan. Misalnya, deployment multi-region dan dual-region diskalakan pada penggunaan CPU prioritas tinggi sebesar 45%, sedangkan deployment regional diskalakan pada penggunaan CPU prioritas tinggi sebesar 65%, baik ditambah maupun dikurangi margin yang diizinkan. Untuk informasi selengkapnya tentang berbagai nilai minimum untuk penskalaan, lihat Notifikasi untuk penggunaan CPU yang tinggi.

Parameter konfigurasi independen

Setiap instance Spanner yang diskalakan otomatis dapat memiliki satu atau beberapa jadwal polling. Setiap jadwal polling memiliki kumpulan parameter konfigurasinya sendiri.

Parameter ini menentukan faktor berikut:

• Jumlah minimum dan maksimum node atau unit pemrosesan yang mengontrol ukuran instance Anda, baik besar maupun kecil, sehingga membantu Anda mengontrol biaya.
• Metode penskalaan yang digunakan untuk menyesuaikan instance Spanner khusus untuk beban kerja Anda.
• Periode tunggu untuk memungkinkan Spanner mengelola pemisahan data.

Metode penskalaan yang berbeda untuk berbagai beban kerja

Alat Autoscaler menyediakan tiga metode penskalaan yang berbeda untuk penskalaan instance Spanner ke atas dan ke bawah: bertahap, linear, dan langsung. Setiap metode dirancang untuk mendukung berbagai jenis beban kerja. Anda dapat menerapkan satu atau beberapa metode ke setiap instance Spanner yang diskalakan secara otomatis saat membuat jadwal polling independen.

Stepwise

Penskalaan bertahap berguna untuk workload yang memiliki puncak kecil atau beberapa puncak. Autoscaler menyediakan kapasitas untuk merampingkan semuanya dengan satu peristiwa penskalaan otomatis.

Diagram berikut menunjukkan pola beban dengan beberapa dataran atau langkah beban, dengan setiap langkah memiliki beberapa puncak kecil. Pola ini sangat cocok untuk metode bertahap.

Saat nilai minimum beban terlampaui, metode ini akan menyediakan dan menghapus node atau unit pemrosesan menggunakan jumlah tetap, tetapi dapat dikonfigurasi. Misalnya, tiga node ditambahkan atau dihapus untuk setiap tindakan penskalaan. Dengan mengubah konfigurasi, Anda dapat mengizinkan penambahan kapasitas yang lebih besar atau penghapusan kapasitas kapan saja.

Linear

Penskalaan linear paling baik digunakan dengan pola beban yang berubah secara bertahap atau memiliki beberapa puncak besar. Metode ini menghitung jumlah minimum node atau unit pemrosesan yang diperlukan untuk menjaga penggunaan di bawah nilai minimum penskalaan. Jumlah node atau unit pemrosesan yang ditambahkan atau dihapus dalam setiap peristiwa penskalaan tidak terbatas pada jumlah langkah tetap.

Contoh pola beban dalam diagram berikut menunjukkan peningkatan dan penurunan beban yang lebih besar secara tiba-tiba. Fluktuasi ini tidak dikelompokkan dalam langkah-langkah yang dapat dikenali seperti dalam diagram sebelumnya. Pola ini lebih mudah ditangani menggunakan penskalaan linear.

Alat Autoscaler menggunakan rasio penggunaan yang diamati terhadap nilai minimum penggunaan untuk menghitung apakah akan menambahkan atau mengurangi node atau unit pemrosesan dari jumlah total saat ini.

Rumus untuk menghitung jumlah node atau unit pemrosesan baru adalah sebagai berikut:

newSize = currentSize * currentUtilization / utilizationThreshold

Langsung

Penskalaan langsung memberikan peningkatan kapasitas secara langsung. Metode ini dimaksudkan untuk mendukung beban kerja batch dengan jumlah node yang lebih tinggi dan telah ditentukan sebelumnya yang diperlukan secara berkala sesuai jadwal dengan waktu mulai yang diketahui. Metode ini menskalakan instance hingga jumlah maksimum node atau unit pemrosesan yang ditentukan dalam jadwal, dan dimaksudkan untuk digunakan selain metode linear atau bertahap.

Diagram berikut menggambarkan peningkatan beban yang direncanakan dalam jumlah besar, yang telah disediakan kapasitasnya terlebih dahulu oleh Autoscaler untuk menggunakan metode langsung.

Setelah beban kerja batch selesai dan penggunaan kembali ke tingkat normal, bergantung pada konfigurasi Anda, penskalaan linear atau bertahap akan diterapkan untuk menskalakan instance ke bawah secara otomatis.

Metode deployment

Alat Autoscaler dapat di-deploy di setiap project atau bersama dengan instance Spanner yang dikelolanya. Alat Autoscaler dirancang untuk memungkinkan fleksibilitas dan dapat mengakomodasi pemisahan tanggung jawab yang ada antara tim operasi dan aplikasi Anda. Tanggung jawab untuk mengonfigurasi penskalaan otomatis instance Spanner dapat dipusatkan dengan satu tim operasi, atau dapat didistribusikan ke tim yang lebih dekat dengan aplikasi yang ditayangkan oleh instance Spanner tersebut.

Berbagai model deployment dibahas secara lebih mendetail di Topologi deployment.

Serverless untuk kemudahan deployment dan pengelolaan

Alat Autoscaler dibuat hanya menggunakan alat Google Cloud serverless dan pengelolaan rendah, seperti fungsi Cloud Run, Pub/Sub, Cloud Scheduler, dan Firestore. Pendekatan ini meminimalkan biaya dan overhead operasional untuk menjalankan alat Autoscaler.

Dengan menggunakan alat Google Cloud bawaan, alat Autoscaler dapat memanfaatkan sepenuhnya Identity and Access Management (IAM) untuk autentikasi dan otorisasi.

Konfigurasi

Alat Autoscaler memiliki berbagai opsi konfigurasi yang dapat Anda gunakan untuk mengelola penskalaan deployment Spanner. Bagian berikutnya menjelaskan opsi konfigurasi dasar dan opsi konfigurasi lanjutan.

Konfigurasi dasar

Alat Autoscaler mengelola instance Spanner melalui konfigurasi yang ditentukan di Cloud Scheduler. Jika beberapa instance Spanner perlu di-polling dengan interval yang sama, sebaiknya konfigurasikan instance tersebut dalam tugas Cloud Scheduler yang sama. Konfigurasi setiap instance direpresentasikan sebagai objek JSON. Berikut adalah contoh konfigurasi dengan dua instance Spanner yang dikelola dengan satu tugas Cloud Scheduler:

   [
    {
        "projectId": "my-spanner-project", "instanceId": "spanner1",
        "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
        "units": "NODES", "minSize": 1, "maxSize": 3
     },
     {
        "projectId":
        "different-project", "instanceId": "another-spanner1", "scalerPubSubTopic":
        "projects/my-spanner-project/topics/spanner-scaling", "units":
        "PROCESSING_UNITS", "minSize": 500, "maxSize": 3000, "scalingMethod": "DIRECT"
    }
   ]

Instance Spanner dapat memiliki beberapa konfigurasi pada tugas Cloud Scheduler yang berbeda. Misalnya, instance dapat memiliki satu konfigurasi Autoscaler dengan metode linear untuk operasi normal, tetapi juga memiliki konfigurasi Autoscaler lain dengan metode langsung untuk workload batch terencana.

Saat berjalan, tugas Cloud Scheduler akan mengirim pesan Pub/Sub ke topik Pub/Sub Polling. Payload pesan ini adalah array JSON dari objek konfigurasi untuk semua instance yang dikonfigurasi dalam tugas yang sama. Lihat daftar lengkap opsi konfigurasi di file README Poller.

Konfigurasi lanjutan

Alat Autoscaler memiliki opsi konfigurasi lanjutan yang memungkinkan Anda mengontrol waktu dan cara pengelolaan instance Spanner dengan lebih tepat. Bagian berikut memperkenalkan pilihan kontrol ini.

Batas kustom

Alat Autoscaler menentukan jumlah node atau unit pemrosesan yang akan ditambahkan atau dikurangi ke instance menggunakan nilai minimum Spanner yang direkomendasikan untuk metrik beban berikut:

• CPU dengan prioritas tinggi
• CPU rata-rata penggiliran 24 jam
• Pemanfaatan penyimpanan

Sebaiknya gunakan nilai minimum default seperti yang dijelaskan dalam artikel Membuat pemberitahuan untuk metrik Spanner. Namun, dalam beberapa kasus, Anda mungkin ingin mengubah nilai minimum yang digunakan oleh alat Autoscaler. Misalnya, Anda dapat menggunakan nilai minimum yang lebih rendah agar alat Autoscaler bereaksi lebih cepat daripada untuk nilai minimum yang lebih tinggi. Modifikasi ini membantu mencegah notifikasi dipicu pada nilai minimum yang lebih tinggi.

Metrik kustom

Meskipun metrik default di alat Autoscaler menangani sebagian besar skenario performa dan penskalaan, ada beberapa kasus saat Anda mungkin perlu menentukan metrik Anda sendiri yang digunakan untuk menentukan kapan harus menskalakan ke atas dan ke bawah. Untuk skenario ini, Anda menentukan metrik kustom dalam konfigurasi menggunakan properti metrics.

Margin

Margin menentukan batas atas dan bawah di sekitar nilai minimum. Alat Autoscaler hanya memicu peristiwa penskalaan otomatis jika nilai metrik lebih dari batas atas atau kurang dari batas bawah.

Tujuan parameter ini adalah untuk menghindari peristiwa penskalaan otomatis dipicu untuk fluktuasi beban kerja kecil di sekitar nilai minimum, sehingga mengurangi jumlah fluktuasi dalam tindakan Autoscaler. Batas dan margin bersama-sama menentukan rentang berikut, sesuai dengan nilai metrik yang Anda inginkan:

[threshold - margin, threshold + margin]

. Semakin kecil margin, semakin sempit rentangnya, sehingga kemungkinan peristiwa penskalaan otomatis dipicu akan lebih tinggi.

Menentukan parameter margin untuk metrik bersifat opsional, dan secara default ditetapkan ke lima poin persentase sebelum dan di bawah parameter.

Topologi deployment

Untuk men-deploy alat Autoscaler, tentukan topologi mana dari berikut ini yang paling cocok untuk memenuhi kebutuhan teknis dan operasional Anda:

• Topologi per project: Infrastruktur Autoscaler di-deploy dalam project yang sama dengan Spanner yang perlu diskalakan secara otomatis.
• Topologi terpusat: Alat Autoscaler di-deploy di satu project dan mengelola satu atau beberapa instance Spanner di project yang berbeda.
• Topologi terdistribusi:: Sebagian besar infrastruktur Autoscaler di-deploy dalam satu project, tetapi beberapa komponen infrastruktur di-deploy dengan instance Spanner yang diskalakan secara otomatis di project yang berbeda.

Topologi per project

Dalam deployment topologi per project, setiap project dengan instance Spanner yang perlu diskalakan secara otomatis juga memiliki deployment komponen Autoscaler independennya sendiri. Sebaiknya gunakan topologi ini untuk tim independen yang ingin mengelola konfigurasi dan infrastruktur Autoscaler mereka sendiri. Ini juga merupakan titik awal yang baik untuk menguji kemampuan alat Autoscaler.

Diagram berikut menunjukkan tampilan konseptual tingkat tinggi dari deployment per project.

Deployment per project yang digambarkan dalam diagram sebelumnya memiliki karakteristik berikut:

• Dua aplikasi, Aplikasi 1 dan Aplikasi 2, masing-masing menggunakan instance Spanner-nya sendiri.
• Instance Spanner (A) berada di project Aplikasi 1 dan Aplikasi 2 masing-masing.
• Autoscaler independen (B) di-deploy ke setiap project untuk mengontrol penskalaan otomatis instance dalam project.

Untuk diagram deployment per project yang lebih mendetail, lihat bagian Arsitektur.

Deployment per project memiliki kelebihan dan kekurangan berikut.

Kelebihan:

• Desain paling sederhana: Topologi per project adalah desain paling sederhana dari ketiga topologi karena semua komponen Autoscaler di-deploy bersama instance Spanner yang diskalakan secara otomatis.
• Konfigurasi: Kontrol atas parameter penjadwal dimiliki oleh tim yang memiliki instance Spanner, yang memberi tim lebih banyak kebebasan untuk menyesuaikan alat Autoscaler dengan kebutuhannya daripada topologi terpusat atau terdistribusi.
• Batasan tanggung jawab infrastruktur yang jelas: Desain topologi per project menetapkan batasan tanggung jawab dan keamanan yang jelas atas infrastruktur Autoscaler karena pemilik tim dari instance Spanner juga merupakan pemilik infrastruktur Autoscaler.

Kekurangan:

• Pemeliharaan yang lebih menyeluruh: Setiap tim bertanggung jawab atas konfigurasi dan infrastruktur Autoscaler sehingga mungkin sulit untuk memastikan bahwa semua alat Autoscaler di seluruh perusahaan mengikuti panduan update yang sama.
• Audit yang lebih kompleks: Karena setiap tim memiliki tingkat kontrol yang tinggi, audit terpusat dapat menjadi lebih kompleks.

Untuk mempelajari cara menyiapkan Autoscaler menggunakan topologi per project, lihat Men-deploy alat Autoscaler per project atau terpusat untuk Spanner.

Topologi terpusat

Seperti pada topologi per project, dalam deployment topologi terpusat, semua komponen alat Autoscaler berada dalam project yang sama. Namun, instance Spanner berada di project yang berbeda. Deployment ini cocok untuk tim yang mengelola konfigurasi dan infrastruktur beberapa instance Spanner dari satu deployment alat Autoscaler di tempat terpusat.

Diagram berikut menunjukkan tampilan konseptual tingkat tinggi dari deployment project terpusat:

Deployment terpusat yang ditampilkan dalam diagram sebelumnya memiliki karakteristik berikut:

• Dua aplikasi, Aplikasi 1 dan Aplikasi 2, masing-masing menggunakan instance Spanner-nya sendiri.
• Instance Spanner (A) berada di project Aplikasi 1 dan Aplikasi 2 masing-masing.
• Autoscaler (B) di-deploy ke project terpisah untuk mengontrol penskalaan otomatis instance Spanner di project Aplikasi 1 dan Aplikasi 2.

Untuk diagram deployment project terpusat yang lebih mendetail, lihat Men-deploy alat Autoscaler per project atau terpusat untuk Spanner.

Deployment terpusat memiliki kelebihan dan kekurangan berikut.

Kelebihan:

• Konfigurasi dan infrastruktur terpusat: Satu tim mengontrol parameter penjadwal dan infrastruktur Autoscaler. Pendekatan ini dapat berguna di industri yang diatur secara ketat.
• Lebih sedikit pemeliharaan secara keseluruhan: Pemeliharaan dan penyiapan umumnya lebih mudah dilakukan dibandingkan dengan deployment per project.
• Kebijakan dan audit terpusat: Praktik terbaik di seluruh tim mungkin lebih mudah ditentukan dan diterapkan. Audit mungkin lebih mudah dijalankan.

Kekurangan:

• Konfigurasi terpusat: Setiap perubahan pada parameter Autoscaler harus melalui tim terpusat, meskipun tim yang meminta perubahan tersebut memiliki instance Spanner.
• Potensi risiko tambahan: Tim terpusat itu sendiri dapat menjadi titik kegagalan tunggal meskipun infrastruktur Autoscaler dirancang dengan mempertimbangkan ketersediaan tinggi.

Untuk tutorial langkah demi langkah guna menyiapkan alat Autoscaler menggunakan opsi ini, lihat Men-deploy alat Autoscaler per project atau terpusat untuk Spanner.

Topologi terdistribusi

Dalam deployment topologi terdistribusi, instance Cloud Scheduler dan Spanner yang perlu diskalakan secara otomatis berada dalam project yang sama. Komponen lain dari alat Autoscaler berada dalam project yang dikelola secara terpusat. Deployment ini adalah deployment hybrid. Tim yang memiliki instance Spanner hanya mengelola parameter konfigurasi Autoscaler untuk instance mereka, dan tim pusat mengelola infrastruktur Autoscaler yang tersisa.

Diagram berikut menunjukkan tampilan konseptual tingkat tinggi dari deployment project terdistribusi.

Deployment hybrid yang digambarkan dalam diagram sebelumnya memiliki karakteristik berikut:

• Dua aplikasi, Aplikasi 1 dan Aplikasi 2, menggunakan instance Spanner-nya sendiri.
• Instance Spanner (A) ada di project Aplikasi 1 dan Aplikasi 2.
• Komponen Cloud Scheduler independen (C) di-deploy ke setiap project: Aplikasi 1 dan Aplikasi 2.
• Komponen Autoscaler yang tersisa (B) di-deploy ke project terpisah.
• Alat Autoscaler menskalakan otomatis instance Spanner di project Application 1 dan Application 2 menggunakan konfigurasi yang dikirim oleh komponen Cloud Scheduler independen di setiap project.

Untuk diagram deployment project terpusat yang lebih mendetail, lihat Men-deploy alat Autoscaler terdistribusi untuk Spanner.

Deployment terdistribusi memiliki kelebihan dan kekurangan berikut.

Kelebihan:

• Tim aplikasi mengontrol konfigurasi dan jadwal: Cloud Scheduler di-deploy bersama instance Spanner yang diskalakan secara otomatis, sehingga tim aplikasi memiliki lebih banyak kontrol atas konfigurasi dan penjadwalan.
• Tim operasi mengontrol infrastruktur: Komponen inti alat Autoscaler di-deploy secara terpusat sehingga tim operasi dapat mengontrol infrastruktur Autoscaler.
• Pemeliharaan terpusat: Infrastruktur Scaler terpusat, sehingga mengurangi overhead.

Kekurangan:

• Konfigurasi yang lebih kompleks: Tim aplikasi perlu menyediakan akun layanan untuk menulis ke topik polling.
• Potensi risiko tambahan: Infrastruktur bersama dapat menjadi titik tunggal kegagalan meskipun infrastruktur dirancang dengan ketersediaan yang tinggi.

Untuk mempelajari cara menyiapkan alat Autoscaler dalam deployment terdistribusi, lihat Men-deploy alat Autoscaler terdistribusi untuk Spanner.

Pemisahan data

Spanner menetapkan rentang data yang disebut pemisahan ke node atau subdivisi node yang disebut unit pemrosesan. Node atau unit pemrosesan secara independen mengelola dan menyalurkan data dalam bagian yang dialokasikan. Pemisahan data dibuat berdasarkan beberapa faktor, termasuk volume data dan pola akses. Untuk mengetahui detail selengkapnya, lihat Spanner - skema dan model data .

Catatan: Spanner menagih Anda setiap jam untuk jumlah node atau unit pemrosesan maksimum yang ada selama jam tersebut, dikalikan dengan tarif per jam. Akibatnya, setiap node atau unit pemrosesan yang Anda sediakan akan ditagih selama minimum satu jam. Sebaiknya jangan optimalkan konfigurasi Autoscaler untuk penskalaan dalam satu jam. Untuk mengetahui informasi selengkapnya, lihat ringkasan harga Spanner .

Data diatur ke dalam bagian dan Spanner secara otomatis mengelola bagian tersebut. Jadi, saat alat Autoscaler menambahkan atau menghapus node atau unit pemrosesan, alat tersebut harus memberi backend Spanner waktu yang cukup untuk menetapkan ulang dan mengatur ulang pemisahan saat kapasitas baru ditambahkan atau dihapus dari instance.

Alat Autoscaler menggunakan periode tunggu pada peristiwa penskalaan naik dan penskalaan turun untuk mengontrol seberapa cepat alat ini dapat menambahkan atau menghapus node atau unit pemrosesan dari instance. Metode ini memungkinkan instance memiliki waktu yang diperlukan untuk mengatur ulang hubungan antara catatan komputasi atau unit pemrosesan dan pemisahan data. Secara default, periode cooldown penskalaan ke atas dan penskalaan ke bawah ditetapkan ke nilai minimum berikut:

• Nilai penskalaan: 5 menit
• Nilai penskalaan ke bawah: 30 menit

Untuk informasi selengkapnya tentang rekomendasi penskalaan dan periode tunggu, lihat Menskalakan Instance Spanner.

Biaya

Konsumsi resource alat Autoscaler sangat minimal sehingga untuk sebagian besar kasus penggunaan, biayanya dapat diabaikan. Tidak ada biaya saat Autoscaler digunakan di Google Cloud. Misalnya , menjalankan alat Autoscaler untuk mengelola 3 instance Spanner dengan interval polling 5 menit untuk setiap instance tersedia tanpa biaya. Estimasi ini mencakup hal berikut:

• 3 Tugas Cloud Scheduler
• 0,15 GB pesan Pub/Sub
• 51840 pemanggilan fungsi Cloud Run 500 md
• Data kurang dari 10 MB di Firestore

Estimasi ini tidak mencakup biaya operasi database Spanner. Gunakan Kalkulator Harga untuk membuat perkiraan biaya berdasarkan penggunaan yang Anda proyeksikan.

Langkah selanjutnya

• Pelajari cara men-deploy alat Autoscaler dalam topologi per project atau terpusat.
• Pelajari cara men-deploy alat Autoscaler dalam topologi terdistribusi.
• Baca selengkapnya tentang nilai minimum yang direkomendasikan Spanner
• Baca selengkapnya tentang metrik penggunaan CPU dan metrik latensi Spanner
• Pelajari praktik terbaik untuk desain skema Spanner untuk menghindari hotspot dan memuat data ke Spanner.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.