Cloudflare R2 หรือ Amazon S3: egress ฟรีแลกกับอัปโหลดที่ช้ากว่า

สำหรับไฟล์ที่ผู้ใช้ดาวน์โหลดซ้ำเป็นจำนวนมาก Cloudflare R2 มักได้เปรียบด้านค่าโอนออก เพราะ ตารางราคา R2 ของ Cloudflare ระบุว่า Standard storage คิด 0.015 ดอลลาร์ต่อ GB-เดือน แต่ไม่คิดค่า egress จาก R2 โดยตรง ยังมีค่าพื้นที่เก็บและคำขอที่เกินโควตาฟรี ดังนั้นค่าโอนออกที่เป็นศูนย์ไม่ได้ทำให้ค่าใช้บริการทั้งหมดเป็นศูนย์

Amazon S3 น่าพิจารณามากขึ้นเมื่องานต้องเขียนไฟล์ถี่ ใช้บริการอื่นใน AWS หรือมีข้อกำหนดเรื่องการเก็บรักษาและสำเนาข้ามรีเจียน เงื่อนไขราคาของ Amazon S3 ให้ข้อมูลขาออกสู่อินเทอร์เน็ต 100 GB แรกต่อเดือนฟรีเมื่อรวมการใช้งานที่เข้าเกณฑ์จากบริการและรีเจียนของ AWS และไม่คิดค่าข้อมูลขาเข้าจากอินเทอร์เน็ต ส่วนที่เกินขึ้นกับรีเจียนและปริมาณการใช้ ผลทดสอบความเร็วที่ทำจากยุโรปชี้ข้อได้เปรียบของ S3 ในงานอัปโหลดภายใต้เงื่อนไขการทดสอบนั้น แต่ไม่ใช่ผลรับประกันสำหรับผู้ใช้ในไทย

ค่าใช้จ่ายจริงมีสามส่วน

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

R2 Standard แบ่งคำขอเป็น Class A สำหรับงานอย่าง PUT และ LIST กับ Class B สำหรับงานอย่าง GET และ HEAD อัตราหลังโควตาฟรีคือ 4.50 ดอลลาร์ต่อหนึ่งล้านคำขอ Class A และ 0.36 ดอลลาร์ต่อหนึ่งล้านคำขอ Class B โควตารายเดือนของ Standard ครอบคลุมพื้นที่ 10 GB-เดือน, Class A หนึ่งล้านครั้ง และ Class B สิบล้านครั้ง การอัปโหลดไฟล์เล็กจำนวนมากจึงอาจทำให้จำนวนคำขอสำคัญกว่าขนาดข้อมูลรวม โดยเฉพาะเมื่อระบบแสดงรายการหรืออ่านข้อมูลประกอบของวัตถุอยู่บ่อยครั้ง

Cloudflare ปัดปริมาณที่คิดเงินขึ้นตามหน่วยเรียกเก็บของแต่ละรายการ จึงไม่ควรนำอัตราต่อหนึ่งล้านคำขอไปคูณเศษส่วนแล้วถือว่าเป็นยอดบิลแน่นอน ในทางกลับกัน คำขอที่ยังอยู่ในโควตาฟรีของ Standard ไม่มีค่าใช้จ่ายส่วนนี้ ชั้น Infrequent Access ของ R2 เก็บถูกกว่า Standard แต่มีค่าดึงข้อมูลและระยะเวลาจัดเก็บขั้นต่ำ จึงต้องคิดรอบการอ่านและการลบไฟล์ด้วย

S3 แยกอัตราตามรีเจียนและชั้นจัดเก็บ รวมทั้งคิดค่าคำขอและค่าดึงคืนในบางชั้น ค่าโอนจาก S3 ไปยังบริการ AWS ในรีเจียนเดียวกันและการส่งจาก S3 ไป CloudFront อยู่ภายใต้ข้อยกเว้นค่าถ่ายโอนจาก S3 แต่ CloudFront และบริการปลายทางอาจมีค่าบริการของตนเอง การนำยอดดาวน์โหลดของผู้ชมทั้งหมดไปคูณอัตรา egress จาก S3 โดยตรงจึงทำให้ประมาณการผิด หากคำขอส่วนใหญ่ได้รับข้อมูลจากแคช

