ASG + 스팟 인스턴스 + 사설 DNS 자동등록 잘 안쓰이는이유

 

구성을 해보는데 asg + spot instance 구성은 그렇게 어렵지 않았습니다. 하지만  private DNS 를 ec2 에 연결하면서부터 굉장히 복잡하게 구성이 됩니다. dns cache, spot instance의 부족으로 인하여 다른 인스턴스가 생성되며 다른 subnet 에 생성이 되어 제어하기가 굉장히 까다롭더군요. 생각해보니 대부분의 개발환경에서는 on-demand를 사용하던데 그이유를 좀더 자세히 알아보고자 포스팅합니다. 

 

 

왜 잘 안 쓰일까?

1) 스팟 특성과 개발 생산성의 충돌

• 예고형 중단(2분 전 통지): 개발 중/테스트 중에 인스턴스가 종료되면 워크플로우가 끊깁니다.
• 가용 용량 변동: 특정 타입/AZ에 스팟 용량이 모자라 스케일-아웃이 실패할 수 있음. “개발=빠른 반복”과 상충.
• 비용 대비 복잡도: 개발환경에서 트래픽이 낮으면 온디맨드 대비 절감폭이 크지 않은데, 스팟 인터럽트 대응 오토메이션(AMI 베이킹, 부팅 스크립트, 캐시/아티팩트 프리페치 등) 비용이 더 큼.

2) 인스턴스별 DNS 등록은 관리 오버헤드가 큼

• 자동등록이 내장 기능이 아님: Route 53에 인스턴스 생명주기 따라 A/AAAA 레코드를 자동으로 올바르게 등록/삭제하려면
  ASG 라이프사이클 훅 + Lambda/Step Functions + IAM 권한 + 예외처리(재시도/충돌)까지 직접 짜야 합니다.
• 정리(Scale-in) 문제가 빈번: 다운된 인스턴스의 레코드가 고아(Orphan) 로 남아 잘못된 IP를 가리키는 일 발생 → 장애성 이슈.
• 헬스체크 부재: 단순 A레코드는 인스턴스 애플리케이션 헬스와 연동되지 않습니다. 프로세스는 죽었는데 DNS는 살아있게 됨.

3) DNS 특성(캐시/전파) 때문에 서비스 디스커버리로 부적절

• TTL/캐시 지연: 레코드가 바뀌어도 클라이언트/OS/JVM이 TTL 동안 캐시 → 느린 전환, 스플릿 브레인.
• 클라이언트 라이브러리 이슈: 일부 런타임/프레임워크는 DNS를 길게 캐시하거나 재조회가 약함(예: 오래된 JVM 기본 동작).
• 네거티브 캐시: 일시적으로 레코드가 비어 있던 시간의 부정 응답이 캐시되어 연결 실패가 길어질 수 있음.

4) 더 나은 대안이 이미 있음

• ALB/NLB + Target Group: 인스턴스 헬스체크, 드레이닝, 가중치 없는 라운드로빈 등 표준 수명주기 관리 지원.
• Cloud Map(서비스 디스커버리): 헬스체크/오토디스커버리와 통합. ECS/EKS와 연계 용이.
• EKS(CoreDNS): 파드/서비스 단위의 디스커버리. 인스턴스가 아닌 서비스 단위 이름을 쓰는 게 관례.
• SSM Session Manager: SSH/고정 사설 DNS 없이도 접속·운영 가능(감사/보안↑).

5) 상태 저장/인증·네트워크 연계 이슈

• 상태 저장 워크로드(예: Kafka, DB, 큐): 브로커/노드 식별이 IP 기반이면 재스케줄 시 브로커 ID·볼륨 매핑·ISR 재구성 이슈. 스팟과 상극.
• 보안 그룹/허용 목록: 외부 SaaS/DB에서 IP 화이트리스트가 필요하면, 스팟+DNS 전환은 잦은 변경으로 운영 피로도↑.
• 부팅 시크릿/부트스트랩: 인스턴스 교체가 잦으면 시크릿 주입, 에이전트 등록, 라이선스 활성화 등 초기화 실패 리스크↑.

