AWS ECS 클러스터 생성 완벽 가이드

ECS 클러스터를 처음 생성하는 초급 개발자를 위한 완벽 가이드입니다. Fargate와 EC2 시작 유형의 차이부터 클러스터 설정, 용량 공급자, 모니터링까지 실무에 필요한 모든 내용을 담았습니다.

1. ECS란 무엇인가

입사 한 달차인 김개발 씨는 팀장님으로부터 처음으로 중요한 임무를 받았습니다. "우리 서비스를 컨테이너로 배포해야 하는데, AWS ECS를 사용해 보면 어떨까요?" 컨테이너는 들어봤지만 ECS는 처음입니다.

도대체 ECS가 뭘까요?

ECS(Elastic Container Service)는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스입니다. 마치 여러 대의 선박을 효율적으로 관리하는 항만 관리 시스템처럼, ECS는 수많은 Docker 컨테이너를 자동으로 배포하고 관리합니다.

개발자는 복잡한 인프라 관리 없이도 애플리케이션 개발에만 집중할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 ECS 클러스터 정보 조회
const { ECSClient, ListClustersCommand } = require('@aws-sdk/client-ecs');

const client = new ECSClient({ region: 'ap-northeast-2' });

async function listClusters() {
  try {
    // 클러스터 목록 조회
    const command = new ListClustersCommand({});
    const response = await client.send(command);

    console.log('ECS 클러스터 목록:', response.clusterArns);
    return response.clusterArns;
  } catch (error) {
    console.error('클러스터 조회 실패:', error);
  }
}

listClusters();

김개발 씨는 구글에 "AWS ECS"를 검색해봤습니다. 수많은 용어들이 눈앞에 펼쳐집니다.

클러스터, 태스크, 서비스, 컨테이너 인스턴스... 머리가 복잡해졌습니다.

선배 개발자인 박시니어 씨가 옆자리에서 이를 보고 빙그레 웃으며 말을 걸어왔습니다. "ECS가 처음이에요?

걱정 마세요. 저도 처음엔 헷갈렸거든요." 그렇다면 ECS란 정확히 무엇일까요?

쉽게 비유하자면, ECS는 마치 대형 물류 센터의 자동화 시스템과 같습니다. 물류 센터에서는 수많은 상품들이 들어오고 나가며, 이를 효율적으로 분류하고 배송하는 시스템이 필요합니다.

ECS도 마찬가지입니다. 수많은 컨테이너(상품)들을 어디에 배치할지, 얼마나 실행할지, 언제 종료할지를 자동으로 관리해줍니다.

ECS가 없던 시절에는 어땠을까요? 개발자들은 서버마다 직접 접속해서 Docker 명령어를 입력해야 했습니다.

"이 서버에는 컨테이너 5개, 저 서버에는 3개..." 이런 식으로 일일이 관리했습니다. 서버가 2-3대라면 괜찮지만, 수십 대, 수백 대가 되면 어떨까요?

상상만 해도 끔찍합니다. 더 큰 문제는 장애 상황이었습니다.

어느 날 갑자기 서버 한 대가 다운되면, 그 위에서 실행되던 컨테이너들도 모두 멈춥니다. 개발자는 새벽에 전화를 받고 부랴부랴 다른 서버에 컨테이너를 다시 띄워야 했습니다.

자동화가 전혀 되어있지 않았던 것이죠. 바로 이런 문제를 해결하기 위해 ECS가 등장했습니다.

ECS를 사용하면 자동 스케일링이 가능해집니다. 트래픽이 갑자기 증가하면 컨테이너를 자동으로 늘리고, 트래픽이 줄어들면 다시 줄여줍니다.

또한 자동 복구 기능도 제공됩니다. 컨테이너에 문제가 생기면 자동으로 재시작하거나 다른 서버에 새로 띄워줍니다.

무엇보다 간편한 배포라는 큰 이점이 있습니다. 몇 번의 클릭만으로 새로운 버전을 배포할 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 2번째 줄을 보면 AWS SDK에서 필요한 클라이언트와 명령어를 불러옵니다.

이 부분이 ECS와 통신하기 위한 준비 단계입니다. 다음으로 4번째 줄에서는 ECS 클라이언트를 생성하는데, 서울 리전(ap-northeast-2)을 지정했습니다.

9번째 줄에서 실제 클러스터 목록을 조회하는 명령어를 실행하고, 그 결과를 반환합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 서비스를 운영한다고 가정해봅시다. 평소에는 트래픽이 적지만 블랙프라이데이 같은 대규모 세일 기간에는 트래픽이 10배 이상 증가합니다.

ECS를 활용하면 트래픽에 따라 자동으로 컨테이너 개수를 조절할 수 있습니다. 쿠팡, 네이버 같은 대형 서비스들도 이런 패턴을 적극적으로 사용하고 있습니다.

ECS의 핵심 구성 요소를 이해하는 것이 중요합니다. 클러스터는 컨테이너들이 실행되는 논리적인 그룹입니다.

하나의 큰 틀이라고 생각하면 됩니다. 태스크는 실제로 실행되는 컨테이너의 설정을 정의합니다.

어떤 Docker 이미지를 사용할지, 메모리는 얼마나 할당할지 등을 명시합니다. 서비스는 지정된 개수만큼 태스크를 유지하도록 관리합니다.

예를 들어 "이 태스크를 항상 5개 유지해줘"라고 설정할 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 클러스터와 태스크를 혼동하는 것입니다. 클러스터는 단지 논리적인 그룹일 뿐, 실제 컨테이너가 실행되는 것은 태스크입니다.

이를 제대로 이해하지 못하면 "클러스터는 만들었는데 왜 아무것도 실행되지 않지?"라는 의문에 빠질 수 있습니다. 따라서 클러스터 생성 후에는 반드시 태스크 정의와 서비스 생성까지 진행해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, ECS가 컨테이너를 자동으로 관리해주는 시스템이군요!" ECS를 제대로 이해하면 더 안정적이고 확장 가능한 서비스를 만들 수 있습니다. 처음에는 복잡해 보이지만, 하나씩 차근차근 배워나가다 보면 어느새 ECS 전문가가 되어 있을 것입니다.

실전 팁

💡 - 무료 티어 활용: AWS 프리티어로 ECS를 무료로 학습할 수 있습니다 (Fargate 사용 시 제한적)

문서 정독: AWS 공식 문서의 Getting Started 가이드를 반드시 읽어보세요
작게 시작하기: 처음부터 복잡한 구조를 만들지 말고, 간단한 웹 서버 하나로 시작하세요

2. Fargate vs EC2 시작 유형

김개발 씨는 ECS 클러스터를 생성하려고 AWS 콘솔에 접속했습니다. 그런데 이게 웬일입니까?

"시작 유형을 선택하세요"라는 메시지와 함께 Fargate와 EC2 두 가지 옵션이 나타났습니다. 도대체 뭐가 다른 걸까요?

Fargate는 서버 관리 없이 컨테이너만 실행하는 서버리스 방식이고, EC2는 직접 서버를 관리하면서 컨테이너를 실행하는 전통적인 방식입니다. Fargate는 편리하지만 비용이 높고, EC2는 복잡하지만 비용을 절감할 수 있습니다.

프로젝트 특성에 따라 적절한 시작 유형을 선택해야 합니다.

다음 코드를 살펴봅시다.

// Fargate 태스크 정의 예제
{
  "family": "my-app-fargate",
  "networkMode": "awsvpc", // Fargate는 awsvpc 필수
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256", // Fargate는 특정 CPU/메모리 조합만 지원
  "memory": "512",
  "containerDefinitions": [{
    "name": "my-container",
    "image": "nginx:latest",
    "portMappings": [{
      "containerPort": 80,
      "protocol": "tcp"
    }]
  }]
}

김개발 씨는 팀 채팅방에 물어봤습니다. "Fargate랑 EC2 중에 뭘 선택해야 하나요?" 그러자 팀원들의 의견이 분분했습니다.

"Fargate가 편해요!" "아니야, EC2가 비용 면에서 훨씬 낫지!" 박시니어 씨가 회의실로 김개발 씨를 불렀습니다. "둘 다 장단점이 있어요.

상황에 맞게 선택하는 게 중요합니다." Fargate와 EC2의 차이를 쉽게 이해해 봅시다. 마치 택시와 자가용의 차이와 같습니다.

Fargate는 택시처럼 필요할 때만 타고 내리면 됩니다. 차량 관리, 보험, 정비 이런 것들은 전혀 신경 쓸 필요가 없습니다.

반면 EC2는 자가용과 같습니다. 직접 차를 구매하고, 관리하고, 정비해야 합니다.

하지만 장거리를 자주 다닌다면 자가용이 훨씬 경제적입니다. Fargate가 없던 시절에는 어땠을까요?

ECS를 사용하려면 무조건 EC2 인스턴스를 직접 띄워야 했습니다. 인스턴스 크기를 선택하고, 오토스케일링을 설정하고, 보안 패치를 적용하고...

컨테이너 오케스트레이션만으로도 복잡한데, 서버 관리까지 신경 써야 했습니다. 더 큰 문제는 리소스 낭비였습니다.

컨테이너는 작은데 EC2 인스턴스는 크게 띄워야 해서, 많은 자원이 놀고 있었습니다. 또한 트래픽이 갑자기 증가하면 EC2 인스턴스를 먼저 늘려야 했는데, 이 과정이 느렸습니다.

바로 이런 문제를 해결하기 위해 Fargate가 등장했습니다. Fargate를 사용하면 서버 관리가 필요 없습니다.

EC2 인스턴스를 띄울 필요도, 패치를 적용할 필요도 없습니다. AWS가 모든 것을 알아서 관리해줍니다.

또한 정확한 리소스 할당이 가능합니다. 256MB 메모리가 필요하면 정확히 256MB만 사용하고, 그만큼만 비용을 지불합니다.

무엇보다 빠른 스케일링이라는 큰 이점이 있습니다. EC2 인스턴스를 기다릴 필요 없이 바로 컨테이너를 실행할 수 있습니다.

하지만 EC2 시작 유형도 여전히 중요합니다. 비용 최적화가 필요한 경우 EC2가 유리합니다.

24시간 내내 실행되는 서비스라면 Reserved Instance나 Spot Instance를 활용해서 비용을 크게 절감할 수 있습니다. 또한 특수한 요구사항이 있는 경우에도 EC2를 선택합니다.

예를 들어 GPU가 필요하거나, 특정 인스턴스 유형이 필요한 경우입니다. 세밀한 제어가 필요할 때도 EC2가 적합합니다.

인스턴스 레벨에서 로깅이나 모니터링을 설정하고 싶다면 EC2를 사용해야 합니다. 위의 코드를 한 줄씩 살펴보겠습니다.

3번째 줄을 보면 networkMode가 "awsvpc"로 설정되어 있습니다. Fargate는 awsvpc 네트워크 모드만 지원하므로 이는 필수입니다.

4번째 줄에서는 requiresCompatibilities를 통해 이 태스크가 Fargate에서 실행될 것임을 명시합니다. 5-6번째 줄에서 CPU와 메모리를 지정하는데, Fargate는 특정 조합만 지원합니다.

256 CPU에는 512, 1024, 2048 메모리만 사용 가능합니다. 실제 현업에서는 어떻게 선택할까요?

스타트업 A사는 초기에 사용자가 적고 트래픽 변동이 심합니다. 이런 경우 Fargate가 적합합니다.

사용한 만큼만 비용을 내고, 갑작스러운 트래픽 증가에도 빠르게 대응할 수 있습니다. 반면 B사는 안정적인 트래픽을 가진 대규모 서비스를 운영합니다.

수백 개의 컨테이너가 24시간 돌아갑니다. 이런 경우 EC2 Reserved Instance를 사용하면 Fargate 대비 50% 이상 비용을 절감할 수 있습니다.

실무에서 자주 사용하는 패턴은 하이브리드 방식입니다. 기본적인 워크로드는 EC2로 처리하고, 갑작스러운 트래픽 증가 시에는 Fargate로 처리합니다.

