소스

https://github.com/rkwhr0010/jpa

SQL을 직접 다룰 때 발생하는 문제점

지루한 반복 코드

JDBC API를 사용해 DB에 CRUD를 하려면 너무 많은 직접 작성한 유사한 SQL과 DB 연결을 위한 반복성 코드가 생긴다.

데이터 접근 계층(DAO)는 대부분 반복성 코드와 유사한 SQL이 많다.

 

SQL에 의존적인 개발

비즈니스 요구사항은 언제나 변한다.

public class Member {         private Long id;         private String name;         private String email; // 새로 추가된 컬럼 }

비즈니스 요구사항을 모델링한 객체를 엔티티라 한다.

요구사항의 변경으로 위 Member 엔티티에서 email을 추가로 저장해야 하는 상황이 오면, 모든 관계된 CRUD 코드를 확인하고 SQL을 수정해야 한다.

 

JPA와 문제 해결

JPA는 객체를 DB에 저장할 때 JPA가 제공하는 API를 사용하면 된다.

JPA가 자동으로 SQL를 생성해서 DB에게 전달한다.

 

다음은 CRUD 에 대표적인 메서드들이다

저장

 

 

조회

 

 

수정

수정의 경우 특별하다. find()로 조회한 엔티티를 수정하면, 트랜잭션을 커밋할 때 DB에 수정사항이 반영된다.

 

삭제

 

 

페러다임의 불일치

애플리케이션은 발전하면서 복잡성도 증대된다.

개발자는 복잡성을 잘 제어해 유지보수하기 좋은 코드를 만들려 노력한다.

 

객체지향 캡상추다, SOLID, 디자인패턴 등은 복잡성을 제어하기 위한 도구이다.

 

비즈니스 요구사항은 코드로 구현을 해도 결국 산출물로 데이터가 나오고 이는 영구히 저장할 곳이 필요하다. 이때 RDB(관계형 DB)가 그 역할을 한다. 여기서 DB는 편의상 RDB로 한정한다.

 

런타임에 객체로 존재하는 데이터를 RDB에 저장해야 한다.

문제는 객체와 RDB는 지향하는 목적이 다르다는 것이다.

RDB에는 객체지향이라는 개념이 존재하지 않는다. 데이터 중심으로 구조화되어 있다.

객체 구조를 테이블 구조에 저장하는 것에 한계가 있다. 이를 패러다임 불일치라 한다.

 

패러다임 불일치를 해소하기 위해 결국 개발자가 많은 노력을 기울여야 한다.

 

상속

객체는 상속이라는 개념이 존재한다.

DB 모델링에는 유사한 개념인 슈퍼타입 서브타입 관계가 존재한다.

비슷해 보이지만, 다르다. 객체는 extends 키워드로 부모의 속성을 상속 받지만, DB의 경우 슈퍼타입과 서브타입 간 KEY 로만 관계를 맺는다.

즉, 1개의 서브타입 객체를 DB에 저장하려면 2개의 INSERT 쿼리가 필요하다.

이게 패러다임 불일치를 해소하기 위한 비용이다.

 

JPA와 상속

JPA는 마치 자바 컬렉션에 저장하듯 사용하면, 나머지는 JPA가 알아서 처리해 준다.

JPA가 알아서 2개의 INSERT 쿼리로 처리해줌

 

 

 

package study.jpa.entity; import jakarta.persistence.Column; import jakarta.persistence.DiscriminatorColumn; import jakarta.persistence.Entity; import jakarta.persistence.GeneratedValue; import jakarta.persistence.Id; import jakarta.persistence.Inheritance; import jakarta.persistence.InheritanceType; @Entity @Inheritance(strategy = InheritanceType.JOINED) @DiscriminatorColumn(name = "DTYPE") public abstract class Item {         @Id         @GeneratedValue         @Column(name = "ITEM_ID")         private Long id;                  private String name;         private Integer price;                  public Long getId() {                 return id;         }         public void setId(Long id) {                 this.id = id;         }         public String getName() {                 return name;         }         public void setName(String name) {                 this.name = name;         }         public Integer getPrice() {                 return price;         }         public void setPrice(Integer price) {                 this.price = price;         } }

package study.jpa.entity; import jakarta.persistence.DiscriminatorValue; import jakarta.persistence.Entity; @Entity @DiscriminatorValue("A") public class Album extends Item{         private String artist;         public String getArtist() {                 return artist;         }         public void setArtist(String artist) {                 this.artist = artist;         } }

package study.jpa.entity; import jakarta.persistence.DiscriminatorValue; import jakarta.persistence.Entity; @Entity @DiscriminatorValue("B") public class Book extends Item{         private String author;         private String isbn;         public String getAuthor() {                 return author;         }         public void setAuthor(String author) {                 this.author = author;         }         public String getIsbn() {                 return isbn;         }         public void setIsbn(String isbn) {                 this.isbn = isbn;         } }

package study.jpa.entity; import jakarta.persistence.DiscriminatorValue; import jakarta.persistence.Entity; @Entity @DiscriminatorValue("M") public class Movie extends Item{         private String director;         private String actor;                  public String getDirector() {                 return director;         }         public void setDirector(String director) {                 this.director = director;         }         public String getActor() {                 return actor;         }         public void setActor(String actor) {                 this.actor = actor;         } }

package study.jpa; import java.util.function.Consumer; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import jakarta.persistence.EntityManager; import jakarta.persistence.EntityManagerFactory; import jakarta.persistence.EntityTransaction; import jakarta.persistence.Persistence; import study.jpa.entity.Album; public class Main {         static Logger logger = LogManager.getLogger();         static EntityManagerFactory emf =                         Persistence.createEntityManagerFactory("studyjpa");                  public static void main(String[] args) {                 createPersistenceContext(em -> {                         Album album = new Album();                         album.setName("앨범");                         album.setArtist("홍길동");                         album.setPrice(1000);                                                  em.persist(album);                 });         }         private static void createPersistenceContext(Consumer<EntityManager> consumer) {                 EntityManager em = emf.createEntityManager();                 EntityTransaction tx = em.getTransaction();                                  try {                         tx.begin();                                                  consumer.accept(em);                                                  tx.commit();                 } catch (Exception e) {                         tx.rollback();                 } finally {                         em.close();                 }                 emf.close();         } }

 

자동으로 2개 SQL

 

JPA 자동으로 객체와 테이블 간 간극을 매핑해준다.

 

 

연관관계

객체는 참조를 통해 해당 객체에 접근한다.

테이블은 외래 키를 통해 조인으로 연관 테이블을 조회한다.

 

객체의 참조와 RDB의 외래 키 사이 패러다임 불일치는 RDB 구조를 객체지향 모델링에 적용 시키는 것이 어렵다.

 

참조의 경우 단방향이다.

 

테이블의 경우 외래 키로 관계를 맺으므로, 방향이라는 것이 없다. 굳이 따지면 양방향이다.

 

 

객체를 테이블에 맞추어 모델링

패러다임 불일치를 가장 크게 체감할 수 있는 방법은 객체를 테이블에 맞춰서 설계해보는 것이다.

 

위와 같은 설계는 데이터를 DB에 저장하기는 편하다.

문제는 RDB의 경우 키 값으로 조인을 해 관계를 맺어준다.

객체는 값으로 관계를 맺어줄 수가 없다. 참조로 연결해야 연관된 객체를 알 수 있다.

 

 

위 처럼 객체지향에 맞춰서 설계를 하면, DB 데이터를 객체에 맞춰야한다.

이 과정을 JPA가 자동으로 해준다.

즉, 개발자는 마치 컬렉션에서 객체를 꺼내듯 사용하면, DB에서 엔티티가 조회된다.

 

 

 

 

JPA가 알아서 패러다임 불일치를 해결해준다.

 

위 처럼 객체 참조를 통해 이동하는 것을 객체 그래프 탐색이라고 한다.

 

JPA 비교와 그냥 비교

 

 

객체 비교의 두가지 방법

동일성은 == 비교이다.

동등성 비교는 equals() 비교이다

 

동일성은 참조 변수의 경우 같은 인스턴스인지 확인한다.

동등성은 그 서로 다른 객체여도 그 내용이 같은지 확인한다.

 

 

 

여기서 중요한 점은 JPA로 조회한 회원 객체이다.

같은 영속성 컨텍스트에서 조회한 멤버는 동일성을 보증한다.

 

정리

객체 모델과 RDB 모델은 지향하는 패러다임이 다르다.

객체지향 어플리케이션을 더욱 더 객체지향스럽게 디자인 할 수록

패러다임 불일치가 더 커진다.

JPA는 이런 패러다임 불일치 문제를 해결해준다.

JPA는 개발자로 하여금 계속 객체지향 모델링을 유지하도록 도와준다.

 

 

 

JPA란 무엇인가

JPA Java Persistence API

자바 진영의 ORM 기술 표준

ORM Object-Relational Mapping

객체와 RDB를 매핑한다는 뜻

 

JPA를 제외하고도 모든 자바 기반 기술은 DB 접속은 JDBC API를 사용한다.

 

 

ORM 프레임워크는 객체와 테이블 매핑에서 오는 패러다임 불일치 문제를 해결해준다.

개발자는 자바 코드에서 컬렉션에 객체를 저장하듯 ORM 프레임워크에 저장하면, 나머지는 작업은 ORM 프레임워크가 알아서 해준다.

가장 유명한 ORM 프레임워크는 하이버네이트다.

 

JPA는 자바 ORM 기술에 대한 API 표준 명세로, 바꿔 말하면, 인터페이스 묶음이다.

즉, 실질적인 구현체 중 하나를 선택해 사용한다.

 

왜 JPA를 사용해야 하나

장점으로 생산성, 유지보수성, 패러다임 불일치 해결, 성능, 데이터 접근 추상화(벤더 독립성)가 있다.

 

지루하고 반복적인 CRUD SQL과 SQL과 객체 사이 데이터 매핑을 할 필요가 없다.

엔티티에 필드가 변경되어도 이전 JPA사용하기 전보다 훨씬 적은 양의 코드만 손보면 된다.

JPA가 객체 RDB간 매핑을 해주기 때문에 개발자는 객체의 참조를 그대로 사용해 객체 그래프 탐색을 할 수 있다. 원래라면 개발자가 조인 쿼리를 짜고, 나온 데이터를 전부 객체에 알맞게 매핑해줘야하는 번거로운 일이다. 이 때문에 과거에는 객체를 테이블에 맞춰 데이터 중심으로 사용했다.

JPA는 애플리케이션과 DB 사이에서 동작한다. 그 사이에서 캐시 역할 등으로 성능 최적화 기회를 얻는다.

데이터 접근이 한 단계 더 추상화된 방언(Dialect) 계층이 있다.

따라서 DB 변경이 자유롭다. 알맞은 벤더의 방언으로 교체하기만 하면 방언이 알아서 SQL을 변경해준다.

극단적으로 개발은 Mysql 운영은 오라클로 바꿀 수 있다.

 

 

 

 

DB 설치

Mysql 로 진행

나는 도커로 Mysql 을 설치했으나, 로컬에 설치해도 상관 없음

도커

docker run --name test-mysql -e MYSQL_ROOT_PASSWORD=root -p 55555:3306 -d mysql:8.1

로컬 포트는 55555를 사용했다. 도커에서 Mysql 포트 3306로 매핑한다.

DB 스키마 및 계정 생성

DB 접속 툴은 DBeaver

STS(이클립스) 기준

프레임워크 없이 단순 JPA만 실습하기 위한 프로젝트 설

메이븐 의존성 pom.xml

영속성 유닛 설정

특이사항으로 이제 jakarta 패키지 명을 사용한다.

logf4.xml

테스트

AuthenticationProvider 인터페이스가 인증 논리를 담당한다.

AuthenticationProvider의 이해

실제 인증은 여러 방식이 있을 수 있다.

단순한 id/pw 인증이 전부가 아니다.

스프링 시큐리티는 AuthenticationProvider 로 모든 인증을 추상화하고, 이게 맞게 구현만 하면 어떠한 인증 시나리오도 구축할 수 있다.

인증에 사용되는 Authentication

Authentication은 인증에 사용되는 필수 인터페이스다.

아래 처럼 인자로 사용되어 인증에 사용된다.

Authentication은 Principal 를 확장한다. Principal은 자바 시큐리티 인터페이스다.

인증 논리 구현

authenticate() 은 인증 성공 시 완전히 인증된 Authentication을 반환해야 한다.

isAuthenticated() true를 반환하고, 모든 필수 정보가 포함되야한다.

단, 보안 상의 이유로 자격증명은 제거될 수 있다.

인증이 이미 성공했기 때문에 더 이상 자격증명 같은 민감한 정보가 필요없기 때문이다.

supports() 는 매개변수 Authentication을 인증 시 사용할 수 있는지 여부를 리턴한다.

주의할 것은 이 메서드가 true를 리턴해도 authenticate()메서드에서 null을 리턴해 인증을 거부할 수 있다.

supports()가 false 경우 AuthenticaitonManager는 인증을 시도하지 않는다. 바로 다음 AuthenticationProvider에게 인증을 위임한다.

맞춤형 인증 논리 구현

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.security.authentication.AuthenticationProvider;

import org.springframework.security.authentication.BadCredentialsException;

import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;

import org.springframework.security.core.Authentication;

import org.springframework.security.core.AuthenticationException;

import org.springframework.security.core.userdetails.UserDetails;

import org.springframework.security.core.userdetails.UserDetailsService;

import org.springframework.security.crypto.password.PasswordEncoder;

import org.springframework.stereotype.Component;

@Component

public class CustomAuthenticationProvider implements AuthenticationProvider{

