[AI] 로드밸런서 도입 검토 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

로드밸런서 도입 검토

기본 인스턴스는 1대이지만 트래픽이 증가할 경우, AutoScale을 통해 최대 3대로 늘릴 것이기 때문에 확장을 대비해 설계

Nginx 도입 검토

Nginx는 L7 계층의 비동기 이벤트 기반 로드밸서로 사용하여 다수의 연결을 효율적으로 관리할 수 있다.

Nginx는 epoll 기반의 비동기 처리 구조로 FastAPI와 잘 맞고, 경량화된 운영이 가능하며, 컨테이너/클라우드 환경에 적합하다는 장점이 있다.

하지만 Nginx는 직접 VM 또는 컨테이너에 배포해야 하며, 이로 인해 다음과 같은 단점이 존재한다:

• 별도 인스턴스나 컨테이너로 자체 운영/모니터링 필요
• 확장성 확보가 제한적 (특히 AI 서버 오토스케일링 환경에서는 스케일된 대상과 분리된 상태 유지 필요)
• 인프라 구성의 복잡도 증가

클라우드 Load Balancer를 사용한 이유

이에 따라 GCP의 HTTP(S) Load Balancer를 도입했다. 이 서비스는 다음과 같은 이유로 더 적합하다:

• Fully-managed: 별도의 VM이나 애플리케이션 없이 Google Cloud가 로드밸런싱, 헬스체크, 트래픽 분산을 자동으로 관리
• Cloud-native 통합: GCE, GKE, Cloud Run 등과 연동이 원활하고 IAM, VPC, 로그, 모니터링과도 쉽게 통합
• 오토스케일링 그룹과의 연동: AI 서버와 같은 오토스케일 인스턴스 그룹을 backend service로 바로 연결 가능
• 고정 IP, SSL 종료, URL 매핑 지원: 운영 편의성과 보안 측면에서도 장점

즉, Nginx는 효율적인 소프트웨어 로드밸런서였지만,

GCP Load Balancer는 클라우드 인프라 전반과 통합되는 “서비스형 로드밸런서”로서, AI 오토스케일링 환경에 더 최적화된 선택이다.