개발 기록 - 개발 언어 및 기반 기술 조사

1. 개발 언어 선정

언어 같은 경우에는 Java 밖에 모르는 상황이고 다른 언어들은 Learning curve 때문에 처음부터 고려를 하지 않았습니다. 다만 그래도 어떤 언어를 사용하여 개발하면 좋을지 조사를 해봤고 잘 정리된 글이 있어 해당 글의 일부를 참고했습니다.

2. Framework

프레임워크 선정도 큰 고민은 아니었습니다.

이미 사용하고 있어 익숙한 Spring Boot를 사용하기로 선정했습니다.

3. 채팅 서버 메시지 처리 방식

채팅 서버 메시지 처리 방식은 크게 2가지 방식을 검토했습니다.

 

1️⃣ HTTP Polling
HTTP Polling 방식은 WebSocket과 다르게 Connection을 맺고 있지 않아도 돼서, 서버 리소스를 상당히 절약할 수 있었고, API 서버 개발만으로 간단하게 기능 구현이 가능하다는 점에서 고려하게 되었었습니다.
그러나 일정 주기로 메시지를 클라이언트에서 가져가는 방식이기 때문에 다른 사용자가 작성한 메시지가 전달되는 데 까지 일정 시간 지연이 발생할 수 있고, 클라이언트 별로 Polling 되는 시점에 따라 서로 보고 있는 메시지가 다르기 때문에 실시간으로 보이는 채팅이 수초가량 불일치하는 문제가 발생할 수 있다는 단점이 있었습니다.

2️⃣ WebSocket
대부분의 채팅 플랫폼에서는 가장 많이 사용되는 메시지 전달 방식으로, 유저와 서버 간의 Connection이 맺어져 있는 상태이기 때문에 메시지가 발생하는 즉시 전달할 수 있다는 장점이 있으나, 서버와 연결이 지속되어야 하므로 서버당 처리할 수 있는 클라이언트의 수의 제한이 있다는 단점이 있습니다. 하지만 HTTP Polling 방식에서 발생하는 단점이 거의 완벽에 가까운 수준으로 발생하지 않습니다.

HTTP Polling vs WebSocket

각 방식의 장/단점을 정리해 봤습니다.

 

이렇게 HTTP Polling과 WebSocket 모두 각각의 장단점이 있었지만, 최종적으로 WebSocket을 선택하게 되었습니다. 큰 이유로는 지속성과 실시간성입니다. 

HTTP Polling 방식은 일정 주기로 메시지를 클라이언트에서 가져가기에 채팅을 보기까지 딜레이가 발생해 채팅의 실시간성이 의미가 없어집니다. 그렇다고 주기를 짧게 가지면 HTTP Polling 방식도 결국 HTTP 통신이어서 서버와의 부하가 싱해집니다. 웹소켓은 이러한 HTTP Polling 방식의 지속성과 실시간성에 대한 단점이 발생하지 않습니다.

또한 사용자 입장에서 봤을 때 실시간 채팅 서비스에서 메시지의 전달 지연이 부정적인 사용자 경험을 줄 수 있다고 생각합니다. 따라서 메시지 처리 방식으로 WebSocket을 결정하게 되었습니다.

4. 채팅 서비스의 데이터베이스

채팅 메시지에 대한 영구 저장소를 선택하기 위해서 다음과 같은 요소를 고려하였습니다.

• 채팅 메시지는 타입별로 메시지(서버/DM/포럼/이모지)의 구조가 다르고, 기능적인 메시지의 추가가 빈번할 수 있을 것으로 예상
• 사용자가 작성한 메시지의 수정/삭제보다는 저장/조회 Operation가 빈번하게 발생할 것으로 예상

이와 같은 요인들을 고려했을 때, 메시지에 대한 영구 저장소는 RDMS 보다는 NoSQL이 더 잘 맞다고 판단되었고, 다양한 NoSQL 중 다음과 같은 장점들 때문에 MongoDB 선택하게 되었습니다.

✳️  Schemaless 한 특성을 통해 다양한 형식의 데이터를 유연하게 저장/관리할 수 있음
✳️  계층적인 도큐먼트 형태로 저장되기 때문에 메시지 내의 다양한 객체를 포함하여 한 번에 저장할 수 있으며, 효과적으로 메시지 내의 모든 객체 관계를 저장/탐색 가능함

참고

https://kakaoentertainment-tech.tistory.com/110