ECS 톺아보기

1. ECS로의 전환 이유

기존 인프라 구성

기존 인프라의 문제점

1. 새로운 타이어 커머스 API 서버를 위한 서버 환경을 다시 구성해야했고,

2. MVP인 타이어 커머스 API 서버의 자원 사용량이 크지 않음에도 인스턴스 하나를 통째로 사용해야했으며,

3. Terraform으로는 EC2 오토스케일링 그룹에 대한 CodeDeploy 블루/그린 배포 방식을 관리할 수 없다

ECS의 장점

1. 공개된 이미지들에 몇가지 설정만을 더하는 방식으로 쉽게 환경을 구성할 수 있고,

2. 0.25vCPU, 256MB 메모리 등, 작은 단위로 자원을 분배할 수 있며,

3. Terraform으로 ECS에 대한 CodeDeploy 블루/그린 배포 방식을 관리할 수 있기 때문에

2. ECS 기본 개념

클러스터(Cluster)

용량 공급자(Capacity Provider)와 용량 공급자 전략 (Capacity Provider Strategy)

용량 공급자

용량 공급자 전략

작업 정의(Task Definition)와 작업(Task)

네트워크 모드

환경 변수

작업 역할(Task Role)과 작업 실행 역할(Task Execution Role)

서비스(Service)

ECR 이미지 저장소(ECR Repository)

3. ECS로 서비스 출시하기

ECS 클러스터 생성

ECS 클러스터 생성

오토스케일링 그룹 생성

#!bin/bash
echo Configuring ECS agent...
sudo cat > /etc/ecs/ecs.config <<EOF
ECS_CLUSTER=[ECS 클러스터명]
EOF

오토스케일링 그룹을 ECS 클러스터 용량공급자로 등록

컨테이너별 Dockerfile 작성

project root
├── taskdef.json
├── buildspec.yml
├── appspec.yml
├── nginx (Nginx 컨테이너)
│		├── Dokerfile
|		└── nginx.conf
└── app (애플리케이션 컨테이너)
		├── Dockerfile
		├── package.json
		└── src
				├── main.ts
				└── ...

FROM node:14 AS builder
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build

FROM node:14-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json

EXPOSE 8081
ENTRYPOINT ["node", "dist/main"]

FROM nginx:stable-alpine
COPY ./nginx.conf /etc/nginx/nginx.conf

EXPOSE 80
ENTRYPOINT ["nginx", "-g", "daemon off;"]

ECR 이미지 저장소 생성

• aws ecr get-login-password --region ap-northeast-2
ECR 레지스트리에 로그인 할 수 있는 비밀번호를 출력합니다. 이 명령어를 실행하기 위해서는 로컬 환경의 AWS CLI에 부여된 자격 증명에 ecr:GetAuthorizationToken 액션 실행 권한이 포함되어 있어야합니다. AWS CLI에 부여될 자격 증명을 관리하는 방법은 AWS 문서를 참조하세요.

• docker login --username AWS --password-stdin [ECR 레지스트리 URL]
이전 명령어로 발급 받은 비밀번호를 통해 docker CLI가 ECR 레지스트리에 접근 가능하도록 로그인시킵니다.

• docker build -t [이미지명] [Dockerfile이 포함된 디렉토리 path]
도커 이미지를 빌드합니다.

• docker tag dev-drcha-app:latest [ECR 이미지 저장소 URL]:latest
이전 명령어를 통해 빌드한 이미지가 ECR 이미지 저장소에 latest 태그로 저장될 수 있도록 이미지에 latest 태그를 붙입니다.

• docker push [ECR 이미지 저장소 URL]:latest
latest 태그를 붙인 이미지를 ECR 이미지 저장소에 푸시합니다.

taskdef.json 작성

