전 글에서 다 못 다뤘던
로드 밸런서에 대해 정리해보겠다.
#0 Sticky Sesstions👥
Sticky Sesstions는 고정 세션을 실행하는 것으로
로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다.
(2개의 EC2 인스턴스와 3개의 클라이언트가 있는 ALB와 같은 것)
위의 그림으로 흐름을 설명하자면 1번 클라이어트가 요청을 생성해 첫 번째 EC2 인스턴스를 통과하면 로드 밸런서에서 두 번째 요청을 실행할 때 동일한 인스턴스로 이동함을 뜻하고 애플리케이션 밸런서가 모든 EC2 인스턴스 전반으로 모든 요청을 확산하는 것과는 다른 동작이다.
2번 클라이언트에서는 ALB가 두 번째 인스턴스와 통신하면 동일한 인스턴스로 이동하고 3번째 클라이언트 또한 마찬가지로 동작한다..! (그리고 이동작들은 CLB와 ALB에서도 설정 가능)
...
이 원리에 관해선 쿠키라는 것이 있는데
클라이언트 → 로드 밸런서로 '요청의 일부'로서 전송되는 것이다.
=> 쿠키가 만료되면 클라리언트가 다른 EC2로 리디렉션 된다는 것.
세션이 만료되면 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결된다.
(⚠️주의 : 고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다.)
<🍪 쿠키란 무엇일까? - Sticky Sesstions의 2가지 유형의 쿠키>
1. Apllication-based Cookies(애플리케이션 기반 쿠키🍪) :
애플리케이션 기반 쿠키는 애플리케이션에서 기간을 지정할 수 있다.
- 커스텀 쿠키
타켓을 대상으로 만든 커스텀 쿠키로 애플리케이션에서 생성되고
애플리케이션에 필요한 모든 커스텀 속성을 포함할 수 있다.
+) 쿠키 이름은 각 target group별로 개별적으로 지정해야 하는데 ELB에서 사용하는 AWSALB, AWSALBTG같은 이름은 사용X
- 어플리케이션 쿠키
로드 밸런서에서 자체에서 생성.
그리고 ALB의 쿠키 이름은 AWSALBAPP이다.
2. Duration-Based Cookies(기간 기반 쿠키🍪) :
로드 밸런서에서 생성되는 쿠키로 (ALB에서는 이름이 AWSALB, CLB에서는 AWSELB)
특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성되는 것이다.
#1 Cross-Zone Load Balancing(교차 영역 밸런싱)🔀
그림과 같이 EC2가 아주 불균형한 상태의 두 개의 가용영역이 있는데 1번째 방식을 먼저 예시를 들어보자면 클라이언트는 로드 밸런서에 접속하는데 Cross-Zone Load Balancing(교차 영역 밸런싱)을 쓰면, 각각의 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배한다. 클라이언트가 트래픽의 절반을 첫 번째 ALB 인스턴스로 보내고 나머지 절반을 다른 쪽으로 보냈다고 해도 ALB는 받는 트래픽을 10개의 EC2 인스턴스 모두에 전달한다. (가용 영역은 상관 X)
=> 인스턴스 개수가 총 10개니까 각각의 인스턴스가 트래픽의 10%를 할당받는 것이다.
2번째 방식은 영역을 교차하지 않고 부하를 분산하는건데 이렇게 하면 Elastic Load Balancer node의 인스턴스로 분산된다.
=> Cross-Zone Load Balancing(교차 영역 밸런싱)이 아니기 때문에 가용영역별로 동일한 트래픽을 보내서 그 안에 들어있는 인스턴스의 개수는 고려대상이 아니어서 위와 같이 2개인 경우 각 인스턴스가 트래픽의 25%씩 할당받는 것이다.
=> 만약 이렇게 가용 영역마다 EC2 인스턴스의 개수가 다르다면 특정 영역에 있는 EC2 인스턴스에게 좀 더 많은 트래픽이 할당될 것이다..!
...
이런걸 고려해서 방식을 선택하면 된다. 정답은 없고 쓰임새에 따라 선택하면 👍👍
+) 애플리케이션 로드 밸런서(ALB)는 Cross-Zone Load Balancing(교차 영역 밸런싱)이 기본으로 활성화되어 있다.
target group 설정에서 비활성화할 수 있고 데이터를 다른 가용 영역으로 옮기는데 비용이 들지 않는다.
#2 SSL/TLS 인증서
실제로 훨씬 복잡하지만
지금은 아주 간단하게 개념정도로 요약해서 정리해보려고 한다.
SSL 인증서란?📜
클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화해준다.
이를 전송 중 암호화(in-flight)라고 한다. 데이터는 네트워크를 이동하는 중에는 암호화되고, 송신자와 수신자 측에서만 이를 복호화할 수 있다. SSL은 '보안 소켓 계층'을 의미하고 연결을 암호화하는데 사용한다.
TLS 인증서란?📜
새로운 버전의 SSL로 'Secure Socket Layers(전송 계층 보안)'을 의미한다.
(최근에는 TLS 인증서가 주로 사용되는데 계속 SSL로 부르는 사람이 많아서 중복하여 인지하고 있으면 편하다.)
Public SSL은 인증 기관(CA)에서 발급한다. 인증기관에는 Comodo, GoDaddy, GlobalSign...등이 있고 Public SSL 인증서를 로드 밸런서에 추가하면 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있다! 그리고 SSL 인증서는 만료 날짜가 있어서 주기적으로 갱신해야한다.
...
그렇다면 SSL은 로드 밸런서에서 어떻게 동작할까?🤔
<로드 밸런서에서 SSL 동작 원리>
먼저 사용자가 HTTPS(인터넷)를 통해 접속하면 로드밸런서에서는 내부적으로 SSL 종료(SSL Termination)을 수행한다. 백엔드에서는 암호화되지 않은 상태로 HTTP로 EC2 인스턴스와 통신하지만 VPC로 이동하는 트래픽은 private 네트워크를 쓰기 때문에 안전하게 보호된다.
로드 밸런서는 SSL 혹은 TLS 서버 인증서라고 하는 X.509 인증서를 사용하는데 이 인증서들을 관리해주는 AWS ACM(AWS 인증 관리자)라는게 있으니 알고 있어야 한다. (우리가 가진 인증서를 ACM에 업로드할 수 도 있다)
그리고 HTTP Listener를 구성할 때 반드시 'HTTPS" 리스너로 해주어야 하고 기본 인증서를 지정해줘야 한다. 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수도 있고 클라이언트는 SNI(서버 이름 지정)라는 걸 써서 접속할 호스트의 이름을 알릴 수도 있다.
+) AWS 상에서 로드 밸런서 생성 후, 세부 고급 설정에 들어가면 리스너 설정 따로 할 수 있으니 참고
<SNI란?>
SNI는 중대한 문제의 해결책으로 많이 쓰이는데 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해서 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있게 해준다.
동작 방식은 아래와 같다.
ALB가 있고 두 개의 Target Group이 있는데 ALB는 어떤 규칙(호스트 이름..)에 의해 트래픽을 라우팅할 Target Group을 고를 것이다. ALB에는 각Target Group에 해당하는 두 개(Domain1.example.com, www.mycorp.com)의 SSL 인증서가 있는데 클라이언트는 ALB에 접속해서 www.mycrop.com에 접속하고 싶다고 하면 ALB는 그 의도를 파악하고 해당하는 SSL 인증서를 로드한다. 요청을 수행하려면 해당하는 인증서를 가져와서 트래픽을 암호화한 다음에 규칙에 따라 Target Group인 mycrop.com으로 요청을 재전송한다.
또한 다른 클라이언트가 ALB에게 Domain1.example.com에 접속을 요구한다면 역시 해당하는 SSL인증서를 가져와서 원하는 Target Group으로 연결시켜준다.
=> 이렇게 SNI, 즉 서버 이름을 지정해서 여러 개의 Target Group과 웹사이트를 지원할 수 있다. (다중 SSL인증서 사용)
+) Application Load Balancer(ALB), Network Load Balancer(NLB) 둘 다 여러 개의 SSL 인증서를 두고 리스너를 여러 개 지원할 수 있다.
#3 +) Deregistration Delay(등록 취소 지연)
애플리케이션 밸런서나 네트워크 로드 밸런서를 사용하는 경우, 인스턴스가 등록 취소 혹은 비정상적인 상태에 있을 때 인스턴스에 어느 정도의 시간을 줘서 in-flight요청(활성 요청)을 완료할 수 있도록 하는 기능이다.
인스턴스가 Draining되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는 거다.
그림을 보고 더 설명하자면 이렇게 EC2 인스턴스가 세 개 있는데 그 중 하나는 Draining 모드로 설정할 때 EC2 인스턴스에 이미 연결된 유저는 충분한 드레이닝 시간을 얻게될 것이고 기존 연결 혹은 기존 요청 등을 완료할 수 있을 것이다. 그리고 작업이 끝나면 모든 연결은 정지되고 만약 새로운 유저가 ELB에 연결하려고 하면 ELB는 기존의 EC2 인스턴스가 드레이닝 상태에 있으니 새로운 연결은 다른 EC2 인스턴스와 될 거라는 점이다.
그리고 1~3600초 사이의 값으로 시간 설정이 가능한데 값을 0으로 주면 드레이닝이 일어나지 않을 수 있다.
-> 짧은 요청일 경우엔 낮은 값으로 설정하면 좋다.
'AWS' 카테고리의 다른 글
| RDS (2) - Aurora에 대해 알아보자 (0) | 2024.03.23 |
|---|---|
| Auto Scaling Group과 RDS (1) (0) | 2024.03.22 |
| AWS Load balancer(로드 밸런서)에 대해 조금 더 자세히 알아보자 (1) (0) | 2024.03.20 |
| EBS에 대해 조금 더 자세히 알아보자 (0) | 2024.03.19 |
| Placement Group(배치그룹)과 ENI, Hibernate(최대 절전 모드)에 대해 알아보자 (0) | 2024.03.18 |