IT STUDY LOG
[AWS] 07. 수평확장 본문
# 학습 목표
- Cloud와 Deployment의 의미를 각각 알고, 서비스를 남에게 배포할 수 있다.
- 클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
- 애플리케이션 배포가 어떻게 변화되어 왔는지 이해할 수 있다.
- AWS의 각 서비스가 어떤 목적에 부합하는지 이해할 수 있다.
- S3의 목적과, 정적 웹 사이트 배포 방법을 이해할 수 있다.
- EC2의 주요 용어를 이해할 수 있다. (AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
- EC2의 인스턴스 시작/중지/종료에 대해 이해할 수 있다.
- RDS와 EC2에서의 MySQL 사용이 어떻게 다른지 이해할 수 있다.
- CloudFront의 목적을 이해할 수 있다.
- Auto Scaling의 특징 및 역할을 알 수 있다.
- 로드 밸런서 중 ELB, 그 중에서 Application Load Balancer의 목적을 이해할 수 있다.
- AWS 인프라 중 VPC에 대해서 이해할 수 있다.
- Route 53의 목적을 이해하고, 도메인을 연결해 HTTPS로 배포할 수 있다.
- 빌드 및 배포시 필요한 환경 설정을 할 수 있다.
- 배포 시 발생하는 문제를 이해하고 고칠 수 있다.
# 학습 내용
1. Auto Scaling Group
- 미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대 또는 축소할 수 있는 기술
- 클라우드가 제공하는 탄력성에 의해 만들어지고, 사용자의 요구 수준을 반영할 수 있는 기술
- Auto Scaling 이용 시 처리 요구량이 급등하는 시기(피크 워크로드)에 맞춰 새 리소스를 자동으로 추가, 환경 설정하므로 처리 요구량과 같은 리소스를 감소시켜 과잉 프로비전의 필요성이 줄어듦
> 프로비전(provision) : 필요한 컴퓨팅 리소스들을 필요한 곳에 배치하고 유휴 자원들을 다시 회수하는 일련의 작업들을 의미
Auto Scaling의 장점
동적 스케일링
- 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 가능
- 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업 가능
로드 밸런싱
- 오토 스케일링과 로드밸런서와 함께 사용하면 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배 가능하며 다수의 AZ에 분포된 EC2 인스턴스에 대한 워크로드도 자동으로 분배하도록 설정 가능하므로 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리할 수 있음
타겟 트래킹
- 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정
헬스 체크와 서버 플릿 관리
- EC2 인스턴스의 헬스 체크 상태 모니터링이 가능
- 헬스 체크 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체
서버 플릿
- 다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우 이들 일련의 EC2 서버 집합을 뜻함
- Auto Scaling은 적정 수준의 서버 플릿 용량을 유지하는 데 도움
(ex) 어떤 기업의 애플리케이션이 6대의 EC2 서버에서 실행 중일 때 6대 서버에 대한 헬스 체크 상태를 모니터링 하다가 특정 서버에 문제가 생기면 즉시 대응 조치 가능. 한 대 또는 그 이상의 서버가 다운 되면 Auto Scaling은 6대의 서버 인스턴스 처리 용량을 유지하기 위해 부족분만큼의 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지
EC2 Auto Scaling 활용 : 오직 EC2 서버라는 리소스만 대상으로 합는 오토 스케일링
시작 템플릿(Launch Configuration)
- 인스턴스 확장/축소 시 어떤 서버를 사용할 지 결정하는 것
- 시작 템플릿(AMI : 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보 가짐)을 사용해 시작
- 만약 시작 템플릿을 사용해 생성하지 않으려는 경우 "시작 구성"으로 생성 가능
> 시작 구성 : EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷. 사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성
Auto Scaling 그룹 생성
- 스케일업 및 스케일 다운 규칙의 모음
- EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책 포함
- Auto Scaling 그룹을 생성하기 위해서는 스케일링 정책 및 유형에 대해 숙지 필요
Scaling 유형
인스턴스 레벨 유지
- 기본 스케일링 계획
- 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정 가능
- 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정
수동 스케일링
- 기존 Auto Scaling 그룹의 크기를 수동으로 변경
- 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제해야하므로 해당 방식은 비추천
예측 스케일링
- 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있을 때 유용
(ex) 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가
동적 스케일링
- 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의
- CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 설정
- 스케일링 정책을 정의 할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 함
(ex) CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식
- 동적 스케일링 정책 종류
> 타겟 트랙킹 스케일링 정책 : 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표(custom metric)을 사용하여 타겟 값으로 설정
> 단순 스케일링 정책 : 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 증감(ex. CPU 활용지표가 80% 에 도달할 때 하나의 인스턴스를 추가하고, 40% 미만으로 떨어질 때 인스턴스 하나를 감소시키는 방식). 이때 쿨다운 기간이라는 새 인스턴스를 시작 혹은 정지 시키기 위한 대기 시간도 정의 가능
> 단계 스케일링 정책 : 단순 스케일링보다 단계 스케일링은 좀 더 세분화 해서 단계를 나누어 규칙을 추가 가능
인스턴스 삭제 정책
- 스케일다운 정책이 적용되면, EC2 인스턴스가 삭제되며, 서버를 셧다운 하는 것은 리소스 관리 측면에서도 꼭 필요
- 스케일다운 정책에서는 명확하게 몇 개의 인스턴스를 삭제할 것인지, 어떤 인스턴스를 먼저 셧다운 할 것인지 환경 설정을 통해 결정 가능
- 대표적인 인스턴스 삭제 정책
> 사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제. 가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크기 때문에 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점
> 시간 단위 과금이 임박한 서버를 삭제. 이 서버를 삭제하면 Auto Scaling의 특유 장점을 최대한 살려, 과금 부담 축소 가능
2. Elastic Load Balancing
로드 밸런싱이란?
1대의 서버로 구성된 경우
- 서비스 규모가 커지면 물리/가상 서버 한 대로는 모든 서비스를 수용하기 어려움
- 서버 한 대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생했을 때 정상적인 서비스를 제공 불가
2대 이상의 서버로 구성된 경우
- 서비스 가용성은 높아지나 각 서버의 IP 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 하며 이 때 로드 밸런서 사용
- 로드밸런싱(부하분산) : 로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고, 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산
- Elastic Load Balancing : AWS에서 제공하는 로드밸런싱
ELB란?
- Elastic Load Balancing
- 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산
- 등록된 대상의 상태를 모니터링 하면서 상태가 양호한 대상으로만 트래픽을 라우팅
ELB의 장점
고가용성
- ELB는 고가용성 아키텍처를 구현하는데 도움
- ELB는 다수의 EC2 인스턴스, 컨테이너 등에 트래픽을 분산 시키며 다수의 AZ에 배포된 EC2 인스턴스에 애플리케이션을 배포해 트래픽을 여러 AZ로 분산
- 하나의 AZ가 모두 다운 돼도 사용자의 애플리케이션은 문제 없이 실행 상태를 유지 가능
탄력성
- ELB의 최대 장점은 자동적 확장성
- 관리자는 인스턴스 추가 또는 삭제를 위한 어떤 수작업도 할 필요가 없으며 수동으로 할 작업 없음
안전성
- 통합 인증관리, SSL 복호화, 포트 포워딩 등 다수의 보안 기능을 제공
- 현대 웹사이트 운영자는 웹 애플리케이션 레벨에도 암호화 기법을 적용하며, 다수의 보안 정책을 제공
높은 처리량
- ELB는 트래픽 증가를 처리할 수 있도록 설계되었으며 초당 수백만 개의 요청을 로드 밸런싱 가능
- 갑작스럽고 변동이 심한 트래픽 패턴도 처리 가능
작동 방식
- 로드 밸런서는 클라이언트에 대한 단일 접점
> 클라이언트에서 오는 트래픽을 허용
> 하나 이상의 가용 영역에서 등록된 대상(EC2 인스턴스)으로 요청을 라우팅
> 등록된 타겟의 상태를 모니터링하고 정상 타겟으로만 트래픽이 라우팅 되도록 함
> 로드 밸런서가 비정상 타겟을 감지하면, 해당 타겟으로 트래픽 라우팅을 중단하며 다음 타겟이 다시 정상으로 감지되면 트래픽을 해당 타겟으로 다시 라우팅
- 리스너는 구성한 프로토콜 및 포트를 사용하여 클라이언트의 연결 요청을 확인
> 리스너에 대해 정의한 규칙에 따라 로드 밸런서가 등록된 타겟으로 요청을 라우팅하는 방법이 결정
> 각 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성
> 규칙에 대한 조건이 충족되면 작업이 수행되므로 각 리스너에 대한 기본 규칙을 정의해야 하며, 필요에 따라 추가 규칙을 정의 가능
- 각 타겟 그룹은 지정한 프로토콜과 포트 번호를 사용하여 EC2 인스턴스 같은 하나 이상의 등록된 타겟으로 요청을 라우팅
> 여러 대상 그룹에 타겟을 등록 가능
> 타겟 그룹 기준으로 상태 확인 구성 가능
> 로드 밸런서의 리스너 규칙에서 지정한 타겟 그룹에 등록된 모든 타겟에서 헬스 체크를 수행
ELB의 다양한 유형
Application Load Balancer
- OSI 모델의 레이어 7에 해당
- HTTP와 HTTPS를 지원
- 애플리케이션 로드 밸런서는 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여, 적용할 규칙을 결정한 다음 규칙 작업의 타겟 그룹에서 타겟을 선택
- 애플리케이션 트래픽의 콘텐츠를 기반으로 다른 타겟 그룹에 요청을 라우팅하도록 리스너 규칙을 구성 가능
- ALB에서는 헤더 수정이 가능(ex. X-Forwarded-For 헤더에 클라이언트 IP주소를 넣듯 필요한 정보를 헤더에 설정)
- ALB의 호스트 기반 라우팅을 통해 HTTP 헤더의 Host 필드에 따라 클라이언트 요청을 라우팅 할 수 있고, 경로 기반 라우팅을 통해 HTTP 헤더의 URL 경로에 따라 클라이언트 요청을 라우팅 가능
Network Load Balancer
- TCP 로드 밸런서라고도 부르며 OSI 모델의 레이어 4에서 작동
- 로드 밸런서가 연결 요청을 받으면 기본 규칙의 타겟 그룹에서 대상을 선택하며 리스너 구성에 지정된 포트에서 선택한 타겟에 대한 TCP 연결을 열려고 시도
1) TCP 트래픽
- TCP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택
- 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 타겟에 라우팅될 수 있음
- 각 TCP 연결은 연결 수명 동안 하나의 타겟에 라우팅
2) UDP 트래픽
- 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택
- UDP 흐름은 소스와 목적지가 동일하기 때문에 수명이 다할 때까지 일관되게 단일 타겟으로 라우트
- 서로 다른 UDP 흐름에는 서로 다른 소스 IP 주소와 포트가 있으므로 다른 타겟으로 라우팅 가능
로드 밸런서 체계
- 로드 밸런서를 생성할 때 로드 밸런서를 내부 로드 밸런서 또는 인터넷 경계 로드 밸런서로 생성할지 여부를 선택
인터넷 경계 로드 밸런서
- 퍼블릭 IP 주소를 가지며 인터넷 경계 로드 밸런서의 DNS 이름은 노드의 퍼블릭 IP 주소로 공개적으로 확인이 가능
- 인터넷 경계 로드 밸런서는 인터넷을 통해 클라이언트의 요청을 라우팅 가능
내부 로드 밸런서
- 프라이빗 IP 주소만 가지며 내부 로드 밸런서의 DNS 이름은 노드의 프라이빗 IP 주소로 공개적으로 확인이 가능
- 내부 로드 밸런서는 로드 밸런서를 위한 VPC에 액세스하여 클라이언트의 요청만 라우팅
- 인터넷 경계 및 내부 로드 밸런서는 모두 프라이빗 IP 주소를 사용하여 대상으로 요청을 라우팅하므로 대상이 퍼블릭 IP 주소 없이도 내부 또는 인터넷 경계 로드 밸런서에서 요청을 수신 가능
- 애플리케이션에 여러 계층이 있는 경우 내부 및 인터넷 경계 로드 밸런서를 모두 사용하는 아키텍처를 설계 가능
다중 AZ의 활용
- AZ가 고가용성을 위한 기본 구조이므로 Auto Scaling과 ELB를 활용해 애플리케이션을 구현할 때는 가능한 다중 AZ를 기반으로 할 것을 권장
- ELB가 트래픽을 AZ간에 균등하게 배분하므로 AWS 생태계를 기반으로 서비스를 구현할 때 다중 AZ 구조 활용이 적합
다중 AZ의 문제점과 해결 방안
문제점
- 동기화 지연: 다중 가용 영역을 사용할 경우, 각 가용 영역에 있는 복제된 인스턴스 간의 동기화에 일정한 지연이 발생 가능하며 데이터베이스 또는 기타 복제된 서비스에서 데이터의 일관성을 보장이 어려울 수 있음
- 비용: 다중 가용 영역을 사용하면 인스턴스와 데이터를 여러 가용 영역에 중복하여 유지해야 하므로 비용이 더 많이 발생
- 복잡성: 다중 가용 영역을 사용하면 각 가용 영역에서 인스턴스와 관련된 리소스(예: 가용 영역 간 로드 밸런싱, VPC 피어링 등)를 구성 및 관리해야 하는 추가적인 복잡성이 발생
해결방안
- Cross Zone Load Balancing : 각 로드 밸런서 노드가 활성화된 모든 가용 영역의 등록된 인스턴스 간에 요청을 고르게 분산. 활성화된 각 가용 영역에서 동일한 수의 인스턴스를 유지해야 할 필요성을 줄이고 하나 이상의 인스턴스 손실을 처리하는 애플리케이션의 기능을 향상. 요청 로드의 불균형이 리전의 사용 가능한 모든 인스턴스에 분산되어 오작동하는 클라이언트의 영향이 감소
- Sticky Session : 클라이언트가 쿠키를 지원하는 경우 로드 밸런서가 사용자의 세션을 특정 대상에 바인딩하도록 지정. 세션 중에 사용자로부터 들어오는 모든 요청이 동일한 대상으로 전송되므로 클라이언트에게 지속적인 경험을 제공하기 위해 상태 정보를 유지하는 서버에 유용. Application Load Balancer는 기간 기반 쿠키와 애플리케이션 기반 쿠키를 둘 다 지원하며, 스티키 세션은 대상 그룹 레벨에서 활성화
# References
챗 GPT
Elastic Load Balancing의 작동 방식 - Elastic Load Balancing
Elastic Load Balancing의 작동 방식 로드 밸런서는 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 등록된 대상(예: EC2 인스턴스)으로 요청을 라우팅합니다. 또한, 로드 밸런서는
docs.aws.amazon.com
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html
Configure cross-zone load balancing for your Classic Load Balancer - Elastic Load Balancing
Configure cross-zone load balancing for your Classic Load Balancer With cross-zone load balancing, each load balancer node for your Classic Load Balancer distributes requests evenly across the registered instances in all enabled Availability Zones. If cros
docs.aws.amazon.com
https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/sticky-sessions.html
Application Load Balancer에 대한 고정 세션 - Elastic Load Balancing
Application Load Balancer에 대한 고정 세션 기본적으로, Application Load Balancer는 선택한 로드 밸런싱 알고리즘에 따라 각 요청을 등록된 대상으로 독립적으로 라우팅합니다. 한편, 고정 세션 기능(세션
docs.aws.amazon.com
'devops bootcamp 4 > 클라우드 서비스 운영' 카테고리의 다른 글
| [AWS] 08. 보안 (0) | 2023.04.18 |
|---|---|
| [AWS] 08. 서비스 노출 (0) | 2023.04.17 |
| [AWS] 06. VPC (0) | 2023.04.17 |
| [AWS] 05. RDS 관련 개념 (0) | 2023.04.14 |
| [AWS] 04. 스토리지 (0) | 2023.04.14 |
