친구와 토이 프로젝트를 하며 테스트를 위한 데이터를 추가하고자 @Sql annotation 을 적용하고자 했다. 하지만 테스트 데이터가 들어가지 않는 이유를 찾기 위한 삽질 로그를 기록하고자 한다.

Background

1. SpringBootTest.WebEnvironment.RANDOM_PORT 사용

실제 개발 환경과 유사한 환경을 위해 RANDOM_PORT 를 설정했다. 해당 옵션을 설정하면 클라이언트와 서버가 분리되어 멀티 스레드 환경이 된다. 그러므로 Thread Local 기반으로 동작하는 @Transaction 을 사용하여 롤백 처리를 할 수 없다.

롤백을 해야 하는 이유는 테스트 격리(Isolated Test) 을 위함이다. 테스트 격리는 공유 자원을 사용하는 여러 테스트끼리 격리하여 서로 영향을 끼치지 않는 방법을 말하여 대표적인 예시가 DB 데이터 이다. DB 데이터 격리를 위해 롤백을 하며, 스프링에서는 일반적으로 동일 스레드에서 동작하여 @Transactional 을 사용하여 롤백한다. 하지만 앞서 이야기했 듯, 이 방법으로는 롤백을 할 수 없어 RDB 에서 제공하는 TRUNCATE 명령어를 활용하고자 했다.

webEnvironment option in @SpringBootTest

MOCK : Mocking된 웹 환경을 제공(MockMvc를 사용한 테스트 가능 = 가짜 웹 환경에서 테스트) RANDOM_PORT : 실제 웹 환경을 구성 (실제 웹 환경(with tomcat) 에서 테스트) DEFINED_PORT : 실제 웹 환경을 구성 + 지정한 포트에서 동작

2. custom TestExecutionListener 사용

sql 파일을 활용하는 방법도 있지만 스키마 변경(e.g. 추가, 삭제) 때마다 코드를 수정해야 하는 번거로움이 있기 때문에 INFORMATION_SCHEMA.TABLES(mysql 8.0 기준) 에 존재하는 스키마 정보를 가져와 데이터를 초기화하는 AcceptanceTestExecutionListener 를 작성했다.

Spring testContext 는 테스트를 위한 확장, 편의 기능을 TestExecutionListener 를 제공한다. 즉, 편리한 테스트를 위한 편의 기능을 TestExecutionListener 를 통해 제공한다. 대표적인 예시로 MockitoTestExecutionListener 이 존재한다. @MocbBean 어노테이션을 선언하기만 하면 테스트 이전에 해당 리스너에서 모킹(mocking) 하고 테스트가 끝난 시점에서는 모킹을 제거한다.

public class AcceptanceTestExecutionListener extends AbstractTestExecutionListener {

    @Override
    public void beforeTestMethod(final TestContext testContext) {
        final JdbcTemplate jdbcTemplate = getJdbcTemplate(testContext);
        final List<String> truncateQueries = getTruncateQueries(jdbcTemplate);
        truncateTables(jdbcTemplate, truncateQueries);
    }

    private List<String> getTruncateQueries(final JdbcTemplate jdbcTemplate) {
        try (Connection connection = jdbcTemplate.getDataSource().getConnection()) {
            String schema = connection.getCatalog();
            return jdbcTemplate.queryForList(
                "SELECT concat('TRUNCATE TABLE ', TABLE_NAME) "
                    + "FROM INFORMATION_SCHEMA.TABLES "
                    + "WHERE TABLE_SCHEMA = '" + schema + "'", String.class);
        } catch (Exception exception) {
            throw new RuntimeException();
        }
    }

    private JdbcTemplate getJdbcTemplate(final TestContext testContext) {
        return testContext.getApplicationContext().getBean(JdbcTemplate.class);
    }

    private void truncateTables(final JdbcTemplate jdbcTemplate, final List<String> truncateQueries) {
        execute(jdbcTemplate, "SET FOREIGN_KEY_CHECKS = FALSE");
        truncateQueries.forEach(v -> execute(jdbcTemplate, v));
        execute(jdbcTemplate, "SET FOREIGN_KEY_CHECKS = TRUE");
    }

    private void execute(final JdbcTemplate jdbcTemplate, final String query) {
        jdbcTemplate.execute(query);
    }

}

문제 상황 & 원인

문제 : 테스트 데이터가 들어오지 않았던 문제

테스트를 위해 테스트 데이터를 @Sql 어노테이션을 통해 주입하고자 했지만 데이터가 추가되지 않았다.

 @DisplayName("인증 테스트")
@Sql("classpath:member.sql")
public class AuthenticationTest {
    ...
}

원인 : TestExecutionListener 순서로 인한 문제

원인은 TestExecutionListener 순서 문제였다. TestExecutionListener 는 개발자가 명시한 순서에 따라 실행된다. custom TestExecutionListener 작성시 별도로 순서(Ordered) 를 설정이 없으면 우선 순위가 가장 낮게 설정되어 가장 늦게 수행한다. 반면, @Sql 을 동작시키는 리스너인 SqlScriptsTestExecutionListener 를 확인해보면 순서(Ordered)가 선언되어 있다. 즉, @Sql 실행하고 TRUNCATE 로직이 실행되어 데이터 추가나서 다시 초기화되는 문제였다.(@Sql 실행 → TRUNCATE 실행 🫠)

해결 : custom TestExecutionListener 순서 입력

TRUNCATE 로직 이후에 @Sql 실행되기 위해 Order 값을 SqlScriptsTestExecutionListener 의 값보다 낮게 설정했다. ( TRUNCATE 실행 → @Sql 실행)

public class DataCleanupTestExecutionListener extends AbstractTestExecutionListener {

    @Override
    public int getOrder() {
        return 4500;
    }

}

정상적으로 테스트 데이터가 등록되었다. 👍

오늘의 교훈

custom TestExecutionListener 만들 때는 기존의 TestExecutionListener 와의 순서를 비교해서 값을 추가하자.

기타 지식(properties)

1. sql.init.mode : 스크립트 동작 설정
   • ALWAYS: 모든 데이터베이스에 sql 스크립트를 동작시킨다.
2. spring.jpa.defer-datasource-initialization: true
   • 2.5이상의 버전부터 data.sql 스크립트는 Hibernate가 초기화되기 전에 실행
   • hibernate ddl-auto property 가 동작하고 data.sql 이 동작하도록 하는 옵션

Reference

• https://www.baeldung.com/spring-testexecutionlistener
• https://docs.spring.io/spring-framework/reference/testing/testcontext-framework/bootstrapping.html
• https://mangkyu.tistory.com/264

분산락 (Distributed Lock) 을 사용하는 이유?

1. 분산 환경에서 공유 자원에 관한 상호 배제(mutual exclusion) 을 보장하기 위해 사용한다.
2. 공유 자원의 임계 영역을 접근하는 가능 여부를 확인하여 분산 환경의 원자성(atomic) 을 보장할 수 있다.

분산락을 Tx commit 이후 해제해야 하는 이유

동시성 환경에서 데이터 정합성을 위함이다. 락을 먼저 해제할 경우, 선행 트랜잭션의 내용이 반영되지 않고 후행 트랜잭션 내용만 반영되는 second lost updates problem 문제가 발생할 수 있다.

테스트 해보자

1. 도메인 구성

Promotion

@Entity
@Getter
@ToString
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Promotion {

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   @Column(length = 20)
   private Long id;

   @Getter
   @Column(length = 100, nullable = false)
   private String name;

   @Column(length = 20, nullable = false)
   private int ticketAmount; // shared resources (warning race condition!)

    public Promotion(final String name, final int ticketAmount) {
      this.name = name;
      this.ticketAmount = ticketAmount;
   }

   public void decreaseTicketAmount() {
      this.ticketAmount -= 1;
   }

   public boolean soldOut() {
      return ticketAmount <= 0;
   }

   public int remainingTickets() {
      return this.ticketAmount;
   }

}

