EC2인스턴스 타입 어떻게 구분해야 할까?

 

 

 

 

 

 

 

EC2 인스턴스 타입, 어떻게 구분해야 할까?

AWS의 인스턴스 이름(예: m5.xlarge)은 [패밀리][세대].[크기] 형식으로 되어 있습니다. 여기서 가장 중요한 것은 패밀리이며,

각 알파벳은 인스턴스의 특화된 목적을 의미합니다.

쉽게 비유하자면, 여러 종류의 '운동선수'를 뽑는 것과 같습니다.

 

서비스의 핵심 요구사항이 무엇인지 파악하고(CPU인가? 메모리인가?), 그에 맞는 패밀리를 선택하는 것이 첫 단계입니다.

 

 

 

Instance family

• 범용
  • 범용 인스턴스는 균형 있는 컴퓨팅, 메모리 및 네트워킹 리소스를 제공하며, 다양한 여러 워크로드에 사용할 수 있습니다. 이러한 인스턴스는 웹 서버, 코드 리포지토리, 중소 규모 데이터베이스와 같은 애플리케이션에 적합합니다.
  • 어떤 걸 써야 할지 잘 모를 때, 일단 M 패밀리로 시작하면 대부분 실패하지않습니다. 웹 서버, 애플리케이션 서버 등 대부분의 일반적인 워크로드에 적합합니다. (Shop, Partner서비스 등)
  • M5 | M5a | M5ad | M5d | M5dn | M5n | M5zn | M6a | M6g | M6gd | M6i | M6id | M6idn | M6in | M7a | M7g | M7gd | M7i | M7i-flex | M8a | M8g | M8gd | M8i | M8i-flex | T3 | T3a | T4g
• 컴퓨팅 최적화
  • 컴퓨팅 최적화 인스턴스는 고성능 프로세서를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합합니다. 컴퓨팅 인스턴스 워크로드의 예로는 배치 프로세싱, 미디어 트랜스코딩, 전용 게임 서버 등이 있습니다.
  • (예: 동영상 인코딩, 대규모 데이터 분석, 트래픽이 매우 높은 API 게이트웨이)
  • C5 | C5a | C5ad | C5d | C5n | C6a | C6g | C6gd | C6gn | C6i | C6id | C6in | C7a | C7g | C7gd | C7gn | C7i | C7i-flex | C8a | C8g | C8gb | C8gd | C8gn | C8i | C8i-flex
