AWS CCP 자격증 - 10 (글로벌 인프라)

글로벌 애플리케이션을 만드는 이유

 

왜 글로벌 애플리케이션을 만들까요?

글로벌 애플리케이션은 여러 지역에 배포되는 애플리케이션이며

 

이는 AWS에서는다양한 AWS 리전과 엣지 로케이션으로 애플리케이션이 배포된다는 의미입니다.

이를 통해 전 세계의 사용자의 지연 시간이 줄어들게 됩니다

지연 시간은 네트워크 패킷이 서버에 도달하는 시간입니다

 

그래서 지구가 큰 것을 고려하면 패킷이 아시아에서 미국까지 도달하는데 긴 시간이 소요될 것입니다

예를 들어, 사용자는 인도에 있고 서버는 미국에 있으면 더 많은 지연이 생기고 지연 시간도 늘어나지만

사용자 근처로 애플리케이션을 배포하면 수월하게 이용할 수 있죠

첫번째는 저 지연시간을 위해서 입니다.

애플리케이션을 미국과 아시아에 배포하면 미국의 사용자와 아시아의 사용자의 지연 시간이 줄어들게 됩니다

애플리케이션 서버에 빠르게 도달하기 대문입니다

두 번째 이유는 재해 복구 계획입니다

하나의 데이터 센터나 한 리전에 의존하지 않는 것으로 그럴 리 없겠지만 지진이나 태풍 또는 정전이나 정치적인 이유 등으로 전체 리전이 정지되면 재해 복구 계획으로 다른 리전으로 장애 조치해 애플리케이션이 계속 실행되도록 하는 것입니다

그래서 재해 복구 계획은 애플리케이션의 가용성을 높이는데 매우 중요합니다

 

글로벌 애플리케이션을 만드는 마지막 이유는 바로 공격에 대비하기 위해서입니다

해커들은 온라인에서 여러 이유로 애플리케이션을 중단시키기 위해 애플리케이션을 공격합니다

이때 애플리케이션이 여러 리전에 있고 전 세계적으로 배포했다면 여러 리전을 한 번에 공격하기 어려워집니다

그래서 이러한 공격으로부터 안전할 수 있는 것입니다

 

Global Applications in AWS

 Global DNS, Route 53을 살펴볼 것입니다

사용자를 최소한의 지연 시간으로 가장 가깝게 배포 리전에 라우팅 하도록 합니다.

그리고 재해 복구 계획에도 유용합니다

 

그리고 글로벌 CDN의 경우에는 CloudFront를 사용해 애플리케이션의 일부를

엣지 로케이션에 다시 복제해 사용자의 지연 시간을 줄이고 일반 요청을 캐시해서 사용자 경험을 개선하고

지연 시간 또한 줄이는 것입니다

 

 

그리고 S3 Transfer Acceleration도 살펴봅니다

Amazon S3로의 전 세계적인 업로드와 다운로드를 가속화합니다.

 

마지막은 AWS Global Accelerator로

AWS의 글로벌 네트워크로 글로벌 애플리케이션의 가용성과 성능을 개선합니다.

 

Amazon Route 53

Amazon Route 53입니다.

Route 53은 관리 DNS(도메인 이름 시스템)입니다

 

DNS가 무엇일까요? DNS는 전화번호부와 같습니다

규칙과 레코드의 모음집으로 클라이언트가 URL을 통해 올바른 서버를 찾아갈 수 있게 도와줍니다.

AWS에서 가장 흔한 레코드를 살펴보겠습니다

예를 들어, www.google.com을 IPv4 주소로 매핑하고자 합니다 이것을 A 레코드라고 합니다.

www.google.com을 긴 IPv6 주소와 매핑하면  AAAA 레코드라고 합니다.

 

호스트 이름을 다른 호스트 이름과 매핑하려고 한다면

즉, search.google.com을 이전 주소에 매핑하면 CNAME이라고 합니다 호스트 이름과 호스트 이름을 매핑하기 때문이죠

 

마지막으로 호스트 이름을 AWS 리소스에 매핑하는 것은 특별한 레코드로 별칭 레코드라고 합니다

