AWS 스터디 - EC2

전재열·2024년 11월 21일

AWS SAA

목록 보기
9/11

EC2 소개

  • 클라우드 컴퓨팅 : 컴퓨팅 빌려 쓰기
  • EC2 : 컴퓨팅을 빌려 쓰는 서비스

EC2의 장점

  • 온디맨드 모델에서는 가격이 초 단위로 결정
    • 필요한 만큼 쓸 수 있다.
  • 서비스 요금을 미리 약정하거나 선입금이 필요 없음(약정을 한다면 더욱 싸게 이용 가능)
  • 몇 분이면 전 세계에 인스턴스 수백여대 구축 가능
  • 머신러닝, 웹서버, 게임서버, 이미지처리 등 다양한 용도에 최적화된 서버 구성 가능
  • 다양한 과금 모델 사용 가능
  • 오토스케일링, ELB, CloudWatch 등 다양한 서비스와 연동 가능
    • 서비스들 끼리 어떻게 연동되는지가 핵심

EC2의 구조

EC2 인스턴스란?

  • EC2에서 컴퓨팅을 담당
    • 다양한 유형과 크기로 구성
    • 저장을 담당하는 EBS와 네트워크로 연결
  • 저장 방법에 따라 두 가지로 분류
    • EBS 연동
    • 인스턴스 스토어
  • 하나의 가용영역(AZ)에 존재

인스턴스 유형

인스턴스 유형(패밀리)

  • 인스턴스의 역할에 따라 CPU, 메모리, 스토리지, 네트워크 등을 조합한 구성
  • 각 인스턴스 유형 별로 사용 목적에 따라 최적화
    • ex) 메모리 위주, CPU위주, 그래픽카드 위주 등등
  • 유형 별로 이름 존재
    • ex) t유형, m유형, inf유형 등
    • 같은 유형의 인스턴스들을 인스턴스 패밀리라 부름
  • 타입 별 세대별로 숫자 부여
    • ex) m5= m인스턴스의 5번째 세대
  • 아키텍쳐 및 프로세서/추가기술에 따라 접미사
    • ex) c7gn = c 인스턴스 중 AWS Graviton 프로세스 사용(g) + Network Optimized(n)

인스턴스 크기

  • 같은 인스턴스 패밀리에서 다양한 크기가 준재
  • 인스턴스의 cpu갯수, 메모리 크기, 성능 등으로 크기 결정
  • 크기가 클 수록
    • 더 많은 메모리
    • 더 많은 CPU
    • 더 많은 네트워크 대역폭
    • EBS와의 통신 가능한 대역폭

Amazon EBS

EBS란?

  • 가상 하드드라이브
  • EC2 인스턴스가 종료 되어도 계속 유지 가능
    • 루트 볼륨으로 사용시 EC2가 종료되면 같이 삭제됨
    • 단 설정을 통해 EBS만 따로 존속 가능
  • 용량을 범위에 따라 자유롭게 설정 가능
  • 특수하게 하나의 EBS를 여러 EC2 장착 가능한 경우도 있음(EBS Multi Attatch)
  • EC2 인스턴스와 같은 가용영역에 존재
  • 가용영역 내에 분산 저장

EBS의 유형

  • 범용(General Purpose) : SSD
  • 프로비저닝 된 IOPS (Provisioned IOPS) : SSD
    • 적은 용량, 빠르고 비쌈
  • 쓰루풋 최적화(Throughput Optimized HDD) : HDD
    • 대용량의 데이터 저장, 느림
  • 콜드 HDD (SC) : HDD
    • 파일 저장소, 잘 쓰지않는 데이터, 쌈
  • 마그네틱 (Standard) : HDD
    • 백업 저장소, 매우 쌈

Snapshot

  • 스냅샷 : EBS의 특정 시점을 저장한 이미지
    • 이후 EBS로 다시 복구 가능
    • EBS의 백업 용도로 활용 가능
  • 증분식 : 바뀐 부분 만 저장
    • 즉, 100gb 볼륨의 스냅샷을 5번 찍어도 500gb가 아닌 100gb+4번의 변경 부분만 저장
  • S3에 저장
  • Data Lifecycle Manager/ AWS Backup등으로 자동화 해서 생성 가능
  • 기타 여러 기능
    • 암호화
    • 아카이브
    • 공유