สำหรับงานเก็บถาวร การเทียบ R2 Standard กับ S3 Standard ให้เห็นเพียงต้นทุนของข้อมูลที่พร้อมเรียกใช้ตามเงื่อนไขของแต่ละบริการ S3 มีชั้นสำหรับข้อมูลที่เข้าถึงไม่บ่อยและกลุ่ม Glacier ซึ่งแลกค่าเก็บที่ต่ำลงกับเงื่อนไขการดึงคืนและเวลาเข้าถึง ข้อมูลสำรองที่ต้องกู้ทั้งชุดในเวลาจำกัดจึงควรประเมินค่าเก็บพร้อมค่ากู้คืน ไม่ใช่เลือกตัวเลขค่าเก็บที่ต่ำที่สุดแยกต่างหาก

แบบจำลอง 200 GB และประมาณ 1 TB

ตัวอย่างนี้เป็นแบบจำลอง ไม่ใช่ใบเสนอราคาสำหรับบัญชีในไทย สมมติเก็บข้อมูลเต็มเดือน โดยให้กรณีใหญ่มี 1,000 GB หรือประมาณ 1 TB และทั้งสองขนาดมีคำขอเขียน 100,000 ครั้งกับคำขออ่าน 2 ล้านครั้งต่อเดือน ใช้ R2 Standard เทียบกับ S3 Standard และยังไม่มีค่าบริการเสริม ภาษี หรือส่วนลดตามสัญญา

เพื่อให้เห็นผลของรูปแบบการใช้งาน สมมติอัตรา S3 สำหรับการคำนวณที่ 0.023 ดอลลาร์ต่อ GB-เดือน, 0.005 ดอลลาร์ต่อหนึ่งพันคำขอเขียน และ 0.0004 ดอลลาร์ต่อหนึ่งพันคำขออ่าน อัตราเหล่านี้เป็นตัวแปรของตัวอย่าง ไม่ใช่ราคาที่รับประกันสำหรับทุกรีเจียน AWS คิดขนาดพื้นที่จัดเก็บตามหน่วยไบนารีในเอกสารราคา ดังนั้นบิลของข้อมูลที่เรียกว่า 1 TB ในระบบจริงอาจไม่ตรงกับสมมติฐาน 1,000 GB นี้

เมื่อเก็บ 200 GB ค่าเก็บ R2 Standard หลังโควตาฟรีด้านพื้นที่เท่ากับ 2.85 ดอลลาร์ต่อเดือน คำขอทั้งสองประเภทในสมมติฐานยังไม่เกินโควตาฟรีของ R2 ฝั่ง S3 ค่าเก็บตามอัตราสมมติเท่ากับ 4.60 ดอลลาร์ และคำขอรวม 1.30 ดอลลาร์ ยอดก่อนคิดการส่งออกจึงเป็น 2.85 ดอลลาร์สำหรับ R2 เทียบกับ 5.90 ดอลลาร์สำหรับ S3

เมื่อเพิ่มพื้นที่เป็น 1,000 GB แต่คงจำนวนคำขอเดิม ค่าเก็บ R2 หลังโควตาฟรีเป็น 14.85 ดอลลาร์ ส่วน S3 ตามอัตราสมมติเป็น 23 ดอลลาร์ เมื่อบวกคำขอ ยอดก่อนค่าโอนออกเท่ากับ 14.85 และ 24.30 ดอลลาร์ตามลำดับ ตัวอย่างนี้แสดงว่าจำนวนคำขอไม่ได้เพิ่มตามจำนวน GB โดยอัตโนมัติ แต่ถ้าการเติบโตของข้อมูลมาจากไฟล์เล็กจำนวนมาก จำนวน PUT, GET และ LIST อาจโตไปพร้อมกัน

สมมติอีกกรณีว่าไฟล์ 1,000 GB ถูกส่งออกสู่อินเทอร์เน็ต 2,000 GB ในเดือนเดียว และใช้อัตราตัวอย่าง S3 ที่ 0.09 ดอลลาร์ต่อ GB สำหรับส่วนที่เกินโควตาฟรี 100 GB ค่าโอนออกที่คิดตามสมมติฐานเป็น 171 ดอลลาร์ ยอด S3 จึงเพิ่มจาก 24.30 เป็น 195.30 ดอลลาร์ ขณะที่ยอด R2 ในแบบจำลองยังอยู่ที่ 14.85 ดอลลาร์ก่อนค่าบริการอื่นที่อาจเชื่อมต่ออยู่ ความต่างหลักในกรณีนี้มาจากปริมาณข้อมูลที่ออก ไม่ใช่ค่าเก็บไฟล์

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

