Amazon Cloud Agent: AWS RDS สำรองข้อมูลอัตโนมัติในช่วงหน้าต่างประสิทธิภาพของฐานข้อมูลมีความผันผวนอย่างมากการวินิจฉัยและการตรวจสอบการต่อสู้จริง

วิศวกรด้านการดำเนินงานและการบำรุงรักษาและ DBA หลายคนต้องเผชิญกับสถานการณ์ที่น่าปวดหัวเช่นนี้ทุกวันในช่วงเวลาที่กำหนดในตอนเช้ากลุ่มสัญญาณเตือนระบบเริ่ม "ทิ้งระเบิด"-อัตราการใช้ CPU ฐานข้อมูลเพิ่มขึ้นอย่างรวดเร็วและจำนวนการสืบค้นช้าการเรียก API ที่พุ่งสูงขึ้นการหมดเวลาจำนวนมากในฝั่งแอปพลิเคชันและแม้แต่พูลการเชื่อมต่อฐานข้อมูลก็เต็ม

เมื่อมองไปที่แผงตรวจสอบ RDS ของ AWS Console ฉันพบว่าช่วงเวลาที่ปัญหาเกิดขึ้นตรงกับหน้าต่างสำรองข้อมูลอัตโนมัติของ RDS

การสำรองข้อมูลอัตโนมัติเดิมมีไว้เพื่อความปลอดภัยของข้อมูลและตระหนักถึงฟังก์ชัน "การช่วยชีวิต" ของการคืนค่าตามเวลา (PITR) เหตุใดจึงกลายเป็น "ตัวฆ่าประสิทธิภาพ" ของระบบธุรกิจในระหว่างการดำเนินการบทความนี้จะพาคุณไปทำความเข้าใจและแก้ไขปัญหานี้อย่างละเอียดจากสี่มิติของกลไกทางกายภาพพื้นฐานของ AWS RDS คอขวดของสถาปัตยกรรมการจัดเก็บเส้นทางการแก้ไขปัญหาการวินิจฉัยและโซลูชันการกำกับดูแลสถาปัตยกรรม

1.ติดตามแหล่งที่มา: เกิดอะไรขึ้นที่ด้านล่างของหน้าต่างสำรองข้อมูล?

ในการวินิจฉัยปัญหานี้อย่างละเอียดก่อนอื่นคุณต้องเข้าใจหลักการทำงานพื้นฐานของการสำรองข้อมูลอัตโนมัติ AWS RDS การสำรองข้อมูลสแนปชอตของ RDS ไม่ใช่ฐานข้อมูลง่ายๆ

Mysqldump

หรือการส่งออกเชิงตรรกะแต่ขึ้นอยู่กับพื้นฐาน

Amazon EBS(Elastic Block Store) ปริมาณภาพรวมระดับบล็อก (Snapshot)

。

เมื่อหน้าต่างสำรองข้อมูลอัตโนมัติเริ่มทำงาน AWS จะเรียกใช้กลไกสแนปชอตเหตุผลหลักสำหรับผลกระทบของกระบวนการนี้ต่อประสิทธิภาพของฐานข้อมูลมีดังนี้:

1.ความล่าช้า I/O ที่เกิดจากการคัดลอก (Copy-on-Write, COW) เมื่อเขียน

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

ในระหว่างขั้นตอนการสร้างสแนปชอตหากแอปพลิเคชันเริ่มดำเนินการเขียนเลเยอร์หน่วยเก็บข้อมูลจำเป็นต้องดำเนินการ "คัดลอก-on-Write" หรือเปลี่ยนเส้นทางตรรกะการเขียนสิ่งนี้จะนำไปสู่การขยายการเขียนซึ่งจะเพิ่มความล่าช้าในการอ่าน/การเขียน (Read/Write Latency) และความลึกของคิวดิสก์ (Disk Queue Depth) โดยตรง

2.ความแตกต่างของกลไก Single-AZ (Single-Available Area) และ Multi-AZ (Multi-Available Area)

สถาปัตยกรรม Single-AZ: อินสแตนซ์ RDS มีโหนดหลักเพียงโหนดเดียวและสแนปชอตจะต้องดำเนินการโดยตรงบนไดรฟ์ข้อมูลที่เก็บข้อมูล EBS ของโหนดหลักในขั้นตอนเริ่มต้นของการสร้างสแนปชอตปริมาณ EBS จะเกิดขึ้นทันที I/O Suspension (I/O Suspension) ซึ่งใช้เวลาตั้งแต่ไม่กี่วินาทีไปจนถึงหลายสิบวินาทีสำหรับบริการเขียนพร้อมกันสูงการวางสาย I/O ไม่กี่วินาทีเหล่านี้เพียงพอที่จะทำให้เกิดการสะสมของคำขอต้นน้ำและพูลการเชื่อมต่อเต็ม

