Amazon EC2(Elastic Compute Cloud), EBS(Elastic Block Store), Amazon EFS 및 Amazon FSx

이번 시간에는 Amazon Cloud Computing의 대표 리소스인 EC2와 EBS에 대해 살펴보겠습니다.

EC2는 기존 온 프레미스 구조와 매우 흡사하다고 볼 수 있으며, 쉽게 VM 환경이라고 이해 할 수 있습니다.

 

# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.

 

기존 온 프레미스 VM의 기능과 같이 호스팅, 데이터베이스, 인증 등의 기능을 수행할 수 있으며, 추가적으로 빠른 인스턴스화로 보다 효율적인 리소스 관리 체계 및 유연한 대응 체계를 구축할 수 있습니다.

즉 서버를 다이나믹 컨피그레이션을 적용하여 일회용 리소스로서 사용할 수 있게 되었습니다. 인스턴스의 Hostname, IP 등의 규격을 명시하는 것은 인프라 관점에서 TA의 주요한 역할 중 하나였습니다. 다만 클라우드 환경에서는 명시적으로 고민하기보다 다이나믹한 정보로 접근하도록 하여 자유로운 재 생성, 빠른 반복(Scale-Out 가능), 데이터 기반 의사 결정이 가능해 졌습니다.

다만 VM환경에서 컨테이너 환경으로 넘어가는 이 시점에 EC2 자체만으로는 충분한 서비스를 제공할 수는 없습니다.

따라서 AWS에서는 ECS & EKS 등의 Container 서비스를 추가로 제공하고 있으며, 이에 대한 내용은 이후에 설명하도록 하겠습니다.

AMI (Amazon Machine Image)

제일 먼저 살펴볼 내용은 AMI입니다.

AMI는 이미 사전 구축되어 있는 이미지를 사용하거나, Marketplace 또는 자체 생성 방식으로 AMI를 생성하여 VM을 기동할 수 있습니다.

- AMI는 루트 볼륨용 템플릿 즉 OS를 포함하고 있으며, OS를 구성하는 다양한 라이브러리들이 함께 구성됩니다. 또한 VM 시작 권한 및 OS와 매핑되야 할 블록 디바이스 (EBS 매핑)를 지정합니다.
- 사실 AMI는 SOA 방식에 최적화된 방식으로 그 용도 역시 이와 상응하는 수준으로 제공됩니다. AMI는 반복성 (손쉬운 파기와 유사한 구성으로의 손쉬운 변경), 재사용성, 복구 및 백업 (장애 발생 시 동일 인스턴스로의 이식), AWS Macketplace 솔루션 등의 용도로 사용이 가능합니다.
- EC2 인스턴스를 생성할 경우 특이사항이라고 할 부분은 사용자 데이터를 사용하여 EC2 인스턴스를 시작할 수 있다는 점입니다. (기동 시점에 필요한 사용자 데이터를 정의하여 함께 수행할 수 있도록 명령을 넣을 수 있음) 인스턴스 생성 시점에 결정되는 메타데이터 (Instance-ID, MAC, IP, Hostname, Domain 등)를 수동으로 결정하거나 OS 기동 후 WAS를 자동으로 띄운다거나, Kernel Parameter를 변경한다거나, Update를 한다거나, 소프트웨어를 설치한다거나 등의 작업 등을 일괄적으로 해당 VM을 사용하는 인스턴스에게 적용하는 방식으로 많이 사용됩니다.

이는 Shell 스크립트로도 수행이 가능하지만, CLI 환경에서 cloud-init 명령으로도 수행이 가능합니다.
- 예를 들어 hostname public-hostname으로 메타 정보를 명시하고 싶을 경우 다음과 같이 사용자 데이터를 추가할 수 있습니다.

---

#!/bin/bash

