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)은 아래 세 가지 요구사항을 만..

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

이전에 Java Spring에서 샤딩을 처리하지 못하던 이슈를 해결한 경험이 있다. 해결 과정: https://jaehoney.tistory.com/180 그때 당시는 해당 기술이 샤딩(Sharding)인지도 몰랐다. 참고로 당시 0년차였다.. 추가로 당시는 대단한 일을 한 것처럼 느껴졌지만 지금은 샤딩을 처리하는 다양한 기술들을 알게 되었다. Naver D2, 우아한형제들 기술블로그, 카카오 뱅크 발표, 요기요 기술 블로그, ... 그래서 이전에 구현한 코드를 어떻게 개선할 수 있을 지 생각해보기 위해 포스팅을 하게 되었다. 샤딩을 처리하는 방법 DB 서버 1대로 트래픽이나 저장량이 감당이 안될 때, Local cache나 Global cache를 동원하기도 한다. 그리고 Master-slave 패턴을..

현재 고객 서비스를 위해 도메인 별로 시스템을 만들어서 MSA 환경을 구축하고 있다. 각 클라이언가 직접 마이크로 서비스를 호출하는 것에는 문제점이 있다. 클라이언트와 마이크로 서비스 간의 강한 결합 개별 마이크로 서비스에 대해 많은 통신이 필요하다. 엣지 기능을 각각의 마이크로 서비스가 직접 구현해야 한다. 보안 및 권한 처리 장애 처리 로깅, 모니터링 요청 개수 제한 캐싱 ... API Gateway 패턴을 사용하면 단일 접점을 활용해서 각각의 마이크로 서비스의 내부에 대해 알 필요가 없다. 즉, API 내부 동작에 대한 캡슐화가 이뤄지고 강한 결합이 끊어진다. 그리고 API Gateway가 공통된 기능을 제공하게 되어 각 마이크로 서비스의 책임이 가벼워진다. 단일 진입점을 제공 각 엣지 기능을 한 ..