Rate Limit, Bulkhead

장애가 발생하기 전, 시스템이 감당할 수 있는 수준으로 부하를 제어하여 장애를 예방하는 두 가지 핵심 기술이 존재합니다. Rate Limit, Bulkhead은 호출량을 제한하여 시스템 자원이 과도한 부하를 받지 않도록 보호한다는 공통점이 있지만, 제한 방식에서의 차이가 존재합니다.

Rate Limit

Rate Limiter는 이름 그대로 실행 횟수를 제한하는 기술입니다.

애플리케이션에서 Rate Limit은 크게 두 곳에 적용할 수 있습니다.

• 요청이 들어오는 곳 (Inbound)

  • 가장 많이 볼 수 있는 케이스입니다.

  • 특정 사용자나 API Key를 기준으로 요청 횟수를 제한하여, 특정 사용자가 시스템 리소스를 독점하거나 과도한 비용을 유발하는 것을 방지합니다.

• 요청이 나가는 곳 (Outbound)

  • 요청을 받는 대상 서비스로 과도한 트래픽이 나가지 않도록 제한합니다.

  • 구축한 서버가 외부 서비스(타사 API 등)를 호출할 때 적용할 수 있습니다.

  • 타 서비스의 시스템이 감당할 수 없을 만큼 과도한 트래픽을 보내지 않도록 보호하는 역할을 수행합니다.

[예시: 로그 시스템 보호하기]

• Rate Limiter는 API 호출뿐만 아니라 에러 로그 처리에도 유용합니다.

• 시스템에 장애가 터지면 에러 로그가 폭발적으로 발생하여 Slack 채널이 마비되거나 로그 서버(ELK 등)가 뻗어버릴 수 있습니다.

• 이때 로그 전송 로직에 Rate Limit을 걸어두면, 평소에는 잘 보내다가 장애 시에는 로그를 차단하거나 요약해서 보냄으로써 2차 피해를 막을 수 있습니다.

resilience4j도 Rate Limit 기능을 제공하는 데, 서킷에 비해서 기능이 조금 미약합니다.

Bulkhead

벌크헤드는 ‘격벽’이라는 의미인데, 선박 내부를 여러 격벽으로 나누어, 한 곳에 구멍이 나도 배 전체가 침몰하지 않게 하는 것에서 유래했습니다.

SW에서는 동시에 진입할 수 있는 수를 제한하는 방식으로 구현됩니다. 그래서 벌크헤드가 적용된 영역에는 동시에 진입할 수 있는 스레드의 수를 제한할 수 있습니다.

비슷한 개념으로는 synchronized 키워드로 동기화를 하는 것도 동시에 하나의 흐름만 블록에 진입하도록 제한하는 것입니다. 이는 방식 자체는 같지만 목적 자체가 다릅니다.

벌크헤드는 동기화가 목적이 아니라, 보호하려는 대상의 리소스가 과도하게 사용되는 것을 막는것입니다.

스레드 풀, 커넥션 풀이 벌크헤드와 완전히 동일한 개념으로도 볼 수 있습니다.

• 너무 많은 요청이 동시에 처리되지 않도록 제한하는 역할

• 너무 많은 요청을 동시에 처리하면 컨텍스트 스위칭같은 오버헤드 때문에 오히려 전체 성능이 저하될 수 있어서 제한을 하는 것이다.

[동작 원리]

• 리소스 격리:

  • 동기화(synchronized)와 비슷하지만 목적이 다릅니다.

  • 동기화는 데이터 정합성이 목적이라면,

  • Bulkhead는 특정 기능이 전체 리소스(예: 스레드/커넥션 풀 등)를 고갈시키는 것을 막는 것이 목적입니다.

• 예시:

  • 이미 사용하고 있는 DBCP(Database Connection Pool)이나 톰캣의 스레드 풀이 해당 패턴의 일종입니다.

• 효과:

  • 너무 많은 요청을 동시에 처리하면 컨텍스트 스위칭 비용 때문에 오히려 성능이 저하될 수 있습니다.

  • Bulkhead는 이를 적절히 제한하여 전체 시스템의 처리량을 유지합니다.

Resilience4j

Resilien4j 기준에서 Rate Limit, Bulkhead 모두 제한되는 영역은 기본적으로 메서드 단위입니다.

• Circuit: 높은 부하를 받는 경우(예외, 느린 응답) 일시적으로 트래픽 차단하여 시스템을 회복

• Rate Limiter: 높은 부하를 예방하기 위해서 시간당 실행 횟수를 제한

• Bulkhead: 높은 부하를 예방하기 위해, 동시에 처리할 수 있는 스레드 수 제한

분산 환경에서 발생할 수 있는 문제점과 대안

단일 서버에서는 메모리 내에서 해결하면 되지만, 서버가 여러 대인 분산 환경에서는 고민이 필요할 수 있습니다.

Rate Limiter나 Bulkhead의 상태를 서버끼리 공유하려면 보통 Redis 같은 외부 저장소를 사용합니다. 하지만 그냥 사용하게 된다면 이후에 큰 문제가 발생할 수 있습니다.

[문제 상황: 상태 관리를 하는 Redis가 죽으면?]

이때 선택할 수 있는 3가지 방안이 있습니다.

정해진 것은 없으며 비즈니스 혹은 서비스 규칙에 맞춰 적절하게 선택해야 합니다.

1. Fail Open (모두 허용)

   • Redis가 죽으면 제한을 풀고 모든 요청을 받습니다.

   • 시스템의 가용성이 중요한 경우 선택할 수 있지만, 시스템 과부하 위험도 존재합니다.

2. Fail Closed (모두 차단)

   • Redis가 죽으면 모든 요청을 거부합니다.

   • 시스템을 보호하는 것에 집중하지만, 서비스 중단이 발생할 수 있습니다.

3. Local Fallback (인스턴스별로 설정)

   • Redis가 죽으면, 각 서버의 로컬 메모리를 기준으로 제한합니다.

   • 가장 현명한 대안이라고 생각되지만, 사용자 입장에서 일관성 없는 경험을 할 수 있습니다.

Summary

Rate Limiter와 Bulkhead는 시스템이 감당할 수 있는 데드라인을 설정하는 것과 같습니다.

• Rate Limiter로 요청 빈도를 제어하고

• Bulkhead로 자원을 격리하고

• 문제가 발생하면 서킷으로 연결을 차단할 수 있습니다.

세 가지 방식이 조화롭게 적용되었을 때, 갑작스러운 트래픽에서도 견고한 시스템을 구축할 수 있을 것입니다.