jpa entity 질문

안녕하세요 HAHA님 핵심을 잘 찌르는 질문 주셔서 감사합니다.사실 이 주제는 저도 아니만 같이 강의를 만드시는 분들 입장에서도 꽤나 주제가 많이 갈리는 주제였습니다.개발의 편의성이 중요하냐, 아니면 기본적인 규칙을 맞추는것이 중요하냐의 문제로 논쟁거리가 많았던 주제이기도 합니다. 하지만 상황에 따라서 조금 달라 질 수 있는 부분이 존재 할 꺼 같아요. data class 선언시 프록시 질문맞습니다. 지연로딩이라는 것이 프록시를 통하고 불변 객체를 통해 구동이 된다면, 정상 동작하지 않을 수 있죠. 그래서 일반적인 class가 권장됩니다. 하지만 상황에 따라서 kotlin-allopen 플러그인을 사용한다면, @Entity가 붙은 객체를 open 상태로 변경해주는 기능도 동작 가능합니다. 이런 플러그인도 고려해 보시면 좋지 않을까 싶어요. 이 부분에서 많이 갈리는게, 프로젝트를 data class로만 구성하고 싶어하시는 분들이 많습니다. 저도 어느정도 공감하는 부분도 많아서... class나 data class냐는 꽤나 논쟁거리가 있는거 같아요. Data class 사용 시 equals & hashCode이 부분도 질문해 주신 부분이 맞죠. 기본적인 id만을 비교 하는것이 성능과 안정성 면에서 좋습니다.왜냐하면 Entity가 영속되지 않은 상태(transient)일 때나, 지연 로딩된 필드가 로드되지 않았을 때 전체 필드로 비교하면 오동작할 수 있다는 문제가 있기 떄문입니다.그래서 class를 사용하는것이 더 유리하기도 합니다면.. data class를 사용하는 경우에 대해서는 오버라이딩 하는 표현식이 필요합니다.저는 그냥 이런 부분까지는 고려를 잘 안하는 스타일이라서... 그냥 작성을 하기는 했습니다.data class User(@Id val id: Long, var name: String) { override fun equals(other: Any?): Boolean { if (this === other) return true if (javaClass != other?.javaClass) return false other as User return id == other.id } override fun hashCode(): Int = id.hashCode() }간단하게 작성해보았는데, 이런 형태이지 않을까 싶습니다. data class 목적사실 저는 data class라는 표현을 사용하는것을 좋아해서 해당 형태로 모두 구현한 부분이기는 합니다. 당연하게도 정석적인 코어 레벨로 구현을 한다면, class가 좀 더 entity에 어울리는것은 사실이기도 하고요. 하지만 kotlin의 문법을 최대한 알려드리고 싶어서 data class로 모두 사용을 하였고, 일반적으로는 response에만 많이 사용하거나, 중간 DTO 모델 정도에만 많이 사용되는것이 data class의 사용처이죠하지만 일부 Entity에도 사용 할 수 있어요. 누군가에게는 그렇게 권장하지 않는 형태라고도 할 수 있겠지만, 저는 그렇게 규격에 얽메이는 것을 싫어해서... 예를들면 val대신 var로 구성 함으로써 내부 변수를 수정 가능한 형태로 구성하는 것이죠. equlas 질문말씀해 주신 부분이 맞죠. 예를들어 이런 형태가 있다고 가정해 볼게요.class Team( val members: List ) class Member( val team: Team )그러면 자동 생성된 함수들에 대해서는 양방향 참조가 발생 가능합니다.그래서 이런 형태에서는 ID만을 통해 검증을 하던가, ToString.Exclude, @EqualsAndHashCode.Exclude 이라는 형태도 사용하기는 합니다. 이 부분도 알아가시면 좋은데, 이렇게 처리하는것은 사실 떔빵?? 한다는 느낌에 가까워서 기본적으로는 구현체 함수를 오버라이딩 하는것이 편하실 겁니다. 결론적으로 말씀드리자면, 전체적으로 class가 Entity에 더 맞지 않냐?? 라는 생각은 맞습니다. 틀린 생각은 아니에요. 개인적으로 data class가 더 편하다고 생각하여 구성을 하였고, JPA와 호환성을 위해서는 플러그인이나 추가적인 오버라이딩이 필요하죠. 그래서 만약 불변을 강조하거나 간단한 프로젝트 이 강의와 같이 간단한 형태라면, data class가 구현하기에는 더 편하실 겁니다. 하지만 뭔가 복잡한 관계가 주어지는 프로젝트라면 일반적인 class를 추천 드리고 싶어요. 이런 내용도 강의에 녹아 드렸어야 했는데, 너무 제가 제 스타일로만 알려드리고 작성한거 같아서 너무 부끄러워지는 주제였던거 같습니다. 이렇게 정성스럽게 질문 주셔서 너무 감사드립니다.

SSD가 메모리인가요?

안녕하세요 누피님 질문 주셔서 감사합니다.엄밀히 말하면 메모리가 아니라 저장 장치이죠. 아무래도 메모리처럼 빠르게 접근 가능하다는 표현이 좀 혼용이 된거 같습니다. 둘은 다른 역할을 수행합니다. 감사합니다.

Circuit Breaker 질문

안녕하세요 HAHA님 질문 주셔서 감사합니다.말씀해주신것처럼 해당 패턴은 단일 인스턴스에서만 유효한 패턴입니다. 하지만 전체 인스턴스 상황을 가정한다면 중간에 이 값을 저장하고 관리 할 주체를 두면 좋겠죠 보통은 그래서 중앙화된 저장소로 Redis를 사용합니다. 싱글 스레드이기도 하기 떄문에 다중 인스턴스 상황에서 중앙 관리 주체로 사용하기에 용이한 형태가 될 것이고, 영구적으로 보관해야 할 데이터도 아니기 떄문에 캐시 데이터를 사용해도 무방하겠죠. 이렇게 답변 드리면 될꺼 같아요. 감사합니다.

HikariCP maxLifetime 가 db 부하에 주는 영향

안녕하세요 부릉부릉님 질문 주셔서 감사합니다.개인적인 생각으로는 연관이 되어 있을꺼같아요. maxLifeTime이 결국 커넥션이 풀에서 살아 있을 수 있는 최대 시간을 의미하게 되는데, 이 시간이 지나게 된다면, 새로운 커넥션을 만들어서 교체하는 작업이 일어나게 될 겁니다. 현재 상황을 예시로 들어보자면 30초로 설정이 되어 있다니, 풀 안의 모든 커넥션이 30초마다 교체가 되는 것이죠 또한 pod당 50개씩 구성이 되어 있으니 총 커넥션은 250개가 되겠네요. 이 상황에서 250개의 커넥션이 30초 주기마다 대량으로 폐기 되기 떄문에 안정된 커넥션 풀이라기보다는 일종의 팩토리같은 같은 상태가 되는게 아닐까 싶습니다. 커넥션을 재연결하는 과정도 결국 DB에 대한 요청이고, 애플리케이션에서 이 주기에 대해서 잠시 커넥션 부족 상태가 가능할꺼 같아서 결국 풀에 대한 고갈과 같은 현상이 발생할꺼 같다는 생각이 드네요.물론 상황마다 일부 다른 부분은 있겠죠 그래서 30초라는 주기가 pool 고갈의 원인일 될 가능성이 일부 있지 않을까 싶습니다.

섹션8. CAP 퀴즈 질문

안녕하세요 메웅교농베님 질문 주셔서 감사합니다.먼저 질문에 대한 답의 기준은 CAP 이론이 무엇인지 알고 있다는 것을 가정해보도록 할게요. 질문에 대한 어떤 답을 하셨는지도 궁금하네요 ㅎㅎ 우선 MOngoDB는 레플리카를 기본적으로 구성합니다. 즉 네트워크 분할이 발생한다면 과반수 정책을 통해서 주요 노드 즉 Primary Node를 정하게 되는 것이죠. 그리고 선정되지 못한 노드들은 Write에 사용이되지 않고 트래픽을 분산하고자 하는 READ용 데이터 베이스로 구성이 될 겁니다. 아니면 복제와 고가용성을 위한 노드로써 유지가 되겠죠그리고 이떄 읽기 요청은 설정에 따라서 세컨더리를 통해서 읽을 수도 있을겁니다. 그래서 이러한 관점에서 보았을 떄, 저는 일관성 보장을 위해서 일부 가용성을 희생하는 구조라는 생각이 드네요. 왜냐하면 우선적으로 일관성을 유지하기 떄문입니다. 과반수의 합의가 없다면 쓰기 작업을 진행하지 않기 떄문이고네트워크 분할상황에서도 시스템이 동작한다는 내성을 가지고 있따고 생각해요.또한 소수 그룹에 속한 노드 즉 Primary Node가 아닌 노드들은 쓰기가 불가능하기 떄문에 가용성을 일부 희생하지 않나라는 생각이 듭니다.그래서 최종적으로 CP 성향을 가진 DB라고 생각합니다.

레디스 활용에 대해서 질문드립니다!

안녕하세요 dt10002님 질문 주셔서 감사합니다.결론적으로 말씀드리자면 거의 없습니다. 아마 한번도 안치실 수도 있어요. 왜냐하면 redis-cli를 굳이 사용하지 않아도 정보를 볼 수 있는 GUI툴들이 있기 떄문입니다.redisInsight 물론 redis-cli를 통해서 데이터를 추가해야한다면, 사용하시기도 하겠지만, 거의 다 데이터를 확인하거나 삭제하는 부분이 많기 떄문에 redis-cli를 직접적으로 활용하시는 케이스는 거의 없다고 봐주시면 됩니다. 감사합니다 :)

자바 17로 하셨던데 21로 해도 되나요?

듣는데에는 큰 무리가 없고 사용하시는데에 있어서는 큰 차이가 없을꺼 같기는 합니다만. 버전에 따른 만약 차이가 일부 발생할수는 있을꺼 같습니다. 17버전과 21버전 사이의 차이를 이 과정에서 모두 핸들링하고 고려하며 추적하기에는 무리가 있을꺼 같아서요.

stomp websocket

https://inf.run/wGCRE해당 질문과 동일하기 떄문에 해당 질문을 참고 부탁드릴게요!!

웹소캣 stomp

안녕하세요 김옥윤님 질문 주셔서 감사합니다!!비슷한 질문을 두개해주신거 같아서 그냥 이 글에 한번에 설명드리도록 할게요.https://inf.run/wHVus 자 일단 둘다 질문주신 부분에 대해서 정답을 내리기는 너무 추상적인 질문이라고 생각이 듭니다. 특정 다르게 코딩만 한다는것이 기준이 어디까지인지, ChatWebSocketHandler만 수정하신다는게 뭔지 이거는 사실 너무 제가 어떤 기준으로 판단하고 설명을 드려야 하는지 판단하기에는 애매한거 같아요. 그래서 그냥 범용적으로 STOMP를 사용 했을 떄의 코드를 일부 보여드리면 좋지 않을까라는 생각을 하였습니다. 일반적으로 우리가 STOMP를 사용한다면, 이런 코드를 구현하시면 됩니다.import org.springframework.context.annotation.Configuration; import org.springframework.messaging.simp.config.MessageBrokerRegistry; import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker; import org.springframework.web.socket.config.annotation.StompEndpointRegistry; import org.springframework.web.socket.config.annotation.WebSocketMessageBrokerConfigurer; @Configuration @EnableWebSocketMessageBroker public class WssConfig implements WebSocketMessageBrokerConfigurer { @Override public void configureMessageBroker(MessageBrokerRegistry registry ){ registry.enableSimpleBroker("/sub"); registry.setApplicationDestinationPrefixes("/pub"); } @Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint("/ws-stomp").setAllowedOrigins("*"); } }엔트포인트와 prefix를 저장해줌으로써 Client와 연결 할 수 있는 통로를 지정해 줍니다. import org.springframework.messaging.handler.annotation.DestinationVariable; import org.springframework.messaging.handler.annotation.MessageMapping; import org.springframework.messaging.handler.annotation.SendTo; import org.springframework.stereotype.Controller; import com.example.demo.domain.chat.model.Message; import com.example.demo.domain.chat.service.ChatService; import com.example.demo.domain.repository.ChatRepository; import com.example.demo.domain.repository.types.Chat; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import java.sql.Timestamp; @RequiredArgsConstructor @Controller @Slf4j public class WssControllerV1 { private final ChatService chatService; @MessageMapping("/chat/message/{from}") @SendTo("/sub/chat") public Message sendMessage( @DestinationVariable String from, Message msg ) { return msg; } }그후 그냥 웹소켓 통신해주시면 됩니다. 들어오는 요청에 대해서 이제 어떤 경로로 또 전송을 해줄지에 대해서도 추가로 맵핑해주면 된다고 보시면 됩니다. 이 코드는 어디까지나 예시라고 봐주시면 될 꺼 같아요. 그래서 추가적인 미들웨어나 부수적으로 구현하고자 하는 기능은 여기에서 살을 붙이는 형태라고 봐주시면 될 꺼같습니다. 질문주신것처럼 당연히 다르게 작성을 해주셔야하고, 기본적으로 형태가 일부 다릅니다. 개념도 좀 다른 부분이 있어서 그 부분을 참고해주시면 좋을꺼 같아요. 감사합니다 :)

이벤트 기반 주문 질문 있습니다.

안녕하세요 qheogus55님 질문 남겨주셔서 감사합니다.이 부분은 어떤 기능을 EDA 아키텍처를 도입해서 사용할지를 정해야 하는거 같아요. 말씀해주신 부분처럼 사용자 경험 관점에서는 당연히 동기식이 더 직관적입니다. 실패인지 성공인지 알 수 있기 때문이에요. 하지만 상황에 따라서 일부 처리를 EDA 기반의 아키텍처로 뺼수도 있겠죠 예를들어서 사용자가 성공했다는 행위를 쿠폰 발급까지만 진행하고, 쿠폰 발급에 대힌 메일 전송과 같은 기능은 이벤트화해서 처리하거나 이런식으로 시간이 오래 소요 될 수 있는 행위에 대해서는 이벤트화 하는것이 좋습니다. EDA 기반의 아키텍처에서 가장 큰 문제가 될 수 있는 부분이 말씀해주신 재고와 관련된 서비스 입니다.그래서 간단하게 해결을 하자면1. 재고 확인 2. 확인 후 문제가 없다면, 이벤트를 전송 (이떄 해야하는 작업이 많겠죠) 3. 특정 이벤트 작업 후 재고 처리 3.1 에러가 발생하면 복구 트랜잭션 발행 3.2 아니면 성공하는 이벤트들에 대해서 추가적으로 수집하여 전체적인 총괄 처리이런식으로 해결하는것이 일반적인 패턴입니다.그래서 이런 구현에 대해서 Saga 패턴도 고민해 보시면 좋을꺼같아요. 질문에 대한 답변이 되었으면 좋겠네요. 혹시 추가적인 질문 있다면 남겨주세요!! 감사합니다 :)