ในโลกของคลาวด์คอมพิวติ้ง Amazon S3 ได้กลายเป็นโซลูชันเก็บข้อมูลพื้นฐานสำหรับแอปพลิเคชันนับไม่ถ้วน อย่างไรก็ตาม เมื่อบริษัทต่างๆ ขยายขนาด ต้นทุนอาจสูงจนน่าตกใจ ซึ่งกระตุ้นให้บางทีมงานวิศวกรรมพิจารณาสร้างทางเลือกด้วยตัวเอง กรณีศึกษาล่าสุดที่บริษัทหนึ่งอ้างว่าประหยัดเงินได้ 500,000 ดอลลาร์สหรัฐ ต่อปี โดยการสร้าง S3 โคลนของตัวเอง ได้จุดประกายการถกเถียงอย่างหนักในหมู่ผู้พัฒนาซอฟต์แวร์และวิศวกรโครงสร้างพื้นฐานเกี่ยวกับว่าเมื่อใดที่การละทิ้งบริการจัดการเพื่อไปใช้โซลูชันแบบกำหนดเองจึงจะสมเหตุสมผล
การอภิปรายเผยให้เห็นความแตกแยกอย่างลึกซึ้งในชุมชนเทคโนโลยีเกี่ยวกับเศรษฐศาสตร์ของคลาวด์ โดยบางกลุ่มชื่นชมการประหยัดต้นทุน ในขณะที่กลุ่มอื่นเตือนเกี่ยวกับภาระการบำรุงรักษาที่ซ่อนอยู่และความเสี่ยงด้านความทนทาน
การแลกเปลี่ยนทางวิศวกรรมของสตอเรจแบบกำหนดเอง
การสร้างระบบจัดเก็บออบเจกต์ของคุณเองเกี่ยวข้องกับการแลกเปลี่ยนทางวิศวกรรมที่สำคัญซึ่งไปไกลกว่าต้นทุนการพัฒนาเริ่มต้น ขณะที่บทความเดิมอธิบายการสร้างระบบภายในชื่อ N3 ที่ลดต้นทุนการจัดเก็บลงเหลือหนึ่งในสิบของราคา S3 ผู้แสดงความคิดเห็นต่างรีบชี้ให้เห็นว่าการแทนที่ S3 ที่แท้จริงต้องการมากกว่าแค่การเก็บไฟล์พื้นฐาน วิศวกรที่มีประสบการณ์คนหนึ่งระบุว่าการนำความทนทานของข้อมูลที่เหมาะสมมาใช้ พร้อมกับสำเนาหลายชุด การตรวจจับความเสียหาย และการซ่อมแซมอัตโนมัติ เพิ่มโอเวอร์เฮดประมาณ 40% ให้กับประมาณการเริ่มต้นของพวกเขา เวลาทางวิศวกรรมที่ต้องใช้สำหรับการสร้างและบำรุงรักษาเครื่องมือแบบกำหนดเองสำหรับการทำซ้ำข้ามหลายภูมิภาค การควบคุมการเข้าถึง และการตรวจสอบ ใช้เวลาของวิศวกรเต็มเวลา 1.5 คน ตลอด 18 เดือน
การนำความทนทานของข้อมูลที่เหมาะสมมาใช้ (สำเนา 3+ ชุด, การตรวจจับความเสียหาย, การซ่อมแซมอัตโนมัติ) เพิ่มโอเวอร์เฮด ~40% ให้กับประมาณการเริ่มต้นของเรา เวลาทางวิศวกรรมที่ใช้ไปกับการสร้างและบำรุงรักษาเครื่องมือแบบกำหนดเอง กลายเป็นเรื่องที่สำคัญมาก
บทสนทนาเผยให้เห็นว่าหลายทีมประเมินภาระการดำเนินงานของการบำรุงรักษาโครงสร้างพื้นฐานแบบกำหนดเองต่ำเกินไป ผู้แสดงความคิดเห็นหลายคนตั้งคำถามว่าบริษัทได้สร้างการแทนที่ S3 ที่สมบูรณ์จริงๆ หรือเพียงแค่สร้างแคชในหน่วยความจำที่อยู่หน้า S3 สำหรับสถานการณ์การใช้งานหลัก (happy path) ของพวกเขาเท่านั้น ความแตกต่างนี้สำคัญเพราะการแคชข้อมูลที่ถูกเข้าถึงบ่อยครั้งต้องการงานทางวิศวกรรมน้อยกว่าการสร้างระบบจัดเก็บออบเจกต์แบบกระจายที่ทนทาน พร้อมกับการรับประกันความน่าเชื่อถือในระดับเดียวกับ S3 มาก
เมื่อใดที่โครงสร้างพื้นฐานแบบกำหนดเองจึงสมเหตุสมผลทางการเงิน?
จุดคุ้มทุนสำหรับการสร้างโครงสร้างพื้นฐานจัดเก็บข้อมูลแบบกำหนดเอง ดูเหมือนจะอยู่ที่ประมาณ 100-200TB ของข้อมูลที่ค่อนข้างคงที่และมีรูปแบบการเข้าถึงที่คาดการณ์ได้ ต่ำกว่าเกณฑ์นี้ โอเวอร์เฮดในการดำเนินงานของการจัดการสตอเรจของคุณเองมีแนวโน้มจะเกินกว่ากำไรส่วนเพิ่มของ S3 สำหรับเวิร์กโหลดที่มีปริมาณการใช้งานสูงเกิน 500 คำขอต่อ секунด์ ผู้แสดงความคิดเห็นบางรายรายงานว่ามีประสิทธิภาพด้านต้นทุนที่ดีกว่าด้วย S 3 เนื่องจากเศรษฐกิจ規模ของ Amazon เกี่ยวกับแบนด์วิธ
การอภิปรายเน้นย้ำว่าการนำสตอเรจแบบกำหนดเองไปใช้ที่ประสบความสำเร็จ มักจะมีลักษณะเฉพาะที่ทำให้สามารถใช้โซลูชันที่เรียบง่ายกว่าได้ ซึ่งรวมถึงการยอมรับการสูญเสียข้อมูลในบางสถานการณ์ ความต้องการจัดเก็บข้อมูลชั่วคราว และความสามารถในการใช้ S3 เป็นตัวสำรองสำหรับข้อมูลที่สำคัญ ทีมที่กำลังพิจารณาเส้นทางนี้จำเป็นต้องมีการประเมินอย่างตรงไปตรงมาทั้งเกี่ยวกับขนาดของพวกเขาและความสามารถทางวิศวกรรมในการสร้างและบำรุงรักษาระบบในระยะยาว
การเปรียบเทียบต้นทุน: S3 เทียบกับระบบจัดเก็บข้อมูลแบบกำหนดเอง
- การประหยัดต้นทุนที่อ้างว่าได้จากการเปลี่ยนจาก S3: $500,000 USD ต่อปี
- ระยะเวลาในการพัฒนาระบบจัดเก็บข้อมูลแบบกำหนดเอง: ~1.5 FTE ในช่วง 18 เดือน (จากประสบการณ์ของผู้แสดงความคิดเห็น)
- ต้นทุนเพิ่มเติมสำหรับความทนทานของข้อมูล: ~40% ของต้นทุนเพิ่มเติมสำหรับการใช้งานที่เหมาะสม
- จุดคุ้มทุน: ข้อมูลแบบคงที่ 100-200TB ที่มีรูปแบบการเข้าถึงที่คาดการณ์ได้
- เกณฑ์ปริมาณการใช้งานสูง: เหนือกว่า 500 requests ต่อวินาที S3 อาจจะคุ้มค่ากว่าเนื่องจากประหยัดต้นทุนจาก bandwidth ในระดับมหภาค
แนวทางทางเลือกและประสบการณ์ในโลกแห่งความเป็นจริง
ส่วนความคิดเห็นเปิดเผยกลยุทธ์ทางเลือกหลายประการที่บริษัทต่างๆ นำมาใช้เพื่อลดต้นทุน S3 โดยไม่ต้องสร้างทุกอย่างจากศูนย์ บางทีมรายงานความสำเร็จด้วยโซลูชันที่เข้ากันได้กับ S3 แบบโอเพนซอร์ส เช่น MinIO และ SeaweedFS แม้ว่าคนอื่นๆ จะตั้งข้อสังเกตว่า MinIO ได้หันเหไปจากการมีรุ่นชุมชนฟรีแล้ว ผู้แสดงความคิดเห็นคนหนึ่งกล่าวถึงการใช้งาน Garage ซึ่งเป็นระบบจัดเก็บออบเจกต์แบบกระจายที่เรียบง่ายกว่า สำหรับกรณีการใช้งานขนาดเล็ก
วิศวกรหลายคนแบ่งปันประสบการณ์กับแนวทางแบบไฮบริดที่รวมกลยุทธ์การจัดเก็บข้อมูลที่แตกต่างกันตามรูปแบบการเข้าถึงข้อมูล รูปแบบทั่วไปอย่างหนึ่งเกี่ยวข้องกับการเก็บข้อมูลที่ถูกใช้งานบ่อย (hot data) ในสตอเรจที่เร็วและแพงกว่า ในขณะที่เก็บข้อมูลที่ถูกใช้งานน้อย (cold data) ไว้ในตัวเลือกที่ถูกว่ากว่า คนอื่นๆ อภิปรายเกี่ยวกับการปรับสถาปัตยกรรมแอปพลิเคชันของพวกเขาเพื่อลดการเรียกใช้ S3 API ที่ไม่จำเป็น ซึ่งสามารถสร้างส่วนสำคัญของต้นทุน S3 สำหรับแอปพลิเคชันที่มีปริมาณการใช้งานสูงได้
ทางเลือก S3-Compatible อื่นๆ ที่ถูกกล่าวถึง
- MinIO: เน้นกลุ่มองค์กร เปลี่ยนแนวทางจากเวอร์ชันชุมชนฟรี
- SeaweedFS: ระบบไฟล์แบบกระจายแบบโอเพนซอร์ส
- Garage: ระบบจัดเก็บข้อมูลแบบกระจายที่เรียบง่ายกว่าสำหรับการใช้งานขนาดเล็ก
- Hybrid Approaches: การผสมผสานกลยุทธ์การจัดเก็บข้อมูลที่แตกต่างกันตามรูปแบบการเข้าถึงข้อมูล
คำถามเกี่ยวกับภาระการบำรุงรักษา
บางทีการอภิปรายที่ขัดแย้งกันมากที่สุดอาจอยู่ที่ต้นทุนการบำรุงรักษาโครงสร้างพื้นฐานแบบกำหนดเองในระยะยาว ผู้แสดงความคิดเห็นหลายคนตั้งคำถามว่าต้องใช้วิศวกรกี่คนต่อปีเพื่อบำรุงรักษาระบบดังกล่าว โดยประมาณการอยู่ในช่วงตั้งแต่เศษส่วนเล็กน้อยของหนึ่งคนไปจนถึงเศษส่วนเล็กน้อยของสามคน ความเป็นจริงน่าจะขึ้นอยู่กับความซับซ้อนของการนำไปใช้และข้อกำหนดความน่าเชื่อถือขององค์กร
บทสนทนาเผยให้เห็นว่าหลายทีมประสบปัญหากับการบัญชีเวลาทางวิศวกรรมอย่างถูกต้องเมื่อประเมินโซลูชันแบบคลาวด์เทียบกับแบบกำหนดเอง ในขณะที่บริการคลาวด์มีใบแจ้งหนี้ที่ชัดเจนและแยกเป็นรายการ ต้นทุนของชั่วโมงงานทางวิศวกรรมมักจะซ่อนอยู่ across ทีมและงบประมาณหลายส่วน สิ่งนี้ทำให้การเปรียบเทียบต้นทุนรวมของการเป็นเจ้าทั้งหมด (TCO) ที่แท้จริงเป็นเรื่องท้าทายโดยไม่มีการติดตามกิจกรรมทางวิศวกรรมที่เกี่ยวข้องทั้งหมดอย่างรอบคอบ
การอภิปรายที่ยังคงดำเนินอยู่ชี้ให้เห็นว่าในขณะที่ต้นทุนคลาวด์สตอเรจสามารถกลายเป็นสิ่งที่ prohibitive ได้ที่สเกลใหญ่ การตัดสินใจสร้างโครงสร้างพื้นฐานแบบกำหนดเองต้องการการพิจารณาอย่างรอบคอบทั้งเกี่ยวกับการประหยัดต้นทุนในทันทีและความมุ่งมั่นในการบำรุงรักษาระยะยาว ดังที่ผู้แสดงความคิดเห็นคนหนึ่งกล่าวอย่างรวบรัดว่า กุญแจสำคัญคือการซื่อสัตย์จริงๆ กับกรณีการใช้งานของคุณ และว่าคุณมีทรัพยากรทางวิศวกรรมที่จะสร้างและบำรุงรักษาสิ่งนี้ในระยะยาวหรือไม่
อ้างอิง: How We Saved $500,000 Per Year by Rolling Our Own “S3”