[DB] Master - Slave 아키텍처

시작에 앞서 다중화란?

**💡 DB 다중화?
- 단일 데이터베이스 구조로 사용할 경우 단일 데이터베이스에 문제가 발생할 경우 계속해서 서비스가 제공되지 못하며,
    서버 데이터 분산을 통해 copy본을 만들어놓는 등의 작업을 위해 다중화를 사용한다.

💡 다중화시 유의점
- 간단히 병렬화해서 대수를 증가시키는 웹 서버나 애플리케이션 서버와 비교하면 다중화에 대해 고민해야할 부분이
  많은데 그 이유는 DB 서버가 데이터를 보존하는 영속(Persistence) 계층이기에 별도의 대처가 필요.    

💡 DB와 다른 서버의 차이
- 데이터베이스는 데이터를 장기간 보존하는 매체가 필요하다. 이 점은 데이터를 일시적으로 처리할 뿐인 
  웹 / 앱 서버와 다른 점이다.
- 결국 DB 서버의 아키텍처는 서버와 저장소를 묶어서 생각해야 한다.DB 서버의 데이터는 영구적이어야하기에**

---

Master / Slave

앞서 설명한 다중화 방식 중 가장 보편적으로 사용되는 아키텍처가 Master/Slave 아키텍처이다.

 

Master Slave 아키텍처

쓰기(Write) 작업은 마스터에서만 지원하고, Slave서버는 DB사본을 갱신하면서, 읽기만을 지원. (통상 애플리케이션은 읽기 연산 비중이 훨씬 크기 때문에 아래와 같은 구성으로 많이 사용)

 

 

이를 웹 아키텍처로 묶어서 설명하면 아래와 같은 그림이 된다.

 

 

동작 원리

1. 사용자는 URL로 사이트에 접속하면 로드밸런서 IP 주소를 받는다.
2. 사용자는 로드밸런서에 접속
3. 사용자의 요청은 웹 서버1 또는 웹 서버2로 전달
4. 웹서버는 쓰기(Write)라면 MasterDB, 읽기(Read)라면 SlaveDB에 접근

---

DB 계층에 Master / Slave구조가 필요한 이유?

• 앞서 설명한듯이 db서버의 과부화를 막아 효율적인 운영을 위해 등장한 개념이 Master / Slave이다.

동작방식

1. 클라이언트가 DB서버 중 Master 서버에 데이터를 전달한다.
2. 마스터 서버는 해당 정보를 Binary Log(Mysql, MariaDB 기준)라는 임시(temp) 파일에 저장한다.
3. Slave가 최신 데이터(Read)를 Master에 요청한다.
4. 이때 Master 서버는 최신정보를 전달하기 위해 아까 Write 작업을 수행한 Binary Log에서 이를 읽어와 Slave 서버에 전달한다.
5. Slave 서버는 이를 Relay Log라는 임시 파일에 적었다가 변경사항을 한번에 DB에 반영한다.
6. 다른 클라이언트에서 동일 데이터에 대한 조회 쿼리가 전달되면 Slave에서 로그애서 꺼내주는 방식으로 동작한다.

---

Binary Log , Relay Log

 

위사진은 TMI 형식의 도움될만한 정보이고 내가 궁금했던부분은 정작 따로 있었다.

 

과연 어느 시점에 DB 디스크 시점에 해당 데이터를 영구적으로 저장하는지였다.

 

결론은 RDB의 설정에 따라 즉시될 수도 특정 시간이후에 처리될 수 있다.

 

BinaryLog의 경우 sync_binlog 설정을 통해 이를 제어하는데 해당값이 1이면 즉시반영하고 Scehduling을 걸 수도 있다. (RelayLog도 마찬가지로 동작한다)

---

Master / Slave 구조의 허점

• Slave에 쌓이는 데이터의 양이 늘어나게되면 마스터가 슬레이브에게 주어야할 데이터가 복제지연된다.
  • 그렇다면? Master 서버와 Slave 서버간에 싱크가 안맞게 되는 이슈가 발생한다.
• 이 경우에는 slave 서버에 어떤 쿼리가 들어오게 되더라도 제대로 된 정보를 주지 못하기도 한다. 가끔 데이터에 정보가 빠지는 경우도 있다.
• 이런 경우에는 패치를 붙여 수정하기도 한다. 예를 들어 특정 쿼리를 요청했는데 해당 슬레이브 데이터가 부정확하면 마스터에게 직접 요청한다

---

요약

위 그림과 같은 구조에서 애플리케이션 서버로부터 오는 데이터 삽입, 수정, 삭제 쿼리를 Master 서버로 보내면 Master 서버는 쿼리를 처리하고 바이너리 로그 스레드를 사용해 변경 내역(쿼리나 변경된 ROW 자체)을 바이너리 로그에 저장한다.

 

그럼 Slave 서버의 Replication I/O 스레드가 Master 서버로 접속해 변경 내역을 요청하면 Master 서버의 바이너리 로그 덤프 스레드가 바이너리 로그를 읽어 변경 내역을 Replication I/O 스레드에게 전달하고 Replication I/O 스레드는 변경 내역을 Slave 서버의 릴레이 로그에 저장한다.

 

마지막으로 Replication SQL 스레드가 릴레이 로그를 읽어 변경 내역을 적용하고 서버 간의 데이터 정합성을 맞추게 됩니다.

단점

• Replication을 적용하면 Master/Slave 서버 간 데이터 동기화까지의 시간이 소요되기 때문에 데이터 정합성 문제가 발생할 수 있다.(Slave에 부하가 심해지면 더 많은 문제가 발생할것이다.)
• Slave 서버에서 데이터 변경이 일어나면 Master 서버와의 정합성이 깨지고 이를 위한 추가 작업이 필요해진다.
• Master 서버에서 바이너리 로그를 안정적으로 기록하기 위해 락(Lock)을 유지하고, 로그를 기록하는 행위 또한 디스크 I/O를 추가적으로 유발
• 애플리케이션 서버에서는 Master/Slave 서버로 분기할 수 있는 기능이 필요하게된다. 해당 작업을 로드밸런서에서 처리한다.