วิธีการทำงานของการค้นหา Yandex.Market และจะเกิดอะไรขึ้นหากเซิร์ฟเวอร์ตัวใดตัวหนึ่งล้มเหลว

สวัสดี ฉันชื่อเยฟเจนีย์ ฉันทำงานในโครงสร้างพื้นฐานการค้นหาของ Yandex.Market ฉันอยากจะบอกชุมชน Habr เกี่ยวกับครัวด้านในของตลาด - และฉันก็มีหลายเรื่องจะเล่าให้ฟัง ประการแรก วิธีการทำงานของการค้นหาตลาด กระบวนการ และสถาปัตยกรรม เราจะจัดการกับสถานการณ์ฉุกเฉินอย่างไร: จะเกิดอะไรขึ้นหากเซิร์ฟเวอร์ตัวหนึ่งล่ม? จะเกิดอะไรขึ้นถ้ามีเซิร์ฟเวอร์ดังกล่าว 100 แห่ง?

คุณยังจะได้เรียนรู้วิธีที่เราปรับใช้ฟังก์ชันใหม่บนเซิร์ฟเวอร์จำนวนมากพร้อมกัน และวิธีที่เราทดสอบบริการที่ซับซ้อนโดยตรงในการผลิต โดยไม่ก่อให้เกิดความไม่สะดวกแก่ผู้ใช้ โดยทั่วไปแล้ว การค้นหาในตลาดทำงานอย่างไรเพื่อให้ทุกคนมีช่วงเวลาที่ดี

เกร็ดเล็กๆ น้อยๆ เกี่ยวกับเรา: เราแก้ปัญหาอะไร

เมื่อคุณป้อนข้อความ ค้นหาผลิตภัณฑ์ตามพารามิเตอร์ หรือเปรียบเทียบราคาในร้านค้าต่างๆ คำขอทั้งหมดจะถูกส่งไปยังบริการค้นหา การค้นหาเป็นบริการที่ใหญ่ที่สุดในตลาด

เราดำเนินการตามคำขอค้นหาทั้งหมด: จากเว็บไซต์ market.yandex.ru, beru.ru, บริการ Supercheck, Yandex.Advisor, แอปพลิเคชันมือถือ นอกจากนี้เรายังรวมข้อเสนอผลิตภัณฑ์ไว้ในผลการค้นหาบน yandex.ru

โดยบริการค้นหา ฉันหมายถึงไม่เพียงแต่การค้นหาเท่านั้น แต่ยังรวมถึงฐานข้อมูลที่มีข้อเสนอทั้งหมดในตลาดด้วย มาตราส่วนคือ: มีการประมวลผลคำขอค้นหามากกว่าพันล้านคำขอต่อวัน และทุกอย่างควรทำงานได้อย่างรวดเร็ว ไม่มีการหยุดชะงักและให้ผลลัพธ์ตามที่ต้องการเสมอ

คืออะไร: สถาปัตยกรรมตลาด

ฉันจะอธิบายโดยย่อเกี่ยวกับสถาปัตยกรรมปัจจุบันของตลาด สามารถอธิบายคร่าวๆ ได้ด้วยแผนภาพด้านล่าง:

สมมติว่ามีร้านค้าพันธมิตรมาหาเรา เขาบอกว่าฉันต้องการขายของเล่น: แมวตัวร้ายตัวนี้มีเสียงแหลม และแมวขี้โมโหอีกตัวที่ไม่มีเสียงแหลม และเป็นเพียงแมว จากนั้นร้านค้าจะต้องเตรียมข้อเสนอที่ตลาดค้นหา ร้านค้าสร้าง xml พิเศษพร้อมข้อเสนอและสื่อสารเส้นทางไปยัง xml นี้ผ่านอินเทอร์เฟซพันธมิตร จากนั้นตัวสร้างดัชนีจะดาวน์โหลด xml นี้เป็นระยะ ตรวจสอบข้อผิดพลาด และบันทึกข้อมูลทั้งหมดลงในฐานข้อมูลขนาดใหญ่

มี xml ที่บันทึกไว้มากมาย ดัชนีการค้นหาถูกสร้างขึ้นจากฐานข้อมูลนี้ ดัชนีจะถูกจัดเก็บในรูปแบบภายใน หลังจากสร้างดัชนีแล้ว บริการเค้าโครงจะอัปโหลดไปยังเซิร์ฟเวอร์การค้นหา

เป็นผลให้แมวโกรธพร้อมเสียงแหลมปรากฏขึ้นในฐานข้อมูล และดัชนีของแมวปรากฏบนเซิร์ฟเวอร์