yum update -y
hostname = $(curl -s http://169.254.169.154/latest/meta-data/public-hostname)

---

Amazon EBS (Elastic Block Store)

다음으로 살펴볼 EBS는 쉽게 생각해서 우리가 자주 사용하는 외장하드 정도로 생각할 수 있습니다. 내가 컴퓨터를 쓰다가 에이 몬가 좀 이상한 것들이 많이 깔리고 용량이 부족하고 해서.. 컴퓨터 포맷한번 해야겠다 생각한적 많이 있으실건데, 클라우드 환경으로 접어들면 이러한 생각을 아주 손쉽게 빠르게 할 수 있게 됩니다. 컴퓨터 밀려면 괜히 어디 둔지 모르는 CD를 찾아야 하고 요즘은 CD-ROM도 잘 안써서 음.. 찾기도 힘들고 윈도우 하나 까는데 참 시간 소모 엄청나게 많이 드는데, 클라우드는 날리고 생성하는데까지 대략 잘 정리 된 사이트의 경우 1분 안팍이면 되니 이거 참 휘발성이 어마어마 하다고 할 수 있죠.

여기서 문제는 바로 이 EC2 인스턴스가 가지고 있는 스토리지 공간이 휘발성이라는 것인데, 기껏 작업 다 해놓고 VM을 지웠더니 그 데이터가 어디론가 살아졌다? 당연하죠. 우리 외장하드에 백업하고 포맷을 했어야 하는데 안했으니.

바로 이러한 외장하드 역할을 하는 것이 Amazon EBS입니다.

 

Amazon EBS는 한 번에 한 인스턴스에만 연결할 수 있으며, 볼륨과 동일한 가용영역에 존재해야만 한다는 제약조건이 있습니다. 다시 정리하면 EC2를 기동할때 사용하는 스토리지는 아래와 같이 두가지 방식이 존재합니다.

---

1) 인스턴스 스토리지 방식
- 하이퍼바이저 위에 기동 된 EC2 인스턴스는 외부 공간에 휘발성 루트 디스크를 붙여 기동하는 방식
- 변경된 인스턴스 스토리지를 사용할 경우 기존 정보가 휘발성으로 삭제 됨
2) EBS에 루트 디스크를 위치 시키는 방식
- 하이퍼바이저 위에 기동 된 EC2 인스턴스는 외부 공간에 EBS 루트 디스크를 붙여 기동하는 방식
- EBS 스토리지를 사용할 경우 기존 정보가 그래로 유지 됨
- EBS는 AZ 가용영역 Scope의 서비스
- EBS는 공유가 되지 않음 / 하나의 인스턴스에서만 연결할 수 있음

---

- Amazon EBS의 경우 I/O가 많이 발생되는 시스템으로 기본 네트워크 트래픽과 함께 운영 될 경우 네트워크 밴드위스 초과 또는 I/O Lock / Block 등의 문제를 야기 할 수 있습니다. 따라서 Amazon EBS 최적화 인스턴스를 구성하여 스토리지 트래픽과 네트워크 트래픽이 공유됨에 따른 성능 저하를 막기 위해 분리시켜 운영할 수 있는 트래픽 망을 구성하여 최적화된 EBS를 구성할 수 있습니다.
AWS에서 제공하는 공유 시스템은 앞장에서 살펴본 S3 + EBS가 있지만, 여러 인스턴스가 동일한 스토리지를 사용해야 할 경우에 적합한 EFS/FSx도 있습니다.

---

AWS 공유 파일 시스템
- EBS : 하나의 인스턴스만 연결 / 블록 스토리지
- S3 : 공유는 가능하지만 업데이트가 자주 발생할 경우 비추 / 오브젝트 스토리지
- EFS/FSx : 공유도 가능하고 업데이트가 자주 발생하는 경우 추천 / 파일 스토리지

---

Amazon EFS 및 Amazon FSx

Amazon EFS (Linux 워크로드) : 공유는 가용 영역, 리전, VPC(트래픽을 분리하는 역할, Isolation을 위한 목적으로 출발), 계정 내에서 가능합니다.

Amazon FSx (Windows 워크로드) : 공유는 가용영역 내에서 가능합니다.

# 참조
- VPC는 독립된 공간이지만 VPC 간 통신이 필요할 경우 VPC Peering을 통해 처리가 가능합니다. 결국 VPC Peering이 있기에 리전과 가용 영역(AZ)간에서 처리가 가능해 졌다는 의미로 해석할 수 있습니다.

Amazon EC2 인스턴스

