Panduan sharding Pengontrol Konfigurasi

Dokumen ini berisi rekomendasi tentang cara melakukan sharding penggunaan Pengontrol Konfigurasi. Sharding adalah proses pemisahan resource Google Cloud yang dikelola Pengontrol Konfigurasi ke beberapa namespace, cluster, atau project.

Dengan sharding, Anda dapat:

  • Mengurangi dampak perubahan: Jika satu shard berhenti berfungsi, shard lainnya tidak akan terpengaruh.
  • Membantu Anda mengelola keamanan: Setiap shard dapat memiliki konfigurasi IAM dan RBAC khusus. Penyerang berbahaya yang menyusupi satu shard tidak dapat mengakses sharding lainnya. Kesalahan konfigurasi dalam satu shard tidak dapat memengaruhi shard lainnya.
  • Skalabilitas yang lebih baik: Satu shard dapat memiliki bottleneck skalabilitas, seperti jumlah objek terkelola atau kuota API. Memiliki beberapa shard akan meningkatkan skalabilitas penggunaan Pengontrol Konfigurasi Anda secara keseluruhan.

Menggunakan sharding dengan Pengontrol Konfigurasi

Ada beberapa cara untuk menerapkan sharding. Pendekatan terbaik untuk Anda akan bergantung pada kebutuhan dan persyaratan spesifik Anda.

Model sharding

Ada dua model sharding utama:

  • Menurut lini bisnis atau tim aplikasi: Model ini biasanya digunakan saat Pengontrol Konfigurasi digunakan oleh tim yang berbeda. Dalam model ini, setiap tim memiliki shard-nya sendiri.
  • Menurut lingkungan: Model ini biasanya digunakan saat Pengontrol Konfigurasi digunakan di lingkungan yang berbeda. Misalnya, Anda mungkin memiliki shard untuk lingkungan pengembangan, shard untuk lingkungan UM (Uji Mutu) Anda, dan shard untuk lingkungan produksi.

Meminimalkan kebutuhan akan referensi lintas sharding

Saat melakukan sharding penggunaan Pengontrol Konfigurasi, Anda harus meminimalkan kebutuhan akan referensi lintas sharding. Referensi lintas shard dapat membuat konfigurasi Anda lebih kompleks dan sulit dikelola. Baca Referensi resource di berbagai instance untuk mengetahui detail selengkapnya.

Mekanisme sharding

Ada tiga mekanisme sharding utama:

Peringatan saat menerapkan sharding

Saat menerapkan sharding untuk penggunaan Pengontrol Konfigurasi, ada beberapa potensi masalah yang harus Anda ketahui dan rencanakan untuk memitigasinya.

Referensi resource di berbagai instance

Salah satu tantangan melakukan sharding Pengontrol Konfigurasi adalah menangani referensi resource di seluruh instance. Misalnya, tim platform dapat membuat Project dalam satu instance, lalu tim aplikasi dapat membuat resource yang merujuk ke Project tersebut dalam instance lain. Hal ini dapat menimbulkan masalah seperti:

  • Kompleksitas yang meningkat: Mengelola referensi resource di seluruh cluster dapat membuat konfigurasi Anda lebih kompleks dan sulit dikelola.
  • Peningkatan risiko: Jika resource dihapus dalam satu shard, resource tersebut masih dapat direferensikan oleh resource dalam shard lain. Hal ini dapat menyebabkan perilaku dan kehilangan data yang tidak terduga.
  • Degradasi performa: Referensi resource di seluruh cluster dapat meningkatkan latensi perubahan konfigurasi Anda.

Ada beberapa cara untuk mengatasi tantangan referensi silang:

  • Sharding dengan cara yang tidak memerlukan referensi lintas shard. Hal ini dapat dilakukan dengan melakukan sharding berdasarkan lingkungan atau tim.
  • Menggunakan referensi eksternal. Artinya, objek yang sedang dirujuk tidak sebenarnya dikelola oleh Pengontrol Konfigurasi. Ini bisa menjadi opsi yang bagus jika objek tidak sering berubah.
  • Memiliki objek yang sama di semua shard. Ini adalah opsi yang lebih kompleks, tetapi dapat menjadi opsi terbaik jika objek sering berubah. Objek tersebut harus memiliki sumber kebenaran yang sama untuk menghindari pertengkaran rekonsiliasi antara objek ini dalam shard yang berbeda. Anda harus menetapkan kebijakan pencegahan konflik ke none untuk objek ini.

Penting untuk mempertimbangkan dengan cermat kelebihan dan kekurangan setiap pendekatan sebelum memilih salah satu.

Kuota API

Sharding dapat meningkatkan kuota API Anda. Anda harus mengetahui hal ini dan membuat rencana yang sesuai. Lihat artikel Mengelola batas kuota API untuk mengetahui praktik terbaik dalam mengelola batas kuota API.

Langkah selanjutnya