• V1 부하 측정에서 REST와 WebSocket을 한 JVM에 둔 경우 WebSocket 연결 증가와 함께 REST의 꼬리 지연, heap, GC pause가 악화됐다. V2에서는 두 서비스를 별도 Spring Boot 프로세스와 ECS Service로 분리한다.
• 선택 구조는 ECS on EC2 단일 AZ 배치다. REST와 WebSocket의 필수 용량은 같은 AZ의 On-Demand t3.small host에 두고, 중단 가능한 REST 추가 용량도 같은 AZ의 Spot ASG로 제공한다. AZ 장애 시 전체 서비스가 중단될 수 있다.
• Fargate는 호스트 운영 부담과 비용을 비교하는 대안으로만 둔다. ECS on EC2의 REST task는 1 vCPU / 1 GiB로 산정하며, Fargate 1 vCPU / 2 GiB와 메모리 용량이 다르다.
• WebSocket은 ALB가 Upgrade와 연결 전달을 맡지만, Spring이 STOMP 인증·구독 권한·메시지 저장·fan-out을 처리한다. Simple Broker로는 다중 task 간 메시지 전달이 되지 않아 공용 broker가 필요하다.
• HikariCP pending 포화는 관측됐으나 MySQL 쿼리·잠금·커넥션 점유 시간과 pool 크기 중 원인은 확정되지 않았다.

V1에서는 REST API와 WebSocket이 하나의 Spring Boot JVM에서 동작한다. 연결이 증가하면 WebSocket 세션 객체와 버퍼가 heap을 점유하고 REST 요청과 GC를 공유한다. 따라서 동시 부하에서 REST 응답 지연과 오류가 증가할 수 있다.

항목	REST 단독	WebSocket 1,642개 + REST	변화
조회 p95	11.0 ms	167.2 ms	15배
조회 p99	33.4 ms	914.8 ms	27배
조회 실패율	0%	4.54%	증가
backend CPU	0.032 cores	0.061 cores	1.9배
heap 최대	123 MB	277 MB	2.3배
GC pause p95	3.1 ms	257 ms	82배
HikariCP 대기	0	0	변화 없음
MySQL CPU	0.017 cores	0.018 cores	변화 없음

HikariCP와 MySQL CPU 변화 없이 heap과 GC pause가 증가하고 REST 지연이 악화됐다. 이는 두 서비스가 같은 JVM 자원을 공유할 때 지연이 전파될 수 있음을 보여준다. 실행 간 조건 차이가 있으므로 연결 하나의 인과 비용으로 해석하지 않는다.

목표 RPS	Hikari active 평균 / 최대	Hikari pending 평균 (관측 최대)	Spring exporter 정상 응답
45.5	0.7 / 10	0 (0)	21/21
91	8.9 / 10	162 (191)	10/21
180	10 / 10	184 (189)	4/21
226	9.9 / 10	157 (191)	7/21

45.5 RPS 표본에서는 커넥션 대기가 없었다. 91 RPS부터 pending이 크게 관측됐고, 180·226 RPS 구간에서도 풀이 가득 차고 대기가 이어졌다. 226 RPS 목표에서 실제 처리율은 157 RPS였다. exporter 표본 누락도 고부하 구간에서 증가했다.

HikariCP pending은 DB 커넥션을 기다리는 Spring 요청 수다. 이 지표는 Spring 쪽 대기열 포화를 보여주지만, 쿼리 지연이나 잠금, 긴 커넥션 점유, 풀 크기 부족 중 어느 것이 원인인지는 단독으로 밝히지 못한다. 이번 요청은 게시글 주변 조회 부하이며 택시팟 생성의 PESSIMISTIC_WRITE 경로와 구분한다. 조회 서비스는 read-only 트랜잭션을 사용하고 트랜잭션 종료 시 커넥션을 반환한다.

별도 V1 WebSocket 부하에서 동시 연결 1,734개일 때 heap 최대 301 MiB, 컨테이너 working set 604 MiB가 관측됐다. 연결당 heap 증가는 28.2 KB, idle 연결 CPU 회귀값은 연결 1,000개당 0.0092 cores였다. 이는 유휴 연결의 CPU 비용은 낮을 수 있지만, 연결 수용 한계와 메시지 처리량을 의미하지는 않는다.

