채팅 서비스 레퍼런스 분석4. Slack Architecture

[tonykang22]

Slack Architecture

• Reference 1
• Reference 2
• Reference 3

Slack 1.0

• 100% 정확하지는 않으나, 공개된 정보들을 토대로 얻어낸 근사치와 가정이라고 한다.

기능 요구 사항

1. 채널 내에서 메시지를 보낼 수 있어야 한다.
2. 메시지는 시간 순이며 언제든 다시 조회할 수 있어야 한다.

비기능 요구 사항

1. 낮은 latency
2. 높은 신뢰성
3. 매일 400만 명의 접속자, 최대 250만 명이 동시에 접속 예상
4. 400만 명이 하루에 최소 10시간 동안 연결 상태 유지 예상

디자인

구성

1. Client
   • 웹, 모바일, 데스크탑
2. Message Server
   • Backend Server의 업데이트 내용을 수신, 워크스페이스 내의 모든 클라이언트에게 실시간 이벤트 전송
3. Backend Server
   • Slack의 주요 로직 수행
     • User, Workspace, Channel이 무엇이고 어떻게 상호작용하는지 알고 있다.
4. MySQL DB
   • 발생하는 모든 작업을 위한 스토리지 계층

동작 원리

• 모델링 : Lekan과 Princess라는 두 사용자가 작업 공간인 FinApp 내에서 메시지를 보내는 시나리오

1. Princess는 FinApp의 최신 스냅샷을 가져오기 위해 Backend를 호출하는 클라이언트를 연다.
   • 이 스냅샷은 컴퓨터의 RAM에 로컬로 저장
     • 스냅샷 에는 워크스페이스 내의 모든 채널, 그룹, 사용자, 메시지 등에 대한 정보가 포함
   • Lekan도 마찬가지
2. 스냅샷 외에도 Backend Server는 메시지 서버의 URL도 반환한다.
   • Lekan과 Princess의 클라이언트는 Message Server에 연결
   • Lekan & Princess의 클라이언트는 이 WebSocket 연결을 통해 FinApp 내의 모든 이벤트에 대한 업데이트를 수신
     • 100개 이상의 이벤트 유형이 WebSocket 연결을 통해 발생
3. Princess가 FinApp 내 채널인 #standup에 Lekan을 언급하는 메시지를 입력하고 전송한다.
   • Enter를 클릭하면 클라이언트가 /message Backend Server에 POST 요청 전송
4. Backend Server는 메시지를 MySQL 데이터베이스에 저장하고, Princess 클라이언트에게 확인 메시지를 전달한다.
   • 이후 메시지는 프린세스에게 "delivered"으로 표시
   • 실패하는 경우 Princess는 클라이언트에게 "retry" 옵션이 표기
5. Backend Server는 new_msg Princess의 메시지가 포함된 이벤트를 Message Server로 보낸다.
6. Message Server는 new_msg 이벤트를 수신하여 처리하고 FinApp의 모든 사용자에게 메시지를 팬아웃한다.
   • Lekan는 고객에게 메시지를 보낸 후에 메시지를 읽을 수 있다.

예측

• 기능 요구 사항을 충족하는 설계가 완성되었으므로 비기능적 요구 사항을 충족하는지 확인해야 한다.
  • 이를 위해 몇 가지 계산이 필요하다.

1. Message Server는 하루에 최대 500,000 개의 연결을 허용할 수 있다.
   • 500,000 개 동시 연결 가능
   • 4M을 예상하기 때문에 8 개의 메시지 서버 필요
2. 각 사람은 하루에 50 개의 메시지를 보내므로 Backend Server, Message Server 및 MySQL Server는 하루에 2억개의 메시지 요청을 받는다.
3. Workspace의 평균 크기는 8k이다.
   • 하나의 메시지가 workspace에 전송될 때, Message Server가 최소 8,000번 (각 클라이언트 마다 하나씩) 보낼 것으로 예상