AMI(Amazon Machine Image)

  • EC2 인스턴스를 실행하기 위해 필요한 정보를 모은 템플릿
  • 구성
    • 1개 이상의 EBS 스냅샷
    • 사용 권한
    • 블록 디바이스 맵핑(볼륨 정보)
  • 필요에 따라 Private으로 가지고 있거다 Public 공개 가능

인스턴스 저장 유형에 따른 AMI의 생성 방법

  • EBS : 스냅샷을 기반으로 루트 디바이스 생성
  • 인스턴스 저장 : S3에 저장된 템플릿을 기반으로 생성

AWS 가격 정책

  • 미리 내지 않고, 사용한 만큼 내고 (On-Demand)
  • 많이 쓸수록 적게 내고
  • 예약할수록 더 적게 낸다

EC2의 요금 구성

  • 인스턴스 요금
  • 데이터 전송
  • Public IPv4 Ip
  • 연동 서비스
    • ELB, CloudWatch, EBS 등

EC2 요금 모델

  • On-Demand : 사용한 시간 만큼만 요금 지불
  • Spot Instances : 남는 인스턴스를 저렴하게 사용
  • Reserved Instances : 인스턴스 사용 기간을 약정
  • Dedicated : 물리적인 전용 인스턴스 임대
    • Dedicated Instance/Dedicated Host
  • Savings Plan : AWS의 컴퓨팅 사용량을 약정

보안 그룹

  • EC2의 방화벽 역할을 하는 서비스
  • Port 허용
    • 기본적으로 모든 포트는 비활성화
    • 선택적으로 트래픽이 지나갈 수 있는 Port와 Source를 설정 가능
    • Deny는 불가능
  • 인스턴스 단위
    • 하나의 인스턴스에 하나 이상의 보안 그룹 설정 가능
    • 인스턴스에 여러 보안 그룹이 적용될 경우 모든 보안 그룹의 규칙을 적용 받음

EC2의 생명 주기

중지

  • 중지 중에는 인스턴스 요금 미 청구
  • 단, EBS요금, 다른 구성요소는 청구
  • 중지 후 재시작시 퍼블릭 IP 변경

재부팅

  • 퍼블릭 IP 변동 없음

최대 절전모드

  • 메모리 내용을 보존해서 재시작시 중단지점에서 시작할 수 있는 정지모드

ENI(Elastic Network Interface)

  • EC2의 가상의 랜카드
  • IP주소와 Mac 주소를 보유
  • 하나의 인스턴스에 여러개의 ENI를 연동 가능
    • 하나의 인스턴스가 한 개 이상의 아이피를 보유 가능
  • 인스턴스 유형 및 사이즈에 따라 최대 보유 가능한 IP주소가 변동
  • 내부적으로는 보안 그룹은 ENI에 부착
  • 기본적으로 Private IP주소와 Private DNS 보유

Elastic IP

  • EC2의 퍼블릭 IP를 고정해주는 서비스
    • 즉 인스턴스를 중지->재시작 해도 고정적인 IP를 확보 가능
  • EC2이외에 다른 서비스에도 사용
  • 내가 보유한 IP주소를 AWS에서 사용 가능
  • 리전 단위
  • 연결하지 않아도 보유하기만 해도 비용 발생

EC2 User Data

  • EC2 인스턴스의 최초 실행 시 지정한 스크립트 실행 가능
    • 별도 설정을 통해서 재부팅 마다 실행하도록 설정 가능
  • 두 가지 모드
    • Shell Script
    • cloud-init : 리눅스 이미지의 부트스트래핑을 위한 오픈소스 어플리케이션
  • 주요 사용 사례
    • EC2 인스턴스 설정
    • 외부 패키지 다운로드
    • 설치 어플리케이션 실행
    • 기타 EC2 실행 시 필요한 동장

