Analisis pascainsiden penghentian layanan Tarsnap

• Server pusat Tarsnap di Amazon EC2 us-east-1 turun dengan status failed system status check, sehingga layanan berhenti sekitar 26 jam 16 menit mulai sekitar 2023-07-02 13:07:58 UTC
• Gangguan terdeteksi pada 13:10 UTC, tetapi setelah reboot tak terduga diterapkan kebijakan operasional untuk mematikan start otomatis kode server agar pemeriksaan dilakukan langsung oleh manusia
• Pemulihan dilakukan dengan membaca header metadata dari filesystem berstruktur log di Amazon S3 dan memutar ulang pekerjaan secara berurutan di lokal; tahap pertama selesai pada 2023-07-03 01:49:49 UTC
• Dalam proses rekonstruksi status, terungkap kasus yang belum tervalidasi pada penanganan machine re-owned yang ditulis pada 2014 serta kelalaian inisialisasi logika resume, dan batas throughput disk juga memperlambat pemulihan
• Tarsnap tidak memiliki SLA yang tegas, tetapi mengikuti kebijakan memberi kredit untuk gangguan yang dinilai adil; pada 2023-07-13, semua akun menerima kredit 50% dari biaya penyimpanan satu bulan

---

Terjadinya gangguan dan respons awal

• Sekitar 2023-07-02 13:07:58 UTC, server pusat Tarsnap menjadi offline di region Amazon EC2 us-east-1
  • Status EC2 adalah failed system status check
  • Pada mesin virtual, status ini dapat menunjukkan berbagai penyebab seperti pemadaman listrik, kegagalan hardware server fisik, atau gangguan jaringan EC2
  • Pada waktu yang sama tidak terlihat laporan gangguan EC2 yang meluas, sehingga kemungkinan terbesar dianggap sebagai kegagalan hardware yang terisolasi
• Pemantauan mendeteksi gangguan pada 2023-07-02 13:10 UTC
  • Pemantauan dilakukan dengan menulis, membaca, dan menghapus arsip setiap 5 menit dari region EC2 lain
  • Peringatan SMS pukul 13:10 UTC tidak membangunkan, tetapi respons dimulai lewat panggilan telepon pukul 13:15 UTC
  • Karena penyelidikan awal tidak menunjukkan error sementara yang jelas, sistem dianggap mati dan persiapan instance EC2 pengganti pun dimulai

Kebijakan operasional yang menghindari restart otomatis

• Sekitar 2023-07-02 13:52 UTC, Amazon me-restart server yang bermasalah pada instance EC2 baru
  • Ini terjadi sekitar 45 menit setelah awal gangguan
  • Sistem operasi FreeBSD berhasil naik, tetapi kode server Tarsnap tidak dimulai otomatis
• Alasan start otomatis dimatikan adalah agar status dapat diperiksa langsung sebelum menerima trafik setelah reboot tak terduga
  • Dalam kebijakan operasional, “mencegah kehilangan data saat ada sesuatu yang rusak” lebih penting daripada “memaksimalkan ketersediaan layanan”
• Setelah reboot, log server menunjukkan kerusakan filesystem
  • Diperkirakan penyebab gangguan mematikan hardware, atau memutus koneksi antara Elastic Block Store yang berisi filesystem dan server
  • Diputuskan untuk melanjutkan penyiapan server baru alih-alih memulihkan server lama

Struktur log di S3 dan prosedur pemulihan

• Layanan Tarsnap menyimpan data di Amazon S3 sebagai filesystem berstruktur log
  • Setiap objek S3 memiliki header yang memuat metadata semua entri log, dan secara opsional juga berisi data entri log
  • Entri log start write transaction hanya memiliki header yang mengidentifikasi machine dan nonce transaksi, tanpa data log
  • Entri log store data block memiliki header yang mengidentifikasi machine dan nama blok, beserta data blok
