장애 대비 체크리스트 — 트래픽보다 의존성부터

용량 계획을 열심히 했어요. 부하 테스트도 하고, 오토스케일도 켜고, 여유 용량도 뒀어요.

그런데 실제로 겪은 장애들을 돌아보니 트래픽 때문에 무너진 건 거의 없었어요. 결제사가 느려졌고, 인증 서비스가 죽었고, 인증서가 만료됐고, 설정 변경이 잘못됐고, 이름 해석이 안 됐어요.

트래픽은 그날도 평소와 같았어요.

우리가 대비한 것과 실제로 일어나는 것이 다릅니다.

그리고 그 차이를 아는 것이 이 편의 목적이에요. 준비의 무게중심이 어디에 놓여 있는지, 그게 실제 위험과 맞는지 다시 보자는 얘기예요. 열심히 대비했는데 엉뚱한 것을 대비했다면 그건 대비가 아닙니다.

왜 그런가

트래픽 급증은 대비하기 쉬운 편이에요. 예측 가능하고, 측정 가능하고, 대응 수단이 명확해요. 그래서 대부분의 팀이 여기에 준비를 집중해요.

의존성 장애는 다릅니다.

먼저 통제할 수 없어요. 상대 서비스가 언제 느려질지 우리는 정할 수 없어요.

그리고 실패 방식이 다양해요. 완전히 죽는 건 오히려 쉬워요 — 연결이 거부되니 빨리 실패하거든요. 어려운 건 앞 편에서 본 반쯤 살아 있는 상태예요. 느려지거나, 일부만 실패하거나, 잘못된 응답을 주는 경우요.

또 전파돼요. 우리가 의존하는 서비스도 다른 것에 의존해요. 세 단계 떨어진 어딘가의 문제가 우리에게 도달할 수 있어요.

여기에 트래픽 외의 원인들이 더 있어요. 인증서 만료, 설정 변경, 배포, 디스크 소진, 이름 해석 실패, 시계 어긋남, 권한 만료 같은 것들이요. 전부 트래픽과 무관하고, 전부 실제로 자주 일어납니다.

정리하면 준비의 무게중심이 잘못 놓여 있는 경우가 많아요. 트래픽 대비는 이미 충분한데 의존성 대비는 비어 있는 상태요.

코드로 보면

의존성 목록부터 만든다:

· 우리가 의존하는 것을 전부 적는다
✓ 외부 API · 내부 서비스 · DB · 캐시 · 큐
✓ DNS · 인증서 · 신원 공급자 · 설정 저장소
✓ 컨테이너 이미지 저장소 · 패키지 저장소
✕ 마지막 둘은 배포할 때만 필요해서 자주 빠진다

· 각각에 대해 세 가지를 답한다
✓ 1) 이게 죽으면 무엇이 안 되나
✓ 2) 느려지면 어떻게 되나 (죽는 것보다 어렵다)
✓ 3) 없이도 되는 기능은 무엇인가

· 그리고 실제로 끊어 본다
✓ 하나씩 차단하고 무슨 일이 일어나는지 관찰
✕ 문서상의 대비와 실제 동작은 다르다

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

대비의 순서를 다시 잡아야 해요.

먼저 의존성 목록을 만드세요. 놀랍게도 많은 팀이 자기가 무엇에 의존하는지 전부 적어 본 적이 없어요. 적어 보면 예상보다 훨씬 많고, 잊고 있던 것들이 나와요. 인증서, 이름 해석, 신원 공급자, 이미지 저장소 같은 것들이요.

그다음 각각에 대해 "죽으면"이 아니라 "느려지면"을 물어야 해요. 앞 편들에서 반복해서 본 대로 반쯤 살아 있는 상태가 가장 어렵거든요. 완전히 죽으면 빨리 실패하고 대안으로 넘어갈 수 있지만, 느려지면 자원이 묶이면서 우리까지 끌고 들어갑니다.

그리고 각 의존성 없이도 되는 기능을 정하세요. 추천이 안 나와도 상품은 보여 줄 수 있고, 프로필 이미지가 없어도 목록은 뜰 수 있어요. 이 구분이 되어 있으면 앞 편에서 본 서킷 브레이커가 진짜 힘을 발휘합니다.

여기까지 하면 도구를 붙일 수 있어요. 타임아웃, 서킷 브레이커, 재시도 예산, 대안 응답이 각 의존성마다 필요한지 판단할 수 있게 되죠.

마지막으로 실제로 끊어 봐야 해요. 문서상의 대비와 실제 동작은 다릅니다. 스테이징에서 의존성을 하나씩 차단하고 무슨 일이 일어나는지 관찰하면, 대비했다고 믿었던 것들이 실제로는 안 되는 걸 발견하게 돼요.

그리고 트래픽 외의 원인들에 대한 기본 점검도 필요해요. 인증서 만료일 알림, 설정 변경 검토 절차, 디스크 사용률 알림 같은 것들이요. 단순한데 안 해 두면 그것 때문에 장애가 납니다.

처방

1. 의존성 목록을 만드세요. 인증서·DNS·신원 공급자·이미지 저장소까지 전부요.
2. 각각에 대해 "느려지면 어떻게 되나"를 물으세요. 죽는 경우보다 이쪽이 어렵습니다.
3. 각 의존성 없이도 되는 기능을 정하세요. 이 구분이 대안 응답의 근거가 됩니다.
4. 타임아웃·서킷 브레이커·대안을 의존성마다 설계하세요.
5. 실제로 끊어 보세요. 스테이징에서 하나씩 차단하고 관찰하세요.
6. 인증서 만료일에 알림을 거세요. 단순한데 안 해서 나는 장애가 많습니다.
7. 설정 변경에도 검토와 단계적 반영을 적용하세요. 코드 배포만 관리하고 설정은 그냥 바꾸는 팀이 많습니다.
8. 장애 회고를 모아 원인을 분류하세요. 트래픽·의존성·배포·설정·만료로 나눠 세면 준비의 무게중심이 맞는지 보입니다.
9. 간접 의존성을 찾으세요. 라이브러리가 몰래 부르는 것들은 목록에 안 들어갑니다.
10. 배포 시에만 필요한 의존성을 목록에 넣으세요. 이미지 저장소·패키지 저장소는 장애 중에 배포하려는 순간 막힙니다.

지금 확인해 보세요

우리는 무엇에 의존하는가:

· 목록을 만들고 각각에 답한다
✓ 죽으면 무엇이 안 되나
✓ 느려지면 어떻게 되나
✓ 없이도 되는 기능은 무엇인가

· 간접 의존성도 찾는다
✕ 라이브러리가 몰래 부르는 것들
✓ 네트워크 연결을 관찰하면 드러난다

· 배포 시에만 필요한 의존성
✕ 이미지 저장소 · 패키지 저장소 · 인증서 발급
✕ 장애 중에 배포하려는 순간 막힌다

· 인증서 만료일
✓ 알림이 걸려 있는가. 몇 개나 되는가

· 실제로 끊어 봤는가
✕ 문서상의 대비와 실제 동작은 다르다

· 지난 장애의 원인 분류
✓ 트래픽 / 의존성 / 배포 / 설정 / 만료 / 기타

핵심 한 줄우리를 무너뜨리는 건 대개 트래픽이 아니라 남의 사정이다.