[2장] Amazon Elastic Compute Cloud와 Amazon Elastic Block Store

2장에서는

EC2 환경을 완벽하게 활용하기 위한 도구와 활용 사례를 알아본다. 

 

프로젝트에 적합한 하드웨어 리소스 구성 및 EC2 인스턴스 프로비저닝 

애플리케이션 요건에 맞는 운영체제 구성

인스턴스에 필요한 안전하고 효과적인 네트워크 환경 구축

인스턴스에 부팅 스크립트 추가로 애플리케이션을 시작/지원

기관의 요구에 부합하는 EC2 요금 모델 선택

EC2 인스턴스 수명 주기 관리 및 활용 방법 

처리 성능 요구에 맞는 스토리지 드라이브 유형 선택

키 페어 보안그룹 IAM 역할을 이용한 EC2 리소스 보호

관리자 또는 최종 사용자로 인스턴스에 액세스하는 방법 

 

EC2 인스턴스

물리서버의 기능을 함축적으로 가상화 했지만 실제 서버와 유사하게 작동하며, 스토리지, 메모리, 네트워크 인터페이스 그리고 운영체제가 새로 설치된 기본적인 드라이브가 제공된다. 

 

사용자는 인스턴스에서 사용할 리소스의 종류 운영체제 종류 실행할 소프트웨어 스택을 선택해서 인스턴스의 운영비용을 결정한다. 

 

인스턴스 프로비저닝

사용자는 운영체제, 소프트웨어 스택, 하드웨어 사양, 인스턴스를 시작할 환경을 구성할 수 있다. 운영체제는 아마존 머신 이미지를 선택하고 하드웨어는 인스턴스 유형으로 지정한다. 

 

머신 이미지

EC2를 시작할 때 루트 볼륨에 설치될 운영체제와 소프트 웨어를 기술한 템플릿 문서 이며 네가지 AMI 가 있다. 

 

빠른시작 AMI

인스턴스 시작 콘솔 화면의 맨 위에 있으며 다양한 리눅스 베포판 등 공동 작업을 수행하기 위한 특수이미지를 포함하고 최신 버전으로 업데이트 하고 공식적으로 지원한다. 

 

마켓 플레이스 AMI

프로덕션(실제 서비스가 운영되는)환경에서 사용가능한 공식 이미지이며 시스코와 같은 공급업체가 제공하고 지원한다. 

 

커뮤니티 AMI

십만개 이상의 이미지가 제공되고 있으며 특정한 요구에 맞도록 공급업체가 제작하고 관리한다.

 

프라이빗 AMI

사용자가 자체 배포한 인스턴스에서 이미지를 생성하여 저장하면 자체 AMI를 만들 수 있다. 

 

청구에 관한 주요 사항 

EC2 인스턴스의 기본 요금과는 별도로 소프트웨어의 시간당 사용량 또는 라이선스 요금이 계정에 청구될 수 있다. 

 

인스턴스 유형 

하드웨어 프로파일 즉 인스턴스 유형에 따라 하드웨어 리소스를 인스턴스에 할당한다. 인스턴스 유형은 어떤 워크로드를 계획하고 있느냐에 따라서 달라진다. 

 

인스턴스 환경 구성

유형 선택만큼 중요한건 어디에서 운영할지 이다. 지리적 리전, 가상 프라이빗 클라우드, 테넌시 모델을 살펴본다. 

 

AWS 리전

AWS는 전 세계 데이터 센터에 서버를 보유하고 있으며 이는 지리적 리전으로 구성되어 있다. EC2 리소스는 사용자가 선택한 리전에서만 관리할 수 있으며 기본값을 CLI나 SDK에서 설정한다. 리전마다 서비스의 기능 특징, 비용이 다르다. 

VPC

가상 프라이빗 클라우드는 훌륭한 AWS 네트워크 구성 도구로서 인프라를 쉽게 구성할 수 있게한다. VPC를 사용하면 인스턴스를 다른 인스턴스와 쉽게 분리해서 실행할 수 있고 프로젝트 단위나 단계별로 만들어 사용할 수 있다. 예를 들어 

테스트, 스테이징, 프로덕션으로 나누어 사용할 수 있다. 

 

NAT 게이트웨이나 VPN 연결을 사용하지 않는다면 간단한 생성에는 비용이 들지 않는다. 

테넌시

인스턴스를 시작할 때 테넌시 모델을 선택할 수 있다. 기본 설정은 공유 테넌시이며 여러 인스턴스가 한 물리서버에서 동시에 가상머신으로 실행된다. 기본 설정은 공유 테넌시 이며 여러 인스턴스가 한 물리서버에서 동시에 가상 머신으로 실행된다. 

