Week do list
⦁ PM님(멘토님)과의 미팅
⦁ 채팅 기본 레퍼런스 코드분석 및 동작원리 이해
⦁ isolation level 공부
⦁ Jpa Query Method 공부
⦁ Http 버전 공부
⦁ P0~ P1 기능 완료
- 소셜로그인
- 검색기능 구현
WIL
PM(멘토님)님께 질문한 것들
Q1. 채팅 테이블 관리 방법
채팅 대화를 테이블에 저장 시 1:1 채팅과 단체 채팅을 구분하여 채팅방 별 테이블을 나눠서 저장해야 하는지 아니면 하나의 테이블에 저장해서 관리해야할지 고민입니다.
그리고 둘중 어떤 방식으로도 테이블에 데이터를 저장한다면 테이블의 isolation level 수준을 어떻게 설정해야 할지 모르겠습니다.
마찬가지로 호가 등 실시간으로 변동하는 데이터를 제어하기 위해서 auction 테이블을 isolation level 3을 default라고 생각하고 개발을 진행하려고 합니다.
이유는 첫번째로는 Transation의 ACID 원칙에 기반한 Isolation에 관한 중요한 개념이기 때문입니다. 즉, 사용자가 입력한 데이터를 정확하게 요청 및 응답 할 수 있어야 되기 때문입니다.
두번째로는 isolation level이 0 --> 3으로 상승할수록 속도가 저하되지만, 안정성이 높다는 판단 때문이었습니다.(Dirty read, Phantom read 방지)
저희의 진행하려고 하는 방향성이 합리적 혹은 보시기에 효율적인지 여쭤보고 싶습니다.
마지막으로 스프링에서 isolation level를 직접 적용할 수 있는 어노테이션이 있는지 궁금합니다.
또 어노테이션이 없다면 isolation level에 맞게 저희가 제어해야 하는지 궁금합니다.
A1.(답변 해주신 부분)
-
아주 좋은 질문입니다. 대단히 좋은 질문입니다.(우리 팀원 모두 ?!?!?!?함.) 일단 위와 같이 테이블을 나누게 된 경위가 무엇입니까?
-
만약 DB를 사용하게 된다면 일단 채팅이라는 기술 특성상 ws를 이용해서 실시간으로 데이터를 DB에 적재해야 된다고 판단했습니다.
-
특히 실시간으로 진행되는 경매라는 특성과 사용자의 동시성을 요구하는 채팅의 특성이라는 2가지 특징 때문에 db에 저장하는 것이 합리적이라고 판단했습니다.
-
좀 더 자세히 말씀드리면 사용자가 실시간 호가를 입력할때 ws의 장애로 인한 병목현상(렉)이 발생하여 실시간으로 호가를 반영해 주지 못하거나 서버 자체의 오류로 인해 이전의 실시간 호가 채팅이 사라진다면 경매라는 저희 서비스에 치명적인 손해가 발생할 수 있기때문입니다.
-
따라서 이러한 점을 방지하기위해서 백앤드 쪽에서 할 수 있는 일은 최소한의 서버에 부담을 주기 위함으로 이렇게 테이블을 나누게 된 것입니다.
-
그러나 하나의 테이블에 전체 채팅방의 목록이나 채팅내용을 저장하게 되면 테이블을 조회하는 시간은 빠르나 하나의 테이블이 사용자들이 채팅을 하는 수많큼 조회되거나 수정이 될 것으로 예상되고
-
각 테이블을 채팅방별로 나누게 되면 많은 양의 테이블이 생성되지만 그만큼 조회되는 부분이 적을 것 같습니다. 반면 해당 테이블을 찾는데 시간이 소요 될 것 같습니다.
-
-
그렇습니다. 제가 말씀 드리고 싶은 부분이 바로 어떤 서비스냐에 따라서 테이블 구조가 바뀌거나 개발자들이 회의를 해서 선택해야 된다는 것입니다. 이것은 전적으로 개발자들의 몫이고 특히 현업에서는 이런 부분에서 많은 회의를 하게 될 것입니다.
-
지금 땅땅이라는 서비스가 초기단계라고 생각해봅시다.
그렇다면 생각보다 많은 사람들이 땅땅서비스를 사용하고 있지는 않을 것이고 사고뭉치팀분들께서는 어떤 테이블 구조를 사용하시든 속도에 관해서는 문제없이 서비스를 하실 수 있습니다.
단, 사용자의 실시간 요청 및 응답을 정확하게 해주어야 합니다. 필수입니다. 따라서 지금(실전 프로젝트기간)은 어떤 테이블 구조든 isolation level을 3으로 개발을 진행해주셔도 무방하다고 판단이 됩니다.(권장합니다) -
그러나 인기가 많아져서 수만명의 사용자들이 땅땅이라는 서비스를 사용한다고 가정해봅시다. 이때는 쿼리문 한번 한번이 회사의 경제에 영향을 주게 됩니다. 그러나 실제로 이정도의 사용자를 감당하려면 많은 서버가 필요합니다. 즉 서버의 갯수가 곧 회사의 경제와 연결되는 겁니다. 이때 각 쿼리문이 서버에 어떤 영향을 줄지 한번 생각해보시고 공부해보시면 좋을 것 같습니다.
-
여튼 이렇게 많은 사용자가 서비스를 사용하면 굳이 isolation 3 level을 지켜가면서 할 필요가 없다. 왜냐하면 우리는 db에 적재되는 것을 순서대로 읽어오게 만들어도 되지 않을까요?.(단 아예 isolation 3 level을 배제하라고 말씀드리는 것은 절대 아닙니다.) 즉 채팅 테이블에 해당 관련 로그를 함께 저장해서 같이 불러오면 될것입니다.
(사실 이부분은 이해가 잘 안되었다. 내가 잘못 필기한 거 일 수 있다. 좀 더 공부해 볼 부분 나중에 이부분 관련해서 TIL 작성하기!!!!!!) -
따라서 정리하면 지금의 테이블 구조 자체로는 db에서 속도문제는 크게 발생하지 않을 가능성이 높습니다. 다만 서비스의 중장기적으로 보았을때는 차라리 채팅방마다 테이블을 만드는 것 보다, 채팅방과 채팅메시지 둘로 만들어서 로그를 만드는 방식을 권장합니다. 그러나 테이블 구조와는 별개로 반드시 바로 아래에 말씀드릴 트랜잭션을 제어해서 반드시 사용자의 요청,응답을 실시간으로 정확하게 제공할 수 있어야 합니다.(이것이 우리 서비스의 가장 중요한 부분이기때문입니다.)
-
어노테이션은 @Transactional로 이용해서 Transaction을 제어 할 수 있습니다.
Q2. 저희 프로젝트에 HTTP 2.0을 적용해야 하는지?
저희가 공부한 내용으로는 이러한 점이 있었는데
성능상 HTTP 1.0보다 2.0이 좋다고 알고 있는데 속도적인 면 뿐만아니라 메모리적인 면에도 더 효율적인지 궁금합니다.
A2.(답변 해주신 부분)
-
공부하셨다 싶이 HTTP 1.0, 1.1은 계속 request, response handshaking이 이루어지고 HTTP 2.0은 session이 한번 열리면 계속적으로 Streaming과 같이 통신이 이루어진다는 점이 큰 차이점입니다.
다만 제가 알기로는 속도적인면 뿐만아니라 메모리적인 면 더나아가서 네트워크 부분에서 미미한 차이가 있을 겁니다. -
이부분은 프로젝트 즉 서비스하려는 방향성에 맞추어서 여러분이 선택하면 될 것입니다. 굳이 2.0을 사용해야 될까요?
-
그러나 백앤드 분들은 이 프로젝트가 끝나고 GraphQL과 gRPC는 공부해 보는 것이 좋습니다.
-
특히 gRPC와 같은 경우에는 http2.0을 사용해야 되는 제약이 있습니다.
Q3.kafka, 루아스크립트
어떻게 적용해야 하는지 잘 모르겠습니다.
전반적인 작동 방식을 검색을 해도 잘 모르겠습니다.
A3.(답변 해주신 부분)
-
제가 지난주에 말씀드렸던 kafka, 루아스크립트는 isolation 3이 중요다고 말씀드리면서 0.000000000001초의 임팩트가 크기 때문에 속도를 높이기 위해서 memory 기반의 db를 사용한다고 말씀드렸었습니다. 그중 하나가 redis이고 isolation의 개념이 아닌 single thread를 사용하면서 유저 task를 처리하면 tracsation을 신경쓸 필요가 없습니다.
-
single thread로 작업을 진행하는 언어중에 하나가 루아입니다. 루아스크립트를 통해서 redis로 접속을 하면 redis가 가지고 있는 transaction을 다 신경 안써도 된다. single thread로 다처리하기 때문이죠.
-
즉 single thread를 제어하는 루아스크립트가 100만명의 요구사항을 다 처리할 것입니다.
- 사고뭉치 : 우와~(실제로 이렇게 나도 모르게 말함. 그게 가능하다고? 이런뜻이었음)
-
카프카와 루아스크립트를 말씀드렸던 것은 이렇게 사용하라고 했던 것은 아니었고 루아스크립트와 레디스 이렇게 권장한다는 것을 말씀드립니다.
Q4.redis의 필요성
WebSocket과 STOMP를 이용하여 채팅 기능을 구현하고 메세지와 채팅방 정보를 DB에 저장하게 되는데 그 과정에서 redis의 필요성을 못 느끼겠습니다. 단순히 성능 향상의 이유일까요??
A4.(답변 해주신 부분)
-위의 내용과 겹치는 부분이 많아서 Q3부분을 좀더 생각해고 공부해보시면 될 것 같습니다.
Q5 PM님(멘토님)이 생각하시는 처음 “Backend” 공부 할 때 공부할 때의 우선순위와 로드맵을 알려주세요 (본인이 공부하면서 어떠한 부분에서 어떠한 감정을 느끼며 공부했는지도 궁금합니다)
A5.(답변 해주신 부분)
-
스프링을 사용하고 있으신데 스프링의 구조가 어떻게 되는지 예를들면 request가 오고 response가는 것에 대한 부분과 dispather servlet이 어떤 것이고 frontController가 무엇이고 servelet은 어떻게 관리되고 filter intercepter는 어떻게 관리되고 하는 것등을 공부하는 것이 중요합니다.
-
하지만 스프링에서 추상화 되어있는 것들을 하나씩 하나씩 낱낱이 파헤쳐 보는 것을 가장 추천합니다.
-
그이유는 java Spring framework, python jango flask, react next js 등 이런 프레워크들이 구조가 다 정말 비슷하다.
-
웹개발 프레임워크는 웹개발자에게 웹개발에 필요한 모든 것들을 너에게 줄게 너가 알아서 해 이런 의미이다. 그렇기때문에 공통된 부분들이 정말 많아서 스프링에 대한 학습만 제대로 해도 다른 프레임워크를 사용하는데 아 이프레임워크의 이것은 스프링의 이런 개념이구나 이런식으로 쉽게할 수 있다.
-
여러분이 어디에 취업하실지는 모르겠지만, 스타트업 같은 경우에는 MSA구조가 아니라 Monolithic일 것일 확률이 높지만, MSA를 사용하는 곳에 취업하시게 되면 카프카, 루아스크립트 결국에는 infraStructure를 고민하게 되는 시점까지 오게 된다.
Retrospection
와 진짜 말이 안나옴. 매주 느끼는 것이지만, 나는 진짜 주니어도 못되는 것 같다.
- 이때까지 뭐했지? 진짜.. 갈길이 너무 멀다.......
Next Week do list
-
Stomp를 사용한 채팅 레퍼런스 코드 분석및 동작원리 이해
-
GraphQL vs REST vs gRPC - 작업에 적합한 프로토콜 선택
https://giljae.com/2022/08/05/Restful-vs-gRPC-vs-GraphQL.html -
[Spring Cloud] Monolithic? MSA? 개념과 차이점을 알아보자
https://mangchhe.github.io/springcloud/2021/02/21/MSAConcept/
공부해서 정리하기.
