WebRTC 프로젝트를 진행하며 적용한 단위 테스트/통합 테스트 방법에 대한 내용이다. 최근 WebRTC 프로젝트와 오픈소스 컨트리뷰션에 참여하며, 테스트 코드에 대한 중요성을 많이 느끼게 되었다. 대학생 -> 개발자로 성장하는 데 있어 실제 배포 환경에서 문제가 발생하는 상황을 예방하는 것이 중요하다고 생각하게 되었으며, 테스트 코드의 작성이 CI 또는 변경 사항에 대한 유지 보수에 많은 도움이 될 것이므로 글을 작성하게 되었다. 추가적으로, 개발하며 테스트 코드를 비즈니스 로직과 함께 작성했어야 했지만, 촉박하게 기능을 개발하는 바람에 테스트 코드를 잘 작성하지 못했다. 그래서 부족한 부분을 프로젝트가 끝난 후에 보강 개념으로 단위 테스트/ 통합 테스트를 구현해보았다. 우선, 인프런, 유데미, 패스트..
현재 채팅서버는 카프카를 통해 채팅을 구현하였다. 카프카를 통해 채팅 서버가 scale out 하더라도 여러 채팅 서버간 분산되어 있는 메시지를 관리하기 위해서 사용하게 되었다. 하지만 고려 못한 부분이 존재했다. 카프카의 큰 이점 중 하나는 여러 파티션으로 나누어 병렬처리할 수 있다는 점이다. 즉, 많은 메시지가 쌓였을 때, 시스템 리소스(CPU, RAM 등)또는 성능에 따라 Consumer 수를 조정하여 파티션별로 데이터를 읽어오는 병렬처리가 가능하다. 하지만, Kafka는 파티션 내에서만 순서 보장이 될 뿐, 여러 파티션에 대해 병렬 처리하는 경우 순서가 보장될 수 없다. 따라서 이에 대한 해결방법을 고민하였고, 결과적으로 파티션별로 특정 채팅방을 할당하는 방식을 사용하게 되었다. 접근 방법 파티션..
프로젝트를 진행하면서 테스트 코드에 대한 필요성 대해 더욱 자각하게 되었다. 그 이유로는 git Action을 통해 클라우드에 서버가 배포되기 때문에 Github에 푸쉬한 이 후에 배포 환경에서 예상치 못한 에러가 발생하는 것을 경험하게 되었다. 각 서버(혹은 컨테이너) 간 상관관계가 일부 존재하기 때문에 서버 간 정보를 주고 받는 경우를 테스트 하기 위한 방법이 필요하였다. 따라서, 테스트 코드를 상세히 작성하여 테스트 코드만으로 "1) 버그와 결함을 조기에 발견, 2) 변경 사항에 대한 동작 확인, 3) CI/CD에서 발생하는 예기치 않은 문제 해결" 이라는 장점을 얻고자 단위 테스트와 통합 테스트에 대해 정리하고자 한다. 단위 테스트(Unit Test) 단위 테스트란 애플리케이션의 작은 단위(일반적..
개요 현재 마이크로서비스 간 데이터 통신 시 TCP를 활용하고 있다. 그러나, gRPC로 방향을 바꿔보고자 한다. 이유로는 크게 3가지가 있다. 성능 개선 기대 예외 처리의 직관성 개선 기대 네트워크 사용량 감소 기대 세가지 경우 모두 확실하지 않지만, 채팅 서버 - 상태관리 서버 사이에 적용하여 다양한 테스트를 해볼 예정이다. 테스트는 아래 3가지를 할 생각이다. TCP VS gRPC 송수신 성능 평가 예외처리 코드 작성 및 직관성 개선 확인(지극히 개인적, 정성적.. 으로 평가할 예정) Prometheus & Grafana를 통한 usage 체크 특히, 현재 가장 문제점은 예외처리 코드에 대한 직관성이 많이 떨어진다. 그 이유로는 TCP통신에 대한 이해도가 부족하여, 예외처리 구현의 미흡함이 있다. ..
OSS(Open Source Software) OSS 컨트리뷰션 아카데미 Backend.AI에 지원했었고, 합격하여 활동하게 되었다. 첫 달인 7월은 Backend.AI에 대해 전반적으로 이해하는 시간을 가졌다. 발대식, 세미나에 참여하였고, 이를 바탕으로 OSS 중간 보고서까지 무사히 작성하여 현재는 Challenge 단계를 지나 Master단계로 진행하고 있다. Challenge는 해당 오픈소스에 대해 알아가는 것이라면, Master는 직접 기여해보는 단계이다. 7월 25일에는 Master를 진행하기 전이었지만 새로운 이슈를 등록하고, 해당 이슈를 해결하기 위한 PR까지 작성하였으며 현재는 Merge까지 된 상태이다!! 해당 내용은 컴퓨팅 세션(AI 연산 세션??) 생성 시 환경변수가 적용되지 않는 ..
개요 현재 WebRTC 프로젝트에서 사용자의 시스템 접속 상태관리를 위해 상태관리 서버를 사용하고 있다. 또한, 현재 마이크로서비스 간 통신을 위해 TCP connection pool을 통해 연결해놓고 있다. 여기서 개선방향을 찾고자 다른 방법에 관하여 공부해보고자 한다. 먼저 gRPC에 앞서 RPC에 대해 이해해야 한다. 기초 지식 RPC란? RPC는 Remote Procedure Call이다. 이는 한국어로 해석하면 원격 프로시져 호출, 즉, 범위 외부에 있는 대상을 호출하는 것이다. 따라서, 마이크로서비스에 적용하기에 국한 시켜 이해하자면, 네트워크로 연결된 마이크로서비스의 함수를 호출할 수 있는 통신 기술이다. 장점으로 개발자는 인터페이스를 통해 원격 함수를 호출하므로, 다른 마이크로서비스의 내부..
시험기간 + 학술대회 발표 + 특허 시험기간과 KCC 학술대회가 겹쳐서 별로 좋지 않은 일정이었다. 이 후에도 특허를 바로 작성해야 됐기 때문에 쉴 틈 없이 지나간 한달인 것 같다. 하지만 학부생 논문 최우수상을 수상하게 되어 그 보상을 돌려받는 기분이다. 항상 지나고 나면 부족한 점이 많이 보이는 것 같아서 아쉽지만 이를 통해서 더욱 성장할 수 있는 것이라고 생각한다!! 저번 달 당근마켓 썸머 테크 인턴을 지원한 후 코테 & CS의 중요성을 느끼고 꾸준히 공부해오고 있다. 수업 때 들었던 내용이 계속해서 기억나고 추가적으로 배우지 않았던 부분들도 강의를 통해 얻을 수 있어서 빠르게 늘고 있는 것 같다!! 하지만 당연하게도 몇 달이 되든 꾸준하게 이어 나가고 여러 번 반복하여 단단하게 기반을 다져야 한다..
에러(Error)는 컴파일 시 문법적인 오류와 런타임 시 널 포인터 참조와 같은 오류로 프로세스에 심각한 문제를 야기시켜 프로세스를 종료시킬 수 있다. 예외(Exception)은 컴퓨터 시스템의 정상적으로 실행되는 도중 예상하지 못했던 예외적인 조건으로 수행 중인 프로그램이 영향 받는 것이다. 오류와 달리 예외는 try-catch 블록을 사용하는 등 Java 코드에서 적절한 예외 처리를 통해 정상적으로 응답하고, 적절한 오류 메시지를 제공하며, 복구할 수 있다. 그렇다면, Java의 에러는 심각하고, 복구할 수 없는 반면 예외는 복구할 수 있다. Java에서 예외와 에러는 어떨까? Throwable 위 그림을 통해 확인할 수 있다시피, Throwable 클래스는 에러와 예외를 나타내는 모든 클래스의 상위..
졸업과제 착수보고서+ 카카오 브레인 + 당근마켓 + WebRTC 5월은 졸업과제 착수보고서로 인해 힘든 한달이었다. 주제가 바뀌기도하고 요구사항 분석, 유스케이스 명세, 유스케이스 다이어그램 등 잘 사용하지 않던 것들을 문서화 하는 것이 쉽지 않다는 것을 뼈저리게 느낄 수 있었다. 그리고 인턴에도 두 차례 지원을 했으나 잘 되지는 않았다. 처음 넣을 때는 내 서류가 통과가 될까? 라는 느낌으로 넣었지만 자소서를 작성하는 과정에서 너무 가고 싶었던 회사여서 사실 떨어지고 실망을 많이 했던 것 같다. 일주일 정도 지나고 지금 생각해보니 코테 & CS 준비가 너무 안되어 있어서 기말고사 끝나고 특훈이 필요하다는 생각이 든다. WebRTC는 마무리하기위해 쭉 진행했지만 생각보다 상태관리 서버에서 이슈가 많았다...
개발 중에 고민했던 내용 중 데이터 변환 과정에서 다형성을 적용한 경험을 정리하였다. 상황 현재 개발 중인 WebRTC 프로젝트는 MSA 형태로 구성되어있으며 실시간 데이터를 관리해야한다. 이 때 실시간 데이터를 관리하기 위한 방법으로 Redis(실시간 데이터 저장소)와 연동되는 것은 State(상태관리) 서버 뿐이며, TCP를 통해 Signaling 서버, Chat 서버로 부터 실시간 데이터를 받는다. 문제가 발생한 것은 Signaling 서버 및 Chat 서버로 부터 데이터를 받는 부분이었다. 우리 주제는 WebRTC 기반 스터디 이기 때문에 사용자가 방에 입장해서 버튼을 누르면 공부시간을 기록할 수 있다. 그렇기 때문에 Signaling 서버에서 유저ID , 버튼 누른 시각 을 보낸다. Chat 서..
