Cachey นำเสนอระบบแคชสำหรับ Object Storage ประสิทธิภาพสูงด้วยสถาปัตยกรรมไฮบริดระหว่างหน่วยความจำและดิสก์

Cachey ได้กลายเป็นโซลูชันแคชเฉพาะทางที่ออกแบบมาเพื่อเร่งความเร็วในการเข้าถึงระบบ object storage เช่น Amazon S3 แคชแบบ read-through นี้ผสมผสานหน่วยความจำและดิสก์เข้าด้วยกันเพื่อสร้างระบบไฮบริดที่มุ่งเป้าลดความหน่วงและต้นทุนสำหรับแอปพลิเคชันที่เข้าถึงข้อมูลเดิมจาก cloud storage บ่อยครั้ง

ระบบนี้ใช้แนวทางที่เป็นเอกลักษณ์ด้วยขนาดหน้าคงที่ 16 MiB โดยจับคู่ช่วงไบต์ที่ร้องขอใดๆ กับการค้นหาที่จัดตำแหน่งตามหน้า การออกแบบนี้ช่วยเพิ่มประสิทธิภาพของแคชในขณะที่รองรับ HTTP range requests มาตรฐานที่แอปพลิเคชันหลายตัวใช้สำหรับสตรีมมิ่งสื่อและการเข้าถึงไฟล์ขนาดใหญ่

ข้อมูลจำเพาะทางเทคนิคหลัก

• ขนาดหน้า: หน้าขนาดคงที่ 16 MiB สำหรับข้อมูลที่แคชทั้งหมด
• ประเภทแคช: ระบบจัดเก็บแบบผสมผสานระหว่างหน่วยความจำและดิสก์โดยใช้ไลบรารี foyer
• หน่วยความจำเริ่มต้น: 4 GiB (สามารถกำหนดค่าได้ด้วยหน่วยต่างๆ เช่น "512MiB", "2GB", "1.5GiB")
• การใช้งานดิสก์: สูงสุด 80% ของพื้นที่ที่มีอยู่ (หากไม่ได้ระบุไว้)
• Hedged Requests: เกณฑ์ latency เริ่มต้นที่เปอร์เซ็นไทล์ที่ 99
• API: HTTP แบบง่ายพร้อม Range headers ที่จำเป็น
• ขีดจำกัด Bucket: สูงสุด 2 buckets ที่พยายามต่อหน้าที่หายไป
• การรองรับ TLS: ใบรับรองที่ลงนามด้วยตนเองหรือคู่ cert/key แบบกำหนดเอง

ความท้าทายในการติดตั้งแบบหลายโซนกระตุ้นการอภิปราย

ชุมชนได้ตั้งคำถามสำคัญเกี่ยวกับความเหมาะสมของ Cachey สำหรับสภาพแวดล้อมการผลิตที่มีความพร้อมใช้งานสูงและหลายโซน ซึ่งแตกต่างจากการติดตั้งในโซนเดียวที่แคชสามารถให้ประโยชน์ที่ชัดเจน การตั้งค่าหลายโซนนำเสนอการแลกเปลี่ยนที่ซับซ้อนระหว่างความสอดคล้องของแคช ต้นทุนเครือข่ายข้ามโซน และประสิทธิภาพ

มันเป็นแคชแบบ read through ฝั่งผู้ใช้ ดังนั้นจึงไม่จำเป็นต้องมีความสอดคล้องของแคชเชิงป้องกัน แต่จะมีการลดประสิทธิภาพในการดึงข้อมูลภายใต้การแข่งขันในการเขียนโดยไม่คำนึงว่าคุณจะมีโซนเดียวหรือหลายโซน

นักพัฒนายอมรับข้อจำกัดนี้และปัจจุบันแนะนำการติดตั้งแยกตามโซนพร้อม auto-scaling ซึ่งหมายความว่าต้องยอมรับต้นทุนโครงสร้างพื้นฐานที่เพิ่มขึ้นหรือค่าใช้จ่ายเครือข่ายข้ามโซน แนวทางนี้ทำงานได้ดีสำหรับข้อมูลที่ไม่เปลี่ยนแปลง แต่อาจไม่เหมาะสำหรับทุกสถานการณ์ในองค์กร

