AI VIDEO BRIEFING

시스템 설계 입문 완전 정리: 로드 밸런서와 캐시, 데이터베이스 복제로 사진 공유 앱 확장하기

월 10달러짜리 서버 한 대로 시작한 사진 공유 앱이 어디서 먼저 무너지는지 따라가며 로드 밸런서와 캐시, 데이터베이스 복제, 무상태 서버 같은 시스템 설계의 기본 개념을 등장하는 순서대로 하나씩 짚었습니다.

서버 한 대가 무너지는 순서대로 배우는 시스템 설계 입문 영상 대표 이미지

핵심 메시지

  • 시스템 설계란 필요한 부품을 골라 알맞은 자리에 놓는 기술이며, 부품은 앱이 실제로 고장 난 뒤에 추가된다.
  • 서버 한 대는 자원 고갈, 데이터베이스 과부하, 단일 장애점이라는 세 가지 방식으로 무너진다.
  • 면접에서는 상위 설계와 상세 설계 중 어느 높이에서 답할지 먼저 밝히는 것이 감점을 피하는 방법이다.
  • 여러 서버로 늘리는 순간 로그인 세션 같은 상태는 서버 밖 공유 저장소로 옮겨야 한다.
  • 캐시는 속도를 주는 대신 원본과 어긋날 위험을 함께 가져오므로 TTL과 능동 무효화 중 하나를 선택해야 한다.

쉽게 이해하기

이 강의는 개념을 하나씩 나열하는 대신 사진 공유 앱 하나를 함께 설계하며 진행됩니다. 처음에는 월 10달러짜리 서버 한 대에 웹 앱과 데이터베이스, 업로드된 사진까지 전부 올려둡니다. 강사는 대부분의 서비스가 이렇게 시작하는 것이 옳다고 말합니다. 만들기 쉽고, 문제가 생겼을 때 들여다볼 곳도 한 군데뿐이기 때문입니다.

문제는 하루에 1만 명이 몰려올 때 생깁니다. 첫째, CPU와 메모리가 바닥나 200밀리초에 열리던 페이지가 10초씩 걸립니다. 서버를 한 대 더 두면 이번엔 '누가 어느 서버로 가야 하는가'라는 질문이 생기고, 그 교통정리를 맡는 것이 로드 밸런서입니다. 둘째, 방문자 대부분이 같은 인기 사진을 요청하는데 데이터베이스는 매번 같은 질의를 처음부터 다시 실행합니다. 여기서 캐시가 등장합니다. 셋째, 디스크가 깨지거나 전원이 나가면 모든 것이 한 대에 있었던 탓에 서비스와 사진이 함께 사라집니다. 이 단일 장애점은 데이터베이스 복제본과 외부 객체 스토리지로 해결합니다.

강사는 요구사항을 기능 요구사항과 비기능 요구사항으로 나눕니다. 가입, 업로드, 팔로우, 피드, 좋아요는 있으면 보이고 없으면 티가 나는 기능 요구사항입니다. 반면 피드가 0.5초에 열리는지 8초 걸리는지, 디스크가 죽어도 사진이 남는지, 백만 명이 몰려도 버티는지는 비기능 요구사항입니다. 가족용 사진 앱과 인스타그램의 기능 목록은 거의 같지만 두 시스템이 완전히 다른 이유가 여기에 있습니다.

여러 서버로 늘린 뒤 사용자가 자꾸 로그아웃되는 버그는 상태(state)를 설명하는 좋은 예로 쓰입니다. 1번 서버가 자기 메모리에 로그인 세션을 저장했는데 다음 요청이 5번 서버로 가면 5번은 그 사용자를 모릅니다. 해법은 세션을 모든 서버가 함께 보는 공유 저장소로 옮겨 앱 서버를 무상태로 만드는 것입니다. 특정 사용자를 늘 같은 서버로 보내는 고정 세션은 간단해 보이지만, 그 서버가 죽으면 세션도 함께 사라지고 부하 분산도 무너집니다.

캐시 편에서는 속도와 정합성의 맞교환을 다룹니다. 캐시에서 읽으면 1밀리초 안에 응답이 오지만 같은 데이터를 데이터베이스에서 읽으면 20~30밀리초가 걸립니다. 대신 같은 데이터가 두 곳에 존재하게 되므로, 만료 시간을 두는 TTL과 데이터가 바뀔 때 캐시를 직접 지우는 능동 무효화 중 하나를 골라야 합니다. 인기 항목이 동시에 만료되며 데이터베이스로 요청이 몰리는 캐시 스탬피드는 만료 시각을 조금씩 어긋나게 두어 완화합니다.

주요 인사이트

  • 로드 밸런서는 특별한 하드웨어가 아니라 요청을 넘겨주는 일만 하는 서버 위의 애플리케이션이다. Nginx나 HAProxy, 클라우드 제공 서비스를 쓰면 되고, 그 자체가 단일 장애점이 되지 않도록 여러 대로 운영한다.
  • 로드 밸런서는 몇 초마다 각 서버에 상태를 확인해 응답이 없는 서버로는 요청을 보내지 않는다. 사용자가 오류를 보지 않는 이유는 죽은 서버로 요청이 애초에 가지 않기 때문이다.
  • '이 서버가 지금 사라지면 사용자가 잃는 데이터가 있는가'라는 질문 하나로 그 서버가 상태를 쥐고 있는지 판별할 수 있다. 사진을 외부 스토리지에 저장하는 것은 상태를 갖는 것과 무관하다.
  • 캐시에 넣기 좋은 대상은 크기가 작고, 자주 읽히며, 거의 바뀌지 않는 데이터다. 인기 게시물과 프로필 카드가 대표적이고, 로그인 세션도 같은 저장소가 맡는 경우가 많다.
  • 권한이나 공개 범위처럼 틀리면 사고로 이어지는 정보에는 만료 시간을 두지 않고 값이 바뀌는 즉시 캐시를 지운다. 반대로 홈 피드나 인기 목록은 수십 초 정도 오래된 값이어도 문제되지 않는다.

자주 묻는 질문

상위 설계와 상세 설계는 어떻게 구분하나요?

상위 설계는 앱 서버, 데이터베이스, 캐시, 큐, CDN 같은 큰 덩어리와 요청이 그 사이를 어떻게 오가는지를 보는 관점입니다. 상세 설계는 좋아요 버튼 하나를 눌렀을 때 어떤 함수가 처리하고 중복 집계를 어떻게 막을지처럼 한 기능 안쪽을 들여다봅니다.

지연시간과 대역폭은 어떻게 다른가요?

지연시간은 요청과 응답이 한 번 오가는 데 걸리는 시간이고, 대역폭은 한 번에 밀어 넣을 수 있는 데이터의 양입니다. 썸네일 30장이 걸린 피드가 느린 이유는 파일이 커서가 아니라 왕복이 30번 일어나기 때문이며, 캐시와 CDN은 바로 이 왕복을 줄이려고 존재합니다.

캐시가 가득 차면 무엇을 지우나요?

가장 오래 아무도 찾지 않은 항목부터 지우는 LRU 방식이 일반적인 답으로 소개됩니다. 함께 나오는 질문이 캐시 스탬피드인데, 한 요청만 값을 다시 채우게 하고 나머지는 기다리게 하는 식의 방어책을 함께 말할 수 있어야 합니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식