        Logger logger = LoggerFactory.getLogger(getClass());

        @Autowired

        private UserDetailsService userDetailsService;

        @Autowired

        private PasswordEncoder passwordEncoder;

        @Override

        public Authentication authenticate(Authentication authentication) throws AuthenticationException {

                logger.info("=========== 인증 시작 ===========");

                String username = authentication.getName();

                String password = authentication.getCredentials().toString();

                UserDetails userDetails = userDetailsService.loadUserByUsername(username);

                if(passwordEncoder.matches(password, userDetails.getPassword())) {

                        return new UsernamePasswordAuthenticationToken(

                                        username, password, userDetails.getAuthorities());

                }

                throw new BadCredentialsException("인증 실패");

        }

        @Override

        public boolean supports(Class<?> authentication) {

                return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication);

        }

}

참고로 권한 정보까지 사용해서 UsernamepasswordAuthenticationToken을 생성하면

아래와 같이 완전히 인증됨을 의미하는 플래그 값을 true로 설정한다.

실행

SecurityContext 이용

SecurityContext(이하 보안 컨텍스트)

인증 프로세스가 끝난 후 인증된 Authentication에 대한 세부 정보가 필요할 가능성이 크다.

주로 이름과 권한을 지속적으로 확인해야할 수 있다.