• Dalam keadaan normal, metadata entri log di-cache di EC2 dan tidak dibaca ulang dari Amazon S3
  • Pembacaan Amazon S3 hanya terjadi saat membaca data blok untuk merespons permintaan klien tarsnap
• Pemulihan status instance EC2 dibagi menjadi dua tahap
  • Pertama, semua header metadata dibaca dari S3
  • Setelah itu, semua pekerjaan diputar ulang (replay) secara lokal
  • Dalam penyimpanan berstruktur log, entri log ditulis ulang saat data dihapus untuk membebaskan ruang, sehingga dua tahap ini tidak dapat dijalankan bersamaan
  • Entri log memiliki nomor urut sehingga bisa diputar ulang dalam urutan yang benar, tetapi harus diurutkan terlebih dahulu setelah diambil

Cacat dan bottleneck yang terungkap selama pemulihan

• Tahap pertama berjalan tanpa masalah dan selesai pada 2023-07-03 01:49:49 UTC
  • Proses pemulihan dikonfigurasi untuk mengirim 250 permintaan paralel ke Amazon S3
  • Nilai ini disetel agar sesuai dengan tingkat yang dapat ditangani Amazon S3 10 tahun lalu, dan sekarang kemungkinan bisa dinaikkan jauh lebih besar
• Tahap kedua gagal hampir seketika
  • Muncul error bahwa entri log yang diputar ulang mencatat data milik machine yang tidak ada
  • Penyebabnya adalah kode penanganan perpindahan akun machine yang ditulis pada 2014
  • Saat pengguna Tarsnap perlu memindahkan machine antar akun, metode yang digunakan adalah menyimpan entri log machine registration baru dan menghapus entri sebelumnya
  • Ada pengujian, tetapi kasus rekonstruksi status server setelah machine re-owned dalam kondisi data sudah tersimpan tidak tercakup
  • Karena nomor urut entri log registrasi machine yang baru lebih tinggi, dalam proses replay data itu tampak seperti disimpan ke machine yang belum ada
• Setelah penyebab ditemukan, “seatbelt” terkait dinonaktifkan dan rekonstruksi status dilanjutkan
  • Tak lama kemudian muncul error bahwa data tidak dapat ditemukan di Amazon S3
  • Penyebabnya, saat mencoba melanjutkan, tahap unduh data S3 dilewati sehingga nilai maximum log entry sequence number tidak diinisialisasi ulang dan tetap 0
  • Setelah masalah ini diperbaiki, rekonstruksi status kembali berjalan normal
• Rekonstruksi status berjalan lebih lambat daripada yang seharusnya
  • Jika sejak awal diketahui bahwa throughput disk adalah bottleneck, throughput pada volume EBS terkait bisa disetel lebih tinggi
  • Karena kurang tidur, proses tidak dipantau dengan saksama; seandainya dipantau, bottleneck bisa terlihat lewat gstat(8) dan Amazon CloudWatch lalu volume EBS dapat disetel ulang

Layanan kembali berjalan dan pemberian kredit

• Sekitar 2023-07-03 15:10 UTC, proses rekonstruksi status selesai
  • Waktu selesai yang tepat tidak dicatat
  • Server dibiarkan dalam mode read-only dan dilakukan pengujian cepat
  • Dibandingkan dengan status server lama untuk memastikan kecocokan, kecuali beberapa detik terakhir data yang hilang dari filesystem server lama saat gangguan terjadi
• Trafik produksi pertama setelah gangguan terjadi pada 2023-07-03 15:25:58 UTC
  • Ini sekitar 26 jam 16 menit setelah awal gangguan
• Tarsnap tidak memiliki SLA yang tegas, tetapi menerapkan kebijakan pemberian kredit untuk gangguan yang dinilai adil
  • Pada 2023-07-13, semua akun Tarsnap menerima kredit sebesar 50% dari biaya penyimpanan satu bulan
  • Pemrosesan kredit dilakukan setelah penanganan gangguan selesai dan setelah beristirahat

[GN⁺]

Opini Hacker News

