[IT 도서 리뷰] 가상 면접 사례로 배우는 대규모 시스템 설계 기초(9장 ~ 12장)

책 정보

---

 

https://www.yes24.com/Product/Goods/102819435

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24

9장 웹 크롤러 설계

---

• 크롤러는 다양하게 이용
  • 검색 엔진 인덱싱: 웹페이지를 모아 로컬 인덱스
  • 웹 아카이빙: 나중에 사용할 목적으로 장기보관
  • 웹 마이닝: 웹 마이닝을 통해 유용한 짓기을 도출
  • 웹 모니터링: 저작권이나 상표권이 침해되는 사례를 모니터링
• 1단계 문제 이해 및 설계 범위 확정
  • 규모 확장성: 웹은 거대하므로 병행성을 활용하면 보다 효과적으로 웹 크롤링
  • 안정성: 잘못 작성된 HTML, 아무 반응이 없는 서버, 장애, 악성 코드가 붙어 있는 링크 등 이런 비정상적 입력이나 환경에 잘 대응할 수 있어야 함
  • 예절: 짧은 시간 동안 너무 많은 요청을 보내서는 안 됨
  • 확장성: 새로운 형태의 콘텐츠를 지원하기 쉬워야 함
• 2단계 개략적 설계안 제시 및 동의 구하기
  • 시작 URL 집합
    • 가능한 한 많은 링크를 탐색할 수 있도록 하는 URL을 고르는 것이 바람직
    • 일반적으로는 전체 URL 공간을 작은 부분집합으로 나누는 전략을 사용
  • 미수집 URL 저장소
    • 다운로드할 URL, 다운로드된 URL -> 2가지 상태로 나누어 관리
    • 다운로드할 URL을 저장 관리하는 컴포넌트를 미수집 URL 저장소라고 부름
    • FIFO 큐
  • HTML 다운로더
    • 인터넷에서 웹 페이지를 다운로드하는 컴포넌트
  • 도메인 이름 변환기
    • 웹 페이지를 다운받으려면 URL을 IP 주소로 변환하는 절차가 필요
  • 콘텐츠 파서
    • 파싱과 검증 절차가 필요
    • 이상한 웹 페이지는 문제를 일으킬 수 있는데다 저장 공간만 낭비하게 되기 때문
  • 중복 컨텐츠인가?
    • 29% 가량의 웹 페이지 콘텐츠는 중복
  • 콘텐츠 저장소
    • 콘텐츠 저장소는 HTML 문서를 보관하는 시스템
  • URL 추출기
    • HTML 페이지를 파싱하여 링크들을 골라내는 역할을 함
  • URL 필터
    • 특정한 콘텐츠 타입이나 파일 확장자를 갖는 URL, 접속 시 오류가 발생하는 URL, 접근 제외 목록(deny list)에 포함된 URL 등을 크롤링 대상에서 배제
  • 이미 방문한 URL?
    • 같은 URL을 여러 번 처리하는 일 방지
    • 서버 부하 줄이고 시스템이 무한 루프에 빠지는 일을 방지
    • 블룸 필터나 해시 테이블이 널리 쓰임
  • URL 저장소
    • 이미 방문한 URL을 보관
• 3단계 상세 설계
  • DFS를 쓸 것인가, BFS를 쓸 것인가
    • 웹은 Directed Graph. 페이지는 노드이고, 하이퍼링크는 에지
    • 그래프 크기가 클 경우 어느 정도로 깊숙이 가게 될지 가늠하기 어려우므로 DFS는 X -> BFS가 좋은 선택지
    • BFS는 FIFO 큐를 사용하며 2가지 문제점
      
      • 한 페이지에서 나오는 링크의 상당수는 같은 서버로 되돌아감
      • BFS 알고리즘은 URL 간에 우선순위를 두지 않음 -> 하지만 모든 웹 페이지가 같은 수준의 품질, 같은 수준의 중요성을 갖지는 않음
  • 미수집 URL 저장소
    • 이 저장소를 잘 구현하면 위 2가지 문제점을 해결 가능
    • 예의
      • 웹 크롤러는 수집 대상 서버로 짧은 시간 안에 너무 많은 요청을 보내는 것을 삼가야 함
    • 우선순위
    • 신선도
    • 미수집 URL 저장소를 위한 지속성 저장장치
      • 대부분의 URL은 디스크에 두지만 IO 비용을 줄이기 위해 메모리 버퍼에 큐를 둠
  • HTML 다운로더
    • 성능 최적화
      • 분산 크롤링: 크롤링 작업을 여러 서버에 분산
      • 도메인 이름 변환 결과 캐시
      • 지역성
      • 짧은 타임아웃
      • 안정성
      • 확장성
      • 문제 있는 콘텐츠 감지 및 회피
