main 은 id를 가지고 있고, 이를 복제한 replica 들은 main 의 아이디로 그룹화되어 있음 그런데, main 이 어떠한 일로 인해(삭제 등) 새롭게 만들어지면 새로운 id 를 가지게 됨 이때 구 id 를 가지고 그룹화되어 있는 replica 들은 현재의 main 과 id 가 다르니 전체 동기화가 일어남 그러면, [구 id 를 가지고 그룹화되어 있는 replica 들] 은 계속 구버전 id 를 가지게 되는건가요? 아니면, 동기화 후 새로운 id 로 다시 그룹화가 되는 걸까요? 추가로, 강의 초반에 위 내용 관련해서 '카프카와 비슷하다'라는 설명이 나왔는데, 카프카에 대해 잘 모르는 입장에서는 조금 혼란스러울 수 있을 것 같습니다. 가능하시다면 추후 강의를 개선하실 계획이 있으실 경우 이 부분을 조금 더 자세히 설명해주시면 좋을 것 같습니다.
안녕하세요 강사님! Look-Aside 패턴과 Thundering Herd 관련 강의(3:37~) 내용을 듣다가 궁금한 점이 있어 질문드립니다. 캐시-어사이드 패턴에서 캐시 미스가 발생했을 때, 강의 중 보여주신 그림에서는 ‘ 캐시가 직접 DB를 조회하고 데이터를 업데이트한 뒤 서버에 응답까지 전달하는 구조 ’ 처럼 표현해주셔서 다소 혼란스럽습니다. 제가 알고 있기로는 캐시-어사이드 패턴은 캐시 미스 발생 시 애플리케이션(서버)이 직접 DB를 조회하고, 조회한 데이터를 캐시에 갱신(PUT)한 뒤 클라이언트에 응답하는 방식으로 동작하는 것으로 알고 있습니다. 만약 MSA 환경에서 캐시 서버가 별도로 구성되어 있고, 데이터를 API 통신 형태로 제공하는 구조라면 그림으로 그리시면서 설명해주신 부분이 어느 정도 이해가 되지만, 해당 파트가 MSA 를 전제하고 설명하는 맥락은 아닌 것 같아서요. 혹시 이 부분에 대해 제가 잘못 이해한 부분이 있다면 피드백 주시면 감사하겠습니다!
안녕하세요 강사님 ! 강의 잘듣고 있습니다. 강의를 거의 다들었는데, Monolithic Architecture로 마이그레이션 해보고 싶다는 생각이 들어 해보려고 합니다. 각각의 모듈을 하나의 어플리케이션의 패키지로 만들기만 하면 될까요 ? 어느 부분을 신경쓰면 좋을지 간단하게라도 조언해주시면 정말 감사드리겠습니다 .!! 이 강의를 듣기를 진심으로 잘했다는 생각이 듭니다. 좋은 강의 해주셔서 감사드리고 다음 강의도 기대하겠습니다 !!
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 2주차 성능 테스트 챕터까지 수강했습니다. 제목처럼 강의 주요 내용은 아니지만 궁금한 점이 생겨 글 작성하였습니다. 질문에 악의가 없는데, 쓰다보니 공격적인 말투로 느껴지네요... 죄송합니다. 공격이 아니고 제가 공부한 부분과 달라서 어떤 게 맞는지를 여쭙고자 작성한 질문입니다. 작성해주신 포트폴리오 코드를 보면, A Service에서 A Repository, B Repository, C Repository 등을 주입받아 사용하셨는데 이게 올바른 구조인가요?? 상황: 현재 저는 계층형 폴더 구조(Controller, Service, Repository 등)가 아닌 도메인형 폴더 구조(User, Post, Tag 등)를 가져가고 있습니다. 계층형과 도메인형 모두 자신의 도메인이 아닌 다른 도메인의 다른 레이어 파일을 주입받기 보다는 Service는 Service끼리 주입을 받는 게 결합도를 낮추고 리팩토링하기 편한 방향이라고 생각했습니다. 이러다보니 Controller에서 호출하는 함수는 DTO로 통신을 하고, Service끼리 사용하는 함수는 Entity로 통신을 하게 되었습니다. 주석으로 "Interal method"라고 명시를 하였지만, 응답 형식만 다를 뿐 같은 일을 하는 함수도 많아져서 이게 맞는건가 싶은 고민이 있었습니다. 애초에 Repository를 쓰는 것도 여러 파일에서 쉽게 불러쓰기 위해서라는 말도 봤던 것 같아서 뭐가 맞는지 정답이 궁금합니다. TPS 기준이 궁금합니다. 현재 쿠폰 시스템 비슷한 프로젝트를 하고 있는데, "우리 서비스의 TPS가 몇이다"라고 할 때는 가장 주요한 로직 기준으로 측정한 결과일까요? 아니면 모든 API 중 가장 낮은 TPS가 기준이 될까요? 또한 TPS 300이 되기 위해서, 400이 되기 위해서 이런 식으로 말씀해주셨는데, Insert 또는 Update 작업이 포함된 경우 어느정도 TPS가 나오면 적지 않은 수준일까요? 감사합니다.
안녕하세요 Transactional Outbox 모듈 적용 부분을 듣던중에 차이가 발생해서 질문드립니다. 강의에서는 이제 각 나눠진 기능마다 XXXAplication 클래스에 EntityScan과 EnableJpaRRepositories 애노테이션을 달아주는것만으로도 다른패키지에있는 outboxEventPublisher를 사용할 수 있는데 저는 인식을 못합니다. application클래스에 @componentScan(...) 까지 달아주고나서야 비로서 인식이 되기 시작하는데 혹시 뭐가 문제고 무슨 차이가 있는걸까요 ... 찾아봤는데 잘 안보입니다 ㅠㅠ
안녕하세요 ! 좋은 강의 해주셔서 감사합니다. 섹션 4의 댓글 수 구현 강의 3분 39초 경에서 질문 있습니다 . 선생님의 코드에서는 댓글을 물리적 삭제할때만 댓글 수를 decrease를 통해 줄여주고 있는데, 논리적 삭제 시에도 count를 줄여주는 것이 맞다고 생각해서 질문글 남깁니다. 왜 물리적 삭제 시에만 댓글 수를 decrease 하시는 건가요 ?
안녕하세요, 강사님 늘 강의 잘 듣고 있습니다, 감사합니다 ! 다름이 아니고, @Transactional과 @TransactionalEventListener 설정 관련해 궁금한 사항이 있어서 문의드리게 되었습니다. 강의내용은 @Transactional, @TransactionalEventListener가 전역적으로 선언되었고 outbox 관련 로직만 존재하기 때문에 괜찮지만 제 업무환경에서는 @TrasnactionalEventListener가 사용되면 프로젝트의 모든 @Transactional으로 관련된 내용이 바인딩되기 때문에 이를 scope 별로 구분하는 방법이 필요해보였는데요. 따로 알아보았지만, payload(강의에서는 OutboxEvent) 를 통해 분기처리하는 방법만 보이다보니 혹시 관련하여 TrasnactionalEventListener 어노테이션 필드 혹은 커스텀 어노테이션만으로 구분할 수 있는 방법이 있을까요 ? 문의드리는 가장 큰 이유는 outbox 로직이 필요없는 DB처리에도 TrasnactionalEventListener이 우선은 호출되고 payload를 통해 early return 시키려고 하다보니, 불필요한 리소스 사용을 방지하고 싶어서 문의드리게 되었습니다.
안녕하세요. 예전에 리뷰 이벤트를 신청했었던 사람이니다. 당시 구매한 강의 3개(레디스, 스칼라, 그래들)를 수강했던 수강생입니다. 당시 리뷰 이벤트로 강의를 제공받은 후, 개인적인 오해와 감정적인 대응으로 인해 영자 측에 해당 강의들 모두 철회 요청을 드렸었습니다. 지금 돌이켜보면 너무 감정적으로 행동했던 것 같고, 다소 어리석은 선택이었음을 느끼고 있습니다. 그 후 지식공유자님께도 별도로 사과의 말씀을 전한 적이 있으며, 그때의 제 행동에 대해 진심으로 반성하고 있습니다. 이메일 cis940320@gmail.com 으로 신청을 드렸었고, 해당 메일 내역을 통해 당시 리뷰와 신청한 강의 내역도 확인 가능하실 것이라 생각됩니다. 혹시 가능하다면, 철회했던 강의들을 다시 수강할 수 있는 기회를 부탁드릴 수 있을까요? 당시에 제가 작성했던 리뷰도 정성스럽게 남겼던 기억이 있어, 다시 한 번 수강할 수 있게 된다면 더욱 성실하게 공부하고 의미 있게 활용하고 싶습니다. 번거롭게 해드려 정말 죄송하고, 답변 기다리겠습니다. 감사합니다.
안녕하세요! 우선 강의 너무 잘 듣고 있습니다! 강의 자료에서 좋아요 수 설계 부분에서 11:17 1:1 관계이지만, 테이블 비정규화의 필요성을 살펴본 것이다. 이 부분은 1:1 관계이므로 비정규화의 필요성이 있지만, 레코드 락으로 인한 자원 한계를 고려하여 '정규화'의 필요성을 살펴본 것 이 맞지 않나 싶습니다! 혹시 제가 잘못 이해한 부분이 있다면 알려주시면 감사하겠습니다!
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 3-6. 쿼리플랜이란? 여기까지 이해하신 내용은 무엇인가요? 옵티마이저가 스토리지 엔진으로부터 가장 효율적으로 데이터를 가져오기 위해 쿼리플랜을 작성한다는 것을 이해했습니다. 2. 어려움을 겪는 부분 어떤 개념이 헷갈리시나요? 이때 인덱스를 참고해서 데이터를 가져온다면 이 인덱스는 메모리에 올라와 있는 상태인가요?? 아니면 디스크에 있는 인덱스를 확인하고 디스크에서 데이터를 가져오는 건가요? 데이터를 가져오는 전체적인 흐름이 궁금합니다! 3. 시도해보신 내용 문제 해결을 위해 어떤 시도를 해보셨나요? 에러가 발생했다면 어떤 에러인가요? 현재 작성하신 코드를 공유해주세요 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!
위의 내용과 같이 언제, 어떻게 만료 시킬 지에 대한 만료 방식을 cache eviction이라고 해주셨는데 검색해보니까 내용 상의 차이가 있다는 것을 알게 됐습니다. TTL, TTI와 같은 특정 시간, 점유 시간에 대해 발동되어 cache expiration으로 정의가 됐습니다. 반면 cache eviction은 메모리 공간이 부족한 경우 발동되어 LRU, LFU, FIFO 등으로 구분됐습니다. 결국 둘 다 캐시 삭제 기법이긴 하나, 트리거 조건에 차이가 있었습니다. 면접에서 eviction 관련 질문을 받는다면 둘을 혼용해도 무방할까요?
안녕하세요 선생님 좋은 강의 감사합니다. 저희 articleController에서 readAll 부분을 보면 @GetMapping("/v1/articles") public ArticlePageResponse findAll( @RequestParam("boardId") Long boardId, @RequestParam("page") Long page, @RequestParam("pageSize") Long pageSize ) { return articleService.readAll(boardId, page, pageSize); } 이런식으로 pageSize를 쿼리 파라미터로 넘겨주도록 설계가 되어 있는데, pageSize라는 파라미터는 값을 받아서 처리하는 것이 아니라, 서버에서 값을 정하고 항상 똑같은 pageSize를 써야하는 것 아닌가요 ?? 왜 pageSize를 인자로 받는지 이해가 잘가지 않습니다.
안녕하세요 선생님 강의 잘 듣고 있습니다 . controller를 구현하실때 중복되는 부분을 전부 다 쓰신 이유가 따로 있으신가요 ? 예를 들어 ArticleController에서 @RequestMapping("/v1/articles") public class ArticleController{ ... } 이런식으로 RequestMapping 애노테이션을 붙여 중복을 줄일 수도 있는데 선생님은 전부 다 그냥 쓰셔서 어떤 의도가 있는 것인지가 궁금합니다.
현재 페이지네이션 기반 조회 시 조회 과정이 궁금해서 질문드립니다. secondary index에서 offset 위치까지 순차탐색 -> secondary index -> 클러스터링 인덱스에서 primary key 조회 -> 실제 데이터 조회 일단 위 과정이 맞는지 궁금합니다. 2 . 위 과정이 맞다면 이 과정에서 db에서 데이터 조회를 limit만큼 반복하는 것인지, 아니면 실제 db에서 데이터 조회는 한 번에 이루어지는 것인지 궁금합니다. 페이지 조회 말고 그냥 범위 조회일 시에는 한 번에 조회되서 값이 많아도 시간 차이가 많이 안나는지 궁금합니다. offset 없이 조회해보니 바로 조회되는 거 같긴합니다.
