반응형
AMAZON WEB SERVICE 소개
[소개]
- EC2: Amazon Elastic Compute Cloud의 약자 / 가상 서버
- 종량 과금제
- 필요한 만큼만 사용하고 사용한 만큼만 지불하는 방식으로 AWS 비즈니스 운영에 대한 첫번째 핵심 가치
[클라우드 컴퓨팅]
- 온디멘드 제공
- AWS가 사용자에게 필요한 리소스를 필요한 수간에 전달할 수 있음
- 반대의 상황에서도 필요 없어지게 되는 경우 리소스 반환으로 비용 지불을 바로 중단할 수 있음 (기존 데이터센터 상황과 정 반대의 경험)
[클라우드 컴퓨팅 배포 모델]
- 클라우드 기반 배포
- 애플리케이션의 모든 부분을 클라우드에서 실행
- 기존 애플리케이션을 클라우드로 마이그레이션
- 클라우드에서 새 애플리케이션을 설계 및 빌드
- 온프레미스 배포
- 가상화 및 리소스 관리 도구를 사용하여 리소스를 배포
- 애플리케이션 관리 및 가상화 기술을 사용하여 리소스 활용도를 높임
- 하이브리드 배포
- 클라우드 기반 리소스를 온프레미스 인프라에 연결하거나 레거시 IT 애플리케이션과 통합 함
[클라우드 컴퓨팅 이점]
- 선행 비용을 가변 비용으로 대체
- 온프레미스 환경과 같이 미리 투자해야 사용할 수 있는 리소스의 비용을 가변적으로 사용할 수 있음 (가변비용의 이점)
- 데이터센터 운영 및 유지관리에 비용 불 필요
- 데이터센터에 컴퓨팅, 인프라 및 서버 관리에 들어가는 비용과 시간을 대폭 줄일 수 있음
- 용량 추정 불필요
- 클라우드 컴퓨팅에서는 애플리케이션 배포 전 인프라 용량 예측할 필요가 없음
- 사용한 컴퓨팅 시간에 대해서만 비용 지불이 가능하므로 미사용 리소스에 대해 비용을 지불하거나 할 필요 없이 유연하게 확장/축소가 가능함
- 규모의 경제로 얻게되는 이점
- 인프라 소유시보다 가변비용이 낮아짐, 종량 과금제를 통한 요금 감소로 이어짐
- 속도 및 민첩성 향상
- 클라우드 컴퓨팅의 유연성으로 더욱 쉽게 개발/배포가 가능
- 리소스 생성 관리에 들어가는 시간을 대폭 줄여 줌
- 몇 분 만에 전세계에 배포
- 클라우드 글로벌 입지를 이용하여 전 세계 고객에세 신속하게 애플리케이션 배포와 동시에 짧은 지연시간 제공
클라우드 컴퓨팅
[소개]
- 하이퍼바이저와 멀티 테넌시
- 가상머신끼리 서로 물리적인 리소스를 공유하도록 돕는 역할을 함
- 가상머신끼리 하드웨어를 공유하는것을 "멀티테넌시"리고 함
- 하이퍼바이저는 이 "멀티테넌시" 조정을 책임짐
- Amazon Elastic Compute Cloud(EC2)
- EC2에는 범용, 컴퓨팅 최적화, 메모리 최적화, 엑셀러레이티드 컴퓨팅, 스토리지 최적화 등의 인스턴스 패밀리가 존재
- 각 인스턴스 패밀리는 요구하는 역할에 맞게 구성이 가능하도록 제공
[Amazon EC2 인스턴스 유형]
- 범용 인스턴스
- 컴퓨팅, 메모리, 네트워킹 리소스를 균형있게 제공
- 애플리케이션 서버, 게임 서버, 엔터프라이즈 애플리케이션 백엔드 서버, 중소 규모 데이터베이스
- 컴퓨팅 최적화 인스턴스
- 고성능 프로세서를 활용하는 집약적인 애플리케이션에 적합
- 웹, 에플리케이션, 게임 서버에 사용 가능
- 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에 사용
- 메모리 최적화 인스턴스
- 메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 인스턴스
- 애플리케이션을 실행하기 전에 많은 데이터를 미리 로드해야 하는 워크로드에 적합
- ex) 방대한 양의 비정형 데이터의 실시간 처리가 필요한 워크로드에 사용
- ex2) 고성능 데이터베이스에 적합
- 엑셀러레이티드 컴퓨팅 인스턴스
- 코어 프로세서를 이용하여 CPU에서 실행되는 소프트웨어보다 더 효율적으로 수행
- 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍 등의 워크로드에 사용
- 스토리지 최적화 인스턴스
- 로컬 스토리지의 대규모 데이터 세트에 대한 순차적 읽기 및 쓰기 엑세스가 많이 필요한 워크로드를 위해 설계
- 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등
- IOPS(저장장치단위) 요구사항이 높은(초당 처리용량이 높은) 애플리케이션등에 사용
[Amazon EC2 요금]
- 온디맨드 인스턴스
- 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션
- 애플리케이션 개발/테스트와 같이 예측할 수 없는 사용 패턴에 적합하며 1년이상 사용시는 적합하지 않음
- Saving Plans
- 1~3년 동안 일정한 컴퓨팅 사용량을 약정하여 비용 절감
- 온디맨드 대비 72%까지 비용 절감이 가능
- 약정 사용량까지는 Saving plan 요금이 청구되며 약정 초과시 일반 온디맨드 요금이 부과됨
- 예약 인스턴스
- 온디맨드 인스턴스 사용시 적용되는 결제 할인 옵션
- 표준 예약 및 컨버터믈 예약 인스턴스는 1년 ~ 3년 약정
- 정기 예약 인스턴스는 1년 약정으로 구매 가능하며 3년 약정시 더 큰 비용 절감 실현 가능
- 스팟 인스턴스
- 시작/종료가 자유로우며 중단을 견딜 수 있는 워크로드에 적합
- 미사용 EC2 컴퓨팅 용량을 사용하여 온디맨드 요금의 최대 90% 절감 가능
- 필요에 따라 시작/중지할 수 있는 백그라운드 처리 작업에 활용 가능
- 단, 스팟 요청시 용량이 부족하다면 사용이 불가하여 지연될 수 있음
- 전용 호스트
- 사용자 전용의 EC2 인스턴스 용량을 갖춘 물리서버
- 비용이 다른 옵션에 비해서 가장 비쌈
[Amazon EC2 확장]
- 확장성
- 확장성을 위해서는 필요한 리소스만으로 시작하고 수요 변화에 자동으로 대응하도록 아키텍처 설계해야 함
- 사용한 리소스에 대해서만 비용을 지불, 고객은 용량 부족으로 걱정할 필요가 없음
- Amazon에서는 이 기능을 Auto Scaling 기능으로 제공
- Auto Scaling
- 실시간으로 변화하는 수요에 따라 인스턴스가 추가/제거 되며 동적/예측 조정으로 나뉨
- 동적 조정: 수요 변화에 대응
- 예측 조정: 예측 수요에 따라 적절한 수의 EC2 자동 예약
- 최소 / 희망 / 최대 용량
- 최소 용량: Auto Scaling 기능 사용시 생성되는 EC2의 최소 용량(개수)
- 희망 용량: Auto Scaling 기능으로 기본 생성되는 희망 EC2 용량 (희망 용량 미 지정시 최소 용량으로 지정 됨)
- 최대 용량: Auto Scaling 기능으로 생성되는 EC2의 최대 용량 제한 (4개 지정시 4개까지만 생성 됨)
- 실시간으로 변화하는 수요에 따라 인스턴스가 추가/제거 되며 동적/예측 조정으로 나뉨
[Elastic Load Balancing]
- Elastic Load Balancing
- 애플리케이션 트래픽을 인스턴스와 같은 리소스에 자동으로 분산하는 서비스
- 모든 웹 트래픽의 단일 접점 역할
- 로드밸런서에 들어오는 트래픽에 맞춰 EC2를 추가하거나 제거하므로 가장 먼저 트래픽이 라우팅 되는 곳
- Elasic Load Balancing + Auto Scaling은 서로 연동하여 성능과 가용성을 제공
- 수요에 따른 Load Balancing + Auto Scaling
- 수요가 적으면 좌측과 같이 LB 하단에 EC2가 적으나, 수요가 증가하는 경우 Auto Scaling에 의해 EC2가 증가하여 더 많은 워크로드를 제공
![]() |
![]() |
[메시징 및 대기열]
- 모놀리식 애플리케이션 및 마이크로 서비스
- 구성요소가 밀결합된 애플리케이션 형태로 DB, Server, UI, Business Logic이 하나의 구성요소에 포함되어 있는 형태
- 한 구성요소에서 장애가 발상하면 전체 애플리케이션으로 번질 수 있음
- 마이크로서비스
- 애플리케이션의 각 구성요소가 소결합 되는 형태
- 단일 구성에서 장애가 발생하더라도 다른 요소로 영향을 주지 않으므로 나머지는 정상 동작 함
- AWS에서는 Amazon Simple Notification Service(SNS)와 Amazon Simple Queue Service(SQS)로 애플리케이션 통합을 도움
- Amazon Simple Notifcation Service (Amazon SNS)
- 게시/구독 서비스로 SNS 주제를 사용하여 구독자에게 메시지를 게시함
- 여기서 구독자는 웹 서버, 이메일, Lambda 함수 등 여러 옵션이 될 수 있음
- Amazon Simple Queue Server (Amazon SQS)
- 메시지 대기열 서비스 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성요소 간 메시지를 전송/저장/수신할 수 있음
- 애플리케이션이 메시지를 대기열로 전송하고 사용자 및 서비스는 대기열에서 메시지를 검색하여 처리 후 대기열에서 삭제함
[추가 컴퓨팅 서비스]
- 서버리스 컴퓨팅
- 서버를 프로비저닝 하거나 관리할 필요가 없는 서비스
- 애플리케이션을 자동으로 확장할 수 있는 유연성이 있으며, 처리량 / 메모리와 같은 소비단위를 수정하여 애플리케이션 용량을 조정할 수 있음
- AWS에서는 AWS Lambda로 해당 서비스를 지원 함
- AWS Lambda
- 서버 관리 필요 없이 코드를 실행할 수 있는 서비스
- 사용한 시간에만 비용을 지불하며(코드를 실행하는 동안에만 요금 부과) 사실상 모든 유형의 애플리케이션 및 백엔드 서비스 코드 실행 가능
- [코드 업로드] -> [이벤트 소스에서 트리거 되도록 설정] -> [트리거 시점에만 코드 실행] -> [사용한 컴퓨팅 시간만 비용 지불]
- 컨테이너
- 애플리케이션의 코드와 종속성을 하나의 객체로 패키징 하는 표준 방식 제공
- ECS(Amazon Elastic Container Service)
- 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 고성능 컨테이너 관리 시스템
- Docker 컨테이너를 지원하며 ECS에서 API 호출을 이용하여 Docker 지원 애플리케이션을 시작/중지 할 수 있음
- EKS(Amazon Elastic Kubernetes Service)
- AWS에서 Kubernetes를 실행하는데 사용하는 완전 관리형 서비스
- Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 오픈소스로 AWS에서도 동일하게 사용할 수 있게 환경을 제공
- AWS Fargate
- 컨테이너용 서버리스 컴퓨팅 엔진으로 ECS와 EKS 사이에서 작동
- 서버를 프로비저닝/관리 할 필요가 없으며 자동으로 서버 인프라를 관리함
반응형
'Tech > Certificate' 카테고리의 다른 글
[AWS Cloud Practitioner] 모듈9 / 모듈10 정리 (0) | 2023.01.03 |
---|---|
[AWS Cloud Practitioner] 모듈7 / 모듈8 정리 (0) | 2023.01.02 |
[AWS Cloud Practitioner] 모듈5 / 모듈 6 정리 (0) | 2022.12.27 |
[AWS Cloud Practitioner] 모듈3 / 모듈 4 정리 (0) | 2022.12.25 |