4. 컴퓨팅 — EC2·컨테이너·Lambda
이 장에서 처음 나오는 말3개
EC2Elastic Compute Cloud- 운영체제부터 직접 구성할 수 있는 컴퓨팅 인스턴스 서비스.
컨테이너Container- 앱과 의존성을 이미지로 묶어 실행하는 단위.
LambdaAWS Lambda- 호출에 따라 함수를 실행하고 기반 서버를 관리해 주는 서비스.
사진 API 코드는 가상 머신에서도, 컨테이너에서도, 함수에서도 실행할 수 있다. VPC 장이 통신 경로를 다뤘다면 여기서는 실행 환경을 누가 준비하고 고치는지를 본다. 읽고 나면 “앱을 올린 뒤 OS 패치·프로세스 복구·확장은 누구의 일인가?”에 답할 수 있어야 한다.
실행 단위와 서버 관리자를 따로 고르기
섹션 제목: “실행 단위와 서버 관리자를 따로 고르기”| 실행 방식 | 배포하는 단위 | 운영자가 주로 관리할 것 |
|---|---|---|
| EC2 | OS 위의 앱·프로세스 | 게스트 OS, 패치, 프로세스, 용량, 장애 복구 |
| ECS·EKS + EC2 기반 노드 | 컨테이너 이미지 | 앱·배포 설정과 선택한 노드 관리 방식 |
| ECS + Fargate | 컨테이너 이미지와 task 설정 | 이미지·CPU/메모리·네트워크·권한·확장 정책 |
| Lambda | 함수 코드 또는 컨테이너 이미지 | handler·런타임·메모리·timeout·권한·이벤트 처리 |
ECS(Elastic Container Service)와 EKS(Elastic Kubernetes Service)는 컨테이너를 배치·운영하는 서비스다. Fargate는 서버 관리 없이 컨테이너를 실행하는 컴퓨팅 방식이다. 따라서 컨테이너 = 직접 서버 관리, 서버리스 = Lambda만이라는 일대일 대응은 성립하지 않는다. (AWS 컴퓨팅 개요, ECS 실행 환경)
Lambda에 컨테이너 이미지를 올려도 일반 컨테이너 서비스와 같은 수명으로 실행되는 것은 아니다. 함수 호출과 Lambda 실행 규약을 따라야 한다. 선택 기준은 포장 형식 하나보다 실행 시간·상태·운영 요구다.
EC2 생성 화면을 네 가지 질문으로 읽기
섹션 제목: “EC2 생성 화면을 네 가지 질문으로 읽기”| 질문 | 설정 | 의미 |
|---|---|---|
| 무엇을 설치한 상태에서 시작할까? | AMI (Amazon Machine Image) | OS와 필요한 소프트웨어를 담은 시작 이미지 |
| 어느 정도의 자원을 쓸까? | Instance type | CPU·메모리·네트워크 등 컴퓨팅 사양 |
| 어디서 어떤 연결을 받을까? | VPC·Subnet·Security Group | 배치 위치와 통신 허용 규칙 |
| 데이터와 AWS 권한은 어디에 둘까? | EBS·IAM instance profile | 영속 디스크와 앱의 역할 자격증명 |
AMI는 실행 중인 서버가 아니라 서버를 시작하는 이미지다. 같은 AMI로 여러 인스턴스를 만들 수 있다. 아키텍처와 리전 등 사용할 조건도 맞아야 한다. (AMI 개념)
사진 원본을 서버 안에만 저장하면 교체 시 이동·보존 문제가 생긴다. 다음 장에서 EBS와 S3를 구분한다. 앱이 S3를 호출하는 권한은 서버 접속용 SSH 키가 아니라 IAM 역할과 instance profile로 연결한다.
가용성과 확장은 인스턴스를 만든 뒤의 설계다
섹션 제목: “가용성과 확장은 인스턴스를 만든 뒤의 설계다”EC2 하나가 실행 중이라고 자동으로 고가용성이 되는 것은 아니다. 서버가 멈췄을 때 대체 서버가 생기고, 새 서버가 준비된 후 요청이 그쪽으로 가야 한다.
EC2 Auto Scaling은 그룹의 원하는 용량을 유지하고, 정책에 따라 인스턴스 수를 조절한다. **ELB(Elastic Load Balancing)**는 등록된 대상에 트래픽을 분산한다. 앱은 서버가 바뀌어도 동작하도록 세션·파일·작업 상태의 저장 위치를 정해야 한다. (Auto Scaling 개요)
서버만 늘려도 DB 연결 한도나 외부 API 제한 때문에 전체 처리는 느릴 수 있다. 확장 정책과 함께 지표와 추적으로 병목을 찾는다.
이 관계를 실제 구성에 대입하려면 고가용성 실습의 ALB·Target Group·ASG를 본다. ALB는 요청 전달, 대상 그룹은 전달 대상·상태 확인 설정, ASG는 서버 대수 유지와 교체를 맡는다. 시작 템플릿은 교체할 서버의 AMI·앱 초기화·권한을 재현하는 설정이다. (ALB와 ASG 통합)
RDS를 쓰면 무엇을 맡기고 무엇을 고를까?
섹션 제목: “RDS를 쓰면 무엇을 맡기고 무엇을 고를까?”EC2에 DB를 직접 설치하면 OS·DB 운영과 복구 절차를 직접 구성한다. RDS는 DB 운영 기능을 제공하지만 엔진·크기·네트워크·백업 보존·장애 대응 옵션은 사용자가 고른다.
Multi-AZ와 Read Replica의 목적
섹션 제목: “Multi-AZ와 Read Replica의 목적”| 기능 | 주된 목적 | 확인할 조건 |
|---|---|---|
| Multi-AZ DB instance | 다른 AZ의 standby로 장애 전환 | standby는 읽기 트래픽 처리용이 아니다 |
| Multi-AZ DB cluster | 여러 AZ의 DB 인스턴스로 가용성 구성 | 읽기 가능한 replica를 포함하며 지원 엔진·구성이 다르다 |
| Read Replica | 읽기 부하 분산 | 일반적인 RDS DB instance replica는 비동기 복제로 지연 가능 |
“Multi-AZ는 읽기를 못 한다”는 설명은 DB instance 배포의 standby에 한정한다. Multi-AZ DB cluster와 섞지 않는다. 읽기 복제본도 백업을 대신하지 않으며 앱에서 읽기 endpoint를 어떻게 사용할지 정해야 한다. (Multi-AZ 유형, DB instance 읽기 복제본)
서버리스에서도 비용과 실행 조건을 확인하기
섹션 제목: “서버리스에서도 비용과 실행 조건을 확인하기”Lambda는 서버를 고르는 대신 메모리·timeout·동시 실행과 호출 방식을 설정한다. 일반적인 Lambda 함수의 최대 timeout은 **900초(15분)**다. 긴 작업을 한 호출에 계속 묶기 전에 분할 가능한지와 다른 실행 환경을 검토한다. (Lambda quotas)
“서버리스는 API 호출당만 과금”으로 외우지 않는다. Lambda도 요청 수와 실행 시간·메모리 등으로 비용이 계산되며 Provisioned Concurrency 같은 별도 옵션도 있다. 서버가 보이지 않아도 저장소·로그·네트워크 비용은 함께 생긴다. (Lambda 요금 구조)
확인 순서는 실행 시간·상태 보존 → 필요한 용량 → 장애·재시도 → 비용이다. 앱 하나를 서비스 여러 개로 나누는 MSA(Microservices Architecture)는 실행 환경과 별개인 설계 선택이다. 컨테이너나 Lambda를 쓴다고 반드시 앱을 잘게 나눌 필요는 없다.