데이터 마이그레이션 프로젝트를 수행할 때 각 역할별 담당 영역과 도구(서비스)
전체 구조 개요
이 그림은 크게 세 단계로 구분되어 있습니다:
- 데이터 수집·적재 단계 (ETL, 네트워크, Spark 엔지니어)
- 데이터 설계·거버넌스 단계 (데이터 아키텍트, 모델러, DBA)
- 데이터 분석·시각화 단계 (BI 엔지니어, 모델러)
오른쪽에는 이를 총괄 관리·보안·설계하는
- 솔루션 아키텍트 / 보안 엔지니어,
- 프로젝트 리더 / 매니저
의 역할이 추가되어 있습니다.
1. 데이터 적재(ETL) 및 네트워크 영역
담당자:
- ETL 엔지니어
- 네트워크 엔지니어
- Spark 엔지니어
사용 도구:
- ADF (Azure Data Factory) – 데이터 파이프라인 구성 및 배치 이동
- DF (Dataflow) – Fabric 내 데이터 변환 프로세스
- Lakehouse / Eventhouse – 원본 데이터 저장 (Raw/Streaming 데이터)
- Storage Account – 원시 데이터 저장소
주요 역할:
- 온프레미스 또는 외부 시스템에서 데이터를 Fabric 환경으로 이전
- Spark, Dataflow, ADF를 활용하여 정제/적재(ETL) 수행
- 네트워크 및 연결 보안 구성
2. 데이터 설계 및 거버넌스 영역
담당자:
- 데이터 아키텍트
- 데이터 모델러
- DBA
사용 도구:
- Lakehouse / Eventhouse / Warehouse – 정제된 데이터 저장
- Purview – 데이터 카탈로그 및 거버넌스 관리
주요 역할:
- 데이터 구조 설계, 모델링 (스키마 정의)
- 데이터 품질 관리, 메타데이터 정리
- Purview를 통한 데이터 분류, 민감도 레이블, 접근 제어 설정
3. 데이터 분석 및 시각화 영역
담당자:
- BI 엔지니어
- 데이터 모델러
사용 도구:
- Warehouse – 분석용 정형 데이터 저장
- Semantic Model – Power BI 모델링 레이어
- Power BI – 대시보드 및 보고서 제작
주요 역할:
- 분석 모델 생성 (DAX, 관계 모델링)
- Power BI를 통해 시각화 및 보고
- 사용자에게 데이터 기반 인사이트 제공
4. 지원 및 관리 영역
역할주요 책임관련 도구
| 솔루션 아키텍트 / 보안 엔지니어 / 네트워크 엔지니어 | 아키텍처 설계, 보안정책, 네트워크 구성 관리 | Azure Key Vault, Defender, Entra ID 등 |
| 프로젝트 리더 / 매니저 | 전체 일정·리소스·리스크 관리, 협업 관리 | Azure DevOps, GitHub, Project for the Web, Planner |
============================================================
단계주요 역할핵심 도구목표
| 데이터 적재 (ETL) | ETL/Spark/네트워크 엔지니어 | ADF, DF, Lakehouse, Storage | 데이터를 안정적으로 Fabric에 적재 |
| 데이터 설계 (Architecture) | 아키텍트, 모델러, DBA | Lakehouse, Warehouse, Purview | 데이터 구조와 거버넌스 설계 |
| 데이터 분석 (BI) | BI 엔지니어, 모델러 | Warehouse, Power BI | 분석/시각화 및 인사이트 제공 |
| 통합 관리 | 아키텍트, 보안, PM | Azure DevOps, Purview, Key Vault | 안정적 운영과 협업 관리 |
==========================================================================================
이 다이어그램은 Fabric 기반 데이터 마이그레이션 프로젝트의 역할 분담(R&R) 체계를 한눈에 보여줍니다.
데이터 이동(ETL) → 구조 설계 → 분석 및 시각화의 엔드투엔드 프로세스를
각 엔지니어링 팀과 관리 담당자가 어떤 도구를 통해 수행하는지 명확히 정의한 구조입니다.
MultiFabric Architecture (멀티패브릭 아키텍처)
🔹 개념
- 하나의 Fabric 환경만 사용하는 것이 아니라,
여러 개의 Fabric 용량(CU)을 목적에 따라 분리 구성하는 방식이에요. - 이렇게 하면 비용 절감 + 성능 최적화를 동시에 달성할 수 있습니다.
🧱 구성 전략
▶ ① F32 이하 (24/7 상시 운영 용도)
- 특징:
- 상시 가동이 필요한 환경 (예: 실시간 데이터 스트리밍, 이벤트 로그 수집 등)
- CPU 사용률은 일정하지만, 항상 켜져 있어야 하는 워크로드
- 운영 방식:
- Reservation (연간 예약제) 로 고정비를 줄임
- 장기간 지속적으로 사용하는 리소스에 적합
- 주요 용도:
- OneLake, Data Engineering, Eventlog, Eventstream, Microbatch
💬 즉, 상시 운영이 필요한 환경은 “예약형(Reservation)”으로 고정비 절감 전략을 취함.
▶ ② F64 이상 (대용량·AI·배치 용도)
- 특징:
- 인공지능, Copilot, 빅데이터 배치 처리 등 단기간 고성능이 필요한 작업
- CPU 사용률이 일정하지 않고, 필요할 때만 매우 높음
- 운영 방식:
- PAYG (Pay-As-You-Go), 즉 사용한 시간만큼만 과금
- 일정 시간만 구동 후 자동 중단 (예: 배치 완료 시 종료)
- 주요 용도:
- ML(머신러닝), Copilot, Big Data Daily Batch
💬 즉, 대규모 작업은 “PAYG 방식으로 단기 실행” 하여 불필요한 시간 과금을 방지.
💰 2️⃣ 비용 최적화 개념 (두 번째 그래프 설명)
이 그래프는 Reservation Instance vs PAYG Instance의 비용 교차점을 설명합니다.
구분설명
| X축 (시간, 자원) | 사용 시간 또는 사용량 |
| Y축 (비용) | 리소스 사용에 따른 누적비용 |
| 빨간선 (Reservation Instance) | 일정 금액을 고정적으로 지불하는 정액제 구조 (항상 동일 비용) |
| 파란선 (PAYG Instance) | 사용량에 따라 선형적으로 증가하는 종량제 구조 |
| Break Even Point | 두 방식의 비용이 같아지는 지점. 이 이후에는 Reservation이 더 경제적 |
👉 즉:
- 짧게만 사용할 경우 → PAYG가 유리
- 지속적으로 사용할 경우 → Reservation이 유리
⚙️ 3️⃣ 실제 적용 시 전략 요약
구분용량방식주요 용도전략 포인트
| Fabric F32 이하 | 상시 운영 | Reservation(연간 예약) | 실시간 처리, 이벤트 로그 수집 | 고정비 절감, 항상 켜짐 유지 |
| Fabric F64 이상 | 대규모 연산 | PAYG(시간제 과금) | AI, 대용량 배치 | 필요 시에만 구동, 과금 최소화 |
🎯 핵심 결론
MultiFabric 구조는 **“항상 필요한 리소스는 Reservation으로,
대규모 연산은 PAYG로 분리”**하여
Fabric 총비용을 최소화하면서 성능을 유지하는 전략입니다.
Rss Feed