"1억 명이 사용하는 트위터를 설계해보세요." - 시스템 디자인 인터뷰 단골 질문 공략하기

Introduction

매일 수억 명의 사용자가 실시간으로 소통하는 트위터. 이 거대한 소셜 네트워크는 어떻게 초당 수천 개의 트윗을 처리하면서도 밀리초 단위의 응답 속도를 유지할 수 있을까요?

이 질문은 구글, 메타, 아마존과 같은 실리콘밸리 기업들이 시스템 설계 면접에서 가장 선호하는 문제 중 하나입니다. 단순해 보이는 이 질문 속에는 대규모 분산 시스템의 모든 도전 과제가 담겨있기 때문이죠.

"트윗 작성 버튼을 누르는 순간부터 전 세계 팔로워의 피드에 표시되기까지, 그 1초도 안 되는 여정에서 어떤 기술적 난제들이 있을까요? 실시간성, 확장성, 안정성을 모두 달성하려면 어떤 트레이드오프를 고려해야 할까요?"

이 글 [Designing Twitter – A System Design Interview Question]에서는 트위터의 핵심 아키텍처를 하나하나 뜯어보면서, 대규모 시스템 설계의 정수를 살펴볼게요. FAANG 기업들의 시스템 설계 면접을 준비하시는 분들은 물론, 실제로 대규모 시스템을 설계하고 운영하시는 분들에게도 유용한 인사이트를 제공해드리겠습니다.

"1억 명이 사용하는 트위터를 설계해보세요."

트위터나 페이스북과 같은 대규모 소셜 미디어 플랫폼의 시스템 설계는 기술 면접에서 자주 다루어지는 주제입니다. 많은 지원자가 코딩 테스트보다 시스템 설계 면접을 더 어려워하는데, 이는 제한된 시간 안에 고려해야 할 설계 요소와 트레이드오프가 많기 때문입니다.

1. 트위터를 어떻게 설계할 것인가?

시스템 설계 면접에서 이런 질문을 받았을 때는 섣불리 기술적인 세부사항을 언급하지 않는 것이 중요합니다. MongoDB, Bootstrap, MapReduce 등의 기술을 나열하기보다는, 실제 프로젝트에 임하듯이 먼저 문제를 정의하고 요구사항을 명확히 하는 것부터 시작해야 합니다.

2. 트위터 시스템 설계 요구사항

2.1 기능적 요구사항:

2.2 비기능적 요구사항:

2.3 추가 요구사항:

3. 용량 산정하기

시스템의 용량을 산정하기 위해 예상되는 일일 클릭률을 분석해보겠습니다.

3.1 트래픽 산정:

총 사용자 10억 명, 일일 활성 사용자(DAU) 2억 명을 가정하고, 각 사용자가 하루 평균 5개의 트윗을 작성한다고 가정하면 하루 10억 개의 트윗이 생성됩니다.

트윗은 이미지나 동영상과 같은 미디어를 포함할 수 있습니다. 사용자가 공유하는 트윗의 10%가 미디어 파일이라고 가정하면, 하루 1억 개의 추가 파일을 저장해야 합니다.

우리 시스템의 초당 요청 수(RPS)는 다음과 같습니다:

3.2 저장소 산정:

각 메시지가 평균 100바이트라고 가정하면, 하루에 약 100GB의 데이터베이스 저장 공간이 필요합니다.

일일 메시지의 10%(1억 개)가 미디어 파일이며, 각 파일이 평균 50KB라고 가정하면 하루에 5TB의 저장 공간이 필요합니다.

10년간 필요한 저장 공간은 19PB입니다.

3.3 대역폭 산정

시스템이 하루에 5.1TB의 인그레스(ingress)를 처리하므로, 최소 초당 60MB의 대역폭이 필요합니다.

4. 유스케이스 설계

시스템의 주요 기능:

5. 저수준 설계

트위터의 저수준 설계는 개별 컴포넌트와 기능의 세부사항을 다룹니다. 주요 측면들을 살펴보겠습니다.

5.1 데이터 저장

5.2 핵심 기능

트윗 작성:

타임라인 생성:

검색:

팔로우/언팔로우:

5.3 추가 고려사항:

캐싱(Caching):

부하 분산(Load Balancing):

데이터베이스 복제(Database Replication):

메시지 큐(Message Queue):

API 설계(API design):