ความเป็นไปได้ในการบูรณาการและกรณีการใช้งาน

สมาชิกในชุมชนได้เสนอแนะโอกาสการบูรณาการที่น่าสนใจ รวมถึง NBD (Network Block Device) frontends ที่สามารถเปลี่ยนออบเจกต์ที่แคชไว้ให้เป็นอุปกรณ์ Linux หรือพื้นที่จัดเก็บสำรองสำหรับเครื่องเสมือน สิ่งนี้จะขยายประโยชน์ของ Cachey นอกเหนือจากแอปพลิเคชันเว็บแบบดั้งเดิมไปสู่สถานการณ์โครงสร้างพื้นฐานและเสมือนจริง

แคชนี้ดูเหมือนจะมีประโยชน์มากที่สุดสำหรับ workloads ที่มีรูปแบบการเข้าถึงซ้ำๆ เช่น ฐานข้อมูลที่สร้างบน object storage หรือแอปพลิเคชันที่เสิร์ฟเนื้อหาเดียวกันหลายครั้ง อย่างไรก็ตาม แอปพลิเคชันที่ใช้การแคชในหน่วยความจำอยู่แล้วอาจต้องประเมินว่าความซับซ้อนเพิ่มเติมให้ประโยชน์เพียงพอเมื่อเทียบกับการเพิ่มขนาดแคชที่มีอยู่หรือไม่

ตัวเลือกการกำหนดค่า API

พารามิเตอร์ CO-Config:

• ct=<ms> - ไทม์เอาต์การเชื่อมต่อ
• rt=<ms> - ไทม์เอาต์การอ่าน (เวลาถึงไบต์แรก)
• ot=<ms> - ไทม์เอาต์การดำเนินการ (ข้ามการลองใหม่)
• oat=<ms> - ไทม์เอาต์การพยายามดำเนินการ
• ma=<num> - จำนวนครั้งสูงสุดที่พยายาม
• ib=<ms> - ระยะเวลา backoff เริ่มต้น
• mb=<ms> - ระยะเวลา backoff สูงสุด

คุณสมบัติการเพิ่มประสิทธิภาพ

Cachey รวมคุณสมบัติขั้นสูงหลายอย่างเพื่อจัดการกับความหน่วงที่คาดเดาไม่ได้ซึ่งมักเกี่ยวข้องกับ object storage ระบบทำ hedged requests โดยส่งคำขอซ้ำหลังจากเกณฑ์ความหน่วงที่กำหนดเพื่อปรับปรุงเวลาตอบสนอง นอกจากนี้ยังสามารถพยายามส่งคำขอไปยัง buckets สำรองเพื่อให้มีตัวเลือกสำรองเมื่อพื้นที่จัดเก็บหลักช้าหรือไม่พร้อมใช้งาน

สถาปัตยกรรมไฮบริดระหว่างหน่วยความจำและดิสก์ที่ขับเคลื่อนโดยไลบรารี foyer caching ช่วยให้จัดการความจุได้อย่างยืดหยุ่น ผู้ใช้สามารถกำหนดค่าทั้งขีดจำกัดหน่วยความจำและเส้นทางพื้นที่จัดเก็บดิสก์ โดยระบบจะใช้พื้นที่ดิสก์ที่มีอยู่ได้ถึง 80% โดยอัตโนมัติหากไม่ได้ระบุไว้เป็นอย่างอื่น

แม้ว่า Cachey จะแสดงให้เห็นถึงความสดใสสำหรับกรณีการใช้งานเฉพาะที่เกี่ยวข้องกับ immutable blob storage แต่สถาปัตยกรรมปัจจุบันทำงานได้ดีที่สุดในการติดตั้งโซนเดียวหรือสถานการณ์ที่ต้นทุนของเครือข่ายข้ามโซนยอมรับได้ องค์กรที่พิจารณาการนำไปใช้ควรประเมินรูปแบบการเข้าถึงและความต้องการโครงสร้างพื้นฐานของตนอย่างรอบคอบเทียบกับการแลกเปลี่ยนเหล่านี้

อ้างอิง: Cachey