AWS ELB, ASG

Siyun·2025년 2월 10일

aws

AWS

목록 보기

8/37

확장성과 고가용성

확장성 : 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미
1) 수직확장성 : 인스턴스의 크기를 확장 (t2.micro -> t2.large). DB(RDS, ElastiCache)와 같이 분산되지 않은 시스템에서 흔히 사용.
2) 수평확장성(탄력성) : 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법.(스케일 아웃. 줄어들면 스케일 인)
고가용성 : 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중이라는 것을 의미. 고가용성의 목표는 데이터센터의 손실에서 살아남는 것. 동일 애플리케이션의 동일 인스턴스를 다수의 AZ에 걸쳐 실행,

ELB(Elastic Load Balancer)

로드 밸런서는 서버 혹은 서버셋으로, 트래픽을 백엔드나 다운스트림 EC2인스턴스 또는 서버들로 전달하는 역할을 한다.
로드 밸런서는 인스턴스의 상태를 확인해 부하를 다수의 다운스트림 인스턴스로 분산한다.
클라우드 내 개인 트래픽과 공공 트래픽을 분리할 수 있다.
ec2 인스턴스들 앞에 ELB가 있고 사용자는 이를 거쳐야 EC2인스턴스 중 하나로 연결 가능하다.
AWS 로드밸런서는 자체 로드밸런서보다 ELB를 쓰는 게 확장성 면에서 좋다.
상태 확인은 포트와 라우트에서 이뤄진다. 보통 /health 엔드포인트로 상태확인을 요청하고 200 응답이 아니면 인스턴스 상태가 좋지 않다고 판단하고 그쪽으로 트래픽을 보내지 않게 된다.

로드밸런서 보안 그룹

유저는 http, https를 사용해 어디서든 로드 밸런서에 접근이 가능하다. 따라서 로드밸런서의 인바운드 규칙에서 http, https는 모두에게 허용하고 있다.
EC2 인스턴스의 인바운드 규칙은 http트래픽을 허용하되 소스는 로드밸런서의 보안그룹이 된다.
이렇게 함으로써 EC2인스턴스는 로드밸런서를 통과한 트래픽만을 허용하게 되어 강화된 보안 매커니즘을 갖게 된다.

ELB의 종류

1. Application Load Balancer(ALB)

http, https, WepSocket 에서 사용(7계층, HTTP전용 로드밸런서)
머신 간 다수 HTTP애플리케이션의 라우팅에 사용된다. 머신들은 대상그룹이라는 그룹으로 묶인다.
컨테이너와 ECS를 사용한다.
리다이렉트를 지원하기 때문에 HTTP에서 HTTPS로 트래픽을 자동 리다이렉트하려는 경우 로드밸런서 레벨에서 가능하다.
경로 라우팅을 지원한다.
-> URL 대상 경로에 기반한 라우팅이 가능하다. (/users와 /posts를 서로 다른 대상그룹에 리다이렉팅 할 수 있음.)
-> URL의 호스트 이름에 기반한 라우팅이 가능하다. (one.example.com & other.example.com)
-> 쿼리 문자열과 헤더에 기반한 라우팅이 가능하다. (example.com/users?id=123&order=false)
마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서이다.(도커와 ECS) 포트매핑기능이 있어 ECS인스턴스의 동적 포트로의 리다이렉션을 가능하게 한다.
ALB 하나만으로 다수의 애플리케이션을 처리할 수 있다.
정적 DNS 이름으로 외부에서 사용할 수 있다.

ALB의 대상 그룹(Target Groups)

EC2 인스턴스(오토 스케일링 그룹으로 관리될 수 있음) -> HTTP
ECS 작업 -> HTTP
람다 함수 -> HTTP요청이 JSON 이벤트로 바뀜.
IP주소 -> 꼭 사설 IP주소여야만 함.
ALB는 여러 대상 그룹으로 라우팅 할 수 있으며 상태 확인은 대상 그룹 레벨에서 이뤄진다.

