Amazon EC2 이해하기
Amazon EC2 (Elastic Compute Cloud)는 AWS 클라우드 환경에서 기본이 되는 핵심 컴퓨팅 플랫폼이다. EC2는 물리적인 서버 하드웨어를 직접 구매하고 관리할 필요 없이, 가상의 컴퓨터(서버)인 인스턴스(Instance) 라는 단위로 빌려 쓸 수 있게 해준다.
이런 인스턴스에는 Amazon Linux, Windows, macOS 등 다양한 운영체제를 설치하여 실행할 수 있고, 사용자는 인스턴스가 실행 중인 시간에 대해서만 비용을 지불하는 시스템이다.
EC2 : 탄력성
EC2의 가장 큰 장점은 Elastic; 탄력성 이다
- 빠른 장애 복구
물리적인 서버가 고장 나면 수리에 오랜 시간이 걸리지만, EC2 인스턴스에 문제가 생기면 미리 만들어 두었던 동일한 구성의 인스턴스를 빠른 시간 안에 새로 시작하여 즉시 서비스를 복구할 수 있다. - 유연한 확장(Scaling)
- Scale-out/in : 트래픽이나 부하가 증가하면 Auto Scaling Group과 같은 기능을 통해 같은 구성의 서버(인스턴스)를 자동으로 복제하여 부하를 분산시킬 수 있다. 반대로 접속이 줄어들면 불필요한 인스턴스를 자동으로 종료하여 비용을 절감할 수 있다.
- Scale-up/down : 현재 사용 ㅈㅇ인 서버의 사용(ex.
t2.micro)이 부족하면, 인스턴스를 중지한 후 더 높은 사양(ex.t2.large)으로 빠르고 손쉽게 변경할 수 있다.
EC2 인스턴스의 핵심 구성 요소
EC2 인스턴스를 시작(launch)할 때는 가상 컴퓨터를 구성하기 위한 몇 가지 핵심 요소가 있다.
1. AMI (Amazon Machine Image)
AMI는 인스턴스를 시작하는 데 필요한 모든 소프트웨어 정보가 담긴 루트 볼륨 템플릿이다. 여기에는 운영 체제 만이 아니라 필요한 애플리케이션이나 설정(ex. 웹 서버)이 포함될 수 있다. 사용자는 AWS가 제공하는 기본 AMI, 서드파티가 제공하는 AMI 또는 자신이 직접 설정한 인스턴스를 기반으로 고객 생성 AMI를 만들 수 있다. 사용자 지정 AMI를 사용하면 동일한 설정의 서버를 빠르고 일관되게 복제, 배포할 수 있다.
2. 인스턴스 유형 (Instance Type)
인스턴스 유형은 인스턴스가 사용할 물리적 호스트 컴퓨터의 하드웨어 사양을 결정한다. 이는 CPU, 메모리, 스토리지 및 네트워킹 용량의 여러 조합을 제공한다.
- 유형 이름 규칙 : 예를 들어,
t2.micro는 아래와 같이 구성된다.t: 인스턴스 패밀리 (T는 버스트 가능한 범용 유형)2: 세대micro: 인스턴스 크기 (CPU와 메모리 용량)
- 패밀리 : 워크로드에 따라 범용(T, M 계열), 컴퓨팅 최적화(C 계열), 메모리 최적화(R, X 계열) 등 다양한 유형을 선택할 수 있다.
3. 네트워크 (Network Configuration)
EC2 인스턴스는 반드시 VPC(Virtual Private Cloud)라는 논리적으로 격리된 가상 네트워크 환경 내 특정 서브넷(Subnet)에 배포되어야 한다. 또한, 인스턴스에 대한 인바운드/아웃바운드 트래픽을 제어하는 가상 방화벽인 보안 그룹(Security Group)을 필수로 지정해야 한다. 인터넷과 통신이 필요할 경우, 공인 IP 자동 할당(Auto-assign public IP) 옵션을 활성화하면 된다.
4. 스토리지 (Storage)
모든 EC2 인스턴스는 운영체제가 설치될 루트 스토리지 볼륨이 필요하다.
- EBS (Elastic Block Store)
가장 일반적으로 사용되며, 인스턴스가 중지되거나 종료되어도 데이터가 보존되는 영구적인 네트워크 연결 디스크이다. OS용 루트 볼륨 외에 데이터 저장을 위한 추가 볼륨(데이터 볼륨)을 연결할 수 있다.
5. 키 페어 (Key Pair)
인스턴스에 안전하게 접속하기 위한 인증 수단이다. 키 페어는 퍼블릭 키와 프라이빗 키로 구성된다. AWS는 인스턴스 내부에 공개키를 저장하고, 사용자는 개인 키 파일(.pem, .ppk)을 보관하다가 SSH(Linux)나 RDP(Windows)로 접속 시 본인 인증에 사용한다.
6. Advanced setting
User Data (사용자 데이터)
인스턴스를 처음 시작할 때 자동으로 실행할 스크립트를 지정하는 기능이다. 이를 통해 OS 업데이트, 소프트웨어 설치, 서비스 시작(ex. 웹 서버)와 같은 일반적인 구성 작업을 자동화할 수 있다.
- ex) Linux에서 Apache 웹 서버 설치 및 실행하는 작업
#!/bin/bash
yum update -y
yun install -y httpd
service httpd start
chkconfig httpd onTenancy (테넌시) Hardware
테넌시 설정은 EC2 인스턴스가 실행되는 물리적 하드웨어의 격리 수준을 결정한다.
- 공유 (Shared) : 기본값이다. 인스턴스는 다른 AWS 고객과 물리적 하드웨어를 공유하는 멀티테넌트(Multi-tenant) 환경에서 실행된다. 대부분의 워크로드에 적합하고, 가장 비용 효율적이다.
- 전용 인스턴스 (Dedicated Instance) : 인스턴스가 사용자의 계정 전용 하드웨어에서 실행된다. 하드웨어는 동일 계정 내 다른 전용 인스턴스와 공유될 수 있지만, 다른 AWS 고객과는 격리된다.
- 전용 호스트 (Dedicated Host) : 사용자가 물리적 서버 전체를 독점적으로 임대하는 방식이다. 특정 규정 준수 요구사항(Compliance)을 충족하거나, Windows Server 또는 SQL Server처럼 기존에 보유한 라이선스(BYOL: Bring Your Own License)를 물리적 코어 수 기준으로 사용해야 할 때 유용하다. 하드웨어에 대한 강력한 제어권과 가시성을 제공해준다.
Instance Profile (인스턴스 프로필)
인스턴스 프로필은 EC2 인스턴스에 IAM 역할(Role)을 연결하는 컨테이너이다.
EC2 인스턴스 내부에서 실행되는 애플리케이션이 S3 버킷에 파일을 업로드하거나 DynamoDB 테이블을 조회하는 등 다른 AWS 서비스에 접근해야 할 때가 있다. 이때에 액세스 키(Access Key) 같은 장기 자격 증명을 인스턴스 내부에 저장하는 것은 보안상 매우 위험하다.
인스턴스 프로필을 사용하게 되면, 인스턴스에 특정 권한을 가진 IAM 역할을 할당할 수 있다. 인스턴스는 이 역할을 통해 자동으로 임시 보안 자격 증명(Temporary Credentials)을 발급받아 다른 AWS 서비스에 안전하게 접근할 수 있다.
Placement Group (배치 그룹)
배치 그룹은 상호 의존적인 EC2 인스턴스 그룹을 AWS 인프라 내에 어떻게 물리적으로 배치할 지 전략을 결정하는 기능이다. 워크로드의 특성에 따라 네트워크 지연 시간, 고가용성 등을 최적화할 수 있다.
- 클러스터 (Cluster) : 인스턴스들을 단일 가용 영역(AZ) 내에서 최대한 가깝게(동일한 랙) 배치한다. 인스턴스 간의 네트워크 지연 시간을 최소화하고 처리량을 극대화하는 데 중점을 둔다. 고성능 컴퓨팅(HPC)이나 실시간 데이터 처리처럼 노드 간 통신이 매우 빈번한 애플리케이션에 적합하다.
- 파티션 (Partition) : 인스턴스들을 하나의 AZ 내에서 논리적인 파티션(별개의 랙)으로 분산시킨다. 각 파티션은 독립된 하드웨어 세트를 가지기 때문에 랙 수준의 하드웨어 장애가 발생하더라도 다른 파티션의 인스턴스에는 영향을 주지 않는다. Hadoop(HDFS), Kafka, Cassandra와 같은 대규모 분산 및 복제 워크로드의 가용성을 높이는 데 사용된다.
- 분산 (Spread) : 각 인스턴스를 물리적으로 완전히 분리된 하드웨어(서로 다른 랙)에 개별적으로 배치한다. 이는 소수의 핵심적인 인스턴스들이 동시에 장애를 겪을 위험을 최소화해 최대 내결함성을 확보하기 위한 것이다.
인스턴스 요금 옵션
워크로드의 특성에 따라 비용을 최적화할 수 있는 다양한 요금 옵션이 존재한다.
- 온디맨드(On-Demand) : 약정 없이 사용한 시간(초 단위)만큼 비용을 지불하는 가장 유연한 방식이다
- 예약 인스턴스(Reserved Instances) : 1년 또는 3년의 기간을 약정하는 대가로 온디맨드 대비 상당한 할인을 제공받는다. 꾸준히 사용량이 예측되는 워크로드에 적합하다.
- 스팟 인스턴스 (Spot Instance) : AWS의 여유 컴퓨팅 용량을 입찰 방식으로 사용하는 방식이다. 온디맨드 대비 최대 90%까지 할인되지만, AWS가 해당 용량을 필요로 하거나 사용자의 입찰가보다 스팟 가격이 높아지면 인스턴스가 중단될 수 있다. 그렇기 때문에 장애에 유연하게 대처할 수 있는 워크로드인 배치 작업이나 빅데이터 분석 등에 적합하다.
Amazon EBS와 스냅샷
EBS
Amazon Elastic Block Store(Amazon EBS)는 영구적인 블록 스토리지 볼륨으로, EC2 인스턴스와 조합하여 사용한다. EC2 인스턴스를 위한 가상의 외장 하드 드라이브라고 생각할 수 있따. 가장 큰 특징은 EC2 인스턴스의 수명 주기와 독립적으로 데이터를 보존할 수 있다는 점이다.
- 가용 영역(AZ) 종속성 : 각각의 EBS 볼륨은 특정 가용 영역 내에서 생성되며 자동으로 해당 AZ 내의 여러 서버에 복제되어 구성 요소 장애로부터 보호된다. 따라서 단일 AZ 내에서는 높은 내구성과 가용성을 보장한다.
EBS의 주요 기능과 유형
EC2의 스토리지
EC2 인스턴스의 부팅 볼륨(루트 볼륨)과 데이터 볼륨으로 모두 사용될 수 있따. 운영체제는 루트 볼륨에 설치되며, 애플리케이션 데이터나 파일은 별도의 데이터 볼륨에 저장하여 관리하는 것이 일반적이다.
EBS의 유형
애플리케이션이 필요한 스토리지 성능에 따라 블록 유형을 선택 가능하다. EBS의 읽기/쓰기 성능은 주로 초당 입출력 처리량인 IOPS(Input/Output Operations Per Second) 단위와 처리량(Throughtput)으로 측정된다.
대표적인 스토리지로는 HDD와 SSD가 있다.
- HDD (Hard Disk Drive) : 대용량을 지원하며 SSD에 비해 저렴하지만 성능이 낮다. iOPS보다 처리량이 중요한 대용량 데이터 워크로드에 적합하다.
- 처리량 최적화 HDD (st1) : 빅데이터 분석, 데이터 웨어하우징, 로그 처리와 같이 크고 순차적인 데이터 액세스가 잦은 워크로드에 최적화된 저비용 스토리지이다.
- 콜드 HDD (sc1) : 액세스 빈도가 매우 낮은 데이터의 대규모 저장을 위한 가장 저렴한 옵션이다. 데이터 아카이빙이나 백업 용도로 사용된다.
- SSD (Solid State Drive) : 가격이 비싸지만 IOPS가 빠르다.
- 범용 SSD (gp3, gp2) : 가격과 성능 간의 균형을 제공하여 가장 많이 사용된다. 시스템 부팅 볼륨, 개발 및 테스트 환경, 지연 시간에 민감하지 않은 대부분의 애플리케이션에 적합하다. 특히 gp3는 IOPS와 처리량을 스토리지 크기와 별개로 독립적으로 프로비저닝할 수 있어 비용 면에서 효율적이다.
- 프로비저닝된 IOPS SSD (io2 Block Express, io1) : 고성능과 일관된 저지연 시간이 요구되는 애플리케이션을 위해 설계되었다. 대규모 관계형 DB나 NoSQL DB와 같은 고성능 워크로드에 이상적이다.
EC2와 EBS
EC2 생성 시 EBS 볼륨 생성
EC2 인스턴스를 생성할 때, EBS 볼륨을 필수적으로 구성해야 한다.
- 루트 볼륨(OS 볼륨) : 인스턴스의 운영체제가 설치되는 볼륨이다. 기본적으로 ‘종료 시 삭제’ 옵션이 활성화되어 있어 인스턴스를 종료하면 루트 볼륨도 같이 삭제된다.
- 데이터 볼륨 추가 : OS와 데이터를 분리하여 관리하기 위해 하나 이상의 데이터 볼륨을 추가할 수 있다. 데이터 볼륨은 기본적으로 ‘종료 시 삭제’ 옵션이 비활성화되어 있어서 인스턴스를 종료해도 데이터가 보존된다.
EBS 백업 : 스냅샷(Snapshot)
스냅샷은 특정 시점의 EBS 볼륨을 Amazon S3에 저장하는 백업이다. 데이터 보호와 복구를 위한 핵심 기능이다.
EC2 인스턴스 연결 방법 - SSH
EC2 인스턴스에 원격으로 접속하기 위해서는 SSH 프로토콜을 사용한다. 이 과정에서 키 페어를 이용한 공개 키 암호화 방식으로 안전하게 인증을 한다.
- 키 페어 작동 원리 : 공개 키와 개인 키 한 쌍으로 구성된다.
- 공개키 : EC2 인스턴스 내부에 저장된다
- 개인키 (.pem) : 사용자가 직접 다운로드해 안전하게 보관해야 한다
- 접속 과정 : 사용자가 PuTTY, Tera Term, Git Bash와 같은 SSH 클라이언트를 사용하여 접속을 시도하고 클라이언트는 개인 키를 사용하여 사용자의 신원을 증명한다. EC2 인스턴스 내부에 저장된 공개 키와 대조하여 일치하는 경우에만 접속이 허용된다.
