소셜 미디어 플랫폼은 현대 웹 서비스의 복잡성과 규모를 이해하는 데 최고의 학습 사례입니다. 오늘 포스팅은 X(전 트위터)를 예시로, 수억 명의 사용자를 지원하는 트윗 서비스의 설계 과정을 다뤘습니다. 기능적 요구사항 정의부터 성능을 위한 캐싱 전략까지 실제 대규모 시스템의 핵심 개념들을 초보 개발자분들의 관점에서 쉽게 설명했습니다. 읽는 동안 시스템 설계의 '왜'와 '어떻게'를 이해해 보세요!

들어가며

오늘날 디지털 시대에서 소셜 미디어 플랫폼은 소통과 정보 공유 방식을 완전히 바꾸어 놓았습니다. 현재 X(전 트위터)는 짧은 메시지인 '트윗'을 공유할 수 있는 마이크로블로깅 서비스로, 수많은 사용자가 매일 트윗을 수십억 개 생성하는 글로벌 플랫폼으로 자리 잡았습니다.

이처럼 X 같은 서비스를 설계하는 것은 확장성, 신뢰성, 사용자 경험까지 만족해야 하는 쉽지 않은 과제입니다.

오늘 포스팅에서는 X와 같은 트윗 서비스를 어떻게 설계할 수 있을지 살펴보겠습니다.

기능적 요구 사항

서비스를 본격적으로 설계하기에 앞서 기능적 요구사항을 알아보겠습니다. X가 갖추어야 할 핵심 기능을 종합적으로 정리함으로써 필요한 요구 사항을 확인하고, 충족시킬 수 있어요.

ⓐ 사용자 등록 및 인증

사용자는 사용자 이름, 이메일, 비밀번호 등 필수 정보를 입력하여 새 계정을 생성할 수 있어야 합니다.
사용자가 로그인할 때 입력하는 자격 증명은 안전하게 저장되고, 인증 절차를 정확히 처리해야 합니다.

ⓑ 트윗 생성

사용자는 최대 글자 수(280자)로 정해진 짧은 메시지를 작성할 수 있어야 합니다.
트윗에는 텍스트, 해시태그, 이미지, 동영상 같은 미디어를 첨부할 수 있습니다.

ⓒ 팔로우/언팔로우

사용자는 다른 사용자를 팔로우해서 해당 사용자의 트윗을 타임라인에서 볼 수 있어야 합니다.

ⓓ 타임라인

사용자의 트윗 생성 시간과 선호도를 반영하여 각 사용자에게 맞는 내용을 효율적으로 생성해서 타임라인에 표시해야 합니다.

ⓔ 검색

사용자는 키워드, 해시태그, 사용자 이름을 기반으로 트윗이나 다른 사용자를 검색할 수 있어야 합니다.

ⓕ 리트윗과 좋아요 기능

사용자는 다른 사용자의 트윗을 자신의 팔로워에게 공유할 수 있는 리트윗 기능을 사용할 수 있어야 합니다.

ⓖ 다이렉트 메시지

사용자는 공개 트윗 피드와는 별도로 다이렉트 메시지를 주고받을 수 있어야 합니다.

트윗 서비스 설계

트윗 서비스는 트윗 생성, 조회, 삭제를 처리하는 핵심 기능을 관리함으로써 X에서 중요한 역할을 맡고 있습니다. 이러한 트윗 서비스의 내부는 어떻게 설계되어 있을까요?

위 이미지는 트윗 서비스의 아키텍처를 나타냅니다. 로드 밸런서를 통해 API 게이트웨이를 거쳐 트윗 서비스로 요청이 전달되는 흐름입니다.

트윗 서비스는 트윗 데이터베이스 테이블, 객체 저장소, 메시지 큐와 상호 작용하여 타임라인 서비스와 검색 서비스가 정상적으로 동작할 수 있도록 뒷받침합니다.

여기서 각 서비스는 외부와 통신할 수 있도록 API 앤드포인트를 제공하는데, 트윗 서비스는 이와 같습니다. 이 정도의 API면 트윗 서비스와 통신하는 클라이언트가 요청에 따라 필요한 응답을 받을 수 있어요.

트윗 서비스의 데이터 모델과 저장소 구조

