연향동큰손

대용량 데이터 수집을 병렬 처리로 최적화하기

연향동큰손 — Mon, 15 Sep 2025 16:23:21 +0900

프로젝트를 진행하면서 고용24에서 제공하는 "내일배움카드 교육" 정보를 OPEN API로 호출하는 방법 대신 DB에 저장하여 조회하는 방식으로 변경하기 위해 모든 데이터를 저장을 해봤다.

국민내일배움카드 훈련과정 API는 총 3가지로 분류된다.

훈련과정 목록
훈련과정,기관 정보
훈련일정

훈련과정의 총 개수는 88366개이다.

모든 훈련과정을 저장하기 위해 훈련과정 목록을 저장했고 모든 지역의 훈련과정을 순차적으로 검색했을때 총 1시간 37분이 걸렸다.

이렇게 저장된 훈련과정 ID를 사용하여 훈련과정,기관정보, 훈련일정을 검색하기 위해서는 하나의 훈련 ID당 두번의 API호출이 필요했다.

즉, 상세정보를 저장하기 위한 총 조회 횟수는 16만번 이상이 된다.

88366개의 데이터를 순차적으로 돌면서 상세정보를 수집하니 총 5시간 45분이 걸렸다.

데이터 수집 과정에서 너무 많은 시간이 소요되는 문제점을 확인하게 되었고, 최적화 필요성을 느끼게 되었다.

스레드 풀 기반 병렬 처리

기존에는 한 작업이 완료되어야만 다음 작업이 시작되는 순차적 방식을 사용했기 때문에 전체 요청 시간이 길어졌다.

그러나 스레드 풀 기반의 병렬 처리를 도입하면서 여러 작업을 동시에 실행할 수 있었고, 그 결과 데이터 수집에 소요되는 시간을 크게 단축할 수 있었다.

Thread Pool(스레드 풀)

스레드 풀이란 스레드를 미리 생성하고, 작업 요청이 발생할 때 마다 미리 생성된 스레드로 해당 작업을 처리하는 방식을 의미한다.

요청이 들어오게 되면 작업큐에 넣고 스레드풀은 작업큐에 들어온 Task일감을 미리 생성해놓은 Tread들에게 일감을 할당하게 된다.

이러한 방식을 사용하게 되면 OPEN API호출과 저장 과정을 병렬처리 하기 때문에 총 소요 시간을 크게 줄일 수 있다.

구현방식

우선 병렬처리용 스레드 풀 설정을 위해 ThreadPoolTaskExecutor를 빈으로 등록해준다.

ThreadPoolTaskExecutor은 스프링에서 제공하는 스레드 풀 구현체이다.

여기서 스레드 풀의 기본 동작 방식을 정의할 수 있다.

@Configuration
public class HrdExecutorConfig {

    @Bean(name = "hrdExecutor")
    public ThreadPoolTaskExecutor hrdExecutor() {
        var ex = new ThreadPoolTaskExecutor();
        ex.setCorePoolSize(8); //스레드 8개 상시 대기      
        ex.setMaxPoolSize(16); //최대 16개까지 확장 가능
        ex.setQueueCapacity(2000); //작업 대기열 크기(TaskQueue에 최대 2000개의 작업 대기)
        ex.setThreadNamePrefix("hrd-"); //스레드 이름
        ex.initialize(); //스레드 풀 초기화
        return ex;
    }
}

setCorePoolSize : 풀에서 항상 유지되는 최소 스레드 수(0으로 설정하면 작업이 없을 때는 스레드 유지 X)
setMaxPoolSize : 작업이 몰려서 큐가 꽉차게 되면 최대 스레드 개수로 늘림
setQueueCapacity : 작업 대기열 크기
setThreadNamePrefix : 풀에서 생성된 스레드 이름
initialize : 스레드 풀 초기화

이제 이 스레드 풀을 저장로직이 있는 Service 클래스에서 사용하여 병렬처리를 적용시키면 된다.

 futures.add(CompletableFuture.runAsync(() -> {
                    try {
                        hrdSearchService.getCourseFull(c.getTrprId(), c.getTrprDegr(), torgId); //두개의 OPEN API를 호출하는 메서드
                    } catch (Exception ex) {
                        log.warn("harvest-full fail trprId={}, degr={}, torgId={}, msg={}",
                                c.getTrprId(), c.getTrprDegr(), torgId, ex.getMessage());
                    }
                }, hrdExecutor));

CompletableFuture.runAsync는 비동기 작업 실행을 지원하는 유틸리티 메서드인데, 여기서는 미리 설정해둔 전용 스레드 풀(hrdExecutor)을 함께 사용하여 내일배움카드 훈련과정 데이터 저장 로직을 여러 스레드에서 동시에 실행하도록 구성하였다.

처리시간 비교

순차적 처리 : 5시간 45분 49초

병렬처리 적용 : 1시간 5분 27초

비교 결과 병렬처리를 적용했을때 순차 처리 대비 5.28배 정도 수집 속도가 향상된 것을 수치상으로 확인 가능했다.

Dockerfile이란?

연향동큰손 — Thu, 28 Aug 2025 14:28:39 +0900

Dockerfile

Dockerfile은 Docker 이미지를 만들때 사용된다.

DockerHub에는 mysql, nginx, node, openjdk등 다양한 사람들이 만들어 놓은 Docker 이미지가 존재한다.

하지만 내가 만든 프로젝트를 Docker를 이용해서 배포해야하는 경우 내 프로젝트를 Docker 이미지로 만들어야 한다.

이럴때 Dockerfile을 사용하면 나만의 Docker이미지를 만들 수 있게 된다.

Dockerfile의 구성

FROM

만약 Spring Boot 애플리케이션을 Docker image로 생성할때를 예로 들어보자.

이 애플리케이션을 실행시키기 위해서는 다음과 같은 것들이 기본적으로 세팅되어 있어야 한다.

운영체제
JDK
빌드툴(Gradle,Maven..)

이러한 환경을 매번 직접 세팅하는 것은 번거롭기 때문에, Docker에서는 베이스 이미지(Base Image)라는 개념을 제공한다.

예를 들어 openjdk:17-jdk-slim을 베이스 이미지로 사용하면 운영체제와 JDK가 이미 포함되어 있어, 추가적인 설치 과정 없이도 애플리케이션 실행 환경을 손쉽게 구성할 수 있다.

즉, FROM 지시어에 애플리케이션 실행에 필요한 베이스 이미지를 지정하기만 하면,최소한의 설정으로도 손쉽게 Docker 이미지를 생성할 수 있게 된다.

COPY

COPY는 로컬환경에서 만든 파일이나 디렉터리를 Docker 이미지 안으로 복사하는 지시어다.

FROM에서 실행환경(운영체제 + JDK 등)을 마련했다면

COPY에서 실행환경 위에 내 애플리케이션 소스나 빌드 결과물(JAR파일 등)을 올려놓는 과정을 실행한다.

