Namu | 나무 개발자 블로그입니다

[01] AWS 자격증 취득하기: SA - Associate by namu

Created at
| 2023-01-28 18:00
Updated at
| 2023-02-24 22:00
post image
image by amazon.com

목차

시리즈

참조


들어가며

신년을 맞아 AWS 자격증 배지를 달아보자는 목표를 세웠습니다.

그 중 퍼블릭 클라우드 인프라 전반에 대한 기본적인 이해를 요구하는
Solutions Architect: Associate 를 취득하기로 정했습니다.

사실 작년동안 회사 내 여러 프로젝트를 진행하며 AWS 퍼블릭 클라우드 인프라를 계속 다뤄왔습니다.

이번 시험을 준비하며 알고있던 개념들을 체계적으로 정리하고, 몰랐던 세부내용까지 학습할 예정입니다.

인프런 AWS Certified Solutions Architect - Associate 자격증 준비하기 강의를 참조했습니다.

“[실전]” 키워드가 달린 부분은 실전문제풀이 이후 출제된 문제 관점에서 개념을 추가로 정리한 내용입니다.


개념 정리

IAM policy

IAM 정책은 Json 포맷으로 이루어집니다.

정책 내에 Statement 는 여러 개 있을 수 있고, 구문이 나열된 순서대로 축적되며 적용됩니다.
statement 간 충돌이 있을 경우 나중에 배치된 구문이 적용됩니다.

커스텀 정책은 IAM 사용자, IAM 그룹 혹은 IAM 역할(role)에 각각 지정할 수 있습니다.
AWS 에는 사전에 정의된 다양한 정책이 존재하므로, 검색을 통해 적절히 활용할 수 있습니다.

AWS Policy Generator 를 활용해 보다 손쉽게 정책을 생성할 수 있습니다.

[실전] "aws:SourceIp": "10.100.100.0/24" 조건이 적용된 경우 해당 정책은 256개 IP 중 끝자리 0, 1, 2, 3, 255 예약된 다섯 개를 제외한 251개에만 적용됩니다.


IAM role

역할(role)은 IAM 사용자, IAM 그룹과 더불어 정책을 구성하는 단위로 사용됩니다.

역할은 AWS 리소스에서 사용하는 자격증명이며, 보통 AWS EC2 리소스에 특정 정책 및 권한을 적용할 때 사용됩니다.


권한 경계(Permissions Boundary)

권한 경계는 IAM 사용자 또는 역할에 최대 권한을 제한하는 기능입니다.
권한 경계가 지정된 사용자는 넓은 범주의 정책 적용을 받더라도 지정된 권한 경계를 초과하는 권한은 가질 수 없습니다.

예를 들어 ‘admin’ 그룹에 속한 사용자들이 AmazonEC2FullAccess 권한을 가진다고 할 때, ‘temp_admin’ 계정에 한해 권한 경계를 AmazonEC2ReadOnlyAccess 로 지정해두면 ‘temp_admin’ 계정은 ‘admin’ 그룹에 속했음에도 EC2 리소스에 대해 읽기 권한만 가집니다.

[실전] 회사는 개발자가 기존에 존재하는 IAM 정책을 기존에 존재하는 IAM 역할에 연결하여 더 빠른 실험과 민첩성을 지원하도록 허용합니다. 그러나 보안 담당자는 개발자가 기존에 존재하는 관리자 정책을 첨부하여 다른 보안 정책을 우회할 수 있다고 우려하고 있으므로, 이를 해결하기 위한 솔루션은,

  • 해결: IAM 권한 경계를 사용!! 개발자의 IAM Role 에 관리자 IAM Policy 연결을 명시적으로 거부하는 권한 경계 설정.
  • » 기존에 존재하는 policy 를 role 에 연결하는 권한을 개발자가 가지고 있지만, 권한 경계로 인해 관리자 policy 한정으로 연결이 거부됨!


신뢰 정책(Trust Policy)

신뢰 정책은 IAM 역할에서 AWS 계정 간 액세스 권한을 위임할 때 사용됩니다.

예를 들어 개발자들이 테스트 수행을 위해 프로젝트의 프로덕션 권한을 얻을 때 사용할 수 있습니다.
(본래는 프로덕션 권한이 없지만 프로덕션 계정의 역할에서 지정된 신뢰 관계를 통해 임시로 권한을 획득)

[실전] 회사에 운영과 개발 두 개의 AWS 계정이 있고 개발 계정의 코드 변경 사항을 운영 계정으로 푸시해야 합니다. 알파 단계에서는 두 명의 개발자가, 베타 단계에서는 더 많은 개발자가 테스트를 위해 액세스 권한이 필요합니다.

  • 해결: 운영 계정에서 IAM Role 생성 후 개발 계정을 지정하는 신뢰 정책을 정의. 개발자가 역할을 맡도록 허용


EC2 관련

(1) AWS 클라우드 사업자는 가상화된 컴퓨팅 자원을 제공합니다. 자원의 제공은 기본적으로 멀티 테넌시(Multi Tenancy) 방식으로 이루어지는데 이는 공통의 물리적 영역에 여러 하드웨어 리소스를 배치하고 여러 고객에게 유연하게 할당/해제하는 것을 의미합니다.

클라우드 사업자 입장에서 이 방식은 유휴 리소스에 대한 관리 비용이 절감되어 고객에게 보다 낮은 가격의 컴퓨팅 자원을 제공할 수 있는 장점이 있지만, 특정 가상 인스턴스에 비정상적인 부하가 발생하는 등 문제가 생기면 물리적 공간을 공유하는 다른 리소스에도 영향이 갈 수 있다는 단점이 있습니다.

