프로메테우스에서 쿼리 카운터 검색이 안됨

민우님 안녕하세요!! 오늘도 좋은 질문 해주셔서 감사합니다!!executor_thread 같은 기본 메트릭은 잘 가져온다는 건 말씀해주신대로 프로메테우스와 EC2 연결 자체는 문제없다는 것 같습니다! EC2에서는 아직 API 호출이 없어서 메트릭이 생성되지 않았을 수 있습니다. 로컬에서는 테스트하면서 여러 요청을 보냈지만, EC2에서는 아직 요청이 없어서 Timer 메트릭이 생성되지 않은 것 같은데, 해당 메트릭을 생성하는 API 를 호출한 뒤에 한 번 결과를 확인해보실 수 있을까요?

오타가 있습니다.

안녕하세요 qkrwlsn102109님!!! 헛 그렇네요!!! 교재 작업하면서 오타가 있었던 것 같습니다 😢😢😢😢제보해주셔서 넘넘 감사드립니다!!!! 곧바로 수정해두겠습니다 너무너무 감사드립니다!! 🙇🙇🙇

9. 1-6 시간복잡도 계산하기

안녕하세요 커디널스님! 좋은 질문 감사합니다!! 교재상 반영되지 못한 오류가 있었던 것 같습니다 제보 감사드립니다!!! 해당 부분 교재에 설명 추가해두겠습니다 질문해주셔서 감사드립니다!!! 이해하는데 불편을 드렸다면 넘 죄송합니다 🙇🙇

colab 프로그램 설정 관련 안내

안녕하세요 정은님! 좋은 질문 감사합니다 7번째 강의인 2-1. colab 기초설정 편에서 확인하실 수 있습니다 https://inf.run/ZpWpg

RedisTemplate<String, String>

안녕하세요 kongminoo님! 좋은 질문 감사합니다!!네, 스프링부트에서는 spring-boot-starter-data-redis 의존성을 추가하면 자동 설정(auto-configuration)을 통해 StringRedisTemplate이 자동으로 빈으로 등록됩니다.스프링부트의 RedisTemplate 자동 설정 과정은 다음과 같습니다!RedisAutoConfiguration에서 자동으로 StringRedisTemplate 빈을 생성합니다StringRedisTemplate은 RedisTemplate을 상속한 클래스입니다따라서 별도로 빈 등록 없이도 생성자 주입으로 사용할 수 있습니다 // RedisAutoConfiguration 내부 코드 @Bean @ConditionalOnMissingBean @ConditionalOnSingleCandidate(RedisConnectionFactory.class) public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) { return new StringRedisTemplate(redisConnectionFactory); }오늘도 좋은 하루 되세요!!

노션에 오타가 있서요

안녕하세요 kongminoo 님!!!앗 맞네요!!! 제보 감사드립니다! 변경해두겠습니다!! ㅎㅎㅎ주의깊게 봐주셔서 넘넘 감사드려용 😍😍😍

@Async 여부의 차이가 궁금합니다.

안녕하세요 kongminoo님, 좋은 질문 감사합니다!맞습니다! 민우님이 스스로 찾으신 답변이 정확합니다!!@Async 없이 @TransactionalEventListener만 사용클라이언트 → (쓰레드 A) 메인로직 수행 → (쓰레드 A) 이벤트 처리 → (쓰레드 A 반환) 클라이언트에게 응답문제점: 카카오톡 API 호출이 2초 걸린다면, 사용자는 이벤트 참가 후 2초를 더 기다려야 함실제 응답 시간: 메인 로직 + 알림 발송 시간@Async와 @TransactionalEventListener 함께 사용클라이언트 → (쓰레드 A) 메인로직 수행 → (쓰레드 A 반환) 클라이언트에게 즉시 응답 → (쓰레드 B) 이벤트 처리장점: 사용자는 이벤트 참가 완료 후 즉시 응답을 받음실제 응답 시간: 메인 로직 시간만실무에서는 이런 부분도 고려해야 해보시는 걸 추천드립니다!비동기 처리 실패 시 재시도 로직스레드 풀 설정 (기본 SimpleAsyncTaskExecutor는 위험)알림 발송 실패에 대한 모니터링이런 경험을 쌓아서 이력서에 써보시는 걸 추천드리빈다!! 항상 좋은 질문 감사드립니다!좋은 주말 보내세요~~~

강의 상 구현 하는 내용과 강의 책 구현 요구 내용이 조금 달라요

안녕하세요 Sooin 님!! 좋은 질문 감사합니다!!말씀주신대로, 교재의 문구가 잘못되었음을 확인했습니다! 덕분에 해당 내용을 변경할 수 있었습니다 감사드립니다!! 강의에 기여해주셔서 감사합니다!! 언제든 편하게 질문해주세요 ㅎㅎㅎ 좋은 하루 보내세요!!

[2주차] 곁다리 질문

