🔥 로드 밸런싱
서버와 유사하게 생각할 수 있으며, 실질적으로 트래픽을 백엔드, EC2인스턴스에 전달하는 역할을 합니다.
쉽게 말해 User가 모두 EC2인스턴스 앞에 있는 엔드포인트와 소통을 하는 것이고, 엔드포인트에서 다른 EC2에게 연결되어 사용이 됩니다.
로드 밸런싱은 주로 서버 부하를 다수의 인스턴스로 분산하기 위함입니다.
- 만약 장애가 발생을 하여도 단일 DNS로 전송되기 떄문에 장애를 쉽게 해결 가능합니다.
🔥 일래스틱 로드 밸런싱
로드밸런싱을 관리하는 로드밸런서 입니다.
AWS가 관리하며, 어떠한 경우에도 작동하는것을 보장합니다.
무조건 쓰는 것이 좋습니다. 자체 로드 밸런싱은 관리하기 어렵기 떄문입니다.
🔨 상태확인
로드 밸런싱이 연결된 EC2가 사용가능한지 확인하기 위해서 사용이 됩니다.
- 제대로 동작하는 EC2에게만 트래픽을 전송하기 떄문입니다.
상태확인은 포트와 라우터에서 이루어 지며 우리가 일반적으로 알고 있듯이 상태코드(200)으로 상태를 확인합니다.
만약 로드밸런서를 사용한다면 기존에 사용하는 EC2인스턴스의 보안 그룹은 조금은 달라져야 합니다.
기본적으로 사용자들이 연결하는 서버는 로드밸런스 이기 떄문에 로드밸런스의 보안그룹은 사용자들에게 맞게,
이후 EC2인스턴스는 로드밸런서의 트래픽만을 받아야 하기 떄문에 보안그룹을 로드 밸런서로 설정을 하면 됩니다.
🔥 클래식 로드 밸런스 (CLB) 실습
일단 기본적인 EC2를 만들어 줍니다.
이후 왼쪽의 메뉴에서 로드밸런스에 들어가 로드밸런스 생성을 클릭합니다.
로드 밸런스에는 총 4가지의 종류가 있습니다.
클래식 로드 밸런스를 선택해 줍니다.
- 나머지 로드 밸런스는 나중에 다루어 보도록 하겠습니다.
- 클래식은 이전의 버전이기 떄문에 잘 사용되지는 않습니다.
이름만 설정한 뒤에 기본 셋팅으로 설정 후 넘어갑니다.
이후 보안그룹에서는 새로운 보안그룹을 눌러서 보안그룹을 생성하겠습니다.
- HTTP 통신을 지원 할 것이기 떄문에 설정을 하고 모든 위치를 허용해 줍니다.
아마 에러가 발생을 하였을 것 입니다.
- 이는 HTTPS, SSl을 사용하지 않기 떄문에 뜨는 경고창이기 떄문에 TEST용으로 그냥 무시해 줍니다.
이후 상태 확인 규칙을 정해줍니다.
번역이 잘 되어있기 떄문에 그닥 어렵지 않고 단순히 Ping경로 만을 수정해 줍니다.
- 연결하는 EC2인스턴스에 존재하는 경로로 설정을 해야 하기 떄문에
/로 수정해 줍니다.
이후 계속 진행하여 생성해 주면 됩니다.
만약 로드밸런스의 Status가 OutOfService로 보이게 된다면 이는 두가지의 원인이 있습니다.
- 보안그룹 문제
-- 적합한 보안규칙을 설정하지 않아서 동작하지 않습니다.- 부트스크립트 문제
-- 문제가 있는 스크립트를 사용하여 EC2인스턴스가 중지되어있는 상태입니다.
이후 EC2인스턴스에 적용된 보안그룹에서 HTTP요청의 인바운드 규칙을 로드밸런스 IP로 수정해 주면 실습이 마무리 됩니다.
🔥 애플리케이션 로드 밸런스 (ALB)
HTTP전용 로드 밸런스로 머신 간 다수 라우팅에 사용이 됩니다.
일반적인 CLB는 분산되어 처리 하기 위해서는 애플리케이션 갯수와 동일 또는 더 많은 갯수의 CLB가 필요합니다.
하지만 ALB는 하나만으로도 다수의 애플리케이션을 처리할 수 있다는 장점이 있습니다.
기본적으로 클라이언트 IP는 X-Forwarded-For라고 불리는 헤더에 입력이 됩니다.
- X-Forwarded-Port, X-Forwarded-Proto는 포트, 프로토콜을 담고 있습니다.
즉 ALB에 트래픽을 전송하는 클라이언트의 정보를 EC2에서 보고자 한다면 HTTP요청에 있는 헤더값을 조회하면 됩니다.
🔥 애플리케이션 로드 밸런스 실습 (ALB)
이전과 마찬가지로 로드밸런스 생성에 들어가 애플리케이션을 등록 합니다.
기본적인 AZ들은 모두 설정하고 이후 Target그룹을 설정해야 합니다.
Target그룹은 다양하게 선택이 가능하며 지금은 인스턴스로 선택을 하면 됩니다.
이후 설정은 그대로 두고 success code만 200으로 설정해 줍니다.
이후 원하는 EC2타겟을 설정하고 기본 창으로 돌아와 Target그룹 설정을 마무리 합니다.
- 이 과정은 설명도 AWS CLI에 설명으로 잘 나와있고, 어려운 작업은 아니기 떄문에 단순하게 넘어갔습니다.
🔥 네트워크 로드 밸런스 (NLB)
TCP, UDP기반의 트래픽을 인스턴스로 보내는 밸런서입니다.
- 낮은 계층의 밸런서입니다.
초당 수백만건의 요청을 처리 가능하기 떄문에 매우 고성능이며, ALB에 비해서 지연시간이 짧습니다.
외부 가용 영역 당 1개의 고정 IP를 노출하기 떄문에 화이트 리스트에 추가할떄 유용하며, NLB자체의 IP가 아니라 일래스틱 IP할당을 지원합니다.
- 예를 들어, 애플리케이션 전용의 특정 IP를 지정하면, NLB가 해당 트래픽을 EC2인스턴스로 보내는 것입니다.
프리티어에 해당하지 않기 떄문에 이론으로만 알아보았습니다.
🔥 게이트웨이 로드 밸런서 (GWLB)
가장 최신의 로드밸런서로 방화벽과 동일한 역할을 합니다.
예를들면 User가 트래픽을 날리게 되면 해당 트래픽에 오점은 없는지 방화벽과 같이 검증을 하고 이후 애플리케이션으로 전송을 하게 됩니다.
- 트래픽을 검증할 떄에는 분산되어서 빠르게 처리가 됩니다.
가장 늦은 네트워크 계층에서 실행이 되는 특징이 있습니다.
- 사용할 떄에는 6081포트의 GENEVE프로토콜을 사용 하면 됩니다.
- 실습은 아직 너무 복잡하고 어려워서 진행을 하지 못하였습니다... ㅠ
🔥 ELB
🐾 고정 세션
고정성이라는 개념은 ALB에서 생각해 볼 수 있습니다.
3명의 클라이언트(A,B,C)와 ALB, 2개의 EC2(x,y)가 있다고 가정을 해 보겠습니다.
A라는 사용자가 처음에 ALB와 통신하여 x라는 EC2인스턴스에 접근을 하면, 이후에 A라는 사용자는 계속해서 x라는 인스턴스와 트래픽을 주고 받는 것을 고정 세션이라고 합니다.
- 이외에도 B,C또한 처음에 연결되는 EC2와 고정적으로 트래픽을 주고 받게 됩니다.
이 원리는 쿠키라는 것을 사용하여 이루어 지고, 이러한 쿠키가 만료가 되면 다른 EC2인스턴스로 리디렉션 됨으로써 이루어 집니다.
- 이게 다르게 보면 고정성이 활성화가 되면 특정 EC2인스턴스의 부하에 불균형을 유발하게 됩니다.
🚀 쿠키
고정 세션에는 총 2가지의 쿠기가 있습니다.
- 애플리케이션 기반 쿠키
해당 쿠키는 애플리케이션 기반의 쿠키이기 떄문에 사용자 정의 쿠키로 애플리케이션에서 생성 됩니다.
- 애플리케이션을 사용하는 사용자의 정보를 담고 있습니다.
- 기간 기반의 쿠키
해당 쿠키는 기간을 설정하여 만료되는 시간을 기록하고 있는 쿠키로 로드 밸런서 자체에서 생성이 됩니다.
- ALB에서는 이름이 AWSALB, CLB에서는 AWSCLB 입니다.
🔥 교차 영역 로드 밸런싱
굉장히 쉽게 이해가 가능한 로드 밸런싱 입니다.
하나의 클라이언트에 두개의 로드 밸런싱(A,B)이 있습니다.
두 로그 밸런싱은 모두 다른 가용영역에서 작동을 하고 있고
A같은 경우에는 2개의 EC2와 연결되어 있고, B같은 경우네는 8개의 EC2와 연결되어 있습니다.
이때 교차영역 로드밸런싱을 사용하고 있다고 가정을 하였을떄
클라이언트는 A에게 50%, B에게 50%를 전송하게 될 것이고 이러한 트래픽은 A가 관리하고 있는 EC2 2개에만 퍼지는 것이 아니라
전체 EC2의 갯수 = 10개에 고르게 분산되어 처리가 되게 되는 것을 교차 영역 로드 밸런싱 이라고 합니다.
- 정답도 없고 오답도 없기 떄문에 사용 사례에 따라 다르며, ALB에서는 항상 활성화 되어 있습니다.
- 비활성화 할 수 없습니다.
- 네트워크 로드 밸런싱은 비활성화 되어 있으며, 사용하고자 한다면 활성화하여 추가적인 비용을 지출 해야 합니다.
- 클래식 로드밸런싱은 비활성화 되어 있으며, 사용을 하고자 하여도 추가적인 비용이 없습니다.
활성화 하고 비활성화를 하는 방법은 로드밸런싱 대시보드에서 로드 밸런스를 선택하여 아래로 내려가 Cross-Zone Load Balancing을 조율하면 됩니다.
🔥 SSL 및 TLS 인증서
SSL 인증서를 활용하면 클라이언트와 로드 밸런서 사이에서 트래픽을 암호화 할수 있습니다.
- 이를
인-플라이트 암호화라고 부르기도 합니다.
즉 뎅리터가 네트워크를 통과하는 중에 암호화되고, 발신자 - 수신자 만이 복호화가 가능합니다.
SSl은 보안 소켓 계층을 뜻하며 연결을 암호화하는데에 사용 됩니다.
- 요즘에 주로 사용 되는 것은 TLS인증서 이지만, 부루는 것은 SSL이라고 많이 부른다고 합니다.
공용 SSL은 인증서는 인증 기관에서 발급이 되며, 일반적으로 웹사이트에 접속을 하게 되었을떄 초록색 자물쇠가 보인다면 트래픽이 암호화 되어있다는, 즉 SSL인증서를 사용한다는 것을 의미합니다.
🚀 로드 밸런스 관점
유저가 HTTPS를 통해 연결을 하게 되면 공용 인터넷을 통해 로드 밸런서와 연결이 됩니다.
이때 로드 밸런서는 내부적으로 SSL 인증서 종료라는 작업을 수행합니다.
그리고 백엔드에서는 EC2인스턴스와 소통을 하고 이떄 HTTP를 사용하기 떄문에 암호화는 되어있지 않지만 사설 네트워크인 VPC를 통해 전송을 하기 떄문에 어느정도의 안전성을 보장합니다.
🚀 SNI
한 웹서버에서 다수의 SSL인증서를 발급해 단일 웹 서버가 여러 개의 웹 사이트를 제공하도록 하는 문제를 해결 합니다.
이는 최신 프로토콜이며, 반드시 클라이언트가 초기 SSL 핸드쉐이크를 할떄에 대상 서버의 호스트 이름을 명시해야 합니다.
- 핸드 쉐이크 : 클라이언트와 서버가 통신을 하기 위해 서로 가용가능한 상태인지를 확인하는 행위를 말합니다.
이는 아무래도 최신 프로토콜이기 떄문에 모든 클라이언트가 지원을 하지는 못하고, 로드밸런스에서는 ALB 혹은 NLB 만이 지원을 하고 있습니다.
좀더 쉽게 설명을 하자면 ALB라는 로드 밸런서가 있고 2개의 EC2서버가 있습니다.
만약 클라이언트가 A에 해당하는 서버에 트래픽을 날리면 로드밸런서가 A에 해당하는 인증서를 부여해 주고
B에 트래픽을 전송하면 B에 해당하는 인증서를 전송해 주는 것으로 동작합니다.
🔥 ELB - 연결 드레이닝
사용하는 로드밸런스에 따라서 다르게 부릅니다.
CLB같은 경우에는 연결 드레이닝 이라고 부르며 NLB, ALB같은 경우에는 등록 취소 지연 이라고 부릅니다.
기능으로는 인스턴스가 비정상적인 상태에 있을떄 어느정도의 시간을 주어 다시 활성화 하는 요청을 완료 할 수 있는 기능입니다.
즉 특정 작업을 하고 있는 EC2인스턴스에 또다른 작업이 부여되지 않는 것으로 특정 작업을 하고 있는 EC2인스턴스를 드레이닝 이라고 합니다.
- 이는 따로 optional하게 설정 가능합니다
1부터 3600사이의 시간을 설정 가능하며 기본적으로는 5분 입니다.
- 만약 0으로 설정하면 비활성화 입니다.
짧은 요청일 수록 낮은 값으로 설정하는 것이 좋습니다.
- 1초보다 아주 적은 짧은 값인 경우에는 30초 정도로 설정을 하면 좋습니다.
