개발 일정 및 목표
•
16일까지는 도메인 개발 및 프론트엔드 개발 마무리
•
16일~21일까지는 배포 및 사용할 기술 정의, 학습, 구현을 목표
•
23일 부터는 최적화 및 성능 향상, 부하테스트 작업 진행
•
이번주 한 일
◦
Mvp 기능 구현 완료 및 단위테스트 코드 작성(Socket 미적용)
◦
프론트엔드 구현 - React 사용으로 결정
◦
JMeter를 사용한 부하테스트.
•
다음주 계획
•
팀원
정해인
최준영
용소희
•
질문할 것 List
◦
로컬에서 JMeter로 부하테스트 해본 결과 조회시 100스레드(성공) / 1000스레드(실패)의 유저가 조회 했을 때 많은 에러가 발생
▪
http Poling(무상태에서 get 요청을 계속 받아오기)이 아니라 websocket을 사용해야겠단 근거
▪
성능 최적화를 위해 로드밸런서 사용
▪
또다른 최적화방법이 어떤게 있을까요
◦
채팅방 조회시 >> 한꺼번에 가져오는 것이 부하를 발생 (메시지 브로커 사용)
◦
프로토콜 관련
0.
부하테스트(진행함)
중요도 순서
1.
웹소켓
2.
배포
3.
부하테스트
4.
로드밸런싱
•
숙제: 멘토링 결과 다음 주까지 해올 일
◦
기본기능 구현
▪
이슈나 풀리퀘스트로 남겨주신다고 하셨음
◦
CI / CD 방법이 다양(도구는 어떤걸로 해도 상관없)
▪
어떤걸 쓸지 논의해보는 것이 좋다.
▪
ci/cd 중간발표 이후 특강 예정
◦
JMeter 부하테스트
▪
로컬에서 진행하는 것은 큰 의미가 없음.
>> 서버가 트래픽을 얼마나 견딜 수 있는지를 보려했던 것.
>> 나중에 다시하길 추천
채팅방 전체 목록조회
나한테 채팅이 왔냐 안왔냐를 계속 조회해봐야하는것.
1.
socket을 해인 >> 소희
2.
polling 해인 >> 소희에게 왔는지 get요청을 보내서 확인
3.
polling과 socket을 제안했던 이유: 자료를 찾아보며 팀원끼리 의논해보며 결정했으면했던것
◦
로드밸런서
▪
scale-in(기기자체를 좋게 바꾸는것) / scale-out(비용이 더 쌈, 가용성이 좋음, 그래서 scale-out을 많이 쓰는 편)
▪
scale-out을 했을때 서버에게 고르게 트래픽이 분배 되었을
▪
로드밸런서 서버를 하나 띄워서 그곳에 로드밸런서(nginx)를 설치하고 이걸로 다른 3서버를 사용 >> 옛날 방식 >> 하지만 어떻게 작동하는지 이해하기는 쉬울것. >> 해볼수록 좋긴하나 면접시 질문사항이 될 수 있으니 제대로 알아보기.
▪
AWS 로드 밸런서 (ElasticLoadbalncing) >> 요즘방식 >> AWS를 쓰는법 및 내부 원리, 선입선출 방식 고르개 분부해주는 것 등의 설정, 개념에 대해서만 알고있어도 충분. >> AWS에 있는 서버를 사용하면서 그 안에 내부적으로 설정해놓은 것
>> 이걸 썼을 때
◦
아쉬웠던 점
▪
채팅방 전체조회 >> 한 사람이 채팅을 많이해서 채팅방이 많이 조회된다.
▪
전체목록 조회 api를 쓸 수 있는가?
>> 페이징 처리 필요. 무조건! 몇천개 몇만개. >> 커서기반 페이지네이션 구현 (프론트까진 안해도됨) >> 백엔드에선 무조건
•
커서기반 페이지네이션이랑 오프셋 페이지네이션이랑 뭐가 다른지
•
장단점이 뭔지
•
왜 커서기반 페이지네이션을 써야하는지 정리해보기.
•
조회를 하는 동안 삭제나 생략이 될 수 있기 때문에 사용. 등등 장단점을 확실히 알 수 있는것
◦
Redis를 사용한 이유에 대한 의도를 명확하게 파악하고 있기
◦
ERD 채팅방사용자 (중간테이블)
▪
>> JPA에 쿼리가 어떻게 나가는지 확인을 해봤는가
▪
>> join으로 나갈 것 같음 >> 외래키로 연결하여, 양방향으로
▪
>> join쿼리는 비용이 많이 드는 쿼리.
▪
>> 예를 들어 카카오톡 같은 부분은 몇억 유저랑 몇억채팅방을 join함 >> 비효율적
▪
>> 코드리뷰를 통해 이런부분있으면 이슈에 남겨주신다고 하심.
•
양방향으로 사용하는 기준 (양방향은 지양되어야하는 부분)
◦
>> 편의성이랑 성능이랑 관련되어있는 부분
◦
>> caseByCase 트래픽이 많지 않은 admin페이지는 양방향으로 구성할 수 있다.
•
WebSocket 아래 문서 참고해서 작성하면 될것 같음
•
소희님 질문
◦
카카오톡을 보면 이 채팅방에 몇개의 새로운 메시지를 사용하고 있는지 나와있음.
◦
갯수만 관리하는 테이블이 따로있을 수도 있고, 소켓으로 받은것을 클라이언트 단에서 카운트를해서 표시해주는것
•
기업들의 경우 이런 연관관계를 애초에 안맺는 기업들이 많음.
◦
예를들어 좋아요기능
▪
인플런서 같은 몇억개의 좋아요
▪
게시글과 좋아요를 따로 만들지 안혹 게시글좋아요 테이블을 따로 만든다.
▪
연관관계도 개념상으로는 연관관계여도 실제로는 연관관계가 아닐수도있다.
•
Socket 구현을 빨리해보는게 좋을 것 같음.
재윤님 : 저희는 EC2에다가 올렸습니다
ㅤㅤEC2에 메모리 특화 인스턴스가 있습니다
ㅤㅤ아니면 Elastic Cache for redis 써도 됩니다
EC2에 레디스 띄우는게 훨씬 간단.
