[TIL.21.1.18 ~ ]AWS EC2(ECC, Elastic Compute Cloud)
EC2(ECC, Elastic Compute Cloud)
- 서버 인스턴스를 획득하고 부팅하는데 필요한 시간을 몇분으로 단축 >> 탄력적 시장대응
- 사용한 만큼만 비용지불
- 신속하게 용령확장 축소
- 장애에 대한 복원력이 뛰어남
클라우드상에 컴퓨팅 파워를 비용을 지불하고 사용
EC2 가격정책
- On-Demand : 실행하는 인스턴스에 따라 시간 또는 초당 컴퓨팅 파워로 측정된 가격을 지불
- Spot- Inatance : 경매형식으로 시장에 남은인스턴스를 저렴하게 구마해서 사용
- 최대 90% 저렴
- 단 언제 다시 내주어야 할지 모름
- 시작 종료가 자유롭거나 추가적인 컴퓨팅 파워가 필요한 경우
- 빅데이터 분석, 혹은 메인서버 보조
- Reserved Instance : 미리 일정기간 약정해서 쓰는 방식
- 최대 75% 정도 저렴
- 수요 예측이 확실할 때
- 총 비용을 절감하기 위해 어느정도 약정이 가능한 사용자
- 전용호스트(Dedicated) : 실제 물리적인 서버를 임대하는 방식
- 라이선스 이슈
- 규정이 따라 필요한 경우
EC2 타입 종류
EC2 와 다른AWS 서비스들
EBS/ AMI
EBS(Elastic Block Store)
*Block Store 반대 Object storage
- EBS Based : 반 영구적인 파일의 저자 가능
- Snapshot 기능
- 인스턴스 업그레이드 가능 (스토리지가 인스턴스와 분리되어 있기 때문)
- Stop 가능
- 네트워크로 연결된 스토리지 > 종속되어 있지 않음
- 다른 EC2인스턴스에서도 접근 가능
- Instance Storage : 휘발성이나 빠른방식
- 빠르지만 저장이 필요 없는 경우
- Stop불가능
- 인스턴스에 내장된 스토리지(물리적)
AMI(Amazon Machine Image)
Amazon Machine Image는 인스턴스를 시작하는 데 필요한 정보를 제공, 인스턴스를 시작할 때 AMI를 지정 해야한다. AMI는 다음을 포함한다.
- 1개 이상의 EBS Snapshot, 인스턴스 저장 지원 AMI의 경우 인스턴스의 루트볼륨에 대한 템플릿
- 운영체제, 애플리케이션 서버, 애플리케이션
- AMI를 사용하여 인스턴스르 시작할 수 있는 AWS계정을 제어하는 시작권한
- 시작될 떄 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑
*Snapshot : EBS에 있는 OS, file, 시작권한을 저장해둠
*Snapshot생성 - S3에 저장 - AMI등록
security Group(SG), ELB(Elastic Load Balancer), AutoScaling Group
Security Group(SG)
- 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할(최대 5개)
- 서브넷 수준이 아니라 인스턴스 수준에서 작동
- 하나의 인스턴스에 하나 이상의 SG설정 가능
- NACL의 경우 서브넷 단위
- 설정된 인스턴스는 설정한 모든 SG의 룰을 적용받음
- 보안장치 : NACL(Network Access LIst)과 함께 방화벽의 역할을 하는 서비스
- Port 허용
- 트래픽이 지나갈 수 있는 Port와 Source를 설정가능
- Deny는 불가능(NACL로 가능)
* 빨간색 포트로는 접근할 수 없음
- 설정된 모든 룰을 사용해서 필터링
- NACL의 경우 적용된 룰의 순서대로 필터링
- Stateful
- 인바운드로 들어온 트래픽이 별 다른 아웃바운드 설정 없이 나갈 수 있음
- NACL은 Stateless
*Stateful VS Stateless
Stateful :인바운드에 명시된 트래픽이 들어왔을 때 이에대한 응답이 나갈 수 있음
Stateless : 인바운드에 명시된 포트로 트래픽이 들어오도라도 아웃바운드에 명시되지 않은 포트로 응답이 나가는것이 불가
* 보안그룹에서 아웃바운드 규칙을 설정하는 경우 :외부 트래픽이 차단된 인스턴스에서 업데이트 요청을 할 때, Push 서버의 경우 User에게 push를 할 때
ELB(Elastic Load Balancer)
Elastic Load Balaning은 들어오는 애플리케이션 트래픽을 EC2 Instance, Container, IP address, Lambda Function과 같은 여러 대상에 자동으로 분산시킨다.
- 단일 가용영역 또는 여러 가용영역에서 부하처리 가능
- 내결함성, 고가용성, 자동 확장/축소, 강력한 보안
- IP가 지속적으로 바뀜
- 지속적으로 IP주소가 바뀜
- 따라서 도메인 기반으로 사용해야 함
- Health Check
- 직접 트래픽을 발생시켜 Instance가 살아있는지를 체크함
- InService, OutofService 두가지 상태로 나누어짐
- 3가지 종류가 존재함
- Application Load Balancer
- Network Load Balancer
- Classic Load Balancer
*Vertical Scale & Horizontal scale
일반적으로(항상 그렇지는 않지만) AWS 아키텍처를 구성할 때 성능을 높이기 보다는 많은 인스턴스를 사용하도록 구조를 잡음
ELB 종류별 특징
- Application Load Balancer
- OSI model 7-layer(application layer)에서 작동
- 똑똑하다
- Network Load Balancer
- OSI model 4-layer(Network layer)에서 작동
- 빠르다
- Classic Load Balancer
- 가장 먼저 서비스 시작
Sticky Session
- 특정 시간동안 한번 세션이 형성된 곳으로 트래픽을 계속 보냄(트래픽이 분산되는 주기를 설정)
AutoScaling Group
AWS Auto Scaling은 애플리케이션을 모니터링하고 용량을 자동으로 조정하여, 최대한 저렴한 비용으로 안정적이고 예측가능한 성능을 유지한다.
*AWS AutoScaling : EC2, DynamoDB, Spot Fleet, Aurora, ECS(Elastic Container Service) 가능
EC2 AutoScaling 목표
- 최소한의 인스턴스 사용 = Cost efficiency
- 원하는 만큼의 인스턴스 개수를 목표로 유지 = Stability
- 최대 인스턴스 개수 이하로 인스턴스를 유지 = Cost efficiency
- Availability Zone에 골고루 분산될 수 있도록 인스턴스를 분배 = Stability
- 항상 서비스가 유지될 수 있는 인스턴스를 확보 = Stability
EC2 AutoScaling 구성
- Launch Configuration - 무엇을 어떻게 실행시킬 것인가?
- EC2 타입, 사이즈
- AMI
- SG, Key, IAM
- User Data
- Mornitoring - 언제 실행시킬 것인가? + 상태 확인
- CPU 점유율이 일정 %를 넘어섰을 떄 추가로 실행 or 2개 이상이 필요한 스택에서 EC2 하나가 죽었을 떄
- Cloud Watch or ELB와 연계
- Desired Capacity - 얼마만큼 실행시킬 것인가?
- 최소 1개~ 최대 3개
- Lifecycle Hook - 인스턴스 시작/ 종료 시 Callback
- 다른서비스와 연계하여 전/후 처리 가능 - Cloud Watch/SNS/SQS
- Terminating : wait/Terminating : Proceed 상태로 전환
- 기본 3600초 동안 기다림
* HealthCheck Type
- ELB : 인스턴스에 올라가있는 어플리케이션이 정상작동 하는지 Check
- EC2 : EC2가 올라가있는지/ 안올라가있는지 Check
- EC2는 살아있는데 Application이 정상 작동하지 않는 경우에 아무 조치를 취하지 않는 상황이 발생할 수 있음 >> ELB HealthCheck 권장