AWS SAA-C03 문제 풀이 9번 ~ 16번

안녕하세요!

5월은 쉬는 날이 많아서 정말 좋네요! 매달 이랬으면 좋겠습니다!😆

9번

뉘앙스는 스토리지 확장이며 새로운 솔루션으로 마이그레이션은 아닌 것 같습니다. 그러면서 비용적인 이점을 위해 파일 수명주기도 관리하려는 것 같습니다. 파일의 수명주기는 S3로 관리하며 SMB 프로토콜을 그대로 사용하면서 저장공간만 확장하는 방법은 file gateway를 사용하는 것입니다.

따라서 답은 B 입니다.

10번

FIFO는 First in first out의 약자입니다. 이 키워드만 알아도 쉽게 답을 찾아갈 수 있습니다. 
SQS는 표준 대기열과 FIFO 대기열을 지원합니다. 표준 대기열의 경우 순서와 관계없이 처리될 수 있습니다. 이유는 SQS는 기본적으로 aws 내의 복수의 노드에서 분산 처리되기 때문입니다. FIFO를 사용하면 순서에 따라 처리하게 할 수 있으나 표준 대기열보다 성능이 조금 떨어질 수 있다고 합니다. 

따라서 답은 B입니다.

11번

DB에 접근할 계정과 같은 어카운트와 관련된 내용을 평문으로 저장하는 것은 위험합니다. 평문으로 저장된 위치를 가져오는 것도 여전히 위험합니다. 어카운트와 같은 보안 정보는 항상 다중 암호화하여 관리하는 것이 좋습니다. AWS Secret Manager는 이러한 부분에 도움을 주는 서비스입니다. 어플리케이션의 보안과 관련된 정보를 KMS를 이용하여 보관하고 불러올 수 있게 해줍니다. 자세한 설명은 링크를 참조하세요. 단순하지만 조금 길게 서술되어있어 편한 마음으로 읽어보시는 것을 추천해요😀
B는 어카운트와 관련된 정보를 저장하고 불러오는데는 적합하지 않고, C도 구성은 가능할 것 같지만 오버헤드가 확실히 증가합니다.

따라서 답은 A 입니다.

12번

글로벌 서비스를 하는 회사가 동적, 정적 데이터의 성능을 개선하고 대기시간을 줄이며 Route53에 등록된 도메인주소를 그대로 사용해야한다고 합니다. 
앞서 말씀드린 것처럼, 정적 컨텐츠의 경우 Cloudfront와 S3의 조합이 매우 강력하고 자주 등장하는 Best practice라고 말씀드렸습니다. 그렇다면 동적 컨텐츠의 경우에는 어떨까요?
정적컨텐츠와 동적컨텐츠 모두 Cloudfront를 사용하여 성능 개선과 대기시간 감소 효과를 가져올 수 있습니다. 저의 경우 CDN(Contents Delivery Service, Cloudfront)은 정적 컨텐츠의 전송에만 유리하다고 생각했었습니다. 이유는 동적컨텐츠는 사용자의 요청에 따라 내용을 가공하여 전달해야 하기 때문입니다. Cloudfront는 최적화된 네트워크를 통해 오리진까지 더 신속한 데이터 전송이 가능하게 합니다. 링크에서 자세한 내용을 확인하실 수 있습니다. 링크의 내용에 따르면 동적컨텐츠도 Cloudfront를 이용하여 성능 개선효과를 볼 수 있습니다.
또한 Route53에서 Cloudfront로 라우팅을 할 때에는 LBR(Latency Based Routing)을 사용하여 사용자로부터 최적의 리전에 있는 오리진에서 콘텐츠가 전송될 수 있도록 하므로 보기 C처럼 새로 Route53에 도메인을 등록할 필요가 없게 됩니다.

따라서 답은 A 입니다.

* CDN과 엣지로케이션은 비슷하지만 조금 다른 개념입니다. CDN은 Contents Delivery Network, 즉 여러 위치에 분산된 서버 네트워크로, 사용자에게 콘텐츠를 빠르게 제공하기 위해 설계되었습니다. CDN은 콘텐츠의 복사본을 여러 위치에 저장하여, 사용자가 근처의 서버로부터 콘텐츠를 다운로드 받을 수 있도록 합니다. 이로 인해 대기 시간이 줄어들고 전체적인 성능이 향상됩니다.
엣지 로케이션은 CDN의 구성 요소로, 사용자에게 가까운 지리적 위치에 있는 데이터 센터입니다. 엣지 로케이션은 콘텐츠 캐싱, 프록시 서버, 요청 처리 등의 기능을 수행합니다. CDN은 여러 개의 엣지 로케이션으로 구성되어 전 세계적인 콘텐츠 전달을 담당합니다.

