Microsoft DP-300 기반 Azure SQL Database 인증 및 권한 관리 실습 정리 Azure SQL Database에서 Microsoft Entra ID 기반 인증과 사용자·역할·권한 관리를 실습한다.

1. 실습 개요

시나리오

AdventureWorks 환경의 보안을 담당하는 DBA 역할로, Azure SQL Database에 Microsoft Entra ID 기반 인증을 구성하고 최소 권한 원칙(Least Privilege)을 적용한다.

• Azure SQL Database에 Entra Admin 지정
• Microsoft Entra MFA 인증으로 SSMS 접속
• Contained User 생성
• 사용자 정의 Role 생성
• Stored Procedure 실행 권한 부여
• EXECUTE AS USER를 이용한 권한 테스트

2. 핵심 개념 정리

Microsoft Entra ID

기존 Azure AD(Azure Active Directory)의 새로운 이름이다. Azure SQL Database의 인증 백엔드로 사용할 수 있으며 MFA, 조건부 액세스 등을 적용할 수 있다.

Entra Admin

Azure SQL Logical Server 단위로 지정되는 관리자 계정이다. 해당 사용자는 서버 내 데이터베이스에 대한 최고 수준 권한을 가진다.

Contained User

Master DB 로그인 없이 특정 데이터베이스 내부에서만 인증되는 사용자이다.

CREATE USER [username] WITH PASSWORD = 'password';

이 방식은 데이터베이스 이동성을 높인다.

Database Role

권한을 묶어서 관리하기 위한 역할(Role)이다.

CREATE ROLE RoleName;
ALTER ROLE RoleName ADD MEMBER UserName;

EXECUTE AS USER

현재 세션의 실행 컨텍스트를 특정 사용자로 변경하여 권한을 테스트한다.

EXECUTE AS USER = 'UserName'

원래 권한으로 돌아갈 때는 다음을 사용한다.

REVERT;

3. 실습 환경 준비

준비물

• Azure SQL Logical Server
• AdventureWorksLT 샘플 데이터베이스
• SSMS 또는 Azure Data Studio
• Microsoft Entra 계정

AdventureWorksLT 샘플 DB 생성 시:

• 워크로드 환경: 개발
• 샘플 데이터 사용: AdventureWorksLT

선택하여 생성한다.

4. Microsoft Entra Admin 구성

Azure Portal에서 관리자 지정

절차

1. Azure Portal 접속
2. All resources 선택
3. SQL Server 선택
4. 구성되지 않음 클릭
5. Microsoft Entra ID 사용자 검색
6. 사용자 선택 후 Save

이 과정을 통해 해당 계정이 Azure SQL Server의 Entra Admin이 된다.

5. SSMS에서 Microsoft Entra MFA 인증 연결

서버 이름 복사

Azure Portal → SQL Server → Overview 에서 서버 이름 복사

예시:

myserver.database.windows.net

SSMS 연결

인증 방식 설정

SSMS에서:

• Connect → Database Engine

• Server name 입력

• Authentication:

  • Microsoft Entra MFA
  • 또는 Azure Active Directory - Universal with MFA

선택

방화벽 이슈

처음 접속 시 클라이언트 IP를 방화벽에 추가해야 할 수 있다.

SSMS가 자동으로 추가 기능을 제공하기도 한다.

6. 데이터베이스 사용자 생성

AdventureWorksLT 데이터베이스에서 새 쿼리를 생성한다.

사용자 생성

CREATE USER [DP300User1] WITH PASSWORD = 'Azur3Pa$$';
GO

CREATE USER [DP300User2] WITH PASSWORD = 'Azur3Pa$$';
GO

이 사용자들은 AdventureWorksLT 데이터베이스 범위(scope) 안에서만 동작한다.

7. 사용자 정의 Role 생성

Role 생성

CREATE ROLE [SalesReader];
GO

사용자 추가

ALTER ROLE [SalesReader] ADD MEMBER [DP300User1];
GO

ALTER ROLE [SalesReader] ADD MEMBER [DP300User2];
GO

8. Stored Procedure 생성

DemoProc 생성

CREATE OR ALTER PROCEDURE SalesLT.DemoProc
AS
SELECT
    P.Name,
    SUM(SOD.LineTotal) AS TotalSales,
    SOH.OrderDate
FROM SalesLT.Product P
INNER JOIN SalesLT.SalesOrderDetail SOD
    ON SOD.ProductID = P.ProductID
INNER JOIN SalesLT.SalesOrderHeader SOH
    ON SOH.SalesOrderID = SOD.SalesOrderID
GROUP BY P.Name, SOH.OrderDate
ORDER BY TotalSales DESC
GO

이 프로시저는 상품별 매출 데이터를 조회한다.

9. 권한 테스트

EXECUTE AS USER 실행

EXECUTE AS USER = 'DP300User1'
EXECUTE SalesLT.DemoProc

실행 시 권한 오류가 발생한다.

The EXECUTE permission was denied on the object 'DemoProc'

왜냐하면 SalesReader 역할에는 아직 아무 권한도 없기 때문이다.

10. EXECUTE 권한 부여

권한 추가

REVERT;

GRANT EXECUTE ON SCHEMA::SalesLT TO [SalesReader];
GO

• REVERT

  • 원래 권한 컨텍스트로 복귀

• GRANT EXECUTE

  • SalesLT 스키마 내 프로시저 실행 권한 부여

11. 다시 실행

EXECUTE AS USER = 'DP300User1'
EXECUTE SalesLT.DemoProc

이번에는 정상적으로 결과가 반환된다.

12. 핵심 심화 개념 - Ownership Chain

이번 실습에서 가장 중요한 개념이다.

왜 EXECUTE 권한만 줬는데 SELECT가 되었을까?

DP300User1에게는 다음 테이블에 대한 SELECT 권한이 없다.

• SalesLT.Product
• SalesLT.SalesOrderDetail
• SalesLT.SalesOrderHeader

그런데도 Stored Procedure는 정상 동작했다.

이유는 SQL Server의 Ownership Chain(소유권 체인) 때문이다.

Ownership Chain 원리

SQL Server는 Stored Procedure 실행 시:

1. 프로시저 자체의 EXECUTE 권한만 검사
2. 내부 객체들이 동일한 owner이면
3. 내부 SELECT 권한 검사를 생략

즉:

사용자
→ 프로시저 실행 권한 검사
→ 내부 테이블 권한 검사 생략
→ 실행 성공

이번 실습에서 체인이 유지된 이유

다음 객체들의 owner가 모두 dbo이다.

• SalesLT.DemoProc
• SalesLT.Product
• SalesLT.SalesOrderDetail
• SalesLT.SalesOrderHeader

따라서 Ownership Chain이 끊기지 않는다.

13. 운영 관점에서 중요한 점

Ownership Chain은 운영 환경에서 매우 많이 사용된다.

대표 패턴:

사용자에게 테이블 직접 권한은 주지 않음
↓
Stored Procedure 실행만 허용
↓
프로시저 내부에서 데이터 접근

이 방식의 장점:

• 최소 권한 원칙 적용 가능
• 테이블 직접 접근 차단 가능
• API 형태의 DB 접근 구조 구현 가능

하지만 주의할 점

권한이 강력한 만큼 위험성도 존재한다.

특히:

• 프로시저 내부에서 민감 컬럼 노출 가능
• 동적 SQL 사용 시 Ownership Chain 깨질 수 있음

운영 환경 권장 사항:

• 스키마 owner 표준화
• WITH EXECUTE AS OWNER 사용
• 정기 권한 감사 수행

14. 실습 검증 체크리스트

다음 항목이 모두 성공하면 실습 완료이다.

• Entra ID 관리자가 서버에 지정됨
• DP300User1 / DP300User2 생성 완료
• SalesReader Role 생성 완료
• 권한 부여 전 EXECUTE 실패 확인
• GRANT EXECUTE 후 실행 성공 확인

15. 정리(Clean-up)

실습 종료 후 삭제 가능:

DROP USER DP300User1;
DROP USER DP300User2;
DROP ROLE SalesReader;

운영 환경에서는 Entra Admin을 개인 계정보다는 보안 그룹 기반으로 관리하는 것이 일반적이다.

마무리

• Microsoft Entra ID 인증
• MFA 기반 SSMS 연결
• Contained User 생성
• Database Role 기반 권한 관리
• Stored Procedure 실행 권한
• EXECUTE AS USER 권한 테스트
• Ownership Chain 동작 원리

Azure SQL Database Hands-on - Microsoft Defender for SQL 활성화 및 데이터 분류

Azure SQL Database에서 Microsoft Defender for SQL을 활성화하고, 데이터 분류(Data Discovery & Classification), 취약성 평가(VA), Threat Detection, Auditing, Dynamic Data Masking까지 실습한다.

1. 실습 개요

시나리오

• Microsoft Defender for SQL 활성화
• 민감 정보 자동 분류
• Vulnerability Assessment(VA)
• Threat Detection 알림
• SQL Auditing
• Dynamic Data Masking(DDM)

발견 → 경고 → 추적 → 보호

2. 핵심 개념 정리

Microsoft Defender for SQL

Azure SQL Database의 보안 기능이다.

주요 기능:

• SQL Injection 탐지
• 이상 로그인 탐지
• Brute-force 탐지
• Vulnerability Assessment(VA)
• Threat Detection

등을 제공한다.

Data Discovery & Classification

DB 내부 컬럼을 스캔하여:

• 이메일
• 전화번호
• 개인정보
• 금융정보

같은 민감 데이터를 자동 식별하고 분류(Label)를 부여한다.

Vulnerability Assessment(VA)

보안 취약점을 자동 분석하는 기능이다.

예시:

• 과도한 권한
• 위험한 설정
• 오래된 구성
• 감사 미설정

등을 탐지한다.

SQL Auditing

데이터베이스 내부 이벤트를 기록하는 기능이다.

저장 위치:

• Storage Account
• Log Analytics
• Event Hub

등으로 전송 가능하다.

Dynamic Data Masking(DDM)

실제 데이터를 변경하지 않고:

조회 결과만 가려서 표시

하는 기능이다.

예시:

test@example.com
↓
tXXX@XXXX.com

3. Microsoft Defender for SQL 활성화

Azure Portal 접속

1. Azure Portal 접속
2. SQL servers 검색
3. 대상 SQL Server 선택

Defender 활성화

경로:

SQL Server
→ Security
→ Microsoft Defender for Cloud

이후:

사용(Enable)

클릭

토글 확인

Configure 진입 후:

MICROSOFT DEFENDER FOR SQL = ON

상태인지 확인한다.

4. Data Discovery & Classification

데이터 분류 기능 진입

경로:

AdventureWorksLT
→ Security
→ Data Discovery & Classification

자동 분류 추천 수락

포털에서 다음 메시지가 표시된다.

15개의 열에서 민감 정보 발견

이후:

• Select All
• Accept selected recommendations
• Save

를 실행한다.

결과

총:

• 5개 테이블
• 15개 컬럼

이 자동 분류된다.

5. Vulnerability Assessment(VA)

목적

보안 취약점을 자동 스캔한다.

예시:

• 약한 설정
• 과도 권한
• 감사 미설정
• 공개 접근

등을 탐지한다.

실습 흐름

1. Defender for SQL 활성화
2. VA 실행
3. Findings 확인
4. 일부 Remediation 수행
5. Passed 상태 확인

6. Threat Detection 알림 시뮬레이션

목적

실제 보안 알림 흐름을 테스트한다.

이메일 알림 설정

Defender for Cloud 설정에서:

• 이메일 주소 등록
• 알림 유형 선택

후 저장한다.

Brute-force 시뮬레이션

SSMS에서:

잘못된 비밀번호로 4~5회 로그인

시도

SQL Injection 패턴 시뮬레이션

EXEC sp_executesql
N'SELECT * FROM sys.databases WHERE name = ''anything'' OR 1=1';
GO

또는:

DECLARE @sql NVARCHAR(MAX) =
N'SELECT * FROM sys.tables WHERE name LIKE ''%'' OR 1=1';

EXEC (@sql);

이후 Defender for Cloud의:

Security alerts

에서 알림을 확인한다.

예시:

• Brute force attack
• Potential SQL injection

7. 민감도 분류 메타데이터 확인

시스템 카탈로그 조회

분류 정보는:

sys.sensitivity_classifications

에 저장된다.

조회 쿼리

SELECT 
    SCHEMA_NAME(o.schema_id) AS [schema],
    o.name AS [table],
    c.name AS [column],
    sc.label,
    sc.information_type,
    sc.rank_desc
FROM sys.sensitivity_classifications sc
INNER JOIN sys.objects o
    ON sc.major_id = o.object_id
INNER JOIN sys.columns c
    ON sc.major_id = c.object_id
   AND sc.minor_id = c.column_id
ORDER BY [schema], [table], [column];

수동 분류 추가

ADD SENSITIVITY CLASSIFICATION TO
    SalesLT.Customer.MiddleName
WITH (
    LABEL = 'Confidential',
    LABEL_ID = '332211aa-bbcc-ddee-ff00-112233445566',
    INFORMATION_TYPE = 'Name',
    INFORMATION_TYPE_ID = '5b56518b-5a91-490b-9300-983344497a82',
    RANK = MEDIUM
);

결과 확인

기존:

15개 컬럼

↓

추가 후:

16개 컬럼

으로 증가한다.

8. SQL Auditing + Log Analytics

목적

민감 데이터 접근 이력을 추적한다.

Auditing 활성화

경로:

AdventureWorksLT
→ Auditing
→ Enable Azure SQL Auditing

이후:

• Log Analytics 연결
• Diagnostic Settings 추가

를 수행한다.

감사 이벤트 발생

SELECT TOP 10
    EmailAddress,
    FirstName,
    LastName
FROM SalesLT.Customer;
GO

KQL 조회

AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| take 10

핵심 포인트

감사 로그 내부에:

data_sensitivity_information_s

필드가 자동 포함된다.

즉:

누가 민감 데이터를 조회했는가

를 추적할 수 있다.

9. Dynamic Data Masking(DDM)

목적

민감 데이터를 일반 사용자에게 숨긴다.

마스킹 규칙 추가

Email 마스킹

ALTER TABLE SalesLT.Customer
    ALTER COLUMN EmailAddress
    ADD MASKED WITH (FUNCTION = 'email()');
GO

Phone 마스킹

ALTER TABLE SalesLT.Customer
    ALTER COLUMN Phone
    ADD MASKED WITH (
        FUNCTION = 'partial(0,"XXX-XXX-",4)'
    );
GO

10. 일반 사용자 관점 테스트

EXECUTE AS USER

EXECUTE AS USER = 'DP300User1';

SELECT TOP 5
    FirstName,
    LastName,
    EmailAddress,
    Phone
FROM SalesLT.Customer;

REVERT;

결과

일반 사용자는:

aXXX@XXXX.com
XXX-XXX-1234

형태로 보인다.

11. UNMASK 권한 부여

권한 추가

GRANT UNMASK TO DP300User1;

다시 조회

EXECUTE AS USER = 'DP300User1';

SELECT TOP 5
    EmailAddress,
    Phone
FROM SalesLT.Customer;

REVERT;