Ticker

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Ticket {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(length = 15, nullable = false)
    private Long price;

    @Column(length = 20, nullable = false)
    private Long promotionId;

    public Ticket(final Long price, final Long promotionId) {
        this.price = price;
        this.promotionId = promotionId;
    }

}

1. 연관관계를 사용하는 경우

   • 장점

     1. 매번 티켓 수를 조회하기 위한 조회 쿼리를 동작하므로 race condition 에 관해 할 필요가 없다.

        다만, 여러 트랜잭션이 insert 하는 시점에 따라 티켓 사이즈가 정확히 일치하는 않는 이슈가 발생할 수 있다.

     2. Promotion 안에 Ticket 을 관리하는 형태로 로직을 응집화 할 수 있는 장점이 있다.

   • 단점

     1. 생성된 티켓 수를 확인하기 위한 조회 쿼리가 필요하다.
        • Ticket 테이블의 데이터양이 증가함에 따라 인덱스의 데이터 추가와 DB 부하를 줄 수 있다.

2. 연관 관계를 사용하지 않는 경우(티켓 잔여량을 관리하는 컬럼 활용하는 경우)

   • 장점
     1. 티켓 사이즈를 확인하는 부수적 쿼리를 발생하지 않아 index row insert, query 수행 에 관한 DB 부하를 줄일 수 있는 장점이 있다.
   • 단점
     1. 잔여 티켓 데이터의 race condition 을 고려해야 한다. 동시 접근할 경우, 데이터 정합성이 깨질 수 있다.

2. JMeter 를 이용한 테스트

(1) ticketAmount, user 100개 동일하게 세팅

(1) thread condition

(2) 100개 HTTP Requests

Reference

• https://github.com/pbg0205/BE-tutorials/blob/b9e740377c09de0a79e26d49070f501cb38fbcd2/cooper-lab/spring-redisson-integrity-test/README.md
• https://helloworld.kurly.com/blog/distributed-redisson-lock/

Java 패러다임

(1) Platform Independence - Java applications are compiled into bytecode which is stored in class files and loaded in a JVM. Since applications run in a JVM, they can be run on many different operating systems and devices.

(2) Object-Oriented - Java is an object-oriented language that take many of the features of C and C++ and improves upon them.

(3) Automatic Garbage Collection - Java automatically allocates and deallocates memory so programs are not burdened with that task.

• Java는 메모리를 자동으로 할당하고 할당 해제하므로 프로그램이 해당 작업에 부담을 느끼지 않는다. (= 개발자가 메모리 할당/해제할 필요가 없어 생산성을 증가한다.)

JVM

• 자바 프로그램을 실행시키는 프로그램
• 장점 : 플랫폼 독립성을 보장
  1. 기존 프로그램 실행 방식
     • 소스 코드를 컴파일러(compiler)를 통해 어셈블리어로 변환하고, 변환된 어셈블리어를 다시 어셈블러(assembler)를 통해 기계가 해석할 수 있는 기계어로 변환
  2. Java 실행 방식
     • 자바의 컴파일러를 통해 바이트 코드(Byte Code)라는 특수한 형태의 중간 코드를 생성해 class 확장자를 부여하고, JVM(Java Virtual Machine)이라는 프로그램을 통해 기계어로 번역되어 실행한다.
  3. JVM 의 장점
     • 하나의 소스코드를 통해 class 파일을 생성해서 배포하고, 어느 환경에서나 그 환경에 맞는 JVM만 설치되어 있다면 프로그램을 실행
• 종류 : Hotspot JVM, GraalVM
  • Hotspot JVM : Java 1.3부터는 Hotspot VM이 추가되었고, Hotspot VM에는 2개의 JIT 컴파일러(c1, c2)가 포함되어 있다.
  • GraalVM : JIT 컴파일러들 중에서 기존의 c++로 작성된 C2 컴파일러인 Graal 컴파일러를 Java 기반으로 새롭게 작성된 VM

Key Hotspot Components

성능 튜닝을 위한 JVM component

1. 힙(heap)은 오브젝트 데이터가 저장되는 곳입니다.
2. 대부분의 튜닝 옵션은 힙의 크기를 조정하고 상황에 가장 적합한 가비지 컬렉터를 선택하는 것과 관련이 있다.
3. JIT 컴파일러도 성능에 큰 영향을 미치지만 최신 버전의 JVM에서는 튜닝이 거의 필요하지 않다.

Describing Garbage Collection

1. 힙 메모리를 살펴보고 사용 중인 객체와 사용하지 않는 객체를 식별하여 사용하지 않는 객체를 삭제하는 프로세스
2. 대표적인 알고리즘 : mark-and-sweep algorithm (old GC)
   1. 과정 : marking - normal deletion - deletion with compacting

Step 1: Marking

• 가비지 컬렉터가 사용 중인 메모리 조각과 사용되지 않는 메모리를 식별하는 단계
• RootSet 식별 기준으로 한다.
  • 힙 내의 다른 객체에 의한 참조
  • Java 스택, 즉 Java 메서드 실행 시에 사용하는 지역 변수와 파라미터들에 의한 참조
  • 네이티브 스택, 즉 JNI(Java Native Interface)에 의해 생성된 객체에 대한 참조
  • 메서드 영역의 정적 변수에 의한 참조

Step 2: Normal Deletion

• 참조되지 않은 객체를 제거하여 참조된 객체와 포인터를 여유 공간에 남김

Step 2a: Deletion with Compacting

• 성능을 더욱 향상시키기 위해 참조되지 않는 객체를 삭제하는 것 외에도 나머지 참조 객체를 압축할 수도 있다.

JVM Generations (in Heap Area)

stop the world : 작업이 완료될 때까지 모든 애플리케이션 스레드가 중지됩니다. (minor, major GC 모두 해당)

1. Young Generation : 새로운 객체가 할당되는 공간 (minor GC 공간)
2. Old Generation : 오래 생존한 객체가 할당저장되는 공간(major GC 공간)
   • major GC 는 생존한 모든 객체를 포함하기 때문에 훨씬 느리다.
   • (old object → new object 를 참조하거 같이 제거해야 할 수도 있기 때문이다.) ⇒ card table
   • card table : Old 영역에 있는 객체가 Young 영역의 객체를 참조할 때마다 정보가 표시
3. Permanent generation : 클래스 및 메서드를 설명하는 데 필요한 메타데이터가 포함되어 있습니다.

Old 영역에 대한 GC

• Serial GC
• Parallel GC
• Parallel Old GC(Parallel Compacting GC)
• Concurrent Mark & Sweep GC(이하 CMS)
• G1(Garbage First) GC

Serial GC (-XX:+UseSerialGC)

• old 영역 사용 알고리즘 : mark-and-sweep algorithm
• 적은 메모리와 CPU 코어 개수가 적을 때 적합한 방식
• 운영에서 절대 사용 금지

Parallel GC (-XX:+UseParallelGC)

• Serial GC와 기본적인 알고리즘은 동일
• GC를 처리하는 쓰레드가 여러 개
• Parallel GC는 메모리가 충분하고 코어의 개수가 많을 때 유리

Parallel Old GC(-XX:+UseParallelOldGC)

• Old 영역의 GC 가 Mark-Summary-Compaction 알고리즘 사용
• sweep 대신 summary 과정으로 대체한다.

G1 GC

• GC는 바둑판의 각 영역에 객체를 할당하고 GC를 실행한다. 그러다가, 해당 영역이 꽉 차면 다른 영역에서 객체를 할당하고 GC를 실행한다. (Young, Old 영역과는 아예 다르다.)
• 가장 큰 장점은 성능이다.

Reference

• Oracle - JVM Generations : https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
• Naver D2 - Java Garbage Collection : https://d2.naver.com/helloworld/1329

1. 인증 객체를 주입받는 로직을 추가

@AuthenticationPrincipal??

• SecurityContextHolder 에 존재하는 인증 객체(Principal)를 주입해주는 어노테이션
• AuthenticationPrincipalArgumentResolver 를 통해 Principal 의 subclass 을 주입한다.

AuthenticationPrincipalArgumentResolver ??

