[클라우드 응용 SW 개발] 4,5주차

4주차: 클라우드 응용 SW 개념 정리

---

1. 데이터의 구분

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

• 구조화 데이터: 행과 열로 구성된 테이블 형태. 스키마가 고정되어 있어 정형화된 데이터를 다루기에 적합하다.
• 반구조화 데이터: JSON처럼 일정한 형식은 있지만 고정된 스키마가 없는 데이터.
• 비구조화 데이터: 이미지, 음성, 영상처럼 형태가 정해지지 않은 데이터.

---

2. 관계형 데이터베이스의 주요 객체

2-1. 테이블 (Table)

• 데이터가 실제로 저장되는 공간
• 행(Row)과 열(Column)로 구성되며, 모든 행은 동일한 열 구조를 가진다
• 각 열은 데이터 타입으로 정의된다 (예: INT, VARCHAR)

2-2. 엔티티 (Entity)

• 실제 존재하는 항목(고객, 제품)이나 가상의 항목(주문)을 나타낸다
• 엔티티 간에는 관계(Relationship)가 존재한다 (예: 고객이 제품을 주문한다)

2-3. 정규화 (Normalization)

• 데이터 중복을 제거하고 일관성을 높이기 위해 테이블을 분리하는 작업
• 효과: 저장 공간 절약, 데이터 중복 방지, 데이터 품질 향상

2-4. 관계 (Relationship)

• 기본 키(Primary Key): 각 행을 고유하게 식별하는 열
• 외래 키(Foreign Key): 다른 테이블의 기본 키를 참조하는 열
• 정규화된 스키마에서는 테이블을 JOIN해서 데이터를 조회한다

2-5. 인덱스 (Index)

• 데이터 검색 속도를 높이기 위해 생성하는 별도의 구조
• SQL 문에서 읽어야 하는 데이터 페이지 수를 줄여 쿼리 성능을 향상시킨다

2-6. 뷰 (View)

• 쿼리 결과를 기반으로 만든 가상 테이블
• 자주 사용하는 복잡한 쿼리를 단순화할 때 활용한다

-- 뷰 생성 예시
CREATE VIEW vw_customerorders AS
SELECT Customers.CustomerID, Customers.CustomerName, Orders.OrderID
FROM Customers
JOIN Orders ON Customers.CustomerID = Orders.CustomerID;

-- 뷰 활용 예시
SELECT CustomerName, OrderID
FROM vw_customerorders
WHERE CustomerID = 102;

---

3. SQL (Structured Query Language)

관계형 데이터베이스를 다루기 위한 표준 언어로, ANSI 및 ISO에 의해 표준이 유지된다.
각 RDBMS 제품마다 자체 확장 문법도 존재한다 (T-SQL, PL/SQL, pgSQL 등).

3-1. SQL 문장의 유형

분류	이름	역할	주요 명령어
DML	데이터 조작 언어	데이터를 조회·삽입·수정·삭제	SELECT, INSERT, UPDATE, DELETE
DDL	데이터 정의 언어	데이터베이스 구조(객체) 정의	CREATE, ALTER, DROP, RENAME
DCL	데이터 제어 언어	보안 권한 관리	GRANT, REVOKE, DENY

3-2. SELECT 문 구조

SELECT EmployeeId, YEAR(OrderDate) AS OrderYear
FROM Sales.Orders
WHERE CustomerId = 71
GROUP BY EmployeeId, YEAR(OrderDate)
HAVING COUNT(*) > 1
ORDER BY EmployeeId, OrderYear;

3-3. INSERT 문

-- 단일 행 삽입
INSERT INTO Sales.OrderDetails (orderid, productid, unitprice, qty, discount)
VALUES (10255, 39, 18, 2, 0.05);

-- 다중 행 삽입
INSERT INTO Sales.OrderDetails (orderid, productid, unitprice, qty, discount)
VALUES
  (10256, 39, 18, 2, 0.05),
  (10258, 39, 18, 5, 0.10);

