[AWS] 로드 밸런서 (ELB: Elastic Load Balancer), ACM (AWS Certificate Manager), HTTPS

artp·2024년 11월 19일

AWS Certificate Manager acm aws elastic load balancer elb http https 로드 밸런서

aws

목록 보기

9/13

ELB (Elastic Load Balancer)란?

ELB란 쉽게 이해하면, 트래픽(부하)을 적절하게 분배해주는 장치입니다.

Elastic Load Balancer(ELB)는 AWS에서 제공하는 로드 밸런싱 서비스로, 여러 서버 간에 트래픽(부하)을 분산하여 안정적이고 효율적으로 트래픽을 처리할 수 있도록 돕습니다. 서버를 두 대 이상 사용하는 시스템에서는 ELB와 같은 로드 밸런서를 필수적으로 도입하여 트래픽 과부하로 인한 장애를 방지합니다.

사용자들이 EC2의 IP 주소 또는 도메인 주소에 직접 요청
ELB에서 사용자의 요청(트래픽) 처리

ELB의 주요 역할

1. 트래픽 분산

사용자 요청(트래픽)을 여러 서버로 고르게 분산해 서버 과부하를 방지합니다.

2. 서비스 가용성 향상

특정 서버가 다운되더라도 다른 정상적인 서버로 트래픽을 유도해 서비스 중단을 방지합니다.

3. SSL/TLS 인증 지원

ELB는 보안 프로토콜인 SSL/TLS 인증을 활용해 HTTP를 HTTPS로 변환하는 보안 기능을 제공합니다.

SSL/TLS란?

SSL/TLS는 웹 사이트의 통신을 암호화하여 안전하게 보호하는 인증서 및 프로토콜입니다.

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인터넷 통신 보안을 위한 표준 프로토콜입니다.
주로 웹 사이트에서 HTTP를 HTTPS로 변환하여 보안을 강화합니다.
이를 통해 서버와 클라이언트 간에 데이터를 안전하게 주고받을 수 있도록 돕습니다.

HTTPS

HTTPS는 HTTP에 SSL/TLS 암호화를 적용한 버전으로, "보안된 HTTP"라는 의미를 가집니다.

HTTPS 적용의 필요성

1. 보안 강화

HTTPS는 클라이언트와 서버 간 데이터를 암호화하여 전송합니다.
암호화되지 않은 HTTP는 데이터를 중간에서 가로챌 가능성이 있어 보안에 취약합니다.

2. 사용자 신뢰

브라우저에서 "안전하지 않음" 메시지가 표시되는 사이트는 사용자의 신뢰를 잃을 수 있습니다.
아래와 같은 경고 메시지가 뜨는 사이트는 사용자 이탈로 이어질 가능성이 높습니다.

실무에서의 HTTPS 적용

현업에서는 다음과 같은 이유로 대부분의 웹 사이트에 HTTPS를 적용합니다.

1. 보안

데이터를 암호화하여 사용자 정보를 안전하게 보호합니다.

2. SEO(검색 엔진 최적화) 우대

구글과 같은 검색 엔진은 HTTPS가 적용된 웹 사이트를 더 신뢰하며, 검색 순위를 높게 평가합니다.

HTTPS 적용 시 백엔드 통신

HTTPS가 적용된 웹 사이트는 백엔드 서버와의 통신에서도 보안성을 유지해야 합니다.

백엔드 서버도 마찬가지로 SSL/TLS 인증서를 적용한 HTTPS 도메인을 사용해야 합니다.
이러한 이유로, 백엔드 서버와 통신할 때에도 IP 주소가 아닌 HTTPS 인증을 받은 도메인 주소로 통신하게 됩니다.

일반적으로, 도메인을 구성할 때 아래와 같이 많이 구성합니다.

웹 사이트 주소: https://my-web-server.com
백엔드 API 서버 주소: https://api.my-web-server.com

ELB (Elastic Load Balancer) 실습

ELB 생성

EC2 → 로드 밸런서 → 로드 밸런서 생성을 선택합니다.

로드 밸런서 유형은 Application Load Balancer를 선택합니다.

로드 밸런서 이름을 작성한 후, 체계 부분에서는 인터넷 경계를 선택하고, 로드 밸런서 IP 주소 유형은 IPv4를 선택합니다.

네트워크 매핑 부분에서 모든 가용 영역을 선택합니다.

보안 그룹 부분에서는 ELB를 위해 별도로 생성한 보안 그룹을 선택합니다.
이를 위해, EC2 네트워크 및 보안 부분에서 ELB를 위한 별도의 보안 그룹을 하나 생성해야 합니다.

ELB를 위한 보안 그룹 생성

EC2에서 보안 그룹 생성을 선택합니다.
ELB의 특성을 고려하여, 인바운드 규칙에 80(HTTP), 443(HTTPS) 포트로 모든 IP에 대해 요청을 받을 수 있게 설정해야 합니다.
아웃바운드 규칙은 기본 설정을 유지합니다.

