NW-study / system-design-interview

8 stars 0 forks source link

[Volume 2][Chapter 02] Q&A #18

Open janeljs opened 6 months ago

janeljs commented 6 months ago

지선

p.41

p. 44

p.47, p. 62-63

p.48, p.57

레디스의 Pub/Sub 시스템은 메시지를 보관(queuing) 하지 않습니다. Publish 하는 시점에 이미 실행한 subscribe 명령으로 대기하고 있는 클라이언트들에게만 전달됩니다.

DictEntry의 key 필드가 channel을 가리킨다. 한 channel을 여러 클라이언트가 subscribe 할 수 있으므로 dictEntry의 value 필드는 리스트(linked list)를 가리킨다. 리스트는 여러 개의 listNode를 가지고 각 노드는 클라이언트를 가리킨다. PUBLISH channel message 명령은 먼저 channel을 Hash table에서 channel을 찾고, 리스트에 저장되어 있는 클라이언트들에게 하나씩 메시지를 보낸다. 그다음 패턴을 등록한 클라이언트들에게 메시지를 보낸다.

p. 60

KKambi commented 6 months ago

한비

54p. 막대한 쓰기 연산 부하 / 많은 이력 데이터에 유리한 DB

1. Cassandra


2. 왜 많은 쓰기 연산에 유리? image


3. 왜 많은 데이터 보관에 유리?


55p. (상태를 가진 웹소켓 서버에 대해) 노드를 실제로 제거하기 전에 우선 기존 연결부터 종료될 수 있도록 해야 한다. 이를 위해, 로드밸런서가 인식하는 노드 상태를 연결 종료 중으로 변경해둔다.

AWS ECS - Graceful Exit image

AWS에서도 Application Load Balancer를 사용하면, 해당 컨테이너를 draining / unused 상태로 변경한 뒤 타겟 그룹에서 제외한다. 그 후 해당 컨테이너에 필요한 시그널(TERM & KILL)을 보낸다. 만약 컨테이너에 시그널에 따른 핸들링이 설정되어 있으면 그에 따른 작업을 수행할 것!

import sun.misc.Signal;
import sun.misc.SignalHandler;

public class ExampleSignalHandler {
    public static void main(String... args) throws InterruptedException {
        final long start = System.nanoTime();
        Signal.handle(new Signal("TERM"), new SignalHandler() {
            public void handle(Signal sig) {
                System.out.format("\nProgram execution took %f seconds\n", (System.nanoTime() - start) / 1e9f);
                System.exit(0);
            }
        });
        int counter = 0;
        while(true) {
            System.out.println(counter++);
            Thread.sleep(500);
        }
    }
}

k8s - Graceful Exit

우리 팀 코드에도 SIGNAL을 핸들링하는 코드가 있는데... n2c에서 이를 사용할 때 주의할 점은 무엇일까?


1. 알고 갈 것 - k8s Container Lifecycle Hook 팟의 종료와 관련해서 PreStop이라는 라이프사이클 훅이 존재한다.

파드의 종료 문서 참고하면 더 자세한 프로세스 나옴!!


2. n2c yobi 4719번 포스트


3. n2c yobi 11910번 포스트 n2c 에서는 cpu/memory 사용량이 매우 높은 노드의 부하를 낮추기 위해 부하 높은 노드의 pod 을 다른 노드로 이전하는 작업을 백그라운드로 실행하고 있고, 그 과정에서 pod 이 재시작될 수 있다.

travelbeeee commented 6 months ago

현석

p.54 카산드라

왜 저 상황에서 카산드라가 유리한지 궁금했는데 한비형이 이미 너무 잘 정리해줬다 👍👍

p.57 ~ 58

모든 사용자에게 채널을 하나씩 부여해서 서버를 사용하고, 설계를 단순화하는게 감명 깊엇다.

p.65 ~ 66 주변의 임의 사용자

임의 사용자를 지오 해시를 이용해서 다루는 방법에 대해서는 이해를 함 그럼 기존 설계 + 임의 사용자 추천도 추가된다면 기존 해시링을 이용한 펍/섭 채널과 지오해시에 따른 펍/섭 채널을 두 대 이용하는 것...? 혹은 지오해시에 따른 펍/섭 채널에서 기존 해시링 이용한 펍/섭 채널처럼 구독(친구) 관계도 다 처리하고 + 임의 사용자까지 처리하는 것...? 후자가 맞겠죠...?

easyfordev commented 6 months ago

이지

kihyun-yang commented 6 months ago

기현

meloncha commented 6 months ago

민석

p.62

오버 프로비저닝(over provisioning)

p.68

얼랭 (erlang)

zziri commented 6 months ago

지훈

p.56