2020-2학기 팀 프로젝트 회고 (1)

Jihoon Oh·2021년 1월 8일
0
post-thumbnail

2020년 2학기, 나는 학교 교과목 중 설계 과목인 공개SW프로젝트를 수강했다. 복수전공을 시작하고 4학기째에 맞는 첫 팀 프로젝트여서 기대감이 상당했다. 과목에 대해 간단히 요약하자면, 오픈 소스를 활용해서 프로젝트를 만드는 과목이라고 보면 된다. 때문에 시작부터 Git과 GitHub를 이용하는 방법부터 배우고, 오픈소스 라이센스에 대해서 배우고 시작했다.

몇 주 동안의 오픈소스 강의가 끝나고, 본격적으로 팀 프로젝트를 구성하기 시작했다. 나는 복수전공생의 신분이었기 때문에, 수업 내에 아는 사람이 나와 함께 복수전공하는 같은 과 동기밖에 없었고, 우선은 그 동기와 팀을 구성해놓고 교수님께 추가 인원 보충을 요청했다.

결과적으로 6명의 인원으로 팀이 구성되었고, (그러나 중간에 1명이 탈주해서 총 5명으로 프로젝트를 진행했다.) 주제 선정을 위해 팀원들 끼리 의논해 보았지만 마땅한 아이디어가 나오지 않아서 교수님께서 지정해 주신 지정 주제 중 하나인 WebRTC 기술을 활용한 원격 수업 플랫폼을 주제로 선정했다. 나는 팀장을 맡았고, 개인적으로 백엔드에 관심 있었기 때문에 서버를 구성하는 역할 또한 맡았다. 추가적으로 WebRTC에 대해 공부해 본 팀원들이 거의 없어서, 그 전에 사전조사로 조금 공부했던 내가 영상 송출 기능 구현까지 맡았다.

사용 기술 스택

Front-End: HTML / CSS / JavaScript

  • 기회가 된다면 React나 Vue 같은 프레임워크들을 사용해서 프론트 단을 구성해 보고 싶었다. 하지만 해당 프레임워크를 사용할 줄 아는 팀원이 없었고, 페이지 구성 자체가 중요한 것은 아니라는 교수님의 말씀에 따라 프레임워크 사용은 포기했다.

Back-End: Node.js Express, AWS EC2, AWS RDS, MySQL

  • 기본적인 서버 구성은 Node.js의 Express 프레임워크를 사용했다. 처음에는 AWS 호스팅까지는 필요하지 않고 로컬에서만 돌릴 예정이었는데, 이후에 AWS 호스팅을 하는 쪽으로 변경하게 되었다. 이 부분은 후술할 것이다.

왜 Node.js와 Express를 사용했는가?

  • 우선 가장 결정적인 이유는 성능이었다. 이번에 만들 프로젝트의 핵심은 "실시간 통신" 이기 때문에, 동시 요청 처리 능력이 좋은 프레임워크를 선택해야 했다. Node.js는 단일 쓰레드 이벤트 루프 기반 비동기 IO 방식을 사용하기 때문에, 동시에 request가 오더라도 해당 request의 처리까지 기다릴 필요가 없어서 실시간 요청을 처리하는데 강점이 있다. 또한 Socket.io를 사용해서 통신 서버를 쉽게 구성할 수 있다는 장점도 있었다.

  • 또 하나의 이유는 다른 프레임워크들 보다 훨씬 더 친숙했다는 점이다. 물론 팀원들이 다 Java를 할 수 있기 때문에 Spring을 사용할까 생각해 보기도 했지만, 기본적으로 프론트 단과 백 단을 모두 JavaScript로 구성하는 것이 코드의 통일성이나 가독성도 더 좋고, 한번에 두 개의 언어를 해서 머리 싸매는 일이 발생하지 않을 거라고 판단했다.

프로젝트 수행 과정

WebRTC 기반 프로젝트였기 때문에, 당연히 초반에 구현하고자 머리를 싸맸던 부분은 WebRTC 기술을 활용하여 브라우저 위에서 화상 통신을 구현하는 것이었다.

사실 WebRTC로 웹캠 화면을 띄우고 전송하는 것은 레퍼런스가 워낙 많아서 큰 어려움이 없었다. 하지만 WebRTC 기술은 Peer-to-Peer 연결이기 때문에 사용자가 많아지면 트래픽이 급증한다는 문제가 있었다. 테스트 결과, 접속한 유저가 4명만 넘어가도 어마어마한 렉 때문에 통신이 버거웠다.

이 부분을 해결하기 위해서, 오픈 소스 WebRTC 미디어 서버인 Kurento를 사용하였다. 그 결과, 여러 세션을 접속시켜도 정상적으로 작동하는 것을 확인할 수 있었다!

그 다음에 테스트 해야 할 부분은 과연 프로젝트의 목표 수치인 30명을 한번에 접속 시킬 수 있는지에 대한 테스트였다. 처음에는 로컬 서버에 띄워 놓고 포트를 개방해서 다른 PC들에서 접속시키고 싶었는데, 내가 아직 미숙해서인지 포트포워딩을 제대로 하는데에 실패했다. 그래서 ngrok을 사용하는 방법도 생각했는데, 이 경우에 도커 위에서 돌리는 Kurento 미디어 서버에 제대로 연결이 안되는 문제가 발생했다.

가자 AWS로

결국 최후의 선택은 아예 AWS 위에 프로젝트를 올려버리자는 선택이었다. 어차피 AWS위에 올리는 것이 채점 받을때 로컬에서 도커로 돌리는 것 보다 더 쉬울 거라는 생각도 했고, 로컬 서버에서보다 성능 테스트를 하기가 더 용이할 거라고 생각했다.

AWS에 대해서 어렴풋이 밖에 모르던 나는 우선 내가 맡은 부분의 기능 처리들을 빠르게 마무리 짓고 AWS 계정을 만든 뒤 호스팅하는 법에 대해서 공부하기 시작했다. AWS CloudFormation을 통해서 Kurento Media Server를 AWS EC2 상에 올렸고, 프리 티어라서 한 달에 한 개의 EC2 인스턴스를 유지하는 것이 고작이었기 때문에 해당 인스턴스 위에 프로젝트 파일들까지 업로드해서 실행시켰다.

사실 처음에는 KMS 서버와 어플리케이션 서버를 둘로 분리 해 놓고, 사용할 때만 인스턴스를 키고 끄는 것을 계획으로 했는데, 그렇게 되면 계속 IP주소가 바뀌는 불편한 점도 있고, 무엇보다 둘로 나누었을때 보안 그룹 설정을 잘못해서 KMS와 브라우저가 통신을 제대로 못하는 상황도 나왔었다.

그래서 서버를 하나로 합치고 실행을 해 보았는데, 로컬에서는 잘 돌아가던 프로그램이 AWS상에서는 안돌아가는 상황이 발생했다. 정확히 말하면 비디오 및 오디오 통신만 안됐다.

Kurento 공식 문서와 Stackoverflow를 샅샅이 뒤진 결과, WebRTC 통신이 이루어지지 않는 이유를 찾을 수 있었다.

-(2)에서 계속

GitHub

profile
Backend Developeer

1개의 댓글

comment-user-thumbnail
2021년 7월 23일

안녕하세요 글 잘 읽었습니다! 혹시 KMS 서버와 어플리케이션 서버를 하나로 합치고 난 후 비디오 통신이 안됐던 이유가 뭔지 알 수 있을까요??😭

답글 달기