(1) AuthenticationPrincipalArgumentResolver ??

• 파라미터로 @AuthenticationPrincipal 를 찾아 인증 객체를 주입해주는 ArgumentResolver
• package org.springframework.security.web.method.annotation 하위에 존재
• spring 4.0 부터 도입

(2) method 살펴보기

supportsParameter

1. 외부에서 MethodParameter의 annotaion 목록을 확인한다. (메서드의 각 파라미터를 탐색하면서 확인)
2. AnnotationUtils를 통해 어노테이션이 AuthenticationPrincipal 타입 을 찾는다.
3. 만약에 어노테이션 타입이 존재하면 해당 annotaion 을 반환하고 그렇지 않으면 null을 반환한다.

public final class AuthenticationPrincipalArgumentResolver implements HandlerMethodArgumentResolver {

        // do something...

        public boolean supportsParameter(MethodParameter parameter) {
            return this.findMethodAnnotation(AuthenticationPrincipal.class, parameter) != null;
        }

        private <T extends Annotation> T findMethodAnnotation(Class<T> annotationClass, MethodParameter parameter) {
            T annotation = parameter.getParameterAnnotation(annotationClass);
            if (annotation != null) {
                return annotation;
            } else {
                Annotation[] annotationsToSearch = parameter.getParameterAnnotations();
                Annotation[] var5 = annotationsToSearch;
                int var6 = annotationsToSearch.length;

                for(int var7 = 0; var7 < var6; ++var7) {
                    Annotation toSearch = var5[var7];
                    annotation = AnnotationUtils.findAnnotation(toSearch.annotationType(), annotationClass); // 여기!
                    if (annotation != null) {
                        return annotation;
                    }
                }

                return null;
    }
}

resolveArgument

1. 해당 메서드의 파라미터에서 @AuthenticationPrincipal annotation 이 있는지를 탐색한다.
2. StandardEvaluationContext 클래스는 해당 표현식(e.g. spEL) 을 평가할 개체를 지정한다. (by. reflection)
3. Expression 객체는 ExpressionParser 을 통해 표현식 문자열 구문 분석을 한 내용과 StandardEvaluationContext 에 평가할 개체를 토대로 원하는 객체를 호출한다.

public final class AuthenticationPrincipalArgumentResolver implements HandlerMethodArgumentResolver {

        // do something...

        public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) {
                Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
                if (authentication == null) {
                    return null;
                } else {
                    Object principal = authentication.getPrincipal();
                    AuthenticationPrincipal annotation = (AuthenticationPrincipal)this.findMethodAnnotation(AuthenticationPrincipal.class, parameter); //(1)
                    String expressionToParse = annotation.expression();
                    if (StringUtils.hasLength(expressionToParse)) {
                        StandardEvaluationContext context = new StandardEvaluationContext(); // (2)
                        context.setRootObject(principal);
                        context.setVariable("this", principal);
                        context.setBeanResolver(this.beanResolver);
                        Expression expression = this.parser.parseExpression(expressionToParse); // (3)
                        principal = expression.getValue(context);
                    }

                    if (principal != null && !ClassUtils.isAssignable(parameter.getParameterType(), principal.getClass())) {
                        if (annotation.errorOnInvalidType()) {
                            throw new ClassCastException(principal + " is not assignable to " + parameter.getParameterType());
                        } else {
                            return null;
                        }
                    } else {
                        return principal;
                    }
                }
           }
}

CustomAnnotation 활용

• 코드 가독성을 위해 @AuthenticationPrincipal 기반한 custom annotation 적용
• 기존 spring 지원 기능을 활용하면 별도의 로직을 작성할 필요가 없기 떄문에 인증 객체 주입 생산성 향상

@Target({ ElementType.PARAMETER })
@Retention(RetentionPolicy.RUNTIME)
@AuthenticationPrincipal
public @interface CurrentUser {
}

@RequiredArgsConstructor
@RestController
@RequestMapping("/api/mypages")
public class MyPageController {

    private final MyPageQueryFacade myPageQueryFacade;
    private final MyPageCommandFacade myPageCommandFacade;

    @GetMapping("/me")
    public ResponseEntity<BaseResponse<UserLookUpResponse>> searchMe(@CurrentUser CurrentUserDto currentUserDto) {
        UserLookUpResponse userLookUpResponse = myPageQueryFacade.findUserWithDetailInfo(currentUserDto.id());
        return ResponseEntity.ok(new BaseResponse<>(USER_LOOK_UP_SUCCESS, userLookUpResponse));
    }
}

인증 객체 Entity → DTO 변환 Custom Resolver 작성

1. 기존 컨트롤러 코드에서 POJO 형태가 아닌 인증객체를 그대로 주입하는 방식으로 구현되어 있었음.
2. sonarcube(정적 코드 분석) 에서 취약성 부분에서 D등급 판정
3. 인증 객체는 엔티티가 상속하고 있어 엔티티 객체를 표현 계층에 할당하여 발생한 원인으로 판단
4. custom resolver 인 CurrenUserDtoArgumentResolver 를 작업하여 반영하여 A 등급으로 판정 변경

코드 변경 이전 등급 판정

CurrentUserDtoArgumentResolver

public class CurrentUserDtoArgumentResolver implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return findMethodAnnotation(CurrentUser.class, parameter) != null;
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); // LoginAuthenticationToken 타입 authentication
        if (authentication == null) {
            return null;
        }

        CustomUser customUser = (CustomUser) authentication.getPrincipal(); // principal을 CustomUser타입으로 변환

        return new CurrentUserDto(customUser.getId(), customUser.getEmail()); // CustomUserDto 타입으로 반환
    }

    private <T extends Annotation> T findMethodAnnotation(Class<T> annotationClass, MethodParameter parameter) {
        T annotation = parameter.getParameterAnnotation(annotationClass);
        if (annotation != null) {
            return annotation;
        }

        Annotation[] annotationsToSearch = parameter.getParameterAnnotations();
        for (Annotation toSearch : annotationsToSearch) {
            annotation = AnnotationUtils.findAnnotation(toSearch.annotationType(), annotationClass);
            if (annotation != null) {
                return annotation;
            }
        }

        return null;
    }
}

코드 변경 등급 판정

3. 인증 객체 테스트 코드 작성

1. 스프링에서 제공하는 @WithMockUser 는 Authentication 의 Pricipal 등록타입이 User 이다.
2. DTO 방식을 등록하기 위해 MockCustomUserSecurityContextFactory 를 선언하고 @WithSecurityContext 를 할당

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@WithSecurityContext(factory = MockCustomUserSecurityContextFactory.class)
public @interface MockCustomUser {

    String value() default "user";

    String username() default "";

    String[] roles() default {"USER"};

    String password() default "password";
}

public class MockCustomUserSecurityContextFactory implements WithSecurityContextFactory<MockCustomUser> {

    @Override
    public SecurityContext createSecurityContext(MockCustomUser annotation) {

        String username = StringUtils.hasLength(annotation.username()) ? annotation.username() : annotation.value();
        Assert.notNull(username, () -> annotation + " cannot have null username on both username and value properties");

        List<GrantedAuthority> authorities = settingRole(annotation);
        CustomUser customUser = new CustomUser(username, annotation.password());
        Authentication authentication = UsernamePasswordAuthenticationToken.authenticated(customUser, "", authorities);

        SecurityContext securityContext = SecurityContextHolder.createEmptyContext();
        securityContext.setAuthentication(authentication);

        return securityContext;
    }

    private List<GrantedAuthority> settingRole(MockCustomUser annotation) {
        List<GrantedAuthority> grantedAuthorities = new ArrayList<>();

        for (String role : annotation.roles()) {
            Assert.isTrue(!role.startsWith("ROLE_"), () -> "roles cannot start with ROLE_ Got " + role);
            grantedAuthorities.add(new SimpleGrantedAuthority("ROLE_" + role));
        }

        return grantedAuthorities;
    }
}

Reference

