[AWS] 정산 배치 아키텍처 설계

1. 정산 배치 아키텍처 조사 목적

기존 배치 방식의 비효율성

위 CPU 모니터링의 예 처럼 배치 작업은 특정 시간에만 동작하여 그 외의 시간은 놀고있는다는 특징이 있습니다. 이러한 특징때문인지 기존 시스템에선 배치를 togle_order Application에 REST API 형태로 구성하였고, 특정 시간마다 Jenkins에서 배치 REST API를 호출하는 방식을 사용한 것으로 보여집니다.

어드민 시스템 같은 사용량이 적은 어플리케이션이였다면 문제가 크지 않겠지만, 기존 방식엔 크고 작은 단점들이 몇 가지 존재합니다.

단점 1. 해당 배치가 돌 것을 대비하여 Application에 최악의 상황을 고려하여, 필요 이상의 서버와 DB ConnectionPool 관련된 자원이 할당되어야 합니다. 그리하여 빌드하는데 소요되는 시간도 더욱 오래 걸리게 됩니다.

단점 2. Application에 문제가 생기면 Application을 비롯한 배치 시스템에 같이 문제가 생깁니다.

단점 3. 정형화된 방식이 아니기 때문에 Jenkins 설정부터 시작하여 흩어진 Jenkins Script를 찾아 봐야하기 때문에 익숙하지 않은 사람이 관리하기엔 다소 어려움이 있을 수 있습니다.

단점 4. 현재 Application과 배치 프로세스가 한 프로젝트에 있기 때문에 배포하는데 부담이 커진다는 단점이 있습니다.

비용

단점 1과 연관된 내용입니다. togle_order Application의 덩어리가 필요 이상으로 커지면서 최악의 상황을 고려해 필요 이상의 자원을 할당하게 됩니다. 또한 해당 Application은 24시간 동작하는 상태를 유지해야 하므로 필요 이상의 자원을 24시간 유지할 수 밖에 없게 됩니다.

---

2. 선택 가능한 아키텍처

1. On Demand 전략

ECR, EC2, AWS Batch와 같은 기능들을 사용하여, 필요할 때만 어플리케이션을 실행시키는 전략

장점

1. 사용하는 만큼 비용이 발생하기 때문에 가장 적은 비용
2. job 단위로 효율적인 자원 활용이 가능
3. tasklet(기능) 단위로 어플리케이션을 실행시키는게 아니라 job, step 단위로 실행하기 때문에 어플리케이션에 장애가 발생해도 하나의 기능만 장애가 발생.
4. 주기적인 인스턴스 모니터링이 불필요

단점

1. 비교적 복잡한 구조
2. 비교적 높은 러닝커브
3. Cloud 의존적 설계

2. PreLoad 전략

24시간 배치용 인스턴스를 실행시켜두고 배치 어플리케이션을 실행해둔 상태로 사용하는 전략

장점

1. 가장 간단한 구조이므로 러닝커브가 낮음

단점

1. 24시간 인스턴스가 떠있기 때문에 시간만큼 비용이 발생하는 cloud 특성 상 비효율적 구조
2. 스케일업이 필요한 경우 인스턴스를 재구동 해야 하기 때문에 작업자가 신경쓸 부분이 많아짐
3. 주기적인 인스턴스 모니터링이 필요

3. Jenkins API 호출 (기존 방식)

Jenkins에 cron 식을 넣어 시간마다 해당 API를 호출하는 방식

장점

1. 기존 방식이기 때문에 기존 작업자들 기준으로 러닝커브가 낮음

단점

1. 24시간 인스턴스가 떠있기 때문에 시간만큼 비용이 발생하는 cloud 특성 상 비효율적 구조
2. API와 같은 Application에 batch 기능이 존재하기 때문에 서버 자원이나 connection pool 관리가 어려움
3. 장애 발생 확률이 가장 높음

4. SCDF (Spring Cloud Data Flow) + Stream 파이프라인