안녕하세요 수환님!! 좋은 질문 넘넘 감사드립니다!!한번 질문 주신 내용에 대해 답변드려보겠습니다. 그리고 표현에 대해서도 미리 말씀 주셔서 전혀 전혀 전혀!!! 불쾌하지 않았습니다!! 구조적인 고민을 깊이 하시는 것 같아 오히려 인상적이었습니다!! 더 맘껏 질문해주세요 ㅎㅎㅎ 서비스에서 여러 Repository를 주입받는 구조 말씀하신 것처럼 도메인 기반 구조에서는 자신의 도메인이 아닌 다른 도메인의 내부 구현(예: 다른 도메인의 Repository)에 직접 접근하는 것이 바람직하지 않다고 보는 시각이 많습니다. 이 관점에서는 각 도메인의 Service끼리 협력하는 구조가 더 느슨한 결합을 유지할 수 있는 방향입니다.다만, 실제 운영되는 서비스에서는 아래와 같은 이유로 Repository를 여러 개 직접 주입하는 경우도 있습니다 복잡한 비즈니스 로직 없이 간단한 쿼리 조합만 필요한 경우 그러합니다. (저희 서비스의 경우에도 그러했스빈다)즉, 이 구조가 절대적으로 잘못되었다기보다는 상황에 따라 타협하는 부분이 많습니다. 다만, 리팩토링 가능성이나 테스트 용이성을 생각하면, 서비스 간 의존을 통해 협력하도록 구성하는 것이 더 일반적인 방향이고, 그렇게 구성하는 것이 더 좋다고 판단되는 경우가 많습니다!!이번 프로젝트에서는 DDD 관점의 아키텍쳐 보다는, 코드 자체의 흐름을 이해하기 쉽게 만들기 위해서 어느정도의 중복을 허용한 상태로 코드를 작성했기에 충분히 수환님과 같은 생각을 하실 수 있을 것 같습니다!! 말씀해주신 것처럼 DTO/Entity 기준으로 인터페이스를 구분하고, 서비스 간 협력을 재정비하거나, 역할 분리를 다시 점검해보는 편이 더 좋을 것 같습니다 좋은 질문 감사드립니다!!TPS 기준에 대해TPS를 이야기할 때 기준이 모호할 수 있는데, 보통은 서비스에서 가장 중요하거나 병목이 될 가능성이 높은 경로(주요 API나 비즈니스 로직 기준)로 측정합니다.예를 들어, 쿠폰 시스템이라면 "쿠폰 발급"이나 "쿠폰 사용 처리"와 같이 Insert 또는 Update가 발생하고 동시성이 중요한 작업을 기준으로 삼는 경우가 많습니다. 단순 조회 API 기준 TPS는 참고로 보되, 기준점으로 잡지 않는 경우가 일반적인 것 같습니다!!그리고 TPS가 어느 정도면 “적지 않은 수준”인지에 대해 제 주관적인 기준을 말씀드려볼게요!! 일반적인 CRUD 기반 웹서비스에서는 Insert/Update 포함 100~200 TPS만 되어도 꽤 많은 동시 처리를 의미합니다. 대규모 플랫폼 서비스라면 300~500 TPS 이상, 경우에 따라 수천 TPS 이상도 요구되지만, 이는 주로 고도화된 시스템이나 캐시, 비동기 처리 등을 통해 달성되는 것 같습니다!!수환님 좋은 질문 감사합니다!! 언제든 편하게 질문해주세요 ㅎ.ㅎ

실행계획에서 드라이빙 테이블과 드리븐 테이블을 판단하는 기준

안녕하세요 cho766님!! 좋은 질문 너무너무 감사합니다!!우선, 실행계획에서 드라이빙 테이블과 드리븐 테이블 구분 기준을 구하는 방법을 말씀드려보겠습니다!강의에서 말하는 "실행계획 결과에서 멤버 테이블이 먼저 나왔기 때문에 드라이빙 테이블"이라는 설명은 EXPLAIN명령으로 출력된 값을 기준으로 한 것입니다! EXPLAIN 결과에서 table 컬럼에 나열된 순서가, MySQL의 Nested Loop Join에서 outer loop (드라이빙 테이블) → inner loop (드리븐 테이블) 순서를 보여줍니다. 따라서 EXPLAIN 결과에서 m 테이블이 먼저 나오고, o 테이블이 두 번째로 나왔다면, m이 드라이빙 테이블입니다! 질문에 언급하신 다이어그램은 조인의 흐름을 시각적으로 표현한 것이지만, 테이블 순서(outer/inner)는 명시적으로 보이지 않습니다. 따라서 EXPLAIN으로 출력한 텍스트 결과표 기준으로 실제로 드라이빙/드리븐 테이블의 순서를 파악해야 합니다! 그럼 여기서 더 나아가서 추가적으로 왜 멤버 테이블을 먼저 읽을까? 라는 궁금증이 생길 수 있습니다! MySQL 옵티마이저 조인 순서를 결정할 때 다음과 같은 요소들을 고려합니다.테이블 크기 (row 수) : 일반적으로 더 작은 테이블을 드라이빙 테이블로 선택하는 경향이 있습니다. 멤버 테이블은 보통 회원 수(예: 몇 천 ~ 몇 만)로 제한적이지만, 주문 테이블은 회원당 여러 건이 쌓이기 때문에 훨씬 클 가능성이 높습니다. 따라서 작은 테이블인 멤버(m) 테이블을 먼저 읽고, 그에 해당하는 주문만 찾는 것이 더 효율적입니다.조건절 및 인덱스 사용 가능성 : 옵티마이저는 WHERE, ON 조건절에서 사용 가능한 인덱스 유무도 고려합니다. 예를 들어, 멤버 ID로 조인을 걸고 이 ID에 인덱스가 있다면, 멤버 테이블에서 한 행을 가져와서 주문 테이블에서 인덱스를 통해 빠르게 조회할 수 있습니다! 즉, 멤버 테이블 한 건 → 주문 테이블에서 매칭되는 건만 찾아가는 Nested Loop 방식에 최적화되어 있다고 할 수 있습니다좋은 질문 주셔서 감사합니다 초님!! 해당 내용은 교재에도 추가로 서술해두도록 하겠습니다 기여해주셔서 감사드립니다!!