같은 물리 서버에서 다른 AWS 고객이 소유한 가상머신이 동시에 실행될 가능성은 있어도 인스턴스에 안전하지 않은 상호작용이 발생할 가능성은 희박하다. 

 

조직의 규정에 인스턴스를 다른 환경과 특별히 격리해야하는 규제사항이 있는 경우 전용인스턴스를 선택하면 그 조직만을 위한 서버에서 인스턴스가 실행된다. 단 전용 인스턴스와 전용 호스트는 공유 테넌시를 사용하는 인스턴스보다 높은 비용이 부과 된다.

 

인스턴스 동작 구성

EC2 에서 인스턴스 구성 단계에서 사용자 데이터를 지정해 인스턴스가 부팅할 때 명령을 실행할 수 있게하는데, 이를 부트 스트랩이라고 한다. 스크립트 파일을 작성해 콘솔에서 인스턴스를 시작할때 인스턴스의 세부 정보 구성에서 지정하거나 CLI 에서 user-data 값을 사용하면 필요한 상태로 인스턴스를 구성할 수 있다. 

 

사용자 데이터는 웹 서버를 설치하고 웹 루트에 배포하는 간단한 명령으로 구성할 수 있고 엔터프라이즈 기반 플랫폼에서 작업노드를 설정하는 등 정교한 스크립트로 구성할 수 있다. 

 

인스턴스 요금

세가지 모델 중 하나를 선택해 EC2 인스턴스를 구매해서 사용할 수 있다.

 

보통 12개월 미만으로 언제든지 시작할 수 있는 인스턴스를 배포할 때는 시간당 요금으로 지급하는 온디맨드 모델을 선택한다. 

 

필요에 따라 인스턴스를 시작하고 중지해서 비용을 철저하게 관리할 수 있지만 다른 모델과 비교하면 시간당 요금이 가장 비싸다. 

 

인스턴스를 1년이상 가동할 계획이라면 1년 또는 3년 기간 약정으로 예약 인스턴스를 구매하면 대폭 할인된 요금 해택을 누릴 수 있다.

 

갑자기 중단 돼도 피해가 크지 않은 워크로드를 가동할때 스팟 시장에서 인스턴스를 구매하면 비용이 많이 절감된다. 스팟 인스턴스의 개념은 특정 리전에서 실행되는 인스턴스 유형에 대해 사용자가 최대 입찰 요금을 입력해서 인스턴스를 사용하는 것이다. 

 

인스턴스를 종료하면 기본 스토리지(인스턴스 스토어)에 저장된 데이터는 삭제되는것이 기본이지만

EBS 를 사용하면 인스턴스가 종료된 후에도 데이터를 유지할 수 있다. 

 

인스턴스 수명 주기

EC2 인스턴스의 상태를 관리하는 방법은 몇가지가 있다. 어떤 방법을 적용하든 인스턴스를 종료하면 사용하던 리소스는 AWS 풀로 반환된다. 

 

인스턴스를 일정기간동안 사용하지 않을 때는 인스턴스를 중지해 놓고 필요할 때 재시작하면 비용을 절약할 수 있다. 

다만 이때 인스턴스 스토어 볼륨의 데이터는 삭제된다. 

 

또한 인스턴스에 할당된 임시 퍼블릭 IP 주소는 중지했다가 재시작하면 대개 다른 주소로 바뀌며 재시작 해도 바뀌지 않은 IP 주소가 필요하면 탄력적 IP 주소를 할당해서 인스턴스에 연결해야한다. 

 

인스턴스가 실행되는 동안에도 언제나 보안 그룹을 편집하거나 변경해서 인스턴스 액세스 정책을 업데이트 할 수 있고 물리서버에서 작업하듯이 인스턴스 유형을 변경해 메모리 스토리지 용량을 줄이거나 늘릴 수 있지만 인스턴스를 중지하고 유형을 변경한 뒤에는 반드시 다시 시작해야한다.

 

리소스 태그

AWS 계정에 리소스를 많이 배포할수록 리소스를 제대로 추적하기 어려워진다. 또한 VPC 두세개에 스토리지 볼륨, 보안 그룹, 탄력적 IP 주소를 연결한 EC2 여러개를 분산해 놓으면 매우 복잡해진다. 

 

