HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
📯
부스트캠프 7기 BE 멤버쉽 설계
/
5주차

5주차

스프린트
[W3] 도서관
강의날짜
Oct 6, 2022
키워드
Cache
🧐
마스터클래스 질의응답 모음
제목
요약
확인
채팅 데이터가 엄청 많다고 했을 때 채팅 내역중 특정 문자열이 존재하는 채팅을 검색하는 기능이 필요하다면 관계형 DB로 구현이 가능할까요? 보통 채팅 데이터를 저장하는 DB는 무슨 DB를 사용하는지 궁금합니다
확인
마스터님은 네이버에 계속 머무실 생각인가요?
모르겠어요
확인
리뷰어님께서 사실 프론트 개발자는 마크업 작업을 많이 안한다고 하는데 정말인가요?
회사마다 다릅니다. - 퍼블리싱 팀이 있는 경우도 있고 - 네이버 같은 경우에는 마크업 개발자가 따로 존재함 - 그런데 프론트엔드 개발자는 마크업에 대한 깊은 지식은 당연히 요구
확인
채팅 기능을 구현해보려다 궁금증이 생겼습니다. 1. 실시간으로 이루어지는 모든 채팅을 db에 바로 바로 집어넣는 것은 너무 부하가 많아질 것으로 생각합니다. 서버에 캐싱을 해야할 것 같은데, 이 경우 캐싱된 데이터를 db에 주기적으로 반영해줘야할 것 같다고 생각했습니다. 이 외에 다른 방법이 있을까요? 서버가 다운되면 캐싱된 데이터는 다 날아가버릴 것 같은데, 대처 방법이 있을까요? 2. 클라이언트가 채팅방에 들어왔을 때, 채팅 내역을 바로 띄워주기 위해 클라이언트에도 특정 양의 채팅 내역은 캐싱해주면 좋겠다고 생각했습니다. 이 때, 클라이언트 측의 채팅 내역과, 실제 서버에 저장된 채팅 내역이 모종의 이유로 다를 수도 있습니다. 이는 어떻게 감지하고 동기화해줄 수 있을까요?
- 대규모에서는 - 분산 시스템을 구축하고 - apache kafka 같은 스트림 서버를 이용해서 분산 처리 - “스트림으로 처리한다” - Redis 같은 캐싱 디비를 이용하자. - 바로 DB에 저장하는게 아니라 - 캐시에 저장 후 - 특정 시점에 DB에 반영
확인
SPA에서 ‘사용자 님’처럼 항상 사이트 한쪽에 사용자의 정보를 띄워줘야하는 경우는 어떻게 이 상태를 관리해야하는 걸까요? 사용자의 정보가 필요할 때마다 access token을 쓰는 건데 계속 띄워줘야하는 경우는 어떻게 할지가 궁금합니다.
- 라우팅(페이지 이동)을 할 때 토큰 검사 하기 - 라우팅 할 때 토큰이 유효하지 않으면 로그인 페이지로 이동 - 로그인하고 되돌아오기
확인
모든 분야를 얼마나 깊게 들어가야할지 모르겠는 경우가 많습니다. 이번에는 인증 공부를 하다가 거의 보안 공부를 하고 있는 것 같아서, 경험해보신 실무에서는 보안에 대해서 얾마나 알아야 개발이 가능한가요?
- 보안은 필요한 개념 정도만 이해하면 좋고 - 실제 구현하는 것들은 구현이 필요한 경우에만 하자
확인
oauth에서 redirect url에다가 authorization code를 받고 그걸로 access token을 발급받는 것으로 알고 있습니다. 이때 access token을 프론트가 받고 백에 넘겨주는게 좋을까요 아니면 access token을 백이 받는게 좋을까요
확인
백엔드에서 유효성 검증을 얼마나 많이 해야할지 고민됩니다! 실제 백엔드 / 프론트엔드 개발자는 예외처리나 보안에 대해서 얼마나 신경쓰게 되나요?
- 백엔드에서의 검증은 할 수 있는건 거의다 해야 한다 - 클라이언트가 브라우저만 되는게 아니라, 서버가 될 수 있다. - 서버에서 유효성 검증은 필수
확인
실제 마스터님이나 BE 엔지니어 분들이 개발을 하실때 DB 접근을 최소화 하기 위해 의식하면서 개발을 하시나요?(과제하면서 DB 접근이 많아지면 신경이 쓰입니다. ex. 과부화 문제)
- 어떻게 하면 DB 접근을 최소화 할 수 있을까? - 실시간으로 가져와야 하는 데이터인가? - 실시간이 필요 없는 데이터인가? - 실시간으로 필요한 데이터가 아니면 그냥 캐시하면 되지 않나?
확인
마스터님은 프론트, 백엔드 둘 다 어떻게 이렇게 잘 아시나요?? 과제하면서 프론트, 백엔드 왔다갔다가 하니까 깊이가 조금 얕아지는 것 같습니다.
- 자리가 만들어줬음
확인
로그인이 필요한 서비스마다 서버에 로그인 검증을 하는 편이 좋을까요? 아니면 로그인 상태를 클라이언트에 저장해두고 크리티컬한 기능만 검증을 하는 편이 좋을까요?
- 항상 검증하는게 좋다
확인
Access, Refresh 토큰을 모두 사용하는 jwt 인증 방식에서는 Refresh 토큰을 디비단에서 저장해두고 있는게 합리적 인증방식일까요? 실제 서비스에서는 어떤 방식으로 할까요?
- 리프레시를 저장를 하는데, 굳이 똑같은 DB에다 저장할 필요는 없다. ( redis, nosql )
확인

