이전 글에 이어 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는 파티션 내에서만 순서 보장이 될 뿐, 여러 파티션에 대해 병렬 처리하는 경우 순서가 보장될 수 없다. 따라서 이에 대한 해결방법을 고민하였고, 결과적으로 파티션별로 특정 채팅방을 할당하는 방식을 사용하게 되었다. 접근 방법 파티션..
프로젝트를 진행하면서 테스트 코드에 대한 필요성 대해 더욱 자각하게 되었다. 그 이유로는 git Action을 통해 클라우드에 서버가 배포되기 때문에 Github에 푸쉬한 이 후에 배포 환경에서 예상치 못한 에러가 발생하는 것을 경험하게 되었다. 각 서버(혹은 컨테이너) 간 상관관계가 일부 존재하기 때문에 서버 간 정보를 주고 받는 경우를 테스트 하기 위한 방법이 필요하였다. 따라서, 테스트 코드를 상세히 작성하여 테스트 코드만으로 "1) 버그와 결함을 조기에 발견, 2) 변경 사항에 대한 동작 확인, 3) CI/CD에서 발생하는 예기치 않은 문제 해결" 이라는 장점을 얻고자 단위 테스트와 통합 테스트에 대해 정리하고자 한다. 단위 테스트(Unit Test) 단위 테스트란 애플리케이션의 작은 단위(일반적..
스마일게이트 윈터데브캠프(팀 프로젝트) + 소프트웨어 공학회(KCSE) 논문 발표 윈터 데브 캠프(서버) 오리엔테이션 개인 프로젝트 (MSA 인증 서버를 활용한 주제) 팀 프로젝트 (MSA 기반 채팅 애플리케이션,1월~2월) 연구실 KCSE 소프트웨어 공학회(학부연구생 논문, RESTful API + Fabric SDK + Hyperledger Fabric) 발표 스마트 컨트랙트 작성 (riceTrasnfer, milkTransfer) 블록체인 Gateway SDK VS CLI 성능 평가 (Jmeter) 매우매우 바쁜 1월,2월이 모두 지나갔다. 심지어 KCSE 논문 발표하러 가서, 일정에 맞춰 API 개발까지... 열정 넘치고 스스로 열심히 한 것 같아 뿌듯하다. 끝나고 난 후 많이 성장했다는 것을 체..
