벌써 최종 프로젝트가 눈 앞까지 왔다. 아직도 배워야 할 것이 많은데 벌써 최종 프로젝트라니.. 걱정이 조금 앞선다. 심지어 과제를 끝내고 난 뒤부터는 프로젝트만큼 열심히 하지 않는 것 같다. 마음만 급해지는게 아닌가 싶다.

개인 과제를 진행하면서 확실히 query 작성을 잘 못한다는 것을 깨닫게 되었다. 아무래도 팀 프로젝트마다 항상 유저 관련 도메인을 맡아서 하다보니 상대적으로 복잡한 쿼리를 만들 일이 없어서 그런 것 같다. 지금이라도 알아차렸으니 알고리즘 문제 풀이를 하면서 틈틈히 sql 문제도 풀어야 겠다고 느꼈다.

특히 기술도 기술이지만 기술을 원활하게 배우고 적절하게 사용하기 위해선 기반이 잘 되어 있어야 한다고 생각한다.. 지금까지 기술을 사용하기 위해서 열심히 달렸으니 프로젝트 이후부턴 비어있는 기본 지식들을 채워 넣는 것에 집중해야할 것 같다.

트러블 슈팅

코드 개선 퀴즈 - JPA 이해

JPQL을 사용해서 동적 쿼리를 만드는 문제였다. 생각보다 이 문제를 푸는 데 시간이 오래 걸렸다. 특히 LocalDate를 LocalDateTime으로 만드는 것과 JQPL 자체 로직 문제로 인해 대부분의 시간이 걸렸다.

결국 다음과 같이 해결했다.

LocalDate -> LocalDateTime으로 변환

LocalDateTime startDateTime = startDate != null ? startDate.atStartOfDay() : null;
LocalDateTime endDateTime = endDate != null ? endDate.atTime(23, 59, 59) : null;

request에서 빈 값이 들어오면 null로 보내고, 아니라면 해당 날짜의 시작과 끝으로 설정해서 보낸 뒤에 처리하게 했다.

JPQL 문제

여긴 그냥 JPQL 자체를 잘못 작성해서 발생했다. 특히 괄호를 적절하게 사용하지 못해서 예외가 발생한 적도 있고, 값이 존재하는지 존재하지 않는지에 대해서 확인하는 로직은 null일 경우가 더 먼저(=왼쪽)있어야 한다는 것도 알게 되었다.

Spring Security 적용 후 테스트 코드 실패

시큐리티를 적용한 뒤에 같은 문제가 반복해서 발생했었다. 의존 주입에 대한 문제였고, @Value를 적은 곳에서 동시에 발생했다.

@Import 사용

테스트 클래스에 @Import({PropertyConfig.class, JwtUtil.class, JwtAuthenticationFilter.class})를 추가해줬다.

여담으로 JwtAuthenticationFilter.class는 없어도 잘 돌아갔다..

test 안의 resources 제거

Import를 적용했는데도 같은 이유로 실패해서 또 삽질을 했다. @Import에 클래스를 넣었다가 뺐다가...

@Import를 했는데도 같은 예외가 발생했었다. 결국 test 안에 만들어 둔 resources 폴더를 전부 삭제했었다.

의외로 그랬더니 성공했다.

아마 Config 주입에서 충돌이 일어난 것이 아닐까..

QueryDSL 설정 문제

// querydsl
implementation 'com.querydsl:querydsl-jpa:5.0.0'

querydsl 내부 클래스들을 읽어오지 못했다. jakarta로 되어있던 것까지 확인했는데도 문제가 생겨서 검색을 해보니 위의 의존성 주입이 잘못되어 있던 것이었다.

// querydsl
implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'

뒤에 버전을 명시하는 것처럼 jakarta를 붙여줬더니 해결됐다.

대용량 데이터 처리

배치를 돌려서 값을 넣고 for 문으로 뒤에 현재 i 값을 뒤에 붙여서 닉네임과 이메일등을 만들도록 하면 된다는 것까진 알고 있었지만 막상 구현하려니 손이 움직이질 않아서 검색을 했다. 값을 넣는 방법은 많았지만 내가 원하는 답이 없어서 배치 설정을 하고 for 문을 돌려서 값을 넣었다.

하지만 1시간이 지나도 완료가 안돼서 확인해보니 로직이 꼬여서 백만 건 * 백만 건 그 이상이 발생하게 된 것이었다!

로직 정상화 이후 9분 32초만에 끝나게 되었다.

여담으로 인덱싱만 했는데도 300ms에서 12ms로 줄어든 것을 보고 인덱싱에 대한 중요성을 느꼈다.

References

깃허브 내 issue에 references를 최대한 작성했습니다.

• https://github.com/dereck-jun/spring-plus/issues

김영한님의 JPA 강의를 듣고 정리한 내용입니다.

값 타입

JPA의 데이터 타입 분류

엔티티 타입

• @Entity로 정의하는 객체
• 데이터가 변해도 식별자로 지속해서 추적 가능
  • ex) 회원 엔티티의 필드 값을 변경해도 식별자로 인식할 수 있다.

값 타입

• int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
• 식별자가 없고 값만 있으므로 변경 시 추적 불가
  • ex) int num = 10; -> num = 20 처럼 값을 변경하면 완전히 다른 값으로 대체됨

값 타입 분류

• 기본 값 타입
  • 자바 기본 타입(int, double)
  • 래퍼 클래스(Integer, Long)
  • String
• 임베디드 타입(embedded type, 복합 값 타입)
• 컬렉션 값 타입(collection value type)

기본 값 타입

• 생명 주기를 엔티티에 의존한다
  • ex) 회원을 삭제하면 안에 있는 필드도 함께 삭제
• 값 타입은 공유하면 안됨
  • ex) 회원 이름 변경 시 다른 회원의 이름도 함께 변경되면 안됨 (나쁜 의미로서의 사이드 이펙트)

자바의 기본 타입은 절대 공유되지 않는다.

• 기본 타입은 절대 공유되지 않는다.
• 기본 타입은 항상 값을 복사한다. (참조 X)
• 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체지만 변경은 안된다 (값을 변경할 방법이 없음)

임베디드 타입

임베디드 타입은 엔티티의 값이다. 따라서 크게 의미를 가질 필요가 없다.

임베디드 타입 사용 전과 후에 매핑하는 테이블은 같다.

객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다.

잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

특징

• 새로운 값 타입을 직접 정의할 수 있음
• JPA는 임베디드 타입이라 한다.
• 주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
• int, String과 같은 값 타입이다.
• 임베디드 타입의 값이 null이면 매핑한 컬럼의 값은 모두 null이다.

장점

• 재사용이 가능하다
• 클래스 내에서 응집도가 높다
• 해당 값 타입만 사용하는 의미 있는 메서드를 만들 수 있다
• 임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티티에 생명 주기에 의존한다

사용법

• @Embeddable: 값 타입을 정의하는 곳에 표시
• @Embedded: 값 타입을 사용하는 곳에 표시
• 기본 생성자 필수

임베디드 타입과 연관관계

엔티티는 임베디드 타입의 값을 가질 수 있고, 임베디드 타입의 값은 임베디드 타입의 값이나 엔티티를 가질 수 있다.

ENTITY -> VALUE -> VALUE   // 엔티티 -> 임베디드 -> 임베디드
ENTITY -> VALUE -> ENTITY  // 엔티티 -> 임베디드 -> 엔티티 

@Column을 사용해서 이름 변경 등도 가능

@AttributeOverride: 속성 재정의

한 엔티티에서 같은 값 타입을 사용하게 되면 컬럼명이 중복되는 문제가 생긴다.

이때 사용할 수 있는 어노테이션이 @AttributeOverrides, @AttributeOverride이다.

아래는 Address 클래스를 동시에 사용하고 있을 때 @AttributeOverrides로 속성 재정의를 하는 방법이다.

@Entity
class Member {
    ...
    @Embedded
    private Address homeAddress;

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name = "city", column = @Column(name = "WORK_CITY")),
        @AttributeOverride(name = "street", column = @Column(name = "WORK_STREET")),
        @AttributeOverride(name = "zipcode", column = @Column(name = "WORK_ZIPCODE"))
    })
    private Address workAddress;
}

값 타입 컬렉션

• 값 타입을 하나 이상 저장할 때 사용한다.
  • 셀렉트 박스처럼 단순하고, 추적할 필요도 없고, 값이 바뀌어도 update 할 필요가 없을 때 사용한다.
• @ElementCollection, @CollectionTable 어노테이션을 사용해서 매핑하면 된다.
• 데이터베이스 컬렉션을 같은 테이블에 저장할 수 없다.
  • 컬렉션의 경우 일대다 개념이기 때문에 DB 안에 한 테이블로 컬렉션을 넣을 수 있는 방법이 없다.
  • 따라서 별도의 테이블로 풀어내야 함
  • 즉, 컬렉션을 저장하기 위한 별도의 테이블이 필요하다는 뜻임
• 값 타입 컬렉션도 지연 로딩 전략을 사용한다.

값 타입 컬렉션은 영속성 전이(CASCADE) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

매핑 방법

@Entity
class Member {
    ...

    @ElementCollection  
    @CollectionTable(name = "FAVORITE_FOOD", joinColumns = 
        @JoinColumn(name = "MEMBER_ID")
    )  
    @Column(name = "FOOD_NAME")  
    private Set<String> favoriteFoods = new HashSet<>();  

    @ElementCollection  
    @CollectionTable(name = "ADDRESS", joinColumns = @JoinColumn(name = "MEMBER_ID"))  
    private List<Address> addressHistory = new ArrayList<>();
}

@ElementCollection으로 컬렉션 값 타입이라는 것을 명시하고, @CollectionTable로 자동으로 생성할 컬렉션 테이블의 이름과 어떤 식별자와 조인해서 사용할 것인지를 넣어주면 된다.

이때 @Column을 사용해서 테이블에 들어갈 컬럼의 이름을 변경할 수 있다.

저장

Member member = new Member();
member.setName("member1");
member.setHomeAddress(new Address("homeCity", "homeStreet", "10001"));

member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("피자");
member.getFavoriteFoods().add("탕수육");

member.getAddressHistory().add(new Address("oldCity1", "st1", "10002"));
member.getAddressHistory().add(new Address("oldCity2", "st2", "10004"));

em.persist(member);

조회

저장 예제 코드에서 이어지는 부분이라고 생각하고 보자.

em.flush();
em.clear();

// 지연 로딩 전략으로 인해 Member만 조회됨
Member findMember = em.find(Member.class, member.getId());

// addressHistory 사용되는 시점에 로딩
List<Address> addressHistory = findMember.getAddressHistory();
for (Address address: addressHistory) {
    // 출력문
}

// favoriteFoods 사용되는 시점에 로딩
Set<String> favoriteFoods = findMember.getFavoriteFoods();
for (String favoriteFood : favoriteFoods) {
    // 출력문
}

수정

저장 예제 코드에서 이어지는 부분이라고 생각하고 보자.

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getId());

// homeCity -> newCity
// findMember.getHomeAddress().setCity("newCity"); <- 사이드 이펙트로 큰일날 수 있음
findMember.setHomeAddress(new Address("newCity", "newStreet", "12345"));

// 치킨 -> 제육볶음
findMember.getFavoriteFoods().remove("치킨");  // equals 재정의 안되어 있으면 안됨
findMember.getFavoriteFoods().add("제육볶음");

다른 곳은 크게 어려움이 없는데 수정에서 알아둬야 하는 점이 조금 있다.

먼저 homeAddress를 수정하는 부분을 보자. 코드에 주석으로도 적혀 있지만 단순하게 setter로 값을 변경했다간 사이드 이펙트 문제가 생길 수도 있다.

따라서 객체를 항상 불변 객체로 만들어 놓고, 값을 변경할 땐 아예 새로운 인스턴스를 만들어서 넣어줘야 한다. 만약 이전 코드를 재사용하고 싶다면 저장할 때 Address를 setHomeAddress() 안에서 사용하지 말고, 따로 빼서 객체를 만들어 주고 넣어주면 된다.

Address address = new Address(...);

Member member = new Member();
member.setHomeAddress(address);

// 이후 변경 시
member.setHomeAddress(new Address("newCity", address.getStreet(), address.getZipcode()));

그 다음은 favoriteFoods 안에 있는 값을 제거하고 새로 추가하는 부분이다. 여기서 remove()의 인자로 보내는 "치킨"이라는 값을 찾으려면 내부적으로 equals()가 동작을 하게 된다.

이때 equals()를 재정의 하지 않았을 경우 "치킨"이라는 값과 동등한 값을 찾지 못해서 삭제가 되지 않게 되니 꼭 재정의 해주도록 하자.

제약 사항

값 타입은 엔티티와 다르게 식별자 개념이 없다. 식별자라는 것이 생기면 그때부턴 값 타입이 아닌 엔티티가 되기 때문이다.

값은 변경되면 추적이 어렵다. 그래서 사이드 이펙트 관련 버그를 찾아내기 힘들다.

값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장해야 한다. 쉽게 말해 객체를 불변 객체로 만들어서 관리해야 한다는 뜻이다.

값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다. 따라서 null값이 있거나 중복으로 저장하면 안된다. (null 제약, unique 제약)

값 타입 컬렉션 대안

실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려하는 것이 나을 수도 있다. 일대다 관계를 위한 엔티티를 만들고, 여기에 값 타입을 사용하는 것이다.

"엔티티로 wrapping 해서 값 타입을 엔티티로 승급시킨다"

@Entity
@Table(name = "ADDRESS")
class AddressEntity {
    @Id @GeneratedValue
    private Long id;

    private Address address;
}

@Entity
class Member {
    ...
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "MEMBER_ID")
    private List<AddressEntity> addressHistory = new ArrayList<>();
}

값을 변경하지 않는다고 해도 DB의 쿼리 자체를 다른 쪽에서 시작해서 가지고 와야 하거나 하는 경우는 전부 엔티티라고 보면 된다.

• ex) 주소가 사라져도 이력이 남아야 한다. (엔티티)

값 타입의 비교

값 타입 비교를 위해선 먼저 동일성 비교와 동등성 비교의 차이를 알아야 한다.

• 동일성(identity) 비교: 인스턴스의 참조 값을 비교, == 를 사용한다.
• 동등성(equivalence) 비교: 인스턴스의 값을 비교, equals()를 사용한다.

값 타입은 동등성 비교를 해야하기 때문에 값 타입의 equals()를 적절하게 재정의해야 한다. 주로 모든 필드를 다 재정의해야 한다.

재정의를 하지 않고 equals() 사용 시 값이 같아도 false가 나온다.

• equals()의 기본은 == 비교이기 때문

// equals() 재정의 전
Address address1 = new Address("city", "street", "10001");
Address address2 = new Address("city", "street", "10001");

System.out.println("address1 equals address2: ", (address1.equals(address2))); // false

재정의 시에는 자동으로 만들어 주는 대로 하는 것이 좋고, 때에 따라선 값의 비교를 필드 접근이 아닌 getter로 호출하거나 getClass() 대신 instanceof를 사용해야 될 수도 있다.

@Override  
public boolean equals(Object o) {  
    if (this == o) return true;  
    if (o == null || getClass() != o.getClass()) return false;  
    Address address = (Address) o;  
    return Objects.equals(city, address.city) && Objects.equals(street, address.street) && Objects.equals(zipcode, address.zipcode);  
}

// 또는

@Override  
public boolean equals(Object o) {  
    if (this == o) return true;  
    if (o == null || getClass() != o.getClass()) return false;  
    Address address = (Address) o;  
    return Objects.equals(getCity(), address.getCity()) && Objects.equals(getStreet(), address.getStreet()) && Objects.equals(getZipcode(), address.getZipcode());  
}

References

• https://www.inflearn.com/course/ORM-JPA-Basic
• https://velog.io/@gentledot/ddd-aggregate

처음으로 과제를 마무리하는데 시간이 남지 않았던 것 같다. 특히 AOP를 구현하기 위해서 기본 개념을 공부하느라 시간을 좀 많이 잡아먹었고, 계속 조느라 집중을 잘 못한 것 같다.

결국 5단계와 6단계 중 하날 더 신경써서 하는 방법 밖에 없었는데, 테스트 코드가 더 중요하지 않을까 싶어서 테스트 코드에 더 시간을 많이 쏟아서 5단계를 제대로 마무리하지 못한 것 같아 아쉽다.

앞으로 팀 프로젝트를 하면서 다음 자격증 공부를 병행해야 하는데 잘할 수 있을지 모르겠다..

Lv 5 해결 과정

A 도메인의 서비스가 B 도메인의 리포지토리를 의존

1. [문제 인식 및 정의]
   • A 도메인의 서비스가 B 도메인의 리포지토리를 의존하고 있음
2. [해결 방안]
   1. [의사결정 과정]
      • 순환 참조 오류를 피할 순 있으나 단일 책임 원칙을 준수하는 것이 둘 중 더 중요하다고 판단.
   2. [해결 과정]
      • 각 서비스를 Write/Read로 나눠서 순환 참조를 피함과 동시에 타 도메인의 서비스를 의존하도록 바꿈
   3. [trade-off]
      • 유저를 찾을 수 없을 때 어떤 유저를 찾을 수 없는지에 대한 자세한 처리가 어려워 진다. (자세한 예외 처리를 할 수 없다)
        • 등록하려고 하는 담당자 유저가 존재하지 않습니다. → 유저를 찾을 수 없습니다.
3. [해결 완료]
   1. [회고]
      • 이제 각 도메인의 Repository는 본인의 Service 들과만 의존해서 단일 책임 원칙을 지킬 수 있게 되었다.

회원 탈퇴 기능이 미구현

1. [문제 인식 및 정의]
   • 회원 탈퇴 기능이 없음
2. [해결 방안]
   1. [의사결정 과정]
      • 탈퇴 기능이 없어도 기능(서비스를 이용하고, 이용하지 않는 것) 문제는 없으나 앞으로 이용하지 않는 사용자의 경우엔 탈퇴시키는 것이 앞으로의 관리 측면에서 더 나을 것 같다고 판단
   2. [해결 과정]
      • UserController와 UserService에 deleteUser() 추가
