[AWS] 컴퓨팅 서비스(EC2, Lambda, Elastic Beanstalk, ECS 등)

AWS 컴퓨팅 서비스

AWS는 다양한 컴퓨팅 서비스를 제공한다.

🔗 컴퓨팅 서비스 분류(4가지 범주)

컴퓨팅 서비스 분류

---

🔗 최적의 컴퓨팅 서비스 선택

• 최적의 컴퓨팅 서비스 또는 사용하는 서비스들은 사용 사례에 따라 달라진다.
• 고려해야할 측면
  • 애플리케이션 설계
  • 사용량 패턴
  • 관리하려는 구성 설정
• 아키텍처에 적합하지 않은 컴퓨팅 솔루션을 선택 → 성능 효율의 저하
  • 바람직한 시작 단계 → 사용 가능한 컴퓨팅 옵션 파악

---

🔗 EC2(Elastic Compute Cloud)

• 안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스
• 다양한 종류(Application, Web, Database, Game, …)의 서버를 올릴 수 있다.
• 클라우드에서 EC2 인스턴스라고 하는 가상머신 제공
• 각 인스턴스에서 게스트 운영체제(Windows or Linux)를 완벽하게 제어 가능
  • 인스턴스에서 실행되는 운영체제에 대한 모든 관리 제어 권한은 고객에게 있음. 대부분의 서버 운영체제가 지원(Windows, Red Hat, Ubuntu, Amazon Linux 등)
• 전 세계 어디서나 가용 영역에서 모든 크기의 인스턴스를 시작 가능
  • AMI에서 인스턴스 시작
  • 클릭 몇번이나 코드 한줄로 인스턴스를 시작하고, 몇분만에 준비가 완료
• 인스턴스 안팎으로 전송되는 트래픽은 “보안 그룹(=방화벽)”을 사용하여 제어

📍EC2의 특성

• 초 단위 온디맨드 가격 모델
  • 온디맨드 모델에서는 가격이 초 단위로 결정
  • 서비스 요금을 미리 약정하거나 선입금이 불필요
• 빠른 구축 속도와 확장성
  • 몇분이면 전세계에 인스턴스 수백여대를 구축 가능
• 다양한 구성방법 지원
  • 머신러닝, 웹 서버, 게임 서버, 이미지 처리 등 다양한 용도에 최적화된 서버 구성 가능
  • 다양한 과금 모델 사용 가능
• 여러 AWS 서비스와 사용 가능
  • 오토스케일링: EC2의 수를 자동으로 조절
  • Elastic Load Balancer(ELB): 다수 EC2의 트래픽을 분산
  • CloudWatch: CPU 사용량, 메모리 사용량을 모니터링

📍 EC2의 구성

• 인스턴스
  • 클라우드에서 사용하는 가상 서버로 CPU, 메모리, 그래픽 카드 등 연산을 위한 하드웨어를 담당
• EBS(Elastic Block Storage)
  • 클라우드에서 사용하는 가상 하드디스크
• AMI
  • EC2 인스턴스를 실행하기 위한 정보를 담고있는 이미지(템플릿)
• 보안 그룹
  • 가상의 방화벽

---

🔗 EC2 인스턴스 구성 과정

📍 1. AMI 선택

• AMI(Amazon Machine Image): EC2를 생성하는데 사용되는 템플릿으로, 인스턴스를 시작하는데 필요한 SW 구성(OS, 서버 프로그램 설정 및 앱)이 미리 구성된 이미지
• AMI 선택 (4가지 범주)
  • Quick Start: AWS에서 일반적으로 제공하는 일반적인 AMI
  • MyAMI: 사용자가 생성한 AMI
  • AWS Marketplace: AWS 및 신뢰할 수 있는 타사 AMI
  • 커뮤니티 AMI: 다른 사용자가 공유하는 AMI(누구나 게시)

📍 2. 인스턴스 유형 선택

• 사용 사례를 고려하여 선택하여야함
• 선택하는 인스턴스 유형에 따라 결정되는 항목
  • 메모리(RAM)
  • 처리능력(CPU)
  • 디스크 공간 및 디스크 유형(스토리지)
  • 네트워크 성능
• 인스턴스 유형 범주
  • 범용
  • 컴퓨팅 최적화
  • 메모리 최적화
  • 스토리지 최적화
  • 가속화 컴퓨팅
• 인스턴스 유형은 패밀리, 세대 및 크기 제공
  • 인스턴스 유형 이름
   

