164. CloudFront 개요
이제 클라우드 프론트를 시작으로 컨텐츠 전달에 대해 알아보겠습니다
클라우드 프론트는 컨텐츠 전달 네트워크, 즉 CDN으로
판독 능력을 향상시키는데요. 컨텐츠가 엣지 로케이션에서 분배 및 캐시가 되기 때문입니다.
현재 이 강의를 녹화 중인 시점에서는 전 세계적으로 216개의 엣지 로케이션이 존재하며 지속적으로 새로운 지점이 추가되고 있죠. AWS 내의 리전은 약 30개로 리전보다 훨씬 더 많으며 전 세계에 펴져 있습니다.
클라우트 프론트는 엣지에서의 캐싱 외에 DDoS 보호도 제공하는데요. 서비스 거부를 배포하는 이러한 공격으로부터 보호막과 웹 애플리케이션 방화벽을 제공하죠. 이 내용은 강의의 보안 섹션에서 배우게 될 겁니다. 하지만 요점은 보안이 철저하다는 것과 애플리케이션을 전 세계적으로 배포하기에 좋은 프론트라는 거죠.
그리고 인증서를 로드하여 외부 HTTPS 엔드 포인트를 노출하고 해당 트래픽을 암호화해야 하는 경우 내부 HTTPS에서 애플리케이션에 내부적으로 통신하게끔 해줍니다.
도면으로 살펴봅시다 여기에 세계 지도가 있고 몇 개의 주황색 리전과 엣지가 있습니다. 지도 내에 보이는 지점은 모두 엣지로 보시다시피 전 세계에 퍼져 있죠. 예를 들어, 호주에서 S3 버킷이 있고 미국의 사용자가 여기로 액세스하려 하면 미국에서 가까운 엣지 로케이션에 액세스를 한 뒤 해당 네트워크가 사설 AWS 네트워크를 통해 S3 버킷까지 전송이 되죠. 그리고 콘텐츠는 캐시됩니다. 즉 미국에 이러한 사용자가 많아질수록 동일한 읽기를 원하는 사람이 많아질 것이고 그렇게 되면 이런 사용자들은 호주가 아니라 미국에서 직접 제공되는 콘텐츠를 얻게 되는 겁니다. 콘텐츠가 미국에서 페치되고 제공되면 현지에서 캐시되기 때문이죠.
아시아에 있는 다른 사용자가 아시아에서 가까운 엣지 로케이션으로 통신을 하면, 엣지 로케이션이 S3 버킷으로 트래픽을 지원하여 콘텐츠를 얻고 엣지에서 캐시할 겁니다. 즉 클라우드 프론트는 이처럼 다양한 엣지 로케이션에 기반해 읽기를 전 세계에 배포합니다. 그러면 메인 S3 버킷에서 지연 시간과 로드를 줄일 수 있죠.
그렇다면 S3 버킷 외의 다른 클라우드 프론트 오리진들도 살펴봅시다
첫 번째는 S3 버킷이고요.
- S3 앞에서 클라우드 프론트를 사용하는 것은 전 세계에 파일을 배포하고 엣지에서 캐시할 때 아주 흔히 볼 수 있는 패턴이죠.
- 그리고 오리진 액세스 신분(OAI)으로 클라우드 프론트와 S3 버킷 사이의 보안을 강화해 주죠 이 부분은 실습에서 볼 겁니다. 이는 S3 버킷이 오직 클라우드 프론트하고만 소통할 수 있도록 해줍니다.
- 마지막으로 클라우드 프론트를 세계 어디서든 파일을 S3에 업로드할 입구처럼 사용할 수도 있습니다.
다른 선택지는 커스텀 오리진을 사용하는 것인데요. 이때는 HTTP 엔드 포인트가 있어야 합니다. HTTP 프로토콜을 준수하는 무엇이든 될 수 있죠.
- 애플리케이션 로드 밸런서일 수도 있고
- EC2 인스턴스나
- S3 웹사이트일 수도 있죠. 하지만 우선 정적 S3 웹사이트로 버킷을 활성화해야 하며 이는 S3 버킷과는 다르다는 점 참고하세요. S3 웹사이트에서 이전에 봤던 설정을 활성화해야 하며
- 여러분이 원하는 모든 HTTP 백엔드가 가능합니다. 예를 들어, 여러분의 사내에 있는 인프라일 수도 있는 거죠.
그러면 클라우드 프론트의 전반적인 작동 방식은 어떨까요?
전 세계 여러 곳에 엣지 로케이션이 있고요. 이 엣지 로케이션들은 우리가 정의한 오리진으로 연결되어 있습니다. S3 버킷 등 어떤 HTTP 엔드 포인트도 될 수 있죠. 클라이언트가 우리의 클라우드 프론트 분산으로 액세스하려 하는 경우 클라이언트는 클라우드 프론트에 직접 HTTP 요청을 보낼 겁니다. HTTP 요청은 이런 형식인데요. URL과 쿼리 스트링 매개변수 헤더 등으로 이뤄져 있죠. 그러면 엣지 로케이션이 요청을 오리진으로 전달할 텐데요. 이 요청에는 쿼리 스트링과 요청 헤더가 포함될 겁니다. 이렇게 모든 내용이 오리진으로 전달이 되는 거죠. 이렇게 구성하실 수 있습니다. 그러면 오리진이 엣지 로케이션에 회신해 엣지 로케이션은 정의된 캐시 설정에 따라 회신 내용을 캐시할 겁니다. 그리고 회신 내용을 클라이언트에게 반환하죠. 그리고 다음 번에 다른 클라이언트가 비슷한 요청을 하면 엣지 로케이션은 요청을 오리진으로 전달하기 전에 우선 캐시부터 살펴볼 겁니다. 이런 작업이 바로 CDN의 목적입니다 아주 간단하죠, 클라우드 프론트의 작동 방식은 이렇습니다.
그럼 오리진으로서의 S3에 대해 자세히 살펴보겠습니다
클라우드가 있고 오리진, 즉 S3 버킷이 있습니다. 엣지 로케이션은 로스엔젤레스에 있다고 해보죠. 이 엣지 로케이션으로부터 데이터를 읽으려 하는 몇몇 사용자들이 있으면 엣지 로케이션이 사설 AWS 네트워크를 통해 S3 버킷에서 데이터를 가져와서 해당 엣지 로케이션으로부터 결과를 제공할 겁니다.
요점은 클라우드 프론트의 엣지 로케이션이 S3 버킷에 액세스하려면 클라우트 프론트 오리진에 대한 IAM 역할인 OAI, 즉 오리진 액세스 신분을 사용해야 한다는 겁니다. IAM 역할을 이용해 S3 버킷에 액세스한 뒤 버킷 정책이 이 역할의 액세스를 허용하면 파일을 클라우드 프론트로 전달하게 되는 겁니다.
이는 브라질의 상파울루나 뭄바이나 멜버른과 같은 다른 엣지 로케이션에서도 작동합니다. 즉 전 세계의 모든 엣지 로케이션이 S3 버킷에 캐시된 콘텐츠를 제공하는 거죠. 이런 방식을 통해 클라우드 프론트는 CDN으로서 굉장히 유용하게 사용됩니다.
그렇다면 만약 오리진이 ALB 또는 EC2인 경우는 어떨까요?
보안 부분이 조금 달라집니다. EC2 인스턴스(들)는 HTTP를 통해 공용 액세스가 가능하게끔 공용이어야 하며 사용자들은 전 세계에 퍼져 있죠. 이들이 엣지 로케이션에 액세스를 하면 엣지 로케이션은 EC2 인스턴스로 액세스할 겁니다. 그럼 보시다시피 보안 그룹을 횡단하게 되죠. 따라서 보안 그룹은 클라우드 프론트 엣지 로케이션의 IP를 EC2 인스턴스 내로 허용해야 하는데요. 이를 위해서는 이 웹사이트에서 찾으실 수 있는 엣지 로케이션의 공용 IP 목록이 있어야 하죠. 즉 보안 그룹이 엣지 로케이션의 모든 공용 IP에 클라우트 프론트가 EC2 인스턴스로부터 컨텐츠를 가져갈 수 있게끔 허용해야 하겠죠.
그러면 ALB를 오리진으로 사용하는 경우에는 어떨까요?
이렇게 해당 ALB에 대한 보안 그룹이 있고 클라우드 프론트가 액세스할 수 있게 ALB는 공용이어야 하지만 이제 백엔드 EC2 인스턴스는 사설이어도 됩니다. 따라서 EC2 인스턴스에 대한 보안 그룹은 로드 밸런서의 보안 그룹을 허용해야 합니다. 이 부분에 대해서는 살펴봤었죠.
공용 로케이션인 엣지 로케이션의 경우에는 공용 네트워크를 통해 ALB에 액세스해야 합니다. 즉 여러분의 ALB에 대한 보안 그룹은 엣지 로케이션의 공용 IP를 허용해야 하는 거죠. 앞서 살펴본 것과 동일한 공용 IP입니다. 즉 아키텍처는 다르지만 개념은 동일합니다. 클라우드 프론트의 앞이나 뒤에서 S3나 ALB나 EC2를 위한 네트워크 보안을 이해해야겠죠.
CDN으로서의 클라우드 프론트에는 몇몇 훌륭한 기능이 있는데 그 중 하나는 지리적 제한이죠.
분산으로의 액세스에 제한을 둘 수 있습니다.
- 화이트리스트라는 걸 제공할 수 있는데 이 리스트에 있는 허용된 국가의 사용자들만이 클라우드 프론트에 액세스할 수 있도록 하는 것이죠.
- 혹은 블랙리스트를 만들어서 특정 국가의 사용자들이 분배에 액세스할 수 없도록 할 수도 있습니다.
제3자 회사의 지리적 IP 데이터베이스를 이용해 국가들의 허용 여부가 결정됩니다. 수신되는 IP와 리스트를 비교하여 국가를 알아내는 방식이죠.
특정 콘텐츠에 액세스를 제한하는 저작권법이 있을 때 이런 제한을 사용할 수 있고 규제 당국에 예를 들면 미국의 컨텐츠에 프랑스로부터의 액세스를 제한하고 있음을 증명할 때 사용할 수 있습니다.
이쯤 되면 클라우드 프론트와 S3 리전 간 복제 사이에 어떤 차이가 있는지 궁금하실 수도 있을 텐데요.
클라우드 프론트는
- 세계적인 엣지 네트워크를 사용하고
- TTL에 맞춰 파일이 캐시됩니다. 타임 투 리브가 하루일 수 있겠죠
- 그러므로 전 세계에서 이용 가능해야 하는 정적인 콘텐츠에 적합합니다. 콘텐츠가 약간 오래되어도 괜찮은 경우에 사용할 수 있겠죠.
반면 S3 리전 간 복제는
- 복제가 일어나도록 할 각 리전에 설정되어야 하며
- 파일이 거의 실시간으로 업데이트되고
- 읽기 전용이기 때문에 읽기 성능이 좋습니다.
- 따라서 S3 리전 간 복제는 적은 수의 리전에서 낮은 지연 시간으로 사용이 가능해야 하는 동적인 콘텐츠에 적합할 겁니다.
이해가 되시나요?
클라우트 프론트는 전 세계 대상이며 S3 리전 간 복제는 선택된 리전에 복제하는 용도입니다
165. CloudFront with S3 - 실습
166. CloudFront 서명 URL/쿠키
CloudFront Signed URL / Signed Cookies
클라우드 프론트 분산을 비공개로 만들기 위해서는 세계 각지의 사람들에게 프리미엄 유료 콘텐츠에 대한 액세스를 주어야 하는데요.
하지만 누가, 어떤 클라우드 프론트 분산에 액세스하는지를 알기 위해서 클라우드 프론트 서명된 URL이나 쿠키를 사용할 수 있습니다. 서명된 URL과 쿠키의 차이점은 슬라이드의 마지막에 볼 겁니다.
- URL과 쿠키를 생성할 때에는 정책을 연결해 해당 URL이나 쿠키가 언제 만료되는지
- 이 데이터에 액세스할 수 있는 IP 범위는 어디인지를 지정해야 합니다. 만약 클라이언트의 대상 IP를 알 경우에 사용이 가능하겠죠
- 그리고 어떤 AWS 계정이 서명된 URL을 생성할 수 있는지를 의미하는 신뢰할 수 있는 서명자도 지정해야 하죠.
그럼 URL은 얼마나 오래 유효해야 하는 걸까요?
- 영화나 음악과 같은 콘텐츠를 공유할 때는 몇 분 정도로 짧아도 될 겁니다.
- 하지만 해당 사용자가 장기간 액세스할 수 있어야 하는 비공개 콘텐츠의 경우에는 URL이나 서명된 쿠키가 수 년간 지속되게 할 수도 있습니다.
그럼 URL과 쿠키의 차이는 무엇일까요?
- 서명된 URL은 개별 파일에 대한 액세스를 줍니다. 파일별로 하나의 URL이 있는 거죠. 파일이 백 개면 백 개의 URL이 있습니다.
- 서명된 쿠키로는 다수의 파일에 액세스를 주고 해당 쿠키는 재사용이 가능합니다. 즉 다수의 파일에 서명된 쿠키는 하나인 거죠. 따라서 상황에 따라 적절히 선택하면 됩니다.
CloudFront Signed URL Diagram
도면을 통해서 서명된 URL에 대해서 알아보죠. 클라우드 프론트 분산이 있고 여러 개의 엣지 로케이션이 있습니다.
그리고 예를 들어 보안을 위해 오리진 액세스 신분(OAI)을 이용해 S3 버킷에 액세스한다고 합시다. 즉 오직 클라우드 프론트를 이용해서만 S3 버킷 내의 객체에 액세스할 수 있는 거죠. 하지만 여전히 클라우드 프론트를 통해 사람들에게 객체에 대한 액세스를 제공하고자 합니다.
즉 클라이언트는 애플리케이션으로 허가 및 승인을 보낼 것이며 우리는 애플리케이션을 코딩해야겠죠.
그리고 애플리케이션은 AWS SDK를 사용해 클라우드 프론트로부터 직접 서명된 URL을 생성합니다. 서명된 URL은 클라이언트에게 반환될 것이고 그럼 클라이언트는 이 서명된 URL을 이용해 데이터와 파일과 객체 등 클라우드 프론트에서 원하는 것을 직접 얻을 수 있게 됩니다. 서명된 URL뿐 아니라 서명된 쿠키도 방식은 동일합니다.
CloudFront Signed URL vs S3 Pre-Signed URL
그러면 서명된 URL과 서명된 쿠키 중 어느 것을 사용해야 할까요?
이 둘은 용도가 다릅니다 클라우드 프론트 서명된 URL은
- 오리진에 상관 없이 경로에 대한 액세스를 허용하기 때문에 서명된 URL은 S3 오리진뿐만 아니라 원하시는 모든 HTTP 백엔드 오리진에 작동합니다.
- 이는 계정 내 키 페어이기 때문에 루트만 관리할 수 있고
- IP, 경로, 날짜, 만료 등으로 필터링할 수 있으며
- 클라우드 프론트에 있는 모든 캐싱 기능을 활용할 수 있습니다
하단의 도면을 보시면 클라우드 프론트 분산에 서명된 URL을 사용하는 클라이언트가 있고 클라우드 프론트 분산은 오리진인 EC2 인스턴스로 통신을 보냅니다.
이런 방식으로 작동하는 거죠.
- 반면 S3 미리 서명된 URL은 URL에 미리 서명한 사람으로서 요청을 발행합니다.
- 따라서 제가 저만의 IAM 원칙으로 URL에 서명하고 서명을 위해 제 IAM 키를 사용하게 되면 해당 URL을 가진 사람은 저와 같은 권한을 가지게 됩니다.
- 수명이 제한적이죠.
이 미리 서명된 URL을 사용해 클라이언트가 직접 S3 버킷에 액세스할 수 있습니다. 만약 사람들이 여러분의 클라우드 프론트 분산에 액세스하길 원하고 S3 앞에 있는 경우라면 의도한 대로 S3 버킷에 액세스할 수 없으므로 서명된 URL을 사용해야만 합니다. 이를 OAI로 제한하는 버킷 정책 때문이죠. 하지만 클라우드 프론트를 사용하지 않고 사용자들이 직접 S3 버킷으로 액세스해 파일을 사용하길 원하시면 미리 서명된 URL이 적합할 겁니다.
167. CloudFront 고급 개념
시험 출제 가능성이 있는 클라우드 프론트의 고급 옵션에 대해 한 번 알아볼 텐데요. 요금과 가격 등급을 살펴보겠습니다.
클라우드 프론트 엣지 로케이션이 전 세계에 퍼져 있다는 건 이미 알고 계시죠.
하지만 전 세계에 걸쳐 존재하기에 엣지 로케이션에 따른 데이터 전송 비용도 다를 겁니다.
표로 정리된 내용은 이렇습니다 보시다시피 엣지 로케이션이 위치한 대륙 또는 지리적 위치에 따라 요금이 달라집니다.
표를 한 번 보시면 멕시코 및 미국, 캐나다의 경우 첫 10TB에 대한 요금은 1GB당 0.085달러입니다. 하지만 인도에 있는 동일한 엣지 로케이션의 경우 비용이 두 배로 전송된 데이터 1GB당 0.17달러를 지불하는 식입니다.
클라우드 프론트에서 더 많은 데이터가 전송될수록 요금은 낮아지므로 만약 클라우드 프론트에서 5PB의 데이터를 전송하는 경우에 미국의 경우에는 0.02달러만 지불하면 되는 거죠.
왼쪽에서 오른쪽으로 갈수록 가격대가 더욱 높아지는데요.
바로 이게 가격 등급이라는 개념으로 이어집니다. 여기서 선택지가 주어지는데
전 세계에 걸쳐 클라우드 프론트 분산에 사용할 엣지 로케이션의 수를 줄여 가격을 낮출 수 있습니다.
가격 등급은 총 세 가지입니다
- Price Class All의 경우에는 모든 지역을 제공하며 당연히 최상의 성능을 보이지만 비용이 다소 높습니다. 예를 들어 인도의 엣지 로케이션의 요금이 미국의 엣지 로케이션보다 더 높은 것과 같은 이치죠.
- Price Class 200도 있는데요. 가장 비싼 지역을 제외한 대부분의 지역을 제공해 줍니다.
- Price Class 100은 가장 저렴한 지역만을 제공하죠.
하단의 표에 내용이 정리되어 있습니다만
표로 보는 건 재미가 없죠
그래서 세계 지도로 도면을 준비해 봤습니다. 전 세계에 굉장히 많은 엣지 로케이션이 있는데요. Price Class 100의 경우 미국, 북미 및 유럽을 제공하고
Price Class 200은 다음과 같은 지역을 추가해 주죠
Price Class All로는 전 세계의 엣지 로케이션을 이용할 수 있습니다.
CloudFront - Multiple Origin
이번에는 클라우드 프론트의 다중 오리진과 오리진 그룹을 살펴봅시다.
예를 들어, 콘텐츠의 유형이나 경로에 따라 클라우드 프론트를 거치는 라우트나 경로를 리다이렉팅해 다른 오리진으로 라우팅하고 싶어질 수도 있습니다.
예를 들어,
- 이미지용 경로나 API용 경로 또는 그 외의 모든 경로가 있다고 한다면
어느 경로건 클라우드 프론트에서는 정해진 경로를 통해 다양한 캐시 작업을 설정할 수 있습니다.
예를 들어 API/* 경로를 사용 중인 경우 애플리케이션 로드 밸런서가 되는 오리진으로부터의 회신이 필요하다고 할 수 있습니다. 하지만 그 외의 모든 경로(/*)를 요청할 경우 /*가 변함 없는 콘텐츠라면 해당 콘텐츠를 S3 버킷에서 가져와야 할 겁니다.
이런 식으로 Amazon 클라우드 프론트에서 사용되는 경로를 기반으로 다중 오리진이 정의됩니다.
CloudFront - Origin Groups
마찬가지로 오리진 그룹을 설정할 수도 있는데 이 경우에는 용례가 다릅니다.
고가용성을 증가시키고 한 오리진에서 장애가 발생한 경우 장애 조치가 가능하게 해주죠.
따라서 오리진 그룹은 하나의 주 오리진과 하나의 보조 오리진으로 구성됩니다.
만약 주 오리진에 장애가 발생하면 클라우드 프론트가 보조 오리진으 사용하는 것으로 대체를 하게 되는 거죠.
예시로 살펴봅시다 클라우드 프론트가 있고 두 개의 EC2 인스턴스로 구성된 오리진 그룹이 있는데요. 첫 번째 인스턴스가 주 오리진 두 번째 인스턴스가 보조 오리진이 됩니다. 그럼 Amazon 클라우드 프론트가 첫 EC2 인스턴스로 요청을 보내고 그리고 이 EC2 인스턴스로부터 에러가 돌아올 경우 Amazon 클라우드 프론트는 동일한 요청을 B 오리진으로 다시 보낼 겁니다. 그러면 이 인스턴스는 okay 상태 코드로 회신을 하는 식이죠. 이런 식으로 대체 작동이 가능합니다
이를 Amazon S3와 함께 사용할 수도 있죠. 이 예시의 경우 만약 S3와 클라우드 프론트를 오리진 그룹과 함께 사용한다면 지역 단위의 고가용성과 재해 복구가 가능하게 됩니다.
한 번 살펴보죠. 두 개의 S3 버킷으로 구성된 오리진 그룹이 있습니다. 첫 S3 버킷이 주 오리진이 되고 두 번째 S3 버킷은 보조 오리진이 되겠죠. 만약 이 S3 버킷들이 다른 지역에 있을 경우 이 버킷들 사이에 복제를 설정할 수 있습니다. 따라서 A 오리진의 모든 콘텐츠가 B 오리진으로 복제되는 거죠. 만약 Amazon 클라우드 프론트가 요청을 보냈는데 지역 단위의 정전 등의 이유로 인해 첫 S3 버킷에서 오류 회신을 받았다면 클라우드 프론트는 동일한 요청을 다른 지역의 다른 S3 버킷으로 보낼 것이고 이 버킷은 복제 덕분에 첫 번째 버킷이 가지고 있던 모든 데이터를 갖고 있겠죠. 따라서 이 S3은 okay 상태 메시지로 회신을 보낼 겁니다. 이런 방식으로 Amazon 클라우드 프론트와 S3 버킷에 대한 지역 단위 재해의 복구가 가능한 훌륭한 구조를 구축할 수 있는 거죠.
CloudFront - Field Level Encryption
마지막으로 필드 수준의 암호화에 대해 살펴봅시다
이는 애플리케이션 스택을 통해 민감한 정보를 보호하는 기능으로
HTTPS를 사용하는 인플라이트 암호화와 더불어 추가적인 보안을 더해 줍니다.
즉, 사용자가 민감한 정보를 전송할 때마다 엣지 로케이션이 이를 암호화하고 개인 키에 대한 권한을 지닌 사용자만이 이 정보를 해독할 수 있도록 하는 개념입니다.
따라서 이 기능은 비대칭 암호화를 사용하겠죠
그럼 작동 원리는 뭘까요?
- Amazon 클라우드 프론트로 보내는 POST 요청의 경우 암호화를 원하는 필드를 최대 10개까지 지정할 수 있습니다. 신용 카드 등을 예로 들 수 있겠죠.
- 그리고 이 필드를 해독할 공용 키도 함께 지정됩니다.
예시를 한 번 살펴보죠. HTTPS를 엣지 로케이션으로 전달하는 클라이언트가 있다고 가정합시다. 그럼 엣지 로케이션은 다시 HTTPS를 통해 클라우드 프론트로 전달하고 이는 애플리케이션 로드 밸런서를 통해 HTTPS를 사용해 오리진까지 전달될 겁니다. 그 다음에는 모든 데이터가 HTTPS를 통해 웹 서버로 전달되겠죠 전송 과정에서 모든 정보는 암호화되어 있으나, 우리는 필드 수준의 암호화를 설정하려 합니다.
예를 들어 한 사용자가 우리에게 신용 카드 정보를 전달한다고 가정하겠습니다. 현재 주황색으로 표시된 정보입니다. 그리고 우리가 이 신용카드 정보에 대한 필드 수준 암호화를 지정하려 하면 엣지 로케이션이 공용 키를 이용해 이 필드를 암호화하는 거죠. 그럼 엣지 로케이션을 지나 Amazon 클라우드 프론트 그리고 오리진으로 전달되는 데이터의 신용카드 정보는 공용키를 이용해 암호화가 되어 있을 겁니다. 그렇게 암호화된 정보가 웹 서버까지 전해지겠죠. 데이터가 도착하면 웹 서버는 개인 키에 대한 권한을 갖게 될 것이며 개인 키를 사용해 이 암호화된 단위를 해독하여 신용카드 번호를 얻게 될 겁니다.
스택 전반에 걸쳐 확인할 수 있듯 클라우드 프론트 지역과 애플리케이션 로드 밸런서는 이 필드를 해독할 수 없습니다. 오직 웹 서버만이 필드를 해독할 수 있는 커스텀 애플리케이션 논리를 가지고 있죠
168. AWS Global Accelerator - 개요
이번 강의에서는 AWS에서 비교적 새로운 종류의 서비스인 AWS Global Accelerator에 대해 얘기하겠습니다. 그러나 그 전에 우리가 해결할 문제가 무엇인지 그리고 어떻게 해결할 수 있는지 말씀드리죠.
여러분이 애플리케이션을 배치했다고 합시다. 이는 글로벌 애플리케이션이고 글로벌 사용자들이 직접 접근하려고 합니다.
그러나 우리 애플리케이션은 오직 한 리전에 배치되어 있죠. 예를 들면 인도에서 공용 애플리케이션 로드 밸런서를 배치했습니다. 반면에 사용자들은 전 세계에 걸쳐 있죠. 미국에도 있고 유럽과 오스트레일리아에도 있습니다.
사용자들이 애플리케이션에 접근할 때는 공용 인터넷을 통하게 되는데 라우터를 거치는 동안의 수 많은 홉으로 인해 상당한 지연이 발생할 수 있습니다.
제가 좀 과장하긴 했습니다만 미국을 보시면, 인도의 공용 ALB에 도달하기 전에 다섯 개의 홉, 즉 라우터 또는 서버들이 있죠. 이는 공용 인터넷을 거치기 때문입니다. 오스트레일리아에도 많은 홉이 있고 유럽에도 마찬가지입니다. 이 홉들은 위험 요소가 될 수 있습니다 연결이 끊길 수 있기 때문이죠. 또한 지연 시간도 발생합니다. Amazon 인프라에 최대한 직접적으로 접근하는 것도 아니죠.
따라서 지연 시간을 최소화하기 위해 최대한 빨리 AWS 네트워크를 통하는 것이 좋습니다. 이를 위해 Global Accelerator를 사용하는데, 그 전에 먼저 유니캐스트와 애니캐스트 IP라는 또 다른 개념을 설명드리겠습니다.
먼저 유니캐스트 IP는 이미 아는 내용이죠.
하나의 서버가 하나의 IP 주소를 가집니다. 따라서 클라이언트가 두 개의 서버와 통신할 때 왼편 서버의 IP 주소는 숫자 12로 시작하고, 반대편은 98로 시작합니다. 여러분이 12로 시작하는 IP 주소를 참조한다면 왼편의 서버로 연결되고 반대편 IP를 사용하면 오른편의 서버로 연결될 겁니다. 우리가 알고 있는 내용으로 이해하기 쉽습니다.
그러나 애니캐스트 IP는 조금 다릅니다. 모든 서버가 동일한 IP 주소를 가지며 클라이언트는 가장 가까운 서버로 라우팅됩니다. 그리 직관적이진 않지만 이런 식으로 작동합니다. 클라이언트와 두 개의 서버가 있고 보시는 것처럼 이 두 개의 서버는 아래 쪽에 있는데 IP가 동일합니다. 클라이언트가 이 애니캐스트 IP로 접속을 시도하면 자신과 가장 가까운 서버로 연결되죠. 놀랍긴 하지만 이런 식으로 작동합니다
그리고 Global Accelerator는 이 애니캐스트 IP 개념을 사용하죠.
어떻게 작동할까요? 애플리케이션을 라우팅하기 위해 AWS 내부 글로벌 네트워크를 활용할 겁니다.
기본 개념은 같습니다. 사용자들이 전 세계에 걸쳐 있고 우리는 인도로 라우팅 하고 싶죠. 그리고 미국의 공용 인터넷을 거쳐서 보내는 대신에 가장 가까운 엣지 로케이션과 통신할 겁니다. 엣지 로케이션으로부터 내부 AWS 네트워크를 거쳐 ALB로 곧장 연결되죠.
오스트레일리아도 동일합니다 오스트레일리아 인근의 엣지 로케이션으로 가서 사설 AWS 네트워크를 거쳐 ALB에 도달합니다 유럽도 마찬가지입니다.
즉 요점은 애니캐스트 IP를 사용한다는 것이죠. 사실, 애플리케이션을 위해 두 개가 생성되는데 둘 다 글로벌합니다.
그리고 애니캐스트 IP는 사용자와 가장 가까운 엣지 로케이션으로 트래픽을 직접 전송합니다. 이것이 애니캐스트 IP의 장점이죠.
그러면 엣지 로케이션은 훨씬 안정적이고 지연 시간이 적은 사설 AWS 네트워크를 거쳐 애플리케이션 로드 밸런서로 트래픽을 전송합니다. Global Accelerator는 어떤 애플리케이션에 대해서도 전 세계의 유저들에게 두 개의 고정 IP 주소를 제공할 수 있도록 해준다는 점에서 매우 독특합니다. 지금은 한 리전에 있는 한 ALB만 보여드리지만 이는 글로벌해질 수 있으며 다수의 ALB나 리전이 될 수도 있죠. 이건 게임 체인저입니다
그러면 무엇과 함께 작동할까요?
탄력적 IP, EC2 인스턴스 애플리케이션 로드 밸런서 네트워크 로드 밸런서와 함께 작동하며 공용일 수도 있고 사설일 수도 있습니다.
네트워크를 거치기 때문에 안정적인 성능을 보여주죠.
- 지능형 라우팅으로 지연 시간이 가장 짧은 엣지 로케이션으로 연결되며 뭔가 잘못될 경우에는 신속한 리전 장애 조치가 이루어질 겁니다.
- 아무것도 캐시하지 않기에 클라이언트 캐시와도 문제가 없습니다. 우리가 사용하는 두 개의 애니캐스트 IP는 변하지 않습니다.
- 엣지 로케이션 다음에 내부 AWS 네트워크가 오기 때문에 완벽하죠.
다음으로 상태 확인이 있습니다
- Global Accelerator가 애플리케이션에 대해 상태 확인을 실행할 겁니다.
- 그리고 애플리케이션이 글로벌한지 확인하죠. 한 리전에 있는 한 ALB에 대해 상태 확인을 실패하면 자동화된 장애 조치가 1분 안에 정상 엔드 포인트로 실행됩니다. 정말 멋지죠.
- 상태 확인 덕분에 재해 복구에 특히 뛰어납니다.
보안에 있어서
- 클라이언트가 화이트리스트 해야 하는 단 두 개의 외부 IP만 존재하기 때문에 보안 측면에서도 매우 안전하죠.
- Global Accelerator를 통해 DDoS 보호도 자동으로 받게 됩니다. 보안 섹션에서 살펴볼 AWS Shield 덕분이죠.
훌륭합니다
Global Accelerator와 CloudFront 사이의 차이점이 궁금할 수도 있겠네요. 차이점을 이미 파악하셨기를 바랍니다. 그렇지 않다면 제가 잘 가르치지 못한 것이니까요. 차이점을 아주 명확히 요약하겠습니다.
Global Accelerator와 CloudFront는 둘 다 동일한 글로벌 네트워크를 사용하고 둘 다 AWS가 생성한 전 세계의 엣지 로케이션을 사용합니다.
DDoS 보호를 위해 둘 다 AWS Shield와 통합되죠. 둘 다 같은 것을 받습니다 이제 차이점을 말씀드리면
CloudFront는
- 이미지나 비디오처럼 캐시 가능한 내용과 API 가속 및 동적 사이트 전달 같은
- 동적 내용 모두에 대해 성능을 향상시킵니다.
- 그리고 이 내용은 엣지 로케이션으로부터 제공되죠. 따라서 엣지 로케이션은 가끔 한 번씩 출처로부터 내용을 가져올 겁니다. 대부분의 경우에 CloudFront는 캐시된 내용을 엣지로부터 가져와서 전달합니다. 즉 사용자들은 엣지로부터 내용을 받는 겁니다.
반면에 Global Accelerator는
- TCP나 UDP상의 다양한 애플리케이션 성능을 향상시키죠.
- 그러나 패킷은 엣지 로케이션으로부터 하나 이상의 AWS 리전에서 실행되는 애플리케이션으로 프록시됩니다. 이 경우에는 모든 요청이 애플리케이션 쪽으로 전달되죠. 캐싱은 불가능합니다.
- 따라서 여러분이 게임이나 IoT 또는 Voice over IP 같은 비 HTTP를 사용할 경우에 매우 적합합니다.
- 글로벌하게 고정 IP를 요구하는 HTTP를 사용할 때도 매우 유용하죠.
- 또는 결정적이고 신속한 리전 장애 조치가 필요할 때도 좋습니다.
Global Accelerator는 비교적 새로운 서비스이고 시험에도 나올 겁니다
