MacOs 사용자 분들이시고 cat ~/.docker/config.json 의 결과에 credsStore 필드가 osxkeychain이고 auth 필드의 값이 비어있으신 경우 인증정보가 keychain으로 관리되고 있고 이걸 jib이 가져오지 못하고 있는 겁니다. 방법 1 (가장 추천합니다) jib 내부의 from과 to 블록의 image 선언 다음 credHelper { helper = "osxkeychain" } 해당 코드를 추가해 keychain에 접근할 수 있도록 해주면 좋습니다. + auth {}로 인증정보를 주입하는 방법으로도 대체 가능합니다. 방법 2 (문제 회피) java 25 이미지를 docker pull 받아 로컬에 두고 ./gradlew jibDockerBuild 하시면 됩니다. 나중에 redis를 받던데 그때로 같은 방법으로 해결하면 될 것같습니다. 방법 3 (keychain 필드깨서 강제로 base64쓰게 하기) credsStore 필드를 훼손시켜 강제로 auth에 암호화된 내용을 저장하도록 하는 것같습니다. 정말 추천하지 않으며, 위 방법이 모두 실패하면 시도해보세요.
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요 쿠케님 강의 너무 잘 보고 있습니다. 해당 내용 수강중에 궁금한 점이 생겨 질문 드립니다. 혹시 제목이나 내용을 검색한다고 했을때는 redis에서 조건을 통해 조회를 하는것인지 다른 전략이 있는지 궁금합니다!
안녕하세요 쿠케님! 현재 구현되어 있는 댓글 삭제 로직을 보면 1. 댓글 조회 2-1. 자식 댓글이 존재하면 deleted=true 로 변경 2-2. 자식 댓글이 존재하지 않으면 댓글을 물리 삭제하고, 부모 댓글을 재귀적으로 삭제 이렇게 구현되어 있는데요. 동시성 문제가 발생할 수 있겠다는 생각이 들었습니다! T1 삭제 트랜잭션 T2 답글 트랜잭션 ──────────────────────────────────────────── SELECT 부모 SELECT 자식 → 없음 SELECT 부모 → ACTIVE INSERT 답글 COMMIT DELETE 부모 COMMIT (제가 잘 분석한게 맞나 모르겠네요 ㅎㅎ) 물론 이렇게 꼬일 확률은 낮지만, 이런 케이스에 대해서는 select for update를 거는 것이 좋을지, 아니면 fk를 추가하여 정합성을 보장해줘야 할지, 쿠케님 의견을 묻고 싶습니다.
강사님 안녕하세요, 좋은 강의 여러번 반복해서 잘 듣고 있습니다. 재고 감소와 비교했을때 차이점이 궁금하여 문의드립니다. 안녕하세요 강사님 이전 재고 관리 강의와 차이에 대해 궁금합니다. 이전 질문을 참고하였으나 추가로 더 궁금한게 있어서 문의드립니다. 재고 감소와 쿠폰 발급의 차이점이 너무 헷갈려서 정리하고 있습니다. 두 경우 모두 한정된 수량을 여러 요청이 동시에 차지한다는 점에서는 비슷해 보입니다. 그렇다면 쿠폰도 이벤트 테이블에 잔여 수량을 100개나 300개로 설정하고, 재고처럼 수량을 차감한 뒤 사용자 쿠폰을 생성하는 방식으로 구현할 수 있지 않을까요? 강의에서는 쿠폰 발급의 정합성을 위해서 전체 로직에 락을 걸 필요가 없다고 하셨는데, 그러면 반대로 재고 감소 같은 경우도 마찬가지로 재고 감소의 정합성을 위해 전체로직에 락을 걸 필요 없이 다른 방법으로 하는게 더 나은 방법 아닌가요?? 비슷해 보이는 한정 수량 문제를 서로 다르게 푼 이유를 잘 모르겠습니다 ㅠㅠ
1. 현재 학습 진도 섹션 3 15강 수강 2. 어려움을 겪는 부분 아직 섹션3 15강밖에 수강하지 않았지만 예전에 배포했을때 설정 문제로 과금이 나간적이있어서 강의는 계속 들으면서 로컬에서 해보고 개인 프로젝트에 적용해보는것이 좋을까요? 아니면 둘 다 하는것이 좋을까요??
안녕하세요, 강사님 🙂 덕분에 코프링을 빠르게 배우고 있어 감사드립니다! 영상 8:20 경, JWT 설명 중 withSubject() 의 값으로 email 만 넣는다던가, name 만 넣어서 구현한다고 말씀주셨습니다. 고민을 해봤지만 여러 개의 Subject 를 만드는 이유가 궁금해서 질문드립니다. 상황 예시와 함께 답변해주시면 감사드립니다!!
안녕하세요. 인기 게시판 목록 기능을 Redis의 Sorted Set을 활용해 좋아요 순으로 정렬하는 방식으로 구현하다 고민이 생겨 질문하게 되었습니다. 먼저 잦은 데이터 변경을 고려해서 Sorted Set의 member에는 게시판 ID만 저장하고, score에는 좋아요 수를 저장하도록 했습니다. 하지만 목록을 생성하기 위해서는 제목, 생성일 같은 부가 정보가 필요한데 이 데이터를 얻는 효율적인 방식에 대해 고민이 생겨 질문을 드리게 되었습니다. AI에게 도움을 받아 2가지 방법을 생각해보았는데 현실성이 있는지 판단 부탁 드립니다. Redis + RDB 조합 Redis ZSet에서 상위 10개의 ID 목록을 먼저 조회합니다. 해당 ID 목록을 가지고 RDB에 WHERE id IN (...) 쿼리를 날려 상세 데이터를 가져옵니다. 데이터베이스의 IN 쿼리는 순서를 보장하지 않기 때문에 애플리케이션에서 Redis가 준 ID 순서대로 리스트를 다시 재정렬하여 반환합니다. 제가 생각하기에는 인기 게시판 목록을 조회할 때마다 RDB의 ORDER BY 부하를 줄이려다 오히려 애플리케이션 단에서 정렬과 DB 조회가 일어나다 보니 얻는 것보다는 잃는 게 많은 구조가 아닌지 고민이 됩니다. Redis Sorted Set + Hash 조합 정렬 기준(ID, 좋아요 수)은 기존대로 Sorted Set에 관리합니다. 게시판의 상세 부가 정보는 Redis의 Hash 자료구조에 따로 캐싱합니다. 목록 조회 시 Sorted Set에서 ID를 뽑은 후 DB를 거치지 않고 Hash에서 상세 데이터를 조회합니다. 이 방식은 DB에 부하를 줄일 수 있지만 데이터가 자주 변하게 된다면 레디스에서 데이터를 자주 변경해야 되어 메모리에 큰 부하를 줄 수 있을 것 같아 고민이 되는 것 같습니다.
안녕하세요 딩코님! 좋은 강의 잘 들었습니다. 강의를 듣다가 조언을 구하고 싶은게 있어서 질문 남깁니다. 저는 현재 주니어 개발자로 일으나 부하테스트 같은것을 회사에서 해볼 수 없는 상황이라(운영 인력이 아님...또한 작은 시스템이라 모니터링도 없고 구축할수도 없는 환경)강의에서 다뤄주신 내용을 실무에 적용해보기가 어려운데요... 그래서 제가 생각해본게 테스트 코드로 만들어서 돌려보면 어떨까 생각했거든요. 예를들어 아래와 같은 메소드를 만들어 놓고, 캐시 전/후를 비교하는 거죠... long start = System.currentTimeMillis(); service.findSomething(id); long elapsed = System.currentTimeMillis() - start; System.out.println(elapsed); 그런데 한가지 고민되는 포인트가, 테스트 코드로 만들어서 돌렸을때 성능 개선을 수치적으로 적기가 좀 애매할것 같다고 생각이 들어서요. 아무래도 JVM이라던지, warmup이라던지 통제할 수 없는 변수가 있다보니까요. 그래서 질문은 아래와 같습니다. 특정 메소드에 로컬 캐시를 적용하기 전/후 테스트 코드에서 성능을 비교 했을때, 1초->1ms로 성능 개선했다. <- 이런 문장이 임팩트가 있을까요? 아님 테스트 코드에서 한건 좀 신뢰성이 떨어질까요? ㅠㅠ 테스트 코드에서 돌려봤을때 누가봐도 신뢰성있게 만들려면 어떻게(?), 무슨 툴(?)을 써서 하는게 좋을까요? ㅠㅠ 저 같이 운영 환경에 적용해볼수 없는 개발자에게 조언을 주시면 또 감사하겠습니다!
커머스 서비스로 배우는 NestJS 실전 개발 (w. Prisma, Docker, Redis, Kafka)
prisma generate로 생성했으면 qty, unit_price 같은 값들 number | null 이라 필터링을 한번 해줘야 될텐데 강사님 코드에는 그런 흔적이 없이 깔끔하게 처리되어 빌드가 잘되는거 같아보여요. 물론 사소한것이지만 라이브러리 버전차이인지 따로 처리해준게 있는건지 궁금합니다
안녕하세요. 최근 수백만 동시 접속을 처리하는 예매 시스템 아키텍처 관련 강의와 유튜브 영상을 참고하면서, 작은 프로젝트로 선착순 쿠폰 발급 시스템을 직접 구현해보며 학습하고 있습니다. 현재는 Redis를 활용해 선착순 쿠폰 발급을 구현하는 구조를 고민하고 있는데, 몇 가지 아키텍처 설계에 대해 궁금한 점이 있어 질문드립니다. 1. Redis + DB 원자성 관련 Redis에서 쿠폰 발급 가능 수량을 감소시키고, 동시에 DB에도 반드시 반영(쿠폰 발급 및 사용자 할당 기록)해야 하는 상황을 가정하고 있습니다. 이 경우 Redis의 재고 감소와 DB 반영을 하나의 트랜잭션처럼 원자적으로 묶어야 할 것 같은데, 현실적으로는 분산 환경 특성상 이를 직접적으로 묶는 것이 어렵다고 이해하고 있습니다. 그래서 일반적으로는 Lua Script로 Redis 내부에서 쿠폰 재고 감소 중복 발급 방지 처리 Redis Stream(또는 Queue)에 발급 이벤트 기록 을 원자적으로 수행하고, 이후 별도의 스케줄러(또는 Worker)가 해당 Stream을 읽어서 DB에 반영하는 방식 으로 설계하는 것이 맞는지 궁금합니다. 2. 메시지 큐(Kafka 등) 사용 시 구조 또한 쿠폰 발급 결과를 Kafka 같은 메시지 큐로 전달하는 방식도 있을 것 같은데, 이 경우에도 동일하게 Lua Script로 Redis 내부에서 쿠폰 재고 감소 중복 발급 방지 처리 Redis Stream(또는 Queue)에 발급 이벤트 기록 이후 스케줄러가 stream읽어서 Kafka로 전달 Consumer가 DB에 반영 과 같은 구조로 가져가는 것이 일반적인지 궁금합니다.
Lock 해제 코드에서 다른 사용자가 생성한 락을 삭제하지 않기 위해 본인의 identifier이랑 락의 value를 비교해서 삭제하는 로직 부분에서 궁금한 내용이 있습니다. 멀티스레드, 프로세스 환경에서 충분히 일어날 일 이라고 하셨는데 내가 락을 얻으면 다른 사용자는 락을 얻지 못해 value는 항상 나의 identifier이 들어있어야 하는게 아닌가? 라는 생각이 드는데 rd.set(lock_name, identifier, nx=True, px=lock_timeout_ms) 이 코드 방식으로 락을 만들면 여러 사용자가 특정 환경에 락을 얻을 수 있는건가요?
학습 중 궁금한 점이 있으시면 편하게 질문 주세요. 참고로 질문이 구체적일 수록 더 정확한 답변을 드릴 수 있습니다. 😊 안녕하세요. 강의를 듣고 있는 개발자입니다. 이전에 유튜브에서 선착순 예매 관련 영상을 봤었는데 해당 영상에서 레디스를 이용해서 대기큐를 구현하는 것을 설명해주셨는데 그거에 대해서 질문이 있습니다. 레디스의 소티드 셋에 넣고 폴링을 통해서 상태를 확인한다. 타 스케줄러가 소티드셋에서 꺼내서 액티브로 바꾼다 라는 설명이 있었는데, 정확히 어떤식으로 구현하는 건지가 궁금합니다. 스케줄러가 꺼내고 액티브 유저 set으로 집어 넣는건가요? 그리고 소티드셋에서 꺼내서 엑티브 유저로 만드는 작업은 원자적으로 처리되게 하는건가요?