V2는 DAU가 V1의 24배, 서비스 범위가 6개 업무지구로 늘어난다. 출퇴근 피크는 91 RPS, 행사 피크는 225.5 RPS와 WebSocket 동시 연결 1,800개다. 핵심 사용자 여정 기준 rolling 28일 99.9% 가용성을 목표로 하며, 월 오류 예산은 약 43분이다. 다만 ECS EC2 용량을 단일 AZ에 두는 현재안은 AZ 장애 시 REST와 WebSocket이 함께 중단될 수 있어 이 목표를 보장하지 않는다. 99.9%는 목표치이며 단일 AZ 장애를 포함한 보장치가 아니다.

구조	장점	단점	판단
단일 Spring Boot	구성과 운영이 단순하다.	REST와 WebSocket이 heap·GC·Tomcat 자원을 공유해 부하가 전파된다.	V1 방식. V2에는 부적합
동일 Spring Boot 다중화	Load Balancer로 host·process 장애와 요청을 분산한다.	각 인스턴스에서 REST·WebSocket 자원 경합은 계속되고, WebSocket 세션 분산 문제가 남는다. 동일 AZ에만 배치하면 AZ 장애는 분산하지 못한다.	단기 확장 방식
REST·WebSocket 분리	각 부하에 맞춰 자원과 배포를 독립 운영한다.	서비스 수가 늘고 WebSocket fan-out을 별도로 설계해야 한다.	V2 기본 구조
REST·WebSocket 분리 + ECS	task 및 서비스 단위 확장, 재시작과 배포 자동화가 가능하다.	ECS와 broker 운영 구성 요소가 추가된다.	V2 적용 구조

비용은 서울 리전 Linux 단가와 월 730시간 기준 compute 추정치다. ALB·NAT·CloudWatch·데이터 전송은 제외한다. EC2에는 EBS, 호스트 운영, Spot 보완 용량과 T3 CPU credit 비용이 추가될 수 있다. 이 안은 단일 AZ 배치이므로 AZ 장애 대비 용량 비용은 포함하지 않는다.

자원	시간당 단가
Fargate Linux/x86 vCPU	$0.04656 / vCPU-hour
Fargate Linux/x86 메모리	$0.00511 / GB-hour
Fargate Linux/ARM vCPU	$0.03725 / vCPU-hour
Fargate Linux/ARM 메모리	$0.00409 / GB-hour
EC2 t3.micro	$0.013 / hour
EC2 t3.small	$0.026 / hour
EC2 t3.medium	$0.052 / hour
EC2 t4g.small / t4g.medium	$0.0208 / $0.0416 per hour

Fargate는 task가 요청한 vCPU·메모리·스토리지와 실행 시간으로 과금한다. ECS on EC2는 EC2와 EBS 등 생성한 자원에 과금하며 ECS 오케스트레이션 자체에는 별도 비용이 없다. EC2는 빈 자원과 장애 보완 용량을 비용에 포함할 수 있다. 현재 단일 AZ 비용안은 AZ 장애 대비 용량을 포함하지 않는다. ARM 단가는 애플리케이션과 이미지 호환이 전제다.

가격 근거: AWS Fargate 요금, ECS 요금, Amazon ECS Price List, Amazon EC2 Price List.

구성	월 compute 비용	전제
Fargate REST 비교 2개, 각 1 vCPU / 2 GiB	약 $82.90	대안 비용 기준
Fargate WebSocket 비교 3개, 각 0.5 vCPU / 1 GiB	약 $62.17	600개 연결씩 분산하는 구성 가정
Fargate REST + WebSocket 비교	약 $145.07	위 두 항목 합계
EC2 REST t3.small 2대	약 $37.96 + EBS	host당 REST task 1개, 각 1 vCPU / 1 GiB
EC2 WebSocket t3.small 3대	약 $56.94 + EBS	host당 WebSocket task 1개, 각 0.5 vCPU / 1 GiB
EC2 REST 2대 + WebSocket 3대	약 $94.90 + EBS	REST 메모리가 Fargate보다 task당 1 GiB 작음
EC2 WebSocket t3.micro 3대	약 $28.47 + EBS	1 GiB WebSocket task에는 호스트 여유가 부족

