대규모 시스템 설계 독서 후 링크드인 시스템 분석하기

대규모 시스템 설계 독서 후 링크드인 시스템 분석

대부분의 서비스 회사에서는 이미 어느 정도의 시스템이 구축되어 있다 보니 시스템 설계에 대한 관심이 크지 않았었는데, 사이드 프로젝트를 진행하며 시스템 설계에 대한 궁금증과 관심이 생기게 되었고 그 시기에 우연히 보게 된 책 제목에 흥미를 가지고 대규모 시스템 설계 기초 책을 읽게 되었습니다.

당시 링크드인을 막 시작할 무렵이다보니 문득 "링크드인 서비스는 대규모 트래픽을 감당하기 위해 시스템이 어떻게 설계되었고, 어떤 기술을 어디에 어떻게 적용하고 있을까?" 라는 궁금증을 가지고 읽게 되었습니다.

책에서는 다양한 시스템 설계 방법에 대하여 소개하고 있는데 링크드인 시스템 분석(사실 분석이라는 말은 거창하지만..)을 위해 적용해 볼 수 있는 몇 가지 주제를 다뤄보려고 합니다.

링크드인에서 제공하는 시스템 설계에 대한 글을 찾지 못 해서 대부분이 내용이 사실을 증명할 수 있는 근거가 없는 지극히 저의 주관적인 생각이 담긴 점 참고 바랍니다..😅

URL 단축기 설계

링크드인의 게시물에 첨부된 링크를 보셨다면 https://lnkd.in/aBcDeFgH 형태의 링크를 볼 수 있습니다.

Short URLs in shared postsp 글을 보면 26자(영문 기준)보다 긴 링크를 공유하면 읽기 쉽도록 자동으로 길이가 줄어든다는 URL 단축기에 대한 설명을 확인할 수 있었습니다.

URL 단축기의 동작

책에서 소개하는 URL 단축기 동작은 개략적으로 아래와 같습니다.

• 단축 URL 요청
• 원래 URL 로 301(Permanently Moved) 응답
• 원래 URL 로 방문

링크드인의 경우 제가 보기에 단축 URL 요청 시 리다이렉트로 원래 URL로 이동시키는 것이 아닌, Request Headers에 아래와 같은 값들이 담기게 되고, 헤더값을 참조하여 생성된 원래 URL 로 다시 요청을 보내는 것으로 보입니다.

authority: 도메인 정보
method: GET
path: 원래 URL의 도메인을 제외한 나머지 경로
...

.

hashValue

hashValue는 [a-z, A-Z]의 문자들로 구성된 8글자의 문자로 보입니다.

hashValue 란 단축 URL(lnkd.in/aBcDeFgH)에서 aBcDeFgH 에 해당하는 값이라고 생각하시면 될 것 같습니다.

• 글자 수: 8글자
• hashValue에 사용할 수 있는 문자 개수: 26 + 26 = 52개
• 만들 수 있는 단축 URL: 52^8 = 53,459,728,531,456개

링크드인에서 53,459,728,531,456 개 즉, 53조 4597억 2853만 1456개의 단축 URL 이 생성될 수 있습니다.

.

URL 단축기 상세 설계

책에서 소개하는 URL 단축기 시스템의 설계 방법은 대부분 사용되는 방식일 것 같고, 링크드인 또한 유사항 방식으로 설계되었을 것이라고 생각합니다.

• (1) 게시물에 긴 URL(영문기준 26자 이상)이 공유
• (2) DB에 해당 URL이 있는지 검사
• (3) DB에 있다면 해당 URL에 대한 단축 URL을 만든 적이 있는 것
  • 따라서 DB에서 해당 단축 URL을 가져와서 클라이언트에게 반환
• (4) DB에 없는 경우 해당 URL은 새로 접수된 것이므로 유일한 ID 생성
  • 이 ID는 DB의 기본 키로 사용