ENTRYPOINT

ENTRYPOINT는 컨테이너가 생성되고 최초로 실행할 때 수행되는 명령어를 정의하는 지시어다.

컨테이너에서 Spring Boot 빌드 결과물인 JAR 파일을 실행하려면, ENTRYPOINT에 java -jar 명령어를 지정하면 된다.

RUN

ENTRYPOINT는 컨테이너를 생성한 직후에 실행시킬 명령어를 정의 한것이면, RUN은 이미지 생성 과정에서 필요한 명령어를 실행시킬 때 사용된다.

예를 들어 컨테이너 환경이 Ubuntu로 구성되어 있고, git이 설치되어 있기를 바란다면,

Dockerfile에서 RUN 지시어로 git 설치가 가능하다.

FROM ubuntu
RUN apt update && apt install -y git
ENTRYPOINT ["/bin/bash", "-c", "sleep 500"]

WORKDIR

WORKDIR은 작업 디렉터리를 작업 디렉터리를 지정하여 RUN,CMD,ENTRYPOINT,COPY,ADD와 같은 명령어를 해당 디렉터리를 기준으로 실행시키도록 해주는 지시어다.

# 문법
WORKDIR [작업 디렉토리로 사용할 절대 경로]
# 예시
WORKDIR /usr/src/app

EXPOSE

EXPOSE는 컨테이너 내부에서 어떤 포트에 프로그램이 실행되는 지를 문서화 하는 역할을 한다.

단지 문서화의 역할만 하기 때문에 EXPOSE를 쓰나 안 쓰나 작동 방식에는 영향을 미치지 않는다.

Spring Boot 애플리케이션 Docker 컨테이너에서 실행

1. Dockerfile 생성

# 베이스 이미지
FROM openjdk:17-jdk

# JAR 파일 복사
COPY build/libs/Redis_Practice-0.0.1-SNAPSHOT.jar app.jar

# 실행
ENTRYPOINT ["java", "-jar", "/app.jar"]

2. 소스코드 빌드, JAR파일 생성

./gradlew clean build

3. Dockerfile 기반으로 Docker 이미지 생성

docker build -t hello-server .

4. 생성한 이미지를 기반으로 Docker 컨테이너를 생성하고 실행

백그라운드로 실행하고 호스트의 8080 포트를 컨테이너의 8080포트와 연결해서 실행시켰다.

docker run -d -p 8080:8080 hello-server

Cloudflare를 사용하여 EC2 웹서버에 HTTPS 적용하기(2)

연향동큰손 — Wed, 27 Aug 2025 16:53:47 +0900

1. 도메인 구매

가비아에서 테스트용으로 'woohyeon.store'를 구입했다.

2. Cloudflare에 도메인 등록

도메인을 등록하고, 도메인에 대한 DNS관리에서 DNS 레코드를 수정해줘야 한다.

도메인과 EC2 서버를 연결하기 위해서 A레코드에 EC2의 Public IP 주소를 등록해준다.

또한 'www.woohyeon.store'로 접속해도 'woohyeon.store'로 맵핑되도록 해주기 위해 CNAME 레코드에 이름을 www로 등록해준다.

형식 : A, 이름 : 도메인, IPv4 주소 : EC2 인스턴스의 public IP주소
형식 : CNAME 이름 : www 대상 : 도메인

3. SSL/TLS 등록

SSL/TLS란 브라우저와 서버 간 통신을 암호화해주는 프로토콜이고, HTTPS로 접속할때 SSL/TLS가 사용된다.

이를 통해 클라이언트와 서버간의 데이터를 암호화 하여 중간에서 데이터를 가로채도 해독 불가능하게 만든다.

브라우저에서 나의 도메인으로 접속을 하면 그 요청은 Cloudflare를 거쳐 나의 서버로 이동하게 되는데,

나는 SSL모드를 '가변'으로 설정하여 브라우저와 Cloudflare 사이의 데이터를 암호화 하도록 하였다.

4. Cloudflare 네임서버를 가비아에 등록

가비아는 도메인을 내 소유로 등록해주는 곳이고, 실제 트래픽을 처리해주지 않기 때문에 이 도메인의 IP나 서브 도메인 정보를 어디서 찾아라고 알려주는 네임서버(NS)를 가비아에 등록해줘야 한다.

5. Nginx 설정

Cloudflare에서 웹서버로 요청이 올때는 80포트로 들어오고 이 요청을 스프링서버(8080포트)로 포워딩 해주기 위해 Nginx를 사용했다.

server {
    listen 80 default_server;
    server_name woohyeon.store www.woohyeon.store;

    # API 요청은 스프링으로 프록시
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;

        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;
    }

    # 파비콘 요청 무시
    location = /favicon.ico { return 204; }
}

<테스트 결과>

[Redis] 캐싱을 이용한 간단한 성능 개선 테스트(Apache JMeter)

연향동큰손 — Mon, 25 Aug 2025 17:00:31 +0900

Redis 캐싱을 이용해 조회성능 테스트를 진행했다.

캐싱이란?

캐싱은 자주 사용하는 데이터를 임시 저장소(캐시)에 보관하여, 데이터 조회 속도를 높이고 시스템 부하를 줄이는 기술이다.

캐싱을 사용하게 되면 메모리에 저장된 데이터를 반환 함으로써 디스크 기반의 데이터베이스보다 빠르게 데이터를 불러올 수 있다는 장점이 있다.

이러한 캐싱 기술은 웹 서비스의 성능을 높일 수 있다는 장점이 있지만 무작정 사용한다면 오히려 성능 저하나 오류가 발생할 수 있다.

캐싱 전략 선택시 고려사항

데이터의 변경 빈도 : 캐싱에 대상이 되는 데이터가 가변성이 높다면 캐시 데이터가 최신 데이터를 반영하고 있지 않을 수 있다. 또한 잦은 캐시 무효화와 재생성으로 인해 부하가 증가할 수 있다.
데이터를 한번 쓰고 여러번 읽는 경우 : 사용자 프로필과 같이 데이터를 한번 쓰고 여러번 읽는 경우 캐싱 효과가 좋다.
캐시 데이터의 수명 : 캐시 데이터가 지워지지 않고 계속 캐시 저장소에 저장되어 있는것은 바람직하지 않다. 따라서 캐시 만료 정책을 적절히 설정하여 캐시 데이터의 신선도를 유지할 필요가 있다.

캐싱을 통한 성능비교 테스트

캐싱을 통해 조회 성능을 비교하는 테스트를 진행했다.

테스트 도구로 Apache JMeter를 사용했다.

Apache JMeter란 서버가 제공하는 성능 및 부하를 측정할 수 있는 테스트 도구이다.

이번에 처음 사용 해봤는데 다양한 테스트 시나리오를 쉽게 테스트 가능했고, 앞으로도 자주 사용하며 사용법을 익힐 예정이다.

