Record 패턴 지원으로 간편한 DTO 설정 가능

• Record 패턴이란? 데이터만을 포함하는 불변한 객체로 선언할 수 있게 해주는 패턴
• Record 클래스는 14부터 사용 가능하나 패턴으로 사용 가능한건 21부터

LTS 중 최신으로 2031년까지 지원 예정

Virtual Thread 지원

JDK 21의 신기능 Virtual Thread 알아보기 (안정수 James)

Core Libraries

[Project Loom] Virtual Thread에 봄(Spring)은 왔는가 | 카카오페이 기술 블로그

Virtual Thread(가상 스레드, 경량 스레드)란?

• (JAVA21 official docs) 특정 OS 스레드에 종속되지 않는 인스턴스, OS 스레드와 다수의 Virtual Thread가 매핑됨
• 기존 스레드는 실제 OS 스레드와 1:1 매핑되어 컨텍스트 스위칭 시 OS가 개입하는 등 비용이 높았음
• JVM 자체적인 스케쥴링으로 컨텍스트 스위칭 비용이 줄어 효율적으로 운영할 수 있음
• 블로킹 I/O 작업에 적합함

Virtual Thread 사용 시 유의사항(JAVA21 official docs)

• 가상 스레드 풀링 금지
  • 가상 스레드는 자원의 개념보다는 작업의 개념으로 봐야 함. 플랫폼 스레드를 사용할 때는 자원을 미리 확보한다는 개념으로 풀링했지만, 가상 스레드는 풀링하면 비효율적임. 한 작업에 한 가상스레드!
• 제한적인 리소스 접근 및 사용 시 Semaphore를 사용한다.
  • 세마포어 : 한 리소스에 최대 n개의 접근만 허용하는 기법
  • DB의 경우 커넥션 풀이 세마포어의 역할을 함
• 재사용 가능 객체 유지하지 말 것
  • 가상 스레드는 한 작업에 하나 할당됨. 캐싱하는 것은 해당 패턴에 위배
• 길고 빈번한 pinning 지양
  • pinning : 가상 스레드가 특정 플랫퐄 스레드에 고정되어 스레드 하나를 점유하는 현상

무조건적인 Virtual Thread 도입이 아님, MVP 구축 후 병목 구간을 식별하여 도입하기 위해 필요

• 예상되는 사용 가능 구간 : 좌표를 kakao api로 행정구역으로 변환하는 과정
• official docs에 따르면, 10,000개 이상의 Virtual Thread를 만들 상황이 아니라면 Virtual Thread의 이점을 가질 수 없다고 함

SNS 특성 상 조회가 빈번할 것으로 예상됨, 이에 따른 대응책 구비 필요

JAVA 17과 비교

유저 한명이 최대 100장의 사진을 올릴 수 있고 AI서버 모델은 임베딩 2초, 후속작업(태깅, 중복사진 여부, 흔들린 사진 여부, 품질점수 측정) 1~2초 정도 소요

유저가 많아질 수록 처리해야하는 사진 수가 많아짐. ⇒ 대용량 처리 기술 도입 필요

AI서버는 비즈니스 로직에서 가장 긴 시간을 소모하여 DB접근과 동시에 병목이 예상되는 부분이므로 향후 AI서버 확장 시 Kafka로 병렬적이 확장 가능

• 컨트롤러에 어노테이션 기반 설명으로 주석으로 설명하는 것보다 가독성 향상

  @Operation(summary = "유저 프로필 조회", description = "AccessToken을 기반으로 유저 정보를 조회합니다.")
  @ApiResponses({
      @ApiResponse(responseCode = "200", description = "성공"),
      @ApiResponse(responseCode = "401", description = "Access Token이 유효하지 않음")
  })
  @GetMapping("/api/user/{userId}")
  public ResponseEntity<UserResponse> getUserInfo() {
      ...
  }
  

Record 패턴 지원으로 간편한 DTO 설정 가능

• Record 패턴이란? 데이터만을 포함하는 불변한 객체로 선언할 수 있게 해주는 패턴
• Record 클래스는 14부터 사용 가능하나 패턴으로 사용 가능한건 21부터

LTS 중 최신으로 2031년까지 지원 예정

Virtual Thread 지원

