[대규모 시스템 설계 스터디] 1장 정리

김연준·2026년 7월 9일

[대규모 시스템 설계 스터디]

목록 보기

1/13

들어가기에 앞서서

이번 방학 기간동안 대규모 시스템 설계 스터디를 진행한다.

교재는 가상 면접 사례로 배우는 대규모 시스템 설계 기초 를 사용했다.

기간은 7월 2일 ~ 9월 12일까지로 예상한다.

각 주마다 2번씩 진행되고, 스터디 과제는 벨로그 작성과 각 단원 문제풀이로 진행하며, 중간마다 시험문제를 출제하여 수준을 검토한다.

최종적으론 대규모 프로젝트를 진행하여 스터디를 마무리한다.

사용자 요청의 종류

사용자 요청에는 크게 웹 앱과 모바일 앱 두 가지 종류가 있다.

웹 앱은 비즈니스 로직과 데이터 저장 등을 처리하기 위해 서버 구현용 언어(자바, 파이썬 등)를 사용하고, 프레젠테이션 용으로는 클라이언트 구현용 언어(HTML, 자바스크립트 등)를 사용한다.

모바일 앱과 웹 서버 간 통신에는 HTTP 프로토콜을 이용한다. HTTP 프로토콜을 통해 반환되는 응답 데이터의 포맷으로는 보통 JSON이 쓰인다.

서버는 웹 계층과 데이터 계층으로 분리할 수 있으며, 각 계층을 독립적으로 확장해 나갈 수 있다.

데이터베이스

DB는 전통적인 관계형 DB와 비관계형 DB로 나뉜다.

관계형 DB (RDBMS)

관계형 데이터베이스 관리 시스템(RDBMS)이라고도 부른다.

대표적으로 MySQL, 오라클 DB, PostgreSQL 등이 있다.
자료를 테이블과 행, 열로 표현한다.
SQL을 사용하면 여러 테이블에 있는 데이터를 그 관계에 따라 조인하여 합칠 수 있다.

비관계형 DB (NoSQL)

대표적으로 CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB 등이 있다.

키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소 4가지로 나눌 수 있다.
일반적으로 조인 연산은 지원하지 않는다.

NoSQL이 적합한 경우는 다음과 같다.

아주 낮은 응답 지연시간이 요구될 때
다루는 데이터가 비정형이라 관계형 데이터가 아닐 때
데이터를 직렬화하거나 역직렬화할 수 있기만 하면 될 때
아주 많은 양의 데이터를 저장해야 할 때

스케일 업 vs 스케일 아웃

구분	설명
스케일 업 (수직적 규모 확장)	서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM)을 추가하는 행위
스케일 아웃 (수평적 규모 확장)	더 많은 서버를 추가하여 성능을 개선하는 행위

스케일 업은 확장에 한계가 있으며, 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 못한다.

로드밸런서

부하분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.

서버 간 통신에는 보안을 위해 사설 IP 주소를 이용한다.
웹 계층의 부하 분산 및 장애 대응이 가능해지고, 가용성이 향상된다.

OSI 계층 기준

OSI 기준으로 L4(NLB)와 L7(ALB) 로드밸런서가 있다.

L4: 전송 계층(TCP/UDP)에서 동작한다. IP와 포트 기반으로 트래픽을 분산하며, 패킷 내용을 보지 않아 빠르고 오버헤드가 적다.
L7: 애플리케이션 계층(HTTP/HTTPS)에서 동작한다. URL 경로, 헤더, 쿠키, 호스트명 등을 보고 라우팅한다. 세밀한 제어가 가능한 대신 상대적으로 무겁다.

구현 방식 기준

하드웨어 LB: 전용 장비를 사용한다. 고성능이지만 비싸고 확장성이 떨어진다.
소프트웨어 LB: 유연하고 저렴해서 클라우드 환경에 적합하다.

DB 다중화

보통 master-slave 관계를 설정하고, 원본은 주서버(master)에, 사본은 부서버(slave)에 저장한다.

쓰기 연산은 마스터에서만 지원하고, 슬레이브는 사본을 전달받아 읽기 연산만 지원한다.
DB에서는 읽기 연산이 쓰기 연산보다 비중이 크기 때문에, 통상 부데이터베이스 수가 더 많다.

