[DeepDive🤿] 대규모 이벤트 상황에서 발생하는 네트워크 병목 현상을 완화하기 위한 전략

[주제를 보고 든 생각]

• 음 어렵다!
• 티켓팅할때 대기순서를 주는게 병목 현상을 완화하기 위한것인듯.
• 근데 대기순서 조차도 튕길때가 있는데, 이건 병목현상을 완화하지 못한건가?

네트워크 병목 현상

• 정의 : 네트워크 자원(대역폭, 라우터, 스위치, 서버 등)의 한계로 인해 특정 지점에서 데이터가 정체되며 전체 네트워크 성능이 저하되는 현상
• 특히 대규모 이벤트 일때는, 평소 대비 매우 짧은 시간에 폭발적인 트래픽이 집중되는 상황 발생 → 이때 서버는 네트워크 처리 용량, 애플리케이션 처리량, 데이터베이스 질의 처리 능력 중 가장 약한 지점에서 병목 발생
• 주요 원인

  • 대역폭 부족 : 특정 구간의 네트워크 회선/장비가 처리할 양이 기존보다 많아질 경우

  • 서버 성능 문제 : CPU/Thread 고갈되어 요청을 처리하지 못할 경우

  • 잘못된 네트워크 구성 : 비효율적인 네트워크 구조, 잘못된 라우팅 설정 등

    ⇒ 결국 처리량(Throughput)은 감소하고 지연(latency)과 실패율(error rate)은 상승

병목 현상 해결하는 방법

1. 병목 지점을 파악해서 해결하기
   • 시스템 설계 차원에서 병목을 줄이는 기술적/구조적 최적화하기 → 이렇게 하기위한 기술들이 레이트 리미팅, CDN, Anycast, 캐싱 등
2. 시스템 이용자 수 제한하기
   • 접속 인원을 물리적으로 줄임 (대기열, 선착순 차단 등)
   • But, 대규모 이벤트에서는 최후의 수단..

병목 현상 완화하기 위한 기술들

1️⃣ 캐싱

• 정의
  • 반복적으로 요청되는 데이터를 저장해두고 빠르게 반환하는 방법
  • 즉, 요청의 “도착 지점”을 서버 → 캐시로 바꿔서 서버 부하를 줄임
• 원리

  • 대규모에서는 동일한 요청이 짧은 시간에 수십만/수백만 번 반복
    - ex ) 티켓팅: “잔여 좌석 정보 조회”, 쇼핑몰 세일: “상품 상세 조회”, “가격/재고 확인”

    # 매 요청마다 DB 조회 발생 -> 반복될시 병목현상 발생함
    사용자 → 서버 → DB → 서버 → 사용자

  • 캐싱이 적용된다면?

    # 캐시에 요청하는 값이 있을시에는 서버/DB까지 요청이 내려가지 않음
    사용자 → 캐시(CDN/Redis) → 사용자

  • 따라서, 요청이 서버까지 내려가는 횟수를 줄여 병목을 “근본적으로 차단”

• 클라이언트, 서버, 데이터베이스 수준에서 캐싱을 적용 가능

2️⃣ CDN(Content Delivery Network)

• 정의 : 지리적으로 분산된 여러개의 서버에 웹 콘텐츠들의 복사본을 저장해두고, 사용자가 요청했을때 사용자와 가장 가까이에 있는 서버에서 콘텐츠를 제공하는 기술
• 1번 캐싱의 구현형태라고 보면 됨
  • 즉, 캐싱이라는 원리 자체는 같지만, CDN은 특히 “전 세계 사용자가 몰릴 때” 효과가 극대화되는 캐싱 위치이기 때문에 별도로 작성
• 원본 서버는 실제로 요청을 받는 횟수가 대폭 감소 → 티켓팅 같은 순간 트래픽에서 원본 서버 보호

3️⃣ Rate Limiting

• 정의 : 서버가 특정 임계치까지만 클라이언트의 요청을 허용하는 정책을 의미 ex) 1분당 60회

• 원리

  • 리밋없이 사용자 모두 받은경우

    사용자 → 서버 → 쓰레드/DB/CPU 모두 소모 → 처리 대기 줄 증가 → 지연 증가 → 서버 다운

  • Rate Limiting 사용한 경우
    - 즉, 서버에 요청이 "도착하기 전에" 과도한 요청을 막음 = 서버가 감당 가능한 양만 처리하도록 강제하여 서버가 죽지 않도록함

    사용자 → (Rate Limiter) → 서버
                    ↓
            초과 요청은 즉시 차단 (429)