이런 부분이 우려된다면 전용 테넌시(Dedicated Tenancy) 방식으로 제공되는 자원을 이용할 수 있는데, 이 때는 단일 테넌트로써 하나의 계정에 할당되는 하드웨어 리소스에 하나의 전용 인스턴스가 실행되므로 다른 계정의 인스턴스와의 하드웨어가 공유가 이루어지지 않습니다. 이것은 가용성이나 보안성 측면에서 우수하고 리소스에 대한 고객 커스터마이징 및 자사 보유의 소프트웨어 라이선스 적용이 가능하다는 장점이 있으나, 그만큼 상대적인 비용이 높고 클라우드 사업자로부터 안정적인 유지보수를 지원받기 어렵습니다.

[실전] 단기 이벤트를 위해 EC2 인스턴스 용량이 필요하다고 할 때, 온디맨드 용량 예약을 생성합니다. 예약 인스턴스나 saving plan 의 경우 연단위로 구매되므로 요구사항에는 비효율적입니다.

[실전] 인스턴스 구매 시 전용 인스턴스 온디맨드를 결제하고 예약 인스턴스를 구매하여 최대 70% 절감하거나 스팟 인스턴스를 구매하여 최대 90% 절감이 가능합니다.

(2) ENI(Elastic Network Interface) 는 인스턴스에 부착되어 네트워크 카드(랜카드) 역할을 합니다.

(3) EC2 배치 그룹(Placement Groups)이란 가용영역 내 하드웨어 서버랙에서 EC2 인스턴스들을 다양한 형태로 가깝게 배치하는 것을 의미합니다. 배치 전략에 따라 서버랙 전반에 분산되도록 하거나 논리적 파티션 단위로 분할하거나 단일 서버랙에 국한되게 구성할 수 있습니다.

(4) EC2 라이프 사이클에서 최대절전모드는 PC의 절전모드와 같음

(5) 타겟 그룹(Target Group) 생성 후 속성(Attributes)값 세팅 시 공통적으로 등록 취소 지연(Deregistration delay) 값을 지정합니다.

(6) 로드 밸런서(ELB, Elastic Load Balancer)

(7) Auto Scaling 은 인스턴스를 자동으로 확장하고 축소하는 기능으로, 사용자가 정의한 조정 정책에 따라 개수가 조절됩니다. 혹은 서버의 로드 수에 따라서 조절도 가능합니다.

[실전] ASG 동적 조정에서 SQS 기반 크기 조정을 사용하는 경우, SQS 의 ApproximateNumberOfMessages 대기열 속성을 사용하여 도출된 메시지 개수에서 폴링중인 ASG 내 InService 상태인 인스턴스 개수를 나눠서 인스턴스당 백로그를 산출합니다.

예를 들어 메시지 평균 처리 시간이 0.1초이고 가장 긴 허용 지연 시간이 10초인 경우 인스턴스당 허용 가능한 백로그는 10/0.1인 100개의 메시지입니다. 그런데 현재 활성화된 인스턴스가 10개이고 SQS 대기열 메시지 수가 1500개라고 가정하면, 1500/10인 150개의 인스턴스당 백로그가 존재하게 되어 그룹이 스케일 아웃되고 5개의 인스턴스를 추가하여 목표값 비율을 유지합니다.

[실전] 배달앱 서비스에서 주문 수집 ASG 과 주문 이행 ASG 이 각각 존재하고, 주문 이행 프로세스보다 주문 수집 프로세스가 더 빠르게 진행된다고 할 때, 각 처리속도 차이에 따른 스케일링 이벤트 차이로 인해 데이터가 손실될 위험이 있습니다. 솔루션 아키텍트는 데이터 손실 없이 두 ASG 의 스케일링이 적절하게 이루어지게 하면서 AWS 리소스 활용을 최적화하기 위한 솔루션을 구성해야 합니다.

  • 해결: 주문 수집용 및 주문 이행용 두 개의 SQS 대기열을 프로비저닝하고 각각 폴링하도록 EC2 인스턴스를 구성합니다.(데이터 손실 X) SQS 기반 크기 조정을 사용하여 인스턴스당 백로그 계산을 기반으로 메트릭을 생성하고, 이 메트릭을 기반으로 Auto Scaling Group 을 확장합니다.
  • (X) SQS 의 알림(지표)를 사용해 ASG 스케일링 하는 방식은 적절하지 않음. 인스턴스의 메시지 평균 처리 속도나 허용되는 지연 시간(대기열 지연) 등 여러 요인을 고려하지 않고 대기열에 메시지가 쌓인 정도만을 가지고 기준을 정할 수 없기 때문

[실전] ASG 의 EC2 인스턴스 및 ALB 로 구성된 아키텍쳐에서 근무 시간 동안 트래픽이 크게 증가하지만 주말에 작동할 필요는 없다고 합니다. 시스템이 수요를 충족하는 확장 및 축소를 할 수 있도록 하는 솔루션은,

  • 해결: (1) 동적 조정의 대상 추적 조정 정책을 사용하여 인스턴스 CPU 사용률에 따라 ASG 을 조정하고 (2) 예정된 스케일링을 사용하여 주말의 ASG 의 최소, 최대, 희망 용량을 0으로 변경 및 일주일 시작 시 기본값으로 되돌리도록 구성

