SW BBANG K

ASG가 멀쩡히 응답하는 인스턴스를 계속 교체하고 있다면, 헬스 체크 타입 설정을 의심해야 한다. 'EC2' 타입은 인스턴스 OS가 살아있는지만 확인하고, 실제 애플리케이션이 HTTP 200을 반환하는지는 전혀 모른다 — 이 간극이 예상치 못한 인스턴스 교체 루프의 원인이 되는 경우가 많다. TL;DR: Auto Scaling Group 헬스 체크 타입 비교 항목 EC2 헬스 체크 ELB 헬스 체크 확인 대상 인스턴스 상태 (하이퍼바이저 레벨) 애플리케이션 응답 (HTTP/TCP) 기본값 예 (ASG 생성 시 기본) 아니오 (명시적 활성화 필요) Unhealthy 판정 조건 stopped, terminated, stopping, shutting-down ELB 타겟 그룹이 unhealthy로 표시 적합한 상황 인스턴스 장애 복구만 필요한 경우 앱 레벨 장애 자동 복구가 필요한 경우 오탐 위험 낮음 ELB 헬스 체크 설정에 따라 높을 수 있음 Auto Scaling Group 헬스 체크가 동작하는 방식 ASG는 주기적으로 각 인스턴스의 상태를 평가하고, unhealthy로 판정된 인스턴스를 종료한 뒤 새 인스턴스로 교체한다. 이 판정의 기준이 바로 헬스 체크 타입이다. EC2 헬스 체크 는 EC2 서비스 자체가 보고하는 인스턴스 상태(instance status)를 기반으로 한다. 인스턴스가 running 상태이고 시스템 상태 체크를 통과하면 healthy로 간주한다. 즉, Nginx가 죽어있어도, 앱 프로세스가 OOM으로 종료되어도 — OS가 살아있으면 ASG는 아무 조치를 취하지 않는다. ELB 헬스 체크 를 활성화하면 ASG는 연결된 로드 밸런서(ALB/NLB)의 타겟 그룹이 해당 인스턴스를 healthy로 표시하는지를 추가로 확인한다. ELB가 unhealthy로 표시하...

ALB를 새로 프로비저닝하고 도메인을 연결하려는 순간, 대부분의 엔지니어는 CNAME 레코드를 먼저 떠올린다. 그런데 example.com 자체(zone apex)를 ALB에 연결하려는 순간 CNAME은 동작하지 않는다 — DNS 표준이 이를 금지하기 때문이다. Route 53 Alias 레코드는 이 문제를 해결하기 위해 설계된 AWS 전용 확장이며, 단순한 편의 기능이 아니라 운영 비용과 장애 내성에 직접 영향을 미친다. TL;DR — Route 53 Alias vs CNAME 핵심 비교 항목 CNAME Route 53 Alias Zone Apex 사용 가능 여부 ❌ 불가 (RFC 1912) ✅ 가능 쿼리 과금 쿼리당 과금 AWS 리소스 대상 시 무료 DNS 응답 내용 CNAME 체인 반환 A/AAAA 레코드로 직접 응답 대상 리소스 상태 연동 없음 ALB 등 AWS 리소스와 연동 TTL 설정 직접 설정 Route 53이 자동 관리 사용 가능 대상 임의 호스트명 AWS 리소스 한정 DNS 동작 원리: CNAME 체인과 Alias 플래팅 CNAME 레코드는 한 호스트명을 다른 호스트명으로 위임한다. 클라이언트가 www.example.com 을 조회하면 리졸버는 CNAME 대상인 ALB의 DNS 이름을 다시 조회해야 한다. 이 추가 조회가 CNAME 체인이다. Zone apex( example.com )에 CNAME을 설정할 수 없는 이유는 RFC 1912에 명시되어 있다 — zone apex에는 SOA, NS 레코드가 반드시 공존해야 하는데, CNAME은 같은 이름에 다른 레코드가 존재하는 것을 허용하지 않는다. Route 53 Alias 레코드는 DNS 표준 레코드 타입이 아니다. Route 53 네임서버 내부에서 처리되는 확장으로, 쿼리 시점에 대상 리소스의 현재 IP 주소를 조...

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