Amazon EC2 Instance Metadata

  • EC2 인스턴스의 속성 및 정보 데이터
    • AMI ID, IPv4/IPv6주소, EBS 맵핑, 보안 그룹 연동상황, IAM 역할 연동 등
  • 실행중인 EC2 인스턴스의 메타데이터 IMDS로 조회 가능
    • HTTP Endpoint 지원
    • IP주소 : 169.254.169.254, fd00:ec2::254
    • 두 가지 모드
      • IMDS v1 : Request/Response 기반
      • IMDS v2 : 세션 기반(default)
  • 주요 사용 사례
    • 인스턴스 별 설정, IAM 임시 자격증명 조회 등
  • EC2 실행 시 메타데이터 엑세스 가능 여부 설정 가능
    • 기본 활성화
    • 버전 선택 가능
  • 무료

Instance Metadata Service V1

  • 별도의 보안 인증이 필요 없는 Request/Response 기반
    • Link Local IP를 사용하기 때문에 해당 EC2 인스턴스에서만 요청 가능
  • CloudWatch Metric을 활용해서 조회 횟수 기록 가능
  • ex) 인스턴스 이름 가져오기 curl http://169.254.169.254/latest/meta-data/tags/instance/Name

Instance Metadata Service V2

  • 보안 토큰을 발급받아 요청할 떄 마다 토큰을 사용해 인증하는 세션 방식
    • 토큰의 유효기간은 1초에서 최대 6시간
  • IMDSv1보다 높은 보안 수준 제공
    • IAM 정책 등을 활용하여 EC2 인스턴스가 IMDS v2를 사용하도록 강제 가능
    • 활용 시 EC2 인스턴스 내부의 AWS CLI, SDK등이 IMDSv2를 지원하는 최신 버전임을 확인 필요

EC2에 권한 부여

IAM 자격 증명을 등록

  • IAM사용자를 생성하고 IAM 자격증명을 발급받아 EC2에 등록
  • AWS Configure를 통해 자격 증명을 파일로 등록(~/.aws/credentials)
  • 관리가 어렵고 바꾸기 힘듦
    • ex) EC2 100대의 자격증명을 교체해야 한다면?

IAM 역할을 부여

  • 권한이 부여된 IAM 역할을 만들고 EC2에 부여
  • 관리가 쉽고 교체가 쉬움
  • 내부적으로 지속적으로 자격증명을 변경
    • 뛰어난 보안성

EC2 Auto Scaling

정확한 수의 EC2 인스턴스를 보유하도록 보장

  • 그룹의 최소 인스턴스 숫자 및 최대 인스턴스 숫자
    • 최소 숫자 이하로 내려가지 않도록 인스턴스 숫자를 유지
    • 최대 숫자 이상 늘어나지 않도록 인스턴스 숫자 유지

다양한 스케일링 정책 적용

  • 다양한 스케일링 정책
    • ex)CPU의 부하에 따라 인스턴스 크기를 늘리기
    • ex)특정 시간에 인스턴스 개수 늘리고 다른 시간에 줄이기

시작 구성/ 시작 템플릿

  • EC2의 유형, 크기
  • AMI, 보안 그룹, Key, IAM 역할
  • 유저 데이터
  • 기타 설정

모니터링

  • ex) CPU 점유율이 일정 %을 넘어 섰을때 추가로 실행
  • ex) 2개 이상이 필요한 스택에서 EC2 하나가 죽었을 때

설정

  • 최대/최소/원하는 인스턴스 숫자
  • ELB와 연동 등

기타 설정 사항

  • 종료 정책 : 인스턴스 숫자를 줄일 경우 어떤 순서로 인스턴스를 종료시킬지에 관한 정책
    • 기본:
      • 인스턴스가 2개 이상인 가용영역의 인스턴스에서
      • 가장 오래된 시작 템플릿
      • 모두 같은 시작 템플릿이라면 다음 과금 시간에 가장 가까운 인스턴스 종료
    • 커스텀:
      • 가장 예전 시작 템플릿부터
      • 가장 오래된 인스턴스부터
      • 가장 최근 인스턴스부터 등
  • Lambda를 활용해서 커스텀 정책 적용 가능