이런 경우, 리소스를 빠르게 식별할 수 있도록 리소스마다 목적 및 다른 리소스와의 관계를 지정해 놓으면 복잡성이 줄어들텐데, 이를 위한 가장 좋은 방법은 일관된 명명 규칙에 따라 태그를 붙이는 것이다. 

 

AWS 계정에서는 리소스에 식별 표를 붙일 수 있으며 이것이 바로 리소스 태그다. 

 

EC2를 비롯해 AWS 환경에서 사용할 수 있는 모든 리소스에 태그를 붙일 수 있으며 하나의 태그는 키와 값으로 구성된다. 프로덕션에 배포한 각 구성요소에 태그를 연결할 때, 서버 인스턴스의 키로 프로덕션서버, 값으로 서버1, 서버2등을 지정할 수 있다. 서버에 연결된 보안 그룹에도 키는 프로덕션 서버로 값은 시큐리티그룹1 으로 부여할 수 있다. 태그를 적절히 사용하면 리소스의 가시성을 높이고 더 쉽고 효과적으로 관리할 수 있다. 

 

서비스 할당량

기본적으로 AWS 계정당 시작할 수 있는 특정 서비스의 인스턴스 수는 제한 되어있다. 계정 내에서 리전당 할당량이 있는 서비스도 있고 글로벌 할당량이 있는 서비스도 있다. 예르르 들어 한 리전당 만들수있는 VPC는 5개고 계정당 허용된 키페어는 5000개 이다. 많일 사용자가 특정서비스의 할당량을 올리길 원한다면 AWS에 요청하면된다. 

 

EC2 스토리지 볼륨 

스토리지 볼륨은 물리 드라이브를 가상으로 나눈 공간이며, 인스턴스에서 실행되는 운영체제에서는 모든 AWS 볼륨이 실제 물리 드라이브 처럼 보인다. 

 

EBS 볼륨

EBS는 필요한 수만큼 인스턴스에 연결할 수 있으며, 물리서버의 하드 드라이브, 플래시 드라이브 USB 드라이브와 유사하게 사용된다. 물리 드라이브에서와 같이 어떤 EBS 볼륨 유형을 선택하느냐에 따라 성능과 비용은 달라진다. 

 

AWS는 SLA 에서 99.9% 가용성으로 EBS 볼륨에 저장한 데이터의 안정성을 보장하고 있으므로 장애에 대한 걱정은 하지 않아도 된다. EBS 드라이브에 장애가 생겨도 그 데이터는 이미 중복으로 저장돼 있어서 문제를 인식하기 전에 복구될 가능성이 크다. 따라서 사용자는 실질적으로 얼마나 빠르고 효과적으로 액세스 할 것인가에 관심을 기울이면 된다. 

 

현재 EBS 볼륨 유형에는 SSD 기술을 사용하는 두가지 유형과 기존 HDD 기술을 사용하는 두가지 유형이 있다. 불륨 유형의 성능은 최고 IOPS 로 측정한다. 

 

EBS 볼륨 기능

모든 EBS 볼륨은 스냅샷을 통해 복사할 수 있고, 기존 스냅샷을 다른 인스턴스에 공유해서 연결할 수 있으며, AMI로 등록할 수 있는 이미지로 변경할 수 있다. 실행중인 인스턴스에 연결된 EBS 볼륨에서도 직접 AMI 이미지를 생성할 수 있지만 데이터 손실이 없게하려면 우선 인스턴스 운영체제를 종료하고 이미지를 생성하는 것이 좋다. 

 

EBS 볼륨을 암호화해서 EC2 인스턴스가 저장하거나 송수신 하는 데이터를 보호할 수 있으며 EBS 에서는 내부에서 암호화키를 자동으로 관리하거나 KMS 에서 제공하는 키를 사용할 수 있다. 

 

인스턴스 스토어 볼륨

인스턴스 스토어 볼륨은 EBS 볼륨과는 다른 임시 디스크며, 디스크가 연결된 인스턴스가 종료됐을 때 저장된 데이터는 영구히 삭제된다. 

 

EBS 대신 인스턴스 스토어를 사용하는 이유는 다음과 같다. 

 

인스턴스 스토어 볼륨은 인스턴스를 호스팅하고 있는 서버에 물리적 고속 인터페이스로 연결된 SSD 이다. 

 

인스턴스 스토어 볼륨 요금은 인스턴스 요금에 포함되어 있다. 

 

인스턴스 스토어 볼륨은 단기 수행역할 이나 외부에서 데이터를 가져와서 처리 후 폐기하는 배포 모델에서 특히 적합하다. 

 

인스턴스 스토어 볼륨을 사용할 수 있는 인스턴스 유형은 따로 있으므로 배포할 때 이 점을 염도해야한다. 

 

