AWS의 주요 서비스

EC2는 Amazon Elastic Compute Cloud로, 크기 조절이 가능한 컴퓨팅 능력, 즉 가상 서버를 제공한다. S3는 Amazon Simple Storage Service로, 임의의 양의 데이터를 객체로 저장한다. 이 둘을 바꿔치기한 서술은 예로부터 흔한 혼동이므로, 이름의 철자에서 역할을 떠올릴 수 있도록 해두면 좋다. 함수 코드를 실행하는 것은 Lambda, 파일을 공유하는 것은 EFS이다.

Lambda는 서버 프로비저닝이나 관리 없이 코드를 실행할 수 있으며, 소비한 컴퓨팅 시간에 대해서만 과금된다. 코드가 실행되지 않는 동안에는 요금이 발생하지 않는 점이 계속 가동해야 비용이 드는 EC2와의 큰 차이이다. 함수 개수나 업로드한 코드 용량 자체를 과금 단위로 삼지는 않는다.

서버리스는 물리 서버가 없다는 뜻이 아니라, 서버의 조달·설정·확장을 이용자가 하지 않아도 된다는 의미이다. Lambda는 '서버 프로비저닝이나 관리 없이 코드를 실행할 수 있다'고 설명되고, Fargate는 '서버나 클러스터의 프로비저닝·설정·확장이 필요 없다'고 설명된다. 물리 서버는 AWS 측에 있으며, OS 종류나 패치 적용을 이용자가 정하는 것은 EC2 같은 형태이다.

Fargate는 컨테이너용 서버리스 종량제 컴퓨팅 엔진으로, 서버나 클러스터의 프로비저닝·설정·확장이 필요 없으며 ECS나 EKS의 시작 유형으로 사용한다. Kubernetes의 매니지드 운영은 EKS, 인스턴스 유형과 대수를 직접 선택하는 것은 EC2 시작 유형, 절차를 워크플로로 정의하는 것은 Step Functions이다.

ECS의 용량 선택지는 서버리스로 AWS가 기반을 관리하는 Fargate와, 인스턴스 유형과 대수를 이용자가 선택해 관리하는 EC2 2가지가 기본이다. 그 밖에 ECS Managed Instances, 온프레미스용 ECS Anywhere가 있다. 어느 쪽을 선택하든 컨테이너 배치와 확장을 하는 것은 ECS이며, 달라지는 것은 기반을 누가 돌보는가 하는 점뿐이다.

EKS는 Amazon Elastic Kubernetes Service로, 직접 Kubernetes 클러스터를 설치·운영하지 않고도 AWS에서 Kubernetes를 실행할 수 있는 매니지드 서비스이며, Kubernetes 준수 인증을 받았다. 데이터베이스 운영 자동화는 RDS, 콘텐츠를 가까운 곳에서 전송하는 것은 CloudFront, 트래픽 분산은 Elastic Load Balancing이 담당한다.

Lambda는 서버 관리 없이 코드를 실행할 수 있으며 소비한 컴퓨팅 시간에 대해서만 과금되고, 실행되지 않는 동안에는 요금이 발생하지 않는다. 따라서 호출이 드문드문한 처리에서는 대기 시간에 비용이 들지 않는 Lambda가 유리하다. EC2나 EKS 클러스터를 상시 가동하는 구성은 처리가 동작하지 않는 대부분의 시간에도 비용이 계속 든다.

EC2는 클라우드에서 안전하고 크기 조절이 가능한 컴퓨팅 능력을 제공하는 서비스로, 사용한 만큼만 지불하며 컴퓨팅 리소스를 완전히 제어할 수 있다고 공식적으로 설명된다. 실행 시간만 과금되고 OS를 다루지 않는 것은 Lambda, 객체 단위로 저장하는 것은 S3, 워크플로를 상태로 정의하는 것은 Step Functions의 성질이다. 제어할 수 있는 범위가 넓은 만큼 OS 관리가 이용자에게 남는다는 점도 함께 기억해두어야 한다.