• https://docs.spring.io/spring-security/reference/servlet/integrations/mvc.html#mvc-authentication-principal
• https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/web/method/annotation/AuthenticationPrincipalArgumentResolver.html
• https://zuminternet.github.io/ZUM-PILOT-WONOH/
• https://tecoble.techcourse.co.kr/post/2020-09-30-spring-security-test/

(1) MySQL Engine

• 역할
  • 쿼리의 실행 계획을 수립해 handler(e.g. storage engine) 로 전달하는 역할
• 구조
  • 쿼리 파서 : 문법 체크 + 파서 트리 만들기
  • 전처리기 : 파서 트리의 구조 문제 파악
  • 옵티마이저 : 실행 계획 수립
  • 실행 엔진 : 실행 계획대로 각 핸들러의 요청 결과를 연결해 사용자에게 전달 (DispatcherServlet 과 같은 역할)

(2) Storage Engine (handler)

• 역할
  • 실행 엔진의 요청에 따라 데이터를 디스크 저장 또는 조회하는 담당
• 구조
  1. In-memory structure
     1. InnoDB buffer pool
        • Adaptive Hash Index
        • Change Buffer
     2. Log Buffer
  2. On-Disk Structure
     1. System Tablespace
     • Doublewrite Buffer Files
     • Undo Tablespaces
     • RedoLog Files
     • File-Per-Table Tablespaces
     • General Tablespaces
     • Temporary Tablespaces

(출처 : RealMySQL 4장. 아키텍처)

2. InnoDB 기능

1. PK 기반 클러스터링 인덱스 지원
   • PK 기반 순서대로 저장
   • PK 기반 레인지 스캔은 빠르게 처리됨
2. 외래키 지원
   • 데이터 변경 시 데이터 체크 작업 필요 → 잠금이 여러 테이블에 전파 → 데드락 위험 ↑
   • foreign_key_checks : 외래키 체크 작업 ON/OFF 시스템 변수
3. MVCC 기능 지원
   1. 언두 로그
      • 장점
        1. 트랜잭션 보장
        2. 격리 수준 보장
4. 자동 데드락 감지
5. 장애 복구 자동화
6. 쓰기 지연 기능 (by. buffer pool)

MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령 하려면 반드시 핸들러를 통해야 한다.

3. InnoDB 구조

1. In-memory Structures
   • Buffer Pool
     • Adaptive Hash Index (자주 접근하는 컬럼 내용에 관한 인덱스)
     • Change Buffer (Secondary Index 변경 내용 버퍼링)
   • Log buffer (Redo Log 변경 내용 버퍼링)
2. On-Disk Structures
   • DoubleWrite Buffer(플러시 이전에 더티 페이지들을 묶어 관리해 장애 복구에 사용)

(1) In-memory Structures

• Buffer Pool
  • Adaptive Hash Index
  • Change Buffer
• Log buffer

1. Buffer Pool
   • 테이블 및 인덱스 데이터 캐싱을 목적으로 하는 메인 메모리 영역
   • 장점 : 쓰기 작업 지연, 장애 복구 (with. Double Write Buffer)
   • 구성 : Data Page, Index Page, Undo Page, Lock Info, Change Buffer
     • 언두 로그?
       • 데이터의 변경 이력을 저장하는 공간 (MVCC)
       • 장점 : 트랜잭션 보장, 격리 수준 보장
2. Adaptive Hash Index
   1. 역할
      • 자주 사용되는 컬럼을 해시로 정의하여 B-Tree Index 대신 직접 Data 에 엑세스 가능
   2. 장점
      • Tx 기능 or 신뢰성 저하 없이 In-memory Database 와 같은 작업 성능을 낸다.
3. Change Buffer (구 : Insert Buffer)
   1. 역할
      • Secondary Index Page 의 변경 내용을 캐싱하기 위한 임시 공간
   2. 동작 과정
      1. 변경할 Secondary Index Page 가 Buffer Pool 에 존재할 경우, 바로 메모리 내 변경 가능
      2. 변경할 Secondary Index Page 가 Buffer Pool 에 없는 경우, 변경 내역만 Change Buffer 에 저장, 향 후 disk 에 플러시
4. Log Buffer (구 : Redo Log Buffer)
   1. 역할
      • Redo Log 파일에 기록할 Data 를 보관하는 메모리 영역
        • Redo Log?
          • 완료되지 않는 Tx 에 의해 변경된 Data 를 적용하기 위해 사용
   2. 동작 과정
      1. Buffer Pool 의 데이터를 변경할 때 먼저 변경사항을 Log Buffer 에 기록
      2. 설정 주기 혹은 Tx commit 시점에 디스크와 동기화

undo log 와 redo log 차이

1. undo log : 트랜잭션 보장과 격리 수준에 맞는 일관성있는 데이터 읽기를 위한 단일 Tx 에 관한 레코드 모임 (for. MVCC)
2. redo log : Crash Recovery 수행 시 완료되지 않은 트랜잭션에 의해 변경된 Data 적용하기 위함. (for. 데이터 동기화)

References

1. RealMySQL 4장 아키텍처
2. [DB 인사이드] MySQL Architecture - 6. InnoDB : In-Memory Structure

summary

1. SpringBoot 를 사용한다면 application.properties 를 선언해서 MessageSource 를 관리하자.
   1. MessageAutoConfiguration 은 MessageSource 빈을 선언하지 않으면 자동 설정된다.
   2. application.properties 에서 spring.messages 로 시작하는 property 를 탐색해서 MessageSource 를 생성한다.

1. MessageSource 설정 및 선언 방법

[1] MessageSource 선언 방법

(1) application.properties 선언하는 방법

spring.messages.basename=message/messages
spring.messages.encoding=UTF-8 # default
spring.messages.fallbackToSystemLocale=false

(2) MessageSource Bean 선언

@Configuration
public class MessageSourceConfig {
    @Bean
    public MessageSource messageSource() {
        ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
        messageSource.setBasenames("customMessage/messages");
        messageSource.setFallbackToSystemLocale(false);
        messageSource.setDefaultEncoding("UTF-8");

        return messageSource;
    }
}

[2] message 선언 방법

• basename 하위에 message_언어코드_국가코드.properties(.xml) 선언하기

2. MessageSourceAutoConfiguration

[1] META-INF/spring/spring-autoconfigure-metadata.properties

• META-INF/spring/spring-autoconfigure-metadata.properties 를 확인해보면 MessageSourceAutoConfiguration 이 존재하는 것을 확인

[2] MessageSourceAutoConfiguration 활성 조건 확인

(1) 설정 어노테이션 확인

• 위치 : org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration

@ConditionalOnMissingBean(name = AbstractApplicationContext.MESSAGE_SOURCE_BEAN_NAME, search = SearchStrategy.CURRENT)

1. messageSource bean 이름이 존재하지 않을 경우
2. SearchStrategy
   • BeanFactory 계층 구조에서 bean 에 대한 명명된 검색 전략.
   • CURRENT : Search only the current context.

(2) ResourceBundleCondition

[1] getMatchOutcome

1. basename 을 application.properties(application.yml) 에서 spring.messages.basename 속성에 대한 값을 가져온다. 없을 경우, “messages” 문자열 반환
2. cache 에 basename 으로 저장된 값이 있는지 확인한다. 만약 저장된 값이 없을 경우, getMatchoutcomeForBasename 을 호출하고 결과 값을 outcome 에 할당한다.
3. outcome 을 cache 변수에 할당한다.

[2] getMatchoutcomeForBasename

1. basename 리스트를 만들고 getResources 에 해당 basename 을 담아 호출한다.
2. getResource() 리턴 값인 Resource 의 값 존재유무를 확인한다.
3. 존재하는 자원이 있다면, match = true 인 outcome을 반환한다.

[3] getResources