สถาปัตยกรรม Multi-AZ: AWS จะทำการสำรองข้อมูลอัตโนมัติแบบกระจายอำนาจไปยังโหนดสแตนด์บาย (Standby Instance)

ได้ค่ะ/ครับในทางทฤษฎีการอ่านและเขียน I/O ของโหนดหลักจะไม่ได้รับผลกระทบโดยตรงจากสแนปชอตอย่างไรก็ตามหากประสิทธิภาพของ I/O ของโหนดสำรองลดลงเนื่องจากการสำรองข้อมูลและไม่สามารถติดตามบันทึกการจำลองแบบของโหนดหลักได้โหนดหลักอาจอยู่ภายใต้การจำลองแบบซิงโครนัส (เช่นกลไกกึ่งซิงโครไนซ์หรือบล็อกดิสก์บันทึกข้อมูล) และประสิทธิภาพจะกระวนกระวายใจ

3.การจัดเก็บ IOPS กับจุดระเบิด (Burst Balance) หมด

ถ้า RDS ใช้รุ่นเก่า

GP2 (สากล SSD)

พื้นที่จัดเก็บประสิทธิภาพ IOPS ขึ้นอยู่กับ "Burst Balance"

ในระหว่างหน้าต่างสำรองข้อมูลการอ่านสแนปชอตและการอ่านและการเขียนของธุรกิจเองสามารถเติม IOPS ของ GP2ได้อย่างรวดเร็วเมื่อจำนวนจุดหมดลงอย่างกะทันหัน IOPS ของ EBS จะตกลงไปที่ระดับพื้นฐานทันทีในลักษณะหน้าผา (ตัวอย่างเช่นพื้นฐานของที่เก็บ GP2ความจุขนาดเล็กมีเพียง100 IOPS) ซึ่งทำให้ฐานข้อมูลติดขัดโดยตรงแม้ว่า

GP3

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

2.วิธีการวินิจฉัยสี่ขั้นตอน: จะหาต้นตอของคอขวดได้อย่างไร?

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

[ขั้นตอนที่1: การจัดตำแหน่งไทม์ไลน์ของ CloudWatch] ──> [ขั้นตอนที่2: Performance Insights ตรวจสอบเหตุการณ์ที่รอ]

│

[ขั้นตอนที่4: ตรวจสอบงานตามกำหนดเวลาทางธุรกิจ/ธุรกรรมขนาดใหญ่] <─── [ขั้นตอนที่3: ตรวจสอบประเภทการจัดเก็บข้อมูลที่มีคอขวด IOPS]

ขั้นตอนที่1: การจัดแนวเส้นเวลา (เปรียบเทียบการตรวจสอบ CloudWatch)

เข้าสู่แผงตรวจสอบ CloudWatch ปรับช่วงเวลาเป็น2ชั่วโมงก่อนและหลังเกิดความผิดปกติและสังเกตตัวบ่งชี้หลักต่อไปนี้:

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

ReadIOPS / WriteIOPS และ DiskQueueDepth: ตรวจสอบว่า IOPS ถึงขีดจำกัดสูงสุดของไดรฟ์ข้อมูลที่เก็บข้อมูลปัจจุบันหรือไม่และสังเกตว่าความลึกของคิวดิสก์เกินค่าปกติหรือไม่ (โดยปกติขอแนะนำให้รักษาความลึกของคิวไว้ที่ประมาณ IOPS/500ที่กำหนดไว้ล่วงหน้าและการพุ่งสูงขึ้นบ่งชี้ว่า I/O มีงานในมือที่ร้ายแรง)

EBSSurplusBalance / BurstBalance: หากคุณใช้ที่เก็บข้อมูล GP2ให้ตรวจสอบว่าตัวบ่งชี้ Burst Balance ลดลงเหลือ0% หรือไม่

ขั้นตอนที่2: ด้วย Perfo

Rmance Insights (การวิเคราะห์เชิงลึกของประสิทธิภาพ)

Performance Insights ที่เปิด RDS สามารถช่วยให้เราเห็นว่า SQL กำลังทำให้ฐานข้อมูลช้าลงให้ความสำคัญเป็นพิเศษ

AAS(Average Active Sessions, จำนวนเซสชันที่ใช้งานอยู่โดยเฉลี่ย)

