Ketika Dua Orang Mengubah State Infrastruktur yang Sama di Waktu yang Bersamaan

Bayangkan ini: Developer A dan Developer B sama-sama perlu memperbarui infrastruktur. Mereka mengambil state terkini dari bucket S3 yang sama, masing-masing membuat perubahan, lalu mengunggah state baru mereka kembali ke S3. Hasilnya? Perubahan salah satu orang menimpa perubahan yang lain secara diam-diam. Infrastruktur yang berjalan di cloud tidak lagi sesuai dengan apa yang tercatat di file state. Tidak ada yang tahu sumber daya mana yang benar-benar dikelola, dan tim mulai kehilangan kendali.

Ini bukan tentang dua orang mengedit sumber daya yang sama secara langsung. Ini tentang dua orang mengedit catatan dari sumber daya tersebut. Dan solusinya adalah mekanisme yang disebut state locking.

Apa yang Sebenarnya Dilakukan State Locking

State locking sederhana dalam konsepnya. Sebelum seseorang mulai memodifikasi state, sistem mencoba menguncinya. Jika penguncian berhasil, orang tersebut dapat membaca state, membuat perubahan, dan menyimpan versi baru. Selama itu terjadi, siapa pun yang mencoba mengakses state yang sama akan diblokir. Mereka menunggu hingga kunci dilepaskan. Setelah perubahan disimpan, kunci akan lepas secara otomatis.

Diagram urutan berikut mengilustrasikan bagaimana dua developer berinteraksi dengan state dan backend kunci:

sequenceDiagram participant A as Developer A participant B as Developer B participant S3 as State Backend (S3) participant DB as Lock Backend (DynamoDB) A->>DB: Ambil kunci DB-->>A: Kunci didapatkan A->>S3: Baca state saat ini S3-->>A: Data state B->>DB: Ambil kunci DB-->>B: Kunci ditolak (tunggu) A->>S3: Tulis state baru S3-->>A: OK A->>DB: Lepaskan kunci DB-->>A: Kunci dilepas B->>DB: Ambil kunci DB-->>B: Kunci didapatkan B->>S3: Baca state saat ini S3-->>B: Data state

Tanpa mekanisme ini, perubahan bersamaan akan merusak state Anda. Dan state yang rusak berarti Anda tidak lagi memiliki sumber kebenaran yang dapat diandalkan untuk infrastruktur Anda.

Bagaimana Backend yang Berbeda Menangani Kunci

Tidak semua backend state menangani penguncian dengan cara yang sama. Jika Anda menyimpan state di S3, Anda memerlukan backend tambahan seperti DynamoDB untuk mengelola kunci. DynamoDB mencatat siapa yang memegang kunci, kapan dimulai, dan state mana yang dikunci. Setiap kali seseorang mencoba memodifikasi state, sistem akan memeriksa DynamoDB terlebih dahulu. Jika kunci aktif, operasi akan berhenti dan mengembalikan error.

Berikut adalah konfigurasi backend Terraform minimal yang mengaktifkan state locking dengan S3 dan DynamoDB:

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Atribut dynamodb_table memberi tahu Terraform untuk menggunakan tabel DynamoDB bernama terraform-locks untuk penguncian. Tabel ini harus ada sebelum menjalankan terraform init. Tabel tersebut membutuhkan primary key bernama LockID (tipe String). Terraform akan secara otomatis membuat dan melepaskan entri kunci di tabel ini selama operasi state.

Beberapa backend memiliki penguncian bawaan. Consul dan etcd, misalnya, dirancang untuk sistem terdistribusi, sehingga penguncian adalah bagian dari operasi normal mereka. Anda tidak perlu menyiapkan komponen tambahan seperti DynamoDB. Namun, kemudahan itu datang dengan konsekuensi: Anda sekarang harus menjalankan dan memelihara Consul atau etcd sendiri.

Ketika Kunci Gagal

Kunci bisa gagal dengan cara yang membuat state Anda macet. Berikut adalah skenario umum: seseorang memulai perubahan, lalu koneksi internet mereka terputus di tengah operasi. Kunci telah diambil tetapi tidak pernah dilepaskan karena prosesnya mati. Sekarang state terkunci dan tidak ada yang bisa memodifikasinya.

Dalam situasi ini, Anda perlu melakukan force unlock. Ini bukan sesuatu yang dilakukan sembarangan. Jika Anda memaksa melepas kunci sementara proses asli masih berjalan di suatu tempat, Anda berisiko merusak state. Tim perlu memverifikasi bahwa proses yang menggantung benar-benar mati sebelum melakukan force unlock.

Alat seperti Terraform menyediakan perintah untuk unlock manual. Namun, force unlock seharusnya tidak pernah menjadi operasi rutin. Jika tim Anda sering menghadapi kunci yang macet, lihat akar penyebabnya: stabilitas jaringan, konfigurasi timeout, atau bagaimana pipeline dijalankan.

Mengapa Ini Penting Lebih dari Sekadar Penguncian

State locking adalah jembatan menuju manajemen lingkungan yang lebih terstruktur. Setelah state Anda aman dari perubahan bersamaan, Anda dapat memikirkan cara menggunakan satu konfigurasi di beberapa lingkungan tanpa menduplikasi kode. Di sinilah workspace berperan.

Namun, sebelum beralih ke workspace, pastikan penguncian sudah benar. Tim yang mengabaikan state locking pada akhirnya akan menghadapi situasi di mana perubahan infrastruktur menghilang secara diam-diam, sumber daya menjadi yatim piatu, dan tidak ada yang mempercayai file state lagi.

Daftar Periksa Praktis untuk State Locking

  • Pilih backend dengan dukungan penguncian. S3 membutuhkan DynamoDB. Consul dan etcd memilikinya secara bawaan. Ketahui apa yang diperlukan backend Anda.
  • Uji skenario kegagalan kunci. Simulasikan putusnya jaringan selama perubahan state. Apakah kunci macet? Bisakah tim Anda pulih tanpa panik?
  • Dokumentasikan prosedur force unlock. Tulis dengan tepat cara memverifikasi bahwa proses yang menggantung sudah mati dan cara melepaskan kunci. Jangan biarkan ini hanya menjadi pengetahuan lisan.
  • Pantau kontensi kunci. Jika banyak orang sering mengalami state terkunci, tim Anda mungkin perlu koordinasi yang lebih baik atau perubahan yang lebih kecil dan lebih sering.
  • Atur timeout yang sesuai. Operasi yang berjalan lama harus memiliki timeout yang melepaskan kunci secara otomatis jika proses menggantung.

Intisari Konkret

State locking bukanlah opsional. Tanpanya, perubahan bersamaan akan secara diam-diam merusak state infrastruktur Anda, dan Anda tidak akan tahu sampai sesuatu rusak di produksi. Siapkan penguncian sebelum tim Anda tumbuh lebih dari satu orang, dan perlakukan force unlock seperti alat pemadam kebakaran: tahu di mana letaknya, tahu cara menggunakannya, tetapi jangan berencana menggunakannya setiap hari.