wedul

jooq 사용 시 aop를 사용하는 경우에 application loading이 오래걸리는 이유

wedul — Sat, 24 Jan 2026 23:08:23 +0900

회사에서 jpa를 사용하고 있지 않고 기존에 spring-data-jdbc를 사용하고 있었다. 그리고 대부분은 findById, findAll을 제외한 쿼리는 @Query annotaion을 붙여서 사용하고 있었다.

팀의 다른 프로젝트들이 mybatis, ibatis를 사용하고 있다보니 그대로 쿼리만 가져와서 spring data jdbc를 사용하도록만 바꾼 것 같다. mybatis가 나쁜건 아니지만 런타임시가 아니면 에러를 확인하기도 어렵고 값 매핑도 어렵다 보니 요새는 많이 선호하지 않아서 바꾼것 같은데 사실 annotaion으로 쿼리를 사용한다면 그것도 크게 다르지 않다고 본다.

그래서 입사 후 jooq나 query dsl 형태의 dsl 구조를 도입해서 컴파일 단위에서 타입 세이프한 쿼리를 사용할 수 있도록 기반을 만들고 있다.

그런데 예전에 많이 사용했었던 query-dsl의 경우 엔티티 기반으로 코드를 만들다 보니 Jpa 없이 사용하기가 애매해서 jooq를 사용하기로 했다. jooq는 db schema를 기준으로 코드를 만들다 보니 entity 클래스가 따로 없는 상황에서는 이게 더 컬럼/타입 관리가 편하게 느껴졌다.

그래서 jooq를 도입해서 코드로 쿼리를 짜는 편안함으로 작업을 다하고 나서 애플리케이션 배포를 했는데 애플리케이션 배포가 너무 느렸다.

현상을 확인해보기 위해 디버깅을 해보니 AOP관련 타겟 클래스를 스캔하는 영역으로 의심되는 부분에서 시간이 오래걸렸다. 그래서 테스트를 위해 임시 프로젝트를 만들었다.

테스트

CREATE TABLE member
(
    id         BIGINT AUTO_INCREMENT PRIMARY KEY,
    email      VARCHAR(100) NOT NULL,
    name       VARCHAR(50)  NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE UNIQUE INDEX ux_member_email ON member (email);

CREATE TABLE student
(
    id         BIGINT AUTO_INCREMENT PRIMARY KEY,
    name       VARCHAR(50)  NOT NULL,
    class     VARCHAR(20)  NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);


CREATE table classs
(
    id         BIGINT AUTO_INCREMENT PRIMARY KEY,
    name       VARCHAR(50)  NOT NULL,
    teacher    VARCHAR(50)  NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

jooq 프로젝트를 만들고 h2 db사용하게 하고 해당 스키마 파일을 참조해서 jooq codegenerate하도록 프로젝트를 구성했다.

package com.wedul.jooq;

import com.wedul.jooq.request.MemberRequest;
import lombok.RequiredArgsConstructor;
import org.jooq.DSLContext;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import static com.example.jooq.Tables.MEMBER;


@Service
@RequiredArgsConstructor
public class MemberService {

    private final DSLContext dslContext;

    @Transactional
    public void joinMember(MemberRequest request) {
        dslContext.insertInto(MEMBER)
                .columns(MEMBER.NAME, MEMBER.EMAIL)
                .values(request.name(), request.email())
                .execute();
    }

    @Transactional
    public String getMemberEmail(String name) {
        return dslContext.select(MEMBER.EMAIL)
                .from(MEMBER)
                .where(MEMBER.NAME.eq(name))
                .fetchOneInto(String.class);
    }

}


package com.wedul.jooq;

import org.jooq.DSLContext;
import org.jooq.SQLDialect;
import org.jooq.impl.DSL;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.sql.DataSource;

@Configuration
public class JooqConfiguration {

    @Bean
    public DSLContext dslContext(DataSource dataSource) {
        return DSL.using(dataSource, SQLDialect.H2);
    }

}

// application.yml
spring:
  application:
    name: jooq

  datasource:
    url: jdbc:h2:mem:testdb;MODE=MySQL
    driver-class-name: org.h2.Driver
    username: sa
    password:

  sql:
    init:
      mode: always
      schema-locations: classpath:db/schema.sql

  jooq:
    sql-dialect: H2

logging:
  level:
    org.jooq.tools.LoggerListener: DEBUG


// build.gradle
plugins {
    id 'org.springframework.boot' version '3.1.2'
    id 'io.spring.dependency-management' version '1.1.7'
    id 'java'
    id 'nu.studer.jooq' version '8.0'
}

ext {
    jooqVersion = '3.17.6' // 프로젝트에서 사용할 jOOQ 버전으로 변경
}

group = 'com.wedul'
version = '0.0.1-SNAPSHOT'
description = 'jooq'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

repositories {
    mavenCentral()
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.boot:spring-boot-dependencies:3.1.2"
    }
}

dependencies {
    runtimeOnly 'com.h2database:h2'
    runtimeOnly 'com.mysql:mysql-connector-j'

    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
    implementation 'org.springframework.boot:spring-boot-starter-data-jdbc'

    implementation 'org.jooq:jooq:3.17.6'

    jooqGenerator 'org.jooq:jooq-meta:3.17.6'
    jooqGenerator 'org.jooq:jooq-codegen:3.17.6'
    jooqGenerator 'com.h2database:h2'

    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-aop'

    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

}

tasks.named('test') {
    useJUnitPlatform()
}

jooq {
    version = '3.19.7'

    configurations {
        main {
            generateSchemaSourceOnCompilation = false

            generationTool {
                jdbc {
                    driver = 'org.h2.Driver'
                    url = 'jdbc:h2:mem:jooq_codegen;' +
                            'DB_CLOSE_DELAY=-1;' +
                            'MODE=MySQL;' +
                            "INIT=RUNSCRIPT FROM 'src/main/resources/db/schema.sql'"
                    user = 'sa'
                    password = ''
                }

                generator {
                    name = 'org.jooq.codegen.DefaultGenerator'

                    database {
                        name = 'org.jooq.meta.h2.H2Database'
                        inputSchema = 'PUBLIC'

                        // 필요하면 특정 테이블만
                        // includes = 'member|order.*'
                    }

                    generate {
                        records = true
                        pojos = true
                        daos = false
                        fluentSetters = true
                    }

                    target {
                        packageName = 'com.example.jooq'
                        directory = 'build/generated-src/jooq/main'
                    }
                }
            }
        }
    }
}

기본적인 구성을 다 한 뒤 애플리케이션을 구동해봤다.

구동은 관련 내용이 워낙 적다보니 약 1초정도로 빠르게 되었다.

그리고 의심이 되었던 aop 관련 pointcut을 execution을 사용해서 2개정도 만들어봤다. (회사 프로젝트는 7~10개정도로 많은 pointcut을 사용하고 있다. 동일하게 execution을 사용하고 있다.)

package com.wedul.jooq;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.context.annotation.Configuration;

@Aspect
@Configuration
public class MethodAopConfiguration {

    @Pointcut("execution(* com.wedul.jooq.MemberService.*(..))")
    public void memberServiceMethods() {}

    @Around("memberServiceMethods()")
    public Object around(ProceedingJoinPoint pjp) throws Throwable {

        System.out.println("Method " + pjp.getSignature().getName() + " is called with arguments: ");
        return pjp.proceed();
    }


}

package com.wedul.jooq.request;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.context.annotation.Configuration;

@Aspect
@Configuration
public class ControllerAopConfiguration {

    @Pointcut("execution(* com.wedul.jooq.*Controller.*(..))")
    public void memberControllerMethods() {}

    @Around("memberControllerMethods()")
    public Object around(ProceedingJoinPoint pjp) throws Throwable {

        System.out.println("Controller " + pjp.getSignature().getName() + " is called with arguments: ");
        return pjp.proceed();
    }
}

약 18초정도 걸렸다. 확실히 원인은 aop가 맞는 것 같다.

그래서 Aop 대상객체를 판단하는 AopUtils쪽의 canApply 코드를 확인하는데 aop 대상이 맞는지 판단하는 부분에서 엄청나게 많은 시간이 걸리고 있었다.

그 이유는 jooq로 code generate를 하게 되면 굉장히 많은 클래스들이 생성되는데 이 클래스들이 선언된 aop 대상이 되는지를 판단하는 시간으로 사용되어서 클래스 * 메소드 수 * aop pointcut만큼 시간이 걸린것이다.

그래서 이를 해결하기 위해서는 aop대상인지를 판단하는걸 method level까지 내려가지 않고 class filter 레벨에서 판단이 되도록 수정해 줘야한다.

아래는 문제의 그 코드인데 ClassFilter에서 걸러지면 밑에 해당 클래스에 있는 모든 메소드를 뒤져보는 Method Filter 부분을 보지 않ㅇ을 수 있지만 그렇게 하지 못하면 엄청나게 많은 시간이 소요된다.

public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {
    Assert.notNull(pc, "Pointcut must not be null");
    // ClassFilter 
    if (!pc.getClassFilter().matches(targetClass)) {
        return false;
    }

    MethodMatcher methodMatcher = pc.getMethodMatcher();
    if (methodMatcher == MethodMatcher.TRUE) {
        // No need to iterate the methods if we're matching any method anyway...
        return true;
    }

    IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;
    if (methodMatcher instanceof IntroductionAwareMethodMatcher iamm) {
        introductionAwareMethodMatcher = iamm;
    }

    Set<Class<?>> classes = new LinkedHashSet<>();
    if (!Proxy.isProxyClass(targetClass)) {
        classes.add(ClassUtils.getUserClass(targetClass));
    }
    classes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetClass));

	// method filter
    for (Class<?> clazz : classes) {
        Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);
        for (Method method : methods) {
            if (introductionAwareMethodMatcher != null ?
                    introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions) :
                    methodMatcher.matches(method, targetClass)) {
                return true;
            }
        }
    }

    return false;
}