Spring에서는 여러 캐시 저장소(Redis, Ehcache, Caffeine, ConcurrentMap 등)를 사용할 수 있도록 CacheManager 인터페이스를 제공한다.

나는 Redis로 캐싱을 구현할 예정이므로 RedisConfig 클래스를 생성해 Redis 커넥션 설정 및 스프링 캐시 추상화에서 사용하는 CacheManager 구현체를 Redis로 설정해줬다.

@Configuration
@EnableRedisRepositories
public class RedisConfig {

    @Value("${spring.data.redis.host}")
    private String host;

    @Value("${spring.data.redis.port}")
    private int port;

    @Value("${spring.data.redis.password}")
    private String redisPassword;

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        RedisStandaloneConfiguration config = new RedisStandaloneConfiguration(host, port);
        config.setPassword(redisPassword);
        return new LettuceConnectionFactory(config);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory());

        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.registerModule(new JavaTimeModule());
        objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

        GenericJackson2JsonRedisSerializer serializer =
                new GenericJackson2JsonRedisSerializer(objectMapper);

        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(serializer);

        template.setHashKeySerializer(new StringRedisSerializer());
        template.setHashValueSerializer(serializer);

        return template;
    }


    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {

        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.registerModule(new JavaTimeModule());
        objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

        GenericJackson2JsonRedisSerializer serializer =
                new GenericJackson2JsonRedisSerializer(objectMapper);

        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .serializeKeysWith(
                        RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(
                        RedisSerializationContext.SerializationPair.fromSerializer(serializer)
                );

        return RedisCacheManager.builder(connectionFactory)
                .cacheDefaults(config)
                .build();
    }

}

그리고 게시글 조회 메서드에 대해서 @Cacheable를 추가해 해당 키를 가진 데이터가 캐시에 존재하지 않으면 DB에 조회하고 캐시에 저장하도록 하고,

만약 캐시 메모리에 해당 키를 가진 데이터가 캐시에 존재하면 DB조회를 하지않고 캐시에 저장된 데이터를 반환 하도록 했다.

@Cacheable(value = "postsCache", key = "'allPosts'")
public List<PostTotalListResponseDto> getTotalPostList() {

    List<Post> posts = postRepository.findAll();

    List<Post> sortedPosts = posts.stream()
            .sorted((p1, p2) -> p2.getCreatedAt().compareTo(p1.getCreatedAt()))
            .toList();

    return sortedPosts.stream()
            .map(PostTotalListResponseDto::toDto)
            .toList();
}

테스트 시나리오

가상 사용자수 50 -> 100 -> 500 순으로 증가
한명의 가상 사용자가 10초에 걸쳐 10번씩 조회 요청

테스트 결과

요청 수 5000의 경우 성능차이

평균 응답속도 : 약 209배 빨라짐
처리량(TPS) : 약 3.9배 증가

테스트 결과 요청수가 늘어날수록 캐시를 적용 했을때와 안했을때의 성능차이가 명확하게 나타났다.

요청수가 5000회인 경우 캐시 없이 DB에서 데이터를 조회할때는 평균응답이 2720ms까지 나타났지만 Redis를 적용한 경우 5000번의 요청에서도 13ms의 평균 응답을 유지했다.

TPS또한 Redis를 사용한 경우 5000번의 요청에서는 4배 가까이 증가하는 것을 확인할 수 있었다.

이 테스트를 통해 Redis 캐시를 사용할 경우 낮은 부하보다 높은 부하 환경에서 성능을 극대화 시킬 수 있다는 것을 알게되었다.

Spring Boot + Redis를 활용한 Refresh Token 기능 구현

연향동큰손 — Sun, 24 Aug 2025 15:23:17 +0900

Access Token만 사용할때의 문제점

Access Token은 사용자 인증과 인가에 직접 사용되므로 상대적으로 짧은 만료 기간(30분 ~ 1시간)을 갖는다.

이렇게 짧은 유효기간을 유지하는 이유는 토큰을 탈취당했을 경우 피해를 최소화 할 수 있기 때문이다.

만약 Access Token의 유효 기간을 길게 설정하게 되면 탈취된 토큰을 활용할 수 있는 시간도 늘어나게 된다.

이렇게 Access Token의 짧은 유효기간은 보안상 좋은점도 있지만, 사용자가 자주 로그인을 해야 하는 불편이 있다.

만약 짧은 유효기간의 Access Token만을 사용하게 되면 사용자가 서비스를 사용중에 갑자기 로그아웃 되거나 오류 메시지를 보게 되어 곤란한 상황이 생길 수 있다.

Refresh Token의 활용

이러한 문제를 Refresh Token을 함께 발급하여 해결할 수 있다.

Refresh Token은 보통 7일 이상의 긴 유효기간을 가지며, Access Token이 만료되면 클라이언트에서 Refresh Token을 사용하여 새로운 Access Token을 발급 받을 수 있다.

이렇게 되면 사용자는 반복 로그인 없이 일정 기간 서비스를 지속적으로 이용할 수 있게된다.

Refresh Token 구현

구현 내용

사용자 로그인
회원정보 DB에서 조회
Refresh Token(TTL 7일) Redis에 저장
Access Token과 Refresh Token을 클라이언트에게 반환

Refresh Token을 Redis에 저장하는 이유

Redis는 키 단위로 TTL을 설정할 수 있어, 만료된 토큰이 자동으로 삭제 되지만 RDB에 저장할 경우 만료된 토큰을 찾아 삭제하는 추가 작업이 필요함.
인메모리 방식의 빠른 조회 성능
휘발성 메모리에 리프레시 토큰을 저장하다가 데이터가 전부 지워져도 모든 유저가 재로그인을 하면 되고, 그렇게 크리티컬한 오류가 아니기 때문

<RefreshToken>

@RedisHash(value = "token")
@AllArgsConstructor
@Getter
@ToString
public class RefreshToken {

    @Id
    private Long id;

    private String refreshToken;

    @TimeToLive
    private Long expiration;
}

<TokenRepository>

Redis 저장소에 RefreshToken 객체를 쉽게 저장하고 조회할 수 있도록 지원하는 Spring Data Repository

@Repository
public interface TokenRepository extends CrudRepository<RefreshToken, Long> {
}

<JwtTokenProvider>

Access Token, Refresh Token 발급 및 Redis에 Refresh Token 저장

@Component
@RequiredArgsConstructor
public class JwtTokenProvider {

        private final TokenRepository tokenRepository;

        @Value("${jwt.secret}")
        private String secretKeyString;

        @Value("${jwt.expiration}")
        private long expiration;

        private Key getSigningKey() {
            return Keys.hmacShaKeyFor(secretKeyString.getBytes(StandardCharsets.UTF_8));
        }

