[Volume 2][Chapter 03] Q&A

kihyun-yang commented 7 months ago

기현

p87

위치정보 저장을 위한 통신 프로토콜로 왜 HTTP를 사용하며 어떻게 keep-alive 옵션을 사용하면 효율을 높일 수 있는 것일까?
- 서버에 연속적으로 동일한 클라이언트(단말)가 요청을 보낼 가능성이 높아서 효율이 높은 것일까?
- 동일한 클라이언트에서 서버로 실시간 요청이 많이 발생하는 경우 keep-alive 옵션을 사용하면 효율을 높일 수 있다고 일반화할 수 있는 것일까?

p94

애플리케이션이 지속적으로 수집한 사용자 위치 데이터를 통해 끊임없이 개선된다?
- 사용자가 움직인 위치 데이터에 따라 도로 데이터를 갱신한다는 말인가?

p98

user_id는 파티션 키, timestamp는 클러스터링 키?
- 카산드라에서 파티션키와 클러스터링 키가 무엇인지?
  - Cassandra에서 파티션 키는 데이터를 저장하는 노드를 결정(파티션 키에 해시를 적용하여 각 노드에 할당하는 방식)하고, 클러스터링 키는 노드 내에 데이터가 저장되는 방법을 결정.
  - 예를 들어 다음과 같은 테이블이 있다고 가정.
  - PRIMARY KEY (city_id, event_id)
    - 이 기본 키는 두 개의 열로 표시되는 두 부분으로 구성
    - city_id 가 파티션 키. 즉, 데이터는 city_id 필드를 기준으로 분할되어 동 한 city_id 가진 모든 행이 동일한 노드에 저장된다.
    - event_id 클러스터링 키 역할을 합니다. 각 노드 내에서 데이터는 event_id 열을 기준으로 정렬된 순서로 구성 및 저장된다.
  - 참고
- 즉, 특정 사용자의 특정 기간 내 위치를 효율적으로 읽을 수 있음.

KKambi commented 7 months ago

기현이형 질문에 대한 생각

HTTP keep-alive
- 위치 정보를 주기적으로 송신해야하는 상황에서, keep-alive로 커넥션 비용을 줄이자고 단순하게 이해했다.
수집한 사용자 위치 데이터를 통해 도로 데이터 개선
- 98p에 나온 것처럼, 새로 개설되어썩나 폐세된 도로를 감지할 수 있다
- 이런 것처럼 단순하게 받아들였다

100p - 지도 표시에 WebGL 기술을 채택하면?

WebGL

https://developer.mozilla.org/ko/docs/Web/API/WebGL_API 플러그인을 사용하지 않고, 웹 브라우저에서 상호작용 가능한 3D와 2D 그래픽을 표현하기 위한 Javascript API

OpenGL 기반이나, 웹(HTML, JS, 브라우저)에서 사용할 수 있도록 만든 것
GPU를 사용하여 2D, 3D 벡터 그래픽을 표현할 수 있음

벡터 vs 래스터

제목 없음

벡터

수학 공식을 따르는 선으로 표현
크기, 비율, 모양을 변경해도 품질 그대로
수학적인 정보만 저장하면 되므로 용량이 작다

래스터

픽셀 조합으로 이미지 구성
픽셀이 많아지면 해상도가 높아진다.
확대할수록 품질을 저해한다.
정보가 많아 상대적으로 용량이 크다 (픽셀 하나하나...)

Q. keep-alive에 대한 궁금증

keep alive 설정 시각에 따라 다르겠지만, 설정 시 동시 커넥션 수에서 불리해지지 않을까?
위치 서비스의 경우 스케일 아웃이 어려워보이지 않으니 상관 없을라나?

janeljs commented 7 months ago

p. 108

롱 폴링
- 클라이언트가 서버에 요청을 보내면 서버는 새로운 데이터를 사용할 수 있거나 특정 시간 초과에 도달할 때까지 요청을 열어둠
- 새 데이터를 사용할 수 있게 되면 서버는 업데이트된 정보로 응답하고, 클라이언트는 즉시 다른 요청을 전송 반복
- 구현하기 쉬움
웹소켓
- 수명이 긴 단일 연결을 통해 클라이언트와 서버 간의 실시간 통신을 가능하게 하는 전이중 통신 프로토콜
- 소켓은 양방향 데이터 흐름을 지원하여 클라이언트와 서버가 비동기식으로 메시지를 전송할 수 있음
  - 요청마다 새로운 연결이 설정되는 롱 폴링과 달리 연결이 지속되기 때문에 양방향으로 지연시간이 짧은 실시간 통신 가능
- 빈번한 HTTP 요청이 필요하지 않으며 네트워크 오버헤드 감소
SSE
- 서버가 수명이 긴 단일 HTTP 연결을 통해 클라이언트에 데이터를 푸시할 수 있는 단방향 통신 기술
- SSE를 사용하면 클라이언트가 계속 요청할 필요 없이 서버가 클라이언트에 여러 개의 업데이트를 보낼 수 있음
- (롱폴링과 비교할 때) 서버에서 클라이언트로 지속적인 데이터 스트림을 제공하여 지연 시간 감소
- (롱폴링과 비교할 때) 수명이 긴 단일 연결을 사용하므로 전반적인 리소스 소비 감소

https://www.pubnub.com/guides/long-polling/ https://medium.com/@pubnub-localized/%EB%A1%B1-%ED%8F%B4%EB%A7%81%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94-abc8f9d1aa36