• 예: t3.large
• t: 패밀리 이름
• 3: 인스턴스 유형의 세대 번호
• large: 크기
• 일반적으로 세대가 높은 유형일수록 인스턴스가 더 강력하며 더 우수한 가격대비 가치를 제공
• 인스턴스 유형 선택: 사용 사례에 따라 선택

📍3. 네트워크 설정 지정

• 인스턴스 배포 위치: VPC 및 서브넷(선택) 확인(VPC를 지정해주지 않으면 기본 VPC에 배치)
• 퍼블릭 IP 주소를 자동으로 할당할지 여부
  • 인터넷에서 액세스할 수 있도록 할지 여부

📍 4. IAM 역할 연결(선택)

• EC2 인스턴스의 소프트웨어가 다른 AWS 서비스와 상호작용해야 하는지의 여부
• 상호 작용해야 하는 경우 적절한 IAM 역할 연결
• AWS IAM을 사용하면 AWS의 서비스 및 리소스에 액세스할 수 있는 주체를 지정하고, 세분화된 권한을 중앙에서 관리하며 액세스 권한을 분석하여 “AWS 전체의 권한을 세분화”
• EC2 인스턴스에 연결된 AWS IAM 역할은 인스턴스 프로파일에 보관

📍 5. 사용자 데이터 스크립트(선택)

• 인스턴스 시작 시 사용자 데이터 스크립트 지정(선택)
• 사용자 데이터 스크립트를 사용하여 인스턴스의 런타임 환경을 사용자 지정
  • 인스턴스가 처음 시작될 때 스크립트가 실행
• 전략적으로 사용 가능: 예를 들어 구축 및 유지 관리하는 사용자 지정 AMI의 수를 줄일 수 있음.

📍 6. 스토리지 지정

• 루트 볼륨 구성: 게스트 운영체제(Window, Linux)가 설치되는 위치
• 추가 스토리지 볼륨 연결(선택)
• 각 볼륨에 대해 다음 지정
  • 디스크 크기(GB)
  • 볼륨 유형: SSD or HDD
• 인스턴스 종료 시 볼륨 삭제 여부(서버 종료시 스토리지의 데이터도 같이 삭제할 것인지)
• 암호화(EBS 자체를 암호화 시키는 것 → 해킹당해도 안전. 내용물 데이터가 암호화 되는 것이 아닌 하드가 암호화) 사용 여부
• EC2 스토리지 옵션
  • EBS: 내구성이 뛰어난 “블록”수준 스토리지 볼륨. 인스턴스를 중지한 후 다시 시작할 수 있으며 데이터가 그대로 유지. 루트 볼륨 적용.
  • Amazon EC2 인스턴스 스토어: 스토리지는 EC2 인스턴스가 실행 중인 호스트 컴퓨터에 연결된 디스크에서 제공. 인스턴스가 중지되면 여기에 저장된 데이터가 삭제. 버퍼 및 캐시와 같이 자주 변경되는 정보를 임시로 저장해야 하는 경우에 효과적. 루트 볼륨 적용.
  • 기타 스토리지 옵션(루트 볼륨 미적용)
    • Amazon Elastic File System(Amazon EFS) : 파일 시스템 탑재
    • Amazon Simple Storage Service(Amazon S3): Object Storage Service

📍 7. 태그 추가

• 태그는 AWS 리소스에 할당할 수 있는 레이블(메모기능같은너낌)
  • 키(key)와 값(value)으로 구성
  • 인스턴스를 여러개 사용할 경우 알아보기 쉽게 별명으로 구분하기 위한 기능
• 태깅은 EC2 인스턴스에 “메타데이터”를 연결할 수 있는 방법
• 태깅의 잠재적 이점 - 필터링, 자동화, 비용 할당 및 액세스 제어

📍 8. 보안 그룹 설정 → 방화벽을 설정하는 단계

• 보안 그룹은 인스턴스에 대한 트래픽을 제어하는 방화벽 규칙 세트: 인스턴스의 게스트 OS 외부에 존재
• 출발지 및 네트워크 통신에 사용할 수 있는 포트를 지정하는 규칙 생성
  • 포트 번호와 TCP, UDP, ICMP 등의 프로토콜 지정
  • 규칙을 사용하여 허용할 출발지(ex: IP 주소 또는 다른 보안 그룹 지정)

📍 9. 키페어 식별 또는 생성

