1. [가상 면접 사례로 배우는 대규모 시스템 설계 기초] 1장: 사용자 수에 따른 규모 확장성
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - YES24
“페이스북의 뉴스 피드나 메신저, 유튜브, 구글 드라이브 같은 대규모 시스템은 어떻게 설계할까?”IT 경력자라도 느닷없이 대규모 시스템을 설계하려고 하면 막막하다고 느낄 수 있다. 특히나
www.yes24.com
✨수백만 사용자를 지원하는 시스템의 설계✨
단일 서버: 웹, 앱, 데이터베이스, 캐시 등이 서버 한 대에서 구동되는 시스템
▶️ 늘어나는 사용자에 따라 서버 확장이 필요 ▶️ 웹/모바일 트래픽을 처리하는 웹 계층 서버와 데이터베이스 서버를 분리하여 확장
웹 애플리케이션: 비즈니스 로직, 데이터 저장 등을 처리하기 위해 서버 구현용 언어(자바, 파이썬 등)를 사용하고, 프레젠테이션용으로는 클라이언트용 언어(HTML, JS 등)를 사용한다.
모바일 앱: 앱과 웹 서버 간 통신은 HTTP 프로토콜로 수행된다. HTTP를 통해 반환되는 응답 데이터 포맷은 보통 JSON이 널리 쓰인다.
✔️ 관계형 vs 비관계형 데이터베이스
비관계형 데이터베이스(NoSQL)는 일반적으로 조인 연산을 지원하지 않는다.
대부분 관계형 데이터베이스(RDBMS)를 사용하는데 다음과 같은 경우에는 비관계형 데이터베이스가 바람직하다.
- 아주 낮은 응답 지연시간이 요구되는 경우
- 비정형 데이터를 다루는 경우
- 데이터를 직렬화/역직렬화할 수 있는 경우
- 저장할 데이터 양이 아주 많은 경우
✔️ 스케일 업 vs 스케일 다운
스케일 업(scale up): 수직적 규모 확장, 서버에 더 좋은 CPU, 더 많은 RAM 등의 고사양 자원을 추가하는 것을 의미한다.
서버로 유입되는 트래픽 양이 적을 때 좋은 선택
그러나 장애에 대한 자동복구(failover)나 다중화(redundancy)를 지원하지 않는다.
서버에 장애 발생 시, 웹/앱은 완전히 중단된다.
스케일 다운(scale down): 수평적 규모 확장, 더 많은 서버를 추가하여 성능을 개선하는 것으로, 대규모 애플리케이션에 적절하다.
사용자가 많아져 서버가 한계에 도달하고 응답 속도가 느려지거나 서버 접속이 불가해지는 상황에 적절한 조치는 🌟로드밸런서 도입🌟이다
✔️ 로드밸런서
로드밸런서는 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산한다.
사용자는 로드밸런서의 공개 IP 주소로 접속하고, 로드밸런서는 사설 IP 주소를 이용하여 웹 서버와 통신한다.
웹 서버를 추가하면 장애 자동복구 문제가 해소되고, 로드밸런서는 자동으로 트래픽을 분산하며 웹 계층의 가용성(availability)은 높아진다.
✔️ 데이터베이스의 다중화
데이터 원본을 저장하는 주 서버, 사본을 저장하는 부 서버와 같이, RDBMS는 서버 사이에 주(master)-부(slave) 관계를 설정하는 다중화를 지원한다.
- 쓰기 연산은 마스터에서만 지원한다. (주 데이터베이스 서버에만 지원)
- 데이터베이스를 변경하는 명령어(INSERT, DELETE, UPDATE)는 주 데이터베이스로만 전달되어야 한다.
- 읽기 연산이 보통 더 많기 때문에 부 데이터베이스가 더 많다.
데이터베이스 다중화의 장점은
- 병렬 처리 가능한 쿼리 수가 늘어 성능이 좋아진다.
- 안정성 보장. 데이터를 여러 장소에 다중화시키면 서버가 일부 파괴되어도 데이터는 보존된다.
- 가용성 보장. 하나의 DB 서버에 장애가 생겨도 데이터를 가져올 다른 DB 서버가 존재하므로 계속 서비스할 수 있다.
- 부 서버가 다운되면 주 서버가 임시적으로 읽기 연산을 맡고, 즉시 새로운 부 서버가 장애 서버를 대체한다.
- 주 서버가 다운되면 한 대의 부 서버가 새로운 주 서버가 되고, 모든 연산은 임시적으로 주 서버에서 수행된다.
✔️ 캐시(Cache)
응답시간의 개선을 위해 사용한다. 캐시를 붙이고 정적 콘텐츠를 CDN으로 옮기면 응답시간을 개선할 수 있다.
캐시 계층은 데이터가 잠시 보관되는 곳으로, 데이터베이스의 부하를 줄여 성능을 개선, 캐시의 규모를 독립적으로 확장시킬 수 있다.
캐시에 저장되어 있는 데이터는 캐시에서 읽고, 없는 데이터는 데이터베이스에서 해당 데이터를 읽어 캐시에 쓴 뒤 웹 서버에 데이터를 반환하는 구조로 캐시 서버를 이용한다.
캐시를 언제 사용하는가
- 데이터 갱신은 빈번하지 않지만, 데이터 참조가 빈번하게 발생하는 경우
- 캐시는 휘발성 메모리이므로 중요 데이터는 지속적 저장소에 보관해야 한다
- 캐시에 보관된 데이터에 대한 만료 정책 필요
- 데이터 저장소의 원본 데이터와 캐시의 사본 데이터가 동일한지 그 일관성 여부를 고려해야 한다
- SPOF를 피하려면 여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다
- 캐시 메모리를 과할당하여 데이터량이 급증할 시 발생 가능한 문제를 방지한다
- 데이터 방출 정책(LRU, LFU, FIFO)을 적절히 사용
더 찾아볼 내용 >>
- 데이터의 직렬화와 역직렬화
- 단일 장애 지점(Single Point of Failure, SPOF)
- 과할당(overprovision)
To Be Continued...🌝