SW BBANG K

배포 직후엔 멀쩡하던 서버가 트래픽이 몰리고 나서 갑자기 응답이 느려진다. CPU 사용률을 보면 100%도 아닌데 레이턴시는 치솟는다. T3 인스턴스를 운영하다 보면 한 번쯤 마주치는 상황이고, 원인을 모르면 인스턴스 타입을 무작정 업그레이드하게 된다. 문제는 CPU 크레딧이다. TL;DR — T3 CPU 크레딧 핵심 요약 항목 내용 T3 동작 방식 기준선(Baseline) 이하 사용 시 크레딧 적립, 초과 시 소진 크레딧 소진 시 동작 Standard 모드: CPU가 기준선으로 스로틀링 / Unlimited 모드: 추가 과금 후 버스트 유지 T3 기본 모드 Unlimited (T3 출시 이후 기본값) 성능 저하 주요 원인 Standard 모드에서 크레딧 고갈, 또는 Unlimited 모드에서 예상치 못한 추가 비용 진단 지표 CloudWatch: CPUCreditBalance, CPUSurplusCreditsCharged T3 버스터블 인스턴스의 동작 원리 T3는 일반 인스턴스와 달리 vCPU를 항상 전속력으로 쓸 수 없다. 인스턴스 크기마다 정해진 CPU 기준선(Baseline) 이 있고, 그 이하로 사용하면 크레딧이 쌓이고, 초과하면 크레딧을 소진하는 구조다. 크레딧이 있을 때만 기준선 이상의 CPU 성능을 낼 수 있다. 기준선은 인스턴스 크기에 따라 다르다. 예를 들어 t3.micro는 vCPU 2개 기준으로 약 10%의 기준선을 가진다. 즉, 평균 CPU 사용률이 10% 이하일 때 크레딧이 적립되고, 10%를 넘으면 크레딧을 소진한다. 정확한 기준선 수치는 인스턴스 크기마다 다르므로 AWS 공식 문서 에서 확인해야 한다. 크레딧 시스템은 은행 계좌와 비슷하다. 조용할 때 저축하고, 바쁠 때 인출한다. 잔고가 바닥나면 더 이상 인출할 수 없다 — Standard 모드에서는. g...

RDS 인스턴스의 CPU와 커넥션 수가 치솟는데 슬로우 쿼리 로그를 열어보면 항상 같은 쿼리들이 반복해서 찍혀 있다. 상품 목록, 사용자 세션, 설정값처럼 데이터는 거의 바뀌지 않는데 매 요청마다 DB를 치고 있는 상황 — ElastiCache Redis를 캐시 레이어로 추가하는 것이 ElastiCache Redis 도입 의 가장 전형적인 시나리오다. TL;DR — ElastiCache Redis 도입 판단 기준 판단 항목 Redis 도입 적합 도입 불필요 동일 쿼리 반복 비율 전체 읽기의 30% 이상이 동일 키 대부분 유니크 쿼리 데이터 변경 주기 수 분 ~ 수 시간 단위 실시간 갱신 필수 RDS 병목 지점 읽기 쿼리 과부하 쓰기 병목, 스키마 문제 응답 지연 허용 범위 수십 ms 이내 목표 DB 직접 조회로 충분 캐시 일관성 요구 Eventually Consistent 허용 Strong Consistency 필수 ElastiCache Redis가 RDS 부하를 줄이는 원리 Redis는 인메모리 데이터 구조 저장소다. RDS가 디스크 I/O와 쿼리 파싱, 실행 계획 수립을 거쳐 결과를 반환하는 동안, Redis는 메모리에서 키-값을 직접 조회해 반환한다. 이 구조적 차이가 응답 속도 격차를 만든다. 캐시 히트 시 요청은 RDS에 도달하지 않는다. RDS 입장에서는 해당 쿼리가 존재하지 않는 것과 같다. 커넥션 풀 소모도 없고, 실행 계획 수립 비용도 없다. 트래픽이 몰리는 구간에서 RDS 커넥션 수가 안정적으로 유지되는 이유가 여기에 있다. graph LR App["애플리케이션 서버"] Redis["ElastiCache Redis"] RDS["Amazon RDS"] App -->|"① GE...