ELB가 있거나 CloudFront, S3, RDS 데이터베이스 등을 이용하면 동작합니다

 

시험에서 모든 레코드 유형을 알 필요가 없지만 Route 53이 관리형 DNS란 것을 알면 됩니다

 

Route53 예시

A 레코드에서 무슨 일이 일어나는지 보면

웹 브라우저가 있고, 배포한 애플리케이션 서버가 있습니다.

공인 IPv4를 가지고 있죠 애플리케이션 서버에 일반 URL을 통해 접근하고 싶습니다

이를 위해 Route 53으로 가서 A 레코드를 만듭니다

 

웹 브라우저가 myapp.mydomain.com에 관한 DNS 요청을 합니다 그러면 DNS는 IP를 응답합니다

웹 브라우저는 이 IP를 이용하여 올바른 서버에 연결합니다 또한 서버로부터 HTTP 응답을 얻죠

대략적으로 DNS가 동작하는 기본 방식입니다

Route 53 라우팅 정책 (시험에나옴)

 

전반적으로 알고 있어야 하며 사용 용례에 따라 알맞은 것을 선택해야 합니다 꽤 간단합니다.

 

첫 번째는 단순 라우팅 정책입니다

상태 확인을 하지 않는 정책이죠 웹 브라우저는 DNS 시스템에 가서

DNS 검색을 하고 예를 들어, IPv4를 결과로 얻습니다 이것이 단순 라우팅 정책입니다 기본적인 정책입니다.

가중치 기반 라우팅 정책은 트래픽을 여러 기관의 인스턴스에 분산합니다.

 

예시에서는 기관 인스턴스에 가중치를 부여합니다 예를 들어, 70, 20, 10입니다

그러면 DNS는 클라이언트가 트래픽의 70%가 첫 번째로 가고, 트래픽의 20%가 두 번째로, 나머지 10%가 세 번째로 가도록 합니다

로드 밸런싱을 할 때 효율적입니다 가중치 라우팅 정책에서는 상태 확인을 합니다

 

지연시간 라우팅 정책

다음은 지연 시간 라우팅 정책입니다 예시에서는 애플리케이션을 전 세계적으로 표시하고 있는데요

하나는 캘리포니아에, 하나는 호주에 있습니다 사용자는 전 세계에 있죠

 

지연 시간 라우팅 정책은 사용자의 위치를 살펴보고 그들이 미국 캘리포이나 EC2 인스턴스에 가깝다면

해당 서버와 통신하도록 리디렉션 됩니다 .(만약 사용자가 호주와 가깝다면 호주 서버와 통신하도록 리디렉션됩니다)

지연 시간에 근거해서 말이죠

 

예시에서는 Route 53이 사용자와 서버 사이의 거리를 가깝게 만들어서 지연 시간을 최소화합니다

마지막으로 장애 조치 라우팅 정책이 있습니다

 

클라이언트가 있고 기본 EC2 인스턴스가 있고 장애 조치 인스턴스가 있습니다

DNS 시스템을 기본 인스턴스의 상태를 확인하고 만약 기본 인스턴스에 장애가 발생하면

장애 조치 인스턴스로 리디렉션합니다

 

장애 회복에 도움 됩니다

Route 53 덕분에 클라이언트는 인스턴스의 상태에 따라 어떤 인스턴스에 연결될지 정확히 알고 있습니다.

 

알아야 할 라우팅 정책은 여기까지입니다

 

첫 번째 정책은 상태 확인을 하지 않고 나머지는 모두 상태 확인을 합니다 모두 다른 목적이 있죠

가중치 라우팅 정책은 트래픽을 여러 기관 인스턴스에 분산합니다

지연 시간은 지연 시간을 최소화하고 장애 조치는 장애 회복에 도움 되죠

 

AWS CloudFront(CDN)

 

CloudFront는 콘텐츠 전송 네트워크, 즉 CDN입니다

언제든 시험에서 CDN이 나오면 CloudFront를 떠올리세요

 

여러 엣지 로케이션에서 웹사이트의 콘텐츠를 캐싱해서 읽기 성능을 향상시킵니다