3. [해결 완료]
   1. [회고]
      • 회원 탈퇴가 생기면서 탈퇴를 원하는 사용자의 경우 탈퇴를 함으로써 (현재는 soft-delete가 적용되어 있지 않기 때문에) 탈퇴 이후 해당 사용자의 정보를 관리할 필요가 없어졌다.
   2. [전후 데이터 비교]

      ![](https://velog.velcdn.com/images/dereck-jun/post/3cb071fe-9085-4a3c-aa5e-9009747f3ea2/image.png)

Timestamped의 각 필드가 nullable 함.

1. [문제 인식 및 정의]
   • Timestamped의 각 필드가 nullable 함.
2. [해결 방안]
   1. [의사결정 과정]
      • 어차피 JPA가 자동으로 해당 값을 채워주는데 굳이 nullable 하게 둘 필요가 없다고 판단함.
      • 또한 null 허용은 보수적으로 적용하는 것이 맞다고 생각함.
   2. [해결 과정]
      • nullable = false를 추가
3. [해결 완료]
   1. [회고]
      • 이전보다 null 값에 대해 안전해졌다.
      • 테스트 코드 상에서의 불편함이 생길 수도 있을 것 같다.
   2. [전후 데이터 비교]

예외 발생 시 메시지의 언어가 통일되지 않음

1. [문제 인식 및 정의]
   • 예외 발생 시 메시지의 언어가 통일되지 않음
2. [해결 방안]
   1. [의사결정 과정]
      • 한국어로 통일하고, 이후 필요한 순간에 메시지 국제화를 통해 여러 언어로 사용할 수 있도록 만드는 것이 나을 것 같다고 판단함.
   2. [해결 과정]
      • 영어로 적힌 모든 에러 메시지를 최대한 같은 의미의 한국어로 치환.
3. [해결 완료]
   1. [회고]
      • 이후 메시지 국제화 적용이 필요할 것 같음
      • 문자열로 관리하는 것이 아닌 Enum으로 관리하는 것이 더 편할 것 같고, 테스트에서도 유용하게 사용될 것 같음

일정 수정과 삭제가 미구현

1. [문제 인식 및 정의]
   • 일정 수정과 삭제가 구현되어 있지 않음
2. [해결 방안]
   1. [의사결정 과정]
      • 일정은 언제든지 바뀔 수 있고, 사라질 수도 있기 때문에 수정과 삭제 기능이 구현되어 있어야 한다고 생각함.
   2. [해결 과정]
      • 일정 수정과 삭제 구현
3. [해결 완료]
   1. [회고]
      • 일정 수정과 삭제가 생겨서 더 이상 오타, 완료, 불발된 일정을 수정하거나 삭제할 수 있게 되면서 깔끔하게 관리할 수 있게 되었다.
        • 우선 순위에 따라 할 일을 조회하고, 할 일을 마치면 완료 상태로 바꾸는 등의 추가 기능도 구현할 수 있을 것 같다.
   2. [전후 데이터 비교]

예외 발생 시 메시지가 어울리지 않음

1. [문제 인식 및 정의]

   • lv 3-2의 3번 케이스 해결 시 todo.getUser() 의 값이 null 일 경우 발생하는 예외 발생 시 메시지가 어울리지 않음.

2. [해결 방안]

   1. [의사결정 과정]
      • 해당 할 일을 만든 유저가 없을 경우 발생하는 것이기 때문에 "담당자를 등록하려고 하는 유저와 일정을 만든 유저가 유효하지 않습니다.”보단 “일정을 만든 유저를 찾을 수 없습니다.” 등의 메시지가 더 어울리는 것 같다고 생각
   2. [해결 과정]
      • 메시지 수정

3. [해결 완료]

   1. [회고]
      • 상황에 더 알맞는 예외 메시지를 보낼 수 있게 되었다.
   2. [전후 데이터 비교]

입력 값 검증

1. [문제 인식 및 정의]
   • 회원가입 시 비밀번호 조건이 없고, @Email 어노테이션의 경우 너무 허술함 (@ 만 있으면 통과)
2. [해결 방안]
   1. [의사결정 과정]
      • 회원가입의 경우엔 비밀번호 변경과 마찬가지로 조건을 명시해줘야 한다고 생각함.
      • @Email 어노테이션의 경우 단순히 @ 만 적으면 조건을 만족하기 때문에 더욱 정교한 이메일 형식 적용을 위해 @Pattern을 사용해서 커스텀으로 만들어 줘야 겠다고 생각함.
   2. [해결 과정]
      • 비밀번호 변경과 동일한 패턴 적용
      • 이메일의 경우
        • 로컬 파트는 영문 대소문자, 숫자, 하이픈, 언더스코어 중 하나 이상을 포함해야 하고, 온점이나 기타 특수문자는 허용하지 않음
        • 도메인 부분은 영문 대소문자, 숫자, 온점 및 하이픈을 사용할 수 있음.
        • 마지막 온점 뒤에 2자 이상 6자 이하의 영문만 허용
3. [해결 완료]
   1. [회고]
      • 더 정확한 수준의 이메일 검증이 가능하게 되었다.
   2. [전후 데이터 비교]

Controller의 Path 구조 변경

1. [문제 인식 및 정의]
   • CommentController 등의 requestUri가 계층적인 구조를 띄고 있음. 이런 경우라면 TodoController 쪽에 같이 위치하는 것이 나을 것 같음.
2. [해결 방안]
   1. [의사결정 과정]
      • 하지만 단일 책임 원칙을 기준으로 바라본다면 이는 CommentController에 위치하는 것이 맞다고 생각함.
      • Manager 도메인도 같은 맥락으로 수정함
   2. [해결 과정]
      • RequestMapping으로 "/comments" 를 공통으로 받게 다시 설계
        • 생성: /comments (RequestDto에 todoId를 추가로 받도록 함)
        • 조회: /comments?todoId={todoId} (RequestParam으로 받도록 함)
        • 수정: /comments/{commentId}
        • 삭제: /comments/{commentId}
3. [해결 완료]
   1. [회고]
      • 일정에 병합되어야 할 것 같던 path가 댓글 중심으로 바뀌면서 명확해진 것 같다. (다른 도메인도 마찬가지)

PersistanceConfig 클래스의 존재 의의

1. [문제 인식 및 정의]
   • PersistanceConfig가 단순히 @EnableJpaAuditing을 설정하기 위해서 존재함
2. [해결 방안]
   1. [의사결정 과정]
      • 실행 클래스에 적용해도 되는 것을 굳이 클래스를 더 만들어서 관리할 필요가 없다고 판단함
   2. [해결 과정]
      • 실행 클래스에 해당 어노테이션을 적용하고 PersistanceConfig 클래스 제거
3. [해결 완료]
   1. [회고]
      • 의미 없는 클래스를 하나 줄일 수 있게 되었다.
      • (추가) 테스트 코드 작성 시 실행 클래스에 @EnableJpaAuditing을 붙이게 되면 추가적인 작업이 필요하다는 것을 알게 되었다.
   2. [전후 데이터 비교]

입력 값 예외 처리 시 불필요한 내용까지 응답

1. [문제 인식 및 정의]
   • GlobalExceptionHandler에서 @Valid를 잡을 때의 메시지에 필요없는 내용까지 출력되고 있었음
2. [해결 방안]
   1. [의사결정 과정]
      • 응답을 받을 때 필요한 내용만 받을 수 있도록 조치가 필요하다고 판단함.
   2. [해결 과정]
      • getBindingResult().getFieldError().getDefaultMessage() 를 통해 기본 메시지 또는 명시적으로 입력한 메시지를 출력할 수 있도록 변경함
3. [해결 완료]
   1. [회고]
      • 응답 메시지에 불필요한 내용을 제거해서 서버의 비용을 줄이고, 더 명확한 예외 메시지를 보낼 수 있게 되었다.
   2. [전후 데이터 비교]

config 폴더 정리

1. [문제 인식 및 정의]
   • config 폴더에 설정이 아닌 다른 종류의 클래스도 존재함
2. [해결 방안]
   1. [의사결정 과정]
      • 각 클래스의 종류나 역할에 따라 리팩토링이 필요하다고 판단함
   2. [해결 과정]
      • 클래스가 사용되는 곳이나 역할에 따라 리팩토링을 진행함
3. [해결 완료]
   1. [회고]
      • config엔 설정 관련 클래스만 위치하도록 해서 필요한 클래스를 더 빠르게 찾을 수 있게 된 것 같다. (가시성의 증가)
   2. [전후 데이터 비교]

트러블 슈팅

요청 본문 로깅 처리 하기

AOP를 사용해서 Lv4 과제를 해결하는 도중 요청 본문에 대한 로그를 찍어야 했었다. 처음엔 필터를 따로 만들어서 순서를 올리면 될까 싶었지만 해결되지 않았었다.

결국 현재 있는 필터에서 가장 빨리 요청을 받는 JwtFilter에 request를 재사용하기 위해 ContentCachingRequestWrapper로 감싸준 뒤 보내줬다.

"재사용하기 위해"라고 말한 이유는 요청 본문을 getInputStream()은 일회용이기 때문에 요청 로그를 찍기 위해선 말 그대로 재사용을 해야 하기 때문이다.

이후 LogTraceAspect 클래스에서 현재 요청 정보를 스레드 로컬 방식으로 저장하기 위해 아래와 같이 적용해줬다. 또한 execution을 사용한 포인트컷보다 커스텀 어노테이션을 만들어서 적용하는 편이 더 간편할 것 같아서 어노테이션이 있는 곳에 어드바이스를 적용하도록 했다.

AOP를 적용한 전체 코드는 다음과 같다.

@Slf4j
@Aspect
@Component
public class LogTraceAspect {

    @Pointcut("@annotation(org.example.expert.domain.common.annotation.LogTrace)")
    public void loggerPointcut() {
    }

    @Around("loggerPointcut()")
    public Object doLogTrace(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        final ContentCachingRequestWrapper cachingRequest = (ContentCachingRequestWrapper) request;

        String traceId = UUID.randomUUID().toString().substring(0, 8);
        String requestBody = getRequestBody(cachingRequest);
        if (!StringUtils.hasText(requestBody)) {
            requestBody = "empty";
        }
        String method = cachingRequest.getMethod();
        LocalDateTime requestTime = LocalDateTime.now();

        // setAttribute()로 저장한 값을 읽어옴
        Long userId = (Long) cachingRequest.getAttribute("userId");

        log.info(toRequestLog(traceId, method, userId, cachingRequest.getRequestURL(), requestTime, requestBody));

        Object result = proceedingJoinPoint.proceed();  // proxy 객체가 target 객체의 메서드를 호출하고 나온 result
        if (!StringUtils.hasText((CharSequence) result)) {
            result = "empty";
        }

        log.info(toResponseLog(traceId, method, cachingRequest.getRequestURL(), userId, requestTime, result));
        return result;
    }

    // 요청 본문 읽어오기
    private String getRequestBody(ContentCachingRequestWrapper cachingRequest) {
        String requestBody = "";
        try {
            requestBody = new String(cachingRequest.getContentAsByteArray(), cachingRequest.getCharacterEncoding());
        } catch (UnsupportedEncodingException uee) {
            throw new InvalidRequestException("Logging 과정에서 에러가 발생했습니다.");
        }
        return requestBody;
    }

    public String toRequestLog(
        String traceId,
        String method,
        Long userId,
        StringBuffer requestUrl,
        LocalDateTime requestTime,
        String requestBody
    ) {
        return String.format(
            "%n========== HTTP REQUEST LOG ==========%n" +
                "Trace ID        : %s%n" +
                "HTTP Method     : %s%n" +
                "Request URI     : %s%n" +
                "Request User ID : %s%n" +
                "Request Time    : %s%n" +
                "Request Body    : %s%n" +
                "======================================",
            traceId, method, requestUrl, userId, requestTime, requestBody
        );
    }

    public String toResponseLog(
        String traceId,
        String method,
        StringBuffer requestUrl,
        Long userId,
        LocalDateTime requestTime,
        Object result
    ) {
        return String.format(
            "%n========== HTTP RESPONSE LOG ==========%n" +
                "Trace ID        : %s%n" +
                "HTTP Method     : %s%n" +
                "Request URI     : %s%n" +
                "Request User ID : %s%n" +
                "Request Time    : %s%n" +
                "Response Body   : %s%n" +
                "======================================",
            traceId, method, requestUrl, userId, requestTime, result
        );
    }
}

요청부터 응답까지 걸린 시간도 넣고 싶었지만 그건 필터에 들어왔을 때부터 나가기 직전까지를 구하는 것이 아니면 의미가 없다고 생각해서 제외하게 되었다.

김영한님의 JPA 강의를 듣고 정리한 내용입니다.

영속성 전이와 고아 객체

영속성 전이 - CASCADE

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때 사용한다. 하나의 부모가 자식을 관리할 때 주로 사용한다.

• ex) 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장
  • 게시판에 첨부파일 경로 -> 한 게시판에서만 관리를 함

다음과 같은 경우에 사용한다.

1. 부모와 자식의 라이프 사이클이 거의 동일할 때
2. 단일 엔티티에 완전히 종속적일 때

연관관계 매핑 속성으로 cascade를 추가해서 설정할 수 있다.

• ex) OneToMany(mappedBy = "...", cascade = CascadeType.ALL)

CASCADE는 다음과 같은 속성이 있다.

• ALL: 모든 CASCADE를 적용
• PERSIST: 엔티티를 영속화할 때, 연관된 엔티티도 함께 유지
• REMOVE: 엔티티를 제거할 때, 연관된 엔티티도 모두 제거
• MERGE: 엔티티 상태를 병합할 때, 연관된 엔티티도 모두 병합
• REFRESH: 상위 엔티티를 새로고침할 때, 연관된 엔티티도 모두 새로고침
• DETACH: 부모 엔티티를 준영속화하면, 연관 엔티티도 준영속화 시킴

주의

영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없다. 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐이다.

위에 설명한 것과 같이 소유자가 하나일 때만 사용해야 한다. 소유자가 둘 이상일 때 사용하면 의도하지 않은 방향으로 전이될 수 있음.

• ex) 부모 A, B에 자식 C가 있고, A-C, B-C로 CASCADE 되어 있을 때 A 삭제 시 C까지 삭제되어 의도치 않게 B에 연결되어있는 C 값이 null로 바뀌게 되는 참사 발생

고아 객체

부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능이다.

orphanRemoval 속성으로 자동 삭제 여부를 결정할 수 있다.

@Entity
class Parent {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @OneToMany(..., orphanRemoval = true)
    @JoinColumn(name = "parent")
    private List<Child> children = new ArrayList<>();
    ...
}

orphanRemoval 속성이 켜져있을 경우 List에서 값이 사라지면 해당 자식 엔티티도 삭제된다.

Child child1 = new Child();  
child1.setName("child1");  

Child child2 = new Child();  
child2.setName("child2");  

Parent parent = new Parent();  
parent.setName("parent1");  
parent.addChild(child1);  
parent.addChild(child2);  

em.persist(parent);  
em.flush();  
em.clear();  

List<Child> children1 = parent.getChildren(); 

for (Child child : children1) {  
    System.out.println("child = " + child.getName());  // 1
}  

Parent findParent = em.find(Parent.class, parent.getId());  
findParent.getChildren().remove(0);  
List<Child> children2 = findParent.getChildren();  

for (Child child : children2) {  
    System.out.println("child = " + child.getName());  // 2
}

이 경우 1번에선 2개의 항목이 나오지만 2번에선 index = 0에 해당하는 객체가 삭제돼서 1개의 항목만 나온다.

주의

참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이기 때문에 참조하는 곳이 하나일 때 사용하거나 특정 엔티티가 개인 소유할 때 사용한다.

@OneToMany 또는 @OneToOne만 사용 가능하다.

개념적으로 부모를 제거하면 자식은 고아가 된다. 따라서 고아 객체 제거 기능을 활성화 하면, 부모를 제거할 때 자식도 함께 제거된다. 이것은 CascadeType.REMOVE처럼 동작한다.

영속성 전이 + 고아 객체의 생명주기

영속성 전이와 고아 객체를 더하는 것은 cascade = CascadeType.ALL + orphanRemoval = true의 의미이다.

위의 둘을 전부 켜게 되면 다음과 같은 의미를 지닌다.

• 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거한다.
• 두 옵션을 전부 켰기 때문에 부모 엔티티를 통해 자식의 생명주기를 관리할 수 있다.
• 도메인 주도 설계(DDD)의 Aggregate Root 개념을 구현할 때 유용하다.

참고: 도메인 주도 설계 (3) - 애그리거트

References

• https://www.inflearn.com/course/ORM-JPA-Basic
• https://velog.io/@gentledot/ddd-aggregate

김영한님의 JPA 강의를 보고 정리한 내용입니다.

지연 로딩과 즉시 로딩

지연 로딩

지연 로딩의 경우 연관관계 매핑 어노테이션에 fetch = FetchType.LAZY 속성을 추가해서 선언해준다. 연관관계 어노테이션 중 *ToMany에 해당하는 어노테이션의 기본 값이다.

• ex) @OneToMany(fetch = FetchType.LAZY)

지연 로딩을 사용하게 되면 객체를 DB가 아닌 프록시에서 가져온다. 프록시에서 객체를 가져올 경우 실제로 사용(초기화)되기 전까지 조회 쿼리를 사용하지 않는다.

예를 들어 Member와 Team 클래스가 있고, Member에 @ManyToOne(fetch = FetchType.LAZY)로 Team과 연관관계를 맺고 있다고 가정해보자.

@Entity
class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;
    ...
}

지연 로딩의 경우 Member 객체를 저장하고, member를 조회하게 되면 member는 DB에서 조회를 하고, 조회된 member안의 Team 객체는 프록시로 가져온다.

그리고 Team을 실제로 사용할 때 DB에서 조회 후 가져오게 된다.

member 객체를 조회할 때 굳이 team 객체를 조회할 필요가 없으므로 DB에 쿼리가 한 번만 나가게 돼서 성능상의 이점을 얻는다.

하지만 지연 로딩 역시 후에 서술할 N+1의 문제가 있다

즉시 로딩

즉시 로딩의 경우 연관관계 매핑 어노테이션에 fetch = FetchType.EAGER 속성을 추가해서 선언해준다. 연관관계 어노테이션 중 *ToOne에 해당하는 어노테이션의 기본 값이다.

• ex) @ManyToOne(fetch = FetchType.EAGER)

즉시 로딩을 사용하면 무조건 조회하는 시점에 필요한 값들이 모두 들어가 있어야 한다.

예를 들어 Member와 Team 클래스가 있고, Member에 @ManyToOne(fetch = FetchType.EAGER)로 Team과 연관관계를 맺고 있다고 가정해보자.

@Entity
class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "team_id")
    private Team team;
    ...
}

즉시 로딩의 경우 Member 객체를 저장하고, member를 조회하게 되면 Team 객체의 사용 여부와 관계없이 조회 시점에 team이 무조건 들어가 있어야 하기 때문에 조회 시 두 엔티티를 조인해서 가져온다.

어떤 방법을 사용해야 할까?

비즈니스 로직에서 두 객체가 동시에 사용되는 빈도가 높다면 즉시 로딩을 사용할 것 같다. 하지만 그것은 어디까지나 이론에서 적용되는 것이고, 실제 실무에선 무조건 지연 로딩을 사용한다고 한다.

• 즉시 로딩 사용 시 예상치 못한 SQL 문제 발생
• 즉시 로딩은 JPQL에서 N+1의 문제를 발생시킴
  • 다음과 같은 JPQL을 사용했다고 가정
    • em.createQuery("select m from Member m", Member.class).getResultList()
  • 이때 실제 SQL은 이렇게 실행될 것이다.
    • SQL: select * from Member
  • 그럼 Member 객체를 전부 다 가져오게 되는데 이때 Member 내부를 보니 Team에 대한 매핑이 즉시 로딩으로 되어있는 것을 확인하고 SQL을 한 번 더 실행
    • SQL: select * from Team where ...
  • 그런데 이 쿼리가 Member의 개수만큼 나감
  • 그래서 Member의 개수 N에 최초 Member를 조회하는 쿼리까지 합한 N+1번 쿼리가 실행됨

결론은 모든 연관관계에 지연 로딩을 사용하고, JPQL 패치 조인이나, 엔티티 그래프 기능을 사용하자.

참고: https://velog.io/@jinyoungchoi95/JPA-%EB%AA%A8%EB%93%A0-N1-%EB%B0%9C%EC%83%9D-%EC%BC%80%EC%9D%B4%EC%8A%A4%EA%B3%BC-%ED%95%B4%EA%B2%B0%EC%B1%85

References

• https://velog.io/@jinyoungchoi95/JPA-%EB%AA%A8%EB%93%A0-N1-%EB%B0%9C%EC%83%9D-%EC%BC%80%EC%9D%B4%EC%8A%A4%EA%B3%BC-%ED%95%B4%EA%B2%B0%EC%B1%85
• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

프록시

프록시는 다음과 같은 질문에서 시작한다.

"Member 엔티티를 조회할 때 Team 엔티티도 함께 조회해야 할까?"

질문에 대한 해답은 "실제 필요한 비즈니스 로직에 따라 다르다"이다. 비즈니스 로직에서 필요하지 않을 때도 있는데, 만약 항상 Team을 같이 조회한다면 이는 낭비일 것이다.

JPA는 위와 같은 행동(낭비)를 방지하기 위해 지연 로딩과 프록시로 해결한다.

프록시 기초

뒤에 나올 지연 로딩을 이해하려면 프록시의 개념을 완벽히 이해해야 한다.

프록시는 쉽게 말해 실제 객체를 상속한 가짜 클래스이다. 프록시 객체는 실제 클래스와 겉 모양이 같고, 클라이언트의 입장에선 내가 호출한 것이 프록시 객체인지 실제 객체인지 알 수 없다.

또한 프록시 객체는 실제 객체의 참조(target)를 보관한다. 프록시 객체의 메서드를 호출하면 프록시 객체는 실제 객체(target)의 메서드를 호출한다.

JPA에는 em.find() 말고 em.getReference() 메서드도 제공한다.

• em.find(): DB를 통해 실제 엔티티 객체를 조회하는 메서드
• em.getReference(): 프록시 엔티티 객체를 조회하는 메서드

em.find()로 객체를 조회하면 데이터베이스에 바로 쿼리가 나간다.

• 지금 당장 필요하지 않아도 바로 쿼리 나감 하지만 em.getReference()로 객체를 조회하면 실제 객체가 사용되는 순간에 DB로 쿼리가 나가게 된다.
• 진짜 필요한 순간에 쿼리 나감
  • 실제 객체가 사용되는 순간 == 실제로 필요한 시점

프록시 객체의 초기화 과정

상황: em.getReference()로 Member 프록시 객체를 조회한 뒤에 member.getName()으로 강제 호출 시 내부에선 어떻게 동작하는지?

1. em.getReference()로 프록시 객체를 조회한 뒤에 member.getName()으로 강제 호출을 하면
2. Member 프록시 객체의 target 값이 처음에 없기 때문에 JPA가 영속성 컨텍스트에 초기화를 요청한다.
3. 영속성 컨텍스트는 실제 DB를 조회한 뒤에
4. 실제 엔티티 객체를 생성하고
5. 프록시 객체의 target과 연결시켜준다.
   • 프록시 내부에는 Member target 이라는 멤버 변수가 있다고 생각
6. 그래서 getName()을 했을 때 프록시 객체 내부의 target.getName()을 통해 Member에 있는 member.getName()이 반환이 됨.

프록시의 특징

• 프록시 객체는 처음 사용할 때 한 번만 초기화 된다.
• 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것이 아니라 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근이 가능해진다.
• 프록시 객체는 원본 엔티티를 상속받는다. 따라서 타입 체크 시 주의해야 한다.
  • == 비교 대신 instance of 사용
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티가 반환된다.
  • 1차 캐시에 이미 올라가 있기 때문에 굳이 프록시를 거칠 필요가 없음
  • JPA는 한 트랜잭션 내에서 같은 식별자에 대한 객체 조회는 동일성을 보장
  • 반대의 경우에도 동일하게 작동한다.
    • 프록시 먼저 호출 후 DB를 통해 조회하는 em.find() 사용해도 select 쿼리는 나가지만 프록시 반환됨 -> 동일성 보장을 위함
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제가 발생한다.
  • 상당히 자주 만나는 문제
  • org.hibernate.LazyInitializationException 예외를 터트림
  • em.detach(), em.clear(), em.close() 모두 같은 에러 발생

프록시 확인

프록시 인스턴스의 초기화 여부 확인

• emf.getPersistenceUnitUtil().isLoaded(Object entity)

프록시 클래스 확인 방법

• entity.getClass().getName()

프록시 강제 초기화 (하이버네이트에서 제공)

• org.hibernate.Hibernate.initialize(entity)

JPA 표준 상 강제 초기화는 없기 때문에 강제 호출을 해야 한다.
강제 호출(실제 객체의 메서드를 사용해서 초기화): entity.getXxx()

References

• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

상속관계 매핑

객체지향에는 클래스끼리 상속이 가능하다. 하지만 관계형 데이터베이스는 상속관계를 지원하지 않는다.

그 대신 상속 관계와 비슷한 논리 모델링 기법인 슈퍼타입, 서브타입 관계를 통해 객체의 상속 관계를 매핑할 수 있다.

슈퍼타입, 서브타입을 실제 테이블로 구현하는 방법엔 3가지 방법이 있다.

1. 조인 전략
2. 단일 테이블 전략
3. 구현 클래스마다 테이블 전략

위의 3가지 방법 모두 JPA의 어노테이션인 @Inheritance(strategy = InheritanceType.XXX)를 통해 구현할 수 있다. 이때 기본 값은 단일 테이블 전략이다.

