Membangun dan Mengoperasikan Sistem Penyimpanan yang Cukup Besar Bernama S3

Pembangunan dan pengoperasian S3

• S3 merupakan singkatan dari Amazon Simple Storage Service, dan mengacu pada sistem penyimpanan berskala besar.
• Andy Warfield bekerja di S3 dan memperoleh pemahaman yang luas tentang sistem tersebut.
• S3 adalah layanan yang mencakup beragam area, mulai dari pengalaman performa pelanggan hingga mekanika hard disk.

17 tahun lalu, di kampus universitas yang jauh...

• S3 diluncurkan pada 14 Maret 2006 dan tahun ini merayakan ulang tahunnya yang ke-17.
• Warfield menyelesaikan gelar doktornya di University of Cambridge, ikut serta dalam proyek Xen, lalu mendirikan startup bernama XenSource.
• XenSource berkembang dan kemudian diakuisisi oleh Citrix, dan Warfield belajar banyak tentang pertumbuhan bisnis serta pengelolaan tim.

Cara kerja S3

• Setelah bergabung dengan Amazon, Warfield mempelajari prinsip kerja S3 dari Seth Markle, salah satu engineer awal S3.
• S3 adalah layanan object storage dengan HTTP REST API, yang terdiri dari frontend, layanan namespace, storage fleet dengan hard disk, dan fleet yang menjalankan pekerjaan latar belakang.
• S3 tersusun dari ratusan microservice, dan interaksi antar tim dilakukan melalui kontrak pada tingkat API.

Pengamatan awal

• S3 adalah ekosistem yang terus berevolusi, melampaui perangkat lunak dan juga mencakup perangkat keras serta manusia.
• Skala S3 terdiri dari kumpulan layanan yang masing-masing di-scale-out, sehingga butuh waktu untuk benar-benar memahami besarnya sistem ini.

Skala teknis: fisika penyimpanan

• S3 adalah sistem yang sangat besar dan menggunakan jutaan hard disk.
• Hard drive merupakan keajaiban teknologi dan inovasi, sekaligus sangat efisien dari sisi biaya.

Manajemen panas: penempatan data dan performa

• Di S3, dilakukan optimasi untuk memecahkan masalah yang disebut 'manajemen panas' dengan mendistribusikan permintaan I/O secara merata ke banyak hard drive.

Replikasi: penempatan data dan durabilitas

• S3 menggunakan skema redundansi seperti replikasi dan erasure coding untuk menjamin durabilitas data dan mengelola panas.

Dampak skala: strategi penempatan data

• Dengan menempatkan data seluas mungkin ke sebanyak mungkin disk, data pelanggan hanya menempati porsi yang sangat kecil di tiap disk, sehingga tercapai isolasi workload.

Faktor manusia

• Kompleksitas S3 tidak hanya berasal dari faktor teknis, tetapi juga dari faktor manusia.
• Amazon mendorong engineer dan tim untuk gagal dengan cepat dan aman, serta tetap fokus menyediakan storage dengan durabilitas tinggi.

Memperluas diriku sendiri: menyelesaikan masalah sulit yang dimulai dan diakhiri dengan 'ownership'

• Warfield mengalami perluasan skala pribadi di Amazon, sambil mempelajari skala perangkat lunak, manusia, dan bisnis.
• Di Amazon, ada penekanan kuat pada 'ownership', yang membantu memahami struktur organisasi dan pendekatan engineering.

Opini GN⁺

• S3 bukan sekadar layanan penyimpanan, melainkan ekosistem kompleks yang menggabungkan perangkat keras, perangkat lunak, dan faktor manusia.
• Tulisan ini memberikan wawasan bagi software engineer pemula yang ingin memahami skala dan kompleksitas S3.
• Budaya 'ownership' di Amazon merupakan elemen penting yang memotivasi tim dan individu untuk mengejar inovasi dengan rasa tanggung jawab yang lebih besar.

[GN⁺]

Komentar Hacker News

• Tingkat kesalahan 1 per 10^15 permintaan adalah hal yang cukup sering terjadi di dunia nyata, dan merupakan sesuatu yang harus dipertimbangkan di S3.

  • Saat bekerja di AWS, saya ingat bahwa pada skala S3, kejadian 1 banding 1 miliar terjadi setiap hari, dan bahkan kejadian dengan probabilitas sangat rendah yang biasanya tidak perlu dikhawatirkan tetap harus dipertimbangkan dan ditangani.
  • Saya senang bisa membaca tentang ShardStore, terutama verifikasi formal dan property-based testing yang sangat mengesankan. Layanan generasi sebelumnya terkenal penuh bug, tetapi setidaknya dirancang dengan baik berkat para engineer S3 yang terobsesi untuk gagal dengan aman demi mencegah kehilangan data.

