주제: 컴퓨팅 파워 (서버)
1. AWS EC2
Elastic Compute Cloud (EC2)
EC2는 AWS에서 제공하는 클라우드 컴퓨팅이다. 안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스이다. 간편하게 구성된 서비스 UI 덕분에 개발자는 쉽게 원하는 설정의 가상 서버를 구축할 수 있으며 보안 및 네트워크 구성을 하며 스토리지도 관리할 수 있다.
Amazon EC2에서는 확장 또는 축소를 통해 요구 사항 변경 또는 사용량 스파이크를 관리할 수 있는 기능을 제공하기 때문에 트레픽을 예측할 필요성이 줄어든다. 다만, 기본적으로 제공하는 프리티어 이상의 용량이나 CPU 성능을 사용하기 위해서는 비용을 지출해야만 한다.
EC2에서는 여러가지 요금 옵션을 지원한다.
- 온디맨드
- 선결제 금액이나 장기 약정 없이 저렴하고 유연하게 서비스를 사용하기 원하는 사용자
- 단기적으로 갑작스럽게 예측할 수 없는 워크로드가 있지만, 중단 되어서는 안되는 어플리케이션
- 소규모 개발 또는 시험적으로 운영하는 애플리케이션
- 스팟 인스턴스
- 시작 및 종료 시간이 자유로운 애플리케이션 / 미사용 인스턴스 중지로 인해 비용 절감 가능
- Saving Plans
- 1년 또는 3년 기간의 일정 사용량 약정을 조건으로 EC2 및 Fargate 사용량에 대해 저렴한 요금을 제공하는 유연한 요금
2. AWS Elastic Beanstalk
Elastic Beanstalk (EB)
AWS 클라우드에서 애플리케이션을 신속하게 배포하고 관리할 수 있는 서비스이다. EB를 사용하게 되면 어플리케이션을 실행하는 인프라에 대해 자세히 알지 못해도 어플리케이션을 업로드 하기만 해도 용량 프로비저닝, 로드 밸런싱, 조정, 애플리케이션 상태 모니터링등 세부정보를 자동적으로 처리 해준다.
Elastic Beanstalk = EC2 + 배포 버전 관리 (롤백) + Elastic Load Balancer + 모니터링 + 로그 트래킹 + 오토 스케일링
EB를 사용해서 배포를 진행하게 되면 CloudFormation을 통해 리소스 생성이 진행되며 사용된 리소스 (EC2, S3, RDS 등등)에 대해서만 요금이 발생하고 EB에 대한 추가적인 요금은 발생하지 않는다.
3. AWS ECR
Amazon Elastic Container Registry (ECR)
ECR은 AWS 관리형 컨테이너 이미지 레지스트리 서비스이다. 쉽게 말해 도커의 컨테이너 이미지를 저장해주는 레포지토리 역할을 해주는데 도커에서 직접적으로 관리를 하는 대신 AWS에 관리를 맞겨 이미지 저장, 관리 및 배포를 자동적으로 해주며 AWS IAM 인증을 통하여 권한 관리도 가능해진다.
- RDS (DB) = 데이터를 저장하는 장소
- S3 = 사진, 이미지 등 파일을 저장하는 장소
- ECR = 도커 이미지를 저장하는 장소
4. AWS ECS
컨테이너란?
컨테이너는 데스크탑, 기존의 IT 또는 클라우드 등 어디서나 실행될 수 있도록 애플리케이션 코드가 해당 라이브러리 및 종속 항목과 함께 패키징되어 있는 소프트웨어 실행 유닛입니다.
가상 머신과는 달리 컨테이너는 모든 인스턴스에 게스트 OS를 포함할 필요가 없으며, 그 대신 호스트 OS의 기능과 리소스를 간편하게 활용할 수 있습니다. 따라서 컨테이너는 소형이고, 빠르며, 이식성이 뛰어납니다.
위에서 설명한 바와 같이 애플리케이션의 필요한 부분만을 패키징해서 다른 애플리케이션과 격리하여 관리하는 것이 컨테이너 방식이다. 컨테이너를 사용하기 전에는 가상머신(Virtual Machine)을 사용하여 격리된 환경을 구성했었지만, 현재는 컨테이너를 더 많이 사용하며 그 중 도커가 가장 대표적이다.
가상머신 VS 컨테이너
위의 그림에서 나온 것처럼 VM의 경우 App, Library 그리고 OS를 각각 가지게 되고 이러한 점은 VM의 이미지를 무겁게 만들었다. 그에 반해 컨테이너의 경우 App과 Library만을 포함하기 때문에 상대적으로 VM 보다 가벼운 이미지를 생성할 수 있다. 특히나 Host의 OS를 사용하기 때문에 실행, 패치, 업데이트등 유지 관리가 쉬워지며 실행 속도 또한 더욱 빨라진다.
Amazon Elastic Container Service (ECS)
ECS는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스로 여러 어플리케이션 컨테이너를 쉽고 빠르게 실행하고, 컨테이너를 적절하게 분배 및 확장, 축소 할 수 있도록 도와주는 서비스이다. 클러스터를 관리하기 위한 별도의 인스턴스를 구성 또는 관리하지 않아도 되고, 클러스터 관리에 대한 추가 비용이 없다.
ECS는 여러 구성요소로 이루어져 있다.
- Cluster
- Task 가 배포되는 Container Instance 들은 논리적인 그룹으로 묶이게 되는데 이 단위를 Cluster 라고 부른다.
- ECS에서 도커 이미지를 실행하게 해주는 논리적인 공간이다.
- 기본적으로 Container Instance에 대한 권한을 가지고 있으며 여러 서비스를 동시에 실행할 수 있다.
- Container Instance
- Task가 배포되는 Cluster에 등록된 EC2 Instance를 말한다.
- ECS를 처음 시작하면 생성되는 Default Cluster 에는 Container instance를 자동으로 할당 시켜 주기도 하지만 새롭게 Cluster 를 생성하게 되면 직접 Container instance 를 만들어야 한다.
- ECS의 시작유형을 EC2가 아닌 Fargate로 설정을 한다면 Serverless로 배포하기 때문에 Container Instance는 적용되지 않는다.
- Service
- Task를 지속적으로 관리하는 단위이다.
- 컨테이너화된 서비스들이 손쉽게 서로를 검색하고 연결할 수 있도록 지원하는 통합된 서비스 검색 기능을 제공한다.
- ELB와 AutoScaling 기능과 연동하여 Task를 관리해준다.
- Task Definition
- Task를 실행하기 위한 설정을 저장하는 단위이다.
- 컨테이너 별로 실행하고자 하는 이미지를 지정할 수 있으며 Task definition 에서 정의된 대로 실제 생성된 container set 들을 Task 라고 부르게 된다.
- Task
- Task definition 에서 정의된 대로 배포된 Container Set이다.
- Task는 Cluster에 속한 Container Instance에 배포된다.
5. AWS Fargate
AWS Fargate
AWS Fargate는 Amazon EC2 인스턴스의 서버나 클러스터를 관리할 필요 없이 컨테이너를 실행하기 위해 ECS에 사용할 수 있는 기술이다. Fargate가 AWS Lambda 서비슬 대체하지는 않지만 더 이상 컨테이너를 실행하기 위해 가상 머신의 클러스터를 프로비저닝, 구성 또는 조정할 필요가 없기 때문에 서버 유형을 선택하거나, 클러스터를 조정할 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없어진다.
쉽게 말해 EC2를 사용할 때 처럼 별도의 컴퓨팅 자원에 의존하지 않고 컨테이너를 독립적으로 실행 가능하게 해준다.
각 Fargate Task에는 자체 격리 경계가 있으며 다른 Task와 기본 커널, CPU 리소스, 메모리 리소스 또는 탄력적 네트워크 인터페이스를 공유하지 않는다.
6. AWS Lambda
AWS Lambda
AWS 람다(Lambda)는 서버리스 컴퓨팅 FaaS 상품이다. 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행하게 해주는 서버리스 컴퓨팅 서비스로서 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 별도의 관리 없이 실행 가능하다. 또한 AWS에서 제공하는 다른 서비스와의 호환성도 뛰어나기 때문에 람다에서 지원하는 언어로 코드를 공급해주기만 한다면 실행 및 확장하는데 필요한 부분을 알아서 처리해준다.
람다는 API연동이 쉬우며 Serverless이기 때문에 배포도 매우 쉬워지지만, 제한적인 실행 환경과 트리거가 실행 될때만 코드를 실행한다는 문제점이 있다. 필요할 때만 함수가 호출 되기 때문에 서버가 항상 켜져 있지 않아도 된다는 이점 때문에 비용절감이 된다는 점이 있지만 EC2나 Elastic Beanstalk을 대신하지는 못한다.
Cold Start VS Warm Start
기본적으로 람다는 함수가 호출 될때마다 서버를 실행시키기 때문에 별도의 상태를 저장하지 않는다. 매번 함수가 호출 될때 새로운 환경에서 서버가 돌아가기 이전 서버환경에서 설정 해놨던 이벤트 값들을 가져오지 못한다. 또한 매번 서버가 새로 실행되기 때문에 EC2같은 인스턴스보다는 Latency가 높다.
콜드 스타트는 배포 패키지의 크기와 코드 실행 시간 및 코드의 초기화 시간에 따라 새 실행 환경으로 호출을 라우팅할 때 지연 시간이 발생하는 것을 뜻한다. 특히 위에서 언급한 것 처럼 람다는 서버를 매번 새로 실행하다 보니 지연시간이 생긴다.
콜드 스타트의 반댓말은 웜 스타트로써 EC2 같이 서버가 항상 켜져있다보니 별도의 준비 시간 없이 바로 요청에 대한 응답을 할 준비가 되어있는 상태를 뜻한다.
