예약 오픈 트래픽, 인프라로 어디까지 하고 뭐가 남았나 (미해결)
· 운영성능회고
공개 가능한 형태로 익명화한 운영 회고. 깔끔한 성공담이 아니라, 인프라로 어디까지 가능했고 뭐가 한계였는지에 대한 기록이다.
OO 지자체의 예약 서비스를 매니지드로 운영했다. 평소엔 트래픽이 잔잔하다가 신청이 열리는 시점에만 접속이 한꺼번에 몰리는 서비스였다.
먼저 역할을 적어두면, 앞단의 가상 대기열(NetFunnel)로 동시 진입을 막는 부분은 개발사가 담당했고, 나는 그 뒤 클라우드 인프라(서버·DB·스토리지) 매니지드였다. 이 글은 인프라 쪽에서 부하를 받아내려 한 기록이다.
한 일
1. 수직 스케일업. 오픈 전에 DB VM을 16 vCore / 64GB → 32 vCore / 128GB로 올리고, 끝나면 되돌렸다. 빠르긴 한데 임시방편이었고, CPU·메모리를 키워도 특정 구간 지연이 사양만의 문제가 아닌 것 같았다.
2. 디스크 IO 의심·측정. DB 추가 디스크가 HDD인 게 눈에 들어왔다. CPU를 아무리 키워도 디스크가 못 받아주면 거기서 막힌다. 막연히 SSD를 지르는 대신 fio로 HDD/SSD의 IOPS·throughput·latency를 비교했고, 그 수치를 근거로 SSD로 교체했다. 추정을 숫자로 바꾼 건 의미가 있었다.
3. 부하 테스트. 스케일업 상태에서 JMeter로 동시접속·TPS·응답시간을 돌리고 병목 구간을 봤다.
뭐가 남았나
솔직히 이걸로 오픈 순간의 응답 지연을 완전히 잡진 못했다. 돌아보면 한계가 분명하다.
- 인프라 레이어에서 근본 원인을 끝까지 못 좁혔다. 디스크 IO는 한 요인이었지만, 애플리케이션 쿼리·DB 락·커넥션 풀 같은 상위 레이어가 더 큰 병목이었을 가능성을 측정으로 확인하지 못했다.
- 수직 스케일업은 어느 지점에서 더 못 올라간다. 읽기 분산·캐시·큐 같은 구조적 접근이 필요했는데, 매니지드 운영 범위와 권한을 넘는 영역이었다.
- 진입 제어(개발사)와 백엔드 용량(인프라)이 맞물리는 지점을 같이 분석하지 못했다.
배운 점
인프라 레버(스케일업·디스크·사양)만으론 못 잡는 문제가 있다. 그럴 때일수록 애플리케이션·DB 레이어랑 같이 측정해야 한다. “측정했다”랑 “원인을 규명했다”는 다른데, fio·JMeter로 데이터는 얻었지만 원인까지 좁히는 분석이 부족했다.
미해결이라도 적어둘 가치는 있다고 본다. 다음에 같은 유형을 만나면 처음부터 상위 레이어를 같이 의심할 거다.
예전 블로그에 적었던 작업 기록을 옮겨온 글입니다.