คู่มือการปรับขนาดแบบขนานของ Amazon RedShift และผลการทดสอบ

ที่ Skyeng เราใช้ Amazon RedShift รวมถึงการปรับขนาดแบบขนาน ดังนั้นเราจึงพบบทความนี้โดย Stefan Gromoll ผู้ก่อตั้ง dotgo.com สำหรับ intermix.io ที่น่าสนใจ หลังจากการแปล ประสบการณ์เล็กน้อยของเราจากวิศวกรข้อมูล Daniyar Belkhodzhaev

สถาปัตยกรรม Amazon RedShift อนุญาตให้ปรับขนาดโดยการเพิ่มโหนดใหม่ให้กับคลัสเตอร์ ความจำเป็นในการจัดการกับคำขอที่มีจำนวนสูงสุดอาจนำไปสู่การจัดสรรโหนดมากเกินไป Concurrency Scaling แทนที่จะเพิ่มโหนดใหม่ จะเพิ่มพลังการประมวลผลตามความจำเป็น

การปรับขนาดแบบขนานของ Amazon RedShift ช่วยให้คลัสเตอร์ RedShift มีความจุเพิ่มเติมเพื่อรองรับปริมาณคำขอที่มีปริมาณสูงสุด ทำงานโดยการย้ายคำขอไปยังคลัสเตอร์ "คู่ขนาน" ใหม่ในเบื้องหลัง คำร้องขอถูกกำหนดเส้นทางตามการกำหนดค่าและกฎ WLM

ราคาการปรับขนาดแบบขนานจะขึ้นอยู่กับโมเดลเครดิตที่มี Free Tier นอกเหนือจากเครดิตฟรีแล้ว การชำระเงินจะขึ้นอยู่กับเวลาที่ Parallel Scaling Cluster ดำเนินการตามคำขอ

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

ข้อกำหนดของคลัสเตอร์

หากต้องการใช้การปรับขนาดแบบขนาน คลัสเตอร์ Amazon RedShift ของคุณต้องเป็นไปตามข้อกำหนดต่อไปนี้:

- แพลตฟอร์ม: EC2-VPC;
— ประเภทโหนด: dc2.8xlarge, ds2.8xlarge, dc2.large หรือ ds2.xlarge;
— จำนวนโหนด: ตั้งแต่ 2 ถึง 32 (ไม่รองรับคลัสเตอร์โหนดเดียว)

ประเภทคำขอที่ยอมรับได้

การปรับสเกลแบบขนานไม่เหมาะกับการค้นหาทุกประเภท ในเวอร์ชันแรก จะประมวลผลเฉพาะคำขออ่านที่ตรงตามเงื่อนไขสามประการเท่านั้น:

— คำสั่ง SELECT เป็นแบบอ่านอย่างเดียว (แม้ว่าจะมีการวางแผนประเภทเพิ่มเติมไว้ก็ตาม)
— แบบสอบถามไม่ได้อ้างอิงตารางที่มีรูปแบบการเรียงลำดับแบบ INTERLEAVED
- การสืบค้นไม่ได้ใช้ Amazon RedShift Spectrum เพื่ออ้างอิงตารางภายนอก

หากต้องการกำหนดเส้นทางไปยัง Parallel Scaling Cluster จะต้องจัดคิวคำขอ นอกจากนี้ แบบสอบถามที่มีสิทธิ์สำหรับคิว SQA (การเร่งแบบสอบถามสั้น)จะไม่ทำงานบนคลัสเตอร์ขนาดขนาน

คิวและ SQA จำเป็นต้องมีการกำหนดค่าที่เหมาะสม การจัดการปริมาณงาน Redshift (WLM). เราขอแนะนำให้ปรับ WLM ของคุณให้เหมาะสมก่อน ซึ่งจะช่วยลดความจำเป็นในการปรับขนาดแบบขนาน และนี่เป็นสิ่งสำคัญเนื่องจากการปรับขนาดแบบขนานนั้นฟรีตามจำนวนชั่วโมงที่กำหนดเท่านั้น AWS อ้างว่าการปรับขนาดแบบขนานจะให้บริการฟรีสำหรับลูกค้า 97% ซึ่งนำเราไปสู่ประเด็นเรื่องราคา

ค่าใช้จ่ายในการขยายขนาดแบบขนาน

AWS เสนอโมเดลเครดิตสำหรับการปรับขนาดแบบขนาน แต่ละคลัสเตอร์ที่ใช้งานอยู่ อเมซอน Redshift สะสมเครดิตทุกชั่วโมง เครดิต Parallel Scaling ฟรีสูงสุดหนึ่งชั่วโมงต่อวัน

คุณจะชำระเงินเฉพาะเมื่อการใช้งาน Parallel Scaling Clusters ของคุณเกินจำนวนเครดิตที่คุณได้รับ

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

เปิดตัว Parallel Scaling

การปรับสเกลแบบขนานจะถูกทริกเกอร์สำหรับแต่ละคิว WLM ไปที่คอนโซล AWS RedShift และเลือกการจัดการภาระงานจากเมนูการนำทางด้านซ้าย เลือกกลุ่มพารามิเตอร์ WLM ของคลัสเตอร์ของคุณจากเมนูแบบเลื่อนลงต่อไปนี้

คุณจะเห็นคอลัมน์ใหม่ชื่อ "Concurrency Scaling Mode" ถัดจากแต่ละคิว ค่าเริ่มต้นคือ "ปิดใช้งาน" คลิก "แก้ไข" และคุณสามารถเปลี่ยนการตั้งค่าสำหรับแต่ละคิวได้

