Bagaimana AWS S3 Memproses 1 Petabyte per Detik di Atas HDD yang Lambat

 (bigdata.2minutestreaming.com)
19 poin oleh GN⁺ 2025-09-27 | 2 komentar | Bagikan ke WhatsApp
  • AWS S3 adalah layanan penyimpanan objek multitenan berskala besar yang menyediakan ketersediaan tinggi dan durabilitas dengan biaya rendah
  • Meski memanfaatkan HDD lama dan lambat (≈120 IOPS), S3 memaksimalkan nilai ekonomi media penyimpanan sangat murah berkapasitas besar
  • S3 merancang lapisan penyimpanan internalnya (ShardStore) dengan struktur log (LSM) agar jalur tulis sesuai dengan I/O sekuensial, sementara jalur baca menutupi masalah performa dengan Erasure Coding (5-of-9) dan paralelisasi skala besar
  • Di seluruh jalur klien, frontend, dan penyimpanan, S3 mengurangi tail latency dan menjumlahkan throughput dengan multipart upload, byte-range GET, connection pool, hedge request, dan teknik lain
  • Dengan penempatan acak terdistribusi, Power of Two Random Choices, rebalancing berkelanjutan, dan decorrelation yang meratakan beban seiring skala membesar, S3 menghindari hotspot dan pada akhirnya mewujudkan throughput kelas >1 PB/s

Arsitektur penyimpanan skala besar AWS S3

  • Semua orang tahu apa itu AWS S3, tetapi hanya sedikit yang memahami seberapa masif skalanya dan inovasi apa saja yang dibutuhkan untuk mewujudkannya
  • S3 adalah layanan object storage multitenan yang dapat diskalakan, yang memungkinkan penyimpanan dan pengambilan objek melalui API, serta menawarkan ketersediaan dan durabilitas yang sangat tinggi dengan biaya yang relatif terjangkau

  • Skala S3

    • Menyimpan lebih dari 400 triliun objek
    • Menangani 150 juta permintaan per detik
    • Mendukung trafik lebih dari 1 PB per detik saat puncak
    • Mengoperasikan puluhan juta hard disk
  • S3 menempatkan ketersediaan dan durabilitas (“11 nines” sebagai target desain) yang tinggi, serta biaya yang relatif rendah, sebagai prasyarat pengalaman pengguna
    • Bahkan telah meluas menjadi lapisan penyimpanan dasar untuk data analytics dan data lake machine learning
  • Tujuan desainnya adalah mempertahankan efisiensi biaya sambil menangani pola akses acak dan konkurensi skala besar
    • S3 berasumsi adanya workload random access kolektif, di mana tiap tenant mengakses ukuran dan offset sembarang

Fondasi teknologi: hard drive (HDD)

  • Skalabilitas dan performa S3 yang mengagumkan bertumpu pada media penyimpanan tradisional, yaitu HDD
  • HDD adalah teknologi lama yang sangat tahan lama, tetapi memiliki keterbatasan pada IOPS (input/output per detik) dan latensi karena pergerakan fisik
    • Karena gerakan mekanis seperti rotasi per detik (misalnya 7200 RPM) dan actuator seeking bersifat wajib, latensi secara struktural besar dan tak terhindarkan
    • Rata-rata half-platter seek ≈4 ms, rata-rata half-rotation ≈4 ms, transfer 0.5 MB ≈2.5 ms → pembacaan acak 0.5 MB rata-rata ≈11 ms, throughput acak satu disk sekitar ≈45 MB/s
  • Berbeda dari SSD, HDD masih dipakai pada penyimpanan skala besar karena kurva jangka panjang kapasitas naik, harga turun membuat ekonominya tetap unggul sebagai media sangat murah/berkapasitas besar
    • Harga: turun 6 miliar kali per byte (disesuaikan inflasi)
    • Kapasitas: naik 7,2 juta kali
    • Ukuran: turun 5 ribu kali
    • Berat: turun 1.235 kali
  • Namun selama 30 tahun, IOPS praktis stagnan di sekitar 120, dan performa akses acak serta latensi tidak banyak membaik
  • SSD unggul untuk random I/O, tetapi pada penyimpanan skala peta hingga exa, total cost of ownership (TCO) menjadi kurang menguntungkan