• 키페어: 인스턴스에 접속하기 위한 물리키
• 인스턴스 시작 시 기존 키페어를 지정하거나, 새로운 키페어 생성. 일종의 비밀번호.
• 키페어의 구성
  • AWS에 저장하는 퍼블릭 키
  • 사용자가 저장하는 프라이빗 키 파일
• Windows AMI의 경우: 프라이빗 키를 사용하여 인스턴스에 로그인하는데 필요한 관리자 암호 획득
• Linux AMI의 경우: 프라이빗 키를 사용하여 SSH를 통해 인스턴스에 안전하게 연결
• pem 파일이 있어야지만 인스턴스에 접근이 가능한 원리

---

🔗 탄력적 IP 주소 사용 고려

• 인스턴스에서 설정된 공인 IP는 서버를 키고 끌때마다 새로운 것으로 갱신되기에 이를 하나의 IP로 고정하기 위해서 탄력적 IP를 사용. 사용하지 않는다면 인스턴스를 키고 끌때마다 아이피가 바뀜.
• 탄력적 IP 주소를 사용하면 인스턴스를 재부팅해도 IP 주소 또는 DNS 호스트 이름이 변경되지 않는다.
• 영구 공인 IP 주소가 필요한 경우: 탄력적 IP 주소를 인스턴스에 연결
• 인스턴스가 중지되었다가 다시 시작된 경우
  • 공인 IPv4 주소와 외부 DNS 호스트 이름 변경
  • 사설 IPv4 주소와 내부 DNS 호스트 이름은 변경 x
• 탄력적 주소의 특성
  • 필요에 따라 리전 내 인스턴스와 연결 가능
  • 릴리스를 선택할 때까지 계정에 할당된 상태로 유지

---

🔗 CloudWatch

• 인스턴스의 모니터링을 위한 서비스
• 실시간에 가까운 지표 제공
• Amazon EC2 콘솔 모니터링 탭에서 볼 수 있는 차트 제공
• 15개월 동안의 기록 데이터 유지
• 기본 모니터링: 기본 기능, 추가 비용 x, 5분마다 CloudWatch로 지표 데이터 전송
• 세부 모니터링: 미리 선택한 7개의 지표에 대한 고정 월별 요금. 1분마다 지표 데이터 전송.

---

🔗 EC2 요금 모델

📍 EC2 요금 모델

• 온디맨드 인스턴스: 시간당 요금. 장기 계약 불필요. AWS 프리티어 이용 자격.
• 전용 호스트: 고객을 위해 EC2 인스턴스 용량을 완전히 전용으로 사용하는 물리적 서버
• 전용 인스턴스: 단일 고객을 위한 전용 하드웨어의 VPC에서 실행되는 인스턴스.
• 예약 인스턴스: 예약하는 인스턴스에 대한 전체 결제, 부분 결제, 또는 선결제 요금 없는 결제. 해당 인스턴스에 대한 시간당 요금 할인. 1년 또는 3년 약정(장기약정)
• 정기 예약 인스턴스: 사용자가 지정한 반복 일정에 따라 항상 사용할 수 있는 예약 용량 구매. 1년 약정.
• 스팟 인스턴스: 사용 가능한 상태이고 입찰 가격이 스팟 인스턴스 가격보다 높으면 인스턴스가 실행됨(경매). AWS는 2분 전에 알림으로써 스팟 인스턴스를 중단 가능. 중단 옵션에는 종료, 중지, 최대 절전 모드가 포함. 온디맨드 인스턴스에 비해 요금이 훨씬 저렴할 수 있음. 애플리케이션을 실행할 수 있는 시점을 유연하게 선택할 수 있는 경우에 적합.

📍 EC2 요금 모델의 사용 사례 및 이점

---

🔗 비용 최적화의 4가지 원칙

📍 1. 적절한 크기

• 필요에 따라 인스턴스 프로비저닝
  • CPU, 메모리, 스토리지 및 네트워크 처리량
  • 사용 사례에 적합한 인스턴스 유형 선택
• Amazon CloudWatch 지표 사용
  • 인스턴스의 유휴 상태 정도. 유휴 상태가 되는 시점.
  • 인스턴스 축소
• 모범 사례: 적절한 크기로 조정한 후 예약

📍 2. 탄력성 증대

• 자주 사용되지 않는 EBS 인스턴스를 중지 또는 최대 절전 모드로 전환(예: 프로덕션 이외의 개발 또는 테스트 인스턴스)
• 사용량에 따라 요구 사항을 추족할 수 있도록 자동 조정 사용 → 자동화된 시간 기반 탄력성