+ 그렇다면 Global Accelerator는 어떤 경우에 적합할까요? GA는 어플리케이션을 가속화하는데에 더 집중되어 있습니다. 그러니까 컨텐츠의 전송보다 사용자와 서버의 상호작용이 빈번이 일어나는 환경에 더 적합합니다. 즉, 지연시간에 민감한 트랜잭션이 많이 발생하는 금융이나 게임(제가 직접 운영해보진 않았지만...)과 같은 어플리케이션, 그리고 다중 리전에 설계된 데이터베이스에 접근해야하는 경우 등이 될 것 같습니다.

13번

방금 전 문제에서 여러 리전에 접근하는 DB에 대해 말씀드려서 같은 내용으로 말씀 드리게되나 싶었지만 안타깝네요 ㅎㅎ

11번 문제와 매우 유사합니다. 여러 리전에 있는 DB의 자격 증명을 주기적으로 교체하면서 최소한의 운영 오버헤드도 충족되어야합니다. Secret Manager는 주기적으로 알아서 자격 증명도 교체해줍니다. 그리고 다중 리전 secret 복제를 한다면 운영 오버헤드도 많이 줄일 것 같습니다.

따라서 답은 A 입니다.

14번

EC2에 MySQL을 설치해서 사용하는 경우를 많이 보긴 했습니다만 가용성 측면에서 매우 불안정합니다. 하지만 RDS를 쓰는 것보다는 저렴하죠. 이제 회사는 고가용성과 CQR에 대해 고민하기 시작했습니다. CQR은 Command-Query Seperation pattern으로 DB에서 조회와 쓰기를 나누겠다는 접근입니다. CQR은 곧 CQRS(Command-Query Responsibility Segregation)로 진화하게 되는데 나중에 MSA에 대해 설명할 기회가 생기면 꼭 다시 말씀드리겠습니다. 
회사는 쓰기보다 읽기 요청이 더 많아지게 되므로 read-only 인스턴스가 auto-scaling되어야 하는 아키텍쳐가 필요합니다. 또한 고가용성이 요청되기 때문에 멀티 AZ에 배포되는 것이 좋겠지요. 

따라서 답은 C 입니다.

Redshift는 페타바이트급 데이터 처리를 위한 종합 컴퓨팅 서비스인데 여기선 그정도는 아닌 것 같습니다.
스팟인스턴스는 고가용성과 거리가 멉니다. 그리고 DB를 스팟인스턴스로 구성하는 것은... 현재의 기술력으론 바람직하지 않습니다. 언제 종료될지 몰라 불안정하기 때문입니다.

15번

AWS Network Firewall를 사용하면 VPC 내의 트래픽을 검사하고 필터링할 수 있습니다. 이 서비스는 사용자 정의 규칙을 적용하여 특정 트래픽 유형을 허용하거나 차단할 수 있습니다. 관리형 규칙을 사용하거나 정규표현식을 통해 직접 만들어서 관리합니다. 비용적으로 직접 만들어 사용하는 것이 유리하다고 합니다😉

답은 C 입니다.

16번

"보고 솔루션" 때문에 조금 혼란이 있으실지도 모르겠습니다. 영문은 reporting으로 한국식 보고와 결재가 아닌 단순 데이터 활용에 대한 상태 전달 정도로 이해하시면 되겠습니다. 데이터 시각화가 되면서 데이터 소스를 확인할 수 있도록하면 충분하므로 QuickSight면 요구사항을 모두 달성할 것으로 보입니다. QuickSight는 수집된 데이터 내용으로 표랑 차트랑 그래프 등을 써서 시각화된 대시보드를 만들어줍니다. 권한에 따라 다른 지표로 구성된 대시보드를 만들어 사용자와 그룹 단위로 공유하면 충분히 요구사항을 구현할 수 있습니다.

따라서 답은 B 입니다.

Glue나 Athena를 써도 시각화를 하려면 QickShight를 이용해야합니다.

 

오늘은 여기까지 입니다. 더 하고 싶었는데 은근 시간이 많이 소요되었네요..ㅎ

그럼 궁금하신 것들 언제나 편히 댓글 남겨주시고, 좋은 하루 보내시길 바랍니다요!!
🙇‍♂️😄