인프런 커뮤니티 질문&답변

1.CloudFront는 보통 S3 버킷 앞에 많이 사용되는걸까요? 찾아보니 그런 것 같아서요! (1-2)

CloudFront는 엣지 로케이션이라는 전세계 데이터 센터 네트워크를 사용하여 콘텐츠를 사용자에게 더 빨리 배포하기위한 콘텐츠 전송 네트워크(CDN) 서비스입니다.

CloudFront는 Amazon S3, Elastic Load balancer, API Gateway, Meadiastore container, Mediapackage container 서비스를 콘텐츠 원본으로 연결할 수 있습니다.

위와 같이 5가지의 서비스와 연결되어 사용 가능하지만

질문하신 것이 주로 어떤 서비스와 연결되어 사용되는 것이 많은지에 대한 것이라면 정적 콘텐츠(이미지, 스타일 시트, JavaScript 등)를 저렴하고 내구성있게 저장할 수 있는 것이 S3이기 때문에 보통 S3 버킷 앞에 많이 사용된다고 답을 드려도 될 것 같습니다.

아래는 CloudFront의 사용사례입니다.

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/IntroductionUseCases.html

2.AWS Elastic Beanstalk이 운영 오버헤드가 많이 발생한다는 것을 어떤식으로 알 수가 있는거죠? 그냥 단순히 외워야 할까요..? 그리고 AWS Elastic Beanstalk에서 Lambda 함수를 직접 실행하는건 불가능한 게 맞나요? (1-6)

Lambda 함수라는 의미는 Lambda라는 서버리스 컴퓨팅 시스템에서 함수(Java, Python등의 프르그래밍 코드)를 실행할 수 있다는 의미입니다.

Elastic Beanstalk는 AWS에서 인프라를 배포하고 관리를 해주는 서비스 입니다. 이 인프라에서 서버는 EC2를 사용합니다. 이 서비스도 Java등의 프로그래밍 코드를 실행할 수 있습니다.

따라서 질문해 주신 Elastic Beanstalk에서 함수(코드)를 실행 할 수 있습니다.

두 서비스 모두 코드를 실행할 수 있는 컴퓨팅 서비스 입니다만 큰 차이점이 AWS에서 완전히 관리를 하는 서버리스(Lambda)냐 사용자의 일정부분 관리가 들어가는 PaaS,Platform-as-a-service(Elastic Beanstalk)이냐의 차이입니다.

운영 오버헤드가 최소화 되려면 서비스가 자동화가 되어 사람의 관리가 적어야 하겠죠. AWS에서 서비스를 구축하고 운영해보면 Lambda에 비해 Elastic Beanstalk이 사용자가 관리하고 설정해 주어야 하는 부분이 많습니다. 그렇다면 Lambda에비해 Elastic Beanstalk이 상대적으로 운영오버헤드가 많이 발생할 것입니다.

3.변경 사항이 발생하는 즉시 새 콘 텐츠를 반환하는 강력한 일관성이라는 말이 결국에는 S3보다 EFS가 더 빠르다는 말씀이신거죠? (1-13)

질문은 여러 대의 EC2에 연결되는 공유스토리지 솔루션입니다. 만일 여러 대의 EC2가 각각의 스토리지에 콘텐츠를 업로드하면 콘텐츠가 업데이트 되었을 때 제때에 반영이 되지 못하여 어느 사용자는 최신 콘텐츠를 보고 어느 사용자는 과거의 콘텐츠를 보는 상황이 발생할 수 있을겁니다. 이러한 상황 발생없이 동일한 데이터를 볼 수 있게 하는 것을 일관성이라고 합니다.

따라서 속도와도 관련이 있겠지만 어떤 스토리지를 구성하는 가도 연관이 있습니다. 예를들어 개별 EC2에 EBS를 각각 연결하고 개별로 콘텐츠를 관리하면 개별 EBS데이터를 동기화 하거나 최신 데이터를 서로 확인해야 하기 때문에 일관성이 떨어질 수 있을 겁니다. 따라서 단일 공유 스토리지인 EFS를 사용을 하는 것이 더욱 적절 합니다.