전 세계에서 콘텐츠를 캐싱하기 때문에 전 세계 사용자들의 대기 시간이 단축되어서 사용자 경험을 개선해줍니다

 

CloudFront는 전 세계에 216개 접속 지점을 두고 있는데 세계 곳곳에 위치해 있는 AWS 엣지 로케이션에

해당합니다, 계속 로케이션을 추가해서 모든 곳에서 사용자 경험을 훨씬 더 개선하고 있어요

 

무엇보다 콘텐츠를 전 세계에 배포함으로써 디도스 공격을 방어합니다

디도스는 전 세계 모든 서버가 동시에 당할 수 있는 공격의 일종입니다.

 

요점은 애플리케이션을 전 세계에서 사용하기 때문에 CloudFront를 이용하면 이런 공격을 막아준다는 것입니다.

 

또 보안 섹션에서 배우게 될 Shield와 Web Application Firewall이라는 것도 이용합니다

세계 지도를 보고 싶다면 여기 지도가 있는데, 엣지 로케이션과 엣지 케이스가 나와 있습니다

 

이를 테면 호주에 S3 버킷을 생성하고 거기에 웹사이트를 만들었는데 사용자는 미국에 있다고 해보면

사용자는 CloudFront를 사용해서 미국에 있는 엣지 로케이션에서 콘텐츠를 요청하고 CloudFront가 호주에서 콘텐츠를 가져올 수 있습니다

 

미국에 있는 또 다른 사용자가 동일한 콘텐츠를 요청하고 있다면 엣지에서 곧바로 제공될 겁니다, 저 멀리 호주까지 가서 콘텐츠를 제공하는 게 아니에요

마

찬가지로 사용자가 중국에 있다면 중국의 접속 지점과 통 신해서 S3 버킷으로 리디렉션되고 콘텐츠는 엣지에서 캐싱됩니다

 

S3 Transfer Acceleration

S3 버킷은 한 리전에만 연결되는 것을 알고 있습니다.

사용자가 전 세계에 있는 파일을 특정 S3 버킷에 전송하고 싶다면 S3 Transfer Acceleration을 이용하여 전송 속도를 올릴 수 있습니다

 

이 방식은 예를 들어, 미국에 있는 파일을 호주 S3 버킷에 업로드할 때 파일을 엣지 로케이션에 업로드하여

미국 사용자에게 가깝게 하고 내부 네트워크를 사용하여 엣지 로케이션에서 호주의 S3 버킷으로 파일을 전송합니다.

좀 더 안정적이고 빠른 연결을 통해서 말이죠

 

S3 Transfer Acceleration가 동작하는 기본 방식입니다

이 방식은 멀리 떨어진 S3 버킷에 파일을 업로드하거나 다운로드할 때 사용합니다

멋진 점은 도구를 테스트하여 얼마나 효과적인지 볼 수 있습니다

 

AWS Global Accelerator

 

AWS Global Accelerator를 배워보겠습니다

 

이것은 AWS 글로벌 네트워크를 이용하여 글로벌 애플리케이션의 가용성과 성능을 개선할 때 사용합니다.

기본적으로 여러분의 요청은 이전에 AWS에서 본 사설 네트워크를 이용하여 라우팅 되고 애플리케이션의 라우팅을

약 60% 정도 최적화합니다

예시를 살펴보면 앱 브라우저를 인도에서 배포했고 전 세계 사용자가 애플리케이션에 접근하기 원합니다.

이들은 Global Accelerator로 엣지 로케이션을 연결하고 엣지 로케이션은 트래픽을 인도로 직접 라우팅합니다.

 

이 방식의 장점은 공용 인터넷의 트래픽이 미국과 가장 가까운 엣지 로케이션에서만 발생한다는 것입니다.

이것은 사설 AWS 네트워크를 이용하여 엣지 로케이션에서 앱 브라우저로 빠르게 연결합니다

유럽과 호주에서도 마찬가지입니다

 

게다가 애플리케이션의 접근은 2개의 정적 IP 또는 애니캐스트 IP로만 가능합니다.