ฉันจะบอกคุณว่าเราค้นหาแมวอย่างไรในส่วนเกี่ยวกับสถาปัตยกรรมการค้นหา

สถาปัตยกรรมการค้นหาตลาด

เราอยู่ในโลกแห่งไมโครเซอร์วิส: ทุกคำขอที่เข้ามา ตลาด.yandex.ru ทำให้เกิดการสืบค้นย่อยจำนวนมาก และบริการหลายสิบรายการเกี่ยวข้องกับการประมวลผล แผนภาพแสดงเพียงบางส่วนเท่านั้น:

รูปแบบการประมวลผลคำขอแบบง่าย

แต่ละบริการมีสิ่งที่ยอดเยี่ยม - บาลานเซอร์ของตัวเองพร้อมชื่อที่ไม่ซ้ำใคร:

บาลานเซอร์ช่วยให้เราจัดการบริการได้อย่างยืดหยุ่นมากขึ้น เช่น คุณสามารถปิดเซิร์ฟเวอร์ ซึ่งมักจำเป็นสำหรับการอัปเดต เป็นต้น บาลานเซอร์จะเห็นว่าเซิร์ฟเวอร์ไม่พร้อมใช้งานและเปลี่ยนเส้นทางคำขอไปยังเซิร์ฟเวอร์หรือศูนย์ข้อมูลอื่นโดยอัตโนมัติ เมื่อเพิ่มหรือลบเซิร์ฟเวอร์ โหลดจะถูกกระจายระหว่างเซิร์ฟเวอร์โดยอัตโนมัติ

ชื่อเฉพาะของบาลานเซอร์ไม่ได้ขึ้นอยู่กับศูนย์ข้อมูล เมื่อบริการ A ทำการร้องขอไปยัง B ดังนั้นตามค่าเริ่มต้น บาลานเซอร์ B จะเปลี่ยนเส้นทางคำขอไปยังศูนย์ข้อมูลปัจจุบัน หากบริการไม่พร้อมใช้งานหรือไม่อยู่ในศูนย์ข้อมูลปัจจุบัน คำขอจะถูกเปลี่ยนเส้นทางไปยังศูนย์ข้อมูลอื่น

FQDN เดียวสำหรับศูนย์ข้อมูลทั้งหมดช่วยให้บริการ A สามารถสรุปข้อมูลจากสถานที่ต่างๆ ได้อย่างสมบูรณ์ คำขอของเขาในการให้บริการ B จะได้รับการดำเนินการเสมอ ข้อยกเว้นคือกรณีที่บริการอยู่ในศูนย์ข้อมูลทั้งหมด

แต่ไม่ใช่ทุกสิ่งที่จะเป็นสีดอกกุหลาบด้วยเครื่องถ่วงดุลนี้: เรามีส่วนประกอบระดับกลางเพิ่มเติม บาลานเซอร์อาจไม่เสถียร และปัญหานี้แก้ไขได้ด้วยเซิร์ฟเวอร์ที่ซ้ำซ้อน นอกจากนี้ยังมีความล่าช้าเพิ่มเติมระหว่างบริการ A และ B แต่ในทางปฏิบัติจะน้อยกว่า 1 ms และสำหรับบริการส่วนใหญ่ก็ไม่สำคัญ

การจัดการกับสิ่งที่ไม่คาดคิด: ความสมดุลและความยืดหยุ่นของบริการค้นหา

ลองนึกภาพว่ามีการล่มสลาย: คุณต้องหาแมวที่มีเสียงดัง แต่เซิร์ฟเวอร์ล่ม หรือ 100 เซิร์ฟเวอร์ จะออกไปได้อย่างไร? เราจะทิ้งผู้ใช้ไว้โดยไม่มีแมวจริงหรือ?

สถานการณ์น่ากลัวแต่เราก็พร้อมรับมือ ฉันจะบอกคุณตามลำดับ

โครงสร้างพื้นฐานการค้นหาตั้งอยู่ในศูนย์ข้อมูลหลายแห่ง:

เมื่อออกแบบ เราได้รวมความเป็นไปได้ในการปิดศูนย์ข้อมูลแห่งเดียว ชีวิตเต็มไปด้วยเรื่องน่าประหลาดใจ ตัวอย่างเช่น รถขุดสามารถตัดสายเคเบิลใต้ดินได้ (ใช่แล้ว เกิดขึ้นแล้ว) ความจุในศูนย์ข้อมูลที่เหลือควรจะเพียงพอต่อการรับภาระงานสูงสุด

ลองพิจารณาศูนย์ข้อมูลเดียว ศูนย์ข้อมูลแต่ละแห่งมีรูปแบบการทำงานของบาลานเซอร์เหมือนกัน:

บาลานเซอร์หนึ่งตัวคือเซิร์ฟเวอร์จริงอย่างน้อยสามเซิร์ฟเวอร์ ความซ้ำซ้อนนี้จัดทำขึ้นเพื่อความน่าเชื่อถือ บาลานเซอร์ทำงานบน HAProx

เราเลือก HAProx เนื่องจากมีประสิทธิภาพสูง ต้องการทรัพยากรต่ำ และฟังก์ชันการทำงานที่หลากหลาย ซอฟต์แวร์ค้นหาของเราทำงานภายในแต่ละเซิร์ฟเวอร์

โอกาสที่เซิร์ฟเวอร์หนึ่งตัวจะล้มเหลวมีน้อย แต่ถ้าคุณมีเซิร์ฟเวอร์จำนวนมาก โอกาสที่อย่างน้อยหนึ่งเซิร์ฟเวอร์จะล่มก็จะเพิ่มขึ้น

นี่คือสิ่งที่เกิดขึ้นในความเป็นจริง: เซิร์ฟเวอร์ขัดข้อง ดังนั้นจึงจำเป็นต้องตรวจสอบสถานะของเซิร์ฟเวอร์ทั้งหมดอย่างต่อเนื่อง หากเซิร์ฟเวอร์หยุดตอบสนอง เซิร์ฟเวอร์จะตัดการเชื่อมต่อจากการรับส่งข้อมูลโดยอัตโนมัติ เพื่อจุดประสงค์นี้ HAProxy จึงมีการตรวจสุขภาพในตัว ไปยังเซิร์ฟเวอร์ทั้งหมดต่อวินาทีด้วยคำขอ HTTP “/ping”

คุณสมบัติอื่นของ HAProxy: การตรวจสอบตัวแทนช่วยให้คุณโหลดเซิร์ฟเวอร์ทั้งหมดเท่าๆ กัน ในการดำเนินการนี้ HAProxy จะเชื่อมต่อกับเซิร์ฟเวอร์ทั้งหมด และส่งคืนน้ำหนักโดยขึ้นอยู่กับโหลดปัจจุบันตั้งแต่ 1 ถึง 100 น้ำหนักจะคำนวณตามจำนวนคำขอในคิวสำหรับการประมวลผลและโหลดบนโปรเซสเซอร์

ตอนนี้เกี่ยวกับการหาแมว ผลการค้นหาในคำขอเช่น: /search?text=angry+cat. เพื่อให้การค้นหารวดเร็ว ดัชนี cat ทั้งหมดจะต้องพอดีกับ RAM แม้แต่การอ่านจาก SSD ก็ยังไม่เร็วพอ

กาลครั้งหนึ่ง ฐานข้อมูลข้อเสนอมีขนาดเล็ก และ RAM ของเซิร์ฟเวอร์เดียวก็เพียงพอแล้ว เมื่อฐานข้อเสนอเพิ่มขึ้น ทุกอย่างไม่พอดีกับ RAM นี้อีกต่อไป และข้อมูลถูกแบ่งออกเป็นสองส่วน: ชาร์ด 1 และชาร์ด 2

แต่สิ่งนี้เกิดขึ้นเสมอ: วิธีแก้ปัญหาใด ๆ แม้แต่วิธีแก้ปัญหาที่ดีก็ก่อให้เกิดปัญหาอื่น ๆ

บาลานเซอร์ยังคงไปที่เซิร์ฟเวอร์ใดก็ได้ แต่บนเครื่องที่คำขอมานั้นมีเพียงครึ่งหนึ่งของดัชนีเท่านั้น ที่เหลือก็อยู่บนเซิร์ฟเวอร์อื่น ดังนั้นเซิร์ฟเวอร์จึงต้องไปที่เครื่องใกล้เคียง หลังจากได้รับข้อมูลจากเซิร์ฟเวอร์ทั้งสอง ผลลัพธ์จะถูกรวมและจัดอันดับใหม่

เนื่องจากบาลานเซอร์กระจายคำขออย่างเท่าเทียมกัน เซิร์ฟเวอร์ทั้งหมดจึงมีส่วนร่วมในการจัดอันดับใหม่ ไม่ใช่แค่ส่งข้อมูลเท่านั้น

