EC2 스토리지 및 ELB, ASG

EBS 스냅샷

- EBS 볼륨 특정 시점에 대한 백업

- 스냅샷을 위해 EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 X but 권장

- 다른 AZ나 리전으로 복사 가능

- 삭제시, 영구 삭제가 아닌 휴지통에 넣어 복원 가능

 

AMI

- 아마존 머신 이미지

- AMI를 따로 구성하여 부팅 및 설정시간을 최소화

- 몇몇 AMI는 특정 AWS 리전에 국한되며, 각 AWS 리전에는 고유한 AMI가 있음

- 다른 AWS 리전에서 AMI를 사용해 EC2 인스턴스를 실행하는 것은 불가

- 대상 AWS 리전으로 AMI를 복사해 EC2 인스턴스를 사용하는 건 가능

- 라이선스나 권한, 유형에 따라 복사하지 못할 수 있음

 

EBS 볼륨 유형

1. gp2/gp3 범용 SSD → 다양한 워크로드에 대해 가격과 성능의 밸런스가 잘 맞는다
2. io1 / io2 최고 성능 SSD → 미션 크리티컬이며 지연시간이 낮고 대용량 워크로드로 데이터베이스 워크로드에 적합
3. st1 저비용의 HDD → 잦은 접근과 처리량이 많은 볼륨
4. sc1 최저비용의 HDD → 접근 빈도그 낮은 워크로드를 위해 설계

- gp2/gp3와 io1/io2만이 부팅 볼륨으로 사용됨

 

EBS 다중 연결

- 하나의 EBS 볼륨을 같은 AZ에 있는 여러 인스턴스에 연결 ->  동시에 읽기 쓰기가 필요한 경우에 사용

- EBS 볼륨 중에서 io1과 io2 제품군에서만 사용 가능

- 각각의 인스턴스는 높은 성능의 볼륨덕분에 동시에 읽고 쓰기 가능

- 한번에 16개의 EC2 인스턴스만 같은 볼륨에 연결 가능

- 다중연결을 하려면 클러스터 인식 파일 시스템을 사용해야함

 

EBS 볼륨 암호화

1. 볼륨의 EBS 스냅샷 생성

2. 복사 기능을 통해 원본 EBS 스냅샷 암호화

3. 위의 스냅샷을 이용해 EBS 볼륨을 암호화하여 새로 생성

4. 암호화된 볼륨을 인스턴스 원본에 연결

- EBS 볼륨 생성시, 암호화가 동시다발적으로(저장 데이터, 인스턴스와 볼륨간 전송 데이터, 모든 스냅샷, 스냅샷으로 생성한 볼륨) 발생

EFS

- Elastic File system로 여러 인스턴스에 마운트(mount) 가능

- 여러 AZ에 있는 인스턴스들이 공유할 수 있는 파일 시스템으로 가용성 확장성이 높음

- 단, 리눅스 기반 AMI와만 호환 가능

- 미리 용량 지정X 사용한 만큼(Petabyte 단위로 자동확장)지불

- 콘텐츠관리, 웹서비스, 데이터 공유, 워드프레스에 사용

 

EBS와 EFS와 인스턴스 스토어의 차이점?

- EBS는 한번에 하나의 인스턴스만 연결 가능- 가용영역에 바인딩되어 다른 가용 영역에서 활용할 수 없음

- gp2 → 볼륨의 수가 늘어날때마다 IOPS(IO per second)도 증가

- io1 → IOPS와 볼륨을 독립적으로 증가 → 중요한 DB를 실행할 때 좋음

- 다른 가용영역으로 옮기고자 한다면 우선 스냅샷을 생성한후 다른 AZ에서 복원

- ec2가 종료된다면 루트 볼륨도 기본적으로 종료 → 옵션으로 변경 가능

 

- EFS는 여러 개의 가용 영역에 걸쳐 많은 인스턴스들과 연결 가능

- EFS Mount Target을 사용해 특정 AZ에서 인스턴스들과 EFS 드라이브를 연결

- 워드프레스같은 웹 사이트 파일을 공유할 때 EFS를 사용

- Linux Posix기반으로, Windows 활용 불가

- EBS보다 비쌈

 

- 인스턴스 스토어는 인스턴스에서 IO를 최대로 사용하게끔 하지만, 인스턴스가 고장나면 데이터가 날라감

 

수직 확장성

- 인스턴스의 크기를 확장하는 것