ECS는 Amazon Elastic Container Service로, 완전 관리형 컨테이너 오케스트레이션 서비스로서 컨테이너화된 애플리케이션의 배포·관리·확장을 쉽게 해준다. Kubernetes를 준수하는 클러스터를 제공하는 것은 EKS, 가상 서버 시작은 EC2, 이벤트에 따른 코드 실행은 Lambda이다. ECS와 EKS는 둘 다 컨테이너를 묶지만 Kubernetes를 사용하는지 여부로 나뉜다.

EKS는 직접 Kubernetes 클러스터를 설치·운영하지 않고도 AWS에서 Kubernetes를 실행할 수 있는 매니지드 서비스로, Kubernetes 준수 인증을 받았다. 한편 ECS는 AWS의 완전 관리형 컨테이너 오케스트레이션 서비스로 Kubernetes를 전제로 하지 않는다. 둘 다 컨테이너를 다루는 서비스이며 가상 서버 이미지만 다루는 것이 아니다. 시작 대상으로는 둘 다 Fargate를 선택할 수 있다.

EBS는 EC2 인스턴스에서 사용하는 영구 블록 스토리지 볼륨으로, 가용 영역 내에서 자동으로 복제되며 원칙적으로 1개의 인스턴스에 연결하여 사용한다. EFS는 리눅스 워크로드용 파일 시스템으로 용량이 자동으로 늘고 줄며, 수천 대의 EC2 인스턴스에서의 병렬 공유 접근을 지원한다. 공유할 수 있는 것은 EFS 쪽이며, 양쪽 모두 공유용이거나 양쪽 모두 단독 연결 전용인 경우는 없다.

S3는 Amazon Simple Storage Service로, 임의의 양의 데이터를 저장·보호할 수 있는, 확장성과 가용성이 뛰어난 객체 스토리지이다. 블록 스토리지는 EBS, 리눅스용 공유 파일 시스템은 EFS, 인메모리 캐시는 ElastiCache가 담당한다. 객체·블록·파일이라는 3가지 저장 방식의 차이가 AWS 스토리지를 선택할 때의 출발점이 된다.

EFS는 파일의 증감에 따라 용량이 자동으로 늘고 줄며, 수천 대의 EC2 인스턴스에서의 병렬 공유 접근을 지원하는 파일 스토리지이므로, 같은 디렉터리를 다수의 인스턴스에서 동시에 마운트하는 용도에 적합하다. EBS는 가용 영역 내의 블록 스토리지로 원칙적으로 1개의 인스턴스에 연결하므로 각자의 영역이 별도가 된다. Glacier Deep Archive는 조회에 시간이 걸리는 아카이브용 클래스, ElastiCache는 파일 시스템이 아닌 인메모리 캐시이다.

EBS는 EC2 인스턴스용 영구 블록 스토리지로, 가용 영역 내에서 자동으로 복제되어 일관된 저지연 성능을 제공한다. 이 단일 AZ라는 성질 때문에 AZ를 넘나드는 가용성을 원한다면 별도의 구조가 필요하다. 리전을 넘나드는 복제나 에지 로케이션에서의 전송은 EBS의 역할이 아니다.

S3 Glacier는 아카이브용 스토리지 클래스 그룹으로, 즉시 조회가 필요한 데이터용 S3 Glacier Instant Retrieval, 거의 접근하지 않는 장기 데이터용 S3 Glacier Flexible Retrieval, 최저 비용으로 몇 시간에 걸쳐 조회하는 S3 Glacier Deep Archive가 있다. 조회 속도와 비용의 균형에 따라 클래스를 선택하는 설계이며 조회 시간이 일률적이지 않다. 저장할 수 있는 데이터 종류에 제한은 없고, 블록 스토리지로 연결하는 사용법도 아니다.

S3는 객체 스토리지, EBS는 EC2에 연결하는 블록 스토리지, EFS는 리눅스 워크로드용 파일 스토리지이다. 객체는 API를 통해 통째로 넣고 빼는 것, 블록은 OS에서 디스크로 보이는 것, 파일은 여러 호스트에서 마운트해 공유할 수 있는 것이라고 정리하면 요건에서 선택할 때 헷갈리지 않는다.