질문주신 부분에 대한 답으로 디스크 퍼포먼스는 EFS가 더 빠릅니다. S3는 AWS에서 가장 저렴한 스토리지입니다. 가격이 제일 싼데 다른 서비스보다 속도도 빠를 수 없을 겁니다.

아래는 S3, EFS, EBS 스토리지 비교를 잘 해놓아서 링크를 남겨드립니다.

https://bluexp.netapp.com/blog/ebs-efs-amazons3-best-cloud-storage-system

4.CloudFront에서 고 가용성을 위해 오리진 그룹을 통한 장애 조치 기능을 제공하기에 Route 53을 사용할 필요 없다고 나와 있는데, 그럼, CloudFront가 없으면 해당 기능을 적용하기 위해서는 Route53을 무조건 사용해야 하나요? (1-16)

CloudFront와 Route53은 둘 다 장애조치 기능이 있지만 목적이 다른 서비스입니다.

질문하신 것처럼 오리진(S3버켓의 Primary와 Secondary구성)장애 조치기능만을 위한 것이라면 CloudFront이외에 Route53의 DNS장애조치 기능으로 구현이 가능할 것입니다.

https://aws.amazon.com/ko/blogs/tech/improve-web-application-availability-with-cloudfront-and-route53-hybrid-origin-failover/

5.콘텐츠를 가능한 한 빨리 전 세계 사용자에게 제공해야 되기 때문에, CloudFront가 더 적합한 솔루션인건가요? Amazon Route 53 지리적 위치 라우팅 정책도 해당 기능이 가능하는지만, CloudFront가 더 적합한거죠? (1-19)

네 맞습니다. 질문은 “콘텐츠를 가능한 한 빨리 전 세계 사용자에게 제공” 하는 CDN 서비스를 물어본 것입니다.

CloudFront 사용자와 가까운 데이터 센터에 콘텐츠를 캐싱(저장)하여 제공하는 것입니다.

질문에서 두개의 리전에 서버를 배포하고 Route 53 지리적 라우팅 정책을 사용할 경우 하나의 리전에 서버를 배포하여 사용하는 것보다 두개의 리전에서 가까운 사용자의 경우에는 속도가 더 빨라질 것입니다.

하지만 CloudFront는 전세계의 데이터센터에 콘텐츠를 캐싱하여 접속하기 때문에 Route 53보다 두개의 리전이 아닌 전세계 사용자를 대상으로 한다면 더 적합한 솔루션이 됩니다.

6.CloudFront는 항상 Public에 있는 것이 맞죠? (2-5)

최종 사용자에게 콘텐츠를 빠르게 전달하는 넷플릭스나 유트브 같은 CDN서비스이기 때문에 서비스의 목적상 Public에 있는 것이 맞습니다.

7.정적 자산을 CloudFront로 이동할 수 없는건 이해가 되는데, D에서 정적 자산을 Amazon S3로 이동 Auto Scaling이 활성화된 Amazon Elastic Container Service(Amazon ECS) 컨테이너로 애플리케이션 이동 데이터베이스를 Amazon RDS로 이동하여 다중 AZ 배포가 맞는게 이해가 안됩니다. 문제가 컨테이너랑 관련이 있는지요? (3-20)

질문은 컨테이너에 대한 것이 아닌 신용카드 결제처리 앱을 위한 3티어 아티텍처의 고가용성 설계에 대한 것입니다.

아래의 목적에 맞는 아키텍처를 찾아야 합니다.

• 1티어 : 프런트엔드 계층 - 정적 웹페이지 구성

• 2티어: 애플리케이션 계층 – 장기실행 프로세스

• 3티어: 데이터베이스 계층 - MySQL

위의 3개의 티어를 목적에 맞게 고가용성 설계를 해야 합니다. 

• 정적자산(정적웹페이지)를 S3에서 구현 (S3는 고가용성을 기본으로 지원)

• 장기실행 애플리케이션은 EC2를 사용하거나 ECS를 사용할 수 있지만 지문에서 고가용성 설계는 Autoscaling 구성하는 ECS.

