API Gateway 장애가 전체 서비스를 마비시키는 이유: Single Point of Failure 제거 전략

API Gateway 장애가 전체 서비스를 마비시키는 이유: Single Point of Failure 제거 전략

Server Infrastructure

MSA를 도입하면서 API Gateway를 구축했다. 인증, 라우팅, 로깅이 한 곳에서 처리되니 깔끔했다. 그런데 어느 날 Gateway 인스턴스 하나가 메모리 부족으로 죽었다. 30초 만에 전체 서비스가 마비됐다.

분산 시스템을 만들었는데, 정작 입구는 단일 장애점(Single Point of Failure)이었던 것이다.

API Gateway가 SPOF가 되는 순간

API Gateway는 모든 트래픽이 통과하는 관문이다. 이 관문이 막히면 아무리 뒤에 있는 서비스가 건강해도 소용없다.

흔한 SPOF 패턴들:

1. 단일 인스턴스 운영
"트래픽이 적으니까 한 대로 충분해" → 그 한 대가 죽으면 끝

2. Sticky Session 의존
특정 인스턴스에 세션이 고정되면 해당 인스턴스 장애 시 세션 유실

3. 공유 상태 저장
Gateway에 인메모리 캐시나 상태를 저장하면 인스턴스 간 불일치 발생

4. 동기식 외부 의존성
인증 서버가 느려지면 Gateway 전체가 느려짐

해결 전략 1: 다중 인스턴스 + 로드밸런서

Network Architecture

최소 3개 이상의 Gateway 인스턴스를 운영하고, 앞단에 L4/L7 로드밸런서를 배치한다.

