Odnoklassniki เป็นผู้ใช้ Apache Cassandra รายใหญ่ที่สุดบน RuNet และเป็นหนึ่งในผู้ใช้รายใหญ่ที่สุดในโลก เราเริ่มใช้ Cassandra ในปี 2010 เพื่อจัดเก็บการให้คะแนนภาพถ่าย และตอนนี้ Cassandra จัดการข้อมูลระดับเพตะไบต์บนโหนดนับพัน ที่จริงแล้ว เรายังพัฒนาของเราเองด้วยซ้ำ .
เราจะจัดขึ้นที่สำนักงานเซนต์ปีเตอร์สเบิร์กในวันที่ 12 กันยายน . วิทยากรหลักของงานจะเป็นหัวหน้าวิศวกรของ Odnoklassniki Oleg Anastasyev Oleg เป็นผู้เชี่ยวชาญในด้านระบบแบบกระจายและทนทานต่อข้อผิดพลาด เขาทำงานร่วมกับ Cassandra มามากกว่า 10 ปีและซ้ำแล้วซ้ำอีก .
ก่อนมีตติ้ง เราได้พูดคุยกับ Oleg เกี่ยวกับความทนทานต่อข้อผิดพลาดของระบบแบบกระจายกับ Cassandra ถามเขาจะพูดถึงอะไรในงานมีตติ้ง และเหตุใดจึงคุ้มค่าที่จะเข้าร่วมกิจกรรมนี้
Oleg เริ่มอาชีพการเขียนโปรแกรมในปี 1995 เขาพัฒนาซอฟต์แวร์ด้านการธนาคาร โทรคมนาคม และการขนส่ง เขาทำงานเป็นนักพัฒนาชั้นนำที่ Odnoklassniki มาตั้งแต่ปี 2007 ในทีมแพลตฟอร์ม ความรับผิดชอบของเขาประกอบด้วยการพัฒนาสถาปัตยกรรมและโซลูชันสำหรับระบบที่มีโหลดสูง คลังข้อมูลขนาดใหญ่ และการแก้ปัญหาประสิทธิภาพและความน่าเชื่อถือของพอร์ทัล เขายังฝึกอบรมนักพัฒนาภายในบริษัทอีกด้วย
- โอเล็กสวัสดี! ในเดือนพฤษภาคมเกิดขึ้น ซึ่งอุทิศให้กับ Apache Cassandra ผู้เข้าร่วมกล่าวว่าการสนทนาดำเนินไปจนดึกดื่น โปรดบอกฉันว่าคุณรู้สึกอย่างไรกับการพบปะครั้งแรก
นักพัฒนาที่มีภูมิหลังที่แตกต่างกันจากบริษัทต่างๆ มาพร้อมกับความเจ็บปวดของตัวเอง วิธีแก้ปัญหาที่ไม่คาดคิด และเรื่องราวที่น่าทึ่ง เราจัดการพบปะส่วนใหญ่ในรูปแบบการสนทนา แต่มีการสนทนามากมายจนเราสามารถพูดถึงหัวข้อที่วางแผนไว้ได้เพียงหนึ่งในสามเท่านั้น เราให้ความสนใจอย่างมากเกี่ยวกับวิธีการและสิ่งที่เราตรวจสอบโดยใช้ตัวอย่างของบริการการผลิตจริงของเรา
ฉันสนใจและชอบมันมาก
- ตัดสินตามประกาศ จะทุ่มเทอย่างเต็มที่เพื่อความทนทานต่อข้อผิดพลาด ทำไมคุณถึงเลือกหัวข้อนี้
Cassandra เป็นระบบกระจายข้อมูลที่ไม่ว่างทั่วไปซึ่งมีฟังก์ชันการทำงานมากมายนอกเหนือจากการให้บริการคำขอของผู้ใช้โดยตรง เช่น การนินทา การตรวจจับความล้มเหลว การเผยแพร่การเปลี่ยนแปลงสคีมา การขยาย/การลดขนาดของคลัสเตอร์ การต่อต้านเอนโทรปี การสำรองข้อมูลและการกู้คืน ฯลฯ เช่นเดียวกับในระบบแบบกระจายอื่นๆ เมื่อปริมาณฮาร์ดแวร์เพิ่มขึ้น โอกาสที่จะเกิดความล้มเหลวก็เพิ่มขึ้น ดังนั้นการดำเนินงานของคลัสเตอร์การผลิต Cassandra จึงจำเป็นต้องมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับโครงสร้างของฮาร์ดแวร์เพื่อคาดการณ์พฤติกรรมในกรณีที่เกิดความล้มเหลวและการดำเนินการของผู้ปฏิบัติงาน หลังจากใช้ Cassandra มาหลายปีแล้ว ซึ่งเราพร้อมจะแบ่งปันและเรายังต้องการหารือเกี่ยวกับวิธีที่เพื่อนร่วมงานในร้านแก้ไขปัญหาทั่วไปด้วย
— เมื่อพูดถึงคาสซานดรา คุณหมายถึงอะไรในเรื่องการอดทนต่อข้อผิดพลาด?
ประการแรก ความสามารถของระบบในการเอาตัวรอดจากความล้มเหลวของฮาร์ดแวร์ทั่วไป: การสูญเสียเครื่อง ดิสก์ หรือการเชื่อมต่อเครือข่ายกับโหนด/ศูนย์ข้อมูล แต่หัวข้อนั้นกว้างกว่ามากและโดยเฉพาะอย่างยิ่งรวมถึงการกู้คืนจากความล้มเหลว รวมถึงความล้มเหลวที่บุคคลไม่ค่อยได้เตรียมตัวไว้ เช่น ข้อผิดพลาดของผู้ปฏิบัติงาน
— คุณช่วยยกตัวอย่างคลัสเตอร์ข้อมูลที่โหลดมากที่สุดและใหญ่ที่สุดได้ไหม
หนึ่งในคลัสเตอร์ที่ใหญ่ที่สุดของเราคือคลัสเตอร์ของขวัญ ซึ่งมีมากกว่า 200 โหนดและข้อมูลหลายร้อย TB แต่ไม่ใช่โหลดมากที่สุดเนื่องจากมีแคชแบบกระจายปกคลุมอยู่ คลัสเตอร์ที่ยุ่งที่สุดของเรารองรับ RPS นับหมื่นสำหรับการเขียน และ RPS หลายพันสำหรับการอ่าน
- ว้าว! บางสิ่งพังบ่อยแค่ไหน?
! โดยรวมแล้ว เรามีเซิร์ฟเวอร์มากกว่า 6 เครื่อง และทุกสัปดาห์จะมีการเปลี่ยนเซิร์ฟเวอร์สองสามเครื่องและดิสก์หลายสิบเครื่อง (โดยไม่คำนึงถึงกระบวนการอัพเกรดและการขยายกลุ่มเครื่องจักรแบบขนาน) สำหรับความล้มเหลวแต่ละประเภท มีคำแนะนำที่ชัดเจนว่าต้องทำอะไรและเรียงลำดับอะไร ทุกอย่างจะเป็นอัตโนมัติทุกครั้งที่เป็นไปได้ ดังนั้นความล้มเหลวจึงเกิดขึ้นเป็นประจำและใน 99% ของกรณีเกิดขึ้นโดยที่ผู้ใช้ไม่มีใครสังเกตเห็น
— คุณจะจัดการกับการปฏิเสธดังกล่าวอย่างไร?
จากจุดเริ่มต้นของการทำงานของ Cassandra และเหตุการณ์แรกๆ เราได้ทำงานเกี่ยวกับกลไกสำหรับการสำรองข้อมูลและการกู้คืนจากสิ่งเหล่านั้น สร้างขั้นตอนการปรับใช้ที่คำนึงถึงสถานะของคลัสเตอร์ Cassandra และตัวอย่างเช่น ไม่อนุญาตให้รีสตาร์ทโหนด หากข้อมูลสูญหายได้ เราวางแผนที่จะพูดคุยเกี่ยวกับทั้งหมดนี้ในงานมีตติ้ง
— อย่างที่คุณพูด ไม่มีระบบที่เชื่อถือได้อย่างแน่นอน ความล้มเหลวประเภทใดที่คุณเตรียมไว้และสามารถจัดการได้?
หากเราพูดถึงการติดตั้งคลัสเตอร์ Cassandra ผู้ใช้จะไม่สังเกตเห็นสิ่งใดเลยหากเราสูญเสียเครื่องหลายเครื่องใน DC เดียวหรือ DC ทั้งหมดตัวเดียว (สิ่งนี้เกิดขึ้น) ด้วยจำนวน DC ที่เพิ่มขึ้น เรากำลังคิดถึงการเริ่มต้นเพื่อให้มั่นใจถึงความสามารถในการทำงานในกรณีที่ DC สองตัวขัดข้อง
— คุณคิดว่าแคสแซนดราขาดอะไรในแง่ของการทนทานต่อข้อผิดพลาด?
Cassandra ก็เหมือนกับร้านค้า NoSQL ยุคแรกๆ อื่นๆ ที่ต้องการความเข้าใจอย่างลึกซึ้งเกี่ยวกับโครงสร้างภายในและกระบวนการแบบไดนามิกที่เกิดขึ้น ฉันจะบอกว่ามันขาดความเรียบง่าย คาดเดาได้ และสังเกตได้ แต่การฟังความคิดเห็นของผู้เข้าร่วมประชุมคนอื่นจะน่าสนใจ!
Oleg ขอบคุณมากที่สละเวลาตอบคำถาม!
เรากำลังรอทุกคนที่ต้องการสื่อสารกับผู้เชี่ยวชาญในสาขาปฏิบัติการ Apache Cassandra ในงานมีตติ้งวันที่ 12 กันยายนที่สำนักงานในเซนต์ปีเตอร์สเบิร์กของเรา
มาเถอะจะน่าสนใจ!
ที่มา: will.com