AWS 자격증 시험 - 클라우드 종사자(Cloud Practitioner) 후기

후기

• AWS 자격증 시험 중에서 가장 저렴하고 기본이라고 생각해서 쉽게 봤는데 고민하게 되는 문제들이 많았다.

• AWS 자격증 강의가 도움이 많이 되었다.

  • AWS Cloud Practitioner Essentials (Second Edition) (Korean)

  • AWS Cloud Practitioner Essentials (Digital)(Korean)

  • 시험에 나오는 대부분의 문제들이 포함됨

  • 기본적으로 AWS 사용 경험이 있고, 강의를 다 봤다면 충분히 합격할 듯

• 민첩성, 탄력성, 고가용성에 기반한 문제들이 많았다.

• 공동 책임 원칙, 보안에 대한 문제들도 많았다.

• 비용 관련 문제도 꽤 있었는데 Support 플랜 비교표를 본 것이 도움이 많이 되었다.

• 하이브리드 클라우드에 대한 문제도 있었다.

  • 예를 들면 하이브리드 클라우드 환경에서 사용할 수 있는 AWS 서비스는?

• 문제들이 대부분 짧았고, 서비스 선택에 대한 문제가 많아서 90분의 시험 시간은 넉넉했다.

 

 

 

아래 내용은 자격증 강의를 들으며 정리한 것들이다.

AWS 클라우드 소개

• 클라우드 컴퓨팅이란?

  • 인터넷을 통해 IT 리소스와 애플리케이션을 온디맨드로 제공하는 서비스

  • 요금은 사용한 만큼만 청구

• 기업들이 클라우드로 마이그레이션하는 주된 이유는 향상된 민첩성

민첩성 (Agility)

• 민첩성에는 다음 세가지 요소가 영향을 미침

  • 속도 (Speed)

  • 실험 (Experimentation)

  • 혁신의 문화 (Culture of innovation)

• AWS 시설이 전세계에 존재

  • IT 리소스를 수분만에 사용할 수 있으므로 조직의 민첩성 향상

  • 리소스의 빠른 사용은 빠른 테스트를 할 수 있는 환경을 제공함으로써 견고한 서비스를 제공할 수 있게됨

• CloudFormation을 사용하면 일관적이고 템플릿화된 개발 환경을 구축할 수 있고 지속적으로 향상 시킬 수 있음

AWS 인프라

• 리전 및 가용영역을 중심으로 구축

  • 리전 : 전세계에 산재한 복수의 가용영역을 포함하는 물리적 장소

  • 가용영역 : 하나 이상의 개별 데이터 센터로 구성

    • 각 데이터센터는 별도의 시설에 자리하며 예비 전력, 네트워킹 및 연결 수단을 갖춤

    • 애플리케이션 및 데이터베이스를 운영할 수 있는 기능을 제공

    • 높은 수준의 가용성(High availability), 내결함성(Fault tolerance), 확장성(Scalability) 제공

탄력성 (Elasticity)

• 탄력성은 간편하게 컴퓨팅 리소스의 규모를 확장 또는 축소할 수 있다는 것을 의미

• 사용한 실제 리소스에 대해서만 지불

• 활용

  • 새로운 애플리케이션을 신속하게 배포

  • 워크로드가 커지면 즉시 확장

  • 필요하지 않는 리소스는 축소하여 인프라 비용 감축

보안

• 클라우드 컴퓨팅 이전에는 인프라 보안 감사가 정기적으로 실시되는 수동 방식

• AWS 클라우드는 고객의 IT 리소스에 대한 구성 변경 사항을 지속적으로 모니터링 할 수 있는 거버넌스 기능 제공

• AWS 데이터 센터는 최첨단 전자식 감시 시스템과 멀티 팩터 액세스 제어 시스템을 사용

• 데이터 센터 내에는 숙련된 보안 경비가 연중무휴 대기하며 액세스에 대한 권한은 최소한의 특권을 기준으로 엄격하게 부여

• 환경 시스템은 환경파괴가 운영에 미치는 영향을 최소화하도록 설계되어 있음

• 여러 리전 및 가용영역을 사용하면 자연재해나 시스템 장애등 대부분의 장애에서도 시스템을 유지할 수 있음

• AWS 자산은 프로그래밍 가능한 리소스이기 때문에 인프라 설계 시 고객의 보안 정책을 수립하여 포함시킬 수 있음

안정성

• AWS에서의 안정성은 시스템이 인프라 또는 서비스 장애를 복구하는 능력으로 정의

• 수요에 따라 컴퓨팅 리소스를 탄력적으로 확보하고 중단 사태를 완화할 수 있는 능력에 초점을 맞춤

