Menyimpan arsip gambar untuk situs di penyimpanan Azure BLOB

Artikel ini menjelaskan pengalaman mengatur penyimpanan anggaran arsip gambar untuk situs dengan jutaan iklan.



Dalam kasus saya, gambar dipahami sebagai foto apartemen, rumah, plot, dll. Saya memiliki proyek saya sendiri yang merupakan situs dengan iklan untuk penjualan dan penyewaan real estat. Situs ini telah ada selama sekitar 6 tahun dan selama waktu ini sejumlah besar iklan telah terkumpul. Pada setiap kartu objek foto ditampilkan, rata-rata 8 foto per iklan. Sebenarnya, saya akan menyimpan foto-foto ini di cloud sehingga nanti saya bisa menunjukkannya kepada pengunjung di kartu objek.

Bagaimana saya menyimpannya sebelumnya? - tidak mungkin. Saya tidak menyimpan gambar kecuali gambar yang ditempatkan secara manual. Dalam kebanyakan kasus, iklan masuk ke situs melalui mitra melalui unggahan feed otomatis. Dalam umpan untuk setiap objek ada tautan ke foto - saya menyimpan tautan dan memberi pengunjung foto langsung dari mitra. Sirkuit ini berfungsi dengan baik dan menghemat banyak sumber daya.

Foto yang dilihat pengunjung dalam pemilihan iklan atau kartu objek sebenarnya diambil dari sumber daya pihak ketiga.

Ada satu peringatan terkait dengan spesifikasi situs - objek arsip tidak pernah dihapus. Yaitu setelah iklan dihapus dari publikasi, tentu saja menghilang dari hasil pencarian, tetapi tautan langsung selalu tersedia (tanpa kontak penjual). Untuk beberapa waktu, tautan ke foto masih hidup, terkadang selama bertahun-tahun, tetapi cepat atau lambat mereka akan mati. Objek yang diarsipkan sangat berharga karena pengunjung dari mesin pencari terus mendatanginya. Juga, peta harga dibangun dari arsip (saya sudah menulis tentang itu ), dan saya tidak sengaja menemukan sumber pendapatan tambahan untuk proyek dalam bentuk menjual informasi kontak benda-benda arsip. Mengapa mereka membelinya, saya tidak tahu pasti, tetapi saya kira pengunjung ingin mendapatkan kontak karena mereka berpikir bahwa iklan telah dihapus dari publikasi karena kecelakaan atau karena kesalahan. Mungkin juga terjadi bahwa mereka ingin belajar sesuatu dari pemilik sebelumnya. Dengan satu atau lain cara, iklan dengan foto dalam hal ini lebih mungkin untuk dibeli. Nilai foto meningkat setelah kesadaran akan nuansa ini.

Jumlah data yang akan saya simpan di cloud sekitar 3-4 terabyte. Ditambah perolehan harian beberapa gigabytes. Mengingat bahwa inovasi ini tidak akan secara langsung menghasilkan uang, itu hanya dapat secara tidak langsung mempengaruhi pengambilan keputusan oleh pengunjung, anggaran di mana saya ingin bertemu dengan yang sangat sederhana adalah 1000-2000 r. per bulan. Akan menyenangkan sekali gratis, tetapi saya tidak menemukan kesempatan seperti itu.

Azure

Saya entah bagaimana segera melihat ke arah Azure karena saya bekerja di .net, dan sering melihat artikel iklan yang indah tentang topik ini. Plus, saya harus menggunakan platform ini untuk pekerjaan utama saya, tetapi di sana kemampuan saya dibatasi oleh persyaratan bisnis dan keinginan manajemen.

Azure menawarkan penyimpanan BLOB dengan tiga tingkatan penyimpanan: Panas, Dingin, dan Arsip. Harga di semua level berbeda. Secara umum, semakin panas semakin murah membaca / menulis dan semakin mahal biaya penyimpanan bulanan, dan sebaliknya. On Hot - bermanfaat untuk menulis / membaca dan menghapus banyak, tetapi mahal untuk menyimpannya untuk waktu yang lama. Arsip murah untuk disimpan tetapi mahal untuk membaca / menulis. Juga, pada tingkat arsip dan dingin, ada biaya untuk penghapusan awal - ini berarti bahwa jika saya menghapus (atau mentransfer ke tingkat lain) suatu objek lebih awal dari periode tertentu, maka saya masih akan dikenakan biaya untuk seluruh periode. Untuk tingkat arsip, ini adalah 180 hari, untuk dingin - 30.