• Saya benar-benar tidak menyangka tulisan ini akan naik ke posisi teratas HN. Saya ingin menjawab pertanyaan, tapi sekarang sudah pukul 10 malam, dan anak saya tertidur pukul 5 sore, jadi kalau beruntung saya mungkin bisa tidur sekitar 4 jam sebelum anak saya bangun
  Saya akan mengeceknya lagi pagi hari dan menjawab pertanyaan

  • Saya penasaran apa alasan untuk memakai layanan ini alih-alih restic. Terima kasih kepada Colin, tetapi dari tulisan ini tampaknya penanggung jawab infrastruktur layanan ini pada dasarnya hanya satu orang
    Bagus bahwa mereka menyatakan dengan jelas tidak ada SLA, tetapi rasanya ada risiko besar yang berada di antara saya dan backup saya
  • Jika ke depannya menulis postmortem lagi—tentu saya berharap hampir tidak ada atau tidak ada sama sekali—akan bagus jika bagian pelajaran yang dipetik ditulis dengan jelas, sehingga terlihat poin mana yang tidak akan terulang lagi dan mengapa
  • Ini postmortem yang benar-benar ditulis dengan baik dan penuh pertimbangan, tapi saya berharap tidak melihat tulisan seperti ini lagi :)
  • Sudah waktunya menyerahkan dukungan 24 jam kepada anak Anda ;)
    Saya membaca https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... dan cukup merasakan manfaatnya. Bisa didapat di perpustakaan, alias semacam Blockbuster untuk buku
  • Saya penasaran berapa lama log transaksi disimpan sebelum ditulis ulang
    Dalam beberapa minggu terakhir saya juga mengalami beberapa instance EC2 yang down dengan gejala seperti terlepas dari EBS, dan dalam kasus saya itu terjadi di eu-west

• Bagian yang mengatakan bahwa berdasarkan kebijakan ambigu “Tarsnap tidak punya SLA, tetapi memberikan kredit untuk gangguan jika tampak adil”, pada 2023-07-13 semua akun Tarsnap diberi kredit sebesar 50% biaya penyimpanan satu bulan, benar-benar menunjukkan orang seperti apa Percival itu
  Kredit ini tampaknya cukup murah hati dalam mengompensasi pelanggan secara memadai, dan berbeda dengan penyedia cloud besar, mereka juga tidak membuat setiap pelanggan harus datang sendiri dan memohon. Ditambah lagi ada postmortem yang jelas, teknis, dan terperinci. Menurut saya semua tempat seharusnya melakukan hal seperti ini

  • Ungkapan “terima kasih sudah menjadi mercusuar di tengah kegelapan” benar-benar pas
    Saya cukup senang hidup di dunia tempat Tarsnap ada dan dihargai dalam satuan picodollars

• Jika prosedur pemulihan bencana disiapkan dan diuji dengan benar, downtime seharusnya bisa jauh lebih singkat
  Perlu membuat sistem staging terpisah yang lengkap, memastikan sistem itu bisa dijatuhkan lalu dibangun kembali, secara berkala menguji berbagai mode kegagalan, dan mendokumentasikan semua detail prosedur pemulihan sistem
  Dalam jangka panjang, ada baiknya juga mempertimbangkan apakah pendapatan bisa ditingkatkan agar dapat mempekerjakan tenaga paruh waktu yang akan sangat membantu ketika hal serupa terjadi
  Kami juga penyedia solusi cloud kecil dan berfokus pada ML API, dan dari tahun ke tahun semakin jelas bahwa jika memakai hardware cloud, baik dedicated maupun virtual, kegagalan akan terjadi secara berkala. RAM, HDD, atau komponen hardware lain bisa rusak kapan saja, jadi dalam jangka panjang hal ini harus 100% diperhitungkan saat menjalankan layanan online dengan ketersediaan tinggi