• (5) 62진법 변환 적용. ID를 단축 URL로 만든다.
  • URL 단축기를 구현할 때 흔히 사용되는 접근법 중 하나
• (6) ID, 단축 URL, 원래 URL로 새 DB 레코드 생성 후 단축 URL을 클라이언트에 전달

.

단축 URL 캐싱

링크드인은 대규모 시스템이므로 단축 URL을 캐시에 저장하여 성능을 향상시키고 있을 것이라고 생각합니다.

• (1) 사용자가 단축 URL 클릭
• (2) 로드밸런서가 해당 클릭으로 발생한 요청을 웹 서버에 전달
• (3) 단축 URL이 이미 캐시에 있는 경우 원래 URL을 바로 꺼내서 클라이언트에게 전달
• (4) 캐시에 해당 단축 URL이 없는 경우 DB에서 꺼내고, DB에 없다면 사용자가 잘못된 단축 URL을 입력한 경우
• (5) DB에서 꺼낸 URL을 캐시에 넣은 후 사용자에게 반환

알림 시스템 설계

링크드인도 좋아요, 팔로우, 알림, DM 등의 알림을 푸시, SMS 메시지, 이메일 서비스를 통해 제공하고 있습니다.

푸시 알림

푸시 알림은 책에 소개된 방법과 유사하게 설계되었을 것으로 생각됩니다.

IOS 푸시 알림

• 애플이 제공하는 서비스인 APNS(Apple Push Notification Service)를 활용하여 푸시 알림을 IOS 장치로 전송

Android 푸시 알림

• FCM(Firebase Cloud Messaging)를 활용하여 푸시 알림을 Android 장치로 전송

SMS 메시지

• SMS 메시지는 링크드인에서 인증코드 발송에 사용되는 것으로 보입니다.
• Twilio, Nexmo 같은 제 3사업자의 서비스 이용

이메일

• 링크드인에서 이메일로도 다양한 알림이 전송되고 있습니다.
• 상용 이메일 서비스로 유명한 Sendgrid, Mailchimp 서비스
  

알림 전송 플로우

대부분의 알림 전송 플로우는 아래와 같습니다.

• (1) API를 호출하여 알림 서버로 알림 전송
• (2) 알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터를 캐시나 DB에서 조회
• (3) 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 삽입
• (4) 작업 서버는 메시지 큐에서 알림 이벤트를 꺼냄
• (5) 작업 서버는 알림을 제3자 서비스로 전송
• (6) 제3자 서비스는 사용자 단말로 알림을 전송

뉴스 피드 시스템 설계

뉴스 피드가 링크드인의 꽃이지 않을까 생각합니다.

뉴스 피드(news feed)

뉴스 피드는 여러분의 홈 페이지 중앙에 지속적으로 업데이트되는 스토리들로, 사용자 상태 정보 업데이트, 사진, 비디오, 링크, 앱 활동, 그리고 여러분이 페이스북에서 팔로우하는 사람들, 페이지, 또는 그룹으로부터 나오는 '좋아요'등을 포함한다.

페이스북

링크드인의 뉴스 피드 시스템도 책의 설명과 유사하게 구성되어 있을 것으로 생각됩니다.

뉴스 피드 시스템은 뉴스 피드 발행(feed publishing)과 뉴스 피드 생성(news feed building) 두 가지 부분으로 나뉩니다.

두 부분의 흐름을 간략하게 살펴보겠습니다.

피드 발행 흐름

• (1) 그래프 DB에서 친구 ID 목록 가져오기
  • 그래프 DB는 친구 관계나 친구 추천을 관리하기 적합
• (2) 사용자 정보 캐시에서 친구 정보 가져오기
  • 사용자 설정에 따라 친구 가운데 일부 필터링(피드 업데이트 무시, 일부 사용자에게만 공유 설정 등..)