• 구현 알고리즘(대표적으로 2개만 설명)

  • Token Bucket : 버킷에 담긴 토큰의 수(= 요청가능한 횟수)를 파악하여 토큰이 없을시 요청 제한
    - 메모리 효율적이지만, 토큰이 나가는 시기와 버킷에 토큰이 채워지는 시기가 동시에 들어오면 Race Condition이 발생할 수 있음
    - 일정 속도로 토큰 생성, 요청 처리 시 토큰 소비
    
    
  • Leaky Bucket : 버킷에 요청을 담고, 가득 차면 더 담지못해 버려짐.
    - FIFO형식으로 작동함.
    - 요청을 일정 속도로만 처리하고 초과는 버림
  • 외에도 Fixed Window Counter, Sliding Logs, Sliding Window Counter이 존재함.

• 어느 위치에 적용하는것이 효과적일까?

위치	예시	설명
클라이언트(CDN / Edge)	Cloudflare / CloudFront	가장 앞단에서 악성/과도 요청 차단
미들웨어(API Gateway)	NGINX, Envoy	구현 용이하지만, 커스텀의 한계
서버(애플리케이션 내부)	Spring AOP, Guava RateLimiter	서버자원을 소비한 뒤 실행되지만, Rate Limit 커스텀 가능

⇒ 즉, Rate Limiting을 어떤 알고리즘으로 적용할건지, 어느 위치에 적용할건지는 각각의 장/단점을 살펴본 후 자신이 구현하는 서비스에 맞게 선택/적용하면됨.

4️⃣ Anycast

• 정의 : 서로 다른곳, 다른 호스트끼리 동일한 IP주소를 가질 수 있는 개념. 가장 가까운 노드와 통신하는 방식
• DNS에서 흔히 사용됨

• 원리
  • 부하가 지리적으로 자동 분산 : 요청이 전 세계에서 동시에 들어와도 한 곳으로 몰리지 않고 각 지역 POP로 흩어져 “한 지점이 포화되는 상황”을 예방

그래서 어떤걸 쓰라는걸까?

• 병목은 한부분에서만 발생하는 것이 아니라 각 단계마다 발생할 수 있는것!
• 각 레벨(클라이언트,미들웨어,서버)에서 "서버에 부하가 쏠리지 않도록" 차단/흡수/지연/분산을 동시에 적용하는것!

처음으로 돌아가서 그럼 대기순서 튕기는 문제는?

• 대기열은 서버가 처리할 수 있는 동시 요청 수를 초과하지 않도록 사용자 유입 속도를 조절하는 전략임
• 따라서 병목을 해소한다기보다 병목의 발생 위치를 서버 깊은 곳에서 앞단(대기열)으로 옮겨 피해를 최소화하는 방식인듯 싶다.
• 대규모 트래픽을 위해 대기열이라는 병목 완화전략이 적용되었으나, 대기열 자체가 병목지점이 된 경우인듯
• 실제 병목 완화는 CDN/캐싱 + Rate Limiting + DB 분산 등 계층별 전략을 함께 적용하면 되지 않을까? 하는 생각이 든다.

회고

실생활의 예시를 생각하면서 공부를 하니까 좀더 재밌게 느껴지는 것 같다. 오늘 정리한거 외에도 방식은 많고 다양한데, 앞으로 점차 더 공부해 나가면 좋을 것 같다!

[참고자료]

• https://www.cloudflare.com/ko-kr/learning/cdn/common-cdn-issues/
• https://www.cloudflare.com/ko-kr/learning/bots/what-is-rate-limiting/
• https://www.cloudflare.com/ko-kr/learning/cdn/glossary/anycast-network/
• https://velog.io/@david1-p/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EB%B3%91%EB%AA%A9%ED%98%84%EC%83%81-%EB%B0%8F-%EA%B5%AC%EC%A1%B0-%EC%A0%95%EB%A6%AC
• https://www.promleeblog.com/blog/post/302-11-network-performance
• https://j2doll.tistory.com/884
• https://gngsn.tistory.com/224#google_vignette
• https://2jaebbang.tistory.com/190