• Saya menghargai postmortem yang jujur dan cara menangani situasi sulit ini dengan baik. Namun soal kurang tidur, jika hanya ada satu orang yang bisa memperbaiki masalah, tidak perlu malu untuk menerima sedikit tambahan waktu gangguan demi mendapatkan pikiran yang jernih
  Pergi tidur sebentar saat alarm berbunyi memang terasa aneh, tetapi kombinasi adrenalin dan kurang tidur sangat mudah membuat masalah menjadi lebih buruk

  • Tidak perlu khawatir, saya sempat tidur siang beberapa kali di tengah-tengah. “Sepertinya ini berjalan baik, tapi masih butuh beberapa jam lagi, jadi saya akan menyetel alarm 2 jam lagi dan tidur sebentar” adalah salah satu alasan saya tidak menyadari bahwa tahap kedua sebenarnya terhambat bottleneck I/O yang tidak perlu

• Dari penjelasannya saja, proses pemulihan ini tampaknya relatif mudah diuji secara berkala, dan sepertinya bisa membantu menangkap bug yang tersisa atau memperkirakan waktu pemulihan
  Seperti yang sering dikatakan, hanya backup yang pernah diuji yang benar-benar merupakan backup

  • Sebagai orang yang baru tahu setelah menguji bahwa proses pemulihan bencana saya tidak berfungsi, saya 100% setuju. Satu-satunya rencana yang mungkin benar-benar berjalan adalah rencana yang dapat diulang dan sudah diuji
  • Benar. Saya sudah berniat melakukannya selama beberapa waktu, tetapi selalu ada hal lain yang prioritasnya lebih tinggi. Saya tidak menyadari bahwa sebelum gangguan ini, proses itu hampir 10 tahun tidak diuji
    Ke depannya saya pasti akan menjadikan latihan tahunan sebagai prioritas tinggi

• Selalu menyenangkan melihat postmortem yang profesional, sopan, dan jujur seperti ini

• Mungkin ini berdasarkan informasi lama tentang perusahaan Tarsnap, tetapi satu-satunya faktor yang membuat saya ragu memakai Tarsnap secara serius adalah gangguan Colin Percival yang tak terduga, alias risiko tokoh kunci
  Saya rasa bukan cuma saya yang berpikir begitu

  • Ini mirip dengan perhitungan mean time between failures. Masalahnya adalah apakah kita percaya pada solusi yang dirancang dengan baik dari perusahaan satu orang yang punya sedikit komponen bergerak dan dirancang dengan baik, atau percaya pada solusi dari perusahaan yang jauh lebih besar tetapi punya jauh lebih banyak komponen bergerak dan mungkin dirancang kurang baik
    Secara pribadi, saya akan memilih solusi yang lebih sederhana. Dari pengalaman saya, untuk mencapai tingkat keandalan yang dimiliki sistem sederhana diperlukan kompleksitas tambahan yang sangat besar, dan sebagian besar kompleksitas justru memperburuk keadaan
    Hal ini jelas terlihat pada clustering server. Satu server tunggal dengan listrik dan jaringan yang stabil lebih dapat diandalkan daripada upaya apa pun untuk menggandakan layanan itu, sampai biaya dan kompleksitasnya meningkat kira-kira 5 kali lipat. Baru pada titik itu mean time between failures-nya mendekati server tunggal, dan setelah itu barulah perbaikan nyata mungkin terjadi
    Saya sangat percaya bahwa jalan terbaik menuju keandalan sejati adalah sesederhana mungkin dan backup yang baik. Jika membutuhkan ketersediaan 24/7 sepanjang tahun, pilihan teknologinya menjadi cukup terbatas
  • Saya paham ini adalah risiko, tetapi saya tidak yakin itu pasti lebih berisiko daripada perusahaan yang lebih besar
    Ini adalah pekerjaan Colin, nama Colin yang dipertaruhkan, dan ini sangat penting bagi Colin
    Di BigBackupCorp, sulit mendapatkan jenis layanan yang sama. Karyawan bisa diganti, manajemen bisa diganti, dan sejujurnya saya sebagai pelanggan pun bisa diganti kalau perusahaan mengubah arah dan memutuskan menjadi BigFlowerArrangementShippingCorp
    Hal baik dari bisnis kecil adalah ia sepenuhnya berjalan demi kepentingannya sendiri. Tidak ada permainan harga saham atau trik ala VC. Jika bisnis itu menguntungkan, seseorang bisa datang dan mengambil alih, memasang namanya sendiri, dan menjadikannya pekerjaannya sendiri. Menurut saya internet terbuka mendapat manfaat besar dari hal-hal seperti ini
  • Jika membuat daftar pesaing yang lenyap lebih dulu daripada Tarsnap, perhitungannya bisa sedikit berubah. Risiko yang harus dinilai bukan “bagaimana kalau sesuatu terjadi pada operatornya?”, melainkan “bagaimana kalau sesuatu terjadi padanya, layanannya juga turun, dan saya juga tidak punya backup dari backup?”
    Risiko ini bisa dibuat sekecil yang diinginkan dengan perencanaan yang cermat
  • Jika memantau HN, Anda mungkin akan tahu dalam 24 jam jika ada masalah dengan Colin. Secara realistis, masalah nyata baru terjadi jika penyimpanan utama, Tarsnap, dan Colin semuanya gagal secara bersamaan dalam jendela sekitar 24 jam sebelum Anda pindah ke penyedia backup baru
  • Saya tidak berniat mempercayai penyedia backup lebih dari itu. Karena begitu Anda bergantung padanya, ia akan gagal pada saat paling sulit
    Layanan seperti Tarsnap sebaiknya dijadikan salah satu dari beberapa lapisan, membangun backup berlapis, dan memverifikasinya secara berkala