(8) EBS(Elastic Block Storage)는 SSD, HDD 와 같은 하드디스크로 EC2에 부착됩니다. 인스턴스를 시작할 때 함께 생성되는 EBS 는 부트 볼륨으로, 시스템 부팅을 위해 사용됩니다.

(9) Instance Store 는 가상머신인 인스턴스에 물리적으로 부착되는 임시 블록 스토리지로, 물리적으로 붙어있기 때문에 고성능이지만 인스턴스가 종료(혹은 최대절전모드)되면 사라지므로 빠른 IOPs 성능의 임시저장 스토리지를 요하는 시스템에 적합합니다.

(10) EFS(Elastic File System) 란 리눅스 환경의 EC2 인스턴스에서 연결하기 위한 네트워크 파일 스토리지입니다. 이것은 인바운드 시 NFS 프로토콜 규칙을 적용하는 보안 그룹을 지정하는 것이 특징입니다.

[실전] 단일 VPC 의 여러 가용 영역의 여러 EC2 인스턴스 간에 데이터를 공유하는 고성능 스토리지 솔루션을 구축해야 합니다. 또한 데이터를 VPC 내에서만 유지해야 합니다. 이 때는 수십~수백 대의 인스턴스 연결 및 데이터 공유가 가능한 EFS 를 사용해야 합니다.

  • (X) S3 는 여러 EC2 인스턴스 간에 데이터를 공유하는 고성능 스토리지 솔루션은 아님
  • (X) EBS 는 다음의 제약사항으로 인해 적절하지 않음
    • 인스턴스 타입 제약 » Nitro 기반 Linux 인스턴스만 가능(single provisioned IOPs SSD)
    • 연결 인스턴스 개수 제약 » 최대 16개
    • 가용 영역 제한 » EBS 가 존재하는 단일 가용 영역에 한함. EBS 복제(Replica)로 다른 가용 영역에 생성은 가능하나, 여러 AZ 의 여러 인스턴스 간 데이터 공유 스토리지 솔루션에는 적합하지 않음

[실전] 여러 가용 영역의 EC2 인스턴스가 공유하는 공유 스토리지 솔루션이면서 수시로 변경되는 콘텐츠 데이터에 대한 강력한 일관성이 요구되는 환경에서 적절한 것은 EFS 입니다. NFS 파일 시스템 스토리지이므로 변경 사항이 즉시 반영됩니다.

  • (X) Storage Gateway 는 온프레미스 환경이 아니므로 해당되지 않는 솔루션
  • (X) EBS 는 단일 가용 영역이므로 부적절
  • (X) CloudFront 솔루션으로 Cache-Control 헤더의 메타데이터를 no-cache 로 설정하는 것은 단지 캐싱 없이 콘텐츠를 제공하는 것이므로 강력한 일관성의 인스턴스 간 공유 스토리지 솔루션을 요하는 해당 이슈와는 무관함


S3 및 기타 스토리지

(1) 오브젝트 스토리지인 S3(Simple Storage Service) 는 파일이 아닌 오브젝트 단위로 데이터를 저장합니다. 오브젝트에는 키, 데이터 및 옵션 메타데이터가 포함되어 있으며 키값으로 접근이 가능합니다.

[실전] 미디어 회사는 비디오 처리 애플리케이션에서 가능한 최대 I/O 성능과 함께 최소 10TB 스토리지가 필요합니다. 미디어 콘텐츠 저장을 위해 내구성이 뛰어난 300TB 의 스토리지와 더 이상 사용하지 않는 아카이브 미디어 저장을 위한 900TB 스토리지 솔루션이 필요합니다.

  • (O) 최대 성능을 위한 EC2 인스턴스 스토어 + 내구성 있는 스토리지를 위한 S3 + 더 이상 사용하지 않는 아카이브를 위한 S3 Glacier
  • (X) EBS 는 충분히 빠르긴 하지만 인스턴스 스토어에 비해 가능한 최대 I/O 성능은 아님
  • (X) EFS 는 내구성에 대한 AWS 측의 공식적인 보장은 없음

[실전] 이미지 업로드 웹사이트를 운영할 때 사용자가 업로드하는 이미지의 크기를 조정하여 저장하되, 업로드 요청 지연 현상이 발생하지 않도록 시스템을 구성하려고 합니다. 솔루션 설계자는 가장 운영 효율적인 프로세스를 설계해야 합니다.

  • 다양한 솔루션 구성이 가능하겠으나, 운영 효율적이려면 업로드 자체는 S3 를 사용하도록 하면서 이미지 크기 조정 프로세스 자체는 서버리스에 가까워야 함.(클라우드 시스템이 알아서 처리하도록)
  • 해결: 원본 이미지를 S3 에 업로드하도록 웹 서버를 구성하고 + 업로드 S3 이벤트 알림을 구성하여 알림이 이미지 크기 조정 Lambda 함수를 호출하도록 함

[실전] S3 에 기밀 데이터를 저장 시, 규정 준수를 위해 객체 암호화가 필요하며 암호화 키 사용은 감사 목적으로 기록되어야 합니다. 키는 매년 순환해야 합니다.

  • 해결: 키 자동 교체와 키 사용에 대한 감사 추적 기록이 가능한 AWS KMS(SSE-KMS) 고객 마스터 키(CMK)를 사용한 서버 측 암호화

