Daftar periksa performa dan skalabilitas untuk penyimpanan Blob
Microsoft telah mengembangkan sejumlah praktik yang terbukti untuk mengembangkan aplikasi dengan performa tinggi dengan penyimpanan Blob. Daftar periksa ini mengidentifikasi kunci praktik yang dapat diikuti pengembang untuk mengoptimalkan performa. Ingatlah praktik ini saat Anda merancang aplikasi dan sepanjang proses.
Azure Storage memiliki skalabilitas dan target performa untuk kapasitas, kecepatan transaksi, dan bandwidth. Untuk informasi selengkapnya tentang target skalabilitas Azure Storage, lihat Skalabilitas dan target performa untuk akun penyimpanan standar dan Skalabilitas dan target performa untuk penyimpanan Blob.
Daftar periksa
Artikel ini mengatur praktik yang terbukti untuk performa ke dalam daftar periksa yang dapat Anda ikuti saat mengembangkan aplikasi penyimpanan Blob Anda.
Target skalabilitas
Jika aplikasi Anda mendekati atau melebihi target skalabilitas apa pun, aplikasi mungkin mengalami peningkatan latensi atau pembatasan transaksi. Ketika Azure Storage membatasi aplikasi Anda, layanan tersebut mulai mengembalikan kode galat 503 (Server sibuk) atau 500 (Waktu habis operasi). Menghindari kesalahan ini dengan tetap berada dalam batas target skalabilitas adalah bagian penting untuk meningkatkan performa aplikasi Anda.
Untuk informasi lebih lanjut tentang target skalabilitas untuk layanan Antrean, lihat Skalabilitas dan target performa Azure Storage.
Jumlah akun penyimpanan maksimum
Jika Anda mendekati jumlah maksimum akun penyimpanan yang diizinkan untuk kombinasi langganan/wilayah tertentu, evaluasi skenario Anda dan tentukan apakah salah satu kondisi berikut ini berlaku:
- Apakah Anda menggunakan akun penyimpanan untuk menyimpan disk yang tidak dikelola dan menambahkan disk tersebut ke komputer virtual (VM) Anda? Untuk skenario ini, Microsoft merekomendasikan penggunaan disk terkelola. Disk terkelola yang diskalakan untuk Anda secara otomatis dan tanpa perlu membuat dan mengelola akun penyimpanan individual. Untuk informasi selengkapnya, lihat Pengantar disk yang dikelola Azure
- Apakah Anda menggunakan satu akun penyimpanan per pelanggan, untuk tujuan isolasi data? Untuk skenario ini, Microsoft merekomendasikan penggunaan kontainer blob untuk setiap pelanggan, bukan seluruh akun penyimpanan. Azure Storage sekarang memungkinkan Anda menetapkan peran Azure berdasarkan per kontainer. Untuk informasi selengkapnya, lihat Menetapkan peran Azure untuk akses ke data blob.
- Apakah Anda menggunakan beberapa akun penyimpanan untuk shard untuk meningkatkan masuk, keluar, operasi I/O per detik (IOPS), atau kapasitas? Dalam skenario ini, Microsoft menyarankan agar Anda memanfaatkan peningkatan batas untuk akun penyimpanan untuk mengurangi jumlah akun penyimpanan yang diperlukan untuk beban kerja Anda jika memungkinkan. Hubungi Dukungan Azure untuk meminta peningkatan batas untuk akun penyimpanan Anda.
Kapasitas dan target transaksi
Jika aplikasi Anda mendekati target skalabilitas untuk satu akun penyimpanan, pertimbangkan untuk mengadopsi salah satu pendekatan berikut:
- Jika aplikasi Anda mencapai target transaksi, pertimbangkan untuk menggunakan akun penyimpanan blob blok, yang dioptimalkan untuk tingkat transaksi tinggi dan latensi rendah serta konsisten. Untuk informasi selengkapnya, lihat Gambaran umum akun penyimpanan Azure.
- Pertimbangkan kembali beban kerja yang menyebabkan aplikasi Anda mendekati atau melebihi target skalabilitas. Dapatkah Anda mendesainnya secara berbeda untuk menggunakan lebih sedikit bandwidth atau kapasitas, atau lebih sedikit transaksi?
- Jika aplikasi Anda harus melebihi salah satu target skalabilitas, maka buat beberapa akun penyimpanan dan partisi data aplikasi Anda di beberapa akun penyimpanan tersebut. Jika Anda menggunakan pola ini, pastikan untuk mendesain aplikasi Anda sehingga Anda dapat menambahkan lebih banyak akun penyimpanan di masa depan untuk penyeimbangan muatan. Akun penyimpanan tidak memiliki biaya selain penggunaan Anda dalam hal data yang disimpan, transaksi yang dilakukan, atau data yang ditransfer.
- Jika aplikasi Anda mendekati target bandwidth, pertimbangkan untuk memadatkan data di pihak klien untuk mengurangi bandwidth yang diperlukan untuk mengirim data ke Azure Storage. Meskipun memadatkan data dapat menghemat bandwidth dan meningkatkan performa jaringan, itu juga dapat berdampak negatif pada performa. Evaluasi dampak performa dari persyaratan pemrosesan tambahan untuk pemadatan dan dekompresi data di pihak klien. Perlu diingat bahwa menyimpan data yang dipadatkan dapat mempersulit pemecahan masalah karena mungkin lebih sulit untuk melihat data dengan menggunakan alat standar.
- Jika aplikasi Anda mendekati target skalabilitas, pastikan Anda menggunakan backoff eksponensial untuk percobaan ulang. Sebaiknya hindari mencapai target skalabilitas dengan menerapkan rekomendasi yang dijelaskan dalam artikel ini. Namun, menggunakan backoff eksponensial untuk percobaan ulang mencegah aplikasi Anda mencoba kembali dengan cepat, yang dapat membuat pembatasan lebih buruk. Untuk informasi selengkapnya, lihat bagian Kesalahan Waktu Habis dan Server Sibuk.
Beberapa klien mengakses satu blob secara bersamaan
Jika Anda memiliki sejumlah besar klien yang mengakses satu blob secara bersamaan, Anda perlu mempertimbangkan target skalabilitas per blob dan per akun penyimpanan. Jumlah pasti klien yang dapat mengakses satu blob bervariasi tergantung pada faktor-faktor seperti jumlah klien yang meminta blob secara bersamaan, ukuran blob, dan kondisi jaringan.
Jika blob dapat didistribusikan melalui CDN seperti gambar atau video yang ditayangkan dari situs web, maka Anda dapat menggunakan CDN. Untuk informasi selengkapnya, lihat bagian berjudul Distribusi konten.
Dalam skenario lain, seperti simulasi ilmiah saat data bersifat rahasia, Anda memiliki dua opsi. Yang pertama adalah terhuyung-huyung akses beban kerja Anda sedemikian rupa sehingga blob diakses selama periode waktu vs diakses secara bersamaan. Atau, Anda dapat menyalin blob untuk sementara ke beberapa akun penyimpanan untuk meningkatkan total IOPS per blob dan di seluruh akun penyimpanan. Hasil bervariasi tergantung pada perilaku aplikasi Anda, jadi pastikan untuk menguji pola konkurensi selama desain.
Bandwidth dan operasi per blob
Blob tunggal mendukung hingga 500 permintaan per detik. Jika Anda memiliki beberapa klien yang perlu membaca blob yang sama dan Anda mungkin melebihi batas ini, maka pertimbangkan untuk menggunakan akun penyimpanan blob blok. Akun penyimpanan blob blok menyediakan tingkat permintaan yang lebih tinggi, atau operasi I/O per detik (IOPS).
Anda juga dapat menggunakan jaringan pengiriman konten (CDN) seperti Azure CDN untuk mendistribusikan operasi pada blob. Untuk informasi selengkapnya tentang Azure CDN, lihat Gambaran umum Azure CDN.
Partisi
Memahami bagaimana Partisi Azure Storage data blob Anda berguna untuk meningkatkan performa. Azure Storage dapat melayani data dalam satu partisi lebih cepat daripada data yang mencakup beberapa partisi. Dengan menamai blob Anda dengan tepat, Anda dapat meningkatkan efisiensi permintaan baca.
Penyimpanan blob menggunakan skema partisi berbasis rentang untuk penskalaan dan penyeimbangan beban. Setiap blob memiliki kunci partisi yang terdiri dari nama blob penuh (account+container+blob). Kunci partisi digunakan untuk membagi data blob ke dalam rentang. Rentang kemudian diseimbangkan beban di seluruh penyimpanan Blob.
Pemartisian berbasis rentang berarti bahwa konvensi penamaan yang menggunakan pengurutan leksikal (misalnya, mypayroll, myperformance, myemployees, dll.) atau tanda waktu (log20160101, log20160102, log20160102, dll.) lebih mungkin mengakibatkan partisi berada di server partisi yang sama sampai peningkatan beban mengharuskan mereka dibagi menjadi rentang yang lebih kecil. Blob pelokasian pada server partisi yang sama meningkatkan performa, jadi bagian penting dari peningkatan performa melibatkan penamaan blob dengan cara yang mengatur mereka paling efektif.
Misalnya, semua blob dalam wadah dapat dilayani oleh satu server sampai beban pada blob ini membutuhkan penyesuaian lebih lanjut dari rentang partisi. Demikian pula, sekelompok akun yang dimuat ringan dengan nama mereka diatur dalam urutan leksikal dapat dilayani oleh satu server sampai beban pada satu atau semua akun ini mengharuskan mereka untuk dibagi di beberapa server partisi.
Setiap operasi penyeimbangan beban dapat memengaruhi latensi panggilan penyimpanan selama operasi. Kemampuan layanan untuk menangani ledakan lalu lintas yang tiba-tiba ke partisi dibatasi oleh skalabilitas server partisi tunggal sampai operasi penyeimbangan beban menendang dan menyeimbangkan kembali rentang kunci partisi.
Anda dapat mengikuti beberapa praktik terbaik untuk mengurangi frekuensi operasi tersebut.
Jika memungkinkan, gunakan ukuran blob atau blok lebih besar dari 256 KiB untuk akun penyimpanan standar dan premium. Ukuran blob atau blok yang lebih besar secara otomatis mengaktifkan blob blok throughput tinggi. Blob blok throughput tinggi memberikan penyerapan performa tinggi yang tidak terpengaruh oleh penamaan partisi.
Periksa konvensi penamaan yang Anda gunakan untuk akun, kontainer, blob, tabel, dan antrean. Pertimbangkan nama prefiks akun, kontainer, atau blob dengan hash tiga digit menggunakan fungsi hashing yang paling sesuai dengan kebutuhan Anda.
Jika Anda mengatur data menggunakan tanda waktu atau pengidentifikasi numerik, pastikan Anda tidak menggunakan pola lalu lintas khusus tambahan (atau prapending). Pola-pola ini tidak cocok untuk sistem partisi berbasis rentang. Pola-pola ini dapat menyebabkan semua lalu lintas masuk ke satu partisi dan membatasi sistem dari keseimbangan beban yang efektif.
Misalnya, jika Anda memiliki operasi harian yang menggunakan blob dengan tanda waktu seperti yyyymmdd, maka semua lalu lintas untuk operasi harian itu diarahkan ke satu blob, yang disajikan oleh satu server partisi. Pertimbangkan apakah batas per blob dan batas per-partisi memenuhi kebutuhan Anda, dan pertimbangkan untuk memecah operasi ini menjadi beberapa blob jika diperlukan. Demikian pula, jika Anda menyimpan data rangkaian waktu di tabel Anda, semua lalu lintas dapat diarahkan ke bagian terakhir ruang nama utama. Jika Anda menggunakan ID numerik, awali ID dengan hash tiga digit. Jika Anda menggunakan tanda waktu, awali tanda waktu dengan nilai detik, misalnya, ssyyymmdd. Jika aplikasi Anda secara rutin melakukan operasi daftar dan kueri, pilih fungsi hashing yang membatasi jumlah kueri Anda. Dalam beberapa kasus, prefiks acak mungkin cukup.
Untuk informasi selengkapnya tentang skema partisi yang digunakan di Azure Storage, lihat Azure Storage: Layanan Penyimpanan Cloud yang Sangat Tersedia dengan Konsistensi Yang Kuat.
Jaringan
Batasan jaringan fisik dari aplikasi mungkin berdampak signifikan pada performa. Bagian berikut menjelaskan beberapa batasan yang mungkin ditemui pengguna.
Kemampuan jaringan klien
Bandwidth dan kualitas tautan jaringan berperan penting dalam performa aplikasi, seperti yang dijelaskan di bagian berikut.
Throughput
Untuk bandwidth, masalahnya sering kali pada kemampuan klien. Instans Azure yang lebih besar memiliki NIC dengan kapasitas yang lebih besar, jadi Anda harus mempertimbangkan menggunakan instans yang lebih besar atau lebih banyak VM jika Anda memerlukan batas jaringan yang lebih tinggi dari satu komputer. Jika Anda mengakses Azure Storage dari aplikasi lokal, aturan yang sama berlaku: pahami kemampuan jaringan perangkat klien dan konektivitas jaringan ke lokasi Azure Storage dan tingkatkan sesuai kebutuhan atau desain aplikasi Anda agar berfungsi dalam kemampuannya.
Kualitas tautan
Seperti halnya penggunaan jaringan apa pun, perlu diingat bahwa kondisi jaringan yang mengakibatkan kesalahan dan kehilangan paket memperlambat throughput yang efektif. Menggunakan WireShark atau NetMon dapat membantu dalam mendiagnosis masalah ini.
Lokasi
Dalam lingkungan terdistribusi apa pun, menempatkan klien di dekat server memberikan performa terbaik. Untuk mengakses Azure Storage dengan latensi terendah, lokasi terbaik untuk klien Anda berada dalam wilayah Azure yang sama. Misalnya, jika Anda memiliki aplikasi web Azure yang menggunakan Azure Storage, temukan keduanya dalam satu wilayah, seperti US Barat atau Asia Tenggara. Sumber daya yang berada di lokasi yang sama mengurangi latensi dan biaya, karena penggunaan bandwidth dalam satu wilayah gratis.
Jika aplikasi klien mengakses Azure Storage tetapi tidak dihosting dalam Azure, seperti aplikasi perangkat seluler atau layanan perusahaan lokal, maka menemukan akun penyimpanan di wilayah yang dekat dengan klien tersebut dapat mengurangi latensi. Jika klien Anda tersebar luas (misalnya, beberapa di Amerika Utara, dan beberapa di Eropa), pertimbangkan untuk menggunakan satu akun penyimpanan per wilayah. Pendekatan ini lebih mudah diterapkan jika data yang disimpan aplikasi khusus untuk pengguna individual, dan tidak memerlukan replikasi data antar akun penyimpanan.
Untuk distribusi konten blob yang luas, gunakan jaringan pengiriman konten seperti Azure CDN. Untuk informasi selengkapnya tentang Azure CDN, lihat Azure CDN.
SAS dan CORS
Misalkan Anda perlu memberikan otorisasi kode seperti JavaScript yang berjalan di browser web pengguna atau di aplikasi ponsel untuk mengakses data di Azure Storage. Salah satu pendekatannya adalah dengan membangun aplikasi layanan yang bertindak sebagai proksi. Perangkat pengguna mengautentikasi dengan layanan, yang pada gilirannya memberikan otorisasi akses ke sumber daya Azure Storage. Dengan cara ini, Anda dapat menghindari mengekspos kunci akun penyimpanan Anda di perangkat yang tidak aman. Namun, pendekatan ini menempatkan overhead yang signifikan pada aplikasi layanan, karena semua data yang ditransfer antara perangkat pengguna dan Azure Storage harus melewati aplikasi layanan.
Anda dapat menghindari penggunaan aplikasi layanan sebagai proksi untuk Azure Storage dengan menggunakan tanda tangan akses bersama (SAS). Dengan menggunakan SAS, Anda dapat mengaktifkan perangkat pengguna untuk membuat permintaan langsung ke Azure Storage dengan menggunakan token akses terbatas. Misalnya, jika pengguna ingin mengunggah foto ke aplikasi Anda, maka aplikasi layanan Anda dapat menghasilkan SAS dan mengirimkannya ke perangkat pengguna. Token SAS dapat memberikan izin untuk menulis ke sumber daya Azure Storage untuk interval waktu tertentu, setelah itu token SAS kedaluwarsa. Untuk informasi selengkapnya tentang SAS, lihat Memberikan akses terbatas ke sumber daya Azure Storage dengan menggunakan tanda tangan akses bersama (SAS).
Biasanya, browser web tidak mengizinkan JavaScript di halaman yang dihosting oleh situs web di satu domain untuk melakukan operasi tertentu, seperti operasi tulis, ke domain lain. Dikenal sebagai kebijakan asal yang sama, kebijakan ini mencegah skrip berbahaya di satu halaman untuk mendapatkan akses ke data di halaman web lain. Namun, kebijakan asal yang sama dapat menjadi batasan saat membangun solusi di cloud. Berbagi sumber daya lintas asal (CORS) adalah fitur browser yang memungkinkan domain target untuk berkomunikasi dengan browser yang mempercayai permintaan berasal dari domain sumber.
Misalnya, aplikasi web yang berjalan di Azure membuat permintaan sumber daya ke akun Azure Storage. Aplikasi web adalah domain sumber, dan akun penyimpanan adalah domain target. Anda dapat mengonfigurasi CORS untuk salah satu layanan Azure Storage untuk berkomunikasi dengan browser web yang permintaan dari domain sumber dipercaya oleh Azure Storage. Untuk informasi lebih lanjut tentang CORS, lihat Dukungan berbagi sumber daya lintas asal (CORS) untuk Azure Storage.
SAS dan CORS dapat membantu Anda menghindari beban yang tidak perlu pada aplikasi web Anda.
penembolokan
Penembolokan memainkan peran penting dalam performa. Bagian berikut membahas praktik terbaik penembolokan.
Membaca data
Secara umum, membaca data sekali lebih disukai untuk membacanya dua kali. Pertimbangkan contoh aplikasi web yang telah mengambil blob 50 MiB dari Azure Storage untuk berfungsi sebagai konten kepada pengguna. Idealnya, aplikasi ini menyimpan blob secara lokal ke disk, lalu mengambil versi tembolokan untuk permintaan pengguna berikutnya.
Salah satu cara untuk menghindari mengambil blob jika belum dimodifikasi sejak penembolokan adalah dengan memenuhi syarat operasi GET dengan header bersyarat untuk waktu modifikasi. Jika waktu terakhir dimodifikasi adalah setelah waktu blob ditembolokkan, maka blob diambil dan ditembolokkan ulang. Jika tidak, blob yang ditembolokkan diambil untuk performa optimal.
Anda juga dapat memutuskan untuk merancang aplikasi Anda untuk mengasumsikan bahwa blob tetap tidak berubah untuk jangka pendek setelah mengambilnya. Dalam hal ini, aplikasi tidak perlu memeriksa apakah blob dimodifikasi selama interval tersebut.
Data konfigurasi, data pencarian, dan data lain yang sering digunakan oleh aplikasi adalah kandidat yang baik untuk penembolokan.
Untuk informasi selengkapnya tentang menggunakan header bersyarat, lihat Menentukan header bersyarat untuk operasi Blob service.
Mengunggah data dalam batch
Dalam beberapa skenario, Anda dapat mengagregasi data secara lokal, lalu mengunggahnya secara berkala dalam batch, bukan langsung mengunggah setiap bagian data. Misalnya, katakanlah aplikasi web menyimpan file log aktivitas. Aplikasi dapat mengunggah detail setiap aktivitas saat terjadi pada tabel (yang memerlukan banyak operasi penyimpanan), atau dapat menyimpan detail aktivitas ke file log lokal, lalu secara berkala mengunggah semua detail aktivitas sebagai file yang dibatasi ke blob. Jika setiap entri log berukuran 1 KB, Anda dapat mengunggah ribuan entri dalam satu transaksi. Satu transaksi mendukung pengunggahan blob berukuran hingga 64 MiB. Pengembang aplikasi harus merancang untuk kemungkinan perangkat klien atau kegagalan pengunggahan. Jika data aktivitas perlu diunduh untuk interval waktu dibandingkan untuk satu aktivitas, maka menggunakan penyimpanan Blob disarankan melalui penyimpanan Table.
Konfigurasi .NET
Untuk proyek yang menggunakan .NET Framework, bagian ini mencantumkan beberapa pengaturan konfigurasi cepat yang dapat Anda gunakan untuk melakukan peningkatan performa yang signifikan. Jika Anda menggunakan bahasa selain .NET, periksa untuk melihat apakah konsep serupa berlaku dalam bahasa yang Anda pilih.
Meningkatkan batas koneksi default
Catatan
Bagian ini berlaku untuk proyek yang menggunakan .NET Framework, karena pengumpulan koneksi dikontrol oleh kelas ServicePointManager. .NET Core memperkenalkan perubahan signifikan sekeliling manajemen kumpulan koneksi, di mana pengumpulan koneksi terjadi pada tingkat HttpClient dan ukuran kumpulan tidak dibatasi secara default. Ini berarti bahwa koneksi HTTP secara otomatis diskalakan untuk memenuhi beban kerja Anda. Menggunakan versi terbaru .NET disarankan, jika memungkinkan, untuk memanfaatkan peningkatan performa.
Untuk proyek yang menggunakan .NET Framework, Anda dapat menggunakan kode berikut untuk meningkatkan batas koneksi default (yang biasanya dua di lingkungan klien atau sepuluh di lingkungan server) menjadi 100. Biasanya, Anda harus mengatur nilainya kira-kira sejumlah alur yang digunakan oleh aplikasi Anda. Atur batas koneksi sebelum membuka koneksi apa pun.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Untuk mempelajari selengkapnya tentang batas kumpulan koneksi di .NET Framework, lihat Batas Kumpulan Koneksi .NET Framework dan Azure SDK baru untuk .NET.
Untuk bahasa pemrogram lainnya, lihat dokumentasi untuk menentukan cara mengatur batas koneksi.
Meningkatkan jumlah alur minimum
Jika Anda menggunakan panggilan sinkron bersama dengan tugas asinkron, Anda mungkin ingin meningkatkan jumlah utas di kumpulan utas:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Untuk informasi selengkapnya, lihat metode ThreadPool.SetMinThreads.
Paralelisme tidak terbatas
Meskipun paralelisme bisa sangat bagus untuk performa, berhati-hatilah menggunakan paralelisme yang tidak terbatas, yang berarti bahwa tidak ada batasan yang diberlakukan pada jumlah utas atau permintaan paralel. Pastikan untuk membatasi permintaan paralel untuk mengunggah atau mengunduh data, untuk mengakses beberapa partisi di akun penyimpanan yang sama, atau untuk mengakses beberapa item di partisi yang sama. Jika paralelisme tidak dibatasi, aplikasi Anda dapat melebihi kemampuan perangkat klien atau target skalabilitas akun penyimpanan, yang mengakibatkan keterlambatan dan pembatasan yang lebih lama.
Pustaka dan alat klien
Untuk performa terbaik, selalu gunakan pustaka dan alat klien terbaru yang disediakan oleh Microsoft. Pustaka klien Azure Storage tersedia untuk berbagai bahasa. Azure Storage juga mendukung PowerShell dan Azure CLI. Microsoft secara aktif mengembangkan pustaka dan alat klien ini dengan mempertimbangkan performa, menjaganya tetap mutakhir dengan versi layanan terbaru, dan memastikan bahwa mereka menangani banyak praktik performa yang terbukti secara internal.
Tip
Driver ABFS dirancang untuk mengatasi kekurangan bawaan WASB. Microsoft merekomendasikan penggunaan driver ABFS daripada driver WASB, karena driver ABFS dioptimalkan khusus untuk analitik big data.
Handel kesalahan layanan
Azure Storage mengembalikan kesalahan saat layanan tidak dapat memproses permintaan. Memahami kesalahan yang mungkin dikembalikan oleh Azure Storage dalam skenario tertentu sangat membantu untuk mengoptimalkan performa. Untuk daftar kode kesalahan umum, lihat Kode kesalahan REST API umum.
Kesalahan Waktu Habis dan Server Sibuk
Azure Storage dapat membatasi aplikasi Anda jika mendekati batas skalabilitas. Dalam beberapa kasus, Azure Storage mungkin tidak dapat menangani permintaan karena beberapa kondisi sementara. Dalam kedua kasus, layanan dapat mengembalikan kesalahan 503 (Server Sibuk) atau 500 (Waktu Habis). Kesalahan ini juga dapat terjadi jika layanan menyeimbangkan ulang partisi data untuk memungkinkan throughput yang lebih tinggi. Aplikasi klien biasanya harus mencoba kembali operasi yang menyebabkan salah satu kesalahan ini. Namun, jika Azure Storage membatasi aplikasi Anda karena melebihi target skalabilitas, atau bahkan jika layanan tidak dapat melayani permintaan karena beberapa alasan lain, percobaan ulang yang agresif dapat memperburuk masalah. Disarankan menggunakan kebijakan percobaan kembali back off eksponensial, dan pustaka klien default untuk perilaku ini. Misalnya, aplikasi Anda mungkin mencoba kembali setelah 2 detik, lalu 4 detik, lalu 10 detik, lalu 30 detik, lalu menyerah sepenuhnya. Dengan cara ini, aplikasi Anda secara signifikan mengurangi bebannya pada layanan, daripada memperburuk perilaku yang dapat menyebabkan pembatasan.
Kesalahan konektivitas dapat segera dicoba kembali, karena bukan hasil pembatasan dan diharapkan bersifat sementara.
Kesalahan yang tidak dapat dicoba kembali
Pustaka klien menangani percobaan ulang dengan kesadaran tentang kesalahan mana yang dapat dicoba kembali dan yang tidak dapat dicoba kembali. Namun, jika Anda memanggil Azure Storage REST API secara langsung, ada beberapa kesalahan yang tidak boleh Anda coba lagi. Misalnya, kesalahan 400 (Permintaan Buruk) menunjukkan bahwa aplikasi klien mengirim permintaan yang tidak dapat diproses karena tidak dalam bentuk yang diharapkan. Mengirim ulang permintaan ini menghasilkan respons yang sama setiap kali, sehingga tidak ada gunanya mencobanya kembali. Jika Anda memanggil Azure Storage REST API secara langsung, ketahui potensi kesalahan dan apakah kesalahan tersebut harus dicoba kembali.
Untuk informasi selengkapnya tentang kode galat Azure Storage, lihat Status dan kode galat.
Menyalin dan memindahkan blob
Azure Storage menyediakan sejumlah solusi untuk menyalin dan memindahkan blob dalam akun penyimpanan, antara akun penyimpanan, dan antara sistem lokal dan cloud. Bagian ini menjelaskan beberapa opsi ini dalam hal efeknya pada performa. Untuk informasi tentang mentransfer data secara efisien ke atau dari penyimpanan Blob, lihat Memilih solusi Azure untuk transfer data.
API salinan blob
Untuk menyalin blob di seluruh akun penyimpanan, gunakan operasi Put Block From URL. Operasi ini menyalin data secara sinkron dari sumber URL apa pun ke dalam blob blok. Put Block from URL Menggunakan operasi dapat secara signifikan mengurangi bandwidth yang diperlukan saat Anda memigrasikan data di seluruh akun penyimpanan. Karena operasi penyalinan berlangsung di sisi layanan, Anda tidak perlu mengunduh dan mengunggah ulang data.
Untuk menyalin data dalam akun penyimpanan yang sama, gunakan operasi Copy Blob. Menyalin data dalam akun penyimpanan yang sama biasanya diselesaikan dengan cepat.
Gunakan AzCopy
Utilitas baris perintah AzCopy adalah opsi yang sederhana dan efisien untuk mentransfer blob secara massal ke, dari, dan di seluruh akun penyimpanan. AzCopy dioptimalkan untuk skenario ini, dan dapat mencapai tingkat transfer yang tinggi. AzCopy versi 10 menggunakan operasi Put Block From URL untuk menyalin data blob di seluruh akun penyimpanan. Untuk informasi selengkapnya, lihat Menyalin atau memindahkan data ke Azure Storage dengan menggunakan AzCopy v10.
Menggunakan Azure Data Box
Untuk mengimpor data dalam volume besar ke penyimpanan Blob, pertimbangkan untuk menggunakan keluarga Azure Data Box untuk transfer offline. Perangkat Kotak Data yang disediakan Microsoft adalah pilihan yang baik untuk memindahkan data dalam jumlah besar ke Azure saat Anda dibatasi oleh waktu, ketersediaan jaringan, atau biaya. Untuk informasi selengkapnya, buka Dokumentasi Azure DataBox.
Distribusi konten
Terkadang aplikasi perlu menyajikan konten yang sama kepada banyak pengguna (misalnya, video demo produk yang digunakan di halaman beranda situs web), yang terletak di satu atau beberapa wilayah. Dalam skenario ini, gunakan Content Delivery Network (CDN) seperti Azure Front Door. Azure Front Door adalah CDN cloud modern Microsoft yang menyediakan akses cepat, andal, dan aman antara pengguna Anda dan konten web statis dan dinamis aplikasi Anda di seluruh dunia. Azure Front Door mengirimkan konten Blob Storage Anda menggunakan jaringan tepi global Microsoft dengan ratusan titik kehadiran (PoPs) global dan lokal. CDN biasanya dapat mendukung batas keluar yang jauh lebih tinggi daripada satu akun penyimpanan dan menawarkan latensi yang ditingkatkan untuk pengiriman konten ke regoin lain.
Untuk informasi selengkapnya tentang Azure Front Door, lihat Azure Front Door.
Menggunakan metadata
Blob service mendukung permintaan HEAD, yang dapat mencakup properti blob atau metadata. Misalnya, jika aplikasi Anda memerlukan data Exif (format gambar yang dapat ditukar) dari sebuah foto, aplikasi dapat mengambil foto dan mengekstraknya. Untuk menghemat bandwidth dan meningkatkan performa, aplikasi Anda dapat menyimpan data Exif di metadata blob saat aplikasi mengunggah foto. Anda kemudian dapat mengambil data Exif dalam metadata hanya menggunakan permintaan HEAD. Hanya mengambil metadata dan bukan konten lengkap blob menghemat bandwidth yang signifikan dan mengurangi waktu pemrosesan yang diperlukan untuk mengekstrak data Exif. Perlu diingat bahwa 8 KiB metadata dapat disimpan per blob.
Pembaruan metadata akun dan kontainer
Metadata akun dan kontainer disebarluaskan di seluruh layanan penyimpanan di wilayah tempat akun berada. Penyebaran penuh metadata ini dapat memakan waktu hingga 60 detik tergantung pada operasi. Contohnya:
- Jika Anda dengan cepat membuat, menghapus, dan membuat ulang akun dengan nama akun yang sama di wilayah yang sama, pastikan Anda menunggu 60 detik agar status akun sepenuhnya disebarluaskan, atau permintaan Anda mungkin gagal.
- Saat Anda membuat kebijakan akses tersimpan pada kontainer, kebijakan mungkin memerlukan waktu hingga 30 detik untuk diterapkan.
Penyetelan performa untuk transfer data
Saat aplikasi mentransfer data menggunakan pustaka klien Azure Storage, ada beberapa faktor yang dapat memengaruhi kecepatan, penggunaan memori, dan bahkan keberhasilan atau kegagalan permintaan. Untuk memaksimalkan performa dan keandalan transfer data, penting untuk proaktif dalam mengonfigurasi opsi transfer pustaka klien berdasarkan lingkungan tempat aplikasi Anda berjalan. Untuk mempelajari selengkapnya, lihat Penyetelan performa untuk unggahan dan unduhan.
Mengunggah blob dengan cepat
Untuk mengunggah blob dengan cepat, pertama-tama tentukan apakah Anda mengunggah satu blob atau banyak. Gunakan panduan di bawah ini untuk menentukan metode yang benar untuk digunakan tergantung pada skenario Anda. Jika Anda menggunakan pustaka klien Azure Storage untuk transfer data, lihat Penyetelan performa untuk transfer data untuk panduan lebih lanjut.
Menggunggah satu blob besar dengan cepat
Untuk mengunggah satu blob besar dengan cepat, aplikasi klien dapat mengunggah blok atau halamannya secara paralel, memperhatikan target skalabilitas untuk blob individu dan akun penyimpanan secara keseluruhan. Pustaka klien Azure Storage mendukung pengunggahan secara paralel. Pustaka klien untuk bahasa lain yang didukung menyediakan opsi serupa.
Menggunggah banyak blob dengan cepat
Untuk mengunggah banyak blob dengan cepat, unggah blob secara paralel. Mengunggah secara paralel lebih cepat daripada mengunggah blob satu per satu dengan unggahan blok paralel karena menyebarkan unggahan di beberapa partisi layanan penyimpanan. AzCopy melakukan unggahan secara paralel secara default, dan direkomendasikan untuk skenario ini. Untuk informasi selengkapnya, lihat Mulai menggunakan AzCopy.
Pilih jenis blob yang benar
Azure Storage mendukung blob blok, blob penambahan, dan blob halaman. Untuk skenario penggunaan tertentu, pilihan jenis blob Anda memengaruhi performa dan skalabilitas solusi Anda.
Blob blok sesuai ketika Anda ingin mengunggah data dalam jumlah besar secara efisien. Misalnya, aplikasi klien yang mengunggah foto atau video ke penyimpanan Blob akan menargetkan blob blok.
Blob penambahan mirip dengan blob blok karena terdiri dari blok. Saat Anda memodifikasi blob pelengkap, blok ditambahkan ke akhir blob saja. Blob penambahan berguna untuk skenario seperti pembuatan log, ketika aplikasi perlu menambahkan data ke blob yang ada.
Blob halaman sesuai jika aplikasi perlu melakukan penulisan acak pada data. Misalnya, disk komputer virtual Azure disimpan sebagai blob halaman. Untuk informasi selengkapnya, lihat Memahami blob blok, blob penambahan, dan blob halaman.