• 4단계 마무리
  • 서버 측 렌더링: 많은 웹사이트가 자바스크립트, AJAX 사용 -> 동적으로 생성되는 링크 발견할 수 없으므로 서버 측 렌더링 적용
  • 원치 않는 페이지 필터링: 스팸 방지 컴포넌트
  • 데이터베이스 다중화 및 샤딩: 다중화나 샤딩 같은 기법 적용
  • 수평적 규모 확장성
  • 가용성, 일관성, 안정성
  • 데이터 분석 솔루션

10장 알림 시스템 설계

---

• 1단계 문제 이해 및 설계 범위 확정
  • 어떤 종류의 알림 지원?
  • 실시간 시스템?
  • 어떤 종류의 단말 지원?
  • 사용자에게 보낼 알림은 누가 만들 수 있는가?
  • 사용자가 일림을 받지 않도록 설정할 수도 있어야 하나?
  • 하루에 몇 건의 알림?
• 2단계 개략적 설계안 제시 및 동의 구하기
  • 알림 유형별 지원 방안
    • iOS 푸시 알림
      • 알림 제공자: 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체
      • APNS: 애플이 제공하는 원격 서비스. 푸시 알림을 iOS 장치로 보내는 역할 담당
      •  iOS 단말: 푸시 알림을 수신하는 사용자 단말
    • 안드로이드 푸시 알림
      • APNS 대신 FCM(Firebase Cloud Messaging) 사용
    • SMS 메시지
      • 트윌리오, 넥스모 같은 제3 사업자의 서비스를 많이 이용
    • 이메일
      • 센드그리드, 메일침프
  • 연락처 정보 수집 절차
    • 알림을 보내려면, 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요
    • 앱 설치나 처음 계정 등록시 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장
  • 알림 전송 및 수신 절차
    • 개략적 설계안
      • 1부터 N까지의 서비스
      • 알림 시스템
      • 제3자 서비스
    • 문제점
      • SPOF: 알림 서비스에 서버가 하나밖에 없다 -> 서버 장애 = 전체 서비스 장애
      • 규모 확장성: 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리 -> 데이터베이스나 캐시 등 중요 컴포넌트의 규모를 개별적으로 늘릴 방법이 없음
      • 성능 병목: 알림을 처리하고 보내는 것은 자원을 많이 필요로 하는 작업
    • 개략적 설계안 (개선된 버전)
      • 데이터베이스와 캐시를 주 서버에서 분리
      • 알림 서버를 증설하고 수평적 규모 확장이 이루어지게 함
      • 메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊는다.
    • 전송 과정
      • API를 호출하여 알림 서버로 알림 보냄
      • 알림 서버는 메타데이터를 캐시나 데이터베이스에서 가져옴
      • 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 큐에 넣음
      • 작업 서버는 메시지 큐에서 알림 이벤트를 꺼냄
      • 작업 서버는 알림을 제3자 서비스로 보냄
      • 제3자 서비스는 사용자 단말로 알림을 전송
