4단계에서는 바꾸까 v1 출시 후 짧은 기간에 많은 사용자들이 몰린 상황을 가정한다.

1. 사용자 급증
2. 팀원 수는 크게 증가하지 않음

세션 시작률 = Peak 동시 사용자(세션) 수 2,000 / 체류 시간 300초 = 약 6.7 세션/초
6.7 세션/초 x 11.95 요청/세션 =  약 80

v1은 적은 비용과 빠른 배포 두 가지를 기준으로 설계했고, 그 결과 EC2 t4g.small(2 vCPU / 2 GiB) 단일 인스턴스 한 대에 서비스의 모든 구성 요소를 컨테이너로 배포했다. 컨테이너 관리 도구는 Docker Compose다.

flowchart TB
    U["사용자"]

    subgraph AWS["AWS 서울 리전 · 단일 AZ"]
        subgraph EC2["EC2 t4g.small · 2 vCPU / 2 GiB · 단일 인스턴스"]
            NG["Nginx<br/>SSL 종료 · 리버스 프록시"]
            FE["Next.js<br/>프론트엔드 서버"]
            BE["Spring Boot<br/>백엔드 API"]
            AI["FastAPI<br/>AI 서버<br/>+ ChromaDB(인메모리)"]
            DB[("MySQL")]
        end
        EBS[("EBS<br/>DB 데이터 볼륨")]
        S3[("S3<br/>업로드 이미지")]
    end

    LLM["Claude API"]
    MODAL["Modal 서버리스"]

    U -->|HTTPS 443| NG
    NG -->|/| FE
    NG -->|/api<br/>WebSocket 연결| BE
    FE -->|SSR 렌더링용 API 호출| BE
    BE -->|presigned URL 발급| FE
    FE -->|이미지 업로드<br/>presigned URL| S3
    BE -->|이미지 URL·텍스트·시세·검색| AI
    AI -->|이미지 조회<br/>presigned URL| S3
    BE --> DB
    AI --> LLM
    AI --> MODAL
    DB --- EBS

v1 구조 전제와 이유

v1의 이 전제들은 당시 상황에서는 맞는 선택이었다. 2장에서는 1.1에서 가정한 v2 트래픽이 이 구조에 그대로 들어왔을 때 어떤 문제가 발생하는지를 확인한다.

앞서 가정한 트래픽(Peak RPS 80, 동시 사용자 2,000)이 v1 구조에 그대로 들어오면, 아래 문제들이 발생한다.

1. 인스턴스 한 대의 성능이 곧 처리량 상한
2. 서비스 Scale-Out 불가능
   • 로그인 세션이 인스턴스 내부에서 관리되며 메시지 브로커가 동일 인스턴스 내부에서만 동작되므로, 두 번째 서버를 띄워도 같은 상태를 보지 못함
3. 단일 장애점(SPOF)
   • 모든 구성요소가 한 인스턴스에 포함되어 있어 인스턴스 정지, 커널 패닉, OOM 발생 시 서비스 전체 중단
4. Tomcat Thread Pool 및 Connection 고갈
   • 기본 임베디드 Tomcat Thread는 200개
   • FastAPI를 거쳐 LLM을 동기 호출하고 있어 응답 대기 시간 동안 Thread 미반환
   • Peak 시 Thread 고갈로 인해 전체 API 중단
5. 단일 호스트 I/O 및 메모리 병목
   • 기존 MySQL 설정(buffer-pool-size=128M, max-connections=30)은 Peak 시 Connection 에러 발생
   • MySQL, MongoDB, OS 로그가 하나의 EBS 디스크 I/O를 공유하여 I/O 병목으로 인해 전체 시스템 중단
6. 배포 시 중단 발생
   • DAU 4만 명의 서비스는 상시 트래픽이 발생하는데, 주 1회 정기 배포 시 최대 5분의 In-Place 다운타임으로 사용자 이탈 발생

v2에서는 v1과 달리, MAU가 20만명, peak RPS가 80으로 사용자층과 트래픽이 매우 성장했다. 그리고 사용자층이 확장되면서, 우리 사용자들은 더이상 서비스 중단을 용납하지 않는다. 따라서 v1의 "적은 비용"과 "빠른 배포" 라는 기준을 동일하게 적용하기 어렵다. 그러므로 v2의 기준을 새로 정리한다.