EBS는 EC2 인스턴스에서 사용하는 영구 블록 스토리지 볼륨으로, 일관된 저지연 성능을 제공하므로 OS나 데이터베이스의 디스크로 사용하기에 적합하다. S3는 객체 스토리지로 버킷을 블록 디바이스로 연결하는 구조가 아니다. Glacier는 조회에 시간이 걸리는 아카이브용 클래스, CloudFront는 전송을 빠르게 하는 CDN이다.

S3는 임의의 양의 데이터를 저장·보호할 수 있는, 확장성·가용성·보안성·성능이 뛰어난 객체 스토리지로, 웹·모바일·백업·아카이브·IoT·빅데이터 분석 같은 용도가 공식적으로 제시되어 있다. OS에서 디스크로 보이는 것은 EBS, 1개 인스턴스로의 연결을 원칙으로 하는 것도 EBS, 메모리 위에 데이터를 두는 것은 ElastiCache의 성질이다.

EFS는 단순하고 확장 가능하며 탄력적인 파일 시스템으로, 파일을 추가·삭제하면 용량이 자동으로 늘고 줄어 사전 용량 설계가 필요 없다. 용량을 미리 정해 고정하거나 넓히기 위해 다시 만드는 것은 블록 스토리지의 발상이며, 연결된 인스턴스의 메모리 양이 용량을 정하는 것도 아니다. 이 신축성이 공유 작업 영역으로 사용하기 좋은 이유가 된다.

S3 Glacier Deep Archive는 거의 접근하지 않는 데이터를 최저 비용으로 보관하고 조회에 몇 시간이 걸리는 아카이브용 스토리지 클래스이므로 이 조건에 맞는다. EBS와 EFS는 조회 속도를 유지하는 설계여서 장기간 잠자는 데이터의 저장소로는 비용이 비싸지기 쉽다. ElastiCache는 인메모리 캐시로 애초에 장기 보관을 위한 구조가 아니다. 조회에 얼마나 기다릴 수 있는지를 먼저 정하는 것이 클래스 선택의 순서이다.

RDS는 클라우드에서 관계형 데이터베이스의 설정·운영·확장을 쉽게 해주는 매니지드 서비스로, 하드웨어 프로비저닝, 데이터베이스 설정, 패치 적용, 백업 같은 관리 작업을 자동화한다. 한편 표와 열의 설계나 인덱스 판단, 애플리케이션의 구성, 데이터 내용의 타당성은 모두 이용자 측의 일로 남는다. 매니지드란 운영의 수고를 맡기는 것이지 설계까지 맡기는 것은 아니다.

Aurora는 매니지드 데이터베이스 서비스인 Amazon RDS의 일부로, 동일한 관리 콘솔·CLI·API 조작으로 프로비저닝, 패치 적용, 백업, 복구, 장애 감지를 수행한다. 차이는 관리 단위에 있으며, 표준 RDS가 개별 DB 인스턴스를 관리하는 데 비해 Aurora는 복제로 동기화된 DB 서버 클러스터 전체를 관리한다. Aurora는 MySQL·PostgreSQL 호환 관계형 데이터베이스이며 키-값 형태가 아니다.

DynamoDB는 키-값 형태와 문서 형태의 NoSQL 데이터베이스로, 어떤 규모에서도 한 자릿수 밀리초의 성능을 제공하는 완전 관리형 멀티 리전 데이터베이스이다. 데이터 웨어하우스는 Redshift, MySQL·PostgreSQL 호환 관계형 데이터베이스는 Aurora, 메모리 위에서의 읽기·쓰기는 ElastiCache가 담당한다.

Redshift는 클라우드 기반의 완전 관리형 페타바이트 규모 데이터 웨어하우스 서비스로, 데이터셋의 크기와 무관하게 기존의 SQL 기반 도구나 BI 애플리케이션에서 빠른 쿼리 성능을 얻을 수 있다. ElastiCache는 인메모리 캐시, EFS는 공유 파일 시스템, SQS는 메시지 큐로, 어느 것도 대량 데이터의 집계와 분석을 담당하는 기반이 아니다.