• AWS를 사용하면 서버나 소프트웨어 라이선스 구매 또는 시설 임대를 비롯한 고가의 인프라 구축에 소중한 리소스를 쏟아부을 필요가 없음

  • 필요한 만큼만 서비스 요금을 지불함으로써 혁신 및 발명에 집중할 수 있으므로 조달 복잡성을 줄이고, 비즈니스에 완전한 탄력성을 부여할 수 있음

AWS 글로벌 인프라

• 구분

  • 리전

  • 가용영역

  • 엣지 로케이션

리전

• 리전은 2개 이상의 가용영역을 호스팅하는 지리 영역을 의미

• 선택 시 어떤 영역이 비용을 절감하고 규제 요구사항들을 준수하면서 지연 시간을 최적으로 조정하는데 도움이 되는지 고려

  • 애플리케이션을 여러 리전에 쉽게 배포 가능

• 리전은 서로 완전히 독립된 엔터티(entity)이며, 한 리전의 리소스는 다른 리전으로 자동 복제되지 않음

가용영역

• 가용영역은 특정 리전 내에 존재하는 데이터 센터들의 모음을 의미

• 가용영역들은 서로 격리되어 있으며 빠르고 지연시간이 짧은 링크에 의해 연결됨

• 각 가용 영역은 물리적으로 구분된 독립적 인프라에 속함

• 물리적, 논리적으로 분리됨

• 각 가용영역은 별도의 무정전 전원공급장치(UPS), 현장 예비 발전기, 냉각장비, 네트워킹 및 연결수단을 자체적으로 갖추고 있음

• 가용영역들은 모두 독립적인 전력 회사의 서로 다른 전력망을 통해 전력이 공급되며 여러 티어1 전송 서비스 공급자를 통해 연결됨

• 서로 격리되어 있기 때문에 한 AZ의 장애로부터 다른 AZ를 보호할 수 있음

• 다중 AZ에 걸쳐 인프라를 프로비저닝하는 것이 좋음

엣지 로케이션

• 엣지 로케이션은 Amazon CloudFront라는 CDN(콘텐츠 전송 네트워크)을 호스팅

• ClondFront는 콘텐츠를 고객에게 전송하는데 사용

• 콘텐츠에 대한 요청이 가장 가까운 엣지 로케이션으로 자동 라우팅되므로 콘텐츠가 더욱 빨리 최종 사용자에게 전송됨

• 여러 엣지 로케이션과 리전으로 구성된 글로벌 네트워크를 활용하면 보다 빠른 콘텐츠 전송에 액세스 할 수 있음

• 엣지 로케이션은 대체로 인구 밀도가 높은 지역에 위치함

  • 리전과 가용영역도 마찬가지임

Amazon Virtual Private Cloud(VPC)

• 사용자의 네트워킹 요구사항들을 충족할 네트워킹 AWS 서비스

• 온프레미스 네트워크와 동일한 여러 가지 개념 및 구성을 사용하는 AWS 클라우드 내 프라이빗 네트워크를 생성할 수 있음

• 제어, 보안 및 유용성을 저해하지 않고도 네트워크 설정의 복잡성이 상당 부분 추상화되어있음

• 고객은 IP 주소 공간, 서브넷, 라우팅 테이블과 같은 일반 네트워킹 구성 항목들을 정의할 수 있음

• 인터넷에 노출시킬 리소스들과 격리시켜야할 리소스들을 제어할 수 있음

• 네트워크의 보안 제어를 계층화하기 위한 방편으로 배포할 수 있음

  • 서브넷 격리, 엑세스 제어 목록 정의, 라우팅 규칙 사용자 지정을 포함

• 수신 트래픽과 송신 트래픽을 모두 허용 및 거부하도록 완벽하게 제어 가능

• VPC에 배포되는 수많은 서비스들은 모두 클라우드 네트워크에 구축된 보안을 상속하고 활용하게됨

AWS 서비스들과의 통합

• EC2 인스턴스는 VPC에 배포됨

• RDS 데이터베이스 인스턴스도 VPC에 배포됨

  • 데이터베이스는 온프레미스 네트워크와 똑같은 네트워크 구조를 통해 보호됨

VPC의 기능

• VPC는 리전 내에 있으며 여러 가용영역에 걸쳐 확장할 수 있음

• 각 AWS 계정은 다중 VPC를 생성하여 서비스 환경을 분리할 수 있음

• VPC는 여러 서브넷에 의해 분할되는 하나의 IP 주소 공간을 정의

  • 서브넷이 가용영역 내에 배포되기 때문에 VPC는 가용영역을 확장함

