후기
-
AWS 자격증 시험 중에서 가장 저렴하고 기본이라고 생각해서 쉽게 봤는데 고민하게 되는 문제들이 많았다.
-
AWS 자격증 강의가 도움이 많이 되었다.
-
시험에 나오는 대부분의 문제들이 포함됨
-
기본적으로 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 |
좋은 정보 감사합니다~!
답글
봐주셔서 감사합니다 :)
일부러 edit 권한을 켜 놓으신건가요?
답글
아뇨 권한을 넣진 않았습니다. 로그아웃 하고 페이지 확인해보니 수정이 불가능한 것으로 보이는데 혹시 수정이 가능하세요? 수정이 가능하다면 티스토리 문제로 보입니다.
비밀댓글입니다
답글
답변이 너무 늦었네요.
한국어로 시험 응시도 가능합니다!
저도 한국어로 시험 봤어요
시험 준비중인데 도움이 많이 됐습니다. 감사합니다.
답글
감사합니다 :)
좋은 정보 감사합니다!!!
답글
감사합니다 :)
시험 준비하면서 많은 도움이 되었습니다. 저도 무사 합격 했네요.
많은 감사 드립니다.
혹시, 저의 블로그에서 이 포스트를 소개해도 될까요?
답글
좋게 봐주셔서 감사합니다!
제가 댓글 확인이 너무 늦었네요 ㅠㅠ
마음껏 공유하셔도 됩니다 감사합니다
허가 감사합니다.
아래 저의 블로그에 소개 했습니다.
또한, 제 동료들에게 시험 보기 전, 3번 이상 공유해주신 블로그를 정독하도록 했습니다 :-)
- https://chocoball.tistory.com/entry/Software-AWS-Certified-1
좋은 하루 되세요. 감사합니다.
저보다 훨씬 잘 작성하셨네요 ㅎㅎ
저도 주변 분들께 추천드려야겠네요!
합격 축하드립니다!!
안녕하세요 좋은 정보 감사드립니다! 지금 11월 시험을 등록하고자 하는데 혹시 준비 기간은 어느 정도 잡으시고 공부하셨나요? ^^
이런 시험이 처음이라 감이 잘 안잡혀서 여쭤봅니다 ㅎㅎ
답글
안녕하세요!
클라우드 종사자 시험은 크게 부담 갖지 않고 보셔도 될 것 같아요.
저는 어소시에이트 솔루션즈 아키텍트 시험 준비를 위해 스터디 그룹을 만들어서 공부를 했는데, 클라우드 종사자 시험 준비는 포스팅에 작성한 대로만 공부만 하고 바로 시험봤습니다.
AWS 사용 경험이 있다면 어렵지 않게 합격 하실 수 있을거예요 ^^
어소시에이트 준비까지 합하면 3개월 정도 공부한 것 같네요
안녕하세요 어소에이트는 따로 리뷰하신글은 없으신가요?
답글
아 네 따로 없습니다 ㅠ 아직 시험을 안봐서요 ㅎㅎ 시험 보게 되면 리뷰글 올리도록 하겠습니다.
안녕하세요 한글말로 시험보셨을때 AWS 용어중에 예를 들어서 CloudWatch, AWS Identity and Access Management 이런 용어들도 번역해서 나오는건가요??
답글
아뇨 그렇진 않아요. 이해하는데 문제가 없을 정도로 번역되어서 나옵니다.
시험 문제는 100% 객관식인가요 아니면 주관식 객관식 섞여 있나요?
답글
100% 객관식입니다.