        public String generateToken(String email, Role role) { //사용자 이메일과 Role정보를 포함한 JWT 토큰 생성

            Date now = new Date();
            Date expiry = new Date(now.getTime() + expiration);

            return Jwts.builder()
                    .setSubject(email) // sub
                    .setIssuedAt(now)
                    .setExpiration(expiry)
                    .signWith(getSigningKey(), SignatureAlgorithm.HS256)
                    .compact();
        }



        public String getEmail(String token) { //JWT 토큰에서 이메일 정보 추출
            return Jwts.parser()
                    .setSigningKey(getSigningKey())
                    .parseClaimsJws(token)
                    .getBody()
                    .getSubject();
        }

        public String getRole(String token) { //JWT 토큰에서 Role 정보 추출
            return Jwts.parser()
                    .setSigningKey(getSigningKey())
                    .parseClaimsJws(token)
                    .getBody()
                    .get("role", String.class);
        }

        public boolean validateToken(String token) { //토큰 유효성 검사
            try {
                Jwts.parser()
                        .setSigningKey(getSigningKey())
                        .parseClaimsJws(token);
                return true;
            } catch (ExpiredJwtException e) {
                System.out.println("Expired JWT token: " + e.getMessage());
                throw new UnauthorizedException(ErrorStatus.UNAUTHORIZED_TOKEN_EXPIRED.getMessage());
            } catch (MalformedJwtException e) {
                System.out.println("Malformed JWT token: " + e.getMessage());
                throw new UnauthorizedException(ErrorStatus.UNAUTHORIZED_INVALID_TOKEN.getMessage());
            } catch (UnsupportedJwtException e) {
                System.out.println("Unsupported JWT token: " + e.getMessage());
                throw new UnauthorizedException(ErrorStatus.UNAUTHORIZED_UNSUPPORTED_TOKEN.getMessage());
            } catch (IllegalArgumentException e) {
                System.out.println("Empty JWT token: " + e.getMessage());
                throw new UnauthorizedException(ErrorStatus.UNAUTHORIZED_EMPTY_TOKEN.getMessage());
            }
        }


    public String generateRefreshToken(String email) {
        Date now = new Date();

        long refreshExpiration = 7 * 24 * 60 * 60 * 1000L; // 7일 밀리초 단위
        Date expiry = new Date(now.getTime() + refreshExpiration);

        return Jwts.builder()
                .setSubject(email) // 토큰 대상자 이메일 정보
                .setIssuedAt(now)
                .setExpiration(expiry)
                // 서명 키는 기존 액세스 토큰 서명키와 동일하게 사용
                .signWith(getSigningKey(), SignatureAlgorithm.HS256)
                .compact();
    }


    /**
     * 리프레시 토큰 저장
     * @param id 토큰의 고유 식별자 (예: 사용자 ID)
     * @param refreshToken 실제 리프레시 토큰 문자열
     * @param expirationSeconds 만료 시간(초)
     */
    public void saveRefreshToken(Long id, String refreshToken, Long expirationSeconds) {
        RefreshToken token = new RefreshToken(id, refreshToken, expirationSeconds);
        tokenRepository.save(token);
    }

    /**
     * 리프레시 토큰 조회
     * @param id 토큰 고유 식별자
     * @return RefreshToken 엔티티, 없으면 null 반환
     */
    public RefreshToken getRefreshToken(Long id) {
        Optional<RefreshToken> tokenOptional = tokenRepository.findById(id);
        return tokenOptional.orElse(null);
    }

    /**
     * 리프레시 토큰 삭제
     * @param id 토큰 고유 식별자
     */
    public void deleteRefreshToken(Long id) {
        tokenRepository.deleteById(id);
    }

}

<MemberService>

로그인 시 Refresh Token, Access Token 생성, 반환
Refresh Token은 Redis에 저장
Access Token 만료 시, Refresh Token 유효성 검사를 통해 새로운 Access Token 발급

@Service
@RequiredArgsConstructor
public class MemberService {


    private final MemberRepository memberRepository;
    private final JwtTokenProvider jwtTokenProvider;
    private final TokenRepository tokenRepository;
    private final PasswordEncoder passwordEncoder;

    @Transactional
    public void signUpMember(SignupRequestDto signupRequestDto){
        if(memberRepository.findByEmail(signupRequestDto.getEmail()).isPresent()){
            throw new BaseException(ErrorStatus.BAD_REQUEST_DUPLICATE_EMAIL.getHttpStatus(),ErrorStatus.BAD_REQUEST_DUPLICATE_EMAIL.getMessage());
        }
        if(memberRepository.findByNickname(signupRequestDto.getNickname()).isPresent()){
            throw new BaseException(ErrorStatus.BAD_REQUEST_DUPLICATE_NICKNAME.getHttpStatus(),ErrorStatus.BAD_REQUEST_DUPLICATE_NICKNAME.getMessage());
        }

        String encodedPassword = passwordEncoder.encode(signupRequestDto.getPassword());

        Member member = signupRequestDto.toEntity(encodedPassword);
        member.setRole(ROLE_MEMBER);
        memberRepository.save(member);
    }

    @Transactional
    public Map<String, Object> loginMember(LoginRequestDto loginRequestDto){

        Member member = memberRepository.findByEmail(loginRequestDto.getEmail())
                .orElseThrow(()->new UnauthorizedException(ErrorStatus.UNAUTHORIZED_EMAIL_OR_PASSWORD.getMessage()));

        if(!passwordEncoder.matches(loginRequestDto.getPw(),member.getPassword())){
            throw new UnauthorizedException(ErrorStatus.UNAUTHORIZED_EMAIL_OR_PASSWORD.getMessage());
        }

        String token = jwtTokenProvider.generateToken(member.getEmail(),member.getRole());
        String refreshToken = jwtTokenProvider.generateRefreshToken(member.getEmail());

        // 리프레시 토큰 저장
        jwtTokenProvider.saveRefreshToken(member.getId(), refreshToken, 7 * 24 * 60 * 60L); // 7일 만료

        Map<String, Object> response = new HashMap<>();
        response.put("token",token);
        response.put("refreshToken", refreshToken);
        response.put("role",member.getRole());

        return response;
    }

    public String reissueAccessToken(String refreshToken){
        if(!jwtTokenProvider.validateToken(refreshToken)){
            throw new BaseException(ErrorStatus.UNAUTHORIZED_REFRESH_TOKEN_EXPIRED.getHttpStatus(),ErrorStatus.UNAUTHORIZED_EMPTY_TOKEN.getMessage());
        }

        String email = jwtTokenProvider.getEmail(refreshToken);

        Member member = memberRepository.findByEmail(email)
                .orElseThrow(()->new UnauthorizedException("회원 정보를 찾을 수 없습니다."));

        //Redis에서 회원 ID로 저장된 리프레시 토큰 조회
        RefreshToken storedRefreshToken = tokenRepository.findById(member.getId())
                .orElseThrow(()-> new UnauthorizedException("리프레시 토큰을 찾을 수 없습니다."));

        // 전달받은 리프레시 토큰과 Redis에서 조회한 토큰 일치 여부 확인
        if(!storedRefreshToken.getRefreshToken().equals(refreshToken)){
            throw new UnauthorizedException("유효하지 않은 리프레시 토큰입니다.");
        }

        // 새로운 액세스 토큰 생성하여 반환
        return jwtTokenProvider.generateToken(email,member.getRole());

    }

}