ปัญหาเกิดขึ้นหากเซิร์ฟเวอร์ใกล้เคียงไม่พร้อมใช้งาน วิธีแก้ไขคือระบุเซิร์ฟเวอร์หลายเครื่องที่มีลำดับความสำคัญต่างกันเป็นเซิร์ฟเวอร์ "ใกล้เคียง" ขั้นแรก คำร้องขอจะถูกส่งไปยังเซิร์ฟเวอร์ในแร็คปัจจุบัน หากไม่มีการตอบสนอง คำขอจะถูกส่งไปยังเซิร์ฟเวอร์ทั้งหมดในศูนย์ข้อมูลนี้ และสุดท้าย คำขอถูกส่งไปยังศูนย์ข้อมูลอื่นๆ
เมื่อจำนวนข้อเสนอเพิ่มขึ้น ข้อมูลจึงถูกแบ่งออกเป็นสี่ส่วน แต่นี่ไม่ใช่ขีดจำกัด

ปัจจุบันมีการใช้การกำหนดค่าแปดส่วน นอกจากนี้ เพื่อประหยัดหน่วยความจำมากขึ้น ดัชนีจึงถูกแบ่งออกเป็นส่วนการค้นหา (ซึ่งใช้สำหรับการค้นหา) และส่วนตัวอย่าง (ซึ่งไม่เกี่ยวข้องกับการค้นหา)

เซิร์ฟเวอร์หนึ่งเครื่องมีข้อมูลสำหรับชาร์ดเดียวเท่านั้น ดังนั้น หากต้องการค้นหาดัชนีทั้งหมด คุณต้องค้นหาเซิร์ฟเวอร์แปดเซิร์ฟเวอร์ที่มีชาร์ดต่างกัน

เซิร์ฟเวอร์ถูกจัดกลุ่มเป็นคลัสเตอร์ แต่ละคลัสเตอร์ประกอบด้วยเครื่องมือค้นหาแปดรายการและเซิร์ฟเวอร์ตัวอย่างหนึ่งรายการ

เซิร์ฟเวอร์ตัวอย่างรันฐานข้อมูลคีย์-ค่าพร้อมข้อมูลคงที่ พวกเขาจำเป็นต้องออกเอกสารเช่นคำอธิบายของแมวที่มีเสียงดัง ข้อมูลจะถูกถ่ายโอนไปยังเซิร์ฟเวอร์แยกต่างหากเป็นพิเศษเพื่อไม่ให้โหลดหน่วยความจำของเซิร์ฟเวอร์การค้นหา

เนื่องจากรหัสเอกสารไม่ซ้ำกันภายในดัชนีเดียวเท่านั้น สถานการณ์จึงอาจเกิดขึ้นได้หากไม่มีเอกสารในตัวอย่างข้อมูล หรือสำหรับ ID เดียวนั้นจะมีเนื้อหาที่แตกต่างกัน ดังนั้น เพื่อให้การค้นหาทำงานได้และส่งคืนผลลัพธ์ จำเป็นต้องมีความสอดคล้องกันทั่วทั้งคลัสเตอร์ ฉันจะบอกคุณด้านล่างว่าเราตรวจสอบความสม่ำเสมออย่างไร

การค้นหามีโครงสร้างดังนี้: คำขอค้นหาสามารถมาที่เซิร์ฟเวอร์ใดก็ได้จากทั้งหมดแปดเซิร์ฟเวอร์ สมมติว่าเขามาที่เซิร์ฟเวอร์ 1 เซิร์ฟเวอร์นี้ประมวลผลอาร์กิวเมนต์ทั้งหมดและเข้าใจว่าจะค้นหาอะไรและอย่างไร เซิร์ฟเวอร์สามารถส่งคำขอเพิ่มเติมไปยังบริการภายนอกสำหรับข้อมูลที่จำเป็น ทั้งนี้ขึ้นอยู่กับคำขอที่เข้ามา หนึ่งคำขอสามารถติดตามได้ถึงสิบคำขอไปยังบริการภายนอก

หลังจากรวบรวมข้อมูลที่จำเป็นแล้ว การค้นหาจะเริ่มขึ้นในฐานข้อมูลข้อเสนอ เมื่อต้องการทำเช่นนี้ แบบสอบถามย่อยจะทำกับเซิร์ฟเวอร์ทั้งแปดในคลัสเตอร์

เมื่อได้รับคำตอบแล้ว ก็นำผลลัพธ์มารวมกัน ท้ายที่สุดแล้ว อาจจำเป็นต้องมีแบบสอบถามย่อยอีกหลายรายการไปยังเซิร์ฟเวอร์ตัวอย่างเพื่อสร้างผลลัพธ์

คำค้นหาภายในคลัสเตอร์มีลักษณะดังนี้: /shard1?text=angry+cat. นอกจากนี้ แบบสอบถามย่อยของแบบฟอร์มจะถูกสร้างอย่างต่อเนื่องระหว่างเซิร์ฟเวอร์ทั้งหมดภายในคลัสเตอร์ต่อวินาที: /สถานะ.

