Cara memastikan ketersediaan layanan web di cloud jika terjadi kegagalan pusat data

Artikel ini menjelaskan opsi untuk memastikan ketersediaan layanan web yang digunakan di cloud jika terjadi kegagalan fungsi di pusat data. Solusi yang diusulkan didasarkan pada kompromi yang terdiri dari duplikasi parsial : sistem cadangan digunakan di pusat data lain, yang dapat beroperasi dalam mode fungsionalitas terbatas ketika pusat data utama tidak tersedia. Skema ini terutama ditujukan untuk aplikasi kegagalan jangka pendek, tetapi juga menyediakan kemampuan untuk dengan cepat mengubah sistem cadangan menjadi sistem utama jika terjadi masalah skala besar.

Deskripsi masalah

Tahun lalu, kami tersentuh oleh insiden di pusat data penyedia cloud terkenal - salah satu layanan kami tidak tersedia bagi pengguna selama setengah jam. Kemudian kami melihat dengan mata kepala sendiri bahwa jika ada masalah di pusat data cloud, praktis tidak ada tuas untuk memulihkan kesehatan aplikasi, dan tidak ada yang tersisa bagi tim yang bertanggung jawab atas aplikasi tersebut kecuali memasang dan menunggu. Pengalaman ini membuat kami serius berpikir tentang menggunakan cloud untuk produk kami.

Apa yang sebenarnya terjadi hari itu tidak pernah diketahui. Kita terbiasa memandang awan sebagai pos terdepan yang tidak bisa dihancurkan, tetapi tidak demikian halnya. Yang benar adalah bahwa tidak ada jaminan seratus persen ketersediaan layanan di cloud, seperti di tempat lain mana pun. Awan adalah abstraksi di balik semua rak yang sama dengan besi di pusat data dan faktor manusia disembunyikan. Setiap perangkat keras cepat atau lambat gagal (meskipun kegagalan perangkat keras untuk pusat data lebih cenderung merupakan situasi biasa). Selain itu, ada kasus masalah yang lebih serius yang menyebabkan tidak dapat diaksesnya pusat data: kebakaran, serangan DDoS, bencana alam, gangguan listrik dan Internet, dll.

Jika kita berbicara tentang faktor manusia, maka ini bukan penyebab kecelakaan terakhir: "menurut statistik, di 80% dari kegagalan infrastruktur jaringan, orang yang harus disalahkan . " Orang, tidak peduli seberapa baik niat mereka dibimbing, tidak dapat diandalkan. Bahkan Anda dan kolega Anda - orang yang secara langsung tertarik pada stabilitas produk yang didukung - mungkin telah melakukan kesalahan, belum lagi personel perusahaan orang lain, yang instans Anda tidak berbeda dari ribuan lainnya. Apa pun tim profesional di balik infrastruktur, masalah baru adalah masalah waktu.

Semuanya ada harganya. Ketika Anda pindah ke cloud, Anda mendapatkan abstraksi sederhana, yang nyaman untuk bekerja dengan, ketergantungan yang lemah pada departemen operasi Anda dengan imbalan kontrol penuh atas situasi. Dalam hal ini, jika Anda tidak menjaga diri sendiri sebelumnya, setelah meramalkan kemungkinan kesalahan orang lain, tidak ada yang akan melakukan ini.

Opsi solusi

Bagi kami, tidak tersedianya layanan, bahkan selama beberapa menit, sudah kritis. Oleh karena itu, kami memutuskan untuk menemukan cara untuk memastikan diri terhadap masalah yang sama di masa depan, tanpa mengabaikan awan.

Ketika mulai memecahkan masalah ketersediaan layanan di cloud, harus diingat bahwa aksesibilitas adalah konsep yang cukup luas dan, tergantung pada apa yang dimaksud olehnya, berbagai skenario ketentuannya dipertimbangkan. Meskipun artikel ini hanya membahas masalah aksesibilitas sebagai akibat dari kegagalan pusat data, akan lebih tepat untuk mengatakan beberapa kata tentang solusi untuk masalah aksesibilitas lainnya.

Ketersediaan sebagai peluang teknis untuk menyediakan akses ke sumber daya untuk waktu tertentu pada beban tertentu. Masalah terjadi ketika layanan berjalan, tetapi karena sumber daya yang terbatas dan kerangka arsitektur sistem, tidak semua pengguna dapat mengaksesnya dalam waktu respons tertentu. Tugas ini paling sering diselesaikan dengan menggunakan instance tambahan dengan aplikasi. Dengan penskalaan ini, awan bekerja dengan baik.