📍 3. 최적의 요금 모델

• 사용 사례에 적합한 요금 모델 활용 ← 사용 패턴 고려
• 구매 유형 최적화 및 조합
• 예: 다양한 워크로드에 온디맨드 인스턴스 및 스팟 인스턴스 사용 / 예측 가능한 인스턴스에 예약 인스턴스 사용
• 서버리스 솔루션(AWS Lambda) 고려

📍 4. 스토리지 선택 최적화

• 스토리지 성능 및 가용성을 유지하면서 비용 절감
• EBS 볼륨 크기 조절
• EBS 볼륨 크기 변경(더 저렴한 스토리지로 성능 요구사항을 충족시킬 수 있는지 확인, st1 스토리지는 gp2스토리지 옵션보다 절반의 비용)
• 더이상 필요하지 않은 EBS 스냅샷(Amazon S3에 EBS 볼륨의 데이터를 백업하는 기능. 스냅샷은 마지막 스냅샷 이후 변경된 디바이스의 블록만 저장.).
• 특정 데이터 유형에 가장 적합한 대상 위치 식별
  • 인스턴스가 EBS에 상주해야 하는 애플리케이션인지?
  • 수명 주기 정책이 포함된 S3 스토리지 옵션을 통해 비용 절감

---

🔗 컨테이너 기본 사항

• 컨테이너는 운영체제를 가상화하는 방식 중의 하나
• 이점
  • 반복 가능
  • 독립형 실행 환경
  • 소프트웨어가 서로 다른 환경에서 동일하게 실행됨(개발자의 노트북, 테스트, 프로덕션)
  • 가상 머신보다 빠르게 시작, 중지 또는 종료할 수 있음(가상머신보다는 OS가 더 light 하기 때문)
• 컨테이너는 가상머신보다는 작으며 전체 운영체제를 포함하지는 않음.
• 컨테이너는 가상화 된 운영체제를 공유하며 리소스가 격리된 프로세스로 실행

📍 Docker

• 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어
• Docker에서 컨테이너를 실행
  • 컨테이너는 이미지 라고 하는 템플릿에서 생성
• 컨테이너에는 소프트웨어 애플리케이션을 실행하는데 필요한 모든 항목이 있음.
• Docker는 컨테이너를 호스팅할 각 서버에 설치. 컨테이너를 구축, 시작 또는 중지하는데 사용할 수 있는 간단한 명령을 제공.

📍 컨테이너와 가상 머신(VM) 비교 

• 모든 컨테이너는 하나의 EC2 인스턴스에서 실행
• Docker 엔진은 컨테이너와 Linux 게스트 OS의 상호작용 방식을 관리하는 역할
• 하이퍼바이저: 다수의 운영체제를 동시에 실행하기 위한 논리적인 플랫폼
• 가상머신은 게스트 OS가 한개이지만, 컨테이너는 각각의 앱마다 각각의 게스트 OS가 존재

📍 Amazon Elastic Container Service(Amazon ECS)

• Amazon Elastic Container Service(Amazon ECS): 확장성과 속도가 뛰어난 컨테이너 관리 서비스
• 주요 이점
  • Docker 컨테이너의 실행을 오케스트레이션
  • 인프라 구축의 복잡성 해소
  • EC2 서비스 사용자에게 익숙한 기능과 통합(EC2와의 연계)
    • Elastic Load Balancing
    • Amazon EC2 보안 그룹
    • Amazon EBS 볼륨
    • IAM 역할
• Amazon ECS는 컨테이너를 오케스트레이션 함.
  • 클러스터(인스턴스의 집합)에서 실행할 다수의 작업을 지정하면, Amazon ECS 스케줄러가 클러스터 내에 이러한 작업을 배치

📍 Amazon Elastic Container Registry(Amazon ECR)

• 개발자가 Docker 컨테이너 이미지를 손쉽게 저장, 관리 및 배포할 수 있게 해주는 완전 관리형 Docker 컨테이너 레지스트리.
• Amazon ECS 통합
• Docker 지원
• Team 협업
• 액세스 제어
• 타사 통합

---

🔗 AWS Lambda