(2) 스토리지 클래스: S3 서비스는 저장하는 데이터의 특성이나 패턴에 따라 스토리지 클래스를 결정할 수 있는데, 이에 따라 비용을 적절하게 절감할 수 있습니다.

[실전] 다음의 조건에 부합하는 가장 비용효율적인 스토리지 솔루션을 구성하십시오.

  1. 수백만 명의 사용자로부터 매일 총 약 1TB 의 데이터 수신, 사용자에게 12개월 전의 사용 보고서를 제공
  2. 정기적 및 감사 요구 사항을 준수하기 위해 모든 사용 데이터를 최소 5년 동안 저장
    • 솔루션: 데이터는 S3 Standard 저장 + 수명 주기 설정 1년 후 데이터는 S3 Glacier Deep Archive 로 전송 + 수명 주기 설정 5년 후 데이터 삭제
    • 설명: 최초 12개월 동안은 짧은 지연과 빈번한 처리가 예상되고, 그 이후 5년 삭제 시점 이전까지는 가장 저렴한 S3 Glacier Deep Archive 에 저장

[실전] 전 세계의 어플리케이션 사용자의 파일 업로드 및 다운로드 속도를 빠르게 하려면, S3 콘솔에서 S3 Transfer Acceleration(S3TA) 을 구성합니다.

  • S3TA 는 더 큰 용량의 객체를 장거리 전송하는 속도를 높이기 위해 고안되었음
  • S3TA 는 트래픽이 글로벌로 분산된 엣지 로케이션이나 AWS 백본 네트워크로 라우팅되게 하거나, 네트워크 프로토콜 최적화를 이용해 전송 퍼포먼스를 향상시킵니다.
  • S3TA 사용시에는 표준 엔드포인트가 아닌 S3 Accelerate endpoint 를 사용하도록 합니다. (<bucket>.s3-accelerate.amazonaws.com 형태의 엔드포인트)

(3) 객체 수명 주기 관리(Lifecycle Policy): 오브젝트마다 스토리지 클래스를 일일히 지정할 수는 없으므로, 이를 비용효율적으로 관리해주는 수명 주기 관리 기능을 사용할 수 있습니다.

[실전] 회사는 매월 일정한 크기와 수의 객체 데이터를 AWS S3 로 업로드하여 유지합니다. 객체는 멀티파트 업로드로 자주 교체됩니다. 스토리지 비용이 매달 증가하는 현상을 경험하고 있을 때 비용을 줄이는 솔루션은,

  • 해결: 불완전한 멀티파트 업로드를 삭제하는 S3 수명 주기 정책을 활성화. 멀티파트 업로드가 시작되면 완료 전까지 데이터가 S3 저장되어 비용이 추가로 발생하기 때문
  • (X) S3 Transfer Acceleration 은 전송 가속화 서비스로 오히려 비용이 증가하게 됨

(4) S3 에서 정적 웹사이트를 호스팅하면 EC2 로 동적 사이트를 호스팅하는 것보다 훨씬 간편하고 저렴하게 운영할 수 있습니다. 이 때는 정적 호스팅을 위한 인덱스 및 에러 페이지와 기본적인 리소스를 버킷에 업로드하고, 퍼블릭 액세스 차단을 해제하도록 합니다.

(5) S3 의 서버 액세스 로깅(Access Logs)을 활성화하면 버킷의 모든 활동이 로그파일로 저장되어 감사 목적으로 활용할 수 있습니다. 이 때 로그파일 저장소를 같은 버킷에 두지 말아야 합니다.(무한루프의 위험) 따라서 액세스 로그 저장용 버킷을 따로 생성해 두면 좋습니다.

(6) S3 Replication(복제 규칙)이란 버킷 간에 객체를 자동으로 복제하는 기능입니다. 이를 위해 원본과 대상 버킷 모두 버전관리가 활성화되어 있어야 합니다.(다른 계정 버킷간에도 가능)

(7) S3 Glacier Vault Lock 을 사용하면 저장된 파일을 삭제하거나 편집하지 못하도록 정책적으로 잠글 수 있습니다. 이를 위해 Vault Lock 정책을 생성해야 합니다.

(8) S3 Object Lock 객체 잠금 기능을 사용하면 일정 시간 또는 무기한으로 객체가 삭제되거나 덮어쓰이지 않고 읽기만 가능하도록 할 수 있습니다.

[실전] 발송된 모든 이메일을 Amazone S3 에 12개월 동안 저장하고자 할 때 구성 단계는,

  • (1) 12개월 후에 메시지를 삭제하는 S3 수명 주기 구성을 생성하고
  • (2) 업로드된 이메일 메시지에 대해 규정 준수 모드에서 S3 객체 잠금을 사용

(9) Storage Gateway 란 온프레미스 데이터 센터의 데이터와 AWS 클라우드 스토리지를 연결하는 서비스로, S3 파일 게이트웨이, FSx 파일 게이트웨이, 볼륨 게이트웨이, 테이프 게이트웨이가 있습니다. 파일 백업, 클라우드 파일 저장소, 재해복구 등의 용도로 사용하며, 이를 통해 온프레미스 스토리지 비용 절감 효과가 있습니다.