로그인 후 Redis CLI를 통해 확인해보면 TTL이 약 7일로 잘 설정 되어있고

토큰 값도 잘 저장되어 있는것도 확인 가능하다.

Access Token 재발급 API에 Refresh Token을 넣어서 테스트하면 새로운 Access Token이 발급되는 것도 확인 가능하다.

EC2에 배포해서 테스트

Redis가 실행될 EC2 서버 한대, Spring Application이 실행될 EC2서버 한대로 테스트를 진행했다.

웹 서버에서 Redis서버로 접근이 가능하게 하기 위해서는 Redis 서버의 보안그룹에서 웹서버 IP에서 Redis 서버의 6379포트로 접근가능하도록 인바운드 규칙을 편집해줘야 한다.

로그인을 실행하면 hash 형식으로 Redis에 키값이 저장된다.

CORS란? Spring Boot에서 CORS 정책 설정

연향동큰손 — Fri, 22 Aug 2025 23:49:42 +0900

Origin이란?

Origin은 출처를 의미한다. URL에서 Protocol, Host, Port가 같으면 동일한 Origin임을 의미한다.

SOP(Same Origin Policy)

만약 Origin이 다른 두 애플리케이션이 자유롭게 소통할 수 있게되면 보안상 치명적인 문제가 생길 수 있다.

XSS(크로스 사이트 스크립팅), CSRF(사이트 요청 위조) 공격에 취약해질 수 있다.

따라서 같은 Origin만 끼리만 리소스를 공유할 수 있는 정책이 필요하다. 이 정책을 SOP(Same Origin Policy)라고 부른다.

하지만 다른 Origin에서의 요청을 허용해줘야 하는 경우도 존재한다.

예를 들면 프론트엔드 서버에서 백엔드 서버로 요청을 보낼 경우 이 요청을 막아버린다면, 프론트엔드와 백엔드간 통신이 불가능하게 된다.

이러한 경우 Origin이 다르더라도 특정 Origin과 리소스를 공유할 수 있도록 허용해줘야한다.

CORS(Cross-Origin Resource Sharing)

CORS는 웹 브라우저에서 다른 출처(Origin)의 리소스에 접근할 수 있도록 하는 보안 메커니즘이다.

브라우저는 본 요청을 보내기 전 예비 요청(Preflight Request)을 보내서 서버와 잘 통신할 수 있는지 확인하는 요청을 보낸다.

서버는 어떤 출처, 어떤 HTTP 메서드, 어떤 헤더를 허용할지 응답헤더로 알려준다.

Preflight 요청이 성공하면 Client에서 Main Request(본 요청)을 보내게 된다.

Spring Boot에서 CORS 정책 설정

프론트엔드와 백엔드가 다른 Origin에 있을 때 백엔드에서 CORS 허용 설정이 필요하다.

CorsConfig 클래스에서 Origin, Methods 등의 설정을 해주면 CORS 에러를 해결할 수 있다.

package com.example.RedisPractice.common.config;


import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.CorsConfigurationSource;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;

import java.util.List;

@Configuration
public class CorsConfig {
    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration config = new CorsConfiguration();

        config.setAllowedOrigins(List.of(
                "http://localhost:3000"           // 프론트엔드 개발 환경
                // 운영 환경 추가
        ));
        config.setAllowedMethods(List.of(           // 허용 메서드
                "GET",
                "POST",
                "PUT",
                "DELETE",
                "OPTIONS"
        ));
        config.setAllowedHeaders(List.of("*")); // 모든 요청 헤더 허용
        config.setAllowCredentials(true);           // 쿠키, 인증정보 포함 여부 허용

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);

        return source;
    }
}

SecurityConfig에서 빈으로 등록한 CORS 정책을 적용하면 된다.

.cors(Customizer.withDefaults())

Redis DB서버 구성

연향동큰손 — Fri, 22 Aug 2025 15:57:39 +0900

Replication(복제)

Master 노드는 쓰기(Write)작업을 처리하고, 여러 Slave노드가 Master 노드의 데이터를 복제하여 읽기 작업을 처리한다.

읽기 요청을 여러 Slave 노드에 분산하여 트래픽 분산을 통해 처리 성능 향상
Master 노드에 장애가 발생해도 Slave 노드들이 데이터를 가지고 있으므로 장애 복구에 좋다.
Master는 쓰기, Slave는 읽기 작업을 담당하여 Master 노드의 부하 감소
수평적 확장 가능

Redis 클러스터 구성

최소 3개의 노드를 가지고 각 노드는 Master와 Slave 로 구성되어있다.
데이터를 여러 노드에 분산하여 저장함으로써 고가용성과 확장성을 제공

여러 노드에 데이터를 무작위로 분산 저장하면, 클라이언트가 어떤 노드에 특정 키가 저장되어 있는지 알기 어려워 데이터 조회나 관리에 문제가 발생할 수 있다.

하지만 Redis 클러스터는 샤딩을 통해 모든 키를 16,384개의 해시 슬롯 중 하나에 명확히 매핑한다.

슬롯들이 클러스터의 Master 노드들에 구간별로 할당되어 있어, 클라이언트는 키 이름으로부터 슬롯을 계산하고 그 슬롯을 담당하는 노드를 자동으로 인식할 수 있습니다.

Redis(Remote Dictionary Server)란?

연향동큰손 — Thu, 21 Aug 2025 17:20:48 +0900

Redis란?

Redis는 고성능의 키-값(key-value) 저장소로, 거대한 맵(Map) 데이터 저장소형태를 가지고 데이터를 메모리에 저장하여 빠른 읽기와 쓰기를 지원하는 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템이다.

Redis의 특징

1. 고성능

RDBS(Relational Database Management System)는 디스크 기반의 저장 방식을 사용한다.

디스크 기반의 저장 방식은 메모리 저장 방식에 비해 데이터를 오래 보관할 수 있다는 장점이 있지만,

메모리에 있는 데이터를 조회하는 방식에 비해 처리 속도가 느리다는 단점이 있다.

반면 Redis는 데이터를 디스크에 쓰는 구조가 아니라, 메모리에서 데이터를 처리하기 때문에 속도가 매우 빠르다.

또한 Redis도 필요시 디스크에 스냅샷 저장이나 AOF(Append Only File)기록을 통해 영속성을 지원한다.

2. Key- Value 방식의 단순한 데이터 구조

