회의 주제

비동기 회의 해보아요~ 의견 남기기도 편하고!

트래픽 그래프 구현 방향

✓ 진짜 실시간?

• 기본적으로 분석용 데이터 & 초기 렌더링 데이터는 HTTP
• 실시간 데이터는 메시지큐 & 웹소켓 SSE
  1. 프록시 서버에서 클릭하우스 insert와 별개로 메시지큐에 로그 송신
  2. 콘솔 API 서버가 메시지 큐 구독하며 로그 수신
  3. 콘솔 API 서버 → 콘솔 프론트엔드 서버는 WebSocket SSE로 실시간 로그 주고받기
• 가능하려면 애초에 우리 서버도 등록되어 있으니, 웹소캣 트래픽도 요청-응답 포워딩 가능해야 함

• 상진 생각: 힘들 것 같은데요..? 우선 프록시가 웹소캣도 잘 나르는지 체크해야 함.. (그치만 한명이라도 하고싶다면 몸 갈아 넣을게유)
• 병우 생각: 이 부분은 SSE 방식을 해보면 어떨까요? 클라이언트 → 서버 측으로 데이터 전송이 이뤄지는 것이 아닌 서버 → 클라이언트로만 데이터 전송이 이뤄지기 떄문에 SSE가 더 적절한 것 같아요!

✓ 세미 실시간?

• 적당한 큰 시간마다 초기 데이터 갱신 & 캐싱
• 적당한 짧은 시간마다 실시간 데이터 갱신 & 캐싱 (병우: 폴링 방식인가요? 상진: 저는 폴링은 생각 안했습니다! 연결 유지시킬 필요가 굳이 있을까 싶어서.. 그리고 갱신 발생할 때까지 기다릴 필요도 없지 않나 싶어서!)

• 상진 생각:

  • 클라이언트에서도 캐싱하고, 날짜도 백&프론트 알아서 계산해서 쌩 숫자 배열만 보낼 수 있으면 더 작은 단위 데이터도 보낼 수 있지 않을가 싶어요.

  • 그리고 초기 데이터는 처음 렌더링할 때만, 실시간 데이터는 30초 정도마다 갱신?

  • 갱신 주기 둘째치고, 정합성을 보장하려면 캐시 주기(ttl)가 갱신 주기보다는 짧아야 할 듯.

    ⇒ 아니면 캐시된 데이터가 그대로 보이고, 실시간성 없어보임

• 성호 생각: 근데 캐싱되면 고민인점.

  • 사용자가 사이트에 접속한다. - 초기데이터 api를 이용해 받음.
  • 30초 갱신이라치고. 2번 실시간 데이터를 받는다.
  • 이 상태에서 새로고침을 하면..?
  • 새로 초기데이터를 받아야할텐데.. 캐싱이 되지않나요?

✓ 결론 (갱신 주기, 캐싱 주기, 데이터 형식, 그래프 형식)