• 3단계 상세 설계
  • 안정성
    • 데이터 손실 방지: 알림이 사라지면 안되므로 알림 데이터를 데이터베이스에 보관라혹 재시도 메커니즘 구현
    • 알림 중복 전송 방지: 중복 탐지 메커니즘 도입
  • 추가로 필요한 컴포넌트 및 고려사항
    • 알림 템플릿: 대부분 형식이 비슷하므로 유사성을 고려하여 템플릿 만들기
    • 알림 설정: 알림 설정 조정할 수 있도록 테이블에 보관
    • 전송률 제한: 사용자가 알림 기능을 꺼버릴 수 있으므로 적당히 보낼수있게 
    • 재시도 방법: 전송에 실패하면 재시도 전용 큐에 넣음
    • 푸시 알림과 보안: appKey와 appSecret을 사용하여 보안 유지
    • 큐 모니터링: 큐에 쌓인 알림의 개수가 너무 크면 이벤트가 빠르게 처리되지 못함 -> 서버 증설
    • 이벤트 추적: 데이터 분석 서비스와 통합
  • 수정된 설계안
    • 알림 서버에 인증과 전송률 제한 기능 추가
    • 전송 실패시 대응 -> 전송에 실패한 알림은 다시 큐에 넣고 지정된 횟수만큼 재시도
    • 전송 템플릿을 사용하여 단순화 및 일관성 유지
    • 모니터링과 추적 시스템 추가
• 4단계 마무리
  • 안정성
  • 보안
  • 이벤트 추적 및 모니터링
  • 사용자 설정
  • 전송률 제한

11장 뉴스 피드 시스템 설계

---

• 1단계 문제 이해 및 설계 범위 확정
  • 앱 or 웹 지원?
  • 중요한 기능?
  • 어떤 순서로 표시
  • 최대 몇 명의 친구
  • 트래픽 규모
  • 이미지나 비디오 포함?
• 2단계 개략적 설계안 제시 및 동의 구하기
  • 피드 발행과 뉴스 피드 생성
    • 피드 발행: 사용자가 스토리를 포스팅하면 해당 데이터를 캐시와 데이터베이스에 기록. 새 포스팅은 친구의 뉴스 피드에도 전송
    • 뉴스 피드 생성: 지면 관계상 뉴스 피드는 모든 친구의 포스팅을 시간 흐름 역순으로 모아서 만든다고 가정
  • 뉴스 피드 API
    • 피드 발행 API
      • POST
        • 바디: 포스팅 내용 해당
        • Authorization 헤더: API 호출 인증
    • 피드 읽기 API
      • GET
        • Authorization 헤더: API 호출 인증
  • 피드 발행
    • 사용자: 모바일 앱이나 브라우저에서 새 포스팅을 올리는 주체
    • 로드밸런서: 트래픽을 웹 서버들로 분산
    • 웹 서버: HTTP 요청을 내부 서비스로 중계하는 역할
    • 포스팅 저장 서비스: 새 포스팅을 데이터베이스와 케시에 저장
    • 포스팅 전송 서비스: 새 포스팅을 친구의 뉴스 피드에 푸시
    • 알림 서비스: 친구들에게 새 포스팅이 올라왔음을 알리거나, 푸시 알림을 보내는 역할을 담당
  • 뉴스 피드 생성
    • 사용자: 뉴스 피드를 읽는 주체
    • 로드 밸런서: 트래픽을 웹 서버들로 분산
    • 웹 서버: 트래픽을 뉴스 피드 서비스로 보냄
    • 뉴스 피드 서비스: 캐시에서 뉴스 피드를 가져오는 서비스
    • 뉴스 피드 캐시: 뉴스 피드를 렌더링할 때 필요한 피드 ID를 보관
