Di musim panas, aktivitas pembelian dan intensitas perubahan dalam infrastruktur proyek web biasanya menurun, kata Captain Obvious. Hanya karena pakar IT pun terkadang pergi berlibur. Dan CTO juga. Hal ini menjadi lebih sulit bagi mereka yang masih menjabat, namun bukan itu masalahnya sekarang: mungkin itulah sebabnya musim panas adalah waktu terbaik untuk secara perlahan memikirkan skema reservasi yang ada dan menyusun rencana untuk memperbaikinya. Dan pengalaman Yegor Andreev dari , yang dia bicarakan di konferensi .
Ada beberapa kendala yang mungkin Anda alami saat membuat situs cadangan. Dan sangat mustahil untuk terjebak di dalamnya. Dan yang menghancurkan kita dalam semua ini, seperti dalam banyak hal lainnya, adalah perfeksionisme dan... kemalasan. Kita berusaha melakukan segalanya, segalanya, segalanya dengan sempurna, namun kita tidak perlu melakukannya dengan sempurna! Anda hanya perlu melakukan hal-hal tertentu saja, namun lakukan dengan benar, selesaikan agar berfungsi dengan baik.
Failover bukanlah hal menyenangkan yang menyenangkan βbiarlahβ; ini adalah sesuatu yang harus melakukan satu hal - mengurangi waktu henti sehingga layanan, perusahaan, kehilangan lebih sedikit uang. Dan dalam semua metode reservasi, saya menyarankan untuk memikirkan konteks berikut: di mana uangnya?
Perangkap pertama: ketika kita membangun sistem yang besar dan andal serta melakukan redundansi, kita mengurangi jumlah kecelakaan. Ini adalah kesalahpahaman yang buruk. Jika kita melakukan redundansi, kemungkinan besar kita akan meningkatkan jumlah kecelakaan. Dan jika kita melakukan semuanya dengan benar, maka secara kolektif kita akan mengurangi waktu henti. Akan ada lebih banyak kecelakaan, namun biayanya akan lebih rendah. Apa itu reservasi? - ini adalah komplikasi dari sistem. Komplikasi apa pun itu buruk: kita memiliki lebih banyak roda gigi, lebih banyak roda gigi, dengan kata lain, lebih banyak elemen - dan, oleh karena itu, kemungkinan kerusakan lebih tinggi. Dan mereka benar-benar akan hancur. Dan mereka akan lebih sering rusak. Contoh sederhananya: misalkan kita mempunyai website dengan PHP dan MySQL. Dan itu perlu segera dicadangkan.
Shtosh (c) Kami mengambil situs kedua, membangun sistem yang identik... Kompleksitasnya menjadi dua kali lebih besar - kami memiliki dua entitas. Kami juga menerapkan logika tertentu untuk mentransfer data dari satu situs ke situs lainnya - yaitu, replikasi data, menyalin data statis, dan seterusnya. Jadi, logika replikasi biasanya sangat kompleks, dan oleh karena itu, total kompleksitas sistem tidak bisa 2, tapi 3, 5, 10 kali lebih besar.
Perangkap kedua: ketika kita membangun sistem yang sangat besar dan kompleks, kita berfantasi tentang apa yang ingin kita dapatkan pada akhirnya. Voila: kami ingin mendapatkan sistem super andal yang bekerja tanpa downtime, beralih dalam setengah detik (atau lebih baik lagi, seketika), dan kami mulai mewujudkan impian. Namun ada juga nuansa di sini: semakin pendek waktu peralihan yang diinginkan, semakin kompleks logika sistemnya. Semakin rumit kita membuat logika ini, semakin sering sistem tersebut rusak. Dan Anda bisa berakhir dalam situasi yang sangat tidak menyenangkan: kami berusaha sekuat tenaga untuk mengurangi waktu henti, namun kenyataannya kami membuat segalanya menjadi lebih rumit, dan jika terjadi kesalahan, waktu henti akan menjadi lebih lama. Di sini Anda sering mendapati diri Anda berpikir: ya... lebih baik tidak membuat reservasi. Akan lebih baik jika ini bekerja sendiri dan dengan waktu henti yang dapat dimengerti.
Bagaimana Anda bisa melawannya? Kita perlu berhenti berbohong pada diri sendiri, berhenti menyanjung diri sendiri bahwa kita sekarang akan membangun pesawat luar angkasa, namun cukup memahami berapa lama proyek tersebut akan bertahan. Dan untuk waktu maksimal ini, kami akan memilih metode apa yang sebenarnya akan kami gunakan untuk meningkatkan keandalan sistem kami.
Sudah waktunya untuk βcerita dari wβ... dari kehidupan, tentu saja.
Contoh nomor satu
Bayangkan sebuah situs kartu nama Pabrik Rolling Pipa No. 1 di kota N. Di situ tertulis dengan huruf besar - PIPA ROLLING PLANT No. Tepat di bawahnya terdapat slogan: βPipa kami adalah pipa paling bulat di N.β Dan di bawah ini adalah nomor telepon CEO dan namanya. Kami memahami bahwa Anda perlu melakukan reservasi - ini adalah hal yang sangat penting! Mari kita mulai mencari tahu apa isinya. Html-statics - yaitu, beberapa gambar di mana manajer umum, sebenarnya, sedang mendiskusikan kesepakatan berikutnya di meja pemandian dengan rekannya. Kami mulai memikirkan waktu henti. Terlintas dalam pikiran: Anda perlu berbaring di sana selama lima menit, tidak lebih. Dan kemudian muncul pertanyaan: berapa banyak penjualan yang diperoleh dari situs kita ini secara umum? Berapa-berapa? Apa maksudnya "nol"? Artinya: karena sang jenderal melakukan keempat transaksi tahun lalu di meja yang sama, dengan orang yang sama dengan siapa mereka pergi ke pemandian dan duduk di meja. Dan kami memahami bahwa meskipun situs tersebut tidak digunakan selama sehari, tidak ada hal buruk yang akan terjadi.
Berdasarkan informasi pendahuluan, ada hari untuk mengangkat cerita ini. Mari kita mulai memikirkan skema redundansi. Dan kami memilih skema redundansi yang paling ideal untuk contoh ini: kami tidak menggunakan redundansi. Semua hal ini dapat diangkat oleh admin mana pun dalam waktu setengah jam dengan istirahat sejenak. Instal server web, tambahkan file - itu saja. Ini akan berhasil. Anda tidak perlu mengawasi apapun, Anda tidak perlu memberikan perhatian khusus pada apapun. Artinya, kesimpulan dari contoh nomor satu cukup jelas: layanan yang tidak perlu dicadangkan tidak perlu dicadangkan.
Contoh nomor dua
Blog perusahaan: orang-orang yang terlatih khusus menulis berita di sana, kami mengikuti pameran ini dan itu, tetapi kami merilis produk baru lagi, dan seterusnya. Katakanlah ini adalah PHP standar dengan WordPress, database kecil dan sedikit statis. Tentu saja, sekali lagi terlintas dalam pikiran bahwa Anda tidak boleh berbaring dalam keadaan apa pun - "tidak lebih dari lima menit!" Itu saja. Tapi mari kita berpikir lebih jauh. Apa fungsi blog ini? Orang-orang datang ke sana dari Yandex, dari Google berdasarkan beberapa pertanyaan, secara organik. Besar. Apakah penjualan ada hubungannya dengan itu? Epifani: tidak juga. Lalu lintas iklan menuju ke situs utama, yang ada di mesin lain. Mari mulai memikirkan skema pemesanan. Dalam cara yang baik, itu perlu dinaikkan dalam beberapa jam, dan alangkah baiknya jika mempersiapkannya. Masuk akal untuk mengambil mesin dari pusat data lain, memasukkan lingkungan ke dalamnya, yaitu server web, PHP, WordPress, MySQL, dan membiarkannya di sana. Pada saat kita memahami bahwa semuanya rusak, kita perlu melakukan dua hal - meluncurkan dump mysql sejauh 50 meter, itu akan terbang ke sana dalam satu menit, dan meluncurkan sejumlah gambar dari cadangan di sana. Ini juga tidak ada karena entah sampai kapan. Jadi, dalam waktu setengah jam semuanya akan beres. Tidak ada replikasi, atau Tuhan maafkan saya, failover otomatis. Kesimpulan: apa yang dapat kami luncurkan dengan cepat dari cadangan tidak perlu dicadangkan.
Contoh nomor tiga, lebih rumit
Toko online. PhP dengan hati terbuka sedikit diubah, mysql dengan basis yang kokoh. Cukup banyak statis (bagaimanapun juga, toko online memiliki gambar HD yang indah dan sebagainya), Redis untuk sesi dan Elasticsearch untuk pencarian. Kami mulai memikirkan waktu henti. Dan di sini, tentu saja, terlihat jelas bahwa toko online tidak bisa dibiarkan begitu saja selama sehari. Lagi pula, semakin lama disimpan, semakin banyak uang yang hilang. Ada baiknya untuk mempercepatnya. Berapa harganya? Saya pikir jika kita berbaring selama satu jam, tidak ada yang akan menjadi gila. Ya, kita akan kehilangan sesuatu, tetapi jika kita mulai bekerja keras, keadaannya hanya akan bertambah buruk. Kami menentukan skema waktu henti yang diperbolehkan per jam.
Bagaimana semua ini bisa dipesan? Bagaimanapun, Anda membutuhkan mobil: waktu satu jam sangatlah sedikit. Mysql: disini kita sudah membutuhkan replikasi, replikasi langsung, karena dalam satu jam kemungkinan besar 100 GB tidak akan ditambahkan ke dump. Statika, gambar: sekali lagi, dalam satu jam 500 GB mungkin tidak punya waktu untuk ditambahkan. Oleh karena itu, lebih baik segera salin gambarnya. Redis: di sinilah hal menjadi menarik. Di Redis, sesi disimpan - kita tidak bisa begitu saja mengambil dan menguburnya. Karena ini tidak terlalu bagus: semua pengguna akan logout, keranjang mereka akan dikosongkan, dan seterusnya. Orang-orang akan dipaksa untuk memasukkan kembali nama pengguna dan kata sandi mereka, dan banyak orang mungkin melepaskan diri dan tidak menyelesaikan pembelian. Sekali lagi, konversi akan turun. Di sisi lain, Redis sudah diperbarui secara langsung, dan pengguna yang masuk terakhir mungkin juga tidak diperlukan. Dan kompromi yang baik adalah dengan menggunakan Redis dan memulihkannya dari cadangan kemarin, atau, jika Anda melakukannya setiap jam, dari satu jam yang lalu. Untungnya, memulihkannya dari cadangan berarti menyalin satu file. Dan cerita yang paling menarik adalah Elasticsearch. Siapa yang pernah mempelajari replikasi MySQL? Siapa yang pernah menggunakan replikasi Elasticsearch? Dan untuk siapa itu berfungsi normal setelahnya? Yang saya maksud adalah kita melihat entitas tertentu di sistem kita. Tampaknya berguna - tetapi rumit.
Kompleks dalam arti bahwa rekan-rekan insinyur kami tidak memiliki pengalaman bekerja dengannya. Atau ada pengalaman negatif. Atau kami memahami bahwa ini masih merupakan teknologi yang cukup baru dengan nuansa atau kekasaran. Menurut kami... Sial, elastisnya juga sehat, butuh waktu lama juga untuk memulihkannya dari cadangan, apa yang harus saya lakukan? Kami memahami bahwa elastis dalam kasus kami digunakan untuk pencarian. Bagaimana toko online kami menjual? Kami menemui pemasar dan menanyakan dari mana orang-orang secara umum berasal. Mereka menjawab: β90% dari Pasar Yandex datang langsung ke kartu produk.β Dan entah mereka membelinya atau tidak. Oleh karena itu, pencarian dibutuhkan oleh 10% pengguna. Dan menjaga replikasi elastis, terutama antara pusat data yang berbeda di zona yang berbeda, memiliki banyak perbedaan. Pintu keluar yang mana? Kami mengambil elastis dari situs yang dipesan dan tidak melakukan apa pun dengannya. Jika kasusnya berlarut-larut, kami mungkin akan mengangkatnya suatu hari nanti, tapi itu belum pasti. Sebenarnya kesimpulannya sama, plus minusnya: kami sekali lagi tidak memesan layanan yang tidak mempengaruhi uang. Untuk membuat diagram lebih sederhana.
Contoh nomor empat, lebih sulit lagi
Integrator: menjual bunga, memanggil taksi, menjual barang, secara umum, apa saja. Suatu hal serius yang berfungsi 24/7 untuk banyak pengguna. Dengan tumpukan menarik yang lengkap, di mana terdapat pangkalan yang menarik, solusi, beban tinggi, dan yang paling penting, menyakitkan untuk berbaring selama lebih dari 5 menit. Bukan hanya karena orang-orang tidak mau membeli, tapi karena orang-orang melihat bahwa produk ini tidak berfungsi, mereka akan merasa kesal dan mungkin tidak akan kembali lagi.
OKE. Lima menit. Apa yang akan kita lakukan mengenai hal ini? Dalam hal ini, kami, seperti orang dewasa, menggunakan semua uang untuk membangun situs cadangan yang nyata, dengan replikasi semuanya, dan bahkan mungkin mengotomatiskan peralihan ke situs ini sebanyak mungkin. Dan selain itu, Anda perlu ingat untuk melakukan satu hal penting: sebenarnya, tuliskan peraturan peralihan. Peraturannya, meskipun semuanya sudah otomatis, bisa sangat sederhana. Dari rangkaian "jalankan skrip yang memungkinkan", "klik kotak centang ini dan itu di rute 53" dan seterusnya - tetapi ini pasti semacam daftar tindakan yang tepat.
Dan semuanya tampak jelas. Mengalihkan replikasi adalah tugas yang sepele, atau akan beralih dengan sendirinya. Penulisan ulang nama domain di DNS berasal dari seri yang sama. Masalahnya adalah ketika proyek semacam itu gagal, kepanikan mulai terjadi, dan bahkan admin yang paling kuat dan berjanggut pun bisa rentan terhadapnya. Tanpa instruksi yang jelas βbuka terminal, kemari, alamat server kami masih seperti iniβ, sulit untuk memenuhi batas waktu 5 menit yang diberikan untuk resusitasi. Ditambah lagi, ketika kita menggunakan peraturan ini, kita akan dengan mudah mencatat beberapa perubahan pada infrastruktur, misalnya, dan mengubah peraturan tersebut.
Nah, jika sistem reservasi sangat rumit dan pada titik tertentu kami melakukan kesalahan, maka kami dapat menghancurkan situs cadangan kami, dan sebagai tambahan, mengubah data menjadi labu di kedua situs - ini akan sangat menyedihkan.
Contoh nomor lima, hardcore lengkap
Layanan internasional dengan ratusan juta pengguna di seluruh dunia. Semua zona waktu ada, beban tinggi dengan kecepatan maksimal, Anda tidak bisa berbaring sama sekali. Sebentar - dan itu akan menyedihkan. Apa yang harus dilakukan? Cadangan, sekali lagi, sesuai program lengkap. Kami melakukan semua yang saya bicarakan pada contoh sebelumnya, dan banyak lagi. Dunia yang ideal, dan infrastruktur kami sesuai dengan semua konsep pengembang IaaC. Artinya, semuanya ada di git, dan Anda cukup menekan tombolnya.
Apa yang hilang? Satu - latihan. Tidak mungkin tanpa mereka. Tampaknya semuanya sempurna bagi kami, umumnya semuanya terkendali. Kami menekan tombolnya, semuanya terjadi. Meskipun demikian - dan kami memahami bahwa hal ini tidak terjadi - sistem kami berinteraksi dengan beberapa sistem lain. Misalnya, ini adalah dns dari rute 53, penyimpanan s3, integrasi dengan beberapa api. Kami tidak akan bisa meramalkan semuanya dalam eksperimen spekulatif ini. Dan sampai kita benar-benar menarik tombolnya, kita tidak akan tahu apakah ini akan berhasil atau tidak.
Mungkin itu saja. Jangan malas atau berlebihan. Dan semoga waktu aktif menyertai Anda!
Sumber: www.habr.com