이번에는 실제 원본 데이터가 보인다.

원상 복구

REVOKE UNMASK FROM DP300User1;

ALTER TABLE SalesLT.Customer
    ALTER COLUMN EmailAddress DROP MASKED;

ALTER TABLE SalesLT.Customer
    ALTER COLUMN Phone DROP MASKED;

12. 실무적으로 중요한 포인트

DDM의 한계

DDM은:

표시값만 가리는 기능

이다.

즉:

• 실제 데이터는 그대로 존재
• 관리자 권한자는 원본 조회 가능

하다.

실제 운영에서는

다음 조합으로 다층 방어를 구성한다.

Classification
→ DDM
→ TDE / Always Encrypted
→ RLS(Row-Level Security)

13. 실습 검증 체크리스트

다음 항목이 모두 성공하면 실습 완료이다.

• Defender for SQL 활성화
• 15개 컬럼 자동 분류
• VA Findings 확인
• Threat Detection 알림 확인
• sys.sensitivity_classifications 증가 확인
• SQLSecurityAuditEvents 수집 확인
• DDM 마스킹 동작 확인
• UNMASK 후 원본 노출 확인

14. 정리(Clean-up)

실습 종료 후:

• DROP MASKED
• REVOKE UNMASK
• 추가 분류 제거
• Log Analytics 삭제
• VA Storage 삭제

등을 수행할 수 있다.

마무리

이번 실습에서는 Azure SQL Database 보안 기능 전반을 실습했다.

Defender 활성화
→ 민감 데이터 발견
→ Threat Detection
→ 감사 로그 수집
→ Dynamic Data Masking 보호

발견 → 탐지 → 감사 → 보호

Azure SQL Database Hands-on - CPU 사용률 식별 및 경고

Azure Monitor를 활용하여 Azure SQL Database의 CPU 사용률을 모니터링하고, 평균 CPU 사용량이 80%를 초과할 경우 이메일 알림을 전송하는 Alert Rule을 구성한다.

1. 실습 개요

시나리오

AdventureWorksLT 데이터베이스의 평균 CPU 사용률이 80%를 초과하면 자동으로 이메일 경고를 전송하도록 Azure Monitor Alert를 구성한다.

이번 실습에서는:

• CPU percentage 메트릭 기반 경고 생성
• Alert Rule 구성
• Action Group 생성
• 이메일 알림 설정
• 실제 CPU 부하 테스트

까지 수행한다.

2. 핵심 개념 정리

Azure Monitor Alert Rule

Azure 리소스의 메트릭 또는 로그를 주기적으로 평가하여:

조건 충족 시 자동 작업(Action) 실행

하는 기능이다.

구성 요소:

• Signal
• Condition
• Action Group

으로 이루어진다.

CPU percentage

Azure SQL Database의 평균 CPU 사용률 메트릭이다.

기본적으로:

1분 단위 집계

가 사용된다.

Aggregation Type

메트릭 집계 방식이다.

대표 유형:

• Average
• Minimum
• Maximum
• Total

이번 실습에서는:

Average

를 사용한다.

Action Group

경고 발생 시 수행할 작업 묶음이다.

예시:

• Email
• SMS
• Push
• Voice
• Webhook
• Azure Function

등을 연결할 수 있다.

3. 실습 환경 준비

준비물

• AdventureWorksLT 데이터베이스
• Azure Portal 접근 권한
• 이메일 수신 가능 계정

4. Azure Monitor Alert 생성

Alerts 메뉴 진입

경로:

AdventureWorksLT
→ Monitoring
→ Alerts

이후:

+ Create alert rule

선택

5. CPU Signal 설정

Signal 선택

CPU percentage

선택

조건 설정

다음과 같이 설정한다.

즉:

평균 CPU 사용률 > 80%

조건이 되면 경고가 발생한다.

6. Action Group 생성

Actions 탭 이동

Alert Rule 생성 화면에서:

Actions
→ Create action group

선택

기본 정보 입력

입력 후:

Next: Notifications

선택

7. 이메일 알림 설정

Notifications 설정

다음과 같이 입력한다.

이후 이메일 주소 입력

생성 완료

Review + create
→ Create

를 눌러 Alert Rule과 Action Group을 생성한다.

8. 이메일 알림 확인

구성이 완료되면:

You've been added to an Azure Monitor action group

형태의 이메일을 수신할 수 있다.

이후 실제 CPU 사용량이 80%를 초과하면 Azure Monitor Alert 메일이 전송된다.

9. 실제 CPU 부하 발생 테스트

실습 문서에서는 CPU 부하를 강제로 발생시키기 위한 쿼리를 제공한다.

대량 카테시안 곱 쿼리

SELECT
    COUNT(*) AS TotalCount,
    SUM(CAST(ABS(CHECKSUM(NEWID())) AS FLOAT)) AS RandomSum
FROM SalesLT.SalesOrderDetail a
CROSS JOIN SalesLT.SalesOrderDetail b
CROSS JOIN SalesLT.SalesOrderDetail c
WHERE
    SQRT(POWER(a.UnitPrice, 2) + POWER(b.UnitPrice, 2)) > 100
    AND a.OrderQty * b.OrderQty * c.OrderQty > 0;

왜 CPU 사용률이 높아질까?

이 쿼리는:

• CROSS JOIN
• 수학 연산
• 문자열/랜덤 함수

를 동시에 수행한다.

특히:

N × N × N

형태의 카테시안 곱이 발생하므로 CPU 부하가 매우 커진다.

10. CPU 지속 사용 루프

루프 기반 CPU 사용

DECLARE @StartTime DATETIME = GETDATE();
DECLARE @EndTime DATETIME = DATEADD(SECOND, 60, @StartTime);
DECLARE @Dummy FLOAT;

WHILE GETDATE() < @EndTime
BEGIN
    SET @Dummy =
        SQRT(PI() * RAND()) * POWER(RAND(), 2);
END;

특징

약 1분 동안 지속적으로 CPU를 사용한다.

특징:

• 반복 수학 연산
• 랜덤 함수 호출
• 지속 루프 실행

으로 인해 CPU 사용률을 강제로 상승시킨다.

11. 실습 검증

다음 항목이 모두 성공하면 실습 완료이다.

• AdventureWorksLT > Alerts에 새 규칙 생성
• Action Group(emailgroup) 생성
• Notification(DemoLab) 생성
• 이메일 수신 확인

12. 운영 관점에서 중요한 포인트

Evaluation Frequency

경고 평가 주기이다.

예시:

• 1분
• 5분

주기를 사용할 수 있다.

짧을수록 민감하지만 비용과 false positive가 증가한다.

Static vs Dynamic Threshold

Static

CPU > 80%

처럼 고정값 사용

Dynamic

Azure가 과거 패턴을 학습하여 자동 임계값을 계산한다.

트래픽 변동성이 큰 시스템에서는 Dynamic Threshold가 false positive를 줄여준다.

13. 실무에서 자주 사용하는 패턴

운영 환경에서는 보통:

형태로 Action Group을 분리해 관리한다.

예시:

cpu-sev0-email
cpu-sev1-teams
cpu-sev2-monitoring

같은 형태로 표준화한다.

14. 정리(Clean-up)

실습 종료 후 비용 절약을 위해:

• Alert Rule 삭제
• Action Group 삭제

를 수행할 수 있다.

마무리

이번 실습에서는 Azure SQL Database의 CPU 사용률을 기준으로 Azure Monitor Alert를 구성했다.

핵심 흐름은 다음과 같다.

CPU percentage 메트릭 선택
→ 임계값 설정
→ Action Group 생성
→ 이메일 알림 연결
→ 실제 CPU 부하 테스트

Azure Monitor Alert는 단순 이메일 기능이 아니라:

• 운영 자동화
• 장애 탐지
• 비용 감시
• 성능 이상 탐지

등 Azure 운영 전반의 핵심 기능으로 활용된다.

Azure Architecture Seminar 정리

Azure 아키텍처를 단순 서비스 나열이 아니라 프레임워크 기반으로 설계하는 방법을 다룬 세미나 자료 정리 핵심 주제는 CAF(Cloud Adoption Framework), WAF(Well-Architected Framework), 그리고 Azure Reference Architecture이다.

1. 세미나 핵심 목표

프레임워크 기반으로 아키텍처를 평가하고 설계하는 사고방식

1. WAF·CAF 기반으로 설계 평가
2. 안티패턴 ↔ 대응패턴 구분
3. 실제 Azure Reference Architecture 분석

2. 온프렘과 클라우드의 결정적 차이

세미나에서는 클라우드 아키텍처 사고방식이 온프렘과 근본적으로 다르다고 설명한다.

1) 장애를 가정하고 설계

온프렘

장애가 안 나도록 비싸게 설계

Azure

장애는 반드시 발생한다고 가정

따라서:

• Availability Zone
• Region 분산
• Backup
• Site Recovery

기반으로 설계한다.

2) 비용은 운영 행위

온프렘은:

CapEx

중심

클라우드는:

OpEx

중심이다.

즉:

• 어떤 SKU를 쓰는가
• 언제 끄는가
• 얼마나 자동화하는가

자체가 비용 설계가 된다.

3) 보안은 경계가 아니라 신원

온프렘:

방화벽 중심

Azure:

Zero Trust

즉:

• 누가
• 어떤 신원으로
• 어디서 접근했는가

가 핵심 기준이 된다.

3. CAF vs WAF

이번 세미나의 핵심이다.

CAF (Cloud Adoption Framework)

조직 차원의 프레임워크

CAF는:

회사가 클라우드를 어떻게 도입하는가

를 다룬다.

구성 단계:

1. 전략
2. 계획
3. 준비
4. 도입
5. 거버넌스
6. 관리

즉:

회사 전체의 클라우드 여정

을 정의한다.

WAF (Well-Architected Framework)

워크로드 차원의 프레임워크

WAF는:

이 시스템 하나를 어떻게 잘 만들 것인가

를 평가한다.

즉:

• 웹앱
• 데이터 파이프라인
• AI 서비스

각 워크로드마다 적용된다.

4. WAF 5+1 기둥

Azure WAF는 총 6개 관점으로 시스템을 평가한다.

5. 왜 프레임워크가 필요한가

프레임워크 없이 설계하면:

• 사람마다 기준이 다름
• 비용·보안·성능 트레이드오프 추적 불가
• 시간이 지나면 왜 그렇게 설계했는지 잊어버림

반대로 프레임워크를 사용하면:

• 공통 언어 생성
• 체크리스트 기반 리뷰 가능
• 트레이드오프 기록 가능
• 자기 진단 가능

해진다.

6. WAF 기둥별 핵심 패턴

Reliability (신뢰성)

안티패턴

• 단일 리전
• 단일 VM
• 복구 테스트 없음
• 단일 Load Balancer

대응 패턴

• Availability Zone 분산
• Geo-redundant
• Backup + ASR
• Front Door 멀티리전

관련 Azure 서비스

• Azure Backup
• Site Recovery
• Front Door
• SQL Geo-replication

Security (보안)

안티패턴

• IP 기반 신뢰
• Secret 하드코딩
• Owner 권한 남발

대응 패턴

• Zero Trust
• Managed Identity
• Key Vault
• RBAC 최소 권한
• PIM

관련 Azure 서비스

• Entra ID
• Managed Identity
• Key Vault
• Defender for Cloud
• Private Endpoint

Cost Optimization (비용 최적화)

안티패턴

• 모든 리소스 Pay-as-you-go
• Dev/Test 24시간 켜둠
• 과도한 SKU

대응 패턴

• Reservation
• Savings Plan
• Spot VM
• Auto-shutdown
• Cost Alert

Operational Excellence (운영 우수성)

안티패턴

• 포털 클릭 기반 운영
• 수동 배포
• 로그 분산

대응 패턴

• Terraform / Bicep IaC
• GitHub Actions
• Canary / Blue-Green 배포
• Log Analytics 중앙화

Performance Efficiency (성능 효율성)

안티패턴

• 모든 요청이 DB로 직행
• 수직 확장만 사용
• 앱 서버가 정적 자산 직접 제공

대응 패턴

• Redis Cache
• Read Replica
• Autoscale
• CDN
• Front Door

Sustainability (지속가능성)

안티패턴

• 탄소 효율 고려 없는 리전 선택
• 낮은 사용률 VM 유지
• 피크 시간대 배치

대응 패턴

• Right-sizing
• 유휴 리소스 자동 정리
• 탄소 인지 스케줄링

7. 가장 중요한 개념 — 트레이드오프

세미나에서 가장 강조하는 부분이다.

모든 기둥을 동시에 완벽하게 만족하는 아키텍처는 없다

예시:

즉:

좋은 아키텍처란
어떤 기둥을 왜 양보했는지 설명할 수 있는 아키텍처

이다.

8. 레퍼런스 아키텍처 1 — 표준 웹 애플리케이션

구조

Front Door
→ App Service
→ Azure SQL

보조 구성:

• Key Vault
• Managed Identity
• App Insights
• Blob + CDN

핵심 의사결정

App Service vs AKS

• 단순 웹앱 → App Service
• 복잡한 컨테이너 운영 → AKS

Active-Active vs Active-Passive

• 낮은 RTO/RPO → Active-Active
• 비용 절감 → Active-Passive

SQL vs Cosmos DB

• 트랜잭션 중심 → Azure SQL
• 글로벌 분산 중심 → Cosmos DB

9. 레퍼런스 아키텍처 2 — 데이터 파이프라인

Medallion Architecture

구조:

Bronze
→ Silver
→ Gold

흐름:

Event Hubs
→ ADLS Gen2
→ Databricks
→ Synapse
→ Power BI

핵심 개념

Bronze

원본 보존

Silver

정제·검증

Gold

비즈니스 집계

왜 Medallion을 쓰는가

• 원본 보존 가능
• 재처리 용이
• 데이터 품질 추적 가능
• 계층별 책임 분리

10. 레퍼런스 아키텍처 3 — AI 추론 / RAG

구조

Container Apps
→ Azure OpenAI
→ AI Search
→ Cosmos DB

보조 서비스:

• Front Door
• Content Safety
• Blob Storage
• App Insights

RAG 흐름

1. 질문 임베딩
2. AI Search 벡터 검색
3. 관련 문서 검색
4. GPT 응답 생성
5. Content Safety 필터링
6. 대화 저장

11. AI 아키텍처 핵심 의사결정

PTU vs PAYG

PTU

• 일정한 트래픽
• 낮은 지연 요구

PAYG

• 초기 구축
• 변동 트래픽

Container Apps vs AKS

Container Apps

• 서버리스
• 빠른 자동 스케일

AKS

• 복잡한 운영
• 세밀한 네트워크 제어

AI Search vs Cosmos vs PostgreSQL

12. 세 가지 아키텍처 비교

가장 큰 위험 요소

13. WAF 자체 평가 체크리스트

세미나 마지막에는 자신의 시스템을 WAF 기준으로 평가한다.

14. 핵심 결론

이번 세미나의 핵심 메시지는 다음 한 문장으로 정리된다.

좋은 아키텍처는
완벽한 아키텍처가 아니라,
어떤 기둥을 왜 양보했는지 설명할 수 있는 아키텍처

그리고 WAF는:

