모듈 2
가상 머신과 멀티 테넨시
- 가상 머신과 멀티 테넨시
- 가상 서버에 엑세스하는 데 사용하는 서버 = EC2
- AWS는 엄청난 양의 컴퓨팅 용량을 지속적으로 운영
- 사용자는 필요한 만큼만 사용하고, 사용한 만큼만 비용 지불
⇒ 실행 중인 인스턴스 비용만 청구 - EC2는 AWS가 관리하는 물리적 호스트 시스템에서 실행
- EC2는 가상머신과 멀티 테넌시를 통해 탁월한 유연성과 제어 기능을 제공
1. 가상머신
- 전체 호스트를 소유하지 않는 대신, 다른 여러 인스턴스와 공유
- 호스트 머신의 하이퍼바이저가 가상 머신 간 물리적 리소스 공유를 책임지고 관리
2. 멀티 테넌시
- 기본 하드웨어를 공유
- 하이퍼바이저는 ‘멀티 테넌시’ 조정을 책임지고, 이는 AWS에서 관리
- 같은 호스트의 리소스를 공유하는 가상 머신을 서로 분리하는 일
- 서로 리소스를 공유할 수는 있지만, 각 EC2는 같은 호스트에 있는 다른 EC2 인스턴스를 인식하지 못함 == 안전
EC2 인스턴스 프로비저닝, ‘서비스로서의 컴퓨팅 모델(CaaS)’
- 운영체제 선택 필요 (Windows, Linux)
- 수천 개의 EC2를 온디맨드로 프로비저닝할 수도 있음
- 자체 사내 앱, 각종 웹 앱, DB, 엔터프라이즈 소프트웨어 패키지 등 타사 소프트웨어 모두에서 인스턴스 관련 설정 제어 가능
EC2의 수직 확장
- 작은 인스턴스로 시작한 뒤 실행 중인 애플리케이션이 서버 한도를 초과한다면, 그때 해당 인스턴스에 더 많은 메모리와 CPU를 제공할 수 있음
⇒ 인스턴스의 수직 확장 - 네트워킹 측면도 제어 가능
- 서버에 전달할 요청 유형, 공개/비공개 액세스 여부 등을 결정할 수 있음
EC2 작동 방식
- 인스턴스 시작
- 템플릿 선택
- 인스턴스 유형(하드웨어 구성) 선택
- 보안 설정 (네트워크 트래픽 제어)
- 연결
- 프로그램과 App에는 인스턴스에 직접 연결하고 데이터를 교환하는 여러 방법 존재
- 사용자가 로그인하여 인스턴스에 연결하고 컴퓨터 데스크톱에 엑세스할 수도 있음
- 사용
- 명령 실행
- SW 설치, 스토리지 추가, 파일 복사 및 정리 등
EC2 인스턴스 유형
- EC2 인스턴스 유형
- 각 아마존 EC2 인스턴스 유형은 인스턴스 패밀리로 그룹화
- 인스턴스 유형에 따라 CPU, 메모리, 스토리지 및 네트워킹 용량의 다양한 조합 제공
- 애플리케이션을 위한 적절한 리소스 조합을 선택할 수도 있음
- EC2에는 범용, 컴퓨팅 최적화, 메모리 최적화, 액셀러레이티드 컴퓨팅, 스토리지 최적화라는 인스턴스 패밀리가 존재
- 범용 인스턴스
- 컴퓨팅, 메모리, 네트워크 리소스를 균형 있게 제공
- 컴퓨팅, 메모리, 네트워킹에 필요한 리소스가 거의 동일할 경우 적합
⇒ 어느 한 영역에 대한 최적화가 불필요하기 때문 - 웹 서비스나 코드 리포지토리 같은 다양한 워크로드에 사용 가능
- 앱 서버, 게임 서버, 엔터프라이즈 앱용 백 서버, 중소 규모 DB
- 컴퓨팅 최적화 인스턴스
- 배치 처리 워크로드 등 컴퓨팅 집약적인 작업에 적합
- 배치 처리 = 주기적으로 대량의 반복적인 데이터 작업을 완료하는 데 사용하는 방법
- 고성능 웹 서버, 컴퓨터 집약적 앱 서버, 게임 전용 서버 등에 적합
⇒ 게임 서비스, 고성능 컴퓨팅, 즉 HPC나 심지어 과학 모델링 등 - 단일 그룹에서 많은 트랜잭션을 처리해야 하는 일괄 처리 워크로드에도 사용 가능
- 메모리 최적화 인스턴스
- 메모리 집약적인 작업에 적합
⇒ 고성능 DB, 방대한 비정형 데이터의 실시간 처리가 필요한 워크로드 등 - 메모리 = 임시 스토리지 영역
- CPU(중앙 처리 장치)가 작업을 완료하는 데 필요한 모든 데이터와 명령이 들어 있음
- 프로그램와 App은 스토리지에서 메모리로 로드된 후 실행됨
- 이 사전 로드 프로세스 덕분에 CPU가 컴퓨터 프로그램에 직접 액세스 가능
- 메모리 집약적인 작업에 적합
- 액셀러레이티드 컴퓨팅
- 하드웨어 액셀러레이터, 코프로세서 사용
- 부동 소수점 계산, 그래픽 처리 또는 데이터 패턴 매칭 등 일부 기능을 CPU에서 실행되는
소프트웨어에서보다 더 효율적으로 수행 - 그래픽 애플리케이션, 게임 스트리밍, 애플리케이션 스트리밍과 같은 워크로드에 적합
- 스토리지 최적화
- 로컬 스토리지 대규모 데이터 세트에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드에 적합
- 분산 파일 시스템, 데이터 웨어하우징 애플리케이션, 고빈도 온라인 트랜잭션 처리(OLTP) 시스템 등
- IOPS(초당 입출력 작업 수) = 스토리지 디바이스의 성능을 측정하는 지표
⇒ 디바이스가 1초 내에 수행할 수 있는 입력 또는 출력 작업의 수 - 스토리지 최적화 인스턴스는 지연 시간이 짧은 임의 IOPS를 App에 제공하도록 설계
EC2 요금 옵션
- 온디맨드
- 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 매우 적합
- 시간당 혹은 초당 비용 지불
- 최소 약정 또는 선결제 필요 x
- 앱 개발 및 테스트, 예측 불가한 사용 패턴이 있는 앱 실행에 용이
- 평균 사용량 기준 확인 용도로 사용 후 Savings Plan으로 전환 가능
- 1년 이상 지속되는 워크로드의 경우 예약 인스턴스가 더 저렴
- Savings Plan
- 1년 또는 3년 동안 시간당 비용 청구하는 대신 EC2를 저렴하게 제공
- 인스턴스 패밀리, 크기, OS, 테넌시 또는 AWS 리전에 상관없이 EC2 사용 가격을 낮출 수 있음
- AWS 컴퓨팅 사용량 요금 72%까지 절약 가능
- 약정 사용량까지는 할인된 Savings Plan 요금이 청구
- 약정을 초과한 사용량에 대해서는 일반 온디맨드 요금 부과
- AWS Cost Explorer를 통해 지난 7일, 30일 또는 60일 동안의 Amazon EC2 사용량 분석, 맞춤형 권장 사항 제공 가능
- 예약 인스턴스
- 사용량이 예측 가능하거나 일정한 워크로드에 적합
- 온디맨드 대비 최대 75% 저렴
- 표준 예약 및 컨버터블 예약 인스턴스는 : 1년 또는 3년 약정
- 정기 예약 인스턴스 : 1년 약정
- 1년 또는 3년 약정 시 할인 가능, 3가지 결제 방법
- 전액 선결제
- 부분 선결제
- 선결제 없음
- 약정 기간이 끝나도 중단 없이 Amazon EC2 인스턴스 계속 사용 가능
⇒ 단, 온디맨드 요금 부과
- 스팟 인스턴스
- Savings Plan과 달리 스팟 인스턴스에는 계약이나 일정한 컴퓨팅 사용량에 대한 약정 불필요
- 여분의 EC2 용량을 온디맨드 가격의 최대 90%까지 비용 절감가능
- 단, AWS가 필요시 언제든 인스턴스 회수 후 작업을 마무리하고 상태를 저장하라는 2분 경고 표시
- 용량을 더 이상 사용할 수 없거나 스팟 인스턴스에 대한 수요가 늘면 인스턴스가 중단될 수 있음
- 필요할 때 언제든 다시 시작할 수 있음
- 배치 워크로드 등에 적합
- 전용 호스트
- 사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버
- 제일 비쌈
- 기존 소켓당, 코어당 또는 VM당 소프트웨어 라이선스를 통해 라이선스 규정 준수를 유지할 수 있음
- 규정 준수 요구 사항 충족을 위해 사용되며 이 호스트의 테넌시는 다른 사람과 공유 X
- 온디맨드 전용 호스트와 전용 호스트 예약 구매 가능
확장성과 탄력성
- Amazon EC2 Auto Scaling
- 애플리케이션 수요에 따라 EC2 인스턴스를 자동으로 추가하거나 제거할 수 있음
- 필요에 따라 인스턴스를 자동으로 조정
⇒ 애플리케이션 고가용성 확보 - 동적 조정 : 수요 변화에 즉각적으로 대응
- 예측 조정 : 예측된 수요에 따라 적절한 수의 Amazon EC2 인스턴스를 자동 예약
- 최소 용량 : Auto Scaling 그룹 생성 직후 시작되는 EC2 인스턴스의 수
- 희망 EC2 인스턴스 수를 지정하지 않으면, 희망 용량은 기본적으로 최소 용량으로 설정
- 최대 용량 설정 가능
- Elastic Load Balancing
- 트래픽을 EC2 인스턴스 등 여러 리소스에 자동 분산하는 AWS 서비스
- Auto Scaling 그룹으로 들어오는 모든 웹 트래픽이 로드밸런서로 라우팅 됨
- 라우팅된 트래픽은 로드밸런서가 자동으로 분산시킴
- 들어오는 트래픽 양에 맞춰 EC2를 추가/제거
- 오토 스케일링과 ELB를 연동해서 사용하면 뛰어난 성능과 고가용성 보장
메시징 및 대기열
- 밀결합(모놀리식 애플리케이션) < 소결합(마이크로 서비스)
- 밀결합된 아키텍쳐에서는 구성 요소 하나가 고장, 변경되면 다른 구성 요소 및 시스템 전체에 장애가 발생할 위험이 큼
- 소결합된 아키텍쳐는 특정 구성 요소에 장애 발생 시 해당 요소를 격리시키므로 다른 구성 요소에 장애가 발생하는 것을 막을 수 있음
- 메시지를 완충 기억 장치에 배치, B에 장애가 발생해도 메시지를 대기열에 남겨놓고 A는 자신의 작업을 지속할 수 있기 때문에 중단이 발생하지 않음
- Amazon SQS
- 볼륨에 상관없이 소프트웨어 구성 요소 간에 메시지 전송, 저장, 수신 가능
- 메시지에 포함된 데이터 = 페이로드 (payload)
- 메시지가 처리 전까지 배치되는 곳 = SQS 대기열 = 메뉴 주문판
- 규모 조정이 자동 실행되고, 안정적이며, 쉽게 구성하고 사용할 수 있음
- Amazon SNS
- 메시지를 서비스에 전달하는 데 사용되며, 알림을 최종 사용자에게도 전송 가능
- 게시/구독, 줄여서 Pub/Sub라고 하는 다른 방식으로 전송
- 사용자는 메시지 전달 채널인 SNS 주제 생성 가능
- 구독자 구성 후 구독자에게 최종 메시지 게시
⇒ SQS 대기열, AWS Lambda 함수, HTTPS 또는 HTTP 웹 후크 같은 엔드포인트도 구독자가 될 수 있음 - 모바일 푸시, SMS와 이메일을 사용하여 알림을 최종 사용자에게 전달할 수 있음
추가 컴퓨팅 서비스
- 서버리스
- EC2를 사용하면 사용자가 시간에 따라 인스턴스 플릿을 직접 설정 및 관리해야 함
⇒ 인스턴스 프로비저닝 → 사용자 코드 업로드 → 앱 실행되는 동안 계속 인스턴스 관리 - 서버리스 옵션 선택 시 어플리케이션을 호스팅하는 기본 인프라나 인스턴스는 보거나 이용할 수 없음
- 그 대신 프로비저닝, 규모 조정, 고가용성 및 유지 관리와 관련한 모든 기본 환경 관리를 대신 처리해줌
- 서버리스 App 자동 확장 가능(유연성)
- 처리량 및 메모리와 같은 소비 단위를 수정하여 App 용량 조절
- EC2를 사용하면 사용자가 시간에 따라 인스턴스 플릿을 직접 설정 및 관리해야 함
- AWS Lambda
- 서버리스 컴퓨팅 옵션
- 컨테이너와 가상머신이 없음
- 사용자가 서버를 프로비저닝하거나 관리할 필요 없이 코드를 Lambda 함수에 업로드
- AWS 서비스, 모바일 애플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거 되도록 코드 설정
- 트리거 구성 시, 람다 함수에서 서비스가 트리거를 기다림
- 트리거가 감지될 때에만 코드가 자동 실행되며 규모가 조절됨
⇒ 가용성이 높으며, 환경 내 모든 유지관리를 AWS가 수행
⇒ 사용한 컴퓨팅 시간(코드가 실제로 실행되는 시간)에 대해서만 비용 지불 - 코드를 15분 미만으로 실행하도록 설계되었기에 딥 러닝 등 장기 실행 프로세스에는 부적합
- 웹 백앤드, 요청 처리나 벡엔드 비용 보고 처리 서비스 등 빠른 처리에 적합
- 컨테이너 오케스트레이션 도구
- Docker 컨테이너 : 운영 체제 수준 가상화를 사용하여 컨테이너에 소프트웨어 제공
- 컨테이너 = App 관련 종속성 및 App에서 실행해야 하는 모든 구성을 하나의 객체로 모아 놓은 코드 패키지
- 애플리케이션을 디버깅하고 컴퓨팅 환경의 차이를 진단하는 데 드는 시간을 줄일 수 있음
- 컨테이너는 호스트가 EC2 인스턴스인 상황에서, EC2 인스턴스에서 실행되며
VM 작동 방식과 비슷하게 서로 격리되어 실행됨 - 단일 EC2 뿐만 아니라 클러스터(인스턴스 모음)에서 실행되는 컨테이너도 시작, 중지,
재시작, 모니터링하는 프로세스 필요
ECS, EKS, Fargate
- Amazon Elastic Container Service (ECS)
⇒ 컨테이너화된 App을 대규모로 실행하는 데 도움이 되도록 설계되어 뛰어난 확장성
⇒ 도커 컨테이너 지dnjs
⇒ API 호출을 사용해 도커 지원 애플리케이션을 시작 및 중지할 수 있음
- Amazon Elastic Kubernetes Service(Amazon EKS)
⇒ Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스- ECS, EKS 모두 EC2에서 실행 가능
- 기본 OS에 액세스할 필요가 없거나 EC2를 사용하여 컨테이너를 호스팅하지 않을 경우, AWS Fargate 활용
- AWS Fargate
⇒ ECS, EKS용 서버리스 컴퓨팅 플랫폼 = 컨테이너용 서버리스 컴퓨팅 엔진
⇒ 프로지버닝, 관리 없이 자동으로 서버 인프라 관리해줌
⇒ 컨테이너 실행에 필요한 리소스에 대해서만 비용 지불
요약
- 정리
- Linux나 Windows 같은 기본 운영 체제에 대한 완전한 액세스를 원한다면
⇒ EC2 - 단기 실행 함수, 서비스 지향 또는 이벤트 기반 App을 호스팅하고 싶으며 기본 환경을 전혀 관리하고 싶지 않다면
⇒ 서버리스 AWS Lambda - Docker 컨테이너 기반 워크로드를 실행하고 싶다면
⇒ ECS 혹은 EKS 선택 후 플랫폼 선택
⇒ EC2 인스턴스? or Fargate(서버리스 환경)
- Linux나 Windows 같은 기본 운영 체제에 대한 완전한 액세스를 원한다면
사람 재미를 아는 길잡이가 될래요
아주 유용한 정보네요!