이제 본격적으로 오늘의 메인 Component인 EC2 인스턴스에 대해 살펴보도록 하겠습니다. EC2 인스턴스를 표기하는 방식은 물론 나만의 표기법을 사용할수도 있지만 대체로 아래와 같은 규칙성을 갖고 있습니다.

- m5-large : m[패밀리 이름]5[세대 번호].large[인스턴스 크기]

여기서 패밀리 이름을 결정 짓는 5가지 포인트가 있는데 바로 범용(여섯 가지 선택지)/컴퓨팅 최적화(세 가지 선택지)/메모리 최적화(일곱 가지 선택지)/가속화된 컴퓨팅(네 가지 선택지)/스토리지 최적화(세 가지 선택지)입니다.

---

- 범용 : t는 소규모 프로젝트를 운영하기 위한 용도로써 cpu 기반 순간적인 성능 확장에 최적화
- 컴퓨팅 최적화 : c는 컴퓨팅(CPU) 집약적 워크로드로 저렴
- 메모리 최적화 : r은 메모리 집약적 애플리케이션 최적화
- 가속화된 컴퓨팅 : p는 딥러닝, 머신러닝, 고성능 컴퓨팅 등 GPU 컴퓨팅 애플리케이션에 사용
- 스토리지 최적화 : i는 최대 16TB HDD 기반 높은 디스크 처리량 및 컴퓨팅과 메모리의 균형 제공

- 균형 : m은 컴퓨팅, 메모리, 네트워크에 균형 잡힌 구성 제공

---

# 참조 1

Scale N

- Scale-Out / Scale-In : 인스턴스의 개수를 늘리고 줄이는 방식 (대표적인 방식 웹서비스) / 복제 방식이라 리부팅이 필요하지 않다.
- Scale-Up / Scale-Down : 인스턴스의 크기를 높이고 줄이는 방식 (대표적인 방식 RDS / 데이터베이스) / 리부팅이 필요하다. 즉 서비스 다운타임이 발생할 수 있다.

# 참조 2

Amazon EC2 요금제
- 온디맨드 인스턴스 : 초당 또는 시간당 요금제 (Amazon Linux & Ubuntu는 초당이라 저렴. RedHat Linux의 경우 시간 당 요금제라 잠시 사용해도 1시간 차지됨)
- 예약 인스턴스 : 연단위 계약 (Max 75% 할인 수준까지 절감)
- 스팟 인스턴스 : 지속 시간을 명시하고 운영하는 요금제 / 종료 시간이 정해져 있음 / 입찰가 기준 인스턴스를 뺏길 수 있음 / 입찰가를 뺏겼을 경우 이를 이어서 처리할 수 있도록 Queue를 두고 구성하는 것을 권고

그룹단위로 Amazon EC2 인스턴스를 사용하다보면 어느 순간 확인되지 않은 EC2 인스턴스 들이 눈에 띄기 시작할 것입니다. 이를 어떻게 효율적으로 관리해 나갈 것인가에 대한 고민이 있다면 다음과 같은 정책을 명시적으로 도입하는 것이 중요합니다.

---

1) 메타데이터 태그를 할당하여 필터링 해라
2) 관리/검색/필터링을 통해 일괄 관리할 수 있도록 해라
3) 태그에 대한 표준화 된 대/소문자 구분 형식
4) 승인 받지 않은 태그가 있을 경우 제거하는 방식으로 관리 및 자동화 도구를 사용함(AWS Config)

---

때로는 과감하게 정책을 위반한 EC2 인스턴스의 경우 삭제를 할 수 있을 정도의 그룹 차원에서 명시적인 규율을 정하는 것이 중요할 것입니다.

운영자 입장에서 모르는 인스턴스 하나가 갑자기 나도 모르게 떠있으면 참 난감할 노릇이기 때문이죠.

 

지금까지 살펴본 AWS 스토리지들에 대한 정리본은 다음 AWS 공식 사이트에서 확인할 수 있습니다.

https://aws.amazon.com/ko/products/storage/

클라우드 스토리지 서비스 – Amazon Web Services(AWS)

이번 포스팅에서는 Amazon EC2 인스턴스와 AWS에서 사용가능한 스토리지 유형에 대해 살펴보았습니다.

다음 포스팅에서는 Amazon 데이터베이스에 대해 살펴보겠습니다.