서버가 느려지면 어떻게 해결할까? (Scale Out vs Scale Up, Primary-Secondary DB 아키텍처, 캐시(Redis), DSR)

🌱 CS

서버가 느려지면 어떻게 해결할까? (Scale Out vs Scale Up, Primary-Secondary DB 아키텍처, 캐시(Redis), DSR)

alreadykite 2023. 12. 10. 15:14

서버가 느려질 경우 해결하는 방법에 대하여 순차적으로 알아보자

1. 서버 확장 : 스케일 아웃, 스케일 업

2. DB 병목 해결 : Primary-Secondary DB, 자주 쓰는 데이터 캐시(Redis)

1. 서버 확장

1) 스케일 아웃(Scale Out)

서버 여러 대를 추가하여 시스템을 확장하는 '수평 확장' 방법이다.

서버가 여러 대가 되기 때문에 서버에 걸리는 부하를 균등하게 해주는 로드밸런싱이 필수적으로 동반되어야 한다.

스케일 아웃의 경우 서버 한 대가 장애로 다운되더라도 다른 서버로 서비스 제공이 가능하다는 장점이 있다.

하지만 모든 서버가 동일한 데이터를 가지고 있어야 하므로 데이터 변화가 적은 웹 서버에 적합한 방식이다.

2) 스케일 업(Scale Up)

서버에 CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 '수직 확장' 방법이다.

서버에 추가 부품을 장착할 수 있는 여유 슬롯이 있다면 CPU나 RAM을 추가할 수 있고, 그렇지 않다면 서버 자체를 고성능으로 교체하는 것이 필요하다.

스케일 업의 경우 서버 한대에 모든 부하가 집중되므로 장애 시 영향을 크게 받을 수 있는 위험성이 있다. (서버 자체가 죽을 수도 있고, 동적으로 늘리기가 어려움)

반면, 한대의 서버에서 모든 데이터를 처리하므로 데이터 갱신이 빈번하게 일어나는 데이터베이스 서버에 적합한 방식이다.

2. DB 병목 해결

서버 자체는 늘려서 서버의 자원은 충분한데 DB 병목으로 느려진다면 DB 단에서의 작업도 필요하다.

1) Primary-Secondary 데이터베이스 구조

Primary-Secondary 구조는 고성능 및 확장성, 고가용성을 고려하여 데이터 정합성을 유지하며 데이터베이스 서버를 늘릴 수 있는 구조이다.

데이터베이스 서버를 늘릴 때는 데이터베이스 서버 간의 데이터 정합성(Data Consistency)을 유지해야 한다.

데이터베이스의 성격은 일반적으로 SELECT 쿼리를 통한 데이터 읽기(READ) 작업이, INSERT, UPDATE, DELETE 등의 데이터 쓰기(WRITE) 작업보다 훨씬 많다.

데이터 정합성을 유지하며 데이터 읽기 작업 용도의 DB를 분리하는 방식이 Read-Replica 방식이다.

Read-Replica 구조

Primary DB는 쓰기 작업, Secondary DB는 읽기 작업을 수행

성능 및 확장성을 위한 Primary-Secondary 구조로, 모든 데이터의 쓰기 작업은 Primary DB에서만 실행하고, 최종 데이터 상태를 Secondary DB에 주기적으로 복제(replication)하는 방식을 사용하여 복수의 DB 서버 간 데이터 정합성을 해결한다.

Active-Standby 구조

Primary DB가 읽고 쓰기 작업, Secondary DB는 백업DB로 Stand-By 형태 유지

성능보다는 백업에 초점을 둔 고가용성을 위한 Primiary-Secondary 구조이다.

Secondary DB를 Stand-By 형태로 유지하다가, Primary DB에 문제가 발생하면 Secondary DB(백업DB)가 Active 되는 형태를 사용한다. 백업 DB는 주기적으로 Primary DB의 스냅샷을 복제하여 데이터 정합성을 유지한다.

쿼리 오프로딩(Query Offloading)

애플리케이션 설계 시부터 DB 읽기/쓰기 작업 모듈을 분리하여 DB 작업을 분산시킴
(Production DB에서 수행되는 쿼리 작업의 일부를 다른 시스템으로 이동시키는 것)

각각의 모듈은 쓰기/읽기 전용 DB에 접속할 수 있도록 커넥션 풀(connection pool)을 구현한다.

N개의 Secondary DB 중, 가장 성능이 좋은 서버로 연결될 수 있도록 로드 밸런싱 또한 구현한다.

Primary DB에 발생한 WRITE 작업이 CDC(Change Data Capture)로그를 통해 Secondary DB에 전달되는데, Secondary의 수가 많을수록 이 작업에 부하가 생길 수 있으므로 바쁜 Primary DB에 부담을 줄이고자 중간에 복제만 담당하는 Staging DB를 둘 수도 있다.