데이터 웨어하우스(DW)란

데이터 웨어하우스(Data Warehouse)는 운영 시스템에 분산된 데이터를 분석 목적에 최적화된 형태로 통합·정제·보관하는 저장소이다.

Bill Inmon은 데이터 웨어하우스를 다음 네 가지 특성으로 정의했다.

OLTP가 “현재 거래를 빠르고 정확하게 처리”하는 시스템이라면, DW는 “장기간 데이터를 누적해 패턴과 추세를 분석”하는 시스템이다.

따라서:

• 스키마 설계
• 인덱스 전략
• 저장 구조
• 하드웨어 구성
• 튜닝 방식

모두 OLTP와 다르게 접근해야 한다.

OLTP vs OLAP 워크로드 비교

차원 모델링(Dimensional Modeling)

차원 모델링은 Ralph Kimball이 정립한 DW 설계 방식이다.

핵심 목표는:

“사용자가 어떤 측정값을 어떤 관점에서 보고 싶어하는가?”

를 직관적으로 표현하는 것이다.

팩트(Fact)와 디멘션(Dimension)

FactRental 예시

• 대여 1건 = 1행
• 이용 시간
• 이동 거리
• 탄소 절감량

등 숫자형 측정값 중심.

디멘션 예시

• 언제?
• 어디서?
• 누가?
• 어떤 유형?

같은 분석 관점을 제공한다.

스타 스키마 vs 스노우플레이크

스타 스키마

팩트를 중심에 두고 디멘션이 한 단계로 연결되는 구조.

           DimDate
               |
DimUserType - FactRental - DimStation(대여)
               |
          DimStation(반납)
               |
            DimTime

특징:

• 조인 단순
• BI 도구 친화적
• 분석 성능 우수
• 가장 일반적

스노우플레이크

디멘션 내부를 다시 정규화한 구조.

예:

• DimStation

  • DimDistrict

    • DimCity

장점:

• 저장 공간 절약
• 정규화 수준 높음

단점:

• 조인 증가
• 분석 성능 저하
• BI 가독성 저하

실무에서는:

스타 스키마를 기본으로 하고, 디멘션 규모가 매우 클 때만 부분 스노우플레이크를 적용한다.

SCD(Slowly Changing Dimension)

디멘션 데이터는 시간이 지나며 변경된다.

예:

• 대여소 이름 변경
• 자치구 변경
• 거치대 수 변경

이런 변경 이력을 어떻게 관리할지 정의하는 것이 SCD 전략이다.

SCD Type 비교

SCD Type 2

Type 2는 기존 행을 수정하지 않고 새로운 행을 추가한다.

주요 컬럼:

예:

이 방식으로:

• 과거 상태 유지
• 시점 분석 가능
• 히스토리 추적 가능

해진다.

Lamda Kappa

Azure 기준 예시

Lambda Architecture

Event Hub
 ├─ Azure Stream Analytics → 실시간 대시보드
 └─ Databricks Batch → 정산/통계

사용자 구조랑 비슷하게 보면: KMA/AirKorea → Azure Function → Event Hub → ASA (실시간) → PostgreSQL

• Databricks 배치 분석

Kappa Architecture

Kafka/Event Hub
→ Flink/ASA
→ PostgreSQL/Power BI

배치 없이:

• 스트림만 계속 처리
• 필요 시 이벤트 재생(replay)

Azure DW 선택지

Azure에서 DW를 구축할 때는 다양한 선택지가 존재한다.

Azure SQL Database — Serverless

특징

• 자동 일시 중지
• 사용량 기반 과금
• 자동 스케일
• 운영 부담 최소

장점

• 개발/교육 환경 비용 절감
• 유휴 시간 과금 최소화
• PaaS 기반 자동 운영

단점

• 콜드 스타트 발생
• vCore 상한 존재

본 과정 메인 플랫폼

Azure SQL Database — Provisioned

특징

• 상시 가동
• 일정한 응답 성능
• Hyperscale 가능

장점

• 안정적 응답 시간
• 대규모 운영 적합

단점

• 유휴 시간도 비용 발생

Azure SQL Managed Instance

특징

• SQL Server와 거의 동일
• SQL Agent 지원
• 크로스 DB 쿼리 가능

장점

• 기존 SQL Server 이전 용이
• 높은 호환성

단점

• 비용 높음
• 프로비저닝 느림

Azure SQL on VM

특징

• IaaS 기반
• OS 직접 관리
• SQL Server 전체 기능 사용 가능

장점

• FCI
• Replication
• Linked Server
• CLR

등 전체 기능 사용 가능.

단점

• 패치 책임 직접 부담
• 백업/HA 직접 구성

Microsoft Fabric Warehouse

특징

• SaaS 기반
• OneLake 통합
• Power BI 친화적

장점

• 데이터·BI 통합 우수

단점

• Capacity 기반 과금
• 기능 변화가 빠름

의사결정 매트릭스

Azure SQL DB Serverless 동작 원리

Serverless는 사용한 만큼만 과금되는 컴퓨트 모델이다.

핵심 기능은 다음 세 가지다.

자동 일시 중지(Auto Pause)

일정 시간 동안 쿼리나 연결이 없으면:

• 컴퓨트 제거
• 과금 중단

스토리지 비용만 유지된다.

교육/개발 환경에서 매우 유리하다.

자동 재개(Auto Resume)

새 연결이 들어오면:

• 자동으로 DB 재개
• 약 30~60초 콜드 스타트 가능

운영 환경에서는:

• 재시도 로직
• Keep-alive
• 워밍 전략

등이 필요하다.

자동 스케일(Auto Scale)

최소·최대 vCore 범위를 설정하면:

• 부하에 따라 자동 확장
• 메모리도 함께 증가

한다.

Storage → DW 적재 패턴

DW 적재에서 가장 일반적인 패턴은:

CSV → Storage Account → DW

이다.

본 과정에서는 두 가지 표준 패턴을 사용한다.

BULK INSERT

외부 CSV 파일을 대량 적재하는 전통적 방식.

특징

• 매우 빠름
• 대량 적재 최적화
• staging 적재에 적합

흐름

1. MASTER KEY 생성
2. DATABASE SCOPED CREDENTIAL 생성
3. EXTERNAL DATA SOURCE 생성
4. BULK INSERT 수행

OPENROWSET(BULK)

외부 파일을 가상 테이블처럼 SELECT 하는 방식.

INSERT INTO staging.RentalRaw (rental_id, station_id, started_at, ended_at, duration_min)
SELECT
    JSON_VALUE(c.line, '$.rental_id'),
    CAST(c.station_id AS INT),
    TRY_CONVERT(datetime2, c.started_at),
    TRY_CONVERT(datetime2, c.ended_at),
    c.duration_min
FROM OPENROWSET(
       BULK '2024/2024-01-rental.csv',
       DATA_SOURCE = 'BlobDS',
       FORMAT = 'CSV',
       FIRSTROW = 2,
       FIELDTERMINATOR = ','
     ) WITH (
       rental_id     varchar(40),
       station_id    varchar(20),
       started_at    varchar(30),
       ended_at      varchar(30),
       duration_min  int
     ) AS c
WHERE TRY_CONVERT(datetime2, c.started_at) IS NOT NULL;

특징

• 변환 자유도 높음
• INSERT ... SELECT 가능
• TRY_CONVERT 활용 가능

장점

• 적재 중 정제 가능
• 필터링 가능
• 데이터 품질 방어 쉬움

BULK INSERT vs OPENROWSET 비교

책임 기준 분리

이벤트 기반 적재 패턴

배치 적재 이후 단계는 자동화이다.

Azure에서는:

• Event Grid
• Azure Functions
• Logic Apps

를 조합한다.

Azure Functions

특징

• 코드 기반
• Python/C#/JS 지원
• 유연성 높음

적합한 경우

• 즉시 처리
• 복잡한 로직
• 실시간 이벤트

Azure Logic Apps

특징

• GUI 기반
• 노코드 워크플로우
• 다양한 SaaS 연결

적합한 경우

• 스케줄 기반 ETL
• 알림
• 오케스트레이션

Event Grid

역할

Azure 전체 이벤트 라우팅 백본.

예:

Blob 업로드
  ↓
Event Grid
  ↓
Function App
  ↓
Stored Procedure 실행

이벤트 기반 적재 구조

CSV Upload
    ↓
Blob Storage
    ↓ BlobCreated Event
Event Grid
    ↓
Function App
    ↓
EXEC sp_LoadFactFromBlob
    ↓
Azure SQL Database

이 구조의 핵심은:

“Storage가 진실의 원본(Source of Truth)”

이라는 점이다.

배치 vs 이벤트 적재 선택 기준

실무에서는:

• 야간 대량 적재 = 배치
• 실시간 보정 = 이벤트

조합이 가장 흔하다.

전체 아키텍처

이번 실습의 전체 구조는 다음과 같다.

서울시 따릉이 CSV
        ↓
Azure Storage Account
(raw / staging / archive)
        ↓
BULK INSERT / OPENROWSET
        ↓
Azure SQL Database Serverless
(staging / dw / mart)
        ↓
분석 쿼리 / Power BI

추가 자동화:
BlobCreated Event
        ↓
Event Grid
        ↓
Azure Function
        ↓
Stored Procedure 실행
        ↓
DW 자동 적재

핵심은 Storage Account를 원본 데이터 저장소로 두고, Azure SQL Database Serverless를 분석용 DW로 사용하는 것이다.

Lab 01 — Azure SQL Database Serverless 생성

리소스 그룹과 SQL Server 생성

먼저 실습에서 사용할 변수들을 정의한다.

RG=rg-dwlab-$USER
LOC=koreacentral
SQL_SRV=sql-dwlab-$USER-$RANDOM
SQL_DB=dw_seoulbike
ADMIN_USER=dwadmin
ADMIN_PASS='Dw!Lab2026Secure'

리소스 그룹과 SQL Server를 생성한다.

az group create -n $RG -l $LOC

az sql server create \
  --name $SQL_SRV \
  --resource-group $RG \
  --location $LOC \
  --admin-user $ADMIN_USER \
  --admin-password $ADMIN_PASS

현재 접속 IP를 방화벽에 등록한다.

MY_IP=$(curl -s https://api.ipify.org)

az sql server firewall-rule create \
  --resource-group $RG \
  --server $SQL_SRV \
  --name allow-me \
  --start-ip-address $MY_IP \
  --end-ip-address $MY_IP

Serverless DB 생성

az sql db create \
  --resource-group $RG \
  --server $SQL_SRV \
  --name $SQL_DB \
  --edition GeneralPurpose \
  --family Gen5 \
  --compute-model Serverless \
  --min-capacity 0.5 \
  --capacity 2 \
  --auto-pause-delay 60 \
  --backup-storage-redundancy Local \
  --collation Korean_Wansung_CI_AS

주요 옵션은 다음과 같다.

접속 확인:

sqlcmd -S $SQL_SRV.database.windows.net \
  -d $SQL_DB \
  -U $ADMIN_USER \
  -P "$ADMIN_PASS" \
  -Q "SELECT @@VERSION;"

Lab 02 — Serverless 동작 확인

Auto Pause 시간 변경

교육 환경에서는 자동 일시 중지를 빠르게 확인하기 위해 15분으로 변경한다.

az sql db update \
  -g $RG \
  -s $SQL_SRV \
  -n $SQL_DB \
  --auto-pause-delay 15

리소스 사용량 확인

SQL Database에서 다음 DMV를 조회해 CPU, 메모리, IO 사용률을 확인한다.

SELECT TOP 5
    avg_cpu_percent,
    avg_memory_usage_percent,
    avg_data_io_percent,
    end_time
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

확인할 내용은 다음과 같다.

운영 환경에서는 Cold Start가 사용자 경험에 영향을 줄 수 있으므로, 재시도 로직이나 Keep-alive 전략을 고려해야 한다.

Lab 03 — Storage Account 생성 및 데이터 업로드

Storage Account 생성

STO_ACC=stodwlab$USER$RANDOM

az storage account create \
  -g $RG \
  -n $STO_ACC \
  -l $LOC \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --allow-blob-public-access false \
  --min-tls-version TLS1_2

Storage Key를 가져온다.

STO_KEY=$(az storage account keys list \
  -g $RG \
  -n $STO_ACC \
  --query [0].value \
  -o tsv)

컨테이너 3개를 생성한다.

for c in raw staging archive; do
  az storage container create \
    --name $c \
    --account-name $STO_ACC \
    --account-key $STO_KEY
done

따릉이 샘플 데이터 업로드

생성된 샘플 CSV 파일을 raw/seoul_bike/ 경로에 업로드한다.

az storage blob upload-batch \
  --account-name "$STO_ACC" \
  --account-key $STO_KEY \
  --destination raw \
  --destination-path seoul_bike/ \
  --source ./seoul_bike_data \
  --pattern "*.csv" \
  --overwrite

업로드 확인:

az storage blob list \
  --account-name "$STO_ACC" \
  --account-key $STO_KEY \
  --container-name raw \
  --prefix "seoul_bike/" \
  --query "[].{name:name, size:properties.contentLength}" \
  -o table

SAS 토큰 생성

Azure SQL Database에서 Blob을 읽기 위해 SAS 토큰을 생성한다.

EXPIRY=$(date -u -d "+7 days" '+%Y-%m-%dT%H:%MZ')

SAS=$(az storage container generate-sas \
  --account-name $STO_ACC \
  --name raw \
  --permissions rl \
  --expiry $EXPIRY \
  --https-only \
  --output tsv)

echo $SAS

SAS는 비밀번호와 같은 민감 정보이므로 외부에 노출되지 않도록 관리해야 한다.

Lab 04 — 스타 스키마 생성

스키마 생성

CREATE SCHEMA staging AUTHORIZATION dbo;
GO
CREATE SCHEMA dw AUTHORIZATION dbo;
GO
CREATE SCHEMA mart AUTHORIZATION dbo;
GO

디멘션 테이블 생성

CREATE TABLE dw.DimDate (
  DateKey       INT          NOT NULL PRIMARY KEY,
  [Date]        DATE         NOT NULL,
  [Year]        SMALLINT     NOT NULL,
  Quarter       TINYINT      NOT NULL,
  [Month]       TINYINT      NOT NULL,
  MonthName     NVARCHAR(10) NOT NULL,
  [Day]         TINYINT      NOT NULL,
  DayOfWeek     TINYINT      NOT NULL,
  DayName       NVARCHAR(10) NOT NULL,
  IsWeekend     BIT          NOT NULL,
  IsHoliday     BIT          NOT NULL DEFAULT 0
);

CREATE TABLE dw.DimTime (
  TimeKey       INT          NOT NULL PRIMARY KEY,
  [Hour]        TINYINT      NOT NULL,
  [Minute]      TINYINT      NOT NULL,
  TimeBucket    NVARCHAR(10) NOT NULL
);

CREATE TABLE dw.DimUserType (
  UserTypeKey   INT IDENTITY PRIMARY KEY,
  UserTypeCode  VARCHAR(20)  NOT NULL UNIQUE,
  UserTypeName  NVARCHAR(40) NOT NULL
);

팩트 테이블 생성

CREATE TABLE dw.FactRental (
  RentalKey       BIGINT IDENTITY,
  RentalId        VARCHAR(40)  NOT NULL,
  StartDateKey    INT          NOT NULL,
  StartTimeKey    INT          NOT NULL,
  EndDateKey      INT          NULL,
  EndTimeKey      INT          NULL,
  StartStationKey BIGINT       NULL,
  EndStationKey   BIGINT       NULL,
  UserTypeKey     INT          NULL,
  DurationMin     INT          NULL,
  DistanceMeter   INT          NULL,
  CarbonGramSaved DECIMAL(10,2) NULL,
  LoadedAt        DATETIME2    NOT NULL DEFAULT SYSUTCDATETIME(),
  SourceFile      VARCHAR(256) NULL,
  CONSTRAINT PK_FactRental PRIMARY KEY NONCLUSTERED (RentalKey)
);

CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactRental
ON dw.FactRental;

CREATE UNIQUE INDEX UX_FactRental_RentalId
ON dw.FactRental(RentalId);

FactRental은 대량 집계가 주 목적이므로 Clustered Columnstore Index를 적용한다.

DimDate / DimTime 사전 적재

WITH d AS (
  SELECT CAST('2015-01-01' AS DATE) AS dt
  UNION ALL
  SELECT DATEADD(DAY, 1, dt)
  FROM d
  WHERE dt < '2030-12-31'
)
INSERT dw.DimDate (
  DateKey, [Date], [Year], Quarter, [Month], MonthName,
  [Day], DayOfWeek, DayName, IsWeekend
)
SELECT
  CONVERT(INT, FORMAT(dt,'yyyyMMdd')),
  dt,
  YEAR(dt),
  DATEPART(QUARTER, dt),
  MONTH(dt),
  DATENAME(MONTH, dt),
  DAY(dt),
  DATEPART(WEEKDAY, dt),
  DATENAME(WEEKDAY, dt),
  CASE WHEN DATEPART(WEEKDAY, dt) IN (1,7) THEN 1 ELSE 0 END
FROM d
OPTION (MAXRECURSION 0);

WITH m AS (
  SELECT 0 AS n
  UNION ALL
  SELECT n + 1
  FROM m
  WHERE n < 1439
)
INSERT dw.DimTime (TimeKey, [Hour], [Minute], TimeBucket)
SELECT
  (n / 60) * 100 + (n % 60),
  n / 60,
  n % 60,
  CASE
    WHEN n/60 BETWEEN 0  AND 5  THEN N'심야'
    WHEN n/60 BETWEEN 6  AND 11 THEN N'오전'
    WHEN n/60 BETWEEN 12 AND 17 THEN N'오후'
    WHEN n/60 BETWEEN 18 AND 22 THEN N'저녁'
    ELSE N'심야'
  END
FROM m
OPTION (MAXRECURSION 0);

사용자 유형도 기본 적재한다.

INSERT dw.DimUserType (UserTypeCode, UserTypeName) VALUES
  ('MEMBER',     N'정기권 회원'),
  ('NONMEMBER',  N'일일권 비회원'),
  ('UNKNOWN',    N'미상');

검증 기준:

Lab 05 — BULK INSERT로 첫 적재

Blob 접근 객체 생성

SQL Database에서 Blob Storage에 접근하기 위한 3종 객체를 만든다.

IF NOT EXISTS (
  SELECT 1
  FROM sys.symmetric_keys
  WHERE name = '##MS_DatabaseMasterKey##'
)
  CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Lab!MasterKey2026';

CREATE DATABASE SCOPED CREDENTIAL StorageCred
  WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
       SECRET   = '<SAS_TOKEN>';

CREATE EXTERNAL DATA SOURCE BlobRaw
  WITH (
    TYPE       = BLOB_STORAGE,
    LOCATION   = 'https://<STO_ACC>.blob.core.windows.net/raw',
    CREDENTIAL = StorageCred
  );

<SAS_TOKEN>에는 앞의 ?를 제외한 SAS 본문만 넣는다.

Staging 테이블 생성

DROP TABLE IF EXISTS staging.RentalRaw;

CREATE TABLE staging.RentalRaw (
  RentalId        VARCHAR(20)  NOT NULL,
  BikeId          VARCHAR(20)  NOT NULL,
  StartTime       DATETIME2(0) NOT NULL,
  EndTime         DATETIME2(0) NOT NULL,
  StartStationId  VARCHAR(20)  NOT NULL,
  EndStationId    VARCHAR(20)  NOT NULL,
  DurationMin     INT          NOT NULL,
  DistanceMeter   INT          NOT NULL,
  UserType        VARCHAR(20)  NOT NULL
);

CSV 파일 BULK INSERT

TRUNCATE TABLE staging.RentalRaw;

DECLARE @i INT = 1, @sql NVARCHAR(MAX);

WHILE @i <= 7
BEGIN
  SET @sql = N'
    BULK INSERT staging.RentalRaw
    FROM ''seoul_bike/rentals_2025090' + CAST(@i AS VARCHAR(1)) + '.csv''
    WITH (
      DATA_SOURCE     = ''BlobRaw'',
      FORMAT          = ''CSV'',
      FIRSTROW        = 2,
      FIELDTERMINATOR = '','',
      ROWTERMINATOR   = ''0x0d0a'',
      CODEPAGE        = ''65001'',
      TABLOCK,
      MAXERRORS       = 100
    );';

  EXEC sp_executesql @sql;
  SET @i += 1;
END

검증:

SELECT COUNT(*) AS staging_rows
FROM staging.RentalRaw;

기대값은 21,600행이다.

staging → FactRental 변환 적재

TRUNCATE TABLE dw.FactRental;

INSERT INTO dw.FactRental (
  RentalId, StartDateKey, StartTimeKey, EndDateKey, EndTimeKey,
  StartStationKey, EndStationKey, UserTypeKey,
  DurationMin, DistanceMeter, CarbonGramSaved,
  LoadedAt, SourceFile
)
SELECT
  s.RentalId,
  CONVERT(INT, CONVERT(VARCHAR(8), s.StartTime, 112)) AS StartDateKey,
  DATEPART(HOUR, s.StartTime) * 60 + DATEPART(MINUTE, s.StartTime) AS StartTimeKey,
  CONVERT(INT, CONVERT(VARCHAR(8), s.EndTime, 112)) AS EndDateKey,
  DATEPART(HOUR, s.EndTime) * 60 + DATEPART(MINUTE, s.EndTime) AS EndTimeKey,
  CAST(NULL AS BIGINT) AS StartStationKey,
  CAST(NULL AS BIGINT) AS EndStationKey,
  COALESCE(ut.UserTypeKey, ut_unk.UserTypeKey) AS UserTypeKey,
  s.DurationMin,
  s.DistanceMeter,
  CAST(s.DistanceMeter * 0.21 AS DECIMAL(10,2)) AS CarbonGramSaved,
  SYSUTCDATETIME() AS LoadedAt,
  'seoul_bike/rentals_' + CONVERT(VARCHAR(8), s.StartTime, 112) + '.csv' AS SourceFile
FROM staging.RentalRaw AS s
LEFT JOIN dw.DimUserType AS ut
  ON ut.UserTypeCode = s.UserType
LEFT JOIN dw.DimUserType AS ut_unk
  ON ut_unk.UserTypeCode = 'UNKNOWN';

여기서는 아직 StartStationKey, EndStationKey를 채우지 않는다.
대여소 디멘션은 Lab 06에서 SCD Type 2로 처리한 뒤 백필한다.

적재 검증

SELECT COUNT(*) AS fact_rows
FROM dw.FactRental;

SELECT StartDateKey, COUNT(*) AS c
FROM dw.FactRental
GROUP BY StartDateKey
ORDER BY StartDateKey;

SELECT COUNT(*) AS unmapped_user_type
FROM dw.FactRental
WHERE UserTypeKey IS NULL;

검증 포인트:

Lab 06 — SCD Type 2 대여소 디멘션 적재

DimStation 생성

CREATE TABLE dw.DimStation (
  StationKey   BIGINT IDENTITY(1,1) NOT NULL,
  StationId    VARCHAR(20)   NOT NULL,
  StationName  NVARCHAR(100) NOT NULL,
  Gu           NVARCHAR(50)  NOT NULL,
  Lat          DECIMAL(9,5)  NOT NULL,
  Lng          DECIMAL(9,5)  NOT NULL,
  RackCount    INT           NOT NULL,
  RowHash      BINARY(32)    NOT NULL,
  ValidFrom    DATE          NOT NULL,
  ValidTo      DATE          NULL,
  IsCurrent    BIT           NOT NULL,
  LoadedAt     DATETIME2(0)  NOT NULL DEFAULT SYSUTCDATETIME(),
  CONSTRAINT PK_DimStation PRIMARY KEY NONCLUSTERED (StationKey)
);

CREATE UNIQUE INDEX UX_DimStation_BusinessVersion
ON dw.DimStation (StationId, ValidFrom);

CREATE INDEX IX_DimStation_Current
ON dw.DimStation (StationId)
WHERE IsCurrent = 1;

RowHash 함수 생성

CREATE OR ALTER FUNCTION dw.fn_StationRowHash(
  @StationName NVARCHAR(100),
  @Gu NVARCHAR(50),
  @Lat DECIMAL(9,5),
  @Lng DECIMAL(9,5),
  @RackCount INT
) RETURNS BINARY(32)
WITH SCHEMABINDING
AS
BEGIN
  RETURN HASHBYTES('SHA2_256',
    CONCAT_WS(N'|',
      @StationName,
      @Gu,
      CONVERT(NVARCHAR(20), @Lat, 1),
      CONVERT(NVARCHAR(20), @Lng, 1),
      CAST(@RackCount AS NVARCHAR(20))
    )
  );
END

RowHash를 사용하면 여러 컬럼을 각각 비교하지 않고 해시값 하나로 변경 여부를 판단할 수 있다.

StationRaw 적재

DROP TABLE IF EXISTS staging.StationRaw;

CREATE TABLE staging.StationRaw (
  StationId    VARCHAR(20)   NOT NULL,
  StationName  NVARCHAR(100) NOT NULL,
  Gu           NVARCHAR(50)  NOT NULL,
  Lat          DECIMAL(9,5)  NOT NULL,
  Lng          DECIMAL(9,5)  NOT NULL,
  RackCount    INT           NOT NULL,
  OpenedDate   DATE          NOT NULL
);

TRUNCATE TABLE staging.StationRaw;

BULK INSERT staging.StationRaw
FROM 'seoul_bike/stations.csv'
WITH (
  DATA_SOURCE='BlobRaw',
  FORMAT='CSV',
  FIRSTROW=2,
  FIELDTERMINATOR=',',
  ROWTERMINATOR='0x0d0a',
  CODEPAGE='65001',
  TABLOCK,
  MAXERRORS=0
);

최초 적재

INSERT INTO dw.DimStation (
  StationId, StationName, Gu, Lat, Lng, RackCount,
  RowHash, ValidFrom, ValidTo, IsCurrent
)
SELECT
  s.StationId,
  s.StationName,
  s.Gu,
  s.Lat,
  s.Lng,
  s.RackCount,
  dw.fn_StationRowHash(s.StationName, s.Gu, s.Lat, s.Lng, s.RackCount),
  s.OpenedDate,
  NULL,
  1
FROM staging.StationRaw s;

팩트 외래키 백필

UPDATE f
SET f.StartStationKey = s.StationKey
FROM dw.FactRental f
INNER JOIN staging.RentalRaw r
  ON r.RentalId = f.RentalId
INNER JOIN dw.DimStation s
  ON s.StationId = r.StartStationId
 AND CAST(r.StartTime AS DATE) >= s.ValidFrom
 AND (s.ValidTo IS NULL OR CAST(r.StartTime AS DATE) < s.ValidTo)
WHERE f.StartStationKey IS NULL;

UPDATE f
SET f.EndStationKey = s.StationKey
FROM dw.FactRental f
INNER JOIN staging.RentalRaw r
  ON r.RentalId = f.RentalId
INNER JOIN dw.DimStation s
  ON s.StationId = r.EndStationId
 AND CAST(r.EndTime AS DATE) >= s.ValidFrom
 AND (s.ValidTo IS NULL OR CAST(r.EndTime AS DATE) < s.ValidTo)
WHERE f.EndStationKey IS NULL;

검증:

SELECT
  SUM(CASE WHEN StartStationKey IS NULL THEN 1 ELSE 0 END) AS null_start,
  SUM(CASE WHEN EndStationKey IS NULL THEN 1 ELSE 0 END) AS null_end
FROM dw.FactRental;

기대값은 0 / 0이다.

Lab 07 — 분석 쿼리

시간대별 평균 이용 패턴

SELECT
  t.TimeBucket,
  d.DayName,
  COUNT(*) AS rentals,
  AVG(f.DurationMin) AS avg_minutes
FROM dw.FactRental f
JOIN dw.DimTime t
  ON t.TimeKey = f.StartTimeKey
JOIN dw.DimDate d
  ON d.DateKey = f.StartDateKey
GROUP BY t.TimeBucket, d.DayName
ORDER BY rentals DESC;

이 쿼리로 시간대와 요일별 이용 패턴을 확인할 수 있다.

자치구별 출발/도착 비대칭

WITH dep AS (
  SELECT s.Gu, COUNT(*) AS departures
  FROM dw.FactRental f
  JOIN dw.DimStation s
    ON s.StationKey = f.StartStationKey
  GROUP BY s.Gu
),
arr AS (
  SELECT s.Gu, COUNT(*) AS arrivals
  FROM dw.FactRental f
  JOIN dw.DimStation s
    ON s.StationKey = f.EndStationKey
  GROUP BY s.Gu
)
SELECT
  COALESCE(d.Gu, a.Gu) AS Gu,
  d.departures,
  a.arrivals,
  a.arrivals - d.departures AS net_flow
FROM dep d
FULL OUTER JOIN arr a
  ON a.Gu = d.Gu
ORDER BY ABS(a.arrivals - d.departures) DESC;

net_flow가 크면 해당 자치구에서 자전거 적체 또는 부족이 발생할 가능성이 높다.

Top 10 OD 페어

SELECT TOP 10
  st.StationName AS start_station,
  en.StationName AS end_station,
  COUNT(*) AS trips,
  AVG(f.DurationMin) AS avg_min
FROM dw.FactRental f
JOIN dw.DimStation st
  ON st.StationKey = f.StartStationKey
JOIN dw.DimStation en
  ON en.StationKey = f.EndStationKey
WHERE f.StartStationKey IS NOT NULL
  AND f.EndStationKey IS NOT NULL
  AND f.StartStationKey <> f.EndStationKey
GROUP BY st.StationName, en.StationName
ORDER BY trips DESC;

ROLLUP으로 소계 만들기

SELECT
  COALESCE(s.Gu, '<<TOTAL_GU>>') AS Gu,
  COALESCE(CAST(t.Hour AS VARCHAR(8)), '<<TOTAL_HOUR>>') AS Hour,
  COUNT(*) AS rides
FROM dw.FactRental f
JOIN dw.DimStation s
  ON s.StationKey = f.StartStationKey
JOIN dw.DimTime t
  ON t.TimeKey = f.StartTimeKey
GROUP BY ROLLUP(s.Gu, t.Hour)
ORDER BY GROUPING(s.Gu), s.Gu, GROUPING(t.Hour), t.Hour;

Lab 08 — Function App + Event Grid 자동 적재

Function App 생성

FUNC_APP=func-dwlab-$USER-$RANDOM
FUNC_LOC="koreacentral"

az functionapp create \
  -g $RG \
  -n $FUNC_APP \
  --consumption-plan-location $FUNC_LOC \
  --runtime python \
  --runtime-version 3.11 \
  --functions-version 4 \
  --storage-account $STO_ACC \
  --os-type Linux

Managed Identity를 활성화한다.

az functionapp identity assign \
  -g $RG \
  -n $FUNC_APP

Storage 읽기 권한을 부여한다.

FUNC_PRINCIPAL=$(az functionapp identity show \
  -g $RG \
  -n $FUNC_APP \
  --query principalId \
  -o tsv)

STO_ID=$(az storage account show \
  -g $RG \
  -n $STO_ACC \
  --query id \
  -o tsv)

az role assignment create \
  --assignee "$FUNC_PRINCIPAL" \
  --role 'Storage Blob Data Reader' \
  --scope "$STO_ID"

SQL DB에 Managed Identity 사용자 등록

CREATE USER [func-dwlab-...] FROM EXTERNAL PROVIDER;

ALTER ROLE db_datareader ADD MEMBER [func-dwlab-...];
ALTER ROLE db_datawriter ADD MEMBER [func-dwlab-...];

GRANT EXECUTE ON SCHEMA :: staging TO [func-dwlab-...];
GRANT EXECUTE ON SCHEMA :: dw TO [func-dwlab-...];

운영 환경에서는 Function 코드에 SQL 비밀번호를 넣지 않는 것이 중요하다.
Managed Identity를 사용하면 Function App 자체의 신원으로 SQL Database에 접근할 수 있다.

Function 코드 핵심

import logging, os, struct
import azure.functions as func
from azure.identity import DefaultAzureCredential
import pyodbc

app = func.FunctionApp()

@app.event_grid_trigger(arg_name='event')
def blob_loaded(event: func.EventGridEvent):
    data = event.get_json()
    blob_url = data.get('url')
    logging.info(f'BlobCreated: {blob_url}')

    if '/raw/' not in blob_url or not blob_url.endswith('.csv'):
        logging.info('Skip non-target blob')
        return

    rel = blob_url.split('/raw/')[-1]

    cred = DefaultAzureCredential()
    token = cred.get_token(
        'https://database.windows.net/.default'
    ).token.encode('utf-16-le')

    token_struct = struct.pack(f'=i{len(token)}s', len(token), token)
    SQL_COPT_SS_ACCESS_TOKEN = 1256

    conn_str = (
        'Driver={ODBC Driver 18 for SQL Server};'
        f'Server=tcp:{os.environ["SQL_SERVER"]},1433;'
        f'Database={os.environ["SQL_DB"]};'
        'Encrypt=yes;TrustServerCertificate=no;'
    )

    with pyodbc.connect(
        conn_str,
        attrs_before={SQL_COPT_SS_ACCESS_TOKEN: token_struct}
    ) as cn:
        cn.cursor().execute(
            'EXEC dw.sp_LoadFactFromBlob @blobPath = ?',
            rel
        ).commit()

    logging.info('sp_LoadFactFromBlob OK')

Stored Procedure 생성

CREATE OR ALTER PROCEDURE dw.sp_LoadFactFromBlob
  @blobPath NVARCHAR(500)
AS
BEGIN
  SET NOCOUNT ON;

  DECLARE @sql NVARCHAR(MAX);

  TRUNCATE TABLE staging.RentalRaw;

  SET @sql = N'BULK INSERT staging.RentalRaw
    FROM ''' + @blobPath + N'''
    WITH (
      DATA_SOURCE=''BlobRaw'',
      FORMAT=''CSV'',
      FIRSTROW=2,
      FIELDTERMINATOR='','',
      ROWTERMINATOR=''0x0a'',
      CODEPAGE=''65001'',
      MAXERRORS=100
    )';

  EXEC sp_executesql @sql;

  EXEC dw.sp_TransformAndLoad @sourceFile = @blobPath;
END

Event Grid 구독 생성

FUNC_KEY=$(az functionapp keys list \
  -g $RG \
  -n $FUNC_APP \
  --query systemKeys.eventgrid_extension \
  -o tsv)

ENDPOINT="https://$FUNC_APP.azurewebsites.net/runtime/webhooks/EventGrid?functionName=blob_loaded&code=$FUNC_KEY"

az eventgrid event-subscription create \
  --name sub-blob-to-func \
  --source-resource-id $STO_ID \
  --endpoint-type webhook \
  --endpoint "$ENDPOINT" \
  --included-event-types Microsoft.Storage.BlobCreated \
  --subject-begins-with /blobServices/default/containers/raw/

이제 raw 컨테이너에 CSV가 업로드되면 Event Grid가 Function을 호출하고, Function이 SQL 저장 프로시저를 실행해 적재한다.

Lab 09 — Logic Apps 일일 적재 워크플로우

Logic Apps는 GUI 기반으로 ETL 흐름을 구성할 수 있다.

워크플로우 구조는 다음과 같다.

Recurrence: 매일 02:00 KST
        ↓
List blobs in raw
        ↓
Filter array
        ↓
For each
        ↓
Execute stored procedure
        ↓
성공: archive 이동
실패: 이메일 알림

Function이 “파일이 올라오자마자 즉시 처리”에 적합하다면, Logic Apps는 “정해진 시간에 여러 작업을 순서대로 실행”하는 데 적합하다.

Lab 10 — 운영: PITR, 모니터링, 권한, 정리

PITR 복원

RESTORE_TS=$(date -u -d "-5 min" '+%Y-%m-%dT%H:%M:%S')

az sql db restore \
  -g $RG \
  -s $SQL_SRV \
  -n dw_seoulbike \
  --dest-name dw_seoulbike_pitr \
  --time $RESTORE_TS \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 2

복원된 DB 행수 확인:

sqlcmd -S $SQL_SRV.database.windows.net \
  -d dw_seoulbike_pitr \
  -U $ADMIN_USER \
  -P "$ADMIN_PASS" \
  -Q "SELECT COUNT(*) FROM dw.FactRental;"

CPU 알림 규칙 생성

az monitor metrics alert create \
  -g $RG \
  -n alert-dw-cpu-high \
  --scopes $(az sql db show -g $RG -s $SQL_SRV -n $SQL_DB --query id -o tsv) \
  --condition "avg cpu_percent > 80" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2

ROLE 기반 권한 분리

CREATE ROLE dw_analyst;
GRANT SELECT ON SCHEMA :: dw TO dw_analyst;
GRANT SELECT ON SCHEMA :: mart TO dw_analyst;
DENY SELECT ON SCHEMA :: staging TO dw_analyst;

CREATE ROLE dw_loader;
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA :: staging TO dw_loader;
GRANT SELECT, INSERT, UPDATE ON SCHEMA :: dw TO dw_loader;
GRANT EXECUTE ON SCHEMA :: dw TO dw_loader;

CREATE ROLE dw_admin;
GRANT CONTROL ON DATABASE :: dw_seoulbike TO dw_admin;

리소스 정리

실습 종료 후에는 리소스 그룹을 삭제해 비용 누적을 막는다.

az sql db delete \
  -g $RG \
  -s $SQL_SRV \
  -n dw_seoulbike_pitr \
  --yes 2>/dev/null

az group delete \
  -n $RG \
  --yes \
  --no-wait

전체 실습 흐름 정리

15. 핵심 정리

이번 실습의 핵심은 다음과 같다.

1. DW는 OLTP와 목적이 다르기 때문에 스키마와 인덱스 전략도 달라야 한다.
2. 분석 중심 모델링에서는 Fact와 Dimension을 분리한다.
3. 대량 분석용 Fact 테이블에는 Columnstore Index가 적합하다.
4. Storage Account는 원본 데이터 저장소 역할을 한다.
5. BULK INSERT는 빠른 1차 적재에 적합하다.
6. SCD Type 2는 대여소처럼 속성이 변하는 디멘션의 이력을 보존하는 데 사용한다.
7. Event Grid + Function을 사용하면 Blob 업로드 기반 자동 적재가 가능하다.
8. Logic Apps는 일정 기반 ETL 오케스트레이션에 적합하다.
9. PITR, Monitor, Role, 비용 정리는 DW 운영에서 반드시 필요하다.

그래프 쪽은 JOIN을 명시적으로 쓰지 않아도 패턴이 곧 쿼리가 됨

1.1 SQL Server Graph Database란?

• SQL Server 2017부터 도입됨
• 노드(Node)와 엣지(Edge)를 사용하여 복잡한 관계형 데이터를 자연스럽게 표현하고 쿼리할 수 있게 해줌
• Azure SQL Database와 Azure SQL VM 모두에서 이 기능을 완벽하게 지원

관계형 모델로도 같은 데이터를 표현할 수 있지만, "친구의 친구의 친구"처럼 여러 단계를 거쳐가는 질의를 JOIN으로 풀려고 하면 SQL이 금세 복잡해집니다. 그래프 모델은 이런 다단계 탐색을 시각적인 패턴 그대로 쿼리로 표현할 수 있게 해 줍니다.

1.2 Graph Database를 사용하는 이유

• 복잡한 관계 표현 — 다대다 관계와 계층 구조를 직관적으로 모델링
• 경로 탐색 — 친구의 친구, 추천 시스템 등 연결 기반 쿼리에 최적화
• 패턴 매칭 — MATCH 절로 복잡한 관계 패턴을 간단하게 표현
• 기존 SQL과 통합 — 관계형 테이블과 그래프 테이블을 함께 사용 가능

💡 언제 그래프 DB가 빛을 발하나요?

• 조직도 / 권한 위임 / 분류 체계처럼 깊이가 가변적인 계층 구조
• 소셜 그래프 (친구·팔로우·차단 등 같은 노드 타입 사이의 다양한 관계)
• 추천 엔진 (콜드 스타트 우회: "비슷한 사람이 좋아하는 것")
• 사기 탐지·자금 흐름 추적 (의심 노드를 시작점으로 N단계 확산 분석)
• 지식 그래프·Knowledge Base (엔티티 + 관계 위주 질의)

1.3 Graph Database 핵심 개념

$node_id는 직접 다루면 안됨

$node_id 값은 "{"schema":"dbo","table":"Person","id":0}" 같은 JSON 문자열입니다. 직접 INSERT하거나 비교 키로 외부 시스템에 노출하지 마세요. 대신 PersonId 같은 비즈니스 키로 식별하고, $node_id는 시스템 내부 조인용으로만 씁니다.

2. 환경 설정 및 샘플 데이터

2.1 시나리오: 소셜 네트워크

이 실습에서는 작은 소셜 네트워크를 모델링합니다. 사용자(Person) 5명과 게시물(Post) 3개가 있고, 사용자 간에는 팔로우 관계가, 사용자와 게시물 사이에는 작성/좋아요 관계가 형성됩니다. 앞으로 모든 쿼리는 이 한 장의 그래프를 기준으로 다양한 질문을 던지게 됩니다.

나같은경우엔 sql vm 생성 시 이미지 선택을 잘못했는지, SSMS가 설치되어있지 않았다. 별도로 설치한 후, 연결은

• 서버이름: localhost
• 인증서 신뢰 체크

후 진행하였다.

2.2 Node 테이블 생성

핵심 키워드는 끝부분의 AS NODE 입니다.

-- 사용자 노드 테이블 
CREATE TABLE Person ( 
    PersonId  INT PRIMARY KEY, 
    Name      NVARCHAR(100), 
    Email     NVARCHAR(200),
    JoinDate  DATE DEFAULT GETDATE()
) AS NODE; 
-- 게시물 노드 테이블 
CREATE TABLE Post ( 
    PostId     INT PRIMARY KEY, 
    Title      NVARCHAR(200), 
    Content    NVARCHAR(MAX), 
    CreatedAt  DATETIME2 DEFAULT GETDATE() 
) AS NODE; 

① AS NODE 키워드

테이블 정의 마지막에 AS NODE를 붙이는 것이 그래프 노드 선언의 전부입니다. 이 한 줄로 SQL Server는 내부적으로 $node_id라는 보이지 않는 컬럼을 추가합니다.

② PRIMARY KEY는 별개

PersonId는 우리가 부여하는 비즈니스 식별자, $node_id는 시스템이 부여하는 그래프 식별자입니다. 두 개가 공존하며 역할이 다릅니다.

③ 일반 컬럼은 자유

Name, Email 등 평소 테이블 만들듯이 컬럼을 자유롭게 추가하면 됩니다. 그래프 테이블도 본질은 일반 테이블입니다.

④ Post 테이블도 동일 패턴

Person과 똑같이 AS NODE로 끝맺기만 하면 됩니다. 노드 타입이 두 종류 이상이어도 패턴은 같습니다.

Person, Post 두 테이블이 생성되며, 각 테이블에는 우리가 정의한 컬럼 외에 $node_id가 숨겨진 형태로 추가됩니다. sys.tables 카탈로그 뷰에서 is_node = 1로 표시되며, sys.columns에서 graph_type 값을 가진 시스템 컬럼들이 함께 보입니다. 아직 데이터는 비어 있고, 두 테이블 사이에는 어떤 관계도 없습니다 — 관계는 다음 단계의 Edge 테이블이 담당합니다.

2.3 Edge 테이블 생성

-- 팔로우 관계 (Person → Person) 
CREATE TABLE follows ( 
    FollowDate DATE DEFAULT GETDATE() 
) AS EDGE; 

-- 좋아요 관계 (Person → Post) 
CREATE TABLE likes ( 
    LikedAt DATETIME2 DEFAULT GETDATE() 
) AS EDGE; 

-- 작성 관계 (Person → Post) 
CREATE TABLE wrote AS EDGE; 

① AS EDGE 키워드

엣지 테이블이 됨을 선언합니다. 자동으로 $edge_id, $from_id, $to_id 세 개의 컬럼이 생성됩니다.

② 엣지 속성 컬럼

follows의 FollowDate처럼, 관계 자체에 대한 메타데이터(언제 맺어졌는지, 가중치 등)를 컬럼으로 자유롭게 둘 수 있습니다.

③ 컬럼 없는 엣지도 가능

wrote 테이블처럼 사용자 정의 컬럼이 하나도 없어도 됩니다. AS EDGE만 있으면 시스템 컬럼만으로 동작합니다.

④ 방향성

엣지는 항상 $from_id → $to_id 방향을 갖습니다. 양방향 관계를 표현하고 싶다면 동일한 엣지를 반대 방향으로 한 번 더 INSERT 하면 됩니다.

⚠️ 엣지 테이블에는 PRIMARY KEY를 두지 않습니다 $edge_id가 시스템 PK 역할을 자동으로 하므로 굳이 추가 PK를 둘 필요가 없습니다. 추가 PK를 두면 같은 두 노드 사이에 여러 엣지(예: 같은 사람이 같은 게시물을 시점을 달리해 두 번 좋아요)를 만들 수 없게 되어 오히려 모델링이 어색해집니다. PRIMARY KEY가 없다고 해서 취소 여부를 못 아는 게 아니라, 엣지 테이블에 FollowedAt, UnfollowedAt, IsActive 같은 속성을 넣어서 관계 자체를 상태 데이터로 관리하는게 보통입니다.

혹은 SCD를 사용한다.

SCD

데이터 웨어하우스에서 “시간이 지나며 바뀌는 데이터”를 어떻게 관리할지에 대한 패턴 | 구분 | Type 1 | Type 2 | | -------- | --------- | ---------------- | | 데이터 변경 시 | 기존 데이터 수정 | 새 행 추가 | | 과거 데이터 | 사라짐 | 유지 | | 테이블 크기 | 작음 | 커짐 | | 구현 난이도 | 쉬움 | 복잡 | | 분석 용도 | 현재 상태 중심 | 이력 분석 가능 | | 예시 | 최신 프로필 | 팔로우 이력, 주소 변경 이력 |

2.4 샘플 데이터 삽입

노드 데이터를 먼저 삽입한 후, 엣지 데이터를 삽입합니다. 이 순서는 매우 중요합니다 — 엣지가 참조할 노드가 먼저 존재해야 합니다.

① 노드 데이터

-- 사용자 노드 삽입 
INSERT INTO Person (PersonId, Name, Email) VALUES 
    (1, N'김원일', 'kim@example.com'), 
    (2, N'이두석', 'lee@example.com'), 
    (3, N'박삼현', 'park@example.com'), 
    (4, N'정사람', 'jung@example.com'), 
    (5, N'오동현', 'oh@example.com');   

-- 게시물 노드 삽입 
INSERT INTO Post (PostId, Title, Content) VALUES 
    (101, N'Azure SQL 시작하기', N'Azure SQL의 기본 사용법을 알아봅니다…'), 
    (102, N'Graph DB 활용법',    N'소셜 네트워크 구현 예제입니다…'), 
    (103, N'성능 최적화 팁',     N'쿼리 성능을 향상시키는 방법…'); 

② 엣지 데이터 (follows)

-- 팔로우 관계 삽입 (누가 누구를 팔로우하는지) 
INSERT INTO follows ($from_id, $to_id) VALUES 
    ((SELECT $node_id FROM Person WHERE PersonId = 1), 
     (SELECT $node_id FROM Person WHERE PersonId = 2)),     -- 김원일 → 이두석 

    ((SELECT $node_id FROM Person WHERE PersonId = 1), 
     (SELECT $node_id FROM Person WHERE PersonId = 3)),     -- 김원일 → 박삼현 

    ((SELECT $node_id FROM Person WHERE PersonId = 2), 
     (SELECT $node_id FROM Person WHERE PersonId = 3)),     -- 이두석 → 박삼현 

    ((SELECT $node_id FROM Person WHERE PersonId = 3), 
     (SELECT $node_id FROM Person WHERE PersonId = 4)),     -- 박삼현 → 정사람 

    ((SELECT $node_id FROM Person WHERE PersonId = 4), 
     (SELECT $node_id FROM Person WHERE PersonId = 5));     -- 정사람 → 오동현 

① $from_id, $to_id에 직접 INSERT

엣지를 만들 때는 두 시스템 컬럼 $from_id, $to_id에 값을 채워 넣습니다. 이 값들은 노드의 $node_id (JSON)와 동일한 형태여야 합니다.

② 서브쿼리로 $node_id 조회

JSON 값을 직접 입력하긴 어렵기 때문에, (SELECT $node_id FROM Person WHERE PersonId = 1) 형태로 비즈니스 키 → $node_id 변환을 매번 거칩니다. 이 패턴이 그래프 INSERT의 표준 관용구입니다.

③ 한 INSERT에 여러 엣지

VALUES 절에 행을 콤마로 나열하면 한 번의 INSERT로 여러 엣지를 만들 수 있어 트랜잭션 비용이 줄어듭니다.

④ 결과 그래프

실행이 끝나면 그림 2-1의 follows 5개 엣지가 모두 만들어집니다. 5명의 Person 노드를 잇는 사슬과 분기 구조가 형성됩니다.

Edge Table에 중복 안넣는 방법

팔로우 했다가 취소했다가 팔로하면? 삭제하지 않고 그냥 둔다. 따라서 보통은 중복을 허용한다. 굳이 중복방지를 하고싶다면 조건을 걸면 된다. edge table에 굳이 추가 PK를 두지 않는것도 있다.

③ 엣지 데이터 (wrote, likes)

-- 게시물 작성 관계 
INSERT INTO wrote ($from_id, $to_id) VALUES 
    ((SELECT $node_id FROM Person WHERE PersonId = 1), 
     (SELECT $node_id FROM Post   WHERE PostId   = 101)),  -- 김원일 → Post 101 
    ((SELECT $node_id FROM Person WHERE PersonId = 2), 
     (SELECT $node_id FROM Post   WHERE PostId   = 102)),  -- 이두석 → Post 102 
    ((SELECT $node_id FROM Person WHERE PersonId = 3), 
     (SELECT $node_id FROM Post   WHERE PostId   = 103));  -- 박삼현 → Post 103 

-- 좋아요 관계 
INSERT INTO likes ($from_id, $to_id) VALUES 
    ((SELECT $node_id FROM Person WHERE PersonId = 2), 
     (SELECT $node_id FROM Post   WHERE PostId   = 101)), 
    ((SELECT $node_id FROM Person WHERE PersonId = 3), 
     (SELECT $node_id FROM Post   WHERE PostId   = 101)), 
    ((SELECT $node_id FROM Person WHERE PersonId = 1), 
     (SELECT $node_id FROM Post   WHERE PostId   = 102)); 

🎯 실습 과제 1

과제 1-A.

새 사용자 "최여섯"(PersonId=6)을 INSERT한 뒤, 김원일이 최여섯을 팔로우하는 엣지를 추가하세요.

INSERT INTO Person (PersonId, Name) VALUES 
(6,N'최여섯');

INSERT INTO follows ($from_id, $to_id) VALUES 
    ((SELECT $node_id FROM Person WHERE PersonId = 1), 
     (SELECT $node_id FROM Person WHERE PersonId = 6));     -- 김원일 → 최여섯 

과제 1-B.

SELECT * FROM Person; 과 SELECT * FROM follows; 를 각각 실행해서 $node_id, $from_id, $to_id 값이 실제로 어떻게 생겼는지 눈으로 확인해 보세요.

SELECT * FROM Person;
SELECT * FROM follows;

과제 1-C.

시스템 카탈로그를 사용해 이 데이터베이스의 모든 노드 테이블과 엣지 테이블을 나열해 보세요. 힌트: SELECT name, is_node, is_edge FROM sys.tables WHERE is_node = 1 OR is_edge = 1;

3. MATCH — 그래프 패턴 쿼리

3.1 이론

노드와 엣지를 ASCII 아트처럼 그려서 패턴을 정의하면, SQL Server가 그래프를 따라가며 그 패턴에 맞는 모든 경로를 찾아옵니다.

핵심은 "코드에 그린 그림이 곧 찾고자 하는 패턴"이라는 점입니다. (A)-(e)->(B) 라고 쓰면 노드 A에서 엣지 e를 타고 노드 B로 가는 모든 쌍을 찾는다는 의미가 됩니다.

3.2 기본 패턴 매칭

직접 연결된 노드 찾기

SELECT 
    Person1.Name AS Follower, 
    Person2.Name AS Following 
FROM Person AS Person1, follows, Person AS Person2 
WHERE MATCH(Person1-(follows)->Person2) 
  AND Person1.Name = N'김원일'; 

① FROM 절에 노드와 엣지 모두 나열

같은 Person 테이블이지만 시작 노드와 끝 노드 두 역할로 쓰이므로, 별칭 Person1, Person2로 두 번 나타나게 합니다. 가운데 follows는 엣지 테이블 그 자체입니다.

② WHERE MATCH(...) — 패턴 정의

MATCH 절은 "Person1에서 follows 엣지를 타고 Person2로 가는 경로"를 의미합니다. SQL Server는 이 표현을 "follows.$from_id = Person1.$node_id AND follows.$to_id = Person2.$node_id"라는 조건으로 내부 변환합니다.

③ AND Person1.Name = N'김원일' — 시작점 고정

MATCH 패턴 자체에 비교 조건을 끼워 넣지 않습니다. 시작 노드를 좁히고 싶을 때는 일반 WHERE 절처럼 AND로 추가합니다.

④ SELECT — 무엇을 가져올지 결정

Person1.Name(팔로워), Person2.Name(팔로잉 대상)을 컬럼명으로 반환합니다. 같은 테이블에서 두 행을 동시에 다루는 self-join 같은 효과를 MATCH 한 줄로 깔끔하게 만든 셈입니다.

역방향 탐색

이번엔 반대로, "박삼현을 팔로우하는 사람들"을 조회합니다. 두 가지 동등한 표현이 있습니다.

-- 방법 A : 순방향 패턴 + 끝 노드를 박삼현으로 고정 
SELECT Person1.Name AS Follower 
FROM Person AS Person1, follows, Person AS Person2 
WHERE MATCH(Person1-(follows)->Person2) 
  AND Person2.Name = N'박삼현'; 

-- 방법 B : 역방향 화살표 사용 
SELECT Person1.Name AS Follower 
FROM Person AS Person1, follows, Person AS Person2 
WHERE MATCH(Person2<-(follows)-Person1) 
  AND Person2.Name = N'박삼현'; 

💡 두 표현은 어떻게 다른가요? 결과는 동일합니다. SQL Server가 동일한 실행 계획으로 평가하기 때문에 성능 차이도 없습니다. 가독성 차이만 있습니다. "박삼현 입장에서 자기를 팔로우하는 사람"이라는 관점이 자연스러울 때는 방법 B가 읽기 쉽고, "전체 팔로우 관계 중 끝점이 박삼현"이라는 관점이라면 방법 A가 자연스럽습니다.

3.3 다중 홉(Multi-hop) 탐색

관계형으로는 N홉마다 JOIN이 N-1번 늘어나지만, 그래프에서는 패턴에 화살표를 더 이어붙이기만 하면 됩니다.

친구의 친구 찾기 (2-hop)

SELECT DISTINCT 
    Person1.Name AS Person, 
    Person2.Name AS Friend, 
    Person3.Name AS FriendOfFriend 
FROM 
    Person AS Person1, 
    follows AS f1, 
    Person AS Person2, 
    follows AS f2, 
    Person AS Person3 
WHERE MATCH(Person1-(f1)->Person2-(f2)->Person3) 
  AND Person1.Name = N'김원일' 
  AND Person1.PersonId <> Person3.PersonId;   -- 자기 자신 제외 

① FROM 절이 길어지는 이유

Person1, Person2, Person3 — 같은 Person 테이블의 별칭이 3개. 엣지도 f1, f2 두 개로 별도 별칭을 부여합니다. 한 패턴 안에 같은 테이블이 여러 번 등장할 수 있기 때문에 별칭은 필수입니다.

② MATCH 패턴 — 화살표 잇기

Person1-(f1)->Person2-(f2)->Person3. 두 엣지가 가운데 노드 Person2를 공유하면서 자연스럽게 이어집니다. 그래프의 ASCII 그림이 곧 우리가 찾고자 하는 경로의 모양.

③ DISTINCT가 필요한 이유

같은 사람이 여러 경로로 도달 가능할 수 있습니다. 예를 들어 X가 다른 두 친구를 통해 동시에 친구의 친구가 되는 경우, DISTINCT 없이는 결과가 중복됩니다.

④ 자기 자신 제외

Person1.PersonId <> Person3.PersonId. 만약 A→B→A라는 상호 팔로우가 있다면 A 자신이 친구의 친구로 잡혀버립니다. 이 조건으로 그런 경우를 제외합니다.

⚠️ 결과 폭발에 주의 N홉 탐색은 평균 차수(degree)의 N제곱에 비례하는 경로 수를 만들어낼 수 있습니다. 평균 팔로우 100명이라면 3홉만 해도 100^3 = 100만 경로 후보가 발생합니다. 실무에서는 보통 2~3홉으로 제한하고, 시작 노드를 명확하게 좁히는 WHERE 조건을 함께 사용합니다.

3단계 연결 탐색 (3-hop)

SELECT DISTINCT 
    P1.Name AS Start, 
    P2.Name AS Hop1, 
    P3.Name AS Hop2, 
    P4.Name AS Hop3 
FROM 
    Person AS P1, follows AS f1, 
    Person AS P2, follows AS f2, 
    Person AS P3, follows AS f3, 
    Person AS P4 
WHERE MATCH(P1-(f1)->P2-(f2)->P3-(f3)->P4) 
  AND P1.Name = N'김원일'; 

4. 복합 패턴 쿼리

4.1 여러 엣지 타입 결합

한 쿼리 안에서 서로 다른 종류의 엣지를 자유롭게 섞을 수 있습니다. 예를 들어 "내가 팔로우하는 사람이 작성한 게시물"은 follows + wrote 두 엣지 타입을 거치는 패턴입니다.

내가 팔로우하는 사람이 작성한 게시물

SELECT 
    Person1.Name  AS Me, 
    Person2.Name  AS Following, 
    Post.Title    AS PostTitle 
FROM 
    Person AS Person1, 
    follows, 
    Person AS Person2, 
    wrote, 
    Post 
WHERE MATCH(Person1-(follows)->Person2-(wrote)->Post) 
  AND Person1.Name = N'김원일'; 

① 서로 다른 노드 타입의 등장

이 쿼리는 Person 노드 두 개와 Post 노드 하나가 한 패턴에 등장합니다. 노드 별칭만 다르게 잡으면 한 그래프 안에 다양한 종류의 노드를 자유롭게 섞을 수 있습니다.

② 두 엣지 타입을 한 패턴에

follows와 wrote는 의미가 전혀 다른 엣지지만, 가운데 Person2 노드를 공유하면서 자연스럽게 이어집니다. 패턴 표현 그대로 "사람을 따라가서 그 사람이 쓴 글까지" 한 줄로 표현되는 셈.

③ 관계형 모델과 비교

같은 결과를 관계형으로 풀려면 Person ⨝ follows ⨝ Person ⨝ wrote ⨝ Post의 4단계 JOIN이 필요합니다. MATCH 패턴은 이 모든 JOIN 조건을 한 줄로 압축합니다.

4.2 조건부 필터링과 집계

팔로워 수 계산

SELECT 
    Person2.Name, 
    COUNT(*) AS FollowerCount 
FROM Person AS Person1, follows, Person AS Person2 
WHERE MATCH(Person1-(follows)->Person2) 
GROUP BY Person2.Name, Person2.PersonId 
ORDER BY FollowerCount DESC; 

▶ 실행 흐름

1) follows 엣지 전체를 훑어 (시작자, 도착자) 쌍을 모두 만든다. 2) Person2(도착자) 기준으로 그룹화한다. 3) 각 그룹의 행 수를 세면 그 사람이 받은 팔로우 수가 된다.

