[멱살잡고 DevOps] 7. DNS 설정 및 테스트 (트러블 슈팅🎯)

 

[Backend Dockerfile] 
1. backend Dockerfile 작성 🎆 
[AWS Front 설정] 
2. S3 버킷 & CloudFront 정적 웹 호스팅 활성화 
[AWS EC2 설정]
3. EC2 인스턴스 프로비저닝
4. EC2 환경 구성 🎆
[CI/CD] 
5. GitHub Actions CI/CD 구축 🎇
[테스트와 확장] <- 현 단계
6.DNS 설정 및 최초 배포 테스트
7. 배포환경 분리 (dev/prod)
[ECS와 Kubernetes 설정]
8. ECS 로 확장
9. 쿠베네티스 사용 설정 

 

 

---

1. 도메인 연결 & DNS 설정

• 기존 ACM 인증용 CNAME 레코드 삭제
• www 서브도메인을 CloudFront로 연결
• 왜 CNAME인가?
  • CloudFront의 서버 IP 주소는 성능 최적화를 위해 AWS에 의해 수시로 변경될 수 있음.
  • 고정된 IP를 가리키는 A 레코드 대신, 절대 바뀌지 않는 CloudFront의 도메인 이름을 가리키는 CNAME을 사용해야 IP가 바뀌어도 서비스가 중단되지 않음

 

💥 https:도메인 입력시 403 에러

 

✅ DNS <-> Cloudfront 사이에 도메인의 요청 응답 과정 

• DNS CNAME vs. CloudFront CNAME 등록
  • DNS 레벨에서 www.{도메인} → {클라우드프론트}.cloudfront.net 으로 매핑한 것은 “사용자가 올바른 서버(CloudFront)로 요청을 보내게” 할 뿐
  • 실제로 CloudFront가 해당 요청을 처리하려면 배포 설정에도 www.{도메인} 를 등록해 두고, 거기에 맞는 SSL 인증서를 연결해야
• Host 헤더와 SNI 인증서의 역할
  • 사용자가 https:// www.{도메인} 로 접속하면 브라우저는
    1. DNS 질의 → CloudFront IP로 연결
    2. TLS 연결 시 서버 이름 표시(SNI)로 www.{도메인} 를 전달
  • 이때 CloudFront는 (a) SNI로 받은 도메인이 배포에 등록된 CNAME 리스트에 있고, (b) 해당 도메인으로 발급된 인증서를 갖고 있어야만 정상적으로 SSL 핸드쉐이크를 마치고 콘텐츠를 전달
  • 둘 중 하나라도 없으면 “Bad request” 형태의 403

 

Cloudfront도 도메인에 연결된 TLS 인증서가 있나 확인해야함

 

 

🌐 해결방법

Cloudfront 에서 도메인 연결 및 ACM 인증서 연결

➡DNS도, CloudFront도 “이 도메인은 우리 배포가 서비스해도 괜찮다”를 서로 인증

 

 

💥 루트 도메인(allweneedfarm.store)에 도달할 때 HTTPS 인증서 적용안되는 문제 

 

 

• 대부분의 외부 DNS 서비스는 루트 도메인(이를 Apex 도메인)에 CNAME 설정을 허용하지 않는 기술적 제약
• 포워딩(Forwarding) 또는 리디렉션(Redirection)으로 문제를 해결할 수 있음 

✅ Apex 도메인과 Cloudfront

 

• APEX(루트) 도메인에 CNAME을 걸 수 없다
  • 루트 도메인 DNS가 여전히 “S3 웹사이트 엔드포인트”(HTTP 전용)이거나, 다른 HTTP 서버
• HTTP로 접속 → 경고 발생
  • HTTPS를 지원하지 않는 S3 웹사이트 엔드포인트로 가면 브라우저는 자동으로 HTTP로 연결하고, 그 결과 “보안 연결(HTTPS)이 사용되지 않았습니다” 라는 경고
  • 인증서는 CloudFront에서만 유효하기 때문에, CloudFront 를 거쳐서 HTTPS로 접속하지 않으면 SSL/TLS 인증이 일어나지 않음

🌐 해결방법

• AWS의 Route 53을 사용하면 ALIAS라는 특수 레코드를 통해 루트 도메인을 CloudFront로 직접 연결할 수 있어 포워딩이 필요없음 -> 과금됨
• Cloudflare DNS로 이전함 (네임서버 변경, 루트 도메인(@) 및 CNAME (WWW)  <-> 클라우드 프론트로 직접연결)

더이상 인증서 오류 뜨지 않음

 

 

 

 

2. 최초 배포 테스트

💥 api 요청시 서버 503 에러 

 

CloudFront가 EC2 API 서버에 연결조차 못 하고 있음

• EC2 보안 그룹 (문지기): "CloudFront로부터 오는 443번 포트 요청만 받겠다!" 라고 설정
• EC2 안의 Nginx (안내원): "나는 80번 포트로 오는 요청만 듣고 있다!" 라고 설정
• CloudFront (손님): EC2의 443번 포트의 문을 두드리지만, 안에서는 아무도 응답하지 않는 상황. 결국 연결에 실패하고 "서비스를 사용할 수 없습니다"라는 의미의 503 에러를 사용자에게 반환

 

✅ 분리된 두 개의 통신 구간

 

터널 1: 사용자 브라우저 ↔ CloudFront (공개적인 구간)

• 사용자는 https://도메인 으로 접속
• 이 통신은 HTTPS 프로토콜을 사용하며, 443번 포트로 이루어짐
• SSL 인증서는 CloudFront에 설치되어 있으며, 이 구간의 암호화를 책임

 

터널 2: CloudFront ↔ EC2 오리진 서버 (AWS 내부망 구간)

• CloudFront는 사용자의 요청을 받아 EC2로 전달해야
• 이때 CloudFront는 EC2에게 있어 하나의 *클라이언트'처럼 행동

💠 '터널 1'이 HTTPS라고 해서 '터널 2'까지 반드시 HTTPS일 필요는 없다

💠 오히려 CloudFront가 SSL 처리를 모두 담당하게 하고, AWS 내부망으로 이루어지는 '터널 2'는 암호화되지 않은 HTTP 통신을 사용하도록 구성하는 것이 더 효율적이고 일반적인 패턴

 

🌐 해결방법

Cloudfront origin 수정

ㄴ이 원본(EC2)과 통신할 때는 무조건 암호화되지 않은 HTTP(80번 포트)를 사용해라

 

EC2 보안그룹 수정

 

ㄴ전 세계의 AWS CloudFront 엣지 서버 IP : 포트번호80 에서 오는 트래픽만 허용

 

💥 api 요청 운영 개발 분리 

• .env 파일 생성 (mongo 및 port 번호 변수화)
• 개발 모드
  • npm start(또는 yarn start)를 실행할 때
  • 내부적으로 NODE_ENV=development가 세팅되고
  • .env.development → .env 순으로 환경변수를 로드
• 운영(빌드) 모드
  • npm run build(또는 yarn build)를 실행할 때
  • 내부적으로 NODE_ENV=production이 세팅되고
  • .env.production → .env 순으로 환경변수를 로드
  • 이때 번들링된 결과물이 build/ 폴더에 들어가고, 실제 서버(예: Nginx)가 여기서 정적 파일을 서빙

 

 

 

3. 모니터링 및 로깅

EC2 CPU 사용량과 log를 모니터링