[ACC 프로젝트 1주차] 회고록

CDN (Content Delivery Network)

콘텐츠 전송 네트워크로, 전 세계적으로 분산된 서버 네트워크를 통해 콘텐츠를 효율적으로 전송하는 서비스.

CDN은 웹사이트, 애플리케이션, 미디어 콘텐츠 등을 빠르고 안정적으로 제공하기 위해 사용된다.

 

CDN의 주요 특징:

1. 엣지 로케이션: CDN이 콘텐츠를 캐싱하고 Client에게 제공하는 지점 혹은 캐시 서버를 의미. 엣지 로케이션은 사용자에게 가까운 위치에 배치되어 있어 콘텐츠에 빠르게 접근할 수 있도록 도와준다.
2. 캐싱: CDN은 콘텐츠를 엣지 서버에 캐시하여 사용자가 요청할 때마다 원본 서버로부터 콘텐츠를 다시 받아오지 않고도 제공한다. 이를 통해 네트워크 대역폭을 절약하고 응답 시간을 단축할 수 있다.
3. 로드 밸런싱: CDN은 트래픽을 여러 서버로 분산시켜 로드 밸런싱을 수행한다. 이를 통해 서버의 부하를 분산시켜 서비스의 안정성을 높일 수 있다.
4. 보안 기능: 일부 CDN은 웹 방화벽, DDoS 공격 방어, SSL/TLS 암호화 등의 보안 기능을 제공하여 콘텐츠의 보안을 강화할 수 있다.
5. 비용 효율성: CDN을 사용하면 전 세계의 사용자에게 콘텐츠를 제공하는 데 필요한 인프라 및 대역폭 비용을 절감할 수 있다.
6. 콘텐츠 최적화: 일부 CDN은 콘텐츠 압축, 이미지 최적화, 캐시 헤더 조정 등의 기능을 제공하여 콘텐츠를 최적화할 수 있다.

 

---

Amazon CloudFront

AWS CloudFront는 AWS가 제공하는 CDN 서비스이다. 

CloudFront의 동작 순서

1. 사용자가 어플리케이션에 요청을 한다.
2. DNS는 사용자에게 적합한 Edge Location으로 라우팅 한다.
3. Edge Location에서 캐시를 확인하고 있으면 이것을 사용자에게 반환한다.
4. 없으면 가장 가까운 REC로 캐시가 있는지 요청한다.
5. 없으면 CloudFront는 오리진으로 요청을 전달한다.
6. 오리진은 '오리진 > REC > Edge Location > CloudFront가 사용자에게 전달' 수순을 밟는다. (캐시도 추가된다)
7. REC에 캐시가 있다면 REC는 콘텐츠를 요청한 Edge Location으로 반환한다.
8. REC로부터 콘텐츠의 첫 번째 바이트가 도착하는 즉시 Edge Location은 이를 사용자에게 반환한다.
9. Edge Location은 나중을 위해 이 콘텐츠 캐시를 저장한다.

그 이후 콘텐츠는 TTL 값 동안 Edge Location에 캐싱되어 낮은 지연시간으로 콘텐츠를 요청할 수 있다.

참고로 오리진(Origin)은 콘텐츠가 위치하고 있는 근원을 말한다 (ex. EC2 Instance, S3 Bucket, On-Premise etc...)

---

Static, Dynamic 콘텐츠 모두 처리

다른 CDN과 다르게 CloudFront는 정적인 콘텐츠와 동적인 컨텐츠를 모두 처리해준다.

• 정적 컨텐츠 : 서버(EC2)가 필요하지 않고 이미지 등과 같은 데이터를 포함한다. 이러한 콘텐츠는 미리 캐시되어 있고 모든 사용자에게 동일하게 전달될 수 있다. 예를 들어, 이미지, CSS 파일, JavaScript 파일 등이 해당된다. 이러한 정적 콘텐츠는 S3 버킷 등에 저장되어 CloudFront 배포를 통해 전송될 수 있다.
• 동적 컨텐츠 : 서버가 필요한 콘텐츠로, 서버에서 동적으로 생성되거나 데이터베이스에서 가져와야 하는 콘텐츠를 말한다. 예를 들어, 로그인 정보, 실시간으로 업데이트되는 뉴스나 게시물 등이 해당된다. 

 

CloudFront에서의 동적 컨텐츠 처리

- 캐시 무효화 : CloudFront는 동적 콘텐츠에 대해 캐시 무효화를 수행할 수 있다. 이를 통해 특정 콘텐츠가 갱신되었을 때, 해당 콘텐츠를 캐시에서 제거하고 새로운 콘텐츠를 원본 서버에서 가져오도록 한다.

