Odnoklassniki adalah pengguna Apache Cassandra terbesar di RuNet dan salah satu yang terbesar di dunia. Kami mulai menggunakan Cassandra pada tahun 2010 untuk menyimpan peringkat foto, dan sekarang Cassandra mengelola data berukuran petabyte di ribuan node, bahkan kami mengembangkannya sendiri .
Pada tanggal 12 September di kantor kami di St. Petersburg, kami akan mengadakannya . Pembicara utama acara ini adalah chief engineer Odnoklassniki Oleg Anastasyev. Oleg adalah pakar di bidang sistem terdistribusi dan toleransi kesalahan; dia telah bekerja dengan Cassandra selama lebih dari 10 tahun dan berulang kali .
Menjelang pertemuan, kami berbicara dengan Oleg tentang toleransi kesalahan sistem terdistribusi dengan Cassandra, menanyakan apa yang akan dia bicarakan pada pertemuan tersebut dan mengapa acara ini layak dihadiri.
Oleg memulai karir pemrogramannya pada tahun 1995. Dia mengembangkan perangkat lunak di bidang perbankan, telekomunikasi, dan transportasi. Dia telah bekerja sebagai pengembang terkemuka di Odnoklassniki sejak 2007 di tim platform. Tanggung jawabnya mencakup pengembangan arsitektur dan solusi untuk sistem beban tinggi, gudang data besar, dan memecahkan masalah kinerja dan keandalan portal. Dia juga melatih pengembang di dalam perusahaan.
- Oleg, halo! Pada bulan Mei terjadi , didedikasikan untuk Apache Cassandra, para peserta mengatakan bahwa diskusi berlangsung hingga larut malam, tolong beri tahu saya, apa kesan Anda pada pertemuan pertama?
Pengembang dengan latar belakang berbeda dari perusahaan berbeda datang dengan penderitaan mereka sendiri, solusi tak terduga terhadap masalah, dan kisah luar biasa. Kami berhasil menyelenggarakan sebagian besar pertemuan dalam format diskusi, namun banyaknya diskusi sehingga kami hanya mampu menyentuh sepertiga topik yang direncanakan. Kami menaruh banyak perhatian pada bagaimana dan apa yang kami pantau menggunakan contoh layanan produksi nyata kami.
Saya tertarik dan sangat menyukainya.
- Dilihat dari pengumumannya, akan sepenuhnya dikhususkan untuk toleransi kesalahan, mengapa Anda memilih topik ini?
Cassandra adalah sistem terdistribusi sibuk yang khas dengan sejumlah besar fungsi selain melayani permintaan pengguna secara langsung: gosip, deteksi kegagalan, penyebaran perubahan skema, perluasan/pengurangan cluster, anti-entropi, pencadangan dan pemulihan, dll. Seperti halnya sistem terdistribusi, seiring bertambahnya jumlah perangkat keras, kemungkinan kegagalan meningkat, sehingga pengoperasian kluster produksi Cassandra memerlukan pemahaman mendalam tentang strukturnya untuk memprediksi perilaku jika terjadi kegagalan dan tindakan operator. Setelah menggunakan Cassandra selama bertahun-tahun, kami , yang siap kami bagikan, dan kami juga ingin mendiskusikan bagaimana rekan-rekan di toko memecahkan masalah yang umum terjadi.
β Kalau bicara Cassandra, apa yang Anda maksud dengan toleransi kesalahan?
Yang pertama, tentu saja, adalah kemampuan sistem untuk bertahan dari kegagalan perangkat keras yang umum terjadi: hilangnya mesin, disk, atau konektivitas jaringan dengan node/pusat data. Namun topiknya sendiri jauh lebih luas dan khususnya mencakup pemulihan dari kegagalan, termasuk kegagalan yang jarang dihadapi orang, misalnya kesalahan operator.
β Bisakah Anda memberikan contoh cluster data yang paling banyak dimuat dan terbesar?
Salah satu klaster terbesar kami adalah klaster hadiah: lebih dari 200 node dan ratusan TB data. Tapi ini bukan yang paling banyak dimuat, karena ditutupi oleh cache terdistribusi. Cluster tersibuk kami menangani puluhan ribu RPS untuk menulis dan ribuan RPS untuk membaca.
- Wow! Seberapa sering sesuatu rusak?
! Secara total, kami memiliki lebih dari 6 ribu server, dan setiap minggu beberapa server dan beberapa lusin disk diganti (tidak termasuk proses paralel peningkatan dan perluasan armada mesin). Untuk setiap jenis kegagalan, terdapat instruksi yang jelas tentang apa yang harus dilakukan dan dalam urutan apa, semuanya diotomatiskan jika memungkinkan, sehingga kegagalan bersifat rutin dan dalam 99% kasus terjadi tanpa disadari oleh pengguna.
β Bagaimana cara Anda menghadapi penolakan seperti itu?
Sejak awal pengoperasian Cassandra dan insiden pertama, kami mengerjakan mekanisme pencadangan dan pemulihan darinya, membangun prosedur penerapan yang mempertimbangkan keadaan cluster Cassandra dan, misalnya, tidak mengizinkan node untuk dimulai ulang jika kehilangan data mungkin terjadi. Kami berencana untuk membicarakan semua ini di pertemuan tersebut.
β Seperti yang Anda katakan, tidak ada sistem yang benar-benar dapat diandalkan. Jenis kegagalan apa yang Anda persiapkan dan mampu atasi?
Jika kita berbicara tentang instalasi cluster Cassandra, pengguna tidak akan menyadari apa pun jika kita kehilangan beberapa mesin dalam satu DC atau satu DC keseluruhan (ini telah terjadi). Dengan bertambahnya jumlah DC, kami berpikir untuk mulai memastikan pengoperasian jika terjadi kegagalan pada dua DC.
β Menurut Anda apa kekurangan Cassandra dalam hal toleransi kesalahan?
Cassandra, seperti banyak toko NoSQL awal lainnya, memerlukan pemahaman mendalam tentang struktur internalnya dan proses dinamis yang terjadi. Menurut saya, hal ini tidak memiliki kesederhanaan, prediktabilitas, dan observasi. Namun akan menarik untuk mendengar pendapat peserta rapat lainnya!
Oleg, terima kasih banyak telah meluangkan waktu untuk menjawab pertanyaan!
Kami menunggu semua orang yang ingin berkomunikasi dengan para ahli di bidang pengoperasian Apache Cassandra pada pertemuan tanggal 12 September di kantor kami di St. Petersburg.
Ayo, ini akan menarik!
Sumber: www.habr.com