1. classpath 내에 basename에 해당하는 properties 파일이 있는지 찾아서 반환한다.
2. classpath 내에 basename에 해당하는 properties 파일이 없다면 자동 설정이 안된다. (따라서 messages.properties 와 같은 기본 파일을 설정해두는 것이 좋을 듯 하다.

[3] MessageSource 생성 조건을 확인해보자

• 위치 : org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration

1. MessageSourceProperties 를 설정하고 MessageSource 을 빈으로 생성한다.

[4] MessageSource : AutoConfiguration vs Custom

(1) AutoConfiguration : properties 기반 설정

spring.messages.basename=message/messages
spring.messages.encoding=UTF-8
spring.messages.fallbackToSystemLocale=false

1. spring.messages.basename
   • spring message 의 properties 기본 이름
   • e.g. message directory 의 message 로 시작하는 파일(properties or yml) 을 탐색한다는 의미
2. spring.messages.encoding
   • 인코딩 방식
3. fallbackToSystemLocale
   • 요청받은 locale 에 대한 메세지 파일이 없을 때, 시스템 locale을 사용할 것인지에 대한 옵션
     • true : 환경설정 언어에 해당하는 영어용 메세지 파일을 가져온다.
     • false : 기본 메세지 파일에서 메세지를 가져온다.

(2) Custom : MessageSource 빈 선언

@Configuration
public class MessageSourceConfig {
    @Bean
    public MessageSource messageSource() {
        ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
        messageSource.setBasenames("customMessage/messages");
        messageSource.setFallbackToSystemLocale(false);
        messageSource.setDefaultEncoding("UTF-8");

        return messageSource;
    }
}

(3) 결론 : Custom 설정이 우선 순위가 높다.

• MessageSourceAutoConfiguration 에서 messageSource 이름으로 시작하는 MessageSource 이 있으면 자동 설정이 활성화되지 않기 때문이다.

// 여기
@ConditionalOnMissingBean(name = AbstractApplicationContext.MESSAGE_SOURCE_BEAN_NAME, search = SearchStrategy.CURRENT)
public class MessageSourceAutoConfiguration {

[1] AbstractHttpConfigurer

(1) AbstractHttpConfigurer

1. disable() : 해당 AbstractHttpConfigurer 를 비활성화 시키는 기능을 제공하며 builder() 메서드를 통해 HttpSecurityBuilder 를 반환한다.
   • HttpSecurityBuilder : 시큐리티 설정을 관리하는 builder 인터페이스

[2] HttpBasicConfigurer

1. AbstractHttpConfigurer abstract class 의 구현체이며, Basic Authentication 을 지원하는 설정을 담당하는 구현체이다.

(1) HttpBasicConfigurer.init()

1. SecurityConfigure interface 의 override 메서드이다.
2. BasicAuthentication 관련된 MediaTypeRequestMatcher, DefaultEntryPoint, DefaultLogoutHandler 기본 설정을 초기화한다.

(2) HttpBasicConfigurer.configure()

1. SecurityConfigure interface 의 override 메서드이다.
2. BasicAuthenticationFilter 설정 (e.g. AuthenticationManager, AuthenticationDetailsSource, RememberMeServices)

[3] AbstractConfiguredSecurityBuilder

(1) AbstractConfiguredSecurityBuilder.dobuild()

1. init(), configure() : SecurityConfigurer 에 선언된 설정들을 초기화, 설정하는 메서드를 호출한다.
   • 해당 메서드는 SecurityFilterChain bean 을 생성하면 해당 설정들이 세팅된다.
     • e.g. defaultSecurityFilterChain (SecurityFilterChainConfiguration) : 해당 설정은 사용자가 정의하면 해당 설정은 덮어쓰기 된다.(back-off)

[4] Basic Authentication

(1) WWW-Authenticate

1. WWW-Authenticate header (response) : 사용자 이름과 비밀번호를 제공하라는 의미로 401 status code 와 함께 요청을 반려하는 헤더. 서버에는 각 다른 비밀번호가 있는 영역들이 있을 것이므로 헤더에 해당 영역을 설명한다.
   • 예시 : WWW-Authenticate : Basic realm="localhost"

(2) 요청 흐름

1. 서버는 클라이언트에게 401 (Unauthorized) status code 를 응답하며, 최소한 한 번의 시도에 포함된 WWW-Authenticate (en-US) 응답 헤더로 권한을 부여하는 방법에 대한 정보를 제공한다.
2. 서버와 인증을 하기를 원하는 클라이언트는 Authorization 요청 헤더 필드에 인증 정보를 포함함으로써 인증을 수행할 수 있다.
3. 클라이언트는 대개 사용자에게 비밀번호 프롬프트를 표시할 것이고 정확한 Authorization 헤더를 포함하는 요청을 만들 것입니다.

[5] Basic Authentication in spring security

(1) 요청 흐름

1. /private URL 에 미인증 요청(unauthenticated request) 하면, AuthorizationFilter 에서 AccessDeniedException 예외를 던진다.
2. 미인증 이후 ExceptionTraslationFilter 는 인증을 시작한다.
   • AuthenticationEntryPoint 의 구현체인 BasicAuthenticationEntryPoint 는 WWW-Authenticate header 를 반환한다.
3. WWW-Authenticate header 를 전달받은 client 는 username, password 를 포함하여 요청을 재시도한다.

(2) 인증 과정

1. BasicAuthenticationFilter는 HttpServletRequest 에서 username, password 를 추출해 UsernamePasswordAuthenticationToken 을 생성한다.
2. AuthenticationManager 에 토큰을 넘겨 인증을 한다.
   • fail
     • SecurityContextHolder 를 비운다.(clear out)
     • RememberMeServices.loginFail 을 호출한다. (만약 설정되지 않았을 경우, 미동작)
     • AuthenticationEntryPoint을 호출해 WWW-Authenticate 헤더를 다시 전달한다.
   • success
     • SecurityContextHoler 에 인증 객체를 보낸다.
     • RememberMeServices.loginSuccess 을 호출한다.
     • BasicAuthenticationFilter 의 FilterChain.doFilter(request,response) 을 호출의 이후 로직을 진행시킨다.

(3) 설정 방법

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
    http
        // ...
        .httpBasic(withDefaults());
    return http.build();
}

QueryDSL 메서드를 통해서 1:N 연관관계를 조회한 데이터를 transform() 메서드를 통해 일괄적으로 DTO 로 변환하여 조회하는 로직을 작성했지만 Connection Leak 이 발생했던 문제가 있었다. 아래가 문제의 쿼리이다.

@RequiredArgsConstructor
public class StudentRepositoryImpl implements StudentRepositoryCustom {

    private final JPAQueryFactory jpaQueryFactory;

    //...

    @Override
    public List<StudentLookupResponse> findAllByStudentIds(List<Long> studentIds) {
        return jpaQueryFactory.select(student)
                .from(student)
                .leftJoin(award).on(student.id.eq(award.student.id))
                .where(student.id.in(studentIds))
                .transform(groupBy(student.id)
                        .list(Projections.constructor(StudentLookupResponse.class,
                                student.id,
                                student.name,
                                student.tagName,
                                GroupBy.list(
                                        Projections.constructor(AwardLookupResponse.class,
                                                award.id,
                                                award.name))
                                )
                        )
                );
    }
}

[2] transform() 메서드 동작 후, ConnectionLeak 확인

hikari pool 의 로깅 레벨을 설정하여 Connection Pool 을 확인해보았다. 실제 API 를 6회 요청을 하고 로그를 확인해보면 HikariPool 의 active -> idle 로 전환되지 않았다.

logging:
  level:
    com.zaxxer.hikari: TRACE
    com.zaxxer.hikari.HikariConfig: DEBUG

[3] @Transactional 을 선언하지 않으면 transform() 사용시 EntityManager 는 닫히지 않는다!

source : Querydsl에서 transform 사용시에 DB connection leak 이슈

(1) transform() 메서드 내부 확인하기

1. iterate(), fetch() 메서드 두가지를 비교해보자.
   1. 공통점
      • createQuery() 호출
   2. 차이점
      • iterate() -> queryHandler.iterate() 반환
      • fetch -> getResultList(query) 반환

package com.querydsl.jpa.impl;

public abstract class AbstractJPAQuery<T, Q extends AbstractJPAQuery<T, Q>> extends JPAQueryBase<T, Q> {

    @Override
    public CloseableIterator<T> iterate() {
        try {
            Query query = createQuery();
            return queryHandler.iterate(query, projection);
        } finally {
            reset();
        }
    }

    @Override
    @SuppressWarnings("unchecked")
    public List<T> fetch() {
        try {
            Query query = createQuery();
            return (List<T>) getResultList(query);
        } finally {
            reset();
        }
    }
}

(2) SharedEntityManagerCreator 의 invoke() 메서드를 확인하자.

1. 현재 트랜잭션에 참여하고 있는 EntityMaager 를 조회한다. 존재하지 않을 경우 새로운 EntityManager 를 생성한다.
2. 현재 생성된 EntityManager 의 메서드를 활용하기 위해서 DeferredQueryInvocationHandler Proxy 생성해서 반환한다.
3. DeferedQueryInvocationHandler 은 SharedEntityManager에서 비트랜잭션 createQuery()가 호출될 때 해당 쿼리 객체를 처리한다.
4. DeferedQueryInvocationHandler proxy의 invoke() 메서드를 실행하고 queryTerminationMethod 미리 정의해둔 method name일 경우에는 entityManager를 종료한다.

public abstract class SharedEntityManagerCreator {

    private static class SharedEntityManagerInvocationHandler implements InvocationHandler, Serializable {

        @Override
        @Nullable
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            // (1) 트랜잭션 참여하면 target 값을 반환하지 않는다.
            EntityManager target = EntityManagerFactoryUtils.doGetTransactionalEntityManager(
                    this.targetFactory, this.properties, this.synchronizedWithTransaction);

            // ...
            try {
                Object result = method.invoke(target, args);
                if (result instanceof Query) {
                    Query query = (Query) result;
                    if (isNewEm) {
                        Class<?>[] ifcs = cachedQueryInterfaces.computeIfAbsent(query.getClass(), key ->
                                ClassUtils.getAllInterfacesForClass(key, this.proxyClassLoader));

                        // (2) DeferredQueryInvocationHandler 생성해서 다른 곳에서 호출
                        result = Proxy.newProxyInstance(this.proxyClassLoader, ifcs,
                                new DeferredQueryInvocationHandler(query, target)); 
                        isNewEm = false;
                    }
                    else {
                        EntityManagerFactoryUtils.applyTransactionTimeout(query, this.targetFactory);
                    }
                }
                return result;
            }
            catch (InvocationTargetException ex) {
                throw ex.getTargetException();
            }
            finally {
                if (isNewEm) {
                    EntityManagerFactoryUtils.closeEntityManager(target);
                }
            }
        }

    private static class DeferredQueryInvocationHandler implements InvocationHandler {

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            // ...

            try {
                // ...
            }
            catch (InvocationTargetException ex) {
                throw ex.getTargetException();
            }
            finally {
                // (3) queryTerminatingMethods 포함되면 EntityManager 를 닫는다.
                if (queryTerminatingMethods.contains(method.getName())) { 
                    if (this.outputParameters != null && this.target instanceof StoredProcedureQuery) {
                        StoredProcedureQuery storedProc = (StoredProcedureQuery) this.target;
                        for (Map.Entry<Object, Object> entry : this.outputParameters.entrySet()) {
                            try {
                                Object key = entry.getKey();
                                if (key instanceof Integer) {
                                    entry.setValue(storedProc.getOutputParameterValue((Integer) key));
                                }
                                else {
                                    entry.setValue(storedProc.getOutputParameterValue(key.toString()));
                                }
                            }
                            catch (IllegalArgumentException ex) {
                                entry.setValue(ex);
                            }
                        }
                    }
                    EntityManagerFactoryUtils.closeEntityManager(this.entityManager);
                    this.entityManager = null;
                }
            }
        }
}

(3) queryTerminationMethod 포함되야 EntityManager 닫힌다.

DeferredQueryInvocationHandler 의 invoke() 메서드를 확인해보면 queryTerminatingMethods 에 정의된 메서드 이름에서 iterate() 가 포함되어 있지 않다. 즉, transform() 메서드의 내부 호출인 iterate() 메서드는 엔티티 매니저를 닫히지 않아 Connection 을 반환하지 않는 문제였다.

[4] @Transactional 은 작업이 완료되면 EntityManager 를 닫는다.

(1) 트랜잭션 핵심 컴포넌트 : TransactionInterceptor

간단히 스프링에서 제공하는 @Transactional 을 선언 시의 동작 방식을 보자. 트랜잭션을 수행하는데 여러 컴포넌트들이 사용되지만 핵심 컴포넌트는 TransactionInterceptor 이다. TransactionInterceptor 은 부모 클래스인 AbstractPlatformTransactionManager 의 invokeWithinTransaction() 메서드를 호출하며 전체 트랜잭션이 동작한다.

(2) AbstractPlatformTransactionManager. invokeWithinTransaction() 내부에 핵심이 있다.

AbstractPlatformTransactionManager 의 invokeWithinTransaction() 를 내부 로직의cleanupAfterCompletion()) 메서드를 확인해보자. 해당 메서드는 트랜잭션이 완료(commit or rollback) 시점에 ThreadLocal 의 트랜잭션 정보를 반환하면서 엔티티 매니저를 닫는다. EntityManager 를 닫으면서 사용한 Connection 을 ConnectionPool 에 반환하기 때문에 @Transactional 어노테이션을 선언하면 Connection 을 반환한다. 그러므로 transform() 메서드의 connection leak 을 방지하기 위해서는 꼭 @Transactional 을 선언해서 사용하도록 해야 한다.

