병가

눈 결막염 이슈로 인해 오늘은 병가를 작성하여 교육장에 가지 못하였다 그래도 집에서 일부 작업하면서 배운 점에 대해서 작성하겠다.

Learned

Terraform SG 모듈 간 순환참조(Cycle) 해결 — 규칙 분리 패턴

문제: Terraform에서 Security Group을 모듈로 관리할 때, 두 SG가 서로의 ID를 참조하면 의존성 그래프에 cycle이 생겨 Error: Cycle 발생 (plan조차 불가)

원래 방식 (inline 규칙): aws_security_group 리소스 안에 ingress/egress 블록을 직접 작성
→ SG 리소스 자체가 상대 SG에 의존 → A→B→A cycle

해결 (규칙 분리): SG 껍데기(aws_security_group)와 규칙(aws_security_group_rule)을 별도 리소스로 분리

• SG 껍데기: 서로 의존 없이 독립 생성
• 규칙 리소스: 양쪽 SG ID를 참조하지만 단방향 의존 → DAG 유지

핵심 원리: Terraform은 DAG(비순환 방향 그래프)로 실행 순서를 결정하므로, cycle을 깨려면 "상호 참조하는 리소스"를 "한쪽만 참조하는 별도 리소스"로 분리

Farmily 적용 케이스: ALB SG ↔ ECS SG, ECS SG ↔ RDS SG, ECS SG ↔ ElastiCache SG

HPA (Horizontal Pod Autoscaler) — K8s 수평 오토스케일링

Kubernetes에서 메트릭(CPU, Memory, custom metric)을 주기적으로(15초) 수집하고 현재값/목표값 비율로 Pod replica 수를 자동 조정하는 컨트롤러. ECS의 Service Auto Scaling에 대응. ECS→EKS 전환 시 Target Tracking → HPA로 마이그레이션됨.

• 관련: EKS, Kubernetes, Auto Scaling, Metrics Server, Prometheus

Custom Metric HPA 단계화 — behavior 기반 스케일링 속도 제어

HPA의 behavior 필드로 스케일 아웃/인 속도를 단계적으로 제한하는 전략. policies(한 번에 몇 개/몇 % 증감)와 stabilizationWindowSeconds(안정화 대기)로 구성. 급격한 스파이크 시 Pod 폭증 방지, thrashing(반복 스케일 인/아웃) 방지, 비용 예측 가능성 확보가 목적. ECS의 Step Scaling(메트릭 구간별 증감량)과 달리 "스케일링 속도"를 제어하는 방식.

• 관련: EKS, HPA, Kubernetes autoscaling/v2, Custom Metrics, KEDA

IMDSv2 강제 — EC2 메타데이터 서비스 보안 강화

EC2 메타데이터 접근 시 세션토큰(PUT→GET)을 필수화하는 설정(http_tokens = "required"). IMDSv1은 단순 GET이라 SSRF 공격으로 IAM Role 임시자격증명 탈취 가능(Capital One 사건). v2는 토큰 기반 + hop limit으로 SSRF 차단. ECS Fargate는 기본 v2만 지원, bastion 등 EC2 직접 관리 인스턴스에 적용 필요.

• 관련: EC2, IAM Role, SSRF, 메타데이터, 보안, Terraform metadata_options

SPOF (Single Point of Failure) — 단일 장애점

시스템에서 하나가 죽으면 전체가 멈추는 지점. HA(고가용성) 설계의 핵심은 SPOF 제거(이중화·분산). 예: DB 1대→Multi-AZ, EC2 1대→ALB+다중 태스크, NAT GW 단일AZ→AZ별 배치. Farmily에서 ECS desired=1이 현재 SPOF(태스크 1개 장애=서비스 다운).

• 관련: HA, Multi-AZ, DR, ECS, RDS, 고가용성 설계