- 데이터베이스같이 분산되지 않은 시스템에서 사용

 

수평 확장성

- 인스턴스나 시스템의 갯수를 늘리는 방법

- 인스턴스의 개수를 확장하는 것

- 분산 시스템이 있을 때 사용하며 현대적 애플리케이션의 개념

 

고가용성 

- 애플리케이션 또는 시스템이 적어도 둘 이상의 AZ나 데이터 센터에서 가용 중인 것

- 센터 하나가 멈춰도 다른 곳에서는 계속 동작해야함 → 문제가 생겨도 손실이 없어야 한다

- RDS 다중 AZ를 갖추고 있다면 수동형 고가용성

- 수평 확장을 하는 경우 활동형 고가용성

 

ELB

- elastic load balancing

-  하나의 서버, 서버셋으로 트래픽을 백엔드나 여러 서버(EC2 인스턴스들)로 다운스트림으로 전달하는 역할

- 인스턴스 앞에 위치하여 유저가 엘라스틱 로드 밸런서로 접근할 때 여러 대상그룹 내 인스턴스로 트래픽을 분산하는 것 → 다른 인스턴스 엔드포인트로 보냄

- 단일 엑세스 지점(DNS)을 노출하게 되고 다운스트림 인스턴스의 장애를 원활히 처리 가능

- 상태 확인 매커니즘(헬스 체크)으로 파악 가능

- 고정 호스트 이름이 부여됨(XXX.region.elb.amazonaws.com)

- 쿠키를 통한 고정성 지원, HTTPS 트래픽을 위한 SSL, 고가용성과 클라우드 내부의 개인 트래픽과 공공 트래픽을 분리할 수 있음

- 자체 로드밸런서를 마련하는 것보다 훨씬 저렴하고 확장성이 좋아 무조건 쓰는 것을 추천

-  다수의 aws 서비스들과 통합되어 있음 →  ACM, Route53, 오토 스케일링 그룹

• 웹소켓 로드 밸런서 ALB → HTTP, HTTPS, WebSocket
• 네트워크 로드 밸런서 NLB → TCP, TLS, secure TCP, UDP
  • NLB는 최고 성능을 위한 로드 밸런서
• 게이트웨이 로드 밸런서 GWLB
  • 네트워크 계층과 IP프로토콜에서 작동
  • 보안, 침입탑지 등 네트워크 트래픽을 분석하기 위한 로드밸런서

 

Health check

- 로드밸런서가 ec2 인스턴스에 현재 제대로 작동하는지 확인하는 것

- 포트와 라우트(대상그룹으로 라우팅)에서 이루어짐

- 제대로 응답하지 않으면 트래픽 전송X

 

ALB

- 7계층 HTTP 전용 로드 밸런서

- 머신 간 다수 HTTP 애플리케이션 라우팅에 사용하며 머신끼리 타겟 그룹으로 묶임

- HTTP/2와 웹소켓 또한 지원한다 → 리다이렉트또한 지원(HTTP→HTTPS)

- 다른 타켓 그룹으로 라우팅

• path in URL 기반 라우팅 (example.com/user & example.com/posts)
• hostname in URL 기반 라우팅 book.example.com & one.example.com
• 쿼리스트링, 헤더 URL 기반 라우팅 example.com/users?id=123 …
• 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서
  • 도커와 ECS의 경우 ALB가 가장 적합
  • 포트 매핑 기능이 있어 인스턴스의 동적 포트로 리다이렉트 가능

쿼리 스트링과 파라미터 규칙을 만들어 타겟 그룹으로 리다이렉트 가능

• ALB 하나만으로 다수의 애플리케이션 처리 가능

대상그룹(target group)

- (오토스케일링 그룹으로 관리되는) ec2 인스턴스들 - HTTP

- ECS tasks - HTTP

- 람다 함수(서버리스)가 될 수도 있음

- 프라이빗 ip

- 여러 대상 그룹으로 라우팅 될 수 있으며 헬스체크는 대상 그룹 레벨에서 이루어짐

- 애플리케이션 서버는 클라이언트의 ip를 직접 보지 못함

• • 로드밸런서는 ec2인스턴스의 프라이빗 아이피로 들어가야 하므로,  클라이언트 실제 ip는 x-forwarded-for 헤더에서 얻을 수 있음

- EC2에 접근할 때, 퍼플링 IP가 아닌 로드밸런서로만 접근가능하게 할 것

