Weekly I Learned 10주차

[기간]

- 11월 21일 ~ 11월 26일

 

 

[Weekly I Learned ( 10주차)]

이번 주는 이때까지 만들어온 프로젝트의 중간 발표가 있는 주차이다.

저번 주차 WIL 에서도 말했듯이 라이어 게임이 주제라 WebRTC, WebSocket 기술들이 주가 되는 프로젝트여서

이번에는 구현해본 WebRTC 에 대해서 얘기해보고자 한다.

 

우선 서비스 아키텍쳐는 이러하다.

(아키텍쳐 사진을 만들어주신 팀원분께 감사하다.. 너무 이쁘다!!)

 

프론트 쪽은 차치하고, 현재 중심적으로 볼것은 메인 기능 부분인 WebRTC 부분이다.

 

[WebRTC란?]

화상/보이스 채팅 기능을 위해 카메라와 마이크 등의 미디어 자원을 통해 실시간으로 소통할 수 있는 기술이 필요했다. WebRTC는 브라우저에서 지원하는 프레임워크로 많이 사용되어 안정성이 검증되어있고, 별도의 플러그인 없이 사용이 가능하여 User 경험에 유리할 것으로 판단했다.

 

쉽게 말해서, 카메라와 같은 미디어 자원을 통해 실시간 스트리밍과 같은 동작을 수행할 수 있는 것이다.

허나, 단순한 WebRTC 로만 구현을 한다면 일대다 형태의 다수의 인원들과의 실시간 통신은 솔직히 힘들다고 한다.

안그래도 넷상에서 찾기 힘들고 자료도 적었던 WebRTC 기술을 지원하는 라이브러리 중에서 OpenVIdu 라는 라이브러리를 채택하였다.

 

 

[OpenVidu]

Peer to Peer 기반의 WebRTC로 N:M 화상 채팅을 구현하기 위한 방법은 여러가지가 있는데 그 중 클라이언트와 서버의 부하가 비교적 적고 안정적인 SFU 방식의 구현을 위해서는 미디어 서버가 필요하다.

Openvidu는 미디어 서버를 구현하는데 필요한 리소스를 절약해주고 빠른 실시간 통신을 도와주는 라이브러리이다. 대부분의 코드를 정리된 소스 코드로 제공해주고 있고 화상 채팅 뿐 아니라 메시징, 화면 공유 등 다양한 기능을 지원하여 확장성과 접근성이 좋을 것으로 판단하여 선택하였다.

 

# OpenVidu를 선택한 이유

1. 앞으로 구현할 기능들 중에서 화상채팅 뿐만이 아니라 다양한 기능들을 사용해야할 수도 있기 때문에 채택

2. 일대다 연결 지원

3. 1,2번의 이유도 큰 이유 중 하나지만 가장 큰 이유는 화상채팅을 구현하는 자료들을 매우 찾기 힘들었다.

    내가 구글링을 잘 못했을 수도 있지만 적어도 일주일이라는 시간을 바치면서까지 찾아도 원하는 정보를 얻기 어려웠던      점을 생각하면 자료 자체가 부족했다는 것도 한몫을 하는 것 같다.

4. 적은 자료 중에서 선별해서 테스트해보는 것까지 엄청난 시간이 걸려서 더 이상 지체할 수 없었다.

    겨우 찾은 OpenVidu만이 희망이었다.....

 

OpenVidu는 Docker로 업로드하여 Ec2 서버에 올린 후 배포하는 형식을 취했다.

OpenVidu를 Spring 서버에 동시에 묶어서 운영해보려고 했으나 Ec2 서버가 너무 자주 터지고, 용량이 한번 꽉 차서 다시 지웠던 경험이 있기 때문에 따로 Ec2 서버를 분리해서 운영하게 되었다.

 

OpenVidu를 이용하여 프론트까지 연결이 되는 것을 이번 중간 발표떄까지 되어서야 겨우겨우 연결할 수 잇었다.

이제 9주차 떄 만들어놓은 WebSocket을 이용한 게임로직 부분과 WebRTC를 정상적으로 연결이 되기까지만 한다면

메인 기본기능은 거의 완성이라고 볼 수 있는 것이다.

 

하지만, 이 과정에서도 순탄하게 넘어가지 못했다....

 

[발생한 Trouble 슈팅]