이를 위해 용량 공급자(Capacity Provider)를 사용합니다. 평소에는 EC2 인스턴스에서 컨테이너를 실행하다가, 리소스가 부족하면 자동으로 Fargate를 사용하도록 설정할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 무조건 Fargate를 선택하는 것입니다.

"관리가 편하니까 Fargate로 하자!" 하지만 24시간 돌아가는 서비스를 Fargate로 운영하면 비용이 예상보다 훨씬 많이 나올 수 있습니다. 따라서 트래픽 패턴과 예상 비용을 먼저 계산해보고 선택해야 합니다.

또 다른 실수는 Fargate의 제약사항을 모르는 것입니다. Fargate는 특정 CPU/메모리 조합만 지원하고, 최대 30GB까지만 스토리지를 사용할 수 있습니다.

대용량 데이터 처리가 필요하다면 EC2를 선택해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "우리 서비스는 초기 단계니까 일단 Fargate로 시작하는 게 좋겠네요!" 선택의 기준을 정리하면 이렇습니다.

빠른 시작과 간편한 관리가 중요하다면 Fargate, 비용 최적화와 세밀한 제어가 필요하다면 EC2를 선택하세요. 여러분의 프로젝트에 맞는 선택을 하시기 바랍니다.

실전 팁

💡 - 비용 계산기 활용: AWS Pricing Calculator로 Fargate와 EC2 비용을 미리 비교해보세요

작게 시작: 처음에는 Fargate로 시작해서 빠르게 검증하고, 나중에 필요하면 EC2로 전환하세요
하이브리드 고려: 용량 공급자를 활용해 두 방식의 장점을 모두 가져갈 수 있습니다

3. 클러스터 생성하기

드디어 김개발 씨가 본격적으로 ECS 클러스터를 생성할 시간입니다. AWS 콘솔을 열고 ECS 메뉴로 들어갔습니다.

"클러스터 생성" 버튼을 눌렀더니 여러 설정 옵션이 나타납니다. 어디서부터 시작해야 할까요?

ECS 클러스터 생성은 AWS 콘솔이나 AWS CLI, Terraform 등을 통해 할 수 있습니다. 클러스터 이름을 지정하고, 네트워킹을 설정하며, 필요한 경우 CloudWatch Container Insights를 활성화합니다.

기본 설정만으로도 간단히 생성할 수 있지만, 프로덕션 환경에서는 세부 설정을 신중히 검토해야 합니다.

다음 코드를 살펴봅시다.

// AWS SDK로 ECS 클러스터 생성
const { ECSClient, CreateClusterCommand } = require('@aws-sdk/client-ecs');

const client = new ECSClient({ region: 'ap-northeast-2' });

async function createCluster() {
  try {
    const command = new CreateClusterCommand({
      clusterName: 'my-production-cluster',
      // Container Insights 활성화 (모니터링)
      settings: [{
        name: 'containerInsights',
        value: 'enabled'
      }],
      // 클러스터 태그 설정
      tags: [
        { key: 'Environment', value: 'production' },
        { key: 'Team', value: 'backend' }
      ]
    });

    const response = await client.send(command);
    console.log('클러스터 생성 완료:', response.cluster);
    return response.cluster;
  } catch (error) {
    console.error('클러스터 생성 실패:', error);
  }
}

createCluster();

김개발 씨는 화면을 유심히 살펴봅니다. 생각보다 입력할 항목이 많지 않습니다.

"이게 전부인가?" 싶을 정도로 간단해 보입니다. 박시니어 씨가 말합니다.

"ECS 클러스터 자체는 논리적인 그룹일 뿐이라서, 생성 자체는 정말 간단해요. 중요한 건 이후에 어떤 태스크와 서비스를 띄울지입니다." 클러스터 생성 과정을 단계별로 살펴봅시다.

마치 아파트 단지를 만드는 것과 비슷합니다. 먼저 단지 이름을 정하고, 기본 인프라를 준비합니다.

실제 건물(컨테이너)은 나중에 짓습니다. ECS 클러스터도 마찬가지입니다.

일단 틀을 만들고, 그 안에 무엇을 실행할지는 나중에 결정합니다. 클러스터 생성이 복잡하지 않은 이유가 있습니다.

전통적인 서버 환경에서는 서버를 준비하는 것 자체가 큰 작업이었습니다. 하드웨어를 구매하고, 랙에 장착하고, 네트워크를 연결하고, OS를 설치하는 등 수많은 단계를 거쳐야 했습니다.

심지어 이 모든 과정이 수일에서 수주가 걸렸습니다. 클라우드 시대에는 이런 물리적 제약이 사라졌습니다.

하지만 여전히 EC2 인스턴스를 띄우고, 설정하고, 관리해야 했습니다. ECS 클러스터는 이런 복잡함을 한 단계 더 추상화했습니다.

바로 이런 배경에서 ECS 클러스터의 간단함이 나옵니다. 클러스터를 생성하면 논리적인 네임스페이스가 만들어집니다.

이 안에 여러 서비스와 태스크를 배치할 수 있습니다. 또한 리소스 격리가 가능해집니다.

개발 환경 클러스터, 스테이징 클러스터, 프로덕션 클러스터를 분리해서 관리할 수 있습니다. 무엇보다 통합 모니터링이라는 큰 이점이 있습니다.

CloudWatch Container Insights를 활성화하면 클러스터 전체의 메트릭을 한눈에 볼 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

8번째 줄에서 CreateClusterCommand를 생성합니다. 이 명령어가 실제 클러스터를 만드는 핵심입니다.

9번째 줄의 clusterName은 필수 항목이며, 리전 내에서 고유해야 합니다. 11-13번째 줄에서는 Container Insights를 활성화합니다.

이를 통해 CPU, 메모리, 네트워크 사용량 등을 자동으로 수집합니다. 15-18번째 줄의 태그는 선택사항이지만, 실무에서는 반드시 설정하는 것이 좋습니다.

나중에 비용 추적이나 리소스 관리에 큰 도움이 됩니다. 실제 현업에서는 어떻게 클러스터를 구성할까요?

대부분의 회사는 환경별로 클러스터를 분리합니다. dev-cluster, staging-cluster, production-cluster 이런 식입니다.

이렇게 하면 개발 환경의 실수가 프로덕션에 영향을 주지 않습니다. 또한 팀별로 클러스터를 나누기도 합니다.

backend-cluster, frontend-cluster, data-cluster 등으로 관리하면 책임 소재가 명확해집니다. 네이버나 카카오 같은 대규모 서비스는 어떻게 할까요?

하나의 거대한 클러스터보다는 여러 개의 작은 클러스터로 나눕니다. 서비스별로, 또는 기능별로 클러스터를 분리합니다.

이를 마이크로서비스 아키텍처라고 부릅니다. 각 팀이 독립적으로 배포하고 관리할 수 있어서 개발 속도가 빨라집니다.

AWS CLI로도 클러스터를 생성할 수 있습니다. 콘솔보다 CLI가 더 편한 경우가 많습니다.

특히 여러 개의 클러스터를 생성하거나, 자동화 스크립트를 작성할 때 유용합니다. Terraform이나 CloudFormation 같은 Infrastructure as Code 도구를 사용하면 더욱 체계적으로 관리할 수 있습니다.

모든 설정이 코드로 관리되므로, 버전 관리도 되고, 재현 가능합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 클러스터 이름을 대충 짓는 것입니다. "test", "cluster1", "my-cluster" 같은 이름은 나중에 혼란을 야기합니다.

명확한 네이밍 컨벤션을 정하세요. 예를 들어 "{환경}-{팀}-{용도}-cluster" 형식으로 통일하는 것이 좋습니다.

또 다른 실수는 Container Insights를 처음부터 활성화하지 않는 것입니다. 나중에 활성화할 수도 있지만, 그동안의 데이터는 볼 수 없습니다.

처음부터 활성화해두면 문제 발생 시 과거 데이터를 분석할 수 있습니다. 물론 약간의 추가 비용이 발생하지만, 그만한 가치가 있습니다.

클러스터를 삭제할 때도 주의가 필요합니다. 클러스터 안에 실행 중인 서비스나 태스크가 있으면 삭제되지 않습니다.

먼저 모든 서비스를 삭제하고, 실행 중인 태스크를 중지한 후에 클러스터를 삭제해야 합니다. 급하게 삭제하려다가 리소스가 남아서 계속 비용이 청구되는 경우가 종종 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 도움을 받으며 김개발 씨는 첫 클러스터를 성공적으로 생성했습니다.

"생각보다 간단하네요!" ECS 클러스터 생성은 시작일 뿐입니다. 이제 이 클러스터 안에 실제 애플리케이션을 배포해야 합니다.

하지만 첫 걸음을 잘 떼었습니다. 여러분도 오늘 배운 내용을 토대로 첫 클러스터를 만들어 보세요.

실전 팁

💡 - 네이밍 컨벤션 정하기: 클러스터 이름은 일관된 규칙을 따르세요 (예: prod-backend-api-cluster)

태그 필수: 환경, 팀, 용도 등을 태그로 명시하면 나중에 관리가 훨씬 쉽습니다
IaC 도구 활용: Terraform이나 CDK로 클러스터를 관리하면 재현성과 버전 관리가 가능합니다

4. 클러스터 설정 옵션

클러스터를 생성한 김개발 씨는 이제 세부 설정을 살펴볼 차례입니다. "클러스터 생성은 했는데, 이제 뭘 설정해야 하지?" 박시니어 씨가 화면을 가리키며 말합니다.

"Container Insights, 기본 용량 공급자 전략, 태그... 이런 것들을 제대로 설정해야 나중에 편합니다."

ECS 클러스터의 주요 설정 옵션으로는 Container Insights 모니터링, 기본 용량 공급자 전략, 태그, 서비스 디스커버리 네임스페이스 등이 있습니다. 이러한 설정들은 클러스터의 가시성, 리소스 관리, 비용 추적에 큰 영향을 미칩니다.

초기 설정을 제대로 하면 운영이 훨씬 수월해집니다.

다음 코드를 살펴봅시다.

// 클러스터 상세 설정 조회
const { ECSClient, DescribeClusterCommand, UpdateClusterSettingsCommand } = require('@aws-sdk/client-ecs');

const client = new ECSClient({ region: 'ap-northeast-2' });

async function updateClusterSettings(clusterName) {
  try {
    // 현재 설정 조회
    const describeCmd = new DescribeClusterCommand({
      clusters: [clusterName],
      include: ['SETTINGS', 'STATISTICS']
    });
    const current = await client.send(describeCmd);
    console.log('현재 설정:', current.clusters[0].settings);

    // Container Insights 활성화
    const updateCmd = new UpdateClusterSettingsCommand({
      cluster: clusterName,
      settings: [{
        name: 'containerInsights',
        value: 'enabled'
      }]
    });

    const response = await client.send(updateCmd);
    console.log('설정 업데이트 완료');
    return response;
  } catch (error) {
    console.error('설정 업데이트 실패:', error);
  }
}

updateClusterSettings('my-production-cluster');

김개발 씨는 클러스터 상세 페이지를 열어봤습니다. 수많은 탭과 메뉴가 눈에 들어옵니다.

"뭐가 이렇게 많아?" 처음 보는 용어들이 가득합니다. 박시니어 씨가 커피를 한 잔 따라주며 설명을 시작합니다.

"하나씩 천천히 알아가면 돼요. 일단 가장 중요한 것들만 먼저 설정합시다." 클러스터 설정을 이해하기 위한 좋은 비유가 있습니다.

마치 새 스마트폰을 샀을 때와 같습니다. 기본 설정만으로도 사용할 수 있지만, 알림, 배터리 절약 모드, 백업 등을 제대로 설정하면 훨씬 편리합니다.

ECS 클러스터도 마찬가지입니다. 기본 설정으로도 작동하지만, 세부 설정을 잘하면 운영이 훨씬 수월해집니다.

가장 먼저 살펴볼 설정은 Container Insights입니다. 이것은 ECS 클러스터의 모니터링 도구입니다.

CPU 사용률, 메모리 사용률, 네트워크 트래픽, 실행 중인 태스크 수 등 중요한 메트릭을 자동으로 수집합니다. CloudWatch와 연동되어 대시보드로 한눈에 볼 수 있습니다.