Jalur tulis yang dioptimalkan untuk I/O sekuensial

  • HDD dioptimalkan untuk akses sekuensial; jika byte dibaca dan ditulis secara berurutan, platter disk dapat terus berputar secara alami sehingga data diproses lebih cepat
  • Struktur data berbasis log (log-structured) memanfaatkan sifat sekuensial ini
    • ShardStore, lapisan penyimpanan internal S3, mengadopsi LSM berstruktur log dengan strategi menangani write sebagai append sekuensial ke disk
    • Dengan cara serupa, batch processing juga dapat memaksimalkan throughput sekuensial disk

Paralelisasi dan Erasure Coding untuk jalur baca acak

  • Pembacaan menimbulkan lompatan ke lokasi acak sesuai permintaan pengguna, sehingga langsung berhadapan dengan batasan fisik tersebut (latensi rata-rata random I/O sekitar 11 ms)
    • Satu HDD dapat menangani maksimal 45 MB per detik untuk random I/O
    • Karena itu, HDD sangat hemat biaya untuk menyimpan data dalam jumlah besar, tetapi lemah untuk performa akses acak
  • Untuk mengatasi batasan fisik ini, S3 mengadopsi paralelisasi skala besar dengan membagi data ke banyak disk dan membaca secara bersamaan untuk menjumlahkan throughput
    • Data didistribusikan ke sangat banyak HDD, lalu input/output tiap disk digunakan secara paralel untuk secara drastis meningkatkan throughput total
    • Misalnya, jika file 1 TB disimpan terpecah di 20 ribu HDD, pembacaan kelas TB/s menjadi mungkin dengan menggabungkan throughput seluruh disk

Erasure Coding

  • Dalam sistem penyimpanan, menjamin redundansi adalah hal wajib
  • S3 menggunakan Erasure Coding (EC) untuk membagi data menjadi K pecahan data dan M pecahan parity
    • Dari total K+M pecahan, pemulihan dapat dilakukan selama ada K pecahan mana pun
  • S3 memakai Erasure Coding (5-of-9) dengan struktur 9 bagian (5 data shard, 4 parity shard) sebagai titik keseimbangan
    • 5 data + 4 parity = 9 pecahan
    • Hingga 4 shard dapat hilang namun tetap bisa dipulihkan, sehingga toleransi kesalahan tercapai karena 5 pecahan mana pun cukup untuk memulihkan data asli
    • Overhead penyimpanan sebesar ≈1,8x, lebih efisien kapasitas dibanding replikasi tiga salinan (3x)
    • Pada saat yang sama, tersedia 5 jalur baca paralel, yang menguntungkan untuk paralelisasi shard dan menghindari straggler
  • Dengan cara ini, S3 mengatasi batasan fisik tersebut sambil tetap menyediakan akses acak ke data dalam skala besar

Struktur pemrosesan paralel

  • S3 menggunakan 3 bentuk paralelisasi utama
    • 1. Pengguna mengunggah dan mengunduh data dengan membaginya menjadi beberapa chunk
    • 2. Klien mengirim permintaan serentak ke beberapa server frontend
    • 3. Server menyimpan objek secara tersebar di beberapa storage server

  • 1. Pemrosesan paralel di tingkat server frontend

    • Memanfaatkan internal HTTP connection pool untuk terhubung serentak ke beberapa endpoint yang terdistribusi
    • Mencegah beban berlebih pada node infrastruktur atau cache tertentu

  • 2. Pemrosesan paralel antar hard drive

    • Berdasarkan EC, data didistribusikan ke beberapa HDD sebagai shard kecil

  • 3. Pemrosesan paralel untuk permintaan PUT/GET

    • Klien memecah data menjadi beberapa bagian untuk diunggah secara paralel
    • PUT: memaksimalkan paralelisme baru melalui multipart upload
    • GET: mendukung byte-range GET (hanya membaca sebagian rentang dalam objek)
  • Dengan memprosesnya secara terdistribusi dan paralel, upload 1 GB per detik pun dapat dicapai tanpa kesulitan