Redis는 Key-Value 구조의 데이터 구조를 사용하기 때문에 SQL처럼 복잡한 쿼리 없이도 데이터 조작이 가능하며, 다양한 자료구조(Hash, List, Set 등도 지원)로 단순하면서도 유연합니다.

3. Single Thread 구조

Redis는 모든 클라이언트 요청 처리를 단일 스레드에서 수행한다.

이 말은 클라이언트의 동시 요청이 들어오더라도 Redis가 이 요청들을 순차적으로 하나씩 처리한다는 의미이다.

이럴경우 트랜잭션의 일관성이 보장되어 동시성 문제가 발생하는 것을 방지할 수 있다.

사용 예시

1. 캐싱 시스템 (Cache)

• 자주 조회되는 데이터를 메모리에 저장해 원본 데이터베이스의 부하를 줄이고 빠른 응답 속도 제공
• 예: 상품 정보, 사용자 프로필, 페이지 콘텐츠 등
• TTL(만료시간) 설정으로 캐시 데이터를 자동 관리

2. 세션 저장소 (Session Store)

• 사용자 로그인 세션 데이터를 Redis에 저장하여 빠른 인증과 세션 관리 가능
• 여러 서버가 같은 Redis에 세션 정보 저장해 로드밸런싱 및 분산 환경에서 효과적

• Refresh Token을 Redis에 저장하여 로그인 상태를 지속적으로 유지하고 인증 관리 가능

3. 리더보드(순위 집계)

• Redis의 Sorted Set 자료구조를 이용해 점수 기반의 순위 계산 및 조회
• 예: 게임 점수 순위, 활동량 랭킹 등
• 자동 정렬과 빠른 조회 지원

4. 실시간 분석 및 통계

• 실시간 트래픽 모니터링, 사용자 활동 집계, 이상 징후 감지 등
• Redis의 다양한 자료구조(Hash, Sorted Set 등)을 활용해 빠른 집계 및 분석 가능

5. 메시지 큐 및 Pub/Sub 시스템

• 실시간 메시지 전송 및 구독 기능 지원
• 채팅 애플리케이션, 푸시 알림, 이벤트 스트리밍 등에 활용 가능

Redis 자료구조

기본적으로 Redis는 0~15까지 16개의 데이터베이스를 제공한다.

최초 접속시 default값인 0번 데이터베이스로 이동하고, select 명령어를 이용해 데이터베이스를 선택 가능하다.

127.0.0.1:6379> select 10
OK
127.0.0.1:6379[10]> select 0
OK

1. String 자료구조

String 자료구조는 Redis에서 가장 기본적이고 단순한 데이터 타입이다.

하나의 Key에 하나의 Value를 저장하는 단일 값 저장 방식이다.

키에 값을 설정할때는 SET 명령어를 사용한다.

127.0.0.1:6379> set user:email:1 yang@naver.com
OK
127.0.0.1:6379> keys *
1) "user:email:1"

그리고 Key의 Value를 가져올때는 GET을 사용할 수 있다.

127.0.0.1:6379> get user:email:1
"yang@naver.com"

만약 Key에 대한 Value가 존재 하는데, 동일한 Key에 대해서 SET을 통해 다른 Value를 설정하면 기존에 설정한 Value를 대신해 새로운 Value가 덮어 씌워지게 된다.

TTL(Time To Live)값 설정

Redis는 Key-Value에 대해서 Key 유지(만료) 시간을 셋팅할 수 있다.

'EX 초단위 시간' 형식으로 지정 가능한다.

127.0.0.1:6379> set user:email:3 yang3@naver.com ex 10
OK
127.0.0.1:6379> keys *
1) "user:email:2"
2) "user:email:1"
3) "user:email:3"
#10초 후
127.0.0.1:6379> keys *
1) "user:email:2"
2) "user:email:1"

캐싱처리

Redis의 String 자료구조는 캐싱 처리에 유용하게 사용될 수 있다.

여기서 캐싱이란 데이터를 한 번 받아오거나 계산한 후, 그 데이터를 더 가까운 곳(예 : 메모리나 임시 저장소)에 임시로 저장해 두었다가, 나중에 다시 필요할 때 빠르게 불러와 사용하는 기술을 의미한다.

게시글 조회를 예시로 들면,

최초에 게시글을 조회하게 되면 DB에 접근하여 게시글을 조회하고 게시글 데이터를 캐싱하기 위해 JSON 문자열로 직렬화 하여 Redis에 저장한다.

이후 같은 요청을 하게되면 Redis에 저장되어있는 데이터를 바로 반환하기 때문에 처리 속도를 높이면서 서버 부하도 줄일 수 있다.

2. List 자료구조

Redis에서 List는 일반적인 프로그래밍 언어에서의 List와 다르게 데크(deque) 자료구조를 사용한다.

데크는 양쪽 끝에서 삽입, 삭제를 수행할 수 있는 자료구조를 의미한다.

(Redis의 List는 데크 구조를 사용하므로 데이터를 중간에 삽입하는 것은 불가능하다.)

List에 데이터를 추가 및 조회하는 방법은 다음과 같다.

1. lpush : 데이터를 왼쪽에 삽입

127.0.0.1:6379> lpush yangwoohyeon yang1
(integer) 1

2. rpush : 데이터를 오른쪽에 삽입

127.0.0.1:6379> rpush yangwoohyeon yang3
(integer) 3

3. lpop : 데이터를 왼쪽에서 꺼내기

4. rpop : 데이터를 오른쪽에서 꺼내기

5. lrange : list 조회 (0은 시작점, -1은 list의 끝자리 의미)

127.0.0.1:6379> lrange yangwoohyeon 0 -1
1) "yang2"
2) "yang1"
3) "yang3"

6. llen : 데이터 개수 조회

127.0.0.1:6379> llen yangwoohyeon
(integer) 1

7. expire : TTL적용

127.0.0.1:6379> expire yangwoohyeon 10
(integer) 1

List 자료구조 활용

사용자의 최근 활동 내역 (예 : 최근 본 상품, 최근 검색어 등등)을 일정 개수만큼 저장하는데 사용할 수 있다.

3. Set 자료구조

Set은 순서가 없고 중복이 없는 자료구조이다.

주요 명령어

1. sadd : 집합에 값 추가

127.0.0.1:6379> sadd memberlist member1
(integer) 1

2. scard : Set맴버 개수 조회

127.0.0.1:6379> scard memberlist 
(integer) 2

3. sismember : 특정 맴버가 Set안에 있는지 존재여부 확인(있으면 1, 없으면 0)

127.0.0.1:6379> sismember memberlist member1
(integer) 1

4. srem : Set에서 맴버 삭제

127.0.0.1:6379> srem memberlist member2
(integer) 1

Set 자료구조 활용

SNS의 게시글에 대한 '좋아요'기능을 살펴보면 한 사용자가 한 게시글에 대해서 한번만 좋아요를 누를 수 있고, 좋아요를 누른지에 대한 여부도 불러올 필요가 있다.

