[AWS] ECS, Lambda, Batch, Lightsail

dereck·2024년 12월 19일

AWS CCP TIL aws

AWS CCP

목록 보기

8/29

AWS에서 도커 컨테이너를 실행하는 방법

Amazon ECS

ECS는 Elastic Container Service의 약자로 AWS에서 도커 컨테이너를 실행할 때 사용된다.

ECS가 동작하기 위해선 어딘가에서 도커 컨테이너를 실행해야 하는데 ECS에서는 반드시 사용자가 프로비저닝해야 하고, 인프라를 자체적으로 유지해야 한다.

사용자는 사전에 여러 EC2 인스턴스를 만들어야 하고, 만들어진 EC2 인스턴스들은 ECS에 의해 다른 컨테이너에서 실행된다. ECS는 새로운 도커 컨테이너를 가질 때마다 어떤 EC2 인스턴스에 도커 컨테이너가 위치할지 알고 있다.

AWS는 사용자를 위해 컨테이너를 시작하고 중지하는 것을 책임지며 사용자가 웹 애플리케이션을 ECS에서 만들기 원한다면 애플리케이션 로드 밸런서(ALB)와의 통합을 책임진다.

AWS Fargate

Fargate 또한 AWS에서 도커 컨테이너를 실행할 때 사용한다. 그러나 Fargate에선 인프라를 프로비저닝할 필요가 없다. EC2 인스턴스를 만들 필요가 없고 관리할 필요가 없다. AWS가 제공하는 간단한 서비스이다.

Fargate는 서버리스 서비스이고, AWS는 각 컨테이너의 CPU 및 RAM 사양을 기반으로 필요한 컨테이너를 실행하기만 하면 된다.

ECS에서는 미리 EC2 인스턴스를 만들어야 했지만 Fargate에선 그럴 필요가 없다

Amazon ECR

ECR은 Elasic Container Registry의 약자로 도커 이미지를 저장하여 ECS나 Fargate에 의해 실행된다.

애플리케이션의 이미지를 ECR에 저장하면 Fargate는 ECR에 저장된 이미지로부터 컨테이너를 만들어서 Fargate 서비스에서 직접 실행한다. ECR에서는 여러 이미지를 가질 수 있고, Fargate에 같은 이미지로 여러 컨테이너를 만들 수도 있다.

Serverless

Serverless는 직역하면 “서버가 없다”는 뜻이다.

하지만 정말로 서버가 없는 것을 말하는 것이 아니다. 서버가 존재하지 않고선 서비스가 동작할 수 없기 때문에 이면에 서버가 존재한다.

따라서 Serverless라는 말은 최종 사용자 입장에서 서버를 관리하지 않거나 프로비저닝하거나 볼 수 없다는 뜻이 된다.

Serverless의 예시로는 이전에 살펴본 S3가 있다. S3를 스토리지 계층으로 사용해도 사용자는 어떤 서버도 관리하지 않기 때문이다. S3는 무한대로 스케일링할 수 있고, 그저 파일을 업로드하면 된다.

DynamoDB와 Fargate도 마찬가지다. DynamoDB는 테이블을 위해 서버를 프로비저닝하지 않는다. 서버와 테이블은 수신하는 로드에 맞게 오토 스케일링할 수 있고, Fargate는 도커 컨테이너를 보내면 Fargate에서 자동으로 실행 방법을 찾아 실행하기 때문에 Serverless 서비스가 된다.

AWS Lambda

AWS Lambda를 사용하는 이유

EC2 인스턴스를 사용하면…

클라우드에 가상 서버를 갖게 된다.
RAM 용량과 CPU의 성능에 제한을 받는다.
(사용하지 않아도) 계속 실행된다.
스케일링 시 오토 스케일링 그룹(ASG)을 사용한다.
- 시간이 지남에 따라 서버를 추가하거나 제거한다는 뜻
- 때때로 오래 걸리거나 구현이 복잡할 수도 있다.

Lambda를 사용하면…

가상 함수를 가지게 된다.
- 서버가 필요하지 않다
시간에 제한을 받는다.
- 짧은 실행을 위한 것이다.
온디맨드(필요)에 따라 실행된다.
스케일링이 필요하면 자동으로 된다.

Lambda의 장점

