“어떻게 만들 것인가”
웹 서비스 개발에 있어서 대부분의 초보자는 “어떻게 만들 것인가”에 집중합니다.
하지만 규모가 커질수록 중요한 것은 “어떻게 지탱할 것인가”입니다.
바로 이 챕터에서는, 대규모 서비스를 뒷받침하는 시스템 구조가 어떻게 구성되는지를 이야기합니다.
웹 서비스의 전체 구조를 한눈에 이해하고, 스스로 그려볼 수 있을 만큼 익숙해지는 것이 이 장의 목표입니다.
"웹 서비스는 단일 서버로 구성되지 않는다"
처음엔 단일 서버로도 서비스를 운영할 수 있습니다. 웹 서버, 애플리케이션, 데이터베이스가 하나의 머신 안에 있습니다. 그러나 트래픽이 늘어나고 사용자가 많아지면, 이 구조는 곧 한계에 봉착합니다.
- 서비스가 무거워지면 서버는 느려지고,
- 데이터가 많아지면 DB는 병목이 생기고,
- 사용자 요청이 몰리면 응답이 지연됩니다.
따라서 대규모 웹 서비스는 여러 구성요소를 분리하고, 각 요소가 담당하는 역할을 명확히 해야 합니다.
"시스템은 계층 구조로 나뉜다"
웹 서비스는 다층 구조(Multi-tier Architecture)를 가집니다. 대표적으로 다음과 같은 계층이 있습니다:
- 클라이언트 (브라우저, 앱 등)
- 웹 서버 (Web Server) – 예: Nginx, Apache
- 애플리케이션 서버 (App Server) – 예: Spring, Django, Rails 등
- 데이터베이스 서버 (DB Server) – 예: MySQL, PostgreSQL
- 캐시 서버 (Cache) – 예: Redis, Memcached
- 로드 밸런서 (Load Balancer) – 트래픽 분산
- 스토리지 / CDN – 정적 자원 처리
데이터 흐름은 이렇게 흘러갑니다.
클라이언트 → 로드 밸런서 → 웹 서버 → 애플리케이션 서버 → DB (또는 캐시) → 응답
실제 서비스에서는 이 구조가 더 복잡해질 수 있지만, 이 흐름을 기본 골격으로 이해하면 전체 아키텍처를 쉽게 파악할 수 있습니다.
"중요한 것은 ‘흐름’이다"
저자는 단순히 “무엇이 있는지”가 아니라, “어떻게 흐르는지”를 그려보라고 강조합니다.
서버 하나하나를 나열하기보다, 실제 사용자의 요청이 어떻게 들어오고 어떤 과정을 거쳐 응답되는지를 생각해야 합니다.
예를 들어 사용자가 로그인을 시도하면:
- 요청이 웹 서버를 거쳐 애플리케이션 서버로 이동하고,
- 서버는 DB에서 사용자 정보를 조회하며,
- 자주 쓰는 세션 정보는 캐시로 처리하고,
- 그 결과가 다시 클라이언트에 전달됩니다.
이 흐름의 이해가 없다면, 문제 발생 시 어디에서 병목이 생겼는지 파악하기 어렵습니다.
"시스템 다이어그램을 그려보자"
저자는 말합니다: “머릿속으로만 구조를 이해하지 말고, 실제로 그려보라.”
- 구성요소 간의 관계를 선으로 연결하고,
- 요청 흐름 방향을 화살표로 표현해보는 것만으로도,
- 구조적 이해가 확연히 달라집니다.
특히 장애 발생 시 어떤 계층에서 문제가 발생할 수 있는지를 시각적으로 파악하면, 문제 대응 속도가 크게 향상됩니다.
사실 회사에서 "회원도메인"의 '시스템 다이어그램'을 그리기 위해서 팀원들을 설득하고 노력했으나 쉽지 않았던 기억이 있습니다.
개인적으로는, 아래의 요소들이 고려가 되어야 한다고 생각합니다.
- 팀 내의 리소스가 충분할가?
- 충분한 팀내 합의를 이루었는가?
- 규칙을 어겼을때는 어떻게 하겠는가?
즉 진리의 사바사, 팀바팀 😭
"각 계층의 역할 정리"
웹 서버 | 정적 파일 처리, HTTPS 종료, 요청 전달 (예: Nginx, Apache) |
애플리케이션 서버 | 비즈니스 로직 처리, DB/캐시와 통신 (예: Spring, Django) |
DB 서버 | 데이터 저장/조회, 트랜잭션 처리 |
캐시 서버 | DB 부하 분산, 빠른 데이터 접근 (예: Redis) |
로드 밸런서 | 요청을 여러 서버로 분산, 이중화 |
CDN/Storage | 이미지, JS/CSS 등 정적 자원 전송 가속화 |
"병목과 장애는 어디서 발생할까?"
대규모 서비스의 현실은 항상 병목과의 싸움입니다.
- 대부분의 병목은 데이터베이스, I/O, 네트워크에서 발생합니다.
- 서비스 장애는 갑자기 오는 것이 아니라, 대부분 병목이 쌓여서 터지는 것입니다.
- 따라서 각 계층마다 장애 대응 전략을 준비해두어야 합니다. (예: 타임아웃 설정, 캐시 백업, 대체 경로 등)
"구조를 ‘이해’하는 것이 아닌, ‘사용’하는 것"
저자는 이게 단순히 이론적인 구조 나열을 말하자는 게 아니라고 합니다.
실제 서비스 운영에서 반드시 마주치는 구성 요소들을, 실행 흐름의 관점에서 바라보고 직접 그려보는 훈련입니다.
💬 “구성 요소를 나열하는 것이 아니라, 요청이 흐르는 그림을 상상하고 손으로 그려보자.”
이것이 대규모 서비스를 ‘지탱하는’ 첫걸음입니다.
출판된지 오래된 서적(2009년)이여서 그런지..
저는 일반적인 내용들이라는 생각이 들었습니다.
💬 "이 책을 신입 시절에 읽었으면 좋았겠다" 라는 생각이 드네요.
'개발서적리뷰 > 대규모 서비스를 지탱하는 기술' 카테고리의 다른 글
🚀 1장 : 대규모 웹 서비스 개발 오리엔테이션 (0) | 2025.04.21 |
---|
댓글