[대규모 서비스를 지탱하는 기술] DB 스케일아웃 전략

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

DB 스케일아웃 전략

1. 인덱스의 효과

• 인덱스는 색인으로 저장 공간과 쓰기 성능을 희생하면서 검색 속도를 높이기 위한 자료구조이다.
• MySQL에서는 기본적으로 B-Tree를 인덱스 알고리즘으로 사용한다.
• B-Tree는 이론적으로 탐색 계산량이 O(log n)으로 보장되므로 선형 탐색에서 O(n)으로 찾는 것보다 B-Tree로 찾는 것이 더 빠르다. 이러한 이유로 인덱스로 탐색하면 검색 속도가 빨라지는 이유이다.
• 이처럼 계산량 측면에서 개선될 뿐만 아니라 디스크 구조에 최적화된 인덱스를 사용해서 탐색함으로써 디스크 Seek 횟수면에서도 개선된다.

 

책에서 인덱스 및 실행계획에 대해서 간단하게 다루고 있는데..
이 부분은 Real MySQL 정리한 것이 더 유용하다고 생각해서 이정도만 정리하였습니다.

cf) Real MySQL 인덱스 정리

https://willseungh0.tistory.com/37?category=874332

[Real MySQL 정리] 5장. 인덱스

cf) Real MySQL 실행 계획 정리 (1, 2)

https://willseungh0.tistory.com/38?category=874332

[Real MySQL 정리] 6장(1). 실행 계획

https://willseungh0.tistory.com/115?category=874332

[Real MySQL 정리] 6장(2) 실행 계획 - MySQL의 주요 처리 방식

2. MySQL의 분산

---

MySQL의 레플리케이션 기능

레플리케이션

• 마스터(master)를 정하고 마스터를 뒤따르는 서버(slave)를 정해두면 마스터에 쓴 내용을 슬레이브가 폴링 해서 동일한 내용으로 자신을 갱신하는 기능이다.
• 조금 더 자세히 알아보면, 마스터 노드에서 발생하는 특정 쿼리들을 binary log에 저장하고 슬레이브 노드에서 마스터 노드의 binary log를 주기적으로 받아서 릴레이 로그에 넣어서 실행시켜서 내용을 동기화하는 방식을 사용한다.

또한, 예전에는 마스터-슬레이브 용어를 많이 사용했는데 최근에는 인종 차별적 문제로 메인-레플리카 혹은 Primary-Secondary 용어를 지양한다고 합니다.

하지만 이 글은 이 책의 내용을 정리하는 것이므로 책의 용어(2011년에 나온 책..)를 따라가겠습니다. (인종 차별적의 의미는 없습니다 ㅠㅠ)

 

다시 본론으로 돌아와서

• 마스터/슬레이브로 레플리케이션해서 서버를 여러 대 준비하게 되면, AP 서버에서는 로드밸런서를 경유해서 슬레이브로 질의하게 해서 쿼리를 여러 서버로 분산할 수 있다.
• 이때 애플리케이션 구현에서 SELECT 등 참조 쿼리만 로드밸런서로 흘러가도록 하고, 갱신 쿼리는 마스터로 직접 던진다. (갱신 쿼리를 슬레이브로 던지게 되면 슬레이브와 마스터 간 내용을 동기화할 수 없다)

 

마스터/슬레이브의 특징

참조 계열 쿼리는 슬레이브로 분산하면 되므로 분산할 수 있지만, 갱신 계열 쿼리를 분산할 수는 없지 않은가? 질문을 할 수 있다. 즉 마스터의 다중화를 어떻게 할 것인가라는 문제이기도 하다.

• 마스터 서버의 확장은 힘들다.
• 그렇지만 웹 애플리케이션의 특성이 있는데, 웹 애플리케이션에서는 대략 90% 이상이 참조 계열 쿼리이다.
• 따라서 웹 애플리케이션에서는 참조계열에 비하면 마스터가 병목이 되어 곤란한 상황이 발생하는 경우는 그렇게 많지 않다.

 

갱신/쓰기 계열을 확장하려고 할 때

드물게 마스터에 엄청난 쓰기 작업이 발생하는 애플리케이션을 개발하는 경우가 있을 수 있다.

테이블을 분할해서 테이블 크기를 작게 해 준다.

• 분할로 인해 쓰기 작업이 분산된다. 테이블 파일이 분산되면 동일 호스트 내에서 여러 디스크를 가지고 분산시킬 수도 있으며, 서로 다른 서버로 분산할 수도 있다.

 

처음부터 RDBMS를 사용하지 않는 방법도 생각해볼 수 있다.

