Wawancara Setelah kehancuran pusat data Google dan Oracle di Inggris awal pekan ini, banyak pengguna yang tidak diragukan lagi menemukan bahwa menerapkan aplikasi mereka di cloud tidak secara otomatis membuat mereka kebal terhadap kegagalan.
Namun menurut laporan yang akan datang dari Uptime Institute, membangun aplikasi yang dapat bertahan dari pemadaman awan semacam ini – yang disebabkan oleh panas atau lainnya – tidak harus sulit atau bahkan semahal itu.
Apakah suatu aplikasi tetap beroperasi atau tidak jika terjadi pemadaman cloud sepenuhnya bergantung pada bagaimana aplikasi itu diterapkan, kata analis Uptime Institute Owen Rogers kepada Pendaftaran dalam sebuah wawancara eksklusif.
Ini seharusnya tidak mengejutkan banyak orang, namun Rogers mengatakan setengah dari perusahaan yang disurvei berada di bawah kesan ketahanan aplikasi adalah tanggung jawab penyedia cloud.
“Masih ada ketidakjelasan tentang siapa yang bertanggung jawab atas masalah ketahanan terkait cloud,” jelasnya, seraya menambahkan bahwa meskipun penyedia cloud publik menawarkan banyak alat untuk membangun aplikasi yang tangguh, tanggung jawab ada pada pengguna untuk mengimplementasikannya.
Analisis alat-alat ini menunjukkan bahwa mencapai tingkat ketahanan yang tinggi adalah prospek yang relatif mudah – terutama ketika biaya bisnis yang hilang dan SLA cloud dipertimbangkan.
Untuk laporan tersebut, Rogers menyelidiki tujuh skenario untuk menerapkan aplikasi stateless di mesin virtual di cloud, masing-masing dengan berbagai tingkat toleransi kesalahan.
Ketahanan tingkat zona
Dengan sendirinya, VM yang berjalan di cloud memberikan perlindungan nol jika terjadi gangguan layanan, zona, atau regional.
Bagi mereka yang tidak terbiasa, wilayah cloud menyediakan layanan ke wilayah geografis yang luas dan biasanya terdiri dari dua atau lebih pusat data independen, yang disebut sebagai zona ketersediaan.
Dengan menerapkan load-balancer dan VM kedua dalam konfigurasi aktif-aktif, di mana lalu lintas dialihkan ke setiap instans, Rogers mengklaim pelanggan dapat memperoleh perlindungan dasar terhadap kesalahan aplikasi dengan biaya hanya 43 persen lebih tinggi daripada VM tunggal.
Dan bagi mereka yang dapat mentolerir downtime 15 menit, pendekatan failover aktif – di mana VM kedua diputar setelah kegagalan yang pertama – biayanya hanya 14 persen lebih mahal daripada baseline.
Namun, pendekatan ini hanya memberikan perlindungan jika terjadi kesalahan aplikasi, dan tidak akan bermanfaat bagi pengguna jika seluruh zona mengalami pemadaman.
Kabar baiknya, menurut Rogers, tidak ada biaya lagi untuk menerapkan salah satu pendekatan di beberapa zona ketersediaan dalam wilayah cloud, tetapi menawarkan ketahanan yang jauh lebih baik – sekitar 99,99 persen.
“Penyedia cloud telah membuatnya sangat mudah untuk dibangun di seluruh zona ketersediaan,” katanya. “Kamu hampir harus menemukan alasan untuk tidak menggunakan zona ketersediaan mengingat mereka sangat mudah dikonfigurasi, dan memberikan tingkat ketahanan yang baik.”
Dalam gaya penerapan ini, aplikasi akan bertahan dari kegagalan regional total. Mengatasi kejadian langka itu sedikit lebih rumit, Rogers menjelaskan.
Penerapan multi-region
Pertama, lalu lintas antar wilayah cloud sering dikenai biaya masuk dan keluar. Selain itu, load balancer saja tidak cukup untuk merutekan lalu lintas, dan layanan luar – dalam kasus pengujian Uptime, server DNS – diperlukan.
“Load balancer dapat dengan mudah mendistribusikan lalu lintas antara dua mesin virtual aktif di wilayah yang sama,” jelas Rogers. “Bila Kamu ingin menyeimbangkannya di berbagai wilayah, saat itulah Kamu harus menggunakan server DNS.”
Investigasi mengeksplorasi beberapa aplikasi untuk penyebaran multi-region. Yang pertama melibatkan pencerminan penyebaran aktif-aktif berbasis zona di beberapa wilayah menggunakan DNS untuk mendistribusikan lalu lintas di antara keduanya. Pendekatan tersebut menawarkan ketahanan terbesar – enam sembilan ketersediaan – tetapi melakukannya dengan biaya tertinggi: kira-kira 111 persen lebih besar daripada VM mandiri.
Rogers juga melihat apa yang disebutnya pendekatan “siaga hangat”, yang menggunakan konfigurasi aktif-aktif berbasis zona di wilayah utama dan VM mandiri di wilayah failover. Penerapan tersebut menawarkan ketersediaan dan ketahanan yang serupa dengan penerapan regional yang dicerminkan, dengan biaya 81 persen lebih tinggi dari baseline.
Terakhir, bagi mereka yang ingin melakukan lindung nilai terhadap kegagalan regional, tetapi bersedia menghadapi waktu henti, pendekatan kegagalan aktif regional dapat digunakan. Dalam skenario ini, jika region utama gagal, server DNS akan mengalihkan lalu lintas ke region failover dan memicu VM cadangan untuk berputar. Penyebaran juga merupakan pendekatan multi-wilayah paling murah yang dieksplorasi dalam laporan.
Namun, laporan tersebut memperingatkan bahwa jika aplikasi berada di bawah tekanan pada saat pemadaman, satu VM di wilayah failover mungkin tidak cukup untuk menangani lalu lintas.
“Load balancer selalu memberikan tingkat ketahanan sehari-hari, tetapi tingkat ketahanan DNS jauh lebih bersifat darurat,” kata Rogers.
Karena itu, dia berpendapat ketahanan multi-zona kemungkinan merupakan titik manis bagi sebagian besar pengguna, sementara pendekatan multi-wilayah harus dipertimbangkan dengan hati-hati untuk menentukan apakah manfaatnya lebih besar daripada kerumitan yang ditambahkan.
SLA bukanlah polis asuransi
Yang tidak boleh dilakukan oleh pelanggan adalah mengharapkan SLA menggantikan waktu henti akibat kurangnya ketahanan aplikasi.
“Kompensasi yang Kamu dapatkan belum tentu sebanding dengan jumlah yang Kamu keluarkan,” jelas Rogers. “Kamu jelas berasumsi bahwa semakin banyak yang Kamu belanjakan di cloud, semakin besar kompensasi Kamu jika terjadi kesalahan – tetapi tidak selalu demikian.”
Layanan cloud yang berbeda memiliki SLA yang berbeda, katanya, menambahkan bahwa pelanggan mungkin terkejut saat mengetahui bahwa jika terjadi kegagalan, mereka hanya diberi kompensasi untuk layanan yang benar-benar rusak, bukan aplikasi secara keseluruhan.
“Kompensasi SLA buruk dan sangat tidak mungkin untuk menutupi dampak bisnis akibat downtime,” tulis Rogers dalam laporan tersebut. “Ketika terjadi kegagalan, pengguna bertanggung jawab untuk mengukur downtime dan meminta kompensasi – itu tidak diberikan secara otomatis.”
Itu tidak berarti SLA sama sekali tidak berharga. Tetapi pelanggan harus menganggapnya sebagai insentif bagi penyedia cloud untuk mempertahankan layanan yang andal, bukan sebagai polis asuransi.
Ini hampir seperti mereka (SLA) digunakan sebagai mekanisme untuk menghukum penyedia cloud daripada mengembalikan uang Kamu atas kerusakan tersebut.
Lebih banyak yang harus dilakukan
Analisis Rogers tentang ketahanan cloud masih jauh dari selesai. Laporan ini adalah yang pertama dari rangkaian yang bertujuan untuk mengatasi tantangan yang terkait dengan beban kerja cloud yang sangat tersedia dari berbagai sudut.
“Kami masih belum menyentuh permukaan tentang bagaimana semua layanan cloud lainnya ini benar-benar akan memiliki tingkat ketahanan yang andal dan terjamin,” katanya.
Misalnya, beban kerja dalam laporan ini tidak memiliki status – artinya data tidak perlu disinkronkan antara zona atau wilayah, yang akan mengubah struktur harga setelah biaya masuk dan keluar diperhitungkan.
“Jika ada transfer data dari satu wilayah ke wilayah lain – misalnya, karena basis data sedang direplikasi ke wilayah lain – itu dapat menimbulkan implikasi biaya yang sangat besar,” jelas Rogers.
Namun, terkait dengan VM, dia berkata, “setelah Kamu melakukan yang minimal, biaya tambahan untuk menambah ketahanan cukup kecil.” ®