top of page

AWS 자격증이 실무에서 쓰이나요? : AWS SA-Professional 2

AWS 자격증이 실무에서 쓰이나요? : AWS Solutions Architect - Professional (SAP) Certification 2

AWS 자격증이 실무에서 쓰이나요?: AWS SA Professional 2

Written by Minhyeok Cha



지난 시간에 이어 AWS 자격증 중 Solutions Architect - Professional (SAP) 의 시험 문제가 실제로 콘솔에서 또는 아키텍처 구조 형식이 어떤 지 정리해 보았습니다.


 

문제 1.

회사는 온프레미스 데이터 센터에서 2 계층 웹 기반 애플리케이션을 실행하고 있습니다. 애플리케이션 계층은 상태 저장 애플리케이션을 실행하는 단일 서버로 구성됩니다. 애플리케이션은 별도의 서버에서 실행되는 PostgreSQL 데이터베이스에 연결됩니다. 애플리케이션의 사용자 기반이 크게 성장할 것으로 예상되므로 회사는 애플리케이션과 데이터베이스를 AWS로 마이그레이션하고 있습니다. 이 솔루션은 Amazon Aurora PostgreSQL, Amazon EC2 Auto Scaling 및 Elastic Load Balancing을 사용합니다.


애플리케이션 및 데이터베이스 계층의 확장을 허용하는 일관된 사용자 경험을 제공하는 솔루션은 무엇입니까?



ⓐ Aurora 복제본에 대해 Aurora Auto Scaling을 활성화합니다. 미해결 요청 라우팅 알고리즘이 가장 적고 고정 세션이 활성화된 Network Load Balancer를 사용합니다.


ⓑ Aurora 작성자에 대해 Aurora Auto Scaling을 활성화합니다. 라운드 로빈 라우팅 알고리즘과 고정 세션이 활성화된 Application Load Balancer를 사용합니다.


ⓒ Aurora 복제본에 대해 Aurora Auto Scaling을 활성화합니다. 라운드 로빈 라우팅 및 고정 세션이 활성화된 Application Load Balancer를 사용합니다.


ⓓ Aurora 작성자에 대해 Aurora Scaling을 활성화합니다. 미해결 요청 라우팅 알고리즘이 가장 적고 고정 세션이 활성화된 Network Load Balancer를 사용합니다.



풀이

이번 문제는 문제보단 보기만 봐도 정답이 이미 나와 있습니다.


RDS Aurora Auto Scaling은 쓰기에 있는 기능이 아니라 복제본에 사용하는 기능이기 때문에 B와 D는 소거됩니다.


Aurora Auto Scaling은 조정 정책을 사용하여 Aurora DB 클러스터의 Aurora 복제본 수를 조정합니다

라우팅 알고리즘 또한 마찬가지로 A에서 언급한 NLB의 라우팅 알고리즘은 미해결 요청 라우팅 알고리즘이 아니기 때문에 A가 소거되어 정답은 C입니다.


정답 : C


💡 Network Load Balancer에서 연결을 수신하는 로드밸런서 노드는 다음 프로세스를 사용합니다.
1. 흐름 해시 알고리즘을 사용하여 기본 규칙에 대한 대상 그룹에서 대상을 선택합니다. 알고리즘은 다음을 기반으로 합니다. 
    ◦ 프로토콜 
    ◦ 소스 IP 주소 및 소스 포트 
    ◦ 대상 IP 주소 및 대상 포트 
    ◦ TCP 시퀀스 번호
2. 개별 TCP 연결은 연결 수명 동안 하나의 대상에 라우팅 됩니다. 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 대상에 라우팅 될 수 있습니다.
    

그러나 이 블로그는 실제로 어떻게 쓰이냐가 주제이기 때문에 해당 문제에서 나온 내용을 아키텍처 및 콘솔 상에서의 세팅 방법을 안내하겠습니다.


문제를 보면 기존 2 계층(티어) 웹 기반 애플리케이션인 경우는 트래픽이 많지 않은 경우에 자주 사용되는 Client와 Server(이는 서버에 DB를 직접 사용하는 구조)만을 사용하는 구조입니다.


문제를 계속 읽어보면 이 고객은 크게 성장할 것으로 예상이 된다고 하였기 때문에 SA 관점에서는 해당 구조를 3 단계로 변경할 필요가 있습니다. 실제로 마이그레이션에 사용될 서비스도 적혀있으니 이를 아키텍처로 구현하면 다음과 같습니다.



라운드 로빈의 가중치 설정은 문제에 적혀있지 않아 50:50 비율로 맞췄습니다. 이제 콘솔에서의 작업을 같이 확인해 보겠습니다.


Application Load Balancer 작업 - 해당 설정은 LB - 대상 그룹 - 속성에서 설정합니다.


라운드 로빈 설정


고정 세션 설정

