[AWS SAA-C02 (feat.삽가능 스터디)] EC2, ELB, RDS

 

A-SAA-P 에이삽! 스터디 정리하기 시작

 

 

---

 

 

 

 

❓ 온프레미스(On-premise) vs. 클라우드(Cloud)

온프레미스 : 실제 물리적인 서버부터 구축. 네트워크 및 인프라 모두 직접 뚝딱뚝딱.

클라우드 : 인프라 즉 IT 자원을 다 빌려줌. 직접 보유하고 있을 필요 없이 필요할 때만 사용.

 

❗️ 클라우드 컴퓨팅의 조건

1. On Demand Self Service
   사용자가 원할 때 바로 사용
2. Broad Network Access
   네트워크 기반, 다양한 클라이언트로 접속 가능
3. Resource Pooling
   자원은 Pool로 관리되며, 사용자의 요청에 의해 반환&할당 됨.
4. Rapid Elasticity
   사용자는 짧은 시간 내 자원을 무한대로 확장&축소 가능.
5. Measured Service
   자원의 사용량이 실시간으로 수집, 모니터링 되어야 함.

EC2

---

Elastic Compute Cloud        참고 공식 문서

• 클라우드 서버를 빌려준다. 컴퓨터 한 대를 빌려주는 것과 동일!
• 서버 한 대 = 인스턴스instance
• 스토리지, 메모리, 네트워크 인터페이스, OS가 설치된 기본 드라이브가 제공.
• AMI = Amazon Machine Image. 템플릿 개념의 '이미지'로 인스턴스를 생성.
  • 여기서 종류를 고를 수 있다. 보통은 프리 티어용인 젤 작고 귀여운 인스턴스를 선택...

  • 

• key pair로 관리
• 보안 그룹Security Groups 으로 인스턴스에 연결할 수 있는 프로토콜, 포트, 소스 IP 지정 가능(방화벽 역할)

• 

• EIP = Elastic IP. 탄력적 IP 주소. 동적 클라우드 컴퓨팅을 위한 IPv4 주소. 서버에 EIP를 붙여서 사용할 수 있다. (안 쓸 때는 다시 EIP를 반납해야 과금이 안됨...ㅜ)
• Region. AWS는 리전을 두고 데이터센터를 세워뒀음. 어느 나라/지역에 해당하는 서버를 사용할 것인지 선택할 수 있음.
  • Availability Zone(AZ)와는 또 조금 다름.
  • AZ는 실제 서버가 돌아가는 영역. 하나가 아닐 수 있음. 가용 영역.

 

EC2 : Auto Scaling

참고 블로그

갑자기 트래픽이 늘어나거나 사용자 수가 증가했을 때 장애가 발생할 수 있음! 이를 해결하기 위한 복구 방법 솔루션

⇒ 수요에 따라 자유자재로 인스턴스의 수를 조절!

• Launch Configuration(시작 구성)
  • 인스턴스를 수동으로 생성할 때 사용.
  • AMI, Instance Type, SSH key pair, Security groups, ... 구성 파라미터를 지정
  • 인스턴스를 수동으로 프로비저닝할 때 입력하는 정보와 같은 내용을 담고 있는 형식 문서
    *프로비저닝 = 필요한 리소스를 기반으로 네트워크에서 사용될 서버를 설정하는 프로세스
  • 한번 만들고 나면 수정 불가! 수정하려면 새로 작성해야 함. (→ Launch Template 추천)
• Launch Template(시작 템플릿)
  • Launch Configuration과 유사하지만 더 다양하게 활용 가능.
  • 수정 가능!
  • 버전별로 보관
• Auto Scaling Group
  • Auto Scaling이 관리하는 EC2 인스턴스의 그룹.
  • 미리 만들어 놓은 Launch Configuration / Template을 지정.
  • 프로비저닝하고 유지하는 가동 인스턴스 숫자 & 최소 & 최대 숫자 지정.
  • 목표 용량 - 최소와 최대 사이에서 선택해야 하고 optional. 지정 안하면 최소 숫자로 시작한다.
• 어떤 서비스에 좋을까?
  • 주기적 트래픽(낮에는 리소스 사용량 많고 밤에는 적음)
  • 배치(batch) 처리, 테스트 같은 온/오프 워크로드 패턴
  • 급증 기간이 있는 트래픽 패턴(이벤트 페이지 등)
• Scale Up / Scale Out / Scale In
  • scale up = 서버 스펙을 상승. 더 좋은 인스턴스로 갈아끼우는 것.
  • scale out = 서버 대수를 늘리는 것. 컴퓨팅 수 증가.
  • scale in = 더이상 필요없는 서버 줄이는 것.
• 상태 검사
  • EC2 상태 검사를 기반으로 인스턴스 상태 판정.
  • ALB로 라우팅 시, LB Target Group에 상태 검사를 구성할 수 있음.
  • 200 ~ 499 범위의 HTTP 응답 코드 검사.
  • 비정상이면, ALB가 해당 인스턴스로 트래픽 안 넘긴다. 제거하고 대체 인스턴스 만들어 Target Group에 재빨리 추가해서 써먹을 수 있게 함!

 

EC2 : RI

참고 공식 문서 참고 블로그

Reserved Instances.

• 왜 사용해야 할까?
  • 온디맨드와 비교해서 저렴 (온디맨드면 쓰는 만큼 냄)
  • 특정 AZ에서 사용하는 경우, 용량을 예약해서 쓸 수 있다.
  • 회원권과 비슷
