왜 데이터 스페이스 비용 예측이 어려운가?
데이터 스페이스는 서로 다른 조직 간에 데이터를 안전하게 공유할 수 있는 환경입니다. Eclipse Dataspace Components(EDC) 커넥터를 AWS에 배포하면 인프라 비용을 예측하고 제어하는 것이 첫 번째 과제입니다. 명확한 벤치마크 없이는 워크로드 사이징, 환경 구성, 장기 투자 결정을 내리기 어렵죠.
이 글에서는 EDC 커넥터 배포 시 비용을 유발하는 AWS 서비스를 식별하고, 비즈니스 크리티컬 워크로드와 비크리티컬 워크로드의 월별 예상 비용을 비교합니다. 또한 최대 58% 까지 비용을 절감할 수 있는 최적화 전략을 공유합니다.
참고: 이 글은 AWS 아키텍처 블로그의 Eclipse Dataspace Components on AWS: Cost optimization strategies를 근거자료로 재구성했습니다.
데이터 스페이스 아키텍처에서 비용은 크게 두 가지로 나뉩니다. 중앙에서 관리하는 Dataspace Governance Authority(DSGA) 컴포넌트와, 각 참여자가 직접 호스팅하는 커넥터입니다. 이 글은 참여자(데이터 제공자/소비자) 측 EDC 커넥터 배포 비용에 초점을 맞춥니다.
비용 시나리오별 상세 비교
기본 가정
| 항목 | 가정 |
|---|---|
| 데이터 볼륨 | 참여자당 5 GB (6개월 이력 + 백업) |
| 네트워크 트래픽 | 참여자당 월 20 GB |
| API 호출 | 참여자당 월 100,000회 |
| OAuth 토큰 요청 | 참여자당 월 1,000회 |
| 리전 | 스페인 (eu-south-2) |
| 운영 시간 | 24/7/365 |
비즈니스 크리티컬 워크로드 (월 $387)
고가용성과 성능이 필요한 핵심 업무용 구성입니다.
| AWS 서비스 | 구성 | 월 비용 (USD) |
|---|---|---|
| Amazon Aurora PostgreSQL | db.r6g.large (2 vCPU, 16 GB), 20 GB 스토리지 + 10 GB 백업 | 276.00 |
| Amazon ECS with Fargate | 2 vCPU, 4 GB RAM, 상시 구동 | 83.00 |
| Network Load Balancer | 20 GB 처리 | 20.00 |
| AWS Secrets Manager | 10개 시크릿 | 4.00 |
| Amazon Cognito | 1K M2M 토큰 요청 | 2.25 |
| Amazon ECR | 2 GB 스토리지, 10 GB 전송 | 1.00 |
| Amazon API Gateway | 100K REST 호출 | 0.40 |
| Amazon S3 | 5 GB Standard | 0.10 |
| 합계 | 387.00 |
비크리티컬 워크로드 (월 $164)
개발/테스트/실험 환경에 적합하며, 약 58% 절감됩니다.
| AWS 서비스 | 구성 | 월 비용 (USD) |
|---|---|---|
| Amazon Aurora PostgreSQL | db.t4g.medium (2 vCPU, 4 GB), 20 GB 스토리지 + 10 GB 백업 | 110.00 |
| Amazon ECS with Fargate Spot | 2 vCPU, 4 GB RAM, 상시 구동 | 26.00 |
| Network Load Balancer | 20 GB 처리 | 20.00 |
| AWS Secrets Manager | 10개 시크릿 | 4.00 |
| Amazon Cognito | 1K M2M 토큰 요청 | 2.25 |
| Amazon ECR | 2 GB 스토리지, 10 GB 전송 | 1.00 |
| Amazon API Gateway | 100K REST 호출 | 0.40 |
| Amazon S3 | 5 GB Standard | 0.10 |
| 합계 | 164.00 |
두 시나리오 모두 데이터베이스, 컴퓨팅, 로드밸런서가 비용의 대부분을 차지합니다. 이는 사용량 기반이 아닌 기본 인프라 비용이라는 점이 중요합니다. 즉, 사용량이 늘어나도 비용이 비례해서 급증하지 않는 구조입니다.
Well-Architected 관점의 최적화 전략
성능 효율성 (Performance Efficiency)
- 컴퓨팅 리소스 적정 사이징: ECS 태스크 정의를 실제 워크로드에 맞추세요. 처음부터 과하게 프로비저닝하지 말고 CloudWatch Container Insights 지표를 보고 스케일업하는 것이 안전합니다.
- Aurora Serverless v2 활용: 변동이 큰 워크로드라면 Aurora Serverless v2가 피크 대비 프로비저닝 부담을 줄여줍니다.
- 데이터 전송 패턴 최적화: 지리적으로 먼 대용량 전송에는 S3 Transfer Acceleration을, 가능하면 압축을 적용해 전송 시간과 비용을 함께 줄이세요.
비용 최적화 (Cost Optimization)
- Fargate Spot으로 최대 70% 절감: 중단을 허용할 수 있는 워크로드(개발/테스트/배치)에 적용하세요. Spot 중단에 대비한 graceful shutdown 처리는 필수입니다.
- S3 수명 주기 정책: 자주 접근하지 않는 이력 로그나 아카이브 자산은 S3 Intelligent-Tiering 또는 Glacier Instant Retrieval로 전환하세요.
- 비용 모니터링: AWS Cost Explorer와 Budgets 알림을 설정하고, EDC 관련 리소스에 일관된 태그를 붙여 비용을 정확히 할당하세요.
- Savings Plans: 예측 가능한 상시 워크로드라면 Aurora와 Fargate에 Savings Plans를 적용해 On-Demand 대비 할인을 받으세요.
지속 가능성 (Sustainability)
- 리소스 활용률 최적화: 오토스케일링으로 수요에 맞추고, 비프로덕션 환경은 업무 시간 외 종료하세요.
- 효율적인 인스턴스 선택: Graviton 기반(r6g, t4g) 인스턴스는 x86 대비 가격 대비 성능과 전력 효율이 우수합니다.
- 데이터 이동 최소화: Federated Catalog로 피어의 카탈로그 데이터를 로컬 캐싱하고, 배치 처리로 네트워크 왕복을 줄이세요.
주의사항: 이 비용 추정치는 상대적 비중을 보여주기 위한 예시입니다. 실제 비용은 리전, 사용 패턴, 데이터 볼륨에 따라 달라질 수 있으므로 AWS Pricing Calculator로 반드시 재검증하세요. 또한 Fargate Spot은 중단 리스크가 있으므로 비즈니스 크리티컬 워크로드에는 부적합합니다.
실무 적용 가이드
국내 SI/엔터프라이즈 환경에서 데이터 스페이스를 도입할 때는 다음 순서를 권장합니다.
- 워크로드 크리티컬리티 먼저 판단: SLA가 걸린 업무인지, 실험 환경인지에 따라 위 두 시나리오 중 하나를 선택하세요.
- Aurora 사이징부터 확정: 비용의 70% 이상을 차지하므로 여기서 결정이 나머지를 좌우합니다.
- 비프로덕션은 Fargate Spot + Aurora Serverless v2 조합으로 시작하고, 프로덕션 승격 시 Savings Plans로 전환하세요.
다음 단계 학습 방향
- EDC 아키텍처 기본 개념은 IDSA 표준 문서와 AWS의 3부작 시리즈 Part 1·2를 참고하세요.
- Infrastructure-as-Code 기반 참조 구현은 Dataspace Connector on AWS에서 확인할 수 있습니다.
- 비용 최적화 사고방식을 넓히고 싶다면 넷플릭스가 코드 배포처럼 데이터를 검증하는 방법 Data Canary 패턴 글도 함께 보시면 데이터 품질 관리 관점에서 도움이 됩니다.
- GPU 워크로드 비용 효율화에 관심 있다면 CUB의 새 단일 호출 API로 GPU 프로그래밍 번잡함 해결하기도 참고하세요.
데이터 스페이스는 산업과 지역을 넘어 확산되고 있습니다. 지금부터 비용 구조를 이해해두면 네트워크 참여 계획을 세울 때 훨씬 수월해집니다.