고정 세션은 유형에서 보이는 대로 쿠키를 사용하여 트래픽을 지정된 서버에 바인딩하는 작업입니다. 로드 밸런서 생성 쿠키는 디폴트이고 애플리케이션 기반 쿠키는 로드 밸런서에 포함된 서버에서 사전 구성된 쿠키를 설정합니다.


Aurora Auto Scaling 작업

RDS에 복제본 “Auto Scaling 추가”를 사용하여 리더 인스턴스를 생성합니다.

생성 전에 위 사진처럼 버튼을 클릭하여 Auto Scaling의 정책을 먼저 구성해야 합니다.

정책을 여러 개 적용하여도 한 개의 정책 충족 시 Scale Out이 적용되는 것을 참고해도 좋습니다.



참고: 각 ELB 유형에 따른 라우팅 알고리즘

Application Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

  1. 적용할 규칙을 결정하기 위해 우선순위에 따라 리스너 규칙을 평가합니다.

  2. 대상 그룹에 대해 구성된 라우팅 알고리즘을 사용하여 규칙 조치에 대한 대상 그룹에서 대상을 선택합니다. 기본 라우팅 알고리즘은 라운드 로빈입니다. 대상이 여러 개의 대상 그룹에 등록이 된 경우에도 각 대상 그룹에 대해 독립적으로 라우팅이 수행됩니다.

Network Load Balancer에서 연결을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

  1. 흐름 해시 알고리즘을 사용하여 기본 규칙에 대한 대상 그룹에서 대상을 선택합니다. 알고리즘은 다음을 기반으로 합니다.

    1. 프로토콜

    2. 소스 IP 주소 및 소스 포트

    3. 대상 IP 주소 및 대상 포트

    4. TCP 시퀀스 번호

  2. 개별 TCP 연결은 연결 수명 동안 하나의 대상에 라우팅 됩니다. 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 대상에 라우팅 될 수 있습니다.

Classic Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음과 같이 등록된 인스턴스를 선택합니다.

  • TCP 리스너에 대한 라운드 로빈 라우팅 알고리즘 사용

  • HTTP 및 HTTPS 리스너에 대한 최소 미해결 요청 라우팅 알고리즘 사용

가중치 설정

문제에는 없었지만, 로드 밸런서의 핵심이라고 할 수 있는 트래픽 가중치 설정입니다.


 

문제 2.

소매 회사는 비즈니스 파트너인 다른 회사에 일련의 데이터 파일을 제공해야 합니다. 이러한 파일은 소매 회사에 속한 계정 A의 Amazon S3 버킷에 저장됩니다. 비즈니스 파트너 회사는 IAM 사용자 중 한 명인 User_DataProcessor가 자체 AWS 계정(계정 B)에서 파일에 액세스하기를 원합니다.


User_DataProcessor가 S3 버킷에 성공적으로 액세스할 수 있도록 회사는 어떤 단계 조합을 수행해야 합니까? (2개를 선택하세요.)


ⓐ 계정 A의 S3 버킷에 대한 CORS(교차 원본 리소스 공유) 기능을 활성화합니다.


ⓑ 계정 A에서 S3 버킷 정책을 다음과 같이 설정합니다.

{
	"Effect": "Allow",
	"Action": [
		"s3:Getobject",
		"s3:ListBucket"
	],
	"Resource": "arn:aws:s3:::AccountABucketName/*"
}

ⓒ 계정 A에서 S3 버킷 정책을 다음과 같이 설정합니다.

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::AccountB:user/User_DataProcessor"
     },
     "Action": [
         "s3:GetObject"
         "se:ListBucket"
     ],
     "Resource": [
         "arn:aws:s3:::AccountABucketName/*"
     ]
}

ⓓ 계정 B에서 User_DataProcessor의 권한을 다음과 같이 설정합니다.

{
    "Effect": "Allow",
    "Action": [
        "s3:GetObject",
        "s3:ListBucket"
    ],
    "Resource": "arn:aws:s3:::AccountABucketName/*"
}

ⓔ 계정 B에서 User_DataProcessor의 권한을 다음과 같이 설정합니다.

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::AccountB:user/User_DataProcessor"
    },
    "Action": [
        "s3:GetObject",
        "s3:ListBucket",
    ],
    "Resource": [
        "arn:aws:s3:::AccountABucketName/*"
    ]
}

풀이


해당 문제에서는 위 사진처럼 B 계정에 있는 IAM이 어떠한 정책을 사용해야지 A 계정에 있는 버킷 안에 있는 파일 접근이 가능한가에 대한 문제입니다.

AWS S3 서비스는 다른 계정의 사용자에게 자신이 소유한 객체에 대한 권한을 부여가 가능합니다.


굳이 B 계정이 A 계정 콘솔에 접근할 필요가 없고 리소스 조회만 하면 되기 때문에 IAM의 Principal을 추가할 필요가 없습니다.


