인스턴스 유형 기본사항 7가지가 있다

  • General Purpose
  • Compute Optimized
  • Memory Optimized
  • Accelerated computing
  • Storage Optimized
  • Instance Features
  • Measuring Instance Performance

네이밍 컨벤션

m5.2xlarge

  • m : instance class → 범용의 ㅣㄴ스턴스
  • 5 : 인스턴스의 세대
  • 2xlarge : 인스턴스 크기 → 사이즈가 크면 클수록 당연하게 더 많은 메모리와 CPU를 가진다

 

시험과 관련되서 알아야할 것

  • General Purpose
    • 웹 서버나 코드 저장소같은 다양한 작업에 적합
    • 컴퓨팅, 메모리, 네트워킹 간 밸런스도 잘 맞는다
    • t2.micro
  • Compute Optimized
    • 컴퓨터 집약적인 작업에 최적화 → 고성능 프로세서
    • 일부 데이터 일괄처리, 미디어 트랜스 코딩, 고성능 웹 서버, HPC, 머신러닝, 전용 게임 서버
    • 모두 C로 시작하는 이름을 가진다
  • Memory Optimized
    • 메모리의 대규모 데이터 셋을 처리할 때
    • 고성능의 관계형, 비관계형 DB, 엘라스틱 캐시, 분산 웹 스케일 캐시 저장소, 비즈니스 인텔리전스 BI, 비정형 데이터의 실시간 처리
    • R로 시작하는 이름이 있지만 x1,z1 high memory등이 있다
  • Storage Optimized
    • 로컬 스토리지에서 대규모의 데이터셋에 엑세스할 때 적합
    • OLTP 시스템 (다수의 사용자에 의한 대량의 데이터베이스 트랜잭션을 실시간으로 실행할 수 있도록 지원) 관계형, NoSQL, Redis
    • 분산 파일 시스템, 데이터 웨어하우스 에플리케이션(비정형 데이터 처리)
    • I,G,H1등..

사용 가능한 인스턴스를 확인할 수 있다.

Amazon EC2 Instance Comparison

 

 

보안 그룹 및 클래식 포트

보안그룹은 EC2의 방화벽

  • 방화벽의 역할로써 포트로의 엑세스를 통제한다
  • 보안 그룹은 네트워크 보안을 실행하는데 핵심이 된다.
  • 인스턴스에 들어가고 나가는 트래픽을 제어
  • 허용 규칙만 포함된다
    • 인증된 IP 주소를 확인
    • 인바운드 네트워크, 아웃바운드 네트워크
  • IP 주소를 참조해 규칙을 만들 수 있다.
    • 컴퓨터의 위치나 다른 보안 그룹을 참조
    • 보안 그룹끼리 서로 참조할 수도 있다
  • 공개된 인터넷을 사용해 EC2 인스턴스에 엑세스하려는 경우 EC2에 보안 그룹을 생성해야한다(방화벽)
    • 보안 그룹은 규칙을 가지게 되는데 바로 인바운드 트래픽의 여부
    • 외부에서 EC2에서 들어오는 것이 허용되면 아웃바운드 트래픽도 수행할 수 있다
  • 보안 그룹은 여러 인스턴스에 연결 가능하며 일대일 관계는 없다
    • 인스턴스에도 여러 보안 그룹을 연결할 수 있다
    • 리전과 VPC 결합으로 되어있으며 리전 변경시 다시 만들어야한다
    • 보안 그룹은 EC2 외부에 있으며 트래픽이 차단되면 EC2 인스턴스 확인 불가능
      • EC2가 실행하는게 아님
      • 보안을 위해서 SSH 액세스를 위해 하나의 별도 보안 그룹을 유지하는 게 좋다
      • 타임아웃으로 애플리케이션에 접근할 수 없으면 보안 그룹 문제
      • 연결 거부 오류가 발생한다면 보안 그룹은 실행됐고 트래픽은 통과됐지만 애플리케이션에서 문제가 발생한 것을 의미함
    • 기본적으로 모든 인바운드 트래픽은 차단
    • 기본적으로 모든 아웃바운드 트래픽은 열려있다
  • 로드밸런서를 사용하면 완벽한데 보안 그룹의 다른 보안 그룹을 참조
    • 첫 번째 EC2에서 2개의 인바운드 보안그룹을 허용해두었다
      • 두 번째 EC2가 첫 번쨰 EC2 보안 그룹을 하나만 가지더라도 접근 가능
    • 인스턴스의 IP와 상관없이 보안 그룹으로 그룹화되어 자동으로 다른 EC2에서 연결 가능
  • SSH, HTTP 쿼리를 시도하는데 타임아웃이 걸리면 100% 보안 그룹 문제이다
