Chapter 04. 분산을 고려한 MySQL 운용 (강의11 ~ 13)

강의11. 인덱스를 올바르게 운용하기 - MySQL

분산을 고려한 MySQL 운용, 세가지 포인트

1. OS 캐시 활용(계속 언급됨)

2. 인덱스를 적절하게 설정하기 -> RDBMS에서 사용하는 구조

3. 확장을 전제로 한 설계

OS 캐시 활용

전체 데이터 크기에 주의해서 데이터양이 물리 메모리보다 가능한 적어지도록 유지한다. 메모리가 부족할 경우에는 증설한다. 대량의 데이터를 저장하려는 테이블은 레코드가 가능한 작아지도록 설계해야 한다. 3억 레코드 정도에서 칼럼을 늘리면(8Byte) 3GB만큼 늘어난다.

정규화?

경우에 따라서 정규화를 하게 되면 쿼리가 복잡 해져서 속도가 떨어지는 경우가 있으므로 속도와 데이터 크기 간 상반관계(trade-off)와 같은 부분도 생각해야 한다. DB의 내용이 메모리 안에 다 들어갈 수 있게 한다면 일단은 정규화 하는 것이 좋다.

인덱스의 중요성 - B트리

인덱스는 탐색을 빠르게 하기 위한 것으로, 그 내부 데이터 구조로 주로 트리가 사용된다.

MySQL에서는 ‘B+Tree’를 사용하는데 삽입이나 삭제를 반복한 경우에도 트리의 형태에 치우침이 생기지 않는 ‘평형 트리’이기도 한다. 탐색에 사용되는 계산 량은 반드시 O(log n)이 된다.

인덱스의 효과 -> 계산 량 측면에서 개선될 뿐만 아니라 디스크 Seek 횟수면에서도 개선된다.

대규모가 되면 될수록 인덱스를 준비해 놓느냐 아니냐 에 따라 차이가 나게 된다.

MySQL에서는 하나의 쿼리에 하나의 인덱스만 사용한다는 특성을 갖고 있다. 그게 싫으면 복합 인덱스를 설정해둘 필요가 있다. (bitmap index같은거는 여러개 사용할 수 있는것으로 아는데 모르겠넹)

 

+ 최근에는 O/M mapper가 SQL을 생성하는 경우가 있으므로 실제로 어떤 SQL이 실행되는지 사전에 확인해 보아야한다. (Spring에서 JPA같은거나, Node.js에서 Typerom, Sequelize같은거) 감시방안을 늘림으로써 사후 대응하는 것이 유효하다.

 

강의12. MySQL의 분산 – 확장을 전제로

MySQL의 replication기능

MySQL에 있는 replication 이란 마스터를 정하고, 뒤따르는 서버(슬레이브)를 정해두면, 마스터에 쓴 내용을 슬레이브가 폴링해서 동일한 내용으로 자신을 갱신하는 기능이다. 슬레이브는 마스터의 레플리카가 되는 것. 이렇게 해서 동일한 내용의 서버를 여러 대 마련할 수 있다.

참조(Select) 쿼리는 slave에 넘겨주고 갱신 쿼리는 마스터로 직접 준다.

쿼리를 분배할 때는 로드밸런서를 이용하거나 MySQL Proxy같은 것을 사용하면 된다.

 

1. 이렇게 할 경우 참조 쿼리는 단순히 slave역할을 하는 DB서버를 늘리는 방식으로 분산이 가능하지만, 갱신 쿼리는 어떻게 할 것인가? -> 웹 application에서는 90% 이상이 참조계열 쿼리이므로 마스터가 병목이 되어 곤란한 상황이 발생하는 경우는 그렇게 많지 않다고 한다.

 

2. 갱신/쓰기 계열을 확장하고자 할 때 -> 테이블을 분할해서 크기를 작게 해준다. (마스터는 확장불가능)

또는 처음부터 RDBMS를 사용하지 않는 방법도 생각해본다. Key- value 스토어 방식은 단순히 값을 저장하고 꺼낼 뿐이므로 RDB가 갖는 복잡한 통계처리나 정렬이 필요하지 않는다. 오버헤드도 적고 압도적으로 빠르며 확장하기 쉽다. -> 웹에서 세션 같은 것을 Redis에 저장하는 그런 느낌?

마스터 / 슬레이브의 특징

참조계열 쿼리는 확장

-> 서버를 늘리기만 하면 된다. 대수를 단순히 늘리는 것이 아니라 메모리에 맞추는 것이 중요하다.

마스터는 확장하지 않는다.

-> 갱신계열 쿼리가 늘어나지 않게, 테이블 분할이나 다른 구현(key-value 스토어) 등으로 연구한다.

강의13. MySQL의 스케일아웃과 파티셔닝

파티셔닝이란 테이블을 서로 다른 서버에 놓아서 분산하는 방법. 국소성을 활용해서 분산할 수 있으므로 캐시가 유효하고 파티셔닝은 효과적이라는 이야기다.

파니셔닝을 전제로 한 설계

기본적으로 JOIN 쿼리는 대상이 되는 테이블을 앞으로도 서버 분할하지 않을 것이라고 보장할 수 있을 때에만 사용한다. 테이블끼리 얼마나 긴밀하게 결합되어 있는지 확인하고, 서로 다른 Host에서의 Join은 AP서버에서 직접 한다.(MySQL5.1부터 가능하다고 적혀 있고, 오라클에는 다른 서버에서 테이블 불러올 수 있는 것으로 배웠음)

파티셔닝의 상반관계

장점은 부하가 내려가고 국소성이 늘어나서 캐시 효과가 높아진다는 점이 있다.

운용이 복잡 해진다.

같은 DB지만 이 서버는 무슨 일을 하고 저 서버는 무슨 일을 하는지를 파악하기가 어렵다. 장애가 발생했을 때나 혼란한 상황에 빠졌을 때 이 내용을 파악하고 있지 않으면 민첩하게 대응하기가 어렵다. 결국 복구에 시간이 더 걸리게 된다.

고장률이 높아진다.

대수가 늘어나는 만큼 고장확률이 높아진다. 무정지 복구를 하기 위해서는 기본적으로 마스터1 + 슬레이브3 = 4개의 DB를 세트로 운용한다. (슬레이브 하나가 고장 날 경우 하나는 서비스를 계속하고 하나는 복사를 위해 사용되기 때문)

따라서 (이 책에서는 4개를 1set로 보니 깐) DB서버를 늘리면 4의 배수만큼 늘어난다. 늘어난 호스트만큼 고장이 날 확률이 높아진다.

정리

파니셔닝의 장점

부하가 내려간다. 국소성이 증가해서 캐시 효과가 높아진다.

파니셔닝의 단점

운용이 복잡해진다. 고장확률이 높아진다.

윤용이 복잡해지면서 경제적인 비용이 든다.

 

언제까지나 파티셔닝은 마지막 카드로 두고 다른 방안들을 먼저 확인해보자.