[실전] Storage Gateway 는 온프레미스 데이터 센터에 NFS 서버가 존재할 때, 온프레미스 애플리케이션의 데이터에 대한 짧은 지연 시간 액세스를 유지하면서 애플리케이션 데이터를 온프레미스에서 AWS 클라우드로 마이그레이션해야 하는 경우 사용합니다.

  • 여기서 마이그레이션이라고 했지만 엄밀히는 지속적인 연결로 파일을 전송하는 것임
  • 짧은 지연 시간 액세스 유지를 위해서는 Storage Gateway 의 S3 File Gateway 의 온프레미스 캐싱 기능을 사용. 디렉토리 액세스 빈도에 따라 로컬 캐시를 AWS 스토리지와 동기화할 수 있음

[실전] Storage Gateway 구성을 위해 온프레미스에 클라이언트 환경을 구성해야 하지만 컴퓨팅 리소스가 없는 작은 데이터 클로짓(small room)인 경우, 하드웨어 어플라이언스를 설치하여 AWS 에 연결할 수 있도록 합니다.

AWS Storage Gateway

(10) FSx for Lustre 는 리눅스 환경을 위한 고성능 병렬 스토리지 시스템(DFS, Distributed File System)으로 머신 러닝, 빅데이터 등 고성능 컴퓨팅(HPC, High Performance Computing)을 위해 사용할 수 있습니다.

Lustre 의 배포 옵션은 다음과 같습니다.

[실전] 일기 예보 회사는 서브밀리초 지연 시간으로 수백 기가바이트의 데이터를 처리해야 합니다. 회사는 데이터 센터에 고성능 컴퓨팅(HPC) 환경이 있고 예측 기능을 확장하고자 합니다. 솔루션 설계자는 대량의 지속적인 처리량을 처리할 수 있는 클라우드 스토리지 솔루션을 식별해야 합니다. 솔루션에 저장된 파일은 전체 데이터 세트에 동시에 처리할 수천 개의 컴퓨팅 인스턴스에 액세스할 수 있어야 합니다.

  • 해결: 대량의 지속적인 처리량과 함께 수천 개의 컴퓨팅 인스턴스에 액세스해야 하므로 Lustre 영구(지속적) 파일 시스템에 Amazon FSx 를 사용
  • (X) EFS 는 고성능 병렬처리 전용이 아님

(11) FSx for Windows File Server 는 윈도우 서버를 위한 파일 공유 서비스이며, 리눅스 파일 공유 스토리지 서비스인 EFS(Elastic File System) 와 비교할 수 있습니다. EFS 가 NFS 프로토콜을 사용하는 반면 이것은 SMB 프로토콜을 사용하며, EFS 와 같이 네트워크 파일 공유 서비스이기 때문에 온프레미스 서버에서도 접근할 수 있습니다.

[실전] 회사는 직원들에게 기밀 및 민감한 파일에 대한 보안 액세스를 제공해야 합니다. 회사는 승인된 사용자만 파일에 액세스할 수 있도록 하려고 합니다. 파일은 직원의 장치에 안전하게 다운로드되어야 합니다. 파일은 온-프레미스 Windows 파일 서버에 저장됩니다. 그러나 원격 사용량 증가로 인해 파일 서버의 용량이 부족합니다. 이러한 요구사항을 충족하는 솔루션은,

  • 해결: 파일을 Amazon FSx for Windows 파일 시스템으로 마이그레이션하고 온프레미스 Active Directory 와 통합한 후 AWS 클라이언트 VPN 을 구성

(12) Snow Family 는 데이터를 네트워크가 아닌 물리적인 장치에 저장하여 전송할 수 있는 디바이스입니다. 오프라인 데이터 전송 방식이므로, 네트워크 연결이 안정적이지 못한 환경이나 강력한 보안을 요하거나 데이터센터 자체의 마이그레이션을 위해 사용할 수 있습니다.

[실전] 문제에서 네트워크적인 제약사항이 존재한다면 Snowball 엣지 디바이스 사용을 고려해야 합니다.

[실전] 온프레미스 NFS 에서 S3 Glacier 로 750TB 의 데이터를 전송해야 합니다. 마이그레이션은 온프레미스 10Mbps 인터넷 연결을 포화시키지 않아야 합니다.

  • 10Mbps 면 너무 느린 환경임(보통 속도 500Mbps)
  • 해결: 인터넷망 사용이 어려우므로 Snowball Edge Storage Optimized 장치 10 개를 주문하고 S3 버킷을 대상으로 선택. S3 수명 주기 정책을 생성하여 객체를 S3 Glacier 로 전환

[실전] 150TB 의 아카이브된 이미지 데이터를 다음 달 기한 내 AWS 클라우드로 마이그레이션해야 합니다. 회사의 현재 네트워크 연결은 야간에만 이 목적을 위해 최대 100Mbps 의 업로드를 허용한다고 합니다. 이 때 적절한 솔루션은,

  • 해결: 보통 네트워크 제약사항이 있으면 Snowball 디바이스를 주문하여 데이터를 AWS 로 배송. Snowmobile 장비는 페타바이트 규모이기 때문에 부적절
  • (X) 100Mbps 네트워크로 150TB 전송하려면 132일이 소요되므로 S3 Transfer Acceleration 이나 VPN 연결 후 기한 내 전송은 불가능

(13) AWS DataSync 는 완전 관리형 데이터 마이그레이션 서비스로, 온프레미스와 AWS 간 또는 AWS 스토리지 서비스 간 데이터 전송 및 복제를 자동화할 수 있습니다.

[실전] DataSync 는 마이그레이션 서비스로, 온프레미스와 AWS 스토리지 간 지속적 연결 서비스인 Storage Gateway 와는 차이가 있음