• 가용성은 모든 기능에 같은 수준으로 적용하지 않는다. 기능마다 사용자가 느끼는 실패의 무게가 다르기 때문이다.
• 데이터 보존을 가용성과 분리한 이유: 서비스가 잠시 멈추는 것과 거래 기록이 사라지는 것은 다른 문제이다.
• 하한선에 미달하는 선택지는 다른 기준을 아무리 잘 만족해도 선택하지 않는다.
• 하한선이 없는 기준은 비교 기준이다. 하한선을 통과한 선택지가 여럿 남았을 때 순서대로 적용해 고른다. 예를 들어, 같은 기준을 만족한다면 비용이 적은 쪽을 선택한다.
• 하나의 기준만으로 정하지 않는다. 여러 기준을 동시에 고려한다.

v1 인프라는 트래픽이 급증한 상황을 받아들일 수 없으므로, 이 트래픽을 감당할 수 있도록 인프라 구성을 변경해야 한다. 그 방법으로는 인스턴스 성능을 높이는 Scale-up과 인스턴스 개수를 늘리는 Scale-out 전략이 있다.

MySQL, MongoDB

• 인덱싱과 튜닝(쿼리, 자원) 작업을 통해 2,000 QPS도 충분히 처리할 수 있다.
• 분산 DB, 샤딩은 운영 복잡도(분산 트랜잭션, 데이터 정합성)가 높아지는 데 비해 Peak RPS가 80인 상황에는 필수적이지 않다.
• 서버 1대에 의존하면 장애 발생 시 전체 서비스가 중단되기 때문에 Read Replica를 1대 추가로 분리한다.
  => 사용자 수가 급격히 증가하고 있기 때문에 시스템 중단으로 인한 UX 저하는 치명적이기에 복제본 1대 정도의 추가 비용은 감수한다.

백엔드 서버

• Scale-up 전략은 v1의 단일 인스턴스 구성으로 인해, v2 확장 기준 중에서 가용성 하한선(하나의 장애가 서비스 중단으로 이어지지 않아야 한다)에 도달하지 못한다.

WAS(Stateless)

• 장애 발생 가능성이 높고, 분산으로 인한 운영 복잡도가 크게 증가하지 않아 여러 인스턴스에 복제본을 배치한다.
• [바꾸까]의 핵심 유저플로우인 물물교환을 위해서는 채팅을 거쳐야만 하기 때문에 채팅(웹소켓) 요청량의 비중이 매우 크다. 따라서 API 서버와 웹소켓 서버를 분리한다.

Scale out 전략으로 서비스를 확장할 때, 동일 AZ 혹은 다른 AZ에 인스턴스를 늘리는 경우의 가용성 범위와 한계를 정리하면 아래와 같다.

우리의 서비스는 "인스턴스 한 대의 장애가 서비스 중단으로 이어지지 않는다"라는 가용성 하한선을 지키기 위해서, 최소 동일 AZ에서 Scale-out이 필요하다.

동일 AZ에서 더 나아가, AZ 분산을 선택하는 이유는 두 가지다.

• 첫째, EC2 인스턴스 요금은 어느 AZ에 두든 동일하므로 가용성을 한 단계 올리는 데 인스턴스 비용이 추가되지 않는다.
• 둘째, AWS는 단일 AZ 구성에 99.5%만 보장하고, 2개 이상 AZ에 배포된 경우에만 99.99% SLA를 적용한다. 즉 최소 비용 기준을 해치지 않으면서 연간 최대 다운타임 보장을 43.8시간에서 52.6분으로 줄일 수 있다.

우리 서비스는 국내에서만 배포하므로, 리전은 AWS 서울 리전만을 선택한다. AWS SLA에 따르면, 멀티 AZ의 업타임 보장 수준이 99.99%이므로, 단일 리전 AZ 단위 확장도 충분한 가용성을 보장한다고 판단했다.

• Public Subnet: 인프라 관리자가 2명인 상태에서 급하게 설계를 확장하는 상황에서 복잡한 통신 구조는 한계가 있고, 민감 정보를 포함하는 서비스가 아니다.
  • ALB
  • Frontend EC2(인바운드 ALB 보안그룹만 허용 / 아웃바운드 Backend 보안그룹만 허용)
  • Backend EC2(인바운드 ALB, Frontend 보안그룹만 허용 / 아웃바운드 DB, AI 보안그룹 및 OAuth용 443 포트만 허용)
  • AI EC2(인바운드 Backend 보안그룹만 허용 / 아웃바운드 외부 LLM API 호출용 443포트 전체 허용)
  • DB(인바운드 Backend 보안그룹만 허용 / 아웃바운드 전체 차단)