3-4. CREATE 문

CREATE TABLE Mytable (
    Mycolumn1 INT NOT NULL PRIMARY KEY,
    Mycolumn2 VARCHAR(50) NOT NULL,
    Mycolumn3 VARCHAR(10) NOT NULL
);

---

4. Azure에서 제공하는 SQL 서비스

Azure는 SQL 기반의 데이터베이스 서비스를 크게 세 가지 형태로 제공한다.

4-1. IaaS vs PaaS 비교

구분	형태	특징
온프레미스 SQL Server	물리적	직접 하드웨어 운영
Azure VM의 SQL Server	IaaS	VM 위에서 SQL Server 운영, OS·백업 등 고객이 직접 관리
Azure SQL Database	PaaS	완전 관리형, 최소한의 운영 부담

4-2. Azure VM의 SQL Server (IaaS)

• 온프레미스 SQL Server와의 완전한 호환성 보장
• OS 업그레이드, 백업, 복제 등 모든 관리는 고객이 직접 수행
• 서버 및 라이선스 단위로 요금 지불

4-3. Azure SQL Database (PaaS)

• 최소한의 관리로 운영 가능한 저비용 완전 관리형 서비스
• 신규 클라우드 프로젝트에 적합하며, 재시작 없이 스케일 업/다운 가능
• 두 가지 옵션 제공:
  • 단일 데이터베이스: 하이퍼스케일 스토리지(최대 100TB), 서버리스 컴퓨팅 지원
  • 탄력적 풀: 여러 데이터베이스가 메모리·저장공간·처리능력을 공유

4-4. Azure SQL Managed Instance (PaaS)

• 온프레미스 SQL Server와 거의 100% 호환
• 자동 백업, 소프트웨어 패치, 모니터링 등 관리 작업 자동화
• 두 가지 옵션 제공:
  • 단일 인스턴스: SQL Server 노출 영역 대부분 지원, 가상 네트워크 기본 지원
  • 인스턴스 풀: 마이그레이션용 사전 프로비전, 소규모 인스턴스(2 vCore) 지원

4-5. 읽기 전용 복제본

• 주 서버에서 최대 5개의 읽기 전용 복제본 생성 가능
• BI, 분석, 대시보드 등 읽기 집약적 워크로드의 성능 향상에 활용
• 재해 복구 시 다른 Azure 지역의 복제본으로 전환 가능

---

5. Python에서 MySQL 연동하기

5-1. 아키텍처 구성

사용자 ↔ Python 앱 (MySQL Connector) ↔ MySQL 데이터베이스

5-2. 패키지 설치

pip install mysql-connector-python

5-3. 기본 연결 코드

import mysql.connector

cnx = mysql.connector.connect(
    host="127.0.0.1",
    port=3306,
    user="root",
    password="password",
    database="database_name"
)

cursor = cnx.cursor()
cursor.execute("SELECT * FROM table_name")
results = cursor.fetchall()

cnx.close()

• Oracle에서 공식 지원하는 순수 Python 라이브러리
• 추가 종속성 없이 사용 가능
• 다른 라이브러리(PyMySQL, SQLAlchemy 등)에 비해 속도가 다소 느린 편

---

6. Problem - Solution: 메모 앱 개발 사례

Problem 1: 데이터 중복 저장

메모 앱을 처음 설계할 때 하나의 테이블에 사용자 정보와 메모 내용을 함께 저장했다. 사용자 한 명이 메모를 100개 작성하면 이름과 전화번호가 100번 중복 저장되고, 전화번호가 바뀌면 100개 행을 전부 수정해야 했다.

Solution: 정규화를 적용해 users 테이블과 memos 테이블로 분리하고, 외래 키로 관계를 연결했다. 이후 JOIN으로 데이터를 조회하면서 중복 문제가 해소되었다.