//인바운드 트래픽
인터넷 --> EC2
인터넷 <-- EC2
//아웃바운드 트래픽

 

EC2 클래식 포트 - 시험에 나오는 것들

  • SSH = 22번 포트로 시큐어 쉘
    • Linux에서 Ec2인스턴스로 로그인
  • FTP = 21번 포트 파일 공유 시스템 파일 업로드
  • SFTP = 22번 포트 시큐어 파일 트랜스퍼 프로토콜로 SSH를 통해 파일을 업로드함
  • HTTP = 80번 포트 - 암호화되지않음 - 보안x
  • HTTPS = 443번 포트 - 암호화됨 - 보안o
  • RDP = 3389 원격 데스크톱 프로토콜로 윈도우에 로그인할 때 사용함

 

보안그룹 실습

자동으로 생성된 launch-wizard도 다른 인스턴스에 넣을 수 있다

 

SSH

터미널이나 CLI로 서버를 제어할 수 있게 해준다

  • 클라우드에서 실행 시 까다로운 부분 중 하나는 유지보수나 조치를 취하기 위해 서버 내부와 연결하는 것
  • 컴퓨터 운영체제에 따라 방법은 다양하다
  • 맥과 리눅스에서 사용 가능하고 윈도우10버전 이상에서 사용 가능하며 이 외엔 Putty 사용
  • 이 외엔 EC2 인스턴스 커넥트로 웹에서 운영체제 관계없이 사용가능함
    • 단 인스턴스가 아마존 리눅스2 운영체제를 사용해야만 한다

 

SSH 연결하기

//키를 먼저 등록해줘야한다
chmod 0400 EC2TutorialKey.pem // Key읽기 권한 부여

//ec2-user라는 이름을 설정한 이유는 ec2접근할 때 디폴트로 생성되는 이름
//접근하는 유저명은 인스턴스가 생성될 때 만들어진 것과 관계가 있기 때문에 IAM과 큰 연관은 없다
ssh -i EC2TutorialKey.pem ec2-user@퍼블릭 인스턴스 ip
ssh ec2-user@퍼블릭 instance-ip
__|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\\___|___|

<https://aws.amazon.com/amazon-linux-2/>
[ec2-user@ip-private-ip ~]$

유저명과 프라이빗 ip가 뜨면 접근이 정상적응로 이루어진 것이다

 

EC2를 위한 IAM 역할(Role)

EC2 인스턴스에 엑세스 키 ID와 secret 엑세스 키를 입력해두면 해당 EC2 인스턴스에 접속하는 누구든지 정보를 회수할 수 있기 떄문에 보안상으로 절대 입력해서는 안된다

aws iam list-users
Unable to locate credentials. You can configure credentials by running "aws configure".
[ec2-user@private-ip ~]$ aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:

→ 반드시 IAM Role을 활용해야 한다

 

 

이전에 만들어두었던 IAM Role을 연결해준다.

이렇게 하면 실제 ec2에서도 유저 권한에 관한 설정이 가능

[ec2-user@private ip ~]$ aws iam list-users
{
    "Users": [
        {
            "UserName": "bj_choi",
            "PasswordLastUsed": "2023-05-15T00:26:37Z",
            "CreateDate": "2023-05-09T00:16:44Z",
            "Path": "/",
            "Arn": "arn:aws:iam::717107759992:user/bj_choi"
        }
    ]
}

 