ElastiCache는 클라우드에서 인메모리 캐시를 손쉽게 배포·운영·확장할 수 있는 서비스로, 디스크 기반 데이터베이스에 의존하지 않고 고속의 인메모리 캐시에서 정보를 조회함으로써 웹 애플리케이션의 성능을 개선한다. 분석용 쿼리를 빠르게 하는 것은 Redshift, 장기 보관 비용 절감은 S3 Glacier 클래스, 디렉터리 공유는 EFS의 담당이다.

Aurora는 MySQL·PostgreSQL 호환 완전 관리형 관계형 데이터베이스 엔진으로, 고성능 분산 공유 스토리지 서브시스템을 가지며 스토리지는 필요에 따라 자동으로 확장된다. 용량을 먼저 정해 수동으로 늘릴 필요가 없다. 키와 값의 쌍으로 저장하는 것은 DynamoDB, 시간을 들여 조회하는 대신 저렴하게 보관하는 것은 S3 Glacier의 아카이브용 클래스이다.

Redshift는 완전 관리형의 페타바이트 규모 데이터 웨어하우스 서비스로, SQL 기반 도구나 BI 애플리케이션에서 대량의 데이터를 집계·분석하는 용도에 적합하다. RDS는 관계형 데이터베이스의 설정·운영·확장을 쉽게 해주는 서비스로, 업무 시스템이 일상적인 거래를 읽고 쓰는 용도에 적합하다. 둘 다 SQL로 조회하므로 비슷해 보이지만 NoSQL도 아니고 양의 차이만 있는 것도 아니다.

DynamoDB는 키-값 형태와 문서 형태의 NoSQL 데이터베이스로, 어떤 규모에서도 한 자릿수 밀리초의 성능을 제공한다고 공식적으로 설명되어 있다. Redshift는 대량 데이터의 집계와 분석에 적합한 데이터 웨어하우스, RDS는 관계형 모델로 읽고 쓰기를 담당하는 서비스, EFS는 파일 공유를 담당하는 스토리지로, 어느 것도 이 조건을 우선 목표로 하는 기반이 아니다.

RDS는 Amazon Relational Database Service로, 클라우드에서 관계형 데이터베이스의 설정·운영·확장을 쉽게 해주는 매니지드 서비스이다. 키와 값의 쌍으로 저장하는 것은 DynamoDB, 인메모리 캐시는 ElastiCache, 대량 데이터의 집계는 데이터 웨어하우스인 Redshift가 담당한다. 참고로 Aurora는 RDS의 일부로 제공되는 엔진이다.

Aurora는 RDS의 일부로 제공되며, 동일한 관리 콘솔·CLI·API 조작으로 프로비저닝, 패치 적용, 백업, 복구, 장애 감지를 수행할 수 있다. 관리용 인스턴스를 별도로 세울 필요는 없고, 이러한 절차를 이용자가 직접 만들 필요도 없다. 표준 RDS가 개별 DB 인스턴스를 관리하는 데 비해, Aurora는 클러스터 전체를 관리 단위로 삼는 점이 차이이다.

SQS는 메시지를 큐에 보관하고, 보통 하나의 컨슈머가 폴링하여 꺼내는 포인트투포인트 서비스이다. SNS는 퍼블리셔가 토픽으로 메시지를 보내고, 여러 구독자에게 동시에 푸시 전달하는 퍼브서브 서비스이다. 둘을 바꿔치기한 서술은 전형적인 혼동이며, 둘 다 같은 방식으로 전달하는 것도 아니다. 큐는 수신자가 가지러 가는 보관소, 토픽은 발신자가 밀어내는 전달자라고 방향으로 기억하면 좋다.

SQS에는 표준 큐와 FIFO 큐가 있으며, 표준 큐는 최소 한 번(at-least-once) 전달이므로 같은 메시지가 여러 번 도착할 수 있다. FIFO 큐는 정확히 한 번(exactly-once) 처리와 순서 보장을 갖추어, 보낸 순서가 유지되고 한 번만 처리된다. 순서나 유실 방지가 중요한 워크플로에서는 FIFO 큐를 선택하게 된다.

