Kaptan Açık, yaz aylarında hem satın alma faaliyetlerinin hem de web projelerinin altyapısındaki değişikliklerin yoğunluğunun geleneksel olarak azaldığını söylüyor. Çünkü BT uzmanları bile bazen tatile çıkıyor. Ve CTO da. Görevde kalanlar için durum daha da zor, ancak şu anda mesele bu değil: Belki de bu nedenle yaz, mevcut rezervasyon planı hakkında yavaş yavaş düşünmek ve onu geliştirmek için bir plan hazırlamak için en iyi dönemdir. Ve Yegor Andreev'in deneyimi konferansta bahsettiği .
Yedekleme siteleri oluştururken karşılaşabileceğiniz çeşitli tuzaklar vardır. Ve onlara yakalanmak kesinlikle imkansızdır. Ve pek çok şeyde olduğu gibi bunda da bizi mahveden şey, mükemmeliyetçilik ve... tembelliktir. Her şeyi, her şeyi, her şeyi mükemmel yapmaya çalışıyoruz ama mükemmel yapmamıza gerek yok! Sadece belirli şeyleri yapmanız gerekiyor ama bunları doğru yapın, tamamlayın ki düzgün çalışsınlar.
Yük devretme bir tür eğlenceli, eğlenceli bir şey değildir; bu tam olarak tek bir şeyi yapması gereken bir şeydir: hizmetin, şirketin daha az para kaybetmesi için kesinti süresini azaltmak. Ve tüm rezervasyon yöntemlerinde şu bağlamda düşünmenizi öneririm: Para nerede?
İlk tuzak: Büyük, güvenilir sistemler oluşturduğumuzda ve yedeklilik sağladığımızda kaza sayısını azaltıyoruz. Bu korkunç bir yanılgıdır. İşten çıkarma yaptığımızda muhtemelen kaza sayısını artıracağız. Ve her şeyi doğru yaparsak, toplu olarak kesinti süresini azaltacağız. Daha fazla kaza olacak ama bunlar daha düşük maliyetlerle gerçekleşecek. Rezervasyon nedir? - bu sistemin bir komplikasyonudur. Her türlü komplikasyon kötüdür: Daha fazla çarkımız, daha fazla dişlimiz, kısacası daha fazla unsurumuz var ve dolayısıyla arıza olasılığımız daha yüksek. Ve gerçekten kırılacaklar. Ve daha sık kırılacaklar. Basit bir örnek: Diyelim ki PHP ve MySQL içeren bir web sitemiz var. Ve acilen rezerve edilmesi gerekiyor.
Shtosh (c) İkinci siteyi alıyoruz, aynı sistemi kuruyoruz... Karmaşıklık iki kat daha büyük hale geliyor - iki varlığımız var. Ayrıca, verileri bir siteden diğerine aktarmak için belirli bir mantık (veri çoğaltma, statik veri kopyalama vb.) sunuyoruz. Yani kopyalama mantığı genellikle çok karmaşıktır ve bu nedenle sistemin toplam karmaşıklığı 2 değil 3, 5, 10 kat daha fazla olabilir.
İkinci tuzak: Gerçekten büyük ve karmaşık sistemler oluşturduğumuzda, sonunda ne elde etmek istediğimizin hayalini kurarız. Voila: Herhangi bir kesinti olmadan çalışan, yarım saniyede (veya daha iyisi anında) geçiş yapan süper güvenilir bir sistem elde etmek istiyoruz ve hayalleri gerçeğe dönüştürmeye başlıyoruz. Ancak burada bir nüans da var: İstenilen anahtarlama süresi ne kadar kısa olursa sistem mantığı da o kadar karmaşık hale gelir. Bu mantığı ne kadar karmaşık hale getirirsek sistem o kadar sık bozulur. Ve kendinizi çok hoş olmayan bir durumla karşı karşıya bırakabilirsiniz: tüm gücümüzle kesinti süresini azaltmaya çalışıyoruz, ancak aslında her şeyi daha karmaşık hale getiriyoruz ve bir şeyler ters gittiğinde, kesinti süresi daha da uzayacak. Burada sık sık kendinizi şunu düşünürken buluyorsunuz: yani... rezervasyon yapmamak daha iyi olur. Tek başına ve anlaşılır bir kesinti süresiyle çalışması daha iyi olurdu.
Bununla nasıl savaşabilirsin? Kendimize yalan söylemeyi bırakmalı, burada artık bir uzay gemisi inşa edeceğiz diye kendimizi övmeyi bırakmalıyız, ancak projenin ne kadar uzun süre dayanabileceğini yeterince anlamalıyız. Ve bu maksimum süre boyunca sistemimizin güvenilirliğini artırmak için gerçekte hangi yöntemleri kullanacağımızı seçeceğiz.
Artık "w'den hikayeler" zamanı... hayattan elbette.
Bir numaralı örnek
N şehrinde 1 No'lu Boru Haddeleme Tesisi için bir kartvizit web sitesi hayal edin. Büyük harflerle - 1 No'lu BORU HADDELEME TESİSİ yazdığını hayal edin. Hemen altında şu slogan yer alıyor: “Borularımız N’deki en yuvarlak borulardır.” Aşağıda da CEO'nun telefon numarası ve adı yer alıyor. Rezervasyon yaptırmanız gerektiğini anlıyoruz - bu çok önemli bir şey! Neyden oluştuğunu anlamaya başlayalım. Html-statik - yani genel müdürün aslında hamamdaki masada ortağıyla bir tür sonraki anlaşmayı tartıştığı birkaç resim. Arıza sürelerini düşünmeye başlıyoruz. Aklıma şu geliyor: Orada beş dakika yatmanız gerekiyor, daha fazla değil. Ve sonra şu soru ortaya çıkıyor: Bu sitemizden genel olarak kaç satış oldu? Ne kadar-ne kadar? "Sıfır" ne anlama geliyor? Bu da şu anlama geliyor: Çünkü general geçen yıl dört işlemi de aynı masada, hamama gidip masaya oturduğu aynı kişilerle yaptı. Ve site bir gün otursa bile korkunç bir şey olmayacağını anlıyoruz.
Giriş bilgilerine göre bu hikayeyi gündeme getirmenin bir günü var. Bir işten çıkarma planı düşünmeye başlayalım. Ve bu örnek için en ideal yedekleme şemasını seçiyoruz: artıklık kullanmıyoruz. Bütün bunlar herhangi bir yönetici tarafından yarım saat içinde duman molalarıyla gündeme getirilebilir. Bir web sunucusu kurun, dosya ekleyin - işte bu kadar. Çalışacak. Hiçbir şeye dikkat etmenize gerek yok, hiçbir şeye özel dikkat göstermenize gerek yok. Yani, bir numaralı örnekten çıkan sonuç oldukça açıktır: rezerve edilmesi gerekmeyen hizmetlerin rezerve edilmesine de gerek yoktur.
İki numaralı örnek
Şirket blogu: Orada özel eğitimli insanlar haber yazıyor, filan fuara katıldık ama yeni bir ürün daha çıkardık falan. Diyelim ki bu WordPress'li standart PHP, küçük bir veritabanı ve biraz statik. Tabii ki, hiçbir durumda uzanmamanız gerektiği tekrar aklıma geliyor - “beş dakikadan fazla değil!” Hepsi bu. Ama daha fazla düşünelim. Bu blog ne işe yarıyor? İnsanlar oraya Yandex'den, Google'dan bazı sorgulara dayanarak organik olarak geliyorlar. Harika. Satışların bununla bir alakası var mı? Epifani: pek değil. Reklam trafiği farklı bir makinedeki ana siteye gider. Bir rezervasyon planı düşünmeye başlayalım. İyi anlamda, birkaç saat içinde yetiştirilmesi gerekiyor ve buna hazırlanmak güzel olurdu. Başka bir veri merkezinden bir makine alıp ortamı onun üzerine yani bir web sunucusunun, PHP, WordPress, MySQL'in üzerine yuvarlayıp orada bırakmak mantıklı olacaktır. Her şeyin bozulduğunu anladığımız anda, iki şey yapmamız gerekiyor - MySQL dökümünü 50 metreye açın, bir dakika içinde oraya uçacak ve oradaki yedekten belirli sayıda resmi yayınlayacak. Bu da Tanrı bilir ne kadar süredir orada değil. Böylece yarım saat içinde her şey yükselir. Çoğaltma yok, ya da Tanrı beni affetsin, otomatik yük devretme. Sonuç: Bir yedeklemeden hızlı bir şekilde çıkarabildiğimiz şeyin yedeklenmesine gerek yoktur.
Üçüncü örnek, daha karmaşık
Online mağaza. Açık kalpli PhP biraz değiştirilmiş, MySQL ise sağlam bir temele sahip. Oldukça fazla statik (sonuçta çevrimiçi mağazada çok güzel HD görüntüler ve benzeri şeyler var), oturum için Redis ve arama için Elasticsearch. Arıza sürelerini düşünmeye başlıyoruz. Ve burada elbette bir çevrimiçi mağazanın bir gün boyunca acısız bir şekilde ortalıkta kalamayacağı açıktır. Sonuçta ne kadar uzun süre yatarsa o kadar çok para kaybederiz. Hızlanmaya değer. Ne kadar? Sanırım bir saat uzansak kimse delirmez. Evet, bir şeyler kaybedeceğiz ama çok çalışmaya başlarsak durum daha da kötüleşecek. Saat başına izin verilen bir kesinti planı tanımlarız.
Bütün bunlar nasıl saklı tutulabilir? Her halükarda bir arabaya ihtiyacınız var: bir saatlik süre oldukça az. Mysql: burada zaten çoğaltmaya, canlı çoğaltmaya ihtiyacımız var, çünkü bir saat içinde 100 GB büyük olasılıkla döküme eklenmeyecek. Statikler, resimler: yine bir saat içinde 500 GB'ın eklenmesi için zaman olmayabilir. Bu nedenle resimleri hemen kopyalamak daha iyidir. Redis: İşlerin ilginçleştiği yer burası. Redis'te oturumlar depolanır; onu öylece alıp gömemeyiz. Çünkü bu pek iyi olmayacak: tüm kullanıcıların oturumu kapatılacak, sepetleri boşaltılacak vb. İnsanlar kullanıcı adlarını ve şifrelerini yeniden girmek zorunda kalacak ve birçok kişi ayrılıp satın alma işlemini tamamlayamayabilir. Dönüşümler yine düşecek. Öte yandan, Redis doğrudan günceldir ve muhtemelen son oturum açan kullanıcılara da ihtiyaç duyulmaz. Redis'i alıp dünkü yedekten veya bunu her saat başı yapıyorsanız bir saat önceki yedekten geri yüklemek iyi bir uzlaşmadır. Neyse ki, onu bir yedekten geri yüklemek, bir dosyayı kopyalamak anlamına gelir. Ve en ilginç hikaye Elasticsearch'tür. Kim MySQL çoğaltmasını aldı? Elasticsearch çoğaltmasını kim aldı? Peki bundan sonra kimin için normal çalıştı? Demek istediğim, sistemimizde belli bir varlığı görüyoruz. Yararlı gibi görünüyor ama karmaşık.
Mühendis arkadaşlarımızın onunla çalışma deneyimi olmaması açısından karmaşık. Veya olumsuz bir deneyim var. Veya bunun hala oldukça yeni ve nüansları veya hamlığı olan bir teknoloji olduğunu anlıyoruz. Düşünüyoruz... Lanet olsun, elastik de sağlıklı, yedekten geri yüklemek de uzun sürüyor, ne yapmalıyım? Bizim durumumuzda elastikin arama için kullanıldığını anlıyoruz. Online mağazamız nasıl satış yapıyor? Pazarlamacılara gidiyoruz ve insanların nereden geldiğini soruyoruz. Cevap veriyorlar: "Yandex Market'in %90'ı doğrudan ürün kartına geliyor." Ve ya satın alırlar ya da almazlar. Bu nedenle, kullanıcıların %10'u aramaya ihtiyaç duyuyor. Özellikle farklı bölgelerdeki farklı veri merkezleri arasında elastik çoğaltmanın sürdürülmesinin gerçekten birçok nüansı var. Hangi çıkış? Ayrılmış bir siteden elastik alıyoruz ve onunla hiçbir şey yapmıyoruz. Konu uzarsa muhtemelen bir gün gündeme getireceğiz ama bu kesin değil. Aslında artı veya eksi sonuç aynı: yine parayı etkilemeyen hizmetleri rezerve etmiyoruz. Diyagramı daha basit tutmak için.
Dördüncü örnek, daha da zor
Entegratör: çiçek satmak, taksi çağırmak, mal satmak, genel olarak her şey. Çok sayıda kullanıcı için 24/7 çalışan ciddi bir şey. İlginç üslerin, çözümlerin, yüksek yükün olduğu ve en önemlisi 5 dakikadan fazla uzanmanın acı verdiği tam teşekküllü ilginç bir yığınla. Sadece insanlar satın almayacağı için değil, aynı zamanda insanlar bu şeyin işe yaramadığını gördükleri için üzülecekler ve bir daha geri gelmeyebilirler.
TAMAM. Beş dakika. Bu konuda ne yapacağız? Bu durumda, yetişkinler gibi biz de tüm parayı, her şeyin kopyalandığı gerçek bir yedekleme sitesi oluşturmak ve hatta bu siteye geçişi mümkün olduğunca otomatikleştirmek için kullanırız. Buna ek olarak önemli bir şeyi de hatırlamanız gerekiyor: Aslında geçiş düzenlemelerini yazın. Her şey otomatikleştirilmiş olsa bile düzenlemeler çok basit olabilir. "Şu ve bu yanıtlayıcı komut dosyasını çalıştır" dizisinden, "rota 53'te falan ve şu onay kutusunu tıklayın" vb. - ancak bu bir tür tam eylem listesi olmalıdır.
Ve her şey açık görünüyor. Çoğaltmayı değiştirmek önemsiz bir iştir, aksi takdirde kendi kendine geçiş yapar. DNS'de alan adının yeniden yazılması da aynı seridendir. Sorun şu ki, böyle bir proje başarısız olduğunda panik başlar ve en güçlü, sakallı yöneticiler bile buna duyarlı olabilir. Açık talimatlar olmadan, “terminali açın, buraya gelin, sunucumuzun adresi hala böyle”, canlandırma için ayrılan 5 dakikalık süre sınırını karşılamak zordur. Artı, bu düzenlemeleri kullandığımızda örneğin altyapıdaki bazı değişiklikleri kayıt altına almak ve buna göre düzenlemeleri değiştirmek çok kolay.
Rezervasyon sistemi çok karmaşıksa ve bir noktada bir hata yaptıysak, yedekleme sitemizi yok edebiliriz ve ayrıca her iki sitedeki verileri de balkabağına dönüştürebiliriz - bu tamamen üzücü olacaktır.
Beş numaralı örnek, tam hardcore
Dünya çapında yüz milyonlarca kullanıcısı olan uluslararası bir hizmet. Tüm zaman dilimleri var, maksimum hızda yüksek yük, hiç uzanamazsınız. Bir dakika - ve üzücü olacak. Ne yapalım? Tüm programa göre tekrar rezervasyon yapın. Önceki örnekte bahsettiğim her şeyi ve biraz daha fazlasını yaptık. İdeal bir dünya ve altyapımız IaaC devops'un tüm konseptlerine uygundur. Yani her şey git'te ve siz sadece düğmeye basıyorsunuz.
Ne eksik? Bir - egzersizler. Onlar olmadan imkansızdır. Görünüşe göre bizde her şey mükemmel, genel olarak her şey kontrolümüz altında. Düğmeye basıyoruz, her şey oluyor. Öyle olsa bile -ki bu şekilde olmayacağını anlıyoruz- sistemimiz diğer bazı sistemlerle etkileşim halindedir. Örneğin, bu rota 53'ten gelen DNS, s3 depolama alanı, bazı API'lerle entegrasyon. Bu spekülatif deneyde her şeyi öngöremeyeceğiz. Ve anahtarı gerçekten çekene kadar çalışıp çalışmayacağını bilemeyeceğiz.
Muhtemelen hepsi bu. Tembel olmayın veya aşırıya kaçmayın. Ve çalışma süresi yanınızda olsun!
Kaynak: habr.com