그럼 어떻게 해결 해야할까? class filter에서 걸릴 수 있도록 이거를 수정해줘야한다. 그렇게 하기 위해서는 메소드 실행 기준을 가지고 있는 execution 대신에 class 타입 기준으로 체크하는 within을 사용해주면 해결할수 있다.

위 두개의 execution pointcut을 아래 within으로 바꾸고 다시실행해봤다.

@Pointcut("within(com.wedul.jooq.MemberService)")
@Pointcut("within(com.wedul.jooq..*Controller)")

1초만에 다시 실행되었다.

관련 issue는 몇가지 git issue에서도 확인이 가능하다. (결론은 aop 범위를 within으로 줄여라..로 이슈는 종결되어있는 것 같다.)

https://github.com/TencentBlueKing/bk-job/pull/2663

https://github.com/jOOQ/jOOQ/issues/5902

jOOQ,spring-boot and aop. · Issue #5902 · jOOQ/jOOQ

Hi, After a migration to jOOQ in an application with the following stack : Java 8 Spring-boot 1.5.1 jOOQ version managed by the boot starter. I had perf issues on startup, after investigation, i fo...

github.com

spring metrics sever, client max-uri-tags

wedul — Fri, 23 Jan 2026 22:44:25 +0900

회사에서 사용하고 있는 서버가 파일관련 서버이다 보니 조건이 많아 호출에 대한 종류가 생각보다 많았다.

호출되는 api도 mvc server endpoint도 100개가 넘었고 내부에서 webclient로 호출하는 외부 api client도 100개가 넘었다.

어느날 새로운 api가 개발이 되고 선 배포 된 이후 실제 배포일자가 되서 호출이 되었는데 metric정보를 찾을수가 없었다. 처음에는 exporter에서 관련 tags cardinality가 높아서 정상 수집이 안되나 확인해봤지만 이슈가 없었고 각 서버에 들어가서 /actuator/prometheus를 통해 수집되는 메트릭 지표를 확인해봤는데 해당 endpoint가 없었다.

하나의 서버에서 이렇게 많은 api를 호출하는것도 호출받는것도 처음이어서 이부분을 모르고 있었다. 기존 팀에서도 해당 지표를 보기보다 모두 커스텀 메트릭으로 저장하고 있어서 해당 부분에 대한 탐지는 내가 그라파나를 추가하면서 드러나게 되었다.

관련해서 현상 확인을 정확하게 하기위해 테스트를 진행해봤다.

end point 100개 이상 생성

package com.wedul.study;

import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DefaultController {

    @ResponseBody
    public String handle() {
        return "wedul";
    }

}


package com.wedul.study;

import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.boot.ApplicationRunner;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.servlet.mvc.method.RequestMappingInfo;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;

import java.lang.reflect.Method;

@Configuration
public class DynamicMappingConfiguration {

    @Bean
    public ApplicationRunner registerMappings(
            @Qualifier("requestMappingHandlerMapping")
            RequestMappingHandlerMapping handlerMapping,
            DefaultController defaultController
    ) {
        return args -> {
            Method method = DefaultController.class.getMethod("handle");

            for (int i = 0; i < 110; i++) {
                RequestMappingInfo info = RequestMappingInfo
                        .paths("/test/" + i)
                        .methods(RequestMethod.GET)
                        .build();
                handlerMapping.registerMapping(info, defaultController, method);
            }
        };
    }

}

RequestMapping을 하나씩 생성하는건 안되고 handlerMapping을 만들어서 추가해주는 방식으로 진행했다.

application.yml

spring:
  application:
    name: study
management:
  endpoints:
    web:
      exposure:
        include: prometheus
  prometheus:
    metrics:
      export:
        enabled: true

metric정보를 볼수 있도록 관련 설정도 추가해줬다.

테스트 코드

package com.wedul.study;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.web.client.RestTemplate;

@SpringBootTest
public class UriEndpointTest {

    private final RestTemplate restTemplate = new RestTemplate();

    @Test
    void test() {
        for (int i = 0; i < 110; i++) {
            String url = "http://localhost:8080/test/" + i;
            restTemplate.getForObject(url, String.class);
        }
    }

}

100개를 넘겨서 호출할수 있도록 110개의 enpoint를 모두 호출 했다.

돌리고 확인해보니 실제 운영에서 겪었었던 것 처럼 동일하게 endpoint가 모두 노출되지 않았다.

로그를 확인해보니 다음과 같은 에러를 확인 할수 있었고

2026-01-23T22:35:14.543+09:00 WARN 17171 --- [study] [nio-8080-exec-9] .s.b.m.m.MaximumAllowableTagsMeterFilter : Reached the maximum number of 'uri' tags for 'http.server.requests'.

spring 문서나 설정되어있는 기본 config를 보면 100으로 설정되어있는걸 확인할 수 있다. (server, client)

management.metrics.web.client.max-uri-tags=100 # Maximum number of unique URI tag values allowed. After the max number of tag values is reached, metrics with additional tag values are denied by filter.

이걸 110으로 수정하고 돌려보면 잘 수집되고 에러메시지도 없는걸 확인 할 수 있다.

지표가 무작정 많이 수집되는건 여러 영향을 줄수 있기 때문에 크기를 어느정도 설정할지에 대해서는 잘 판단하는게 좋을 것 같다. 하지만 이설정이 누락되어서 관련 지표나 알림이 누락될 수 있으니 사전에 확인하는게 좋을 것 같다.

https://docs.spring.io/spring-boot/docs/2.0.0.RELEASE/reference/html/common-application-properties.html

Appendix A. Common application properties

Appendix A. Common application properties Various properties can be specified inside your application.properties file, inside your application.yml file, or as command line switches. This appendix provides a list of common Spring Boot properties and refer

docs.spring.io

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1.0-M3-Configuration-Changelog

https://github.com/weduls/promethus-max-uri-tags-test

swagger OpenApiCustomizer를 사용하여 커스텀 하기

wedul — Sun, 18 May 2025 23:41:22 +0900

회사에서 사용하고 있는 rpc library가 있는데 해당 rpc는 proto를 사용하는것이 아닌 java class로 만든 IDL을 사용하고 있다.

https://youtu.be/iOoquUhKT5g

출처 2023 우아콘

method를 정의하고 method에 사용된 request, response 객체를 사용해서 rpc 호출을 하는 구조이다. 기존에 http로 통신하는 경우에는 spring rest docs를 사용하거나 spring swagger ui를 사용해서 api명세를 편하게 만들어서 외부 사용하는 팀에 전달 할 수 있었다.

하지만 java method기반으로 통신 프로토콜을 정의하는 방식에서는 swagger 기존 방식으로는 사용할 수 없기 때문에 이를 custom해줘야했다. 그 과정에서 문서를 만들기 위해서 custom한 과정을 정리한다.

RequestBody, ApiResponse에 대한 custom annotation으로의 대체

기존에는 @Schema 애노테이션을 붙여서 RequestBody, ApiResponse로 사용될 객체에 클래스 위, 필드위에 설명을 적용할 수 있었다. 하지만 내부 library에 경우 @Schema를 붙여서 사용하지 않고 특정 custom annotation을 사용하고 있다. 여기서는 그 이름을 CustomSchemeAnnotation이라고 했다.

