Access Token의 유효기간을 짧게하여 보안도 높이고, 편의성도 챙기는 방법이다. 로그인을 완료하면, 유효기간이 짧은 Access Token과 유효기간이 긴 Refresh Token을 발급해준다.

Access Token은 기존에 사용하던 JWT 토큰이라고 생각하면 되고, Refresh Token은 Access Token이 만료되었을 때, 새로 발급해주는 토큰이라고 생각하면 된다.

Access Token 만료시간을 짧게 하면 보안성은 좋아집니다. 그러나, Access Token의 만료시간을 짧게 가져가면 사이트를 이용하는 회원은 자주 로그인 해야되는 불편함이 있습니다.

따라서, Refresh Token을 이용하여 Access Token을 재발급할 수 있고 Access Token의 유효 기간을 짧고 자주 재발급 하도록 만들어 보안을 강화하면서 사용자는 로그아웃 되어 다시 로그인해야 되는 상황을 주지 않도록 하기 위함입니다.

Refresh Token은 Access Token을 재발급하기 위한 용도입니다.

Refresh Token을 쿠키에 저장하면 오히려 보안성만 떨어뜨리는 행위가 됩니다. 쿠키는 CSRF 공격에 취약하다는 점을 가지고 있어 좋지 않은 방법이라고 결론을 내렸습니다.
마찬가지로 Refresh Token을 세션 스토리지에 저장하는 것도 XSS 공격의 취약성을 가지고 있습니다.

따라서 Refresh Token을 Redis에 저장하는 방식을 채택했습니다. 그 이유는

1. Key - Value 방식, 인메모리 DB 방식으로 빠르게 접근할 수 있습니다.
2. 브라우저에 비해 탈취 가능성이 낮다고 생각하는 redis 서버에 저장하는 방식입니다.
3. Refresh Token은 영구적으로 저장되는 데이터가 아닙니다.
   
   

레디스는 key-value 쌍으로 데이터를 관리할 수 있는 데이터 스토리지입니다. 모든 데이터를 메모리에(메인 메모리인 RAM) 저장하고 조회하는 in-memory 데이터베이스입니다.

Memcached 라는 인메모리 데이터 스토리지도 있지만, 성능차이가 크게 없고, Memcached는 문자열만 지원하기 때문에 Redis를 선택했습니다.

JPA를 사용할 때 더티 체킹(Dirty Checking)을 활용하는 것은 매우 JPA스러운 접근 방식입니다. 더티 체킹은 엔터티의 상태가 변경될 때 이를 자동으로 감지하고 변경 사항을 데이터베이스에 반영하는 JPA의 핵심 기능 중 하나입니다. 이 과정은 트랜잭션이 커밋되는 시점에 실행되며, 변경된 엔터티의 스냅샷과 원본 엔터티를 비교하여 자동으로 UPDATE 쿼리를 생성하고 실행합니다.

더티 체킹을 이용하면, 개발자는 엔터티의 상태를 직접 관리하고 적절한 시점에 데이터베이스에 반영할 쿼리를 작성할 필요가 없습니다. 이는 코드의 복잡성을 줄이고, 오류 발생 가능성을 낮추며, 개발자가 비즈니스 로직에 더 집중할 수 있게 해줍니다. 또한, 트랜잭션 커밋 시점에 쓰기 지연 SQL 저장소에 쌓인 쿼리들이 일괄적으로 데이터베이스로 전송되기 때문에 성능 측면에서도 이점이 있습니다.

Spring Data JPA에서는 @Query 애노테이션을 사용하여 직접 정의한 쿼리를 실행할 수 있습니다. 특히, 데이터의 변경을 수반하는 INSERT, DELETE, UPDATE 같은 쿼리를 실행할 때는 @Modifying 애노테이션을 함께 사용해야 합니다. 이 조합을 사용하면 JPA의 변경 감지 기능을 건너뛰고, 쿼리 실행을 더 효율적으로 할 수 있습니다. 예를 들어, 특정 사용자의 이름을 업데이트하는 경우 다음과 같이 작성할 수 있습니다:

@Transactional
@Modifying
@Query("UPDATE User u SET u.name = :name WHERE u.id = :id")
int updateUserName(@Param("id") Long id, @Param("name") String name);

@Transactional
@Modifying
@Query("UPDATE User u SET u.age = u.age + 1")
int incrementAllUserAges();

카프카(Kafka)는 웹사이트, 어플리케이션, 센서 등에서 수집된 데이터를 실시간으로 관리하고 전송하기 위해 설계된 분산 스트리밍 플랫폼입니다. 이 플랫폼은 데이터를 생성하는 어플리케이션과 데이터를 소비하는 어플리케이션 사이에서 중재자 역할을 하며, 데이터의 전송, 처리, 관리를 담당합니다. 카프카 시스템은 여러 요소(노드)로 구성될 수 있으며, 이를 '카프카 클러스터'라고 부릅니다.

이 시스템은 다른 메시징 시스템과 유사하게 어플리케이션과 서버 간의 비동기 데이터 교환을 용이하게 합니다. 또한, 카프카는 하루에 수조 개의 이벤트를 처리할 수 있는 능력을 가지고 있습니다. 간단히 말해, 카프카는 다양한 서비스로부터 나오는 데이터 흐름을 실시간으로 제어하고, 이를 통해 서비스 간 연결을 가능하게 하는 중추적인 역할을 하는 플랫폼입니다. 이를 통해 복잡한 데이터 환경에서도 효율적인 데이터 스트림 관리가 가능해집니다.