---

추천 패턴 (현실적으로 잘 굴러가는 설계)

A. “인스턴스 단위 DNS” 대신 “서비스 단위 엔드포인트”

• 내부 트래픽: NLB/ALB (internal) → Target Group에 ASG 인스턴스를 자동 등록
  • 헬스체크·드레이닝·무중단 롤링이 내장.
• 서비스 디스커버리:
  • EKS 사용 시 svc.namespace.svc.cluster.local
  • VM 기반이면 Cloud Map(네임스페이스+서비스) 사용.

B. 스팟 사용 시 안정성 가이드

• ASG: capacity-optimized 전략 + 여러 인스턴스 패밀리/사이즈 풀 구성(분산)
• 인터럽트 훅(2분)으로 프리스톱 핸들러:
  • ALB 드레이닝, 큐 소비 중단, 세션 종료, 메트릭 플러시
• 이미지 베이킹(AMI) + 부팅시간 최적화: 아티팩트/패키지 미리 포함, 유저데이터 idempotent
• EBS 재사용 필요 시: 루트/데이터 볼륨 분리, 태깅·어태치 자동화(단, 복잡도↑ → dev에 과한 경우 많음)

C. 개발환경이라면 더 단순하게

• 트래픽 낮고 가용성 부담 적으면:
  • 온디맨드 1~2대 + 스케줄러(Instance Scheduler/ASG Scheduled Actions) 로 야간 중지 → 비용↓/안정성↑
• 컨테이너 기반이라면:
  • EKS + Karpenter/Cluster-Autoscaler + Spot(노드 레벨) → 애플리케이션은 서비스 DNS만 사용.
  • 노드가 바뀌어도 파드 서비스 엔드포인트는 안정적.

---

“그래도 사설 DNS 자동등록”을 꼭 쓰고 싶다면

최소 요구 설계

1. ASG 라이프사이클 훅(Launching/Terminating)
2. Lambda(Route 53 API로 A/AAAA UPSERT/DELETE)
3. 헬스 기반 정합성: EC2 헬스가 아니라 애플리케이션 헬스 신호로만 등록
4. 짧은 TTL(5–15s) + 클라이언트 DNS 재조회 보장(런타임 설정 확인)
5. 오류 내성: 재시도/멱등 처리, 중복 레코드 정리, 고아 레코드 스캐빈징 주기 작업

현실적으로 ALB/NLB가 이 모든 관리 로직을 이미 해줍니다.
그래서 “인스턴스 개별 DNS”는 특수 케이스(예: 브로커 개별 접속이 필요한 미들웨어) 말고는 지양합니다.

---

언제 이 구성이 합리적일까?

• 브로커 고정 식별이 꼭 필요한 개발 실험(Kafka/ZooKeeper 레거시, 모놀리식 WAS의 세션 고정 등)
• 네트워크 어플라이언스 테스트(프록시/IDS/커스텀 에이전트)
• 단기간 PoC로 Route 53 오토메이션 자체를 검증하고 싶을 때

대부분의 일반 웹/API 개발환경에서는 ALB/NLB 또는 EKS 서비스가 더 간단하고 튼튼합니다.

---

한 줄 정리

• 인스턴스별 사설 DNS 자동등록은 “되지만, 굳이 안 하는” 길입니다.
  => 하면 할수있지만 구성하는데 정말 까다롭고 구성하더라도 조금만 틀어져도 구성이 굉장히 힘들어집니다.
• 운영 난이도·오류 가능성·DNS 캐시 문제를 감안하면, ALB/NLB/Cloud Map/EKS Service가 표준 해법입니다.
• 스팟은 노드 레벨에서 흡수(오토스케일러/카펜터)하고, 애플리케이션은 서비스 단위 엔드포인트만 바라보게 하세요.