AWS Global 인프라에 사용되는 서비스와 기능에 관해

 

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

...

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

AWS는 다양한 region과 Edge Location으로 애플리케이션이 배포된다는 의미이다.

 

글로벌 애플리케이션을 만드는 이유는 간단히 정리하자면 다음과 같다.

- 지연 시간이 짧다 : (지연 시간 : 네트워크 패킷이 서버에 도달하는 시간) 사용자 근처로 애플리케이션을 배포하면 수월하게 이용할 수 있다. 

- 재해 복구에 용이하다 : 하나의 데이터 센터나 한 region에 의존하지 않는 것으로 장애가 일어난 region에서 다른 region으로 조치해서 애플리케이션이 계속 작동되도록 할 수 있다. (가용성을 높이는데 매우 중요)

- 해커의 공격에 대비하기 위함 : 해커들은 온라인에서 애플리케이션을 중단시키기 위해 애플리케이션을 공격한다. 이때 여러 region에 있으면 한 번에 공격하기 어렵다. 이러한 공격에 조금 더 안전하다고 볼 수 있다.

 

 

#0 Route 53 - 관리형 DNS📂

글로벌 애플리케이션을 배포할 때 중요한 서버는 바로 Amazon Route 53이다. Route 53는 관리 DNS(도메인 이름 시스템)이다. 여기서 DNS는 전화번호부라고 생각하면 편하다. 여기서는 규칙과 레코드의 모음집이고 클라이언트가 URL을 통해서 올바른 서버를 찾아갈 수 있게 도와준다..! 

그러면 Route 53는 어떻게 동작할까?

A레코드에서 무슨 일이 일어나는지 알고 싶어한다. 이미지 상 왼쪽에는 웹 브라우저는 있는 상태이고 오른쪽 아래에는 우리가 배포한 애플리케이션 서버가 있는데 공인 IPv4를 가지고 있다. 애플리케이션 서버에 일반 URL을 통해 접근하고 싶어한다. 이를 위해 Route 53로 가서 A 레코드를 만든다. 웹 브라우저가 Route 53에 DNS 요청을 하면 DNS는 IP를 응답한다.웹 브라우저는 이 IP를 이용해서 올바른 서버에 연결한다. 또한 서버로부터 HTTP 응답을 얻는다.

=> 이것이 대략적으로 DNS가 동작하는 기본 방식이다👍

 

<Route 53의 라우팅 정책>

라우팅 정책은 전반적으로 우리가 알고 있어야 하고 사용 사례에 따라서 알맞은 것을 선택해야 한다.

 

1) Simple Routing Policy(단순 라우팅 정책)

그림을 통해 설명하자면 상태 확인을 하지 않는 정책으로 웹 브라우저는 DNS 시스템에 가서 DNS 검색을 하고 IPv4로 결과를 얻는다.

 

2) Weighted Routing Policy(가중치 기반 라우팅 정책)

이것은 트래픽을 여러 기관의 인스턴스에 분산한다. 그림 상에서는 기관 인스턴스에 가중치 70...을 부여한다. 그러면 DNS는 클라이언트가 트래픽의 70%가 첫 번째로 가고, 20%가 두 번째로 가는 식이다. (즉, 로드 밸런싱을 할 때 효율적)

 

3) Latency Routing Policy(지연 시간 라우팅 정책)

위의 예시 그림에서는 애플리케이션을 전세계적으로 표시하고 있는데 지연 시간 라우팅 정책은 사용자의 위치를 살펴보고 그들이 미국 캘리포니아 EC2 인스턴스에 가깝다면 해당 서버와 통신하도록 리디렉션된다. (지역 시간에 근거함)

=> 서버 사이를 가까이해서 지연 시간을 최소화한다!

 

4) Failover Routing Policy(장애 조치 라우팅 정책)

그림을 보면 클라이언트가 있고 기본 EC2 인스턴스와 장애 조치 인스턴스가 있는데 DNS 시스템을 기본 인스턴스의 상태를 확인하고 만약 기본 인스턴스에 장애가 발생하면 장애 조치 인스턴스로 리디렉션한다! (장애 회복에 도움이 된다)

...

이렇게 Route 53 덕분에 클라이언트는 인스턴스의 상태에 따라서 어떤 인스턴스에 연결될지 정확히 알 수 있는 것이다.

 

#1 CloudFront - 콘텐츠 전송 네트워크(CDN) 📷🎞️