• 하나의 VPC에서 많은 서브넷을 생성할 수 있지만 네트워크 토폴로지의 복잡성을 제한하기 위해 서브넷 수는 적게 유지하는 것을 권장하지만 전적으로 사용자에게 달려 있음

• 서브넷과 인터넷 사이의 트래픽을 제어하기 위해 서브넷에 대한 라우팅 테이블을 구성할 수 있음

• 기본적으로 VPC 내 모든 서브넷들은 서로 통신할 수 있음

• 서브넷은 일반적으로 퍼블릭 또는 프라이빗으로 분류됨

  • 퍼블릭으로 설정하려면 인터넷 게이트웨이를 VPC에 연결하고 퍼블릭 서브넷의 라우팅 테이블을 업데이트하여 외부로 가는 트래픽을 인터넷 게이트웨이로 전송해야함

  • EC2 인스턴스 역시 인터넷 게이트웨이로 라우팅하려면 퍼블릭 IP가 필요

• IP 주소 할당에는 CIDR(Classless Inter-Domain Routing) 형식을 사용하는데 이는 VPC에서 사용할 수 있는 IP 주소의 수가 65,000개가 넘는 다는 것을 의미

AWS Security Groups

• 보안 그룹은 사용자의 가상 서버를 위한 내장 방화벽과 같이 작동

• 인스턴스에 대한 접근성을 완벽하게 제어할 수 있음

• 가장 기초적인 수준에서 인스턴스에 대한 트래픽을 필터링하는 여러 방법 중 하나에 불과함

  • 특정 트래픽을 허용 또는 거부하도록 설정할 수 있음

컴퓨팅 서비스

• AWS를 사용하면 컴퓨팅 요구를 워크로드에 맞게 조정할 수 있음

• 확장성은 컴퓨팅 서비스에 내장되어 있기 때문에 수요가 증가하면 쉽게 확장 가능

• 수요가 감소할 경우에도 규모를 축소하여 비용과 리소스를 절감할 수 있음

• EC2 서비스는 단순한 웹 서버부터 대규모 머신러닝 클러스터에 이르기까지 모든 유형에 적합한 다양한 가상 서버 인스턴스 유형을 제공함

  • 사용자는 특정 하드웨어 구성에 얽매이지 않고 인스턴스 유형을 쉽게 변경할 수 있음

• 온프레미스 환경과 달리 온디멘드 가격을 적용하여 필요에 따라 리소스를 비용 효율적으로 확장 및 축소할 수 있음

• AWS Lambda를 사용하면 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있음

  • 사용한 컴퓨팅 시간에 대한 비용만 지불

• 간단한 웹사이트 또는 전자 상거래 애플리케이션을 실행해야 하는 경우 Amazon Lightsail 권장

  • 하나의 가상 프라이빗 서버를 단 몇분만에 시작할 수 있음

  • 간단한 웹 서버 및 애플리케이션 서버를 쉽게 관리할 수 있음

  • 저렴하면서 예측 가능한 가격으로 프로젝트에 필요한 모든 것을 포함함

    • 가상머신, SSD 기반 스토리지, 데이터 전송, DNS 관리, 정적 IP 주소 등

• 컨테이너를 사용하는 경우 Amazon ECS 권장

  • Docker 컨테이너를 지원하는 확장성과 성능이 뛰어난 컨테이너 관리 서비스

  • 자체적으로 클러스터 관리 인프라를 설치하기 때문에 운영 및 확장을 신경쓸 필요가 없음

Amazon Elastic Compute Cloud(EC2)

• EC2의 Elastic이라는 단어는 하나의 애플리케이션에 대한 현재의 수요에 따라 필요한 서버의 수량으로 자동 증감할 수 있다는 사실을 의미

• AWS에서는 애플리케이션이 구동되는 서버를 EC2 인스턴스라고 부름

• 인스턴스는 종량 과금제 방식으로 요금이 부과됨

  • 실행 중인 시간에 한해서만 요금 지불

• 다양한 하드웨어 및 소프트웨어, 인스턴스를 호스팅할 위치 등을 선택할 수 있음

AWS Lambda

• 이벤트 중심의 서버리스 컴퓨팅 서비스

• 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 컴퓨팅 서비스

• 필요할 때에만 코드를 실행하며 초당 수천 건의 요청으로 자동 확장됨

• 사용한 컴퓨팅 시간에 대해서만 요금 지불

• 가변적이고 단속적인 워크로드에 적합

• 거의 모든 애플리케이션 또는 백엔드 서비스에서 별도의 관리 없이 코드를 실행할 수 있음

