[데이터베이스 첫걸음] 1~4장: 디비기본기능, 아키텍쳐, 가용성,클러스터링,리플리케이션 찍먹

개발 단톡방에서 누군가 추천해줘서 알라딘 중고로 바로 구매했다.ㅋㅋ 이것도 조금씩 읽자!

 

처음~ 116페이지. 2,3장은 아는 내용이라 판단해서 정리하지 않았다.

1장 - 데이터베이스 기본기능

1. 데이터 검색과 갱신

이때 특히 몇백만명의 사용자가 등록된 경우, 검색 성능을 어떻게 향상할 것인가는 영원한 숙제임. 이는 부록에서 다룬다

 

2. 동시성 제어

동시에 복수의 사용자로부터 검색이나 갱신 처리를 받는다

단순 예로, 두명이서 파일 하나를 동시에 검색했다 치자.

해결방법: 

방법1: 최초에 누군가 열었으면 다른 사람은 그 파일을 열 수 없다. -> 가장 엄격

방법2: 두번째 연사람은 '읽기전용'으로만 열린다.  -> 중간

방법3: 늦게 수정한 사람이 최종수정. -> 가장 자유로움. dirty write

 

3. 장애대응

데이터 소실 대책

- 데이터 다중화

달걀을 한바구니에 담지마라! 예방책임

- 백업

사후대책

위 이야기는 각각 4장, 9장에서 다룬다.

---

4장 - 데이터베이스와 아키텍쳐 구성

아키텍쳐 역사

1. stand-alone

-디비서버가 설치된 장소까지 물리적으로 접근해야만 디비사용가능함.

-복수 사용자가 동시에 작업 불가능(네트워크에 연결되어 있지 않기에)

-가용성이 낮다(1대만 있으니 고장나면 끝)

-확장성 부족(성능 개선 수단이 머신을 좋은걸로 바꾸는 수밖에 없음)

 

2. 클라이언트/서버

pc와 네트워크 기술발전으로 90년대부터 채용됨

 

3. web 3계층 구성 등장:

웹서버 계층, 애플리케이션 계층, 데이터베이스 계층을 말함

웹서버 계층은 클라이언트로부터 접속요청을 받고 앱 계층에 넘기고 그 결과를 클라이언트에 반환한다. 즉, 앱 서버와 클라이언트(브라우저)의 가교역할. 웹 서버로는 아파치가 대표적.

애플리케이션 계층은 비즈니스 로직을 구현한 앱이 동작하는 곳임. 웹서버로부터 요청을 받으면 처리하고, 디비계층에 접속해서 데이터 추출도 함. 톰캣이 대표적.

 

가용성과 확장성 확보

web 3계층이 등장하면서 stand-alone의 문제점 중 2가지는 해결(물리적 거리문제, 동시 사용하기 문제).

그러나 가용성(서버가 1대밖에 없어서 문제일어나면 끝장)이 낮은 문제와 확장성 부족(서버가 1대라서 성능이 한계에 다다르면 부품 교환하는 거밖에 성능개선방법이 없음)은 여전하다.

 

가용성 높이기 전략 2개

- 심장전략(고품질-소수전략)

- 신장전략(저품질-다수전략)

 

위에서 신장전략처럼 동일한 기능의 컴포넌트를 병렬화하는 것을 '클러스터링'이라고 한다. 

 

클러스터링

디비는 데이터를 영구적으로 보존하고 그에따른 성능도 요구된다. 일반적으로 서버 내부의 로컬 저장소나 메모리로는 이런 요건을 충족하지 못하기에 전용의 외부 저장소를 사용한다. 

즉,  데이터베이스는 서버(계산이나 업무 로직 처리)와 저장소(데이터 보존)로 구성된다.

 

Active-Active와 Active-Standby

서버 다중화

둘 모두 디비 서버만 다중화하고, 저장소는 하나만 두는 구성임. 어 땐 어차피 저자오가 1개라서, 정합성 신경쓸 필요가 없다.

 

- Active-Active
클러스터를 구성하는 컴포넌트를 동시에 가동. DBMS 중 Oracle과 DB2가 현재 가능함.

장점1: 시스템 다운 시간이 짧다. 하나가 죽어도 하나가 돌아가면서 계속 처리하기 때문임. 

장점2: 성능이 좋다. 서버가 여러개니까 cpu랑 메모리도 증가.(단, 저장소는 하나라서 병목현상 가능)

 

- Active-Standby

Standby 상태의 DB서버는 사용되지 않다가 Active DB가 장애나면 사용됨. 그래서 

 

리플리케이션

위 두가지 클러스터 구성은 서버만 다중화하고, 저장소는 하나임. 저장소도 보통 내부 컴포넌트가 다중화되어있지만, 데이터 센터 전체가 지진나서 무너저벼리면 끝남. 이를 위한 클러스터 구성이 바로 리플리케이션(복제)임. 즉 DB서버와 저장소 세트를 통째로 복수로 준비하는 것임.

리플리케이션

중요한 점은 Standby 측 데이터에다 Active 측 저장소의 데이터를 반영하지 않으면 과거 데이터만 있게 됨. 고로 일정주기로 액티브 디비서버에서 갱신된 데이터를 일정 주기로 스탠바이측 디비서버에 써놔야 한다.(얼마나 자주할지는 성능과 트레이드 오프가 있다)

 

Shared Nothing

Active-Active 구성의 디비 저장소는 병목이 발생할 수 있는 문제점이 있잖어. 서버 여러개가 저장소 하나 쓰니까 저장소가 성능이 빨리 못따라가는 거임. 이런걸 Shared Disk라고 함.

이 문제를 해결하기 위해 고안된게 Shared Nothing임. 서버 하나에 저장소 하나씩 쓰는 것임. 그럼 하나의 세트(서버, 디스크)가 증가될 때마다 처리율도 증가됨. 

단점: 저장소를 공유하지 않는다는 게 문제가 됨. 예를 들면, 각 세트별로 하나의 서버가 다른 세트의 데이터에 접근이 불가능해짐. 이런걸 해결하는게 커버링 구성이라고 하는데, 복잡하대...