การสอบสวน /สถานะ ตรวจพบสถานการณ์ที่เซิร์ฟเวอร์ไม่พร้อมใช้งาน

นอกจากนี้ยังควบคุมว่าเวอร์ชันเครื่องมือค้นหาและเวอร์ชันดัชนีเหมือนกันบนเซิร์ฟเวอร์ทั้งหมด ไม่เช่นนั้นข้อมูลภายในคลัสเตอร์จะไม่สอดคล้องกัน

แม้ว่าเซิร์ฟเวอร์ตัวอย่างหนึ่งจะประมวลผลคำขอจากเสิร์ชเอ็นจิ้นแปดตัว แต่ตัวประมวลผลก็โหลดน้อยมาก ดังนั้น ขณะนี้เรากำลังถ่ายโอนข้อมูลตัวอย่างไปยังบริการแยกต่างหาก

ในการถ่ายโอนข้อมูล เราได้แนะนำคีย์สากลสำหรับเอกสาร ขณะนี้เป็นไปไม่ได้สำหรับสถานการณ์ที่เนื้อหาจากเอกสารอื่นถูกส่งคืนโดยใช้คีย์เดียว

แต่การเปลี่ยนไปใช้สถาปัตยกรรมอื่นยังไม่เสร็จสมบูรณ์ ตอนนี้เราต้องการกำจัดเซิร์ฟเวอร์ตัวอย่างเฉพาะ แล้วย้ายออกจากโครงสร้างคลัสเตอร์ไปพร้อมกัน ซึ่งจะช่วยให้เราขยายขนาดต่อไปได้อย่างง่ายดาย โบนัสเพิ่มเติมคือการประหยัดธาตุเหล็กอย่างมาก

และตอนนี้ก็มาถึงเรื่องราวที่น่ากลัวและตอนจบที่มีความสุข ลองพิจารณาหลายกรณีที่เซิร์ฟเวอร์ไม่พร้อมใช้งาน

มีบางอย่างเลวร้ายเกิดขึ้น: เซิร์ฟเวอร์หนึ่งเครื่องไม่พร้อมใช้งาน

สมมติว่ามีเซิร์ฟเวอร์หนึ่งเครื่องไม่พร้อมใช้งาน จากนั้นเซิร์ฟเวอร์ที่เหลือในคลัสเตอร์จะสามารถตอบสนองต่อไปได้ แต่ผลการค้นหาจะไม่สมบูรณ์

ผ่านการตรวจสอบสถานะ /สถานะ เซิร์ฟเวอร์ใกล้เคียงเข้าใจว่าเซิร์ฟเวอร์หนึ่งไม่พร้อมใช้งาน ดังนั้นเพื่อรักษาความสมบูรณ์เซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์ต่อคำขอ /ปิง พวกเขาเริ่มตอบสนองต่อบาลานเซอร์ว่าไม่พร้อมใช้งานเช่นกัน ปรากฎว่าเซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์หยุดทำงาน (ซึ่งไม่เป็นความจริง) นี่คือข้อเสียเปรียบหลักของแผนคลัสเตอร์ของเรา นั่นคือสาเหตุที่เราต้องการหลีกหนีจากคลัสเตอร์

คำขอที่ล้มเหลวโดยมีข้อผิดพลาดจะถูกส่งอีกครั้งโดยบาลานเซอร์บนเซิร์ฟเวอร์อื่น
บาลานเซอร์ยังหยุดส่งการรับส่งข้อมูลของผู้ใช้ไปยังเซิร์ฟเวอร์ที่ไม่ทำงาน แต่ยังคงตรวจสอบสถานะต่อไป

เมื่อเซิร์ฟเวอร์พร้อมใช้งาน ก็จะเริ่มตอบสนอง /ปิง. ทันทีที่การตอบสนองตามปกติต่อการส่ง Ping จากเซิร์ฟเวอร์ที่ไม่ทำงานเริ่มมาถึง ตัวปรับสมดุลจะเริ่มส่งการรับส่งข้อมูลของผู้ใช้ไปที่นั่น การดำเนินการของคลัสเตอร์ได้รับการกู้คืนแล้ว ไชโย

ที่แย่ไปกว่านั้น: เซิร์ฟเวอร์จำนวนมากไม่พร้อมใช้งาน

ส่วนสำคัญของเซิร์ฟเวอร์ในศูนย์ข้อมูลถูกตัดทอนลง จะทำอย่างไรวิ่งที่ไหน? บาลานเซอร์มาช่วยเหลืออีกครั้ง บาลานเซอร์แต่ละตัวจะจัดเก็บจำนวนเซิร์ฟเวอร์ที่ใช้งานอยู่ในปัจจุบันในหน่วยความจำอย่างต่อเนื่อง โดยจะคำนวณปริมาณการรับส่งข้อมูลสูงสุดที่ศูนย์ข้อมูลปัจจุบันสามารถประมวลผลได้อย่างต่อเนื่อง