- 이때, EC2의 보안그룹의 인바운드 규칙에는 로드밸런서에서 오는 트래픽만 받도록 설정

 

NLB

- L4(Transport) 계층 로드 밸런서로 TCP와 UDP 트래픽을 모두 다룰 수 있다.

- 성능이 매우 좋다 적은 레이턴시

- 가용영역별로 하나의 고정 IP를 가진다

• 1~3개의 IP로만 엑세스할 수 있는 애플리케이션을 만들라고 하면 무조건 NLB
• 고성능,TCP/UDP, 고정 IP라는 단어가 나오면 NLB이다

- NLB에는 SSL/TLS 인증서 적용 가능

- 고정 IP를 사용하면 인증서를 한 번만 구매하고 설치한 후에도 IP 주소 변경 없이 계속 사용할 수 있음

- ALB 앞에 배치하여 NLB를 통해 고정 IP주소를 얻은 이후 ALB로 적절한 로드밸런싱을 함

 

GWLB

- 배포 및 확장과 manage a fleet of 3rd party network virtual appliances in AWS

- 네트워크의 모든 트래픽이 방화벽 통과 or 침입 탐지 방지 (IDPS) or 심층 패킷 분석 시스템 등을 네트워크 수준에서 가능

- 모든 로드밸런서보다 낮은 계층에서 실행 (L3)

• 모든 VPC 트래픽이 GWLB의 단일 엔트리와 출구를 통과
• 이후 서드파티 가상 어플라이언스 타겟 그룹에 트래픽을 분산

- 6081번 포트의 GENEVE 프로토콜을 사용

- GWLB의 대상그룹으로 아래 3개를 등록 가능

• EC2 인스턴스
• IP address - 프라이빗 ip ( 어플라이언스를 사설 서버로 만들 경우 등록 )
• 타사 어플라이언스

→  주요 기능은 네트워크 트래픽 분석이며 L3 (네트워크 계층)에서 이루어지며 GWLB를 두는 순간 라우트 테이블은 업데이트 되어 이후 트래픽이 GWLB를 거침

Stichy Session

- HTTP Keepalive 속성처럼 처음 연결된 인스턴스와 계속해서 연결을 되는 로드 밸런서의 기능

-  ALB에서 설정 가능하며 쿠키를 통해 클라이언트에서 로드밸런서로 전달되어 검증 → 고정성과 만료성이 있으며 쿠키가 만료되면 다른 인스턴스로 리디렉션

- 사용자 로그인과 같은 백엔드 단 중요 세션 데이터를 잃지 않기위해 동일한 인스턴스에 연결 →  ec2 인스턴스 부하에 불균형을 초래

 

 

 

• 애플리케이션 기반 쿠키
  • Custom Cookie
    • 사용자 정의 쿠키로 애플리케이션에서 생성
    • 애플리케이션에 필요한 여러 사용자 정의 속성들을 포함 가능
    • 쿠키 이름은 각 대상 그룹별로 지정해야한다
      • AWSSALB, AWSSALBAPP 등 AWS에서 사용되는 이름은 불가능
  • Application cookie
    • 로드밸런서에 의해 생성되며 AWSALBAPP이라는 이름을 가짐
• Duration-based Cookies
  • 로드밸런서에 의해 생성
  • AWSSALB, AWSSELB
  • 특정 기간을 기반으로 만료되며 로드 밸런서 자체에서 생성되는 것

 

인스턴스와 연결되어 고정성을 위한 쿠키가 생성

 

 

Cross-zon 로드밸런싱

- 각 AZ에 있는 로드 밸런서가 각각 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배

- 로드밸런서에 등록된 인스턴스 갯수가 달라도 받는 트래픽 부하는 동등

- ALB는 디폴트로 켜짐+추가비용X이며, NLB와 GWLB는 꺼짐+추가비용O

 

SSL/TLS 인증서

- SSL 인증서란 클라이언트와 로드 밸런서 사이에 트래픽이 이동하는 동안 데이터를 암호화해주는 것 (in-flight encryption)

- SSL은 Secure Socket Layer로 연결을 암호화하는데 사용

- TLS는 새로운 버전의 SSL로 Transport Layer Security

• 최근에는 TLS 인증서가 주로 사용된다

- CA에서 발급

- 퍼블릭 SSL 인증서를 로드밸런서에 추가하면 트래픽 데이터를 암호화할 수 있음