샘플 그래프에서는 박삼현이 2명(김원일, 이두석)으로 1위, 그 외는 모두 1명

인기 게시물 찾기 (좋아요 수 기준)

SELECT 
    Post.Title, 
    COUNT(*) AS LikeCount 
FROM Person, likes, Post 
WHERE MATCH(Person-(likes)->Post) 
GROUP BY Post.PostId, Post.Title 
HAVING COUNT(*) >= 2 
ORDER BY LikeCount DESC; 

① Person 별칭 생략 가능

같은 테이블이 한 패턴에 한 번만 등장하면 별칭(AS …)을 생략하고 테이블명을 그대로 별칭처럼 사용할 수 있습니다. 가독성을 위해 명시하는 것이 보통이지만 짧은 쿼리에서는 생략도 흔합니다.

② GROUP BY에 PK 포함

Title이 같다면 PostId 없이 Title만으로 그룹화하면 잘못 합쳐질 수 있습니다. 비즈니스 키를 GROUP BY에 함께 넣는 습관을 들이세요.

③ HAVING으로 사후 필터

집계 결과에 대한 조건은 WHERE가 아니라 HAVING입니다. "좋아요 2개 이상인 게시물만"이라는 조건이 여기에 해당.

5. 실무 시나리오

5.1 추천 시스템 구현

친구 추천 (공통 친구 기반)

소셜 네트워크의 클래식한 추천 알고리즘 중 하나는 "공통 친구가 많은 사람"을 우선 추천하는 방식입니다. 나의 1-hop 친구(공통 친구)를 거쳐서 도달 가능한 2-hop의 사람을 모두 모은 뒤, 같은 사람이 여러 경로로 도달될수록 점수가 높다고 보는 것이 핵심입니다.

-- 김원일에게 친구 추천: 공통 친구가 많은 사람 
SELECT 
    Recommended.Name AS RecommendedPerson, 
    COUNT(*)         AS CommonFriends 
FROM 
    Person  AS Me, 
    follows AS f1, 
    Person  AS CommonFriend, 
    follows AS f2, 
    Person  AS Recommended 
WHERE MATCH(Me-(f1)->CommonFriend-(f2)->Recommended) 
  AND Me.Name = N'김원일' 
  AND Me.PersonId <> Recommended.PersonId 
  -- 이미 팔로우하는 사람 제외 
  AND NOT EXISTS ( 
        SELECT 1 FROM follows AS existing -- 데이터 존재 여부(TRUE) 를 확인하는 성능 최적화용
        WHERE existing.$from_id = Me.$node_id 
          AND existing.$to_id   = Recommended.$node_id 
  ) 
GROUP BY Recommended.PersonId, Recommended.Name 
ORDER BY CommonFriends DESC; 

① Me-(f1)->CommonFriend-(f2)->Recommended

2-hop 패턴. 가운데 CommonFriend는 "내가 팔로우하는 사람"이자 "Recommended를 팔로우하는 사람" 두 역할을 동시에 수행합니다.

② COUNT(*)의 의미

같은 Recommended가 서로 다른 CommonFriend를 통해 여러 번 도달되면, 그만큼 (Me, CommonFriend, Recommended) 행이 여러 개 나옵니다. 이걸 GROUP BY Recommended로 묶어 COUNT하면 곧 "공통 친구의 수"가 됩니다.

③ 자기 자신 제외

A→B→A 형태의 상호 팔로우가 있을 때 자기가 자기에게 추천되는 것을 막습니다.

④ 이미 팔로우 중인 사람 제외 (NOT EXISTS)

Me.$node_id에서 Recommended.$node_id로 가는 follows 엣지가 이미 존재하면 추천 후보에서 빼야 합니다. NOT EXISTS는 결과 1건만 확인되면 빠르게 끝나기 때문에 NOT IN 보다 효율적이고 NULL 안전합니다.

⑤ 결과 해석

샘플 그래프에서 김원일에게 추천될 수 있는 후보는 정사람뿐(박삼현 → 정사람 경로). 이두석 → 박삼현 경로는 박삼현이 이미 팔로우 중이라 NOT EXISTS에서 걸러집니다.

select 1

• 데이터 값 자체는 필요 없고, 조건을 만족하는 행이 존재하는지만 확인하고 싶을 때
• DB 연결 테스트
• 쿼리 동작 확인용

콘텐츠 추천 (팔로우하는 사람들이 좋아한 게시물)

SELECT 
    Post.Title, 
    COUNT(DISTINCT Following.PersonId) AS LikedByFollowing 
FROM 
    Person  AS Me, 
    follows, 
    Person  AS Following, 
    likes, 
    Post 
WHERE MATCH(Me-(follows)->Following-(likes)->Post) 
  AND Me.Name = N'김원일' 
  -- 내가 이미 좋아요한 게시물 제외 
  AND NOT EXISTS ( 
        SELECT 1 FROM likes AS myLikes 
        WHERE myLikes.$from_id = Me.$node_id 
          AND myLikes.$to_id   = Post.$node_id 
  ) 
GROUP BY Post.PostId, Post.Title 
ORDER BY LikedByFollowing DESC; 

💡 COUNT(*) vs COUNT(DISTINCT …) 차이

여기서 COUNT()를 쓰면 "내 팔로우 친구 한 명이 같은 게시물에 두 번 좋아요한 경우"가 잘못 가중되어 계산됩니다. COUNT(DISTINCT Following.PersonId)는 "이 게시물을 좋아한 (서로 다른) 친구 수"라는 정확한 지표가 됩니다. 데이터 모델상 한 사람이 같은 게시물을 두 번 좋아요 할 수 없다면(원천적으로 안된다면) COUNT()도 무방하지만, 안전한 기본값은 DISTINCT.

5.2 영향력 분석

인플루언서 찾기

"받은 팔로워 수"와 "내 글이 받은 좋아요 수"를 합산해 영향력 점수를 계산합니다. CTE(공통 테이블 표현식)로 두 지표를 따로 구하고 마지막에 LEFT JOIN으로 합치는 패턴입니다.

-- 팔로워 수와 게시물 좋아요 수를 합산한 영향력 점수 
WITH FollowerCounts AS ( 
    SELECT 
        Person2.PersonId, 
        COUNT(*) AS Followers 
    FROM Person AS Person1, follows, Person AS Person2 
    WHERE MATCH(Person1-(follows)->Person2) 
    GROUP BY Person2.PersonId 
), 
LikeCounts AS ( 
    SELECT 
        Author.PersonId, 
        COUNT(*) AS TotalLikes 
    FROM Person AS Liker, likes, Post, wrote, Person AS Author 
    WHERE MATCH(Liker-(likes)->Post<-(wrote)-Author) 
    GROUP BY Author.PersonId 
) 
SELECT 
    p.Name, 
    ISNULL(f.Followers, 0)   AS Followers, 
    ISNULL(l.TotalLikes, 0)  AS TotalLikes, 
    ISNULL(f.Followers, 0) + ISNULL(l.TotalLikes, 0) AS InfluenceScore 
FROM Person p 
LEFT JOIN FollowerCounts f ON p.PersonId = f.PersonId 
LEFT JOIN LikeCounts     l ON p.PersonId = l.PersonId 
ORDER BY InfluenceScore DESC; 

① CTE 1 — FollowerCounts

4.2의 팔로워 수 쿼리를 그대로 가져와 "PersonId별 팔로워 수"를 임시 테이블처럼 다룹니다. CTE는 메인 쿼리에서 한 번만 사용해도 가독성을 크게 높입니다.

② CTE 2 — LikeCounts와 역방향 패턴

Liker-(likes)->Post<-(wrote)-Author. 좋아요한 사람으로부터 게시물로 가고, 그 게시물을 누가 썼는지 역방향으로 가져옵니다. 한 패턴 안에서 "정방향 + 역방향" 혼용이 가능합니다.

③ LEFT JOIN으로 모든 사람 보존

글을 쓴 적 없거나 팔로워가 0인 사람도 결과에 나타나야 합니다. INNER JOIN으로 묶으면 이런 사람이 사라지므로 LEFT JOIN + ISNULL 패턴이 정석.

④ ISNULL로 NULL을 0으로

집계 결과가 없는 사람은 Followers/TotalLikes가 NULL입니다. ISNULL(…, 0)로 0 처리해야 더하기 연산이 망가지지 않습니다.

⚠️ 실무 단순화 주의 "팔로워 수 + 좋아요 수" 단순합은 학습용 예시입니다. 실무에서는 PageRank, HITS, Eigenvector centrality 같은 지표가 훨씬 견고합니다 — "유명한 사람을 많이 팔로우하는 게 단순히 무명인 사람 100명을 팔로우하는 것보다 점수가 높아야" 하기 때문입니다. SQL Graph 자체는 PageRank 내장 함수를 제공하지 않으므로, 본격 분석은 외부 그래프 엔진(Neo4j GDS, Spark GraphFrames 등)이나 Python(networkx)으로 옮겨 수행하는 것이 일반적입니다.

6. SHORTEST_PATH — 최단 경로 탐색

SQL Server 2019부터는 두 노드 간의 최단 경로를 자동으로 찾아주는 SHORTEST_PATH 키워드가 추가되었습니다. "6단계 분리 이론"을 직접 검증해 볼 수 있는 강력한 기능입니다. (Azure SQL Database도 동일한 호환성 레벨에서 지원합니다.)

6.1: "X명까지의 모든 도달 가능 노드"

-- 김원일에서 출발해 follows 경로상 모든 도달 가능한 사람과 거리 
SELECT 
    LAST_VALUE(Person2.Name) WITHIN GROUP (GRAPH PATH) AS Reachable, 
    STRING_AGG(Person2.Name, ' → ') WITHIN GROUP (GRAPH PATH) AS Path, 
    COUNT(Person2.PersonId)  WITHIN GROUP (GRAPH PATH) AS Distance 
FROM 
    Person AS Person1, 
    follows FOR PATH AS f, 
    Person  FOR PATH AS Person2 
WHERE MATCH( SHORTEST_PATH( Person1( -(f)->Person2 )+ ) ) 
  AND Person1.Name = N'김원일' 
ORDER BY Distance; 

이 쿼리는 김원일이 follows 경로로 도달 가능한 모든 사람과 그 사람까지의 최단 거리, 그리고 거치는 경로를 한꺼번에 반환합니다. 거리 1(직접 팔로우), 거리 2(친구의 친구), 거리 3 형태로 자연스럽게 묶입니다.

⚠️SHORTEST_PATH 사용상 주의 SHORTEST_PATH는 "엣지 가중치"를 고려하지 않는 단순 BFS입니다. 가중치가 있는 최단 경로(다익스트라)가 필요하면 SQL Graph로는 직접 구현할 수 없고, 외부 그래프 엔진을 사용해야 합니다. 하나의 패턴 안에 SHORTEST_PATH는 한 번만 사용 가능합니다. 큰 그래프에서는 시작 노드를 매우 좁게 좁히지 않으면 (예: WHERE Person1.Name = …) 폭발적으로 느려질 수 있습니다. 데이터베이스 호환성 레벨이 140 이상(SQL Server 2019, Azure SQL DB 최신)이어야 합니다.

7. 성능 최적화

7.1 인덱스 전략

그래프 테이블도 결국 일반 테이블이므로, 일반 SQL Server의 인덱스 전략이 그대로 적용됩니다. 다만 자주 검색되는 시작 노드의 비즈니스 키와, 엣지의 $from_id, $to_id 시스템 컬럼에 인덱스가 잘 걸려 있는지가 핵심입니다.

-- 노드 테이블의 자주 검색되는 컬럼에 인덱스 
CREATE INDEX IX_Person_Name  ON Person(Name); 
CREATE INDEX IX_Post_Title   ON Post(Title);

-- 엣지 테이블의 시스템 컬럼에 인덱스 (★ 가장 중요) 
CREATE INDEX IX_follows_from ON follows($from_id); 
CREATE INDEX IX_follows_to   ON follows($to_id); 
CREATE INDEX IX_likes_from   ON likes($from_id); 
CREATE INDEX IX_likes_to     ON likes($to_id); 
CREATE INDEX IX_wrote_from   ON wrote($from_id); 
CREATE INDEX IX_wrote_to     ON wrote($to_id); 

① 시작점 좁히기용 인덱스

IX_Person_Name 같은 비즈니스 컬럼 인덱스는 "Name = N'김원일'" 같은 조건이 시작 노드를 빠르게 찾도록 도와줍니다. 시작 노드를 좁히지 못하면 그래프 전체를 훑게 되어 성능 저하의 가장 흔한 원인이 됩니다.

② $from_id, $to_id 인덱스

그래프 탐색은 본질적으로 "엣지의 한쪽 끝 ID를 기준으로 다른 쪽을 찾는" 연산의 반복입니다. 이 두 컬럼이 인덱스 없이 풀 스캔되면 N홉 쿼리가 N제곱으로 느려집니다. 엣지 테이블을 만들면 거의 자동 반사로 두 인덱스를 함께 만드세요.

③ 복합 인덱스 고려

특정 조건(예: 특정 기간의 follows만)이 자주 함께 들어간다면 ($from_id, FollowDate) 같은 복합 인덱스가 더 유리할 수 있습니다. 단순 단일 컬럼 인덱스만 무한정 만드는 것이 능사는 아닙니다.

7.2 모범 사례

1. 명명 규칙

Node는 단수 명사 단수형(Person, Post), Edge는 동사 또는 관계명(follows, likes, wrote). 엣지가 동사형이면 패턴이 자연어처럼 읽힙니다.

2. 데이터 무결성

엣지 제약 조건을 적극 활용해 잘못된 노드 타입 사이에 엣지가 만들어지지 않도록.

3. 성능 모니터링

실행 계획에서 Edge Scan, Filter 비용이 큰 단계를 찾아내고, 인덱스/통계 갱신을 주기적으로 수행.

4. 홉 수 제한

가능한 한 명시적인 N-hop 쿼리(2~3홉)로 작성하고, 무제한 SHORTEST_PATH는 시작 노드가 충분히 좁혀진 경우에만.

8. 관계형 + 그래프 통합

8.1 하이브리드 쿼리

Graph DB의 가장 큰 장점 중 하나는 기존 관계형 테이블과 자유롭게 결합할 수 있다는 점입니다. 그래프 패턴 + 일반 JOIN을 한 쿼리에 섞을 수 있어, 별도 NoSQL 그래프 DB로 ETL할 필요 없이 같은 데이터베이스 안에서 모든 분석을 할 수 있습니다.

-- 가정: 일반 관계형 테이블 UserActivity가 있다 
CREATE TABLE UserActivity ( 
    ActivityId    INT IDENTITY PRIMARY KEY, 
    PersonId      INT, 
    ActivityType  NVARCHAR(50), 
    ActivityDate  DATETIME2 DEFAULT GETDATE() 
); 

-- 그래프 패턴 + 관계형 JOIN을 한 쿼리에 섞기 
SELECT 
    p.Name, 
    COUNT(DISTINCT f2.$to_id)  AS FollowingCount, 
    COUNT(DISTINCT ua.ActivityId) AS RecentActivities 
FROM Person p 
LEFT JOIN follows f2     ON f2.$from_id = p.$node_id 
LEFT JOIN UserActivity ua 
       ON p.PersonId = ua.PersonId 
      AND ua.ActivityDate >= DATEADD(day, -7, GETDATE()) 
GROUP BY p.PersonId, p.Name; 

① $node_id로 직접 JOIN

MATCH 절을 쓰지 않고도, follows 엣지의 $from_id와 Person의 $node_id를 직접 ON 조건으로 묶을 수 있습니다. 그래프 패턴 표현이 어색한 상황에서 유용한 우회로.

② 관계형 테이블과 자연스럽게 결합

UserActivity는 그래프와 무관한 일반 테이블이지만, PersonId라는 비즈니스 키로 자연스럽게 LEFT JOIN됩니다. 같은 데이터베이스 안에 있다는 것의 큰 이점.

③ COUNT(DISTINCT)의 두 용도

f2.$to_id를 DISTINCT 카운트하면 "팔로잉 인원"을, ua.ActivityId를 DISTINCT 카운트하면 "활동 건수"를 동시에 한 GROUP BY 안에서 산출할 수 있습니다. 두 측면을 각각 별도 쿼리로 만들고 합치는 수고를 덜어줍니다.

8.2 그래프 데이터를 JSON으로 내보내기

그래프를 외부 시스템(D3.js, 시각화 도구 등)에 전달할 때 흔한 형식은 nodes/edges가 분리된 JSON입니다.

-- 노드를 JSON 배열로 
SELECT 
    PersonId   AS id, 
    Name       AS label, 
    'Person'   AS type 
FROM Person 
FOR JSON PATH, ROOT('nodes');  

-- 엣지를 JSON 배열로 
SELECT 
    Person1.PersonId   AS source, 
    Person2.PersonId   AS target, 
    'follows'          AS type 
FROM Person AS Person1, follows, Person AS Person2 
WHERE MATCH(Person1-(follows)->Person2) 
FOR JSON PATH, ROOT('edges'); 

💡 FOR JSON PATH의 결과 형태 { "nodes": [ {"id":1,"label":"김원일","type":"Person"}, … ] } 형태가 한 줄로 반환됩니다. 필요하면 두 쿼리 결과를 애플리케이션 단에서 합쳐 { nodes:[…], edges:[…] } 형태로 만든 뒤 D3.js force layout 등으로 렌더링하면 됩니다. 대용량 그래프라면 FOR JSON 결과가 행당 2GB 한도에 부딪힐 수 있으므로 페이지 단위로 잘라 내보내는 패턴이 안전합니다.

9. 자주 하는 실수 / 트러블슈팅

9.1 노드/엣지 정의 실수

⚠️ 실수 1: AS NODE / AS EDGE 키워드 누락

증상: 평범한 테이블이 만들어지지만, 이후 MATCH 쿼리에서 "테이블이 그래프 노드/엣지가 아닙니다" 류 에러가 발생.

원인: CREATE TABLE 마지막의 AS NODE 또는 AS EDGE를 빠뜨림.

해결: 테이블을 DROP한 뒤 다시 생성하거나, 새 그래프 테이블을 만들고 데이터를 옮긴 뒤 교체. (일반 테이블 → 그래프 테이블로의 자동 변환은 지원되지 않음.)

⚠️ 실수 2: 엣지 테이블에 PRIMARY KEY 추가

증상: 같은 두 노드 사이에 여러 엣지를 만들 수 없게 됨. 예) "한 사람이 같은 게시물을 두 번 좋아요"가 안 됨.

