Pada musim panas, kedua-dua aktiviti pembelian dan intensiti perubahan dalam infrastruktur projek web secara tradisinya berkurangan, Kapten Obvious memberitahu kami. Hanya kerana pakar IT pun kadang-kadang pergi bercuti. Dan CTO juga. Ia lebih sukar bagi mereka yang kekal di pejabat, tetapi itu bukan perkara sekarang: mungkin itulah sebabnya musim panas adalah tempoh terbaik untuk perlahan-lahan memikirkan skim tempahan sedia ada dan merangka rancangan untuk memperbaikinya. Dan pengalaman Yegor Andreev dari , yang dibicarakannya pada persidangan itu .
Terdapat beberapa perangkap yang boleh anda hadapi semasa membina tapak sandaran. Dan sangat mustahil untuk terperangkap di dalamnya. Dan apa yang merosakkan kita dalam semua ini, seperti dalam banyak perkara lain, adalah kesempurnaan dan... kemalasan. Kami cuba melakukan segala-galanya, segala-galanya, semuanya dengan sempurna, tetapi kami tidak perlu melakukannya dengan sempurna! Anda hanya perlu melakukan perkara-perkara tertentu, tetapi lakukan dengan betul, lengkapkannya supaya ia berfungsi dengan baik.
Failover bukanlah sejenis perkara yang menyeronokkan "jadilah"; ini adalah perkara yang sepatutnya melakukan satu perkara - mengurangkan masa henti supaya perkhidmatan, syarikat, kehilangan wang yang lebih sedikit. Dan dalam semua kaedah tempahan, saya cadangkan berfikir dalam konteks berikut: di manakah wang itu?
Perangkap pertama: apabila kami membina sistem yang besar dan boleh dipercayai dan terlibat dalam redundansi, kami mengurangkan bilangan kemalangan. Ini adalah salah tanggapan yang dahsyat. Apabila kita terlibat dalam pemberhentian kerja, kita berkemungkinan akan meningkatkan bilangan kemalangan. Dan jika kita melakukan semuanya dengan betul, maka secara kolektif kita akan mengurangkan masa henti. Akan ada lebih banyak kemalangan, tetapi ia akan berlaku pada kos yang lebih rendah. Apa itu tempahan? - ini adalah komplikasi sistem. Sebarang komplikasi adalah buruk: kami mempunyai lebih banyak roda gigi, lebih banyak gear, secara ringkasnya, lebih banyak elemen - dan, oleh itu, peluang kerosakan yang lebih tinggi. Dan mereka benar-benar akan pecah. Dan mereka akan pecah lebih kerap. Contoh mudah: katakan kita mempunyai tapak web dengan PHP dan MySQL. Dan ia perlu ditempah dengan segera.
Shtosh (c) Kami mengambil tapak kedua, membina sistem yang sama... Kerumitan menjadi dua kali lebih hebat - kami mempunyai dua entiti. Kami juga melancarkan logik tertentu untuk memindahkan data dari satu tapak ke tapak yang lain - iaitu, replikasi data, menyalin data statik dan sebagainya. Jadi, logik replikasi biasanya sangat kompleks, dan oleh itu, jumlah kerumitan sistem boleh bukan 2, tetapi 3, 5, 10 kali lebih besar.
Perangkap kedua: apabila kita membina sistem kompleks yang sangat besar, kita berkhayal tentang apa yang kita ingin dapatkan pada akhirnya. Voila: kami ingin mendapatkan sistem yang sangat boleh dipercayai yang berfungsi tanpa sebarang masa henti, bertukar dalam setengah saat (atau lebih baik lagi, serta-merta), dan kami mula membuat impian menjadi kenyataan. Tetapi terdapat juga nuansa di sini: semakin pendek masa pensuisan yang diingini, semakin kompleks logik sistem menjadi. Lebih kompleks kita perlu membuat logik ini, lebih kerap sistem akan rosak. Dan anda boleh berakhir dalam situasi yang sangat tidak menyenangkan: kami cuba sedaya upaya untuk mengurangkan masa henti, tetapi sebenarnya kami menjadikan segala-galanya lebih rumit, dan apabila berlaku masalah, masa henti akan menjadi lebih lama. Di sini anda sering terfikir: baik... adalah lebih baik untuk tidak membuat tempahan. Adalah lebih baik jika ia berfungsi secara bersendirian dan dengan masa henti yang boleh difahami.
Bagaimana anda boleh melawan ini? Kita perlu berhenti berbohong kepada diri kita sendiri, berhenti memuji diri kita sendiri bahawa kita akan membina kapal angkasa di sini sekarang, tetapi memahami dengan secukupnya berapa lama projek itu boleh berbohong. Dan untuk masa maksimum ini, kami akan memilih kaedah yang sebenarnya akan kami gunakan untuk meningkatkan kebolehpercayaan sistem kami.
Sudah tiba masanya untuk "cerita dari w"... dari kehidupan, sudah tentu.
Contoh nombor satu
Bayangkan laman web kad perniagaan untuk Loji Gelek Paip No. 1 di bandar N. Ia tertera dalam huruf besar - LOJI GOLEK PAIP No. 1. Di bawah adalah slogan: "Paip kami ialah paip paling bulat di N." Dan di bawah adalah nombor telefon CEO dan namanya. Kami faham bahawa anda perlu membuat tempahan - ini adalah perkara yang sangat penting! Mari kita mula memikirkan apa yang terdiri daripadanya. Html-statics - iaitu, beberapa gambar di mana pengurus besar, sebenarnya, sedang membincangkan beberapa jenis perjanjian seterusnya di meja di rumah mandi dengan pasangannya. Kami mula memikirkan masa henti. Terlintas di fikiran: anda perlu berbaring di sana selama lima minit, tidak lebih. Dan kemudian persoalan timbul: berapa banyak jualan yang terdapat dari laman web kami ini secara umum? Berapa-berapa? Apakah maksud "sifar"? Dan ini bermakna: kerana jeneral membuat semua empat transaksi tahun lepas di meja yang sama, dengan orang yang sama dengan siapa mereka pergi ke rumah mandi dan duduk di meja. Dan kami faham bahawa walaupun tapak itu duduk selama sehari, tiada perkara buruk akan berlaku.
Berdasarkan maklumat pengenalan, ada hari untuk membangkitkan kisah ini. Mari kita mula memikirkan tentang skim redundansi. Dan kami memilih skim redundansi yang paling ideal untuk contoh ini: kami tidak menggunakan redundansi. Semua perkara ini boleh dibangkitkan oleh mana-mana admin dalam masa setengah jam dengan pemecahan asap. Pasang pelayan web, tambah fail - itu sahaja. Ia akan berfungsi. Anda tidak perlu mengawasi apa-apa, anda tidak perlu memberi perhatian khusus kepada apa-apa. Maksudnya, kesimpulan daripada contoh nombor satu agak jelas: perkhidmatan yang tidak perlu ditempah tidak perlu ditempah.
Contoh nombor dua
Blog syarikat: orang yang terlatih khas menulis berita di sana, kami mengambil bahagian dalam pameran itu dan itu, tetapi kami mengeluarkan satu lagi produk baharu, dan sebagainya. Katakan ini adalah PHP standard dengan WordPress, pangkalan data yang kecil dan sedikit statik. Sudah tentu, terlintas di fikiran sekali lagi bahawa anda tidak boleh berbaring dalam apa jua keadaan - "tidak lebih daripada lima minit!" Itu sahaja. Tetapi mari kita berfikir lebih jauh. Apa yang blog ini buat? Orang datang ke sana dari Yandex, dari Google berdasarkan beberapa pertanyaan, secara organik. Hebat. Adakah jualan ada kaitan dengannya? Epiphany: tidak juga. Trafik pengiklanan pergi ke tapak utama, iaitu pada mesin yang berbeza. Mari kita mula memikirkan tentang skim tempahan. Dengan cara yang baik, ia perlu dinaikkan dalam beberapa jam, dan adalah baik untuk bersedia untuk ini. Adalah munasabah untuk mengambil mesin dari pusat data lain, melancarkan persekitaran ke atasnya, iaitu, pelayan web, PHP, WordPress, MySQL, dan biarkan di sana. Pada masa ini apabila kita memahami bahawa semuanya rosak, kita perlu melakukan dua perkara - melancarkan dump mysql 50 meter, ia akan terbang ke sana dalam satu minit, dan melancarkan sejumlah gambar dari sandaran di sana. Ini juga tidak ada kerana Tuhan yang tahu berapa lama. Oleh itu, dalam setengah jam semuanya meningkat. Tiada replikasi, atau Tuhan ampunkan saya, failover automatik. Kesimpulan: apa yang boleh kami keluarkan dengan cepat daripada sandaran tidak perlu disandarkan.
Contoh nombor tiga, lebih rumit
Kedai atas talian. PhP dengan hati terbuka sedikit tweak, mysql dengan asas yang kukuh. Agak banyak statik (lagipun, kedai dalam talian mempunyai imej HD yang cantik dan semua perkara itu), Redis untuk sesi dan Elasticsearch untuk carian. Kami mula memikirkan masa henti. Dan di sini, sudah tentu, adalah jelas bahawa kedai dalam talian tidak boleh berbaring tanpa rasa sakit selama sehari. Lagipun, semakin lama, semakin banyak wang yang kita hilang. Patut dipercepatkan. Berapa banyak? Aku rasa kalau kita baring sejam, takde orang gila. Ya, kita akan kehilangan sesuatu, tetapi jika kita mula bekerja keras, ia akan menjadi lebih teruk. Kami mentakrifkan skema masa henti yang dibenarkan setiap jam.
Bagaimana semua ini boleh ditempah? Anda memerlukan kereta dalam apa jua keadaan: masa sejam agak sedikit. Mysql: di sini kita sudah memerlukan replikasi, replikasi langsung, kerana dalam satu jam 100 GB kemungkinan besar tidak akan ditambah ke tempat pembuangan. Statik, gambar: sekali lagi, dalam satu jam 500 GB mungkin tidak mempunyai masa untuk ditambah. Oleh itu, adalah lebih baik untuk menyalin gambar dengan segera. Redis: di sinilah perkara menjadi menarik. Di Redis, sesi disimpan - kita tidak boleh mengambilnya dan menguburkannya. Kerana ini tidak akan menjadi sangat baik: semua pengguna akan dilog keluar, bakul mereka akan dikosongkan, dan sebagainya. Orang ramai akan dipaksa untuk memasukkan semula nama pengguna dan kata laluan mereka, dan ramai orang mungkin melepaskan diri dan tidak menyelesaikan pembelian. Sekali lagi, penukaran akan menurun. Sebaliknya, Redis secara langsung terkini, dengan pengguna log masuk terakhir mungkin tidak diperlukan sama ada. Dan kompromi yang baik adalah dengan mengambil Redis dan memulihkannya daripada sandaran dari semalam, atau, jika anda melakukannya setiap jam, dari sejam yang lalu. Nasib baik, memulihkannya daripada sandaran bermakna menyalin satu fail. Dan cerita yang paling menarik ialah Elasticsearch. Siapa yang pernah mengambil replikasi MySQL? Siapa yang pernah mengambil replikasi Elasticsearch? Dan untuk siapa ia berfungsi seperti biasa selepas itu? Apa yang saya maksudkan ialah kita melihat entiti tertentu dalam sistem kita. Nampaknya ia berguna - tetapi ia adalah kompleks.
Kompleks dalam erti kata bahawa rakan jurutera kami tidak mempunyai pengalaman bekerja dengannya. Atau ada pengalaman negatif. Atau kami faham bahawa ini masih merupakan teknologi yang agak baru dengan nuansa atau mentah. Kami fikir... Alamak, elastik juga sihat, ia juga mengambil masa yang lama untuk memulihkannya dari sandaran, apa yang perlu saya lakukan? Kami faham bahawa elastik dalam kes kami digunakan untuk carian. Bagaimanakah kedai dalam talian kami menjual? Kami pergi ke pemasar dan bertanya dari mana orang datang. Mereka menjawab: "90% daripada Pasaran Yandex datang terus ke kad produk." Dan sama ada mereka membelinya atau tidak. Oleh itu, carian diperlukan oleh 10% pengguna. Dan mengekalkan replikasi elastik, terutamanya antara pusat data yang berbeza di zon yang berbeza, benar-benar mempunyai banyak nuansa. Keluar yang mana? Kami mengambil anjal dari tapak yang dikhaskan dan tidak melakukan apa-apa dengannya. Sekiranya perkara itu berlarutan, kami mungkin akan membangkitkannya suatu hari nanti, tetapi ini tidak pasti. Sebenarnya, kesimpulannya adalah sama, tambah atau tolak: kami, sekali lagi, tidak menempah perkhidmatan yang tidak menjejaskan wang. Untuk memastikan rajah lebih ringkas.
Contoh nombor empat, lagi susah
Integrator: menjual bunga, menelefon teksi, menjual barang, secara umum, apa sahaja. Perkara yang serius yang berfungsi 24/7 untuk sebilangan besar pengguna. Dengan timbunan menarik yang lengkap, di mana terdapat pangkalan yang menarik, penyelesaian, beban tinggi, dan yang paling penting, ia menyakitkan untuk berbaring selama lebih daripada 5 minit. Bukan sahaja dan bukan kerana orang tidak akan membeli, tetapi kerana orang akan melihat bahawa perkara ini tidak berfungsi, mereka akan kecewa dan mungkin tidak akan kembali sama sekali.
OKEY. Lima minit. Apa yang akan kita lakukan mengenai perkara ini? Dalam kes ini, kami, seperti orang dewasa, menggunakan semua wang untuk membina tapak sandaran sebenar, dengan replikasi segala-galanya, dan mungkin juga mengautomasikan penukaran ke tapak ini sebanyak mungkin. Dan sebagai tambahan kepada ini, anda perlu ingat untuk melakukan satu perkara penting: sebenarnya, tulis peraturan penukaran. Peraturan, walaupun anda mempunyai segala-galanya secara automatik, boleh menjadi sangat mudah. Daripada siri "jalankan skrip boleh jadi begini dan begitu", "klik kotak semak begini dan begitu dalam laluan 53" dan seterusnya - tetapi ini mestilah sejenis senarai tindakan yang tepat.
Dan semuanya nampak jelas. Menukar replikasi adalah tugas remeh, atau ia akan menukar dirinya sendiri. Menulis semula nama domain dalam DNS adalah daripada siri yang sama. Masalahnya ialah apabila projek sedemikian gagal, panik bermula, malah pentadbir yang paling kuat dan berjanggut boleh terdedah kepadanya. Tanpa arahan yang jelas "buka terminal, datang ke sini, alamat pelayan kami masih seperti ini," sukar untuk memenuhi had masa 5 minit yang diperuntukkan untuk resusitasi. Selain itu, apabila kita menggunakan peraturan ini, mudah untuk merekodkan beberapa perubahan dalam infrastruktur, contohnya, dan mengubah peraturan dengan sewajarnya.
Nah, jika sistem tempahan sangat rumit dan pada satu ketika kami membuat kesilapan, maka kami boleh memusnahkan tapak sandaran kami, dan di samping itu mengubah data menjadi labu di kedua-dua tapak - ini akan menyedihkan sepenuhnya.
Contoh nombor lima, tegar lengkap
Perkhidmatan antarabangsa dengan ratusan juta pengguna di seluruh dunia. Semua zon waktu ada, beban tinggi pada kelajuan maksimum, anda tidak boleh baring langsung. Seminit - dan ia akan menjadi sedih. Apa nak buat? Tempah, sekali lagi, mengikut program penuh. Kami melakukan semua yang saya bincangkan dalam contoh sebelumnya, dan sedikit lagi. Dunia yang ideal, dan infrastruktur kami adalah mengikut semua konsep IaaC devops. Iaitu, semuanya dalam git, dan anda hanya menekan butang.
Apa yang hilang? Satu - latihan. Mustahil tanpa mereka. Nampaknya segala-galanya sempurna dengan kami, kami biasanya mempunyai segala-galanya di bawah kawalan. Kami menekan butang, semuanya berlaku. Walaupun begitu - dan kami faham bahawa ia tidak berlaku dengan cara ini - sistem kami berinteraksi dengan beberapa sistem lain. Sebagai contoh, ini adalah dns dari laluan 53, storan s3, penyepaduan dengan beberapa api. Kami tidak akan dapat meramalkan segala-galanya dalam percubaan spekulatif ini. Dan sehingga kita benar-benar menarik suis, kita tidak akan tahu sama ada ia akan berfungsi atau tidak.
Itu sahaja mungkin. Jangan malas atau berlebihan. Dan mungkin uptime bersama anda!
Sumber: www.habr.com