[Netty] 비동기 서버 Netty와 NoSQL MongoDB로 채팅 서비스 구현

이전에 STOMP를 사용해서 채팅 서비스를 구현해 보았다. 이번에는 비동기 서버인 Netty 서버와 MongoDB로 구현한 채팅 서비스를 구현해보았다.

 

그 전에 mySQL과  MongoDB의 차이점을 짚고  넘어가자

mySQL은 관계형 데이터베이스 관리 시스템(RDBMS)이다.

• 테이블에 데이터를 저장하고 데이터베이스 액세스를 위해 구조화된 쿼리 언어(SQL)를 사용한다.
• 여러 테이블의 데이터가 필요할 때 Join을 사용하여 액세스한다. 

 

MongoDB는 데이터를 JSON과 유사한 문서롤 저장하는 NoSQL 데이터베이스이다.

• 문서는 관련 정보를 함께 저장하고 액세스를 위해 MongoDB 쿼리 언어(MQL)을 사용
• 필드는 문서마다 다를 수 있음
• 문서 구조를 선언할 필요가 없음

 

 

 

SQL은 언제 사용하는게 좋을까?

• 관계를 맺고 있는 데이터가 자주 변경(수정)되는 애플리케이션일 경우 (NoSQL에서라면 여러 컬렉션을 모두 수정해줘야만 함.) 
• 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

 

 

NoSQL은 언제 사용하는게 좋을까?

• 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우 
• 읽기(read)처리를 자주하지만, 데이터를 자주 변경(update)하지 않는 경우 (즉, 한번의 변경으로 수십 개의 문서를 업데이트 할 필요가 없는 경우) 
• 데이터베이스를 수평으로 확장해야 하는 경우 ( 즉, 막대한 양의 데이터를 다뤄야 하는 경우)

 

---

따라서 이 프로젝트에선 대량의 채팅을 조회할 때 성능을 내기 위해 MongoDB를 사용하였다.

 

 

Netty 서버를 선택한 이유

스레드 기반 서버(톰켓)은 요청마다 스레드가 생성된다. 스프링 4.0 까지는 서블릿 기반이다.

 

A 사용자가 서버에 요청을하고 서버가 DB를 조회한다고 가정해보자. 이때, 새로운 B 사용자가 동시에 요청을 할 수 있어야하므로 새로운 스레드를 만들어서 요청을 보낸다. 만약 유저가 늘어난다고 하면 스레드의 개수가 계속해서 늘어나고, 서버에 큰 부하가 걸리게 된다.

 

서버에 큰 부하가 걸리는 이유는 context-switching 때문이다. 

 

스프링 5.0은 기본적으로 Netty 서버를 사용한다. 비동기 서버의 가장 큰 특징 중 하나는 스레드가 하나인 것이다. 

 

A사용자가 서버에 요청을하고 서버가 DB를 조회하고 응답받는데 3초가 걸린다고 가정해보자. 그 사이에 새로운 B 사용자가 서버에 요청을 보낸다면 A의 DB 응답을 기다리는동안 B 사용자의 요청을 처리해준다. 그리고 3초가 지나면 A사용자의 요청의 DB 응답을 응답해준다. 즉 기다리는 시간 동안 할 수 있는 일들을 찾아서 해준다

 

즉 비동기 서버는 스레드 하나로 돌리는데 대신 놀고 있는 시간이 없고 따라서 무척 빠르다.

만약 비동기 서버를 사용할거면 db도 비동기여야 한다. 데이터베이스가 동기이면 아무리 서버에서 여러 요청을 받을 수 있다 해도 db가 동기이면 요청을 하나만 처리할 수 있기 때문이다. Mongo를 선택한 또 다른 이유는 여기에 있다.

 

 

 

 

코드로 살펴보자

• 우선 MongoDB를 사용하기 위해 application.yml 파일에 설정값을 세팅해줬다.

spring:
  data:
    mongodb:
      host: localhost
      port: 27017
      database: chatdb

 

• 컨트롤러는 1:1 채팅, 단체 채팅, 채팅 데이터 처리하는 메소드 3개로 구성
• 여기서 FLUX는 "흐름" 이라는 의미로 컨트롤러와 클라이언트가 커넥션을 유지할 수 있도록 해준다.

@RestController
@RequiredArgsConstructor
@Slf4j
public class ChatController {
    private final ChatRepository chatRepository;

    /**
     * 1:1 채팅
     */
    //Flux: 데이터를 계속 리턴
    @CrossOrigin
    @GetMapping(value = "/sender/{sender}/receiver/{receiver}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<Chat> getMsg(@PathVariable String sender, @PathVariable String receiver) {
        return chatRepository.mFindBySender(sender, receiver)
                .subscribeOn(Schedulers.boundedElastic());
    }

    //Mono: 데이터를 한번만 리턴
    @CrossOrigin
    @PostMapping("/chat")
    public Mono<Chat> setMsg(@RequestBody Chat chat) {
        chat.setCreatedAt(LocalDateTime.now());
        return chatRepository.save(chat);
    }

    /**
     * 단체 채팅
     */
    @CrossOrigin
    @GetMapping(value = "/chat/roomNum/{roomNum}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<Chat> findByRoomNum(@PathVariable Integer roomNum) {
        return chatRepository.mFindByRoomNum(roomNum)
                .subscribeOn(Schedulers.boundedElastic());
    }
}

 

• Mongo에서 데이터를 조회해오는 Repository 코드이다.
• @Tailable 은 커서를 닫지 않고 유지할 수 있다. 따라서 데이터가 들어올 때마다 컨트롤러로 이동 가능함
• FLUX를 사용하여 클라이언트로 데이터를 전송할 수 있다.
• 클라이언트로 데이터를 보낼 때 SSE 프로토콜을 사용한다. 

public interface ChatRepository extends ReactiveMongoRepository<Chat, String> {

    // Flux (흐름)
    // 데이터를 흘려서 계속 받겠다.
    // Response 를 유지하면서 데이터를 계속 보낼 수 있다.
    //같은 방에서 채팅하고 있는 사용자 조회
    @Tailable
    @Query("{ roomNum: ?0 }")
    Flux<Chat> mFindByRoomNum(Integer roomNum);

}

 

위 코드를 그림으로 나타내면 아래와 같다

 

 

 

(번외)

 

프론트 부분은 외부에 js를 사용해 따로 구현해두었다. 라이브 서버는 기본적으로 5000포트를 사용하기 8080포트와는 cors에러가 발생했다. 때문에 컨트롤러에 어노테이션으로 간단하게 cors에러를 해결해주었다.  

 

처음엔 아래와 같이 WebConfigurer 에서 cors에러를 해결해주려 했지만 netty 서버를 사용하고 있어서 이 방법으로는 실패했다. 

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**").allowedOrigins("http://front-server.com");
            }
        };
    }