[Volume 2][Chapter 02] Q&A

[janeljs]

지선

p.41

• Facebook Launches “Nearby Friends”
• Facebook to shutter its Nearby Friends service, having lost the friend-finding market

p. 44

• 위치 정보를 모든 친구에게 전송해야 한다 → HTTP 프로토콜을 사용하지 못하게 될 수도 있다?

p.47, p. 62-63

• 웹 소켓 서버, 유상태 서버 클러스터라는 말이 구체적으로 어떤 걸 말하는건지?
  • p.55 로드밸런서가 인식하는 노드는 연결에 대한 상태를 가지고 있음. 노드 제거 시 draining 상태로 변경. draining 상태일 경우 해당 노드로는 새로운 웹소켓 연결 생성이 안 됨
• 레디스 펍/섭 서버가 유상태 서버라는 것
  • 채널에 대한 상태정보: 구독자 목록
  • 특정 채널을 담당하던 펍/섭 서버를 교체하거나 해시 링에서 제거하는 경우 → 채널을 다른 서버로 이동시키고, 해당 채널의 모든 구독자에게 알려야 함
  • 아마도 서비스 디스커버리가 모든 웹소켓 서버에 해시 링이 갱신되었음을 알리고, resubscription 요청이 발생한다는 말일듯? (p. 63)

p.48, p.57

• redis pub/sub

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

• Pub/Sub Internal
  

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

p. 60

• consistent hashing

[KKambi]

한비

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

1. Cassandra

• 분산형 NoSQL (key-value / wide column-oriented database model)
• peer-to-peer replication (master-slave ❌)
• tolerant to failure
  

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

• p2p
• 모든 노드가 코디네이터가 될 수 있다 = 모든 노드가 어플리케이션 요청을 수락할 수 있다.
• 클라이언트가 요청한 데이터를 관련 노드에서 읽어서 클라이언트로 전달
• 클라이언트가 입력한 데이터를 관련 위치의 노드에 저장
• 확장도 쉽다.

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

• 근본이 분산형
• 각 노드가 데이터를 나눠서 보관하기 때문
• MySQL처럼 다 복사해두는 게 아니고, Kafka처럼 replication factor를 설정

---

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

AWS ECS - Graceful Exit

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이라는 라이프사이클 훅이 존재한다.

• API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출
• 컨테이너를 중지하기 위한 TERM 신호가 보내지기 이전에 완료되어야 한다.
• 파드의 그레이스 종료 기간terminationGracePeriodSeconds의의 카운트는 훅이 실행되기 전에 시작되어, 핸들러의 결과에 상관없이 컨테이너가 파드의 그레이스 종료 기간 내에 결국 종료되도록 한다.

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

2. n2c yobi 4719번 포스트

• pod의 status가 Terminating에 들어가면 service endpoint에서 제외되기 때문에 추가적인 트래픽은 들어가지 않습니다.
• pod spec 중 terminationGracePeriodSeconds의 값(기본 값 30초)이 preStop에 걸리는 시간 + SIGTERM을 처리하는 시간보다 길어야 합니다.

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

• 노드 cpu 사용률 급증 → 해당 pod livenessProbe 실패 → container SIGKILL 로 강제 종료
• 즉, 정상적인 pod lifecycle에 속하지 않으므로, SIGTERM 없이 SIGKILL만 전달된다.

[travelbeeee]

현석

p.54 카산드라

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

p.57 ~ 58

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

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

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

[easyfordev]

이지

• 저 우선 책을 2단계 개략적 설계를 읽다가 말았습니다 ㅠ 죄송합니다... 질문은 하나만 달아둘게요....ㅠ(이것도 뒷부분 읽으면 해결 될수도 있을 것 같아요..) 책 더 읽는대로 내용 채워두겠습니다!
• 43p. 위치 데이터를 저장하기 위해 강한 일관성(strong consistency)을 지원하는 데이터 저장소를 사용할 필요는 없다.
  • 강한 일관성(strong consistency)을 지원하는 데이터 저장소의 예시..? 단순 RDB 구조를 말하는걸까..?
  • 1권 6장에 강한 일관성에 대한 설명이 나오긴 함
  • 강한 일관성(strong consistency)
  • 달성하는 방법 : 모든 사본에 현재 쓰기 연산의 결과가 반영될 떄까지 해당 데이터에 대한 읽기, 쓰기를 금지하는 것
  • 고가용성 시스템에는 적합하지 않음. 새로운 요청의 처리가 중단되기 때문

[kihyun-yang]

기현

• 웹소켓 서버라는게 생소하다.
  • 웹소켓은 쉽게말해, Socket Connection을 유지한 채로 실시간으로 양방향 통신 혹은 데이터 전송이 가능한 프로토콜
  • HTTP 와는 다르게 stateFull 하다고 보면 될 듯
  • draning 상태의 웹소켓 서버에서 모든 연결이 종료되면 서버를 제거한다고 했는데, 굳이 모든 연결이 종료될때까지, 기다릴 필요가 있는건가? 그냥 바로 서버 제거하면 되는거 아닌가?

[meloncha]

민석

p.62

오버 프로비저닝(over provisioning)

• 애플리케이션이나 시스템에 필요한 것보다 더 많은 컴퓨팅 리소스를 할당
• Cluster overprovisioning in Kubernetes

p.68

얼랭 (erlang)

• 범용적으로 사용가능한 병령 프로그래밍
• 동시성 제어를 필요로 하는 병렬시스템, 분산처리 시스템의 개발을 위한 언어
• 함수형 프로그래밍 언어
• CouchDB, SimpleDB, Riak 등 NoSQL DB에서 맵리듀스의 구현 혹은 DBMS의 전체 구현을 위해 많이 사용되며, 채팅과 메시징, RabbitMQ, WhatsApp 서버, 금융시스템, 게임 서버와 같은 분야에 이용된다

[zziri]

지훈

p.56

• 관계형 데이터베이스 샤딩은 아주 널리 사용되는 기술이다
  • 조인때문에 거의 쓰지 않는 것으로 알고 있는데...
    • https://engineering.linecorp.com/ko/blog/line-manga-server-side
    • https://goodgid.github.io/DB-Sharding/