이전 글에 이어 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 들의 방 입장과 퇴..
유저 서버 유저 서버는 채팅 앱에서 친구 요청/수락/취소/삭제, 유저 검색, 프로필 수정의 기능을 수행한다. 유저 서버 주요 구현 내용 유저 쿼리 프로필 이미지 저장 - AWS S3 친구 상태 관리 유저 쿼리 유저 쿼리에서 유의미한 성능 향상과 좋은 팁들을 얻을 수 있었다. 우선 쿼리를 다시 점검하게 된 이유는 팀원의 Prometheus와 Grafana를 활용한 모니터링과 Ngrinder의 부하테스트 덕분이었다. 친구 목록 조회 쿼리가 채팅 앱의 거의 메인화면에 해당하기 때문에 가장 많이 사용되었다. 그러나 성능이 매우 뒤떨어 진다(TPS 20.8)는 결론을 얻을 수 있어서 성능 향상의 계기가 되었다. 성능 개선의 요인은 3가지가 있다. @Transactional(readOnly = true) 추가 쿼리..
1인 프로젝트에서 MSA 기반 인증 서버 만든 것을 확장하여 구현하였다. 게이트웨이 Gateway를 통해 Jwt 토큰을 검증하고 각 서버에서 필요 시 jwt토큰으로 부터 유저 정보를 확인한다. 게이트웨이를 활용하였기 때문에 각 서버에서 따로 검증하는 코드를 작성할 필요가 없게 되었다. 게이트웨이 주요 구현 내용 Jwt 검증 GlobalExceptionHandler ErrorCode Jwt 검증 게이트웨이에서 Jwt를 검증한 방법은 아래 코드를 통해 확인할 수 있다. header에 Jwt 토큰이 존재하는 지, 그리고 그 토큰이 유효한 지를 검증한다. 이 때 예외 발생 시 예외를 던진다. public class AuthorizationHeaderFilter extends AbstractGatewayFilte..
프로젝트를 경험해보면서 API, DB 등 설계의 중요성을 많이 느꼈다. 프로젝트가 복잡해질수록 소프트웨어도 복잡해지고 이에따라 탄탄한 설계가 가져오는 장점들이 존재함을 몸소 느낄 수 있었다. 우리가 만들고하자는 요구사항(윈터데브캠프의 목표)을 효과적으로 만족시킬 수 있다. 유지보수 측면에서 용이하다. 협업에서 이점을 갖는다. 따라서, API,DB명세를 상세히 하고자 했고, 이에 따라 적용한 방법을 보이고자 한다. 내가 생각하는 API 명세를 작성하는 이유는 크게 3가지가 존재한다. 어떤 것을 구현해야하는지 명확히 한다. 협업에 있어 req/res 형태를 공유한다. 정해진 규칙을 따라 API를 명세한다. 이를 만족시키기 위해 기능 명세를 작성하였다. 기능 명세를 작성한 이유는 시간에 대한 한계가 있기 때문..
스마일게이트 윈터데브캠프에서 채팅 애플리케이션을 개발하였다. 채팅 애플리케이션을 개발하기로 한 이유는 팀원들 간 회의를 통해 도출된 공통 목표에서 나오게 되었다. 공통 목표 경험해보지 못한 아키텍처와 기술들을 활용하여 문제 해결에 대한 폭을 넓힌다. 양방향 소켓 통신에 대한 경험 X 전체 서버의 아키텍처는 MSA를 기반으로 구성하였으며, 채팅 서버는 scale out 가능한 구조로 구성하고자 했다. 전체 구조는 아래 그림과 같다. 이번 프로젝트에서 서비스 레지스트리, 게이트웨이, 인증 서비스, 유저 서비스, 푸시 서비스는 내가 맡게 되었다. 추후 각 서비스 별 주요 내용을 정리할 예정이다. 실제 상호작용하는 부분이 추가된 상세화된 아키텍처는 아래와 같다. 전체 사용 스택은 Spring Boot, Spri..
MSA 기반 인증 서버 스마일게이트 윈터데브캠프에서 팀 프로젝트 시작하기 전 개인 프로젝트 개발 과제를 진행했다. 블로그 , URL shortener , MSA 인증 서버 중 인증 서버 개발 과제를 선택했고 그 이유는 팀 프로젝트에서 백엔드 담당 이기 때문에 Spring Boot를 사용해보기 위해 선택했다. MSA 구성 기간이 1달 정도이고, 기말고사 기간이 2주 겹쳐있었기 때문에 React의 경우는 매우 간단하게 짰고 최대한 서버 부분에 집중했다. User 서비스 : 회원가입, 로그인 처리 Order 서비스 : User 서비스와 1:N관계를 갖는 주문 정보를 처리 Discovery 서비스 : 각 서비스들의 상태 정보를 처리 Gateway 서비스 : 각 서비스들로 중계 역할을 수행 요구 사항 윈터데브캠프..