• JOINED
• SINGLE_TABLE
• TABLE_PER_CLASS

구분자 컬럼(DTYPE)이 필요한 경우 부모 클래스에 @DiscriminatorColumn으로 DTYPE을 설정할 수 있고 name 속성으로 DTYPE의 컬럼명을 바꿀 수 있다. 기본 값은 DTYPE이다.

자식 클래스엔 @DiscriminatorValue 어노테이션으로 DTYPE이 저장되는 값을 바꿀 수 있다. 기본 값은 클래스명이다.

어떤 전략을 사용하든지 크게 바뀌는 코드는 없다. 단지 어노테이션만 바꿔주면 JPA가 알아서 해당하는 전략에 맞게 테이블을 매핑해준다.

조인 전략

조인 전략은 슈퍼타입, 서브타입 논리 모델을 각각 테이블로 옮긴 방식이다. 테이블이 구분되어 있기 때문에 데이터를 조회할 때 조인이 필요해서 조인 전략이라고 부른다.

조인 테이블 전략은 구분자 컬럼이 반드시 필요하진 않지만 구분자 컬럼을 설정하는 것이 부모 테이블 조회만 해도 어떤 데이터 타입을 가지고 있는지 확인할 수 있어서 설정하는 것이 좋다.

장/단점

장점

• 테이블이 정규화 된다.
• 외래 키 참조 무결성 제약 조건을 활용할 수 있다.
• 저장 공간 효율화
  • 정규화가 되어있기 때문

단점

• 조회 시 조인을 많이 사용하기에 성능이 저하됨
• 조회 쿼리가 복잡함
• 데이터 저장 시 insert 쿼리 2번 호출

단점으로 성능이 떨어질 수 있다고 했지만 데이터가 엄청 많은게 아닌 이상 성능에 대한 이슈가 있지는 않다.

조인 전략은 상속 관계를 매핑하는 전략 중 데이터베이스의 관점에서 가장 정규화된 깔끔하고 정석적인 선택이다.

단일 테이블 전략

단일 테이블 전략은 이름 그대로 하나의 테이블에 모든 데이터를 몰아넣는 전략이다.

조인 전략에서는 구분자 컬럼이 필수는 아니었지만 단일 테이블 전략은 하나의 테이블에 모든 데이터가 들어가기 때문에 구분자 컬럼이 필수다. (개발자가 지정해주지 않아도 JPA가 자동으로 만들어 준다)

장/단점

장점

• 조인이 필요 없다
  • 일반적인 상황에서 조회 성능이 빠름
  • 조회 쿼리가 단순함

단점

• 자식 엔티티에 매핑한 컬럼은 모두 null 값을 허용해야 한다.
  • 데이터 무결성 입장에서 애매함
• 테이블 컬럼의 길이가 커지기 때문에 조인 전략과 비교해서 성능이 더 느려질 수도 있다.

조인 전략과 비교해서 성능이 더 느려지려면 임계점을 넘어야 하는데 보통 넘을 일은 없다.

단일 테이블 전략은 조인 전략과는 다르게 테이블 하나만 사용하기 때문에 가볍고, 덜 복잡한 프로젝트와 잘 어울리는 전략이다. 프로젝트가 덜 복잡하고, 바뀌지 않을 것 같다면 추천한다.

구현 클래스마다 테이블 전략

조인 전략과 좀 비슷하지만 부모 객체를 없애버리고, 부모 객체에 있는 속성들을 자식 객체에 내리는 전략이다.

이때 부모 객체는 테이블이 만들어지면 해당 객체만 독단적으로 쓰는 일도 있다는 것이기 때문에 아예 만들어 지지 않게 추상 클래스로 정의한다.

장단점

장점

• 서브타입을 명확하기 구분해서 처리할 때 효과적
• not null 제약 조건 사용 가능

단점

• 여러 자식 테이블을 함께 조회할 때 성능이 느림
  • 여러 테이블을 조회할 때 UNION 쿼리를 사용함
• 자식 테이블을 종합해서 쿼리하기 어려움
  • 뭘 묶어낼 수 있는게 있어야 통합이 가능한데 묶어낼 수 있는 것이 없음
    • ex) 시스템에 새로운 타입이 추가돼서 정산 로직을 다시 짜야 함
    • ex) 정산을 할 때 한 테이블만 정산해서 되는게 아니라 각 테이블에서 모두 정산을 해야 함

구현 클래스마다 테이블 전략은 변경이라는 관점에서 볼 때 매우 안좋다. 시스템에 새로운 것이 추가 될 때마다 굉장히 많은 걸 뜯어내야 한다.

구현 클래스마다 테이블 전략은 DBA와 개발자 모두 선호하지 않는 전략이다. 선택을 하게 되면 먼 미래에 언젠가 큰 후회를 하게 된다. 따라서 사용하지 않도록 하자.

@MappedSuperClass

공통 매핑 정보가 필요할 때 사용한다. 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용한다.

아래 예시를 보면 공통으로 들어가는 정보인 createdBy, createdAt, lastModifiedBy, lastModifiedAt를 BaseEntity 클래스에 모아서 사용하는 것을 볼 수 있다.

@Getter
@MappedSuperClass
public abstract class BaseEntity {
    private String createdBy;
    private LocalDateTime createdAt;
    private String lastModifiedBy;
    private LocalDateTime lastModifiedAt;
}

@Entity
public class Post extends BaseEntity {
    ...
}

@MappedSuperClass는 상속관계 매핑이 아니니 헷갈리지 말자.

@MappedSuperClass는 엔티티가 아니라 그저 속성만 내려주는 클래스이다. 그래서 해당 어노테이션이 적용되어 있는 클래스는 테이블과 매핑이 되지 않고, 부모 클래스를 상속받는 자식 클래스에 매핑 정보만 제공한다.

같은 맥락으로 해당 어노테이션이 적용된 클래스의 타입으로는 조회와 검색이 불가능하다. 이것도 상속관계 매핑과 다른 점이라고 볼 수 있다. (상속관계 매핑은 가능)

해당 클래스는 직접 사용할 일이 없으므로 추상 클래스로 만드는 것을 권장한다.

@Entity 클래스는 같은 @Entity 클래스나 @MappedSuperClass로 지정한 클래스만 상속 가능하다.

References

• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

연관관계 매핑 2

연관관계 정의 규칙

연관관계를 매핑할 때, 생각해야 할 것은 크게 3가지가 있다.

1. 방향 - 단/양방향
   • 무조건 양방향 연관관계를 가지면 안될까?
   • 양방향 매핑 정리
2. 연관관계의 주인 - 연관관계에서 관리 주체
   • 왜 연관관계의 주인을 지정해야 할까
   • 연관관계 매핑에서 자주하는 실수
3. 다중성
   • 일대일(1:1)
   • 일대다(1:N)
   • 다대일(N:1)
   • 다대다(N:M)

"연관관계 매핑 2"에서는 다중성에 대한 내용이 있음

다중성

데이터베이스를 기준으로 다중성을 결정한다. 이때 연관관계는 대칭성을 가진다.

• 일대다(1:N) <--> 다대일(N:1)
• 일대일(1:1) <--> 일대일(1:1)
• 다대다(N:M) <--> 다대다(M:N)

이때 일대다 관계과 다대일 관계는 똑같은 내용이 아니라 각각 일을 주인으로 두었을 때의 관점과 다를 주인으로 두었을 때의 관점에서 봤을 때의 내용이다.

다대일(N:1)

다대일 관계는 다쪽에서 외래 키를 관리하는 형태이고, 가장 많이 사용하는 연관관계이다. 반대는 일대다 관계이다.

회원(Member)와 팀(Team)으로 다대일 관계를 만들어 보자.

• 요구사항
  • 한 팀에는 여러 회원이 들어갈 수 있다.
  • 한 회원은 한 개의 팀에만 들어갈 수 있다.

단방향 다대일 예제 코드

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    @ManyToOne
    @JoinColumn(name = "team_id")
    private Team team;

    ...
}

@Entity
public class Team {
    @Id @GeneratedValue
    @Column(name = "team_id")
    private Long id;
    private String teamName;

    ...
}

다대일이기 때문에 Member 클래스 쪽에 @ManyToOne을 사용해서 해당 클래스가 다(Many)라는 것을 지정하면서 @JoinColumn(name = "team_id")로 Team 클래스와 어떤 컬럼을 기준으로 조인할 것인지를 정해줬다.

양방향 다대일 예제 코드

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    @ManyToOne
    @JoinColumn(name = "team_id")
    private Team team;

    ...
}

@Entity
public class Team {
    @Id @GeneratedValue
    @Column(name = "team_id")
    private Long id;
    private String teamName;

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();

    ...
}

양방향의 경우 일(ToOne)에 해당하는 Team 클래스에 @OneToMany를 추가하고 연관관계의 주인을 mappedBy로 지정해준다. 이때 주인 객체에서 사용하는 변수명을 지정해주면 된다.

이번 예제 코드의 경우 Team 클래스의 주인인 Member 클래스가 Team에 대한 변수로 team을 사용하고 있기 때문에 mappedBy = "team"으로 지정해줬다.

일대다(1:N)

여기서는 앞서 말한대로 일(One)쪽이 연관관계의 주인일 때를 말한 것이다. 즉, 일에서 외래 키를 관리하겠다는 말이다.

객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조이다.

추가로 @JoinColumn을 꼭 사용해야 한다. 그렇지 않으면 @JoinTable 방식을 사용하게 된다.

• 자동으로 중간 테이블을 하나 추가하게 됨 (기본 값임)

표준 스펙에서 지원은 하지만 권장하지는 않는다.

일대다 단방향

예제 코드

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    ...
}

@Entity
public class Team {
    @Id @GeneratedValue
    @Column(name = "team_id")
    private Long id;
    private String teamName;

    @OneToMany
    @JoinColumn(name = "team_id") // DB 관점에서 조인할 컬럼
    private List<Member> members = new ArrayList<>();

    ...
}

예제 코드를 기준으로 일대다 관계는 Team 클래스의 members 값을 바꿨을 때 다른 테이블에 있는 외래 키를 update 해줘야 한다.

아까 일에서 외래 키를 관리한다고 했잖아요

위에서 말한 외래 키의 관리는 JPA가 조회, 저장, 수정, 삭제 등을 하는 작업에서의 주체를 말한 것이고, 여기서 말한 다른 테이블에 있는 외래 키는 데이터베이스의 관점에서의 외래 키를 말한 것이다.

코드에서 @OneToMany를 사용한다고 그게 데이터베이스까지 영향을 미치는 것은 아니다. 해당 어노테이션은 JPA가 어떤 객체를 중심으로 관리할 것인가를 나타낸 것이다.

실제 사용을 아래와 같이 할 수 있다.

Member member = new Member();  
member.setName("memberA");  

em.persist(member);  // 실행 1

Team team = new Team();  
team.setName("teamA");  
team.getMembers().add(member);  

em.persist(team);  // 실행 2

실행 1에서는 별 문제 없이 insert 쿼리가 나가는 것을 알 수 있다.

하지만 실행 2가 문제다.

실행 2에선 team을 insert하고 member를 update하는 쿼리가 나간다. 이때 Member에 실제 외래 키가 존재하기 때문에 Team에서 Member에 외래 키를 수정하려면 조인 후 update 쿼리를 날려야만 수정할 수 있는 문제가 생긴 것이다.

• Team을 수정했는데 Member가 수정이 되는 기적을 보게 됨
• insert 쿼리 실행 후 update 쿼리를 실행하게 되는 낭비가 발생
  • 성능상 이슈는 크게 없으나 낭비가 발생하는 것은 팩트

일대다 단방향이 필요한 경우라도 유지보수의 측면에서 바라볼 때 다대일 관계로 매핑하는 것이 더 수월하기에 다대일 방식을 추천한다.

일대다 단방향 관계 정리

일대다 단방향 매핑의 단점

• 엔티티가 관리하는 외래 키가 다른 테이블에 있다.
  • 그냥 이것 하나만으로도 어마어마한 단점
• 연관관계 관리를 위해 추가적인 update 쿼리가 실행된다.

결론적으로 일대다 단방향 매핑보다는 객체적으로 설계가 덜 깔끔해지는 손해를 보더라도 다대일 양방향 매핑을 사용하는 것이 더 좋다. (그냥 일대다를 쓰지 말자)

일대다 양방향 매핑은 없나요?

일대다 양방향 매핑이라는 것은 공식적인 스펙으로 존재하진 않는다. 하지만 야매로 된다.

위의 일대다 단방향 예제 코드에서 Member 클래스의 내용만 추가했다.

일대다 양방향 예제 코드

@Entity
public class Member {
    ...

    @ManyToOne
    @JoinColumn(name = "team_id", insertable = false, updatable = false)
    private Team team;

    ...
}

코드를 보면 일대다의 대칭이기 때문에 @ManyToOne을 추가했다.

그 다음이 중요한데 @JoinColumn으로 조인할 테이블의 id를 설정해준 뒤에 insertable, updatable 속성을 false로 만들어서 매핑은 되어있고 값도 쓰는데, 최종적으로 insert/update를 하지 않는 것이다.

정말 필요할 때가 아주 가끔 있겠지만 양방향으로 객체 참조가 필요한 경우 그냥 다대일 양방향 매핑을 사용하도록 하자.

일대일(1:1)

일대일 관계는 그 반대도 일대일이다. 그래서 주 테이블이나 대상 테이블 중 어느 곳이든지 외래 키를 설정할 수 있다.

주 테이블이 Member라고 가정했을 때 외래 키를 Member에 넣어도 되고, 주 테이블은 아니지만 Team에 외래 키를 넣어도 되는 것이다.

추가로 외래 키에 데이터베이스 유니크 제약 조건을 추가해야 일대일 관계가 성립한다. 사실 굳이 제약 조건을 넣지 않아도 할 수는 있지만 그러면 애플리케이션 관리를 매우 잘해야 한다.

데이터베이스 입장에서는 외래 키에 데이터베이스 유니크 제약 조건이 추가가 된게 일대일 관계가 된다.

일대일 주 테이블 단방향

일대일 주 테이블 단방향 예제 코드

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;
}

@Entity
public class Locker {
    @Id @GeneratedValue
    @Column(name = "locker_id")
    private Long id;
    private int number;
}

코드를 보면 알겠지만 다대일 단방향 매핑과 어노테이션만 다르지 거의 똑같다는 것을 알 수 있다.

일대일 주 테이블 양방향

일대일 주 테이블 양방향 예제 코드

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;
}

@Entity
public class Locker {
    @Id @GeneratedValue
    @Column(name = "locker_id")
    private Long id;
    private int number;

    @OneToOne(mappedBy = "locker")
    private Member member;
}

마찬가지로 다대일 양방향 매핑처럼 외래 키가 있는 곳이 주인이기 때문에 반대쪽에 mappedBy를 적용해서 읽기 전용으로 만들어 준다.

일대일 대상 테이블 단방향

불가능하다. 지원도 안되고 방법이 없다.

일대일 대상 테이블 양방향

이 경우는 논란의 여지가 있다. 어떤 테이블에서 외래 키를 관리하는게 좋을 것인가를 생각해봐야 한다.

테이블의 경우 한 번 생성되면 변경이 매우 어렵다. 하지만 야속하게도 비즈니스 로직은 언제든 바뀔 수 있다.

만약 Member가 여러 개의 Locker를 가질 수 있게 변경되었다면 Locker에 외래 키가 있는 것이 변경에 유연하다.

하지만 비즈니스에서 Member는 웬만하면 조회를 해와야 한다. 이런 입장에서 바라보았을 땐 별 다른 조인 없이 member.getLocker()로 locker에 대한 값을 확인할 수 있다는 것이 장점이 된다.

결론적으로 종합적으로 판단하고 결정해야 한다는 것이고, 코드 상으로 바라보았을 땐 일대일 주 테이블 양방향을 할 때와 똑같이 하면 된다.

일대일 정리

• 주 테이블에 외래 키
  • 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾는 방식
    • 장점: 주 테이블만 조회해도 대상 테이블에 데이터까지 확인 가능
    • 단점: 값이 없으면 외래 키에 null 허용
  • 객체 지향 개발자 선호
  • JPA 매핑 편리
• 대상 테이블에 외래 키
  • 대상 테이블에 외래 키 존재
    • 장점: 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경했을 때 테이블 구조 유지 가능
    • 단점: 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨
      • Member를 로딩할 때 무조건 Locker를 뒤져서 확인해야 한다.
      • 어차피 쿼리가 나가게 됨 -> 값의 존재 여부를 알기 때문에 프록시를 만들 이유가 없음
      • 따라서 지연 로딩으로 설정해도 대상 테이블에 외래 키가 있으면 무조건 즉시 로딩이 된다. (지연 로딩 설정해도 쿼리만 한 번 더 나감)

다대다(N:M)

관계형 데이터데이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없기 때문에 사용하면 안된다.

대신 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 한다.

여기서 문제는 객체는 컬렉션을 사용해서 객체 2개로 다대다 관계를 풀어낼 수 있다. 따라서 ORM은 중간 테이블을 임의로 만들어서 매핑을 해준다.

설명만 들으면 "자동으로 매핑을 해준다니 이거 완전 좋은거 아닌가요?" 라고 생각할 수 있기 때문에 왜 안되는지 알아보자

다대다 단/양방향

다대다 단/양방향 예제 코드

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    @ManyToMany
    @JoinTable(name = "member_product")
    private List<Product> products = new ArrayList<>();    
}

@Entity
public class Product {
    @Id @GeneratedValue
    @Column(name = "product_id")
    private Long id;
    private String name;

    // 양방향의 경우 추가
    // @ManyToMany(mappedBy = "products")
    // private List<Member> members = new ArrayList<>();
}

예제 코드에선 @JoinTable을 사용해서 생성되는 테이블의 이름을 지정해줬지만 해당 어노테이션을 빼도 중간 테이블을 임의로 생성해준다.

그 외 나머지는 다른 방법들과 동일하다.

그렇다면 왜 실무에서 사용하면 안될까?

다대다 매핑의 한계

다대다 관계의 경우 데이터베이스로는 풀어낼 수 없는 관계이기 때문에 중간(연결) 테이블을 임의로 생성한다고 설명했었다.

하지만 중간 테이블은 단순히 연결만 하고 끝나지 않는다. 중간 테이블에는 추가적인 비즈니스 로직이 들어가는데 이런 로직을 추가할 수가 없다. 또한 중간 테이블이 숨겨져 있기 때문에 나도 모르는 복잡한 조인 쿼리가 발생하게 된다.

위와 같은 이유로 실무에서 사용하면 안되는 것이다.

다대다 한계 극복

그럼 이런 문제를 어떻게 해결할 수 있을까?

바로 @ManyToMany를 @OneToMany + @ManyToOne으로 바꾸고, 중간 테이블을 엔티티로 승격하는 것이다.

그렇다면 이런 형태의 매핑이 이뤄질 것이다.

@Entity
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    @OneToMany(mappedBy = member)
    private List<MemberProduct> memberProducts = new ArrayList<>();    
}

@Entity
public class MemberProduct {
    @Id @GeneratedValue
    @Column(name = "member_product_id")
    private Long id;

    @ManyToOne
    @JoinColumn(name = "member_id")
    private Member member;

    @ManyToOne
    @JoinColumn(name = "product_id")
    private Product product;
}

@Entity
public class Product {
    @Id @GeneratedValue
    @Column(name = "product_id")
    private Long id;
    private String name;

    @OneToMany(mappedBy = "product")
    private List<MemberProduct> memberProducts = new ArrayList<>();
}

이렇게 되면 중간 테이블에 내가 원하는 비즈니스 로직들을 추가해서 구현할 수 있게 된다.

번외로 MemberProduct의 PK를 지금처럼 따로 만들어 주는 것이 아닌 member_id와 product_id를 묶어서 PK로 설정하고 각각 FK로 쓰는 방법도 존재한다.

어떤 방식을 사용할 것인지는 고민이 필요하지만 따로 id를 두고, 필요에 따라 제약 조건을 추가하는 것이 운영적 측면에서 더 도움이 될 수도 있다.

결론은 다대다는 사용하지 말자.

References

• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

연관관계 매핑 1

연관관계 정의 규칙

연관관계를 매핑할 때, 생각해야 할 것은 크게 3가지가 있다.

1. 방향 - 단/양방향
   • 무조건 양방향 연관관계를 가지면 안될까?
   • 양방향 매핑 정리
2. 연관관계의 주인 - 연관관계에서 관리 주체
   • 왜 연관관계의 주인을 지정해야 할까
   • 연관관계 매핑에서 자주하는 실수
3. 다중성
   • 일대일(1:1)
   • 일대다(1:N)
   • 다대일(N:1)
   • 다대다(N:M)

"연관관계 매핑 1"에서는 방향과 연관관계의 주인에 대한 내용이 있음

방향

데이터베이스 테이블은 외래 키 하나로 양 쪽 테이블 조인이 가능하다. 따라서 데이터베이스는 방향을 나눌 필요가 없다.

하지만 객체는 참조용 필드가 있는 객체만 다른 객체를 참조하는 것이 가능하다. 그렇기 때문에 두 객체 사이에 하나의 객체만 참조용 필드를 갖고 참조하면 단방향 관계, 두 객체 모두가 각각 참조용 필드를 갖고 참조하면 양방향 관계라고 한다.

엄밀하게는 양방향 관계는 없고, 두 객체가 서로 단방향 참조를 가져서 양방향 관계처럼 사용하고 있다고 말하는 것이다.

JPA를 사용하여 데이터베이스와 패러다임을 맞추기 위해서는 객체는 어떤 방향으로 연관관계를 가질 지 선택해야 한다. 이때 선택은 비즈니스 로직에서 어떤 객체가 참조가 필요한 지 생각해보면 된다.

• Member와 Team이 있을 때
  • member.getTeam(): Member가 Team을 참조
  • team.getMember: Team이 Member를 참조