이 정적 애니캐스트 IP를 이용하여 자동으로 올바른 엣지 로케이션에 리디렉션됩니다

 

Global Accelerator 없이 무슨 일이 일어나는지 보여주면, 클라이언트는 리전의 애플리케이션을 가져오기 위해

네트워크에서 많은 홉을 거치게 되고 이는 문제가 될 수 있습니다 지연 시간이 더해질 수 있습니다.

 

Global Accelerator를 이용한다면 AWS 엣지 로케이션에 연결하여 엣지 로케이션으로부터

연결하려는 리전까지 빠르게 갑니다 더 빠른 사설 AWS 네트워크를 이용하기 때문입니다.

 

Global Accelerator와 CloudFront의 공통점, 차이점

공통점 : 둘 다 AWS 글로벌 네트워크 사용, 전 세계 엣지 로케이션 사용하고 Shield와 통합하여 DDoS 보호

 

CloudFront : CDN(콘텐츠 전송 네트워크)으로 엣지에서 이미지, 영상, 웹사이트 같은 콘텐츠를 캐싱

- CloudFront 엣지에서 콘텐츠를 제공합니다. (엣지로케이션에서 캐싱하기 때문)

 

Global Accelerator : 캐싱하지 않고, 엣지 로케이션으로부터의 모든 요청은 리전의 애플리케이션으로 전달됩니다.

- TCP, UDP와 같이 넓은 범위에서의 요청에서 성능을 개선합니다.

- 정적 IP 주소를 요구하는 HTTP 사용 예시에 적합합니다.

- 결정적이고 빠른 지역 장애 조치나 좋은 성능을 요구할 때 적합합니다.

 

AWS Outposts

 

하이브리드 클라우드가 무엇일까요?

온프레미스 인프라를 유지하면서 클라우드 인프라를 가져가는 사업을 하이브리드 클라우드라고 합니다.

 

이때 IT 시스템을 처리하는 두 가지 방법이 있습니다

 

AWS 클라우드는 예를 들어, AWS 콘솔, CLI, AWS API를 이용합니다

 

다른 하나는 온프레미스 인프라를 위한 방법입니다

 

따라서 두 가지 다른 유형의 스킬이 있고 두 가지 다른 유형의 API가 있습니다 

그래서 AWS는 하이브리드 클라우드를 이용하는 회사를 위해 Outposts라는 서비스를 만듭니다.

 

Outposts는 클라우드와 마찬가지로 자체 온프레미스 애플리케이션을 구축할 수 있도록 동일한 AWS 인프라, 서비스, API 및 도구를 제공하는 "서버 랙"입니다

즉, 사내 온프레미스 인프라 내에 있는 서버에 Outposts 랙을 설치하여 관리할 것입니다.

 

이 서버에는 AWS 서비스가 미리 로드되어 있고 온프레미스의 장점도 누릴 수 있습니다.

기업의 데이터 센터를 보면 AWS가 Outposts 랙을 설정하고 이는 AWS 서비스를 온프레미스 데이터 센터로 직접 확장할 수 있습니다. 클라우드에서 실행하는 EC2 인스턴스와 자체 데이터 센터에서 실행하는 EC2 인스턴스의 차이점은

사용자가 랙 자체의 물리적 보안을 책임져야 한다는 점입니다. 사용자의 데이터 센터에 랙이 있기 때문이죠

 

Outposts의 혜택

첫 번째는 온프레미스 시스템에 접근할 때 지연 시간이 적다는 것입니다.

데이터 처리를 로컬에서 하고 데이터는 온프레미스 시스템을 떠나지 않죠 클라우드로 절대 가지 않고

데이터 센터 내에 머무릅니다

그리고 온프레미스에서 Outposts로 옮기기는 쉽습니다. Outposts에서 데이터를 클라우드로 쉽게 보낼 수 있습니다

이것은 완전 관리 서비스입니다 AWS가 서비스를 관리해 줍니다 Outposts를 사용하여 많은 서비스를 실행할 수 있습니다

예를 들어, Amazon EC2, Amazon EBS, Amazon S3, Amazon EKS, Amazon ECS, Amazon RDS, Amazon EMR이 있고

