1. 개요
클라우드 환경에서 비용 효율적인 Docker 기반의 분석 파이프라인을 구성하려면, 자동 확장 및 필요한 리소스를 유동적으로 사용하는 방식이 필수적입니다. AWS와 GCP와 같은 클라우드 서비스는 EKS (Elastic Kubernetes Service)와 Spot Instances, 또는 Preemptible VMs와 같은 저비용 인스턴스를 통해 이러한 요구를 충족시킬 수 있습니다. 이 글에서는 AWS와 EKS를 사용하여 Docker 기반의 분석 파이프라인을 구성하고, 비용을 최소화하는 방법을 설명합니다. 또한, 여러 Docker 이미지를 사용하는 경우와 하나의 Docker 이미지로 결합하는 경우의 장단점에 대해 논의하고, Argo Workflows를 사용한 워크플로우 자동화 방법도 다룹니다.
2. AWS에서 Docker 기반 파이프라인 구성 및 비용 절감 방안
AWS는 EKS (Elastic Kubernetes Service)를 통해 Docker 기반의 파이프라인을 유연하게 관리할 수 있으며, 필요한 컴퓨팅 자원을 효율적으로 사용할 수 있도록 도와줍니다. 또한, Spot Instances를 활용하여 비용을 절감할 수 있습니다.
2.1. AWS EKS와 Spot Instances 사용
EKS는 AWS에서 관리형 Kubernetes 서비스를 제공하여 Docker 컨테이너의 배포 및 관리를 쉽게 할 수 있습니다. EKS를 사용하면 Spot Instances와 같은 저비용 인스턴스를 활용해 비용을 절감할 수 있습니다. Spot Instances는 AWS에서 남는 자원을 저렴한 가격에 제공하는 방식으로, 최대 90%까지 비용을 절감할 수 있습니다. 이때, Auto Scaling을 통해 클러스터의 리소스를 유연하게 확장 및 축소할 수 있습니다.
2.2. AWS Fargate 사용
작업이 짧고 일시적인 경우, AWS Fargate를 사용하여 서버리스 환경에서 Docker 컨테이너를 실행하는 것이 비용 절감에 유리할 수 있습니다. Fargate는 EC2 인스턴스를 직접 관리할 필요 없이, 작업량에 따라 자동으로 리소스를 할당하고 종료하므로 필요한 만큼만 비용을 지불하게 됩니다.
3. 여러 Docker 이미지를 사용하는 방식 vs 하나의 Docker 이미지로 결합
Docker 기반의 분석 파이프라인을 구성할 때, 파이프라인의 각 단계를 별도의 Docker 이미지로 나누어 관리할지, 아니면 하나의 Docker 이미지로 통합할지 선택할 수 있습니다. 이 두 가지 방식은 각각의 장단점이 있습니다.
3.1. 여러 Docker 이미지를 사용하는 경우
장점:
- 모듈화: 각 단계가 독립적으로 관리되므로, 특정 단계에 대한 변경 사항이 생겼을 때 개별 이미지만 수정하면 됩니다. 파이프라인이 유연하게 확장됩니다.
- 의존성 충돌 방지: 각 Docker 이미지마다 다른 라이브러리와 환경 설정을 사용하여 의존성 충돌을 방지할 수 있습니다.
- 스케일링 최적화: 각 단계마다 리소스 사용량이 다르다면, 단계별로 리소스를 조정하여 효율적으로 운영할 수 있습니다.
- 병렬 처리 가능: 파이프라인의 여러 작업을 동시에 처리할 수 있습니다.
단점:
- 복잡성 증가: 여러 Docker 이미지를 관리해야 하므로 빌드, 배포, 버전 관리가 복잡해질 수 있습니다.
- 데이터 전달 필요: 각 단계 간의 데이터를 외부 스토리지(S3, EFS 등)를 통해 주고받아야 할 경우 데이터 전달 설정이 필요합니다.
- 네트워크 비용 증가 가능성: 컨테이너 간 통신이나 데이터 전달이 빈번할 경우 네트워크 비용이 증가할 수 있습니다.
3.2. 하나의 Docker 이미지로 결합하는 경우
장점:
- 단순화: 모든 파이프라인 단계를 하나의 Docker 이미지로 통합하면, 빌드와 배포가 단순해집니다.
- 빠른 데이터 처리: 데이터가 같은 컨테이너 내에서 처리되므로, 외부 데이터 전달이 필요 없고, 처리 속도가 빨라질 수 있습니다.
- 데이터 관리 용이: 데이터가 한 컨테이너 내부에서 처리되므로, 외부 저장소나 데이터 전달 방식을 고려할 필요가 적습니다.
단점:
- 의존성 관리 어려움: 여러 단계가 하나의 Docker 이미지 내에 포함되므로, 서로 다른 라이브러리나 환경을 관리하는 데 어려움이 있을 수 있습니다.
- 확장성 제한: 단계별로 리소스를 최적화하기 어렵습니다. 파이프라인의 일부 단계에서 리소스를 많이 요구하더라도, 개별적으로 조정할 수 없습니다.
- 유지보수 어려움: 파이프라인의 일부가 변경되면 전체 이미지를 다시 빌드하고 배포해야 하므로 비효율적일 수 있습니다.
4. Argo Workflows를 통한 자동화된 파이프라인 관리
Argo Workflows는 Kubernetes 기반의 워크플로우 관리 도구로, 복잡한 파이프라인을 체계적으로 관리하고 자동화할 수 있도록 돕습니다. 특히 Argo Workflows는 여러 단계로 나뉜 작업의 의존성을 관리하고, 순차적 또는 병렬적으로 실행할 수 있는 기능을 제공합니다.
4.1. Argo Workflows에서 여러 Docker 이미지 사용
Argo Workflows에서는 여러 Docker 이미지를 활용하여 각 단계별로 컨테이너를 실행할 수 있습니다. 이를 통해 여러 작업을 병렬 또는 순차적으로 처리할 수 있습니다.
Argo Workflows 예시: Job 간 의존성 설정
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: pipeline-
spec:
entrypoint: main
templates:
- name: main
steps:
- - name: preprocessing
template: preprocessing-job
- - name: analysis
template: analysis-job
- - name: postprocessing
template: postprocessing-job
- name: preprocessing-job
container:
image: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-preprocessing:latest
command: ["python", "preprocessing.py"]
- name: analysis-job
container:
image: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-analysis:latest
command: ["python", "analysis.py"]
- name: postprocessing-job
container:
image: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-postprocessing:latest
command: ["python", "postprocessing.py"]이 예시는 Argo Workflows에서 여러 Docker 이미지를 사용하여 Preprocessing, Analysis, Postprocessing을 순차적으로 실행하는 방식입니다. 각 작업이 완료되면 다음 작업이 실행됩니다.
5. Argo Workflows에서 스토리지 마운트 사용
Argo Workflows는 Kubernetes 기반으로 동작하기 때문에, Persistent Volume (PV)와 Persistent Volume Claim (PVC) 또는 외부 스토리지를 사용하여 데이터를 공유할 수 있습니다.
5.1. PVC 마운트 사용 예시
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: pvc-workflow-
spec:
entrypoint: main
volumeClaimTemplates:
- metadata:
name: workflow-pvc
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 5Gi
templates:
- name: main
steps:
- - name: preprocess
template: preprocess
- - name: analyze
template: analyze
- name: preprocess
script:
image: python:3.8
command: [python]
source: |
with open('/mnt/data/preprocessed.txt', 'w') as f:
f.write('Preprocessed data')
volumeMounts:
- name: workflow-pvc
mountPath: /mnt/data
- name: analyze
script:
image: python:3.8
command: [python]
source: |
with open('/mnt/data/preprocessed.txt', 'r') as f:
print(f.read())
volumeMounts:
- name: workflow-pvc
mountPath: /mnt/data이 예시는 Persistent Volume Claim (PVC)를 사용하여 여러 단계 간 데이터를 공유하는 방식입니다.
5.2. 외부 스토리지 (S3) 사용 예시
Argo Workflows에서 S3와 같은 외부 스토리지를 활용하여 데이터를 주고받을 수 있습니다. 이를 위해 AWS CLI나 Boto3와 같은 SDK를 사용합니다.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: s3-workflow-
spec:
entrypoint: main
templates:
- name: main
steps:
- - name: preprocess
template: preprocess
- - name: analyze
template: analyze
- name: preprocess
script:
image: amazon/aws-cli
command: [sh, -c]
source: |
echo "Preprocessing data" > /tmp/data.txt
aws s3 cp /tmp/data.txt s3://my-bucket/preprocessed_data.txt
- name: analyze
script:
image: amazon/aws-cli
command: [sh, -c]
source: |
aws s3 cp s3://my-bucket/preprocessed_data.txt /tmp/data.txt
cat /tmp/data.txt이 예시는 데이터를 S3에 업로드하고, 다음 단계에서 다시 S3에서 다운로드하여 사용하는 방식입니다.
6. 결론
AWS EKS를 사용하여 Docker 기반의 파이프라인을 구성하는 것은 비용 효율적이고 확장 가능한 솔루션을 제공합니다. Spot Instances나 Fargate를 활용하면 비용을 최소화할 수 있으며, Argo Workflows는 복잡한 파이프라인을 자동화하고 관리하는 데 매우 유용합니다. 파이프라인을 구성할 때 여러 Docker 이미지를 사용할지, 하나의 Docker 이미지로 통합할지는 파이프라인의 복잡성과 요구사항에 따라 결정할 수 있습니다. 또한, Argo Workflows를 통해 저장소 마운트를 활용하거나 외부 스토리지를 사용하여 데이터를 유연하게 관리할 수 있습니다.
이 블로그 글을 통해 클라우드 환경에서 Docker 기반 파이프라인을 구성하고, Argo Workflows를 활용하여 자동화하는 방법을 이해하는 데 도움이 되기를 바랍니다.
'Computer Science > linux' 카테고리의 다른 글
| 작업량 기반 노드 배정 설명: 공용 노드와 작업량에 기반한 개인 또는 프로젝트별 노드 배정 전략 (0) | 2024.10.14 |
|---|---|
| GNU Parallel: 정의, 사용법, 그리고 예시 (1) | 2024.10.02 |
| 프롬프트 스트링 (1) | 2024.09.24 |
| Argo workflow 설치와 예제 (0) | 2024.09.22 |
| Docker Compose 사용하기 (0) | 2024.09.20 |