AWS SAA-C03 문제 풀이 1번 ~ 8번

업데이트 중입니다..

보시는 분의 편의를 위해 한글로 번역하여(구글번역) 풀이합니다.

1번

풀이 : 글로벌 서비스의 경우 상황에 따라 해답이 매우 다양합니다. 회사의 서비스를 고객에게 전달한다면 아마 가장 먼저 떠오르는 것이 CDN 즉, CloudFront 일 것입니다. CloudFront는 엣지로케이션에 서비스를 배포하여 고객이 더 빠르게 서비스를 이용할 수 있도록 합니다.
 하루 평균 500GB의 많은 데이터를 처리하지만 고속 인터넷 연결이 되어있기 때문에 추가 장비가 필요하지 않습니다. 만약 인터넷 속도가 느리다면 AWS의 Snow 시리즈를 이용해 AWS의 실물장비로 자료를 옮기고 datacenter로 이동하는 것이 더 빠를 수 있습니다. 
 S3는 기본적으로 글로벌 서비스입니다. 오브젝트 스토리지 특성상 파일에 주소가 할당되어 서울리전에 있는 버킷에 있는 자료에 전세계 어디서든 접근하는 것이 가능합니다. 다만 해외에서는 속도가 매우 느릴 것입니다. 따라서 AWS는 S3 버킷을 여러 리전에 복제하는 기능을 지원합니다. 다만 CRR(Cross Resion Replication)을 이용하는 것은 빠르지 않습니다.  AWS는 이를 보완하기 위해 CloudFront를 이용하여 글로벌 환경에서 더 신속하게 S3 버킷을 이용할 수 있는 Transfer Acceleration을 서비스하고 있습니다. 리전 별로 버킷을 복제할 필요도 없어 운영 편의성도 가져갈 수 있습니다.

따라서 답은 A가 됩니다.

물론, 이 시험은 SAA라 단순하게 복잡성 최소화만 바라보고 A로 접근할 수도 있습니다. 다른 모든 문항과 다르게 A는 기능을 활성화하는 것 만으로도 요구사항을 모두 충족하며 B, C 그리고 D 모두 "가능한 빨리"와 "복잡성 최소화"와 거리가 멀어 A로 답을 빠르게 찾아갈 수 있습니다.

2번

Athena(아테나)는 s3와 사용하는 가장 쉽고 편리한 대화형 쿼리 서비스입니다. S3에 저장되어있는 정보를 쿼리 형태로 분석할 때 사용합니다. 너무 자주 등장하는 조합이라 사용해보시지 않았더라도 기억하고 계시면 좋을 것 같습니다. Athena는 다양한 쿼리를 지원하는데 Json형식도 당연히 지원합니다. 문제에서는 최소한의 운영 오버헤드를 언급했으므로 가장 사람 손이 덜 가도록 아키텍처를 구상하면됩니다. 이미 S3를 사용하고 있으며 Athena만 추가하면 모든 요구사항을 달성할 수 있습니다.

따라서 답은 C 입니다.

3번

실제 운영환경에서는 어카운트를 매우 많이 사용합니다. 페이어를 위해 마스터를 하나 두고 실제 사용을 위해 유저를 분리하거나 어카운트를 여러개 붙여서 사용하는데요, 그때 유용한 서비스가 Organizations입니다. 여기서는 전체적인 어카운트의 거버넌스 관리를 위한 다양한 설정이 가능합니다. 
마스터 계정에 S3 버킷이 여러 개가 있고 그 중 하나는 매우 보안적인 사항으로 인가를 따로 받거나 접근 권한을 부여받은 유저나 계정에만 허락될 수 있도록 구성하고자 한다면, 엔터프라이즈 환경에서 해당 버킷의 접근 권한에 대해 유저마다 또는 어카운트마다 설정하는 것은 매우 번거로울 것입니다. 이때 Organizations의 전역 조건 키를 사용하면 다소 편리합니다. S3의 버킷 정책에서 리소스 기반으로 aws:PrincipalOrgID를 갖고 있는 계정만 엑세스를 허용하게 설정하면, 그 전역 키를 갖고 있는 조직에 속한 유저 또는 계정은 접근할 수 있도록 구성할 수 있습니다.

따라서 답은 A 입니다.

B의 경우, A는 이미 조직 ID로 S3 버킷에 대해 접근할 수 있는 사용자를 구별해낸 반면, 새로운 OU를 만들어야하므로 추가적인 운영 관리 요소가 증가하게 됩니다. 따라서 오답으로 분류됩니다.

4번

