멀티모듈 초기설정

안녕하세요 김우철님 질문 남겨주셔서 감사합니다. 어... 현재 질문주신 내용으로는 제가 어떤 문제인지 잘 파악이 힘들꺼 같아요... 그떄 당시의 소스코드라던지 추가적인 정보가 필요할꺼같습니다... ㅠㅠ IDE 문제일수도 있고, 필수 라이브러리가 아직 설치가 안되어 있을수도 있고 유추가 거의 불가능한 상태인거 같네요.,.

중복 컨슘 방지에 대해서 여쭤보고 싶습니다!

안녕하세요 YOGURT님 질문 주셔서 감사합니다.우선 처리 실패에 대해서는 DLQ를 사용하는 패턴을 구현하셨다는걸로 이해를 하였습니다.그리고 정확히 한번 즉 exactly-once 정책을 보장하고 싶은 고민으로 보입니다. 우선 해결해야 하는 부분은 컴슈머 입장에서의 멱등성 보장입니다.어떤 전략을 사용하냐에 따라 다르지만, 기본적으로 중복된 메시지가 들어와도 이미 처리가 되었다면, 더이상 처리가 되지 않도록 하는 방식 구현이 되면 좋습니다. 대표적으로 처리한 ID를 기록해두면 좋겠죠 이를 통해서 멱등성도 보장이 가능하고요 말씀해 주셨던 인박스 패턴이라는게 결국 이런 멱등성을 보장하기 위한 패턴ㅇ입니다. 상태 저장소에 기록함으로써 처리하였던것을 기록하고 검증하는 것이죠. 근데 조금 제가 이해가 안가는 부분이 있는거 같아요.하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...? 해당 부분에서 첫번쨰에서 리밸런싱 발생 -> 하지만 인박스 패턴 및 리밸런싱이 발생해도 상태값을 통해 다시 같은 메시지를 스킵 -> 이후의 첫 컨슘?? 이 첫 컨슘이 어떤 컨슘을 의미하시는지 상황이 명확하게 그려지지는 않는거 같아서요. 혹시 마지막에 질문주신 부분을 좀 더 상세하게 설명해 주실 수 있을까요??

강의 19] 질문입니다.

안녕하세요 치즈초코우유님 질문 주셔서 감사합니다.보내주신 당연하게도 개발자간에 스타일의 차이는 있겠고 저도 새당 코드를 구현할 떄 크게 뭔가 고려한 스타일은 아니였다보니 중요하게 생각하지 않았는데, 보내주신 코드 스타일이 좀 더 유지관리하기에는 좋은 포인트인거 같습니다. 직접적으로 전달을 해준다는것이 좀 더 유용한 형태는 맞는거 같아요. 저보다 더 뛰어나시네요 ㅎㅎ 질문주셔서 감사합니다!

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으로 되어있는 이벤트를 조회이떄 중복 데이터를 방지하기 위한 논리적인 락이나, 분산 락등 추가적인 처리가 필요하겠죠필요에 따라서 멱등성 보장을 위한 개념이 들어가면 더 좋을꺼 같고요 고민해 주신 부분이 거의 정석에 가까운 형태라고 생각을 합니다. 상황에 따라서 일부 달라질 수 있겠지만 정석에 가까운 고민을 하신거 같아요.하지만 이런 구조는 기본적으로 인스턴스가 많다는 상황을 가정하셨고 그러면 앞서 말씀드린 다양한 문제들을 방지할 수 있는 개념들을 숙지하고 클라이언트 레벨에서 제어하는게 좋지 않을까 싶습니다. 감사합니다!