SecurityContext는 Authentication 객체가 요청이 유지되는 동안 내부에 저장한다.

보안 컨텍스트는 이게 전부다. 보면 알 수 있듯 인증 객체를 저장하는 것이 역할이다.

보안 컨텍스트를 관리하는 SecurityContextHolder는 3 가지 모드를 지원한다.

MODE_THREADLOCAL

스레드에 안전한 저장소에 보안 문맥을 저장한다.

일반적으로 WAS는 하나의 요청 당 하나의 쓰레드를 가지므로 기본이 되는 전략이다.

MODE_INHERITABLETHREADLOCAL

MODE_THREADLOCAL와 유사하다.

비동기 메서드의 경우, 다음 스레드로 복사해서 사용한다.

예를들어, @Async 메서드를 실행하는 새 스레드가 보안 컨텍스트를 상속한다.

MODE_GLOBAL

애플리케이션의 모든 스레드가 같은 보안 컨텍스트를 공유한다.

스프링 시큐리티는 이외에도 사용자가 커스텀한 전략을 사용하도록 설정할 수 있다.

보안 컨텍스트를 위한 보유 전략 이용

MODE_THREADLOCAL

기본 전략은 MODE_THREADLOCAL 이다.

내부적으로 ThreadLocal 을 사용한다.

