6주차 문제 - 12장 (채팅 시스템 설계) ~ 13장 (검색어 자동완성 시스템)

[hodadako]

12장 (채팅 시스템 설계)

• 관계형 데이터베이스는 키 값 저장소와 달리 이것을 잘 처리하지 못하는 경향이 있다고 합니다. 이것에 들어갈 말로 알맞은 것은?
  롱 테일 (long tail)
  
  https://velog.io/@jude0124/DatabaseRedis

• 채팅 시스템 설계에서 상태 유지가 필요한 두 서버는 무엇일까요?
  채팅 서버, 접속 상태 서버

13장 (검색어 자동완성 시스템)

• 트라이 자료 구조 최적화 기법에는 접두어 최대 길이 제한과 이것이 있습니다. 이것에 들어갈 말로 알맞은 것은?
  노드에 인기 검색어 캐시
• 한글로 된 트라이 자료 구조를 만들 때 검색어를 어떤 식으로 분리해야 효율적일까요?
  https://bab2min.tistory.com/561?category=686456 형태소 단위로 분리

[Hju95]

12장(채팅 시스템 설계)

• channel_id 의 2가지 사용법은?
  답 : 복합키로 사용, 파티션키로 사용(그룹 채팅에 적용될 모든 질의는 특정 채널을 대상으로 할 것이기 때문)

• 웹소켓 연결 과정을 설명해주세요
  클라이언트가 시작. 처음에는 HTTP연결이지만 특정 핸드셰이크 절차를 거쳐 웹소켓 연결로 업그레이드
  웹소켓 핸드셰이크 절차는 다음과 같은 단계로 이루어집니다:

클라이언트의 요청: 클라이언트는 HTTP 프로토콜을 사용하여 웹소켓 연결을 요청합니다. 이 요청은 일반적으로 HTTP 헤더에 웹소켓 연결을 위한 Upgrade 헤더를 포함합니다.

서버의 응답: 서버는 클라이언트의 요청을 받으면 HTTP 101 Switching Protocols 응답 코드를 반환하여 클라이언트의 웹소켓 연결 요청을 받아들였음을 알립니다. 이 응답은 클라이언트가 웹소켓 프로토콜로 업그레이드될 수 있다는 것을 나타냅니다.

업그레이드와 핸드셰이크: 이후, 클라이언트와 서버 간에 웹소켓 프로토콜로의 업그레이드와 핸드셰이크가 이루어집니다. 이 과정에서는 추가적인 프로토콜과 핸드셰이크 메시지를 통해 웹소켓 연결을 설정하고, 이후에는 이 연결을 통해 양방향 메시지 교환을 수행할 수 있게 됩니다.

13장(검색어 자동완성 시스템)

• 필터 계층은 몇개까지 가능한가요? 늘어날수록 어떤 영향이 있을까요?
  무한하다. 코드의 복잡성 증가(유지보수 및 관리 측면에서 문제), 데이터 처리량과 처리 시간에 영향을 줄 수 있습니다.

• 대규모 서비스의 경우, 모든 질의 결과를 로깅하면 어떤 현상이 발생하나요? 해결 방법은?
  CPU 자원과 저장공간을 소진, 데이터 샘플링 기법 : N개 요청 가운데 1개만 로깅
  추가로 이벤트 기반 로깅, 축적 로깅(특정 주기마다 데이터를 모으거나 요약하여 로깅)

[c0olcode]

12장(채팅 시스템 설계)

• 채팅 시스템 설계 중, 짧은 시간동안 인터넷 연결이 끊어졌다 복구되는 현상에 대응할 수 있는 설계를 해야한다. 사용자의 인터넷 연결이 끊어질 경우 웹소켓 같은 지속성 연결도 끊어지는데, 대응을 위해 사용자를 오프라인 상태로 변경 후 연결이 복구되면 온라인 상태로 바꾸는 방법이 있다. 하지만 짧은 터널을 반복해서 지나면서 접속 상태를 계속 변경하는 것은 바람직 하지 않다. 이러한 문제(= 접속 장애)를 해결하기 위해 사용하는 방법은?
  : heartbeat 검사

• HTTP 프로토콜은 클라이언트가 연결을 만드는 프로토콜이기 때문에, 채팅 시스템 설계 시 메시지 수신에 적합하지 않다. 이를 해결하기 위해 서버가 연결을 만드는 것처럼 동작할 수 있는 기법들이 제안되어 왔는데, 제안된 기법 세가지가 무엇인가요?
  : 폴링, 롱 폴링, 웹소켓

13장(검색어 자동완성 시스템)

• 트라이의 크기가 크다면 여러 서버에 분산하여 저장할 수 있다. 이 때 샤딩을 할 수 있는데, 어떤 검색어가 어느 저장소 서버에 저장되어 있는지에 대한 정보를 관리하는 것을 뭐라고 하나요?
  : 검색어 대응 샤드 관리자