• Lambda는 고가용성 컴퓨팅 인프라에서 코드를 실행하고, 서버 및 운영체제 유지 관리, 용량 프로비저닝, 오토스케일링, 코드 모니터링, 로깅 등은 AWS가 관리함

• Node.js, Java, C#, Python 등 다양한 언어를 지원

• Lambda는 서버리스 및 마이크로서비스 애플리케이션을 지원하기 위한 서비스

• 모놀리식 솔루션의 생성을 방지하기 위해 AWS Lambda는 다음 제한을 두고 있음

  • 디스크 공간은 512MB로 제한

  • 메모리는 128 ~ 1536MB까지 할당 가능

  • 최대 5분까지만 실행

  • 배포 패키지 크기와 최대 File Descriptor 수에 의해 제한됨

  • Request, Reponse의 Body Payload는 6MB를 초과할 수 없음

  • 이벤트 Request Body는 128KB로 제한됨

  • 동시 실행 횟수는 Soft LImit에 속하고, 요청 시 증가할 수 있음

사용 예

• 백업 자동화

• S3에 업로드된 객체의 처리

• 이벤트 중심의 로그 분석

• 이벤트 중심의 변환

• 사물 인터넷(IoT)

• 서버리스 웹 사이트 운영

• S3 버킷 또는 DynamoDB 테이블의 변경 이벤트에 대한 응답으로 Lambda 코드를 실행할 수 있음

• Amazon API Gateway를 사용하여 HTTP 요청에 응답하여 Lambda 코드를 실행할 수 있음

• AWS CodePipeline, CodeDeploy를 사용하면 함수를 자동으로 배포할 수 있음

• Kinesis에서 스트리밍 되는 데이터를 Lambda를 사용하여 추출, 변환, 로드(ETL) 파이프라인을 구축할 수 있음

• 많은 고객이 Lambda, Amazon SNS, API Gateway를 이용한 마이크로 서비스 백엔드를 사용하여 웹사이트와 모바일 애플리케이션을 실행

AWS Elastic Beanstalk

• PaaS 서비스

  • 사용 중인 코드를 필요에 따라 시스템에 간단히 배치할 수 있도록 전체 인프라와 전체 플랫폼을 생성하여 제공

• PaaS 서비스를 사용하면 사용자의 애플리케이션을 신속하게 배포할 수 있음

• 관리상의 복잡성을 줄여줌

• 사용자가 전체 시스템을 제어할 수 있음

  • 인스턴스 유형 선택

  • 데이터베이스 선택

  • 오토스케일링 설정

  • 애플리케이션 업데이트

  • 로그 파일 액세스

  • 로드밸런싱 설정

• 다양한 언어로 제작된 애플리케이션 수용

• 애플리케이션을 위한 환경을 생성

  • 웹 서버 환경

  • 사용자의 필요한 설정을 입력할 수 있음

• 어플리케이션 실행에 필요한 파일을 S3에 업로드하고 Beanstalk에서 가져다 사용할 수 있음

Application Load Balancer

• Classic Load Balancer가 제공하는 기능을 대부분 제공

• HTTP/2 및 WebSockets 지원이 추가됨

• 지표 및 액세스 로그가 개선되었으며 상태 확인 대상이 확대됨

  • Request 추적을 사용하여 클라이언트에서 대상까지 요청을 추적할 수 있음

• 경로 또는 호스트 기반 라우팅을 사용하는 요청에 대한 추가 라우팅 매커니즘 제공

  • 경로 라우팅으로 Request 내 URL을 기반으로 대상 그룹으로 라우팅하는 규칙 생성 가능

  • 호스트 기반 라우팅으로 동일한 로드밸런서가 여러 도메인을 지원할 수 있음

    • 요청된 도메인을 기반으로 Request를 해당 대상 그룹으로 라우팅

• ALB에서는 리스너라는 개념을 사용하는데 인스턴스 대신 대상 그룹이 등록됨

• ECS 예약 컨테이너 사용 시 동적 호스트 포트를 설정할 수 있음

Amazon Elastic Load Balancer

• 유일하게 노출되는 액세스 포인트를 통해 웹 서버 액세스를 보호하거나 애플리케이션 환경을 결합, 해제하거나 퍼블릭 및 내부 로드밸런서를 함께 사용하거나, 트래픽을 여러 가용영역으로 분산하여 고가용성 및 내결함성을 제공하거나 최소한의 오버헤드로 탄력성 및 확장성을 제공할 수 있음

• TCP 요청을 분산하는 경우 단순 라운드 로빈 사용