요청의 클라이언트 ip가 로드밸런서에 도착하면 로드밸런서의 사설 ip주소가 출발지가 되어 EC2인스턴스로 도착하게 된다.클라이언트 ip를 알고싶다면 HTTP요청의 추가 헤더인 X-Forwarded-Port와 Proto를 확인하면 된다.

ALB 생성 실습

1. 인스턴스를 두 개 만들어준다. (인스턴스 생성 시 number of instances 를 2로 입력)

2. EC2 > Load Balancer > Create Application Load Balancer 에서 ALB를 선택해 로드밸런서를 생성한다.

3. 네트워크 매핑에서 로드밸런서를 배포할 곳과 AZ를 선택한다.

🚨여기서 AZ를 선택하면 AZ마다 Public IPv4를 부여받는다. (과금됨) EC2인스턴스가 있는 AZ를 해제하면 접속이 안되니 그 외는 필요에 따라 해제해준다.
ALB를 인터넷-facing으로 설정할 때는, 퍼블릭 서브넷에 배치되며, 이때 퍼블릭 IP 주소가 자동으로 할당된다.
때문에 과금이 되지 않으려면 Internal ALB을 사용한다. 이 경우, 외부에서 접근할 수 없으며, VPC 내에서만 트래픽을 처리한다.

4. 보안 그룹을 생성해 인바운드, 아웃바운드 룰을 정한뒤 할당한다.

인바운드에서 HTTP만 IPv4 어디서든 접속할 수 있게 해주었다.

5. 라우팅을 하기 위해 대상 그룹을 만든다.

인스턴스를 타겟으로 하고 대상 그룹의 프로토콜은 HTTP로 설정한다.

원하는 인스턴스를 선택해 포트 80에 pending상태로 추가하고 대상 그룹을 생성한다.

6. 다시 로드밸런서 생성에서 대상그룹을 선택하고 생성을 마무리한다.

7. 생성된 로드밸런서 확인하기

ALB가 생성된 것을 확인할 수 있다. DNS 이름을 복사해 url창에 입력하면 ALB를 통해 EC2인스턴스의 HTTP 접속이 가능하다.

8. 로드밸런서를 통해서만 대상그룹에 접속할 수 있게 하기

대상그룹 EC2인스턴스들에 적용된 보안그룹에서 기존 HTTP 접속 규칙을 삭제하고 새로 HTTP 규칙을 추가해 소스를 로드밸런서의 보안그룹으로 적용하면 된다.

로드밸런서 리스너 규칙 실습

1. 리스너 확인하기

EC2 > Load Balancer 로 가서 ALB를 선택 > Listener > HTTP:80 클릭

2. 리스너 규칙 추가하기

기본 규칙은 모든 요청을 ALB의 대상 그룹으로 보내라는 것이다. Add rule을 눌러 규칙을 추가할 수 있다.

규칙의 이름을 설정하고 다음을 누르면 조건을 추가할 수 있다.
조건은 이 규칙 요청에서 무엇을 필터링할 것인가를 말한다.
호스트 헤더, 요청 경로, HTTP 요청 메소드(GET, POST 등), 소스 IP, 쿼리 스트링, HTTP 헤더로 필터링할 수 있다.

현재는 path를 선택해 /error로 요청이 오면 필터링 할 수 있게끔 해보겠다.

다음으로 Actions을 설정해 필터링 된 요청을 어떻게 처리할 지 선택할 수 있다.

Forward to target groups :대상 그룹이 두 개 이상인 경우 특정 대상 그룹으로 전달할 수 있다.
Redirect to URL : 특정 URL로 리디렉션. 호스트, 경로, 쿼리 지정가능
Return fixed response : 고정된 응답 반환.
여기서는 고정된 응답으로 문자열을 404 번호와 함께 반환해주었다.

다음으로 규칙 우선순위를 설정할 수 있다.
우선순위 값은 1-50000 까지 설정할 수 있고 숫자가 클수록 우선순위가 낮다.
하나의 요청이 여러 규칙에 일치한다면 그 중 우선순위가 높은 규칙이 적용된다.