리스너 및 라우팅 설정은 ELB로 들어온 요청을 어떤 EC2 인스턴스에 전달할 건지 설정하는 부분입니다.

ELB로 들어온 요청을 처리하려면, 해당 요청을 전달할 대상(서버나 서비스)을 지정해야 합니다. 이때, ELB가 요청을 전달할 대상들의 집합을 '대상 그룹(Target Group)'이라고 부릅니다.
대상 그룹 선택을 위해 대상 그룹 생성을 선택하여, 대상 그룹을 생성해야 합니다.

대상 그룹 생성

EC2에서 대상 그룹 생성을 선택합니다.
EC2에서 만든 특정 인스턴스로 트래픽을 전달할 것이므로 대상 유형은 인스턴스를 선택합니다.
프로토콜: 포트는 각각 HTTP, 80으로 설정합니다.
IP 주소 유형은 IPv4를 선택합니다.
VPC는 기본 설정을 유지합니다.
프로토콜 버전은 HTTP1을 선택합니다.
위의 설정은 HTTP(HTTP1), 80번 포트, IPv4 주소로 통신한다는 것을 의미합니다. 이 방식이 일반적으로 현업에서 많이 사용하는 설정입니다.
ELB의 상태 검사(Health Check)는 ELB가 대상 그룹(Target Group)에 있는 서버(예: EC2 인스턴스)가 정상적으로 작동하고 있는지 확인하는 중요한 기능입니다.
ELB는 트래픽(요청)을 대상 그룹의 서버로 분산하는데, 특정 서버에 문제가 생기면 해당 서버로 요청을 보내는 것은 비효율적입니다. 상태 검사를 통해 고장난 서버를 자동으로 감지하고, 문제 있는 서버로는 요청을 보내지 않도록 합니다.
ELB는 주기적으로(기본 30초) 대상 그룹의 각 EC2 인스턴스에 GET 요청을 보냅니다.
- 요청에 대해 200번대 응답(정상 상태)이 오면 서버가 정상적으로 작동한다고 판단합니다.
- 200번대가 아닌 응답(에러 상태)이 오면 해당 서버에 문제가 있다고 판단하여 트래픽을 보내지 않습니다.
이러한 작동 과정 덕분에 ELB는 효율적으로 트래픽을 분배할 수 있습니다.
상태 검사 프로토콜은 HTTP, 상태 검사 경로는 /health를 설정합니다.
위 설정은 대상 그룹의 모든 EC2 인스턴스에 GET /health 요청을 보내도록 구성한 것입니다. 정상적인 Health Check 기능을 위해, 각 EC2 인스턴스에서 작동 중인 백엔드 서버에 상태 검사용 API(/health)를 구현해 ELB가 이를 확인할 수 있도록 설정해야 합니다.
대상에 등록할 인스턴스를 선택하여 대상 그룹에 추가한 후 대상 그룹 생성을 완료합니다.
로드 밸런서 생성을 완료합니다.

Health Check API 추가

EC2 인스턴스에 접속한 후, app.js 파일에 다음의 코드를 추가합니다. 추가 후에는, EC2 인스턴스의 서버를 업데이트합니다.

// GET /health 요청에 대해 상태코드 200으로 응답하는 API
app.get('/health', (req, res) => {
  res.status(200).send("Success Heatlth Check");
})

로드밸런서 주소를 통해 서버 접속 확인

로드 밸런서를 통한 서버 접속은 DNS 이름을 통해서 접속이 가능합니다.
로드 밸런서 DNS 이름을 복사하여 주소창에 붙여넣어 접속합니다.

ELB에 도메인 연결

EC2에 직접 트래픽을 보내는 것이 아닌, ELB에 트래픽을 보내도록 하기 위해 ELB에 도메인을 연결합니다.
구매한 호스팅 영역을 선택합니다.

EC2와 직접 연결한 레코드를 삭제합니다.

새롭게 레코드를 생성합니다.

레코드 이름을 작성하고, 레코드 유형은 A를 선택합니다.
라우팅 대상은 로드 밸런서를 선택하고, 리전은 아시아 태평양(서울), 생성해놓은 로드 밸런서를 선택합니다.

새롭게 생성한 레코드 이름으로 잘 접속되는 것을 확인할 수 있습니다.

HTTPS 적용을 위한 인증서 발급

AWS Certificate Manager 서비스로 들어가서 인증서를 발급받습니다.

인증서를 받은 도메인 이름을 작성한 후 요청을 선택하여 발급을 완료합니다.

도메인 검증을 위해, Route 53에서 CNAME 이름-값을 사용하여 레코드를 생성해야 합니다.

레코드를 생성한 후, 호스팅 영역 세부 정보를 보면 CNAME 유형의 레코드가 새로 생성된 것을 확인할 수 있습니다.

약 1 ~ 5분 뒤에, 인증서 발급이 완료됩니다.