Official-Dev. blog

요즘 너무 설계 내용만 포스팅해서 유튜브 설계 내용은 포스팅하지 않겠다고 생각했는데.. 유튜브 설계 내용이 생각외로 되게 재밌어서 또 포스팅하게 됬다! 이번 포스팅은 가상 면접 사례로 배우는 대규모 시스템 설계 기초에 기반한 내용이다. 개략적 설계 유튜브 시스템은 언뜻 보기에는 간단해 보일 수 있지만 실제로는 굉장히 복잡하다. 아래는 유튜브에 대한 통계 자료이다. MAU: 21억 매일 재생되는 비디오 수: 50억 5천만 명의 창작자 모바일 인터넷 트래픽 가운데 37%를 점유 2019년 기준 연간 광고 수입이 150억 달러 80개 언어로 이용 가능 기본적으로 유튜브는 단순히 비디오를 생성하고 보는 것 이외에도 댓글, 공유, 좋아요, 재생목록, 채널, 구독 등과 같은 다양한 기능을 제공한다. 해당 기능들을 ..

구글 검색 또는 아마존 웹 사이트 검색창에 단어를 입력하면 입력 중인 글자에 맞는 검색어가 자동으로 완성된다. 이런 기능은 검색어 자동완성(autocomplete)이라 부른다. 가장 많이 이용된 검색어 k개를 자동완성해서 출력하는 시스템을 설계해보자. 가정 먼저 요구사항을 분명히 해야 한다. 요구사항은 아래와 같다. 사용자가 입력하는 단어는 자동완성될 검색어의 첫 부분으로 한정한다. 자동완성 검색어는 5개가 표시된다. 검색 기준은 인기 순으로 한다. 맞춤법 검사 기능은 제공하지 않는다. 질의는 영어로 하지만 다국어 지원을 고려한다. 대문자나 특수문자는 처리하지 않는다. DAU 기준 천만 명의 사용자를 수용할 수 있어야 한다. 100ms 이내에 질의가 완료되어야 한다. 시스템의 일부에 장애가 발생하거나 예..

SNS 분산 아키텍처에서 사용할 채팅 시스템을 설계해보자. 아래는 현재 시장에서 널리 쓰이는 채팅 시스템의 나열이다. Whatsapp Facebook messenger Wechat Line Google Hangout Discord 여기서 Whatsapp, Wechat, Facebook Messenger는 1:1 채팅에 집중하고, Slack, Discord 등은 그룹 채팅과 낮은 Latency의 음성 채팅에 집중한다. 이렇게 채팅 시스템도 제각각 요구사항이 다르다. 요구사항을 확실히 해야 한다. 가정 이번에 설계할 시스템에서는 이해 관계자와의 합의 속에 아래의 가정을 했다고 하자. 1:1 채팅, 그룹 채팅을 모두 지원한다. 모바일 앱, 웹 앱을 모두 지원한다. DAU 기준 5천만 명을 처리할 수 있어야 한..

알림 시스템 설계 이번에는 SNS 아키텍처에서 사용할 알림 시스템을 설계해보자. 하루에 백만 건 이상의 알림을 처리하는 시스템을 구축하는 게 쉬운 과제는 아니다. 먼저 아래의 가정이 필요할 수 있다. 알림의 종류 (푸시 알림 / SMS / 이메일) 실시간 처리가 필요한 지 어떤 단말을 지원할 지 하루에 몇 건의 알림을 처리해야 하는 지 가정 이번 설계에서는 아래 요구사항을 가정한다. 푸시 알림, SMS 메시지, 이메일을 모두 지원한다. 연성 실시간(Soft Real-Time)을 보장한다. 알림은 가능한 빨리 전달한다. 시스템의 부하가 크다면 약간의 지연은 무방하다. 알림을 받지 않도록 설정할 수 있다. 하루에 1천만 건의 푸시 알림, 1백만 건의 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 한다..

해당 포스팅은 가상 면접 사례로 배우는 대규모 시스템 설계 기초의 내용을 기반으로 한다. 시스템 설계 4단계 접근법으로 SNS 아키텍처를 설계하는 과정을 경험해보자! 1. 가정 설계를 하기 앞서 첫 번째로 해야할 것은 요구사항과 가정이다. SNS 서비스 아키텍처를 설계를 한다고 했을 때 속도를 최대한 늦춰서 깊게 생각하고 가정을 명확히 해야 한다. 이는 잘못된 설계를 할 가능성을 방지한다. 아래의 질문들을 통해 가정을 명확히할 수 있다. 구체적으로 어떤 기능들이 필요한 지? 타임라인을 제공하는 것이 주요 기능인지? 정렬은 어떻게 되는 지? 이미지 / 비디오 파일도 올려야 하는 지 최대 팔로우 수는 몇명인지? 사용자 수는 얼마나 되는 지? 회사나 팀 규모는 어떻게 되는 지? 기술 스택은 어떻게 되는 지? ..