S3는 기본적으로 인터넷을 통해 접근합니다. 따라서 프라이빗 서브넷에 존재하는 인스턴스에서는 곧바로 접근할 수 없습니다. 이때 인스턴스는 여전히 프라이빗 서브넷에 존재하면서 S3에 접근하는 방법은 2가지가 있습니다. 하나는 "게이트웨이 엔드포인트"이고 다른 하나는 "인터페이스 엔드포인트"입니다. 이 둘은 여러 차이가 있습니다만, 가장 큰 차이로는 게이트웨이 엔드포인트는 라우팅을 통해 연결 가능하고 인터페이스 엔드포인트는 서비스용 네트워크 인터페이스를 새로 만들어 연결해준다는 것입니다. 즉, 게이트웨이 엔드포인트가 사용하기 쉽습니다. 게이트웨이 엔드포인트는 S3와 DynamoDB에서 사용되며 인터페이스는 S3를 포함하여 다양한 서비스에서 사용할 수 있습니다. S3 게이트웨이 엔드포인트는 매우 쉬우면서도 유용한 best practice 중 하나입니다.

답은 A 입니다.

5번

잘 읽어보면 조금 실소가 나오는 구성입니다. ALB를 앞에 배치한 후 WAS 서버를 2개 두고 데이터를 WAS서버에 각각 저장하면 당연히 새로고침 할 때마다 보이는 정보가 다르겠죠.. DB라면 하나의 타겟을 두면 되겠지만 여긴 블록스토리지에 저장 중이라고하니 공유할 수 있는 파일 시스템을 붙여주면 해결될 것 같습니다.

따라서 답은 C 입니다.

A가 아닌 이유는 두 스토리지 간에 계속 sync를 맞춰주기 위해 부수적인 작업이 필요하게 됩니다. EBS 공유를 사용한다 하더라도 리전이나 포멧 등 제약사항이 많으므로 본 문항에서는 EFS(NFS)를 사용하는 것보다 큰 실익이 없습니다.

6번

온프레미스에 있는 비디오 파일이 총 70TB가 있는데 S3로 마이그레이션을 해야합니다. 하지만 회사의 인터넷 회선이 100Mbps라면 어떻게 할까요.. 생각만해도 답답합니다. 이런 상황에서는 인터넷선으로 데이터를 보내는 것보다 스토리지에 담에 택배로 보내서 연결시키는게 빠를겁니다. 다행이도 AWS에는 이러한 서비스가 있습니다. AWS 스노우 패밀리입니다. 이 중 snow ball을 사용하면 택배로 장비를 받아서 랜 포트 꼽아 다이렉트로 파일을 넣은 후 AWS로 보내 S3에 모든 내용을 저장하도록 할 수 있습니다.

따라서 답은 B입니다.

7번

마이크로서비스 아키텍처에서 주로 사용하는 pub/sub 패턴의 경우 한 서비스가 이벤트를 퍼블리싱하면 그것을 구독하는 다른 서비스들이 정보를 확인하고 필요한 후처리를 하게 됩니다. 이 때 갑자기 발행되는 메세지가 초당 10만개까지 증가한다면 순간적으로 확장될 수 있는 메세징 서비스를 이용하는 것이 좋을겁니다. SQS와 SNS는 마이크로서비스 아키텍쳐에서 이러한 역할을 하기 위해 존재합니다. SNS에서 메세지를 발행하고 SQS에서 구독하도록 구성하면 솔루션이 분리되며 확장성도 좋아집니다. SNS에서 메세지를 발행하면 여러 SQS에서 각각 필요한 정보만을 구독하여 붙어있는 어플리케이션에게 필요한 작업을 지시하도록 구성하여 급증하는 트래픽에도 적정히 메세지를 처리하게 할 수 있습니다.

따라서 답은 D 입니다.

 

 

Kinesis는 실시간 처리를 위한 서비스이므로 본 문항에서 요구하는 pub/sub 구조와는 조금 사용사례가 다릅니다.

8번

7번 문제와 마찬가지로 분산형 아키텍쳐와 관련됩니다. 마찬가지로 분산형 아키텍쳐에서 각 서비스가 필요한 작업을 하기 위해 SQS에서 필요한 작업을 큐로 구성하여 큐에 메세지가 다량 적제될 때 이에 맞춰 스케일링되는 아키텍처로 구성해야 합니다. 복원력과 확장성을 최대화한다는 것은 스케줄이 아닌 트래픽에 의존하여 스케일링한다고 이해하면 되겠습니다.

따라서 답은 B 입니다.

CloudTrail은 이용자의 사용 추적과 관련되므로 분산 아키텍쳐와 거리가 멀어 보입니다. 이벤트브릿지를 사용하는 것은 CloudWatch에서 관찰될 수 있는 log처럼 상태를 전달하는 목적이 강합니다. 따라서 어플리케이션에 메세지를 전달하는 것이 필요하다면 SQS가 더 적정한 서비스가 됩니다.