[AWS Re:Invent 2023] Best practices for resilient systems

Created
Nov 30, 2023
Created by
Tags
AWS
Property
 
 
참고문서
 
 

 

우리가 생각하는 시스템 실패 원인

  • disk faults
  • clock skew
  • os
  • network
우리는 하드웨어/소프트웨어 튼튼함은 챙기지만 배포 후 운영에 필요한 투자(로깅, 지표수집, 배포절차 대상으로 하는 투자)는 적게 하는 편이다.
하지만 진짜 시스템 실패 이유의 40% 이상은 운영 오류(주로 휴먼 에러)에서 기인한다.
 
 

MTBF, MTTR and MTTD

  • Lower MTTD (Mean Time To Detect : 시스템 실패를 감지하기까지 소요되는 평균 시간 → detect faster)
  • Lower MTTR (Mean Time To Repair : 시스템 실패를 수리하는 데 소요되는 평균 시간 → repair/mitigate faster)
  • Higher MTBF (Mean Time Between Failure : 시스템 실패 시점부터 다음 실패까지의 평균 시간 → fail less frequently)
 
 

resiliency in operations 챙기는 방법

 

Logging

 
[문제상황]
ECS 으로 구성된 애플리케이션의 로그는 CloudWatch 에 집계하고 있다. 그런데 ECS 에 장애가 발생하여 CloudWatch 에 로깅이 되지 않는 상황. 시스템을 복구했다고 하더라도 장애 기간 동안에 들어온 트래픽은 로깅이 되어있지 않아서 사후 처리가 어려웠다. 이런 상황을 방지하려면 어떻게 해야 할까?
 
MTTR 를 낮추려면 어떻게 해아 할까? → fail open 이어야 한다.
  • fail-closed : 시스템에 장애가 있으면 트래픽 받지 않겠다.
  • fail-open : 시스템에 장애가 있어도 트래픽 받겠다. → loosely coupled 구조가 필요하다.
 

Health check

[문제상황]
9시 5분 부터 9시 10분까지 전체 사용자들이 주문을 하지 못하고 9시 10분부터 20분까지는 일부 사용자들이 주문을 하지 못했다. 원인은 RDS 와 애플리케이션 사이의 transient network issue 였다. (시간대 별로 현상이 다른 것은 RDS dns 주소 캐싱이랑 연관 있는 듯?) 그러나 개발자들은 RDS 와 애플리케이션 사이에 네트워크 이슈가 있었음을 감지하지 못했다. 이러한 현상의 원인을 빨리 감지하려면 어떻게 해야 하는가?
 
MTTD를 어떻게 낮출까? → deep health check 를 한다.
  • deep health check : 헬스체크 요청이 들어오면 RDS 까지 요청을 넘기고 RDS 에서 특정 횟수 이상 응답을 하지 않으면 RDS 에 문제가 있다고 판단한다.
  • 하지만 deep health check 해야 할 리소스들이(RDS ElasticCache, S3 등) 너무 많으면? → 스모크테스트 어쩌고 했는데 잘 못알아들었다.. 스모크 테스트 대상 API를 헬스체크에 태우라는 건가..
  • shallow health check : 애플리케이션이 건강한지만 확인
  • deep health check 에서 주의해야 할 것 : ELB 에서 auto scaling group 대상으로 deep health check 하게 하지 마라
    • RDS 가 unhealthy 하다면 ec2 는 ELB 의 health check 에 OK 으로 응답하지 못할 것이고 ELB 는 타겟 그룹에서 모든 ec2 를 셧다운시키고 새로 ec2 를 띄우려고 할 것임 → 다운타임 발생
    • deep health check 하는 인스턴스를 타겟 그룹 밖에서 따로 띄워야 할 듯.
    • [참고문서] Choosing the right health check with Elastic Load Balancing and EC2 Auto Scaling
 

Safe deployment

[문제상황]
영업 시간 시작 전에 디비 버전을 업그레이드하는 메인터넌스가 끝나야 하는데 끝나지 않아서 영업 시작 후 100% request failure 가 발생했다. 이런 일이 생기지 않으려면 어떻게 해야 할까?
 
→ 메인터넌스 하기 전에 IaaS 서비스 상태를 확인하는 절차를 만들어라.
  • AWS 서비스가 health check 에 정상으로 응답하지 않으면 디비 버전 업그레이드 중지하는 파이프라인을 만들어라. (내부적으로 어떻게 되어있는지는 잘 못알아들었는데 대충 AWS Health 는 very deep health check 를 수행한다고 함.)