문제가 생겼을 때 "언제부터 CPU가 올라갔지?" 같은 질문에 바로 답할 수 있습니다. Container Insights가 없던 시절에는 어땠을까요?

개발자들은 직접 모니터링 도구를 설치하고 설정해야 했습니다. Prometheus, Grafana 같은 오픈소스 도구를 사용하거나, 자체 모니터링 시스템을 구축했습니다.

이는 많은 시간과 노력이 필요했습니다. 더 큰 문제는 일관성이 없었다는 점입니다.

팀마다 다른 도구를 사용해서 메트릭을 비교하기 어려웠습니다. Container Insights를 활성화하면 이런 고민이 사라집니다.

AWS가 표준화된 메트릭을 자동으로 수집해줍니다. 설정도 간단합니다.

클러스터 생성 시 체크박스 하나만 선택하면 됩니다. 물론 약간의 추가 비용이 발생하지만, 운영 편의성을 생각하면 충분히 가치가 있습니다.

다음으로 중요한 설정은 기본 용량 공급자 전략입니다. 이것은 태스크를 어디에 배치할지 결정하는 정책입니다.

Fargate를 사용할지, EC2 인스턴스를 사용할지, 아니면 둘을 섞어서 사용할지를 정의합니다. 예를 들어 "평소에는 EC2를 사용하다가, 리소스가 부족하면 Fargate로 넘어가"라고 설정할 수 있습니다.

이를 통해 비용과 유연성의 균형을 맞출 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

9-12번째 줄에서 DescribeClusterCommand를 사용해 현재 클러스터의 설정을 조회합니다. include 파라미터에 'SETTINGS'와 'STATISTICS'를 지정하면 상세 정보를 가져올 수 있습니다.

17-22번째 줄에서는 UpdateClusterSettingsCommand로 Container Insights를 활성화합니다. 이미 생성된 클러스터의 설정도 언제든 변경할 수 있습니다.

태그 설정도 매우 중요합니다. 태그는 단순한 라벨이 아닙니다.

AWS Cost Explorer를 통해 태그별로 비용을 추적할 수 있습니다. "이번 달 프로덕션 환경에 얼마나 썼지?" 같은 질문에 바로 답할 수 있습니다.

또한 IAM 정책에서 태그를 기반으로 권한을 제어할 수도 있습니다. "Environment=production" 태그가 있는 리소스는 시니어 개발자만 수정할 수 있도록 설정하는 식입니다.

실무에서는 보통 이런 태그를 사용합니다. Environment 태그로 dev, staging, production을 구분합니다.

Team 태그로 backend, frontend, devops 등 담당 팀을 명시합니다. CostCenter 태그로 비용 부서를 지정하면 회계팀이 좋아합니다.

Project 태그로 어떤 프로젝트에 속하는지 표시합니다. 서비스 디스커버리 네임스페이스는 고급 기능입니다.

마이크로서비스 아키텍처에서는 서비스 간 통신이 중요합니다. A 서비스가 B 서비스를 호출하려면 B 서비스의 주소를 알아야 합니다.

하지만 컨테이너는 동적으로 생성되고 삭제되므로 IP 주소가 계속 바뀝니다. 서비스 디스커버리를 설정하면 "backend.local" 같은 이름으로 접근할 수 있습니다.

내부적으로 AWS Cloud Map이 자동으로 주소를 찾아줍니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 모든 설정을 한꺼번에 바꾸려는 것입니다. Container Insights, 용량 공급자, 서비스 디스커버리를 동시에 설정하다가 혼란에 빠집니다.

하나씩 차근차근 설정하고 테스트하는 것이 좋습니다. 먼저 Container Insights만 활성화해서 모니터링이 제대로 되는지 확인하세요.

그다음 용량 공급자를 설정하고, 필요하면 서비스 디스커버리를 추가하세요. 또 다른 실수는 설정을 문서화하지 않는 것입니다.

6개월 후에 "이 클러스터는 왜 이렇게 설정했지?" 하고 헷갈릴 수 있습니다. 각 설정의 의도를 README 파일이나 Wiki에 기록해두세요.

특히 Terraform이나 CloudFormation을 사용한다면 코드에 주석으로 남기는 것이 좋습니다. Container Insights의 비용도 고려해야 합니다.

수집되는 메트릭과 로그에 따라 비용이 발생합니다. 소규모 클러스터라면 월 몇 달러 수준이지만, 대규모 클러스터는 수백 달러가 될 수 있습니다.

필요한 메트릭만 선별적으로 수집하도록 설정하면 비용을 절감할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 체크리스트를 작성했습니다. "Container Insights 활성화, 태그 설정, 용량 공급자는 나중에..." 하나씩 차근차근 진행하기로 했습니다.

클러스터 설정은 한 번에 완벽할 필요가 없습니다. 서비스가 성장하면서 필요에 따라 추가하고 조정하면 됩니다.

중요한 것은 기본적인 모니터링과 태그만 제대로 설정해두는 것입니다.

실전 팁

💡 - Container Insights 먼저: 가장 먼저 활성화해서 기준선 데이터를 쌓으세요

태그 표준 정하기: 팀 전체가 동일한 태그 규칙을 따르도록 문서화하세요
점진적 설정: 모든 기능을 한꺼번에 켜지 말고 필요한 것부터 하나씩 활성화하세요

5. 용량 공급자

김개발 씨는 클러스터를 운영하면서 고민에 빠졌습니다. "평소에는 EC2로 비용을 절약하고, 트래픽이 급증하면 Fargate로 빠르게 확장하고 싶은데 가능할까?" 박시니어 씨가 웃으며 말합니다.

"용량 공급자(Capacity Provider)를 사용하면 됩니다."

용량 공급자는 ECS 태스크를 실행할 인프라를 관리하는 컴포넌트입니다. Fargate, Fargate Spot, Auto Scaling Group과 연동된 EC2 등을 용량 공급자로 설정할 수 있습니다.

여러 공급자를 조합하고 가중치와 기본 값을 설정해서 비용과 성능의 균형을 맞출 수 있습니다.

다음 코드를 살펴봅시다.

// 용량 공급자 전략 설정
const { ECSClient, PutClusterCapacityProvidersCommand } = require('@aws-sdk/client-ecs');

const client = new ECSClient({ region: 'ap-northeast-2' });

async function configureCapacityProviders(clusterName) {
  try {
    const command = new PutClusterCapacityProvidersCommand({
      cluster: clusterName,
      // 사용할 용량 공급자 목록
      capacityProviders: ['FARGATE', 'FARGATE_SPOT'],
      // 기본 전략: 70% Fargate, 30% Fargate Spot
      defaultCapacityProviderStrategy: [
        {
          capacityProvider: 'FARGATE',
          weight: 70,
          base: 2  // 최소 2개는 항상 Fargate 사용
        },
        {
          capacityProvider: 'FARGATE_SPOT',
          weight: 30,
          base: 0  // Spot은 추가 태스크만
        }
      ]
    });

    const response = await client.send(command);
    console.log('용량 공급자 설정 완료:', response);
    return response;
  } catch (error) {
    console.error('설정 실패:', error);
  }
}

configureCapacityProviders('my-production-cluster');

김개발 씨는 지난 한 달간의 비용 리포트를 보고 놀랐습니다. Fargate 비용이 예상보다 훨씬 높게 나왔습니다.

"이대로는 안 되겠는데..." 하지만 EC2로 전환하면 관리가 복잡해질 것 같습니다. 박시니어 씨가 해결책을 제시합니다.

"두 가지 장점을 모두 가져갈 수 있어요. 용량 공급자를 제대로 활용하면 됩니다." 용량 공급자를 이해하기 위한 좋은 비유가 있습니다.

마치 택시와 버스를 적절히 활용하는 것과 같습니다. 평소에는 저렴한 버스(EC2)를 주로 이용하고, 급할 때는 택시(Fargate)를 타는 것입니다.

심지어 할인 택시(Fargate Spot)도 활용할 수 있습니다. 용량 공급자는 이런 전략을 자동화해주는 교통 관리 시스템입니다.

용량 공급자가 등장하기 전에는 어땠을까요? 개발자들은 수동으로 태스크를 배치해야 했습니다.

"이 서비스는 Fargate로, 저 서비스는 EC2로" 이런 식으로 일일이 지정했습니다. 트래픽이 증가하면 직접 개입해서 Fargate 태스크를 늘려야 했습니다.

자동화가 안 되니 항상 모니터링을 해야 했고, 대응이 느렸습니다. 더 큰 문제는 리소스 낭비였습니다.

안전을 위해 여유 있게 EC2 인스턴스를 띄워두면 평소에 리소스가 남았습니다. 반대로 딱 맞게 띄우면 트래픽 급증 시 대응이 늦었습니다.

최적의 균형점을 찾기가 정말 어려웠습니다. 바로 이런 문제를 해결하기 위해 용량 공급자가 등장했습니다.

용량 공급자를 설정하면 자동 리소스 선택이 가능해집니다. 설정한 전략에 따라 ECS가 알아서 적절한 인프라를 선택합니다.

또한 유연한 확장이 가능합니다. EC2 용량이 부족하면 자동으로 Fargate로 넘어갑니다.

무엇보다 비용 최적화라는 큰 이점이 있습니다. 저렴한 Spot 인스턴스를 적극 활용하면서도 안정성을 유지할 수 있습니다.

주요 용량 공급자 유형을 살펴봅시다. FARGATE는 가장 간편한 옵션입니다.

서버 관리 없이 바로 실행되며, 안정적입니다. FARGATE_SPOT은 Fargate의 저렴한 버전입니다.

최대 70% 할인되지만, 언제든 중단될 수 있습니다. 중요하지 않은 배치 작업에 적합합니다.

EC2 Auto Scaling Group은 직접 관리하는 EC2 인스턴스 그룹입니다. 가장 저렴하지만 설정이 복잡합니다.

위의 코드를 한 줄씩 살펴보겠습니다. 11번째 줄에서 사용할 용량 공급자 목록을 지정합니다.

Fargate와 Fargate Spot 두 가지를 사용하겠다는 의미입니다. 13-24번째 줄이 핵심입니다.

defaultCapacityProviderStrategy에서 각 공급자의 **가중치(weight)**와 **기본 값(base)**을 설정합니다. base가 2라는 것은 최소 2개의 태스크는 항상 Fargate로 실행한다는 뜻입니다.

나머지는 가중치 비율(70:30)로 분배됩니다. 실무에서 많이 사용하는 전략을 소개합니다.

안정성 우선 전략: 중요한 프로덕션 서비스에서는 Fargate 80%, Fargate Spot 20% 정도로 설정합니다. base를 높게 잡아서 최소한의 안정적인 용량을 확보합니다.

Spot은 추가 트래픽 처리용으로만 사용합니다. 비용 최적화 전략: 개발이나 테스트 환경에서는 Fargate Spot 70%, Fargate 30%로 거꾸로 설정합니다.

가끔 중단되어도 크게 문제가 없으므로 비용을 크게 절감할 수 있습니다. 하이브리드 전략: EC2 Auto Scaling Group을 base로 사용하고, 확장 시에만 Fargate를 사용합니다.

평소 트래픽은 저렴한 EC2로 처리하고, 급증 시에만 Fargate로 빠르게 확장합니다. Fargate Spot 사용 시 주의사항이 있습니다.

Spot 인스턴스는 언제든 2분 전 통보 후 중단될 수 있습니다. 따라서 상태를 저장하지 않는(stateless) 애플리케이션에만 사용해야 합니다.

또한 재시도 로직을 구현해야 합니다. 작업 중간에 중단되면 자동으로 다시 시작되도록 설계하세요.

용량 공급자 전략은 서비스별로 다르게 설정할 수 있습니다. 클러스터 레벨에서 기본 전략을 정의하고, 각 서비스에서 이를 오버라이드할 수 있습니다.

