-
Notifications
You must be signed in to change notification settings - Fork 2
6주차 멘토님과의 시간
[ 10분 ]
-
소개 (30초)
안녕하세요 부스트캠프 6기 웹 풀스택 교육 이수중인 web10 민태홍 남친구함 팀의 김영진입니다.
저희 팀의 프로젝트는 소개팅 웹 서비스 프로젝트입니다.
-
주요 기능 저희 팀이 구현한 주요 기능을 간단 소개드리면,
- 무한스크롤
- 실시간 채팅
- webRTC를 통한 화상,음성채팅
- iFrame을 사용한 게임하기 기능이 있습니다.
바로 데모 시연 영상을 보여드리겠습니다.
-
짧은 데모 (3분이내 최대한 짧게)
- 회원가입
- 소셜 카카오 연동
- 카카오 로그인
- 실시간 1 : 1 [ 신청 , 승인 , 채팅 ]
- 팀 설정
- 실시간 N : N [ 신청 , 승인 , 채팅 ]
- 채팅 무한 스크롤
- 그룹 화상 채팅
- 그룹 테트리스
-
webRTC 고민
webRTC 구현 방법에 크게 P2P, SFU , MCU 3가지 방법이 있는데,
저희 서비스는 클라이언트의 상황에 따른 불확정성보다는 안정적인 서비스를 제공해주기 위해, 저희는 클라이언트에 부담을 주는 P2P방식이 아닌 서버에서 부담을 덜어주는 SFU 방식으로 구현을 하기로 하였습니다.
저희는 최대 8명의 webRTC 그룹통신까지 생각하고 있기 때문에 P2P로서는 한계를 보이고 있다고 생각을 하였고 MCU를 채택하기에는 프로젝트를 진행하는데 주어진 서버로서는 부하를 견디기 힘들다고 판단하여 서버와 클라이언트의 부하를 분담하는 SFU 방식을 채택하였습니다.
[ MCU vs SFU vs P2P ] 클라이언트에 있는 pc 차이 보여주는 그림
-
SFU 구현 문제점
- SFU방식은 서버에서 클라이언트의 부담을 덜어주는 방식이기 때문에 최소한의 서버성능이 요구 된다.
[ 첫번째 ] - vCPU 1개 / RAM 2G 환경에서 /g1 / standard - 5명 이상 입장 시 서버 응답 속도가 현저히 느려짐 (로그인 하는데에 8초) -> 증거사진 + PM2 스트레스 테스트 결과 이미지 + 설명
[ 첫번째 해결 방안 ] - 배포 서버 성능을 올리자 - CPU 8개 / RAM 32gb / g2 / standard - 램은 상관없다 -> cpu 성능이 문제 -> 증거 사진 + PM2 스트레스 테스트 + NCloud 성능 사진 - JS는 단일 스레드로 CPU가 여러개여도 1개의 CPU만 사용한다. - 그런데 성능이 좋아진 이유? -> 기존 첫번째 방식에서 램때문에 서버가 터진게 아닌가?
[ 두번째 ] - CPU 성능문제 - JS는 단일 스레드로 CPU가 여러개여도 1개의 CPU만 사용한다.
[ 두번째 해결방안 ] - PM2 클러스터 모드와 NodeJs 클러스터 모듈을 사용하여 멀티 프로세싱을 가능하게 하였다. - 각 프로세스에서 세션값을 인지하지 못하는 문제가 발생했음 - Redis 사용으로 해결책 마련 - 증거 사진 + PM2 스트레스 테스트 + NCloud 성능 사진
-
성장
- 멀티 프로세싱 경험
[ 10분 ]
- QnA
- 더 발표하고 싶은 내용
- customHook
- Jest / StoryBook 사용했다
=>