AWS 입문자가 가장 먼저 알아야 할 3티어 아키텍처
실제 사례로 이해하는 AWS 아키텍처 설계의 기초
실제 사례로 이해하는 AWS 아키텍처 설계의 기초들어가며
AWS를 처음 접하면 가장 먼저 드는 생각이 있습니다.
“서비스가 너무 많은데, 대체 뭐부터 알아야 하지?”
EC2, S3, RDS, Lambda, VPC… 이름만 들어도 벌써 부담스럽습니다. AWS 공식 문서를 펼치자마자 덮어버린 경험이 있다면, 그건 당신의 문제가 아닙니다. AWS가 워낙 방대하기 때문입니다.
하지만 다행히도 실제 웹 서비스를 만드는 데 필요한 핵심 개념은 생각보다 단순합니다.
그리고 정답처럼 사용하는 웹 서비스 아키텍처가 있습니다. 이런 정답 처럼 사용하는 아키텍처를 구축할때 사용하는 핵심 서비스는 손에 꼽을 정도입니다.
이 글에서는 “쇼핑몰 사장이 되어 AWS로 서비스를 운영해보는 이야기”를 통해 AWS 아키텍처의 기본이 되는 3티어 아키텍처를 한 장의 그림으로 이해하는 것을 목표로 합니다.
왜 서버를 나눠야 하는지?
AWS에서는 각 역할을 어떤 서비스가 맡는지?
로드 밸런서와 오토 스케일링은 왜 필요한지?
이론 설명보다는 실제 상황에서 어떤 문제가 생기고, 그것을 AWS로 어떻게 해결하는지에 집중해 설명하겠습니다.
AWS 입문자라면 이 글을 통해 “아, AWS 아키텍처의 큰 그림은 이거구나” 라는 감각을 얻어가실 수 있을 것입니다.
1. 왜 3티어 아키텍처인가?
하나의 서버에 모든 것을 설치하면 생기는 문제
쇼핑몰을 만들어서 세상을 바꾸고 싶은 한 개발자가 있습니다. 인프라 지식이 부족한 이 개발자는 일단 서버를 구매하고 운영체제와 서버 프로그램을 설치하면 된다고 생각했습니다. 처음에는 테스트 삼아 집에 남는 컴퓨터를 서버로 사용하기로 했죠.
이 컴퓨터에 쇼핑몰 사이트를 만들었습니다. 서버로 사용할 컴퓨터에는 이미 웹 서버, 애플리케이션 서버, 데이터베이스 서버 기능을 하는 프로그램들을 설치했습니다. 그리고 쇼핑몰 애플리케이션을 배포했죠.
웹 서버, 애플리케이션 서버, 데이터베이스 서버란?
웹 서버(Web Server): HTML, CSS, 자바스크립트, 이미지, 동영상 등을 저장하고, 사용자 요청 시 그대로 전송하는 용도의 서버입니다. 보통 아파치(Apache)나 엔진엑스(Nginx)를 많이 사용합니다.
애플리케이션 서버(Application Server): 개발자가 만든 애플리케이션을 설치하는 서버입니다. 사용자가 쇼핑몰에서 구매 요청을 하면 애플리케이션 서버가 이를 처리하고, 데이터베이스 서버에 구매 관련 데이터를 기록하거나 불러옵니다. 자바의 경우 톰캣(Tomcat)이, 파이썬의 경우 Gunicorn이 주로 사용됩니다.
데이터베이스 서버(Database Server): 데이터를 저장 및 관리하는 서버입니다. 오늘날에는 일반적으로 관계형 데이터베이스가 사용되며, 대표적인 관계형 데이터베이스로는 MySQL, MariaDB, Oracle, PostgreSQL, MSSQL 등이 있습니다.
하나의 서버에서 발생하는 문제들
처음에는 쇼핑몰이 잘 될지 안 될지 모르니 테스트 겸 집에서 인터넷을 연결해서 운영했습니다. 그런데 어느 날 갑자기 쇼핑몰이 열리지 않았습니다. 사용자 수가 많지 않았음에도 서버가 트래픽을 감당하지 못해 장애가 발생한 것이었습니다.
사실 서버 장애는 다양한 원인으로 발생할 수 있습니다. 이번 경우는 명확히 성능 문제였기 때문에 서버를 증설해야 한다는 결론에 이르렀습니다. 하지만 어떤 방식으로 증설할 것인지에 대해서는 고민이 필요했습니다.
지금은 하나의 물리적인 서버가 웹 서버, 애플리케이션 서버, 데이터베이스 서버의 역할을 모두 맡다 보니 성능의 한계로 장애가 발생한 것입니다. 게다가 여러 프로그램이 하나의 장비에 함께 있다 보니 장애가 발생했을 때 어떤 프로그램이 문제를 일으켰는지 파악하기도 쉽지 않았습니다.
TIP: 이런 이유로 데이터베이스 서버는 별도로 분리해 운영하는 편이 더 나을 것 같습니다. 그리고 웹 서버와 애플리케이션 서버는 기존처럼 한 장비에서 함께 운영합니다.
계층을 분리해야 하는 이유
결론적으로 웹 + 애플리케이션 서버용 장비 두 대와 데이터베이스 서버용 장비 한 대로 구성해야 할 듯합니다. 추가 서버를 구매하는 데 드는 비용 부담이 크지만, 미래를 위해 투자해보기로 하고 다음과 같은 구조로 만들 계획입니다.
2. AWS에서 각 계층은 어떤 서비스로 구성되나?
서버를 직접 구매해서 운영하려면 먼저 서버로 사용할 컴퓨터를 마련하고, 전원을 공급하고, 네트워크도 연결하는 등 모든 것을 스스로 해야 합니다. 비용도 많이 들고, 무엇보다 관리하기가 쉽지 않습니다.
하지만 AWS에서는 서버를 빌려서 사용할 수 있습니다. 그것도 몇 번의 클릭만으로 바로 실행 가능한 형태로 제공됩니다. 이 같은 방식으로 제공되는 가상 서버가 바로 EC2(Elastic Compute Cloud)입니다.
EC2 - 서버 역할을 하는 서비스
EC2는 AWS에서 가상 서버(인스턴스)를 제공하는 컴퓨팅 서비스입니다. 한마디로, AWS에서 "서버 하나 주세요"라고 하면 바로 받을 수 있는 서버가 EC2입니다.
앞서 서버를 직접 구매했던 경우를 생각해 보겠습니다. 업체에 구매 요청을 하고, 서버가 배달될 때까지 1주일, 서버를 설정하는 데 1주일이 걸렸습니다. 일반적인 회사에서는 이 같은 과정에 더 오랜 시간이 걸립니다. 실제로 아마존도 초창기에는 서버를 구매해서 사용할 수 있는 상태가 되기까지 최소 3주 정도 걸렸다고 합니다.
하지만 클라우드를 사용하면 어떨까요? 인터넷을 통해 앞에서 살펴본 AWS 관리 콘솔에 접속해 인스턴스 유형과 운영체제를 선택하고 인스턴스 시작 버튼을 클릭하면 3~5분 후에 사용 가능한 인스턴스가 뚝딱 만들어집니다. 얼마나 빠르고 쉬운가요?
"클라우드를 사용하는 가장 큰 이유 중 하나는 비즈니스의 민첩성을 높일 수 있다는 것입니다. 서버를 사용하려면 최소 3주가 걸리는 시간을 3~5분 만에 가능하게 한 것입니다."
RDS - 데이터베이스 역할을 하는 서비스
데이터베이스 서버를 직접 구축하려면 컴퓨터를 준비하고, 운영체제와 데이터베이스를 설치하고, 스토리지를 구성하고, 백업·복구 전략을 세우고, 패치·보안 업데이트까지 모두 스스로 챙겨야 합니다. 비용도 많이 들고, 무엇보다 관리하기가 쉽지 않습니다.
하지만 AWS에서는 데이터베이스를 빌려서 사용할 수 있습니다. 그것도 몇 번의 클릭만으로 바로 실행 가능한 형태로 데이터베이스가 제공됩니다. 이 같은 방식으로 제공되는 관리형 데이터베이스가 바로 RDS(Relational Database Service)입니다.
RDS는 AWS에서 관계형 데이터베이스(인스턴스)를 제공하는 완전관리형 데이터베이스 서비스로서, 데이터베이스 설치부터 운영까지 AWS에서 전부 담당하고 개발자는 그냥 데이터베이스에 연결해서 쓰기만 하면 됩니다.
3티어 아키텍처의 AWS 서비스 매핑
3. 로드 밸런서는 왜 필요한가?
그런데 위 그림처럼 아키텍처를 구성하려고 했더니 새로운 문제가 생겼습니다. 웹 + 애플리케이션 서버가 두 대가 되면 각 서버의 IP 주소가 각각 다르기 때문에 쇼핑몰 도메인을 어디에 연결해야 할지 결정해야 합니다. 그리고 사용자의 트래픽을 두 대의 서버에 분산해야 하므로 트래픽을 분산해줄 장비가 필요합니다.
그래서 웹 + 애플리케이션 서버 앞에 트래픽(또는 부하)을 분산하는 로드 밸런서(Load Balancer; LB)를 설치하고, 쇼핑몰 도메인 주소를 로드 밸런서로 연결하면 될 것 같습니다.
AWS의 로드 밸런서: ELB
AWS에서 이러한 로드 밸런서의 역할을 하는 서비스의 정식 명칭은 ELB(Elastic Load Balancing)입니다. AWS에서 제공하는 로드 밸런서는 여러 종류가 있는데, 인터넷을 통해 HTTPS 프로토콜로 서비스를 제공하는 쇼핑몰을 운영하고 있기 때문에 HTTP와 HTTPS 트래픽을 분산 처리할 수 있는 ALB(Application Load Balancer)를 사용할 것입니다.
로드 밸런서의 트래픽 분산 원리
로드 밸런서가 트래픽을 분산하는 흐름은 다음과 같습니다.
1. 사용자가 쇼핑몰 도메인(예: luckyvanilla.com)에 접속합니다.
2. 도메인은 로드 밸런서로 연결되어 있습니다.
3. 로드 밸런서가 트래픽을 여러 EC2 인스턴스에 분산합니다.
4. 각 EC2 인스턴스가 사용자 요청을 처리합니다.
4. 오토 스케일링으로 자동 확장하기
실전 사례: 트래픽 폭주 상황
이제 준비가 다 됐으니 다시 쇼핑몰을 운영하면서 돈만 쓸어 담으면 될 것 같습니다. 다행히도 온라인 광고 효과로 쇼핑몰이 잘 되고 있습니다. 서버를 증설하니 더 많은 트래픽도 문제없이 처리됩니다.
그런데 어느 날 유명 연예인이 판매하는 상품을 방송에서 입고 나왔습니다. 다음 날 트래픽이 폭주했고, 결국 서버에서 장애가 발생했습니다. 성능 좋은 서버였지만 두 대로는 폭주하는 트래픽을 감당하지 못해 전체 시스템에 장애가 발생했습니다. 이런 행운은 자주 오는 일이 아닌데 서버의 성능 문제로 기회를 놓치고 말았습니다.
다시 고민을 해봅니다. 서버를 몇 대 더 늘려야 할까? 전혀 예상이 되지 않습니다. 서버 한 대 가격도 만만치 않아서 매우 부담이 됩니다.
오토 스케일링이란?
이 문제를 해결하기 위해 오토 스케일링을 사용합니다. 오토 스케일링은 트래픽에 맞춰 인스턴스를 자동으로 생성하고 삭제하는 역할을 합니다. 이것이 AWS를 사용하는 가장 큰 이유 중 하나입니다.
오토 스케일링을 사용하려면 어떤 기준으로 인스턴스를 자동으로 생성하고 삭제할지를 정해야 합니다. 인스턴스의 평균 CPU 사용률이나 네트워크의 입출력에 따라 기준을 정할 수 있습니다. 오토 스케일링의 기준이 되는 대상 값을 지정하면 대상 값에 맞춰 오토 스케일링이 인스턴스를 생성하고 삭제하게 됩니다.
"마치 에어컨에 온도를 설정해두면 에어컨이 자동으로 그 온도를 맞춰 주는 것과 같습니다."
AMI(이미지)의 역할
오토 스케일링을 사용하려면 시작 템플릿(Launch Template)이 필요합니다. 그리고 시작 템플릿을 만들려면 AMI(Amazon Machine Image)가 필요합니다.
AMI는 흔히 '이미지'라고도 합니다. 쉽게 말해, AWS에서 인스턴스에 운영체제를 빠르게 설치할 수 있도록 미리 만들어 놓은 운영체제 환경의 템플릿이라고 생각하면 됩니다. AMI에는 운영체제뿐만 아니라 필요한 경우 애플리케이션, 설정 값, 패키지 등이 포함될 수 있어 EC2 인스턴스를 빠르고 일관되게 만들 수 있는 기반이 됩니다.
TIP: 인스턴스에 Nginx만 설치했지만 일반적으로 다양한 애플리케이션을 설치하고 설정을 하게 됩니다. 이러한 작업을 인스턴스를 만들 때마다 반복하려면 번거로울 것이므로 한 번 설정해 놓고 인스턴스의 AMI를 만들어 재사용하는 것이 일반적입니다.
5. 이 아키텍처의 비용은 얼마나 들까?
AWS를 처음 시작하는 분들이 가장 궁금해하는 부분이 바로 비용입니다. 이 아키텍처를 구성했을 때 대략적인 월 비용을 살펴보겠습니다.
예상 월 비용 (개략 안내)
프리 티어 활용법
AWS를 처음 사용하는 분들은 AWS 프리 티어(Free Tier)를 활용할 수 있습니다. 계정 생성 후 12개월 동안 EC2 t2.micro나 t3.micro 인스턴스 750시간, RDS db.t2.micro 750시간 등을 무료로 사용할 수 있습니다.
[중요] 실습 후 리소스 삭제
실습을 직접 따라 하며 AWS 사용법을 배우게 되므로 당연히 비용이 발생합니다. 따라서 각 실습마다 리소스를 만들고 지우는 방법도 함께 설명하므로 실습이 끝나면 리소스를 꼭 지우길 바랍니다.
TIP: AWS는 정말 자주 업데이트됩니다. 실습 화면을 캡처한 그림이 많은데, 업데이트로 인해 변경된 부분이 있더라도 설명을 잘 참고해서 따라 하길 바랍니다.
핵심 정리
AWS의 핵심은 EC2(서버) + ELB(분산) + RDS(DB) + Auto Scaling(자동 확장)입니다. 이 4가지만 이해하면 대부분의 웹 서비스 아키텍처를 설계할 수 있습니다.
마무리
이 글에서 소개한 아키텍처를 스토리와 함께 직접 구축해보고 싶다면, 《따라 하면서 완성하는 AWS 인프라 구축 입문》에서 쇼핑몰 사장이 되어 AWS를 배워보세요. 책에서는 이 아키텍처를 한 단계씩 직접 손으로 만들어볼 수 있습니다.
https://wikibook.co.kr/lucky-aws/