องค์ประกอบ

การปรับขนาดแบบขนานทำงานโดยการส่งต่อคำขอที่เหมาะสมไปยังคลัสเตอร์เฉพาะใหม่ คลัสเตอร์ใหม่มีขนาด (ประเภทและจำนวนโหนด) เท่ากันกับคลัสเตอร์หลัก

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

การตรวจสอบ

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

จำนวนคลัสเตอร์การปรับขนาดที่ใช้งานอยู่จะแสดงอยู่ในอินเทอร์เฟซผู้ใช้ในส่วน “กิจกรรมการปรับขนาดพร้อมกัน”:

ในแท็บแบบสอบถาม มีคอลัมน์ที่ระบุว่าแบบสอบถามถูกดำเนินการในคลัสเตอร์หลักหรือในคลัสเตอร์มาตราส่วนแบบขนาน:

ไม่ว่าการสืบค้นเฉพาะเจาะจงจะดำเนินการในคลัสเตอร์หลักหรือผ่านคลัสเตอร์การปรับขนาดแบบขนานก็ตาม การสืบค้นดังกล่าวจะถูกจัดเก็บไว้ใน stl_query.concurrency_scaling_status

ค่า 1 บ่งชี้ว่าการสืบค้นถูกดำเนินการในคลัสเตอร์มาตราส่วนขนาน ในขณะที่ค่าอื่น ๆ บ่งชี้ว่าการสืบค้นถูกดำเนินการในคลัสเตอร์หลัก

ตัวอย่าง:

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

ผลการวิจัย

ผู้เขียนเริ่มการปรับขนาดแบบขนานสำหรับหนึ่งคิวในคลัสเตอร์ภายในเมื่อเวลาประมาณ 18:30:00 น. GMT ในวันที่ 29.03.2019/3/20 เปลี่ยนพารามิเตอร์ max_concurrency_scaling_clusters เป็น 30 เมื่อเวลาประมาณ 00:29.03.2019:XNUMX น. ของวันที่ XNUMX/XNUMX/XNUMX

เพื่อจำลองคิวคำขอ เราได้ลดจำนวนช่องสำหรับคิวนี้จาก 15 เป็น 5

ด้านล่างนี้เป็นแผนภูมิแดชบอร์ด intermix.io ที่แสดงจำนวนคำขอที่ทำงานและเข้าคิวหลังจากลดจำนวนช่องแล้ว

เราพบว่าเวลารอคำขอในคิวเพิ่มขึ้นโดยมีเวลาสูงสุดมากกว่า 5 นาที

นี่คือข้อมูลที่เกี่ยวข้องจากคอนโซล AWS เกี่ยวกับสิ่งที่เกิดขึ้นในช่วงเวลานี้:

Redshift เปิดตัวคลัสเตอร์การปรับขนาดแบบขนานสาม (3) คลัสเตอร์ตามที่กำหนดค่าไว้ ดูเหมือนว่าคลัสเตอร์เหล่านี้มีการใช้งานน้อยเกินไป แม้ว่าคำขอจำนวนมากในคลัสเตอร์ของเราจะอยู่ในคิวก็ตาม

กราฟการใช้งานมีความสัมพันธ์กับกราฟกิจกรรมการปรับขนาด:

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

ผลการวิจัย

การปรับสเกลแบบขนานสามารถลดเวลาที่คำขอใช้ในคิวระหว่างที่มีการใช้งานสูงสุดได้

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

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

แม้ว่าการปรับสเกลแบบขนานจะไม่ใช่โซลูชันสากลสำหรับการตั้งค่า WLM แต่การใช้คุณลักษณะนี้ทำได้ง่ายและตรงไปตรงมา

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

เนื่องจาก AWS เพิ่มการรองรับประเภทการสืบค้นและตารางเพิ่มเติม การปรับขนาดแบบขนานจึงจะค่อยๆ มีประสิทธิภาพมากขึ้นเรื่อยๆ

ความคิดเห็นจาก Daniyar Belkhodzhaev วิศวกรข้อมูล Skyeng

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

บังเอิญว่าในช่วงกลางเดือนเมษายน เรามีคำขอไปยังคลัสเตอร์ Redshift จำนวนมากผิดปกติ ในช่วงเวลานี้ เรามักจะหันไปใช้ Concurrency Scaling บางครั้งคลัสเตอร์เพิ่มเติมจะทำงานตลอด 24 ชั่วโมงโดยไม่หยุด

สิ่งนี้ทำให้เป็นไปได้หากไม่สามารถแก้ไขปัญหาคิวได้อย่างสมบูรณ์ อย่างน้อยก็ทำให้สถานการณ์เป็นที่ยอมรับได้

การสังเกตของเราส่วนใหญ่ตรงกับความประทับใจของคนจาก intermix.io

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

หลังจากที่กำจัดโหลดที่ผิดปกติออกไปในเดือนเมษายน เราก็เข้าสู่โหมดการใช้งานเป็นครั้งคราวตามที่ AWS คาดไว้ - ภายใน Free Norm
คุณสามารถติดตามต้นทุนการปรับขนาดแบบขนานได้ใน AWS Cost Explorer คุณต้องเลือกบริการ - Redshift ประเภทการใช้งาน - CS เช่น USW2-CS:dc2.large

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับราคาในภาษารัสเซีย ที่นี่

ที่มา: will.com