Mencegah hotspot

  • S3 beroperasi dalam lingkungan paralel berskala sangat besar dengan puluhan juta drive, ratusan juta permintaan per detik, dan ratusan juta shard
  • Jika beban terkonsentrasi pada disk atau node tertentu, performa seluruh sistem bisa menurun
  • Strategi utama untuk mencegahnya:
    • 1. Distribusi acak lokasi penyimpanan data
    • 2. Rebalancing berkelanjutan
    • 3. Ekspansi skala sistem

  • 1. Shuffle sharding & Power of Two

    • Lokasi penyimpanan awal data disebarkan secara acak
    • Menerapkan algoritma Power of Two Random Choices:
      • Dengan memilih node yang lebih ringan bebannya dari dua node acak, load balancing yang efektif dapat dicapai

  • 2. Rebalancing

    • Temperatur data: memanfaatkan karakteristik bahwa data baru lebih panas (lebih sering diakses) untuk melakukan rebalancing berkala atas ruang dan I/O
      • Semakin tua data, semakin rendah frekuensi aksesnya, sehingga kapasitas I/O keseluruhan penyimpanan meningkat
    • S3 menyebarkan ulang cold data untuk memaksimalkan pemanfaatan ruang dan sumber daya
    • Saat rak baru ditambahkan (misalnya 20 PB/rak, 1000×20 TB), distribusi aktif ke kapasitas kosong diperlukan

  • 3. Chill@Scale

    • Efek skala: semakin independen workload, semakin kecil burst concurrency, sehingga terjadi decorrelation yang meratakan beban agregat
    • Semakin besar sistem, semakin kecil kesenjangan puncak/rata-rata, dan semakin baik prediktabilitas
    • Artinya, meski pola penggunaan berulang antara lonjakan dan diam, dalam skala besar semuanya saling meniadakan sehingga beban tetap dapat diprediksi

Budaya operasional, keandalan, dan teknik lainnya

  • Melalui shuffle sharding di level DNS, S3 mengejar isolasi antar tenant dan distribusi yang merata pada tingkat name resolver
  • Rollout software juga dilakukan secara bertahap dan tanpa downtime seperti EC, dan transisi ShardStore pun dilakukan tanpa dampak pada layanan
  • Budaya durabilitas: keandalan dijaga lewat proses seperti deteksi kegagalan berkelanjutan, chain of custody, pemodelan ancaman terhadap durabilitas, dan verifikasi formal

Mengapa ini penting: tren infrastruktur data berbasis S3

  • Seiring meluasnya arsitektur stateless, pola di mana node aplikasi melepaskan state dan menyerahkan persistensi, replikasi, dan load balancing ke S3 semakin berkembang
    • Contoh: Kafka Diskless(KIP-1150), SlateDB, Turbopuffer, Lucene on S3, integrasi object storage di ClickHouse/OpenSearch/Elastic, dan lain-lain
  • Keuntungannya adalah elastic scaling, penyederhanaan operasi, dan penghematan biaya, sedangkan kekurangannya adalah potensi kenaikan latensi, sehingga trade-off tiga unsur latensi, biaya, dan durabilitas harus dirancang sesuai workload

Ringkasan

  • AWS S3 adalah layanan penyimpanan multitenan berskala besar yang mengatasi keterbatasan media penyimpanan lambat dengan paralelisme skala besar, load balancing, dan data sharding
  • Dengan Erasure Coding, distribusi acak, rebalancing berkelanjutan, hedge request, dan teknik lain, S3 memperoleh stabilitas dan performa
  • Pada awalnya berfokus pada backup dan media, tetapi kemudian berkembang menjadi penyimpanan utama untuk infrastruktur big data seperti analitik data dan machine learning
  • Arsitektur berbasis S3 memungkinkan skalabilitas stateless, sekaligus secara efektif mendelegasikan persoalan durabilitas, replikasi, dan load balancing ke AWS
  • Hal ini juga memberikan penghematan biaya cloud dan efisiensi pengelolaan