Elastic Load Balancer

  • 다수의 EC2에 트래픽을 분산 시켜주는 서비스
  • 총 4가지 종류
    • Application Load Balancer
    • Network Load Balancer
    • Classic Load Balancer
    • Gateway Load Balancer
  • Health Check
  • Autoscaling과 연동 가능
  • 지속적으로 IP 주소가 바뀌며 IP 고정 불가능 : 항상 도메인 기반으로 사용

Application Load Balancer

  • 똑똑하다
  • OSI Moder Layer 7
  • 트래픽을 모니터링 하여 라우팅 가능
    • ex) image.sample.com > 이미지 서버로, web.sample.com > 웹 서버로 트래픽 분산

Network Load Balancer

  • 빠르다
  • OSI Model Layer 4
  • TCP, UDP 기반 빠른 트래픽 분산
  • Elastic IP 할당 가능

Classic Load Balancer

  • 옛날거
  • 요즘 잘 사용하지 않음

Gateway Load Balancer

  • 먼저 트래픽을 체크함
  • OSI Layer 3
  • 가상 어플라이언스 배포/확장 관리를 위한 서비스

대상 그룹

  • ELB가 라우팅 할 대상의 집합
  • 구성
    • 대상 종류
      • Instance
      • IP
      • Lambda
      • ALB
    • 프로토콜(HTTP,HTTPS,gRPC,TCP 등)
    • 기타 설정
      - 트래픽 분산 알고리즘, 고정 세션 등

리스너

  • ALB로 들어오는 요청을 처리하는 주체
    • 들어오는 트래픽의 프로토콜 + 포트 단위
  • 규칙으로 ALB에서 어떤 요청을 받을지, 요청을 어떻게 어디로 처리할지 결정
  • 규칙을 활용해 다양한 조건에 따라 트래픽 배분 가능
    • 활용 가능한 조건 : Header, QueryString, source IP, Method 등
  • 들어온 트래픽 처리 방식 : forward, redirect, fixed-response, cognito 인증 등

ELB의 비용

  • 기본적으로 시간당 프로비전 비용
  • 추가적으로 트래픽/사용량 비용
  • 프로비전 시 시간당 비용 청구 (서울리전 기준)
    • 기본 $0.0225/시간
    • $0.008/LCU-시간
  • LCU : ALB가 트래픽을 처리하는 단위
    • 1LCU는
      • 25개의 새로운 컨넥션/초
      • 3000/분 연결 숫자 or 1500/분 TLS
      • 1GB/시간 의 EC2, 컨테이너, IP주소, 혹은 0.4GB/시간 의 Lambda 함수 트래픽
      • 1000/ 초 룰 평가(10개 무료)
    • 이 중 가장 높게 측정된 것 기준으로 계산

NLB의 비용

  • 프로비전 시 시간당 비용 청구 (서울리전 기준)
    • $0.0225/시간
    • $0.006/NLCU
  • NLCU : NLB가 트래픽을 처리하는 단위
    • 1NLCU
      • 800ㅅ TCP 연결, 400UDP/초
      • 100,000 TCP 초당 연결유지, 50,000 UDP
      • 1GB / 시간 EC2, 컨테이너, IP, ALB 대상 트래픽

Amazon CloudWatch 와 EC2

  • AWS에서 제공하는 AWS 서비스 / 어플리케이션의 모니터링 서비스
  • EC2 를 포함한 AWS의 다양한 서비스에 기본적인 모니터링을 지원
  • EC2의 주요 지표
    • CPU 사용량
    • 디스크
    • 네트워크
    • CPU Credit 관련 지표
    • 상태 관련
  • 이외에 커스텀 지표 활용 가능
  • EC2의 경우 별도로 활성화 불필요 / 무료
  • 기본 5분 단위 (상태 확인만 1분 단위)
  • EC2 세부 모니터링
    • 모든 지표에 1분단위 모니터링
    • 메트릭 별로 비용 발생, 단 저장 비용은 없음
    • 별도로 활성화 필요

Amazon CloudWatch 와 Autoscale

  • Autoscale 지표
    • 지표의 별도로 활성화 필요
  • 주요 지표
    • 용량
    • 인스턴스 상태
    • 기타 관리중인 인스턴스 모두의 통합 지표 제공
  • 이외에 내부적으로 Autoscaling의 알람, 타켓 추적 스케일링 정책등은 CloudWatch 기반