package com.wedul.openapi.annotation;

import io.swagger.v3.oas.annotations.media.Schema;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Schema
@Target({ElementType.FIELD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface CustomSchemeAnnotation {

    String description() default "";

    String example() default "";

    String format() default "";

}

이 Annotation을 기존 @Scheme와 같이 RequestBody, ApiResponse로 사용될 객체에 명세를 작성해줄 수 있다. 여기서는 @Schema에서 제공하는 필드 중 내부적으로 사용할 필드 세가지만 가지고 왔다.

RequestBody (CustomRequest)

package com.wedul.openapi.annotation;

import java.util.List;
import java.util.Map;

@CustomSchemeAnnotation(description = "custom request class")
public class CustomRequest {

    @CustomSchemeAnnotation(description = "custom annotation name", example = "wedul", format = "String")
    private String name;

    @CustomSchemeAnnotation(description = "custom annotation age", example = "10", format = "int")
    private int age;

    @CustomSchemeAnnotation(description = "list of string", example = "[\"classA\", \"classB\"]", format = "array of string")
    private List<String> stringList;

    @CustomSchemeAnnotation(description = "data list example", example = "{\"fieldName\":\"exampleField\"}", format = "array of Data")
    private Data data;

    @CustomSchemeAnnotation(description = "generic string wrapper", example = "{\"value\":\"hello\"}", format = "GenericWrapper<String>")
    private GenericWrapper<String> wrappedString;

    @CustomSchemeAnnotation(description = "generic data wrapper", example = "{\"value\":{\"fieldName\":\"nestedField\"}}", format = "GenericWrapper<Data>")
    private GenericWrapper<Data> wrappedData;

    @CustomSchemeAnnotation(description = "metadata map", example = "{\"key1\": 1, \"key2\": 2}", format = "Map<String, Integer>")
    private Map<String, Integer> metadata;

}



package com.wedul.openapi.annotation;

@CustomSchemeAnnotation(description = "data inner class")
public class Data {
    @CustomSchemeAnnotation(description = "field name in data", example = "exampleField", format = "string")
    private String fieldName;
}


package com.wedul.openapi.annotation;

@CustomSchemeAnnotation(description = "generic wrapper")
public class GenericWrapper<T> {

    @CustomSchemeAnnotation(description = "wrapped value", example = "exampleValue", format = "generic type")
    private T value;
}

ApiResponse

package com.wedul.openapi.annotation;

@CustomSchemeAnnotation
public class CustomResponse {

    @CustomSchemeAnnotation(description = "result Message", example = "this is result.", format = "String")
    private String resultMessage;

    public CustomResponse(String resultMessage) {
        this.resultMessage = resultMessage;
    }

    public CustomResponse() {

    }
}

RestController의 명세인 Operation을 대체 할 Custom annotation

http가 아닌 메소드이름 자체가 path가 되어야한다. OpenApiCustomizer에서 path에 대한 작업을 진행하겠지만 path가 될 method를 명시해야하기 때문에 사용하고자 하는 method에 custom annotation CustomMethodAnnotation를 추가했다.

package com.wedul.openapi.annotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface CustomMethodAnnotation {

    String title();

}

package com.wedul.openapi.annotation;

public class CustomMethodImpl implements CustomMethod {

    @Override
    @CustomMethodAnnotation(title = "test method")
    public CustomResponse test(CustomRequest request) {
        return new CustomResponse();
    }
}

OpenApiCustomizer를 문서 커스텀

기존 open api 문서를 생성하는 방식이 아닌 새롭게 정의한 애노테이션을 사용하도록 해야하고 path를 메소드 이름으로 사용할 수 있도록 커스텀을 진행해야한다. 이를 커스텀 하기 위해서 OpenApiCustomizer를 커스텀을 진행한다.

package com.wedul.openapi.annotation.config;

import com.wedul.openapi.annotation.CustomMethodAnnotation;
import com.wedul.openapi.annotation.CustomSchemeAnnotation;
import io.swagger.v3.core.util.PrimitiveType;
import io.swagger.v3.oas.models.OpenAPI;
import io.swagger.v3.oas.models.Operation;
import io.swagger.v3.oas.models.PathItem;
import io.swagger.v3.oas.models.media.*;
import io.swagger.v3.oas.models.parameters.RequestBody;
import io.swagger.v3.oas.models.responses.ApiResponse;
import io.swagger.v3.oas.models.responses.ApiResponses;
import org.reflections.Reflections;
import org.reflections.scanners.Scanners;
import org.reflections.util.ConfigurationBuilder;
import org.springdoc.core.customizers.OpenApiCustomizer;

import java.lang.reflect.*;
import java.util.List;
import java.util.Map;
import java.util.Set;

public class MethodCustomizer implements OpenApiCustomizer {

    @Override
    public void customise(OpenAPI openApi) {
        Reflections reflections = new Reflections(
                new ConfigurationBuilder()
                        .forPackages("com.wedul")
                        .addScanners(Scanners.TypesAnnotated, Scanners.MethodsAnnotated, Scanners.SubTypes)
        );

        Set<Method> annotatedMethods = reflections.getMethodsAnnotatedWith(CustomMethodAnnotation.class);

        for (Method annotatedMethod : annotatedMethods) {
            CustomMethodAnnotation annotation = annotatedMethod.getAnnotation(CustomMethodAnnotation.class);

            Operation operation = new Operation();
            operation.setSummary(annotation.title());
            operation.setOperationId(annotatedMethod.getName());

            Parameter[] parameters = annotatedMethod.getParameters();
            Class<?> requestType = parameters[0].getType();

            Schema<?> schema = buildSchemaFromCustomAnnotation(requestType, openApi);

            RequestBody requestBody = new RequestBody()
                    .content(new Content().addMediaType("application/json",
                            new MediaType().schema(schema)));
            operation.setRequestBody(requestBody);


            Class<?> returnType = annotatedMethod.getReturnType();
            Schema<?> responseSchema = buildSchemaFromCustomAnnotation(returnType, openApi);

            ApiResponse apiResResponse = new ApiResponse()
                    .content(new Content().addMediaType("application/json",
                            new MediaType().schema(responseSchema)));

            operation.setRequestBody(requestBody);
            operation.setResponses(new ApiResponses().addApiResponse("200", apiResResponse));

            PathItem pathItem = new PathItem().get(operation);
            openApi.path(annotatedMethod.getName(), pathItem);
        }
    }

    public Schema<?> buildSchemaFromCustomAnnotation(Class<?> clazz, OpenAPI openApi) {
        Schema<?> schema = new ObjectSchema();

        CustomSchemeAnnotation classAnnotation = clazz.getAnnotation(CustomSchemeAnnotation.class);
        if (classAnnotation != null) {
            applyCustomAnnotationToSchema(schema, classAnnotation);
        }

        for (Field field : clazz.getDeclaredFields()) {
            field.setAccessible(true);
            CustomSchemeAnnotation fieldAnnotation = field.getAnnotation(CustomSchemeAnnotation.class);
            if (fieldAnnotation != null) {
                Schema<?> fieldSchema = resolveFieldSchema(field.getGenericType(), fieldAnnotation, openApi);
                schema.addProperties(field.getName(), fieldSchema);
            }
        }
        openApi.getComponents().addSchemas(clazz.getSimpleName(), schema);
        return schema;
    }

    private Schema<?> resolveFieldSchema(Type type, CustomSchemeAnnotation annotation, OpenAPI openApi) {
        Schema<?> schema;

        if (type instanceof ParameterizedType) {
            ParameterizedType pt = (ParameterizedType) type;
            Type raw = pt.getRawType();
            Type actual = pt.getActualTypeArguments()[0];

            if (raw == Map.class) {
                Type valueType = pt.getActualTypeArguments()[1];
                Schema<?> valueSchema = resolveFieldSchema(valueType, annotation, openApi);

                schema = new MapSchema().additionalProperties(valueSchema);
            } else if (raw == List.class || raw == Set.class) {
                schema = new ArraySchema().items(resolveFieldSchema(actual, annotation, openApi));
            } else {
                schema = resolveFieldSchema(actual, annotation, openApi);
            }
        } else if (type instanceof Class<?>) {
            Class<?> clazz = (Class<?>) type;
            schema = PrimitiveType.createProperty(clazz);
            if (schema == null) {
                buildSchemaFromCustomAnnotation(clazz, openApi);
                schema = new Schema<>().$ref("#/components/schemas/" + clazz.getSimpleName());
            }
        } else {
            schema = new StringSchema();
        }

        applyCustomAnnotationToSchema(schema, annotation);
        return schema;
    }

    private void applyCustomAnnotationToSchema(Schema<?> schema, CustomSchemeAnnotation ann) {
        if (!ann.description().isEmpty()) schema.setDescription(ann.description());
        if (!ann.example().isEmpty()) schema.setExample(ann.example());
        if (!ann.format().isEmpty()) schema.setFormat(ann.format());
    }

}

void customise(OpenAPI openApi)

-> OpenApiCustomizer 인터페이스에 정의된 문서로 이곳을 통해서 openapi를 커스텀을 진행한다. 우선 com.wedul 로 시작하는 패키지 기준으로 애노테이션이 붙은 클래스들을 스캔한다. Operation의 기준이 될 method 들을 먼저 스캐닝하고 찾은 메소드의 CustomMethodAnnotation의 필드를 꺼내서 Operation객체를 새로 생성한다. 그 다음 해당 메소드의 Parameter와 response를 꺼내서 schema를 등록한다. 과정은 아래 메소드로 나눠서 설명한다.

Schema<?> buildSchemaFromCustomAnnotation(Class<?> clazz, OpenAPI openApi)

-> class에 annotation이 달려있으면 상위 schema에 대해서 설명을 추가한다. 그 다음 필드를 순회하면서 CustomSchemeAnnotation이 달려있는 정보를 꺼내서 filed별 schema를 생성하고 클래스 schema에 properties로 추가한다.

다 생성 된 후 현재 class의 schema를 componets에 추가해준다. (스키마 재사용을 위해)

private Schema<?> resolveFieldSchema(Type type, CustomSchemeAnnotation annotation, OpenAPI openApi)

-> RequestBody, ApiResponse 클래스 내부에 정의된 filed들에 대해서 schema를 만드는 로직이다. 이 로직을 통해서 ParameterizedType의 경우 collection과 제네릭에 대한 처리를 진행 할 수 있다. 그리고 그 이외 Primitive type에 대한 처리와 추가 처리 되지 못한건 string schema 처리를 진행했다.

최종 화면

전체 코드는 이곳에서 볼 수 있다.

https://github.com/weduls/custom-openapi/tree/main

Virtual thread pinning issue와 java 24에서 해소 방법

wedul — Fri, 20 Dec 2024 14:07:31 +0900

virtual thread

java 21부터 virtual thread가 나온 것은 대부분의 알고 있는 사실이다. 간단하게 virtual thread는 기존 jvm에 사용하는 thread가 os kernal thread에 매핑되어 사용되던 걸 carrier thread (platform thread)에 virtual thread(향후 vt)를 사용하여 내부적 요청에 vt를 carrier thead에 mount, unmont하여 kernal os를 덜 사용하는 전략을 사용하는 thread를 말한다.

내부적으로 실행되는 로직을 확인해보자. openjdk에 있는 테스트용 VThreadRunner.java 코드를 이용해서 호출해보면서 내부적으로 VThread에서 사용되는 carrier thread 호출 scheduler는 fork join pool을 사용하는 걸 알 수 있다.

/*
 * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

package javas.main;

import java.lang.reflect.Field;
import java.time.Duration;
import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.atomic.AtomicReference;

/**
 * Helper class to support tests running tasks a in virtual thread.
 */
public class VThreadRunner {
    private VThreadRunner() { }

    /**
     * Characteristic value signifying that initial values for inheritable
     * thread locals are not inherited from the constructing thread.
     */
    public static final int NO_INHERIT_THREAD_LOCALS = 1 << 2;

    /**
     * Represents a task that does not return a result but may throw
     * an exception.
     */
    @FunctionalInterface
    public interface ThrowingRunnable {
        /**
         * Runs this operation.
         */
        void run() throws Exception;
    }

    /**
     * Run a task in a virtual thread and wait for it to terminate.
     * If the task completes with an exception then it is thrown by this method.
     * If the task throws an Error then it is wrapped in an RuntimeException.
     *
     * @param name thread name, can be null
     * @param characteristics thread characteristics
     * @param task the task to run
     * @throws Exception the exception thrown by the task
     */
    public static void run(String name,
                           int characteristics,
                           ThrowingRunnable task) throws Exception {
        AtomicReference<Exception> exc = new AtomicReference<>();
        Runnable target =  () -> {
            try {
                task.run();
            } catch (Error e) {
                exc.set(new RuntimeException(e));
            } catch (Exception e) {
                exc.set(e);
            }
        };

        Thread.Builder builder = Thread.ofVirtual();
        if (name != null)
            builder.name(name);
        if ((characteristics & NO_INHERIT_THREAD_LOCALS) != 0)
            builder.inheritInheritableThreadLocals(false);
        Thread thread = builder.start(target);

        // wait for thread to terminate
        while (thread.join(Duration.ofSeconds(10)) == false) {
            System.out.println("-- " + thread + " --");
            for (StackTraceElement e : thread.getStackTrace()) {
                System.out.println("  " + e);
            }
        }

        Exception e = exc.get();
        if (e != null) {
            throw e;
        }
    }

    /**
     * Run a task in a virtual thread and wait for it to terminate.
     * If the task completes with an exception then it is thrown by this method.
     * If the task throws an Error then it is wrapped in an RuntimeException.
     *
     * @param name thread name, can be null
     * @param task the task to run
     * @throws Exception the exception thrown by the task
     */
    public static void run(String name, ThrowingRunnable task) throws Exception {
        run(name, 0, task);
    }

    /**
     * Run a task in a virtual thread and wait for it to terminate.
     * If the task completes with an exception then it is thrown by this method.
     * If the task throws an Error then it is wrapped in an RuntimeException.
     *
     * @param characteristics thread characteristics
     * @param task the task to run
     * @throws Exception the exception thrown by the task
     */
    public static void run(int characteristics, ThrowingRunnable task) throws Exception {
        run(null, characteristics, task);
    }

    /**
     * Run a task in a virtual thread and wait for it to terminate.
     * If the task completes with an exception then it is thrown by this method.
     * If the task throws an Error then it is wrapped in an RuntimeException.
     *
     * @param task the task to run
     * @throws Exception the exception thrown by the task
     */
    public static void run(ThrowingRunnable task) throws Exception {
        run(null, 0, task);
    }

    /**
     * Returns the virtual thread scheduler.
     */
    private static ForkJoinPool defaultScheduler() {
        try {
            var clazz = Class.forName("java.lang.VirtualThread");
            var field = clazz.getDeclaredField("DEFAULT_SCHEDULER");
            field.setAccessible(true);
            return (ForkJoinPool) field.get(null);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    /**
     * Sets the virtual thread scheduler's target parallelism.
     * @return the previous parallelism level
     */
    public static int setParallelism(int size) {
        return defaultScheduler().setParallelism(size);
    }

    /**
     * Ensures that the virtual thread scheduler's target parallelism is at least
     * the given size. If the target parallelism is less than the given size then
     * it is changed to the given size.
     * @return the previous parallelism level
     */
    public static int ensureParallelism(int size) {
        ForkJoinPool pool = defaultScheduler();
        int parallelism = pool.getParallelism();
        if (size > parallelism) {
            pool.setParallelism(size);
        }
        return parallelism;
    }
}

그리고 contiton을 생성해서 task를 실행시키는데 이때 사용되는 VThreadContinuation을 생성한다. 이 Continuation은 실제 해당 vt가 실행될 때 호출되는 메소드이고 wrap이외에 onPinned가 구현되어 있는데 onPinned는 내부적으로 vt가 pinning되었을 때 실행되는 메소드이다.

이 Vt를 실행시키는 runContinuation을 선언하는데 이 runContinuation은 vt가 실행되는 yield상태에서 호출되고 바로 호출 하는 것이 아닌 위에 생성했던 scheduler에 스케줄 처리되면서 실행된다.

condition내부에는 vt를 mount하고 종료되면 unmount 하는 코드가 들어있는 걸 확인할 수 있다.

virtual thread의 효과적인 사용처

virtual thread를 사용할 때 cpu intensive한 환경이 아닌 io intensive한 환경에서 사용하라고 한다. 그이유는 virtual thread의 경우 i/o bound 작업에 효율성이 있어 높은 처리량을 주기위해서 설계되었기 때문에 cpu bound가 높은 환경에서는 오히려 오버헤드가 늘어날 수 있다. 또한 virtual thread는 가볍게 여러개 생성되면서 여러 작업을 수행할 수 있게 해주는데 cpu intensive한 환경에서는 어울리지 않으며 컨텍스트 스위칭 비용에 대한 효과를 보기 어렵다.

virtual thread의 문제

carrier thread에서는 vt를 할당받아서 내부적으로 수행하게 되는데 synchronized 되어 있는 코드를 수행하게 되면 pinning이 발생하는 문제가 생긴다. 그 이유는 synchronized안에는 동시성 제어를 위한 monitor를 들고 있으며 이 걸 사용해서 lock, unlock을 수행한다. 내부적으로 이 monitor에 대한 소유는 carrier thread가 보유하게 되기 때문에 blocking되는 상황에서는 carrior thread자체가 blocking 되는 이슈가 있다. 이는 synchronized가 jvm 레벨에서 구현되어 있기 때문이다.

이해 대한 해결법으로 ReentrantLock을 사용하면 해소가 가능하다고 한다. ReentrantLock는 synchronized와 다르게 FIFO 큐로 관리되어있어 lock에 대한 점유 순서를 보장하고 있기 때문에 VT에서는 효율적인 스케줄링이 가능하기 때문에 필요에 따라서 Carrier Thread에서 mount/unmount가 가능하다. 이는 java level에서 구현되어 있어서 가능한 부분이다.

출처 : https://www.reddit.com/r/java/comments/13ze03y/question_about_virtual_threads_and_their/?rdt=60476

https://stackoverflow.com/questions/78671922/why-reentrantlock-is-better-for-virtual-threads-than-synchronized

From the java community on Reddit

Explore this post and more from the java community

www.reddit.com

넷플릭스에서 찾은 관련된 이슈

https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d

한번 테스트 해보자.

package javas.main.wedul;

import lombok.Synchronized;

public class Wedul {

    @Synchronized
    public synchronized void start() throws InterruptedException {
        System.out.println("start");
        Thread.sleep(1000);
    }
}

synchronized가 붙어있는 Wedul클래스의 start라는 메소드가 있다고 가정하자

이때 두개의 virtual thread가 Wedul.start()를 실행시킨다고 가정해보면 synchronized가 pinning을 발생시키는지 확이할 수 있다.

이때 여러개의 carrier thread가 존재할 경우 vt로 인한 pinning이 아닌 여러개의 carrier thread가 실행될 수 있으니 vm option을 주어 개수를 제한한다. 그리고 trace mode가 켜져있어야 하기 때문에 해당 옵션도 켜준다.

-Djdk.virtualThreadScheduler.parallelism=1 
-Djdk.virtualThreadScheduler.maxPoolSize=1 
-Djdk.virtualThreadScheduler.minRunnable=1 
-Djdk.tracePinnedThreads=short

그럼 위에 사용했던 VThreadRunner를 사용해서 thread를 실행시켜보자.

package javas.main.wedul;

import javas.main.VThreadRunner;

public class JavaApplication {

    public static void main(String[] args) throws Exception {
        Wedul w = new Wedul();
        VThreadRunner.run(w::start);
        VThreadRunner.run(w::start);
    }


}

pinning 이 발생해서 VT 생성시에 추가되었던 VThreadContinuation에 onPinned가 실행된다.

java 24에서 virtual thread 해소

https://openjdk.org/jeps/491

JEP 491: Synchronize Virtual Threads without Pinning

JEP 491: Synchronize Virtual Threads without Pinning AuthorPatricio Chilano Mateo & Alan BatemanOwnerAlan BatemanTypeFeatureScopeImplementationStatusCompletedRelease24Componenthotspot / runtimeDiscussionhotspot dash dev at openjdk dot org, loom dash de

openjdk.org

openjdk에 올라온 내용을 보면 jdk24부터는 synchroize를 사용하더라도 pinning이 되지 않도록 수정했다고 하는데 그 주요 내용은 carrier thread가 synchorinzed를 만났을 때 monitor를 점유하는게 아닌 vt가 점유하게 하고 그 vt를 unmount시키도록 하는 방법이다.

똑같은 코드를 jdk24로 수행해보니 pinning 경고가 사라진걸 확인 할 수 있다.

결론

virtual thread를 사용한다면 특히 synchronized가 많은 mysql drive를 사용한다면 jdk 24이상부터 사용하자.

위 예시 코드

https://github.com/weduls/virtual-theadtest

lettuce pipeline코드 사용시 커넥션 풀 사용 필요

wedul — Sat, 8 Jun 2024 21:40:40 +0900

lettuce를 사용해서 레디스를 사용을 하고 있었는데 어느날 갑자기 아래처럼 레디스 커넥션을 못잡는 이슈가 발생했다.

org.springframework.data.redis.RedisSystemException: Redis exception; nested exception is io.lettuce.core.RedisException: Master is currently unknown: [RedisMasterReplicaNode [redisURI=redis://xxx.xxx.com?timeout=20s, role=REPLICA]]

처음에는 aws 레디스쪽 이슈일것으로 의심했으나 레디스쪽에는 별다른 지표가 없었고 애플리케이션에서 커넥션을 사용하지 못하는 것 같았다.

이번에 배포 하면서 들어간 코드는 비동기 코드로 파이프라인 코드를 사용하는 부분이 들어갔었다. 파이프라인을 사용한 부분은 set + expire를 줘야했고 한번에 100개 이상의 키를 넣었어야했는데 단건으로 요청할시 하나의 요청이 20ms걸린다고 가정했을 때 100개면 2초가 소요되었다.

이는 로직상 너무 늦어지는 부분이었고 이걸 줄이기 위해서 요청을 한번에 레디스에 보낼수 있도록 파이프라인을 사용했고 그결과 20~100ms사이로 요청을 확 줄일 수 있었다.

근데 이부분이 커넥션을 못찾게 되는 부분을 만들게 되었다.

이유가 모였을까? 기본적으로 lettuce는 하나의 싱글 커넥션을 가지고 처리를 하고 내부적으로는 네티 기반(event-driven i/o)으로 되어있어서 멀티 스레드 환경에서 사용하는데 문제가 없다.

그래서 파이프라인이 들어가기 전에 비동기 환경에서 사용했어도 별도의 커넥션 풀을 사용하지 않아도 큰 문제가 없었다. 하지만 pipeline이나 트랜잭션의 요청의 경우 블로킹 요청이기 때문에 네티 환경에서 사용하게 되면 문제가 발생된다.

이 사실을 알고 우리는 배치 애플리케이션이었고 굳이 레디스에 msetex하는 파이프라인 부분에 비동기로 할필요가 없어서 동기로 바꿨고 문제는 해결되었다.

근데 만약 계속 비동기 사용이 필요한경우에는 하나의 커넥션으로 하게되면 block되는 과정에서 다른 스레드에서 커넥션을 사용하지 못하는 문제가 발생하기 때문에 커넥션 풀을 꼭 사용해야한다.

커넥션 풀 사용하는 방법

https://github.com/redis/lettuce/wiki/Connection-Pooling

참고 :https://bytepitch.com/blog/article/redis-integration-spring-boot

Software Engineering Company Blog | BytePitch

BytePitch shares knowledge on software development topics to support the community and help software engineering projects succeed.

bytepitch.com

spring batch에서 파라미터 시 - 사용 주의

wedul — Tue, 7 May 2024 11:01:11 +0900

spring batch에서 job param을 전달할 때 관용적으로 -를 붙여서 사용했다.

문제가 된 시점은 프로젝트에서 중복으로 돌면 안되는 배치에 preventrestart를 붙히고 돌리고 있는데 주기적으로 already job param으로 동작한 배치가 있다면서 배치가 자꾸 죽는 이슈가 발생했다.

원인을 파악하기 위해 디버깅을 하던 중 spring batch에서 job의 unique를 판단하는 부분에서 job param으로 전달하고 있는 값들을 job instance에 유니크로 확인하는데 사용을 못하고 있는 부분을 발견했다.

그림을 보면 알겠지만 실제 parameter는 push라는 형태로 전달 되지만 identifying이 false로 되어있는걸 확인할 수 있다. 이러다보니 job instance가 이미 돈적이 있다는 오류가 계속 발생했었다.

그래서 이 identifying을 체크하는 로직을 따라가보니 param으로 설정할 때 -를 붙히면 identifying을 false로 지정하고 있는걸 확인했다.

관용적으로 쓰던 -가 실제 의미를 가지고 동작하는지는 처음 확인하게된 부분이었다.

param에서 -를 빼고 요청하니 정상적으로 identifying이 true로 동작하는걸 확인했다. 아마 기존에는 spring batch실행 시 prevent restart를 붙히지 않았거나 run.id를 붙여서 사용했어서 큰 이슈가 없었던 것 같다. 조심하자

gradle build시 파라미터 전달받아 사용하기

wedul — Tue, 7 May 2024 10:51:28 +0900

beta에는 restdocs를 만들어서 static/index.html에 위치시키고 싶었고 운영에 경우에는 이로직을 빼고 싶었다.

그러기 위해서는 build시점에 profile을 전달받아야했고 그것에 따라서 로직 분리가 필요했다.

그러기 위해서는 ./gradlew build 시 param으로 값을 전달하고 그 전달한 값을 사용하여 빌드 로직을 분리해야했다.

우선 build를 할 build.gradle에 argument를 받는코드와 분기로직을 작성했다.

bootJar {
    enabled = true
    String activeProfile = project.findProperty('profiles') ?: ''
    println "zone: $activeProfile"
    if (activeProfile == 'beta') {
		// beta 로직 
    } else if (activeProfile == 'prod') {
    	// 운영 로직
    }
}

그리고 ./gradlew에 param을 추가한다.

 -Pprofiles=beta

잘 된다.

elasticsearch routing 사용하기

wedul — Tue, 25 Jul 2023 23:33:20 +0900

[기본구조]

elasticserch에서 데이터는 index에 저장되고 index는 shard로 구성되어 있다. 기본적으로 데이터가 shard에 들어가는 기준은 document에 _id를 기준으로 들어가게 된다. 그렇기 때문에 index에 데이터를 조회할 때 어떤 샤드에 값이 저장되어 있는지 알수 없기 때문에 모든 shard에 값을 질의하고 그 값을 조합해서 값을 내려준다.

한번 일반적인 index를 만들고 조회해보자. 아래처럼 Index를 생성하고 "name"에 wedul을 넣고 조회해보겠다.

PUT localhost:19200/before-route
{
  "settings": {
    "number_of_shards": 4,
    "number_of_replicas": 0
  },
  "mappings": {
    "properties": {
      "name": { "type": "text" }
    }
  }
}

그럼 아래에 보는것처럼 4개의 shard 모두 조회에 사용된 것을 확인할 수 있다.

[routing]

그럼 routing을 추가해서 값을 조회해보자. 우선 routing을 index에 무조건 넣어서 데이터를 indexing하도록 만들어보자. 기존 before-route index를 놔두고 새로운 after-route index를 생성해보자. mappings에 _routing필드를 추가하고 required 속성을 true로 지정하면 무조건 indexing할때 routing 정보가 있어야 라우팅 된다.

PUT localhost:19200/after-route
{
    "settings": {
        "number_of_shards": 4,
        "number_of_replicas": 0
    },
    "mappings": {
        "_routing": {
            "required": true
        },
        "properties": {
            "name": {
                "type": "text"
            }
        }
    }
}

이를 강제해서 무조건 필요한 데이터 조회 시 특정한 샤드를 조회할 수 있도록 해야한다. 물론 아무때나 routing field를 추가할 수 있는건 아니다. 전체 문서 기준으로 조회가 매번 필요하고 별도 샤드를 나눌 기준이 없는경우에는 routing을 기준으로 삼을만한게 없다. 이럴때는 routing을 넣을 때 신중하게 기준을 삼는게 좋고 그게 어렵다면 routing filed를 사용하지 않는것도 방법이다. routing field에 적합한 예로는 특정 가게에 있는 상품들을 조회한다고 가정하였을 때, 단순 쿼리로 shopNo를 필터한다면 모든 샤드를 다조회해야하고 그 양이 일반적인 커머스라면 수억건이 될거라서 부담을 많이 줄 수 있기에 가게번호 기준으로 routing을 해놓으면 특정 샤드만 조회하기에 이점을 가져갈 수 있다.

단 주의해야할 점이 routing은 특정 shard를 매칭하기 위함이기에 shopNo에 대한 필터 쿼리는 유지해야한다. routing에 가게번호를 넣어서 조회한다고해서 해당가게 데이터만 나오는게 아니다. 단순히 routing은 shard에 대한 routing이기에 해당 shard에 있는 다른 데이터들도 함께 조회되기 때문에 filter 쿼리를 빼먹으면 안된다.

그럼 값을 넣어보자.

routing을 사용해서 값을 넣을 때는 request param으로 routing 필드를 넣어줘야한다. 그럼 이렇게 들어간 데이터의 routing 필드 데이터를 _search api로 확인해보면 아까 넣은값이 들어있는걸 확인할 수 있다.

_search 조회 시 _routing field값 보임

단, _routing field를 강제한 상황에서 doc을 조회할 시 기존처럼 id로 조회할 때 무조건 routing을 함께 적어야한다. 그렇지 않으면 routing_missing_exception이 발생한다.

_routing정보를 빼고 조회한경우

GET localhost:19200/after-route/_doc/1?routing=1000

이렇게 routing을 넣어줘야 값이 제대로 나온다.

그럼 다음으로 실제로 routing을 넣어서 조회하면 하나의 shard에서만 조회가 발생하는지 확인해보면 아래 같은 쿼리에서 routing만 붙여서 조회해도 shard가 1개에서 조회가 이뤄진거를 확인할 수 있다.

이처럼 routing을 사용하면 성능상 이점을 가져올 수 있고 리소스 사용량도 확 줄일 수 있다. 하지만 잘못된 routing을 넣으면 값이 없기 때문에 내가 넣은 데이터의 routing정보를 잘 확인하고 조회에 사용해야 서비스 버그를 예방할 수 있다. 실제 60000 routing field에 저장된 값을 1로 임의로 바꿔서 조회하면 아래처럼 값이 나오지 않는걸 알 수 있다.

추가적으로 routing을 사용했다고 해서 전체 document를 대상으로 조회가 되지 않는건 아니다. 만약 routing을 제외하고 전체 document를 대상으로 조회하고 싶은경우에는 _search api에서 routing parameter만 빼고 조회하면 된다. (단, 위에서 봤듯이 특정 document에 경우에는 조회하고자 할경우에 무조건 routing정보를 기입해줘야한다.)

shard reroute api 테스트

wedul — Tue, 25 Jul 2023 21:44:41 +0900

elasticsearch에서는 들어온 요청에 대해서 primary shard, replica shard를 병렬로 요청을하기 때문에 replica가 있는게 좋긴하다. 하지만 replica shard나 primary shard가 제대로 노드에 분배되어 있지 않으면 조회가 특정노드에 몰리거나 인덱싱 시 노드에 부하가 심해질 수 있다.

분배를 위해서는 기본적으로 es cluster에 아래 옵션들이 제공된다. (링크)

cluster.routing.allocation.balance.shard

- 노드에 샤드를 균등하게 분배 (기본값 0.45f, 값이 높아질수록 노드들에 샤드들이 골고루 분배됨)

cluster.routing.allocation.balance.index

- 인덱스당 샤드 분배를 균등하게 (기본값은 0.55f, 값이 높아질후록 클러스터 모든 노드에 shard가 골구루 분배됨)

cluster.routing.allocation.balance.threshold

- 클러스터에서 노드 간 데이터 분배를 조정하는데 사용한다. (기본값은 1.0f, 이값이 높아지면 높아질 수록 클러스터는 밸런스가 깨진 상태가 됨)

하지만 위 설정을 한다고 해도 일부 샤드만 재조정을 하고자하는 경우가 있을것이다. 관련해서 우리는 reroute api를 사용할것이고 몇가지 사례를 가정해서 테스트 해보자.

primary shard를 노드를 이동하고 싶을 때

primary shard가 3개있고 노드가 3개인 상황에서 shard0을 elasticsearch3 node로 move시켜보자.

POST _cluster/reroute
{
    "commands": [
        {
            "move": {
                "index": "wedul",
                "shard": 0,
                "from_node": "elasticsearch1",
                "to_node": "elasticsearch3"
            }
        }
    ]
}

shard 0이 elasticsearch 3로 이동되고 1이 elasticsearch0으로 swap 된거를 확인할 수 있다.

그럼 primary shard가 수가 노드마다 다를때는?

0을 elasticsearch2노드로 옮겨보자.

POST _cluster/reroute
{
    "commands": [
        {
            "move": {
                "index": "wedul2",
                "shard": 0,
                "from_node": "elasticsearch1",
                "to_node": "elasticsearch2"
            }
        }
    ]
}

샤드가 한쪽이 더 많을 때는 스왑되지 않고 그대로 옮겨진다.

그럼 샤드가 할당되지 않은 노드에 할당한다면?

POST localhost:19200/_cluster/reroute
{
    "commands": [
        {
            "move": {
                "index": ".ds-.logs-deprecation.elasticsearch-default-2023.07.25-000001",
                "shard": 0,
                "from_node": "elasticsearch7",
                "to_node": "elasticsearch4"
            }
        }
    ]
}

잘 옮겨진다.

replica가 있는 상태에서 primary shard를 노드를 이동하고 싶을 때

replica shard가 1개로 primary shard를 이동시켜보자. elasitcsearch3에 있는 1번 shard를 elasticsearch2 샤드로 옮겨보자.

POST _cluster/reroute
{
    "commands": [
        {
            "move": {
                "index": "wedul2",
                "shard": 1,
                "from_node": "elasticsearch3",
                "to_node": "elasticsearch2"
            }
        }
    ]
}

1번 샤드가 옮겨지면서 elasticsearch2에 있던 3 replica shard가 옮겨지는 rebalance가 진행되었다.

그럼 이번에는 primary shard가 없는 노드로 primary shard를 보내보자.

elasticseearch2에 있는 primary shard2를 elasticsearch3로 이동시키면 아래와 같이 조정이되었다. 그럼 아래상태에서 다시 shard 1을 elasticsearch2로 옮겨보는 command를 날려보자.

POST /_cluster/reroute
{
    "commands": [
        {
            "move": {
                "index": "wedul2",
                "shard": 1,
                "from_node": "elasticsearch3",
                "to_node": "elasticsearch2"
            }
        }
    ]
}

아까와는 다르게 실패하게 되는데 원인을 로그에서 확인해보자.

{
    "error": {
        "root_cause": [
            {
                "type": "illegal_argument_exception",
                "reason": "[move_allocation] can't move 1, from {elasticsearch3}{T-R4unaNTrS3cG0TBLZI1w}{VnPxLF9MSSyY2i5v28y34w}{172.21.0.4}{172.21.0.4:9300}{cdfhilmrstw}{ml.machine_memory=8232894464, xpack.installed=true, transform.node=true, ml.max_open_jobs=512, ml.max_jvm_size=536870912}, to {elasticsearch2}{fZmPapXcTmOXUZW5qgY37g}{5BmI1q8hS8SBr6Pn7itftw}{172.21.0.3}{172.21.0.3:9300}{cdfhilmrstw}{ml.machine_memory=8232894464, ml.max_open_jobs=512, xpack.installed=true, ml.max_jvm_size=536870912, transform.node=true}, since its not allowed, reason: [YES(shard has no previous failures)][YES(shard is primary and can be allocated)][YES(explicitly ignoring any disabling of allocation due to manual allocation commands via the reroute API)][YES(can relocate primary shard from a node with version [7.17.5] to a node with equal-or-newer version [7.17.5])][YES(no snapshots are currently running)][YES(ignored as shard is not being recovered from a snapshot)][YES(this node is not currently shutting down)][YES(neither the source nor target node are part of an ongoing node replacement (no replacements))][YES(node passes include/exclude/require filters)][NO(a copy of this shard is already allocated to this node [[wedul2][1], node[fZmPapXcTmOXUZW5qgY37g], [R], s[STARTED], a[id=YXQNS0DQTbqQ0yAh6AtE7Q]])][YES(enough disk for shard on node, free: [49.3gb], shard size: [3.3kb], free after allocating shard: [49.3gb])][YES(below shard recovery limit of outgoing: [0 < 2] incoming: [0 < 2])][YES(total shard limits are disabled: [index: -1, cluster: -1] <= 0)][YES(allocation awareness is not enabled, set cluster setting [cluster.routing.allocation.awareness.attributes] to enable it)][YES(index has a preference for tiers [data_content] and node has tier [data_content])][YES(shard is not a follower and is not under the purview of this decider)][YES(decider only applicable for indices backed by searchable snapshots)][YES(this decider only applies to indices backed by searchable snapshots)][YES(decider only applicable for indices backed by searchable snapshots)][YES(this node's data roles are not exactly [data_frozen] so it is not a dedicated frozen node)]"
            }
        ],
        "type": "illegal_argument_exception",
        "reason": "[move_allocation] can't move 1, from {elasticsearch3}{T-R4unaNTrS3cG0TBLZI1w}{VnPxLF9MSSyY2i5v28y34w}{172.21.0.4}{172.21.0.4:9300}{cdfhilmrstw}{ml.machine_memory=8232894464, xpack.installed=true, transform.node=true, ml.max_open_jobs=512, ml.max_jvm_size=536870912}, to {elasticsearch2}{fZmPapXcTmOXUZW5qgY37g}{5BmI1q8hS8SBr6Pn7itftw}{172.21.0.3}{172.21.0.3:9300}{cdfhilmrstw}{ml.machine_memory=8232894464, ml.max_open_jobs=512, xpack.installed=true, ml.max_jvm_size=536870912, transform.node=true}, since its not allowed, reason: [YES(shard has no previous failures)][YES(shard is primary and can be allocated)][YES(explicitly ignoring any disabling of allocation due to manual allocation commands via the reroute API)][YES(can relocate primary shard from a node with version [7.17.5] to a node with equal-or-newer version [7.17.5])][YES(no snapshots are currently running)][YES(ignored as shard is not being recovered from a snapshot)][YES(this node is not currently shutting down)][YES(neither the source nor target node are part of an ongoing node replacement (no replacements))][YES(node passes include/exclude/require filters)][NO(a copy of this shard is already allocated to this node [[wedul2][1], node[fZmPapXcTmOXUZW5qgY37g], [R], s[STARTED], a[id=YXQNS0DQTbqQ0yAh6AtE7Q]])][YES(enough disk for shard on node, free: [49.3gb], shard size: [3.3kb], free after allocating shard: [49.3gb])][YES(below shard recovery limit of outgoing: [0 < 2] incoming: [0 < 2])][YES(total shard limits are disabled: [index: -1, cluster: -1] <= 0)][YES(allocation awareness is not enabled, set cluster setting [cluster.routing.allocation.awareness.attributes] to enable it)][YES(index has a preference for tiers [data_content] and node has tier [data_content])][YES(shard is not a follower and is not under the purview of this decider)][YES(decider only applicable for indices backed by searchable snapshots)][YES(this decider only applies to indices backed by searchable snapshots)][YES(decider only applicable for indices backed by searchable snapshots)][YES(this node's data roles are not exactly [data_frozen] so it is not a dedicated frozen node)]"
    },
    "status": 400
}

a copy of this shard is already allocated to this node (주요원인)

- 옮기려고하는 node에 이미 replica shard가 존재하고 있어서 발생하는 에러로 위에 그림에서 보면 shard1에 replica shard가 이미 존재하는것을 확인할 수 있다.

total shard limits are disabled

- total shard가 제한이 있을 경우 문제인데 disabled되어있어서 이유가 아니다.

enough disk for shard on node

- 대상 노드에 shard를 할당하기에 충분한 디스크 공간이 있는 것으로 보여서 이유가 아니다.

shard is not a follower and is not under the purview of this decider

allocation awareness is not enabled

this node's data roles are not exactly [data_frozen] so it is not a dedicated frozen node

- 여러 힌트들을 확인해 볼 수 있다.

그럼 위에서 주요이슈가 되었던 동일한 shard가 없는 elasticsearch1 노드로 옮겨보자.

POST /_cluster/reroute
{
    "commands": [
        {
            "move": {
                "index": "wedul2",
                "shard": 1,
                "from_node": "elasticsearch3",
                "to_node": "elasticsearch1"
            }
        }
    ]
}

잘 옮겨진다.

모든 노드의 replica shard가 있는 상태에서 primary shard를 노드를 이동하고 싶을 때

노드가 자주 교체되고 몇개의 노드가 shutdown되면서 데이터가 유실될 수 있는 환경에서는 모든 노드에 replica를 넣기도한다. 보통이럴때는 auto_expand_replicas: "0-all"로 설정하여 진행한다.

모든 primary shard가 elasticsearch4노드에 모여있으서 이것을 elasitcsearch5, elasitcsearch6 node에 옮겨보겠다.

이때는 모든 샤드가 노드에 다있어서 위에서 발생했던 동일 replica shard, primary shard가 이동하려는 곳에 같이있어서 발생했던 이슈가 무조건 발생한다. (a copy of this shard is already allocated to this node)

그래서 cancel을 사용해서 primary shard 할당을 cancel해주면 replica shard에 primary shard가 할당되면서 primary shard를 분산할 수 있다.

POST localhost:19200/_cluster/reroute
{
    "commands": [
        {
            "cancel": {
                "index": "wedul",
                "shard": 3,
                "node": "elasticsearch6",
                "allow_primary": "true"
            }
        }
    ]
}

근데 이렇게 하면 특정 노드에 할당할수 없고 마지막에 올라온 노드로 자동으로 primary shard가 할당된다.

내가 찾은 방법은 우선 auto_expand_replica 옵션을 false로 끄고 number_of_replicas의 값을 0으로 바꾸면 replica shard는 모두 사라지고 primary shard는 각 노드에 분산되어 저장된다.

한쪽에 몰려있는 primary shard

PUT localhost:19200/wedul/_settings
{
  "settings": {
    "number_of_replicas": 0,
    "auto_expand_replicas": false
  }
}

replica가 사라지면서 분산된 primary shard

primary shard가 분산된걸 확인할 수 있다. 그다음 다시 auto_expand_replicas옵션을 "0-all"로 켜주면 이상태에서 replica shard만 붙는다.

replica shard는 조회 성능에 많은 영향을 끼치고 이과정에서 만약 노드하나가 죽어서 primary shard가 날아간다면... 조심해야한다. 오히려 reindex를 해주는게 나을수도 있지만 운영중인환경에서 쉽지 않은 선택이다.

관련해서 elasticsearch github에도 issue ticket이 올라와 있으나 아직 뾰족하게 어떻게 하는게 좋을지 감이 오지는 않는다. index를 하나 더만들고 alias를 같이 붙이고 reindex를 하면서 is_write_true를 새로운 index에 붙여야하나.. 질문을 올려보긴 했는데 기다려보자.

주의사항

Shard rerouting은 Elasticsearch 클러스터의 샤드를 다시 할당하는 작업을 의미합니다. 이 작업은 특정 상황에서 유용할 수 있지만, 잘못 사용하거나 신중하지 않게 진행할 경우 몇 가지 위험성이 있다. 아래는 Shard reroute 작업의 위험성에 대한 몇 가지 주요 요인들이다.

1. 데이터 손실

Shard rerouting은 샤드를 다른 노드로 이동시키는 작업이므로 실수로 잘못된 노드로 샤드를 이동시키면 해당 샤드에 저장된 데이터를 손실할 수 있다. 신중하게 계획되지 않은 샤드 이동은 데이터 유실을 초래할 수 있으므로 조심해야 한다.

2. 클러스터 불안정성

Shard reroute 작업은 클러스터의 상태를 변경하는 작업이기 때문에 클러스터 불안정성을 유발할 수 있다. 잘못된 샤드 이동이나 충돌하거나 네트워크 문제가 발생하면 클러스터의 안정성과 가용성이 저하될 수 있다.

- 다행히 primary shard 이동 시 기존 primary shard는 유지한채 새로운 shard를 복사하면서 switch하기 때문에 이것만으로는 cluster가 red가 되지 않는다. 단, 진행하는 도중에 여러이유로 발생할수 있으니 신중히 테스트가 필요하다.

3. 네트워크 부하

Shard reroute 작업은 노드 간에 샤드 데이터를 이동시키므로 클러스터의 네트워크 부하가 증가할 수 있다. 대규모 클러스터에서 많은 샤드를 이동시키는 경우 네트워크 병목 현상이 발생할 수 있으므로 성능을 감안하여 계획해야 한다.

4. 클러스터 성능 저하

Shard reroute 작업은 클러스터의 상태를 변경하므로 이 작업이 실행되는 동안에는 클러스터 성능이 저하될 수 있다. 특히, 대규모 클러스터에서 수천 개의 샤드를 이동시키는 경우 클러스터의 응답 속도가 느려질 수 있다.

5. 충돌 위험

병렬로 실행되는 shard reroute 작업이 충돌하거나 동시에 여러 작업이 발생할 경우 예상치 못한 결과가 발생할 수 있다. 이러한 충돌은 클러스터의 안정성을 악화시킬 수 있으므로 주의가 필요하다.

위험성을 최소화하려면 Shard reroute 작업을 신중하게 계획하고 테스트를 거쳐야 한다. 큰 변화를 가하는 작업이므로 라이브 환경에서 수행하기 전에 백업을 만들고 롤백 계획을 갖추는 것이 좋다. 또한 Elasticsearch 클러스터의 상태와 성능을 모니터링하고 작업 진행 중에 잠재적인 문제를 신속하게 식별하고 대응해야 한다.

#부록

사용한 클러스터 docker-compose.yml 정보

version: "2"

services:
  elasticsearch1:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch1
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch1
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - indices.lifecycle.history_index_enabled=false
     - xpack.monitoring.collection.enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
     - node.roles=master
    ports:
      - "19200:9200"

  elasticsearch2:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch2
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch2
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - xpack.monitoring.collection.enabled=false
     - indices.lifecycle.history_index_enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
     - node.roles=master
    ports:
      - "29200:9200"

  elasticsearch3:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch3
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch3
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - xpack.monitoring.collection.enabled=false
     - indices.lifecycle.history_index_enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
     - node.roles=master
    ports:
      - "39200:9200"

  elasticsearch4:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch4
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch4
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - xpack.monitoring.collection.enabled=false
     - indices.lifecycle.history_index_enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3,elasticsearch4
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
     - node.roles=data
    ports:
      - "49200:9200"

elasticsearch cluster 구성 시 기본으로 생성되는 index확인

wedul — Tue, 25 Jul 2023 13:40:14 +0900

elasticsearch cluster를 사용하기 위해서 cluster를 구성하기전에 꼭 추가해야하는 부분이 있는데 기본으로 생성되는 index에 대한 disable처리가 필요하다.

geoip_databases 인덱스

기본적으로 cluster 구성 시 geoip_databases가 인덱스가 추가가 되어있는데 이게 hidden index여서 모르고 지나칠 수 있다. 만약 모르고 클러스터를 구성하고 노드를 조작할 경우 해당 인덱스의 primary shard가 unassigned되면서 cluster 상태가 red가 될 수 있다.

그럼 왜 geoip_databases가 기본적으로 생기는가? 생기지 않도록 할 수 없는가?

해당 인덱스가 생성되는 이유는 ingest.geoip.downloader.enabled 속성 때문에 생성되는데 해당 속성의 기본값이 true이다. 그리고 이게 true인 상태에서 cluster red 상태로 만든 index를 지울 수 없게 되어있어서 서비스 운영시 장애를 유발할 가능성이 있다.

해결방법은 간단하다. 이미 클러스트를 구성하고 있다면 아래 api를 호출하여 ingest.geoip.downloader.enabled를 비활성화 해주면 된다.

PUT _cluster/settings
{
    "persistent": {
       "ingest.geoip.downloader.enabled": false
    }
}

그럼 red상태에 빠졌던 클러스터는 index가 제거되면서 다시 green으로 돌아온다.

만약 클러스터를 구성하기 전이었다면 elasticsearch.yml에 해당 설정을 추가해주고 cluster를 올리는게 좋다.

ingest.geoip.downloader.enabled: false

.ds-ilm-history-*

ilm은 index lifecycle management에 약자로 elasticsearch에서 인덱스에 라이프사이클에 따라서 인덱스의 생명주기를 관리하는 것인데 이 policy에 따라서 진행된 내용을 history index에 생성한다.

하지만 이걸 사용하지 않는다고 하면 해당인덱스를 보유하고 있을 필요가 없다. 레플리카가 한개있기 때문에 만약 두개의 데이터 노드가 이탈된다면 이또한 cluster상태를 red로 만들 수 있다.

cluster 구성 시 indices.lifecycle.history_index_enabled=false를 설정해서 history가 저장되지 않게 한다.

[참고]

클러스터 생성 docker-compose.yml

version: "2"

services:
  elasticsearch1:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch1
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch1
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - indices.lifecycle.history_index_enabled=false
     - xpack.monitoring.collection.enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
    ports:
      - "19200:9200"

  elasticsearch2:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch2
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch2
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - xpack.monitoring.collection.enabled=false
     - indices.lifecycle.history_index_enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
    ports:
      - "29200:9200"

  elasticsearch3:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.5
    container_name: elasticsearch3
    environment:
     - cluster.name=docker-cluster
     - node.name=elasticsearch3
     - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
     - xpack.monitoring.collection.enabled=false
     - indices.lifecycle.history_index_enabled=false
     - discovery.seed_hosts=elasticsearch1,elasticsearch2,elasticsearch3
     - cluster.initial_master_nodes=elasticsearch1,elasticsearch2,elasticsearch3
     - xpack.security.enabled=false
    ports:
      - "39200:9200"

결론

위 index들이외에도 언제든지 생성될 수 있다. 어떤 index가 설정에 따라서 기본으로 special 속성으로 생성될지 모르기 때문에 항상 클러스터 운영시 설정을 지켜보고 Index를 주기적으로 체크하는게 좋다.