EC2의 합산 비용이 낮아 보이지만 REST task 메모리가 Fargate 기준보다 작고 EBS·호스트 관리·CPU credit·장애 대비 여유 자원이 포함되지 않는다. $94.90과 $145.07은 동등 성능 구성의 비교가 아니다.

트래픽 시나리오에서 평시 출퇴근 피크는 45.5 RPS이며, 하루 두 세션 가정에서는 91 RPS다. 이 피크가 하루 4시간 이어지는 것으로 산정한다. 이벤트는 사용자 3,600명, 10분 삼각형 HTTP 유입에서 event-only peak 180 RPS, 평시 중첩 시 225.5 RPS다. WebSocket은 1,800개 연결을 첫 5분 동안 6개/초로 만들고, 부하 시나리오에서 10분 유지하며 메시지 peak는 36 msg/s다. WebSocket의 평시 동시 연결 수는 별도 성장 가정에 없으므로 산출할 수 없다.

WebSocket idle connection 측정값(연결당 heap 증가 28.2 KB, 연결 1,000개당 CPU 0.0092 cores)을 선형 환산하면 600개 연결은 heap 약 16.5 MiB와 CPU 약 0.0055 cores, 1,800개는 heap 약 49.5 MiB와 CPU 약 0.0166 cores의 증분이다. 이는 유휴 연결 비용 추정이며 JVM 기본 메모리, 메시지 저장·fan-out, CONNECT/SUBSCRIBE 처리나 수용 한계를 나타내지 않는다. 실제 STOMP 혼합 측정에서는 목표 1,800개 연결이 안정적으로 유지되지 못했고, 36 msg/s 목표 중 약 8.66 msg/s에서 OOM Kill이 발생했다. 따라서 이 측정만으로 WebSocket task 수나 Spot으로 줄일 task 수를 확정할 수 없다.

시기·역할	기준 용량	Spot 사용	조건 및 해석
평시 REST	On-Demand t3.small 2대	ASG 최소 0. 일일 4시간 peak에 1대 추가하는 경우를 비용 민감도로 계산	91 RPS에서 HikariCP pending이 관측돼 DB 여유가 확인될 때만 추가한다. Spot REST task마다 Hikari 최대 연결 10개가 더해지므로 DB 연결 예산을 넘기지 않는다.
이벤트 REST	평시 On-Demand 용량 유지	행사 전 Spot task를 추가하고 행사 후 0으로 축소	225.5 RPS 중 필요한 Spot task 수는 신규 task 처리율이 없으므로 산정 불가. Spot은 추가 처리량으로만 보고, 기준 용량/SLO에는 포함하지 않는다.
WebSocket	On-Demand task 유지. 3대는 잠정 시나리오	평시·이벤트 모두 필수 연결 용량에는 Spot 미사용	소켓은 Spot 회수 시 연결이 끊기며 재접속이 집중될 수 있다. 기존 측정에서 handshake 실패와 예기치 않은 종료가 컸으므로 event 1,800개를 Spot 용량으로 보장하지 않는다.

Spot 가격은 instance type·AZ·수급에 따라 변한다. 아래는 t3.small On-Demand $0.026/hour에서 50%·70%·90% 할인된다고 가정한 민감도이며, 실제 견적이 아니다. AWS도 현재 Spot 가격이 공급·수요에 따라 변하고 최대 90% 할인을 제시한다. EC2 Spot 요금 및 가격 변동.

사용 시나리오	Spot 실행량 가정	50% 할인	70% 할인	90% 할인
평시 REST peak: 1대 × 4시간/일 × 30일	120 host-hour/월	$1.56/월	$0.94/월	$0.31/월
이벤트 REST: Spot 1대당 매 1 event-hour	1 host-hour/event	$0.013/event	$0.0078/event	$0.0026/event
이벤트 WebSocket: 선택적 추가 1대당 매 1 event-hour	1 host-hour/event	$0.013/event	$0.0078/event	$0.0026/event

