AWS Certified Solutions Architect Associate [5] 고가용성, 스케일링: ELB, ASG
1
고가용성과 확장성의 개요
확장성은 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미입니다.수직 확장성= Scale Up- 인스턴스의 크기를 확장하는 것
수평 확장성= Scale Out- 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 것
- 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 것
고가용성은 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중이라는 걸 의미합니다.고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것으로 센터 하나가 멈춰도 계속 작동이 가능하게끔 하는 것입니다.
ELB
로드 밸런싱 (load balancing)
- 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 합니다.
로드 밸런서를 사용하는 이유
부하를 다수의 다운스트림 인스턴스로분산하기 위해서 입니다.- 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 되고 다운스트림 인스턴스의 장애를 원활히 처리할 수 있습니다.
인스턴스의 상태를 확인할 수 있습니다.- SSL 종료도 할 수 있으니 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있습니다.
쿠키로 고정도를 강화할 수 있습니다.고가용성을 가집니다.클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있습니다.
ELB를 사용하는 이유
- 관리형 로드 밸런서
- AWS가 관리하며, 어떤 경우에도 작동할 것을 보장합니다.
- AWS가 업그레이드와 유지 관리 및 고가용성을 책임집니다.
- 로드 밸런서의 작동 방식을 수정할 수 있게 일부 구성
놉도 제공합니다
- 무조건 쓰는 편이 좋습니다.
- 자체 로드 밸런서를 마련하는 것보다 저렴하고 자체 로드 밸런서를 직접 관리하려면 확장성 측면에서 굉장히 번거롭기 때문입니다.
다수의 AWS의 서비스들과 통합되어 있습니다.
상태 확인 (health Checks)
- ELB가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용됩니다.
- 포트와 라우트에서 이뤄집니다.
4 종류의 로드 밸런서
-
Classic Load Balancer- TCP (4계층), HTTP (7계층)
- TCP (4계층), HTTP (7계층)
-
Application Load Balancer- 7계층
고정 호스트 이름이 부여됩니다.- 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못하며 클라이언트의 실제 IP는 X-Forwarded-For라고 불리는 헤더에 삽입됩니다.
- 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용되는데, 이러한 머신들은
대상 그룹으로 묶입니다. - 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를
분산합니다. HTTP/2와WebSocket을 지원합니다.리다이렉트도 지원합니다.경로 라우팅도 지원합니다- 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서로 이후 배우게 될 도커와 Amazon ECS의 경우에는 ALB가 가장 적합한 로드 밸런서가 될 겁니다.
port mapping기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 합니다.
-
Network Load BalancerTCP나UDP기반의 트래픽을 인스턴스로 전달하는 것대상 그룹- EC2 인스턴스
- IP 주소들 (프라이빗)
- ALB
- NLB의 기능을 활용해서 고정 IP를 가질 수 있기 때문입니다.
- 따라서 NLB 수준의 고정 IP를 가지면서 규칙과 같은 HTTP 관련 기능에 ALB를 활용할 수 있는 것입니다.
- 외부의 가용 영역 당 1개의 고정 IP를 노출합니다.
- 특정 IP를 화이트리스트에 추가할 때 유용하며
NLB 자체의 IP를 가져오는 대신일래스틱 IP 할당을 지원합니다
- 특정 IP를 화이트리스트에 추가할 때 유용하며
- 고성능이나 TCP 또는 UDP 수준의 트래픽을 원할 때 사용합니다.
- NLB는 AWS 프리 티어에 포함되지 않습니다.
-
Gateway Load Balancer
- 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용됩니다.
대상 그룹- EC2 인스턴스
- IP 주소들 (프라이빗)
- 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용합니다.
- 두 가지 기능
- 투명 네트워크 게이트웨이
- VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문입니다.
- 로드 밸런서
- 대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산합니다.
- 투명 네트워크 게이트웨이
- 6081번 포트의 GENEVE 프로토콜을 사용하세요. 바로 GWLB가 됩니다
일부 로드 밸런서들은 내부에 설정될 수 있어 네트워크에 개인적 접근이 가능하고 웹사이트와 공공 애플리케이션 모두에 사용이 가능한 외부 공공 로드 밸런서도 있습니다.
고정 세션 (세션 밀접성)
- 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것입니다.
- CLB, ALB
- 쿠키
- 클라이언트에서 로드 밸런서로 요청의 일부로서 전송되는 것입니다.
- 고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있습니다.
쿠키
- 애플리케이션 기반 쿠키
- 커스텀 쿠키
- 대상으로부터 생성된 사용자 정의 쿠키
- 애플리케이션 쿠키
- 로드 밸런서 자체에서 생성
- 커스텀 쿠키
- 기간 기반 쿠키
- 특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성
Cross-Zone 로드 밸런싱
- ALB
- 비활성화할 수 없습니다.
- 비용을 지불해야 합니다.
- AZ 간 데이터 전송에 관한 비용이 없습니다
- NLB
- 기본으로 비활성화입니다.
- 가용 영역 간 데이터 전송에 비용을 지불해야 합니다.
- CLB
- 기본으로 비활성화입니다.
- 활성화하면 가용 영역 간 데이터 전송에 비용이 발생하지 않습니다.
SSL/TLS
SSL 인증서를 사용하면 클라이언트와 로드 밸런서 사이에서 전송 중에 있는 트래픽을암호화할 수 있습니다.인-플라이트 암호화
SSL은 보안 소켓 계층을 뜻하며연결을 암호화하는 데에 사용됩니다.TLS는SSL의 최신 버전으로써전송 계층 보안을 의미합니다.- 요즘에 주로 사용되는 건 TLC 인증서, 사람들은 이를 여전히 SSL이라고 부르고 있습니다.
공용 SSL 인증서는 Comodo, Symantec GoDaddy, GlobalSign Letsencrypt 등의 인증 기관에서 발급됩니다.로드 밸런서와 연결된공용 SSL 인증서를 사용하면 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있습니다.
SSL 인증서에는 여러분이 설정한 유효 기간이 있고 인증을 위해 주기적으로 갱신되어야 합니다
SSL 인증
- 로드 밸런서가 X.509 인증서를 불러옵니다.
- SSL 혹은 TLS 서버 인증서라고 불리는 인증서입니다.
- AWS에서 ACM을 사용해 SSL 인증서를 관리할 수 있습니다.
- ACM은 AWS 인증서 관리자의 약자입니다.
- 여러분만의 인증서도 ACM에 업로드할 수 있습니다.
- HTTPS 리스너
- 기본 인증서를 지정해야 합니다.
- 다수의 도메인을 지원하는 인증서 선택 목록을 추가할 수 있습니다.
- 클라이언트는 SNI, 즉 서버 이름 표시를 사용해서 도달하는 호스트 이름을 지정할 수 있습니다.
- HTTPS에 대해 특정한 보안 정책을 설정할 수 있습니다.
* 레거시 클라이언트로 불리는 구형TLSSLS를 지원하도록 지정할 수 있습니다.
- CLB
- 하나의 SSL 인증서만 지원합니다.
- 여러 SSL 인증서가 있는 다중 호스트 이름이 필요한 경우에는 다수의 클래식 로드 밸런서를 사용하는 게 가장 좋습니다.
- ALB
- 다중 SSL 인증서를 가진 다수의 리스너를 지원합니다.
- SNI를 사용합니다.
- NLB
- 다중 SSL 인증서를 가진 다수의 리스너를 지원합니다.
- SNI를 사용합니다.
SNI - Server Name Indication
- 한 웹 서버 상에 다수의 SSL 인증서를 발급해 단일 웹 서버가 여러 개의 웹 사이트를 제공하도록 하는 문제를 해결해 줍니다.
- 클라이언트가 초기 SSL 핸드셰이크에서 대상 서버의 호스트 이름을 명시해야 합니다.
- 모든 클라이언트가 이를 지원하지는 않습니다.
- 최신 프로토콜이기 때문입니다.
- 애플리케이션 로드 밸런서나 네트워크 로드 밸런서와 같은 최신 버전의 로드 밸런서나 클라우드 프론트에서만 작동합니다.
- 구형인 클래식 로드 밸런서를 사용하는 경우에는 작동하지 않습니다.
연결 드레이닝
- CLB를 사용할 경우에는
연결 드레이닝 - ALB, NLB를 사용할 경우에는
등록 취소 지연
- 인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때
인스턴스에 어느 정도의 시간을 주어 인-플라이트 요청, 즉 활성 요청을 완료할 수 있도록 하는 기능입니다. - ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않습니다.
- 연결 드레이닝 파라미터는 매개변수로 표시할 수 있습니다.
- 1부터 3,600초 사이의 값으로 설정할 수 있는데 기본적으로는 300초, 즉 5분입니다
- 이 값을 0으로 설정하면 전부 다 비활성화할 수 있습니다.
- 짧은 요청의 경우에는 낮은 값으로 설정하면 좋습니다.
ASG
Auto Scaling Group
부하가 증가하면 거기 맞춰서EC2 인스턴스를 추가하고
줄어든 부하에 맞춰EC2 인스턴스를 제거하는 작업입니다.
- 머신의 최소 및 최대 숫자를 설정할 수 있습니다.
- 로드 밸런서에 자동으로 새 인스턴스를 등록해 주는 기능이 있습니다.
- ASG 속성
- AMI + 인스턴스 종류
- EC2 사용자 데이터
- EBS 볼륨
- 보안 그룹
- SSH Key Pair
- EC2 Instances의 IAM 역할
- Network + Subnets 정보
- Load Balancer 정보
- 최소 크기와 최대 크기
- 최초 용량 및 기대 용량
- 스케일링 정책
오토 스케일링 알람
- 알람은 평균 CPU 같은 메트릭을 모니터링하며 메트릭은 전반적인 평균으로 계산됩니다.
- 알람을 기반으로 스케일 아웃 및 스케일 인 정책을 만들 수 있습니다.
오토 스케일링 커스텀 메트릭
오토 스케일링 그룹은 AWS의 노출된 메트릭에 결부되어 있지 않으며 어떤 메트릭이든 관계가 없고 어떤 것도 커스텀 메트릭이 될 수 있습니다.
ASG 스케일링 정책
동적 스케일링 정책
- Target Tracking Scaling
- 가장 단순하고 설정하기도 쉽습니다.
- Simple/Step Scaling
- CloudWatch 경보를 설정하고 용량을 두 유닛 추가하도록 설정할 수 있습니다.
- CloudWatch 경보를 설정할 때에는 한 번에 추가할 유닛의 수와 한 번에 제거할 유닛의 수를 단계별로 설정할 필요가 있습니다.
- Scheduled Actions
- 나와 있는 사용 패턴을 바탕으로 스케일링을 예상하는 것입니다.
예측 스케일링
- AWS 내 오토 스케일링 서비스를 활용하여 지속적으로 예측을 생성할 수 있습니다.
- 로드를 보고서 다음 스케일링을 예측하는 것입니다.
- 시간에 걸쳐 과거 로드를 분석하고 예측이 생성됩니다.
- 해당 예측을 기반으로 사전에 스케일링 작업이 예약됩니다.
스케일링 지표
- CPU 사용률
- 인스턴스 간의 평균 CPU 사용률
- Request Count Per Target
- 테스트를 기반으로 하는 대상별 요청의 수
- 평균 네트워크 I/O
- 애플리케이션이 네트워크에 연결된 경우
- 커스텀 메트릭
- 애플리케이션 별로 지표를 설정하고 이를 기반으로 스케일링 정책을 바꿀 수 있습니다.
스케일링 휴지
- 스케일링 작업이 끝날 때마다 인스턴스의 추가 또는 삭제를 막론하고 기본적으로 5분 혹은 300초의 휴지 기간을 갖는 것입니다.
- 휴지 기간에는 ASG가 추가 인스턴스를 실행 또는 종료할 수 없습니다.
- 즉시 사용이 가능한
AMI를 이용하여 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋습니다.
SA가 알아야할 ASG
- 인스턴스가 종료되는 방식에 규칙이 있다는 것
- 기본적으로 ASG 기본 종료 정책이 있고 좀 더 단순한 버전이 있습니다.
1. 먼저 가장 많은 인스턴스가 있는 AZ를 찾습니다.
2. 그런 다음 AZ에 선택할 인스턴스가 여러 개인 경우 가장 오래된 실행 구성이나 실행 템플릿이 있는 인스턴스를 삭제합니다.
ASG 수명 주기 후크 (Lifecycle Hooks)
- 기본적으로 ASG에서 인스턴스가 실행되자마자 서비스가 시작되지만 인스턴스를 실행할 때 발생하는 긴 프로세스가 있습니다.
- 인스턴스가 실행되면 보류 상태가 되고 보류 상태에서 수명 주기 후크를 정의하면 인스턴스가 보류 대기 상태로 바로 전환되고 해당 인스턴스를 구성하거나 많은 작업을 수행할 수 있는 옵션이 생깁니다.
- 종료 상태에서 수명 주기 후크를 정의하면 종료 대기 상태가 된 다음 종료 진행 이후에 종료됩니다.
종료 수명 주기 후크가 있는 이유는 무엇일까요?
예를 들어 ECM2 인스턴스가 완전히 종료되기 전에 로그 또는 파일에 대한 정보를 추출하려는 경우 수명 주기 후크를 사용하는 사례가 될 수 있습니다.
실행 템플릿과 실행 구성의 차이점
- 공통
- 실행 템플릿과 실행 구성은 모두 EC2 인스턴스의 AMI ID를 지정할 수 있습니다.
- 실행 구성 (오래된 것)
- 단일 매개변수를 업데이트할 때마다 다시 생성되어야 합니다.
- 실행 템플릿 (새 것)
- 여러 버전을 가지기 때문에 버전 관리가 됩니다.
- 여러 템플릿에서 재사용하고 상속해야 하는 부분 구성을 정의할 수 있습니다.
- 온디맨드 인스턴스와 스팟 인스턴스를 혼합하여 프로비저닝하여 실행 구성보다 비용 구조가 더 나은 스팟 플릿을 갖게 될 수 있습니다.
- T2 무제한 버스트 기능도 사용할 수 있습니다.
- AWS에서 권장합니다.
클라우드, 데이터, DevOps 엔지니어 지향 || 글보단 사진 지향