규칙 생성을 완료하고 로드밸런서의 DNS주소에 /error를 입력하면 규칙이 트리거되어 설정해둔 값을 반환하는 것을 확인했다.

2. Network Load Balancer

TCP, TLS(secure TCP), UDP
네트워크 4계층 로드밸런서
초고성능 환경을 구축할 때 사용. 지연시간을 최소로 유지하면서 초당 수백만 건의 요청을 처리. (ALB 지연시간 400ms vs NLB 지연시간 100ms)
AZ별로 하나의 고정 IP를 갖는다. 탄력적 IP주소를 각 AZ에 할당하여 사용할 수 있다.
여러개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다.
프리티어에 포함되지 않음.

NLB의 대상그룹

EC2 인스턴스들
IP 주소 (하드코딩된 사설 IP)
ALB
NLB 대상 그룹이 수행하는 '상태 확인'은 TCP, HTTP, HTTPS 프로토콜을 지원한다.

NLB 생성 실습

1. EC2 > Load Balancer에서 새로운 로드밸런서 생성

2. NLB 선택 후 서브넷 모두 선택

서브넷은 AWS로부터 할당된 IPv4주소를 선택했는데, 이는 곧 NLB를 위해 활성화하는 각 AZ마다 고정된 IPv4 주소를 받는다는 뜻.
탄력적 IP가 있다면 AZ마다 이를 선택해도 됨.

3. 보안그룹 생성 후 적용하기 (추천사항)

인바운드 HTTP 80을 허용한다.

4. 리스터 설정하기

프로토콜과 포트를 선택하고 해당 포트를 통한 트래픽을 전송할 대상 그룹을 선택해준다.

5. 대상그룹 생성하여 적용하기

대상그룹을 생성할때 프로토콜은 TCP 포트는 80으로 설정한다.(NLB이기 때문)
Health check는 상태 확인 패킷을 보낼 수 있는 애플리케이션의 프로토콜에 따라 선택한다. (지금은 HTTP선택)
Advanced health check settings에서 Healthy threashold는 2, timeout을 2, interval은 5로 임의로 설정.
대상 그룹 생성 후 적용하고 NLB 생성을 마친다.

6. 대상그룹의 보안그룹에서 인바운드룰 추가

NLB로부터 HTTP 트래픽을 허용하는 인바운드룰을 추가한다.
소스를 NLB의 보안그룹으로 설정하면 된다.

3. Gateway Load Balancer

네트워크 3계층인 IP 프로토콜에서 자동
보안, 침입 탐지, 방화벽에 특화되어 있다.
배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
-> 소스에서 발생한 트래픽이 GWLB를 지나 써드파티 가상어플라이언스들(대상 그룹)에서 방화벽과 같이 필터링 작업이 수행되고 통과되면 다시 GWLB로 트래픽이 간 다음 애플리케이션(목적지)로 도달할 수 있다.
투명 네트워크 게이트웨이 : VPC의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과한다. 대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드밸런서가 된다.
6081번 포트의 GENEVE 게이트웨이를 사용하면 바로 GWLB가 됨.

가상 어플라이언스(Virtual Appliance, VA)는 특정 목적을 위해 사전 구성된 가상 머신(VM) 이미지. 일반적으로 운영 체제(OS), 애플리케이션, 필요한 라이브러리 및 설정이 미리 포함되어 있어, 사용자가 별도로 설치하거나 설정할 필요 없이 빠르게 배포하고 실행할 수 있다.
EX) AMI

GWLB의 대상 그룹

EC2 instances
IP주소들 (사설IP)

ELB의 Sticky Sessions(고정세션)

