정기간행물/daily 39

Observer 패턴

상태 변화를 알려준다 관찰 대상의 상태가 변화하면 관찰자에게 알린다 → 상태 변화에 따른 처리를 기술할 때 효과적 예제 프로그램 관찰 당하는 대상이 갖고 있는 숫자가 변경됐을 때, 대상을 관찰하고 있는 Observer들에게 알리는 예제 클래스 및 인터페이스 목록 이름 설명 Observer 관찰자 인터페이스 NumberGenerator 수를 생성하는 추상 클래스 RandomNumberGenerator 랜덤하게 수를 생성하는 클래스 DigitObserver 숫자로 수를 표시하는 클래스 GraphObserver 그래프로 수를 표시하는 클래스 Main 동작 테스트용 클래스 예제 프로그램의 클래스 다이어그램 Observer 인터페이스 관찰자를 나타내는 인터페이스. 구체적인 관찰자가 이 인터페이스를 구현한다. up..

구글 드라이브 설계 (대시설기)

1단계 문제 이해 및 설계 범위 확정 기능적 요구사항 파일 추가 파일 다운로드 여러 단말에 파일 동기화 파일 갱신 이력 조회 파일 공유 파일이 편집되거나 삭제되거나 새롭게 공유되었을 때 알림 표시 비기능 요구사항 안정성 빠른 동기화 속도 네트워크 대역폭 규모 확장성 높은 가용성 2단계 개략적 설계안 제시 및 동의 구하기 서버 한대에서 시작 파일을 올리고 다운로드 하는 과정을 처리할 웹 서버 사용자 데이터, 로그인 정보, 파일 정보 등의 메타데이터를 보관할 데이터베이스 파일을 저장할 저장소 시스템 API 파일 업로드 API 단순 업로드 이어 올리기 인자: uploadType=resumable, data: 업로드할 로컬 파일 이어 올리기 URL을 받기 위해 최초 요청 전송 데이터를 업로드하고 업로드 상태 모..

유튜브 설계 (대시설기)

1단계 문제 이해 및 설계 범위 확정 빠른 비디오 업로드 원활한 비디오 재생 재생 품질 선택 기능 낮은 인프라 비용 높은 가용성과 규모 확장성, 안정성 지원 클라이언트: 모바일 앱, 웹브라우저, 스마트 TV 2단계 개략적 설계안 제시 및 동의 구하기 주요 컴포넌트 3개 단말 CDN: 비디오는 CDN에 저장한다. API 서버: 비디오 스트리밍을 제외한 모든 요청 처리(피드 추천, 비디오 업로드 URL 생성, 메타데이터 데이터베이스, 캐시 갱신, 사용자 가입) 설계 영역 2가지 비디오 업로드 절차 비디오 스트리밍 절차 비디오 업로드 절차 사용자 로드밸런서 API 서버 메타데이터 데이터베이스 메타데이터 캐시: 비디오 메타데이터와 사용자 객체는 캐시한다. 원본 저장소: 원본 비디오를 보관할 대형 이진 파일 저장..

채팅 시스템 설계 (대시설기)

1단계 문제 이해 및 설계 범위 확정 응답지연이 낮은 일대일 채팅 기능 최대 100명까지 참여할 수 있는 그룹 채팅 기능 사용자의 접속상태 표시 기능 다양한 단말 지원 푸시 알림 2단계 개략적 설계안 제시 및 동의 구하기 채팅 서비스 클라이언트들로부터 메시지 수신 메시지 수신자 결정 및 전달 수신자가 접속 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관 HTTP 프로토콜을 이용해 서버가 연결을 만드는 것처럼 동작하는 기법 3가지 폴링 클라이언트가 주기적으로 서버에게 새 메시지가 있냐고 물어보는 방법 롱폴링 클라이언트는 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지, 메시지를 반환받으면 연결을 종료하고 새로운 요청을 보낸다. 단점 로드밸런싱을 사용하는 경우, 메시지를 받은 서버는 해당 메시지..

검색어 자동완성 시스템 (대시설기)

가장 많이 이용된 검색어 k개를 자동완성하여 출력하는 시스템을 설계해보자. 1단계 문제 이해 및 설계 범위 확정 입력 단어는 자동완성될 검색어의 첫 부분 5개의 자동완성 검색어 표시 인기순 맞춤법 x, 자동 수정 x 모든 질의는 영어 소문자 DAU 기준으로 천만명 요구사항 빠른 응답 속도 - 시스템 응답속도는 100ms 연관성 정렬 - 인기순 규모 확장성 - 많은 트래픽 고가용성 - 페일오버 개략적 규모 추정 DAU 천만명 한 사용자는 매일 10건의 검색 질의할 때마다 평균 20바이트 데이터 입력 검색창에 금자를 입력할 때마다 클라이언트는 검색어 자동완성 백엔드에 요청을 보낸다. 초당 24,000건의 질의(QPS)가 발생할 것 최대 QPS = QPS * 2 = 48,000 질의 가운데 20% 정도는 신규..