EBS와 인스턴스 스토리지를 잘 사용하고 있더라도 외부에 대용량 데이터 세트를 두는 것이 훨씬 나을 때가 있다 S3 서비스의 사용사례는 다양하며 컴퓨팅 작업에 직접 사용되는 파일 부터 데이터 베이스까지 저장할 수 있으면서도 훨씬 저렴하게 사용할 수 있다. 

 

인스턴스 액세스

인스턴스는 네트워크에 연결된 모든 장치와 마찬가지로 고유한 IP로 식별된다. 모든 인스턴스에는 기본적으로 최소 한개의 프라이빗 IPv4주소가 할당된다. 

 

프라이빗 서브넷에서 만들어진 인스턴스는 서브넷 내부에서만 통신할 수 있고 인터넷과 직접 연결할 수 없다. 

 

다른 리소스와 연결이 필요로 되는 인스턴스에 여러개의 네트워크가 있어야 하는 경우 하나 이상의 가상 탄력적 네트워크 인터페이스를 만들어 인스턴스에 연결할 수 있다. 

 

이때, 각각의 인터페이스는 기존 서브넷과 보안그룹에 연결돼어 있어야 하며, 인터페이스에 서브넷 범위의 정적 IP 주소를 할당하거나 인터넷에 액세스 하기 위한 퍼블릭 IP 주소를 할당할 수 도 있다. 앞서 인스턴스 수명주기에서 살펴봤듯 인스턴스에 할당된 기본 퍼블릭IP 는 일시적이고 재부팅하면 바뀔수 있으므로 장기적인 배포를 위해서는 영구적이고 탄력적인 IP를 할당하는 것이 바람직 하다. 

 

실행중인 인스턴스에 연결돼 있기만 하면 탄력적 IP 에는 비용이 부과되지 않는다. 

 

2장 후반부에서는 보안 측면에서 관리자로 인스턴스에 액세스 하는 방법을 다룬다. 실행중인 인스턴스에 대한 많은 정보를 인스턴스 메타 데이터 시스템을 통해 확인할 수 있으며, 인스턴스에 로그인 한 후 명령줄에서 curl 명령을 실행하면 아래와 같은 데이터 목록이 표시된다. 

인스턴스 보안

사용자에게는 무단으로 EC2 인스턴스가 사용되지 않도록 적절하고 효과적으로 액세스 제어를 구성해야할 책임이 있다. 

AWS 는 이를 위해 보안그룹, IAM 역할, NAT 인스턴스 , 키페어 등 네가지 도구를 지원한다.

 

보안 그룹 

보안 그룹은 방화벽 역할을 한다. 보안 그룹의 기본 설정은 수신하는 모든 트래픽을 거부한다. (수신 거부) 보안 그룹에 지정한 트래픽 유형만을 허용하는 정책 규칙을 설정하며, 네트워크에서 송수신하는 모든 데이터 패킷은 그 규칙에 따라 평가해서 허용 또는 거부된다. 

 

보안 그룹은 원본과 대상 대상 네트워크 포트 사용 프로토콜을 검사해서 트래픽을 재평가 한다. 예를 들어 사무실 컴퓨터의 퍼블릭 IP 주소를 원본 IP 주소로 하고 TCP-SSH(22) 포트를 사용하는 패킷이 특정 인스턴스에 액세스 하도록 허용할 수 있다. 

 

보안 그룹에서는 정교한 규칙 세트를 쉽게 만들어서 서비스 액세스를 관리할 수 있으므로 전 세계에 웹사이트를 공개하더라도 백엔드 서버에는 팀 구성원만 액세스 하게 할 수 있다. 

 

보안 그룹에서는 인스턴스 수준에서 트래픽을 제어한다 

인스턴스 수준이 아닌 서브넷 수준에서 트래픽을 제어할때는 NACL을 사용한다. 

 

IAM 역할

IAM 역할을 사용해서 EC2 인스턴스를 비롯한 AWS 리소스에 액세스하는 것을 제어할 수 있다. IAM 역할은 AWS 계정 내 특정 서비스 또는 리소스에 작업을 수행할 수 있는 권한을 부여하며 특정 사용자나 리소스에 역할을 할당하면 그 사용자나 리소스는 역할 정책에 포함된 다른 리소스에 액세스 할 수 있다. 

 

제한된 수의 다른 리소스나 사용자에게 역할을 부여하면 EC2 인스턴스 등의 리소스에 독점적으로 액세스 할 수 있는 권한을 부여할 수 있다. 

 

