1. 목표
2. 주요 기능
3. 사용 기술
4. 아키텍처
5. 상세 기능
6. 서버별 주요 코드
7. 서버별 주요 고려사항
8. Docs

원격, 실시간으로 스터디에 참여할 수 있도록하여 학습동기를 부여한다. 또한, 이를 지원하기위해 WebRTC를 활용하여 화면 공유, 자료 공유 등을 제공하며, 채팅, 일정 관리 기능을 통해 효율성을 높인다.

1. 스터디 그룹 형성: 사용자들이 특정 주제나 과목에 관심을 가지고 함께 스터디 그룹을 형성할 수 있다.
2. 실시간 모임: 원격으로 스터디 그룹 멤버들이 스터디방을 생성하고 참여할 수 있다.
3. 자료 공유: 사용자들은 공부 자료, 노트, 문제 해결 방법 등을 공유하고 함께 작업할 수 있다.
4. 화면 공유: 화면 공유 기능을 통해 다른 사용자들에게 자신의 화면을 보여주고 설명할 수 있다.
5. 채팅: 실시간 채팅 기능을 통해 멤버들은 토론하거나 질문을 주고받을 수 있다.
6. 캘린더 및 시간 관리: 개인 학습 일정 또는 개인 학습 시간을 기록할 수 있다.

• 백엔드 : Spring Boot, Spring Cloud(Eureka, Gateway)
• 데이터베이스 : MySQL, MongoDB
• 메시지 브로커 : Kafka
• 캐시 : Redis
• 배포 : Docker, AWS EC2, AWS RDS, AWS S3, Mongo Atlas, Git Action

전체 아키텍처	배포 아키텍처

채팅	상태관리

• 채팅 서버
• 시그널링 서버
• 그룹관리 서버
• 상태관리 서버

• Kafka는 메시지 큐와 같은 역할을 수행한다. 따라서, 채팅 서버가 여러 개 있는 경우 분산되어 요청되는 채팅에 대해서도 원활하게 처리한다.
• STOMP를 사용하였으며 pub/sub구조를 활용한다. 채팅 서버는 이를 통해 subscribe를 intercept하여 구독한 방으로 현재 사용자의 접속 상태 및 접속 위치를 파악한다.

• 고려한 점
  • Kafka에 파일, 이미지 등의 blob 데이터가 들어간 경우 채팅 서버 전반적인 성능의 하락이 일어날 수 있다고 생각하였다. (Blob 데이터가 사용자 -> 채팅, 채팅 -> 카프카, 카프카 -> 채팅으로 3회 전달)
  • 따라서, 이를 극복하기 위해 HTTP 통신으로 채팅 서버에 blob 데이터를 전달하고, 이를 AWS S3로부터 uri로 반환하여, 해당 uri로 kafka에 produce 되도록 구현하였다. (Blob 데이터가 사용자 -> 채팅, 채팅 -> AWS S3로 2회 전달되고 이 후 uri를 반환받아 uri 가 채팅 <-> 카프카로 전달)

• 상태관리 서버는 Cache Storage인 Redis에 실시간 데이터를 저장.
• 여러 서버에서 동시에 Redis에 접근하지 않고 상태관리를 위한 상태관리 서버를 별도로 구현
• 실시간성을 높이기 위해 TCP 통신을 활용

• 접속 상태 관리 방법
  • 사용자 접속 시 스터디방에 들어가지 않더라도 Default(전체) 스터디 방 소켓에 연결
  • 사용자가 스터디방 들어가면 해당 스터디방 소켓에 연결
  • 따라서 중복 입장을 막고 항상 소켓을 하나에만 연결하여 소켓 연결 여부(웹소켓 세션)를 통해 접속 상태 관리
• 이유
  • 접속 상태를 위해 별개의 소켓을 연결하게 되면 스터디방 접속 시 소켓을 두개 연결해야한다.
  • 10000명이 접속한다고 치면 10000개의 소켓 연결 대신 20000개(채팅 소켓 + 접속 확인용 소켓)의 소켓을 연결해야하는 셈
  • 그러나, 제시한 방법의 경우에도 스터디방에 접속하지 않더라도 소켓이 Default 스터디방에 연결되어 있음.

• API명세