원인: $edge_id가 시스템 PK 역할을 하는데, 추가로 사용자 PK를 두면 의도치 않은 유일성 제약이 걸림.

해결: 엣지 테이블에는 일반 PK를 두지 않습니다. 유일성이 정말 필요하면 UNIQUE INDEX로 명시적으로 표현.

9.2 INSERT 단계의 실수

⚠️ 실수 3: $node_id를 직접 INSERT하려 함

증상: "$node_id 컬럼에 직접 값을 삽입할 수 없습니다" 류 에러.

원인: $node_id는 시스템이 자동 생성하는 컴퓨티드 컬럼. 사용자가 값을 넣을 수 없습니다.

해결: INSERT INTO Person (PersonId, Name, …) VALUES … 형태로, 시스템 컬럼은 빼고 비즈니스 컬럼만 명시.

⚠️ 실수 4: 엣지 INSERT 시 NULL $from_id / $to_id

증상: 엣지가 만들어졌지만 MATCH 쿼리에서 잡히지 않음.

원인: 서브쿼리 (SELECT $node_id FROM Person WHERE PersonId = 999)가 매칭 행이 없어 NULL을 반환했고, NULL인 채로 INSERT됨.

해결: 서브쿼리 작성 시 비즈니스 키가 실제 존재하는지 먼저 확인. 또는 INSERT 전에 EXISTS 체크를 추가하거나, 트랜잭션 + RAISERROR 패턴으로 안전망 구성.

9.3 MATCH 절 작성 실수

⚠️ 실수 5: MATCH를 SELECT 절에 적음

증상: "MATCH 절은 WHERE 절에서만 사용할 수 있습니다" 에러.

원인: 익숙한 SQL 사고방식으로 SELECT나 FROM 위치에 MATCH를 두려고 함.

해결: MATCH는 반드시 WHERE 절 안에 위치. 일반 비교 조건은 AND로 자유롭게 결합.

⚠️ 실수 6: FROM 절에 같은 테이블 별칭 누락

증상: "Person이 두 번 사용되었지만 별칭이 없습니다" 류 에러.

원인: 한 패턴에 같은 노드 타입이 여러 번 등장할 때 별칭(AS Person1, AS Person2)을 부여하지 않음.

해결: 같은 테이블이 한 패턴에 두 번 이상 나오면 반드시 다른 별칭을 부여.

⚠️ 실수 7: MATCH 패턴 안에 비교 연산자

증상: 컴파일 에러.

원인: MATCH(Person1.Name = N'김원일'-(follows)->Person2) 처럼 패턴 안에 일반 비교를 넣으려 함.

해결: MATCH 안에는 그래프 패턴만. 일반 비교는 AND로 분리.

9.4 SHORTEST_PATH 관련 실수

⚠️ 실수 8: FOR PATH 키워드 누락

증상: "SHORTEST_PATH 함수의 인수에는 FOR PATH 별칭이 필요합니다" 류 에러.

원인: 가변 길이 패턴 안의 노드/엣지 변수에 FOR PATH 표시가 빠짐.

해결: follows FOR PATH AS f, Person FOR PATH AS Person2 형태로 모든 반복 패턴 변수에 FOR PATH 추가.

⚠️ 실수 9: 호환성 레벨이 낮음

증상: SHORTEST_PATH 키워드 자체를 인식하지 못함.

원인: 데이터베이스 호환성 레벨 < 140.

해결: ALTER DATABASE [DBName] SET COMPATIBILITY_LEVEL = 140; (또는 더 높음). Azure SQL DB에서는 보통 자동으로 최신 레벨이지만, 마이그레이션된 DB는 확인 필요.

9.5 성능 관련 실수

⚠️ 실수 10: 시작 노드를 좁히지 않은 N-hop 쿼리

증상: 데이터가 조금만 커져도 쿼리가 수십 초 ~ 수 분.

원인: WHERE 절에 시작 노드를 좁히는 조건이 없어, 모든 노드 쌍에 대해 N-hop 패턴을 평가함.

해결: AND Person1.Name = …, Person1.PersonId = … 같은 시작 노드 식별 조건을 반드시 함께 사용. 인덱스(7.1)도 함께 점검.

⚠️ 실수 11: $from_id / $to_id 인덱스 부재

증상: 작은 그래프에서는 빠르지만 데이터 증가에 따라 N제곱으로 느려짐.

원인: 엣지의 $from_id, $to_id에 인덱스가 없어, 매 홉마다 풀 스캔.

해결: 7.1의 모든 엣지 테이블에 ($from_id), ($to_id) 인덱스를 만들고, 통계를 최신 상태로 유지.

9.6 진단용 SQL 모음

-- (1) 모든 그래프 테이블 목록 
SELECT name, is_node, is_edge 
FROM sys.tables 
WHERE is_node = 1 OR is_edge = 1; 

-- (2) 그래프 테이블의 시스템 컬럼 확인 
SELECT t.name AS TableName, c.name AS ColumnName, c.graph_type_desc 
FROM sys.tables t 
JOIN sys.columns c ON t.object_id = c.object_id 
WHERE (t.is_node = 1 OR t.is_edge = 1) AND c.graph_type IS NOT NULL 
ORDER BY t.name, c.column_id;  

-- (3) 엣지 제약 조건 목록 
SELECT OBJECT_NAME(parent_object_id) AS EdgeTable, name AS ConstraintName 
FROM sys.edge_constraints; 

-- (4) 호환성 레벨 확인 
SELECT name, compatibility_level 
FROM sys.databases 
WHERE name = DB_NAME(); 

Neo4j와 Azure 기반 금융 사기 탐지 실습

1장. 그래프 데이터베이스 이론

1.4 LPG vs RDF — 두 가지 그래프 모델

LPG(Labeled Property Graph) 는 노드와 엣지에 ‘라벨(타입)’을 붙이고 ‘속성(key=value)’을 자유롭게 달 수 있는 모델로, Neo4j가 대표적입니다. RDF(Resource Description Framework) 는 W3C 표준으로 모든 데이터를 ‘주어-서술어-목적어(triple)’로 표현하며, 시맨틱 웹과 지식 그래프 분야에서 강세입니다. 실무에서는 표현력과 학습 곡선의 균형이 좋은 LPG가 더 널리 채택되고 있습니다.

1.5 그래프 DB를 써야 할 ‘세 가지 신호’

모든 데이터를 그래프에 담으려는 것은 망치를 든 사람에게 모든 것이 못으로 보이는 함정입니다. 다음 중 둘 이상이 해당될 때 그래프 DB가 적합합니다.

• 관계의 깊이가 3-hop 이상. SNS의 친구 추천, 사기 탐지의 우회 거래 등.
• 관계 자체가 분석 대상. ‘무엇이 연결되어 있는가’가 ‘무엇이 있는가’보다 중요한 도메인. 지식 그래프, 추천 시스템, 사회망 분석.
• 스키마가 자주 변하거나 다양한 관계 타입이 등장. 새로운 관계 타입을 추가하려고 매번 ALTER TABLE을 하지 않아도 됨.

  단순 트랜잭션 처리(OLTP), 회계장부형 데이터, 전통적 보고서 생성, 컬럼 단위 집계 분석 등은 RDB나 데이터 웨어하우스가 훨씬 효율적입니다. 그래프 DB를 강제로 도입하면 오히려 복잡도만 늘어납니다.

1.6 주요 제품 비교

2장. Neo4j 핵심 개념

2.1 Neo4j 아키텍처 한눈에

Neo4j는 JVM 위에서 동작하는 단일 프로세스 데이터베이스입니다. 클라이언트는 두 가지 프로토콜로 접속합니다. HTTP(7474)는 웹 브라우저 기반 Neo4j Browser용이고, Bolt(7687)은 애플리케이션 드라이버용 바이너리 프로토콜입니다. 스토리지는 ‘기록 파일(record store)’ 구조로, 각 노드와 관계는 고정 크기 레코드로 저장되어 ID 기반 직접 접근(O(1))이 가능합니다. 이것이 N-hop 트래버설이 빠른 핵심 비결입니다 — JOIN 비용 없이 인접 관계의 메모리 주소를 바로 따라갑니다(‘index-free adjacency’).

2.2 LPG 데이터 모델

| 구성요소 | 설명 | 예시 |
|----------|------|------|
| Node | 개체, 라벨로 타입 구분 | (:Account) |
| Relationship | 노드 사이의 방향성 있는 관계 | [:TRANSFER] |
| Property | 노드/관계에 붙는 key=value 데이터 | {amount: 89500000} |
| Label | 노드의 분류 태그 (다중 부착 가능) | :Account:HighRisk |

2.3 Cypher 쿼리 언어

Cypher는 Neo4j가 만든 그래프 질의 언어로, 2018년 ISO/IEC GQL 표준의 기반이 되었습니다. 핵심 아이디어는 ‘ASCII 아트로 패턴을 그린다’ 입니다.

// '계좌 A가 계좌 B에게 송금했다'를 그림으로
MATCH (a:Account)-[:TRANSFER]->(b:Account)
RETURN a, b
LIMIT 5;

2.4 인덱스와 제약조건

인덱스 없는 그래프 DB는 인덱스 없는 RDB보다도 더 빨리 느려집니다. 첫 노드를 어떻게 ‘찾을 것인가(seek)’가 트래버설의 시작점이기 때문입니다. Neo4j 5.x에서는 다음 두 가지를 거의 항상 만들어 둡니다.

// 고유성 제약 (자동으로 인덱스 생성됨)
CREATE CONSTRAINT account_id IF NOT EXISTS
  FOR (a:Account) REQUIRE a.accountId IS UNIQUE;

// 일반 인덱스 (자주 조회하는 속성)
CREATE INDEX account_country IF NOT EXISTS
  FOR (a:Account) ON (a.country);

2.5 GDS — Graph Data Science 라이브러리

Neo4j의 진가는 단순 패턴 매칭을 넘어 그래프 알고리즘까지 한 자리에서 실행할 수 있다는 점입니다. GDS 라이브러리는 다음과 같은 알고리즘을 한 줄로 호출할 수 있게 해 줍니다.

📌 GDS의 동작 원리 GDS는 디스크의 그래프를 그대로 쓰지 않고, 분석 대상 부분을 ‘메모리에 투영(project)’한 뒤 알고리즘을 돌립니다. 큰 그래프에서도 빠른 이유이자, 분석이 끝나면 명시적으로 drop하지 않으면 메모리에 남는 이유이기도 합니다.

3장. Azure 환경 구축

NSG로 본인 IP만 허용 → 7474, 7687 포트 한정 개방

이후 vm 내에서 neo4j 설치

• APT 업데이트 + Java 21 설치 — Neo4j 5.x는 OpenJDK 21을 요구합니다.
• Neo4j 공식 GPG 키 + APT 저장소 등록 — debian.neo4j.com을 신뢰 저장소로 추가.
• apt install neo4j — 5.26.x 안정 버전 설치.
• 외부 접속 허용 — 기본은 127.0.0.1만 listen하므로 0.0.0.0으로 변경. 보안은 NSG가 담당.
• 서비스 시작 + 검증 — systemctl로 부팅 시 자동 시작 등록.

💡 메모리 튜닝의 황금률 Neo4j 성능의 80%는 메모리 설정이 좌우합니다. 일반적으로 'heap size 2~4GB' + '나머지 메모리는 page cache'에 할당합니다. 본 실습은 8GB VM 기준 heap 2GB + page cache 1GB로 설정합니다

4장. OpenPay 시나리오

4.1 도메인 모델링

💡 모델링 원칙 ‘속성으로 표현할 수 있는 것은 노드로 만들지 마라.’ 처음 입문하면 거래 채널(MOBILE/WEB/ATM)도 노드로 만들고 싶어지지만, 이는 트래버설을 무겁게 만들 뿐입니다. 채널은 TRANSFER 관계의 속성으로 충분합니다. 반면 ‘디바이스’는 여러 계좌가 ‘공유’할 가능성이 핵심이므로 반드시 노드여야 합니다.

4.2 데이터 적재

부속 코드 02-data-generation/generate_data.py는 결정론적 시드(SEED=20260506)로 다음 데이터를 생성

// CSV 파일을 한 줄씩 읽어 노드 생성
LOAD CSV WITH HEADERS FROM 'file:///accounts.csv' AS row
CREATE (a:Account {
  accountId: row.accountId,
  name:      row.name,
  country:   row.country,
  createdAt: datetime(row.createdAt)
});

// 관계는 양 끝 노드를 MATCH로 찾고 CREATE
LOAD CSV WITH HEADERS FROM 'file:///transactions.csv' AS row
CALL {
  WITH row
  MATCH (src:Account {accountId: row.fromAccount})
  MATCH (dst:Account {accountId: row.toAccount})
  CREATE (src)-[t:TRANSFER {
    txId:      row.txId,
    amount:    toFloat(row.amount),
    timestamp: datetime(row.timestamp),
    channel:   row.channel
  }]->(dst)
} IN TRANSACTIONS OF 1000 ROWS;

⚠ Neo4j 5.x의 변화 Neo4j 4.x에서 쓰던 'USING PERIODIC COMMIT'은 5.x에서 deprecated되었습니다. 대신 'CALL { ... } IN TRANSACTIONS OF N ROWS' 패턴을 사용해야 큰 CSV도 메모리 부족 없이 적재됩니다.

MATCH (a:Account)   RETURN 'Account'    AS label, count(a) AS cnt
UNION ALL
MATCH ()-[r:TRANSFER]->() RETURN 'TRANSFER' AS label, count(r) AS cnt;

5장. Cypher 사기 탐지 실습

5.1 [ORG-5] 허브 계좌 — 단순 집계로 시작

가장 쉬운 패턴은 ‘비정상적으로 많이 받는 계좌’입니다. RDB의 GROUP BY와 본질적으로 같습니다.

MATCH (sender:Account)-[t:TRANSFER]->(receiver:Account)
RETURN receiver.accountId AS account,
       count(t)           AS in_count,
       sum(t.amount)      AS total_received
ORDER BY in_count DESC
LIMIT 10;

5.2 [ORG-3] SMURFING — WHERE 조건으로 패턴 좁히기

‘100만원 미만 거래를 같은 수신자에게 10회 이상’ — CTR(고액현금거래보고) 기준선을 회피하려는 분할 송금 패턴입니다. WHERE로 금액 임계값을 걸고 count()로 횟수를 셉니다.

MATCH (s:Account)-[t:TRANSFER]->(r:Account)
WHERE t.amount < 1000000
WITH s, r, count(t) AS n_tx, sum(t.amount) AS total
WHERE n_tx >= 10
RETURN s.accountId AS sender,
       r.accountId AS receiver,
       n_tx        AS tx_count,
       round(total) AS total_amount
ORDER BY n_tx DESC;

5.3 [ORG-2] 디바이스 공모 — 양방향 패턴

‘한 디바이스를 여러 계좌가 공유한다’는 SQL로 표현하면 GROUP BY device + HAVING count(*) >= N입니다. Cypher에서는 패턴이 거의 그림 그대로 — (a)-[:OWNS]->(d)<-[:OWNS]-(b) 가 ‘서로 다른 두 계좌가 같은 디바이스를 가리킨다’는 뜻입니다.

MATCH (a:Account)-[:OWNS]->(d:Device)
WITH d, collect(DISTINCT a.accountId) AS accounts
WHERE size(accounts) >= 8
RETURN d.deviceId AS device,
       size(accounts) AS n_accounts,
       accounts
ORDER BY n_accounts DESC;

💡 노이즈는 학습 자료다 결과에 의도 외 계좌가 섞여 있는 것은 버그가 아닙니다. 현실 데이터에는 ‘우연히’ 같은 디바이스를 쓴 가족, 한 디바이스를 두 명이 공유하는 부부 등이 늘 섞여 있습니다. 이런 노이즈와 진짜 사기를 구분하는 능력 자체가 분석가의 몫입니다.

5.4 [ORG-4] 해외 IP 공모 — 다중 조건 결합

디바이스 공모와 같은 패턴이지만 IP가 대상이고, 추가로 ‘국가가 한국이 아님’이라는 조건이 붙습니다.

MATCH (a:Account)-[:USED]->(ip:IPAddress)
WITH ip, collect(DISTINCT a.accountId) AS accounts
WHERE size(accounts) >= 10
  AND ip.country <> 'KR'
RETURN ip.ipId, ip.address, ip.country, ip.isProxy,
       size(accounts) AS n_accounts, accounts
ORDER BY n_accounts DESC;

5.5 [ORG-1] 자금세탁 순환 — 그래프 DB의 강점

여기까지의 패턴은 RDB도 어떻게든 풀 수 있습니다. 하지만 ‘N개 계좌를 거쳐 자금이 출발지로 돌아오는 순환’은 RDB로는 사실상 불가능합니다. 자기 조인 4번을 짜야 하고, 각 단계마다 시간 순서까지 비교해야 하기 때문입니다. Cypher에서는 단 한 줄. 시작 노드와 끝 노드를 같은 변수 a로 묶기만 하면 됩니다.

MATCH path = (a:Account)-[t1:TRANSFER]->(b:Account)
                        -[t2:TRANSFER]->(c:Account)
                        -[t3:TRANSFER]->(d:Account)
                        -[t4:TRANSFER]->(a)
WHERE a <> b AND b <> c AND c <> d AND d <> a
  AND t1.timestamp < t2.timestamp
  AND t2.timestamp < t3.timestamp
  AND t3.timestamp < t4.timestamp
  AND t1.amount > 10000000
RETURN a.accountId, b.accountId, c.accountId, d.accountId,
       round(t1.amount) AS amt1,
       round(t4.amount) AS amt4,
       duration.between(t1.timestamp, t4.timestamp).hours AS hours;

의심도 점수 매기기 탐지를 넘어 우선순위를 매기는 것이 분석가의 다음 일입니다. 다음 두 신호가 강할수록 의심도가 높습니다. (1) 거래 간격이 짧을수록 — 자동화된 자금세탁일 가능성, (2) 금액이 비슷할수록 — 수수료 정도만 빠지는 패턴.

6장. GDS 알고리즘 응용

gds 설치

cd /var/lib/neo4j/plugins/
sudo wget https://github.com/neo4j/graph-data-science/releases/download/2.13.2/neo4j-graph-data-science-2.13.2.jar -O neo4j-graph-data-science.jar

sudo systemctl restart neo4j

6.1 그래프 프로젝션 — GDS의 첫 단계

GDS는 디스크 그래프가 아닌 ‘메모리 투영본’에서 알고리즘을 돌립니다. 분석할 부분만 골라 메모리에 올리는 작업이 프로젝션입니다.

CALL gds.graph.project(
  'fraud-graph',
  'Account',
  {
    TRANSFER: {
      orientation: 'NATURAL',
      properties: 'amount'
    }
  }
);

6.2 PageRank — 허브 식별의 정교한 버전

PageRank는 본래 1998년 구글 검색이 등장하면서 ‘웹페이지 중요도’를 매기기 위해 만들어졌습니다. 핵심 직관은 ‘중요한 페이지로부터 링크받은 페이지는 중요하다’ 입니다. 이 직관을 거래 그래프에 적용하면, 단순 ‘수신 건수’를 넘어 ‘중요한 계좌로부터 송금받은 계좌’가 더 높은 점수를 받습니다.

CALL gds.pageRank.stream('fraud-graph', {
  maxIterations: 20,
  dampingFactor: 0.85,
  relationshipWeightProperty: 'amount'
})
YIELD nodeId, score
WITH gds.util.asNode(nodeId) AS account, score
RETURN account.accountId, round(score * 100) / 100 AS pagerank
ORDER BY pagerank DESC LIMIT 10;

6.3 Weakly Connected Components — 공모 집단

WCC는 ‘방향 무시하고 한 덩어리로 연결된 노드들’을 찾는 알고리즘입니다. 디바이스/IP 공유 그래프에서 연결된 컴포넌트는 곧 ‘같은 자원을 통해 연결된 계좌 집단’ — 즉 잠재적 공모 그룹입니다.

CALL gds.graph.project.cypher(
  'shared-resource-graph',
  'MATCH (a:Account) RETURN id(a) AS id',
  '
   MATCH (a1:Account)-[:OWNS]->(:Device)<-[:OWNS]-(a2:Account)
   WHERE id(a1) < id(a2)
   RETURN id(a1) AS source, id(a2) AS target
   UNION
   MATCH (a1:Account)-[:USED]->(:IPAddress)<-[:USED]-(a2:Account)
   WHERE id(a1) < id(a2)
   RETURN id(a1) AS source, id(a2) AS target
  '
);

CALL gds.wcc.stream('shared-resource-graph')
YIELD nodeId, componentId
WITH componentId, collect(gds.util.asNode(nodeId).accountId) AS members
WHERE size(members) >= 6
RETURN componentId, size(members) AS size, members
ORDER BY size DESC;

6.4 Louvain — 거래 흐름 기반 커뮤니티

Louvain은 모듈러리티 최적화 기반 커뮤니티 탐지 알고리즘입니다. ‘안에서는 빽빽하게 연결되어 있고, 밖으로는 듬성듬성 연결된’ 노드 집단을 찾습니다. 거래 흐름에 적용하면 ‘끼리끼리 거래하는 그룹’이 드러납니다.

CALL gds.louvain.stream('fraud-graph', {
  relationshipWeightProperty: 'amount'
})
YIELD nodeId, communityId
WITH communityId, collect(gds.util.asNode(nodeId).accountId) AS members
WHERE size(members) >= 3 AND size(members) <=30
RETURN communityId, size(members) AS size, members[0..10] AS sample
ORDER BY size DESC LIMIT 10;

📌 알고리즘의 한계 이해하기 Louvain은 거래 흐름을 보지 디바이스/IP는 보지 않습니다. 즉 ORG-2/ORG-4(자원 공모)는 Louvain만으로는 잡히지 않습니다.

6.5 메모리 정리

CALL gds.graph.drop('fraud-graph') YIELD graphName RETURN graphName;
CALL gds.graph.drop('shared-resource-graph') YIELD graphName RETURN graphName;

SQL Server 성능 튜닝을 제대로 이해하려면 가장 먼저 알아야 하는 것이 바로 인덱스(Index) 이다.

이번 실습에서도:

• Fragmentation
• Key Lookup
• Execution Plan
• Query Store
• Blocking

같은 다양한 성능 이슈를 다뤘지만, 결국 대부분의 문제는 인덱스와 연결되어 있었다.

따라서 본격적인 실습 내용을 보기 전에, 먼저 SQL Server 인덱스 개념을 정리하고 시작한다.

인덱스(Index)란?

인덱스는 데이터를 빠르게 찾기 위한 자료구조이다.

책에서 원하는 내용을 찾을 때:

• 책 전체를 처음부터 끝까지 읽지 않고
• 맨 뒤의 색인(Index)을 먼저 보는 것과 비슷하다.

SQL Server에서도 인덱스가 없다면 원하는 데이터를 찾기 위해 테이블 전체를 읽어야 한다.

이를 Table Scan이라고 한다.

데이터 양이 적을 때는 큰 문제가 없지만, 데이터가 수백만 건 이상으로 증가하면 성능 차이가 매우 커진다.

인덱스가 필요한 이유

1. 검색 속도 향상

인덱스는 원하는 데이터 위치를 빠르게 찾을 수 있게 해준다.

예를 들어:

SELECT *
FROM Users
WHERE Email = 'test@test.com'

같은 쿼리에서 Email 컬럼에 인덱스가 존재하면 SQL Server는 전체 데이터를 읽지 않고 필요한 데이터만 바로 찾을 수 있다.

2. 디스크 I/O 감소

인덱스가 없으면 SQL Server는 테이블 전체를 읽는다.

즉:

• 더 많은 페이지 읽기
• 더 많은 디스크 접근
• 더 많은 메모리 사용

이 발생한다.

인덱스를 사용하면 필요한 데이터만 읽기 때문에 I/O가 감소한다.

3. 대규모 시스템 필수 요소

실제 운영 환경에서는:

• 수많은 사용자
• 동시 요청
• 대량 데이터

를 처리해야 한다.

인덱스 없이 운영하면:

• 응답 속도 저하
• CPU 사용량 증가
• 서버 부하 증가

가 발생한다.

따라서 인덱스는 단순 최적화가 아니라 필수 요소에 가깝다.

SQL Server의 인덱스 구조

SQL Server는 대부분 B-Tree(B+Tree) 구조를 사용한다.

구조는 다음과 같다.

B-Tree 구조 동작 방식

예를 들어 다음과 같은 데이터가 있다고 가정한다.

1, 5, 10, 20, 50, 100

SQL Server는 이 값을 트리 형태로 정렬하여 저장한다.

검색 시에는:

1. Root Node 탐색
2. 중간 노드 이동
3. Leaf Node 도달

과정을 거친다.

즉:

전체 데이터를 순차 탐색하지 않아도 된다.

이것이 인덱스가 빠른 이유이다.

Clustered Index

Clustered Index는 실제 데이터 자체가 정렬된다.

즉:

• 데이터 저장 순서
• 인덱스 순서

가 동일하다.

특징

Clustered Index 예시

CREATE CLUSTERED INDEX IX_Users_Id
ON Users(UserId);

이 경우 Users 테이블 데이터 자체가 UserId 기준으로 정렬된다.

Nonclustered Index

Nonclustered Index는 실제 데이터와 별도 구조로 존재한다.

인덱스에는:

• 키 값
• 데이터 위치 포인터

만 저장된다.

구조 특징

Nonclustered Index 예시

CREATE NONCLUSTERED INDEX IX_Users_Email
ON Users(Email);

이 경우 Email 기반 검색이 빨라진다.

Index Seek vs Table Scan

실행 계획에서 가장 중요하게 보는 것 중 하나가:

• Index Seek
• Table Scan

이다.

Table Scan

Table Scan은 테이블 전체를 읽는다.

즉:

1행부터 끝까지 전부 읽음

데이터가 많을수록 매우 느려진다.

Index Seek

Index Seek는 필요한 데이터만 찾는다.

즉:

원하는 위치만 바로 접근

따라서 훨씬 빠르다.

실행 계획에서 확인 가능

실행 계획(Execution Plan)에서:

• Table Scan 발생 여부
• Index Seek 사용 여부

를 확인할 수 있다.

튜닝에서 가장 기본적으로 보는 부분이다.

Covering Index

Covering Index는 쿼리에 필요한 모든 컬럼이 인덱스에 포함된 경우를 말한다.

즉:

• 추가 테이블 접근 없이
• 인덱스만 읽어서
• 결과 반환 가능

하다.

INCLUDE 사용

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId)
INCLUDE (OrderDate, TotalAmount);

장점

Key Lookup

Key Lookup은 SQL Server가:

1. 인덱스로 위치 찾고
2. 원본 데이터 다시 접근

하는 작업이다.

즉:

인덱스만으로 필요한 컬럼이 부족함

을 의미한다.

왜 문제인가?

Key Lookup은:

• 랜덤 I/O 증가
• 페이지 접근 증가
• 성능 저하

를 유발한다.

특히 결과 건수가 많을수록 심각해진다.

Fragmentation(조각화)

데이터가 지속적으로 변경되면 인덱스 페이지 순서가 깨진다.

이를 Fragmentation이라고 한다.

조각화 발생 원인

조각화 문제점

Fragmentation 확인

SQL Server에서는 다음 DMV로 확인 가능하다.

sys.dm_db_index_physical_stats

REORGANIZE vs REBUILD

조각화 해결 방법은 크게 2가지이다.

실행 계획(Execution Plan)

SQL Server는 쿼리를 실행하기 전에:

“어떻게 실행하는 것이 가장 효율적인가”

를 계산한다.

이 결과가 실행 계획이다.

실행 계획에서 보는 주요 요소

Query Optimizer

실행 계획은 Query Optimizer가 생성한다.

Optimizer는:

• 인덱스
• 통계 정보
• 데이터 분포
• 비용 계산

을 기반으로 가장 효율적이라고 판단한 플랜을 선택한다.

하지만 항상 완벽하지는 않다.

따라서:

• 잘못된 실행 계획
• 비효율 플랜
• Parameter Sniffing

같은 문제도 발생한다.

Query Store

SQL Server의 Query Store는:

• 실행 계획 저장
• 느린 쿼리 분석
• 성능 Regression 추적

기능을 제공한다.

특히:

• 이전보다 느려진 쿼리
• 플랜 변경
• 강제 플랜 적용(Force Plan)

분석에 매우 유용하다.

Blocking

Blocking은 트랜잭션이 서로 Lock을 기다리는 현상이다.

예를 들어:

1. 세션 A가 UPDATE 수행
2. COMMIT 안 함
3. 세션 B가 같은 데이터 읽기 시도

하면 세션 B는 대기 상태가 된다.

Snapshot Isolation

Blocking 완화를 위해 SQL Server는 Snapshot 기반 격리 수준을 제공한다.

대표적으로:

READ_COMMITTED_SNAPSHOT

이 있다.

핵심 개념

기존 Read Committed:

• Lock 기다림

Snapshot 기반:

• 이전 버전(Row Version) 읽음

즉:

Reader와 Writer 충돌 감소

효과가 있다.

이번 실습에서 중요했던 핵심 포인트

이번 실습의 핵심은 단순 SQL 문법이 아니었다.

진짜 중요한 것은:

• 왜 실행 계획이 그렇게 나오는가
• 왜 인덱스가 필요한가
• 왜 Key Lookup이 성능 병목이 되는가
• 왜 Fragmentation이 Logical Read를 증가시키는가
• 왜 Blocking이 발생하는가

를 SQL Server 내부 동작 관점에서 이해하는 것이었다.

Lab07 - Fragmentation 실습

이번 실습에서는 조각화를 의도적으로 발생시켰다.

1. 조각화 상태 확인

USE AdventureWorks2017
GO

SELECT i.name Index_Name
, avg_fragmentation_in_percent
, db_name(database_id)
, i.object_id
, i.index_id
, index_type_desc
FROM sys.dm_db_index_physical_stats(
    db_id('AdventureWorks2017'),
    object_id('person.address'),
    NULL,
    NULL,
    'DETAILED'
) ps
INNER JOIN sys.indexes i
ON ps.object_id = i.object_id
AND ps.index_id = i.index_id
WHERE avg_fragmentation_in_percent > 50

처음에는 조각화가 거의 없기 때문에 결과가 나오지 않는다.

2. 데이터 대량 INSERT

USE AdventureWorks2017
GO

INSERT INTO [Person].[Address]
(
    [AddressLine1],
    [AddressLine2],
    [City],
    [StateProvinceID],
    [PostalCode],
    [SpatialLocation],
    [rowguid],
    [ModifiedDate]
)
SELECT
    AddressLine1,
    AddressLine2,
    'Amsterdam',
    StateProvinceID,
    PostalCode,
    SpatialLocation,
    newid(),
    getdate()
FROM Person.Address;
GO

이 작업으로 Person.Address 테이블 크기가 증가하며 페이지 분할(Page Split)이 발생한다.

결과적으로 인덱스 조각화율이 크게 증가한다.

3. 논리적 읽기(Logical Read) 측정

SET STATISTICS IO,TIME ON
GO

USE AdventureWorks2017
GO

SELECT DISTINCT (StateProvinceID)
,count(StateProvinceID) AS CustomerCount
FROM person.Address
GROUP BY StateProvinceID
ORDER BY count(StateProvinceID) DESC;
GO

메시지 탭에서 Logical Read 값을 확인할 수 있다.

조각화가 심해질수록 더 많은 페이지를 읽게 된다.

인덱스 REBUILD

조각화 문제 해결을 위해 REBUILD를 수행한다.

USE AdventureWorks2017
GO

ALTER INDEX [IX_Address_StateProvinceID]
ON [Person].[Address]
REBUILD PARTITION = ALL

REBUILD는 인덱스를 새로 만드는 작업이다.

결과:

• Fragmentation 감소
• Logical Read 감소
• 쿼리 성능 향상

REORGANIZE vs REBUILD

실행 계획(Execution Plan)

SQL Server는 쿼리를 실행하기 전에 “어떻게 실행할지” 계획을 만든다.

이것이 Execution Plan이다.

실행 계획을 통해:

• Index Seek
• Table Scan
• Key Lookup
• Hash Match

등이 어떻게 발생하는지 확인할 수 있다.

Lab09 - 암시적 형 변환(Implicit Conversion)

다음 쿼리를 실행했다.

SELECT BusinessEntityID,
       NationalIDNumber,
       LoginID,
       HireDate,
       JobTitle
FROM HumanResources.Employee
WHERE NationalIDNumber = 14417807;

실행 계획에서 경고가 발생했다.

원인은 Implicit Conversion이다.

왜 발생했는가?

NationalIDNumber 컬럼 타입은:

nvarchar(15)

이다.

하지만 비교값은 숫자(INT)이다.

따라서 SQL Server가 내부적으로:

CONVERT_IMPLICIT(...)

를 수행한다.

문제점

Implicit Conversion은 다음 문제를 만든다.

해결 방법 1 - 쿼리 수정

WHERE NationalIDNumber = '14417807';

문자열로 맞춰주면 된다.

이렇게 하면:

• 경고 제거
• 실행 계획 개선
• 인덱스 활용 가능

해진다.

해결 방법 2 - 컬럼 타입 변경

ALTER TABLE [HumanResources].[Employee]
ALTER COLUMN [NationalIDNumber] INT NOT NULL;

하지만 여기서 중요한 문제가 발생한다.

인덱스 문제

NationalIDNumber는 기존 인덱스에서 사용 중이었다.

따라서:

1. 인덱스 DROP
2. ALTER COLUMN
3. 인덱스 재생성

순서가 필요하다.

즉 운영 환경에서는 다운타임 문제가 발생할 수 있다.

Key Lookup 문제

Lab10에서는 Key Lookup 문제를 분석했다.

실행 계획에서:

• Index Seek
• Key Lookup(cost 99%)

이 발생했다.

왜 Key Lookup이 발생하는가?

현재 인덱스는:

(ProductID)

만 포함한다.

하지만 SELECT에서 필요한 컬럼은 더 많다.

따라서 SQL Server는:

1. 인덱스로 위치 찾기
2. 원본 데이터 다시 접근

을 수행한다.

이 추가 접근이 Key Lookup이다.

Covering Index

해결 방법은 Covering Index이다.

CREATE NONCLUSTERED INDEX
[IX_SalesOrderDetail_ProductID]

ON [Sales].[SalesOrderDetail]
([ProductID],[ModifiedDate])

INCLUDE (
    [CarrierTrackingNumber],
    [OrderQty],
    [UnitPrice]
)

WITH (DROP_EXISTING = on);

핵심:

• 필요한 컬럼을 INCLUDE로 포함
• 인덱스만 읽어서 쿼리 해결 가능

결과:

• Key Lookup 제거
• Logical Read 감소
• 성능 향상

Query Store

Query Store는 SQL Server의 성능 분석 기능이다.

활성화:

ALTER DATABASE [AdventureWorks2017]
SET QUERY_STORE = ON;

Query Store로 할 수 있는 것

• 느린 쿼리 찾기
• 실행 계획 비교
• 성능 Regression 추적
• 좋은 실행 계획 강제 적용

Force Plan

실행 계획 중 더 좋은 플랜을 강제로 사용 가능하다.

실습에서는:

• 빠른 Plan
• 느린 Plan

두 개를 비교 후:

Force Plan

기능으로 좋은 플랜을 강제 적용했다.

Blocking

Blocking은 트랜잭션이 서로 잠금을 기다리는 현상이다.

Blocking 실습

세션 1

BEGIN TRANSACTION

UPDATE Person.Person
SET LastName = LastName;

트랜잭션 종료 안 함.

세션 2

SELECT TOP (1000)
    [LastName],
    [FirstName],
    [Title]
FROM Person.Person
WHERE FirstName = 'David'

결과:

• 무한 대기
• Blocking 발생

왜 발생했는가?

첫 번째 세션이 Lock을 유지 중이기 때문이다.

두 번째 세션은 같은 데이터 접근 시도 중이라 대기 상태가 된다.

Extended Events

Blocking 추적을 위해 Extended Events를 사용했다.

blocked_process_report

를 통해:

• 누가 막는지
• 어떤 쿼리가 원인인지
• 어떤 세션인지

확인 가능하다.

READ_COMMITTED_SNAPSHOT

Blocking 완화를 위해 Snapshot Isolation 기반 설정을 적용했다.

ALTER DATABASE AdventureWorks2017
SET READ_COMMITTED_SNAPSHOT ON
WITH ROLLBACK IMMEDIATE;

핵심 개념

기존 Read Committed:

• 수정 중 데이터 접근 시 대기

READ_COMMITTED_SNAPSHOT:

• 이전 버전(Row Version) 읽음
• Lock 기다리지 않음

즉:

Reader와 Writer 충돌 감소

최종 정리

이번 실습에서는 단순 SQL 작성이 아니라 실제 운영 환경 수준의 SQL Server 성능 튜닝 과정을 경험했다.

특히 다음 내용을 실제로 확인할 수 있었다.

• 인덱스 구조와 동작 방식
• Fragmentation이 성능에 미치는 영향
• 실행 계획 분석
• Implicit Conversion 문제
• Key Lookup 제거 방법
• Covering Index 설계
• Query Store 기반 분석
• Blocking 및 Snapshot Isolation

결국 SQL 성능 튜닝의 핵심은:

“왜 SQL Server가 그런 실행 계획을 선택했는가”

를 이해하는 것이라는 점을 확인할 수 있었다.

아키텍처 개요

#!/usr/bin/env bash
# ============================================================
# 01-setup-vm-sqlserver.sh
# Azure VM 생성 → SQL Server 2025 설치 → 외부 SSMS 접근 → 시딩
#
# 로컬 PC (Mac/Linux/WSL) 에서 실행
#
# 사용법:
#   bash 01-setup-vm-sqlserver.sh
#
# 환경변수 사전 설정 가능:
#   export RG=rg-carmarket-lab LOC=koreacentral SA_PASSWORD='YourP@ssw0rd!'
#   bash 01-setup-vm-sqlserver.sh
# ============================================================

set -euo pipefail

# =============================================================
# 기본값
# =============================================================
RG="${RG:-rg-carmarket-lab}"
LOC="${LOC:-koreacentral}"
VM="${VM:-vm-carmarket-$(date +%m%d)}"
VM_SIZE="${VM_SIZE:-Standard_B2s}"
USER_NAME="${USER_NAME:-azureuser}"
SSH_KEY="${SSH_KEY:-$HOME/.ssh/id_rsa.pub}"
SA_PASSWORD="${SA_PASSWORD:-}"
REPO_URL="https://github.com/jhjwlee/sqlvm_usedcar.git"

# 색상
G='\033[0;32m'; Y='\033[0;33m'; R='\033[0;31m'; B='\033[0;34m'; NC='\033[0m'
banner() { echo ""; echo -e "${B}═══════════════════════════════════════════════════${NC}"; echo -e "${B}  $1${NC}"; echo -e "${B}═══════════════════════════════════════════════════${NC}"; }
step()   { echo ""; echo -e "${G}▶ [$1/$TOTAL_STEPS]${NC} $2"; }
ok()     { echo -e "${G}  ✓${NC} $1"; }
warn()   { echo -e "${Y}  ⚠${NC} $1"; }
fail()   { echo -e "${R}  ✗${NC} $1"; }
abort()  { echo -e "${R}❌ $1${NC}"; exit 1; }