• (3) 친구 목록과 새 스토리의 포스팅 ID를 메시지 큐에 삽입
• (4) 팬아웃 작업 서버가 메시지 큐에서 데이터를 꺼내어 뉴스 피드 데이터를 뉴스 피드 캐시에 삽입
  • 뉴스 피드 캐시는 <포스팅ID, 사용자ID> 순서쌍을 보관하는 매핑 테이블
  • 대부분 사용자가 보려 하는 것은 최신 스토리이므로 캐시 미스가 일어날 확률은 낮음

.

피드 읽기 흐름

이미지나 비디오 같은 미디어 콘텐츠는 CDN에 저장하여 빨리 읽어갈 수 있도록 세팅되어 있을 것입니다.

• (1) 사용자가 뉴스 피드를 읽으려는 요청 전송
• (2) 로드밸런서가 요청을 웹 서버 가운데 하나로 전송
• (3) 웹 서버는 피드를 가져오기 위해 뉴스 피드 서비스 호출
• (4) 뉴스 피드 서비스는 뉴스 피드 캐시에서 포스팅 ID 목록 조회
• (5) 뉴스 피드에 표시할 사용자 이름, 사진, 포스팅 콘텐츠, 이미지 등을 사용자 캐시와 포스팅 캐시에서 가져와 완전한 뉴스 피드 생성
• (5) 생성된 뉴스 피드를 JSON 형태로 클라이언트에게 전송. 클라이언트는 해당 피드를 렌더링

채팅 시스템

링크드인에서 채팅 시스템도 제공하고 있습니다.

뉴스 피드와 마찬가지로 채팅 시스템도 책의 설명과 유사하게 구성되어 있을 것으로 생각되고, 다룰 내용이 많다보니 간략하게 1:1 채팅 메시지의 처리 흐름만 살펴보겠습니다.

1:1 채팅 메시지 처리 흐름

• (1) 사용자 A가 채팅 서버 1로 메시지 전송
• (2) 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정
• (3) 채팅 서버 1은 해당 메시지를 메시지 동기화 큐로 전송
• (4) 메시지가 키-값 저장소에 보관
• (5)
  • (a) 사용자 B가 접속중인 경우 메시지는 사용자 B가 접속 중인 채팅 서버로 전송
  • (b) 접속 중이 아닐 경우 푸시 알림 메시지를 푸시 알림 서버로 전송
• (6) 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이에는 연결되어있는 웹소켓을 이용

검색어 자동완성 시스템

링크드인에서는 검색어 결과로 모바일은 최대 8개, PC는 최대 10개의 결과를 보여주고 있는 것으로 보입니다.

다만, 자동완성이라기보다 링크드인에 등록된 회사, 회원의 이름과 매칭되는 결과를 보여주는 것(?) 같기도 합니다.

링크드인의 검색 시스템에 대한 정보는 자세히 모르겠지만 사용자 입장에서 볼 때 자동완성에 대한 기능은 제공하고 있지 않는 것으로 보였습니다.

따라서 가장 인기 있는 질의문을 골라내기 위한 트라이 자료구조나 검색어 자동완성 구현에 필요한 알고리즘들은 사용되지 않을 것으로 생각됩니다.

다만 인기 검색어를 캐시하여 질의문을 포함하는 결과를 빠른 응답으로 보여주는 정도는 구현되어 있지 않을까 생각이 됩니다.

마무리

시스템 설계에 대한 경험이 없었지만, 사이드 프로젝트를 통해 고민했던 내용들을 많이 다루고 있어서 나름 흥미롭게 읽을 수 있었습니다.

지극히 주관적인 생각으로 링크드인의 시스템을 살짝 분석해 보았는데 구체적이지 않더라도 링크드인 시스템 설계에 대한 글을 알고 계신 분이 계시거나, 읽으시면서 궁금하신 사항, 개선 사항이 보이신다면 언제든 아래 코멘트 부탁드립니다.

글을 읽어주신 모든 분께 감사드립니다. 🙇🏻‍

Reference

• 가상 면접 사례로 배우는 대규모 시스템 설계 기초
• A Brief History of Scaling LinkedIn