SW BBANG K

EC2 인스턴스를 며칠에 걸쳐 완벽하게 세팅했다. 패키지 설치, 환경 변수 설정, 애플리케이션 배포까지 끝냈는데, 이걸 그대로 복제하거나 Auto Scaling에 쓰려면 어떻게 해야 할까? Amazon Machine Image(AMI) 생성이 그 답이다. 이 글은 AMI의 동작 원리부터 실제 생성 절차, 운영 중 자주 마주치는 함정까지 다룬다. TL;DR — AMI 생성 핵심 요약 단계 핵심 내용 1. AMI 개념 이해 EBS 스냅샷 + 루트 디바이스 매핑 + 메타데이터의 조합 2. 인스턴스 준비 임시 파일 정리, 민감 정보 제거, 로그 초기화 3. AMI 생성 콘솔 또는 CLI로 create-image 실행 4. 상태 확인 describe-images 로 available 상태 대기 5. 검증 및 활용 테스트 인스턴스 실행 후 Launch Template 또는 Auto Scaling에 연결 AMI가 실제로 무엇인지 — 동작 원리 AMI를 '인스턴스 복사본'이라고 단순하게 생각하면 나중에 반드시 문제가 생긴다. 정확히는 EBS 스냅샷 집합 + 블록 디바이스 매핑 + 부팅 권한 메타데이터 로 구성된 리소스다. 인스턴스 자체를 저장하는 게 아니라, 그 인스턴스를 재현하는 데 필요한 청사진을 저장한다. EBS 기반 인스턴스(현재 대부분의 인스턴스 유형)에서 AMI를 생성하면 다음이 일어난다: 루트 볼륨과 추가 EBS 볼륨 각각에 대해 EBS 스냅샷이 생성된다. AMI는 이 스냅샷들을 참조하는 블록 디바이스 매핑을 포함한다. AMI를 이용해 새 인스턴스를 시작하면, 해당 스냅샷에서 새 EBS 볼륨이 생성되어 인스턴스에 연결된다. AMI를 삭제(deregister)해도 연결된 EBS 스냅샷은 자동으로 삭제되지 않는다. 스냅샷은 별도로 수동 삭제해야 한다. 이걸 모...

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를 자동 ...