---

Problem 2: 검색 속도 저하

메모 데이터가 수십만 건으로 늘어나자 특정 사용자의 메모를 조회하는 쿼리가 느려졌다. 매번 전체 테이블을 스캔하고 있었던 것이 원인이었다.

Solution: user_id 열에 인덱스를 생성했다. 인덱스가 검색 경로를 미리 정리해두기 때문에 읽어야 하는 데이터 페이지 수가 크게 줄어 쿼리 속도가 개선되었다.

---

Problem 3: 운영 부담 — 어떤 클라우드 DB를 선택할 것인가?

서비스를 클라우드에 올리면서 DB 서버 관리(백업, 패치, 모니터링)에 시간을 너무 많이 쓰게 되었다. 특히 트래픽이 갑자기 몰릴 때 스케일 업을 위해 서버를 재시작해야 하는 문제가 있었다.

Solution: Azure SQL Database(PaaS)로 전환했다. 백업과 패치는 Azure가 자동으로 처리해주고, 트래픽 변화에 맞춰 재시작 없이 스케일 업/다운이 가능해졌다. 운영 부담이 줄어 개발에 집중할 수 있게 되었다.

---

Problem 4: Python 앱과 DB 연동

Python으로 작성한 메모 앱에서 MySQL에 데이터를 저장하고 불러오려면 별도의 연결 방법이 필요했다. 직접 소켓 통신을 구현하기엔 너무 복잡했다.

Solution: mysql-connector-python 패키지를 사용했다. connect() 함수로 DB에 연결하고, cursor를 통해 SQL 문을 실행하면 Python 코드 안에서 데이터베이스를 자유롭게 다룰 수 있었다. 결국 앱의 데이터 처리 핵심은 Python이 아니라 SQL이라는 점을 다시 한번 확인하게 되었다.

---

5주차: 클라우드 응용 SW 개발 개념 정리

---

1. 반정형 데이터(Semi-structured Data)란?

관계형 DB처럼 고정된 스키마가 있는 것도 아니고, 이미지처럼 아무 구조가 없는 것도 아닌 중간 어딘가에 위치한 데이터다. 필드별로 실제 데이터 안에 구조가 정의되어 있으며, 같은 컬렉션 안에서도 엔티티마다 필드가 달라도 된다는 점이 특징이다.

예를 들어 고객 1은 집 전화와 회사 전화가 모두 있지만, 고객 2는 휴대폰만 있을 수도 있다. 관계형 DB에서는 이런 경우 NULL로 채워야 하지만, 반정형 방식에서는 있는 필드만 적으면 된다.

반정형 데이터베이스의 주요 사용 사례

분야	설명
IoT / 텔레매틱스	센서에서 대량의 데이터를 실시간으로 수집·처리해야 하는 경우
소매 / 마케팅	전 세계에 분산된 문서 스토리지 시나리오
게임	게임 내 통계, 순위표, 소셜 미디어 통합 등 낮은 응답 지연이 필요한 경우
웹 / 모바일	웹 클릭 분석, 챗봇 등 현대적인 앱에서 일반적으로 사용

---

2. 반정형 데이터 포맷

2-1. JSON (JavaScript Object Notation)

• 키-값 쌍으로 이루어진 가장 보편적인 반정형 데이터 포맷
• 사람이 읽고 쓰기 쉬운 텍스트 기반 형식으로, 대부분의 프로그래밍 언어에서 파싱 가능
• 지원 데이터 타입: 문자열, 숫자, 불리언, null, 객체, 배열

{
  "name": "Jane Smith",
  "age": 35,
  "city": "San Francisco",
  "hobbies": ["reading", "swimming"]
}

장점: 직관적 구조, JavaScript와의 자연스러운 통합, 표준화된 형식
단점: 복잡한 데이터 타입 표현에 한계, 주석 미지원

