[클라우드] AWS SAA 취득 후기 및 시험 전략 공유!

GOMGun·2022년 6월 2일
0

안녕하세요?

곰군입니다.

저는 2019년도에 클라우드 개발자로 성장하고 싶어서,

AWS 기초 자격증부터 시작해서 Developer Associate, DevOps Engineer Professional 자격증을 취득하였습니다.

아~~무 것도 모르고 공부했을 때라, 정말 이것저것 문서 찾아보고, 인터넷에 있는 문제란 문제는 다 풀어보고, Associate에서는 정말 한 문제 차이로 떨어져 보기도 하고 다양한 경험을 하였습니다.

하지만 실무에서는 AWS 아키텍쳐를 구성하거나 시스템 엔지니어적인 이슈 핸들링 등의 업무나 문의를 접할 때가 많았습니다. IT인프라나 네트워크 기본이 약한 저는 위의 다양한 요구사항에 적절하게 대응하게 힘들었습니다.

하여 기초부터 다시 공부하자는 마음으로 인프라 및 네트워크, 클라우드의 기본부터 다시 공부하기 시작했습니다.

깊이 있는 공부는 아니였지만, IT를 잘 모르는 경영진이나 관리자급 분들께 쉽게 설명할 수 있는 정도의 정리를 하였습니다.

관련 글은 아래 링크를 참조하세요 ㅎㅎ

https://cgomgun.tistory.com/1

[Back to Basics] 인프라 기초 정리

인프라 기초 정리 퍼블릭 클라우드가 대세로 자리 잡아 감에 따라 개발자는 개발만, 시스템 엔지니어는 인프라 관리만 하던, 평화롭고 안정적이던 분업의 시대는 이제 저물어 가는 것 같습니다.

cgomgun.tistory.com
https://cgomgun.tistory.com/3

[Back to Basics] 클라우드 컴퓨팅 기초 정리

클라우드 컴퓨팅이 뭔가요? 컴퓨터 통신망의 복잡한 네트워크 및 서버 구성 등을 직접 물리적으로 관리하지 않고, 어디에서나 온라인으로 구름 속의 컴퓨터 자원을 활용해 자기가 원하는 작업

cgomgun.tistory.com
이렇게 기초 공부를 하고 나니 SAA시험 공부가 많이 쉬워졌습니다.

예를 들어 기존에 기초가 없을때에는 ALB와 NLB의 특징, 차이점 등을 이해하지 못하고 무작정 외웠었는데, OSI 7계층을 이해하고나니 둘의 차이점이 명확하게 이해가 되었습니다.

AWS 자격증 공부를 하시는 분들 중 저와 같이 인프라에 대한 기초가 부족한 분들이 계시다면 꼭 기초 공부를 미리 하시는 것을 추천드립니다. 저는 Eric Han님이 정리해놓으신 하기 링크에서 정말 많은 공부를 하였습니다. 감사합니다!!

https://futurecreator.github.io/2018/11/09/it-infrastructure-basics/

개발자를 위한 인프라 기초 총정리

최근 클라우드 관련 부서로 옮겨 클라우드 관련 업무를 맡게 되었습니다. 그동안 개발은 했어도 인프라 지식은 많지 않은 상황에서 업무를 하다보니 어려운 부분이 있어 인프라 기초를 정리해

futurecreator.github.io

취득후기

그래서 5월에 피어슨뷰 온라인 시험을 통해서 SAA자격증을 취득하였습니다.

집에서 보니 편하고 좋네요...

예전처럼 시험장 예약을 위해서 한 달전에 미리 신청할 필요도 없고,

예약 변경도 잘되서 온라인 시험 강력 추천합니다!!

SAA시험 전략 공유

AWS관련 시험을 많이 보다 보니...

이제 좀 노하우가 생겨서 팁을 공유드리고자 이 글을 쓰고 있습니다..

일단 AWS 자격증 자체가, AWS의 다양한 서비스들을 잘 활용하여 아키텍처를 구현하고, 다양한 고객의 요구사항들을 지원하기 위한 공부임을 잊지마셔야합니다.

그래서 기본적인 IT기술과 장비, 아키텍쳐 등을 알고 계시고, 그걸 AWS 서비스하고 연결을 하는 공부를 하시는 게 필수입니다.

예를들어 고객이 고가용성 및 내결함성에 관심이 높다고하면,

AWS의 멀티리젼이나 멀티AZ에 대한 이해와 로드밸런싱, CloudWatch, Auto Scaling 등 AWS 서비스들을 활용해서 안정성과 내구성을 높은 서비스나 아키텍쳐를 제공할 수 있어야 합니다.

