Dari kesalahan 13% pada Black Friday hingga nol downtime: Kami menghemat 60% biaya server dengan menggunakan pendekatan deployment berbasis kontainer.

Tahun lalu, saat Black Friday, interface pemrosesan alamat kami benar-benar mengalami masalah serius—13% dari permintaan mengalami kesalahan (error code 429), dan tim layanan menerima lebih dari 300 keluhan dari para pedagang. Tiga server backend harus bekerja non-stop selama 24 jam untuk mengatasi puncak beban tersebut. Saat itu, layanan kami masih dijalankan pada dua server cloud dengan konfigurasi tetap, dan proses penyesuaian kapasitas (scaling) dilakukan secara manual. Baru setelah instance baru diaktifkan, puncak beban lalu lintas telah berlalu.

Pertama-tama, mari kita jelaskan apa itu kontainerisasi deployment (containerized deployment).

Singkatnya, intinya adalah mengemas semua kode Anda, pustaka yang dibutuhkan, dan berkas konfigurasi menjadi sebuah “kotak” yang terstandarisasi dengan ukuran antara beberapa MB hingga beberapa ratus MB. Dengan cara ini, lingkungan eksekusi akan 100% seragam, tidak peduli di server mana program tersebut dijalankan. Ukuran awal dari image layanan pemrosesan alamat yang kami kemas adalah…187MBProses pengambilan (pulling) dan memulai seluruh proses tidak memakan waktu lebih dari 10 detik.

Tiga manfaat utama yang benar-benar kita dapatkan

• Auto-scaling really saved the day: This year, during the Black Friday shopping season, traffic increased by three times. The system automatically launched 27 container instances, and after the peak, it reduced them back to 3. The whole process was done without any human intervention, and the error rate dropped directly to less than 0.1%.
• Bug akibat ketidakkonsistenan lingkungan telah sepenuhnya hilang: Masalah-masalah misterius yang sebelumnya tidak terjadi saat dijalankan secara lokal, tetapi langsung menyebabkan kegagalan saat dijalankan di lingkungan produksi, menyumbang 40% dari total bug yang kami temukan, tidak pernah muncul lagi setelah kami beralih ke lingkungan kontainer.
• Biaya server dikurangi hingga setengahnya: Sebelumnya, untuk menanggung beban puncak, kami menyewa 8 server berkinerja tinggi sepanjang tahun, namun tingkat penggunaannya hanya sekitar 15%. Sekarang, kami membayar berdasarkan penggunaan yang sebenarnya, dan secara tahunan kami menghemat 60% dari biaya server.

Jangan hanya melihat keuntungannya saja, kami sudah beberapa kali terjebak dalam kesalahan-kesalahan ini.

Ketika pertama kali menggunakan kontainer, untuk memudahkan proses, kami menyimpan semua log dan file sementara di dalam kontainer. Akibatnya, ketika sebuah instance dihentikan secara otomatis, log permintaan selama 3 hari hilang, dan membutuhkan waktu dua hari penuh untuk menggantinya. Ada juga kasus di mana terlalu banyak dependensi yang tidak berguna dimasukkan ke dalam image, sehingga waktu startup meningkat dari 10 detik menjadi 2 menit. Ketika terjadi lonjakan lalu lintas tiba-tiba, kami tidak sempat memperluas kapasitas, dan hampir saja terjadi masalah lagi.

Yang paling mudah diabaikan adalah masalah hak akses (permission): awalnya kami memberikan hak akses root kepada kontainer tersebut, dan kemudian program penambangan (mining program) memanfaatkan celah tersebut untuk mengambil 30% dari sumber daya CPU. Baru setelah seminggu kami menyadari hal tersebut melalui sistem pemantauan.

Pikirkan dulu dengan matang apakah kamu benar-benar harus menggunakannya atau tidak.

Jika Anda hanya berada dalam sebuah tim kecil yang terdiri dari beberapa orang dan mengembangkan alat internal dengan fluktuasi lalu lintas yang sangat kecil, hanya terdiri dari 1-2 layanan saja, maka sebenarnya tidak perlu repot-repot. Lebih mudah jika Anda langsung menyewa sebuah server untuk menjalankannya.

Namun, jika lalu lintas layanan Anda sangat fluktuatif, Anda perlu sering melakukan pembaruan secara online, lingkungan pengembangan yang dibuat oleh berbagai orang dalam tim sering kali bertentangan, atau Anda sudah merasa kesal karena penggunaan sumber daya server yang tidak efisien, maka penggunaan teknik deploymen berbasis kontainer (containerization) sangat layak untuk Anda coba, meskipun Anda mungkin perlu menghabiskan waktu sekitar seminggu untuk mempelajarinya.

3 saran spesifik untuk orang yang pertama kali mencobanya

• Jangan langsung mulai dengan mengelola kluster K8S; gunakan Docker Compose untuk melakukan penyebaran (deployment) secara mandiri (standalone) terlebih dahulu. Pelajari dengan baik logika pengemasan (packaging), proses eksekusi (running), dan penanganan log (logging). Itulah yang kami lakukan selama 3 bulan terakhir, dan itu sudah cukup untuk memulai.
• Pada pengemasan image pertama, kita mengikuti “prinsip minimalisme”, hanya memasukkan dependensi yang diperlukan untuk menjalankan aplikasi. Dengan menggunakan image dasar Alpine, ukuran image dapat dikurangi lebih dari setengahnya.
• Semua data dan log yang dihasilkan harus dimuat ke dalam volume penyimpanan di luar kontainer, dan tidak boleh disimpan di dalam kontainer itu sendiri. Poin ini harus dituliskan di bagian awal pedoman operasional tim Anda.

Pertanyaan Umum dan Jawabannya

Pertanyaan: Tidak ada anggota tim kami yang memahami konsep kontainer, apakah biaya belajar akan sangat tinggi?
Jawaban: Untuk penggunaan dasar, Anda hanya perlu menghabiskan waktu 2 hari membaca dokumen panduan resmi untuk bisa menjalankan layanan pertama. Konfigurasi kluster yang lebih kompleks bisa Anda pelajari nanti, saat Anda benar-benar membutuhkannya.

Pertanyaan: Apakah akan merepotkan jika layanan yang ada sekarang dipindahkan ke kontainer?
Jawaban: Ketiga layanan backend kami berhasil dipindahkan sepenuhnya dalam waktu seminggu, dan sebagian besar waktu dihabiskan untuk menyelesaikan masalah terkait ketergantungan (dependencies). Waktu yang sebenarnya digunakan untuk menulis Dockerfile kurang dari satu hari.