오히려 S3 버킷에서 외부 계정 접근을 열어줘야 할 필요가 있습니다.


그렇기 때문에 S3 정책에서 S3 권한과 Principal을 사용해 B 계정을 열어준

C와

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::AccountB:user/User_DataProcessor"
     },
     "Action": [
         "s3:GetObject",
         "s3:ListBucket"
     ],
     "Resource": [
         "arn:aws:s3:::AccountABucketName/*"
     ]
}

IAM 정책 S3 권한과 리소스(A 계정 버킷)를 지정한

D가 정답이 되겠습니다.

{
    "Effect": "Allow",
    "Action": [
        "s3:GestObject",
        "s3:ListBucket"
    ],
    "Resource": "arn:aws:::AccountABucketName/*"
}

정답 : C, D



참고

제공하려는 액세스 유형에 따라 다음과 같이 권한을 부여가 가능합니다.

  1. IAM 정책 및 리소스 기반 버킷 정책

  2. IAM 정책 및 리소스 기반 ACL

  3. 교차 계정 IAM 역할

 

문제 3

한 회사가 Amazon EC2 인스턴스에서 기존 웹 애플리케이션을 실행하고 있습니다. 회사는 애플리케이션을 컨테이너에서 실행되는 마이크로 서비스로 리팩터링해야 합니다. 별도의 애플리케이션 버전이 프로덕션과 테스트라는 두 가지 서로 다른 환경에 존재합니다. 애플리케이션 부하는 가변적이지만 최소 부하와 최대 부하가 알려져 있습니다. 솔루션 설계자는 운영 복잡성을 최소화하는 서버리스 아키텍처로 업데이트된 애플리케이션을 설계해야 합니다.


이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?


ⓐ 컨테이너 이미지를 AWS Lambda에 함수로 업로드합니다. 예상되는 최대 로드를 처리하기 위해 연결된 Lambda 함수에 대한 동시성 제한을 구성합니다. Amazon API Gateway 내에서 두 개의 개별 Lambda 통합을 구성합니다. 하나는 프로덕션용이고 다른 하나는 테스트용입니다.


ⓑ 컨테이너 이미지를 Amazon Elastic Container Registry(Amazon ECR)에 업로드합니다. 예상 로드를 처리하기 위해 Fargate 시작 유형을 사용하여 자동 확장된 Amazon Elastic Container Service(Amazon ECS) 클러스터 2개를 구성합니다. ECR 이미지에서 작업을 배포합니다. 트래픽을 ECS 클러스터로 전달하도록 두 개의 별도 Application Load Balancer를 구성합니다.


ⓒ 컨테이너 이미지를 Amazon Elastic Container Registry(Amazon ECR)에 업로드합니다. 예상 로드를 처리하기 위해 Fargate 시작 유형을 사용하여 자동 확장된 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터 2개를 구성합니다. ECR 이미지에서 작업을 배포합니다. 트래픽을 EKS 클러스터로 전달하도록 두 개의 별도 Application Load Balancer를 구성합니다.


ⓓ 컨테이너 이미지를 AWS Elastic Beanstalk에 업로드합니다. Elastic Beanstalk에서는 프로덕션 및 테스트를 위해 별도의 환경과 배포를 생성합니다. 트래픽을 Elastic Beanstalk 배포로 전달하도록 두 개의 별도 Application Load Balancer를 구성합니다.



풀이

기존 EC2에서 컨테이너를 사용하는 마이크로서비스 리펙터링 즉 서비스 마이그레이션을 원하는 문제입니다.

이번에는 컨테이너, 마이크로서비스, 서버리스 아키텍처, 비용 효율적 이렇게 4개만 숙지하고 보기로 넘어가도록 하겠습니다.


A의 AWS Lambda는 서버리스는 맞습니다만 컨테이너가 아니기 때문에 소거,

D의 AWS Elastic Beanstalk은 컨테이너(Docker Image)를 사용은 할 수 있으나 이 서비스는 PaaS로 분류되어 있기에 정확히는 서버리스가 아니기 때문에 소거.


그렇다면 나머지 B의 ECS와 C의 EKS로 나뉘게 되는데 마지막 비용 효율성으로 보면 ECS가 더 저렴하기 때문에 정답은 B가 되겠습니다.


정답: B


이번 문제는 단순 아키테칭 솔루션을 구성하는 문제라 콘솔에서 작업하는 과정은 건너뛰겠습니다.

마무리

오늘 풀어본 AWS SA 자격증 문제가 여러분에게 도움이 되었길 바랍니다. 문제 풀이에 대해 궁금하다거나 틀린 부분이 있는 경우, 혹은 추가적인 질문이 있다면 언제든지 partner@smileshark.kr로 연락 주시기 바랍니다.

조회수 420회댓글 0개

관련 게시물

전체 보기

Commentaires


bottom of page