{
  "family": "sample-application-task-definition",
  "networkMode": "awsvpc",
  "cpu": "640",
  "memory": "1152",
  "taskRoleArn": "<TASK_ROLE_ARN>",
  "executionRoleArn": "<TASK_EXECUTION_ROLE_ARN>",
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "<NGINX_IMAGE_URL>",
      "essential": true,
      "cpu": 128,
      "memory": 128,
      "portMappings": [
        {
          "protocol": "tcp",
          "hostPort": 80,
          "containerPort": 80
        }
      ],
			"environment": [
        {
          "name": "[환경 변수명]",
          "value": "[환경 변수값]"
        }
      ],
      "environmentFiles": [
        {
          "type": "s3",
          "value": "[S3 환경 변수 객체 ARN]"
        }
      ],
      "secrets": [
        {
          "name": "[환경 변수명]",
          "valueFrom": "[환경 변수값이 저장된 AWS Secrets Manager secret, 또는 AWS System Manager 파라미터 스토어 파라미터 ARN]"
        }
      ]
    },
    {
      "name": "app",
      "image": "<APPLICATION_IMAGE_URL>",
      "essential": true,
      "cpu": 512,
      "memory": 1024,
      "portMappings": [],
		  "environment": [
        {
          "name": "[환경 변수명]",
          "value": "[환경 변수값]"
        }
      ],
      "environmentFiles": [
        {
          "type": "s3",
          "value": "[S3 환경 변수 객체 ARN]"
        }
      ],
      "secrets": [
        {
          "name": "[환경 변수명]",
          "valueFrom": "[환경 변수값이 저장된 AWS Secrets Manager secret, 또는 AWS System Manager 파라미터 스토어 파라미터 ARN]"
        }
      ]
    }
  ]
}

• family: taskdef.json 파일을 바탕으로 생성될 작업 정의의 패밀리명입니다. 프로젝트명에 맞게 자유롭게 작성하시면 됩니다.

• networkMode: 작업의 네트워크 모드. 앞서 설명하였듯, 특별한 이유가 없는 경우 awsvpc 모드를 사용하는 것이 좋습니다.

• cpu, memory: 작업에서 사용할 CPU와 메모리 자원량. cpu의 경우 1024가 1vCPU에 해당하며, memory의 단위는 MiB입니다. 작업의 자원량은 작업의 모든 컨테이너에 부여된 자원량의 합보다 커야합니다. 문자열로 입력해야합니다.

• taskRoleArn, executionRoleArn: 작업 IAM 역할 ARN과 작업 실행 IAM 역할 ARN입니다. 아직 두 역할을 생성하지 않았으니, 일단은 비워둡니다.

• containerDefinitions: 작업에서 실행할 컨테이너 정의 목록.
• name: 컨테이너명. 이번 글에서는 애플리케이션 컨테이너와 nginx 컨테이너를 한 작업에서 실행하므로, nginx와 app으로 설정하였습니다.
• image: 컨테이너에서 실행할 이미지 URL. 이전 단계에서 빌드해 ECR 이미지 장소에 latest 태그를 붙여 푸시한 이미지 URL을 입력합니다.
• essential: 이 필드가 true로 설정된 컨테이너 실행에 실패하면 작업 전체가 실행에 실패합니다. 이 필드가 false로 설정된 컨테이너 실행에 실패하더라도 작업은 실행에 성공합니다. 한 작업에는 최소한 하나의 essential 컨테이너가 포함되어야합니다. 이 경우 애플리케이션을 정상적으로 실행하기 위해서는 Nginx와 애플리케이션 컨테이너가 모두 실행되어야하므로 모든 컨테이너를 essential 컨테이너로 설정합니다.
• cpu, memory: 컨테이너에서 사용할 CPU와 메모리 자원량입니다. 단위는 작업의 단위와 같습니다. 그러나, 컨테이너의 자원량은 문자열이 아닌 정수로 입력해야합니다.
• portMapping: 네트워크 인터페이스(hostPort)와 컨테이너(containerPort) 간에 매핑할 포트 목록입니다. awsvpc 네트워크 모드의 경우, 네트워크 인터페이스와 컨테이너의 포트를 다르게 설정할 수 없습니다. 또한 awsvpc 네트워크 모드의 경우, 컨테이너 간 네트워크 연결을 위해 별도의 포트 매핑을 설정할 필요가 없습니다. 작업의 모든 컨테이너에 같은 네트워크 인터페이스가 연결되므로, 로컬 호스트에 포트를 지정해 다른 컨테이너와 네트워크 연결을 만들 수 있습니다. 따라서, 하나의 작업에 포함된 컨테이너들이 모두 다른 포트를 사용해야합니다. 이번 글에서는 Nginx 컨테이너의 80번 포트만 외부로 노출하고, Nginx 컨테이너의 80번 포트로의 요청을 애플리케이션 컨테이너에서 사용하는 포트로 전달하도록 Nginx를 설정합니다.
• environment: 컨테이너가 실행되는 환경의 환경 변수 목록입니다. taskdef.json 파일 또한 깃허브 등에 올라가므로, API key와 같은 민감 정보는 이 필드로 전달하면 안됩니다.
• environmentFiles: 환경 변수들을 담은 파일을 통해 환경 변수를 설정할 수 있습니다. 현재 지원되는 유일한 파일 유형은 S3 객체입니다. value 필드에는 S3 객체의 ARN을 입력합니다.
• secrets: 민감 정보를 환경 변수로 전달할 때 사용합니다. AWS Secrets Manager의 secert이나, AWS System Manager의 파라미터 스토어 내 파라미터로부터 값을 가져올 수 있습니다. valueFrom 필드에 입력할 값은 AWS 문서를 참조하세요.

