# 10주차 - 인터넷 서비스를 위한 DBMS 선택과 활용의 여정

오민석(카카오데이터플랫폼)

본인이 DBMS를 어떤걸 사용해왔는지에 대한 것을 연도별로 설명

## PostgreSQL 첫인상 (2002)

- Fragmentation(단편화)로 점점 느려짐
- 해결법은 Vaccum 명령어를 사용하는 것(Vaccum: DB의 오래된 영역을 재사용하거나 정리함)
- 서비스가 잘될수록 점점 느려지고 점점 Vaccum을 자주 사용해야함
- Vaccum으로도 너무 느려서 Full Vaccum을 사용해야했음(Full vaccum: 아예 DB를 다 밀고 새로 데이터를 채워 넣는 것)
- Full vaccum을 하면 그동안 서비스 불가
- 결국 full vaccum으로도 힘들어서 Oracle 쓰기로 결정

## HA-DR 구성 (2005)


- **HA**(High Availability, 고가용성): 시스템의 지속적인 작동을 보장하는데 중점
- 예) DB나 WAS같은거 하나가 죽었을 때 다른 노드로 부터 복구, 스토리지는 공유
- **DR**(Disaster Recovery, 재해복구): 해킹, 재난 상황같은 치명적인 이벤트를 복구하는데 중점
- 예) 데이터센터가 하나가 맛갔을 때 백업센터로부터 복구

## 미션 - RAC Prototype (2007)

> Oracle RAC는 오라클에서 만든 HA 솔루션 중 하나임

RAC를 이해하기 위해 직접 장비를 사서 구성
이렇게 HA를 하다보니깐 Cache Fusion에 대해 알게 됨

### Cache Fusion


Node A에서는 4로 업데이트되어 있음 그러나 DISK에서는 아직 3으로 업데이트 안된 상황(캐시)
이 때 Node B에서 저 3(4)이란 데이터를 요청
그러면 DISK I/O를 하지 않고 Node A에서 데이터를 가져옴 (그러므로 속도도 빠름)

## VIP를 쓰는 이유 (VIP = 가상 IP)

클라이언트는 항상 가상 IP로 접속
서버가 장애가 나더라도 다른 서버가 그 가상 IP로 대체해서 정상적인 접속 유지
클라이언트 입장에서는 실제 서버가 바뀌든 안바뀌든 계속 정상적으로 서비스 제공받음

## HA 구성후 (2008)

- 2007년에는 53시간의 장애시간, 2008년에는 단 2분만의 장애시간으로 획기적으로 줄임
- Resource Switch (DB트래픽 사용량을 보고 어느쪽에서 서비스 배포할지 조절)
- 무중단 정기점검이 가능함 (돌아가면서 인스턴스를 넘겨주고 반대쪽을 점검)

## UNIX-HA와 Orcale RAC 비교(요약)

- UNIX는 Active-Standby라 하나가 운영중이면 한쪽은 대기인데 RAC는 Active-Active라 양쪽다 운영가능
- Down-time이 거의 없음
- 가격도 더 쌈

## 전문적인 MySQL 지원시작 (2009)

### MySQL Replication

Replication을 통해 데이터 이중화 MySQL은 물리 복제가 아닌 논리 복제

Master: Read/Write 가능
Slave: Read-Only (Master가 Slave에 Write함)

- Read 분산
- 인터넷 서비스를 하면 Read:Write 9:1 정도의 비율로 Read가 많이 일어남
- Master 하나 밑에 여러 Slave를 둬서 Read 성능을 높임
- 특정 스키마만 처리하는 Slave를 둔다던지 여러 방식의 구성 가능
- Multi-Master
- 만약 Master가 장애나면 복구가 오래걸리고 Write 성능이 너무 떨어짐
- 하나의 Master만 잇는게 아닌 여러개의 Master를 통해 Write도 분산
- 서로 Master-Slave역할을 하기도하고, circular로 연결하기도하고 다양한 구성 가능
- Data Delivery
- 데이터 분배를 topological하게 구성
- Data Integration
- 데이터를 다양한 Master-Slave에게 받아서 통합

## 2010년 이후

- NoSQL(2011): NoSQL 부분도입
- MongoDB (2015): MongoDB의 사용처를 늘림
- 레거시 상용 DB를 OpenSOurce DB로 (2019): Oracle을 걷어냄
- Citus(2021): PostgreSQL을 분산 데이터베이스처럼 사용
- 현재 그리고 앞으로의 R&D
- db-engines 랭킹등을 보면서 DBMS 사용을 고려함
- 지속적으로 TF 미팅을 함
- Greenplum(데이터 병렬처리, 분석 플랫폼) 도입

# 예상 문제

- HA와 DR 구분하기
- Cache Fusion or VIP 설명 주고 이름 맞추기
- MySQL Replication 구분하기 (조직도를 주고 이름 맞추기)
- (case 1) 그림에서 Master가 여러개면 Multi-Master
- (case 2) 데이터가 아래에서 하나로 합쳐지면 Data-intergration
- (case 3) 조직도-트리의 depth가 2 이상이면 Data-Delivery
- (default) 그냥 평범하게 Master-Slave관계면 Read 분산