Praktik terbaik untuk Cloud Storage

Halaman ini berisi indeks praktik terbaik untuk Cloud Storage. Anda dapat menggunakan informasi yang dikumpulkan di sini sebagai referensi cepat tentang hal-hal yang perlu diingat ketika membangun aplikasi yang menggunakan Cloud Storage.

Jika Anda baru mulai menggunakan Cloud Storage, halaman ini mungkin bukan tempat terbaik untuk memulai, karena tidak mengajarkan dasar-dasar cara menggunakan Cloud Storage. Jika Anda adalah pengguna baru, sebaiknya mulai dengan Menemukan penyimpanan objek dengan Konsol Google Cloud atau Menemukan penyimpanan objek dengan alat gcloud.

Penamaan

Lihat Penamaan bucket dan Penamaan objek untuk mengetahui persyaratan dan pertimbangan nama.

Traffic

  • Lakukan estimasi cepat terkait jumlah traffic yang akan dikirim ke Cloud Storage. Secara khusus, pikirkan tentang:

    • Operasi per detik. Jumlah operasi per detik yang Anda harapkan, untuk bucket dan objek, serta untuk operasi pembuatan, update, dan penghapusan.

    • Bandwidth. Berapa banyak data yang akan dikirim, dalam jangka waktu berapa? Pertimbangkan untuk menggunakan alat seperti Wolfram Alpha untuk menghindari kesalahan dalam perhitungan Anda.

    • Kontrol cache. Menentukan metadata Cache-Control pada objek yang dapat diakses secara publik akan menguntungkan latensi baca pada objek panas atau yang sering diakses. Baca bagian Melihat dan Mengedit Metadata untuk mengetahui petunjuk cara menyetel metadata objek, seperti Cache-Control.

  • Desain aplikasi Anda untuk meminimalkan lonjakan traffic. Jika ada klien aplikasi Anda yang melakukan update, sebarkan aktivitas tersebut sepanjang hari.

  • Saat mendesain aplikasi untuk rasio permintaan yang tinggi, perhatikan pembatasan kapasitas untuk operasi tertentu. Ketahui batas bandwidth untuk jenis traffic keluar tertentu dan ikuti Panduan Distribusi Akses dan Rasio Permintaan. Perhatikan penskalaan otomatis dan kebutuhan untuk meningkatkan rasio permintaan secara bertahap untuk mendapatkan performa terbaik.

  • Saat menangani error:

    • Pastikan aplikasi Anda menggunakan strategi coba lagi untuk menghindari masalah akibat burst traffic yang besar.

    • Coba lagi menggunakan koneksi baru dan mungkin selesaikan ulang nama domain. Hal ini membantu menghindari "kelekatan server", saat percobaan ulang mencoba melalui jalur yang sama dan mencapai komponen tidak responsif yang sama dengan yang dicapai permintaan awal.

  • Jika aplikasi Anda sensitif terhadap latensi, gunakan permintaan yang dilindungi. Dengan permintaan yang dilindungi, Anda dapat mencoba ulang dengan lebih cepat dan mengurangi latensi tail. Hal ini dilakukan tanpa mengurangi batas waktu permintaan, yang dapat menyebabkan waktu habis lebih awal. Untuk informasi selengkapnya, lihat Tail dalam Skala.

  • Pahami tingkat performa yang diharapkan pelanggan dari aplikasi Anda. Informasi ini membantu Anda memilih opsi penyimpanan saat membuat bucket baru.

Lokasi dan opsi penyimpanan data

Lihat topik Kelas penyimpanan dan Lokasi bucket untuk mendapatkan panduan tentang cara terbaik menyimpan data Anda.