• 3단계 상세 설계
  • 피드 발행 흐름 상세 설계
    • 웹 서버
      • 클라이언트와 통신할 뿐 아니라 인증이나 처리율 제한 등의 기능도 수행
      • 한 사용자가 올릴 수 있는 포스팅의 수에 제한 (스팸 막고 유해한 콘텐츠 방지)
    • 포스팅 전송(팬아웃) 서비스
      • 어떤 사용자의 새 포스팅을 그 사용자와 친구 관계에 있는 모든 사용자에게 전달하는 과정
      • 하나는 쓰기 시점에 팬아웃 모델
      • 다른 하나는 읽기 시점에 팬아웃
      • 쓰기 시점 팬아웃: 새로운 포스팅을 기록하는 시점에 뉴스 피드 갱신
        • 장점: 뉴스 피드가 실시간 갱신, 뉴스 피드를 읽는 데 시간이 짧다.
        • 단점: 친구가 많다면 갱신에 많은 시간 소요 (핫키(hotkey) 문제), 서비스를 자주 이용하지 않는 사용자의 피드까지 갱신해야 하므로 컴퓨팅 자원 낭비
      • 읽기 시점에 팬아웃: 피드를 읽어야 하는 시점에 뉴스 피드를 갱신. 요청 기반 모델
        • 장점: 비활성화된 사용자, 또는 서비스에 거의 로그인하지 않는 사용자의 경우에는 유리, 핫키 문제도 생기지 않음
        • 단점: 뉴스 피드를 읽는 데 많은 시간 소요
      • 뉴스 피드를 빠르게 가져오는 것이 중요하므로 푸시 모델을 기본으로 사용하면서 친구나 팔로어가 많은 사용자는 풀 모델을 사용하여 시스템 과부화 방지
  • 피드 읽기 흐름 상세 설계
  • 캐시 구조
    • 뉴스 피드 시스템의 핵심 컴포넌트
    • 다섯 계층으로 나눔
      • 뉴스 피드: 뉴스 피드의 ID를 보관
      • 콘텐츠: 포스팅 데이터를 보관. 인기 콘텐츠는 따로 보관.
      • 소셜 그래프: 사용자 간 관계 정보를 보관.
      • 행동(action): 포스팅에 대한 사용자의 행위에 관한 정보를 보관. 포스팅에 대한'좋아요', 답글 등등이 이에 해당
      • 횟수(counter): '좋아요' 횟수, 응답 수, 팔로어 수, 팔로잉 수 등의 정보를 보관
• 4단계 마무리
  • 데이터베이스 규모 확장
    • 수직적 규모 확장 vs 수평적 규모 확장
    • SQL vs NoSQL
    • 주-부(master-slave) 다중화
    • 복제본(replica)에 대한 읽기 연산
    • 일관성 모델(consistency model)
    • 데이터베이스 샤딩(shardinig)

12장 채팅 시스템 설계

---

• 1단계 문제 이해 및 설계 범위 확정
  • 1:1 채팅 앱 or 그룹 채팅 앱
  • 모바일 앱 or 웹 앱
  • 트래픽 규모
  • 그룹 채팅 인원 제한
  • 중요 기능? 첨부 파일?
  • 메시지 길이에 제한
  • 종단 간 암호화
  • 채팅 이력 보관