TOTAL_STEPS=8
LOG_FILE="/tmp/carmarket-setup-$(date +%Y%m%d-%H%M%S).log"
exec > >(tee -a "$LOG_FILE") 2>&1

banner "CarMarket Lab — VM + SQL Server + SSMS 접근 자동 설정"
echo "  리소스 그룹: $RG"
echo "  위치:       $LOC"
echo "  VM 이름:    $VM"
echo "  VM 크기:    $VM_SIZE"
echo "  로그 파일:  $LOG_FILE"

# =============================================================
# Step 1: 사전 점검
# =============================================================
step 1 "사전 점검 (Azure CLI · SSH 키 · 로그인)"

command -v az >/dev/null 2>&1 || abort "Azure CLI 미설치. https://aka.ms/azcli"
ok "Azure CLI: $(az version --query '\"azure-cli\"' -o tsv 2>/dev/null || echo 'unknown')"

if ! az account show >/dev/null 2>&1; then
  warn "Azure 로그인 필요"
  az login
fi
ok "구독: $(az account show --query name -o tsv)"

if [ ! -f "$SSH_KEY" ]; then
  warn "SSH 키 없음 → 자동 생성"
  ssh-keygen -t rsa -b 4096 -N "" -f "${SSH_KEY%.pub}" -q
fi
ok "SSH 키: $SSH_KEY"

# =============================================================
# Step 2: SA 비밀번호 입력
# =============================================================
step 2 "SA 비밀번호 설정"

