프로젝트/FitTrip

서론저희 팀은 기술적인 도전으로 MSA 아키텍처를 도입하기로 했습니다.MSA의 장점으로는 서비스에 대한 scale out이 용이하다입니다.그렇다면 MSA 도입 시 채팅 서비스도 scale out이 용이할까요?채팅 서비스는 일반적인 HTTP 통신을 사용하는 stateless 서비스와 달리, 웹소켓을 사용해 클라이언트와 연결된 stateful한 특성 때문에 scale out이 쉽지 않았습니다. 이번 글에서는 MSA 아키텍처 내 scale out이 용이하지 않은 채팅 서비스에 대한 문제를 해결하는 과정을 적어보겠습니다.채팅 서비스 scalue out시 문제점왜 stateful 한다면 scalue out이 용이하지 않을까요? 하나의 채팅 서비스에 두 명의 유저가 웹소켓으로 연결되어 있고1번 유저와 2번 유저 둘..

1. 개발 언어 선정언어 같은 경우에는 Java 밖에 모르는 상황이고 다른 언어들은 Learning curve 때문에 처음부터 고려를 하지 않았습니다. 다만 그래도 어떤 언어를 사용하여 개발하면 좋을지 조사를 해봤고 잘 정리된 글이 있어 해당 글의 일부를 참고했습니다.2. Framework프레임워크 선정도 큰 고민은 아니었습니다.이미 사용하고 있어 익숙한 Spring Boot를 사용하기로 선정했습니다.3. 채팅 서버 메시지 처리 방식채팅 서버 메시지 처리 방식은 크게 2가지 방식을 검토했습니다. 1️⃣ HTTP Polling HTTP Polling 방식은 WebSocket과 다르게 Connection을 맺고 있지 않아도 돼서, 서버 리소스를 상당히 절약할 수 있었고, API 서버 개발만으로 간단하게 기능..

프로젝트를 진행하면서 팀원들 간에 공통적으로 맞춰야 하는 작업이나 개발 효율을 위해 설정한 작업들에 대한 글입니다.설정한 공통 작업들로는 코드 컨벤션, 공통 응답, 예외처리, Git 커밋 컨벤션 정의, Git 브랜치 전략 정의, 패키지 구조가 있습니다.코드 컨벤션hobbytip Java Style Guide는 우아한 테크코스 Java Style Guide를 기준으로 작성되었습니다.우아한 테크코스 Java Style Guide와 다른 부분, 추가적인 부분을 깃허브 위키에 명시했습니다.기존 내용과 다른 부분은 제목에 목차를 명시, 새로 추가된 부분은 ✅  를 표기하였습니다.https://github.com/hobbytrip/hobbytrip/wiki/BE-%EC%BB%A8%EB%B2%A4%EC%85%98공통..

전체 아키텍처아키텍처란 시스템의 구조, 동작 등을 정의하는 개념적인 모형으로 시스템의 목적을 달성하기 위해 시스템의 각 컴포넌트가 무엇이며 어떻게 상호작용 하는지, 정보가 어떻게 교환되는 지를 설명한다. 쉽게 말해 아키텍처란 전체 시스템을 어떻게 구성할 건지를 정합니다.저희 팀의 아키텍처입니다.저희 팀은 기술적인 도전으로 MSA 아키텍처를 도입하기로 결정했습니다. 디스코드 기능을 분석하면서 어떤 구성요소가 있는지 파악하고구성이 비슷한 거 끼리 묶어서 서비스들을 구성했습니다.처음부터 서비스들을 작게 작게 나누기보다는 우선은 크게 크게 서비스들을 나누고거기서 세분화하는 방식으로 서비스들을 구성했습니다. MSA를 도입하면 얻는 여러 장점들이 있다고 합니다.loosely coupled를 기반으로 빠른 배포주기,..