ECS เริ่มการทำงานใหม่เนื่องจากความล้มเหลวของ health_check เมื่อคำขออื่นๆ หลายรายการส่งคืนช้า

เราสังเกตเห็นว่าบริการแบ็กเอนด์ ECS Fargate ของเราเริ่มต้นใหม่เนื่องจากหมดเวลาตอบสนองในการตรวจสอบความสมบูรณ์:

(บริการไซต์ของเรา-com-stack-BackendApiServiceStack...) (พอร์ต 8000) ไม่แข็งแรงใน (กลุ่มเป้าหมาย arn:aws:elasticloadbalancing:us-east-1:1234:targetgroup/dev-d-ABC-ABC123/ ABC123) เนื่องจาก (เหตุผลที่คำขอหมดเวลา)

เรากำลังพยายามหาวิธีดำเนินการตรวจสุขภาพในแอปพลิเคชันของเราสำหรับ ECS ที่จะไม่รีสตาร์ทบริการโดยไม่จำเป็นเมื่อใดก็ตามที่ฐานข้อมูลไม่ว่าง (หรือคำขออื่นๆ ที่ช้ากำลังรอดำเนินการ)

เดิมทีเรารู้สึกว่าสถานการณ์อาจคล้ายกับที่อธิบายไว้ที่นี่: https://cloudsoft.io/blog/consequences-of-bad-health-checks-in-aws-application-load-balancer. โดยพื้นฐานแล้ว หากฐานข้อมูลของเราไม่ว่าง/ช้า คำขออาจหมดเวลา

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

ใน AWS Application Stack ของเรา Route 53 ใช้เพื่อกำหนดเส้นทางการรับส่งข้อมูลไปยังการกระจาย CloudFront ของเรา CloudFront กำหนดเส้นทางการรับส่งข้อมูลสำหรับปลายทางนี้ไปยัง Application Load Balancer สำหรับแอปพลิเคชัน Django

การตรวจสุขภาพของเราเป็นส่วนหนึ่งของแอปพลิเคชัน Django และโดยพื้นฐานแล้วจะตอบกลับเพียง 200 รายการ:

def health_check (คำขอ):
    ตอบกลับ = JsonResponse({"ข้อความ": "ตกลง"})
    ตอบกลับ

นี่คือวิธีการตั้งค่าการตรวจสุขภาพของเราใน CDK:

        self.https_listener = self.alb.add_listener(
            "HTTPSListener",
            พอร์ต = 443,
            ใบรับรอง = [scope.certificate],
            เปิด=จริง,
        )

        ขอบเขตhttps_listener.add_targets(
            "แบ็กเอนด์เป้าหมาย",
            พอร์ต = 80,
            targets=[self.backend_service],
            ลำดับความสำคัญ = 2,
            path_patterns=["*"],
            health_check=elbv2.HealthCheck(
                healthy_http_codes="200-299",
                เส้นทาง="/api/core/health-check/",
            ),
        )

คำสั่งที่เริ่มต้นเซิร์ฟเวอร์ที่ใช้งานจริงของเราคือ:

GEVENT_RESOLVER=ares gunicorn -t 1,000 -k gevent -w 4 -b 0.0.0.0:8000 backend.wsgi

ในระหว่างการทดสอบที่ไม่เกี่ยวข้องกัน เราสามารถจำลองปัญหาเดิมโดยใช้ Daphne:

แดฟนี -b 0.0.0.0 -p 8000 backend.asgi:application

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