ECS, Serverless 개념, Lambda, API Gateway, Batch, Lightsail

Docker? (참고)

• 앱 배포를 위한 소프트웨어 개발 플랫폼
• 컨테이너에 앱을 패키징 한다.
• 컨테이너: 모든 운영체제에서 쉽게 실행할 수 있다.
• 앱이 컨테이너에서 실행되면 위치에 따라 상관없이 매번 같은 방식으로 실행된다.
• 어떤 기계든 호환성 문제가 없고 동작을 예측할 수 있다.
• 작업량도 적고, 유지 보수 및 배포가 쉽다.
• 몇 초만에 컨테이너를 스케일링 업 다운이 가능하다.
• JAVA, NodeJs, MySQL 실행하는 도커 3개가 있다.
• 도커 컨테이너에 앱을 패키징하기만 하면, EC2 인스턴스에서 실행하는 것이 아주 쉬워진다. 
• 도커 이미지는 도커 레포지토리에 저장된다.

VM 과 Docker 구동 차이

 

ECS(Elastic Container Service)

• Docker Container 에서 실행
• 프로비저닝을 해야하며, 인프라를 유지해야한다 -> EC2 인스턴스를 사전에 만들어야 한다.
• AWS 가 컨테이너를 시작하고 중지하는 것을 책임지며 웹 애플리케이션을 ECS 에서 만들기 원한다면, ALB(Application Load Balancer) 와의 통합을 책임진다. 
• 여러 개의 EC2 인스턴스에서 ECS 서비스에 의해 다른 컨테이너에서 실행된다. 
• ECS 서비스는 새로운 도커 컨테이너를 가질 때마다 어떤 EC2 인스턴스를 도커 컨테이너에 위치할지 알고 있다.

Fargate

• Docker Container 를 실행할때 사용
• ECS 와는 다르게 인프라를 프로비저닝할 필요가 없다. >>> EC2 인스턴스를 만들 필요가 없고, 관리할 필요가 없다.
• Serverless 서비스 >>> 우리가 관리할 서버가 없다.
• AWS 는 우리가 필요한 컨테이너를 각 컨테이너의 CPU와 RAM 사양에 맞게 실행시켜 준다.
• Fargate를 사용하는 것이 훨씬 간편하다.
• 구동 방식
  1. Fargate가 있으면, New Docker Container는 Fargate에서 실행된다.
  2. Fargate는 자동으로 해당 컨테이너를 실행해준다. (어디에 있는 지 우리가 알지는 못하지만 실행된다.)
  3. >> 이는 Fagate 기본 아이디어가 어떤 EC2 인스턴스도 관리하지 않기 때문에 쉽게 사용할 수 있다. 
• ECS 에서는 EC2 인스턴스를 먼저 만들었지만, Fargate 에서는 그럴 필요가 없다. 하지만 이 두개 모두 Docker Container 를 실행하게 해준다.

ECR (Elastic Container Registry)

• Docker 이미지 저장하여 ECS 나 Fargate 에 의해 실행된다. 
• 예시로 ECR 과 Fargate 가 있으면, 애플리케이션 이미지를 ECR 에 저장하고자 하면, Fargate 는 이 이미지들을 살펴보고 이들로부터 컨테이너를 만들어  Fargate 서비스에서 직접 실행한다.

ECR, Fargate 예시

 

 

What is Serverless?

• 개발자가 서버를 관리하지 않는 새로운 패러다임
• 코드 또는 함수를 배포한다
• 처음에는 AWS Lamda 와 함께 서비스형 함수로 만들어졌다. 
  즉, 코드를 배포하고 각 함수는 Lamda 서비스에 의해 독립적으로 실행된다.
• 최근에는 서비리스라는 것은 관리되는 어떤 것으로 여기에 사용자에 의한 서버 관리가 포함된다
  즉, 서버리스 DB, 메세지, 스토리지 등을 포함한다.
