AWS 3Tier 아키텍처란
3-tier 아키텍처는 웹 애플리케이션을 3개의 논리적 및 물리적 계층으로 분할하는 가장 널리 사용되는 아키텍처 패턴입니다.
계층 구성
1. Presentation Tier
- 사용자가 직접 접근하는 인터페이스 계층
- HTML, JavaScript, CSS 등으로 구성
- 데스크톱 애플리케이션, 모바일 앱, 웹페이지, IoT 장치 등 다양한 형식 지원
2. Login(Application) Tier
- 비즈니스 로직이 실행되는 계층
- 데이터 처리 및 비즈니스 규칙 적용
3. Data Tier
- 데이터 저장 및 관리를 담당
- MySQL, PostgreSQL 등의 데이터베이스 시스템 사용
- 데이터의 CRUD 작업 처리
주요 이점
- 각 계층을 독립적으로 업데이트하고 확장 가능
- 개발 팀별로 전문 분야에 집중 가능
- 관심사의 분리를 통해 비즈니스 로직 변경이 프레젠테이션 계층에 영향을 주지 않음
AWS 주요 구성 요소 및 동작 방식
출처: https://potato-yong.tistory.com/73?category=845362
네트워크 구성요소
- VPC: 가상 네트워크 환경 구성
- IGW: VPC와 인터넷 간 통신을 담당
- NAT: 프라이빗 서브넷의 인스턴스들이 인터넷과 통신할 수 있도록 지원
- Bastion Host: 프라이빗 서브넷으로 SSH 접근을 위한 징검다리 서버
로드밸런서
- EX-ALB: 외부 로드밸런서로 클라이언트의 요청을 WEB 서버로 분산
- IN-ALB: 내부 로드밸런서로 WEB 서버의 요청을 WAS 서버로 분산
동작 방식
1)클라이언트가 서비스에 접속하면 IGW를 통해 요청이 VPC로 전달된다.
2)EX-ALB가 요청을 수신하여 가용한 WEB 서버로 트래픽을 분산한다.
3)WEB 서버는 필요한 비즈니스 로직 처리를 위해 IN-ELB를 통해 WAS 서버로 요청을 전달한다.
4)WAS 서버는 데이터 처리가 필요한 경우 Private 서브넷의 데이터베이스와 통신한다.
5)처리된 결과는 역순으로 클라이언트에게 전달된다.
이러한 3-tier 아키텍처는 확장성, 유지보수성, 보안성을 고려한 엔터프라이즈급 애플리케이션 개발에 적합한 구조를 제공합니다.
웹 계층의 필요성
Web 계층 없이 External ALB에서 직접 Application 계층으로 연결하는 것도 기술적으로는 가능하지만, 아래와 같은 이유로 Web 계층을 포함하는 것이 권장됩니다.
사용자 인터페이스 처리
- Web 계층은 GUI, 웹사이트 등 사용자와의 상호작용을 담당
- HTML, CSS, JavaScript와 같은 정적 컨텐츠를 처리
아키텍처 분리
- 각 계층이 명확한 역할을 가지며 모듈화된 구조 제공
- 프레젠테이션 로직과 비즈니스 로직의 분리
- 각 계층별 독립적인 수정과 유지보수 가능
성능과 확장성
- 프레젠테이션 계층에서 요청을 캐싱하여 네트워크 사용 최소화
- 각 계층별로 독립적인 수평 확장 가능
- 로드 밸런싱이 더 효과적으로 수행됨
실습 포스팅
- https://dodomp0114.tistory.com/8
- https://insoobaik.tistory.com/231
- https://velog.io/@lijahong/0부터-시작하는-AWS-공부-3-Tier-구축-1편-구축-계획-VPC-Bastion-Host
- https://potato-yong.tistory.com/73?category=845362
- https://potato-yong.tistory.com/79
- https://growth-coder.tistory.com/180
3Tier 아키텍처의 다양한 구성 패턴
1) 정적 컨텐츠는 CloudFront 와 S3 로 처리하고, REST API 서버만 애플리케이션 계층에서 처리
REST API 서버만 있는 경우, Web 계층이 꼭 필요하진 않습니다.
권장 아키텍처
프론트엔드 (정적 컨텐츠)
- S3: 정적 파일 호스팅 (HTML, CSS, JS 등)
- CloudFront: CDN 서비스로 정적 컨텐츠 전달1
백엔드 (API 계층)
- EX-ALB: 프라이빗 서브넷의 API 서버로 요청 라우팅
- 프라이빗 서브넷의 API 서버: REST API 처리
장점
비용 효율성
- 불필요한 Web 계층 제거로 인프라 비용 절감
S3와 CloudFront를 통한 효율적인 정적 컨텐츠 제공
- 간단한 아키텍처
- 아키텍처 복잡도 감소
- 관리 포인트 감소
- 장애 발생 가능성 감소
보안
- API 서버가 프라이빗 서브넷에 위치하여 보안성 확보
- ALB만이 애플리케이션 서버와 통신 가능
- 애플리케이션 서버는 직접 인터넷에 노출되지 않음
- CloudFront를 통한 보안 기능 활용 가능
- ALB를 통한 보안 기능 활용 가능
- 보안 그룹을 통한 ALB-애플리케이션 서버 트래픽 제어
- SSL/TLS 종료 처리 가능
- WAF(Web Application Firewall) 연동 가능
이러한 구조는 REST API의 주요 원칙인 클라이언트-서버 분리, 무상태성, 계층화 시스템을 잘 준수하면서도 효율적인 아키텍처를 제공합니다.
추가적으로 애플리케이션 계층(스프링 부트)에서 직접 html, css, js 와 같은 정적 컨텐츠들을 같이 처리하는 구조도 가능합니다. 아래 이미지와 같이 EX-ALB가 직접 프라이빗 서브넷의 스프링부트 애플리케이션으로 정적 리소스 요청을 라우팅하게 됩니다.
사내 네트워크망에서 프라이빗 서브넷에 존재하는 RDS 에 직접 접근할 수 있는 이유는?
- 프라이빗 서브넷에 존재하는 RDS 의 경우엔 외부에서의 직접 접근이 불가능하다.
- 현재 사내 네트워크망에서 개발자들이 직접 dv, st 환경 RDS 에 접근 가능한 상태이다.
- DevOps팀에 문의해본결과
AWS Site-to-Site VPN서비스를 사용하면 IPSec 암호화 프로토콜을 사용하여 사내 온디맨드 네트워크망과 VPC Cloud 환경을 연결해준 상태라고 한다.- 간단하게 설명하면 아래 이미지와 같이 AWS에는 VGW(Virtual Private Gateway)가 있고 On-Premise에는 CGW(Customer Gateway)가 붙어있으며 이 둘 사이에 IPSec 프로토콜을 이용해 터널링을 만들어줘서 인터넷을 통한 상호 간 통신이 가능하게끔 해주는 원리다.
- VGW는 AWS Cloud VPC의 라우터라고 생각하면 된다. 하나의 VGW는 여러 On-Premise와 연결이 가능하지만 VGW 하나당 복수개의 VPC를 연결할 수 없다.
- CGW는 On-Premise의 라우터 값을 AWS에 제공해주는 서비스다. CGW는 AWS에서 구성되는 가상 게이트웨이이며 이를 위해 On-Premise 쪽에 별도의 VPN 장비를 준비해야 한다. 모든 준비가 완료되면, AWS 쪽에서 VPN 라우팅을 위한 구성 파일을 다운로드하여 On-Premise 쪽의 VPN 장비에 설치를 해줘야 비로소 통신이 연결된다.
- 자세한 내용은 여기를 참고바란다.
https://bosungtea9416.tistory.com/entry/AWS-Site-to-Site-VPN-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0