Amazon CloudWatch 와 ELB

  • ELB 지표는 기본적으로 활성화
  • 주요 지표
    • 요청/연결
    • Status Code별 Count(3xx,4xx,5xx)
    • IPv6 처리
    • 네트워크 지표 (처리된 네트워크 트래픽)

AutoScale Scaling 정책

  • Autoscale에서 관리하고 있는 인스턴스의 숫자를 조절하는 방식
  • 크게 네 가지 분류
    • 수동 스케일 : 수동으로 직접 인스턴스 숫자를 증감
    • 스케쥴기반 스케일 : 특정 시점에 인스턴스 숫자를 증감
      • 주로 예측 가능한 시점의 부하 처리 목적으로 활용
    • 동적 스케일 : 특정 기준을 두고 기준치에 따라 인스턴스 숫자를 증감
      • ex) CPU사용률 기반, 요청 숫자 기반, 판매량 기반 등
    • 예측기반 스케일 : 과거의 기록의 패턴을 기반으로 수요량을 예측해서 인스턴스 숫자를 증감

수동 스케일

  • 수동으로 인스턴스 숫자를 조절
    • 주로 개발 환경 혹은 다른 정책을 적용하기 전 사전 테스트 용도로 활용
  • 되도록이면 다른 스케일 정책을 비활성화 시킨 후 적용 추천

스케쥴기반 스케일

  • 예측 가능한 시점의 변동사항에 대비해서 인스턴스 숫자를 조절하는 방식

  • 적용 방식

    • 특정 시점을 정해서 해당시점 or Cron으로 표현하는 반복 시점에
    • 범위 지정
      • 지정한 범위보다 인스턴스가 작다면 Scale Out
      • 지정한 범위보다 인스턴스가 크다면 Scale In

Cron Expression

  • 특정 시간의 주기를 표현하기 위한 표현식
  • 1분 단위가 최소 단위

동적 스케일

  • 지표에 반응해서 인스턴스 숫자를 조절하는 방식
    • 주로 CloudWatch의 지표 활용
    • 혹은 자신만의 기준으로 스케일링 정책 조절 가능
  • 주로 Autoscale에서 지원하는 추적 조정 정책 활용
    • 내부적으로 CloudWatch Alarm을 생성해서 Alarm에 반응하여 자동으로 증감
    • 지표 증감에 따라 얼마나 민감하게 반응할 것인지 결정 가능
  • 필요시 커스텀 로직을 활용해서 Autoscale의 증감을 수동으로 조절 가능

예측기반 스케일

  • 사용 패턴의 히스토리를 기반으로 인스턴스 수요량을 예측하여 인스턴스 숫자를 조절하는 방식
    • 주로 반복되는 패턴이 명확한 경우, 혹은 인스턴스 준비가 오래 걸리는 경우 사용
    • ex) 매일 오후 2시에 레이드 이벤트가 열리는 게임 서비스의 서버
  • CloudWatch 지표를 14일간 분석하여 패턴을 만들고 다음 48시간의 사용 패턴을 분석
  • 수요량에 따라 증가만 가능
    • 즉, 인스턴스 숫자를 감소시키려면 동적 스케일링 정책 필요
  • 주의사항
    • Autoscale Group에 다양한 인스턴스 종류가 섞여있을 경우 효율성이 매우 떨어짐
    • 다양한 스케일링 정책이 공존할 경우 효율성이 떨어짐
    • 충분한 데이터가 쌓일 때 까지 기다림 필요

Health Check

  • 인스턴스의 상태를 체크하는 기능
  • 상태 확인 소스
    • EC2 : 인스턴스가 실행중인지, 하드웨어 상태가 정상적인지 확인
    • ELB : 트래픽을 발생시켜서 해당 트래픽을 잘 수행하는지 확인
    • VPC Lattice : 생략
    • 커스텀 : 직접 커스텀 로직으로 상태를 확인
  • 상태확인에 실패했을때 Unhealthy 상태로 변경 > Autoscale에서 직접 해당 인스턴스를 교체

