ELB
ELB는 Elastic Load Balancer의 약자로, AWS 상에서 쓰이는 로드 밸런서라고 생각하면 된다. 그 종류는 CLB, ALB, NLB, GWLB로 총 4가지이고, CLB -> GWLB 순으로 나왔다.
로드밸런서를 쓰는 이유는 여러 가지가 있는데, 제일 중요한 2가지가 있다.
- 부하를 다수의 다운스트림으로 분산시켜주기 위해
- 단일 액세스 지점으로 여러 인스턴스로 전달하기 위해
이 2가지 때문에 쓰는 경우가 제일 많고, 여러 특별한 경우에는 다른 이유로 쓰기도 한다. 그리고 이렇게 쓰면서 부가적인 효과도 있는데, 로드밸런서가 쿠키 관리를 해주고, SSL 설정, 각 인스턴스의 헬스체크, 퍼블릭 트래픽과 프라이빗 트랙픽 분리, 여러 영역에 걸친 고가용성을 만들어 준다.
CLB
CLB는 우리가 흔히 배우는 로드밸런서 기초의 본판이다. HTTP, HTTPS, TCP, SSL, Secure TCP 지원해준다. 이것은 AWS에서 제일 처음 나오기도 했고, ALB와 NLB를 통해 네트워크 계층적으로 분리시켰기 때문에 AWS에서도 쓰지말라고 하는 로드밸런서이다. (그래도 지원은 해준다. Deprecated 상태라고 보면 될 것 같다.)
ALB
HTTP(/2), HTTPS, WebSochet Protocol를 지원해준다. 지원해주는 것을 보면 알 수 있듯이 7계층 로드밸런서이다. URL 기반으로 라우팅하기 좋고, 컨테이너 기반 로드밸런서로 자주 쓰인다. 타겟 그룹은 EC2 Intances, ECS tasks, Lambda, IP address(private IPs)가 있다. 어플리케이션 계층에서 작동하므로 404Response, 401Response 등 커스텀해서 응답을 만들 수도 있다.
NLB
TCP, SSL, Secure TCP, UDP를 지원해준다. 이것도 마찬가지로 프로토콜을 보고 4계층인 것을 확인할 수 있다. 타겟 그룹은 IP address(private IPs), EC2 Intances, ALB이며, 외부 가용영역 하나당 고정된 IP를 노출 시킬 수 있다. 이는 정책 상 매우 중요한 부분이었는데, 기업의 정책에 고정된 IP를 사용해야 하는 규제같은 것이 있기도 하고, 다른 보안적인 부분에서도 변동하는 IP보다 고정된 IP를 선호했기 때문이다.
여담으로 CLB, ALB는 호스트만 존재했기 때문에 고정 IP가 있는 NLB가 나오길 손꼽아 기다렸다는 사람들이 많다고 한다.
NLB는 ALB보다 빠른 속도를 자랑한다. (ALB - 400ms / NLB - 100ms) 그리고 타겟그룹을 보면 ALB라고 적혀있는 것을 볼 수 있는데, 이는 NLB를 만들고 그 뒤에 ALB를 붙이는 형식이라고 생각하면 쉽다. 즉, NLB가 로드밸런싱한 것을 ALB가 받아서 또 나누는 형식이다.
GWLB
최신에 나온 로드밸런서인데, 이건 3계층 프로토콜로 IP에 사용된다. IP address(private IPs), EC2 Intances, Third Party Alliance가 타겟 그룹이다. 얘를 쓰는 이유가 뭐냐면, 네트워크 들어올 때부터 보안적으로 체크하려고 쓴다. GW는 게이트웨이를 뜻하는데, 인터넷에서 3계층부터 요청을 확인하는 것이다. Third Party Alliance를 보안 인스턴스로 지정하여 사용하고 들어오는 모든 트래픽은 보안 인스턴스가 확인하여 모니터링한다고 한다.
고정 세션
동일 사용자가 동일 인스턴스에 요청하게 하는 것이다. 옛날에 로그인 세션 때문에 이렇게 고정세션이 필요한 경우가 많았다. 지금이야 JWT나 공용 세션 등을 사용해서 로그인 문제는 많이 해소 되었다하지만 고정 세션을 사용해야하는 상황이 생기기도 한다.
고정세션을 사용하면 단점은 EC2 인스턴스 균형이 무너질 수 있고, 일부 인스턴스는 고정 사용자가 생길 수 있다는 점이다.
쿠키
쿠키는 어플리케이션 기반 쿠키와 로드밸런서 기반 쿠키로 나뉜다. 어플리케이션에서 커스텀해서 쿠키를 사용해도 되는데, 로드밸런서에는 예약된 이름으로 쿠키를 가지고 있기 때문에 조심해야 한다. AWSALB, AWSALBAPP, AWSALBTG는 사용해선 안된다.
그리고 로드밸런서 상의 쿠키는 특정 기간을 기반으로 유지되고, AWS Console 에서 설정가능하다.
Cross Zone LB
Cross Zone 설정을 활성화하면 AZ당 여러 인스턴스가 불균형하게 있어도 로드밸런서가 알아서 EC2의 수에 맞게 각 AZ로 request를 분배해서 전달한다. 각 로드밸런서 별로 비용과 디폴트 설정이 다르다.
- CLB는 디폴트로 켜져있지않고 AZ간의 비용 X
- ALB는 무조건 켜져있고, AZ 간의 비용 X
- NLB는 디폴트가 켜져있지 않고 AZ간의 비용이 발생
SNI
다중 SSL 설정을 위한 것이라고 생각하면 된다. 로드밸런서로 묶인 인스턴스들이 각 다른 호스트를 쓸 수도 있다. 근데 로드밸런서는 앞단에서 사용자에게 하나의 endpoint를 지원하면 각 인스턴스의 호스트네임에 따라 SSL 설정을 할 수가 없게 된다. 그 때문에 SNI가 나왔다. SNI는 여러 타겟그룹에 대한 SSL 인증서를 관리하고 해당 SSL을 통해서 올바른 대상 그룹인지를 확인시켜주는 역할을 한다. AWS에서 설정할 수 있는 곳은 Cloud Front, ALB, NLB 이다. 다만, 모든 클라이언트가 SNI를 지원하지 않는다고 하니 주의해서 사용하자.
등록 취소 지연
한 인스턴스가 등록 중, 취소 중, 오류 등 정상적으로 동작하지 않을 때, 인스턴스에게 정상적인 활동을 할 수 있게끔 시간을 주는 것을 말한다. 일정 시간 뒤, 재연결 시도해주는 것과 같다.
그 시간을 드레이닝이라고 부르고 드레이닝 중에는 해당 인스턴스로는 요청을 보내지 않는다. 드레이닝 일어나지 않을려면 지연시간 설정을 0초로 하면 된다.
ASG
Auto Scaling Group의 약자로 해당 그룹 내에서 서비스 인스턴스들이 잘 동작하게끔 자동적으로 관리하는 것이라 보면 된다. ASG는 메모리 풀과 비슷하게 기본/최대/최소 인스턴스 수를 지정하고 트리거링 되는 방식을 설정하면 해당 설정에 따라 자동으로 스케일인/아웃을 수행한다.
이 그룹의 장점은 인스턴스를 그냥 추가하는 것만이 아니라 로드밸런서에 자동으로 새 인스턴스 등록까지 해주고 다른 서비스들과 연동하여 트리거링되는 부분들을 기본적인 메트릭뿐만 아니라 커스텀할 수 있게 만들어 준다는 것이다. 커스텀 할 때는 CloudWatch 서비스를 이용한다.
스케일링 정책
스케일링 정책은 어떤 메트릭을 통해 트리거링할지 정해주는 룰인데, 주로 CPU 사용률과 request per instance를 본다. 예를 들면 인스턴스 당 1분에 10000requests씩 받게끔 설정, CPU 평균이 50% 넘어가면 새로운 인스턴스를 하나 더 생성하도록 하는 설정 등이 있다.
그리고 이런 기본적인 정책이 아니라 커스텀 메트릭을 기반으로 하는 것은 어플리케이션에 연결된 유저의 수가 1000 이상일 경우, 어플리케이션 인스턴스 추가, 검색 api를 사용한 횟수가 초당 200이 넘을 경우 인스턴스 추가 등이 있다.
스케일링 정책 종류
타겟 트래킹 스케일링
해당 타겟의 기본적인 메트릭을 활용하여 사용하는 것을 말한다.
심플/스텝 스케일링
클라우드 알람을 설정해서 트리거링해서 사용하는 것을 말한다.
예약 스케일링
사용자 패턴을 보고 지정한 시간대나 일자에 인스턴스를 늘이거나 줄이는 것을 말한다.
예측 스케일링
시계열 데이터를 기반으로 과거를 보고 로드를 예측해서 스케일링을 해주는 것을 말한다.
스케일링 쿨다운
스케일링 활동 후에는 5분(디폴트설정) 스케일링 활동을 쉬는 것을 말한다. 지정한 시간만큼 쉴 수 있다. 이는 서비스 안정화를 위한 설정이고, 이 시간을 줄일려면 즉시 배포가능한 AMI를 설정하면 좋다. 각 AMI 설정도 올라가는데 빠르면 빠를 수록 더 쿨타임을 줄일 수 있다.
기타
- ASG는 무료로 바로 작성하면 되는데, 연결된 인스턴스나 ASG를 구성하는 자원 비용은 내야한다.
- 인스턴스 교체방식은 불량 인스턴스가 있으면 바로 종료시키고 새 인스턴스를 생성해서 쓴다.
- 좋은 메트릭 예제
- CPU 사용률 평균
- request per target
- 네트워크 입출력량(처리량)
- CloudWatch를 통한 커스텀 메트릭
