Module 2. 클라우드 컴퓨팅
Amazon EC2
EC2는 안전하고 크기 조정이 가능한 컴퓨팅 용량을 Amazon EC2 인스턴스로 클라우드에서 제공합니다.
EC2는 가상화 기술을 사용하여 AWS에서 관리하는 물리적 호스트 시스템에서 실행됩니다.
EC2 인스턴스를 가동할 때는 전체 호스트를 소유하지 않아도 됩니다.
대신 호스트를 다른 여러 인스턴스와 공유합니다. 가상 머신이라고도 하죠.
그리고 호스트 머신에서 실행하는 하이퍼바이저가 가상 머신 간의 기본 물리적 리소스 공유를 책임집니다.
멀티테넌시
: 기본 하드웨어를 공유하는 것.
: 하이퍼바이저는 이러한 멀티 테넌시 조정을 책임지며 이는 AWS에서 관리합니다.
온프레미스와 Amazon EC2 비교
온프레미스
- 미리 하드웨어를 구매해야 합니다.
- 서버가 배달될 때 까지 기다려야 합니다.
- 물리적 데이터 센터에 서버를 설치해야 합니다.
- 필요한 모든 구성을 수행해야 합니다.
EC2
- 짧은 시간에 EC2 인스턴스를 프로비저닝하고 시작할 수 있습니다.
- 프로비저닝 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다. - 워크로드 실행을 완료했다면 인스턴스 사용을 중지할 수 있습니다.
- 인스턴스가 실행 중일 때 사용한 컴퓨팅 시간에 대해서만 비용을 지불하고 인스턴스가 중지 또는 종료된 상태에서는 비용을 지불하지 않습니다.
- 필요한 서버 용량에 대해서만 비용을 지불하므로 비용을 절감할 수 있습니다.
Amazon EC2 인스턴스 유형
Amazon EC2 인스턴스 유형은 다양한 작업에 최적화되어 있습니다.
인스턴스 유형을 선택할 때는 워크로드 및 애플리케이션의 구체적 요구 사항을 고려합니다.
여기에는 컴퓨팅, 메모리 또는 스토리지 기능에 대한 요구 사항이 포함될 수 있습니다.
- 범용 인스턴스
* 컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공- 다양한 워크로드, 웹 서버, 코드 리포지토리
- 앱 서버, 게임 서버, 엔터프라이즈급 백엔드 서버, 중소 규모 데이터 베이스
_
- 컴퓨터 최적화 인스턴스
* 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합- 컴퓨팅 집약적 작업, 게임 서버, 고성능 컴퓨팅(HPC), 과학 모델링
_
- 컴퓨팅 집약적 작업, 게임 서버, 고성능 컴퓨팅(HPC), 과학 모델링
- 메모리 최적화 인스턴스
* 메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 빠른 성능을 제공하기 위해 설계되었습니다.- 메모리 집약적인 작업에 적합
_
- 메모리 집약적인 작업에 적합
- 엑셀러레이티드 컴퓨팅 인스턴스
* 하드웨어 액셀러레이터 또는 코프로세서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서보다 더 효율적으로 수행합니다.- 부동 소수점 계산, 그래픽 처리, 데이터 패턴 매칭
_
- 부동 소수점 계산, 그래픽 처리, 데이터 패턴 매칭
- 스토리지 최적화 인스턴스
* 로컬 스토리지의 대규모 데이터 세트에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계되었습니다.- 로컬에 저장된 데이터를 위해 고성능이 요구되는 워크로드
_
- 로컬에 저장된 데이터를 위해 고성능이 요구되는 워크로드
Amazon EC2 요금
Amazon EC2에서는 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.
- 온 디맨드
인스턴스를 실행한 기간만큼만 비용을 낸다는 뜻.
인스턴스 유형과 선택한 운영 체제에 따라 시간당 또는 초당 비용을 지불합니다.- 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 매우 적합합니다.
- 1년 이상 지속되는 워크로드에는 권장하지 않습니다.
_
- Amazon EC2 Savings Plans
1년 또는 3년 기간동안 일정한 사용량을 약정하는 대가로 EC2를 저렴하게 제공합니다.
이 유연한 가격 책정 모델로 AWS 컴퓨팅 사용량 요금을 72%까지 절약할 수 있습니다.- 인스턴스 패밀리, 크기, OS, 테넌시 또는 AWS 리전에 상관없이 EC2 사용 가격을 낮출 수 있습니다.
- 서버리스 컴퓨팅 옵션인 AWS Fargate와 AWS Lambda 사용량에도 적용됩니다.
_
- 예약 인스턴스
꾸준한 상태의 워크로드나 사용량이 예측 가능한 워크로드에 적합합니다.
온디맨드 요금제 대비 최대 75% 저렴합니다.
표준 예약 및 컨버터블 예약 인스턴스는 1년 또는 3년 약정- 예약 인스턴스 약정 기간이 끝나도 중단 없이 Amazon EC2 인스턴스를 계속 사용할 수 있습니다.
- 인스턴스 종료, 인스턴스 속성과 일치하는 새 예약 인스턴스 구입 시, 온 디맨드 요금이 부과됩니다.
_
- 스팟 인스턴스
시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합합니다.
여분의 Amazon EC2 컴퓨팅 용량을 온디맨드 가격의 최대 90%로 절감 요청할 수 있습니다.
중요한 점은 AWS가 필요시 언제든 인스턴스를 회수한 다음 작업을 마무리하고 상태를 저장하라는 2분 경고를 표시한다는 것입니다. 이후 필요할 때 언제든 다시 시작할 수 있습니다.
Savings Plans와 달리, 계약이나 일정한 컴퓨팅 사용량에 대한 약정이 필요하지 않습니다.- 스팟 인스턴스를 선택할 때는 워크로드에서 중단을 허용할 수 있는지 확인해야 합니다. 대표적인 예는 배치 워크로드입니다.
_
- 스팟 인스턴스를 선택할 때는 워크로드에서 중단을 허용할 수 있는지 확인해야 합니다. 대표적인 예는 배치 워크로드입니다.
- 전용 호스트
사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버입니다.- 보통 규정 준수 요구 사항을 충족합니다.
- Amazon EC2 옵션 중에서 전용 호스트가 가장 비용이 많이 듭니다.
_
확장성과 탄력성
수요를 고객의 평균으로 맞추면 효율적이지만 최대 수요일 때 이용하지 못하는 고객이 생깁니다.
리소스를 최대로 설정하면 모든 고객이 이용할 수 있지만 idle 리소스가 매우 많아집니다.
확장성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처를 설계해야 합니다.
이 조정 프로세스가 자동으로 수행되도록 하려면 어떤 AWS 서비스를 사용해야 할까요?
Amazon EC2 인스턴스에 이 기능을 제공하는 AWS 서비스가 Amazon EC2 Auto Scaling입니다.
Amazon EC2 Auto Scaling
Amazon EC2 Auto Scaling을 사용하면 변화하는 애플리케이션 수요에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거할 수 있습니다.
필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지할 수 있습니다.
Amazon EC2 Auto Scaling 두 가지 접근 방식
- 동적 조정 : 수요 변화에 대응합니다.
- 예측 조정 : 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동으로 예약합니다.
증가하는 수요는 두 가지 방법으로 처리할 수 있습니다.
수직 확장 (실행 중인 장치의 성능을 추가)과 수평 확장(장치 수의 추가)입니다.
카페의 예시를 다시 살펴보자면, 고객이 증가하면 카운터에 있는 사람이 커진다고 고객의 주문이 더 빨리 처리하지는 못합니다. 상황이 직원이 아닌 고객에게 달려있기 때문입니다.
따라서 우리는 더 많은 직원이 필요합니다.질문이 있습니다.
주문 음료를 만드는 인스턴스보다 주문을 받는 인스턴스가 많으면 어떻게 될까요?
이 경우에는 음료를 만드는 인스턴스가 주문 장비에서 전송하는 것보다 많은 양의 작업을 처리할 수 있습니다. 백로그가 없으니 작업자 인스턴스를 추가할 이유가 없죠.
이는 시스템 분리의 장점 중 하나입니다.
개별적인 문제를 해결하기 위해 오버프로비저닝하는 대신 프로세스 각 부분에 적절한 수준의 성능을 제공하게 되죠.여기서 AWS는 할 일 없이 쉬고 있는 추가 작업자가 필요 없어지면 집으로 돌려보냅니다.
즉, 인스턴스를 중지한다는 뜻입니다.Amazon EC2 Auto Scaling은 수요에 따라 인스턴스를 추가하고 필요 없는 인스턴스는 폐기합니다. 24시간 내내 적절한 수의 인스턴스만 보유한다는 뜻이죠.
Elastic Load Balancing
Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스입니다.
트래픽을 적절하게 분산한다면,
- 고성능
- 비용 효율성 증가
- 고가용성
- 자동 확장 기능
ELB 미사용시 매우 복잡해진다.
Load Balancer
: Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 합니다.
: 즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅됩니다.
: 그런 다음 요청을 처리할 여러 리소스로 분산됩니다.
메시징 및 대기열 (Messaging and Queueing)
메시지를 완충 기억 장치에 배치한다는 개념
다시 카페를 예를 들어,
계산원이 주문을 받고 주문서를 바리스타에게 전달했는데 바리스타가 쉬고 있거나 다른 주문을 처리하느라 바쁘다면 어떨까요?
계산원은 바리스타가 주문을 처리할 준비가 되기 전까지는 아무것도 할 수 없습니다.
그리고 특정 시점이 되면 주문이 취소되고 계산원은 다음 고객을 응대하게 될 것입니다.
따라서, 이 문제를 해결하기 위해 일종의 완충 기억 장치의 역할인 주문을 게시합니다.
모놀리식 애플리케이션
애플리케이션은 여러 구성 요소로 구성됩니다.
구성 요소는 서로 통신하여 데이터를 전송하고, 요청을 이행하고, 애플리케이션을 계속 실행합니다.
구성 요소가 밀결합된 애플리케이션이 있다고 가정해 보겠습니다.
이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있습니다.
이러한 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있습니다.
이 접근 방식에서는 한 구성 요소에서 장애가 발생하면 다른 구성 요소에서 장애가 발생하고,
심지어 전체 애플리케이션에서 장애가 발생할 수도 있습니다.
마이크로서비스
마이크로서비스 접근 방식에서는 애플리케이션 구성 요소가 소결합됩니다.
이 경우 단일 구성 요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동합니다.
소결합 때문에 전체 애플리케이션에서 장애가 발생하는 것이 방지됩니다.
Amazon Simple Notification Service (Amazon SNS)
Amazon Simple Notification Service(Amazon SNS)는 게시/구독 서비스입니다.
게시자는 Amazon SNS 주제를 사용하여 구독자에게 메시지를 게시합니다.
이는 카페에서 계산원이 음료를 만드는 바리스타에게 주문 사항을 전달하는 것과 비슷합니다.
Amazon SNS에서 구독자는 웹 서버, 이메일 주소, AWS Lambda 함수 또는 그 밖의 여러 옵션이 될 수 있습니다.
단일 주제에서 업데이트 게시
카페에 모든 비즈니스 영역의 업데이트를 포함하는 단일 뉴스레터가 있다고 가정해 보겠습니다. 여기에는 쿠폰, 커피 상식, 신제품과 같은 주제가 포함됩니다. 단일 뉴스레터이기 때문에 모든 주제가 그룹화됩니다. 뉴스레터를 구독하는 모든 고객은 쿠폰, 커피 상식, 신제품에 대한 업데이트를 받습니다.
얼마 후 일부 고객이 관심 있는 특정 주제에 대해서만 별도의 뉴스레터를 받으면 좋겠다는 의견을 표명합니다. 커피숍 점주는 이 접근 방식을 시험해 보기로 결정합니다.
여러 주제에서 업데이트 게시
이제 카페는 모든 주제를 다루는 단일 뉴스레터 대신 이를 3개의 뉴스레터로 나눴습니다.
각 뉴스레터는 쿠폰, 커피 상식, 신제품과 같은 특정 주제만을 다룹니다.이제 구독자는 구독한 특정 주제에 대해서만 즉시 업데이트를 받게 됩니다.
구독자는 주제를 하나 또는 여러 개 구독할 수 있습니다. 예를 들어 첫 번째 고객은 쿠폰 주제만 구독하고 두 번째 구독자는 커피 상식 주제만 구독합니다. 세 번째 고객은 커피 상식 주제와 신제품 주제를 구독합니다.
Amazon Simple Queue Service(Amazon SQS)
Amazon Simple Queue Service(Amazon SQS)는 메시지 대기열 서비스입니다.
Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있습니다.
Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송합니다. 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제합니다.
EX) 주문 이행
만약 계산원이 주문을 받아 바리스타에게 전달하려는데 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘다면 어떻게 될까요? 계산원은 바리스타가 주문을 받을 준비가 될 때까지 기다려야 합니다. 그러면 주문 프로세스가 지연되고 고객은 주문한 음료를 받을 때까지 더 오래 기다려야 합니다.
커피숍의 인기가 많아지고 주문하려는 고객의 줄이 줄어드는 속도가 더 느려지면 점주는 현재 주문 프로세스가 시간이 많이 걸리고 비효율적이라는 것을 알게 됩니다. 점주는 대기열을 사용하는 다른 접근 방식을 시도하기로 결정합니다.
EX) 대기열에 있는 주문
계산원이 주문을 대기열에 넣습니다. 이를 계산원과 바리스타 사이의 버퍼 역할을 하는 주문판이라고 생각할 수 있습니다. 바리스타가 쉬는 시간이거나 다른 주문으로 바쁘더라도 계산원은 계속해서 새 주문을 대기열에 넣을 수 있습니다.
다음으로 바리스타가 대기열을 확인하고 주문을 검색합니다.
바리스타가 음료를 만들어 고객에게 제공합니다.
바리스타는 완료된 주문을 대기열에서 제거합니다.
바리스타가 음료를 만드는 동안 계산원은 계속 새로운 주문을 받아 대기열에 추가할 수 있습니다.
분리된 애플리케이션과 마이크로서비스의 경우, Amazon SQS를 사용하면 구성 요소 간에 메시지를 전송, 저장, 검색할 수 있습니다.
개별 구성 요소는 이러한 분리된 접근 방식을 통해 보다 효율적이고 독립적으로 작동할 수 있습니다.
추가 컴퓨팅 서비스
Amazon EC2에서 실행하려면 애플리케이션은,
- 인스턴스 (가상 서버)를 프로비저닝
- 사용자 코드를 업로드
- 애플리케이션이 실행되는 동안 계속해서 인스턴스를 관리
서버리스 컴퓨팅
서버리스 : 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻.
서버리스 컴퓨팅을 사용하면 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는 데 더 집중할 수 있습니다.
서버리스 컴퓨팅의 또 다른 이점은 서버리스 애플리케이션을 자동으로 확장할 수 있는 유연성입니다. 서버리스 컴퓨팅은 처리량 및 메모리와 같은 소비 단위를 수정하여 애플리케이션의 용량을 조정할 수 있습니다.
AWS Lambda
서버리스 컴퓨팅용 AWS 서비스는 AWS Lambda입니다.
즉, 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스입니다.
AWS Lambda를 사용하는 경우 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.
코드를 실행하는 동안에만 요금이 부과됩니다.
사실상 모든 유형의 애플리케이션 또는 백엔드 서비스 코드를 실행할 수 있으며 이를 관리할 필요는 전혀 없습니다.
작동 방식
AWS에서는 컨테이너식 애플리케이션을 빌드/실행할 수도 있다.
컨테이너
: 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식
: 보안성, 안정성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크플로에도 컨테이너를 사용합니다.
작동 방식
여러 컨테이너가 있는 단일 호스트
회사의 애플리케이션 개발자의 컴퓨터 환경이 IT 운영 직원이 사용하는 컴퓨터의 환경과 다르다고 가정해 보십시오.
개발자는 애플리케이션 환경이 배포와 상관없이 일관되게 유지되기를 원합니다.
따라서 컨테이너식 접근 방식을 사용합니다.
이를 통해 애플리케이션을 디버깅하고 컴퓨팅 환경의 차이를 진단하는 데 드는 시간을 줄일 수 있습니다.
수백 개의 컨테이너가 있는 수십 개의 호스트
컨테이너식 애플리케이션을 실행할 때는 확장성을 고려하는 것이 중요합니다.
여러 컨테이너가 있는 단일 호스트 대신 수백 개의 컨테이너가 있는 수십 개의 호스트를 관리해야 한다고 가정해 보십시오.
또는 수천 개의 컨테이너가 있는 수백 개의 호스트를 관리해야 합니다.
규모가 커지면 메모리 사용량, 보안, 로깅 등을 모니터링하는 데 시간이 얼마나 걸릴지 상상해 보십시오.
컨테이너 오케스트레이션 서비스는 컨테이너식 애플리케이션을 배포, 관리, 확장하는 데 도움을 줄 수 있습니다.
컨테이너 오케스트레이션을 제공하는 두 가지 서비스
- Amazon Elastic Container Service
- Amazon Elastic Kubernetes Service
Amazon Elastic Container Service(Amazon ECS)
Amazon Elastic Container Service(ECS)는 AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템입니다.
Amazon ECS는 Docker 컨테이너를 지원합니다.
Docker는 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼입니다.
AWS는 오픈 소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원합니다.
Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있습니다.
Amazon Elastic Kubernetes Service(Amazon EKS)
Amazon Elastic Kubernetes Service(Amazon EKS)는 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스입니다.
Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어입니다.
자원자로 구성된 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극적으로 협력합니다.
Kubernetes 애플리케이션의 새로운 기능이 릴리스되면 Amazon EKS로 관리되는 애플리케이션에 이러한 업데이트를 손쉽게 적용할 수 있습니다.
AWS Fargate
AWS Fargate는 컨테이너용 서버리스 컴퓨팅 엔진으로, Amazon ECS와 Amazon EKS에서 작동합니다.
AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없습니다.
AWS Fargate는 자동으로 서버 인프라를 관리합니다.
애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 됩니다.
Summary
클라우드 컴퓨팅
: 종량 과금제 요금으로 인터넷을 통해 필요에 따라 IT리소스를 제공
: 이는 컴퓨팅, 네트워킹, 스토리지, 분석 및 기타 유형의 리소스 같은 IT 리소스를 요청하면 온디맨드로 제공된다는 뜻입니다.
: 리소스 요금을 선불로 지불하지 않습니다. 대신 프로비저닝 후 월말에 지불합니다.
Amazon EC2
: EC2를 사용하면 EC2 인스턴스라고 하는 가상 서버를 동적으로 가동 및 중단할 수 있습니다.
: EC2 인스턴스를 시작할 때는 인스턴스 패밀리를 선택하고 인스턴스 패밀리에 따라 인스턴스가 실행되는 하드웨어가 정해집니다.
특정 목적을 위해 제작된 인스턴스를 이용할 수도 있습니다.
이 인스턴스는
범용, 컴퓨팅 최적화, 메모리 최적화, 액셀러레이티드 컴퓨팅, 스토리지 최적화
로 구분됩니다.
Amazon EC2 Auto Scaling
: EC2 인스턴스는 인스턴스 규모를 조정하여 수직으로 확장하거나 새 인스턴스를 시작하여 수평으로 확장할 수 있습니다.
Elastic Load Balancer
: EC2를 수평으로 확장한 후에는 수신하는 트래픽을 인스턴스에 분산하는 도구
EC2 인스턴스 요금제
: 온디맨드는 가장 유연하고 계약이 필요 없으며 스팟 가격 책정을 통해 사용하지 않는 용량에는 할인된 가격을 적용합니다.
: Savings Plan이나 예약 인스턴스의 경우 AWS와 계약을 맺어 일정 수준의 사용량을 약정하면 할인 요금이 적용됩니다.
: Savings Plan은 AWS Lambda와 AWS Fargate는 물론 EC2 인스턴스에도 적용됩니다.
메시징 서비스
: Amazon Simple Queue Service, 즉 SQS라고 하는 서비스가 있습니다. 이 서비스를 이용하면 시스템 구성 요소를 분리할 수 있습니다.
: Amazon Simple Notification Service, 즉 SNS는 이메일, 문자 메시지, 푸시 알림, 심지어 HTTP 요청을 포함하는 메시지를 전달하는 데 사용합니다. 메시지가 게시되면 모든 구독자에게 전송됩니다.
다양한 유형의 컴퓨팅
: Amazon Elastic Container Service, 줄여서 ECS라고 하는 컨테이너 서비스가 있습니다.
: Amazon Elastic Kubernetes Service, 줄여서 EKS라고 하는 서비스도 있습니다.
: 두 서비스 모두 컨테이너 오케스트레이션 도구입니다.
: 이러한 도구를 EC2 인스턴스와 함께 사용할 수 있지만 관리하고 싶진 않다면 그래도 됩니다.
: AWS Fargate를 사용하면 되니까요.
: 이 서비스를 이용하면 컨테이너를 서버리스 컴퓨팅 플랫폼에서 실행할 수 있습니다.
: AWS Lambda를 사용하면 코드를 업로드하고 트리거를 기반으로 실행되도록 구성할 수 있습니다.
: 코드가 실제로 실행될 때만 비용을 내면 됩니다.
