Penemuan Ulang Berkelanjutan: Sejarah Singkat Block Storage di AWS

 (allthingsdistributed.com)
2 poin oleh GN⁺ 2024-08-23 | 1 komentar | Bagikan ke WhatsApp

Penemuan Ulang Berkelanjutan: Sejarah Singkat Block Storage di AWS

  • Pendahuluan

    • Marc Olson telah bekerja di tim Elastic Block Store (EBS) selama lebih dari 10 tahun.
    • EBS telah berkembang dari layanan block storage sederhana menjadi sistem penyimpanan jaringan berskala besar yang memproses lebih dari 140 triliun operasi per hari.
    • Tulisan ini membagikan proses evolusi EBS dan pelajaran penting yang didapat.

  • Sejarah awal EBS

    • EBS diluncurkan pada 20 Agustus 2008, dimulai dari ide sederhana untuk menyediakan block storage terhubung jaringan bagi instance EC2.
    • Pada awalnya EBS menggunakan hard disk drive (HDD) bersama, dan kini dapat menyediakan ratusan ribu IOPS untuk satu instance EC2.
    • Saat ini EBS memproses lebih dari 140 triliun operasi per hari melalui armada SSD terdistribusi.

  • Teori antrean

    • Cara sistem komputer berinteraksi dengan storage pada dasarnya tidak berubah.
    • CPU menaruh permintaan ke dalam antrean, lalu perangkat storage mengambil data dari memori CPU dan menyimpannya ke media yang tahan lama, atau sebaliknya mentransfer data ke memori CPU.
    • Teori antrean memainkan peran penting dalam memahami proses ini.

  • Peralihan dari HDD ke SSD

    • EBS awal menggunakan HDD, yang kinerjanya terbatas karena batasan fisik.
    • Dengan hadirnya SSD, permintaan acak pun bisa diproses hampir secepat permintaan berurutan.
    • Pada 2012, AWS merilis tipe server storage baru berbasis SSD dan tipe volume EBS baru bernama Provisioned IOPS.

  • Pengukuran dan pengelolaan

    • Pada 2012, EBS hanya memiliki telemetri dasar.
    • Untuk meningkatkan kinerja sistem, tim perlu mengetahui apa yang bermasalah lalu menyelesaikannya berdasarkan prioritas.
    • Mereka membangun cara untuk mengukur IO di berbagai subsistem dan mendeteksi perubahan melalui pemantauan berkelanjutan.

  • Pecah dan taklukkan dalam organisasi

    • Tim server storage EBS direorganisasi menjadi tim-tim kecil yang fokus pada area tertentu seperti replikasi data, durabilitas, dan hidrasi snapshot.
    • Setiap tim dapat mengiterasi dan mengirim perubahan secara independen.

  • Menantang asumsi

    • Tim menemukan bahwa pengaturan default hypervisor Xen membatasi kinerja.
    • Dengan kartu offload Nitro, tugas pemrosesan jaringan dan storage dipindahkan ke hardware.

  • Eksperimen tuning jaringan

    • Saat EBS dipindahkan ke Nitro, overhead jaringan itu sendiri meningkat.
    • Untuk meningkatkan kinerja jaringan, AWS mengembangkan protokol SRD (Scalable Relatable Diagram) sebagai pengganti TCP.

  • Kendala mendorong inovasi

    • Untuk memberikan manfaat SSD kepada semua pelanggan, AWS menambahkan SSD tanpa mengganti hardware yang ada.
    • SSD ditambahkan secara manual ke server, penulisan baru disimpan ke SSD terlebih dahulu, lalu di-flush ke HDD secara asinkron.

  • Refleksi tentang perluasan kinerja

    • Kisah pertumbuhan pribadi: transisi dari budaya perusahaan kecil ke organisasi berskala besar.
    • Sesi debugging bersama rekan membantu menyelesaikan masalah dan meningkatkan efisiensi tim.

  • Kesimpulan

    • EBS berkembang bukan lewat satu perubahan besar, melainkan melalui serangkaian perbaikan bertahap.
    • Kebutuhan pelanggan akan terus meningkat, dan itu menjadi pendorong untuk terus berinovasi dan beriterasi.