이러한 기능에 Set 자료구조가 특화되어 있다고 볼 수 있다.

좋아요를 누를때 Set에 사용자ID를 함께 추가하고 좋아요 여부를 'sismember'로 체크하여 불러올 수 있다.

그리고 기존에 좋아요를 누른 사용자가 좋아요를 한번 더 누르더라도 Set은 중복을 허용하지 않기 때문에 문제될게 없다.

4. zset 자료구조

ZSET(Sorted Set)은 각 원소에 점수(score)를 부여하여 자동으로 정렬되는, 유니크한 값들의 집합 자료구조이다.

주요 명령어

1. zadd : 맴버-점수 쌍 추가

127.0.0.1:6379> zadd memberlist 3 member1
(integer) 1
127.0.0.1:6379> zadd memberlist 4 member2
(integer) 1
127.0.0.1:6379> zadd memberlist 1 member3
(integer) 1
127.0.0.1:6379> zadd memberlist 2 member4

2. zrange : Score 기준으로 오름차순 정렬

127.0.0.1:6379> zrange memberlist 0 -1
1) "member3"
2) "member4"
3) "member1"
4) "member2"

3. zrevrange : Score 기준으로 내림차순 정렬

127.0.0.1:6379> zrevrange memberlist 0 -1
1) "member2"
2) "member1"
3) "member4"
4) "member3"

4. zrem : zset 맴버 삭제

5. zrank : 특정 맴버가 몇번째(index 기준) 순서인지 출력

127.0.0.1:6379> zrank memberlist member1
(integer) 1

ZSET 자료구조 활용

최근 본 상품 목록을 저장하는 기능을 예시로 들면,

조회한 시간을 기준으로 정렬하여 중복 없는 최근 본 상품 목록 조회에 사용할 수 있다.

최근 본 상품이나, 주식 가격과 같이 변화가 많고 임시적이며 빠른 접근이 필요한 데이터는 Redis에 저장하는 것이 성능과 운영 측면에서 더 효율적이므로 Redis 활용이 권장된다.

5. Hash 자료구조

Hash는 Value값이 map 형태인 자료구조이다.

아래 형식과 같이 필드와 값의 쌍을 저장하며, 이러한 형식은 객체 형식의 데이터를 캐싱할때 효율적이다.

- name: "Laptop"
- brand: "Apple"
- price: "1500"
- stock: "50"

주요 명령어

1. hset : 필드, 값 데이터 저장

127.0.0.1:6379> hset author:info:1 name hong email hong@naver.com age 30
(integer) 3

2. hget : 특정값 조회

127.0.0.1:6379> hget author:info:1 name
"hong"

3. hgetall : 모든 객체값 조회

127.0.0.1:6379> hgetall author:info:1
1) "name"
2) "hong"
3) "email"
4) "hong@naver.com"
5) "age"
6) "30"

4. hincrby : 필드값을 정수만큼 증가

127.0.0.1:6379> hincrby author:info:1 age 3
(integer) 33
127.0.0.1:6379> hgetall author:info:1
1) "name"
2) "kim"
3) "email"
4) "hong@naver.com"
5) "age"
6) "33"

Hash값은 빈번하게 변경될 가능성이 있는 객체 형식의 데이터를 캐싱할때 효율적이다.

만약 JSON 형식의 문자열로 캐싱된 데이터를 수정해야하는 경우, 일일이 파싱 후 모든 값을 다시 셋팅해야하는 비효율이 존재하는데,

Hash는 특정 요소값만을 변경하기에 용이하기 때문에 비교적 효율적이라고 볼 수 있다.

[Kafka] MSA 구조에서의 Kafka 사용

연향동큰손 — Tue, 19 Aug 2025 16:37:57 +0900

MSA(Microservice Architecture)란?

MSA는 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누어 개발하고 운영하는 아키텍처이다.

각 서비스는 독립적으로 배포와 확장이 가능하고, 명확히 분리된 API로 통신을 하게 된다.

MSA의 특징

독립적으로 개발, 배포, 확장 가능
API 기반의 통신으로 서비스 간 느슨한 결합 유지
서비스 마다 서로 다른 언어나 기술 스택 사용 가능
장애 격리 : 특정 서비스 장애가 전체 시스템에 영향 최소화

이러한 MSA와 같은 분산환경에서 Kafka가 유용하게 사용될 수 있다.

서비스간 직접 호출 대신 Kafka 메시지 큐를 통해 이벤트 기반의 통신을 통해 서로 의존성을 줄일 수 있고,

비동기 작업 처리로 응답속도를 향상시킬 수 있다.

또한 Kafka의 토픽은 여러 개의 파티션으로 나뉘며, 각 파티션은 독립적으로 읽기/쓰기가 가능하여 클러스터 내 다른 브로커에 I/O부하를 분산하여 처리량을 높일 수 있다.

MSA 프로젝트에 Kafka 적용해보기

https://github.com/yangwoohyeon/MSA_Kafka

GitHub - yangwoohyeon/MSA_Kafka

Contribute to yangwoohyeon/MSA_Kafka development by creating an account on GitHub.

github.com

구현 기능

회원가입 서비스, 프로젝트에서는 Producer의 역할 (localhost:8080)
회원가입에 성공하면, DB에 저장 후, 회원정보(userId, email)를 Kafka 서버로 전송
Kafka 서버에서 Email Service로 회원정보 전달
Email Service에서는 회원가입 축하 이메일 전송(이메일 전송 로직 구현 생략)
Kafka 서버는 AWS EC2에 구현 ( Partition개수: 3개, Replication : 3개)

1. 토픽 생성

메시지 분산 저장 및 병렬 처리를 위해 3개의 파티션을 확보하고, 데이터 안정성과 가용성을 위해 각 파티션을 3개의 브로커에 복제

bin/kafka-topics.sh \
--bootstrap-server localhost:9092 \
--create \
--topic user.signed-up \
--partitions 3 \
--replication-factor 3

2. DLT 토픽 생성

메시지 처리 중 오류가 발생하여 정상적으로 메시지를 처리하지 못할 경우, 처리하지 못한 메시지를 별도로 분리하여 관리하고, 시스템의 안정성과 신뢰성을 높이기 위해 DLT 토픽을 생성해준다.

bin/kafka-topics.sh \
--bootstrap-server localhost:9092 \
--create \
--topic user.signed-up.dlt \
--partitions 1 \
--replication-factor 3

3. 회원가입 서비스 user-service 구현

<UsersignedUpEvent>

Kafka에 회원정보를 전달할때 Key와 Value를 String 타입으로 직렬화 하도록 지정했기 때문에 회원정보를 문자열로 변환하여 전송해야 한다.

따라서 Kafka로 보낼 정보를 객체로 캡슐화 하고, 객체를 JSON 형식의 String으로 변환하여 전송하기 위해 회원 정보를 저장할 UsersignedUpEvent 클래스를 생성해줬다.

