Kim-Baek 개발자 이야기

서버 한 대로는 한계였다Court Alarm이 2년째 운영되면서 사용자가 급증했다.월간 활성 사용자: 10만 명일일 예약: 5,000건동시 접속: 1,000명MySQL 서버 하나로 버티고 있었는데, 점점 한계가 보이기 시작했다.CPU: 90% (쿼리 처리)메모리: 85% (버퍼 풀)디스크 I/O: 포화 (읽기/쓰기)응답 시간: 2초 (평소 50ms)특히 새벽 6시, 예약 오픈 시간에는 서버가 거의 죽었다.두 가지 선택지가 있었다:1. Scale-Up (수직 확장)서버 스펙 업그레이드CPU, RAM, SSD 증설한계: 비용 급증, 물리적 한계2. Scale-Out (수평 확장)서버 추가읽기/쓰기 분산무한 확장 가능당연히 Scale-Out을 선택했다. 그리고 두 가지 기법을 적용했다:Replication: ..

같은 쿼리가 다른 결과를 보여줬다예약 통계를 보여주는 대시보드를 만들고 있었다.@Transactionalfun getStatistics(userId: Long): Statistics { // 1. 총 예약 수 val totalCount = reservationRepository .countByUserId(userId) // 2. 예약 목록 val reservations = reservationRepository .findByUserId(userId) return Statistics( totalCount = totalCount, reservations = reservations )}이상한 현상:totalCoun..