Aksesibilitas sebagai ketersediaan layanan web untuk pengguna dari wilayah tertentu. Solusi yang jelas di sini adalah sharding. Dengan kata lain, membagi sistem menjadi beberapa aplikasi independen di pusat data yang berbeda dengan datanya sendiri dan menempatkan setiap pengguna ke instance sistemnya, misalnya, berdasarkan geo-location-nya. Saat beling, kegagalan satu pusat data dalam kasus terburuk akan mengakibatkan tidak tersedianya layanan hanya untuk sebagian pengguna yang terkait dengan pusat data ini. Bukan argumen terakhir yang mendukung sharding - ini adalah waktu ping yang berbeda dengan pusat data di berbagai wilayah.

Namun, seringkali pembatasan untuk bekerja dengan cloud dan perlunya desentralisasi adalah persyaratan legislatif yang biasanya diperhitungkan bahkan pada tahap desain sistem. Persyaratan ini meliputi: Hukum Yarovaya - penyimpanan data pribadi (PD) pengguna di Rusia; Peraturan Perlindungan Data Umum (GDPR) - pembatasan transfer lintas batas dari pengguna UE ke beberapa negara; dan sensor internet Cina, di mana SEMUA komunikasi dan SEMUA bagian dari aplikasi harus ditempatkan di Cina dan, lebih disukai, di server mereka.

Masalah tidak dapat diaksesnya teknis pusat data diselesaikan dengan menduplikasi layanan di pusat data lain. Ini bukan tugas teknis yang mudah. Hambatan utama untuk penyebaran layanan paralel di berbagai pusat data adalah database. Biasanya, sistem kecil menggunakan arsitektur wizard tunggal. Dalam hal ini, kegagalan pusat data dengan master membuat seluruh sistem tidak beroperasi. Skema replikasi master replikasi dimungkinkan, tetapi memberlakukan batasan kuat yang tidak semua orang mengerti. Bahkan, itu tidak skala catatan ke database, tetapi bahkan memberikan penalti waktu yang kecil, karena itu perlu untuk mengkonfirmasi semua node bahwa transaksi telah diterima. Waktu operasi penulisan meningkat bahkan lebih ketika node harus ditempatkan di pusat data yang berbeda.

Pembenaran keputusan

Analisis beban pada layanan kami menunjukkan bahwa rata-rata sekitar 70% panggilan ke API dilakukan dengan metode GET. Metode ini menggunakan database hanya baca.


Layanan panggilan distribusi metode HTTP Web

Saya pikir hasil ini mencerminkan keseluruhan gambaran layanan web yang tersedia secara umum. Oleh karena itu, kita dapat mengatakan bahwa dalam API layanan web rata-rata, metode membaca disebut lebih sering daripada metode menulis .

Pernyataan kedua yang ingin saya kemukakan adalah bahwa jika kita berbicara tentang aksesibilitas absolut, maka pelanggan layanan benar-benar membutuhkan aksesibilitas seperti itu tidak hanya dari kekayaan metode API yang tersedia, tetapi hanya mereka yang diperlukan untuk melanjutkan pekerjaan "biasa" dengan sistem. dan melakukan kueri "normal" . Tidak ada yang akan marah jika metode yang diakses beberapa kali dalam sebulan tidak tersedia selama beberapa menit. Seringkali, aliran "normal" ditutupi oleh metode membaca.

Oleh karena itu, memastikan ketersediaan absolut dari hanya metode membaca sudah dapat dianggap sebagai opsi yang memungkinkan untuk solusi jangka pendek untuk masalah ketersediaan sistem jika terjadi kegagalan pusat data.

Apa yang ingin kita terapkan

Jika terjadi kegagalan di pusat data, kami ingin mengalihkan lalu lintas ke sistem cadangan di pusat data lain. Dalam sistem cadangan, semua metode membaca harus tersedia, dan ketika memanggil metode yang tersisa, jika tidak mungkin dilakukan tanpa menulis ke database, kesalahan yang benar harus ditampilkan.

Dalam operasi normal, permintaan pengguna dikirim ke penyeimbang, yang pada gilirannya mengarahkannya ke API utama. Jika layanan utama tidak tersedia, penyeimbang menentukan fakta ini dan mengalihkan permintaan ke sistem cadangan yang beroperasi dalam mode fungsi terbatas. Pada saat ini, tim menganalisis masalah dan memutuskan untuk menunggu pemulihan pusat data atau mengalihkan sistem cadangan ke mode utama.

Algoritma implementasi

Perubahan infrastruktur yang diperlukan

1. Membuat replikasi budak database di pusat data lain.
2. Menyiapkan penyebaran layanan web, mengumpulkan log, metrik di pusat data kedua.
3. Konfigurasi penyeimbang untuk mengalihkan lalu lintas ke pusat data cadangan jika yang pertama tidak tersedia.

