사내에서 가상 면접 사례로 배우는 대규모 시스템 설계 기초라는 책으로 스터디를 진행하게 되었습니다.
간만에 진행하는 스터디라서 설레는 마음으로 첫 주를 진행했는데,
이번 주차를 통해 배운 점에 대해서 간단히 정리해보려고 합니다.
가장 기초적으로 웹 서버를 개발한다면, 다음과 같은 형태일 것입니다.
수직적 확장
웹 서버는 컴퓨터에서 돌아가는 하나의 프로그램입니다.
많은 요청이 웹 서버로 유입되면 웹 서버는 그만큼 많은 리소스를 필요로 합니다.
이러한 경우 우리가 가장 먼저 생각해볼 수 있는 방법은 컴퓨터를 더 좋은 컴퓨터로 바꾸는 것입니다.
마치 고사양 게임을 하기 위해 CPU, RAM, 그래픽 카드를 업그레이드 하는 것처럼 말이지요.
하지만 해보신 분들은 아시겠지만, 부품들의 스펙이 올라갈수록 가격도 천정부지로 올라갑니다.
서버도 마찬가지입니다.
한 대의 서버 사양을 올리는 것은 가장 편하지만, 한계가 명확하고 비싼 방법입니다.
이러한 방법을 수직적 확장, Scale Out이라고 합니다.
수평적 확장
그렇다면 수직적 확장 말고는 늘어나는 요청에 대응하는 방법이 없는 것일까요?
서버의 개수를 늘리고, 요청을 분담하면 됩니다.
로드 밸런서라는 장치를 두고 요청을 분산하는 방식입니다.
로드 밸런서는 서버 대신 요청을 받은 후, 자신에게 할당된 서버 목록으로 요청을 전달합니다.
이 때, 설정에 따라 적절한 서버로 요청을 분산할 수 있습니다.
책에서는 다음과 같이 표현하고 있습니다.
이번 스터디를 통해 지리적 라우팅이라는 개념을 배우게 되었습니다.
모든 서버에게 차례대로 동일한 횟수만큼 요청을 분산하는 라운드 로빈 방식으로 작동하는 줄 알았지만, 지리적으로 가까운 데이터 센터로 이동하는 방식도 적용할 수 있다고 합니다.
마스터 슬레이브 다중화(Master-Slave Replication)
시스템에서 가장 자주 병목의 원인이 되는 지점은 데이터베이스입니다.
그래서 시스템의 규모가 커지면 데이터베이스를 다중화하는 것도 반드시 필요한 일 중 하나입니다.
데이터베이스는 서버와 같이 단순하게 여러 대를 두는 방식으로는 다중화를 할 수 없습니다.
단순 컴퓨팅이 아닌 데이터 저장의 역할을 하기 때문입니다.
따라서 데이터베이스 중 하나는 반드시 최신의 정보로 업데이트 되어야 합니다.
대표적으로 사용되는 방법이 마스터-슬레이브 다중화입니다.
통상적으로 데이터베이스는 쓰기 작업보다 읽기 작업을 더 많이 한다는 점에서 착안하여 쓰기 / 읽기 전용 데이터베이스를 분리합니다.
이 때, 쓰기 전용 데이터베이스를 마스터, 읽기 전용 데이터베이스를 슬레이브라고 칭합니다.
마스터는 쓰기 작업인 CREATE / UPDATE / DELETE 명령을 담당하고, 슬레이브는 읽기 작업인 SELECT 명령을 담당합니다.
쓰기 데이터베이스는 주기적으로 변경사항을 읽기 데이터베이스로 전달하여 동기화를 진행합니다.
슬레이브에 장애가 발생하면, 다른 슬레이브가 읽기 작업을 추가 담당하거나 마스터가 일시적으로 읽기 작업도 담당합니다.
만약 마스터에 장애가 발생하면 데이터의 변경사항이 유실될 수 있습니다.
과거에는 이러한 상황에 대응하기 위한 다중화 방식이 존재했지면, 클라우드의 발달로 변경사항의 유실을 막을 수 있는 백업 조치가 되어있습니다.
요즘은 마스터와 슬레이브라는 단어가 부적절하다는 이야기 많기 때문에 주 데이터베이스, 부 데이터베이스라고 표현합니다.
멀티 마스터 다중화
위에서 주 데이터베이스에 장애가 발생하여 변경사항을 유실하는 경우에 대해 언급했습니다.
과거에는 이러한 상황에 대응하기 위해 마스터를 여러개 두는 멀티 마스터 다중화 방식을 사용하기도 했습니다.
MySQL의 MMM 혹은 PostgreSQL의 BDR과 같은 오픈 소스를 통해 쓰기 전용 데이터베이스 간의 데이터 동기화를 할 수 있는 구조로 주 데이터베이스의 장애를 대비했습니다.
이와 관련된 레퍼런스를 찾아보려고 했지만, 테크 기업에서 활용한 사례를 찾지 못했습니다.
이를 통해 클라우드 기반의 시스템에서는 고려되지 않는 이슈로 생각되었습니다.