package com.example.userservice;


//Kafka에 넣을 메시지 객체
public class UsersignedUpEvent {

    private Long userId;

    private String email;

    private String name;

    /*비밀번호는 이메일 서버에서 필요하지 않기 때문에 포함 X*/
    public UsersignedUpEvent(Long userId, String email, String name) {
        this.userId = userId;
        this.email = email;
        this.name = name;
    }

    public Long getUserId() {
        return userId;
    }

    public String getEmail() {
        return email;
    }

    public String getName() {
        return name;
    }
}

<UserService>

회원가입에 성공할 경우 회원 정보를 DB에 저장하고, toJsonString메서드를 이용해 Kafka에 전송할 객체를 JSON 형식의 String으로 변환하여 user.signed-up 토픽으로 전송한다.

package com.example.userservice;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    private final UserRepository userRepository;
    private final KafkaTemplate<String,String> kafkaTemplate; //Kafka 메시지 발행 객체

    public UserService(UserRepository userRepository, KafkaTemplate<String, String> kafkaTemplate) {
        this.userRepository = userRepository;
        this.kafkaTemplate = kafkaTemplate;
    }

    public void signUp(SignUpRequestDto signUpRequestDto){
        User user = new User( //유저 생성
                signUpRequestDto.getEmail(),
                signUpRequestDto.getName(),
                signUpRequestDto.getPassword()
        );
        User savedUser = userRepository.save(user); //유저 정보 DB에 저장

        UsersignedUpEvent usersignedUpEvent = new UsersignedUpEvent(
                savedUser.getId(),
                savedUser.getEmail(),
                savedUser.getName()
        );
        this.kafkaTemplate.send("user.signed-up",toJsonString(usersignedUpEvent));
    }

    private String toJsonString(Object object){ //Kafka에 전송할 객체를 Json형식의 String 으로 변환하기 위해 사용
        ObjectMapper objectMapper = new ObjectMapper();
        try{
            String message = objectMapper.writeValueAsString(object);
            return message;
        }catch(JsonProcessingException e){
            throw new RuntimeException("Json 직렬화 실패");
        }
    }
}

4. consumer 역할을 하는 email-service 구현

<UserSignedUpEvent>

Kafka에서 받은 메시지를 객체로 역직렬화 하기위한 DTO이다.

package com.example.email_service;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;

//Kafka에서 받은 이벤트 메시지를 JSON -> 객체로 역질렬화하는 DTO
public class UserSignedUpEvent {
    private Long userId;
    private String email;
    private String name;

    public UserSignedUpEvent(){ //역직렬화에 필요

    }

    public UserSignedUpEvent(Long userId, String email, String name) {
        this.userId = userId;
        this.email = email;
        this.name = name;
    }

    public static UserSignedUpEvent fromJson(String json){ //수신한 JSON 문자열을 객체로 변환
        try{
            ObjectMapper objectMapper = new ObjectMapper();
            return objectMapper.readValue(json, UserSignedUpEvent.class);
        }catch(JsonProcessingException e){
            throw new RuntimeException("JSON 파싱 실패");
        }
    }

    public Long getUserId() {
        return userId;
    }

    public String getEmail() {
        return email;
    }

    public String getName() {
        return name;
    }
}

<UserSignedUpEventConsumer>

user.signed-up 토픽을 구독하여 메시지를 수신할 수 있도록 했다.

메시지 처리에 실패할 경우 재시도 정책을 통해 5번까지 메시지 재처리하도록 하고, 모든 재시도에 실패할 경우 user.signed-up.dlt라는 DLT로 메시지를 이동 시킨다.

3개의 파티션에서 메시지를 병렬처리 하도록 하기 위해 concurrency값은 3으로 설정 하였다.

package com.example.email_service;

import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.kafka.annotation.RetryableTopic;
import org.springframework.retry.annotation.Backoff;
import org.springframework.stereotype.Service;

@Service
public class UserSignedUpEventConsumer {

    private EmailLogRepository emailLogRepository;

    public UserSignedUpEventConsumer(EmailLogRepository emailLogRepository) {
        this.emailLogRepository = emailLogRepository;
    }

    @KafkaListener(
            topics = "user.signed-up", //이 토픽에서 메시지를 수신
            groupId = "email-service",
            concurrency="3" //파티션 개수만큼 설정
    )
    @RetryableTopic( //재시도 정책 정의
            attempts = "5",
            backoff = @Backoff(delay=1000, multiplier = 2),
            dltTopicSuffix = ".dlt"
    )
    public void consume(String message) throws InterruptedException {
        UserSignedUpEvent userSignedUpEvent = UserSignedUpEvent.fromJson(message); //수신한 메시지를 객체로 변환

        //실제 이메일 발송 로직은 생략
        String receiverEmail = userSignedUpEvent.getEmail();
        String subject = userSignedUpEvent.getName()+ "님, 회원 가입을 축하드립니다!";;
        Thread.sleep(3000);
        System.out.println("이메일 발송 완료");

        EmailLog emailLog = new EmailLog(
                userSignedUpEvent.getUserId(),
                receiverEmail,
                subject
                );

        emailLogRepository.save(emailLog);
    }
}

프로그래머스 - 삼각 달팽이[Java]

연향동큰손 — Mon, 18 Aug 2025 23:59:29 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/68645

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

문제 해결 과정

이 문제에서 찾은 규칙은 다음과 같다.

첫번째 삼각형에서 아래로 가는 이동 횟수는 n번, 그 다음 삼각형에서는 n-3번
첫번째 삼각형에서 오른쪽으로 이동 횟수는 n-1번, 그 다음 삼각형에서는 n-3-1번
첫번째 삼각형에서 대각선 위로 이동하는 횟수는 n-2번, 그 다음 삼각형에서는 n-3-2번
아래 -> 오른쪽 -> 대각선 위 순서로 이동 후 len-3

import java.util.*;

class Solution {
    public int[] solution(int n) {
        int[][] arr = new int[n][n];
        int startX=0;
        int startY=0;
        int value=1;
        int size=0;
        int len=n;
        while(len>0){
            for(int i=0; i<len; i++){ //아래
                arr[startX][startY]=value;
                value++;
                startX++;
                size++;
                if(i==len-1){startX--;}
            }
            for(int i=0; i<len-1; i++){ //오른쪽
                startY++;
                arr[startX][startY]=value;
                size++;
                value++;
            }
            for(int i=0; i<len-2; i++){ //대각선
                startX--;
                startY--;
                arr[startX][startY]=value;
                size++;
                value++;
            }
            len=len-3;
            startX++;
        }
        int[] answer = new int[size];
        int index=0;
        for(int i=0; i<n; i++){
            for(int j=0; j<n; j++){
                if(arr[i][j]!=0){
                    answer[index]=arr[i][j];
                    index++;
                }
            }
        }
        
        return answer;
    }
    
    
}