인스턴스 Warm Up / Health Check Grace Period

  • 인스턴스 Warm Up
    • 인스턴스에 대한 CloudWatch의 모니터링 지표가 수집 되기 전 준비 기간
    • 트래픽을 받기 전에 지표등이 반영되지 않도록 설정 가능
  • Health Check Grace Period
    • 신규로 추가된 인스턴스가 Health Check을 수행 하기 전 준비를 위한 기간
      • 기본 300초
    • 인스턴스가 신규로 올라간 이후 준비가 오래 필요할 경우 등에 활용

Instance Scale-In Protection

  • Autoscale 혹은 인스턴스 단위로 인스턴스의 종료를 막는 기능
  • 디버그 목적 혹은 로직을 끝까지 수행할 수 있도록 보장하기 위해서 사용
  • Protection이 있어도 종료되는 경우
    • Health Check Fail
    • Spot 인스턴스
    • 수동으로 삭제

인스턴스 Lifetime 관리

  • 인스턴스가 최대로 실행되어 있는 기간(초 단위)을 설정 가능
    • 해당 기간 이후 자동으로 교체
  • 최소 1일
  • 설정을 취소하려면 새로운 값을 0으로 입력 > 모든 인스턴스에 적용
  • Scale In Protection이 걸려있을 경우, 해당 기능 우선
    • 즉, 인스턴스가 종료되지 않을 수 있음
  • 기본 교체 방법은 인스턴스가 종료된 후 신규 인스턴스 생성

인스턴스 유지 관리 정책

  • 인스턴스의 숫자가 변동할 때 어떤 우선순위로 어떻게 변동할지를 정하는 정책

인스턴스 유지 관리 기본 정책

인스턴스 유지 관리 커스텀 정책

Autoscale 기능 임시 비활성화

  • 임시로 Autoscale의 다양한 기능을 비활성화/활성화 가능
    • 주로 디버그 / 상황 대응의 복적으로 활용
  • 주요 비활성화 가능한 기능
    • Launch : 인스턴스의 Scale Out이 필요할 때 신규 인스턴스를 시작을 비활성화
    • Terminate : 인스턴스의 Scale In이 필요할 때 인스턴스 중지를 비활성화
    • AddToLoadBalancer : ELB에 인스턴스 등록을 중지
    • AZRebalance : 가용영역간에 골고루 인스턴스가 분배되도록 인스턴스 조절 기능을 중지
    • HealthCheck : 인스턴스의 상태 체크를 비활성화
    • ReplaceUnhealthy : HealthCheck에 실패한 인스턴스의 교체 비활성화

Autoscale 관리 임시 해제

  • 임시로 Autoscale으로 관리중인 인스턴스를 StandBy 상태로 전환 가능
  • StandBy : ELB의 트래픽을 받지 않고 HealthCheck도 임시로 비활성화된 상태
  • 업데이트, 디버그 등등 목적으로 활용 가능
    • 예 : 인스턴스를 StandBy로 두고 관련 소프트웨어 업데이트 후 복귀
  • StandBy 설정 시 desired capacity 조절 가능
    • desired capacity 하나를 낮추면 Autoscale그룹에서 인스턴스 숫자 유지
    • desired capacity 변경 없이 진행한다면 Autoscale그룹에서 인스턴스를 추가
  • AZRebalance 가 비활성화 되어있지 않다면, StandBy가 풀리면서 인스턴스 조정 가능

Autoscale Lifecycle Hooks

  • Autoscaling의 각 단계에서 특정 로직을 수행할 수 있는 기능
    • 주로 미리 수행되어야 하는 작업/ CI/CD 파이프라인을 통한 배포 등을 수행
  • 추후 Notification Target에 대해 배우고 나서 실습진행 예정

Elastic File System

  • NFS 기반 공유 스토리지 서비스
    • 따로 용량을 지정할 필요 없이 사용한 만큼 용량이 증가 <-> EBS는 미리 크기를 지정해야 함
  • 페타바이트 단위까지 확장 가능
  • 몇 천개의 동시 접속 유지 가능
  • 데이터는 여러 AZ에 나누어 분산 저장
  • 쓰기 후 읽기 일관성
  • Private Service : AWS 외부에서 접속 불가능
  • 각 가용영역에 Mount Target을 두고 각각의 가용영역에서 해당 Mount Target으로 접근
  • Linux Only