travelbeeee commented 7 months ago

p.98~99

카프카를 두고 사용자의 위치 데이터를 이용해 새로 열린 도로나 폐쇄된 도로를 탐지하고 해당 변경 내역을 객체 저장소의 경로 안내 타일에 반영함으로써 점진적으로 지도의 품질을 개선한다
- => 지금 데이터 상으로는 갈 수 없는 길에 사용자 위치가 찍히면 해당 좌표에 새로 도로가 열렸다고 판단하는건가?? 그럼 CDN 에 있는 지도 이미지까지 모두 다 갱신하는거겠지...??
- => 폐쇄된 도로는 어떻게 판단하는거지?? 사람들이 가라는대로 안가면...? 감지할만한 패턴이나 알고리즘이 있을까...?

easyfordev commented 7 months ago

p.84(매우 minor)

QPS 계산할 때 하루에 3000억건의 요청 / 10^5 = 3백만 QPS로 계산하는데, 분모에 10^5가 들어가는 이유? 하루를 10^5초로 퉁치는건가?!

p86

'패키지나 상품이 목적지에 가까워졌을 때는 실시간 양방향 통신이 필요한 경우도 있다'
- 지도 서비스에서 이런 경우가 어떤 경우가 있을까요? (기술적인 질문이 전혀 아니라 의미상으로 이해가 살짝 안감)
웹소켓이 양방향 통신이 가능해서 채택해서 사용한다면, 웹소켓의 커넥션을 맺고 끊는 시점은 언제일까요?
- 경로 안내 서비스 요청을 할 때 웹소켓 커넥션 맺고 -> 목적지 도착하면 close하게 되는걸까요?
그렇다면, 많은 수의 웹 소켓 커넥션을 계속 물고있는? 형태가 되는걸까요? 이 경우 서버에 부담은 없는 걸까요?
(웹소켓을 어떻게 쓰는지 구조를 잘 몰라서 이런 생각이 드는듯...)

나머지

나머지는 위에서 다 다뤄줬으므로 패스..
HTTP keep-alive 옵션, 카산드라에서 clustering key,

meloncha commented 7 months ago

HTTP keep-alive 옵션

HTTP 1.0

persistent connection
커넥션 유지를 위해 Connection:Keep-Alive 헤더를 포함시켜야 한다
keep-alive 옵션의 동작은 Keep-Alive 헤더의 쉼표로 구분된 옵션들로 제어가 가능하다.
- timeout 파라미터 : 커넥션이 얼마간 유지될것인가? (이대로 동작한다는 보장은 없다.)
- max 파라미터 : 커넥션이 몇 개의 HTTP 트랜잭션을 처리할 때 까지 유지될것인가?(이대로 동작한다는 보장은 없다.)
```
Keep-Alive 응답 헤더의 예시
Connection: Keep-Alive
Keep-Alive: max=4, timeout=180
```

=> 서버는 약 4개의 트랜잭션이 처리될 동안 커넥션을 유지하거나, 3분동안 커넥션을 유지하라.



#### HTTP 1.1 에서는 기본 옵션이 keep-alive. 
  - 필요 없을 경우 Connection : close 헤더 사용 
  - 장점 : 서버의 단일 시간내 TCP연결의 수를 적게해서 자원을 절약할 수 있고 네트워크 혼잡이나, 지연의 경우의 수를 줄일 수 있다. 또한 속도가 빨라진다.
  - 단점 : 서버에 연결된 클라이언트의 TCP연결이 계속해서 늘어나면 서버의 자원이 고갈되어 다른 클라이언트들의 접속에 대처할 수 없는 상황이 발생할 수 있다.
![image](https://github.com/NW-study/system-design-interview/assets/51734158/11e24d39-aa7b-4d63-8f7e-c9ffa714e0c4)

#### HTTP 2.0
  - Multiplexed Streams를 이용해 Connection한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고 받는다. 
  - Multiplexing : 단일 connection 내에서 여러 HTTP request /response 를 처리
![image](https://github.com/NW-study/system-design-interview/assets/51734158/0b6a7c74-8fe2-491a-94c2-975740ef50c1)

#### keep-alive default timeout
- nginx : 3분
- apache : 5초

### ETC
- HTTP 프로토콜의 대표적인 특징으로 무상태성(stateless), 비연결성(connectionless) 인데, 왜 HTTP 1.1 부터 keep-alive 옵션이 기본 활성화 되는가?
  - persistent connection 은 HTTP 의 연결이나 내용 자체를 유지하는 것이 아닌 TCP connection dmfh 3-way handshake 를 불필요하게 다시 맺지 않도록 하기 위함.
  - 큰 데이터의 경우 TCP 연결은 유지하되, 각각의 HTTP 메시지는 독립적인 단위로 처리해야 한다!

참고 : 
- https://goodgid.github.io/HTTP-Keep-Alive/
- https://en.wikipedia.org/wiki/HTTP_persistent_connection
- https://en.wikipedia.org/wiki/HTTP/2

zziri commented 7 months ago

이미 대부분 설명을 잘 해주셨네요

http keep-alive (p.87)
ETA (p.88)
- Estimated Time of Arrival
POP (p.90)
- 여기서는 CDN 서버라고 생각하면 되겠다

NW-study / system-design-interview

[Volume 2][Chapter 03] Q&A #19

기현

p87

p94

p98