현재 기본 compute $94.90/월(REST On-Demand 2대 + WebSocket On-Demand 3대, EBS 제외)에 평시 REST Spot 1대를 매일 4시간 추가하면 민감도 합계는 약 $95.21~$96.46/월이다. 이벤트 비용은 이벤트 수 × 이벤트당 Spot 실행 시간 × Spot host 수 × host-hour 단가로 더한다. 이벤트 빈도와 사전 기동·종료 시간이 주어지지 않아 월 이벤트 비용은 고정하지 않는다. Spot WebSocket 비용 행은 선택 시 비용만 보여주며, 권장 기준 용량이나 연결 수용량을 뜻하지 않는다.

3대의 WebSocket t3.small을 24시간 Spot으로 바꾸면 compute 민감도상 월 $28.47(50% 할인), $17.08(70%), $5.69(90%)로 On-Demand $56.94보다 $28.47~$51.25 낮아질 수 있다. 그러나 이 절감은 24시간 연결을 Spot에 맡기는 대가로 얻는다. 기존 연결 측정에서 session 유지 실패와 재접속 폭증이 관측됐으므로 이 구조는 채택하지 않는다. Spot은 중단 가능한 REST 추가 용량에 우선 적용하고 WebSocket은 On-Demand로 유지한다.

역할	실행 환경	필수 용량	추가 용량	배치 원칙
Spring REST	ECS on EC2	On-Demand ASG 2대, 단일 AZ	같은 AZ의 별도 Spot ASG에서 REST task	On-Demand task가 기준 용량을 담당하고 Spot task는 중단 가능한 부하만 처리한다.
Spring WebSocket	ECS on EC2	On-Demand ASG 3대, 단일 AZ (초기 분산 가정)	기본안에는 Spot 미사용	task당 600 연결은 계산상 분배값이며 검증된 처리 한도가 아니다.
Fargate	비용·운영 비교안	해당 없음	해당 없음	호스트 운영 부담과 task별 비용 비교에만 사용한다.

기본 구조는 ECS on EC2로 확정한다. REST와 WebSocket은 역할별 On-Demand ASG와 capacity provider를 분리해 각 서비스의 필수 task가 Spot이나 다른 서비스의 host 여유에 의존하지 않도록 한다. REST ECS Service에는 On-Demand capacity provider의 base를 2 task로 설정하고, 동일 AZ의 Spot capacity provider를 추가 용량으로 연결한다. ECS의 base는 해당 provider에서 실행할 최소 task 수이며, base 충족 뒤 추가 task는 provider weight에 따라 분배된다. Spot을 사용할 수 없으면 추가 task가 배치되지 않을 수 있으므로 Spot 용량은 필수 처리량에 포함하지 않는다. 단일 AZ 배치이므로 AZ 장애 시 On-Demand와 Spot 용량이 모두 영향을 받는다. ECS capacity provider strategy.

Spot ASG는 단일 AZ에 두되 여러 인스턴스 유형을 지정하고 price-capacity-optimized 할당 전략, ECS managed scaling 및 instance draining을 적용한다. 단일 AZ 제한은 Spot 풀의 선택 폭과 가용성을 낮출 수 있다. Spot 중단은 연결 이전을 보장하지 않으므로 WebSocket의 기본 연결이나 필수 용량에는 Spot을 포함하지 않는다. Fargate는 이 구조의 대체안이 아니라 호스트 관리 부담과 비용을 판단하기 위한 비교 기준이다. ECS capacity provider, EC2 Spot 권장사항, ECS Spot draining.

