백엔드 17

[System Design Interview] 1권 후기 및 앞으로의 계획

후기 지금까지 업로드한 총 16개의 글은 [System Design Interview - An Insider’s Guide: Volume 1]의 한글 번역판인 [가상 면접 사례로 배우는 대규모 시스템 설계 기초]를 기반으로 한 글들이다. System Design Interview - An Insider’s Guide는 아키텍트에게 필요한 도메인 지식을 실제 시스템 사례를 통해 소개하고 있는 책이다. 현재 2권까지 나와있으며, 1권은 번역이 되어 있지만 2권은 아직 번역이 되지 않았다 :( 책의 저자는 Alex Xu, Sahn Lam 두 분이시며, ByteByteGo라는 시스템 디자인 교육 사이트를 운영하시면서, 뉴스레터, 유튜브, 도서 등으로 다양한 시스템 디자인 자료들을 올려주신다. 뉴스레터나 유튜브 ..

[System Design Interview] 16장 배움은 계속된다

실세계 시스템들 좋은 시스템을 설계하기 위해서는 많은 지식을 쌓아야 함 → 실세계에서 쓰이는 시스템의 구조를 공부하면서 지식을 빠르게 쌓을 수 있음 각각의 기술을 공부하고 그 기술이 어떤 문제를 푸는지 이해하는 것은, 지식의 토대를 견고하게 하고 설계 프로세스를 다듬는 아주 좋은 방법임 Facebook Timeline: Brought To You By The Power Of Denormalization: https://goo.gl/FCNrbm Scale at Facebook: https://goo.gl/NGTdCs Building Timeline: Scaling up to hold your life story: https://goo.gl/8p5wDV Erlang at Facebook (Facebook c..

[System Design Interview] 15장 구글 드라이브 설계

구글 드라이브: 파일 저장 및 동기화 서비스 파일은 다양한 디바이스에서 이용 가능해야 함 파일은 다른 사람과 손쉽게 공유할 수 있어야 함 1단계 문제 이해 및 설계 범위 확정 요구사항 파일 추가. 가장 쉬운 방법은 파일을 구글 드라이브 안으로 떨구는(drag-and-drop) 것이다 파일 다운로드 여러 단말에 파일 동기화. 한 단말에서 파일을 추가하면 다른 단말에도 자동으로 동기화되어야 한다 파일 갱신 이력 조회(revision history) 파일 공유 파일이 편집되거나 삭제되거나 새롭게 공유되었을 때 알림 표시 안정성: 데이터 손실은 발생하면 안된다 빠른 동기화 속도: 파일 동기화에 시간이 너무 많이 걸리면 사용자는 제품을 사용하지 않을 것이다 네트워크 대역폭: 모바일 데이터 플랜 등 네트워크 대역폭..

[System Design Interview] 14장 유튜브 설계

콘텐츠 창작자가 비디오를 올리고, 시청자가 재생 버튼을 누르는 이 시스템의 이면에는 엄청나게 복잡한 수많은 기술이 숨어있음 유튜브는 DAU 20억명, 매일 재생되는 비디어 50억개, 모바일 인터넷 트래픽의 37% 점유 등 엄청난 규모를 가지고 있음 1단계: 문제 이해 및 설계 범위 확정 기능 명세 빠른 비디오 업로드 원활한 비디오 재생 재생 품질 선택 가능 낮은 인프라 비용(infrastructure cost) 높은 가용성과 규모 확장성, 그리고 안정성 지원 클라이언트: 모바일 앱, 웹브라우저, 그리고 스마트 TV 개략적 규모 추정 일간 능동 사용자(DAU: Daily Active User) 수는 5백만(5 million) 한 사용자는 하루에 평균 5개의 비디오를 시청 10%의 사용자가 하루에 1 비디오..

[System Design Interview] 13장 검색어 자동완성 시스템

많이 이용된 이용된 검색어 k개를 자동완성하여 출력하는 시스템 설계 1단계 문제 이해 및 설계 범위 확정 요구사항 빠른 응답 속도: 시스템 응답속도는 100ms 이하여야 함 (페이스북 검색어 자동완성 시스템에 관한 문서에는 100ms 이내가 아니면 시스템 이용이 불편하다고 나와있음) 연관성: 사용자가 입력한 단어와 연관된 것이어야 함 정렬: 계산 결과는 인기도 등의 순위 모델(ranking model)에 의해 정렬되어야 함 규모 확장성: 시스템은 많은 트래픽을 감당할 수 있도록 확장 가능해야 함 고가용성: 시스템에 일부에 장애가 생겨도 시스템은 계속 사용 가능해야 함 개략적 규모 추정 DAU는 1000만명 평균적으로 사용자들은 매일 10건의 검색을 수행함 질의할 때마다 20바이트의 데이터를 입력함 검색창..

[System Design Interview] 12장 채팅 시스템 설계

채팅 시스템은 하나쯤 사용하지 않는 사람이 드물다. 1단계 문제 이해 및 설계 범위 확정 어떤 종류의 채팅 앱을 설계하려는지 확실히 해 두는 것이 면접에서 가장 중요함 요구사항 응답지연이 낮은 일대일 채팅 기능 최대 100명까지 참여할 수 있는 그룹 채팅 기능 사용자의 접속상태 표시 기능 다양한 단말 지원. 하나의 계정으로 여러 단말에 동시 접속 지원 푸시 알림 5000만 DAU(Daily Active User) 2단계 개략적 설계안 제시 및 동의 구하기 클라이언트와 서버의 통신 방법에 대한 기본적 지식이 있어야 함 메시지 전송 (클라이언트 → 서버): keep-alive 헤더를 사용한 HTTP 프로토콜이 꽤 괜찮음 메시지 수신 (서버 → 클라이언트): HTTP 프로토콜은 클라이언트가 연결을 만드는 프로..

[System Design Interview] 11장 뉴스 피드 시스템 설계

뉴스 피드: 사용자에게 지속적으로 업데이트되는 스토리들을 제공하는 포맷 (사용자, 친구들의 활동 등등) 뉴스 피드를 사용하는 서비스들: 페이스북, 인스타그램, 트위터 등 SNS 서비스 1단계: 문제 이해 및 설계 범위 확정 기능 명세 피드 발행: 사용자는 뉴스 피드 페이지에 새로운 스토리를 올릴 수 있음 뉴스 피드 생성: 피드 사용자의 친구들이 올리는 스토리를 볼 수 있어야 함 뉴스 피드 순서: 시간 역순 사용자가 맺을 수 있는 최대 친구 수: 5000명 미디어: 피드에 이미지나 비디오 포함 가능 지원 클라이언트: 모바일 앱, 웹브라우저 개략적 규모 추정 일간 능동 사용자(DAU: Daily Active User) 수는 천만 명 (10 million) 2단계: 개략적 설계안 제시 및 동의 구하기 피드 발..

[System Design Interview] 10장 알림 시스템 설계

알림 시스템의 종류 1. 모바일 푸시 알림 2. SMS 메시지 3. 이메일 1단계 문제 이해 및 설계 범위 확정 요구사항 모든 종류의 알림을 지원해야 함 실시간 시스템이여야 함 알림은 애플리케이션이나, 서버 스케줄링 등으로 만들 수 있음 알림 취소 기능이 있어야 함 하루에 1000만 건의 모바일 푸시 알림, 100만 건의 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 함 2단계 개략적 설계안 제시 및 동의 구하기 알림 유형별 지원 방안 필요한 컴포넌트 알림 제공자(provider): 알림 요청(notification request)를 만들어 각 단말 푸시 알림 서비스에 보냄 푸시 알림 서비스: APNs, FCM, SMS Service, Email Service 등의 푸시 서비스 단말: 알림을 받는..

[System Design Interview] 9장 웹 크롤러 설계

웹 크롤러(web crawler): 로봇(robot) 또는 스파이더(spider)라고 불림. 웹에 새로 올라오거나 갱신된 콘텐츠를 찾아내는 것이 주된 목적. 웹 페이지에서 링크를 따라 나감녀서 콘텐츠를 수집함 크롤러의 용례 1. 검색 엔진 인덱싱(search engine indexing): 검색 엔진을 위한 로컬 인덱스 생성 2. 웹 아카이빙(web archiving): 웹의 자료를 장기보관 3. 웹 마이닝(web mining): 데이터 마이닝 4. 웹 모니터링(web monitoring): 저작권이나 상표권 침해 모니터링 1단계 문제 이해 및 설계 범위 확정 웹 크롤러의 기본 알고리즘 URL 집합이 입력으로 주어지면, 해당 URL들이 가리키는 모든 웹 페이지를 다운로드한다 다운받은 웹 페이지에서 URL..

[System Design Interview] 8장 URL 단축기 설계

1단계 문제 이해 및 설계 범위 확정 시스템의 기본적 기능 URL 단축: 주어진 긴 URL을 훨씬 짧게 줄인다 URL 리다이렉션(redirection): 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구됨 개략적 추정 쓰기 연산: 1억/24/3600 = 초당 1160 읽기 연산: 비율이 10:1일 때, 초당 11,600 10년간 운영 시: 1억 x 365 * 10 = 3650억개의 레코드 저장 용량: URL의 평균 길이가 100이면 3650억 x 100바이트 = 36.5TB 2단계 개략적 설계안 제시 및 동의 구하기 API 엔드포인트 REST 스타일로 설계 URl 단축용 엔드포인트: 단축할 URL을 인자로 실어서 POST 요청 URL 디라이렉션..