EC2 인스턴스에 HTTPS 연결을 설정하고 도메인을 인증하며 AWS Certificate Manager를 사용하여 SSL 인증서를 발급하는 방법에 대한 2번째 포스트입니다.
이번 포스트는 발급한 인증서를 사용해 아래와 같은 방식으로 진행됩니다.
1. EC2 인스턴스의 로드 밸런서(Load Balancer)를 위한 타겟 그룹을 생성
2. 로드 밸런서(Load Balancer)로 리다이렉트 규칙을 설정(http 요청을 https로 리다이렉트)
3. 로드 밸런서의 Health check를 통과해 로드 밸런싱을 안전하게 유지
4. 도메인 레코드(A)를 생성해 메인에 연결된 IPv4 주소로 매핑
진행 방법
EC2 인스턴스의 타겟 그룹을 생성하고 대상의 Health Check을 통해 서비스 가능 여부를 판단한 후 도메인 레코드를 설정하여 내 EC2의 IPv4 주소를 내 도메인에 매핑한다. 이후 다음과 같은 동작이 진행된다.
- HTTPS 요청의 경우
1 . 로드 밸런서 리스너 규칙에 따라 요청을 받으면 먼저 HTTPS 프로토콜을 사용하여 암호화된 상태로 로드 밸런서에 도착
- 로드 밸런서는 이 요청을 백엔드 웹 서버로 전달하기 위해 타겟 그룹을 사용(이 과정은 암호화된 HTTPS 연결에서 웹 서버의 HTTP 포트로 요청을 전달하는 것)
- HTTP 요청의 경우
- 로드 밸런서 리스너 규칙에 따라 요청을 받으면 로드 밸런서는 이 요청을 HTTPS로 리디렉션하여 보안 연결을 강제
- 이후 HTTPS로 리디렉트된 요청은 HTTPS 포트를 사용하는 로드 밸런서 리스너에 의해 처리되고, 타겟 그룹을 통해 웹 서버로 전달
용어 설명
로드 밸런서(Load Balancer)
- 애플리케이션 트래픽을 여러 EC2 인스턴스로 분산하는 데 사용
로드 밸런서의 주요 기능
- 트래픽 분산 : 로드 밸런서는 여러 EC2 인스턴스 사이에 들어오는 트래픽을 분산해 단일 인스턴스에 부하를 분산시키고 가용성을 향상
- 자동 확장 지원 : Amazon Auto Scaling과 함께 사용하면 트래픽이 늘어나면 자동으로 인스턴스를 추가하고 줄어들면 자동으로 제거하여 애플리케이션의 성능 조절
- 회복성 및 장애 조치 : 로드 밸런서는 장애 발생 시 트래픽을 정상 상태인 인스턴스로 자동으로 전환하여 서비스 가용성을 유지
타겟 그룹(Target Group)
- 로드 밸런서가 요청을 전달하는 대상(타겟)의 집합
- 로드 밸런서가 어떤 인스턴스, 컨테이너, IP 주소 또는 Lambda 함수로 트래픽을 분배할지 정의하는 역할 타겟 그룹의 주요 기능
- 로드 밸런서와의 연결 : 타겟 그룹을 생성하고 로드 밸런서와 연결하여 트래픽을 분산. 로드 밸런서는 타겟 그룹 내에서 정의된 대상에게 트래픽을 분배
- 자동 확장: 타겟 그룹은 AWS Auto Scaling 그룹과 통합하여 자동으로 확장 및 축소. 이를 통해 트래픽 증가 시 자동으로 인스턴스를 추가하거나 감소
- 장애 조치: 타겟 그룹을 사용하면 로드 밸런서가 타깃으로 지정된 대상 중에서 가용성이 있는 대상으로 트래픽을 전환할 수 있음. 이를 통해 장애가 발생한 경우에도 서비스 가용성을 유지
- 경로 기반 라우팅: Application Load Balancer의 경우, 타겟 그룹을 사용하여 URL 경로나 요청 헤더에 따라 트래픽을 서로 다른 대상 그룹으로 라우팅
- 세션 유지: Classic Load Balancer와 Network Load Balancer는 타겟 그룹을 사용하여 세션 유지를 구성할 수 있습니다. 이를 통해 동일한 사용자가 항상 동일한 백엔드 서버로 연결
Health check
- 로드 밸런서가 타겟 그룹의 각 대상(타겟)의 상태를 주기적으로 모니터링하고 해당 대상이 서비스 가능한지 여부를 판단하는 프로세스를 의미
- 로드 밸런서가 트래픽을 분배할 때 어떤 대상에 트래픽을 전달할지 결정하는 데 중요한 역할
Health check 주요 기능
- 가용성 유지 : Health Check를 통해 로드 밸런서는 서비스 가능한 대상만에 트래픽을 분배하여 가용성을 유지. 서비스 불가능한 대상에는 트래픽을 전달하지 않고 정상적으로 작동하는 대상에만 트래픽을 라우팅
- 자동 확장 및 복구 : Health Check를 통해 Auto Scaling 그룹과 통합하여 서비스의 부하나 장애 상황에 따라 자동으로 인스턴스를 확장하거나 복구하는 데 사용. Health Check에 실패한 대상은 자동으로 대상 집합에서 제외되며, 새로운 인스턴스가 생성되거나 대상이 다시 서비스 가능한 상태로 복구될 때 다시 포함
- 가중치 기반 로드 밸런싱 : Health Check 결과에 따라 각 대상에 대한 가중치 조절 (예를 들어, Health Check에 실패한 대상에 대한 트래픽 가중치를 낮추고, 정상 대상에 대한 가중치를 높여 트래픽을 적절하게 분배)
- 장애 조치 : Health Check를 통해 로드 밸런서는 서비스가 중단된 대상을 타깃으로 지정하지 않고 트래픽을 분배하도록 장애 조치를 취함
도메인레코드(A)
- A 레코드는 사용자가 웹 브라우저에서 도메인 이름을 입력하면 해당 도메인의 웹 서버 또는 다른 네트워크 서비스로 연결하는 데 사용
도메인레코드(A) 주요 기능
- 도메인 이름과 IP 주소 매핑 : A 레코드는 도메인 이름을 해당 도메인에 연결된 웹 서버 또는 다른 서버의 IPv4 주소로 매핑한다. 예를 들어, "www.example.com" 도메인을 "192.0.0.1"과 같은 IPv4 주소로 연결할
- 웹 브라우저에서 사용: A 레코드는 웹 브라우저가 웹 페이지를 요청할 때 도메인 이름을 IP 주소로 변환하는 데 사용하며 사용자가 도메인 이름을 입력하면 DNS 서버가 해당 도메인의 A 레코드를 찾아서 관련 IP 주소를 제공
작업 전 주의사항
- 네트워크 설정은 연결할 EC2 인스턴스의 환경에 따라 구성해야 한다.
(이는 VPC (가상 사설 클라우드 네트워크) 및 서브넷 설정을 포함합니다.) - 보안 그룹은 연결할 EC2 인스턴스의 보안을 고려하여 구성해야 한다.
(보안 그룹은 허용할 트래픽 및 포트 설정을 관리하는 데 사용됩니다.) - 웹 서버의 포트 번호를 사용한다.
(해당 포스팅에서는 예시로 4000 포트를 사용하고 있지만, 실제 웹 서버가 사용하는 포트 번호로 변경해야 합니다.)
사전 작업 : EC2 인스턴스 보안 설정
HTTPS 적용을 하려는 인스턴스에서 보안설정
-
보안 그룹을 선택한다.
-
보안 규칙 설정(인바운드 규칙 편집 클릭)
-
사용자 지정 TCP로 내 웹서버의 포트 번호(4000)와, HTTPS의 Anywhere-IPv4, Anywhere-IPv6를 모두 등록한다. (HTTP, HTTPS 모든 요청을 열어주겠다는 것)
1-1. 타겟그룹 생성
(EC2 메뉴 하단에 대상 그룹 클릭)
- 대상 그룹 생성 클릭한다.
- 대상 유형으로 인스턴스를 선택한다.
우리는 HTTPS 적용을 하기 위한 EC2의 VPC의 로드 밸런싱을 해야하기 때문이다.
- 대상 그룹 이름(원하는 것)으로 설정하고 프로토콜은 HTTP 포트 번호는 웹 서버의 포트번호(4000)으로 변경한다.
VPC는 EC2와 동일하게 설정한다.(default VPC면 default 그대로 적용)
1-1. 상태 검사(Health Check) 설정
상태 검사 (Health Check) 설정은 중요하다.
여기서 주요한 설정은 "상태 검사 경로"와 상태 검사 경로의 "성공 코드"이다.
AWS에서는 내가 구입한 도메인 주소로 요청을 보내고 해당 응답을 확인하여 Health Check의 상태를 결정한다. 즉, 위의 스크린샷에서는 "http://(내가 구입한 도메인 주소):4000/"로 설정되어 있는데 해당 주소로 HTTP GET 요청을 보내는 것을 의미한다.
요청에 대한 응답 상태 코드가 "200"이면 해당 대상을 "healthy"로 판단한다. 큐브데이터의 웹 서버의 경우 "/"로 GET 요청을 보내면 상태 코드가 200이 되도록 설정되어 있습니다. 따라서, 상태 검사 경로를 자신의 프로젝트에 맞게 수정하여 해당 주소로 요청을 보낼 때 응답 상태 코드가 "200"이 되도록 설정해야 한다.
이렇게 하면 Health Check이 정상적으로 "healthy" 상태로 변경되어 웹 서버의 가용성을 효과적으로 관리할 수 있다.
- 사용할 인스턴스를 체크하고, 포트 번호(4000)를 확인한 후 아래에 포함시킨다.
- 아래와 같이 타겟 그룹이 생성을 확인 할 수 있다.
2-1. 로드 밸런서 생성
(EC2 메뉴 하단에 로드밸런서 클릭)
-
Application Load Balancer를 선택한다.
Application Load Balancer (ALB)
-
HTTP 및 HTTPS 트래픽을 로드 밸런싱하는 데 사용
-
Layer 7 (애플리케이션 레이어) 로드 밸런서로, HTTP 요청 내용에 따라 트래픽을 분산
-
도메인 기반 라우팅 및 경로 기반 라우팅과 같은 고급 라우팅 기능을 지원
Network Load Balancer (NLB)
-
TCP, UDP, TLS(SSL) 트래픽을 로드 밸런싱하는 데 사용
-
Layer 4 (네트워크 레이어) 로드 밸런서로, 빠른 속도와 고급 네트워크 레벨 기능을 제공
-
IP 주소 기반 라우팅을 지원하므로 정적 IP 주소가 필요한 경우에 유용합니다.
-
대량 트래픽을 처리하기에 효율적
Classic Load Balancer
-
HTTP, HTTPS, TCP, SSL 트래픽을 로드 밸런싱하는 데 사용
-
Layer 4 및 Layer 7 로드 밸런서 기능을 제공
-
기본 로드 밸런서 유형으로, 간단한 구성 및 설정을 제공
-
-
로드 밸런서 이름(원하는 것)을 설정한다.
-
VPC를 선택한다.
-
네트워크 매핑 설정을 구성할 때, Availability Zone(AZ)를 두 개의 AZ로 선택하고 해당 AZ 내에 있는 EC2 인스턴스가 사용하는 VPC 및 서브넷을 확인하고 선택한다.
(서울의 경우 2a, 2c를 선택해야 한다고 하는데 정확히 어떤 영역을 선택해야 하는지 모르겠다..)
서울 리전에는 총 4개의 AZ가 있으며, 이 중에서 2개를 선택해 사용하면 다음과 같은 이점을 얻을 수 있다.
- 고가용성 : 2개의 AZ를 사용하면 하나의 AZ에 장애가 발생했을 때 다른 AZ에서 서비스를 계속 제공할 수 있다. 이로써 시스템의 고가용성이 보장된다.
- 부하 분산 : 서로 다른 AZ에 리소스를 배포하고 로드 밸런싱을 설정함으로써 트래픽을 분산시킬 수 있다. 이는 서비스의 성능을 향상시키고 대량 트래픽을 처리하는 데 도움이 된다.
- 장애 도메인 분리: 각 AZ는 독립된 장애 도메인을 가지며, 장애 도메인 간에 상호 영향을 미치지 않는다. 따라서 장애 도메인 내에서 발생하는 문제가 전체 서비스에 영향을 미치지 않는다.
- 지역적 백업 : 다수의 AZ를 사용하면 데이터의 백업과 회복성을 향상시킬 수 있다. 데이터를 여러 AZ에 복제하여 장애 시 데이터 손실을 방지할 수 있다.
-
"EC2 인스턴스 보안 설정" 작성한 보안 그룹을 선택한다.
-
HTTP(4000), HTTPS(443)의 각 포트를 설정하고 위에서 설정한 타겟 그룹을 선택한다.
-
보안 리스너 설정은 HTTPS 적용(1)에서 생성한 인증서를 선택 후 생성을 완료한다.
2-2. 로드 밸런스 규칙 생성
(생성한 로드 밸런스의 정보로 들어가, 아래의 리스너 및 규칙)
-
HTTPS(443), HTTP(4000)의 리스너가 존재하고, 443에는 SSL 인증서도 연결된 것을 확인 가능하다.
-
규칙을 편집하기 전 아래의 경우 이전 규칙 경험을 사용할 수도 있습니다. 클릭 후 이전 버전을 이용한다.
HTTPS:443 규칙 편집
아래의 사진과 같이 전달대상이 올바르게 설정되어 있는지 확인한다.
요청 시에, 해당 대상 그룹으로 요청을 보낸다는 것이다.
HTTP:4000 규칙 편집
HTTP 규칙은 HTTPS로 리디렉션하여 요청을 보내야 하므로 새로운 규칙을 생성해야 한다.
호스트 헤더에는 내 도메인의 주소를 입력하고, 리디렉션 대상으로는 HTTPS(443)로 설정한 후 규칙을 생성한다.
3. 도메인 레코드 생성
(1)의 포스트에서 Route 53을 통해 생성한 호스팅 영역의 레코드 3개 중 A 레코드를 생성하여 내 EC2의 IPv4 주소를 내 도메인에 매핑하는 작업을 수행
- 레코드 생성을 클릭한다.
- 별칭을 체크한 뒤 트래픽 라우팅 대상을 아래의 사진처럼 설정하고, 위에서 생성한 로드 밸런스를 지정한다.
레코드 이름(서브 도메인)이 필요한 경우 작성하여 레코드를 생성하면 되며 (해당 포스트에서는 직접 "api.cubedata.live"의 호스팅을 직접 설정했기 때문에 따로 생략하고 진행했습니다.)
4. Health check
(EC2 메뉴 하단에 대상 그룹 클릭 후 생성한 대상 그룹을 선택)
- 대상 그룹의 포트의 상태가 healthy 혹은 unhealthy 상태인 것을 확인할 수 있다.
- 1-1의 Health check 설정을 올바르게 한 경우 healthy 상태로 변경된다.
5. 도메인 확인
- HTTPS 설정이 되었는지 확인하기 위해 내 도메인으로 요청을 보내본다.
HTTPS의 기본 포트는 443이므로, 포트를 생략하면 https://(내 도메인 주소):443 으로 연결된다. (크롬에서 자물쇠모양을 확인할 수 있다.)
- HTTP로 요청을 보낸 경우 로드 밸런스 규칙에 의거해 HTTPS로 리다이렉트 된다.
후기
HTTPS를 적용함으로써 사용자 데이터의 안전성을 확보하고, 웹 서버의 신뢰성을 높다. 이러한 변화로 크롬 개발자 도구를 통해 내 백엔드로 요청을 보냈을 때,
mixed content오류를 찾을 수 없게 되었다. 뿐만 아니라, 내 웹 서버가 브라우저에서 "안전" 표시로 감싸져 있어 사용자들에게 안전성을 제공할 수 있는 것에 큰 만족을 느꼈습니다.
HTTP는 데이터를 암호화하지 않고 평문으로 전송하는 프로토콜인 반면, HTTPS는 HTTP의 보안 버전으로, 데이터를 암호화하여 전송한다는 단편적인 지식을 가지고 있었는데 이러한 암호화 과정과 사용자 데이터의 안정성을 어떻게 보장하는지에 대한 궁금증이 생겼다. 다음 포스트에 궁금증을 한번 해결해 보겠다!
정보를 얻은 곳(출처)
