OMS의 back-end에 대한 내용 공유 페이지입니다.

## Transaction

`Transaction`이란 데이터베이스에서 상태를 변화시키기 위해 수행하는 작업의 단위를 뜻합니다. 
크게 4가지 특징이 있고 이를 ACID라 합니다.1

1.	원자성(Atomicity)

트랜잭션에서 정의된 연산들은 모두 성공적으로 실행되던지 아니면 전혀 실행되지 않아야 합니다.

2.	일관성(Consistency)

트랜잭션이 실행 되기 전의 데이터베이스 내용이 잘못 되어 있지 않다면 트랜잭션이 실행된 이후에도 데이터베이스의 내용에 잘못이 이쓰면 안됩니다.

3.	독립성(Isolation)

트랜잭션이 실행되는 도중에 다른 트랜잭션의 영향을 받아 잘못된 결과를 만들어서는 안됩니다.

4.	지속성(Durability)

트랜잭션이 성공적으로 수행되면 그 트랜잭션이 갱신한 데이터베이스의 내용은 영구적으로 저장됩니다.

## Transactional 어노테이션

Spring에서는 `@Transactional` 어노테이션을 사용해서 선언적 트랜잭션을 사용합니다. 
서비스의 한 메서드를 Transaction 단위로 만들어 주는 역할을 합니다. 
위에서 설명한 트랜잭션의 4가지 특징을 서비스에서 보장해줍니다. 
선언하는 방법은 메서드에 선언하거나, 서비스에 선언을 합니다. 
서비스에 선언을 할 경우 서비스 내의 메서드들이 전부 영향을 받게 됩니다.

-	롤백

트랜잭션의 원자성 특징으로 연산들은 모두 실행되던지 혹은 전혀 실행되지 않아야 합니다. 
따라서 서비스에서 Exception이 발생할 경우에 결과가 commit되지 않고 모두 rollback 됩니다.

```java
@Service
@RequiredArgsConstructor
public class TransactionService {

	private final UserRepository userRepository;

	@Transactional
	public void transactionTest(Long id) throws Exception {
		User user = userRepository.findById(id).orElseThrow();
		userRepository.delete(user);
		throw new Exception("익셉션 발생");
	}

}
```

위의 예시에서 user 엔티티를 삭제하여서 delete 문을 통해 데이터가 삭제되어야 하지만, `Exception`이 발생하게 되면 삭제되지 않게 됩니다.

### 주의할 점

```java
@Service
@RequiredArgsConstructor
public class TransactionService {

	private final UserRepository userRepository;

	public void transactionParent(Long id) {
		transactionChild(id);
	}

	@Transactional
	public void transactionChild(Long id) throws Exception {
		User user = userRepository.findById(id).orElseThrow();
		userRepository.delete(user);
		throw new Exception("익셉션 발생");
	}
}
```

위의 코드가 실행되면 어떻게 동작할까요? 
`@Transactional`의 동작에 의해서는 user가 delete되지 않고 rollback되어야 정상입니다. 
하지만 위의 코드가 실행된다면 rollback이 되지 않고 user가 삭제됩니다. 
그 이유는 `@Transactional` 어노테이션은 Proxy 방식으로 동작하기 때문입니다. 
Spring은 proxy로 접근해서 기존 코드를 가로채 앞 뒤로 transaction을 처리하는 코드를 생성해줍니다.

```java
@Service
public class TransactionService {
	
	@Transactional
	public void test() {
		...
	}
}
```

위의 코드가 있다면 실제로 동작하는건 프록시로부터 아래의 코드처럼 동작합니다.

```java
public class TransactionProxy {
	private final TransactionManager manager = TransactionManager.getInstance();

	public void transactionLogic() {
		try {
			manager.begin(); // 트랜잭션 전처리
			est(); // 코드 동작
			manager.commit();
		} catch (Exception e) {
			manager.rollback();
		}
	}
}
```

그런데 이 Proxy모드는 오직 외부로부터의 method 호출이 발생한 경우에만 인터셉트 되어서 트랜잭션 관리가 가능해집니다. 
그렇기 때문에 내부에서 호출할 경우에는 해당 메서드의 `@Transactional`이 적용되지 않으니 유의하면서 코드를 작성해야 합니다.

### readOnly 옵션

`readOnly`옵션은 Transaction내에서 조회를 하겠다고 선언하는 옵션입니다. 
이 옵션을 사용해야하나? 라 하면 사용하는 것이 좋다. 입니다. 
첫번째로는 readOnly옵션이 있을 경우 영속성 컨텍스트가 엔티티를 관리하지 않게 됩니다. 
즉 1차캐시에 스냅샷을 만들어 두지 않기 때문에 단순 조회만 사용할 경우에 성능이 올라가게 됩니다. 
두번째로는 혹시모를 데이터 변경을 방지할 수 있습니다. 
만약 업데이트문을 사용하지 않을것인데 엔티티의 내용이 변경되거나 return이 된다면 데이터 변경이 일어날수도 있는데,(물론 이미 잘못 설계된 코드입니다.) 이를 방지하여 줍니다. 
세번째로는 선언만으로 직관적으로 조회 서비스인걸 알 수 있습니다. 
CUD 로직이 없음을 알기에 알아보기 쉬워지고 신뢰성이 보장됩니다. 
네번째로는 MySql을 사용할 경우에는 읽기 전용으로 master가 아닌 slave를 호출해서 DB 서버의 부하를 줄여줍니다. 
이러한 이유들로 단순 조회쿼리를 사용할 경우에도 readOnly 옵션을 사용하는 것이 좋습니다.

```java
@Service
@RequiredArgsConstructor
public class TransactionService {
	private final UserRepository userRepository;

	@Transactional(readOnly = true)
	public UserDto getUserStatus(Long id) {
		User user = userRepository.findById(id).orElseThrow();
		return user.toDto();
	}
}
```

Spring에서 제공하는 Transactional 어노테이션의 역할 및 사용법

Transactional 어노테이션

## 더티 체킹

더티 체킹(Dirty Checking)이란 상태 변경을 감지한다는 의미입니다. 
JPA에서 엔티티를 다룰 때 한 엔티티의 변경이 일어나면, 그 변경을 감지하여서 자동으로 Update를 데이터베이스에 반영하여 줍니다. 
JPA Repository에는 Update를 위한 메서드가 따로 존재하지 않는데, 이는 더티 체킹을 통해 업데이트를 하는것이 일반적이기 때문입니다.

-	더티 체킹 범위

더티 체킹은 한 Transaction 내부에서만 이뤄지는데, Transaction은 `EntityManager`를 이용해 Transaction을 생성하여 이용하거나, JPA Data에서는 `@Transactional` 어노테이션을 이용해 생성합니다. 
영속성 컨텍스트는 Entity를 보관할 때 최초의 상태를 저장하는데 이를 스냅샷이라고 합니다. 
영속성 컨텍스트가 Flush되는 시점에 스냅샷과 현재의 엔티티를 비교해 상태가 달라진 Entity를 찾아 Update 쿼리를 생성하여 줍니다. 
영속성 컨텍스트가 Flush 되는 시점은 1. `Transaction commit` 2. `EntityManager flush` 3. `@Modify(flushAutomatically = true)`가 있습니다.

```java
@Service
@RequiredArgsConstructor
public class DirtyCheckService {
	private final EntityManagerFactory entityManagerFactory;

public void dirtyCheckEntityManager(Long id, String nickName) {
	EntityManager em = entityManagerFactory.createEntityManager();
	EntityTransaction transaction = em.getTransaction();
	transaction.begin(); // 트랜잭션 시작
	User user = em.find(User.class, id);
	user.changeNickName(nickName); // 엔티티 변경
	transaction.commit();
}
}
```

위의 예시는 EntityNabager를 이용해 transaction을 생성하고 그 안에서 Entity를 조회하고, 그 값을 변경하였습니다. 
Transaction내에서 User 엔티티가 조회된 순간에 EntityManager가 관리를 시작하고, 해당 엔티티의 변경을 감지하고, `transaction.commit();` 으로 감지된 변경사항을 Update문을 통해 변경합니다. 
직접 Update문과 관련된 메서드나 쿼리를 작성하지 않아도 자동으로 Update가 이뤄집니다.

```java
@Service
@RequiredArgsConstructor
public class DirtyCheckService {
	private final UserRepository userRepository;

	@Transactional
	public void dirtyCheckTransactional(Long id, String nickName) {
		User user = UserRepository.findById(id).get();
		user.changeNickName(nickName);
	}
}
```

JPA Data에서는 `@Transactional` 어노테이션을 통해 자동으로 트랜잭션 관리를 합니다. 
해당 메서드 안에서 User엔티티를 조회하고, 그 순간 EntityManager에서 엔티티를 관리합니다. 
이후 메서드가 끝날 때 변경을 감지하고 Update 쿼리를 사용합니다. 
당연히도 위의 코드에서 `@Transactional 어노테이션을 제외하면 엔티티의 nickName값은 변하지만 DB에는 영향을 주지 않습니다.

-	더티 체킹 대상

더티 체킹은 모든 엔티티를 대상으로 하진 않습니다. 
영속성 컨텍스트가 관리하는 엔티티들만 대상으로 더티 체킹을 하는데, `detach`된 엔티티(준영속)나 DBㅔ 반영되기 전 새로운 엔티티(비영속)를 대상으로는 더티 체킹을 하지 않습니다.

```java
@Service
@RequiredArgsConstructor
public class DirtyCheckService{
	private final UserRepository userRepository;

	@Transactional
	public void dirtyCheckTest(Long id, Long id2, String nickName) {
		User user = userRepository.findById(id).get(); // 조회를 통해 영속된 Entity
		User user2 = User.builder().nickName(nickName); // 비영속 상태인 새로운 Entity
		user2.changeNickName(nickName + "11"); // Dirty Check를 수행하지 않아 변경점이 DB에 저장되지 않음
		User user3 = userRepository.findById(id2);
		User user4 = userRepository.save(user3); // save를 통해 eturn 받는 Entity는 영속이 됨. 반대로 기존의 Entity는 detach 상태가 됨.
 user3.changeNickName(nickName + "22"); // 준영속상태이기에 Dirty Check를 수행하지 않음
 user4.changeNickName(nickName + "33"); // 영속 상태이기 때문에 Dirty Check를 수행하여 Update문 생성
	}
}
```

## 더티 체킹 vs JPQL

많은 수의 row를 Update해야할 때는 더티 체킹보다 벌크 연산용으로 쿼리를 사용하는 것이 좋습니다. 
더티 체킹을 활용할 경우, 한 Row마다 Update문이 나가기 때문인데 이를 활용하여 빠른 속도로 Update를 마칠 수 있습니다.

```java
public interface UserRepository extends JpaRepository<User, Long> {
	@Modifying(clearAutomatically = true, flushAutomatically = true)
	@Query("update User u set u.age = u.age + 1 where u.id in :ids")
	void updateAgePlus(@Param("ids") List<Long> ids);
}
```

JPA에서 업데이트를 하는 방법과 더티체킹의 의미

JPA의 더티체킹(Dirty Checking)과 Update

JPA Repository에는 save메서드가 있습니다. 
이는 어쩔때는 INSERT문을 사용하고, 어쩔때는 UPDATE문을 사용합니다. 
이를 결정해주는건 `isNew`메서드를 사용하여서 해당 Entity가 새로 생긴건지 기존의 것인지를 구분합니다.

## SimpleJpaRepository 구현체

```java
// SimpleJpaRepository.java
@Transactional
public <S extends T> S save(S entity) {
	if (entityInformation.isNew(entity)) {
		em.persist(entity);
		return entity;
	} else {
		return em.merge(entity);
	}
}
```

위는 JPA Repository의 구현체인 SimpleJpaRepository에서 save메서드의 구현입니다. 
`isNew`메서드로 Entity가 새롭게 만들어진 것인지, 기존의 것인지를 구분하고 새로운것이면 `persist`를 아니면 `merge`를 수행합니다.

### isNew

```java
// AbstractEntityInformation.java
public boolean isNew(T entity) {
	ID id = getId(entity);
	Class<ID> idType = getIdType();

	if (!idType.isPrimitive()) {
		return id == null;
	}

	if (id instanceof Number) {
		return ((Number) id).longValue() == 0L;
	}

	throw new IlleaglArgumentException(String.format("Unsupported primitive id type %s!", idType));
}
```

위는 AbstractEntityInformation에서의 `isNew`메서드 구현체 입니다. 
ID의 타입이 기본 타입일 경우 0일 때, 참조 타입일 경우 null인 경우에 true를 반환합니다. 
이는 `@GeneratedValue`에 맞춰서 구현되어 있기 때문인데, 해당 어노테이션을 사용할 경우에는 INSERT시에 id값을 주지 않기 때문입니다. 
사실상 `@GeneratedValue`를 사용하지 않는 Entity면 false를 리턴하게 됩니다.

### persist vs merge

-	persist

	`persist`는 최초로 새엇ㅇ된 Entity를 영속화 합니다. 
	flush메서드가 호출될 때 `INSERT`문을 사용하게 됩니다.

-	merge

	`merge`는 `detached`상태의 Entity를 다시 영속화 합니다. 
	`detached`란 한번이라도 영속화가 되었지만 현재는 영속화가 되어있지 않은 상태 입니다. 
	다시 영속화 하는 과정에서 id값을 통해 `SELECT`문으로 값을 확인하게 됩니다. 
	flush메서드가 호출될 때 `SELECT`의 결과가 있다면 `UPDATE`를 없다면 `INSERT`를 사용합니다.

여기서 주의해야할 점은 `merge`입니다. 
`save`의 구현체를 보면 `persist`의 경우에는 기존의 Entity를 return하지만, `merge`의 경우에는 새로운 Entity를 return 합니다.

```java
@Transactional
public void test() {
	User user = User.builder()
			.id("id")
			.name("이름")
			.build();

	User insertUser = userRepository.save(user); // INSERT
	System.out.println(user == insertUser); // false

	insertUser.updateName("새로운 이름");
	User updateUser = userRepository.save(insertUser); // UPDATE
	System.out.println(insertUser == updateUser); // false
}
```

위의 테스트 코드를 동작하면 insertUser와 user도 서로 다르고, updateUser도 서로다른 Entity인 것을 확인할 수 있습니다. 
이 때 이전에 있던 Entity들은 더이상 영속성 관리 대상이 아니게 됩니다. 
그에 따른 dirtyCheck도 수행하지 않게 됩니다.

```java
@Transactional
public void test() {
	User user = User.builder()
			.id("id")
			.name("이름")
			.build();

	User insertUser = userRepository.save(user); // INSERT

	insertUser.updateName("새로운 이름");
	User updateUser = userRepository.save(insertUser); // UPDATE

	insertUser.updateName("또다른이름"); // dirtyCheck로 인한 UPDATE가 발생하지 않음.
	// updateUser.updateName("또다른이름"); 으로 하면 UPDATE가 제대로 발생함.
}
```

또다른 테스트 코드를 실행해보면 insertUser의 name을 변경하여도 dirtyCheck로 인한 UPDATE문이 발생하지 않는 것을 확인할 수 있습니다. 
따라서 `save`이후에 어떠한 로직을 수행할 경우 반드시 return 값을 새로이 받아서 사용하는 것이 좋습니다. 
만약에 `@GeneratedValue`를 사용한다면 결과가 달라질 수 있습니다.

```java
@Entity
@Builder
public class Board {
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private id;