เมื่อเซิร์ฟเวอร์จำนวนมากในศูนย์ข้อมูลล่ม บาลานเซอร์จะรู้ว่าศูนย์ข้อมูลนี้ไม่สามารถประมวลผลการรับส่งข้อมูลทั้งหมดได้

จากนั้นการรับส่งข้อมูลส่วนเกินจะเริ่มกระจายแบบสุ่มไปยังศูนย์ข้อมูลอื่น ทุกอย่างทำงานได้ดีทุกคนมีความสุข

วิธีที่เราทำ: การเผยแพร่ข่าวประชาสัมพันธ์

ตอนนี้เรามาพูดถึงวิธีที่เราเผยแพร่การเปลี่ยนแปลงที่เกิดขึ้นกับบริการ ที่นี่เราได้ใช้เส้นทางของกระบวนการลดความซับซ้อน: การเปิดตัวรุ่นใหม่เกือบจะเป็นไปโดยอัตโนมัติทั้งหมด
เมื่อสะสมการเปลี่ยนแปลงในโปรเจ็กต์เป็นจำนวนหนึ่ง จะมีการสร้างรีลีสใหม่โดยอัตโนมัติและเริ่มการสร้าง

จากนั้นจึงนำบริการไปทดสอบ โดยมีการตรวจสอบความเสถียรของการทำงาน

ขณะเดียวกันก็มีการเปิดตัวการทดสอบประสิทธิภาพอัตโนมัติ ซึ่งได้รับการจัดการโดยบริการพิเศษ ฉันจะไม่พูดถึงมันตอนนี้ - คำอธิบายของมันคุ้มค่ากับบทความแยกต่างหาก

หากการเผยแพร่ในการทดสอบสำเร็จ การเผยแพร่การเผยแพร่ในรูปแบบ prestable จะเริ่มต้นโดยอัตโนมัติ Prestable เป็นคลัสเตอร์พิเศษที่ควบคุมการรับส่งข้อมูลผู้ใช้ปกติ หากส่งคืนข้อผิดพลาด บาลานเซอร์จะส่งคำขอใหม่ไปยังการใช้งานจริง

ในรูปแบบที่กำหนดได้ จะมีการวัดเวลาตอบสนองและเปรียบเทียบกับรุ่นก่อนหน้าในการผลิต หากทุกอย่างเรียบร้อยดี บุคคลนั้นจะเชื่อมต่อกัน: ตรวจสอบกราฟและผลลัพธ์ของการทดสอบโหลด จากนั้นจึงเริ่มเปิดตัวสู่การใช้งานจริง

ผู้ใช้จะได้รับสิ่งที่ดีที่สุด: การทดสอบ A/B

ไม่ชัดเจนเสมอไปว่าการเปลี่ยนแปลงบริการจะก่อให้เกิดประโยชน์ที่แท้จริงหรือไม่ เพื่อวัดประโยชน์ของการเปลี่ยนแปลง ผู้คนจึงใช้การทดสอบ A/B ฉันจะบอกคุณเล็กน้อยเกี่ยวกับวิธีการทำงานใน Yandex.Market search

ทุกอย่างเริ่มต้นด้วยการเพิ่มพารามิเตอร์ CGI ใหม่ที่ช่วยให้ใช้งานฟังก์ชันใหม่ๆ ได้ ให้พารามิเตอร์ของเราเป็น: market_new_functionity=1. จากนั้นในโค้ดเราจะเปิดใช้งานฟังก์ชันนี้หากมีแฟล็กอยู่:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

ฟังก์ชันใหม่กำลังเปิดตัวสู่การใช้งานจริง

เพื่อให้การทดสอบ A/B เป็นอัตโนมัติ มีบริการเฉพาะที่ให้ข้อมูลโดยละเอียด อธิบายไว้ที่นี่. มีการสร้างการทดสอบในบริการ ส่วนแบ่งการเข้าชมถูกตั้งค่าไว้ เช่น 15% เปอร์เซ็นต์ไม่ได้ถูกกำหนดไว้สำหรับการสืบค้น แต่สำหรับผู้ใช้ นอกจากนี้ยังระบุระยะเวลาของการทดสอบด้วย เช่น หนึ่งสัปดาห์

สามารถดำเนินการทดลองหลายอย่างพร้อมกันได้ ในการตั้งค่า คุณสามารถระบุได้ว่าสามารถตัดกับการทดลองอื่นๆ ได้หรือไม่