EC2 인스턴스 구매 옵션

  • On-demand 인스턴스 - 사용한만큼 지불
    • 시간 단위로 청구
    • 비용이 가장 많이 들지만 바로 지불할 금액도 없고 장기적인 약정도 없다
    • 단기적이고 중단없는 워크로드, 애플리케이션이 어떻게 될지 모를 때 추천
  • Reserved 인스턴스 - 예약 인스턴스 1~3년 장기간의 워크로드를 위함
    • 온디맨드에 비해 72% 할인 / 선결제
    • 인스턴스 타입, 리전, Tenancy(인스턴스 격리 유형), OS
      • 특정 범위의 리전과 AZ 선택 가능
    • 오랫동안 DB를 실행할 계획이면 예약 인스턴스가 좋다
    • Convertible Reserved Instances - 시간이 지나면 인스턴스 타입을 변경 가능
      • 앞서 인스턴스 타입, 리전, Tenancy(인스턴스 격리 유형), OS같이 설정한 부분 변경 가능
      • 할인성은 약간 적다
    • 사용량이 일정한 애플리케이션에 추천, 데이터베이스 등
    • 필요가 없어지면 팔수도 있다
  • Savings Plans( 1년 또는 3년)
    • 장기간 사용하면 할인 70%정도 시간당 10달러 정도
    • 달러 단위로 특정한 사용량을 약정하는 것 → 얼마를 사용할지 미리 아는게 중요하다
    • 사용량이 넘어가면 절약 플랜은 온디맨드 가격으로 청구가 된다
    • 특정한 인스턴스 유형과 특정한 리전으로 고정된다
  • Spot instance
    • 짧은 워크로드를 위함, 엄청 싸지만 언제라도 인스턴스들이 손실될 수 있어 신뢰성이 낮다
    • 할인률이 최대 90%로 제일 크다
    • 최대 가격을 정의하고 그 가격을 넘어가면 인스턴스가 없어질 수 있다
    • 가장 절약적인 옵션이고 고장에 대한 회복력이 강하다면 충분히 고려해볼만하다
    • 배치작업, 데이터 분석, 이미지 처리, 모든 종류의 분산형 워크로드
    • 중요한 작업을 하는 서버나 데이터베이스에는 적절하지 않다**(시험에 이런 부분을 물어본다)**

시험에서는 전용 호스트와 전용 인스턴스의 차이를 물어본다

전용 인스턴스 → 인스턴스에 대해 인스턴스로 설정한 만큼의 자신의 하드웨어를 갖는다

전용 호스트 → 물리적 서버 자체에 대한 접근권을 갖고 하드웨어와 가장 근접하게 가시성을 제공해준다

  • Dedicated Hosts(전용 호스트)
    • 물리적 서버 전체를 예약해서 인스턴스 배치를 제어
    • 법규 준수가 요구되거나 라이선스를 기준으로 청구되는 소프트웨어를 사용하면서 소프트웨어 라이센스가 있는 리전에서 사용할 필요가 있는 경우, 혹은 전용 서버에서 실행하는 엄격한 사내 규정이 있는 경우
      • 물리적 서버에 접근할 필요가 있는 경우
    • 온디맨드로 지불하거나 예약할 수 있다
    • 실제 물리적 서버를 예약하기 때문에 가장 비싼 옵션이다
  • 전용 인스턴스
    • 다른 고객과 하드웨어를 공유하지 않는다
    • 전용 하드웨어에서 실행
    • 같은 계정에서 다른 인스턴스와 함께 하드웨어를 공유, 인스턴스 배치에 대한 통제는 불가능
  • Capacity Reservations
    • 용량 예약을 한다면 원하는 기간 동안 특정한 AZ에 용량을 예약할 수 있다.
    • 필요할 때마다 용량에 접근
    • 기간약정은 없고 언제라도 용량 예약 취소가 가능 따라서 온디맨드 요금이 부과
    • 지역별 예약 인스턴스와 결합하거나 절약 플랜과 결합
    • 특정한 AZ에 있어야하며 단기적이고 중단없는 워크로드에 적합

 

