웹 계층이 꼭 필요한 이유
- Web 계층 없이 External ALB에서 직접 Application 계층으로 연결하는 것도 기술적으로는 가능하지만, 다음과 같은 이유로 Web 계층을 포함하는 것이 권장된다.
사용자 인터페이스 처리
- Web 계층은 GUI, 웹사이트 등 사용자와의 상호작용을 담당
- HTML, CSS, JavaScript와 같은 정적 컨텐츠를 처리
아키텍처 분리
- 각 계층이 명확한 역할을 가지며 모듈화된 구조 제공
- 프레젠테이션 로직과 비즈니스 로직의 분리
- 각 계층별 독립적인 수정과 유지보수 가능
성능과 확장성
- 프레젠테이션 계층에서 요청을 캐싱하여 네트워크 사용 최소화
- 각 계층별로 독립적인 수평 확장 가능
- 로드 밸런싱이 더 효과적으로 수행됨
정적 컨텐츠는 CloudFront 와 S3 로 처리하고, REST API 서버만 애플리케이션 계층에서 처리한다면?
- REST API 서버만 있는 경우, Web 계층이 꼭 필요하진 않다.
권장 아키텍처
프론트엔드 (정적 컨텐츠)
- S3: 정적 파일 호스팅 (HTML, CSS, JS 등)
- CloudFront: CDN 서비스로 정적 컨텐츠 전달1
백엔드 (API 계층)
- External ALB: 프라이빗 서브넷의 API 서버로 요청 라우팅
- Private 서브넷의 API 서버: REST API 처리2
장점
비용 효율성
- 불필요한 Web 계층 제거로 인프라 비용 절감
S3와 CloudFront를 통한 효율적인 정적 컨텐츠 제공
- 간단한 아키텍처
- 아키텍처 복잡도 감소
- 관리 포인트 감소
- 장애 발생 가능성 감소
보안
- API 서버가 프라이빗 서브넷에 위치하여 보안성 확보
- CloudFront를 통한 보안 기능 활용 가능
REST API의 3-tier 구조
- REST API는 아래와 같은 3개의 계층으로 구성된다.
Routing Layer (Presentation Layer)
- HTTP 요청을 적절한 서비스 핸들러로 라우팅
- 요청/응답 처리를 위한 미들웨어 포함
- ALB가 이 역할을 수행할 수 있음
Service Layer (Business Logic Layer)
- 핵심 애플리케이션 로직 처리
- 유효성 검사 및 비즈니스 규칙 적용
- API 엔드포인트의 실제 처리 로직 구현
Data Access Layer
- 데이터베이스와의 직접적인 상호작용
- CRUD 작업 수행
- ORM/ODM 사용 (예: Mongoose)
이러한 구조는 REST API의 주요 원칙인 클라이언트-서버 분리, 무상태성, 계층화 시스템을 잘 준수하면서도 효율적인 아키텍처를 제공한다.
애플리케이션 계층의 스프링부트 애플리케이션이 html, css, js 와 같은 정적 컨텐츠들을 같이 처리하는 구조
- External ALB가 직접 프라이빗 서브넷의 스프링부트 애플리케이션으로 트래픽을 라우팅하는 구조도 가능하며, 보안적인 측면에서도 충분히 안전할 수 있다. 그 이유는 아래와 같다.
보안적 측면
ALB의 보안 기능
- ALB가 첫 번째 방어 계층 역할 수행
- 보안 그룹을 통한 트래픽 제어
- SSL/TLS 종료 처리 가능
- WAF(Web Application Firewall) 연동 가능
프라이빗 서브넷 보호
- 애플리케이션 서버가 직접 인터넷에 노출되지 않음
- ALB만이 애플리케이션 서버와 통신 가능
- 보안 그룹을 통한 ALB-애플리케이션 서버 간 통신 제한
구현 방식
- 트래픽 흐름
- Internet → ALB(Public Subnet) → 스프링부트(Private Subnet)
- 정적 파일은 스프링부트에서 직접 처리
- 필요시 정적 컨텐츠는 CDN으로 분리 가능
따라서 Apache와 같은 별도의 웹 서버 계층이 없어도 보안성을 충분히 확보할 수 있다.