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...

SNS 토픽을 만들고 이메일 구독까지 등록했는데 알림이 하나도 안 온다. 가장 먼저 의심해야 할 건 코드도 IAM도 아니다 — 구독 확인(Subscription Confirmation) 이메일을 클릭했는지 여부다. 이 단계를 건너뛰면 SNS는 메시지를 발행해도 해당 엔드포인트로 전달하지 않는다. TL;DR — SNS 이메일 알림 미수신 핵심 체크리스트 점검 항목 확인 방법 조치 구독 상태가 'PendingConfirmation' AWS 콘솔 또는 CLI로 구독 목록 조회 확인 이메일의 링크 클릭 또는 재발송 확인 이메일이 스팸함에 있음 수신 이메일함 스팸 폴더 확인 스팸 해제 후 링크 클릭 토픽에 메시지가 실제로 발행되지 않음 CloudWatch 지표 NumberOfMessagesSent 확인 Publish API 또는 콘솔에서 테스트 메시지 발행 구독 필터 정책이 메시지를 차단 구독 속성의 FilterPolicy 확인 필터 정책 제거 또는 메시지 속성 추가 잘못된 이메일 주소로 구독 등록 구독 엔드포인트 값 확인 구독 삭제 후 올바른 주소로 재등록 SNS 이메일 구독의 동작 원리 SNS 이메일 알림이 왜 안 오는지 이해하려면 구독 생성부터 메시지 전달까지의 흐름을 알아야 한다. SNS는 이메일 엔드포인트를 등록할 때 즉시 활성화하지 않는다. 반드시 수신자가 확인 이메일의 링크를 클릭해야 구독이 'Confirmed' 상태로 전환된다. 이 설계는 동의 없이 타인의 이메일로 메시지를 보내는 것을 방지하기 위한 것이다. sequenceDiagram participant User as 사용자 participant SNS as Amazon SNS participant Email as 이메일 수신함 User->>SNS: subscr...

Lambda 함수가 3초 만에 끊기는데 실제 작업은 10초가 필요한 상황 — 처음 마주치면 당황스럽지만, 원인은 단순하다. Lambda의 기본 타임아웃이 3초로 설정되어 있고, 이 값을 명시적으로 늘리지 않으면 함수는 작업 완료 여부와 무관하게 강제 종료된다. 이 글에서는 Lambda 타임아웃 설정 위치, 최대 한도, 그리고 단순히 값을 올리는 것 이상으로 놓치기 쉬운 실전 주의사항을 정리한다. TL;DR — Lambda 타임아웃 핵심 요약 항목 내용 기본 타임아웃 3초 최대 타임아웃 900초 (15분) 설정 단위 함수 단위 (버전/별칭별 독립 설정 불가) 타임아웃 측정 범위 전체 호출 시간 — 콜드 스타트 init 단계 포함 설정 방법 콘솔, AWS CLI, IaC (SAM/CDK/Terraform) 연동 서비스 타임아웃 API Gateway(29초), ALB(60초) 등 별도 제한 존재 Lambda 타임아웃이 동작하는 방식 Lambda 타임아웃은 함수 호출이 시작된 시점부터 카운트된다. 중요한 점은 타임아웃이 핸들러 실행 시간만이 아닌 전체 호출 시간에 적용된다 는 것이다. 콜드 스타트가 발생하면 런타임 초기화(init) 단계도 이 시간에 포함된다. 즉, init에 2초가 걸리고 핸들러 로직에 9초가 필요한 함수라면, 타임아웃을 10초로 설정해도 강제 종료될 수 있다. 타임아웃이 초과되면 Lambda는 Task timed out after X.XX seconds 메시지와 함께 호출을 종료하고, 호출자에게 오류를 반환한다. 함수 내부에서 try/catch로 잡을 수 없다 — 런타임 레벨에서 강제 중단되기 때문이다. graph TD A["Lambda 호출 시작 타임아웃 카운터 시작"] --> B{"콜드 스타트?"}; B ...

EC2 인스턴스를 운영하다 보면 CloudWatch 콘솔에서 CPU는 보이는데 메모리가 없다는 걸 처음 마주치는 순간이 있다. 알람을 걸려고 했더니 지표 자체가 없고, 인스턴스가 OOM으로 죽었는데 CloudWatch에는 아무 흔적이 없다. EC2 메모리 사용률 은 기본 CloudWatch 지표에 포함되지 않으며, 이를 수집하려면 CloudWatch Agent를 직접 설치해야 한다. TL;DR — EC2 메모리 모니터링 핵심 요약 항목 기본 CloudWatch CloudWatch Agent 설치 후 CPU 사용률 ✅ 자동 수집 ✅ 자동 수집 네트워크 I/O ✅ 자동 수집 ✅ 자동 수집 디스크 I/O (EBS 바이트) ✅ 자동 수집 ✅ 자동 수집 메모리 사용률 (RAM) ❌ 수집 불가 ✅ 수집 가능 디스크 공간 사용률 (파일시스템) ❌ 수집 불가 ✅ 수집 가능 프로세스별 메모리 ❌ 수집 불가 ✅ 수집 가능 (procstat 플러그인) 왜 EC2 메모리 사용률은 기본으로 보이지 않는가 CloudWatch가 기본으로 수집하는 지표는 AWS 하이퍼바이저 계층에서 관측 가능한 것들이다. CPU 사이클, 네트워크 패킷, EBS I/O 바이트 — 이것들은 인스턴스 외부에서 측정할 수 있다. 반면 OS 내부의 메모리 할당 상태, 파일시스템 사용량, 프로세스 목록은 게스트 OS 안에서만 볼 수 있다. AWS는 EC2 인스턴스 내부 OS에 직접 접근하지 않는다. 이건 보안 모델의 일부이기도 하고, 공유 책임 모델(Shared Responsibility Model)의 경계이기도 하다. 게스트 OS 레이어는 고객 책임 영역이고, AWS는 그 안을 들여다보지 않는다. 결과적으로 메모리 사용률을 수집하려면 인스턴스 안에서 직접 데이터를 밀어내는 에이전트가 필요하다. EBS 디스크 I/O 바이트는 하이퍼바이...

