항해99 8주차 WIL

1. 주제 확정 및 기본 CRUD 작성

필자가 속한 6조는 작곡가들을 위한 음악 스트리밍과 협업에 관한 사이트를 만들기로 정하였다. 기본적인 페이지 설계와 필요한 기능, 추가적으로 구현할 인프라 고도화 등의 회의를 거쳐 월요일부터 기본적인 CRUD에 관한 REST api를 작성하기 시작했다. 기본적으로 필자의 조는 스트리밍 기능을 포함하고 있기 때문에 MP3 파일을 어떤 방식으로 저장하고 어떤 방식으로 보낼지를 정해야했다. 필자의 조는 어떤 툴을 사용하여 MP3 파일을 저장할지 고민하였고 일단 저번 주차까지 사용했던 S3를 써보기로 했다. 결과는 성공이었다. s3는 어떤 방식의 확장자라도 저장이 가능했다. 이를 통해 파일들을 대부분  s3에 저장하고 그에 대한 정보는 데이터베이스에 저장하기로 했다. 이후에 어떤 방식으로 메세지와 화상채팅을 구현할지에 대해 고민했다.

2. 메세지 작성과 소켓, 그리고 STOMP

WebSocket

-> 기존의 단방향 HTTP 프로토콝과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜

-> 일반 소켓 통신과 달리 HTTP 80 포트를 사용하여 방화벽에 제약이 없고 동상 웹소켓이라 불린다.

-> 접속까지는 HTTP 프로토콜을 이용하고 그 이후 통신은 자체적인 웹소켓 프로토콜을 이용한다.

 

 기존 HTTP 통신의 특징인 (연결-> 연결 해제)방식은 채팅 시스템을 구성하기에 효율이 많이 떨어지게 되서 2014년 HTML5부터 웹소켓이 포함되었다. 웹소켓은 클라이언트가 접속 요청을 하고 웹 서버가 응답한 후 연결을 끊는 것이 아닌 Connection을 그대로 유지하고 클라이언트의 요청 없이도 데이터를 전송할 수 있는 프로토콜이다. 프로토콜의 요청은 [ws://~]로 시작한다.

 

 WebSocket이 기존의 TCP Socket과 다른 점은 최초 접속이 일반 HTTP Request를 통해 HandShaking 과정을 통해 이뤄진다는 점이다.

 

 HTTP Request를 그대로 사용하기 때문에 기존의 80, 443 포트로 접속을 하므로 추가 방화벽을 열지 않고도 양방향 통신이 가능하고, HTTP 규격인 CORS 적용이나 인증 등 과정을 기존과 동일하게 가져갈 수 있는 것이 장점이다.

 

 실시간성을 보장해야 하고, 변경 사항의 빈도가 잦다면, 또는 짧은 대기 시간, 고주파수, 대용량의 조합인 경우 WebSocket이 좋은 해결책이 될 수 있다.

 

클라이언트가 먼저 헨드셰이크 요청을 보내고 이에 대한 응답을 서버가 클라이언트로 보내는 구조이다. 핸드셰이크는 HTTP 1.1 프로토콜을 사용하여 서버와 클라이언트가 요청과 응답을 보내는 것이다.

 

STOMP

 

 STOMP(Simple Text Oriented Messaging Protocol)은 메세징 전송을 효율적으로 하기 위해 탄생한 프로토콜이고, 기본적으로 pub / sub 구조로 되어있어 메세지를 전송하고 메세지를 받아 처리하는 부분이 확실히 정해져 있기 때문에 개발자 입장에서 명확하게 인지하고 개발할 수 있는 이점이 있다. 한 줄로 정의하자면, STOMP 프로토콜은 WebSocket 위에서 동작하는 프로토콜로써 클라이언트와 서버가 전송할 메세지의 유형, 형식, 내용들을 정의하는 매커니즘이다.

 스톰프는 양방향 네트워크 프로토콜을 기반으로 퍼블리셔와 서브스크라이버를 분리해 제공하는 메세징 기법이다. 배포자와 구독자로 나누어서 다수의 구독자에 메세지를 배포자가 뿌리는 형식이다.

 

 채팅방 생성 : pub / sub 구현을 위한 Topic이 생성됨

 

 채팅방 입장 : Topic 구독

 

채팅방에서 메세지를 송수신 : 해당 Topic으로 메세지를 송신(pub), 메세지를 수신(sub)

 

 클라이언트는 메세지를 전송하기 위해 SEND, SUBSCRIBE COMMAND 를 사용할 수 있다. 이 커맨드 요청 프레임에는 어떤 메세지와 누가 처리할지에 대한 정보가 헤더에 있다. 이 과정에 브로커를 통해 다른 사용자에게 메세지를 보낼 수 있다. Spring에서 지원하는 STOMP는 많은 기능을 하는데 예를 들어 Simple In-Memory Broker를 이용해 SUBSCRIBE 중인 다른 클라이언트들에게 메세지를 보내준다. Simple In Memory Broker는 클라이언트의 SUBSCRIBE 정보를 자체적으로 메모리에 유지한다.

 

구조적인 면을 보자면, 스프링은 메세지를 외부 Broker에게 전달하고, Broker는 WebSocket으로 연결된 클라이언트에게 메세지를 전달하는 구조가 되겠다. 이와 같은 구조 덕분에 HTTP 기반의 보안 설정과 공통된 검증 등을 적용할 수 있게 된다.

 

Spring framework 및 Spring Security는 STOMP 를 사용하여 WebSocket만 사용할 때보다 더 다채로운 모델링을 할 수 있다.

• Messaging Protocol을 만들고 메세지 형식을 커스터마이징 할 필요가 없다.
• RabbitMQ, ActiveMQ 같은 Message Broker를 이용해, Subscription(구독)을 관리하고 메세지를 브로드캐스팅할 수 있다.
• WebSocket 기반으로 각 Connection(연결)마다 WebSocketHandler를 구현하는 것 보다 @Controller 된 객체를 이용해 조직적으로 관리할 수 있다.
  • 즉, 메세지는 STOMP의 "destination" 헤더를 기반으로 @Controller 객체의 @MethodMapping 메서드로 라우팅 된다.
• STOMP의 "destination" 및 Message Type을 기반으로 메세지를 보호하기 위해 Spring Security를 사용할 수 있다.

출처: https://dev-gorany.tistory.com/235

[Spring Boot] WebSocket과 채팅 (3) - STOMP

3. TROUBLE SHOOTING

사실 아직까지 큰 트러블이 일어나서 난감한 상황을 겪지는 않았다. 기본적인 CRUD와 REST api는 지난 주차들을 통해 많은 경험을 했기 때문이 아닐까 싶다. 화상채팅의 경우 일대다의 방향이 정해졌기 때문에 OPENVIDU라는 오픈 소스를 이용할 것이고 메세징은 구현을 하고 있다. 필자의 조가 가장 문제로 꼽고 있는 문제는 방향성이다. 인프라 고도화를 하고 싶은데 그러기 위해서는 트래픽 계산을 해야하고 CICD 통합을 사용하고 싶은데 이러한 툴은 우분투 리눅스 서버 내에서 언어를 처리해야한다. 즉 지금은 공부해야하는 시기라고 생각한다. 하루에도 수많은 블로그를 넘나들으며 어떤 공부를 하고 어떤 걸 볼지 정해야한다. 이러한 공부 방법이나 방향성 문제는 풀리지 않는 숙제라고 생각된다. 다음주가 되면 멘토님 께서 주신 숙제들을 처리해야한다. 그러기 위해서 지금은 젠킨스를 공부 중에 있다. 추후에 인프라 고도화가 진행된다면 필자는 JPA로 작성한 것들을 queryDSL을 사용하고 리펙토링 하는 것이 목표이다.