[Meet up with Mentor] 22.12.01

지난주 추가 질문에 대한 대답

메세지 전송을 API, Socket Server 각각에 요청하는 방식

두 군데에 두번 보내는 케이스는 없다. 서버 to 서버를 고려해라

서버 to 서버 사이에 메시지 큐를 사용하는 경우가 있다. 서버간에 서로가 어떤 상황인지를 모르기 때문에 잘 생각해야한다.

카프카 (서버 to 서버를 안정적으로 시켜 줌)

카프카에 메세지가 쌓여서 컨슈머가 요청하 갯수만큼 하나씩 준다.

컨슈머 (소켓서버) 가 죽으면 계속 쌓일 것이다.. 이런 것들을 처리해야한다.

카프카가 컨슈머에게 어디까지 전송했는지를 파일에 주기적으로 쓴다.

카프카도 한개만 있는건 아니고 물리적으로 두번 쓸 수 있다. (디스크가 나가서 아예 복구가 안되는 경우)

모든 서버가 2개 이상 죽을 수 있다는걸 고려해서 해야한다.

소켓 서버에서 다 처리한다면, DB 저장에 성공하면 브로드캐스팅 하는 방식으로 로직을 구현 할 것. 에러도 소켓으로 쏴버려

2개 DB 혼용

회사에서는 보통 정합성이 요구되면 RDB를 사용한다.

몽고디비를 캐시 layer로.. 쓴다던지 비 정형화 데이터를 한번에 넣는 경우도 있다.

수정이 일어났을 때 mongodb<> dual lighting?

RDB는 완벽한 정합성을 요구하는가

mongoDB 성능이 더 중요한다.

서비스가 규모가 커질 수록 mySQL은 scale-up을 한다. (mysql 성능을 올리는 것)

그에 비해 몽고디비는 샤딩을 해주기 때문에 그 점은 좋다.

보통 일단은 mysql 로 하다가 mongodb로 migration을 해버리는, 정합성이 크게 중요하지 않은건 mongodb에 넣어버리는..

캐시로 몽고디비를 사용하는걸 먼저 고려해보는게 좋다.

캐시로만은 redis가 좋긴한데, 디비가 다운되었을 때 리스크가 있기 때문에 mongodb가 상대적으로 안정성은 있다.. 모두 trade off

현업에서 DB를 바꾸는 경우가 사실 거의 생기진 않는다.. DB 별로 Query가 다르기 때문에, 최적화 관점에서

mysql → oracle 여기서 두개 쿼리가 동일한 역할인지를 전부 검증하는 것이 쉽지가 않다..

꼭 넘어가야한다면, 두개의 db에 똑같이 쿼리를 계속 날려서 db 두개 결과가 다른지를 비교해보는 식으로 검증을 해간다.

[수만] 소켓에서 DB연결시 느려지지 않을까?

• 만약 mongoDB를 소켓서버에 연결한다고 가정했을 때 이러한 문제가 생길 수 있다고 생각함
• 그렇게 생각하는 이유 : 현재 repository를 보면 거의 동기 처리(await, async)를 해줬다. 그래서 데이터 송수신량이 많은 소켓이 느려질거 같다고 생각

답변

어차피 mongodb는 비동기로 처리하면 크게 신경쓰지않아도 될 것 같다.

하나의 서버에서 열릴 수 있는 소켓이 몇개인지를 명확히 확인해봤으면 좋겠다.

부하테스트를 해보는 것도 좋다. 부하가 많이 왔을 때 에러처리를 어떻게 할 것인가?

어떤 소켓서버에 연결할지를 결정하는 앞단의 API 서버가 있어야한다고 생각. 샤딩이 가능한 구조

페북은 롱폴링 방식을 사용한다는 썰이 있다. 클라이언트가 요청을 하면 서버에서 응답을 여러개 보낼 수 있다. (롱폴링 방식)

[민종] 소켓을 사용하는 서비스가 적은 편인가요?