이렇게 비즈니스 로직에 맞게 선택 했는데 두 객체가 서로 단방향 참조를 했다면 양방향 연관관계가 되는 것이다.

무조건 양방향 연관관계를 가지면 안될까?

객체 관점에서 양방향 연관관계를 가지면 오히려 복잡해질 수 있다.

예시로 일반적인 비즈니스 애플리케이션에서 사용자(User) 엔티티는 많은 테이블과 연관관계를 맺게 된다. 이런 경우에 모든 엔티티를 양방향으로 설계하게 되면 사용자 엔티티는 엄청나게 복잡해질 것이다.

그리고 다른 엔티티들도 불필요한 연관관계 매핑으로 인해 복잡성이 증가할 수 있다.

양방향 매핑 정리

• 단방향 매핑만으로도 이미 연관관계 매핑은 완료되어야 한다.
  • 설계라는 관점에서만 봤을 때 단방향으로 끝내라는 말
• 양방향 매핑은 반대 방향으로 조회 기능이 추가된 것일 뿐이다.
  • 조회 기능 = 객체 그래프 탐색
• JPQL에서 역방향으로 탐색할 일이 많다.
  • (하지만) 단방향 매핑을 한 뒤에 필요할 때 양방향을 추가해도 된다.
    • 어차피 테이블에 영향을 주지 않음
    • 연관관계 편의 메서드 예시를 활용해서 추가하도록 한다.

연관관계 편의 메서드 예시

class Member {
    ...
    @ManyToOne
    @JoinColumn(name = "team_id")
    private Team team;

    public void changeTeam(Team team) {
        this.team = team;
        team.getMembers().add(this);  // 해당 메서드 호출 시 자동으로 동기화
    }
}

비즈니스 로직이 정말 복잡하면 값을 체크하는 로직을 포함하도록 하자.

• null 체크 로직
• 기존 값 변경 시 필요한 로직

연관관계의 주인

두 객체가 양방향(단방향 2개) 관계를 맺을 때, 연관관계의 주인을 지정해야 한다. 연관관계의 주인을 지정하는 것은 두 단방향 관계 중, 제어의 권한을 갖는 실질적인 관계가 어떤 것인지 JPA에게 알려준다고 생각하면 된다.

• 제어의 권한: 외래 키를 비롯한 테이블 레코드를 조회, 저장, 수정, 삭제 처리하는 것

연관관계의 주인이 아닌 쪽에 mappedBy 속성으로 주인을 지정한다. 쉽게 말하면 외래 키가 존재하는 곳이 주인이고, 외래 키가 없는 쪽이 주인이 아니기 때문에 외래 키가 없는 쪽에 mappedBy로 주인을 지정해주면 된다.

연관관계의 주인을 정할 때 비즈니스 로직을 기준으로 주인을 선택하면 안된다. 연관관계의 주인은 외래 키의 위치를 기준으로 정해야 한다.

연관관계의 주인은 연관관계를 갖는 두 객체 사이에서 제어를 할 수 있지만, 연관관계의 주인이 아니면 조회만 가능하다.

왜 연관관계의 주인을 지정해야 할까?

객체에서 양방향으로 매핑을 하게 되면 테이블과 매핑을 담당하는 JPA에 혼란을 주게 된다. 어떤 객체에서 수정을 할 때 외래 키를 수정할 지를 결정하기 어렵기 때문이다.

그래서 두 객체 간 연관관계의 주인을 정해서 명확하게 어떤 객체에서 수정을 할 때만 외래 키를 수정하겠다고 정하는 것이다.

연관관계 매핑에서 자주하는 실수

실수 1. mappedBy 미사용

주인이 아닌 쪽에 mappedBy로 주인을 정하지 않는 실수를 많이 한다.

Team team = new Team();
team.setName("teamA");
em.persist(team);

Member member = new Member();
member.setName("memberA");

// Team class에 List<Member> members = new ArrayList<>(); 가 있다고 가정
team.getMembers().add(member);

위 코드처럼 역방향만 연관관계를 설정했을 경우 member 객체에는 team의 id 값이 null로 들어갈 것이다.

실수 2. 순수 객체 상태를 고려하지 않음

데이터베이스에 외래 키가 있는 테이블을 수정하려면 연관관계의 주인만 변경하는 것이 맞지만, 객체의 관점에선 둘 다 변경해주는 것이 좋다. 두 참조를 사용하는 순수한 객체는 데이터 동기화가 필요하기 때문이다.

• 데이터 동기화 예시는 연관관계 편의 메서드 예시를 참고

양쪽 어느 곳이든지 데이터 동기화를 위한 코드를 작성해도 상관 없지만 양쪽 모두에 동기화 코드를 작성하는 것은 무한 루프에 걸릴 수도 있으니 한 쪽에만 작성하도록 한다. 해당 코드는 방향대로 작성하든지 역방향에서 작성하든지 상관 없다. (상황에 따라 변경)

또한 단순 setXxx 형식의 메서드 네이밍은 해당 로직이 중요하다는 인식을 주지 못하기 때문에 이름을 바꿔 주는 것이 좋다.

• ex) setTeam(Team team) -> changeTeam(Team team)

실수 3. 양방향 매핑 시 무한 루프

toString()이나 Lombok, JSON 생성 라이브러리 등을 생성했을 때 무한 루프에 걸릴 수 있다.

예시로 toString()을 생성했을 때를 보자.

@Override  
public String toString() {  
    return "Member{" +  
            "id=" + id +  
            ", name='" + name + '\'' +  
            ", team=" + team +  
            '}';  
}
---
@Override  
public String toString() {  
    return "Team{" +  
            "id=" + id +  
            ", name='" + name + '\'' +  
            ", members=" + members +  
            '}';  
}

각 toString()안에 있는 team과 members는 각 클래스의 toString()을 호출한다는 뜻이다. 결론적으로 양쪽에서 무한으로 toString()을 호출하게 돼서 StackOverflowError가 발생하게 된다.

Lombok이나 JSON 생성 라이브러리 또한 마찬가지로 양방향이 걸려 있으면 엔티티를 JSON으로 변환하는 순간 무한 루프에 빠져버릴 수 있다.

특히 컨트롤러에서 엔티티를 그대로 반환할 때 주의하도록 한다.

• 컨트롤러에서 엔티티를 그대로 반환했을 때 생길 수 있는 일
  • 무한 루프
    1. "Member JSON으로 반환
    2. 근데 Member 안에 Team이 있네?
    3. Team을 JSON으로 반환
    4. 근데 Team안에 Members가 있네?"
    5. 1 ~ 4 무한 반복
  • 엔티티의 변경
    • 엔티티를 API에 반환해버리면 나중에 그 엔티티를 변경하는 순간 API 스펙이 변경되는 것

해결 방법에는 Lombok 등의 라이브러리 사용 시 toString()은 사용하지 않도록 하고, 컨트롤러에선 엔티티 반환 대신 DTO 객체를 만들어서 반환하도록 하자.

References

• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

기본 키 매핑

기본 키 매핑 어노테이션에는 @Id와 @GeneratedValue가 있다.

기본 키 매핑 방법

기본 키 매핑 방법에는 개발자가 PK 값을 직접 할당하는 직접 할당과 원하는 키 생성 전략을 선택해서 데이터베이스가 자동으로 PK 매핑을 하는 자동 생성이 있다.

직접 할당

@Id만을 사용한다. 위에서 설명했던 것처럼 개발자가 직접 PK 값을 설정해서 저장하고 싶은 경우에 사용한다.

자동 생성

@Id와 @GeneratedValue를 사용한다. 이때 각 데이터베이스마다 PK 값을 자동 생성하는 전략이 다르기 때문에 몇몇 옵션을 가지고 있다.

자동 생성 전략

자동 생성 전략에는 IDENTITY, SEQUENCE, TABLE, AUTO가 있다.

IDENTITY 전략

• 기본 키 생성 방법을 데이터베이스에 위임하는 것이다.
  • 영속성 컨텍스트에서 데이터베이스로 sql을 넘길 때 id 값을 null로 넘긴다.
• 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용한다.
  • ex) MySQL - AUTO_INCREMENT

JPA는 보통 트랜잭션 커밋 시점에 insert sql을 실행한다. 하지만 IDENTITY 전략의 경우 데이터베이스에서 값을 설정하기 때문에 쿼리 실행 전까지 id 값이 null이 된다. 이 말은 영속성 컨텍스트의 1차 캐시에 저장할 수 없다는 말이 된다.

따라서 IDENTITY 전략의 경우 em.persist() 시점에 즉시 insert sql을 실행하고, JPA에서 내부적으로 해당 id 값을 데이터베이스에서 조회해서 가지고 온다. 그래서 영속성 컨텍스트에 저장이 된다.

결론적으로 데이터베이스에 insert하는 시점에 이 값을 바로 알 수 있다.

SEQUENCE 전략

• 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트이다.
• 주로 Oracle, PostgreSQL, DB2, H2 데이터베이스에서 사용한다.
• @SequenceGenerator와 함께 사용할 수 있다.

@SequenceGenerator 속성

• name
  • 실제 @Id 필드에서 참조할 이름
  • 필수로 입력해야 한다.
• sequenceName
  • 실제 데이터베이스에 생성되는 시퀀스 객체 이름
  • 기본 값은 hibernate_sequence이고, 각 테이블마다 시퀀스를 따로 관리할 수 있음
• allocationsSize
  • 데이터베이스에서 가져오는 시퀀스 호출에 증가하는 값의 크기 (성능 최적화)
    • 여러 웹 서버가 있어도 동시성 문제 없이 다양한 문제 해결 가능
    • 웹 서버를 내리는 시점에 가지고 있던 값이 날라간다.
  • 기본 값이 50이기 때문에 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야 한다.
• initialValue
  • DDL 생성 시에만 사용된다. DDL을 생성할 때 처음 시작하는 수를 지정
  • 기본 값은 1

SEQUENCE 전략 또한 IDENTITY 전략과 마찬가지로 id 값을 따로 설정하지 않는다. 하지만 IDENTITY 전략과는 다르게 flush가 바로 실행되지는 않는다.

대신 설정한 시퀀스에서 초기 값 또는 next_val의 값을 가져와서 해당 객체에 id 값을 넣은 뒤 영속성 컨텍스트에 저장한다.

결론적으로 PK 값만 얻어온 뒤에 실제로 flush는 커밋 직전에 수행되는 것이다.

[!info] SEQUENCE 전략의 최적화 SEQUENCE 전략을 사용하고 initialValue = 1, allocationsSize = 50 인 경우 데이터베이스에서 시퀀스를 보면 현재 값: -49, 증가: 50으로 되어있는 것을 알 수 있다.

그 이유는 보통 call next value를 한 번 호출해서 나온 값을 사용하는데, 처음 호출했을 때 1이 되기를 기대하기 때문이다. 이후 한번 더 호출을 해서 DB의 SEQ 값을 51로 맞추게 된다. (처음은 더미를 호출한 것이라고 생각)

SEQ 값을 51로 맞춘 이후부터는 DB에서 SEQ 값을 호출하지 않고, DB로부터 받아온 50개의 SEQ 값을 메모리에 캐싱받아 작동하게 된다. (메모리에서 작동한다는 말)

대신 51번을 만나는 순간 그 다음 50개를 확보해야 하기 때문에 call next value가 한번 호출된다.

값을 크게 잡아도 상관 없지만 웹 서버를 내리는 시점에 확보한 SEQ 값이 날라가기 때문에 그 숫자만큼 공백이 생기고, 다 사용하지 못하고 내려간 시점에서 낭비가 발생한 것이 되게 된다.

TABLE 전략

• 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
• 특정 데이터베이스에 의존적이지 않다.
  • 어느 데이터베이스에나 사용할 수 있다.
  • 성능 이슈가 존재한다.
• 해당 전략 사용 시 jpa-ddl-auto 설정이 되어있지 않다면 시퀀스 테이블 생성이 선행돼야 한다.
• @TableGenerator와 함께 사용할 수 있다.

@TableGenerator 속성

• name
  • 실제 @Id 필드에서 참조할 이름
  • 필수로 입력해야 한다.
• table
  • 시퀀스 생성 용 테이블 이름을 설정
• pkColumnName
  • 시퀀스 컬럼 이름을 설정
  • 기본 값은 sequence_name
• valueColumnName
  • 시퀀스 값 컬럼 이름을 설정
  • 기본값은 next_val
• pkColumnValue
  • 키로 사용할 값의 이름을 설정
  • 기본 값은 엔티티 이름
• initialValue
  • 초기 값, 마지막으로 생성된 값이 기준
  • 기본 값은 0
• allocationSize
  • 데이터베이스에서 가져오는 시퀀스 호출에 증가하는 값의 크기 (성능 최적화)
  • 기본 값이 50이기 때문에 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야 한다.
• catalog
  • 데이터베이스 catalog 이름
• scheme
  • 데이터베이스 scheme 이름
• uniqueConstraints (DDL)
  • 유니크 제약 조건을 지정할 수 있음

AUTO 전략

데이터베이스에 따라 자동으로 위의 3가지 전략 중 하나를 선택한다. 데이터베이스를 바꿔도 수정할 필요는 없지만 SEQUENCE나 TABLE의 경우 시퀀스나 키 테이블을 미리 생성해야 하는 것에 주의가 필요하다.

jpa-ddl-auto 설정이 되어있다면 hibernate가 알아서 생성해 준다.

권장하는 식별자 전략

기본 키 제약 조건에 대해서 생각을 먼저 해보는 것이 필요하다. 기본 키 제약 조건은 null이면 안되고, 변하면 안된다. (유일성)

하지만 이 조건을 만족하는 자연 키는 찾기 어렵기 때문에 대리 키(대체 키)를 사용하는 것이 좋다.

• 주민등록번호 역시 기본 키로는 적절하지 않다.
• 전화번호 역시 마찬가지

권장하는 값은 "Long 타입 + 대체 키 + 키 생성 전략 사용"이다. 이때 long 타입이 아니라 참조 타입인 Long인 것에 주의

• 데이터가 생성되는 시점에서 해당 값이 할당된다는 것이며, 도메인 객체의 id는 특정 시점에 존재할 수도 있고 존재하지 않을 수도 있다.
• 그렇기 때문에 long이 아닌 Long을 사용하며, 다만 이 변수가 not null 이 보장된다면 long을 사용하는 것이 더 좋다.

References

• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

필드와 컬럼 매핑

자세한 내용으로 들어가기에 앞서 간단하게 어떤 어노테이션이 있는지 알아보자

• @Column: 컬럼 매핑
• @Temporal: 날짜 타입 매핑
• @Enumurated: enum 타입 매핑
• @Lob: BLOB, CLOB 타입 매핑
• @Transient: 특정 필드를 컬럼과 매핑하지 않음
• @Access: JPA가 엔티티에 접근하는 방식 설정

@Column

엔티티의 필드를 테이블의 컬럼과 매핑한다.

속성

• name
  • 필드와 매핑할 테이블의 컬럼 이름
  • 기본 값은 객체의 필드 이름
• insertable/updatable
  • 등록/변경 가능 여부를 나타냄
  • false여도 데이터베이스에서 강제로 변경은 가능하지만 JPA를 쓸 때는 반영 안됨
  • 기본 값은 true
• nullable(DDL)
  • null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다.
• unique(DDL)
  • @Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약 조건을 걸 때 사용한다.
  • 하지만 컬럼에서 유니크 제약 조건을 거는 것은 그리 선호하지 않는 방법이다.
    • 제약조건의 이름이 무작위로 설정됨 -> uniqueConstraints는 이름 설정 가능
• columnDefinition(DDL)
  • 데이터베이스의 컬럼 정보를 직접 줄 수 있다. (자료형, 길이, 기본값 설정 가능)
    • varchar(100) default 'EMPTY'
  • 특정 데이터베이스의 종속적인 옵션들도 넣을 수 있다.
  • 기본 값은 필드의 자바 타입과 방언 정보를 사용
• length(DDL)
  • 문자 길이 제약조건, String 타입에만 사용한다.
  • 기본 값은 255
• precision/scale (DDL)
  • BigDecimal 타입에서 사용한다. (BigInteger도 사용할 수 있다)
  • 참고로 double, float 타입에는 적용되지 않는다.
  • precision은 소수점을 포함한 전체 자릿수를 정한다.
    • 기본 값은 19 (합쳐서 19개의 숫자)
  • scale은 소수의 자릿수를 정한다.
    • 기본 값은 2 (소수점 하위 2번째 자리)

@Enumurated

enum 타입을 매핑할 때 사용한다.

속성

@Enumurated의 기본 값은 EnumType.ORDINAL이다.

• EnumType.ORDINAL: enum의 순서대로 데이터베이스에 저장
  • 선언된 순서를 데이터베이스에 반영하여 저장한다.
  • USER, ADMIN으로 선언했을 경우
    • 0: USER
    • 1: ADMIN
• EnumType.STRING: enum의 이름을 문자열로 데이터베이스에 저장
  • 선언된 이름을 데이터베이스에 반영하여 저장한다.

주의

@Enumurated를 사용 시 옵션으로 ORDINAL을 사용하지 않도록 한다.

public enum RoleType {  
    USER, ADMIN  
}

처음엔 위의 방식으로 RoleType을 선언하고 있다가 나중에 GUEST라는 RoleType이 새로 생겼다고 가정해보자.

public enum RoleType {  
    GUEST, USER, ADMIN  
}

사람마다 다를 순 있겠지만 GUEST라는 값을 ADMIN 옆에 위치시키진 않을 것이다. 이렇게 새로운 RoleType을 선언한 뒤에 새로운 데이터가 들어온다면 기존에 데이터베이스에 있던 값은 어떻게 변할까?

간단하게 id, name, role_type을 컬럼으로 갖는 Member 테이블이 존재한다고 가정하고, 해당 테이블 안에 USER와 ADMIN을 RoleType으로 갖는 데이터가 각각 하나씩 존재한다고 했을 때 저장된 값은 다음과 같다.

GUEST 선언 전

Member member1 = new Member();  
member1.setId(1L);  
member1.setName("A");  
member1.setRoleType(RoleType.USER);  
em.persist(member1);  

Member member2 = new Member();  
member2.setId(2L);  
member2.setName("B");  
member2.setRoleType(RoleType.ADMIN);  
em.persist(member2);  

tx.commit();

GUEST 선언 후

Member member3 = new Member();  
member3.setId(3L);  
member3.setName("C");  
member3.setRoleType(RoleType.GUEST);  
em.persist(member3);  

tx.commit();

예시 코드와 결과를 보면 enum의 순서는 바뀌었지만 이미 저장된 데이터는 바뀌지 않아서 결국 어떤 역할을 가지고 있는지 알 수 없게 된다. 따라서 데이터 마이그레이션 등을 수행해야 하는 불상사가 생기게 된다.

비록 ORDINAL보다 데이터를 더 많이 차지하는 것은 STRING이지만 위험을 가지고 운영을 하는 것보단 STRING 방식으로 저장하는 것이 더 나은 선택이다.

@Temporal

아래의 날짜 타입을 매핑할 때 사용한다.

• java.util.Date
• java.util.Calendar

LocalDate 또는 LocalDateTime을 사용하는 경우 데이터베이스 저장 시 자동으로 date와 timestamp로 매핑되어 생성되기 때문에 굳이 @Temporal 어노테이션을 사용할 필요가 없다.

속성

• TemporalType.TIME: 시간을 데이터베이스 time 타입과 매핑
• TemporalType.TIMESTAMP: 날짜 + 시간을 데이터베이스 timestamp 타입과 매핑

@Lob

데이터베이스의 BLOB, CLOB 타입과 매핑할 때 사용한다.

@Lob은 따로 지정할 수 있는 속성이 없다. 매핑하는 필드가 문자면 CLOB으로 매핑하고 그렇지 않다면 BLOB으로 매핑한다.

• BLOB(Binary Large OBject)
  • 이진 데이터를 저장할 때 사용되며, 주로 이미지, 오디오, 비디오, 바이너리 데이터 등을 저장할 때 사용된다.
  • 자바 자료형으로 분류
    • byte[]
    • java.sql.BLOB
• CLOB(Character Large OBject)
  • 문자 기반의 큰 객체를 나타내며, 주로 텍스트 데이터를 저장할 떄 사용된다.
  • 자바 자료형으로 분류
    • String
    • char[]
    • java.sql.CLOB

@Transient

엔티티의 필드를 매핑하고 싶지 않을 때 사용하는 어노테이션이다. 저장 및 조회도 하지 않기 때문에 메모리에서 사용하고 버려지는 값으로 사용할 수 있다.

@Access

JPA가 엔티티 데이터에 접근하는 방식을 지정한다.

속성

• AccessType.FIELD
  • 필드에 직접 접근하며 private로 선언했더라도 접근이 가능하다.
  • @Id가 필드에서 선언되었을 경우 해당 접근 방식은 생략이 가능하다.
• AccessType.PROPERTY
  • 접근자(getter/setter)를 통해서 접근이 가능하다.
  • @Id가 프로퍼티에서 선언되었을 경우 해당 접근 방식은 생략 가능하다.

References

• https://www.inflearn.com/course/ORM-JPA-Basic

김영한님의 JPA 강의를 보고 정리한 내용입니다.

객체와 테이블 매핑

JPA에서 제일 중요하게 봐야 되는 두 가지 중 하나는 JPA가 내부적으로 어떤 매커니즘으로 동작하는지에 대한 매커니즘적인 측면과 객체와 관계형 데이터베이스를 어떻게 매핑을 해서 사용하는지에 대한 정적인 측면으로 나뉜다. 쉽게 말하면 영속성 컨텍스트와 엔티티 매핑의 두 가지로 나뉜다고 볼 수 있을 것 같다.

엔티티 매핑에는 다음과 같은 매핑 어노테이션이 있다.

• 객체와 테이블 매핑
  • @Entity
  • @Table
• 필드와 컬럼 매핑
  • @Column
• 기본 키 매핑
  • @Id
• 연관관계 매핑
  • @ManyToOne
  • @JoinColumn

