각종 시스템을 다루다 보면, “왜 이렇게 구성했을까”를 다시 짚어보고 싶어질 때가 있습니다.
이번 글에서는 웹 서비스를 설계할 때 가장 기본이 되는 3계층 아키텍처를 시작으로, VM과 컨테이너 비교, 분산·확장 시스템 설계 시 고려 요소, 그리고 로드밸런서(ALB vs NLB)까지 제가 공부하면서 정리한 내용을 공유해봅니다. AWS 환경을 예로 들어 설명하면 이해가 더 잘 되는 것 같아서, 실제 AWS 서비스와 엮어서 정리해봤습니다.
3계층 아키텍처란? 웹 아키텍처 기초 정리
1. 3계층 아키텍처(3-Tier Architecture)란?
3계층 아키텍처, 흔히 3티어 아키텍처라고도 부르는 이 구조는 애플리케이션을 세 개의 논리적 계층으로 나누는 설계 방식입니다. 참고로 “계층(Layer)”과 “티어(Tier)”를 같은 의미로 혼용해서 쓰는 경우가 많은데, 엄밀히는 티어는 각 계층이 별도의 물리적 인프라에서 실행되는 경우를 가리키고, 계층은 소프트웨어 상의 기능적 구분을 의미합니다. 다만 실무에서는 두 용어를 크게 구분하지 않고 섞어 쓰는 경우가 대부분이라고 생각합니다.
3계층은 각각 다음과 같이 구성됩니다.
- Presentation Tier (프레젠테이션 계층 / 프론트엔드)
: 사용자에게 보여지는 UI 영역.
– Nginx 같은 웹서버가 여기 해당하며 HTML, CSS, JavaScript로 구성됩니다. - Application Tier (애플리케이션 계층 / 백엔드)
: 프론트엔드의 요청을 처리하는 비즈니스 로직 계층.
– 실제 요청을 처리하는 핵심 영역입니다. - Data Tier (데이터 계층)
: 데이터베이스 서버나 파일 시스템으로 구성되어 안정적인 데이터 관리를 담당합니다.
왜 3계층으로 나누는가?
| 장점 | 설명 |
|---|---|
| 보안 | 계층이 물리적으로 분리되어 있어 방화벽/DMZ로 보안 강화 가능 |
| 확장성 | 병목이 생긴 계층만 선택적으로 증설 가능 (예: 웹서버만 리소스 부족 시 그 부분만 스케일업) |
| 유지보수성 | 논리적으로 분리된 모듈이라 관리와 개선이 쉬움 |
| 개발 속도 | 계층별 전문 개발팀이 동시에 작업 가능, 업그레이드도 해당 계층만 교체하면 됨 |
3계층 아키텍처는 사실 수십 년간 클라이언트-서버 애플리케이션에서 가장 보편적으로 쓰여온 구조라고 합니다. 지금도 대부분의 웹 서비스가 기본 골격으로 삼고 있는 표준적인 설계 방식입니다.
AWS 서비스로 옮겨보면 이렇게 매핑됩니다
3계층 아키텍처를 AWS 서비스로 옮겨보면 감이 더 잘 옵니다.
- Presentation Tier: CloudFront(CDN) + S3(정적 리소스) 혹은 ALB 뒤의 EC2/Nginx
- Application Tier: EC2, ECS/Fargate, Elastic Beanstalk 등에서 실행되는 백엔드 애플리케이션
- Data Tier: RDS, DynamoDB, ElastiCache 등
각 계층을 서로 다른 서브넷(퍼블릭/프라이빗)에 배치하고 보안 그룹으로 접근을 제어하는 것이 AWS에서 3계층 구조를 구현하는 전형적인 방식입니다.
Data Tier는 보통 프라이빗 서브넷에 두고, Presentation Tier에서만 접근 가능하게 라우팅 테이블과 보안 그룹을 좁혀두는 식이죠.
Nginx의 역할도 함께 짚어보면, Nginx는 경량 웹서버로서 정적 파일을 응답하는 역할뿐 아니라, 리버스 프록시로서 뒤에 있는 WAS(애플리케이션 서버)의 부하를 줄이는 로드밸런서 역할까지 할 수 있습니다. 외부에는 Nginx만 노출시키고 실제 서버는 내부망에 숨길 수 있어 보안 측면에서도 유리합니다.
2. VM과 컨테이너 차이
3계층 구조가 애플리케이션을 “논리적으로” 나누는 방식이라면,
이번엔 그 계층들이 실제로 “어떤 인프라 위에서” 돌아가는지를 살펴볼 차례입니다.
핵심은 “자원 공유의 수준” 차이입니다.
VM (Virtual Machine)
- 물리적 컴퓨터(Baremetal) 위에 하이퍼바이저가 자원을 가상화
- 각 VM은 서로의 존재를 모르고, 커널을 포함한 OS가 독립적으로 실행됨
- 장점: 물리 컴퓨터와 기능 차이가 없어 다양한 작업이 가능
- 단점: 각자 OS를 가지고 있어서 무거움
컨테이너
- 소프트웨어 코드와 실행에 필요한 컴포넌트를 표준화된 방식으로 패키징
- 컨테이너 엔진만 있으면 어디서든 실행 가능
- HostOS 위에 컨테이너 엔진이 있고, 개별 컨테이너는 그 엔진으로 서비스를 수행
핵심 차이점
컨테이너는 하나의 OS를 공유하는 반면, VM은 각각의 OS를 띄워야 합니다.
이 때문에 컨테이너가 상대적으로 가볍고, 이미지 카피나 부팅 시간이 짧아 scale in/out이 VM 대비 훨씬 빠릅니다.
다만 트레이드오프도 있습니다. VM은 하나에 보안 이슈가 생겨도 다른 VM에 영향을 주지 않지만, 컨테이너는 OS를 공유하기 때문에 커널 취약점 하나가 여러 컨테이너에 영향을 줄 수 있습니다.
AWS에서 이 개념이 어떻게 서비스로 나뉘어 있는지
AWS는 이 VM-컨테이너 스펙트럼을 아래처럼 서비스로 잘게 쪼개놓았습니다.
- EC2: VM 그 자체. OS 레벨까지 사용자가 직접 관리 (IaaS)
- ECS / EKS: 컨테이너 오케스트레이션 서비스. 컨테이너를 어떤 EC2(혹은 Fargate)에 배치할지 관리해줌
- Fargate: ECS/EKS 위에서 서버(EC2 인스턴스) 자체를 신경 쓸 필요 없이 컨테이너만 올리면 되는 서버리스 컨테이너 실행 환경 (PaaS에 가까움)
- Lambda: 컨테이너보다 한 단계 더 추상화된 서버리스 함수 실행 환경
즉 “직접 관리할 범위”를 기준으로 EC2 → ECS on EC2 → Fargate → Lambda 순으로 점점 인프라 관리 부담이 줄어드는 구조라고 이해하면 편합니다.
요즘은 VM과 컨테이너를 상호보완적으로 씁니다. 하드웨어를 VM(EC2)으로 가상화한 뒤, 그 위에 컨테이너 환경을 얹는 아키텍처가 널리 쓰이고 있죠. 앞서 살펴본 3계층 구조의 각 계층도 결국 이 EC2/컨테이너 중 어떤 형태로 배치할지를 선택하게 됩니다.
3. 분산 및 확장 가능한 시스템 설계 시 고려 요소
3계층 구조로 시스템을 나눴다면, 이제 트래픽이 늘어날 때 이 구조를 어떻게 확장할지가 다음 문제입니다. 분산 시스템은 하나의 대형 컴퓨터가 처리하던 업무를 여러 지역에 분산시켜 동시다발적으로 처리하는 방식이고, 확장 가능한 시스템은 늘어나는 요청에 서비스를 복제해 대응하는 방식입니다. 이 둘을 설계할 때 고려해야 할 6가지 요소를 정리해봤습니다.
- 가용성(Availability)
: 서비스가 몇 분만 멈춰도 큰 손실로 이어질 수 있습니다. 중요 컴포넌트의 이중화, 빠른 복구 방법, 일부 장애가 나도 전면 중단은 막는 graceful degradation 설계가 필요합니다. AWS라면 여러 가용영역(AZ)에 인스턴스를 분산 배치하는 Multi-AZ 구성이 대표적입니다. - 성능(Performance)
: 빠른 응답 시간과 낮은 레이턴시는 사용자 만족도뿐 아니라 검색엔진 랭킹에도 영향을 줍니다. CloudFront 같은 CDN을 붙여 물리적 거리로 인한 지연을 줄이는 것도 이 맥락입니다. - 신뢰성(Reliability)
: 같은 요청에는 항상 같은 결과를 반환해야 하고, 데이터가 갱신되면 항상 최신 데이터를 조회할 수 있어야 합니다. - 확장성(Scalability)
: 더 많은 트래픽, 더 많은 저장 공간, 더 많은 트랜잭션을 얼마나 쉽게 처리할 수 있는지가 핵심입니다. AWS의 Auto Scaling Group이 트래픽에 따라 EC2 대수를 자동으로 늘리고 줄이는 게 이 요소를 해결하기 위한 기능입니다. - 관리성(Manageability)
: 문제 발생 시 분석과 이해가 쉬워야 하고, 운용(업데이트·수정)이 수월해야 합니다. CloudWatch로 로그와 지표를 한곳에서 모으는 것도 관리성을 높이는 방법입니다. - 비용(Cost)
: 하드웨어·소프트웨어 비용뿐 아니라 빌드 시간, 운용 노력, 교육 비용까지 포함한 총소유비용(TCO) 관점에서 고려해야 합니다.
4. 로드밸런서(Load Balancer) 정리
앞서 3계층 중 Presentation Tier와 Application Tier 사이, 혹은 Application Tier 내부에서 여러 대의 서버로 트래픽을 나눠주는 역할을 하는 것이 바로 로드밸런서입니다.
개념
클라이언트와 서버 풀 사이에 위치해서, 한 서버에 부하가 집중되지 않도록 트래픽을 분산시켜주는 장치/기술입니다.
계층별 분류
| 종류 | 기준 |
|---|---|
| L2 | MAC 주소 기반 분산 |
| L3 | IP 주소 기반 분산 |
| L4 | Transport 계층(IP + 포트 번호) 기반 분산 |
| L7 | Application 계층(URL, HTTP 헤더) 기반 분산 |
분산 알고리즘
- 라운드로빈: 서버 성능이 동일하고 처리 시간이 짧을 때, 순서대로 요청을 할당
- 가중 라운드로빈: 서버마다 처리 용량이 다를 때, 가중치를 부여해 정수값으로 처리 용량을 조정
- 최소 연결 방식: 현재 연결 수가 가장 적은 서버로 동적으로 분산
- IP Hash 방식: 클라이언트 IP를 해싱해서 항상 같은 서버로 연결되도록 보장 (세션 유지가 필요할 때 유용)
- 최소 리스폰타임 방식: 응답시간이 가장 짧은 서버에 우선적으로 트래픽 배분
ALB vs NLB
| 구분 | ALB (L7) | NLB (L4) |
|---|---|---|
| 계층 | Application | Transport |
| IP | 유동적 | 고정 IP |
| SSL | 적용 가능 (L7이라 지원) | 없음 |
| 라우팅 기준 | URL, HTTP 헤더 | IP + 포트 |
| 대표 사용처 | 일반적인 웹 애플리케이션, 마이크로서비스 라우팅 | 초저지연이 필요한 게임 서버, TCP 기반 서비스, 고정 IP가 필요한 경우 |
정리하면 “세밀한 라우팅과 SSL 종료가 필요하면 ALB, 고정 IP와 초저지연이 필요하면 NLB” 로 기억하면 됩니다. 참고로 실제 AWS 콘솔에서 로드밸런서를 만들 때도 이 두 가지(+Gateway Load Balancer)를 선택하게 되어 있어서, 개념만 알아두면 콘솔에서 헤매지 않을 수 있습니다.
마무리
3계층 아키텍처를 기본 골격으로 놓고, 그 위에 VM/컨테이너로 어떻게 배치할지, 트래픽이 늘어날 때 어떤 요소를 고려해 확장할지, 그리고 그 확장을 로드밸런서가 어떻게 뒷받침하는지까지 이어서 정리해봤습니다.
답글 남기기