예를 들어 중요한 API 서비스는 Fargate 100%로 설정하고, 로그 처리 서비스는 Fargate Spot 100%로 설정하는 식입니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 Fargate Spot을 과도하게 사용하는 것입니다. "저렴하니까 전부 Spot으로!" 하지만 트래픽이 많을 때 Spot이 대량으로 중단되면 서비스 장애로 이어질 수 있습니다.

항상 안정적인 용량을 base로 확보하고, Spot은 추가 용량으로만 사용하세요. 또 다른 실수는 가중치를 너무 복잡하게 설정하는 것입니다.

"Fargate 45%, Fargate Spot 35%, EC2 20%..." 이렇게 세밀하게 나누면 오히려 예측하기 어렵습니다. 간단하게 2-3개 정도로 나누는 것이 관리하기 좋습니다.

모니터링도 중요합니다. CloudWatch에서 어떤 용량 공급자가 실제로 사용되는지 확인하세요.

설정한 전략대로 작동하는지, Spot 중단율은 얼마나 되는지 주기적으로 점검해야 합니다. 필요하면 전략을 조정하세요.

다시 김개발 씨의 이야기로 돌아가 봅시다. 용량 공급자를 설정한 김개발 씨는 한 달 후 비용 리포트를 확인했습니다.

"와, 비용이 30% 정도 줄었네요!" 안정성은 유지하면서 비용을 절감하는 데 성공했습니다. 용량 공급자는 ECS의 강력한 기능 중 하나입니다.

처음에는 복잡해 보이지만, 제대로 활용하면 비용과 성능 모두를 잡을 수 있습니다. 여러분의 서비스 특성에 맞는 전략을 찾아보세요.

실전 팁

💡 - 작게 시작: 처음에는 Fargate 100%로 시작해서 안정화한 후, 점진적으로 Spot을 추가하세요

모니터링 필수: Spot 중단율과 비용 절감 효과를 주기적으로 확인하세요
상태 없는 설계: Spot을 사용하려면 애플리케이션이 언제든 재시작될 수 있도록 설계되어야 합니다

6. 클러스터 모니터링

클러스터를 프로덕션에 배포한 김개발 씨는 새로운 고민에 빠졌습니다. "서비스가 잘 돌아가는 건지 어떻게 알 수 있지?" 새벽 3시에 문제가 생기면 어떻게 알 수 있을까요?

박시니어 씨가 말합니다. "모니터링과 알람을 제대로 설정해야 합니다."

ECS 클러스터 모니터링은 CloudWatch Container Insights, CloudWatch Logs, CloudWatch Alarms를 통해 이루어집니다. CPU, 메모리, 네트워크 사용률 같은 메트릭을 실시간으로 추적하고, 임계값을 초과하면 자동으로 알림을 받을 수 있습니다.

제대로 된 모니터링은 문제를 조기에 발견하고 대응하는 핵심입니다.

다음 코드를 살펴봅시다.

// CloudWatch 알람 생성 - CPU 사용률 모니터링
const { CloudWatchClient, PutMetricAlarmCommand } = require('@aws-sdk/client-cloudwatch');

const client = new CloudWatchClient({ region: 'ap-northeast-2' });

async function createCpuAlarm(clusterName, serviceName) {
  try {
    const command = new PutMetricAlarmCommand({
      AlarmName: `${serviceName}-high-cpu`,
      AlarmDescription: 'CPU 사용률이 80%를 초과하면 알림',
      MetricName: 'CPUUtilization',
      Namespace: 'AWS/ECS',
      Statistic: 'Average',
      Period: 300, // 5분
      EvaluationPeriods: 2, // 2번 연속 초과 시
      Threshold: 80.0, // 80% 임계값
      ComparisonOperator: 'GreaterThanThreshold',
      Dimensions: [
        { Name: 'ClusterName', Value: clusterName },
        { Name: 'ServiceName', Value: serviceName }
      ],
      // SNS로 알림 전송
      AlarmActions: ['arn:aws:sns:ap-northeast-2:123456789:alerts']
    });

    const response = await client.send(command);
    console.log('알람 생성 완료');
    return response;
  } catch (error) {
    console.error('알람 생성 실패:', error);
  }
}

createCpuAlarm('my-production-cluster', 'api-service');

김개발 씨는 지난주 장애 상황을 떠올렸습니다. 오후 2시쯤 갑자기 서비스가 느려졌고, 사용자들의 불만이 쏟아졌습니다.

한 시간이 지나서야 문제를 발견했습니다. CPU 사용률이 100%에 도달해 있었던 것입니다.

박시니어 씨가 고개를 끄덕입니다. "모니터링이 없으면 사후 대응만 가능해요.

제대로 된 모니터링이 있으면 문제가 커지기 전에 미리 알 수 있습니다." 클러스터 모니터링을 이해하기 위한 좋은 비유가 있습니다. 마치 자동차의 계기판과 같습니다.

속도계, 연료 게이지, 엔진 온도 등을 실시간으로 확인할 수 있습니다. 연료가 부족하면 경고등이 켜지고, 엔진 과열이 감지되면 알림이 울립니다.

ECS 모니터링도 마찬가지입니다. 클러스터의 상태를 실시간으로 보여주고, 문제가 생기면 즉시 알려줍니다.

모니터링이 제대로 되지 않던 시절에는 어땠을까요? 개발자들은 로그 파일을 직접 열어서 확인해야 했습니다.

"에러가 있나?" "CPU는 괜찮나?" 하루에도 수십 번씩 서버에 접속해서 확인했습니다. 주말이나 새벽에 문제가 생겨도 모를 수 있었습니다.

사용자들이 먼저 문제를 제보하는 경우가 많았습니다. 더 큰 문제는 원인 분석이 어려웠다는 점입니다.

문제가 발생한 후에는 이미 늦었습니다. "언제부터 문제가 시작됐지?" "무엇이 원인이었지?" 과거 데이터가 없으니 추측만 할 뿐이었습니다.

바로 이런 문제를 해결하기 위해 CloudWatch Container Insights가 등장했습니다. Container Insights를 활성화하면 자동 메트릭 수집이 시작됩니다.

CPU, 메모리, 네트워크, 디스크 사용률이 자동으로 기록됩니다. 태스크별, 서비스별, 클러스터별로 세분화된 데이터를 볼 수 있습니다.

또한 실시간 대시보드가 제공됩니다. 웹 콘솔에서 그래프로 한눈에 현황을 파악할 수 있습니다.

무엇보다 과거 데이터 보관이라는 큰 이점이 있습니다. 문제가 생기면 과거로 돌아가서 언제부터 시작됐는지 확인할 수 있습니다.

핵심 모니터링 메트릭을 살펴봅시다. CPU 사용률은 가장 기본적인 지표입니다.

80%를 넘어가면 성능 저하가 시작되고, 100%에 도달하면 응답이 느려집니다. 메모리 사용률도 중요합니다.

메모리가 부족하면 프로세스가 강제 종료될 수 있습니다. 네트워크 처리량을 보면 트래픽 패턴을 이해할 수 있습니다.

갑작스러운 증가는 공격 징후일 수도 있습니다. 실행 중인 태스크 수를 추적하면 오토스케일링이 제대로 작동하는지 확인할 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 9-10번째 줄에서 알람의 이름과 설명을 지정합니다.

나중에 알림을 받았을 때 무엇에 대한 알림인지 바로 알 수 있도록 명확하게 작성하세요. 11-13번째 줄에서 모니터링할 메트릭을 지정합니다.

CPUUtilization을 평균값으로 측정합니다. 14-16번째 줄이 핵심입니다.

5분 동안의 평균값을 측정하고, 80%를 2번 연속 초과하면 알람을 발생시킵니다. 한 번만 초과했다가 내려가는 일시적 스파이크는 무시합니다.

실무에서 꼭 설정해야 할 알람들을 소개합니다. CPU 고사용률 알람: 80% 이상이 지속되면 스케일 아웃을 고려해야 합니다.

메모리 고사용률 알람: 90% 이상이면 OOM(Out of Memory) 위험이 있습니다. 태스크 실패 알람: 태스크가 계속 실패하고 재시작되면 코드에 문제가 있을 가능성이 큽니다.

응답 시간 알람: API 응답 시간이 평소보다 2배 이상 느려지면 조사가 필요합니다. CloudWatch Logs도 중요한 모니터링 도구입니다.

애플리케이션 로그를 CloudWatch Logs로 전송하면 중앙에서 모든 로그를 확인할 수 있습니다. 여러 컨테이너에서 발생한 로그를 한곳에서 검색하고 분석할 수 있습니다.

에러 로그를 기반으로 알람을 설정할 수도 있습니다. "ERROR" 문자열이 1분에 10번 이상 나타나면 알림을 보내는 식입니다.

CloudWatch Insights 쿼리를 활용하면 더욱 강력합니다. SQL과 유사한 쿼리 언어로 로그를 분석할 수 있습니다.

"지난 1시간 동안 가장 많이 발생한 에러 TOP 10"을 찾거나, "특정 사용자의 모든 요청 로그"를 추적할 수 있습니다. 문제 해결에 큰 도움이 됩니다.

실무에서는 대시보드를 만들어 사용합니다. 중요한 메트릭들을 한 화면에 모아서 대시보드를 구성합니다.

출근하자마자, 그리고 주기적으로 대시보드를 확인하는 습관을 들이면 문제를 조기에 발견할 수 있습니다. 팀 전체가 같은 대시보드를 보면 상황 공유도 쉬워집니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 알람을 설정하는 것입니다.

"혹시 몰라서" 모든 메트릭에 알람을 걸어두면, 하루에도 수십 개의 알림이 옵니다. 알람 피로(alert fatigue) 현상이 발생해서 정작 중요한 알림을 놓치게 됩니다.

정말 중요한 것만 알람으로 설정하고, 나머지는 대시보드로 확인하세요. 또 다른 실수는 임계값을 너무 낮게 설정하는 것입니다.

CPU 사용률 50% 알람을 설정하면 하루 종일 알림이 올 것입니다. 실제 문제가 되는 수준에서 알람이 울리도록 임계값을 조정하세요.

초기에는 높게 설정하고, 운영하면서 점진적으로 낮추는 것이 좋습니다. 알림 채널도 신중하게 선택해야 합니다.

중요한 알람은 SMS나 전화로 받고, 덜 중요한 알람은 이메일이나 슬랙으로 받습니다. 새벽 2시에 중요하지 않은 알림으로 깨어나는 일이 없도록 설정하세요.

온콜(on-call) 일정을 정해서 담당자를 순환하는 것도 좋은 방법입니다. 비용도 고려해야 합니다.

CloudWatch는 메트릭 개수, 로그 저장량, 알람 개수에 따라 비용이 발생합니다. 불필요한 로그는 빨리 삭제하고, 중요한 로그만 장기 보관하세요.

로그 보관 기간을 7일, 30일, 90일 등으로 구분해서 설정하면 비용을 절감할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

모니터링을 설정한 후 김개발 씨는 한결 안심하게 되었습니다. 어느 날 오전, CPU 사용률 알람이 울렸습니다.

문제가 커지기 전에 발견해서 빠르게 대응할 수 있었습니다. "모니터링이 이렇게 중요한 거였구나!" 제대로 된 모니터링은 안정적인 서비스 운영의 기본입니다.

처음에는 설정이 번거로워 보이지만, 한 번 제대로 구축해두면 장기적으로 큰 도움이 됩니다. 여러분도 오늘 배운 내용을 바탕으로 모니터링 체계를 구축해 보세요.

실전 팁

💡 - 핵심 메트릭 우선: CPU, 메모리, 태스크 실패율 같은 핵심 지표부터 모니터링하세요

알람은 선택적으로: 정말 중요한 것만 알람으로 설정해서 피로도를 줄이세요
대시보드 공유: 팀 전체가 같은 대시보드를 보면 상황 인식이 빨라집니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#ECS#Fargate#Docker#Container

AWS ECS 클러스터 생성 완벽 가이드

