Mengapa Rollback Infrastruktur Tidak Sama dengan Rollback Aplikasi

Anda melakukan deploy pembaruan aplikasi yang bermasalah. Pengguna mulai melihat error. Tim Anda mengalihkan load balancer kembali ke versi sebelumnya, atau pipeline melakukan redeploy artefak lama. Dalam hitungan menit, aplikasi sudah berjalan dengan kode lama. Data tetap utuh. Database tidak berubah. Server masih mesin yang sama seperti sebelumnya. Masalah selesai.

Itulah rollback aplikasi. Ini berhasil karena aplikasi sebagian besar bersifat stateless. Anda mengganti kode, dan perilaku lama kembali. Tidak ada efek samping yang bertahan.

Sekarang bayangkan Anda mengubah aturan firewall, mengubah ukuran disk database, atau memperbarui konfigurasi subnet. Sesuatu menjadi rusak. Anda ingin kembali. Bisakah Anda cukup menerapkan ulang konfigurasi lama dan berharap semuanya berfungsi?

Kemungkinan besar tidak.

Rollback infrastruktur adalah kategori masalah yang berbeda. Sumber daya yang terlibat menyimpan data, mengelola jalur jaringan, dan menyediakan layanan fundamental yang bergantung pada sistem lain. Saat Anda mengubah infrastruktur, Anda tidak hanya mengganti kode. Anda mengubah status dari sesuatu yang mungkin memiliki data bertahun-tahun, koneksi ke puluhan layanan, atau peran sebagai fondasi untuk segala sesuatu di atasnya.

State Adalah Masalah Pertama

Aplikasi dirancang untuk dapat dibuang. Anda bisa mematikan container, membuat yang baru dengan kode lama, dan aplikasi mulai dari awal. Tidak ada memori versi sebelumnya. Tidak ada data sisa dari deployment yang gagal.

Infrastruktur adalah kebalikannya. Database tetap menyimpan datanya meskipun Anda mengubah konfigurasinya. Volume disk tetap menyimpan filenya meskipun Anda mengubah ukurannya. Sumber daya ini bersifat stateful. Mereka menyimpan state yang bertahan melampaui siklus hidup perubahan konfigurasi apa pun.

Saat Anda melakukan rollback aplikasi, Anda hanya memulihkan kode. Saat Anda melakukan rollback infrastruktur, Anda harus memulihkan konfigurasi tanpa menghancurkan data yang telah terakumulasi di dalam sumber daya tersebut. Itu tidak selalu memungkinkan.

Berikut adalah contoh konkret. Anda meningkatkan tipe instance database dari kecil ke besar karena lalu lintas meningkat. Tipe instance baru memiliki masalah. Anda ingin kembali ke instance kecil. Namun selama instance besar berjalan, lebih banyak data ditulis ke database. Instance kecil yang lama tidak dapat lagi menampung data tersebut. Rollback tidak aman. Anda tidak bisa mengecilkan instance tanpa kehilangan data, dan Anda tidak bisa menyimpan data jika Anda beralih kembali.

Perbedaannya menjadi jelas ketika Anda membandingkan kedua jalur secara berdampingan.

flowchart TD A[Perubahan buruk di-deploy] --> B{Apakah ini aplikasi?} B -->|Ya| C[Tukar kode via LB atau pipeline] C --> D[Kode lama berjalan, tanpa efek samping] D --> E[Rollback berhasil] B -->|Tidak, ini infrastruktur| F[Identifikasi sumber daya stateful] F --> G{Bisakah state dipertahankan?} G -->|Tidak| H[Rollback dapat menghancurkan data] G -->|Ya| I[Periksa dependensi] I --> J[Urutan rollback yang teratur] J --> K[State parsial atau rusak] K --> L[Pemulihan diperlukan, bukan sekadar rollback]

Ini bukan masalah alat. Ini adalah batasan fundamental dari sumber daya stateful. Tindakan menjalankan konfigurasi baru mengubah sumber daya dengan cara yang tidak dapat diakomodasi oleh konfigurasi lama.

Dependensi Melipatgandakan Risiko

Sumber daya infrastruktur jarang berdiri sendiri. Satu perubahan dapat menyentuh sepuluh sumber daya yang saling terhubung: VPC, subnet, security group, load balancer, beberapa instance, dan database. Setiap sumber daya bergantung satu sama lain dengan cara tertentu.

Saat Anda melakukan rollback satu sumber daya, sumber daya yang bergantung padanya akan terpengaruh. Memulihkan security group lama dapat memutus komunikasi antara load balancer dan instance. Memulihkan subnet dapat memutus koneksi database. Rollback bukanlah operasi tunggal. Ini adalah urutan yang harus diatur dengan hati-hati, dan urutannya tergantung pada bagaimana sumber daya awalnya dibuat dan bagaimana mereka berubah sejak saat itu.

