Dev_Henry

spring을 이용한 캡스톤 프로젝트 진행 중 요구사항 중 채팅 기능이 있었다. 이를 구현하기 위해 spring에서 webSocket과 stomp를 사용해 구현했다. 이때 기본 내장 브로커는 안정성, 확장성 측면에서 단점이 많아 외부 브로커를 도입했다. (장애 발생시 메시지 유실, 수용가능한 세션 크기 제한, 모니터링이 어려움, 서버 분리,확장이 안됨) 찾아보니 많이 사용하는 것들이 아래의 3개이기 때문에 각각의 특징을 알아보려고 한다. 우선 아래의 세가지 모두 비동기 메시지를 사용하는 서비스들 사이에서 데이터 송수신을 의미하는 MOM(메시지 지향 미들웨어)를 구현한 메시지큐이다. 메시지 큐의 특징으로는 큐를 사용한 비동기 처리 어플리케이션과의 분리 실패에도 전체에 영향을 주지 않음 여러 프로세스가 큐에..

ubuntu-jammy-22.04-amd64-server-20220912 환경의 ec2 에서 rabbitmq 설치하기 https://www.rabbitmq.com/install-debian.html#apt-quick-start-packagecloud Installing on Debian and Ubuntu — RabbitMQ Installing on Debian and Ubuntu This guide covers RabbitMQ installation on Debian, Ubuntu and distributions based on one of them. RabbitMQ is included in standard Debian and Ubuntu repositories. However, the version..

채팅목록 관리는 기존 사용하던 방식 그대로 Spring Data JPA와 mysql을 사용했다. 채팅내용을 관리하는 부분에서 어떤식으로 구현을 할지 고민을 많이했다. 처음에는 서버에 저장하지않고 클라이언트에만 저장하려 했으나, 어플이 꺼져있는 동안(소켓연결이 끊겨있는 동안) 온 메시지를 접속시 보여주려면 메시지큐를 다루어야 할것같은데 이 부분이 어렵기도하고 안정성이나 관리 측면을 생각해서 서버에 저장하려고 한다. 하지만 채팅 특성상 채팅데이터가 여러가지 형태로 올 수 있고, 삽입과 조회가 빈번하게 일어나기 때문에 RDB를 사용하면 성능이 떨어질듯 해서 사용해본적 없는 nosql을 써보기로 결정했다. 의존성 추가 implementation ('org.springframework.boot:spring-boo..

기본적으로 스프링에서 내장브로커를 제공하지만, 1. 인메모리 형식으로 데이터의 유실 위험도 있고 2. spring boot서버 내에서 함께 처리하기 때문에 서버의 부담도 커진다. 3. 메시지 큐를 모니터링하기 어렵고 4. 또한 현재 프로젝트 규모에서는 아직 필요없지만, 추후 서버를 여러개 둔다면 메시지를 함께 처리할 수 없어 확장성이 떨어진다. 이러한 여러 이유들로 외부 메시지 브로커인 RabbitMQ를 도입하고자 한다. RabbitMQ 의 메시지 전달 과정 1. 송신자가 메시지를 보내면 브로커가 처리과정을 위임받는다. 2. 일종의 우체통 역할을 하는 Exchange로 먼저 전달해서 메시지를 분류한다. 3. exchange에서는 몇가지 종류가 있지만 여기서는 넘어간다. ( Topic은 라우팅 키를 패턴으..