실무에서의 복잡한 쿼리 결과 캐싱 전략(크기, TTL 등) 관련 질문

안녕하세요 지니님. 일단 좋은 질문 주셔서 감사합니다. 말씀해주신 사례를 들어보니, 아마도 조회 데이터의 결과값이 단건이 아니라 목록(list)였을것으로 생각됩니다. 단건 데이터가 아닌경우엔 일반적으로 캐싱처리하기에는 부적절하다고 생각합니다. 통상적으로 목록상의 데이터는 빈번히 변경될 여지가 있으므로, 보통은 단건의 데이터에 한해 캐싱처리를 한다고 보시면 됩니다. 다만, 말씀해주신 사례처럼 변경이 빈번하지 않을것으로 생각된다고 말씀하셨으니, 그 경우에는 전체 데이터가 아닌 핵심 데이터 요약결과 정도만 캐싱처리하는게 적절하다고 생각합니다. 이 경우에도 데이터의 변경가능성을 충분히 고려하여 캐싱처리를 해주셔야 할것 같습니다.

리프레시 토큰은 알아서 구현하면 되는건가요??

안녕하세요. 리프레시 토큰은 수업목적이 웹소켓이다보니, 시간관계상 자세하게 다루지 못하여 수업에서 별도로 구현하지 못했습니다. 코드자체가 크게 복잡하거나 어렵지 않은 부분이므로 레퍼런스 참고하여 구현해주시면 될것 같아요.

JWT 필터구현

안녕하세요~! 말씀해주신 질문의 요지가 GenericFilter와 OncePerRequestFilter 를 상속받는 방식에 있어서, 웹소켓 요청 관련하여 인증처리의 차이를 낳을수 있냐로 이해해도 될까요? 그 질문이 맞다면, 두 필터 방식중 어떤걸 사용한다 하더라도, 웹소켓 관련 모든 요청의 경우에는 permitAll로 흘려 보내고 StompHandler에서 인증처리하는게 옳습니다. 즉, 현재 코드와 동일한 방식으로 코딩해야 한다고 이해하시면 될것 같습니다.

자바 21로 소스 작성해도 되나요?

안녕하세요. 상위버전으로 하위버전프로그램은 일반적으로 잘 실행되나, 예외사항들이 있으므로 17버전으로 실행하는걸 권고드립니다.

레디스 서버 구성

안녕하세요. 일단 졸은 질문 주셔서 감사합니다. 당연히 실무에서는 redis를 다중구성에 복제까지 가능한 고가용성 설계로 진행합니다. 다만, 해당 수업에서는 수업의 본질적인 내용은 아니었기에 편의상 1대만 두고 진행했습니다. 다중의 redis를 두고 클러스터를 구성하는 작업은 인프라영역의 작업이고 실무에서는 담당 인프라 엔지니어가 있거나, aws elastic cache같은 클러스터 제공 서비스를 이용하기도 합니다. 감사합니다.

38강 질문입니다.

안녕하세요. 스키마를 따로 둔다고 하더라도 현재 수업에서 사용한 코드가 달라질건 yml파일외엔 없습니다. 애초에 테이블을 나눠서 프로그램을 설계했고, 수업목적의 편의상 같은 스키마를 쓰는 상황이라, 스키마 나누셔도 전혀 문제될것 없습니다.

메시지 브로커 선택에 관한 질문

안녕하세요. 먼저 좋은 질문 주셔서 감사합니다. 일단은 메시지브로커 목적으로는 redis와 카프카가 가장 많이 사용되는 만큼 2가지만 비교해서 1,2번 질문을 한꺼번에 대답해드리도록 하겠습니다. 먼저 redis는 인메모리 데이터베이스이고 메시지를 별도로 저장하지 않고 전파하기에 성능에 강점이 있습니다. 메시지브로커로서 지연없는 서비스를 위해서는 적절하다고 생각합니다. 다만, 단점으로는 메시지를 저장하지 않으므로 일시적인 채팅서버 장애시에는 메시지가 유실될 가능성이 있습니다. 이에반해 카프카는 일단 메시지를 자체 디스크에 저장을 합니다. 그래서 메시지 유실의 가능성이 크게 낮아집니다. 다만, 디스크기반에 메시지 저장 시스템을 갖추고 있다보니 성능에 단점이 있습니다. 그래서 결론은 채팅서비스의 성능이냐 메시지유실의 방지냐의 관점에서 2가지 중에 하나를 선택하시면 될것 같습니다. 저는, 채팅내용의 유실은 생각보다 흔하고 아주 크리티컬 하지는 않다고 생각하여 레디스를 도입하였지만, 안정적인 채팅서버를 구축하고 싶다면 카프카를 도입하셔도 될것 같습니다.

WebSocket과 Spring Security 질문

맞습니다. filterchain은 http요청에 대한 인증처리를 하므로, 웹소켓 커넥트 요청의 경우에는 http요청이 아니기에 처리가 불가합니다. 그래서 모든 연결요청을 permit으로 풀어주고 웹소켓 핸들러에서 인증처리를합니다.

코드 살펴보던 중에 발견한 것

안녕하세요~! 지금 보니까 일관성 없이 id가 아닌 email로 넣은것 같습니다. 다만, email을 넣든 id를 넣든 refresh토큰에서는 전혀 문제될것 같지 않습니다. refresh토큰의 목적은 rt를 통해 at를 발급하는 것이라, rt안에 사용자를 구분지을수 있는 unique한 값만 있으면 돼서 email과 id 모두가 가능합니다. at는 각 서버에서 token안에 id값을 지속적으로 사용하고 있기 때문에 id를 토큰에 넣었던 것인데, rt도 id를 넣어두는게 더 일관성 있을것 같습니다!!

추가 커스텀 구현 질문 있습니다.

안녕하세요~안 읽은 메시지의 숫자가 실시간으로 변화돼야 한다면, 매우 빈번하게 통신을 해야 하니 채팅을 하는것과 동일하게 웹소켓 connect를 통한 실시간통신을 활용하는게 좋을것 같습니다.