Dalam praktiknya, ini berarti Anda tidak bisa begitu saja menjalankan terraform apply pada file state lama dan pergi. State lama mungkin bertentangan dengan state saat ini dari sumber daya lain yang tidak di-rollback. Hasilnya sering kali berupa pemulihan parsial yang membuat infrastruktur Anda dalam keadaan rusak.

Idempotent Apply Tidak Berarti Safe Rollback

Pipeline infrastruktur dirancang untuk menjadi idempoten. Anda dapat menjalankan konfigurasi yang sama beberapa kali dan mendapatkan hasil yang sama. Itu berfungsi dengan baik untuk menerapkan perubahan. Tetapi idempotent apply tidak berarti safe rollback.

Pertimbangkan ukuran disk. Anda mendeklarasikan disk sebesar 100 GB, menerapkannya, dan disk tersebut dibuat. Anda menjalankan konfigurasi yang sama lagi, dan tidak ada yang berubah. Itu idempoten. Sekarang Anda mengubah konfigurasi menjadi 200 GB dan menerapkannya. Disk membesar. Kemudian Anda mengubah konfigurasi kembali ke 100 GB dan menerapkannya lagi. Apa yang terjadi?

Sebagian besar alat infrastruktur akan menolak operasi tersebut atau menghancurkan disk dan membuat yang baru. Mereka tidak bisa mengecilkan disk tanpa risiko kehilangan data. Konfigurasi secara teori idempoten, tetapi sumber daya aktual telah berubah dengan cara yang tidak dapat dibalikkan.

Ini disebut state drift. Konfigurasi dalam kode Anda mengatakan satu hal, tetapi sumber daya aktual di cloud atau di server berbeda. Saat Anda mencoba rollback, Anda tidak hanya mengembalikan kode. Anda mencoba merekonsiliasi konfigurasi yang tidak lagi sesuai dengan kenyataan. Dan kenyataan sering kali menang.

Artinya bagi Tim Anda

Rollback infrastruktur memerlukan jenis persiapan yang berbeda dari rollback aplikasi. Anda tidak dapat mengandalkan pipeline yang sama atau model mental yang sama. Anda perlu tahu sumber daya mana yang aman untuk di-rollback, mana yang tidak, dan urutan apa yang harus diikuti.

Beberapa perubahan bersifat reversibel. Mengubah konfigurasi health check load balancer biasanya aman untuk di-rollback. Mengubah grup parameter database mungkin aman jika parameter baru tidak mengubah data yang tersimpan. Tetapi mengubah ukuran instance, ukuran disk, topologi jaringan, atau mesin penyimpanan seringkali tidak dapat diubah tanpa kehilangan data atau downtime.

Pendekatan teraman adalah merencanakan pemulihan, bukan sekadar rollback. Pemulihan berarti menerima bahwa konfigurasi lama mungkin tidak lagi valid dan membangun jalur ke depan, bukan ke belakang. Itu mungkin melibatkan pembuatan sumber daya baru dengan konfigurasi lama dan memigrasikan data, atau menerima keadaan yang terdegradasi sementara perbaikan dikembangkan.

Daftar Periksa Praktis untuk Perubahan Infrastruktur

Sebelum Anda menerapkan perubahan infrastruktur apa pun, ajukan pertanyaan-pertanyaan ini:

  • Apakah sumber daya ini menyimpan state? Jika ya, dapatkah state dipertahankan jika kami mengembalikan konfigurasi?
  • Sumber daya lain apa yang bergantung pada sumber daya ini? Apakah rollback akan memutus konektivitas mereka?
  • Apakah perubahan tersebut reversibel? Dapatkah alat mengecilkan disk, menurunkan versi instance, atau memulihkan jalur jaringan tanpa menghancurkan data?
  • Apa rencana pemulihan yang sebenarnya jika perubahan gagal? Apakah itu rollback, migrasi, atau rebuild?
  • Sudahkah kami menguji jalur pemulihan di lingkungan non-produksi?

Kesimpulan

Rollback aplikasi adalah pertukaran kode. Rollback infrastruktur adalah masalah rekonsiliasi state. Memperlakukan keduanya dengan cara yang sama akan menyebabkan sistem rusak, data hilang, dan waktu pemulihan yang lama. Rencanakan pemulihan, bukan sekadar rollback. Ketahui perubahan mana yang reversibel, dan uji jalur pemulihan Anda sebelum Anda membutuhkannya.