• HTTP, HTTPS 요청을 처리하는 경우 백엔드 인스턴스에 대해 최소 대기 요청 사용

• 여러 가용 영역으로 트래픽을 분산하는 것을 도움

• 애플리케이션에 쿠키를 사용하려는 경우 ELB는 고정 세션 기능을 제공함

  • 해당 세션이 유지되는 동안 사용자 세션을 바인딩할 수 있고, 이는 기간 기반 쿠키 또는 애플리케이션 제어 고정 세션을 사용할지 여부에 따라 결정 됨

• 백엔드 EC2 인스턴스의 Health Check를 위해 간단한 연결 시도 또는 Ping 사용

• Classic Load Balancer에서는 여러 유형의 로드밸런서를 생성 가능

  • 인터넷 경계 또는 퍼블릭 로드 밸런서 : 교차 영역에 밸런싱이 가능하고 로드밸런서에 유일하게 노출되는 엔드포인트를 통해 백엔드 인스턴스로 요청을 라우팅할 수 있도록 DNS 이름 제공

    • 노드는 퍼블릭 IP 주소를 가지고, DNS 이름은 노드의 퍼블릭 IP 주소로 공개적으로 확인이 가능

    • 인터넷 경계 로드 밸런서는 인터넷을 통해 클라이언트의 요청을 라우팅할 수 있음

  • 내부 로드 밸런서 : 노드는 오직 프라이빗 IP 주소만 가짐

    • 내부 로드 밸런서의 DNS 이름은 노드의 프라이빗 IP 주소로 공개적으로 확인이 가능

    • 내부 로드 밸런서는 로드 밸런서를 위한 VPC에 액세스하여 클라이언트의 요청만 라우팅할 수 있음

Auto Scaling

• 애플리케이션 로드를 처리할 수 있는 적절한 수의 EC2 인스턴스를 유지하도록 함

• EC2 인스턴스에서 애플리케이션을 실행할 때 Amazon CloudWatch를 사용하여 워크로드의 성능을 모니터링

• CloudWatch 자체로는 EC2 인스턴스를 추가하거나 제거할 수 없고, Auto Scaling을 사용

• Auto Scaling을 위해 다음 요소들이 필요

  • 시작 구성 : Auto Scaling이 시작할 인스턴스를 정의

    • 인스턴스 유형, 보안그룹, 역할 등

  • Auto Scaling 그룹 : 배포가 이루어지는 위치와 배포에 대한 제한을 정의

    • VPC, 로드밸런서 등

  • Auto Scaling 정책 : EC2 인스턴스를 시작 또는 종료할지를 지정

    • 시간을 예약하거나 임계값을 설정

Amazon Elastic Block Store(EBS)

• EC2 인스턴스의 저장 단위로 사용

• 인스턴스에 디스크 공간이 필요한 경우 언제나 EBS 볼륨 사용을 고려

• 하드 디스크나 SSD 일 수 있음

• 사용한 만큼만 지불

• EBS 볼륨은 내구성과 가용성을 위주로 설계됨

• 볼륨에 있는 데이터가 가용영역에서 실행되는 복수의 서버에 걸쳐 자동 복제됨

• 볼륨 생성 시 스토리지 유형을 선택 할 수 있음

  • 하드 디스크 또는 SSD

• 볼륨의 시점 별 스냅샷을 생성하여 한층 더 높은 수준의 데이터 내구성을 구현할 수 있음

• 스냅샷을 공유하거나 다른 AWS 리전에 복사할 수 있음

  • 이로 인해 재해복구(DR) 성능이 높아짐

• 추가 비용 없이 EBS 볼륨을 암호화 할 수 있음

  • EC2 인스턴스와 AWS 데이터 센터 내부의 EBS 볼륨 간에 이동하는 데이터가 암호화 되어 전송됨

• EBS 볼륨은 용량 증가와 여러 유형간의 변환이 가능

  • 인스턴스 중단 없이 바로 운영 규모를 조정할 수 있음

Amazon Simple Storage Service(S3)

• 데이터 저장 및 검색을 위한 간단한 API를 제공해주는 완전 관리형 스토리지 서비스

• S3에 저장하는 데이터는 임의의 특정 서버와 연계되어 있지 않기 때문에 고객이 직접 인프라를 관리할 필요가 없음

• 원하는 만큼 많은 객체를 S3에 저장할 수 있음

• S3는 수조개의 객체를 저장하며 정기적으로 최대 초당 수백만건의 요청을 처리