SCDF를 사용한 Stream 구조의 파이프라인 구축

장점

1. 파이프라인을 GUI 형태로 관리 가능하기 때문에 담당 개발자가 아니더라도 알기 쉬운 형태로 개발 가능
2. 유망한 최신기술을 체험 가능

단점

1. 참고할만한 레퍼런스가 가장 적음
2. 러닝커브 높음
3. preload 전략보다 높은 비용

---

3. 결정된 아키텍처

기존 방식과의 차이는?

1. 크론식으로 이벤트를 발행하는 역할이 Jenkins에서 EventBridge로 이동
2. 배치 프로세스가 togle_order에서 24시간 REST API 호출을 스텐바이 하던 방식에서, AWS Batch를 통해 배치가 동작하는 특정 시점에만 인스턴스를 생성하여 동작하는 방식으로 변경.

AWS Batch란?

AWS Batch는 배치 컴퓨팅 작업을 효율적으로 실행할 수 있게 도와줍니다. 배치 작업량과 리소스 요청을 기반으로 최적의 리소스 수량 및 인스턴스 유형을 동적으로 프로비저닝 합니다. AWS Batch에서는 별도의 관리가 필요 없기 때문에 문제 해결에만 집중할 수 있습니다. 별도의 추가 비용이 발생하지 않으며, 배치 작업을 저장 또는 실행할 목적으로 생성된 AWS 리소스(인스턴스 등)에 대해서만 비용을 지불하면 됩니다.

 

EC2, ECS, Fargate란?

ECS

ECS는 컨테이너의 라이프사이클을 관리하는 AWS의 컨테이너 오케스트레이션 서비스이다. 컨테이너 라이프사이클엔  'Container Start', 'Re-Schedule', 'Load Balancing' 등이 포함된다. ECS는 내부적으로 Cluster, Task, Sevice 이렇게 세 가지 메인으로 구성되어 있는데, 간단히 설명하자면 다음과 같다.

• Cluster : 여러 컨테이너의 하드웨어 리소스를 논리적으로 그룹화한 녀석이며, 컨테이너 라이프사이클을 관리한다.
• Task : VM에 어떻게 컨테이너를 배포할지 내용을 품고 있는 템플릿 메타데이터 (mem, cpu, env etc... 어떻게 배포할지)
• Service : Auto-Scaling, LB 등 컨테이너를 어떻게 배포, 실행, 관리할지 Task보다 advanced 한 설정 내용을 품고 있는 녀석
• 스케줄링 : k8s 방식으로 설명하자면, 새로 생성된 파드 중 노드가 할당되지 않은 녀석을 스케줄러가 탐지해, 해당 파드를 가동할 최적의 노드를 찾는다. 최적의 노드는 파드 배치가 가능한 노드에 일련의 Function을 돌려 스케줄러가 점수를 매기고, 가장 높은 점수의 노드를 채택한다.

위의 이미지는 ECS 컨테이너 서비스 이용한 하나의 예제이다. DockerFile을 이용해, AWS의 레포지토리 서비스인 ECR에 도커 이미지를 업로드하고, 그리고 ECR에 올라온 이미지로 ECS 컨테이너 서비스로 이미지를 컨테이너화 하여 관리할 수 있다.

ECS 외부 Repository 연동 가능 여부?

DockerHub 및 Nexus URL로 접근 가능.

EC2

컨테이너는 VM에서 동작하며, 여기서 VM이란 EC2 인스턴스가 되겠다. EC2는 컨테이너를 호스팅 역할을 하며, ECS Cluster와 연결되어 함께 동작한다. EC2에는 Docker Runtime, Container Runtime 가 있어 컨테이너를 시작할 수 있으며, ECS agent가 설치되어 있어 Control Plane인 ECS Cluster가 VM을 관리할 수 있는 것이다.