- SSL 인증서에는 만료날짜가 있어 주기적으로 갱신하여 인증 상태를 유지

- HTTPS 리스너

• 기본 인증서를 지정해줘야 함
• 다중 도메인을 위해 여러 개의 인증서 등록 가능
• 클라이언트는 SNI( Server Name Indication) 를 써서 접속할 호스트의 이름을 지정 가능
• 구버전 SSL/TLS를 지원하여 레거시 클라이언트를 지원 가능

SNI(server name indication)

- SNI는 여러 개의 SSL 인증서를 하나의 웹 서버에 등록해 하나의 웹 서버가 여러 웹사이트를 지원 가능

???????????

 

connection Draning

- 인스턴스가 등록 취소, 혹은 비정상인 상태일 때 인스턴스에 어느정도 유예 시간을 두어 현재 활성된 요청을 완료할 수 있도록 하는 기능

- 인스턴스가 드레이닝 상태가 되면 ELB는 등록 취소 중(드레이닝 중)인 인스턴스로 새로운 요청을 보내지 않고 현재 연결되어 있는 작업을 다 완료하면 종료

- 아주 짧은 요청인 경우에는 연결 드레인을 적게 둠으로써, EC2 인스턴스가 빠르게 드레이닝 되고 이후 인스턴스에 관한 작업을 수행할 수 있음

 

Auto Scaling Group

- ASG의 목표는 스케일 아웃, 즉 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나 스케일 인, 즉 감소한 로드에 맞춰 EC2 인스턴스를 줄이는 것

- 최소 및 최대 개수를 보장하기 위해 매개변수로 정의 가능

- 로드 밸런서와 페어링 하는 경우 ASG에 속한 모든 EC2 인스턴스가 자동으로 로드밸런서에 연결

- 로드밸런서가 헬스체크를 통해 unhealthy한 인스턴스를 알려주면 EC2를 없앰

- 기능 자체는 무료이고 EC2 인스턴스가 생성된 것에 대해서만 비용을 받음

 

CloudWatch Alarms & Scaling

- CloudWatch 경보를 기반으로 ASG를 스케일 인 및 스케일 아웃 할 수 있음

- 알람이 울리면 지표 - metric ( 평균 CPU 혹은 커스텀 지표를 활용할 수 있음) 스케일링이 시작

- ASG 전체의 평균 CPU가 너무 높으면 지표에 따라 알림이 울리고 스케일링 활동이 발생

- 스케일 조절할 때 좋은 지표는

1. CPU 사용률
2. 대상별 요청수 (RequestCountPerTarget) → 한 번에 대상별로 1,000개의 요청까지만 최적으로 작동하므로 스케일링에 활용 가능
3. Average Network In / Out  → 업로드와 다운로드가 많아 해당 네트워크에서 병목 현상이 발생할 것으로 판단되면 평균 네트워크 입출력량에 따라 스케일 가능
4.  Any Custom metric - 사용자가 마음대로 커스텀 할 수 있다

3개로 분산되기 때문에 RequestCountPerTarget은 3

 

동적 스케일링 정책(<-> 수동 스케일링 정책)

- loudWatch의 경고 상황을 모니터링한 결과에 따라 희망 용량을 증가시키는 방식으로 작동

• Target Tracking Scaling
  • CPU 사용률이 40%에 머무를 수 있도록 할때 사용
  • 기본 기준선을 세워 상시 가용을 유지
• Simple / Step Scaling
  • CloudWatch를 설정하고 CPU 사용률 > 70%라면 유닛 하나 추가
  • CloudWatch를 설정하고 CPU 사용률 < 40%라면 유닛 하나 제거
  • CloudWatch 경보를 설정할 때는 한 번에 추가/제거할 유닛의 수를 단계별로 설정해야한다
• Scheduled Actions
  • 정해진 사용 패턴을 바탕으로 스케일링을 예상
  • 시간이나 특정 일같이 스케일링이 필요함을 미리 알 때에 예정된 작업을 설정하면 된다
• Predictive Scaling
  • AWS 내 오토 스케일링 서비스를 활용하여 로드를 보고서 다음 스케줄링을 예측
  • 머신러닝을 통해 사전에 스케일링 작업을 진행

https://kimjingo.tistory.com/186 를 참고하자.

[AWS] Auto Scailing 그룹 및 옵션(정책)