[Volume 2][Chapter 03] Q&A

[kihyun-yang]

기현

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]

기현이형 질문에 대한 생각

• 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에 대한 궁금증

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

[janeljs]

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]

p.98~99

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

[easyfordev]

p.84(매우 minor)

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

p86

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

나머지

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

[meloncha]

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연결이 계속해서 늘어나면 서버의 자원이 고갈되어 다른 클라이언트들의 접속에 대처할 수 없는 상황이 발생할 수 있다.
  

HTTP 2.0

• Multiplexed Streams를 이용해 Connection한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고 받는다.
• Multiplexing : 단일 connection 내에서 여러 HTTP request /response 를 처리
  

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]

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

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