Amazon EFS 타입

  • Regional : 리전 전체를 활용하여 고가용성과 내구성 확보
  • One-Zone : AZ 하나만 활용하여 고가용성과 내구성은 떨어지지만 저렴한 가격

Amazon EFS 퍼포먼스 모드

  • General Purpose : 가장 보편적인 모드
  • Max IO : 매우 높은 IOPS가 필요한 경우

EFS Throughput 모드

  • Elastic Throughput : EFS가 자동으로 Throughput을 조절 - 예측하기 어렵거나 적은 범위에서 변동이 있는 경우
  • Bursting Throughput : 낮은 Throughput일 때 크레딧을 모아서 높은 Throughput일때 사용
  • Provisioned Throughput : 미리 지정한 만큼의 Throughput을 미리 확보해두고 사용

T인스턴스

  • T 인스턴스는 burstable performance instances
    • 다른 인스턴스 타입처럼 고정된 용량의 CPU 자원을 제공하지 않음
    • CPU 크레딧 제도
      • CPU 사용량이 기본 수준 이상이라면 크레딧을 차감
      • CPU 사용량이 기본 수준 미만이라면 크레딧을 제공
    • 베이스라인 : CPU사용량을 통해 크레딧의 소모와 증가가 같은 지점
  • 즉 평소에는 baseline 밑으로 유지해 크레딧을 모으고 꼭 필요한 상황에 크레딧을 소모해 Burst
  • 크레딧이 없다면 최악의 경우 CPU 사용량이 5% 미만으로 제한

T인스턴스 모드

  • 스탠다드 모드
    • 베이스라인 이상으로 Burst가 발생할 경우 미리 저장된 크레딧을 소모해 CPU 사요
    • 크레딧이 없다면 베이스라인 이상으로 CPU 사용 불가
  • 언리미티드 모드
    • 제한없이 필요한만큼 CPU 사용
    • 베이스라인 이상으로 Burst가 발생할 경우 미리 저장된 크레딧을 소모해 사용
    • 크레딧이 없을경우, 24시간 안으로 크레딧을 빌려 충당
    • 24시간 안에 베이스라인 미만으로 CPU를 유지해 추가된 크레딧으로 갚기 가능
    • 갚지 못한 크레딧은 비용을 지불해 충당
  • T2는 스탠다드가 기본, T3는 언리미티드가 기본

Launch Credit

  • T2 인스턴스의 경우 Launch Credit을 제공
    • 인스턴스가 처음 생성될 때 제공
    • 생성 직후에 Burst 로 진입할 경우를 대비
    • Standard 모드가 Default 이기 때문
  • T3의 경우 Unlimited Mode가 기본이기 떄분에 Launch Credit이 부여되지 않음
    • 즉 T3를 Standard모드로 사용해서 생성할 경우, 바로 Burst 진입 불가

T2인스턴스가 크레딧이 없을 경우

  • 인스턴스의 응답이 없음
  • 어플리케이션이 자주 멈춤

해결책

  • 인스턴스 사이즈 들리기
  • 인스턴스 타입 바꾸기
  • Unlimited 모드로 바꾸기
  • 계획적으로 CPU 사용하기

인스턴스 타입 변경

  • 클라우드 컴퓨팅의 장점을 최대한 이용하여 프로비전 이후에도 적절한 타입/사이즈로 변경 가능
  • 두 가지 변경
    • 사이즈 변경 : 같은 인스턴스 패밀리에서 사용량에 따라 크기 조절
    • 패밀리 변경 : 워크로드의 성격에 따라 다른 인스턴스 패밀리로 변경
  • 호환성 체크 필요
    • 가상화타입, EBS 볼륨 개수 등
  • 인스턴스 정지 필요
    • Spot 인스턴스는 변경 불가능
    • HealthCheck 불가능 > Autoscale에 영향
  • 참고사항
    • 인스턴스 아이디는 유지
    • Private IP는 유지하지만 Public IP는 변경(중지하고 시작하기 때문)
  • 인스턴스 스토어와 EBS 사용 인스턴스에 따라 과정이 달라짐
profile
재열이

0개의 댓글