อาร์เต็ม เดนิซอฟ ( , )
Badoo เป็นเว็บไซต์หาคู่ที่ใหญ่ที่สุดในโลก ปัจจุบันเรามีผู้ใช้ที่ลงทะเบียนแล้วประมาณ 330 ล้านคนทั่วโลก แต่สิ่งที่สำคัญกว่ามากในบริบทของการสนทนาของเราในวันนี้ก็คือ เราจัดเก็บภาพถ่ายของผู้ใช้ได้ประมาณ 3 เพตาไบต์ ทุกๆ วันผู้ใช้ของเราอัปโหลดรูปภาพใหม่ประมาณ 3,5 ล้านภาพ และปริมาณการอ่านก็ประมาณนั้น 80 คำขอต่อวินาที. นี่เป็นเรื่องค่อนข้างมากสำหรับแบ็กเอนด์ของเรา และบางครั้งก็มีปัญหาในเรื่องนี้
ฉันจะพูดถึงการออกแบบระบบนี้ซึ่งจัดเก็บและส่งภาพถ่ายโดยรวมและจะพิจารณาจากมุมมองของนักพัฒนา จะมีการสรุปสั้นๆ เกี่ยวกับการพัฒนา โดยฉันจะสรุปเหตุการณ์สำคัญ แต่จะพูดถึงเฉพาะรายละเอียดเพิ่มเติมเกี่ยวกับโซลูชันที่เรากำลังใช้อยู่เท่านั้น
ตอนนี้เรามาเริ่มต้นกัน
อย่างที่ผมบอกไป นี่จะเป็นการย้อนหลัง และเพื่อที่จะเริ่มต้นมันสักจุดหนึ่ง เรามายกตัวอย่างที่พบบ่อยที่สุดกัน
เรามีงานทั่วไป เราต้องยอมรับ จัดเก็บ และส่งภาพถ่ายของผู้ใช้ ในรูปแบบนี้เป็นงานทั่วไป เราสามารถใช้อะไรก็ได้:
- ที่เก็บข้อมูลบนคลาวด์ที่ทันสมัย
- วิธีแก้ปัญหาแบบบรรจุกล่องซึ่งมีอยู่มากมายในตอนนี้
- เราสามารถตั้งค่าเครื่องหลายเครื่องในศูนย์ข้อมูลของเรา และใส่ฮาร์ดไดรฟ์ขนาดใหญ่ไว้และจัดเก็บรูปภาพไว้ที่นั่น
ในอดีต Badoo - ทั้งในปัจจุบันและหลังจากนั้น (ในช่วงเวลาที่ยังอยู่ในช่วงเริ่มต้น) - อาศัยอยู่บนเซิร์ฟเวอร์ของตัวเอง ภายใน DC ของเราเอง ดังนั้นตัวเลือกนี้จึงเหมาะสมที่สุดสำหรับเรา
เราเพิ่งเอาเครื่องมาหลายเครื่อง เรียกมันว่า "ภาพถ่าย" และเราก็ได้คลัสเตอร์ที่เก็บภาพถ่าย แต่ดูเหมือนมีบางอย่างขาดหายไป เพื่อให้ทั้งหมดนี้ทำงานได้ เราจำเป็นต้องพิจารณาว่าเราจะเก็บรูปภาพใดไว้ในเครื่องใด และที่นี่ก็ไม่จำเป็นต้องเปิดอเมริกาด้วย
เราเพิ่มช่องข้อมูลบางส่วนลงในพื้นที่จัดเก็บข้อมูลของเราพร้อมข้อมูลเกี่ยวกับผู้ใช้ นี่จะเป็นคีย์ชาร์ดดิ้ง ในกรณีของเรา เราเรียกมันว่า place_id และรหัสสถานที่นี้จะชี้ไปยังสถานที่จัดเก็บรูปภาพของผู้ใช้ เราทำแผนที่
ในขั้นแรกสามารถทำได้ด้วยตนเอง - เราบอกว่ารูปถ่ายของผู้ใช้รายนี้ซึ่งมีสถานที่ดังกล่าวจะลงจอดบนเซิร์ฟเวอร์ดังกล่าว ด้วยแผนที่นี้ เราจึงรู้อยู่เสมอว่าผู้ใช้อัพโหลดรูปภาพเมื่อใด จะบันทึกรูปภาพนั้นไว้ที่ไหน และเรารู้ว่าจะต้องนำรูปภาพนั้นมาจากที่ใด
นี่เป็นโครงการที่ไม่สำคัญอย่างยิ่ง แต่ก็มีข้อได้เปรียบที่สำคัญมาก อย่างแรกคือมันเรียบง่าย อย่างที่ผมบอกไปแล้ว และอย่างที่สองคือด้วยวิธีนี้ เราสามารถปรับขนาดในแนวนอนได้ง่ายๆ เพียงส่งมอบรถใหม่และเพิ่มลงในแผนที่ คุณไม่จำเป็นต้องทำอะไรอีก
สำหรับเรามันก็เป็นเช่นนั้นมาระยะหนึ่งแล้ว
นี่ก็ประมาณปี 2009 พวกเขาส่งมอบรถ, ส่งมอบ...
และเมื่อถึงจุดหนึ่งเราก็เริ่มสังเกตเห็นว่าโครงการนี้มีข้อเสียบางประการ ข้อเสียคืออะไร?
ประการแรก ความจุมีจำกัด เราไม่สามารถอัดฮาร์ดไดรฟ์จำนวนมากลงบนเซิร์ฟเวอร์จริงเครื่องเดียวได้เท่าที่เราต้องการ และนี่ก็กลายเป็นปัญหาบางอย่างเมื่อเวลาผ่านไปและด้วยการเติบโตของชุดข้อมูล
และประการที่สอง นี่เป็นการกำหนดค่าเครื่องจักรที่ไม่ปกติ เนื่องจากเครื่องจักรดังกล่าวยากต่อการนำกลับมาใช้ซ้ำในกลุ่มอื่นๆ บางกลุ่ม ซึ่งค่อนข้างเฉพาะเจาะจง เช่น พวกเขาควรจะมีประสิทธิภาพอ่อนแอ แต่ในขณะเดียวกันก็มีฮาร์ดไดรฟ์ขนาดใหญ่
ทั้งหมดนี้เป็นของปี 2009 แต่โดยหลักการแล้ว ข้อกำหนดเหล่านี้ยังคงมีความเกี่ยวข้องในปัจจุบัน เรามีการย้อนหลัง ดังนั้นในปี 2009 ทุกอย่างจึงแย่มากกับเรื่องนี้
และจุดสุดท้ายคือราคา
ตอนนั้นราคาสูงชันมาก และเราจำเป็นต้องมองหาทางเลือกอื่น เหล่านั้น. เราจำเป็นต้องใช้ทั้งพื้นที่ในศูนย์ข้อมูลและเซิร์ฟเวอร์ทางกายภาพซึ่งเป็นที่ตั้งของทั้งหมดนี้ให้ดีขึ้นให้ดีขึ้น และวิศวกรระบบของเราได้เริ่มการศึกษาวิจัยครั้งใหญ่โดยได้ทบทวนตัวเลือกต่างๆ มากมาย พวกเขายังพิจารณาระบบไฟล์แบบคลัสเตอร์ เช่น PolyCeph และ Luster อีกด้วย มีปัญหาด้านประสิทธิภาพและการดำเนินงานค่อนข้างยาก พวกเขาปฏิเสธ เราพยายามติดตั้งชุดข้อมูลทั้งหมดผ่าน NFS บนรถแต่ละคันเพื่อที่จะขยายขนาดให้ใหญ่ขึ้น การอ่านยังทำได้ไม่ดีนัก เราลองใช้วิธีแก้ปัญหาต่างๆ จากผู้ขายหลายราย
และในท้ายที่สุด เราก็ตัดสินใจใช้สิ่งที่เรียกว่า Storage Area Network
เหล่านี้เป็น SHD ขนาดใหญ่ที่ออกแบบมาโดยเฉพาะสำหรับการจัดเก็บข้อมูลจำนวนมาก เป็นชั้นวางที่มีดิสก์ซึ่งติดตั้งอยู่บนเครื่องเอาต์พุตแสงขั้นสุดท้าย ที่. เรามีเครื่องจักรบางประเภทที่ค่อนข้างเล็ก และ SHD เหล่านี้ซึ่งโปร่งใสต่อลอจิกการส่งของเรา เช่น เพื่อให้ nginx ของเราหรือใครก็ตามสามารถให้บริการคำขอรูปภาพเหล่านี้ได้
การตัดสินใจครั้งนี้มีข้อได้เปรียบที่ชัดเจน นี่คือ SHD มีวัตถุประสงค์เพื่อจัดเก็บภาพถ่าย วิธีนี้ใช้ราคาถูกกว่าการติดตั้งฮาร์ดไดรฟ์ให้กับเครื่องจักร
บวกที่สอง
นี่คือความจุที่มากขึ้นเช่น เราสามารถรองรับพื้นที่จัดเก็บข้อมูลได้มากขึ้นในปริมาณที่น้อยกว่ามาก
แต่ก็มีข้อเสียเกิดขึ้นค่อนข้างเร็วเช่นกัน เมื่อจำนวนผู้ใช้และโหลดบนระบบนี้เพิ่มขึ้น ปัญหาด้านประสิทธิภาพก็เริ่มเกิดขึ้น และปัญหาที่นี่ค่อนข้างชัดเจน - ตามกฎแล้ว SHD ใด ๆ ที่ออกแบบมาเพื่อจัดเก็บภาพถ่ายจำนวนมากในปริมาณน้อยจะต้องทนทุกข์ทรมานจากการอ่านอย่างเข้มข้น นี่เป็นเรื่องจริงสำหรับที่เก็บข้อมูลบนคลาวด์หรือสิ่งอื่นใด ขณะนี้เราไม่มีพื้นที่จัดเก็บข้อมูลในอุดมคติที่สามารถปรับขนาดได้อย่างไม่จำกัด คุณสามารถใส่อะไรก็ได้ลงไป และมันจะทนทานต่อการอ่านค่าได้เป็นอย่างดี โดยเฉพาะการอ่านแบบสบาย ๆ
เช่นเดียวกับภาพถ่ายของเรา เนื่องจากการขอรูปภาพไม่สอดคล้องกัน และสิ่งนี้จะส่งผลต่อประสิทธิภาพอย่างมาก
ตามตัวเลขของวันนี้ หากเราได้รับภาพถ่ายมากกว่า 500 RPS บนเครื่องที่เชื่อมต่อกับที่จัดเก็บข้อมูล ปัญหาก็เริ่มต้นขึ้นแล้ว และมันก็แย่พอสำหรับเราแล้ว เนื่องจากจำนวนผู้ใช้เพิ่มขึ้น สิ่งต่างๆ ก็จะยิ่งแย่ลงเท่านั้น สิ่งนี้จำเป็นต้องได้รับการปรับให้เหมาะสม
เพื่อเพิ่มประสิทธิภาพ เราตัดสินใจอย่างชัดเจนในขณะนั้นว่าจะดูโปรไฟล์โหลด - โดยทั่วไปแล้วเกิดอะไรขึ้น อะไรที่ต้องได้รับการปรับให้เหมาะสม
และที่นี่ทุกอย่างเล่นอยู่ในมือของเรา
ฉันได้กล่าวไปแล้วในสไลด์แรก: เรามีคำขออ่าน 80 คำขอต่อวินาที โดยมีการอัปโหลดเพียง 3,5 ล้านครั้งต่อวัน นั่นคือนี่คือความแตกต่างของขนาดสามลำดับความสำคัญ เห็นได้ชัดว่าการอ่านจำเป็นต้องได้รับการปรับให้เหมาะสม และชัดเจนว่าจะต้องทำอย่างไร
มีจุดเล็กๆ อีกจุดหนึ่ง ลักษณะเฉพาะของบริการคือการที่บุคคลหนึ่งลงทะเบียน อัปโหลดรูปภาพ จากนั้นเริ่มมองคนอื่นอย่างกระตือรือร้น เช่น พวกเขา และแสดงต่อผู้อื่นอย่างแข็งขัน แล้วจะหาคู่หรือไม่ก็หาคู่ไม่ได้ก็ขึ้นอยู่ว่าจะเป็นยังไงและหยุดใช้บริการไปสักระยะหนึ่ง ช่วงนี้พอใช้รูปก็มาแรง เป็นที่ต้องการ คนดูเยอะมาก ทันทีที่เขาหยุดทำสิ่งนี้ เขาก็เลิกพบปะผู้อื่นอย่างรวดเร็วเหมือนเมื่อก่อน และรูปถ่ายของเขาก็แทบไม่เคยถูกขอเลย
เหล่านั้น. เรามีชุดข้อมูลยอดนิยมที่มีขนาดเล็กมาก แต่ในขณะเดียวกันก็มีคำขอของเขามากมาย และวิธีแก้ปัญหาที่ชัดเจนที่สุดคือการเพิ่มแคช
แคชที่มี LRU จะช่วยแก้ปัญหาทั้งหมดของเรา เรากำลังทำอะไรอยู่?
เราเพิ่มอีกอันที่ค่อนข้างเล็กไว้หน้าคลัสเตอร์ขนาดใหญ่พร้อมพื้นที่เก็บข้อมูล ซึ่งเรียกว่าโฟโต้แคช นี่เป็นเพียงพร็อกซีแคชเท่านั้น
มันทำงานจากภายในได้อย่างไร? นี่คือผู้ใช้ของเรา นี่คือที่เก็บข้อมูล ทุกอย่างเหมือนเดิม เราจะเพิ่มอะไรเข้าไประหว่างนั้น?
มันเป็นเพียงเครื่องที่มีดิสก์ภายในเครื่องซึ่งเร็ว นี่คือการใช้ SSD เป็นต้น และแคชในเครื่องบางประเภทถูกเก็บไว้ในดิสก์นี้
มันดูเหมือนอะไร? ผู้ใช้ส่งคำขอรูปถ่าย NGINX ค้นหามันก่อนในแคชในเครื่อง ถ้าไม่เช่นนั้น เพียง proxy_pass ไปยังที่เก็บข้อมูลของเรา ดาวน์โหลดรูปภาพจากที่นั่นและมอบให้กับผู้ใช้
แต่อันนี้ดูซ้ำซากมากและไม่ชัดเจนว่าเกิดอะไรขึ้นภายใน มันทำงานบางอย่างเช่นนี้
แคชแบ่งออกเป็นสามชั้นตามตรรกะ เมื่อฉันพูดว่า "สามชั้น" นี่ไม่ได้หมายความว่ามีระบบที่ซับซ้อนบางอย่าง ไม่ นี่เป็นเพียงสามไดเร็กทอรีในระบบไฟล์ตามเงื่อนไข:
- นี่คือบัฟเฟอร์ที่รูปภาพที่เพิ่งดาวน์โหลดจากพร็อกซีไป
- นี่คือแคชร้อนที่เก็บรูปภาพที่มีการร้องขอในปัจจุบัน
- และแคชเย็น ซึ่งรูปภาพจะค่อยๆ ผลักออกจากแคชร้อนเมื่อมีคำขอน้อยลง
เพื่อให้ได้ผล เราต้องจัดการแคชนี้ เราต้องจัดเรียงรูปภาพในแคชใหม่ ฯลฯ นี่เป็นกระบวนการดั้งเดิมมากเช่นกัน
Nginx เพียงเขียนลงใน RAMDisk access.log สำหรับแต่ละคำขอ โดยจะระบุเส้นทางไปยังรูปภาพที่ให้บริการอยู่ในปัจจุบัน (เส้นทางสัมพัทธ์แน่นอน) และพาร์ติชันใดที่ให้บริการ เหล่านั้น. อาจพูดว่า "รูปภาพ 1" แล้วตามด้วยบัฟเฟอร์ หรือแคชร้อน หรือแคชเย็น หรือพร็อกซี
เราต้องตัดสินใจว่าจะทำอย่างไรกับภาพถ่ายทั้งนี้ขึ้นอยู่กับสิ่งนี้
เรามี daemon ขนาดเล็กที่ทำงานอยู่บนแต่ละเครื่อง ซึ่งจะอ่านบันทึกนี้อย่างต่อเนื่องและจัดเก็บสถิติเกี่ยวกับการใช้ภาพถ่ายบางภาพไว้ในหน่วยความจำ
เขาเพียงแค่รวบรวมที่นั่น เก็บเคาน์เตอร์ และทำสิ่งต่อไปนี้เป็นระยะ เขาย้ายรูปภาพที่มีการร้องขออย่างแข็งขันซึ่งมีคำขอจำนวนมากไปยังแคชด่วนไม่ว่าจะอยู่ที่ไหนก็ตาม
รูปภาพที่มีการร้องขอน้อยครั้งและมีการร้องขอน้อยลงจะค่อยๆ ผลักออกจากแคชร้อนไปยังแคชเย็น
และเมื่อเรามีพื้นที่ว่างในแคชไม่เพียงพอ เราก็เริ่มลบทุกอย่างออกจากแคชเย็นโดยไม่เลือกปฏิบัติ และอีกอย่าง มันได้ผลดี
เพื่อให้ภาพถ่ายได้รับการบันทึกทันทีเมื่อทำการพร็อกซีไปยังบัฟเฟอร์ เราใช้คำสั่ง proxy_store และบัฟเฟอร์ก็เป็น RAMDisk เช่นกัน เช่น สำหรับผู้ใช้มันทำงานเร็วมาก สิ่งนี้เกี่ยวข้องกับภายในของแคชเซิร์ฟเวอร์เอง
คำถามที่เหลือคือวิธีกระจายคำขอข้ามเซิร์ฟเวอร์เหล่านี้
สมมติว่ามีคลัสเตอร์ของเครื่องจัดเก็บข้อมูลจำนวน XNUMX เครื่องและเซิร์ฟเวอร์แคช XNUMX เครื่อง (นี่คือสิ่งที่เกิดขึ้น)
เราจำเป็นต้องพิจารณาว่าคำขอใดเป็นคำขอสำหรับรูปถ่ายใดและจะนำไปที่ไหน
ตัวเลือกที่พบบ่อยที่สุดคือ Round Robin หรือทำโดยบังเอิญ?
สิ่งนี้เห็นได้ชัดว่ามีข้อเสียหลายประการ เนื่องจากเราจะใช้แคชอย่างไม่มีประสิทธิภาพในสถานการณ์เช่นนี้ คำขอจะถูกส่งไปที่เครื่องสุ่มบางเครื่อง: ที่นี่มันถูกแคชไว้ แต่ในเครื่องถัดไปจะไม่อยู่ที่นั่นอีกต่อไป และถ้าทั้งหมดนี้ได้ผลก็จะแย่มาก แม้จะมีเครื่องจักรจำนวนน้อยในคลัสเตอร์ก็ตาม
เราจำเป็นต้องกำหนดอย่างชัดเจนว่าเซิร์ฟเวอร์ใดจะส่งคำขอใด
มีวิธีซ้ำซาก เราใช้แฮชจาก URL หรือแฮชจากคีย์การแบ่งส่วนของเราซึ่งอยู่ใน URL แล้วหารด้วยจำนวนเซิร์ฟเวอร์ จะทำงาน? จะ.
เหล่านั้น. เรามีคำขอ 2% เช่น สำหรับ "example_url" บางส่วน แคชจะลงจอดบนเซิร์ฟเวอร์ที่มีดัชนี "XNUMX" เสมอ และแคชจะถูกกำจัดอย่างต่อเนื่องอย่างดีที่สุดเท่าที่จะทำได้
แต่มีปัญหาในการแบ่งส่วนใหม่ในโครงการดังกล่าว Resharding - ฉันหมายถึงการเปลี่ยนจำนวนเซิร์ฟเวอร์
สมมติว่าคลัสเตอร์แคชของเราไม่สามารถรับมือได้อีกต่อไป และเราตัดสินใจเพิ่มเครื่องอื่น
มาเพิ่มกันเถอะ
ตอนนี้ทุกอย่างหารไม่ได้ด้วยสาม แต่ด้วยสี่ ดังนั้น คีย์เกือบทั้งหมดที่เราเคยมี ปัจจุบัน URL เกือบทั้งหมดอยู่บนเซิร์ฟเวอร์อื่น แคชทั้งหมดใช้งานไม่ได้เพียงชั่วขณะหนึ่ง คำขอทั้งหมดตกไปที่คลัสเตอร์พื้นที่จัดเก็บข้อมูลของเรา อาการเริ่มไม่ดี บริการล้มเหลว และผู้ใช้ไม่พอใจ ฉันไม่ต้องการที่จะทำเช่นนั้น
ตัวเลือกนี้ไม่เหมาะกับเราเช่นกัน
ที่. เราควรทำอย่างไร? เราต้องใช้แคชอย่างมีประสิทธิภาพ ส่งคำขอเดียวกันบนเซิร์ฟเวอร์เดียวกันซ้ำแล้วซ้ำเล่า แต่ต้องทนต่อการแบ่งส่วนใหม่ และมีวิธีแก้ไขดังกล่าว มันไม่ซับซ้อนขนาดนั้น เรียกว่าการแฮชที่สม่ำเสมอ
มันดูเหมือนอะไร?
เราใช้ฟังก์ชันบางอย่างจากคีย์การแบ่งส่วนและกระจายค่าทั้งหมดบนวงกลม เหล่านั้น. ที่จุดที่ 0 ค่าต่ำสุดและค่าสูงสุดจะมาบรรจบกัน ต่อไป เราจะวางเซิร์ฟเวอร์ทั้งหมดของเราไว้ในวงกลมเดียวกันในลักษณะประมาณนี้:
แต่ละเซิร์ฟเวอร์ถูกกำหนดโดยหนึ่งจุด และเซกเตอร์ที่ไปตามเข็มนาฬิกาจะถูกเสิร์ฟโดยโฮสต์นี้ เมื่อมีคำขอมาถึงเรา เราจะเห็นได้ทันทีว่า เช่น คำขอ A - มีแฮชอยู่ที่นั่น - และคำขอนั้นให้บริการโดยเซิร์ฟเวอร์ 2 คำขอ B - โดยเซิร์ฟเวอร์ 3 เป็นต้น
จะเกิดอะไรขึ้นในสถานการณ์นี้ระหว่างการแบ่งย่อยใหม่?
เราไม่ทำให้แคชทั้งหมดใช้งานไม่ได้เหมือนเมื่อก่อน และไม่เลื่อนคีย์ทั้งหมด แต่เราเลื่อนแต่ละเซกเตอร์เป็นระยะทางสั้น ๆ เพื่อให้เซิร์ฟเวอร์ที่หกของเราซึ่งเราต้องการเพิ่ม พอดีกับพื้นที่ว่าง และ เราเพิ่มมันที่นั่น
แน่นอนว่าในสถานการณ์เช่นนี้ กุญแจก็จะหลุดออกไปเช่นกัน แต่พวกมันกลับอ่อนแอลงกว่าเดิมมาก และเราเห็นว่าคีย์สองคีย์แรกของเรายังคงอยู่บนเซิร์ฟเวอร์ และเซิร์ฟเวอร์แคชจะเปลี่ยนเฉพาะคีย์สุดท้ายเท่านั้น สิ่งนี้ทำงานได้ค่อนข้างมีประสิทธิภาพ และหากคุณเพิ่มโฮสต์ใหม่ทีละน้อย ก็ไม่มีปัญหาใหญ่ที่นี่ คุณเพิ่มและเพิ่มทีละน้อย รอจนกว่าแคชจะเต็มอีกครั้ง และทุกอย่างทำงานได้ดี
คำถามเดียวยังคงอยู่กับการปฏิเสธ สมมติว่ารถยนต์บางประเภทไม่เรียบร้อย
และเราไม่ต้องการสร้างแผนที่นี้ใหม่ในขณะนี้ ทำให้ส่วนหนึ่งของแคชใช้งานไม่ได้ และอื่นๆ เช่น หากเครื่องถูกรีบูท และเราจำเป็นต้องขอรับบริการด้วยวิธีใดวิธีหนึ่ง เราเพียงเก็บแคชรูปถ่ายสำรองไว้ที่แต่ละไซต์ ซึ่งทำหน้าที่ทดแทนเครื่องที่ขัดข้องอยู่ในปัจจุบัน และหากเซิร์ฟเวอร์ตัวใดตัวหนึ่งของเราใช้งานไม่ได้ กะทันหัน การรับส่งข้อมูลจะไปที่นั่น โดยปกติแล้ว เราไม่มีแคชใดๆ อยู่ที่นั่น เช่น อากาศหนาว แต่อย่างน้อยคำขอของผู้ใช้ก็ได้รับการประมวลผล หากนี่เป็นช่วงเวลาสั้น ๆ เราก็จะประสบกับมันอย่างสงบอย่างสมบูรณ์ มีพื้นที่จัดเก็บมากขึ้นเท่านั้น หากช่วงเวลานี้ยาวนาน เราก็สามารถตัดสินใจได้แล้วว่าจะลบเซิร์ฟเวอร์นี้ออกจากแผนที่หรือไม่ หรืออาจแทนที่ด้วยเซิร์ฟเวอร์อื่น
นี่เป็นเรื่องเกี่ยวกับระบบแคช มาดูผลลัพธ์กันดีกว่า
ดูเหมือนว่าไม่มีอะไรซับซ้อนที่นี่ แต่วิธีการจัดการแคชนี้ทำให้เรามีอัตราการหลอกลวงประมาณ 98% เหล่านั้น. จากคำขอ 80 คำขอต่อวินาที มีเพียง 1600 คำขอที่เข้าถึงได้ และนี่เป็นโหลดปกติโดยสมบูรณ์ พวกเขาอดทนกับมันอย่างใจเย็น เรามีเงินสำรองไว้เสมอ
เราวางเซิร์ฟเวอร์เหล่านี้ไว้ใน DC สามแห่งของเรา และได้รับการแสดงตนสามจุด ได้แก่ ปราก ไมอามี และฮ่องกง
ที่. พวกเขาตั้งอยู่ในท้องถิ่นของตลาดเป้าหมายแต่ละแห่งของเราไม่มากก็น้อย
และเพื่อเป็นโบนัสที่ดี เราได้รับพร็อกซีแคชนี้ ซึ่งจริง ๆ แล้ว CPU ไม่ได้ใช้งาน เนื่องจากไม่จำเป็นในการให้บริการเนื้อหา และที่นั่น ด้วยการใช้ NGINX+ Lua เราได้นำตรรกะที่เป็นประโยชน์มากมายมาใช้
ตัวอย่างเช่น เราสามารถทดลองกับ webp หรือ progressive jpeg (ซึ่งเป็นรูปแบบสมัยใหม่ที่มีประสิทธิภาพ) ดูว่ามันส่งผลต่อการรับส่งข้อมูลอย่างไร ตัดสินใจบางอย่าง เปิดใช้งานสำหรับบางประเทศ ฯลฯ ปรับขนาดหรือครอบตัดรูปภาพแบบไดนามิกได้ทันที
นี่เป็นกรณีการใช้งานที่ดี ตัวอย่างเช่น เมื่อคุณมีแอปพลิเคชันมือถือที่แสดงรูปภาพ และแอปพลิเคชันบนมือถือไม่ต้องการเสีย CPU ของไคลเอ็นต์ในการขอรูปภาพขนาดใหญ่ จากนั้นจึงปรับขนาดให้มีขนาดที่แน่นอนเพื่อที่จะพุชเข้าไป มุมมอง. เราสามารถระบุพารามิเตอร์บางตัวใน URL แบบมีเงื่อนไขของ UPort ได้แบบไดนามิก และแคชรูปภาพจะปรับขนาดรูปภาพเอง ตามกฎแล้วมันจะเลือกขนาดที่เรามีอยู่จริงบนดิสก์ให้ใกล้เคียงกับขนาดที่ร้องขอมากที่สุดและขายดาวน์ในพิกัดเฉพาะ
อย่างไรก็ตาม เราได้เผยแพร่วิดีโอที่เปิดเผยต่อสาธารณะในช่วงห้าปีที่ผ่านมาของการประชุมนักพัฒนาระบบที่มีภาระงานสูง . ดู เรียนรู้ แบ่งปัน และติดตาม .
นอกจากนี้เรายังสามารถเพิ่มตรรกะผลิตภัณฑ์จำนวนมากที่นั่นได้ ตัวอย่างเช่น เราสามารถเพิ่มลายน้ำต่างๆ โดยใช้พารามิเตอร์ URL เราสามารถเบลอ เบลอ หรือสร้างพิกเซลให้กับรูปภาพได้ นี่คือเวลาที่เราต้องการแสดงรูปถ่ายของบุคคล แต่เราไม่ต้องการแสดงใบหน้าของเขา วิธีนี้ได้ผลดี ทุกอย่างถูกนำไปใช้ที่นี่
เราได้อะไร? เรามีจุดแสดงตนสามจุด อัตรากลอุบายที่ดี และในขณะเดียวกัน เราก็ไม่มี CPU ที่ไม่ได้ใช้งานในเครื่องเหล่านี้ แน่นอนว่าตอนนี้เขามีความสำคัญมากกว่าเมื่อก่อนแล้ว เราจำเป็นต้องมอบรถยนต์ที่แข็งแกร่งให้กับตัวเอง แต่มันก็คุ้มค่า
เรื่องนี้เกี่ยวข้องกับการส่งคืนรูปถ่าย ทุกอย่างที่นี่ค่อนข้างชัดเจนและชัดเจน ฉันคิดว่าฉันไม่ได้ค้นพบอเมริกา CDN เกือบทุกแห่งก็ใช้วิธีนี้
และผู้ฟังที่เชี่ยวชาญอาจมีคำถาม: ทำไมไม่เปลี่ยนทุกอย่างเป็น CDN ล่ะ? มันก็จะประมาณเดียวกัน CDN ยุคใหม่ทั้งหมดสามารถทำได้ และมีสาเหตุหลายประการ
อย่างแรกคือรูปถ่าย
นี่เป็นหนึ่งในประเด็นสำคัญของโครงสร้างพื้นฐานของเรา และเราต้องการการควบคุมมันให้มากที่สุดเท่าที่จะเป็นไปได้ หากนี่เป็นวิธีแก้ปัญหาบางอย่างจากผู้จำหน่ายบุคคลที่สาม และคุณไม่มีอำนาจเหนือโซลูชันดังกล่าว จะค่อนข้างยากสำหรับคุณที่จะใช้งานมันเมื่อคุณมีชุดข้อมูลขนาดใหญ่ และเมื่อคุณมีโฟลว์ขนาดใหญ่มาก ของคำขอของผู้ใช้
ผมขอยกตัวอย่างให้คุณฟัง ตอนนี้ ด้วยโครงสร้างพื้นฐานของเรา เราสามารถยกตัวอย่างได้ ในกรณีที่เกิดปัญหาหรือการชนใต้ดิน ไปที่เครื่องจักรและเละเทะไปรอบๆ ตรงนั้น พูดได้เลย เราสามารถเพิ่มคอลเลกชันของเมตริกบางอย่างที่เราต้องการเท่านั้น เราสามารถทดลองด้วยวิธีใดวิธีหนึ่ง ดูว่าสิ่งนี้ส่งผลต่อกราฟอย่างไร และอื่นๆ ขณะนี้มีการรวบรวมสถิติจำนวนมากบนคลัสเตอร์แคชนี้ และเราจะดูมันเป็นระยะและใช้เวลานานในการสำรวจความผิดปกติบางอย่าง ถ้าเป็นฝั่ง CDN คงควบคุมได้ยากกว่ามาก หรือตัวอย่างเช่น หากเกิดอุบัติเหตุขึ้น เรารู้ว่าเกิดอะไรขึ้น เรารู้ว่าจะรับมือกับมันอย่างไร และจะเอาชนะมันได้อย่างไร นี่คือข้อสรุปแรก
ข้อสรุปที่สองยังค่อนข้างเป็นอดีต เนื่องจากระบบมีการพัฒนามาเป็นเวลานาน และมีข้อกำหนดทางธุรกิจที่แตกต่างกันมากมายในแต่ละขั้นตอน และไม่สอดคล้องกับแนวคิด CDN เสมอไป
และประเด็นต่อจากที่แล้วก็คือ
เนื่องจากในแคชรูปภาพ เรามีตรรกะเฉพาะจำนวนมาก ซึ่งไม่สามารถเพิ่มได้เสมอไปเมื่อมีการร้องขอ ไม่น่าเป็นไปได้ที่ CDN จะเพิ่มสิ่งที่กำหนดเองบางอย่างให้กับคุณตามคำขอของคุณ ตัวอย่างเช่น การเข้ารหัส URL หากคุณไม่ต้องการให้ลูกค้าสามารถเปลี่ยนแปลงบางสิ่งบางอย่างได้ คุณต้องการเปลี่ยน URL บนเซิร์ฟเวอร์และเข้ารหัส จากนั้นส่งพารามิเตอร์ไดนามิกบางส่วนที่นี่
ข้อสรุปนี้บ่งบอกถึงอะไร? ในกรณีของเรา CDN ไม่ใช่ทางเลือกที่ดีนัก
และในกรณีของคุณ หากคุณมีข้อกำหนดทางธุรกิจที่เฉพาะเจาะจง คุณสามารถปรับใช้สิ่งที่ฉันแสดงให้คุณเห็นได้อย่างง่ายดาย และสิ่งนี้จะทำงานได้อย่างสมบูรณ์แบบกับโปรไฟล์โหลดที่คล้ายกัน
แต่ถ้าคุณมีวิธีแก้ปัญหาทั่วไป และงานไม่เฉพาะเจาะจงมากนัก คุณสามารถรับ CDN ได้อย่างปลอดภัย หรือหากเวลาและทรัพยากรมีความสำคัญต่อคุณมากกว่าการควบคุม
และ CDN ยุคใหม่มีเกือบทุกอย่างที่ฉันบอกคุณตอนนี้ ยกเว้นบวกหรือลบคุณสมบัติบางอย่าง
เป็นการแจกรูปครับ
ตอนนี้เรามาดูย้อนหลังกันสักหน่อยและพูดคุยเกี่ยวกับการจัดเก็บ
ปี 2013 กำลังจะผ่านไป
เพิ่มเซิร์ฟเวอร์แคชแล้ว ปัญหาด้านประสิทธิภาพหายไป ทุกอย่างปกติดี. ชุดข้อมูลกำลังเติบโต ในปี 2013 เรามีเซิร์ฟเวอร์ประมาณ 80 เครื่องที่เชื่อมต่อกับพื้นที่จัดเก็บข้อมูล และมีแคชประมาณ 40 เครื่องในแต่ละ DC นี่คือข้อมูล 560 เทราไบต์ในแต่ละ DC เช่น รวมประมาณหนึ่งเพตะไบต์
และด้วยการเติบโตของชุดข้อมูล ต้นทุนการดำเนินงานก็เริ่มเพิ่มขึ้นอย่างมาก สิ่งนี้หมายความว่าอย่างไร?
ในแผนภาพนี้ที่วาดขึ้น - ด้วย SAN โดยมีเครื่องจักรและแคชเชื่อมต่ออยู่ - มีจุดที่เกิดข้อผิดพลาดมากมาย หากเราเคยจัดการกับความล้มเหลวของเซิร์ฟเวอร์แคชมาก่อน ทุกอย่างสามารถคาดเดาและเข้าใจได้ไม่มากก็น้อย แต่ในด้านพื้นที่จัดเก็บข้อมูล ทุกอย่างแย่ลงมาก
ประการแรกคือ Storage Area Network (SAN) เองซึ่งอาจล้มเหลวได้
ประการที่สอง เชื่อมต่อผ่านออพติกกับเครื่องจักรขั้นสุดท้าย อาจมีปัญหากับการ์ดออปติคัลและหัวเทียน
แน่นอนว่ามีไม่มากเท่ากับ SAN เอง แต่ถึงกระนั้นสิ่งเหล่านี้ก็เป็นจุดล้มเหลวเช่นกัน
ถัดมาเป็นตัวเครื่องซึ่งเชื่อมต่อกับที่เก็บข้อมูล ก็สามารถล้มเหลวได้เช่นกัน
โดยรวมแล้วเรามีจุดบกพร่องสามจุด
นอกจากนี้ นอกเหนือจากจุดที่เสียหายแล้ว ยังมีการบำรุงรักษาพื้นที่จัดเก็บข้อมูลอย่างหนักอีกด้วย
นี่เป็นระบบที่มีหลายองค์ประกอบที่ซับซ้อน และวิศวกรระบบอาจประสบปัญหาในการทำงานกับระบบนี้
และจุดสุดท้ายที่สำคัญที่สุด หากความล้มเหลวเกิดขึ้นที่จุดใดจุดหนึ่งในสามจุดเหล่านี้ เรามีโอกาสไม่ศูนย์ที่จะสูญเสียข้อมูลผู้ใช้เนื่องจากระบบไฟล์อาจเสียหาย
สมมติว่าระบบไฟล์ของเราเสียหาย ประการแรก การกู้คืนใช้เวลานาน - อาจใช้เวลาหนึ่งสัปดาห์โดยมีข้อมูลจำนวนมาก และประการที่สองในที่สุดเรามักจะจบลงด้วยไฟล์ที่เข้าใจยากจำนวนหนึ่งซึ่งจะต้องรวมเข้ากับรูปถ่ายของผู้ใช้ และเราเสี่ยงต่อการสูญเสียข้อมูล ความเสี่ยงค่อนข้างสูง และยิ่งสถานการณ์ดังกล่าวเกิดขึ้นบ่อยขึ้น และยิ่งเกิดปัญหาในห่วงโซ่ทั้งหมดนี้มากขึ้นเท่าใด ความเสี่ยงก็จะยิ่งสูงขึ้นเท่านั้น
จะต้องทำอะไรสักอย่างเกี่ยวกับเรื่องนี้ และเราตัดสินใจว่าเราเพียงแค่ต้องสำรองข้อมูล นี่เป็นวิธีแก้ปัญหาที่ชัดเจนและเป็นทางเลือกที่ดีจริงๆ เราทำอะไรไปแล้วบ้าง?
นี่คือหน้าตาเซิร์ฟเวอร์ของเราเมื่อเชื่อมต่อกับที่เก็บข้อมูลมาก่อน นี่คือส่วนหลักส่วนหนึ่ง เป็นเพียงอุปกรณ์บล็อกที่แสดงถึงการเมาท์สำหรับการจัดเก็บระยะไกลผ่านออปติก
เราเพิ่งเพิ่มส่วนที่สอง
เราวางที่เก็บข้อมูลที่สองไว้ข้างๆ (โชคดีที่ไม่แพงขนาดนั้น) และเรียกมันว่าพาร์ติชั่นสำรอง นอกจากนี้ยังเชื่อมต่อผ่านเลนส์และอยู่ในเครื่องเดียวกัน แต่เราจำเป็นต้องซิงโครไนซ์ข้อมูลระหว่างกัน
ที่นี่เราเพียงแค่สร้างคิวอะซิงโครนัสในบริเวณใกล้เคียง
เธอไม่ค่อยยุ่งมาก เรารู้ว่าเรามีบันทึกไม่เพียงพอ คิวเป็นเพียงตารางใน MySQL ซึ่งมีการเขียนบรรทัดเช่น "คุณต้องสำรองรูปภาพนี้" หากมีการเปลี่ยนแปลงหรืออัปโหลด เราจะคัดลอกจากพาร์ติชันหลักไปยังการสำรองข้อมูลโดยใช้อะซิงโครนัสหรือโปรแกรมทำงานเบื้องหลังบางประเภท
ดังนั้นเราจึงมีสองส่วนที่สอดคล้องกันเสมอ แม้ว่าส่วนหนึ่งของระบบนี้จะล้มเหลว แต่เราสามารถเปลี่ยนพาร์ติชันหลักด้วยการสำรองข้อมูลได้ตลอดเวลา และทุกอย่างจะยังคงทำงานต่อไป
แต่ด้วยเหตุนี้ ปริมาณการอ่านจึงเพิ่มขึ้นอย่างมาก เนื่องจาก... นอกจากลูกค้าที่อ่านจากส่วนหลักแล้ว เพราะพวกเขาดูรูปถ่ายที่นั่นก่อน (ซึ่งล่าสุดกว่านั้น) แล้วมองหามันในข้อมูลสำรองหากพวกเขาไม่พบมัน (แต่ NGINX เพิ่งทำสิ่งนี้) ระบบของเรายังเป็นการสำรองข้อมูลแบบบวกที่อ่านได้จากพาร์ติชันหลัก ไม่ใช่ว่านี่เป็นปัญหาคอขวด แต่ฉันไม่ต้องการเพิ่มภาระ จริงๆ แล้วเป็นเช่นนั้น
และเราได้เพิ่มดิสก์แผ่นที่สามซึ่งเป็น SSD ขนาดเล็ก และเรียกมันว่าบัฟเฟอร์
มันทำงานอย่างไรตอนนี้.
ผู้ใช้อัปโหลดภาพถ่ายไปยังบัฟเฟอร์ จากนั้นเหตุการณ์จะถูกส่งไปยังคิวเพื่อระบุว่าจำเป็นต้องคัดลอกออกเป็นสองส่วน มันถูกคัดลอกและรูปภาพจะคงอยู่ในบัฟเฟอร์เป็นระยะเวลาหนึ่ง (เช่นหนึ่งวัน) จากนั้นจึงถูกลบออกจากที่นั่น สิ่งนี้ช่วยปรับปรุงประสบการณ์ผู้ใช้อย่างมาก เนื่องจากตามกฎแล้วผู้ใช้อัปโหลดรูปภาพ คำขอเริ่มติดตามทันที หรือเขาเองอัปเดตหน้าและรีเฟรชหน้าเอง แต่ทั้งหมดขึ้นอยู่กับแอปพลิเคชันที่ทำการอัปโหลด
หรือตัวอย่างเช่น คนอื่น ๆ ที่เขาเริ่มแสดงตัวให้ส่งคำขอหลังจากรูปภาพนี้ทันที ยังไม่ได้อยู่ในแคช คำขอแรกเกิดขึ้นอย่างรวดเร็ว โดยพื้นฐานแล้วเหมือนกับจากแคชรูปภาพ การจัดเก็บที่ช้าไม่เกี่ยวข้องกับเรื่องนี้เลย และเมื่อวันต่อมามันถูกล้างข้อมูล มันก็ถูกแคชไว้บนเลเยอร์แคชของเราแล้ว หรืออาจไม่มีใครต้องการมันอีกต่อไป เหล่านั้น. ประสบการณ์ผู้ใช้ที่นี่เติบโตขึ้นอย่างมากเนื่องจากการยักย้ายง่ายๆ
และที่สำคัญที่สุด: เราหยุดการสูญเสียข้อมูล
เอาเป็นว่าเราหยุดแล้วกัน อาจ สูญเสียข้อมูลเพราะเราไม่ได้สูญเสียมันไปจริงๆ แต่ก็มีอันตราย เราเห็นว่าวิธีแก้ปัญหานี้แน่นอนว่าดี แต่ก็เหมือนกับการทำให้อาการของปัญหาราบรื่นขึ้น แทนที่จะแก้ปัญหาทั้งหมด และปัญหาบางอย่างยังคงอยู่ที่นี่
ประการแรก นี่คือจุดของความล้มเหลวในรูปแบบของโฮสต์ทางกายภาพซึ่งเครื่องจักรทั้งหมดนี้ทำงานอยู่ และไม่ได้หายไปไหน
ประการที่สอง ยังคงมีปัญหากับ SAN การบำรุงรักษาอย่างหนัก ฯลฯ ยังคงอยู่ ไม่ใช่ว่ามันเป็นปัจจัยสำคัญ แต่ฉันอยากจะพยายามใช้ชีวิตโดยปราศจากมัน
และเราได้สร้างเวอร์ชันที่สาม (อันที่จริง เวอร์ชันที่สอง) - เวอร์ชันจอง มันดูเหมือนอะไร?
นี่คือสิ่งที่มันเป็น -
ปัญหาหลักของเราอยู่ที่ความจริงที่ว่านี่คือโฮสต์จริง
ประการแรก เรากำลังลบ SAN เนื่องจากเราต้องการทดลอง เราต้องการลองใช้เพียงฮาร์ดไดรฟ์ในเครื่อง
นี่เป็นปี 2014-2015 แล้วและในเวลานั้นสถานการณ์ของดิสก์และความจุในโฮสต์เดียวก็ดีขึ้นมาก เราตัดสินใจว่าทำไมไม่ลอง
จากนั้นเราก็นำพาร์ติชั่นสำรองของเราแล้วถ่ายโอนไปยังเครื่องอื่น
ดังนั้นเราจึงได้แผนภาพนี้ เรามีรถสองคันที่เก็บชุดข้อมูลเดียวกัน พวกเขาสำรองข้อมูลซึ่งกันและกันอย่างสมบูรณ์และซิงโครไนซ์ข้อมูลผ่านเครือข่ายผ่านคิวอะซิงโครนัสใน MySQL เดียวกัน
เหตุใดจึงได้ผลดีเนื่องจากเรามีบันทึกน้อย เหล่านั้น. ถ้าการเขียนเปรียบได้กับการอ่าน บางทีเราอาจมีค่าใช้จ่ายและปัญหาเครือข่ายบางอย่าง มีการเขียนน้อยอ่านมาก - วิธีนี้ใช้ได้ผลดีเช่น เราไม่ค่อยคัดลอกรูปภาพระหว่างเซิร์ฟเวอร์ทั้งสองนี้
วิธีนี้ทำงานอย่างไรหากคุณดูรายละเอียดเพิ่มเติมอีกเล็กน้อย
ที่อัพโหลด. บาลานเซอร์เพียงเลือกโฮสต์แบบสุ่มด้วยคู่แล้วอัปโหลดไปที่โฮสต์นั้น ในขณะเดียวกัน เขาก็ตรวจสุขภาพตามปกติและดูแลไม่ให้รถล้ม เหล่านั้น. เขาอัปโหลดรูปภาพไปยังเซิร์ฟเวอร์ที่ใช้งานจริงเท่านั้น จากนั้นผ่านคิวแบบอะซิงโครนัส รูปภาพทั้งหมดจะถูกคัดลอกไปยังเพื่อนบ้านของเขา ด้วยการอัปโหลดทุกอย่างก็ง่ายมาก
งานจะยากขึ้นเล็กน้อย
Lua ช่วยเราที่นี่ เพราะมันอาจเป็นเรื่องยากที่จะสร้างตรรกะดังกล่าวใน vanilla NGINX ก่อนอื่นเราทำการร้องขอไปยังเซิร์ฟเวอร์แรก ดูว่ารูปถ่ายอยู่ที่นั่นหรือไม่ เนื่องจากอาจอัปโหลดไปยังเพื่อนบ้านได้ แต่ยังมาไม่ถึงที่นี่ ถ้ามีรูปก็ดีครับ เรามอบมันให้กับลูกค้าทันทีและอาจแคชไว้ด้วย
หากไม่มีอยู่ เราก็ส่งคำขอไปยังเพื่อนบ้านของเราและรับประกันว่าจะได้รับจากที่นั่น
ที่. อีกครั้งที่เราสามารถพูดได้: อาจมีปัญหากับประสิทธิภาพเนื่องจากมีการเดินทางไปกลับอย่างต่อเนื่อง - อัปโหลดรูปภาพแล้ว มันไม่ได้อยู่ที่นี่ เรากำลังส่งคำขอสองรายการแทนที่จะเป็นคำขอเดียว ซึ่งควรจะทำงานช้า
ในสถานการณ์ของเรา สิ่งนี้ไม่ได้ทำงานช้า
เรารวบรวมเมตริกจำนวนมากบนระบบนี้ และอัตราอัจฉริยะแบบมีเงื่อนไขของกลไกดังกล่าวคือประมาณ 95% เหล่านั้น. ความล่าช้าของการสำรองข้อมูลนี้มีน้อย และด้วยเหตุนี้เราจึงเกือบจะรับประกันได้ หลังจากที่อัปโหลดรูปภาพแล้ว เราจะถ่ายในครั้งแรกและจะไม่ต้องไปไหนอีกสองครั้ง
แล้วเรามีอะไรอีกบ้างที่เจ๋งจริงๆ?
ก่อนหน้านี้ เรามีพาร์ติชั่นสำรองหลัก และเราอ่านจากพาร์ติชั่นเหล่านั้นตามลำดับ เหล่านั้น. เราค้นหาอันหลักก่อนเสมอแล้วจึงค้นหาข้อมูลสำรอง มันเป็นการเคลื่อนไหวครั้งหนึ่ง
ตอนนี้เราใช้การอ่านจากสองเครื่องพร้อมกัน เราแจกจ่ายคำขอโดยใช้ Round Robin ในกรณีเล็กๆ น้อยๆ เราส่งคำขอสองครั้ง แต่โดยรวมแล้ว ตอนนี้เรามีสต็อกการอ่านเพิ่มขึ้นสองเท่าจากเมื่อก่อน และโหลดก็ลดลงอย่างมากทั้งบนเครื่องส่งและบนเครื่องจัดเก็บโดยตรงซึ่งเรามีในขณะนั้นด้วย
ในเรื่องการยอมรับความผิด จริงๆ แล้วนี่คือสิ่งที่เราต่อสู้เพื่อเป็นหลัก ด้วยการทนต่อความผิดพลาด ทุกอย่างจึงออกมาดีที่นี่
รถคันหนึ่งเสีย.
ไม่มีปัญหา! วิศวกรระบบอาจไม่ตื่นตอนกลางคืนด้วยซ้ำ เขาจะรอจนถึงเช้า ไม่มีอะไรเลวร้ายเกิดขึ้น
แม้ว่าเครื่องนี้จะล้มเหลว คิวก็ไม่เป็นระเบียบ ไม่มีปัญหาใดๆ เช่นกัน บันทึกจะถูกสะสมไว้บนเครื่องที่มีชีวิตก่อน จากนั้นจึงจะถูกเพิ่มเข้าไปในคิว จากนั้นจึงต่อไปยังรถที่จะ เริ่มดำเนินการหลังจากผ่านไประยะหนึ่ง
สิ่งเดียวกันกับการบำรุงรักษา เราเพียงแค่ปิดเครื่องเครื่องใดเครื่องหนึ่ง ดึงเครื่องออกจากพูลทั้งหมดด้วยตนเอง เครื่องหยุดรับการรับส่งข้อมูล เราทำการบำรุงรักษาบางประเภท แก้ไขบางอย่าง จากนั้นเราส่งคืนสู่การบริการ และการสำรองข้อมูลนี้ติดตามได้ค่อนข้างเร็ว เหล่านั้น. ต่อวัน เวลาหยุดทำงานของรถคันหนึ่งเกิดขึ้นภายในไม่กี่นาที นี่น้อยมากจริงๆ ฉันพูดอีกครั้งว่าทุกอย่างยอดเยี่ยมที่นี่ด้วยความทนทานต่อข้อผิดพลาด
ได้ข้อสรุปอะไรจากโครงการความซ้ำซ้อนนี้?
เรามีความอดทนต่อความผิดพลาด
ง่ายต่อการใช้. เนื่องจากเครื่องจักรมีฮาร์ดไดรฟ์ในตัวเครื่อง จึงสะดวกกว่ามากจากมุมมองของการปฏิบัติงานสำหรับวิศวกรที่ทำงานร่วมกับเครื่องดังกล่าว
เราได้รับค่าเผื่อการอ่านสองเท่า
นี่เป็นโบนัสที่ดีมากนอกเหนือจากความทนทานต่อข้อผิดพลาด
แต่ยังมีปัญหาอยู่ ตอนนี้เรามีการพัฒนาฟีเจอร์บางอย่างที่เกี่ยวข้องกับเรื่องนี้ที่ซับซ้อนมากขึ้น เนื่องจากระบบมีความสอดคล้องกัน 100% ในที่สุด
ในงานเบื้องหลังบางงาน เราต้องคิดอยู่เสมอว่า "ตอนนี้เรากำลังใช้งานเซิร์ฟเวอร์ใดอยู่" "มีรูปถ่ายปัจจุบันที่นี่จริงหรือ" ฯลฯ แน่นอนว่าทั้งหมดนี้เสร็จสิ้นแล้ว และสำหรับโปรแกรมเมอร์ที่เขียนตรรกะทางธุรกิจ มันก็มีความโปร่งใส แต่ถึงกระนั้น ชั้นที่ซับซ้อนขนาดใหญ่นี้ก็ปรากฏขึ้น แต่เราพร้อมที่จะทนกับสิ่งนี้เพื่อแลกกับสารพัดที่เราได้รับจากมัน
และความขัดแย้งก็เกิดขึ้นอีกครั้ง
ฉันบอกไปแล้วในตอนแรกว่าการจัดเก็บทุกอย่างไว้ในฮาร์ดไดรฟ์ในเครื่องนั้นไม่ดี และตอนนี้ฉันบอกว่าเราชอบมัน
ใช่ เมื่อเวลาผ่านไป สถานการณ์เปลี่ยนแปลงไปมาก และตอนนี้แนวทางนี้มีข้อดีหลายประการ ประการแรก เราได้รับการดำเนินการที่ง่ายกว่ามาก
ประการที่สอง มีประสิทธิผลมากกว่า เนื่องจากเราไม่มีตัวควบคุมอัตโนมัติหรือการเชื่อมต่อกับชั้นวางดิสก์
มีเครื่องจักรจำนวนมากอยู่ที่นั่น และนี่เป็นเพียงดิสก์เพียงไม่กี่แผ่นเท่านั้น ที่รวมตัวกันบนเครื่องเพื่อการโจมตี
แต่ก็มีข้อเสียอยู่เช่นกัน
ซึ่งมีราคาแพงกว่าการใช้ SAN ประมาณ 1,5 เท่า แม้ในราคาปัจจุบันก็ตาม ดังนั้นเราจึงตัดสินใจที่จะไม่แปลงคลัสเตอร์ขนาดใหญ่ทั้งหมดของเราให้เป็นรถยนต์ที่มีฮาร์ดไดรฟ์ในเครื่องอย่างกล้าหาญ และตัดสินใจทิ้งโซลูชันแบบไฮบริดไว้
เครื่องของเราครึ่งหนึ่งใช้งานได้กับฮาร์ดไดรฟ์ (ไม่ใช่ครึ่งหนึ่ง - อาจจะ 30 เปอร์เซ็นต์) และที่เหลือเป็นรถเก่าที่เคยจองครั้งแรก เราเพียงแค่ติดตั้งใหม่ เนื่องจากเราไม่ต้องการข้อมูลใหม่หรือสิ่งอื่นใด เราเพียงแค่ย้ายการเมานต์จากโฮสต์จริงหนึ่งไปยังสองโฮสต์
และตอนนี้เรามีสต็อกหนังสือจำนวนมาก และเราได้ขยายมันออกไป หากก่อนหน้านี้เราติดตั้งที่เก็บข้อมูลหนึ่งอันบนเครื่องหนึ่งเครื่อง ตอนนี้เราติดตั้งสี่อันในหนึ่งคู่ และมันก็ใช้ได้ดี
เรามาสรุปโดยย่อเกี่ยวกับสิ่งที่เราทำสำเร็จ สิ่งที่เราต่อสู้เพื่อ และเราประสบความสำเร็จหรือไม่
ผลของการ
เรามีผู้ใช้ - มากถึง 33 ล้านคน
เรามีจุดให้บริการสามจุด ได้แก่ ปราก ไมอามี ฮ่องกง
ประกอบด้วยเลเยอร์แคชซึ่งประกอบด้วยรถยนต์ที่มี Fast Local Disk (SSD) ซึ่งมีกลไกง่ายๆ จาก NGINX, access.log และ Python daemons ทำงาน ซึ่งประมวลผลทั้งหมดนี้และจัดการแคช
หากคุณต้องการ คุณจะอยู่ในโปรเจ็กต์ของคุณ หากรูปภาพไม่สำคัญสำหรับคุณเท่ากับสำหรับเรา หรือหากการควบคุมการแลกเปลี่ยนกับความเร็วในการพัฒนาและต้นทุนทรัพยากรเป็นไปในทิศทางอื่นสำหรับคุณ คุณสามารถเปลี่ยนใหม่ได้อย่างปลอดภัย ด้วย CDN CDN สมัยใหม่ก็ทำได้ดี
ถัดมาคือชั้นพื้นที่จัดเก็บข้อมูล ซึ่งเรามีกลุ่มเครื่องคู่ที่สำรองข้อมูลซึ่งกันและกัน ไฟล์ต่างๆ จะถูกคัดลอกแบบอะซิงโครนัสจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่งทุกครั้งที่มีการเปลี่ยนแปลง
นอกจากนี้ เครื่องเหล่านี้บางเครื่องยังใช้งานได้กับฮาร์ดไดรฟ์ในเครื่องอีกด้วย
เครื่องเหล่านี้บางเครื่องเชื่อมต่อกับ SAN
และในอีกด้านหนึ่งสะดวกกว่าในการใช้งานและมีประสิทธิภาพมากกว่าเล็กน้อยในทางกลับกันสะดวกในแง่ของความหนาแน่นของตำแหน่งและราคาต่อกิกะไบต์
นี่เป็นภาพรวมโดยย่อของสถาปัตยกรรมของสิ่งที่เราได้รับและวิธีการพัฒนาทั้งหมด
คำแนะนำเพิ่มเติมจากกัปตัน คำแนะนำง่ายๆ บางประการ
ขั้นแรก หากคุณตัดสินใจว่าจำเป็นต้องปรับปรุงทุกอย่างในโครงสร้างพื้นฐานของภาพถ่ายอย่างเร่งด่วน ให้วัดผลก่อน เพราะอาจไม่มีอะไรต้องปรับปรุง
ผมขอยกตัวอย่างให้คุณฟัง เรามีกลุ่มเครื่องที่ส่งรูปภาพจากไฟล์แนบในการแชท และโครงการนี้ดำเนินการที่นั่นมาตั้งแต่ปี 2009 และไม่มีใครประสบปัญหาดังกล่าว ทุกคนสบายดี ทุกคนชอบทุกอย่าง
ในการวัดผล ขั้นแรกให้แขวนเมตริกไว้เป็นกลุ่มก่อน แล้วดูที่เมตริกเหล่านั้น จากนั้นจึงตัดสินใจว่าคุณไม่พอใจกับสิ่งใดและสิ่งใดที่ต้องปรับปรุง เพื่อวัดสิ่งนี้ เรามีเครื่องมือเจ๋งๆ ที่เรียกว่า Pinba
ช่วยให้คุณสามารถรวบรวมสถิติโดยละเอียดจาก NGINX สำหรับแต่ละคำขอและรหัสตอบกลับ และการกระจายเวลา - ตามที่คุณต้องการ มันมีการเชื่อมโยงกับระบบการวิเคราะห์ที่แตกต่างกันทุกประเภท และคุณจึงสามารถดูมันทั้งหมดได้อย่างสวยงาม
ขั้นแรกเราวัดมัน จากนั้นเราปรับปรุงมัน
ไกลออกไป. เราเพิ่มประสิทธิภาพการอ่านด้วยแคช การเขียนด้วยการแบ่งส่วน แต่นี่คือจุดที่ชัดเจน
ไกลออกไป. หากคุณเพิ่งเริ่มสร้างระบบของคุณ จะดีกว่ามากถ้าสร้างรูปภาพเป็นไฟล์ที่ไม่เปลี่ยนรูป เพราะคุณจะสูญเสียปัญหาทั้งคลาสทันทีเกี่ยวกับการทำให้แคชใช้ไม่ได้ รวมถึงวิธีที่ตรรกะควรค้นหาเวอร์ชันที่ถูกต้องของรูปถ่ายและอื่น ๆ
สมมติว่าคุณอัปโหลดไปแล้วร้อยครั้ง จากนั้นจึงหมุนเวียน ทำให้เป็นไฟล์ที่แตกต่างออกไป เหล่านั้น. ไม่ต้องคิด: ตอนนี้ฉันจะประหยัดพื้นที่นิดหน่อย เขียนลงในไฟล์เดียวกัน เปลี่ยนเวอร์ชัน สิ่งนี้ไม่ได้ผลดีเสมอไปและทำให้เกิดอาการปวดหัวมากในภายหลัง
จุดต่อไป. เกี่ยวกับการปรับขนาดได้ทันที
ก่อนหน้านี้ เมื่อผู้ใช้อัปโหลดรูปภาพ เราจะตัดขนาดทั้งหมดทันทีสำหรับทุกโอกาส สำหรับลูกค้าที่แตกต่างกัน และขนาดทั้งหมดก็อยู่ในดิสก์ ตอนนี้เราได้ละทิ้งสิ่งนี้แล้ว
เราเหลือเพียงสามขนาดหลัก: เล็ก กลาง และใหญ่ เราเพียงลดขนาดสิ่งอื่นๆ จากขนาดที่อยู่เบื้องหลังขนาดที่ Uport ถามเรา เราเพียงแค่ลดขนาดและมอบให้กับผู้ใช้
CPU ของเลเยอร์แคชที่นี่จะมีราคาถูกกว่าการที่เราสร้างขนาดเหล่านี้ใหม่อย่างต่อเนื่องในแต่ละพื้นที่จัดเก็บข้อมูล สมมติว่าเราต้องการเพิ่มอันใหม่ ซึ่งจะใช้เวลาหนึ่งเดือน - รันสคริปต์ทุกที่ที่จะทำทั้งหมดนี้อย่างเรียบร้อย โดยไม่ทำลายคลัสเตอร์ เหล่านั้น. หากคุณมีโอกาสเลือกตอนนี้ จะดีกว่าถ้าสร้างขนาดทางกายภาพให้น้อยที่สุดเท่าที่จะเป็นไปได้ แต่เพื่อให้การกระจายบางส่วนเป็นสามขนาด และทุกสิ่งทุกอย่างสามารถปรับขนาดได้ทันทีโดยใช้โมดูลสำเร็จรูป ตอนนี้ทุกอย่างเป็นเรื่องง่ายและเข้าถึงได้
และการสำรองข้อมูลแบบอะซิงโครนัสแบบเพิ่มหน่วยก็ดี
ดังที่แนวทางปฏิบัติของเราแสดงให้เห็นแล้วว่า รูปแบบนี้ใช้งานได้ดีกับการคัดลอกไฟล์ที่เปลี่ยนแปลงล่าช้า
จุดสุดท้ายก็ชัดเจนเช่นกัน หากโครงสร้างพื้นฐานของคุณไม่มีปัญหาดังกล่าวในตอนนี้ แต่มีบางอย่างที่สามารถพังได้ มันจะพังอย่างแน่นอนเมื่อมันเพิ่มขึ้นอีกเล็กน้อย ดังนั้นจึงเป็นการดีกว่าที่จะคิดเรื่องนี้ล่วงหน้าและไม่มีปัญหากับมัน นั่นคือทั้งหมดที่ฉันอยากจะพูด
รายชื่อผู้ติดต่อ
»
»
รายงานนี้เป็นสำเนาสุนทรพจน์ที่ดีที่สุดในการประชุมนักพัฒนาระบบที่มีภาระงานสูง . เหลือเวลาอีกไม่ถึงหนึ่งเดือนก็จะถึงการประชุม HighLoad++ 2017
เรามีพร้อมอยู่แล้ว ขณะนี้กำหนดการกำลังถูกจัดทำขึ้นอย่างแข็งขัน
ปีนี้เรายังคงสำรวจหัวข้อสถาปัตยกรรมและการปรับขนาดต่อไป:
- / อิกอร์ วาซิลีฟ
- / มิทรี เอโกรอฟ
- / อนาโตลี พลาสคอฟสกี้
- / โรมัน เชคอฟต์ซอฟ, อเล็กเซย์ โกรมัทชิคอฟ
- / ฟิลิป เดลกาโด
เรายังใช้สื่อเหล่านี้บางส่วนในหลักสูตรการฝึกอบรมออนไลน์ของเราเกี่ยวกับการพัฒนาระบบที่มีภาระงานสูง เป็นห่วงโซ่ของตัวอักษร บทความ สื่อ วิดีโอที่คัดสรรมาเป็นพิเศษ หนังสือเรียนของเรามีสื่อการสอนที่มีเอกลักษณ์มากกว่า 30 รายการอยู่แล้ว เชื่อมต่อ!
ที่มา: will.com