로드밸런서도 부하를 줄이는 방법이 맞다. scale in, scale out
scale out을 많이 쓴다.
로드밸런서를 쓰는 이유는 서버를 3대를 썼을 때 한 대에만 트래픽이 가면 안되니까 3대에 골고루 트래픽을 보내주기 위함이다.
spring 서버가 세대가 있다고 가정했을 때 세대에 트래픽 분산을 시켜줘야 함.
로드밸런서 서버를 사용해야 하는데 서버를 하나 띄워서 로드밸런서를 설치해야 함. (NginX)
이렇게 쓰는 건 옛날 방식이다. 로드밸런서 서버를 또 관리해야 해서 아예 아마존에서 로드밸런서 제공해줌.
ELD 사용해서 하는게 더 좋다.
정확히는 AWS에 있는 서버를 쓰면서 내부적으로 그런 구현이 되어있는게 ELD
그냥 갖다가 쓰기만 하면 됨.
전체 목록 조회 API는 페이징 처리를 해야한다.
기본적으로는 들어가야 함. 몇 천개 몇 만개가 들어가면, 용량이 엄청나고 네트워크 비용이 많이 들어서 페이지네이션 처리를 해줘야 한다.
커서 기반 페이지네이션 해보기 → 프론트까지는 굳이 안 해도 될 것 같긴 한데 백에서는 무조건 해야한다.
정확히는 커서 기반 페이지네이션이랑 오프셋 페이지네이션이랑 뭐가 다른지, 장단점은 뭔지, 왜 커서기반 페이지네이션을 써야 하는지. 를 알아야 한다.
조회를 하는 동안 삭제나 생성이 될 수 있어서 생략이 되거나 순서가 뒤죽박죽 돼서 조회되거나 해서 방지하기 위해 사용 → 이런 장단점을 명확히 알고 커서 기반 페이지네이션 구현 해라.
너무 어렵게는 안 해도 됨. QueryDSL 까지는 안 해도 되는데 시간 되면 하면 좋음 → 쿼리 최적화
이메일 인증을 REDIS 를 사용한 이유는 휘발성 데이터여서 RDB에 직접 저장하고, Delete 쿼리를 날리는 것보다 Redis에 저장하는 것이 더 좋다고 생각했다. 등과 같이 잘 설명할 수 있도록!
조인 쿼리 → 비용이 되게 많이 드는 쿼리이다. 만약에 카카오톡 어플리케이션이라고 가정했을 때, 사용자가 거의 1억명은 될 것이다. 채팅방은 몇억개일 것.
채팅방 몇억개, 사용자 몇억개를 조인 해서 쿼리로 한 번에 가져와야 해서 성능이 되게 안 좋아짐.
join을 쿼리로 날리면 성능이 안 좋아져서 join 쿼리를 안 쓰게 하거나, RDB를 안 쓰거나 성능이 문제가 없을 만한 경우에만 join쿼리를 사용한다거나 함.
성능이랑 편의성을 따져서 전체 목록 조회는 자주 쓸테니 join 쿼리를 지양한다던가 상황에 맞게 써야 함.
아직 쿼리 어떻게 나가는지 까지는 자세히 못 보셔서 이번주 내에 코드리뷰 하면서 한 번 성능 문제 될만한 부분 있으면 코멘트 남겨주신다고 함. (이슈에)
웹소켓으로 어떻게 구현할지는 생각해봤는가? → 아니요
갖다 쓰면 돼서 그렇게 어렵지 않다. . . 쉽다는 아니고 블로그 글이라던지 그런게 많아서 일단 한 번 해보는게 좋을 것 같다.
맨 처음에 보낸 것중에 이준호 튜터님이 스프링 공식문서 예제 보내주신 거 있다.
가져다 써도 되고, 로컬에서 테스트 해보는게 좋을 것 같다!
웹 소켓 이용한 spring 채팅 구현 쳐보면 많이 나오니까 해봐라
채팅방 목록 전체를 조회할 수는 없으니 아마 그 갯수만 관리하는 테이블이 따로 있을 수도 있고 소켓으로 메시지를 받은 거를 클라이언트 단에서 세서 업데이트 하는 것 같다.
소켓을 쓰게 되면 메시지가 왔다는 걸 알 수 있다. 그 개수를 클라이언트 단에서 계산해서 보여주고 있을 것 같다.
join 관련해서 말씀해주신 거랑 비슷한 건데 실제 기업들에서는 지금 연관 관계 맺은 걸 아예 안 하는 경우도 있다.
왜냐면 사용자가 몇 명이 될지도 모르고, 그 사용자가 채팅을 몇만개를 가지고 있을 지도 모르기 때문에 한 번에 조회할 수가 없다.
그래서 프로젝트 할 때 좋아요랑 게시글이랑 연관관계를 맺어놨었는데, 만약에 인스타로 예를 들면 그 게시글에 좋아요를 가져오려고 한 게시글에 몇억개 연결돼있는 좋아요를 다 가져올 필요가 없으니까 게시글이랑 좋아요를 연관관계를 안 맺고 게시글 좋아요만 있는 테이블