• 즉, Serverless 는 서버가 없다는 것이 아니다. 이면에 서버가 존재하며, 최종 사용자 입장에서 서버를 관리하거나 프로비저닝하거나 서버를 볼 수 없다는 뜻이다.
• S3가 그 예시 중 하나다. 우리가 스토리지 계층으로 사용했지만, 어떤 서버도 관리하지 않았다. S3 는 무한대로 스케일링할 수 있고, 서버가 없다. 그냥 파일을 업로드하면 됐었다.
• 테이블을 오토스케일링하는 DynamoDB, 도커컨테이너를 실행할때 EC2 인스턴스를 만들지 않고 자동으로 실행 방법을 찾아 실행하는 Fargate도 Serverless 라고 할 수 있다.
• + Lambda : Serverless Service 의 선구자

Lambda

• EC2 인스턴스를 이용하면 클라우드에 가상 서버를 갖게 되는데 메모리의 용량(RAM) 과 성능(CPU)에 제한을 받게 된다. + 우리가 사용하지 않을 때도 지속해서 실행된다. 
• 스케일링하고 싶을때는 Auto Scaling Group 을 사용한다. 이 말은 시간이 지남에 따라 서버를 추가하거나 제거한다는 뜻인데, 때때로 오래걸리거나 구현이 복잡할 수 있다.
• Lambda 의 경우에서는 서버가 필요하지 않고, 가상 함수를 가지게 된다. -> 이 함수들은 시간에 제한을 받는데,  짧은 유형의 실행을 위한 것이다. 수요에 따라 실행한다. + 스케일링도 자동으로 된다.
• Benefits 
  1. 가격 정책이 쉽다. (요청 당 및 컴퓨팅 시간당 비용 지불) 
  2. 프리티어 넉넉함 매달 백만개의 Lambda 호출과 40만GBs의 컴퓨팅 시간을 준다.
  3. 전체 AWS 와 통합된다.
  4. 이벤트 기반...! : 이벤트가 일어났거나, 필요할때 함수가 AWS 에 의해 호출된다.(반응형 서비스)
  5. 많은 프로그래밍 언어와 완전히 통합된다.
  6. CloudWatch 를 통해 쉽게 모니터링 할 수 있다.
  7. 함수당 리소스를 증가시키기 쉽다. RAM 증가시키면 CPU도 자동으로 증가 시킨다.
• 사용예시
  1. S3 에서 이미지를 업로드 한다.
  2. 업로드되면 Lambda 함수가 이미지를 가지고 섬네일로 만든다.
  3. 섬네일은 S3 로 다시 보내진다. 섬네일은 이미지의 작은 버전이다. 또는 섬네일 관련 메타데이터를 DynamoDB에 보낼 수 있다.(이미지 이름, 크기, 생성일 등)
  4. 이 모든 것은 완전히 이벤트 기반이고 완전히 서버리스다

S3 와 Lambda 사용 예시

• 즉, 서버리스 섬네일 생성이 아주 잘 스케일링할 것이다. 서버를 프로비저닝 하는 것과 서비스를 스케일링하는 것 관련해서 걱정할 필요가 없다.
• 사용예시 2 (CRON)
  1. 스케줄(ex. 매시간, 매일 또는 월요일마다) 을 정의하게 해주는 CRON을 이용해서 스크립트를 실행한다.
  2. Linux AMI 에서 작동하며, Linux 머신이다. 하지만 서버리스이기 때문에 EC2 인스턴스를 프로비저닝할 필요가 없다.
  3. 대신 CloudWatch Events EventBridge라는 것을 사용한다. >>> 매시간 람다함수를 트리거하여 작업을 효과적으로 실행한다. 여기에 서버가 없는데, CloudWatch Events 와 Lambda 가 서버리스 이기 때문. 
• 람다함수는 클라우드에서 서버리스 함수를 위한 것이다. 
• 가격: 요청마다 지불한다. -> 처음 백만번의 람다 호출은 무료이고, 그 이후 요청당 0.20 달러를 지불한다.
  기간으로도 지불을 하는데 프리 티어는 400,000GBs의 컴퓨팅 시간이 무료로 제공된다. 즉, 함수가 1GB 의 RAM을 갖는다면, 400,000초이다. 그 이후로는 600,000GBs에 1달러 지불
• 서버리스 애플리케이션이나 웹사이트를 실행할때 인기있는 서비스이다. 비용도 저렴

API Gateway