• 외부 유저를 유입하게 되었기 때문에 서비스 성장을 위해 검색 엔진 노출을 목적으로 SSR로 전환한다.
• 컨테이너 기반 Next.js Standalone 구동을 통해 경량 이미지로 인스턴스 클러스터에서 직접 서빙한다.
• CPU 낭비를 방지하기 위해 CloudFront를 전면에 배치하여 공통 정적 페이지 및 에셋을 엣지에 포함하고, 동적 렌더링 요청만 SSR 컨테이너로 전달한다.

• Vercel에 비해 비용이 효율적이지만, OpenNext 변환 레이어 관리 부담이 생긴다.
• Next.js 버전을 올리거나 빌드 설정을 바꿀 때 발생하는 런타임 에러(청크 누락, 미들웨어 에러 등)를 인프라 엔지니어가 리버스 엔지니어링으로 디버깅해야 한다.
• 순간적으로 트래픽이 상승하여 여러 개의 신규 샌드박스가 동시 생성되거나 요청량이 일관적이지 않으면 콜드스타트로 인해 로딩 지연과 타임아웃을 유발할 수 있다.
• Provisioned Concurrency를 활성화하면 해결할 수 있지만, 상시 가동 비용이 발생하여 최대 장점인 비용 절감이 사라지고, 고정 비용이 EC2보다 비싸진다.

• 수치 산정
  • Peak 80 RPS 중 정적 파일 캐시를 제외하고 동적 SSR 요청 50 RPS
  • 일일 SSR 요청 수 20만(DAU 4만 * 유저당 평균 5개 페이지 이동 가정)
  • 월간 SSR 요청 수 600만
  • 1회 렌더링 200ms
  • 메모리 1GB
• Lambda
  • 총 컴퓨팅 리소스: 600만 * 0.2s * 1GB = 120만 GB-s
  • 매월 100만 건 호출, 400만GB-s 컴퓨팅 무료
  • 비용: 11.67$(무료 티어 없으면 17.2$)/월
  • 요청 수: (600만 건 - 100만 건) * 0.2$/100만 = 1$
  • 컴퓨팅: (120만GB-s - 40만GB-s) * 0.0000133334$ = 10.67$
  • [바꾸까]는 점심시간(12-13시)이나 18시-21시에 트래픽이 상승하지만, 이벤트성 서비스가 아니기 때문에 콜드 스타트로 인한 지연을 체감할 정도의 예상치 못한 트래픽 수치로 상승할 확률이 매우 낮다.
    => Provisioned Concurrency는 사용하지 않는다.
• EC2
  • 단일 인스턴스는 장애 시 서비스 전체가 중단되기 때문에 t4g.small 2대를 서로 다른 AZ에 배치한다.
  • ALB를 통해 health check를 수행하고 트래픽을 분산한다.
  • CPU 사용률이 70% 초과 시 최대 4대까지 스케일아웃되도록 ASG를 연동한다.
  • 비용: t4g.small 15.18$ * 2 = 30.36$월 + ALB 비용

EC2 Container 선정

• Lambda가 비용적으로 우세(1/3 가격)하고 자동으로 관리(고가용성)해주는 장점이 있으나, 콜드 스타트는 우리 서비스에 매우 치명적이기에 20$의 가치보다 UX 저하로 인한 손해가 더 크다.
• 고정 비용 지출로 예측 가능하기에 비용 상한선을 통제할 수 있다.
• 다른 애플리케이션과 동일한 환경에서 배포하기에 별도의 배포 환경을 위한 추가적인 학습이 불필요하다.

