EC2
EC2는 정말 인기 있는 AWS 서비스이며, Elastic Compute Cloud의 약어다.
EC2는 하나의 서비스가 아닌 다음과 같은 많은 것을 포함하고 있다.
- 임대 가능한 VM
- 데이터를 가상 드라이브 EBS 볼륨에 저장 가능
- Elastic Load Balancer(ELB)로 분산 가능
- Auto Scaling Group를 사용해 서비스 확장 가능
EC2의 기초를 아는 것이 클라우드 동작 방식을 이해할 때 필수적이다.
클라우드는 언제든 컴퓨터를 대여할 수 있는데 대표적인 예시가 EC2이다.
EC2 설정 옵션과 크기
EC2를 처음 생성할 때 다양한 설정 옵션(운영체제, RAM, storage, 방화벽 등)이 존재한다.
- EC2를 생성할 때 리눅스, 윈도우, 맥을 운영체제로 선택할 수 있다.
- 생성할 가상 머시넹 사용할 컴퓨팅 성능과 코어의 양도 선택할 수 있다. 즉, CPU의 개수를 정할 수 있다.
- RAM의 크기도 설정 가능하다.
- storage 크기도 설정이 가능하다.
- 예시로는 네트워크를 통해 연결할 스토리지가 필요한지 여부다.
- 연결할 수 있는 스토리지는 EBS, EFS가 있고 하드웨어를 연결하는 경우 EC2 인스턴스 스토어가 된다.
- EC2에 연결할 네트워크의 종류를 선택할 수 있다. 속도가 빠른 네트워크를 원하는지 ,어떤 종류의 공용 IP 규칙을 원하는지
- 방화벽 규칙도 설정이 가능하다.
- 마지막으로 인스턴스를 구성하기 위한 부트 스트랩 스크립트도 작성할 수 있다.
- 바로 처음에 설정하는 EC2 사용자 데이터이다.
EC2 사용자 데이터
EC2 사용자 데이터 스크립트를 사용해 인스턴스를 부트스트래핑할 수 있다.
부트스트래핑이란?
머신이 작동할 때 명령을 시작하는 것을 의미한다.
스크립트는 처음 가상머신이 시작할 때 한 번만 실행되며, 다시 실행되지 않는다.
부팅 작업을 자동화하기 때문에 부트 스트래핑이라는 이름을 가지게 되었다.
EC2 사용자 데이터는 인스턴스를 부팅할 때 자동화하고 싶은 작업이 존재한다면 사용한다.
자동화하고 싶은 작업의 예시는 아래와 같다.
- 업데이트, 소프트웨어 설치
- 일반적인 파일을 인터넷에서 다운로드
우리가 생각하는 것이 거의 다 가능하며, 사용자 데이터 스크립트에 작업을 더 추가할수록 부팅 시 인스턴스가 할 일이 늘어난다.
참고로 EC2 사용자 데이터 스크립트는 루트 계정에서 실행된다.
그러므로 모든 계정은 sudo를 꼭 붙여야 한다.
EC2 인스턴스 종류, 타입
인스턴스를 중지했다가 다시 시작하면 AWS는 공용 IPV4 주소가 변경된다.
사설 IP는 변경되지 않는다.
EC2 인스턴스 종류는 여러가지가 존재한다.
- t2.micro
- t2.xlarge
- c5.4xlarge
- r5.16xlarge
- m5.8xlarge
여기에는 규칙이 존재한다. m5.2xlarge를 가지고 살펴보자.
- m: 인스턴스 클래스 (m이 범용의 인스턴스 그룹에 보함됨.)
- 5: 인스턴스 세대 (새로운 세대의 하드웨어)
- 2xlarge: 인스턴스 클래스 내에서 사이즈를 의미한다.
- 크기는 small 부터 시작한다.
- 크기가 클수록 메모리와 cpu가 커진다.
EC2 인스턴스 타입은 7가지가 있다. 4가지 정도 살펴보겠다.
General Purpose
범용 인스턴스는 웹 서버나 코드 저장소와 같은 다양한 작업에 적합하다.
컴퓨팅, 메모리, 네트워킹 간의 균형도 잘 맞는다.
Compute Optimized
컴퓨팅 최적화 인스턴스는 컴퓨터 집약적인 작업에 최적화되어 있다.
고성능 프로세스는 어디서 사용하는 것일까?
- 배치 프로세스
- 미디어 트랜스 코딩 작업 시 혹은 고성능 웹서버가 필요할 때
- 고성능 컴퓨팅이라는 HPC 작업을 수행할 때
- 머신 러닝
- 전용 게임 서버가 있을 때
모두 빡센 CPU와 컴퓨팅을 요구한다. 컴퓨팅 최적화 인스턴스는 모두 c로 시작한다.
Memory Optimized
여기서 말하는 메모리는 RAM을 가리키며 메모리 최적화 인스턴스다.
메모리에서 데규모 데이터 셋을 처리하는 유형의 작업에 빠른 성능을 제공한다.
예시는 다음과 같다.
- 인 메모리 데이터베이스가 되는 데이터베이스에서 사용
- Elastic Cache를 예로 들 수 있는 분산 웹 스케일 캐시 저장소에서 사용
- 비즈니스 인텔리전스, BI에 최적화된 인 메모리 데이터베이스와
대규모 비정형 데이터의 실시간 처리를 진행하는 애플리케이션에서 사용한다.
메모리 최적화 인스턴스는 RAM을 나타내는 R로 시작한다.
그러나 X1, Z1같은 대용량 메모리도 존재한다.
Storage Optimized
스토리지 최적화 인스턴스다.
로컬 스토리지에서 대규모의 데이터셋에 액세스할 때 적합한 인스턴스다.
예시는 다음과 같다.
- 고주파 온라인 트랜잭션 처리인 OLTP 시스템에 사용
- 관계형과 비관계형인 NOSQL DB에서 사용
- Redis 같은 메모리 데이터베이스의 캐시나 데이터 웨어하우징 애플리케이션과 분산 파일 시스템에 사용
I, G, H1으로 시작한다.
스토리지 최적화 EC2 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대해 높은 수준의,
그리고 순차적인 읽기/쓰기 액세스 권한이 필요한 워크로드에 적합하다.
보안 그룹
보안그룹은 AWS 클라우드에서 네트워크 보안을 실행하는데 핵심이 되는 부분이다.
- Ec2 인스턴스에 들어오고 나가는 트래픽을 제어한다.
- 보안 그룹은 간단하며, 허용 규칙만 포함된다.
- 출입이 허용된 것이 무엇인지 확인할 수 있고 IP 주소를 참조해 규칙을 만들 수 있다.
- 컴퓨터의 위치나 다른 보안 그룹을 참조한다.
- 보안 그룹끼리 서로 참조 가능하다.
- 외부에서 EC2 인스턴스로 들어오는 것이 허용되면 아웃 바운드 트래픽도 수행할 수 있다.
보안 그룹은 EC2 인스턴스의 방화벽이다.
포트로의 액세스를 통제하며 인증된 IP 주소 범위를 확인해 IPV4, IPV6인지 확인한다.
외부에서 인스턴스로 들어오는 인바운드 네트워크도 통제한다.
인스턴스에서 외부로 나가는 아웃바운드 네트워크도 통제한다.
ec2 인스턴스가 웹사이트에 액세스하고 연결을 시도하면 보안 그룹에서 허용하는 것이다.
중요한 부분은 다음과 같다.
- 여러 인스턴스에 보안그룹을 연결할 수 있음
- 인스턴스에도 여러 보안 그룹을 연결할 수 있음 (다대다)
- 보안 그룹은 지역과 VPC 결합으로 통제되어 있음
- 그래서 지역을 전환하면 새 보안 그룹을 생성하거나 다른 VPC를 생성해야 한다
- 보안그룹은 ec2 외부에 있다
- 그래서 트래픽이 차단되면 ec2 인스턴스는 확인할 수 없다
- ssh 액세스를 위해 하나의 별도 보안 그룹을 유지하는 것이 좋다
- 타임아웃으로 애플리케이션에 접근 못하면 보안 그룹 문제임. 포트 연결해도 멈추면 보안그룹 문제
- 연결을 거부되었다는 응답을 받으면, 보안 그룹은 실행됐는데, 애플리케이션에 문제가 생긴 것. 실행 오류 등
- 기본적으로 모든 인바운드 트래픽은 차단, 모든 아웃 바운드는 허용
- 시큐리티 그룹에 다른 시큐리티 그룹을 참조하는 방법. 로드밸런서에서 이 방식이 좋다
- ec2 인스턴스의 ip와는 상관이 없다.
중요한 포트
- 22: ssh secure shell → 리눅스 용
- 21: FTP File Transfer Protocl
- 22: SFTP Secure File Transfer Protocol
- 80: HTTP
- 443: HTTPS
- 3389 : RDP (Remote Desktop Protocol) → 윈도우 인스턴스에 사용할 때 사용
EC2와 AWS 서비스 연결하기
IAM API 키를 절대 EC2 내부에 연결하지마라.
EC2 인스턴스에 액세스 키 id와 비밀 액세스 키를 입력하는 건 최악의 방법이다.
이 방식 대신에 IAM ROLE을 사용하자.
IAM ROLE을 사용해 EC2 인스턴스에 AWS 자격 증명을 제공하자.
EC2 구매 옵션
On-Demand
- 필요한대로 인스턴스를 실행하는 옵션
- 단기적인 워크로드에 사용하기 좋고, 애플리케이션의 거동을 예측할 수 없을 때 좋다
- 사용한대로 지불
- 비용을 예측하고 초단위로 요금을 지불
- linux와 윈도우는 1분 이후에 초단위로 청구
- 또 다른 모든 운영체제는 1시간 단위로 청구
- 비용이 가장 많이 발생함. 그러나 바로 지불할 금액은 없음. 장기적인 약정도 없다
- 그러나 다른 종류의 워크로드가 있다면 우리는 AWS에 그걸 지정해서 할인을 받고 비용을 최적화할 수 있다
예약 인스턴스(Reserved)
- 오랫동안 사용할거면 이 옵션이 좋다
- On-Demand에 비해 72% 할인을 제공
- 우리는 특정 인스턴스 속성(운영체제, 리전, 인스턴스 타입, 테넌시)을 예약
- 예약 기간을 1년이나 3년으로 지정해서 할인 더 받기 가능하다
- 전부 선결제, 부분 선결제 또는 선결제 없음 중에 선택할 수 있다. 선 결제를 하면 할인이 더 들어간다
- 범위를 특정한 리전이나 존으로 할 수 있다. 특정한 AZ에 있는 예약된 용량을 의미
- DB같은 사용량이 일정한 애플리케이션에 예약 인스턴스를 사용하는 것이 좋다
- 예약 인스턴스를 더 살 수 있고, 더 필요가 없으면 팔 수도 있다.
전환형 예약 인스턴스라는 구매 옵션도 존재한다.
- 인스턴스 타입, 인스턴스 패밀리, 운영체제, 범위, 테넌시를 변경할 수 있다
- 유연성이 크므로 할인은 적다.
- On-Demand의 최대 66퍼 할인
절약 플랜(Saving Plans)
- 기간은 1년, 3년이다.
- 절약 플랜은 특정한 인스턴스 유형을 약정하는 게 아니라 달러 단위로 특정한 사용량을 약정하는 것이므로 좀 더 현대적인 방식이다
- 장기 방식에 좋다. On-Demand에 비해 70퍼 할인
- 그러나 1년 내지 3년 동안 시간당 10달러로 약정을 하게 된다.
- 사용량이 한도를 넘어서면 절약 플랜은 온디맨드 가격으로 청구가 된다
- 절약 플랜을 사용하면 특정 인스턴스와 패밀리, 리전으로 고정된다
- 인스턴스 사이즈, OS, 테넨시는 변경 가능하다
Dedicated hosts (전용 호스트)
- 물리적 서버 전체를 예약해서 인스턴스 배치를 제어할 수 있다
- 전용으로 사용되는 Ec2 인스턴스 용량이 있는 실제 물리적 서버를 받는다
- 법규 준수 요건이 있는 활용 사례나 소켓, 코어, VM 소프트웨어 라이선스를 기준으로 청구되는 기존의 서버에 연결된 소프트웨어 라이선스가 있는 경우에 사용한다
- 이런 경우가 바로 우리가 물리적 서버에 접근하고 전용 호스트를 갖춰야하는 사례이며, 법적 조건이 중요한 경우 사용한다
- 온디맨드로 초당 비용을 지불하거나 1년 또는 3년 예약 가능
- 실제로 물리 서버를 예약하므로 이게 제일 비싸다
Dedicated instances(전용 인스턴스)
- 다른 고객이 하드웨어를 공유하지 않는다
- 물리적 서버와는 다르다
- 우리는 같은 계정에서 다른 인스턴스와 함께 하드웨어를 공유할 수 있다
- 인스턴스 배치에 대한 통제권이 없다
전용 인스턴스란 자신만의 인스턴스를 자신만의 하드웨어에 갖는다.
전용 호스트는 물리적 서버 자체에 대한 접근권을 갖고 낮은 수준의 하드웨어에 대한 가시성을 제공해준다.
Capacity Reservations(용량 예약)
- 원하는 기간 동안 특정한 AZ에 원하는 용량을 예약하는 방식이다
- 원하는 기간동안 특정 AZ에 온디맨드 인스턴스를 예약 한다
- 필요할 때마다 그 용량에 접근 가능하며, 기간 약정이 없다
- 언제라도 용량을 예약하고 취소 가능하다. 청구 할인도 없다. 오직 용량을 예약하는 것이 목적이다
- 만약 청구 할인을 받으려면 지역별 예약 인스턴스와 결합하거나 절약 플랜과 결합해야 한다
- 인스턴스를 실행하는지에 무관하게 온디맨드 요금이 부과된다
- 예약만 하면 실행과 무관하게 비용을 지불해야한다
- 특정한 AZ에 있어야 하는 단기적이고 중단 없는 워크로드에 매우 적합하다
Spot Instances
- 아주 짧은 워크로드를 위한 인스턴스 타입이다. 매우 저렴하다
- 언제라도 인스턴스가 손실될 수 있으므로 신뢰성이 매우 낮다
- 온디맨드 대비 90퍼 할인이 가능하다.
- 그러나 스폿 인스턴스에 대해 지불하려는 최대 가격을 정의하고 만약 스폿 가격이 그걸 넘어버리면 인스턴스가 사라지므로 매우 위험하다
- 가장 비효율적인 인스턴스다. 회복 전략이 있으면 훌륭한 선택
- 사용 예시로는 배치 작업, 데이터 분석, 이미지 처리, 모든 종류의 분산형 워크로드,
또는 시간 시작과 종료 시간이 유연한 워크로드가 있다 - 실패해도 복원력 있는 것에 사용해야한다
- DB와 중요한 작업에는 절대 적절하지 않다
- 어떤 스팟 인스턴스에 대해 지불할 의향이 있는 스팟 최고가를 정의한 후에 인스턴스의 비용이 그것을 넘어가면 인스턴스 없어진다
- 비용이 최고가보다 낮다면 계속 인스턴스를 사용할 수 있다
- 시간 당 스팟 비용은 오퍼 및 용량에 따라 다양하다
- 현재 스팟 가격이 설정한 최대 가격을 넘어가면 멈추거나 종료하거나 2개의 선택지가 있다. 2분의 유예 시간 동안 정하면 된다
- 중단은 스팟을 멈추면 최고가 보다 낮아지면 다시 동작한다. 종료는 아예 종료. 새로 만들어야 한다
다른 전략으로 스팟 블록 사용이 있다.
AWS에게 스팟 인스턴스를 회수당할 일이 없게 하기 위한 전략임스팟 블록이란 특정 기간(1시간 ~ 6시간)동안 인스턴스를 차단하는 기능이다.
문서상 그렇다고 한다. 드물게 회수가 가능하지만, 인스턴스가 회수되지 않는 상황이라고 생각하면 된다.
그러나 2022년 12월 31일자로 종료됐다고 한다. 시험에 나올 수도 있으니 일단 정리했다.
Spot 인스턴스를 종료하는 법
스팟 요청에는 원하는 인스턴스의 개수, 인스턴스 최고 가격, AMI 등 요구되는 사양, 요청의 유효 기간이 있다.
요청의 유형도 포함된다.
요청에는 2가지 유형이 있다.
스팟 인스턴스를 위한 일회성 요청
- 요청이 이행되는 즉시 인스턴스가 실행된다
- 스팟 요청은 바로 사라진다
- 스팟요청이 사라져도 괜찮은 경우에 사용한다
사후 인스턴스를 위한 지속적인 요청
- 스팟 요청의 valid from 부터 valid until 까지 우리가 요청한 개수의 인스턴스들이 유효하게 된다
- 최고 가격을 넘어서 인스턴스가 없어져도 스팟 요청이 다시 연결되어 자동으로 다시 생긴다
스팟 요청이 취소되기 위해서는 open 상태, active 상태, disabled 상태여야 한다.
failed, cancelled, closed면 안된다.
스팟 요청을 취소하려는 경우 취소하게 되면 기존에 실행했던 인스턴스는 종료되지 않는다.
기존에 실행했던 인스턴스를 실행하는 것은 AWS의 역할이 아닌 우리의 역할이다.
스팟 인스턴스를 완전 죽이려면 스팟 요청부터 취소하고 요청과 연결된 인스턴스를 꺼야한다.
인스턴스를 우리가 먼저 죽이면 스팟 요청으로 인해 다시 실행된다.
스팟 플릿
극강의 비용 절감을 위한 것이 스팟 플릿이다.
한 세트의 스팟 인스턴스에다가 온디맨드 인스턴스를 선택적으로 조합해 사용하는 방법이다.
스팟 플릿은 정의된 비용 제한 내에서 대상 용량을 맞추려고 노력한다. 사용 가능한 런치 풀을 사용해서 실행된다.
다양한 인스턴스 유형, 다양한 운영체제 다양한 가용 영역을 가질 수 있다.
여러 개의 런치풀과 여러 개의 인스턴스 크기 등 여러 가지의 모든 것들을 정의하게 된다.
그러고 나면 플릿이 가장 적합하고 좋은 런치풀을 선택해준다.
그리고 스팟 플릿이 정해진 예산 혹은 원하는 용량에 달한 경우에는 인스턴스 실행을 멈춘다.
스팟 플릿내에 스팟인스턴스를 할당해 줄 전략을 정의한다. 이 부분이 시험에 잘 나온다고 한다.
- lowestPrice: 제일 자주 나오며, 스팟 플릿이 가장 적은 피용을 가진 풀에서부터 인스턴스를 실행한다.
이런식으로 비용을 최적화하며, 아주 짧은 워크로드에 적합하다 - diversified: 우리가 정의한 모든 풀에 걸쳐 분산된다. 긴 워크로드에 적합하며, 가용성이 뛰어 한 풀이 중단되더라도 다른 풀이 돌아감
- capacityOptimized: 인스턴스의 개수에 따라서 최적 용량으로 실행된다. 적절한 풀을 찾아준다
스팟 플릿을 이용해 여러 가지 런치풀과 인스턴스 유형을 다양하게 정의할 수 있다
스팟플릿에 lowestPrice 전략을 사용하면 스팟 플릿이 자동으로 최저 가격의 스팟 인스턴스를 요청해준다.
스팟 플릿을 사용하면 스팟 인스턴스에 따라 추가적인 비용 절감이 가능하다.
이유는 적합한 스팟 인스턴스 풀을 선택해주기 때문. 이게 장점이다.
인스턴스 유형과 가용 영역을 선택하는 단순 스팟 요청과 달리 스팟 플릿은 우리의 요구에 따라 모든 것을 최적화 해준다.
워크로드에 어떤 인스턴스 타입이 적합한지 물어보는게 시험문제라고 한다.
참고자료
당신이 지금 알아야할 AWS(이영호)
댓글