클라우드에서 서버를 운영한다는 건, 결국 어떤 의미일까?
원문: AWS Cloud Practitioner Essentials — Module 2: Compute in the Cloud
출처: AWS E-Learning / Compiled by Kenneth Leung (2020)
한 줄 요약: AWS에서 컴퓨팅 자원을 다루는 핵심 서비스들 — EC2, Auto Scaling, Load Balancing, Lambda, 컨테이너 — 의 개념과 차이를 정리한 모듈이다.
왜 클라우드 컴퓨팅이 필요한가
회사에서 새 웹사이트를 만들어야 한다고 가정해 보자. 전통적인 방식이라면 이런 과정을 거쳐야 한다.
- 서버 하드웨어를 구매한다 (선불로 큰 비용 발생)
- 배송을 기다린다 (몇 주에서 몇 달)
- 데이터센터에 설치하고 배선한다
- 각종 설정을 마친 뒤에야 비로소 사용할 수 있다
문제는 한 번 산 서버는 사용하든 안 하든 비용이 발생한다는 점이다. AWS의 Amazon EC2를 쓰면 이 과정이 몇 분으로 줄어든다. 필요할 때 켜고, 안 쓸 때 끄고, 실제로 사용한 시간만큼만 비용을 낸다.
Amazon EC2, 클라우드 위의 가상 서버
Amazon EC2(Elastic Compute Cloud)는 클라우드에서 크기를 자유롭게 조절할 수 있는 가상 서버를 제공하는 서비스다. 이 가상 서버 하나하나를 “인스턴스”라고 부른다.
작동 방식은 세 단계
| 단계 | 설명 |
|---|---|
| Launch (시작) | 운영체제, 애플리케이션, 하드웨어 사양을 골라 인스턴스를 띄운다 |
| Connect (연결) | 프로그램이나 사용자가 인스턴스에 접속한다 |
| Use (사용) | 소프트웨어 설치, 파일 관리 등 원하는 작업을 수행한다 |
멀티테넌시, 한 건물에 여러 세입자가 사는 것과 같다
EC2 인스턴스는 물리 서버 위에서 가상화(virtualization) 기술로 돌아간다. 하나의 물리 서버를 여러 인스턴스가 나눠 쓰는 구조인데, 이를 멀티테넌시(multi-tenancy)라고 한다. 아파트 한 동에 여러 세대가 살지만 각 세대는 독립적인 것과 비슷하다. 이 분배를 관리하는 것이 하이퍼바이저(hypervisor)로, AWS가 직접 운영한다. 인스턴스끼리는 서로의 존재를 알 수 없고, 보안이 분리되어 있다.
어떤 인스턴스를 골라야 할까? — EC2 인스턴스 유형
인스턴스는 용도에 따라 다섯 가지 유형으로 나뉜다. 어떤 작업을 하느냐에 따라 적합한 유형이 달라진다.
| 유형 | 특징 | 적합한 작업 |
|---|---|---|
| 범용(General Purpose) | CPU, 메모리, 네트워크가 균형 잡힌 구성 | 애플리케이션 서버, 중소규모 DB |
| 컴퓨팅 최적화(Compute Optimized) | 고성능 프로세서에 특화 | 게임 서버, 고성능 웹 서버, 배치 처리 |
| 메모리 최적화(Memory Optimized) | 대용량 데이터를 메모리에 올려 빠르게 처리 | 고성능 DB, 실시간 비정형 데이터 처리 |
| 가속 컴퓨팅(Accelerated Computing) | GPU 등 하드웨어 가속기 탑재 | 그래픽 처리, 부동소수점 연산, 데이터 패턴 매칭 |
| 스토리지 최적화(Storage Optimized) | 로컬 스토리지에 대한 빠른 읽기/쓰기 | 분산 파일 시스템, 데이터 웨어하우스, OLTP |
IOPS(Input/Output Operations Per Second)라는 용어가 나오는데, 이는 저장 장치가 1초에 처리할 수 있는 읽기/쓰기 횟수를 뜻한다. 스토리지 최적화 인스턴스는 이 수치가 매우 높다.
비용은 어떻게 내나? — EC2 요금 체계
EC2의 요금 옵션은 다섯 가지다. 상황에 맞게 조합하면 비용을 크게 줄일 수 있다.
| 요금 모델 | 핵심 특징 | 적합한 상황 |
|---|---|---|
| 온디맨드(On-Demand) | 선불 없이 사용한 만큼만 지불 | 테스트, 개발, 사용 패턴을 아직 모를 때 |
| Savings Plans | 1~3년간 일정 사용량을 약정, 최대 72% 할인 | 사용량이 어느 정도 예측 가능할 때 |
| 예약 인스턴스(Reserved) | 온디맨드에 대한 할인 적용, 1~3년 약정 | 꾸준하고 예측 가능한 워크로드 |
| 스팟 인스턴스(Spot) | 최대 90% 할인, 대신 AWS가 언제든 회수 가능 | 중단돼도 괜찮은 배치 작업 |
| 전용 호스트(Dedicated Hosts) | 물리 서버 전체를 독점 사용, 가장 비쌈 | 라이선스 규정 준수, 보안 컴플라이언스 |
스팟 인스턴스는 가격이 파격적이지만, AWS가 여유 용량이 필요하면 2분 전 경고 후 인스턴스를 회수한다. 따라서 중단에 민감한 서비스(예: 웹 서버, 운영 DB)에는 적합하지 않다.
트래픽이 몰리면 어떻게 하지? — 확장성(Scalability)
온프레미스 데이터센터를 운영한다면 딜레마에 빠진다.
- 평균 트래픽에 맞추면: 평소엔 괜찮지만, 피크 타임에 서버가 버티지 못한다
- 최대 트래픽에 맞추면: 대부분의 시간 동안 서버가 놀게 된다
클라우드에서는 이 문제를 자동 확장으로 해결한다. 필요한 만큼만 쓰고, 수요가 변하면 자원을 늘리거나(scale out) 줄인다(scale in).
Amazon EC2 Auto Scaling
Auto Scaling 그룹을 만들 때 세 가지 용량을 설정한다.
| 설정 | 의미 |
|---|---|
| 최소 용량(Minimum) | 항상 유지되는 최소 인스턴스 수 |
| 희망 용량(Desired) | 평상시 운영할 인스턴스 수 (미설정 시 최소값과 동일) |
| 최대 용량(Maximum) | 아무리 트래픽이 몰려도 이 수를 넘지 않음 |
확장 방식은 두 가지다.
- 동적 스케일링(Dynamic Scaling): 실시간 수요 변화에 대응
- 예측 스케일링(Predictive Scaling): 과거 패턴을 분석해 미리 인스턴스를 준비
트래픽을 골고루 나눠주는 교통 경찰 — Elastic Load Balancing
Elastic Load Balancing(ELB)은 들어오는 트래픽을 여러 EC2 인스턴스에 자동으로 분산해 주는 서비스다. 커피숍에서 손님이 몰릴 때 빈 카운터로 안내해 주는 직원이라고 생각하면 된다.
핵심 특성을 정리하면 다음과 같다.
- 단일 진입점(Single URL): 프런트엔드는 ELB 주소 하나만 알면 된다. 뒤에 인스턴스가 몇 개든 상관없다.
- 리전 수준에서 동작: 개별 인스턴스가 아니라 AWS 리전 단위로 운영되기 때문에 자동으로 고가용성(high availability)이 보장된다.
- 자동 확장: 트래픽이 증가해도 추가 비용이나 별도 설정 없이 ELB가 알아서 처리량을 늘린다.
Auto Scaling이 인스턴스 수를 조절하는 역할이라면, ELB는 그 인스턴스들에 부하를 균등하게 배분하는 역할이다. 둘은 별개의 서비스지만 함께 쓸 때 효과가 극대화된다. 이런 구조를 분리된 아키텍처(decoupled architecture)라고 부른다.
주문이 밀려도 괜찮아 — 메시징과 큐잉
커피숍에서 캐셔가 주문을 받아 바리스타에게 직접 전달한다고 해 보자. 바리스타가 자리를 비우면? 캐셔도 멈추고, 주문도 밀리고, 전체 프로세스가 멈춘다. 이처럼 구성 요소끼리 직접 통신하는 구조를 밀결합(tightly coupled)이라 한다.
해결책은 중간에 주문판(큐)을 두는 것이다. 캐셔는 주문을 큐에 넣고, 바리스타는 큐에서 꺼내 처리한다. 바리스타가 잠시 자리를 비워도 주문은 큐에 안전하게 남아 있다. 이런 구조를 느슨한 결합(loosely coupled)이라 하고, AWS에서 지향하는 아키텍처 방식이다.
모놀리식 vs 마이크로서비스
- 모놀리식(Monolithic): 모든 기능이 하나로 묶여 있어, 한 부분이 고장 나면 전체가 영향을 받는다
- 마이크로서비스(Microservices): 기능별로 분리되어 있어, 한 부분이 실패해도 나머지는 정상 동작한다
이 느슨한 결합을 가능하게 해 주는 AWS 서비스가 바로 SQS와 SNS다.
Amazon SQS — 메시지 큐잉 서비스
| 항목 | 설명 |
|---|---|
| 역할 | 소프트웨어 구성 요소 간 메시지를 보내고, 저장하고, 받는 큐 서비스 |
| 핵심 개념 | 메시지 안의 데이터를 페이로드(payload)라 부르며, 전달이 완료될 때까지 보호된다 |
| 특징 | 상대 서비스가 꺼져 있어도 메시지가 유실되지 않는다 |
Amazon SNS — 발행/구독 서비스
| 항목 | 설명 |
|---|---|
| 역할 | 발행자(publisher)가 메시지를 보내면, 구독자(subscriber)에게 전달하는 서비스 |
| 핵심 개념 | SNS 토픽이라는 채널을 만들고, 구독자는 관심 있는 토픽만 선택적으로 구독한다 |
| 차이점 | SQS와 달리 모바일 푸시, SMS, 이메일 등으로 최종 사용자에게 직접 알림을 보낼 수 있다 |
SQS는 “1:1 메시지 전달”에, SNS는 “1:다수 알림 전파”에 적합하다.
서버 관리는 이제 그만 — 서버리스 컴퓨팅
EC2는 유연하지만 여전히 직접 관리해야 할 것들이 있다. 인스턴스를 프로비저닝하고, 코드를 올리고, 패치하고, 스케일링을 설정해야 한다.
서버리스(serverless)는 말 그대로 “서버를 신경 쓰지 않는다”는 의미다. 서버가 없는 게 아니라, 서버 인프라의 프로비저닝, 스케일링, 고가용성, 유지보수를 AWS가 전부 알아서 처리한다는 뜻이다.
AWS Lambda
Lambda는 서버리스 컴퓨팅의 대표 서비스다.
작동 방식:
- 코드를 Lambda에 업로드한다
- 이벤트 소스(AWS 서비스, HTTP 요청 등)와 연결하는 트리거를 설정한다
- 이벤트가 발생하면 코드가 자동 실행된다
- 실행된 시간만큼만 비용을 낸다
주의할 점은 Lambda가 15분 이내에 끝나는 작업용이라는 것이다. 딥러닝처럼 오래 걸리는 작업에는 적합하지 않고, 웹 백엔드 처리, 이미지 리사이즈, 비용 리포트 생성 같은 짧고 빠른 처리에 맞춰져 있다.
컨테이너라는 선택지 — ECS, EKS, Fargate
서버리스로 가기엔 아직 인프라에 대한 접근이 필요하고, EC2만 쓰기엔 관리가 부담스러운 경우가 있다. 이때 등장하는 것이 컨테이너(container)다.
컨테이너는 애플리케이션의 코드, 의존성, 설정을 하나의 패키지로 묶는 방식이다. Docker가 대표적인 컨테이너 플랫폼이고, 이 컨테이너들은 EC2 인스턴스 위에서 격리된 채로 실행된다.
컨테이너가 수백, 수천 개로 늘어나면 이를 관리하는 오케스트레이션(orchestration)이 필요하다. AWS에서는 두 가지 옵션을 제공한다.
| 서비스 | 설명 |
|---|---|
| Amazon ECS | AWS가 만든 고성능 컨테이너 관리 시스템. Docker 컨테이너를 API 호출로 실행/중단한다 |
| Amazon EKS | 오픈소스 Kubernetes를 AWS에서 완전 관리형으로 제공하는 서비스 |
AWS Fargate — 서버리스 컨테이너 엔진
ECS나 EKS를 쓸 때 EC2 인스턴스조차 관리하고 싶지 않다면 AWS Fargate를 쓰면 된다. Fargate는 컨테이너를 위한 서버리스 컴퓨팅 플랫폼으로, 서버 인프라를 AWS가 관리하고 사용자는 컨테이너 실행에 필요한 자원에 대해서만 비용을 낸다.
그래서 뭘 쓰면 되나? — 컴퓨팅 서비스 선택 가이드
| 상황 | 추천 서비스 |
|---|---|
| OS에 대한 전체 접근이 필요한 전통적 애플리케이션 | EC2 |
| 짧은 실행 시간의 이벤트 기반 함수, 서버 관리 불필요 | AWS Lambda |
| Docker 컨테이너 기반 워크로드 (AWS 네이티브 도구 선호) | Amazon ECS |
| Docker 컨테이너 기반 워크로드 (Kubernetes 선호) | Amazon EKS |
| 컨테이너를 쓰되 EC2 인스턴스 관리도 하고 싶지 않을 때 | AWS Fargate |
마무리
클라우드 컴퓨팅의 핵심은 결국 “필요한 만큼만 쓰고, 쓴 만큼만 낸다”는 원칙에 있다. EC2로 가상 서버를 직접 운영할 수도 있고, Lambda로 코드만 올려두고 이벤트가 올 때만 실행할 수도 있다. 컨테이너로 애플리케이션을 패키징하고, Fargate로 서버 관리까지 맡길 수도 있다.
어떤 서비스를 선택하든 공통된 방향은 같다. 관리 부담은 줄이고, 비용은 실제 사용량에 맞추고, 확장은 자동으로. 이 원칙을 이해하면, AWS의 수많은 서비스가 결국 같은 철학 위에 서 있다는 것이 보이기 시작한다.