간편한 가격 책정
- 요청당 및 컴퓨팅 시간당 비용을 지불하게 되는데 프리 티어도 넉넉하다
- 매달 백만 개의 Lambda 호출과 400,000GB-초의 컴퓨팅 시간을 준다.
  - 400,000GB-초는 400,000 GB / 1GB = 400,000 , 400,000 GB / 128MB = 3,125,000 과 같다.
  - 이후 백만 개의 요청당 0.20달러 지불, 600,000GB-초당 1달러 지불
전체 AWS 서비스와 통합 가능
이벤트 기반
- 이벤트가 일어났거나 필요할 때 함수가 AWS에 의해 호출된다.
- Lambda가 반응형 서비스인 이유
다양한 프로그래밍 언어 지원
- Java, Node(JS), C#, etc
- 사용자 정의 런타임 API를 통해 원하는 함수도 실행 가능
- Lambda 컨테이너 이미지
  - 실제 도커 컨테이너를 Lambda에서 실행하게 해주지만 컨테이너 이미지가 반드시 Lambda 런타임 API를 구현해야 한다.
  - ECS/Fargate가 임의의 도커 이미지를 실행할 때 선호되는 방식
CloudWatch를 통해 쉽게 모니터링이 가능
함수당 리소스를 가져오기 쉬움
- 함수당 10GB의 RAM을 사용 가능
RAM을 늘리면 CPU와 네트워크도 개선됨

시험에서는 호출과 기간에 따른 Lambda 가격을 알아야 한다.

Amazon API Gateway

API Gateway는 완전 관리 서비스에 사용되며 개발자가 클라우드에서 쉽게 만들고, 게시하고, 유지하며, 모니터링하고 안전한 API를 사용하게 한다. 또한 서버리스이며 확장 가능하고, RESTful API와 데이터 실시간 스트리밍을 위한 WebSocket API, 보안, 사용자 인증, API throttling, API 키, 모니터링 등을 지원한다.

Amazon API Gateway는 시험에서 서버리스 HTTP API를 구축하는 사용 사례로 나오며 서버리스 API를 만들 때를 물어볼 경우 API Gateway와 Lambda를 생각하면 된다.

API Gateway 예시

람다를 사용해서 DynamoDB로부터 데이터 CRUD를 한다고 가정한다.

둘 다 서버리스 기술이지만 클라이언트가 람다 함수에 접근하게 하고 싶을 경우 API Gateway를 통해 노출해야 하며, REST HTTP API를 클라이언트에 제공하여 웹사이트에 직접 연결한다. 그리고 API Gateway는 람다 함수에 요청을 프록시하고, 이는 데이터를 반환한다.

AWS Batch

Batch는 완전 관리 배치 처리 서비스로 어떤 규모에서도 배치 처리를 가능하게 한다. 배치 서비스를 통해 수백, 수천 개의 컴퓨팅 배치 작업을 AWS에서 쉽고 효율적으로 처리할 수 있다.

배치 작업에는 시작과 끝이 있다. 배치 작업은 특정 시점에 일어나며 동적으로 EC2 인스턴스 또는 스팟 인스턴스를 실행하여 해당 배치 작업을 실행하는 로드를 수용한다.

배치는 배치 대기열 처리에 적합한 양의 컴퓨팅과 메모리를 프로비저닝할 수 있다. 사용자는 그저 스케줄 된 배치 작업을 배치 대기열에 제출하면 된다. 나머지는 배치 서비스가 알아서 해준다.

배치 작업(Batch Job)은 간단히 도커 이미지와 테스트 정의로 ECS 서비스에서 실행된다. 즉, ECS에서 실행할 수 있는 어떤 것이든 배치에서 실행할 수 있다는 뜻이다. 또한 자동으로 EC2 인스턴스 또는 스팟 인스턴스를 알맞은 개수로 스케일링 해주고 작업을 실행한다. 따라서 비용 최적화를 할 수 있고 인프라에 덜 신경쓰고 배치 작업에만 집중할 수 있다.

Batch vs Lambda

Lambda

15분이라는 시간 제한이 있다
몇 개의 프로그래밍 언어로만 접근할 수 있다.
임시 디스크 용량이 제한되어 작업을 실행하려면 서버리스여야 한다

Batch

EC2 인스턴스에 의존하기 때문에 시간 제약이 없다
원하는 런타임을 도커 이미지로 패키징 하기만 하면 원하는 만큼 가질 수 있다.
스토리지의 경우 EC2 인스턴스의 스토리지에 의존한다.
- EBS 볼륨이 될 수도 있고, 디스크 용량을 위한 EC2 인스턴스 스토어일 수도 있다.
- 람다 함수보단 용량이 더 큼
서버리스 서비스가 아니다.
- 관리 서비스지만 EC2 인스턴스가 실제로 만들어져야 한다.
- 하지만 AWS가 EC2 인스턴스를 관리하기 때문에 오토 스케일링 등에 관해 걱정할 필요는 없다.

