Azure

Fabric 담당 영역과 도구(서비스)

ravon 2025. 10. 31. 15:25

데이터 마이그레이션 프로젝트를 수행할 때 각 역할별 담당 영역과 도구(서비스)

 

 

 

전체 구조 개요

이 그림은 크게 세 단계로 구분되어 있습니다:

  1. 데이터 수집·적재 단계 (ETL, 네트워크, Spark 엔지니어)
  2. 데이터 설계·거버넌스 단계 (데이터 아키텍트, 모델러, DBA)
  3. 데이터 분석·시각화 단계 (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 총비용을 최소화하면서 성능을 유지하는 전략입니다.