문제 상황

• 트랜스파일링 서버는 ffmpeg 프로세스가 RTMP 청크를 HLS 세그먼트로 트랜스파일링을 완료한 시점에 Object Storage 로 업로드 하는 로직이 필요합니다. 따라서 서버는 트랜스 파일링 완료 시점에 대한 별도의 감지 로직이 필요했습니다.
• 호스트 페이지는 트랜스파일링 서버에 숏 폴링으로 HLS 세그먼트의 변환이 완료되면 세그먼트 파일을 받아오고 있습니다.

해결 방안

• 트랜스파일링이 완료되는 시점을 fs.watch 등으로 감지할 수도 있지만, 호스트 페이지에서 HLS 세그먼트를 위한 숏 폴링을 주기적으로 보내고 있었기 때문에 이를 활용한다면 트랜스파일링 서버 내부에는 감지 로직이 필요하지 않을 것이라고 생각했습니다.
• 그렇게 호스트 페이지에서 숏 폴링으로 HLS 세그먼트를 받는 동시에 Object Storage 에 업로드하도록 로직을 수정해서 감지 로직을 위한 CPU 소모량을 줄였습니다.
• 하지만 그 결과, Object Storage 에 업로드하는 로직이 호스트 페이지와 강한 의존성을 맺게 되었고 호스트 페이지에서 숏 폴링을 보내지 않는다면 Object Storage 에도 업로드 되지 않는 결과를 낳았습니다.
• 이러한 강한 의존성을 끊어내고자 트랜스파일링 서버 내부에 감지 로직을 구현하고, 호스트 페이지에 SSE 로 HLS 세그먼트를 보내는 방식을 채택했습니다.
• 그러나 서비스 특성 상, 트랜스파일링 서버를 확장했을 때 OBS 와 연결된 트랜스파일링 서버가 어떤 서버인지 알아야 호스트 페이지 또한 해당 트랜스파일링 서버에 SSE 연결을 할 수 있습니다.
• 최종적으로 확장성까지 고려해서 트랜스파일링 서버의 내부 감지 로직을 통해 Object Storage 에 업로드 하고 호스트 페이지가 Object Storage 에 숏폴링으로 HLS 세그먼트를 받아오는 방식으로 구현

결과
- 호스트 페이지와 트랜스파일링 간에 생기는 강한 의존성을 제거
- 호스트 페이지의 숏 폴링과 동시에 트랜스파일링 내부의 감지 로직을 위한 CPU 사용 → 트랜스파일링 서버의 내부 감지 로직만을 위한 CPU 사용
- 호스트 페이지에서 Object Storage 에 업로드 되는 시간동안의 지연 시간이 발생했지만 이는 시청자 페이지와 다르지 않기 때문에 시청자 페이지와 같은 지연시간이 된 것이므로 문제없다고 판단

문제 상황

• socket.io 는 채팅을 하기 위해 room 에 join 하게 됩니다. 같은 room 에 있는 클라이언트는 같은 채팅방에 있는 시스템입니다.
• socket.io 는 유저의 소켓 연결을 할 때, socket.id 와 동일한 이름의 room (Default Room) 에 자동으로 join 하게 됩니다. 이는 1:1 채팅이나 서버에서 개인에게 공지를 보내는 등의 용도로 사용하게 됩니다.
• 그러나 저희 서비스는 위와 같은 1:1 채팅이 없는 실시간 라이브 방송의 채팅이므로 이러한 Default Room 은 사용되지 않은 채 서버의 메모리를 낭비할 여지가 있습니다.
• 따라서 소켓 연결을 할 때 Default Room 에 join 하지 않도록 로직을 수정했는데 연관이 없다고 생각했던 broadcast 로직이 바뀌는 현상이 발생했습니다.
• broadcast 는 기본적으로 sender 를 제외 하고 다른 사람들에게 이벤트를 보내는 로직인데, Default Room 에서 나간 채로 broadcast 를 하게 되면 Sender 를 포함해서 이벤트를 보내는 로직으로 바뀌는 문제가 발생했습니다. (관련 이슈 🔗)

해결 방안
문제를 해결하기 위해 3가지 정도의 방법을 생각해보았습니다.

• socket.io 대신 WebSocket 을 사용하면서 room + broadcast 개념을 직접 구현
• socket.io 의 room 개념을 그대로 유지한 채로 broadcast 로직을 새롭게 구현
• socket.io 의 broadcast 로직을 직접 수정