Bacaan terkait

2 komentar

 
shakespeares 2025-10-05

Kalau teknologinya tidak bagus, sepertinya tidak akan menghasilkan keuntungan.
 
GN⁺ 2025-09-27
Komentar Hacker News

  • Ada beberapa kesalahan fakta, tetapi tidak terlalu memengaruhi alur artikel. Contohnya, klaim bahwa S3 memakai skema sharding 5:9, padahal S3 sebenarnya menggunakan berbagai skema sharding, dan setahu saya 5:9 bukan salah satunya. Rasio 1,8 byte fisik per 1 byte logis adalah angka yang sangat buruk dari sudut pandang biaya HDD. Sebenarnya ada cara untuk menurunkan rasio itu, sekaligus memperlebar paralelisme dan meningkatkan ketersediaan. Misalnya, perlu dipikirkan berapa banyak shard yang bisa hilang sebelum objek menjadi tidak bisa di-GET saat seluruh AZ mati

    • Saya memahami dari video YouTube ini di menit 42:20 bahwa S3 menggunakan skema sharding tersebut. Kalau Anda tahu lebih banyak, saya penasaran

    • Sulit rasanya memahami secara intuitif bagaimana rasio 1,8x bisa diturunkan sambil sekaligus meningkatkan ketersediaan. Jika replika lebih sedikit, bukankah risiko kehilangan data saat gangguan AZ akan membesar? Saya kira AWS menyediakan replika yang sepenuhnya independen di 3 AZ. Dan penjelasan bahwa untuk membaca satu chunk 16MB justru lebih cepat jika membaca 4MB dari 5 hard drive berbeda tetap terasa menakjubkan

    • VAST Data menggunakan skema 146+4. (tautan)

  • Saya senang membaca tulisan ini, tetapi jawaban untuk pertanyaan di judul terlalu jelas: paralelisme

    • Saya hampir tidak pernah memikirkan kecepatan I/O storage dalam skala sebesar itu. Dulu saya pernah memakai RAID0 untuk membuat hard disk menulis lebih cepat, tapi itu sudah lama sekali. Awalnya saya kira mereka akan memakai pendekatan menarik seperti caching atau tiering. Baru setelah membaca saya merasa, ya tentu saja jawabannya paralelisme. Namun, saya tidak sampai memikirkan detail implementasi S3 atau cara koreksi kesalahannya. Kata kuncinya memang paralelisme, tetapi detailnya memberi banyak wawasan. Saya kira minio juga akan punya cerita skalabilitas yang mirip: lagi-lagi paralelisme

    • Saya rasa judul artikelnya agak membingungkan karena hanya berfokus pada throughput puncak total S3. Pertanyaan yang benar-benar menarik menurut saya adalah, "bagaimana mungkin throughput GET bisa melampaui throughput maksimum HDD". Jika hanya memakai replikasi sederhana, Anda bisa menunjuk banyak HDD dan menjalankan GET secara paralel sehingga throughput total S3 naik, tetapi pada akhirnya tetap dibatasi oleh throughput tiap HDD * jumlah permintaan GET. Namun S3 tampaknya tidak memiliki batas ini, dan di situlah letak bagian yang rahasia sekaligus menarik

    • Jika Anda menggabungkan jutaan hard disk, Anda mendapatkan bandwidth IO yang sangat besar

    • Terdengar seperti logika, "cara pergi ke bulan itu jelas: perjalanan"

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    Secara rata-rata, jika dua titik terdistribusi uniform pada interval [0,1], nilai harapan jaraknya bukan 0,5 melainkan 1/3. Jika waktu seek full platter adalah 8ms, maka waktu seek rata-ratanya 2,666ms

    • Pada drive modern, full seek lebih dekat ke 25ms daripada 8ms. Jika ingin mengujinya sendiri, bila Anda punya hard disk dan hak root, Anda bisa memakai fio dengan opsi --readonly lalu menjalankan pembacaan bergantian dari dua ujung disk. Ada juga paper bagus yang menjelaskan mengapa angka 1/3 tidak akurat untuk drive modern (di sini). Jika ada pertanyaan lain tentang mekanik atau performa disk drive, saya bisa menjawabnya

    • Saat bergerak antartrek, head mengalami akselerasi. Semakin pendek jaraknya, semakin rendah kecepatan puncaknya, dan ada juga latensi tetap tertentu seperti settling time, sehingga rata-rata 4ms bisa saja benar dalam praktik

    • Karena platter berbentuk lingkaran, yang benar bukan distribusi uniform [0, 1] melainkan distribusi lingkaran satuan pada [0, 2pi], dan karena platter hanya berputar ke satu arah, jarak harus selalu dihitung searah jarum jam.
      Untuk menyederhanakan masalah, jika titik awal di 0 derajat dan titik tujuan di posisi acak, berapa jarak rata-ratanya? Karena panjang busur 0-180 derajat dan 180-360 derajat sama, jarak rata-ratanya menjadi 180 derajat. Artinya, half-platter seek tepat setengah dari full-platter seek

  • Jika ingin menebak apakah S3 masih memakai HDD untuk layanan utamanya, Anda bisa melihat harganya dan mengonversinya berdasarkan IOPS. Tarif permintaan GET/PUT S3 cukup mahal sehingga AWS memang punya ruang untuk membiarkan sebagian kapasitas disk menganggur demi melayani tenant berperforma tinggi. Namun tidak lebih dari sedikit lebih mahal dari itu

  • Saya penasaran apakah sebagian S3 berjalan di atas SSD. Saya mengira bahkan S3 standar pun berbasis SSD, dan hanya tier lambat yang memakai HDD atau sistem yang lebih lambat

    • KeyMap Index milik S3 menggunakan SSD. Pada titik ini, sepertinya SSD juga sudah dipakai untuk cache objek panas atau sebagian dari produk one zone yang baru

    • Data yang benar-benar disimpan kemungkinan besar hampir semuanya ada di HDD. Namun metadata, indeks, dan semacamnya kemungkinan memakai storage flash yang jauh lebih cepat. Server MDS pada cluster Ceph skala kecil pun biasanya begitu, dan skala S3 jauh lebih besar

    • Sudah sempat disebut di atas, tetapi untuk tier standar, tarif permintaan cukup tinggi sehingga bahkan jika ada pelanggan dengan rasio IOPS/TB tinggi, secara biaya masih efisien untuk membiarkan sebagian kapasitas disk menganggur. Tetapi kalau lebih mahal dari itu, keuntungannya hilang. HDD modern menyimpan sekitar 30TB, dan meski saya tidak tahu AWS membelinya dengan harga berapa, saya perkirakan sekitar 300-500 dolar. Jauh lebih murah dibanding SSD 30TB. Selain itu, HDD seperti ini bisa dipasang dalam sistem berkepadatan tinggi, misalnya 100 drive dalam 4U, dengan tambahan hanya sekitar 25% dari total biaya. Sebaliknya, box hardware yang mendukung SSD dalam jumlah besar jauh lebih mahal per slot

    • Saya menduga S3 Express One Zone berbasis SSD. Tetapi tampaknya Amazon tidak menyatakannya secara terbuka

    • Metadata hampir pasti disimpan di SSD. Objek panas yang sering dibaca mungkin juga di-cache di SSD

  • Menarik bahwa meskipun harga HDD terus turun, tarif S3 tetap sama setidaknya selama 8 tahun. Kurangnya persaingan penurunan harga membuat struktur tarif tinggi itu tetap bertahan. Bisa dibayangkan betapa besarnya keuntungan yang dihasilkan ini bagi AWS

    • Kebijakan harga AWS mirip di semua layanannya. Misalnya, instance EC2 m7a.medium berharga 50 dolar per bulan untuk on-demand, dan 35 dolar jika reserved 1 tahun. Bahkan jika dibandingkan layanan perusahaan lain dengan spesifikasi mirip, daya saingnya jauh tertinggal

    • Ada juga pengaruh inflasi, jadi walaupun tarif nominal sama, secara riil harganya memang turun. Namun saya setuju bahwa inflasi tercermin jauh lebih lambat daripada laju kemajuan teknologi

    • Saya rasa penghematan biaya bukan tujuan utama dari insentifnya. Jika melihat perusahaan seperti Splunk atau CrowdStrike yang menyimpan data dalam jumlah sangat besar di AWS, ada sangat banyak data berulang, lalu mereka membebankan biaya itu apa adanya ke pelanggan dan hanya menerapkan deduplikasi secara sederhana. Jika biaya diturunkan, justru muncul insentif untuk lebih banyak penggunaan yang tidak perlu

    • Saya penasaran apakah penurunan harga HDD memang masih besar. Dalam beberapa tahun terakhir, laju penurunan harga per GB hard disk sudah banyak melambat, sehingga SSD tampaknya akan segera menyusul

  • Untuk bacaan S3 yang lebih menarik, saya merekomendasikan "Building and operating a pretty big storage system called S3"

  • Saya penasaran seperti apa performa nyata rustfs

  • Melihat penyebutan penggunaan puluhan juta HDD, jika HDD enterprise berkapasitas 10-20TB, kita bisa memperkirakan total kapasitas AWS S3 ada di kisaran ratusan exabyte. Sangat mungkin ini adalah sistem storage terbesar di bumi

    • Jika hardwarenya sudah di-upgrade sejak 2013, pusat data tertentu di Utah bisa saja melampaui kapasitas itu (artikel terkait)

    • HDD enterprise saat ini sudah 30TB, dan sebentar lagi kemungkinan bisa mencapai 50TB

  • Saya ingin tahu layanan open source apa yang dioptimalkan untuk HDD dan bisa memberikan performa serupa. Proyek-proyek utama seperti MinIO, Swift, Ceph+RadosGW, dan SeaweedFS semuanya merekomendasikan deployment khusus flash. Belakangan saya sedang melihat proyek bernama Garage, tetapi desainnya cukup berbeda, misalnya tidak memakai EC

    • Ceph+RadosGW juga bisa bekerja cukup baik dengan HDD. Hanya saja, pool indeks perlu memakai SSD, dan Anda perlu punya ekspektasi realistis tentang angka IOPS yang bisa didapat dari pool HDD. IOPS di sisi klien pada praktiknya akan berlipat ganda beberapa kali, dan S3 juga memecahkan masalah ini dengan sangat banyak HDD. Untuk storage besar 4MB yang bersifat streaming, ini bukan masalah besar, tetapi jika Anda banyak membaca/menulis key kecil secara acak atau ada banyak akses tersebar ke satu key, performa backend menjadi penting

    • Lustre/ZFS juga bisa mencapai kecepatan serupa. Namun, jika butuh IOPS tinggi, Lustre memerlukan flash di MDS, sedangkan ZFS membutuhkan SSD log khusus

    • Semua layanan ini memerlukan sangat banyak drive kelas data center agar bisa mencapai performa yang sama. Hanya sangat sedikit deployment yang benar-benar menangani skala seperti ini. Karena itu, flash lebih efisien untuk akses cepat dari sisi ruang/biaya

    • SeaweedFS telah berkembang pesat dalam beberapa tahun terakhir dan kini mendukung RDMA serta EC

    • Di tempat kerja saya sebelumnya, kami menjalankan object storage berbasis SwiftStack, dengan metadata disimpan di SSD dan data objek di HDD biasa. Itu bekerja dengan cukup baik