항목	시작 스펙	근거
실행 환경	ECS on EC2 Linux/x86, REST 전용 ECS Service	WebSocket과 JVM 자원을 분리한다. 기준 task는 REST On-Demand capacity provider에 배치하고 Spot은 추가 용량으로만 사용한다.
CPU	1 vCPU	기존 실제 API 부하에서 CPU 평균은 0.48 cores였고, CPU가 우선 병목이라는 증거는 없었다.
메모리	1 GiB	비용안 task 용량 가정이다. 기존 768 MiB 제한에서 working set 평균이 622~662 MiB였으므로 여유 폭이 크지 않다. Fargate의 2 GiB 구성과 동등 용량으로 보지 않는다.
JVM heap	-Xms128m -Xmx512m	관측 heap 최대 335 MiB와 non-heap 메모리를 고려한다.
최소 용량	On-Demand t3.small 2대, 단일 AZ. host당 REST task 1개	기준 용량은 Spot 가용성에 의존하지 않는다. host 장애 직후에도 task 2개의 용량을 유지한다는 뜻은 아니며, AZ 장애 대응은 제공하지 않는다.
HikariCP	task당 maximumPoolSize 10을 시작 설정으로 유지	REST task 2개에서 최대 DB 연결은 20개다. 풀 포화 원인이 확정되지 않아 증설 근거는 없다.
월 compute	약 $37.96 + EBS 2개	t3.small On-Demand host 2대 비용. ALB·NAT·로그·전송 제외

단순 detail 조회는 0.75 CPU·768 MiB 환경에서 274.5 RPS, p95 16.7 ms, p99 44.1 ms, CPU 0.125 cores와 throttling 0으로 끝났다. 해당 쿼리는 운영 HomeService의 공간 검색과 다르므로 처리량을 직접 환산할 수 없다. 실제 API 혼합 부하에서는 91 RPS부터 HikariCP 대기, 226 RPS 목표에서 실제 157 RPS가 관측됐으며 CPU 평균은 0.48 cores였다. 따라서 task CPU는 1 vCPU로 두고, EC2 task memory는 비용 비교를 위한 1 GiB 가정으로 둔다. 이는 Fargate 2 GiB 기준보다 메모리가 작은 선택이다.

이 구성은 EC2 배포의 시작 기준이지 91·226 RPS SLO나 AZ 장애 시 서비스 지속을 보증하지 않는다. 단일 AZ 선택에 따라 해당 AZ 전체가 장애 도메인이 된다. ECS task CPU·메모리 조합, ECS 용량·가용성 권장사항.

ALB는 WebSocket HTTP/1.1 Upgrade를 target으로 전달하고, 성립한 연결을 유지한다. HTTPS listener에서 TLS를 종료할 수도 있다. ALB는 STOMP 명령이나 앱 로직을 실행하지 않는다. ALB는 최소 2개 AZ의 subnet을 활성화해야 하며, AWS 문서는 활성화한 각 AZ에 target group별 target을 두도록 요구한다. 따라서 ECS host/task를 한 AZ에만 두려는 현재 결정과 ALB target 요건은 그대로는 맞지 않는다. 배포 전 각 ALB 활성 AZ에 target을 둘지, 단일 AZ 조건을 유지하면서 ALB 대신 다른 진입 구성을 쓸지 확정해야 한다. ALB 생성 요건, ALB target 등록 요건.

현재 Spring WebSocket은 다음을 수행한다.

• CONNECT에서 JWT를 검증하고 사용자 Principal을 설정한다.
• SUBSCRIBE에서 채팅방 활성 참여자 여부를 DB에서 조회한다.
• SEND에서 참여자·채팅방·사용자를 확인하고 메시지와 읽음 위치를 DB에 반영한 뒤 방에 브로드캐스트한다.
• 메시지가 없는 동안에도 열린 socket과 STOMP session을 보유하므로 task memory와 file descriptor가 필요하다.

따라서 WebSocket 서버의 idle CPU가 낮더라도 프로세스가 할 일이 없는 것은 아니다. CONNECT·SUBSCRIBE·메시지 저장과 fan-out은 별도 CPU·DB 부하다.

현재 WebSocketConfig는 enableSimpleBroker("/sub")를 사용한다. Simple Broker는 구독 정보를 task 메모리에 두며 Spring 공식 문서도 clustering에 적합하지 않다고 명시한다. V2에서는 REST와 WebSocket 프로세스에서 생성하는 채팅 이벤트를 여러 WebSocket task로 fan-out하기 위해 Redis Pub/Sub를 공용 메시지 경로로 선택한다. 메시지 저장 원본은 MySQL이며 Redis Pub/Sub는 재생이나 소비 확인을 보장하지 않는다. 도입 시점, 이벤트 계약, 장애 복구와 RabbitMQ/STOMP broker relay 비교는 V2 WebSocket 메시지 버스와 Redis 도입 설계를 참고한다. Spring STOMP broker 문서, Redis Pub/Sub 전달 의미.