대부분의 문제는 하기 3가지 절차를 따르면 정답에 많이 가까워집니다.

  1. 문제를 읽으면서 키워드를 뽑아낸다.

  2. 고객 혹은 시스템이 전략적으로 중요하게 생각하는 것을 파악한다. - 운영/비용/관리 효율성 등

  3. 제약사항을 확인한다. - 용량/전송속도/정책 등등

예제 문제를 하나 보시겠습니다.

_비즈니스에는 처리할 페이로드가 포함된 메시지를 보내는 응용 프로그램과 페이로드가 포함된 메시지를 받는 응용 프로그램의 두 가지 응용 프로그램이 있습니다. 조직은 두 앱 간의 통신을 관리하기 위해 Amazon Web Services(AWS) 솔루션을 만들고자 합니다. 발신자 프로그램은 매시간 약 1,000개의 메시지를 보낼 수 있습니다. 통신 처리에는 최대 2일이 소요될 수 있습니다. 메시지가 처리되지 않으면 후속 메시지 처리를 방해하지 않도록 보관해야 합니다.
어떤 솔루션이 이러한 매개변수를 충족하고 운영 효율성 측면에서 가장 최적입니까?

A. Redis 데이터베이스를 실행하는 Amazon EC2 인스턴스를 설정합니다. 인스턴스를 사용하도록 두 애플리케이션을 모두 구성합니다. 메시지를 각각 저장, 처리 및 삭제합니다.
B. Amazon Kinesis 데이터 스트림을 사용하여 발신자 애플리케이션에서 메시지를 수신합니다. 처리 애플리케이션을 Kinesis 클라이언트 라이브러리(KCL)와 통합합니다.
C. 발신자 및 프로세서 애플리케이션을 Amazon Simple Queue Service(Amazon SQS) 대기열과 통합합니다. 처리에 실패한 메시지를 수집하도록 배달 못한 편지 대기열을 구성합니다.
D. 처리할 알림을 수신하려면 처리 애플리케이션을 Amazon Simple Notification Service(Amazon SNS) 주제에 등록합니다. SNS 주제에 쓸 발신자 애플리케이션을 통합합니다._

  1. 문제를 읽으며 딱 보이는 키워드는 '메시지 서비스' 입니다. 그렇다면 AWS 제공하는 메시지 서비스는 뭐가 있을까요?

Kinesis, SQS, SNS, MQ 등을 정답 고려 대상군에 넣어놓습니다. A는 탈락이네요?

  1. 이 문제에서 고객이 중요시하는 것은 운용효율성입니다. 어떤 고객은 비용을 중요시하게 생각하고 어떤 고객은 안정성을 중요시하게 생각합니다. 지금의 케이스는 운용효율성이니 비용 이슈 보다는 사람의 손을 덜 타는 관리형 서비스를 검토하시면 좋겠죠?
  1. 제약 사항은 "매시간 약 1,000개의 메시지", "통신 처리에는 최대 2일이 소요", "메시지가 처리되지 않으면 후속 메시지 처리를 방해하지 않도록 보관"
    입니다. 그렇다면 먼저 메시지 실패에 대한 조치가 있는 보기를 검토해야 합니다.
    C밖에 없네요? 가능성이 높아 보입니다!

메세징 서비스에서 후속 메시지 처리를 방해하지 않으려면 DLQ(Dead-Letter Queue)를 설정해야 합니다.
일정 횟수이상 실패했을 시 배달 못한 편지 대기열로 옮기는 것으로, 이 설정을 해두면 해당 오류 메시지 이후의 메시지는 오류가 없으면 정상적으로 실행됩니다.

AWS DLQ 서비스는 SQS입니다. 모르시더라도 배달 못한 편지 대기열(Dead-Letter Queue)이란 단어가 보이니까 정답은 C가 되겠네요.

B, D는 "메시지가 처리되지 않으면 후속 메시지 처리를 방해하지 않도록 보관"에 대한 고려가 보이지 않으니 자동 탈락입니다.

이렇게 3단계를 거치면 어지간한 문제는 확신을 가지고 답을 선택하실 수 있을 겁니다.

별 것 아닌 팁이지만 지문이 긴 문제를 푸실때 막연하게 접근하시면서 읽다가 지치시기 보다는, 이 3단계를 확인하시면서 읽으시면 접근이 좀 편해지고, 오답 확률도 줄어듭니다.

그럼 도움이 되셨길 바라면서 이만 쓰겠습니다.
감사합니다.

profile
곰군

0개의 댓글