[실전] DataSync 는 스케줄에 따라 마이그레이션이 동기화되므로, 특정 시점의 스냅샷을 AWS 에 복제하는 배치 작업을 예약할 필요가 없음

[실전] 온프레미스 NFS 서버에서 AWS S3 버킷으로 온라인 마이그레이션하려고 합니다. 전송 중 및 전송 종료 시 데이터 무결성 확인 및 암호화가 필요한 경우, DataSync 를 사용합니다.

(14) AWS Backup: AWS 는 다양한 스토리지 서비스의 백업을 중앙집중식 서비스로 제공합니다. 다만 EBS 는 자체적인 스냅샷/백업 시스템을 가지고 있습니다.

[실전] 회사의 인프라는 EBS 스토리지를 사용하는 수백 개의 EC2 인스턴스로 구성됩니다. 재해 발생 후 모든 EC2 인스턴스를 복구할 수 있도록 해야 할 때, 최소한의 노력으로 구성 가능한 솔루션은,

  • 해결: 수백 개의 인스턴스 백업 및 복구를 위해 AWS Backup 을 사용하여 전체 인스턴스에 그룹에 대한 백업 계획을 설정
  • (X) EBS 만 백업 대상이라면 스냅샷을 사용할 수 있겠으나, 수백 개의 EC2 인스턴스를 일일히 백업 및 복구할 수는 없음


글로벌 전송

(1) 글로벌 배포 서비스인 CloudFront 는 콘텐츠 전송 네트워크 서비스, 즉 AWS 에서 제공하는 CDN(Contents Delivery Network) 서비스입니다. 전 세계에 배포된 200개 이상의 엣지 로케이션을 이용해 가까운 지역에 콘텐츠를 빠르게 전송합니다.

(2) CloudFront 의 배포 예제로는, 오리진 S3 버킷으로 정적 퍼블릭 웹사이트를 생성하고 그것을 토대로 CloudFront 배포를 생성하는 것이 있습니다.

[실전] S3 호스팅 + CloudFront: 오리진 S3 버킷에 대한 부하를 줄이고, 글로벌 단위로 콘텐츠를 제공하는 애플리케이션 서비스를 배포

  • 원본 부하를 줄이려면 사실상 원본에 대한 직접적 액세스를 제한해야 하므로,
  • 아래 CloudFront 보안에서 OAI 접근 제어를 적용하고 원본과 연계된 CloudFront 의 도메인을 고객에게 제공해야 함

[실전] CloudFront 배포 목적이 각 지역별 HTTP 프로토콜의 콘텐츠 제공 최적화라면, AWS Global Accelerator 의 목적은 TCP/UDP 계층 수준에서 라우팅 경로 최적화(Anycast)에 있음.

  • 즉, 전자는 가까운 지역에서 빠른 콘텐츠 제공의 목적이고, 후자는 가장 최적화된 경로 찾기의 목적임

[실전] CloudFront 로 배포된 S3 정적 호스팅의 가용성을 높이기 위해서는, (1) S3 리전 간 복제로 다른 리전에 복제본을 생성하고, (2) 복제본 리전을 바라보는 오리진을 생성하고, (3) 기존 오리진 버킷을 기본으로 하고 복제본 오리진 버킷을 보조로 하는 CloudFront 오리진 그룹을 설정하면 됩니다.**

[실전] 정적 및 동적 콘텐츠를 전 세계 사용자에게 가능한 한 빨리 제공하려면 단일 리전에 인프라(ELB+EC2 등)를 구축하고 CloudFront 를 구성하여 해당 리전의 ELB 를 오리진으로 설정하면 됩니다.

  • (X) 두 AWS 리전에 인프라를 구축한다 해도 수많은 엣지 로케이션에서 콘텐츠를 제공하는 CloudFront 보다 빠르거나 효율적일 수 없음
  • (X) 동적 콘텐츠 또한 ELB 에서 직접 제공하는 것보다 CloudFront 오리진으로 설정해서 제공하는 것이 빠름. 엣지 로케이션은 AWS 자체의 고속 네트워크를 사용하기 때문임

(3) CloudFront 의 보안은 다음과 같습니다.

[실전] S3 호스팅 시, 회사의 보안 정책에 따라 모든 웹 사이트 트래픽을 AWS WAF 에서 검사해야 하는 경우, “트래픽 ==> WAF + CloudFront + S3 origin” 형태로 구성

  • WAF ACL 은 CloudFront 를 대상으로 생성되고, 모든 트래픽이 이 WAF 를 거치려면 CloudFront 를 거치도록 해야함
  • 이를 위해 S3 오리진에 직접적인 액세스는 원천적으로 막아야 함 -> S3 오리진 정책에서 연계된 CloudFront OAI 만 허용하도록 지정해야 함
  • (X) WAF <==> S3 origin 직접 설정은 불가능함
  • (X) S3 에 보안 그룹(SG) 적용은 불가능함
  • (X) CloudFront 에 IP 특정도 불가능함 WAF+CloudFront+S3 image from xp-cloud.jp

[실전] 애플리케이션을 위한 CloudFront 배포를 생성합니다. 사용자가 제출한 일부 정보는 중요하여 애플리케이션은 HTTPS 를 사용하지만 다른 보안 계층이 필요합니다. 민감한 정보는 전체 애플리케이션 스택에서 보호되어야 하고, 정보에 대한 최종 액세스는 특정 애플리케이션으로 제한되어야 할 때,

  • 해결: 민감한 정보를 전체 애플리케이션 스택에서 보호하고, 정보에 대한 최종 액세스를 특정 애플리케이션으로 제한하라는 의미는 사용자 제공 데이터를 암호화 하라는 것. 따라서 CloudFront 필드 수준 암호화 프로필을 구성!