• 결제옵션
  • 전체 선결제All Upfront : RI 약정 기간 동안의 비용을 한번에. 할인율 제일 높음.
  • 부분 선결제Partial Upfront : 일부만 선결제하고 약정 기간 동안 할인된 비용 지불.
  • 선결제 없음No Upfront : 선결제는 안하고 그냥 할인된 비용으로 지불.

유형 → 표준 & 컨버터블

• 표준 RI
  • 가장 큰 할인 혜택.
  • 사용량이 꾸준한 경우에 적합
• 컨버터블 RI
  • RI 속성 변경 가능(변경 후의 금액이 이전보다 크거나 같을 때만)
  • 역시 사용량이 꾸준한 경우에 적합
• RI 속성
  • 인스턴스 유형 (= CPU, 메모리, 스토리지, 네트워킹 용량 ...)
  • 테넌시.
  • AZ. 선택시 그 안에서 인스턴스를 사용하는 경우 할인&용량 예약 제공. RI의 AZ 지정 안되어 있으면 리전 내에서 실행되는 모든 크기의 인스턴스에 적용됨.

 

EC2 : Spot Instance

참고 블로그

사전 약정 없이 사용할 수 있는 EC2 Instance.

현재 시각에 유효한 가격만 지불, 온디맨드보다 70 ~ 90% 저렴.

장점

• 용량 활용 : 온디맨드처럼 표준 가격이 형성되어 있는 게 아니라, Spot의 수요와 공급에 따라 시장 가격 형성. EC2의 안정성, 보안성, 성능, 제어 및 탄력성 제공 받음.
• 운영비용 절감 : 온디맨드보다 저렴.
• 처리량 향상 : 상태 비저장 웹 서비스, 이미지 랜더링, 빅데이터 분석, 대량의 병렬 계산 등 애플리케이션을 실행하고 확장 가능.

배치 작업을 돌리는 서버 등에 유용!

Spot Instance 종류

• Spot Fleet
  • Load balancing workloads : 모든 AZ에서 동일한 사이즈의 인스턴스 사용. 웹에 적합.
  • Flexible workloads : 모든 AZ에서 모든 사이즈의 인스턴스 사용. 배치, CI/CD에 적합.
  • Big data workloads : 단일 AZ에서 여러 사이즈의 인스턴스 사용. MapReduce 작업에 적합.
• Spot Block
  • Defined duration workloads : 1~6시간 동안의 spot block(지정된 접속시간) 인스턴스 사용.

Spot Fleet 특징

• 인스턴스 중단에 대비해야 함!! → Spot 가격이 최고가보다 높아지거나, 미사용 EC2 인스턴스가 수요를 충족할만큼 충분히 없거나, 제약 조건에 걸리면 중단
• 대비하기 위해...
  • 종료 2분 전에 경고
  • 합리적인 입찰 가격 사용
  • 종료되어도 영향 안받을 곳에 데이터 저장. (EBS, S3 등의 스토리지)

Spot 집합 = Spot Instance 모음

• 가격, 용량의 변동으로 중단될 때 목표 용량 집합 유지하려는 시도를 함.
• 전략
  • 최저가격lowest price : 최저 가격 풀에서 인스턴스 가져옴.
  • 다각화diversified : 모든 풀에 분산해서 인스턴스 가져옴. 하나의 풀에서 발생하는 가격 상승에 덜 민감.

 

ELB

---

Elastic Load Balancer

• 트래픽을 분산시켜주는 장비.
• 서버 여러 대를 모니터링하면서 상태가 양호한 쪽으로 트래픽을 나눠줌.
• EC2 인스턴스에 들어오는 트래픽을 분산시켜준다.
• 1인스턴스 1도메인 → Scale Up 하면 인스턴스 업뎃하는 동안 사용 불가, Scale Out 하면 서버 늘어날 때마다 도메인 새로 필요... 따라서 LB가 필요!!
• On-premise의 L4 Switch와 같은 역할. (OSI 7계층 참고)
• AWS에는 CLB, ALB, NLB, GLB가 있다.
  • CLB = Classic LB
  • ALB = Application LB
  • NLB = Network LB
  • GLB = Gateway LB
• ALB vs. NLB
  • ALB → HTTP, HTTPS 트래픽의 로드 밸런싱에 가장 적합
  • NLB → TCP, UDP의 4계층 프로토콜 로드 밸런싱에 가장 적합 (네트워크 전문!)
• Target Group
  • Auto Scaling을 위한 단어이긴 함!
  • ALB 사용해서 Auto Scaling Group에 있는 인스턴스로 트래픽 분산하려면, Auto Scaling Group 만들 때 Target Group 이름을 넣음.
  • 그러면 새 인스턴스 만들 때마다 자동으로 ALB Target Group에 추가.

 

RDS

---

Relational Database Service

특징

• 간단한 사용법
• 간단한 백업 : S3 스냅샷 기능 이용으로 백업 가능
• 스토리지 및 iops(input output per sec..? 단위 시간당 읽기쓰기 횟수) 확장 용이

지원하는 인스턴스

⇒ Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server DB

RDS 설정 시,,,

• 보안 그룹, 파라미터 그룹, 포트 번호 등 설정 가능

 

RDS : 다중 AZ

❗️ 우선, Region과 Availability Zone

• 실제 물리적인 위치 = Region.
• Region 안에 AZ를 여러 개 둘 수 있다.

다중 AZ를 이용해 고가용성을 지원!

서로 다른 AZ에 복제본을 프로비저닝하고 유지. → 백업본 → 인스턴스 오류, AZ 중단 방지 가능.