4주차 멘토링

질문과 답변

1. 사용자 간에 소통할 수 있는 기능이 있으면 좋겠다는 생각이 있어서 sse 를 이용한 쪽지 기능을 넣고자 합니다. 하지만 남은 시간이 많지 않아서 최대 일주일 정도를 투자 할 수 있을 것 같은데, 시도하는 것과 현재 구현된 기능에 대한 문서 정리를 하는 것 중에 어떤 것이 괜찮을까요?

• 메타인지
• 소켓 / Long Polling / SSE 세 개를 비교해보고 정해보는 것도 좋을듯
• SSE는 특정 브라우저에서 지원을 안 함
  • IE는 지원 X, 나머지는 어지간하면 (버전이 정말 낮지 않으면) 지원을 함
  • => IE도 사용자가 1%는 되기 때문에, 사용자 1%를 잃을 각오를 한다면 괜찮고 아니면 롱 폴링이나 웹소켓을 생각해야 함
  • 보통 IE는 롱 폴링으로 구현
  • 또는 크롬 설치 페이지로 안내
• DB에 저장 => 모든 데이터를 한 번에 저장하는 것은 risky함
  • 페이징을 넣어서 문서에 넣는 방식
  • 첫 번째 대화부터 99번째 대화까지는 1페이지, 100번째부터 199번째까지는 2페이지, ...
  • 문서가 무제한으로 커질 염려가 적어짐
  • 채팅 글자 길이 제한도 무조건 들어가야 함 (Serverside, ClientSide 검증)
• 대화내용 저장 컬렉션 => A와 B의 대화내역만, n개 단위로 페이징
  • 프론트엔드 => 무한 스크롤
  • 이렇게 구현하면 큰 트래픽도 커버 가능할 듯하다 (몽고디비는 서버 분산 관련 기능이 있어 효과가 좋음)
• MySQL 등으로 구현한다면? Deep Query 같은 문제를 고려해야 함
  • Join 등의 쿼리에서 오는 부하가 적지 않음
  • 이 부분에서 NoSQL이 갖는 강점이 크다
• RDB에 모든 데이터를 넣고, 주기적으로 몽고디비 등 NoSQL DB에 복사하는 방식
  • 정합성이 엄청나게 중요하지 않을 경우 몽고디비 접근, 정합성이 필요할 경우 RDB에 JOIN 사용하는 등 크로싱
  • 몽고디비를 캐시 DB로 사용하기도
  • MySQL과 몽고디비에 듀얼 라이팅을 쓰기도 함
  • 정합성이 중요한 경우 몽고디비만 쓰지는 않음 (섞어 쓰기)
• 지금 규모에서는 NoSQL 정도로 괜찮을 듯 하다
• 남은 시간 2주 - 테스팅 1주 => 어려울 것 같다
  • 1주일만에 구현 가능한 내용일지...?
  • 간단하게 만들어 보는 것도? (페이징 등을 고려하지 않고, 빠르게 MVP로 작업한 뒤 나중에 고려했던 내용을 이야기하는 것도 좋을듯)
  • 설계가 불완전하다고 해서 불안해할 필요는 없다
• 경험을 했다는 점이 중요, 실 서비스 레벨로 업그레이드하려면 어떻게 하는 게 좋을지 이야기할 수 있을 정도면 충분할듯

2. 쪽지 기능을 구현한다고 한다면, 유의깊게 살펴봐야 할 만한 것들이 있을까요?

만약 구현을 한다면

1. A가 B에게 쪽지(짧은 문장)를 보낸다.(이건 단순 api로 요청을 받아도 되는건지?)
2. B가 접속해있는 경우, server-sent-event를 이용하여 쪽지를 push 한다.
3. B가 접속해있지 않은 경우, 보내야하는 쪽지들을 DB에 저장해놨다가, B가 접속한 경우 쪽지를 push 한다. 이정도의 기능을 생각하고 있습니다.

신경써야할만한 부분들이 있을까요?

• 쪽지 내역을 NoSQL DB 에 저장할 때 주의사항(내역이 무한대로 증가하는 경우는 어떻게 해야하는지)
• 많은 사용자의 동시다발적인 요청을 경험하기 위해서 어떤 방법이 있을지?
• 등등

3. 프론트엔드 폴더 구조에 대한 패턴, 디자인 패턴 궁금증

• React가 채택한 디자인 패턴의 특징 (선언적 프로그래밍)

  • Pages => presentational <- 여러 컴포넌트를 묶어서 한 페이지를 대표하는 컴포넌트를 작성
  • Common => container component (보통은 components 라는 이름으로 지음)

• 그 외에는 보통 자율로 구성

  • hook도 Util에 넣는 경우가 있다
  • services
  • store는 redux, recoil 등에서
  • GraphQL에서는 graphQL 관련 폴더가 존재하기도

• 팀원들의 합의에 따라 작성

• MVC <- 옛날 패턴, 이것을 타파하기 위한 여러 패턴이 지나가다가 현재의 패턴으로 정착됨

• IOS, Android 등 백엔드를 제외하면 이러한 형태로 개발하는 편

• Atomic: 디자인 팀의 힘이 강해야 함

  • 조그만 컴포넌트를 모아 완성하는 컨셉 <- 한국의 서비스는 예외가 너무 많아 아토믹으로는 커버가 힘듦
  • 잘 쓰이지는 않는 듯

• React는 많이 사용해본 듯 하니, Next 등 SSR을 공부해보는 것도 좋아 보인다

4. 채팅 부하? <- 수정 필요

• nGrinder
  • 수동으로 부하 테스트를 하는 도구
  • 초당 10, 20, 30, 40 ... 조금씩 요청 수를 늘려가면서 테스트하는 방식
  • 요청을 올려가면서 테스트하다 보면 어느 순간 응답 수가 내려가는 포인트가 생기는데, 이 시점을 한 서버가 낼 수 있는 최대 성능을 넘었다고 판단한다
• Kafka
  • 프로듀서 서버가 메시지 요청을 큐에 넣고, 서버 (컨슈머) 가 카프카 쪽 큐에서 데이터를 가져와 처리하는 방식
  • 메시지 큐를 구현하기 위한 간이 DB 중 하나이다
  • 메시지는 Restful API를 통해 프로듀서 서버에서 받는다 => 메시지 큐에 밀어넣는다 => 컨슈머가 메시지 큐에서 메시지를 하나씩 꺼내 처리한다는 흐름
  • 카프카 큐에서 메시지를 보관하고 다른 컨슈머들이 메시지를 하나씩 처리하여 몇몇 컨슈머 서버가 죽을 때를 대비할 수 있다
  • 똑같은 메시지를 두 번 처리할 가능성을 카프카에서 막아준다
  • 카프카 서버가 죽을 때를 대비하여, 메시지를 어디까지 보냈는지도 저장하여 만약 죽을 경우 마지막으로 보낸 메시지 다음부터 마저 보내게 된다
  • 간단한 서버에서는 필요없을 수도 있지만, 대형 프로젝트에서 안정성을 올리기 위해 많이 사용된다
• 메시지 큐를 공부해보는 것도...?

5. Swagger

• Swagger 예제
• 프론트엔드 개발자가 API를 사용해볼 수 있다는 점에서 오는 개발 용이성 + 문서화를 도와주는 도구

6. 복잡해지는 데코레이터

• 데코레이터 때문에 로직을 못 보는게 더 크리티컬
• 최소한의 내용만 데코레이터로 구현하기