• 트라이 데이터베이스로 사용할 수 있는 데이터베이스 저장소 종류 2가지?
  : 문서저장소: 주기적으로 트라이를 직렬화하여 데이터베이스에 저장한다.
  키-값 저장소: 해시테이블 형태로 변환하여 저장한다.

[oxix97]

12장(채팅 시스템 설계)

• 인터넷 접속 장애가 발생하는 경우를 감지하기 위해 어떤 검사를 하여 문제를 해결할 수 있나요?
  A) 박동(heartbeat) 검사 : heartbeat event를 접속상태 서버로 보내도록 하고, 마지막 이벤트를 받은 지 x초 이내에 또 다른 이벤트를 받으면 온라인을 유지한다고 판단
• 채팅 이력의 많은 데이터를 저장할 저장소로 관계형 데이터베이스보다 키-값 저장소를 사용하면 좋은 점을 알려주세요.
  A) 데이터 접근 지연시간이 낮다 (NoSQL 특징),
  관계형 데이터베이스는 데이터 가운데 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있다.

long tail

일반적으로 "long tail"이라는 용어는 큰 데이터 세트에서 소수의 항목이나 사건이 일어나는 분포의 꼬리 부분을 나타냅니다. 이 용어는 큰 데이터 집합에서 일어나는 드물고 특이한 사건을 설명할 때 사용됩니다.

1. 쿼리 최적화의 어려움: 롱 테일 데이터는 전체 데이터 중 소수의 레코드에 해당하므로 특정 쿼리에 대한 최적화가 어려울 수 있습니다. 관계형 데이터베이스는 쿼리 최적화를 통해 빠른 성능을 제공하는데, 이를 롱 테일에 적용하기 어려운 경우가 있습니다.

2. 인덱스의 한계: 대량의 다양한 값을 가진 롱 테일은 효율적인 인덱스 구성을 어렵게 만듭니다. 인덱스의 크기가 늘어날 뿐만 아니라 업데이트 및 삽입 작업이 복잡해지기 때문에 성능에 영향을 줄 수 있습니다.

13장(검색어 자동완성 시스템)

• 트라이는 문자열들을 간략하게 저장할 수 있는 자료구조입니다. 그렇다면 어떠한 연산에 초점을 맞추어 설계된 자료구조일까요?
  A) 문자열을 꺼내는 연산

• 트라이 데이터베이스는 지속성 저장소입니다. 데이터베이스로 사용할 수 있는 2가지 방법에 대해 알려주세요
  A) 1. 문서 저장소, 키-값 저장소

문서 저장소**는 검색이 중요한 데이터에 적합합니다. 예를 들어, 다음과 같은 서비스에서 문서 저장소가 사용됩니다.

• 웹 검색: 구글, 네이버, 다음 등
• 문서 관리: 구글 드라이브, 마이크로소프트 365, 오픈라이브러리 등
• 전자 상거래: 아마존, 이베이, 쿠팡 등

키-값 저장소는 데이터 삽입 및 삭제가 중요한 데이터에 적합합니다. 예를 들어, 다음과 같은 서비스에서 키-값 저장소가 사용됩니다.

• 캐시: 웹 브라우저, 웹 서버, 애플리케이션 서버 등
• 로그: 애플리케이션 로그, 시스템 로그 등
• 이벤트 처리: 실시간 이벤트 처리 시스템 등

구체적인 예를 들어 설명하면 다음과 같습니다.

문서 저장소

• 구글 검색은 웹 페이지의 콘텐츠를 문서 저장소에 저장하여 검색어에 해당하는 페이지를 빠르게 검색합니다.
• 구글 드라이브는 문서, 이미지, 동영상 등 다양한 종류의 파일을 문서 저장소에 저장하여 관리합니다.
• 아마존은 상품의 설명, 이미지, 가격 등 상품 정보를 문서 저장소에 저장하여 쇼핑몰을 운영합니다.

키-값 저장소

• 웹 브라우저는 자주 방문하는 웹사이트의 정보를 키-값 저장소에 캐시하여 웹 페이지를 더 빠르게 로드합니다.
• 웹 서버는 웹 요청의 정보를 키-값 저장소에 기록하여 로그를 관리합니다.
• 실시간 이벤트 처리 시스템은 이벤트의 발생 시점을 키-값 저장소에 기록하여 이벤트를 처리합니다.