온프레미스 시스템 인프라에클라우드를 확장하는 멋지고 혁신적인 방식입니다

 

AWS WaveLength 

일단 시험에 5G가 나온다면 Wave Length입니다.

 

WaveLength 영역은 5G 네트워크 엣지에 있는 통신 제공업체의 데이터 센터 내에 내장된 인프라 배포입니다.

 

기본적으로 AWS 서비스를 5G 네트워크의 엣지에 배포할 수 있습니다.

EC2 인스턴스, EBS 볼륨, VPC를 WaveLength 영역에 배포할 수 있습니다.

예를 들어 5G 네트워크를 가진 통신사가 있고 WaveLength 영역이 있을 때 통신사의 게이트웨이를 통하여

EC2를 해당 영역에 배포할 수 있습니다.

 

그래서 영역은 5G 네트워크 자체에 속해있어서 모바일 기기의 5G 사용자가 WaveLength 영역에 접근할 때 지연 시간은 매우 적습니다 이유는 애플리케이션이 엣지에 배포되기 때문입니다

전반적으로 WaveLength는 5G 네트워크를 통해 애플리케이션의 지연 시간을 줄여줍니다

예시에서 트래픽은 통신 서비스 제공자, 즉 CSP 네트워크를 떠나지 않습니다

실제로 AWS에 도달하지 않지만 AWS로 보안 연결을 원한다면 그렇게 할 수 있습니다.

 

즉, WaveLength 영역은 부모 리전에 연결되어 있습니다 예시에서 WaveLength 영역에 있는

EC2 인스턴스는 데이터베이스에 접근해야 하는데요

 

예를 들어 AWS 리전의 RDS 또는 DynamoDB에 연결합니다 WaveLength를 사용할 때 추가 비용이나 서비스 동의는 필요 없어요

사용 사례도 다양합니다 스마트 도시, ML 기반 진단, 커넥티드 카, 대화형 실시간 영상 스트리밍, AR 및 VR, 실시간 게임이 있습니다

 

적은 지연 시간을 요구하고 사용자와 엣지가 매우 가까워야 하는 모든 것에 적합합니다

5G로 가능한 사용 사례였습니다

 

AWS Local Zones

 

시험에서 나올 수 있는 AWS 로컬 영역을 다뤄보겠습니다

 

가용 영역이 있고 전 세계에 여러 리전이 있습니다 로컬 영역이라는 개념은 컴퓨팅 스토리지 데이터베이스 및

데이터베이스가 선택한 다른 서비스를 최종 사용자와 가깝게 배치하여

지연 시간에 민감한 애플리케이션을 실행합니다

 

기본적으로 AWS 리전을 1개 이상의 위치 또는 1개 이상의 가용 영역으로 확장해 줍니다

이를 로컬 영역이라고 부릅니다

EC2, RDS, ECS, EBS, 일래스틱 캐시, Direct Connect 등과 호환됩니다

us-east-1 N.Virginia에 리전이 있고 6개의 AZ가 기본으로 있습니다 이 AZ를 더 많은 로컬 영역에 확장할 수 있습니다

보스턴, 시카고, 댈러스, 휴스턴, 마이애미 등으로 말이죠

어떻게 동작할까요? us-east-1 리전에 2개의 AZ가 있고

보스턴에 로컬 영역을 정의할 수 있습니다 그리고 VPC를 AZ과 로컬 영역으로 확장합니다

그러면 EC2 인스턴스를 로컬 영역에서 실행할 수 있습니다

 

Global Applications Architecture

 

어떻게 글로벌 애플리케이션을 만들까요?

아키텍처를 이야기하겠습니다

만약 하나의 리전, 하나의 AZ라면 간단합니다 하나의 리전에 한 AZ에 EC2 인스턴스가 있고

이는 가용성이 높지 않을 것입니다 글로벌 지연 시간이 좋지 않을 거예요

리전에서 멀리 떨어진 사용자가 이 기관에 접근한다면 지연 시간은 높을 것이기 때문이죠

하나의 리전에 여러 AZ가 있으면 즉, 여기에 한 리전에 2개의 AZ가 있습니다