• 하테나에서 쓰기 작업이 너무 많아서 RDBMS를 사용하지 않는 실제 사례로는 우고메모의 동영상 재생횟수를 표시하고 있는 부분이다. (사용자가 동영상을 재생할 때 마다 갱신이 일어난다)
  여기는 쓰기작업 횟수가 많아서 RDB로는 확장할 수 없어서 key-value 스토어 방식을 사용하고 있다.
• 단순히 값을 저장하고 꺼낼 뿐이므로 RDB가 갖는 복잡한 통계처리나 범용적인 정렬 처리가 필요하지 않다면 key-value 스토어는 오버헤드도 적고 압도적으로 빠르며 확장하기 쉽다.

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

---

MySQL의 스케일아웃 전략

정리하면

• 데이터가 메모리에 올라가는 크기이면 메모리에 올리고, 올라가지 않으면 메모리를 증설한다. 그리고 인덱스를 제대로 걸자.
• 하지만 메모리 증설이 불가능하다면 파티셔닝 전략을 사용한다.

 

파티셔닝 (테이블 분할)

파티셔닝 (테이블 분할 전략)이란 테이블 A와 테이블 B를 서로 다른 서버에 놓아서 분산하는 방법이다.

파티셔닝은 국소성을 활용해서 분산할 수 있으므로 캐시를 유효하게 함.

 

파티셔닝을 전제로 한 설계

• MySQL는 서로 다른 서버에 있는 테이블을 JOIN 하는 기능이 기본적으로는 없다. (5.1 이상부터 FEDERATED 테이블 지원)
• 기본적으로 JOIN 쿼리는 대상이 되는 테이블을 앞으로도 서버 분할하지 않을 것이라고 보장할 수 있을 때에만 사용한다.
• INNER JOIN을 WHERE IN 등 두 번 쿼리를 사용하는 방법으로 구현할 수 있다.

 

파티셔닝의 상반 관계

파티셔닝으로 분산할 수 있는데, 파티셔닝에는 트레이드오프가 존재한다.

파티셔닝의 좋은 점은 부하가 내려가고 국소성이 늘어나서 캐시 효과가 높아진다는 점이었다. 한편으로는 나쁜 점도 물론 있다.

 

운용이 복잡해진다.

• 서버로 여러대로 나뉘고, 용도가 다른 서버가 생기는 것이다. 이런 식으로 운용이 복잡해지는 단점이 있다.

 

고장률이 높아진다.

• 대수가 늘어나는 만큼 고장 확률이 높아지는 문제가 있다.

 

다중화에 필요한 서버 대수는 몇 대?

한 서버에 최소 4대이다.

먼저 다중화를 하지 않으면 (서버가 1대밖에 없다면) 고장 나면 복구할 수 없다.

• 마스터/슬레이브 관련 내용을 생각해보면 마스터가 1대 있고 슬레이브가 3대로 구성해 다중화하는 것이다. (1세트에 4대의 서버)
• 이렇게 하면 슬레이브가 1대 고장 나더라도 괜찮을 뿐 아니라 마스터가 고장 나더라도 슬레이브가 살아있으므로 슬레이브 중에 1대를 마스터로 승격시키면 된다.

 

왜 슬레이브가 3대나 필요할까?

만약 슬레이브 서버가 2대 있고, 슬레이브가 1대 고장 났다고 하자.

• 남아있던 슬레이브를 중지하지 않으면 복사할 수 없다. 그러면 서비스가 중지된다. 만약 마스터를 중지하면 쓰기 작업을 할 수 없게 되고 슬레이브를 중지하면 참조할 수 없게 되므로 서비스를 중지하지 않으면 복구할 수 없게 된다.
• 슬레이브가 3대가 있으면, 1대가 고장 나더라도 남은 2대 중에 1대를 중지하고 새로운 서버로 데이터를 복사해서 고장 난 슬레이브 이외의 슬레이브 3대를 정리해서 복구할 수 있다. 이렇게 해서 무정지 복구를 할 수 있다.

 

따라서 다중화를 완벽하게 고려하자면 4대를 1세트로 생각할 필요가 있다

 

애플리케이션의 용도와 서버 대수

• 참고로 애플리케이션의 용도에 따라 무정지가 필수조건이 아닌 경우는 반드시 4대가 필요하다고는 할 수 없다.

 

서버 대수와 고장률

• 메모리를 늘림으로써 대응할 수 있다고 하면 그렇게 하는 편이 분할하지 않아도 되므로 더 수월하다
• 제품의 가격대를 고려해보고, 똑같이 분할하더라도 어느 쪽이 더 저렴할지 어느 족이 더 운용하기 편한지를 빈틈없이 생각할 필요가 있다.

역시 파티셔닝도 트레이드오프이다.
파티셔닝을 하는 것이 항상 좋은 것이 아니고, 그에 따라 발생하는 단점도 존재하므로 잘 고려해야 할 것 같다.