Rasio permintaan dan pedoman distribusi akses

Google Cloud Storage adalah layanan yang sangat skalabel, yang menggunakan teknologi penskalaan otomatis untuk mencapai rasio permintaan yang sangat tinggi. Halaman ini menguraikan panduan untuk mengoptimalkan penskalaan dan performa yang disediakan Cloud Storage.

Penskalaan Otomatis

Cloud Storage adalah layanan multi-tenant, yang berarti pengguna memiliki set resource dasar yang sama. Untuk mengoptimalkan penggunaan resource bersama ini, bucket memiliki kapasitas IO awal sebesar:

  • Sekitar 1.000 permintaan tulis objek per detik, yang mencakup mengupload, mengupdate, dan menghapus objek. Perlu diperhatikan bahwa Cloud Storage juga memiliki batas yang lebih kecil untuk penulisan berulang ke nama objek yang sama.
  • Sekitar 5.000 permintaan baca objek per detik, yang mencakup pencantuman objek, data objek pembacaan, dan metadata objek pembacaan.

Kecepatan baca dan tulis awal ini rata-rata mencapai 2,5 PB untuk operasi tulis dan 13 PB dalam sebulan untuk objek 1 MB. Seiring bertambahnya rasio permintaan untuk bucket tertentu, Cloud Storage akan melakukan penskalaan otomatis dan secara otomatis meningkatkan kapasitas IO untuk bucket tersebut dengan mendistribusikan beban permintaan ke beberapa server.

Waktu distribusi ulang beban

Saat bucket mendekati batas kapasitas IO-nya, Cloud Storage biasanya memerlukan beberapa menit untuk mendeteksi dan mendistribusikan ulang beban ke lebih banyak server. Akibatnya, jika rasio permintaan di bucket Anda meningkat lebih cepat daripada pendistribusian ulang yang dapat dilakukan Cloud Storage, Anda mungkin akan mencapai batas sementara, khususnya tingkat error dan latensi yang lebih tinggi. Meningkatkan kecepatan permintaan secara bertahap untuk bucket Anda, seperti yang dijelaskan di bawah, akan menghindari latensi dan error tersebut.

Pengindeksan kunci objek

Cloud Storage mendukung pencantuman objek yang konsisten, sehingga pengguna dapat menjalankan alur kerja pemrosesan data dengan mudah di Cloud Storage. Agar dapat menyediakan pencantuman objek yang konsisten, Cloud Storage mempertahankan indeks kunci objek untuk setiap bucket. Indeks ini disimpan dalam urutan leksikografis dan diperbarui setiap kali objek ditulis ke atau dihapus dari bucket. Menambahkan dan menghapus objek yang semua kuncinya ada dalam rentang kecil indeks secara alami akan meningkatkan peluang pertentangan.

Cloud Storage mendeteksi pertentangan tersebut, yang juga dikenal sebagai hotspotting, dan secara otomatis mendistribusikan ulang beban pada rentang indeks yang terpengaruh di beberapa server. Serupa dengan menskalakan kapasitas IO bucket, saat mengakses rentang indeks baru, misalnya saat menulis objek dengan awalan baru, Anda harus meningkatkan rasio permintaan secara bertahap, seperti yang dijelaskan di bawah. Jika hal ini tidak dilakukan, akan terjadi latensi dan tingkat error yang lebih tinggi untuk sementara waktu.

Praktik terbaik

Bagian berikut memberikan praktik terbaik tentang cara meningkatkan rasio permintaan, memilih kunci objek, dan mendistribusikan permintaan untuk menghindari batas sementara pada bucket Anda. Perlu diperhatikan bahwa selain pertimbangan per bucket ini, ada juga batas bandwidth gabungan yang berlaku untuk bucket yang terletak di lokasi dan project yang sama.

Meningkatkan rasio permintaan secara bertahap

Untuk memastikan penskalaan otomatis Cloud Storage selalu memberikan performa terbaik, Anda harus meningkatkan rasio permintaan secara bertahap untuk setiap bucket yang belum memiliki rasio permintaan tinggi dalam beberapa hari atau yang memiliki rentang baru kunci objek. Jika rasio permintaan Anda kurang dari 1.000 permintaan tulis per detik atau 5.000 permintaan baca per detik, peningkatan tidak diperlukan. Jika rasio permintaan Anda diperkirakan akan melebihi nilai minimum ini, Anda harus memulai dengan rasio permintaan di bawah atau mendekati nilai minimum tersebut, lalu secara bertahap meningkatkan rasio tersebut tidak lebih cepat daripada menggandakan rasio selama periode 20 menit.

Jika Anda mengalami masalah seperti peningkatan latensi atau tingkat error, jeda peningkatan atau kurangi rasio permintaan untuk sementara waktu agar Cloud Storage memiliki lebih banyak waktu untuk menskalakan bucket Anda. Anda harus mencoba lagi permintaan dengan backoff eksponensial jika:

  • Menerima error dengan kode respons 408 dan 429.
  • Menerima error dengan kode respons 5xx.

Bucket dengan namespace hierarkis yang diaktifkan menawarkan batas Kueri per detik (QPS) awal hingga 8 kali lebih tinggi untuk membaca dan menulis objek dibandingkan dengan bucket tanpa namespace hierarkis yang diaktifkan. QPS awal yang lebih tinggi memudahkan penskalaan beban kerja yang memerlukan banyak data dan memberikan throughput yang lebih baik. Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan namespace hierarkis di bucket, lihat Membuat bucket dengan namespace hierarkis yang diaktifkan.

Menggunakan konvensi pemberian nama yang mendistribusikan pemuatan secara merata di seluruh rentang kunci

Penskalaan otomatis rentang indeks dapat diperlambat saat menggunakan nama berurutan, seperti kunci objek berdasarkan urutan angka atau stempel waktu. Hal ini terjadi karena permintaan terus bergeser ke rentang indeks baru, sehingga mendistribusikan ulang beban menjadi lebih sulit dan kurang efektif.

Untuk mempertahankan rasio permintaan yang tinggi, hindari penggunaan nama berurutan. Menggunakan nama objek yang benar-benar acak memberi Anda distribusi pemuatan terbaik. Jika Anda ingin menggunakan nomor urut atau stempel waktu sebagai bagian dari nama objek, terapkan pengacakan pada nama objek dengan menambahkan nilai hash sebelum nomor urut atau stempel waktu.

Misalnya, jika nama objek asli yang ingin Anda gunakan adalah:

my-bucket/2016-05-10-12-00-00/file1
my-bucket/2016-05-10-12-00-00/file2
my-bucket/2016-05-10-12-00-01/file3
...

Anda dapat menghitung hash MD5 nama objek asli dan menambahkan 6 karakter pertama hash sebagai awalan pada nama objek. Nama objek baru menjadi:

my-bucket/2fa764-2016-05-10-12-00-00/file1
my-bucket/5ca42c-2016-05-10-12-00-00/file2
my-bucket/6e9b84-2016-05-10-12-00-01/file3
...

Awalan acak yang lebih panjang memberikan penskalaan otomatis yang lebih efektif saat meningkatkan kecepatan baca dan tulis yang sangat tinggi. Misalnya, awalan 1 karakter yang menggunakan nilai hex acak akan memberikan penskalaan otomatis yang efektif dari operasi baca/tulis awal 5.000/1.000 per detik hingga sekitar 80.000/16.000 baca/tulis per detik, karena awalan memiliki 16 nilai potensial. Jika kasus penggunaan Anda tidak memerlukan tarif yang lebih tinggi dari ini, awalan acak 1 karakter sama efektifnya dalam meningkatkan rasio permintaan dengan 2 karakter atau awalan acak yang lebih panjang.

