[AWS] 컨테이너 오케스트레이션 서비스로 비용절감하는 법

AWS에서 제공하는 컨테이너 서비스인

Amazon ECS와 Amazon EKS를 사용하는 개발자들은

컨테이너 환경에서 슬기롭게 생활한다.

이번 세션에서는 AWS에서 컨테이너 서비스를 보다 잘 활용할 수 있는 방법들을 전수받고왔다.

먼저 컨테이너 오케스트레이션 서비스에 대해 알아보도록하자.

 

컨테이너 오케스트레이션 서비스는 마치 내집 마련을 하는 것과 같다.

AWS에서는 Amazon ECS와 Amazon EKS를 제공한다.

Amazon ECS는 완전히 관리되는 컨테이너 오케스트레이션 서비스로,

간단하게 애플리케이션을 배포하고 관리할 수 있다.

Amazon EKS는 Kubernetes를 사용하는 컨테이너 오케스트레이션 서비스로,

보다 유연하고 안정적인 컨테이너 환경을 제공한다.

이미지 사이즈를 줄이는 방법

이미지가 작아야 하는 이유는 빠른 배포와 자원 사용 최적화를 위해서이다.

이미지 사이즈를 줄이는 방법으로는 레이어를 줄이는 것이 가장 중요하다.

레이어를 줄이는 방법으로는 add, run, **copy**를 활용하는 것과

and 절로 줄이는 것이 있다.

또한 멀티스테이지 빌드를 활용하면 필요한

아티펙트만 최종 이미지에 복사하여 이미지 사이즈를 최적화할 수 있습니다.

이미지 사이즈를 최적화하는 예제 코드: 코틀린 스프링을 이용하여 Dockerfile을 작성함

# build stage
FROM gradle:7.3.3-jdk11 AS build

# set working directory
WORKDIR /app

# copy source code
COPY . .

# build application
RUN gradle clean build --no-daemon

# production stage
FROM openjdk:11.0.13-jdk-slim-buster

# set working directory
WORKDIR /app

# copy built application from build stage
COPY --from=build /app/build/libs/app.jar .

# set environment variables
ENV SPRING_PROFILES_ACTIVE=production

# expose port
EXPOSE 8080

# start application
CMD ["java", "-jar", "app.jar"]

이 코드는 두 개의 스테이지로 구성되어 있다.

첫 번째 스테이지(build stage)에서는 Gradle을 이용하여 애플리케이션을 빌드한다.

빌드를 위해 필요한 소스 코드와 빌드 스크립트 등을 복사한 후,

gradle clean build 명령어를 실행하여 애플리케이션을 빌드한다.

-no-daemon 옵션을 사용하여 빌드 시에 Gradle 데몬을 사용하지 않도록 설정한다.

두 번째 스테이지(production stage)에서는 실행에 필요한

최소한의 종속성만을 포함하는 Slim Buster 기반 이미지를 사용한다.

이를 통해 불필요한 파일이나 라이브러리 등이 제거되어 이미지 사이즈를 줄일 수 있다.

또한 위 Dockerfile에서는 COPY --from 명령을 사용하여

첫 번째 스테이지에서 빌드된 애플리케이션 코드만을 두 번째 스테이지로 복사한다.

이를 통해 최종 이미지에는 불필요한 파일이나 라이브러리가 포함되지 않도록 한다.

마지막으로, SPRING_PROFILES_ACTIVE 환경 변수를 설정하여

애플리케이션이 실행될 환경을 지정하고,

java -jar app.jar 명령어를 사용하여 애플리케이션을 실행한다.

컨테이너 배포 꿀팁

Amazon ECS에서는 배포 옵션을 조정하고,

최소/최대 실행 가능한 task 수를 조절하고,

헬스체크를 조정하여 배포를 보다 원활하게 할 수 있다.

컨테이너 워크로드에 대한 관측을 위해 로그와 메트릭(APM)을 수집하는 것이 필요하다.

Amazon ECS에서는 awslog와 awsfirelens를 사용하여 로그를 수집할 수 있고,

Amazon EKS에서는 control plane과 awsfirelens를 사용하여 로그를 수집할 수 있다.

또한 프로메테우스를 활용하여 로그와 메트릭을 수집할 수 있다.

 

이를 위해서는 open telemetry 또는

AWS의 **Application Discovery and Profiling Tools(ADOT)**를 사용할 수 있다.

컨테이너 오케스트레이션 서비스

AWS의 컨테이너 서비스 중 Amazon ECS와 Amazon EKS를 활용하여

컨테이너 환경에서 스마트한 운영을 하기 위해서는 여러 가지 요소를 고려해야한다.

먼저, 컨테이너 오케스트레이션 서비스를 활용하여 내집 마련을 할 수 있다.

ECS는 Control Plane을 제공하며, EKS는 Kubernetes의

유연성과 완전 관리형 서비스를 제공한다.

이미지 사이즈를 줄이는 것은 빠른 배포 시간과 자원 사용 최적화에 매우 중요하다.

이미지를 작게 만드는 방법으로는 도커 공식 이미지를 사용하거나,

 

Alpine이나 Slim 이미지를 고려할 수 있다.

또한, 레이어를 줄이기 위해 add, run, copy를 활용하고,

and 절로 줄이는 등의 멀티스테이지 빌드를 적용할 수 있다.

컨테이너 배포에 있어서는 ECS의 development 옵션 조정과

최소/최대 실행 task, 헬스체크 조정 등을 고려해야 한다.

컨테이너 워크로드에 대한 관측을 위해 로그와 메트릭(성능 지표) 수집이 중요하다.

 

Log 수집에는 ECS에서는 awslog, awsfirelens,

EKS에서는 control plane, awsfirelens를 활용할 수 있고

서드 파티 솔루션으로 보낼 수도 있다.

Metric 수집은 사용률, 작업 비율, 오류 횟수와 같은

기본적인 지표와 초당 요청 수, 초당 실패한 요청 수,

각 요청에 걸리는 시간과 같은 빨간 지표를 고려해야 한다.

CloudWatch Agent나 Prometheus를 활용하여 수집할 수 있으며,

OpenTelemetry나 ADOT 등을 활용하여 다양하게 통합이 가능하다.

Trace는 AWS X-Ray를 활용하여 수집할 수 있다.

 

비용 최적화를 위해서는 ECS와 EKS에서 tagging을 잘하고,

cost Explorer와 AWS Cost Usage Report (CUR)를 활용할 수 있다.

EKS의 경우, 심층적인 추적이 까다롭기 때문에

kubecost for Amazon EKS나 Prometheus 서버를 손봐야 하지만 필수이다…