# AWS ECS 클러스터 생성 완벽 가이드 ECS 클러스터를 처음 생성하는 초급 개발자를 위한 완벽 가이드입니다. Fargate와 EC2 시작 유형의 차이부터 클러스터 설정, 용량 공급자, 모니터링까지 실무에 필요한 모든 내용을 담았습니다. --- ## 목차 1. [ECS란_무엇인가](#ecs란-무엇인가) 2. [Fargate_vs_EC2_시작_유형](#fargate-vs-ec2-시작-유형) 3. [클러스터_생성하기](#클러스터-생성하기) 4. [클러스터_설정_옵션](#클러스터-설정-옵션) 5. [용량_공급자](#용량-공급자) 6. [클러스터_모니터링](#클러스터-모니터링) --- ## 1. ECS란_무엇인가 입사 한 달차인 김개발 씨는 팀장님으로부터 처음으로 중요한 임무를 받았습니다. "우리 서비스를 컨테이너로 배포해야 하는데, AWS ECS를 사용해 보면 어떨까요?" 컨테이너는 들어봤지만 ECS는 처음입니다. 도대체 ECS가 뭘까요? **ECS**(Elastic Container Service)는 AWS에서 제공하는 **컨테이너 오케스트레이션 서비스**입니다. 마치 여러 대의 선박을 효율적으로 관리하는 항만 관리 시스템처럼, ECS는 수많은 Docker 컨테이너를 자동으로 배포하고 관리합니다. 개발자는 복잡한 인프라 관리 없이도 애플리케이션 개발에만 집중할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 ECS 클러스터 정보 조회 const { ECSClient, ListClustersCommand } = require('@aws-sdk/client-ecs'); const client = new ECSClient({ region: 'ap-northeast-2' }); async function listClusters() { try { // 클러스터 목록 조회 const command = new ListClustersCommand({}); const response = await client.send(command); console.log('ECS 클러스터 목록:', response.clusterArns); return response.clusterArns; } catch (error) { console.error('클러스터 조회 실패:', error); } } listClusters(); ``` 김개발 씨는 구글에 "AWS ECS"를 검색해봤습니다. 수많은 용어들이 눈앞에 펼쳐집니다. 클러스터, 태스크, 서비스, 컨테이너 인스턴스... 머리가 복잡해졌습니다. 선배 개발자인 박시니어 씨가 옆자리에서 이를 보고 빙그레 웃으며 말을 걸어왔습니다. "ECS가 처음이에요? 걱정 마세요. 저도 처음엔 헷갈렸거든요." 그렇다면 ECS란 정확히 무엇일까요? 쉽게 비유하자면, ECS는 마치 대형 물류 센터의 자동화 시스템과 같습니다. 물류 센터에서는 수많은 상품들이 들어오고 나가며, 이를 효율적으로 분류하고 배송하는 시스템이 필요합니다. ECS도 마찬가지입니다. 수많은 컨테이너(상품)들을 어디에 배치할지, 얼마나 실행할지, 언제 종료할지를 자동으로 관리해줍니다. ECS가 없던 시절에는 어땠을까요? 개발자들은 서버마다 직접 접속해서 Docker 명령어를 입력해야 했습니다. "이 서버에는 컨테이너 5개, 저 서버에는 3개..." 이런 식으로 일일이 관리했습니다. 서버가 2-3대라면 괜찮지만, 수십 대, 수백 대가 되면 어떨까요? 상상만 해도 끔찍합니다. 더 큰 문제는 장애 상황이었습니다. 어느 날 갑자기 서버 한 대가 다운되면, 그 위에서 실행되던 컨테이너들도 모두 멈춥니다. 개발자는 새벽에 전화를 받고 부랴부랴 다른 서버에 컨테이너를 다시 띄워야 했습니다. 자동화가 전혀 되어있지 않았던 것이죠. 바로 이런 문제를 해결하기 위해 ECS가 등장했습니다. ECS를 사용하면 **자동 스케일링**이 가능해집니다. 트래픽이 갑자기 증가하면 컨테이너를 자동으로 늘리고, 트래픽이 줄어들면 다시 줄여줍니다. 또한 **자동 복구** 기능도 제공됩니다. 컨테이너에 문제가 생기면 자동으로 재시작하거나 다른 서버에 새로 띄워줍니다. 무엇보다 **간편한 배포**라는 큰 이점이 있습니다. 몇 번의 클릭만으로 새로운 버전을 배포할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 2번째 줄을 보면 AWS SDK에서 필요한 클라이언트와 명령어를 불러옵니다. 이 부분이 ECS와 통신하기 위한 준비 단계입니다. 다음으로 4번째 줄에서는 ECS 클라이언트를 생성하는데, 서울 리전(ap-northeast-2)을 지정했습니다. 9번째 줄에서 실제 클러스터 목록을 조회하는 명령어를 실행하고, 그 결과를 반환합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 서비스를 운영한다고 가정해봅시다. 평소에는 트래픽이 적지만 블랙프라이데이 같은 대규모 세일 기간에는 트래픽이 10배 이상 증가합니다. ECS를 활용하면 트래픽에 따라 자동으로 컨테이너 개수를 조절할 수 있습니다. 쿠팡, 네이버 같은 대형 서비스들도 이런 패턴을 적극적으로 사용하고 있습니다. ECS의 핵심 구성 요소를 이해하는 것이 중요합니다. **클러스터**는 컨테이너들이 실행되는 논리적인 그룹입니다. 하나의 큰 틀이라고 생각하면 됩니다. **태스크**는 실제로 실행되는 컨테이너의 설정을 정의합니다. 어떤 Docker 이미지를 사용할지, 메모리는 얼마나 할당할지 등을 명시합니다. **서비스**는 지정된 개수만큼 태스크를 유지하도록 관리합니다. 예를 들어 "이 태스크를 항상 5개 유지해줘"라고 설정할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 클러스터와 태스크를 혼동하는 것입니다. 클러스터는 단지 논리적인 그룹일 뿐, 실제 컨테이너가 실행되는 것은 태스크입니다. 이를 제대로 이해하지 못하면 "클러스터는 만들었는데 왜 아무것도 실행되지 않지?"라는 의문에 빠질 수 있습니다. 따라서 클러스터 생성 후에는 반드시 태스크 정의와 서비스 생성까지 진행해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, ECS가 컨테이너를 자동으로 관리해주는 시스템이군요!" ECS를 제대로 이해하면 더 안정적이고 확장 가능한 서비스를 만들 수 있습니다. 처음에는 복잡해 보이지만, 하나씩 차근차근 배워나가다 보면 어느새 ECS 전문가가 되어 있을 것입니다. **실전 팁** 💡 - **무료 티어 활용**: AWS 프리티어로 ECS를 무료로 학습할 수 있습니다 (Fargate 사용 시 제한적) - **문서 정독**: AWS 공식 문서의 Getting Started 가이드를 반드시 읽어보세요 - **작게 시작하기**: 처음부터 복잡한 구조를 만들지 말고, 간단한 웹 서버 하나로 시작하세요 --- ## 2. Fargate_vs_EC2_시작_유형 김개발 씨는 ECS 클러스터를 생성하려고 AWS 콘솔에 접속했습니다. 그런데 이게 웬일입니까? "시작 유형을 선택하세요"라는 메시지와 함께 Fargate와 EC2 두 가지 옵션이 나타났습니다. 도대체 뭐가 다른 걸까요? **Fargate**는 서버 관리 없이 컨테이너만 실행하는 **서버리스 방식**이고, **EC2**는 직접 서버를 관리하면서 컨테이너를 실행하는 **전통적인 방식**입니다. Fargate는 편리하지만 비용이 높고, EC2는 복잡하지만 비용을 절감할 수 있습니다. 프로젝트 특성에 따라 적절한 시작 유형을 선택해야 합니다. 다음 코드를 살펴봅시다. ```javascript // Fargate 태스크 정의 예제 { "family": "my-app-fargate", "networkMode": "awsvpc", // Fargate는 awsvpc 필수 "requiresCompatibilities": ["FARGATE"], "cpu": "256", // Fargate는 특정 CPU/메모리 조합만 지원 "memory": "512", "containerDefinitions": [{ "name": "my-container", "image": "nginx:latest", "portMappings": [{ "containerPort": 80, "protocol": "tcp" }] }] } ``` 김개발 씨는 팀 채팅방에 물어봤습니다. "Fargate랑 EC2 중에 뭘 선택해야 하나요?" 그러자 팀원들의 의견이 분분했습니다. "Fargate가 편해요!" "아니야, EC2가 비용 면에서 훨씬 낫지!" 박시니어 씨가 회의실로 김개발 씨를 불렀습니다. "둘 다 장단점이 있어요. 상황에 맞게 선택하는 게 중요합니다." Fargate와 EC2의 차이를 쉽게 이해해 봅시다. 마치 택시와 자가용의 차이와 같습니다. Fargate는 택시처럼 필요할 때만 타고 내리면 됩니다. 차량 관리, 보험, 정비 이런 것들은 전혀 신경 쓸 필요가 없습니다. 반면 EC2는 자가용과 같습니다. 직접 차를 구매하고, 관리하고, 정비해야 합니다. 하지만 장거리를 자주 다닌다면 자가용이 훨씬 경제적입니다. Fargate가 없던 시절에는 어땠을까요? ECS를 사용하려면 무조건 EC2 인스턴스를 직접 띄워야 했습니다. 인스턴스 크기를 선택하고, 오토스케일링을 설정하고, 보안 패치를 적용하고... 컨테이너 오케스트레이션만으로도 복잡한데, 서버 관리까지 신경 써야 했습니다. 더 큰 문제는 **리소스 낭비**였습니다. 컨테이너는 작은데 EC2 인스턴스는 크게 띄워야 해서, 많은 자원이 놀고 있었습니다. 또한 트래픽이 갑자기 증가하면 EC2 인스턴스를 먼저 늘려야 했는데, 이 과정이 느렸습니다. 바로 이런 문제를 해결하기 위해 Fargate가 등장했습니다. Fargate를 사용하면 **서버 관리가 필요 없습니다**. EC2 인스턴스를 띄울 필요도, 패치를 적용할 필요도 없습니다. AWS가 모든 것을 알아서 관리해줍니다. 또한 **정확한 리소스 할당**이 가능합니다. 256MB 메모리가 필요하면 정확히 256MB만 사용하고, 그만큼만 비용을 지불합니다. 무엇보다 **빠른 스케일링**이라는 큰 이점이 있습니다. EC2 인스턴스를 기다릴 필요 없이 바로 컨테이너를 실행할 수 있습니다. 하지만 EC2 시작 유형도 여전히 중요합니다. **비용 최적화**가 필요한 경우 EC2가 유리합니다. 24시간 내내 실행되는 서비스라면 Reserved Instance나 Spot Instance를 활용해서 비용을 크게 절감할 수 있습니다. 또한 **특수한 요구사항**이 있는 경우에도 EC2를 선택합니다. 예를 들어 GPU가 필요하거나, 특정 인스턴스 유형이 필요한 경우입니다. **세밀한 제어**가 필요할 때도 EC2가 적합합니다. 인스턴스 레벨에서 로깅이나 모니터링을 설정하고 싶다면 EC2를 사용해야 합니다. 위의 코드를 한 줄씩 살펴보겠습니다. 3번째 줄을 보면 networkMode가 "awsvpc"로 설정되어 있습니다. Fargate는 awsvpc 네트워크 모드만 지원하므로 이는 필수입니다. 4번째 줄에서는 requiresCompatibilities를 통해 이 태스크가 Fargate에서 실행될 것임을 명시합니다. 5-6번째 줄에서 CPU와 메모리를 지정하는데, Fargate는 특정 조합만 지원합니다. 256 CPU에는 512, 1024, 2048 메모리만 사용 가능합니다. 실제 현업에서는 어떻게 선택할까요? 스타트업 A사는 초기에 사용자가 적고 트래픽 변동이 심합니다. 이런 경우 Fargate가 적합합니다. 사용한 만큼만 비용을 내고, 갑작스러운 트래픽 증가에도 빠르게 대응할 수 있습니다. 반면 B사는 안정적인 트래픽을 가진 대규모 서비스를 운영합니다. 수백 개의 컨테이너가 24시간 돌아갑니다. 이런 경우 EC2 Reserved Instance를 사용하면 Fargate 대비 50% 이상 비용을 절감할 수 있습니다. 실무에서 자주 사용하는 패턴은 **하이브리드 방식**입니다. 기본적인 워크로드는 EC2로 처리하고, 갑작스러운 트래픽 증가 시에는 Fargate로 처리합니다. 이를 위해 **용량 공급자**(Capacity Provider)를 사용합니다. 평소에는 EC2 인스턴스에서 컨테이너를 실행하다가, 리소스가 부족하면 자동으로 Fargate를 사용하도록 설정할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 무조건 Fargate를 선택하는 것입니다. "관리가 편하니까 Fargate로 하자!" 하지만 24시간 돌아가는 서비스를 Fargate로 운영하면 비용이 예상보다 훨씬 많이 나올 수 있습니다. 따라서 트래픽 패턴과 예상 비용을 먼저 계산해보고 선택해야 합니다. 또 다른 실수는 Fargate의 제약사항을 모르는 것입니다. Fargate는 특정 CPU/메모리 조합만 지원하고, 최대 30GB까지만 스토리지를 사용할 수 있습니다. 대용량 데이터 처리가 필요하다면 EC2를 선택해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "우리 서비스는 초기 단계니까 일단 Fargate로 시작하는 게 좋겠네요!" 선택의 기준을 정리하면 이렇습니다. 빠른 시작과 간편한 관리가 중요하다면 Fargate, 비용 최적화와 세밀한 제어가 필요하다면 EC2를 선택하세요. 여러분의 프로젝트에 맞는 선택을 하시기 바랍니다. **실전 팁** 💡 - **비용 계산기 활용**: AWS Pricing Calculator로 Fargate와 EC2 비용을 미리 비교해보세요 - **작게 시작**: 처음에는 Fargate로 시작해서 빠르게 검증하고, 나중에 필요하면 EC2로 전환하세요 - **하이브리드 고려**: 용량 공급자를 활용해 두 방식의 장점을 모두 가져갈 수 있습니다 --- ## 3. 클러스터_생성하기 드디어 김개발 씨가 본격적으로 ECS 클러스터를 생성할 시간입니다. AWS 콘솔을 열고 ECS 메뉴로 들어갔습니다. "클러스터 생성" 버튼을 눌렀더니 여러 설정 옵션이 나타납니다. 어디서부터 시작해야 할까요? ECS 클러스터 생성은 **AWS 콘솔**이나 **AWS CLI**, **Terraform** 등을 통해 할 수 있습니다. 클러스터 이름을 지정하고, 네트워킹을 설정하며, 필요한 경우 CloudWatch Container Insights를 활성화합니다. 기본 설정만으로도 간단히 생성할 수 있지만, 프로덕션 환경에서는 세부 설정을 신중히 검토해야 합니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK로 ECS 클러스터 생성 const { ECSClient, CreateClusterCommand } = require('@aws-sdk/client-ecs'); const client = new ECSClient({ region: 'ap-northeast-2' }); async function createCluster() { try { const command = new CreateClusterCommand({ clusterName: 'my-production-cluster', // Container Insights 활성화 (모니터링) settings: [{ name: 'containerInsights', value: 'enabled' }], // 클러스터 태그 설정 tags: [ { key: 'Environment', value: 'production' }, { key: 'Team', value: 'backend' } ] }); const response = await client.send(command); console.log('클러스터 생성 완료:', response.cluster); return response.cluster; } catch (error) { console.error('클러스터 생성 실패:', error); } } createCluster(); ``` 김개발 씨는 화면을 유심히 살펴봅니다. 생각보다 입력할 항목이 많지 않습니다. "이게 전부인가?" 싶을 정도로 간단해 보입니다. 박시니어 씨가 말합니다. "ECS 클러스터 자체는 논리적인 그룹일 뿐이라서, 생성 자체는 정말 간단해요. 중요한 건 이후에 어떤 태스크와 서비스를 띄울지입니다." 클러스터 생성 과정을 단계별로 살펴봅시다. 마치 아파트 단지를 만드는 것과 비슷합니다. 먼저 단지 이름을 정하고, 기본 인프라를 준비합니다. 실제 건물(컨테이너)은 나중에 짓습니다. ECS 클러스터도 마찬가지입니다. 일단 틀을 만들고, 그 안에 무엇을 실행할지는 나중에 결정합니다. 클러스터 생성이 복잡하지 않은 이유가 있습니다. 전통적인 서버 환경에서는 서버를 준비하는 것 자체가 큰 작업이었습니다. 하드웨어를 구매하고, 랙에 장착하고, 네트워크를 연결하고, OS를 설치하는 등 수많은 단계를 거쳐야 했습니다. 심지어 이 모든 과정이 수일에서 수주가 걸렸습니다. 클라우드 시대에는 이런 물리적 제약이 사라졌습니다. 하지만 여전히 EC2 인스턴스를 띄우고, 설정하고, 관리해야 했습니다. ECS 클러스터는 이런 복잡함을 한 단계 더 추상화했습니다. 바로 이런 배경에서 ECS 클러스터의 간단함이 나옵니다. 클러스터를 생성하면 **논리적인 네임스페이스**가 만들어집니다. 이 안에 여러 서비스와 태스크를 배치할 수 있습니다. 또한 **리소스 격리**가 가능해집니다. 개발 환경 클러스터, 스테이징 클러스터, 프로덕션 클러스터를 분리해서 관리할 수 있습니다. 무엇보다 **통합 모니터링**이라는 큰 이점이 있습니다. CloudWatch Container Insights를 활성화하면 클러스터 전체의 메트릭을 한눈에 볼 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 8번째 줄에서 CreateClusterCommand를 생성합니다. 이 명령어가 실제 클러스터를 만드는 핵심입니다. 9번째 줄의 clusterName은 필수 항목이며, 리전 내에서 고유해야 합니다. 11-13번째 줄에서는 Container Insights를 활성화합니다. 이를 통해 CPU, 메모리, 네트워크 사용량 등을 자동으로 수집합니다. 15-18번째 줄의 태그는 선택사항이지만, 실무에서는 반드시 설정하는 것이 좋습니다. 나중에 비용 추적이나 리소스 관리에 큰 도움이 됩니다. 실제 현업에서는 어떻게 클러스터를 구성할까요? 대부분의 회사는 환경별로 클러스터를 분리합니다. dev-cluster, staging-cluster, production-cluster 이런 식입니다. 이렇게 하면 개발 환경의 실수가 프로덕션에 영향을 주지 않습니다. 또한 팀별로 클러스터를 나누기도 합니다. backend-cluster, frontend-cluster, data-cluster 등으로 관리하면 책임 소재가 명확해집니다. 네이버나 카카오 같은 대규모 서비스는 어떻게 할까요? 하나의 거대한 클러스터보다는 여러 개의 작은 클러스터로 나눕니다. 서비스별로, 또는 기능별로 클러스터를 분리합니다. 이를 **마이크로서비스 아키텍처**라고 부릅니다. 각 팀이 독립적으로 배포하고 관리할 수 있어서 개발 속도가 빨라집니다. AWS CLI로도 클러스터를 생성할 수 있습니다. 콘솔보다 CLI가 더 편한 경우가 많습니다. 특히 여러 개의 클러스터를 생성하거나, 자동화 스크립트를 작성할 때 유용합니다. Terraform이나 CloudFormation 같은 **Infrastructure as Code** 도구를 사용하면 더욱 체계적으로 관리할 수 있습니다. 모든 설정이 코드로 관리되므로, 버전 관리도 되고, 재현 가능합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 클러스터 이름을 대충 짓는 것입니다. "test", "cluster1", "my-cluster" 같은 이름은 나중에 혼란을 야기합니다. 명확한 네이밍 컨벤션을 정하세요. 예를 들어 "{환경}-{팀}-{용도}-cluster" 형식으로 통일하는 것이 좋습니다. 또 다른 실수는 Container Insights를 처음부터 활성화하지 않는 것입니다. 나중에 활성화할 수도 있지만, 그동안의 데이터는 볼 수 없습니다. 처음부터 활성화해두면 문제 발생 시 과거 데이터를 분석할 수 있습니다. 물론 약간의 추가 비용이 발생하지만, 그만한 가치가 있습니다. 클러스터를 삭제할 때도 주의가 필요합니다. 클러스터 안에 실행 중인 서비스나 태스크가 있으면 삭제되지 않습니다. 먼저 모든 서비스를 삭제하고, 실행 중인 태스크를 중지한 후에 클러스터를 삭제해야 합니다. 급하게 삭제하려다가 리소스가 남아서 계속 비용이 청구되는 경우가 종종 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 도움을 받으며 김개발 씨는 첫 클러스터를 성공적으로 생성했습니다. "생각보다 간단하네요!" ECS 클러스터 생성은 시작일 뿐입니다. 이제 이 클러스터 안에 실제 애플리케이션을 배포해야 합니다. 하지만 첫 걸음을 잘 떼었습니다. 여러분도 오늘 배운 내용을 토대로 첫 클러스터를 만들어 보세요. **실전 팁** 💡 - **네이밍 컨벤션 정하기**: 클러스터 이름은 일관된 규칙을 따르세요 (예: prod-backend-api-cluster) - **태그 필수**: 환경, 팀, 용도 등을 태그로 명시하면 나중에 관리가 훨씬 쉽습니다 - **IaC 도구 활용**: Terraform이나 CDK로 클러스터를 관리하면 재현성과 버전 관리가 가능합니다 --- ## 4. 클러스터_설정_옵션 클러스터를 생성한 김개발 씨는 이제 세부 설정을 살펴볼 차례입니다. "클러스터 생성은 했는데, 이제 뭘 설정해야 하지?" 박시니어 씨가 화면을 가리키며 말합니다. "Container Insights, 기본 용량 공급자 전략, 태그... 이런 것들을 제대로 설정해야 나중에 편합니다." ECS 클러스터의 주요 설정 옵션으로는 **Container Insights** 모니터링, **기본 용량 공급자 전략**, **태그**, **서비스 디스커버리 네임스페이스** 등이 있습니다. 이러한 설정들은 클러스터의 가시성, 리소스 관리, 비용 추적에 큰 영향을 미칩니다. 초기 설정을 제대로 하면 운영이 훨씬 수월해집니다. 다음 코드를 살펴봅시다. ```javascript // 클러스터 상세 설정 조회 const { ECSClient, DescribeClusterCommand, UpdateClusterSettingsCommand } = require('@aws-sdk/client-ecs'); const client = new ECSClient({ region: 'ap-northeast-2' }); async function updateClusterSettings(clusterName) { try { // 현재 설정 조회 const describeCmd = new DescribeClusterCommand({ clusters: [clusterName], include: ['SETTINGS', 'STATISTICS'] }); const current = await client.send(describeCmd); console.log('현재 설정:', current.clusters[0].settings); // Container Insights 활성화 const updateCmd = new UpdateClusterSettingsCommand({ cluster: clusterName, settings: [{ name: 'containerInsights', value: 'enabled' }] }); const response = await client.send(updateCmd); console.log('설정 업데이트 완료'); return response; } catch (error) { console.error('설정 업데이트 실패:', error); } } updateClusterSettings('my-production-cluster'); ``` 김개발 씨는 클러스터 상세 페이지를 열어봤습니다. 수많은 탭과 메뉴가 눈에 들어옵니다. "뭐가 이렇게 많아?" 처음 보는 용어들이 가득합니다. 박시니어 씨가 커피를 한 잔 따라주며 설명을 시작합니다. "하나씩 천천히 알아가면 돼요. 일단 가장 중요한 것들만 먼저 설정합시다." 클러스터 설정을 이해하기 위한 좋은 비유가 있습니다. 마치 새 스마트폰을 샀을 때와 같습니다. 기본 설정만으로도 사용할 수 있지만, 알림, 배터리 절약 모드, 백업 등을 제대로 설정하면 훨씬 편리합니다. ECS 클러스터도 마찬가지입니다. 기본 설정으로도 작동하지만, 세부 설정을 잘하면 운영이 훨씬 수월해집니다. 가장 먼저 살펴볼 설정은 **Container Insights**입니다. 이것은 ECS 클러스터의 모니터링 도구입니다. CPU 사용률, 메모리 사용률, 네트워크 트래픽, 실행 중인 태스크 수 등 중요한 메트릭을 자동으로 수집합니다. CloudWatch와 연동되어 대시보드로 한눈에 볼 수 있습니다. 문제가 생겼을 때 "언제부터 CPU가 올라갔지?" 같은 질문에 바로 답할 수 있습니다. Container Insights가 없던 시절에는 어땠을까요? 개발자들은 직접 모니터링 도구를 설치하고 설정해야 했습니다. Prometheus, Grafana 같은 오픈소스 도구를 사용하거나, 자체 모니터링 시스템을 구축했습니다. 이는 많은 시간과 노력이 필요했습니다. 더 큰 문제는 일관성이 없었다는 점입니다. 팀마다 다른 도구를 사용해서 메트릭을 비교하기 어려웠습니다. Container Insights를 활성화하면 이런 고민이 사라집니다. AWS가 표준화된 메트릭을 자동으로 수집해줍니다. 설정도 간단합니다. 클러스터 생성 시 체크박스 하나만 선택하면 됩니다. 물론 약간의 추가 비용이 발생하지만, 운영 편의성을 생각하면 충분히 가치가 있습니다. 다음으로 중요한 설정은 **기본 용량 공급자 전략**입니다. 이것은 태스크를 어디에 배치할지 결정하는 정책입니다. Fargate를 사용할지, EC2 인스턴스를 사용할지, 아니면 둘을 섞어서 사용할지를 정의합니다. 예를 들어 "평소에는 EC2를 사용하다가, 리소스가 부족하면 Fargate로 넘어가"라고 설정할 수 있습니다. 이를 통해 비용과 유연성의 균형을 맞출 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 9-12번째 줄에서 DescribeClusterCommand를 사용해 현재 클러스터의 설정을 조회합니다. include 파라미터에 'SETTINGS'와 'STATISTICS'를 지정하면 상세 정보를 가져올 수 있습니다. 17-22번째 줄에서는 UpdateClusterSettingsCommand로 Container Insights를 활성화합니다. 이미 생성된 클러스터의 설정도 언제든 변경할 수 있습니다. **태그** 설정도 매우 중요합니다. 태그는 단순한 라벨이 아닙니다. AWS Cost Explorer를 통해 태그별로 비용을 추적할 수 있습니다. "이번 달 프로덕션 환경에 얼마나 썼지?" 같은 질문에 바로 답할 수 있습니다. 또한 IAM 정책에서 태그를 기반으로 권한을 제어할 수도 있습니다. "Environment=production" 태그가 있는 리소스는 시니어 개발자만 수정할 수 있도록 설정하는 식입니다. 실무에서는 보통 이런 태그를 사용합니다. Environment 태그로 dev, staging, production을 구분합니다. Team 태그로 backend, frontend, devops 등 담당 팀을 명시합니다. CostCenter 태그로 비용 부서를 지정하면 회계팀이 좋아합니다. Project 태그로 어떤 프로젝트에 속하는지 표시합니다. **서비스 디스커버리 네임스페이스**는 고급 기능입니다. 마이크로서비스 아키텍처에서는 서비스 간 통신이 중요합니다. A 서비스가 B 서비스를 호출하려면 B 서비스의 주소를 알아야 합니다. 하지만 컨테이너는 동적으로 생성되고 삭제되므로 IP 주소가 계속 바뀝니다. 서비스 디스커버리를 설정하면 "backend.local" 같은 이름으로 접근할 수 있습니다. 내부적으로 AWS Cloud Map이 자동으로 주소를 찾아줍니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 모든 설정을 한꺼번에 바꾸려는 것입니다. Container Insights, 용량 공급자, 서비스 디스커버리를 동시에 설정하다가 혼란에 빠집니다. 하나씩 차근차근 설정하고 테스트하는 것이 좋습니다. 먼저 Container Insights만 활성화해서 모니터링이 제대로 되는지 확인하세요. 그다음 용량 공급자를 설정하고, 필요하면 서비스 디스커버리를 추가하세요. 또 다른 실수는 설정을 문서화하지 않는 것입니다. 6개월 후에 "이 클러스터는 왜 이렇게 설정했지?" 하고 헷갈릴 수 있습니다. 각 설정의 의도를 README 파일이나 Wiki에 기록해두세요. 특히 Terraform이나 CloudFormation을 사용한다면 코드에 주석으로 남기는 것이 좋습니다. Container Insights의 비용도 고려해야 합니다. 수집되는 메트릭과 로그에 따라 비용이 발생합니다. 소규모 클러스터라면 월 몇 달러 수준이지만, 대규모 클러스터는 수백 달러가 될 수 있습니다. 필요한 메트릭만 선별적으로 수집하도록 설정하면 비용을 절감할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 체크리스트를 작성했습니다. "Container Insights 활성화, 태그 설정, 용량 공급자는 나중에..." 하나씩 차근차근 진행하기로 했습니다. 클러스터 설정은 한 번에 완벽할 필요가 없습니다. 서비스가 성장하면서 필요에 따라 추가하고 조정하면 됩니다. 중요한 것은 기본적인 모니터링과 태그만 제대로 설정해두는 것입니다. **실전 팁** 💡 - **Container Insights 먼저**: 가장 먼저 활성화해서 기준선 데이터를 쌓으세요 - **태그 표준 정하기**: 팀 전체가 동일한 태그 규칙을 따르도록 문서화하세요 - **점진적 설정**: 모든 기능을 한꺼번에 켜지 말고 필요한 것부터 하나씩 활성화하세요 --- ## 5. 용량_공급자 김개발 씨는 클러스터를 운영하면서 고민에 빠졌습니다. "평소에는 EC2로 비용을 절약하고, 트래픽이 급증하면 Fargate로 빠르게 확장하고 싶은데 가능할까?" 박시니어 씨가 웃으며 말합니다. "용량 공급자(Capacity Provider)를 사용하면 됩니다." **용량 공급자**는 ECS 태스크를 실행할 인프라를 관리하는 컴포넌트입니다. Fargate, Fargate Spot, Auto Scaling Group과 연동된 EC2 등을 용량 공급자로 설정할 수 있습니다. 여러 공급자를 조합하고 **가중치**와 **기본 값**을 설정해서 비용과 성능의 균형을 맞출 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // 용량 공급자 전략 설정 const { ECSClient, PutClusterCapacityProvidersCommand } = require('@aws-sdk/client-ecs'); const client = new ECSClient({ region: 'ap-northeast-2' }); async function configureCapacityProviders(clusterName) { try { const command = new PutClusterCapacityProvidersCommand({ cluster: clusterName, // 사용할 용량 공급자 목록 capacityProviders: ['FARGATE', 'FARGATE_SPOT'], // 기본 전략: 70% Fargate, 30% Fargate Spot defaultCapacityProviderStrategy: [ { capacityProvider: 'FARGATE', weight: 70, base: 2 // 최소 2개는 항상 Fargate 사용 }, { capacityProvider: 'FARGATE_SPOT', weight: 30, base: 0 // Spot은 추가 태스크만 } ] }); const response = await client.send(command); console.log('용량 공급자 설정 완료:', response); return response; } catch (error) { console.error('설정 실패:', error); } } configureCapacityProviders('my-production-cluster'); ``` 김개발 씨는 지난 한 달간의 비용 리포트를 보고 놀랐습니다. Fargate 비용이 예상보다 훨씬 높게 나왔습니다. "이대로는 안 되겠는데..." 하지만 EC2로 전환하면 관리가 복잡해질 것 같습니다. 박시니어 씨가 해결책을 제시합니다. "두 가지 장점을 모두 가져갈 수 있어요. 용량 공급자를 제대로 활용하면 됩니다." 용량 공급자를 이해하기 위한 좋은 비유가 있습니다. 마치 택시와 버스를 적절히 활용하는 것과 같습니다. 평소에는 저렴한 버스(EC2)를 주로 이용하고, 급할 때는 택시(Fargate)를 타는 것입니다. 심지어 할인 택시(Fargate Spot)도 활용할 수 있습니다. 용량 공급자는 이런 전략을 자동화해주는 교통 관리 시스템입니다. 용량 공급자가 등장하기 전에는 어땠을까요? 개발자들은 수동으로 태스크를 배치해야 했습니다. "이 서비스는 Fargate로, 저 서비스는 EC2로" 이런 식으로 일일이 지정했습니다. 트래픽이 증가하면 직접 개입해서 Fargate 태스크를 늘려야 했습니다. 자동화가 안 되니 항상 모니터링을 해야 했고, 대응이 느렸습니다. 더 큰 문제는 **리소스 낭비**였습니다. 안전을 위해 여유 있게 EC2 인스턴스를 띄워두면 평소에 리소스가 남았습니다. 반대로 딱 맞게 띄우면 트래픽 급증 시 대응이 늦었습니다. 최적의 균형점을 찾기가 정말 어려웠습니다. 바로 이런 문제를 해결하기 위해 용량 공급자가 등장했습니다. 용량 공급자를 설정하면 **자동 리소스 선택**이 가능해집니다. 설정한 전략에 따라 ECS가 알아서 적절한 인프라를 선택합니다. 또한 **유연한 확장**이 가능합니다. EC2 용량이 부족하면 자동으로 Fargate로 넘어갑니다. 무엇보다 **비용 최적화**라는 큰 이점이 있습니다. 저렴한 Spot 인스턴스를 적극 활용하면서도 안정성을 유지할 수 있습니다. 주요 용량 공급자 유형을 살펴봅시다. **FARGATE**는 가장 간편한 옵션입니다. 서버 관리 없이 바로 실행되며, 안정적입니다. **FARGATE_SPOT**은 Fargate의 저렴한 버전입니다. 최대 70% 할인되지만, 언제든 중단될 수 있습니다. 중요하지 않은 배치 작업에 적합합니다. **EC2 Auto Scaling Group**은 직접 관리하는 EC2 인스턴스 그룹입니다. 가장 저렴하지만 설정이 복잡합니다. 위의 코드를 한 줄씩 살펴보겠습니다. 11번째 줄에서 사용할 용량 공급자 목록을 지정합니다. Fargate와 Fargate Spot 두 가지를 사용하겠다는 의미입니다. 13-24번째 줄이 핵심입니다. defaultCapacityProviderStrategy에서 각 공급자의 **가중치(weight)**와 **기본 값(base)**을 설정합니다. base가 2라는 것은 최소 2개의 태스크는 항상 Fargate로 실행한다는 뜻입니다. 나머지는 가중치 비율(70:30)로 분배됩니다. 실무에서 많이 사용하는 전략을 소개합니다. **안정성 우선 전략**: 중요한 프로덕션 서비스에서는 Fargate 80%, Fargate Spot 20% 정도로 설정합니다. base를 높게 잡아서 최소한의 안정적인 용량을 확보합니다. Spot은 추가 트래픽 처리용으로만 사용합니다. **비용 최적화 전략**: 개발이나 테스트 환경에서는 Fargate Spot 70%, Fargate 30%로 거꾸로 설정합니다. 가끔 중단되어도 크게 문제가 없으므로 비용을 크게 절감할 수 있습니다. **하이브리드 전략**: EC2 Auto Scaling Group을 base로 사용하고, 확장 시에만 Fargate를 사용합니다. 평소 트래픽은 저렴한 EC2로 처리하고, 급증 시에만 Fargate로 빠르게 확장합니다. Fargate Spot 사용 시 주의사항이 있습니다. Spot 인스턴스는 언제든 2분 전 통보 후 중단될 수 있습니다. 따라서 **상태를 저장하지 않는(stateless)** 애플리케이션에만 사용해야 합니다. 또한 **재시도 로직**을 구현해야 합니다. 작업 중간에 중단되면 자동으로 다시 시작되도록 설계하세요. 용량 공급자 전략은 서비스별로 다르게 설정할 수 있습니다. 클러스터 레벨에서 기본 전략을 정의하고, 각 서비스에서 이를 오버라이드할 수 있습니다. 예를 들어 중요한 API 서비스는 Fargate 100%로 설정하고, 로그 처리 서비스는 Fargate Spot 100%로 설정하는 식입니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 Fargate Spot을 과도하게 사용하는 것입니다. "저렴하니까 전부 Spot으로!" 하지만 트래픽이 많을 때 Spot이 대량으로 중단되면 서비스 장애로 이어질 수 있습니다. 항상 안정적인 용량을 base로 확보하고, Spot은 추가 용량으로만 사용하세요. 또 다른 실수는 가중치를 너무 복잡하게 설정하는 것입니다. "Fargate 45%, Fargate Spot 35%, EC2 20%..." 이렇게 세밀하게 나누면 오히려 예측하기 어렵습니다. 간단하게 2-3개 정도로 나누는 것이 관리하기 좋습니다. 모니터링도 중요합니다. CloudWatch에서 어떤 용량 공급자가 실제로 사용되는지 확인하세요. 설정한 전략대로 작동하는지, Spot 중단율은 얼마나 되는지 주기적으로 점검해야 합니다. 필요하면 전략을 조정하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다. 용량 공급자를 설정한 김개발 씨는 한 달 후 비용 리포트를 확인했습니다. "와, 비용이 30% 정도 줄었네요!" 안정성은 유지하면서 비용을 절감하는 데 성공했습니다. 용량 공급자는 ECS의 강력한 기능 중 하나입니다. 처음에는 복잡해 보이지만, 제대로 활용하면 비용과 성능 모두를 잡을 수 있습니다. 여러분의 서비스 특성에 맞는 전략을 찾아보세요. **실전 팁** 💡 - **작게 시작**: 처음에는 Fargate 100%로 시작해서 안정화한 후, 점진적으로 Spot을 추가하세요 - **모니터링 필수**: Spot 중단율과 비용 절감 효과를 주기적으로 확인하세요 - **상태 없는 설계**: Spot을 사용하려면 애플리케이션이 언제든 재시작될 수 있도록 설계되어야 합니다 --- ## 6. 클러스터_모니터링 클러스터를 프로덕션에 배포한 김개발 씨는 새로운 고민에 빠졌습니다. "서비스가 잘 돌아가는 건지 어떻게 알 수 있지?" 새벽 3시에 문제가 생기면 어떻게 알 수 있을까요? 박시니어 씨가 말합니다. "모니터링과 알람을 제대로 설정해야 합니다." ECS 클러스터 모니터링은 **CloudWatch Container Insights**, **CloudWatch Logs**, **CloudWatch Alarms**를 통해 이루어집니다. CPU, 메모리, 네트워크 사용률 같은 메트릭을 실시간으로 추적하고, 임계값을 초과하면 자동으로 알림을 받을 수 있습니다. 제대로 된 모니터링은 문제를 조기에 발견하고 대응하는 핵심입니다. 다음 코드를 살펴봅시다. ```javascript // CloudWatch 알람 생성 - CPU 사용률 모니터링 const { CloudWatchClient, PutMetricAlarmCommand } = require('@aws-sdk/client-cloudwatch'); const client = new CloudWatchClient({ region: 'ap-northeast-2' }); async function createCpuAlarm(clusterName, serviceName) { try { const command = new PutMetricAlarmCommand({ AlarmName: `${serviceName}-high-cpu`, AlarmDescription: 'CPU 사용률이 80%를 초과하면 알림', MetricName: 'CPUUtilization', Namespace: 'AWS/ECS', Statistic: 'Average', Period: 300, // 5분 EvaluationPeriods: 2, // 2번 연속 초과 시 Threshold: 80.0, // 80% 임계값 ComparisonOperator: 'GreaterThanThreshold', Dimensions: [ { Name: 'ClusterName', Value: clusterName }, { Name: 'ServiceName', Value: serviceName } ], // SNS로 알림 전송 AlarmActions: ['arn:aws:sns:ap-northeast-2:123456789:alerts'] }); const response = await client.send(command); console.log('알람 생성 완료'); return response; } catch (error) { console.error('알람 생성 실패:', error); } } createCpuAlarm('my-production-cluster', 'api-service'); ``` 김개발 씨는 지난주 장애 상황을 떠올렸습니다. 오후 2시쯤 갑자기 서비스가 느려졌고, 사용자들의 불만이 쏟아졌습니다. 한 시간이 지나서야 문제를 발견했습니다. CPU 사용률이 100%에 도달해 있었던 것입니다. 박시니어 씨가 고개를 끄덕입니다. "모니터링이 없으면 사후 대응만 가능해요. 제대로 된 모니터링이 있으면 문제가 커지기 전에 미리 알 수 있습니다." 클러스터 모니터링을 이해하기 위한 좋은 비유가 있습니다. 마치 자동차의 계기판과 같습니다. 속도계, 연료 게이지, 엔진 온도 등을 실시간으로 확인할 수 있습니다. 연료가 부족하면 경고등이 켜지고, 엔진 과열이 감지되면 알림이 울립니다. ECS 모니터링도 마찬가지입니다. 클러스터의 상태를 실시간으로 보여주고, 문제가 생기면 즉시 알려줍니다. 모니터링이 제대로 되지 않던 시절에는 어땠을까요? 개발자들은 로그 파일을 직접 열어서 확인해야 했습니다. "에러가 있나?" "CPU는 괜찮나?" 하루에도 수십 번씩 서버에 접속해서 확인했습니다. 주말이나 새벽에 문제가 생겨도 모를 수 있었습니다. 사용자들이 먼저 문제를 제보하는 경우가 많았습니다. 더 큰 문제는 **원인 분석이 어려웠다는 점**입니다. 문제가 발생한 후에는 이미 늦었습니다. "언제부터 문제가 시작됐지?" "무엇이 원인이었지?" 과거 데이터가 없으니 추측만 할 뿐이었습니다. 바로 이런 문제를 해결하기 위해 CloudWatch Container Insights가 등장했습니다. Container Insights를 활성화하면 **자동 메트릭 수집**이 시작됩니다. CPU, 메모리, 네트워크, 디스크 사용률이 자동으로 기록됩니다. 태스크별, 서비스별, 클러스터별로 세분화된 데이터를 볼 수 있습니다. 또한 **실시간 대시보드**가 제공됩니다. 웹 콘솔에서 그래프로 한눈에 현황을 파악할 수 있습니다. 무엇보다 **과거 데이터 보관**이라는 큰 이점이 있습니다. 문제가 생기면 과거로 돌아가서 언제부터 시작됐는지 확인할 수 있습니다. 핵심 모니터링 메트릭을 살펴봅시다. **CPU 사용률**은 가장 기본적인 지표입니다. 80%를 넘어가면 성능 저하가 시작되고, 100%에 도달하면 응답이 느려집니다. **메모리 사용률**도 중요합니다. 메모리가 부족하면 프로세스가 강제 종료될 수 있습니다. **네트워크 처리량**을 보면 트래픽 패턴을 이해할 수 있습니다. 갑작스러운 증가는 공격 징후일 수도 있습니다. **실행 중인 태스크 수**를 추적하면 오토스케일링이 제대로 작동하는지 확인할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 9-10번째 줄에서 알람의 이름과 설명을 지정합니다. 나중에 알림을 받았을 때 무엇에 대한 알림인지 바로 알 수 있도록 명확하게 작성하세요. 11-13번째 줄에서 모니터링할 메트릭을 지정합니다. CPUUtilization을 평균값으로 측정합니다. 14-16번째 줄이 핵심입니다. 5분 동안의 평균값을 측정하고, 80%를 2번 연속 초과하면 알람을 발생시킵니다. 한 번만 초과했다가 내려가는 일시적 스파이크는 무시합니다. 실무에서 꼭 설정해야 할 알람들을 소개합니다. **CPU 고사용률 알람**: 80% 이상이 지속되면 스케일 아웃을 고려해야 합니다. **메모리 고사용률 알람**: 90% 이상이면 OOM(Out of Memory) 위험이 있습니다. **태스크 실패 알람**: 태스크가 계속 실패하고 재시작되면 코드에 문제가 있을 가능성이 큽니다. **응답 시간 알람**: API 응답 시간이 평소보다 2배 이상 느려지면 조사가 필요합니다. CloudWatch Logs도 중요한 모니터링 도구입니다. 애플리케이션 로그를 CloudWatch Logs로 전송하면 중앙에서 모든 로그를 확인할 수 있습니다. 여러 컨테이너에서 발생한 로그를 한곳에서 검색하고 분석할 수 있습니다. 에러 로그를 기반으로 알람을 설정할 수도 있습니다. "ERROR" 문자열이 1분에 10번 이상 나타나면 알림을 보내는 식입니다. **CloudWatch Insights 쿼리**를 활용하면 더욱 강력합니다. SQL과 유사한 쿼리 언어로 로그를 분석할 수 있습니다. "지난 1시간 동안 가장 많이 발생한 에러 TOP 10"을 찾거나, "특정 사용자의 모든 요청 로그"를 추적할 수 있습니다. 문제 해결에 큰 도움이 됩니다. 실무에서는 **대시보드**를 만들어 사용합니다. 중요한 메트릭들을 한 화면에 모아서 대시보드를 구성합니다. 출근하자마자, 그리고 주기적으로 대시보드를 확인하는 습관을 들이면 문제를 조기에 발견할 수 있습니다. 팀 전체가 같은 대시보드를 보면 상황 공유도 쉬워집니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 알람을 설정하는 것입니다. "혹시 몰라서" 모든 메트릭에 알람을 걸어두면, 하루에도 수십 개의 알림이 옵니다. **알람 피로(alert fatigue)** 현상이 발생해서 정작 중요한 알림을 놓치게 됩니다. 정말 중요한 것만 알람으로 설정하고, 나머지는 대시보드로 확인하세요. 또 다른 실수는 임계값을 너무 낮게 설정하는 것입니다. CPU 사용률 50% 알람을 설정하면 하루 종일 알림이 올 것입니다. 실제 문제가 되는 수준에서 알람이 울리도록 임계값을 조정하세요. 초기에는 높게 설정하고, 운영하면서 점진적으로 낮추는 것이 좋습니다. **알림 채널**도 신중하게 선택해야 합니다. 중요한 알람은 SMS나 전화로 받고, 덜 중요한 알람은 이메일이나 슬랙으로 받습니다. 새벽 2시에 중요하지 않은 알림으로 깨어나는 일이 없도록 설정하세요. 온콜(on-call) 일정을 정해서 담당자를 순환하는 것도 좋은 방법입니다. 비용도 고려해야 합니다. CloudWatch는 메트릭 개수, 로그 저장량, 알람 개수에 따라 비용이 발생합니다. 불필요한 로그는 빨리 삭제하고, 중요한 로그만 장기 보관하세요. 로그 보관 기간을 7일, 30일, 90일 등으로 구분해서 설정하면 비용을 절감할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 모니터링을 설정한 후 김개발 씨는 한결 안심하게 되었습니다. 어느 날 오전, CPU 사용률 알람이 울렸습니다. 문제가 커지기 전에 발견해서 빠르게 대응할 수 있었습니다. "모니터링이 이렇게 중요한 거였구나!" 제대로 된 모니터링은 안정적인 서비스 운영의 기본입니다. 처음에는 설정이 번거로워 보이지만, 한 번 제대로 구축해두면 장기적으로 큰 도움이 됩니다. 여러분도 오늘 배운 내용을 바탕으로 모니터링 체계를 구축해 보세요. **실전 팁** 💡 - **핵심 메트릭 우선**: CPU, 메모리, 태스크 실패율 같은 핵심 지표부터 모니터링하세요 - **알람은 선택적으로**: 정말 중요한 것만 알람으로 설정해서 피로도를 줄이세요 - **대시보드 공유**: 팀 전체가 같은 대시보드를 보면 상황 인식이 빨라집니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, ECS, Fargate, Docker, Container

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS ECS 클러스터 생성 완벽 가이드

목차

1. ECS란 무엇인가

2. Fargate vs EC2 시작 유형

3. 클러스터 생성하기

4. 클러스터 설정 옵션

5. 용량 공급자

6. 클러스터 모니터링

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

쿠버네티스 아키텍처 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드