Pengacakan setelah awalan umum berlaku efektif di bawah awalan

Perlu diperhatikan bahwa string acak tidak harus berada di awal nama objek. Penambahan string acak setelah awalan umum tetap memungkinkan penskalaan otomatis berfungsi, tetapi efeknya terbatas pada awalan tersebut, tanpa mempertimbangkan bucket lainnya.

Contoh:

my-bucket/images/animals/4ce4c6af-6d27-4fa3-8a91-5701a8552705/1.jpg
my-bucket/images/animals/9a495e72-1d85-4637-a243-cbf3e4a90ae7/2.jpg
...
my-bucket/images/landscape/585356ac-ce89-47a8-bdd2-78a86b58fee6/1.jpg
my-bucket/images/landscape/2550ae5b-395e-4243-a29b-bbf5aece60ef/2.jpg
...
my-bucket/images/clouds/1.jpg
my-bucket/images/clouds/2.jpg
...

Penamaan di atas memungkinkan penskalaan otomatis objek yang efisien dalam images/animals dan images/landscape,, tetapi tidak images/clouds.

Pengacakan setelah awalan berurutan tidak seefektif

Seperti yang disebutkan di atas, menggunakan string acak setelah awalan umum hanya akan membantu penskalaan otomatis berdasarkan awalan tersebut. Setelah permintaan beralih ke awalan baru, Anda mungkin tidak lagi mendapatkan manfaat dari efek penskalaan otomatis sebelumnya. Hal ini terutama menjadi masalah ketika awalan mengikuti pola berurutan.

Misalnya, jika Anda menulis file dengan awalan berbasis stempel waktu yang baru setiap jam:

my-bucket/2016-05-10-00/cf9a7b95-0d2e-4466-9596-840ff388ddbd
my-bucket/2016-05-10-00/f1e16a88-16b8-4c66-ba66-a225c87be80c
my-bucket/2016-05-10-00/646d8272-4a88-4dc2-b2d4-d537c778df41
...
my-bucket/2016-05-10-01/bdcba6de-ac25-4c27-8550-0d08f249e69d
my-bucket/2016-05-10-01/a32c867c-09a9-4d65-9668-ddd4ebe4138b
my-bucket/2016-05-10-01/d619485c-5243-4a4e-8ef3-0f7e1d26ce1d
...

Meskipun penskalaan otomatis membantu meningkatkan kecepatan tulis di bawah awalan dari waktu ke waktu, kecepatan operasi tulis akan direset di awal setiap jam. Hal ini menghasilkan kecepatan tulis yang kurang optimal serta peningkatan latensi dan tingkat error secara berkala. Jika Anda perlu menulis ke awalan yang berbeda dari waktu ke waktu, untuk menghindari masalah ini, pastikan awalan baru tersebut didistribusikan secara merata di seluruh rentang kunci.

Urutkan ulang operasi massal untuk mendistribusikan beban secara merata di seluruh rentang kunci

Terkadang, Anda mungkin ingin melakukan upload atau penghapusan data secara massal di Cloud Storage. Dalam kedua kasus tersebut, Anda mungkin tidak memiliki kontrol atas nama objek. Meskipun demikian, Anda dapat mengontrol urutan upload atau penghapusan objek untuk mencapai tingkat penulisan atau penghapusan setinggi mungkin.

Untuk melakukannya, Anda harus mendistribusikan upload atau penghapusan ke beberapa awalan. Misalnya, jika Anda memiliki banyak folder dan banyak file dalam setiap folder yang akan diupload, strategi yang baik adalah mengupload dari beberapa folder secara paralel dan secara acak memilih folder serta file mana yang diupload. Dengan demikian, sistem dapat mendistribusikan beban secara lebih merata di seluruh rentang kunci, sehingga Anda dapat mencapai rasio permintaan yang tinggi setelah peningkatan awal.

Langkah berikutnya