주요 활용: REST API 데이터 포맷, 앱 설정 파일, 게임 데이터 저장, 시스템 간 데이터 교환

2-2. 그 외 빅데이터용 포맷

포맷	특징	주요 사용처
Apache Avro	스키마 기반 직렬화, 언어 독립적, 스키마 진화 지원	빅데이터 환경의 데이터 교환
ORC	컬럼형 저장, 효율적 압축, 데이터 스키핑	Hadoop / Hive 워크로드
Parquet	컬럼 기반 저장, 중첩 데이터 구조 지원, 메타데이터 포함	대규모 데이터 분석

---

3. Azure Storage Account

Azure에서 클라우드 데이터를 저장·관리하기 위한 기본 단위다. 하나의 스토리지 계정 아래 용도에 맞는 다양한 저장 서비스를 골라 사용할 수 있다.

3-1. 주요 특징

• 구조화·비구조화·반구조화 데이터 모두 지원
• 데이터 암호화, 액세스 제어 등 보안 기능 제공
• 복제 옵션: LRS(로컬), GRS(지리적), RA-GRS(읽기 전용 지리적)
• 사용량 기반 과금 모델

3-2. 스토리지 유형별 비교

유형	역할	특징
Blob Storage	대규모 비구조적 데이터(이미지, 동영상, 로그) 저장	Hot / Cool / Archive 계층 지원
File Storage	클라우드 파일 공유	SMB 3.0 프로토콜, 최대 100TB
Queue Storage	메시지 기반 작업 흐름 구현	비동기 처리, 큐 메시징
Table Storage	구조화 데이터의 NoSQL 저장	스키마 없는 키-값 저장소
Disk Storage	Azure VM에 연결되는 디스크	고성능 SSD / HDD 옵션

3-3. Blob Storage 세부 유형

유형	최대 크기	용도
블록 Blob	4.7TB	이미지, 동영상 등 자주 변경되지 않는 대형 파일
페이지 Blob	8TB	가상 머신용 가상 디스크 구현
추가 Blob	약 195GB	로그 데이터처럼 끝에 계속 데이터를 추가하는 경우

---

4. Azure Cosmos DB

Azure가 제공하는 다중 모델 NoSQL 데이터베이스다. 분할된 문서 집합으로 데이터를 관리하며, 전 세계 어디서든 10ms 미만의 응답 속도를 보장한다는 것이 가장 큰 강점이다.

4-1. 주요 특징

• 실시간 읽기/쓰기 대기 시간 보장
• Azure의 스케일링 및 스토리지 기능 활용
• 단일 지역 내에서는 서버 클러스터로 확장성과 가용성을 확보
• 전역으로 데이터 복제 가능

4-2. Cosmos DB 사용 사례

분야	설명
웹 / 소매	다중 마스터 복제로 전 세계 사용자에게 10ms 미만 응답
게임	게임 내 통계, 리더보드, 소셜 미디어 통합
IoT	Azure IoT Hub와 연계해 센서 데이터를 실시간으로 빠르게 저장

4-3. Cosmos DB가 지원하는 API

다양한 기존 DB 생태계와 호환되는 API를 제공하므로, 기존에 쓰던 DB를 마이그레이션할 때도 코드 변경을 최소화할 수 있다.

API	특징	주요 용도
NoSQL API	JSON 문서 저장, SQL 유사 쿼리	일반 문서 기반 앱
MongoDB API	MongoDB와 호환	기존 MongoDB 앱 마이그레이션, 실시간 분석
Cassandra API	와이드 컬럼 모델	대규모 IoT, 시계열 데이터, 고성능 로깅
Gremlin API	그래프 데이터베이스	소셜 네트워크, 추천 엔진, 공급망 관계 모델링
PostgreSQL API	관계형 DB 호환	기존 PostgreSQL 앱 마이그레이션

4-4. 요금 체계: RU (Request Unit)

