Men-deploy alat Autoscaler ke fungsi Cloud Run

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.

Dokumen ini adalah bagian dari rangkaian yang juga mencakup:

Seri ini ditujukan untuk tim IT, Operasi, dan Site Reliability Engineering (SRE) yang ingin mengurangi overhead operasional dan mengoptimalkan biaya penempatan Spanner.

Halaman ini memperkenalkan tiga cara untuk men-deploy Autoscaler ke fungsi Cloud Run, sesuai dengan persyaratan Anda:

  • Topologi deployment per project. Infrastruktur Autoscaler di-deploy dalam project yang sama dengan Spanner yang perlu diskalakan otomatis. Sebaiknya gunakan topologi ini untuk tim independen yang ingin mengelola konfigurasi dan infrastruktur Autoscaler mereka sendiri. Topologi deployment per project juga merupakan titik awal yang baik untuk menguji kemampuan Autoscaler.
  • Topologi deployment terpusat. Alat Autoscaler di-deploy di satu project dan mengelola satu atau beberapa instance Spanner di project yang berbeda. Kami merekomendasikan topologi ini untuk tim yang mengelola konfigurasi dan infrastruktur satu atau beberapa instance Spanner sekaligus menyimpan komponen dan konfigurasi untuk Autoscaler di tempat terpusat. Dalam topologi terpusat, selain project Autoscaler, Anda menyiapkan project kedua, yang dalam tutorial ini disebut sebagai Project aplikasi. Project Aplikasi menyimpan resource aplikasi, termasuk Spanner.
  • Topologi deployment terdistribusi. Sebagian besar infrastruktur Autoscaler di-deploy di satu project, tetapi beberapa komponen infrastruktur di-deploy dengan instance Spanner yang diskalakan secara otomatis di project yang berbeda. Kami merekomendasikan topologi ini untuk organisasi dengan beberapa tim, dengan tim yang memiliki instance Spanner hanya ingin mengelola parameter konfigurasi Autoscaler untuk instance mereka, tetapi infrastruktur Autoscaler lainnya dikelola oleh tim pusat.

Serverless untuk kemudahan deployment dan pengelolaan

Dalam model ini, alat Autoscaler hanya dibuat menggunakan alat Google Cloud pengelolaan rendah dan serverless, 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 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": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "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.

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 konseptual.

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.

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 panduan langkah demi langkah untuk deployment per project.

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 project terpusat konseptual.

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.

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 mempelajari cara menyiapkan Autoscaler menggunakan topologi terpusat, lihat panduan langkah demi langkah untuk deployment terpusat.

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 project terdistribusi konseptual.

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) berada di project Aplikasi 1 dan Aplikasi 2.
  • Komponen Cloud Scheduler independen (C) di-deploy ke setiap project: Aplikasi 1 dan Aplikasi 2.
  • Komponen Autoscaler lainnya (B) di-deploy ke project terpisah.
  • Alat Autoscaler menskalakan instance Spanner secara otomatis di project Application 1 dan Application 2 menggunakan konfigurasi yang dikirim oleh komponen Cloud Scheduler independen di setiap project.

Fungsi forwarder

Cloud Scheduler hanya dapat memublikasikan pesan ke topik dalam project yang sama, jadi untuk topologi terdistribusi, diperlukan komponen perantara yang disebut fungsi Forwarder.

Fungsi Forwarder mengambil pesan yang dipublikasikan ke Pub/Sub dari Cloud Scheduler, memeriksa sintaksis JSON-nya, dan meneruskannya ke topik Pub/Sub Poller. Topik dapat berasal dari project terpisah dari Cloud Scheduler.

Diagram berikut menunjukkan komponen yang digunakan untuk mekanisme penerusan:

Mekanisme penerusan.

Seperti yang ditunjukkan pada diagram sebelumnya, instance Spanner berada dalam project yang bernama Application 1 dan Application 2:

  1. Cloud Scheduler adalah project yang sama dengan instance Spanner.

  2. (2a) Cloud Scheduler memublikasikan pesannya ke topik Forwarder dalam project Aplikasi 1 dan Aplikasi 2.

    (2b) Fungsi Forwarder membaca pesan dari topik Forwarder.

    (2c) Fungsi Forwarder meneruskan pesan ke topik Polling yang berada di project Autoscaler.

  3. Fungsi Poller membaca pesan dari topik polling dan proses berlanjut, seperti yang dijelaskan di bagian Poller.

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 kontrol yang lebih besar terhadap 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 Autoscaler menggunakan topologi terdistribusi, lihat panduan langkah demi langkah untuk deployment terdistribusi.

Langkah berikutnya