Perubahan Kode:

1. Menambahkan koneksi terpisah ke replika di layanan web.
2. Migrasikan semua rute API hanya-baca ke replika.
3. Untuk metode yang tersisa, pengenalan mode hanya baca melalui variabel lingkungan atau pemicu lainnya, di mana mereka alih-alih menulis ke database, sebagian akan berhasil atau, jika fungsionalitasnya rusak tanpa menulis ke database, memberikan kesalahan yang benar.
4. Perbaikan pada frontend untuk menampilkan kesalahan yang benar saat memanggil metode perekaman.

Pro dan kontra dari solusi yang dijelaskan

Manfaatnya

• Keuntungan utama dari skema yang diusulkan adalah bahwa selalu ada layanan duplikat, kapan saja siap melayani pengguna. Jika terjadi masalah dengan pusat data utama, Anda tidak perlu menulis skrip penerapan pada beberapa infrastruktur lain dan menjalankan semuanya dengan tergesa-gesa.
• Solusinya murah untuk diimplementasikan dan dipelihara. Jika Anda memiliki arsitektur layanan mikro dan produk tidak hanya membutuhkan satu tetapi banyak layanan, maka dalam hal ini seharusnya tidak ada masalah khusus dengan transfer semua layanan Microsoft ke skema ini.
• Tidak ada ancaman kehilangan data, karena selalu ada salinan lengkap dari database pada replika di pusat data lain.
• Solusinya terutama ditujukan untuk perpindahan lalu lintas sementara, hingga setengah jam. Setengah jam inilah yang tidak cukup untuk bernavigasi jika ada masalah dengan infrastruktur. Jika selama periode ini pusat data pertama tidak dipulihkan, replika budak dari database berubah menjadi master, dan layanan duplikat menjadi yang utama.
• Dalam skema yang diusulkan, aplikasi dan database berada di pusat data yang sama. Jika Anda memiliki API dan database di pusat data yang berbeda, maka yang terbaik adalah mentransfernya ke satu: ini akan secara signifikan mengurangi waktu eksekusi kueri. Sebagai contoh, pengukuran kami menunjukkan bahwa untuk Google Cloud, permintaan dari API ke basis data dalam satu pusat data rata-rata 6 ms, dan ketika pergi untuk data ke pusat data lain, waktunya meningkat puluhan milidetik.

Kekurangan

• Kelemahan utama dari keseluruhan skema adalah bahwa untuk peralihan lalu lintas instan, diperlukan penyeimbang yang tidak terletak di pusat data yang sama dengan layanan utama. Penyeimbang adalah titik kegagalan: jika pusat data dengan penyeimbang gagal, maka layanan Anda menjadi tidak tersedia dalam hal apa pun.
• Kebutuhan untuk menyebarkan kode ke server lain, memantau sumber daya tambahan - misalnya, memantau replika sehingga tidak ada jeda.

Kesimpulan

Anda tidak dapat membuat sistem yang tahan terhadap semua jenis kegagalan. Meskipun demikian, melindungi diri Anda dari tipe tertentu adalah tugas yang layak. Solusi yang dijelaskan dalam artikel, yang memungkinkan untuk memastikan ketersediaan aplikasi jika terjadi kegagalan fungsi di pusat data, dapat menarik dan bermanfaat dalam aplikasi praktis dalam banyak kasus.

Mengubah layanan web biasa menjadi sistem terdistribusi penuh untuk melindungi dari kegagalan hipotetis di pusat data kemungkinan besar tidak praktis. Pada pandangan pertama, bahkan skema yang diusulkan tampak berlebihan dan “berat”, tetapi kerugian ini lebih dari tumpang tindih oleh kelebihan dan kemudahan implementasi. Anda dapat menggambar analogi dengan asuransi kecelakaan: ada kemungkinan besar bahwa Anda tidak akan pernah membutuhkan asuransi semacam itu, tetapi jika kecelakaan terjadi, itu akan sangat disambut. Dengan skema yang diusulkan, Anda akan yakin bahwa Anda selalu memiliki sistem cadangan yang siap, yang, untuk masalah jangka pendek, akan memastikan ketersediaan sebagian besar metode layanan, dan jika terjadi kegagalan yang lama, ia dapat sepenuhnya berubah menjadi yang utama dalam hitungan menit. Banyak yang akan setuju untuk membayar harga ini untuk kepercayaan diri tersebut.

Setiap sistem memiliki parameter beban dan aksesibilitas yang unik. Itu sebabnya tidak ada jawaban benar atau salah untuk pertanyaan: "Bisakah Anda mempercayai Google Cloud atau AWS sepenuhnya?" - dalam setiap situasi tertentu ia akan menjadi miliknya sendiri.