• 2단계 개략적 설계안 제시 및 동의 구하기
  • 아래 기능을 제공해야 함
    • 클라이언트들로부터 메시지 수신
    • 메시지 수신자 결정 및 전달
    • 수신자가 접속 상태가 아닌 경우에는 접속할 때까지 해당 메시지 보관
  • 검증된 HTTP 프로토콜 사용
    • keep-alive 헤더 사용 -> 클라이언트와 서버 사이의 연결을 끊지 않고 계속 유지, TCP 핸드셰이크 횟수 줄일 수 있음
  • 수신 시나리오는 복잡
    • HTTP는 클라이언트가 연결을 만드는 프로토콜이며, 서버에서 클라이언트로 임의 시점에 메시지를 보내는 데는 쉽게 쓰일 수 없음
    • 따라서, 서버가 연결을 만드는 것처럼 동작할 수 있는 기법들 제안.
  • 폴링
    • 클라이언트가 주기적으로 서버에게 새 메시지가 있느냐고 물어보는 방법
    • 폴링 비용은 폴링을 자주하면 할수록 올라감
    • 답해줄 메시지가 없는 경우에는 서버 자원이 불필요하게 낭비
  • 롱 폴링
    • 새 메시지가 반환되거나 타임아웃 될 때까지 연결을 유지
    • 클라이언트는 새 메시지를 받으면 기존 연결을 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작
    • 약점
      • 메시지를 보내는 클라이언트와 수신하는 클라이언트가 같은 채팅 서버에 접속하게 되지 않을 수도 있음
      • 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 좋은 방법이 없음
      • 여전히 비효율적임. 메시지를 많이 받지 않는 클라이언트도 타임아웃이 일어날 때마다 주기적으로 서버에 다시 접속할 것
  • 웹소켓
    • 서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술
    • 웹소켓 연결은 클라이언트가 시작
    • 한번 맺어진 연결은 항구적이며 양방향
    • 처음에는 HTTP 연결이지만 특정 핸드세이크 절차를 거쳐 웹소켓 연결로 업그레이드 -> 서버는 클라이언트에게 비동기적으로 메세지 전송
    • 웹소켓을 이용하면 메시지를 보낼 때나 받을 때 동일한 프로토콜을 사용할 수 있으므로 설계뿐 아니라 구현도 단순하고 직관적
    • 유의할 것은 웹소켓 연결은 항구적으로 유지되어야 하기 때문에 서버 측에서 연결 관리를 효율적으로 해야 함
  • 개략적 설계안
    • 무상태 서비스
      • 로그인, 회원가입, 사용자 프로파일 표시 등을 처리하는 전통적인 요청/응답 서비스
      • 로드밸런서 뒤에 위치 -> 로드밸런서가 요청을 그 경로에 맞는 서비스로 정확하게 전달
    • 상태 유지 서비스
      • 채팅 서비스
      • 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문
    • 제3자 서비스 연동
      • 푸시 알림
      • 새 메시지를 받았다면 설사 앱이 실행 중이지 않더라도 알림을 받아야 함 -> 푸시 알림 서비스와의 통합은 아주 중요함
    • 규모 확장성
      • 서버 한 대로 처리하면 안됨 -> SPOF(Sin-gle-Point-Of-Failure)
    • 설계
      • 채팅 서버는 클라이언트 사이에 메시지를 중계하는 역할을 담당한다.
      • 접속상태 서버는 사용자의 접속 여부를 관리한다.
      • API 서버는 로그인, 회원가입, 프로파일 변경 등 그 외 나머지 전부를 처리한다.
      • 알림 서버는 푸시 알림을 보낸다.
      • 키-값 저장소에는 채팅 이력을 보관한다. 시스템에 접속한 사용자는 이전 채팅 이력을 전부 보게 될 것이다.
    • 저장소
      • 어떤 데이터베이스를 쓰느냐? (SQL vs NoSQL)
      • 데이터의 유형과 읽기/쓰기 연산의 패턴을 중요하게 따져야 함.
      • 채팅 시스템이 다루는 데이터는 보통 2가지
        • 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터 -> 안정성을 보장하는 관계형 데이터베이스에 보관, 다중화와 샤딩은 이런 데이터의 가용성과 규모확장성을 보증
        • 채팅 시스템에 고유한 데이터(채팅 이력)
          • 키-값 저장소를 추천
            • 수평적 규모확장이 쉬움
            • 데이터 접근지연시간이 낮음
            • 관계형 데이터베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향. 인덱스가 커지면 데이터에 대한 무작위적 접근을 처리하는 비용 증가
            • 이미 많은 안정적인 채팅 시스템이 키-값 저장소를 채택(페이스북 메신저는 HBase, 디스코드는 카산드라)
    • 데이터 모델
      • 1:1채팅을 위한 메시지 테이블
        • 기본 키는 message_id
      • 그룹 채팅을 위한 메시지 테이블
        • (channel_id, message_id)의 복합키(composite key)를 기본 키로 사용
    • 메시지 ID
      • 2가지 속성
        • message_id의 값은 고유해야 한다.
        • ID 값은 정렬 가능해야 하며 시간 순서와 일치해야 한다. 즉, 새로운 ID는 이전 ID보다 큰 값이어야 한다.
      • 지역적 순서 번호 생성기 이용
        • ID의 유일성은 같은 그룹 안에서만 보증하면 충분
        • 메시지 사이의 순서는 같은 채널, 혹은 같은 1:1 채팅 세션 안에서만 유지되면 충분