• Serverless HTTP API를 구축하는 사용 사례
• 사용 예시 (외부의 클라이언트가 람다 함수에 접근하게 하고싶을때)
  1. Lambda를 이용하여 DynamDB로 부터 데이터를 읽고, 만들고 업데이트하고 삭제한다.
  2. 람다 함수는 API로 바로 노출되 지 않고, 외부의 클라이언트에서 API Gateway를 통해 노출해야한다.
  3. 이는 REST HTTP API 를 클라이언트에게 제공하여 웹사이트에 직접 연결한다.
  4. 클라이언트는 API Gateway에 통신한다. -> 클라이언트 요청을 람다함수에 프록시한다. 즉, 데이터를 변환한다.
• API Gateway는 완전관리서비스에서 사용.
• 개발자가 클라우드에서 쉽게 만들고, 게시하고, 유지하며, 모니터링하고 안전한 API를 사용하게한다.
• 서버리스 기술로 완전히 스케일링 가능
• Restful API 와 데이터의 실시간 스트리밍을 위해 WebSocket API를 지원한다.

Batch

• 완전 관리 배치 처리 서비스 >> 어떤 규모에서도 배치 처리를 가능하게 한다.
• Batch 서비스를 통해 수백, 수천 개의 컴퓨팅 배치 작업을 AWS 에서 쉽고 효율적으로 처리할 수 있다.
• Batch 작업이란 일단, 배치 작업에는 시작과 끝이 있다. 이는 절대 끝나지 않고 항상 실행되는 지속적 또는 스트리밍 작업과 반대에 해당한다. 
  배치작업은 특정 시점에서 일어난다. 
• 배치 서비스는 동적으로 EC2 인스턴스 또는 Spot 인스턴스를 실행하여 해당 배치 작업을 실행하는 로드를 수용한다.
• 배치 작업은 도커 이미지와 ECS 서비스에서 실행된다. 이 말은 ECS 에서 실행할 수 있는 어떤 것이든 Batch에서 실행할 수 있다.
• 예를들어
  1. 사용자에 의해 S3에 Batch 방식으로 제출된 이미지를 처리하고자 할 때
  2. 이미지는 S3에 보내지고
  3. Batch 에서 작업을 트리거한다. 
  4. Batch 는 자동으로 EC2 인스턴스나 Spot 인스턴스로 만들어진 ECS 클러스터를 갖게 되고 배치를 인스턴스의 개수가 배치 대기열에 있는 배치 작업의 로드를 수용하는데에 적절한지 확인한다.
  5. 이 인스턴스들은 작업을 수행할 도커 이미지를 실행하게 된다. 처리된 객체를 삽입하는 작업이 될 수도 있고, 다른 S3 버킷으로 이미지를 필터 처리할 수 있다.

Batch 사용 예시

 

Batch vs Lambda

• Lamda:
  1. 15분이라는 시간의 한계가 있다. + 몇개의 프로그래밍 언어로만 접근할 수 있다.
  2. 임시 디스크 용량이 제한되어 작업을 실행하기 원한다면 서버리스여야 한다.
  
  
• Batch
  1. EC2 인스턴스에 의존하기 때문에 Batch 에는 시간 제약이 없다.
  2. 런타임은 Docker 이미지로 패키징하기만 하면 원하는 만큼 가질 수 있다.
  3. 스토리지의 경우 EC2 인스턴스의 스토리지에 의존한다. (EBS 볼륨이 될 수도 있고, 디스크 용량을 위한 EC2 인스턴스 스토어 일 수도 있다.)
  4. Batch 는 Serverless 서비스가 아닌 관리 서비스. 하지만 EC2 인스턴스가 실제로 만들어져야 한다. ---> AWS 가 EC2 인스턴스를 관리하기 때문에 Auto Scaling 에 대해서는 걱정할 필요가 없다.

 

Lighsail

• 독립 실행형 서비스
  >> 가상 서버, 스토리지, DB 및 네트워크를 한 곳에서 구축할 수 있다.
• 가격 저렴 및 예측 가능
• Lightsail을 사용하는 이유는 EC2 RDS, ELB, EBS, Route53과 같은 서비스를 사용하는 것보다 훨씬 더 쉽다
• 클라우드의 사용 경험이 거의 없고, 서비스의 복잡한 작동 방식을 익히고 싶지 않은 사람들을 위해 만들어진 서비스이다.