작업 IAM 역할 및 작업 실행 IAM 역할 생성

1. ECR 이미지 저장소 접근 및 이미지 다운로드 권한.

{
	  "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "ecr:GetAuthorizationToken",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
            ],
            "Effect": "Allow",
            "Resource": [
                "[ECR Nginx이미지 저장소 ARN]",
                "[ECR 애플리케이션 이미지 저장소 ARN]"
            ]
        }
    ]
}

2. 환경 변수 파일 S3 객체 접근 권한 (environmentFiles 필드를 사용할 경우)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "s3:GetBucketLocation",
            "Effect": "Allow",
            "Resource": [
							"[환경 변수 파일이 저장된 S3 버킷 ARN]"
						]
        },
        {
            "Action": "s3:GetObject",
            "Effect": "Allow",
            "Resource": [
							"[환경 변수 파일 S3 객체 ARN]"
						]
        }
    ]
}

3. 환경 변수로 사용할 민감 정보를 가진 Secrets Manager secret, 또는 System Manager parameter 접근 권한. (secrets 필드를 사용할 경우)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "secretsmanager:GetSecretValue",
            "Effect": "Allow",
            "Resource": [
							"[Secrets Manager secret ARN]"
						]
        },
				{
						"Action": "ssm:GetParameters",
						"Effect": "Allow",
						"Resource": [
							"[System Manager parameter ARN]"
						]
				}
    ]
}

ECS 작업 정의 및 서비스 생성

작업 정의 생성

서비스 생성 (서비스 기본 설정)

서비스 생성 (로드밸런서 설정)

서비스 생성 (오토스케일링 설정)

서비스 생성 완료

4. 소소한 팁

ECS 모범 사례

• 컨테이너 이미지의 크기를 최대한 작게 유지하라.

• 컨테이너 이미지 하나에서는 하나의 프로세스만 실행하라. 프로세스에 문제가 생겨 정지 되었을 때 이를 재실행하는 것은 컨테이너 내부에서 담당해서는 안되고, ECS가 컨테이너 단위로 관리해야한다.

• 컨테이너 이미지의 latest 태그 사용을 지양하고, Git 커밋 ID등을 이미지 태그로 활용하라.

• 애플리케이션이 SIGTERM을 처리하도록 하여 ECS가 SIGTERM을 통해 애플리케이션을 종료 시킬 때 데이터베이스 커넥션을 끊는 등 필요한 조치를 취하도록 하라.

블루/그린 배포 시 클러스터 여유 리소스 확보

CI/CD 파이프라인

복수의 컨테이너 관리

1. Git 커밋 ID를 컨테이너 이미지 태그로 사용해야하는데, 프로젝트 하나에 여러 컨테이너가 포함되므로 컨테이너 이미지 태그 설정 기준이 변경 되어야 합니다.

2. 사이드카 컨테이너는 거의 변경되지 않는데, 애플리케이션 컨테이너가 변경될 때마다 사이드카 컨테이너도 빌드 해야 합니다. 빌드 시간이 불필요하게 길어집니다.

• 애플리케이션 컨테이너의 이미지 태그로 Git 커밋 ID를 사용한다.

• 사이드카 컨테이너의 경우 보통 디렉토리내 내용이 설정 파일들 뿐으로 크지 않다. 그러므로 디렉토리 내 모든 파일의 해시값을 컨테이너 이미지 태그로 사용한다.

• 빌드 시에 애플리케이션 컨테이너는 항상 빌드하고, 사이드카 컨테이너의 경우 해시값을 계산한 후, 해당 해시값을 태그로 같는 이미지가 이미 이미지 저장소에 존재하는지 확인한다. 존재한다면 사이드카 컨테이너는 변경 사항이 없는 것이므로 빌드하지 않고, 존재하는 이미지를 사용한다. 존재하지 않는다면 사이드카 컨테이너에 변경 사항이 생긴 것이므로 새로 빌드하여 이미지 저장소에 업로드한다.

5. 마치며 — 다음엔 같이해요