Clubhouse ได้สร้างความฮือฮาในชุมชน observability ด้วยการละทิ้ง OpenTelemetry (OTel) framework ที่เป็นมาตรฐานอุตสาหกรรม และหันไปใช้โซลูชันการบันทึกข้อมูลแบบกำหนดเองแทน การเปลี่ยนแปลงนี้ช่วยให้พวกเขาบรรลุเป้าหมายที่ท้าทายในการประมวลผลข้อมูล observability ด้วยต้นทุนเพียง 500 ดอลลาร์สหรัฐต่อเพตะไบต์ ขณะที่จัดการข้อมูลที่บีบอัดแล้วกว่า 100 เพตะไบต์ต่อวัน
การตัดสินใจนี้ได้จุดประกายการถกเถียงอย่างรุนแรงในหมู่นักพัฒนาเกี่ยวกับความจำเป็นของการเก็บรวบรวมข้อมูลจำนวนมหาศาล หรือเป็นเพียงการสิ้นเปลืองทรัพยากร บริษัทตอนนี้ประมวลผลเหตุการณ์ 100 พันล้านรายการต่อวัน ทำให้เกิดคำถามเกี่ยวกับคุณค่าของการจัดเก็บข้อมูล log ในปริมาณมหาศาลเช่นนี้
เป้าหมายระดับการสังเกตการณ์ของ Clubhouse
| เมตริก | ระดับ | วันที่บรรลุเป้าหมาย |
|---|---|---|
| เหตุการณ์ต่อวัน | 100 พันล้าน | ตุลาคม 2023 |
| ข้อมูลที่รับเข้าต่อวัน (บีบอัด) | 100+ เพตะไบต์ | พฤศจิกายน 2023 |
| เป้าหมายประสิทธิภาพต้นทุน | $500 USD ต่อเพตะไบต์ | เป้าหมายปัจจุบัน |
| ต้นทุนการดำเนินงานรายวัน | ต่ำกว่า $50,000 USD | เป้าหมายปัจจุบัน |
การถกเถียงครั้งใหญ่เรื่องการบันทึกข้อมูล: เก็บทุกอย่างหรือเลือกสรร
ชุมชนแบ่งออกเป็นสองฝ่ายอย่างชัดเจนเกี่ยวกับแนวทางการเก็บรวบรวมข้อมูลของ Clubhouse ฝ่ายวิจารณ์โต้แย้งว่าการจัดเก็บ logs 100 เพตะไบต์แสดงถึงการตัดสินใจทางวิศวกรรมที่ไม่ดีมากกว่าความสำเร็จทางเทคนิค พวกเขาแนะว่าข้อมูลส่วนใหญ่นี้ประกอบด้วยข้อมูล debug ที่แทบไม่มีใครตรวจสอบ เว้นแต่ระบบ production จะประสบปัญหาร้ายแรง
การจัดเก็บ logs 100PB หมายความว่าเรายังไม่ได้คิดออกว่าอะไรคือสิ่งที่คุ้มค่าแก่การบันทึกจริงๆ metrics + structured events มักจะสามารถเล่าเรื่องได้ 90% แล้ว
อย่างไรก็ตาม ฝ่ายสนับสนุนโต้แย้งว่าการมีข้อมูลครอบคลุมทุกด้านเป็นสิ่งสำคัญสำหรับการ debug ปัญหาที่ไม่คาดคิด พวกเขาชี้ให้เห็นว่าการกรอง logs อย่างเข้มงวดเกินไปอาจทำให้วิศวกรไม่มีข้อมูลที่จำเป็นเมื่อต้องสืบสวนปัญหาซับซ้อนที่ไม่ได้คาดการณ์ไว้ตั้งแต่ระยะออกแบบการบันทึกข้อมูลเบื้องต้น
การถกเถียงนี้สะท้อนความตึงเครียดพื้นฐานในการพัฒนาซอฟต์แวร์สมัยใหม่ระหว่างการปรับปรุงต้นทุนและการมองเห็นการดำเนินงาน องค์กรบางแห่งชอบการบันทึกข้อมูลแบบเรียบง่ายพร้อมการคัดสรรอย่างระมัดระวัง ในขณะที่อื่นๆ ใช้แนวทางเก็บทุกอย่างแล้วกรองทีหลัง
สถาปัตยกรรมทางเทคนิค: การทำให้ Data Pipeline ง่ายขึ้น
โซลูชันทางเทคนิคของ Clubhouse เกี่ยวข้องกับการเอา collector layer ของ OpenTelemetry ออก ซึ่งพวกเขาพบว่าเพิ่มความซับซ้อนและ overhead ที่ไม่จำเป็น แทนที่จะเป็นเช่นนั้น พวกเขาใช้ pipeline โดยตรงด้วย FluentBit เพื่อส่งข้อมูล application logs ตรงเข้าไปใน ClickHouse ซึ่งเป็นฐานของฐานข้อมูลแบบ columnar
การเปลี่ยนแปลงสถาปัตยกรรมนี้ลดความต้องการในการประมวลผลลงอย่างมาก บริษัทรายงานว่าต้องการ CPU cores 8,000 ตัวเพื่อจัดการการประมวลผล JSON log ในการตั้งค่าเดิม เทียบกับเพียง 90 cores ด้วยแนวทางใหม่ pipeline ที่เรียบง่ายขจัดขั้นตอน serialization และ deserialization หลายขั้นตอนที่กินทรัพยากรการคำนวณอย่างมาก
ระบบใหม่ใช้ wide table schemas ใน ClickHouse ทำให้วิศวกรสามารถจัดเก็บข้อมูล event ที่หลากหลายในโครงสร้างตารางเดียว แนวทางนี้ช่วยให้ query เร็วขึ้นและสามารถเชื่อมโยงเหตุการณ์ที่เกี่ยวข้องได้ดีขึ้นระหว่างเซสชัน troubleshooting
การเปรียบเทียบสถาปัตยกรรมทางเทคนิค
การตั้งค่าเดิม (ใช้ OpenTelemetry):
- Container stdout → CRI-O/dockerd
- FluentBit จับข้อมูลและเสริมด้วย metadata ของ Kubernetes
- OTel collector ประมวลผลข้อมูลใน memory
- OTel ส่งข้อมูลที่แปลงแล้วไปยัง streaming backend
- ClickHouse รับและจัดเก็บข้อมูล
- ต้องการ: 8,000 CPU cores สำหรับการประมวลผล JSON
การตั้งค่าใหม่ (Custom Pipeline):
- ส่ง FluentBit ไปยัง ClickHouse streaming โดยตรง
- การจัดเส้นทาง event แบบ Lua-based ภายใน FluentBit
- โครงสร้างตารางแบบกว้างสำหรับการวิเคราะห์เฉพาะทาง
- ต้องการ: 90 CPU cores (ลดลง 99%)
การแลกเปลี่ยนระหว่างต้นทุนกับเวลาวิศวกรรม
ผลกระทบทางการเงินของแพลตฟอร์ม observability ได้กลายเป็นความกังวลหลักสำหรับทีมวิศวกรรม สมาชิกชุมชนหลายคนแบ่งปันประสบการณ์กับผู้ขายเช่น Datadog และ Splunk ที่การต่อสัญญามักจะกระตุ้นมาตรการลดต้นทุนอย่างรุนแรงที่อาจส่งผลเสียต่อการมองเห็นระบบ
องค์กรต่างๆ ถูกบังคับให้สร้างสมดุลระหว่างพฤติกรรมระบบที่สังเกตได้กับข้อจำกัดงงบประมาณมากขึ้น บริษัทบางแห่งจัดสรร 5-10% ของงบประมาณทั้งหมดให้กับการบันทึกข้อมูลและ observability โดยมองว่าเป็นการลงทุนโครงสร้างพื้นฐานที่จำเป็น บริษัทอื่นๆ ดิ้นรนที่จะปรับต้นทุนเหล่านี้ให้สมเหตุสมผล โดยเฉพาะเมื่อคุณค่าวัดได้ยากในเมตริกทางธุรกิจแบบดั้งเดิม
ความท้าทายจะซับซ้อนมากขึ้นเมื่อพิจารณาต้นทุนที่ซ่อนอยู่ของ observability ที่ไม่เพียงพอ วิศวกรอาจใช้เวลาหลายชั่วโมงหรือหลายวันในการสืบสวนปัญหาที่สามารถแก้ไขได้ในไม่กี่นาทีด้วยข้อมูล tracing และ logging ที่เหมาะสม อย่างไรก็ตาม การวัดผลกระทบต่อผลิตภาพนี้ยังคงเป็นเรื่องยากสำหรับองค์กรส่วนใหญ่
ประสิทธิภาพฐานข้อมูลในระดับใหญ่
บทบาทของ ClickHouse ในฐานะรากฐานการจัดเก็บได้ดึงดูดความสนใจอย่างมากจากชุมชน ผู้ใช้รายงานการปรับปรุงประสิทธิภาพอย่างมากเมื่อเทียบกับฐานข้อมูลแบบดั้งเดิม โดยบางคนประสบความเร็วเพิ่มขึ้น 50 เท่าสำหรับ analytical workloads ที่เกี่ยวข้องกับชุดข้อมูลขนาดใหญ่
อย่างไรก็ตาม ClickHouse มาพร้อมกับชุดความท้าทายของตัวเอง ฐานข้อมูลทำงานได้ดีที่สุดกับรูปแบบข้อมูลที่ไม่เปลี่ยนแปลงและ append-only ทำให้เหมาะสมน้อยกว่าสำหรับแอปพลิเคชันที่ต้องการการอัปเดตบ่อยครั้ง การพึ่งพาระบบประสานงานเช่น Zookeeper ยังแนะนำความซับซ้อนในการดำเนินงานที่ทีมบางทีมพบว่าเป็นภาระ
โมเดลการจัดเก็บแบบ columnar ของฐานข้อมูลเก่งในการจัดการ wide event schemas ที่ Clubhouse ใช้ ทำให้สามารถ query คอลัมน์ข้อมูลเฉพาะได้อย่างมีประสิทธิภาพโดยไม่ต้องสแกนชุดข้อมูลทั้งหมด ความสามารถนี้กลายเป็นสิ่งสำคัญเมื่อประมวลผลข้อมูลในระดับเพตะไบต์
ข้อพิจารณาด้านกฎระเบียบและความเป็นส่วนตัว
การอภิปรายยังเน้นความกังวลด้านกฎระเบียบที่สำคัญ โดยเฉพาะเกี่ยวกับการเก็บรักษาข้อมูลและการปฏิบัติตามกฎหมายความเป็นส่วนตัว กฎระเบียบ GDPR ของยุโรปจำกัดระยะเวลาที่องค์กรสามารถเก็บรักษา logs ที่อาจมีข้อมูลส่วนบุคคล โดยทั่วไปจำกัด logs การวิเคราะห์ข้อผิดพลาดทั่วไปไว้ประมาณหนึ่งเดือน
กรอบกฎระเบียบนี้บังคับให้บริษัทต่างๆ ใส่ใจมากขึ้นเกี่ยวกับข้อมูลที่พวกเขาเก็บรวบรวมและเก็บรักษาในระยะยาว องค์กรบางแห่งพบว่าการปฏิบัติตาม GDPR ปรับปรุงแนวปฏิบัติการบันทึกข้อมูลของพวกเขาโดยส่งเสริมกลยุทธ์การเก็บรวบรวมข้อมูลที่มีความคิดมากขึ้น
ความท้าทายคือการสร้างสมดุลระหว่างการมองเห็นระบบอย่างครอบคลุมกับความต้องการด้านความเป็นส่วนตัวและต้นทุนการจัดเก็บ แพลตฟอร์ม observability สมัยใหม่เริ่มเสนอโซลูชันการจัดเก็บแบบชั้นที่สามารถเก็บ logs รายละเอียดในที่เก็บถาวรขณะที่เก็บข้อมูลที่เข้าถึงบ่อยไว้ในชั้นการจัดเก็บที่เร็วกว่าและแพงกว่า
บทสรุป
การตัดสินใจของ Clubhouse ที่จะแทนที่ OpenTelemetry ด้วยโซลูชันแบบกำหนดเองสะท้อนความตึงเครียดในอุตสาหกรรมที่กว้างขึ้นเกี่ยวกับต้นทุน observability นโยบายการเก็บรักษาข้อมูล และผลิตภาพทางวิศวกรรม แม้ว่าความสำเร็จทางเทคนิคของพวกเขาจะน่าประทับใจ แต่ชุมชนยังคงแบ่งออกเป็นสองฝ่ายว่าการเก็บรวบรวมข้อมูลอย่างครอบคลุมเช่นนี้แสดงถึงแนวปฏิบัติทางวิศวกรรมที่ดีหรือ over-engineering ที่แพง
การถกเถียงท้ายที่สุดมุ่งเน้นไปที่การจัดการความเสี่ยง: ความเสี่ยงของการพลาดข้อมูล debugging ที่สำคัญเทียบกับความเสี่ยงของต้นทุนโครงสร้างพื้นฐานที่มากเกินไปและปัญหาการปฏิบัติตามกฎระเบียบ เมื่อเครื่องมือ observability ยังคงพัฒนาต่อไป องค์กรจะต้องหาสมดุลของตัวเองระหว่างการมองเห็นอย่างครอบคลุมและข้อจำกัดเชิงปฏิบัติ
อ้างอิง: Scaling our Observability platform beyond 100 Petabytes by embracing wide events and replacing OTel