WebSocket 3대는 측정으로 도출한 최소 대수가 아니다. V1 별도 부하에서 총 동시 연결 1,734개, heap 최대 301 MiB, container working set 604 MiB가 관측됐지만, 이 결과는 V2의 0.5 vCPU / 1 GiB task에서 메시지 처리 부하를 포함해 task당 수용량을 검증하지 않는다. task당 600개는 1,800개를 세 task에 나눈 예산·배치 가정일 뿐이다. 이 가정대로라면 한 task 장애 뒤 남은 두 task가 각각 900개를 맡아야 하므로, 세 대가 1,800개 연결을 장애 중에도 유지한다는 근거도 없다.

역할	On-Demand host	ECS task	구성 가정
Spring REST	t3.small 2대, 동일 AZ	1 vCPU / 1 GiB, JVM heap 최대 512 MiB	host당 REST task 1개. Fargate 기준보다 메모리를 1 GiB 낮춘 비용안
Spring WebSocket	t3.small 3대, 동일 AZ (잠정)	0.5 vCPU / 1 GiB, JVM heap 최대 약 512 MiB	host당 task 1개. task당 600 연결은 검증 전 분배 가정
REST 추가 용량	별도 Spot ASG, 기본 수 0	1 vCPU / 1 GiB	REST task 추가 용량이며 기준 용량과 필수 처리량에는 포함하지 않음

t3.small은 2 vCPU·2 GiB, t3.micro는 2 vCPU·1 GiB다. ECS host의 OS와 agent 메모리를 남겨야 하므로 t3.micro는 1 GiB task와 함께 WebSocket 기본안에 적합하지 않다. t3.small은 task당 1 GiB REST 또는 0.5 vCPU / 1 GiB WebSocket 하나를 배치하는 시작 host다. task 여러 개를 같은 t3.small에 배치하면 호스트 메모리 여유가 부족해질 수 있다. T3 사양, ECS 메모리 관리, ECS task placement.

t3.micro 3대의 compute 비용은 월 약 $28.47이지만, 현재 WebSocket 시작 task인 1 GiB를 수용할 여유가 부족하다. 512 MiB task를 가정한 저비용 하한과 1 GiB task의 t3.small 구성을 같은 성능으로 비교하지 않는다.

T3는 burstable이다. t3.micro CPU baseline은 vCPU당 10%, t3.small은 vCPU당 20%다. 장시간 baseline을 초과하면 Unlimited surplus credit 비용이 생길 수 있다. CPU credit 수치와 과금은 호스트 비용에 포함해 해석한다. T3 CPU baseline과 credit, Unlimited 모드.

구성	월 compute 비용	비교
REST t3.small 2대	약 $37.96 + EBS 2개	각 host에 1 vCPU / 1 GiB task
WebSocket t3.small 3대	약 $56.94 + EBS 3개	각 host에 0.5 vCPU / 1 GiB task
REST 2대 + WebSocket 3대	약 $94.90 + EBS 5개	REST 1 GiB task를 전제로 한 합계
WebSocket t3.micro 3대	약 $28.47 + EBS 3개	1 GiB task의 호스트 메모리 조건과 맞지 않음

REST 2대와 WebSocket 3대의 t3.small 합계는 WebSocket 3대 가정을 둔 비용 시나리오이며, Fargate 기준 구성 약 $145.07보다 compute 가격이 낮다. 다만 EC2 REST task 메모리는 Fargate보다 1 GiB 작고, EC2 금액은 EBS·CPU credit·호스트 관리·spare capacity를 제외한다.

ECS on EC2를 기본 배포 구조로 선택한다. REST는 같은 AZ의 On-Demand t3.small 2대에 1 vCPU / 1 GiB task를 하나씩 둔다. WebSocket의 On-Demand t3.small 3대, task당 0.5 vCPU / 1 GiB는 현재 1,800개 동시 연결을 위한 잠정 분산 가정이며, task당 연결 수와 필요한 최소 대수는 V1 측정만으로 확정되지 않는다. REST Spot ASG는 같은 AZ의 추가 용량으로만 사용한다.