และรอเหตุการณ์ (Wait Events):

หากมี io/file/innodb/innodb_data_file หรือ IO:DataFileRead / IO:DataFileWrite รออยู่แสดงว่าคอขวดหลักจะเน้นที่ดิสก์ฟิสิคัล I/O

หากมี wait/synch/sxlock/innodb/btr_search_latch หรือรอการล็อกหน่วยความจำจำนวนมากหมายความว่าไม่สามารถปัดหน้าข้อมูลได้ทันเวลาเนื่องจากการบล็อก I/O ซึ่งจะทำให้เกิดการแย่งชิงการล็อกภายในฐานข้อมูล

ขั้นตอนที่3: ตรวจสอบสถาปัตยกรรมอินสแตนซ์และประเภทการจัดเก็บ

ยืนยันการกำหนดค่าคุณสมบัติของอินสแตนซ์ RDS ปัจจุบัน:

เป็น Single-AZ หรือ Multi-AZ?

ประเภทการจัดเก็บคือ GP2, GP3หรือ Provisioned IOPS (io1/io2)?

เครื่องมือฐานข้อมูลเปิดการล้างข้อมูล Undo Log ขนาดใหญ่หรือ Dirty Pages (หน้าสกปรก) ในสัดส่วนที่สูงหรือไม่?

ขั้นตอนที่4: แก้ไขความขัดแย้งระหว่างด้านแอปพลิเคชันและงานตามกำหนดเวลาพื้นหลัง

หลายทีมคุ้นเคยกับการดำเนินงานตามกำหนดเวลาเช่นการทำธุรกรรมระยะยาวการจัดเก็บข้อมูลและการสร้างรายงาน ETL ในเวลากลางคืนหากงานกำหนดเวลาทางธุรกิจเหล่านี้ตรงกับหน้าต่างสำรองข้อมูลอัตโนมัติ RDS ของ AWS มันจะสร้างเอฟเฟกต์การซ้อนทับของ "การเขียนและการอ่านภาพรวมที่ขยายใหญ่ขึ้น" ซึ่งจะระเบิดดิสก์ I/O โดยตรง

3.การกำกับดูแลอย่างละเอียดและแผนการเพิ่มประสิทธิภาพสถาปัตยกรรม

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

1.การอัพเกรดสถาปัตยกรรม: โซนเดียวเปลี่ยนเป็นหลายโซน (Single-AZ อัพเกรดเป็น Multi-AZ)

หากสภาพแวดล้อมการผลิต RDS ยังคงใช้ Single-AZ ขอแนะนำอย่างยิ่งให้อัปเกรดเป็นการปรับใช้ Multi-AZ

ผลกระทบ: หลังจากการอัปเกรด AWS จะถ่ายโอนงานสำรองข้อมูลอัตโนมัติรายวันไปยังโหนดสแตนด์บาย Standby โดยอัตโนมัติเพื่อดำเนินการตัดผลกระทบโดยตรงของสแนปชอต I/O ที่แขวนอยู่ในธุรกิจการผลิตโหนดหลักโดยสิ้นเชิง

2.การจัดเก็บแปลง: ไม่มีรอยต่อโยกย้ายจาก GP2ไปยัง GP3หรือที่ตั้งไว้ล่วงหน้า Provisioned IOPS

บอกลา GP2:GP2อาศัย Burst Balance ประสิทธิภาพไม่เสถียรอย่างยิ่ง GP3ให้ IOPS อิสระและความสามารถในการตั้งค่าล่วงหน้าสำหรับปริมาณงานและการกำหนดค่าพื้นฐานให้3,000 IOPS และ125 MB/s

ปริมาณงาน

ใช้ io1/io2ในสถานการณ์ที่มีภาระงานสูง: สำหรับฐานข้อมูลหลักที่มีความต้องการพร้อมกันสูงมากและมีเวลาแฝงต่ำขอแนะนำให้ใช้พื้นที่จัดเก็บ IOPS(io1/io2) ของ Provisioned โดยตรงและตั้งค่าที่ตั้งไว้ล่วงหน้า IOPS ให้เพียงพอตามความต้องการของพลังการประมวลผลทางธุรกิจ

3.จัดเรียงหน้าต่างสำรองข้อมูลใหม่และกำหนดเวลางานเซ

กำหนดหน้าต่างสำรองอีกครั้ง: ในการตั้งค่า RDS ให้ปรับหน้าต่างสำรองข้อมูลอัตโนมัติให้เป็นช่วงเวลาที่ต่ำที่สุดของปริมาณการใช้งานทางธุรกิจตลอดทั้งวัน (เช่น03:00-04:00น. ในตอนเช้า)

