Inovasi Berkelanjutan: Sejarah Singkat Block Storage AWS
(allthingsdistributed.com)- AWS EBS berawal dari block storage terhubung jaringan untuk EC2, lalu berkembang dari layanan berbasis HDD bersama menjadi armada SSD terdistribusi yang memproses lebih dari 140 triliun operasi per hari
- Keterbatasan performa awal bukan hanya berasal dari 120–150 IOPS HDD dan latensi rata-rata 6–8 ms, tetapi juga dari masalah noisy neighbor yang muncul ketika workload beberapa pelanggan berbagi disk yang sama
- Dengan adopsi SSD, volume Provisioned IOPS pada 2012 menyediakan hingga 1.000 IOPS dan latensi rata-rata sekitar 2–3 ms, tetapi bottleneck berpindah ke jaringan, hypervisor, dan antrean perangkat lunak
- Tim EBS menginstrumentasi seluruh jalur IO dan melakukan perbaikan per lapisan, mulai dari antrean Xen, offloading Nitro, pemrosesan enkripsi di hardware, tuning TCP, hingga protokol transport SRD
- Peningkatan performa dilakukan bukan lewat penulisan ulang besar-besaran, melainkan melalui migrasi tanpa downtime, perubahan independen oleh tim kecil, pengukuran berkelanjutan, dan perbaikan bertahap yang bisa di-rollback
Dari block storage untuk EC2 menjadi armada SSD berskala besar
- EBS dimulai pada 20 Agustus 2008, sekitar dua tahun setelah peluncuran beta EC2, dari gagasan untuk menyediakan block storage terhubung jaringan bagi instance EC2
- Saat itu tim memiliki satu atau dua pakar storage dan beberapa engineer sistem terdistribusi, lalu mulai membangun layanan berdasarkan pengetahuan tentang sistem komputer dan jaringan
- Sejak itu, EBS berubah dari produk HDD bersama menjadi layanan yang dapat menyediakan ratusan ribu IOPS untuk satu instance EC2
- IOPS yang kini dapat diberikan ke satu instance lebih besar daripada tingkat yang dulu diberikan ke seluruh Availability Zone pada masa awal berbasis HDD
- Secara keseluruhan, EBS memproses lebih dari 140 triliun operasi per hari di armada SSD terdistribusi
- Workload utamanya adalah disk sistem instance EC2, bentuknya mirip menyediakan peran hard disk di server fisik sebagai storage jaringan
- Pelanggan menganggap durabilitas penting, tetapi performa dan ketersediaan yang terhubung langsung dengan pengalaman EC2 juga sama pentingnya
- Volume io2 Block Express dan snapshot volume disediakan sebagai elemen dasar untuk mencapai durabilitas tinggi
- Performa dan ketersediaan volume EBS hampir langsung tercermin dalam pengalaman aplikasi berbasis EC2
Keterbatasan awal akibat antrean dan HDD
- Dalam sistem komputer, permintaan storage diproses melalui beberapa antrean di antara CPU, bus, dan perangkat
- Pada storage jaringan, beberapa antrean terbentuk di antara kernel sistem operasi, adapter storage, fabric storage, adapter storage target, dan media penyimpanan
- Saat EBS pertama kali dibuat pada 2008, pasar storage terutama didominasi HDD, dan latensi didominasi oleh media penyimpanan itu sendiri
- Hard disk adalah perangkat mekanis sehingga memiliki batasan fisik
- Selama puluhan tahun, performa HDD bertahan di kisaran sekitar 120–150 operasi per detik, dengan latensi IO rata-rata 6–8 ms
- Karena antrean dan pengurutan ulang perintah di dalam drive, tail latency bisa meningkat hingga ratusan ms
- Karena latensi end-to-end EBS saat itu berada dalam satuan puluhan ms, tambahan puluhan mikrodetik dari jaringan hanya menjadi porsi kecil dari total latensi
- Performa HDD sangat dipengaruhi oleh operasi lain yang menumpuk dalam antrean
- Permintaan acak kecil yang tersebar di media membutuhkan waktu lebih lama untuk ditemukan dan diakses dibanding beberapa permintaan besar yang berdekatan
- Menyebarkan pelanggan ke beberapa disk mengurangi latensi di atas puncak workload terpanas, tetapi perilaku tidak teratur menyebar ke lebih banyak pelanggan
- Noisy neighbor, ketika satu workload memengaruhi workload lain, menjadi masalah bisnis penting
- AWS melihat perlunya isolasi performa yang kuat untuk meningkatkan kualitas pengalaman pelanggan
- Perubahan algoritme penjadwalan disk dan penyebaran workload ke lebih banyak spindle hanya menghasilkan perbaikan kecil dan bertahap
Pentingnya instrumentasi yang terlihat setelah adopsi SSD
- Sekitar 2011, SSD menjadi lebih populer dan mulai tersedia dalam kapasitas yang layak dipertimbangkan AWS
- SSD tidak memiliki pergerakan lengan fisik untuk mencari data, permintaan acak hampir secepat permintaan sekuensial, dan memiliki beberapa kanal antara controller dan chip NAND
- EBS pertama-tama membuat tipe server storage baru berbasis SSD dan tipe volume baru bernama Provisioned IOPS
- Peluncuran tipe volume baru bukan pekerjaan kecil, dan workload yang dapat memanfaatkannya juga terbatas
- Berbeda dari harapan bahwa mengganti HDD dengan SSD akan menyelesaikan hampir semua masalah, masalah noisy neighbor tidak otomatis hilang
- Provisioned IOPS yang diluncurkan pada Agustus 2012 menyediakan hingga 1.000 IOPS
- 10 kali lebih tinggi daripada volume EBS standard yang ada sebelumnya
- Latensi rata-ratanya sekitar 2–3 ms, peningkatan 5–10 kali
- Pengendalian outlier juga jauh membaik
- Pada titik ini, EBS hanya memiliki telemetri dasar, dan diperlukan instrumentasi yang lebih rapat untuk menentukan apa yang perlu diperbaiki
- Tim membangun cara untuk melacak setiap IO di beberapa titik
- initiator klien EBS
- stack jaringan
- mesin durabilitas storage
- sistem operasi
- Selain memantau workload pelanggan, mereka membuat canary test yang terus memeriksa dampak positif dan negatif perubahan pada workload yang sudah dikenal dengan baik
Perbaikan yang membagi hardware dan software bersama-sama
- Telemetri baru memperjelas area investasi awal
- Jumlah antrean di seluruh sistem perlu dikurangi
- Ada ruang untuk menurunkan kompleksitas jalur IO hypervisor Xen yang digunakan di EC2
- Optimasi perangkat lunak jaringan diperlukan
- Mesin durabilitas inti memerlukan penempatan data on-disk, optimasi cache line, dan adopsi model pemrograman asinkron
- Masalah performa sistem AWS sering melintasi beberapa lapisan stack hardware dan software sekaligus
- EBS menggerakkan tim server storage dan tim klien secara paralel, serta melibatkan engineer hypervisor EC2 dan grup performa jaringan internal AWS
- Organisasi pengembangan juga dibagi dengan cara divide and conquer seperti sistem perangkat lunak
- Tim pengembangan server storage monolitik direorganisasi menjadi tim kecil per area seperti replikasi data, durabilitas, dan snapshot hydration
- Setiap tim dapat melakukan iterasi dan menerapkan perubahan secara independen berdasarkan pengujian yang ketat
- Blueprint yang dibuat pada 2013 tidak sama dengan bentuk EBS hari ini, tetapi memberikan arah pergerakan
- Saat itu belum diperkirakan bahwa Amazon suatu hari akan membuat SSD sendiri dan memiliki stack teknologi yang disesuaikan dengan kebutuhan EBS
Menghapus bottleneck dari Xen ke Nitro dan SRD
- Hingga akhir 2017, semua instance EC2 berjalan di hypervisor Xen
- Jalur perangkat Xen memiliki ring queue tempat guest domain dan privileged driver domain bernama dom0 berbagi informasi, dan klien EBS berjalan sebagai perangkat blok kernel di dom0
- Dari instance hingga keluar dari host EC2, permintaan IO melewati beberapa antrean
- antrean perangkat blok instance
- Xen ring
- antrean perangkat blok kernel dom0
- antrean jaringan klien EBS
- Tim EBS menulis beberapa perangkat loopback untuk memisahkan dampak tiap antrean
- Meski latensi driver perangkat dom0 nyaris tidak ada, ditemukan bahwa throughput efektif seluruh sistem melambat ketika beberapa instance menghasilkan IO secara bersamaan
- EC2 diluncurkan dengan jumlah antrean perangkat blok dan jumlah entri antrean bawaan Xen
- Nilai bawaan ini ditetapkan berdasarkan hardware storage yang terbatas di lingkungan pengembangan Xen masa lalu
- Permintaan IO outstanding untuk seluruh host dibatasi menjadi 64, bukan batas per perangkat
- Pada 2013, pengembangan Nitro offload card pertama khusus jaringan sedang berlangsung
- Pemrosesan jaringan terdefinisi perangkat lunak VPC dipindahkan dari kernel Xen dom0 ke pipeline hardware khusus
- Data plane pemrosesan paket dipisahkan dari hypervisor sehingga siklus CPU instance pelanggan tidak perlu dipakai untuk memproses trafik jaringan
- Pendekatan yang sama diterapkan pada storage EBS
- Lebih banyak pemrosesan dipindahkan ke hardware untuk mengurangi antrean sistem operasi di hypervisor
- Pekerjaan berbasis interrupt di-offload sehingga waktu yang digunakan hypervisor untuk memproses permintaan berkurang
- Kartu Nitro kedua juga memiliki kemampuan hardware untuk memproses volume terenkripsi EBS tanpa dampak performa
- Materi kunci enkripsi dipisahkan dari hypervisor untuk menambah perlindungan data pelanggan
- Setelah EBS dipindahkan ke Nitro, bottleneck bergeser ke jaringan itu sendiri
- Parameter tuning TCP dan algoritme congestion control untuk data center modern ditinjau
- Dalam beberapa kasus, menambahkan latensi acak kecil pada permintaan server storage menghasilkan efek smoothing jaringan yang menurunkan latensi rata-rata dan outlier
- Tuning seperti ini tidak bertahan lama seiring performa dan skala sistem terus meningkat, sehingga pengukuran dan monitoring untuk mencegah regresi tetap diperlukan
- Pada 2014, pekerjaan berbasis Scalable Reliable Datagram(SRD) dimulai dengan tujuan membuat pendekatan yang lebih baik daripada TCP
- Makalah terkait adalah A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Persyaratannya mencakup peningkatan kemampuan pemulihan kegagalan dan pengalihan rute, serta kemudahan offloading hardware
- Dalam desain SRD, dua pengamatan menjadi penting
- Fokus dapat diarahkan pada desain jaringan data center AWS, bukan internet umum
- Pada storage, urutan eksekusi permintaan IO yang sedang berjalan dapat diatur ulang
- Biaya strict in-order delivery TCP dapat dihindari, dan permintaan lain dapat dikirim melalui beberapa jalur jaringan untuk dieksekusi saat tiba
- SRD digunakan bukan hanya untuk storage, tetapi juga untuk networking
- Pada Elastic Network Adapter(ENA) Express, SRD meningkatkan performa stack TCP guest
- Dengan memanfaatkan beberapa jalur jaringan serta mengurangi overflow dan antrean pada perangkat jaringan perantara, utilisasi jaringan yang lebih tinggi dapat dicapai
Cache SSD dan migrasi tanpa downtime
- EBS tidak puas dengan kondisi ketika hanya sebagian volume dan pelanggan memperoleh performa lebih baik, dan berupaya menyediakan manfaat SSD secara lebih luas
- Saat itu, jutaan volume pelanggan non-provisioned IOPS berjalan di ribuan server storage
- Sebagian volume tersebut masih ada hingga sekarang
- Membuang dan mengganti semua hardware akan sangat mahal
- Sasis server memiliki ruang kosong, tetapi satu-satunya posisi yang tidak mengganggu aliran udara pendingin adalah di antara motherboard dan kipas
- SSD kecil dan ringan, tetapi tidak boleh bergoyang di dalam sasis; setelah bantuan ilmuwan material serta trial and error, ditemukan hook and loop fastening tape industrial tahan panas
- Selama beberapa bulan pada 2013, EBS memasang 1 SSD secara manual ke masing-masing dari ribuan server
- Pada software, perubahan kecil ditambahkan untuk melakukan staging penulisan baru ke SSD, mengembalikan completion ke aplikasi, lalu melakukan flush asinkron ke HDD yang lebih lambat
- Pekerjaan ini dilakukan tanpa gangguan pelanggan
- Sejak awal, EBS dirancang dengan mempertimbangkan event maintenance tanpa downtime
- Volume EBS dapat di-retarget ke server storage baru, lalu server kosong dapat diperbarui atau dibangun ulang
- Kemampuan memindahkan volume pelanggan ke server storage baru berguna berkali-kali setelah itu
- Digunakan saat memperkenalkan struktur data yang lebih efisien untuk format on-disk
- Juga dipakai saat mengganti hardware lama dengan hardware baru
- Beberapa volume yang dibuat pada bulan-bulan awal peluncuran EBS pada 2008 masih aktif
- Volume semacam ini kemungkinan telah melewati ratusan server berbeda dan beberapa generasi hardware
- Pembaruan dan pembangunan ulang armada dilakukan tanpa dampak pada workload tersebut
Gaya kepemimpinan yang disesuaikan dengan perluasan performa
- Skala EBS berbeda dari lingkungan perusahaan kecil atau startup yang ada sebelumnya, bukan hanya secara teknis tetapi juga secara organisasi
- Jika pakar sistem terlibat dalam semua eskalasi, review commit, dan tinjauan perubahan desain, mereka dapat menjadi bottleneck performa organisasi
- Untuk mengatasi ini, eksperimen dilakukan bukan hanya pada kode, tetapi juga pada cara berkolaborasi
- Salah satu alat utama yang digunakan adalah peer debugging
- Beberapa engineer melihat kode dan terminal bersama-sama sambil melacak masalah
- Mereka menemukan kasus ketika lokasi dan cara locking untuk pembaruan critical data structure menjadi sumber masalah
- Biasanya masalah tidak terlihat, tetapi sesekali respons permintaan melambat; memperbaikinya menghilangkan salah satu sumber jitter
- Memberi engineer wewenang untuk bereksperimen dengan aman, mengurangi hambatan, tetapi tetap mempertahankan guardrail dapat menghasilkan hasil yang lebih baik
Perbaikan berkelanjutan, bukan penulisan ulang besar-besaran
- Perbaikan EBS berlangsung sebagai rangkaian perbaikan bertahap dari waktu ke waktu, bukan satu perubahan raksasa
- Pendekatan ini memungkinkan nilai bagi pelanggan dikirim lebih cepat, sekaligus memungkinkan arah disesuaikan berdasarkan pembelajaran dari perubahan workload pelanggan
- Pengalaman latensi EBS meningkat dari rata-rata lebih dari 10 ms per operasi IO menjadi IO submilidetik yang konsisten pada volume io2 Block Express berperforma tertinggi
- Perubahan ini dicapai tanpa membuat layanan offline untuk menyediakan arsitektur baru
- Pelanggan terus menginginkan performa yang lebih besar, dan tuntutan itu terus menjadi pendorong inovasi dan iterasi EBS
1 komentar
Komentar Hacker News
Senang sekali melihat tulisan ini di sini. Jika Anda punya ketertarikan sedikit saja pada sistem berskala besar, ini wajib dibaca.
Pada beban kerja sekuensial, disk magnetik modern bisa mencapai lebih dari 100MB/s untuk baca/tulis, tetapi pada beban kerja 4kB yang sepenuhnya acak, angkanya bisa turun hingga 400kB/s. Queuing dan scheduling memang membantu menghindari skenario terburuk, tetapi performa nyata bisa berbeda lebih dari 100 kali tergantung beban kerja, sehingga sangat sulit ditangani oleh sistem multi-tenant. Terutama untuk operasi baca, tidak ada jalan pintas seperti “tulis saja di tempat lain”.
Pelajaran terbesar dari Marc adalah bahwa untuk tahu apa yang rusak, pertama-tama kita harus bisa melihatnya dengan benar. Ia membuat visualisasi latensi, misalnya deret waktu histogram seperti di artikel, lalu menggunakan visualisasi itu untuk bercerita sehingga tim melihat pekerjaan yang harus dilakukan dengan cara yang benar-benar berbeda. Setiap puncak dalam histogram punya penyebab dan pekerjaan optimisasi masing-masing, dan investasi untuk melihat data performa secara mendalam dengan berbagai cara membuka efisiensi dan peluang yang sebelumnya tidak terlihat.
Proyek retrofit pada 2013, yang memasang satu SSD di masing-masing dari ribuan server, adalah salah satu kisah AWS favorit saya. Itu dimungkinkan karena sejak awal EBS volume dirancang agar dapat diarahkan ulang ke server storage baru, dan server kosong dapat diperbarui atau dibangun ulang, dengan mempertimbangkan event pemeliharaan tanpa downtime. Ini contoh bagus bahwa sistem terdistribusi bukan hanya untuk scale-out, tetapi juga memungkinkan kegagalan server ditoleransi secara alami dan data dipindahkan tanpa kehilangan, sehingga operasi skala besar bisa dilakukan.
Dick Lyon dari Google juga menggunakan pendekatan yang sama pada server storage Google, dan mulai slide ke-62 di https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers...., ia mengidentifikasi banyak queue dan kontensi sumber daya sebagai bottleneck utama block storage.
Ini mengingatkan masa lalu. Reddit adalah salah satu pengguna awal EBS pada 2008, dan kami merasa pintar karena menemukan bahwa membuat software RAID dari 5 EBS volume bisa meningkatkan IOPS.
Saat itu performa tiap volume sangat tidak konsisten, jadi kami menyalakan 7–8 volume, menjalankan beban baca/tulis, lalu memilih 5 yang performanya paling bagus dan menggabungkannya dengan Linux software RAID. Saat berjalan baik, efeknya sesuai harapan dan kadang menghasilkan IOPS lebih dari 5 kali satu node, tetapi saat buruk, hasilnya benar-benar mengerikan.
Kami tidak tahu bahwa pada software RAID, jika satu node lambat, seluruh RAID akan berjalan pada kecepatan volume paling lambat, dan akibatnya database tampak seperti rusak. Butuh waktu untuk mengetahui bahwa penyebabnya adalah RAID, dan mengeluarkan node buruk juga sulit. Software RAID tidak mau melepasnya sampai selesai menulis ke volume lambat itu.
Kami harus memasukkan EBS volume baru dan membangun ulang array, tetapi ini juga tidak bagus karena terhambat oleh IOPS volume baru. Setelah itu kami berhenti memakai software RAID tersebut, dan di Netflix kami hampir tidak memakai EBS. Saya menceritakan kesalahan yang kami buat di Reddit kepada siapa pun yang mau mendengar, dan bahkan sebelum saya bergabung, Netflix sudah menstandarkan diri pada hanya menggunakan disk lokal.
Sebagai catatan sampingan yang menarik, saat gangguan besar EBS di AWS terjadi, saya bekerja di Reddit dan sedang menonton Netflix sambil menunggu EBS pulih agar bisa memperbaiki database. Saat wawancara di Netflix, saya bertanya, “Bagaimana kalian tetap bertahan saat gangguan EBS?” dan mereka menjawab, “Oh, kami memang tidak memakai EBS.”
Saya senang membaca artikel ini.
Bagian yang menarik adalah, pada periode yang dibahas artikel, saya ingat AWS mengalami gangguan sekitar 4 hari karena EBS, dan EC2, EBS, serta RDS terdampak. Gangguan ini sangat mengguncang kepercayaan terhadap AWS.
Akibatnya ada reorganisasi, dan EBS mendapat investasi yang jauh lebih dalam sebagai layanan independen. Periode ini juga beririsan dengan masa ketika Apple menjadi pelanggan, serta saat AWS secara keseluruhan tumbuh pesat berkat adopsi startup seperti Netflix, Zynga, dan Dropbox.
Kisah teknis dan operasional seperti ini memang menarik, tetapi inovasi teknologi di production itu berantakan dan terjadi di atas latar kebutuhan bisnis dunia nyata. Saya berharap bisa mendengar lebih banyak kisah seperti itu juga.
Namun roda kembali berputar dan fokus kembali ke pengembangan fitur. Saya selalu mengingat tahun itu sebagai tahun dengan eskalasi paling sedikit selama saya berada di sana.
Saya penasaran dengan bagian “menambahkan sedikit latensi acak pada request ke server storage justru mengurangi latensi rata-rata dan outlier karena efek meratakan jaringan”. Bisa jelaskan mengapa begitu?
Jika tertarik, ada presentasi [0] dari 2009 tentang struktur internal Amazon S3. Presentasi itu dibuat berdasarkan materi internal tim S3, dan banyak hal di dalamnya juga memengaruhi cara EBS dikembangkan.
[0]: https://vimeo.com/7330740
Saya suka bagian tentang menambahkan SSD secara manual ke semua perangkat EBS pada 2013. Dilihat dari fotonya, tampaknya cukup mirip dengan Samsung SATA SSD
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Ingatan saya mungkin keliru, tetapi rasanya penggunaan SSD yang dipasang di blade Dell sudah dilakukan jauh sebelum itu. Sekitar 2010–2012, performa I/O benar-benar menjadi isu besar, dan itu adalah masa transisi dari hard disk berputar ke memori flash
Saya masih ingat bereksperimen dengan perangkat berbasis flash mentah yang sama sekali tidak punya penanganan error atau wear leveling. Itu tindakan gila, tetapi semua orang sangat membutuhkan lonjakan performa I/O besar yang didapat saat berpindah dari disk berputar ke silikon
Kecepatan disk meningkat begitu cepat sampai SKU pertama menjadi usang dalam 6 bulan. Untung saja saya tidak perlu menjelaskan langsung ke tim aset saat kami memensiunkan rack-rack itu beberapa tahun lebih awal dari rencana. Memasang model baru yang lebih padat dan lebih cepat membuat nilai lokasi rack jauh lebih tinggi
Saya teringat masa ketika membangun infrastruktur storage sebagai layanan sebelum ada open source yang layak dipakai. Kami beralih dari Sun SAN, Fibre Channel, dan Solaris ke GlusterFS di atas server storage Supermicro yang menjalankan Linux dan NFS, dan sebelum saya pergi pada 2007 skalanya hampir mencapai 2 PB
Saya juga teringat masa ketika menyelipkan SSD sebagai pengganti disk berputar saat server masih berjalan, lalu diam-diam merusak dan membangun ulang mdraid, terasa masuk akal saja. Alasannya, SATA cukup mendukung hot swap drive. Beralih dari disk berputar ke SSD meningkatkan IOPS sistem paling penting di platform sebesar 14 kali lipat
Di awal karier, saya menangani sistem secara menyeluruh di sebuah perusahaan internet yang skalanya besar secara teknologi dan operasi, bukan secara jumlah karyawan. Jumlah pelajaran yang saya dapat dalam waktu singkat benar-benar tidak masuk akal. Setelah meninggalkan perusahaan itu, saya menyadari bahwa kebanyakan orang hampir tidak pernah menghadapi masalah semacam itu sepanjang karier mereka, sehingga mereka juga tidak mempelajari pelajaran tersebut
Karena itu saya berpikir harus ada sistem kualifikasi profesional. Jika diwajibkan magang di bawah engineer berpengalaman, orang bisa mempelajari pengetahuan dan keterampilan yang sangat berharga, yang hanya bisa didapat lewat pengalaman, dalam waktu singkat, lalu bekerja jauh lebih efektif setelahnya. Dari sisi pewawancara kandidat pun, bukti pengalaman dan rekomendasi mentor akan sangat bernilai
Saya suka kalimat ini
“Cita-cita full-stack engineer yang banyak dipuji memang bernilai, tetapi dalam sistem yang dalam dan kompleks, sering kali lebih bernilai membentuk sekelompok spesialis yang mampu berkolaborasi dan bekerja kreatif melintasi seluruh stack serta area keahlian mendalam masing-masing”
Diagram pertama dalam tulisan itu tidak akurat atau isinya cukup lama. Pada komputer modern, sebagian besar PCIe lane terhubung langsung ke I/O hub CPU atau area Uncore, bukan melalui PCH terpisah seperti dulu
Ini perkembangan penting baik untuk throughput I/O maupun latensi. Selain itu, tulisannya bagus, dan berhasil menunjukkan bahwa pada akhirnya semuanya adalah queue
Saya akan memperjelas pada caption gambar bahwa strukturnya berasal dari era tersebut