로드 밸런서(ELB)가 특정 클라이언트의 요청을 항상 같은 백엔드 인스턴스로 라우팅하도록 설정하는 기능
로그인 정보나 사용자 데이터를 유지해야 하는 웹 애플리케이션에서는 같은 서버로 연결을 지속하는 것이 중요하기에 필요함
클라이언트에서 로드밸런서로 요청의 일부로서 쿠키가 전송되는데 쿠키가 만료되기 전까지 세션이 유지됨.
고정성을 활성화하면 백엔드 EC2인스턴스 부하에 불균형을 초래할 수 있다.

🍪## 쿠키란?
고정세션에 두가지 쿠키가 있다.
1. 애플리케이션 기반 쿠키

사용자 정의 쿠키: 애플리케이션에서 생성되며 애플리케이션에 필요한 모든 사용자 속성을 포함할 수 있다. 쿠키 이름은 대상 그룹별로 개별적으로 지정한다.( AWSALB, AWSALBAPP, AWSALBTG 이름은 사용하면 안됨)

애플리케이션 쿠키 : 로드밸런서 자체에서 생성된다. 이름은 AWSALBAPP
2. 기간 기반 쿠키

로드밸런서에서 생성되는 쿠키로 이름이 AWSALB이다.

특정 기간을 기반으로 만료되며 그 기간이 로드밸런서 자체에서 생성되는 것이다. 애플리케이션 기반의 쿠키는 애플리케이션에서 기간 설정이 가능하다.

고정세션 활성화 실습

EC2 > Target groups에서 대상그룹을 선택 > Actions > Edit target group attributes 선택
Attributes에서 Stickness 선택

고정성 타입과 기간을 1초~7일로 설정가능하다.
앱 기반 쿠키를 선택하면 쿠키이름을 지정해야 한다.

Cross-Zone(교차영역) 로드밸런싱

AZ에 상관없이 여러 AZ의 인스턴스에 부하를 균등 분배
교차영역 로드밸런싱을 사용하지 않고 요청을 분산하면 각 AZ의 탄력적 로드밸런서 노드의 대상 그룹 인스턴스로 부하가 분산된다.

ALB의 교차영역 로드밸런싱

기본으로 활성화되어 있다. (대상 그룹 설정에서 비활성화 할 수 있다.)
데이터를 다른 AZ로 옮기는데 비용이 들지 않는다.

NLB, GWLB의 교차영역 로드밸런싱

기본적으로 비활성화되어 있다.
활성화하려면 비용을 지불해야 한다. AZ 사이에서 데이터를 옮기려면 비용이 들기 때문.

교차영역 로드밸런싱 활성화 실습

로드밸런서를 선택하고 Attributes를 확인해 Cross-zone load balancing이 켜져있는지 확인한다.
비활성화된 로드밸런서를 선택하고 Edit load balancer attributes를 선택해 Target selection configuration의 Cross-zone load balancing을 활성화해준다.
활성화 되었는지 확인한다.

ALB의 교차영역 로드밸런싱 비활성화 실습

1.원하는 대상그룹의 속성 편집 > Target selection configuration에서 교차영역 로드밸런싱을 상속받아 활성화하거나 끌 수 있다. 끄면 해당 대상그룹에서만 꺼지게 된다.

SSL/TLS

SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화해준다. (전송중 암호화=in-fllight encryption)
데이터는 네트워크를 이동하는 중에 암호화되고 송신자와 수신자 측에서면 이를 복호화할 수 있다.
SSL은 '보안 소켓 계층'을 의미하고 연결을 암호화하는 데 사용한다.
TLS는 새로운 버전의 SSL로 '전송 계층 보안'을 의미한다.
최근엔 TLS 인증서가 주로 사용되는데 많은 사람들이 이를 여전히 SSL이라고 부름.
퍼블릭 인증서는 인증 기관(CA)에서 발급한다.
퍼블릭 SSL 인증서를 로드밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있다.
SSL 인증서에는 만료 날짜가 있어 주기적으로 갱신해 인증 상태를 유지해야 한다.

로드밸런서에서 SSL