• MySQL인 RDS를 지원하는 서비스는 Amazon RDS를 사용하고 고가용성을 위해 다중 AZ를 사용.

8.다른 가용 영역에 다른 EC2 인스턴스를 오리진 그룹의 일부로 구성한다는 말이 이해가 되지 않습니다 이 말은 오리진 그룹에 속한 EC2 인스턴스가 여러 가용 영역에 분산되어 있는걸까요? . (3-27)

네, 질문하신 것이 맞습니다. 고가용성을 위해 서버를 여러 가용영역에 분산한다는 것입니다.

9.D에서 Amazon Route 53 가중 라우팅 정책 생성 리전에서 사용자 수가 가장 많은 EC2 인스턴스에 가장 높은 가중치를 부여하도록 라우팅 정책을 구성이 아니라 가장 낮은 가중치를 부여하도록 하면 해당 질문에 맞는 답일까요? (3-30)

단순히 질문에 대한 답은 맞지만 Route53 가중치 기반이 적절한 솔루션인지는 생각해 보아야 할 듯합니다.

질문에서는 네트워크 지연시간을 최적화하는 것입니다. 이 방법은 네트워크 아키텍처에 대한 설계를 물어보고 있습니다. 사용자와 서버나 콘텐츠와의 라우팅 경로를 최적화 한다 거나 짧은 구간을 사용해야 할 것입니다.

물론 사용자가 서버에 접속하는 것을 분산시켜 서버의 부하를 줄여주는 것도 지연시간을 줄이는 방법 중 하나가 될 수는 있을 것입니다.

Global Accelerator는 네트워크 라우팅 경로를 최적화 하는 것이고 CloudFront는 사용자가 가까운 엣지로케이션으로 접속하도록 하는 것이니 이것도 네트워크 지연시간을 최소화 하는 솔루션입니다.

Route53 가중치 기반은 사용자 트래픽을 어떤 서버로 보낼지 분산하는 서비스인데 게임 애플리케이션같은 트래픽 예측이 어려운 경우에 어떤 기준으로 가중치를 둬야 하는지 쉽지 않을 것 같습니다.

아래는 가중치 기반 라우팅에 대한 설명입니다.

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-policy-weighted.html

안녕하세요, 인프런 AI 인턴이에요.

1. CloudFront는 indeed S3 버킷 앞에 많이 사용되는 서비스입니다. CloudFront는 전 세계에 분산된 엣지로케이션에 콘텐츠를 캐싱하여 보다 빠른 전송 속도와 낮은 대기 시간을 지원해줍니다.

2. AWS Elastic Beanstalk은 관리 형 플랫폼으로, 배포와 운영을 간소화하는데 도움을 줍니다. 오버헤드는 플랫폼에서 제공하는 기능을 사용하는 것이므로 외우지 않아도 됩니다. Elastic Beanstalk에서 Lambda 함수를 직접 실행하는 것은 지원하지 않습니다.

3. “변경 사항이 발생하는 즉시 새 콘텐츠를 반환하는 강력한 일관성”이라는 말은 EFS가 변경 사항을 즉시 반영하여 더 빠르게 콘텐츠를 제공할 수 있다는 의미입니다. S3와 EFS는 각각 다른 용도로 사용되는데, S3는 객체 저장 및 정적 웹 사이트 호스팅에, EFS는 파일 시스템을 요구하는 애플리케이션에 사용됩니다.

4. CloudFront에서 오리진 그룹을 통한 장애 조치 기능을 제공한다면, Route 53을 사용할 필요는 없습니다. CloudFront는 분산된 오리진 서버 그룹에서 콘텐츠를 검색하기 때문에 고 가용성을 보장할 수 있습니다.

5. 말씀하신대로, CloudFront는 콘텐츠를 빠르게 전 세계 사용자에게 제공하기 위한 서비스입니다. CloudFront는 엣지 로케이션에 콘텐츠를 캐싱하고, 가장 가까운 엣지로케이션을 통해 사용자에게 전달하여 최적의 성능을 제공합니다.

더 궁금한 점이 있으시면 언제든지 물어보세요! 좋은 하루 되세요~요.