그렇기 때문에 고가용성을 가집니다 그러나 글로벌 지연 시간은 개선하지 않습니다 AZ끼리 가까이 있죠

AZ에서 멀리 떨어진 지점에서는 지연 시간이 길 것입니다 

 

다음으로 액티브-패시브라고 부르는 다중 리전이 있습니다.

 

이 말은 2개의 리전이 있다는 뜻입니다. 각 리전은 하나 이상의 AZ가 있습니다

 

하나의 리전에는 EC2 인스턴스가 액티브되거나 애플리케이션이 액티브될 것입니다.

이 말은 사용자가 어디에 있든지 액티브된 리전의 EC2 인스턴스에 읽고 쓸 수 있다는 뜻입니다.

 

다른 EC2는 패시브인데요 이 말은 액티브 리전과 패시브 리전 간 데이터 복제가 일어나 사용자는 패시브 리전에서 읽을 수 있습니다 그러나 패시브 리전에 쓸 수는 없죠 액티브-패시브라고 부르는 이유입니다.

 

액티브-패시브를 사용하면, 전 세계에 많은 리전이 있고 모두가 패시브라면 읽기 지연 시간을 개선합니다

전 세계에 데이터를 복제하였기 때문에 지연 시간이 줄어들었습니다

그러나 쓰기의 경우, 여전히 중앙 리전으로 가야 합니다글로벌 수준에서 쓰기는 여전히 지연 시간이 높습니다.

 

 마지막으로 액티브-액티브가 있습니다

 

각 EC2 인스턴스가 쓰고 읽을 수 있습니다 2개의 인스턴스에서 복제가 일어나고 읽기 지연 시간을 개선하고

글로벌 수준의 쓰기 지연 시간도 마찬가지입니다

이제 애플리케이션이 한 리전에서 많은 것을 하므로 설정하기 더 어렵습니다

예를 들어, 액티브-액티브를 설정할 수 있는 데이터베이스는 DynamoDB 글로벌 테이블로 이전에 본 적 있습니다.

 

AWS 글로벌 애플리케이션 요약

먼저 글로벌 DNS Route 53을 살펴보았습니다 사용자를 가까운 배포로 라우팅하여 지연 시간을 최소화하는 좋은 방법으로 재해 복구 전략을 정의할 때 유용합니다.

레코드를 만드는 방법을 배웠고 호스트 이름에서 IP로 리디렉션하는 법 등을 배웠습니다.

CDN CloudFront를 배웠죠 Amazon S3와 실제로 연결해 보았습니다 기본적으로 애플리케이션 데이터를

어떤 AWS 엣지 로케이션에 복제하였습니다 이는 지연 시간을 줄여줍니다

추가로 CloudFront에서 일반적인 요청을 캐시에 저장했습니다 사용자 경험을 개선하고 지연 시간을 줄였죠

 

다음으로 S3 Transfer Acceleration입니다 이는 Amazon S3로 업로드하고 다운로드할 때 AWS 엣지 로케이션을 이용하여

속도를 빠르게 해주었습니다

Global Accelerator는 글로벌 네트워크인 엣지 로케이션을 사용하여 글로벌 애플리케이션의 가용성과 성능을 개선하였습니다

 

그리고 Outposts를 다뤘습니다 전체 인프라를 확장하는 방법이죠

Outposts를 통해 데이터 센터에 Outposts 랙을 배포하여 AWS 서비스를 확장합니다

온프레미스 데이터 센터 내에 AWS 클라우드가 있습니다

WaveLength는 AWS 서비스를 5G 네트워크의 엣지로 올립니다 애플리케이션의 지연 시간이 아주 낮아집니다.

마지막으로 로컬 영역입니다 로컬 영역은 AWS 리소스를 사용자와 가까운 데이터베이스 스토리지에서

컴퓨팅하도록 지원합니다

예를 들어 보스턴, 댈러스, 마이애미, 시카고 등등에서 말이죠 미국이나 세계 어느 특정 리전에서 로컬 접근이 빨라야 하는,

지연 시간에 민감한 애플리케이션일 때 정말 좋습니다