1. 과제 설명

• 확장성을 고려한 배포 아키텍처 다이어그램 (예: 여러 모델 서비스 인스턴스와 로드밸런서 구성, 오토스케일링 정책 등).

---

2. 아키텍처

---

3.오토스케일링 정책

• 다음 조건을 만족하면 인스턴스 3대까지 자동 확장(기본 1대):

조건	기준값	설명
CPU 사용률	평균 65% 이상 (5분 지속)	API 요청 처리량 증가 시 CPU 사용량 증가 대응

a. Terraform 오토스케일링 예시

resource "google_compute_autoscaler" "fastapi_autoscaler" {
  name   = "fastapi-autoscaler"
  region = "asia-northeast3"
  target = google_compute_region_instance_group_manager.fastapi_mig.id

  autoscaling_policy {
    min_replicas    = 1
    max_replicas    = 3
    cooldown_period = 60

    # CPU 사용률 65% 초과
    cpu_utilization {
      target = 0.65
    }
}

b. 로드밸런서를 도입한 이유

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

c. Nginx를 고려한 사항

• Nginx는 L7 계층의 비동기 이벤트 기반 로드밸서로 사용하여 다수의 연결을 효율적으로 관리할 수 있다.
• Nginx는 epoll 기반의 비동기 처리 구조로 FastAPI와 잘 맞고, 경량화된 운영이 가능하며, 컨테이너/클라우드 환경에 적합하다는 장점이 있다.
• 하지만 Nginx는 직접 VM 또는 컨테이너에 배포해야 하며, 이로 인해 다음과 같은 단점이 존재한다:
  • 별도 인스턴스나 컨테이너로 자체 운영/모니터링 필요
  • 확장성 확보가 제한적 (특히 AI 서버 오토스케일링 환경에서는 스케일된 대상과 분리된 상태 유지 필요)
  • 인프라 구성의 복잡도 증가

d. 클라우드 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 오토스케일링 환경에 더 최적화된 선택이다.