@Entity

• @Entity가 붙은 클래스는 JPA가 관리하는 엔티티이다. 해당 어노테이션이 붙지 않으면 JPA와는 전혀 관계없는 그냥 내가 마음대로 쓰고 싶은 클래스라고 볼 수 있다.
• JPA를 사용해서 테이블과 매핑할 클래스는 @Entity가 필수이다.

주의

• 기본 생성자 필수 (파라미터가 없는 public 또는 protected 생성자)
• enum, interface, inner class, final class 사용 불가
• 저장할 필드에 final 사용 불가

속성

• name
  • JPA에서 사용할 엔티티의 이름을 지정한다. (JPA가 내부적으로 구분하는 이름)
  • 기본 값은 클래스의 이름을 그대로 사용하는 것이다.
  • 같은 클래스의 이름이 없으면 가급적 기본 값을 사용한다.

@Table

• @Table은 엔티티와 매핑할 테이블을 지정한다.

속성

• name
  • 매핑할 테이블의 이름을 설정
  • 기본 값은 엔티티의 이름을 그대로 사용하는 것
• catalog
  • 데이터베이스 catalog 매핑
• schema
  • 데이터베이스 schema 매핑
• uniqueConstraints
  • DDL 생성 시 유니크 제약 조건 생성

데이터베이스 스키마 자동 생성

• DDL을 애플리케이션 실행 시점에 자동 생성
  • 객체에서 매핑을 다 해놓으면 애플리케이션 사용할 때 필요하면 테이블을 다 만들어준다.
• 테이블 중심 -> 객체 중심
• 데이터베이스 방언을 통해 데이터베이스에 맞는 적절한 DDL을 생성해 준다.
• 이렇게 생성된 DDL은 개발 장비에서만 사용해야 한다.
• 생성된 DDL은 운영 서버에서는 사용하지 않거나, 적절히 다듬은 후 사용한다.

속성

persistence.xml 설정 파일에 hibernate.hbm2ddl.auto의 값으로 아래의 속성을 적용한다. application.properties에 설정할 경우 spring.jpa.hibernate.ddl-auto로 설정할 수 있다.

• create
  • 애플리케이션 생성 시 기존 테이블 삭제 후 다시 생성한다.
  • 애플리케이션 실행 -> drop -> create -> 애플리케이션 종료
• create-drop
  • create와 같으나 종료 시점에 테이블을 drop 한다.
  • 애플리케이션 실행 -> drop -> create -> drop -> 애플리케이션 종료
• update
  • 기존 내용은 유지한 채 변경되는 것만 반영한다. (운영 DB에는 사용하면 안됨)
    • 필드 추가 -> alter table ... add column ...
  • 단, 필드 삭제의 경우는 반영하지 않는다.
    • 필드 삭제 -> ... (반영 X)
• validate
  • 엔티티와 테이블이 정상 매핑되었는지만 확인한다.
  • 필드 추가 -> 실행 -> 에러 발생 (엔티티와 테이블의 매핑 정보가 다름)
• none (관례)
  • 사용하지 않는다.
  • value = "asdjfakjhdsfklj" 적는 것과 똑같지만 관례상 none으로 적는다.
    • 매칭되는 것이 없기 때문에 실행이 안되는 것

persistence.xml과 application.properties의 차이가 뭘까? persistence.xml은 JPA가 사용하는 설정 파일인 반면, application.properties은 스프링 부트가 사용하는 설정 파일이다. 하지만 persistence.xml을 따로 만들지 않고, application.properties에 설정해도 정상적으로 동작하는 이유는 스프링 부트가 내부에서 JPA를 만들 때 persistence.xml이 없어도 동작하도록 구현되어 있기 때문이다. 따라서 스프링과 JPA를 함께 사용한다면 application.properties을 사용하자.

주의

• 운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
• 개발 초기에는 create 또는 update
• 테스트 서버는 update 또는 validate
• 스테이징과 운영 서버는 none

결국 이런 웹 애플리케이션에서 사용하는 DBMS 계정은 alter나 drop을 못하도록 계정을 분리하는 것이 맞다.

DDL 생성 기능

데이터베이스 스키마 자동 생성과 다른 것이다. (내가 잘 몰랐던 내용이라 넣어봄)

• 제약 조건 추가: 회원 이름은 필수, 10자 제한
  • @Column(nullable = false, length = 10)
