[업무에 바로 쓰는 AWS 입문] 3장 EC2 요약

EC2

 - a.k.a 인스턴스

 - 클라우드 공간에서 돌리는, 크기가 유연한 가상 서버

 - 디스크 용량, CPU, 메모리 및 네트워크 등 설정 가능

 - 필요성: 애플리케이션 실행에 필요한 용량/디스크 크기 예측 불가 -> 유연한 볼륨 설정이 가능한 EC2로 고민 해결

 

 

EC2 비용 지불 방법

1) 온디맨드

 - 시간 당 정해진 금액 지불 (선불 개념 없음)

 - 소프트웨어 검증 및 테스트 단계에서 많이 사용

 - 개발 기간이 짧고 개발이 끝나는 시간을 미리 알 수 없을 때 유용

 - 짧고 불규칙한 주기 내 테스트 할 때

 

2) 리저브드

 - EC2 인스턴스를 1~3년 정도 싸게 임대 (a.k.a 비행기 지정석)

 - 개발 시작과 끝을 미리 알고 있을 때 유용

 - 개발 요구 조건이 크게 변경 X / 개발 시간을 잘 알고 있을 때 권장

 - 단점: 인스턴스 크기 늘리거나 줄일 수 없음(최초 지정했던 크기와 설정 고정)

 

3) 스팟

 - 인스턴스 가격 입찰/구매

 - 최소 입찰가 < 인스턴스 가격 < 최대 입찰가: 사용 가능

 - 최대 입찰가 < 인스턴스 가격: 사용 X / 갑자기 냅다 중단

 

 

EBS

- EC2의 스토리지(저장 공간)

- 컴퓨터 : 하드디스크 : 운영체제 & 부팅 관련 파일 = EC2 인스턴스 : 스토리지 : 파일 시스템

- EBS 가용 영역 설정 

 

 

가용 영역

- 여러개의 가용 영역(AZ) ⊂ Region

- 각 가용 영역은 메인 서버에서 만들어지는 일종의 복사본 - 각각의 네트워크 설정, 컴퓨팅 파워 존재

- 가용 영역 1이 셧다운 되더라도 서비스가 가용영역 2에서 백업 & 정상 작동하도록 

출처 : IT 엔지니어를 위한 네트워크 입문

 

 

EBS  타입

 1) SSD

  - 빈번한 읽기/쓰기, "입출력 비중" 클때 사용하면 좋음

   - General Purpose SSD(gp2): standard

   - Provisioned IOPS SSD: 성능 굿, 가격 비쌈

 

 2) Magnetic / HDD

   - 스트리밍 워크로드 등 "처리량"이 방대할 때 사용하면 좋음

   - Throughput Optimized HDD(st1)

      : 실시간 대용량 데이터 처리시 주로 사용

      : 빅데이터 데이터 웨어하우스/로그 프로세싱 등

      : 부트 볼륨으로 사용할 수 없음

  - CDD HDD(sc1)

     : 파일 서버처럼 input/Output이 매우 드문 경우

     : 부트 볼륨으로 사용 불가 / 가격이 너무 착해~

  - Magnetic(standard): HDD 군에서 부트 볼륨으로 사용 가능 / 가격 굿~

 

 

ELB의 타입

 - 서버의 흐름을 각 인스턴스에 공평하게 배분

  1) 애플리케이션 로드 밸런서(ALB)

     - HTTP, HTTPS같은 네트워크 트래픽 제어할 때 적합(HTTP/HTTPS 라우팅 기능)

     - 네트워크 7번째 OSI 레이어(애플리케이션 레이어)에서 작동 -> 해당 레이어에 ALB 존재

     - ALB의 고급 설정 통해 원하는 서버 직접 라우팅(라우팅 커스터마이징 기능)

 2) 네트워크 로드 밸런서(NLB)

     - 네트워크 4번째 OSI 레이어(Transport Layer)에서 작동 -> TCP/IP 모델 포함

     - TCP 트래픽 관리: 초당 수백만 개 이상의 요청에 대한 로드 밸런서(TCP 트래픽 요청 라우팅 기능)

     - Opt 환경에서 주로 활용

 3) 클래식 로드 밸런서(CLB) 

     - ALB와 NL보다 성능 별로 -> 거의 사용 X

     - ALB의 HTTP/HTTPS 라우팅 기능 & NLB의 TCP 트래픽 요청 라우팅 기능 모두 보유

     - 요청과 네트워크의 연결에 근거하여 서버 트래픽 제어 가능 / 단, 네트워크 호스트가 누구인지 알 수 없음(보안 문제)

 

ELB에서 흔히 일어나는 에러

Load Balancer Error: 504 ERROR

   - 애플리케이션이나 서버에서 특정 시간 내 응답 못 받는 경우 발생하는 에러

   - a.k.a Gateway Time Out

   - 서버 레이어, 데이터베이스 레이어에서 발생

   - 로드 밸러는 최대 접속 시간 제한 설정 있음(60s default)

   - 즉, 60초 동안 로드 밸런서가 아무런 데이터를 전달받지 못한 경우 연결 자동 종료 / 타임아웃 에러 생성

   - 애플리케이션 규모가 큰 경우, 최대 접속 시간 늘리기 추천

 

 

X-Forwarded-For 헤더

 - 헤더에서 HTTP/HTTPS 요청을 로드밸런서에서 받을 때 '출처'에 대한 정보 담음

 - HTTP 요청이 프록시 또는 로드 밸런서 같은 중간 서버들을 거쳐 갈 때, 원래 클라이언트의 IP 주소를 식별

 - 유저 - ELB - EC2 순으로 요청의 흐름이 일어날 때, EC2는 ELB의 private IP address만 알 뿐, 유저의 public IP address를 알 수 없음. -> 이를 해결하고자 XFF 헤더 사용 

 

 

EC2 생성 관련 유의점

 - AMI: 애플리케이션 및 이미지 / 인스턴스 생성할 때 돌아가는 운영 체제 설정

 - 키페어: EC2 인스턴스 접속을 위한 정보 / (Mac) 파일 유형 pem 선택, (Window) 파일 유형 ppk 선택 - Putty 프로그램 필수

 - 네트워크 설정

   - VPC:

   - 서브넷: 

   - 보안 규칙에서 "소스 유형 - 위치 무관"은 실무에서 절대 안됌