6. 고수준 설계

이번에는 트위터의 고수준 설계에 대해 논의해보겠습니다.

6.1 아키텍처

서비스를 수평적으로 확장하고 서비스간 결합도를 낮추기 위해 마이크로서비스 아키텍처를 사용합니다. 각 서비스는 자체 데이터 모델을 소유하며, 시스템을 핵심 서비스들로 나눕니다.

6.2 사용자 서비스

인증과 사용자 정보와 같은 사용자 관련 문제를 처리합니다. 로그인 페이지, 회원가입 페이지, 프로필 페이지, 홈 화면이 이 서비스에서 처리됩니다.

6.3 뉴스피드(newsfeed) 서비스

사용자 뉴스피드의 생성과 발행을 처리합니다. 뉴스피드에 대해 더 자세히 살펴보도록 하죠. 뉴스피드는 구현하기 쉬워 보이지만, 이 기능을 성공적으로 만들거나 혹은 망칠 수 있는 많은 요소들이 있습니다. 문제를 두 부분으로 나누어 보겠습니다:

6.3.1 생성(generation)

사용자 A의 피드를 생성한다고 가정할 때, 다음 단계를 수행합니다:

피드 생성은 리소스를 많이 사용하는 프로세스이며, 특히 많은 사람을 팔로우하는 사용자의 경우 상당한 시간이 걸릴 수 있습니다. 성능을 개선하기 위해 피드를 미리 생성하여 캐시에 저장하고, 주기적으로 피드를 업데이트하고 새로운 트윗에 순위 알고리즘을 적용하는 메커니즘을 구현할 수 있습니다.

6.3.2 발행(publishing)

발행은 각 사용자에 맞춰 피드 데이터를 푸시하는 단계입니다. 사용자가 수백만 명의 친구나 팔로워를 가질 수 있기 때문에 이는 매우 무거운 작업이 될 수 있습니다. 이를 처리하기 위한 세 가지 접근 방식이 있습니다:

풀 모델(Pull Model) (또는 로드 시 팬아웃):

푸시 모델(Push Model) (또는 쓰기 시 팬아웃):

하이브리드 모델:

6.4 트윗 서비스

트윗 작성, 즐겨찾기 등 트윗 관련 유스케이스를 처리하는 마이크로서비스입니다.

6.5 리트윗

추가 요구사항 중 하나인 리트윗 기능을 구현하기 위해, 리트윗하는 사용자의 ID로 새 트윗을 생성하고 새 트윗의 type enum과 content 프로퍼티를 수정하여 원본 트윗과 연결할 수 있습니다.

6.6 검색 서비스

검색 관련 기능을 담당하는 마이크로서비스입니다. 검색 서비스에서는 랭킹 시스템을 통해 인기 게시물, 최신 게시물 등을 제공합니다.

6.7 미디어 서비스

이미지, 동영상, 파일 등의 미디어 업로드를 처리하는 서비스입니다.

6.8 Analytics 서비스

각종 메트릭과 analytics 유스 케이스를 위한 서비스입니다.

6.9 랭킹 알고리즘

각 사용자에게 특화된 관련성에 따라 각 트윗의 순위를 매기는 알고리즘이 필요합니다.

ex) 페이스북은 EdgeRank 알고리즘을 사용했습니다. 각 피드 항목의 순위는 다음과 같이 계산됩니다:

여기서:

현재는 알고리즘이 훨씬 더 복잡해졌습니다. 수천 개의 요소를 고려할 수 있는 머신러닝 모델을 사용하여 순위를 매기죠.

6.10 검색 서비스

때로는 전통적인 DBMS가 충분한 성능을 제공하지 못할 수 있습니다. 대량의 데이터를 빠르게 저장, 검색, 분석하고 밀리초 단위로 결과를 제공할 수 있는 솔루션이 필요합니다. Elasticsearch가 이러한 용도로 도움이 될 수 있습니다.

Elasticsearch는 모든 유형의 데이터(텍스트, 숫자, 지리공간, 구조화 및 비구조화 데이터)를 위한 분산형 무료 오픈소스 검색 및 분석 엔진입니다. Apache Lucene을 기반으로 구축되었습니다.

6.11 트렌딩 토픽은 어떻게 식별하나요?

6.12 알림 서비스

7. 데이터 모델 설계

다음은 요구사항을 반영하는 일반적인 데이터 모델입니다.

