학교 식단 프로젝트 시 https으로 접속하기 위해서 여러 시도를 해보았고 성공했기 때문에 글을 작성한다. 이 글엔 내가 겪은 시행착오들도 적어보려고 하니 HTTPS 를 적용시키고자 하는 사람은 이 글을 읽으면서 따라해보면서 구현하면 좋을 것 같다. https 를 사용해 ec2 에 접속하는 방법은 cloudFrount 를 사용하는 방법과 ELB 를 사용하는 방법이 있다. 나의 경우 이 프로젝트를 추후에 확장시켜 출시할 예정이기 때문에 트래픽 부하 분산을 고려하여 ELB 를 사용하여 https 접속하는 방법을 선택해보았다.
1. EC2 생성
https 로 접속할 인스턴스를 만들어준다. 이 글을 읽는 분들은 기본적으로 EC2 생성할 줄 아는 사람들이라고 가정하고 유의할 사항만 언급해도록 하겠다. 기존 보안 그룹을 사용해도 된다. 다만 기존 보안 그룹이 80, 443 포트에 열려있는지 확인하고 사용하길 바란다. 만약에 EC2 에 spring 을 사용할 것이라면 8080 열어 놓길 바란다. 새로운 보안 그룹을 생성할 땐 다음처럼 체크하고 EC2생성한다
생성된 EC2에 접속하여 아파치 서버를 설치한다. 만약 EC2 에 spring이 돌고 있다면 아파치르 굳이 설치할 필요가 없으니 참고하기 바란다. spring에도 내장 서버(Tomcat)이 있기 때문이다.
# 패키지 목록 업데이트
sudo apt-get update
# Apache2 설치
sudo apt-get install apache2 -y
# Apache 서비스 시작
sudo systemctl start apache2
# 서버 재시작시 자동으로 Apache가 시작되도록 설정
sudo systemctl enable apache2
# Apache 상태 확인
sudo systemctl status apache2
만약에 설치를 다했다면 테스트를 해보기 위해 본인의 ec2 public ip 주소를 url에 입력해보자. 그럼 다음처럼 나올 것이다.
2. 도메인 사기
먼저 도메인을 사야 한다. AWS Route 53에서도 구입이 가능하지만 , 가비아가 좀 더 싼 거 같아 가비아를 이용하였다.
원하는 도메인을 입력하고 검색 버튼을 누르자. 나같은 경우는 my-profile로 했다.
나 같은 경우는 가장 싼 my-profile.store 로 했다. 신청하기 버튼을 눌러 구매를 마저 해주기로 하자.
다음 사진처럼 개인정보 입력하고, 관리자 정보, 서비스 관리, 정보, 부가서비스 추가에 대해선 건드리지 않고 진행한다.
3. Route 53과 연결하기
호스팅 영역 생성을 클릭한다.
호스팅 영역(Hosted Zone)은 Route 53에서 도메인의 DNS 레코드들을 관리하는 컨테이너다. 즉 도메인에 대한 DNS 레코드들의 모음이라고 볼 수 있다.
- A 레코드 (IPv4 주소)
- CNAME 레코드 (별칭)
- MX 레코드 (메일 서버)
- NS 레코드 (네임서버) 등
호스팅 영역은도메인/서브도메인의 트래픽을 어디로 라우팅할지 정의하고, DNS 쿼리에 응답하는 방식 설정한다.
도메인의 DNS 설정을 관리하는 중앙관리 혹은 컨테이너라고 보는 것이다.
도메인 이름을 내가 구매한 도메인 이름으로 해준다. 나같은 경우는 my-profile.store 로 하였다. 내가 구매한 도메인을 최상위 루트 도메인으로 설정하는 것이기 때문에 도메인 이름에 my-profile.store 을 입력한다.
다른 블로그 글에서 *. 를 붙이라는 말에 *. my-profile.store 로 했다가 안돼서.. 한참을 헤맸다. *. my-profile.store 은 와일드카드 도메인으로, 모든 서브도메인을 의미하는데, 와일드카드는 레코드 설정에서 사용하는 것이지, 호스팅 영역 이름으로 사용하는 것이 아니기 때문에 에러가 발생했던 것이다.
호스팅 영역은 도메인의 최상위 DNS 설정을 관리하기 때문의 DNS의 계층 구조상 루트 도메인이 모든 서브도메인의 상위에 위치해야 한다. 따라서 상위 루트 도메인에 my-profile.store 을 입력한 것이다.
4. AWS Certificate Manager
인증서를 발급 받아야 한다. 인증서 요청 > 퍼블릭 인증서 요청을 클릭한다
'완전히 정규화된 도메인 이름'에 내가 구매한 도메인을 넣고 요청 버튼을 클릭한다.
인증서가 생겼으니 검증 대기 중인 요청서를 클릭한다.
Route 53에서 레코드 생성 을 클릭한다.
레코드 생성을 클릭한다.
위 사진은 인증서에 대한 레코드를 만드는 것이고, 우리가 구매한 도메인에 대한 레코드도 생성해야 한다. Route 53 으로 돌아와서 레코드 생성 버튼을 누른 후 생성한 ec2의 public ip 주소를 값에 넣어주고 레코드를 생성한다. 레코드 이름을 안 적어도 된다.
가비아로 돌아와 아까 생성한 도메인 관리 페이지로 들어간다. 관리를 클릭하면
다음 사진에서 1차,2차,3차,4차 네임서버를 변경해줘야 한다. 근데 뭐로 변경해야 하냐면
호스팅 영역에 오면 빨간색 사각형 안에 4개의 값이 보일 건데 이 4개의 값을 1차, 2차, 3차, 4차 네임서버에 넣어준다.
이 때 네임서버에 넣을 때 끝에 .을 없애주고 넣어야 한다.
5. 로드 밸런서 구성
EC2 에 접속 후 아래 사진에 있는 로드 밸런서를 클릭한다.
로드 밸런서 생성 할 때 다음처럼 3가지 유형 중에서 Application Load Balacner 를 선택한다. 여기서 각 Load Balance에 대해서 간략히 알아보도록 하겠다.
Application Load Balancer(ALB)는 HTTP와 HTTPS 트래픽을 처리하는 로드 밸런서로, 주로 웹 애플리케이션의 트래픽을 분산하는 데 사용된다.
Network Load Balancer(NLB)와 비교하면, ALB는 애플리케이션 계층(Layer 7)에서 작동하며 URL 기반 라우팅이 가능한 반면, NLB는 네트워크 계층(Layer 4)에서 작동하여 TCP/UDP 프로토콜을 처리하고 더 낮은 지연 시간을 제공합니다. NLB는 고성능이 필요한 게임 서버나 스트리밍 서비스에 적합하다.
Gateway Load Balancer(GWLB)와 비교하면, ALB는 웹 트래픽 분산에 중점을 두는 반면, GWLB는 방화벽, 침입 탐지, 심층 패킷 검사와 같은 보안 서비스를 처리하는 데 특화되어 있습니다.
결론적으로 ALB는 웹 애플리케이션을 위한 지능적인 라우팅과 HTTPS 보안을 제공하는 데 최적화되어 있다. 우리는 EC2에 HTTPS 로 접속할 것이기 때문에 Application Load Balancer 를 선택한다.
로드 밸런서 이름은 임의로 정하면 된다. 여기서 인터넷 경계와 내부 중 하나의 체계를 선택해야 한다.
인터넷 경계 로드 밸런서는 public ip 주소를 사용하여 인터넷을 통해 외부에서 들어오는 트래픽을 처리한다. 웹사이트나 공개 api와 같이 외부 사용자의 접근이 필요한 서비스에 주로 사용되며, public 서브넷에 위치해야 합니다.
반면 내부 로드 밸런서는 private ip 주소만을 사용하여 VPC 내부의 트래픽만 처리합니다. 데이터베이스 서버나 내부 api와 같이 외부에 노출될 필요가 없는 내부 서비스들 사이의 통신에 사용되며, 프라이빗 서브넷에 위치할 수 있다.
우리는 public ip주소로 https 접속이 가능하는지 해볼 것이기 때문에 인터넷 경계를 선택한다.
EC2 가 있는 VPC를 선택해준다. 아까 EC2를 생성할 때 VPC 를 별도로 생성하지 않았으므로 defalut VPC 를 사용한다.(생성한 EC2가 VPC 에 생성 될 것이기 때문에) 또한 EC2 가 있는 가용 영역을 선택해 주는데 최소 2개 이상의 가용 영역을 설정해줘야 한다.
보안그룹의 경우 EC2 생성 시 사용했던 보안그룹을 선택하면 되는데, 꼭 80, 443 포트가 열려있는지 확인 해보고 사용하길 바란다. 나는 보안상 아무 선택도 하지 않은 화면을 보여준 것임을 자각하고 본인에게 맞는 가용용역, 보안그룹을 선택하면 된다. EC2가 속한 가용영역이 어딘지 궁금한 분은 가용영역 4개 모두 선택해도 무관하다.
5-1. 대상그룹 생성
다음 사진을 보면 대상 그룹 생성 버튼이 있다. 클릭해서 생성하러 가자.
EC2를 사용할 것이기 때문에 인스턴스를 선택한다. 나는 아까 80 포트에서 실행되는 아파치 서버를 설치했기 때문에 프로토콜 포트를 80으로 선택한다. 만약에 spring 이 8080 포트에서 작동중인 사람은 8080으로 변경하길 바란다.
대상 그룹 이름은 알아서 지으면 된다.
아까 생성한 인스턴스를 클릭한 후 아래 보류 중인 것으로 포함 클릭 > 대상 그룹 생성 클릭 하여 대상그룹에 인스턴스를 추가해준다.
5-3. Load Balancer 마무리 설정
다시 Load Balancner 만드는 화면으로 돌아와서 리스터 리스너 HTTP:80, HTTPS:443 을 추가한 다음에 사진처럼 방금 생성한 대상 그룹을 선택해준다.
다음 사진에서 설정한 내용은 다음과 같다. http , 80 포트로 오는 경우와 https 443포트로 오는 경우 대상 그룹으로 트래픽을 전달해주는 것이다. 아까 대상 그룹에 아까 만든 ec2를 추가한 것으로 가는 것이다.
아까 생성한 인증서도 선택해준다. 로드 밸런서를 설정해준다.
6. Load Balancer 와 도메인 연결
다음 사진처럼 유형 A를 클릭하고 우측에 레코드 편집 버튼을 누른 다음
별칭 선택, Application Load Balancer 선택, 방금 생성한 Load Balancer 를 선택하고 수정한다.
이렇게 https://my-profile.store/ 입력하면 잘 접속이 된다는 것을 알 수 있다. 각자 본인의 구매한 도메인 주소에 https 를 붙여서 접속해 보시길 바란다.
7. 배운 점
HTTPS 로드 밸런서를 구현하는 과정을 통해 HTTPS 통신의 전체적인 흐름을 이해할 수 있었다. 클라이언트의 요청이 443 포트로 들어오면 HTTPS로 암호화된 트래픽을 HTTP로 복호화하는 과정을 거쳐서 HTTP로 EC2의 8080 포트로 전달되는 과정을 좀 더 세부적으로 이해할 수 있게 되었다.
인증서 관리에서는 ACM을 통해 SSL 인증서를 발급받고 관리하는 방법을 배웠다. 특히 와일드카드 인증서와 일반 인증서의 차이를 이해했다. 일반 인증서의 같은 경우는 특정 도메인, 해당 블로그에선 my-profile.sotre 만 보호하는 것에 반해 와일드카드 인증서는 *.my-profile.store 형태로 모든 서브도메인 보호한다는 사실을 알게 되었다. 또한도메인 이름과 인증서가 정확히 매칭되어야 하는 중요성을 알게 되었다.
Route 53에서 도메인 설정을 진행하며 DNS의 동작 원리를 더 깊이 이해하게 되었다. 호스팅 영역을 생성하고, A 레코드를 통해 ALB와 도메인을 연결하는 과정에서 DNS 레코드 타입들의 실제 역할을 알 수 있었다.
로드 밸런서 설정 과정에서는 리스너 규칙 설정, 대상 그룹 구성, 상태 검사 설정, 로드 밸런서의 구조 등 실제 운영에 필요한 다양한 설정들을 경험했다. 특히 보안 그룹을 구성하고 인바운드/아웃바운드 규칙을 설정하면서 보안의 중요성을 체감했다.
마지막으로 인증서 오류나 로드 밸런서 연결 문제를 해결하면서 실제 운영 환경에서 발생할 수 있는 문제들을 해결하는 경험을 쌓을 수 있었다. DNS 전파 시간을 고려해야 하는 등 실제 서비스 운영에서 주의해야 할 점들도 배울 수 있었다.
8. 마무리
해당 블로그를 따라 실습하실 때 인증서, 보안그룹, 호스팅 영역, 도메인, ec2, 포트 등 다양한 부분을 유심히 설정하여 실습에 오유가 없길 바란다.
실제 프로젝트를 위해 https 를 배포하기 위해 공부를 하고 실제로 구현에 완성하여 이 부분을 기록하고, 공유하고자 해당 블로그를 작성한 것임을 다시 한 번 알린다.
