백엔드 › 클라우드·네트워크
서버를 사는 대신 빌려 쓴다는 게 이렇게 큰 의미였다 — AWS 클라우드 컴퓨팅 기초
요즘 클라우드 관련 자료를 좀 챙겨보고 있다. 그동안 EC2, VPC 이런 단어는 들어봤어도 정확히 뭔지는 몰랐는데, 이번 기회에 제대로 정리해보려고 한다.
첫 편은 제일 기초인 “클라우드 컴퓨팅이 뭔지”부터 “AWS가 실제로 어디에 있는지”까지다. 그동안 당연하게 넘겼던 개념들에 생각보다 다 이유가 있었다. 회사에서 “왜 클라우드로 갈아타야 하나요”라는 질문에 답할 일이 생기면 이 글 하나로 정리해서 말할 수 있을 정도로 자세히 써보려고 한다.
클라우드 컴퓨팅이 뭐길래
한 줄로 정리하면 “필요할 때 빌려 쓰고, 쓴 만큼만 돈 내는” 컴퓨터 자원 대여 서비스다. 예전 같으면 서버가 필요할 때 장비를 사고, 배송을 기다리고, 설치까지 몇 주는 걸렸을 텐데 지금은 콘솔에서 버튼 몇 번이면 끝난다.
이게 가능한 이유는 AWS가 전 세계에 미리 대규모 서버 풀을 갖춰두고 있어서다. 사용자는 API 호출 한 번으로 그 풀에서 필요한 만큼만 즉시 할당받는다. 다 쓰면 반납하면 그만이고, 반납한 순간부터는 과금도 끝난다.
1
2
3
4
5
6
7
사용자 요청 (콘솔 클릭 / API 호출)
↓
AWS 인프라 풀에서 즉시 할당 (수 초~수 분)
↓
과금 시작 (사용 중인 만큼만)
↓
삭제 요청 → 과금 종료
여기서 두 단어가 핵심이다. on-demand(온디맨드, 필요할 때 바로 받는다는 뜻)와 pay-as-you-go(종량과금제, 쓴 만큼만 낸다는 뜻). 정수기를 사는 대신 생수 정기배송을 시켜서 마신 만큼만 요금을 내는 것과 비슷한 구조라고 보면 이해가 빨랐다.
온프레미스 시절엔 얼마나 걸렸을까
이 부분이 궁금해서 좀 더 찾아봤다. 온프레미스 환경에서 서버 하나를 실제로 쓸 수 있게 만들려면 대략 이런 과정을 거쳤다고 한다.
- 요구사항에 맞는 하드웨어 견적 요청 (며칠)
- 결재·구매 승인 (며칠~몇 주, 조직에 따라 편차 큼)
- 장비 배송 및 입고 (몇 주)
- 데이터센터 랙 설치, 전원·네트워크 케이블링 (며칠)
- OS 설치, 방화벽·보안 설정 (며칠)
빠르면 3~4주, 늦으면 몇 달까지 걸렸다는 얘기를 듣고 좀 놀랐다. 반면 EC2는 콘솔에서 인스턴스 유형과 AMI만 고르면 몇 분 안에 SSH 접속까지 가능한 서버가 생긴다. 실제로 명령줄로 하면 이렇게 한 줄이면 된다고 한다.
1
2
3
4
aws ec2 run-instances \
--image-id ami-0c02fb55956c7d316 \
--instance-type t2.micro \
--key-name my-key
몇 주짜리 프로세스가 명령어 한 줄로 줄어든 거다. 이 격차를 보고 나니 왜 다들 클라우드로 넘어가는지 체감이 됐다.
주의할 점도 하나 적어둔다. 실습 후 리소스를 삭제하지 않으면 계속 과금된다는 것. 생수 정기배송 해지를 깜빡한 것과 똑같은 상황이 벌어진다. AWS는 이런 실수를 막으려고 프리 티어(Free Tier)라는 걸 제공하는데, 일정 사용량까지는 무료지만 그 이상 쓰면 바로 과금이 시작된다고 하니 실습할 때 사용량 대시보드를 같이 챙겨봐야겠다.
배포 모델부터 정해야 한다
클라우드를 쓴다고 해서 다 똑같이 쓰는 게 아니었다. “이 자원을 누구랑 같이 쓸지, 어디까지 내가 통제할지”에 따라 세 가지로 나뉜다.
Private Cloud — 나 혼자 전용으로
리소스가 다른 조직과 절대 공유되지 않는 방식이다. 통제력이 제일 세지만 그만큼 비용도 크다. 은행처럼 보안 규제가 엄격한 곳이 이 방식을 많이 쓴다고 한다. 고객 금융정보를 규제상 외부와 공유할 수 없으니까.
Private Cloud를 실제로 구현하는 방법도 찾아봤는데, OpenStack이나 VMware 같은 소프트웨어로 사내 데이터센터에 클라우드 관리 계층을 직접 얹는 방식이 흔하다고 한다. 겉보기엔 클라우드처럼 온디맨드로 자원을 받을 수 있지만, 물리적으로는 여전히 우리 회사 건물 안에 있는 서버라는 게 핵심이다.
Public Cloud — 여러 조직이 나눠 쓰기
여러 사용자나 조직이 인터넷을 통해 같은 클라우드 사업자의 인프라를 나눠 쓰는 방식이다. AWS가 바로 이 방식이다. 통제력은 상대적으로 낮지만 비용이 저렴하고 확장성이 좋다. 나 같은 초보자나 스타트업이 시작하기엔 이쪽이 훨씬 접근하기 쉽다.
AWS, GCP(Google Cloud Platform), Azure(Microsoft) 셋이 흔히 3대 퍼블릭 클라우드로 묶이는데, 세 곳 다 같은 원리로 동작한다. 서비스 이름만 다를 뿐이지 “필요할 때 빌리고 쓴 만큼 낸다”는 본질은 똑같다. AWS는 EC2, GCP는 Compute Engine, Azure는 Virtual Machines 이런 식으로 이름만 다르게 붙어 있다고 한다.
Hybrid Cloud — 절충안
일부 서버는 사내에 두고 필요한 기능만 클라우드로 확장하는 방식이다. 중요한 데이터는 Private 인프라에서 제어하면서, Public Cloud의 유연성과 비용 효율성을 같이 가져가는 거다. 예를 들어 결제 정보 DB는 사내 서버에 두고 웹사이트나 API 서버는 EC2에 올리는 식이라고 한다. 실무에서는 순수 Private보다 이 조합이 훨씬 흔하다고 들었다.
AWS도 이 Hybrid 시나리오를 위한 전용 서비스를 따로 만들어뒀다는 게 흥미로웠다. AWS Outposts라는 서비스인데, AWS의 하드웨어와 소프트웨어를 아예 회사 데이터센터 안에 물리적으로 설치해주는 거다. 그러면 사내에 있으면서도 AWS 콘솔과 API로 관리할 수 있다고 한다. 규제 때문에 데이터를 국내나 사내에 둬야 하지만 관리 편의성은 클라우드처럼 누리고 싶은 회사들이 쓴다고.
셋을 비교하면 이렇다. Private은 통제력 최고·비용 최고·확장성 낮음, Public은 통제력 낮음·비용 최저·확장성 최고, Hybrid는 그 중간 어딘가. 면접 답변으로 정리하면 “Hybrid는 민감 데이터는 Private에, 트래픽 변동이 큰 서비스는 Public으로 분리해 확장성과 통제력을 동시에 잡는 전략”이라고 하면 될 것 같다.
클라우드다워지는 5가지 조건
배포 모델은 “어디서 쓰느냐”의 문제였고, 이번엔 “무엇을 갖춰야 클라우드라고 부를 수 있느냐”다. 미국 표준기술연구소(NIST)가 딱 5가지로 정의해뒀다고 한다.
- 주문형 셀프 서비스 — 사람 개입 없이 자동으로 리소스를 확보한다. 콘솔 클릭이나
aws ec2 run-instancesAPI 호출 하나로 끝난다. - 폭넓은 네트워크 접근 — 노트북이든 휴대폰이든 인터넷만 되면 어디서든 접속 가능하다.
- 멀티테넌시와 자원 공동관리 — 여러 고객이 같은 물리 서버를 쓰지만 논리적으로 완전히 분리된다.
- 빠른 탄력성과 확장성 — 트래픽이 늘면 자동으로 서버가 늘고, 줄면 자동으로 줄어든다.
- 측정된 서비스 — CPU 사용시간, 전송량 등을 정확히 측정해서 쓴 만큼만 청구한다.
이 중에서 제일 헷갈렸던 게 멀티테넌시(multi-tenancy)였다. 여러 고객이 물리적으로는 같은 서버에 있는데 어떻게 서로 데이터를 못 보게 막는 건지 궁금했는데, 알고 보니 VPC(Virtual Private Cloud)라는 서비스가 이 논리적 격리를 담당한다고 한다. VPC 안에서도 보안 그룹(Security Group)이라는 가상 방화벽으로 한 번 더 막아서, 물리적으로 같은 하드웨어 위에 있어도 논리적으로는 완전히 다른 네트워크처럼 동작하게 만든다. 이건 다음에 다룰 세 번째 자료(책 실습)의 3장에서 직접 만들어볼 예정이라 그때 더 자세히 정리해야겠다.
4번(빠른 탄력성과 확장성)도 좀 더 파봤는데, 실제 구현체는 Auto Scaling Group이라는 서비스라고 한다. CPU 사용률이 일정 기준을 넘으면 자동으로 서버를 몇 대 더 띄우고, 다시 낮아지면 그 서버들을 종료하는 방식이다. 사람이 새벽에 트래픽 그래프를 보면서 수동으로 서버를 늘렸다 줄였다 하지 않아도 된다는 게 핵심이다.
5번(측정된 서비스)도 그냥 “청구서에 찍힌다”는 정도로만 생각했는데, AWS Cost Explorer나 CloudWatch billing metric으로 실시간에 가깝게 지금까지 쓴 비용을 확인할 수 있다는 걸 알았다. 나중에 실습할 때 이거 켜두고 얼마나 나오는지 지켜봐야 할 것 같다.
5개 중 하나라도 빠지면 엄밀히는 클라우드가 아니라는 게 인상적이었다. 예를 들어 서버 신청서를 결재받아야 하는 사내 인프라 시스템은 1번(셀프서비스)이 없어서 클라우드라고 부르기 애매하다고. 아무리 가상 서버를 쓰고 있어도 사람이 중간에 승인해야 한다면 그건 이미 클라우드의 정의에서 벗어나는 셈이다.
회사가 실제로 얻는 6가지 이득
특징이 “기술적으로 뭘 갖췄나”였다면, 이번엔 “그래서 회사가 뭘 얻는가”다. 나중에 팀 프로젝트에서 인프라 선택을 설명할 일이 생기면 이 프레임을 그대로 쓸 수 있을 것 같아서 따로 정리해뒀다.
크게 두 그룹으로 나뉜다. 비용 구조를 바꾸는 쪽(①~③)과 속도·확장을 개선하는 쪽(④~⑥)이다.
| 번호 | 장점 | 내용 |
|---|---|---|
| ① | CAPEX → OPEX 전환 | 목돈 대신 매달 사용료 |
| ② | 규모의 경제 | AWS가 크게 사니까 단가가 낮아짐 |
| ③ | 용량 추정 불필요 | 서버 몇 대 살지 미리 안 정해도 됨 |
| ④ | 속도·민첩성 개선 | 아이디어를 결재 없이 바로 실험 |
| ⑤ | 데이터센터 유지관리 불필요 | 전기·냉각·보안 인력 부담 제거 |
| ⑥ | 몇 분만에 전 지역 확대 | 클릭 몇 번으로 다른 리전에 배포 |
①의 CAPEX(Capital Expenditure, 설비투자 같은 초기 목돈)를 OPEX(Operating Expenditure, 매달 나가는 운영비)로 바꾸는 게 사실 나머지 5개의 뿌리라는 걸 정리하면서 알게 됐다. 목돈이 안 드니까 실험(④)도 쉬워지고, 잘못 추정해도 손해가 크지 않으니 용량 추정 부담(③)도 사라지는 식으로 서로 연결돼 있었다.
②(규모의 경제)도 재밌었다. AWS는 전 세계 수십만 고객의 사용량을 다 합쳐서 서버·네트워크 장비를 어마어마한 규모로 구매한다. 개인이나 작은 회사가 서버 한 대 살 때보다 훨씬 싼 단가로 하드웨어를 확보할 수 있다는 거고, 그 절감분이 결국 사용자가 내는 요금이 낮아지는 방향으로 이어진다고 한다. 실제로 AWS는 서비스 출시 이후 여러 번 가격을 스스로 인하한 이력이 있다고 하는데, 규모가 커질수록 원가가 낮아지는 구조가 뒷받침하고 있어서 가능한 일이라는 설명이 이해가 됐다.
넷플릭스 사례도 찾아봤는데, 원래 자체 데이터센터를 운영하다가 2008년 데이터베이스 손상 사고를 겪은 뒤 몇 년에 걸쳐 AWS로 완전히 이전했다고 한다. 자체 데이터센터를 유지하는 부담(⑤)을 없애고, 전 세계 어디서든 몇 분 만에 새 리전에 서비스를 확장(⑥)할 수 있게 된 게 이전을 결정한 큰 이유 중 하나였다고.
“클라우드 왜 써요?”라는 질문에 “탄력적이라서요” 같은 기술 용어보다 “초기 투자비 90% 절감, 신규 서비스 출시까지 3개월에서 2주로 단축” 처럼 숫자로 답하는 게 이 6개 장점을 실전에서 써먹는 방법이라고 한다. 나도 다음에 발표할 일 있으면 이렇게 정리해서 말해봐야겠다.
오래된 문제들이 어떻게 풀렸나
이 부분은 새로운 내용이라기보다 앞에서 본 특징·장점을 “어떤 문제가 풀렸나”로 다시 본 슬라이드였다. 유연성, 비용 효율성, 확장성, 탄력성, 고가용성·내결함성, 민첩성 6가지인데 앞 두 섹션이랑 겹치는 게 많아서 표로 빠르게 정리만 해뒀다.
| 문제 | 온프레미스 시절 | 클라우드로 해결 |
|---|---|---|
| 유연성 | 리소스 타입 바꾸려면 재구매 | 필요에 따라 즉시 변경 |
| 비용 효율성 | 안 써도 감가상각 발생 | 쓴 만큼만 |
| 확장성 | 서버 추가에 몇 주 | 자동 확장 |
| 탄력성 | 스케일 인/아웃 수동 | 필요 시 자동 |
| 고가용성·내결함성 | 데이터센터 1곳이면 단일장애점 | 전 세계 분산 |
| 민첩성 | 실험 한 번에 결재·구매 필요 | 즉시 반복 가능 |
여기서 처음 나온 용어가 고가용성과 내결함성이었다. 둘이 비슷해 보이는데 사실 다르다고 한다. 고가용성(high-availability)은 “장애가 나도 사용자가 못 느끼게” 만드는 거고, 내결함성(fault-tolerance)은 “장애 자체가 서비스에 영향을 안 주게” 만드는 거다.
예를 들어보면 차이가 더 명확해진다. 웹 서버 하나가 죽었을 때 로드밸런서가 30초 안에 감지해서 다른 서버로 트래픽을 돌리면 그건 고가용성이다. 사용자는 잠깐이라도 지연을 느낄 수 있다. 반면 처음부터 요청 하나하나를 여러 서버가 동시에 처리하고 있어서 서버 하나가 죽어도 사용자가 아예 눈치채지 못한다면 그건 내결함성에 가깝다. AWS는 여러 가용영역(AZ)에 서버를 나눠서 이 둘을 다 확보하는데, 이건 뒤쪽 섹션에서 더 자세히 다룬다.
블랙프라이데이나 수강신청처럼 순간적으로 트래픽이 폭주하는 상황을 생각해보면 이 6가지가 왜 다 같이 필요한지 감이 온다. 확장성으로 서버를 늘리고, 탄력성으로 그걸 자동화하고, 고가용성으로 일부 서버가 죽어도 버티고, 그러면서도 비용 효율성 덕분에 트래픽이 빠지면 다시 비용이 줄어드는 거다. 하나만 있어서는 완성되지 않는 조합이라는 게 흥미로웠다.
어디까지 내가 관리할까 — IaaS, PaaS, SaaS
여기까지가 “클라우드가 뭔지”였다면, 이제 클라우드 안에서도 “내가 뭘 직접 관리하고 뭘 맡길지” 정하는 선택지를 봐야 한다. 나중에 EC2를 쓸지 더 편한 서비스를 쓸지 고르는 기준이 된다.
IaaS — 인프라만 빌리고 나머지는 내가
Amazon EC2가 대표적이다. 가상 서버만 빌리고 OS 설치, 미들웨어, 런타임, 애플리케이션까지 다 내가 관리한다. 자유도는 제일 높지만 그만큼 손이 많이 간다. GCP의 Compute Engine, Azure의 Virtual Machines도 같은 계열이다.
PaaS — 실행 환경까지 받고 앱만 올림
Elastic Beanstalk, Heroku 같은 서비스다. 코드만 배포하면 서버·OS·오토스케일링까지 알아서 관리해준다. 조직이 기본 인프라를 관리할 필요가 사라져서 애플리케이션 배포와 관리에만 집중할 수 있다고 한다. Google App Engine이나 Firebase도 비슷한 포지션이라고 들었다.
SaaS — 완제품을 그냥 씀
Gmail, Dropbox, Zoom처럼 설치·설정 없이 로그인만 하면 바로 쓸 수 있는 완제품이다. 서비스 공급자가 운영하고 관리하는 것까지 전부 끝나 있는 상태다.
셋의 차이를 스택으로 그려보면 이렇게 정리된다.
| 계층 | On-Premises | IaaS(EC2) | PaaS(Beanstalk) | SaaS(Gmail) |
|---|---|---|---|---|
| 애플리케이션 | 내가 | 내가 | 내가 | 제공자가 |
| 데이터 | 내가 | 내가 | 내가 | 제공자가 |
| 런타임 | 내가 | 내가 | 제공자가 | 제공자가 |
| 미들웨어 | 내가 | 내가 | 제공자가 | 제공자가 |
| OS | 내가 | 내가 | 제공자가 | 제공자가 |
| 가상화·서버·네트워킹 | 내가 | 제공자가 | 제공자가 | 제공자가 |
IaaS에서 PaaS, SaaS로 갈수록 아래층부터 위로 제공자가 관리하는 범위가 넓어진다. EC2(IaaS)는 OS 패치까지 내가 신경 써야 하지만 Beanstalk(PaaS)은 코드만 올리면 끝이라는 게 체감상 가장 큰 차이였다.
판단 기준을 나름대로 정리해보면, 커스터마이징이 중요하면 아래층(IaaS)으로, 속도가 중요하면 위층(PaaS·SaaS)으로 가면 된다. 특정 리눅스 커널 옵션을 건드려야 하는 서비스는 EC2를, 빠르게 웹앱만 배포하고 싶으면 Beanstalk을 쓰는 식이다. 다만 위층으로 갈수록 자유도는 줄어드는 트레이드오프가 있다는 것도 같이 기억해둬야겠다. PaaS가 지원하지 않는 특정 런타임 버전이나 미들웨어 설정이 필요하면 결국 IaaS로 내려와야 하는 경우도 있다고 한다.
AWS는 실제로 어디 있을까 — 글로벌 인프라 구조
지금까지는 “클라우드가 뭔지” 개념 이야기였는데, 이제부터는 그 클라우드가 실제로 어디에 어떤 단위로 존재하는지다. 서버가 눈에 안 보이니까 “내 서버가 지금 어디 있는지, 장애가 나면 어디까지 영향받는지” 감이 잘 안 잡혔는데 이 계층 구조를 보고 나서야 이해가 됐다.
AWS 인프라는 나라(리전) 안에 여러 동네(가용영역)가 있고, 동네마다 건물(데이터센터)이 있는 구조다. 그리고 리전 밖에도 배달이 빠르도록 곳곳에 캐시 거점(엣지 로케이션)을 세워뒀다.
1
2
3
4
5
6
7
8
리전(Region) — 서울(ap-northeast-2)
├─ 가용영역(AZ) — ap-northeast-2a
│ └─ 데이터센터 1개 이상
├─ 가용영역(AZ) — ap-northeast-2b
└─ 가용영역(AZ) — ap-northeast-2c
리전 밖: 엣지 로케이션 (전 세계 42개국 84개 도시, 400개+)
└─ Wavelength (통신사 5G망 내부)
Wavelength는 특이했는데, 아예 통신사의 5G 기지국 옆에 미니 인프라를 붙여놓은 거라고 한다. 그래서 5G폰에서 요청하면 정말 코앞에서 바로 응답이 온다. 자율주행차나 실시간 AR 게임처럼 몇 밀리초 차이가 중요한 서비스를 위한 서비스라고 하는데, 이건 이번 자료에서는 이름만 나오고 자세히는 안 다뤄서 나중에 따로 찾아봐야 할 것 같다.
찾아보다가 Local Zones라는 개념도 같이 알게 됐다. 리전에서 지리적으로 멀리 떨어진 대도시에 컴퓨팅·스토리지 자원 일부를 미리 배치해두는 서비스라고 하는데, 미디어·게임처럼 지연시간에 민감한 서비스가 리전까지 가지 않고 가까운 Local Zone에서 처리하게 해준다고 한다. 엣지 로케이션은 캐싱 전용이고 Local Zones는 실제 컴퓨팅이 가능하다는 게 둘의 차이라고 하니, 나중에 이 부분도 정리해봐야겠다.
이 계층 구조를 알아야 하는 진짜 이유는 장애 격리 범위를 예측하기 위해서라고 한다. 리전 하나가 통째로 죽는 경우는 거의 없지만, 가용영역 하나가 정전으로 죽는 일은 실제로 종종 일어난다고. 그래서 서비스를 설계할 때 “이 리소스가 리전 단위인지 AZ 단위인지”를 항상 확인해야 한다는 말이 와닿았다.
리전 이름 읽는 법
리전 코드가 ap-northeast-2처럼 생겼는데, 처음엔 그냥 랜덤한 문자열인 줄 알았다. 알고 보니 지역-방향-번호 3단 구조였다.
1
2
3
4
5
ap-northeast-2
│ │ │
지역 방향 번호
(Asia (북동쪽) (같은 방향 내 순번)
Pacific)
ap는 Asia Pacific, northeast는 그 안에서 북동쪽, 마지막 숫자는 같은 방향에 여러 리전이 있을 때 구분하는 번호다. 도쿄가 1번(ap-northeast-1)이라서 서울은 2번(ap-northeast-2)이 됐다고.
| 코드 | 이름 |
|---|---|
| us-east-1 | US East (N. Virginia) |
| us-west-2 | US West (Oregon) |
| eu-west-1 | EU (Ireland) |
| eu-central-1 | EU (Frankfurt) |
| ap-northeast-1 | Asia Pacific (Tokyo) |
| ap-northeast-2 | Asia Pacific (Seoul) |
| ap-southeast-1 | Asia Pacific (Singapore) |
여기서 실무자가 자주 겪는다는 삽질 얘기가 재밌었다. 서울 리전에서 EC2를 만들어놓고 콘솔 오른쪽 위가 도쿄 리전으로 바뀐 채 들어가면 방금 만든 인스턴스가 목록에서 안 보인다고 한다. 삭제된 게 아니라 그냥 다른 리전을 보고 있어서 그런 거다.
이걸 구분하는 기준이 “리전 종속 서비스 vs 글로벌 서비스”인데, EC2·VPC·RDS는 리전마다 완전히 별개로 존재하지만 IAM이나 Route53은 리전 개념 자체가 없는 전역 서비스라 어느 리전에서 봐도 똑같이 보인다고 한다. AWS CLI를 쓸 때도 이 리전 설정을 신경 써야 하는데, aws configure로 기본 리전을 지정해두거나 명령어마다 --region ap-northeast-2 옵션을 붙여야 한다고 한다. 나도 실습 편 쓸 때 이거 조심해야겠다.
가용영역 — 서버 하나만 두면 안 되는 이유
가용영역이 리전 안에서 전기·통신망이 완전히 따로 도는 독립 구역이라는 건 위에서 봤는데, 이번엔 왜 “최소 2개 이상 쓰라”고 그렇게 강조하는지를 봤다.
핵심 문장은 이거였다. AWS의 고가용성 설계는 리전 단위가 아니라 가용영역(AZ) 단위로 이뤄진다. 처음엔 리전이 이미 완전히 독립된 지역이라고 했으니 그걸로 충분한 줄 알았는데, 그게 아니었다.
1
2
3
4
5
6
7
서울 리전 (ap-northeast-2)
├─ AZ-A: 전력망·냉각시스템 독립
├─ AZ-B: 전력망·냉각시스템 독립 ← 여기서 장애 나도
└─ AZ-C: 전력망·냉각시스템 독립 A/C는 멀쩡
서버를 A에만 두면: 장애 시 서비스 전체 중단
서버를 A+C에 나눠두면: A 장애 시 C가 트래픽 이어받음
전력 장애, 네트워크 장애, 하드웨어 결함은 리전 안 특정 구역에서 언제든 일어날 수 있다는 걸 전제로 설계한다는 게 인상 깊었다. 그래서 로드밸런서가 장애 난 AZ를 자동으로 감지하고 나머지 AZ로만 트래픽을 넘긴다고 한다.
이 원칙이 실제로 어디에 적용되는지도 찾아봤다. RDS(관계형 데이터베이스 서비스)를 만들 때 “Multi-AZ 배포”라는 옵션을 켜면, 기본 DB(Primary)와 똑같은 복제본(Standby)을 다른 가용영역에 자동으로 하나 더 만들어준다고 한다. 기본 DB가 있는 AZ에 장애가 나면 자동으로 Standby가 Primary 역할을 넘겨받아서, 애플리케이션 쪽에서는 DB 엔드포인트 주소가 그대로인 채로 장애 조치가 끝난다고. 이런 식으로 “가용영역 최소 2개” 원칙이 EC2뿐 아니라 데이터베이스 설계까지 관통하는 기본 전제라는 걸 알게 됐다.
주의할 점도 하나 있었다. AWS 계정마다 ap-northeast-2a가 실제로 가리키는 물리적 위치가 다를 수 있다고. AWS가 특정 AZ에 트래픽이 몰리는 걸 막으려고 계정별로 매핑을 무작위로 섞어두기 때문이라고 한다. 그래서 AZ 이름 자체보다 “AZ를 분산해서 쓴다”는 구조적 사고가 더 중요하다고. 세 번째 자료(책 실습)에서 서브넷을 2개 가용영역(2a, 2c)에 나눠 만드는 이유가 바로 이거였구나 싶었다.
엣지 로케이션 — 편의점처럼 가까운 곳에
마지막은 리전 밖에서 속도를 챙기는 장치다. 서울 리전 서버에 저장된 이미지를 브라질 사용자가 요청하면 지구 반 바퀴를 돌아와야 해서 느릴 수밖에 없는데, 이걸 해결하는 게 엣지 로케이션이다.
전 세계 84개 도시에 캐시 거점을 두고, 자주 찾는 콘텐츠를 미리 복사해둔다. 동네 편의점에 인기 상품을 미리 갖다놓는 것과 비슷한 원리라고 생각하니 이해가 쉬웠다.
1
2
3
4
사용자 요청
→ 가장 가까운 엣지 로케이션
├─ 캐시 히트: 저장된 콘텐츠 있음 → 즉시 응답 (수 ms)
└─ 캐시 미스: 없음 → 원본 리전까지 요청 → 받아서 캐싱 후 응답
이 구조를 실제로 담당하는 서비스가 CloudFront라는 CDN(콘텐츠 전송 네트워크)이다. S3에 원본 이미지를 저장해두고 CloudFront를 앞에 붙이면, 첫 사용자가 요청할 때만 원본 리전까지 갔다 오고(캐시 미스) 그 이후 같은 지역 사용자들은 전부 엣지 로케이션에서 바로 받아간다(캐시 히트). Regional Edge Cache라고 해서, 자주 안 쓰이는 콘텐츠는 엣지보다 한 단계 위의 더 큰 캐시 계층에 보관해뒀다가 필요할 때 꺼내주는 중간 단계도 있다고 한다.
여기서 꼭 기억해야 할 게, 엣지 로케이션에는 EC2나 RDS 같은 컴퓨팅 자원이 없다는 점이다. 오직 캐싱 전용 계층이라서 “CloudFront에 서버를 올릴 수 있나요?” 같은 질문 자체가 성립하지 않는다고 한다. CloudFront는 애플리케이션을 실행하는 공간이 아니라 콘텐츠 전송을 최적화하는 계층일 뿐이다.
넷플릭스 같은 서비스가 전 세계 어디서든 끊김 없이 재생되는 게 이 엣지 로케이션 구조 덕분이라고 하니, 평소에 아무 생각 없이 쓰던 서비스들이 다시 보였다. 캐시 히트율이 높을수록 원본 리전으로 가는 트래픽이 줄어드니까, 서비스 운영 비용을 아끼는 데도 직접적으로 도움이 된다고 한다.
마무리
10개 소단원을 한 번에 정리하다 보니 생각보다 시간이 오래 걸렸는데, 그만큼 개념 하나하나가 뒤에 나오는 실습이랑 다 연결돼 있다는 걸 느꼈다. 특히 가용영역 최소 2개 원칙이랑 IaaS/PaaS 책임분담 이 두 개가 나중에 VPC 실습에서 계속 튀어나올 것 같은 예감이다.
CAPEX에서 OPEX로 바뀌는 구조, 리전-가용영역-엣지 로케이션의 계층, IaaS/PaaS/SaaS의 책임 분담. 이 세 가지만 확실히 잡고 가면 이후에 나오는 EC2나 VPC 같은 개별 서비스들이 왜 그렇게 설계됐는지 훨씬 잘 이해될 것 같다.
다음 편은 같은 자료의 3장, EC2다. AMI가 뭔지, 스팟 인스턴스가 왜 90% 싸다는 건지 정리해볼 예정이다.