Aeron ระบบส่งข้อความประสิทธิภาพสูงที่พัฒนาโดย Real Logic และปัจจุบันดำเนินการโดย Adaptive Financial Consulting ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนเกี่ยวกับความท้าทายในทางปฏิบัติของการนำ reliable multicast messaging ไปใช้ในสภาพแวดล้อมการผลิต แม้ว่าระบบจะสัญญาว่าจะให้การส่งข้อความ UDP unicast, multicast และ IPC ที่มีประสิทธิภาพ โดยมุ่งเน้นไปที่การบรรลุ throughput สูงสุดและ latency ต่ำสุด แต่ประสบการณ์ในโลกจริงเผยให้เห็นอุปสรรคการติดตั้งที่สำคัญ
การใช้งาน Multicast พิสูจน์แล้วว่ามีปัญหาในทางปฏิบัติ
ชุมชนได้เน้นย้ำถึงความท้าทายมากมายเกี่ยวกับความน่าเชื่อถือของ multicast ในโครงสร้างเครือข่ายที่แตกต่างกัน สภาพแวดล้อมองค์กร ระบบเสมือน และแพลตฟอร์มคลาวด์นำเสนอความยากลำบากเป็นพิเศษ ผู้ดูแลเครือข่ายมักจะปิดใช้งาน multicast โดยเจตนา และความไม่สอดคล้องของฮาร์ดแวร์สร้างรูปแบบพฤติกรรมที่คาดเดาไม่ได้
หลังจากหลายปีของการดูแลและใช้ชุดแอปพลิเคชันที่อาศัย multicast สำหรับการสื่อสารภายใน ผมจะลังเลที่จะใช้คำว่า reliable และ multicast ในประโยคเดียวกัน
ปัญหาเหล่านี้เกิดจากการจัดการที่ไม่น่าเชื่อถือใน switches, routers, network adapters และ TCP/IP stacks ของระบบปฏิบัติการ ปัญหาทั่วไปรวมถึง multicast sockets ที่เข้าร่วม network interfaces ที่ไม่ถูกต้อง การสูญเสีย membership หลังจากรอบการหลับของระบบ และอุปกรณ์ระดับองค์กรที่ตัดการเชื่อมต่อ multicast โดยไม่คาดคิด
ปัญหาการใช้งาน Multicast ที่พบบ่อย
- Multicast sockets เชื่อมต่อกับ network adapter interfaces ผิดตัว
- การสูญเสียสมาชิกภาพ multicast หลังจากระบบเข้าสู่โหมดพักหรือ hibernate
- Switches และ routers ตัดการเป็นสมาชิก multicast เมื่อเวลาผ่านไป
- พฤติกรรมไม่สม่ำเสมอในสภาพแวดล้อมเสมือน (VMs)
- ปัญหาความเข้ากันได้ของระบบองค์กร ( SUSE Linux , Windows Server )
- ความขัดแย้งในการใช้ socket ซ้ำและความท้าทายในการกำหนดค่า
- การปิดใช้งาน multicast โดยเจตนาในเครือข่าย cloud และองค์กร
การอ้างสิทธิ์ด้านประสิทธิภาพเผชิญการตรวจสอบอย่างละเอียด
สมาชิกในชุมชนได้ตั้งคำถามเกี่ยวกับการอ้างสิทธิ์ด้านประสิทธิภาพของ Aeron หลังจากตรวจสอบข้อมูลการทดสอบจากการติดตั้งใน AWS และ Google Cloud Platform การวิเคราะห์เผยให้เห็นว่าแม้ว่า Aeron จะบรรลุอัตราข้อความที่น่าประทับใจ แต่ประสิทธิภาพต่อ core อาจไม่ตรงตามความคาดหวังเมื่อเปรียบเทียบกับการใช้งาน TCP แบบดั้งเดิม
บน AWS c5.9xlarge instances ที่มี 36 vCPUs, Aeron ประมวลผลข้อความขนาด 288 ไบต์ประมาณ 3 ล้านข้อความต่อวินาที ลดลงเหลือ 700,000 ข้อความต่อวินาทีสำหรับข้อความขนาดใหญ่ 1,344 ไบต์ สิ่งนี้แปลเป็นประมาณ 200 Mbps ต่อ core ซึ่งบางคนโต้แย้งว่าต่ำกว่าความสามารถของ TCP ที่สามารถบรรลุ 10 Gbps ต่อ core เดียวโดยไม่ต้องมีการปรับแต่งอย่างรุนแรง
อย่างไรก็ตาม ผู้สนับสนุนชี้ให้เห็นว่าสถาปัตยกรรมของ Aeron แตกต่างจากแนวทางดั้งเดิมโดยพื้นฐาน ระบบใช้ threading น้อยที่สุดโดยปกติจะมีเพียง receive thread หนึ่งตัวและ transmit thread หนึ่งตัว รวมถึง administrative thread แทนที่จะเป็นการประมวลผลแบบขนานอย่างหนัก
เกณฑ์มาตรฐานประสิทธิภาพของ Aeron
| แพลตฟอร์ม | ประเภทอินสแตนซ์ | ขนาดข้อความ | ข้อความ/วินาที | อัตราการส่งข้อมูล |
|---|---|---|---|---|
| AWS | c5.9xlarge (36 vCPU) | 288 ไบต์ | ~3 ล้าน | ~7.5 Gbps |
| AWS | c5.9xlarge (36 vCPU) | 1,344 ไบต์ | 700,000 | ~1 GB/s |
| GCP | C3 (ไม่ระบุ) | 288 ไบต์ | ~4.7 ล้าน | ~12 Gbps |
ประสิทธิภาพต่อคอร์: ~200 Mbps (ประมาณการจากการกระจายแบบ 36 คอร์)
ภาคการซื้อขายทางการเงินแสดงการยอมรับอย่างแข็งแกร่ง
แม้จะมีความท้าทายในการติดตั้ง แต่ Aeron ได้พบความสำเร็จอย่างมากในระบบซื้อขายทางการเงินที่มีโครงสร้าง multicast อยู่แล้วสำหรับการกระจายข้อมูลตลาด การรวมระบบกับ Simple Binary Encoding (SBE) ให้ประสิทธิภาพการเข้ารหัสและถอดรหัสข้อความที่ยอดเยี่ยม ทำให้น่าสนใจสำหรับแอปพลิเคชันที่ไวต่อ latency
เครือข่ายที่เปิดใช้งาน multicast ที่มีอยู่แล้วของภาคการเงินและความอดทนต่อความซับซ้อนของโครงสร้างพื้นฐานทำให้เป็นสภาพแวดล้อมที่เหมาะสำหรับการติดตั้ง Aeron ระบบซื้อขายได้รับประโยชน์จากลักษณะ tail latency ที่เหนือกว่าที่ Aeron ให้เมื่อเปรียบเทียบกับทางเลือกที่ใช้ TCP
การออกแบบสถาปัตยกรรมเน้น Mechanical Sympathy
สถาปัตยกรรมระบบของ Aeron แสดงถึงจุดแข็งหลักของมัน โดยนำสิ่งที่นักพัฒนาเรียกว่า mechanical sympathy มาใช้ - การออกแบบซอฟต์แวร์ที่ทำงานอย่างมีประสิทธิภาพกับฮาร์ดแวร์พื้นฐาน ระบบใช้ Aeron Server แบบรวมศูนย์ที่จัดการการสื่อสารเครือข่ายภายนอก ในขณะที่กระบวนการ client สื่อสารผ่าน shared memory pipes ประสิทธิภาพสูง
การออกแบบนี้อนุญาตให้มีการส่งข้อความที่ไม่ขึ้นกับการขนส่ง โดยที่ clients สมัครสมาชิก channels โดยไม่ต้องส่งข้อมูลเครือข่ายโดยตรง เซิร์ฟเวอร์จัดการการกำหนดเส้นทางข้อมูลไปยัง client shared memory queues ทำให้สามารถบรรลุประสิทธิภาพสูงสุดด้วย reliable UDP และ multicast fan-out สำหรับ data streams ทั่วไป
โค้ดเบสเองได้รับการยอมรับว่าเป็นการศึกษาที่เป็นแบบอย่างในคุณภาพซอฟต์แวร์ โดยเฉพาะสำหรับการพัฒนา Java แม้ว่าผู้เชี่ยวชาญจะเตือนว่าเทคนิคที่ไม่ใช่แบบแผนของมันให้ความสำคัญกับประสิทธิภาพมากกว่าแบบแผน Java ทั่วไป
ส่วนประกอบของสถาปัตยกรรมระบบ Aeron
- Media Driver: จัดการการสื่อสารเครือข่ายภายนอกด้วย threading ที่น้อยที่สุด (1 RX + 1 TX + 1 admin thread)
- Client Processes: สื่อสารผ่าน shared memory pipes ที่มีประสิทธิภาพสูง
- Archive Module: บันทึก message streams ลงใน persistent storage เพื่อการเล่นซ้ำ
- Cluster Module: ให้บริการที่ทนต่อความผิดพลาดโดยใช้ Raft consensus algorithm
- Transport Support: รองรับ UDP unicast, UDP multicast และ IPC messaging
- Language Support: มี Java, C, C++ และ .NET clients ให้ใช้งาน
บทสรุป
Aeron แสดงถึงแนวทางที่ซับซ้อนต่อการส่งข้อความประสิทธิภาพสูงที่ให้ผลลัพธ์ที่น่าประทับใจในสภาพแวดล้อมที่ควบคุมได้ โดยเฉพาะในภาคการซื้อขายทางการเงิน อย่างไรก็ตาม ความท้าทายในทางปฏิบัติของการติดตั้ง multicast และความซับซ้อนของการบรรลุประสิทธิภาพที่เหมาะสมแสดงให้เห็นว่าองค์กรควรประเมินความสามารถและข้อกำหนดของโครงสร้างพื้นฐานของตนอย่างรอบคอบก่อนการยอมรับ แม้ว่าระบบจะเป็นเลิศในกรณีการใช้งานเฉพาะ แต่ประโยชน์ของมันมาพร้อมกับค่าใช้จ่ายการใช้งานและการบำรุงรักษาที่สำคัญซึ่งอาจไม่เหมาะสมกับแอปพลิเคชันทั้งหมด
อ้างอิง: Aeron