dev_harry.log https://velog.io/ 새로움이 두렵지 않은 탐험가 Tue, 09 Dec 2025 02:29:32 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed dev_harry.log https://velog.velcdn.com/images/dev_harry/profile/dfb0b436-5b47-4d87-af20-6e981bd525f6/image.png https://velog.io/ Copyright (C) 2019. dev_harry.log. All rights reserved. <![CDATA[가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 1장 사용자 수에 따른 규모 확장성]]> https://velog.io/@dev_harry/%EA%B0%80%EC%83%81-%EB%A9%B4%EC%A0%91-%EC%82%AC%EB%A1%80%EB%A1%9C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-1%EC%9E%A5-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%88%98%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B7%9C%EB%AA%A8-%ED%99%95%EC%9E%A5%EC%84%B1 https://velog.io/@dev_harry/%EA%B0%80%EC%83%81-%EB%A9%B4%EC%A0%91-%EC%82%AC%EB%A1%80%EB%A1%9C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-1%EC%9E%A5-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%88%98%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B7%9C%EB%AA%A8-%ED%99%95%EC%9E%A5%EC%84%B1 Tue, 09 Dec 2025 02:29:32 GMT

이 글은 〈가상 면접 사례로 배우는 대규모 시스템 설계 기초〉를 읽으며 이해한 내용을 바탕으로 정리한 개인 스터디 문서입니다.

1. 단일 서버에서 시작하는 웹 서비스 구조

우리가 흔히 만드는 서비스는 처음엔 대부분 단일 서버로 시작한다. 사용자가 웹사이트에 접속하면 다음과 같은 과정이 일어난다:

  1. 사용자가 브라우저에 도메인을 입력
  2. DNS가 해당 도메인을 IP 주소로 변환
  3. 변환된 IP로 요청이 전송
  4. 서버가 HTML·JSON 등을 응답

여기까지만 보면 단일 서버만 있어도 충분해 보이지만, 실제로는 조금만 사용자가 늘어도 서버와 데이터베이스를 분리해야 한다.

2. 데이터베이스 선택: RDBMS vs NoSQL

서비스가 커지면 데이터 저장 방식도 고민해야 한다.

관계형 데이터베이스(RDBMS)

  • MySQL, PostgreSQL 등
  • 테이블 기반 구조
  • 복잡한 조인, 트랜잭션에 강함

비관계형 데이터베이스(NoSQL)

  • MongoDB, Cassandra 등
  • 스키마 유연
  • 거대한 데이터, 낮은 지연시간 등이 필요할 때 적합
  • 조인보다는 단순 조회가 빠르고 확장성에 초점

요약하면 구조화된 데이터 + 트랜잭션 중심이면 RDBMS, 유연함·확장성·빠른 읽기 중심이면 NoSQL이 어울린다.

3. 규모 확장: Vertical vs Horizontal

서비스가 커질 때 선택지는 크게 두 가지다.

수직 확장(Scale-up)

  • 더 좋은 CPU·RAM을 추가
  • 구조는 단순
  • 하지만 서버 한 대의 한계가 명확하고 장애 시 전체가 멈춤

수평 확장(Scale-out)

  • 서버를 여러 대로 늘리는 방식
  • 현대 대부분의 대규모 서비스가 이 방식을 사용
  • 단, 서버 간 트래픽을 나누기 위한 로드밸런서가 필수

4. 로드밸런서가 필요한 이유

로드밸런서는 요청을 여러 서버에 나눠 보내 균형을 맞춰준다.

로드밸런서를 쓰면:

  • 특정 서버가 죽어도 나머지 서버에서 서비스가 계속됨
  • 서버를 더 추가하기 쉬워짐 → 자연스러운 확장성
  • 외부에는 로드밸런서의 IP만 노출되므로 보안에도 도움

실제로 “대규모 서비스”라는 느낌이 나기 시작하는 지점이 여기다.

5. 데이터베이스 다중화(Master–Replica)

읽기와 쓰기를 분리하여 성능과 안정성을 높이는 방식이다.

  • Master(주 DB): 쓰기 전용
  • Replica(부 DB): 읽기 전용

읽기 요청은 대부분 Replica가 처리하므로 부하가 줄고, Master 장애 시 Replica를 승격시키는 식의 장애 대응도 가능하다.

이 구조만으로도 서비스 안정성이 상당히 좋아진다.

