EC2 - Virtual Machin

Virtual Machin (Amazon EC2)

가상 서버 인스턴스

• 데이터센터 물리 서버 안에 하이퍼바이저를 올리고 Guest OS라고 부르는 가상머신을 올라가게 되는데 VM Service를 AWS는 EC2(Elastic Cloud Compute)라 부름

• 클라우드는 버츄얼머신을 인스턴스로 부른다.

  • 서버에서 필요할 때 빠르게 가져다쓰고 버리고 쉽게 이루어지는것을 강조하기 위해 인스턴스라 표현

AMI (Amazon Machin Image)

• AWS에서 제공하는 가상머신 템플릿

• OS, App, 설정, 데이터 등이 포함되어있음

• AMI를 기반으로 새로운 EC2 인스턴스를 빠르게 생성할 수 있음

가상머신 생명주기

실행 중 (Running)

정지됨 (Stopped)

최대 절전 모드 (Stopped - Hibernate)

• 특정한 OS 기반 인스턴스 타입들은 최대 절전모드를 지원함

• 노트북을 닫아놓는것처럼..?

• 실행중에 비해 컴퓨팅,메모리 비용을 내지 않아도 되고, 사용할 떄 빠르게 부팅업하기 위함

종료됨 (Terminate)

• 많은 사람들이 종료가 되는걸 정지되는거로 착각하고 Terminate를 시켰음

• 인스턴스를 종료시키면 복구가 불가능 (돌이킬수 없어 주의해야함)

인스턴스 타입

ex: c7gn.xlarge

• c: Computed Optimize (Instance family)

• 7: instance generation

• g: AWS Graviation processor (Processor family)

• n: Network and EBS optimized (Adiitional Capability)

• xlarge: Instance Size

클라우드 컴퓨팅 옵션

• 테스트 용도의 인스턴스가 필요하다면 -> T 시리즈

• 가장 범용적인 인스턴스가 필요하다면 -> M 시리즈 / C 시리즈 (arm 프로세서가 사용가능하다면 M7g, C7g)

• HPC(고성능 컴퓨팅) 용도의 인스턴스가 필요하다면 -> HPC 시리즈

• ML을 돌리기 위한 인스턴스가 필요하다면 -> G 시리즈 / P 시리즈 (FPGA가 필요하다면 F 시리즈)

FPGA(Field-Programmable Gate Array) - 하드웨어의 기능을 사용자가 직접 소프트웨어처럼 설계 가능한 칩

로드밸런싱

수신된 트래픽 요청을 EC2 Instance 또는 컨테이너, 특정 IP주소로 라우팅하게 되는 네트워크 스위치

• OSI 7 Layer 전송 계층에서 동작하게되는 로드밸런서

• ELB (Elastic Load Balanacer)

• 기본적으로 하나의 End-point를 갖고있지만 여러개의 가용영역으로 고가용성을 확보할 수 있도록 내부적으로 구현되어있음

로드밸런서 옵션

• ALB: L7(Application 레벨) 레이어에서 동작하는 스마트 라우터

  • Host Header, URI 등을 기반으로 Listener rule 지정 가능

  • 일반적으로 가장 많이 사용하게됨

• NLB: L4(네트워크) 레이어 로드밸런서

  • 초당 수천만건의 트래픽을 감당할 수 있도록 최적화된 성능

  • 워크로드 성격에 따라 ALB 또는 NLB를 많이 사용함

• CLB: 이전 세대의 클래식 로드밸런서

  • 사실상 deplicate를 앞두고 있음

• GWLB: 3rd party 방화벽 등의 네트워크 applicance와 함께 사용하는 전용 로드밸런서

  • Gateway Load balancer

  • 일반적인 목적의 부하분산 용도는 아님

  • 특수한 목적 용도

Instance Customize

일반적으로 static한 설정 (오래걸리는 설정)들은 AMI에 말아넣고, 인스턴스마다 어디서 가져와서 설정해야하는 구성은 user data를 같이 활용하여 부팅

AMI와 User Data 사이에 Sweet Spot을 찾는게 핵심 (효율, 속도, 최적화)

Customized Image

인스턴스 커스터마이징 - AMI

처음 부팅된 깡통(OS만 담긴) 이미지를 가지고 내가 필요한 소프트웨어나 디펜던시, 툴을 모두 설치해서 커스터마이즈된 EC2를 먼저 만듬, 그 후 스냅샷을 찍어서 커스터마이즈된 이미지를 만듬

• base image (AMI) -> OS만 담긴 빈 깡통

• + customizing

• + snapshot

• = customized Image (AMI)

  • 워크로드를 실제로 돌릴 수 있는 AMI 완성!

User Data

인스턴스가 최초 부팅할 때 돌아가는 스크립트

• 인스턴스가 최초 부팅시 UserData가 정의되어있으면 cloud-init 프로세스가 돌면서 user-data에 정의한 스크립트를 실행하여 인스턴스 부트스크래핑

  • 부트스크래핑 -> 스스로를 초기화하거나 시작하는 과정을 의미

  • 작은 시작점에서 출발해 점점 더 큰 시스템을 만들어가는 과정

• 빈 깡통에서 정의한 스크립트를 실행*(설치, 및 설정)하여 워크로드를 실행할 수 있는 EC2로 준비됨

• static한 설정들이 너무 많은 경우 모두 userData에 넣게되면 부팅하는데 시간이 오래걸리므로 오토스케일링에 대응하기가 비효율적으로 변화됨

컨테이너 기반으로 워크로드를 만든다면, 이 컨테이너가 쿠버네티스에 돌리는것으로 구성한다면 기반 AMI가 중요하지 않다.

어차피 호스트레벨은 깡통으로 쓰고, 그 위에 커스터마이즈한 컨테이너 이미지를 가지고 컨테이너를 올려서 사용하는거기 때문에 사실상 인스턴스는 컨테이너를 돌릴 수 있는 호스트 역할만 하면 된다.

그런것들은 이미 AWS에서 기본 AMI로 제공하기 때문에 그런 경우 AMI와 userData를 정의할일은 별로 없긴함, (But EC2 위주의 워크로드라면 자주 사용함)

가상머신 접속

Mac OS의 경우 기본적으로 터미널을 제공하여 사용

Winodw는 쁘띠같은 프로그램을 설치해서 SSH 접속하거나, Remote Desktop을 이용해서 window RDP 접속 등

• 클라우드가 발전하면서 위 접속하는 방식을 재미있게 변경시킴

SSH/RDP Client

• 여전히 SSH/RDP 클라이언트로 접속하는건 유효한 방법이지만 그렇게 하기 위해선 22(SSH) PORT, 3380(RDP)를 EC2 Security Group에서 열어줘야하는 부가 작업이 필요함

Browser Session

• 요즘은 클라우드에서 브라우저 세션을 제공을함

• 브라우저 방식으로 클라우드 WEB UI에서 스트리밍 되는 세션을 열어줌

• 네트워크방식으로 접속하는것이 아닌 API 방식으로 접속하는것이라 취약한 포트를 열어줄 필요없음

• 대신 클라우드에서 기본적으로 통용되는 권한체계(AWS IAM) 권한, 즉 브라우저 세션을 실행할 수 있는 권한을 유저나 ROLE이 갖고있어야함

• 서버 접속마저도 통합해서 관리할 수 있어 운영측면에서 편리함

• 취약한 포트를 열지 않아도 되서 보안적인 측면에도 좋다.