# Ringkasan GN⁺

  • Tulisan ini memberikan sudut pandang orang dalam tentang bagaimana EBS AWS berevolusi.
  • Dibahas berbagai tantangan teknis dan solusinya, seperti teori antrean, adopsi SSD, dan tuning jaringan.
  • Artikel ini menekankan pentingnya pengukuran dan pengelolaan berkelanjutan untuk peningkatan kinerja.
  • Produk dengan fungsi serupa antara lain Google Cloud Persistent Disk dan Microsoft Azure Disk Storage.

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-23
Komentar Hacker News

  • Jika Anda tertarik pada sistem berskala besar, artikel ini layak dibaca

    • Performa hard drive bergantung pada transaksi lain yang ada di antrean
    • Pada beban kerja acak 4kB, performa bisa turun drastis
    • Queueing dan scheduling memang membantu, tetapi performa nyata bisa berbeda lebih dari 100x tergantung beban kerja
    • Dalam sistem multi-tenant, ada tantangan khususnya pada operasi baca

  • Untuk menyelesaikan masalah, Anda harus mengetahui apa yang salah

    • Pelajaran terbesar yang dipelajari dari Marc adalah mengubah perspektif tim melalui visualisasi
    • Dengan menganalisis data performa dalam berbagai cara, kita bisa menemukan efisiensi dan peluang yang sebelumnya tidak terlihat

  • Proyek memasang SSD pada server EBS pada 2013 adalah salah satu kisah menarik AWS

    • Sistem ini sejak awal dirancang dengan mempertimbangkan maintenance event non-destruktif
    • Dengan membangun sistem terdistribusi, operasi dalam skala besar menjadi memungkinkan

  • Gangguan sekitar 4 hari di AWS disebabkan oleh EBS, dan ini mengguncang kepercayaan terhadap AWS

    • Akibatnya, investasi pada EBS meningkat
    • Ini juga bertepatan dengan periode ketika Apple menjadi pelanggan

  • Reddit adalah salah satu pengguna awal EBS pada 2008

    • Mereka mencoba meningkatkan IOPS dengan software RAID, tetapi performanya tidak konsisten
    • Butuh waktu untuk menyelesaikan masalah RAID
    • Netflix tidak menggunakan EBS

  • Menambahkan latensi acak dapat menurunkan latensi rata-rata dan juga outlier

  • Ada banyak pelajaran yang didapat saat bekerja di perusahaan internet berskala besar

    • Melalui proses apprenticeship, pengetahuan dan keterampilan penting bisa dipelajari dengan cepat
    • Saat wawancara, pengalaman dan rekomendasi dari mentor sangat membantu

  • Bagian tentang memasang SSD secara manual ke semua unit EBS pada 2013 terasa menarik

    • Antara 2010-2012, performa I/O adalah isu yang sangat penting

  • Pada 2009, ada presentasi tentang internal Amazon S3

    • Presentasi ini memengaruhi pengembangan EBS

  • Pada masa awal cloud, hardware umum digunakan, tetapi sekarang hardware khusus dipakai untuk masing-masing layanan

    • AWS menggunakan chip Graviton, Inferentia, dan Tranium
    • Google menggunakan TPU dan kartu keamanan Titan
    • Azure menggunakan FPGA dan Sphere

  • Diagram pertama salah atau sudah usang

    • Komputer modern umumnya memiliki sebagian besar PCIe lane yang terhubung langsung ke CPU
    • Ini adalah perkembangan penting untuk throughput dan latensi I/O

  • Sedang mencari cara terbaik untuk menyediakan direktori dataset 256GB yang cepat pada instance EC2 baru

    • Saat ini menggunakan volume EBS, tetapi pembaruannya merepotkan
    • EFS terlalu lambat
    • SSD instance storage bersifat sementara
    • FSx Lustre belum dicoba