• 유니크 제약 조건 추가
  • @Table(uniqueConstraints = {@UniqueConstraint(name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"})})
  • @Column(unique = true)
• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다
  • JPA의 런타임 시 기능은 결국 DB와 연결하여 create, update, insert, delete 쿼리를 날리는 것과 관련있다.
  • 이런 점에서 봤을 때, @Table의 name 속성을 바꾸면 JPA는 해당 name에 있는 테이블명에 create, update, insert, delete 쿼리를 날리기 때문에 런타임 기능에 영향을 준다고 한 것 같다.
  • 반면에 @Column의 속성값의 경우 DDL 생성이 켜져있을 때, 처음 애플리케이션 실행 시에만 DDL에서 작동할 뿐, JPA의 기능을 활용하는 런타임에서는 사용하지 않는다는 의미인 것 같다.

References

• https://www.inflearn.com/course/ORM-JPA-Basic
• https://www.inflearn.com/community/questions/847958/16-25%EC%B4%88-%EB%B6%80%ED%84%B0%EC%9D%98-%EC%84%A4%EB%AA%85%EC%9D%B4-%EC%9D%B4%ED%95%B4%EA%B0%80-%EA%B0%80%EC%A7%80-%EC%95%8A%EC%8A%B5%EB%8B%88%EB%8B%A4
• https://www.inflearn.com/community/questions/273750/application-yml-vs-persistence-xml?srsltid=AfmBOop9zwKHgBbx7tgxmWI5RXoTHkkPqBn7dhwoaMUPVZAgmDakOeIP

김영한님의 JPA 강의를 보고 정리한 내용입니다.

Flush 란?

영속성 컨텍스트의 현재 변경 사항을 데이터베이스에 반영하는 행위를 말한다. 쉽게 말해, 영속성 컨텍스트에 쌓인 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송함으로써, 영속성 컨텍스트와 데이터베이스를 동기화하는 행위라고 할 수 있다.

이때 flush를 한다고 해서 영속성 컨텍스트를 비우는 것은 아니다. 1차 캐시와 쓰기 지연 SQL 저장소 모두 비워지지 않는다. 단순히 변경 내용을 데이터베이스에 동기화하는 작업일 뿐이다.

flush는 결국 트랜잭션이라는 개념이 있기 때문에 가능한 것이다. 쿼리를 따로 보내든지, 모아서 한번에 보내든지 커밋 직전에 동기화하면 되기 때문이다.

Flush 발생

• 변경 감지(Dirty Checking)가 일어난다.
• 수정된 엔티티를 쓰기 지연 SQL 저장소에 등록한다.
• 저장소 내의 쿼리를 데이터베이스에 전송한다.

이때 flush()가 발생한다고 해서 데이터베이스 트랜잭션이 커밋되는 것은 아니다. 단순히 저장소 안에 있는 쿼리들이 데이터베이스에 전송되는 것이지 실제로 반영되는 시점은 commit() 시점이다.

예시를 들자면 DBMS에서 트랜잭션을 사용할 때도 커밋이 되기 전까지는 실제로 데이터베이스에 반영되지 않는다. 그리고 커밋이 수행된 후에 실제 데이터베이스에 트랜잭션의 작업 내용이 반영 되는 것과 동일하다.

영속성 컨텍스트를 Flush 하는 방법

• em.flush() - 직접 호출
• 트랜잭션 커밋 - 자동 호출
• JPQL 쿼리 실행 - 자동 호출

Flush 모드 옵션

• em.setFlushMode(FlushModeType.AUTO)를 사용한다.
  • FlushModeType.AUTO: 커밋이나 쿼리를 실행할 때 flush 실행 (기본 값)
  • FlushModeType.COMMIT: 커밋할 때만 flush 실행

References

• https://www.inflearn.com/course/ORM-JPA-Basic

확실히 JDBC를 사용하다가 JPA를 사용하니 똑같은 쿼리를 작성해주지 않아도 돼서 상당히 편했다. 하지만 기능을 제대로 알고 있지 않을 경우 골치 아픈 일이 발생한다는 것을 다시 한 번 느끼게 되었다. 자세한 사항은 아래에 기술하였다.

단순 기능 구현 자체는 쉬워졌지만 어떻게 설계할 지 고민하는 시간이 늘어나는 것 같다. 심지어 검색을 해도 사람마다 생각하는 바가 달라서 정하기 쉽지 않았다.

또한 Git에 대한 공부를 더 해야할 것 같았다. 이번에 브랜치를 잘못 관리해서 PR을 올렸을 때 하나의 브랜치에 모든 정보가 다 섞여서 repo를 다시 만들어서 노가다를 하게 되었는데 다신 하고 싶지 않는 경험이었다.. (특히 팀 프로젝트에서 이런 실수를 했다고 생각하면..)

잡다한 내용

spring.jpa.open-in-view

설정을 안한다고 해서 문제 발생하진 않았던 것 같다. 하지만 매번 WARN이 나와서 이번에서야 검색을 하게 되었다.

spring.jpa.open-in-view를 따로 설정하지 않았다면 스프링 부트 애플리케이션 시작 시 아래와 같은 메세지가 뜬다.

[startup] [ ] 17:22:33.916 [main] WARN  o.s.b.a.o.j.JpaBaseConfiguration$JpaWebConfiguration - 
spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during 
view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning

이 메세지는 스프링 부트에선 spring.jpa.open-in-view를 true로 설정하고 있는데 이는 OSIV(Open Session In View) 측면에서 매우 부적절하다고 한다.

정말 간단히 말하면 Controller나 View에서도 지연로딩이 가능하게 만들어 주는 것이다. 즉, 영속성 컨텍스트의 생존 범위가 굉장히 넓어지는 것이다.

부적절하다고 하는 이유는 데이터베이스 커넥션 리소스를 사용하기 때문이다. Controller에서 외부 API를 호출하면 외부 API 대기 시간만큼 커넥션 리소스를 반환하지 못하게 돼서 트래픽이 많은 경우에는 꺼둔다고 한다.

하지만 OSIV를 false로 설정한 경우에도 단점은 존재한다. 우선 영속성 컨텍스트의 범위가 좁혀지기 때문에 모든 지연로딩을 트랜잭션 내부에서 처리해야 한다는 것이다. 트랜잭션이 끝난 뒤 지연로딩을 하려고 하면 LazyInitializationException 발생한다.

OSIV를 종료하는 방법은 spring.jpa.open-in-view 설정을 false로 바꿔주면 된다.

spring:
  jpa:
    open-in-view: false

간단한 애플리케이션이기 때문에 굳이 false로 설정할 필요는 없었지만, 트랜잭션 외부에서 지연로딩하는 코드가 없다고 판단하여 false 설정하였다.

OSIV와 Transactional, 영속성 컨텍스트에 대한 개념을 더 알아본 뒤 생각이 바뀌면 나중에 바꿀 예정이다.

데이터베이스 정보 환경 변수에 저장

이전 과제 피드백에 있던 내용이라 바로 적용했다. 하나 생각하지 못했던 것은 진짜 환경 변수에 저장하고 불러오려고 했다는 것이다. 뭔가 이상하다고 생각이 들어서 검색을 해봤고, 쉽게 방법을 찾을 수 있었다.

1. application.yml에 가져올 환경 변수 세팅

   spring:
    datasource:
      driver-class-name: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://localhost:${MYSQL_PORT}/${MYSQL_DB}
      username: ${MYSQL_USERNAME}
      password: ${MYSQL_PASSWORD}

   ${KEY}를 통해 환경 변수에 저장된 KEY에서 값을 가져온다.

2. 실행 -> 구성 편집 (Run -> Edit Configurations...)

   또는 애플리케이션 실행 버튼 옆의 이름이나 ...을 클릭

   

   

3. 스프링 부트 실행 클래스를 선택 -> 옵션 수정(Modify options) -> 환경 변수(Environment variables)

   

4. 환경 변수 추가

   이때 key1=value1;key2=value2;... 방식으로 직접 작성해도 되고, 아래처럼 해도 된다.

   

   

로그 필터 적용

필터를 사용하는 만큼 모든 요청과 응답에 대한 로그를 필터를 통해 찍어보고 싶었다.

Filter를 구현한 로그 필터 클래스를 만들고 doFilter를 구현했다. 로그인 필터에서도 동일한 값을 사용하기 위해 MDC.put()으로 값을 저장하고, chain.doFilter(request, response) 앞뒤에 로그를 찍어주었다.

응답 로그 이후엔 MDC.clear()를 통해 저장된 값을 초기화했다.

<?xml version="1.0" encoding="UTF-8" ?>

<configuration>

    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>[%X{request_id:-startup}] [%X{http_method} %X{request_uri}] %d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n</Pattern>
        </layout>
    </appender>

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

logback.xml을 만들어서 로그가 찍힐 때 패턴을 정의해줬다. 고유한 ID 값을 UUID를 통해 만들어서 넣고, HTTP Method와 Request URI 값을 확인할 수 있도록 구성했다.

Page Interface의 직렬화

일정 전체 조회에 페이징을 적용하고 있던 중 콘솔에 WARN 표시가 나왔다.

[2b441087-aae7-4098-94a2-ffc8d4b114c7] [GET /api/v1/schedules] 19:30:00.644 [http-nio-8080-exec-6] WARN  o.s.d.w.c.SpringDataJacksonConfiguration$PageModule$WarningLoggingModifier - Serializing PageImpl instances as-is is not supported, meaning that there is no guarantee about the stability of the resulting JSON structure!
    For a stable JSON structure, please use Spring Data's PagedModel (globally via @EnableSpringDataWebSupport(pageSerializationMode = VIA_DTO))
    or Spring HATEOAS and Spring Data's PagedResourcesAssembler as documented in https://docs.spring.io/spring-data/commons/reference/repositories/core-extensions.html#core.web.pageables.

번역하면 PageImpl 인스턴스를 있는 그대로 직렬화하는 것은 지원되지 않으므로 결과 JSON 구조의 안정성에 대해 보장할 수 없습니다! 라는 뜻인데 말로는 이해가 안될 수 있으니 여기에 있는 어노테이션을 적용시키기 전과 후의 결과 차이를 보면 다음과 같다.

// 적용시키기 전
{
    "status": "OK",
    "data": {
        "content": [
            {
                "scheduleId": 8,
                "title": "타이틀",
                "body": "본문",
                "createdDateTime": "2025-02-11T14:47:59.864844",
                "updatedDateTime": "2025-02-11T14:51:41.952323",
                "username": "tester",
                "commentCount": 0
            },
            // 결과들...
        ],
        "pageable": {
            "pageNumber": 0,
            "pageSize": 10,
            "sort": {
                "empty": false,
                "sorted": true,
                "unsorted": false
            },
            "offset": 0,
            "paged": true,
            "unpaged": false
        },
        "last": true,
        "totalPages": 1,
        "totalElements": 3,
        "first": true,
        "size": 10,
        "number": 0,
        "sort": {
            "empty": false,
            "sorted": true,
            "unsorted": false
        },
        "numberOfElements": 3,
        "empty": false
    },
    "message": "일정 전체 조회 성공",
    "timestamp": "2025-02-11T19:40:56.4995927"
}

// 적용시킨 후
{
    "status": "OK",
    "data": {
        "content": [
            {
                "scheduleId": 8,
                "title": "타이틀",
                "body": "본문",
                "createdDateTime": "2025-02-11T14:47:59.864844",
                "updatedDateTime": "2025-02-11T14:51:41.952323",
                "username": "tester",
                "commentCount": 0
            },
            // 결과들...
        ],
        "page": {
            "size": 10,
            "number": 0,
            "totalElements": 3,
            "totalPages": 1
        }
    },
    "message": "일정 전체 조회 성공",
    "timestamp": "2025-02-11T19:43:02.4308486"
}

확실히 더 깔끔해졌다. 또한 내부 JavaDoc을 보면 다음과 같이 나와있는 것을 확인할 수 있다.

해당 어노테이션을 사용하기 위해선 Spring 3.2 이상이 필요하다고 한다.

트러블 슈팅

@SQLRestriction 사용으로 인한 문제점

현재 각 엔티티에는 소프트 딜리트 방식을 손쉽게 구현 및 사용하기 위한 다음과 같은 어노테이션이 클래스에 정의되어 있다.

@SQLDelete(sql = "update users set deleted_date_time = current_timestamp where user_id = ?")
@SQLRestriction(value = "deleted_date_time is null")

예시로 유저가 삭제되면 실제로 삭제하는 것이 아니라 @SQLDelete 안의 sql을 실행해서 deleted_date_time 값에 current_timestamp를 찍어주고, 조회를 할 땐 deleted_date_time에 값이 없는 것만 필터링해서 가져올 수 있도록 해주는 것이다.

이후 Postman을 활용해서 테스트를 진행했고, 문제는 유저 탈퇴 이후 처음 알게 되었다.

회원가입, 일정 단건 조회 등등에서 다양한 예외가 발생했다.

[Exception]: Unable to find com.example.schedule.user.entity.User with id 1
[Exception]: could not execute statement [Duplicate entry 'tester@test.com' for key 'users.UK6dotkott2kjsp8vw4d0m25fb7'] [insert into users (created_date_time,deleted_date_time,email,password,updated_date_time,username) values (?,?,?,?,?,?)]; SQL [insert into users (created_date_time,deleted_date_time,email,password,updated_date_time,username) values (?,?,?,?,?,?)]; constraint [users.UK6dotkott2kjsp8vw4d0m25fb7]

ControllerAdvice에 정의한 Exception을 주석처리 한 뒤 다시 실행시켜 봤다.

jakarta.persistence.EntityNotFoundException: Unable to find com.example.schedule.user.entity.User with id 1
java.sql.SQLIntegrityConstraintViolationException: Duplicate entry 'tester@test.com' for key 'users.UK6dotkott2kjsp8vw4d0m25fb7'

하나는 엔티티를 찾을 수 없다고 나오고, 다른 하나는 unique 제약 조건을 걸었는데 값이 겹친다고 나온다.

중단점을 찍어서 자세히 확인해보면 엔티티를 찾을 수 없다고 한 경우엔 탈퇴한 유저가 작성한 일정을 단건 조회 등을 할 경우 발생했고, 정확히는 Schedule을 ScheduleDto로 매핑하는 도중 Schedule 엔티티에서 User 값을 getter로 가져오면서 발생했다.

회원가입의 경우엔 탈퇴한 유저와 같은 email 또는 username을 가지고 등록을 시도할 경우 발생했고, 정확히는 중복 체크 구문을 전부 문제 없이 통과하고, 새로운 User 엔티티를 생성한 뒤에 데이터베이스에 저장 시도할 때 예외가 발생했다.

@SQLRestriction 의 문제라고 생각이 들어서 제거하고, 서비스에서 필요한 로직에 따라서 deleted_date_time 값에 따라 처리할 수 있도록 바꾸면 해결될 것이라 생각했다.

deleted_date_time 필요 여부에 따라서 JPQL을 직접 만들었다. existsXxx의 경우엔 회원가입 등에서 탈퇴한 유저의 정보까지 비교할 수 있도록 deleted_date_time까지 확인하도록 했다.

그리고 정상적으로 원하는 예외를 발생시킬 수 있게 되었다.

// 탈퇴한 유저의 이메일이나 사용자명과 중복될 경우 바꾸기 전까진 Exception에 핸들링 되었음
{
    "status": "CONFLICT",
    "errorDetails": [
        {
            "field": "email",
            "message": "중복된 이메일입니다.",
            "code": "DUPLICATED"
        },
        {
            "field": "username",
            "message": "중복된 사용자명입니다.",
            "code": "DUPLICATED"
        }
    ],
    "timestamp": "2025-02-11T15:45:38.3245642"
}

// 일정이 탈퇴한 유저와 연결되어 있는 경우 바꾸기 전까진 Exception에 핸들링 되었음
{
    "status": "NOT_FOUND",
    "errorDetails": [
        {
            "field": null,
            "message": "요청에 해당하는 일정을 찾을 수 없습니다.",
            "code": "NOT_FOUND"
        }
    ],
    "timestamp": "2025-02-11T14:48:52.9056308"
}

JSON 직렬화 문제

LoginFilter에서 세션의 값을 확인하고, 없을 경우 바로 예외를 던져서 처리하고자 했다. 하지만 간과하지 못한 사실이 하나 있었다.

바로 Filter의 위치이다. Filter는 WAS 단에서 확인하기 때문에 예외가 발생해도 Spring Context 바깥에서 발생한 예외이기 때문에 정상적으로 처리할 수 없었다. 하지만 try-catch를 통해 바로 응답을 내려줄 수 있었다.

현재 응답 실패에 대한 공통 응답 클래스를 사용하고 있기 때문에 필터에서 내리는 응답도 마찬가지로 구조를 맞춰서 응답을 하려고 했다.

처음 생각한 방식은 무식하게 전부 적어주는 것이었다. 어차피 발생하는 예외는 응답 실패 시간을 제외하면 항상 동일하기 때문에 가장 먼저 생각하게 되었다. 하지만 JSON 응답 구조를 하나하나 만드는 것은 너무 비효율적이라고 생각이 들어 검색을 했고, ObjectMapper를 통해 객체를 JSON 문자열로 바꿀 수 있다고 보게 되었다.

그래서 바로 적용한 뒤에 테스트를 돌려보니...

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Java 8 date/time type `java.time.LocalDateTime` not supported by default: add Module "com.fasterxml.jackson.datatype:jackson-datatype-jsr310" to enable handling (through reference chain: com.example.schedule.global.common.response.ErrorResponse["timestamp"])

생각하지도 못한 예외가 발생했다. 해당 예외를 번역하면 Java 8 날짜/시간 유형 java.time.LocalDateTime이 기본적으로 지원되지 않음: "com.fasterxml.jackson.datatype:jackson-datatype-jsr310" 모듈을 추가하여 처리를 활성화합니다. 라는 의미였다. 해결하기 위해서 여러 곳을 확인하고 추가해봤지만 유의미한 결과를 보인 방법은 다음과 같이 ObjectMapper에 추가 설정을 하는 방법이었다.

ObjectMapper 객체를 생성하고, objectMapper.registerModule(new JavaTimeModule()).disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);을 설정해서 날짜 및 시간 클래스(LocalDate, LocalDateTime 등)를 직렬화/역직렬화할 수 있도록 지원하는 모듈을 등록하고, JSON으로 출력되는 날짜 정보를 표준화된 문자열 포맷으로 제공할 수 있게 SerializationFeature.WRITE_DATES_AS_TIMESTAMPS를 disable 처리해주는 것으로 해결했다.

{
    "status": "UNAUTHORIZED",
    "errorDetails": [
        {
            "field": null,
            "message": "로그인이 필요한 서비스입니다. 로그인을 해주세요.",
            "code": "UN_AUTHORIZED"
        }
    ],
    "timestamp": "2025-02-11T16:46:28.7494056"
}

ObjectMapper의 사용 방법이 바뀐다고 하는데 정확한 사용 방법을 몰라서 현재 작성일 기준 사용할 수 있는 코드를 우선 사용했다.

JSON 직렬화 시 동일 필드 직렬화

응답 실패에 대한 공통 응답 클래스에 필드로 위치하는 ErrorDetail 클래스에서 JSON 직렬화 시 응답 필드를 동일하게 설정하기 위해서 @JsonProperty(value = "code")를 통해 동일한 이름으로 설정했다.

하지만 테스트를 실행해보니...

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Conflicting getter definitions for property "code": com.example.schedule.global.common.exception.ErrorDetail#getCode() vs com.example.schedule.global.common.exception.ErrorDetail#getErrorCode() (through reference chain: com.example.schedule.global.common.response.ErrorResponse["errorDetails"]->java.util.ImmutableCollections$List12[0])

또 다른 예외가 날 반겨주었다. 간단한 설명을 하자면 code 값에 대한 getter의 충돌로 인해 문제가 생겼다는 의미이다. 그리고 JSON은 직렬화 시 접근 제한자에 따라서 직렬화하는 방식이 다른데 private의 경우 getter를 통해 직렬화를 하게 된다는 사실을 알게 되었다.

그래서 위의 코드에서 명시적으로 getter를 하나 설정해줬다.

@JsonProperty("code")
public String getSerializedCode() {
    return code != null
        ? code : (errorCode != null ? errorCode.name() : null);
}

이렇게 되면 직렬화 시 getter 메서드가 우선적으로 사용되기 때문에 위의 메서드를 호출하여 JSON의 code 프로퍼티 값을 생성하게 된다. 따라서 이름을 똑같게 만들어도 접근 제한자 상에서 우위를 가지는 public에 우선적으로 사용되게 되어서 정상적으로 결과를 응답할 수 있게 되는 것이다.

References

• https://docs.spring.io/spring-data/commons/reference/repositories/core-extensions.html#core.web.page.config ([Spring] Page Interface의 직렬화)
• https://gony-dev.tistory.com/33 ([Spring] Page Interface의 직렬화)
  
• https://minoolian.github.io/tech/Objectmapper-serialize.html (LocalDateTime Json 직렬화 시 문제)
• https://pjh3749.tistory.com/281 (Jackson 라이브러리 기본 기능 정리)
  
• https://velog.io/@hyunsoo730/spring-Data-JPA-%ED%8E%98%EC%9D%B4%EC%A7%95-%EC%A0%81%EC%9A%A9 (JPA 페이징 적용)
  
• https://www.inflearn.com/community/questions/137740/orphanremoval%EA%B3%BC-cascade%EC%9D%98-%EA%B4%80%EA%B3%84?srsltid=AfmBOoqYLsqNiuJzj99m3XKubSw3Bb1TXPtqxk6jZvBy4OFlP2M51lK1 (orphanRemoval과 cascade의 관계)
  
• https://beaniejoy.tistory.com/96 (filter 관련)
  
• https://mangkyu.tistory.com/266 (logback mdc 관련 정보)
• https://logback.qos.ch/manual/mdc.html (logback mdc 관련 정보)
• https://github.com/qos-ch/logback/blob/master/logback-examples/src/main/resources/chapters/mdc/simpleMDC.xml (logback mdc 관련 정보)
  
• https://mchch.tistory.com/282 (database 정보 환경 변수에 저장하기)
  
• https://mand2.github.io/spring/spring-boot/1/ (spring.jpa.open-in-view 로그 오류 해결하기)
• https://stackoverflow.com/questions/30549489/what-is-this-spring-jpa-open-in-view-true-property-in-spring-boot (spring.jpa.open-in-view 로그 오류 해결하기)
• https://hstory0208.tistory.com/entry/SpringJPA-OSIV-%EC%A0%84%EB%9E%B5%EC%9D%B4%EB%9E%80-%EC%96%B8%EC%A0%9C-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C (OSIV 전략이란 언제 사용해야 할까)

김영한님의 JPA 강의를 보고 정리한 내용입니다.

영속성 컨텍스트란?

• JPA를 이해하는데 가장 중요한 용어
• "엔티티를 영구 저장하는 환경"이라는 뜻
• EntityManager.persist(entity)로 객체를 영속화한다.
• DB에 저장한다는 것이 아니라 영속성 컨텍스트를 통해서 엔티티를 영속성화 한다는 뜻
  • 엔티티를 영속성 컨텍스트라는 곳에 저장한다는 말
• EntityManager 안에 영속성 컨텍스트라는 눈에 보이지 않는 어떤 공간이 생긴다고 이해하면 됨

EntityManagerFactory / EntityManager

EntityManagerFactory 특징

1. 생성 비용이 크다
2. 생성 비용이 크기 때문에 데이터베이스당 하나만 만들어서 쓰레드간 공유한다.
3. Thread-safe 하다

EntityManager 특징

1. persist(), find(), remove() 등을 사용해 Entity를 관리한다.
2. Thread-safe 하지 않다.
3. 생성 시 데이터베이스 연결이 꼭 필요한 시점까지 커넥션을 얻지 않는다.

엔티티의 생명 주기

• 비영속 (new/transient): 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
• 영속 (managed): 영속성 컨텍스트에 관리되는 상태
• 준영속 (detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제 (removed): 삭제된 상태

비영속

JPA와 전혀 관계없는 상태일 때 비영속 상태라고 한다. 아래 코드는 객체를 생성만 했을 뿐 JPA와는 전혀 관련없다(=객체를 생성한 상태).

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId(100L);
member.setName("member1");

영속

객체를 생성한 후 EntityManager.persist()에 객체를 저장한 상태를 말한다.

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId(100L);
member.setName("member1");

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

// 객체를 저장한 상태 (영속)
em.persist(member);

이때 em.persist()의 경우에만 영속이 되는 것이 아니라, em.find()를 했을 때 1차 캐시에 없는 데이터를 찾아서 1차 캐시에 해당 정보가 저장된 경우도 영속 상태가 된다.

준영속 / 삭제

준영속 상태

• 영속 상태의 엔티티가 영속성 컨텍스트에서 분리(detached)된 것이다. 한마디로 그냥 다 빼버리는 것이다.
• 준영속 상태의 경우 영속성 컨텍스트가 제공하는 기능을 사용 못한다.

Member findMember = em.find(Member.class, 101L);  // ID = 101L 객체가 영속 상태로 변경
findMember.setName("ASDF");  // 더티 체킹으로 update 쿼리가 날라갈 예정
em.detach(findMember);  // 이었으나 준영속 상태로 변경 (JPA에서 관리 안함)

tx.commit();  // select 문만 전송되고 update 문은 전송되지 않음

준영속 상태로 만드는 방법

• em.detach() - 특정 엔티티만 준영속 상태로 전환
• em.clear() - 영속성 컨텍스트를 완전히 초기화
• em.close() - 영속성 컨텍스트 종료

삭제의 경우

• 커밋이 되지 않은 영속 객체를 삭제할 경우 준영속과 같은 상태가 된다.
• 이미 데이터베이스에 저장된 객체를 찾아서 삭제할 경우 해당 데이터가 삭제된다.

// 객체를 생성한 상태 (비영속)
Member member = new Member();
member.setId(100L);
member.setName("member1");

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

// 객체를 저장한 상태 (영속)
em.persist(member);

// 객체를 영속성 컨텍스트에서 분리한 상태 (준영속)
em.detach(member);

// 객체를 삭제한 상태 (삭제)
Member findMember = em.find(Member.class, 1L);
em.remove(findMember);

영속성 컨텍스트의 이점

1차 캐시

• 1차 캐시는 영속 상태의 엔티티가 실제로 저장되는 곳이다
• 메모리에 Map<ID, Entity>의 형태로 존재한다고 생각
• 객체 생성 후 영속화하면 1차 캐시에 저장된다.
• 이때 객체를 조회할 경우 데이터베이스를 조회하기 전 1차 캐시 먼저 조회를 한다.
• 1차 캐시에 없을 경우 데이터베이스에 조회 후 1차 캐시에 저장한 뒤 해당 객체를 반환한다.

결론: 1차 캐시를 통해 성능상 이점을 가진다.

동일성(Identity) 보장

• 동일성(Identity): 실제 인스턴스의 참조 값이 같다. (==)
• 동등성(Equality): 실제 값이 같다. (equals)

결론: (같은 트랜잭션 내에서) 같은 식별자에 대한 객체 조회는 동일성을 보장해준다.

트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)

• 여러 데이터를 저장한다는 가정 하에 EntityManager는 쓰기 지연 SQL 저장소에 insert sql을 쌓아둔다.
  • 이때 저장소의 크기는 <property name="hibernate.jdbc.batch_size" value="10"/>로 지정할 수 있다.
  • 지정한 value 마다 insert query가 실행된다.
  • batch-size에 대한 제한이 없으면 OutOfMemoryException이 발생할 수도 있고, 메모 관리 측면에서도 효율적이지 않다.
  • 자세한 사항은 여기를 참조
• 이후 커밋 시점에 비로소 모든 쿼리를 데이터베이스에 보내게 된다. (flush)
• (문제가 없다면) 커밋이 정상적으로 수행된다.

결론: 영속 시점에 쿼리를 바로 데이터베이스에 보내는 것이 아니라 커밋 직전까지 쓰기 지연 SQL 저장소에 모아둔 뒤 한번에 보내기 때문에 성능상 이점이 있다.

변경 감지 (Dirty Checking)

• 객체 수정 시 별도의 메서드 없이 객체를 수정할 수 있는 이유이다.
  1. JPA는 객체를 영속성 컨텍스트에 보관 시 스냅샷을 만들게 된다. (백업 데이터 같은 느낌)
  2. flush() 시점에 스냅샷과 객체를 비교해서 변경된 객체를 찾는다. 이때 영속성 컨텍스트 안에 있는 객체만 변경 감지 기능의 대상이 된다.
  3. 변경된 객체가 존재할 경우, 수정 쿼리를 쓰기 지연 SQL 저장소에 저장한다.
  4. 커밋 시점에 저장소 안에 있는 sql을 데이터베이스에 보낸다. (flush() 끝)
  5. (문제가 없을 경우) 트랜잭션이 정상적으로 종료(커밋)된다.

지연 로딩 (Lazy Loading)

이후 추가 예정

References

• https://www.inflearn.com/course/ORM-JPA-Basic
• https://cheese10yun.github.io/jpa-batch-insert/#jpa-with-batch-insert-code-1

김영한님의 JPA 강의를 보고 정리한 내용입니다.

SQL 중심적인 개발의 문제점

SQL 중심적인 개발에는 여러 문제점이 있다.

1. 무한 반복, 지루한 코드

• CRUD 쿼리 무한 반복. 객체에 필드가 추가되면 쿼리에 변경점을 하드 코딩해줘야 한다.

2. 패러다임의 불일치

• 객체 지향의 목표와 RDB의 패러다임에 차이 때문에 문제가 생긴다.
  • 객체 지향: 추상화, 캡슐화, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공
  • RDB: 데이터를 중심으로 구조화되어 있음. (다양한 도구가 존재하지 않음)
• RDB가 인식할 수 있는 것은 SQL. 결국 객체를 SQL로 짜야 한다.
  • 객체 -> SQL 매핑 작업 -> RDB 저장
  • 위의 매핑 작업을 할 수 있는 것은 개발자 뿐. 개발자 == SQL Mapper라고 할 정도

3. 객체와 RDB의 차이

상속

객체에는 상속 관계가 있지만 RDB에는 상속 관계가 없다. 대신 상속 관계와 유사한 모델인 슈퍼타입/서브타입이 존재한다.

album을 DB에 저장한다고 하면 item 테이블 삽입 sql, album 테이블 삽입 sql 총 2개를 작성해야 한다. album을 조회한다고 해도 join으로 album과 item 테이블을 조회해서 나온 결과 값을 일일이 각 객체의 필드 값에 넣어줘야 한다.

이는 개발자가 실수할 가능성을 높이게 되고, 생산성의 저하로 이어지게 된다.

하지만 자바 컬렉션을 사용하듯이 사용하게 된다면 훨씬 편하게 사용할 수 있을 것이다.

list.add(album);  // 저장

Album album = list.get(album.getId());  // 조회

Item item = list.get(album.getId());  // 다형성 활용

연관 관계

Member 객체는 Member.team 필드에 Team 객체의 참조를 보관해서 Team 객체와 관계를 맺는다. 이 참조 필드에 접근해 Member와 연관된 Team을 조회할 수 있다.

반면 MEMBER 테이블은 MEMBER_ID 외래 키 컬럼을 사용해서 TEAM과 관계를 맺는다.  이 외래키를 사용해 TEAM 테이블과 조인하면 MEMBER 테이블과 연관된 TEAM 테이블을 조회할 수 있다.

여기서 발생하는 문제는 객체의 참조 방향이다. 객체 연관 관계의 경우 member.getTeam으로 참조 가능하지만 반대로 Team.getMember()는 불가능하다. 반면 테이블은 어느 쪽에서든 조인을 사용할 수 있다.

4. 모델링에서의 문제

객체는 참조를 통해 관계를 맺는다.

class Member {
    Long memberId;
    Team team;
    String name;

    ...
}

class Team {
    Long teamId;
    String name;

    ...
}

그런데 위 코드처럼 객체 모델을 사용하면 테이블에 저장하거나 조회하기 쉽지 않다. 객체 모델을 Team 객체로 DB는 Team을 team_id로 저장하기 때문이다. 이런 차이가 있어 개발자가 중간에서 변환 역할을 해야 한다.

Member member = new Member();
member.setName("memberA");
...  // 추가적인 회원 관련 정보 추가

Team team = new Team();
team.setName("teamA");
...  // 추가적인 팀 관련 정보 추가

member.setTeam(team);  // 회원과 팀 관계 설정

이런 과정은 모두 패러다임 불일치를 해결하기 위해 소모되는 비용이다.

5. 객체 그래프 탐색

객체에서 회원이 소속된 팀을 조회할 때 다음처럼 참조해서 사용하면 연괸된 팀을 찾을 수 있다. 이것을 객체 그래프 탐색이라고 한다.

Team team = member.getTeam();

member.getOrder().getOrderItem();

객체는 마음대로 객체 그래프를 탐색할 수 있어야 한다. 그런데 DB에서는 객체를 조회할 때 Tember와 Team의 데이터만 조회했다면 member.getOrder()의 값은 null이 된다.

SQL을 직접 다루면 처음 실행하는 SQL문에 따라 객체 그래프의 탐색이 한정된다. 이는 개발자에겐 큰 제약이며, 비즈니스 로직에 따라 사용하는 객체 그래프가 다른데 언제 끊어질 지 모를 객체 그래프를 함부로 탐색할 순 없다.

6. 객체 비교에서 차이

DB는 기본 키의 값으로 각 행을 구분한다. 반면, 객체는 동일성 비교와 동등성 비교의 두 가지 방법이 있다.

public Member getMember(Long memberId) {
    String sql = "select * from Member where member_id = ?";
    ...
    // JDBC API, SQL 실행
    return new Member(...);
}

Long memberId = 100L;
Member member1 = member.getMember(memberId);
Member member2 = member.getMember(memberId);

member1 == member2  // false

같은 sql, 같은 member_id로 조회했는데도 두 객체가 동일하지 않다. 그 이유는 내용은 같지만 new를 사용해서 새로운 인스턴스로 만들었기 때문이다. 만약 객체를 컬렉션에 보관했다면 동일성 비교에 성공했을 것이다.

이런 패러다임 불일치를 해결하기 위해 같은 row를 조회할 때마다 같은 인스턴스를 반환하도록 구현하는 것은 쉽지 않다. 여기에 트랜잭션이 동시에 실행되는 상황까지 고려하면 문제는 더 어려워질 것이다.

References

• https://www.inflearn.com/course/ORM-JPA-Basic

Bean Validation 개요

Bean Validation은 특정한 구현체가 아니라 Bean Validation 2.0(JSR-380)이라는 기술 표준이다. 쉽게 말하면 검증 어노테이션과 여러 인터페이스의 모음이며 마치 JPA 기술 표준이고 그 구현체로 하이버네이트가 있는 것과 같다.

Bean Validaion을 구현한 기술 중에 일반적으로 사용하는 구현체는 하이버네이트 Validator이다. 이름에 하이버네이트가 붙었지만 ORM과는 관련없다.

하이버네이트 Validator 관련 링크 공식 사이트: http://hibernate.org/validator/ 공식 메뉴얼: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/ 검증 어노테이션 모음: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/#validator-defineconstraints-spec

의존 관계 추가

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

참고 jakarta.validation.constraints.NotNull org.hibernate.validator.constraints.Range

jakarta.validation으로 시작하면 특정 구현에 관계없이 제공되는 표준 인터페이스이고, org.hibernate.validator로 시작하면 하이버네이트 validator 구현체를 사용할 때만 제공되는 검증 기능이다. 실무에서 대부분 하이버네이트 validator를 사용하므로 자유롭게 사용 가능하다.

동작 원리

@Valid

@Valid의 경우 ArgumentResolver에 의해 처리된다.

대표적으로 @RequestBody에서 JSON 메시지를 객체로 변환해주는 작업을 ArgumentResolver의 구현체인 RequestResponseBodyMethodProcessor가 처리하며 이 내부에 @Valid로 시작하는 어노테이션이 있을 경우에 유효성 검사를 진행한다.

@ModelAttribute의 경우엔 ModelAttributeMethodProcessor에 의해 @Valid가 처리된다.

그리고 검증에 오류가 있다면 MethodArgumentNotValidException 예외가 발생하게 된다.

@Valid는 기본적으로 Controller에서만 동작하며 기본적으로 다른 계층에서는 검증이 되지 않는다.

@Validated

입력 파라미터의 유효성 검증은 컨트롤러에서 최대한 처리하고 넘겨주는 것이 좋다. 하지만 개발을 하다보면 불가피하게 다른 곳에서 파라미터를 검증해야 할 수 있다.

이를 위해 Spring에서는 AOP 기반으로 메서드의 요청을 가로채서 유효성 검증을 진행해주는 @Validated를 제공하고 있다. @Validated는 JSR 표준 기술이 아니며 Spring Framework에서 제공하는 어노테이션 및 기능이다.

클래스에 @Validated를 붙여주고, 유효성을 검증할 메서드의 파라미터에 @Valid를 붙여주면 된다.

@Service
@Validated
public class ItemService {
    public void saveItem(@Valid SaveItemRequest request) {
        ...
    }
}

유효성 검증에 실패하면 ConstraintViolationException이 발생한다. @Validated는 AOP 기반으로 메서드 요청을 인터셉터하여 처리된다. @Validated를 클래스 레벨에 선언하면 해당 클래스에 유효성 검증을 위한 AOP의 어드바이스 또는 인터셉터(MethodValidationInterceptor)가 등록된다.

따라서 @Validated를 사용하면 계층에 무관하게 Spring Bean이라면 유효성 검증을 진행할 수 있다.

Spring Boot 3.2 이후

스프링 부트 3.2(Spring Framework 6.1)부터 Spring MVC와 WebFlux에서 유효성 검사를 위한 @Constraint 관련 어노테이션을 기본적으로 지원하도록 개선되었다. 컨트롤러를 위한 파라미터를 생성하는 ArgumentResolver들이 모두 동작하고, 컨트롤러의 메서드 호출이 준비되었을 때 유효성 검사가 진행된다. 스프링은 이를 MethodValidator라고 부른다.

스프링의 MethodValidator 관련 기능을 활용하기 위해서는 다음의 조건들이 충족되면 된다.

1. 컨트롤러에 @Validated를 통한 AOP 기반 검증이 존재하지 않음
2. LocalValidatorFactoryBean과 같은 jakarta.validation.Validator 타입의 빈이 등록됨
3. 메서드 파라미터 유효성 검증 어노테이션이 붙어있음

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello(@RequestParam @Length(min = 1) String name) {
        ...
    }
}

이를 통해 기존에는 불가능했던 방식으로도 동작이 가능해진다. 왜냐하면 파라미터가 모두 준비된 이후에 파라미터에 붙어있는 유효성 검사 어노테이션을 파싱하여 유효성 검사를 진행하기 때문이다.

스프링 통합 전

검증기 생성

ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();

위 코드와 같이 검증기를 생성한다. 이후 스프링과 통합하면 직접 코드를 작성하지 않기 때문에 '이렇게 사용하는구나' 정도만 참고하자.

검증 실행

Set<ConstraintViolation<Item>> violations = validator.validate(item);

검증 대상(item)을 직접 검증기에 넣고 그 결과를 받는다. Set에는 ConstraintViolation이라는 검증 오류가 담긴다. 따라서 결과가 비어있으면 검증 오류가 없는 것이다.

스프링 통합 후

스프링 MVC는 어떻게 Bean Validator를 사용할까?

스프링 부트가 spring-boot-starter-validation 라이브러리를 넣으면 자동으로 BeanValidation를 인지하고 스프링에 통합한다.

LocalValidatorFactoryBean을 글로벌 Validator로 등록한다. 이 Validator는 @NotNull 같은 어노테이션을 보고 검증을 수행한다. 이렇게 글로벌 Validator가 적용되어 있기 때문에 @Valid, @Validated만 적용하면 된다. 만약 검증 오류가 발생하면 FieldError, ObjectError를 생성해서 BindingResult에 담아준다.

검증 순서

1. @ModelAttribute 각각의 필드에 타입 변환 시도
   1. 성공하면 다음으로
   2. 실패하면 typeMismatch로 FieldError 추가
2. Validator 적용

BeanValidator는 바인딩에 실패한 필드는 BeanValidation을 적용하지 않는다. 타입 변환에 성공해서 바인딩에 성공한 필드여야 BeanValidation 적용이 의미가 있기 때문이다.

주의 글로벌 Validator를 직접 등록하면 스프링 부트는 BeanValidator를 글로벌 Validator로 등록하지 않는다.

에러 코드

메시지 등록

BeanValidation이 기본으로 제공하는 오류 메시지를 좀 더 자세히 변경하고 싶으면 메시지를 등록하면 된다.

# errors.properties
NotBlank={0} 공백 X
Range={0}, {2} ~ {1} 허용
Max={0}, 최대 {1}

{0}은 필드명이고, {1}, {2}는 각 어노테이션 마다 다르다.

BeanValidation 메시지 찾는 순서

1. 생성된 메시지 코드 순서대로 messageSource에서 메시지 찾기
2. 어노테이션의 message 속성 사용
   • @NotBlank(message = "{0}은 공백일 수 없습니다.")
3. 라이브러리가 제공하는 기본 값 사용
   • 공백일 수 없습니다.

오브젝트 오류

BeanValidation에서 특정 필드가 아닌 해당 오브젝트 관련 오류는 @ScriptAssert()를 사용할 수도 있다.

@Data
@ScriptAssert(
    lang = "javascript", script = "this.price * this.quantity >= 10000"
)
public class Item {
    ...
}

하지만 실제로 사용해보면 제약이 많고 복잡하며 실무에서는 검증 기능이 해당 객체의 범위를 넘어서는 경우들도 종종 등장할 때 대응이 어렵기 때문에 오브젝트 오류(글로벌 오류)의 경우 @ScriptAssert를 억지로 사용하는 것보다 오브젝트 오류 관련 부분만 자바 코드로 작성하는 것을 권장한다.

HTTP 메시지 컨버터

@Valid, @Validated는 HttpMessageConverter(@RequestBody)에도 적용할 수 있다.

API의 경우 3가지 경우를 나누어 생각해야 한다.

• 성공 요청
• 실패 요청: JSON을 객체로 생성하는 것 자체가 실패함
• 검증 오류 요청: JSON을 객체로 생성하는 것은 성공했지만, 검증에서 실패함

참고 @ModelAttribute는 HTTP 요청 파라미터(URL, 쿼리 스트링, POST Form)를 다룰 때 사용한다. @RequestBody는 HTTP Body의 데이터를 객체로 변환할 때 사용한다. 주로 API JSON 요청을 다룰 때 사용한다.

References

• 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술
• https://mangkyu.tistory.com/174
• https://mangkyu.tistory.com/379

Spring에서 기본적으로 제공되는 검증 오류를 보관하는 객체로 주로 사용자 입력 폼을 검증할 때 많이 쓰이고 FieldError와 ObjectError를 보관한다.

BindingResult docs 바인딩 결과를 나타내는 일반 인터페이스.

오류 등록 기능을 위해 오류 인터페이스를 확장하여 유효성 검사기를 적용할 수 있도록 하고 바인딩별 분석 및 모델 구축을 추가합니다.

DataBinder.getBindingResult() 메서드를 통해 얻은 DataBinder의 결과 홀더 역할을 합니다. 예를 들어 단위 테스트의 일부로 유효성 검사기를 호출하는 등 BindingResult 구현을 직접 사용할 수도 있습니다.

BindingResult는 인터페이스이고, Errors 인터페이스를 상속받고 있다. 실제 넘어오는 구현체는 BeanPropertyBindingResult 라는 것인데, Errors와 BindingResult를 모두 구현하고 있기 때문에 Errors를 사용해도 되지만 BindingResult는 추가 기능들을 제공하기 때문에 BindingResult를 많이 사용한다.

BindingResult가 있으면 @ModelAttribute에 데이터 바인딩 시 오류가 발생해도 컨트롤러가 호출된다.

컨트롤러에서 BindingResult는 검증해야 할 객체인 target 바로 다음에 온다. 따라서 BindingResult는 이미 본인이 검증해야 할 객체인 target을 알고 있다.

@ModelAttribute에 바인딩 시 타입 오류가 발생하면?

1. BindingResult가 있을 경우: 오류 정보(FieldError)를 BindingResult에 담아서 컨트롤러를 정상 호출한다.
2. 400 오류가 발생하면서 컨트롤러가 호출되지 않고, 오류 페이지로 이동한다.

BindingResult에 검증 오류를 적용하는 3가지 방법

1. @ModelAttribute의 객체에 타입 오류 등으로 바인딩이 실패하는 경우 스프링이 FieldError를 생성해서 BindingResult에 넣어준다.
2. 개발자가 직접 넣어준다.
3. Validator 사용

FieldError & ObjectError

FieldError - 필드 오류

// 사용 예시
if(!StringUtils.hasText(item.getItemName())) {
    bindingResult.addError(new FieldError("item", "itemName", "상품 이름은 필수입니다."));
}

// FieldError 생성자 (1)
public FieldError(String objectName, String field, String defaultMessage) { ... }

// FieldError 생성자 (2)
public FieldError(
    String objectName, String field, @Nullable Object rejectedValue, 
    boolean bindingFailure, @Nullable String[] codes, 
    @Nullable Object[] arguments, @Nullable String defaultMessage) { ... }

필드에 오류가 있으면 FieldError 객체를 생성해서 bindingResult에 담아두면 된다.

• objectName: @ModelAttribute 이름
• field: 오류가 발생한 필드 이름
• defaultMessage: 오류 기본 메시지

파라미터 목록은 다음과 같다.

• objectName: 오류가 발생한 객체의 이름
• field: 오류 필드
• rejectedValue: 사용자가 입력한 값(거절된 값)
• bindingFailure 타입 오류 같은 바인딩 실패인지, 검증 실패인지 구분 값
• codes: 메시지 코드
• arguments: 메시지에서 사용하는 인자
• defaultMessage: 기본 오류 메시지

ObjectError - 글로벌 오류

// 사용 예시
bindingResult.addError(new ObjectError("item", "가격 * 수량의 합은 10,000원 이상이어야 합니다. 현재 값 = " + resultPrice));

// ObjectError 생성자 (1)
public ObjectError(String objectName, String defaultMessage) { ... }

// ObjectError 생성자 (2)
public ObjectError(
    String objectName, @Nullable String[] codes, 
    @Nullable Object[] arguments, @Nullable String defaultMessage) { ... }

특정 필드를 넘어서는 오류가 있으면 ObjectError 객체를 생성해서 bindingResult에 담아두면 된다.

• objectName: @ModelAttribute 이름
• codes: 메시지 코드
• arguments: 메시지에서 사용하는 인자
• defaultMessage: 기본 오류 메시지

rejectValue(), reject()

BindingResult가 제공하는 rejectValue(), reject()를 사용하면 FieldError, ObjectError를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.

rejectValue()

void rejectValue(
    @Nullable String field, String errorCode, 
    @Nullable Object[] errorArgs, @Nullable String defaultMessage);

• field: 오류 필드명
• errorCode: 오류 코드
  • 이 오류 코드는 메시지에 등록된 코드가 아니라 messageResolver를 위한 코드임
• errorArgs: 오류 메시지에서 {0}을 치환하기 위한 값
• defaultMessage: 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

bingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null)