• Bekerja di bidang genomika, selama 10 tahun terakhir saya telah menangani banyak penyimpanan data berukuran petabyte.

  • Berdasarkan pengalaman menggunakan berbagai sistem penyimpanan seperti AWS S3, GCP GCS, Ceph, Gluster, dan sistem HP, saya sangat menghargai besarnya upaya yang dibutuhkan untuk mengoperasikan sistem-sistem ini.
  • Manfaat berbagi disk IOPS dengan banyak pelanggan lain sangat besar, dan sangat sulit untuk mengatasinya pada satu sistem saja.
  • Untuk cluster hardware co-located, kami harus menyesuaikan sistem batch agar pada pekerjaan berskala besar, IO dapat diperlakukan sebagai sumber daya yang bisa dialokasikan seperti RAM atau CPU.
  • S3 dan GCP memang mahal, tetapi performanya sepadan dengan biayanya.

• Hal-hal yang bisa kita bangun jika S3 menggunakan protokol berbasis OAuth2 untuk mendelegasikan akses baca/tulis.

  • Kita membutuhkan protokol berbasis HTTP yang memungkinkan aplikasi mengakses data atas nama pengguna.
  • Google Drive adalah yang paling mendekati hal itu, tetapi ada masalah penyedia tunggal, dan sangat disayangkan remoteStorage tidak pernah populer.
  • Saya berharap Solid berhasil, tetapi terasa rumit.
  • Solusi saya sendiri untuk masalah ini adalah gemdrive.io, tetapi saat ini saya sedang fokus pada bagian lain dari stack self-hosting saya.

• Penjelasan tentang spesifikasi hard drive IBM RAMAC tahun 1956.

  • Spesifikasi kapasitas penyimpanan 3.75 MB dan biaya sekitar $9,200 per terabyte mungkin tidak akurat.
  • Situs lain menyarankan harga belinya sekitar $10,000 per megabyte, jadi spesifikasi yang benar seharusnya $9,200 per megabyte.

• Menangani autentikasi dalam sistem terdistribusi itu sangat sulit.

  • Pada skala AWS, autentikasi terasa seperti sihir, dan AWS memiliki model izin yang kaya sehingga perubahan autentikasi dapat dipropagasikan melalui infrastruktur dalam kecepatan sub-milidetik.
  • Tidak seperti layanan lain, di S3 izin berada pada resource, yang mungkin dilakukan demi kecepatan.

• Sebagai engineer yang sangat berpengalaman dengan agenda teknis, saya menghabiskan lebih banyak waktu untuk mengembangkan dan menjelaskan masalah dengan jelas daripada memberikan ide.

  • Untuk berhasil dalam peran seperti itu, fokuslah pada memperjelas masalah dan mendukung solusi, sambil mencari cara untuk membantu tim engineering yang kuat agar memiliki kepemilikan atas solusinya.

• Senang melihat karyawan Amazon berbicara secara terbuka tentang cara kerja internal S3.

  • Saya ingin mendengar lebih banyak tentang cara kerja Glacier, dan karena media penyimpanan yang digunakannya masih belum diungkapkan, ada banyak spekulasi tentang hal itu.

• Bagian yang menjelaskan kepala hard drive dengan analogi pesawat 747.

  • Itu adalah pekerjaan yang sangat presisi, seperti pesawat yang mengelilingi bumi 25,000 kali lalu hanya sekali membuat kesalahan hingga meleset dari satu helai rumput.

• Kembali ke masa S3 KeyMap, kami belajar bahwa bahkan setelah mengidentifikasi objek/partisi/bucket terpanas, masalahnya tidak bisa diselesaikan hanya dengan memindahkannya.

  • Solusi sebenarnya adalah membagi beban partisi host ke dalam kuartil, lalu memindahkan partisi kuartil kedua ke host dengan beban paling rendah.
  • Hasilnya, tingkat kesalahan berubah dari stabil di sekitar 1% menjadi hari-hari tanpa kesalahan, sehingga kami memperbarui alert menjadi jauh lebih ketat.

• S3 bukan sekadar penyimpanan sederhana, melainkan sebuah standar.

  • Beberapa tempat menyediakan penyimpanan yang kompatibel dengan S3, dan meski tidak jelas seberapa terbuka standar itu atau apakah harus membayar Amazon untuk boleh menyebutnya "kompatibel dengan S3", ini tetap hal yang sangat keren.