Kotlin data class 엔티티에서 copy로 수정 후 save하는 이유가 있을까요?

안녕하세요 심재경님 질문 주셔서 감사합니다. 혹시 어떤 영상을 보시고 질문을 해주셨는지 알 수 있을까요?? 구체적인 코드를 확인하고 내용을 확인하면 답변드리는데 더 큰 도움이 될 꺼 같습니다.

엔티티는 Data Class로 작성하면 안되나요?

안녕하세요 최현민님 질문 주셔서 감사합니다. 비슷한 형태로 좋은 질문 해주신 분이 있고 그에따라서 답변을 한 케이스가 있어서 해당 질문을 참고해 보시면 좋을 꺼 같습니다. https://inf.run/GHA8N 그리고 compainon object, object는 기본적으로 Spring Boot를 통해서 무언가 상태를 관리하지 않을 떄 사용하는게 좋습니다. 예를들면 일반 상수값이나, 정말 무난하게 사용가능한 함수 같은거에 적용하면 좋을꺼같습니다. 감사합니다.

CQRS 설계 팁

안녕하세요 초보송이님 질문 주셔서 감사합니다. 우선 Write와 Read하는 행위에 대해서 나눈것이 기본적으로 부하를 줄일 수 있는 형태가 CQRS입니다. 배치 처리기본적으로 줄일 수 있는 방식이죠. 처리해야 하는 데이터를 모아서 한번에 배치처리를 통해 데이터를 처리하는 방법입니다. 물론 이 과정에서 실패하는 케이스들에 대해서 핸들링 해야하는 부분이 존재하죠 Write Debouncing같은 리소스에 대해서 잦은 Update를 최근 상태 하나로 압축하는 겁니다.예를들면 장바구니 데이터나, 좋아요등이 존재하겠죠Redis나 Kafka Stream 같은 중간 버퍼에서 key 단위로 마지막 command만 남기고 이전 요청은 버려버리는거에요.즉 가장 최근 올라온 상태만 처리하는 것이죠이런 형태라면 1000건이 와도 최근 값만 반영되기 떄문에 총 1건만 반영하면 됩니다.하지만 도입하기에 너무 부답스럽고 까다롭다는 특징이 있습니다. 이외에는 MSQ를 도입함으로써 인스턴스의 부하를 방지하는 방법도 있을 꺼 같아요. 하지만 이는 Write 하는 DB에 대한 부하를 줄일 수는 없는 형태이고 기본적인 인스턴스의 부하를 줄일 수 있는 방법입니다. 감사합니다.

OkHttpClientConfig timeout 설정 질문

안녕하세요 Hello님 질문 주셔서 감사합니다. 우선 timeout에 대한 기준은 크게 없습니다. 기본적으로 default를 사용하시면 좋습니다.차라리 설정을 안하는게 더 좋은 상황이 많아요. 왜냐하면 장애상황에 대해서 커넥션을 계속 물고 있으면 그게 장애로 이어지기 떄문입니다.그렇다고 너무 짧게 잡자니 상대 서버에 대한 latency가 너무 유동적인 현상도 존재하고요 그러기떄문에, 그냥 default로 두고 상황에 따라서 동적으로 조율하는게 좋을꺼같습니다.예를들어 통신하는 서버가 너무 느려서 늘려야 한다면, 그떄 그냥 좀 여유있게 늘려놓는 형태가 되겠죠 그래서 사실 이 질문에 대해서는 제가 답변드릴 수 있는 부분이 너무 적은거 같아요.. ㅠㅠ 너무 상황에따라 다르고 유동적이기 떄문입니다. 감사합니다.

비전공자인데 AI가 발전한 요즘 백엔드로 진로를 하고 싶으면 어떤식으로 공부를 해야 하는지 알 수 있을까요???

안녕하세요 JS계의 김영한 목표님 질문 주셔서 감사합니다. 요즘 시장에서 참 어려운 질문인거 같아요. 저도 사실 어떻게 해야 하는지 잘 모르겠고 고민이 많은 상황입니다. 개인적인 생각으로는 AI가 하지 못할만한 부분에 집중하면 좋지 않을까 싶습니다. 사실상 기본적인 로직은 AI가 잘 작성을 해주기 떄문에, 아키텍처 관점에서 AI에게 질문을 던질 수 있는 능력을 기르는게 좋지 않을까 싶습니다. 물론 기본적인 코딩도 당연히 중요하지만, 시간이 점점 갈수록 큰 의미가 없다고 생각을 해서... 뭔가 좀 더 설계적인 관점에서 다가간다면 좋지 않을까 싶습니다. 하지만 어디까지나 제 개인적인 의견입니다. 미래는 어떻게 될 지 모르기떄문에 너무 맹신하지 마시고 참고만 해주시면 좋을꺼같습니다. 감사합니다.

Advice 패턴을 다시 분리할 수 있나요

안녕하세요 홈런님 질문 주셔서 감사합니다. 말씀해주신것처럼 advice 패턴을 도입하게 된다면, 기본적으로 클라이언트 코드가 좀 더 길어지는 경향이 있고 관리 측면에서 단점을 가져 갈 수 있습니다. 반대로 장점으로는 좀 더 명확하고 유동적으로 확인이 가능하다는 특징이 있죠. 음... 현재로써 저도 사실 이 부분에 대해서 딱히 떠오르는 부분이 없는거 같습니다 ㅠㅠ 한가지 생각나는 부분은 BeanPostProcessor 같은 형태를 적용하면 좋지 않을까 싶은데.. 사실상 이런 형태도 내부적인 코드가 매우 길어진다고 생각이 드네요. 큰 도움을 드리지 못해서 죄송합니다 ㅠㅠ 질문 감사합니다!

OutBox 패턴에 대한 질문입니다.

안녕하세요 김승수님 질문 주셔서 감사합니다. 우선 기본 전제를 정리하자면,CDC 도입 X -> 그로인해서 폴링을 통해 데이터를 인지 이런 경우 가장 먼저 고려해야 하는 부분이 말씀하신 것처럼 인스턴스가 늘어났을 때 동일한 Outbox 데이터를 여러 폴링 프로세스가 동시에 처리할 수 있다는 점입니다. 이로 인해 중복 메시지 발행, 경합(lock contention), 데이터 순서 꼬임 등이 발생할 수 있는거는 당연한 문제죠 폴링 전용 애플리케이션(or 워커 역할) 분리말하신 구조처럼 폴링 전용 서버를 두는 방식입니다.이 서버는 주기적으로 테이블을 스캔하면서, 아직 발행되지 않는 즉 처리해야하는 데이터를 조회 후 실질적으로 처리하지 않고 메시지를 전송합니다. 이 과정에서 redis, kafka등을 MSQ로 사용하면 좋고 중복된 데이터를 조회하는 부분에 있어서는 분산락을 사용하던 논리적인 락을 적용 할 수 있겠죠.좀 더 안전하게 한다면, 처리해야하는 주문 데이터에 대해서 이벤트를 발송 할 떄 멱등성을 보장 할 수 있으면 좋을꺼 같아요. 구조를 좀 더 단계별로 보면 다음과 같을꺼 같아요.주문이 생성이 된다면, 주문 데이터 + Outbox 이벤트를 같은 트랜잭션으로 DB에 저장이떄 Outbox 이벤트의 status는 PENDING으로 두겠죠그러면 이제 폴링 서버에서 status가 PENDING으로 되어있는 이벤트를 조회이떄 중복 데이터를 방지하기 위한 논리적인 락이나, 분산 락등 추가적인 처리가 필요하겠죠필요에 따라서 멱등성 보장을 위한 개념이 들어가면 더 좋을꺼 같고요 고민해 주신 부분이 거의 정석에 가까운 형태라고 생각을 합니다. 상황에 따라서 일부 달라질 수 있겠지만 정석에 가까운 고민을 하신거 같아요.하지만 이런 구조는 기본적으로 인스턴스가 많다는 상황을 가정하셨고 그러면 앞서 말씀드린 다양한 문제들을 방지할 수 있는 개념들을 숙지하고 클라이언트 레벨에서 제어하는게 좋지 않을까 싶습니다. 감사합니다!

kafka 컨슘은 실시간 인가요?

안녕하세요 핵심국사님 Kafka의 컨슘은 실시간이 아닙니다.기본적으로 이벤트를 특정 기간마다 긁어오는 형태로 동작합니다. 감사합니다.

Temporal에 대해서 더 알고 싶어요.

안녕하세요 수박님 질문 남겨주셔서 감사합니다. 우선 가장 좋은 해결법은 오픈소스를 뜯어보는 것이죠. 기본적으로 오픈소스로써 Github에 올라와있기 떄문에 해당 방식을 뜯어보는것이 가장 좋다고 생각합니다. 하지만 구현체도 어렵고 코드 보기가 아직 익숙하지 않으시다면... 사실 공식문서를 참고하거나 검색을 통해 여러개의 자료를 확인하는 방법밖에 없지 않을까 싶습니다 ㅠㅠ 저 또한 공식 문서를 통해서 학습을 했던 부분이라... 제 기준에서는 크게 질문을 드리기 어려울꺼 같습니다. 질문 감사합니다!

전체적인 플로우에 대해 질문드립니다.

안녕하세요 dbghksdn92님 질문 남겨주셔서 감사합니다. 우선 Kafka와 Debezium과 Temporal을 별개로 생각하시면 좋습니다. Kafka와 Debezium은 그냥 이벤트를 실시간으로 안전하게 받아서 처리하기 위한 용도로 이벤트만 잘 주어지면 되는것이고 그 이후에는 Temporal을 통해 비지니스 로직을 안전하게 처리한다로 이해하시면 됩니다. 즉 서로 하는 역할이 분리가 되어 있는겁니다.Temporal을 통해서 우리가 일반적으로 작성하는 비지니스 로직에서 이슈가 될만한 부분 순간적인 네트워크 이슈로 인한 재시도가 가장 일반적이겠죠 이런 부분들을 하나하나 핸들링 하지 않고 처리해야 하는 작업을 관리하는 툴로써 사용한다고 봐주시면 됩니다. 즉 Kafka와 Debezium을 통해 안전하게 이벤트를 받고, 그 이벤트를 처리하는 과정을 하나의 작업으로 두고 해당 작업을 안전하게 처리할 떄 Temporal을 사용한다고 이해하시면 되지 않을까 싶어요. 추가적인 질문이 있다면 남겨주세요. 감사합니다!