CloudFront는 콘텐츠 전송 네트워크, 즉 CDN이다. 여러 Edge Location에서 웹사이트의 콘텐츠(이미지 등등)를 캐싱해서 읽기 성능을 올려준다. 전세계에서 콘텐츠를 캐싱하기 때문에 전세계 사용자들의 대기시간이 단축된다. 그리고 디도스 공격도 방어할 수 있다고 한다.

CloudFront는 몇 가지 Origin 타입이 있다. 예를 들어 S3버킷이 있어서 CloudFront를 이용해 엣지에 파일을 분산시키고 캐싱한다. 이걸 보장하기 위해 CloudFront만 S3 버킷에 액세스할 수 있다. S3로 데이터 파일을 업로드하는데 이걸 '인그레스'라고 한다.

모든 커스텀 오리진 HTTP 백엔드 앞에도 CloudFront를 둘 수 있다. => 로드 밸런서일수도 EC2나 S3 웹사이트일 수도 있다. 하지만 먼저 정적 S3 웹사이트로 버킷을 활성화해야 한다. 아니면 원하는 HTTP 백엔드 다 가능하다.

 

+) high level에서는 CloudFront가 어떻게 활용될까?

전세계 Edge Location이 위치해 있는데 이 로케이션이 우리들의 오리진으로 연결이 되면 S3버킷이나 HTTP 서버일 수도 있다. 근데 클라이언트가 Edge Location으로 연결해서 HTTP 요청을 하면 Edge Location은 캐시가 있는지 확인한다. 캐시가 없다면 오리진으로 가서 request 결과를 받아오고 결과를 받아오면 로컬 캐시에 캐싱해서 다른 클라이언트가 동일한 Edge Location에서 동일한 콘텐츠를 request할 경우, 해당 Edge Location이 오리진으로 이동할 필요가 없다.

 

어쨌거나 CloudFront를 사용해 애플리케이션의 일부를 Edge Location에 다시 복제해서 사용자의 지연 시간을 줄이고 일반 요청을 캐시해서 사용자 경험을 개선하고 지연 시간 또한 줄이는 것인데

...

CloudFront와 S3 Region(복제)의 차이점은 무엇일까?

<CloudFront>

CloudFront가 있다는건 Edge Location을 사용한다는 것인데 각각 하루동안  Edge Location에 캐싱되는데 전세계 어디에서나 이용이 가능해야 하는 정적 콘텐츠가 있을 때 아주 유용하다고 한다.

<S3 Region>

복제를 하고싶은 region마다 각각 설정해야 하기 때문에 전세계 모든 region에 적용되는 것이 아닐 뿐더러 파일이 거의 실시간으로 업데이트가 되는데 캐싱이 일어나지 않고 읽기 전용으로만 쓰는 것이 특징이다. 즉, 일부 region에서 항상 바뀌면서 대기 시간이 짧아야 하는 동적 컨텐츠가 있을 때 적합하다.

=> 결국 두 개의 개념은 매우 다른 용도로 서비스가 되는 것을 알 수 있다.

 

#2 S3 Transfer Acceleration - 전세계에서 빠르게 업로드/다운로드 하기 ⬇️

우리가 전세계에 있는 파일을 특정 S3 버킷에 전송하고 싶을 때, Transfer Acceleration을 이용해서 전송 속도를 올릴 수 가 있다.

설명을 위한 이미지

위의 그림을 보면 먼저 미국에 있는 파일을 호주에 있는 S3 버킷에 업로드할 때, Edge Location에 업로드해서 미국 사용자의 로케이션에 가깝게 하고 내부 네트워크를 사용해서 Edge Location에서 호주의 S3버킷으로 파일을 전송한다.

=> Amazon S3로의 전 세계전인 업로드와 다운로드를 가속화한다. 

 

#3 AWS Global Accelerator - 캐싱없이 정적인 IP주소를 요구하는 HTML에 적당

AWS의 글로벌 네트워크로 글로벌 애플리케이션의 가용성과 성능을 개선할 때 사용한다. 기본적으로 우리의 request는 이전에 AWS에서 본 사설 네트워크를 이용해서 라우팅이 되고 애플리케이션의 라우팅을 약 60%정도 최적화한다고 한다. 그리고 공용 인터넷의 트래픽이 보내는 region과 가장 가까운 Edge Location에서만 발생한다는 것이다..!

 그림으로 설명해보자면 앱을 인도에서 배포했고 전세계 사용자가 애플리케이션에 접근하기를 원하는 상황이다. Global Accelertor로 Edge Location을 연결하고 Edge Location은 트래픽을 인도로 직접 라우팅한다. (이 방식의 장점은 공용 인터넷의 트래픽이 미국과 가장 가까운 Edge Location에서만 발생한다는 점이다)

