Slack ย้ายไปสู่สถาปัตยกรรมแบบ Cellular

 (slack.engineering)
5 คะแนน โดย GN⁺ 2023-08-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วง 1.5 ปีที่ผ่านมา Slack ได้เปลี่ยนจากโครงสร้างแบบเดี่ยวไปเป็นโครงสร้างแบบเซลล์ (Cellular Architecture) เพื่อเพิ่มความซ้ำซ้อน (Redundancy) และจำกัดผลกระทบของความล้มเหลวระดับไซต์
  • การเปลี่ยนแปลงนี้ขับเคลื่อนโดยความจำเป็นในการเพิ่มความยืดหยุ่นของบริการ Slack หลังเหตุขัดข้องของเครือข่ายในเดือนมิถุนายน 2021 ที่ทำให้ลูกค้า Slack พบกับการให้บริการที่ด้อยลง
  • โครงสร้างแบบเซลลูลาร์ทำให้แต่ละบริการทำงานเป็นบริการเสมือนหนึ่งชุดต่อหนึ่ง Availability Zone (AZ) จึงทำให้ความล้มเหลวใน AZ หนึ่งไม่ส่งผลกระทบต่อ AZ อื่น
  • ยังมีความสามารถในการระบายทราฟฟิก (Drain) ออกจาก AZ ที่มีปัญหา เพื่อแยก AZ นั้นออกจากส่วนที่เหลือของระบบได้อย่างมีประสิทธิภาพ
  • กลไกการระบายถูกออกแบบให้รวดเร็ว ไม่มีข้อผิดพลาด ทำงานแบบค่อยเป็นค่อยไป และเป็นอิสระจากทรัพยากรของ AZ ที่กำลังถูกระบาย
  • การเปลี่ยนไปใช้โครงสร้างแบบเซลลูลาร์ยังรวมถึงกลยุทธ์ที่เรียกว่า Siloing ซึ่งทำให้บริการรับและส่งทราฟฟิกเฉพาะภายใน AZ ของตัวเอง ช่วยกักปัญหาความล้มเหลวทั้งหมดให้อยู่ภายใน AZ เดียว
  • การใช้งานกลไกการย้ายทราฟฟิกมุ่งเน้นไปที่ระบบที่ทำหน้าที่กำหนดเส้นทางคำขอของผู้ใช้ไปยังบริการแกนหลัก
  • สถาปัตยกรรมใหม่นี้ใช้ความสามารถของ Envoy อย่าง weighted clusters และการกำหนดค่าน้ำหนักแบบไดนามิกผ่าน RTDS เพื่อรองรับการระบาย AZ
  • การเปลี่ยนแปลงนี้ได้เปลี่ยนทั้งวิธีการปฏิบัติการของ Slack และวิธีการสร้างบริการ พร้อมมอบเครื่องมือใหม่ที่ทรงพลังสำหรับการจัดการทราฟฟิกและการบรรเทาความล้มเหลว
  • ในบล็อกโพสต์ถัดไป จะเจาะลึกรายละเอียดด้านการติดตั้งใช้งานเชิงเทคนิค และพูดคุยว่าสถาปัตยกรรมใหม่นี้ส่งผลต่อการดำเนินงานของ Slack อย่างไร

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-08-27
ความคิดเห็นจาก Hacker News
  • การย้ายของ Slack ไปสู่สถาปัตยกรรมแบบเซลลูลาร์ได้รับความสนใจเนื่องจากแนวทางด้านการปฏิบัติการและการมอนิเตอร์ที่เป็นเอกลักษณ์ของพวกเขา
  • กลยุทธ์ของบริษัทคือจัดการคำขอภายใน AWS Availability Zone (AZ) เดียว เพื่อทำให้การปฏิบัติการง่ายขึ้นและเอื้อต่อการมอนิเตอร์
  • แนวทางนี้ทำให้สามารถตรวจจับและบรรเทาเหตุการณ์ที่เกิดขึ้นในคลัสเตอร์เดียวได้ง่าย โดยการเปรียบเทียบเมตริกระหว่างคลัสเตอร์
  • อย่างไรก็ตาม กลยุทธ์นี้ทำให้เกิดความซ้ำซ้อนในด้านคอมพิวต์ แคช และส่วนอื่น ๆ เนื่องจากบริการส่วนใหญ่ต้องรันอยู่บนหลายคลัสเตอร์
  • ผู้ใช้บางคนตั้งคำถามถึงประสิทธิภาพของระบบคำขอ API ของ Slack ซึ่งอาจ fan-out ไปเป็น RPC หลายร้อยรายการสู่เซอร์วิสแบ็กเอนด์
  • มีการถกเถียงกันถึงความแตกต่างระหว่างการใช้ AWS Availability Zone affinity กับการดรอป AZ ที่ล่มทิ้งไปตรงจุด routing ชั้นบนสุดแบบง่าย ๆ
  • มีความกังวลเกี่ยวกับความซ้ำซ้อนของการรันทุกอย่างบน AWS USE1 เพราะปัญหาที่เกี่ยวข้องกับ USE1 อาจส่งผลกระทบต่อหลายบริการ
  • มีการตั้งคำถามว่าข้อมูลผู้ใช้ถูกจัดการอย่างไรในสถาปัตยกรรมนี้ โดยเฉพาะเมื่อเกิดการคูณจำนวน AZ
  • ผู้ใช้บางคนหวนระลึกถึงสถาปัตยกรรมคล้ายกันที่เคยทำงานด้วยในอดีต เช่น ระบบปฏิบัติการแบบกระจายที่ชื่อว่า Metal Cell
  • มีการพูดคุยถึงปัญหาความเป็นไปได้ที่งานซึ่งใช้ทรัพยากรมากอาจรันต่อไปอย่างไม่สิ้นสุดใน AZ ที่ถูกแยกออก แม้จะไม่มีคำขอใหม่จากผู้ใช้เข้ามาแล้วก็ตาม
  • ผู้ใช้สงสัยว่าในปัจจุบัน Slack เขียนด้วยภาษาโปรแกรมอะไร และถามว่ายังเป็น Hack/PHP อยู่หรือไม่
  • ผู้ใช้บางคนแสดงความผิดหวังต่อประสิทธิภาพของ Slack และเปรียบเทียบในทางเสียเปรียบกับแอปแชตอื่น ๆ เช่น Discord