ThreadLocal 에 저장된 데이터는 다른 쓰레드에선 접근이 불가능하다.

이는 웹 요청마다 새로운 쓰레드를 생성하는 일반적인 WAS와 잘 맞아떨어지는 동작방식이다.

만약 서버가 비동기 기술을 사용한다면 문제가 될 수 있다. 기존 쓰레드에서 새로운 쓰레드를 생성해 실행하면, 새로 생성된 쓰레드는 접근을 하지 못하기 때문이다.

6번에 저장된 보안 컨텍스트를 7번에서 꺼내서 사용할 수 있다.

MODE_INHERITABLETHREADLOCAL

비동기를 사용하는 상황에서 전략

비동기 설정

아직 보안 컨텍스트 모드를 설정하지 않아 기본 모드인 MODE_THREADLOCAL 로 동작하기에 값이 없다.

InitializingBean 빈을 구현하면, 스프링이 컨테이너를 초기화하는 과정에 호출해준다.

정상적으로 값이 나온다.

주의할 것은 이 방법은 선언적으로 작성한 코드에 대해서만 동작을 한다.

선언적으로 작성한 코드는 프레임워크에서 런타임 중에 비동기임을 알기 때문에 자동으로 처리가 된다.

개발자가 메서드 안에서 코드로 쓰레드를 만들어 호출하면, 프레임워크는 비동기가 발생한지 알 수 없어, Null 이 나오게 된다.