추가적으로 시험에서는..

시험에서는 워크로드에 적합한 게 어떤 타입의 인스턴스인지 물어볼 것

Spot Instance

  • spot 인스턴스는 온디맨드 방식보다 비용이 크게 절감됨
  • "Max Spot Price"는 Amazon EC2 Spot Instance의 입찰 가격을 설정하는 옵션 중 하나
    • 이 가격을 설정하면 현재 Spot Instance의 시장 가격이 설정한 최대 가격보다 낮을 때 인스턴스를 받을 수 있다.
      • 내가 max spot price를 0.07달러로 정의했을 때 인스턴스 비용이 0.05달러라면 인스턴스를 받고 계속해서 사용할 수 있다
    • 현재 스팟 가격이 최고 가격보다 높아지는 경우 두 가지 옵션이 있다
      1. 2분 정도의 유예 시간을 받고 최고가를 다시 올려 인스턴스를 유지 or 인스턴스를 중단했다가 다시 스팟 가격이 낮아지면 인스턴스를 재시작하거나 완전히 종료시키는 방법
      2. Spot Block - 현재 더이상 지원되지 않는 방식이지만 시험엔 나올 수 있다 (2023년일자로 서비스 종료됨)
        1. 스팟 인스턴스를 회수당하지 않는다
        2. 특정 기간동안 인스턴스를 차단 1~6시간까지 문서상으로 가능
  • 배치작업, 데이터분석등 실패해도 복원력이 있는 작업에 사용된다
  • 스팟은 AZ에서 가격의 변동이 생긴다
    • 온디맨드 0.1달러, 스팟 인스턴스 0.04달러
  • 스팟 요청 - 시험에 출제됨
    • 원하는 인스턴스 갯수, 인스턴스 최고 가격, AMI 등 요구되는 사양, 요청의 유효 기간, 요청 유형
    • 요청 유형에는 두 가지
      • 일회성 요청 - 스팟 인스턴스
        • 스팟 요청이 이행되는 즉시 인스턴스 시작됨
        • 이후 바로 인스턴스 요청은 삭제된다
      • 지속적인 요청 - 사후 인스턴스
        • Valid from ~ Valid until까지 유지 됨
        • 중단되더라도 스팟 요청이 다시 전달되어 요청이 검증되고 스팟 인스턴스가 재시작됨
        • 스팟 인스턴스가 중단되더라도 자동적으로 인스턴스를 재시작 시켜준다
    • 스팟 요청 취소하기 위해선 open, active, disabled 상태여야한다
    • 스팟 요청 취소와 기존의 있던 스팟 인스턴스를 종료시키는 것은 다르다
      • 스팟 요청 취소는 인스턴스를 종료시키지 않기 때문에 따로 종료해야함
    • 스팟 인스턴스를 영구 종료하고 다시 시작시키지 않기 위해서는 스팟 요청부터 취소하고 해당 요청과 연결된 스팟 인스턴스를 종료해야함
      • 요청을 먼저 취소해야한다. 그렇지 않으면 다시 인스턴스를 구매하는 요청이 들어가게 된다

 

