https 적용(Route 53, ACM, 로드밸런서)

 

 

 

 

오늘 하루를 https를 적용하는데 써버렸다..

 

처음 목표는 github.io로 프론트 서버를 돌리고 백엔드는 ec2에서 돌리는데 도메인을 구입해서 github에서 설정을 잘 해서 예쁘게 만들려고 했지만 도메인을 적용하면 ec2 프론트 엔드 서버로 자꾸 리다이렉트 돼서 그냥 돈을 조금 더 내더라도 ec2로 프론트를 돌리기로 했다.

 

 

 

 

---

도메인 구매

 

오늘 사용한 aws 서비스는 ACM(AWS Certificate Manager), Route 53, 로드밸런서 이렇게 3가지 서비스를 사용하였다. hosting.kr에서 도메인을 1년짜리를 5천원이었나 구입하였다. 무료 도메인을 사용하고 있었는데 내도메인.한국 사이트에서 무료로 제공하는 도메인은 ssl 인증이 안된다고 알고 있어서 결국 유료로 도메인을 구매했다. 구글에 검색하면 도메인을 구매할 수 있는 여러 사이트가 있으니 가격과 편의성을 고려하여 사이트를 선택하자.

 

 

 

 

---

Route 53 호스팅 영역 등록

 

 

처음에 Route 53으로 호스팅 영역을 구성해야 한다. 호스팅 영역을 만들면 네임서버가 4개 나오는데 hosting.kr 관리 페이지에서 네임 서버에 붙여 넣으면 잘 작동된다. 오늘 모든 작업이 설정을 마치더라도 다 시간이 5분 정도 지나야 적용이 되어서 이게 잘 된건지 안된건지 잘 모르겠어서 시간이 많이 걸렸다.. 그래도 결국 겪어야 하기에 어쩔 수 없이 울며 겨자먹기로 했다.

 

1. 호스팅 영역 생성 버튼 클릭

 

2. 도메인 이름 입력

 

3. 레코드는 아마 NS, SOA 2가지가 생성되어 있을텐데 이후 ACM 인증에서 레코드를 생성할 것이므로 지금 안해도 됨.

 

4. 위에서 구매한 도메인 사이트에 가서 route 53의 호스팅 영역 NS에 적힌 네임서버 주소를 입력하자.

 

이렇게 하면 호스팅 영역 세팅이 끝난다. 이후 레코드에 로드 밸런서를 추가해서 도메인과 IP를 연결할 건데 나중에 로드 밸런서를 생성하고 나서 진행한다.

 

문제점은 프론트와 백엔드 둘 다 https를 적용 안하면 "mix-content 차단됨" 이런식으로 아예 통신이 안돼서 대부분 작업을 프론트, 백앤드 두가지를 생각하고 진행하였다.

 

처음에는 프론트, 백엔드 두가지로 모두 나눠서 설정하였고 동작이 잘 되었지만 나중에 결국 로드 밸런서를 프론트, 백엔드 각각 설정하면 시간이 따로 추가돼서 요금이 750시간이 넘어 한달에 만원이 넘게 비용이 청구되는 사태가 발생했다. 그래서 다시 도전해서 로드 밸런서를 한개로 https를 설정하는데 성공하였다. 

 

 

---

 

ACM 인증서 등록

 

다음으로 ACM에서 인증서를 받아야하는데 그냥 *.도메인처럼 하나만 가져와도 될 것 같지만 혹시 몰라서 인증서도 하나의 인증서를 만들 때 다른이름 추가로 프론트 백엔드 2가지를 가져왔다.

 

필자는 프론트: lemonsoju.blog, 백엔드: api.lemonsoju.blog와 같이 2가지를 등록하였다. 대체이름 추가를 클릭하고 추가 도메인을 입력하면 된다.

 

그런데 다시 도전할 때는 로드 밸런서에서 포트를 기준으로 나눌 수 있다는 사실을 깨닫고 lemonsoju.blog만 등록하였다.

 

DNS 검증을 클릭하고 인증서를 받고 인증서에 Route 53 레코드 생성 버튼을 바로 눌러서 인증을 진행하였다. 검증도 이게 알아서 되는거라 나는 15분 정도 걸렸던 것 같다. 두번째 시도에서는 30분이 지나고 검증보류 중이어서 살펴보니 보안그룹이 default로 되어 있어서 검증이 안된 것이었다. 만약 검증 보류가 30분이 지나고 풀리지 않는다면 보안그룹을 잘 살펴보자. 앞에서 호스팅 영역을 설정할 때 인스턴스와 도메인 구매 사이트를 연결했었는데 지금을 위한 과정이었다. 앞에서 설정을 제대로 했으면 자동으로 aws에서 검증을 진행하고 어느순간 검증 완료라고 바뀐다.

 

 

 

 