Cache

  • 어떤 상황에 캐시를 해야 좋을까?
  • 어떤 캐시가 있을까?
    • HTTP 캐시
    • DB 캐시
    • Client 캐시
      • localStorage
      • 메모리 캐시
    • Server 캐시
      • Redis
      • 메모리 캐시
    • …
 
CPU ⇒ 레지스트리 ⇒ CPU 내부 캐시 ⇒ 캐시 ⇒ 메모리 ⇒ 파일시스템
 
i3, i5, i7 ⇒ 교수님 피셜
똑같이 멀티코어를 사용한다고 가정했을 때
왜 i7이 제일 좋을지 → 캐시 메모리가 많아서
 
서버에서 redis에다가 어쨌든 “요청(HTTP)”을 해야됨
 
Node 서버에 메모리 캐시 ⇒ 10대가 다 다름
 
10명의 사용자가 요청을 보냈는데, 10대에 서버에 다 캐시가 없으면? 무조건 리얼 데이터를 히트
 
 
Node 서버가 10대 ⇒ redis 1대 공유
 
redis 서버가 1대 (분산 서버에 캐시를 달아놓을 때 적합)
 
⇒ 10명에 사용자가 요청을 보내도 항상 캐시 반환
 
 
 
 
 
 
굉장히 많은 데이터를 한 번에 가져올 때
 
  1. 사용자에게 요청이 들어올 때 ⇒ 캐시 데이터가 없네? ⇒ 데이터 가져오고 ⇒ 캐시에 올리고 ⇒ 반환
    1. 문제가 뭘까?
        • 첫 요청이 항상 느리다
        • 캐시를 언제 갱신할지 모른다
          • 캐시 수명을 정해놓을 순 있음
          • 캐시가 없으면?
          • 다시 사용자가 요청해야 캐시가 만들어짐
 
  1. 주기적으로 데이터 가져오고 ⇒ 캐시에 올리고 ⇒ 사용자가 요청 보내면 캐시만 반환
    1. 항상 일관적인 속도로 응답을 보내줄 수 있음
 
 
 
 

스케쥴(주기적으로 실행하기)

  • cron?
    • 정해진 시간에 실행
      • 1초마다
      • 5초마다
      • 1분마다 ( 1분 정각이 되었을 때, 2분 정각이 되었을 때 )
  • timer?
    • 현재 시점 기준으로 주기적으로 10초마다 실행
      • 현재 시간이 18시 26분 36초인데,
      • 10초 마다 실행하면?
      • 46초
      • 56초
      • 1분 6초
      • 1분 16초
 

API 호출 최소화하기

  • SSR을 할 수도 있고
  • 서버에서 미리 데이터 가져올 수도 있고
 

실습