<aside>

CloudWave · W05 · 4/5 · 예상 읽기 7분

</aside>

이 글에서 확인할 것

넷째 날에는 기능을 아는 것보다 실패했을 때의 순서가 중요했다. 브라우저에서 도메인이 열리지 않으면 애플리케이션부터 의심하기 쉽지만, 이름 해석과 경로, 대상 상태, 보안 규칙을 거꾸로 확인하면 문제를 더 빨리 좁힐 수 있다.

이름 해석부터 대상까지

Route 53의 public hosted zone은 인터넷에서 해석되는 레코드를 제공하고 private hosted zone은 연결된 VPC 안에서만 이름을 해석한다. A와 AAAA는 주소 유형이 다르고 CNAME은 다른 이름을 가리킨다. 따라서 레코드가 어느 영역에 있고, 질의하는 클라이언트가 그 영역에 접근할 수 있는지부터 확인한다.

DNS가 올바른 주소를 반환해도 라우팅 테이블에 목적지 경로가 없거나 보안 그룹이 요청을 막으면 연결은 실패한다. 대상이 로드 밸런서라면 리스너와 규칙, 대상 그룹의 health check까지 이어서 봐야 한다. 문제를 한 서비스의 결함으로 단정하기 전에 요청의 이동 경로를 그린다.

배포 단계의 경계

Jenkins나 CodeBuild 같은 빌드 도구는 소스 변경을 실행 가능한 산출물로 만드는 책임을 가진다. CodeDeploy는 컴퓨팅 자원에 배포하는 책임을 맡고, CodePipeline은 여러 단계를 연결하는 흐름을 구성한다. 각각의 역할을 섞으면 “빌드는 성공했는데 서비스가 안 열린다” 같은 상황에서 확인 대상이 흐려진다.

연결 오류 점검 순서

첫째, 사용한 이름과 DNS 응답이 의도한 대상인지 확인한다. 둘째, 대상의 라우팅과 공용·사설 범위를 본다. 셋째, 보안 그룹과 엔드포인트 정책을 확인한다. 넷째, 로드 밸런서 리스너와 health check를 본다. 다섯째, 배포 산출물과 프로세스 로그를 확인한다. 이 순서는 절대적인 법칙은 아니지만, 계층별로 가설을 세우는 데 유용하다.

실무에서는 어떻게 연결될까

Local과 Dev에서는 가상 도메인과 작은 테스트로 빠르게 검증할 수 있다. QA와 Staging에서는 운영과 비슷한 DNS·인증서·배포 순서를 확인하되 데이터와 권한은 분리한다. Production에서는 변경 승인, 롤백, 헬스체크, 감사 기록과 복구 목표가 함께 필요하다. 실습에서 한 번 성공한 배포가 운영 품질을 증명하는 것은 아니다.

헷갈렸던 점

DNS는 애플리케이션 서버가 아니며, 도메인 레코드가 있다고 네트워크 경로가 생기는 것도 아니다. 빌드 성공은 배포 성공과 다르고, 배포 성공은 사용자 경로 전체의 정상 동작과 다르다.

오늘의 한 줄 정리

연결 문제는 주소 하나가 아니라 이름 해석에서 프로세스까지의 경로를 계층별로 확인해야 풀린다.

공식 참고자료