---

로드 밸런서 등록

 

첫번째 시도 -> 돈이 많이 나온다.

마지막으로 대상 그룹을 프론트, 백엔드 나눠서 생성하고 프론트는 80, 443에 대해서 백엔드는 서버 포트인 8080에 대해서 설정했다. 로드 밸런서도 각각 설정하고 나면 https에 빨간 줄이 없어진다... 인터넷에 찾아도 자료가 별로 없어서 chatgpt한테 계속 물어봤는데 애도 잘 몰라서 포기할 뻔 했다..

 

두번째 시도 -> 대상 그룹은 프론트, 백엔드로 나누는게 맞다. 프론트는 80, 백엔드는 8080만 설정하면 된다. 해당 포트는 나중에 로드밸런서에서 서버로 데이터가 넘어갈때 방금 설정한 포트로 넘어간다고 생각하면 된다.

 

ec2 화면에서 왼쪽 네이게이션 메뉴에 로드 밸런서가 있는데 로드 밸런서 생성을 클릭하면 된다.

 

1. 대상 그룹 생성. 

-> 필자는 view, back 2개의 대상 그룹 생성

여기서 대상 등록할 포트는 각 인스턴스에서 사용할 포트를 입력해야 한다. 예를 들어 프론트는 80으로 요청을 받고 백엔드는 8080 포트로 요청을 받으면 프론트에는 80, 백엔드는 8080을 대상 등록해야 한다.

 

2. Application Load Balancer를 생성

-> 총 1개의 로드 밸런서를 생성할 예정 -> 2개 이상 생성하면 프리티어도 한달에 만원 넘게 나온다.

 

3. 리스너에는 http 80, https 443, https 8080을 추가.

-> 포트마다 알맞은 대상 그룹을 선택 

 

4. 가용영역은 모두 선택한다.

 

5. 보안 그룹은 이미 사용중인 그룹을 사용하였다.

 

6. 생성을 완료하고 로드 밸런서 별로 DNS 이름에 대상 그룹명이 잘 맞는지 확인한다.

 

7. 호스팅 영역 레코드 편집에서 생성한 로드 밸런서를 등록해서 도메인과 ip를 연결한다. 

 

 

 

 

로드 밸런서가 꼭 필요한가? 라는 의문이 들어서 찾아봤다.

 

https에서 로드 밸런서를 사용하는 이유

 

1. SSL/TLS 종료: HTTPS 통신에서는 SSL/TLS 암호화가 필요합니다. 로드 밸런서를 사용하면 클라이언트와 로드 밸런서 간의 암호화된 통신을 처리하고, 로드 밸런서는 암호화를 해제하여 요청을 백엔드 서버로 전달합니다. 백엔드 서버는 암호화 연산을 처리하지 않아도 되므로 성능이 향상됩니다.

 

2. 인증서 관리: 로드 밸런서를 통해 SSL/TLS 종료를 수행하면 인증서 관리가 용이해집니다. 로드 밸런서에서 인증서를 관리하고 업데이트할 수 있으며, 백엔드 서버에서 인증서를 개별적으로 관리할 필요가 없어집니다.

 

3. 부하 분산: HTTPS 트래픽이 많은 경우 로드 밸런서를 사용하여 트래픽을 여러 대의 백엔드 서버로 분산시킬 수 있습니다. 이를 통해 서버의 부하를 분산시키고 성능과 가용성을 향상시킬 수 있습니다.

 

4. 장애 복구: 로드 밸런서는 여러 백엔드 서버에 트래픽을 분산시킴으로써, 하나 이상의 서버가 장애를 겪더라도 다른 정상적인 서버로 트래픽을 전달합니다. 이를 통해 시스템의 가용성을 높이고 장애에 대한 복구력을 강화할 수 있습니다.

 

HTTPS를 사용하기 위해서는 SSL/TLS 암호화가 필요하며, 이를 효율적으로 처리하고 부하를 분산시키기 위해 로드 밸런서를 사용하는 것이 권장됩니다. 이는 보안, 성능, 가용성 측면에서 이점을 제공하며 안전한 웹 트래픽을 처리하는 데 도움을 줍니다.

 

 

 

 

 

---

위 과정을 끝으로 모든 과정이 끝났다. 지금까지 https를 적용했는데 많은 고난이 있었다. 인증서를 적용했는데 알 수 없는 원인으로 https에 빨간줄이 그어져 있었고 안전하지 않은 인증서라고 떠서 계속 고통받으면 이것저것하다가 결국 문제를 다 해결해서 기분이 좋은 상태이다..