Master-Slave 서버에 대해 알아보자
기획자를 위한 마스터, 슬레이브 서버 개념 한판 정리
개발자분께 다음과 같은 메일을 받았을 때 기획자의 심정을 서술하시오. (20점)
"복제 지연으로 인한 이슈로 확인됐습니다. 검색 쪽으로 요청하기 전에 master 쿼리 하도록 수정했고 3.2 배포 때 같이 나갈 예정입니다."
오늘은 데이터 베이스 서버를 효율적으로 구축하는 방법 중 하나인 마스터와 슬레이브 개념에 대해 알아보도록 한다. (안 정확함 주의)
들어가기 전, 용어 정리
서버: 말 그대로 정보를 제공(서빙)하는 컴퓨터
클라이언트: 정보를 제공받는 손님(손놈)
DB(Data Base): 여러 사람들이 공유하고 사용할 목적으로 통합 관리되는 데이터들의 모임
DB 서버: 데이터 정보를 제공하는 서버
쿼리: 원하는 데이터를 얻기 위해 DB서버에 요청하고 받아가는 것
서버와 DB에 대한 더 자세한 개념 정리가 필요하다면 이전 글을 참고해보자.
우리에게 노예가 필요한 이유
거의 모든 서비스는 서비스 내에서 일어난 활동들을 DB에 저장하고, 이를 가공해 서비스에 다시 사용한다. 이렇게 말하면 어려우니, 우리가 배달의 민족에서 음식을 주문할 때 일어나는 일들로 설명해보자. (실제로 배민이 이렇게 동작하는지는 모른다;)
“야심한 시각, 배달의 민족 앱을 켜고 엽기 떡볶이를 시킨다. 나와 같이 굶주린 자들의 주문 내역은 배민의 어느 서버에 차곡차곡 쌓인다. 이렇게 쌓인 데이터는 배달의 민족이 제공하는 여러 기능들에 필요하다. 예를 들어 내가 지금까지 주문한 내역을 보기 위해서 진입하는 주문 내역에 이 데이터가 필요하다. 엽기 떡볶이 사장님이 판매자 페이지에서 오늘 매출을 조회할 때도 이 데이터가 필요하다. 배달의 민족 기획자가 회사 운영 페이지에서 통계를 확인할 때에도 이 데이터가 필요하다.”
각각의 기능을 담당하는 서버는, 주문 데이터가 필요할 때마다 이 주문 데이터가 담긴 db 서버에서 '퍼가염~'을 외치며 데이터를 읽어간다. 이렇게 각 서버가 db 서버에 데이터를 요청하고 받아가는 것을 "쿼리"라고 한다. 쿼리에도 여러 종류가 있지만 이렇게 읽어가는 퀴리는 "조회(select)"라고 한다.
문제는, 너무 많은 서버들이 db 서버에 데이터를 요청한다는 것이다. 원본 데이터가 담겨있는 서버는 한개인데, 너무 많은 서버가 데이터를 요청하면 이 db 서버에는 과부하가 걸리게 된다. 그래서 db 서버는 자신만의 노예들을 영입하게 된다.
주인님을 위한 노예 - Slave 서버
위에서 보았듯, db 서버의 과부하를 막고 효율적으로 db 서버를 운영하기 위해 등장한 것이 Master - Slave 개념이다. 그렇다. 서버에 주인과 노예의 개념을 도입한 것이다. 주인님인 master 서버는 메인 프로세스를 담당한다. 그리고 Slave는 master 서버로부터 복제된 데이터를 받아서 어시스트 같은 느낌쓰로 master 각종 짜바리 같은 요청들에 대응한다.
실제로 이렇게 때리면서 일을 시키지는 않는다.예를 들어 배달의 민족에 주문 내역 데이터가 필요한 다른 서버들이 데이터를 요청하면, 진짜로 원본 데이터가 쌓여있는 master 서버가 아니라, 똑같은 데이터가 복제된 slave 서버가 데이터를 제공한다.
그럼 master 서버와 Slave 서버는 어떻게 데이터를 동기화할까? 그것까지 들어가면 좀 어렵지만, 간단히 살펴보자면 아래처럼 구조화할 수 있다. Binary Log와 Relay Log는 각 서버가 바쁜 와중에 정보가 들어오면 메모를 할 수 있는 메모장이라고 보면 쉽다.
Master - Slave 구조 심화 버전 (몰라도 크게 문제 없다.)1. 클라이언트가 db 서버 중 마스터 db 서버에 데이터를 보내준다.
2. 마스터 서버는 일단 이렇게 들어오는 데이터를 Binary Log라는 메모장에 적어두었다가, 때가 되면 db에 업데이트한다.
3. 이 와중에 Slave 서버가 최신 데이터를 요청한다.
4. 마스터 서버는 Binary log에 적어둔 최신 정보를 읽어서
5. Slave 서버에 전달한다.
6. Slave 서버는 이 정보들을 자신의 메모장인 Relay Log에 적었다가
7. 나중에 한번에 변경사항을 db에 적어둔다.
8. 다른 클라이언트나 서버가 마스터가 저장해둔 데이터를 쿼리로 요청하면
9. Slave 서버가 동기화된 데이터를 전달해준다.
나 서버,, 가끔 실수를 한다,, ⭐️
하지만 slave가 항상 일을 잘 해내는 것은 아니다. 갑자기 데이터 쌓이는 양이 늘어나게 되면 마스터가 슬레이브에게 주어야할 데이터를 제때 주지 못하고 복제 지연이 발생하게 된다.
예를 들어 한일전 때문에 치킨 주문량이 늘어나면, master db 서버가 시시각각 계속 데이터를 받게 되면서 slave 서버와 싱크가 안 맞을 수 있다.
이 경우에는 slave 서버에 어떤 쿼리가 들어오게 되더라도 제대로 된 정보를 주지 못하기도 한다. 가끔 데이터에 정보가 빠지는 경우도 있다.
이런 경우에는 패치를 붙여 수정하기도 한다. 예를 들어 특정 쿼리를 요청했는데 해당 슬레이브 데이터가 부정확하면 마스터에게 직접 요청한다. 마치 손님이 알바에게 물어봤는데 잘 대응을 못하면, '사장 나오라 그래!' 해서 사장님이 직접 대응하는 식이다.
다시 해석해보는 개발자의 언어
그럼 이쯤 해서 다시 개발자의 답변을 해석해보자.
"복제 지연으로 인한 이슈로 확인됐습니다. 검색 쪽으로 요청하기 전에 master 쿼리 하도록 수정했고 3.2 배포 때 같이 나갈 예정입니다."
→ 메시지 사용량이 많아 데이터 복제에 지연이 있어 부정확한 데이터를 읽어가는 이슈로 확인했습니다. slave 서버로 쿼리를 했을 때 지연으로 데이터가 없으면, master 서버(데이터가 있음)로 쿼리를 하도록 하는 로직을 추가했습니다. v3.2 타겟으로 배포 예정입니다.
빻은 단어 고치기 운동
마스터와 슬레이브 구조는 매우 유용하지만 사실 단어로만 보면 빻았다. 21세기에 이렇게 인종 차별과 관련된 단어는 안 쓰는 게 맞다. 우리나라의 경우 이런 문제에 둔감하지만, 실제로 African American에 대한 인종 차별이 있었던 미국에서는 예민할 수밖에 없는 문제다.
실제로 Micro Soft는 마스터와 슬레이브라는 용어를 지양하며, 불가피하게 사용해야 할 경우 아래와 같은 참고사항을 기재하고 있다.
MS 개발자 문서에는 이렇게 슬레이브 용어에 대한 참고를 달고 있다.