SNS는 토픽으로 보낸 메시지를 여러 구독자에게 동시에 푸시 전달하며, 구독자로 SQS 큐를 지정할 수 있다. 이 SNS 토픽에서 여러 SQS 큐로 전달하는 형태가 공식적으로 정석으로 제시되는 팬아웃 패턴이다. 큐는 전달의 출발점이 아니라 수신 측이므로 큐가 토픽을 읽는 방향은 되지 않는다.

SNS의 구독자 유형은 SQS, Lambda, HTTP(S), Data Firehose 등 앱 간을 가리키는 A2A와, 이메일·모바일 푸시·SMS 등 대인용을 가리키는 A2P의 2가지로 정리된다. 어느 한쪽으로 한정되지도, EC2 인스턴스만을 수신처로 하는 구조도 아니다. 이러한 폭넓음이 대인 알림에도 앱 간 연계에도 SNS가 쓰이는 이유가 된다.

Step Functions는 워크플로, 즉 스테이트 머신을 만들어 분산 애플리케이션 구축, 프로세스 자동화, 마이크로서비스 오케스트레이션, 데이터·머신러닝 파이프라인 구축을 가능하게 하는 서비스이다. 각 단계를 state, 실행 중인 인스턴스를 execution이라고 부른다. 트래픽 분산은 Elastic Load Balancing, 객체 보관은 S3, 키와 값의 캐시는 ElastiCache의 영역이다.

API Gateway는 REST, HTTP, WebSocket API를 어떤 규모로도 생성·게시·유지·모니터링·보호하는 서비스로, EC2 위의 워크로드, Lambda, 임의의 웹 애플리케이션 같은 백엔드로의 접근에 프런트 도어 역할을 한다. 처리 자체를 실행하는 것은 백엔드 측, 보호 규칙의 일원화는 AWS Firewall Manager, 에지에서의 캐시는 CloudFront의 역할이다.

EventBridge는 이벤트를 이용해 애플리케이션 구성 요소들을 연결하는 서버리스 서비스로, 이벤트 수집·필터링·변환·전달을 수행한다. 이벤트 버스는 다수의 소스에서 다수의 타깃으로 이벤트를 라우팅하는 라우터이다. 대기열은 SQS, 스테이트 머신은 Step Functions, 프런트 도어는 API Gateway에 대한 설명에 해당한다.

EventBridge Scheduler는 cron 식이나 rate 식에 의한 정기 실행과 단발 실행을 관리하는 구조이므로, 정해진 시각의 시작은 이곳에서 다룬다. SQS는 메시지를 보관해 수신자가 꺼내게 하는 큐, SNS는 구독자에게 전달하는 퍼브서브, API Gateway는 API를 게시해 중계하는 서비스로, 어느 것도 시각에 의한 시작을 목적으로 한 구조가 아니다.

SQS는 분산된 소프트웨어 시스템이나 구성 요소를 통합해 느슨하게 결합시키는, 안전하고 내구성과 가용성이 뛰어난 호스팅 큐 서비스이다. 접수 측은 메시지를 큐에 넣은 시점에 응답할 수 있고, 후속 처리는 자신의 속도로 꺼내어 진행할 수 있으므로 한쪽의 지연이 다른 쪽을 멈추게 하기 어렵다. 직접 호출하는 구성이나 하나로 묶는 구성에서는 후속 처리의 지연이 그대로 접수 측의 대기 시간이 된다.

SNS는 토픽으로 보낸 메시지를 여러 구독자에게 동시에 푸시 전달하며, 구독자로 SQS 큐를 지정할 수 있으므로 1건의 사건을 3개의 처리로 나누려면 SNS 토픽과 여러 SQS 큐에 의한 팬아웃 패턴을 사용한다. 1개의 큐를 3개의 처리가 공유하면 보통 어느 하나가 꺼낸 시점에 나머지는 받을 수 없다. 발생원이 3번 보내는 구성이나 받은 처리가 전달하는 구성은 수신처가 늘어날 때마다 보내는 쪽을 고쳐야 하므로 느슨한 결합이 되지 않는다.