• 마스터님들이 마스터 클래스에서 왜이렇게 소켓을 사용하는 팀이 많은거야~~ 잘 쓰지 않는 기술인데… 와 같은 뉘앙스로 말씀을 하시던데
  1. 실시간 서비스에서 소켓을 사용하지 않고 다른 방식을 사용한다는걸까요?
  2. 아니면 실시간 서비스가 필요한 웹 서비스 자체가 적다는 의미일까요?

답변

네트워크가 불안정하면 연결을 끊고 클라이언트가 다시 롱폴링 요청을 한다.

웹소켓이라는게 아직 검증이 잘 된 부분도 아니다. 롱폴링이나 server sent event에 더 가깝다.

[[WEB] 📚 Polling / Long Polling / Server Sent Event / WebSocket 요약 정리](https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Polling-Long-Polling-Server-Sent-Event-WebSocket-%EC%9A%94%EC%95%BD-%EC%A0%95%EB%A6%AC)

디스코드 같은건 메시지를 받는 서버랑 보내는 서버가 다른듯?

[수만] 에러처리를 위한 DB접근

• 현재 모든 쿼리를 요청할 때 마다 검증하는 로직이 있고 검증하는 로직에서 DB에 접근하는 것이 필요한 로직에서 DB 접근하는 것보다 많은 경우가 있다. DB에서 데이터를 가져오는 것은 전부 동기처리로 되어있어서 성능이 저하되는 것이 우려됩니다.
• Ex
  • 채널의 정보를 가져올 때, 채널 document에 해당하는 정보만 가져오면 된다.
  • 사용자 document를 가져와서 채널이 사용자 document에 있는지 확인 하고 없으면 에러처리
  • 커뮤니티 document를 가져와서 채널이 커뮤니티 document에 있는지 확인하고 없으면 에러처리
  • 총 DB 접근 : 3회
    • 로직을 위한 DB 접근 : 1회
    • 에러처리를 위한 DB 접근 : 2회

[백엔드 에러처리 어디까지?? (1)

[민종] 생성, 수정, 삭제 시 해당 데이터를 전달받아야하는가?

답변

클라이언트에서 다시 목록으로 넣어서 추가된 한개 때문에 다시 요청하는건.. ㅇㅁㅇ

mySQL이라면 생성하자마자 응답해서 그 때 get 요청을 하면 새로 생성된게 못받아올 수 있다. (복제지연)

보통 바뀐데이터에 대해서 다시 응답으로 데이터를 전달해주는 편이다.

delete : statuscode 200 받았으면 client side에서 지워버령

[수만] 채팅을 클라이언트로 보낼 때 어떤 단위로 보내야 할 지 고민입니다.

• 상황
  • 채팅을 100개 저장하는 chatList 도큐먼트가 있다.
  • 클라이언트에서는 채팅을 20개 씩 보여줄 예정
• chatList를 그대로 클라이언트에서 보내고, 클라이언트에서 가지고 있다가 필요할 때 다시 요청 (like no cache)
• chatList를 20개씩 잘라서 보내고, 클라이언트에서 필요할 때 다시 요청 (like cache)

[나영] 클라이언트 서버가 https이고 백엔드가 http라면 mixed contents 에러가 났었는데 어떻게 해결한다고 하더라도 옳지 않은 방법인가

https://comple.co.kr/471

https://superuser.com/questions/565409/how-to-stop-an-automatic-redirect-from-http-to-https-in-chrome

크롬브라우저에 캐시를 지우면된다..

해킹을 방지하기위해서 크롬에서 전에 동일 주소에 https를 간 적이 있으면 막아둔것이다.

준영

• mock API로 개발을 진행하고 있습니다. DB 변경이 필요한 로직이 잘 돌아가는지 확인하기 위해 mock 데이터 객체를 만들어놓고 해당 객체를 수정하는 방식을 씁니다. 관계가 있는 데이터를 다룰 때가 까다롭고, 오류도 간간히 생깁니다. 하지만 관계가 있는 전체 데이터를 짜놓자니 시간도 들고 BE 변경사항을 반영하기도 어려운 거 같습니다. 관련해서 의견이 있다면 듣고 싶습니다.

class validator같은 거로 API 응답을 검증하기도 한다 프론트단에서

하기로 했던 스펙 다 만들고, 그다음에 리팩토링할 때 공통화하면 좋다~