프로젝트에서 내가 설정해야하는 부분이고,
이 역할을 하기 위해 AWS 공부를 시작했다.
우선 ELB에 대해 알아보기 전, Scalability와 High Availability에 대해 알아보자.
Scalability(확장성) :
- 수직 확장성(Vertical Scalability)
- 수평 확장성(Horizontal Scalability)
수직 확장성이란?
인스턴스의 크기를 확장하는 것
ex) 프로그램 개발 중, 갑자기 일이 많아짐
-> 유능한 5년차 경력직 개발자 채용
수평 확장성
-> 신입 개발자 5명 채용
수직 확장성은 보통 데이터베이스와 같이 분산되지 않은 시스템에서 사용한다.
High Availability(고가용성) 이란?
애플리케이션 또는 시스템을 적어도 둘 이상의 AZ나 데이터 센터에서
가동 중이라는것을 의미한다.
고가용성의 목표: 데이터 센터에서의 손실에서 살아남는 것
-> 둘 이상으로 가동하고, 센터 하나가 멈춰도 계속 작동이 가능하게끔
Scale out/ in
Scale out은 인스턴스의 수가 늘어나는 것, 즉 수평 확장성을 의미하고,
Scale in은 인스턴스의 개수를 줄이는 것을 의미한다.
이제 로드 밸런싱에 대해 알아보자.
로드 밸런싱
첫 번째 유저가 접속을 시도하면, EC2 인스턴스에 접근하는 것이 아니라, ELB로 접근이 된다.
이후에 두 번째 유저가 접속을 시도하면 2번째 인스턴스,
이런식으로 EC2 인스턴스의 부하를 ELB를 통해 분산시킬 수 있는것이다.
ELB는 관리형 로드 밸런서다.
AWS가 관리하며, 어떤 경우에도 작동할 것을 보장해준다.
ELB Health Checks
헬스체크는 해당 인스턴스의 작동이 올바르게 되고 있는지의
여부를 확인하기 위해 사용된다.
만약 제대로 작동중이 아니라면, 해당 인스턴스로는 트래픽을 보낼 수 없기 때문에, 로드 밸런서에서 상태 확인은 매우 중요하다.
위의 그림과 같이, 포트 혹은 라우터에서 체크 할 수 있다.
만약, 200 응답이 오지 않을 경우 unhealthy로 기록 되며,
로드 밸런서는 그쪽으로 트래팩을 보내지 않는다.
AWS에는 4개의 로드밸런서가 있다.
1. Classic Load Balancer -> 이제 안 씀
2. Application Load Balancer (ALB)
- HTTP, HTTPS, WebSocket 프로토콜 지원
- Network Load Balancer(NLB)
- TCP, TLS, secure TCP, UDP 프로토콜 지원
- Gateway Load Balancer(GWLB)
- 네트워크층에서 작동함
- 즉, 3계층과 IP 프로토콜에서 작동함
하나씩 알아보자.
Application Load Balancer
7계층, 즉 HTTP 전용 로드 밸런서
- 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산함
- HTTP/2 , WebSocket 지원
- redirect 지원해줌
-> HTTP -> HTTPS 트래픽 자동 리다이렉션 가능 - URL 대상 경로에 기반한 라우팅 가능
ex) example.com/users <- 이런식으로 경로를 지정하고,
이 uri 요청이 들어올 때 특정 EC2 인스턴스로 보낼 수 있음 - 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서임
대상 그룹이란?
EC2 인스턴스가 대상 그룹이 될 수 있음.
정리: ALB는 여러 대상 그룹으로 라우팅 할 수 있으며, 상태 확인은 대상 그룹 레벨에서 이뤄진다
NLB, GWLB는 나중에...! 우선은 프로젝트를 위해
우리가 사용하는 AWS 서비스들을 빨리 익혀야한다
Sticky Sessions
고정 세션을 실행하는 것
쿠키를 이용해, 특정 사용자가 다시 접속했을 때, 같은 EC2 인스턴스로 보내는 방법.
- 고정성을 사용하면 EC2 인스턴스 부하에 불균형을 초래할 수 있음
- 일부 인스턴스는 고정 사용자를 가질 수 있음
잘 생각하고, 필요시에 도입하자
크로스존 로드밸런싱
그림을 보면서 간단하게 이해해보자.
이 그림은 크로스존 로드밸런싱을 사용하지 않은 그림이다.
Client는 각각의 ELB에 50%씩 부하를 분산한다.
이후 AZ1에서 EC2 인스턴스가 2개 존재하기에,
각각의 EC2 인스턴스는 25만큼의 부하를 받는다.
반면, AZ2는 8개의 EC2 인스턴스가 존재하기에 6.25의 부하를 받는다.
이번에는 크로스존 로드밸런싱을 사용한 그림을 보자.
Client는 ELB에 각각 50%만큼의 부하를 분산했지만,
총 EC2 인스턴스는 10개이기에 각각의 인스턴스에 10만큼의 부하가 전달되는걸 확인할 수 있다.
크로스존 로드밸런싱을 사용할 지 말지는 프로젝트의 구성에 따라 다를 거 같다.
-> ALB에서는 크로스존 로드밸런싱이 기본으로 활성화되어있음 (비활성화 가능)
-> 데이터를 다른 가용 영역으로 옮기는데 비용이 들지 않음
-> 원래 돈 들지만, ALB는 크로스존 로드밸런싱이 기본으로 활성화되어 있기 때문에 AZ 간의 데이터 이동에 비용이 들지 않음
SSL 인증서
클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화해줌.
데이터는 네트워크를 이동하는 중에는 암호화되고, 송신자와 수신자 측에서만 이를 복호화 할 수 있음.
SSL은 '보안 소켓 계층'을 의미하고 연결을 암호화하는데 사용된다.
TLS는 새로운 버전의 SSL이다. '전송 계층 보안'을 의미
요즘에는 TLS를 많이 쓰는데, 사람들은 TLS를 SSL이라고 부름
SSL은 Certificate Authorities(CA) 에서 발급해줌.
SSL 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있음.
SSL 인증서에는 만료 날짜가 있어 주기적으로 갱신해줘야함.
ACM이란?
AWS 인증서 관리자
로드밸런서에서의 SSL 동작 과정
1. 먼저 사용자가 HTTPS를 통해 접근한다.
2.인터넷을 통해 우리 로드 밸런서에 접속하면, 로드 밸런서에서 내부적으로 SSL종료를 수행한다.
3. 백엔드에서는 HTTP로 EC2 인스턴스와 통신한다. (VPC로 이동하는 트래픽은 프라이빗 네트워크를 사용해 안전함)
로드 밸런서는 X.509 인증서를 사용하는데, 이걸 SSL 서버 인증서라고 부른다.
AWS에서는 이 인증서를 관리할 수 있는 ACM이 존재함.
ACM이란?
AWS 인증서 관리자
- HTTP 리스너를 구성할 때 반드시 'HTTPS' 리스너로 해야함
- 기본 인증서를 지정해줘야함
- 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수 있음(ALB, NLB 한정)
SNI (Server Name Indication)
여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있게 해줌
-> 클라이언트가 대상 서버의 호스트 이름을 지정하도록 함
그림으로 이해해보자.
ALB에 두 개의 SSL 인증서 보유
1.Client가 www.mycorp.com에 접속하고 싶다고 https 요청을 보냄. (SSL Handshake 시작)
2. ALB는 mycorp.com에접속하고 싶다는걸 파악하고 해당하는 SSL 인증서 로드
3. 클라이언트와 ALB간의 SSL 연결이 설정된 후, ALB는 요청을 적절한 TargetGroup으로 라우팅 함 (이 과정에서 SSL 연결 종료)
ASG도 같이 정리하려 했는데, 양이 많아서 따로 정리하려고 한다.
끝!