6. 캐시(Cache): 성능 향상의 핵심

애플리케이션이 느려지는 가장 흔한 원인은 DB 과부하다. 이를 줄이기 위해 많이 쓰는 값은 캐시에 보관한다.

캐시 계층을 두면 생기는 장점

  • 데이터 조회가 훨씬 빨라짐
  • DB의 부담이 크게 줄어듦
  • 캐시 서버만 별도로 확장할 수 있음

대표 전략: Read-Through

  1. 캐시에서 먼저 검색
  2. 없으면 DB에서 가져오고 캐시에 저장
  3. 이후 요청은 캐시만 조회

캐시 사용 시 주의사항

  • 갱신은 적고 조회가 많을 때 효과적
  • 너무 작은 캐시는 잦은 eviction으로 오히려 병목
  • 캐시 서버 단독 운영은 위험 → 다중화 필요
  • 만료 정책은 필수(LRU, LFU 등)

7. CDN(Content Delivery Network)

정적 파일(이미지, JS, CSS)을 사용자와 가까운 서버에 저장해 빠르게 제공하는 기술.

CDN을 쓰면 다음이 달라진다:

  • 정적 리소스 로딩 속도 향상
  • 우리 서버로 가는 요청 감소
  • 글로벌 사용자가 많은 서비스에서 필수

TTL, 캐시 무효화 방식, 비용 구조 등을 고려해 적용하면 된다.

8. 무상태 웹 계층(Stateless Architecture)

서버를 여러 대로 늘리려면 서버가 세션을 직접 들고 있으면 절대 안 됨.

상태를 서버가 들고 있을 때 문제

  • 같은 사용자 요청이 항상 같은 서버로 가야 함 → sticky session 필요
  • 서버 장애 발생 시 세션 날아감
  • 서버 추가/제거가 어려움

무상태 구조

  • 세션·상태는 Redis나 DB 등 외부 저장소에 보관
  • 어떤 서버가 요청을 받아도 동일한 결과 제공 가능
  • 자동 스케일링과 궁합이 좋음

9. 여러 데이터 센터 지원

전 세계 사용자에게 빠르고 안정적인 서비스를 제공하기 위해 필요한 요소들:

  • GeoDNS를 통한 위치 기반 라우팅
  • 데이터센터 간 데이터 동기화
  • 멀티 리전 배포 자동화
  • 지역 장애 시 트래픽 우회

이 단계는 글로벌 서비스를 목표로 할 때 반드시 고려해야 한다.

10. 메시지 큐(Message Queue)

서비스 간 결합을 느슨하게 만들어주는 핵심 요소.

메시지 큐를 도입하면:

  • 서비스가 서로 직접 의존하지 않음
  • 소비자가 잠시 죽어도 메시지 손실 없이 처리 가능
  • 스케일 아웃 방식의 비동기 처리에 최적

대규모 시스템은 거의 대부분 메시지 큐를 사용한다고 보면 된다.

11. 로그·모니터링·자동화

시스템이 커지면 운영이 코드를 뛰어넘는다.

  • 로그: 문제 파악 및 디버깅
  • 메트릭: DAU, 트래픽, 에러율 등 상태 파악
  • 자동화: 배포, 알람, 스케일링 등 운영 효율 극대화

운영 기반이 튼튼해야 장애 대응과 확장이 수월해진다.

12. 데이터베이스의 본격 확장: 샤딩(Sharding)

DB의 수평 확장 전략으로, 데이터를 여러 DB로 나누는 방식.

특징

  • 각 샤드는 스키마는 같지만 데이터는 서로 다름
  • 샤딩 키 설계가 성패를 가름
  • 부하 분산 + 저장 용량 확보 가능
  • 운영 난이도는 높아짐(조인 불가, 재샤딩 등)

규모가 진짜 커지기 시작하면 DB 샤딩을 고민하게 된다.

마무리

이번 스터디에서 느낀 점은, 대규모 시스템 설계는 특정 기술을 아는 것보다 ‘문제를 단계별로 분해하는 사고 방식’을 익히는 게 중요하다는 것이다.

  • 처음엔 단일 서버
  • 트래픽이 늘면 웹/DB 분리
  • 더 늘면 로드밸런싱
  • 캐시, CDN, 메시지 큐, 무상태 아키텍처로 확장
  • 지역 확장, 샤딩으로 초대규모 대응
]]>