Amazon Lightsail

Lightsail은 AWS에서 약간 독특한 서비스로 독립 실행형 서비스이다. Lightsail을 사용하면 가상 서버 스토리지, 데이터베이스 및 네트워크를 한 곳에서 구축할 수 있다.

Lightsail은 가격이 저렴하고 예측 가능하다. 사람들이 Lightsail을 사용하는 이유는 EC2, RDS, ELB, EBS, Route 53과 같은 서비스를 사용하는 것보다 더 쉽기 때문이다. 즉, Lightsail은 클라우드 사용 경험이 거의 없고, 서비스의 복잡한 작동 방식을 익히고 싶지 않은 사람들을 위해 만들어진 서비스이다.

Lightsail에서도 리소스에 대한 모니터링 알람 설정을 할 수 있다. 또한 LAMP, Nginx, MEAN, Node.js 등을 사용한 간단한 웹 애플리케이션 배포 시 Lightsail에는 해당 템플릿들이 있고, WordPress, Magento, Plesk 등을 사용한 웹 사이트는 Lightsail에서 템플릿을 사용해 쉽게 배포할 수 있다.

AWS에서 구축된 개발 또는 테스트 환경이 있는 경우에도 Lightsail은 좋은 선택지이다. Lightsail에는 고가용성 개념이 있지만 오토 스케일링은 지원하지 않고 AWS에 제한적으로 통합된다.

요약하자면 Lightsail은 클라우드 사용 경험이 없고 복잡한 설정 없이 저렴하고 예측 가능한 가격으로 서비스를 빠르게 시작하려는 사람에게만 좋은 선택인 것이다.

컴퓨팅 서비스 요약

Docker
- 애플리케이션을 실행시킬 수 있는 컨테이너 기술
ECS
- 도커 컨테이너를 EC2 인스턴스에서 실행시킬 수 있음
- 실행 전 인스턴스를 프로비저닝 해야 함
Fargate
- 인프라 프로비저닝이 없고 과정이 보이지 않지만 동일하게 도커 컨테이너를 사용할 수 있음
- 도커 컨테이너를 실행하기 위해 EC2 인스턴스를 관리하지 않기 때문에 서버리스 서비스임
ECR
- 사설 도커 이미지 리포지토리인 ECR을 이용해서 도커 컨테이너를 AWS에 저장할 수도 있음
Batch
- 배치를 사용하면 사용하고 있는 여러 EC2 인스턴스에 배치 작업을 실행할 수 있음
- 배치 작업은 ECS 위에서 실행됨
Lightsail
- 저렴하고 예측 가능한 비용으로 애플리케이션을 실행할 수 있는 새로운 유형의 서비스이자 데이터베이스 기술
Lambda
- 서버리스 서비스로 기능을 제공하며 원활한 스케일링을 가능하게 함
- 초당 한번의 호출에서 수천 번의 호출까지 완전히 반응적으로 대응함
- 두 가지 결제 방식이 존재
  1. 람다 함수에 대한 메모리 프로비저닝 양에 실행 시간을 곱하는 방식
  2. 람다 함수가 호출된 횟수를 계산하는 방식
- 다양한 프로그래밍 언어를 지원
- 컨테이너 이미지 지원
  - 특정 런타임 API를 구현해야 함
  - 따라서 임의의 도커 이미지를 지원하지는 않음
    - 임의의 도커 이미지 지원은 ECS 또는 Fargate
  - 사용하려는 도커 이미지에서 람다 컨테이너 런타임 API를 구현하면 도커 이미지를 람다에서 길행할 수 있음
- 호출 시간은 최대 15분
- 사용 사례
  - Amazon S3에 업로드된 이미지의 썸네일 만들기
  - 서버리스 CRON 작업 실행
API Gateway
- 사용자가 만든 람다 기능을 API로 공개할 때 사용
- 서버리스 서비스
- 함수를 HTTP API로 공개할 수 있고, 보안, 스로틀링, API 키 등의 기능도 사용할 수 있음

References

dereck

이전 포스트

[AWS] 데이터베이스 및 분석

다음 포스트