반응형
SMALL
카페에서 피크타임에 대비해 직원을 10명을 고용해야 한다면? 하루 중 대부분의 시간에는 직원 전원에게 제공하는 급여의 가치만큼 많은 손님이 오지 않는다. (= 온프레미스 데이터 센터에서 발생하는 일)
하지만 AWS에서는 바리스타, 즉 인스턴스가 필요하면 버튼을 클릭하기만 하면 바로 생성할 수 있고, 필요 하지 않으면 클릭 한번으로 없앨 수 있음. 비용 지불도 당연히 중단됨. 직원이 일하지 않는 시간에 급여를 주지 않는 것과 같은 원리.
따라서, 필요한 만큼 지불하는 것이 AWS에서의 비즈니스 운영에 대한 첫 번째 핵심 가치.
클라우드 컴퓨팅은 IT 리소스를 인터넷을 통해 온디맨드로 제공 (AWS가 사용자에게 필요한 리소스를 필요한 순간에 전달)하고, 사용한 만큼만 비용을 지불함.
획일적인 작업 부담을 돕고자 하는 것이 AWS가 돕고자 하는 것.
클라우드 컴퓨팅의 이점
- 선행 비용 (미리 투자)을 가변 비용 (사용하는 컴퓨팅 리소스에 대해서만 비용 지불)만 지불
- 데이터 센터 운영 및 유지 관리에 비용 투자 불필요
- 용량 추정 불필요 (컴퓨팅 시간에 대해서만 비용 지불)
- 인프라를 소유할 때보다 가변 비용이 낮아짐 -> 높은 수준의 규모의 경제를 달성
- 애플리케이션을 더욱 쉽게 개발하고 배포 가능 (유연성)
**클라우드 기반 배포
- 애플리케이션 모든 부분을 클라우드에서 실행
- 모두 클라우드로 마이그레이션
- 완전히 클라우드에 기반한 가상 서버, DB, 네트워킹 구성 요소로 구성된 애플리케이션 제작 가능
**온프레미스 배포
- 프라이빗 클라우드 배포라 불림
- 가상화 및 리소스 관리 도구를 사용하여 온프레미스에 배포
**하이브리드 배포
- 클라우드 기반 리소스를 온프레미스 인프라에 연결
- 클라우드 기반 리소스를 레거시 IT 애플리케이션과 통합
EC2
커피숍에 다양한 직원이 있듯 AWS에는 가동하여 AWS 환경에 배포할 수 있는 다양한 유형의 EC2 인스턴스가 있다. 각 인스턴스 유형은 특정 유형의 작업에 최적화됨.
- Amazon Elastic Compute Cloud
- 가상 서버에 액세스 하는데 사용하는 서버
- AWS가 이미 서버를 구입하여 제반 작업을 마쳤고 이 서버는 바로 사용할 수 있는 상태
- 가상화 기술을 사용하여 AWS에서 관리하는 물리적 호스트 시스템에서 실행됨.
- EC2 인스턴스는 그 호스트에 있는 다른 EC2 인스턴스 인식 X -> 안전하면서 서로 분리되어 있음.
- 인스턴스의 수직 확장 (유연한 크기 조정 가능)
EC2 인스턴스 유형
- 범용 인스턴스
- 컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공 - 컴퓨팅 최적화 인스턴스
- 고성능 우베서버, 서버 및 게임에 적합 - 메모리 최적화 인스턴스
- 메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 빠른 성능 제공 - 액셀러레이티드 컴퓨팅 인스턴스
- 데이터 처리를 가속화할 수 있는 구성 요소
ex) 그래픽처리, 부동 소수점 수 계산, 데이터 패턴 일치 - 스토리지 최적화 인스턴스
- 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계됨.
- 분산파일 시스템, 데이터 웨어하우징 애플리케이션에 적합.
온디맨드 인스턴스
- 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 매우 적합
- 1년 이상 지속되는 워크로드에 권장 X / 예약 인스턴스를 사용하는게 비용 절감에 더 효과적
Amazon EC2 Savings Plans
- 기간 약정을 통해 비용 절감
- 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금 부과
- 온디맨드 비용에 비해 최대 72%까지 비용 절감
예약 인스턴스
- 계정에서 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션
- 표준은 1년, 3년
- 다음 중 하나를 수행할 때까지는 온디맨드 요금 부과
- 인스턴스종료
- 인스턴스 속성과 일치하는 새 예약 인스턴스 구입
스팟 인스턴스
- 시작 및 종료시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합
- EC2 Savings Plans와 달리 약정이 필요하지 않음!
- 미사용 Amazon EC2 컴퓨팅 용량을 사용하며, 온디맨드 요금의 최대 90%까지 비용 절감
전용 호스트
- 사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버
- 모든 EC2 옵션 중에서 가장 비용이 많이 들어감.
※ 프로비저닝이란?
- "제공하는것" , 어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공 하는 것.
- 인프라 자원, 서비스, 또는 장비가 될 수 있음.
- IT 인프라 자원을 사용자 또는 Customer에게 Service Vendor 가 제공하는 것!
EC2 확장성
- 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처 설계
- 그 결과, 사용한 리소스에 대해서만 비용 지불 -> 용량 부족으로 고객 요구사항에 대한 걱정 X
Amazon EC2 Auto Scaling
- 커피숍에서 갑자기 바리스타 한명이 수십명의 고객의 주문을 다 받아야 한다면??!!
이러한 변화에 따라 사용되는것이 Auto Scaling - 바로 위와 같은 기능을 제공하는 서비스!
- 변화하는 애플리케이션 수요에 따라 EC2 인스턴스를 자동으로 추가하거나 제거할 수 있음!
- 필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지.
- 동적 조정 = 수요 변화에 대응
- 예측 조정 = 예측된 수요에 따라 적절한 수의 EC2 인스턴스를 자동으로 예약
- 최소용량(Auto Scaling 그룹을 생성한 직후 시작되는 EC2 인스턴스의 수) /희망 용량 / 최대용량 설정 가능.
※ 수직확장
- 실행 중인 장치에 성능을 추가하는 작업
ELB
커피숍에서는 3가지 방법으로 주문을 받을 수 있는데, 대부분의 고객이 한 줄로 서기 때문에 균일하게 분산되지 않음. 들어온 고객은 어디에서 주문을 해야 할지 정확히 알지 못하기 때문에, 이 상황에 호스트를 추가한다면 고객을 가장 효율적인 방식으로 응대하게 함.
- Elastic Load Balancing
- 로드밸런싱의 획일적인 작업 부담을 처리할 목적으로 제작됨. = 주요 관리형 서비스
- 같은 프로그램을 실행하여 같은 목적을 수행하는 EC2 인스턴스가 여러 개 있을 때 요청이 들어오면 이 요청이 어떤 EC2 인스턴스로 가야 하는지에 있어서 로드 밸런싱이 필요함.
- 요청을 받은 다음 처리할 인스턴스로 라우팅하는 애플리케이션
- AWS에는 다양한 로드 밸런서 제품이 있고, 마음에 드는것을 이용하면됨.
- 개별 EC2 인스턴스가 아닌 리전 수준에서 실행되므로 사용자가 추가로 작업하지 않아도 자동으로 고가용 서비스가 된다는 것을 꼭 기억!
요약
- 들어오는 애플리케이션 트래픽을 EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 서비스
- 워크로드를 여러 인스턴스에 분산하므로 어느 한 인스턴스가 대량으로 워크로드 처리 필요 X
- Elastic Load Balancing과 Auto Scaling은 별도의 서비스이지만 서로 연동
Amazon Simple Notification Service (Amazon SNS)
- 게시/구독 서비스
Amazon Simple Queue Service (Amazon SQS)
- 메시지 대기열 서비스
- 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신 가능.
EC2 인스턴스
- 최소한의 손실로 프로비저닝해 AWS에서의 가동 및 실행할 수 있는 가상 머신
서버리스
- 애플리케이션을 호스팅하는 기본 인프라나 인스턴스를 보거나 이용할 수 없다는 뜻
- 대신 프로비저닝, 규모 조정, 고가용성 및 유지 관리와 관련한 기본 환경 관리를 대신 처리해줌.
- 관리하기 편리한 컴퓨팅 서비스, 유연성
- 서버리스 컴퓨팅용 AWS 서비스 = AWS Lambda
★ Amazon EC2에서 실행하려는 애플리케이션이 있는 경우에는 다음과 같이 해야함.
서버리스 컴퓨팅
- 인스턴스(가상 서버)를 프로비저닝
- 사용자 코드를 업로드
- 애플리케이션이 실행되는 동안 계속해서 인스턴스 관리
※ 트리거란?
"방아쇠" 라는 뜻. 방아쇠를 당기면 그로 인해 총기 내부에서 자동으로 일련의 작업을 실행하고 총알이 날아가는데, 이처럼 DB에더 트리거(Trigger)는 특정 테이블에 INSERT, DELETE, UPDATE 같은 DML 문이 수행되었을 때, DB에서 자동으로 동작하도록 작성된 프로그램. 즉, 자동적으로 호출하는 것이 가장 큰 특징!
AWS Lambda
- 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스
- 사용한 컴퓨팅 시간에 대해서만 비용 지불
- 코드를 실행하는 동안에만 요금 부과
- Lambda는 트리거된 경우에만 코드를 실행
컨테이너
- 애플리케이션과 관련 종속성 및 실행해야하는 모든 구성을 모아 놓은 코드 패키지
- EC2 인스턴스에서 실행되며, 가상 머신 작동 방식과 비슷하게 서로 격리되어 실행됨.
(이 경우 호스트는 EC2 인스턴스)
컨테이너 오케스트레이션
- 컨테이너 관리를 지원할 목적으로 제작
- 컨테이너화된 애플리케이션을 대규로모 실행하는 데 도움이 되도록 설계
- Amazon Elastic Container Service
Amazon Elastic Kubernetes Service
Amazon ECS
- Amazon Elastic Container Service
- 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템
- Docker 컨테이너를 지원
- ★Docker란?
= 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼
Amazon EKS
- Amazon Elastic Kubernetes Service
- AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스
- ★kubernetes란?
= 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어
AWS Fargate
- 컨테이너용 서버리스 컴퓨팅 엔진
- Amazon ECS / EKS 에서 작동함.
- Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요 X
- 자동으로 서버 인프라 관리.
AWS 고가용성 / 글로벌인프라
- 리전을 통해 기업 운영에 필요한 서비스 액세스
- 리전에는 가용 영역이 있어 물리적으로 먼곳도 논리적 통합을 유지할 수 있음.
- 가용 영역을 이용하면 사용자의 추가 노력 없이도 고가용성 및 재해 복구 시나리오 해결 가능
- AWS 엣지 로케이션은 CloudFront를 실행하여 어디든 콘텐츠를 고객과 가까운 곳으로 가져옴.
※ 리전은 두 개 이상의 가용 영역으로 구성됨
ex) sa-east-1a, sa-east-1b, sa-east-1c
리전선택
서비스, 데이터 및 애플리케이션에 적합한 리전을 결정할 때 다음 4가지 요소를 고려해야함.
- 데이터 거버넌스 및 법적 요구 사항 준수
- 고객과의 근접성
- 리전 내에서 사용 가능한 서비스
- 요금
엣지 로케이션
- Amazon CloudFront가 더 빠른 컨텐츠 전송을 위해 고객과 가까운 위치에 콘텐츠 사본을 캐시하는 데 사용하는 사이트
- 리전과는 구분되는 개념.
- CDN 뿐 아니라 Amazon Route 53라고 하는 Domain Name Service, 즉 DNS도 실행함.
-> 빠르게 고객들을 응대하기 위함.
Amazon CloudFront
- CDN, 엣지 콘텐츠를 사용자의 지리적 위치를 기반으로 사용자에게 전달하는 네트워크
- 글로벌 콘텐츠 전송 서비스 (파일, 사진, 웹 페이지 등)
- 데이터, 동영상, 애플리케이션, API를 전 세계 고객에게 짧은 지연 시간으로 빠르게 전달하는 서비스
- 전 세계에 있는 엣지 로케이션을 이용해 사용자가 어떤 위치에 있든 통신 속도를 높임.
AWS 리소스를 프로비저닝하는 방법
- AWS의 모든 것은 API 호출과 관련됨. (서비스와 실제로 상호작용)
★ API란? = 애플리케이션 프로그래밍 인터페이스 - API를 호출하여 AWS 리소스를 구성하고 관리할 수 있음.
ex) EC2 인스턴스를 시작하거나, AWS Lambda 함수를 생성
AWS Management Console
- Amazon 서비스 액세스 및 관리를 위한 웹 기반 인터페이스
- 최근에 사용한 서비스에 빠르게 액세스하고 이름, 키워드 또는 약어로 다른 서비스 검색 가능.
- 리소스 모니터링, 경보 보기, 결제 정보 확인 등의 작업 수행 가능.
- 여러 ID가 동시에 AWS 콘솔 모바일 앱에 로그인 할 수 있음.
AWS 명령줄 인터페이스
- AWS CLI
- CLI를 사용하면 머신의 터미널에서 API를 호출 할 수 있음.
- 작업을 스크립트하고 반복할 수 있음. -> EC2 인스턴스 시작을 위해 명령을 작성하고 실행 가능.
- -> 미리 작성 가능 (시간절약) -> 인적 오류 발생 가능성이 줄어듬
소프트웨어 개발 키트
- SDK
- 프로그래밍 언어 or 플랫폼용으로 설계된 API를 통해 AWS 서비스를 보다 간편하게 사용 가능.
AWS와의 연결
VPC
=명시된 허가 없이 아무것도 출입할 수 없는 강화된 요새=
- Virtual Private Cloud
- AWS에서의 사용자 고유 프라이빗 네트워크
- AWS 리소스용 프라이빗 IP 범위를 정의하고 VPC에 EC2 인스턴스나 ELB 같은 요소를 배치할 수 있음.
- 게이트웨이 (like 커피숍 출입구)가 없다면 누구도 VPC 안에 있는 리소스에 접근 X
- 비공개 내부 AWS 리소스로 가는 암호화된 VPN 연결을 만들고 싶다면 가상 프라이빗 게이트웨이를 VPC에 연결
- 최대한 짧은 지연 시간과 최대한 높은 수준의 보안
- -> AWS Direct Connect 라는 기능을 이용하여 이를 달성할 수 있음.
요약
- 수백만명의 고객의 리소스에 경계가 없으면 네트워크 트래픽이 제한 없이 리소스 간에 흐를 수 있음.
- 고로, AWS 리소스에 경계를 설정하는 데 사용할 수 있는 네트워킹 서비스 = VPC
- AWS 클라우드의 격리된 섹션을 프로비저닝할 수 있음.
※ VPC에서 서브넷을 사용하는 유일한 기술적인 이유는?
= 게이트웨이에 대한 액세스 관리를 위함.
※ 인터넷 게이트웨이
- VPC와 인터넷 간의 연결
가상 프라이빗 게이트웨이(VPN)
- VPC 내의 비공개 리소스에 액세스하기 위한 게이트웨이
- 보호된 인터넷 트래픽이 VPC로 들어오도록 허용하는 구성 요소.
- VPC와 프라이빗 네트워크(회사 네트워크같은) 간에 가상 프라이빗 네트워크(VPN) 연결을 설정할 수 있음.
AWS Direct Connect
- 데이터 센터와 VPC 간에 비공개 전용 연결을 설정하는 서비스
- ex) 아파트 입주자만 이용할 수 있는 복도, 통로
- 네트워크 비용을 절감하고 대역폭을 늘리는 데 도움이 됨.
VPC 내에서 서브넷의 역할에 대해 자세히 알아보기 위해 커피숍의 예를 들어보면, 고객이 계산원에게 음료를 주문하고, 계산원이 바리스타에게 주문을 전달할 때 한 고객이 계산원을 건너 뛰고 바리스타에게 직접 주문하려고 한다면? 그렇다면 주문 흐름이 중단되고 고객이 커피숍의 제한 구역에 접근하게 됨.
따라서, 점주는 계산대와 바리스타를 별도의 워크스테이션에 배치하여 영역을 구분함. 계산원은 퍼블릭, 바리스타는 프라이빗으로 구분. 이는 AWS 네트워킹 서비스를 사용하여 리소스를 격리하고 네트워크 트래픽의 흐름을 정확히 결정하는 것과 비슷한 맥락임. 커피숍의 퍼블릭 영역을 VPC라고 생각하면 됨!
VPC에서 서브넷은 리소스를 그룹화하는 데 사용되는 별개의 영역!
※ 서브넷
- 리소스 (예를 들어 EC2 인스턴스)를 포함할 수 있는 VPC 섹션
- 퍼블릭 또는 프라이빗 일 수 있음.
- 퍼블릭서브넷 -> 누구나 액세스 할 수 있어야 하는 리소스가 포함
ex) 온라인 상점의 웹사이트 - 프라이빗 서브넷 -> 개인정보 등이 포함된 데이터베이스 같은 리소스가 포함.
- VPC 내에서 서브넷은 서로 통신할 수 있음.
VPC의 네트워크 트래픽
- 고객이 AWS 클라우드에서 호스팅되는 애플리케이션에 데이터를 요청하면 이 요청은 패킷으로 전송이 됨.
- ★ 패킷이란?
= 인터넷이나 네트워크를 통해 전송되는 데이터의 단위 - 패킷은 인터넷 게이트웨이를 통해 VPC로 들어감.
- 서브넷으로 들어가거나 나오려면 먼저 권한을 확인해야 함.
- 이러한 사용 권한은 패킷을 보낸 사람과 패킷이 서브넷의 리소스와 통신하려는 방법을 나타냄.
- 서브넷의 패킷 권한을 확인하는 VPC 구성 요소는 네트워크 ACL(액세스 제어 목록)
네트워크 ACL (액세스 제어 목록)
- 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 "가상 방화벽"
- 공항의 "출입국 심사 직원" 과 같은 맥락
- 각 AWS 계정에는 기본 네트워크 ACL이 포함됨!
- VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 생성할 수 있음.
- 기본 네트워크 액세스 제어 목록은 상태 비저장이며 모든 인바운드 및 아웃바운드 트래픽을 허용함
- 사용자가 자체 규칙을 추가하거나 수정할 수 있음.
상태 비저장 패킷 필터링
- 아무것도 기억하지 않고 각 방향(인바운드 및 아웃바운드)으로 서브넷 경계를 통과하는 패킷만 확인
- 해당 요청에 대한 패킷 응답이 서브넷으로 반환될 때 네트워크 ACL은 이전 요청을 기억하지 못함.
- 패킷이 서브넷에 들어간 후에는 서브넷 내의 리소스(예를 들어 EC2 인스턴스)에 대한 권한이 평가되어야함.
- 패킷에서 Amazon EC2 인스턴스에 대한 권한을 확인하는 VPC 구성요소는 "보안 그룹"
보안 그룹
- Amazon EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 "가상 방화벽"
- 상태 저장이며, 기본적으로 모든 인바운드 트래픽을 거부하고 아웃바운드 트래픽을 허용.
- -> 상태 저장은 즉, 인스턴스에 대한 새 요청을 평가할 때 이전 트래픽 패턴 및 흐름을 사용.
- 예를 들어 로비에서 방문객을 안내하는 경비원이 있는 호텔을 생각해본다면, 방문객=패킷, 경비원=보안그룹
상태 저장 패킷 필터링
- 보안 그룹은 상태 저장 패킷 필터링을 수행함.
- 즉, 들어오는 패킷에 대한 이전 결정을 기억함
DNS
- Domain Name System
- 쉽게 이야기해서 번역 서비스 또는 인터넷의 전화번호부
- 언어를 번역하는 대신 웹사이트 이름을 컴퓨터가 읽을 수 있는 주소인 IP, 즉 인터넷 프로토콜로 번역
Amazon Route 53
- DNS 웹 서비스
- 개발자와 비즈니스가 최종 사용자를 AWS에서 호스팅되는 인터넷 애플리케이션으로 라우팅할 수 있는 안정적인 방법 제공
- 사용자 요청을 AWS에서 실행되는 인프라 (예를 들어 EC2 인스턴스, 로드밸런서)에 연결
- 또한 사용자를 AWS 외부의 인프라로 라우팅할 수 있음.
- DNS 레코드를 관리하는 기능도 가지고 있다. -> 직접 새 도메인 이름을 등록할 수도 있음.
- -> 단일 위치에서 모든 도메인 이름 관리 가능!
모듈4 까지 정리 완료
반응형
LIST
'자격증 > AWS Solution Architect Associate' 카테고리의 다른 글
| AWS cloud Practitioner Essentals 요약 (skill Builder)#4 (0) | 2022.06.17 |
|---|---|
| AWS cloud Practitioner Essentals 요약 (skill Builder)#3 (0) | 2022.06.16 |
| AWS cloud Practitioner Essentals 요약 (skill Builder)#2 (0) | 2022.06.15 |
| SAA 유데미 모의고사 복습용 정리 (+AWS 기초용어)#1 (0) | 2022.03.17 |
| AWS Certificate Solutuions Architect - Associate(SAA-CO2) 시작 (0) | 2022.03.11 |