การเปลี่ยนแปลงสูงสุดของงานตามกำหนดเวลา: เดินโซเซงานที่กำหนดเวลาเช่นการประมวลผลชุดงานการจัดเก็บข้อมูลและการสร้างดัชนีใหม่ในระบบด้วยหน้าต่างสำรองข้อมูลอัตโนมัติเป็นเวลาอย่างน้อย1-2ชั่วโมงเพื่อหลีกเลี่ยงการซ้อนทับของการรับส่งข้อมูล

4.การรับประกันการดำเนินงานและการบำรุงรักษา: การขยายทรัพยากรระบบคลาวด์และการจัดการงบประมาณ

ไม่ว่าจะเป็นการอัปเกรด Single-AZ เป็น Multi-AZ การอัปเกรด GP2เป็น GP3/io2หรือการปรับปรุงข้อกำหนดอินสแตนซ์และการตั้งค่าล่วงหน้า IOPS ก็จะทำให้เกิดการเปลี่ยนแปลงต้นทุนโครงสร้างพื้นฐานระบบคลาวด์

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

การเติมเงินบัญชี AWS

เป็นการดำเนินการรับประกันการดำเนินงานและการบำรุงรักษาที่สำคัญหากในช่วงสูงสุดของการเปลี่ยนแปลงหรือขั้นตอนการขยายอัตโนมัติบริการถูกจำกัดหรือการเปลี่ยนแปลงถูกขัดจังหวะเนื่องจากการค้างชำระบัญชีอาจทำให้เกิดอุบัติเหตุในการผลิตที่ร้ายแรงขึ้นดังนั้นการรวมการจัดการทางการเงินและงบประมาณเข้ากับการดำเนินการและการบำรุงรักษาประจำวัน Standard Operating Procedure (SOP) จึงเป็นส่วนสำคัญในการรับรองความพร้อมใช้งานของฐานข้อมูลที่สูง

สี่สรุปและแนวทางปฏิบัติที่ดีที่สุด Checklist

ความผันผวนของประสิทธิภาพที่เกิดจากการสำรองข้อมูลอัตโนมัติ AWS RDS โดยพื้นฐานแล้ว

การจัดเก็บทางกายภาพทรัพยากร I/O ถึงคอขวดภายใต้แรงกดดันจากสแนปชอต

ศูนย์รวมของ. ด้วยการออกแบบสถาปัตยกรรมที่เหมาะสมและการปรับแต่งพารามิเตอร์ทำให้สามารถบรรลุ "การสำรองข้อมูลแบบไม่เหนี่ยวนำ" ได้อย่างสมบูรณ์

ในการดำเนินงานและการบำรุงรักษาประจำวันขอแนะนำให้ดูที่รายการตรวจสอบการปฏิบัติที่ดีที่สุด (Checklist) ต่อไปนี้:

ตรวจสอบมิติข้อมูล

ข้อกำหนดการปฏิบัติที่ดีที่สุด

คำอธิบาย

สถาปัตยกรรมการปรับใช้

ฐานข้อมูลการผลิตต้องเปิด Multi-AZ

ลดแรงดัน I/O สำรองลงในโหนดสแตนด์บาย Standby

ประเภทการจัดเก็บ

ละทิ้ง GP2และอัปเกรดเป็น GP3หรือ io1/io2

จัดเตรียม IOPS และปริมาณงานที่คาดเดาได้เพื่อหลีกเลี่ยงจุดที่ลดลงอย่างกะทันหัน

การจัดการหน้าต่าง

หน้าต่างสำรองข้อมูลเพื่อหลีกเลี่ยงจุดสูงสุดของธุรกิจ

ตรวจสอบให้แน่ใจว่าไม่มีงาน ETL หรือแบทช์ Delete/Update ในช่วงระยะเวลาการสำรองข้อมูล

การแจ้งเตือนการเฝ้าระวัง

กำหนดค่าการแจ้งเตือน CloudWatch WriteLatency และ DiskQueueDepth

พบสัญญาณของการลดลงของประสิทธิภาพการจัดเก็บข้อมูลล่วงหน้า

การดำเนินงานและการบำรุงรักษาทางการเงิน

รักษา

เติมเงินบัญชี AWS และเงินเพียงพอ

ตรวจสอบให้แน่ใจว่าการขยายตัวที่ยืดหยุ่นการเปลี่ยนแปลงการจัดเก็บและการอัปเกรด Multi-AZ เป็นไปอย่างราบรื่น

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