public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {

    private void processCommit(DefaultTransactionStatus status) throws TransactionException {
        try {
            try {
                // ...                                
                else if (status.isNewTransaction()) {
                    // ...
                    doCommit(status); // 커밋하기 (구현체: JpaTransactionManager)
                }
                // ...                
            }
        }
        finally {
            // 트랜잭션 정보 제거
            cleanupAfterCompletion(status);
        }
    }

    private void cleanupAfterCompletion(DefaultTransactionStatus status) {
        status.setCompleted();
        if (status.isNewSynchronization()) {
            TransactionSynchronizationManager.clear();
        }
        if (status.isNewTransaction()) {
            doCleanupAfterCompletion(status.getTransaction()); // 여기 들어가면 EntityManager 다는 로직 있음.
        }
        if (status.getSuspendedResources() != null) {
            if (status.isDebug()) {
                logger.debug("Resuming suspended transaction after completion of inner transaction");
            }
            Object transaction = (status.hasTransaction() ? status.getTransaction() : null);
            resume(transaction, (SuspendedResourcesHolder) status.getSuspendedResources());
        }
    }

    @Override
    protected void doCleanupAfterCompletion(Object transaction) {
        // ...

        if (txObject.isNewEntityManagerHolder()) {
            EntityManager em = txObject.getEntityManagerHolder().getEntityManager();
            if (logger.isDebugEnabled()) {
                logger.debug("Closing JPA EntityManager [" + em + "] after transaction");
            }
            EntityManagerFactoryUtils.closeEntityManager(em); // EntityManager 닫기!
        }
        else {
            logger.debug("Not closing pre-bound JPA EntityManager after transaction");
        }
    }


}

(3) (번외) QueryDSL? Hibernate? 에서 해결할 문제인가?

[Querydsl repo] Connection leak when using FetchableQueryBase#transform outside of a transaction #3089

실제 QueryDSL repository 에서도 관련 이슈에 대해 이야기하고 있지만 querydsl 가 아닌 것으로 판단하고 있다. 그 이유는 트랜잭션이 활성화되지 않을 때는 Connection 을 생성하는 주체는 Hibernate 이며 따라서 트랜잭션을 닫는 주체는 Hibernate 인 것으로 이야기하며 모든 메서드에 @Transactional 을 선언하는 것을 권장하고 있다.

[5] References

• Querydsl에서 transform 사용시에 DB connection leak 이슈
• [spring-framework-orm] SharedEntityManagerCreator
• [Querydsl] Connection leak when using FetchableQueryBase#transform outside of a transaction

