클라우드라는 집 짓기(2)
재료를 조합하여 '웹사이트' 만들기
안녕하세요.
지난 화에 이어 클라우드의 재료를 조합해서 웹사이트를 만드는 방법을 계속 이야기해 보겠습니다.
"블랙프라이데이 자정. 접속자 100명에서 10,000명으로 급증. 서버 다운까지 남은 시간: 3분."
2015년, 한 패션 쇼핑몰에서 있었던 상황입니다.
준비한 세일이 SNS를 타고 퍼지면서 순식간에 폭주가 시작됐죠. 결과는? 서버 다운, 3시간 동안 사이트 마비, 추정 매출 손실 2억 원.
하지만 2020년 같은 회사는 같은 상황에서 서버를 자동으로 50배 확장하며 무사히 버텨냈습니다. 무엇이 달라졌을까요?
바로 클라우드 인프라의 '조합법'을 제대로 이해한 것입니다.
지난 화에서 우리는 서버, 스토리지, 네트워크라는 '재료' 각각의 특징을 살펴보았습니다. 이제 이 재료들을 어떻게 조합해야 실제로 작동하는 '웹사이트'가 만들어지는지, 그 실전 조합법을 알아보겠습니다.
1. 설계도 그리기: 웹사이트의 세 가지 핵심 공간
현대의 웹사이트는 보통 3-Tier 아키텍처라 불리는 세 가지 핵심 공간으로 나뉩니다.
우리 집에 비유하자면, 손님을 맞는 '현관', 실제 일을 처리하는 '작업실', 그리고 중요한 물건을 보관하는 '서고'입니다.
웹 서버 (Web Server): 현관
방문자가 처음 마주하는 공간입니다. 웹 서버는 방문자의 요청을 가장 먼저 받아 안내하는 역할을 합니다. HTML, CSS, JavaScript 같은 정적 파일을 바로 전달하거나, 복잡한 요청은 뒤쪽의 앱 서버로 전달합니다.
가장 널리 쓰이는 웹 서버 소프트웨어로는 Nginx와 Apache HTTP Server가 있습니다. Nginx는 특히 동시 접속자가 많을 때 메모리를 적게 사용해 효율적이라 최근 더 선호되는 추세입니다.
앱 서버 (Application Server): 작업실
실제 비즈니스 로직이 실행되는 공간입니다. 로그인 처리, 상품 검색, 장바구니 계산, 결제 처리 등 복잡한 연산과 판단이 여기서 이루어집니다.
웹 서버가 "고객님이 로그인 요청하셨습니다"라고 전달하면, 앱 서버가 "아이디와 비밀번호를 확인하고, 맞으면 세션을 만들어 드리겠습니다"라고 실제 처리를 하는 것이죠.
개발 언어에 따라 다양한 솔루션이 사용됩니다.
Java 기반이면 Tomcat이나 JBoss, Python이면 uWSGI나 Gunicorn, JavaScript라면 Node.js 등입니다.
웹 서버와 앱 서버는 왜 분리할까?
초보자들이 가장 궁금해하는 부분입니다. 사실 작은 서비스는 하나로 합쳐도 됩니다. 하지만 트래픽이 늘어나면 분리해야 하는 이유가 생깁니다.
웹 서버는 단순히 파일을 전달하는 일을 빠르게 많이 처리하는 데 특화되어 있습니다.
반면 앱 서버는 복잡한 계산을 정확하게 처리하는 데 특화되어 있죠.
각자 잘하는 일을 맡기면 전체 효율이 올라갑니다. 또한 앱 서버만 여러 대로 늘려서 확장할 수도 있고, 보안상 앱 서버를 외부에 노출시키지 않을 수도 있습니다.
데이터베이스 (Database): 서고
회원 정보, 상품 목록, 주문 내역 등 소중한 데이터를 보관하는 공간입니다. 관계형 데이터베이스인 MySQL, PostgreSQL, Oracle 등이 전통적으로 많이 사용되며, 최근에는 대량의 비정형 데이터를 다루는 MongoDB 같은 NoSQL 데이터베이스도 함께 쓰입니다.
2. 손님이 몰려도 끄떡없는 현관 만들기 (로드 밸런싱과 오토스케일링)
만약 우리 집 현관문이 하나뿐이라면, 손님이 한꺼번에 몰려들 때 집이 마비될 겁니다. 클라우드는 이 문제를 두 가지 방법으로 해결합니다.
로드 밸런서: 똑똑한 교통정리원
먼저, 현관문(서버)을 여러 개 만듭니다. 그리고 그 앞에 로드 밸런서(Load Balancer)라는 '교통정리원'을 둡니다.
로드 밸런서는 들어오는 손님들을 실시간으로 모니터링하면서 가장 한가한 서버로 안내합니다.
어떤 서버가 응답하지 않으면 자동으로 제외시키고, 다시 살아나면 다시 투입합니다.
방문자는 이 모든 과정을 전혀 눈치채지 못합니다.
대표적인 클라우드 로드 밸런서로는 AWS의 ELB(Elastic Load Balancer), Azure의 Load Balancer, GCP의 Cloud Load Balancing이 있습니다.
오토스케일링: 자동으로 늘었다 줄었다
여기서 한 단계 더 나아가, 오토스케일링(Auto Scaling)이라는 마법을 부릴 수 있습니다.
CPU 사용률이 70%를 넘으면 서버를 자동으로 추가하고, 30% 이하로 떨어지면 자동으로 줄이는 규칙을 설정하는 것이죠.
손님이 갑자기 100배로 몰려들면 클라우드가 알아서 서버를 수십 대로 늘려주고, 손님이 빠져나가면 다시 원래대로 줄여줍니다.
AWS의 Auto Scaling Group, Azure의 VM Scale Sets, GCP의 Managed Instance Groups가 이 역할을 합니다.
실제 사례를 볼까요? 한 게임 회사는 평소 서버 20대로 운영하다가 신규 업데이트 날에는 자동으로 200대까지 늘어나도록 설정했습니다. 만약 200대를 항상 유지했다면 월 3,000만 원의 비용이 들었겠지만, 오토스케일링 덕분에 실제로는 월 500만 원만 지불했습니다.
3. 소중한 정보를 안전하게 보관하는 서고 (데이터베이스 조합법)
데이터베이스라는 '서고'를 만드는 방법은 크게 두 가지입니다.
직접 책장 짜기 (IaaS 방식)
강력한 서버(인스턴스)를 빌려서, 그 위에 MySQL이나 PostgreSQL 같은 데이터베이스 소프트웨어를 직접 설치하고 운영하는 방식입니다.
모든 것을 내 마음대로 제어할 수 있습니다. 특수한 설정이나 플러그인을 자유롭게 사용할 수 있죠.
하지만 백업, 보안 패치, 장애 대응, 성능 튜닝 등 모든 관리 책임을 내가 져야 합니다. 데이터베이스 전문가가 있는 큰 기업들이 주로 선택하는 방식입니다.
책장 세트 빌리기 (PaaS 방식)
AWS의 RDS, Azure SQL Database, GCP의 Cloud SQL과 같은 '관리형 데이터베이스 서비스'를 이용하는 방식입니다.
우리는 어떤 종류의 데이터베이스(MySQL, PostgreSQL, Oracle 등)를 쓸지만 고르면, 백업, 보안 패치, 고가용성 구성, 모니터링 등 귀찮은 관리는 모두 클라우드 제공업체가 알아서 해줍니다.
비용은 IaaS보다 20~30% 정도 더 들지만, 관리 인력이 필요 없다는 점을 고려하면 대부분의 기업에게 더 저렴합니다. 실제로 스타트업의 90% 이상이 관리형 데이터베이스를 선택합니다.
고가용성: 서고가 무너져도 데이터는 안전하게
관리형 데이터베이스의 가장 큰 장점은 자동 이중화입니다. 마스터 데이터베이스가 죽으면 자동으로 복제본(슬레이브)이 마스터로 승격되어 서비스가 계속됩니다. 전환 시간은 보통 30초~2분 정도로, 사용자는 거의 눈치채지 못합니다.
AWS RDS의 Multi-AZ 배포를 예로 들면, 서울 리전의 서로 다른 가용 영역에 데이터베이스를 복제해 둡니다. 한쪽 데이터센터에 문제가 생겨도 다른 쪽이 즉시 인계받는 것이죠.
4. 사진과 영상은 별도의 창고에 (스토리지와 CDN 조합법)
웹사이트의 수많은 이미지나 동영상 파일을 현관(웹 서버)에 쌓아두는 것은 비효율적입니다. 현관이 좁아져 손님 응대 속도가 느려지기 때문이죠.
오브젝트 스토리지: 무한 창고
클라우드에서는 이런 파일들을 오브젝트 스토리지(AWS S3, Azure Blob Storage, GCP Cloud Storage)라는 '외부 임대 창고'에 보관합니다.
이 창고는 거의 무한히 넓고, 1GB당 월 2~3센트로 매우 저렴하며, 99.999999999%(일레븐 나인)의 내구성을 보장합니다. 쉽게 말해 파일 100억 개를 저장하면 1,000년에 하나 정도만 손실될 확률이라는 뜻입니다.
CDN: 전 세계 곳곳의 전진 기지
여기서 한 걸음 더 나아갑니다. CDN(Content Delivery Network)을 사용하는 것이죠.
서울에 있는 서버에서 미국 사용자에게 이미지를 전송하려면 물리적 거리 때문에 1~2초가 걸립니다.
CDN은 전 세계 주요 도시에 캐시 서버를 두고, 한 번 전송된 파일을 각 지역에 복사해 둡니다. 그래서 미국 사용자는 미국에 있는 캐시 서버에서 0.1초 만에 이미지를 받을 수 있습니다.
대표적인 CDN으로는 AWS CloudFront, Azure CDN, Cloudflare CDN, Akamai 등이 있습니다.
글로벌 서비스를 운영한다면 CDN은 선택이 아닌 필수입니다.
한 이커머스 업체는 CDN 도입 후 해외 사용자의 페이지 로딩 속도가 3초에서 0.5초로 개선되었고, 이로 인해 구매 전환율이 40% 증가했습니다.
5. 우리 집의 주소와 울타리 (네트워크와 보안 조합법)
이제 이 모든 공간들을 VPC(가상 사설 클라우드)라는 '우리 집 울타리' 안에 안전하게 배치합니다.
VPC: 논리적으로 격리된 우리만의 공간
VPC는 퍼블릭 클라우드 안에서 우리 회사만 사용하는 독립된 네트워크 공간입니다. IP 주소 범위도 우리가 정하고, 서브넷(작은 네트워크 구역)도 우리가 나눕니다.
퍼블릭 서브넷과 프라이빗 서브넷
VPC 안에서 공간을 다시 두 가지로 나눕니다.
- 퍼블릭 서브넷: 외부 인터넷과 직접 통신할 수 있는 공간입니다. 로드 밸런서나 웹 서버처럼 외부 손님을 맞이해야 하는 것들을 여기 배치합니다.
- 프라이빗 서브넷: 외부와 직접 통신할 수 없는 안쪽 공간입니다. 앱 서버, 데이터베이스처럼 중요한 자원들을 여기 숨겨 외부의 직접적인 접근을 막습니다.
보안 그룹: 각 방마다 다른 출입 규칙
각 서버마다 보안 그룹(Security Group)이라는 방화벽 규칙을 설정할 수 있습니다.
예를 들어:
- 로드 밸런서: 전 세계 누구나 80번 포트(HTTP), 443번 포트(HTTPS)로 접근 가능
- 웹 서버: 로드 밸런서에서만 접근 가능
- 앱 서버: 웹 서버에서만 접근 가능
- 데이터베이스: 앱 서버에서만 3306번 포트(MySQL)로 접근 가능
이렇게 계층적으로 접근을 제한하면, 설령 웹 서버가 해킹당해도 데이터베이스까지 뚫리는 것을 막을 수 있습니다. 이것이 바로 심층 방어(Defense in Depth) 전략입니다.
실제 아키텍처 다이어그램
이 모든 것을 그림으로 그리면 이렇습니다:
클라우드 웹사이트 아키텍처 예시마무리: 조합의 기술이 곧 클라우드 설계
이처럼 클라우드 인프라 설계는 단순히 부품을 나열하는 것이 아닙니다. 각 재료의 특성을 이해하고, 비즈니스 요구사항에 맞게 유기적으로 '조합'하는 과정입니다.
같은 웹사이트라도:
- 소규모 블로그라면 단순하게 구성하고
- 중규모 쇼핑몰이라면 오토스케일링과 CDN을 더하고
- 대규모 글로벌 서비스라면 멀티 리전, 데이터 복제, 장애 조치까지 고려해야 합니다
이 조합을 통해 우리는 비로소 안정적이고, 확장 가능하며, 비용 효율적인 시스템이라는 집을 지을 수 있습니다.
그런데 집을 다 지었다고 끝이 아닙니다. 이제 이 집을 24시간 안전하고 효율적으로 관리해야 합니다.
다음 화에서는 클라우드 인프라를 모니터링하고, 문제를 미리 감지하며, 자동으로 대응하는 '운영 시스템'에 대해 알아보겠습니다.