Cosmos DB의 비용은 작업량이 아니라 RU(Request Unit) 단위로 측정된다. 1KB 항목 하나를 읽는 데 1 RU가 소모되며, 복잡한 쿼리나 대량 쓰기 작업일수록 더 많은 RU가 필요하다.

• 프로비전된 처리량: 초당 RU(RU/s)를 미리 설정해 처리량을 보장받는 방식
• 모니터링: Azure Portal에서 RU 사용량을 실시간으로 확인 가능
• 비용이 RU에 따라 직접 청구되므로, Cosmos DB는 꼭 필요한 기능에 제한적으로 사용하는 것이 권장된다

4-5. 일관성(Consistency) 수준

Cosmos DB는 성능과 데이터 일관성 사이의 균형을 조절할 수 있도록 5가지 일관성 수준을 제공한다: 강력 > 제한된 부실 > 세션 > 일관된 접두사 > 최종. 가장 약한 단계인 최종 일관성은 성능이 가장 높지만, 읽기 시점에 약간 오래된 데이터를 볼 수 있다.

---

5. Python에서 Cosmos DB 연동하기

5-1. 아키텍처 구성

사용자 ↔ Python 앱 (azure-cosmos) ↔ Azure Cosmos DB

5-2. 사전 조건

• Azure 계정 및 활성 구독
• Azure Cosmos DB for NoSQL 계정
• Python 3.7 이상

5-3. 패키지 설치

pip install azure-cosmos

5-4. Cosmos DB 연결 시 주의할 점

MySQL과 달리 Cosmos DB는 스키마가 없는 문서 DB이기 때문에 데이터를 JSON 형태로 자유롭게 넣고 뺄 수 있다. 대신 RU 소모에 유의해야 하며, 복잡한 쿼리일수록 비용이 올라간다는 점을 코드 설계 단계부터 고려해야 한다.

---

6. Problem - Solution: 비록 AWS 로 해보긴 했지만...

DataGrip ssh 터널링으로 RDS 연결 시 접속 실패 트러블 슈팅 

거의 3시간 정도 걸린것 같다 ... 으아...

환경

• EC2 (rds-ssh) → RDS (discodeit-db) SSH 터널링으로 DataGrip 연결 시도

---

문제

DataGrip에서 SSH 연결은 성공했는데 DB 연결에서 실패가 떴다.

The connection attempt failed.

---

원인

RDS 보안 그룹 인바운드 규칙에 로컬 IP만 등록되어 있었던 게 문제였다.

SSH 터널링은 두 구간으로 나뉜다.

내 로컬 → EC2   (SSH / 22번 포트)
EC2     → RDS   (PostgreSQL / 5432번 포트)

각 구간마다 보안 그룹에서 별도로 허용해줘야 하는데, EC2 보안 그룹 ID가 RDS 인바운드 규칙에 등록되지 않아서 EC2 → RDS 5432 포트 구간이 막혀 있었던 것.

EC2에서 telnet으로 확인해봤을 때 응답 없이 계속 대기 상태 → 네트워크 레벨에서 차단 확인.

---

해결

RDS 보안 그룹 인바운드 규칙을 아래와 같이 수정했다.

프로토콜 포트 소스

~~로컬 IP 규칙~~	~~5432~~	~~59.27.39.12/32~~
PostgreSQL	5432	rds-ssh 보안 그룹 ID

기존 로컬 IP 규칙을 삭제하고, EC2의 보안 그룹 ID를 소스로 하는 새 규칙을 추가하면 된다.

---

핵심 정리

SSH 터널링 = 두 구간의 연결이다. 각 구간에 맞는 보안 그룹 규칙이 모두 열려 있어야 한다.

• 로컬 → EC2: EC2 보안 그룹에서 22번 포트 허용
• EC2 → RDS: RDS 보안 그룹에서 EC2 보안 그룹 ID를 소스로 5432번 포트 허용