TDD TDD란 Test Driven Development의 약자로 테스트 주도 개발을 의미합니다. 반복 테스트를 이용한 소프트웨어 방법론 중 하나로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하며 구현하는 방법으로 소프트웨어를 개발하는 것입니다. 단위 테스트 : 가장 작은 한 단위만을 테스트하는 것 (...

# 문제점 AWS가 제공하는 원격 서버에 파일을 배포하다보니 로컬환경과 배포환경에서 필요한 환경 변수가 동일하지 않는 경우가 발생했습니다. 특히 DB를 연동하는 과정에서 사용되는 변수의 차이가 있었습니다. 그래서 프로젝트가 동작하는 환경에 따라 이를 구분된 파일로 관리하고 지정해줄 필요를 느꼈습니다. # 해결방안 Spring Profiles ...

# 문제점 API 서버에서 웹소켓 접속에 대한 요청을 최초로 받고 여러 개로 존재하는 웹소켓 중 하나의 주소를 선정해 응답객체로 전달해줘야 하는 과정에서 가장 적절한 웹소켓 주소를 선정해야 하는 소요가 발생했습니다. 적절한 웹소켓 주소를 선정해야 하는 가장 큰 이유로는 하나의 서비스를 위한 서버를 분리한 구조에서 하나의 서버가 대부분의 트래픽에 ...

# 문제점 실제 애플리케이션이 사용자로부터 사용되기 위해서 로컬환경이 아닌 외부 원격 서버에 배포되어야 하는 필요성이 있었고, 이를 위해 AWS에 배포환경을 구성해보기로 했습니다. 하지만 AWS에 배포하기 전 AWS에서 제공해주는 서비스는 무엇이 있으며 어떻게 활용해야 이전에 작성한 아키텍처 설계와 같은 동작을 할 수 있는지 학습부터 할 필요가 있...

# 문제점 API 서버와 웹소켓 구분하고 각 서버를 여러 서버로 Scale Out 할 수 있는 구조로 설계함으로써 관리해야 될 서버의 수가 늘어나면서 각 웹소켓이 다운되는 것으로 인해 발생할 수 있는 장애를 제어해야 할 필요가 있다고 판단했습니다. 그 중 하나의 경우로, 여러 웹소켓 중 다운이 되어 동작할 수 없는 경우에 해당 웹소켓으로 사용자가 ...

# 문제점 Scale Out을 고려한 아키텍처 설계 를 위해 STOMP의 pub/sub 방식의 메세징 기법을 사용하지 않고 웹소켓을 직접 핸들링해 채팅 기능을 구현해야 했습니다. # 해결방안 제가 구성한 채팅 기능 로직의 흐름은 다음과 같고 순서대로 구현 코드를 알아보겠습니다. API 서버에서 메세지 전송에 대한 요청을 받는다...

# 문제점 채팅 서비스가 동작하기 위해 필요한 기능 중 핵심은 하나의 채팅방에서 특정 사용자가 메시지를 작성해 전송한 경우, 채팅방에 접속해 있는 수신 대상자에게는 메시지가 직접 전송되어야 하며, 그렇지 않은 대상자에겐 푸시알림 으로 메세지 내용이 전송되어야 하는 것입니다. 하지만 채팅방에 초대된 사용자가 많으면 많을수록 해당 로직을 수행하는 시간...

# 문제점 애플리케이션이 실제 배포가 되었을 때, 사용자 수가 증가함에 따라 트래픽이 증가할수록 서버를 확장해야 하는데 하나의 서버로만 실행한다면 SPOF로 인해 확장이 불가능해 심각한 장애를 발생시킬 수 있다고 생각했습니다. 그래서 아키텍처 설계 단계에서부터 Scale Out이 가능한 아키텍처 설계를 고민해보고 구성해보기로 결정했습니다. # 해...

# 문제점 로컬환경에서 수정이 계속되는 jar 파일을 직접 터미널을 통해 ec2 서버에 전송해주고 실행시키는 작업 환경이 매우 반복적이고 오랜 시간이 걸리는 불편함을 느꼈고 이를 자동화를 통해 해결해 했습니다. # 해결방안 1. Github Actions Github Actions에 대한 정보와 특징은 CI 툴로 Github Action...

# 문제점 API 서버와 웹소켓 서버를 구분한 아키텍처로 구현했지만 하나의 모듈 내에서 전부 구현되어 하나의 포트에서 동작하는 한계가 있었습니다. 같은 프로젝트를 두개 이상의 서버로 실행시키면서 제한적인 기능만 활용하는 모양이 되었고 이러한 구조는 서버를 분리하면 할수록 매우 비효율적으로 동작하게 되었습니다. 결국 현재 프로젝트 구조는 제가 의도...