#7

 

 

 

지난 주는 공식문서의 Start Guide를 참고해 웹소켓 채팅을 구현하는데 중점을 뒀다

 

https://spring.io/guides/gs/messaging-stomp-websocket/

Using WebSocket to build an interactive web application

 

여기를 참고해 받아오는 메세지에 JWT 액세스 토큰을 멤버변수로 첨가해

 

접속한 유저가 로그인한 유저인지 판별해 토큰을 JWTS로 디코딩해서 payload에서 해당 유저의 닉네임을 뽑아내

 

메세지를 Response 하는 시간에 맞춰 LocalDateTime을 줌으로써

 

실시간 채팅을 구현하는 작업을 했는데 나름 재밌었다

 

다음에 하게되면 WebRTC를 구현해 볼 생각인데 언제가 될지 모르겠지만 재밌는 작업이 될 것 같다

 

조금 아쉬운 점이라면 HttpServlet를 extends해서 Request에 AccessToken을 cookie로 실어보내는 방식으로 진행할 수도 있었을텐데, 아직 프론트와의 협업이 익숙하지 않다거나 배우지 않았다는 문제로 익숙한 방식을 사용해 채팅 메세지가 날아 갈 때마다 매번 토큰을 함께 실어나르는 부분이 영 탐탁치 않았다

 

애초에 채팅룸 입장(POST) 시 한번 쿠키에 구워서 보내고 프론트에서 쿠키에서 꺼내거나 로컬스토리지에 저장해 지속적으로 실시간 채팅룸에 뿌리는 방식이 효율적으로 보였지만, 무리한 부탁이 될 수 있는 일을 하기는 어려웠다

 

차라리 서버에서 매 요청시마다 토큰을 분해해 메세지 작성 시간과 함께 메세지 및 유저 정보를 보내주는 게 협업하는 분들에게 프로젝트를 유지할 수 있는 난이도로 스트레스를 받지않고 넘어갈 수 있다는 생각이 들었다

 

그러다보니 물론 구현력도 중요하긴 하나 Perfomance적인 측면에서 스프링을 사용할 때 어떻게 더 빠르게, 더 정확하고 안전하게 코딩을 할 수 있을까 하는 생각이 미치고 있다

 

언제까지고 꼴랑 데이터 수십 수백개짜리 작업만을 해서는 현업에서 유저들을 대상으로 사용되는 서비스의 작업을 맡을 수는 없다고 생각했기 때문이다. 당연한 얘기지만 역지사지로 생각해서 내가 시니어 개발자라고 가정해도 이런 신입한테는 일을 맡기지 않겠다

 

회사가 유지되려면 상품에 상업성이 있어야하고 상업성은 필연적으로 빅데이터를 생산해내니, 스타트업만 전전하거나 프리랜서로 용역만 하다 살다 죽을 게 아니라면, 빅데이터를 핸들링하는 기술이 기술자로써의 효용적 가치를 생산해낸다는 생각이 들었다

 

그래서- 엘라스틱 서치 보고 있다

 

레디스 사용법도 대충 알았고, 토큰 등 휘발성 데이터를 다루는 데에는 인메모리 방식의 레디스를 부분적으로 도입하는 게 더 퍼포먼스 측면에서 나은 방향이라는 것도 깨달았다

 

성능에 중점을 두고 생각을 이어가다 보니 필수 불가결한 AOP로 StopWatch 등의 어노테이션을 커스텀해서 사용하는 방식들도 자연스럽게 습득하고 있다

 

콘솔 등에서 어질어질할 정도로 날려대는 select, delete, insert 등의 1+n 문제도 어떻게하면 batch insert 등의 batchSize 설정을 통해 한방 쿼리로 만들어 로딩시간을 줄일까 실험해보고 있고, HikariCP로 쓰레드풀 설정도 깔짝여보고, mySQL 등의 RDBMS에서 JDBC 규격에 따라 이루어지는 체번 방식을 변경함으로써 얻어지는 퍼포먼스적인 측면을 테스트해 보고 있다

(체번을 위해 쿼리를 두번 날리게 되므로 ID를 pooled-lo optimizer generator 방식으로 미리 만들거나 그런 짓을 해보고 있음)

 

결과적으로  Jpql이나 QueryDSL 방향 쪽으로 나아가고 있긴한데 아마 JDBC까지 원시적으로 SEQ 날리는 방향까지 원점회귀 하듯 파고들어갈 것 같다

(여윽시 튜닝의 끝은 바닐라지)

 

암튼 귀여운 똘똘이 보고가셈

 

어헝 기여어