해시 테이블은 Key, Value 형테로 데이터를 저장하는 자료구조이며, 평균 시간 복잡도가 O(1) 인 만큼 빠른 검색 속도를 제공한다. 해시 테이블이 빠른 속도를 제공하는 이유는 해시함수(hash function) 와 해시 테이블(hash table)의 버킷(bucket) 덕분이다. 해시 함수(hash function) 은 Key 값을 해시(Hash) 로 변환해주는 함수를 말하고, 버킷(bucket) 은 해시 테이블의 값을 저장하는 공간이다.

[2] 해시테이블 동작원리

Key 값을 해시 함수(Hash Function) 을 거쳐 해시 값(Hash) 을 변환하여 해시테이블의 특정 버킷의 저장할 인덱스를 설정하고 Key, Value, Hash 와 같은 값들을 저장한다. - 해시 함수(Hash Function) : 임의의 데이터를 정수(Integer) 로 변환하는 함수

[3] 해시 함수

해시 함수는 크게 Division Method, Digit Folding, Multiplication Method, Univeral Hashing 기법이 존재한다.

1. Division Method: 나눗셈을 이용하는 방법으로 입력값을 테이블의 크기(bucket size)로 모듈러 연산을 통해 인덱스를 결정한다. ( 주소 = 입력값 % 버킷 사이즈) 테이블의 크기를 소수로 정하고 2의 제곱수와 먼 값을 사용해야 효과가 좋다고 알려져 있다.
2. Digit Folding: 각 Key의 문자열을 ASCII 코드로 바꾸고 값을 합한 데이터를 테이블 내의 주소로 사용하는 방법이다.
3. Multiplication Method: 숫자로 된 Key값 K와 0과 1사이의 실수 A, 보통 2의 제곱수인 m을 사용하여 다음과 같은 계산을 해준다. h(k)=(kAmod1) × m
4. Univeral Hashing: 다수의 해시함수를 만들어 집합 H에 넣어두고, 무작위로 해시함수를 선택해 해시값을 만드는 기법이다.

[4] Hash collision

해시 함수의 결과가 같을 경우의 데이터를 관리하는 방법을 말한다. 해시 테이블 bucket 의 데이터를 관리하는 방법은 크게 open address, seperate chaining 을 통해 해결하고 있다.

(1) 분리 연결법(seperate chaining)

Seperating Chaining 은 동일한 버킷의 데이터에 LinkedList 와 같은 자료구조를 추가해 다음 데이터 주소를 저장하는 것을 말한다. Seperating Chaining 방식은 해시 테이블의 확장이 필요없고 간단하게 구현하는 것이 가능하지만 동일한 버킷의 체이닝되는 데이터가 많아지면 탐색 속도가 떨어지는 단점이 있다.

(2) 개방 주소법(Open Addressing)

Open Addressing 은 비어있는 해시 테이블의 버킷을 활용하는 방법이다. Open Addressing 을 구현하기 위한 대표적인 방법은 Linear Probing, Quadratic Probing, Double Hashing Probing 이 존재한다.

1. Linear Probing: 현재의 버킷 index로부터 고정폭 만큼씩 이동하여 차례대로 검색해 비어 있는 버킷에 데이터를 저장한다.
2. Quadratic Probing: 해시의 저장순서 폭을 제곱으로 저장하는 방식이다. 예를 들어 처음 충돌이 발생한 경우에는 1만큼 이동하고 그 다음 계속 충돌이 발생하면 2^2, 3^2 칸씩 옮기는 방식이다.
3. Double Hashing Probing: 해시된 값을 한번 더 해싱하여 해시의 규칙성을 없애버리는 방식이다. 해시된 값을 한번 더 해싱하여 새로운 주소를 할당하기 때문에 다른 방법들보다 많은 연산을 하게 된다.

[5] java 에서의 HashMap

자바에서는 해시 충돌 해결 방법으로 Seperate chaining 방식을 선택하고 있으며, 데이터 접근, 삽입, 삭제 시간 모두 상수 시간에 접근하지만, 같은 해시 값이 늘어난다면 값이 해당 버킷에 대한 검색 시간이 선형 시간으로 변경될 수 있기 때문에 위에서 언급한 해시함수를 선언하는 것에 대해 신중할 필요가 있다. ([이펙티브 자바] 아이템 11. equals를 재정의하려거든 hashCode도 재정의하라)

• image source : https://www.youtube.com/watch?v=ZBu_slSH5Sk

References

• [쉬운코드]맵(map)과 해시 테이블(hash table) 핵심만 모아보기! 맵과 해시 테이블(a.k.a 해시 맵)을 20분간 아주아주아주 알차게 설명합니다!!
• [mangkyu][자료구조] 해시테이블(HashTable)이란?
• A Complete Guide to Open Addressing & its Classification to eliminate Collisions
• [Wikipedia] Hash Table

OSIV(Open Session In View) 란??

OSIV(Open Session In View)은 영속성 컨텍스트 관리 영역을 뷰(View)까지 확장하는 기능이다. Open Session In View라 불리는 이유는 JPA의 구현체인 Hibernate 에서 EntityManager의 구현체로 Session 을 사용한다. JPA에서는 OEIV(Open-EntityManager-In-View) 로 부르지만 통상적으로 Open-Session-In-View 로 부른다.

Spring-Boot 의 프로퍼티 기반 OSIV 설정 과정

Spring-Boot 는 프로퍼티를 기반으로 한 자동 설정을 지원한다. JpaBaseconfiguration 추상 클래스의 nested static class 인 JpaWebConfiguration 에에 OSIV 를 담당하는 인터셉터인 OpenEntityanagerInViewInterceptor 를 활성 여부를 관리한다. spring.jpa.open-in-view 프로퍼티를 통해 관리되며 별도의 설정이 없을 경우에는 OpenEntityanagerInViewInterceptor 는 빈으로 등록되고 인터셉터로 관리된다.

spring.jpa.open-in-view: false # default value = true

package org.springframework.boot.autoconfigure.orm.jpa;

// imports ...

@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties(JpaProperties.class)
public abstract class JpaBaseConfiguration implements BeanFactoryAware {

    private final DataSource dataSource;

    // 여기에 JpaProperties
    private final JpaProperties properties; 

    private final JtaTransactionManager jtaTransactionManager;

    private ConfigurableListableBeanFactory beanFactory;

    @Configuration(proxyBeanMethods = false)
    @ConditionalOnWebApplication(type = Type.SERVLET)
    @ConditionalOnClass(WebMvcConfigurer.class)
    @ConditionalOnMissingBean({ OpenEntityManagerInViewInterceptor.class, OpenEntityManagerInViewFilter.class })
    @ConditionalOnMissingFilterBean(OpenEntityManagerInViewFilter.class)
    @ConditionalOnProperty(prefix = "spring.jpa", name = "open-in-view", havingValue = "true", matchIfMissing = true)
    protected static class JpaWebConfiguration {

        private static final Log logger = LogFactory.getLog(JpaWebConfiguration.class);

        private final JpaProperties jpaProperties;

        protected JpaWebConfiguration(JpaProperties jpaProperties) {
            this.jpaProperties = jpaProperties;
        }

        // 실제 OSIV 를 담당하는 OpenEntityManagerInViewInterceptor 가 빈으로 선언되는 부분
        @Bean
        public OpenEntityManagerInViewInterceptor openEntityManagerInViewInterceptor() {
            if (this.jpaProperties.getOpenInView() == null) {
                logger.warn("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");
            }
            return new OpenEntityManagerInViewInterceptor();
        }