• 국내 한정 서비스라 글로벌 캐싱은 불필요하지만, 정적 파일 요청을 컨테이너까지 전달하고 응답하는 건 리소스 낭비다.
• Next.js 런타임은 싱글 스레드 이벤트 루프 기반이기 때문에 정적 파일 요청이 유입되면 CPU 렌더링 자원을 뺏겨 응답 속도가 저하된다.
• 정적 파일까지 Next.js에서 처리하려면 처리해야 할 RPS를 더 높게 산정하고 자원을 더 많이 할당하여 비용이 상승한다.
• CloudFront는 월 데이터 전송량 1TB와 1000만 건의 요청을 영구적으로 무료 제공한다. 무료 범위를 초과해도 0.085$/GB이므로 비용이 합리적이고, 응답 시간이 매우 빠르기에 CloudFront Edge 캐싱을 활용한다.
• CloudFront를 사용하고, 정적 파일을 저장할 저장소로 AWS S3 버킷을 활용한다.
  • 빌드 시점에 .next/static 결과물을 S3로 갱신하는 CI/CD 스크립트를 포함해야 한다.
  • 경로 패턴이 _next/static/*, /public/*이면 AWS S3 버킷에서 데이터를 조회하고 캐싱하여 정적 파일을 서빙한다.
  • Next.js는 BE와 통신하여 동적으로 HTML을 생성하는 데에만 리소스를 사용한다.

• Reverse Proxy(ALB)를 통한 Same-Origin 구성으로 CORS 문제 해결
  • bakkucca.com/api/*: Backend API target group
  • bakkucca.com/ws/*: Backend WebSocket target group
  • bakkucca.com/*: Next.js target group
• SSR 환경에서 VPC 내부 통신
  • VPC 내부 DNS로 요청(예: http://backend.internal:8080)
  • 불필요한 패킷 지연 단축

단일 App 서버의 한계와 문제 해결

핵심 정리

1. 백엔드 서비스는 독립된 인스턴스로 확장, 배포한다.
2. 백엔드 상태 분리를 위해 Redis를 사용한다.
   • 이를 위한 인프라로 ElastiCache Serverless(Valkey)를 사용한다. 월 약 $8~12로 선택지 중 가장 저렴하고, 여러 AZ 복제와 자동 전환이 기본으로 포함된다.
3. 다중 인스턴스 간 채팅 메시지 중계도 동일하게 ElastiCache Serverless(Valkey)를 사용하며, Redis Pub/Sub 기술을 도입한다.

$QPS_{peak} = RPS_{peak} \times (\text{요청당 평균 DB 쿼리 수})$

• Peak RPS: 80 RPS 중 정적 캐싱(S3/CloudFront)을 제외하고 백엔드로 유입되는 동적 API 요청은 약 50~70 RPS
• 요청당 쿼리 수: 일반적인 CRUD 및 인증 확인을 거치는 웹 트랜잭션은 요청 1회당 평균 3~5개의 쿼리 유발 (JPA Fetch Join 및 N+1 최적화 전제)
• 산출된 요구 성능
  • Peak Read QPS: $70 \times 4 \times 0.8 \approx 224 \sim 300\ \text{QPS}$
  • Peak Write TPS: $70 \times 0.2 \approx 14 \sim 25\ \text{TPS}$
• Active Working Set (메모리 적재 대상 데이터 크기):DAU 4만 명의 유저 세션 메타데이터, 최근 등록된 물물교환 게시글 10,000건, 활성 채팅방 메타데이터 및 카테고리 인덱스의 총합은 약 1.5GB ~ 2.2GB.

DB 전문가가 없고, 인프라 관리자가 2명인 상황에서 EC2 위에 도커로 DB를 띄우면, 컨테이너 비정상 종료, 데이터 파일 깨짐, Disk Full 장애 발생 시 실시간 복구(MTTR)가 어려워서 서비스 장애로 직결된다.
EC2 대비 월 15$~30$ 추가 지출이 발생하지만, RDS가 제공하는 자동화된 특정 시점 복구(PITR)와 백업, 스토리지 자동 확장, 파라미터 템플릿 관리는 2인 인프라 팀이 부담해야 할 유지보수 비용을 90% 이상 흡수하기에 당장 추가 인원 보충이 어려운 상황에서는 가치 대비 적은 비용이다.

• 단순 Read Replica(비동기 복제)는 Primary DB가 죽었을 때 자동으로 Primary로 승격(failover)되지 않는다.
• 개발자가 수동으로 승격시키고, Spring Boot의 DB 주소를 변경해 재배포해야 하므로 다운타임이 수십 분 이상 발생한다.
• 비동기 복제 특성상 Primary 장애 직전 트랜잭션이 유실될 수 있다.

Peak 80 RPS 수준에서는 단일 인스턴스로도 Read/Write 처리가 충분하다.
현재 중요한 것은 읽기 트래픽 분산이 아니라 단일 장애점(SPOF) 제거 및 데이터 유실 없는 무중단 복구이므로 Multi-AZ Standby를 우선 도입한다.
=> 평소에 Read 쿼리를 처리하지 않는 Hot Standby 상태이므로 비용이 2배로 증가한다. => Standby와 Primary 전환(failover) 중 약 1분의 중단이 발생한다.

인스턴스: db.t4g.medium(2vCPU, 4GB RAM)

• db.t4g.medium의 4GB 메모리 중 70-75%인 약 2.8GB를 innodb_buffer_pool_size로 할당하면, 바운딩된 Working Set(1.5-2.2GB) 전체가 메모리에 상주하여 Buffer Pool Hit Ratio를 95% 이상으로 유지할 수 있다.
• 최대 2,200 QPS를 소화할 수 있으므로, 현재 요구치인 300 QPS는 한계치의 약 14%이기에 트래픽 스파이크에 안정적으로 대응할 수 있다.
• burstable 인스턴스 특성상 CPU 크레딧 고갈 시 성능이 20%로 저하될 위험이 있다. 14% 사용률이면 상시 크레딧이 축적되어 현재 운영 환경에서 효율적이다.

스토리지: AWS EBS gp3(기본 50GB, 3,000 IOPS, 125 MB/s)

• 다른 요소(기존 구성의 타 DB, OS 등)들과 완전히 격리한다.
• I/O 요구량
  • Read I/O:
  • Write I/O:
  • 합산:
• 기본 제공걍인 3,000 IOPS는 80 RPS의 쓰기 작업에 충분하다.

커넥션 수가 CPU 코어 수를 초과해 과도해지면 Context Switching과 CPU 캐시 라인 무효화로 인해 처리량이 급감한다.

• MySQL 엔진이 CPU/메모리에서 순수하게 SQL을 파싱하고 실행하는 시간은 평균 0.24초.
• Spring Boot의 @Transactional 환경에서 애플리케이션이 HikariCP 커넥션을 점유하고 놓지 않는 시간(Connection Hold Time)은 Java 힙 메모리에서의 객체 매핑, 비즈니스 - 연산, 네트워크 왕복 시간(RTT)이 더해져 실제 1회 트랜잭션 동안 커넥션을 쥐고 있는 시간은 20ms까지 늘어날 수 있다.
• 점유 시간이 2ms에서 20ms로 10배 늘어나면, 리틀의 법칙에 의해 특정 순간 커넥션을 물고 있는 평균 개수도 $0.24 \times 10 = \mathbf{2.4\text{개}}$로 늘어난다.
• 여기에 피크 시 트래픽 버스트가 튀면 순간적으로 10~15개의 커넥션이 동시에 활성화될 수 있다.
• MySQL은 해당 커넥션에서 지금 당장 쿼리가 돌고 있는지(Active), 아니면 HikariCP 풀 안에서 대기 중인지(Sleep/Idle) 구분하지 않고 똑같이 max_connections 슬롯 1개로 계산한다.

=> 애플리케이션 풀 사이즈를 10개보다 더 늘릴 필요가 없다.
=> 2개의 애플리케이션을 구동하다가 무중단 배포 진행 시 2배로 늘어나 40개의 커넥션이 필요하다.

[ 배포 전환 순간 ]
- 구버전 WAS 1 (Hikari: 10개) ──┐
- 구버전 WAS 2 (Hikari: 10개) ──┼──► MySQL 커넥션 일시적 40개 점유
- 신버전 WAS 1 (Hikari: 10개) ──┤
- 신버전 WAS 2 (Hikari: 10개) ──┘

=> AWS RDS 관리 데몬, 엔지니어 운영 툴 등 별도 커넥션이 추가로 필요하다.
=> 총 60개 이상의 max_connections 설정이 필요하다.
=> MySQL의 기본 설정값이 151로, 부족함이 없다.
=> max_connectoins 외에도 별도 세부 설정 튜닝이 현재 환경에서는 필수적이지 않으므로 고려하지 않는다.

• DB
  • RDS(Multi-AZ): 76$
• FE
  • CDN: 무료
  • NextJS 인스턴스 컨테이너(t4g.small * 2): 30.36$
• Load Balancer
  • ALB: 기본 16.2$ + LCU 20(~30)$
• BE
  • ECS on EC2(t4g.small * 2): 30.36$
  • EBS 30GB * 2: 5.5$

=> 총합 178.42$