서비스가 커질수록 장애는 한 곳에서 끝나지 않아요. 문제는 느린 API 하나가 아니라, 그 API를 붙잡고 있는 단 하나의 서버, 단 하나의 DB, 단 하나의 배포 경로일 때가 많아요. 이때 그 지점이 무너지면 전체 서비스가 같이 멈춰요. 그게 SPOF예요.
SPOF는 서버 한 대만 뜻하지 않아요
SPOF는 Single Point of Failure의 약자예요. 단일 장애 지점이라는 뜻이고, 하나의 구성 요소가 실패했을 때 시스템 전체의 가용성이 무너지는 구조를 말해요.
실무에서 자주 놓치는 SPOF는 생각보다 많아요.
- 단일 애플리케이션 서버
- 단일 DB 마스터
- 단일 Redis
- 단일 Load Balancer
- 단일 배포 스크립트
- 단일 리전 또는 단일 존
- 단일 DNS 설정
서버를 여러 대 두면 안전하다고 생각하기 쉬워요. 하지만 그 앞의 로드 밸런서가 하나면 거기도 SPOF예요. 서버는 복제했는데 세션 저장소가 하나면 거기도 SPOF예요. 겉으로는 분산처럼 보여도 실제로는 한 점에 의존하고 있을 수 있어요.
복제만으로는 충분하지 않아요
복제는 SPOF를 줄이는 시작점일 뿐이에요. 중요한 건 실패했을 때 자동으로 넘겨받을 수 있느냐예요.
예를 들어 DB를 master-replica로 구성했다고 해도, failover가 수동이면 장애 시점에 운영자가 개입해야 해요. 그 사이에 서비스는 멈추거나 읽기 전용이 돼요. Redis를 이중화했더라도 애플리케이션이 새 주소를 모르면 계속 죽은 인스턴스만 바라볼 수 있어요.
즉, "복제되어 있다"와 "장애를 흡수할 수 있다"는 다른 말이에요. SPOF는 복제 여부보다 전환 가능성과 검증 여부를 같이 봐야 해요.
분산 시스템은 보통 여러 단계로 나눠져 있어요. 트래픽 진입점, 세션과 캐시, 데이터 저장소, 작업 큐, 운영 경로가 각각 다른 방식으로 장애를 만들 수 있어요. 그래서 한 군데만 중복화해도 끝나지 않아요.
어디서부터 줄여야 하나요
가장 좋은 방법은 한 번에 모두 없애려 하지 않는 거예요. 먼저 가장 큰 blast radius를 가진 곳부터 봐야 해요.
- 사용자 트래픽이 처음 닿는 지점
- 상태를 저장하는 지점
- 장애가 연쇄로 번지는 의존성
- 배포와 복구를 담당하는 운영 경로
상태가 없는 애플리케이션 서버는 수평 확장이 쉬워요. 반면 세션, 캐시, 락, 큐, 외부 API처럼 상태나 순서가 중요한 부분은 더 조심해야 해요. 이 지점들은 단순히 복제한다고 끝나지 않고, 장애 전환과 재시도 정책까지 같이 설계해야 해요.
컨트롤 플레인도 자주 놓쳐요. 애플리케이션은 여러 대인데 설정 배포, 비밀 관리, 도메인, 인증서, 모니터링 수집기가 한 군데에 묶여 있으면 운영 중단이 길어질 수 있어요.
테스트하지 않은 이중화는 이중화가 아니에요
SPOF를 없앴다고 말하려면 failover를 실제로 시험해 봐야 해요. 평소에는 멀쩡해 보여도, 장애 상황에서 전환이 안 되면 의미가 없어요. 그래서 장애 대응 문서보다 중요한 게 복구 리허설이에요.
운영에서는 이런 질문을 직접 확인해야 해요.
- 한 인스턴스가 죽으면 트래픽이 자동으로 넘어가나요?
- DB 주 서버가 바뀌면 애플리케이션이 새 주소를 곧장 보나요?
- 캐시가 죽어도 서비스가 계속 동작하나요?
- 배포 스크립트가 멈추면 수동 복구가 가능한가요?
이 질문에 대답하지 못하면 SPOF는 아직 남아 있어요. 이중화가 있다는 말보다, 실제 전환이 되는지 확인한 기록이 더 중요해요.
정리
- SPOF는 한 군데가 고장 나면 전체가 멈추는 구조예요.
- 서버를 여러 대로 늘리는 것만으로는 부족하고, 전환과 복구까지 있어야 해요.
- 장애를 완전히 없앨 수는 없어도, 하나의 실패가 전체 실패로 번지는 구조는 줄일 수 있어요.