NAT 디바이스

때로는 EC2 인스턴스에 퍼블릭 IP 주소를 연결하지 않고 네트워크 노출을 제한할 필요가 있다. 그러나 보안 패치와 소프트웨어 업데이트 등을 받으려면 제한적으로 인터넷에 연결돼야하는 문제점이 있다. 

 

이를 해결하는 방법은 특수한 장치를 통해 프라이빗 인스턴스에서 인터넷으로 향하는 트래픽을 라우팅하는 것이다. 이를 위해 AWS는 NAT 인스턴스와 NAT 게이트웨이를 제공해서 트래픽을 라우팅하게 한다. NAT 게이트웨이는 관리형 이므로 직접 인스턴스를 시작하고 유지 관리할 필요가 없다. 두가지 모두 매월 요금이 청구된다. 

 

키 페어

관리를 위해 실행중인 인스턴스에 연결할 때 암호화 되지않은 일반 텍스트를 사용한 원격 세션 연결방식은 사용하지 않는다 세션을 제대로 보호하혀면 키 페어를 생성해서 퍼블릭 키는 인스턴스에 저장하고 다른 절반인 프라이빗 키는 사용자 단말에 저장해야한다. 

 

AWS 가 생성하는 키 페어는 생성한 리전 내에 설치되어 있으며 삭제할 때 까지 새로 시작하는 인스턴스에 사용할 수 있는데, 만약 분실되었다가 노출되었다면 저장한 키를 반드시 삭제해야한다. 

 

기타 관련 서비스 

 

시스템 매니저

시스템 메니저 서비스는 AWS 클라우드와 온프라미스 인프라에서 운영하는 리소스를 모니터링하고 관리하기 위한 도구 모음이다.

 

배치 그룹

배치 그룹은 지연시간이 짧은 네트워크 상호 연결이 필요한 여러 EC2 인스턴스에 특히 유용하며 다음과 같은 두가지 전략이 필요하다. 

 

클러스터 그룹은 단일 가용영역안에서 물리적으로 근접하고 서로 연결된 인스턴스를 시작한다. 

분산형 그룹은 장애 관련 데이터나 서비스 손실을 줄이기 위해 분리된 하드웨어에 인스턴스를 분산한다.

 

Beanstalk

사용자가 Beanstalk 에서 몇몇 파라미터를 정의하고 앱 코드를 올리려면 실행에 필요한 인프라를 구성 실행 유지한다. Beanstalk 에는 인스턴스 로드 밸런싱 오토스케일링, RDS 데이터 베이스 인스턴스 전체 네트워크 패치 등이 포함되어 있는데 이들은 Beanstalk를 사용하지 않으면 직접 설치해야하는 항목들이다. 인프라 비용 이외 추가 비용은 없다. 

 

ECS 와 Fargate

대규모 도커 컨테이너 기반에서 실행하는 앱은 본질적으로 AWS 와 같은 클라우드 플랫폼에서 적합하다. 

이러한 작업을 하려면 예전에는 잘 구성한 인스턴스를 여러개 만들어서 직접 Docker 호스트에 구성해야 했다. 

그러나 ECS를 사용하면 미리 구축된 호스트 인스턴스를 시작하고 도커 컨테이너가 작업하는 방식을 정의 할 수 있다 

컨테이너를 자동화하고 리소스와 완벽하게 통합된 인프라에서 운영할 수 있다. 

 

최근에 출시된 Fargate 도구는 ECS 구성 프로세스를 더욱 추상화 했기 때문에 컨테이너 인스턴스를 실행하고 구성할 필요조차 없으며 패키징과 환경요구 사항 설정만 수행하면 된다. 

 

AWS Lambda 

서버리스 앱은 프로그래밍 코드 기반으로 실행된다. 서버에서 동작하지만 사용자가 서버를 제어하는 대신 사전 설정된 이벤트로 람다 서버를 트리거 해서 코드를 실행하도록 구성한다. 

 

VM Import/Export 

VM Import/Export를 사용하면 온프레미스 VMware 환경과 계정간에 S3를 거쳐서 가상 머신 이미지를 쉽게 이동할 수 있으며, 마이그레이션이 가능하다. 

 

ELB와 Auto Scaling

로드 밸런서는 외부 사용자의 요청을 여러 인스턴스에 전송해 리소스를 더욱 효율적으로 분산해서 사용할 수 있게하고 사용자 경험을 향상시킨다.

 

Auto Scaling은 사전정의된 임곗값에 반응해서 수요에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄인다.