Please enable JavaScript.
Coggle requires JavaScript to display documents.
CloudFront + ALB 조합의 인프라 구성 - Coggle Diagram
CloudFront + ALB
조합의 인프라 구성
ALB (Application Load Balancer)
ALB란?
AWS에서 제공하는
로드 밸런서
중 하나.
OSI 7 Layer의 7번째 계층인 Application 계층에서 동작하며, 트래픽을 자동으로 분산시켜 애플리케이션의 가용성과 확장성(Scalability)를 향상시킨다
보안
AWS Web Application Firewall(WAF) 연동
AWS WAF와 연동함으로써 SQL injection, XSS등 웹 애플리케이션의 공격 방어 가능
WAF: aws의 애플리케이션 방화벽 서비스
SSL 인증서 탑재 가능
SSL Offloading(SSL Termination) 지원
클라이언트의 HTTPS 요청을 로드밸런서에서 decrypt => 백엔드에는 HTTP로 전달
EC2 인스턴스의 부담을 줄이기 위해 ALB가 대신 SSL 인증서를 이용한 암호화 통신을 실시
(백엔드 서버 부담 감소)
특징
HTTP 를 활용한 라우팅(부하 분산)
TCP 를 기반으로 하는 HTTP / HTTPS / Websocket 등을 활용
HTTP Header, Host Header, 요청 메서드 등에 기준을 적용하고, 적절한 대상 그룹으로 라우팅
다수의 타겟 그룹에 라우팅 및
가중치 설정
가능 - 라우팅 규칙 설정으로 가중치(우선순위) 부여
Cross-Zone Load Balancing(교차 영역 로드밸런싱)을 통해 Availability Zone의 모든 타겟 그룹에 트래픽을 고르게 분산 가능
Availability Zone(AZ): AWS region 내에서 독립적으로 운영되는 데이터 센터 그룹을 의미
Proxy Server로서의 역할
보안적 이점: 클라이언트는 ALB까지만 접속 가능하고, 실제 EC2 인스턴스의 IP가 외부로 노출되지 않음
동작: 사용자 요청 -> ALB -> EC2 인스턴스(response)
7계층 프록시 역할을 수행, 클라이언트와 백엔드 간의 직접적인 연결을 차단하고 보안 강화
라우팅 알고리즘
Round Robin (RR)
: 트래픽을 순차적으로 순환하며 대상 그룹 내의 서버들에 트래픽 균등 분배 (default)
간단하고 공정한 분배 방식. 모든 서버(EC2 인스턴스)가 동등한 트래픽을 처리할 수 있다고 가정, 동일한 비중의 요청을 분배하여 효율젹으로 로드 밸런싱
BUT 성능 상의 문제 발생 가능성.
일부 서버에 할당된 요청 처리가 오래 걸리거나 더 많은 리소스를 소비할 경우, 작업을 끝마치지 못한 상황에서 지속적으로 새로운 요청이 유입되어 균형이 깨질 가능성
Least Outstanding Requests (LOR)
: 미처리 요청이 가장 적은(여유가 가장 많은) 대상에 우선적으로 요청
대상 간에 부하가 고르게 분배됨
RR의 성능 문제에 대한 해결 방안이 될 수 있음
한계
Latency 및 성능 제한
OSI 7계층에서 동작하므로, 패킥 해석 및 처리에 추가적인 오버헤드 발생 가능성
NLB(Network Load Balancer)와 비교했을 경우 latency 증가와 성증 저하 발생할 여지 있음. 고성능이 요구될 경우 NLB가 이점이 더 많음
갑작스러운 트래픽 증가(스파이크 트래픽)에 대한 대응의 한계 있음
보안 설정의 복잡성
기본적으로 DDos에 대한 보안을 제공하지 않음. 기본적으로 AWS Shield Standard가 자동 적용되지만, DDos에 대한 방어가 필요한 환경에서는 AWA Shield Advanced 고려 필요
HTTP / HTTPS 트래픽을 처리하므로 웹 관련 공격에 노출될 가능성 있음
AWS WAF 연동을 통한 보안성 강화 필요
유지보수 용이성 저하:
설정과 관리가 복잡해지므로 초기에는 설정에 많은 시간이 소요될 수 있고, 이후에도 트래픽 패턴이나 새로운 보안 위협에 따라 규칙을 업데이트하는 등의 지속적인 관리가 필요. 또한, 많은 규칙을 적용할 경우 성능 저하나 비용 증가가 발생할 수 있기 때문에, 이를 적절히 관리하는 노력이 필요
추가적인 비용 발생 가능성: 트래픽에 따라 비용 변동
제한된 할당량
AWS 계정에는 리전별로 적용되는 ALB에 대한 기본 할당량이 존재.
할당량 증가 요청이 가능하지만, 일부는 늘릴 수 없는 제한 있음.
따라서, 대규모 트래픽을 처리해야 하는 경우 주의 필요.
CloudFront
CloudFront란?
AWS의 CDN 서비스.
콘텐츠를 캐싱하고, 해당 콘텐츠를 제공하는데 최적화 된 네트워크를 제공.
요청이 발생하면 가까운 Edge Location에서 빠르게 캐싱된 콘텐츠를 전달.
캐싱된 데이터가 없을 경우 Origin Server로 요청을 보내 데이터를 획득하고 해당 데이터를 캐싱한다.
CDN (Content Delivery Network)
: 클라이언트의 요청으로 서버에서 받아온 콘텐츠를 캐싱하고, 이후 요청 시 캐싱된 데이터를 제공하는 서비스.
물리적 거리가 먼 곳에서도 빠른 요청 처리가 가능하며, 결과적으로 서버의 부하를 감소시킨다.
특징
HTTPS 지원
Origin이 HTTPS를 지원하지 않아도, HTTPS를 사용하여 사용자와 CloudFront 간의 통신을 암호화 할 수 있다. 사용자와 CloudFront 간의 통신은 HTTPS, 이후 Orign까지는 HTTP 프로토콜로 통신하는 개념
사용자 - CloudFront: HTTPS
CloudFront - Origin Server: HTTP
HINT 2 충족
Edge Server의 캐싱
기본적으로 한번 발생한 요청에 대해서 캐싱 정보 저장.
기본 TTL은 24시간이지만, 사용자 설정에 따른 변경이 가능.
BUT, 전체 데이터에 대한 TTL 수정이 아니라, 개별 데이터에 대한 invalidation API로 삭제가 가능하다.
제공하는 콘텐츠 종류
정적 웹 콘텐츠: HTML, CSS, JS, 이미지 파일 등
동적 웹 콘텐츠: CloudFront에서 캐싱할 수 없는 콘텐츠로, 사용자 요청에 따라 실시간으로 생성되는 동적 페이지나 API 응답을 포함
비디오 콘텐츠: HLS 또는 DASH와 같은 스트리밍 프로토콜을 이용한 비디오 콘텐츠 제공
HLS: HTTP Live Streaming
DASH: Dynamic Adaptive Streaming over HTTP)
소프트웨어 다운로드: 애플리케이션, 패치 파일 등 대용량 파일의 빠른 제공
특징적 기능
지리적 제한 기능
: 특정 region에서 콘텐츠를 차단하거나, 특정 지역에서만 콘텐츠 접근을 허용하는 지리적 제한 기능 제공
Signed URL 기능: 허용된 사용자에게만 접근을 허가하는 URL 제공 기능 (하나의 콘텐츠에만 사용 가능)
Signed Cookie 기능
키워드
Edge Location
: AWS가 실질적으로 제공하는 전 세계 주요도시에 분포한 데이터 센터
Edge Server
: 엣지 로케이션 내의 서버
Origin Server
: 원본 데이터가 있는 서버. 보통 AWS 에서는 S3, EC2 인스턴스
Regional Edge Cache (REC)
: 오리진과 엣지 로케이션 중간 지점에서 데이터를 캐싱하고 저장. 엣지 로케이션보다 큰 캐시 스토리지 용량을 제공하며, 캐시가 더 오랫동안 유지됨
Origin에 대한 요청 횟수를 줄여 CloudFront의 성능을 최적화
캐시 미스(cache miss)를 줄이고 콘텐츠 제공 속도 및 효율 최적화
Cache Miss ↔️ Cache Hit
한계
비용 발생
데이터 전송량과 요청 수에 따른 요금을 부과하는 방식으로, 트래픽이 많은 경우 상당한 비용 발생 가능성이 있음
캐싱 무효화 비용 발생: 콘텐츠 변경 시, 인위적인 invalidation으로 인해 비용이 증가할 수 있음
제한된 커스터마이징
기본적인 캐싱 및 콘텐츠 전달 기능을 제공하지만, 특정한 요구사항에 맞춘 세부적 설정이나 기능 구현에는 제한이 있을 수 있음
가파른 러닝 커브
CloudFront의 다향한 기능과 설정 옵션을 사용하기 위해서는 AWS의 전반적인 이해와 학습이 필요하다
데이터 전송 과정
사용자(Client) -> Edge Server -> (REC) -> Origin Server
1) 엣지 서버로의 요청 발생
2) 요청이 발생한 데이터에 대한 캐싱 여부 확인
3) 캐싱 정보가 없을 경우 오리진 서버로 요청 전달
4)오리진 서버에서 데이터를 획득하여 엣지 서버에 캐싱 데이터 생성 후, 클라이언트로 응답 발생
CloudFront + ALB
강점
정적 및 동적 콘텐츠 통합 최적화
: CloudFront에서 정적 리소스 캐싱,
ALB에서 동적 요청 처리
백엔드 부하 감소 및 비용 절감
: CloudFront가 캐싱을 수행하여 ALB와 백엔드 서버의 부하를 경감
보안 강화
:
AWS WAF, AWS Shield 적용 가능
AWS WAF
CloudFront: 요청을 받을 때, WAF가 엣지 로케이션에서 요청을 검사하여 악성 트래픽이나 DDos를 차단
ALB: 트래픽을 받아 처리하기 전 WAF가 트래픽을 검사. 트래픽을 백엔드로 보내기 전에 필터링 해, 공격을 차단할 수 있음
AWS Shield
CloudFront: Standard 자동 적용. 네트워크 계층(DDos 공격)에 자동적으로 적용되며, 대규모 공격을 효과적으로 완화
ALB: Standard로 DDos 공격 자동 방어. AWS Shield Advanced로 보다 고도화된 DDos 공격 방어 가능
글로벌 서비스 대응 가능
:
CloudFront의 엣지 로케이션을 통해 빠른 콘텐츠 제공 가능
HTTPS 도메인 제공
CloudFront는 자체적으로 SSL을 적용한 도메인을 기본 제공하므로 도메인을 구매할 필요 없이 HTTPS 암호화 통신 사용 가능
주의점
ALB의 퍼블릭 노출
:
ALB가 인터넷에서 접근 가능한 상태여야 CloudFront 와 연결 가능.
보안 그룹 설정 및 CloudFront 전용 IP 허용 필요
CloudFront의 캐싱 정책 세밀 조정 필요
:
동적 콘텐츠 캐싱이 잘못될 경우 응답 속도 저하
ALB 스파이크 트래픽 대응
:
ALB는 CloudFront의 Origin Shield 활용 불가.
대신 Regional Edge Cache 적절한 활용으로 ALB의 부하 방지 필요
CloudFront와 ALB의 통합
:
AWS는 최근 CloudFront와 ALB의 원클릭 통합을 발표
ALB 콘솔에서 직접 CloudFront와 AWS WAF의 구성이 가능해짐.
따라서, ALB 에 도달하기 위한 모든 인바운드 트래픽을 수집, 흡수, 필터링하는 단일 진입 지점으로 손쉽게 CloudFront 사용 가능.
최소한의 구성으로 ALB, CloudFront, AWS WAF를 활성화하여 애플리케이션을 보호할 수 있게 됨.
추천 사용 사례
글로벌 트래픽
을 처리하는 웹 애플리케이션
정적 콘텐츠와 동적 API 요청을 동시에 처리해야 하는
대규모 서비스
ALB.단독 사용보다 비용 최적화가 필요한 경우
Spring Boot와의 연결
API 요청
흐름
: 사용자(Client) -> CloudFront -> ALB -> 백엔드(EC2)
CloudFront가 API요청을 ALB로 프록시 함
HINT 1 충족
API URL 접근
CloudFront
특정 CloudFront에서만 오리진(ALB)에 호출 가능하도록 설정
AWS WAF에서 Allow "/api/*' 요청
CloudFront Signed URL 또는
JWT 토큰 인증
적용 가능
ALB
ALB 리스너: HTTPS 443
path-based 라우팅으로 /api/* 요청을 특정 백엔드 그룹으로 전달