스팟 플릿(spot fleets)

  • 극강의 비용 절감을 위한 방법
  • 한 세트의 스팟 인스턴스 + 온디맨드 인스턴스를 조합해 사용하는 방식
    • 집합이라는 뜻의 Fleet
  • 정의된 비용 제한 내에서 대상 용량을 맞추려고 한다
  • 사용 가능한 런치풀(launch pools)을 통해서 실행
    • 다양한 인스턴스 유형, OS, AZ을 정의
  • 여러 개의 런치풀과 여러 개의 인스턴스 크기등 여러가지 모든 것을 정의
  • 플릿이 가장 적합하고 좋은 런치풀을 선택해준다
  • 스팟 플릿이 정해진 예산 혹은 원하는 용량에 도달하면 인스턴스 실행을 멈춤
  • 스팟 플릿 내에서 스팟 인스턴스에게 할당해줄 전략을 정의
    • lowestPrice - 시험에 가장 자주 출제되는 전략이다
      • 스팟 플릿이 가장 적은 비용을 가진 풀에서부터 인스턴스를 실행해준다
      • 아주 짧은 워크로드가 있는 경우 적합한 옵션
    • diversified
      • 사용자가 기존에 정의한 모든 풀에 걸쳐 분산된다
      • 긴 워크로드에 적합, 가용성이 뛰어남
      • 한 풀이 중단되도 다른 풀이 있다
    • capacityOptimized
      • 인스턴스의 개수에 따라서 최적 용량으로 실행, 적절한 풀을 찾아줌

 

스팟 플릿을 요약하자면

  1. 여러 가지 런치풀과 인스턴스 유형을 다양하게 정의
  2. 이후 스팟 플릿에 전략을 사용하면 자동적으로 전략과 스팟 플릿 런치풀에 따라 스팟 인스턴스를 요청
  3. By using Launch Pools, you can easily add or remove instance types and launch specifications as your workload changes, and ensure that you are always using the most cost-effective instances.

쉽게 말해 스팟 플릿은 온디맨드 + 스팟 인스턴스이고 다양한 런치풀을 통해 사용자가 원하는 인스턴스 타입과 OS, AZ등 스팟 인스턴스로써 사용자에 맞는 최상의 조합을 찾을 수 있다. 그리고 이러한 런치풀과 스팟 플릿 전략에 따라 사용자가 설정해놓은 Capacity에 맞게 원하는 스팟 인스턴스를 구하여 효율적으로 스팟 인스턴스를 실행시키는 방식이 스팟플릿이다.

즉 스팟 플릿을 사용하면 스팟 인스턴스에 따라 추가적인 비용 절감이 되는데 적합한 스팟 인스턴스 풀을 선택해주고 비용을 최대한 낮출 수 있게 해준다.

마지막으로 차이점을 이해해야 하는데 사용자가 사용하고자 하는 인스턴스의 유형과 가용 영역을 지정해서 사용하는 스팟 인스턴스 요청과 달리 스팟 플릿은 최저가 선택같이 사용자의 요구의 조건에 따라 인스턴스 유형과 가용영역을 선택하도록 한다

ChatGPT 정리

요약하면 스팟 인스턴스는 가용성 측면에서 유연하고 중단을 처리할 수 있는 워크로드에 이상적이며 스팟 플릿은 여러 인스턴스 유형, 가용 영역 및 리전에서 고가용성, 확장성 및 비용 최적화가 필요한 워크로드에 이상적입니다.

 

EC2 launch type (실행시킬 수 있는 모든 방법)

1. 스폿 요청(spot requests)

온디맨드 요금, AZ에 따라 다른 것들을 확인할 수 있다.

다양한 파라미터를 통해 스팟 인스턴스에 대해 여러 옵션들을 설정할 수 있다.

Capacity optimized, lowest price, diversified(여러 개를 미리 정의해야함)

2. Reserved instance

12 months or 36 months / 선결제, 부분선결제 등이 있다

현재는 Savings Plan을 권장하는 중

3. Savings Plans

1년 or 3년 Reserved instance와는 다르게 유연하게 인스턴스를 생성할 수 있다.

4. 전용 호스트

물리적인 서버의 하드웨어까지 접근할 수 있다.

라이선싱 가격에 우대를 해줌 → 라이선스 측면에서 생각

5. Capacity Reservations

이해가 잘 안되서 찾아봤다.

원하는 가용영역에 원하는 인스턴스를 원하는 양만큼 예약하여 사용하는 것이라고 한다. 

https://cloudest.oopy.io/posting/050

복사했습니다!