​ ▶ Cluster : 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
▶ Producer : 데이터를 만들어내어 전달하는 전달자의 역할
▶ Consumer : 프로듀서에서 전달한 데이터를 브로커에 요청하여 메시지(데이터)를 소비하는 역할
▶ Broker : 생산자와 소비자와의 중재자 역할을 하는 역할
▶ Topic : 보내는 메시지를 구분하기 위한 카테고리화

카프카(Kafka)는 기본적으로 listener를 통해 producer로부터의 요청을 받아 처리하는 구조를 가집니다. 이 시스템에서 'KafkaServer'는 broker 역할을 하며, producer와 consumer는 카프카가 제공하는 API를 통해 구현된 어플리케이션을 의미합니다.

카프카 클러스터는 하나 이상의 broker로 구성될 수 있습니다. 클러스터 내의 각 KafkaServer(broker)는 고유한 식별자인 'broker.id'를 부여받습니다. 또한, 이러한 broker는 producer로부터 생성된 메시지를 저장할 위치 정보와 클러스터의 메타정보를 저장 및 관리하기 위해 Zookeeper와 연결됩니다.

Kafka Cluster는 여러 브로커들의 정보를 관리하고 효과적인 리더 선출(leader election)을 위해 Zookeeper를 활용합니다. 특정 broker에 장애가 발생한 경우, 컨트롤러는 변경된 리더 파티션의 정보를 업데이트하기 전에 그 정보를 Zookeeper에 저장하는 방식으로 운영됩니다. 이러한 구조는 카프카 클러스터가 높은 가용성과 신뢰성을 유지할 수 있도록 도와줍니다.

카프카(Kafka)에서 이벤트 스트림은 '토픽(Topic)'이라는 이름으로 저장됩니다. 카프카의 토픽은 구체화된 이벤트 스트림을 의미하며, 연관된 이벤트들을 묶어 영속화하는 역할을 합니다. 이를 데이터베이스의 테이블이나 파일 시스템의 폴더에 비유할 수 있습니다.

토픽은 카프카에서 생산자(Producer)와 소비자(Consumer)를 분리하는 중요한 개념입니다. Producer는 카프카의 토픽에 메시지를 저장(push)하고, Consumer는 저장된 메시지를 읽어(pull)옵니다. 하나의 토픽에는 여러 Producer와 Consumer가 존재할 수 있습니다.

이러한 개념은 간단히 설명하면, 관련된 이벤트들이 모여 스트림을 형성하고, 이 스트림이 카프카에 저장될 때 토픽의 이름으로 저장됩니다. 이러한 과정을 통해 카프카는 대량의 데이터 스트림을 효율적으로 관리하고 처리할 수 있게 됩니다.

위에서 설명한 카프카의 토픽들은 여러 파티션으로 나눠집니다. 토픽이 카프카에서 일종의 논리적인 개념이라면, 파티션은 토픽에 속한 레코드를 실제 저장소에 저장하는 가장 작은 단위입니다. 각각의 파티션은 Append-Only 방식으로 기록되는 하나의 로그 파일입니다.

회원탈퇴 API 같은 경우, User-Server에서 회원을 탈퇴하면 Team-Server에 존재하는 UserSquad Table에서 삭제해야합니다. 이 상황에서 Kafka를 사용하여 회원 탈퇴 이벤트를 처리하는 경우, User-Server가 Kafka의 Producer 역할을 하고, Team-Server가 Consumer 역할을 합니다.

1. Kafka Config (USER-SERVER)

@Bean
public Map<String, Object> UserProducerConfig() {
    return CommonJsonSerializer.getStringObjectMap(BOOTSTRAP_SERVERS_CONFIG);
}

@Bean
public ProducerFactory<String, Long> deleteUserProducerFactory() {
    return new DefaultKafkaProducerFactory<>(UserProducerConfig());
}

@Bean
public KafkaTemplate<String, Long> deleteUserKafkaTemplate(){
    return new KafkaTemplate<>(deleteUserProducerFactory());
}

2. UserKafkaProducer

@Component
@RequiredArgsConstructor
public class UserKafkaProducer {
    private final KafkaTemplate<String, Long> deleteUserKafkaTemplate;

    public void deleteUser(Long userId) {
        deleteUserKafkaTemplate.send("user", userId);
    }

3. USER-SERVICE

@Transactional
public void deleteUser(String studentId) {
    User user = userRepository.findByStudentId(studentId)
            .orElseThrow(() -> new NotFoundException(NOT_FOUND_STATUS_CODE, NOT_REGISTER_USER_EXCEPTION_MESSAGE));
    userRepository.delete(user);
    userKafkaProducer.deleteUser(user.getId());
}

1. Kafka Config

@Bean
public Map<String, Object> ConsumerConfigs() {
    return CommonJsonDeserializer.getStringObjectMap(BOOTSTRAP_SERVERS_CONFIG, GROUP_ID_CONFIG);
}

@Bean
public ConsumerFactory<String, Long> deleteUserSquadConsumerFactory() {
    return new DefaultKafkaConsumerFactory<>(ConsumerConfigs());
}

@Bean
public ConcurrentKafkaListenerContainerFactory<String, Long> deleteUserSquadListener() {
    ConcurrentKafkaListenerContainerFactory<String, Long> factory =
            new ConcurrentKafkaListenerContainerFactory<>();
    factory.setConsumerFactory(deleteUserSquadConsumerFactory());
    return factory;
}

2. TEAM-SERVICE

@Transactional
@KafkaListener(topics = "user", groupId = "group_2")
public void deleteUserSqaud(Long userId) {
    userSquadRepository.deleteAllByUserIds(userId);
}