1 장. 확장성 및 고가용성의 개념
01) 확장성
- 애플리케이션 / 시스템이 조정을 통해 더 많은 양을 처리할 수 있는 능력을 의미.
02) 확장성의 종류
- 수직 확장성
- 수평 확장성 = 탄력성
- 확장성은 연결되어 있지만 고가용성과는 다릅니다!
03) 수직 확장성
- 인스턴스의 크기를 확장하는 것.
- 예를 들어, 애플리케이션이 t2.micro에서 실행되고 있을 때, 수직 확장을 하면 t2.large에서 실행됨.
- 수직 확장은 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용됨.
- RDS, ElastiCache는 수직 확장이 가능한 서비스.
- 일반적으로 수직 확장의 한계가 있음. (hardware limit)
04) 수평 확장성
- 애플리케이션의 인스턴스 / 시스템 수를 늘리는 것.
- 수평 확장을 하는 것은 분산 시스템이 있다는 것을 의미함.
- 웹이나 현대 애플리케이션은 대부분 분산 시스템으로 이루어져 있다!
- Amazon EC2와 같은 클라우드 제공 업체 덕분에 쉽게 수평 확장이 가능.
05) 고가용성
- 일반적으로 수평 확장과 함께 사용되는 개념.
- 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중인 것을 의미.
- 고가용성의 목표: 데이터 손실에서 살아남는 것. 따라서 센터 하나가 멈춰도 계속 작동이 가능하게끔 하는 것.
- 고가용성은 수동적일 수 있음. (ex. RDS Multi AZ)
- 고가용성은 능동적일 수 있음. (ex. 수평 확장)
❓ High Availability & Scalability for EC2
- 수직 확장: 인스턴스의 크기를 늘림 (= scale up / down)
- From: t2.nano - 0.5G of RAM, 1 vCPU
- to: u-12tb1.metal – 12.3 TB of RAM, 448 vCPUs
- 수평 확장: 인스턴스 수 증가 (= scale out / in)
- Auto Scaling Group
- 로드 밸런서
- 고가용성: 같은 애플리케이션을 실행하는 인스턴스를 다양한 AZ에 걸쳐 실행
- Auto Scaling Group multi AZ
- Load Balancer multi AZ
2장. 일라스틱 로드 밸런싱 (ELB)
01) Load balancing 이란?
- Load Balance는 트래픽을 여러 서버(예: EC2 인스턴스)에 다운스트림으로 전달하는 서버입니다.
02) 로드밸런서를 왜 사용할까?
- 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서.
- 애플리케이션에 단일 액세스 지점(DNS)을 노출함.
- 다운스트림 인스턴스의 장애를 원활하게 처리함.
- 인스턴스에 정기적으로 상태 확인 체크를 수행함.
- 웹 사이트에 대한 SSL 종료(HTTPS)를 제공함.
- 쿠키로 정적 분배를 적용함.
- 영역 간 고가용성
- 공용 트래픽과 개인 트래픽을 분리함.
03) 그렇다면 왜 Elastic Load Balancer를 사용할까?
- Elastic Load Balancer는 관리형 로드 밸런서이다.
- AWS가 관리하며, 어떠한 경우에도 로드 밸런서가 작동할 것을 보장.
- AWS는 업그레이드, 유지 관리 및 고가용성을 책임짐.
- AWS는 몇 가지 일부 구성 놉(configuration knobs)도 제공함.
- 자체 로드 밸런서를 설정하는 것은 비용이 적게 들지만, 많은 노력이 필요함. 따라서 Elastic Load Balancer를 사용하는 것이 좋음.
- 다수의 AWS 서비스들과 통합되어 있음.
- EC2, EC2 Auto Scaling Groups, Amazon ECS
- AWS Certificate Manager (ACM), CloudWatch
- Route53, AWS WAF, AWS Global Accelerator
- Elastic Load Balancer는 애플리케이션에 사용 가능한 정적 DNS 이름을 제공함
04) Health Checks
- 로드 밸런서에서 Health Checks(상태 확인)은 매우 중요함.
- 이를 통해 로드 밸런서가 전달하는 트래픽을 처리할 수 있는 인스턴스의 가용성을 파악할 수 있음.
- 상태 확인은 특정 포트와 라우트(/health가 일반적)에서 수행됨.
- 응답이 200(OK)가 아니면 해당 인스턴스는 건강하지 않은 상태임.
05) 로드 밸런스 보안 그룹
3장. AWS 로드 밸런서의 4가지 유형
01 ) 애플리케이션 로드 밸런서 (ALB)
- AWS는 4가지의 관리형 로드 밸런서를 제공한다.
- 더 많은 기능을 가지고 있는 새로운 세대의 로드 밸런서를 사용하는 것이 좋다.
- 일부 로드 밸런서는 내부(private) 또는 외부(public) ELB로 설정할 수 있다.
1. Classic Load Balancers (v1)
- AWS에서 지원하지 않으며 시험에서도 관련 레퍼런스는 모두 제외됨!
- HTTP, HTTPS, TCP, SSL (secureTCP)
2. Application Load Balancer (v2)
(1) 계층 및 용도
- 계층: Layer 7 (HTTP 전용 로드 밸런서).
- 용도: HTTP 애플리케이션의 트래픽을 여러 서버(target group)에 분산시키는데 사용. 이는 웹 애플리케이션과 서비스가 원활하게 운영될 수 있도록 함.
- 대상 그룹이라는 그룹으로 여러 서버들이 묶임.
- 원리: 애플리케이션당 여러 개의 Classic Load Balancer(클래식 로드 밸런서)가 필요.
(2) 기술 지원
- 지원 프로토콜: HTTP/2와 WebSocket을 지원하여, 실시간 양방향 통신 및 향상된 웹 퍼포먼스 제공.
- 로드 밸런싱 기능: 경로 라우팅 및 리디렉션(예: HTTP에서 HTTPS로) 지원, 고급 라우팅 옵션 제공.
- 포트 매핑 기능: ECS의 동적 포트로 리디렉션 지원
(3) 역할 및 기능
- 다수의 HTTP 애플리케이션 간 트래픽 라우팅에 특화.
- 동일한 EC2 인스턴스상의 다양한 애플리케이션(ex. 컨테이너) 간 효율적인 로드 밸런싱 가능.
(4) 적합한 환경
- 마이크로서비스 및 컨테이너 기반 애플리케이션에 이상적.
- Docker, Amazon ECS와의 통합으로 높은 확장성 및 유연성 제공.
(5) 등록 대상
① 대상 그룹 (EC2, ECS, 람다, IP)
• EC2 인스턴스 (Auto Scaling Group으로 관리될 수 있음) - HTTP
• ECS 작업 (ECS 자체에서 관리됨) - HTTP
• 람다 함수 - HTTP 요청이 JSON 이벤트로 변환됨
• IP 주소 - 프라이빗 IP 여야 함
② 대상 그룹(target groups)에 따른 라우팅:
• URL 경로를 기반으로 라우팅
(example.com/users & example.com/posts)
• URL 호스트 이름 기반으로 라우팅
(one.example.com & other.example.com)
• 쿼리 스트링, 헤더를 기반으로 라우팅
(example.com/users?id=123&order=false)
④ HTTP 기반 트래픽
- ALB는 여러 대상 그룹으로 라우팅할 수 있으며, 헬스 체크는 대상 그룹 수준에서 이루어진다.
(6) 알아야 되는 내용
• 고정된 호스트 이름 (XXX.region.elb.amazonaws.com)
• 애플리케이션 서버는 클라이언트의 IP를 직접적으로 보지 못함.
• 클라이언트의 실제 IP는 헤더 X-Forwarded-For에 삽입됨.
• 포트(X-Forwarded-Port)와 프로토콜(X-Forwarded-Proto)도 얻을 수 있음.
3. Network Load Balancer (v2)
(1) 계층 및 트래픽 처리
- 계층: Layer 4, HTTP/HTTPS의 상위 계층인 Layer 7보다 낮은 계층에서 작동.
- 트래픽 처리: TCP 및 UDP 트래픽을 인스턴스로 직접 전달. 이는 특히 실시간 데이터 처리와 같이 연결 지향적 트래픽 관리가 필수적인 애플리케이션에 적합함.
(2) 성능 및 지연 시간
- 처리 능력: 초당 수백만 건의 요청을 처리할 수 있는 고성능 로드 밸런서. 이는 대규모 트래픽을 처리해야 하는 애플리케이션에 이상적임.
- AWS 무료 사용 계층에 포함되지 않음. 고성능과 고급 기능 제공을 위한 비용이 발생함.
(3) 대상 그룹
- EC2 인스턴스 및 프라이빗 IP 주소를 포함한 여러 대상 유형을 지원함.
(4) 헬스 체크
-
- TCP, HTTP, HTTPS 프로토콜을 지원하는 헬스 체크를 통해 로드 밸런서는 백엔드 시스템의 상태를 지속적으로 모니터링하고, 장애가 발생한 시스템에서 트래픽을 자동으로 제거하여 높은 가용성을 유지함.
(5) IP 관리
- 고정 IP 주소: 가용 영역(AZ) 당 하나의 고정 IP 주소를 제공. 이는 네트워크 구성과 관리를 단순화함.
- 탄력적 IP(Elastic IP) 할당: 각 가용 영역에 탄력적 IP를 할당할 수 있음. 이는 특정 IP 주소를 화이트리스트에 추가해야 하는 경우 유용함.
(6) 비용
- AWS 무료 사용 계층에 포함되지 않음. 고성능과 고급 기능 제공을 위한 비용이 발생함.
(7) 대상 그룹
- EC2 인스턴스 및 프라이빗 IP 주소를 포함한 여러 대상 유형을 지원함.
(8) 헬스 체크
- TCP, HTTP, HTTPS 프로토콜을 지원하는 헬스 체크를 통해 로드 밸런서는 백엔드 시스템의 상태를 지속적으로 모니터링하고, 장애가 발생한 시스템에서 트래픽을 자동으로 제거하여 높은 가용성을 유지함.
4. Gateway Load Balancer
(1) 목적 및 사용 사례
- 배포 및 확장: AWS에서 제공하는 제3자 네트워크 가상 어플라이언스의 플릿을 쉽게 배포하고 확장할 수 있도록 설계됨.
- 사용 사례 예시: 방화벽, 침입 탐지 및 방지 시스템, 딥 패킷 검사, 페이로드 조작 등의 네트워크 보안 및 모니터링 서비스에 주로 사용됨.
(2) 작동 계층 및 기능
- 계층: Layer 3 - IP 패킷을 처리하는 네트워크 계층에서 작동, 기존 로드 밸런서보다 더 낮은 수준에서 운영됨.
- 네트워크 게이트웨이: 투명한 네트워크 게이트웨이로서 작동, 단일 진입점 및 출구점을 제공함.
- 로드 밸런싱: 가상 어플라이언스로의 트래픽을 효율적으로 분산시키는 역할을 함.
(3) 프로토콜 및 포트
- GENEVE 프로토콜: 포트 6081에서 GENEVE 프로토콜을 사용하여, 가상 네트워크 장치 간의 통신을 용이하게 함.
(4) 대상 그룹
- 대상: EC2 인스턴스 및 프라이빗 IP 주소를 대상으로 함. 이는 보안 및 네트워크 구성의 일관성을 보장함.
🔗 Sticky Sessions (Session Affinity) - 고정 세션
- 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것.
- 로드 밸런서 뒤에 있는 동일한 인스턴스로 항상 리디렉션 되도록 고정 세션을 구현할 수 있음.
- 이는 Classic Load Balancer, Application Load Balancer 에서 설정할 수 있음.
- 고정 세션에 사용되는 "쿠키"는 클라이언트에서 로드 밸런서로 요청의 일부로서 전송되는 것임. 만료 기간을 포함하고 있음.
- 사용 사례: 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용.
- 고정 세션을 활성화하면 백엔드 EC2 인스턴스에 부하 불균형이 발생할 수 있음.
Cookie Names
Application-based Cookies 애플리케이션 기반 쿠키
- Custom cookie
- Generated by target
- 애플리케이션에서 필요한 사용자 정의 속성을 포함할 수 있음
- 쿠키 이름은 각 대상 그룹마다 개별적으로 지정해야 함
- AWSALB, AWSALBAPP 또는 AWSALBTG는 사용 불가 (ELB에서 사용되기 때문)
- Application cookie
- Generated by the load balancer
- Cookie name is AWSALBAPP
Duration-based Cookies 기간 기반 쿠키
- Generated by the load balancer
- ALB인 경우엔 AWSALB, CLB인 경우엔 AWSELB
'AWS > DVA-C02' 카테고리의 다른 글
06. RDS + Aurora + ElastiCache (0) | 2024.05.18 |
---|---|
04. EC2 인스턴스 스토리지 (0) | 2024.05.16 |
03. EC2 솔루션스 아키텍트 Associate 레벨 (0) | 2024.05.16 |
02. EC2 기초 (0) | 2024.05.16 |
01. IAM (Identity and Access Management) (0) | 2024.05.16 |