게다가 애플리케이션에 접근할 때, 2개의 정적IP나 Anycast IP로만 가능하고 이것을 이용해 자동으로 올바른 Edge Location에 리디렉션된다. 

 

<Global Accelerator와 CloudFront의 공통점과 차이점>

둘 다 AWS 글로벌 네트워크를 사용하고 전세계 Edge Location을 사용한다. 또한 Shield와 통합해서 DDOS을 보호한다. 그러나 두 서비스는 차이점이 극명하게 존재한다.

- CloudFront

콘텐츠 전송 네트워크라 Edge에서 이미지나 영상, 웹사이트 같은 콘텐츠를 '캐싱'하고 Edge Location에 캐싱하니 여기세어 콘텐츠를 제공한다는 것이 특징이다.

- Global Accelerator

그러나 Global Accelerator에서는 '캐싱'을 하지않고 Edge Location으로부터 모든 request는 region의 애플리케이션으로 전달된다. 따라서 TCP 또는 UDP와 같이 넓은 범위에서의 request에서 성능을 개선한다.

=> 정적 IP주소를 요구하는 HTTP 사용 케이스에 적합하다! (혹은 결정적이고 빠른 regional failover이나 좋은 성능을 요구할 때 좋다.)

 

#4 AWS Outposts - 하이브리드 클라우드용 서비스🗄️

AWS Outposts라는 흥미로운 서비스를 살펴보려고 한다. 여기서 하이브리드 클라우드 개념을 짚고 넘어가야 하는데 온프레미스 인프라를 유지하면서 클라우드 인프라도 같이 가져가는 것을 말한다.

두 개를 운영하면 두 가지 다른 유형의 API를 가지고 있기 때문에 복잡하다..

여기서 AWS Outposts는 하이브리드 클라우드를 이용하는 회사를 위해서 동일한 AWS 인프라, 서비스, API등등을 제공하는 'server racks'이다.

Outposts를 사용하면 온프레미스 시스템에 접근할 때 지연 시간이 적다는 것이다. 데이터 처리를 로컬에서 하고 데이터는 온프레미스 시스템에서 떠나지 않게 한다. (클라우드로 절대 가지 않고 데이터 센터 내에서 머뭄)

그리고 Outposts를 이용해서 아래와 같은 AWS 서비스를 이용할 수 있는데

온프레미스 시스템 인프라에 클라우드를 확장하는 좋은 방식임은 틀림없다.

 

#5 AWS WaveLength - 실시간 서비스 등으로 적은 지연 시간이 필요할 때..(5G 📱)

기본적으로 AWS 서비스를 5G 네트워크 엣지에 배포할 수 있는데 EC2, EBS 볼륨, VPC를 WaveLength 영역에 배포할 수 있다. 예를 들어 5G를 가진 통신사의 gateway를 통해서 EC2를 해당 영역에 배포할 수 있다는 것이다. 

설명을 위한 이미지

위의 그림을 참고해서 설명하자면 다음과 같다.

모바일로 접근하는 5G 유저가 WaveLength 영역에 접근할 때, 지연 시간은 매우 적다. (애플리케이션이 엣지에 배포되기 때문) 전반적으로 WaveLength는 5G 네트워크를 통해 애플리케이션의 지연 시간을 줄여준다. 예시에서 트래픽은 통신 서비스 제공자(CSP) 네트워크를 떠나지 않는다. 실제로 AWS에 도달하지 않지만 AWS로 보안 연결을 원한다면 그렇게 할 수 있다. 그 위의 region 박스가 WaveLength영역은 부모 region에 연결되어 있는 모습인데 WaveLength영역에 있는 EC2 인터페이스는 DB에 접근(예: RDS, DynamoDB..)해야 하는데 WaveLength를 사용할 때 추가 비용은 없다.

사용 사례는 스마트 도시나 ML 기반 진단,  커넥티드 카, 실시간 영상 스트리밍(zoom), AR, VR, 실시간 게임 등이 있고 이는 모두 적은 지연 시간을 요구하며 유저와 엣지 로케이션이 엄청 가까워야 하는 사례에 적합하다..!

 

#6 AWS Local Zones