로드밸런서 작동
1) 사용자가 HTTPS를 통해 접속한다.
2) 로드밸런서에서는 내부적으로 SSL 종료를 수행한다.
3) 백엔드에서는 HTTP로 EC2인스턴스와 통신한다.(암호화되지 않은 채로, VPC로 이동하는 트래픽은 안전함)
로드밸런서는 X.509인증서(SSL또는 TLS 서버인증서)를 사용
ACM(AWS Cerificate Manager)에서 인증서들을 관리함.
원한다면 내가 가진 인증서를 ACM에 업로드할 수 있음.
HTTP 리스너를 구성할 때 반드시 'HTTPS'리스너로 해야 한다.
👉 기본 인증서를 지정
👉 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수 있음.
👉 클라이언트는 SNI(Server Name Indication)을 써서 접속할 호스트의 이름을 알릴 수 있음.
👉 원하는 대로 보안 정책을 지정할 수 있다.

SNI (Server Name Indication)

여러개의 SSL인증서를 하나의 웹 서버(ALB or NLB)에 로드해 해당 서버가 여러 개의 웹사이트를 지원할 수 있게 함.
최초 SSL 핸드셰이크 단계에서 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.
👉 클라이언트가 접속할 웹사이트를 말하면 서버는 어떤 인증서를 로드해야 하는지 알 수 있다.
이는 새로 추가된 프로토콜로 ALB, NLB, CloudFront에서만 동작한다.

ALB와 NLB에서 SSL 인증서 사용 실습

ALB로 가서 리스너를 추가해준다.
프로토콜을 HTTPS로 설정하고 트래픽을 전달할 대상그룹을 선택한다.
리스너 보안 설정에서 SSL 보안 정책을 설정할 수 있다.

보안 정책은 필요에 따라 구버전의 SSL을 적용할 수 있고 인증서를 ACM, IAM, 외부에서 가져올 수 있다.
외부에서 가져올 시 개인 키, 인증서, 인증서 체인을 붙여넣어 ACM으로 가져올 수 있다.

NLB에서도 비슷하게 하면 된다.

Connection Draining (연결 드레이닝)

ALB, NLB에서는 등록 취소 지연이라고 부른다.
인스턴스가 등록 취소, 혹은 비정상적인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 in-filght(활성) 요청을 완료할 수 있도록 하는 기능.
연결이 드레이닝 되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다.
시간을 1초~5분으로 정할 수 있고 0으로 설정하여 연결 드레이닝 기능을 비활성화 할 수 있다.
짧은 요청의 경우 낮은 값으로 설정하는 것이 좋다. (1초 미만의 요청이면 30정도로 설정)

ASG(Auto Scaling Group)이란?

웹사이트나 애플리케이션을 배포할 때 예상보다 로드가 많아질 경우 클라우드에서 EC2인스턴스 생성 API호출을 통해 서버를 빠르게 생성하고 종료할 수 있다.
위 과정을 자동화하고 싶으면 ASG를 생성
ASG는 무료

ASG의 목표

스케일 아웃 (증가한 로드에 맞춰 EC2인스턴스 추가)
스케일 인 (감소한 로드에 맞춰 EC2인스턴스 제거)
ASG에서 실행되는 EC2인스턴스의 최소, 최대개수 보장을 위해 매개변수 정의
로드밸런서와 페어링하는 경우 ASG에 속한 모든 EC2인스턴스가 로드밸런서에 연결된다.
한 인스턴스가 비정상이면 종료하고 이를 대체할 새 EC2인스턴스를 생성한다.

AWS에서 ASG

ASG내 인스턴스의 최소 용량(개수), 희망 용량, 최대 용량 설정.
인스턴스 개수가 희망 용량을 벗어나면 이는 스케일 아웃이 된다.
로드밸런서에 연결했다면 로드밸런서가 상태를 확인해 ASG에게 전달한다. -> 비정상(unhealthy)이라 판단한 EC2인스턴스를 ASG가 종료할 수 있다.
인스턴스 속성을 기반으로 ASG를 생성하려면 Launch Template를 생성해야 한다.
CloudWatch 경보(Alarms)를 기반으로 ASG를 스케일 인 및 스케일 아웃할 수 있다.
CloudWatch에서 모니터링하는 지표(평균 CPU나 사용자 지정 지표)중 사용자가 선택한 지표가 일정 수준 이상이면 트리거를 발동해 스케일링을 유발한다.

