[DB] 분산을 고려한 MySQL 운용

웹 개발자를 위한 대규모 서비스를 지탱하는 기술, 4장

대규모 서비스를 지탱하는 기술 - YES24

4장, 분산을 고려한 MySQL 운용

데이터 분산 시에는 국소성을 고려하고, 규모에 맞게 메모리를 조정하고, 메모리 증설로도 대응이 어려울 때에는 분산한다!

 

▶ DB Scale-Out 전략의 3가지 포인트

 

1. 인덱스를 올바르게 사용한다.

인덱스?
데이터 베이스에서 인덱스란, 책의 색인과 같이 빠르게 원하는 데이터를 찾을 수 있도록 하는 자료구조다. 
추가적인 쓰기 작업과 저장공간을 필요로 하며, 올바르게 사용하지 않으면 오히려 성능이 저하될 수 있다.

 

DB를 설계할 때에는 OS캐시, 인덱스를 적절히 활용하여 성능을 높이고 확장을 전제로 설계하는 것이 좋다.

 

OS 캐시 활용

규모가 커질수록 DB스키마의 중요성도 높아진다. 스키마의 작은 변경으로도 데이터의 증가량이 거대하기 때문이다.

데이터량이 물리 메모리보다 가능한 한 적어지도록 설계한다. 메모리가 부족할 경우에는 증설한다. 대량의 데이터를 저장하려는 테이블은 가능한 한 레코드가 작아지도록 설계한다. 

 

* 정규화는 경우에 따라서 잘 선택하자. 

 

인덱스 활용

인덱스는 검색 속도를 높이기 위한 것으로, 내부적으로 트리구조로 되어있다.

MySQL의 인덱스는 기본적으로 B+ tree구조다. (B tree에서 파생)

B tree는 각 노드가 여러 개의 자식을 가질 수 있는 다분트리이며 데이터의 삽입/삭제가 반복되어도 트리의 형태에 치우짐이 생기지 않는 평형트리다. 하드 디스크상에 구축하기 알맞은 구조다.

B tree에서의 데이터 삽입은 일정한 규칙을 갖고, 그 규칙 덕분에 검색이 빨라진다.

B tree의 검색 방법
먼저 root에서 시작하여 각 노드에 찾는 값이 있는지 확인, 없으면 자식을 찾아간다. 이때 값의 대소관계로 어떤 자식을 찾아가면 되는지가 한 번에 결정된다. 때문에 최악의 경우에도 트리의 높이만큼만 찾아가면 되므로 탐색이 빨라진다. => O(logn)

* 이분트리와 B트리: 자식이 반드시 2개 이하인 이분트리와 달리 여러 개의 자식을 가질 수 있는 B트리는 각 노드를 1블록에 모아 저장되도록 구성할 수 있어 디스크 Seek 발생 횟수를 줄일 수 있다.

출처

B+트리는 각 노드내에 자식 노드로의 포인터만 가지고 있고, 실제 값은 모두 단말노드(leaf Node)에 가지고 있는 구조이며, 데이터를 저장하기에 최적화된 구조다.

 

대규모 데이터에서는 인덱스가 확실히 검색속도를 향상해 주지만, 작은 애플리케이션의 경우에는 불필요할 수 있다. MySQL은 레코드 총건수를 보고 인덱스를 사용하지 않는 것이 빠를 때에는 자체적으로 사용하지 않도록 최적화 작업을 수행한다.

인덱스를 걸어 놓았더라도, 사용하는 쿼리문에 따라 인덱스가 사용될 수도 아닐수도 있다.

 

인덱스로 작용하는 것

• 명시적으로 추가한 인덱스
• Primary Key, UNIQUE 제약

explain 명령어
해당 명령어를 통해 성능을 확인해볼 수 있다.

 

2. MySQL 분산 

레플리케이션(Replication)

마스터(master)를 정하고 슬레이브(slave)를 정해두면, 마스터에 쓴 내용을 슬레이브가 폴링(Polling)해서 동일한 내용을 자신을 갱신하는 기능.

마스터/슬레이브로 레플리케이션 서버를 여러 대 준비하게 되면, 쿼리를 여러 서버로 분산할 수 있다.

동기화를 위해 갱신쿼리는 마스터에만 던진다. 

하테나에서는 O/R 매퍼로 제어한다는데,,? (안궁금)

대부분의 경우는 90%이상이 참조계열의 쿼리고 갱신쿼리는 많지 않다.

 

갱신 쿼리를 분산할 수 없으면, 갱신이 많을 때는 어떻게 하나!

• 테이블을 분할하여 테이블 크기를 작게한다. -> 쓰기 작업이 분산되며, 여러 디스크나 서버로 분산할 수도 있다.
• RDBMS를 사용하지 않는다. -> key-value 방식의 스토어

 

3. 스케일 아웃과 파티셔닝

스케일 아웃 시, 데이터가 메모리에 올라가는 크기면? 메모리에 올리고

메모리에 올라가는 크기가 아니면? 메모리를 증설하고

메모리 증설이 불가능하면? 파티셔닝을 한다

 

파티셔닝?
테이블 A와 B를 다른 서버에 놓아 분산하는 방법

MySQL에는 다른 서버에 있는 테이블을 JOIN하는 기능이 기본적으로 없으므로 JOIN의 대상이 되는 테이블들은 서버를 분할하지 않는다.

서로 밀접하지 않고, 크기가 커서 분할이 필요한 경우에는 분할한다. 

이와 같이 데이터의 특성을 파악하고 테이블을 설계, 분할해야한다.

 

파티셔닝은 데이터의 국소성이 증가하여 캐시 효과가 높아진다는 장점을 가지고 있지만, 단점도 존재한다.

• 운용이 복잡해진다. -> 장애 발생 시 파악이 어렵고, 대응 및 복구에 더 많은 시간이 필요하다.
• 고장률이 높아진다. -> 분산을 하면 다중화까지도 복사해야하고, 기본적으로 다중화는 마스터1대, 슬레이브 3대를 사용한다. 때문에 4대짜리 세트인 서버를 분산하면? 4*2 => 8대가 필요하다. 서버가 많으니 당연히 고장날 가능성도 높아진다.

운용과 고장률을 고려하면, 파티셔닝은 쉬운 선택이 아니다. 어디까지나 마지막 카드로 사용한다.