서비스를 외우기 위한 프레임워크가 아니라,
좋은 질문을 하기 위한 프레임워크

이다.

2. PostgreSQL 16 설치 및 초기화

• Ubuntu 24.04 기본 저장소에서 PostgreSQL 16을 apt로 설치하고 systemd로 관리한다.

• 운영용 사용자(handson)와 데이터베이스(onestore)를 생성하고, .pgpass로 비밀번호 입력을 자동화한다.
• 보안 기본값을 적용한다 (외부 네트워크 차단, scram-sha-256 인증).
• B2ms 8GB 환경에 맞는 메모리 튜닝을 적용한다.

개념 설명: cluster / database / role

┌──────────────────────────────────────────────────────────┐ │ Linux user "azureuser" (나) │ │ │ │ ① Unix 소켓 접속: sudo -u postgres psql │ │ → peer 인증 (Linux user == PG role 매칭) │ │ → 슈퍼유저 postgres로 진입, 관리용 │ │ │ │ ② TCP 접속 127.0.0.1:5432: │ │ psql -h 127.0.0.1 -U handson -d onestore │ │ → scram-sha-256 (비밀번호) │ │ → 운영 DB 작업용 │ └──────────────────────────────────────────────────────────┘

개념 설명: 메모리 튜닝 룰 오브 썸

PostgreSQL 16 설치

sudo apt update
sudo apt install -y postgresql-16 postgresql-client-16 postgresql-contrib-16

psql --version
sudo systemctl status postgresql --no-pager

슈퍼유저 진입 및 운영 사용자/DB 생성

-- 운영 사용자 생성 (비밀번호는 학습용. 운영 시엔 강력한 값으로)
CREATE ROLE handson WITH LOGIN PASSWORD '비밀번호';

-- 운영 DB 생성 (소유자 handson)
CREATE DATABASE onestore OWNER handson ENCODING 'UTF8';

-- 추가 권한 (DB 안 모든 객체에 대한 풀권한)
GRANT ALL PRIVILEGES ON DATABASE onestore TO handson;

\l onestore
\du handson
\q

TCP 접속 테스트

psql -h 127.0.0.1 -U handson -d onestore -c "SELECT current_user, current_database(), version();"
# 비밀번호 프롬프트 → handson_pw_2026

.pgpass로 비밀번호 자동화

cat > ~/.pgpass << 'EOF'
127.0.0.1:5432:onestore:handson:비밀번호
127.0.0.1:5432:*:handson:비밀번호
EOF

chmod 600 ~/.pgpass
ls -l ~/.pgpass

# 비번 입력 없이 접속되는지 확인
psql -h 127.0.0.1 -U handson -d onestore -c "SELECT 'pgpass works' AS status;"

환경변수로 접속 정보 설정

grep -q "PGUSER=handson" ~/.bashrc || cat >> ~/.bashrc << 'EOF'

# === PostgreSQL 접속 (Part 3) ===
export PGHOST=127.0.0.1
export PGPORT=5432
export PGDATABASE=onestore
export PGUSER=handson
# 비밀번호는 .pgpass가 처리 (PGPASSWORD 환경변수 사용 X — ps에 노출됨)
EOF

source ~/.bashrc

# 환경변수 만으로 psql 접속되는지 확인
psql -c "SELECT current_user, current_database();"

메모리 튜닝(postgresql.conf)

# 백업 (필수)
sudo cp /etc/postgresql/16/main/postgresql.conf \
        /etc/postgresql/16/main/postgresql.conf.original

# 사용자 정의 설정을 별도 파일로
sudo tee /etc/postgresql/16/main/conf.d/99-handson.conf > /dev/null << 'EOF'
# === Handson Part 3 메모리 튜닝 (B2ms 8GB) ===
# PG 할당 예산 ~1.2GB

shared_buffers = 768MB
work_mem = 16MB
maintenance_work_mem = 128MB
effective_cache_size = 2GB
max_connections = 20

# WAL / 체크포인트 (학습 환경 안정성)
wal_buffers = 16MB
checkpoint_completion_target = 0.9
min_wal_size = 80MB
max_wal_size = 1GB

# SSD 가정 (Azure VM은 SSD)
random_page_cost = 1.1

# 로그 (트러블슈팅 편의)
log_min_duration_statement = 1000   # 1초 이상 쿼리 로깅
log_line_prefix = '%t [%p]: user=%u,db=%d,app=%a '
EOF

# include_dir 확인
grep -A1 "^include_dir" /etc/postgresql/16/main/postgresql.conf

# 서비스 재시작
sudo systemctl restart postgresql@16-main

# 적용 확인
psql -c "SHOW shared_buffers; SHOW work_mem; SHOW max_connections;"

psql 기본 사용법

\?              -- psql 명령어 도움말 전체
\h SELECT       -- SELECT SQL 도움말
\l              -- 데이터베이스 목록
\dt             -- 현재 DB의 테이블 목록 (Section 3 후 채워짐)
\d 테이블명      -- 테이블 스키마 상세
\du             -- role 목록
\timing         -- 쿼리 실행 시간 표시 토글
\x              -- 결과 가로/세로 출력 토글
\!              -- 셸 명령 실행 (예: \! ls)
\i 파일.sql      -- SQL 파일 실행
\q              -- 종료

3. 스키마 설계 및 테이블 생성

• 데이터 모델링 결과를 SQL 스크립트로 작성하고 psql -f로 일괄 실행한다.

• PRIMARY KEY / FOREIGN KEY / CHECK / INDEX의 의미와 선택 근거를 이해한다.
• \d 테이블명으로 스키마를 검증한다.

Float이 아닌 Numeric을 쓰는 이유

-- FLOAT 함정
SELECT 0.1::float8 + 0.2::float8;
-- 결과: 0.30000000000000004 (반올림 오차)

-- NUMERIC은 정확
SELECT 0.1::numeric + 0.2::numeric;
-- 결과: 0.3

개념 설명: 인덱스 선택 근거

쿼리 패턴:

-- 1) 특정 고객의 거래 조회
SELECT * FROM transactions_fact WHERE customer_id = 'C001234';
-- 2) 최근 N분간 전체 거래
SELECT * FROM transactions_fact WHERE ts > NOW() - INTERVAL '5 min';
-- 3) 고객별 거래 수 집계
SELECT customer_id, COUNT(*) FROM transactions_fact GROUP BY customer_id;

• customer_id에 인덱스: 1번·3번 가속
• ts에 인덱스: 2번 가속 (시계열 슬라이싱)
• transaction_id는 PK라 자동 인덱스

DDL

cat > ~/spark-handson/sql/init.sql << 'EOF'
-- =====================================================================
-- OneStore Hands-on Part 3 — 초기 스키마
-- 실행: psql -f ~/spark-handson/sql/init.sql
-- 멱등: IF NOT EXISTS 절 사용. 재실행해도 안전.
-- =====================================================================

\set ON_ERROR_STOP on

BEGIN;

-- ----------------------------
-- 1) customers_dim — Part 2 정제본 적재 대상
-- ----------------------------
CREATE TABLE IF NOT EXISTS customers_dim (
    customer_id  VARCHAR(20) PRIMARY KEY,
    age          INT,
    gender       VARCHAR(10),
    country      VARCHAR(10),
    plan_type    VARCHAR(20),
    signup_date  DATE,
    loaded_at    TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

COMMENT ON TABLE customers_dim IS 'Part 2 customers_clean 정제본 적재 (배치 1회)';

-- ----------------------------
-- 2) transactions_fact — 스트리밍 적재 대상
-- ----------------------------
CREATE TABLE IF NOT EXISTS transactions_fact (
    transaction_id  VARCHAR(30) PRIMARY KEY,
    customer_id     VARCHAR(20) NOT NULL
                    REFERENCES customers_dim(customer_id),
    ts              TIMESTAMP NOT NULL,
    amount          NUMERIC(10, 2) CHECK (amount >= 0),
    category        VARCHAR(20),
    status          VARCHAR(20)
                    CHECK (status IN ('COMPLETED','PENDING','FAILED','REFUNDED')),
    ingested_at     TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX IF NOT EXISTS idx_tx_customer ON transactions_fact(customer_id);
CREATE INDEX IF NOT EXISTS idx_tx_ts       ON transactions_fact(ts);

COMMENT ON TABLE transactions_fact IS 'Spark Structured Streaming이 Kafka에서 적재';

-- ----------------------------
-- 3) ml_predictions — 배치 추론 결과
-- ----------------------------
CREATE TABLE IF NOT EXISTS ml_predictions (
    customer_id     VARCHAR(20) PRIMARY KEY
                    REFERENCES customers_dim(customer_id),
    predicted_at    TIMESTAMP NOT NULL,
    churn_proba     NUMERIC(5, 4) CHECK (churn_proba BETWEEN 0 AND 1),
    churn_label     INT CHECK (churn_label IN (0, 1)),
    model_version   VARCHAR(50)
);

CREATE INDEX IF NOT EXISTS idx_pred_at ON ml_predictions(predicted_at);

COMMENT ON TABLE ml_predictions IS 'cron 배치 추론 결과 (UPSERT, 고객당 1행)';

COMMIT;

-- 확인용
\echo ''
\echo '=== 생성된 테이블 ==='
\dt
EOF

ls -l ~/spark-handson/sql/init.sql

#실행
psql -f ~/spark-handson/sql/init.sql

PySpark에서 PostgreSQL 연결 (JDBC)

• PostgreSQL JDBC 드라이버를 PySpark에 통합 (--packages 자동 다운로드 / 수동 jar).

• 안전한 비밀번호 처리 패턴(.pgpass 파싱)을 적용.
• Part 2의 customers_clean Parquet을 customers_dim 테이블에 적재.
• PySpark에서 PostgreSQL 데이터를 다시 읽어 검증하는 양방향 패턴.

--packages vs --jars

┌─────────────────────────────────────────────────────────────┐
│  ① --packages org.postgresql:postgresql:42.7.4              │
│     → Maven Central → ~/.ivy2/cache → 자동 클래스패스        │
│   (장점: 의존성 transitively 해결, 첫 실행 후 캐시됨)          │
│   (단점: 외부 네트워크 필요, 첫 실행 1~3분)                   │
│                                                             │
│  ② --jars /path/to/postgresql-42.7.4.jar                    │
│   (장점: 오프라인 가능, 즉시 시작)                            │
│   (단점: 의존성 수동 관리)                                    │
└─────────────────────────────────────────────────────────────┘

개념 설명: Spark JDBC 적재 동작

PySpark DataFrame (10,000 rows)
        │
        │ .write.format("jdbc").mode("append")
        │   .option("batchsize", 1000)
        ▼
JDBC Driver (postgresql-42.7.4.jar)
        │ INSERT INTO customers_dim VALUES (...) -- 1000행 묶음 × 10
        ▼
PostgreSQL

왜 mode("overwrite")가 위험한가? Spark JDBC overwrite는 기본 DROP TABLE + CREATE TABLE. 우리 customers_dim엔 PK·CHECK·FK 메타데이터가 붙어 DROP하면 다 사라진다. 그래서 append + 멱등성 패턴.

JDBC 드라이버 사전 캐싱

cat > /tmp/cache_jdbc.py << 'PYEOF'
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("cache_jdbc").getOrCreate()
print("PostgreSQL JDBC 드라이버 다운로드 완료")
spark.stop()
PYEOF

spark-submit \
  --packages org.postgresql:postgresql:42.7.4 \
  --conf spark.driver.memory=1g \
  /tmp/cache_jdbc.py 2>&1 | grep -E "(SUCCESSFUL|downloaded|완료|ERROR)"

# 캐시 확인
ls -la ~/.ivy2/jars/ | grep postgresql

적재

cat > ~/spark-handson/jobs/load_customers_dim.py << 'PYEOF'
#!/usr/bin/env python3
"""
load_customers_dim.py
Part 2의 customers_clean Parquet을 PostgreSQL customers_dim 테이블에 적재.
"""
import os
import sys
from pathlib import Path

from pyspark.sql import SparkSession
from pyspark.sql.functions import col


def get_pgpass(host: str, port: str, db: str, user: str) -> str:
    pgpass = Path.home() / ".pgpass"
    if not pgpass.exists():
        sys.exit("ERROR: ~/.pgpass not found. See Section 2 Step 2-4.")
    if oct(pgpass.stat().st_mode)[-3:] != "600":
        sys.exit("ERROR: ~/.pgpass permission must be 600.")
    for line in pgpass.read_text().splitlines():
        if not line or line.startswith("#"):
            continue
        parts = line.split(":")
        if len(parts) != 5:
            continue
        h, p, d, u, pw = parts
        if h in (host, "*") and p in (port, "*") \
           and d in (db, "*") and u in (user, "*"):
            return pw
    sys.exit(f"ERROR: no matching .pgpass entry for {user}@{host}:{port}/{db}")


PG_HOST = os.environ.get("PGHOST", "127.0.0.1")
PG_PORT = os.environ.get("PGPORT", "5432")
PG_DB   = os.environ.get("PGDATABASE", "onestore")
PG_USER = os.environ.get("PGUSER", "handson")
PG_PW   = get_pgpass(PG_HOST, PG_PORT, PG_DB, PG_USER)

JDBC_URL = f"jdbc:postgresql://{PG_HOST}:{PG_PORT}/{PG_DB}"
JDBC_PROPS = {
    "user": PG_USER,
    "password": PG_PW,
    "driver": "org.postgresql.Driver",
}

CUSTOMERS_PARQUET = os.path.expanduser("~/spark-handson/data/customers_clean")


def main():
    spark = (
        SparkSession.builder
        .appName("load_customers_dim")
        .getOrCreate()
    )
    spark.sparkContext.setLogLevel("ERROR")

    print(f"[INFO] reading parquet: {CUSTOMERS_PARQUET}")
    df = spark.read.parquet(CUSTOMERS_PARQUET)

    df_to_load = df.select(
        col("customer_id"),
        col("age").cast("int"),
        col("gender"),
        col("country"),
        col("plan_type"),
        col("signup_date").cast("date"),
    )

    src_count = df_to_load.count()
    print(f"[INFO] source rows: {src_count}")

    existing = (
        spark.read.jdbc(url=JDBC_URL, table="customers_dim",
                        properties=JDBC_PROPS).count()
    )
    print(f"[INFO] customers_dim existing rows: {existing}")

    if existing > 0:
        print("[WARN] customers_dim is not empty. Skipping load.")
        print("       To reload, run reset SQL first:")
        print("       psql -c 'TRUNCATE customers_dim, transactions_fact, ml_predictions CASCADE;'")
        spark.stop()
        return

    print("[INFO] loading into customers_dim ...")
    (
        df_to_load.write
        .format("jdbc")
        .option("url", JDBC_URL)
        .option("dbtable", "customers_dim")
        .option("user", PG_USER)
        .option("password", PG_PW)
        .option("driver", "org.postgresql.Driver")
        .option("batchsize", 1000)
        .mode("append")
        .save()
    )

    loaded = (
        spark.read.jdbc(url=JDBC_URL, table="customers_dim",
                        properties=JDBC_PROPS).count()
    )
    print(f"[OK] loaded rows: {loaded} (expected: {src_count})")

    spark.stop()


if __name__ == "__main__":
    main()
PYEOF

chmod +x ~/spark-handson/jobs/load_customers_dim.py
ls -l ~/spark-handson/jobs/load_customers_dim.py

실행

spark-submit \
  --packages org.postgresql:postgresql:42.7.4 \
  --conf spark.driver.memory=2g \
  ~/spark-handson/jobs/load_customers_dim.py \
  2>&1 | tee ~/spark-handson/logs/load_customers_dim.log | grep -E "INFO|WARN|OK|ERROR"

(선택) 재적재

# 1) 자식 테이블 + customers_dim 모두 비우기 (CASCADE)
psql -c "TRUNCATE customers_dim, transactions_fact, ml_predictions CASCADE;"

# 2) 다시 적재
spark-submit \
  --packages org.postgresql:postgresql:42.7.4 \
  ~/spark-handson/jobs/load_customers_dim.py

Kafka 3.7 단일 노드 설치(KRaft 모드)

• Apache Kafka 3.7을 tarball로 설치하고 /opt/kafka에 배치.

• KRaft(Kafka Raft) 모드로 클러스터 초기화 (ZooKeeper 미사용).
• B2ms 8GB 환경에 맞게 JVM 힙을 1GB로 제한.
• systemd unit으로 등록.
• transactions-raw 토픽 생성 + 콘솔 producer/consumer 검증.

KRaft vs ZooKeeper

┌─── 기존 (ZooKeeper 모드) ───┐    ┌─── KRaft 모드 ───────────┐
│   ┌─────────────┐            │    │   ┌────────────────────┐  │
│   │ ZooKeeper   │  메타데이터  │    │   │ Kafka 프로세스      │  │
│   │ (별도 클러스터) │            │    │   │  ├─ broker        │  │
│   └──────┬──────┘            │    │   │  └─ controller     │  │
│          │                   │    │   │  (메타데이터 = Raft) │  │
│   ┌──────▼──────┐            │    │   └────────────────────┘  │
│   │ Kafka brokers│            │    │                           │
│   └─────────────┘            │    │   프로세스 1개로 끝         │
│   프로세스 2종류 운영 부담       │    │   메모리 절약 + 단순성      │
└──────────────────────────────┘    └───────────────────────────┘

B2ms 8GB에 KRaft가 적합한 이유: ZooKeeper 모드는 별도 JVM(~512MB) 추가. KRaft는 통합 → 메모리·복잡도 절약.

Topic/Partition/Offset

Topic: transactions-raw   (partitions=3)
┌───────────────────────────────────────────────────────────┐
│ Partition 0:  [m0][m1][m2][m3][m4][m5]...                 │
│ Partition 1:  [m0][m1][m2]...                              │
│ Partition 2:  [m0][m1][m2][m3]...                          │
└───────────────────────────────────────────────────────────┘

Producer가 메시지 발행:
  - key 없음 → 라운드로빈/스티키
  - key 있음 → hash(key) % partitions로 같은 key는 같은 파티션 (순서 보장)

Consumer가 메시지 소비:
  - 같은 Consumer Group 안의 consumer들이 파티션 분담
  - Spark Streaming도 내부적으로 Consumer Group 사용

KRaft 단일 노드의 listeners

단일 노드라도 controller listener 필수.

메모리 예산

Kafka는 JVM 힙을 작게 유지하고 OS page cache에 의존. -Xmx1g로도 충분.

tarball 다운로드

mkdir -p ~/dl && cd ~/dl

KAFKA_VER=3.7.0
KAFKA_FILE=kafka_2.13-${KAFKA_VER}.tgz
KAFKA_URL_PRIMARY="https://archive.apache.org/dist/kafka/${KAFKA_VER}/${KAFKA_FILE}"
KAFKA_URL_FALLBACK="https://dlcdn.apache.org/kafka/${KAFKA_VER}/${KAFKA_FILE}"

curl -fLO "$KAFKA_URL_PRIMARY" || curl -fLO "$KAFKA_URL_FALLBACK"

ls -lh ${KAFKA_FILE}
file ${KAFKA_FILE}

압축 해제 + /opt/kafka 배치

cd ~/dl
sudo tar -xzf kafka_2.13-3.7.0.tgz -C /opt/
sudo mv /opt/kafka_2.13-3.7.0 /opt/kafka-3.7.0
sudo ln -sfn /opt/kafka-3.7.0 /opt/kafka
ls -la /opt/ | grep -E "kafka|->"

환경변수 등록

grep -q "KAFKA_HOME" ~/.bashrc || cat >> ~/.bashrc << 'EOF'

# === Kafka (Part 3) ===
export KAFKA_HOME=/opt/kafka
export PATH=$PATH:$KAFKA_HOME/bin
EOF

source ~/.bashrc
echo "KAFKA_HOME=$KAFKA_HOME"
which kafka-topics.sh

데이터, 로그 디렉터리 준비

mkdir -p ~/spark-handson/kafka-data
mkdir -p ~/spark-handson/logs/kafka
ls -ld ~/spark-handson/kafka-data ~/spark-handson/logs/kafka

server.properties 작성

sudo cp /opt/kafka/config/kraft/server.properties \
        /opt/kafka/config/kraft/server.properties.original

sudo tee /opt/kafka/config/kraft/server.properties > /dev/null << 'EOF'
# ===========================================================================
# Kafka 3.7 KRaft Single-Node — Hands-on Part 3
# ===========================================================================

# ---- KRaft Roles ---------------------------------------------------------
process.roles=broker,controller
node.id=1
controller.quorum.voters=1@localhost:9093

# ---- Listeners -----------------------------------------------------------
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
advertised.listeners=PLAINTEXT://localhost:9092

# ---- Storage -------------------------------------------------------------
log.dirs=/home/azureuser/spark-handson/kafka-data

# ---- Topic Defaults (단일 노드용 축소) -----------------------------------
num.partitions=3
default.replication.factor=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
min.insync.replicas=1

# ---- Retention (학습용 기본 1h, 토픽별 재정의 가능) ----------------------
log.retention.hours=1
log.segment.bytes=104857600
log.retention.check.interval.ms=300000

# ---- Performance (단일 노드 학습 환경) ------------------------------------
num.network.threads=3
num.io.threads=4
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600

# ---- Auto Topic Creation (학습 편의, 운영에선 false 권장) ----------------
auto.create.topics.enable=false
EOF

grep -E "^(process.roles|node.id|listeners|log.dirs|num.partitions|log.retention)" \
     /opt/kafka/config/kraft/server.properties

KAFKA_HEAP_OPTS 정착

sudo tee /etc/default/kafka > /dev/null << 'EOF'
KAFKA_HEAP_OPTS="-Xmx1g -Xms1g"
LOG_DIR=/home/azureuser/spark-handson/logs/kafka
EOF

cat /etc/default/kafka

Cluster ID 생성 + Storage Format

KAFKA_CLUSTER_ID=$(/opt/kafka/bin/kafka-storage.sh random-uuid)
echo "Cluster ID: $KAFKA_CLUSTER_ID"

echo "$KAFKA_CLUSTER_ID" > ~/spark-handson/kafka-data/CLUSTER_ID.txt

/opt/kafka/bin/kafka-storage.sh format \
  -t "$KAFKA_CLUSTER_ID" \
  -c /opt/kafka/config/kraft/server.properties

ls ~/spark-handson/kafka-data/
cat ~/spark-handson/kafka-data/meta.properties

systemd unit 작성

sudo tee /etc/systemd/system/kafka.service > /dev/null << 'EOF'
[Unit]
Description=Apache Kafka (KRaft single-node)
Documentation=https://kafka.apache.org/documentation/
After=network.target

[Service]
Type=simple
User=azureuser
Group=azureuser
EnvironmentFile=/etc/default/kafka
Environment=JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/kraft/server.properties
ExecStop=/opt/kafka/bin/kafka-server-stop.sh

Restart=on-failure
RestartSec=5s
LimitNOFILE=100000
TimeoutStopSec=60s

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable kafka
sudo systemd-analyze verify /etc/systemd/system/kafka.service

Kafka 기동

sudo systemctl start kafka
sleep 5
sudo systemctl status kafka --no-pager | head -15

# 포트 LISTEN 확인 (9092 + 9093)
ss -tlnp 2>/dev/null | grep -E ':9092 |:9093 '

# Kafka 자체 로그
tail -20 ~/spark-handson/logs/kafka/server.log 2>/dev/null \
  || tail -20 /opt/kafka/logs/server.log

로그 마지막에 Kafka Server started 확인. 실패시 다음과 같이 fix.

1) 환경 파일을 올바른 변수명으로 다시 작성

sudo tee /etc/default/kafka > /dev/null << 'EOF'
KAFKA_HEAP_OPTS="-Xmx1g -Xms1g"
LOG_DIR=/home/azureuser/spark-handson/logs/kafka
EOF

# 2) 재시작 카운터 초기화 (41번 실패한 거 리셋)
sudo systemctl reset-failed kafka

# 3) 시작
sudo systemctl restart kafka
sleep 8
sudo systemctl status kafka --no-pager | head -8

다시 확인

# Kafka 자체 로그
tail -20 ~/spark-handson/logs/kafka/server.log 2>/dev/null \
  || tail -20 /opt/kafka/logs/server.log

토픽 생성

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic transactions-raw \
  --partitions 3 \
  --replication-factor 1 \
  --config retention.ms=3600000 \
  --config segment.ms=600000

kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --bootstrap-server localhost:9092 \
  --describe --topic transactions-raw

콘솔 Producer/Consumer 검증

터미널:

printf 'msg-1\nmsg-2\nmsg-3\n' | \
  kafka-console-producer.sh --bootstrap-server localhost:9092 \
    --topic transactions-raw

kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic transactions-raw \
  --from-beginning \
  --max-messages 3 \
  --timeout-ms 10000

Python Producer

• kafka-python 클라이언트로 Producer 구현.

• customers_dim에서 추출한 실제 customer_id로 외래키 정합성 유지.
• 발행률(rate), 실행 시간(duration), 이상치 비율(dirty rate) 인자로 제어.
• 의도적으로 1% 비율로 깨진 데이터를 섞어 Section 7 정제 로직 검증 재료를 만든다.

Application 스레드           kafka-python 내부            Kafka Broker
─────────────────            ─────────────────            ─────────────
producer.send(...)  ──→  [accumulator 큐]
producer.send(...)  ──→  [accumulator 큐]
                              │
                              │                 linger_ms 또는 batch.size 도달
                              ▼    
                         [Sender 스레드] ──→     TCP ─→         [9092]
                              │
                              │                 broker ack 대기 (acks=all)
                              ▼
                         [retry 또는 done]

producer.flush()    ──→  큐 비울 때까지 블록
producer.close()    ──→  flush + 연결 종료

flush()를 안 부르면? 스크립트 종료 시 큐에 남은 메시지 손실 가능. 본 가이드는 try/finally에서 호출.

key 사용 전략

key=None 또는 매번 다른 key:
  Partition 0: [t1][t4][t7]...    ← 라운드로빈
  Partition 1: [t2][t5]...
  Partition 2: [t3][t6]...

key=customer_id ("C001234"):
  hash("C001234") % 3 = 1
  → 이 고객의 모든 거래는 항상 Partition 1
  → 순서 보장

key=customer_id. 이유:

1. 같은 고객의 거래 순서 보장 (이상 거래 탐지 시 유용)
2. 파티션 분포가 customer_id 분포에 따름 → 자연스러운 부하 분산

4종 dirty 패턴

kafka-python 설치

echo $VIRTUAL_ENV
# /home/azureuser/sparkenv 가 나와야 함

pip install --quiet "kafka-python>=2.0.0,<3.0.0"

python -c "import kafka; print('kafka-python', kafka.__version__)"

customer_id 샘플 파일 생성

Producer가 매번 PG에 쿼리하면 비싸다. 시작 시 한 번 추출.

psql -tAc "SELECT customer_id FROM customers_dim ORDER BY customer_id" \
  > ~/spark-handson/streaming/customer_ids.txt

wc -l ~/spark-handson/streaming/customer_ids.txt
head -3 ~/spark-handson/streaming/customer_ids.txt
tail -3 ~/spark-handson/streaming/customer_ids.txt

# 기대 출력:
10000 ~/spark-handson/streaming/customer_ids.txt
C000001
C000002
...
C009998
C009999

gen_events.py 작성

cat > ~/spark-handson/streaming/gen_events.py << 'PYEOF'
#!/usr/bin/env python3
"""
gen_events.py — OneStore 가짜 거래 이벤트 생성기 (Kafka Producer)

실행 예시:
  # 기본: 초당 5건, 무한, dirty 1%
  python ~/spark-handson/streaming/gen_events.py

  # 60초간 초당 10건
  python ~/spark-handson/streaming/gen_events.py --rate 10 --duration 60

  # systemd가 호출할 때 (로그 파일 분리)
  python ~/spark-handson/streaming/gen_events.py \
    --rate 5 --log-file ~/spark-handson/logs/gen_events.log
"""
import argparse
import json
import logging
import os
import random
import signal
import sys
import time
from datetime import datetime, timezone
from pathlib import Path
from typing import List

from kafka import KafkaProducer
from kafka.errors import KafkaError

# ── 도메인 정의 ────────────────────────────────────────────────────────
CATEGORIES = [
    ("GROCERY",      35),
    ("FASHION",      20),
    ("ELECTRONICS",  15),
    ("BOOKS",        10),
    ("SPORTS",       10),
    ("BEAUTY",        5),
    ("FOOD_DELIVERY", 5),
]
STATUS = [
    ("COMPLETED", 85),
    ("PENDING",   10),
    ("FAILED",     3),
    ("REFUNDED",   2),
]
DIRTY_PATTERNS = [
    "negative_amount",
    "invalid_status",
    "unknown_customer",
    "missing_field",
]

logger = logging.getLogger("gen_events")


# ── 유틸 ────────────────────────────────────────────────────────────────
def load_customer_ids(path: str) -> List[str]:
    p = Path(os.path.expanduser(path))
    if not p.exists():
        sys.exit(f"ERROR: customer sample file not found: {p}")
    ids = [ln.strip() for ln in p.read_text().splitlines() if ln.strip()]
    if len(ids) < 100:
        sys.exit(f"ERROR: too few customer ids ({len(ids)}). Expected 100+.")
    logger.info(f"loaded {len(ids)} customer ids")
    return ids


def make_tx_id(seq: int) -> str:
    """T + YYYYMMDDHHMMSS + 3-digit sequence (max 30 chars)."""
    now = datetime.now(timezone.utc)
    return f"T{now.strftime('%Y%m%d%H%M%S')}{seq:03d}"


def amount_for_category(cat: str) -> float:
    if cat == "ELECTRONICS":
        return round(random.uniform(50_000, 2_000_000), 2)
    if cat == "GROCERY":
        return round(random.uniform(3_000, 80_000), 2)
    if cat == "FASHION":
        return round(random.uniform(15_000, 300_000), 2)
    return round(random.uniform(5_000, 150_000), 2)


def gen_clean(customer_ids: List[str], seq: int) -> dict:
    cat = random.choices(
        [c for c, _ in CATEGORIES],
        weights=[w for _, w in CATEGORIES], k=1
    )[0]
    st = random.choices(
        [s for s, _ in STATUS],
        weights=[w for _, w in STATUS], k=1
    )[0]
    return {
        "transaction_id": make_tx_id(seq),
        "customer_id": random.choice(customer_ids),
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "amount": amount_for_category(cat),
        "category": cat,
        "status": st,
    }


def gen_dirty(customer_ids: List[str], seq: int) -> dict:
    ev = gen_clean(customer_ids, seq)
    pat = random.choice(DIRTY_PATTERNS)
    if pat == "negative_amount":
        ev["amount"] = -abs(ev["amount"])
    elif pat == "invalid_status":
        ev["status"] = "ZZZ_INVALID"
    elif pat == "unknown_customer":
        ev["customer_id"] = "C999999"          # customers_dim에 없는 ID
    elif pat == "missing_field":
        ev.pop("category", None)
    ev["_dirty"] = pat                          # _ 시작 필드는 다운스트림 무시
    return ev


# ── Producer ────────────────────────────────────────────────────────────
def make_producer(bootstrap: str) -> KafkaProducer:
    return KafkaProducer(
        bootstrap_servers=bootstrap,
        value_serializer=lambda v: json.dumps(v, default=str).encode("utf-8"),
        key_serializer=lambda k: (k or "").encode("utf-8"),
        acks="all",
        linger_ms=10,
        retries=3,
        max_in_flight_requests_per_connection=1,  # 순서 보장
    )


# ── 메인 루프 ───────────────────────────────────────────────────────────
def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--bootstrap",   default="localhost:9092")
    ap.add_argument("--topic",       default="transactions-raw")
    ap.add_argument("--sample-file", default="~/spark-handson/streaming/customer_ids.txt")
    ap.add_argument("--rate",        type=float, default=5.0,
                    help="events per second")
    ap.add_argument("--duration",    type=int,   default=0,
                    help="seconds; 0 = infinite")
    ap.add_argument("--dirty-rate",  type=float, default=0.01)
    ap.add_argument("--log-file",    default=None)
    args = ap.parse_args()

    # 로깅
    handlers = [logging.StreamHandler()]
    if args.log_file:
        Path(args.log_file).parent.mkdir(parents=True, exist_ok=True)
        handlers.append(logging.FileHandler(args.log_file))
    logging.basicConfig(
        level=logging.INFO,
        format="%(asctime)s %(levelname)s %(message)s",
        handlers=handlers,
    )

    customer_ids = load_customer_ids(args.sample_file)
    producer = make_producer(args.bootstrap)
    logger.info(f"connected to {args.bootstrap}, topic={args.topic}, "
                f"rate={args.rate}/s, dirty={args.dirty_rate*100:.1f}%")

    # 그레이스풀 종료
    stop = {"flag": False}
    def handle(sig, _frame):
        logger.info(f"signal {sig} received, stopping...")
        stop["flag"] = True
    signal.signal(signal.SIGINT, handle)
    signal.signal(signal.SIGTERM, handle)

    interval = 1.0 / args.rate if args.rate > 0 else 0.0
    seq = 0
    sent_clean = sent_dirty = sent_err = 0
    start = time.time()

    try:
        while not stop["flag"]:
            if args.duration and (time.time() - start) >= args.duration:
                break

            seq = (seq + 1) % 1000
            is_dirty = random.random() < args.dirty_rate
            ev = (gen_dirty if is_dirty else gen_clean)(customer_ids, seq)

            try:
                producer.send(args.topic,
                              key=ev.get("customer_id"),
                              value=ev)
                if is_dirty:
                    sent_dirty += 1
                else:
                    sent_clean += 1
            except KafkaError as e:
                sent_err += 1
                logger.warning(f"send error: {e}")

            total = sent_clean + sent_dirty
            if total and total % 100 == 0:
                el = time.time() - start
                logger.info(
                    f"sent={total} clean={sent_clean} dirty={sent_dirty} "
                    f"err={sent_err} elapsed={el:.1f}s rate={total/el:.1f}/s"
                )

            if interval > 0:
                time.sleep(interval)
    finally:
        logger.info("flushing remaining messages...")
        producer.flush(timeout=10)
        producer.close(timeout=10)
        el = time.time() - start
        total = sent_clean + sent_dirty
        logger.info(
            f"DONE total={total} clean={sent_clean} dirty={sent_dirty} "
            f"err={sent_err} elapsed={el:.1f}s avg_rate={total/max(el,0.01):.1f}/s"
        )


if __name__ == "__main__":
    main()
PYEOF

chmod +x ~/spark-handson/streaming/gen_events.py
ls -l ~/spark-handson/streaming/gen_events.py
wc -l ~/spark-handson/streaming/gen_events.py

짧은 실행 (10초간 초당 5건)

터미널 1 (Producer):

python ~/spark-handson/streaming/gen_events.py \
  --rate 5 --duration 10 --dirty-rate 0.10
# (학습용으로 dirty-rate 10%로 올려 dirty 패턴 가시성 ↑)

메시지 수신 확인 (Consumer)

kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic transactions-raw \
  --from-beginning \
  --max-messages 50 \
  --timeout-ms 5000 \
  | head -5

dirty 데이터 패턴 분포 확인

kafka-console-consumer.sh --bootstrap-server localhost:9092 \
  --topic transactions-raw --from-beginning \
  --max-messages 50 --timeout-ms 5000 2>/dev/null \
  | grep '^{' \
  | jq -r '._dirty // "clean"' \
  | sort | uniq -c

Spark Structured Streaming — Kafka Consume + 정제

• Spark Structured Streaming의 micro-batch 모델 이해.

• Kafka source(format="kafka")에서 binary value를 JSON으로 파싱.
• 명시적 스키마(StructType)로 타입 안전성 확보.
• 4종 dirty 패턴을 정제 로직으로 걸러낸다.
• 콘솔 sink로 적재 전 결과를 시각적으로 검증.

Micro-batch 모델

시간축 →

  Trigger 1 (t=5s)        Trigger 2 (t=10s)        Trigger 3 (t=15s)
       │                       │                       │
       ▼                       ▼                       ▼
   ┌────────┐             ┌────────┐             ┌────────┐
   │ batch  │            │ batch  │             │ batch  │
   │  ID=0  │            │  ID=1  │             │  ID=2  │
   │ 25 msg │            │ 27 msg │             │ 24 msg │
   └────┬───┘             └────┬───┘             └────┬───┘
        │ DataFrame           │ DataFrame            │ DataFrame
        ▼                      ▼                      ▼
    [정제 로직]            [정제 로직]            [정제 로직]
        │                      │                      │
        ▼                      ▼                      ▼
    [Sink]                  [Sink]                  [Sink]
        │                      │                      │
        ▼                      ▼                      ▼
   checkpoint 갱신       checkpoint 갱신        checkpoint 갱신

핵심: 매 trigger마다 받은 메시지가 정적 DataFrame. 이후 처리는 일반 Spark 연산과 동일.

Kafka source의 raw 스키마

spark.readStream.format("kafka")가 반환하는 DataFrame은 항상 다음 7개 컬럼.

4종 dirty 패턴 정제 매핑

원본 메시지 (JSON)
     │ CAST(value AS STRING) → from_json(payload, SCHEMA)
     ▼
struct<transaction_id, customer_id, timestamp, amount, category, status>
     │ ① missing_field (category null) → IS NOT NULL 필터
     │ ② negative_amount → amount >= 0 필터
     │ ③ invalid_status → status IN (...) 필터
     │ ④ unknown_customer → 7-2에서 화이트리스트로 차단
     ▼
정제된 DataFrame
     │
     ▼
sink (7-1: 콘솔, 7-2: PostgreSQL)

Kafka 패키지 사전 캐싱

cat > /tmp/cache_kafka_pg.py << 'PYEOF'
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("cache_kafka_pg").getOrCreate()
print("Kafka + PostgreSQL packages loaded")
spark.stop()
PYEOF

spark-submit \
  --packages org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.8,org.postgresql:postgresql:42.7.4 \
  --conf spark.driver.memory=1g \
  /tmp/cache_kafka_pg.py 2>&1 | grep -E "(SUCCESSFUL|downloaded|loaded|ERROR)"

# 캐시 확인 — Step 4-1과 같은 경로 패턴 (~/.ivy2/jars/, 평탄 구조)
ls -la ~/.ivy2/jars/ | grep -E "spark-sql-kafka|spark-token|kafka-clients|postgresql"

정제 검증용 스크립트 (콘솔 sink)

cat > ~/spark-handson/streaming/streaming_console.py << 'PYEOF'
#!/usr/bin/env python3
"""
streaming_console.py — Section 7-1 검증용
Kafka transactions-raw 구독 → 정제 → 콘솔 출력.
"""
import os
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, to_timestamp
from pyspark.sql.types import StructType, StringType, DoubleType

KAFKA_BOOTSTRAP = "localhost:9092"
KAFKA_TOPIC     = "transactions-raw"
VALID_STATUS    = ["COMPLETED", "PENDING", "FAILED", "REFUNDED"]


PAYLOAD_SCHEMA = (
    StructType()
    .add("transaction_id", StringType())
    .add("customer_id",    StringType())
    .add("timestamp",      StringType())
    .add("amount",         DoubleType())
    .add("category",       StringType())
    .add("status",         StringType())
)


def main():
    spark = (
        SparkSession.builder
        .appName("streaming_console")
        .getOrCreate()
    )
    spark.sparkContext.setLogLevel("ERROR")

    # 1) Kafka 소스 구독
    raw = (
        spark.readStream
        .format("kafka")
        .option("kafka.bootstrap.servers", KAFKA_BOOTSTRAP)
        .option("subscribe", KAFKA_TOPIC)
        .option("startingOffsets", "earliest")  # 운영은 latest
        .option("failOnDataLoss", "false")
        .load()
    )

    # 2) JSON 파싱
    parsed = (
        raw
        .select(
            col("partition").alias("kafka_partition"),
            col("offset").alias("kafka_offset"),
            col("timestamp").alias("kafka_ts"),
            from_json(col("value").cast("string"), PAYLOAD_SCHEMA).alias("p"),
        )
        .select("kafka_partition", "kafka_offset", "kafka_ts", "p.*")
    )

    # 3) 타입 변환 + 정제
    cleaned = (
        parsed
        .withColumn("ts", to_timestamp(col("timestamp")))
        .where(col("transaction_id").isNotNull())
        .where(col("customer_id").isNotNull())
        .where(col("ts").isNotNull())
        .where(col("amount").isNotNull() & (col("amount") >= 0))
        .where(col("category").isNotNull())
        .where(col("status").isin(VALID_STATUS))
        .select(
            "transaction_id", "customer_id", "ts",
            "amount", "category", "status",
            "kafka_partition", "kafka_offset",
        )
    )

    # 4) 콘솔 sink
    query = (
        cleaned.writeStream
        .format("console")
        .outputMode("append")
        .option("truncate", "false")
        .option("numRows", 10)
        .trigger(processingTime="5 seconds")
        .queryName("console_q")
        .start()
    )

    print(f"[INFO] streaming started. trigger=5s, topic={KAFKA_TOPIC}")
    print(f"[INFO] press Ctrl-C to stop")
    query.awaitTermination()


if __name__ == "__main__":
    main()
PYEOF

chmod +x ~/spark-handson/streaming/streaming_console.py

두 터미널 실행 패턴

터미널 A: Producer

python ~/spark-handson/streaming/gen_events.py \
  --rate 5 --duration 120 --dirty-rate 0.20

터미널 B: Streaming consumer

spark-submit \
  --packages org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.8 \
  --conf spark.driver.memory=2g \
  ~/spark-handson/streaming/streaming_console.py

dirty 메시지가 사라진 게 보이는가? Producer는 dirty 20%를 보냈지만 콘솔엔 정상만. 즉 dirty는 정제 단계에서 모두 제거.

종료

터미널 B에서 Ctrl-C. graceful shutdown.

Spark Structured Streaming — foreachBatch + PostgreSQL 적재 + 체크포인트

• foreachBatch로 micro-batch DataFrame을 JDBC로 적재.

• customers_dim 화이트리스트로 unknown_customer 사전 차단.
• ON CONFLICT DO NOTHING 패턴으로 멱등성 확보 (재처리 시 중복 PK 무시).
• checkpointLocation으로 정확히 끊긴 지점부터 재개 (exactly-once 효과).
• 운영 환경 권장 옵션(maxOffsetsPerTrigger, retry 정책) 적용.

개념 설명: 화이트리스트 사전 차단 vs FK 거부

방어선 1: Spark에서 화이트리스트 (선제 차단)
   df.join(customers_broadcast, "customer_id", "inner")
   → unknown_customer 메시지 사전 제거

방어선 2: PostgreSQL FK (최종 차단)
   FOREIGN KEY (customer_id) REFERENCES customers_dim(customer_id)
   → 만에 하나 통과해도 INSERT 거부

방어선 1만으로 거의 끝. 2는 안전망.

왜 broadcast? customers_dim 10,000건 (~1MB)은 작아서 모든 executor에 broadcast 가능. shuffle 없이 빠른 join.

개념 설명: ON CONFLICT DO NOTHING의 멱등성

INSERT INTO transactions_fact (transaction_id, customer_id, ts, amount, category, status)
VALUES (...)
ON CONFLICT (transaction_id) DO NOTHING;

• 같은 transaction_id 다시 들어오면 무시.
• Streaming 재시작 후 일부 메시지가 재처리되어도 중복 안 됨.
• 이것이 Streaming의 "exactly-once 효과"의 핵심.

개념 설명: Checkpoint 동작

첫 실행:
  Kafka offset 0 → batch 0 → PG 적재 → checkpoint 갱신 (offset=25)
  Kafka offset 25 → batch 1 → PG 적재 → checkpoint 갱신 (offset=52)
  ...

재시작 (마지막 checkpoint=52):
  Kafka offset 52 부터 재개
  → batch 마지막에 미완료 적재가 있어도 ON CONFLICT가 멱등성 보장

Checkpoint 구조:

~/spark-handson/checkpoints/streaming_to_pg/
├── offsets/         ← 매 batch의 시작 offset
├── commits/         ← batch 완료 표시
├── sources/         ← Kafka source 메타
└── state/           ← (stateful 연산 시 사용; 본 가이드는 stateless)

체크포인트 디렉터리는 절대 수동 삭제 X (의도적 reset 외엔). 삭제 시 처음부터 다시 처리 → 중복 가능.

psycopg2-binary 설치

pip install --quiet "psycopg2-binary>=2.9.0,<3.0.0"
python -c "import psycopg2; print('psycopg2', psycopg2.__version__)"

streaming_to_pg.py 작성

cat > ~/spark-handson/streaming/streaming_to_pg.py << 'PYEOF'
#!/usr/bin/env python3
"""
streaming_to_pg.py — Section 7-2 본 적재 스크립트
Kafka → 정제 → customers_dim 화이트리스트 → PostgreSQL UPSERT.
checkpoint로 정확한 재시작 보장.
"""
import os
import sys
from pathlib import Path

import psycopg2
from psycopg2.extras import execute_values

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, to_timestamp, broadcast
from pyspark.sql.types import StructType, StringType, DoubleType


# ── 설정 ────────────────────────────────────────────────────────────────
KAFKA_BOOTSTRAP = "localhost:9092"
KAFKA_TOPIC     = "transactions-raw"
VALID_STATUS    = ["COMPLETED", "PENDING", "FAILED", "REFUNDED"]
CHECKPOINT_DIR  = os.path.expanduser("~/spark-handson/checkpoints/streaming_to_pg")

PAYLOAD_SCHEMA = (
    StructType()
    .add("transaction_id", StringType())
    .add("customer_id",    StringType())
    .add("timestamp",      StringType())
    .add("amount",         DoubleType())
    .add("category",       StringType())
    .add("status",         StringType())
)


# ── PG 접속 정보 (.pgpass 파싱) ─────────────────────────────────────────
def get_pg_password() -> str:
    pgpass = Path.home() / ".pgpass"
    if oct(pgpass.stat().st_mode)[-3:] != "600":
        sys.exit("ERROR: ~/.pgpass permission must be 600")
    for ln in pgpass.read_text().splitlines():
        parts = ln.split(":")
        if len(parts) == 5 and parts[3] == "handson":
            return parts[4]
    sys.exit("ERROR: handson entry missing in ~/.pgpass")


PG_HOST, PG_PORT = "127.0.0.1", 5432
PG_DB,   PG_USER = "onestore", "handson"
PG_PASS = get_pg_password()


# ── customers_dim 화이트리스트 로드 ─────────────────────────────────────
def load_customer_whitelist(spark: SparkSession):
    jdbc_url = f"jdbc:postgresql://{PG_HOST}:{PG_PORT}/{PG_DB}"
    props = {"user": PG_USER, "password": PG_PASS,
             "driver": "org.postgresql.Driver"}
    df = (
        spark.read.jdbc(jdbc_url,
                        "(SELECT customer_id FROM customers_dim) AS sub",
                        properties=props)
    )
    cnt = df.count()
    print(f"[INFO] customers_dim whitelist loaded: {cnt} rows")
    if cnt == 0:
        sys.exit("ERROR: customers_dim is empty. Run Section 4 first.")
    return df


# ── foreachBatch 함수 ───────────────────────────────────────────────────
def write_batch_to_pg(batch_df, batch_id):
    """매 micro-batch마다 호출."""
    if batch_df.rdd.isEmpty():
        print(f"[batch {batch_id}] empty, skip")
        return

    # Spark Driver로 행 수집 (batch당 보통 수십~수백건)
    rows = batch_df.collect()
    print(f"[batch {batch_id}] received {len(rows)} valid rows")

    if not rows:
        return

    # psycopg2로 UPSERT
    conn = None
    try:
        conn = psycopg2.connect(
            host=PG_HOST, port=PG_PORT,
            dbname=PG_DB, user=PG_USER, password=PG_PASS,
            connect_timeout=5,
        )
        conn.autocommit = False
        with conn.cursor() as cur:
            data = [
                (r.transaction_id, r.customer_id, r.ts,
                 float(r.amount), r.category, r.status)
                for r in rows
            ]
            sql = """
                INSERT INTO transactions_fact
                  (transaction_id, customer_id, ts, amount, category, status)
                VALUES %s
                ON CONFLICT (transaction_id) DO NOTHING
            """
            execute_values(cur, sql, data, page_size=500)
            inserted = cur.rowcount
            conn.commit()
            print(f"[batch {batch_id}] inserted={inserted} (skip on conflict)")
    except Exception as e:
        if conn:
            conn.rollback()
        # 에러 raise → Spark가 batch를 retry. 너무 자주면 max retry 후 query 실패.
        print(f"[batch {batch_id}] ERROR: {e}")
        raise
    finally:
        if conn:
            conn.close()


def main():
    spark = (
        SparkSession.builder
        .appName("streaming_to_pg")
        .getOrCreate()
    )
    spark.sparkContext.setLogLevel("ERROR")

    # 1) 화이트리스트 (broadcast로 변환)
    whitelist = broadcast(load_customer_whitelist(spark))

    # 2) Kafka 소스
    raw = (
        spark.readStream
        .format("kafka")
        .option("kafka.bootstrap.servers", KAFKA_BOOTSTRAP)
        .option("subscribe", KAFKA_TOPIC)
        .option("startingOffsets", "latest")           # 운영: latest
        .option("failOnDataLoss", "false")
        .option("maxOffsetsPerTrigger", 1000)          # 백프레셔 보호
        .load()
    )

    # 3) JSON 파싱 + 정제
    parsed = (
        raw.select(
            from_json(col("value").cast("string"), PAYLOAD_SCHEMA).alias("p")
        )
        .select("p.*")
        .withColumn("ts", to_timestamp(col("timestamp")))
        .where(col("transaction_id").isNotNull())
        .where(col("customer_id").isNotNull())
        .where(col("ts").isNotNull())
        .where(col("amount").isNotNull() & (col("amount") >= 0))
        .where(col("category").isNotNull())
        .where(col("status").isin(VALID_STATUS))
    )

    # 4) 화이트리스트 join (unknown_customer 차단)
    cleaned = parsed.join(whitelist, "customer_id", "inner") \
                    .select("transaction_id", "customer_id", "ts",
                            "amount", "category", "status")

    # 5) foreachBatch sink
    query = (
        cleaned.writeStream
        .foreachBatch(write_batch_to_pg)
        .option("checkpointLocation", CHECKPOINT_DIR)
        .trigger(processingTime="10 seconds")
        .queryName("kafka_to_pg")
        .start()
    )

    print(f"[INFO] streaming started")
    print(f"[INFO] checkpoint: {CHECKPOINT_DIR}")
    print(f"[INFO] press Ctrl-C to stop gracefully")

    query.awaitTermination()


if __name__ == "__main__":
    main()
PYEOF

chmod +x ~/spark-handson/streaming/streaming_to_pg.py
ls -l ~/spark-handson/streaming/streaming_to_pg.py

Producer

Streaming → PG

PG에서 실시간 적재 확인

checkpoint 디렉터리 확인

재시작 검증 (exactly-once 효과)

터미널 B에서 Ctrl-C → 30초 대기 → 같은 명령으로 재실행.

# 재실행 전 PG의 전체 행 수
COUNT_BEFORE=$(psql -tAc "SELECT COUNT(*) FROM transactions_fact")
echo "before restart: $COUNT_BEFORE"

# 30초간 더 실행 후 종료, 다시 행 수 확인
# (재시작 시 [INFO] starting from checkpoint ... 로그 보임)

예상: checkpoint 덕분에 끊긴 지점에서 재개. 약간의 중복은 ON CONFLICT가 흡수.

적재 데이터 검증 SQL

psql << 'SQL'
\echo '== 전체 행 수 =='
SELECT COUNT(*) FROM transactions_fact;

\echo '== status별 분포 =='
SELECT status, COUNT(*) FROM transactions_fact GROUP BY status ORDER BY 2 DESC;

\echo '== 가장 활발한 고객 5명 =='
SELECT customer_id, COUNT(*) AS tx_count, SUM(amount) AS total_spent
FROM transactions_fact
GROUP BY customer_id
ORDER BY tx_count DESC
LIMIT 5;

\echo '== category별 평균 금액 =='
SELECT category, COUNT(*) AS n, ROUND(AVG(amount)::numeric, 0) AS avg_amount
FROM transactions_fact
GROUP BY category
ORDER BY avg_amount DESC;

\echo '== 최근 1분간 처리량 =='
SELECT COUNT(*) AS recent_count
FROM transactions_fact
WHERE ingested_at >= NOW() - INTERVAL '1 minute';
SQL

cron

cron으로 충분한 경우

다음 모두 해당하면 cron 유지.

• 잡 수 < 10개
• 잡 의존성 없음 (또는 시간 순서로 강제 가능)
• 모든 잡의 실행 시간 < 다음 호출 간격 (락으로 보강)
• 실패 시 다음 회차 재실행으로 충분 (즉시 복구 불요)
• 단일 호스트에서 처리 가능
• 한국 시간 기준 일정한 시각으로 충분 (윈도우·캘린더 복잡도 없음)

Airflow가 필요한 시점

다음 신호가 하나라도 등장하면 Airflow(또는 Dagster, Prefect) 도입 고려.

Phase 1 :
  cron + bash wrapper (락·메모리 가드·로그)
  → Part 3 수준에 적합

Phase 2:
  cron + Python orchestrator
  - 더 복잡한 wrapper (DB로 잡 상태 추적)
  - Slack 알림
  → 잡 수 5~15개

Phase 3:
  Airflow (LocalExecutor, single host)
  - DAG, retry, UI
  → 잡 수 15~50개, 의존성 등장

Phase 4:
  Airflow (CeleryExecutor 또는 KubernetesExecutor)
  - 분산 워커
  → 50개 이상, 멀티 팀

kafka 다중 브로커

현재 (단일):
  ┌─────────┐
  │ broker1 │ partitions: P0, P1, P2 (모두 leader)
  └─────────┘ replication: 1

확장 (3 broker, RF=3):
  ┌─────────┐  ┌─────────┐  ┌─────────┐
  │ broker1 │  │ broker2 │  │ broker3 │
  │ P0 (L)  │  │ P1 (L)  │  │ P2 (L)  │
  │ P2 (F)  │  │ P0 (F)  │  │ P0 (F)  │
  │ P1 (F)  │  │ P2 (F)  │  │ P1 (F)  │
  └─────────┘  └─────────┘  └─────────┘
  L=Leader, F=Follower (replica)

도입 시 필요한 작업:

• 추가 VM 2대 또는 컨테이너
• 모든 broker가 같은 controller quorum 공유 (controller.quorum.voters=1@host1:9093,2@host2:9093,3@host3:9093)
• 토픽 재생성 또는 kafka-reassign-partitions.sh로 replication 추가
• min.insync.replicas=2 (3 broker, RF=3 권장)
• Producer acks=all (이미 본 가이드 적용)

Spark 분산 모드

현재 (local):
  spark-submit --master local[*]
  → driver = executor = 한 JVM
  → 메모리 = VM RAM

확장 옵션:
  ① Spark Standalone Cluster
     spark-submit --master spark://master:7077 \
                  --deploy-mode cluster \
                  --executor-memory 4g --executor-cores 2 \
                  --num-executors 5
     → 별도 master + worker 노드 (Spark 자체 클러스터 매니저)

  ② Kubernetes
     spark-submit --master k8s://https://... \
                  --deploy-mode cluster \
                  --conf spark.kubernetes.container.image=...
     → Pod로 동적 executor 생성·소멸

  ③ YARN (Hadoop 환경)
     spark-submit --master yarn --deploy-mode cluster
     → 기존 Hadoop 클러스터 자원 활용

Delta Lake 도입

Parquet의 한계 → Delta Lake로 ACID·time travel.

전환 예시

# Streaming sink를 Delta로 변경
parsed.writeStream \
  .format("delta") \
  .option("checkpointLocation", "/.../checkpoints/delta") \
  .start("/.../delta/transactions_fact")

# UPSERT (배치 추론에서 사용 가능)
from delta.tables import DeltaTable
delta_pred = DeltaTable.forPath(spark, "/.../delta/ml_predictions")
delta_pred.alias("p").merge(
    new_pred.alias("n"),
    "p.customer_id = n.customer_id"
).whenMatchedUpdate(set={...}).whenNotMatchedInsert(values={...}).execute()

도입 비용: --packages io.delta:delta-spark_2.12:3.0.0. PostgreSQL은 그대로 두고, 분석·아카이브 레이어를 Delta로 분리하는 패턴이 일반적.

Schema Registry

현재 Producer가 임의 JSON. → 스키마 레지스트리로 contract 강제.

Producer        Schema Registry         Consumer
   │                 ▲                     │
   │ schema_id 조회  │  ┌─schemas:─┐       │
   ├────────────────▶│  │ v1: ... │       │
   │                 │  │ v2: ... │       │
   │                 │  └─────────┘       │
   │  msg = schema_id + binary payload     │
   ├──────────────────────────────────────▶│
                                           │
                       schema_id로 deserialize

대표 옵션:

• Confluent Schema Registry: Avro 표준
• Apicurio: Avro/Protobuf/JSON Schema 다 지원, Apache 2.0
• Karapace: Apache 2.0, Confluent 호환

장점:

• 호환성 검증 (BACKWARD/FORWARD/FULL)
• Producer/Consumer 독립 진화
• 메시지 크기 절감 (스키마 미포함, ID만)

Dead-Letter Topic

현재 정제 실패 메시지는 where(...) 필터로 폐기. → 별도 토픽에 보관해 분석.

              ┌───── valid → transactions_fact
              │
[정제 분기]   ┤
              │
              └───── invalid → transactions-dlq (dead-letter)

구현 패턴:

# foreachBatch 내부
valid = batch_df.filter(...).cache()
invalid = batch_df.exceptAll(valid).cache()

# valid → PG
write_to_pg(valid)

# invalid → Kafka dead-letter 토픽 (또는 PG 별도 테이블)
invalid.selectExpr("CAST(transaction_id AS STRING) AS key",
                   "to_json(struct(*)) AS value") \
       .write.format("kafka") \
       .option("topic", "transactions-dlq") \
       .save()

dead-letter 분석으로 Producer 버그·외부 시스템 변경 조기 탐지.

모니터링 스택 (Prometheus + Grafana)

현재 사람이 SQL·CLI로 조회 → 자동 메트릭 수집·시각화·알림.

┌────────────────────────────────────────────────────────┐
│ ① 메트릭 노출 (각 컴포넌트 → /metrics endpoint)         │
│    - PG       : postgres_exporter                       │
│    - Kafka    : JMX exporter                            │
│    - Spark    : spark.metrics.conf                      │
│    - Node     : node_exporter (메모리·디스크·CPU)       │
│    - 사용자정의 : pushgateway                           │
└────────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────┐
│ ② Prometheus (시계열 DB) - 주기적 scrape, 저장         │
└────────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────┐
│ ③ Grafana (시각화) - 대시보드, 알림 룰                 │
└────────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────┐
│ ④ Alertmanager - Slack·PagerDuty·Email                │
└────────────────────────────────────────────────────────┘

확장 우선순위 (현재 → 운영으로 가려면)

다음 순서를 권장:

1. Schema Registry — 데이터 contract 강제
2. Dead-Letter — 실패 분석·신뢰도 향상
3. Prometheus + Grafana — 정량 모니터링
4. PG replica + 백업 자동화 — 데이터 안전성
5. Kafka 3-broker — Kafka 장애 내성
6. Spark 분산 — 처리량이 한계 도달 시
7. Delta Lake — 분석 레이어 분리 시

쇼핑몰 인프라 핵심 기술 정리

Elasticsearch

왜 사용하는가?

RDBMS는 일반적인 CRUD에는 강하지만 검색 엔진 역할에는 한계가 있다.

예를 들어:

LIKE '%맥북%'

같은 쿼리는 인덱스를 제대로 활용하지 못해 대규모 데이터에서 매우 느려진다.

특히 쇼핑몰에서는:

• 상품 10억 건 규모
• 한국어 형태소 분석
• 오타 보정
• 카테고리 + 가격 + 태그 조합 검색
• 검색어 적합도 순 정렬

등이 필요하기 때문에 Elasticsearch를 별도로 둔다.

Elasticsearch의 핵심 특징

1. 역색인(Inverted Index)

일반 DB:

문서 → 단어

Elasticsearch:

단어 → 문서

형태로 저장한다.

즉:

"맥북"이라는 단어가 들어간 문서 목록

을 미리 만들어두기 때문에 검색이 매우 빠르다.

2. 형태소 분석

한국어는 띄어쓰기·조사·어미 변화가 많다.

예:

노트북을
노트북이
노트북용

Elasticsearch는:

• Nori
• Mecab-ko

같은 분석기를 통해 단어를 분리하고 정규화할 수 있다.

3. Relevance Score

단순 포함 여부가 아니라:

검색어와 얼마나 관련 있는가

를 계산해 정렬한다.

예:

• 제목에 포함 → 점수 높음
• 설명에만 포함 → 점수 낮음

CDC (Change Data Capture)

문제:

상품 DB와 Elasticsearch 데이터를 어떻게 동기화할 것인가?

직접 애플리케이션 코드에서:

• DB 저장
• ES 저장

둘 다 처리하면 결합도가 커진다.

Debezium + Kafka 구조

MySQL binlog
    ↓
Debezium
    ↓
Kafka
    ↓
Elasticsearch

Debezium 역할

DB binlog를 읽어:

• INSERT
• UPDATE
• DELETE

변경 이벤트를 추출한다.

즉:

DB 변경사항을 이벤트로 변환

하는 역할이다.

Kafka 역할

변경 이벤트를 버퍼링·전달한다.

장점:

• 대량 이벤트 처리 가능
• Consumer 분리 가능
• 재처리 가능

Redis

Redis를 사용하는 이유

Redis는 메모리 기반 저장소이다.

특징:

• 매우 빠름
• 읽기 TPS 높음
• 단순 조회에 강함

쇼핑몰처럼:

• 조회량은 많고
• 데이터 변경은 상대적으로 적은

환경에 매우 적합하다.

Redis 캐시 전략

이 자료에서는:

모든 데이터를 동일하게 캐싱하지 않는다

는 점이 중요하다.

데이터 성격에 따라 전략을 다르게 가져간다.

1. 메인 페이지 상품

특징:

• 모든 사용자 동일 데이터
• 1시간마다 갱신

전략:

Write-Through
TTL 1시간

Write-Through

DB 업데이트 시:

• Redis도 같이 갱신

즉:

데이터 생성 시 캐시도 함께 생성

하는 방식.

TTL(Time To Live)

캐시에 만료 시간을 둔다.

1시간 후 자동 삭제

이 자료에서는:

• 매시간 배치 실행
• Redis 갱신
• TTL 1시간

전략을 사용한다.

2. 카테고리 트리

특징:

• 거의 안 바뀜
• 변경 시 즉시 반영 필요

전략:

Read-Through
+ Explicit Invalidate

Read-Through

조회 시:

1. Redis 확인
2. 없으면 DB 조회
3. Redis 저장

Explicit Invalidate

관리자가 카테고리를 수정하면:

캐시를 직접 삭제

한다.

즉 TTL만 믿지 않고:

• 변경 이벤트 기반으로 캐시 제거

전략을 사용한다.

3. 평점·리뷰 수

문제:

리뷰 작성마다 평균 계산

을 하면:

• 락 경합
• DB 부하

문제가 생긴다.

해결 전략

30분 배치 집계
→ Redis 저장

즉:

• 실시간 정확성보다
• 안정성과 성능

을 우선한다.

메시지 큐(Message Queue)

왜 필요한가?

주문 API는 빠르게 응답해야 한다.

하지만:

• 이메일 발송
• 판매자 알림

은 느릴 수 있다.

이걸 동기로 처리하면:

• 응답 지연
• 타임아웃

이 발생한다.

비동기 처리 구조

주문 API
  ↓
Message Queue
  ↓
Worker

핵심 아이디어:

"일단 큐에 넣고 응답 먼저"

이다.

Queue의 장점

1. 트래픽 평탄화(Traffic Smoothing)

순간 TPS 급증을 큐가 흡수한다.

2. 시스템 분리

주문 시스템과 알림 시스템이 독립된다.

3. 재시도 가능

실패 메시지는:

• 재시도
• DLQ(Dead Letter Queue)

로 관리 가능하다.

SQS vs RabbitMQ vs Kafka

SQS

특징:

• AWS 관리형
• 운영 부담 적음
• DLQ 기본 제공

이 자료에서는:

• 이메일
• 판매자 알림

같은 단순 비동기에 적합하다고 평가했다.

RabbitMQ

특징:

• 복잡한 라우팅 가능
• 낮은 지연시간

단점:

• 직접 운영 필요

Kafka

특징:

• 초고성능 이벤트 스트리밍
• 이벤트 재처리 가능
• CDC와 매우 잘 맞음

하지만:

• 운영 복잡도 높음
• 단순 큐 용도로는 과함

이라는 특징이 있다.

Hot / Warm / Cold 아카이빙

핵심 아이디어

모든 데이터를 비싼 DB에 둘 필요는 없다.

대부분 오래된 데이터는 거의 조회되지 않는다.

계층 분리

HOT

최근 30일

• RDS
• 빠른 조회
• 고비용

WARM

30일 ~ 2년

• 샤딩 DB
• 일부 인덱스 유지

COLD

2년 ~ 5년

• S3 Parquet
• Athena 조회

특징:

• 저비용
• 느린 조회 허용

1. 데이터가 너무 커진 경우 → 배치 처리
2. sklearn으로는 학습이 안끝나 분산 ML이 필요한 경우 → ML 파이프라인
3. 실시간(1분내)로 보고받고 싶은 경우 → 스트리밍

1. 배치처리

분산 처리

Spark 아키텍처

Driver은 1개, Worker Node는 여러개. 작업이 끝나면 Worker Node는 자원을 반납

핵심 추상화

Pandas, DF, SQL

지연 실행(Lazy Evaluation)

Spark에서는 Transformation 연산을 수행한다고 해서 즉시 데이터 처리가 실행되지 않는다. filter(), select(), groupBy(), join(), orderBy() 와 같은 연산은 실제 계산을 수행하는 것이 아니라, 어떤 작업을 수행할지에 대한 실행 계획만 생성한다.

df = spark.read.parquet('orders/')
df2 = df.filter(df.amount > 100)
df3 = df2.groupBy('city').count()
df4 = df3.orderBy('count', desc=True)

이 과정에서는 실제로 데이터 파일을 읽거나 계산하지 않는다. Spark는 단지 “데이터를 읽고 → 필터링하고 → 그룹화하고 → 정렬한다” 라는 작업 흐름(DAG, Directed Acyclic Graph)만 내부적으로 구성한다.

즉, 위 코드는 실행 계획만 수립한 상태이며, 아직 클러스터 자원도 거의 사용하지 않는다.

실제 실행은 Action 연산이 호출되는 순간 발생한다.

df4.show(20)

show()가 실행되는 시점에 Spark는 지금까지 쌓아둔 Transformation 작업들을 하나의 최적화된 실행 계획으로 구성한 뒤 한 번에 수행한다. 이때 Spark 내부에서는 다음과 같은 작업이 실제로 실행된다.

• 데이터 읽기(read)
• filter 수행
• groupBy 집계
• 정렬(sort)
• limit 처리

이처럼 Spark는 필요한 순간까지 실행을 미루었다가(Action 호출 시점) 최적화된 형태로 한 번에 처리하는데, 이를 지연 실행(Lazy Evaluation) 이라고 한다.

대표적인 Action 연산

• show()
• collect()
• count()
• first()
• take()
• foreach()
• toPandas()
• write.parquet()
• write.format()

Spark UI 읽는 법

실습 순서

1. Parquet 읽고 스키마 확인

transactions.parquet 5M 행 읽기, printSchema(), describe()

2. 집계와 groupBy

고객별 거래 횟수, 지역별 매출 합계 — DataFrame API와 SQL을 같은 결과로 비교

3. 조인과 윈도우 함수

customers ⋈ transactions, 고객별 누적 매출 랭킹 — Window.partitionBy()

4. Spark UI 분석

방금 돌린 쿼리의 Job/Stage/Task 확인, 셔플 크기, 쿼리 플랜 읽기

자주 발생하는 문제

작은 파일 문제

Kafka 적재 결과를 그대로 Parquet으로 저장하면 수만 개의 작은 파일이 생깁니다. 다음 배치 작업의 메타데이터 로딩이 데이터 처리보다 오래 걸리는 사태가 발생합니다.

→ 해법: coalesce(N) 또는 OPTIMIZE/compaction

셔플(shuffle) 과다

groupBy, join, repartition은 네트워크로 데이터를 재분배합니다. 1TB 셔플 = 1TB 네트워크 트래픽 + 디스크 IO. 가장 비싼 연산입니다.

→ 해법: 셔플 전 filter로 데이터 줄이기, 적절한 partition 수

broadcast join을 안 쓸 때

작은 테이블(< 100MB)과 큰 테이블을 join할 때 broadcast hint를 안 주면 양쪽 모두 셔플됩니다.

→ 해법: broadcast(small_df) 명시 또는 spark.sql.autoBroadcastJoinThreshold 조정

ML 파이프라인

sklearn이 아닌 Spark MLlib를 쓰는 이유

안되는 순간이 온다.

PipelineModel

Transformer는 변환, Estimator는 학습. 둘을 합쳐서 PipelineModel

범주형 처리 - StringIndexer + OneHotEncoder

• StringIndexer만 쓰면 서울=0, 부산=1, 대구=2가 되어 모델이 대구 > 서울이라고 잘못 학습

handelInvalid='keep'

학습에 없던 카테고리가 운영에서 들어와도 모델이 죽지 않도록 하는 옵션

모델 평가 지표

모델 저장과 로드

노트북에서 학습한 모델을 다른 곳에서 쓰는 방법

학습 환경 (노트북/GPU 클러스터)

# 학습 후 저장
pipeline = Pipeline(stages=[...])
model = pipeline.fit(trainDF)

# 디스크/스토리지에 저장
model.write().overwrite() \
  .save('s3://models/churn/v1')

# 또는 MLflow 레지스트리
mlflow.spark.log_model(model)

• 모든 Transformer + Estimator 상태 저장
• 학습한 인덱싱 사전, 가중치, 분기 규칙 모두
• MLflow 사용시 버전 관리 자동

서빙 환경 (실시간 추론 클러스터)

# 운영 환경에서 로드
from pyspark.ml import PipelineModel

model = PipelineModel.load(
  's3://models/churn/v1'
)

# 새 데이터에 그대로 적용
predictions = model.transform(newCustomers)
predictions.select('id', 'prediction').show()

• 학습 코드의 전처리 그대로 재현됨
• 환경만 다르면 됨 — 코드는 동일
• Part 3 스트리밍에서도 그대로 사용

실시간 스트리밍 - Kafka + Structured Streaming

배치 Batch

특징

• 데이터를 모아서 한 번에 처리
• 처리량 지연: 분~시간 단위
• 처리량이 크고 비용 효율적
• 데이터 경계가 명확 (시작/끝)

언제 쓰나

• $\rightarrow$ 일배치 리포트, 월말 정산, ML 학습
• $\rightarrow$ "어제까지의 데이터로 OK"인 경우
• $\rightarrow$ DataFrame · spark.read.parquet()

스트리밍 Streaming

특징

• 데이터가 도착하는 즉시 처리
• 지연: 초~분 단위
• 24시간 무중단, 운영 부담 $\uparrow$
• 데이터 경계가 모호 (스트림은 끝이 없음)

언제 쓰나

• $\rightarrow$ 실시간 추천, 이상 탐지, 알림
• $\rightarrow$ "지금 막 일어난 일에 반응" 필요
• $\rightarrow$ spark.readStream.format("kafka")

Lambda 아키텍처

배치의 정확성 + 스트리밍 즉시성

Kafka

분산 메시지 큐의 표준

필요한 이유

DB에 직접 쓰면 안되는 이유 제공해주신 이미지 속에 적힌 텍스트를 그대로 추출하여 정리해 드립니다.

1. 트래픽 흡수

Peak 시점 보호 광고 폭주, 이벤트로 초당 트래픽이 10배 뛰어도 Kafka가 흡수. Consumer는 자기 속도로 처리. $\rightarrow$ DB가 죽지 않음

2. 데이터 내구성

재처리 가능 메시지는 디스크에 저장 $\rightarrow$ Consumer 장애 시 처음부터 재처리. 일주일 전 데이터도 다시 읽기 가능. $\rightarrow$ 데이터 손실 없음

3. 다중 소비자

Pub/Sub 한 번 적재한 데이터를 Spark Streaming, 알림 시스템, 분석 DB가 각자 독립 소비. Producer는 누가 읽는지 몰라도 됨. $\rightarrow$ 소비자 추가 자유

4. 비동기 분리

느슨한 결합 Producer와 Consumer가 같은 시간에 살 필요 없음. Consumer가 잠시 죽어도 Producer는 계속 발행. $\rightarrow$ 시스템 독립성

Structured Streaming

실시간 스트림 = 무한히 자라는 테이블. 그 테이블에 대한 SQL은 짧은 주기로 다시 실행됩니다.

체크포인트와 멱등성

Checkpoint

Spark가 처리 상태를 디스크에 주기 저장

query = df.writeStream \
  .option(
    'checkpointLocation',
    's3://checkpoints/job1/'
  ) \
  .start()

저장되는 것

• 어디까지 처리했는가 (Kafka offset)
• 진행 중이던 집계 상태
• 메타데이터 로그
• $\rightarrow$ 재시작 시 정확히 그 지점부터 이어서 처리*

멱등성 (Idempotency)

같은 메시지가 두 번 와도 결과 같게 만들기

왜 필요한가 Kafka는 "at-least-once" 보장. 장애 복구 시 같은 메시지가 두 번 처리될 수 있음.

멱등 적재 패턴

• Primary Key 기반 upsert (MERGE)
• Delta Lake MERGE INTO 활용
• 메시지 ID로 중복 제거

Checkpoint + 멱등 = effectively exactly-once

실습

Docker로 Kafka 띄우기 $\rightarrow$ Producer 만들기 $\rightarrow$ Topic 설계 $\rightarrow$ Partition 실험

Structured Streaming 첫 쿼리 $\rightarrow$ JSON 파싱 $\rightarrow$ 윈도우 집계 $\rightarrow$ trigger 비교

Part 2의 PipelineModel 로드 $\rightarrow$ 실시간 추론 $\rightarrow$ PostgreSQL 멱등 적재

프로듀서 강제 종료 $\rightarrow$ 체크포인트 복구 검증 $\rightarrow$ exactly-once 확인

환경 준비

1. azure portal에서 vm 생성
2. 쉘에서 ssh로 접속
3. 가상머신에 라이브러리 설치

• APT (Advanced Package Tool): Debian/Ubuntu 계열 패키지 관리자. apt update로 패키지 목록 갱신, apt upgrade로 실제 업그레이드.
• OpenJDK 17: 오라클 JDK의 오픈소스 구현. Spark 3.5.x는 Java 8/11/17 공식 지원.
• JDK vs JRE: JDK = JRE + 컴파일러/디버거. 개발용은 JDK, 실행만 한다면 JRE. Spark도 PySpark 호출 시 내부적으로 JVM 실행이 필요하므로 JDK 권장.
• PEP 668 (Externally Managed Environment): Ubuntu 23.04부터 시스템 Python에 pip install을 직접 막는 정책. 시스템 패키지(apt)와 pip 패키지 충돌로 인한 OS 손상 방지가 목적. 해결책은 venv 가상환경 사용 (권장) 또는 --break-system-packages 플래그 (비권장).

  sudo apt update && sudo apt upgrade -y
  sudo apt install -y openjdk-17-jdk
  sudo apt install -y python3-pip python3-venv python3-full wget curl
  python3 -m venv ~/sparkenv
  source ~/sparkenv/bin/activate

Spark 설치

• Apache Spark: 분산 데이터 처리 엔진. 메모리 기반 연산으로 Hadoop MapReduce 대비 빠름. SQL/스트리밍/ML/그래프 통합 API 제공.
• Spark 3.5.8: 3.5 LTS 라인의 최신 maintenance 릴리스 (2027.11까지 보안 패치). Java 17 정식 지원.
• Hadoop3 prebuilt: Spark는 Hadoop의 HDFS 클라이언트 라이브러리를 사용해 다양한 스토리지(S3, ADLS 등) 접근. bin-hadoop3 패키지는 Hadoop 3.x 라이브러리가 포함된 사전 빌드 버전 → 별도 빌드 불필요.
• Standalone 모드: Spark 자체 클러스터 매니저. 본 핸즈온은 단일 노드에서 standalone(또는 local) 모드로 동작.
• /opt: Linux 전통적으로 third-party 애플리케이션 설치 디렉터리. /usr/local도 가능하나 /opt가 더 격리적.

cd ~
wget https://dlcdn.apache.org/spark/spark-3.5.8/spark-3.5.8-bin-hadoop3.tgz

tar -xzf spark-3.5.8-bin-hadoop3.tgz
sudo mv spark-3.5.8-bin-hadoop3 /opt/spark
sudo chown -R azureuser:azureuser /opt/spark
rm spark-3.5.8-bin-hadoop3.tgz

📂 리눅스 주요 디렉토리 구조

1. /opt (Optional)

• 의미: 추가적인 독립 소프트웨어 패키지가 설치되는 곳입니다.
• 용도: 시스템 기본 패키지 관리자(apt)가 관리하지 않는, 외부 서드파티 애플리케이션(예: Google Chrome, 전용 데이터베이스, 특정 벤더의 도구 등)이 설치됩니다.
• 특징: 보통 한 프로그램이 하나의 하위 디렉토리에 모든 파일(bin, lib 등)을 통째로 가지고 있는 경우가 많습니다.

2. /var (Variable)

• 의미: 시스템 운영 중 내용이 시시각각 변하는 파일들이 저장되는 곳입니다.
• 용도: /var/log: 시스템 및 애플리케이션의 *로그 파일** (가장 자주 확인하게 되는 곳).
• /var/lib: 데이터베이스나 패키지 상태 정보.
• /var/spool: 메일이나 인쇄 대기열.

• 특징: 용량이 계속 늘어날 수 있는 데이터가 많아, 서버 구축 시 별도의 파티션으로 분리하기도 합니다.

3. /etc (Et cetera / Editable Text Configuration)

• 의미: 시스템 전체의 설정 파일(Configuration files)이 들어있는 곳입니다.
• 용도: 네트워크 설정, 사용자 비밀번호 파일, 설치된 프로그램의 설정값(.conf) 등이 위치합니다.
• 특징: 텍스트 파일로 되어 있어 관리자가 직접 수정할 수 있습니다.

4. /usr (Unix System Resources)

• 의미: 사용자가 실행하는 대부분의 프로그램과 읽기 전용 데이터가 들어있습니다.
• 용도: */usr/bin: 일반 사용자가 실행하는 실행 파일.
• /usr/local: 사용자가 소스 코드로 직접 빌드해서 설치한 프로그램이 위치하는 곳 (/opt와 유사하지만 더 전통적인 방식).

Windows와 Linux 경로 비교

환경변수 설정

nano ~/.bashrc

파일 맨 아래에 추가

# ===== Apache Spark =====
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export SPARK_HOME=/opt/spark
export PYSPARK_PYTHON=python3

# Python venv 자동 활성화
source ~/sparkenv/bin/activate
# Python venv 활성화 후 path 추가
export PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin

#적용
source ~/.bashrc

Spark Shell 실행

spark-shell --master "local[2]" --driver-memory 2g

PySpark

pyspark --master "local[2]" --driver-memory 2g

SparkPi

spark-submit \
  --master "local[2]" \
  --driver-memory 2g \
  --class org.apache.spark.examples.SparkPi \
  $SPARK_HOME/examples/jars/spark-examples_2.12-3.5.8.jar \
  100

jupyter lab 연동

• Jupyter Lab: 노트북 기반 인터랙티브 개발 환경. 코드/마크다운/시각화를 셀 단위로 실행.
• 포트 8888: Jupyter Lab 기본 포트. Azure NSG에서 별도 허용 필요.
• SSH 터널링 (권장): Jupyter 포트를 외부에 직접 노출하지 않고, SSH 채널을 통해 로컬 PC의 포트로 포워딩. 보안적으로 안전.

설치

pip install --upgrade pip
pip install jupyterlab pyspark==3.5.8 pandas matplotlib

참고: pyspark==3.5.8 은 /opt/spark 설치본과 별도로 Python에서 import 가능하도록 PyPI 패키지 설치. 두 버전이 일치해야 충돌 없음.

실행(8888 터널링)

jupyter lab --no-browser --ip=0.0.0.0 --port=8888

이후 token 부분 복사

새 로컬 쉘에서 실행

ssh -L 8888:localhost:8888 azureuser@<VM_PUBLIC_IP>

이후 http://localhost:8888/lab?token=<위에서_복사한_토큰> 접속

메모리 설정

• spark.driver.memory: 드라이버 JVM 힙 크기. SparkContext가 사용. collect()로 큰 결과를 가져올 때 이 값이 부족하면 OOM.
• spark.executor.memory: 익스큐터 JVM 힙 크기. 실제 task 실행 메모리. 단일 노드 local 모드에선 driver와 executor가 같은 JVM이라 driver memory만 의미 있음. standalone/YARN/K8s 클러스터에선 별개.
• spark.driver.maxResultSize: collect() 결과 최대 크기. 기본 1g. 초과 시 abort.
• JVM 오버헤드: 힙 크기 외에 메타스페이스, 코드 캐시, GC 등 추가 메모리 (보통 힙의 10~15%).
• OS 점유: Ubuntu + 시스템 데몬 = 약 600MB~1GB.

cp $SPARK_HOME/conf/spark-defaults.conf.template $SPARK_HOME/conf/spark-defaults.conf
nano $SPARK_HOME/conf/spark-defaults.conf

밑에 추가

spark.driver.memory              3g
spark.driver.maxResultSize       1g
spark.sql.shuffle.partitions     4

데이터 정제와 머신러닝

합성 데이터 생성: Faker + Spark로 현실적인 더티 데이터 만들기 EDA & 정제: 결측/중복/이상치/일관성 문제를 PySpark로 처리 피처 엔지니어링: 두 테이블 join, 집계, 타겟 변수 생성 분류 ML: Pipeline API로 고객 이탈 예측 모델 구축 및 평가 회귀 ML (보너스): 거래액 예측 모델

• Faker: Python의 가짜 데이터 생성 라이브러리. 이름·주소·이메일·날짜 등 현실적인 더미 데이터 생성. 학습/테스트용 데이터 제작에 표준.
• 합성 데이터 (Synthetic Data): 실제 데이터를 모방해 생성한 인공 데이터. 개인정보 우려 없이 ML 학습/테스트 가능.
• Parquet: 컬럼 지향(Columnar) 압축 포맷. CSV 대비 1) 압축률 5~10배, 2) 스키마 보존, 3) 컬럼 단위 읽기 가능 → Spark 표준 포맷.
• dirty data 주입: 학습용 데이터에 의도적으로 결측·중복·이상치를 섞는 기법. 정제 실습에 필수.

추가 라이브러리 설치

source ~/sparkenv/bin/activate
pip install faker

합성데이터 생성

• SparkSession.createDataFrame(): Python 리스트/Pandas DataFrame을 Spark DataFrame으로 변환. driver 메모리 사용하므로 대용량은 부적합.
• schema 명시: StructType으로 스키마 명시 → 자동 추론보다 빠르고 정확.
• Spark 데이터 타입: IntegerType, LongType, StringType, TimestampType, DoubleType, BooleanType 등.
• 결측 표현: Spark는 None (Python) → null (Spark)로 변환. NumPy의 NaN과 다름 주의.
• .write.mode("overwrite").parquet(): 기존 디렉터리 덮어쓰기. mode("append")는 추가, mode("error")는 기본값.

SparkSession 생성

데이터 생성

경고가 뜬다면, 이유:

• Spark는 driver의 데이터를 task로 보낼 때 직렬화해서 워커에 전송
• 50,000개 transaction을 Python 리스트로 만들어 createDataFrame에 넘기면 driver가 통째로 직렬화
• 그 직렬화 페이로드가 1131 KiB > Spark 권장값 1000 KiB 큰 문제 아니나 해결하려면, partition을 명시적으로 나눠서 만들면 됩니다:

  # 기존 방식 (driver가 한 덩어리로 전송)
  transactions_df = spark.createDataFrame(transactions_data, schema=transactions_schema)

  # 개선 방식 (4개 partition으로 분할 전송)
  transactions_rdd = spark.sparkContext.parallelize(transactions_data, numSlices=4)
  transactions_df = spark.createDataFrame(transactions_rdd, schema=transactions_schema)

  numSlices=4로 데이터를 4등분해서 보내므로 각 task ~283 KiB로 줄어듭니다.

parquet로 저장

데이터 탐색 (EDA)

• EDA (Exploratory Data Analysis): 모델링 전 데이터의 특성/품질을 파악하는 단계. 통계 요약, 분포, 결측 패턴, 상관관계 등.
• describe() vs summary(): 둘 다 통계 요약. summary()가 더 풍부 (count, mean, stddev, min, percentiles, max).
• dtypes / printSchema(): 컬럼 타입 확인. 정제 전 반드시 검토.
• PySpark → Pandas 변환 주의: .toPandas()는 driver 메모리에 전체를 수집(collect). 큰 데이터에선 OOM 위험. 시각화 직전 작은 집계 후 변환할 것.

데이터 정제

• 결측치 처리 전략: 1) 행 제거(dropna), 2) 평균/중앙값 대체(fillna), 3) 그룹별 대체, 4) 별도 카테고리("UNKNOWN") 부여. 어느 것이 좋은지는 도메인과 결측 비율에 따름.
• when().otherwise(): SQL의 CASE WHEN. 조건부 값 변환에 사용.
• F.trim(), F.upper(), F.lower(): 문자열 정규화 함수.
• 이상치 처리: 1) 제거(필터), 2) winsorize(상하한 자르기), 3) 변환(log). 도메인 지식이 핵심.
• dropDuplicates(): 모든 컬럼 또는 지정 컬럼 기준 중복 제거. 첫 번째 row를 유지.

피처 엔지니어링

• 피처 엔지니어링 (Feature Engineering): 원시 데이터에서 모델 학습에 유용한 변수를 만드는 과정. ML 성능의 70~80%는 피처에서 결정된다는 격언도 있음.
• RFM 분석:
  • Recency: 마지막 거래 후 경과일 → 작을수록 활성
  • Frequency: 거래 횟수 → 클수록 충성
  • Monetary: 총 거래액 → 클수록 가치 높음. 고객 세분화·이탈 예측의 고전적 피처
• Window Function: 행 간 관계 연산. 누적합, 순위, 이전 값 참조 등.
• groupBy().agg(): SQL의 GROUP BY + 집계함수. F.sum, F.avg, F.count, F.countDistinct, F.max, F.min 등.
• 타겟 변수 (Label): 지도학습에서 예측할 값. 본 시나리오에서는 "최근 30일 비활동 = 이탈"로 정의.

정제 데이터 로드

거래 데이터 집계

추가 피처: 카테고리 선호

고객 정보와 join

타겟 변수: 이탈 정의

최종 피처셋 저장

머신러닝: 이탈 예측 (분류)

• Spark MLlib: Spark의 분산 ML 라이브러리. 두 API 존재: pyspark.ml (DataFrame 기반, 현재 권장) pyspark.mllib (RDD 기반, 유지보수만 됨)
• Pipeline: 전처리 + 모델을 단일 객체로 묶음. 학습/예측 시 동일 변환 보장 → 데이터 누수 방지.
• StringIndexer: 범주형 문자열을 정수 인덱스로 변환. [“KR”,”US”,”KR”] → [0.0, 1.0, 0.0].
• OneHotEncoder: 인덱스를 희소 벡터로. 0 → [1,0,0], 1 → [0,1,0]. 트리 모델은 불필요하나 선형 모델엔 필수.
• VectorAssembler: 여러 피처 컬럼을 하나의 vector 컬럼으로 결합. ML 알고리즘 입력 표준 형식.
• LogisticRegression: 이진 분류의 베이스라인 모델. 확률 출력, 해석 용이.
• train/test split: randomSplit([0.8, 0.2])로 학습 80% / 평가 20% 분리.
• 평가 지표:
  • `Accuracy : 전체 정답률. 클래스 불균형 시 오해 소지.
  • AUC (ROC): 임계값 무관 분류 성능. 0.5=무작위, 1.0=완벽, 0.7+=쓸만함.
  • Confusion Matrix: TP/FP/TN/FN 행렬.
  • Precision/Recall/F1: 클래스별 세부 성능.

피처 로드 및 분할

Pipeline 구성

학습

평가

Confusion Matrix

피처 중요도 (계수)

모델 저장 및 로드

실시간 데이터 파이프라인 — Kafka + PostgreSQL + Spark Structured Streaming + 배치 ML 추론

1. PostgreSQL 16을 같은 VM에 설치·운영 (Spark·Kafka와 8GB 안에서 공존)
2. Kafka 3.x 단일 노드를 KRaft 모드로 설치 (ZooKeeper 없이)
3. Python 프로듀서로 가짜 거래 이벤트를 Kafka 토픽에 발행
4. Spark Structured Streaming으로 Kafka 토픽 구독·정제·PostgreSQL 적재
5. PostgreSQL 데이터를 PySpark로 다시 읽어 분석·조회
6. Part 2의 학습된 ML 모델을 운영 DB의 신규 데이터에 적용 (배치 추론)
7. systemd + cron으로 파이프라인 자동화·운영
8. SQL·Kafka CLI·Spark UI로 파이프라인 모니터링

데이터 웨어하우스(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는 분산 시스템에서 중요한 세 가지 특성이다.