4. 하나의 MySQL 서버가 20M/일 처리 가능하다고 가정할 때, 2억개의 요청을 예상하므로 10개의 인스턴스가 필요하다.

• 비기능적 요구 사항에 따른 설계 안은 아래와 같다.

Slack 2.0

• Slack이 성장하며 이슈가 발생했다.

이슈

• 증가하는 workspace 스냅샷 크기와 대형 클라이언트 메모리 공간
  • Workpace가 커지며 스냅샷 크기도 덩달아 커진다.
  • 사용자 수, 채널 수, 총 메시지 크기 등 여러 요소가 스냅샷 크기에 영향을 미친다.
  • 스냅샷 크기가 선형적이라고 가정하면,
  • 사용자 500명 : ~ 2.5 MB
  • 사용자 30,000명 : ~ 150MB
  • 사용자 200,000명 : ~ 1GB
  • 즉, 사용자 수가 20만명인 workspace의 사용자가 스냅샷을 로드하는 경우 1GB 상당의 데이터를 로컬로 가져와 저장해야한다.
  • 4GB RAM의 25%나 된다...
• Expensive Connection
  • 사용자가 Slack을 열고 닫을 때마다
  • Client → Backend → Database 경로를 거쳐 로컬 스냅샷을 업데이트해야 한다.
  • 당시 규모에서는 최소 8M이 해당 경로를 사용할 것으로 예상
  • 하루에 노트북을 한 번 이상 닫는다면, 16M이 되고,, 두 번,, 세번 닫는다면...
• Thundering Herd
  • 전세계적인 어플리케이션이 되면서,, 이런 가정도 가능하다고 한다.
  • 나이지리아 회사 30,000명의 사용자가 존재한다고 가정하자.
  • Rough한 계산으로 당시에는 스냅샷 크기가 약 150MB 였다고 한다.
  • 나이지리아는 일시적인 정적이 자주 일어난다고 한다.
  • 나이지리아의 모든 사람들의 Slack 클라이언트가 Backend에 동시에 연결을 시도하게 된다.
  • 4.5TB의 데이터를 한 번에 가져오려고 시도하게 된다.
  • 네트워크가 이를 견뎌내고 처리할 수 있을까...? 거의 DDos...

개선 방안 1. Fat + Lazy 클라이언트

• 기존
  • 클라이언트 : 부팅(재연결) 시, 전체 스냅샷을 가져와 로컬로 저장해야 했다.
• 변경
  • 클라이언트 : 부팅(재연결) 시, 부분 데이터를 로드하고, 필요한 경우에만 나머지 데이터를 요청(지연 로딩)한다.
• 즉, 클라이언트가 더 이상 모든 데이터를 로컬에 저장할 필요가 없다.
  • 필요에 따라 Backend에서 데이터를 가져와야 한다.
• 문제점
  • Thundering Herd 등에 여전히 취약하다.
  • 클라이언트 메모리 공간은 여전히 workspace 규모에 따라 증가한다.
  • Lazy loading을 사용하면 여전히 Expensive Connection 이슈가 존재한다.

개선 방안 2. Flannel

• Flannel은 edge cache service라고 한다.
  • 캐시로 지원되는 읽기 전용 쿼리 엔진이라고 한다.
  • Flannel은 초당 1M+ 의 쿼리를 처리할 수 있다고 한다.
  • Ref : https://www.youtube.com/watch?v=x1Uz3rMlOBo&t=940s

1. Flannel은 쿼리 엔진으로 요청에 응답하고 캐시로서 응답을 제공할 수 있다.
2. Flannel은 캐시로 활용된다.
   • Flannel을 통해 RAM에 데이터를 저장할 수 있다.
   • Flannel은 쓰기 기능에는 사용되지 않는다.
     • Write-around 전략을 사용한다.

잠깐 : Write-around 전략?

• Write-around는 캐싱 전략 중 하나이다.
  • 캐싱 전략은 시스템 성능 향상을 위한 중요한 기술 중 하나이다.