เป็นผลให้บริการเพิ่มอาร์กิวเมนต์โดยอัตโนมัติ market_new_functionity=1 ถึง 15% ของผู้ใช้ นอกจากนี้ยังคำนวณเมตริกที่เลือกโดยอัตโนมัติอีกด้วย หลังจากการทดสอบเสร็จสิ้น นักวิเคราะห์จะพิจารณาผลลัพธ์และสรุปผล จากการค้นพบนี้ มีการตัดสินใจเปิดตัวสู่การผลิตหรือการปรับแต่ง

มือที่คล่องแคล่วของตลาด: การทดสอบในการผลิต

บ่อยครั้งที่คุณต้องทดสอบการทำงานของฟังก์ชันใหม่ในการผลิต แต่คุณไม่แน่ใจว่าฟังก์ชันดังกล่าวจะทำงานอย่างไรในสภาวะ "การต่อสู้" ภายใต้ภาระงานหนัก

มีวิธีแก้ไข: แฟล็กในพารามิเตอร์ CGI สามารถใช้ไม่เพียงแต่สำหรับการทดสอบ A/B เท่านั้น แต่ยังเพื่อทดสอบฟังก์ชันการทำงานใหม่ด้วย

เราได้สร้างเครื่องมือที่ช่วยให้คุณสามารถเปลี่ยนการกำหนดค่าบนเซิร์ฟเวอร์นับพันเครื่องได้ทันทีโดยไม่ทำให้บริการมีความเสี่ยง เรียกว่าหยุดแตะ แนวคิดเดิมคือสามารถปิดการใช้งานฟังก์ชันการทำงานบางอย่างได้อย่างรวดเร็วโดยไม่ต้องมีเค้าโครง จากนั้นเครื่องมือก็ขยายและซับซ้อนมากขึ้น

แผนภาพการไหลของบริการแสดงไว้ด้านล่าง:

ค่าสถานะถูกกำหนดผ่าน API บริการการจัดการเก็บค่าเหล่านี้ไว้ในฐานข้อมูล เซิร์ฟเวอร์ทั้งหมดไปที่ฐานข้อมูลทุกๆ สิบวินาที สูบค่าแฟล็กออก และใช้ค่าเหล่านี้กับแต่ละคำขอ

ในการแตะหยุด คุณสามารถตั้งค่าได้สองประเภท:

1) การแสดงออกตามเงื่อนไข ใช้เมื่อค่าใดค่าหนึ่งเป็นจริง ตัวอย่างเช่น:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

ค่า "3" จะถูกนำไปใช้เมื่อมีการประมวลผลคำขอในตำแหน่ง DC1 และค่าจะเป็น "4" เมื่อมีการประมวลผลคำขอบนคลัสเตอร์ที่สองสำหรับไซต์ beru.ru

2) ค่าที่ไม่มีเงื่อนไข ใช้ตามค่าเริ่มต้นหากไม่มีตรงตามเงื่อนไข ตัวอย่างเช่น:

คุณค่า คุณค่า!

หากค่าลงท้ายด้วยเครื่องหมายอัศเจรีย์ แสดงว่าค่านั้นมีลำดับความสำคัญสูงกว่า

ตัวแยกวิเคราะห์พารามิเตอร์ CGI แยกวิเคราะห์ URL จากนั้นนำค่าจาก Stop Tap ไปใช้

ใช้ค่าที่มีลำดับความสำคัญต่อไปนี้:

1. ด้วยลำดับความสำคัญที่เพิ่มขึ้นจาก Stop Tap (เครื่องหมายอัศเจรีย์)
2. ค่าจากการร้องขอ
3. ค่าเริ่มต้นจากการแตะหยุด
4. ค่าเริ่มต้นในรหัส

มีแฟล็กจำนวนมากที่ระบุในค่าตามเงื่อนไขซึ่งเพียงพอสำหรับทุกสถานการณ์ที่เรารู้จัก:

• ศูนย์ข้อมูล.
• สิ่งแวดล้อม: การผลิต การทดสอบ เงา
• Venue: ตลาดเบรู.
• หมายเลขคลัสเตอร์

ด้วยเครื่องมือนี้ คุณสามารถเปิดใช้งานฟังก์ชันการทำงานใหม่บนกลุ่มเซิร์ฟเวอร์บางกลุ่มได้ (เช่น ในศูนย์ข้อมูลเพียงแห่งเดียว) และทดสอบการทำงานของฟังก์ชันนี้โดยไม่มีความเสี่ยงใดๆ ต่อบริการทั้งหมด แม้ว่าคุณจะทำผิดพลาดร้ายแรงที่ไหนสักแห่ง ทุกอย่างเริ่มพังและศูนย์ข้อมูลทั้งหมดล่ม ตัวปรับสมดุลจะเปลี่ยนเส้นทางคำขอไปยังศูนย์ข้อมูลอื่น ผู้ใช้จะไม่สังเกตเห็นอะไรเลย