ACL dan kontrol akses

  • Permintaan Cloud Storage merujuk pada bucket dan objek berdasarkan namanya. Akibatnya, meskipun ACL mencegah pihak ketiga yang tidak berwenang untuk beroperasi pada bucket atau objek, pihak ketiga dapat mencoba permintaan dengan nama bucket atau objek dan menentukan keberadaannya dengan mengamati respons error. Kemudian, ada kemungkinan informasi dalam bucket atau nama objek bocor. Jika khawatir dengan privasi nama bucket atau objek, Anda harus melakukan tindakan pencegahan yang sesuai, seperti:

    • Memilih nama bucket dan objek yang sulit ditebak. Misalnya, bucket bernama mybucket-gtbytul3 cukup acak sehingga pihak ketiga yang tidak memiliki otorisasi tidak dapat menebaknya dengan mudah atau menghitung nama bucket lain darinya.

    • Menghindari penggunaan informasi sensitif sebagai bagian dari nama bucket atau objek. Misalnya, beri nama somemeaninglesscodename-prod pada bucket, bukan mysecretproject-prodbucket. Di beberapa aplikasi, Anda mungkin ingin menyimpan metadata sensitif di header Cloud Storage kustom seperti x-goog-meta, daripada mengenkode metadata dalam nama objek.

  • Sebaiknya gunakan grup untuk mencantumkan secara eksplisit pengguna dalam jumlah besar. Selain skalanya lebih baik, juga memberikan cara yang sangat efisien untuk memperbarui kontrol akses untuk sejumlah besar objek sekaligus. Terakhir, lebih murah karena Anda tidak perlu membuat permintaan per objek untuk mengubah ACL.

  • Meninjau dan mengikuti praktik terbaik kontrol akses.

  • Sistem kontrol akses Cloud Storage mencakup kemampuan untuk menentukan bahwa objek dapat dibaca oleh publik. Pastikan Anda ingin agar objek apa pun yang Anda tulis dengan izin ini dapat dilihat oleh publik. Setelah "dipublikasikan", data di Internet dapat disalin ke banyak tempat, sehingga secara efektif tidak mungkin untuk mendapatkan kembali kontrol baca atas objek yang ditulis dengan izin ini.

  • Sistem kontrol akses Cloud Storage mencakup kemampuan untuk menentukan bahwa bucket dapat ditulis secara publik. Meskipun mengonfigurasi bucket dengan cara ini dapat digunakan untuk berbagai tujuan, sebaiknya jangan gunakan izin ini. Izin ini dapat disalahgunakan untuk mendistribusikan konten ilegal, virus, dan malware lainnya, serta pemilik bucket secara hukum dan bertanggung jawab secara finansial atas konten yang disimpan di bucket mereka.

    Jika perlu membuat konten tersedia dengan aman bagi pengguna yang tidak memiliki akun pengguna, sebaiknya gunakan URL yang ditandatangani. Misalnya, dengan URL yang ditandatangani, Anda dapat memberikan link ke objek, dan pelanggan aplikasi Anda tidak perlu melakukan autentikasi dengan Cloud Storage untuk mengakses objek tersebut. Saat membuat URL bertanda tangan, Anda mengontrol jenisnya (baca, tulis, hapus) dan durasi akses.

Upload data

  • Jika Anda menggunakan callback XMLHttpRequest (XHR) untuk mendapatkan update progres, jangan menutup dan membuka kembali koneksi jika mendeteksi progres tersebut terhenti. Tindakan ini akan menghasilkan feedback loop positif yang buruk selama periode kemacetan jaringan. Ketika jaringan padat, callback XHR dapat terhambat di balik aktivitas konfirmasi (ACK/NACK) dari aliran upload, serta menutup dan membuka kembali koneksi saat hal ini terjadi akan menggunakan lebih banyak kapasitas jaringan ketika Anda paling tidak mampu.

  • Untuk traffic upload, sebaiknya setel waktu tunggu yang cukup lama. Untuk pengalaman pengguna akhir yang baik, Anda dapat menyetel timer sisi klien yang memperbarui jendela status klien dengan pesan (misalnya, "kemacetan jaringan") saat aplikasi belum menerima callback XHR untuk waktu yang lama. Jangan hanya menutup koneksi dan coba lagi saat ini terjadi.

  • Cara yang mudah dan praktis untuk mengurangi bandwidth yang diperlukan untuk setiap permintaan adalah dengan mengaktifkan kompresi gzip. Meskipun penggunaan CPU tambahan memerlukan waktu untuk mengekstrak hasil, manfaatnya terhadap biaya jaringan biasanya sangat sepadan.

    Objek yang diupload dalam format gzip umumnya juga dapat disajikan dalam format gzip. Namun, hindari mengupload konten yang memiliki content-encoding: gzip dan content-type yang dikompresi karena dapat menyebabkan perilaku yang tidak terduga.

  • Sebaiknya gunakan upload yang dapat dilanjutkan, yang memungkinkan Anda melanjutkan transfer data meskipun kegagalan komunikasi mengganggu aliran data. Anda juga dapat menggunakan upload multibagian XML API untuk mengupload bagian file secara paralel, yang berpotensi mengurangi waktu untuk menyelesaikan upload secara keseluruhan.

Penghapusan data

Lihat Menghapus objek untuk panduan dan pertimbangan dalam menghapus data. Anda juga dapat menggunakan fitur untuk mengontrol siklus proses data guna membantu melindungi data Anda agar tidak dihapus secara keliru oleh pengguna atau software aplikasi.