이렇게 다중화를 하면 읽기 연산을 병렬 처리할 수 있어 성능이 향상되고, 안정성과 가용성이 높아진다.

💡 새로 알게 된 점
master가 꼭 하나일 필요는 없다.
쓰기 충돌 문제, PK 자동 증가값 충돌, 일관성 관리 복잡도 등의 문제가 있지만, master를 여러 개 둘 수도 있다.

캐시 (Cache)

값비싼 연산 결과나 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다.

데이터베이스보다 훨씬 빠르고, 데이터베이스의 부담을 덜어주는 장점이 있다.
정적 콘텐츠를 CDN으로 옮기면 응답시간을 개선할 수 있다.

읽기 주도형 캐시 전략: 찾는 데이터가 캐시에 없다면 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환한다.

캐시 사용 시 고려할 부분

어떤 데이터를 둘지, 보관된 데이터는 어떻게 만료시킬지, 일관성 유지와 장애 대처는 어떻게 할지, 캐시 메모리의 크기를 얼마로 잡고 데이터 방출 정책을 무엇으로 할지 등 (자세한 내용은 책 참조)

콘텐츠 전송 네트워크 (CDN)

정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크다.

이미지, 비디오, CSS, JavaScript 파일 등을 캐시하며, 동적 콘텐츠도 가능하다.
쉽게 말하면, 사용자에게 가장 가까운 CDN 서버로 안내하여 콘텐츠를 받게 하는 것이다.

CDN 사용 시 고려할 부분

비용, 적절한 만료 시한 설정, CDN 장애에 대한 대처 방안, 콘텐츠 무효화 방법 등 (자세한 내용은 책 참조)

무상태(Stateless) 웹 계층

웹 계층을 수평적으로 확장하기 위해서는 상태 정보를 제거해야 한다.

상태 정보를 가지면 특정 사용자의 요청이 그 상태 정보를 가진 특정 서버로만 가야 하기 때문에, 수평 확장을 방해한다.

같은 클라이언트의 요청을 같은 서버로 전송시키려면 로드밸런서의 고정 세션(sticky session) 기능을 사용하는데, 이는 로드밸런서에 부담을 주고 서버를 추가하고 제거하기도 까다로워진다.

따라서 상태 정보가 필요하면 지속성 저장소에 보관하고, 필요할 때 가져오게 하는 것이 좋다.

데이터 센터

단일 데이터 센터만 이용한다면, 해당 센터에 문제가 생길 시 서비스에 장애가 발생할 수 있다.

이를 방지하기 위해 두 개의 데이터 센터를 이용하고, 장애가 없는 상황에서는 사용자와 가까운 데이터 센터로 안내한다. 이 절차를 지리적 라우팅이라고 한다.

geoDNS: 사용자 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해 주는 DNS 서비스

다중 데이터 센터 아키텍처를 위해 고려할 점으로는 트래픽 우회, 데이터 동기화, 테스트와 배포 등이 있다. (자세한 내용은 책 참조)

메시지 큐

대규모 분산 시스템에서는 시스템의 컴포넌트들이 각기 독립적으로 확장될 필요가 있다. 이런 문제를 해결하기 위한 핵심 전략 중 하나가 메시지 큐다.

메시지 큐는 메시지 무손실을 보장하는 비동기 지원 컴포넌트다.

이 기능을 사용하면 서비스 또는 서버 간 결합이 느슨해져, 규모 확장성이 보장되어야 하는 안정적인 애플리케이션을 구성하기 좋다.
큐가 커지면 더 많은 작업 프로세스(소비자)를 추가해야 처리 시간을 줄일 수 있고, 큐가 항상 비어 있다면 작업 프로세스의 수를 줄일 수 있다.

로그, 메트릭, 자동화

로그: 시스템 오류와 문제들을 찾아내는 데 필수적이다. 서버 단위로 모니터링할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있다.
메트릭: 시스템의 현재 상태를 파악할 수 있는 지표다. 사업 현황에 관한 유용한 정보도 얻을 수 있다.
자동화: 지속적 통합(CI)을 도와주는 도구를 활용하면 코드를 자동으로 검증하여 문제를 쉽게 탐지할 수 있다. 이 외에도 빌드, 테스트, 배포 등을 자동화할 수 있다.