AWS 계정을 처음 만들고 프리 티어로 실습하다가 월말에 예상치 못한 청구서를 받는 경우가 생각보다 많다. EC2 인스턴스를 종료하지 않고 잠들었거나, 실수로 프리 티어 한도를 초과하는 서비스를 켜둔 경우다. CloudWatch 결제 알람(Billing Alarm) 을 미리 설정해두면 요금이 임계값을 넘는 순간 이메일로 알림을 받을 수 있어, 프리 티어 초과를 조기에 차단할 수 있다. TL;DR — CloudWatch 결제 알람 설정 요약 단계 작업 핵심 포인트 1 결제 알람 활성화 루트 계정 또는 결제 권한 보유 IAM 사용자로 Billing 콘솔에서 활성화 필요 2 SNS 주제 생성 us-east-1 리전에서만 생성 — 결제 지표는 이 리전에만 존재 3 이메일 구독 추가 및 확인 구독 확인 이메일의 링크를 클릭해야 알림이 실제로 전송됨 4 CloudWatch 알람 생성 EstimatedCharges 지표, USD 5 임계값 설정 5 동작 확인 알람 상태 및 SNS 구독 상태 검증 결제 알람이 작동하는 방식 — 설정 전에 반드시 알아야 할 구조 CloudWatch 결제 알람은 일반 CloudWatch 알람과 동일한 메커니즘으로 동작하지만, 몇 가지 중요한 제약이 있다. AWS/Billing 네임스페이스의 EstimatedCharges 지표는 us-east-1 리전에서만 게시 된다. 다른 리전에서 알람을 만들려고 해도 이 지표를 찾을 수 없다. 또한 이 지표는 약 6시간마다 업데이트되므로, 실시간 요금 감시 도구가 아니라 누적 요금 경보 도구로 이해해야 한다. 알람이 트리거되면 CloudWatch는 SNS(Simple Notification Service) 주제로 메시지를 발행하고, SNS는 구독된 이메일 주소로 알림을 전달한다. 이 흐름에서 SNS 구독 확인이 완료되지 않으면 알람이 울려...

ALB 액세스 로그에 502가 쏟아지는데 타겟 그룹 콘솔에는 인스턴스가 멀쩡히 Healthy 로 표시되어 있다. 이 상황이 혼란스러운 이유는 ALB의 헬스체크와 실제 요청 처리가 완전히 별개의 레이어에서 동작하기 때문이다. 헬스체크는 통과했지만 실제 HTTP 응답이 ALB의 기대를 벗어나는 순간 502가 발생한다. TL;DR — ALB 502 원인 분류 원인 카테고리 증상 핵심 확인 지점 HTTP 프로토콜 위반 모든 요청에서 502 발생 응답 헤더 형식, Content-Length 불일치 Keep-Alive 타임아웃 불일치 간헐적 502, 로드 증가 시 악화 ALB idle timeout vs 앱 서버 keep-alive timeout 응답 헤더 크기 초과 특정 요청에서만 502 응답 헤더 총 크기 타겟 연결 거부/타임아웃 target_status_code가 비어 있음 보안 그룹, 포트 바인딩 청크 인코딩 오류 대용량 응답에서 502 Transfer-Encoding 헤더 처리 ALB 502가 발생하는 메커니즘 ALB는 클라이언트와 타겟 사이에서 HTTP 레이어 7 프록시로 동작한다. 타겟이 Healthy 상태라는 것은 ALB가 헬스체크 엔드포인트에서 정상 응답을 받았다는 의미일 뿐, 실제 애플리케이션 요청에 대한 응답이 올바르다는 보장이 아니다. ALB는 타겟으로부터 받은 HTTP 응답이 RFC를 위반하거나, 연결이 예기치 않게 끊기거나, 응답 자체를 받지 못하면 클라이언트에게 502를 반환한다. sequenceDiagram participant C as 클라이언트 participant ALB as ALB participant TG as 타겟 인스턴스 C->>ALB: HTTP 요청 ALB->>TG: 요청 전달 (Keep-Alive 연...