ECS with EC2를 정리하자면, EC2를 생성해야 하고, 그것을 ECS Cluster에 연결해야 하며, 새로운 컨테이너를 생성한다면 EC2 인스턴스에 충분한 리소스가 남아 있는지를 고려하고, 또한 OS 및 Docke Runtime, ECS Agent도 관리해야 한다. 물론 이 작업을 위해 유저는 그에 맞는 권한이 있는 있어야 한다.

즉, ECS with EC2는 ECS Cluster가 컨테이너 서비스를 관리해주지만 VM의 경우 사용자가 직접 신경 써줘야 하는 부분이 있다는 것이다.

하지만 이런 인프라 관리마저도 AWS에 맡기고 싶다면(컨테이너 라이프사이클, 인프라 호스팅)? 이 경우, EC2 인스턴스의 대체품으로 AWS Fargate를 고려해 볼 수 있다. Fargate는 이용하면 EC2처럼 프로비저닝 작업은 필요 없다. Fargate는 어떻게 동작할까?

Fargate

Fargate는 Task 인스턴스의 인프라 프로비저닝 관리를 자동으로 관리 해주는 서비스.

AWS 위에 동작시키고 싶은 컨테이너가 있다면 ECS Cluster에 Fargate 방식으로 배포하면 된다. Fargate는 컨테이너를 분석해 얼마만큼의 리소스가 필요한지, 자동으로 해당 컨테이너를 위해 리소스를 프로비저닝 해, 프로비저닝 된 리소스 위해 배포 및 실행한다. 이 모든 것이 다 자동이다. 새로운 컨테이너가 추가되어 Fargate에 배포하여도, Fargate는 동일하게 동작한다. 즉, EC2처럼 미리 프로비저닝 할 것이 없어 VM에 신경이 덜 쓰인다.

사용법

ECS에서 클러스터를 생성할때 온디멘드 방식, 스팟 인스턴스 방식을 선택할 수 있다.

필요할 때만 생성해서 사용하고 싶다면 스팟 인스턴스를,

인스턴스를 유지하고 해당 인스턴스에 컨테이너를 띄워 사용하고 싶다면 온디멘드 방식을 선택하면 된다.

---

On Demand 인스턴스, Spot 인스턴스, 예약 인스턴스 비용 차이

AWS에선 세 종류의 인스턴스 옵션을 제공합니다. 각 옵션별 차이를 분석하면 다음과 같습니다.

On Demand 인스턴스

사용하는 시간만큼 비용이 발생되는 일반적인 Cloud 형태의 EC2 인스턴스입니다.

예약 인스턴스

서버 비용을 미리 지불해놓고 사용하는 EC2 인스턴스입니다.

총 가격으로 보면 저렴하지만, 1년이나 3년이라는 기간동안 사용하지 않는 기간에도 요금은 계속 지불되는 특징을 가지고 있습니다.

선불, 부분선불 여부에 따라 가격이 다르지만, 온디멘드 대비 30~40% 저렴

Spot 인스턴스

스팟 인스턴스는 온디맨드 가격보다 저렴한 비용으로 사용할 수 있는 EC2 인스턴스입니다. 스팟 인스턴스는 최대 90% 할인율로 미사용 EC2 인스턴스를 요청할 수 있게 해주므로 Amazon EC2 비용을 대폭 낮출 수 있습니다.

AWS의 **스팟 인스턴스(Spot Instance)**를 사용하면 특정 워크로드에서는 인스턴스 비용을 최대 90%까지 절감할 수 있습니다.

단, 인스턴스의 남는 자원을 빌려 사용하는 개념이므로 언제든지 인스턴스가 회수당할 수 우려가 있습니다. 2분 전 회수에 대한 이벤트를 발행해주며, 그에 대한 대책은 항상 고려하고 사용해야 합니다.

온디멘드 대비 60~70% 저렴

스팟 인스턴스와 온디맨드 인스턴스의 주요 차이점

스팟 인스턴스 온디맨드 인스턴스 예약 인스턴스

가격	가장 저렴(싯가)	비쌈	저렴~중간
중단	회수당할 수 있음	내가 직접 중단	중단하거나 말거나 요금은 계속 나감
평균 사용시간	짧음	사용자가 원하는 만큼	무조건 1년 아니면 3년

