안녕하세요. redis 강의를 통해 간단한 프로젝트로 적용을 하려고 합니다. @Cacheable( value = "reviewList", key = "'review:store:' + #storeId + ':page:' + #pageable.pageNumber", cacheManager = "reviewCacheManager", condition = "#pageable.pageNumber == 0") @Transactional(readOnly = true) public Page<ResViewReviewDto> getReviews(UUID storeId, ReviewRepositorySearchConditionDto condition, Pageable pageable) { Page<ResViewReviewDto> reviews = reviewRepository.findReviews(storeId, condition, pageable); return new PageImpl<>(reviews.getContent(), pageable, reviews.getTotalElements()); }원래는 return reviews를 했더니 계속 조회를 누르면 ClassCastException: LinkedHashMap cannot be cast to Page 이 오류가 나오게 됩니다. 강의에서는 그냥 getContent를 List로 반환값을 보냈는데 혹시 위 코드처럼 new PageImpl 형식으로 return 해도 괜찮을까요? 

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요, 선생님! 강의 알차게 잘 수강하고 있습니다.현재 90% 수강 완료하였는데, 어렵고 힘들게 여기까지 온 만큼 저의 역량도 비교할 수 없을 정도로 많이 성장한 것 같습니다.먼저 감사의 말씀을 드립니다.일단 현재 게시글 목록 최적화 전략 구현(64강) 강의를 수강 중인데, 이전의 강의 내용(게시글 조회 최적화 전략)과 비교하였을때 최적화 전략을 수립하는 과정과 관련하여 몇가지 의문점이 들어 질문드리게 되었습니다.의문점) - 게시글/카테고리에 대한 게시글 목록 모두 전략을 나누어야 하는가?의문점이 들었던 과정) - 일단 크게 보았을때, 게시글 내용에 대한 캐싱(articleId)과 게시글 목록(*특정 카테고리, board로 지칭)에 대한 캐싱(boardId)으로 내용을 나눌 수 있을 것 같습니다.- 여기서 드는 제 개인적인 생각은, (일단 전략의 당위성이나 세부적인 내용 상관없이) 캐싱전략을 너무 세세하게, 오히려 성능적 이점보다는 관리적 비용이 더 크게 소모되지 않을까 하는 염려가 들 정도로 배꼽이 더 큰 전략/관리방안을 각각 구분해놓는 것이 아닌가하는 생각이 들었습니다.- 예를 들어, 게시글 목록 최적화 전략의 경우 말씀하신대로 최초 목록 조회 진입 시 보여지는 내용이기도 하고 이는 모든 사용자에게 공통적으로 적용할 수 있는 정책이므로 관리의 당위성이나 책임이 명확하다고 생각하였습니다.- 하지만 게시글 조회 최적화 전략의 경우, 목록 최적화 전략을 수강한 이후에는 "게시글 조회"역시 어떻게 보면 그 게시글을 보고싶은 사용자 일부에 대해서만 보여지는 글이므로..지금처럼 모든 생성 글/댓글/좋아요에 대해 ArticleQueryModel 데이터를 생성하는 것이 비용효율이나 관리효율면에서 과연 올바른 방향인지 다소 의문이 들게 되었습니다. 또한, 이러한 전략수립의 당위성을 떠나서 각 조회기능별로 전략을 구상하는게(단건/목록 등) 수립은 가능하더라도 관리가 힘들 것 같은데, 실무적으로 관리가 가능할지 의문이 들기도 하였습니다.최종 질문)- 제가 올바르게 강의내용을 이해하지 못하여 질문드리는 것 일 수 있기에, 일단 제가 들었던 의문이 선생님께서 생각하셨을때, 타당한 의문일지 궁금합니다.- 타당하다면 아래와 같은 "게시글 단건" 조회 전략을 생각할 수 있을 것 같은데, 혹시 바람직한 전략이 될 수 있을지 고견을 요청드려보고자 합니다.- 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다.[단건 조회전략 구상 방안] 게시글 조회 전략을 만약 구상한다면(세부적인 전략구현은 생략)- 지금처럼 단건 데이터 생성마다 articleQueryModel을 구성하는 것이 아니라, 각 카테고리별 보여지는 1000개의 데이터에 대해 articleQueryModel 데이터를 구성한다. (*게시글을 보는 것도 결국 최신 1000개의 데이터에 대해서만 볼 것이기 때문이다.)- 인기글 데이터 생성 후 해당 인기글에 대한 articleQueryModel 데이터를 구성한다.(*인기글 데이터에 대해서만 단건 조회 트래픽이 몰릴 것으로 예상할 수 있기 때문이다.)읽어주셔서 감사드립니다.

안녕하세요! 강의 너무 잘 보고 있습니다!강의를 보는 중 궁금한 부분이 생겨 질문드려봅니다!@GetMapping("/callback") fun callback( ... return ResponseEntity.status(HttpStatus.FOUND) .location(URI.create("https://localhost:3000")).build()콜백 함수에 return을 이렇게 작성하셨는데요!만약에 서블릿객체를 이용해서 쿠키를 담지 않고 아래와 같이 하는 방법은 어떻게 보시는지요...?? 같은 동작을 할 것으로 예상은되는데 보편적인 스타일이 궁금합니다 ㅋ.ㅋ;```return ResponseEntity .status(HttpStatus.FOUND) .header("Set-Cookie", "authToken=$token; HttpOnly; Path=/; Max-Age=${60 60 24 * 7}") .location(URI.create("http://localhost:3000")) .build()```

안녕하세요!다른 분 질문에 대한 답변을 보고 기본적인 의구심은 해소되었는데요. 혹시 몰라 확인차 여쭙습니다.09:38 피피티에서요.나머지 연산을 이용해서 물리샤드, 논리샤드를 구분하셨잖아요.제가 이해하기로 나머지가 0이면 1번 샤드, 1이면 2번 샤드...이렇게 의도하시려고 했던 것 같아요.https://inf.run/7i72V여기에서 답변해주신 것과 피피티의 샤드 번호 현황?이 달라서 조금 혼란스러웠습니다. 링크 답변을 보면 아주 간단한 샤딩 예시였지만, 물리 샤드가 두 개일 때 % 2를 적용하면 1번 샤드(나머지 연산결과 +1)에는 article_Id가 [2, 4, 6, 8]이 들어가고 2번 샤드에는 [1, 3, 5, 7]이 들어갈 테죠.논리 샤드 기준으로는1번 논리샤드 = [4, 8]2번 논리샤드 = [1, 5]3번 논리샤드 = [2, 6]4번 논리샤드= [3, 7] 1번 물리 샤드에는 1, 3번 논리 샤드2번 물리 샤드에는 2, 4번 논리 샤드(링크 답변과 동일한 분포)이게 제가 위의 답변을 강의 자료에 적용해서 이해한 샤딩 현황입니다! 실제 프로덕션에서도 이렇게 샤딩하는지는 모르겠지만 교육 목적 상 간단한 해싱이었어도 제대로 이해하고 넘어가고 싶었습니다.PPT만 보고는 나머지 연산이 어떻게 사용된 건지 이해가 안 됐는데 답변 보고 이해가 돼서 확인 차 질문드렸습니다.추가적으로 클라이언트는 논리 샤드만 알고 있다고 하셨는데 그럼 물리 샤드 번호는 물리적으로 나뉜 샤드를 구분하는 데만 사용하고 비즈니스 로직에서는 사용되는 일이 없을까요?감사합니다.

쿠폰에 관련되어서 좀 더 참고할만한 자료가 있을까요?

게시글 조회 기능을 확장하려고 할 때 댓글을 조회하는 방향에 대해 고민이 있어서 질문 남깁니다.게시글 하나를 보는 페이지로 사용자가 이동해서, 게시글의 내용과 댓글들까지 이동한 페이지에서 그려야 할 때 게시글 정보와 해당 게시글의 모든 댓글을 가져오는 기능을 신규로 추가하려고 합니다. 해당 기능의 구현에 대해 2 가지 방향을 고민해봤습니다.게시글처럼 댓글까지 캐싱하는 방법Hot data 로 캐싱된 게시글들의 댓글들을 캐싱하는 것을 고민했을 때, 댓글은 게시글보다 훨씬 많은 양이기 때문에 캐싱에 대한 비용이 너무 커지는 것에 부담이 생기는 문제가 있다고 생각합니다.댓글에 대한 조회는 매번 댓글 서비스에서 조회하는 방법실시간으로 게시물의 댓글을 계속 조회한다면, 조회 서비스에 읽기 부하가 크게 걸릴 것으로 생각합니다. 두 방식 다 장단점이 있다고 생각하는데, 강사님께선 어떤 방식으로 게시글 + 댓글 조회 기능을 구현하실지 의견이 궁금합니다!

해당 강의를 수강하기 전에 사전 학습으로 준비하면 좋은 내용들(MySQL, Redis, Kafka, 시스템 설계 등)에 대해 추천해주실 만한 책이나 강의가 있을까요?저에게는 이 강의가 다소 어렵게 느껴져서, 관련 내용을 따로 공부한 후 다시 수강하고 싶습니다.혹시 강의 내용과 연관되어 쿠케님께서 좋다고 느끼셨던 자료나 도움이 되었던 책, 강의 등이 있다면 공유 부탁드립니다!

강사님, 캐싱 관련해서 실무적인 관점의 질문이 있습니다.강의에서 String 타입의 value에 JSON 형식으로 데이터를 저장해서 캐싱 처리를 한다고 배웠는데, 실무에서 어느 범위까지 캐싱하는 게 적절한지 감을 잡고 싶습니다. 과거에 MyBatis의 동적 쿼리처럼 조건부 로직이 포함된 200줄짜리 복잡한 쿼리가 DB에서 파싱되는 시간 자체만으로도 성능 부하를 유발했던 경험이 있습니다.쿼리 자체를 수정하는 것이 베스트겠지만, 현실적으로 어려울 때가 있었습니다. 이런 '고치기 힘든 악성 쿼리'의 실행 자체를 회피하는 목적으로 Redis 캐싱을 적극적으로 사용하는 전략에 대해 궁금합니다. 실무에서는 이런 경우:1. 쿼리 결과 데이터가 어느 정도 크기(예: 수십 MB)까지 Redis에 캐싱을 허용하시나요?데이터가 너무 크면 오히려 Redis에 부담이 될 것 같아서요. 2. 만약 결과가 너무 크다면, 페이징 처리된 일부만 캐싱하시나요?아니면 보고서처럼 핵심 요약 데이터만 따로 캐싱하는 전략을 사용하시나요? 3. 특히 이런 복잡한 집계/통계 쿼리는 데이터 변경이 잦지 않은데,이런 경우 TTL은 보통 어느 정도로 설정하시는지 강사님의 경험이 궁금합니다.

안녕하세요, 강의를 통해 대규모 시스템 설계에 대한 다양하고 실무적인 방법을 배우게 되어 감사히 수강하고 있습니다!수강중 Transactional Outbox 테이블 관련하여 궁금한 부분이 있어 질문드립니다.실무에서는 보통 "Outbox 테이블에 Insert -> kafka send 후 Outbox 상태 Update" 하는 방식으로 쓰일까요? 강의에서는 간단히 Delete로 구현한다고 말씀주셔서 질문드려봅니다!Update 하는 방식도 자주 쓰인다면 Outbox 테이블은 파티셔닝(p20251001 와 같이)하여 관리하고 주기적으로 삭제하는 방식일지도 궁금하여 질문드립니다!  

안녕하세요 강사님!카프카를 사용하면서 궁금한 점이 있어서요~ 예를 들어 주문 시스템을 구현한다고 하면요.주문에 대해 상태가 계속 바뀌어 해당 이벤트를 받을 수 있도록 카프카를 붙이려고해요.consumer가 동일한 주문 id에 대해 상태 업데이트를 해야 하니, producer가 순서 보장되도록 카프카 key도 동일하게 셋팅하면 consumer는 순서대로 status를 제대로 update 하는데요. 만약 producer가 메시지 발행을 비동기적으로 진행하도록 구현했다고 하면,무언가 이슈로 주문 생성 -> 주문 취소 순이 아닌 주문 취소 -> 주문 생성 순으로 발행되었다면consumer 입장에서 메시지 순서가 제대로 들어왔음을 어떻게 인지할 수 있을까요..? 이런 상황은 발생하지 않을까요..? ㅎㅎ

안녕하세요 강사님!아직 완강은 아니지만 너무 재밌게 잘 보면서 많이 배우고 있습니다! 이번 강의를 보다가 궁금한 점이 생겨 질문을 남깁니다!강의에서 제시해주신 조회수라는 정보가 게시판이라는 도메인으로 보았을 때 비교적 중요하지 않다고 하신거에 충분히 동의합니다!근데, 문득 조회수를 통해 수익이 발생하는 서비스(ex. 유튜브)에서는 중요한 정보 아닌가? 라는 고민이 생겼습니다. 중요한 정보인데 쓰기가 자주 발생하는 상황에서 In-Memory 저장소를 메인으로 사용하고 RDB를 백업용으로 사용하면 위험하지 않나? 라는 생각이 들었습니다!이럴 때에는 보통 어떻게 처리하시나요? (이럴 때 NoSQL을 사용하나요?) 

쿠케님 안녕하세요!우선 좋은 강의 제작해주셔서 정말 감사합니다. 강의 들으면서 대규모 시스템을 설계할 때는 어느 것을 신경써야 하고, 또 주의해야 하는지 많은 인사이트를 얻고 있어요. 추석 연휴 동안 제 나름대로 열심히 들어서 이제 한 개 섹션만 남았는데, 완강을 한 뒤에 강의에서 얻은 것들을 토대로 대규모 트래픽을 가정한 서비스를 설계하고, 개발해보려고 합니다. 강의로만 듣고 넘기기에는 아까운 내용들이 많아서 확실하게 제 것으로 만들어야겠다 싶더라고요. 일하면서 써먹으면 더없이 좋겠지만 아쉽게도 그럴 환경은 안 되어서요.. ㅎㅎ 그래서 나름대로 구상을 해보면서 강의를 듣고 있는데, 문득 강의에서 다룬 아키텍처와 기술을 한 번에 다 도입하는 건 오히려 학습 효율을 떨어뜨리는 선택이 아닐까 싶은 생각이 들어서요. 실무에서 Redis 정도는 사용해봤지만, 분산 데이터베이스나 MSA도, Kafka나 CQRS도 이 강의에서 처음 사용해봤습니다. 개념은 대충 주워 듣긴 했지만, 제대로 공부해본 적도 없고요. 결론적으로 하나씩 해보는 게 낫겠다 싶은데, 강의에서 다룬 내용 중 어느 것을 먼저 학습하는 게 좋을지 쿠케님께 조언을 구하고 싶어요. 물론 정답이 없는 문제지만, 지금 당장 제가 일하는 환경에서는 써먹을 일이 별로 없는 내용들이다 보니 무엇을 먼저 하는 게 좋을지 선택하기가 어렵네요. 감사합니다.

안녕하세요, 강사님!Kafka 관련 강의를 듣다가 기술 선택의 기준에 대해 궁금한 점이 생겨 질문드립니다. 현재 강의에서 Kafka를 이벤트 브로커(Event Broker)로 사용하고 계신데,Redis의 Pub/Sub 또는 Redis Streams 기능을 이용하면비슷한 형태로 서비스 간 메시지 전달을 구현할 수도 있을 것 같다는 생각이 들었습니다. 그래서 아래 두 가지 부분이 궁금합니다  Kafka를 선택하신 이유 또는 기준이 무엇인지 예: 처리량, 확장성, 영속성, 장애 복구 등 기술적 관점에서 어떤 요소가 결정적이었는지혹은 실제 서비스 환경에서 Redis 기반 메시징을 사용했을 때의 한계가 있었는지도 궁금합니다. 이벤트 브로커(Event Broker)와 메시지 브로커(Message Broker)의 개념적 차이 두 용어가 거의 비슷하게 사용되는 경우도 많은데,Kafka가 ‘이벤트 브로커’로 분류되는 이유가 무엇인지 알고 싶습니다.실제로 시스템 설계 시, 어떤 기준으로 두 개념을 구분하고 선택하시는지도 궁금합니다. 제가 이해하기로는 Redis는 단순한 메시지 전달 중심,Kafka는 이벤트 스트리밍 및 데이터 파이프라인 중심으로 알고 있는데,이 부분이 맞는 방향인지도 확인해보고 싶습니다. 

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.강사님, 최적화를 진행할 때 보통 어떤 순서로 고민하시나요?예를 들어 트래픽이 몰릴 때 먼저 어디를 확인하고, 어떤 기준으로 개선 방향을 정하시는지가 궁금합니다.

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요.2뎁스 댓글 목록의 테스트 데이터 삽입 시에는 계층 구조까지 파악할 수 있게끔 작성이 되었는데무한 뎁스 댓글의 테스트 데이터 삽입은 계층 구조로 생성하지 않으신 이유가 궁금합니다!

data class로 엔티티를 정의해서 copy로 변경 후 save하는 방식을 사용하셨는데, 일반적으로는 JPA의 더티 체킹을 이용해 변경 감지를 활용하는 경우가 많습니다.혹시 copy 방식을 사용하신 게 의도하신 설계 방향일까요?

현재처럼 서비스 구조가 거의 테이블 단위로 DB와 API 서비스가 분리될 때,이런 구조에서 화면에서 리스트 형태로 두 도메인 데이터를 함께 조회해야 하는 경우가 있을 것 같습니다.예를 들자면 게시글과 게시글 조회 수를 함께 보여주는 리스트 API가 필요한 상황에서,단건 조회라면 프론트에서 별도로 API를 호출해도 괜찮을 것 같은데,페이징 처리나 리스트 형태로 여러 데이터를 묶어서 조회해야 할 때,실무에서는 보통한 서비스에서 다른 서비스를 RestClient(Feign 등) 로 호출해서 데이터를 합치는 방식으로 처리하는지,아니면, 같은 도메인 서비스로 묶어버린다던지아니면 프론트엔드에서 각각의 API를 호출한 뒤 병합하는 방식으로 처리하는지궁금합니다.실제 현업에서는 이런 경우 어떤 접근 방식을 주로 사용하나요?

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.안녕하세요.향로님의 추석 챌리지에서 우연히 제목을 보고 바로 구매했는데 아직 완강하지는 못했지만 정말 좋은 강의 같습니다!선배 개발자님이 개발하시는 느낌으로 보고있습니다! ㅎㅎ궁금한 점은 혹시 실무에서도 이런식으로 서브쿼리를 이용해서 대규모 데이터에 대해서 처리를 하는지가 궁금해져서 질문 남겨봅니다!

안녕하세요 강사님.강의에서 Path Enumeration 방식을 활용해 데이터베이스 조회 성능을 최적화하는 방법을 매우 유익하게 배웠습니다.실제 대규모 서비스 환경에서 이 조회 결과를 Redis로 캐싱하려고 할 때, 캐시를 저장하는 자료구조 선택에 대해 강사님의 의견을 듣고 싶습니다.현재는 Path를 기반으로 DB에서 계층 구조를 유지하며 정렬된 댓글 목록을 조회하고 있습니다. 이 결과를 Redis에 저장하는 방법으로 아래 두 가지를 고려하고 있습니다.1. List 구조 (LRANGE)장점: DB에서 조회한 정렬 순서를 그대로 Redis에 저장할 수 있어, 조회 시 한 번에 가져올 수 있습니다.고민: CUD(특히 중간 삽입) 발생 시 전체 List를 삭제하고 DB에서 다시 조회해 재저장해야 하므로 비효율적일 수 있습니다.2. Sorted Set 구조 (ZADD)장점: 각 댓글을 멤버로 저장하고 Path 값이나 정렬 기준을 score로 부여하면, CUD 발생 시 해당 멤버만 ADD/REMOVE로 처리할 수 있어 갱신이 효율적입니다.고민: Path 기반의 정렬 값을 Redis의 score로 매핑하는 과정이 다소 복잡합니다.이처럼 캐싱 로직의 구현 복잡도(Sorted Set)와 갱신 효율성(List의 TTL 전략) 사이의 균형을 고려할 때,강사님께서는 무한 depth 댓글 구조를 캐싱할 때 어떤 Redis 자료구조가 더 적합하다고 생각하시는지 궁금합니다.감사합니다.

대부분 하나의 DB만을 사용하다보니 shard key가 고려되지 않은 테이블 설계를 보고 많이 사용했는데 처음부터 shard key는 고려하면서 설계를 하는것이 좋을까요?저같은 경우처럼 shard key가 고려되지 않은 테이블에서 샤딩을 하기위해서 shard key를 추가하는 작업은 어느정도의 난이도가 있을까요?강사님이 생각하시는 데이터베이스 샤딩을 위한 기준같은게 있으신지 궁금합니다.