Harga

Biaya penyimpanan adalah $ 0,0023 per GB per bulan di tingkat arsip, $ 0,01 pada dingin dan $ 0,0196 pada panas. Pada tingkat saat ini, ini adalah sekitar 0,15, 0,65 dan 1,28 rubel, masing-masing.

Saya membandingkannya dengan biaya di Amazon dan Google, ternyata Azure lebih murah.

	Azure	Amazon (S3)	Google
Panas	$ 0,0196	$ 0,024	$ 0,026
Keren	$ 0,01	$ 0,01	$ 0,01
Arsipkan	$ 0,0023	$ 0,0045	$ 0,007

Selain biaya penyimpanan, perlu untuk memperhitungkan biaya operasi - mereka juga berbeda di semua tingkatan. Harga berlaku untuk 10.000 transaksi.

Panas
Baca: $ 0,0043, Tulis: $ 0,054

Keren
Baca: $ 0,01, Tulis: $ 0,10

Arsipkan
Baca: $ 6, Tulis: $ 0,12

Logika kerja

Saat iklan aktif, foto di dalamnya ditampilkan oleh tautan dari sumber pihak ketiga (dari mitra). Setelah pengumuman dihapus dari publikasi, itu menjadi arsip, tetapi tautan ke foto masih hidup untuk beberapa waktu. Cepat atau lambat, mereka mati, dan Anda perlu memastikan bahwa saat ini sudah ada salinan arsip.

Proses pemrosesan foto dapat dijelaskan dalam langkah-langkah berikut:

1. Segera setelah iklan menghilang dari file impor mitra, mis. mitra berhenti mempublikasikannya, sebuah entri terbentuk dalam antrian prioritas, di mana prioritasnya adalah jumlah tampilan oleh pengunjung - semakin banyak tampilan, semakin besar kemungkinan arsip diarsipkan, objek akan dilihat lebih lanjut.
2. Saat memproses catatan dari antrian, objek BLOB terbentuk berisi foto yang berkurang (hingga 800x600) untuk iklan. Penggunaan objek komposit daripada foto langsung juga karena penghematan - alih-alih 8 operasi perekaman (rata-rata 8 foto per objek), satu dilakukan, dan setiap operasi membutuhkan biaya.
3. BLOB dimuat pertama kali di Hot, dan kemudian segera ditransfer ke arsip. Tidak ada kemungkinan untuk menulis langsung ke arsip, dan karena Cool memiliki biaya untuk penghapusan awal, lebih murah untuk menggunakan Hot sebagai transit.
4. Arsip BLOB selama tautan ke foto asli aktif (foto sejauh ini ditunjukkan oleh tautan dari mitra).
5. Tautan diperiksa untuk fungsionalitas ketika pengunjung mengunjungi kartu objek - jika mereka pergi ke sana, maka objek tersebut populer dan masuk akal untuk mengembalikan foto dari arsip.
6. Jika tautan ke foto asli telah mati, saya memeriksa apakah ada salinan arsip, dan jika demikian, saya mengirim permintaan untuk memulihkan dari arsip ke Dingin (mungkin diperlukan hingga 15 jam untuk mengembalikan gumpalan dari arsip - ini disebut rehidrasi dari Microsoft).
7. Setelah BLOB telah dipulihkan dari arsip, itu disalin ke penyimpanan lokal dan dibagi menjadi foto normal. Penyimpanan lokal adalah hard drive server saya.
8. Foto pada kartu pengumuman sudah diberikan dari penyimpanan lokal.
9. Foto disimpan di penyimpanan lokal selama beberapa hari. Jika selama ini ada pemindaian, periode penyimpanan lokal diperpanjang. Jika tidak ada tampilan, foto akan dihapus dari penyimpanan lokal, tetapi tetap pada level Cool di Azure.
10. Dari Cool ke Archive mereka disalin jika tidak ada tampilan selama dua bulan - objek jelas tidak populer dan, karenanya, tidak masuk akal untuk membayar lebih untuk penyimpanan di Cool.

