estudy 한국어/English

장애 대응 시 우선순위 판단 기준

1,478 단어·3 분·원문(.md)

장애 발생 시 가장 흔히 하는 치명적인 실수는 왜 터졌는지를 찾느라 시간을 허비하는 것인데.

왜 중요하지 않냐 싶을 수 잇지만 핀트는 당장 고객이 결제를 못하고있는데 스레드 덤프나 코드를 보고 디버깅하기보다는 어쨋든 고객을 성공시키는게 맞지 않냐는 말이다.

원인 파악은 서비스가 정상화 된이후나 회고하면서 사후 분석 (포스트 모텀)을 하는것이며 장애 상황에서는 최우선 목표가 수단과 방법을 가리지 않고 서비스 상태를 이전으로 되돌려 놓는 것이다.

우선순위를 결정하는 3가지 핵심 기준 #

모든 api와 서비스의 가치는 동등하지 않다. 서비스의 tier에 따라 최우선으로 살려야할 대상을 결정하자

  • Tier 1: 인증, 로그인, 결제, 핵심 도메인을 무조건 1순위
  • Tier 2: 검색, 추천, 프로필 수정과같은 안되면 불편하지만 돈이 바로 새어나가지는 않는
  • Tier 3: 내부 어드민, 통계 배치, 로그 수집 같은 장애시 과감하게 서버를 내려도 괜찮은.

모든것이 그렇지 않겠지만 보편적으로 이런느낌으로 티어를 정할 수 있다.

연쇄 장애 위험성 cascading failure #

하나의 장애가 다른 멀쩡한 시스템까지 끌고 내려갈 위험이 있는지를 본다.

격리된 장애는 특정 추천 api만 500 에러를 뱉고 끝나는 경우라 우선순위가 낮은데

전파되는장애 예를들어 추천 api가 느려져 공용 db 커넥션풀을 다 물고 늘어져, 멀쩡하던 결제 api까지 타임아웃이 나는 경우 (우선순위 최상)이다. 추천 api를 차단하거나 circuit break하여 db를 살리는것이 최우선 조치

조치의 신속성 #

당장 스위치를 내려서 끌수있는가 피쳐토글같이? 아니면 코드를 핫픽스해 배포해야하는가?

시간이 오래걸리는 작업보다 1분안에 적용할 수 잇는 이전 롤백이나 스케일아웃을 먼저 실행하는 방식도 중요함

실무 장애 등급 분류 #

글로벌 it 기업및 실무 환경에서는 주로 등급 SEV 분류 체계인데 알람이 울리면 이 등급을 먼저 선언하고 움직인다.

  • SEV-1: critical 치명적 장애며 전체 서비스 다운, 결제 불가, 대규모 데이터 유실 발생이 원인이며 즉각적인 롤백, 트래픽 우회 DR, 전사 엔지니어 소집같은 대응이 발생한다
  • SEV-2: Major 심각한 장애이며 주요 기능(검색 등)마비되는것같은 문제며 해당 기능 feature toggle off, 서버 스케일 아웃등으로 1차 대응한다.
  • SEV-3: Minor 경미한 장애로 일부 유저만 간헐적 지연, 중요하지 않은 부가기능 에러같은 것이고 원인 파악후 다음 배포때 핫픽스 포함으로 대처 가능
  • SEV-4: 내부 오피스망 네트워크 불안정이나 오타같은거 이건 일과시간 티켓생성후 처리로 진행하는 편이다.

Example #

장애가 발생했을 때 디버깅보다 먼저 실행해야하는 우회 및 복구 로그 조치의 대표적인 예시 셋이다.

배포 직후 장애 발생시 즉각적인 롤백을 예로 들오보면 새로운 버전을 배포햇는데 모니터링 그래프가 곤두박질 치고 있다면 로그를 볼 게 아니라 바로 롤백을 진행하자

# 1. 특정 디플로이먼트의 배포 이력(History) 확인
kubectl rollout history deployment/my-backend-app

# 2. 직전의 정상 상태(리비전)로 즉시 롤백 (가장 많이 쓰는 마법의 명령어)
kubectl rollout undo deployment/my-backend-app

# 3. 롤백이 잘 진행되는지 실시간 상태 확인
kubectl rollout status deployment/my-backend-app

특정 api가 db를 죽이고 있다면 nginx같은걸로 긴급 차단을 해도 된다.

무거운 api 조회 /api/v1/heavy-stats이라고 쳤을대 트래픽이 몰려 db커넥션이 고갈되어 연쇄 장애 되고있다면, 백엔드 코드를 수정할 시간도없다. 앞단인 nginx에서 해당 api만 즉시 차단 503응답하여 시스템을 보호한다.

# nginx.conf (또는 해당 서버 설정)
server {
    listen 80;
    server_name api.mywebsite.com;

    # 🚨 긴급 차단: 무거운 통계 API를 일시적으로 503 에러로 튕겨냄 (서비스 보호)
    location /api/v1/heavy-stats {
        return 503 "Service Temporarily Unavailable due to high load";
    }

    # 정상 트래픽은 백엔드로 통과
    location / {
        proxy_pass http://backend_servers;
    }
}

fault injection을 해두어 일단 차단해두어 장애 연쇄를 막는 느낌이고 nginx -t && nginx -s reload (Nginx 재시작 없이 설정 즉시 반영)로 적용한다 위에예시에선 ㅇㅇ

일단 해당 api를 호출하는 유저는 에러를 받겠지만 db가 살아나므로 가장 중요한 api들이 즉시 정상화가 될 수 있으니 희생하는것.

SRE/question/q_41.md