앞에서 BindingResult는 어떤 객체를 대상으로 검증하는지 target을 이미 알고 있다고 했다. (target 뒤에 BindingResult가 위치하기 때문) 따라서 target에 대한 정보는 없어도 된다.

reject()

void reject(String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);

• field: 오류 필드명
• errorCode: 오류 코드
  • 이 오류 코드는 메시지에 등록된 코드가 아니라 messageResolver를 위한 코드임
• errorArgs: 오류 메시지에서 {0}을 치환하기 위한 값
• defaultMessage: 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

bingResult.rejectValue("price", "range", new Object[]{1000, 1000000}, null)

오랜만에 스프링을 해서 그런가 과제 시작하고 하루에서 이틀 동안은 손에 잘 안잡혔던 것 같다. 특히 생각이 잘 안나는 JDBC 만을 사용해서 구현해야 하다보니 더 안잡혔던 것 같다.

그래도 과제를 하면서 사용해본 적 없던 MapStruct나 Swagger를 사용해보려고 시도해봤다. MapStruct 같은 경우 어찌저찌 사용을 했지만 Swagger의 경우엔 공통 응답 클래스를 따로 만들어서 그런가 원하는대로 응답 구조가 만들어지지 않아서 결국 Excel에 API 명세서를 작성했다.

나중에 좀 더 찾아보고 적용시켜보는 것을 목표로 해봐야겠다.

알게 된 내용

카디널리티의 종류와 의미

1. Zero or One

   • 의미: 한 엔티티가 다른 엔티티와 0개 또는 1개의 관계를 가질 수 있음
   • 예시: 사용자(User)가 프로필 사진(Profile Picture)을 가질 수 있지만, 필수는 아닐 경우

2. Zero or Many

   • 의미: 한 엔티티가 다른 엔티티와 0개 이상(여러 개)의 관계를 가질 수 있음
   • 예시: 사용자가 작성한 게시글(Post)이 없을 수도 있고, 여러 개일 수도 있는 경우

3. One or Many (1 또는 N)

   • 의미: 한 엔터티가 다른 엔터티와 최소 1개 이상의 관계를 가질 때
   • 예시: 주문(Order)은 반드시 하나 이상의 상품(Item)을 포함해야 하는 경우

4. One Only (정확히 1)

   • 의미: 한 엔터티가 다른 엔터티와 정확히 1개의 관계를 가질 때
   • 예시: 주민등록번호는 반드시 하나의 사용자와만 연결되는 경우

5. Many (N)

   • 의미: 한 엔터티가 다른 엔터티와 여러 개의 관계를 가질 수 있고, 이때 최소값은 명시되지 않음
   • 예시: 하나의 카테고리에 여러 개의 상품이 속할 수 있는 경우

6. One (1)

   • 의미: 한 엔터티가 다른 엔터티와 최소 1개의 관계를 가질 수 있고, 이때 최대값은 명시되지 않음
   • 예시: 학생(Student)이 반드시 하나의 학급(Class)에 속해야 하는 경우

Jackson 어노테이션

Jackson은 자바 진영의 다양한 형식의 데이터를 지원하는 Data processing 툴이다. 스트림 방식으로 속도가 빠르고 유연하며 다양한 서드 파티 데이터 타입을 지원한다. 또한 어노테이션 방식으로 메타 데이터를 기술할 수 있다.

어노테이션

• @JsonIgnoreProperties: 직렬화, 역직렬화 시 제외할 속성을 지정.
• @JsonIgnore: 멤버 변수 위에 선언해서 제외 처리
• @JsonProperty: Json으로 변환 시 사용할 이름 (DB 컬럼과 이름이 다르거나 API 응답과 이름이 다르지만 매핑해야 하는 경우)
• @JsonInclude: 값 존재 유무에 따라 직렬화 시 동작을 지정
  • ALWAYS: 속성의 값에 의존하지 않고 항상 포함 (default)
  • NON_NULL: null이 아닌 값을 갖는 속성만 포함
  • NON_ABSENT: null과 참조 유형의 없음 값(Optional, AtomicReference)을 제외하고 포함
  • NON_EMPTY: null, 없음, 빈 문자열, 빈 컨테이너를 제외한 값 (NON_NULL과 NON_ABSENT 모두에 의해 제외되는 값을 뺀 나머지 값)

GitHub README 꼼수

ERD 등의 사진 파일을 올려야 할 경우 따로 image 폴더를 만들어서 두지 않고도 사진 파일을 사용할 수 있다.

1. GitHub 프로젝트의 Issues 탭으로 들어간다.
2. New Issue를 누른다.
3. 업로드하고자 하는 이미지를 내용 칸으로 드래그한 뒤 놓는다.
4. 잠시 기다리면 마크 다운 형식의 이미지 업로드 형식으로 이미지의 경로가 나온다.
5. 그대로 복사/붙여넣기를 하면 된다.

트러블 슈팅

페이지네이션

사실 페이지네이션은 해본 적이 없어서 알게된 내용으로 가야하지 않을까 싶지만.. 일단 적어본다.

페이지네이션은 DB 상으론 limit와 offset을 사용하면 되는데 limit는 결과 중 처음부터 얼마나 가져올 것인지를 정하는 것이고, offset은 어디서부터 가져올 것인지를 정하는 것이다.

이때 offset의 경우 입력받은 page 값에서 1만큼 빼준 뒤 입력받은 size를 곱해주면 된다. (int offset = (page - 1) * size)

-1을 하는 이유는 사용자가 볼 땐 1 페이지지만 실제로는 0 페이지이기 때문이다.

전체 일정의 개수를 알려주기 위해서 repository에 count 메서드를 추가했다. 그리고 전체 일정 개수를 활용해서 전체 페이지 수 또한 계산 후 넘겨줬다.

    @Override
    public PageDto<ScheduleWithAuthor> findAll(GetSchedulesRequest request) {
        List<ScheduleWithAuthor> resultList = scheduleRepository.findAll(request.getAuthorId(), request.getSelectedDate(), request.getPage(), request.getSize());

        long totalCount = scheduleRepository.count();
        int totalPages = (int) Math.ceil((double) totalCount / request.getSize());
        return new PageDto<>(resultList, request.getPage(), request.getSize(), totalCount, totalPages);
    }

따로 PageDto 객체를 만들어서 반환하도록 했다. 또한 다른 메서드와는 달리 작성자의 이름이 포함되어야 하기 때문에 작성자의 이름을 반환받기 위해 repository 폴더에 ScheduleWithAuthor를 만들어서 repository의 반환값으로 사용했다.

RowMapper

repository에서 RowMapper를 사용할 때 컴파일 에러가 났었었다.

    private RowMapper<Schedule> scheduleRowMapper() {
        return (rs, rowNum) -> {
            Schedule.builder()
                .id(rs.getLong("schedule_id"))
                .authorId(rs.getLong("author_id"))
                .todo(rs.getString("todo"))
                .password(rs.getString("password"))
                .createdAt(rs.getTimestamp("created_at").toLocalDateTime())
                .lastUpdated(rs.getTimestamp("last_updated").toLocalDateTime())
                .build();
        }  // error!: return 문 누락
    }

알고보니 @Builder 사용 시 리턴이 없기 때문에 람다 본문을 만들 필요가 없었었다.

    private RowMapper<Schedule> scheduleRowMapper() {
        return (rs, rowNum) ->
            Schedule.builder()
                .id(rs.getLong("schedule_id"))
                .authorId(rs.getLong("author_id"))
                .todo(rs.getString("todo"))
                .password(rs.getString("password"))
                .createdAt(rs.getTimestamp("created_at").toLocalDateTime())
                .lastUpdated(rs.getTimestamp("last_updated").toLocalDateTime())
                .build();
    }

@RequestParam

일정 전체 조회 시 QueryParameter로 작성자 ID, 선택한 날짜, 페이지, 사이즈 값을 받아오게 되는데 이것들을 Request 객체로 만들어서 한 번에 가져오려고 했고, 별 생각 없이 @RequestParam을 사용했다.

    @GetMapping
    @Override
    public ApiResponse<PageDto<ScheduleWithAuthor>> findAllSchedules(@Valid @RequestParam GetSchedulesRequest request) {  // error!
        PageDto<ScheduleWithAuthor> authorDtoPageDto = scheduleService.findAll(request);
        return ApiResponse.success(OK, authorDtoPageDto, "일정 전체 조회 성공");
    }

하지만 요청 전송 시 MissingServletRequestParameterException이 발생했고 파라미터 request를 찾을 수 없다고 나왔다.

찾아보니 @RequestParam은 단일 파라미터를 매핑하기 때문에 GetSchedulesRequest 타입의 request라는 이름을 찾는 것이었다. 당연히 그런 타입은 없고, QueryParameter에도 request라는 이름이 없으니 예외가 발생하는 것이었다.

그래서 여러 파라미터를 읽는 경우에 사용하는 @ModelAttribute를 사용해서 해결하게 되었다.

    @GetMapping
    @Override
    public ApiResponse<PageDto<ScheduleWithAuthor>> findAllSchedules(@Valid @ModelAttribute GetSchedulesRequest request) {
        PageDto<ScheduleWithAuthor> authorDtoPageDto = scheduleService.findAll(request);
        return ApiResponse.success(OK, authorDtoPageDto, "일정 전체 조회 성공");
    }

DELETE 구현

@Getter
@RequiredArgsConstructor
public class DeleteScheduleRequest {
    @NotBlank
    private final String password;
}

일정 삭제 시 Password 필드 하나만을 가지고 있는 Request를 보내게 되는데, 이때 JSON -> Object로의 역직렬화가 제대로 되지 않아서 예외가 발생했다. 찾아보니 필드가 하나인 경우 Delegating 방식과 Properties 방식 중 어떤 것을 사용해야 할 지 몰라서 발생한 에러라고 한다.

@Getter
public class DeleteScheduleRequest {
    @NotBlank
    private final String password;

    @JsonCreator
    public DeleteScheduleRequest(String password) {
        this.password = password;
    }
}

여러 해결 방법이 있었지만 나는 @JsonCreator를 사용해서 문제를 해결했다. 기본 생성자를 사용하지 않기 때문에 final을 제거할 필요가 없어서 선택했다.

이건 조금 다른 얘긴데 DTO에 대해서 튜터님께 여쭤보러 갔었을 때였는데 튜터님이 DELETE 코드를 잠깐 보시더니 리소스 삭제는 정말 신중하게 해야하고, 삭제를 한 뒤에도 tracking이 가능해야 한다고 말씀을 해주셨다.

그래서 내 생각에 가장 간단한 방법이라고 느낀 soft-delete 방식을 사용하게 되었다.

# 기존 삭제 구문
delete from schedules where schedule_id = 1

# soft-delete 구문
update schedules set is_active = false where schedule_id = 1

repository에서 기존 삭제 구문처럼 실제로 삭제하는 것이 아니라 상태를 나타내는 is_active를 추가한 뒤에 삭제 시 false로 바꿔주고, 다른 조회 구문에서 where is_active = true를 추가하게 되면 실제로 삭제가 된 것처럼 is_active가 false인 row를 제외하고 조회하게 된다.

로그 파일을 따로 만들어서 tracking을 하는 방법도 있다.

Password 암호화

일정 등록 시 Password를 등록하고, 일정 수정이나 삭제 시 Password를 확인해서 일치할 경우 기능이 수행되도록 한다. 이때 Password 암호화를 하지 않을 경우 DB에서 조회 시 사용자의 password가 저장된 상태 그대로 전부 보이기 때문에 보안에 좋지 않다.

따라서 PasswordEncoder를 사용하려고 했다. 실제로 spring-boot-starter-security 의존성 사용 시 PasswordEncoder 인터페이스를 빈으로 등록해서 구현체를 사용할 수 있다는 것을 알고 있었지만 security 사용 시 filterChain을 설정해줘야 하는 번거로움이 있어서 고민을 했었다.

하지만 spring-security-crypto를 사용하게 되면 별도의 filterChain 설정 없이 PasswordEncoder만 사용할 수 있다는 것을 알게 되었다.

implementation 'org.springframework.security:spring-security-crypto'

추가로 비밀번호 검증 시 단순하게 passwordEncoder.encode(request.getPassword()).equals(schedule.getPassword())를 사용하면 안된다. 입력한 값이 실제로 같더라도 암호화하는 과정에서 값이 달라지기 때문에 비밀번호 검증 시에는 passwordEncoder.matches(request.getPassword(), schedule.getPassword())를 사용해야 한다.

메서드 추출

메서드 추출 단축키(ctrl + alt + m)가 갑자기 안먹혔을 때가 있었다. 처음엔 메서드 추출이 안되는 구문인 줄 알았지만 다른 구문도 마찬가지로 메서드 추출 단축키가 안먹혔었다.

왜 그런지 알아보니 최근에 그래픽 카드 업데이트를 하면서 Geforce Experience도 같이 다운받았는데 해당 기능 중 게임 내 오버레이 기능 중 메서드 추출 단축키와 겹치는 것이 있어서 먹히지 않았던 것이었다.

해당 기능을 비활성화해서 해결했다.

단건 조회 시 Optional 반환

객체 단건 조회 시 null을 반환받지 않도록 하기 위해서 Optional로 반환 받으려고 했다.

하지만 JDBC에서 Optional로 반환받아본 적이 없어서 조금 찾아보게 되었고, 알게 된 방법이 있다.

    @Override
    public Optional<Schedule> findById(Long scheduleId) {
        String sql = "select * from schedules where schedule_id = :scheduleId and is_active = true";
        SqlParameterSource param = new MapSqlParameterSource("scheduleId", scheduleId);

        List<Schedule> schedules = jdbcTemplate.query(sql, param, scheduleRowMapper());
        return schedules.stream().findFirst();
    }

바로 단건 조회여도 query()를 사용해서 List로 값을 가져오도록 하고, return schedules.stream().findFirst()를 통해 Optional로 반환하도록 했다.

findFirst()는 Optional을 반환한다

application.yml

데이터베이스 연결 정보를 숨기기 위해서 프로필을 분리했다.