앞서 살펴본 트윗 서비스는 데이터베이스와 객체 저장소를 조합하여 트윗 데이터를 저장하는데요. 이를 살펴보면 트윗 서비스의 데이터가 어떻게 설계되는지 대략적으로 알 수 있습니다.

데이터베이스 (아파치 카산드라, 아마존 DynamoDB 등): 트윗 ID, 사용자 ID, 트윗 내용, 타임스탬프 같은 내용을 하나의 데이터에 담아 관계형 데이터베이스에 저장할 수 있습니다. 데이터가 각 노드에 고르게 분산되도록 파티션 키는 트윗 ID로 설정하며, 시간 순서대로 트윗을 효율적으로 조회하려고 클러스터링 키로 타임스탬프를 사용합니다.
객체 저장소 (아마존 S3 등) : 트윗에 첨부된 이미지나 동영상 등 미디어 파일은 객체 저장소에 개별 파일로 저장합니다. 각 파일에는 고유한 식별자를 부여하고, 데이터베이스의 트윗 정보에는 해당 미디어 파일의 고유 식별자를 참조로 포함합니다.

트윗 생성과 조회 과정

앞서 트윗 서비스를 이루는데 필요한 API와 데이터 모델을 살펴봤습니다. 이러한 요소들이 합쳐져 트윗이 생성과 조회되는 과정을 이루는데요. 과정을 보기 쉽게 정리한 표와 트윗 처리 절차를 바탕으로 자세히 알아보세요!

사용자가 애플리케이션으로 새 트윗을 만들면 서비스 내에서는 다음 절차를 따라 트윗을 처리합니다.

클라이언트는 트윗 내용(content), 사용자 ID(userid), 미디어 파일(옵셔널)을 포함하여 POST/tweets 엔드포인트로 요청을 보냅니다.

클라이언트가 보낸 요청이 트윗 서비스에 도달하면 즉시 유효성 검사를 수행합니다. 트윗 길이에 대한 검증이나 사용자 인증 같은 필수 유효성 검사를 수행합니다.

트윗에 미디어 파일이 포함되면 해당 파일을 객체 저장소에 업로드하고 고유 식별자를 만들어 가져옵니다.

이후 기본 키로 사용할 트윗 ID를 만들어 트윗 데이터(트윗 내용, 사용자 ID, 타임스탬프, 미디어 참조)와 같이 데이터베이스에 저장합니다.

새롭게 만든 트윗 객체를 클라이언트에 응답 값으로 반환합니다.

마지막으로 5에서 만든 트윗 객체의 메시지를 트윗 ID를 포함하여 아파치 카프카 같은 메시지 큐에 전달(발행)하면 타임라인 서비스나 검색 서비스가 이를 받아 메시지를 처리합니다.

이번엔 생성된 트윗을 조회하는 방법을 알아볼까요?

사용자가 특정 트윗이나 트윗 타임라인을 조회하고자 요청할 경우, 서비스는 아래와 같은 과정을 거칩니다.

클라이언트가 GET / tweets/{tweetId} 또는 GET / users/{userId}/tweets 경로로 필요한 정보를 담아 GET 요청을 보냅니다.

2. 트윗 서비스가 요청을 받아 사용자 인증과 권한을 확인합니다.

3. 트윗 서비스가 데이터베이스에 트윗 ID나 사용자 ID를 보내 이와 맞는 트윗을 찾아 달라고 요청합니다.

4. 데이터베이스가 반환한 트윗에 미디어 파일이 포함되어 있다면 객체 저장소에서 해당 파일을 가져옵니다.

5. 조회한 트윗과 미디어 파일을 합쳐 클라이언트에 응답으로 보냅니다.

X(전 트위터)와 같이 규모가 큰 사용자와 서비스를 대상으로 하는 시스템에서는 성능이 매우 예민한 주제입니다. 그만큼 성능을 어떻게 끌어올리느냐가 상당히 중요한 과제라고 할 수 있는데요. 이때 캐싱 레이어를 추가하여 성능을 높이는 것도 방법입니다.

캐싱

입력된 트윗을 더 빠르게 조회하기 위해서는 트윗 서비스에서 레디스 같은 캐싱 시스템을 활용합니다. 예를 들어 인기 급상승 트윗이나 화제가 되는 트윗처럼 자주 요청하는 데이터를 캐시에 미리 저장해 두는 거예요. 사용자가 트윗을 요청하면 서비스는 먼저 캐시를 확인해서 데이터가 있으면 바로 가져올 수 있어 편해요!

