API 장애 자동 복구 (트리거 설계, 복구 전략, 안전 장치)
API 장애는 평균 감지부터 수동 대응까지 최소 수 분이 걸립니다. API 장애 대응에서 가장 중요한 요소는 속도입니다. 장애는 대부분 짧은 시간 안에 급격하게 확산되며, 대응이 지연될수록 시스템 전체에 미치는 영향은 기하급수적으로 증가합니다. 기존의 운영 방식에서는 모니터링을 통해 장애를 감지하고, 담당자가 이를 확인한 후 수동으로 대응하는 구조가 일반적이었습니다. 그러나 이 방식은 인간의 인지 속도와 의사결정 과정에 의존하기 때문에, 실시간 대응이 필요한 환경에서는 명확한 한계를 가집니다. 이러한 문제를 해결하기 위해 등장한 개념이 바로 자동 복구 전략입니다. 트리거 설계: 언제 시스템이 스스로 깨어나야 하는가 자동 복구에서 가장 먼저 물어봐야 할 것이 있습니다. "어떤 상황에서 시스템이 스스로 대응해야 하는가?" 이 질문에 제대로 답하지 못하면, 자동화는 오히려 더 큰 혼란을 만들어냅니다. 에러율 하나만 보고 트리거를 걸었더니, 배치 작업 중 일시적인 오류가 복구 루틴을 반복 실행시켜 멀쩡한 서비스가 재시작되는 황당한 상황이 벌어졌습니다. 트리거는 SLO(서비스 수준 목표, 즉 서비스가 얼마나 안정적으로 운영되어야 하는지 정의한 기준)를 기반으로 설계하는 것이 맞습니다. 에러율이 올라갔는가, 응답 지연이 특정 임계값을 넘었는가, 이 두 가지가 동시에 충족되는 복합 조건을 써야 오탐(False Positive, 실제 장애가 아닌데 장애로 잘못 감지하는 것)이 줄어듭니다. 단일 지표는 생각보다 거짓말을 자주 합니다. "에러율 5% 이상 + 해당 엔드포인트 호출 집중"처럼 맥락을 포함한 조건이 훨씬 안정적이었습니다. 트래픽이 극도로 낮은 시간대에 에러 1~2건이 나면 에러율이 순간적으로 높게 잡히는 경우가 있는데, 이걸 복합 조건이 걸러줍니다. 설계 단계에서 이 부분을 충분히 테스트하지 않으면 나중에 꼭 후회하게 됩니다. 복구 전략: 재시도, 스케일링, 격리 중 무엇을 선택할 것인가 트리거가 발동하면 다음 질...