- TTL 설정 : CloudFront는 각 객체에 대해 TTL(Time to Live)을 설정할 수 있다. 동적 콘텐츠의 경우 낮은 TTL을 설정하여 자주 갱신되도록 할 수 있다. 이렇게 하면 동적 콘텐츠가 자주 업데이트되어 최신 상태를 유지할 수 있다.

- Lambda@Edge : Lambda@Edge를 사용하면, CloudFront의 요청 및 응답을 실시간으로 처리하고 수정할 수 있다.

Lambda@Edge는 서버 관리 부담 없이 웹 애플리케이션을 전 세계로 배포하고 성능을 개선하여 효과를 향상해 줍니다. Lambda@Edge는 Amazon CloudFront 콘텐츠 전송 네트워크(CDN)에 의해 생성된 이벤트에 대한 응답으로 코드를 실행합니다. 코드를 업로드하기만 하면 AWS Lambda가 최종 사용자와 가장 가까운 AWS 로케이션에서 뛰어난 가용성으로 코드를 실행하고 확장하는 데 필요한 모든 작업을 처리합니다.

https://aws.amazon.com/ko/lambda/edge/

 

- Origin Server 설정 : 동적 컨텐츠를 원본 서버에서 직접 제공하는 방법. CloudFront는 원본 서버와의 통신을 통해 동적 컨텐츠를 전달한다. 

 

https://bosungtea9416.tistory.com/entry/AWS-CloudFront

 

---

 

ELB(Elastic Load Balancer)

L4 스위치

로드밸런싱(서버 부하 분산)을 처리하는 장비이다. 외부에서 들어오는 모든 요청은 L4 스위치를 거쳐야 하며, 모든 요청을 L4 스위치가 받아 서버들에게 적절하게 나누어 준다. L4 스위치는 부하 분산뿐만 아니라 TCP, UDP, HTTP와 같은 Protocol의 Header를 분석하여 그 정보를 바탕으로 부하 분산을 실시하며, Source IP 혹은 Destination IP를 NAT 하여 보낼 수 있다. 

NAT (Network Address Translation) 개념
네트워크 주소 변환(network address translation, 줄여서 NAT)은 컴퓨터 네트워킹에서 쓰이는 용어로서,
IP패킷의 TCP/UDP 포트 숫자와 소스 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해
네트워크 트래픽을 주고 받는 기술을 말한다.
한 마디로 Network Address인 IP를 변환(Translation)하겠다는 뜻이다. 

https://inpa.tistory.com/entry/WEB-🌐-NAT-란-무엇인가

 

https://aws-hyoh.tistory.com/entry/L4-Switch-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

 

ELB 정의와 특징

ELB는 AWS가 제공하는 로드밸런서 서비스이다.

LB의 주요 기능은 서버 부하 분산, 즉 로드밸런싱으로 특정 서버에 부하가 몰리지 않도록 적절히 분산하는 것이다.

ELB는 서로 다른 EC2 인스턴스에 대한 하나의 엔드포인트를 제공한다. 그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려 없이, 동일한 엔드포인트로 요청을 전송할 수 있다. 

ELB는  EC2 뿐만 아니라 ECS의 컨테이너, Lambda 등을 상대로 부하 분산을 실시한다.

On-premise의 L4 스위치처럼 부하분산 뿐만 아니라, 부하 분산 대상에 대한 헬스 체크와 이를 통한 다운 서버 제외, 고정 세션, SSL offload(SSL 암복호화) 등의 기능을 한다.

 

ELB의 기본구성

ELB는 AWS의 사용자 정의 네트워크인 VPC에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스에 적절히 부하 분산한다. 

ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성되며 ELB는 다수의 리스너와 대상그룹을 가질 수 있다. 

부하 분산의 대상인 대상 그룹 내 리소스들은 헬스 체크 (Health Check)를 활용해 끊임 없이 상태를 확인 받는다. 

 

리스너는 외부의 요청을 받아들이기 때문에 서비스 포트(Service Port)를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리한다. (ex) 웹 서비스의 경우 80 포트) 대상 그룹 또한 서비스 포트 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려 있어야 한다. 한편, 대상그룹의 포트는 꼭 리스너와 포트가 같을 필요는 없다. 요청을 검토한 리스너가 요청이 적합한 경우 대상그룹에게 이를 전달할 떄, 대상 그룹의 포트로 'Port Tranlation'을 실시하기 때문이다.