A Beginner’s Guide to Understanding RPUs in AWS Redshift Serverless, Let’s go!
Introduction
เปิดหน้า Pricing ของ AWS Redshift Serverless แล้วเจอคำว่า RPU โผล่มาเต็มไปหมด แต่ไม่รู้จะตั้งเท่าไหร่ดีถึงจะพอดีกับงานที่ทำอยู่ แล้วสุดท้ายบิลจะออกมาเท่าไหร่กันแน่ วันนี้เลยจะขอพามาถอดรหัสตัวเลขตัวนี้กัน
ปกติเวลาเราใช้ Redshift แบบ Provisioned เราก็ต้องมานั่งเลือก Node type เลือกจำนวน Node เอง ซึ่งเป็นการตัดสินใจที่ปวดหัวไม่น้อย แต่พอมาเป็น Serverless ทาง AWS ตัดเรื่องพวกนี้ทิ้งไปเลย เหลือแค่ตัวเลขตัวเดียวที่เราต้องตั้งคือ RPU เท่านั้นเองครับ ฟังดูเหมือนง่ายขึ้นเยอะ แต่คำถามที่ตามมาคือ แล้วตัวเลขนี้มันคืออะไรกันแน่ และเราจะรู้ได้ไงว่าต้องตั้งเท่าไหร่ถึงจะพอดี ไม่จ่ายแพงเกินจำเป็น
RPU คืออะไรกันแน่
Redshift Processing Unit (RPU)
พูดง่ายๆ RPU ก็คือหน่วยของ Compute capacity ที่ Redshift Serverless ใช้วัดกำลังการประมวลผล โดย 1 RPU จะให้ Memory มา 16 GB พร้อม Compute และ I/O ที่ Scale ตามสัดส่วนกันไปด้วย เราไม่ต้องมาแยกตั้งค่า Memory กับ Compute เองแบบ Provisioned เลยครับ ตัวเลข RPU ตัวเดียวกำหนดทั้งสองอย่างพร้อมกัน
สิ่งที่เราตั้งได้จริงๆ เรียกว่า Base capacity คือระดับ RPU ที่ Workgroup ของเราวิ่งอยู่เป็นค่าเริ่มต้น แล้วพอเวลามี Query ที่ต้องการทรัพยากรมากขึ้น ตัว Redshift ก็จะ Scale ขึ้นให้เองอัตโนมัติ แล้วค่อยลดกลับมาที่ Base เหมือนเดิมเมื่องานเสร็จ ตอนนี้ช่วงที่ตั้งได้กว้างมากตั้งแต่ 4 ไปจนถึง 1024 RPU เลยครับ (ขึ้นอยู่กับ Region ด้วยนะ บาง Region ยังไม่รองรับค่าต่ำสุดแบบนี้ และส่วน RPU ถ้ากังวลว่า RPU จะ scale เกินไปสามารถตั้งค่า Limit ได้เช่นกัน)
สูตรคิดเงินง่ายๆ ที่ต้องจำให้ขึ้นใจ
ตัว Compute ของ Serverless จะคิดเงินแบบ Per-second โดยมีขั้นต่ำอยู่ที่ 60 วินาทีทุกครั้งที่ Warehouse ถูกเรียกใช้งาน ถ้าไม่มี Query วิ่งเลยก็ไม่เสียตังค์ครับ ส่วนสูตรที่อยู่เบื้องหลังทุกอย่างคือ
Cost = RPU x ชั่วโมงที่ Active x Rate ต่อ RPU-ชั่วโมง
ถ้าอยู่ที่ US East (N. Virginia) Rate แบบ On-demand จะอยู่ที่ $0.375 ต่อ RPU-ชั่วโมง ซึ่งตัวเลขนี้เปลี่ยนได้ตามแต่ละ Region และตามเวลา อันนี้แนะนำให้เช็คหน้า Pricing จริงก่อนเอาไปประเมินงบจริงๆนะครับ อย่าเพิ่งจำตัวเลขไปใช้ตรงๆ
ลองดูตัวอย่างจริงจากหน้า Pricing ของ AWS เองก็ได้ครับ สมมติมี Job ที่รันด้วย 128 RPU วันละ 13 รอบ รอบละ 10 นาที 30 วินาที รวมเวลา Active ทั้งวันคือ 8,190 วินาที (2.275 ชั่วโมง) พอเอาเข้าสูตรจะได้ค่าใช้จ่ายวันละ $109.20 พอดี หรืออีกตัวอย่างที่ซับซ้อนขึ้น เป็น Dashboard app ที่ตั้ง Base ไว้ 64 RPU แต่ช่วงเช้าและบ่ายมีคน Query เยอะจน Scale ขึ้นไปถึง 192 RPU และ 128 RPU ตามลำดับ พอรวมทั้งวันแล้วจะได้ 1,344 RPU-ชั่วโมง คิดเป็นเงินวันละ $504 ครับ
จุดที่น่าสนใจจากตัวอย่างที่สองคือ ตัวเลขที่กำหนดค่าใช้จ่ายจริงๆไม่ใช่ Base RPU เพียงอย่างเดียว แต่เป็น “พื้นที่ใต้กราฟ” ของ RPU คูณเวลาที่ Active ต่างหาก Workgroup สอง Workgroup ที่ตั้ง Base เท่ากันเป๊ะ อาจมีบิลต่างกันมากได้เลยถ้า Scale ขึ้นไม่เท่ากัน
แล้วจะรู้ได้ไงว่าต้องตั้งกี่ RPU
อันนี้แหละที่หลายคนติดปัญหาที่สุดครับ ทาง AWS มีแนวทางคร่าวๆให้ตามช่วงของโปรเจกต์ ถ้าเพิ่งเริ่มโปรเจกต์ใหม่ยังไม่รู้ Pattern การใช้งานที่แน่ชัด แนะนำให้เริ่มที่ค่าต่ำสุดของ Base RPU ในโซนของเราไปก่อน (ประมาณ 4 ถึง 24 RPU) แล้วค่อยสังเกตว่า Query ช้าหรือมีการ Spill ลง Disk ไหม ถ้าเจอปัญหาค่อยขยับ Base ขึ้นไปทีละสเต็ป
พอโปรเจกต์เริ่มโตขึ้นมาหน่อย แนะนำให้ขยับไป Base 32 RPU แล้วเปิด AI-driven scaling ที่ Price-performance target 50 หรือที่เรียกว่า Balanced เพราะ AI-driven scaling ต้องการ Base ขั้นต่ำ 32 RPU ถึงจะเปิดใช้ได้ครับ ส่วนถ้าเป็น Workload ที่นิ่งแล้ว ใช้งานมานานพอสมควร ก็แนะนำให้เริ่มที่ AI-driven scaling ตรงๆเลยที่ Target 50 แล้วค่อยขยับขึ้นไปทาง 75-100 ถ้ายังช้าอยู่ หรือขยับลงมาทาง 25 ถ้ารู้สึกว่าจ่ายแพงเกินความจำเป็น
ถ้าอยากได้ตัวเลขคร่าวๆอ้างอิงจากขนาดข้อมูลที่ Query สแกน ทาง AWS แนะนำประมาณนี้ครับ 32 RPU รองรับ Query ที่สแกนข้อมูลได้ราวๆ 100 GB, 64 RPU รองรับได้ราวๆ 250 GB และ 128 RPU รองรับได้ราวๆ 500 GB แต่ย้ำว่าเป็นแค่จุดเริ่มต้นให้ลองเทียบเท่านั้นนะครับ เพราะความต้องการจริงขึ้นกับรูปแบบ Query ด้วย ทั้ง Join, Aggregation หรือจำนวน Column ไม่ใช่แค่ขนาดข้อมูลอย่างเดียว
จุดที่หลายคนเข้าใจผิด ตั้ง RPU สูงไม่ได้แปลว่าแพงขึ้นเสมอไป
ตรงนี้ผมว่าเป็นจุดที่คนงงกันเยอะที่สุดเลยครับ 😆 เพราะโดยสัญชาตญาณเราจะคิดว่ายิ่งตั้ง RPU สูง ยิ่งต้องจ่ายแพงขึ้น แต่จริงๆแล้วเราจ่ายตาม RPU คูณเวลา ไม่ใช่ RPU เฉยๆ ลองดูตัวอย่างนี้ครับ Query เดียวกันเป๊ะ รันที่ 32 RPU ใช้เวลา 60 นาที กับรันที่ 128 RPU ใช้เวลาแค่ 15 นาที ทั้งสองแบบคิดเป็นเงินเท่ากันคือ $11.52 พอดี
เพราะฉะนั้นการตั้ง RPU ต่ำเกินไปไม่ได้แปลว่าจะประหยัดเสมอไป ถ้ามันทำให้ Query กินเวลานานขึ้นจนรวมแล้ว RPU-ชั่วโมงเท่าเดิม แถมยังอาจเจอปัญหา Query Spill ลง Disk ซึ่งช้ากว่าการทำงานใน Memory ถึง 5 ถึง 10 เท่าอีกด้วย การประหยัดจะเกิดขึ้นจริงก็ต่อเมื่อ Workload ต้องการทรัพยากรน้อยจริงๆเท่านั้น ไม่ใช่แค่เราตั้งค่าต่ำไว้เฉยๆครับ
แล้วเมื่อไหร่ควรใช้ Provisioned Reserved Instance แทน Serverless
Serverless ไม่ได้ถูกที่สุดเสมอไปนะครับ ถ้า Workload ของเรานิ่งมากๆ ทำงานปริมาณเท่าเดิมตลอด 24 ชั่วโมง 7 วันแบบไม่ค่อยมี Variability เลย เช่นระบบรับข้อมูล IoT ที่ไหลเข้ามาต่อเนื่อง กรณีแบบนี้ตัว Provisioned cluster แบบ Reserved 3 ปี อาจถูกกว่า Serverless จริงๆ เพราะเราไม่ได้ใช้ความยืดหยุ่นแบบ On-demand ของ Serverless เลย
ลองดูตัวอย่างเทียบราคาแบบ 8 RPU Serverless กับ Provisioned cluster 4 Node ที่ให้ Memory เท่ากันครับ ถ้าใช้แบบ On-demand ทั้งคู่ Serverless จะถูกกว่าราว 50% แต่พอ Provisioned ไป Reserve 1 ปีแบบ No upfront ราคาจะใกล้เคียงกันมาก ต่างกันแค่ประมาณ 5% เท่านั้น และถ้า Reserve ยาวไป 3 ปีเลย Provisioned จะถูกกว่า Serverless ถึง 35% เลยทีเดียว
แต่ประเด็นคือ การ Reserve 3 ปีเป็นการผูกมัดระยะยาวมาก ซึ่งเทคโนโลยีเปลี่ยนเร็วทุกปี เพราะฉะนั้นควรมั่นใจจริงๆว่า Workload จะนิ่งแบบนี้ไปอีกนานก่อนตัดสินใจครับ
อีกจุดหนึ่งที่อยากแทรกไว้ตรงนี้คือเรื่อง Cold start ครับ ถึงแม้ Serverless จะไม่คิดเงินตอน Idle เลยก็จริง แต่ถ้า Workgroup ว่างจนถูก Scale ลงไปเหลือศูนย์ พอมี Query แรกเข้ามาใหม่ ตัว Warehouse ต้อง Spin ขึ้นมาก่อน ซึ่งจากการทดสอบของหลายที่มักเจอ Latency เพิ่มขึ้นประมาณ 10 ถึง 30 วินาทีก่อนที่จะกลับมาทำงานความเร็วปกติ (ตัวเลขนี้ไม่ใช่ตัวเลขทางการจาก AWS โดยตรงนะครับ เป็นผลจากการทดสอบของ Third-party อีกที) ถ้าเป็น Batch job ที่รันตอนกลางคืนแบบไม่มีคนรอผลอยู่ อีก 10-30 วินาทีก็ไม่ใช่เรื่องใหญ่อะไร แต่ถ้าเป็น Dashboard ที่มีคนนั่งจ้องหน้าจอรอ Loading อยู่ อันนี้ควรทดสอบให้ดีก่อนตัดสินใจใช้ Serverless เต็มตัว หรือจะตั้ง Query เล็กๆรันเป็นระยะเพื่อ Keep warm ไว้ก็ช่วยได้เหมือนกันครับ ส่วน Provisioned cluster ที่รันอยู่ตลอดจะไม่เจอปัญหานี้เลย เพราะไม่มีสถานะ Idle ที่ต้อง Scale ลงศูนย์แบบ Serverless
สรุปประมาณนี้ว่า
ถ้าใครกำลังเริ่มโปรเจกต์ใหม่ หรือยังไม่รู้ Pattern การใช้งานที่ชัดเจน แนะนำให้เริ่มที่ Serverless ตั้ง Base RPU ต่ำๆไว้ก่อน แล้วค่อยสังเกตและปรับขึ้นตามจริง ไม่ต้องรีบเดา RPU สูงๆไว้ล่วงหน้า เพราะเสี่ยงจ่ายแพงเกินความจำเป็นโดยไม่จำเป็นเลยครับ ส่วนถ้าโปรเจกต์เริ่มโตแล้ว อยากได้ Performance ที่สม่ำเสมอโดยไม่ต้องมานั่งปรับ RPU เอง AI-driven scaling ที่ Target 50 คือคำตอบที่ตอบโจทย์ที่สุด
แต่ถ้า Workload ของใครนิ่งมากจริงๆ ทำงานเดิมๆตลอด 24 ชั่วโมงแบบไม่มี Peak ไม่มี Idle เลย อันนี้ ควรลองเทียบราคากับ Provisioned แบบ Reserved 3 ปีดูก่อน เพราะมีโอกาสสูงที่จะถูกกว่า Serverless จริงๆ
สุดท้ายอย่าลืมว่าตัวเลข Rate และช่วง RPU ที่ตั้งได้ เปลี่ยนแปลงได้เรื่อยๆตามที่ AWS อัปเดต ก่อนเอาไปทำ Estimate งบจริงจัง แนะนำให้ย้อนกลับไปเช็คหน้า Pricing อีกทีเสมอนะครับ 🚀
ref:
https://aws.amazon.com/redshift/pricing/ https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-billing.html https://repost.aws/articles/ARPo2EYjL6ST-Cr9ysyPp07w/how-should-i-size-amazon-redshift-for-my-project
Blog 
Leave a comment