• Kesalahan seperti entri log yang diputar ulang mencatat data dari mesin yang tidak ada sepertinya bisa ditangkap dengan menulis model TLA+

• Dengan kombinasi seperti restic+backblaze, biayanya bisa turun beberapa orde magnitudo, jadi saya penasaran apa keuntungan memakai Tarsnap. Saya tidak tahu kebutuhan konkret seperti apa yang bisa memotivasi orang membayar 3000 dolar per TB-tahun

  • Sebagian dari kami punya cukup banyak uang lebih, dan senang punya alasan untuk memberi uang kepada cperciva agar ia tidak bekerja di pekerjaan yang buruk dan bisa memakai keterampilan serta bakatnya untuk hal-hal yang lebih besar dan lebih baik
    Untuk orang yang bertanya soal bus factor yang rendah: Anda tentu tidak menaruh backup hanya di satu layanan atau satu lokasi, kan? Anda tentu memakai Tarsnap bersama Restic+Backblaze, Rsync.net, S3, dan sebagainya, kan? “Backup adalah pajak yang dibayar demi kemewahan bernama pemulihan”
  • Deduplication-nya bekerja sangat baik, sehingga biaya untuk kumpulan data inti yang sangat penting yang saya backup ke Tarsnap bisa diabaikan. Jika datanya lebih sering berubah, perhitungannya mungkin berbeda
    Misalnya, untuk pustaka video dan foto saya memakai layanan lain, tetapi database akuntansi dan dokumen penting saya backup ke Tarsnap
    Saya sudah memakai Tarsnap selama 10 tahun, dan hampir tidak pernah ada masalah ketersediaan, juga hampir tidak ada masalah jenis apa pun sejauh yang saya ingat

• Sebagian besar downtime 26 jam terdengar seperti dihabiskan untuk memulihkan backup. Kebetulan, ini persis alasan saya tidak bisa memakai Tarsnap di lingkungan produksi
  Dari sisi pengguna, pemulihan backup terasa sangat lambat sampai menyakitkan. Saat sistem saya offline, saya tidak punya kesabaran menunggu berjam-jam karena layanan backup. Mungkin sekarang sudah lebih baik, tetapi terakhir kali saya memakainya beberapa tahun lalu, memulihkan backup beberapa GB memakan waktu kira-kira dalam hitungan jam