뉴스 피드 시스템 설계 (대시설기)

뉴스 피드는 홈 페이지 중앙에 지속적으로 업데이트되는 스토리이다. (페이스북, 인스타그램 피드 설계) 1단계 문제 이해 및 설계 범위 확정 앱, 웹 모두 지원 새로운 스토리를 올리고, 친구들이 올리는 스토리를 볼 수도 있다. 시간 흐름 역순 한 사용자는 5천명의 친구를 가질 수 있다. 매일 천만 명이 방문 (10million DAU) 이미지나 비디오 등 미디어 파일이 포함될 수 있다. 2단계 개략적 설계안 제시 및 동의 구하기 피드 발행: 스토리를 포스팅하면 해당 데이터를 캐시와 DB에 기록한다. 뉴스 피드 생성: 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다. 뉴스 피드 API 피드 발행 API 새 스토리를 포스팅하기 위한 API다. 피드 읽기 API 뉴스 피드를 가져오는 API다. 피드 발행..

알림 시스템 설계

알림 시스템 모바일 푸시 알림 SMS 메시지 이메일 1단계 문제 이해 및 설계 범위 확정 푸시 알림, SMS 메시지, 이메일 연성 실시간 시스템 (soft real-time) ios, android 단말, 랩탑, 데스크탑 지원 클라이언트 어플리케이션 또는 서버에서 스케줄링 할 수 있다. 사용자가 알림을 받지 않도록(opt-out) 설정할 수도 있다. 하루에 천만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메일 2단계 개략적 설계안 제시 및 동의 구하기 알림 유형별 지원 방안 연락처 정보 수집 절차 알림 전송 및 수신 절차 알림 유형별 지원 방안 ios 푸시 알림 알림 제공자 → APNS → IOS 단말 알림 제공자: 애플 푸시 알림 서비스(Apple Push Notification..

웹 크롤러 설계 (대시설기)

검색 엔진에서 널리 쓰는 기술로, 웹에 새로 올라오거나 갱신된 콘텐츠를 찾아내는 것이 주 목적이다. 크롤러 이용처 검색 엔진 인덱싱: 크롤러는 웹 페이지를 모아 검색 엔진을 위한 로컬 인덱스를 만든다. 웹 아카이빙: 나중에 사용할 목적으로 장기보관하기 위해 웹에서 정보를 모으는 절차를 말한다. 웹 마이닝: 유명 금융 기업들은 크롤러를 사용해 주주총회 자료나 연차 보고서를 다운받아 기업의 핵심 사업 방향을 알아낸다. 웹 모니터링: 인터넷에서 저작권이나 상표권이 침해되는 사례를 모니터링할 수 있다. 1단계 문제 이해 및 설계 범위 확정 URL 집합이 입력으로 주어지면, 해당 웹 페이지를 다운로드한다. 다운받은 웹 페이지에서 URL들을 추출한다. 추출된 URL들을 다운로드할 URL 목록에 추가하고 처음부터 반..

Chain of Responsibility

요약 : 여러 객체를 사슬처럼 연쇄적으로 묶고, 객체 사슬을 차례대로 돌면서 원하는 객체를 결정하는 방법 요청이 들어오고 요청을 처리할 수 있으면 처리하고 없으면 다음 사람에게 떠넘긴다. 클래스 목록 Trouble 트러블 클래스, 특정 번호(Number)를 갖는다. Support 트러블을 해결하는 추상 클래스 NoSupport 트러블을 해결하는 구상 클래스(항상 No!) LimitSupport 트러블을 해결하는 구상 클래스(지정한 번호 미만의 트러블만 Yes) OddSupport 트러블을 해결하는 구상 클래스(홀수 번호만 Yes) SpecialSupport 트러블을 해결하는 구상 클래스(특정 번호만 Yes) Main 동작 테스트용 클래스 예제 프로그램의 클래스 다이어그램 Chain of Responsib..

URL 단축기 설계 (대시설기)

1단계 문제 이해 및 설계 범위 확정 기본적인 기능 URL 단축: 주어진 긴 URL을 훨씬 짧게 줄인다. URL 리디렉션: 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구됨 개략적 추정 쓰기 연산: 매일 1억 개의 단축 URL 생성 초당 쓰기 연산: 1억/24/3600 = 1160 읽기 연산: 읽기 연산과 쓰기 연산 비율은 10:1이라고 하자. 초당 읽기 연산은 초다아 11,600회 발생한다. URL 단축 서비스를 10년간 운영한다고 가정하면 1억 * 365 * 10 = 3650억개의 레코드를 보관해야 한다. 축약 전 URL의 평균 길이는 100이라고 하자. 따라서 10년 동안 필요한 저장 용량은 3650억 * 100바이트 = 36.5TB이다..