	private String content;
}
````

```java
@Transactional
public void test() {
	Board board = Board.builder()
				.content("내용").build();

	Board insertBoard = boardRepository.save(board);
	System.out.println(board == insertBoard); // true
	board.updateContent("새로운 내용"); // dirtyCheck로인한 UPDATE가 발생함
}
```

위의 테스트 코드에선 `persist`로 인해 같은 엔티티를 return하였고, 그 결과로 dirtyCheck가 수행된것을 확인할 수 있습니다.

## SELECT 없이 INSERT 하기(Persistable 구현)

한개나 두개의 row를 INSERT하는 경우라면 SELECT문이 발생해도 큰 지장이 없습니다. 
하지만 만약 1000개의 row를 INSERT하게 된다면 1000번의 SELECT문이 발생할 것이고, 이는 성능적으로 장애를 일으킬 수 있습니다. 
JPA에서는 이를 방지하기 위해 `isNew`메서드를 오버라이드 해와 직접 구현할 수 있습니다.

```java
public class User implements Persistable<String> {
	@Id
	private String id;

	@Override
	public String getId() {
		return id;
	}

	@Override
	boolean isNew() {
		return false;
	}
}
```

### Auditing 활용

지난번의 [Auditing 포스트](/post/back-end/auditing)의 Auditing기능을 활용할 수 있습니다. 
`@CreatedDate`는 entity가 INSERT될 때 자동적으로 입력이 됩니다. 
이를 이용하여서 필드값이 null일 경우에 isNew가 false임을 return하면 됩니다.

```java
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@Getter
public abstract class Auditalbe {
 ......
	@CreatedDate
	@Column(name = "create_time", columnDefinition = "date", nullable = false, updateable = false)
	protected LocalDateTime createDateTime;
 ......
}
```

```java
public class User extends Auditable implements Persistable<String> {
	@Id
	private String id;

	@Override
	public String getId() {
		return id;
	}

	@Override
	boolean isNew() {
		return createDateTime = null;
	}
}
```

이렇게 구현할 경우 createDateTime이 null일 경우 SELECT문 없이 INSERT를 사용합니다.

## 마치며

JPA Repository의 save메서드를 분석하여 보았습니다. 
save 메서드를 통하여서 UPDATE를 할 경우, null인 데이터들은 그대로 null로 update가 될 수 있습니다. 
다음번에는 이를 방지하기 위한 방법과 dirtyCheck로 인한 UPDATE를 알아보겠습니다.

JPA Repository에서 save 메서드가 INSERT, UPDATE를 결정하는 방법과, SELECT없이 INSERT하는 방법

JPA의 save 메서드 동작과정과 SELECT 없이 INSERT하기

객체를 생성하는 방법에는 생성자 패턴, 메소드 패턴 등등이 있는데, 그 중에 빌더 패턴이 있습니다.

## Builder패턴 만들기

Lombok을 사용할 경우 빌더 패턴을 만들어서 사용하기 매우 편해집니다. 
하지만 그 이전에 Lombok없이 빌더 패턴의 구조를 만들어보도록 하겠습니다.

```java
public class User {
	private string id;
	private String password;

	User(String id, String password) {
		this.id = id;
		this.password = password;
	}

	public static User.UserBuilder builder() {
		return new User.UserBuilder();
 }

 public static class UserBuilder {
 private String id;
 private String password;

 public UserBuilder () { } //NoArgsConstructor

 public User.UserBuilder id(String id) {
 this.id = id;
 return this;
 }

 public User.UserBuilder password(String password) {
 this.password = password;
 return this;
 }

 public User build() {
 return new User(this.id, this.password);
 }
 }
}
```

위의 구조를 보면 User클래스와 그 내부 static 객체인 UserBuilder클래스를 생성하였습니다. 
User 클래스에서는 빌더 클래스에서 사용될 생성자가 하나 필요합니다. 
그리고 빌더클래스를 생성해주는 static builder 메서드를 만듭니다. 
빌더 클래스에선 기본 생성자 하나와 자기 자신을 return 하는 필드를 채우는 메서드들을 만듭니다. 
마지막으로는 User 클래스의 생성자를 이용해 자신의 필드들로 객체를 생성합니다.

```java
User user = User.builder()
		.id("홍길동")
		.password("1234").build();
```

빌더 패턴을 완성하였다면 위의 예시와 같이 객체를 생성할 수 있게 됩니다. 
위의 코드들을 Lombok을 사용하면 단 하나의 어노테이션으로 만들 수 있습니다.

```java
@Builder
public class User {
	private String id;
	private String password;
}
```

위의 class에 `@Builder` 어노테이션을 이용하면 위와 완전히 동일한 코드가 됩니다. 
또한 `@Builder` 어노테이션은 생성자에다가도 사용하여 특정 필드들만을 대상으로 구현할 수 있습니다.

```java
public class User {
	private String id;
	private String password;
	private String name;

	@Builder
	User (String password, String name) {
		this.password = password;
		this.name = name;
	}
}
```

Lombok은 매우 강력하지만, 모르고 쓰면 독이 된다 생각합니다. 
잘 알고 적용하는 것이 중요한데 그 이유를 설명하겠습니다.

### @Builder의 기능

`@Builder` 어노테이션은 빌더 클래스를 만들고 메서드를 제공해주는 기능만 있지 않습니다. 
Builder 어노테이션의 설명을 보면 아래와 같이 나와있습니다.

![builder size:600*150](/back-end/builder.png)

해석하면 클래스에 `@Build` 어노테이션을 사용할 경우 모든 필드를 인수로 사용하는 생성자를 제공해줍니다.(`@AllArgsConstructor(access = AccessLevel.PRIVATE)`) 
하지만 항상 제공하는 것이 아니라 생성자를 하나도 작성하지 않고, `@XArgsConstructor` 주석이 없을 경우 에만 제공해줍니다. 
만약 생성자가 있다면 Lombok은 모든 필드를 인수로 사용하는 생성자가 있다고 가정하고 코드를 생성하게 됩니다. 
즉 해석에 따르면 아무런 생성자 없이 `@Build`어노테이션 하나만 사용하거나, 그렇지 않은 경우에는 반드시 `@AllArgsConstructor`와 함께 이용해야 합니다.

### 생성자의 접근 단계

빌더 패턴을 사용할 때 생성자의 접근 단계또한 중요합니다.

-	기본생성자는 protected

`@NoArgsConstructor(access = AccessLevel.PROTECTED)`를 이용하여 기본성생자를 protected하게 합니다. 
그 이유는 무분별한 객체 생성을 막는 것인데 서비스에서 기본생성자를 통해 객체를 만들고 setter로 필드를 채울 경우에 완전하지 않은 객체가 될 가능성이 크기 때문입니다.

-	@Build 기반 생성자는 private

빌더 패턴을 사용할 객체는 `build()`를 통해서만 객체 생성을 제공하는 것이 좋습니다. 
또한 `@AllArgsConstructor`로 인해 변하기 쉬운 코드를 방지할 수 있습니다. 
따라서 아래와 같이 사용하는게 좋습니다.

```java
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder
public class User {
	private String id;
	private String password;
	private String name;

	// 따로 생성자를 사용할 경우
	@Builder
	protected User (String password, String name) {
		this.password = password;
		this.name = name;
	}
}
```

## 사용하는 이유 (ResponseEntity)

Rest API 컨트롤러에서는 응답을 만들 때 ResponseEntity를 사용합니다. 
이 객체의 경우에는 생성자 패턴, 메서드 패턴, 빌더 패턴 모두 사용이 가능한데, 이 객체를 통해 예시를 들어보겠습니다.

```java
// 생성자 패턴 사용 1
return new ResponseEntity<TestDto>(testDto, HttpStatus.OK);
// 생성자 패턴 사용 2 (header 추가)
HttpHeaders httpHeaders = newHttpHeaders();
httpHeaders.add("token", "test");
return new ResponseEntity<TestDto>(testDto, httpHeaders, HttpStatus.OK);
// 생성자 패턴 사용 3 (상태코드만 보내줄 경우
return new ResponseEntity(HttpStatus.OK);
```

생성자 패턴을 이용한 구현입니다. 
코드를 보았을 때 코드의 직관성이 떨어지고, 코드를 확장할 외부의 라이브러리를 사용할 경우 생성자의 모양을 알아야만 사용할 수 있습니다.

```java
// 메서드 패턴 사용 1
return ResponseEntity.ok(testDto);
// 메서드 패턴 사용 2 (header 추가)
ResponseEntity<TestDto> response = ResponseEntity.ok(testDto);
response.getHeaders().add("token", "test");
return response;
// 메서드 패턴 사용 3 (상태코드만 보내줄 경우)
return Response.ok(null);
```
메서드 패턴을 이용한 구현입니다. 
메서드 패턴은 간단한 기능만 수행할 경우에는 거기에 맞는 코드를 작성하여 코드가 간결해지나, 코드를 확장할 경우 코드가 복잡해지거나 알맞는 메서드를 찾아야 합니다.

```java
// 빌더 패턴 사용 1
return Response.ok().body(testDto);
// 빌더 패턴 사용 2 (header 추가)
return ResponseEntity.ok()
	.header("token", "test")
	.body(testDto);
// 빌더 패턴 사용 3 (상태코드만 보내줄 경우)
return ResponseEntity.ok().build();
```

빌더 패턴을 이용한 구현입니다. 
필드명만 알면 코드에 일관성이 유지되고 유지보수가 쉬워집니다. 
위의 각 3가지 예시는 완전히 동일한 동작을 하는 코드입니다. 
상황에 따른 장단점은 있겠지만 확장을 할 경우에는 builder 패턴을 유용하게 사용할 수 있습니다. 
또한 코드를 한눈에 알아보기 쉽게 되어서 분석이 쉬워집니다. 
그리고 이 차이는 DTO같은 객체들을 직접 다룰 때 더 크게 나타납니다.

## 필드 기본값 주기

Lombok에는 `@Builder.Default`가 있습니다. 
이를 활용해 쉽게 필드의 기본값을 줄 수 있습니다.

```java
@Builder
public class User {
 private String id;
 private String name;
 @Builder.Default
 private String nation = "Korea";

}
```

하지만 이 방식은 class에 어노테이션을 붙일 경우에만 사용이 가능합니다. 
생성자에 `@Builder` 어노테이션을 사용할 경우에는 기본값이 들어가지 않습니다. 
따라서 아래와 같이 구현함으로서 기본값을 줄 수 있습니다.

```java
public class User {
 private String id;
 private String name;
 private String nation;

 @Builder
 private User (String id, String name) {
 this.id = id;
 this.name = name;
 this.nation = "Korea"; // 초기값을 줄 수 있습니다.
 }

}
```

생성자에서 직접 값을 초기화 함으로서 기본값을 줄 수 있게 됩니다.

## 필수 파라미터 확인하기

또한 생성자를 이용하여서 필수로 들어가야할 파라미터가 존재하는지 확인할 수 있습니다.

```java
public class User {
 private String id;
 private String password;
 private String name;

 @Builder
 private User(String id, String password, String name) {
 Assert.notNull(id, "id must not be null");
 this.id = id;
 this.password = password;
 this.name = name;
 }
}
```

## 마치며

Builder 패턴은 필드 수가 많을수록 큰 강점을 가지고 있습니다. 
실수를 줄여주고 확실한 객체를 만들기 쉽습니다. 
하지만 Builder 패턴 자체를 구현하기 위해서 들어가는 코드의 양이 많아지고,
또한 생성자 방식처럼 아예 필수 필드들을 처음부터 받을 수 있지 않아서 그에 따른 단점 또한 존재합니다. 
장,단점을 파악하고 사용하였을 때 빌더 패턴의 강점을 이용할 수 있다 생각합니다.

객체를 생성자가 아닌 Builder패턴으로 생성하기

Builder 패턴 사용하기