แบบจำลองถือว่าการดาวน์โหลดออกจากที่เก็บตามเส้นทางที่กำหนด หากวาง CDN ไว้หน้าที่เก็บ คำขอที่แคชตอบได้จะไม่กลับไปอ่านวัตถุต้นทางทุกครั้ง แต่ต้องนำราคาการส่งเนื้อหาของ CDN เข้ามาแทนด้วย เช่นเดียวกัน การทำสำเนาหรือแปลงไฟล์ก่อนเผยแพร่จะเพิ่มพื้นที่และคำขอที่แบบจำลองอย่างง่ายยังไม่รวม

ผลทดสอบงานเขียนบอกอะไรได้บ้าง

ใน การทดสอบ object storage ของ AIMultiple ซึ่งส่งคำขอจากยุโรปไปยังปลายทางในยุโรป การอัปโหลดไฟล์ 1 GB ได้ 77.92 MB/s สำหรับ S3 และ 25.61 MB/s สำหรับ R2 ส่วนค่า upload latency ที่รายงานเป็น 28.45 และ 171.58 มิลลิวินาทีตามลำดับ ตัวเลข throughput เป็นผลสำหรับไฟล์ขนาดที่ระบุ ส่วน latency เป็นอีกตัวชี้วัดหนึ่งของการทดสอบ ไม่ควรนำมาบวกรวมเป็นเวลาที่ไฟล์ 1 GB ใช้อัปโหลด

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

ในทางกลับกัน งานอัปโหลดไฟล์ใหญ่จะให้ความสำคัญกับ throughput รวมมากขึ้น การแบ่งอัปโหลดเป็นหลายส่วนและส่งหลายคำขอพร้อมกันอาจเปลี่ยนคอขวดของการเชื่อมต่อ แต่ก็เพิ่มจำนวนการดำเนินการที่ต้องนำไปคิดค่าใช้จ่าย ผลของ AIMultiple จึงเป็นหลักฐานว่า S3 เร็วกว่า R2 ในชุดทดสอบนั้น ไม่ใช่กฎว่าทุกไฟล์ ทุกเครื่องมือ และทุกเส้นทางเครือข่ายจะมีอัตราส่วนเดียวกัน

ผลทดสอบเดียวกันรายงาน TTFB เมื่ออ่านผ่าน S3 API ของ R2 สูงกว่า S3 ด้วย แต่ TTFB จากที่เก็บไม่เท่ากับเวลาที่ผู้ชมเว็บไซต์จะเห็นเมื่อไฟล์ถูกแคชไว้ใกล้ผู้ใช้ คำขอที่แคชตอบได้ไม่ต้องรอการอ่านจากที่เก็บต้นทาง การประเมินไฟล์สาธารณะจึงต้องแยกประสิทธิภาพของที่เก็บออกจากประสิทธิภาพของเส้นทางส่งเนื้อหา

สำหรับระบบที่รับอัปโหลดจากไทย ระยะทางไปยังบักเก็ต เส้นทางของผู้ให้บริการอินเทอร์เน็ต วิธีส่งไฟล์ และตำแหน่งของผู้ใช้อาจเปลี่ยนผลอย่างมีนัยสำคัญ ข้อมูลจากยุโรปช่วยระบุความเสี่ยงของงานเขียนบน R2 แต่ยังไม่บอกเวลาที่ผู้ใช้งานจริงในไทยจะรอ การตัดสินใจที่มีข้อกำหนดด้านความเร็วควรใช้ขนาดไฟล์และจำนวนคำขอแบบเดียวกับงานจริงในการประเมิน

ไฟล์สาธารณะ ข้อมูลสำรอง และชุดข้อมูล AI

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

หากใช้ S3 กับ CloudFront อยู่แล้ว ค่าโอนจาก S3 ไป CloudFront ไม่ใช่ค่าโอนตรงสู่อินเทอร์เน็ตที่ควรคูณกับทุกการรับชม ผู้ใช้ปลายทางได้รับข้อมูลตามราคาของ CloudFront และสัดส่วนแคชที่ตั้งไว้ การย้ายไฟล์สาธารณะไป R2 จึงควรเทียบค่าใช้จ่ายทั้งเส้นทางการส่งไฟล์ ไม่ใช่เทียบบิล S3 ที่สมมติว่าทุกการรับชมดึงจากต้นทาง