특성	문서 저장소	키-값 저장소
데이터 구조	트리	트리
데이터 저장 방식	문서	키-값
데이터 검색 방식	트리 탐색	키 검색
데이터 삽입 방식	문서 삽입	키-값 삽입
데이터 삭제 방식	문서 삭제	키-값 삭제
데이터 업데이트 방식	문서 업데이트	키-값 업데이트
장점	데이터 구조가 유연하여 다양한 데이터를 저장할 수 있음, 데이터 검색이 빠름	데이터 삽입 및 삭제가 빠름, 데이터 검색이 간단함
단점	데이터 삽입 및 삭제가 느림, 데이터 검색이 복잡함	데이터 구조가 단순하여 다양한 데이터를 저장하기 어려움, 데이터 검색이 느릴 수 있음
적합한 사용 사례	문서 기반 데이터, 검색이 중요한 데이터	키-값 기반 데이터, 데이터 삽입 및 삭제가 중요한 데이터

[GBGreenBravo]

12장(채팅 시스템 설계)

• 채팅을 위한 NoSQL DB의 메시지 테이블 PrimaryKey(message_id)를 설계할 때, PK의 고유성과 시간순 정렬을 위해 스노플레이크(Snowflake)와 같은 전역적 64-bit 순서 번호 생성기를 이용할 수 있습니다. 이 상황에서 스노플레이크(Snowflake)보다 더 구현하기 쉬운 접근법에는 무엇이 있을까요?

  • 지역적 순서 번호 생성기(local sequence number generator) (p.210)

• 채팅 서비스에서 접속상태(상태정보) 변화를 알려주고 싶습니다. 그룹 채팅방의 규모를 100,000명까지 수용하려 합니다. 이 경우에는 어떤 방법을 채택해야 성능 문제 없이 정상적으로 사용자의 상태정보를 표시할 수 있을까요?

  • 사용자가 그룹 채팅에 입장하는 순간에만 상태정보를 읽어가게 하거나, 친구 리스트에 있는 사용자의 접속상태를 갱신하고 싶을때 수동으로 하도록 유도하는 것. (p.219)

13장(검색어 자동완성 시스템)

• 다음 문장의 빈칸에 알맞은 단어를 말씀해 주세요. 웹 어플리케이션의 경우 브라우저는 보통 ( ______ ) 요청을 보내어 자동완성된 검색어 목록을 가져옵니다. 이 방법의 장점은 요청을 보내고 받기 위해 페이지를 새로고침 할 필요가 없다는 것입니다.

  • AJAX (p.239)

• 트라이 자료구조 최적화 기법에 '접두어 최대 길이 제한'이 있는데, 반대로 접두어 최대 길이 제한을 하지 않으면 어떠한 문제점이 있을까요?

  • 사용자가 입력하는 모든 길이의 검색어를 트라이 자료구조에 저장하게 됩니다. 그러나 실제로 사용자가 검색하는 검색어가 그렇게 길지 않기 때문에, 불필요한 노드가 무한정으로 많아지게 됩니다. 예를 들어 50자리의 검색어를 입력했더라도, 이전에 검색한 1000자리의 유효노드까지 탐색해야 합니다. 즉, 사용자가 터무니없이 긴 길이의 검색어를 입력하더라도 이를 트라이 자료구조에 저장하게 된다면, 대부분의 검색이 이뤄지는 비교젹 짧은 길이의 검색어에 무한정으로 자식 노드가 늘어나, 접두어를 찾는데 매우 큰 시간복잡도 O(가장 긴 검색어의 문자열 길이)를 갖게되는 것입니다. 그러나 '접두어 최대 길이 제한'을 하게 된다면, 시간복잡도 O(제한한 접두어 최대 길이)를 갖게 되어 사실상 O(1)의 시간복잡도를 갖게되는 것입니다. (p.233) 책에서 말하는 접두어가 검색하는 검색어의 접두어를 말하는 것이 아니라, 트라이 자료구조에 저장된 가장 긴 접두어를 말하는 것입니다.

[yoonseon12]

12장(채팅 시스템 설계)

1. 클라이언트가 주기적으로 서버에게 새 메시지가 있느냐고 묻는 '폴링' 방식의 한계 때문에 나온 기법인 '롱 폴딩' 기법의 단점은?
2. HTTP 프로토콜이 메시지를 보내려는 클라이언트에게 괜찮은 프로토콜이지만 HTTP 대신 웹소켓을 더 많이 사용하는 이유는?
3. 웹소켓 연결이 방화벽이 있는 환경에서도 잘 동작하는 이유는?

13장(검색어 자동완성 시스템)

4. 트라이를 갱신하는 두 가지 방법은?

---

답변

• HTTP 서버들의 무상태로 이루어져 있기 때문에 메시지를 보내는 클라이언트와 수신하는 클라이언트가 다른 서버에 접속할 수 있다.
• 서버 입장에서는 클라이언트가 연결을 해제했는지 아닌지 알 방법이 없다.

2. 양방향 통신을 지원하기 때문에
3. 80이나 443처럼 HTTP or HTTPS 프로토콜이 사용하는 기본 포트를 사용하기 때문
4. 매주 한 번씩 갱신, 각 노드를 개별적으로 갱신