• 객체는 이미지, 동영상, 서버 로그 등 거의 모든 유형의 데이터 파일을 수용

  • 수 테라바이트 크기의 객체까지 지원하기 때문에 데이터베이스 스냅샷도 객체처럼 저장 가능

• 인터넷(HTTP, HTTPS)를 통한 데이터 액세스 지연 시간이 짧기 때문에 언제 어디서든 데이터를 검색할 수 있음

• 가상 사설 클라우드 엔드포인트를 통해 S3에 비공개적으로 액세스할 수 있음

• ID, 액세스 관리 정책, 버킷 정책, 객체별 엑세스 제어 목록을 사용하여 데이터 엑세스를 허용하는 사용자를 정밀하게 관리할 수 있음

• 기본적으로 데이터는 Public 공개되지 않음

• 데이터를 전송 중에 암호화하고 객체에 대한 서버측 암호화를 활성화 할 수도 있음

• 버킷을 S3에 생성하면 특정 AWS 리전과 연계됨

• 버킷에 데이터를 저장할 때마다 선택한 리전 내에 있는 복수의 AWS 시설에 중복 저장됨

• S3 서비스는 두 AWS 시설에 있는 데이터가 동시에 훼손되는 경우에도 데이터가 안전하게 저장되도록 설계되어 있음

• S3 서비스는 확장/축소가 가능하기 때문에 대용량의 볼륨 요청도 처리할 수 있음

• 스토리지나 처리량을 직접 프로비저닝할 필요 없이 사용한 만큼만 지불

• 관리 콘솔, AWS CLI, SDK를 통해 S3에 액세스 가능

• REST 엔드포인트를 통해 버킷에서 직접 데이터에 엑세스 가능

  • HTTP, HTTPS 지원

• URL 기반 액세스를 지원하기 위해서는 S3 버킷 이름이 전 세계적으로 고유해야 하고, DNS를 준수해야 함

• 객체 키가 URL에 대해 안전한 문자를 사용해야함

• 사실상 데이터를 무제한 저장하고 어디서든 데이터에 액세스할 수 있는 유연성 덕분에 다양한 시나리오에 적합

• S3는 스토리지와 성능이 조정 가능하기 때문에 다양한 빅데이터 도구를 사용하여 분석하고자하는 데이터의 스테이징 또는 장기 저장에 적합

  • S3에 있는 데이터 스테이지를 Redshift에 로드하거나 EMR로 처리

  • Amazon Athena로 곧바로 쿼리

  • Snowball로 Import/Export 디바이스를 사용하여 대용량 데이터를 S3로 가져오거나 내보내기

Amazon Glaicer

• AWS의 저비용 데이터 보관 솔루션

• 자주 액세스되지는 않지만 업무상 혹은 법적 이유로 반드시 보존해야하는 콜드 데이터 보관용으로 설계

• 최대한 비용 효율적이고 효과적으로 설계할 수 있도록 돕는 것이 목표

• 데이터를 복수의 시설에, 각 시설 안에서도 여러 디바이스에 다중 저장하기 때문에 내구성이 뛰어남

• Glaicer 용어 정리

  • 아카이브(Archive) : 사진, 동영상, 파일, 문서 등과 같은 임의의 객체

    • Glacier의 기본 스토리지 단위

    • 각 아카이브는 고유 ID를 가짐

  • 저장소(Vault) : 아카이브를 저장하는 컨테이너

    • 생성 시 저장소 이름과 리전을 지정

    • 각 저장소에 대해 개별 저장소 액세스 정책을 수립

    • 잠금 정책을 사용하여 저장소 변경 방지도 가능

• S3에 보관된 파일을 더이상 사용하지 않게 되었을 때 Glaicer로 이전

  • S3 Standard Infrequent Access(SIA)로 자동 이전 되도록 설정 가능

  • 자동 이전 후 지정된 기간동안 Glaicer에서 보관하다가 삭제하도록 설정할 수 있음

• 검색 방법

  • 대량 검색(Bulk Retrieval) : 비용이 가장 저렴하고 대개 5 ~ 12시간 정도 소요됨

  • 표준 검색 (Standard Retrieval) : 3 ~ 5시간 정도 소요

  • 신속 검색 (Expedited Retrieval) : 가장 비싸고, 1 ~5분내에 검색이 완료됨

• S3와 마찬가지로 데이터를 무제한 저장 가능

• S3는 짧은 지연 시간으로 빈번하게 데이터에 액세스하는 용도로 설계되었고, Glacier는 자주 액세스하지 않는 데이터를 저 비용으로 장기간 보관하는 용도로 설계됨

• S3의 최대 항목 크기는 5TB이고, Glacier는 최대 40TB