# Nginx 로드밸런서 설정 예시
upstream api_gateway {
    least_conn;  # 연결 수 기반 분산
    server gateway-1:8080 weight=5;
    server gateway-2:8080 weight=5;
    server gateway-3:8080 weight=5;
    
    # Health check
    server gateway-1:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl;
    
    location / {
        proxy_pass http://api_gateway;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

핵심 설정:

  • least_conn: 연결 수가 적은 서버로 분산
  • max_fails: 3회 실패 시 해당 서버 제외
  • proxy_next_upstream: 실패 시 다음 서버로 자동 재시도

해결 전략 2: Stateless Gateway 설계

Gateway는 상태를 가지면 안 된다. 모든 요청은 어떤 인스턴스로 가도 동일하게 처리되어야 한다.

세션/토큰 처리:

// BAD: 인메모리 세션 저장
Map<String, Session> sessions = new ConcurrentHashMap<>();

// GOOD: Redis 외부 저장소 사용
@Autowired
private RedisTemplate<String, Session> redisTemplate;

public Session getSession(String token) {
    return redisTemplate.opsForValue().get("session:" + token);
}

Rate Limiting:

// BAD: 로컬 카운터
AtomicInteger counter = new AtomicInteger();

// GOOD: Redis 분산 카운터
public boolean isAllowed(String clientId) {
    String key = "ratelimit:" + clientId;
    Long count = redisTemplate.opsForValue().increment(key);
    if (count == 1) {
        redisTemplate.expire(key, 1, TimeUnit.MINUTES);
    }
    return count <= 100;  // 분당 100회 제한
}

해결 전략 3: Circuit Breaker 적용

Gateway가 호출하는 외부 서비스(인증, 권한 등)에 장애가 발생하면 Gateway까지 죽을 수 있다. Circuit Breaker로 장애를 격리해야 한다.

@CircuitBreaker(name = "authService", fallbackMethod = "authFallback")
@TimeLimiter(name = "authService")
public CompletableFuture<AuthResult> authenticate(String token) {
    return CompletableFuture.supplyAsync(() -> 
        authClient.validate(token)
    );
}

// 인증 서버 장애 시 캐시된 결과 사용
private CompletableFuture<AuthResult> authFallback(String token, Exception e) {
    AuthResult cached = authCache.get(token);
    if (cached != null && !cached.isExpired()) {
        return CompletableFuture.completedFuture(cached);
    }
    return CompletableFuture.failedFuture(
        new ServiceUnavailableException("Auth service unavailable")
    );
}

Resilience4j 설정:

resilience4j:
  circuitbreaker:
    instances:
      authService:
        slidingWindowSize: 10
        failureRateThreshold: 50
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 3
  timelimiter:
    instances:
      authService:
        timeoutDuration: 2s

해결 전략 4: Health Check와 자동 복구

장애 감지가 빨라야 복구도 빠르다. Kubernetes 환경이라면 Probe 설정이 핵심이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: gateway
        image: api-gateway:latest
        ports:
        - containerPort: 8080
        
        # Liveness: 죽었는지 확인
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 3
        
        # Readiness: 트래픽 받을 준비 됐는지 확인
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "1Gi"
            cpu: "1000m"

Health Endpoint 구현:

@RestController
@RequestMapping("/health")
public class HealthController {
    
    @Autowired
    private RedisTemplate redisTemplate;
    
    @Autowired
    private AuthClient authClient;
    
    // Liveness: 프로세스가 살아있는지만 확인
    @GetMapping("/live")
    public ResponseEntity<String> live() {
        return ResponseEntity.ok("OK");
    }
    
    // Readiness: 의존성까지 확인
    @GetMapping("/ready")
    public ResponseEntity<Map> ready() {
        Map<String, String> status = new HashMap<>();
        
        // Redis 연결 확인
        try {
            redisTemplate.opsForValue().get("health-check");
            status.put("redis", "UP");
        } catch (Exception e) {
            status.put("redis", "DOWN");
            return ResponseEntity.status(503).body(status);
        }
        
        return ResponseEntity.ok(status);
    }
}

해결 전략 5: Graceful Shutdown

배포나 스케일링 시 진행 중인 요청을 끊지 않고 안전하게 종료해야 한다.

@Component
public class GracefulShutdownHandler {
    
    private volatile boolean shuttingDown = false;
    private AtomicInteger activeRequests = new AtomicInteger(0);
    
    @PreDestroy
    public void shutdown() {
        shuttingDown = true;
        
        // 최대 30초간 진행 중인 요청 완료 대기
        int waitTime = 0;
        while (activeRequests.get() > 0 && waitTime < 30) {
            try {
                Thread.sleep(1000);
                waitTime++;
            } catch (InterruptedException e) {
                break;
            }
        }
    }
    
    public void requestStarted() {
        activeRequests.incrementAndGet();
    }
    
    public void requestCompleted() {
        activeRequests.decrementAndGet();
    }
}

Kubernetes 설정:

spec:
  terminationGracePeriodSeconds: 60
  containers:
  - name: gateway
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 10"]  # LB에서 제거될 시간 확보

모니터링 지표

SPOF를 예방하려면 선제적 모니터링이 필수다.

지표 정상 범위 알람 조건
인스턴스 수 3개 이상 2개 이하
CPU 사용률 < 70% > 85% (5분 지속)
메모리 사용률 < 75% > 90%
P99 응답시간 < 100ms > 500ms
에러율 < 0.1% > 1%
Circuit Open 횟수 0 > 0

결론

API Gateway는 MSA의 핵심 인프라지만, 잘못 설계하면 가장 큰 약점이 된다. SPOF를 제거하려면:

  • ✅ 최소 3개 이상 인스턴스 운영
  • ✅ Stateless 설계 (외부 저장소 활용)
  • ✅ Circuit Breaker로 외부 의존성 격리
  • ✅ Health Check와 자동 복구
  • ✅ Graceful Shutdown 구현
  • ✅ 선제적 모니터링

분산 시스템의 입구가 단일 장애점이 되지 않도록 설계하자.

더 자세한 분산 시스템 아키텍처 패턴은 PowerSoft Tech Blog에서 확인할 수 있다.


PowerSoft Technical Report
Backend Architecture Series | January 2026
Author: PowerSoft R&D Center

댓글

댓글 쓰기

이 블로그의 인기 게시물

[2026 Deep Dive] L7 로드밸런싱의 숨겨진 복잡성: 세션 어피니티가 만드는 트래픽 블랙홀

이미지
[2026 Deep Dive] L7 로드밸런싱의 숨겨진 복잡성 Session Affinity: The Hidden Traffic Black Hole in Your Load Balancer "로드밸런서 달았으니까 트래픽 분산은 끝났다"고 생각하시나요? 2026년 현재, 수많은 엔터프라이즈 플랫폼이 잘못 설정된 로드밸런싱 때문에 성능 병목에 시달리고 있습니다. 특히 세션 어피니티(Session Affinity) 설정은 양날의 검입니다. 오늘은 L7 로드밸런싱의 함정과 2026년형 베스트 프랙티스를 깊이 파헤쳐 보겠습니다. 세션 어피니티란 무엇인가? 세션 어피니티(또는 Sticky Session)는 같은 사용자의 요청을 항상 같은 서버로 보내는 설정입니다. 왜 필요한가? 로그인 세션 유지 장바구니 정보 보존 WebSocket 연결 유지 문제는 여기서 시작됩니다. 세션 어피니티의 3가지 함정 함정 1: 트래픽 불균형 (Hot Spot) 특정 사용자가 대량의 요청을 보내면? 그 사용자가 고정된 서버 하나가 과부하에 걸립니다. 다른 서버는 놀고 있는데, 한 서버만 죽어나가는 상황이 발생합니다. 실제 사례: 대규모 실시간 게이밍 플랫폼에서 VIP 유저 10명이 전체 트래픽의 40%를 차지했고, 이들이 모두 같은 서버에 고정되어 장애가 발생했습니다. 함정 2: 스케일 아웃 무력화 새 서버를 추가해도 기존 세션은 이동하지 않습니다. 트래픽이 급증해서 서버를 늘렸는데, 새 서버에는 아무도 안 오는 상황. 오토스케일링의 의미가 없어집니다. 함정 3: 서버 장애 시 세션 손실 고정된 서버가 죽으면? 해당 서버에 붙어있던 모든 사용자의 세션이 날아갑니다. "갑자기 로그아웃됐어요"라는 CS가 폭주합니다. 2026년형 해결 전략 전략 1: Stateless 아키텍처 전환 세션을 서버가 아닌 외부 저장소 에 보관합니다. 저장소 장점 단점 Redis Cluster 빠름, 확장...
자세한 내용 보기

[Tech Review] 2,000만 트래픽도 거뜬한 2026년형 엔터프라이즈 아키텍처의 비밀

이미지
"서버가 터지는 것은 사고가 아니라, 설계의 실패입니다." 온라인 플랫폼 비즈니스에서 트래픽 급증은 축복이자 재앙입니다. 준비되지 않은 인프라에 쏟아지는 유저는 시스템 다운(Downtime)을 유발하고, 이는 곧 막대한 매출 손실과 신뢰도 하락으로 이어집니다. 최근 엔터프라이즈 솔루션 전문 기업 PowerSoft(파워소프트)에서 발표한 <2026 엔터프라이즈 플랫폼 인프라 표준> 리포트를 심층 분석해 보았습니다. 이 보고서는 단순한 서버 증설이 아닌, '아키텍처의 구조적 혁신'을 통해 99.99%의 가동률을 달성하는 구체적인 해답을 제시하고 있습니다. 인프라 담당자와 CTO라면 반드시 주목해야 할 3가지 핵심 기술을 요약 정리합니다. 1. 지능형 L7 로드밸런싱 (Intelligent Load Balancing) 과거의 L4 스위치 방식은 단순한 트래픽 분배에 그쳤습니다. 하지만 PowerSoft가 제안하는 2026년 표준은 L7 계층(애플리케이션 레이어) 에서 트래픽의 내용을 분석합니다. 이를 통해 비정상적인 패턴이나 악성 봇(Bot)을 사전에 필터링하고, 실제 유효한 유저 트래픽만을 최적의 서버 노드로 연결합니다. 이는 서버의 리소스 낭비를 막고 응답 속도를 획기적으로 개선하는 핵심 기술입니다. 2. 죽지 않는 서버: 오토 힐링(Auto-Healing) 시스템 서버 장애는 언제든 발생할 수 있습니다. 중요한 것은 '복구 속도'입니다. 본 리포트에 따르면, PowerSoft의 아키텍처는 특정 노드에 장애가 감지되는 즉시 0.1초 내에 해당 노드를 격리하고 대체 인스턴스를 자동 투입 합니다. 사용자는 장애가 발생했는지조차 인지할 수 없는 무중단(Zero-Downtime) 환경이 구현되는 것입니다. 3. 데이터 무결성을 위한 보안 표준 (TLS 1.3 & ACID) 속도만큼 중요한 것이 데이터의 정확성입니다. 특히 결제나 정산이 포함된 플랫폼에서 데이터 불일치는 치명적입니다. 이 아키텍처는 모든...
자세한 내용 보기

데이터베이스 교착 상태(Deadlock) 발생 원인과 해결 전략

이미지
데이터베이스 교착 상태(Deadlock) 발생 원인과 해결 전략 트랜잭션 기반 시스템에서 Deadlock은 피할 수 없는 문제입니다. 두 개 이상의 트랜잭션이 서로가 보유한 리소스를 무한히 대기하는 상황으로, 외부 개입 없이는 해결되지 않습니다. 본 리포트에서는 Deadlock의 발생 메커니즘과 실무에서 적용 가능한 해결 전략을 다룹니다. Deadlock 발생 메커니즘 Deadlock이 발생하려면 네 가지 조건이 동시에 충족되어야 합니다. 상호 배제(Mutual Exclusion) : 리소스는 한 번에 하나의 트랜잭션만 사용할 수 있습니다. 점유 대기(Hold and Wait) : 트랜잭션이 리소스를 보유한 상태에서 다른 리소스를 요청합니다. 비선점(No Preemption) : 다른 트랜잭션이 보유한 리소스를 강제로 빼앗을 수 없습니다. 순환 대기(Circular Wait) : 트랜잭션들이 순환 형태로 서로의 리소스를 대기합니다. 실제 시나리오를 살펴보겠습니다. Transaction A: Lock(Order #1) → Request Lock(Inventory #100) → 대기 Transaction B: Lock(Inventory #100) → Request Lock(Order #1) → 대기 트랜잭션 A는 Order #1을 보유하고 Inventory #100을 요청합니다. 트랜잭션 B는 Inventory #100을 보유하고 Order #1을 요청합니다. 양쪽 모두 상대방이 보유한 리소스를 무한히 대기하게 됩니다. 발생 빈도와 트래픽의 상관관계 Deadlock은 확률적으로 발생합니다. 두 트랜잭션이 정확히 같은 타이밍에 교차하는 리소스를 요청해야 하기 때문입니다. 일반적인 상황에서는 한 트랜잭션이 먼저 완료되어 리소스를 해제합니다. 그러나 동시 접속자가 증가하면 충돌 확률이 기하급수적으로 상승합니다. 트래픽 증가에 따른 Deadlock 발생 빈도 예시입니다. 일반 트래픽: 월 1-2회 발...
자세한 내용 보기