7.1 Users (사용자):

이 테이블은 ID가 자동 생성되는 고유 필드이며 사용자의 이름, 이메일, 생년월일 및 기타 정보를 포함합니다.

7.2 Tweets (트윗):

이 테이블은 트윗과 해당 속성(타입: 텍스트, 이미지, 비디오 등), 내용 등을 저장합니다. UserID도 저장됩니다.

7.3 Favorites (즐겨찾기):

이 테이블은 애플리케이션의 즐겨찾기 트윗 기능을 위해 트윗과 사용자를 매핑합니다.

7.4 Followers (팔로워):

이 테이블은 팔로워와 팔로이(팔로우 당하는 사람)를 매핑합니다. N:M 관계를 가집니다.

7.5 Feeds (피드):

이 테이블은 해당 사용자 ID와 함께 피드 속성을 저장합니다.

7.6 Feeds_Tweets (피드_트윗):

이 테이블은 트윗과 피드를 매핑합니다(N:M 관계).

7.7 트위터는 어떤 종류의 데이터베이스를 사용하나요?

8. API 설계

서비스를 위한 기본적인 API 설계:

8.1 트윗 작성:

플랫폼에 트윗을 게시할 수 있는 API입니다.

매개변수:

8.2 사용자 팔로우/언팔로우:

사용자가 다른 사용자를 팔로우하거나 언팔로우할 수 있는 API입니다.

매개변수:

8.3 뉴스피드 가져오기:

이 API는 주어진 뉴스피드 내에 표시될 모든 트윗을 반환합니다.

매개변수:

9. 트위터 시스템 설계를 위한 마이크로서비스

9.1 데이터 파티셔닝

데이터베이스를 확장하기 위해서는 데이터 파티셔닝이 필요합니다. 수평 파티셔닝(샤딩이라고도 함)이 좋은 첫 단계가 될 수 있습니다. 다음과 같은 파티션 방식을 사용할 수 있습니다.

위의 접근 방식들은 여전히 불균등한 데이터와 부하 분산을 야기할 수 있는데요, 이는 안정 해시(Consistent hashing)를 통해 해결할 수 있습니다.

9.2 함께 아는 친구(Mutual friends)

함께 아는 친구 기능을 위해 모든 사용자에 대한 소셜 그래프를 구축할 수 있습니다.

이는 매우 기본적인 알고리즘입니다. 추천 정확도를 높이기 위해서는 머신러닝을 활용하는 추천 모델을 알고리즘에 포함시켜야 합니다.

9.3 메트릭과 애널리틱스

9.4 캐싱

9.5 미디어 접근 및 저장

대부분의 저장 공간은 이미지, 동영상 또는 기타 파일과 같은 미디어 파일을 저장하는 데 사용됩니다.

9.6 콘텐츠 전송 네트워크(CDN)

10. 트위터 시스템 설계의 확장성

이제 우리가 디자인한 시스템에서 단일 장애 지점(single point of failure)을 식별하고 해결해봅시다. 이를 위해 아래와 같이 질문을 던져볼 수 있는데요.

시스템을 더 견고하게 만들기 위해 다음과 같은 조치를 취할 수 있습니다:

결론

트위터는 초당 수천 개의 트윗을 처리하므로 모든 데이터를 처리하기 위한 하나의 큰 시스템이나 테이블만으로는 충분하지 않습니다. 따라서 분산 접근 방식을 통해 처리해야 합니다.

트위터는 'scatter and gather' 전략을 사용합니다:

👥 더 나은 데브필을 만드는 데 의견을 보태주세요

Top 1% 개발자로 거듭나기 위한 처방전, DevPill 구독자 여러분 안녕하세요 :) 

저는 여러분들이 너무 궁금합니다. 

어떤 마음으로 뉴스레터를 구독해주시는지, 

어떤 환경에서 최고의 개발자가 되기 위해 고군분투하고 계신지, 

제가 드릴 수 있는 도움은 어떤 게 있을지. 

아래 설문조사에 참여해주시면 더 나은 콘텐츠를 제작할 수 있도록 힘쓰겠습니다. 설문에 참여해주시는 분들 전원 1개월 유료 멤버십 구독권을 선물드립니다. 유료 멤버십에서는 아래와 같은 혜택이 제공됩니다.

설문 참여하고 유료 멤버십 혜택받기 →