25년 9월에 출시된 ECS Managed Instance에 대해
안녕하세요 클래스메소드의 이수재입니다.
25년 9월 30일에 ECS Managed Instance 라는 기능이 출시되었습니다.
EC2의 기능을 사용하면서 인프라 관리 책임을 AWS에 맡길 수 있는 기능이라고 합니다.
어떤 기능이고 다른 유형과 어떻게 다른지 간략하게 알아보도록 하겠습니다.
기존의 ECS 환경
ECS를 사용해서 컨테이너 환경을 배포하기 위해서는 컨테이너를 배포하기 위한 노드 그룹이 필요합니다.
노드 그룹은 EC2와 Fargate 유형이 선택가능합니다.
EC2를 사용하면 보다 유연하게 설정할 수 있는 장점이 있고 Fargate를 사용하면 인스턴스의 관리를 AWS에 맡길 수 있기 때문에 사용자는 서비스에만 집중할 수 있다는 장점이 있습니다.
두 기능을 비교하자면 다음과 같습니다.
| 비교 항목 | EC2 시작 유형 | Fargate 시작 유형 |
|---|---|---|
| 개요 | 사용자가 관리하는 EC2 인스턴스 클러스터에서 컨테이너를 실행하는 모델. | 컴퓨팅 인프라(서버)를 신경 쓸 필요 없이 컨테이너를 실행할 수 있는 서버리스 모델. |
| 인프라 관리 | 필요 ・EC2 인스턴스 선택, 시작, 모니터링 ・OS 패치 적용, 보안 업데이트 ・컨테이너 에이전트 업데이트 |
불필요 ・AWS가 인프라 프로비저닝과 관리를 모두 수행. ・사용자는 컨테이너 정의와 실행에만 집중할 수 있음. |
| 과금 모델 | 실행 중인 EC2 인스턴스에 대해 과금. (컨테이너가 실행되지 않아도 요금 발생) |
실행 중인 태스크(컨테이너) 가 사용하는 vCPU와 메모리, 실행 시간에 대해 과금. (태스크가 중지되면 과금도 중지) |
| 비용 최적화 | ・예약 인스턴스(Reserved Instances) ・Savings Plans ・스팟 인스턴스(Spot Instances) |
・Compute Savings Plans ・Fargate Spot (최대 70% 할인) |
| 스케일링 | ・태스크 스케일링(Service Auto Scaling) ・인스턴스 스케일링(Cluster Auto Scaling) 양쪽 모두 고려해야 함. |
・태스크 스케일링(Service Auto Scaling)만 고려. ・인스턴스를 신경 쓸 필요 없이 빠른 스케일링 가능. |
| 제어 및 유연성 | 높음 ・인스턴스 유형(GPU, 고용량 메모리 등)을 자유롭게 선택 가능. ・OS나 커널 파라미터 커스터마이징 가능. ・EBS 볼륨 직접 마운트 등 고급 설정 가능. |
낮음 ・CPU와 메모리 조합은 AWS가 정의한 것 중에서 선택. ・OS나 커널 커스터마이징 불가. ・GPU 지원은 제한적. |
| 네트워크 | awsvpc, bridge, host 등 여러 네트워크 모드 지원. |
awsvpc 모드만 지원.(각 태스크에 전용 ENI가 할당되어 보안상 격리됨) |
| 보안 | 공동 책임 모델 ・사용자가 OS, 미들웨어, 네트워크 설정의 보안을 관리할 책임이 있음. |
AWS가 인프라 관리 ・사용자는 컨테이너 이미지와 애플리케이션 보안에만 집중할 수 있음. ・태스크별로 격리된 환경에서 기본적으로 높은 보안 수준을 제공. |
| 비용 | ・고부하 및 고밀도로 컨테이너를 실행한다면 Fargate보다 코스트 효율이 좋은 경우가 있음 이용률이 낮으면 불필요한 비용 발생이 생김 |
・ 트래픽 변동이 크거나 지속적인 워크 로드(배치 처리 등)에서 코스트 효율이 좋음 항상 고부하 작업이 발생하는 경우에는 EC2보다 많은 비용이 발생할 가능성 있음. |
Managed Instances?
이 새로운 솔루션은 인프라 오프로드를 통한 운영 단순성, Amazon EC2의 유연성과 제어 역량을 결합했습니다. 즉, 고객은 총 소유 비용(TCO)을 줄이고 AWS 모범 사례를 유지하면서 혁신을 주도할 애플리케이션을 구축하는 데 집중할 수 있습니다.
완전히 새로운 시작 유형이 아니라 'EC2 시작 유형'의 한 종류입니다.
하지만 사용자가 OS 선정부터 패치 적용까지 모든 것을 직접 수행하는 '자체 관리형 EC2(Self-managed EC2)'와는 다르게 AWS가 제공하는 ECS 최적화 AMI , Auto Scaling Group , Systems Manager 등의 기능을 조합하여 운영 부담을 줄여주는 모델입니다.
Fargate의 '완전한 서버리스'와 사용자가 모든 것을 관리하는 '자체 관리형 EC2'의 중간에 위치하는, 균형 잡힌 선택지 로 이해하면 쉽습니다.
주요 특징
공식 문서에서 제공하는 내용으로 특징과 모범 사례를 알아보자면 다음과 같습니다.
1. 인스턴스 선택
Amazon ECS 관리형 인스턴스는 인스턴스 유형을 선택하는 두 가지 방법을 제공합니다.[1]
- 특정 인스턴스 유형 선택 : 작업에 사용할 EC2 인스턴스 유형을 명시적으로 지정합니다.
- 단일 인스턴스 유형에 의존하지 않고 여러 패밀리, 크기, 세대를 혼합하여 사용함으로써, 특정 인스턴스가 부족할 경우의 리스크를 분산하고 스팟 인스턴스의 중단 내성을 높입니다.
- 속성 기반 인스턴스 유형 선택 : 애플리케이션에 필요한 속성(예: vCPU, 메모리, 아키텍처)을 지정하면 Amazon ECS 관리형 인스턴스가 적절한 인스턴스 유형을 선택합니다.
- '
c5.large나m5.large'처럼 구체적인 인스턴스 유형을 지정하는 대신, 'vCPU 4개 이상, 메모리 8GB 이상'과 같이 요구사항(속성)으로 지정하는 방식입니다.- 이를 통해 Auto Scaling Group이 해당 요구사항을 충족하는 다양한 인스턴스(특히 가격이 저렴한 스팟 인스턴스)를 자동으로 찾아 시작해주므로, 비용 효율성과 가용성이 크게 향상됩니다.
- '
Amazon ECS Managed Instances는 다음과 같은 여러 메커니즘을 통해 인프라 활용도와 비용을 최적화합니다.[2]
- 멀티태스크 배치 : 기본적으로 Amazon ECS는 여러 개의 작은 작업을 더 큰 인스턴스에 배치하여 활용도를 극대화하고 비용을 절감합니다.
- 활성 워크로드 통합 : Amazon ECS는 컨테이너 인스턴스가 실제로 유휴 상태인 시점을 식별하여 애플리케이션 가용성이나 배포 성능에 영향을 줄 수 있는 조기 종료를 방지합니다. 시스템은 서비스에 설정된 최소 및 최대 작업 수, 시작 전 중지 동작, 그리고 작업 보호 동작을 준수합니다.
- 적정 크기 조정 : 워크로드 요구 사항이 변경되면 Amazon ECS는 현재 요구 사항에 맞게 적절한 크기의 대체 인스턴스를 시작합니다.
2. 운영 관리 간소화[3]
사용자는 OS 계층에 개입할 수 없습니다. 그리고 사용자는 다음 작업도 불가능합니다.
- 인스턴스에 대한 SSH 액세스
- 루트 파일 시스템 변경
- 사용자 지정 AMI 사용
또한 실행된 인스턴스의 OS 보안 상태를 상수로 유지하기 위해 Bottlerocket 기반의 정기적인 패치로 OS가 자동으로 유지됩니다. 따라서 VM 인스턴스가 14일마다 다시 시작됩니다.
자연스럽게 실행 중인 ECS 작업도 정기적으로 교체할 필요가 있습니다.
이런 제한사항이 있기 때문에 완전히 자유로운 인스턴스 설정은 불가능하다고 보여집니다.
3. 보안
Amazon ECS 관리형 인스턴스는 유연성과 보호의 균형을 이루는 포괄적인 보안 모델을 구현합니다.
- AWS 관리형 인프라 : AWS는 관리형 인스턴스의 수명 주기를 제어하고 보안 패치를 처리하여 인적 오류와 변조 가능성을 제거합니다.
- 관리자 액세스 불가 : 보안 모델이 잠겨 있어 관리형 인스턴스에 대한 관리자 액세스가 금지됩니다.
- 멀티태스크 배치 : 기본적으로 Amazon ECS 관리형 인스턴스는 비용과 활용도를 최적화하기 위해 단일 인스턴스에 여러 작업을 배치하므로 Fargate에 비해 워크로드 격리 제약이 완화됩니다.
- 데이터 격리 : AWS는 인스턴스 수명 주기와 작업 배치를 제어하지만 AWS는 관리형 인스턴스에 로그인하거나 고객 데이터에 액세스할 수 없습니다.
또한 공동 책임 모델에 따라, 사용자가 담당하는 범위의 보안을 강화하기 위한 모범 사례가 제시됩니다.
- 최소 권한 원칙: IAM 역할에 필요한 권한만 부여합니다.
- 네트워크 분리: 보안 그룹 및 네트워크 ACL로 통신을 엄격하게 제어합니다.
- 인스턴스 접근 제한: SSH를 통한 직접 접근은 피하고, 감사 및 관리가 용이한 AWS Systems Manager Session Manager 사용이 권장됩니다.
4. 인프라 및 비용 최적화
컴퓨팅 리소스를 낭비 없이 사용하기 위한 접근 방식을 고려해볼 수 있습니다.
- 스팟 인스턴스 적극 활용: 중단을 허용할 수 있는 워크로드에서 스팟 인스턴스를 사용하면 온디맨드 요금에 비해 대폭적인 비용 절감이 가능합니다. '속성 기반 인스턴스 유형 선택'과 조합하면 매우 효과적입니다.
- Savings Plans / 예약 인스턴스: 안정적인 워크로드에 대해서는 이러한 구매 옵션으로 비용을 절감합니다.
- 클러스터 오토 스케일링: 수요에 따라 인스턴스 수를 자동으로 증감시켜 불필요한 유휴 비용을 방지합니다.
모범 사례
인스턴스 선택에 대한 모범 사례[4]
인스턴스 타입을 선전할 때 다음 내용을 기반으로 검토해보는 것을 권장합니다.
- Amazon ECS Managed Instances 기본 용량 공급자 사용
- 대부분의 작업 부하에 대해 속성 기반 선택을 사용하여 유연성을 제공하고 배치 성공률을 개선
- 애플리케이션에 특정 하드웨어 요구 사항이 있는 경우에만 특정 인스턴스 유형을 사용
- 과도한 프로비저닝과 불필요한 비용을 피하기 위해 균형 잡힌 리소스를 선택
- 다양한 작업 부하가 있는 애플리케이션에 대해 인스턴스 유형을 혼합하여 성능과 비용의 균형을 맞추기
마이그레이션 동기
Fargate나 자체 관리형 EC2에서 'Managed Instances'로의 마이그레이션이 검토되는 경우는 주로 다음과 같습니다.
Fargate에서 마이그레이션하는 경우
- 더 세밀한 제어가 필요할 때: OS 커널 파라미터 조정이나 특정 모니터링 에이전트 도입이 필요해진 경우.
- 특수한 하드웨어가 필요할 때: GPU, 추론 칩(Inferentia), Graviton 프로세서 등 Fargate에서 사용할 수 없는 하드웨어를 사용하고 싶은 경우.
- 추가적인 비용 최적화: 워크로드가 항상 높은 부하로 안정적이며, 예약 인스턴스나 스팟 인스턴스를 최대한 활용하여 컴퓨팅 요금을 극한까지 낮추고 싶은 경우.
- 워크 로드의 보안: ECS 작업 수준에서 워크로드를 엄격하게 격리할 필요가 없는 경우 마이그레이션 고려 가능.
자체 관리형 EC2에서 마이그레이션하는 경우
- 운영 부담 감소: 커스텀 AMI 생성, OS 패치 관리, ECS 에이전트 업데이트와 같은 수작업을 없애고 AWS의 관리형 구조에 맡기고 싶은 경우.
- 비용 및 가용성 향상: '속성 기반 인스턴스 유형 선택'이나 스팟 인스턴스 활용 등 AWS의 최신 모범 사례를 도입하고 싶은 경우.
요약
개인적인 의견으로 세 유형을 비교하면 다음과 같다고 생각합니다.
| Fargate | ECS Managed Instances | 자체 관리형 EC2 | |
|---|---|---|---|
| 관리 부담 | 낮음 (불필요) | 중간 | 높음 |
| 유연성 | 낮음 | 높음 | 가장 높음 |
| 비용 | 변동/소규모에 유리 | 안정/대규모에 유리 | 최적화에 따라 다름 |
| 추천 대상 | 편의성 최우선 | 유연성과 운영 부담의 균형 | 완전한 맞춤형 환경 |
이 외에도 이번에 관리형 인스턴스가 출시되면서 공식 문서[5]에서도 클러스터에 관리형 인스턴스를 사용하는 것을 권장하도록 수정되었습니다.
Choosing the right cluster type
...
Amazon ECS Managed Instances (Recommended)
마무리
이 글이 Managed Instance를 사용하려는 분에게 도움이 되었으면 좋겠네요.
사용 방법은 이 글 서두에 첨부한 AWS 코리아의 글을 참고하시는 것을 권장합니다.
또한 일본어 블로그이지만 아래 글도 설명이 잘 되어 있으므로 참고하는 것을 권장합니다.
긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.
문의 사항은 클래스메소드코리아로!
클래스메소드코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.
AWS에 대한 상담 및 클래스메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr
