[클라우드응용SW개발] 3. 클라우드 데이터 플랫폼(1)

지난 실습을 통해 VM에 Streamlit 앱을 올리는 방법을 배웠다.

근데 데이터를 어디에 저장하지?

파일에 쓸까? SQLite? 아니면 MySQL?

온라인 주문 웹사이트를 만든다고 치면,

사용자가 입력한 주문 데이터는 트랜잭션이 보장돼야 하고,

상품 이미지는 테이블에 못 넣고,

행동 로그는 매번 스키마가 달라진다.

그러므로 우리는

데이터 종류마다 저장 전략이 다르다는 걸 먼저 이해하고

DB를 직접 설치할지, 클라우드 Managed 서비스를 쓸지도 결정해야 한다.

---

3-1. 클라우드 기반의 데이터 플랫폼

데이터의 구분

데이터는 저장 방식에 따라 크게 세 가지로 나뉜다.

구조화(Structured) 데이터 — 행과 열로 이루어진 테이블 형태의 데이터다. RDB에 들어가는 데이터가 대표적이다. 스키마가 명확하게 정의되어 있고, SQL로 조회할 수 있다. 고객 정보, 주문 내역, 재고 현황 등 비즈니스의 핵심 데이터가 여기에 해당한다.

반구조화(Semi-structured) 데이터 — 테이블 형태는 아니지만 나름의 구조(태그, 키-값)를 가진 데이터다. JSON, XML, AVRO, ORC, Parquet 같은 포맷이 여기에 속한다. 같은 컬렉션 내에서도 document마다 필드가 다를 수 있다는 점이 구조화 데이터와의 결정적 차이다. API 응답, 로그 데이터, IoT 센서 데이터 등이 반구조화에 해당한다.

비구조화(Unstructured) 데이터 — 이미지, 영상, 음성, 텍스트 파일 등 정해진 포맷이 없는 데이터다. 전체 데이터의 80% 이상이 비구조화 데이터라는 통계도 있을 만큼 현대 IT 환경에서 차지하는 비중이 점점 커지고 있다.

구분	형태	예시	저장소
구조화	테이블(행/열)	고객 DB, 주문 테이블	RDBMS
반구조화	키-값, 태그 기반	JSON, XML, Parquet	Document DB, Data Lake
비구조화	포맷 없음	이미지, 영상, 음성	Blob Storage, Object Storage

OLTP와 OLAP

데이터를 다루는 워크로드는 목적에 따라 두 가지로 나뉜다.

OLTP(Online Transaction Processing) — 트랜잭션 처리에 초점을 맞춘 워크로드다. 쇼핑몰의 주문 처리, 은행의 이체 처리처럼 데이터를 한 건씩 빠르게 읽고 쓰는 작업이다. 정규화된 테이블 구조에서 동작하며, 동시에 수많은 사용자가 접근해도 데이터 무결성을 보장해야 한다.

OLAP(Online Analytical Processing) — 분석 처리에 초점을 맞춘 워크로드다. OLTP에서 쌓인 대량의 데이터를 주기적으로 집계해서 큐브(다차원 모델)에 저장하고, 요약·추세·비즈니스 인사이트를 뽑아내는 것이 목적이다. Data Warehouse가 대표적인 OLAP 시스템이다.

실무에서 흔히 하는 실수가 OLTP 데이터베이스에 분석 쿼리를 직접 날리는 것이다. 무거운 집계 쿼리가 트랜잭션 처리 성능을 잡아먹으면서 서비스 장애로 이어지는 경우가 많다. OLTP와 OLAP는 분리하는 게 원칙이다.

트랜잭션 워크로드와 ACID

트랜잭션 데이터는 조직의 활동과 관련된 상호 작용을 추적하는 정보다. 트랜잭션은 반드시 ACID 속성을 만족해야 한다.

속성	설명
Atomicity (원자성)	트랜잭션은 전부 성공하거나 전부 실패하는 단일 단위로 처리된다. 중간 상태는 없다.
Consistency (일관성)	트랜잭션 전후로 데이터베이스는 항상 유효한 상태를 유지한다.
Isolation (격리성)	동시에 실행되는 여러 트랜잭션이 서로 간섭하지 않는다.
Durability (영속성)	커밋된 트랜잭션은 시스템 장애가 발생해도 유지된다.

은행 이체를 예로 들면, A 계좌에서 출금은 됐는데 B 계좌에 입금이 안 되는 상황이 있으면 안 된다. 출금과 입금이 하나의 원자적 단위로 처리되어야 하고(Atomicity), 이체 후 총 금액은 변하지 않아야 하며(Consistency), 동시에 여러 이체가 일어나도 꼬이지 않아야 하고(Isolation), 이체 완료 후에는 서버가 죽어도 결과가 보존되어야 한다(Durability).

분석 워크로드

분석 워크로드는 OLTP에서 축적된 트랜잭션 데이터를 기반으로 요약, 추세 분석, 비즈니스 인텔리전스를 도출하는 데 사용된다. 대량의 데이터를 읽어서 집계하는 작업이 주를 이루기 때문에, OLTP와는 테이블 설계 철학부터 다르다. Star Schema, Snowflake Schema 같은 비정규화된 구조를 사용하는 것이 일반적이다.

일괄 처리와 스트림 처리

데이터 처리 방식은 타이밍에 따라 두 가지로 나뉜다.

일괄 처리(Batch Processing) — 데이터를 모아뒀다가 한꺼번에 처리하는 방식이다. 일별/주별 배치 작업이 대표적이다. 모든 입력 데이터가 준비된 후에 처리가 시작되고, 처리 완료 후 결과를 한번에 출력한다. Hadoop MapReduce, Spark Batch, 전통적인 ETL 파이프라인이 여기에 해당한다.

스트림 처리(Stream Processing) — 데이터가 도착하는 즉시 실시간으로 처리하는 방식이다. IoT 센서 데이터, 실시간 로그 분석, 주식 거래 모니터링 같은 시나리오에서 쓰인다. Apache Kafka, Apache Flink, Azure Stream Analytics 등이 대표적인 도구다.

구분	일괄 처리	스트림 처리
처리 타이밍	데이터 축적 후 한꺼번에	도착 즉시 실시간
지연 시간	분~시간 단위	밀리초~초 단위
적합한 시나리오	일일 정산, 보고서 생성	실시간 알림, 이상 탐지
대표 도구	Spark Batch, Hadoop	Kafka, Flink, Stream Analytics

비관계형 데이터

비관계형 데이터는 테이블 형식에 얽매이지 않는다. 같은 컬렉션 내에서도 document마다 필드가 다를 수 있고, 스키마가 유연하다. 이런 특성 때문에 빠르게 변하는 요구사항이나 다양한 형태의 데이터를 다뤄야 하는 환경에 적합하다.

비관계형 데이터의 특징을 정리하면:

• 같은 컬렉션(컨테이너) 내에서 각 entity가 서로 다른 필드를 가질 수 있다
• 테이블 형식이 아닌 여러 스키마를 포함한다
• 각 필드는 이름(key)으로 정의되는 경우가 많다

비관계형 데이터 사용 사례

분야	설명
IoT 및 텔레매틱스	대량의 데이터를 빈번하게 수집해야 하고, 반구조화/구조화 혼재, 실시간 처리 필요
소매 및 마케팅	전 세계 분산 데이터, document storage 기반의 유연한 구조
게임	게임 내 통계, 소셜 미디어 통합, 순위표 등 low latency 필수
웹 및 모바일	클릭 분석, 챗봇 등 최신 애플리케이션에 범용적으로 사용

반구조화 데이터 포맷

반구조화 데이터는 데이터 구조가 데이터 자체 내에 필드별로 정의되는 특징이 있다. 대표적인 포맷은 다음과 같다:

• JSON — 가장 범용적. REST API, NoSQL DB에서 사실상 표준
• AVRO — 스키마를 바이너리에 포함. Kafka 메시지 직렬화에 주로 사용
• ORC — Hive 최적화 컬럼 포맷. 대규모 배치 처리에 유리
• Parquet — 컬럼 기반 저장 포맷. Spark, BigQuery 등 분석 워크로드에 최적

NoSQL 데이터베이스 유형

NoSQL은 비관계형 데이터베이스를 통칭하는 느슨한 용어다. 데이터 모델에 따라 크게 네 가지로 분류된다.

유형	설명	대표 제품
Key-Value Store	단순 키-값 쌍. 캐시, 세션 관리에 적합	Redis, DynamoDB
Document DB	JSON/BSON document 단위 저장. 유연한 스키마	MongoDB, Cosmos DB
Column Family DB	컬럼 기반 저장. 대규모 분산 환경에 적합	Cassandra, HBase
Graph DB	노드와 에지로 관계를 표현. 소셜 네트워크, 추천 시스템	Neo4j, Cosmos DB (Gremlin)

Graph DB는 entity를 관계 중심으로 저장하고, 노드 및 에지 네트워크를 순회하는 쿼리를 수행할 수 있다. 조직도, 소셜 네트워크, 지식 그래프 같이 관계의 깊이와 패턴이 중요한 시나리오에서 RDBMS의 JOIN보다 훨씬 효율적이다.

---

3-2. 클라우드 Open Source Database

Azure에서 제공하는 Open Source Database

Azure는 대표적인 Open Source RDBMS 세 가지를 PaaS 형태로 제공한다.

서비스	기반 엔진	특징
Azure Database for PostgreSQL	PostgreSQL Community Edition	고급 데이터 타입, JSON 지원, 확장성 우수. 복잡한 쿼리와 분석 워크로드에 강점
Azure Database for MySQL	MySQL Community Edition	가장 널리 쓰이는 오픈소스 RDBMS. 웹 애플리케이션 백엔드의 사실상 표준
Azure Database for MariaDB	MariaDB Community Edition	MySQL에서 fork된 엔진. MySQL과 호환되면서 일부 성능 개선

셋 다 Community Edition 기반이므로 온프레미스에서 쓰던 도구와 코드를 거의 그대로 가져갈 수 있다. 차이는 인프라 관리를 Azure가 대신 해준다는 점이다.

클라우드 Managed Database의 장점

직접 VM에 MySQL을 설치해서 운영하는 것과 Azure Database for MySQL(PaaS)을 쓰는 것은 완전히 다른 경험이다.

완전 관리형 서비스 — 패치, 백업, 모니터링, failover를 Azure가 알아서 처리한다. DBA 없이도 프로덕션 수준의 DB 운영이 가능하다.

고가용성 기본 제공 — 추가 비용 없이 built-in HA가 포함된다. 수동으로 replication을 구성할 필요가 없다.

지능형 성능 및 확장 — 최대 16TB 스토리지, 20K IOPS까지 지원하며, 빌트인 인텔리전스가 성능 병목을 자동 감지한다.

보안 및 규정 준수 — Advanced Threat Protection, 저장 데이터 암호화(Encryption at Rest), SSL 연결 강제 등이 기본 포함된다.

Azure 에코시스템 통합 — App Service, Functions, AKS 등 Azure 서비스와 네이티브로 연결된다. Private Link를 통해 VNet 내부에서만 접근하도록 구성하는 것도 간단하다.

관계형 데이터 서비스 구성

Azure에서 Open Source Database를 프로비저닝할 때 설정해야 하는 주요 항목은 다음과 같다.

단계	설정 항목
기초	구독, 리소스 그룹, 서버 이름, DB 이름, 관리자 로그인/암호, 지역, 컴퓨팅+스토리지
네트워크 연결	공개/비공개 액세스, VNet 규칙, 방화벽 규칙
추가 설정	데이터 원본, 데이터 정렬, 표준 시간대, Advanced Data Security
태그	리소스 분류를 위한 key-value 태그
검토 및 만들기	이용 약관 확인 후 배포

실무에서는 네트워크 설정이 가장 중요하다. 기본값인 공개 액세스 대신, Private Endpoint + VNet 통합으로 구성하는 게 보안상 권장된다. 방화벽 규칙에서 0.0.0.0/0을 열어두는 건 개발 환경에서도 피하는 게 좋다.

Azure 내에서 Database 연결 정책

Azure SQL Database(및 유사한 Managed Database)에 접근할 때 두 가지 연결 정책이 있다.

리디렉션(Redirect) 정책:

1. 애플리케이션이 게이트웨이를 통해 최초 연결을 설정한다
2. 첫 번째 요청 이후 모든 요청은 실제 DB 노드로 직접 전송된다(게이트웨이 bypass)
3. 연결 실패 시 게이트웨이를 통해 재연결한다
4. 클러스터 내 다른 replica로 연결될 수도 있다

프록시(Proxy) 정책:

1. 애플리케이션이 게이트웨이를 통해 연결을 설정한다
2. 모든 요청이 항상 게이트웨이를 경유한다
3. 클러스터 내 다른 replica로 연결될 수도 있다

정책	지연 시간	적합한 시나리오
Redirect	낮음 (첫 연결 이후 직접 통신)	Azure 내부에서 접속하는 경우
Proxy	상대적으로 높음 (항상 게이트웨이 경유)	Azure 외부에서 접속하는 경우

Azure 내부(같은 region)에서 접근한다면 Redirect가 기본이고 성능도 더 좋다. 외부에서 접근하는 경우에는 Proxy가 기본 적용된다.

---

3-3. 클라우드 데이터 플랫폼의 관리도구

역할별로 다른 도구

데이터를 다루는 사람은 한 종류가 아니다.

DB를 직접 관리하는 사람, 데이터를 옮기고 가공하는 사람, 분석해서 인사이트를 뽑는 사람.

각자 하는 일이 다르니, 쓰는 도구도 다르다.

크게 세 가지 역할로 나뉜다.

역할	주요 업무	대표 도구
데이터베이스 관리자 (DBA)	DB 관리, 보안 구현, 백업, 사용자 액세스 제어, 성능 모니터링	Azure Data Studio, SSMS, Azure Portal/CLI
데이터 엔지니어	데이터 파이프라인 구축, 데이터 수집/저장, 분석용 데이터 준비	Azure Synapse Studio, SSMS, Azure Portal/CLI
데이터 분석자	인사이트 도출, 시각화, 데이터 모델링, 보고서 작성	Power BI Desktop, Power BI Service, Power BI 보고서 작성기

실무에서는 이 역할이 명확하게 나뉘지 않는 경우도 많다. 스타트업이나 소규모 팀에서는 한 사람이 DBA와 데이터 엔지니어를 겸하는 게 흔하고, 분석까지 같이 하는 경우도 있다. 하지만 도구의 목적을 이해하고 있으면 필요할 때 적절한 도구를 꺼내 쓸 수 있다.

다양한 관리 도구

Azure 환경에서 데이터베이스를 관리할 때 쓸 수 있는 도구는 생각보다 다양하다.

도구	특징
Azure Portal	웹 브라우저 기반. 리소스 프로비저닝부터 모니터링까지 GUI로 처리
SQL Server Management Studio (SSMS)	Windows 전용. 가장 포괄적인 DB 관리 도구. 온프레미스/클라우드 모두 지원
SQL Server Data Tools (SSDT)	Visual Studio 통합. DB 프로젝트 단위로 스키마 관리, CI/CD 파이프라인에 적합
Azure Data Studio	크로스 플랫폼(Windows/macOS/Linux). 경량 GUI. Notebook 지원
SQLCMD	CLI 기반 쿼리 도구. 스크립트 자동화에 유용
Azure CLI / Cloud Shell	Azure 리소스를 명령줄로 관리. ARM 템플릿과 결합하면 인프라 자동화 가능

SSMS가 가장 기능이 풍부하지만 Windows에서만 돌아간다는 제약이 있다. macOS나 Linux를 쓴다면 Azure Data Studio가 대안이다. 자동화가 목적이라면 Azure CLI + SQLCMD 조합이 낫다.

MySQL Workbench로 Azure Database 관리

Azure Database for MySQL을 쓸 때는 MySQL Workbench로 직접 접속해서 쿼리를 날릴 수 있다.

접속 설정 시 핵심 항목:

• Hostname: <서버이름>.mysql.database.azure.com
• Port: 3306
• Username: <관리자계정>@<서버이름>
• Connection Method: Standard (TCP/IP)
• SSL: Azure Managed MySQL은 기본적으로 SSL 연결을 강제하므로, SSL 탭에서 CA 인증서를 지정해야 한다

접속 후에는 로컬 MySQL과 동일하게 CREATE DATABASE, INSERT, SELECT 등 표준 SQL을 그대로 쓸 수 있다. PaaS라서 인프라가 다를 뿐, SQL 레벨에서는 차이가 없다.

---

실습 진행

우선 이번주에는 3-2의 내용까지만 실습을 진행해보겠다.

리소스 그룹 생성 후, 이번에는 MySQL 리소스를 만든다.

요거 만들기

---

정리

• 데이터는 구조화, 반구조화, 비구조화 세 가지로 분류되며, 각각 저장/처리 전략이 다르다
• OLTP는 트랜잭션 처리, OLAP는 분석 처리에 특화되어 있고, 이 둘은 반드시 분리해야 한다
• 트랜잭션은 ACID 속성을 만족해야 데이터 무결성이 보장된다
• 일괄 처리는 데이터를 모아서 한꺼번에, 스트림 처리는 도착 즉시 실시간으로 처리한다
• NoSQL은 Key-Value, Document, Column Family, Graph 네 가지 유형으로 나뉜다
• Azure는 PostgreSQL, MySQL, MariaDB를 PaaS로 제공하며, 관리형 서비스의 장점(HA, 보안, 자동 백업)을 그대로 누릴 수 있다
• 클라우드 DB 연결 시 Redirect와 Proxy 정책의 차이를 이해하고 환경에 맞게 선택해야 한다
• Azure 환경에서는 Azure Portal, SSMS, Azure Data Studio, Azure CLI 등 다양한 관리 도구를 제공한다
• SSMS는 가장 포괄적이지만 Windows 전용이고, Azure Data Studio는 크로스 플랫폼을 지원한다
• Azure Database for MySQL은 MySQL Workbench로 접속해서 기존과 동일한 방식으로 관리할 수 있다
• 자동화가 필요하면 Azure CLI + SQLCMD 조합을 활용한다