2장: 주변 친구

[minkukjo]

끄적끄적

• 그다지 인상깊은 내용은 없었던 챕터
• 웹소켓 할당을 위해 안정해시를 사용하는 파트가 인상깊었던 부분
• 레디스 펍/섭 대신 얼랭을 사용해볼 수 있다는 것도 좋았음

[LOG-INFO]

끄적끄적

• 동시 접속자 천만... 역시 글로벌은 다르다...
• Redis Pub/Sub 서버로만 140대... 역시 글로벌은 다르다...
• Redis Pub/Sub GB급 메모리의 최신 Redis Server에는 수백만개의 채널(Topic) 생성 가능
  • Kafka는?
  • Kafka so far doesn't limit you on the number of topics you can create in a Kafka Cluster. However, its advised not to go beyond 2–4k partitions per broker. This is because of dependency on zookeeper for leader election. The more partitions you have, the greater is the overhead on the zookeeper.
  • With Kafka's new KRaft mode, which entirely removes ZooKeeper from Kafka's architecture, a Kafka cluster can handle millions of topics/partitions
  • KRaft mode를 사용해야 클러스터당 2백만개정도의 파티션이 한계인 듯
  • NATS는?
  • As of nats-server v0.8.0, there is no hard limit on the maximum number of subjects.
    • https://docs.nats.io/reference/faq
    • What is NATS?

    • NATS is a connective technology that powers modern distributed systems.

      대안

• 위치정보를 위해 굳이 Cassandra Cluster를 구축해야한다면 그냥 RDB를 써도 될 것 같기도 함 (쓰기 연산 부하를 감당할 수 있다면..!)
  • CDC나 배치를 이용해서 S3로 옮기고 삭제해도 될 듯
  • 그런데 위치정보 기록을 조회해야하는 로직이 추가된다면 RDB는 어렵고, 그러면 Cassandra(또는 ScyllaDB)가 최고일 듯
  • 그런데 가정하는 쓰기 연산이 334K QPS니까.... RDB는 안되겠군 ㅎㅎ...
  • Benchmark 정보
    • 
• p.49. Redis Pub/Sub의 대안으로 다른 메시지 버스 기술도 경량의 통신 채널만 제공한다면 대체 가능

  • 뭐가 있을까?

  • Apache Kafka? 는 적절하지 않을 듯 (적은 수의 partition 수)
    • 적은 수의 partition으로도 가능은 할 것 같긴 한데 효율적이지 않고 복잡해질 듯. Simple is best 이므로 패스
    • 근데 140대 Redis Pub/Sub 서버 쓰고, Sharding + Service Discovery Component 사용할거면,,,, 그냥 Kafka 여러 Cluster를 샤딩해서 쓰는 것도...?
    • 아니다 안되겠다 ㅎㅎ...
      • 
  • NATS?

[HaeUlNam]

• 이론적으로는 순수한 P2P 방식으로도 해결 가능한 문제다.
• 좀 더 실용적인 설계방안은 공용 서버를 사용하는 것. 웹소켓을 통해 양방향 통신을 하고 위치 정보를 주고 받는다.
  • Websocket vs Http: https://sendbird.com/ko/developer/tutorials/websocket-vs-http-communication-protocols
  • Websocket을 쓸 때는 LB의 알고리즘 선택도 잘 해야 할 듯. HTTP 같은 경우 round-robin 알고리즘을 기본으로 선택해서 쓰는 경우도 있지만, Websocket에서는 효율적이지 않을 듯. Scale-out 되었을 때 기존의 트래픽을 분배하지 않는 이슈 등이 존재.
  • Q. 보통 websocket을 실무에서 사용할 때 뭘 사용하나? Java Websocket? Spring websocket 아니면 다른 Lib?
• 3,4,5를 병렬로 처리하는 것보다 DB에 먼저 저장하고 4,5를 병렬로
• Redis Pub/Sub
  • 채널 비용이 아주 저렴하기 때문. 채널 하나를 유지하기 위해서는 구독자 관계를 추적하기 위해 해시 테이블과 연결 리스트가 필요한데, 아주 소량의 메모리만 사용.
  • 분산 레디스 Pub/Sub 서버 클러스터: Hash 링을 사용하여 Publish/Subscribe할 채널을 찾는다.
  • 클러스터 크기를 조정하는 일을 조심스럽게 진행해야 한다. 많은 채널이 같은 해시 링 위의 다른 여러 서버로 이동해서, 많은 재구독 요청이 발생할 것.
• 주변의 임의 사용자 요구사항에 대해서는 지오해시별 펍/섭 채널을 통해 해결할 수 있다. 근데 이런 요구사항을 추가로 고려하게 되면 핫키 이슈도 발생할 수 있을 듯.