티스토리 뷰
AWS SAA
SAA-C02 자격증 합격 후기에 이어 공부했던 내용들을 간단하게 다시 정리하려고 합니다.
모든 시험 범위를 포함할 수는 없고, 중요하다고 생각하는 내용들 위주로 정리하였습니다.
첫 번째로 가장 기본이 되고 가장 많이 쓰이는 EC2와 Auto Scaling, ELB에 대해서 알아보겠습니다.
EC2 (Elastic Compute Cloud)
소개
EC2는 물리 서버의 기능을 가상화했지만 실제 서버와 유사하게 작동하는 가상 컴퓨팅 환경입니다.
기본적으로 스토리지, 메모리, 네트워크 인터페이스, OS가 설치된 기본 드라이브가 제공되어 손쉽게 원하는 작업을 진행할 수 있습니다.
인스턴스 수명 주기 & 요금
인스턴스는 시작한 순간부터 종료될 때까지 다음과 같이 다양한 상태를 가집니다.
- pending
- 인스턴스가 running 상태가 될 준비를 하고 있습니다. 인스턴스를 새로 시작하거나 stopped 상태의 인스턴스를 다시 시작하는 경우입니다.
- 비용은 미청구됩니다.
- running
- 인스턴스 실행 상태입니다.
- 비용은 청구됩니다.
- stopping
- 인스턴스가 중지 또는 최대 절전 모드로 전환할 준비를 하고 있습니다.
- 중지를 준비하는 경우 미청구,
최대 절전 모드로 준비중인 경우 청구
됩니다.
- stopped
- 인스턴스가 중지되고 사용이 불가합니다.
- 비용은 미청구됩니다.
- shutting-down
- 인스턴스가 종료할 준비를 하고 있습니다.
- 비용은 미청구됩니다.
- terminated
- 인스턴스가 영구적으로 삭제되었으며 재시작할 수 없습니다.
- 비용은 미청구됩니다.
- 예약 인스턴스인 경우 결제 옵션에 따라 기간이 종료될 때까지 요금이 청구됩니다.
인스턴스 최대 절전 모드
인스턴스 최대 절전 모드라는 것이 있는데요, Amazon EBS를 지원하는 인스턴스 유형에만 해당됩니다.
쉽게 말해 인스턴스의 데이터를 Amazon EBS에 임시 저장하고, 다시 복원할 수 있는 기능입니다.
인스턴스를 최대 절전 모드로 전환하면 운영 체제에 최대 절전 모드를 수행하도록 알리고, 인스턴스 메모리(RAM)의 콘텐츠를 Amazon EBS 루트 볼륨에 저장합니다.
인스턴스를 다시 시작하면 EBS 루트 볼륨이 이전 상태로 복원되고, RAM 콘텐츠가 다시 로드됩니다.
이어서 이전에 연결된 데이터 볼륨이 다시 연결되고, 인스턴스는 해당 인스턴스 ID를 유지하게 됩니다.
인스턴스를 최대 절전 모드로 전환하면 stopping
상태로 전환되고 나서 stopped
상태로 전환됩니다.
최대 절전 모드로 전환하지 않고 인스턴스를 중지한 경우와 달리 최대 절전 모드 인스턴스가 stopped
상태이면 해당 인스턴스에 대해서는 사용 요금을 청구할 수 없지만 stopping
상태일 때 비용이 청구됩니다.
데이터 전송에 대해 사용 요금이 부과되지는 않지만 RAM 데이터에 대한 스토리지를 포함해 모든 Amazon EBS 볼륨에 대한 스토리지 요금은 부과됩니다.
인스턴스 구입 옵션
사용자의 상황에 따라 인스턴스를 좀 더 저렴한 가격으로 구입할 수 있는 옵션들이 있습니다.
- 온디맨드 인스턴스
- 기본적으로 사용하는 인스턴스를 의미합니다.
- 비용을 초 단위로 지불합니다.
- 전용 인스턴스 (Dedicated instances)
- 일반 인스턴스와 달리 하드웨어 수준에서 물리적으로 격리된 VPC에서 사용되는 인스턴스입니다.
- 동일 AWS 계정의 다른 인스턴스와는 하드웨어를 공유할 수도 있습니다.
- 예약 인스턴스 (Reserved instances)
1년
혹은3년
약정으로 할인된 가격에 미리 인스턴스를 구입 비용을 지불하여 이용할 수 있습니다.- 위 약정 기간 동안 컴퓨팅 리소스 사용량이 충분히 예측된다면 저렴한 가격으로 인스턴스를 사용할 수 있는 좋은 옵션입니다.
- 스팟 인스턴스
- 가장 큰 할인율로 인스턴스를 이용할 수 있습니다.
- 스팟 인스턴스의 수요와 공급에 의해 스팟 가격(시장 가격)이 책정되고 점진적으로 조정되는데, 이 스팟 가격보다 사용자가 제시한 최고 가격이 더 높을 때만 실행됩니다.
- 스팟 가격이 사용자 최고 가격보다 높아지만 인스턴스가 즉각 종료됩니다. (설정에 따라 중지, 최대 절전 모드로 선택 가능합니다)
- 시간을 유연하게 조정하고
중단되어도 되는 애플리케이션
에서 데이터 분석, 배치 작업, 백그라운드 프로세싱 등의 용도로 사용되기에 적합합니다.
배치 그룹 (Placement Group)
일반적인 인스턴스는 기본 하드웨어 전반에 분산되어 상호 관련 오류의 위험성을 줄입니다.
하지만 인스턴스 배치 그룹을 사용하면, 특정 요구 사항을 충족할 수 있도록 인스턴스를 좀 더 효율적으로 배치하고 활용할 수 있습니다.
- 클러스터 배치 그룹
- 단일 가용 영역 내에 있는 인스턴스 논리적 그룹
짧은 네트워크 지연 시간
,높은 네트워크 처리량
을 요하는 애플리케이션에 권장
- 파티션 배치 그룹
- 논리적 파티션을 나누고, 각 인스턴스 그룹이 서로 기본 하드웨어를 공유하지 않게 합니다.
- Hadoop, Cassandra, Kafka 등
대규모의 분산 및 복제된 워크로드
에 필요
- 분산형 배치 그룹
- 소규모의 인스턴스 그룹을 다른 기본 하드웨어로 분산하여 상호 관련 오류를 줄입니다.
- 동일한 리전의 여러 가용 영역에 적용될 수 있고, 그룹당 가용 영역별로 최대 7개의 인스턴스까지 가능합니다.
Amazon EC2 Auto Scaling
소개
EC2에 이어서 Auto Scaling에 대해 알아보겠습니다.
EC2 Auto Scaling 서비스는 애플리케이션 장애를 방지하고, 장애가 발생했을 때 복구할 수 있는 방법을 제공합니다.
Auto Scaling은 지정한 개수의 EC2 인스턴스를 자동으로 프로비저닝해서 시작하는데요, 수요가 증가하면 더 많은 인스턴스를 동적으로 추가할 수 있고, 인스턴스가 종료되거나 장애가 생기면 Auto Scaling이 자동으로 인스턴스를 교체하게 됩니다.
애플리케이션의 가용성을 높일 수 있는 가장 중요한 도구 중 하나입니다.
시작 구성
시작 구성(Launch Configuration)은 인스턴스를 수동으로 생성할 때 사용하며, AMI, 인스턴스 유형, SSH 키 페어, 보안 그룹, 인스턴스 프로필, 블록 장치 연결, EBS 최적화 여부, 배치 테넌시, 사용자 데이터 등의 구성 파라미터를 지정합니다.
시작 구성은 인스턴스를 수동으로 프로비저닝할 때 입력하는 정보와 같은 내용을 담고 있는 형식 문서입니다.
시작 구성은 기존 EC2 인스턴스에서 만들 수 있고, Auto Scaling이 인스턴스에서 설정을 복사한 뒤, 필요에 따라 그 설정을 변경해서 만들 수 있으며, 아예 백지 상태에서 처음부터 만들 수도 있습니다.
시작 구성은 Auto Scaling에서만 사용되므로, 인스턴스를 직접 시작할 때 시작 구성을 활용할 수 없습니다.
또한 시작 구성을 만들고 나면 수정할 수 없으므로
, 설정의 일부 내용을 수정하려면 새롭게 시작 구성을 작성해야 합니다.
공식 문서에서는 시작 구성을 사용하지 않기를 권장하고 있고, 대신 다음의 시작 템플릿을 사용하기를 권장하고 있습니다.
시작 템플릿
시작 템플릿(Launch Template)은 인스턴스를 수동으로 프로비저닝할 때 입력하는 정보를 설정 작업에 사용한다는 점에서 시작 구성과 유사하지만, 기존의 시작 구성보다 다양한 용도로 활용할 수 있습니다.
시작 템플릿을 생성하고 난 후 수정할 수 있으며, 기존 템플릿과 수정 템플릿을 버전별로 보관
합니다.
AWS에 모든 버전을 보관하고 있다가 필요에 따라 앞 버전과 뒤 버전의 템플릿을 선택해서 사용할 수도 있습니다.
간단하게 시작 구성은 생성 후 수정할 수 없고, 시작 템플릿은 수정할 수 있으며 버저닝이 되어 활용도가 높다 정도로 정리하시면 됩니다.
Auto Scaling Group
Auto Scaling 그룹은 Auto Scaling이 관리하는 EC2 인스턴스의 그룹이며, Auto Scaling 그룹을 만들 때는 미리 만들어 놓은 시작 구성이나 시작 템플릿을 지정합니다.
Auto Scaling이 프로비저닝하고 유지해야 하는 가동 인스턴스의 숫자도 지정하고, Auto Scaling 그룹의 최소 및 최대 숫자도 지정하며, 유지해야 할 인스턴스의 목표 숫자도 선택적으로 설정할 수 있습니다.
- 최소
- 정상 인스턴스 수가 최솟값보다 적어지지 않도록 합니다.
- 0으로 설정하면 Auto Scaling은 인스턴스를 만들지 않고 그룹 내에서 가동 중인 모든 인스턴스를 종료합니다.
- 최대
- 정상 인스턴스 수가 최댓값을 넘지 않도록 합니다.
- 목표 용량
- 최솟값과 최댓값 사이에서 선택하며 반드시 설정해야 하는 것은 아닙니다.
- 목표 용량을 지정하지 않으면 Auto Scaling은 최소 인스턴스 수로 시작하고, 목표 용량을 지정하면 Auto Scaling은 지정된 용량을 유지하기 위해 인스턴스를 추가하거나 종료합니다.
Application Load Balancer 대상 그룹 지정
Application Load Balancer를 사용해 Auto Scaling 그룹에 있는 인스턴스로 트래픽을 분산하려면 Auto Scaling 그룹을 만들 때 ALB 대상 그룹의 이름을 넣습니다.
그러면 Auto Scaling이 새 인스턴스를 만들 때마다 자동으로 인스턴스를 ALB 대상 그룹에 추가합니다.
애플리케이션 인스턴스 상태 검사
기본적으로 Auto Scaling은 EC2 상태 검사를 기반으로 인스턴스의 상태를 판정합니다.
ALB를 사용해 트래픽을 인스턴스로 라우팅할 때 로드 밸런서 대상 그룹에 상태 검사를 구성할 수 있습니다.
대상 그룹 상태 검사는 200에서 499 범위의 HTTP 응답 코드를 검사합니다.
ALB 상태 검사에서 인스턴스가 비정상으로 확인되면 그 인스턴스로 사용자의 트래픽이 전달되지 않도록 하고, Auto Scaling은 해당 인스턴스를 제거하고 대체 인스턴스를 만들어서 로드 밸런서의 대상 그룹에 추가해 새 인스턴스로 트래픽이 전달되도록 합니다.
Amazon ELB (Elastic Load Balancing)
소개
Elastic Load Balancing은 모든 EC2 인스턴스에 들어오는 애플리케이션 트래픽을 분산시키는 서비스입니다.
온프레미스 환경에서의 L4 Switch와 동일한 역할을 합니다.
AWS에는 CLB(Classic Load Balancer), ALB(Application Load Balancer), NLB(Network Load Balancer), GLB(Gateway Load Balancer) 등의 로드 밸런서가 있는데요, 시험에는 주로 ALB가 문제 상황으로 제시되고, 가끔 NLB가 별도의 문제로 나오고 있습니다.
ALB와 NLB의 차이
- Application Load Balancer
- HTTP, HTTPS 트래픽의 로드 밸런싱에 가장 적합합니다.
- Network Load Balancer
TCP, UDP의 4계층 프로토콜
의 로드 밸런싱에 가장 적합합니다.
'devOps' 카테고리의 다른 글
[AWS SAA] 3. Storage Service (0) | 2021.02.10 |
---|---|
[AWS SAA] 2. VPC (0) | 2021.02.09 |
AWS SAA-C02 합격 후기 (0) | 2021.02.07 |
Github Actions + CodeDeploy + Nginx 로 무중단 배포하기 (3) (0) | 2020.08.20 |
Github Actions + CodeDeploy + Nginx 로 무중단 배포하기 (2) (0) | 2020.08.20 |