Amazon Elastic Computer Cloud(EC2)
EC2는 안전하고 크기 조정이 가능한 컴퓨팅 용량을 EC2 인스턴스로 클라우드에서 제공한다.
만약, 어느 회사에서 리소스 아키텍처를 책임지고 새로운 프로젝트를 진행해야 한다고 가정했을 때, 온 프레미스 리소스를 사용할 경우
- 미리 하드웨어 구매
- 서버가 배달될 때까지 기다리기
- 물리적 데이터 센터에 서버 설치
- 필요한 모든 구성을 수행
이에 비해 EC2를 사용할 경우 AWS 클라우드에서 가상 서버를 사용하여 애플리케이션을 실행할 수 있다.
- 몇 분이면 EC2 인스턴스를 프로비저닝하고 시작할 수 있다
- 워크로드 실행을 완료했다면 인스턴스 사용을 중지할 수 있다
- 인스턴스가 실행 중일 때만 사용한 시간에 대해 비용을 지불하고, 종료하면 지불하지 않는다
- 필요한 서버 용량에 대해서반 비용을 지불한다
EC2 인스턴스 유형
1. 범용 인스턴스
컴퓨팅, 메모리, 네트워킹 리소스를 균형있게 제공한다. 다음과 같은 다양한 워크로드에 사용된다.
- 애플리케이션 서버
- 게임 서버
- 엔터프라이즈 애플리케이션용 백엔드 서버
- 중소 규모 데이터베이스
2. 컴퓨팅 최적화 인스턴스
고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합하다. 범용 인스턴스의 사용처를 포함하고 있지만 고성능 웹서버, 집약적 애플리케이션 및 게임전용 서버에 적합하다. 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에 사용할 수 있다.
3. 메모리 최적화 인스턴스
메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 빠른 성능을 제공하기 위해 설계되었다. CPU가 작업을 완료하는데 필요한 모든 데이터와 명령이 들어있다.
애플리케이션을 실행하기 전에 많은 데이터를 미리 로드해야 하는 워크로드가 있다면 메모리 최적화 인스턴스를 사용하면 뛰어난 성능을 얻을 수 있다.
4. 액셀러레이티드 컴퓨팅 인스턴스
하드웨어 엑셀러레이터 또는 코프로레서를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서보다 더 효율적으로 수행한다.
- 소수점 수 계산
- 그래픽 처리
- 데이터 패턴 일치
그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 적합하다.
5. 스토리지 최적화 인스턴스
로컬 스토리지의 대규모 데이터 세트에 대한 순차적 읽기, 쓰기 액세스가 많이 필요한 워크로드를 위해 설계되었다.
- 분산 파일 시스템
- 데이터 웨어하우징 애플리케이션
- 고빈도 온라인 트랜잭션 처리(OLTP)
IOPS(초당 입출력 작업수) 요구 사항이 높은 애플리케이션이 있는 경우 스토리지 최적화 인스턴스는 이러한 종류 사용 사례에 최적하되지 않은 다른 인스턴스보다 나은 성능을 제공한다.
EC2 요금 "매우 중요"
1. 온디맨드
중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 적합하다. 선결제나 최소 약정은 없으며 인스턴스는 중지될 때까지 계속 실행되자만 사용한 시간에 대해서만 비용을 지불한다.
애플리케이션 개발 및 테스트에 적합하고 1년 이상 지속되는 워크로드에는 권장하지 않는다.
2. Saving Plans
약정 사용량 까지는 할인된 요금이 청구되고, 약정을 초과한 사용량에 대해서는 온디맨드 요금이 부과된다.
1년 또는 3년의 가긴동안 일정한 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있다. 온드맨드 요금에 비해 72% 절감할 수 있다.
3. 예약 인스턴스
온디맨스 인스턴스를 사용할 때 적용되는 결제 할인 옵션이다. 1년 또는 3년 약정으로 정기예약은 1년 약정으로 구입할 수 있다. 약정 기간이 끝나면 중단 없이 계속 사용할 수 있지만 인스턴스를 종료하거나 속성과 일치하는 새 예약 인스턴스를 구매할 때까지 온디맨드 요금이 부과된다.
4. 스팟 인스턴스
시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합나다. 온디맨드 요금의 90%까지 비용절감이 가능하다.
필요에 따라 시작, 중지할 수 있는 백그라운드 처리 작업(예, 고객 설문조사 데이터 처리)가 있을 때 전반적인 비즈니스 운영에 영향을 주지 않고 처리 작업을 시작하고 중지하려고 한다면 스팟 인스턴스가 시작된다.
스팟 인스턴스를 시작한 후에 용량을 더 사용할 수 없거나 수요가 늘면 인스턴스가 종료될 수 있다.
5. 전용 호스트
사용자 전용의 EC2 인스턴스 용량을 갖춘 물리적 서버이다. 기존 소켓, 코어당 또는 VM당 소프트웨어 라이선스를 사용하여 규정 준수를 유지할 수 있다. 모든 옵션 중에 제일 비싸다.
EC2 확장
확장성
확작성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍처를 설계해야 한다. 그 결과, 리소스에 대해서만 비용을 지불한다. 컴퓨팅의 용량 부족으로 고객의 요구 사항을 충족할 수 없을지 걱정할 필요가 없다.
EC2 Auto Scaling
변화하는 애플리케이션 수요에 따라 EC2 인스턴스를 자동으로 추가하거나 제거할 수 있다. 필요에 따라 인스턴스를 자동으로 저정하여 애플리케이션 가용성을 효과적으로 유지할 수 있다.
- 동적 조정은 수요 변화에 대응한다
- 예측 조정은 예측된 수요에 따라 적절한 수의 EC2 인스턴스를 자동으로 예약한다.
Auto Scaling은 그룹의 크기를 구성할 때 최소 EC2 인스턴스 수를 1로 설정할 수 있다. 즉, 하나 이상의 EC2 인스턴스가 항상 실행중이어야 한다. 최소 용량은 Auto Scaling 그룹을 생성한 직후에 시작되는 EC2 인스턴스의 수입니다.
그런 다음 애플리케이션을 실행하려면 최소 하나의 EC2 인스턴스가 필요하더라도 희망 용량을 EC2 인스턴스 두개로 설정할 수 있습니다.
💡 Auto Scaling 그룹에서 희망 EC2 인스턴스 수를 지정하지 않으면 희망 용량은 기본적으로 최소 용량으로 설정됩니다.
최대 용량은 수요 증가에 대응하여 확장하도록 그룹을 구성하되 EC2 인스턴스 수를 최대 4개로 제한할 수 있습니다.
Auto Scaling은 사용한 인스턴스에 대해서만 비용을 지불하면 된다.
Elastic Load Balancing을 사용하여 트래픽 리디액션
Elastic Load Balancing
ELB는 들어오는 애플리케이션의 트래픽을 EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스이다.
ELB는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다. 즉, 들어오는 트래픽의 양에 맞춰 EC2 인스턴스를 추가하거나 제거하므로, 이러한 요청이 로드밸런서로 먼저 라우팅된다.
ELB와 Auto Scaling은 별도의 서비스지만 서로 연동하여 뛰어난 성능과 가용성을 제공하도록 돕늗다.
수요가 적다면 EC2도 그 수요에 맞게 설정이 되고 수요가 많아지면 로드밸런싱이 적합한 EC2로 안내하여 균등하게 작업을 처리하도록 한다.
메시징 및 대기열
모놀리식 애플리케이션 및 마이크로 서비스
구성요소가 밀결합된 애플리케이션이 있다고 가정한다. 이러한 구성 요소에는 데이터베이스, 서버, 사용자 인터페이스, 비즈니스 로직 등이 포함될 수 있다. 이러한 유형의 아키텍처를 모놀리식 애플리케이션으로 볼 수 있다.
이 접근 방식에서는 한 구성 요소에서 장애가 발생하면 다른 구성요소에서 장애가 발생하고, 전체 애플리케이션 장애로 발생할 수 있다.
단일 구성 요소에 장애가 발생했을 때 애플리케이션 가용성을 유지할 수 있도록 마이크로서비스 접근 방식을 통해 애플리케이션을 설계할 수 있다.
구성요소가 소결합된 애플리케이션으로, 이 경우 단일 구성 요소에 장애가 발생해도 다른 구성요소들은 서로 통신하기 때문에 계속 작동한다. 전체 애플리케이션에서 장애가 발생하는 것을 방지한다.
Amazon Simple Queue Service(SQS)를 사용하여 마이크로서비스를 구축할 수 있다.
Amazon Simple Notification Service(SNS)는 게시/구독 서비스이다. 게시자는 SNS 주제를 사용하여 구독자에게 메시지를 게시한다.
최종 사용자에게 알람, SMS, 이메일 등으로 안내를 할 수 있다.
서버리스 컴퓨팅
💡 EC2의 특징
- 유연성
- 안전성
- 확장성
EC2에서 실행하려는 애플리케이션이 있는 경우 다음과 같이 해야 한다.
- 인스턴스를 프로비저닝한다
- 사용자 토드 업로드한다
- 애플리케이션이 실행되는 동안 인스턴스 관리한다
서버리스라는 용어는 코드가 서버내에서 실행되지만 이러한 서버를 프로비저닝하거나 관리가 필요없다는 이야기이다. 서버리스는 서버를 유지 관리하는 대신 새로운 제품과 기능을 혁신하는데 더 집중할 수 있다.
서버리스 컴퓨팅용 AWS 서비스는 AWS Lambda이다.
AWS Lambda
서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서비스이다.
사용한 시간에 대해서만 비용을 지불하며, 코드를 실핼하는 동안에만 요금이 부과된다. 모든 유형의 애플리케이션 또는 백엔드 서비스 코드를 실행할 수 있다.
AWS Lambda 작동방식
컨테이너
컨테이너는 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공한다. 보안성, 안정성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크를로에도 컨테이너를 사용한다.
컨테이너 작동 방식
💡 컨테이너 오케스트레이션 서비스는 컨테이너식 애플리케이션을 배포, 관리, 확장하는데 도움을 줄 수 있다.
Amazon Elastic Container Service(Amazon ECS)
AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 이는 확장성이 뛰어난 고성능 컨테이너 관리 시스템이다.
ECS는 Docker 컨테이너를 지원한다. Docker는 애플리케이션을 신속하게 구축, 테스트. 배포할 수 있는 소프트웨어 플랫폼이다. AWS는 오픈소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원한다. API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있다.
Amazon Elastic Kubernetes Service(Amazon EKS)
AWS에서 Kubernetes를 실행하는데 사용할 수 있는 완전 관리형 서비스이다.
Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는데 사용할 수 있는 오픈 소스 소프트웨어이다. 자원자로 구성된 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극 협력한다.
AWS Fargate
컨테이너용 서버리스 컴퓨팅 엔진으로. ECS, EKS에서 작동한다. 서버를 프로미저닝하거나 관리할 필요가 없다. 자동으로 서버 인프라를 관리해준다.
- EC2 사용
- 기존 애플리케이션 호스팅
- OS에 대한 전체 액세스
- Lambda
- 단기 실행 함수 호스팅
- 서비스 중심 애플리케이션
- 이벤트 기반 애플리케이션
- 서버를 프로비저닝 또는 관리하지 않음
- ECS, EKS
- Docker 컨테이서 기반 워크로드 실행
- EC2 또는 Fargate 사용
'study > TIL🐥' 카테고리의 다른 글
[AWS Cloud Practitioner] 4. 네트워킹 (0) | 2022.07.15 |
---|---|
[AWS Cloud Practitioner] 3. 글로벌 인프라 및 안정성 (0) | 2022.07.15 |
[AWS Cloud Practitioner] 1. Amazon Web Service (0) | 2022.07.12 |
[DB] Partition 사용 이유 (0) | 2021.07.07 |
[Git] 잘못 올라간 파일/폴더 지우기 (0) | 2021.06.08 |