• Write-around 전략은 이름에서 나타나 있듯이 Write 캐싱 전략 중 하나이다.
  • Write-through
  • Write-behind(back)
  • Write-around
  • 명확하게 이해하기 위해 아래 다른 전략들도 함께 정리
• 참고 : #11
• 요약
  • 대부분의 채팅 어플리케이션은 쓰기 작업보다 읽기 작업이 더 많다.
  • 쓰기 작업을 바로 저장소에서 수행하면 Cache Poisioning을 방지할 수 있다.
  • Slack은 대개 일대다 채팅이기 때문에 이를 사용한 것으로 생각된다.

두 가지 경로

1. Client -[HTTP] - BackendServer
   • Backend의 모든 호출이 Flannel을 통해 이뤄진다.
   • 비용이 많이 드는 요청 결과는 캐시할 수 있다.
     • 불필요한 요청을 줄일 수 있다.
2. Client -[WebSocket]- MessageServer
   • Client가 local 스냅샷을 업데이트하기 위한 경로
     • Client가 업데이트할 때, Flannel에 해당 스냅샷을 업데이트 해둬서 다른 Client에게도 전달 가능

개선 방안 3. Flannel Reloaded

• 몇 가지 주요 사항을 더 추가한 내용이다.

Distributed Flannel

• 확장을 위해서는 여러 Flannel을 띄워야한다.
• 활용 방안은 다음과 같다.
  1. GeoDNS를 사용하여 Client의 지리적 위치를 기반으로 적절한 지역으로 라우팅한다.
  2. 라우팅되면 Slack은 HAProxy를 사용하여 Client의 스냅샷이 있는 Flannel 인스턴스를 찾는다.
     • 즉, Client가 라우팅된 Flannel은 관련 스냅샷이 없을 수도 있다.
  3. Client가 라우팅된 Flannel 인스턴스가 BackendServer에서 스냅샷을 가져온다.

Query Engine

• Flannel은 쿼리 엔진이기도 하다.
  • 일부 쿼리 작업이 BackendServer → Flannel로 이동했기 때문이다.
• Flannel에서 제공하는 기능
  • 빠른 전환기
  • 다른 workspace, 동료 검색
  • 멘션 제안
  • @를 통해 동료 등을 멘션할 수 있게 추천
  • 채널 헤더

Preemptive Updates

• 시나리오를 통해 이해해보자
  • 1. P가 Slack을 열고, #standup 스냅샷을 load한다.
  • 2. L도 Slack을 열고, #music 스냅샷을 load한다.
  • 3. P가 #standup에서 L을 멘션하면, P-Client는 BackendServer에 요청을 보낸다.
  • 4. BackendServer는 이 메시지를 MySQL에 저장하고, MessageServer로 보낸다.
  • 5. MessageServer 수신한 메시지를 L-Client에게 팬아웃한다.
  • 6. 팬아웃은 Flannel을 경유한다. Flannel은 L-Client가 아직 #standup을 load하지 않은 것을 알고 있기 때문에 Flannel은 #standup에 메시지 업데이트를 포함하는 페이로드를 선제적으로 업데이트한다.
  • 선제적으로 업데이트 하지 않으면, L-Client는 메시지를 수신한 뒤에 Flannel에 #standup 관련 데이터를 요청하게 된다.
  • 이와 같은 추가 호출을 방지할 수 있는 방식이다.

그 외

1. Memcache 혹은 Redis를 캐시로 사용하지 않고 Flannel을 사용한 이유는 무엇인가?
   • A1: Flannel은 쿼리 엔진의 기능도 있기 때문이다.
2. Flannel은 읽기 전용인가?
   • A2: 그렇다.
3. Workplace와 DB 샤드는 1:1 매핑되어 있는가?
   • A3: 그렇지 않다. DB 서버 샤드는 하나가 아닌 다양한 workplace를 처리한다.