-

14장 유튜브 설계 유튜브는 엄청난 규모의 전 지구적 서비스 문제 이해 및 설계 범위 확정 다음의 기능을 포함한다. 댓글 남기기 비디오 공유 좋아요 누르기 재생목록에 저장 구독 일간 능동 사용자가 5백만이고, 10%의 사용자가 하루에 1비디오 업로드 한다고 가정하자. 비디오의 평균 크기가 300MB라면, 매일 요구되는 저장 용량 150TB이다. 개력적 설계안 제시 및 동의 구하기 CDN을 새롭게 구축할 필요는 없다. (기존 클라우드 서비스 활용) 시스템 설계 면접은 모든 것을 밑바닥부터 만드는 것과는 관계가 없다. ** 저장소를 사용한다, 라고 언급만 해도 충분하다. 규모 확장이 쉬운 CDN을 만드는 것은 지극히 복잡하고, 많은 비용이 드는 일이다. 비디오 업로드 절차 사용자 : 유튜브를 시청하는 이용자..

13장 검색어 자동완성 시스템 설계 범위 확정 필요한 검색어 자동완성 시스템 단어를 검색할 때 검색어의 첫 부분이 자동 완성된다. 검색 시 5개의 자동 완성 검색어가 표시된다. 인기 순위를 기준으로 5개, 맙춤법 검사나 자동 수정은 지원하지 않는다. 영어만을 사용하고, 모든 질의는 영어 소문자로 한다. DAU는 천만명이다. 요구사항 빠른 응답 속도: 시스템 응답속도 100밀리초 이내 연관성: 사용자가 입력한 단어와 연관된 것이 출력되어야 한다, 개략적 규모 추정 평균 1사람당 매일 10건 검색한다고 가정하고, 20바이트의 데이터를 입력한다고 가정한다. 검색어가 평균적으로 4개의 단어로 이루어진다고 가정하고, 각 단어는 5글자로 구성된다고 했을 때, 20바이트의 데이터를 입력한다고 한다. 검색창에 글자를 ..

12장 채팅 시스템 설계 요구 사항 확인 응답 지연이 낮은 1:1, 그룹 채팅 모두 가능한 앱 모바일 & 웹 모두 지원 ⇒ 하나의 계정으로 여러 단말에 동시 접속 지원 5천만 DAU 100명까지 가능한 그룹 채팅 텍스트만 가능, 사요자 접속상태 표시 지원 10,000자 이하 암호화는 필요 없다. 채팅 이력을 영원히 보관해야한다. 개략적 설계안 메시지 발신 시 HTTP 프로토콜을 사용하여 채팅 서비스에 메시지를 보낸다. keep-alive 헤더로 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지할 수 있다. ⇒ TCP 접속 과정의 핸드세이크 횟수를 줄일 수 있다. 메시지 수신 시 HTTP는 클라이언트가 연결을 만들기 때문에, 서버에서 클라이언트로 메시지를 보내는 데이는 쉽게 쓰일 수 없다. 폴링 클라이..

11장 뉴스 피드 시스템 설계 요구사항 앱, 웹 모두 지원해야한다. 뉴스 피드에 새로운 스토리를 올리고 친구들의 스토리를 볼 수 있도록 한다. 단순히 시간 흐름 역순으로 피드에 표시된다. 한 사람당 최대 5000명의 친구를 가질 수 있다. 매일 천만명이 방문한다. 피드에는 이미지, 비디오 등도 포함될 수 있다. 개략적 설계안 제시 뉴스 피드 시스템에는 크게 2가지 기능이 있다. 피드 발행 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록한다. 뉴스 피드 생성 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다. Rest API방식으로 API를 설계한다고 하면, 피드 발행 API는 POST /v1/me/feed 피드 읽기 API는 GET /v1/me/feed로 구현한다. 요청하는 유..

9장 웹 크롤러 설계 크롤러는 검색 엔진에서 널리 쓰이는 기술로, 몇 개의 웹 페이지에서 시작하여 그 링크를 계속 따라 나가면서 새로운 콘텐츠를 수집한다. 크롤러 활용 예시 검색 엔진 인덱싱 (Search Engine Indexing) : 크롤러는 웹 페이지를 모아 검색엔진을 위한 로컬 인덱스를 만든다. googlebot 웹 아카이빙 : 정보를 장기보관하기 위해서 정보를 모은다. 보통 국립 도서관에서 아카이빙한다. 웹 마이닝 : 인터넷에서 유용한 지식을 도출해내기 위해 웹 모니터링 : 저작권이나 상표권이 침해되는 사례를 모니터링 1단계 문제 이해 및 설계 범위 확정 규모 확장성 웹에는 수십억개의 페이지가 존재한다. 병행성을 활용하여 효과적으로 웹크롤링 해야한다. 안전 웹은 함정으로 가득하다. 잘못 작성된..

