웹 페이지 도메인 주소 적용하기
내도메인 한국에서 받은 도메인 주소로 프로젝트 도메인 주소 적용하기로했다!
굳이 유로 도메인을 사용할 필요가 없다고 생각해서 무료 도메인 주소 사이트인 [내도메인.한국]을 사용했고,
cloudfront를 사용해서 s3와 직접적인 연결은 막았지만, 접속 주소가
https://d12345enizpvfx6cl4321.cloudfront.net/ (진짜 cloudfront 배포 도메인 이름이 아니다. )
이런식으로 구성되어있어서 기억하기 쉽고 사용하기 편리하여 이름을 붙여관리하기위해 도메인 주소를 적용했다.
내도메인한국에서 DNS를 발급 받은 뒤, SSL인증서를 ACM(Amazon Certificate Manager)을 통해 등록해서 사용하는 방법을 이용해서 적용시켰다.
reference
위 블로그를 참고해서 cloudfront에 대체 도메인을 적용시켰다.
나는 위 블로그를 따라 route53을 추가로 사용해줬다.
route53을 사용하면 한달에 600원 정도 과금되는데, 왜 사용했냐!
-
속도가 빠른 유료 DNS기반
보통 한국에서 무료로 받을 수 있는 네임서버를 4개이하로 고정되어있는데, 호스팅사에서 트래픽이 증가하면 네임서버 연결 단에서 먼저 시간지체(Latency)
가 일어나기 시작한다. 근데 route53은 해당 지역 리전의 가용 영역에서 작동되는 수천대의 네임서버에서 서버 로드가 가장 작은 무작위 순서를 정해 할당하므로 네임서버의 동작이 엄청 빠르다.
정리하면, 비용을 지불해서 빠른 속도를 보장받는것이다. -
지연시간 기반 연결 (Latency Based Routing)
route53에서는 도메인 하나에 각 지역별로 가장 빠른 곳으로 연결해주는 서비스를 지원한다. ex_ 사용자의 웹사이트 접속지점이 대한민국이면 서울 리전에 있는 네임서버로 연결하고, LA에서 접속하면 캘리포니아 리전으로 연결해준다.
이렇게 접속 지역에 맞춰서 접속 속도를 최상으로 유지할 수 있게 해준다. -
Health check와 Fail Over
route53에서 자체적으로 Health check 기능을 가지고있다. 하나의 DNS 명에 대해서 여러개의 IP주소를 반환할 수 있는데, 해당 IP의 서버 상태를 체크해서 장애상태일 경우에 네임서버의 리스에서 제외하고 있다가 장애가 복구되면 다시 리스트에 추가하는 형태로 웹 서버의 션 다운 타임을 최소화하고 웹 반응 속도를 최대로할 수 있는 기반 기술을 제공한다. -
CDN 기능 추가 사용 시 속도 증가
Route53와 Cloudfront의 경우 해당 지역의 동일한 가용 영역 내에서는 타 CDN 보다 훨씬 빠르게 동작할 수 있다.
refernce1
refernce2
위 2개 레퍼런스를 참고해서 route53의 장점을 확인했고, 우리 프로젝트는 사용자가 급격히 많거나, 여러 리전에서 접속할 가능성이 정말 매우 적었지만 cloudfront도 적용되어있었고 접속속도가 최상인 환경으로 구성해보고싶었기에 route 53을 적용했다.
EC2 서버 도메인 주소 적용하기 (Https 적용)
cloudfront에 대체 도메인을 설정해주니 이렇게 아무런 데이터도 불러오지못했다..
postman으로 확인해보면 서버는 정상적으로 켜져있는 상태였고,
개발자도구로 로그를 확인해보니,
main.c29cda05.js:2 Mixed Content: The page at 'https://celebee.kro.kr/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://{ec2 서버 IP 주소}:8080/boards'. This request has been blocked; the content must be served over HTTPS.Mixed Content에러라고 알려주고있었다..
이제 웹페이지는 ssl인증서도 적용해 도메인 주소를 적용한 https인데 프론트에서 요청을 보내는 서버 주소는 http여서 생긴 이슈였다.
해결방법은 이제 서버도 Https를 적용하고 서버 도메인주소를 설정하는 것!
ssl을 발급할 때 와일드카드를 적용해서 하위도메인 인증을 한번에 받아놓으려고 *.celebee.kro.kr 로 받았기때문에, {서버}.celebee.kro.kr을 서버 주소로하고 ec2와 연결시켰다. (route53이용)
그리고 로드밸런서를 등록해줬고, 로드 밸런서에서 리스너를 통해 Http로 접근할 경우 자동으로 Https로 리디렉션하게 설정해줬다.
reference1
reference2
reference3
서버 도메인 주소로도 접근이 되고, http -> https로 리다이렉션도 잘 되는데
Mixed Content에러는 해결되지 않았다...
프론트에서 api주소를 아예 서버 도메인 주소로 바꿔주어도 해결되지 않았고,
{서버}.celebee.kro.kr/boards:1 Failed to load resource: net::ERR_CERT_COMMON_NAME_INVALID이런 로그를 개발자모드로 확인했다.
구글링과 GPT의 힘을 빌려 찾아보니 SSL/TLS 인증서 문제라고 확인되었다.
(인증서의 "Common Name" 또는 "Subject Alternative Name" (SAN) 필드가 현재 접속하려는 도메인과 일치하지 않을 때 발생한다고하는데, 도메인도 올바르고 Https을 통해 연결하려고도 했고 캐시랑 쿠키를 사용해도 해결되지 않고 같은 에러를 내뱉었기 때문이다...)
근데 나는 ssl인증을 ACM 통해서 받았는데?! 와일드카드 설정도 제대로 해줬는데!!! ACM 통해서 받은 같은 인증서인데 www. 으로 접속하는건 문제없고 {서버}. 로 접속하는게 문제 있을리 있나...? 하면서 진짜 몇시간을 구글에서 헤어나오지 못했다.. 이때가 새벽 4-5여서 GPT밖에 물어볼 사람이 없었다..
또 열심히 구글링을 하다가 https://okky.kr/questions/1363563
글에서
ACM 은 AWS 서비스내에서만 동작합니다.
라는 글을 보았다.
다른 팀원이 메인 도메인 주소(celebee.kro.kr)를 발급받고 ec2서버에 HTTPS를 적용시키기만 했던걸, 메인 도메인 주소를 클라 도메인 주소로 사용하기위해 바꾸고 있는 과정이었는데 이때 ssl 인증서를 ec2로 옮기는걸 도와줬던 기억이 났다. 이때 메인 도메인이랑 www. 으로 지정해서 ssl발급받았던거같은데 혹시 이래서 www.은 되는데 다른 하위도메인이 인증서 문제가 나오는건가? 싶었다.
ssl 인증서 정보 확인 사이트
에서 메인 도메인과 하위 도메인들에 인증서가 있는지 확인해봤는데, {서버}만 없어서 애가 인증서가 없는게 확실해졌다..
그래서 Let's Encrypt를 이용해서 {서버}의 ssl 인증서를 발급받았다.
인증서 발급받고 Nginx설정 파일에서도 {서버} 하위 도메인을 추가해주고
Ec2 재부팅한뒤 접속하니까 정상적으로 데이터를 불러왔다..
진짜 감격... 새벽2시쯤되니까 오기생겨서 밤새워버렸고 오전 11시에 마무리지을 수 있었다.. 새벽이라서 왜이러는지 멘토님한테 질문할 수도 없었고,,그래서 정말 시간과 체력을 다 쏟아부어버리는 비효율적인 방법이었지만
이 쾌감.. 중독된걸까.. 도메인 주소로 데이터 불러올 때 진짜 짜릿했다
이렇게 도메인 주소, 로드 밸런싱, route53까지 적용해서 프로젝트를 배포환경 설정을 마무리했다.
구글링과 GPT로만 공부해서 적용하다보니, 이유도 명확하지 않은데 하라고하길래 적용하기도 했고 적용한 기능들이 정확히 어떻게 작동하는지 모르겠는 부분이 많다. 인프라 관련된 책과 강의를 더 찾아서 듣고 공부해서 지금 프로젝트가 더 안정적인 환경을 가질 수 있도록 업데이트해야겠다.
reference
https://studyforus.tistory.com/246
https://hyeon9mak.github.io/change-cloudfront-domain-name/
https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/route-53-concepts.html
https://velog.io/@hahaha/AWS-Route53%EB%9E%80
https://bitkunst.tistory.com/entry/AWS-EC2-%EB%B0%B0%ED%8F%AC-5-Route-53-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0-HTTPS
https://cl8d.tistory.com/97
https://steady-coding.tistory.com/628
https://tre2man.tistory.com/266
https://aws.amazon.com/ko/what-is/load-balancing/
https://yoo11052.tistory.com/63
https://gist.github.com/woorim960/dda0bc85599f61a025bb8ac471dfaf7a
https://yeni-days.tistory.com/9
