EC2 HTTPS로 연결하기 (2) - 로드밸런서로 리다이렉트 설정하고 Health check 통과하기
<< EC2 HTTPS로 연결하기 >>
1편) 도메인 구매하고 ACM 인증서 발급하기 (링크)
(도메인 구매 --> 도메인 인증 --> ACM 인증서 발급 --> Target Group 생성 --> Load Balancer 생성 --> 규칙 수정 --> Health check 성공)
2편) 로드 밸런서 사용하고 Health check 통과하기 <-- 현재 글
(도메인 구매 --> 도메인 인증 --> ACM 인증서 발급 --> Target Group 생성 --> Load Balancer 생성 --> 규칙 수정 --> Health check 성공)
개요
EC2를 HTTPS로 연결하기 위한 포스팅 시리즈입니다.
'가비아'에서 도메인을 구매하고,
AWS(Route 53)에서 도메인 소유를 인증하고,
ACM(AWS Certification Manager)를 통해 SSL(TSL) 인증서를 발급받았습니다.
이번 포스팅에서는,
EC2 인스턴스의 로드 밸런싱을 위한 타겟 그룹을 생성하고,
로드 밸런서(Load Balancer)로 리다이렉트 규칙을 설정하고(http 요청을 https로 리다이렉트),
로드 밸런서의 Health check를 통과해 로드 밸런싱을 안전하게 유지하는 방법을 정리해보겠습니다.
사전 설명 (타겟 그룹? 로드 밸런서?)
로드 밸런서(Load Balancer)는 본래, 요청을 여러 서버로 분산시키기 위해 사용하는 장치 혹은 기술입니다.
타겟 그룹을 여러 개 생성하고, 들어오는 요청을 특정 알고리즘에 따라 각 타겟 그룹에 분산시켜 보내는 것입니다.
(설명이 틀렸을 수 있으니 참고만 해주세요.)
하지만 지금 우리가 구현하려고 하는 방식은 아래와 같습니다.
- 타겟 그룹이 1개
- HTTPS 요청 (리스너에서 캐치) --> HTTPS를 거친 후, 로드밸런싱을 통해 본래 사용하던 HTTP 포트(타겟 그룹)로 요청
- HTTP 요청 (리스너에서 캐치) --> 위의 HTTPS로 리디렉션(by 리스너 규칙)
보다 정확한 로드 밸런서에 대한 이해는 아래 아티클을 추천드립니다.
https://inpa.tistory.com/entry/AWS-📚-ELB-Elastic-Load-Balancer-개념-원리-구축-세팅-CLB-ALB-NLB-GLB
[AWS] 📚 ELB(Load Balancer) 개념 원리 & 사용 세팅 💯 정리
ELB (Elastic Load Balancer) ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(ECS), A
inpa.tistory.com
준비 사항
아래 내용을 따라가실 때는, 다음 사항을 기억해주셔야 합니다.
1. 네트워크는 연결할 EC2의 설정을 따를 것(VPC 등)
2. 보안그룹은 연결할 EC2의 설정을 따를 것
3. 나의 웹 서버에서 사용하는 포트 번호를 사용할 것 --> 본 포스팅에서는 8080
또한, EC2에서 사용하는 보안 그룹을 아래와 같이 수정해주셔야 합니다.
연결할 EC2 인스턴스의 정보 탭에 들어가서, 사용 중인 보안 그룹(Red box)을 클릭합니다.
인바운드 규칙 편집을 클릭합니다.
8080(웹 서버에서 사용 중인 포트 번호 / 아래에서는 설명 생략), 443번 포트에 대해 Anywhere-IPv4, Anywhere-IPv6를 모두 등록하고, 우측 하단의 규칙 저장을 클릭합니다.
HTTP, HTTPS 모든 요청을 열어주겠다는 것입니다.
이제 아래에서, 본격적으로 로드 밸런싱을 설정해보겠습니다.
타겟 그룹(Target Group) 생성
EC2 메뉴 하단에 대상 그룹이 있습니다. 클릭해줍니다.
타겟 그룹을 생성합니다.
갑자기 왜 영어가 된 지는 모르겠지만, 해석 + 버튼 위치 등으로 잘 따라와주시길 바랍니다.
타겟 유형은 인스턴스를 선택하고,
적당한 이름을 설정하고, 포트 번호를 바꿔주고, VPC를 EC2와 동일하게 설정합니다. (default VPC면 default 그대로)
Health check는 타겟 그룹의 EC2 인스턴스가 건강한지 확인하는 방법을 말합니다.
Unhealthy하다면, 로드 밸런서가 해당 타겟 그룹으로 요청(부하)을 보내지 않습니다.
이건 이따 손 볼 예정이니, 디폴트를 유지하겠습니다.
다음 페이지로 넘어가겠습니다.
사용할 인스턴스를 체크하고, 포트 번호를 확인한 후 아래에 포함시킵니다.
위처럼 타겟이 추가되었다면, 타겟 그룹 생성(Create target group)을 클릭합니다.
위와 같이 TG(Target Group)가 생성되었음을 확인할 수 있습니다.
로드 밸런서(Load Balancer) 생성
로드 밸런서 생성을 클릭합니다. (제 LB는 이미 생성되어있지만 무시해주세요.)
ALB를 사용하겠습니다.
적당한 이름을 설정하고 넘어갑니다.
네트워크 매핑은, 최소 2개의 AZ(Available Zone)을 설정해야 합니다..만
반드시 확인하셔야 할 것은, EC2가 사용하는 VPC, 서브넷과 매핑되어야 한다는 것입니다.
헷갈리신다면, 아래처럼 EC2 인스턴스 정보를 확인하셔서
인스턴스의 VPC, 서브넷(혹은 가용 영역)을 포함하도록 네트워크 매핑을 진행해주세요.
참고로 위에서 Scheme 설정을 Internet-facing으로 정했기에,
Private subnet은 매핑할 수 없습니다.
Public subnet으로 매핑해주세요.
보안 그룹은 EC2 인스턴스와 동일하게 설정해줍니다.
HTTP 8080, HTTPS 443 에 대한 리스너를 생성합니다.
Forward to를 위에서 생성한 타겟 그룹으로 설정합니다.
이전 포스팅에서 생성한 인증서를 적용해줍니다!!
Load Balancer가 생성되었습니다.
도메인 레코드 생성
이전 포스팅에서,
Route 53을 통해 생성한 호스팅 영역의 레코드 4개(A, NS, SOA, CNAME) 중
A는 다음에 만들 것이라고 했었는데요,
A 레코드를 만들어보겠습니다.
레코드 이름(서브 도메인)은 사용해도 되고, 안해도 됩니다. 저는 안하고 넘어가겠습니다.
트래픽 라우팅 대상을 위 그림처럼 설정해서, 위에서 생성한 LB를 지정해주어야 합니다.
그리고 레코드를 생성합니다.
자, 이제 호스팅 영역의 레코드 4개가 다 생성되었습니다!
로드 밸런서 리스너 규칙 추가
위에서 생성한 로드 밸런서의 정보로 들어가, 아래의 리스너 탭을 확인해봅시다.
443, 8080의 리스너가 존재하고, 443에는 SSL 인증서도 연결되어 있음을 알 수 있습니다.
각각을 클릭해 규칙을 편집해보겠습니다.
먼저 HTTPS:443 입니다.
위와 같이 설정하고 저장합니다.
요청 시에, 위에서 생성한 대상 그룹으로 100% 보내겠다는 뜻입니다.
이번에는 HTTP:8080 입니다.
위와 같이 규칙을 추가합니다.
다시 LB의 리스너 탭을 확인하면, Rules가 위와 같이 변경되었음을 확인할 수 있습니다.
자 이제 진짜 다왔습니다!
Health check
EC2>로드 밸런싱(좌측 메뉴)>대상 그룹 에서, 위에서 생성한 대상 그룹을 선택합니다.
그럼 위와 같이 대상 그룹의 각 대상들이 healthy 혹은 unhealthy 상태인 것을 확인할 수 있습니다.
지금의 목표는 8080을 healthy하게 만드는 것입니다.
그를 위해 방법만 알려드리고 포스팅을 마치고자 합니다.
웹 서버가 EC2 인스턴스 위에서 구동되고 있어야 합니다.
그럼 AWS에서 특정 주소로 요청을 보내고, 그 응답을 확인하여 healthy 상태를 확인합니다.
그 설정을 확인해보겠습니다.
편집 창으로 이동합니다.
여러 가지 설정이 있는데, 잘 읽어보시고 수정할 수 있습니다.
하지만 가장 중요한 것은, Health check path와 Success codes 입니다.
/로 되어 있다는 것은, root 디렉토리로 요청을 보낸다는 것인데요,
저의 경우를 예시로 들면,
http://domain.com:8080/ 으로 HTTP 요청을 보낸다는 것입니다. (아마 GET 요청인 것 같습니다.)
이 요청에 대한 응답 상태 코드가 200번이면, 해당 타겟을 healthy하다고 판단하는 것입니다.
저는 Spring boot 프로젝트로 웹 서버를 만들었기 때문에,
루트 디렉토리에 GET 요청을 보내면 404 코드가 오는 상황이었습니다.
따라서 Health check path를 특정 주소로 수정하고,
특정 주소에 대한 요청을 무조건 200으로 보내는 API를 작성하여
웹 서버 코드를 다시 빌드하고 구동시켰습니다.
요약하면, <타겟 주소>:8080/<Health check path> (eg. http://domain.com:8080/home/health/) 로 보낸 요청에 대한 응답이 Success codes에 포함되면 healthy 상태가 됩니다.
이렇게 8080 포트 타겟을 healthy 상태로 만들면,
긴 여정이 끝났습니다!
확인
확인해보겠습니다.
https://domain.com --> 웹 서버 주소로 연결
여기서 https의 기본 포트는 443이므로, 포트를 생략하면 https://domain.com:443 으로 연결됩니다.
domain.com:443 으로 들어온 요청은 443에 해당하는 리스너가 잡아서 인증을 거친 후 domain.com:8080(타겟 그룹)으로 보냅니다.
http 8080으로 요청을 보내도, https로 리다이렉트 되는 것을 확인할 수 있습니다.
p.s. https://google.com:443 은 구글로 연결되지만, https:google.com:444는 연결되지 않습니다.
마찬가지로 http://google.com:80은 구글로 연결되지만, http://google.com:81은 연결되지 않습니다.
https, http의 기본 포트 번호가 각각 443, 80이고, 이는 자동으로 생략되기 때문에
https://google.com:443 이 아닌 https://google.com으로 표시되고, 사용할 수 있는 것입니다.
이렇게 EC2 위에 구동된 서버에 접근하는 요청을
https로 연결하는 긴 여정이 끝났습니다.
두 편의 포스팅에 걸쳐 우리가 한 작업은 아래와 같습니다.
- 가비아에서 도메인을 구매
- 호스팅 영역을 생성
- 도메인의 네임서버를 AWS 호스팅 영역의 것으로 수정
- ACM에서 SSL 인증서를 발급
- 로드 밸런싱 타겟 그룹을 생성(EC2 인스턴스 IP 주소의 8080번 포트)
- 로드 밸런서를 만들어 https://domain.com의 443, http://domain.com의 8080번 포트에 대한 리스너를 추가
- 리스너 규칙을 추가해 http 요청을 https로 리다이렉트
- Health check 통과용 API를 만든 후, 타겟 그룹의 Health check 설정을 수정해 healthy 상태로 만들기
처음엔 길고 복잡하지만, 고작 2번 작업을 통해 익숙해지니
1시간이면 충분한 작업이 되었네요.
덕분에 Load balancer에 대한 이해도 깊어졌습니다.
질문이나 지적은 언제든 환영입니다.
긴 글 읽어주셔서 감사합니다!