[AWS] AWS Solutions Architect Associate (1)
AWS SAA(AWS Solutions Architect Associate) 문제 풀이
Question #1
여러 대륙에 걸쳐 있는 도시의 온도, 습도, 기압에 대한 데이터를 수집하는 회사가 있다.
회사는 평균적으로 각 사이트에서 매일 500GB의 데이터를 수집하며, 각 사이트는 고속 인터넷이 연결되어있다.
해당 회사는 이러한 모든 글로벌 사이트의 데이터를 가능한 한 빨리 단일 Amazon S3 버킷에 집계하려고 하며, 솔루션의 운영 복잡성은 최소화해야 한다.
해당 사항에 충족하는 솔루션은?
지문
- 대상 S3 버킷에서 S3 Transfer Acceleration을 켭니다. 멀티파트 업로드를 사용하여 사이트 데이터를 대상 S3 버킷에 직접 업로드합니다.
- 각 사이트의 데이터를 가장 가까운 리전의 S3 버킷으로 업로드합니다. S3 크로스 리전 복제를 사용하여 객체를 대상 S3 버킷으로 복사합니다. 그런 다음 원본 S3 버킷에서 데이터를 제거합니다.
- AWS Snowball Edge Storage Optimized 장치 작업을 매일 예약하여 각 사이트에서 가장 가까운 리전으로 데이터를 전송합니다. S3 크로스 리전 복제를 사용하여 객체를 대상 S3 버킷에 복사합니다.
- 각 사이트의 데이터를 가장 가까운 리전의 Amazon EC2 인스턴스로 업로드합니다. Amazon Elastic Block Store(Amazon EBS) 볼륨에 데이터를 저장합니다. 정기적으로 EBS 스냅샷을 찍어 대상 S3 버킷이 있는 리전에 복사합니다. 해당 리전에서 EBS 볼륨을 복원합니다.
풀이
문제 풀이 접기/펼치기
엣지 로케이션을 활용하여 S3 버킷 간의 장거리 파일 전송을 빠르고 쉬우며 안전하게 전송할 수 있는 버킷 수준의 기능이며, 전 세계에 정시적으로 수 기가바이트에서 수 테라바이트의 데이터를 전송할 경우에 사용할 수 있다.
- S3 Transfer Acceleration
- 엣지 로케이션을 활용하여 S3 버킷 간의 장거리 파일 전송을 빠르고 쉬우며 안전하게 전송할 수 있는 버킷 수준의 기능이다.
- 전 세계에서 S3 버킷으로 전송 속도를 최적화하도록 설계되었으며, 엣지 로케이션에 도착한 데이터는 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅된다.
- 기술적으로 가능한 솔루션이지만, 비용이 많이 들고, 프로세스가 느리며 복잡하다.
- Snowball 서비스를 별도로 비용을 들여 사용해야 하며, Snowball 서비스는 테라바이트 규모의 데이터를 한 번 업로드하도록 설계되어 있기 때문에, 소규모 전송에는 적합하지 않다.
- 기술적으로 가능한 솔루션이지만, EC2 인스턴스와 EBS 서비스 사용 등의 불필요한 비용이 많이 들며, 프로세스가 지나치다.
Question #2
자체 애플리케이션의 로그 파일을 분석할 수 있는 기능이 필요하다.
로그는 Amazon S3 버킷에 JSON 형식으로 저장되며, 쿼리는 간단하게 주문(대화)형으로 실행된다.
솔루션 아키텍트는 기존 아키텍처를 최소한으로 변경하여 분석을 수행해야 한다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하기 위해 무엇을 해야 하는가?
지문
- Amazon Redshift를 사용하여 모든 콘텐츠를 한곳에 로드하고 필요에 따라 SQL 쿼리를 실행합니다.
- Amazon CloudWatch Logs를 사용하여 로그를 저장합니다. 필요에 따라 Amazon CloudWatch 콘솔에서 SQL 쿼리를 실행합니다.
- 필요에 따라 Amazon Athena를 Amazon S3와 직접 함께 사용하여 쿼리를 실행합니다.
- AWS Glue를 사용하여 로그를 카탈로그화합니다. Amazon EMR에서 일시적인 Apache Spark 클러스터를 사용하여 필요에 따라 SQL 쿼리를 실행합니다.
풀이
문제 풀이 접기/펼치기
- Armazon Red thinshift는 복잡한 쿼리를 사용하는 경우이다.
- 주문(대화)형으로 실행되는 쿼리이므로 CloudWatch Logs를 사용하여 로그를 저장할 필요가 없다.
- S3에 있는 데이터를 직접 간편하게 분석할 수 있는 대화형 쿼리 서비스로 S3에 저장된 데이터를 지정하고 표준 SQL을 사용하여 임시 쿼리를 실행하여 몇 초 안에 결과를 얻을 수 있다.
- 불필요하게 많은 서비스를 사용한다.
Question #3
AWS Organizations를 사용하여 여러 부서의 여러 AWS 계정을 관리한다,
관리 계정에는 프로젝트 보고서가 들어있는 Amazon S3 버킷이 있다,
이 회사는 이 S3 버킷에 대한 액세스를 AWS Organizations의 조직 내 계정 사용자로만 제한하려고 한다.
어떤 솔루션이 운영 오버헤드를 최소화하면서 이러한 요구 사항을 충족하는다?
지문
- 조직 ID에 대한 참조가 있는 aws:PrincipalOrgID 글로벌 조건 키를 S3 버킷 정책에 추가합니다.
- 각 부서에 대한 조직 단위(OU)를 만듭니다. S3 버킷 정책에 aws:PrincipalOrgPaths 글로벌 조건 키를 추가합니다.
- AWS CloudTrail을 사용하여 CreateAccount, InviteAccountToOrganization, LeaveOrganization 및 RemoveAccountFromOrganization 이벤트를 모니터링합니다. 이에 따라 S3 버킷 정책을 업데이트합니다.
- S3 버킷에 액세스해야 하는 각 사용자를 태그합니다. aws:PrincipalTag 글로벌 조건 키를 S3 버킷 정책에 추가합니다.
풀이
문제 풀이 접기/펼치기
aws:PrincipalOrgID조건 키를 사용하면 조직 ID를 기반으로 액세스를 제한하여 AWS 조직 내 계정의 주체(사용자, 역할 등)만 S3 버킷에 액세스가 가능하다.- 각 부서에 대한 조직 단위(OU)를 만들고, 그에 따른 S3 버킷 정책에
aws:PrincipalOrgPaths글로벌 조건 키를 추가해야 하는 등의 불필요한 작업이 존재한다. - CloudTrail의 경우, API 이벤트만 기혹하기 때문에 S3 버킷에 대한 사용자 액세스를 방지할 수 없다.
- 각 사용자에게 수동으로 태그를 지정하는 옵션으로, 수동 태그 지정 업데이트도 필요하며, 많은 사용자가 있는 대규모 조직에는 확장이 불가능할 수 있다.
Question #4
애플리케이션은 VPC의 Amazon EC2 인스턴스에서 실행된다.
애플리케이션은 Amazon S3 버킷에 저장된 로그를 처리한다.
EC2 인스턴스는 인터넷에 연결하지 않고도 S3 버킷에 액세스해야 한다.
어떤 솔루션이 Amazon S3에 프라이빗 네트워크 연결을 제공하는가?
지문
- S3 버킷에 대한 게이트웨이 VPC 엔드포인트를 생성합니다.
- 로그를 Amazon CloudWatch Logs로 스트리밍합니다. 로그를 S3 버킷으로 내보냅니다.
- S3 액세스를 허용하기 위해 Amazon EC2에 인스턴스 프로필을 생성합니다.
- S3 엔드포인트에 액세스하기 위한 개인 링크가 있는 Amazon API Gateway API를 생성합니다.
풀이
문제 풀이 접기/펼치기
- VPC 엔드포인트를 사용하면 공용 인터넷 대신 개인 네트워크를 사용하여 비용에 대한 부담 없이 AWS 서비스에 연결할 수 있다.
- CloudWatch Logs는 로그를 수집하고 모니터링할 뿐, 프라이빗 연결에 대한 매커니즘과 상관이 없다.
- 인스턴스 프로필은 EC2 인스턴스에 IAM 역할을 할당하는 데에 사용되며, 네트워크 연결과는 관련이 없다.
- 프록시와 같은 API 게이트웨이는 외부 사이트에서 네트워크를 수신하고 AWS Lamda, EC2, Load Balancing 제품 등 공개적으로 사용 가능한 HTTPS 기반 엔드포인트로 요청을 전달하지만, S3는 해당되지 않는다.
Question #5
한 회사에서 사용자가 업로드한 문서를 Amazon EBS 볼륨에 저장하는 단일 Amazon EC2 인스턴스를 사용하여 AWS에서 웹 애플리케이션을 호스팅하고 있다.
더 나은 확장성과 가용성을 위해 회사는 아키텍처를 복제하고 다른 가용성 영역에 두 번째 EC2 인스턴스와 EBS 볼륨을 만들어 둘 다 애플리케이션 로드 밸런서 뒤에 배치했다.
이 변경을 완료한 후, 사용자들은 웹 사이트를 새로고침할 때마다 문서의 하위 집합 중 하나 또는 다른 하나를 볼 수 있지만, 모든 문서를 동시에 볼 수 없다고 보고했다.
솔루션 아키텍트는 사용자가 모든 문서를 한 번 에 볼 수 있도록 하기 위해 무엇을 제안해야 하는가?
지문
- 두 EBS 볼륨 모두에 모든 문서가 포함되도록 데이터를 복사합니다.
- 사용자를 문서가 있는 서버로 안내하도록 애플리케이션 로드 밸런서를 구성합니다.
- 두 EBS 볼륨의 데이터를 Amazon EFS로 복사합니다. 새 문서를 Amazon EFS에 저장하도록 애플리케이션을 수정합니다.
- 두 서버 모두에 요청을 보내도록 애플리케이션 로드 밸런서를 구성합니다. 올바른 서버에서 각 문서를 반환합니다.
풀이
문제 풀이 접기/펼치기
- EBS 볼륨 간에 동기화가 필요하기 떄문에 복잡하며, 확장이 불가능하다.
- Load Balancer가 사용자를 하나의 인스턴스로만 안내하는 경우에는 확장이 불가능하다.
- EFS는 EBS와 달리 여러 인스턴스에 연결될 수 있으며, 두 인스턴스가 하나의 EFS 데이터 저장소를 가리키므로 사용자는 두 데이터를 모두 볼 수 있다.
- 애플리케이션 로드 밸런서는 서버 간의 작업 부하를 분산하도록 설계되었기 때문에 두 서버에 요청을 보내는 것을 지원하지 않으며, ALB는 두 서버의 문서를 결합하여 반환할 수 없다.
Question #6
한 회사가 NFS를 사용하여 온프레미스 네트워크 연결 스토리지에 대용량 비디오 파일을 저장한다.
각 비디오 파일의 크기는 1MB에서 500GB까지이며, 총 스토리지는 70TB로 더이상 증가하지 않는다.
회사는 비디오 파일을 Amazon S3로 마이그레이션하기로 결정했으며, 가능한 한 빨리 비디오 파일을 마이그레이션해야 하고 가능한 한 최소한의 네트워크 대역폭을 사용해야 한다.
어떤 솔루션이 이러한 요구 사항을 충족하는가?
지문
- S3 버킷을 만듭니다. S3 버킷에 쓸 수 있는 권한이 있는 IAM 역할을 만듭니다. AWS CLI를 사용하여 모든 파일을 로컬로 S3 버킷에 복사합니다.
- AWS Snowball Edge 작업을 만듭니다. 온프레미스에서 Snowball Edge 장치를 받습니다. Snowball Edge 클라이언트를 사용하여 데이터를 장치로 전송합니다. AWS가 Amazon S3로 데이터를 가져올 수 있도록 장치를 반환합니다.
- 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 서비스 엔드포인트를 만듭니다. S3 버킷을 만듭니다. S3 파일 게이트웨이에 새 NFS 파일 공유를 만듭니다. 새 파일 공유를 S3 버킷으로 지정합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.
- 온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정합니다. 온프레미스에 S3 파일 게이트웨이를 배포합니다. S3 파일 게이트웨이에 연결할 퍼블릭 가상 인터페이스(VIF)를 만듭니다. S3 버킷을 만듭니다. S3 파일 게이트웨이에 새 NFS 파일 공유를 만듭니다. 새 파일 공유를 S3 버킷으로 지정합니다. 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송합니다.
풀이
문제 풀이 접기/펼치기
- 가능한 한 빠르게 완료할 수 있지만, 많은 대역폭을 사용하게 된다.
AWS Snowball Edge는 최소한의 네트워크 대역폭 사용으로 대용량 데이터 세트(테라바이트 또는 페타바이트)를 전송해야 하는 시나리오를 위해 특별히 설계되었으며, 70TB의 비디오 파일과 같은 일회성 대규모 마이그레이션에 이상적이다.
지속적이고 소규모의 데이터 전송의 경우, S3 File Gateway 또는 AWS DataSync와 같은 솔루션이 더 적합할 수 있다.
- AWS Snowball Edge
- AWS Snowball Edge는 일부 AWS 기능을 위한 온보드 스토리지 및 컴퓨팅 성능을 갖춘 Snowball 디바이스의 한 유형이다.
- 각 Snowball 디바이스에는 인터넷보다 더 빠르게 데이터를 전송할 수 있으며, 이 전송은 리전 운송 업체를 통해 디바이스의 데이터를 운송하는 방식으로 이루어진다.
- 전송 속도가 최대 100Gbit/초인 네트워크 어댑터로, 저장 데이터와 물리적으로 전송 중인 데이터를 보호하기 위해 암호화가 실행된다.
- 로컬 환경과 Amazon S3 간에 데이터를 가져오거나 내보댈 수 있으며, 인터넷을 사용하지 않고도 하나 이상의 디바이스로 데이터를 물리적으로 전송할 수 있다.
- 가능한 한 빠르게 완료할 수 있지만, 많은 대역폭을 사용하게 된다.
- 온프레미스 네트워크와 AWS 간에 AWS Direct Connect 연결을 설정하는 과정에서 시간이 오래 걸린다.
Question #7
어느 회사에 수신 메세지를 수집하는 애플리케이션이 있다.
수십 개의 다른 애플리케이션과 마이크로서비스가 이 메시지를 빠르게 소비하는데, 메시지 수는 크게 달리지며 때로는 초당 100,000개로 갑자기 증가한다.
이 회사는 솔루션을 분리하고 확장성을 높이려고 하는데, 이러한 요구 사항에 충족하는 솔루션은?
지문
- Amazon Kinesis Data Analytics에 메시지를 유지합니다. 소비자 애플리케이션을 구성하여 메시지를 읽고 처리합니다.
- CPU 메트릭에 따라 EC2 인스턴스 수를 확장하기 위해 Auto Scaling 그룹의 Amazon EC2 인스턴스에 수집 애플리케이션을 배포합니다.
- 단일 샤드로 Amazon Kinesis Data Streams에 메시지를 씁니다. AWS Lambda 함수를 사용하여 메시지를 사전 처리하고 Amazon DynamoDB에 저장합니다. 소비자 애플리케이션을 구성하여 DynamoDB에서 읽어 메시지를 처리합니다.
- 여러 Amazon Simple Queue Service(Amazon SOS) 구독이 있는 Amazon Simple Notification Service(Amazon SNS) 주제에 메시지를 게시합니다. 소비자 애플리케이션을 구성하여 대기열에서 메시지를 처리합니다.
풀이
문제 풀이 접기/펼치기
- Amazon Kinesis Data Analytics는 분석 목적으로 사용되며 Kinesis Data Stream이나 Kinesis Data FireHose 또는 MSK(Apache Kafka용 관리형 스트림)에서 데이터를 가져와서 분석하는 서비스로, 메시지를 소비하여 애플리케이션으로 보낼 수 없다.
- Auto Scaling 그룹은 CPU 메트릭을 확인하여 EC2를 시작하는 데 시간이 필요하고 메시지가 크게 다르기 때문에 잘 확장되지 않으며, 확장하는 동안 서버가 잠시 다운될 수 있다.
- Amazon Kinesis Data Streams는 해당 경우를 샤드를 늘려 처리할 수 있지만, 단일 샤드는 늘려서는 안 된다.
Amason SQS와 Amazon SNS는 확장이 가능랃고 분리된 아키텍처를 제공하며, Amazon SNS는 수집 애플리케이션이 여러 구독자에게 메시지를 브로드케스트할 수 있도록 하는 게시-구독 메시징 서비스이다.
SQS는 SNS 토픽의 구독자 역할을 하며 각 소비자 애플리케이션에 대해 별도의 메시지 대기열을 만든다.
이를 통해 메시지는 대기열에 분산되어 생산자와 소비자를 분리마혀, SQS 대기열은 소비자 애플리케이션이 처리할 수 있을 때까지 메시지를 저장하여 메시지 볼륨이 갑자기 급증하는 것을 수용한다.
- Amazon Simple Queue Service
- Amazon SQS 대기열에 메시지를 보내고 받을 수 있는 사람을 제어할 수 있으며, Amazon SQS 관리형 서버 측 암호화(SSE)를 사용하거나 AWS KMS에서 관리되는 사용자 지정 SSE키를 사용하여 대기열에 있는 메시지의 콘텐츠를 보호함으로써 민감한 데이터를 전송하도록 선택할 수 있다.
- 메시지의 안전을 위해 Amazon SQS는 메시지를 여러 서버에 저장하며, 표준 대기열은 최소 1회 메시지 전송을 지원하고, FIFO 대기열은 정확히 1회 메시지 처리 및 높은 처리량 모드를 지원한다.
- Amazon SQS는 버퍼링된 요청을 각각 독립적으로 처리하여 프로비저닝 지침 없이도 로드 증가 또는 급증을 처리하기 위해 투명하게 확장할 수 있다.
- Amazon SQS는 처리 중에 메시지를 잠그므로 여러 생산자와 소비자가 동시에 메시지를 전송 및 수신할 수 있다.
Question #8
한 회사가 분산 애플리케이션을 AWS로 마이그레이션하고 있으며, 이 애플리케이션은 가변적인 워크로드를 처리한다.
레거시 플랫폼은 여러 컴퓨팅 노드에서 작업을 조정하는 기본 서버로 구성되며, 이 회사는 복원성과 확장성울 극대화하는 솔루션으로 애플리케이션을 현대화하려고 한다.
솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 어떻게 아키텍처를 설계해야 하는가?
지문
- Amazon Simple Queue Service(Amazon SQS) 대기열을 작업의 대상으로 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현합니다. 예약된 스케일링을 사용하도록 EC2 Auto Scaling을 구성합니다.
- Amazon Simple Queue Service(Amazon SQS) 대기열을 작업의 대상으로 구성합니다. Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 컴퓨팅 노드를 구현합니다. 대기열의 크기에 따라 EC2 Auto Scaling을 구성합니다.
- Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버와 컴퓨팅 노드를 구현합니다. 작업의 대상으로 AWS CloudTrail을 구성합니다. 기본 서버의 부하에 따라 EC2 Auto Scaling을 구성합니다.
- Auto Scaling 그룹에서 관리되는 Amazon EC2 인스턴스로 기본 서버와 컴퓨트 노드를 구현합니다. 작업의 대상으로 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다. 컴퓨트 노드의 부하에 따라 EC2 Auto Scaling을 구성합니다.
풀이
문제 풀이 접기/펼치기
- 예약된 스케일링은 고정적인 패턴을 가진 트래픽에 적합하지만, 가변적인 워크로드를 처리해야 하기 때문에 적합하지 않으며, 가변적 트래픽을 처리하려면 SQS 대기열 크기 기반의 동적 스케일링이 필요하다.
Amazon SQS 대기열을 작업의 대상으로 사용하고, Auto Scaling 그룹에서 관리되는 EC2 인스턴스로 컴퓨팅 노드를 구현하며, SQS 대기열 크기에 따라 Auto Scaling을 조정하는 방법이 가장 적절하다.
- SQS를 활용한 비동기 작업 처리
- 분산 애플리케이션이므로 작업을 조정하는 중앙 서버를 제거하고, SQS를 사용하여 작업을 대기열에 넣고 개별 워커 노드(EC2 인스턴스)에서 이를 소비하도록 설계하면 높은 복원성과 확장성을 확보할 수 있다.
- 기본 서버(중앙 조정 서버)를 유지하면 단일 장애 지점(Single Point of Failure, SPOF)이 생길 수 있다.
- EC2 Auto Scaling을 SQS 큐 크기에 따라 조정
- SQS 대기열 크기에 따라 Auto Scaling이 EC2 인스턴스를 자동으로 확장 또는 축소하도록 구성하면, 가변적인 워크로드를 효과적으로 처리할 수 있다.
- 워크로드가 증가하면 대기열에 작업이 쌓여 이를 기반으로 인스턴스 수를 늘리며, 워크로드가 감소하면 대기열 크기가 줄어들어 인스턴스 수도 자동으로 줄어든다.
- AWS에서 SQS와 Auto Scaling을 연동하는 정책(Amazon CloudWatch와 함께 사용 가능)을 제공하여 이를 쉽게 구현할 수 있다.
- 기본 서버를 유지하는 것은 레거시 시스템과 크게 다르지 않아 복원성이 낮아지고 단일 장애 지점(SPOF)이 발생할 가능성이 높아지며, AWS CloudTrail은 AWS API 호출을 로깅하는 서비스이기 때문에 작업을 조정하는 데 사용되지 않는다.
- EventBridge는 이벤트 기반으로 작업을 트리거하는 서비스로, 대규모 분산 애플리케이션의 작업 큐로 적합하지 않아 작업을 조정하는 서비스로는 SQS가 더 적절하며, 기본 서버를 유지하는 것 또한 비효율적이다.