8장 URL 단축기 설계 URL 단축기 요구사항 매일 1억개의 단축 URL을 만들어낸다. 단축 URL의 길이는 짧으면 짧을 수록 좋다. 단축 URL에는 숫자(0-9), 영문자만 사용가능하다 만든 URL 정보를 삭제하거나 갱신할 수 없다. 높은 가용성과 규모 확장성, 장애 감내가 요구된다. 개략적 추정 매일 1억개라고 치면 1초당 1160개의 연산을 한다. 읽기 연산과 쓰기 연산의 비율이 10:1의 비율이라고 할 때 초당 11,600회 발생한다. 10년간 운영한다고 가정하면 1억 * 365 * 10 = 3650억개의 레코드를 보관해야하고, url 평균 길이가 100이라면 3650억 * 100 = 36.5tb를 저장해야한다. HTTP Redirect code 301 permanently moved : 브라우..

7장 분산 시스템을 위한 유일 ID 생성기 설계 만약 분산 시스템을 위해 여러 데이터베이스 서버를 사용한다면, 관계형 데이터베이스의 auto_increment 속성을 사용할 수 없다. 유일 ID 생생기 요구사항 - ID 유일한 숫자값 - 계속 커지는 값이어야 한다. - 초당 10000개의 ID를 만들 수 있어야 합니다. 유일 ID 생성기를 만드는 방법 다중 마스터 복제 데이터베이스의 auto increment 기능을 활용하지만, 1만큼 증가시키는 것이 아니라 k만큼 증가시킨다. 데이터베이스가 총 2대일 때, 데이터베이스1에서는 아이디를 1, 3, 5로 정하고 데이터베이스 2에서는 2, 4, 6과 같이 아이디를 정하는 방법이다. 이 경우 ID 유일성은 보장되겠지만, 시간 흐름에 맞추어 커지도록 보장할 수 ..

6장 키-값 저장소 설계 키-값 저장소란 비 관계형 데이터베이스를 말한다. 값은 키를 통해서 접근할 수 있고, 예를 들어 레디스, 아마존 다이나모가 있다. 단일 서버 키-값 저장소 1. 메모리에 해시 테이블로 저장하기 가장 직관적인 방법으로, 키-값 쌍을 모두 메모리에 해시 테이블로 저장하는 방법이다. 빠른 속도를 보장하지만, 모든 데이터를 메모리 안에 두는 것이 가능할까? ㄴ 데이터 압축, 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장하는 개선 방법 ㄴ 그래도 한 대 서버로 부족한 때가 온다. 2. 분산 키-값 저장소 (분산 해시 테이블) ㄴ 대규모 데이터를 저장하기 위해서 안정 해시를 사용해 서버들에 부하 분산 CAP 정리 - 데이터 일관성(Consistency): 분산 시스템에 접속하는..

안정 해시 설계 해시 키 재배치 문제 서버가 추가되거나 기존 서버가 삭제되면 해시값 인덱스가 달라져서 재배치 해야한다. 대부분의 키가 재분배 되면 대규모 캐시 미스가 발생할 것 이다. 안정 해시란 평균적으로 k/n개의 키만 재배치하는 해시 기술이다. 해시 링 해시 공간을 구부려 접어서 해시 링을 만들고, 서버 IP나 이름을 이 위치에 대응시킬 수 있다. 해시 키도 링 위의 어느 지점에 배치한다. 시계 방향으로 링을 탐색해서 만나는 첫 번째 서버에 대응된다. 위 사진에서의 해시 링에서 서버 10.5.5.2, 10.9.5.1, 10.1.2.3을 각각 빨강, 파랑, 초록색으로 해시 링 공간에 대응하였다. 그리면 Venus에 해당하는 해시는 링을 탐색해서 만나는 첫 번째 서버인 파란색에 대응할 것이다. Mars..

4장 처리율 제한 장치의 설계 처리율 제한 장치 (rate limiter) 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치 API 요청 횟수가 제한 장치에 정의된 임계치를 넘어서면 추가로 도달한 모든 호출은 처리가 block 된다. 예시) 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다. 장점 Dos(Denial of Service) 공격에 의한 자원 고갈을 방지할 수 있다. 비용을 절감할 수 있다. 우선순위가 높은 API에 더 많은 자원을 할당할 수 있다. 서버 과부하를 막는다. 봇에서 오는 트래픽이나 사용자의 잘못된 이용 패턴으로 유발된 트래픽을 걸러낼 수 이다. 1단계) 문제 이해 및 설계 범위 확정 문제를 이해..