이 중에서 broadcast 로직을 직접 수정하는 것이 근본적인 문제를 해결할 수 있는 가장 좋은 방법이라 생각했습니다. 그래서 첫 번째로 프로젝트에서 Default Room 을 수정했을 때 Broadcast 로직이 수정되었으므로 room 에서 나가는 로직과 broadcast 간의 관계에 대해 학습했습니다. broadcast 의 로직을 직접 보기 전까지는 sender 를 제외시키는 과정이 sender 의 socket.id 를 제외하는 방식일거라 생각했는데 실제로 확인해본 결과 socket.id 와 같은 room (default room)을 제외시키는 방식이었습니다. default room 을 나가게 되면 해당 room 자체가 사라져버리므로 sender 를 제외시킬 수 없는 문제였습니다.

따라서 만약 room 이 존재하지 않는다면 연결되어 있는 socket.id 에서 default room 과 같은 socket.id 가 존재하는지의 여부에 따라 제외할 수 있도록 로직을 추가했습니다.

결과

• 사용하지 않는 Default Room 을 메모리에서 제거 함으로써, 클라이언트 한 명이 연결될때마다 생기던 메모리 낭비를 해결
• sender 를 포함하여 broadcast 되던 로직을 수정하면서 직접 sender 를 제외시켜야 하는 코드를 없애면서 코드 가독성 증가
• socket.io 의 이슈에 코멘트 등록 및 컨트리뷰션 가이드라인에 맞게 PR 🔗을 작성했습니다.

문제 상황
단일 채팅 서버로도 소수의 클라이언트들의 채팅은 충분히 처리할 수 있었지만, 초기에 기획했던 300명의 채팅 이벤트에 대해서는 불안정한 모습을 보였습니다.
특히나 트랜스파일링 서버가 CPU 집약적 연산을 위주로 하기 때문에 많은 트랜스파일링과 맞물려 많은 채팅이 오는 경우, 채팅 서버의 확장이 반드시 필요했습니다.

해결 방안
단일 채팅 서버에서 다중 채팅 서버로 확장함에 따라 채팅 서버 간의 유저, room 등에 대한 정보가 공유되어야 했습니다. 따라서 socket.io 의 기본 Adapter 를 Redis Adapter 로 바꾸어 Redis pub/sub 을 활용해서 채팅 서버 간의 데이터를 공유했습니다. 채팅 서버와 트랜스파일링 서버는 컨테이너로 관리하면서 확장에 용이하도록 Docker Swarm 으로 클러스터링하여 배포했습니다. 초기 목표가 300명 규모였기 때문에 서버 인스턴스가 많이 필요하지 않았고, 복잡한 설정이 요구되지 않았습니다. 따라서 엔터프라이즈 환경에서 주로 사용하는 쿠버네티스 대신, 빠른 설정과 높은 호환성을 제공하는 Docker Swarm을 선택하게 되었습니다.

결과
400명의 채팅 부하 테스트 시나리오에서, 1대의 NCP(Naver Cloud Platform) 서버 인스턴스와 단일 채팅 서버로는 약 300명 정도의 사용자의 시나리오에서 CPU 사용률이 50퍼센트를 넘었지만, 2대의 NCP 서버 인스턴스와 3대의 채팅 서버로는 400명의 사용자 시나리오에서도 각각의 인스턴스가 CPU 를 20퍼센트와 30퍼센트 수준으로 부하를 분산하여 확장성과 안정성 향상

• 주기적으로 검사해야하는 아동 정서 검사의 비용 문제 해결
• 검사 진행과 검사 결과를 바로 볼 수 있도록 어플리케이션으로 설계
• 아동에 맞춘 시청각 자료를 활용한 스토리텔링 검사

• 앱 시작 시, 칠드러닝 기업의 로고를 띄우는 시간 동안 coroutine 을 활용하여 검사 이미지를 미리 로딩하여 사용자 경험 개선

• 누원초등학교 학생들을 대상으로 검사 진행 및 피드백 반영
• 초등학생은 집중력을 길게 유지하기 힘드므로 검사 문항자체를 짧게 수정
• 집에서 검사를 진행할 경우 학부모의 개입이 있을 수 있어서 학교에서 진행하는 것을 선호
• 학교 소유의 태블릿을 주로 활용하므로 넓은 가로의 반응형 디자인
• 초등학생들이 힘들어하는 부분을 직접 옆에서 도와주면서 피드백 반영 (아이콘, 화면전환 등)

• 공식 프로젝트 기간이 끝난 후 리팩토링 및 현업 개발자 피드백을 위해서 대표님께 직접 찾아가 인턴으로 합류
• 코드 수정 시, GitHub Action 으로 EC2 에 자동 배포함으로써 개발 편의성 증가