반면, 캐시에 데이터가 없다면 데이터베이스에서 트윗을 가져오고, 가져온 데이터를 캐시에 저장합니다. 이렇게 하면 다음번에 같은 요청이 들어왔을 때 훨씬 빠르게 처리할 수 있어 전체적인 성능을 끌어올릴 수 있어요.

캐싱을 활용하는 여러 가지 전략

아래는 캐싱을 활용하는 여러 가지 전략입니다. 캐시를 효율적으로 관리하기 위해서는 데이터를 잘 정리할 수 있는 전략을 사용하는 것이 중요해요.

1️⃣ 시간 기반 슬라이딩 윈도우 캐싱

최근 N시간(ex. 24시간) 이내에 게시된 트윗을 캐시에 유지합니다.
새로운 트윗이 추가되면 캐시에 저장하고, 지정된 시간을 초과한 트윗은 캐시에서 삭제합니다.
이렇게 하면 항상 최신 트윗이 캐시에 포함되도록 관리할 수 있습니다.

2️⃣ 인기도 기반 캐싱

좋아요, 리트윗, 댓글 같은 사용자 반응 데이터를 활용하여 트윗 점수를 계산합니다.
점수가 일정 기준을 넘는 트윗만 캐시에 저장합니다.
주기적으로 점수를 다시 계산하여 캐시를 업데이트합니다.

3️⃣ 하이브리드 캐싱

시간 기반과 인기도 기반을 함께 활용하는 방식입니다.
최근 몇 시간(ex. 2시간) 이내에 작성된 트윗은 인기도와 상관없이 모두 캐시에 저장합니다.
일정 시간이 지난 트윗은 인기도 기준을 충족하는 경우에만 캐시에 유지합니다.

아래처럼 캐싱과 데이터 삭제 전략을 잘 활용한다면 X와 비슷한 서비스를 만들 때, 자주 조회하거나 중요한 트윗을 캐시에 넣어 효율적으로 관리할 수 있어요. 이렇게 하면 응답 속도를 크게 개선하고, 데이터베이스에 가하는 부담도 줄일 수 있습니다.

캐시를 계층으로 나누어 효율성을 높입니다. 예를 들어 핫 캐시는 매우 자주 조회하는 트윗을, 웜 캐시는 중간 빈도로 조회하는 트윗을, 콜드 캐시는 거의 조회하지 않는 트윗을 저장하는 방식으로 설정할 수 있습니다.
시스템을 재시작할 때를 대비하여 사람들이 곧바로 자주 조회할 가능성이 높은 트윗을 미리 캐시에 채워 넣는 방법(캐시 워밍)을 사용하면 초기 성능 저하를 미리 방지할 수 있습니다.
트윗이 수정되거나 삭제될 때 남아 있는 데이터를 제대로 정리하려면 캐시 버전 관리나 캐시 생성 번호를 사용하는 방법을 활용하는 것도 좋습니다.

이러한 세부 설계를 바탕으로 트윗 서비스를 만들면 트윗의 생성, 조회, 삭제를 효율적으로 처리할 수 있습니다. 또 확장성, 성능, 데이터 무결성을 유지하면서 객체 저장소와 메시지 큐 등 다른 구성 요소와 연동하여 체계적으로 트윗을 관리할 수 있어요.

지금까지 X(전 트위터)의 트윗 서비스 설계 방법에 대해 자세히 알아보았습니다. 서비스의 규모가 큰 만큼, 요구사항과 데이터 / 캐싱 등 효율적으로 업무를 진행할 수 있는 방식을 놓치지 않고 실행하여 사용자의 불편함을 최소화하는 것이 중요합니다.

만약 초보 개발자라면 시스템 설계의 기본 요소와 대규모 서비스의 설계 방법을 먼저 익히는 것을 추천드립니다.

이 글은 길벗에서 출간된 책 <요즘 개발자를 위한 시스템 설계 수업> 에서 발췌·편집한 글입니다. 원문은 [여기]에서 볼 수 있습니다. 책에는 트위터 외에도인스타그램, 구글 독스, 넷플릭스 등의 서비스를 설계하는 방법이 누구나 이해할 수 있게끔 담겨 있습니다.