이전 글에 이어 gRPC client부분을 구현하고, gRPC 통신을 테스트하였다.https://jhl8109.tistory.com/62 [WebRTC] 마이크로서비스 간 gRPC 통신 - 개발편(1)개요 현재 마이크로서비스 간 데이터 통신 시 TCP를 활용하고 있다. 그러나, gRPC로 방향을 바꿔보고자 한다. 이유로는 크게 3가지가 있다. 성능 개선 기대 예외 처리의 직관성 개선 기대 네트워크jhl8109.tistory.com gRPC 동작 gRPC 동작은 MessageChannelInterceptor에 의해 수행된다.코드 중 주석 부분은, 존재하던 TCP 코드이다.@Slf4j@RequiredArgsConstructor@Componentpublic class Message..
WebRTC 프로젝트를 진행하며 적용한 단위 테스트/통합 테스트 방법에 대한 내용이다. 최근 WebRTC 프로젝트와 오픈소스 컨트리뷰션에 참여하며, 테스트 코드에 대한 중요성을 많이 느끼게 되었다. 대학생 -> 개발자로 성장하는 데 있어 실제 배포 환경에서 문제가 발생하는 상황을 예방하는 것이 중요하다고 생각하게 되었으며, 테스트 코드의 작성이 CI 또는 변경 사항에 대한 유지 보수에 많은 도움이 될 것이므로 글을 작성하게 되었다. 추가적으로, 개발하며 테스트 코드를 비즈니스 로직과 함께 작성했어야 했지만, 촉박하게 기능을 개발하는 바람에 테스트 코드를 잘 작성하지 못했다. 그래서 부족한 부분을 프로젝트가 끝난 후에 보강 개념으로 단위 테스트/ 통합 테스트를 구현해보았다. 우선, 인프런, 유데미, 패스트..
현재 채팅서버는 카프카를 통해 채팅을 구현하였다. 카프카를 통해 채팅 서버가 scale out 하더라도 여러 채팅 서버간 분산되어 있는 메시지를 관리하기 위해서 사용하게 되었다. 하지만 고려 못한 부분이 존재했다. 카프카의 큰 이점 중 하나는 여러 파티션으로 나누어 병렬처리할 수 있다는 점이다. 즉, 많은 메시지가 쌓였을 때, 시스템 리소스(CPU, RAM 등)또는 성능에 따라 Consumer 수를 조정하여 파티션별로 데이터를 읽어오는 병렬처리가 가능하다. 하지만, Kafka는 파티션 내에서만 순서 보장이 될 뿐, 여러 파티션에 대해 병렬 처리하는 경우 순서가 보장될 수 없다. 따라서 이에 대한 해결방법을 고민하였고, 결과적으로 파티션별로 특정 채팅방을 할당하는 방식을 사용하게 되었다. 접근 방법 파티션..
개요 현재 마이크로서비스 간 데이터 통신 시 TCP를 활용하고 있다. 그러나, gRPC로 방향을 바꿔보고자 한다. 이유로는 크게 3가지가 있다. 성능 개선 기대 예외 처리의 직관성 개선 기대 네트워크 사용량 감소 기대 세가지 경우 모두 확실하지 않지만, 채팅 서버 - 상태관리 서버 사이에 적용하여 다양한 테스트를 해볼 예정이다. 테스트는 아래 3가지를 할 생각이다. TCP VS gRPC 송수신 성능 평가 예외처리 코드 작성 및 직관성 개선 확인(지극히 개인적, 정성적.. 으로 평가할 예정) Prometheus & Grafana를 통한 usage 체크 특히, 현재 가장 문제점은 예외처리 코드에 대한 직관성이 많이 떨어진다. 그 이유로는 TCP통신에 대한 이해도가 부족하여, 예외처리 구현의 미흡함이 있다. ..
같은 과 학생들과 함께 프로젝트 팀을 구성하여 팀 프로젝트를 진행하게 되었다. 특정 문제를 해결하는 것보다 기술적 능력을 향상 및 다양한 기술을 경험이 목표이다. 세부 주제는 WebRTC기반 스터디 그룹 프로젝트이다. 주요 구현 목표 미디어 / 시그널링 서버를 통한 WebRTC 스터디 WebSocket을 활용한 접속 상태 On/Off 버튼을 통한 실시간 사용자 공부 시간 관리 실시간 데이터를 관리하기 위한 상태 관리 서버 그룹 채팅 아키텍처 미디어 & 시그널링 Client끼리 WebRTC를 하기위해 시그널링 서버를 통해 SDP 및 ICE Candidate 정보 전달 (COTURN을 통해 STUN 서버도 구축) 이렇게 받은 정보를 토대로 미디어 서버를 통해 WebRTC 통신 Client 들의 방 입장과 퇴..
