Netflix เพิ่งเผยรายละเอียดเกี่ยวกับการปรับปรุงสถาปัตยกรรมของ Tudum เว็บไซต์แฟนคลับของพวกเขา โดยเปลี่ยนจากระบบ CQRS มาใช้ระบบจัดเก็บข้อมูลในหน่วยความจำที่เรียกว่า RAW Hollow แม้ว่าบริษัทจะนำเสนอเรื่องนี้เป็นเรื่องราวความสำเร็จทางเทคนิค แต่ชุมชนวิศวกรกลับตอบสนองด้วยการวิพากษ์วิจารณ์อย่างกว้างขวาง โดยตั้งคำถามว่าความซับซ้อนเช่นนี้สมเหตุสมผลหรือไม่สำหรับสิ่งที่หลายคนมองว่าเป็นเพียงเว็บไซต์บล็อกธรรมดา
ความไม่สมดุลระหว่างขนาดปัญหากับความซับซ้อน
ประเด็นที่โดดเด่นที่สุดของการถกเถียงครั้งนี้คือความแตกต่างอย่างมากระหว่างขนาดของปัญหากับความซับซ้อนของวิธีแก้ไข สมาชิกในชุมชนชี้ให้เห็นอย่างรวดเร็วว่าข้อมูลทั้งหมดของ Tudum รวมถึงเนื้อหาสามปีที่ผ่านมา เมื่อบีบอัดแล้วมีขนาดเพียง 130MB เท่านั้น ขนาดข้อมูลที่เล็กนิดเดียวนี้ทำให้หลายคนตั้งคำถามว่าทำไม Netflix ถึงใช้ระบบกระจายระดับองค์กร รวมถึง Kafka, Cassandra และฐานข้อมูลในหน่วยความจำแบบกำหนดเองสำหรับข้อมูลที่มีขนาดน้อยกว่าแอปสมาร์ทโฟนทั่วไป
นักพัฒนาหลายคนสังเกตว่าโปรเซสเซอร์สมัยใหม่มีขนาดแคชที่ใกล้เคียงกับปริมาณข้อมูลนี้ ทำให้การเลือกใช้โครงสร้างพื้นฐานดูเกินความจำเป็นเป็นพิเศษ ความเห็นพ้องของชุมชนชี้ว่าวิธีแก้ไขแบบดั้งเดิมอย่าง PostgreSQL พร้อม read replicas หรือแม้แต่การสร้างเว็บไซต์แบบสแตติก จะสามารถจัดการกับปริมาณงานนี้ได้โดยมีความซับซ้อนน้อยกว่ามาก
การเปรียบเทียบขนาดชุดข้อมูล Tudum
- ข้อมูลที่บีบอัด: 130MB (เนื้อหา 3 ปี)
- ขนาดที่ไม่บีบอัด: ~520MB
- บริบท: ขนาด L3 cache ของโปรเซสเซอร์ระดับไฮเอนด์เข้าใกล้ระดับนี้
- ผู้ใช้รายเดือน: 20 ล้านคน
ปัญหาการดูตัวอย่างที่เป็นจุดเริ่มต้นของทุกอย่าง
ปัญหาเดิมที่ Netflix ต้องการแก้ไขค่อนข้างธรรมดา นั่นคือบรรณาธิการเนื้อหาต้องรอหลายสิบวินาทีเพื่อดูตัวอย่างการเปลี่ยนแปลงเนื่องจากรอบการรีเฟรชแคช อย่างไรก็ตาม ชุมชนได้ระบุวิธีแก้ไขที่ง่ายกว่าหลายวิธีที่สามารถแก้ไขปัญหานี้ได้โดยไม่ต้องปรับปรุงสถาปัตยกรรม ข้อเสนอแนะรวมถึงการสร้างสภาพแวดล้อมตัวอย่างเฉพาะที่ปิดการใช้แคช การใช้เทคนิค cache-busting ด้วย content hash หรือเพียงแค่สร้างระบบ CMS แบบ local-first
วิธีแก้ไขทั่วไปคือการสร้าง DNS hostname เฉพาะที่เรียกว่า 'preview.www.netflix.com' และปิดการแคชทั้งหมดเมื่อผู้ใช้เข้าผ่านเส้นทางนั้น บรรณาธิการและผู้ตรวจสอบใช้เส้นทางนั้น และนั่นคือ... เสร็จแล้ว!
ความรู้สึกนี้สะท้อนความหงุดหงิดของชุมชนต่อสิ่งที่พวกเขามองว่าเป็นวิธีแก้ไขทางวิศวกรรมสำหรับปัญหาองค์กรที่สามารถแก้ไขได้ด้วยการเปลี่ยนแปลงการดำเนินงานที่ง่ายกว่า
คอมโพเนนต์สถาปัตยกรรมที่ถูกเปลี่ยนแปลง
- ระบบเดิม: CQRS กับ Kafka + Cassandra + Near Cache
- ระบบใหม่: RAW Hollow in-memory object store
- ปัญหาที่ได้รับการแก้ไข: ความล่าช้าในการรีเฟรช cache (หลายสิบวินาที)
- ทางเลือกอื่นที่แนะนำ: preview environments, cache-busting, static site generation
ข้อกล่าวหาเรื่องการพัฒนาเพื่อประวัติย่อ
การวิพากษ์วิจารณ์ที่รุนแรงที่สุดมุ่งเป้าไปที่ข้อกล่าวหาเรื่องการพัฒนาเพื่อประวัติย่อ ซึ่งเป็นการปฏิบัติที่เลือกใช้เทคโนโลยีที่ซับซ้อนเพื่อเสริมสร้างโอกาสในการทำงานมากกว่าการแก้ไขปัญหาทางธุรกิจอย่างมีประสิทธิภาพ สมาชิกในชุมชนเสนอว่าการมีวิศวกรที่มีความสามารถมากกว่า 20 คนทำงานกับสิ่งที่เป็นบล็อกของบริษัทโดยพื้นฐานย่อมนำไปสู่การใช้วิศวกรรมเกินความจำเป็น เนื่องจากทีมต้องการพิสูจน์การมีอยู่ของตนเองและสร้างโครงการที่คู่ควรกับการเลื่อนตำแหน่ง
การอภิปรายเผยให้เห็นความกังวลในวงการที่กว้างขึ้นเกี่ยวกับวิธีที่เมตริกการเลื่อนตำแหน่งและอีโก้ของวิศวกรสามารถขับเคลื่อนความซับซ้อนที่ไม่จำเป็น ผู้แสดงความคิดเห็นหลายคนสังเกตว่าตำแหน่งที่ทำกำไรได้ของ Netflix ช่วยให้พวกเขาสามารถรับต้นทุนของการทดลองเช่นนี้ได้ แต่เตือนสตาร์ทอัปไม่ให้คัดลอกรูปแบบสถาปัตยกรรมเหล่านี้โดยไม่มีทรัพยากรที่คล้ายกันหรือความต้องการที่แท้จริง
ประเด็นการวิจารณ์จากชุมชน
- การพัฒนาที่ซับซ้อนเกินไปสำหรับฟังก์ชันบล็อกธรรมดา
- ข้อกล่าวหาเรื่องการพัฒนาเพื่อประวัติ
- พฤติกรรมนักสถาปัตยกรรมอวกาศ
- ความไม่สอดคล้องระหว่างขนาดปัญหาและความซับซ้อนของโซลูชัน
- มีทางเลือกที่ง่ายกว่าพร้อมใช้งาน
นักบินอวกาศสถาปัตยกรรมทางเทคนิค
ชุมชนวิพากษ์วิจารณ์เป็นพิเศษต่อสิ่งที่พวกเขาเรียกว่าพฤติกรรมนักบินอวกาศสถาปัตยกรรม นั่นคือวิศวกรที่สร้างระบบซับซ้อนเพื่อความซับซ้อนมากกว่าคุณค่าทางธุรกิจ นักวิจารณ์ชี้ให้เห็นว่าเว็บไซต์ Tudum ทั้งหมดน่าจะสามารถให้บริการได้ด้วยฐานข้อมูลเดียวกับการแคชแบบดั้งเดิม หรือแม้แต่สร้างเป็นไฟล์สแตติก
ผู้แสดงความคิดเห็นไม่พลาดที่จะสังเกตความขัดแย้งที่ Netflix บริษัทที่รู้จักในฐานะผู้บุกเบิกสถาปัตยกรรมไมโครเซอร์วิส ยังคงใช้วิธีแก้ไขระดับองค์กรกับปัญหาที่ไม่จำเป็นต้องใช้ความซับซ้อนเช่นนั้น บางคนสังเกตว่าแม้แต่ฟอรัมอภิปรายนี้ก็จัดการกับการแก้ไข การปรับแต่งส่วนบุคคล และการอัปเดตแบบเรียลไทม์ได้โดยไม่ต้องใช้ CQRS, Kafka หรือฐานข้อมูลกระจายแบบกำหนดเอง
บทเรียนสำหรับอุตสาหกรรม
การถกเถียงครั้งนี้เน้นย้ำคำถามสำคัญเกี่ยวกับการเลือกใช้เทคโนโลยีที่เหมาะสมในการพัฒนาซอฟต์แวร์ แม้ว่าทีมวิศวกรของ Netflix จะมีความเชี่ยวชาญอย่างไม่ต้องสงสัย แต่การตอบสนองของชุมชนชี้ให้เห็นว่าความสามารถทางเทคนิคไม่ได้แปลเป็นแนวทางการแก้ปัญหาที่เหมาะสมเสมอไป
การถกเถียงนี้เป็นเครื่องเตือนใจว่าการตัดสินใจทางวิศวกรรมควรขับเคลื่อนด้วยความต้องการที่แท้จริงมากกว่าเทคโนโลยีที่มีอยู่หรือความชอบของทีม สำหรับองค์กรส่วนใหญ่ที่เผชิญกับความท้าทายในการจัดการเนื้อหาที่คล้ายกน ความเห็นพ้องของชุมชนชี้ไปที่วิธีแก้ไขที่ง่ายกว่ามากที่จะให้ผลลัพธ์ที่ดีกว่าด้วยค่าใช้จ่ายในการบำรุงรักษาที่ต่ำกว่าและรอบการพัฒนาที่เร็วกว่า
อ้างอิง: Netflix Revamps Tudum's CQRS Architecture with RAW Hollow In-Memory Object Store