안녕하세요. 강사님캐시전략 - Write-behind 전략을 설명해주셨는데,인스타라이브나 유튜브라이브에서 좋아요를 한 사용자가 여러번 누를 수 있는데, 이때가 아마 Write-behind 전략을 적용할 수 있을 거 같습니다.1. 좋아요를 레디스 캐시에 카운트 증가2. 좋아요 누른 개수를 몇 초마다 flush로 카프카 큐에 발행3. 카프카 consumer에서 db저장 이런 방식으로 설계가 가능할 거 같습니다. 강의에서는 Write-behind DB에 나중에 저장한다고 말씀하셨는데 그럼 이런 라이브 상황에서 DB에 좋아요를 언제 저장하는 것이 바람직할까요? 그 기준을 어떤 식으로 잡으면 좋을지도 선생님의 고견이 듣고 싶습니다.좋은 강의 감사합니다.  

안녕하세요. 강의 잘 수강하고 있습니다. SubStack 1년 무료 제공 링크를 통해 신청했는데,신청 처리 되었는지 확인 부탁 드립니다. 

안녕하세요, 강의 잘 듣고 있습니다 감사합니다! SubStack 1년 무료 제공 관련해서 https://forms.gle/diKHUhvUe61JwzXF7 링크를 통해 신청했는데, 신청 정상적으로 되었는지 확인 부탁드립니다! 감사합니다!

안녕하세요, 선생님! 강의 들으면서 Service 및 Cache Handler 구성간 Create/Update <-> Delete 간의 Return Record 여부 차이에 대해 질문드리고자 합니다. 서비스도 그렇고, 핸들러도 그렇고, Return type이 Create/Update는 전달받은 Record를 Entity Context에 적용한 객체인데, delete의 경우 void로 운용하시는 것을 보고 어떤 차이점이 있는지 궁금하여 질문드리게 되었습니다. create, update 모두 반영 이후의 내역을 바로 반환하여 보여준다는 의미로 생각하였는데, delete를 보면 그런 것 같지는 않아서 따로 다른 의미가 있는지(실무에서 이렇게 많이 사용한다던가), 별 의미가 없는지 구체적으로 문의드리고자 합니다. 감사합니다.

안녕하세요, 선생님!6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다.데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지  일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다.  제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.   

안녕하세요 미국 달팽이님! 강의 잘 듣고 있습니다.https://inf.run/JxEdX에서 안내주신 구글 폼 링크로 수강 닉네임과 substack 이메일을 제출했는데, 혹시 제가 입력한 정보가 잘못됐을까요? 확인 한번 부탁드립니다.!

m=32MB짜리 10개와 m=512MB짜리 1개의 경우를 비교해주셨습니다.그런데 이는 샤딩을 통해서 메모리 효율적으로 됐다기 보다는 메모리 총량이 512MB->320MB로 감소했기 때문에 오차율이 조금 증가하는 대신 메모리를 덜 쓸 수 있는 것 아닌가요?예를 들어 320MB 짜리 1개인 경우와 32MB짜리 10개인 경우의 오차율이 똑같지 않나 하는 생각이 들어서 질문드립니다! 

"Split 전략에서 항상 모든 Split을 조회한다."요 부분이 이해가 가지 않아서 질문드립니다!findSplitIndex로 계산한 split에만 접근하는 것 아닌가요?아니면 모든 스플릿이 단일 redis 내에 존재하는 것이 문제라는 의도로 말씀하신걸까요?

@Slf4j @SpringBootTest class SplitBloomFilterRedisHandlerTest extends RedisTestContainerSupport { @Autowired SplitBloomFilterRedisHandler splitBloomFilterRedisHandler; @Test void mightContain() { SplitBloomFilter splitBloomFilter = SplitBloomFilter.create("testId", 1000, 0.01); List<String> values = IntStream.range(0, 1000).mapToObj(idx -> "value" + idx).toList(); for (String value : values) { splitBloomFilterRedisHandler.add(splitBloomFilter, value); } for (String value : values) { boolean result = splitBloomFilterRedisHandler.mightContain(splitBloomFilter, value); assertThat(result).isTrue(); } for (int i = 0; i < 1000; i++) { String value = "notAddedValue" + i; boolean result = splitBloomFilterRedisHandler.mightContain(splitBloomFilter, value); if (result) { log.info("value={}", value); } } } }  위 코드는 SplitBloomFilterRedisHandlerTest 인데요.강의 중 코드입니다 1000 크기에 0.01 오차율의 Bloom Filter 를 만들고1000개의 데이터를 넣고 False Positive 까지 검증해보는 코드인데요.질문입니다Split 전략을 배우기 전에순수한 Bloom Filter 구현 강의에서도 위와 동일한 테스트 코드가 있는데요이 때, 순수한 Bloom Filter 의 한계로써생성한 Bloom Filter 크기를 초과하여 데이터를 넣으면 비트 1이 많아져 오차율이 증가하고그로 인해 False Positive 데이터가 많이 조회되는 현상을 살펴보거든요.그리고 그 해결책으로처음부터 큰 Bloom Filter 를 만드는 것 이외에Split / Sharding / Sub Filter 전략이라고 말씀하시는데요근데 위 Split 전략의 테스트 코드에서 BloomFilter 크기는 1000으로 만들고 데이터를 훨씬 초과하여 2000개 만들어 넣어보면순수한 Bloom Filter 때처럼 False Positive 데이터가 많이 조회됩니다.저는 PC 가 느려서 False Positive 를 1000번으로 조회하였고오차율 (0.01) 에 의하면 약 10개의 False Positive 가 나와야 하는데데이터 1000개를 저장했을 때는 오차율에 맞게 8개로 떨어지는데데이터 2000개를 저장했을 때는 오차율을 훨씬 넘어갑니다제가 코드를 잘못 따라 친건지.. Split 도 원래 그런건지..제 질문 의미가 전달될지는 모르겠지만.. 명확하게 개념 정리가 되지 않아 질문드립니다

해당 용어로 검색했을때 관련 자료를 찾을수가 없더라고요.혹시 업계에서 다른 용어로도 불리고 있는 기술인가요?

 유튜브 예제에서 사용자가 동영상을 요청하면 CNAME으로 CDN에 먼저 가는 것이 아니라 API 게이트웨이로 갔다가 CDN으로 요청을 보내는건가요?

안녕하세요. transcoder service에 대해 문의 드립니다.해당 서비스는 음악파일에 대한 변환으로 이해했는데요. 그렇다면 변환 과정을 거쳐서 file storage 로 넣어야하지 않을까 싶어요.혹시 언급된 transcoder가 다른 의미가 있을까요?

특별 학습 자료 프로모션 1년 멤버십 무료 제공 지원 어떻게 확인할 수 있을까요?

강의 마지막에 위치 이름 기반으로 호텔을 조회하는 메서드 관련하여 질문 드립니다. 참조 관계강의에서 hotel, location 양쪽에서 서로를 참조하고 있습니다. 여기서는 location에서만 hotel을 참조하는 것이 맞지 않나요?? 우선 location을 생성할 때 hotel이 필요하고, location은 호텔을 위해 생성된 호텔에 종속적인 모델이기 때문에 location에 두는게 맞다고 생각합니다.  위치 기반 호텔 조회 메서드1번에서 location에서 호텔을 참조한다면, 위치 기반 호텔 조회 메서드는 location에 있어야 한다고 생각합니다.또한 지금 호텔을 전부 탐색하며 일치하는 모델을 찾고 있는데, 그냥 단순히 bruteforce 로직을 보여주시려고 하신걸까요?? 호텔과 location을 조인해서 가져오거나, 그냥 location에서 name 인덱싱을 걸고 호텔 id 값 찾아서 + 호텔 조회하는 그런 방식을 생각했는데 logic으로 적어주신 이후 최적화 과정이 빠진 것이 아쉽습니다. 이런 부분들을 어떻게 최적화 할 수 있는지 다양한 방법들을 배우고 싶습니다ㅠ 제가 맞다고 주장하는 것이 아니라 몰라서 질문 드립니다.감사합니다 :)

1초로하면 현재 성공, 실패 각각 200, 0으로 나오고 2초로 해야 100개 씩 성공하는데 정상인가요?

환경은 windows 11 64비트이구요,자바 21, redis는 물론 docker 8.2.1 실행 중이엇구요 하지만SplitShardedBloomFilterRedisHandlerTest 클래스에 mightContain 테스트 함수 실행 하면 첨부한 이미지 처럼 에러가 출력 됩니다. 아래는 docker 버전 정보입니다. 

현재 강의에서는 Inventory table을 따로 분리해두었습니다.그런데 Inventory Table을 분리한 이유에 대해 말씀해 주실 때, 분리하는 게 좋다고만 말씀해주신 것 같아서 설명이 부족하다는 생각이 들었습니다. Inventory가 재고라는 의미를 가지는 것으로 알고 있어서 items table에 있는 수량을 Inventory로 옮기는 것이 더 옳은 설계가 아닌가라는 생각이 들었습니다.물론 지금 강사님께서 설명해주신 구조도 맞다고 보지만, 그 구조를 유지한다면 현재 Inventory table에 유의미한 칼럼이 없기 때문에 Inventory table이 없어야 하지 않나라는 생각을 했습니다. 그리고 재고가 자주 바뀌는 상황이 발생한다고 한다면 오히려 Inventory table에 재고를 넘겨줘야한다고 생각을 하는데요. 왜냐하면 Items table에 재고 칼럼이 있다면 재고가 바뀌는 순간에는 Items table의 데이터를 수정할 수 없게 됩니다. 그러면 관리자가 Item을 수정하려고 할 때, 재고가 많이 바뀌는 상황에는 그만큼 수정 쿼리가 대기를 하게 될 것이라고 생각하는데요. (물론 이 정도까지의 문제는 생기지 않을 것이라고 생각합니다.) 또한 이 글에서 강사님께서 말씀해주신 유형별 재고 관리 정책 부분은 Inventory가 재고라는 성격을 나타낸다는 점에서 Inventory table에서 관리할 것 같고, 트래픽 증가 시 성능 문제가 생긴다면 여기서 또 테이블 분리를 시도하거나 레디스 같은 memory DB를 생각해볼 수 있을 것 같습니다. 그래서 질문은현재 재고 칼럼의 위치를 어디에 두는 게 맞는지, 트래픽 증가의 성능 문제가 있다면 오히려 Inventory 테이블로 넘겨주는 게 맞는게 아닌지유형별 재고 관리 정책이 필요한 경우에 강사님께서 생각하시는 확장성 있는 구조는 무엇인지가 궁금합니다.  혹시 제가 잘못 알고 있거나 잘못 이해한 부분이 있다면 같이 짚어주시면 감사하겠습니다!

안녕하세요 백엔드 개발자를 희망하고 있는 학생입니다.유저별 포인트 같은 정합성이 중요한 데이터로 로그를 따로 관리 해야한다고 말씀 해 주셨는데 이런 경우(배치 도구를 스프링 배치를 사용할 경우에) 로그 테이블을 따로 만들어서 관리 해주는게 나중에 자소서 쓸 때도 도움이 되나요?   

안녕하세요!강의를 통해 많은 인사이트를 얻었습니다. 좋은 강의 제공해주셔서 감사합니다. 강의를 수강하는 과정에서 궁금한 점이 생겨 질문 남깁니다. 시스템 디자인 단계에서 응답 시간(P95/P99)이나 TPS 같은 성능 목표를 설정할 때,인스턴스 스펙이나 인프라 제약도 함께 고려해야 하는지가 궁금합니다. 특히 학생이나 개인 프로젝트의 경우 프리티어처럼 제한된 리소스를 사용하는 일이 많은데,이런 환경에서는 인프라 제약을 기준으로 현실적인 목표치를 설정하는 것이 맞는지,아니면 인프라 스펙을 별도로 고려하지 않고 일반적인 목표값을 그대로 설정하는 것이 더 바람직한지 조언 부탁드립니다. 감사합니다!

 ------------------------------ 해결 방안-------------------------------저와 비슷한 이슈가 있으신분은 이렇게 처리 부탁드립니다! 인텔리제이 설정에서 Preferences > Build, Execution, Deployment > Build Tools > Gradle에서Build and run using : GradleRun tests using : Gradle 이렇게 수정 하고 다시 시도 부탁드립니다!!!  쿠케님 감사합니다 :)    안녕하세요 우선 좋은 강의 만들어주셔서 정말 감사드립니다.GET - http://localhost:8080/cache-strategy/NONE/items/{{itemId}} 해당 API 를 호출 하게 되면ItemController -> KukeCacheAspect -> KukeCacheKeyGenerator -> ItemNoneCacheService  대충 이런 흐름으로 가게 되는데요.KukeCacheKeyGenerator 객체에서 for (int i = 0; i<args.length; i++) { context.setVariable(parameterNames[i], args[i]); } parameterNames 객체에 NPE 에러가 발생 되고 있습니다.코드는 강의 자료실 통해 제공해주신 코드로 실행 해보았습니다. 이 부분 어떻게 수정을 해야 할까요?