스팟 인스턴스 관련 개념

주요 개념 설명

스팟 인스턴스 풀	동일한 인스턴스 유형(예: m5.large), 운영 체제, 가용 영역 및 네트워크 플랫폼을 가지는 미사용 EC2 인스턴스의 세트입니다. 즉, 사용자에게 할당되기 전 AWS에 있는 인스턴스들이라고 보시면 됩니다.
스팟 가격	스팟 인스턴스의 시간당 현재 가격입니다. 현재 가격은 https://aws.amazon.com/ko/ec2/spot/pricing/서 보시면 됩니다! 참고로 과거의 히스토리, 즉 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html로도 보실 수 있는 옵션도 있습니다.
스팟 인스턴스 요청	스팟 인스턴스를 요청합니다. 스팟 인스턴스에 대해 지불하고자 하는 시간당 최고 가격을 제공합니다. 최고 가격을 지정하지 않는 경우, 기본 최고 가격은 온디맨드 가격입니다.현재 가격이 점점 높아져서, 사용자가 "지불하고자 하는 시간당 최고 가격" 보다 현재 가격이 높아지면 그 때 스팟 인스턴스를 회수당하는 것입니다.
스팟 플릿(Fleet)	사용자가 지정한 기준을 바탕으로 시작되는 스팟 인스턴스 여러개 묶음, 즉 세트입니다. 스팟 플릿에서 목표 용량(원하는 인스턴스 갯수)를 지정하시면, 하나가 죽거나 회수당하더라도 원하는 갯수로 다시 인스턴스가 실행됩니다.AWS는 착하신 분들이라 따로 지정하지 않으면 사용자가 선택한 옵션들 중에서 가장 저렴한 인스턴스로 알아서 목표 용량을 채워줍니다. (물론 전략은 https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/spot-fleet-allocation-strategy.html 하실 수 있으세요)
스팟 인스턴스 중단	스팟 가격이 요청에 대한 최고 가격을 초과하거나 사용할 수 있는 용량이 더 이상 없는 경우 Amazon EC2는 스팟 인스턴스를 종료 또는 중지시키거나 최대 절전 모드로 전환합니다. Amazon EC2는 스팟 인스턴스 중단 공지를 통해 중지 2분 전에 이를 인스턴스에 경고합니다.

참고 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-spot-instances.html

즉, 스팟 인스턴스는 사용자가 원하지 않더라도 언제든지 회수당할 가능성이 있습니다

그러므로 스팟 인스턴스는 1) 내결함성이 있는(죽어도 되는) 애플리케이션 또는 2) 1~6시간 정도의 짧은 워크로드에 사용하기 좋습니다. 배치, 하둡, 렌더링, 크롤링, 무상태 웹 앱 등이 대표적인 사용 예시입니다.

옵션별 비용 측정

네트워크 요금

AWS Batch 요금

무료

ECR 요금

 

- 퍼블릭 리포지토리에서 전송 프라이빗 리포지토리에서 전송

수신되는 모든 데이터	0.0	0.0
데이터 송신	AWS 리전 외 위치로 5TB/월을 초과하는 경우 - GB당 0.09 USD
이외 - 0.0 USD	다음 9.999TB/월 - GB당 0.126
다음 40TB/월 - GB당 0.122 USD
다음 100TB/월 - GB당 0.117 USD
150TB 이상/월 - GB당 0.108 USD

ECS Fargate 요금

 

EC2 요금

---

결론

Fargate가 상대적으로 비싸다. 하지만 프로비저닝을 자동으로 해주므로 관리가 훨씬 수월한 편.

결론적으로 말하자면 이번 프로젝트에서 Batch는 요금 절감을 위해 AWS Batch + Fargate(스팟 인스턴스)를 사용하였고, ECS + EC2 인스턴스를 사용하여 요금을 절감할수 있었다.