[AWS Technical Support Note] วิธีตรวจสอบ ALB (Application Load Balancer) ว่ามีปัญหาคอขวดหรือไม่

บทความนี้จะรวบรวมวิธีการตรวจสอบและรับมือกับปัญหาคอขวดว่าเกิดจาก ALB มีการเข้าถึงเพิ่มขึ้นอย่างกะทันหันหรือไม่

#Classmethod Thailand

#Thai Language

#AWS

#AWS-Thai

#Thai Technical Support

Piyachart Temwipartsiri

2024.01.31

ปัญหาที่เกิดขึ้น　

มีการเข้าถึง ALB (Application Load Balancer) เพิ่มขึ้นอย่างรวดเร็วและส่งผลให้การประมวลผลล่าช้า และยังเกิด Server Error อยู่ในระยะเวลาหนึ่ง เลยต้องการตรวจสอบว่าปัญหาคอขวดที่เกิดขึ้นมาจากฝั่ง ALB หรือฝั่ง backend server กันแน่ และขอทราบวิธีตรวจสอบขีดจำกัดประสิทธิภาพของ ALB ด้วยครับ

วิธีแก้ปัญหา　

เนื่องจาก ALB จะปรับขนาด(scaling) ภายในตามสถานะของ workload โดยไม่ได้มีการเปิดเผยข้อมูลจำนวนการเชื่อมต่อสูงสุด
ด้วยเหตุนี้ จึงไม่สามารถตรวจสอบขีดจำกัดประสิทธิภาพของ ALB ได้อย่างแน่ชัด แต่สามารถตรวจสอบตัวชี้วัดดังต่อไปนี้ (1) ～ (3) เพื่อตรวจสอบว่า ALB หรือ backend ตัวไหนที่ทำให้เกิดปัญหาคอขวดขึ้น

(1) ตรวจสอบว่าในเวลาดังกล่าวมีการปรับขนาด (scaling) ของ ALB หรือไม่

เมื่อการเชื่อมต่อไปยัง ALB ถึงขีดจำกัดของ physical node แล้ว ระบบจะปรับขนาดโดยอัตโนมัติ และจะสร้าง ENI (network interface) ด้วยเสมอ

ดังนั้น การตรวจสอบเวลาที่มีการเข้าถึงเพิ่มขึ้นอย่างรวดเร็วนั้นว่ามี ENI ถูกสร้างขึ้นหรือไม่ ก็จะสามารถระบุได้ว่ามีการปรับขนาดเกิดขึ้นหรือไม่ (ถึงขีดจำกัดของ node หรือไม่) โดยสามารถใช้ CloudTrail ในการตรวจสอบได้ด้วยขั้นตอนดังต่อไปนี้

ในประวัติของ CloudTrail event ให้กรองตามวันที่มีการเข้าถึงเพิ่มขึ้นอย่างรวดเร็ว และค้นหา event ที่ชื่อ CreateNetworkInterface

ตรวจสอบรายละเอียดของ event หากมีชื่อ ALB ที่เกี่ยวข้องแสดงอยู่ในรายการ description ก็จะสามารถระบุได้ว่ามีการปรับขนาดบน ALB ที่เกี่ยวข้อง

(2) ตรวจสอบการเชื่อมต่อที่ถูกปฏิเสธเนื่องจากขีดจำกัดจากทางฝั่ง ALB

หากตรวจสอบ ALB เป้าหมายบน CloudWatch และพบว่ามีระบุ metric RejectedConnectionCount ในช่วงเวลาที่เกิดการเข้าถึงเพิ่มขึ้นอย่างรวดเร็ว แสดงว่ามีการเชื่อมต่อที่ไม่สามารถประมวลผลได้เนื่องจากขีดจำกัดจำนวนการเชื่อมต่อของ ALB

อ้างอิงจาก เอกสาร [1]

RejectedConnectionCount
The number of connections that were rejected because the load balancer had reached its maximum number of connections.

*ถึงแม้ RejectedConnectionCount จะไม่ได้แสดงขึ้นมาก็ตาม ALB ก็อาจเกิดการปรับขนาด (scaling) ขึ้นได้ ดังนั้นไม่ว่าจะถึงขีดจำกัดประสิทธิภาพของ ALB หรือไม่ ก็ไม่ควรพิจารณาจาก metric เพียงอย่างเดียว แต่ควรพิจารณาร่วมกับ (1) ที่กล่าวไว้ข้างต้นด้วย

(3) ตรวจสอบสาเหตุของข้อผิดพลาดของเซิร์ฟเวอร์ว่าเกิดจากฝั่ง backend หรือไม่

หากไม่สามารถตรวจสอบตามวิธี (1) และ (2) ได้ อาจเกิดปัญหาคอขวดจากประสิทธิภาพที่จำกัดในฝั่ง backend server (EC2 หรือ ECS) มาลองตรวจสอบกันว่ามีการตัวบ่งชี้ใดๆต่อไปนี้หรือไม่

・ หากมีการบันทึก metric HTTPCode_Target_5XX_Count บนฝั่ง ALB แสดงว่ามีการตอบกลับข้อผิดพลาด server error กลุ่ม 500 ภายใน backend server ยิ่งไปกว่านั้น หาก TargetResponseTime มีการเพิ่มขึ้น ก็สามารถระบุได้ว่าการประมวลผลที่ล่าช้าเกิดขึ้นที่ฝั่ง backend ไม่ใช่ฝั่ง ALB

อ้างอิงจาก เอกสาร [1]

HTTPCode_Target_5XX_Count
The number of HTTP response codes generated by the targets. This does not include any response codes generated by the load balancer.

TargetResponseTime
The time elapsed, in seconds, after the request leaves the load balancer until a response from the target is received.。

・ ตรวจสอบ Metric และ Log ภายในฝั่ง backend server (EC2) หากมีอัตราการใช้งาน CPU หรือหน่วยความจำเพิ่มขึ้นในช่วงเวลานั้น เป็นไปได้ว่ากระบวนการภายใน backend server อาจเกิดปัญหาคอขวดขึ้น

ควรทำอย่างไรหาก ALB เกิดปัญหาคอขวด

หากคุณมีการสมัครแผนที่สามารถใช้บริการสนับสนุนจาก AWS ได้ หรือ สามารถคาดการณ์วันและเวลาที่จะมีการเข้าถึง ALB เพิ่มขึ้นได้ล่วงหน้า ลองพิจารณาการยื่นขอ Pre-warming ELB กับฝ่ายสนับสนุนของ AWS

หากต้องการการรับมือในช่วงที่เกิดการเข้าถึงเพิ่มขึ้นอย่างคาดไม่ถึง ควรพิจารณาเปลี่ยนไปใช้ NLB (Network Load Balancer)
ซึ่งไม่ต้องทำ Pre-warming และยังสามารถประมวลผลคำขอได้มากกว่า ALB อีกด้วย

※ อย่างไรก็ตาม มีบางฟังก์ชันที่ใช้ได้เฉพาะใน ALB เท่านั้น (เช่น การผสานรวมกับ AWS WAF หรือ Listener rules) ก็อาจไม่สามารถเปลี่ยนเป็น NLB ได้

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