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로 표시하...

DynamoDB 테이블을 처음 생성할 때 가장 먼저 마주치는 질문이 바로 용량 모드 선택이다. 트래픽 패턴이 불분명한 초기 단계에서 Provisioned를 잘못 설정하면 스로틀링으로 요청이 거부되고, On-Demand를 무심코 유지하다 보면 예상치 못한 청구서를 받게 된다. 이 글은 DynamoDB 용량 모드 의 내부 동작 원리부터 실전 전환 판단 기준까지, 운영 경험을 바탕으로 정리한다. TL;DR — 한눈에 보는 선택 기준 상황 권장 모드 핵심 이유 트래픽 패턴 미확인, 초기 서비스 On-Demand 스로틀링 없이 자동 스케일, 용량 예측 불필요 트래픽이 예측 가능하고 일정함 Provisioned + Auto Scaling 단위 비용이 낮고 비용 상한 제어 가능 급격한 스파이크 + 평시 트래픽 낮음 On-Demand 피크 대비 Provisioned 과잉 프로비저닝 방지 높은 베이스라인 + 예측 가능한 피크 Provisioned + Auto Scaling Reserved Capacity와 조합 시 비용 최적화 DynamoDB 용량 모드의 내부 동작 원리 두 모드를 단순히 '자동 vs 수동'으로 이해하면 운영 중 반드시 실수가 생긴다. 각 모드가 내부적으로 어떻게 처리량을 관리하는지 먼저 파악해야 한다. Provisioned 모드 Provisioned 모드에서는 RCU(Read Capacity Unit)와 WCU(Write Capacity Unit)를 명시적으로 설정한다. DynamoDB는 설정된 용량을 파티션 단위로 분배하며, 특정 파티션에 요청이 집중되면 해당 파티션의 할당량이 소진되어 ProvisionedThroughputExceededException 이 발생한다. Auto Scaling을 활성화하면 CloudWatch 지표를 기반으로 목표 사용률에 맞게 RCU/WCU를 자동 ...