해당 포스팅은 NAVER ENGINEERING DAY(7월)의 아래 강연을 토대로 나름대로 정리한 글입니다. https://www.youtube.com/watch?v=Jpvh9oOyNVM&t=53s 조회용 DB로 분산 DB를 선택해서 개발한 내용과 겪게된 이슈에 대한 내용입니다. 분산 DB가 필요해진 이유 아래는 네이버 쇼핑에서 상품에 대한 정보들이다. 해당 페이지에 필요한 데이터를 얻기 위해 20개 이상의 테이블 데이터를 가져와야 한다고 한다. 카탈로그 기본 정보 판매처별 정보 리뷰 정보 속성 네이밍 정보 기존에는 Oracle을 사용해서 Join을 사용했는데 코로나 이후 트래픽 수가 급증하면서 Lock도 걸리고 Replication lag도 늘어나면서 장애 상황이 많이 생겼다. 그래서 분산 DB인 Po..

분산이 가능한 DB는 대표적으로 Dynamo, Memcached, Redis와 같은 것들이 있다. 먼저 분산 서버를 저장하기 위한 저장소의 목적을 명확히 할 필요가 있다. 대용량 데이터 저장 가능 짧은 Latency HA 확보 강한 일관성 … 단일 서버 ? 단일 서버에서는 사실 비교적 쉽다. 데이터를 메모리에 Map형태로 저장하기만 하면 된다. 다만, 메모리가 부족해지는 문제를 해결하기 위해 아래 기법을 적용할 수 있다. 데이터 압축(compression) 캐싱 (자주 쓰이지 않으면 디스크에 저장) 분산 서버 분산 서버를 설계할 떄는 CAP 이론을 이해해야 한다. CAP 이론(Consistency, Availability, Partition Tolerance theorem)은 아래 세 가지 요구사항을 만..

WebSocket(WebSocket)은 클라이언트와 서버를 연결하고 실시간으로 통신이 가능하도록 하는 통신 프로토콜이다. WebSocket은 TCP 접속에 전이중(duplex) 통신 채널을 제공한다. 쉽게 말해, Socket Connection을 유지한 채로 실시간 양방향 통신이 가능하다. 아래 서비스에서 대표적으로 웹소켓을 많이 사용한다. SNS 실시간 채팅 화상 회의 실시간 협업 툴 온라인 게임 증권, 거래소 예시를 보면 동시간 접속자 수가 많으며, 실시간 데이터가 아주 많이 오간다는 것을 알 수 있다. vs HTTP 먼저 일반적으로 사용하는 HTTP 프로토콜과의 차이를 알아보자. 1. State HTTP는 단방향 통신이다. 클라이언트가 서버로 요청을 보내면 응답을 받는 구조로 동작하며, 어떠한 상태..

해당 포스팅에서는 토스 SLASH 23에서 실시간 데이터를 처리하는 방법에 대한 강연 내용에 바탕을 둔다. https://www.youtube.com/watch?v=SF7eqlL0mjw&t=41s 토스 증권에서는 KRX(한국 거래소)에서 실시간 체결가, 호가뿐 아니라 거래 정지, 공매도, 외국인 투자 현황 등을 전달받는다. 가장 중요한 것은 요청이 많은 오전 9시에 데이터가 누락되거나 밀리지 않고 처리하는 것이다. 시세 플랫폼 시세 플랫폼은 거래소의 데이터를 가공하고, 누적한 데이터와 결합한 후 내부 서비스에 전달한다. 여기서 더 세부적인 단위로 나누면 아래와 같다. 수신부는 UDP 멀티캐스트 그룹에 접속해서 데이터를 읽어온다. 참고로 한국 거래소에서 데이터를 읽어오는 방식은 크게 두 가지가 있다. UD..

Pinpoint는 Naver에서 2015년에 오픈소스로 공개한 APM 도구이다. 분산 환경에서 JVM 언어 기반으로 작성된 서버에서 많이 사용한다. APM이란 ? APM이란 Application Performance Management / Application Performance Monitoring의 약자이다. 즉, 애플리케이션의 성능을 관리/모니터링 한다고 보면 된다. APM 도구를 사용하면 서버에서 발생하는 메트릭(CPU, Memory, Thread, Transaction, …), 이벤트, 로그, 트랜잭션 등을 모니터링할 수 있다. 이렇게 분석한 데이터는 아래의 목적을 위해 활용할 수 있다. 성능 문제를 예측하고 방지 고객 기대 성능 보장, 고객 경험 향상 응답 시간 보장 가용성 증대, 다운타임 감..