(4) Global Accelerator 는 글로벌 서비스로써, 요청을 보낸 사용자로부터 가장 가까운 위치로 트래픽을 라우팅하여 인터넷 대기시간을 줄이고 전송 성능을 향상시키는 서비스입니다.

[실전] 전 세계의 기자는 RTMP 프로토콜 방식의 라이브 스트림을 AWS 에서 호스팅되는 방송 시스템 솔루션으로 보내고, 솔루션은 브로드캐스팅 시스템에 대한 가속화된 TCP 연결을 다시 제공하는 구조입니다.

  • 문제: 기자에게 최고 품질의 스트림을 보낼 수 있는 솔루션을 설계하려면?
  • 해결: TCP/UDP 전송 계층(4 Layer)의 RTMP 프로토콜을 사용하고 가속화된 TCP 연결 브로드캐스팅을 지원해야 하므로, Global Accelerator 를 사용해야 함
  • (X) CloudFront 는 CDN 서비스로 HTTP 계층의 콘텐츠 제공에 적합한 솔루션.

[실전] 서로 다른 리전에서 ALB 를 사용하는 애플리케이션 환경이 존재할 때, 회사의 네트워킹 팀은 연결을 활성화하기 위해 온프레미스 방화벽에 ALB 의 IP 주소를 허용해야 합니다. 최소한의 구성 변경으로 가장 확장성 있는 솔루션은,

  • 해결: ALB 에는 고정 IP 할당이 불가능하므로 앞단에 Global Accelerator 를 추가하여 다른 리전의 ALB 를 가속기에 등록. 온프레미스에서는 가속기와 연결된 고정 IP 주소를 허용하도록 방화벽 규칙 업데이트
  • (X) 고정 IP 할당이 가능한 NLB 로 ALB 를 교체하는 것도 하나의 방법이겠으나, GA 추가에 비해 구성 변경이 많음


데이터베이스

(1) RDS 는 AWS 관계형 데이터베이스 서비스이며, Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server 등의 데이터베이스를 사용할 수 있습니다.

[실전] RDS PostgreSQL DB 인스턴스 사용 환경에서, 매월 초 회계 마감 기간 동안 회계사가 높은 사용량으로 인해 DB 성능에 영향을 미치는 대규모 쿼리를 실행합니다. 최소한의 노력으로 이 쿼리가 웹 애플리케이션에 미치는 영향을 최소한으로 줄이는 솔루션은?

  • (O) 읽기 전용 복제본을 만들어 보고서 트래픽을 여기에 연결. Read Replica 는 원본에 영향 없이 읽기 쿼리 성능을 향상시키는 용도
  • (X) 다중 AZ 데이터베이스는 고가용성 확보, 재해 복구를 위한 용도로 읽기 성능 향상에 적절하지 않음
  • (X) 교차 리전 읽기 전용 복제본은 리전이 달라 지연 시간이 증가할 수 있어 부적절. 동일 리전의 Read Replica 면 됨

(2) Aurora 는 RDS 호환형 관계형 데이터베이스로, AWS 에서 제공하기 때문에 저렴한 비용에 뛰어난 성능을 나타냅니다. 또한 Read Replica, Backup, Security 등 기본적인 RDS 기능들을 그대로 제공합니다.

[실전] 액세스 패턴이 드문 온프레미스 MySQL 데이터베이스가 있고, 이것을 특정 인스턴스 유형을 선택하지 않고 AWS 로 마이그레이션하려고 합니다. 앞으로 더 많은 사용자를 예상하며 다운타임이 최소화되어야 한다고 합니다.

  • 해결: 현재 액세스 패턴이 드물고 특정 인스턴스 유형을 선택하지 않으므로 Aurora Serverless 가 적절함

[실전] 회사의 애플리케이션은 데이터베이스에 Aurora 다중 AZ 배포를 사용합니다. 성능 지표를 평가할 때 데이터베이스 읽기가 높은 I/O 를 유발하고 쓰기 요청에 대기 시간이 추가되는 것을 발견했습니다. 읽기 요청과 쓰기 요청을 어떻게 분리합니까?

  • 해결: Read Replica 를 작성하고 적절한 엔드포인트를 사용하도록 애플리케이션을 수정. 즉 읽기 요청은 읽기 엔드포인트를, 쓰기 요청은 원본 엔드포인트를 사용하도록 함
  • (X) 다중 AZ 대기(Standby) 인스턴스를 생성한다는 것은 RDS 에서 Failover 를 위한 것임. Aurora 에서는 Read Replica 로 Failover 를 수행

[실전] 회사의 애플리케이션에서 사용하는 PostgreSQL 데이터베이스를 Amazon Aurora 데이터베이스로 호스팅하기로 결정했습니다. 애플리케이션이 고가용성일 필요는 없지만 데이터는 내구성을 극대화하기 위해 여러 가용 영역에 저장되어야 합니다. 이러한 요구사항을 가장 비용 효율적으로 충족하는 구성은,

  • 해결: Aurora DB 에 저장되는 데이터는 DB 인스턴스 개수에 상관 없이 기본적으로 고가용성을 만족함(컴퓨팅과 스토리지가 분리되어 있음). 따라서 가장 비용 효율적이려면 DB 인스턴스를 단일로 구성(기본 인스턴스 하나)하고, Aurora PostgreSQL DB 클러스터로 호스팅하면 됨
  • (X) 읽기 전용 복제본(Read Replica)은 고가용성을 만족하지만 다른 AZ 의 복제본마다 읽기 전용 DB 인스턴스가 추가로 생성되므로 단일 인스턴스에 비해 비용이 더 많이 나옴. 다중 AZ 배포도 마찬가지
  • (X) Aurora PostgreSQL 글로벌 데이터베이스 클러스터는 다중 리전에 복제본을 생성하므로 당연히 비용이 더 나옴