• 3단계 상세 설계
  • 서비스 탐색
    • 서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
    • 사용되는 기준으로는 클라이언트의 위치, 서버의 용량 등
    • 가장 널리 쓰이는 오픈 소스 솔루션으로는 아파치 주키퍼
    • 동작 방식
      • 사용자 A가 시스템에 로그인을 시도
      • 로드밸런서가 로그인 요청을 API 서버들 가운데 하나로 보낸다.
      • API 서버가 사용자 인증을 처리하고 나면 서비스 탐색 기능이 동작하여 해당 사용자를 서비스할 최적의 채팅 서버를 찾는다. 이 예제의 경우에는 채팅 서버 2가 선택되어 사용자 A에게 반환되었다고 하겠다.
      • 사용자 A는 채팅 서버 2와 웹소켓 연결을 맺는다.
  • 메시지 흐름
    • 1:1채팅 메시지 처리 흐름
      • 사용자 A가 채팅 서버 1로 메시지 전송
      • 채팅 서버 1은 ID 생성기를 사용해 해당 메시지의 ID 결정
      • 채팅 서버 2은 해당 메시지를 메시지 동기화 큐로 전송
      • 메시지가 키-값 저장소에 보관됨
        • (a) 사용자 B가 접속 중인 경우 메시지는 사용자 B가 접속 중인 채팅 서버로 전송됨
        • (b) 사용자 B가 접속 중이 아니라면 푸시 알림 메시지를 푸시 알림 서버로 보냄
      • 채팅 서버 2는 메시지를 사용자 B에게 전송. 사용자 B와 채팅 서버 2 사이에는 웹소켓 연결이 있는 상태이므로 그것을 이용
    • 여러 단말 사이의 동기화
      • 새 메시지로 간주하는 2가지 조건
        • 수신자 ID가 현재 로그인한 사용자 ID와 같다.
        • 키-값 저장소에 보관된 메시지로서, 그 ID가 cur_max_message_id보다 크다.
    • 소규모 그룹 채팅에서의 메시지 흐름
      • 각 큐를 사용자 각각에 할당된 메시지 수신함 같은 것으로 생각 
      • 새로운 메시지가 왔는지 확인하려면 자기 큐만 보면 되므로 메시지 동기화가 단순
      • 그룹이 크지 않으면 메시지를 수신자별로 복사해서 큐에 넣는 작업의 비용이 문제가 되지 않음
      • 위챗이 이런 접근법을 쓰고, 그룹의  크기는 500명으로 제한
  • 접속상태 표시
    • 사용자 로그인
      • 클라이언트와 실시간 서비스 사이에 웹소켓 연결이 맺어지고 나면 접속상태 서버는 A의 상태와 last_active_at 타임스탬프 값을 키-값 저장소에 보관. -> 접속 중으로 표시
    • 로그아웃
      • 키-값 저장소에 보관된 사용자 상태가 online에서 offline으로 바뀌게 됨
    • 접속 장애
      • 간단한 방법: 사용자를 오프라인 상태로 표시하고 연결이 복구되면 온라인 상태로 변경
        • 문제점: 짧은 시간 동안 인터넷 연결이 끊어졌다 복구되는 일은 흔함
      • 박동(heartbeat) 검사를 통해 해결
        • 온라인 상태의 클라이언트로 하여금 주기적으로 박동 이벤트를 접속상태 서버로 보내도록 함
        • 마지막 미벤트를 받은 지 x초 이내에 또 다른 박동 이벤트 메시지를 받으면 온라인으로 유지. 그렇지 않다면 오프라인으로 바꿈
    • 상태 정보의 전송
      • 사용자 A와 친구 관계에 있는 사용자들은 어떻게 해당 사용자의 상태 변화를 알게 될까?
      • 발행-구독 모델(publish-subscribe model)을 사용
        • 각각의 친구관계마다 채널을 하나씩 두는 것
        • 그룹 크기가 작다면 괜찮음
      • 그룹 크기가 크다면?
        • 사용자가 그룹 채팅에 입장하는 순간에만 상태 정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶으면 수동으로(manual) 하도록 유도
• 4단계 마무리
  • 채팅 앱을 확장하여 사진이나 비디오 등의 미디어를 지원하도록 하는 방법
  • 종단 간 암호화
    • 왓츠앱은 메시지 전송에 있어 종단 간 암호화를 지원
  • 캐시: 클라이언트에 이미 읽은 메시지를 캐시해 두면 서버와 주고받는 데이터 양을 줄일 수 있음
  • 로딩 속도 개선: 슬랙은 사용자의 데이터, 채널 등을 지역적으로 분산하는 네트워크를 구축하여 앱 로딩 속도를 개선
  • 오류 처리
    • 채팅 서버 오류: 서버 하나가 죽으면 서비스 탐색 기능이 동작하여 새로운 서버를 배정하고 다시 접속할 수 있도록 해야함
    • 메시지 재전송: 재시도나 큐는 메시지의 안정적 전송을 보장하기 위해 흔히 사용되는 기법