[아키텍처] 아키텍처 개선과 SPOF 해결: SPOF 문제는 꼬리에 꼬리를 이어..

🌏 인트로

서비스가 성장하면서 단일 서버 기반의 단순한 구조는 점차 한계를 드러냅니다. 특히 하나의 구성 요소가 고장날 경우 전체 서비스가 멈추는 구조, 즉 SPOF(Single Point of Failure)는 장애 발생 시 곧바로 전체 시스템이 멈추게 되어 사용자 경험에 치명적인 영향을 줄 수 있습니다.

이 글에서는 기존 단일 아키텍처에서 출발하여 각 요소별 SPOF 원인과 이를 해결하기 위한 고가용성 아키텍처로의 개선 방안을 단계적으로 설명하겠습니다.

🌏 기존 구조와 SPOF 문제

✅ 기존 구조

Client → Server [Nginx → Tomcat] → Cache(Redis) → RDB

이 구조는 각 계층이 모두 단일 서버로 구성되어 있기 때문에, 어느 하나라도 장애가 발생하면 전체 서비스가 중단되는 위험이 존재합니다. 즉, 모든 구성요소가 SPOF 입니다. 이를 해결하기 위해 구성 요소별로 SPOF 원인을 분석하고, 다중화 및 고가용성 전략을 적용해야 합니다.

🌏 구성 요소별 SPOF 원인과 해결 전략

✅ Client (SPOF는 아님)

클라이언트는 직접적인 SPOF는 아니지만, 특정 리전이나 AZ(가용 영역)에 종속되어 있다면 해당 인프라 장애 발생 시 서비스 접속이 불가능해질 수 있습니다.

• 해결 방안
  • on-premise 환경에서는 다수의 지역에 클라이언트를 분산 배치합니다.
  • 클라우드 환경에서는 Multi Region, Multi AZ 배포를 통해 장애 체감을 줄입니다.
  • 글로벌 서비스라면 Cloud Load Balancer(ALB 등)를 통해 분산된 리소스로 연결되도록 구성합니다.

✅ Nginx SPOF

Nginx는 SSL termination, reverse proxy, 무중단 배포 등의 역할을 담당합니다. 하지만 단일 서버로 구성되어 있다면 장애 시 트래픽 처리가 중단됩니다.

• 해결 방안
  • Nginx 서버 다중화 및 외부 감시 시스템(health check) 도입합니다.
  • Kubernetes 환경에서는 Nginx Ingress Controller 다중화를 적용하는 외부 솔루션을 사용할 수도 있습니다.
  • 로드밸런서를 상단에 배치하여 Nginx 인스턴스를 분산 호출할 수 있지만, 이 경우에는 로드밸런서가 SPOF가 되는 점을 고려해야 합니다.
  • 클라우드 환경에서는 LB 자체가 HA를 지원하지만, 온프레미스에서는 LB 이중화가 필요합니다! 

✅ Tomcat (Application Server) SPOF

Tomcat이 단일 서버로 구성되어 있다면 애플리케이션에 장애가 발생했을 때 전체 서비스가 중단됩니다.

• 해결 방안
  • Stateless 기반 설계를 통해 다중화를 쉽게 할 수 있도록 하고, 로드밸런서를 통해 트래픽 분산합니다. 이때 로드밸런서가 SPOF가 될 수 있는 점을 고려해야 합니다.
  • Kubernetes 기반으로 HPA(Horizontal Pod Autoscaler)를 통해 CPU/메모리 부하에 따라 자동 확장하는 외부 솔루션을 사용할 수도 있습니다.

✅ Redis

Redis는 캐시, 세션 저장소로 활용되며 성능 향상에 기여합니다. 하지만 단일 서버일 경우 장애 시 캐시 미스나 세션 소실로 이어질 수 있습니다.

• 해결 방안
  • master-slave 구조의 replica 구성해 캐시 서버를 다중화할 수 있습니다.
  • Sentinel을 통한 자동 failover
  • Redis Cluster 기반 샤딩 구조로 수평 확장
  • AWS ElastiCache와 같은 관리형 서비스 도입
• 운영 시 유의사항
  • split brain 문제를 방지하기 위한 quorum 기반 failover 및 fencing token 적용
  • cache stampede 대응: random TTL, mutex lock, pre-warming 등
  • write는 master에서만 처리하도록 구성하여 일관성 유지

✅ RDB (Relational Database)

데이터의 정확성과 지속성을 보장해야 하는 RDB는 장애 발생 시 가장 큰 영향을 미칩니다.

• 해결 방안
  • master-slave 기반 replica 구성
  • 장애 발생 시 slave를 master로 승격하는 failover 체계 구축
  • 샤딩 기반 분산 저장
  • AWS RDS, GCP CloudSQL과 같은 고가용성 구조의 클라우드 서비스 활용
• 운영 시 유의사항
  • connection pool tuning, 쿼리 최적화, replication lag 모니터링 필수
  • Redis와는 달리 CAP 이론 상 CP(일관성 + 파티션 내성) 지향

🌏 개선된 고가용성 아키텍처 구조

✅ 서버 및 캐시 다중화 구조

Client → Load Balancer → Nginx(Ingress) → Server(N대) → Redis Cluster → DB Cluster

• Load Balancer를 통해 클라이언트 요청을 Nginx 및 애플리케이션 서버로 분산합니다.
• 서버는 모두 Stateless하게 구성되어 자동 확장 및 축소가 가능합니다.
• Redis는 샤딩 및 replica 기반의 클러스터로 구성하여 장애 발생 시 자동 복구가 가능합니다.
• DB는 replica 및 샤딩 구조를 통해 확장성과 내결함성을 확보합니다.

🌏 Kubernetes 기반 설계의 장점

Kubernetes는 컨테이너 오케스트레이션 플랫폼으로, 다음과 같은 장점을 제공합니다.

• Pod 자동 복구 및 롤링 배포
• ingress controller를 통한 경로 기반 내부 라우팅
• CPU/메모리 부하에 따른 자동 확장(HPA)
• 서비스 네트워크 추상화로 DNS 기반 접근 가능
• 리소스 제한, 설정 관리, ConfigMap, Secret 등 운영 자동화 지원

🌏 결론: 장애를 견디는 구조로의 진화

SPOF를 제거하고 고가용성을 확보하기 위한 설계는 단순히 장비를 늘리는 것이 아닙니다. 각 계층에 대한 이해를 바탕으로 장애를 탐지하고 복구할 수 있는 메커니즘을 미리 설계하는 것이 핵심입니다.

모든 시스템은 언젠가 장애가 발생한다는 전제를 두고, 그 장애를 최대한 감지하고 최소한의 영향으로 회복할 수 있도록 준비하는 것이 진정한 고가용성 설계입니다.

서비스 신뢰성을 높이고 사용자에게 안정적인 경험을 제공하기 위해서는, 구성 요소별로 SPOF를 제거하고 자동화된 복구 시스템을 갖춘 구조로 점진적으로 진화해 나가야 합니다.

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!