[실전] 회사는 다중 지역 재난 복구 RPO 1초이고 RTO 1분인 관계형 데이터베이스를 구현해야 합니다.

  • 해결: Aurora Global Database 를 사용. 3개 가용영역에 6개의 데이터 사본으로 구성되며 장애 시 보조 리전 중 하나가 1분 이내로 읽기/쓰기로 승격됨
  • (X) 글로벌 테이블이 있는 DynamoDB 는 관계형 데이터베이스가 아니기 때문에 조건에 부합하지 않음

(3) ElastiCache 는 인메모리 데이터 스토어로 1밀리초(마이크로초) 미만의 빠른 응답이 필요한 애플리케이션에서 사용합니다. 코드 변경이 필요하며 세션 스토어, 게임 리더보드, 스트리밍 및 분석과 같이 내구성이 필요하지 않는 기본 데이터 스토어로 사용됩니다.

[실전] 미디어 스트리밍 회사는 실시간 데이터를 수집하여 디스크에 최적화된 데이터베이스 시스템에 저장합니다. 회사는 예상되는 처리량을 알지 못하고 있으며 데이터 복제를 사용하여 더 빠르게 수행하고 고가용성을 제공하는 인-메모리 데이터베이스 스토리지 솔루션을 원합니다.

  • 해결: 인-메모리 데이터베이스를 위해 ElastiCache 를 사용하되 고가용성을 제공하는 Redis 용으로 구성

(4) DynamoDB 는 NoSQL 데이터베이스 서비스로 키-값 문서 데이터 모델을 지원합니다. 또한 서버리스 서비스라 용량에 맞게 자동으로 확장 및 축소(Auto Scaling)하므로 관리 및 운영 오버헤드가 최소화되며, 한 자리 밀리초의 매우 빠른 응답과 초당 수백만개 이상의 request 처리성능을 제공합니다.

[실전] DynamoDB 는 애플리케이션에서 사용자 데이터 등 짧은 대기 시간으로 엑세스해야 하는 Json 타입 문서 저장을 위해 사용됩니다. 또한 서버리스이기 때문에 비용효율적입니다.

[실전] DynamoDB TTL 기능 활용하기 » 시간이 지남에 따라 테이블의 크기가 커지기 때문에 더 이상 필요하지 않은 데이터를 삭제해야 하는 경우, 가장 비용효율적인 방법은 DynamoDB 의 TTL 기능을 활용하는 것입니다.

DynamoDB TTL(Time to Live)

  • TTL 을 사용하면 아이템별 타임스탬프를 정의하여 만료시점을 결정할 수 있음
  • TTL 타임스탬프가 만료된 후, DynamoDB 는 쓰기 처리량을 전혀 소비하지 않고 48시간 이내에 테이블에서 항목을 삭제함
  • TTL 활성화: 콘솔에서 Enable TTL 이후, 지정한 속성명(Attribute name)에 해당하는 속성-속성값을 새로 생성되는 아이템에 추가하도록 애플리케이션을 확장
  • 여기서 속성값이 TTL 만료기준으로 사용되므로, 숫자 형식의 Epoch 타임스탬프 값을 넣어야 함 (ex. { ‘expirationTime’: 1572268323 })
  • 주의할 점: 48시간 이내에 삭제된다 했으므로, 읽기 작업 수행 시 현재의 타임스탬프보다 만료값이 큰 경우만 가져오도록 필터하는 것이 권장됨

[실전] DynamoDB 서버리스 자동 확장 및 축소는 Auto Scaling 으로 이루어진다..!

[실전] 애플리케이션에서 사용하는 DynamoDB 테이블에 대한 많은 요청이 최신 데이터를 반환하지 않는다는 것을 발견했고 요청 대기 시간은 허용 가능한 범위라고 할 때, 강력한 일관된 읽기 요청을 사용합니다.

(5) 그 외 데이터베이스로 DocumentDB(MongoDB 호환, JSON), Keyspaces(Cassandra 호환, Wide Column 모델, 대규모 산업용), Neptune(그래프 데이터베이스, Node 간 관계, 소셜 네트워킹), Quantum Ledger Database(QLDB, 원장 레코드 DB, 은행거래), Timestream(time series, 시계열 DB, IoT 센서기록) 이 있습니다.

(6) Database Migration Service(DMS) 서비스를 활용해 온프레미스-AWS 혹은 AWS 내에서 원본 DB 를 사용하는 중에도 마이그레이션이 가능합니다. 이 기종의 DB 인 경우 Schema Conversion Tool(SCT) 를 사용해 스키마를 마이그레이션 대상에 적합하게 변환할 수 있습니다. 마이그레이션 작업을 위해서는 데이터를 옮기기 위한 중간 복제 인스턴스를 생성해야 합니다.


[다음글]

Written on January 28th, 2023 by namu
Feel free to share!

You may also enjoy: