강의 내용을 듣고 생각했을때 ,대부분의 경우 Redis String 보다 Redis Hash 사용하는게 대부분 이득일것 같다 생각이 들던데...어떻게 사용하고 계시나요 ?? 사실 저는 Redis String 으로 Json 으로 많이 사용했었습니다. 그리고 큰 장애를 경험하지 못했는데요 아무래도 트래픽에 대한 차이인것 같네요

강의 잘 들었습니다.Redis 주로 그냥 일반적으로 메모리에 저장하고 호출하는 정도로만 사용을 하고 있는데요BLPOP ,RPUSH job_queue job1 와 같은 기능은 언제 사용하게 되나요 ?? 

  최근에 Redis 의 개발사가 라이선스 정책을 변경하면서, 더 이상 완전한 무료 오픈소스로 부르기 애매해지는 사건이 있었습니다. 이에 반발한 AWS, 구글 등 빅테크 기업들이 모인 Linux Foundation 에서 기존 Redis 코드를 그대로 복사해서(포크해서) 만든 진짜 100% 무료 오픈소스가 바로 Valkey 입니다.라고 제미나이가 그러던데... 요즘은 Valkey를 선택하는 게 대세인가요?

수업 예시에서는 외부 api가 실패할 경우 스케쥴러를 활용해서 후보정 로직을 통하여 결과적 일관성을 맞추고 있습니다. 만약에 자리를 지정하는 콘서트를 위와 같이 처리할 경우 (예약은 성공, 외부 api는 실패), 후보정 로직이 동작하기 전 다른 예약 시스템에서 해당 자리를 예약한 경우 더욱 큰 문제가 발생할 수 있을 것으로 보입니다. 이러한 경우 (좌석처럼 한정된 자원을 예약하는 경우), 외부 API 실패 시 후보정 로직을 통한 비동기 처리 대신 동기적으로 처리하는 것이 올바른 방식인 것 같은데, 강사님은 어떻게 생각하시는지 궁금합니다!

강의에서 작성된 코드를 제공해주시는 것 같은데 어디서 볼 수 있나요?

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 도 원래 그런건지..제 질문 의미가 전달될지는 모르겠지만.. 명확하게 개념 정리가 되지 않아 질문드립니다

안녕하세요.게시판 관련 강의를 듣는 도중 궁금한 점이 있어 질문을 남깁니다.강의에서는 Snowflake 기반 단순 정렬을 기준으로 커버링 인덱스를 설명해주셨는데요,실무에서는 여러 정렬 조건과 필터, 검색 조건이 함께 붙는 경우가 많습니다.✅ 이런 복합적인 조회 패턴에서도 커버링 인덱스를 중심으로 설계하는 것이 적절한지,아니면 다른 전략을 어떻게 사용해야 하는지 궁금합니다.(설명이 길어질 경우 간단한 힌트라도 부탁드립니다.)💥 걱정하는 부분정렬되는 컬럼 전부에 대해 인덱스를 걸면 더 문제가 발생할 것 같아요.검색 %검색어%의 경우에는 결국엔 full_scan이어서 성능 최적화가 불가능하다.

강의를 보다가 궁금한 부분들이 생겨 질문드립니다!!1. RateLimit Boundary Burst 관련RateLimit을 설명해주시는 부분을 보면서 한 가지 의문이 들었습니다.예를 들어 1초에 100개로 제한을 두었을 때,0.9초 시점에 100개 요청이 들어오고 1초가 되자마자 다시 100개가 들어온다면실제로는 매우 짧은 시간 안에 200개의 요청이 처리될 수 있지 않을까 하는 생각이 들었습니다.찾아보니 이러한 문제를 Boundary Burst라고 부른다는 것을 알게 되었습니다.이를 해결하기 위해:Sliding WindowSliding Window CounterToken BucketLeaky Bucket등의 방식이 있다는 것을 확인했습니다.실무 관점에서는 이런 경계 구간 Burst 문제를 어떤 방식으로 해결하는지 궁금합니다.2. Request Collapsing 관련Request Collapsing을 설명해주신 부분을 보면서,여러 요청을 하나로 모아서 처리하는 방식으로 Golang의 SingleFlight 패턴을 응용하는 방법도 가능하지 않을까 생각해보았습니다.이와 관련해서 아래와 같은 예제 코드도 작성해 보았습니다.private final StringRedisTemplate redisTemplate; private final Map<String, CompletableFuture<?>> singleFlightMap = new ConcurrentHashMap<>(); @Override public <T> T fetch(String key, Duration ttl, Supplier<T> supplier, Class<T> clazz) { String cached = redisTemplate.opsForValue().get(key); if (cached != null) { return DataSerializer.deserializeOrNull(cached, clazz); } CompletableFuture<T> newFuture = new CompletableFuture<>(); CompletableFuture<T> existing = (CompletableFuture<T>) singleFlightMap.putIfAbsent(key, newFuture); if (existing != null) { // 다른 스레드가 실행 중 → 기다림 return existing.join(); } // 내가 실행자 (락 없이 실행) try { T result = refresh(key, ttl, supplier); newFuture.complete(result); return result; } catch (Throwable t) { newFuture.completeExceptionally(t); throw t; } finally { singleFlightMap.remove(key, newFuture); } } private <T> T refresh(String key, Duration ttl, Supplier<T> dataSourceSupplier) { T result = dataSourceSupplier.get(); put(key, ttl, result); return result; }이 방식은 분산 락이나 폴링 방식 없이도 동일 인스턴스 내 요청을 모을 수 있다는 장점이 있다고 생각했습니다.물론 이 방법은 모든 분산 서버 간 요청을 하나로 모으는 것은 아니기 때문에, 서버 인스턴스 수만큼은 요청이 발생할 수 있다는 한계가 있다고 생각합니다.하지만 인스턴스 수가 많지 않다면, 분산 락으로 인한 오버헤드나 복잡성을 줄이면서도 어느 정도 트래픽을 제어할 수 있는 현실적인 선택지가 될 수 있지 않을까 하는 생각이 들었습니다.실무 관점에서는 이런 방식에 대해 어떻게 평가하시는지 궁금합니다.3. Write Through 방식에서의 장애 처리Write Through 방식에서는 일반적으로:DB에 먼저 저장동일 데이터를 Redis에도 저장하는 구조로 이해하고 있습니다.그런데 만약:DB에는 쓰기 성공Redis에는 쓰기 실패하는 상황이 발생한다면, 이 경우를 트랜잭션 실패로 간주해야 하는지 궁금합니다.Redis 장애로 인해 캐시 반영이 실패했을 때,핵심 트랜잭션(DB 쓰기)까지 롤백해야 하는지아니면 캐시는 보조 저장소로 보고 DB 성공을 기준으로 처리해야 하는지두 저장소 간 원자성을 반드시 보장해야 하는 설계인지 실무에서는 어떤 기준으로 판단하는지 궁금합니다.

혹시 선생님께서 수업 중 사용하신 ppt 파일이 있으실까요? 복습할 때 꼭 필요해서 질문드립니다!

안녕하세요!AI로 개발하는 대략적인 방법에 대해서 알 수 있어서 재밌게 잘 듣고 있습니다!! 다만, 프론트에서 React 훅을 만드는 작업(API 작업)을 다루는 부분이 많이 스킵되어 이 부분을 어떻게 처리해야 할 지 고민이 됩니다.이전에 AI로 프로젝트를 진행할 때에도, 이미 만들어진 UI/UX에 API 추가하는 것이 항상 어려움이 있었던 작업이라..혹시, API를 연결할 때 조금 더 수월하게 할 수 있는 팁 같은 것이 있을까요?감사합니다!

안녕하세요! 해당 강의를 통해 redis pipeline과 lua script 활용 법을 눈으로 보고 배울 수 있어서 재밌게 수강하고 있습니다.  AsyncPERStrategy() 메서드를 통해 랜덤한 확률로 레디스의 캐시 데이터를 업데이트 하는 것으로 이해하였습니다. 캐시 데이터를 업데이트를 비동기적으로 처리를 위해 프록시 기반 AOP로 동작하는 @Async 어노테이션을 활용하셨는데, 해당 메서드를 내부호출 함으로써 비동기 처리가 안되는 것으로 예상됩니다! 혹시 제가 잘못 알고있을 수도 있으니 확인 부탁드립니다!

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요? 여기까지 이해하신 내용은 무엇인가요? 2. 어려움을 겪는 부분어느 부분에서 막히셨나요?코드의 어떤 로직이 이해가 안 되시나요?어떤 개념이 헷갈리시나요? 3. 시도해보신 내용문제 해결을 위해 어떤 시도를 해보셨나요?에러가 발생했다면 어떤 에러인가요?현재 작성하신 코드를 공유해주세요 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!  안녕하세요. 아직 수강전인데 수강을 해야만 백엔드 기술면접 실전문제집을 받을 수 있는건가요? (혹시 아직 여분이 있는걸까요?!)

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요? 여기까지 이해하신 내용은 무엇인가요? 2. 어려움을 겪는 부분어느 부분에서 막히셨나요?코드의 어떤 로직이 이해가 안 되시나요?어떤 개념이 헷갈리시나요? 3. 시도해보신 내용문제 해결을 위해 어떤 시도를 해보셨나요?에러가 발생했다면 어떤 에러인가요?현재 작성하신 코드를 공유해주세요 안녕하세요 항상 강의 잘 보고 있습니다 !  딩코딩코님 혹시, 로컬에서 테스트 한 결과를 이력서에 써도 괜찮을까요?  서비스를 배포를 할 생각이긴한데, 똑같은 환경을 2개 만들어서 배포를 하고 테스트를 하려니 비용이 많이 나올 것 같아서 어떻게 해야될지 고민하고 있습니다 ㅜㅜ  이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!

코드리뷰 실습 부분에서 아래 두가지와 관련된 질문 들이 있습니다!agentscommands질문두 가지는 실제로 클로드 코드에서 제공해주는 각각 다른 기능인건가요? 아니면 똑같은 기능이지만 추상적인 의미만 부여한 건가요?agents.md 파일 코드리뷰에이전트 이외에도 테스트코드작성전용에이전트, 쿼리작성에이전트와 같이 하나의 페르소나를 부여한 별도로 하나의 기능을 가진 객체로 생각해도 될까요?commands 기능은 꼭 agents 파일을 바인딩 할 때만 사용하는 기능인가요?위 기능의 차이점이 단순히 agents.md를 실행하려면 자연어로 명령하고 commands기능은 /xx로 명령하는 차이만 있는건가요?

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다.그렇다면, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서 불필요한 DB 부하와 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하고 처리하는 것이 적절한가요?좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다.다만, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서는 애플리케이션 단의 단순한 선행 검증만으로는 이를 제어하기 어렵다고 느꼈습니다.예를 들어, 아래와 같은 코드에서는 다음과 같은 경쟁 상태(race condition)가 발생할 수 있습니다.T1: exists → false T2: exists → false T1: insert T2: insert ❌ (유니크 제약 위반) if (!likeRepository.exists(postId, userId)) { likeRepository.save(...); } 이처럼 애플리케이션 레벨의 exists → insert 패턴이 동시성 문제를 해결하지 못하는 상황에서DB 예외에만 의존하지 않고 불필요한 중복 요청과 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하는 것이 바람직하다고 보시는지 궁금합니다.

강의에서는 비관적 락과 낙관적 락을 다루셨는데, 일반적으로 대규모 서비스가 아닌이상 좋아요 자체가 순식간에 많은 트래픽이 몰릴것같지않아 낙관락으로 처리하는 것이 더 효율적일것같다고 생각이듭니다. 그래도극단적인 상황을 대비해서, 뒤에서 나오는 조회수 처리처럼 레디스로 좋아요 수를 증가시키고 스케줄링같은걸로 RDB에 백업하는 방식은 어떤가요?동시성처리에서 비관적 락으로만 처리해야 하는 상황이 있을까요? 레디스의 분산 락을 사용하는 것이 성능 측면에서 비관락보다 유리할 때도 있을 것 같은데, 실제로 비관락을 반드시 써야 하는 예시나 사례가 궁금합니다.RDB 트랜잭션(@Transactional) 내부에서 레디스를 함께 업데이트하는 경우, RDB에서 장애가 발생해서 롤백이됬는데 Redis 만 데이터가 업데이트 되는 경우도 발생할수도 있을것같은데. 이런 경우를 어떻게 처리하는지, 2PC를 적용하는지 아니면 다른 방법이 있는지도 궁금합니다.

1. 현재 학습 진도redis 2. 어려움을 겪는 부분 간단하게 제 프로젝트를 소개하자면 RSS피드를 통해 블로그의 글들을 불러와서 하나의 게시판에서 볼 수 있는 서비스 입니다.스케쥴러 작업에서 구독한 피드의 새로운 글들을 불러옵니다. 피드마다 비동기로 병렬 처리됩니다.이때 새로운 글인지 아닌지를 판단할 때 피드마다 redis를 사용하거나 피드마다 db의 조회를 통해 차이를 확인했는데 redis를 사용했을 때 빨라질 것이라 생각했지만 빠르지 않았습니다.3. 시도해보신 내용앞선 강의를 토대로 쿼리발생 횟수를 모니터링 횟수로 측정한 결과 피드가 100개일 경우 db의 조회를 활용했을 때 비동기 병렬 처리 되므로 100개의 select문이 나갑니다.redis를 사용했을 때는 0개의 select문으로 감소합니다. 하지만 성능은 비슷합니다.예상 가는 이유로는 redis를 사용했을 때 그 횟수가 너무 잦아서 redis에 연결하는 네트워크 시간 때문에 차이가 미미하다는 말이 있던 것 같습니다.만약 제 가설이 맞다고 한다면 redis를 사용할 때 항상 네트워크의 횟수를 최소화 해야만 redis의 성능을 온전히 이끌어 낼 수 있는건가요?보통 레디스를 사용할 때 이걸 다 생각하면서 1번만 redis가 조회 되도록 하고 생각하면서 쓰나요?그렇다면 제 코드에서 redis의 성능을 올바르게 나타내려면 피드의 새로운 글들을 하나의 List로 전부 묶은 후 redis에서 한번의 연결을 통해 한번에 캐싱을 확인해서 성능을 높여야 하는건가요?  

1. 현재 학습 진도부하테스트 2. 어려움을 겪는 부분부하 테스트의 코드를 통해 성능 개선 사례를 적으려고 합니다. 하지만 현재 평균 req_duration 즉 레이턴시가 너무 낮게 나옵니다. vus를 300으로 두었는데 아마 커넥션 풀이 모자라서 대기가 길어지는게 원인 같긴 합니다. 하지만 이걸 떠나서도 vus 300치고 너무 느리다고 판단되어서 이걸 개선했다고 포트폴리오에 쓰는게 의미가 있을지 걱정됩니다.또한 커넥션 풀이 모자라다고 대기업 개발자들이 항상 aws의 사양을 up시켜  커넥션 풀만 늘려서 해결하는 해결 방식을 사용하지는 않을 것 같은데 보통 성능 최적화를 통해 커넥션풀 점유를 짧게 해서 최대한 커넥션풀 고갈을 방지하는 방식으로 해결하나요?만약 그렇다면 성능 최적화 하는 방법에 부하를 분산하기 위한 kafka, redis, msa같은 기술들이 들어가는 건가요?마지막으로 성능 최적화를 포트폴리오 이력에 쓸 때 적절한 vus수가 궁금합니다 예를들어 면접관이 봤을 때 300명이라면 너무 적다고 판단되지 않을까 걱정되어서 어느 정도의 대략적으로 vus가 적정 인원인지가 궁금합니다, 3. 시도해보신 내용시도하진 않았지만 개선할 방법으로는 강의에서 제공해주신 mysql의 실행계획을 통해 index 추가와 커넥션풀 사이즈 늘리는 것 그리고 캐싱 도입을 생각하고 있긴합니다.