        @Bean
        public WebMvcConfigurer openEntityManagerInViewInterceptorConfigurer(
                OpenEntityManagerInViewInterceptor interceptor) {
            return new WebMvcConfigurer() {

                @Override
                public void addInterceptors(InterceptorRegistry registry) {
                    registry.addWebRequestInterceptor(interceptor);
                }

            };
        }

    }

OpenEntityManagerInViewInterceptor 의 기본 동작을 확인해보자.

실제 코드를 확인해보면 요청이 들어올 경우에는 엔티티 매니저를 생성하고, 요청이 완료되는 경우에는 엔티티 매니저를 종료하는 것을 확인할 수 있다. 이외에도 엔티티 매니저가 관리되기 위한 TransactionSynchronizationManager, AsyncRequestInterceptor 와 같이 트랜잭션 동기화, 비동기를 위한 작업을 위한 설정이 있는 것을 확인해볼 수 있다.

package org.springframework.orm.jpa.support;

// imports ...

public class OpenEntityManagerInViewInterceptor extends EntityManagerFactoryAccessor implements AsyncWebRequestInterceptor {

    public static final String PARTICIPATE_SUFFIX = ".PARTICIPATE";


    @Override
    public void preHandle(WebRequest request) throws DataAccessException {
        String key = getParticipateAttributeName();
        WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
        if (asyncManager.hasConcurrentResult() && applyEntityManagerBindingInterceptor(asyncManager, key)) {
            return;
        }

        EntityManagerFactory emf = obtainEntityManagerFactory();
        if (TransactionSynchronizationManager.hasResource(emf)) {
        // 트랜잭션 동기화와 관련된 로직
        }
        else {
            logger.debug("Opening JPA EntityManager in OpenEntityManagerInViewInterceptor");

            // EntityManager 가 생성된다.
            try {
                EntityManager em = createEntityManager();
                EntityManagerHolder emHolder = new EntityManagerHolder(em);
                TransactionSynchronizationManager.bindResource(emf, emHolder);

                AsyncRequestInterceptor interceptor = new AsyncRequestInterceptor(emf, emHolder);
                asyncManager.registerCallableInterceptor(key, interceptor);
                asyncManager.registerDeferredResultInterceptor(key, interceptor);
            }
            catch (PersistenceException ex) {
                throw new DataAccessResourceFailureException("Could not create JPA EntityManager", ex);
            }
        }
    }

    @Override
    public void afterCompletion(WebRequest request, @Nullable Exception ex) throws DataAccessException {
        if (!decrementParticipateCount(request)) {
            EntityManagerHolder emHolder = (EntityManagerHolder)
                    TransactionSynchronizationManager.unbindResource(obtainEntityManagerFactory());
            logger.debug("Closing JPA EntityManager in OpenEntityManagerInViewInterceptor");
            EntityManagerFactoryUtils.closeEntityManager(emHolder.getEntityManager()); // 2. 엔티티 매니저를 닫는다.
        }
    }

만약 Filter 에서 엔티티를 관리되어야 한다면?

Spring Security 와 같이 FilterChain 기반에서 엔티티를 초기화해야 하는 경우가 있다. 일반적으로 Open-Session-In-View 는 안티 패턴이라 말한다. 요청이 시작, 종료되는 시점까지 DB Connection 을 잡고 있어 실시간 서비스와 같이 트래픽에 민감한 서비스의 경우에 성능 저하 요소가 될 수 있기 때문이다. 하지만 사내의 시스템이 레거시 코드로 인해 필터 쪽에서 엔티티를 초기화해야 되서 불가피하게 사용해야 한다면 OpenEntityManagerInViewFilter 을 선언해서 사용해야 한다. OpenEntityManagerInViewFilter 는 스프링에서 지원해주기 때문에 해당 빈을 등록해서 사용하도록 하자.

(만약 필터와 인터셉터의 차이를 잘 모르는 경우, 아래 블로그 글을 참고하도록 하자.)

• [mangkyu] [Spring] 필터(Filter) vs 인터셉터(Interceptor) 차이 및 용도 - (1)
• [mangkyu] [Spring] 필터(Filter)가 스프링 빈 등록과 주입이 가능한 이유(DelegatingFilterProxy의 등장) - (2)

package org.springframework.orm.jpa.support;

// 여러가지 import

public class OpenEntityManagerInViewFilter extends OncePerRequestFilter {
// 비즈니스 로직
}

// source : https://tecoble.techcourse.co.kr/post/2020-09-20-entity-lifecycle-2/

@Component
@Configuration
public class OpenEntityManagerConfig {
    @Bean
    public FilterRegistrationBean<OpenEntityManagerInViewFilter> openEntityManagerInViewFilter() {
        FilterRegistrationBean<OpenEntityManagerInViewFilter> filterFilterRegistrationBean = new FilterRegistrationBean<>();
        filterFilterRegistrationBean.setFilter(new OpenEntityManagerInViewFilter());
        filterFilterRegistrationBean.setOrder(Integer.MIN_VALUE); // 최우선 순위로 Filter 등록
        return filterFilterRegistrationBean;
    }
}

내가 생각하는 open-session-in-view

흔히 open-session-in-view 를 안티 패턴이라 부른다. 이전에 언급했듯이 실시간 트래픽이 중요한 서비스의 경우, 요청 시점에 EntityManager 가 생성되면서 DB Connection Pool 의 Connection 을 붙잡고 있어 Connection Pool 이 고갈될 수 있는 문제가 발생할 수 있다.

open-session-in-view 를 활성화 할 경우, DB 작업이 모두 완료되고 다른 외부 API 요청을 대기하는 시간까지 Connection 을 반환하지 않는다. 이와 같은 병목지점이 생기고 해당 로직이 많은 사용자가 사용한다면 ConnectionPool 의 Connection 을 모두 잡는다면 Connection 을 반환하기를 기다리는 문제가 발생할 수 있다. 이는 사용자에게 나쁜 사용 경험을 제공해주기 때문에 특별한 이유가 없다면 사용하지 않는 것이 적합한 것 같다.

hikariCP 에서 제공하는 프로퍼티들의 기본 값 정도는 참고로 알고 있자.

 # 주의 : DB 단위 - s, Spring Boot 단위 - ms
 # Spring Boot 설정을 Database 설정보다 적게 설정하는 것을 권장

 spring.datasource.hikari.minimumIdle=30000 #30초
 spring.datasource.hikari.connectionTimeout=30000 #30초
 spring.datasource.hikari.maximumPoolSize=10
 spring.datasource.hikari.idleTimeout=600000 # 10분
 spring.datasource.hikari.maxLifeTime=1800000 # 30분
 spring.datasource.hikari.autoCommit=true

비록 thymeleaf, jsp 와 같은 템플릿 엔진을 어드민 페이지로 사용하는 경우에 편의성을 가져다w주는 장점이 있지만 편리함으로 인해 템플릿 엔진에 의존적인 코드가 발생하고 vue.js 나 react 로 전환할 때의 공수가 늘어날 수 있다. 만약 기존 thymeleaf, jsp 와 같은 템플릿 엔진과 open-session-in-view 활성화해서 개발하고 있다면 최대한 엔티티 초기화를 템플릿 엔진에서 사용하지 않도록 하고, 엔티티 대신에 DTO 를 활용하는 방향으로 코드를 작성하는 방식으로 코드 작업을 하는 것이 낮은 의존성을 기반해서 유지보수하기 용이하지 않을까 싶다.

• 신규 프로젝트에서 사용한다면 open-session-in-view 비활성화 하기
• 기존 프로젝트에서 사용한다면 open-session-in-view 를 비활성화하는 방향으로 작업하기 (e.g. DTO)

summary

1. OSIV 는 영속성 컨텍스트의 라이프 사이클을 요청, 응답이 끝날 때까지 활성화하는 전략을 말한다.
2. OSIV 는 OpenEntityManagerInViewInterceptor, OpenEntityManagerInViewFilter 를 통해 영속화 범위가 확장된다.
3. OSIV 는 다른 로직의 처리가 길어지는만큼 Connection 을 붙잡고 있어 커넥션 고갈이 될 수 있는 문제로 인해 안티 패턴이다. 특별한 이유가 없다면 비활성화해서 사용하자. (비활성화 할경우, 영속성 컨텍스트는 @Transactional 내부에서만 관리된다.)

references

• 자바 ORM 표준 JPA 프로그래밍
• [tecoble] Entity Lifecycle을 고려해 코드를 작성하자 2편
• [spring.io] Common Application Properties - Data Properties