MSA에서는 각 설정파일(.yml, .properties) 들을 서비스 내부에서 관리하는것이 아니라, Config server를 두어서 설정값을 넘겨줍니다. 
이로 인해 여러 서비스에서 하나의 설정파일을 공유할 수도 있고, 혹은 설정 값을 변경할 때 중앙에서 쉽게 관리할 수 있게 됩니다. 
뿐만 아니라 dev, prod 환경 등을 구분하여 설정파일을 제공해줄 수 있어서 개발환경과 배포환경을 쉽게 구분하여 구성할 수 있습니다. 
Spring Cloud에선 Cloud Config Server를 통해 중앙 서버에서 Config설정을 관리하는 서비스를 만들 수 있습니다. 
[공식 홈페이지](https://cloud.spring.io/spring-cloud-config/refresence/html)

## Cloud Config Server 구성

build.gradle에 `Spring cloud` 의존성을 추가하고 Application 클래스에 `@EnableConfigServer`어노테이션을 추가함으로서 Cloud Config Server로 사용할 수 있습니다.

```groovy
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter'
	implementation 'org.springframework.cloud:spring-cloud-config-server'
}
```

```java
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
	public static void main(String[] args) {
		SpringApplication.run(ConfigServerApplication.class, args);
	}
}
```

## 저장소

Config Server에서 yml을 관리할 저장소는 크게 2가지가 있습니다. 
첫번째로는 config server의 로컬 파일 시스템을 활용하는 방법과, 두번째로는 다른 git repository를 이용해 그곳으로 부터 가져올 수 있습니다.

### 로컬 파일 시스템

```yml
spring:
	profiles:
		active: native
	cloud:
		config:
			server:
				native:
					search-locations: classpath:configs/
```

`spring.profiles.active` 속성을 native로 한다면 설정파일을 외부가 아닌 파일 시스템 혹은 프로젝트 내부 소스에서 제공하겠다는 의미입니다. 
`spring.cloud.config.server.native.search-locations` 속성은 설정파일들을 가져올 위치를 정할 수 있습니다. 
classpath를 이용해 현재 서비스의 `/src/main/resources/`로 부터 설정파일을 가져올 수 있습니다.

![config-directory](/back-end/config-directory.png)

위처럼 configs 폴더로부터 설정파일을 가져오게 됩니다.

### Git 저장소

```yml
server:
	port: 8881

spring:
	cloud:
		config:
			server:
				git:
					uri: https://github.com/show5116/...git
					username: test
					password: test
					search-paths: configs
```

git repository를 만들어서 username과 password를 통해 접근하고, 그 repository의 search-paths의 위치로 부터 설정 파일들을 가져올 수 있습니다.

## Client에서 사용

각 Client서비스에서는 Cloud Config Server로부터 설정정보를 가져와서 빌드시에 설정파일을 적용해줍니다. 
설정파일은 정해진 순서대로 읽게 되고, 같은 속성이 존재할 경우 마지막에 읽는 속성값으로 적용됩니다.

```groovy
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-config'
}
```

```yml
spring:
	application:
		name: auth-service
	cloud:
		config:
			uri: http://localhost:8881# config server uri
	profiles: 
		active: dev,test
```

### yml 파일 명 규칙

저장소로부터 yml파일을 가져오는 요소는 총 3가지가 있습니다.

-	`{application}` `spring.application.name`에 매핑됩니다.
-	`{profile}` `spring.profiles.active`에 매핑됩니다. (쉼표로 구분)
-	`{label}` git의 경우 branch로 매핑됩니다.

위의 yml파일과 같이 설정하였을 경우 우선 순위를 가지고 속성이 적용됩니다.

1.	config server `{application}-{profile}.yml`
2.	config server `{application}.yml`
3.	config server `application-{profile}.yml`
4.	각 프로젝트 `application-{profile}.yml`
5.	config server `application.yml`
6.	각 프로젝트 `application.yml`

만약 profile이 여러개일 경우 쉼표(,)를 기준으로 앞의 profile을 우선으로 적용합니다. 
실제로는 위의 우선순위의 반대로 yml파일을 불러오며, 만약 먼저 불러온 속성과 겹치는 속성이 뒤에 있을 경우 그 값을 덮어 쓰면서 기존의 값은 사라지게 됩니다.

## 마치며

위의 설정을 이용하여 실제로 dev, prd 환경에 맞게 설정값들을 쉽게 가져올 수 있습니다. 
더하여서 config server 자체를 숨기는 방법도 있고, 혹은 git private repository를 이용하여 ssh key를 통해 설정 값을 가져올 수 도 있고 무중단 설정값 변경 등 onfig server의 활용방법은 많습니다. 
각 어플리케이션마다 특징이나 환경이 다르니 공식 문서를 참조하면서 알맞게 적용하는 것이 좋을 수 있습니다.

Spring Cloud Config를 이용하여 중앙에서 설정파일을 관리해보자.

Spring Cloud Config

JPA에서는 Audit기능을 제공해줍니다. 
Audit은 감시하다 라는 뜻으로, 이 기능을 활용하면 생성일, 수정일, 생성한 사람, 수정한 사람의 정보를 남길 수 있습니다. 

## @MappedSuperclass

![mappedSuperclass size:800*400](/back-end/mapped-superclass.png)
`@MappedSuperclass` 어노테이션은 부모클래스에 선언하여서 상속받는 Entity들은 모두 상속받은 컬럼을 가지게 해줍니다. 
이 어노테이션을 사용한 클래스는 `엔티티`가 아니고, 상속관계 매핑이 아닙니다. 
위의 이미지와 같이 BaseEntity란 부모클래스가 id와 name이란 컬럼을 가지고 있다면, Member와 Seller Entity는 이를 상속받아 두개의 컬럼을 가지게 됩니다.

```java
@MappedSuperclass
@Getter
public abstract class BaseEntity {
	@Column(name = "create_user", columnDefinition = "varchar2(50)", nullable = false, updatable = false)
	private String createUser;

	@Column(name = "change_user", columnDefinition = "varchar2(50)", nullable = false)
	private String modifyUser;

	@Column(name = "create_time", columnDefinition = "date", nullable = false, updateable = false)
	private LocalDateTime createDateTime;

	@Column(name = "change_time", columnDefinition = "date", nullable = false)
	private LocalDateTime modifyDateTime;

}
```

위에는 createUser, modifyUser, createDateTime, modifyDateTime 4개의 컬럼을 가진 추상클래스를 만들었습니다. 

```java
@Entity
@Table(name = "users")
public class User extends BaseEntity {
 ......
}
```

이런방식으로 해당 4개의 컬럼이 필요한 Entity에서 BaseEntity를 상속받으면 4개의 컬럼을 가지게 됩니다. 
대부분의 Entity는 생성시간과 수정시간을 저장해두면 좋으니 상속받아 구현하면 좋습니다.

## Audit 사용하기

`@MappedSuperclass`을 이용해 추상클래스를 구현하였다면, 이젠 Audit 기능을 사용하여서 INSERT, UPDATE시에 저 컬럼들에 값을 자동으로 넣도록 할 수 있습니다.

### Config

Audit을 위한 Configuration 파일을 생성해줍니다. 
`@EnableJpaAuditing`어노테이션은 사용한 어플리케이션에 JPA Audit 기능을 제공해주게 되는 어노테이션입니다. 
메인 어플리케이션 클래스에서 사용하여도 상관없지만, Test코드를 이용할 때와 또한 정확하게 기능을 구분하기 위해 따로 사용하는 것이 좋습니다.

```java
@Configuration
@EnableJpaAuditing
public class AuditingConfig implements AuditorAware<String> {

	@Override
	public Optional<String> getCurrentAuditor() {
		HttpServletRequest currentRequest = WebHelper.getCurrentRequest();
 String memberId = currentRequest.getHeader("member-id");
 memberId = memberId.isEmpty() ? "System" : memberId;
		return Optional.of(memberId);
	}
}
```

```java
public class WebHelper {
	public static HttpServletRequest getCurrentRequeset() {
		return ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
	}
}
```

`AuditorAware`을 implements하면 `getCurrentAuditor` 메서드를 구현하게 됩니다. 
해당 클래스는 추후에 createUser와 modifyUser에 들어가게 될 값을 정해줍니다. 
현재 HttpServletRequest를 가져오고, RequestHeader를 통해 member-id를 넣어줍니다. 
혹여 member-id가 없는 상황(Spring 스케쥴러를 통한 상황, 혹은 회원 가입 등..)에선 System이란 아이디를 넣어줍니다.

### 추상클래스 변경

앞에서 만들었던 추상클래스를 변경해주도록 하겠습니다. 
`@EntityListeners` 어노테이션은 JPA Entity에서 이벤트가 발생할 때마다 특정 로직을 실행시킬 수 있게 해주는 어노테이션입니다. 
AuditingEntityListener.class의 값을 주면 @PrePersist로 Audit 기능을 수행하게 해줍니다.

```java
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@Getter
public abstract class Auditalbe {
	@CreatedBy
	@Column(name = "create_user", columnDefinition = "varchar2(50)", nullable = false, updatable = false)
	protected String createUser;

	@LastModifiedBy
	@Column(name = "change_user", columnDefinition = "varchar2(50)", nullable = false)
	protected String modifyUser;

	@CreatedDate
	@Column(name = "create_time", columnDefinition = "date", nullable = false, updateable = false)
	protected LocalDateTime createDateTime;

	@LastModifiedDate
	@Column(name = "change_time", columnDefinition = "date", nullable = false)
	protected LocalDateTime modifyDateTime;

}
```

- @CreatedDate

Entity가 INSERT될 때 생성 시간을 넣어줍니다. 
JPA에서 제공하는 `@CreateDate` 말고 Hibernate에서 제공하는 `@CreationTimestamp`이란 어노테이션도 존재합니다. 
둘의 차이점은 `@CreateDate`는 위에서 한 것과 같이 `@EnableJpaAuditing`과 `@EntityListeners`를 필요로 합니다. 
반면에 `@CreationTimestamp`는 그러한 설정없이 동작이 가능합니다. 
그 이유는 JPA는 JPA 고유 메모리 공간(context)을 이용해 Entity 객체들을 관리하는데 관리되는 객체들이 변경되면 데이터에 반영하는 형식이라 변화를 감지해야 하기 때문입니다.

- @LastModifiedDate

Entity가 UPDATE될 때 수정 시간을 넣어줍니다. 
마찬가지로 Hibernate에서 제공하는 `@UpdateTimestamp`이란 어노테이션이 존재해서 대신 사용해도 됩니다.

- @CreatedBy

Entity가 INSERT될 때 `getCurrentAuditor`메서드를 통해 얻어온 값을 넣어줍니다.


- @LastModifiedBy

마찬가지로 Entity가 UPDATE될 때 `getCurrentAuditor`메서드를 통해 얻어온 값을 넣어줍니다.

JPA의 Auditing과 MappedSuperclass를 이용하여 INSERT와 UPDATE시 시간과 저장한 사람의 정보를 담습니다.

JPA의 Auditing 기능 INSERT, UPDATE시 시간 저장하기

JPA에서는 데이터를 삭제하는 방법이 여러가지 있습니다. 
논리적 삭제(UPDATE문)을 통한 방법도 있지만 해당 글은 물리적 삭제(DELETE문)에 대한 글입니다.

## JpaRepository


```java
public interface UserRepository extends JpaRepository<User, String> {
}
```

```java
@Entity
@Table(name = "users")
@NoArgsConstructor(acessLevel = Accesslevel.PRIVATE)
public class User {
	@Id
	@Column(name = "user_id")
	private String id;

	......
}
```

JPA에서 제공하는 JpaRepository는 인터페이스를 만드는 것 만으로도 다양한 CRUD 메서드들을 제공해줍니다. 
[JpaRepository](/post/back-end/jpa-repository)참조 
그 중에서도 delete 관련된 메서드들이 존재하는데, 해당 메서드들에 대해서 먼저 알아보고 각 맞는 사용법에 대해 설명드리겠습니다.

### delete

`delete(T entity)`는 가장 기본적인 delete 메서드 입니다. 
매개변수로 entity를 받고 아래의 쿼리로 단일 조회를 마친 후 해당 row가 있다면 delete하고, 없다면 아무런 일이 일어나지 않습니다.

```sql
SELECT member.*
 FROM member
 WHERE member.id = ?
```

```java
@Service
@RequiredArgsConstructor
public class MemberService {
	private final MemberRepository repository;

	@Transactional
	public deleteOne(String id) {
		Member member = repository.findById(id).get();
		repository.delete(member);
	}
}
```

단일 데이터 삭제를 할때는 유용하게 사용됩니다. 
조회 쿼리가 나가는게 부담도 없고 사용하기도 편합니다. 
JpaRepository의 구현체인 SimpleJpaRepository에는 아래와 같이 구현되어 있습니다.

```java
// SimpleJpaRepository.java
@Transactional
public void delete(T entity) {
	
	Assert.notNull(entity, "Entity must not null!");
	// isNew() 메서드는 엔티티의 ID 유무를 확인해 DB에 들어간 값인지 아닌지를 판단합니다.
	if (entityInformation.isNew(entity)) {
		return;
	}

	T existing = em.find(entityInformation.getJavaType(), entityInformation.getId(entity));

	if (existing == null) {
		return;
	}
	em.remove(em.contains(entity) ? entity : em.merge(entity));
}
```

### deleteAll

`deleteAll(Iterable<? extends T> entities)` 이 메서드는 위의 delete메서드를 반복하는 것과 같은 역할을 합니다. 
실제로 JpaRepository의 구현체를 보면 delete를 반복하여서 구현한 것을 확인할 수 있습니다.

```java
// SimpleJpaRepository.java
@Transactional
public void deleteAll(Iterable<? extends T> entities) {
	Assert.notNull(entities, "Entities must not be null");

	for (T entity : entities) {
		delete(entity);
	}
}
```

결국 이 메서드도 삭제를 진행하기 전에 모든 데이터를 SELECT를 하고 DELETE를 실행하여서 데이터의 row가 많을 경우 실행시간이 오래걸릴 수 있습니다. 
매개변수를 넣지 않을경우에는 해당 Entity의 모든 데이터를 삭제합니다.

```java
// SimpleJpaRepository.java
@Transactional
public void deleteAll() {
	for (T element : findAll()) {
		delete(element);
	}
}
```

### deleteById

`deleteById(ID id)`는 id값으로 Entity를 조회하고 있다면 삭제합니다. 
Entity가 없다면 `EmptyResultDataAccessException` 익셉션이 던져집니다.

```java
// SimpleJpaRepository.java
@Transactional
public void deleteById(ID id) {
	Assert.notNull(id, ID_MUST_NOT_BE_NULL);

	delete(findById(id).orElseThrow(() -> new EmptyResultDataAccessException(
String.format("No %s entity with id %s exists!", entityInformation.getJavaType(), id), 1)));
}
```

여기까지의 delete 메서드들을 보았을 때 모두 SELECT를 하여서 존재 유무를 확인한 후에 DELETE를 하였습니다. 
따라서 다수의 데이터를 삭제할때는 당연히 수행시간이 늦어질 수 밖에 없습니다. 
일부러 ID가 없을경우 익셉션을 내야하는 경우가 아니라면 (그런 경우가 있는지도 모르겠지만..) 단건이 아닌 데이터들에 위의 메서드들을 사용하는 것은 안좋은 방법이라 생각합니다.

### deleteInBatch

**주의 2022년 기준으로 해당 메서드는 <del>deprecated</del> 되었고, deleteAllInBatch(Iterable entities)로 대체되었습니다.(로직은 동일)** 
`deleteInBatch(Iterable entites)`는 위의 메서드들과는 달리 SELECT문을 사용하지 않습니다.

```java
SimpleJpaRepository.java
@Transactional
public void deleteInBatch(Iterable<T> entities) {
	Assert.notNull(entities, "Entities must not be bull!");

	if (!entities.iterator().hasNext()) {
		return;
	}

	applyAndBind(getQueryString(DELETE_ALL_QUERY_STRING, entityInformation.getEntityName()), entities, em)
		.executeUpdate();
}
```

위의 `getQueryString` 으로 가져오는 쿼리문은 delete문입니다.

```java
// QueryUtils
public static final String DELETE_ALL_QUERY_STRING = "delete from %s x";
```

그리고 또한 `applyAndBind`는 아래와 같이 구현되어 있습니다.

```java
public static <T> Query applyAndBind(String queryString, Iterable<T> entities, EntityManager entityManager) {
	...
	Iterator<T> iterator = entities.iterator();
	...
	StringBuilder builder = new StringBuilder(queryString);
	builder.append(" where");

int i = 0;
	
	while (iterator.hasNext()) {
		iterator.next();

builder.append(String.format(" %s = ?%d", alias, ++i));

		if (iterator.hasNext()) {
			builder.append(" or");
		}
	}
}
```

로직에 따르면 or절을 계속해서 이어붙이면서 where 절을 완성시킵니다. 
실제 쿼리는 아래와 같이 나가게 됩니다.

```sql
DELETE FROM meber
 WHERE member.id = ? OR member.id = ? ...
```

결과적으로 이 메서드는 단 한번의 delete 쿼리를 만들어서 삭제를 하기 때문에 위의 메서드들보다 빠르게 삭제가 가능합니다. 
하지만 이 메서드도 완벽하진 않습니다. 
그것은 바로 JPA 내부의 문제점인데, 쿼리를 생성할 때 너무 많은 or절을 생성할 경우 `StackOverFlow`익셉션이 발생하는 현상이 있습니다. 
따라서 한번의 많은 데이터를 DELETE할 때 갑작스레 에러가 발생할 수 있습니다.

### deleteAllInBatch

`deleteAllInBatch()`는 매개변수 없이 테이블의 모든 데이터를 삭제합니다. 
위처럼 where절을 생성하지도 않고 SELECT 절을 사용하지도 않습니다. 
하지만 실제 서비스에선 사용할 일이 거의 없을것입니다.

```java
//SimpleJpaRepository.java
@Transactional
public void deleteAllInBatch() {
	em.createQuery(getDeleteAllQueryString()).executeUpdate();
}
```

## Bulk delete 해결방법

결국 가장 좋은 방법은 순정이라고, 직접 delete 쿼리를 작성하는 방법입니다.

```java
pulibc interface MemberRepository extends Repository<Member, String> {
	@Modifyung(clearAutomatically = true, flushAutomatically = true)
	@Query("delete from Member m where m.id in :ids")
	void deleteAllByIds(@Param("ids") Iterable<String> ids);
}
```

위와 같이 in절을 이용해 커스텀 쿼리문을 작성하면 빠른 성능으로 삭제를 할 수 있습니다.

### @Modifying

위와 같은 벌크 연산을 실행하게 될 시에는 영속성 컨텍스트를 무시하고 쿼리가 실행됩니다. 
따라서 이미 제거된 엔티티를 조회할 가능성이 생길 수 도 있는데 `@Modifying` 어노테이션은 DB와 데이터 싱크를 맞춰주는 역할을 합니다. 
`@Modifying` 어노테이션은 JPA Entity의 Life Cycle을 무시하고 쿼리가 실행됩니다. 
그래서 영속성 관리를 위한 clearAutomatically 속성과 flushAutomatically 속성이 있습니다.

-	clearAutomatically

	이 속성은 쿼리 메서드 실행 후, 영속성 컨텍스트를 clear해주는 속성입니다. 
	이 속성을 true로 하면 삭제된 Entity를 조회할 일이 사라지게 됩니다.

-	flushAutomatically

	이 속성은 쿼리를 실행하기 전, 영속성 컨텍스트의 변경사항을 DB에 lush할 것인지 결정하는 속성입니다. 
	default는 false이나, Hibernate의 FlushModeType이 default로 AUTO값이기에 따로 설정하지 않으면 flushAutomatically가 false이든 true이든 항상 쿼리 실행 전에 flush가 나가게 됩니다.

Spring data Jpa에서 delete를 하는 여러 가지 방법과 대량 데이터 삭제할 때 더 좋은 방법

JPA delete (bulk delete)

## JpaRepository

Spring Data JPA를 사용하면 기본적인 CRUD쿼리는 직접 작성하지 않고 공통 인터페이스를 통해 사용합니다. 
JpaRepository는 공통 인터페이스로서 `save()`, `saveAll()`, `findById()`, `delete()` 등등.. 간단한 메서드가 이미 정의되어 있습니다. 
해당 메서드들의 구현체는 `SimpleJpaRepository`에 구현되어 있어서 인터페이스를 생성하는 것 만으로도 CRUD가 가능합니다.

```java
@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {
	...
	@Transactional
	public <S extends T> S save(S entity) {
		if (entityInformation.isNew(entity)) {
			em.persist(entity);
			return entity;
		} else {
			return em.merge(entity);
		}
	}
}
```

위의 코드는 실제 구현체에서 save 메서드에 대한 구현 로직입니다.

### 기본 사용법

1.	Entity 생성

```java
@Entity
@Getter
@NoArgsConstructor(access = Accesslevel.PRIVATE)
@AllArgsConstructor(access = Accesslevel.PROTECTED)
@Builder
public class Test {
	@Id
	@GenerationValue(straregy = GenerationType.IDENTITY)
	private Long id;

	private String name;

	public updateName(String name) {
		this.name = name;
	}
}
```

2.	Repository 새엇ㅇ
Repository를 생성합니다. 
이 때 Bean에 등록할 @Repository 어노테이션은 사용하지 않아도 됩니다. 
구현체 클래스에서 이미 어노테이션이 선언 되어있기 때문에 상속받는 것 만으로도 Bean에 올라갑니다.

```java
// 제네릭 좌측은 Entity 클래스를, 우측에는 해당 Entity의 Id 타입을 넣어줍니다.
public interface TestRepository extends JpaRepository<Test, Long>
```

3.	메서드 사용

```java
@Service
@RequiredArgsConstructor
public class TestService {
	private final TestRepository testRepository;

	@Transactional(readOnly = true)
	public Test getTestEntity(long id) {
		Optional<Test> testWrapper = testRepository.findById(id);
		Test test = testWrapper.orElseThrow();
	}

	@Transactional
	public void insertTestEntity(String name) {
		Test test = Test.builder()
				.name(name).build();
		testRepository.save(test);
	}

	@Transactional
	public void updateTestEntity(long id, String newName) {
		Optional<Test> testWrapper = testRepository.findById(id);
		Test test = testWrapper.orElseThrow();
		test.updateName(id);
	}

	@Transactional
	public void deleteTestEntity(long id) {
		testRepository.deleteById(id);
	}
}
```

위의 예시처럼 select, insert, update, delete문을 간단하게 구현 가능합니다. 
이외에도 페이징 쿼리나 bulk 연산 쿼리들도 기본 메서드로 구현되어 있습니다. 
각 기능들에 대해선 추후에 포스팅 하겠습니다.

### 메서드 정의하기

JpaRepository는 특수한 명명 규칙으로 메서드를 정의하여 사용할 수 있습니다. 
특정 검색조건이나 orderBy, 혹은 특정row 갯수만 조회한다던가 메서드 이름으로 여러 방법으로 활용할 수 있습니다. 
이에 대해서도 추후에 자세하게 포스팅하겠습니다.

```java
public interface TestRepository extends JpaRepository<Test, Long> {
	public List<Test> findAllByName(String name);
}
```

### @Query 어노테이션

@Query 어노테이션을 이용해서 JPQL 문법을 활용해 쿼리를 직접 작성할 수 있습니다. 
nativeQuery = true 속성을 통해 nativeQuery도 사용 가능합니다.

```java
public interface TestRepository extends JpaRepository<Test, Long> {
	@Query("select t.username from Test t")
 public List<String> findAllName();

 @Query("select t from Test t where t.name = :name")
 public Optional<Test> findTestByName(String name);
}
```

## JpaRepository의 계층

![Repository-interface size:800*400](/back-end/repository-interface.png')

위에서 사용한 JpaRepository는 PagingAndSortingRepository를 상속받았고, 그 위에는 CrudRepository 최종적으로는 Repositry interface로부터 상속받았습니다. 
JpaRepository는 최하층으로서 CrudRepository에선 Crud 메서드를, PagingAndSortingRepository에선 Paging 쿼리를 그리고 JpaRepository에선 flush메서드 등이 구현됩니다. 
최 상단인 Repository를 상속받으면 구현이 되어있는 메서드가 전혀 없습니다. 
따라서 사용할 메서드를 직접 선언해줘야만 합니다.

```java
public interface TestRepository extends Repository<Test, Long> {

 public Test save(Test test);

 public void delete(Test test);

 public Optional<Test> findById(Long id);
}
```

실제 JpaRepository에서 사용하는 메서드와 같은 타입, 같은 이름으로 선언해주면 동일한 로직을 수행하는 메서드가 구현되게 됩니다.

## Repository를 사용하면 좋은 이유

그렇다면 왜 Repository 인터페이스를 언급했을까요? 
실제로 JpaRepository를 사용해도 서비스에는 문제는 없습니다. 
하지만 JpaRepository를 사용할 경우에는 실제로 사용하지 않는 메서드들이 너무 많이 만들어집니다. 
그에 따라 Repository를 사용할 경우 상대적으로 얻게되는 장점들이 있습니다.

1. 필요한 메서드들만 구현하고 외부로 노출

 repository만 보더라도 어떤 역할들을 하는지 한눈에 알아볼 수 있게 됩니다. 
 또한 IDE에서는 해당 메서드들을 사용하고 있는 위치를 쉽게 추적도 가능하게 해줍니다.

2. 메서드의 재사용성

 필요한 메서드들만 구현할 경우 메서드들의 재사용성이 늘어납니다. 
 이에 따라서 쿼리 캐싱의 가능성이 높아지게 됩니다.

이러한 점들로 인하여 Repository를 사용하면 조금 더 Repository의 역할에 집중할 수 있게 해줍니다. 
물론 JpaRepository를 상속받으면 코드의 수도 적어지고 구현하기 쉬워지니 무엇이 무조건 맞다고는 할 수 없습니다.

JpaRepository의 간단한 사용법과 그냥 Repository를 사용할 때의 이점

JpaRepository의 사용법 그리고 Repository

[JWT 로그인 방식 구현 포스트](/post/back-end/access-token)에선 access token을 발급받는 과정까지 구현하였습니다. 
하지만 access token 하나만 가지고는 보안에서 한계가 존재하는데 이를 refresh token으로 극복할 수 있습니다.

## refresh token

JWT는 무상태(Stateless) 방식을 사용합니다. 
즉 서버가 클라이언트의 상태를 보존하지 않게 되는데, JWT가 만약 탈취당할 경우 서버는 이를 알지 못합니다. 
즉 누군가에게 토큰을 탈취당하면 아이디 비밀번호를 모르더라도 서비스를 제약 없이 사용할 수 있게 됩니다. 

refresh token이란 이런 단점을 보안하기 위해 새로운 하나의 토큰을 더 사용하는 것입니다. 
access token의 유효시간을 짧게 하고, 이 유효기간이 지날 경우에는 refresh token을 이용해서 새로운 access token을 발급하여 사용할 수 있게 합니다. 
즉 refresh token의 유효기간은 로그인 유지 시간이 되고, access token은 그 시간 내에 OTP처럼 계속해서 발급받는 토큰이 됩니다.

## refresh token의 탈취

하지만 refresh token도 마찬가지로 탈취당하면 위험합니다. 
탈취한 refresh token을 이용해서 새로운 access token을 발급받을 수 있고, 새로이 발급받은 access token으로 서비스를 이용할 수 있습니다. 
결국 access token 하나만 사용할 때와 마찬가지로 탈취당하게 된다면 refresh token을 사용한 의미가 없게 될 수 있습니다. 
그래서 이러한 현상을 막기 위해 refresh token에는 새로운 접근이 필요합니다.

### 서버에서 refresh token을 관리

refresh token을 발급하고 서버의 로직으로 이를 관리합니다. 
하지만 서버가 클라이언트의 상태를 가지게 되므로 더이상 무상태(Stateless)가 아니게 됩니다. 
서버에서 refresh token을 관리하는 방법으로는 세션을 이용하거나 데이터베이스를 이용합니다. 
세션의 경우에는 사용자가 많아질수록 부담이 심해지고 관리가 힘들어집니다. 
거기에 더불어 무상태(Stateless)에서 완전하게 벗어나게 되므로 JWT를 사용하는 이점을 잃게 됩니다. 
따라서 데이터베이스를 사용하는 것이 더 좋다 생각합니다. 
이 또한 무상태(Stateless)는 벗어나지만 적어도 access token의 유지 시간동안은 서버의 접근을 필요로 하지 않기 때문에 어느정도는 포기하지 않을 수 있습니다.

-	access token 저장 위치

access token은 탈취당할 경우 유지시간이 짧더라도 그 시간동안은 서비스를 이용할 수 있습니다. 
javascript의 비공개(private) 변수를 이용하면 가장 안전하게 지킬 수 잇습니다. 
비공개 변수에는 공격자가 접근할 방법이 없으니 XSS나 CSRF 공격으로부터 자유롭습니다. 
하지만 javascript의 변수라서 단점이 존재하는데, 페이지 이동이나 새로고침을 하게 되면 해당 변수는 사라지게 됩니다. 
따라서 페이지에 접근할 때 access token을 새로 발급받는 로직을 추가해야 합니다.
React 프레임워크처럼 CSR만 사용한다면 그나마 덜하지만 Next 프레임워크처럼 SSR을 사용한다면 access token을 자주 재발급 받게 될 수 도 있습니다.

-	refresh token 저장 위치

refresh token을 저장할 수 있는 저장소의 종류는 3가지가 있습니다. 
로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage) 그리고 쿠키(Cookie)가 있습니다. 
`로컬 스토리지`와 `세션 스토리지`는 둘 다 자바스크립트로 저장하고 가져올 수 있습니다. 
따라서 XSS공격을 통해 토큰을 탈취당할 가능성이 존재합니다. 
이 둘은 둘다 새로고침이나 페이지 이동에도 저장소가 유지되나, 세션 스토리지는 새로운 탭으로 열릴 경우 저장소를 공유하지 않습니다. 
`쿠키`의 경우에는 자바스크립트로도 접근이 가능하고, 서버로부터 접근도 가능하여서 XSS공격과 CSRF공격에 모두 취약합니다. 
그래도 쿠키는 이러한 공격으로부터 비교적 안전하게 사용할 수 있는 옵션들이 존재합니다. 
`HttpOnly`가 true일 경우 쿠키는 자바스크립트로 접근이 불가능하게 되어 XSS로부터 비교적 안전합니다. 
`Secure`옵션은 Https로만 쿠키가 전해지기 때문에 Https설정을 할 경우에 안전해집니다. 
`SameSite`옵션은 크로스 사이트(Cross-site)로 전송하는 요청에 대하여 쿠키를 제한합니다. 
SameSite옵션은 Strict모드와 Lax모드가 있습니다. 
`Strict`모드는 같은 도메인 범위에서만 해당 쿠키를 사용하게 되며, `Lax`모드는 기본적으로 Strict모드와 비슷하나 사용자가 페이지 이동이나 혹은 Form을 통한 Get 요청시에는 크로스 사이트에도 사용합니다. 
SameSite옵션을 활용하면 CSRF공격으로 부터 어느정도 안전하게 됩니다. 
결론으로는 access token을 private 변수에 사용하게 될 경우 그리고 후술할 RTR방식까지 사용하게 될 경우 access token은 탈취 불가능해지고 refresh token만 탈취해서는 할 수 있는 것이 없게 됩니다. 
비교적 쿠키가 안전하다고는 하나 쿠키도 공격자들이 마음만 먹으면 XSS나 CSRF공격을 완전하게 막을 순 없습니다. 
따라서 개인적으로는 저장소는 선택의 영역이라 생각합니다.

-	access token 유지 시간

access token의 유지 시간은 짧으면 짧을수록 보안이 강화됩니다. 
하지만 그만큼 서버에 접근하는 횟수가 많아지기 때문에 사용자가 많을수록 부담이 될 가능성이 있습니다. 
짧으면 분단위, 길면 시간단위로 설정합니다.

-	refresh token 유지 시간

refresh token도 마찬가지로 유지 시간이 짧을수록 보안은 강화됩니다. 
하지만 유지시간은 곧 로그인 유지시간이니 짧으면 짧을수록 사용자들이 UX적으로 불편함을 느낄 수 있습니다. 
시간단위나 날짜단위로 설정합니다.

### Refresh Token Rotation(RTR)

데이터베이스에 refresh token과 access token을 1:1로 설계합니다. 
그러면서 refresh token과 access token이 1:1이 되기에 refresh token도 1회용으로만 사용이 가능해집니다. 
새로운 access token을 발급받을 때 동시에 refresh token도 발급받음으로서 기존의 refresh token은 폐기합니다. 
이 과정을 `Refresh Token Rotation`이라고 합니다. 
만약 누군가가 refresh token을 탈취하더라도 사용 전에 refresh token이 이미 발급되면 사용이 불가능해집니다. 
또한 refresh token을 탈취 당하더라도 access token이 같이 탈취 당하지 않는 이상 사용이 불가하고, 혹여나 둘다 탈취당했다 하더라도 기존 사용자의 refresh token이 폐기 됨으로써 기존 사용자가 재발급을 요청할 경우 토큰이 유출되었음을 감지할 수 있게 됩니다.

-	IP 정보와 함께 사용

사용자의 IP를 받아서 데이터베이스에 같이 저장합니다. 
토큰의 유효성을 검사할 때 IP정보도 확인함으로서 조금 더 안전하게 사용이 가능합니다.

-	로그인 유지 시간 갱신

RTR방식을 사용할 경우 refresh token을 재생성 할 때 마다 만료 시간 클레임을 다시 정해줄 수 있습니다. 
그에 따라 refresh token 재발급 할 때 마다 계솏해서 새로운 만료 시간을 줄 수도 있고, 혹은 초기의 만료시간을 다시 주면서 처음 로그인 시 기준으로 만료시간을 정해줄 수도 있습니다.

## 구현

위에서 서술한 방식을 토대로 구현해보도록 하겠습니다. 
refresh token은 쿠키에 저장할 경우에는 서버쪽 코드에서 저장해야하고, 로컬 스토리지에 저장할 경우에는 자바스크립트 코드에서 저장해야 합니다. 
저는 실제로 자바스크립트 코드로 구현하여서 서버쪽에선 respnose에 추가해주었습니다.

### 엔티티

```java
@Entity
@Table(name = "token")
@NoArgsConstructor(access = Accesslevel.PROTECTED)
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class Token {
	@Id
	@Column(name = "user_id")
	private String id;

	@Column(name = "access_token")
	private String accessToken;

	@Column(name = "refresh_token")
	private String refreshToken;

	@Column(name = "ip_address")
	private String ipAddress;

	@OneToOne
	@MapsId
	@JoinColumn(name = "user_id")
	private User user;

	public void updateUser(User user) {
		this.userId = user.getId();
		this.user = user;
	}
}
```

```java
@Entity
@Table(name = "users")
@NoArgsConstructor(access = Accesslevel.PROTECTED)
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class User {
	@Id
	@Column(name = "user_id")
	private String id;

	@Column(name = "password")
	private String password;

	@Column(name = "user_name")
	private String name;

	@OneToOne(cascade = CascadeType.ALL, mappedBy = "user")
	@PrimaryKeyJoinColumn
	private User user;

	public void updateToken(Token token) {
		this.token = token;
	}
}
```

### controller

refreshToken을 이용해 새로운 accessToken을 발급받을 로직을 추가해줍니다. 
@RequestMapping 의 Method를 지정하지 않아서 Get, Post, Delete 등 어떠한 Method로 넘어오더라도 발급이 가능하도록 합니다. 
이렇게 한 이유는 API-Gateway에서 access-token 인증에 실패할 경우 API 주소만을 변경해주기 때문에 기존의 Method방식으로 그대로 넘어오기 때문입니다. 
그러면 화면에서는 사용자가 눈치채지 않게끔 access-token을 자연스럽게 발급받을 수 있습니다.

```java
@RestController
@RequiredArgsConstructor
public class SignController {
	private final SignService signService;

	@PostMapping("/auth/sign/in")
	public ResponseEntity<SignInResponse> signIn(HttpServlet request, @RequestBody SignInRequest requestBody) {
		return ResponseEntity.ok(signService.signIn(request, requestBody));
	}

 @RequestMapping(value = "/auth/sign/refresh")
 public ResponseEntity<SignResponse> refreshToken(
	 HttpServletRequest request,
	 @RequestHeader("Refresh-Token") String refreshToken
 ) {
	 return ResponseEntity.ok(signService.refreshToken(accessToken, refreshToken));
 }
}
```

```java
// SignResponse
@NoArgsConstructor
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class SignInResponse {
	private String memberName;

	// 기존의 token을 accessToken으로 수정
	private String accessToken;

	// 새로운 refreshToken 추가
	private String refreshToken;
}
```

### Service

[JWT 로그인 방식 구현 포스트](/post/back-end/access-token)에서 구현한 로그인 로직에 refresh token도 발급하도록 수정하겠습니다. 
또한 refreshToken을 새로 발급받는 서비스를 구현합니다. 
IP주소가 다를경우 로그인을 차단하였지만, 서비스에 따라서 핸드폰 인증을 거치게 하는 방식으로 구현도 가능합니다.

```java
@Service
@RequiredArgsConstructor
public class SignService {

	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());
	private static final String AUTH_TOKEN_HEADER_PREFIX = "Bearer ";

	private final BCryptPasswordEncoder passwordEncoder;
	private final JwtUtil jwtUtil;
	private final UserRepository userRepository;
	// 새롭게 Token Repository를 추가합니다.
	private final TokenRepository tokenRepository;

	@Transactional
	public SignResponse signIn(HttpServletRequest request, SignInRequest requestBody) {
		User loginUser = userDao
			.findById(requestBody.getId())
			.filter(user -> passwordEncoder.matches(AesCryptUtil.decrypt(requestBody.getPassword()), user.getPassword()));

		String accessToken = jwtUtil.createAccessToken();
		// refreshToken도 같이 발급해줍니다.
		String refreshToken = jwtUtil.createRefreshToken(loginUser);

		this.updateToken(loginUser, accessToken, refreshToken, request);

		logger.info("{} login success", requestBody.getId());

		return SignInResponse.builder()
			.memberName(loginUser.getMemberName())
			.accessToken(accessToken)
			.refreshToken(refreshToken)
 .build();
	}

 @Transactional
	public SignResponse refreshToken(HttpServletRequest request, String refreshToken) throws Exception {
 String subRefreshToken = refreshToken.subString(AUTH_TOKEN_HEADER_PREFIX.length());
 // refreshToken이 만료될 시 여기서 Exception 발생
 String userId = jwtUtil.getTokenField(subRefreshToken, PrivateClaimKey.USER_ID, String.class);

		User loginUser = userRepository.findById(userId).orElseThrow();

 if (loginUser.getToken() == null) {
 // 무언가 잘못된 요청으로 refreshToken이 폐기될 경우 입니다.
 throw new Exception("잘못된 요청 시도가 있었습니다. 본인이 아닐 시 문의 바랍니다.");
 } else if (!refreshToken.equals(loginUser.getToken().getRefreshToken())) {
 // 이미 폐기된 refreshToken을 통해 인증을 시도할 경우입니다.
			tokenRepository.delete(loginUser.getToken());
			throw new Exception("잘못된 인증 값입니다. 여러 매체에서 로그인 시도한 경우가 아닐 시 해킹 가능성이 있으니 확인 바랍니다.");
		} else if (!WebHelper.getIpAddress(request).equals(loginUser.getToken().getIpAddress())) {
		 // IP 주소가 처음 로그인 시도한 곳과 다를 경우입니다.
 tokenRepository.delete(loginUser.getToken());
			thorw new Exception("다른 IP주소에서 접근을 시도하셨습니다. 다시 로그인 해주세요.");
		}

 String newAcessToken = jwtUtil.createAcessToken(loginUser);
		String newRefreshToken = jwtUtil.createRefreshToken(loginUser);

		this.updateToken(loginUser, newAccessToken, newRefreshToken, request);

 return SignInResponse.builder()
			.memberName(loginUser.getMemberName())
			.accessToken(newAcessToken)
			.refreshToken(newRefreshToken)
 .build();
	}

	public void updateToken(User user, String accessToken, String refreshToken, HttpServletRequest request) {
		String ipAddress = WebHelper.getIpAddress(request);

		if(user.getToken() != null) {
			tokenRepository.delete(user.getToken());
		}

		Token token = Token.builder()
			.accessToken(accessToken)
			.refreshToken(refreshToken)
			.ipAddress(ipAddress)
			.build();

		token.updateUser(user);
		user.updateToken(token);

		userRepository.save(user);
		tokenRepository.save(token);
	}
}
```

### JwtUtil

refresh Token을 발급할 메서드를 추가해줍니다. 
또한 TokenField interface를 활용하여서 특정 클레임을 parsing 하는 메서드를 만들었습니다.

```java
@Component
public class JwtUtil {

	@Value("${jwt.signKey}")
	private String jwtSignKey;

	public String createAccessToken() {
		Map<String, Object> body = new HashMap<>();
		body.put(PublicClaimKey.NAME.getValue(), user.getName());
		body.put(PrivateClaimKey.USER_ID.getValue(), user.getId());

		return this.createToken("accessToken", body, 30);
	}

 	public String createRefreshToken() {
		Map<String, Object> body = new HashMap<>();
		body.put(PublicClaimKey.NAME.getValue(), user.getName());
		body.put(PrivateClaimKey.USER_ID.getValue(), user.getId());

		return this.createToken("refreshToken", body, 60 * 24 * 2);
	}

	public String createToken(String subject, Map<String, Object> body, int expirationTime) {
		LocalDateTime currentTime = LocalDateTime.now();

		Claims claims = Jwts.claims(body);

		return Jwts.builder()
			.setClaims(claims)
			.setSubject(subject)
			.setIssuer("https://oms-tech-blog.netlify.app")
			.setIssuedAt(Date.from(currentTime.atZone(ZoneId.systemDefault()).toInstant()))
			.setExpiration(Date.from(currentTime.plusMinutes(expirationTime).atZone(ZoneId.systemDefault()).toInstant()))
			.signWith(SignatureAlgorithm.HS512, jwtSignKey)
			.compact();
	}

	public <T> T getTokenField(String token, TokenField tokenField, Class<T> type) {
		return Jwts
			.parser()
			.setSigningKey(jwtSignKey)
			.parseClaimsJws(token)
			.getBody()
			.get(tokenField.getValue(), type);
	}
}
```

### WebHelper

WebHelper를 통해 ip주소를 가져오는 메서드를 만듭니다.

```java
public class WebHelper {
	public static String getIpAddress(HttpServletRequest request) {
		String ip = request.getHeader("X-Forwarded-For");

		if(ip == null || ip.length() == 0) ip = request.getHeader("Proxy-Client-IP");
		if(ip == null || ip.length() == 0) ip = request.getHeader("WL-Proxy-Client-IP");
		if(ip == null || ip.length() == 0) ip = request.getHeader("HTTP_CLIENT_IP");
		if(ip == null || ip.length() == 0) ip = request.getHeader("HTTP_X_FORWARDED_FOR");
		if(ip == null || ip.length() == 0) ip = request.getRemoteAddr();

 return ip;
	}
}
```

## 마치면서

token을 활용한 인증 방법에는 고민할 거리가 정말 많았습니다. 
access token이나 refresh token의 저장 위치부터, 그리고 front-end에서 새로고침할 경우에 새로이 발급받으면서도 만료시에는 사용자가 눈치채지 않게 하면서 구현하는 방법까지. 
구현 방법도 다양했으나 UX적으로 편리할 수록 보안은 조금씩 약해질 수 밖에 없었고, 반대로 완전한 보안또한 존재하지는 않았습니다. 
하지만 보안에 대해 계속해서 고민하고 고쳐가면서 더욱 발전하는거라 생각합니다.

JWT를 활용하여 refresh token을 구현하고 보안을 강화합니다.

JWT Refresh Token 구현

[지난 포스트](/post/back-end/api-gateway-zuul-filter)에서는 Netflix Zuul의 ZuulFilter를 활용해 토큰을 검증하는 과정까지 설명하였습니다. 
하지만 토큰을 검증하기 전에는 당연히 토큰을 발급하는 과정이 필요한데, 이번 포스트에선 그 과정에 대해 다루겠습니다.

## jjwt

Spring에서 JWT를 사용하기 위한 라이브러리 입니다. 
JWT에 대한 사전 지식이 부족할 경우 [JWT 포스트](/post/front-end/jwt)를 참조해주세요.

```groovy
dependencies {
	implementation 'io.jsonwebtoken:jjwt:0.9.0'
}
```

사용하기 위해선 gradle이나 maven에 의존성을 추가해야 합니다. 
jjwt를 활용해서 JWT를 생성하거나 혹은 분석할 수 있습니다.

## 로그인 구현

### controller

로그인 컨트롤러를 구현합니다. 
화면단에서 넘어오는 requestBody와 추후에 refresh-token 파트에서 사용할 HttpServletRequest를 받아와줍니다.

```java
@RestController
@RequiredArgsConstructor
public class SignController {
	private final SignService signService;

	@PostMapping("/auth/sign/in")
	public ResponseEntity<SignInResponse> signIn(HttpServletRequest request, @RequestBody SignInRequest requestBody) {
		return ResponseEntity.ok(signService.signIn(request, requestBody));
	}
}
```
### requestDto

requestDto에는 로그인시에 입력하는 아이디와 비밀번호가 포함되어 있습니다.

```java
@Getter
@AllArgsConstructor
public class SignInRequest {
	private String id;

	private String password;
}
```

### responseDto

responseDto에는 프론트엔드로 보내줄 token값과, 상태관리에서 사용할 멤버 이름이나 아이디, 권한 등을 보내줄 수 있습니다. 
해당 데이터들은 Redux와 같은 상태 관리를 통해 클라이언트에서 사용이 가능합니다.

```java
@NoArgsConstructor
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class SignInResponse {
	private String memberName;

	private String token;
}
```

### Service

서비스에서는 [decrypt과정](/post/front-end/aes)을 통해 암호를 해독하여 일치하는지 확인합니다. 
그 후 access token을 만들어 보내줍니다. 

```java
@Service
@RequiredArgsConstructor
public class SignService {

	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());
	private static final String AUTH_TOKEN_HEADER_PREFIX = "Bearer ";

	private final BCryptPasswordEncoder passwordEncoder;
	private final JwtUtil jwtUtil;
	private final UserRepository userRepository;

	@Transactional
	public SignResponse signIn(HttpServletRequest request, SignInRequest requestBody) {
		User loginUser = userDao
			.findById(requestBody.getId())
			.filter(user -> passwordEncoder.matches(AesCryptUtil.decrypt(requestBody.getPassword()), user.getPassword()))
			.updateLoginTime();

		String accessToken = jwtUtil.createAccessToken();

		logger.info("{} login success", requestBody.getId());

		return SignInResponse.builder()
			.memberName(loginUser.getMemberName())
			.token(accessToken).build();
	}
}
```

### JwtUtil

JWT를 생성할 때는 어플리케이션의 성격에 맞게 claim값들을 설정할 수 있습니다. 
등록된 클레임(Registered Claim)은 Jwts객체에 setter가 존재하여 이를 통해 설정할 수 있습니다. 
만료 시간(Expiration Time) 클레임은 설정해주어서 만료 시간이 지날 경우 토큰이 폐기되도록 하는 것이 좋습니다. 
jwtUtil에서는 이들을 통해 access-token을 생성해줍니다. 
HashMap을 이용해 body claim을 넣어줄 수 있습니다.

```java
@Component
public class JwtUtil {

	@Value("${jwt.signKey}")
	private String jwtSignKey;

	public String createAccessToken() {
		Map<String, Object> body = new HashMap<>();
		body.put(PublicClaimKey.NAME.getValue(), user.getName());
		body.put(PrivateClaimKey.USER_ID.getValue(), user.getId());

		return this.createToken("accessToken", body, 30);
	}

	public String createToken(String subject, Map<String, Object> body, int expirationTime) {
		LocalDateTime currentTime = LocalDateTime.now();

		Claims claims = Jwts.claims(body);

		return Jwts.builder()
			.setClaims(claims)
			.setSubject(subject)
			.setIssuer("https://oms-tech-blog.netlify.app")
			.setIssuedAt(Date.from(currentTime.atZone(ZoneId.systemDefault()).toInstant()))
			.setExpiration(Date.from(currentTime.plusMinutes(expirationTime).atZone(ZoneId.systemDefault()).toInstant()))
			.signWith(SignatureAlgorithm.HS512, jwtSignKey)
			.compact();
	}
}
```

### enum

공캐 클레임(Public Claim)이나 비공개 클레임(Private Claim)들은 enum등을 활용해서 구현 할 수 있습니다. 
TokenField interface를 이용하면 Claim을 parse하거나 set해줄 때 TokenField 타입을 활용할 수 있습니다.

```java
public interface TokenField {
	String getValue();
}
```

```java
public enum PublicClaimKey implements TokenField {
	NAME("name"),
	NICKNAME("nickname");

	private String value;

	PublicClaimKey(String value) {
		this.value = value;
	}

	public String getValue() {
		return value;
	}
}
```

```java
public enum PrivateClaimKey implements TokenField {
	USER_ID("userId");

	private String value;

	PrivateClaimKey(String value) {
		this.value = value;
	}

	public String getValue() {
		return value;
	}
}
```

원래 refresh token 발급 까지 설명하고 구현하려 하였으나 생각보다 양이 많아져서 한번 더 나누게 되었습니다. 
[다음 포스터](/post/back-end/refresh-token)에서는 access token의 한계점과 refresh token에 대해서 설명하고 구현하도록 하겠습니다.

JWT를 활용해서 access token을 발급하여 로그인을 하는 기능을 구현합니다.

JWT 로그인 방식 구현

[지난번 포스트 API Gateway](/post/back-end/api-gateway)에 이어 활용하는 내용입니다. 
Netflix Zuul을 API Gateway로 사용하면서 ZuulFilter를 활용하여 JWT인증을 구현합니다. 
Gateway에 인증을 구현함으로서, 각 서비스는 자신의 역할에만 집중하여 로직을 구현할 수 있고, 공통된 인증 시스템을 구현할 수 있습니다.

## Filter 작성

```java
@Configuration
public class JwtFilter extends ZuulFilter {
	
	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());

	@Override
	public String filterType() {
		return FilterConstants.PRE_TYPE; // "pre"를 return합니다.
	}

	@Override
	public int filterOrder() {
		return 0;
	}

	@Override
	public boolean shouldFilter() {
		return true;
	}

	@Override
	public Object run() {
		return null;
	}
}
```

**shouldFilter**와 **run**부분은 아래에서 작성하고, 
filterType은 API 서버로 라우팅 되기 전에 인증을 수행하고 그에 따라서 라우팅을 취소하거나 해야하니 **pre**로 해줍니다. 
filterOrder는 0으로 가장 먼저 등록되게 하겠습니다.

## shouldFilter

shouldFilter부분은 인증을 수행할지 말지를 결정해야 합니다. 
대부분의 로직은 인증을 수행해야 하지만 회원가입, 로그인 아이디 찾기 등 토큰을 발급받기 전에 수행해야할 로직들은 인증을 하면 안됩니다. 
또한 HTTP Method의 OPTIONS는 통신 옵션만 요청하여 가능 여부만 검사하니 이 또한 인증을 하지 않습니다.

```java
@Override
public boolean shouldFilter() {
	RequestContext context = RequestContext.getCurrentContext();

	if ("OPTIONS".equals(context.getRequest().getMethod())) {
		return false; // OPTIONS는 인증을 하지 않습니다.
	}

	List<String> whiteList = getWhiteList();
	// HttpServletRequest의 getRequestURI는 쿼리 param을 제외한 컨텍스트 경로부터 가져옵니다.
	if (whiteList.contains(context.getRequest().getRequestURI())) {
		return false;
	}

	return true; 
}

private List<String> getWhiteList() {
	return List.of("/auth/sign", "/auth/user/id");
}
```

**getWhiteList** 메서드를 이용해서 인증을 거치지 않을 URI들을 가져옵니다. 
해당 기능은 DataBase 구조에 따라서 Service를 거쳐서 DB로 부터 가져와도 되고, 
혹은 Enum을 활용하거나 혹은 위의 예시처럼 직접 String을 넣어도 됩니다. 
Http Method까지 포함하여 객체를 만들어 비교하는 방법도 가능합니다. 
여기선 테스트 코드로 직접 String을 넣었습니다.

## run

이 부분에선 실제 인증 과정을 작성해줍니다. 
API 요청으로부터 JWT 토큰을 가져오고 해당 토큰을 parse해서 문제가 있는지 확인합니다.

```java
@Configuration
public class JwtFilter extends ZuulFilter {
	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());

	// Value 어노테이션은 properties나 yml파일로부터 설정값을 가져옵니다. cloud config server를 만들어 값을 숨길 수 있습니다.
	@Value("${jwt.signKey}")
	private String jwtSignKey;
	......
}
```

field부분에 JWT의 signKey를 가져오는 코드를 추가합니다.

```java
@Override
public Object run() throws ZuulException {
	try {
		RequestContext requestContext = RequestContext.getCurrentContext();
		String jwt = requestContext.getRequest().getHeader("Authorization")
			.substring(7); // "Bearer "의 크기만큼 제거
	
		Claims claims = Jwts.parser().setSigningKey(jwtSignKey).parseClaimsJws(jwt).getBody();
	} catch (ExpiredJwtException ex) {
		// 토큰의 기간이 지난 경우입니다. Refresh 토큰을 활용할 경우 여기서 처리할 수 있습니다.
		this.requestRefreshToken();
	} catch (UnsupportedJwtException | MalformedJwtException | SignatureException ex) {
		// jwt의 구조가 잘못되거나, 서명에 실패할 경우입니다. 
		logger.warn("Bad Request" + ex.getMessage());
		throw new ZuulException("Bad token", HttpStatus.BAD_REQUEST.value(), ex.getMessage());
	} catch (Exception ex) {
		logger.warn("Something wrong in gateway" + ex.getMessage());
		throw new ZuulException("Something wrong in gateway", HttpStatus.INTERNAL_SERVER_ERROR.value(), ex.getMessage());
	}
	return null;
}

private void requestRefreshToken() {
	// auth 서비스로 URI를 변경하여서 refresh 토큰을 얻는 시도를 하도록 변경합니다.
	RequestContext context = RequestContext.getCurentContext();
	context.getRequest().setAttribute(WebUtils.INCLUDE_REQUEST_URI_ATTRIBUTE, "/auth/refresh");
}
```

토큰에 대해 인증을 수행하고 expired 될 경우에는 refresh 토큰을 얻을 수 있는지 auth 서비스에 요청합니다. 
그 이외의 인증에 실패할 경우에는 Exception을 일으켜서 요청을 취소하고 로그를 남깁니다. 
다음 포스트에는 auth 서비스에서 로그인을 통해 토큰을 발급받고, 또한 refresh 토큰을 발급받는 과정을 설명하겠습니다.

Netflix Zuul의 ZuulFilter를 이용하여 JWT 인증 구현합니다.

Netflix Zuul을 활용하여 JWT 인증 구현

처음에 MSA프로젝트에 투입되었을 때 Front-end에서는 Request Header를 넣어주는 코드가 없었는데, 
로컬 환경이 아닌 개발 환경에서만 Request Header가 들어가서 당황했었던 적이 있었습니다. 
API Gateway는 각각의 요청을 일괄처리 해주는 Gateway(관문) 역할을 하면서 다양한 역할을 수행할 수 있는 MSA에서 중요한 서비스입니다. 

## 특징

-	인증 및 권한 부여
-	서비스 검색 통합
-	응답 캐싱
-	정책, 회로차단기 및 QoS 다시 시도
-	속도 제한
-	부하 분산(load balance)
-	로깅, 추적, 상관 관계
-	헤더, 쿼리 문자열 및 청구 변환
-	IP 허용 목록에 추가

## Netflix Zuul

Spring Cloud의 Netflix Zuul은 Spring 2.4버전 이후부터는 더이상 지원하지 않습니다. 
현재 OMS에서는 Netflix Zuul을 Gateway로 사용중이며, 그 이후 버전의 프로젝트에서는 Spring Cloud Gateway를 적용해야 합니다.

## Setting

### Eureka

먼저 Gateway를 만드려면 Eureka Server에 등록을 해야 합니다. 
Gateway는 이를 통해 Eureka로부터 serviceId와 그곳의 EndPoint를 알게 되고,
적절하게 Load Balance를 할 수 있습니다.

```java
@SpringBootApplication
@EnableZuulProxy
@EnableEurekaClient
public class GatewayApplication {
	public static void main(String[] args) {
		SpringApplication.run(GatewayApplication.class, args);
	}
}
```

```yml
 ## bootstrap.yml
eureka:
	client:
		serviceUrl:
			defaultZone: http://localhost:8081/eureka/
		registerWithEureka: true
		fetchRegistry: true
```

### zuulRoutes

zuul Routes는 정해진 path 규칙에 따라서 알맞는 서비스 명으로 보내줄 수 있습니다.

```yml
 ## application.yml
zuul:
	ignored-services: '*'
	sensitive-headers:
	routes:
		auth-service:
			path: /auth/**
			serviceId: auth-service
			stripPrefix: false

		main-service
			path: /main/**
			service: main-service
			stripPrefix: false
```

-	ignored-services

	자동 생성에서 제외할 서비스들을 지정해줍니다.

-	sensitive-headers

	내부에서 사용되는 헤더값이 노출되는 것을 막아줍니다.

-	routes

	path에 맞는 조건의 API 요청들을 eureka에 등록된 serviceId로 zuul이 검색하여 알맞는 서비스에 API요청을 보내줍니다.

- stripPrefix

 false일 경우에는 API가 서비스로 넘어갈때 **앞의 내용들도 넘어갑니다. 
 반면에 true이면 넘어가지 않습니다.

## ZuulFilter

ZuulFilter는 Gateway에서 서비스로 요청을 보내기 전, 거치게 되는 서비스입니다. 
이곳에서 Jwt토큰을 확인하는 로직 등을 넣을 수 있습니다.

```java
@Configuration
public class TestFilter extends ZuulFilter {
	@Override
	public String filterType() {
		return "pre";
	}

	@Override
	public int filterOrder() {
		return 0;
	}

	@Override
	public boolean shouldFilter() {
		return true;
	}

	@Override
	public Object run() {
		return null;
	}
}
```

-	filterType

	filterType은 필터의 타입, 적용 시점을 설정하는 메서드입니다. 
	총 4가지의 타입이 있습니다.

	1.	pre

		API 서버로 라우팅 되기 전에 수행하는 필터(인증, 로깅 등..)

	2.	routing

		요청에 대한 라우팅을 제어하기 위해 수행하는 필터(Ribbon)

	3.	post

		API 서버로 라우팅 된 후 수행하는 필터(HTTP Header 추가 및 데이터 수집)

	4.	error

		앞 단계 필터들에서 발생된 오류 수행 필터(Exception)

-	filterOrder

	filterOrder는 여러개의 filter를 사용할 때, filter의 등록 순서를 정해줍니다. 
	0부터 순서대로 Filter가 적용됩니다.

-	shouldFilter

	shouldFilter는 해당 필터를 적용시킬지 말지 결정해주는 메서드입니다.

	```java
	// RequestContext는 요청되는 API 정보를 담고 있는 객체 입니다.
	RequestContext context = RequestContext.getCurrentContext();

	String url = context.getRequest().getRequestURI();
	if(whiteList.contains(url)) return false;
	return true;
	```

	위의 예시처럼 whiteList의 값이 들어올 경우 filter를 미적용 시키는 방법으로 사용할 수 있습니다.

-	run

	실제 동작을 하는 부분입니다. 
	어떠한 인증을 하거나 혹은 request에 새로운 값을 추가해줄 수 도 있고, Exception을 일으켜서 예외처리 등에도 사용할 수 있습니다.

Netflix Zuul을 이용한 API Gateway의 역할과 구성 방법

Netflix Zuul(API Gateway)

DI(Dependency Injection)는 의존성 주입으로, 하나의 객체가 다른 객체의 의존성을 제공하는 기술입니다. 
클래스 레벨에서는 의존관계가 고정되지 않고 런타임 시에 관계를 동적으로 주입해주어서, 
유연성을 확보하고 결합도를 낮출 수 있게 해줍니다.

## 의존성 주입 방법

Spring에서 의존성을 주입하는 방법에는 3가지가 있습니다. 
결론부터 말하면 생성자 주입 방법을 사용하는 것이 좋습니다.

### 생성자 주입

```java
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;

	// Class내 생성자가 하나뿐이면 @Autowired 생략 가능
	@Autowired
	public ExampleController(ExampleService1 service1, ExampleService2 service2) {
		this.service1 = service1;
		this.service2 = service2;
	}
}
```

생성자 주입은 생성자 호출 시점에 1회 호출 되는 것이 보장되어서, 주입받은 객체가 변하지 않게 됩니다.

### 필드 주입

```java
@Controller
public class ExampleController {
	@Autowired
	private final ExampleService1 service1;
	@Autowired
	private final ExampleService2 service2;
}
```

필드 주입은 코드가 간결해지고 유지보수가 편해지는 장점이 있습니다. 
하지만 외부에서 접근이 불가능하다는 단점이 있습니다. 
또한 반드시 Spring과 같은 DI 프레임워크가 존재해야 하기 때문에 사용을 지양합니다.

### Setter 주입

```java
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;

	@Autowired
	public void setService1(ExampleService1 service1) {
		this.service1 = service1;
	}

	@Autowired(required = false)
	public void setService2(ExampleService2 service2) {
		this.service2 = service2;
	}
}
```

Setter 주입은 생성자 주입과 다르게 주입받는 객체가 변경될 가능성이 있는 경우에 사용합니다. 
@Autowired 어노테이션은 주입할 대상이 없는 경우에는 오류가 발생합니다. 
따라서 주입할 대상이 없어도 동작하도록 하려면 requried = false를 이용해 설정할 수 있습니다.

## Lombok 활용

생성자 주입은 필드 객체에 final 키워드를 사용할 수 있습니다. 
Lombok의 @RequiredArgsConstructor를 활용하면, 
final 변수를 위한 생성자를 대신 생성해줍니다. 
이를 활용하면 새로운 객체를 추가하거나 기존 객체를 삭제할 때 등등… 
유지보수가 간결해지며 코드 작성시에도 간편해집니다.

```java
// 변경 전
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;

	public ExampleController(ExampleService1 service1, ExampleService2 service2) {
		this.service1 = service1;
		this.service2 = service2;
	}
}

// 변경 후
@RequiredArgsConstructor
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;
}
```

변경 전과 변경 후의 코드가 동일한 생성자 주입을 하는 코드가 됩니다. 
코드 작성이 편해지면서 수정이 적어집니다.

Spring에서 DI(의존성 주입)을 하는 방법입니다.

의존성 주입(DI)

Lombok이란? 
Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java. Never write another getter or equals method again, with one annotation your class has a fully featured builder, automate your logging variables, and much more.
[공식문서로 부터](https://github.com/projectlombok/lombok) 
해석하여 요약하면 롬복은 에디터의 빌드툴에 자동으로 연결하여 자바를 향상시켜주는 라이브러리 입니다.

## 원리

위의 Lombok 설명을 보면 **편집기에 build tools를 자동으로 연결하여** 라는 말이 있습니다. 
Lombok은 실제로 컴파일러로 넘어갈 때 AST트리를 동적으로 수정하고 바이트 코드를 자동으로 작성해주는 역할을 합니다. 
결국 컴파일 시점 코드 생성이고, 컴파일러 플러그인이기 때문에, 지원하는 IDE에서만 사용할 수 있습니다.

## 사용해야 할까?

Lombok에 대해서는 많은 개발자들 사이에서 **사용해야 한다 vs 사용하면 안된다** 로 나뉩니다. 
결국에 Lombok은 개발을 편하게 하기 위해 사용하는 것이고, 컴파일러를 거치면 사용한 것과 사용하지 않은 것의 성능과 동작은 일치합니다. 
그래도 분명 사용했을때의 강점도 크기 때문에 실제로 많은 기업에서도 잘 사용하고 있습니다. 
개인적인 생각이지만 무조건 사용하지 말아야한다보단 잘 파악하고 사용한다면 큰 문제가 없을거라 생각합니다. 
따라서 이 문서에서는 Lombok에 대해 사용하면 안된다는 이유와 사용해야 한다는 이유를 분석하고, 이에 따라 사용하게 되면 어느 부분을 조심해야 할지에 대해 다루겠습니다.

## 사용해야 한다.

사용해야 한다 의견은 매우 단순합니다. 
Lombok을 잘 적용하면 코드량을 많이 줄여줍니다. 
그에 따라 개발하는 속도가 빨라지고, 또한 리펙토링이 쉬워지며, 코드를 분석하기가 매우 편해집니다.

```java
// Lombok 미적용
public class MemberDto {
	private String id;
	private String password;
	private String name;
	private int age;

	public MemberDto () {}

 public MemberDto (String id, String password, String name, int age) {
 this.id = id;
 this.password = password;
 this.name = name;
 this.age = age;
 }

 public String getId() {
 return id;
 }

 public void setId(String id) {
 this.id = id;
 }

 public String getPassword() {
 return password;
 }

 public void setPassword(String password) {
 this.password = password;
 }

 public String getName() {
 return name;
 }

 public void setName(String name) {
 this.name = name;
 }

 public int getAge() {
 return age;
 }

 public void setAge(int age) {
 this.age = age;
 }
}

public class MemberDtoBuilder {
	private String id;
	private String password;
	private String name;
	private int age;

	public MemberDtoBuilder () {}

	public MemberDtoBuilder id(String id) {
		this.id = id;
		return this;
	}

	public MemberDtoBuilder password(String password) {
		this.password = password;
		return this;
	}

 public MemberDtoBuilder name(String name) {
		this.name = name;
		return this;
	}

 public MemberDtoBuilder age(int age) {
		this.age = age;
		return this;
	}

	public Member build() {
		return new Member(id, password, name, age);
	}
}

// Lombok 적용
@Getter @Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class MemberDto {
	private String id;
	private String password;
	private String name;
	private int age;
}
```

빌드 패턴을 적용하였지만, 빌드패턴을 제외하더라도 코드량이 상당히 줄어들게 됩니다.

## 사용하면 안된다.

1.	컴파일러 단계에서 적용

컴파일러 단계에서 지원하다보니, 특정 IDE에 종속되게 됩니다. 
뿐만 아니라 관련된 플러그인이나 설정을 해야만 적용할 수 있습니다.

2.	지원 중단 시 리스크

	Lombok은 코드량을 많이 줄여줍니다. 
	하지만 그만큼 이미 적용한 프로젝트에서 Lombok 코드를 제거하기란 쉽지 않은데, 
	Lombok에 관련하여서 어떠한 이슈가 발생하거나 제거 해야 할 일이 생기면 그만큼 많은 수정을 필요로 하게 됩니다.

-	코드가 쉽게 변환

	```java
	// Member 클래스
	@AllArgsConstructor
	public class Member {
		private String id;
		private String name;
	}

	// 사용하는 곳
	Member member = new Member("id", "name");
	```

	위와 같은 코드가 있고 정상적으로 동작할 때, 만약 누군가가 아래와 같이 코드를 수정할 수 있습니다.

	```java
	// Member 클래스
	@AllArgsConstructor
	public class Member {
		private String name;
		private String id;
	}

	// 사용하는 곳
	Member member = new Member("id", "name");
	```

	단순히 위 아래 순서만 고쳤지만 실 사용되던 곳의 코드는 완전히 다르게 됩니다. 
	컴파일 에러를 발생하지 않으면서 코드가 쉽게 변환 될 가능성을 가지게 됩니다.

-	순환참조

	JPA Data의 Eintity에서 양방향 매핑을 할 때처럼, 서로가 서로를 참조하고 있을 때와 같이, 
	아무런 생각없이 @ToString 어노테이션을 사용한다면 Stack Over Flow가 발생합니다.

## 해결방안

이슈들로부터 비교적 안전하게 Lombok을 사용하기 위한 방안들입니다.

-	**@Data** 사용 금지

	**@Data* 어노테이션은 @RequiredArgsContructor + @Getter + @Setter + @ToString + @EquialsAndHashCode 입니다. 
	필요 없는 어노테이션까지 가져올 가능성이 많고, 클래스를 잘못 사용하게 될 가능성이 있습니다.

-	**@ToString**은 조심해서

	exclude 파라미터를 활용해서 특정 필드만 제외시킬 수 있습니다. 
	순환참조일 경우 해당 필드를 제외시키고, 조심해서 사용해야 합니다.

-	**@XXArgsConstructor**

	해당 어노테이션들은 위에서 언급하였듯, 코드가 쉽게 변할 수 있는 리스크를 가지게 됩니다.

	1.	**@Builder**와 함께 이용

		접근레벨을 access = PRIVATE로 낮추고 Builder 패턴을 사용하면 코드가 생성자에 종속적이지 않게 되어서, 안전한 코드 작성이 가능합니다.

	2.	사용하지 않음

		그냥 사용하지 않고 생성자를 직접 만들어주는 것도 하나의 방법입니다.

-	**EqualsAndHashCode**

	equals 메서드와 hashcode 메서드를 생성해주는 어노테이션 입니다. 
	하지만 무분별하게 사용하면, Set과 함께 사용할 경우에 이슈가 발생할 수 있습니다.

	```java
	// Member클래스
	@AllArgsConstructor
	@EqualsAndHashCode
	@Setter
	public class Member {
		private String id;
		private String name;
	}

	// Set 사용
	Set<Member> memberSet = new HashSet();
	Member member = new Member("id1","홍길동");
	memberSet.add(member);
	member.setName("개명");
	memberSet.add(member);
	```

	위의 코드 결과를 보면 분명 member객체는 하나뿐인데, Set은 이를 구별하지 못하게 되는 현상이 일어나게 됩니다. 
	따라서 Pk들과 같은 변할일이 없는 객체에만 사용하기를 권합니다.

	```java
	@Entity
	public class Member {
		@EmbededId
		private MemberId;
		......
	}

	@Embeddable
	@EqualsAndHashCode // Id Class는 불변 객체입니다.
	public class MemberId implements Serializable {
		......
	}
	```

Lombok에 대해 단점과, 장점 그리고 사용한다면 어떠한 방식으로 사용해야 할까에 대한 글입니다.

Lombok

[Representational State Transfer API](https://aws.amazon.com/ko/what-is/restful-api/)는 리소스를 이름으로 구분하여 해당 상태를 주고 받는것을 의미합니다. 
간단하게는 API의 URI를 만드는 규칙입니다.

## 사용 이유

1.	서버와 클라이언트의 구분

	백엔드랑 프론트엔드를 구분하여서 서로의 의존성을 떨어뜨립니다.

2.	무상태(Stateless)

	세션과 쿠키를 다루지 않으면서 서버는 요청만 단순 처리하게 되고, 서비스의 자유도가 높아집니다.

3.	캐시(Cacheable)

	HTTP 프로토콜의 캐싱 기능 적용 가능

4.	협업 규칙

	개발자들이 동일한 방식으로 API를 개발하여 서비스의 통일감을 주고, 
	코드 분석을 빠르게 합니다.

## REST 구성 요소

1.	자원(Resource): URI

2.	행위(Verb): HTTP Method

	HTTP 프로토콜의 [Method](#http-method)들을 사용합니다.

3.	표현(Representation of Resource)

	JSON, XML등 형태로 나타내어 지고, Spring에서는 ResponseEntity를 활용합니다.

## HTTP Method

메서드는 총 8가지가 있습니다.

1.	GET: 서버로 부터 데이터를 취득

2.	POST: 서버에 데이터를 추가, 작성 등

3.	PUT: 서버의 데이터를 갱신, 작성 등

4.	PATCH: 리소스의 일부분을 수정

5.	DELETE: 서버의 데이터를 삭제

6.	HEAD: 서버 리소스의 헤더(메타 데이터의 취득)

7.	OPTIONS: 리소스가 지원하고 있는 메소드의 취득

8.	CONNECT: 프록시 동작의 터널 접속을 변경

## Response Status (상태 코드)

HTTP STATUS CODE 라고 불리고, Response에 상태코드가 담겨서 클라이언트에게 응답합니다. 

-	2XX(성공)

	-	200 OK

		요청이 성공했음을 의미합니다. 
		**ResponseEntity.ok(dto);**

	-	201 Created

		POST나 PUT요청 이후에 리소스가 생성되었음을 나타냅니다. 
		**ResponseEntity.created(URI.create("/")).build();**

	-	204 No Content

		요청에 대해 보낼 컨텐츠가 없을 때 사용합니다. 
		**ResponseEntity.noContent().build();**

-	4XX(클라이언트 오류)

	-	400 Bad Request

		잘못된 문법으로 서버가 요청을 이해하지 못할 경우입니다.

	-	401 Unauthorized

		요청이 인증받지 못했음을 나타냅니다.

	*	403 Forbidden

		요청에 권한이 없을 때를 나타냅니다.

	-	404 Not Found

		일반적으론 알려지지 않은 URL을 나타냅니다. 
		때에 따라선 결과 리소스가 없을 경우에도 404를 사용합니다. 
		**ResponseEntity.notFound().build();**

-	5XX(서버 오류)

	-	500 Internal Server Error

		서버에 에러가 나타났음을 알립니다.

	-	502 Bad Gateway

		서버가 게이트웨이로부터 잘못된 응답을 수신했음을 나타냅니다.

	-	504 Gateway Timeout

		서버가 게이트웨이 역할을 수행하는 동안 요청을 마치기 위한 응답을 수신하지 못할 경우입니다.

## 설계 규칙

1.	동사 대신 명사를 사용합니다.

	**@GetMapping("/getMember")** X → **@GetMapping("/member/[id]")**

2.	자원에 대한 행위는 HTTP method를 이용합니다.

	**@GetMapping("/books")** → 책 목록을 가져온다. 
	**@GetMapping("/books/[id]")** → 특정 책의 정보를 가져온다. 
	**@PostMapping("/books/[id]")** → 새로운 책을 등록합니다. 
	**@PatchMapping("/books/[id]")** → 특정 책을 삭제한다.

3.	URI 경로에는 소문자가 적합합니다.

4.	슬래시 구분자(/)는 계층 관계를 나타냅니다.

	**/houses/apartments**

5.	URI마지막 문자로 슬래시(/)를 넣지 않습니다.

6.	밑줄(￦_), camelCase 대신 하이폰(-)을 사용하여 가독성을 높여줍니다.

	**/bookAndVideo, /book-and-video** X → **/book-and-video**

## 추가 자료

-	GET vs OTHER

	GET 방식은 다른 메서드들과 차이점을 가지고 있습니다.

	1.	캐싱

		GET 방식은 캐싱을 하기 때문에 반복된 요청에 더 빠릅니다.

	2.	파라미터
		
		파라미터 내용이 노출되기 때문에 사용자들이 이를 볼 수 있습니다.

	3.	길이 제한

		GET 방식의 파라미터는 데이터 길이에 대한 제한이 있습니다. 제한되는 정도는 브라우저마다 다릅니다.

-	idempotent(멱등성)

	여러번 API가 수행되더라도 같은 결과가 나와야 한다는 말입니다. 
	GET, PUT, DELETE가 이에 속합니다.

-	PUT vs PATCH

POST, PUT 그리고 PATCH의 차이점은 일종의 규약이기 때문에 반드시 지킬 필요는 없습니다. 
그래도 규약을 지킨다면 메서드가 어떤 역할을 하는지가 분명해져서 코드를 이해하기 더 편해집니다. 

1.	PUT

	데이터가 없다면 새로운 데이터를 생성하거나, 있다면 그 위에 덮어씌우는 역할을 합니다. 
	새로운 데이터를 생선한 경우에는 201(Created), 기존 데이터를 덮어쓴 경우는 200(OK) 혹은 204(No Content)로 응답해야 합니다. 
	즉 PUT은 자원의 모든 상태를 알고 있는 상태(Request에 모든 데이터)여야만 합니다.

```java
	// controller
	@PutMapping("/member/{id}")
	public ResponseEntity<Void> updateMember(
		@RequestBody MemberRequest request,
		@PathVariable String id
	){
		if(memberService.updateMember(request, id)){
			return ResponseEntity.ok().build();
		}
		return ResponseEntity.created(URI.create("/member/id/")).build();
	}

	// service
	@Transactional
	public boolean updateMember(MemberRequest request, String id) {
		boolean isMember = memberRepository.findById(id).isPresent();
		Member member = request.toEntity();
		memberRepository.save(member);

		return isMember;
	}
```

2.	PATCH는 PUT과 달리 Entity를 찾아오고, 그 데이터의 일부를 수정하는 역할을 합니다.

```java
	// controller
	@PatchMapping("/member/{id}")
	public ResponseEntity<Void> updateNickNameMember(
		@RequestParam String nickName,
		@PathVariable String id
 ) {
	 service.updateNickNameMember(nickName,id);
	 return ResponseEntity.ok().build();
 }

	// service
	@Transactional
	public void updateNickNameMember(String nickname, String id) {
		Member member = memberRepository.findById(id)
			.orElseThrow(NoSuchElementException::new);

		member.changeNickName(nickName);
	}

	// entity
	@Entity
	public class Member {
		@Id
		@Column
		private String id;

		@Column
		private String nickName;

		public void changeNickName(String nickName) {
			this.nickName = nickName;
		}
	}
```

## 목적

RESTful의 목적은 이해하기 쉽고 사용하기 쉬운 Application을 만드는데 있습니다. 
성능향상을 위한것이 아닌, 일종의 규칙을 만드는 것으로 
각 서비스에 맞게 적용하면 됩니다.

RESTful API

지난 포스트에서는 Eureka Server로 동작할 Service Discovery를 만들었습니다. 
[ServiceDiscovery 포스트](/post/back-end/service-discovery) 
Eureka Server에 각 Service들을 Client로 등록해서 Server가 파악할 수 있게 해야합니다.

## 등록방법

Eureka Server에 각 Service들을 Client로 등록해서 Server가 파악할 수 있게 해야합니다.

### Dependencies

```groovy
// build.gradle
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}
```

### Annotation

Service Client로 등록하는 어노테이션은 총 2개가 있습니다. 

-	@EnableDiscoveryClient

	이 어노테이션은 Eureka뿐 아니라 consul, zookeeper들이 같이 속해있습니다. 
	해당 기능들도 같이 구현하여 사용하고 싶을 때 이 어노테이션을 사용합니다.

-	@EnableEurekaClient

	이 어노테이션은 오로지 Eureka Client로 등록해주기만 합니다.

두 어노테이션중 하나를 선택하여서, 메인클래스에 붙이면 됩니다.

```java
@SpringBootApplication
@EnableEurekaClient
public class TestApplication {
	public static void main(String[] args) {
		SpringApplication.run(TestApplication.class, args);
	}
}
```

### 설정 파일 추가

```yml
eureka:
	client:
		serviceUrl:
			defaultZone: http://www.exam.com:8085/eureka/
		registerWithEureka: true
		fetchRegistry: true
```

Eureka Server의 URL을 eureka.client.serviceUrl.defaultZone 설정값에 넣어줘야 합니다. 
그리곤 Eureka Server 서비스와는 반대로, Client임을 알리기 위해 
eureka.client.registerWithEureka, 
eureka.client.fetchRegistry 이 두개의 값을 true로 설정합니다.

```yml
spring:
	application:
		name: client-name
```

spring.application.name의 이름으로 Eureka Server에 등록됩니다.

## Eureka 등록의 원리 (HTTP Method로 등록 및 삭제)

Eureka Server는 HTTP Method를 받아서 등록, 갱신, 및 삭제를 진행합니다.

-	등록

	appID로 Client에 등록합니다. 
	**POST /eureka/apps/[appID]**

-	갱신

	appID의 instanceID 갱신을 받습니다. 
	**PUT /eureka/apps/[appID]/[instanceID]**

-	삭제

	appID의 instanceID를 삭제합니다. 
	**DELETE /eureka/apps/[appID]/[instanceID]**

위의 등록 방법에서 어노테이션을 적용하면 위 3가지 작업을 자동으로 진행합니다. 
갱신 요청이 일정 시간동안 없다면 해당 서비스를 죽은것으로 간주합니다.

Spring Cloud MSA 환경에서 Service들을 등록하는 방법에 대한 글입니다.

Eureka Server(ServiceClient)

Service Discovery란 외부에서 마이크로 서비스들을 검색하기 위한 기능을 지원해줍니다. 
ket, value 값으로 각 서비스가 어디에 존재하는지 저장하고, 검색을 해줍니다.

## Netflix Eureka

Eureka는 Gateway로 부터 요청정보를 받게되면 알맞는 서비스에 요청을 보내주는 역할을 합니다. 
뿐만 아니라 Load Balancer를 지원해주거나 서비스 인스턴스 상태를 확인할 수 있습니다.

## 적용법

Spring Boot 프로젝트에서는 아래 방법대로 적용할 수 있습니다.

### dependencies

gradle 혹은 maven에서 netflix-eureka-server를 추가해줍니다. 
gradle 기준으로는 아래와 같습니다.

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

### @EnableEurekaServer

SpringBoot의 메인 메서드가 존재하는 서비스 어플리케이션에 어노테이션을 추가해줍니다.

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

}
```

### 설정 파일 추가

```yml
spring:
	application:
		name: cloud-discovery

eureka:
	client:
		register-with-eureka: false
		fetch-registry: false
```

spring.application.name 속성은 서비스의 이름 (Key값)을 지정해줍니다. 
eureka.client.register-with-eureka속성은 eureka 서버에 등록 여부를 결정해주는데, 
Discovery 서비스는 해당 서비스 자체가 eureka 서버가 되야하기 때문에 false로 해줍니다.

## 적용 확인

![EurekaInstance size:800*400](/back-end/eurekaInstance.png)

-	Instances currently registered with Eureka

	현재 Eureka Server에 등록되어 있는 Service목록들을 확인 할 수 있습니다. 
	Application은 yml의 spring.application.name으로 설정한 Key 값이며, 
	Availability Zones는 가용성 영역으로 한 서비스 내의 인스턴스 갯수를 나타내줍니다. 
	Status는 UP은 서버가 문제없이 가동되는 것, DOWN은 서버가 가동되지 않음을 뜻합니다.

Spring Cloud MSA 환경에서 서비스들을 감독해주는 서비스에 대한 글입니다.

Eureka Client(Service Discovery)

## Monolithic vs MSA

Monolitihc이란 기존에 사용하던 방식으로, 
한 서비스 안에 모든 기능을 유기적으로 연결시켜 운영하는 방식입니다. 
MSA는 Monolithic방식과 다르게 서비스를 나누고 기능을 분리하여 하나의 어플리케이션으로 합쳐서 운영하는 방식입니다. 
MSA환경에서 실제 개발을 해보면서 느낀점은, 
MSA 환경이여서 얻는 이점도 많았지만, 
장점만 존재하진 않았고, 불편한 점들도 상당히 있었습니다. 
약간 주관적이겠지만 제가 생각하는 장단점입니다.

### 장점
-	유연한 서비스 관리

 각 서비스를 유연하게 배포할 수 있어서 실제 상황에서 소스를 롤백하거나, 또한 확장하기에 좋습니다.

-	책임 분리 및 장애 범위 축소

 서비스의 책임이 분리되어서, 대량 데이터 조회 서비스와 
 핵심 로직 서비스를 분리하는 방식으로 사용도 가능하여서, 
 장애가 일어나도 커다란 피해가 없을 수 있습니다.

-	편리한 관리도구

 elk 스택을 활용한 로그조회나, grafana를 통한 시각화 자료등이 각 서비스 마다 이루어져 있기에, 
 분석이나 해결방안을 도출하는데 많은 도움이 되었습니다.

-	편리한 기능개발

 신규 기능을 개발하기에 해당 서비스에 미치는 영향도를 고려하기 더 쉽고, 
 특정 서비스의 구성을 바꿀 수 있기에 다양한 시도를 하기 좋습니다.

### 단점

-	초기 서비스를 갖추는데 많은 시간과 인력이 필요합니다.

 서비스를 설계에 따라 나누고, gateway, discovery, 등등 필요로 하는 서비스뿐 아니라, 
 배포화 도구, 모니터링 도구 등… 
 그 구현 난이도 또한 어렵습니다.

-	특정 소스 테스트 및 디버깅 난이도 상승

 여러 서비스끼리 서로 api를 주고받는 경우, 
 어디 서비스에서 어떤 문제가 있는지 찾기 더 어려워질 수 있습니다. 
 또한 테스트하려면 여러 서비스를 동시에 돌려서 테스트 해야하는데 이것도 번거롭습니다.

-	난잡한 코드관리

 JPA를 사용하는데 컬럼이 추가된다거나 하는 경우 해당 Entity를 사용하는 모든 서비스를 찾아서 업데이트를 해줘야하고, 
 혹은 새로운 기준코드가 생겨도 enum을 사용할 경우 마찬가지로 해당 모든 서비스를 찾아서 코드를 업데이트 해줘야 합니다. 
 뿐만 아니라 개발자의 수가 많아지고 프로젝트가 커질수록 여러 서비스에 같은 로직이 구현되어 있을 가능성도 점점 커집니다.

적다보니 단점도 많이 적었지만, MSA는 얻는 이점도 크고 확실한 아키텍처라고 생각합니다. 
하지만 기술적으로나, 관리적으로 보았을 때 무조건적으로 MSA를 사용하는 것이 좋다 보단, 
서비스의 규모나 특징을 생각하고 선택하는 것이 더 좋다 생각합니다.

## MSA의 구조

MSA에 정해진 구조는 없지만, 이정도의 틀은 유효하다 생각합니다.

### API Gateway

Client에게 요청을 바든 지점입니다. 
Service Router를 통해 API요청을 각 서비스에 보내주고, 
간단한 보안, 인증을 수행합니다.

### Service Mesh

Service Mesh란 Micro Service내의 내부 통신을 의미합니다.
-	Service Discovery (Eureke)

 Service들을 등록하고, 각 Service들의 위치(IP주소,Port번호), 
 인스턴스 갯수 및 상황등을 파악하여 주는 서비스입니다.

-	Load Balancer (Ribbon)

 서비스가 분산된 형태로 존재할 때 알맞는 Instance에 요청을 보내주도록 도와줍니다.

-	Config Store

 공통된 설정파일(DB 정보나, Network 설정 등..)을 저장해두고 필요로 하는 서비스에게 보내줍니다.

-	Circuit Breaker

 원격 접속의 실패율이 임계치를 넘을 경우, 
 접속을 차단해주는 시스템입니다.

### Telemetry

전체 서비스의 모니터링과 진단 기능을 가집니다. 
elastic Search같은 도구들을 이용합니다.

MSA란 무엇인지, 기존 프로젝트와 어떠한 차이가 있는지에 대한 글입니다.