• S3와 Glacier간 중요한 차이는 데이터 암호화 방식

  • 두 솔루션 모두 HTTPS를 통해 데이터를 안전하게 저장하지만 Glacier의 경우 모든 데이터 아카이브가 기본적으로 암호화됨

  • S3는 애플리케이션이 서버 측 암호화를 활성화해야함

Amazon Relational Database Service(RDS)

• 데이터베이스 관리 비용 없이 관계형 데이터베이스를 구축하고 운영할 수 있도록 함

  • 운영체제 설치 및 패치, 자동 백업, 고가용성 유지, 리소스 규모 조정, 전력 및 서버 관리, 유지 관리 수행 등을 AWS에서 담당

  • 기본 빌딩 블록은 데이터베이스 인스턴스

    • 사용자가 만든 여러 데이터베이스가 포함될 수 있음

  • 데이터베이스 인스턴스에 있는 리소스는 데이터베이스 인스턴스의 등급에 의해 결정되고, 스토리지 유형은 디스크 유형에 의해 정해짐

  • 데이터베이스 인스턴스를 생성하려면 먼저 데이터베이스 엔진을 지정해야함

    • MySQL, Aurora, PostgreSQL MSSQL, MariaDB, Oracle

• 데이터베이스 인스턴스는 프라이빗 서브넷에 격리되어 지정된 애플리케이션 인스턴스에서만 접근 가능

• 다중 가용영역 배포로 높은 가용성을 제공

  • RDS를 구성하면 예비 복사본을 동일한 VPC내 다른 가용영역에 자동 생성

  • RDS의 DNS 엔드포인트를 사용하기 때문에 장애가 발생하여 복제본을 사용하게 되더라도 애플리케이션의 수정은 필요 없음

• MySQL, MariaDB, PostgreSQL, Aurora는 읽기 전용 복제본 생성을 지원

  • 읽기 전용 복제본은 마스터 데이터베이스와 다른 리전에 생성 가능

• 처리량이 많고, 가용성이 높은 데이터베이스를 필요로하는 웹, 모바일 애플리케이션에 적합

• 두가지 SSD 기반 스토리지 옵션 선택 가능

  • 고성능 OLTP 애플리케이션에 최적화된 스토리지

  • 비용 효율적인 범용 애플리케이션에 최적화된 스토리지

Amazon DynamoDB

• 완전 관리형 NoSQL 데이터베이스 서비스

• AWS는 모든 기반 데이터 인프라를 관리하고 내결함성 아키텍처의 일부로 미국 리전 내에 있는 여러 시설에 걸쳐 데이터를 다중 저장

• 테이블에 저장할 수 있는 항목의 수는 사실상 제한이 없음

• DynamoDB에 있는 모든 데이터는 SSD에 저장됨

• 스토리지 규모를 조정할 수 있을 뿐만아니라 테이블에 필요한 읽기, 쓰기 처리량을 프로비저닝 할 수 있음

• AutoScaling을 활성화하여 테이블에 대한 로드를 모니터링하다가 프로비저닝되는 처리량을 자동으로 늘리거나 줄일 수 있음

• 스토리지 및 처리량 프로비저닝 측면에서 테이블의 규모를 조정할 수 있는 기능 덕분에 웹, 모바일, IoT 애플리케이션의 구조화 데이터에 적합

  • 지속적으로 데이터를 생성하고 초당 다수의 요청을 하는 클라이언트가 많을 경우에 규모 조정으로 일관된 성능을 유지할 수 있음

• 지연시간에 민감한 애플리케이션에도 적합

  • 광고나 게이밍과 같이 가변적인 지연시간이 사업 목표에 영향을 줄 수 있는 경우 유용

• 테이블 데이터는 기본키에 의해 분할 및 색인됨

• 데이터 검색 방법

  • 기본키 사용

  • 스캔 (키가 아닌 속성에 대한 조건으로 검색)

    • 테이블 내 모든 항목을 검색하여 찾기 때문에 비효율적

    • 되도록이면 키를 사용하는 검색 방법 사용을 권장

• DynamoDB 항목의 최대 크기는 400 킬로바이트

• 정리하면 DynamoDB는 확장을 통해 대량의 데이터를 저장하고 많은 요청 볼륨을 지원하고 짧은 지연 시간의 쿼리 성능을 요구하는 애플리케이션용 데이터 스토어로 활용 가능한 관리형 NoSQL데이터베이스 서비스

Amazon Redshift

• 속도가 빠른 완전관리형 데이터 웨어하우스

• 표준 SQL 및 기존 비즈니스 인텔리전스 도구를 사용하여 모든 데이터를 간편하고 비용 효율적으로 분석할 수 있게 해줌