Local Zone(로컬 영역)이라는 개념은 컴퓨팅 스토리지 데이터베이스 혹은 데이터베이스가 선택한 다른 서비스를 최종 유저와 가깝도록 배치해서 지연 시간에 민감한 애플리케이션을 실행하도록 한다. 

기본적으로 AWS region을 1개 이상의 로케이션 or 가용영역으로 확장해준다. = 이것이 Local Zones

그리고 EC2, RDS, ECS, EBS, 일래스티 캐시 등과 호환이 가능하다.

위의 그림을 참고하면서 설명해보겠다.

region이 있고 6개의 AZ가 기본으로 있는데 이 AZ를 더 많은 local영역(보스턴, 시카고..)에 확장할 수 있다는 것이다.

어떻게 동작할까?🤔

이미지 상에서 us-east-1 region에 2개의 AZ가 있고 보스턴에 local 영역을 정의하고 VPC를 AZ와 local영역으로 확장한다. 그러면 EC2 인스턴스를 local영역에서 실행할 수 있다.

 

#7 AWS 글로벌 애플리케이션 아키텍처 살펴보기 🖋️

 

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

1. 하나의 리전에 한 AZ, 한 EC2가 있는데 이는 설정하기에는 쉽지만 가용성과 글로벌 지연 시간이 좋지 않을 것이다.

=> region에서 멀리 떨어진 사용자가 접근하면 지연 시간은 높을 것이기 때문

2. 하나의 region에 여러 AZ가 있으면 가용성이 높지만 글로벌 지연 시간은 여전히 개선되지 않는다.

=> AZ에서 멀리 떨어진 지점에서는 지연 시간이 길 것이기 때문

3. Active-Passive(액티브 - 패시브)라고 부르는 다중 region인데 2개의 region이 있다는 뜻으로 각 region에는 하나 이상의 AZ가 있고 하나의 region에는 EC2 인스턴스가 Active되거나 애플리케이션이 Active될 것. 이 말은 즉 사용자가 어디에 있던지 Active된 region의 EC2 인스턴스에 읽고 쓸 수 있다는 뜻이다! 다른 EC2는 Passive인데 이 말은 Active region과 Passive region간의 데이터 복제가 일어나서 유저는 Passive region에서 읽을 수 있고 쓸 수는 없다.

=> Active-Passive를 사용하면 전세계의 많은 region이 있고 모두가 Passive라면 '읽기 지연 시간'을 개선할 수 있다!

     (전세계에 데이터를 복제했기 때문)

   그러나 쓰기의 경우, 여전히 중앙 region으로 가야하기 때문에 글로벌 수준에서는 쓰기 부분에선 여전히 지연 시간이 높     다. 여러 region이 있어 난이도도 높다.

4. Active-Active가 있는데 각 EC2 인스턴스가 쓰고 읽을 수가 있다. 2개의 인스턴스에서 복제가 일어나고 읽기와 쓰기 지연 시간을 개선하지만 난이도는 더 올라간다. 왜냐면 한 region에서 많은 것을 해야해서 설정하기 어렵기 때문이라고 한다. 

 

✅짤막한 개념 정리

 

CodeStar는 AWS에서 애플리케이션을 빠르게 개발, 구축 및 배포하는 데 사용된다.

Elastic Beanstalk를 사용하여 환경의 상태를 모니터링하고 확인할 수 있다.

AWS CodeCommit은 팀이 코드에 대해 더 쉽게 협업할 수 있도록 해주는 안전하고 확장성이 뛰어난 관리형 소스 제어 서비스

AWS CloudFormation은 클라우드 환경에서 AWS 및 타사 애플리케이션 리소스를 모델링하고 프로비저닝할 수 있는 공통 언어를 제공한다. 이를 통해 코드형 인프라를 배포할 수 있다.

Elastic Beanstalk는 PaaS, 서비스형 플랫폼이다. 데이터와 애플리케이션만 관리하고 AWS Elastic Beanstalk를 사용하면 개발자가 AWS 클라우드에서 애플리케이션을 더 빠르게 배포하고 관리할 수 있다.

AWS CodePipeline은 빠르고 안정적인 애플리케이션 및 인프라 업데이트를 위해 릴리스 Pipeline을 자동화하는 데 도움이 되는 완전관리형 지속적 전달 서비스이다. CodeStar는 통합 사용자 인터페이스를 통해 AWS에서 애플리케이션을 빠르게 개발, 구축 및 배포하는 데 사용된다.