[Chapter 12] Q&A

[zziri]

[Chapter 12] 채팅 시스템 설계

• 궁금한 점 혹은 이야기하고 싶은 주제 코멘트로 정리
• 추가로 같이 보면 좋을 것 같은 기술 블로그, 아티클 등 공유

[zziri]

지훈

• 웹소켓의 동작
  • https://kellis.tistory.com/65
  • https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Polling-Long-Polling-Server-Sent-Event-WebSocket-%EC%9A%94%EC%95%BD-%EC%A0%95%EB%A6%AC
• p.209 "관계형 데이터베이스는 데이터 가운데 롱 테일(long tail)에 해당하는 부분을 잘 처리하지 못하는 경향이 있다"
  • 왜 일까요...
• p.215 "많은 사용자를 지원해야 하는 경우라면 똑같은 메시지를 모든 사용자의 큐에 복사하는 게 바람직하지 않을 것이다"
  • 그럼 어떻게 해야할까용...

[kihyun-yang]

기현

• 인덱스가 커지면 데이터에 대한 무작위 접근(random access)을 처리하는 비용이 늘어난다?

  • 랜덤 엑세스(I/O)?

  • 논리적, 물리적 순서가 아닌 레코드 하나를 읽기 위해 한 블록씩 접근하는 방식

  • 한 번에 하나의 블록만을 액세스 하는 싱글 블록 I/O 방식이다. (Index range scan)

  • 순차 엑세스(I/O)?

  • 논리적 또는 물리적으로 연결된 순서에 따라 차례대로 블록을 읽어들이는 방식

  • 테이블 풀 스캔(Table Full Scan)의 경우에는 한 번에 여러 개의 블록을 액세스 하는 멀티 블록 I/O 방식

  • 인덱스 비용 원리

    

  • 인덱스 키 값의 크기가 random access에 미치는 영향(https://yoon1fe.tistory.com/m/276)

  • MySQL의 B-Tree에서 자식 노드의 개수는 인덱스의 페이지 크기와 키 값의 크기에 따라 결정된다.

  • innodb_page_size 시스템 변수를 이용해 4~64KB 사이의 값을 선택할 수 있는데, 기본값은 16KB이다.

  • 인덱스 키가 16바이트이고, 자식 노드 주소가 12바이트라고 가정했을 때, 하나의 인덱스 페이지에는 16*1024/(16+12) = 585개를 저장할 수 있다.

  • 만약 인덱스 키 값이 두 배인 32바이트로 늘어났을 때는 16*1024/(32+12) = 372개 저장할 수 있다.

  • SELECT 쿼리가 레코드 500개를 읽어와야 한다면 후자의 경우에는 최소 두 번 이상 디스크에서 읽어와야 한다.

  • 또한, 인덱스 키 값의 길이가 길어진다는 것은 전체적인 인덱스의 크기가 커진다는것을 의미하는데, 인덱스를 캐싱하는 InnoDB 버퍼 풀이나 MyISAM의 키 캐시 영역은 크기가 제한적이기 때문에 인덱스의 크기가 커지면 그만큼 메모리에 캐시해 둘 수 있는 레코드 수가 줄어들게 된다.

[meloncha]

민석

• long tail에 해당하는 데이터는 무엇일까? -> 왜 잘 처리하지 못할까?
• Random Access 란?
  • https://sas-study.tistory.com/448
• "많은 사용자를 지원해야 하는 경우라면 똑같은 메시지를 모든 사용자의 큐에 복사하는 게 바람직하지 않을 것이다"
  • 11장의 쓰기 시점에 팬아웃하는 모델 느낌
  • 11장의 읽기 시점에 팬아웃하는 모델로 변경해야 할 것으로 보임
  • 사용자가 채팅방에 들어갔을 때 전체 메시지를 확인하는 요청을 보낸다? (p.192)

[travelbeeee]

현석

• 종단 간 암호화 ( 이 내용은... 영어 능력이 부족한 사람이 해석하고 이해한 정리글로 사실과 다를 수 있습니다. )
  • WhatsApp's end-to-end encryption is used when you chat with another person using WhatsApp Messenger. End-to-end encryption ensures only you and the person you're communicating with can read or listen to what is sent, and nobody in between, not even WhatsApp. This is because with end-to-end encryption, your messages are secured with a lock, and only the recipient and you have the special key needed to unlock and read them
  • 핵심 : A가 B에게 보낸 메시지에는 락이 걸려서 보안이 되고, A와 B만 락을 풀 수 있는 특별한 키를 가지고 있다.
  • WhatsApp has no ability to see the content of messages or listen to calls that are end-to-end encrypted. That’s because the encryption and decryption of messages sent and received on WhatsApp occurs entirely on your device
  • 핵심 : 사용자 기기에서 암호화, 복호화가 이루어지므로 중간에 가로채거나 메시지를 볼 방법이 없다.
  • Public Key Types
  • Identity Key Pair : A long-term Curve25519 key pair, generatedat install time.
    • 앱 설치할 때 생기는 128비트짜리 Key
  • Signed Pre Key : A medium-term Curve25519 key pair, generated at install time, signed by the Identity Key, and rotated on a periodic timed basis.
    • 앱 설치할 때 생기는 Key로 Identity Key 를 이용해 서명되었고, 시간에 따라 주기적으로 순환하는 Key
  • One-Time Pre Key : A queue of Curve25519 key pairs for one time use, generated at install time, and replenished as needed.
  • Session Key Types
  • Root Key : A 32-byte value that is used to create Chain Keys.
  • Chain Key : A 32-byte value that is used to create Message Keys
  • Message Key : An 80-byte value that is used to encrypt message contents. 32 bytes are used for an AES-256 key, 32 bytes for a HMACSHA256 key, and 16 bytes for an IV.
  • Other Key Types
  • Linking Secret Key : A 32-byte value that is generated on a companion device and must be passed by a secure channel to the primary device, used to verify an HMAC of the linking payload received from a primary device. The transmission of this key from companion devices to the primary device is done by scanning a QR code.
  • 공개 키 암호 방식을 사용해서 앱마다 Key Pair 가 생기고, 이 Pair Key와 암호화 기법을 이용해 종단 암호 제공
  • AES256, HMAC-SHA256 암호화가 사용됨.
  • 간략설명
  • 자세한 논문(?)

[easyfordev]

이지

• 이번 챕터는 내용은 길었지만, 이해가 안되는 내용은 거의 없었습니다.
• '관계형 DB는 데이터 중 롱 테일에 해당하는 부분을 잘 처리하지 못하는 경향이 있다'가 무슨 의미일까요?
  • index가 커지면 -> 캐시에 저장할 수 있는 데이터가 적어지는거고 -> 롱테일에 해당하는 데이터를 잘 처리하지 못한다(miss가 많이 나거나, 캐싱이 안되거나 등등)
  • Long Tail이란?
    • https://ko.wikipedia.org/wiki/%EA%B8%B4_%EA%BC%AC%EB%A6%AC
    • https://rogerheederer.github.io/LongTailProblem/
  • 파레토 법칙을 그래프에 나타냈을 때 꼬리처럼 긴 부분을 형성하는 80%의 부분
    • 즉, 파레토 법칙과는 반대로, 80%의 사소한 다수가 20%의 핵심 소수보다 뛰어난 가치를 창출한다는 이론
    • 머신러닝에서는 Head data sample과 Tail data sample이 불균형하게 분포되어 발생되는 문제를 Long Tail Problem이라고 부른다고 함
    • 파레토 법칙 : 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상
    • 예) 20%의 고객이 백화점 전체 매출의 80%에 해당하는 쇼핑을 하는 현상

[janeljs]

지선

• 롱테일에 대해 궁금했는데 위에 많이들 적어주신 것 같습니다.
  • https://www.linkedin.com/pulse/why-cassandra-writes-faster-than-traditional-rdbms-vishal-kharjul
  • https://www.scylladb.com/2021/08/19/cassandra-4-0-vs-cassandra-3-11-comparing-performance/
  • https://www.datastax.com/ko/blog/improved-client-request-routing-apache-cassandratm
  • https://instagram-engineering.com/open-sourcing-a-10x-reduction-in-apache-cassandra-tail-latency-d64f86b43589
• 디스코드의 카산드라 사용
  • https://discord.com/blog/how-discord-stores-billions-of-messages
• 아마도 위챗의 메시지 동기화 큐
  • https://github.com/Tencent/phxqueue