if [ -z "$SA_PASSWORD" ]; then
  echo "  SQL Server SA 비밀번호를 입력하세요."
  echo "  요구사항: 8자+ / 대·소문자·숫자·특수문자 중 3종 이상"
  echo "  예) CarMarket@2026"
  while true; do
    read -s -p "  SA Password: " SA_PASSWORD; echo ""
    read -s -p "  Confirm:     " SA_CONFIRM;  echo ""
    if [ "$SA_PASSWORD" = "$SA_CONFIRM" ] && [ ${#SA_PASSWORD} -ge 8 ]; then
      break
    fi
    echo -e "${R}  비밀번호 불일치 또는 8자 미만. 재입력.${NC}"
  done
fi
ok "SA 비밀번호 설정 완료 (${#SA_PASSWORD}자)"

# 비용 안내
echo ""
echo "  예상 비용: VM(B2s) ≈ \$0.5/일"
echo "  예상 시간: 약 10~15분"
read -p "  진행? (y/N): " ok_proceed
[[ "$ok_proceed" =~ ^[Yy]$ ]] || abort "취소됨"

# =============================================================
# Step 3: Resource Group + VM 생성
# =============================================================
step 3 "Azure 리소스 생성 (RG + VM)"

if az group show -n "$RG" >/dev/null 2>&1; then
  ok "RG '$RG' 이미 존재 (재사용)"
else
  az group create -n "$RG" -l "$LOC" --output none
  ok "RG '$RG' 생성"
fi

if az vm show -g "$RG" -n "$VM" >/dev/null 2>&1; then
  warn "VM '$VM' 이미 존재 → 재사용"
else
  echo "  → VM 생성 중 (3~5분)..."
  az vm create \
    --resource-group "$RG" \
    --name "$VM" \
    --image Ubuntu2404 \
    --size "$VM_SIZE" \
    --admin-username "$USER_NAME" \
    --ssh-key-values "$SSH_KEY" \
    --public-ip-sku Standard \
    --storage-sku Premium_LRS \
    --os-disk-size-gb 32 \
    --output none
  ok "VM '$VM' 생성 완료"
fi

PUBIP=$(az vm show -d -g "$RG" -n "$VM" --query publicIps -o tsv)
ok "Public IP: $PUBIP"

# =============================================================
# Step 4: NSG 포트 오픈 (22, 1433, 5000)
# =============================================================
step 4 "NSG 포트 오픈 — SSH(22) + SQL(1433) + Flask(5000)"

# NSG 이름 자동 탐색
NSG_NAME=$(az network nsg list -g "$RG" --query "[0].name" -o tsv 2>/dev/null || echo "${VM}NSG")

open_port() {
  local PORT=$1 PRIORITY=$2 NAME=$3
  if az network nsg rule show -g "$RG" --nsg-name "$NSG_NAME" -n "$NAME" >/dev/null 2>&1; then
    ok "$NAME ($PORT) 이미 존재"
  else
    az vm open-port -g "$RG" -n "$VM" --port "$PORT" --priority "$PRIORITY" --output none 2>/dev/null || true
    ok "$NAME ($PORT) 오픈"
  fi
}

open_port 1433 1010 "allow_sql_1433"
open_port 5000 1020 "allow_flask_5000"
ok "NSG 규칙 적용 완료"

# =============================================================
# Step 5: SSH 대기 + 접속
# =============================================================
step 5 "SSH 연결 대기"

echo "  → SSH 준비 대기 (최대 90초)..."
for i in $(seq 1 45); do
  if ssh -o StrictHostKeyChecking=no -o ConnectTimeout=3 -o BatchMode=yes \
     "$USER_NAME@$PUBIP" "echo ready" >/dev/null 2>&1; then
    ok "SSH 연결 가능"
    break
  fi
  sleep 2
  [ $i -eq 45 ] && abort "SSH 연결 90초 타임아웃"
done

# =============================================================
# Step 6: VM 내부 — SQL Server 설치 (0.0.0.0 바인딩)
# =============================================================
step 6 "VM 내부: SQL Server 2025 설치 + 0.0.0.0 바인딩"

ssh -o StrictHostKeyChecking=accept-new "$USER_NAME@$PUBIP" bash -s "$SA_PASSWORD" << 'REMOTE_SCRIPT'
#!/usr/bin/env bash
set -euo pipefail

SA_PASSWORD="$1"
G='\033[0;32m'; NC='\033[0m'
ok() { echo -e "${G}  ✓${NC} $1"; }

echo "=== [VM] 패키지 업데이트 ==="
sudo apt update -qq
sudo apt install -y -qq curl wget gnupg2 software-properties-common \
  apt-transport-https ca-certificates lsb-release git unzip jq > /dev/null
ok "기본 패키지"

# Swap (RAM < 6GB)
RAM_GB=$(free -g | awk 'NR==2{print $2}')
if [ "$RAM_GB" -lt 6 ] && ! swapon --show | grep -q swapfile; then
  sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
  sudo mkswap /swapfile -q && sudo swapon /swapfile
  grep -q "/swapfile" /etc/fstab || echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab > /dev/null
  ok "swap 2GB 활성화"
fi

echo "=== [VM] Microsoft GPG 키 + 저장소 ==="
sudo rm -f /etc/apt/sources.list.d/mssql-server-2022.list /etc/apt/sources.list.d/mssql-server-preview.list
if [ ! -f /usr/share/keyrings/microsoft-prod.gpg ]; then
  curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | \
    sudo gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
fi
curl -fsSL https://packages.microsoft.com/config/ubuntu/24.04/mssql-server-2025.list | \
  sudo tee /etc/apt/sources.list.d/mssql-server-2025.list > /dev/null
curl -fsSL https://packages.microsoft.com/config/ubuntu/24.04/prod.list | \
  sudo tee /etc/apt/sources.list.d/mssql-release.list > /dev/null
sudo apt update -qq
ok "저장소 등록"

echo "=== [VM] SQL Server 설치 ==="
if ! dpkg -l | grep -q "^ii.*mssql-server "; then
  sudo apt install -y -qq mssql-server > /dev/null
  ok "mssql-server 패키지 설치"
else
  ok "mssql-server 이미 설치됨"
fi

if ! sudo systemctl is-active --quiet mssql-server; then
  sudo MSSQL_PID=Developer ACCEPT_EULA=Y MSSQL_SA_PASSWORD="$SA_PASSWORD" \
    /opt/mssql/bin/mssql-conf -n setup > /dev/null
  ok "SQL Server setup (Developer Edition)"
fi

# ★ 핵심: 0.0.0.0 바인딩 (외부 SSMS 접근 허용)
sudo /opt/mssql/bin/mssql-conf set network.ipaddress 0.0.0.0 > /dev/null
sudo systemctl restart mssql-server

echo "=== [VM] SQL Server 시작 대기 ==="
for i in $(seq 1 30); do
  if sudo ss -tlnp 2>/dev/null | grep -q ":1433"; then
    ok "0.0.0.0:1433 listen 확인"
    break
  fi
  sleep 2
  [ $i -eq 30 ] && { echo "❌ 60초 내 시작 안됨"; exit 1; }
done

echo "=== [VM] mssql-tools18 + ODBC ==="
sudo ACCEPT_EULA=Y apt install -y -qq mssql-tools18 unixodbc-dev msodbcsql18 > /dev/null
grep -q "mssql-tools18/bin" "$HOME/.bashrc" || \
  echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> "$HOME/.bashrc"
export PATH="$PATH:/opt/mssql-tools18/bin"
ok "mssql-tools18 + ODBC Driver 18"

# 연결 검증
if /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -Q "SELECT 1" -h -1 -W 2>/dev/null | grep -q "^1$"; then
  ok "sqlcmd 로컬 연결 성공"
else
  echo "❌ sqlcmd 연결 실패"; exit 1
fi

echo "=== [VM] 완료 ==="
REMOTE_SCRIPT

ok "SQL Server 2025 설치 + 0.0.0.0 바인딩 완료"

# =============================================================
# Step 7: DB 스키마 + 시드 데이터
# =============================================================
step 7 "DB 스키마 + 시드 데이터 적용"

ssh "$USER_NAME@$PUBIP" bash -s "$SA_PASSWORD" "$REPO_URL" << 'SEED_SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
SA_PASSWORD="$1"
REPO_URL="$2"
INSTALL_DIR="$HOME/sqlvm_usedcar"
export PATH="$PATH:/opt/mssql-tools18/bin"

G='\033[0;32m'; NC='\033[0m'
ok() { echo -e "${G}  ✓${NC} $1"; }

# Repo clone
if [ -d "$INSTALL_DIR/.git" ]; then
  cd "$INSTALL_DIR" && git pull --rebase --quiet
else
  [ -d "$INSTALL_DIR" ] && mv "$INSTALL_DIR" "${INSTALL_DIR}.bak.$(date +%s)"
  git clone -q "$REPO_URL" "$INSTALL_DIR"
  cd "$INSTALL_DIR"
fi
ok "Repo clone: $(git rev-parse --short HEAD)"

# Schema
sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -i sql/schema.sql > /dev/null
ok "schema.sql 적용 (Users, Cars, Inquiries + 3 indexes)"

# Seed
sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -i sql/seed.sql > /dev/null

# 검증
SEED_COUNT=$(sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -d CarMarket \
  -Q "SELECT COUNT(*) FROM Cars" -h -1 -W 2>/dev/null | head -1 | tr -d ' \r')
if [ "$SEED_COUNT" = "5" ]; then
  ok "seed.sql 적용 (Users 5건, Cars 5건)"
else
  echo "⚠ Cars 행 수: $SEED_COUNT (예상 5)"
fi
SEED_SCRIPT

ok "CarMarket DB 시딩 완료"

# =============================================================
# Step 8: Flask 앱 + systemd + 검증
# =============================================================
step 8 "Flask 앱 배포 + 헬스체크"

ssh "$USER_NAME@$PUBIP" bash -s "$SA_PASSWORD" << 'APP_SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
SA_PASSWORD="$1"
INSTALL_DIR="$HOME/sqlvm_usedcar"

G='\033[0;32m'; NC='\033[0m'
ok() { echo -e "${G}  ✓${NC} $1"; }

sudo apt install -y -qq python3 python3-pip python3-venv python3-dev > /dev/null

cd "$INSTALL_DIR/app"
[ ! -f venv/bin/activate ] && python3 -m venv venv
source venv/bin/activate
pip install --quiet --upgrade pip
pip install --quiet -r requirements.txt
deactivate

cat > .env <<EOF
SA_PASSWORD=$SA_PASSWORD
DB_SERVER=localhost
DB_NAME=CarMarket
FLASK_PORT=5000
EOF
chmod 600 .env
ok ".env 생성"

cd "$INSTALL_DIR"
sudo cp systemd/carmarket.service /etc/systemd/system/carmarket.service
sudo sed -i "s|/home/azureuser|$HOME|g" /etc/systemd/system/carmarket.service
sudo sed -i "s|User=azureuser|User=$(whoami)|" /etc/systemd/system/carmarket.service
sudo systemctl daemon-reload
sudo systemctl enable carmarket --quiet
sudo systemctl restart carmarket
sleep 3

if sudo systemctl is-active --quiet carmarket; then
  ok "carmarket.service 실행 중"
else
  echo "❌ Flask 서비스 실행 실패"
  sudo journalctl -u carmarket -n 20 --no-pager
  exit 1
fi

HEALTH=$(curl -s --max-time 5 http://localhost:5000/health || echo '{}')
if echo "$HEALTH" | grep -q '"status":"ok"'; then
  ok "Health OK: $HEALTH"
fi
APP_SCRIPT

ok "Flask 앱 배포 완료"

# =============================================================
# 외부 검증
# =============================================================
echo ""
sleep 3
echo "  → 외부 헬스체크..."
if curl -fsS --max-time 10 "http://$PUBIP:5000/health" 2>/dev/null | grep -q '"status":"ok"'; then
  ok "외부 Flask 접근 확인: http://$PUBIP:5000/"
else
  warn "Flask 외부 접근 실패 — NSG/서비스 확인 필요"
fi

# =============================================================
# 완료 안내
# =============================================================
banner "설치 완료!"

# 환경변수 파일 저장
cat > "$HOME/.carmarket-env" <<EOF
export RG=$RG
export LOC=$LOC
export VM=$VM
export PUBIP=$PUBIP
export USER_NAME=$USER_NAME
export SA_PASSWORD='$SA_PASSWORD'
EOF
chmod 600 "$HOME/.carmarket-env"

cat <<EOF

┌─────────────────────────────────────────────────────────────┐
│  SQL Server 2025 (Developer)  — 외부 SSMS 접근 가능        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  SSMS 연결 정보:                                            │
│    서버:    $PUBIP,1433                                     │
│    인증:    SQL Server 인증                                  │
│    로그인:  sa                                              │
│    암호:    (설정한 SA_PASSWORD)                             │
│    ★ 연결 속성 → "서버 인증서 신뢰" 체크                     │
│                                                             │
│  웹 앱: http://$PUBIP:5000/                                 │
│  SSH:   ssh $USER_NAME@$PUBIP                               │
│                                                             │
│  비용 차단:  az vm deallocate -g $RG -n $VM                 │
│  완전 삭제:  az group delete -n $RG --yes --no-wait         │
│                                                             │
│  환경변수:   source ~/.carmarket-env                         │
└─────────────────────────────────────────────────────────────┘

EOF

1. Azure CLI 로그인 확인 + SSH 키 검증
2. Resource Group + Ubuntu 24.04 VM (B2s) 생성
3. NSG에서 22(SSH) + 1433(SQL) + 5000(Flask) 포트 오픈
4. SQL Server 2025 Developer Edition 설치
5. 0.0.0.0 바인딩 (외부 SSMS 접근 허용)
6. CarMarket DB 스키마 생성 + 시드 데이터 5건
7. Flask 앱 배포 + systemd 서비스 등록

SSMS 연결

또는 VSCode에서 SQL Server(mssql) extension을 통해 접속 가능

데이터 확인

USE CarMarket;
GO
-- 테이블 목록 확인
SELECT TABLE_NAME, TABLE_TYPE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE';
-- 차량 매물 확인
SELECT c.Brand, c.Model, c.Year,
FORMAT(c.Price, 'N0') AS Price,
FORMAT(c.Mileage, 'N0') AS Mileage,
u.Name AS Seller
FROM Cars c
JOIN Users u ON c.SellerId = u.UserId
ORDER BY c.Price DESC;
-- 인덱스 확인
SELECT i.name AS IndexName,
t.name AS TableName,
COL_NAME(ic.object_id, ic.column_id) AS ColumnName
FROM sys.indexes i
JOIN sys.tables t ON i.object_id = t.object_id
JOIN sys.index_columns ic ON i.object_id = ic.object_id AND i.index_id = ic.index_id
WHERE i.name LIKE 'IX_%';

이 실습에서는 학습 편의를 위해 1433을 외부에 직접 오픈합니다. 프로덕션 환경에서는 절대 하지 마세요. 실무에서는 다음 방법을 사용합니다:

• SSH 터널: ssh -L 1433:localhost:1433 azureuser@<PUBIP> 후 SSMS에서 localhost 접속
• VPN Gateway 또는 Azure Bastion
• Private Endpoint

Azure SQL Database 마이그레이션

#!/usr/bin/env bash
# ============================================================
# 02-migrate-to-azure-sql.sh
# VM SQL Server → Azure SQL Database 마이그레이션 (Azure DMS)
#
# 사전 조건:
#   - 01-setup-vm-sqlserver.sh 완료
#   - source ~/.carmarket-env (환경변수 로드)
#
# 사용법:
#   source ~/.carmarket-env
#   bash 02-migrate-to-azure-sql.sh
# ============================================================

set -euo pipefail

# =============================================================
# 환경변수 확인 + 기본값
# =============================================================
RG="${RG:-rg-carmarket-lab}"
LOC="${LOC:-koreacentral}"
VM="${VM:-}"
PUBIP="${PUBIP:-}"
USER_NAME="${USER_NAME:-azureuser}"
SA_PASSWORD="${SA_PASSWORD:-}"

# Azure SQL 관련 변수
SQL_SERVER_NAME="${SQL_SERVER_NAME:-sql-carmarket-$(date +%m%d)-$RANDOM}"
SQL_DB_NAME="${SQL_DB_NAME:-CarMarket}"
SQL_ADMIN="${SQL_ADMIN:-sqladmin}"
SQL_ADMIN_PASSWORD="${SQL_ADMIN_PASSWORD:-}"
DMS_NAME="${DMS_NAME:-dms-carmarket-$(date +%m%d)}"

# 색상
G='\033[0;32m'; Y='\033[0;33m'; R='\033[0;31m'; B='\033[0;34m'; NC='\033[0m'
banner() { echo ""; echo -e "${B}═══════════════════════════════════════════════════${NC}"; echo -e "${B}  $1${NC}"; echo -e "${B}═══════════════════════════════════════════════════${NC}"; }
step()   { echo ""; echo -e "${G}▶ [$1/$TOTAL_STEPS]${NC} $2"; }
ok()     { echo -e "${G}  ✓${NC} $1"; }
warn()   { echo -e "${Y}  ⚠${NC} $1"; }
abort()  { echo -e "${R}❌ $1${NC}"; exit 1; }

TOTAL_STEPS=7
LOG_FILE="/tmp/carmarket-migrate-$(date +%Y%m%d-%H%M%S).log"
exec > >(tee -a "$LOG_FILE") 2>&1

banner "CarMarket Lab — VM → Azure SQL Database 마이그레이션"

# =============================================================
# Step 1: 사전 점검
# =============================================================
step 1 "사전 점검"

command -v az >/dev/null 2>&1 || abort "Azure CLI 미설치"
az account show >/dev/null 2>&1 || { warn "로그인 필요"; az login; }
ok "Azure CLI 로그인 확인"

# PUBIP가 비어있으면 VM에서 가져오기
if [ -z "$PUBIP" ] && [ -n "$VM" ]; then
  PUBIP=$(az vm show -d -g "$RG" -n "$VM" --query publicIps -o tsv 2>/dev/null || echo "")
fi
[ -z "$PUBIP" ] && abort "PUBIP를 확인할 수 없습니다. source ~/.carmarket-env 후 재시도"
ok "소스 VM: $PUBIP"

# SA 비밀번호 확인
if [ -z "$SA_PASSWORD" ]; then
  read -s -p "  소스 VM SA 비밀번호: " SA_PASSWORD; echo ""
fi
ok "소스 SA 비밀번호 확인"

# Azure SQL 관리자 비밀번호
if [ -z "$SQL_ADMIN_PASSWORD" ]; then
  echo "  Azure SQL Database 관리자 비밀번호를 입력하세요."
  echo "  (소스와 같은 비밀번호 사용 가능)"
  while true; do
    read -s -p "  SQL Admin Password: " SQL_ADMIN_PASSWORD; echo ""
    read -s -p "  Confirm:            " CONFIRM; echo ""
    [ "$SQL_ADMIN_PASSWORD" = "$CONFIRM" ] && [ ${#SQL_ADMIN_PASSWORD} -ge 8 ] && break
    echo -e "${R}  불일치 또는 8자 미만${NC}"
  done
fi
ok "Azure SQL 관리자 비밀번호 설정"

echo ""
echo "  Azure SQL Server: $SQL_SERVER_NAME.database.windows.net"
echo "  Database:         $SQL_DB_NAME"
echo "  Admin:            $SQL_ADMIN"
echo "  예상 비용: DTU 기반 S0 ≈ \$0.49/일"
read -p "  진행? (y/N): " ok_proceed
[[ "$ok_proceed" =~ ^[Yy]$ ]] || abort "취소됨"

# =============================================================
# Step 2: Azure SQL Server + Database 생성
# =============================================================
step 2 "Azure SQL Server + Database 생성"

# SQL Server (논리 서버)
if az sql server show -g "$RG" -n "$SQL_SERVER_NAME" >/dev/null 2>&1; then
  ok "SQL Server '$SQL_SERVER_NAME' 이미 존재"
else
  echo "  → 논리 서버 생성 중..."
  az sql server create \
    --resource-group "$RG" \
    --name "$SQL_SERVER_NAME" \
    --location "$LOC" \
    --admin-user "$SQL_ADMIN" \
    --admin-password "$SQL_ADMIN_PASSWORD" \
    --output none
  ok "SQL Server '$SQL_SERVER_NAME' 생성"
fi

# 방화벽: VM Public IP 허용
echo "  → 방화벽 규칙 추가..."
az sql server firewall-rule create \
  --resource-group "$RG" \
  --server "$SQL_SERVER_NAME" \
  --name "AllowSourceVM" \
  --start-ip-address "$PUBIP" \
  --end-ip-address "$PUBIP" \
  --output none 2>/dev/null || true

# 방화벽: 내 로컬 IP 허용
MY_IP=$(curl -s https://api.ipify.org 2>/dev/null || echo "")
if [ -n "$MY_IP" ]; then
  az sql server firewall-rule create \
    --resource-group "$RG" \
    --server "$SQL_SERVER_NAME" \
    --name "AllowMyIP" \
    --start-ip-address "$MY_IP" \
    --end-ip-address "$MY_IP" \
    --output none 2>/dev/null || true
  ok "방화벽: VM($PUBIP) + 로컬($MY_IP) 허용"
else
  ok "방화벽: VM($PUBIP) 허용"
fi

# Azure 서비스 접근 허용
az sql server firewall-rule create \
  --resource-group "$RG" \
  --server "$SQL_SERVER_NAME" \
  --name "AllowAzureServices" \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0 \
  --output none 2>/dev/null || true
ok "Azure 서비스 접근 허용"

# Database 생성 (S0 = 10 DTU, 실습에 충분)
if az sql db show -g "$RG" -s "$SQL_SERVER_NAME" -n "$SQL_DB_NAME" >/dev/null 2>&1; then
  ok "Database '$SQL_DB_NAME' 이미 존재"
else
  echo "  → Database 생성 중 (1~2분)..."
  az sql db create \
    --resource-group "$RG" \
    --server "$SQL_SERVER_NAME" \
    --name "$SQL_DB_NAME" \
    --service-objective S0 \
    --output none
  ok "Database '$SQL_DB_NAME' 생성 (S0 / 10 DTU)"
fi

SQL_FQDN="${SQL_SERVER_NAME}.database.windows.net"
ok "Azure SQL: $SQL_FQDN / $SQL_DB_NAME"

# =============================================================
# Step 3: 소스 VM에서 bacpac 내보내기 준비
# =============================================================
step 3 "소스 DB에서 스키마·데이터 SQL 스크립트 생성"

# DMS 대신 sqlcmd를 통한 직접 마이그레이션 (소규모 DB에 적합)
# 대규모에서는 DMS를 사용하지만, 이 실습은 교육용이므로 두 방식 모두 제공

echo "  → VM에서 스키마 + 데이터 추출..."
ssh "$USER_NAME@$PUBIP" bash -s "$SA_PASSWORD" << 'EXPORT_SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
SA_PASSWORD="$1"
export PATH="$PATH:/opt/mssql-tools18/bin"
EXPORT_DIR="$HOME/migration_export"
mkdir -p "$EXPORT_DIR"

G='\033[0;32m'; NC='\033[0m'
ok() { echo -e "${G}  ✓${NC} $1"; }

# Azure SQL 호환 스키마 생성 (IDENTITY 유지, Azure SQL 미지원 구문 제거)
cat > "$EXPORT_DIR/schema-azure.sql" << 'AZSCHEMA'
-- Azure SQL Database용 스키마 (CarMarket)
-- Azure SQL은 CREATE DATABASE를 별도로 실행하므로 DB 생성 구문 제외

-- 기존 테이블 정리 (멱등성)
IF OBJECT_ID('Inquiries', 'U') IS NOT NULL DROP TABLE Inquiries;
IF OBJECT_ID('Cars',      'U') IS NOT NULL DROP TABLE Cars;
IF OBJECT_ID('Users',     'U') IS NOT NULL DROP TABLE Users;
GO

CREATE TABLE Users (
    UserId    INT IDENTITY(1,1) PRIMARY KEY,
    Name      NVARCHAR(100)  NOT NULL,
    Email     NVARCHAR(200)  NOT NULL UNIQUE,
    Phone     NVARCHAR(20),
    UserType  NVARCHAR(10)   NOT NULL DEFAULT 'both'
              CHECK (UserType IN ('seller', 'buyer', 'both')),
    CreatedAt DATETIME2      DEFAULT SYSUTCDATETIME()
);
GO

CREATE TABLE Cars (
    CarId       INT IDENTITY(1,1) PRIMARY KEY,
    SellerId    INT            NOT NULL FOREIGN KEY REFERENCES Users(UserId),
    Brand       NVARCHAR(50)   NOT NULL,
    Model       NVARCHAR(100)  NOT NULL,
    Year        INT            NOT NULL,
    Price       DECIMAL(12, 0) NOT NULL,
    Mileage     INT            NOT NULL,
    FuelType    NVARCHAR(20),
    Description NVARCHAR(MAX),
    Status      NVARCHAR(20)   NOT NULL DEFAULT 'available'
                CHECK (Status IN ('available', 'reserved', 'sold')),
    CreatedAt   DATETIME2      DEFAULT SYSUTCDATETIME()
);
GO

CREATE TABLE Inquiries (
    InquiryId INT IDENTITY(1,1) PRIMARY KEY,
    CarId     INT            NOT NULL FOREIGN KEY REFERENCES Cars(CarId),
    BuyerId   INT            NOT NULL FOREIGN KEY REFERENCES Users(UserId),
    Message   NVARCHAR(1000) NOT NULL,
    CreatedAt DATETIME2      DEFAULT SYSUTCDATETIME()
);
GO

CREATE INDEX IX_Cars_Brand     ON Cars(Brand);
CREATE INDEX IX_Cars_Status    ON Cars(Status);
CREATE INDEX IX_Cars_CreatedAt ON Cars(CreatedAt DESC);
GO
AZSCHEMA
ok "Azure SQL 호환 스키마 생성"

# 데이터 추출 (INSERT 문으로)
sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -d CarMarket -h -1 -W -Q "
SET NOCOUNT ON;

-- Users
SELECT 'SET IDENTITY_INSERT Users ON;'
UNION ALL
SELECT 'INSERT INTO Users (UserId, Name, Email, Phone, UserType) VALUES ('
  + CAST(UserId AS NVARCHAR) + ', N''' + REPLACE(Name, '''', '''''') + ''', '''
  + Email + ''', ''' + ISNULL(Phone, '') + ''', ''' + UserType + ''');'
FROM Users
UNION ALL
SELECT 'SET IDENTITY_INSERT Users OFF;'
UNION ALL
SELECT ''
UNION ALL
-- Cars
SELECT 'SET IDENTITY_INSERT Cars ON;'
UNION ALL
SELECT 'INSERT INTO Cars (CarId, SellerId, Brand, Model, Year, Price, Mileage, FuelType, Description, Status) VALUES ('
  + CAST(CarId AS NVARCHAR) + ', ' + CAST(SellerId AS NVARCHAR) + ', N'''
  + REPLACE(Brand, '''', '''''') + ''', N''' + REPLACE(Model, '''', '''''') + ''', '
  + CAST(Year AS NVARCHAR) + ', ' + CAST(Price AS NVARCHAR) + ', '
  + CAST(Mileage AS NVARCHAR) + ', N''' + ISNULL(FuelType, '') + ''', N'''
  + ISNULL(REPLACE(Description, '''', ''''''), '') + ''', ''' + Status + ''');'
FROM Cars
UNION ALL
SELECT 'SET IDENTITY_INSERT Cars OFF;'
UNION ALL
SELECT 'GO';
" > "$EXPORT_DIR/seed-azure.sql" 2>/dev/null

# 빈 줄/공백 정리
sed -i '/^$/d' "$EXPORT_DIR/seed-azure.sql"
ok "데이터 INSERT 스크립트 생성"

# 행 수 검증
USER_CNT=$(sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -d CarMarket \
  -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM Users" -h -1 -W | head -1 | tr -d ' \r')
CAR_CNT=$(sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -C -d CarMarket \
  -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM Cars" -h -1 -W | head -1 | tr -d ' \r')
ok "소스 DB: Users=${USER_CNT}건, Cars=${CAR_CNT}건"

echo "$USER_CNT $CAR_CNT" > "$EXPORT_DIR/source_counts.txt"
EXPORT_SCRIPT

ok "마이그레이션 데이터 준비 완료"

# =============================================================
# Step 4: Azure SQL에 스키마 적용
# =============================================================
step 4 "Azure SQL Database에 스키마 적용"

# VM에서 Azure SQL로 직접 sqlcmd 실행
ssh "$USER_NAME@$PUBIP" bash -s "$SQL_FQDN" "$SQL_ADMIN" "$SQL_ADMIN_PASSWORD" "$SQL_DB_NAME" << 'APPLY_SCHEMA'
#!/usr/bin/env bash
set -euo pipefail
SQL_FQDN="$1"; SQL_ADMIN="$2"; SQL_ADMIN_PASSWORD="$3"; SQL_DB_NAME="$4"
export PATH="$PATH:/opt/mssql-tools18/bin"
EXPORT_DIR="$HOME/migration_export"

G='\033[0;32m'; NC='\033[0m'
ok() { echo -e "${G}  ✓${NC} $1"; }

echo "  → Azure SQL에 스키마 적용..."
sqlcmd -S "$SQL_FQDN" -U "$SQL_ADMIN" -P "$SQL_ADMIN_PASSWORD" -d "$SQL_DB_NAME" \
  -i "$EXPORT_DIR/schema-azure.sql" > /dev/null
ok "스키마 적용 완료"

echo "  → Azure SQL에 시드 데이터 적용..."
sqlcmd -S "$SQL_FQDN" -U "$SQL_ADMIN" -P "$SQL_ADMIN_PASSWORD" -d "$SQL_DB_NAME" \
  -i "$EXPORT_DIR/seed-azure.sql" > /dev/null 2>&1 || true
ok "시드 데이터 적용"
APPLY_SCHEMA

ok "Azure SQL 스키마 + 시드 적용 완료"

# =============================================================
# Step 5: Azure DMS를 통한 온라인 마이그레이션 (선택)
# =============================================================
step 5 "Azure DMS 리소스 생성 (추가 마이그레이션 도구)"

echo "  ℹ️  소규모 DB는 Step 4의 직접 sqlcmd 방식으로 충분합니다."
echo "  ℹ️  대규모·프로덕션에서는 Azure DMS를 사용합니다."
echo ""

read -p "  DMS 리소스도 생성하시겠습니까? (y/N): " create_dms
if [[ "$create_dms" =~ ^[Yy]$ ]]; then
  # DMS 확장 설치
  az extension add --name dms 2>/dev/null || true

  echo "  → DMS 인스턴스 생성 중 (5~10분)..."
  az dms create \
    --resource-group "$RG" \
    --name "$DMS_NAME" \
    --location "$LOC" \
    --sku-name Standard_1vCores \
    --output none 2>/dev/null || warn "DMS 생성 실패 (수동 생성 필요할 수 있음)"

  ok "DMS '$DMS_NAME' 생성"
  echo ""
  echo "  DMS는 Azure Portal에서 마이그레이션 프로젝트를 생성하여 사용합니다."
  echo "  Portal → Database Migration Service → 새 마이그레이션 프로젝트"
  echo "    소스: SQL Server ($PUBIP:1433)"
  echo "    대상: Azure SQL Database ($SQL_FQDN)"
else
  ok "DMS 생성 건너뜀 (sqlcmd 직접 방식 사용)"
fi

# =============================================================
# Step 6: 마이그레이션 검증
# =============================================================
step 6 "마이그레이션 검증"

echo "  → Azure SQL 데이터 검증..."
VERIFY_RESULT=$(ssh "$USER_NAME@$PUBIP" bash -s "$SQL_FQDN" "$SQL_ADMIN" "$SQL_ADMIN_PASSWORD" "$SQL_DB_NAME" << 'VERIFY'
export PATH="$PATH:/opt/mssql-tools18/bin"
SQL_FQDN="$1"; SQL_ADMIN="$2"; SQL_ADMIN_PASSWORD="$3"; SQL_DB_NAME="$4"

# 테이블 수
TABLE_COUNT=$(sqlcmd -S "$SQL_FQDN" -U "$SQL_ADMIN" -P "$SQL_ADMIN_PASSWORD" -d "$SQL_DB_NAME" \
  -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE'" \
  -h -1 -W 2>/dev/null | head -1 | tr -d ' \r')

# Users 수
USER_COUNT=$(sqlcmd -S "$SQL_FQDN" -U "$SQL_ADMIN" -P "$SQL_ADMIN_PASSWORD" -d "$SQL_DB_NAME" \
  -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM Users" -h -1 -W 2>/dev/null | head -1 | tr -d ' \r')

# Cars 수
CAR_COUNT=$(sqlcmd -S "$SQL_FQDN" -U "$SQL_ADMIN" -P "$SQL_ADMIN_PASSWORD" -d "$SQL_DB_NAME" \
  -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM Cars" -h -1 -W 2>/dev/null | head -1 | tr -d ' \r')

# 인덱스 수
IDX_COUNT=$(sqlcmd -S "$SQL_FQDN" -U "$SQL_ADMIN" -P "$SQL_ADMIN_PASSWORD" -d "$SQL_DB_NAME" \
  -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM sys.indexes WHERE name LIKE 'IX_%'" \
  -h -1 -W 2>/dev/null | head -1 | tr -d ' \r')

echo "$TABLE_COUNT $USER_COUNT $CAR_COUNT $IDX_COUNT"
VERIFY
)

read T_CNT U_CNT C_CNT I_CNT <<< "$VERIFY_RESULT"
ok "Azure SQL 테이블: ${T_CNT}개"
ok "Azure SQL Users:  ${U_CNT}건"
ok "Azure SQL Cars:   ${C_CNT}건"
ok "Azure SQL 인덱스: ${I_CNT}개"

# 소스와 비교
SOURCE_COUNTS=$(ssh "$USER_NAME@$PUBIP" "cat ~/migration_export/source_counts.txt" 2>/dev/null || echo "5 5")
read S_U S_C <<< "$SOURCE_COUNTS"

if [ "$U_CNT" = "$S_U" ] && [ "$C_CNT" = "$S_C" ]; then
  ok "✅ 소스 ↔ 대상 데이터 일치 (Users: $S_U, Cars: $S_C)"
else
  warn "데이터 불일치: 소스(U:$S_U, C:$S_C) ↔ 대상(U:$U_CNT, C:$C_CNT)"
fi

# =============================================================
# Step 7: 연결 정보 저장
# =============================================================
step 7 "연결 정보 저장"

# 환경변수 파일 업데이트
cat >> "$HOME/.carmarket-env" <<EOF

# Azure SQL Database
export SQL_SERVER_NAME=$SQL_SERVER_NAME
export SQL_FQDN=$SQL_FQDN
export SQL_DB_NAME=$SQL_DB_NAME
export SQL_ADMIN=$SQL_ADMIN
export SQL_ADMIN_PASSWORD='$SQL_ADMIN_PASSWORD'
EOF
chmod 600 "$HOME/.carmarket-env"
ok "~/.carmarket-env 업데이트"

# =============================================================
# 완료 안내
# =============================================================
banner "마이그레이션 완료!"

cat <<EOF

┌─────────────────────────────────────────────────────────────┐
│  Azure SQL Database 마이그레이션 결과                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  소스 (VM SQL Server):                                      │
│    $PUBIP:1433 / sa                                         │
│                                                             │
│  대상 (Azure SQL Database):                                 │
│    서버: $SQL_FQDN                                          │
│    DB:   $SQL_DB_NAME                                       │
│    관리자: $SQL_ADMIN                                       │
│                                                             │
│  SSMS 연결 (Azure SQL):                                     │
│    서버: $SQL_FQDN                                          │
│    인증: SQL Server 인증                                     │
│    로그인: $SQL_ADMIN                                       │
│    암호: (설정한 SQL_ADMIN_PASSWORD)                         │
│                                                             │
│  검증: 테이블 ${T_CNT}개, Users ${U_CNT}건, Cars ${C_CNT}건   │
│                                                             │
│  다음 단계:                                                  │
│    bash 03-switch-app-to-azure-sql.sh                       │
│    (Flask 앱을 Azure SQL로 전환)                             │
│                                                             │
│  환경변수: source ~/.carmarket-env                           │
└─────────────────────────────────────────────────────────────┘

EOF

1. Azure SQL Server (논리 서버) + Database (S0) 생성
2. 방화벽 규칙 설정 (VM IP + 로컬 IP + Azure 서비스)
3. VM SQL Server에서 스키마·데이터를 SQL 스크립트로 추출
4. Azure SQL Database에 스키마·시드 데이터 적용
5. Azure DMS 리소스 생성 (선택)
6. 소스 ↔ 대상 데이터 일치 검증

검증

마이그레이션 검증 (SSMS에서)

-- 테이블 구조 비교
SELECT TABLE_NAME,
(SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS c
WHERE c.TABLE_NAME = t.TABLE_NAME) AS ColumnCount
FROM INFORMATION_SCHEMA.TABLES t
WHERE TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_NAME;
-- 행 수 비교 (소스와 동일해야 함)
SELECT 'Users' AS TableName, COUNT(*) AS [RowCount] FROM Users
UNION ALL
SELECT 'Cars', COUNT(*) FROM Cars
UNION ALL
SELECT 'Inquiries', COUNT(*) FROM Inquiries;
-- 데이터 내용 확인
SELECT c.Brand, c.Model, c.Year,
FORMAT(c.Price, 'N0') AS Price,
u.Name AS Seller
FROM Cars c
JOIN Users u ON c.SellerId = u.UserId
ORDER BY c.Price DESC;
-- Azure SQL 특유 정보 확인
SELECT
@@VERSION AS SQLVersion,
DB_NAME() AS DatabaseName,
DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS Edition,
DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective') AS ServiceTier;

VM SQL Server vs Azure SQL Database 비교

Flask 앱 연결 전환

#!/usr/bin/env bash
# ============================================================
# 03-switch-app-to-azure-sql.sh
# Flask 앱 연결 대상을 VM SQL Server → Azure SQL Database로 전환
#
# 사전 조건:
#   - 01, 02 스크립트 완료
#   - source ~/.carmarket-env
#
# 사용법:
#   source ~/.carmarket-env
#   bash 03-switch-app-to-azure-sql.sh
# ============================================================

set -euo pipefail

# 환경변수
RG="${RG:-rg-carmarket-lab}"
VM="${VM:-}"
PUBIP="${PUBIP:-}"
USER_NAME="${USER_NAME:-azureuser}"
SQL_FQDN="${SQL_FQDN:-}"
SQL_DB_NAME="${SQL_DB_NAME:-CarMarket}"
SQL_ADMIN="${SQL_ADMIN:-sqladmin}"
SQL_ADMIN_PASSWORD="${SQL_ADMIN_PASSWORD:-}"

# 색상
G='\033[0;32m'; Y='\033[0;33m'; R='\033[0;31m'; B='\033[0;34m'; NC='\033[0m'
banner() { echo ""; echo -e "${B}═══════════════════════════════════════════════════${NC}"; echo -e "${B}  $1${NC}"; echo -e "${B}═══════════════════════════════════════════════════${NC}"; }
ok()    { echo -e "${G}  ✓${NC} $1"; }
warn()  { echo -e "${Y}  ⚠${NC} $1"; }
abort() { echo -e "${R}❌ $1${NC}"; exit 1; }

banner "Flask 앱 → Azure SQL Database 전환"

# 검증
[ -z "$SQL_FQDN" ] && abort "SQL_FQDN 환경변수 없음. source ~/.carmarket-env"
[ -z "$PUBIP" ] && abort "PUBIP 환경변수 없음. source ~/.carmarket-env"
[ -z "$SQL_ADMIN_PASSWORD" ] && { read -s -p "Azure SQL Admin 비밀번호: " SQL_ADMIN_PASSWORD; echo ""; }

echo ""
echo "  현재:  localhost (VM SQL Server)"
echo "  전환:  $SQL_FQDN (Azure SQL Database)"
echo ""
read -p "  Flask 앱 연결 대상을 Azure SQL로 전환? (y/N): " ok_proceed
[[ "$ok_proceed" =~ ^[Yy]$ ]] || abort "취소됨"

# =============================================================
# VM에서 .env 수정 + 재시작
# =============================================================
echo ""
echo "  → .env 백업 + 수정..."

ssh "$USER_NAME@$PUBIP" bash -s "$SQL_FQDN" "$SQL_DB_NAME" "$SQL_ADMIN" "$SQL_ADMIN_PASSWORD" << 'SWITCH'
#!/usr/bin/env bash
set -euo pipefail
SQL_FQDN="$1"; SQL_DB_NAME="$2"; SQL_ADMIN="$3"; SQL_ADMIN_PASSWORD="$4"
APP_DIR="$HOME/sqlvm_usedcar/app"

G='\033[0;32m'; NC='\033[0m'
ok() { echo -e "${G}  ✓${NC} $1"; }

# 백업
cp "$APP_DIR/.env" "$APP_DIR/.env.vm-backup"
ok "기존 .env 백업 → .env.vm-backup"

# Azure SQL 용 .env 생성
cat > "$APP_DIR/.env" <<EOF
# Azure SQL Database 연결
SA_PASSWORD=$SQL_ADMIN_PASSWORD
DB_SERVER=$SQL_FQDN
DB_NAME=$SQL_DB_NAME
DB_USER=$SQL_ADMIN
FLASK_PORT=5000
EOF
chmod 600 "$APP_DIR/.env"
ok ".env 업데이트 → $SQL_FQDN"

# app.py에서 DB_USER 환경변수 지원하도록 패치 (필요시)
if ! grep -q 'DB_USER' "$APP_DIR/app.py"; then
  # DB_USER = "sa" → 환경변수에서 읽도록 변경
  sed -i 's/DB_USER = "sa"/DB_USER = os.environ.get("DB_USER", "sa")/' "$APP_DIR/app.py"
  ok "app.py: DB_USER 환경변수 지원 패치"
fi

# 재시작
sudo systemctl restart carmarket
sleep 3

if sudo systemctl is-active --quiet carmarket; then
  ok "carmarket.service 재시작 완료"
else
  echo "❌ 서비스 재시작 실패"
  sudo journalctl -u carmarket -n 20 --no-pager
  exit 1
fi

# 헬스체크
HEALTH=$(curl -s --max-time 10 http://localhost:5000/health || echo '{}')
if echo "$HEALTH" | grep -q '"status":"ok"'; then
  ok "Health OK (Azure SQL 연결): $HEALTH"
else
  echo "⚠ Health 실패: $HEALTH"
  echo "  → VM SQL Server로 롤백하려면:"
  echo "     cp $APP_DIR/.env.vm-backup $APP_DIR/.env"
  echo "     sudo systemctl restart carmarket"
fi
SWITCH

# 외부 검증
echo ""
echo "  → 외부 헬스체크..."
sleep 2
HEALTH=$(curl -s --max-time 10 "http://$PUBIP:5000/health" || echo '{}')
if echo "$HEALTH" | grep -q '"status":"ok"'; then
  ok "외부에서 Azure SQL 통해 앱 정상 작동 확인"
else
  warn "외부 헬스체크 실패: $HEALTH"
fi

# API 검증
echo "  → API 테스트 (차량 목록)..."
CARS=$(curl -s --max-time 10 "http://$PUBIP:5000/api/cars" || echo '[]')
CAR_COUNT=$(echo "$CARS" | python3 -c "import sys,json; print(len(json.load(sys.stdin)))" 2>/dev/null || echo "0")
ok "API 응답: Cars ${CAR_COUNT}건"

banner "전환 완료!"

cat <<EOF

┌─────────────────────────────────────────────────────────────┐
│  Flask 앱이 Azure SQL Database를 사용 중입니다               │
│                                                             │
│  웹 앱:  http://$PUBIP:5000/                                │
│  DB:     $SQL_FQDN / $SQL_DB_NAME                           │
│                                                             │
│  롤백 방법 (VM SQL Server로 복귀):                           │
│    ssh $USER_NAME@$PUBIP                                    │
│    cp ~/sqlvm_usedcar/app/.env.vm-backup ~/sqlvm_usedcar/app/.env │
│    sudo systemctl restart carmarket                         │
└─────────────────────────────────────────────────────────────┘

EOF

1. 기존 .env 백업 ( .env.vm-backup )
2. DB 연결 대상을 Azure SQL Database로 변경
3. app.py 에 DB_USER 환경변수 지원 패치
4. carmarket 서비스 재시작
5. 헬스체크 + API 테스트

이후 ssh로 vm 접속

cd ~/sqlvm_usedcar/app
# 1. 현재 DB_USER 확인
grep 'DB_USER' app.py
# 2. app.py 수정 (DB_USER를 환경변수에서 읽도록)
sed -i 's/DB_USER = "sa"/DB_USER = os.environ.get("DB_USER", "sa")/' app.py
# 3. .env에 DB_USER가 있는지 확인
cat .env
# 4. DB_USER가 없으면 추가
grep -q 'DB_USER' .env || echo 'DB_USER=sqladmin' >> .env
# 5. 서비스 재시작
sudo systemctl restart carmarket
# 6. 확인
curl -s http://localhost:5000/health

전환 후 검증

# 헬스체크 — db: connected 확인
curl http://$PUBIP:5000/health
# 차량 목록 — Azure SQL에서 조회
curl http://$PUBIP:5000/api/cars
# 매물 등록 테스트 — Azure SQL에 INSERT
curl -X POST http://$PUBIP:5000/api/cars \
-H "Content-Type: application/json" \
-d '{"seller_id":1,"brand":"기아","model":"카니발","year":2023,"price":38000000,"mileage":10000}'

롤백 (VM SQL Server로 복귀)

ssh azureuser@$PUBIP
cp ~/sqlvm_usedcar/app/.env.vm-backup ~/sqlvm_usedcar/app/.env
sudo systemctl restart carmarket

리소스 정리

source ~/.carmarket-env
# 방법 1: VM만 중지 (데이터 유지, 비용 중단)
bash scripts/99-cleanup.sh
# 방법 2: 전체 삭제 (되돌릴 수 없음)
bash scripts/99-cleanup.sh --delete

SQL Server on Azure Virtual Machines

CIDR

사이더 CIDR(Classless Inter-Domain Routing, 클래스 없는 도메인 간 라우팅)은 1993년 도입된 IP 주소 할당 및 라우팅 효율화 방식입니다. 고정된 클래스 기반 체계(A, B, C)를 대체하여 IP 주소 낭비를 줄이고, 접두어(Prefix)를 사용하여 유연하게 네트워크 영역을 나누어 라우팅 테이블 크기를 줄인다.

SQL Server 인덱스 조각화 문제 감지 및 수정 실습

실습 개요

이 실습은 SQL Server에서 인덱스 조각화(Index Fragmentation) 문제를 감지하고, 조각난 인덱스를 다시 작성하여 쿼리 성능 변화를 확인하는 과정이다.

AdventureWorks 데이터베이스를 복원한 뒤, Person.Address 테이블에 데이터를 추가하여 인덱스 조각화를 인위적으로 발생시킨다. 이후 DMV를 사용해 조각화 수준을 확인하고, ALTER INDEX ... REBUILD로 인덱스를 다시 작성한다. 마지막으로 SET STATISTICS IO, TIME ON을 사용해 논리적 읽기 수가 줄어드는지 비교한다.

실습 배경

AdventureWorks는 10년 넘게 자전거와 자전거 부품을 소비자와 유통업체에 직접 판매해 온 회사이다. 최근 고객 요청을 처리하는 데 사용되는 제품의 성능 저하가 발견되었다.

데이터베이스 관리자는 SQL 도구를 사용하여 성능 문제를 식별하고, 발견된 문제를 해결할 수 있는 실행 가능한 솔루션을 제공해야 한다.

이 실습에서는 다음을 수행한다.

• AdventureWorks2017 데이터베이스 복원
• 인덱스 조각화 상태 확인
• 대량 데이터 삽입으로 조각화 유발
• 조각화된 인덱스 확인
• 논리적 읽기 수 측정
• 인덱스 다시 작성
• 조각화 감소 및 논리적 읽기 감소 확인

참고: SSMS에서 라인 번호 표시하기

T-SQL 코드를 복사하여 실행할 때 디버깅을 쉽게 하기 위해 SSMS 편집기에 라인 번호를 표시할 수 있다.

설정 경로:

Tools → Options → Text Editor → Transact-SQL → General → Line numbers 체크

데이터베이스 복원

1. AdventureWorks2017 백업 파일 다운로드

랩 가상 머신에서 아래 경로의 데이터베이스 백업 파일을 다운로드한다.

https://github.com/MicrosoftLearning/dp-300-database-administrator/blob/master/Instructions/Templates/AdventureWorks2017.bak

다운로드한 파일은 아래 폴더에 저장한다.

C:\LabFiles\Monitor and optimize

해당 폴더가 없다면 직접 생성한다.

2. SSMS 실행

Windows 시작 버튼을 선택하고 SSMS를 입력한다.

목록에서 Microsoft SQL Server Management Studio 18을 선택한다.

3. SQL Server 연결

SSMS가 열리면 Connect to Server 대화 상자가 표시된다.

기본 인스턴스 이름이 미리 채워져 있으면 그대로 Connect를 선택한다.

서버가 보이지 않는 경우에는 다음을 선택해 서버를 찾을 수 있다.

<Browse for more>

4. New Query 선택

Object Explorer에서 Databases 폴더를 선택한 뒤, 상단의 New Query를 선택한다.

5. 데이터베이스 복원 쿼리 실행

New Query 창에 아래 T-SQL을 복사하여 붙여넣고 실행한다.

RESTORE DATABASE AdventureWorks2017
FROM DISK = 'C:\LabFiles\Monitor and optimize\AdventureWorks2017.bak'
WITH RECOVERY,
 MOVE 'AdventureWorks2017'
 TO 'C:\LabFiles\Monitor and optimize\AdventureWorks2017.mdf',
 MOVE 'AdventureWorks2017_log'
 TO 'C:\LabFiles\Monitor and optimize\AdventureWorks2017_log.ldf';

백업 파일 이름과 경로는 실제 다운로드한 파일 위치와 일치해야 한다. 경로가 다르면 복원 명령이 실패한다.

6. 복원 성공 확인

복원이 완료되면 메시지 창에 성공 메시지가 표시된다.

예시:

RESTORE DATABASE successfully processed ... pages ...

인덱스 조각화 조사

1. 현재 조각화 상태 확인

New Query를 선택한 뒤 아래 T-SQL 코드를 실행한다.

USE AdventureWorks2017
GO
SELECT i.name Index_Name
, avg_fragmentation_in_percent
, db_name(database_id)
, i.object_id
, i.index_id
, index_type_desc
FROM
sys.dm_db_index_physical_stats(db_id('AdventureWorks2017'),object_id('person.address'),NULL,NULL,'DETAILED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
AND ps.index_id = i.index_id
WHERE avg_fragmentation_in_percent > 50
-- find indexes where fragmentation is greater than 50%

이 쿼리는 Person.Address 테이블에서 조각화가 50%를 초과하는 인덱스를 조회한다.

처음 실행하면 반환되는 결과가 없다. 즉, 현재는 50%를 초과하는 조각화된 인덱스가 없는 상태이다.

2. 데이터 삽입으로 조각화 유발

다음 T-SQL을 실행하여 Person.Address 테이블에 많은 수의 새 레코드를 삽입한다.

USE AdventureWorks2017
GO

INSERT INTO [Person].[Address]
 ([AddressLine1]
 ,[AddressLine2]
 ,[City]
 ,[StateProvinceID]
 ,[PostalCode]
 ,[SpatialLocation]
 ,[rowguid]
 ,[ModifiedDate])

SELECT AddressLine1,
 AddressLine2, 
 'Amsterdam',
 StateProvinceID, 
 PostalCode, 
 SpatialLocation, 
 newid(), 
 getdate()
FROM Person.Address;
GO

이 쿼리는 기존 Person.Address 데이터를 다시 읽어 같은 테이블에 추가 삽입한다.

특히 City 값을 'Amsterdam'으로 고정하여 삽입한다. 결과적으로 행 개수가 약 2배로 늘어나고, Person.Address 테이블과 관련 인덱스의 조각화 수준이 증가한다.

3. 조각화 상태 다시 확인

처음 실행했던 조각화 확인 쿼리를 다시 실행한다.

USE AdventureWorks2017
GO
SELECT i.name Index_Name
, avg_fragmentation_in_percent
, db_name(database_id)
, i.object_id
, i.index_id
, index_type_desc
FROM
sys.dm_db_index_physical_stats(db_id('AdventureWorks2017'),object_id('person.address'),NULL,NULL,'DETAILED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
AND ps.index_id = i.index_id
WHERE avg_fragmentation_in_percent > 50
-- find indexes where fragmentation is greater than 50%

이제 고도로 조각난 인덱스 4개를 확인할 수 있다.

예시 결과에서는 다음과 같은 인덱스들이 50% 이상의 조각화를 보인다.

논리적 읽기 수 측정

1. STATISTICS IO, TIME 활성화 후 쿼리 실행

다음 쿼리를 실행한다.

SET STATISTICS IO,TIME ON
GO

USE AdventureWorks2017
GO

SELECT DISTINCT (StateProvinceID)
 ,count(StateProvinceID) AS CustomerCount
FROM person.Address
GROUP BY StateProvinceID
ORDER BY count(StateProvinceID) DESC;
GO

이 쿼리는 Person.Address 테이블에서 StateProvinceID별 건수를 집계하고, 건수가 많은 순서대로 정렬한다.

2. Messages 탭에서 logical reads 확인

SQL Server Management Studio의 결과 창에서 Messages 탭을 클릭한다.

여기에서 쿼리에 의해 수행된 논리적 읽기 수를 확인한다.

실습 자료 기준으로 조각화된 상태에서의 논리적 읽기 수는 다음과 같다.

logical reads = 94

논리적 읽기(logical reads)는 SQL Server가 버퍼 캐시에서 읽은 데이터 페이지 수를 의미한다.

조각화가 심하면 쿼리가 필요한 데이터를 찾기 위해 더 많은 페이지를 읽게 되고, 이로 인해 성능 저하가 발생할 수 있다.

조각난 인덱스 다시 작성

1. IX_Address_StateProvinceID 인덱스 REBUILD

다음 T-SQL을 실행하여 IX_Address_StateProvinceID 인덱스를 다시 작성한다.

USE AdventureWorks2017
GO
ALTER INDEX [IX_Address_StateProvinceID] ON [Person].[Address] REBUILD PARTITION = ALL
WITH (PAD_INDEX = OFF, 
 STATISTICS_NORECOMPUTE = OFF, 
 SORT_IN_TEMPDB = OFF, 
 IGNORE_DUP_KEY = OFF, 
 ONLINE = OFF, 
 ALLOW_ROW_LOCKS = ON, 
 ALLOW_PAGE_LOCKS = ON)

ALTER INDEX ... REBUILD는 인덱스를 새로 다시 만드는 작업이다.

이를 통해 인덱스 페이지가 정리되고, 논리적 순서와 물리적 순서가 더 잘 맞춰지며, 페이지 내부의 빈 공간도 정리된다.

2. 인덱스 조각화 감소 확인

아래 쿼리를 실행하여 IX_Address_StateProvinceID 인덱스의 조각화가 더 이상 50%를 초과하지 않는지 확인한다.

USE AdventureWorks2017
GO

SELECT DISTINCT i.name Index_Name
 , avg_fragmentation_in_percent
 , db_name(database_id)
 , i.object_id
 , i.index_id
 , index_type_desc
FROM
sys.dm_db_index_physical_stats(db_id('AdventureWorks2017'),object_id('person.address'),NULL,NULL,'DETAILED') ps
 INNER JOIN sys.indexes i ON (ps.object_id = i.object_id AND ps.index_id = i.index_id)
WHERE i.name = 'IX_Address_StateProvinceID'

결과를 비교하면 IX_Address_StateProvinceID 인덱스의 조각화가 약 81%에서 0%로 감소한 것을 확인할 수 있다.

인덱스 재작성 후 논리적 읽기 비교

1. 동일한 SELECT 쿼리 재실행

이전 섹션에서 실행했던 집계 쿼리를 다시 실행한다.

SET STATISTICS IO,TIME ON
GO

USE AdventureWorks2017
GO

SELECT DISTINCT (StateProvinceID)
 ,count(StateProvinceID) AS CustomerCount
FROM person.Address
GROUP BY StateProvinceID
ORDER BY count(StateProvinceID) DESC;

GO

2. Messages 탭에서 logical reads 재확인

인덱스를 다시 작성했기 때문에 이전보다 효율적으로 데이터를 읽을 수 있다.

실습 자료 기준으로 인덱스 재작성 후 논리적 읽기는 다음과 같이 감소한다.

logical reads = 70

즉, 인덱스 유지 관리가 쿼리 성능에 영향을 줄 수 있다는 것을 확인할 수 있다.

실습 결과 정리

이번 실습에서는 인덱스를 다시 작성하고 논리적 읽기를 분석하여 쿼리 성능을 높이는 방법을 확인했다.

1. 인덱스 조각화의 이해 및 영향 확인

인덱스 조각화(Index Fragmentation)는 데이터베이스에서 데이터가 삽입, 업데이트, 삭제되는 과정에서 발생한다.

인덱스의 논리적 순서와 실제 디스크상의 물리적 순서가 달라지거나, 데이터 페이지 내부에 빈 공간이 생기는 현상을 말한다.

이 실습에서는 대량의 데이터를 삽입하여 인덱스 조각화를 인위적으로 발생시켰다. 이를 통해 조각화가 실제로 어떻게 발생하는지 간접적으로 경험할 수 있었다.

가장 중요한 점은 조각화가 심해지면 SQL Server가 데이터를 읽을 때 더 많은 페이지를 읽어야 한다는 것이다.

그래서 이 실습에서는 SET STATISTICS IO ON을 사용해 논리적 읽기(Logical Reads) 횟수를 측정했다. 조각화된 인덱스를 사용하는 쿼리는 불필요하게 많은 페이지를 읽게 되어 성능 저하를 유발할 수 있다.

2. 조각화 진단 방법 학습

조각화 상태는 sys.dm_db_index_physical_stats 동적 관리 뷰(DMV)를 사용해 확인한다.

이 DMV를 통해 특정 테이블이나 특정 인덱스의 조각화 수준을 퍼센트로 확인할 수 있다.

DBA가 시스템 상태를 진단할 때 사용하는 핵심 도구 중 하나이다.

3. 조각화 해결 방법 학습 및 효과 검증

심하게 조각화된 인덱스는 ALTER INDEX REBUILD 명령어를 사용하여 다시 작성할 수 있다.

인덱스 재구축은 인덱스 페이지를 새로 만들고, 물리적 순서를 논리적 순서에 가깝게 정리하며, 페이지 내부의 빈 공간을 제거한다.

참고로 ALTER INDEX REORGANIZE는 온라인으로 조각화를 일부 정리하는 다른 방법이다.

실습에서는 인덱스를 재구축한 후 동일한 쿼리를 다시 실행했다. 그 결과 논리적 읽기 수가 감소하는 것을 확인했다.

이는 조각화 해결이 실제 쿼리 성능 향상으로 이어질 수 있음을 보여준다.

4. 데이터베이스 유지 관리의 중요성

인덱스 조각화는 시간이 지나면서 자연스럽게 발생한다.

따라서 데이터베이스 성능을 최적으로 유지하려면 정기적인 인덱스 유지 관리가 필요하다.

DBA는 주기적으로 조각화 수준을 모니터링하고, 필요에 따라 인덱스를 재구성하거나 다시 작성해야 한다.

핵심 요약

사용한 주요 T-SQL 모음

데이터베이스 복원

RESTORE DATABASE AdventureWorks2017
FROM DISK = 'C:\LabFiles\Monitor and optimize\AdventureWorks2017.bak'
WITH RECOVERY,
 MOVE 'AdventureWorks2017'
 TO 'C:\LabFiles\Monitor and optimize\AdventureWorks2017.mdf',
 MOVE 'AdventureWorks2017_log'
 TO 'C:\LabFiles\Monitor and optimize\AdventureWorks2017_log.ldf';

조각화 확인

USE AdventureWorks2017
GO
SELECT i.name Index_Name
, avg_fragmentation_in_percent
, db_name(database_id)
, i.object_id
, i.index_id
, index_type_desc
FROM
sys.dm_db_index_physical_stats(db_id('AdventureWorks2017'),object_id('person.address'),NULL,NULL,'DETAILED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
AND ps.index_id = i.index_id
WHERE avg_fragmentation_in_percent > 50
-- find indexes where fragmentation is greater than 50%

데이터 삽입으로 조각화 유발

USE AdventureWorks2017
GO

INSERT INTO [Person].[Address]
 ([AddressLine1]
 ,[AddressLine2]
 ,[City]
 ,[StateProvinceID]
 ,[PostalCode]
 ,[SpatialLocation]
 ,[rowguid]
 ,[ModifiedDate])

SELECT AddressLine1,
 AddressLine2, 
 'Amsterdam',
 StateProvinceID, 
 PostalCode, 
 SpatialLocation, 
 newid(), 
 getdate()
FROM Person.Address;
GO

논리적 읽기 측정

SET STATISTICS IO,TIME ON
GO

USE AdventureWorks2017
GO

SELECT DISTINCT (StateProvinceID)
 ,count(StateProvinceID) AS CustomerCount
FROM person.Address
GROUP BY StateProvinceID
ORDER BY count(StateProvinceID) DESC;
GO

인덱스 다시 작성

USE AdventureWorks2017
GO
ALTER INDEX [IX_Address_StateProvinceID] ON [Person].[Address] REBUILD PARTITION = ALL
WITH (PAD_INDEX = OFF, 
 STATISTICS_NORECOMPUTE = OFF, 
 SORT_IN_TEMPDB = OFF, 
 IGNORE_DUP_KEY = OFF, 
 ONLINE = OFF, 
 ALLOW_ROW_LOCKS = ON, 
 ALLOW_PAGE_LOCKS = ON)

특정 인덱스 조각화 확인

USE AdventureWorks2017
GO

SELECT DISTINCT i.name Index_Name
 , avg_fragmentation_in_percent
 , db_name(database_id)
 , i.object_id
 , i.index_id
 , index_type_desc
FROM
sys.dm_db_index_physical_stats(db_id('AdventureWorks2017'),object_id('person.address'),NULL,NULL,'DETAILED') ps
 INNER JOIN sys.indexes i ON (ps.object_id = i.object_id AND ps.index_id = i.index_id)
WHERE i.name = 'IX_Address_StateProvinceID'

VM 생성

디스크

여기서는 안쓰지만, 디스크를 사용하여 애플리케이션 등 저장이 가능하다.

자동 종료

관리탭

이후 검토 + 만들기 하고 .pem 확장자의 ssh 키를 다운받는다.

VM 연결

SSH 명령 탭의 경로 입력하기

powershell 연결

ssh -i "키경로" azureuser@ip주소

OS 정보 확인

패키지 업데이트

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl wget gnupg2 software-properties-common apt-transport-https ca-certificates

Swap 파일 생성(SQL Server 안정성)

B2s의 4GB RAM은 SQL Server + Python + OS 동시 구동에 빠듯합니다. 2GB swap을 추가하여 OOM Killer 발동을 예방합니다.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h 출력의 Swap 행에 2.0Gi 표시되면 OK. Swap(스왑) 파일은 물리적 메모리(RAM)가 부족할 때 디스크(HDD/SSD)의 일부를 메모리처럼 사용하는 가상 메모리 공간입니다.RAM이 가득 찼을 때 스왑 공간이 없으면 리눅스 커널은 OOM(Out of Memory) Killer를 동작시켜 중요 프로세스를 강제로 종료합니다. 스왑 파일은 이러한 갑작스러운 시스템 멈춤이나 응용 프로그램 종료를 막아줍니다.

시간대 설정

SQL Server2025 설치

Microsoft 공식 저장소 등록

# Microsoft GPG 키 등록 (Ubuntu 24.04 권장 방식)
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg

# SQL Server 2025 저장소 등록 (Ubuntu 24.04 공식)
curl -fsSL https://packages.microsoft.com/config/ubuntu/24.04/mssql-server-2025.list | \
  sudo tee /etc/apt/sources.list.d/mssql-server-2025.list

sudo apt update

SQL Server 패키지 설치

sudo apt install -y mssql-server

mssql-conf setup — Edition · 비밀번호 설정

sudo /opt/mssql/bin/mssql-conf setup

서비스 상태 확인

systemctl status mssql-server --no-pager

Active: active (running) 표시되면 OK. LISTEN 0.0.0.0:1433 으로 바인딩 — 다음 단계에서 localhost-only로 변경합니다.

SQL Server를 localhost 전용으로 바인딩 (보안 핵심)

SQL Server를 외부에 노출하면 Brute force 공격의 1순위 대상이 됩니다. NSG뿐 아니라 SQL Server 자체에서도 localhost만 바인딩하도록 이중 차단합니다.

# /var/opt/mssql/mssql.conf 에 IP 바인딩 설정 추가
sudo /opt/mssql/bin/mssql-conf set network.ipaddress 127.0.0.1
sudo systemctl restart mssql-server
sudo ss -tlnp | grep 1433

ss 출력이 127.0.0.1:1433 으로만 표시되면 OK. 0.0.0.0:1433 또는 *:1433 이면 실패.

설정 제거 방법

sudo /opt/mssql/bin/mssql-conf unset network.ipaddress
sudo systemctl restart mssql-server

0.0.0.0:1433 나오면 외부 접속 가능 상태

mssql-tools, ODBC Driver, Python

# prod.list 저장소 등록 (Ubuntu 24.04용)
curl -fsSL https://packages.microsoft.com/config/ubuntu/24.04/prod.list | \
  sudo tee /etc/apt/sources.list.d/mssql-release.list

sudo apt update
sudo ACCEPT_EULA=Y apt install -y mssql-tools18 unixodbc-dev msodbcsql18

# PATH에 sqlcmd 추가
echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> ~/.bashrc
source ~/.bashrc

sqlcmd 접속

sqlcmd -S localhost -U sa -P '<SA_비밀번호>' -C -Q "SELECT @@VERSION"

Microsoft SQL Server 2025 (RTM-CU...) 또는 17.x 버전 정보 출력되면 OK.

• -C 옵션: TrustServerCertificate (자체 서명 인증서 신뢰). 실습용.
• 비밀번호에 특수문자가 있을 때는 작은따옴표 ' ' 로 감쌀 것.
• 명령 히스토리에 비밀번호가 남는 것을 피하려면 -P 생략 후 프롬프트 입력 권장.

Python3 + 가상환경 + 필수 패키지 설치

sudo apt install -y python3 python3-pip python3-venv

# 작업 디렉토리
mkdir -p ~/carmarket && cd ~/carmarket

# 가상환경 생성
python3 -m venv venv
source venv/bin/activate

# 패키지 설치
pip install --upgrade pip
pip install flask pyodbc python-dotenv gunicorn

pip list | grep -E 'Flask|pyodbc|python-dotenv' 로 3개 패키지 출력 확인.

pyodbc 동작 검증

python3 -c "import pyodbc; print(pyodbc.drivers())"

출력에 ['ODBC Driver 18 for SQL Server'] 가 포함되면 OK.

데이터베이스, 스키마, 시드 데이터

CarMarket 데이터베이스를 만들고 Users, Cars, Inquiries 3-table 모델을 구축, 시드 데이터를 적재

스키마 SQL 파일 작성

cd ~/carmarket
nano schema.sql

schema.sql

CREATE DATABASE CarMarket;
GO
USE CarMarket;
GO

CREATE TABLE Users (
    UserId    INT IDENTITY(1,1) PRIMARY KEY,
    Name      NVARCHAR(100) NOT NULL,
    Email     NVARCHAR(200) NOT NULL UNIQUE,
    Phone     NVARCHAR(20),
    UserType  NVARCHAR(10) NOT NULL DEFAULT 'both'
              CHECK (UserType IN ('seller','buyer','both')),
    CreatedAt DATETIME2 DEFAULT SYSUTCDATETIME()
);

CREATE TABLE Cars (
    CarId       INT IDENTITY(1,1) PRIMARY KEY,
    SellerId    INT NOT NULL FOREIGN KEY REFERENCES Users(UserId),
    Brand       NVARCHAR(50) NOT NULL,
    Model       NVARCHAR(100) NOT NULL,
    Year        INT NOT NULL,
    Price       DECIMAL(12,0) NOT NULL,
    Mileage     INT NOT NULL,
    FuelType    NVARCHAR(20),
    Description NVARCHAR(MAX),
    Status      NVARCHAR(20) NOT NULL DEFAULT 'available'
                CHECK (Status IN ('available','reserved','sold')),
    CreatedAt   DATETIME2 DEFAULT SYSUTCDATETIME()
);

CREATE TABLE Inquiries (
    InquiryId INT IDENTITY(1,1) PRIMARY KEY,
    CarId     INT NOT NULL FOREIGN KEY REFERENCES Cars(CarId),
    BuyerId   INT NOT NULL FOREIGN KEY REFERENCES Users(UserId),
    Message   NVARCHAR(1000) NOT NULL,
    CreatedAt DATETIME2 DEFAULT SYSUTCDATETIME()
);

CREATE INDEX IX_Cars_Brand     ON Cars(Brand);
CREATE INDEX IX_Cars_Status    ON Cars(Status);
CREATE INDEX IX_Cars_CreatedAt ON Cars(CreatedAt DESC);
GO

시드 데이터 작성

nano seed.sql

USE CarMarket;
GO

INSERT INTO Users (Name, Email, Phone, UserType) VALUES
(N'김판매', 'seller1@test.com', '010-1111-1111', 'seller'),
(N'이판매', 'seller2@test.com', '010-2222-2222', 'seller'),
(N'박판매', 'seller3@test.com', '010-3333-3333', 'seller'),
(N'최구매', 'buyer1@test.com',  '010-4444-4444', 'buyer'),
(N'정구매', 'buyer2@test.com',  '010-5555-5555', 'buyer');

INSERT INTO Cars (SellerId, Brand, Model, Year, Price, Mileage, FuelType, Description) VALUES
(1, N'현대',   N'쏘나타 DN8',     2021, 18500000, 45000, N'가솔린', N'무사고, 1인 소유, 정기점검 완료'),
(1, N'기아',   N'K5 3세대',        2020, 16000000, 62000, N'가솔린', N'썬루프, 어라운드뷰 옵션'),
(2, N'BMW',   N'520d (G30)',      2019, 28000000, 78000, N'디젤',   N'풀옵션, 가죽시트, 무사고'),
(2, N'벤츠',   N'E300 (W213)',     2020, 38000000, 55000, N'가솔린', N'AMG 패키지, 1인 소유'),
(3, N'제네시스', N'G80 (RG3)',      2022, 45000000, 28000, N'가솔린', N'신차급, 출고 1년');
GO

sql 파일 실행

read -s -p "SA Password: " SA_PWD
export SA_PWD

sqlcmd -S localhost -U sa -P "$SA_PWD" -C -i schema.sql
sqlcmd -S localhost -U sa -P "$SA_PWD" -C -i seed.sql

데이터 검증

sqlcmd -S localhost -U sa -P "$SA_PWD" -C -d CarMarket -Q \
  "SELECT c.Brand, c.Model, c.Year, c.Price, u.Name AS Seller
   FROM Cars c JOIN Users u ON c.SellerId = u.UserId
   ORDER BY c.Price DESC"

Flask 백엔드 구현(REST API)

Python Flask로 5개의 REST 엔드포인트(/health, GET·POST /cars, POST /inquiries, GET /users)를 구현하고 SQL Server와 연결

.env파일로 비밀번호 분리

nano .env

SA_PASSWORD=YourStrongP@ssw0rd
DB_SERVER=localhost
DB_NAME=CarMarket
FLASK_PORT=5000

# 권한 600 — 본인만 읽기·쓰기
chmod 600 .env
ls -la .env

app.py

nano app.py

import os
from contextlib import contextmanager
import pyodbc
from flask import Flask, request, jsonify, render_template_string
from dotenv import load_dotenv

load_dotenv()

app = Flask(__name__)

DB_SERVER   = os.environ.get("DB_SERVER", "localhost")
DB_NAME     = os.environ.get("DB_NAME", "CarMarket")
DB_USER     = "sa"
DB_PASSWORD = os.environ.get("SA_PASSWORD")
FLASK_PORT  = int(os.environ.get("FLASK_PORT", 5000))

CONN_STR = (
    "DRIVER={ODBC Driver 18 for SQL Server};"
    f"SERVER={DB_SERVER};DATABASE={DB_NAME};"
    f"UID={DB_USER};PWD={DB_PASSWORD};"
    "TrustServerCertificate=yes;Encrypt=yes;"
)

@contextmanager
def db():
    conn = pyodbc.connect(CONN_STR, autocommit=False)
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise
    finally:
        conn.close()

# ====== Health check ======
@app.route("/health")
def health():
    try:
        with db() as conn:
            cur = conn.cursor()
            cur.execute("SELECT 1")
            cur.fetchone()
        return jsonify({"status": "ok", "db": "connected"}), 200
    except Exception as e:
        return jsonify({"status": "error", "db": str(e)}), 500

# ====== Users ======
@app.route("/api/users", methods=["GET"])
def list_users():
    with db() as conn:
        cur = conn.cursor()
        cur.execute("SELECT UserId, Name, Email, Phone, UserType FROM Users ORDER BY UserId")
        rows = cur.fetchall()
    return jsonify([
        {"id": r[0], "name": r[1], "email": r[2], "phone": r[3], "type": r[4]}
        for r in rows
    ])

# ====== Cars: 목록 + 검색 ======
@app.route("/api/cars", methods=["GET"])
def list_cars():
    brand = request.args.get("brand")
    max_price = request.args.get("max_price", type=int)

    sql = """
        SELECT c.CarId, u.Name, c.Brand, c.Model, c.Year, c.Price,
               c.Mileage, c.FuelType, c.Description, c.Status, c.CreatedAt
          FROM Cars c
          JOIN Users u ON c.SellerId = u.UserId
         WHERE c.Status = 'available'
    """
    params = []
    if brand:
        sql += " AND c.Brand = ?"
        params.append(brand)
    if max_price:
        sql += " AND c.Price <= ?"
        params.append(max_price)
    sql += " ORDER BY c.CreatedAt DESC"

    with db() as conn:
        cur = conn.cursor()
        cur.execute(sql, params)
        rows = cur.fetchall()

    return jsonify([
        {
            "id": r[0], "seller": r[1], "brand": r[2], "model": r[3],
            "year": r[4], "price": int(r[5]), "mileage": r[6],
            "fuel": r[7], "desc": r[8], "status": r[9],
            "created_at": r[10].isoformat() if r[10] else None
        } for r in rows
    ])

# ====== Cars: 등록 ======
@app.route("/api/cars", methods=["POST"])
def create_car():
    data = request.get_json(silent=True) or {}
    required = ["seller_id", "brand", "model", "year", "price", "mileage"]
    missing = [k for k in required if k not in data]
    if missing:
        return jsonify({"error": f"missing fields: {missing}"}), 400

    with db() as conn:
        cur = conn.cursor()
        cur.execute("""
            INSERT INTO Cars (SellerId, Brand, Model, Year, Price, Mileage, FuelType, Description)
            OUTPUT INSERTED.CarId
            VALUES (?, ?, ?, ?, ?, ?, ?, ?)
        """, data["seller_id"], data["brand"], data["model"], int(data["year"]),
             int(data["price"]), int(data["mileage"]),
             data.get("fuel", ""), data.get("desc", ""))
        new_id = cur.fetchone()[0]
    return jsonify({"car_id": new_id}), 201

# ====== Inquiries ======
@app.route("/api/inquiries", methods=["POST"])
def create_inquiry():
    data = request.get_json(silent=True) or {}
    for k in ("car_id", "buyer_id", "message"):
        if k not in data:
            return jsonify({"error": f"missing {k}"}), 400

    with db() as conn:
        cur = conn.cursor()
        cur.execute("""
            INSERT INTO Inquiries (CarId, BuyerId, Message)
            OUTPUT INSERTED.InquiryId
            VALUES (?, ?, ?)
        """, int(data["car_id"]), int(data["buyer_id"]), data["message"])
        new_id = cur.fetchone()[0]
    return jsonify({"inquiry_id": new_id}), 201

# ====== UI: 단일 페이지 (Step 8에서 추가) ======
INDEX_HTML = ""  # Step 8에서 채움

@app.route("/")
def index():
    return render_template_string(INDEX_HTML)

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=FLASK_PORT, debug=False)

로컬 테스트

source venv/bin/activate
python app.py

# 다른 터미널 또는 같은 세션에서:
curl -s http://localhost:5000/health | python3 -m json.tool

API 동작 테스트

curl -s http://localhost:5000/api/cars | python3 -m json.tool

# 브랜드 필터
curl -s "http://localhost:5000/api/cars?brand=BMW" | python3 -m json.tool

# 차량 등록
curl -s -X POST http://localhost:5000/api/cars \
  -H "Content-Type: application/json" \
  -d '{"seller_id":1,"brand":"기아","model":"카니발","year":2022,"price":35000000,"mileage":15000,"fuel":"디젤","desc":"하이리무진 풀옵"}' \
  | python3 -m json.tool

# 문의 등록
curl -s -X POST http://localhost:5000/api/inquiries \
  -H "Content-Type: application/json" \
  -d '{"car_id":1,"buyer_id":4,"message":"실차 확인 가능한가요?"}' \
  | python3 -m json.tool

백그라운드 프로세스 종료

ps aux | grep "[p]ython app.py"
kill <PID>

프론트엔드

Bootstrap 5 CDN으로 차량 목록·등록·문의 UI를 구현. 단일 HTML 문자열을 Flask render_template_string으로 제공

app.py의 INDEX_HTML = "" 라인을 아래 내용으로 교체

INDEX_HTML = """
<!doctype html>
<html lang="ko">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>중고차 마켓 MVP</title>
  <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet">
  <style>
    body { background:#f4f8fa; }
    .navbar { background:#21295C !important; }
    .card-car { transition: transform .15s; }
    .card-car:hover { transform: translateY(-3px); box-shadow:0 6px 20px rgba(0,0,0,.08);}
    .price { color:#065A82; font-weight:700; }
    .badge-status { font-size: .75rem; }
  </style>
</head>
<body>
<nav class="navbar navbar-dark px-4">
  <span class="navbar-brand mb-0 h4">🚗 중고차 마켓 MVP</span>
  <div>
    <button class="btn btn-light btn-sm me-2" onclick="showRegister()">+ 매물 등록</button>
    <span id="health" class="badge bg-secondary">checking…</span>
  </div>
</nav>

<div class="container my-4">
  <div class="row g-2 mb-3 align-items-end">
    <div class="col-md-3">
      <label class="form-label small">브랜드</label>
      <select id="filterBrand" class="form-select form-select-sm">
        <option value="">전체</option>
        <option>현대</option><option>기아</option><option>제네시스</option>
        <option>BMW</option><option>벤츠</option>
      </select>
    </div>
    <div class="col-md-3">
      <label class="form-label small">최대 가격(원)</label>
      <input id="filterPrice" type="number" class="form-control form-control-sm" placeholder="예: 30000000">
    </div>
    <div class="col-md-2">
      <button class="btn btn-primary btn-sm w-100" onclick="loadCars()">검색</button>
    </div>
    <div class="col-md-4 text-end">
      <small class="text-muted" id="count"></small>
    </div>
  </div>

  <div id="cars" class="row g-3"></div>
</div>

<!-- 등록 모달 -->
<div class="modal fade" id="regModal" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header bg-primary text-white"><h5 class="modal-title">매물 등록</h5></div>
      <div class="modal-body">
        <div class="row g-2">
          <div class="col-6"><label class="form-label">판매자</label>
            <select id="r_seller" class="form-select"></select></div>
          <div class="col-6"><label class="form-label">브랜드</label>
            <input id="r_brand" class="form-control" placeholder="현대"></div>
          <div class="col-6"><label class="form-label">모델</label>
            <input id="r_model" class="form-control"></div>
          <div class="col-3"><label class="form-label">연식</label>
            <input id="r_year" type="number" class="form-control" value="2022"></div>
          <div class="col-3"><label class="form-label">연료</label>
            <input id="r_fuel" class="form-control" placeholder="가솔린"></div>
          <div class="col-6"><label class="form-label">가격(원)</label>
            <input id="r_price" type="number" class="form-control"></div>
          <div class="col-6"><label class="form-label">주행(km)</label>
            <input id="r_mile" type="number" class="form-control"></div>
          <div class="col-12"><label class="form-label">설명</label>
            <textarea id="r_desc" rows="2" class="form-control"></textarea></div>
        </div>
      </div>
      <div class="modal-footer">
        <button class="btn btn-secondary" data-bs-dismiss="modal">취소</button>
        <button class="btn btn-primary" onclick="submitCar()">등록</button>
      </div>
    </div>
  </div>
</div>

<!-- 문의 모달 -->
<div class="modal fade" id="inqModal" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header bg-info text-white"><h5 class="modal-title">문의하기</h5></div>
      <div class="modal-body">
        <p class="text-muted small mb-2">차량 ID: <span id="inq_car_id"></span></p>
        <label class="form-label">구매자</label>
        <select id="inq_buyer" class="form-select mb-2"></select>
        <label class="form-label">메시지</label>
        <textarea id="inq_msg" class="form-control" rows="3"></textarea>
      </div>
      <div class="modal-footer">
        <button class="btn btn-secondary" data-bs-dismiss="modal">취소</button>
        <button class="btn btn-info text-white" onclick="submitInquiry()">전송</button>
      </div>
    </div>
  </div>
</div>

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js"></script>
<script>
let users = [];

async function checkHealth() {
  try {
    const r = await fetch('/health');
    const j = await r.json();
    document.getElementById('health').className = 'badge ' + (j.status==='ok' ? 'bg-success' : 'bg-danger');
    document.getElementById('health').textContent = 'DB ' + j.status;
  } catch (e) {
    document.getElementById('health').className = 'badge bg-danger';
    document.getElementById('health').textContent = 'DB error';
  }
}

async function loadUsers() {
  const r = await fetch('/api/users');
  users = await r.json();
  const sellerSel = document.getElementById('r_seller');
  const buyerSel  = document.getElementById('inq_buyer');
  sellerSel.innerHTML = users.filter(u => u.type !== 'buyer')
    .map(u => '<option value="' + u.id + '">' + u.name + ' (' + u.email + ')</option>').join('');
  buyerSel.innerHTML  = users.filter(u => u.type !== 'seller')
    .map(u => '<option value="' + u.id + '">' + u.name + '</option>').join('');
}

async function loadCars() {
  const brand = document.getElementById('filterBrand').value;
  const price = document.getElementById('filterPrice').value;
  const params = new URLSearchParams();
  if (brand) params.append('brand', brand);
  if (price) params.append('max_price', price);
  const r = await fetch('/api/cars?' + params);
  const cars = await r.json();
  document.getElementById('count').textContent = '검색 결과: ' + cars.length + '건';
  document.getElementById('cars').innerHTML = cars.map(function(c) {
    return '' +
      '<div class="col-md-6 col-lg-4">' +
        '<div class="card card-car h-100"><div class="card-body">' +
          '<div class="d-flex justify-content-between">' +
            '<h5 class="card-title mb-0">' + c.brand + ' ' + c.model + '</h5>' +
            '<span class="badge bg-success badge-status">' + c.status + '</span>' +
          '</div>' +
          '<p class="text-muted small mt-1">' + c.year + '년식 · ' + c.mileage.toLocaleString() + 'km · ' + (c.fuel||'-') + '</p>' +
          '<p class="price h5 mb-2">' + c.price.toLocaleString() + ' 원</p>' +
          '<p class="small mb-2">' + (c.desc||'') + '</p>' +
          '<p class="small text-muted mb-2">판매자: ' + c.seller + '</p>' +
          '<button class="btn btn-sm btn-outline-info" onclick="openInquiry(' + c.id + ')">문의하기</button>' +
        '</div></div>' +
      '</div>';
  }).join('');
}

function showRegister() { new bootstrap.Modal(document.getElementById('regModal')).show(); }

async function submitCar() {
  const body = {
    seller_id: parseInt(document.getElementById('r_seller').value),
    brand:   document.getElementById('r_brand').value.trim(),
    model:   document.getElementById('r_model').value.trim(),
    year:    parseInt(document.getElementById('r_year').value),
    price:   parseInt(document.getElementById('r_price').value),
    mileage: parseInt(document.getElementById('r_mile').value),
    fuel:    document.getElementById('r_fuel').value.trim(),
    desc:    document.getElementById('r_desc').value.trim(),
  };
  const r = await fetch('/api/cars', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify(body)
  });
  if (r.ok) {
    alert('등록 완료!');
    bootstrap.Modal.getInstance(document.getElementById('regModal')).hide();
    loadCars();
  } else {
    alert('실패: ' + (await r.text()));
  }
}

function openInquiry(carId) {
  document.getElementById('inq_car_id').textContent = carId;
  document.getElementById('inq_msg').value = '';
  new bootstrap.Modal(document.getElementById('inqModal')).show();
}

async function submitInquiry() {
  const body = {
    car_id:   parseInt(document.getElementById('inq_car_id').textContent),
    buyer_id: parseInt(document.getElementById('inq_buyer').value),
    message:  document.getElementById('inq_msg').value.trim(),
  };
  if (!body.message) { alert('메시지를 입력하세요'); return; }
  const r = await fetch('/api/inquiries', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify(body)
  });
  if (r.ok) {
    alert('문의 전송 완료!');
    bootstrap.Modal.getInstance(document.getElementById('inqModal')).hide();
  } else {
    alert('실패: ' + (await r.text()));
  }
}

checkHealth();
loadUsers();
loadCars();
</script>
</body>
</html>
"""

로컬 테스트

source venv/bin/activate
python app.py &

curl -s http://localhost:5000/ | head -20

외부 접근 설정(NSG) + systemd 서비스화

NSG에 5000 포트를 열어 외부 브라우저에서 접근 가능하게 하고, Flask 앱을 systemd 서비스로 등록해 SSH 종료 후에도 동작하게 설정

NSG 규칙 추가 - Flask 5000 포트

로컬 개발 머신(VM이 아닌, 로컬 PC)에서 실행

# 5000 포트 외부 노출
az vm open-port \
  --resource-group $RG \
  --name $VM \
  --port 5000 \
  --priority 1010

# 현재 NSG 규칙 확인
az network nsg rule list \
  --resource-group $RG \
  --nsg-name ${VM}NSG \
  --output table

• 1433 포트는 절대 열지 마세요. SQL Server는 Step 4에서 127.0.0.1 바인딩했지만 NSG도 이중 차단입니다.
• 우선순위(priority) 1010은 SSH 1000과 충돌하지 않도록 100 이상 차이를 둡니다.
• 끝나면 5000도 다시 닫는것 필수

외부 차단 검증

# 외부에서 SQL Server 접속 시도 — 반드시 timeout 발생해야 정상
sqlcmd -S $PUBIP,1433 -U sa -P 'dummy' -C -l 5
# 출력 예: Login timeout expired ... (10 ~ 60초 후)

# 또는 nc(netcat) / Test-NetConnection
# Linux/Mac:
nc -zv $PUBIP 1433
# 결과: "Connection refused" 또는 "timed out" → OK

# Windows PowerShell:
Test-NetConnection -ComputerName $env:PUBIP -Port 1433
# TcpTestSucceeded : False → OK

1433 포트가 외부에서 timeout 또는 refused — 정상. 만약 connect 성공하면 즉시 NSG와 SQL Server bind 설정 재점검.

Flask앱 systemd 서비스 등록

sudo nano /etc/systemd/system/carmarket.service

[Unit]
Description=CarMarket Flask App
After=network.target mssql-server.service
Requires=mssql-server.service

[Service]
Type=simple
User=azureuser
WorkingDirectory=/home/azureuser/carmarket
EnvironmentFile=/home/azureuser/carmarket/.env
ExecStart=/home/azureuser/carmarket/venv/bin/gunicorn \
  --bind 0.0.0.0:5000 \
  --workers 2 \
  --access-logfile - \
  app:app
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

# 서비스 활성화 및 시작
sudo systemctl daemon-reload
sudo systemctl enable carmarket
sudo systemctl start carmarket
sudo systemctl status carmarket --no-pager

Active: active (running) 표시되면 OK. 실패 시 journalctl -u carmarket -n 50 으로 로그 확인.

외부 브라우저로 접속

로컬 PC 브라우저에서 http://<PUBIP>:5000/ 로 접근 (azure portal의 vm 리소스에 기본 NIC 공용 IP 사용)

정리

리소스 삭제하거나, vm의 인바운드 포트 규칙의 5000 삭제

초기에 죄다 azure function(서버리스)로 처리하면 의존성이 증가하여 유지보수가 힘들다 → NOSQL로도 만들수 있지만, RDBMS를 함께 써야 확장성이 좋다.

MySQL을 쓰더라도 온프레미스로 vm(월 100$)에 설치해서 직접 관리하냐 vs 돈 좀 내고 Paas 서비스(Azure Database for MySQL 월 200$) 쓸거냐

Azure Database Engineer Bootcamp 정리

지형도 & 환경 셋업

Azure 데이터 서비스의 전체 그림을 이해하고, 실습 환경을 직접 구축하는 과정이다. 예상 비용은 1인당 약 $0.5로 안내되어 있다.

학습 목표

이번 과정의 학습 목표는 다음과 같다.

선수 지식 확인

DB 역사와 이론

왜 DB 역사를 배우는가?

DB 역사를 배우는 이유는 현재 기술의 장단점이 과거 문제 해결 과정에서 탄생했기 때문이다.

• 현재 기술의 장단점은 과거 문제 해결 과정에서 탄생
• NoSQL은 RDBMS를 “대체”하는 것이 아님
• 워크로드에 맞는 DB 선택 = DBA 핵심 역량
• Azure에 데이터 서비스가 10가지 넘는 이유를 이해하기 위함

계층형 DB → 관계형 DB

1960s 계층형 DB

1970s 네트워크 DB

1970~80s 관계형 DB

계층형·네트워크 DB의 한계

RDBMS가 혁명적이었던 이유는 기존 계층형·네트워크 DB의 한계를 해결했기 때문이다.

• 트리/그래프 구조에서는 데이터 접근 경로를 프로그래머가 직접 코딩해야 했다.
• 스키마 변경 시 애플리케이션 전체 수정이 필요했다.
• 데이터 독립성이 부족했다.
• 물리적 저장 구조와 논리적 구조가 결합되어 있었다.
• 다대다 관계 표현이 복잡했다.
• 이러한 문제들이 Codd의 관계 모델 탄생 배경이 되었다.

SQL의 탄생과 표준화

SQL의 진화

SQL의 선언적 혁신

SQL은 “어떻게 가져올지”가 아니라 “무엇을 가져올지”를 기술한다.

예시:

SELECT name FROM users
WHERE age > 30;

이 경우 사용자는 원하는 결과만 선언하고, 실제 최적 경로는 DB 엔진이 결정한다.

RDBMS 30년 지배

1980년대부터 2000년대까지 RDBMS는 데이터베이스 시장을 지배했다.

• 1980~2000: Oracle, SQL Server, MySQL, PostgreSQL 시장 장악
• ACID 트랜잭션: 금융 · ERP · 재고 시스템의 기반
• SQL 표준화: 어떤 RDBMS든 비슷한 쿼리 사용 가능
• 정규화 이론: 중복 제거, 무결성 보장
  • 예)중복되는 부분을 테이블 분리 후 ID로 관리
• 그러나 2000년대 웹 스케일 문제가 RDBMS의 한계를 드러냄

NoSQL

Not Only SQL

NoSQL 4가지 데이터 모델

NoSQL이 등장한 배경

2000년대 Google과 Amazon이 NoSQL의 길을 열었다.

• 2004: Google BigTable 논문 → Column-Family 모델에 영감

• 2007: Amazon Dynamo 논문 → Key-Value + Eventual Consistency

• 2009: MongoDB, Cassandra, Redis 등 폭발적 등장

• 핵심 동인: 웹 스케일

  • 수십억 사용자
  • 페타바이트 데이터

• RDBMS의 수직 확장 한계

  • 단일 서버 성능에 의존

• 수평 확장 필요

  • Scale-Out
  • 분산 시스템
  • CAP 트레이드오프 발생

실시간으로 기록해야하는 부분(그날 게임점수 신기록) 이런건 NoSQL로 처리하는게 이득

데이터베이스의 종류와 역사

데이터베이스란?

데이터베이스는 구조화된 정보나 데이터의 조직화된 모음이다. 일반적으로 컴퓨터 시스템에 전자적으로 저장된다.

DBMS(Database Management System)는 사용자와 애플리케이션이 데이터베이스와 상호 작용할 수 있게 해주는 소프트웨어이다.

주요 역할

데이터와 정보의 차이

데이터(Data)

데이터는 가공되지 않은 원시 사실이나 관찰 결과를 의미한다. 그 자체로는 특별한 의미가 없는 단순한 숫자, 문자, 이미지 등의 모음이다.

정보(Information)

정보는 데이터를 가공·처리하여 의미를 부여한 결과물이다. 특정 목적을 위해 데이터를 해석하고 조직화한 형태이다.

데이터베이스의 역사 개요

데이터베이스 기술은 1960년대부터 시작되어 컴퓨팅 기술의 발전과 함께 계속 진화해왔다.

초기에는 단순한 파일 시스템으로 데이터를 관리했지만, 시간이 지나면서 계층형 DB, 네트워크형 DB, 관계형 DB, 객체지향 DB, NoSQL, NewSQL, 클라우드 DB까지 발전했다.

이러한 변화는 다음 요인에 의해 가속화되었다.

파일 시스템 시대

파일 시스템 시대 (1세대)

파일 시스템은 초기 데이터 관리 방식이다. 데이터를 데이터베이스가 아니라 파일 단위로 저장하고, 애플리케이션이 직접 파일을 읽고 쓰는 방식이었다.

파일 시스템의 특징

파일 시스템의 한계

이 시기에는 프로그래머가 직접 파일 관리 로직을 구현해야 했다. 따라서 데이터 접근과 관리에 많은 시간과 자원이 소모되었다.

계층형 데이터베이스

계층형 데이터베이스 (2세대)

계층형 데이터베이스는 데이터를 트리 구조로 구성한다. 부모-자식 관계를 중심으로 데이터를 표현하며, 하향식으로 데이터를 탐색한다.

주요 특징

한계점

계층형 데이터베이스는 파일 시스템의 한계를 극복하고 구조화된 데이터 관리를 가능하게 했지만, 복잡한 다대다 관계를 표현하기에는 제한적이었다.

네트워크형 데이터베이스

네트워크형 데이터베이스

네트워크형 데이터베이스는 계층형 모델보다 복잡한 관계를 표현하기 위해 등장했다. 그래프 구조를 사용하며 레코드 간 다대다 관계를 표현할 수 있다.

네트워크형 데이터베이스는 계층형 모델의 제한을 극복했지만, 여전히 데이터 구조와 쿼리가 복잡하다는 한계가 있었다.

관계형 데이터베이스 도입

E.F. Codd의 혁신

1970년 IBM 연구원 에드거 F. 코드(E.F. Codd)는 “A Relational Model of Data for Large Shared Data Banks”라는 논문을 발표했다. 이 논문은 관계형 데이터베이스의 이론적 기반을 마련했다.

주요 혁신점

코드의 관계형 모델은 이전 데이터베이스 패러다임의 복잡성을 극복하고, 직관적이고 유연한 데이터 구조를 제공했다. 이 개념은 현대 데이터베이스 발전의 토대가 되었다.

관계형 DBMS의 발전 (3세대)

관계형 데이터베이스는 표준화된 SQL의 등장과 함께 산업 표준으로 자리 잡았다. 비즈니스 애플리케이션과 공공 시스템에서 널리 채택되었고, 이 시기에 데이터 무결성, 트랜잭션 처리, 백업/복구 등의 핵심 기능이 발전했다.

객체지향 DBMS

객체지향 DBMS (4세대)

1980년대 후반 객체지향 프로그래밍이 인기를 얻으면서 복잡한 데이터 구조를 더 잘 표현할 수 있는 데이터베이스의 필요성이 커졌다.

객체지향 DB의 등장 배경

주요 특징

대표 시스템

객체지향 DBMS는 복잡한 데이터 표현에 강점이 있었지만, 관계형 데이터베이스의 강력한 점유율과 표준화된 SQL의 부재로 인해 주류 시장에서는 제한적인 성공을 거두었다.

객체-관계형 DBMS

객체-관계형 DBMS (5세대)

객체-관계형 DBMS는 관계형 데이터베이스의 테이블 구조와 객체지향 데이터베이스의 유연성을 결합한 하이브리드 모델이다.

하이브리드 접근법

관계형 데이터베이스의 테이블 구조와 객체지향 데이터베이스의 유연성을 결합한다.

확장된 데이터 타입

복잡한 사용자 정의 데이터 타입, 배열, XML, JSON 등 다양한 형식의 데이터를 직접 저장하고 처리할 수 있다.

SQL 확장

객체 조작을 위한 확장된 SQL 구문을 제공하여 복잡한 데이터 구조에 대한 쿼리를 쉽게 한다.

대표 시스템

현대적인 관계형 데이터베이스 대부분은 객체-관계형 기능을 통합하고 있다.

DBMS 역사 총정리

데이터베이스 시스템은 단순 파일 저장에서 시작해 복잡한 데이터 관계와 구조를 표현할 수 있는 형태로 발전했다. 각 세대는 이전 세대의 한계를 극복하고 새로운 요구사항을 충족하기 위해 등장했다.

대표적 관계형 DBMS

Oracle Database

1979년 출시된 엔터프라이즈급 RDBMS이다. 대규모 트랜잭션 처리와 안정성에 강점이 있다.

MySQL

1995년 출시된 오픈소스 RDBMS이다. 웹 애플리케이션과의 뛰어난 호환성과 속도가 특징이다.

Microsoft SQL Server

1989년 출시된 Microsoft의 RDBMS이다. Windows 환경과의 통합성이 뛰어나다.

PostgreSQL

1996년 출시된 고급 오픈소스 RDBMS이다. 확장성과 표준 준수에 강점이 있다.

MySQL과 PostgreSQL 비교

MySQL의 특징

MySQL은 주로 콘텐츠 관리 시스템, 블로그, 웹 애플리케이션에 적합하다.

PostgreSQL의 특징

PostgreSQL은 금융 시스템, 과학 연구, 복잡한 데이터 분석에 적합하다.

오픈소스 DB의 부상

엔터프라이즈 DBMS

Oracle Database

글로벌 금융 기관과 대기업에서 많이 사용되는 엔터프라이즈 DBMS이다.

IBM Db2

대형 메인프레임 환경에서 강점을 가진 엔터프라이즈 데이터베이스이다.

Microsoft SQL Server

Windows 환경에서 강력한 통합 기능을 제공하는 엔터프라이즈 솔루션이다.

NoSQL의 등장

NoSQL의 의미

NoSQL은 Not Only SQL을 의미한다. 전통적인 관계형 데이터베이스의 한계를 넘어서기 위해 등장한 새로운 데이터베이스 패러다임이다.

등장 배경

2000년대 후반 Google의 BigTable과 Amazon의 Dynamo 논문이 발표되면서 NoSQL 움직임이 본격화되었다. 이후 MongoDB, Cassandra, Redis 등 다양한 NoSQL 데이터베이스가 등장하며 새로운 데이터 저장 패러다임을 형성했다.

NoSQL 배경

NoSQL 주요 유형 개관

각 NoSQL 유형은 특정 사용 사례와 데이터 모델에 최적화되어 있다. 관계형 데이터베이스로 해결하기 어려운 특정 문제를 효율적으로 해결할 수 있다. 오늘날 많은 기업은 다양한 워크로드를 위해 여러 유형의 데이터베이스를 함께 사용하는 멀티 모델 접근 방식을 채택하고 있다.

Key-Value DB

작동 원리

Key-Value DB는 단순한 키(key)와 값(value)의 쌍으로 데이터를 저장하는 가장 기본적인 NoSQL 데이터베이스이다.

주요 특징

대표적 시스템

주요 활용 분야

Document DB

작동 원리

Document DB는 JSON, BSON 또는 XML과 같은 반구조화된 형식의 문서로 데이터를 저장한다. 각 문서는 자체적으로 완결된 정보를 포함하며, 다양한 필드와 중첩 구조를 가질 수 있다.

예시 문서

{
  "id": "user123",
  "name": "홍길동",
  "email": "hong@example.com",
  "orders": [
    { "id": "ord1", "date": "2023-01-15" },
    { "id": "ord2", "date": "2023-02-20" }
  ]
}

주요 특징

대표 시스템 및 활용

주요 활용 분야는 웹 애플리케이션, 콘텐츠 관리 시스템, 카탈로그, 사용자 프로필 관리 등이다.

컬럼형 데이터베이스

작동 원리

컬럼형 데이터베이스는 데이터를 행이 아닌 컬럼 단위로 저장한다. 관련 컬럼들은 컬럼 패밀리로 그룹화된다. 분석 쿼리에서 필요한 컬럼만 효율적으로 읽을 수 있다는 장점이 있다.

주요 특징

대표 시스템

주요 활용 분야

그래프 DB

그래프 DB는 실제 세계의 연결 구조를 노드와 관계로 모델링한다.

대표 시스템

주요 활용 분야

NewSQL의 출현

NewSQL은 전통적인 관계형 데이터베이스의 강점과 NoSQL의 확장성을 결합한 데이터베이스이다.

주요 특징

대표 시스템

NewSQL은 미션 크리티컬한 트랜잭션 처리와 대규모 데이터 처리를 동시에 요구하는 현대적 애플리케이션에 적합하다.

인메모리 DBMS

기본 개념

인메모리 DBMS는 주로 디스크가 아닌 메인 메모리(RAM)에 데이터를 저장하고 처리하는 데이터베이스 시스템이다. 디스크 I/O 병목을 제거하여 매우 빠른 처리 속도를 제공한다.

주요 특징

대표 시스템

주요 활용 분야

데이터베이스의 활용 변화

데이터베이스의 활용 영역은 단순 트랜잭션 처리에서 실시간 분석, AI 기반 의사결정, 엣지 컴퓨팅까지 확장되고 있다.

현대 애플리케이션은 다양한 데이터 유형과 워크로드를 처리할 수 있는 다기능 데이터 플랫폼을 요구한다.

데이터베이스와 클라우드

클라우드 전환의 배경

기업들은 자체 데이터센터에서 데이터베이스를 운영·유지보수하는 대신, 클라우드 제공업체가 관리하는 서비스형 데이터베이스(DBaaS)로 전환하고 있다.

주요 이점

주요 클라우드 제공업체

2023년 기준 새로 배포되는 데이터베이스의 75% 이상이 클라우드 환경에서 구축되고 있으며, 이 비율은 계속 증가할 전망이라고 설명한다.

클라우드 DBMS 개요

관리형 서비스

패치, 백업, 확장, 고가용성 설정 등 데이터베이스 관리 작업을 클라우드 제공업체가 자동으로 처리한다.

탄력적 확장성

필요에 따라 컴퓨팅 및 스토리지 리소스를 자동으로 확장하거나 축소하여 비용을 최적화할 수 있다.

서버리스 옵션

사용한 만큼만 비용을 지불하는 서버리스 데이터베이스 옵션을 통해 인프라 관리 부담을 제거한다.

멀티 모델 지원

하나의 서비스에서 관계형, 문서, 그래프 등 다양한 데이터 모델을 지원하여 애플리케이션 개발을 단순화한다.

글로벌 분산

전 세계 데이터 센터에 데이터를 자동으로 복제하여 지연 시간을 줄이고 데이터 주권 준수를 지원한다.

서비스 통합

분석, 머신러닝, IoT 등 다른 클라우드 서비스와 통합하여 데이터 활용 가치를 높인다.

AWS의 주요 DB 서비스

Amazon RDS

관리형 관계형 데이터베이스 서비스이다. MySQL, PostgreSQL, Oracle, SQL Server, MariaDB 등 다양한 엔진을 지원한다.

Amazon DynamoDB

완전 관리형 NoSQL 데이터베이스 서비스이다. 무제한 확장성과 밀리초 단위 성능을 제공한다.

Amazon Aurora

MySQL 및 PostgreSQL과 호환되는 클라우드 네이티브 관계형 데이터베이스이다. 기존 엔진보다 최대 5배 빠른 성능을 제공한다고 설명한다.

기타 AWS DB 서비스

Google Cloud DB 서비스

Cloud Spanner

글로벌 분산 트랜잭션을 지원하는 수평적 확장 관계형 데이터베이스이다. 강력한 일관성과 99.999% 가용성을 제공한다.

Cloud Bigtable

대규모 분석 및 운영 워크로드를 위한 완전 관리형 NoSQL 데이터베이스 서비스이다.

Cloud SQL

MySQL, PostgreSQL, SQL Server를 위한 완전 관리형 관계형 데이터베이스 서비스이다.

BigQuery

서버리스 엔터프라이즈 데이터 웨어하우스이다. 페타바이트 규모의 데이터를 실시간으로 분석할 수 있다.

기타 Google Cloud DB 서비스

Microsoft Azure DB 서비스

Azure SQL Database

Microsoft SQL Server 기반의 완전 관리형 관계형 데이터베이스 서비스이다.

Azure Cosmos DB

글로벌 분산 멀티 모델 데이터베이스 서비스이다. 다양한 데이터 모델과 API를 지원한다.

Azure Database for MySQL/PostgreSQL

오픈소스 데이터베이스를 위한 완전 관리형 서비스이다.

기타 Azure DB 서비스

클라우드 DBMS 특징

무중단 백업 및 복구

자동화된 백업 시스템과 시점 복구(Point-in-Time Recovery)를 통해 데이터 손실 위험을 최소화한다. 백업 작업이 성능에 영향을 미치지 않으며 재해 복구 계획도 쉽게 구현할 수 있다.

자동 확장 및 성능 최적화

워크로드 증가에 따라 리소스를 자동 확장하고, AI 기반 성능 모니터링과 최적화 도구로 데이터베이스 성능을 지속적으로 개선한다.

제공 기능:

향상된 보안 및 규정 준수

저장 및 전송 중 암호화, 세밀한 접근 제어, 위협 감지 등 다양한 보안 기능이 기본 제공된다.

지원하는 규정 준수 예시:

고가용성 및 재해 복구

다중 가용 영역 및 지역 복제, 자동 장애 조치(failover), 상시 가동 아키텍처 등을 통해 최대 99.999%의 가용성을 보장한다. 자연재해나 지역 장애에도 서비스 연속성을 유지할 수 있다.

온프레미스 DB vs 클라우드 DB

온프레미스 데이터베이스

장점

단점

클라우드 데이터베이스

장점

단점

많은 기업은 두 접근 방식의 장점을 결합한 하이브리드 방식을 채택하고 있다. 워크로드 특성과 비즈니스 요구사항에 따라 최적의 배포 모델을 선택한다.

멀티 클라우드·하이브리드 DB

멀티 클라우드 전략

멀티 클라우드는 여러 클라우드 제공업체의 데이터베이스 서비스를 동시에 활용하는 접근 방식이다.

장점

단점

하이브리드 데이터베이스 환경

하이브리드 데이터베이스 환경은 온프레미스와 클라우드 데이터베이스를 함께 운영하는 방식이다.

장점

주요 과제

최근에는 Kubernetes 기반 데이터베이스 운영과 같은 컨테이너화된 접근 방식이 등장하여 환경 간 이식성을 높이고 있다. 데이터베이스 가상화 및 추상화 레이어를 통해 복잡성을 관리하는 솔루션도 발전하고 있다.

DBMS 발전의 핵심 트렌드

오픈소스 확산

엔터프라이즈 영역에서도 오픈소스 데이터베이스 채택이 급증하고 있다.

클라우드 전환 가속

기업들이 자체 데이터센터에서 클라우드 환경으로 데이터베이스를 이전하는 추세가 가속화되고 있다.

다양한 데이터 포맷 지원

정형 데이터 외에도 다양한 비정형/반정형 데이터를 처리할 수 있는 능력이 중요해지고 있다.

데이터베이스 선택 기준

용도 파악

트랜잭션 처리(OLTP), 분석(OLAP), 혼합(HTAP) 중 어떤 워크로드인지 파악해야 한다.

데이터 특성

정형 데이터인지 비정형 데이터인지, 데이터 크기와 성장률은 어느 정도인지, 관계 복잡성은 어떤지 고려해야 한다.

확장성 요구

예상 사용자 수, 트래픽 패턴, 수직/수평 확장 필요성을 고려해야 한다.

일관성 vs 가용성 요구사항

CAP 이론에 따라 강한 일관성(CP)이 중요한지, 가용성과 파티션 허용(AP)이 중요한지 고려해야 한다.

예를 들어 금융 거래는 강한 일관성이 필요하지만, 소셜 미디어는 일시적 불일치를 허용할 수 있다.

쿼리 패턴 및 성능 요구사항

복잡한 조인이 필요한지, 단순 키-값 검색이 중심인지, 실시간 응답이 필요한지에 따라 적합한 DB가 달라진다.

명확히 정의해야 할 성능 지표:

기술 생태계 및 개발자 역량

팀의 기존 기술 스택과 호환되는지, 개발자가 얼마나 익숙한지, 커뮤니티 지원과 도구 생태계가 충분한지 고려해야 한다.

좋은 데이터베이스라도 팀이 효과적으로 활용할 수 없다면 가치가 제한된다.

주요 DBMS 비교 표

각 데이터베이스 유형은 고유한 강점과 약점을 가지고 있으며, 특정 워크로드와 사용 사례에 최적화되어 있다.

많은 현대 애플리케이션은 다양한 유형의 데이터베이스를 함께 사용하는 폴리글랏 퍼시스턴스(Polyglot Persistence) 접근 방식을 채택하고 있다.

미래의 데이터베이스 전망

AI 기반 자율 데이터베이스

인공지능이 자동으로 데이터베이스를 튜닝, 최적화, 관리하는 시스템이 확산되고 있다.

자동화되는 영역:

DBA의 역할도 단순 운영보다 전략적 방향으로 진화하고 있다.

서버리스 데이터베이스의 확산

인프라 관리 없이 필요한 만큼만 사용하고 비용을 지불하는 서버리스 DB가 주류화될 전망이다. 개발자는 데이터베이스 운영보다 비즈니스 로직과 애플리케이션 개발에 집중할 수 있다.

엣지 컴퓨팅과 분산 데이터베이스

IoT 장치와 5G 네트워크 확산으로 데이터 생성 지점에 가까운 엣지 위치에서 데이터를 처리하는 분산 데이터베이스 시스템이 중요해질 것이다.

핵심 과제는 중앙 클라우드와 엣지 노드 간의 효율적인 데이터 동기화이다.

데이터베이스와 AI의 통합

데이터베이스 시스템 내에서 직접 머신러닝 모델을 실행하고 학습하는 기능이 강화될 것이다.

데이터 이동 없이 데이터베이스 내부에서 분석과 예측을 수행하는 AI in DB 개념이 발전할 것이다.

블록체인 기반 분산 데이터베이스

높은 투명성과 변조 방지가 필요한 애플리케이션을 위한 블록체인 기반 데이터베이스 시스템이 발전할 것이다.

중요성이 증가할 산업:

결론: 데이터베이스의 진화 방향

다종 복합 DB 환경 도래

단일 데이터베이스 시스템으로 모든 요구사항을 충족하는 시대는 지나고 있다. 현대적인 데이터 아키텍처는 다양한 유형의 데이터베이스를 목적에 맞게 조합하는 방향으로 진화하고 있다.

데이터 활용 방식의 변화

데이터베이스는 단순한 저장소를 넘어 비즈니스 가치 창출의 핵심 도구로 진화하고 있다.

데이터베이스 기술은 60년이 넘는 역사 동안 계속 진화해왔다. 앞으로도 클라우드, AI, IoT 등의 기술과 융합하며 발전할 것이다.

이러한 변화에 맞춰 데이터 전략을 수립하고 적응하는 조직이 디지털 시대의 경쟁에서 우위를 점할 수 있다.

참고 자료

DBMS 선택 실전 사례

다양한 산업 분야에서 비즈니스 요구사항에 따라 데이터베이스를 선택한 실제 사례를 살펴볼 수 있다.

NewSQL과 Vector DB

NewSQL

NewSQL은 ACID와 수평 확장을 동시에 목표로 한다.

Vector DB

Vector DB는 AI/ML 임베딩 검색에 사용된다.

ACID 트랜잭션

ACID는 관계형 DB의 핵심 보장이다.

CAP 정리

CAP는 분산 시스템에서 중요한 세 가지 특성이다.

세가지를 모두 동시에 만족할 순 없다.(동시에 두개까지만 가능)

CAP 실무 적용 — 서비스별 선택

BASE 특성

BASE는 NoSQL에서 많이 사용하는 유연한 일관성 모델이다.

ACID vs BASE 비교

DB 진화 요약

60년의 DB 진화를 한 장으로 요약하면 다음과 같다.

핵심 메시지는 다음과 같다.

정답은 없다. 워크로드에 맞는 선택이 최선이다.

이 원칙이 이후 전체 과정의 판단 기준이 된다.

Azure 데이터 서비스 지형도

Azure 데이터 서비스 전체 맵

Azure에서 선택할 수 있는 데이터 서비스는 크게 네 영역으로 나눌 수 있다.

SQL VM vs SQL DB vs SQL MI

Cosmos DB 개요

Cosmos DB는 글로벌 분산 NoSQL 서비스이다.

• 글로벌 분산 NoSQL
• 60개 이상 Azure 리전 지원
• 10ms 미만 읽기/쓰기
• 5가지 일관성 수준
• 5가지 API
• 상세 실습은 Day 6에서 진행 예정

OSS PaaS + 분석 서비스

의사결정 트리 — 5개 질문

Azure 데이터 서비스를 선택할 때 다음 질문을 기준으로 판단한다.

워크샵: 시나리오별 서비스 선택

환경 셋업 실습

Azure 구독부터 Budget Alert까지 직접 구축한다.

워크샵 가이드: 의사결정 트리 실습

목표는 3개 시나리오에 대해 2~3인 조별 토론 후 서비스 선택 결과를 발표하는 것이다.

실습 1: 구독 · 리소스 그룹 생성

부트캠프 전용 리소스 그룹을 생성한다.

# Cloud Shell: Portal 상단 >_ 아이콘

# 구독 확인
az account show --output table

# 리소스 그룹 생성
az group create \
--name rg-bootcamp-day1 \
--location koreacentral \
--tags "project=bootcamp" "owner=<이름>"

# 확인
az group show --name rg-bootcamp-day1 -o table

실습 2: VNet · NSG

부트캠프 전 과정에서 사용할 VNet과 NSG를 생성한다.

# VNet 생성
az network vnet create \
-g rg-bootcamp-day1 \
--name vnet-bootcamp \
--address-prefix 10.0.0.0/16 \
--subnet-name snet-default \
--subnet-prefix 10.0.1.0/24

# NSG 생성 + SSH 규칙
az network nsg create \
-g rg-bootcamp-day1 -n nsg-bootcamp

az network nsg rule create \
-g rg-bootcamp-day1 --nsg-name nsg-bootcamp \
-n AllowSSH --priority 1000 \
--destination-port-ranges 22 \
--access Allow --protocol Tcp --direction Inbound

VNet과 NSG 기본 개념

VNet (가상 네트워크)

VNet은 Azure 내 프라이빗 네트워크이다.

NSG (네트워크 보안 그룹)

NSG는 방화벽 규칙 집합이다.

실습 3: Cloud Shell 환경

목표는 CLI 환경을 확인하고 기본 명령을 연습하는 것이다.

실습 4: Budget Alert 설정

목표는 비용 한도 초과를 사전에 감지하는 것이다.

리소스 정리 스크립트

Day 1은 VM이 없으므로 모든 리소스를 유지한다.

유지 리소스는 다음과 같다.

확인 명령:

# Day 1은 VM 없음 — 모두 유지

# 유지 리소스:
# rg-bootcamp-day1
# vnet-bootcamp
# nsg-bootcamp
# bootcamp-budget

# 확인만:
az resource list -g rg-bootcamp-day1 -o table

# Cost Analysis에서 비용 확인: $0.5 이하

Day 1 리소스 정리 + 체크리스트

# Day 1 체크리스트
az resource list -g rg-bootcamp-day1 -o table

정리 체크리스트는 다음과 같다.

Day 1 예상 비용: $0.5 한도: $10/일

비용 관리 — 9일 전체 전략

이 습관이 9일간의 비용을 결정한다.

Q&A

정리

핵심 요약

이번 과정은 단순히 Azure 리소스를 만드는 실습이 아니라, 데이터베이스가 왜 지금과 같은 형태로 발전했는지 이해하고, 워크로드에 따라 적절한 Azure 데이터 서비스를 선택하기 위한 기준을 세우는 과정이다.

핵심은 다음과 같다.

• RDBMS는 데이터 독립성과 ACID를 기반으로 발전했다.
• NoSQL은 웹 스케일과 수평 확장 문제를 해결하기 위해 등장했다.
• NewSQL은 ACID와 Scale-Out을 동시에 추구한다.
• Vector DB는 AI/ML 시대의 검색 인프라로 중요해졌다.
• Azure에서는 SQL VM, SQL DB, SQL MI, Cosmos DB, Flexible Server, ADX, Fabric 등 다양한 선택지가 있다.
• 정답은 하나가 아니라, 워크로드에 맞는 선택이 최선이다.
• 실습 환경은 RG, VNet, NSG, Budget Alert를 기준으로 구성한다.
• 비용 관리는 매일 Cost Analysis 확인과 VM deallocate가 핵심이다.

Azure의 대표 컨셉은 Microsoft Entra ID이다(AAD)

Azure SQL Database 실습

Lab 1 – Lab 환경 구축

Bastion은 가상 네트워크 생성시 선택 가능

Portal에서 Azure SQL 찾기

Azure Portal 상단 검색창에서 Azure SQL을 검색하면 Azure SQL과 관련된 서비스 목록이 표시된다.

이 화면에서는 다음과 같은 리소스를 확인할 수 있다.

• Azure SQL Database
• Azure SQL Managed Instance
• SQL Server on Azure VM

Azure SQL 선택을 위한 질문

Azure SQL 선택 화면에서는 사용자의 요구사항을 기반으로 적절한 서비스를 추천하기 위해 질문을 제공한다.

이 질문들은 다음과 같은 기준을 포함한다.

• 어떤 유형의 워크로드인가
• 기존 시스템을 마이그레이션하는가
• 새로운 애플리케이션인가

Azure SQL 선택 의사 결정 트리

Azure로 Database 마이그레이션

Azure에서는 데이터베이스 마이그레이션을 쉽게 하기 위한 도구를 제공한다.

마이그레이션 시작 화면에서 다음 옵션을 확인할 수 있다.

• Azure Database Migration Service
• Azure Arc enabled SQL Server
• Azure Migrate

데이터베이스를 Azure로 이전하기 위한 방법

Azure에서 제공하는 마이그레이션 방법은 다음과 같다.

• 다양한 DB → Azure 이전 → Azure Database Migration Service

• SQL Server → Azure 이전 → Azure Arc enabled SQL Server

• 앱 + DB 전체 이전 → Azure Migrate

Azure SQL Database 만들기

https://learn.microsoft.com/ko-kr/azure/private-link/tutorial-private-endpoint-sql-portal

워크로드 환경 및 백업 스토리지 설정

다음과 같이 설정한다.

• SQL Elastic Pool: 사용 안 함
• 워크로드 환경: 개발
• 백업 스토리지: 로컬 중복

컴퓨팅 요소 설정

컴퓨팅 계층 및 하드웨어를 설정한다.

• 서비스 계층: 범용
• 컴퓨팅 계층: 프로비전됨
• 하드웨어: Gen5

👉 이후 Serverless와 비교 목적

네트워크 설정

데이터베이스 접근을 위한 네트워크 설정을 수행한다.

• 연결 방법: 퍼블릭 엔드포인트
• 방화벽: 현재 IP 추가
• 연결 정책: 기본값
• TLS: 1.2

보안 설정

기본 제공 옵션을 그대로 유지한다.

추가 설정

기존 데이터 사용에서 👉 샘플 선택 (AdventureWorks)

생성

“만들기”를 선택하면 배포가 진행된다.

• 소요 시간: 약 1~2분

DB 확인 및 쿼리 실행

DB 확인

쿼리 편집기를 통해 생성된 DB를 확인한다.

• SQL Server 인증 방식 사용

쿼리 실행

SELECT TOP 20 pc.Name as CategoryName, p.name as ProductName
FROM SalesLT.ProductCategory pc
JOIN SalesLT.Product p
ON pc.productcategoryid = p.productcategoryid;

쿼리 실행 결과를 통해 데이터 확인 가능

SSMS 설치

SSMS 설치 가이드를 통해 설치 진행 연결시 Microsoft Entra 인증으로 생성했다면 Microsoft Entra 암호 입력 후 인증서 신뢰를 체크하면 연결됨

데이터베이스 복구

삭제 유형별 비교

방화벽 확인

Azure SQL Database에서 현재 IP 확인 후 방화벽 등록

Virtual Network 생성

Bastion

virtual machine

bastion을 통해야하므로 공용 인바운드 포트 X

sql db 프라이빗 엔드포인트

연결

vm-bastion으로 연결-ssh 로컬 파일로 접속(azureuser)

SQL Server 도구 설치

https://learn.microsoft.com/ko-kr/sql/linux/sql-server-linux-setup-tools?view=sql-server-ver17&tabs=redhat-install%2Codbc-ubuntu-1804

sudo su
curl -sSL -O https://packages.microsoft.com/config/ubuntu/24.04/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
exit

sudo apt-get update
sudo apt-get install mssql-tools18 unixodbc-dev

sudo apt-get update
sudo apt-get install mssql-tools18

echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> ~/.bash_profile
source ~/.bash_profile

echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> ~/.bashrc
source ~/.bashrc

Managed Instance 생성

설정

• Public endpoint 사용
• 포트 3342 오픈
• NSG에서 IP 허용

SSMS 연결

• Endpoint 복사
• Server name 입력
• Connect

Lab 2 – 데이터 복원 및 관리

데이터 적재

AdventureWorks2022.bak 다운로드 후 Blob Storage에 업로드

Blob Storage 구성

• Storage Account 생성
• Container 생성
• 파일 업로드

SAS 생성

SAS는 다음 역할 수행

• 제한된 시간 동안 접근 허용
• 권한 제어 가능
• URL 기반 인증

Managed Instance에서 복원

• SSMS → Restore Database
• Blob URL + SAS 사용

SQL Database vs Managed Instance

구조 차이

MI는 Lift & Shift에 적합

.bacpac vs .bak 비교

.bak은 완벽한 시점 복원용 백업/복구 파일이고, .bacpac은 클라우드 이전 및 버전 업/다운그레이드용 마이그레이션 파일이다.

.bak의 장점

1. 완벽한 데이터 일관성

.bak 파일은 특정 시점의 데이터베이스를 그대로 저장한 Point-in-time 스냅샷이다. 백업 도중 데이터가 변경되더라도 트랜잭션 로그를 함께 포함하기 때문에 데이터 무결성이 보장된다.

즉, 운영 중인 DB를 백업하더라도 “백업 시점 기준으로 데이터가 깨지지 않은 상태”를 유지할 수 있다.

2. 압도적인 속도와 성능

.bak은 데이터베이스의 물리적 페이지 단위 블록을 통째로 백업한다. 그래서 대용량 데이터베이스에서는 .bacpac보다 백업/복원 속도가 훨씬 유리하다.

특히 수백 GB~TB 단위 DB에서는 .bak 방식이 사실상 필수에 가깝다.

3. 시스템 부하가 비교적 작음

.bak 백업은 SQL Server 엔진의 기본 백업 기능을 사용한다. 그래서 운영 중인 서버에서 백업을 수행해도 비교적 안정적으로 동작하고, 시스템 부하도 상대적으로 적다.

.bacpac의 장점

1. 버전 호환성과 이식성

.bacpac은 데이터베이스의 물리 구조를 그대로 복사하는 것이 아니라, 테이블 구조와 데이터를 논리적으로 추출한 파일이다.

그래서 SQL Server 버전에 덜 종속된다. 예를 들어 SQL Server 2022에서 만든 .bak은 SQL Server 2019로 복원할 수 없지만, .bacpac은 구조와 데이터를 추출한 형태이기 때문에 하위 버전으로 이동할 수 있다.

2. Azure SQL Database 이전에 적합

Azure SQL Database는 사용자에게 파일 시스템 접근 권한을 제공하지 않는다. 그래서 SQL Server의 물리 백업 파일인 .bak을 직접 복원할 수 없다.

반면 .bacpac은 스키마와 데이터만 담은 논리적 아카이브이기 때문에 Azure SQL Database로 가져올 수 있다.

즉,

• Azure SQL Managed Instance → .bak 복원 가능
• Azure SQL Database → .bacpac 가져오기 사용

3. 파일 크기가 작음

.bacpac은 트랜잭션 로그나 여유 디스크 공간을 포함하지 않는다. 순수하게 구조와 데이터만 추출해서 압축하기 때문에 .bak보다 파일 크기가 훨씬 작아질 수 있다.

자료 예시에서는 4.3GB .bak 파일이 197MB .bacpac 파일로 줄어들 수 있음을 설명한다.

정리

한 줄로 정리하면, .bak은 “복구용”, .bacpac은 “이전용”에 가깝다.

Database Watcher

클라우드 비교

Azure SQL 개요

Azure SQL은 Azure 클라우드에서 SQL Server 데이터베이스 엔진을 사용하는 관리형, 보안 및 인텔리전트 제품군이다. SQL Server 엔진 기반이기 때문에 기존 애플리케이션을 비교적 쉽게 마이그레이션할 수 있고, 익숙한 도구와 언어, 리소스를 계속 사용할 수 있다.

Azure SQL 제품군은 크게 세 가지로 나뉜다.

리프트 앤 시프트는 주로 IaaS 환경에서 많이 한다.

Azure SQL 포트폴리오 비교

Azure SQL은 SQL Server 엔진을 기반으로 구축된 통합 SQL 포트폴리오이다. 서비스 선택은 관리 책임, 호환성, 제어 수준에 따라 달라진다.

리호스팅은 IT 시스템 마이그레이션에서 대표적으로 사용되는 방식으로, 기존 시스템을 큰 변경 없이 다른 환경으로 이전하는 방법이다.(센터 이전도 가능)

신기능은 Azure Virtual Machines 외의 2종류 정도에만 잘 들어간다.

Versionless Database 엔진과 호환성

Azure VM 위의 SQL은 선택한 특정 SQL Server 버전에 묶여 있다. 반면 Azure SQL Database와 Azure SQL Managed Instance는 PaaS 특성상 특정 버전에 종속되지 않는다. 특히 Always-up-to-date 업데이트 정책을 사용하면 최신 클라우드 기능을 빠르게 반영할 수 있다.

핵심은 SQL Server, Azure SQL Database, Managed Instance가 하나의 공통 코드베이스를 기반으로 최신 엔진 기능을 제공한다는 점이다. SQL Server 버전은 몇 년 단위로 출시되지만, PaaS 서비스는 지속적으로 엔진이 업데이트된다. 이 구조 덕분에 OS 및 SQL Server 패치 부담이 줄어든다.

Azure SQL 서비스 비교

Azure SQL 서비스는 Bare Metal부터 PaaS까지 다양한 형태로 SQL Server를 사용할 수 있게 한다. (Bare Metal은 가상화 없이 사용하는 것) Private Cloud는 자체적으로 구축한 클라우드 환경

Azure SQL 결정 트리

Azure SQL 결정 트리는 신규 앱인지, 기존 DB 마이그레이션인지, OS 접근이 필요한지, SQL Server 호환성이 어느 정도 필요한지에 따라 서비스를 선택하도록 돕는다.

• 신규 클라우드 앱이면 Azure SQL Database가 우선 고려된다.
• 기존 SQL Server 앱을 마이그레이션하고 호환성이 중요하면 Managed Instance가 적합하다.
• OS 수준 접근, 특정 SQL Server 기능, 완전한 제어가 필요하면 SQL Server on Azure VM이 적합하다.
• 대규모 확장, 서버리스, 하이퍼스케일 요구가 있으면 Azure SQL Database의 Hyperscale 또는 Serverless 옵션을 고려한다.

Azure SQL DB 내부 구조: Control Ring vs Data Ring

Azure SQL은 단일 서버가 아니라 Control Ring과 Data Ring으로 나뉜 분산 시스템이다. Control Ring은 라우팅을 담당하고, Data Ring은 실제 연산을 수행한다. 백엔드 노드에 장애가 발생해도 Control Ring이 정상 노드로 트래픽을 우회하여 연결 단절을 최소화한다.

연결 토폴로지: Proxy vs Redirect

Azure SQL은 성능과 네트워크 보안 요구에 따라 Proxy와 Redirect 방식의 연결 토폴로지를 제공한다.

Azure SQL 주요 기능

Azure SQL은 안전하고 안정적인 운영을 위해 다양한 기능을 제공한다.

구매 모델 및 스케일링 전략

Azure SQL 배포 옵션

Azure SQL은 다양한 워크로드 요구 사항에 맞게 여러 배포 옵션을 제공한다.

SQL virtual machines는 SQL Server와 OS를 직접 접근하고 관리할 수 있다. Managed Instance는 SQL Server surface area 대부분을 지원하면서도 완전 관리형 서비스이다. Database는 Hyperscale, Serverless, Elastic Pool 등을 통해 최신 앱에 적합한 운영 방식을 제공한다. Elastic이라는 단어가 들어갔다면 확장성에 집중한 모델임을 알 수 있다.

DTU vs vCore 모델

Azure SQL Database는 DTU 기반 구매 모델과 vCore 기반 구매 모델을 제공한다. vCore 기반 모델이 권장된다.

DTU는 단순하고 미리 구성된 리소스 옵션을 제공하는 반면, vCore는 CPU와 스토리지 등 리소스를 더 투명하게 선택할 수 있다.

Provisioned vs Serverless 설계 및 Auto-pause

워크로드 패턴에 따라 고정 리소스 방식과 자동 스케일링 방식을 선택할 수 있다.

Scalability

Azure SQL 서비스 유형별 확장 방식과 특징은 다르다.

Elastic Database 풀

Elastic Database Pool은 여러 데이터베이스 또는 인스턴스 간에 리소스를 공유하고 비용을 최적화하는 기능이다.

Paychex 사례에서는 여러 고객의 시간 및 결제 관리를 개별 DB로 운영하면서도 비용 절감을 위해 SQL Database Elastic Pool을 선택했다.

하이퍼스케일 모델: 지역 중복 가용성

하이퍼스케일 모델은 기존 로컬/공유 스토리지 모델과 달리 컴퓨트와 스토리지 계층을 완전히 분리한다. 이로 인해 대용량 데이터, 빠른 확장성, 효율적 장애 복구를 제공한다.

하이퍼스케일 모델의 특징은 다음과 같다.

• 컴퓨트와 스토리지가 완전히 분리된다.
• 여러 컴퓨트와 여러 스토리지 구성 요소가 독립적으로 확장된다.
• 노드 장애 시 다른 컴퓨트 노드에서 서비스를 재개할 수 있다.
• 수십 TB급 대용량 데이터베이스에 적합하다.
• 새 복제본 또는 스냅샷을 빠르게 생성할 수 있다.

하이퍼스케일 모델: 영역간 중복 가용성

영역 중복성을 선택하면 하이퍼스케일 계층 전체에 대해 가용성 영역 간 복제가 적용되어 영역 수준 복원력이 보장된다.

• 애플리케이션 로직 변경 없이 엔터프라이즈급 내결함성 구성 가능
• 한 가용성 영역 장애 시 실시간 자동 failover 지원
• 데이터 손실 없는 고가용성 보장
• 서비스 중단 없이 패치 및 업그레이드 가능
• 대용량 확장성과 빠른 복구 제공

네트워크 보안

방화벽 규칙: 서버 수준 vs DB 수준

Azure SQL 방화벽은 서버 수준과 데이터베이스 수준 두 겹으로 동작한다. 최소 권한 원칙에 따라 특정 DB에만 접근을 허용하는 데이터베이스 수준 방화벽 규칙이 권장된다.

규칙 평가 순서는 데이터베이스 수준 규칙이 먼저이며, 매칭되면 해당 DB만 접속된다. 데이터베이스 수준 규칙이 없으면 서버 수준 규칙을 확인하고, 둘 다 없으면 접속이 차단된다.

VNet Service Endpoint vs Private Link

PaaS 데이터베이스를 퍼블릭 인터넷에서 격리하고 회사 내부망과 연동하는 방식은 서비스에 따라 다르다. 온프레미스라면 VNet Injection이 적합(다만 전용인 VNet Injection이 더 비쌈)

각각 공용, 전용 | 구분 | Azure SQL Database: Private Link | SQL Managed Instance: VNet Injection | |---|---|---| | 방식 | 프라이빗 엔드포인트 사용 | 가상 네트워크 주입 방식 | | 구조 | 기존 VNet 변경 불필요, 개별 DB 단위 사설 IP 매핑 | MI 전용 서브넷 필수 | | 인프라 | 외부 PaaS 인프라 유지 | 내 VNet 안에 서버를 통째로 넣는 구조 | | 장점 | 개별 DB 단위로 안전하게 사설 접근 가능 | 완벽한 양방향 통신, 온프레미스 VPN 연동, 물리적 격리에 가까운 수준 |

데이터베이스 보안 및 관리

데이터 암호화 및 접근 제어

Azure SQL은 TDE, Always Encrypted, RLS, DDM 등 다계층 데이터 보호를 제공한다.

Microsoft Entra ID 및 비밀번호 없는 연결

Azure SQL은 SQL Server 인증 대신 Microsoft Entra ID 기반 토큰 인증을 지원한다. 이를 통해 소스코드에서 비밀번호를 제거할 수 있다.

Azure SQL Ledger

Azure SQL Ledger는 블록체인의 SHA-256 해시 기술을 관계형 데이터베이스 엔진에 탑재하여 데이터 위변조를 탐지할 수 있도록 하는 기능이다.

성능 모니터링 및 최적화

Built-in monitoring and intelligence

Azure SQL은 여러 도구를 통해 모니터링과 성능 분석을 제공한다.

대기 통계 Wait Stats 분석 방법

Wait Stats는 쿼리가 실행되는 동안 어떤 자원을 기다리느라 시간이 소요되었는지 알려주는 성능 트러블슈팅 핵심 지표이다.

Automatic tuning 및 지능형 인사이트

PaaS 서비스인 Azure SQL Database와 Managed Instance는 AI 기반 자동/추천 성능 최적화 기능을 제공한다. VM 기반 SQL은 운영자가 직접 튜닝해야 한다.

고가용성 아키텍처 및 재해 복구

High Availability

Azure SQL의 고가용성 내부 구현은 서비스 계층에 따라 다르다.

Availability Architectural Models

Azure SQL Database와 SQL Managed Instance는 각각 고유한 고가용성 아키텍처 모델을 제공한다.

Azure SQL Database 가용성 모델

Azure SQL Managed Instance 가용성 모델

원격 스토리지 모델: 지역 중복 가용성

DTU 기반 Basic/Standard 계층과 vCore 기반 General Purpose 계층은 Remote Storage 가용성 모델을 사용한다. 컴퓨팅 레이어와 저장소 계층이 분리되어 있다.

Stateful한건 늘리거나 하지 않고, Stateless에 computing 가능한 부분을 두어 늘릴 수 있게 함. 예를 들자면, 홈쇼핑 데이터베이스라면 주 기능에 관한건 Stateful한 부분에, 그리고 접속이나 계산 등 computing하고 가변적으로 늘려야 하는 부분은 Stateless 사용

로컬 스토리지 모델: 지역 중복 가용성

DTU Premium 계층과 vCore Business Critical 계층은 컴퓨팅 리소스와 로컬 SSD 스토리지를 단일 노드에 통합하는 로컬 스토리지 모델을 사용한다.

• 각 컴퓨트 노드에는 데이터베이스 엔진과 로컬 SSD가 결합되어 있다.
• 주요 데이터 파일과 로그 파일이 각 노드의 로컬 SSD에 저장된다.
• Always On Availability Group을 통해 노드 간 동기화 복제를 수행한다.
• 로컬 SSD 직접 접근으로 IO 지연이 낮고 성능이 높다.
• 장애 발생 시 동기화된 Secondary 노드가 Primary로 승격된다.

로컬이 더 비싸고 빠름

원격 스토리지 모델: 영역간 중복 가용성

Zone-redundant 옵션을 사용하면 하나의 Region 내 서로 다른 가용성 영역에 컴퓨트 노드가 분산 배치된다.

로컬 스토리지 모델: 영역간 중복 가용성

Premium 또는 Business Critical 계층에서 영역 중복을 사용하면 복제본이 동일 지역의 여러 가용성 영역에 배치된다.

• SPOF 제거를 위해 Control Ring이 여러 영역에 걸쳐 복제된다.
• 게이트웨이 링 라우팅은 Azure Traffic Manager가 제어한다.
• 기존 복제본을 다양한 가용성 영역에 배치하므로 추가 비용 없이 사용할 수 있다.
• 데이터센터 중단 같은 큰 장애에도 탄력적으로 복구 가능하다.
• 기존 Premium/Business Critical DB 또는 Elastic Pool을 영역 중복 구성으로 변환할 수 있다.

Automated Backups

Azure SQL 서비스별 자동 백업 방식은 다르다.

LTR: Long Term Retention

Automated Patching

Azure SQL Database와 Azure SQL Managed Instance는 PaaS 서비스이므로 OS와 SQL 데이터베이스 엔진의 최신 보안 업데이트 및 성능 개선 패치가 자동 적용된다.

Business Continuity 참고

Business Continuity는 기업의 핵심 자산, 서비스, 수익에 대한 위협을 식별하고, 주요 비즈니스 기능이 재난이나 장애 상황에서도 계속 운영될 수 있도록 하는 전략이다.

Azure SQL Database에서는 내장된 고가용성, 지역 중복, 장애 복구 기능을 통해 서비스 지속성을 보장한다. SPOF는 시스템, 네트워크, 소프트웨어 등 특정 지점 장애가 전체 시스템 중단으로 이어지는 단일 실패 지점을 의미한다.

Azure Site Recovery 참고

Azure Site Recovery는 Microsoft Azure에서 제공하는 재해 복구 서비스이다. 주요 IT 중단 발생 시에도 비즈니스 애플리케이션과 워크로드를 계속 실행하여 Business Continuity를 보장하도록 돕는다.

Geo-replication

Geo-replication은 Azure SQL Database, Managed Instance, SQL Server on Azure VM에 따라 지원 방식이 다르다.

Migration & Innovation

Migrating to Azure

Azure는 온프레미스 SQL Server, 다른 클라우드, 타 DB 등에서 Azure SQL 제품으로 안전하게 이전하기 위한 절차와 도구를 제공한다.

클라우드 마이그레이션: 비즈니스 드라이버 및 전략

성공적인 클라우드 마이그레이션은 기술 이동만이 아니라 명확한 비즈니스 이유를 기반으로 전략을 선택하는 과정이다.

Azure Cloud Migration Strategy: 8R

참고로 Gartner의 5R 이후 AWS에서는 Repurchase를 추가한 6R 및 7R이 많이 활용되며, Azure에서는 8R로 분류해 설명한다.

AWS Cloud Migration Strategy 참고

AWS 7R은 다음과 같이 시각적으로 정리된다.

최신 기능

Vector 데이터 지원 및 RAG 아키텍처

Azure SQL Database는 VECTOR 데이터 형식과 VECTOR_DISTANCE 함수를 지원하여 별도 벡터 DB 없이 기존 관계형 데이터와 함께 RAG 아키텍처를 구현할 수 있다.

JSON Native Support

기존에는 JSON을 NVARCHAR 문자열 컬럼에 담아 처리했지만, JSON 타입으로 처리하면서 성능 개선이 가능해졌다.

Fabric Mirrored Databases 연동

Azure SQL은 Microsoft Fabric의 Mirrored Database와 연결된다. 포털에서 미러링을 켜면 Azure SQL 데이터가 Fabric OneLake에 실시간에 가깝게 Delta 포맷으로 복제된다.

사례

Azure Virtual Machines의 SQL Server 사례: Allscripts

Allscripts는 의료 서비스 소프트웨어 제조업체이다. 애플리케이션을 안전하고 안정적으로 호스트하기 위해 Azure로 빠르게 이동하려 했고, Azure Site Recovery를 사용해 약 1,000개의 VM에서 실행 중이던 애플리케이션 수십 개를 3주 만에 Azure로 마이그레이션했다.

Azure SQL Managed Instance 사례: Komatsu

Komatsu는 건설용 중장비 제조 회사로, 여러 메인프레임 애플리케이션의 다양한 데이터를 통합적으로 파악하고 오버헤드를 줄이고자 했다. SQL Server 기능 호환성이 중요했기 때문에 Azure SQL Managed Instance를 선택했다.

Azure SQL Database 사례: AccuWeather

AccuWeather는 날씨 분석 및 예측 기업으로, 빅데이터, 머신러닝, AI 기능을 활용하기 위해 Azure를 선택했다. 데이터베이스 관리보다 모델과 애플리케이션 구축에 집중하고자 SQL Database를 Azure Data Factory, Azure Machine Learning 등과 함께 사용했다.

전체 정리

Azure SQL은 SQL Server 엔진을 기반으로 한 Azure의 통합 데이터베이스 제품군이다. Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VM은 각각 관리 수준, 호환성, 제어 범위가 다르며, 워크로드 특성에 따라 선택해야 한다.

PaaS 기반의 Azure SQL Database와 Managed Instance는 자동 패치, 자동 백업, 고가용성, 보안, 성능 모니터링, 자동 튜닝을 제공한다. 특히 Serverless, Elastic Pool, Hyperscale, Private Link, Entra ID 인증, Ledger, Vector, Fabric Mirroring 등 최신 기능을 통해 운영 부담을 줄이면서 확장성과 보안성을 강화할 수 있다.

마이그레이션 관점에서는 DMS, BACPAC, Log Replay Service, Managed Instance Link, Native backup/restore, Azure Migrate/Arc 등 다양한 도구를 제공한다. 클라우드 이전 전략은 Retire, Rehost, Replatform, Refactor, Rearchitect, Replace, Rebuild, Retain의 8R 관점에서 비즈니스 목표와 워크로드 특성에 맞게 선택해야 한다.

한 줄 요약

Azure SQL은 SQL Server 기반 워크로드를 Azure에서 운영하기 위한 통합 데이터베이스 플랫폼이며, 서비스 유형별로 관리 책임과 호환성, 확장성, 보안 기능이 다르므로 워크로드 특성에 맞는 선택이 중요하다.

실습

Azure SQL 생성

소프트웨어 개발 프로젝트의 계획, 개발, 테스트 및 배포 전 과정을 지원하는 통합 플랫폼

GraphQL 기반 API 배포

Fabric에서 레이크하우스 생성 graphQL 생성 데이터 업로드 후 graphQL 연결 엔드포인트 복사로 확인 network를 확인해서 http request 내역 확인 가능 엔드포인트, 메소드, 헤더, 바디

Postman으로 확인

Authorization Token은 개발자도구로 확인해야하는데, safari를 사용한다면 환경설정에서 웹 개발자 도구 보기를 선택해야한다. opt+cmd+i를 누르고, 개발자도구탭에서 네트워크를 선택한다 graphql을 찾고, 우클릭해서 curl로 복사 선택 이후 postman에서 import로 추가해준다. 자동으로 authorization token이 들어가고 정상적으로 200 OK 가 떨어진다. 참고로 체크는 GraphQL로 해야하는데, 로그인 안하면 지원 안하는듯. 로그인하니 뜬다.

가상환경 생성

# 1. 'fabric-lab'이라는 이름의 새로운 폴더(디렉토리)를 생성합니다.
mkdir fabric-lab

# 2. 생성한 'fabric-lab' 폴더 안으로 이동합니다.
cd fabric-lab

# 3. 'fabric'이라는 이름의 콘다 가상 환경을 생성합니다.
#    -c conda-forge: 패키지를 가져올 채널(저장소) 지정
#    nodejs=24: 최신 버전인 Node.js 24 버전을 함께 설치합니다.
conda create -n fabric -c conda-forge nodejs=24

# 4. 방금 만든 'fabric3' 가상 환경을 활성화합니다. 
# (주의: 위에서 'fabric'으로 만드셨다면 'conda activate fabric'이 맞습니다.)
conda activate fabric3

# 5. 서버 코드를 담을 'server' 폴더를 생성합니다.
mkdir server

# 6. 'server' 폴더 안으로 이동합니다.
cd server

# 7. Node.js 프로젝트를 초기화합니다. (-y는 모든 설정을 기본값으로 자동 승인함)
# 이 명령어를 치면 package.json 파일이 생성됩니다.
npm init -y

# 8. 서버 운영에 필요한 핵심 라이브러리들을 설치합니다.
# express: 웹 서버 프레임워크
# cors: 교차 출처 리소스 공유(보안 정책) 해결용
# @azure/identity: Azure 서비스 인증용 (패브릭 연결 시 필요)
# node-fetch@2: API 요청을 보내기 위한 라이브러리 (버전 2)
npm install express cors @azure/identity node-fetch@2

샘플 코드 실행

fabric-lab/server 에서 실행

npm init -y
npm install express cors @azure/identity node-fetch@2

fabric의 graphQL에서 코드 생성(js) commonjs 를 module로 바꿔줘야한다

샘플 코드 저장 후 node {파일명}.js로 실행하면 브라우저 인증 후 데이터 조회 가능 (graphql.js 의 경로가 package.json과 동일한 경로여야 함) 이 경우 authentication을 브라우저에서 열리면서 해야한다.

클라이언트 secret을 통해서 인증하는방식으로 해야 앱 개발 가능(매번 브라우저 인증은 불가능)

앱등록 후 액세스 관리

Entra Id 화면- 관리- 앱등록에서 Fabric 전체를 관리할 어플리케이션 등록 가능 등록 후 ClientId와 Secretkey 발급 가능 이후 fabric에서 액세스관리에서 기여자로 추가 tenant ID client ID client Secret 필요

클라이언트로 인증 처리

import { ClientSecretCredential, InteractiveBrowserCredential } from "@azure/identity";

// Acquire a token
// DO NOT USE IN PRODUCTION.
// Below code to acquire token is for development purpose only to test the GraphQL endpoint
// For production, always register an application in a Microsoft Entra ID tenant and use the appropriate client_id and scopes
// https://learn.microsoft.com/en-us/fabric/data-engineering/connect-apps-api-graphql#create-a-microsoft-entra-app

const TENANT_ID = "";
const CLIENT_ID = "";
const CLIENT_SECRET = "";

let app = new ClientSecretCredential(TENANT_ID, CLIENT_ID, CLIENT_SECRET);
let tokenPromise = app.getToken('https://analysis.windows.net/powerbi/api/.default');
let accessToken = await tokenPromise;

const endpoint = '';
const query = `
query {
  namhae_travels(first: 10) {
     items {
        no
        name
        address
     }
  }
}
`;

const variables = 
  {

  }
  ;

const headers = {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${accessToken.token}`
};

async function fetchData()     {
    try {
        const response = await fetch(endpoint, {
            method: 'POST',
            headers: headers,
            body: JSON.stringify({ query, variables }),
        });

        const result = await response.json();
        console.log(JSON.stringify(result));
    } catch (error) {
        console.log('Error fetching data:', error);
    }
}

fetchData();

DevOps에 레포지토리 업로드

devops의 repos-files의 링크를 local에서 add remote에 사용

vscode상에서는 차례대로 링크복붙-origin입력-git credentials 복붙(password)

CI 파이프라인

Settings-Agent Pool-Default

이후 mac에서는 엄청나게 비밀번호 입력을 많이 해야한다고 하셔서 안내해주신대로 비밀번호 입력을 한 번만 하도록 설정했다.(권한변경)

sudo xattr -rd com.apple.quarantine <agent파일 위치>

이후

./config.sh

하는 도중에 해당 폴더가 documents 하위에 있어 루트권한으로도 접근이 막히는 문제가 발생했다. 따라서 agent폴더 자체를 루트디렉토리로 옮겨서 해결했다.

PAT 토큰 발급은 우상단 user settings로 하면 된다.

trigger:
  paths:
    include:
      - server/*

pool:
  name: 'Default'

steps:
  - checkout: self
    clean: true       # 기존에 남은 찌꺼기 파일들을 깨끗이 지우고 시작
    fetchDepth: 1     # 최신 커밋 1개만 빠르게 가져옴
    displayName: 'Get Sources (Manual)'
  - task: NodeTool@0
    inputs:
      versionSpec: '24.x'
    displayName: 'Install Node.js'

  - script: |
      cd server
      npm install
      # NestJS나 TypeScript를 사용한다면 build 스크립트가 필수입니다.
      # 일반 Express라면 생략 가능하지만, 관례상 포함하는 경우가 많습니다.
      npm run build --if-present
    displayName: 'Install and Build'

  - task: ArchiveFiles@2
    inputs:
      # 중요: 'server' 폴더 전체를 압축하되,
      # 보통 node_modules를 포함해야 App Service에서 바로 실행됩니다.
      rootFolderOrFile: 'server'
      includeRootFolder: false
      archiveType: 'zip'
      archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
    displayName: 'Archive files'

  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
      ArtifactName: 'drop'
    displayName: 'Publish Artifact'

import { ClientSecretCredential } from "@azure/identity";
import express from 'express';
import cors from 'cors';
import fetch from 'node-fetch';

const TENANT_ID = "";
const CLIENT_ID = "";
const CLIENT_SECRET = "";

let credential = new ClientSecretCredential(TENANT_ID, CLIENT_ID, CLIENT_SECRET);
let tokenPromise = credential.getToken('https://analysis.windows.net/powerbi/api/.default');
let accessToken = await tokenPromise;

const app = express();
app.use(cors()); //이부분 괄호 안쳤다가 접속 안됨
app.use(express.json());

const config = {

}

app.get('/', (req, res) => {
    res.json({
        status: "OK",
        message: "조회에 성공하였습니다.",
        token: accessToken
    })
});

app.listen(3000, () => {
    console.log("Server is running on port 3000");
});

SQL Endpoint vs Dedicated Warehouse

Microsoft Fabric는 전통적인 Data Warehouse 외에도 Lakehouse에 정제된 데이터를 두고 SQL Endpoint로 읽는 방법도 제공

Spark SQL vs T-SQL

T-SQL: Microsoft SQL Server와 Azure SQL Database에서 사용하는 표준 SQL 언어의 확장판으로서 데이터 정의, 데이터 조작, 데이터 제어 뿐만 아니라, 절차적 프로그래밍 기능을 추가하여 복잡한 비즈니스 로직을 서버 측에서 구현

T-SQL을 쓰는 이유

• Universal Connectivity: Excel, 3rd Party BI도구와 높은 호환성
• Standard Governance: GRATN/DENY 기반의 명확한 오브젝트 레벨 권한 관리
• Logic Encapsulation: Stored Procedure를 통해 비즈니스 로직을 DB 내부에 안전하게 격리

Cross-Database Query

다른 Database, 다른 Lakehouse에 있는 테이블을 JOIN 하기 위해서 데이터를 이동할 필요가 없음

Power BI Direct Lake Mode

• Import는 메모리 한계가 있고 Direct Query는 느림
• 이럴때 Direct Lake를 사용하면 빠른 속도에 대용량 파일도 로드 가능

실습: Microsoft Fabric에서 Data Warehouse 쿼리

Data Warehouse 쿼리

SQL 쿼리 편집기는 IntelliSense, 코드 완성, 구문 강조 표시, 클라이언트 측 구문 분석(parsing) 및 유효성 검사를 지원합니다. Data Definition Language (DDL), Data Manipulation Language (DML) 및 Data Control Language (DCL) 문을 실행할 수 있다.

SELECT
    D.MonthName,
    COUNT(*) AS TotalTrips,
    SUM(T.TotalAmount) AS TotalRevenue
FROM dbo.Trip AS T
JOIN dbo.[Date] AS D
    ON T.[DateID]=D.[DateID]
GROUP BY D.MonthName;

이 쿼리를 통해 각 월별 전체 이동 횟수와 총 수익을 확인할 수 있다.

다음으로 요일별 평균 이동 시간과 평균 이동 거리를 분석한다.

SELECT
    D.DayName,
    AVG(T.TripDurationSeconds) AS AvgDuration,
    AVG(T.TripDistanceMiles) AS AvgDistance
FROM dbo.Trip AS T
JOIN dbo.[Date] AS D
    ON T.[DateID]=D.[DateID]
GROUP BY D.DayName;

이를 통해 요일별 이동 패턴을 파악할 수 있다.

또한, 이동이 많이 발생한 도시를 확인하기 위해 도시별 이동 수 상위 10개를 조회한다.

SELECT TOP 10
    G.City,
    COUNT(*) AS TotalTrips
FROM dbo.Trip AS T
JOIN dbo.Geography AS G
    ON T.DropoffGeographyID=G.GeographyID
GROUP BY G.City
ORDER BY TotalTrips DESC;

이 쿼리는 특정 도시에서의 이동량이 얼마나 집중되는지 확인하는 데 유용하다.

데이터 일관성 확인

분석 결과의 신뢰성을 확보하기 위해 데이터의 일관성을 확인한다.

먼저 비정상적으로 긴 이동 시간이 존재하는지 확인한다. (24시간 = 86400초 기준)

-- Check for trips with unusually long duration
SELECT COUNT(*) FROM dbo.Trip WHERE TripDurationSeconds > 86400; -- 24 hours

이 값이 존재한다면 데이터 오류 가능성을 의심할 수 있다.

다음으로 음수 이동 시간이 존재하는지 확인한다.

-- Check for trips with negative trip duration
SELECT COUNT(*) FROM dbo.Trip WHERE TripDurationSeconds < 0;

음수 이동 시간은 명백한 데이터 오류이므로 반드시 제거해야 한다. 확인된 데이터 오류를 제거하여 데이터 품질을 개선한다.

-- Remove trips with negative trip duration
DELETE FROM dbo.Trip WHERE TripDurationSeconds < 0;

이 과정을 통해 분석에 사용되는 데이터의 정확도를 높일 수 있다.

뷰로 저장

이제 자주 사용하는 분석 쿼리를 View로 저장하여 재사용할 수 있도록 한다.

먼저 기본 집계 쿼리를 작성한다.

SELECT
    D.DayName,
    AVG(T.TripDurationSeconds) AS AvgDuration,
    AVG(T.TripDistanceMiles) AS AvgDistance
FROM dbo.Trip AS T
JOIN dbo.[Date] AS D
    ON T.[DateID]=D.[DateID]
GROUP BY D.DayName;

이후 특정 조건(예: 1월 데이터)으로 필터링한다.

SELECT
    D.DayName,
    AVG(T.TripDurationSeconds) AS AvgDuration,
    AVG(T.TripDistanceMiles) AS AvgDistance
FROM dbo.Trip AS T
JOIN dbo.[Date] AS D
    ON T.[DateID]=D.[DateID]
WHERE D.Month = 1
GROUP BY D.DayName

해당 쿼리를 선택한 후 Save as view 기능을 사용하여 vw_JanTrip이라는 이름으로 저장한다.

이렇게 생성된 View는 이후 반복적인 분석이나 BI 도구에서 재사용할 수 있다.

T-SQL을 사용하여 Data Warehouse에 데이터 로드

Lakehouse 생성 및 데이터 준비

먼저 Microsoft Fabric에서 Workspace를 생성한 뒤, Lakehouse를 생성한다.

이후 제공된 sales.csv 파일을 Lakehouse의 Files 영역에 업로드한다. 업로드한 파일을 기반으로 테이블을 생성(Create table) 하여 staging_sales 테이블을 만든다.

이 테이블은 이후 Data Warehouse로 데이터를 적재하기 위한 Staging 영역 역할을 한다.

Data Warehouse 생성

다음으로 Data Warehouse를 생성한다.

이 Warehouse는 Lakehouse의 데이터를 기반으로 분석용 Fact/Dimension 테이블을 구성하는 공간이다.

Warehouse에서 안하고 Lakehouse에서 하면 create table 할때 denied되니 명심하자

Fact 및 Dimension 테이블 생성

Warehouse에서 SQL Query를 열고, Fact 테이블과 Dimension 테이블을 생성한다.

CREATE SCHEMA Sales;
GO

CREATE TABLE Sales.Fact_Sales
(
    SalesOrderNumber NVARCHAR(20) NOT NULL,
    SalesOrderLineNumber INT NOT NULL,
    OrderDate DATE NOT NULL,
    CustomerKey INT NOT NULL,
    ItemKey INT NOT NULL,
    Quantity INT,
    UnitPrice FLOAT,
    Tax FLOAT
);
GO

CREATE TABLE Sales.Dim_Customer
(
    CustomerKey INT IDENTITY(1,1) NOT NULL,
    CustomerName NVARCHAR(100),
    Email NVARCHAR(100)
);
GO

CREATE TABLE Sales.Dim_Item
(
    ItemKey INT IDENTITY(1,1) NOT NULL,
    ItemName NVARCHAR(100)
);
GO

• Fact_Sales → 판매 데이터 저장 (Fact Table)
• Dim_Customer, Dim_Item → 차원 테이블

Staging 데이터 연결 (View 생성)

Lakehouse의 staging_sales 테이블을 Warehouse에서 참조하기 위해 View를 생성한다.

CREATE VIEW Sales.Staging_Sales
AS
SELECT *
FROM staging_sales;

이 View를 통해 Lakehouse 데이터를 Warehouse에서 직접 조회할 수 있다.

데이터 로드를 위한 저장 프로시저 생성

Staging 데이터를 Fact/Dimension 테이블로 적재하기 위해 저장 프로시저를 생성한다.

CREATE PROCEDURE Sales.LoadDataFromStaging (@OrderYear INT)
AS
BEGIN

-- Load customers
INSERT INTO Sales.Dim_Customer (CustomerName, Email)
SELECT DISTINCT CustomerName, Email
FROM Sales.Staging_Sales
WHERE YEAR(OrderDate) = @OrderYear
AND CustomerName NOT IN (SELECT CustomerName FROM Sales.Dim_Customer);

-- Load items
INSERT INTO Sales.Dim_Item (ItemName)
SELECT DISTINCT Item
FROM Sales.Staging_Sales
WHERE YEAR(OrderDate) = @OrderYear
AND Item NOT IN (SELECT ItemName FROM Sales.Dim_Item);

-- Load fact table
INSERT INTO Sales.Fact_Sales
SELECT
    s.SalesOrderNumber,
    s.SalesOrderLineNumber,
    s.OrderDate,
    c.CustomerKey,
    i.ItemKey,
    s.Quantity,
    s.UnitPrice,
    s.Tax
FROM Sales.Staging_Sales s
JOIN Sales.Dim_Customer c
    ON s.CustomerName = c.CustomerName
JOIN Sales.Dim_Item i
    ON s.Item = i.ItemName
WHERE YEAR(s.OrderDate) = @OrderYear;

END;

이 프로시저는 다음 작업을 수행한다.

• 고객 데이터 적재
• 상품 데이터 적재
• Fact 테이블 적재

데이터 로드 실행

2021년 데이터를 Warehouse로 로드한다.

EXEC Sales.LoadDataFromStaging 2021;

데이터 분석

데이터가 정상적으로 로드되었는지 확인하기 위해 분석 쿼리를 실행한다.

고객별 총 판매액

SELECT
    c.CustomerName,
    SUM(f.Quantity * (f.UnitPrice + f.Tax)) AS TotalSales
FROM Sales.Fact_Sales f
JOIN Sales.Dim_Customer c
    ON f.CustomerKey = c.CustomerKey
GROUP BY c.CustomerName
ORDER BY TotalSales DESC;

상품별 총 판매액

SELECT
    i.ItemName,
    SUM(f.Quantity * (f.UnitPrice + f.Tax)) AS TotalSales
FROM Sales.Fact_Sales f
JOIN Sales.Dim_Item i
    ON f.ItemKey = i.ItemKey
GROUP BY i.ItemName
ORDER BY TotalSales DESC;

카테고리별 상위 고객 분석

WITH SalesCTE AS
(
    SELECT
        c.CustomerName,
        i.ItemName,
        SUM(f.Quantity * (f.UnitPrice + f.Tax)) AS TotalSales,
        CASE
            WHEN i.ItemName LIKE '%Bike%' THEN 'Bike'
            ELSE 'Other'
        END AS Category
    FROM Sales.Fact_Sales f
    JOIN Sales.Dim_Customer c
        ON f.CustomerKey = c.CustomerKey
    JOIN Sales.Dim_Item i
        ON f.ItemKey = i.ItemKey
    GROUP BY c.CustomerName, i.ItemName
)
SELECT *
FROM
(
    SELECT *,
           ROW_NUMBER() OVER (PARTITION BY Category ORDER BY TotalSales DESC) AS rn
    FROM SalesCTE
) t
WHERE rn <= 5;

자습서: Direct Lake 의미 체계 모델 및 Power BI 보고서 만들기

데이터 가져오기

Warehouse에서 데이터 가져오기 선택 샘플 데이터의 Retail~ 선택

의미체계 모델 만들기

만들어진 의미체계 모델은 작업 영역에서 확인 가능

관계 관리

보고서 만들기

Fabric을 활용한 실시간 분석

Security Architecture & Hierarchy

Workspace Roles & Permissions

단위입니다. 팀 리더, 데이터 엔지니어, 분석가, 보고서 사용자 등 역할에 따라 Admin, Member, Contributor, Viewer 중 하나를 부여하여 필요한 권한만 제공 더 세밀한 제어가 필요하면 'Share'로 특정 아이템만 공유

OneLake Security

데이터 자체(테이블, 폴더)에 대한 접근을 제어.

Row-Level Security(RLS)

사용자의 권한(User Context)에 따라 테이블의 특정 행(Row)만 조회되도록 필터링하는 보안 기능

Implementing RLS with T-SQL

1. 보안 함수 생성

USER_NAME() 함수를 사용하여 현재 접속한 사용자 식별

2. 보안 정책 적용

위에서 만든 함수를 실제 테이블에 결합 STATE = ON 으로 설정하는 즉시 모든 쿼리에 필터가 적용

SQL Permissions: GRANT, Deny & Column-Level Security

Governance: Purview, Lineage & Endorsement

Purview Hub (데이터 보호)

• MIP Label: 데이터에 '기밀(Confidential)’ tag를 붙이면, 엑셀로 다운로드해도 암호화가 유지 • 인사이트: "우리 회사에 민감 정보가 얼마나 있지?"를 대시보드로 표시

Data Lineage (데이터 족보)

• 자동 시각화: 원본 데이터가 어떤 파이프라인을 거쳐 어떤 리포트가 되었는지 자동 생성 • 영향도 분석: "이 테이블 고치면 어떤 리포트가 깨질까?“ 미리 알 수 있음

Endorsement (신뢰 마크)

• Certified (인증됨): IT 부서가 "이건 믿고 써도 됨"이라고 보증한 데이터. • Promoted (홍보됨): 팀 리더가 "우리 팀 데이터 공유할게"라고 내놓은 데이터.

Real-Time Intelligence: KQL Database & Eventstream

KQL Database (저장소)

• 고성능 로그 분석: 기존 SQL DB는 로그 쌓이면 느려지지만, KQL DB는 페타바이트급 로그도 순식간에 검색 • 비정형 데이터: JSON, 텍스트 로그 등 구조가 일정하지 않은 데이터도 그대로 넣고 바로 쿼리

Eventstream (연결 통로)

• No-Code 연결: IoT 센서, 앱 로그, Kafka 등을 코딩 없이 클릭만으로 연결 • 실시간 처리: 데이터가 들어오는 즉시 필터링하거나 변환해서 KQL DB나 Lakehouse로 전송

KQL (Kusto Query Language)

데이터를 탐색하고 패턴을 발견하고, 변칙과 이상값을 식별하고, 통계 모델링을 만드는 등의 작업을 수행할 수 있는 강력한 도구로서 Microsoft에서 만들었으며 Azure Data Explorer, Azure Monitor, Microsoft Fabric 등에 사용 대소문자를 구분함

Fabric Activator (formely Reflex)

데이터 소스에서 특정 패턴이나 조건이 감지될 때 자동으로 작업을 실행하는 코드 없는 저지연 이벤트 감지 엔진

• 1초 미만의 대기 시간으로 데이터 원본을 지속적으로 모니터링
• 임계값이 충족되거나 특정 패턴이 검색되면 작업 (예: 전자메일 또는 Teams 알림 보내기, Power Automate 흐름 시작, 타사 시스템 통합 등)을 시작
• 데이터가 지속적으로 흐르는 반응형 이벤트 기반 아키텍처에 적합하며, 이벤트 데이터의 상태 저장 평가에 따라 거의 실시간으로 결정

실습: Microsoft Fabric 데이터 웨어하우스 보안 설정

테이블의 Column에 동적 데이터 마스킹 규칙 적용

동적 데이터 마스킹 규칙은 테이블 수준의 개별 Column에 적용되므로 모든 Query가 마스킹의 영향을 받습니다. 기밀 데이터를 볼 명시적인 권한이 없는 사용자는 Query 결과에서 마스킹된 값을 보게 되며, 데이터를 볼 명시적인 권한이 있는 사용자는 마스킹되지 않은 데이터를 봅니다. 마스크에는 기본(default), 이메일(email), 무작위(random), 사용자 지정 문자열(custom string)의 네 가지 유형이 있습니다.

1. Warehouse에서 T-SQL 타일을 선택하고, 다음 T-SQL 문을 사용하여 테이블을 생성하고 데이터를 삽입하고 조회합니다.

   CREATE TABLE dbo.Customers
   (   
    CustomerID INT NOT NULL,   
    FirstName varchar(50) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL,     
    LastName varchar(50) NOT NULL,     
    Phone varchar(20) MASKED WITH (FUNCTION = 'default()') NULL,     
    Email varchar(50) MASKED WITH (FUNCTION = 'email()') NULL   
   );
   

INSERT dbo.Customers (CustomerID, FirstName, LastName, Phone, Email) VALUES (29485,'Catherine','Abel','555-555-5555','catherine0@adventure-works.com'), (29486,'Kim','Abercrombie','444-444-4444','kim2@adventure-works.com'), (29489,'Frances','Adams','333-333-3333','frances0@adventure-works.com');

SELECT * FROM dbo.Customers;

마스크 해제된 데이터를 볼 수 없는 사용자가 테이블을 Query할 때, FirstName Column은 문자열의 첫 글자와 XXXXXXX를 표시하고 마지막 문자는 표시하지 않습니다. Phone Column은 xxxx를 표시합니다. Email Column은 이메일 주소의 첫 글자 다음에 XXX@XXX.com을 표시합니다. 이 접근 방식은 민감한 데이터가 기밀을 유지하도록 보장하면서도 제한된 사용자가 테이블을 Query할 수 있도록 합니다.
![](https://velog.velcdn.com/images/rudin_/post/8f5fd4e8-123a-4eda-adc9-78cd9d61ca4d/image.png)

2. ▷ 실행 버튼을 사용하여 SQL 스크립트를 실행합니다. 이 스크립트는 Data Warehouse의 dbo Schema에 Customers라는 새 테이블을 생성합니다.
3. 그런 다음, 탐색기 창에서 Schemas > dbo > Tables를 확장하고 Customers 테이블이 생성되었는지 확인합니다. Workspace 생성자로서 마스크 해제된 데이터를 볼 수 있는 Workspace Admin 역할의 멤버이므로, SELECT 문은 마스크 해제된 데이터를 반환합니다.

## 행 수준 보안(Row-level security) 적용
```python
CREATE TABLE dbo.Sales  
(  
    OrderID INT,  
    SalesRep VARCHAR(60),  
    Product VARCHAR(10),  
    Quantity INT  
);

--Populate the table with 6 rows of data, showing 3 orders for each test user. 
INSERT dbo.Sales (OrderID, SalesRep, Product, Quantity) VALUES
(1, '<username1>@<your_domain>.com', 'Valve', 5),   
(2, '<username1>@<your_domain>.com', 'Wheel', 2),   
(3, '<username1>@<your_domain>.com', 'Valve', 4),  
(4, '<username2>@<your_domain>.com', 'Bracket', 2),   
(5, '<username2>@<your_domain>.com', 'Wheel', 5),   
(6, '<username2>@<your_domain>.com', 'Seat', 5);  

SELECT * FROM dbo.Sales;  

새 Schema, Function으로 정의된 보안 Predicate, 그리고 보안 정책을 생성

--Create a separate schema to hold the row-level security objects (the predicate function and the security policy)
CREATE SCHEMA rls;
GO

/*Create the security predicate defined as an inline table-valued function.
A predicate evaluates to true (1) or false (0). This security predicate returns 1,
meaning a row is accessible, when a row in the SalesRep column is the same as the user
executing the query.*/   
--Create a function to evaluate who is querying the table
CREATE FUNCTION rls.fn_securitypredicate(@SalesRep AS VARCHAR(60)) 
    RETURNS TABLE  
WITH SCHEMABINDING  
AS  
    RETURN SELECT 1 AS fn_securitypredicate_result   
WHERE @SalesRep = USER_NAME();
GO   
/*Create a security policy to invoke and enforce the function each time a query is run on the Sales table.
The security policy has a filter predicate that silently filters the rows available to 
read operations (SELECT, UPDATE, and DELETE). */
CREATE SECURITY POLICY SalesFilter  
ADD FILTER PREDICATE rls.fn_securitypredicate(SalesRep)   
ON dbo.Sales  
WITH (STATE = ON);
GO

열 수준 보안(Column-level security) 구현

열 수준 보안은 어떤 사용자가 테이블의 특정 Column에 접근할 수 있는지 지정할 수 있도록 합니다. 이는 Column 목록과 Column을 읽을 수 있거나 없는 사용자 또는 역할을 지정하여 테이블에 GRANT 또는 DENY 문을 발행함으로써 구현됩니다. 접근 관리를 간소화하기 위해 개별 사용자 대신 역할에 권한을 할당합니다. 이 실습에서는 테이블을 생성하고, 테이블의 Column 하위 집합에 접근 권한을 부여하며, 제한된 Column이 본인 외의 사용자에게는 보이지 않는지 테스트합니다.

CREATE TABLE dbo.Orders
(   
    OrderID INT,   
    CustomerID INT,  
    CreditCard VARCHAR(20)      
);   
INSERT dbo.Orders (OrderID, CustomerID, CreditCard) VALUES
(1234, 5678, '111111111111111'),
(2341, 6785, '222222222222222'),
(3412, 7856, '333333333333333');   
SELECT * FROM dbo.Orders;

DENY SELECT ON dbo.Orders (CreditCard) TO [<username1>@<your_domain>.com];

T-SQL을 사용하여 SQL 세분화된 권한 구성

Fabric은 Workspace 수준 및 항목 수준에서 데이터 접근을 제어할 수 있는 권한 모델을 가지고 있습니다. Fabric Warehouse의 보안 개체(securables)를 사용자들이 무엇을 할 수 있는지 더 세밀하게 제어해야 할 때, 표준 SQL 데이터 제어 언어(DCL) 명령어인 GRANT, DENY, REVOKE를 사용할 수 있습니다. 이 실습에서는 객체(objects)를 생성하고, GRANT 및 DENY를 사용하여 객체를 보호한 다음, Query를 실행하여 세분화된 권한 적용의 효과를 확인합니다.

CREATE PROCEDURE dbo.sp_PrintMessage
AS
PRINT 'Hello World.';
GO   
CREATE TABLE dbo.Parts
(
    PartID INT,
    PartName VARCHAR(25)
);

INSERT dbo.Parts (PartID, PartName) VALUES
(1234, 'Wheel'),
(5678, 'Seat');
 GO

/*Execute the stored procedure and select from the table and note the results you get
as a member of the Workspace Admin role. Look for output from the stored procedure on 
the 'Messages' tab.*/
EXEC dbo.sp_PrintMessage;
GO   
SELECT * FROM dbo.Parts

다음으로, Workspace Viewer 역할의 멤버인 사용자에게 테이블에 대한 DENY SELECT 권한을 부여하고, 동일한 사용자에게 프로시저에 대한 GRANT EXECUTE 권한을 부여합니다. <username1>@<your_domain>.com을 Workspace에 Viewer 권한을 가진 사용자의 사용자 이름으로 대체합니다.

DENY SELECT on dbo.Parts to [<username1>@<your_domain>.com];

GRANT EXECUTE on dbo.sp_PrintMessage to [<username1>@<your_domain>.com];

Microsoft Fabric에서 Eventstream을 사용하여 실시간 데이터 수집

Eventstream은 Microsoft Fabric의 기능으로, 실시간 이벤트를 캡처, 변환 및 다양한 대상으로 라우팅합니다. Eventstream에 이벤트 데이터 원본, 대상 및 변환을 추가할 수 있습니다.

Eventhouse 만들기

작업 영역에서 + 새 항목을 선택

Eventstream 만들기

샘플 데이터 사용

원본 추가

대상 추가

watermark delay: 데이터가 늦게 도착해도 윈도우(결과 집계)를 닫지 않고 얼마나 더 기다려줄 것인가

캡처된 데이터 쿼리

이벤트 데이터 변환

변환된 데이터 쿼리

Microsoft Fabric Eventhouse에서 데이터 작업

KQL을 사용하여 데이터 쿼리

// Use 'project' and 'take' to view a sample number of records in the table and check the data.
Bikestream
| project Street, No_Bikes
| take 10

Bikestream
| project Street, ["Number of Empty Docks"] = No_Empty_Docks
| take 10

Bikestream
| summarize ["Total Number of Bikes"] = sum(No_Bikes)

Bikestream
| summarize ["Total Number of Bikes"] = sum(No_Bikes) by Neighbourhood
| project Neighbourhood, ["Total Number of Bikes"]

Bikestream
| summarize ["Total Number of Bikes"] = sum(No_Bikes) by Neighbourhood
| project Neighbourhood = case(isempty(Neighbourhood) or isnull(Neighbourhood), "Unidentified", Neighbourhood), ["Total Number of Bikes"]

Bikestream
| summarize ["Total Number of Bikes"] = sum(No_Bikes) by Neighbourhood
| project Neighbourhood = case(isempty(Neighbourhood) or isnull(Neighbourhood), "Unidentified", Neighbourhood), ["Total Number of Bikes"]
| sort by Neighbourhood asc

Bikestream
| summarize ["Total Number of Bikes"] = sum(No_Bikes) by Neighbourhood
| project Neighbourhood = case(isempty(Neighbourhood) or isnull(Neighbourhood), "Unidentified", Neighbourhood), ["Total Number of Bikes"]
| order by Neighbourhood asc

Bikestream
| where Neighbourhood == "Chelsea"
| summarize ["Total Number of Bikes"] = sum(No_Bikes) by Neighbourhood
| project Neighbourhood = case(isempty(Neighbourhood) or isnull(Neighbourhood), "Unidentified", Neighbourhood), ["Total Number of Bikes"]
| sort by Neighbourhood asc

이 가이드는 Fabric Lakehouse로 데이터를 수집하고, PySpark와 Spark SQL을 사용하여 데이터를 읽고, 분석하고, 시각화하는 전체 과정을 다룹니다.

1. 환경 설정 및 데이터 준비

작업 영역 및 Lakehouse 생성

1. 작업 영역 만들기: Fabric 홈 페이지에서 Workspaces를 선택하고, Advanced 섹션에서 Fabric Capacity 라이선스 모드를 선택하여 새 작업 영역을 만듭니다.
2. Lakehouse 생성: Create 메뉴에서 Lakehouse를 선택하고 이름을 지정하여 생성합니다.
3. 데이터 업로드:
   • orders.zip 파일을 다운로드하고 압축을 풉니다.
   • Lakehouse Explorer의 Files 폴더에서 Upload > Upload folder를 선택하여 orders 폴더(2019.csv, 2020.csv, 2021.csv 포함)를 업로드합니다.

Notebook 생성

• Create 페이지에서 Notebook을 생성합니다.

2. 데이터 로드 및 스키마 정의

기본 데이터 로드 (CSV)

2019.csv 파일을 로드하는 가장 기본적인 코드입니다.

# 2019.csv 파일 로드 (헤더 포함)
df = spark.read.format("csv").option("header","true").load("Files/orders/2019.csv")
display(df)

스키마 정의 및 모든 파일 로드

데이터 형식을 명시적으로 지정하고, 와일드카드(*)를 사용하여 orders 폴더 내의 모든 CSV 파일을 로드합니다.

from pyspark.sql.types import *

# 스키마 정의
orderSchema = StructType([
    StructField("SalesOrderNumber", StringType()),
    StructField("SalesOrderLineNumber", IntegerType()),
    StructField("OrderDate", DateType()),
    StructField("CustomerName", StringType()),
    StructField("Email", StringType()),
    StructField("Item", StringType()),
    StructField("Quantity", IntegerType()),
    StructField("UnitPrice", FloatType()),
    StructField("Tax", FloatType())
])

# 모든 연도의 CSV 파일 로드
df = spark.read.format("csv").schema(orderSchema).load("Files/orders/*.csv")
display(df)

3. 데이터 탐색 및 집계

데이터 필터링

특정 열을 선택하거나 조건을 적용하여 데이터를 필터링합니다.

# 특정 제품을 구매한 고유 고객 리스트 추출
customers = df.select("CustomerName", "Email").where(df['Item']=='Road-250 Red, 52')
print(f"Total records: {customers.count()}")
print(f"Distinct customers: {customers.distinct().count()}")
display(customers.distinct())

데이터 집계 및 그룹화

제품별 수량 합계 및 연도별 주문 수를 계산합니다.

# 제품별 주문 수량 합계
productSales = df.select("Item", "Quantity").groupBy("Item").sum()
display(productSales)

# 연도별 판매 주문 수 계산
from pyspark.sql.functions import *
yearlySales = df.select(year(col("OrderDate")).alias("Year")).groupBy("Year").count().orderBy("Year")
display(yearlySales)

4. 데이터 변환 및 저장

데이터프레임 변환 (열 추가 및 재정렬)

연/월 추출, 이름 분리 등 복합적인 변환을 수행합니다.

from pyspark.sql.functions import *

# 연, 월 열 추가 및 FirstName, LastName 분리
transformed_df = df.withColumn("Year", year(col("OrderDate"))).withColumn("Month", month(col("OrderDate")))
transformed_df = transformed_df.withColumn("FirstName", split(col("CustomerName"), " ").getItem(0)).withColumn("LastName", split(col("CustomerName"), " ").getItem(1))

# 열 필터링 및 순서 재정렬
transformed_df = transformed_df["SalesOrderNumber", "SalesOrderLineNumber", "OrderDate", "Year", "Month", "FirstName", "LastName", "Email", "Item", "Quantity", "UnitPrice", "Tax"]

# 결과 확인
display(transformed_df.limit(5))

변환된 데이터 저장 (Parquet)

데이터를 Parquet 형식으로 저장하고 다시 로드합니다.

# Parquet 형식으로 저장
transformed_df.write.mode("overwrite").parquet('Files/transformed_data/orders')
print("Transformed data saved!")

# 저장된 Parquet 파일 로드
orders_df = spark.read.format("parquet").load("Files/transformed_data/orders")
display(orders_df)

데이터 분할(Partitioning) 저장

성능 향상을 위해 연도 및 월별로 데이터를 분할하여 저장합니다.

# Year 및 Month별로 분할 저장
orders_df.write.partitionBy("Year","Month").mode("overwrite").parquet("Files/partitioned_data")
print("Transformed data saved!")

# 특정 파티션(2021년 전체) 데이터만 로드
orders_2021_df = spark.read.format("parquet").load("Files/partitioned_data/Year=2021/Month=*")
display(orders_2021_df)

5. 테이블 및 SQL 작업

Delta 테이블 생성 및 쿼리

관계를 정의하고 SQL로 쿼리할 수 있도록 Delta 테이블로 저장합니다.

# Delta 테이블로 저장
df.write.format("delta").saveAsTable("salesorders")

# 테이블 정보 확인
spark.sql("DESCRIBE EXTENDED salesorders").show(truncate=False)

salesorders 테이블의 ..메뉴에서 Load data> Spakr를 선택하여 새 코드 셀 추가

# PySpark 내에서 SQL 쿼리 실행
df = spark.sql("SELECT * FROM day1_lakehouse2.salesorders LIMIT 1000")
display(df)

SQL 매직 커맨드 사용

셀 상단에 %%sql을 사용하여 직접 SQL 문을 실행합니다.

%%sql
SELECT YEAR(OrderDate) AS OrderYear, 
       SUM((UnitPrice * Quantity) + Tax) AS GrossRevenue
FROM salesorders
GROUP BY YEAR(OrderDate)
ORDER BY OrderYear;

6. 데이터 시각화

Spark로 데이터 시각화

%%sql
SELECT * FROM salesorders

Matplotlib를 사용한 시각화

Spark 데이터프레임을 Pandas로 변환하여 막대형 차트를 생성합니다.

import pandas as pd
from matplotlib import pyplot as plt

# SQL 쿼리 결과를 Spark DF로 가져오기
sqlQuery = "SELECT CAST(YEAR(OrderDate) AS CHAR(4)) AS OrderYear, \
            SUM((UnitPrice * Quantity) + Tax) AS GrossRevenue, \
            COUNT(DISTINCT SalesOrderNumber) AS YearlyCounts \
            FROM salesorders \
            GROUP BY CAST(YEAR(OrderDate) AS CHAR(4)) \
            ORDER BY OrderYear"
df_spark = spark.sql(sqlQuery)

# Matplotlib를 위해 Pandas DF로 변환
df_sales = df_spark.toPandas()

# 차트 사용자 지정 및 출력
plt.clf()
fig = plt.figure(figsize=(8,3))
plt.bar(x=df_sales['OrderYear'], height=df_sales['GrossRevenue'], color='orange')
plt.title('Revenue by Year')
plt.xlabel('Year')
plt.ylabel('Revenue')
plt.grid(color='#95a5a6', linestyle='--', linewidth=2, axis='y', alpha=0.7)
plt.xticks(rotation=45)
plt.show()

# 서브플롯 생성 (막대 차트 + 파이 차트)
plt.clf()
fig, ax = plt.subplots(1, 2, figsize = (10,4))
ax.bar(x=df_sales['OrderYear'], height=df_sales['GrossRevenue'], color='orange')
ax.set_title('Revenue by Year')
ax.pie(df_sales['YearlyCounts'])
ax.set_title('Orders per Year')
ax.legend(df_sales['OrderYear'])
fig.suptitle('Sales Data')
plt.show()

Seaborn을 사용한 시각화

더 간결한 코드로 세련된 테마의 차트를 생성합니다.

import seaborn as sns

# 막대 차트 (Whitegrid 테마)
plt.clf()
sns.set_theme(style="whitegrid")
ax = sns.barplot(x="OrderYear", y="GrossRevenue", data=df_sales)
plt.show()

# 선형 차트
plt.clf()
ax = sns.lineplot(x="OrderYear", y="GrossRevenue", data=df_sales)
plt.show()

7. 리소스 정리

실습이 종료되면 세션을 중단하고 작업 영역을 삭제합니다.

1. Notebook 상단에서 Stop session을 클릭합니다.
2. Workspace settings에서 Remove this workspace를 선택하여 삭제합니다.

스트리밍 데이터에 Delta Table 사용

Delta Lake는 스트리밍 데이터를 지원합니다. Delta Table은 Spark Structured Streaming API를 사용하여 생성된 데이터 스트림의 Sink 또는 Source가 될 수 있습니다. 이 예시에서는 시뮬레이션된 IoT(Internet of Things) 시나리오에서 일부 스트리밍 데이터의 Sink로 Delta Table을 사용합니다.

 from notebookutils import mssparkutils
 from pyspark.sql.types import *
 from pyspark.sql.functions import *

 # Create a folder
 inputPath = 'Files/data/'
 mssparkutils.fs.mkdirs(inputPath)

 # Create a stream that reads data from the folder, using a JSON schema
 jsonSchema = StructType([
 StructField("device", StringType(), False),
 StructField("status", StringType(), False)
 ])
 iotstream = spark.readStream.schema(jsonSchema).option("maxFilesPerTrigger", 1).json(inputPath)

 # Write some event data to the folder
 device_data = '''{"device":"Dev1","status":"ok"}
 {"device":"Dev1","status":"ok"}
 {"device":"Dev1","status":"ok"}
 {"device":"Dev2","status":"error"}
 {"device":"Dev1","status":"ok"}
 {"device":"Dev1","status":"error"}
 {"device":"Dev2","status":"ok"}
 {"device":"Dev2","status":"error"}
 {"device":"Dev1","status":"ok"}'''

 mssparkutils.fs.put(inputPath + "data.txt", device_data, True)

 print("Source stream created...")

방금 실행한 코드는 가상의 IoT 디바이스에서 읽은 데이터를 나타내는, 일부 데이터가 저장된 폴더를 기반으로 스트리밍 데이터 Source를 생성했습니다.

# Write the stream to a delta table
delta_stream_table_path = 'Tables/iotdevicedata'
checkpointpath = 'Files/delta/checkpoint'
deltastream = iotstream.writeStream.format("delta").option("checkpointLocation", checkpointpath).start(delta_stream_table_path)
print("Streaming to delta sink...")

이 코드는 스트리밍 디바이스 데이터를 Delta 형식으로 iotdevicedata라는 폴더에 씁니다. Tables 폴더에 있는 폴더 위치의 경로 때문에 해당 폴더에 Table이 자동으로 생성됩니다.

%%sql
SELECT * FROM IotDeviceData;

# Add more data to the source stream
more_data = '''{"device":"Dev1","status":"ok"}
{"device":"Dev1","status":"ok"}
{"device":"Dev1","status":"ok"}
{"device":"Dev1","status":"ok"}
{"device":"Dev1","status":"error"}
{"device":"Dev2","status":"error"}
{"device":"Dev1","status":"ok"}'''

mssparkutils.fs.put(inputPath + "more-data.txt", more_data, True)

%%sql
SELECT * FROM IotDeviceData;

deltastream.stop()

코드에서 Files/data 안에 있는 데이터들로 하도록 설정해서, 기존의 sales 데이터까지 읽어들여 NULL값이 입력되는 문제가 있었다. sales 데이터를 삭제하고 진행하면 정상적으로 진행된다.

또한 동일한 데이터(동일한 셀)을 넣는걸 반복하더라도 중복으로 적재되지 않는다.

PySpark 기반 메달리온 아키텍처 구축과 Data Wrangler를 활용한 효율적 데이터 전처리

Starter Pool

Fabric에서는 Live Pool(Warm) 방식으로 클러스터를 운영 → 대기 시간 없이 거의 바로 세션을 시작 가능

• 항상 켜져 있음
• 5~10초안에 세션 시작
• 대기 비용 X

OneLake & Notebook

• Fabric Notebook에서는 Lakehouse Explorer(OneLake에 저장된 테이블 및 파일 탐색)가 내장
• 데이터 탐색을 위한 별도 탭 이동 없이 Notebook 내에서 데이터 탐색, 코드 작성, 시각화를 진행

Spark on Databricks vs Spark on Fabric

Medallion Architecture

Data Quality Startegy

Level 3: Advanced Validation (고급)

• What: 복잡한 비즈니스 규칙 검증
• How: Great Expectations (GX) 라이브러리 활용 (Fabric Notebook에 설치 가능)
• Note: Fabric은 Python 라이브러리를 자유롭게 지원하므로, 기존에 쓰던 GX 같은 도구를 그대로 사용 가능

Level 2: Constraint Checks (중급)

• What: 값의 유효성 검사 (NULL 불가, 양수만 허용 등)
• How: Delta Lake의 CHECK 제약 조건 사용
• Code:ALTER TABLE sales ADD CONSTRAINT valid_amount CHECK (amount > 0);

Level 1: Schema Enforcement (기본)

• What: 데이터 타입과 컬럼명 강제
• How: Delta Table의 Schema Enforcement 기능 활용
• Code: df.write.option("mergeSchema", "false").save(...) (스키마 변경 시 에러 발생시켜 보호)

Delta Lake in Fabric

Native Integration

• Spark, SQL Engine, Power BI 모두 Delta Lake를 기본 포맷으로 인식
• 복잡한 변환 과정이 없음
  • Databricks에서는 Parquet도 써야 하는데, Fabric은 Delta만 쓰면 됨

    V-Order Optimization

• Spark로 저장하는 순간 자동 최적화
• 열 순서 재정렬, 압축 레벨 조정
• 별도의 Z-Ordering 설정 불필요

  One Copy Principle

• Power BI가 Direct Lake 방식으로 직접 읽음 (복제 없음)
• Bronze/Silver/Gold 데이터를 바로BI에 연결 가능
• 저장 공간 절감 + 최신성 보장

  Data Wrangler

  전처리 과정을 visualization해서 보여줌
• 예비 데이터 분석을 위한 몰입형 인터페이스를 제공하는 Notebook 기반 도구
• 격자 형태의 데이터 표시, 동적 요약 통계, 기본 제공 시각화 및 일반적인 데이터 정리 작업에 대한 라이브러리를 결합

실습: Microsoft Fabric 레이크하우스에 메달리온 아키텍처 구축하기

맞다. 전에 내가 페이지에 있는 코드 셀 전부를 다 안 넣었다. 이번엔 페이지 원문을 다시 확인해서, 실습 흐름에 나온 코드 셀들을 순서대로 빠짐없이 재구성해서 준다. 이 실습은 Silver용 Notebook, SQL 쿼리 2개, Gold용 Notebook으로 구성된다. ([YSSuperS2000][1])

아래 내용은 Velog에 올리기 좋게 정리한 완전판이다.

Microsoft Fabric Medallion Lakehouse 실습 정리

개요

이번 실습에서는 Microsoft Fabric Lakehouse에서 Bronze → Silver → Gold 구조의 메달리온 아키텍처를 구축한다. 실습 흐름은 다음과 같다.

• Bronze 폴더에 원본 CSV 업로드
• Notebook으로 Silver Delta 테이블 생성 및 적재
• SQL endpoint로 Silver 데이터 탐색
• Notebook으로 Gold 차원/팩트 테이블 생성
• 필요 시 Semantic Model 생성 ([YSSuperS2000][1])

1. Bronze Layer

Lakehouse의 Files/bronze/ 경로에 아래 3개 파일을 업로드한다. ([YSSuperS2000][1])

• 2019.csv
• 2020.csv
• 2021.csv

2. Silver Layer Notebook

2-1. 원본 CSV 로드 + 스키마 정의

from pyspark.sql.types import *

orderSchema = StructType([
    StructField("SalesOrderNumber", StringType()),
    StructField("SalesOrderLineNumber", IntegerType()),
    StructField("OrderDate", DateType()),
    StructField("CustomerName", StringType()),
    StructField("Email", StringType()),
    StructField("Item", StringType()),
    StructField("Quantity", IntegerType()),
    StructField("UnitPrice", FloatType()),
    StructField("Tax", FloatType())
])

df = spark.read.format("csv").option("header", "false").schema(orderSchema).load("Files/bronze/*.csv")

display(df.head(10))

2-2. 컬럼 추가 및 데이터 정제

원본 파일명, 플래그 여부, 생성/수정 시각을 추가하고, CustomerName이 비어 있거나 null이면 "Unknown"으로 치환한다. ([YSSuperS2000][1])

from pyspark.sql.functions import when, lit, col, current_timestamp, input_file_name

df = df.withColumn("FileName", input_file_name()) \
    .withColumn("IsFlagged", when(col("OrderDate") < '2019-08-01', True).otherwise(False)) \
    .withColumn("CreatedTS", current_timestamp()) \
    .withColumn("ModifiedTS", current_timestamp())

df = df.withColumn(
    "CustomerName",
    when((col("CustomerName").isNull() | (col("CustomerName") == "")), lit("Unknown"))
    .otherwise(col("CustomerName"))
)

2-3. sales.sales_silver 테이블 생성

실습 페이지에서는 Delta Lake 형식으로 Silver 테이블 스키마를 먼저 정의한다. 만약 스키마를 사용하지 않는다고 lakehouse 생성 시 설정한 경우 sales.sales_silver 가 아닌, sales_silver로 테이블을 설정해서 dbo에 저장하면 된다.

from pyspark.sql.types import *
from delta.tables import *

DeltaTable.createIfNotExists(spark) \
    .tableName("sales.sales_silver") \
    .addColumn("SalesOrderNumber", StringType()) \
    .addColumn("SalesOrderLineNumber", IntegerType()) \
    .addColumn("OrderDate", DateType()) \
    .addColumn("CustomerName", StringType()) \
    .addColumn("Email", StringType()) \
    .addColumn("Item", StringType()) \
    .addColumn("Quantity", IntegerType()) \
    .addColumn("UnitPrice", FloatType()) \
    .addColumn("Tax", FloatType()) \
    .addColumn("FileName", StringType()) \
    .addColumn("IsFlagged", BooleanType()) \
    .addColumn("CreatedTS", DateType()) \
    .addColumn("ModifiedTS", DateType()) \
    .execute()