# Practice Project
redis적용전과 적용후를 비교해보자.
Definition Access 문제 채팅과 관련하여 채팅방에 입장 할 때 이전 메세지를 불러오는 부분에서 Jpa Query Method로 DB의 채팅메시지를 저장하는 테이블을 조회하여 채팅메시지를 출력하였는데, RDB의 테이블을 조회하는 횟수가 많아지게 되면 서버에 부담이 많이 발생할 것이라는 생각과 함께 조회속도 또한 느려질 수 있다는 결론으로 조회방식에 대한 최적화를 고민함. 선택지 채팅메시지를 redis를 이용하여 cache memory에 저장하고 DB에도 저장 후 조회하는 방식 이유: Jpa Query Method를 사용하여 RDB에서 조회하는 방식보다 조회 속도 및 서버의 부담이 줄어든다는 것을 멘토님들과의 회의를 통해 알게 됨 결과 메세지를 저장할 때는 Redis와 DB에 같이 저장하고, 메세지를 조회할 경우에는 Redis Cache를 사용하는 로직 적용 후 테스트 결과 RDB에서 조회 하는 것 대비
최종 발표 (최종 주차 WIL)
(왜이렇게 시간이 비었지?) Week do list ⦁ 최종발표 준비및 마무리 Introduce 땅땅(ddangddang) 프로젝트 소개 https://github.com/DdangDdang5/Backend 중고 물품을 경매하는 사이트입니다. 나에게 소중했던 물품이 당신에게도 쓸모있는 물건이라면! 땅땅은 구매자와 판매자 사이에 합당한 가격에 땅땅에서 경매를 통해서 구매하자! 라는 생각에서 시작한 프로젝트입니다. 땅땅 서비스 들어가기 : https://www.ddangddang.world/ 땅땅 팀 노션 링크 들어가기 : https://typhoon-sphere-952.notion.site/6d35e88c83f74a48a069e2e5f093cf35
경매 입찰하기(실시간 가격변동)
Trouble Shooting 경매 입찰하기(실시간 가격변동) 문제 상세화면에서 경매 입찰 가격이 실시간으로 변하지 않는 문제 상세화면에서 경매 가격 입력해 입찰 시 제대로 반영되지 않는 문제(정확한 낙찰자 선정이 안됨) 원인파악 1번 문제에 관한 원인파악 a. 실시간 호가 입력 후 상세페이지에 접속해 있는 사용자들에게 전부 실시간으로 변경된 가격을 보여주어야 함. b. 가격 변동후 상세페이지에 입장하는 사람들 및 메인페이지에 접근하는 사용자에게도 변경된 가격을 보여주어야 함. 따라서 a의 경우에는 소켓을 사용하여 실시간으로 데이터를 주고 받아야 했고 b의 경우에는 해당 경매 게시글의 경매가를 실시간으로 사용자들이 제시한 가격을 저장하여 보여 주어야 한다.
JPA로 해당 경매 게시글 검색하기
TIL JPA란 이전글 : https://velog.io/@sago_mungcci/ORM-JPA-Spring-Data-JPA 해당 단어가 들어간 경매 게시글 검색 Jpa query method 참고 : https://goodgid.github.io/Spring-Data-JPA-QueryPart1/ <br
redis 메시지 직렬화 및 역직렬화 문제(2)
Trouble Shooting 문제 채팅메시지를 레디스에 저장시 저장이 안되고 아래와 같은 오류가 발생 채팅메시지를 Redis에 저장 시 저장이 안되는 오류 발생 오류내용 : org.springframework.data.redis.serializer.SerializationException: Cannot serialize; 채팅메시지를 레디스에 저장후 1:1 채팅방 및 경매 게시글 채팅방에서 나갔다 들어왔을때 아래의 오류 내용이 발생 채팅메시지 Redis 저장 후 1:1 채팅방에 입장후 퇴장 시 오류 발생 오류내용 : Java 8 date/time type java.time.LocalDateTime not supported by default 원인
1:1 채팅방 목록 조회 오류
Trouble Shooting 문제 1:1 채팅시 해당 사용자의 채팅방 목록이 아닌 전체 1:1채팅 목록이 출력되는 오류가 발생 원인 파악 각 1:1 채팅방의 메시지를 통해 1:1 채팅방을 전체 조회했음. 1:1 채팅방이라면 경매게시글 작성자와 낙찰자 2명만 존재해야 되는데 게시자와 낙찰자를 따로 구분해놓지 않았음. 따라서 경매게시자 닉네임으로 따로 채팅목록이 만들어져야 되고 낙찰자 닉네임로도 따로 채팅목록이 만들어져야 했음. 결국 경매게시자, 낙찰자 닉네임으로 1:1채팅방을 조회하면 해당 1:1 채팅방의 roomId에 해당하는 컬럼 전체를 조회해와서 roomid갯수만큼 채팅방 목록이 출력됨.
스프링 Java 8 LocalDateTime 직렬화 역직렬화 오류(1)
Trouble Access redis를 적용하던 도중 이런 오류가 발생했다. 이건 고민할 문제가 아니라고 판단하여 구글링을 진행하였다. Trouble Shooting Java 8 date/time type java.time.LocalDateTime not supported by default 라는 오류는 LocalDataTime을 역직렬화하지 못해서 생기는 오류이다. gradle에 아래와 같이 추가하고 해당 LocalDateTime이 있는 클래스에 가서 @JsonSerialize, @JsonDeserialize 어노테이션을 기입해줘야 한다. 그렇지 않으면 오류가 발생한다. (나는 Timestamped라는 클래스를 따로 만들어서 createdAt, modifiedAt을 상속해서 사용했다) Retrospection 정상적으로 작동한다.
실전 프로젝트 22, 23일 회고(10주차 WIL)
Week do list ⦁ 실시간 채팅 기능 구현 ⦁ 중간 발표 ⦁ 중간 발표 후 팀 회의 WIL(이번주까지 사용한 기술 회고) AWS EC2 서비스 배포 서버이다. 서비스 배포 서버를 AWS EC2를 선택한 이유는 배포의 경험을 해봐야 하기 때문이다. 배포의 경험이 없는 입문자인 우리에게 제공되는 정보가 많고 또한 AWS에서 제공해주는 EC2 뿐만아니라 RDS, S3버킷 redis, docker 등 AWS플랫폼을 이용하면 한번에 적용및 관리할 수 있다 무엇보다 1년 프리티어 무료부분이 너무 장점이었다.(잘못 사용하면 장점은 아니다.) 마지막으로 모니터링을 통해서 서버상태를 볼 수 잇다는 점도 우리에게 유리하다는 판단을 했다. 웹호스
실전 프로젝트 21일 회고
Today do list ⦁ 아 내일이 중간 발푠데 깃 푸시를 잘못해서 업데이트가 제대로 되지 않았다...... TIL ⦁ 아,....... Retrospection ⦁ 멘붕....... Tommorrow do list ⦁ 중간 발표
실전 프로젝트 20일 회고
Today do list ⦁ 경매 생성시 경매 채팅방 생성 ⦁ 상세 페이지 접근시 경매 채팅방 roomId반환 ⦁ 경매 채팅메시지 시간, 닉네임, 프로필이미지 반환 TIL 저장소에 관하여 채팅 시스템에서 데이터 계층을 올바르게 만드는 데는 노력이 필요하다. 중요한 것은 어떤 데이터베이스를 쓰느냐다. 관계형데이터베이스를 쓸것인가? 아니면 NoSQL을 사용 할 것인가이다. 이것을 선택할때 중요한 기준은 데이터의 유형과 읽기/쓰기 연산의 패턴이다. 채팅 시스템이 다루는 데이터는 보통 2가지다. 첫 번째는 사용자 프로파일, 설정, 친구 목록처럼 일반적인 데이터다. 이런 데이터는 안정성을 보장하는 관계형 데이터베이스에 보관한다. 다중화와 샤딩은 이런 데이터의 가용성과 규모의 확장성을 보증하기 위해 보편적으로 사용되는 기술이다. 두번째 유형의 데이터는 채팅 시스템에 고유한 데이터로, 바로 채팅 이력이다. 이 데이터를 어떻게 보관할지 결정하려
실전 프로젝트 19일 회고
Today do list ⦁ 경매 입찰 하기 기능 개발 ⦁ 다른 회원 조회시 해당 회원의 경매 리스트 추가하기 기능 개발 ⦁ 낙찰된 경우 1:1 채팅 로직 논의 Retrospection 낙찰된 경우 1:1 채팅 로직 논의 시작 오늘 낙찰된 경우 1:1 채팅 로직에 대해서 전체 회의시간에 논의 하던 도중 처음으로 약간의 논점이 달라졌다. 나의 경우 백앤드이기 때문에 request로 경매게시자와 낙찰자의 닉네임 혹은 memberid만 요청 받으면 낙찰자의 정보를 호가테이블에서 가져오지 않고 한번에 response해서 채팅방을 열고 낙찰자가 들어오는 로직을 완성할 수 있을것 같았다. 그러나 프런트쪽에서 그리고 애초에 와이어프레임을 봐도 경매 낙찰가는 있었지만 낙찰자에 대한 정보가 없어서 이것을 인지하지 못한 내 잘못이 컸다. 이부분은 호가 테이블을 통해서 가져올 수 있다고 하더라도 전체로직을 완성하기 위해서는 최종적으로 낙찰자가 해당
실전 프로젝트 18일 회고
Today do list ⦁ Stomp를 사용한 채팅 기본 레퍼런스 코드 분석및 동작원리 이해 TIL Stomp를 사용하여 채팅 기본 구조 이해하기. WebSocket 참고 : https://velog.io/@sago_mungcci/%EC%8B%A4%EC%A0%84-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-1415%EC%9D%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0 Spring과 함께 STOMP 메시징을 사용하여 채팅 기본 구조 이해해보자. Stomp STOMP : Simple Text Oriented Messaging Protocol Stomp는 메시징 전송을 효율적으로 하기 위해 나온 프로토콜이다. 기본적으로 pub/sub 구조로 되어있기때문에 메시지를 발송하고, 메시지를 받아 처리하는 부분이 명확하다. 개발과정에서 명확하게 인지하고 개발할 수 있다는 장점이있다. 또한 St
실전 프로젝트 17일 회고(9주차 WIL)
Week do list ⦁ PM님(멘토님)과의 미팅 ⦁ 채팅 기본 레퍼런스 코드분석 및 동작원리 이해 ⦁ isolation level 공부 ⦁ Jpa Query Method 공부 ⦁ Http 버전 공부 ⦁ P0~ P1 기능 완료 소셜로그인 검색기능 구현 WIL PM(멘토님)님께 질문한 것들 Q1. 채팅 테이블 관리 방법 채팅 대화를 테이블에 저장 시 1:1 채팅과 단체 채팅을 구분하여 채팅방 별 테이블을 나눠서 저장해야 하는지 아니면 하나의 테이블에 저장해서 관리해야할지 고민입니다. 그리고 둘중 어떤 방식으로도 테이블에 데이터를 저장한다면 테이블의 isolation level 수준을 어떻게 설정해야 할지 모르겠습니
실전 프로젝트 14,15일차 회고
Today do list ⦁ Websocket 공부 ⦁ Stomp 공부 ⦁ 채팅 기본 예제 공부. ⦁ 경매 카테고리 별 인기순 조회 ⦁ 경매 지역 별 인기순 조회 TIL WebSocket 소개 WebSocket 프로토콜은 표준된 방법으로 서버-클라이언트 간에 단일 TCP 커넥션을 이용해서 양방향 통신을 제공한다. 특징 기존의 다른 TCP 기반의 프로토콜과 다르게, WebSocket은 HTTP 요청 기반으로 Handshake 과정을 거쳐 커넥션을 생성한다. 덕분에, 초기 WebSocket Handshake 요청은 추가적인 방화벽 설정없이 80, 443 포트를 사용하여 양방향 통신이 가능하다. 뿐만 아니라, HTTP 규격 그대로 유지할 수 있기 때문에 HTTP 인증, CORS 등을 동일하게 적용할 수 있다는 장점이 있다. HTTP vs WebSocket WebSocket이 HTTP 요청을 시작되는 호환성을 가지고 있지
실전 프로젝트 13일차 회고 MySQL5Dialect?, MySQL8Dialect?
Today do list ⦁ 경매 전체 조회 페이지네이션 ⦁ 경매 카테고리별 조회 페이지네이션 ⦁ 경매 지역별 조회 페이지네이션 ⦁ 참여한, 찜한, 내가 생성한 경매 페이지네이션 ⦁ websocket 공부 ⦁ stomp 공부 Trouble Shooting 최초 문제 발생 A.클라이언트 상태 문제 없이 정상적인 request, response 실행 B. 서버상태 서버 시작시 기존 db 테이블의 drop시 drop이 안되는 오류가 발생함 그러나 정상적으로 서버가
실전 프로젝트 12일차 회고
Today do list Transaction isolation level 태그 기능 추가 및 해당 단어가 들어간 경매 게시글 검색. TIL WebSocket을 이용한 실시간 채팅을 구현하고 실시간으로 테이블을 조작하는 부분(호가 및 채팅 기록 저장)이 있어서 사용자 별로 정확한 데이터를 Response해 주고 싶었다. PM님께서 동시성 및 isolation level과 관련해서 테이블을 다루는 Transaction을 공부해보는 것이 좋을 것 같다는 말씀을 듣고 이렇게 정리 한다. Transaction 정의 : 하나의 논리적 기능을 정상적으로 수행하기 위한 작업의 기본 단위, 한꺼번에 모두 수행되어야 할 일련의 연산이다. --> 트랜잭션은 사용자로 하여금 자신이 정확한 데이터를 입출력 할 수 있다는 확신을 주게 하는 중요한 부분이다. 쿼리를 하나로 처리해서 만약 중간에 실행이 중단됐을 경우, 최종 커밋
실전 프로젝트 11일차 회고
Today do list http 1.0, 1.1 ,2.0, 3.0 공부 카카오 소셜 로그인 구현 TIL http 1.0, 1.1 ,2.0, 3.0 전체 HTTP/0.9 (1991년) HTTP/1.0 (1996년) HTTP/1.1 (1997년) : 가장 많이 사용중 HTTP/2.0 (2015년) : HTTP 1.1의 성능 개선 및 확장 HTTP/3.0 (진행중) 핵심 HTTP 1.1 이 모든것의 기반이기 때문에 잘 알고 그 다음에 2.0 / 3.0을 알아두면 좋다 추후 사용될 HTTP 3.0도 인지해두자 참고 : https://velog.io/@neity16/HTTP-HTTP-%EB%B2%84%EC%A0%84-%EB%B3%84-%ED%8A%B9%EC%A7%95 HTTP/0.9 (1991년) 처음 버전에는 버전 번호가 없어서 이후 버전과 구별하기 위해 나중에 0.9라고 불렀다.(1991년
실전 프로젝트 8,9일 회고(8주차 WIL)
Today do list 8일차 카테고리별 인기순 반환. 지역별 인기순 반환. 9일차 우리조 담당 PM님과 첫 미팅. 미팅 후 PM님께서 말씀해주신 부분 공부 중. PM님께 질문할 부분 정리해서 준비. TIL 8일차 TIL을 작성 못했던 이유 카테고리별 인기순 반환, 지역별 인기순 반환로직을 생각하고 작성할 때 내 로직이 잘못되어 데이터가 제대로 안들어감. 로직이 잘못됬다고 알게된게 새벽이었다. 8일차 TIL Trouble Shooting 최초 문제 발생 위의 메서드가 작동 될때마다 Cnt가 1씩 증가 되어야 하는데 2까지만 작동하고 2이상 카운트 되지 않음 문제 발생했을때 나의 로직. 상세
실전 프로젝트 7일 회고
Today do list 개인 분담 기능 단일 이미지 및 다중이미지 적용하기 경매 테이블 생성하기 경매 생성(다중이미지 적용함) 경매 수정(다중이미지 적용함) 경매 삭제 백앤드 팀원 분들이 겪은 트러블 슈팅 Https 적용해서 배포(오늘은 실패함) 로직 생각하기 TIL Trouble Shooting https를 담당한 부리더님께서 겪으셨던 부분을 내가 트러블 슈팅으로 같이 나누자고 졸라서 정리해주셨다. 최초 문제 발생 http를 적용하던 AWS EC2 인스턴스를 Https로 전환하던 도중 502 Gateway error와 정상적인 접근 2가지가 발생. A.클라이언트 상태 접근이 되다가 안되다가 반복함. 안정적인 접근이 불가함. B. 서버상태 서버도 굉장히 불안정함. c. 어플리케이션 정보 db와 Spring 서버 자체는 이상이 없음. http로 적용하면 정상작동함
실전 프로젝트 6일 회고
Today do list 오시영 튜터님 깃 라이브 세션 강의 수강 라이브 세션 후 깃 이슈 발행 및 백로그 관리 기능 개발 트러블 슈팅 : A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance TIL 오시영 튜터님 깃 라이브 세션 강의 수강 깃에 프로젝트를 올리면 read me를 잘 설명해야 된다. 개발자들은 프로젝트를 git readme에 설명을 한다. 깃 리드미 예시 https://github.com/siyoungoh/readme-template/tree/master/korean 노션 링크를 참조