Peluncuran pertama

Ketika proses itu ditulis dan diuji, tiba saatnya untuk percobaan, dan ada masalah yang diharapkan. Dalam antrian pada waktu itu ada sekitar 10 juta objek, saya memutuskan untuk memulai migrasi dari 30.000 objek per hari. Siapkan grafik yang indah di dasbor dan mulai mengamati. Dalam statistik, saya melihat "lunges" aneh dengan permintaan GetBlobProperties. Mereka terjadi dengan interval kira-kira sama satu jam, selalu mulai sekitar satu setengah jam setelah dimulainya migrasi, dan berlangsung selama beberapa waktu setelah selesai.



Jumlah permintaan semacam itu terlalu besar untuk diabaikan. Saya melihat log dan melihat bahwa permintaan ini tidak datang dari server saya tetapi dari alamat IP asing. Saya tidak mau membayar untuk mereka sama sekali.

Saya mencari di tumpukan dan di dokumentasi, tetapi tidak berhasil. Menulis pertanyaan tentang Stackoverflow dan dukungan teknis. Akibatnya, setelah korespondensi yang panjang dengan dukungan teknis, dan memberi mereka log, mereka mengatakan kepada saya bahwa mereka dapat mereproduksi situasi dan ini adalah bug di pihak mereka.

Nuansa yang menarik adalah bahwa pertanyaan saya tentang Stackoverflow dijawab tidak menjelaskan alasannya, tetapi hanya menegaskan bahwa saya akan membayar untuk permintaan ini, tetapi orang yang memberikan jawaban dengan tegas meminta saya untuk menandainya sebagai benar. Dia juga mengisyaratkan untuk menyampaikan kepada saya bahwa mereka (dalam dukungan) tidak dapat menyebarkan bug di produk mereka sendiri. Saya memberi tahu dia bahwa saya tidak akan melakukannya sampai dia menulis kebenaran. Saya dapat menulis ini sendiri, tetapi saya berpikir bahwa staf dukungan teknis mungkin mengukur jumlah jawaban yang dikonfirmasi, jadi saya memintanya untuk menulis alasan yang sebenarnya dan dalam hal ini saya menandai jawabannya sebagai benar. Setelah ragu-ragu, dia setuju dan menambahkan komentarnya dengan laporan bug. Secara umum, saya menyukai cara kerja dukungan teknis - saya bahkan dipindahkan ke seorang gadis Rusia yang masih membuat saya tahu tentang perubahan pada masalah ini.

Fakta bahwa bug itu dikenali hanya memuaskan saya secara moral, tetapi saya ingin menjalankan mekanisme itu, dan pada saat yang sama tidak membayar uang untuk permintaan kidal. Terutama mengingat bahwa saya biasanya menjadi bingung untuk meminimalkan jumlah permintaan dan biaya.

Dalam dukungan teknis, mereka menyarankan saya untuk menunggu dengan peluncuran dan setelah beberapa minggu mereka menulis bahwa bug telah diperbaiki, tetapi ketika rilis dengan perbaikannya akan diketahui, tidak diketahui. Mereka menawarkan untuk mengaktifkan pencatatan dan bekerja seperti itu, dan setelah rilis, meminta kompensasi di Microsoft. Sebenarnya, dalam mode ini, masih berfungsi. Setiap hari saya memulai migrasi sejumlah kecil objek dan menunggu rilis.

Kesimpulan

Biaya 30.000 objek harian masih 900 p. per bulan - dan ini cukup dapat diterima. Sebagian besar biaya adalah operasi tulis. Jadi ketika seluruh antrian diproses dan tahap pekerjaan yang direncanakan dimulai, akan menjadi jelas berapa biaya sebenarnya dari penyimpanan semacam itu. Tetapi menurut perhitungan saya, ini akan terjadi dalam waktu sekitar satu tahun.

Ketika akan ada rilis di Azure Blob-storage, saya akan menambahkan di sini apakah saya berhasil mendapatkan kompensasi. Mengenai biaya bulanan, ini sekitar 10% dari biaya.