หากคุณสังเกตเห็นปัญหา คุณสามารถคืนค่าแฟล็กเป็นค่าก่อนหน้าได้ทันที และการเปลี่ยนแปลงจะถูกย้อนกลับ

บริการนี้ก็มีข้อเสียเช่นกัน: นักพัฒนาชอบมากและมักจะพยายามผลักดันการเปลี่ยนแปลงทั้งหมดไปที่ Stop Tap เรากำลังพยายามต่อสู้กับการใช้งานในทางที่ผิด

วิธี Stop Tap ทำงานได้ดีเมื่อคุณมีโค้ดที่เสถียรพร้อมที่จะเปิดตัวสู่การใช้งานจริงอยู่แล้ว ในขณะเดียวกัน คุณยังคงมีข้อสงสัย และต้องการตรวจสอบโค้ดในเงื่อนไข "การต่อสู้"

อย่างไรก็ตาม Stop Tap ไม่เหมาะสำหรับการทดสอบระหว่างการพัฒนา มีคลัสเตอร์แยกต่างหากสำหรับนักพัฒนาที่เรียกว่า “คลัสเตอร์เงา”

การทดสอบความลับ: คลัสเตอร์เงา

คำขอจากคลัสเตอร์ใดคลัสเตอร์หนึ่งซ้ำกับคลัสเตอร์เงา แต่บาลานเซอร์จะเพิกเฉยต่อการตอบสนองจากคลัสเตอร์นี้โดยสิ้นเชิง แผนภาพการทำงานแสดงไว้ด้านล่าง

เราได้รับคลัสเตอร์การทดสอบที่อยู่ในสภาพ "การต่อสู้" จริง ปริมาณการใช้งานของผู้ใช้ปกติจะไปที่นั่น ฮาร์ดแวร์ในทั้งสองคลัสเตอร์เหมือนกัน จึงสามารถเปรียบเทียบประสิทธิภาพและข้อผิดพลาดได้

และเนื่องจากบาลานเซอร์ละเว้นการตอบสนองโดยสิ้นเชิง ผู้ใช้จะไม่เห็นการตอบสนองจากคลัสเตอร์เงา ดังนั้นจึงไม่น่ากลัวที่จะทำผิดพลาด

ผลการวิจัย

แล้วเราจะสร้างการค้นหาในตลาดได้อย่างไร

เพื่อให้ทุกอย่างดำเนินไปอย่างราบรื่น เราจึงแยกฟังก์ชันการทำงานออกเป็นบริการที่แยกจากกัน ด้วยวิธีนี้เราสามารถปรับขนาดเฉพาะส่วนประกอบที่เราต้องการและทำให้ส่วนประกอบต่างๆ ง่ายขึ้น เป็นเรื่องง่ายที่จะมอบหมายองค์ประกอบแยกต่างหากให้กับทีมอื่นและแบ่งปันความรับผิดชอบในการทำงานกับองค์ประกอบนั้น และการประหยัดธาตุเหล็กได้อย่างมากด้วยวิธีนี้ถือเป็นข้อดีอย่างเห็นได้ชัด

Shadow Cluster ยังช่วยเราด้วย: เราสามารถพัฒนาบริการ ทดสอบบริการในกระบวนการ และไม่รบกวนผู้ใช้

แน่นอนว่าการทดสอบในการผลิต ต้องการเปลี่ยนการกำหนดค่าบนเซิร์ฟเวอร์นับพันหรือไม่ ง่าย ๆ ใช้ Stop Tap ด้วยวิธีนี้ คุณสามารถเปิดตัวโซลูชันที่ซับซ้อนสำเร็จรูปได้ทันที และย้อนกลับไปเป็นเวอร์ชันเสถียรหากเกิดปัญหา

ฉันหวังว่าฉันจะสามารถแสดงให้เห็นว่าเราทำให้ตลาดรวดเร็วและมั่นคงได้อย่างไรด้วยฐานข้อเสนอที่เพิ่มมากขึ้นเรื่อยๆ วิธีที่เราแก้ไขปัญหาเซิร์ฟเวอร์ จัดการกับคำขอจำนวนมาก ปรับปรุงความยืดหยุ่นของบริการ และดำเนินการโดยไม่ขัดจังหวะกระบวนการทำงาน

ที่มา: will.com