• 정교한 쿼리 최적화, 고성능 로컬 디스크에 대한 열 형식 저장, 방대한 병렬 쿼리 실행을 통해 페타 바이트 규모의 구조화 데이터를 대상으로 복잡한 분석 쿼리를 실행할 수 있음

• 대부분의 결과가 수 초 이내에 반환됨

• 방대한 병렬 처리 아키텍처와 더불어 열 형식 스토리지 및 자동 압축 기능을 채택하여 페타바이트 규모의 데이터 세트에 대해서도 아주 빠른 쿼리 성능을 제공

• 전통적인 데이터 웨어하우스 서비스에 비해 비용이 1/10에 불과함

• Redshift Spectrum을 사용하면 엑사바이트 규모의 데이터에 대해 S3에서 직접 쿼리를 실행할 수도 있음

• 확장성이 기본적으로 제공되기 때문에 콘솔에서 간편하게 클러스터를 확장하거나 축소 가능

• 저장 및 전송 중에 데이터를 암호화하는 기능이 내장되어 있음

• 표준 SQL을 지원하고, 고성능 JDBC 및 ODBC 커넥터를 제공

Amazon Aurora

• 고성능 상용 데이터베이스의 속도와 가용성에 오픈 소스 데이터베이스의 간편성과 비용 효율성을 결합한 MySQL 관계형 데이터베이스 엔진

• 가용성이 뛰어남

  • 데이터의 복사본 6개를 세곳의 가용영역에 저장

  • S3에 지속적으로 백업

  • 최대 15개의 읽기 전용 복제본 사용 가능

  • 데이터베이스 장애 발생 후에 최근 데이터베이스 체크 포인트로부터 Redo 로그를 재현할 필요가 없음. 대신 이를 읽기 작업시에 수행하기 때문에 장애 발생 후 재시작 시간이 60초 이하로 줄어듬

  • 데이터베이스 프로세스에서 버퍼 캐시를 분리하여 재시작 즉시 사용할 수 있도록 하여 캐시가 다시 채워질 때까지 액세스를 제한할 필요가 없어 중단이 방지됨

  • MySQL보다 다섯 배 뛰어난 성능 발휘

  • InnoDB 스토리지 엔진을 사용하기 때문에 MySQL 5.6과도 즉시 호환성을 갖추고 있음

• 종량제 서비스로 실제 사용하는 서비스와 기능에 대해서만 요금 지불

• 관리형 서비스

  • 규모 조정, 높은 가용성 확보, 백업 관리, 패치 등이 자동으로 수행됨

  • AWS Database Migration Service, AWS Schema Conversion Tool과 같은 서비스와 통합되어 데이터 세트를 Aurora로 편리하게 이전

AWS Trusted Advisor

• AWS의 리소스 추적에 사용

  • AWS를 사용하다보면 점점 추적할 수 없을 정도로 많은 리소스를 보유하게 됨

  • 낭비되고 있는 리소스나 내결함성, 성능 또는 보안을 위해 최적화 되지 않은 리소스들을 보유하게 될 수 있음

• Trusted Advisor는 모든 리소스를 검사하여 각 리소스가 모범 사례에 부합하는지 확인

  • 보안, 내결함성, 성능, 비용 최적화의 범주로 검사

• CloudWatch Events와 연동하여 Lambda를 실행하게끔 해서 위반되는 리소스에 대한 조치를 자동화 할 수 있음

• 검사 예

  • 서비스의 Limits 검사

  • 자주 사용되지 않는 Access key

  • 보안 또는 성능 향상을 위한 OS 패치

  • EC2 Config를 포함한 EC2 Windows

• 등록된 이메일로 검사 내용을 요약해서 전송 가능

• CSV, Excel 형식의 파일로 보고서 다운로드

• 대시보드 형태로 검사 결과 확인

• 카카오스토리
• 트위터
• 페이스북

'Work > 개발 노트' 카테고리의 다른 글

Go언어로 웹 서버 개발 시 Swagger 문서 자동 생성하기  (0)	2020.05.05
Mac에서 VS Code 터미널 폰트 깨지는 문제  (0)	2019.06.23
AWS 자격증 시험 - 클라우드 종사자(Cloud Practitioner) 후기  (22)	2019.06.17
[양재동코드랩] 자바스크립트 강의 3일차 - Class  (0)	2018.10.13
[양재동코드랩] 자바스크립트 강의 3일차 - Generator  (0)	2018.10.13
[양재동코드랩] 자바스크립트 강의 3일차 - Array  (0)	2018.10.13