• ⛔ 문제
• Spring과 Open-vidu를 하나의 서버에 구축했을 때, docker 및 docker 이미지 등을 설치하며 용량이 초과하는 현상이 발생했고, EC2 서버 인스턴스도 자주 끊어지는 문제가 있었다.
• ✅ 해결
• 두 서버를 함께 운영하기에는 서버에 무리가 있다 판단하여 Open-vidu 전용 EC2 서버를 만들어서 운영했다.

 

• ⛔ 문제
• OAuth를 사용하여 구글에 직접 인가코드와 엑세스 토큰을 받아 로그인/회원가입을 구현하려하였으나 unauthorize, miss_match_url 과 같은 에러가 발생했다.
• ✅ 해결
• 구글 API권한 요청을 받을 때 리다이렉트 URL을 접속하고자 하는 알맞은 도메인을 기입하지 않았을 경우 발생하는 에러로 판단하여 FE에서 인가코드를 거친 엑세스 토큰을 전달하게하여 해결했다.

 

• ⛔ 문제
• 일반적인 웹사이트와 다른 방식의 기획으로 기본 게임 진행 구현에 대한 로직이 어려웠다.
• ✅ 해결
• 채팅과 같이 Stomp를 이용하여 데이터를 주고 받으며, 게임 진행에 따라 필요한 함수들을 FE와 약속된 Type명으로 전달하여 구현하였다. 일반 채팅과는 달리 redis는 적용하지 않았습니다.

 

• ⛔ 문제
• 라이어와 시민에게 각각 다른 키워드를 동시에 전송해야 하나 기본 Stomp 기능으로는 구현이 어려웠다.
• ✅ 해결현재는 라이어와 키워드를 모든 유저에게 전달하면 FE에서 나누어 출력하는 방식으로 구현하였다.
• 추후 입장한 유저마다 개별 구독주소를 발부하여 라이어와 시민 각각 역할에 맡는 키워드만 받는 방식으로 변경하고자 한다.
• Spring Security내 Principal이라는 객체를 통해 유저마다 principal 정보를 따로 저장한 후 Principal 정보를 이용하여 convertAndSendToUser 명령어로 특정 유저(Principal)에게 websocket 방식으로 데이터를 보내주는 방식을 시도하였으나, 유저 로그인 정보에 데이터를 전송하는 방식이다보니 기대처럼 성공하지못했다.

 

• ⛔ 문제
• setAllowedOrigins("*")로 CORS 접속을 허용하였으나 Access-Control-Allow-Origin 오류가 발생했다.
• ✅ 해결따라서, allowedOriginPatterns(”*”) 로 변경해주거나 allowedOrigins(”http://localhost:8080/*”) (등 여러 IP주소)처럼 설정해주어야 정상적으로 접근이 가능했다.
• spring boot에서 CORS 설정 시, allowCredentials(true)와 allowedOrigins(”*”)는 동시 설정이 불가하며, 모든 주소를 허용하는 대신 특정 패턴만 허용하는 것으로 업데이트되었다.

 

지금 기억나는 것만 꼽아도 대표적으로 이정도인데 3주 동안 엄청난 이슈와 스트레스가 반복해서 발생했기 때문에 

개인적으로 너무 힘들었다고 생각한다...

특히, 서버 자주 터짐 이슈.... OpenVidu 이슈...

 

발표도 정말 잘 못했던 것 같았다.

시니어 개발자님께서 궁금해하셨던 내용을 옳바르게 답변을 해드리지도 못했던 것 같았고, 대부분 생각해본 적이 없었던 내용들도 있었다.

또한, 개발자님께서 질문하신 내용을 잘못 들어서 잘못 대답한 것도 몇가지 있었다..

(예를 들어서, 로그아웃 하게 되면 리프레시토큰 같은 것들을 어떻게 클렌징하는지.. 클렌징 처리되어있는데 클렌징 처리를 안하고 있다고 말씀을 드려버렸고, MySql n+1 이슈도 알고있었지만 잘못 들어서 처음 들어보는 이슈 내용이라 판단하고 잘 모르겠다고 답변을 해버렸다..)

 

하면서 느꼈지만 실전 프로젝트 시작 후 2주차 떄 번아웃이랑 무기력증이 너무 쎄게 온 것 같았다.

코딩을 할 떄 정신적으로 좀 힘들었고 집중도 잘 되지 않았고 자료 정리랑 발표 정리도 팀장님과 같이 나눠서 열심히 하고 싶었는데 그러지 못했던 것 같다..