• 메모리 최적화
  • 메모리 최적화 인스턴스는 메모리에서 대규모 데이터 세트를 처리하는 워크로드를 위한 빠른 성능을 제공하기 위해 설계되었습니다. 예를 들어, 이러한 인스턴스는 인메모리 데이터베이스, 데이터 분석 및 엔터프라이즈 애플리케이션에 적합합니다.
  • (예: 인메모리 데이터베이스(Redis), 대규모 캐싱, 실시간 데이터 분석
  • R5 | R5a | R5ad | R5b | R5d | R5dn | R5n | R6a | R6g | R6gd | R6i | R6id | R6idn | R6in | R7a | R7g | R7gd | R7i | R7iz | R8a | R8g | R8gb | R8gd | R8gn | R8i | R8i-flex | U-3tb1 | U-6tb1 | U-9tb1 | U-12tb1 | U-18tb1 | U-24tb1 | U7i-6tb | U7i-8tb | U7i-12tb | U7in-16tb | U7in-24tb | U7in-32tb | U7inh-32tb | X2gd | X2idn | X2iedn | X2iezn | X8g | X8aedz | z1d
• 스토리지 최적화
  • 인스턴스는 지연 시간이 짧은 수백만 개의 무작위 초당 I/O 작업 수(IOPS)를 애플리케이션에 지원하도록 최적화되어 있습니다. 스토리지 최적화 인스턴스는 로컬 스토리지에서 매우 큰 데이터 집합에 대해 많은 순차적 읽기 및 쓰기 액세스를 요구하는 워크로드를 위해 설계되었습니다. 예를 들어 처리량이 많은 데이터베이스, 데이터 처리 및 데이터 스트리밍에 적합합니다.
  • 트래픽이 적고 간헐적인 서비스에 사용하면 매우 저렴합니다. (예: 개발/테스트 환경, 내부 어드민 페이지)
  • D3 | D3en | I3en | I4g | I4i | I7i | I7ie | I8g | I8ge | Im4gn | Is4gen
• 가속화된 컴퓨팅
  • 액셀러레이티드 컴퓨팅 인스턴스는 하드웨어 액셀러레이터 또는 보조 프로세서를 사용하여 기능을 보다 효율적으로 수행합니다. 예를 들어, GPU는 부동 소수점 숫자 계산, 그래픽 처리 또는 데이터 패턴 매칭에 유용할 수 있습니다.
  • DL1 | DL2q | F2 | G4ad | G4dn | G5 | G5g | G6 | G6e | G6f | Gr6 | Gr6f | Inf1 | Inf2 | P4d | P4de | P5 | P5e | P5en | P6-B200 | P6-B300 | P6e-GB200 | Trn1 | Trn1n | Trn2 | Trn2u | VT1
• 고성능 컴퓨팅
  • 고성능 컴퓨팅(HPC) 인스턴스는 대규모 HPC 워크로드를 실행하는 데 있어 최고의 가격 대비 성능을 제공합니다. HPC 인스턴스는 복잡한 시뮬레이션, 딥러닝, 시각 효과 렌더링과 같이 고성능 프로세서의 이점을 활용하는 애플리케이션에 이상적입니다.
  • Hpc6a | Hpc6id | Hpc7a | Hpc7g

 

 

---

 

 

'큰 거 한 대' vs '작은 거 여러 대', 무엇이 더 좋은가요?

운영 환경에서는 거의 항상 '작은 거 여러 대'가 정답입니다.
'배달 트럭' 비유를 통해 설명해 드리겠습니다.

 

 

시나리오 1: 큰 트럭 한 대 (c5.4xlarge)

우리 회사에 모든 배송을 처리하는 아주 큰 트럭이 딱 한 대 있다고 상상해봅시다.

• 장점:
  • 관리의 단순함: 운전사 한 명만 관리하면 되니 편합니다.
  • 큰 화물 처리: 아주 거대한 냉장고 같은 화물도 문제없이 실을 수 있습니다.
    (아주 무거운 Batch 작업도 단일 인스턴스 내에서 처리 가능)
• 단점 (치명적):
  • 단일 장애점 (SPOF): 만약 그 트럭이 고장 나거나 타이어가 터지면, 회사의 모든 배송이 중단됩니다.
    서비스 전체가 다운되는 것과 같습니다.
  • 비효율적인 확장: 편지 한 통을 배달하기 위해 거대한 트럭 전체가 움직여야 합니다. (리소스 낭비)
    배송량이 약간 늘어났을 뿐인데, 똑같이 거대한 트럭을 한 대 더 사야 합니다. (비용 급증)

 

시나리오 2: 작은 밴 여러 대 (c5.xlarge x 4대)

이번엔 우리 회사에 보통 크기의 배달용 밴이 4대 있다고 상상해봅시다.

• 장점:
  • 고가용성 (High Availability): 밴 한 대가 고장 나도 나머지 3대가 배송을 계속 이어갑니다. 서비스
    속도가 약간 느려질 수는 있어도, 전체가 멈추지는 않습니다.
  • 탄력적 확장 (Elasticity): 배송량이 늘어나면, 필요한 만큼 밴을 한 대씩 추가하면 됩니다.
    반대로 줄어들면 차고지로 돌려보내면 됩니다. 딱 필요한 만큼만 비용을 지불하게 되어 매우 효율적입니다.
• 단점:
  • 초대형 화물 문제: 밴 한 대에 실을 수 없는 아주 큰 화물은 배송이 불가능합니다.
    (해결책: 우리 회사의 가장 큰 화물에 맞춰 밴의 크기, 즉 c5.xlarge 같은 인스턴스 '사이즈'를 선택하면 됩니다.)

 

결론: 안정성이 무엇보다 중요한 운영 환경에서는 '작은 거 여러 대' 전략을 통해 단일 장애점을 없애고,
고가용성을 확보하는 것이 클라우드 아키텍처의 기본 원칙입니다.

 

 

 

 

---

 

 

 

클러스터 오토스케일링은 똑같은 EC2만 생성하나요?

기본적으로는 그렇게 동작하지만, 우리가 그 규칙을 직접 정해주는 것입니다.

 

1. 우리는 "이런 모양의 EC2 인스턴스를 만들어줘" 라는 시작 템플릿(Launch Template)을 먼저 정의합니다.
   • 이 템플릿 안에 인스턴스 타입(c5.xlarge), AMI(운영체제), 보안 그룹 등 모든 명세가 들어갑니다.
2. 그리고 이 시작 템플릿을 사용하는 오토스케일링 그룹(Auto Scaling Group, ASG)을 만듭니다.
3. 마지막으로, ECS 클러스터의 Capacity Provider가 이 ASG를 바라보게 설정합니다.

 

💡 동작 순서
ECS 클러스터에 자리가 부족하다! → Capacity Provider가 ASG에게 "인스턴스 한 대 추가해!"라고 요청 →
ASG는 자기가 들고 있는 시작 템플릿을 보고, 거기에 명시된 똑같은 모양의 c5.xlarge 인스턴스를 복제하여
클러스터에 추가합니다.

 

 

클러스터 오토스케일링은 우리가 미리 정해놓은 '설계도(템플릿)'에 따라 똑같은 인스턴스를 계속 생성하는 구조가 맞습니다. 그리고 이것이 바로 예측 가능하고 일관된 인프라 환경을 유지하는 비결입니다.

ASG 하나에 여러 인스턴스 타입(예: c5.xlarge, m5.xlarge)을 섞어 등록하여, AWS가 당시 상황에 가장 저렴하고 가용한 인스턴스를 선택하게 만드는 더 유연한 전략도 사용할 수 있습니다.

 

 

 

참고

https://jibinary.tistory.com/207

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/instance-types.html