현재 게시글 작성 유저에 대한 게시글 알림 신청 유저 리스트를 불러오는 방식은 jpa를 통해 처리 → 이를 QueryDsl 을 이용한 방식으로 변경

swagger 테스트 도중 8080 → 8081 port 로 변경 시 404 에러 발생

{
  "timestamp": "2024-11-21T07:52:18.583+00:00",
  "status": 404,
  "error": "Not Found",
  "path": "/subscribe-service/write/subscribe/%7BauthorUuid%7D"
}

swagger의 AddServersItem의 값으로 "<http://localhost:8081/subscribe-service>" 되었지만 실제 테스트에 대해선/subscribe-service 가 추가 적으로 붙지 않아 발생했던 문제

.addServersItem(new Server().url("<http://localhost:8081/subscribe-service>"))
->
.addServersItem(new Server().url("<http://localhost:8081>"))

또는
@RequestMapping("/subscribe-service/write/subscribe")

기존 방식과의 비교 위해 약 500 개의 데이터 삽입 (authorUuid: normal-12345678)

@Test
	public void testBulkSubscribersRegistration() {
		// 주어진 authorUuid
		String authorUuid = "normal-12345678";

		// 500명의 subscriberUuid 생성
		List<String> subscriberUuids = IntStream.range(1, 11)
			.mapToObj(i -> "subscriber-" + i)
			.collect(Collectors.toList());

		// 각 subscriberUuid에 대해 Subscribe 엔티티 생성 및 저장
		for (String subscriberUuid : subscriberUuids) {
			Subscribe subscribe = Subscribe.builder()
				.authorUuid(authorUuid)
				.subscriberUuid(subscriberUuid)
				.build();
			subscribeRepository.save(subscribe);
		}

	}

조회 테스트: 218 ms (약 10000개 데이터)

@Test
	public void testQueryTimeForNormalAuthor() {
		// 주어진 authorUuid
		String authorUuid = "normal-12345678";

		// 조회 시작 시간 측정
		long startTime = System.nanoTime();

		// authorUuid로 구독자 조회
		List<Subscribe> subscriptions = subscribeRepository.findByAuthorUuid(authorUuid);

		// 조회 종료 시간 측정
		long endTime = System.nanoTime();

		// 조회 시간 계산 (밀리초 단위로 변환)
		long durationInMillis = (endTime - startTime) / 1_000_000;

		// 결과 출력
		System.out.println("조회 시간: " + durationInMillis + " ms");

		// 결과 검증 (예: 구독자가 존재해야 함)
		assertThat(subscriptions).isNotEmpty();
	}

Msa를 적용한 만큼 대용량 데이터에 대한 처리가 필요하다고 판단

• 1차적으로는 jpa를 이용한 조회에서 QueryDsl 을 이용해보자고 판단

  → But 다만 한 유저에 대해 게시글 알림 신청한 유저의 수가 매우 커질것이라고 생각되지 않음

  → 조회대상인 AuthorUuid에 대해 인덱스 최적화를 하기에는 AuthorUuid를 unique 속성으로 받지 않고 있음

  → QueryDsl의 장점인 “동적 쿼리 생성”, “복잡한 쿼리 지원” 은 조회 성능 개선의 목적과 거리가 있다고 판단하기에 다른 방법이 필요

  → 알림 신청한 유저가 수시로 변경된다고 판단되지 않기에 @Cacheable 을 적용

캐싱 처리에 대하여 구현체로 “Caffeine” 사용 ← 고성능 java 기반 캐시

@Test
	public void testQueryTimeForNormalAuthor() {
		String authorUuid = "normal-12345678";

		// 첫 번째 호출
		long startTime = System.nanoTime();
		SubscribeResponseDto response1 = subscribeService.readSubscribers(authorUuid);
		long endTime = System.nanoTime();
		long duration1 = (endTime - startTime) / 1_000_000;
		System.out.println("첫 번째 조회 시간: " + duration1 + " ms");

		// 두 번째 호출 (캐시에서 가져와야 하므로 시간이 줄어들어야 함)
		startTime = System.nanoTime();
		SubscribeResponseDto response2 = subscribeService.readSubscribers(authorUuid);
		endTime = System.nanoTime();
		long duration2 = (endTime - startTime) / 1_000_000;
		System.out.println("두 번째 조회 시간: " + duration2 + " ms");

		assertThat(response1.getSubscriberUuids()).isNotEmpty();
		assertThat(response2.getSubscriberUuids()).isEqualTo(response1.getSubscriberUuids());
	}