[JDK 21의 신기능 Virtual Thread 알아보기 (안정수 James)](https://www.youtube.com/watch?v=vQP6Rs-ywlQ)

[Core Libraries](https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html)

[[Project Loom] Virtual Thread에 봄(Spring)은 왔는가 | 카카오페이 기술 블로그](https://tech.kakaopay.com/post/ro-spring-virtual-thread/)

Virtual Thread(가상 스레드, 경량 스레드)란?

• (JAVA21 official docs) 특정 OS 스레드에 종속되지 않는 인스턴스, OS 스레드와 다수의 Virtual Thread가 매핑됨
• 기존 스레드는 실제 OS 스레드와 1:1 매핑되어 컨텍스트 스위칭 시 OS가 개입하는 등 비용이 높았음
• JVM 자체적인 스케쥴링으로 컨텍스트 스위칭 비용이 줄어 효율적으로 운영할 수 있음
• 블로킹 I/O 작업에 적합함

Virtual Thread 사용 시 유의사항(JAVA21 official docs)

• 가상 스레드 풀링 금지
  • 가상 스레드는 자원의 개념보다는 작업의 개념으로 봐야 함. 플랫폼 스레드를 사용할 때는 자원을 미리 확보한다는 개념으로 풀링했지만, 가상 스레드는 풀링하면 비효율적임. 한 작업에 한 가상스레드!
• 제한적인 리소스 접근 및 사용 시 Semaphore를 사용한다.
  • 세마포어 : 한 리소스에 최대 n개의 접근만 허용하는 기법
  • DB의 경우 커넥션 풀이 세마포어의 역할을 함
• 재사용 가능 객체 유지하지 말 것
  • 가상 스레드는 한 작업에 하나 할당됨. 캐싱하는 것은 해당 패턴에 위배
• 길고 빈번한 pinning 지양
  • pinning : 가상 스레드가 특정 플랫퐄 스레드에 고정되어 스레드 하나를 점유하는 현상

무조건적인 Virtual Thread 도입이 아님, MVP 구축 후 병목 구간을 식별하여 도입하기 위해 필요

• 예상되는 사용 가능 구간 : 좌표를 kakao api로 행정구역으로 변환하는 과정
• official docs에 따르면, 10,000개 이상의 Virtual Thread를 만들 상황이 아니라면 Virtual Thread의 이점을 가질 수 없다고 함

SNS 특성 상 조회가 빈번할 것으로 예상됨, 이에 따른 대응책 구비 필요

JAVA 17과 비교

• 3.2와 비교 시 Virtual Thread 지원 개선(Micrometer Metric 시스템, Undertow 서버같은 구성요소가 Virtual Thread에서 제대로 동작하도록 개선) ⇒ Virtual Thread에 대한 호환성 강화

• 자동 HTTP 클라이언트 팩토리 선택 로직이 개선됨(Apache, Jetty, Netty 설정방식 통합)
• 별도 의존성을 추가하지 않으면 JDK 기존 HttpClient를 사용하도록 Default Inversion

• Test Container로 DB를 띄울 때 @AutoConfigureTestDatabase 를 통해 유연한 테스트db 사용 가능

• 앨범 조회, 앨범 피드 조회 등등..
• 무한스크롤을 통해 반복적인 읽기 api 호출 → 잦은 SELECT 쿼리 발행

• 향후 여러 인스턴스가 리프레시 토큰을 공유해야할 때 중앙 집중형 캐시 서버로 Redis 사용 가능

• 팔로우/언팔로우

  • 내가 팔로우한 유저 ID, 나를 팔로우한 유저 ID를 SET으로 Redis 저장

    Key: follow:following:<내_유저ID>
    Type: Set
    Value: [내가 팔로우한 유저 ID들]
    예: follow:following:1001 → {2002, 2003, 2004}
    
    Key: follow:follower:<내_유저ID>
    Type: Set
    Value: [나를 팔로우한 유저 ID들]
    예: follow:follower:2002 → {1001, 1010}

  • 팔로우/팔로우 취소 시 DB에 반영 후 Redis에 캐싱

  • 팔로우/팔로워 리스트 조회 시 Redis에서 먼저 조회 → 없으면 DB에서 조회

• 유저별 월별 방문 장소, 등록 사진 수

  • 유저 월별 일간 사진 수와 전체 사진 수 Hash, String으로 저장

    Key: stat:picture:daily:<userId>:2025-04
    Type: Hash
    Value: {
      "2025-04-01": 3,
      "2025-04-02": 7,
      ...
    }
    
    Key: stat:picture:total:<userId>
    Type: String
    Value: "153"

  • 유저 월별 장소 및 전체 방문 장소 수 Hash, String 저장

    Key: stat:place:monthly:<userId>:2025-04
    Type: Hash
    Value: {
      "강원도/횡성군/횡성읍": 10,
      "서울특별시/마포구/서교동": 5,
      ...
    }
    
    Key: stat:place:total:<userId>
    Type: String
    Value: "27"
    

• 피드 좋아요 표시

  • 피드 좋아요 수와 좋아요 누른 유저 캐싱(INT, SET)

    Key: like:feed:<feedId>
    Type: Set
    Value: [userId, userId, ...]
    
    Key: like:feed:count:<feedId>
    Type: String or Integer
    Value: 좋아요 수 (INT)

서비스 도입 시 Redis Stream과 Redis pub/sub 비교

• 추가로, 이미 캐싱 목적으로 Redis를 도입했기 때문에 Redis Stream으로 기능확장을 하는 것이 올바른 선택

Kafka는 도입 고려안한 이유?

[Redis Stream 적용기](https://dev.gmarket.com/113)

• Redis Stream 적용기를 찾다가 발견한 지마켓 테크블로그에서 kafka를 고려한 내용이 나온다.
• 지마켓도 kafka나 MQ를 고려했으나 개발 공수와 리소스가 많이 소모될 것이라고 판단하여 선택지에서 제외한다.

Kafka vs Redis Stream 비교

유저 한명이 최대 100장의 사진을 올릴 수 있고 AI서버 모델은 임베딩 2초, 후속작업(태깅, 중복사진 여부, 흔들린 사진 여부, 품질점수 측정) 1~2초 정도 소요

유저가 많아질 수록 처리해야하는 사진 수가 많아짐. ⇒ 대용량 처리 기술 도입 필요

AI서버는 비즈니스 로직에서 가장 긴 시간을 소모하여 DB접근과 동시에 병목이 예상되는 부분이므로 향후 AI서버 확장 시 Kafka로 병렬적이 확장 가능

• 컨트롤러에 어노테이션 기반 설명으로 주석으로 설명하는 것보다 가독성 향상

  @Operation(summary = "유저 프로필 조회", description = "AccessToken을 기반으로 유저 정보를 조회합니다.")
  @ApiResponses({
      @ApiResponse(responseCode = "200", description = "성공"),
      @ApiResponse(responseCode = "401", description = "Access Token이 유효하지 않음")
  })
  @GetMapping("/api/user/{userId}")
  public ResponseEntity<UserResponse> getUserInfo() {
      ...
  }