• Lambda: 서버리스 컴퓨팅 서비스(이벤트 중심) → 서버 없이 코드 실행 → 이벤트가 발생했을 때 서버에 접속하지 않고 코드가 실행
• 동작 과정: 코드 업로드 → 실행하는 코드는 Lambda 함수. 일정에 따라 이벤트에 대한 응답으로 코드 실행. → 코드는 트리거된 경우에만 실행 → 사용한 컴퓨팅 시간에 대해서만 비용 지불
• 고객은 실행하려고 하는 코드를 포함하는 AWS 리소스인 Lambda 함수를 생성한 다음 일정에 따라 또는 이벤트에 대한 응답으로 Lambda 함수가 트리거 될 수 있도록 설정
• Lambda의 이점
  • 여러 프로그래밍 언어(ex. Java, Python, C#, Go, PowerShell, Node.js …) 지원 → 새로운 언어, 도구, 프레임워크 배울 필요 없음
  • 완전히 자동화된 관리
  • 내결함성 기본 제공
  • 여러 함수의 오케스트레이션 지원
  • 사용량에 따라 요금 지불
• Lambda 이벤트 소스(S3, DynamoDB, SNS, SQS, API Gateway, Application Load Balancer…)
  • 이벤트 소스 → Lambda 함수 → AWS Lambda → 코드 실행(트리거된 경우) or CloudWatch(로깅, 모니터링 지표)
• Lambda 함수는 이벤트를 처리하기 위해 작성하는 사용자 지정 코드이며 Lambda는 사용자 대신 Lambda 함수를 실행
• Lambda 함수 구성
  1. 함수 이름 지정
  2. 런타임 환경 지정(Python, Node.js…)
  3. 실행 역할: 함수에 IAM 역할 부여
  4. 함수 구성: 트리거 추가 포함
• “예약 기반” Lambda 함수 예제
  • Amazon EC2 사용량을 줄여야 하는 상황 가정
  • 미리 정해진 시간에 인스턴스를 중지하기로 결정(야간에 중지하고 다음 작업이 시작되기 전 아침에 인스턴스 다시 시작)
  • Lambda와 CloudWatch 이벤트를 구성하여 이러한 작업을 자동으로 수행
• “이벤트 기반” Lambda 함수 예제 - 썸네일 이미지 생성
  • S3 버킷에 업로드 되는 각 이미지 파일에 대한 썸네일 생성
  • 솔루션을 구축하려면 객체가 업로드 될 때 S3에 액세스하고 호출을 수행하는 Lambda 함수를 생성 → 이벤트 기반
  • 이 Lambda 함수는 소스 버킷에서 이미지 객체를 읽고 썸네일 이미지와 대상 버킷을 생성
• Lambda 제한: Lambda 함수를 실행하고 저장할 때 사용할 수 있는 컴퓨팅 및 스토리지 리소스에 대한 제한
  • 리전당 소프트웨어 제한: 동시실행 = 1000, 함수 및 계층 스토리지 = 75GB
  • 개별 함수에 대한 하드 제한: 최대 함수 메모리 할당 = 10240MB, 함수 제한 시간=15분, 배포 패키지 크기 = 압축 해제시 250MB(계층 포함)

---

🔗 AWS Elastic Beanstalk

• AWS Elastic Beanstalk: 앱 애플리케이션을 쉽게 시작 및 실행할 수 있는 방법
• 다음을 자동으로 처리하는 관리형 서비스
  • 인프라 프로비저닝 및 구성
  • 배포
  • 로드밸런싱
  • 자동 조정
  • 상태 모니터링
  • 분석 및 디버깅
  • 로깅
• Elastic Beanstalk에 대한 추가 요금 없음 → 사용한 기본 리소스에 대해서만 요금 지불

📍 Elastic Beanstalk 배포

• 공용 플랫폼용으로 작성된 웹 애플리케이션 지원 → Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker
• 사용자가 코드 업로드

• 사용자가 코드 업로드
  • Elastic Beanstalk가 배포를 자동으로 처리
  • Apache, NGINX, Passenger Puma, 및 Microsoft Internet Information Services(IIS) 서버에 배포

📍 Elastic Beanstalk의 이점

• 빠르고 간단하게 사용 시작 → 애플리케이션을 실행하는 인프라에 대해 자세히 알지 못해도 AWS 클라우드에서 애플리케이션을 신속하게 배포하고 관리
• 개발자 생산성 증가 ← 선택 또는 제어에 대한 제한 없이 관리 복잡성을 감소, 애플리케이션을 업로드하기만 하면 Elastic Beanstalk에서 용량 프로비저닝, 로드 밸런싱, 조정, 상태 모니터링에 대한 세부 정보를 자동으로 처리
• 확장의 어려움
• 완벽한 리소스 제어