Membangun dan Mengoperasikan Sistem Penyimpanan Raksasa Bernama S3
(allthingsdistributed.com)- Amazon S3 berawal sebagai object storage berbasis HTTP REST API yang diluncurkan pada 14 Maret 2006, lalu berkembang menjadi layanan berskala besar yang dioperasikan bersama oleh ratusan microservice dan banyak tim khusus
- Skala S3 tidak bisa dijelaskan hanya lewat kode; ini adalah sistem yang terus berubah, dengan hard disk, firmware, data center, organisasi operasional, dan workload pelanggan yang saling terkait terus-menerus
- HDD telah banyak meningkat dalam kapasitas dan efisiensi biaya, tetapi performa akses acaknya tetap terikat pada batas mekanis, sehingga S3 menjadikan manajemen panas I/O dan penempatan data di jutaan disk sebagai masalah inti
- Replikasi dan erasure coding berbasis Reed-Solomon bukan hanya meningkatkan durabilitas, tetapi juga membantu mengelola performa dan tail latency dengan mengalihkan request agar menghindari disk yang kelebihan beban
- Operasi S3 dirancang agar dapat mempertahankan pengembangan cepat sekaligus standar durabilitas tinggi melalui durability review, ShardStore berbasis Rust, verifikasi formal ringan, dan ownership di tingkat tim
Melihat S3 sebagai satu sistem layanan raksasa
- S3 adalah layanan object storage yang terdiri dari HTTP REST API, frontend fleet, layanan namespace, storage fleet berbasis hard disk, dan background job fleet
- Untuk setiap komponen besar, ada area terpisah di dalam organisasi S3 beserta pemimpin dan beberapa tim, dan komponen yang lebih dalam juga dioperasikan dalam bentuk fleet dan timnya sendiri
- Saat ini S3 terdiri dari ratusan microservice, dan interaksi antar tim mendekati kontrak pada level API
- Jika modularitas dirancang dengan buruk, interaksi antar tim juga bisa menjadi tidak efisien dan canggung, sehingga memperbaikinya juga termasuk dalam proses merancang software dan tim secara bersamaan
Bukan software saja, melainkan seluruh layanan adalah sistem
- Pelanggan S3 membeli pengalaman layanan, bukan software yang dikemas, dan mereka mengharapkan kualitas yang konsisten serta dapat diprediksi
- Batas sistem S3 tidak berhenti pada kode saja
- kode yang berjalan dekat disk
- teknisi yang memasang storage rack baru di data center
- aplikasi pelanggan yang men-tuning performa
- organisasi hardware, keuangan, dan engineering
- S3 lebih dekat pada sistem hidup yang terus tumbuh dan berubah bersama software, hardware, dan manusia
- Diagram arsitektur sederhana di whiteboard cenderung menyembunyikan layanan yang telah berkembang dan skala di dalam tiap kotak, sehingga membuat orang meremehkan sistem yang sebenarnya
Pengaruh batas fisik HDD terhadap desain S3
- S3 adalah sistem yang sangat besar dan menggunakan jutaan hard disk, dan karakteristik HDD adalah salah satu kendala utama dalam desainnya
- Sejak IBM 350 disk storage unit pada 1956, HDD telah berkembang pesat
- HDD terbesar yang disebutkan saat ini adalah Western Digital Ultrastar DC HC670 26TB
- sejak RAMAC, kapasitas meningkat 7,2 juta kali
- ukuran fisik mengecil 5.000 kali
- biaya per byte setelah penyesuaian inflasi menjadi 6 miliar kali lebih murah
- Namun seek time hanya membaik sekitar 150 kali, dan performa baca/tulis acak tetap berada di kisaran sekitar 120 operasi per detik
- Angka performa ini juga mirip saat S3 diluncurkan pada 2006, dan tidak jauh berbeda dibanding 10 tahun sebelumnya
- Karena HDD adalah perangkat mekanis, kita harus menunggu lengan bergerak dan platter berputar, sehingga performa akses acak tidak membaik secepat peningkatan kapasitas
- Roadmap industri menunjukkan jalur menuju HDD 200TB dalam 10 tahun ke depan, dan pada tingkat itu, jika diasumsikan seluruh data diakses secara acak dan merata, maka tiap 2TB data pada disk hanya mengizinkan 1 I/O per detik
- S3 belum memakai drive 200TB, tetapi diperkirakan akan menggunakan drive tersebut dan semua ukuran drive di antaranya
Manajemen panas: penempatan data dan performa
- Di S3, heat berarti jumlah request yang masuk ke satu disk pada suatu waktu tertentu
- Jika manajemen panas buruk, request bisa menumpuk pada disk tertentu dan menciptakan hotspot, yang menurunkan performa keseluruhan request yang bergantung pada disk tersebut
- Hotspot biasanya tidak langsung menghentikan sistem, tetapi membentuk antrean request dan menurunkan pengalaman pelanggan
- request yang menunggu disk sibuk menjadi tertunda
- latensi diperbesar ke lapisan atas storage stack melalui I/O dependensi seperti lookup metadata atau erasure coding
- muncul latensi tinggi pada sebagian request, yaitu straggler
- hotspot pada HDD individual berujung pada tail latency, dan jika dibiarkan dapat memengaruhi latensi request secara keseluruhan
- Di S3, saat data ditulis, tidak diketahui kapan dan bagaimana data itu akan diakses di masa depan, sehingga keputusan penempatan data saat write menjadi sulit
- Pada skala kecil, prediksi dan pengelolaan heat I/O sangat sulit, tetapi pada skala dan multi-tenancy S3 muncul karakteristik yang berbeda
- Workload individual sering kali idle hampir sepanjang waktu lalu tiba-tiba mencapai puncak, tetapi ketika jutaan workload digabungkan, permintaan total menjadi lebih rata dan dapat diprediksi
- Setelah melewati skala tertentu, satu workload individual menjadi sulit atau bahkan tidak mungkin memengaruhi puncak total sistem
Replikasi dan erasure coding menangani durabilitas dan performa sekaligus
- Metode redundansi dalam sistem penyimpanan bukan hanya melindungi data dari kegagalan hardware, tetapi juga membantu distribusi panas
- Replikasi menempatkan salinan di beberapa disk agar tahan terhadap kegagalan disk, dan memungkinkan request baca dilayani dari salah satu salinan tersebut
- Dari sudut pandang kapasitas, replikasi mahal, tetapi dari sudut pandang I/O baca, ini efisien
- Agar tidak membayar overhead replikasi untuk semua data, S3 juga menggunakan erasure coding
- Salah satu pendekatan contohnya menggunakan algoritme seperti Reed-Solomon
- objek dibagi menjadi k identity shard
- m parity shard tambahan dibuat
- objek dapat dibaca selama k shard dari total k+m shard masih tersedia
- Pendekatan ini mengurangi overhead kapasitas sambil tetap menahan jumlah kegagalan yang sama
Strategi penempatan data dan isolasi workload pelanggan
- Metode redundansi membagi data menjadi lebih banyak fragmen daripada jumlah baca yang dibutuhkan, sehingga request bisa dikirim sambil menghindari disk yang kelebihan beban
- S3 menempatkan objek baru secara luas di seluruh disk fleet untuk lebih mengurangi heat
- Satu objek dapat di-encode ke puluhan drive, dan objek yang berbeda ditempatkan pada kumpulan drive yang berbeda
- Menyebarkan objek dalam tiap bucket ke banyak disk memberi dua keuntungan
- porsi data pelanggan pada satu disk menjadi sangat kecil, sehingga workload individual sulit menciptakan hotspot pada disk tertentu
- workload individual dapat melakukan burst hingga skala disk yang sulit dibangun sendiri sebagai sistem terpisah dan akan sangat mahal
- Burst dari pelanggan analisis genomik yang menjalankan analisis paralel di ribuan fungsi Lambda dapat ditangani oleh lebih dari 1 juta disk individual
- Saat ini ada puluhan ribu pelanggan di S3 yang bucket-nya tersebar di jutaan drive
- Pembeda S3 bukan hanya skala sistem penyimpanannya sendiri, tetapi juga bahwa skala agregasi pelanggan dan workload dapat mengubah sifat sistem itu sendiri
Durability review dan guardrail
- Amazon sangat menekankan agar engineer dan tim bisa gagal dengan cepat namun aman
- Untuk bergerak cepat sambil tetap menyediakan storage dengan durabilitas tinggi, S3 menggunakan proses durability review
- durability review bukan mekanisme yang termasuk dalam model statistik 11 9s, tetapi tetap dianggap penting dalam operasi S3
- Jika perubahan engineering dapat memengaruhi kondisi durabilitas, maka durability review dilakukan
- Proses ini meminjam ide threat model dari riset keamanan
- menulis ringkasan perubahan
- membuat daftar ancaman yang komprehensif
- merangkum bagaimana perubahan tersebut bertahan terhadap ancaman-ancaman itu
- durability review memiliki dua peran
- mendorong penulis dan reviewer untuk berpikir kritis tentang risiko yang harus dilindungi
- memungkinkan risiko dan langkah penanganannya dipisahkan agar bisa dibahas secara terpisah
- Saat mencari penanganan, pendekatan yang disukai bukan memberi mitigasi terpisah untuk setiap risiko rinci, melainkan guardrail yang sederhana namun kuat untuk mencegah kelompok risiko yang luas
ShardStore, Rust, dan verifikasi formal ringan
- Beberapa tahun lalu, S3 memulai proyek untuk menulis ulang dari awal lapisan paling bawah dari storage stack, yaitu bagian yang mengelola data pada masing-masing disk
- Nama lapisan storage baru itu adalah ShardStore
- Salah satu guardrail yang diadopsi saat membangun ulang ShardStore adalah verifikasi formal ringan
- Untuk menemukan bug lebih awal, tim memindahkan bahasa implementasi ke Rust
- memanfaatkan type safety
- memanfaatkan dukungan bahasa yang terstruktur
- menulis library yang memperluas type safety hingga ke struktur on-disk
- Dari sisi verifikasi, model penyederhanaan logika ShardStore ditulis dalam Rust dan ditempatkan dalam repositori yang sama dengan implementasi ShardStore produksi yang sebenarnya
- Model ini berfungsi sebagai spesifikasi yang dapat dieksekusi, dengan menghilangkan kompleksitas lapisan storage on-disk nyata dan HDD
- Ukuran model hanya sekitar 1% dari sistem nyata, tetapi memungkinkan pengujian pada tingkat yang tidak realistis terhadap hard drive 120 IOPS
- Pekerjaan ini juga dipublikasikan sebagai makalah SOSP, Using lightweight formal methods to validate a key-value storage node in Amazon S3
- Setelah itu, alat dan teknik yang sudah ada seperti property-based testing digunakan untuk memverifikasi apakah perilaku implementasi sesuai dengan spesifikasi
- Intinya, teknik riset verifikasi formal telah diindustrialisasi menjadi kode yang bisa dipelihara engineer biasa dan alat yang diterapkan pada setiap commit
- Guardrail verifikasi memberi tim kepercayaan diri untuk mengembangkan lebih cepat, dan tetap dipertahankan bahkan setelah engineer baru bergabung
Menangani masalah skala tim dan individu lewat ownership
- Di Amazon, ownership adalah konsep yang memperjelas satu individu atau tim yang bertanggung jawab penuh sampai tuntas agar pekerjaan atau layanan tertentu berhasil
- Di S3, agar bisa bergerak cepat sambil menjaga standar kualitas tinggi, tim harus menjadi pemilik
- memiliki kontrak API dengan sistem lain
- bertanggung jawab atas durabilitas, performa, dan ketersediaan
- memperbaiki bug bahkan pada pukul 3 pagi jika bug tak terduga memengaruhi ketersediaan
- setelah memperbaiki bug, meningkatkan sistem agar hal yang sama tidak terulang
- ownership memerlukan kepercayaan seiring tanggung jawab yang besar
- Agar individu atau tim bisa memiliki layanan, mereka perlu ruang untuk memutuskan sendiri bagaimana layanan itu akan diberikan
- Dari pengalaman proyek riset pascasarjana juga terlihat bahwa mahasiswa berinvestasi lebih dalam ketika mereka merasa itu adalah idenya sendiri dan dapat mengembangkannya secara langsung
- Dalam peran engineer yang sangat senior, pendekatan yang lebih efektif sering kali bukan menyodorkan solusi seolah akan langsung dideploy sendiri, melainkan mendefinisikan masalah dengan baik dan membantu tim memiliki solusi tersebut
- Pada masalah yang memiliki banyak kemungkinan solusi, membantu seseorang memilih solusi yang tepat menjadi cara untuk memberinya ownership atas solusi
Kesimpulan yang didapat dari S3
- Skala teknis S3 bukan sekadar versi lebih besar dari sistem kecil; workload, struktur, dan cara operasinya sendiri berbeda secara mendasar
- “Sistem” mencakup bukan hanya software, tetapi juga operasi layanan, organisasi operasional, dan bahkan kode pelanggan yang berjalan bersama layanan tersebut
- Karena organisasi juga merupakan bagian dari sistem, organisasi memiliki masalah skalabilitas dan peluang inovasi tersendiri
- Untuk berhasil dalam peran individual, yang penting bukan hanya solusi, tetapi kemampuan menyatakan masalah dengan jelas dan mendukung agar tim engineering yang kuat benar-benar memiliki solusi itu
2 komentar
Komentar Hacker News
Salah satu percakapan yang saya ingat saat berada di AWS adalah bahwa bahkan kejadian satu dalam satu miliar pun terjadi setiap hari pada skala S3
Hal-hal yang biasanya dianggap terlalu kecil kemungkinannya untuk dikhawatirkan tetap harus dipertimbangkan dan ditangani
Senang melihat pendekatan seperti ShardStore, terutama verifikasi formal dan pengujian berbasis properti. Layanan generasi sebelumnya punya banyak bug sampai-sampai menunjukkan risiko pertumbuhan organik dengan jelas, tetapi setidaknya dirancang agar kegagalan terjadi secara “aman” sehingga kehilangan data bisa dicegah, dan para engineer S3 sangat terobsesi dengan bagian itu
Bukan cuma S3. Misalnya pada Prime Day 2022, DynamoDB naik hingga lebih dari 105 juta permintaan per detik hanya dari workload Amazon: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
Dalam tulisannya, Andy juga membahas teknik formal ringan dan adopsi Rust oleh tim; pada skala ketika bahkan kejadian dengan probabilitas sangat rendah menjadi umum, kita harus berinvestasi pada berlapis-lapis alat dan proses demi kebenaran
Saya menjelaskan bahwa jika naik sampai target 500k TPS, itu berarti 30 kali per menit, lalu bertanya, “mau pegang on-call minggu itu?” Di stack tersebut, “memegang standar tertinggi” punya arti yang sama sekali berbeda dari kebanyakan organisasi
Untungnya algoritmanya bagus, dan hardware masa kini juga jauh lebih andal
Di kepala saya juga ada suara yang agak sinis, siap menonton sambil makan popcorn jika kebetulan bisa menyaksikan dampak dari tabrakan hash kriptografis besar pertama
Saat bekerja di genomika, selama 10 tahun terakhir saya banyak menangani penyimpanan data berskala petabyte
Setelah memakai AWS S3, GCP GCS, dan sistem penyimpanan untuk hardware colocation (Ceph, Gluster, dan sistem HP yang namanya sudah saya hapus dari ingatan), saya jadi sangat menghargai upaya yang dibutuhkan untuk mengoperasikan sistem seperti ini
Sulit juga meremehkan manfaat berbagi disk I/O dengan begitu banyak pelanggan lain. Istilah “heat” yang disebut di tulisan itu baru pertama kali saya dengar, tetapi pada sistem tunggal hal ini benar-benar sulit dimitigasi. Di cluster colocation kami, demi mengelola I/O dengan benar di antara pekerjaan besar, kami harus mengubah sistem batch agar memperlakukan I/O sebagai resource yang bisa dialokasikan seperti RAM atau CPU. S3 dan GCP sangat mahal, tetapi kadang performanya sepadan dengan harganya
Tulisan seperti inilah sisi terbaik HN menurut saya
Dari sudut pandang cloud storage, pelanggan terbaik adalah pelanggan yang menyimpan data dalam jumlah sangat besar tetapi hampir tidak pernah membacanya. Mirip seperti menyewa hard disk, tetapi jika hanya sebagian dari tiap disk diisi data “dingin”, seluruh kapasitas I/O disk yang sama tetap bisa dipakai untuk menangani pekerjaan panas
Jika menyeimbangkan dengan sangat hati-hati data apa ditempatkan di drive mana, semua drive tetap bisa dimanfaatkan meski sebagian besar data tidak digunakan. Karena itu penyimpanan relatif murah, sedangkan pembacaan relatif mahal
Bahkan ketika mendukung S3, performanya sering jauh lebih lambat dari yang sebenarnya bisa dicapai
Ini sulit, dan saya minta maaf karena ketersediaan bacanya hanya sekitar 99,95%
Jika S3 sejak awal menetapkan protokol sederhana berbasis OAuth2 untuk pendelegasian akses baca/tulis, akan ada banyak hal yang bisa dibangun
Dunia membutuhkan protokol berbasis HTTP yang memungkinkan aplikasi mengakses data atas nama pengguna. Google Drive paling mendekati ini, tetapi penyedianya hanya satu dan ada masalah lain juga[0]. Sayang remoteStorage tidak pernah benar-benar mapan. Saya berharap Solid berhasil, tetapi bagi saya rasanya terlalu rumit. Pendekatan saya untuk masalah ini adalah https://gemdrive.io/, tetapi sekarang hampir berhenti karena saya sedang berfokus pada bagian lain dari stack self-hosting
[0]: https://gdrivemusic.com/help
Untuk melakukannya dengan benar saat ini sangat sulit. Saya sampai membuat satu aplikasi CLI utuh untuk memecahkan masalah “menerbitkan kredensial AWS yang hanya bisa mengakses bucket tertentu ini”, tetapi saya tidak ingin menyuruh pengguna memasang dan menjalankan hal seperti ini: https://s3-credentials.readthedocs.io/en/stable/
Idealnya ada library dengan dependensi sisi klien minimal yang me-mount direktori lokal yang sebenarnya adalah bucket S3 milik pengguna
Karena pesaing kapan saja bisa masuk lewat interoperabilitas yang bermusuhan
Sangat disayangkan proyek-proyek yang pernah mencoba atau sedang mencoba mewujudkan kedaulatan data pengguna semuanya mengalir ke arah kripto yang aneh
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Sunting: Sepertinya saya salah membaca komentar. Saya mengira maksudnya aplikasi ingin mendelegasikan data pengguna ke klien, padahal tampaknya yang diinginkan adalah pengguna mendelegasikan datanya ke aplikasi. Itu use case yang berbeda
Spesifikasi IBM RAMAC menyebutkan kapasitas penyimpanan 3,75 MB dan sekitar 9.200 dolar per terabita, tetapi itu tidak mungkin benar
Jika biaya dikalikan dengan kapasitas penyimpanan, harga drive-nya menjadi 3 sen
Situs ini[1] mengatakan bahwa perangkat itu “menyimpan sekitar 2.000 bit per inci persegi dan harga belinya sekitar 10.000 dolar per megabita”
Jadi kemungkinan spesifikasinya seharusnya 9.200 dolar per megabita. Dengan begitu harga drive menjadi 34.500 dolar, yang jauh lebih masuk akal
[1]: https://www.historyofinformation.com/detail.php?entryid=952
Kapasitasnya 30 juta bit, dan angka itu hanya memakai 6 bit data setelah mengecualikan parity. Namun karena disewakan 3.000 dolar per bulan, tidak ada biaya tetap seperti membeli drive fisik secara tunai. Dalam hal itu, modelnya juga cukup mirip dengan S3
Yang tidak disadari kebanyakan orang adalah bahwa keajaibannya bukan terletak pada pemrosesan sistem itu sendiri, melainkan pada membuat otorisasi terlihat seolah-olah tanpa biaya
Otorisasi dalam sistem terdistribusi itu luar biasa sulit. Pada skala AWS, itu praktis seperti sihir. AWS memiliki model izin yang kaya, dan perubahan izin mungkin menyebar ke seluruh infrastrukturnya dalam waktu submilidetik sambil tetap menangani triliunan request
Bagian ini, bersama logging/rekonsiliasi untuk penagihan, adalah dua unsur ajaib AWS yang ingin saya baca dalam bentuk tulisan
S3 menangani kontrol akses secara berbeda dibanding layanan lain; izinnya melekat pada resource. Sepertinya karena alasan kecepatan
Salah satu alasan pendekatan bucket/key terasa khusus adalah karena model itu sudah mapan ketika IAM muncul
Kemungkinan model itu tetap dipertahankan setelahnya karena menghapus model lama akan menjadi pekerjaan sulit yang dapat merusak konfigurasi banyak pelanggan
“Sebagai engineer yang benar-benar senior di perusahaan, tentu saya punya pendapat yang kuat dan agenda teknis. Namun ketika berinteraksi dengan para engineer, kalau kita hanya mencoba membagikan ide, sulit bagi semua orang untuk berhasil. Jauh lebih sulit untuk benar-benar terlibat dalam ide yang bukan milik sendiri. Jadi saat bekerja dengan tim, saya mengambil strategi agar ide terbaik saya menjadi ide yang diajukan orang lain, bukan saya. Saya secara sadar menghabiskan jauh lebih banyak waktu untuk mengembangkan masalah dan mengungkapkannya dengan sangat baik, daripada menjual solusi. Sering kali ada banyak cara untuk memecahkan sebuah masalah, dan memilih cara yang tepat berarti membuat seseorang memiliki solusi itu.”
“Saya belajar bahwa agar benar-benar berhasil dalam peran saya, saya harus berfokus pada merumuskan masalah dengan jelas, bukan solusinya, dan mencari cara untuk mendukung tim engineering yang kuat agar benar-benar memiliki solusi tersebut.”
Bagian ini benar-benar bagus. Sedikit mengingatkan pada efek Ikea. Jika ingin seseorang bersemangat terhadap pekerjaan yang ia lakukan, kita perlu mendorong rasa kepemilikan, dan cara yang baik adalah membuat pekerjaan itu menjadi “ide orang tersebut”.
Pada akhirnya, orang sering kali berbeda pandangan bahkan tentang apa itu “masalah”.
Untungnya tidak semua masalah seperti ini. Namun misalnya jika melihat diskusi tentang “masalah packaging” di Python, yang sebenarnya ada sekitar enam masalah berbeda dijelaskan orang dengan cara yang sangat berbeda-beda, dan fenomena ini tampak cukup buruk.
Jika Andy Warfield membaca ini, dan kemungkinan besar ia membacanya, saya punya pertanyaan. Saat mengembangkan sebuah masalah, seberapa bernilaikah membuat sketsa kemungkinan solusi? Jika masalah dirumuskan dengan jelas, beberapa solusi yang mungkin akan muncul secara alami. Apakah layak membagikan solusi-solusi itu untuk memulai proses berpikir calon pemiliknya? Atau lebih baik berfokus hanya pada masalah dan membiarkan ruang solusi sepenuhnya terbuka?
Selain itu, adakah bahan bacaan lain tentang cara kerja individual contributor yang sangat senior seperti ini?
Bagi saya terdengar seperti, “Hei rakyat jelata! Aku tidak punya waktu untuk peduli pada masalahmu. Kalau kau hanya membawa masalah, aku tidak bisa naik jabatan dari pekerjaanmu.”
Agar bisa memecahkan masalah, pertama-tama kita harus bisa memahami masalah itu dan mengakui keberadaannya.
Dalam situasi tanpa otoritas atau keahlian yang sudah diakui sebelumnya—yakni konteks tempat sebagian besar masalah sehari-hari muncul—jika seseorang memonopoli kanal percakapan dua arah dengan penjelasan masalah yang panjang, rinci, dan disusun hati-hati, ia mudah terlihat seperti orang yang hanya mau bicara dan tidak mau bekerja, atau seperti orang yang tidak ingin mencari solusi bersama orang lain.
Senang melihat karyawan Amazon kini bisa berbicara secara terbuka tentang cara kerja internal S3.
Saya juga ingin mendengar lebih banyak tentang bagaimana Glacier bekerja. Sejauh yang saya tahu, mereka tidak pernah mengungkapkan apa media penyimpanan dasarnya, sehingga muncul berbagai spekulasi: tape, HDD offline, HDD kustom, dan lain-lain.
Namun ada juga yang tidak setuju. Masih tetap misteri.
Saya berharap AWS menceritakan semuanya tentang itu dan seluruh perjalanannya. Itu benar-benar objek yang menarik.
Padahal cukup satu engineer mabuk lalu mengoceh. Di bidang yang jauh lebih serius, seorang tentara di Massachusetts membocorkan informasi keamanan nasional di Discord agar terlihat keren di mata teman-teman gamernya, dan kini menghadapi hukuman penjara yang panjang. Saya kira detail Glacier sudah akan keluar sekarang.
“Bayangkan kepala hard disk sebagai sebuah 747 yang terbang di atas halaman rumput dengan kecepatan 75 mil per jam. Celah udara antara bagian bawah pesawat dan ujung rumput setebal dua lembar kertas. Jika bit pada disk diukur sebagai helai rumput, lebar track adalah 4,6 helai rumput dan panjang bit adalah satu helai rumput. Saat pesawat terbang di atas rumput sambil menghitung helai rumput, ia hanya melewatkan satu helai rumput setiap 25 ribu kali mengelilingi Bumi.”
Bagian load balancing mengingatkan saya pada era KeyMap S3 dan masa ketika kami mencoba bermigrasi ke sana dari implementasi awal.
Pelajaran yang didapat adalah, bahkan setelah mengidentifikasi objek/partisi/bucket yang paling panas, kita tidak bisa sekadar memindahkannya lalu selesai. Semuanya harus diurutkan. Solusi sebenarnya adalah mengurutkannya, lalu membagi beban partisi host ke dalam kuartil, dan memindahkan partisi kuartil kedua ke host dengan beban paling rendah.
Jika mencoba memindahkan bucket paling panas, yakni kuartil pertama, beban pada anggota yang tersisa akan meningkat dan terus gagal.
Efek samping lainnya, tingkat error berubah dari sekitar 1% yang stabil menjadi beberapa hari tanpa error, dan akibatnya kami memperbarui ambang notifikasi menjadi jauh lebih ketat. Kira-kira ini terjadi sekitar 2009.
Saya juga punya latar belakang akademis dari UM, tetapi bergabung dengan S3 alih-alih mengambil program doktor. Rimanya juga pas.
S3 lebih dari sekadar penyimpanan; ia adalah standar.
Saya suka bahwa di beberapa tempat kita bisa menggunakan penyimpanan yang kompatibel dengan S3, biasanya dengan sedikit catatan. Saya tidak tahu seberapa terbuka standarnya, atau apakah harus membayar Amazon untuk bisa mengatakan “S3 compatible”, tetapi ini cukup keren.
Contohnya iDrive E2, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage, dan Backblaze B2.
Sunting: setelah dicari, sepertinya Azure memang tidak punya :-/
Komentar Hacker News
Bekerja di bidang genomika, selama 10 tahun terakhir saya telah menangani banyak penyimpanan data berukuran petabyte.
Hal-hal yang bisa kita bangun jika S3 menggunakan protokol berbasis OAuth2 untuk mendelegasikan akses baca/tulis.
Menangani autentikasi dalam sistem terdistribusi itu sangat sulit.
Senang melihat karyawan Amazon berbicara secara terbuka tentang cara kerja internal S3.
Bagian yang menjelaskan kepala hard drive dengan analogi pesawat 747.
Kembali ke masa S3 KeyMap, kami belajar bahwa bahkan setelah mengidentifikasi objek/partisi/bucket terpanas, masalahnya tidak bisa diselesaikan hanya dengan memindahkannya.
S3 bukan sekadar penyimpanan sederhana, melainkan sebuah standar.