ASG 생성 실습

1. EC2 > Auto Scaling groups > Create Auto Scaling group 선택

2. 적용할 런치 템플릿을 만들어 적용한다.

런치 템플릿 만들기
AMI와 인스턴스 유형 등을 설정한다.
user data에 아래 내용을 입력한다.
Apache 웹 서버(httpd)를 설치하고 부팅시 자동 실행되게끔 설정하고 실행하는 내용이다.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

3. 인스턴스 시작 옵션을 선택한다.

기본 VPC와 AZ들을 선택한다.

4. 옵션 사항 선택

로드밸런서를 연결할 수 있다.

로드밸런서를 연결했다면 상태체크에서 ELB의 상태체크를 사용할 수 있다.

5. 스케일링 설정

원하는 인스턴스 용량을 설정할 수 있다.
나머지 옵션은 우선 건너뛰고 생성한다.

EC2 > ASG에서 생성한 ASG를 선택해 Activity > Activity history 에서 인스턴스의 생성 현황을 볼 수 있다.
EC2 인스턴스를 삭제하면 희망 용량을 1로 설정했기 때문에 자동으로 한 개의 EC2인스턴스가 새로 생성된다.

ASG - 스케일링 정책

동적(Dynamic) 스케일링

목표추적

설정이 간단하다.
CPU 사용률과 같은 ASG에 대한 메트릭을 정의하고 해당 메트릭을 유지하도록 스케일링한다. (ex. cpu 사용률이 약 40%를 유지하도록 스케일링)
메트릭 이상 CPU 사용량이 발생하면 클라우드 와치 알람이 발생한다. (CloudWatch alarms에서 확인. 부하 테스트는 EC2인스턴스에 stress를 설치해 stress -c 4 를 입력하면 가능.)

단순/단계 스케일링

CloudWatch alarm이 트리거가 되어 스케일링.
단계 스케일링은 클라우드와치의 경보값에 따라 단계적으로 스케일링함.
단순 스케일링은 클라우드와치의 경보에 따라 바로 스케일링

예약(Scheduled) 스케일링

알려진 사용 패턴을 기반으로 스케일링 예상
예를 들어 금요일 오후 5시에 최소 용량을 10으로 늘리기.
시작기간과 끝나는 기간, 희망/최소/최대 용량을 선택할 수 있음.

예측(Predictive) 스케일링

지속적으로 부하를 예측한 다음 미리 예약을 시작한다.
반복되는 패턴이 있을 때 좋다.
머신러닝을 기반으로 한다.
ASG는 자동으로 과거 부하를 분석한 다음 예측치를 생성해 예측치를 기반으로 스케일링 작업을 한다.

다운로드량(네트워크 사용량), 연산량(CPU사용량), 요청량 등에 따라 스케일링 정책을 설정한다.

과거 부하를 기반으로 예측하는 것에 체크하고 지표를 설정해 인스턴스당 CPU사용률을 설정할 수 있다.

스케일링 쿨다운

인스턴스를 추가하거나 제거할 때 기본적으로 5분(300초) 쿨다운 시간에 들어간다. 메트릭이 안정화되도록 하고 새로운 인스턴스가 적용되어 새로운 메트릭이 어떻게 변할지를 지켜보는 시간을 가지기 위해서이다.
기본 쿨다운이 효과가 없으면 사용하지 않는다.

스케일링 정책 실습

ASG에서 스케일링하고 싶은 ASG를 선택해 Automatic scaling을 선택해 정책을 추가한다.

Siyun

공부 기록

이전 포스트

AWS EFS(Elastic File System)

다음 포스트