Odnoklassniki, RuNet'teki en büyük Apache Cassandra kullanıcısıdır ve dünyadaki en büyüklerden biridir. Cassandra'yı 2010 yılında fotoğraf derecelendirmelerini depolamak için kullanmaya başladık ve şimdi Cassandra binlerce düğümdeki petabaytlarca veriyi yönetiyor; hatta kendi verimizi bile geliştirdik .
12 Eylül'de St. Petersburg ofisimizde gerçekleştireceğiz . Etkinliğin ana konuşmacısı Odnoklassniki'nin baş mühendisi Oleg Anastasyev olacak. Oleg, dağıtılmış ve hataya dayanıklı sistemler alanında uzmandır; Cassandra ile 10 yılı aşkın süredir ve defalarca çalışmaktadır. .
Buluşmanın arifesinde Cassandra ile Oleg ile dağıtık sistemlerin hata toleransı hakkında konuştuk, buluşmada ne konuşacağını ve neden bu etkinliğe katılmaya değer olduğunu sorduk.
Oleg programlama kariyerine 1995 yılında başladı. Bankacılık, telekom ve ulaştırma alanlarında yazılım geliştirdi. 2007'den beri Odnoklassniki'de platform ekibinde lider geliştirici olarak çalışıyor. Sorumlulukları arasında yüksek yüklü sistemler ve büyük veri ambarları için mimariler ve çözümler geliştirmek ve portal performansı ve güvenilirliğiyle ilgili sorunları çözmek yer alıyor. Ayrıca şirket içindeki geliştiricilere de eğitim veriyor.
- Oleg, merhaba! Mayıs ayında gerçekleşti Apache Cassandra'ya ithaf edilen etkinlikte katılımcılar tartışmaların gece geç saatlere kadar sürdüğünü söylüyorlar, lütfen söyleyin bana, ilk buluşmaya ilişkin izlenimleriniz neler?
Farklı şirketlerden farklı geçmişlere sahip geliştiriciler, kendi acılarıyla, sorunlara beklenmedik çözümlerle ve harika hikayelerle geldiler. Buluşmanın büyük bir kısmını tartışma formatında yürütmeyi başardık ama o kadar çok tartışma vardı ki planlanan konuların ancak üçte birine değinebildik. Gerçek üretim hizmetlerimiz örneğini kullanarak nasıl ve neyi takip ettiğimize çok dikkat ettik.
İlgimi çekti ve gerçekten beğendim.
- Duyuruya bakılırsa, Tamamen hata toleransına ayrılacak, neden bu konuyu seçtiniz?
Cassandra, kullanıcı isteklerine doğrudan hizmet vermenin ötesinde çok büyük miktarda işlevselliğe sahip, tipik, meşgul, dağıtılmış bir sistemdir: dedikodu, arıza tespiti, şema değişikliklerinin yayılması, küme genişletme/küçültme, anti-entropi, yedekleme ve kurtarma vb. Herhangi bir dağıtılmış sistemde olduğu gibi, donanım miktarı arttıkça arıza olasılığı da artar, bu nedenle Cassandra üretim kümelerinin çalışması, arıza durumunda davranışı ve operatör eylemlerini tahmin etmek için yapısının derinlemesine anlaşılmasını gerektirir. Cassandra'yı uzun yıllar kullandıktan sonra Bunu paylaşmaya hazırız ve ayrıca mağazadaki meslektaşlarımızın tipik sorunları nasıl çözdüğünü tartışmak istiyoruz.
— Konu Cassandra'ya gelince, hata toleransından neyi kastediyorsunuz?
Her şeyden önce, elbette sistemin tipik donanım arızalarından kurtulma yeteneği: makinelerin, disklerin veya düğümler/veri merkezleriyle ağ bağlantısının kaybı. Ancak konunun kendisi çok daha geniştir ve özellikle, operatör hataları gibi insanların nadiren hazırlıklı olduğu arızalar da dahil olmak üzere, arızalardan kurtulmayı içerir.
— En çok yüklenen ve en büyük veri kümesine örnek verebilir misiniz?
En büyük kümelerimizden biri hediye kümesidir: 200'den fazla düğüm ve yüzlerce TB veri. Ancak dağıtılmış bir önbellek tarafından kapsandığı için en çok yüklü olanıdır. En yoğun kümelerimiz yazma için on binlerce RPS'yi ve okuma için binlerce RPS'yi yönetir.
- Vay! Bir şey ne sıklıkla kırılır?
! Toplamda 6 binden fazla sunucumuz var ve her hafta birkaç sunucu ve birkaç düzine disk değiştiriliyor (makine filosunun paralel yükseltme ve genişletme süreçleri dikkate alınmadan). Her arıza türü için ne yapılacağına ve hangi sırayla yapılacağına dair açık talimatlar vardır; her şey mümkün olduğunda otomatikleştirilir, dolayısıyla arızalar rutindir ve vakaların %99'u kullanıcılar tarafından fark edilmeden meydana gelir.
— Bu tür reddedilmelerle nasıl başa çıkıyorsunuz?
Cassandra'nın çalışmasının en başından ve ilk olaylardan itibaren, yedekleme ve kurtarma mekanizmaları üzerinde çalıştık, Cassandra kümelerinin durumunu dikkate alan ve örneğin düğümlerin yeniden başlatılmasına izin vermeyen dağıtım prosedürleri oluşturduk. veri kaybı mümkünse. Bütün bunları buluşmada konuşmayı planlıyoruz.
— Dediğiniz gibi kesinlikle güvenilir bir sistem yok. Ne tür başarısızlıklara hazırlanıyorsunuz ve hayatta kalabiliyorsunuz?
Cassandra kümelerinin kurulumlarından bahsedersek, bir DC'de veya bir DC'nin tamamında birkaç makineyi kaybedersek (bu oldu) kullanıcılar hiçbir şey fark etmeyeceklerdir. DC sayısının artmasıyla birlikte iki DC'nin arızalanması durumunda çalışabilirliği sağlamaya başlamayı düşünüyoruz.
— Sizce Cassandra'nın hata toleransı açısından neyi eksik?
Cassandra, diğer birçok eski NoSQL mağazası gibi, iç yapısının ve meydana gelen dinamik süreçlerin derinlemesine anlaşılmasını gerektirir. Basitlik, öngörülebilirlik ve gözlemlenebilirlikten yoksun olduğunu söyleyebilirim. Ancak diğer toplantı katılımcılarının görüşlerini duymak ilginç olacak!
Oleg, soruları yanıtlamaya zaman ayırdığınız için çok teşekkür ederim!
Apache Cassandra'nın işletimi alanında uzman kişilerle iletişim kurmak isteyen herkesi 12 Eylül'de St. Petersburg ofisimize bekliyoruz.
Gelin, ilginç olacak!
Kaynak: habr.com