ข้อมูลสำรองให้ความสำคัญกับพื้นที่ที่ต้องเก็บ ระยะเวลารักษาข้อมูล และต้นทุนเมื่อต้องกู้คืน หากสำรองเป็นวัตถุขนาดใหญ่จำนวนไม่มาก ค่า request อาจมีน้ำหนักต่ำ แต่หากระบบสร้างชิ้นส่วนเล็กจำนวนมาก ค่าเขียนและเวลาต่อคำขอจะเด่นขึ้น ชั้นจัดเก็บราคาต่ำเหมาะได้ก็ต่อเมื่อค่าดึงคืน ระยะเวลาขั้นต่ำ และเวลารอข้อมูลสอดคล้องกับเป้าหมายการกู้ระบบ

การสำรองข้อมูลที่ไม่เคยถูกเปิดอ่านอาจทำให้ข้อได้เปรียบ egress ของ R2 แทบไม่ส่งผลต่อบิลรายเดือน แต่เหตุการณ์กู้คืนครั้งใหญ่จะเปลี่ยนสมการทันที การคิดต้นทุนตลอดอายุข้อมูลจึงควรรวมทั้งเดือนปกติและครั้งที่ต้องอ่านกลับจำนวนมาก มิฉะนั้นชั้นเก็บที่ดูถูกในเดือนปกติอาจมีต้นทุนสูงในวันที่ต้องใช้ข้อมูล

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

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

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

Object Lock และสำเนาข้ามรีเจียน

เมื่อระบบต้องรักษาวัตถุตามข้อกำหนดที่ป้องกันการลบหรือเขียนทับ ความสามารถที่ใช้ต้องตรงกับนโยบาย ไม่ใช่มีเพียงชื่อคล้ายกัน ความสามารถของ Amazon S3 ครอบคลุม Object Lock ซึ่งมีโหมด Governance และ Compliance รวมถึง Cross-Region Replication ที่คัดลอกวัตถุไปยังบักเก็ตในอีกรีเจียน โหมด Compliance ของ Object Lock ไม่เปิดให้ผู้ใช้ยกเลิกการคุ้มครองก่อนครบกำหนดตามที่ AWS อธิบายไว้

R2 ก็มีวิธีป้องกันการลบและเขียนทับ: Bucket locks ของ Cloudflare กำหนดระยะเวลารักษาวัตถุได้ รวมถึงแบบไม่มีกำหนด แต่ผู้ที่มีสิทธิ์แก้การตั้งค่าบักเก็ตสามารถลบกฎได้ จึงต้องเทียบอำนาจผู้ดูแลและเงื่อนไขการบังคับใช้นโยบายให้ตรงกับข้อกำหนดจริง การมี bucket lock ไม่ได้ทำให้พฤติกรรมเท่ากับ S3 Object Lock ในโหมด Compliance

การทำสำเนาข้ามรีเจียนเป็นอีกโจทย์หนึ่งที่ไม่ควรปนกับการเก็บวัตถุหลายชุดภายในระบบของผู้ให้บริการ หากต้องระบุรีเจียนปลายทางและให้ระบบคัดลอกวัตถุใหม่ไปยังบักเก็ตนั้นตามนโยบาย S3 มี Cross-Region Replication สำหรับงานนี้ ค่าเก็บสำเนา คำขอที่เกิดจากการทำสำเนา และการถ่ายโอนระหว่างรีเจียนต้องอยู่ในประมาณการด้วย

ข้อกำหนดเหล่านี้อาจตัดสินตัวเลือกก่อนการคำนวณค่า egress ระบบที่ต้องใช้พฤติกรรมของ S3 Object Lock โหมด Compliance หรือการทำสำเนาข้ามรีเจียนตามนโยบายที่กำหนดมีเหตุผลให้เลือก S3 ส่วนไฟล์สาธารณะที่อ่านหนักและไม่มีเงื่อนไขดังกล่าวมีเหตุผลให้เลือก R2 มากขึ้นเมื่อปริมาณส่งออกสูงพอ ความเร็วเขียนและค่าใช้จ่ายทั้งเส้นทางยังเป็นส่วนของการตัดสินใจเดียวกัน