AWS Cloud Practitioner Essentials 취득하면서 공부한 내용의 정리본이다.
AWS Cloud Practitioner Essentials란?
AWS 자격증 중 가장 기초이다.
65문제를 90분 안에, 1000점 만점에 700점 이상이 합격점이다.
비영어권 국가일 경우 시험시간 30분 추가할 수 있다. (혜택 페이지에서 신청해야 함)
가격 : 100USD
aws에서 기본적으로 제공하는 동영상 강의가 있다.
이를 수강하면서 많은 도움이 되었다.
AWS 클라우딩 모델 => 클라이언트-서버 모델
Ex) 커피숍
서버 = 바리스타
클라이언트 = 고객
- Amazon EC2 instance (바리스타, 즉 서버 역할)
- 정당한지 검증 (돈이 지불되었는지 확인)
- 결과 반환 (커피 증정)
AWS 핵심개념
- 종량과금제 (지불한만큼 지급)
직원이 일을 하지 않는 시간에 급여를 주지 않는 것과 같음
핵심 가치 : 필요한 만큼 지불
클라우드 컴퓨터란?
: 종량 과금제 요금으로 인터넷을 통해 온디맨드로 필요에 따라 IT 리소스를 제공
- 미리 통보하지 않고도 필요한 스토리지를 필요한 시기에 사용할 수 있음.
- 필요하지 않을 때는 반환하여 비용지불을 중단할 수 있음
+ 유연성. 직접 운용하는 데이터 센터에서는 불가능한 일.
AWS에 왜 이렇게 많은 제품이 있을까?
: 많은 기업에서 원하기 때문에
- IT의 획일적인 작업 = 공통적이고, 반복되고, 시간이 오래 걸리는 작업
- AWS에서 이 일을 돕고, 기업에서는 기업의 “차별화 요소”에 집중하면 됨.
클라우드 컴퓨팅을 위한 배포 모델
- 클라우드 기반 배포 (AWS 형식, 클라우드 사업자가 IT 인프라를 기업, 개인에 제공)
- 온프레미스 배포 (기업이 자체적으로 IT 인프라를 소유, 관리 및 운영하는 경우 : On-Premise)
- 하이브리드 배포 (기존 인프라와 애플리케이션을 클라우드 기반 리소스에 연결하는 방식으로 배포)
Amazon EC2 (Elastic Compute Cloud)란?
서비스를 운영하기 위해 “서버”가 필요하다
이 서버를 이용해서 웹 애플리케이션을 호스팅하고 기업에 필요한 용량을 제공.
AWS를 사용하는 경우, 서버가 물리적인 서버가 아니라 인터넷을 통해서 접근할 수 있는 가상화되어 있는 서버이다.
EC2 = 가상화된 서버에 액세스하는데 사용하는 서비스 / 즉, 서버 액세스 서비스
On-premise 배포
- 하드웨어 구매, 배달까지 기다리고 물리적 데이터 센터에 서버 설치 … etc
- 가장 안좋은 점, 서버를 구매하면 사용의 여부에 상관없이 무조건 보유해야함
- 하지만 EC2를 시작하면 매우 간단하다
AWS는 이미 데이터센터를 구축, 데이터 보안 역시 검증됨.
몇 분이면 Amazon EC2 인스턴스를 provisioning 하고 시작할 수 있음.
실행중인 인스턴스에만 비용을 지불하고, 중지 또는 종료되면 지불하지 않음.
EC2는 가상화라고 하는 기술을 통해 AWS에서 관리중.
AWS에서 관리하고 있는 물리적 호스트 시스템에서 실행 => 전체 호스트를 다 소유하지 않아도 됨. 대신 호스트를 다른 여러 인스턴스와 공유하여 사용. 이러한 방식을 가상머신이라고 함.
멀티테넌시(Multitenancy) : 가상 컴퓨터간 기본 하드웨어 공유
리소스를 공유할 수 있지만, 호스트에 있는 다른 리소스는 인식하지 못함
안전하면서 분리되어 있음
프로비저닝 (provisioning) : “제공하는 것”, 어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공하는 것. 제공하는 것은 인프라 자원이나 서비스, 또는 장비가 될 수도 있음.
Amazon EC2 인스턴트 유형
EC2 => 클라이언트의 요청을 처리하는 직원에 해당.
모든 직원이 카운터를 보지 않음. 다양한 작업을 수행 (커피를 내리거나, 라떼아트를 하거나 ..)
비즈니스에서 최대의 효율을 내기 위해, 직원의 기술이 각자의 역할에 적합한지 확인해야 함.
다양한 유형의 EC2 인스턴스로 구성됨.
각 EC2 인스턴스 유형은 인스턴트 패밀리로 구분되며, 특정 유형의 작업에 최적화함.
- 범용 인스턴스 : 컴퓨팅, 메모리, 네트워킹 리소스를 균형있게 제공 (애플리케이션 서버, 게임 서버, 백엔드 서버, 중소 규모 데이터베이스)
- 컴퓨팅 최적화 인스턴스 : 고성능 프로세서를 활용하는 컴퓨팅 집약적 애플리케이션에 적합. (고성능 웹 서버, 컴퓨팅 집약적 애플리케이션 서버, 게임 서버 + 배치 처리 워크로드에 적)
- 메모리 최적화 인스턴스 : 메모리에서 대규모 데이터 집합을 처리하는 워크로드에 빠른 성능을 제공하기 위해 설계 (고성능 데이터베이스, 방대한 양의 비정형 데이터의 실시간 처리가 필요한 워크로드)
- 액셀러레이티드 컴퓨팅 인스턴스 : 데이터 처리를 가속화할 수 있는 구성 요소 (그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍)
- 스토리지 최적화 인스턴스 : 로컬 스토리지의 대규모 데이터 집합에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드 (분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리 시스템)
요금제
- 온디맨드 : 아무런 사전 계약이나 선결제 비용, 최소 약정 적용 X, 인스턴스는 중지될 때까지 실행되며, 사용한 컴퓨팅 시간에 대해서만 비용 지불 (1년 이상 지속하는 워크로드에는 추천하지 않음. AWS를 처음 사용하는 사람들이 서비스를 가동하고, 워크로드를 테스트하며 조정해보고 싶을 때 자주 사용.)
- Savings Plans : 일정한 기간(1년 또는 3년) 동안 시간당 지출 약정을 할 경우 비용 할인.
| RI / SP 차이점 | RI | SP |
| 인스턴스 패밀리 | 지정 | 고정 |
| 인스턴스 크기 | 지정 | 변경 가능 |
| 운영체제 | 지정 | 변경 가능 |
| 지역 | 1 Region 지정 | 1 Region 지정 |
| 적용 가능한 서비스 | EC2/RDS | EC2 |
3. 예약 인스턴스 (RI) : 꾸준한 상태의 워크로드나, 사용량이 예측 가능한 워크로드에 적합. 그러나 지역, 크기, 인스턴트 패밀리를 지정하게 되면 변경이 거의 불가능하여 계약의 리스크가 크고 유연성이 떨어진다는 단점. => SP 계약 제공 시작
둘의 차이점을 얘기하려면, RI를 말할 때 특정 운영체제, 인스턴트 크기를 언급.
4. 스팟 인스턴스 : 여분의 아마존 컴퓨팅 용량을 온디맨드 가격의 최대 90%까지 할인을 받아 사용가능. 그러나 여기서 중요한 점은 AWS 필요 시 언제든 인스턴스의 용량을 회수할 수 있다는 점. 회수 2분 전에 경보 제공
5. 전용 호스트 : 사용자 전용의 AWS EC2 인스턴스 용량을 갖춘 물리적 서버. 즉 다른 사용자와 물리적 호스트, 서버 머신을 공유하지 않음.
Amazon EC2 크기 조정
확장성 및 탄력성
고객 워크로드는 시간에 따라 다름.
중요한 문제는 하드웨어를 얼마나 구매할 것인가.
- 평균 금액과 평균 사용량만큼 구매한다면 => 돈은 낭비하지 않지만, 피크 부하가 발생하면 하드웨어가 부족해 고객에게 서비스를 제공할 수 없게 됨.
- 최대 부하에 맞춰 구매한다면 => 고객은 만족하지만 1년 중 대부분의 시간에 자원이 사용되지 않을 수 있음
- 이 문제는 On premise에서 해결이 불가능함.
그러나 AWS는 다른 답을 내놓음 (해결)
확장성을 위해서는 필요한 리소스만으로 시작
⇒ 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍쳐 설계 (사용한 리소스에 대해서만 비용을 걱정하면 됨)
If 주문을 받는 인스턴스(앨런)가 손실되면 어떻게 되는가?
- 앨런을 만들 때 사용하던 프로그램 방식을 똑같이 사용하여 두 번째 앨런(인스턴스) 제작
그렇게 되면 고객 서비스는 절대로 중단되지 않음.
Amazon EC2 Auto Scaling을 사용하면 변화하는 애플리케이션 수요에 따라 Amazon EC2 인스턴스를 자동으로 추가하거나 제거 가능. 필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지.
두 가지 접근 방식
- 동적 조정 : 수요 변화에 대응
- 예측 조정 : 예측된 수요에 따라 적절한 수의 인스턴스를 자동으로 예약
증가하는 수요를 처리할 수 있는 두 가지 방법
- 수직 확장 ⇒ 실행중인 장치의 성능을 추가 (일부 사례에서는 도움이 되지만, 앨런이 커진다고 고객의 주문이 빨라지는 것은 아님)
- 수평 확장 ⇒ 장치의 갯수를 추가
** 되게 어렵게 설명되어 있는데, 요지는 이렇다**
서버 사용량이 기간마다 다른데, 적은 날도 있고 확연히 많은 날도 있다.
평균으로 맞추자니, 피크 타임때를 다 놓치고
최대를 기준으로 사용량을 맞추자니, 사용하지 않는 기간이 더 많다.
⇒ 이를 AWS는 이렇게 해결한다
리얼 사용량만큼 서버를 늘리고 줄이고. (Amazon EC2 Auto Scaling)
그것을 어떻게 대응하나
- 동적 조정
- 예측 조정
그리고 증가하는 수요를 처리할 수 있는 두 가지 방법
- 수직 확장 ⇒ 실행중인 장치의 성능 추가 (앨런 크기 키우기)
- 수평 확장 ⇒ 장치의 갯수 추가 (앨런 여러 명)
Elastic Load Balancing (ELB)을 사용하여 트래픽 리디렉션
트래픽의 문제가 있다면 ?
손님이 계산대 하나에만 줄을 설 때 ⇒ 나머지 직원이 일을 하지 않고 있게 됨
이 때, Elastic Load Balancing (안내원) 이 해결해줌 ⇒ 어느 줄로 가야 하는지, 가장 짧은 줄로 보냄
*라우팅 = 네트워크에서 경로를 선택하는 프로세스
같은 프로그램을 실행하여 같은 목적을 수행하는 EC2 인스턴트가 여러개 있을 때,
요청이 어떤 인스턴스로 가야하는지 어떻게 알 수 있는가 ?
요청을 여러 인스턴스들로 라우팅해야 함 ⇒ 로드 밸런싱 (Load Balancing)이 필요하다.
로드 밸런서 = 요청을 받은 다음, 처리할 인스턴스로 라우팅하는 애플리케이션
'Cloud > AWS' 카테고리의 다른 글
| [AWS] AWS Cloud Practitioner 정리 (3) | 2025.10.26 |
|---|