MODE_GLOBAL

보안 컨텍스트가 모든 스레드에 공유된다.

모든 스레드가 공유하기 때문에 이게 따른 동시성 이슈를 개발자가 직접 해결해야 한다.

DelegatingSecurityContextRunnable 보안 컨텍스트 전달

보안 컨텍스트 저장 전략은 총 세 가지로 그 중 기본 모드는 MODE_THREADLOCAL 이다

이 모드는 하나의 요청 마다 새로운 쓰레드를 사용하는 보편적인 서버에서 사용된다.

이 상황에서 비동기 작업을 하는 경우, 개발자가 직접 새 쓰레드로 보안 컨텍스트를 전파하는 작업을 해줘야 한다

이를 위해 스프링이 제공하는 유틸들이 있다.

DelegatingSecurityContextRunnable 은 반환 값이 없는 경우 사용

DelegatingSecurityContextCallable 은 반환 값이 있는 경우 사용한다.

비동기 작업을 각 각 비동기 메서드를 통해, 새 쓰레드로 복사한 후 실행한다.

실행

DelegatingSecurityContextExecutorService

DelegatingSecurityContextCallable, DelegatingSecurityContextRunnable은 동기화 모드에서 비동기 메서드를 사용해야 할 때 보안 컨텍스트를 복사해주는 유용한 클래스다.

이보다 더 우아한 방법으로 DelegatingSecurityContextExecutorService는 스레드 풀에서 이 전파 작업을 해준다.

스레드 풀에서 각 새로운 스레드에 보안 컨텍스트를 전파해 준다.

이것도 기존 클래스에 기능을 더 한 데코레이터 패턴이 적용된 클래스다.

보안 컨텍스트를 전파해주는 스레드 풀 클래스

보안 컨텍스트를 전파해주는 클래스

DelegatingSecurityContextCallable, DelegatingSecurityContextRunnable

인증 실패 제어

클라이언트가 인증에 실패하거나, 액세스 권한이 없는 리소스에 인증되지 않은 요청을 하는 경우가 있다.

이 경우 클라이언트로부터 자격 증명을 요청하는 데 AuthenticationEntryPoint 구현이 사용된다.

AuthenticationEntryPoint 구현은 로그인 페이지로 리디렉션을 수행하거나, WWW-Authenticate 헤더로 응답하거나, 다른 작업을 수행할 수 있다.

일반적으로 ExceptionTranslationFilter에 인증 체계를 시작하기 전에 호출된다.

인증 실패 해보기

Form 기반 로그인 인증 구현

일반적인 사용자가 ID/PW 를 입력해서, 인증하는 방식을 실습해본다.

위와 같이 설정 후 서버를 키고 접속하면, 스프링이 기본으로 제공하는 로그인 페이지가 뜬다.

이전처럼 RestController가 아닌 일반 Controller로 실습을 하기 위해 간단한 html파일 생성

폼 로그인 성공/실패 시 처리할 핸들러

성공은 AuthenticationSuccessHandler, 실패는 AuthenticationFailureHandler 를

각각 구현해서 아래에 메서드에 등록해 주면 된다.

form 타입은 FormLoginConfigurer<HttpSecurity>으로 양식 인증 관련 다양한 설정을 할 수 있다.

AuthenticationSuccessHandler, AuthenticationFailureHandler  구현