spring:
  config:
    import:
      - classpath:application-dev.yml

사실 다른 방법도 있지만 단순 과제였기 때문에 프로필을 분리해서 데이터베이스 정보가 있는 파일을 .gitignore에 추가하는 방식으로 선택했다.

References

https://coding-business.tistory.com/34 (오류 메시지)

https://jiwondev.tistory.com/251 (DTO는 어떤 레이어에 포함되어야 하는가)

https://jong-bae.tistory.com/80 ([MapStruct] @Mapping 활용하기)

https://rk1993.tistory.com/196 (MySQL 날짜 더하기) https://phpschool.com/gnuboard4/bbs/board.php?bo_table=qna_db&wr_id=224393&sca=&sfl=wr_subject%7C%7Cwr_content&stx=date&sop=and (날짜 범위 설정) https://insight-bgh.tistory.com/246 (MySQL 타임존 설정)

https://worthpreading.tistory.com/83 (깃허브 리드미에 이미지 올릴 때 꼼수)

https://inpa.tistory.com/entry/ERD-CLOUD-%E2%98%81%EF%B8%8F-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8%EC%9D%84-%EC%98%A8%EB%9D%BC%EC%9D%B8%EC%97%90%EC%84%9C-%EA%B7%B8%EB%A0%A4%EB%B3%B4%EC%9E%90 (ERD Cloud 사용 방법)

https://velog.io/@westreed/Spring-application.yml-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0 (application.yml 관리하기)

https://kong-dev.tistory.com/236 (Json 필드 매핑 관련)

https://promisingmoon.tistory.com/215 (security 없이 PasswordEncoder 추가)

https://rainbow-flavor.tistory.com/12 (메서드 추출 안될 때)

성능 효율성은 컴퓨팅 리소스를 사용해 시스템 요구 사항을 충족하고, 수요가 바뀌고, 기술이 발전함에 따라 효율성을 유지하는 기능을 포함한다.

설계 원칙

• 첨단 기술의 대중화
  • 고급 기술을 대중화해서 사용할 수 있도록 하면 제품 개발에도 도움이 되므로 계속 흐름을 파악해야 함
• 몇 분 안에 전 세계에 배포
  • 여러 리전에 배포를 해야 한다면 며칠이 아니라 몇 분 안에 배포해야 함
  • 여러 지역에 쉽게 배포해야 한다는 의미이기도 함
• 서버리스 아키텍처 사용
  • 서버 관리 부담 방지를 위한 서버리스 아키텍처 사용
• 더 자주 실험하기
  • 간편한 비교 테스트를 수행해야 함
  • 서버리스 아키텍처로 실험해서 제대로 작동하는지 확인해 볼 수 있음
• 기계적 동조
  • 모든 AWS 서비스에 대해 알고 있어야 함
  • 변경 사항이 발생하면 솔루션 아키텍처가 극적으로 변경될 수 있기 때문

AWS 서비스에서의 성능 효율성

• 사용자에게 적합한 서비스를 선택
  • Lambda: 서버리스가 필요
  • Auto Scaling: 더 많은 EC2에 사용
  • EBS: 디스크가 필요하지만 gp2, io1 을 사용해서 성능을 관리할 때
  • S3: 전 세계적 확장에 사용
  • RDS: 데이터베이스를 프로비저닝하고, Aurora로 마이그레이션 할 때 사용
• 성능 검토
  • 생성하기 전에 필요한 것을 정확히 얻는지 확인: CloudFormation
  • 모든 성능 개선 사항의 업데이트: AWS News Blog
• 성능 모니터링
  • 성능이 좋은지 확인하는 방법: CloudWatch Alarms, CloudWatch metrics, CloudWatch
  • Lambda: 병목 되지 않고 애플리케이션의 람다 함수가 최소 시간 내에 실행되도록 함
• 절충
  • RDS 와 Aurora 사용
  • ElastiCache: 캐시에 오래된 데이터가 있지만 성능을 개선할 것인지, 일래스티 캐시 사용 없이 최신 버전을 얻을 것인지 절충해야 함
  • Snowball: 데이터를 클라우드에서 확인하고 모든 네트워크 용량을 사용하거나, 데이터를 트럭으로 옮기고 일주일 안에 받을지 절충해야 함
  • CloudFront 엣지 주변의 것을 캐싱하고, 전 세계에 배포하면 하루 동안 캐시돼서 웹사이트 업데이트 릴리스 시 사용자들이 새 버전을 얻는 데 시간이 걸릴 수 있음

5. Cost Optimization

• 비용 최적화는 비즈니스 가치를 창출하는 시스템을 최저의 가격으로 실행하는 능력이며 매우 합리적인 접근 방식이다.

비용 최적화 설계 원칙

• 소비 모델 채택
  • 서비스를 사용한 만큼만 비용 지불
    • Lambda → 사용하지 않으면 비용을 지불하지 않음
    • 데이터베이스 → 사용하지 않아도 비용을 지불 (프로비저닝 했기 때문)
• 전반적인 효율성 측정
  • CloudWatch를 사용하여 리소스를 효과적으로 사용하고 있는지 측정하는 것
• 데이터 센터 운영 비용 지출 중단
  • AWS가 인프라를 대신 관리해주고, 사용자가 조직의 애플리케이션과 시스템에 집중할 수 있도록 해 줌
• 비용을 분석하고 어디에 지출되고 있는지 파악
  • 태그를 사용하여 각 애플리케이션의 비용을 추적해서 비용을 최적화할 수 있음
• 애플리케이션 수준의 관리 서비스를 사용하여 소유 비용 절감
  • 관리형 서비스는 클라우드 규모로 운영되기 때문에 트랜잭션 또는 서비스당 비용을 낮출 수 있음

AWS 서비스에서의 비용 최적화

• 지출 인식
  • Budgets, Cost and Usage Report, Cost Explorer, Reserved Instance Reporting
    • 예약한 인스턴스를 실제로 사용하는지 파악할 수 있도록 해줌
• 리소스 비용 효율성
  • Spot instance, Reserved instance, S3 Glacier
    • 비용 효율적인 리소스를 사용할 수 있는지 파악하는 것
• 수요/공급의 일치
  • Auto Scaling: 프로비저닝이 과잉되지 않도록 함
  • Lambda: 서버리스 인프라 구조를 사용 중인 경우 고려
• 시간 경과에 따른 최적화
  • Trusted Advisor, Cost and Usage Report, AWS News Blog
    • 최적화에 필요한 정보를 얻을 수 있음

6. Sustainability

• 지속 가능성은 클라우드 워크로드 실행이 환경에 미치는 영향을 최소화하는 데 중점을 둔다.

지속 가능성 설계 원칙

• 영향력 이해
  • 성과 지표를 설정하고 개선점을 평가하는 것으로 영향을 이해
• 지속 가능성 목표 수립
  • 장기 목표와 목표 ROI(투자 수익률)를 세워 목표를 달성
• 서비스 활용 극대화
  • 에너지 효율을 높이고 환경에 미치는 영향을 조절하기 위함
• 더 효율적인 하드웨어 및 소프트웨어 제품을 예측해서 채용
  • AWS의 인프라 최적화를 통해 새로운 것을 사용하면 효율이 올라갈 수 있음
• 관리형 서비스 사용
  • 지속 가능성 모범 사례를 자동화하는 데 도움이 됨
    • 공유 서비스: 인프라의 양을 줄임
    • 관리형 서비스: 자주 액세스하지 않는 데이터를 콜드 스토리지로 옮기고 컴퓨팅 용량을 조정함
• 클라우드 워크로드의 후속 영향 줄이기
  • 고객이 서비스를 사용하기 위해 지속적으로 디바이스를 업그레이드해야 할 필요를 줄여야 함

AWS 서비스에서의 지속 가능성

• 서버리스 제품을 비롯한 AWS의 지속 가능성에 도움이 되는 서비스
  • EC2 Auto Scaling, Lambda, Fargate
  • 기본적으로 태스크에 적절한 만큼의 컴퓨팅만을 수행
• AWS 용량 컴퓨팅 사용 시 에너지 효율 확인이 가능
  • Cost Explorer AWS Graviton 2, EC2 T instance, @Spot instance
• 스토리지 관련 비용 최적화
  • EFS-IA, S3 Glacier, EBS Cold HDD volumes
• 데이터가 적절한 계층에 있도록 만듦
  • S3 Lifecycle Configurations, S3 Intelligent Tiering, Data Lifecycle Manager
• 데이터베이스 (Read Local, Write Global)
  • RDS Read Replicas, Aurora Global DB, DynamoDB Global Table, CloudFront

AWS Well-Architected Tool

• 6대 원칙을 기준으로 아키텍처를 검토하고 모범 사례를 선정할 수 있다.

작동 방식

1. 워크로드를 선택해 질문에 답한다.
2. 6대 원칙을 기준으로 한 답과 사용자의 답변을 비교한다.
3. 조언을 얻고 영상, 문서, 보고서 등을 받을 수 있다.

AWS Customer Carbon Footprint Tool

• AWS 사용으로 인해 발생하는 탄소 배출량을 추적, 측정, 검토 및 예측하는 데 사용되는 도구이다.
• 지속 가능성 목표를 달성해야 하는 경우 매우 유용하다.
  • 탄소 배출량, 절감량 탄소 배출량이 많은 서비스를 파악할 수 있음
  • 시간 경과에 따른 배출량을 추적하고 AWS 계정에 사용된 100% 재생 에너지의 경로를 확인할 수 있음

AWS Cloud Adoption Framework

• CAF는 기본적으로 전자책이고 백서이다.
• 서비스는 아니지만 AWS의 혁신적인 사용을 통해 투어 디지털 혁신을 위한 포괄적인 계획을 수립하고 실행할 수 있도록 지원한다.
• AWS 전문가들이 AWS 모범 사례와 수천 명의 고객으로부터 얻은 교훈을 활용하여 만든 솔루션이다.
• AWS CAF는 성공적인 클라우드 전환을 뒷받침하는 특정 조직 역량을 식별하고, 기능을 6가지 관점으로 재구성한 것이다.
  • 비즈니스
  • 사람
  • 거버넌스
  • 플랫폼
  • 보안
  • 운영

CAF 관점 및 기본 비즈니스 역량

• 비즈니스 역량은 3개의 기둥으로 구성되어 있다.
  1. 비즈니스 관점
     • 클라우드 투자를 통해 디지털 혁신 목표의 달성과 비즈니스 성과를 가속화할 수 있도록 도와줌
       • 전략 관리, 포트폴리오 관리, 혁신 관리, 제품 관리, 전략 파트너십, 데이터 수익화, 비즈니스 인사이트 및 데이터 과학
  2. 사람 관점
     • 비즈니스라는 큰 테두리 안에서 기술과 비즈니스를 연결하는 가교 역할을 함
     • 지속적 성장을 위한 학습이 조직 문화로 빠르게 뿌리내리고 조직이 변화가 일상적인 비즈니스가 되는 곳으로 진화하도록 도와줌
     • 따라서 사람을 통해 문화, 조직 구조, 리더십 및 인력에 초점을 맞출 수 있음
       • 조직 문화 발전, 혁신적 리더십, 클라우드 숙련도, 인력 혁신, 변화 가속화, 조직 설계 및 조직적 정비
  3. 거버넌스 관점
     • 조직이 누리는 이점을 극대화하고, 혁신과 관련된 위험을 최소화 하면서 클라우드 계획을 조율할 수 있도록 도와줌
       • 프로그램 및 포트폴리오 관리, 혜택 관리, 위험 관리, 클라우드 재무 관리, 애플리케이션 포트폴리오 관리, 데이터 거버넌스 및 데이터 큐레이션

CAF 관점 및 기반 역량 기술 역량

• 기술 역량은 플랫폼, 보안 및 운영 관점으로 구성되어 있다.
  1. 플랫폼 관점
     • 엔터프라이즈급의 확장 가능한 혼합형 클라우드 플랫폼을 구축하여 기존 워크로드를 현대화하고 새로운 클라우드 네이티브 솔루션을 구현할 수 있도록 도와줌
     • 개별적인 역량은 아래와 같음
       • 플랫폼 아키텍처, 데이터 아키텍처, 플랫폼 엔지니어링, 데이터 엔지니어링, 프로비저닝 및 오케스트레이션, 최신 애플리케이션 개발, 지속적 통합 및 지속적 배포
  2. 보안 관점
     • 데이터 및 클라우드 워크로드의 기밀성, 무결성 및 가용성을 확보하는 데 도움이 됨
     • 개별적인 역량은 아래와 같음
       • 보안, 거버넌스, 보안 보증, ID 및 액세스 관리, 위협 탐지, 취약성 관리, 인프라 준비 상태, 데이터 보호, 애플리케이션 보안 및 인시던트 대응
  3. 운영 관점
     • 클라우드 서비스를 비즈니스 요구 사항을 충족하는 수준으로 제공할 수 있도록 도와줌
     • 개별적인 역량은 아래와 같음
       • 가시성, 이벤트 관리, 인시던트 및 문제 관리, 변경 및 릴리스 관리, 성능 및 용량 관리, 구성 관리, 패치 관리, 가용성 및 연속성 관리, 애플리케이션 관리

각각의 역량이 어떤 관점 아래 속해있으며 실제로 이해하고 있는지를 시험을 통해 알아보고자 하는 것이기 때문에 위의 6가지 관점을 반드시 기억해야 한다.

AWS CAF - 혁신 도메인

• 기술
  • 클라우드를 사용하여 레거시 인프라 애플리케이션 데이터 및 분석 플랫폼을 이전하고 현대화하는 것
• 프로세스
  • 비즈니스 운영을 디지털화, 자동화 및 최적화하는 것이며 이를 위해선 다음 두 가지가 필요함
    1. 클라우드의 도움을 받아 새로운 데이터 및 분석 플랫폼을 활용하여 실행 가능한 인사이트를 창출하는 것
    2. 머신 러닝을 사용하여 고객 서비스 경험을 개선하는 것
• 조직
  • 운영 모델을 어떻게 재정립하느냐의 문제
    • 제품과 가치 흐름을 중심으로 팀을 재편해야 함
    • 애자일 방법론을 활용하여 변화에 신속하게 대응하고 지속적인 발전을 이뤄내야 함
• 제품
  • 제품과 서비스 및 수익 모델과 같은 새로운 가치 제안을 창출하여 비즈니스 모델을 재정립하는 것

AWS CAF - 혁신 단계

• 비전 수립 단계 (비즈니스 기회 식별)
  • 클라우드를 채택하여 혁신 기회를 식별하고 디지털 혁신의 기반을 구축함으로써 비즈니스 성과가 어떻게 가속화될 것인가를 구체적으로 제시해야 함
• 정렬 단계 (비즈니스 기회를 CAF 관점과 비교하여 격차를 찾고 실행 계획을 세움)
  • 지금까지 살펴본 6가지 CAF 관점을 검토하여 필요한 역량과 현재 역량 사이의 격차를 파악하고 실행 계획을 도출하는 단계
• 실행 단계
  • 실제로 파일럿 프로젝트를 구축하고 이를 프로덕션 환경에 제공하여 점진적으로 증가하는 비즈니스 가치를 입증
• 확장 단계
  • 원하는 비즈니스 혜택을 실천하면서 파일럿 이니셔티브를 원하는 규모로 확장

시험과 관련하여, 어떤 관점이 프레임워크의 일부분에 해당하는지 여부와 어떤 역량이 특정 관점에 속하는지 여부를 식별하는 질문, 마지막으로 혁신 도메인과 해당 단계에 대한 문제도 출제될 것이다.

AWS Right Sizing

• 클라우드는 탄력적이고 언제든지 인스턴스 유형을 바꿀 수 있기 때문에 가장 강력한 인스턴스를 선택하는 것이 좋다.
• Right Sizing은 최저 비용으로 인스턴스의 유형이나 크기를 워크로드의 성능과 용량의 요구 사항에 일치시키는 프로세스이다.
  • 클라우드에선 스케일 업이 쉽기 때문에 크기가 올바른지 확인하는 것
  • 따라서 작은 크기로 시작해 올바른 크기를 찾아야 함
• 배포한 인스턴스를 지속적으로 확인하는 프로세스이다.
  • 용량이나 성능을 손상하지 않고 지표를 통해 제거하거나 축소할 수 있는 기회를 식별
  • 결과적으로 비용 절감
• Right Sizing는 두 가지 순간에 매우 중요하다.
  1. 클라우드 마이그레이션 직전
     • 기업이 클라우드로 마이그레이션 할 때 가장 큰 인스턴스 크기로 두고 잊어버리는 경우가 많기 때문
  2. 클라우드 마이그레이션이 끝나도 달에 한 번 정도 지속적으로 해야 함
     • 요구 사항이 변경되고 올바른 크기로 늘릴지, 줄일지 확인하는 것이 중요하기 때문
• CloudWatch, Cost Explorer Trusted Advisor 와 같은 크기 조정을 돕는 도구가 있다.

AWS 생태계

AWS를 둘러싼 생태계에는 많은 무료 리소스가 있다. 예를 들어 블로그나 커뮤니티 기반의 포럼, 백서와 가이드도 있다. 예시로 Well-Architected 프레임워크는 백서 중 하나이다.

• AWS Blogs: https://aws.amazon.com/blogs/aws/
• AWS Forums: https://forums.aws.amazon.com/index.jspa
• AWS Whitepapers & Guides: https://aws.amazon.com/whitepapers
• AWS Partner Solutions: https://aws.amazon.com/quickstart
  • AWS 클라우드에서 애플리케이션 및 워크로드를 AWS 모범 사례에 따라 자동으로 배포할 수 있음
  • 템플릿을 사용하여 프로덕션 환경을 매우 빠르게 구축할 수 있음

AWS IQ

• IQ는 프로젝트에 도움을 줄 전문가를 빠르게 찾는 데 사용된다.
• 인증을 받은 (제 3자) 전문가를 많이 확보하여 온디맨드 프로젝트 작업에 투입할 수 있게 해 주는 것이다.
• IQ는 화상 회의, 계약 관리, 안전한 협업 및 통합 청구 기능을 제공한다.

IQ 고객의 경우

1. 자신의 프로젝트에 대한 설명이 포함된 요청을 제출하게 된다.
2. 받은 응답을 검토하고 요구 사항 및 일정 등을 토대로 전문가와 연결된다.
3. 몇몇 후보자를 선정하고 나서 요금이나 업무 경험 등을 토대로 전문가를 선택할 수 있다.
4. 해당 전문가에게 사용자의 계정에 대한 액세스 권한을 안전하게 부여하여 안전하게 협업을 진행할 수 있다.
5. 마지막으로, 전문가의 작업에 만족할 경우 마일스톤을 해제할 수 있고 그러면 마일스톤에 대한 비용이 사용자의 AWS 청구서에 직접 부과된다.

IQ 전문가인 경우

1. 본인 소개, 사진, 자격증 정보 등이 포함된 프로필을 생성하면 고객과 연결된다.
2. 제안을 시작하고, 제안이 수락되면 안전하게 작업을 수행한다.
3. 마일스톤이 해제된 후에 대가를 지급받게 된다.

AWS re:Post

• 도움을 받을 수 있는 또 다른 옵션은 re:Post를 사용하는 것으로 re:Post는 사실상 포럼이다.
• 궁금한 사항에 대한 답변을 찾고, 질문을 하고, 모범 사례를 찾고, 그룹에 참여할 수도 있는 커뮤니티 포럼이다.
• AWS에 대한 기술적인 질문에 대해 많은 사람들이 답변하고, 전문가가 그 답변을 검토하는 방식으로 AWS가 관리하는 Q&A 서비스이다.
• 작동 방식은 스택 오버플로우와 유사하다.
• re:Post는 프리 티어의 일부로 액세스하는 데 비용이 들지 않는다.
• 시간이 촉박한 질문에 대해서나 긴급한 조치가 필요한 경우에는 적합하지 않다.

AWS Knowledge Center

• AWS에 관해 가장 빈번하고 일반적인 질문과 요청을 찾을 수 있는 곳이다.
  • 인기 있는 서비스, 분석, 애플리케이션 통합 등 다양한 범주가 있음
• 시험 응시자의 입장에서 볼 때 매우 일반적인 질문에 대한 답이나 모범 용례를 찾을 수 있다.

AWS Managed Services

• AWS Managed Services(이하 AMS)는 실제로 AWS에서 인프라 구조 및 애플리케이션 지원을 제공하는 사람들로 구성된 팀이다.
• 따라서 AWS에는 서비스를 제공하는 전문가 팀이 있으며 이를 AWS 팀 즉, AMS 라고 한다.
• AMS는 고객의 인프라 구조를 관리 및 운영하여 인프라 구조의 보안, 신뢰성 및 가용성이 보장되도록 하고, 조직이 일상적인 유지 관리 작업에서 벗어나 비즈니스 목표에 집중할 수 있도록 도와준다.
• AMS는 완전 관리형 서비스이며 변경 요청, 모니터링, 패치 관리, 보안 및 백업 서비스와 같은 일반적인 활동을 AWS가 처리한다.
• 모범 사례를 구현하고 인프라 구조를 유지 관리하여 운영상의 부담과 위험을 줄여준다.
• AMS는 연중무휴 24시간 운영되며 고객은 클라우드 환경을 시작하기만 하면 된다.
• AMS를 통해 얻을 수 있는 이점은 다음과 같다.
  • 보안 강화
  • 자동화에 집중 가능
  • 규정 준수 강화
  • 운영 비용 감소
  • 관리의 간소화 및 원활한 혁신

• AMS는 고객이 클라우드 환경의 기초를 구축하고 그 기초 위에서 시스템을 유지, 확장 또는 이전할 수 있도록 한다.
• 위의 과정에서 고객에게 필요한 지원을 제공한다.
• 그 다음 고객이 클라우드에서 인프라 구조를 운영할 수 있도록 도와준다.

Refenrence

• https://www.udemy.com/course/best-aws-certified-cloud/learn/lecture/29390176?start=0#content