지도 기반의 프로젝트를 진행하면서 지구상 좌표의 위도(latitude), 경도(longitude)를 필요로 하는 API가 여러개가 되다보니 Validation을 공통으로 관리하면서 좌표 범위에 대한 Validation을 나타내고 싶어서 Custom Validator를 만들었다.

좌표계는 여러 종류가 있는데 모바일 환경에서는 일반적으로 WGS 84 좌표계를 사용한다.(GPS 좌표계) 현재 진행중인 지도 기반의 프로젝트가 WGS 84 좌표계를 사용하고 좌표의 범위를 한국으로만 제한하고 있어서 한국 좌표 범위에 대한 validation을 추가하였다.

 

WGS 84 좌표계에서 한국의 범위는 위도 약 33 ~ 39도, 경도 약 124 ~ 132도에 포함이 된다.

 

Custom Validator를 사용하기 위해서는 애노테이션과 실제 검증 로직이 담긴 ConstraintValidator 인터페이스를 구현한 클래스가 필요하다. 먼저 KoreaCoordinate 애노테이션을 만들고 @Constraint에 ConstraintValidator 구현체를 추가한다.

 

@Constraint(validatedBy = CoordinateValidator.class)

@Target({ElementType.FIELD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

public @interface KoreaCoordinate {

String message() default "잘못된 좌표입니다.";

Class<?\>\[\] groups() default {};

Class<? extends Payload\>\[\] payload() default {};

}

 

ConstraintValidator 인터페이스를 구현하는 것은 isValid() 메서드를 구현하면 되는데 초기화 작업이 필요하면 default 메서드인 initialize()도 구현하면 된다. 단순 검증 여부가 아닌 상세한 에러 메시지를 반환해주기 위해 값이 유효하지 않은 경우 addConstraintViolationMessage()를 통해 ConstaintViolation을 추가해준다.

 

public class CoordinateValidator implements ConstraintValidator<KoreaCoordinate, CoordinateDto> {
    public static final String COORD_NOT_EMPTY = "좌표에 빈 값이 들어갈 수 없습니다.";
    public static final String COORD_INVALID_RANGE = "좌표의 범위가 유효하지 않습니다.";
    private static final double MIN_LATITUDE = 33.0;
    private static final double MAX_LATITUDE = 39.0;
    private static final double MIN_LONGITUDE = 124.0;
    private static final double MAX_LONGITUDE = 132.0;

    @Override
    public boolean isValid(CoordinateDto value, ConstraintValidatorContext context) {
        boolean isValid = true;
        final Double lon = value.lon();
        final Double lat = value.lat();
        if (lon == null) {
            addConstraintViolationMessage(context, "lon", COORD_NOT_EMPTY);
            isValid = false;
        } else if (lon < MIN_LONGITUDE || lon > MAX_LONGITUDE) {
            addConstraintViolationMessage(context, "lon", COORD_INVALID_RANGE);
            isValid = false;
        }
        if (lat == null) {
            addConstraintViolationMessage(context, "lat", COORD_NOT_EMPTY);
            isValid = false;
        } else if (lat < MIN_LATITUDE || lat > MAX_LATITUDE) {
            addConstraintViolationMessage(context, "lat", COORD_INVALID_RANGE);
            isValid = false;
        }

        return isValid;
    }

    private void addConstraintViolationMessage(ConstraintValidatorContext context, String field, String message) {
        context.disableDefaultConstraintViolation();
        context.buildConstraintViolationWithTemplate(message)
            .addPropertyNode(field)
            .addConstraintViolation();
    }
}

 

이제 GET 요청을 보면 전달 받은 위도(lat), 경도(lon)를 CoordinateDto로 받고 있고 validation 처리가 되는 것은 ModelAttribute의 ArgumentResolver인 ModelAttributeMethodProcessor를 보면 된다.

 

@GetMapping("/spots")
public ResponseEntity<ApiResponse<NearbySpotListResponse>> getNearbySpotList(
    @ModelAttribute @Valid CoordinateDto coord,
    @RequestParam(name = "radius") @PositiveOrZero(message = "반경(m)은 0보다 커야 됩니다.") Integer radius
) {
    var response = spotService.getNearbySpotList(new NearbySpotRequest(coord.toCoord(), radius));
    return ResponseEntity.ok(ApiResponse.success(response));
}

 

참고로 ModelAttributeMethodProcessor의 supportsParameter()를 보면 ModelAttribute 애노테이션이 없어도 simple property 타입이 아니면 지원을 하기 때문에 생략이 가능하지만 확실하게 명시해주는 것이 좋다.

 

@Override
public boolean supportsParameter(MethodParameter parameter) {
    return (parameter.hasParameterAnnotation(ModelAttribute.class) ||
            (this.annotationNotRequired && !BeanUtils.isSimpleProperty(parameter.getParameterType())));
}

 

ModelAttributeMethodProcessor의 resolveArgument() 내부에서 validateIfApplicable()를 통해 Valid 애노테이션을 체크하고 validate()를 해서 bindingResult()의 error가 있을 경우 MethodArgumentNotValidException을 throw한다.

 

 

 

MethodArgumentNotValidException의 bindingResult를 보면 errors에 에러가 담긴 것을 볼 수 있다.

 

 

Cusom Validator를 테스트하기위해 validator를 초기화하고 검증을 했다.

class CoordinateValidatorTest {
	private Validator validator;

	@BeforeEach
	public void setUp() {
		validator = Validation.buildDefaultValidatorFactory().getValidator();
	}

	@DisplayName("유효한 좌표 범위가 들어오면 Validator를 통과한다.")
	@Test
	void coordinateValidSuccessTest() {
		//given
		CoordinateDto coordinateDto = new CoordinateDto(127.0, 37.0);
		//when
		Set<ConstraintViolation<CoordinateDto>> violations = validator.validate(coordinateDto);

		//then
		assertThat(violations).isEmpty();
	}

	@DisplayName("빈 값 또는 유효하지 않은 좌표가 들어오면 ConstraintViolation가 추가된다.")
	@MethodSource(value = "getCoordinateTestDatas")
	@ParameterizedTest(name = "{0}, validErrors {1}")
	void coordinateValidFailTest(CoordinateDto coordinateDto, Tuple... validErrors) {
		String fieldPath = "propertyPath.currentLeafNode.name";
		String errorMessagePath = "messageTemplate";
		// When
		Set<ConstraintViolation<CoordinateDto>> violations = validator.validate(coordinateDto);

		// Then
		assertThat(violations)
			.extracting(fieldPath, errorMessagePath)
			.contains(validErrors);

	}

	private static Stream<Arguments> getCoordinateTestDatas() {
		return Stream.of(
			Arguments.of(new CoordinateDto(null, 3711.0), new Tuple[] {
				new Tuple("lon", CoordinateValidator.COORD_NOT_EMPTY),
				new Tuple("lat", CoordinateValidator.COORD_INVALID_RANGE)
			}),
			Arguments.of(new CoordinateDto(null, null), new Tuple[] {
				new Tuple("lon", CoordinateValidator.COORD_NOT_EMPTY),
				new Tuple("lat", CoordinateValidator.COORD_NOT_EMPTY)
			}),
			Arguments.of(new CoordinateDto(127.0, 3711.0), new Tuple[] {
				new Tuple("lat", CoordinateValidator.COORD_INVALID_RANGE)
			}),
			Arguments.of(new CoordinateDto(-127.0, -37.0), new Tuple[] {
				new Tuple("lon", CoordinateValidator.COORD_INVALID_RANGE),
				new Tuple("lat", CoordinateValidator.COORD_INVALID_RANGE)
			})
		);
	}
}

 

 

스프링부트에서는 Validator를 사용하기 위해 ValidationAutoConfiguration에서 LocalValidatorFactoryBean을 자동으로 설정하기 때문에 테스트 환경에서 Validation.buildDefaultValidatorFactory().getValidator() 방식으로 초기화를 하기보다는 스프링부트 테스트 환경에서 Autowired로 주입을 받아서 테스트하는 것이 좋을 것 같다.

 

[참고]

 

 

ConstraintValidator을 이용해서 효과적인 검증 - Yun Blog | 기술 블로그

ConstraintValidator을 이용해서 효과적인 검증 - Yun Blog | 기술 블로그

cheese10yun.github.io

 

 

Spring Boot Bean Validation 제대로 알고 쓰자

지난번에 작성한 Java Bean Validation 제대로 알고 쓰자에 이어서 Spring Boot 환경에서 Validation을 어떻게 사용할 수 있는지 확인해보겠습니다. Spring에서도 Hibernate Validator를 사용합니다. Java Bean Validation

kapentaz.github.io

 

 

Spring에서 Custom validation 테스트하기 - Increment

스프링의 Bean validation을 활용하는 custom annotation을 테스트하는 과정에서 겪은 문제를 남겨둡니다. 개요 본문의 코드는 GitHub에서 확인하실 수 있습니다. 스프링에서는 기본으로 제공되는 validation

www.latera.kr

 

게시판 만들기를 하면서 기계처럼 붙이고 보는 @Transactional을 왜 사용하는지 머릿속에 정리가 안 돼서 다시 강의를 보면서 정리를 해봤다.

 

데이터베이스를 사용하는 중요한 이유는 하나는 트랜잭션이라는 개념을 지원하기 때문인데 트랜잭션이란 하나의 논리적인 작업 단위로 계좌이체로 예를 들면 돈을 보내고 받는 과정이 하나의 작업이 되는 것이다. 작업이 성공적으로 끝나면 커밋(commit), 중간에 실패하면 되돌리는 롤백을 한다.

 

트랜잭션은 ACID를 보장해야 하는데 이 중에서 격리성(Isolation)은 동시성의 정도를 나타내는데 동시성을 보장하는 것은 성능과의 trade-off가 있어서 격리 수준이 나뉘게 된다.

 

 

 

[DB 접근 기술1] 트랜젝션(Transaction) 기초

트랜젝션 데이터를 저장할 때 단순 파일이 아닌 데이터베이스에 저장하는 가장 큰 이유는 데이터베이스가 트랜젝션이라는 개념을 지원하기 때문이다. 트랜젝션은 데이터베이스에서 하나의 거

treecode.tistory.com

 

[Real MySQL] MySQL의 격리 수준

트랜잭션의 격리 수준이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다. 격리 수준 READ U

treecode.tistory.com

 

트랜잭션을 사용하기 위해서는 auto commit을 false로 설정하면 되는데 일반적으로는 디폴트 값이 true로 되어 있다. 이렇게 되면 매번  쿼리마다 자동으로 커밋이 되다 보니 하나의 작업 단위를 묶을 수가 없어서 auto commit 옵션을 false로 주고 개발자가 직접 commit, rollback을 해야 된다.

 

커넥션 연결을 하게 되면 데이터베이스 내부에 세션이 생성되고 세션을 통해서 트랜잭션을 시작하고 SQL을 실행, 커밋, 롤백, 트랜잭션 종료와 같은 작업이 이루어진다.

하나의 논리적인 작업 단위의 기준은 비즈니스 로직으로 서비스 계층에서 시작을 해야 하는데 이렇게 되면 서비스 클래스에서 커넥션을 꺼내기 위해 DataSource를 가지고 트랜잭션 시작, commit, rollback, 트랜잭션 종료 등의 처리를 하는 코드가 들어가게 된다.

 

public void accountTransfer(String fromId, String toId, int money) throws
  SQLException {
	Connection con = dataSource.getConnection();
	try {
        con.setAutoCommit(false); //트랜잭션 시작 //비즈니스 로직
        bizLogic(con, fromId, toId, money); con.commit(); //성공시 커밋
    } catch (Exception e) { con.rollback(); //실패시 롤백
        throw new IllegalStateException(e);
    } finally {
        release(con);
    }
}

위의 예시에서 bizLogic()에서는 트랜잭션을 유지하기 위해 동일 커넥션을 사용해야 되고 repository를 호출할 때마다 커넥션을 파라미터로 전달해줘야 한다. 그리고 SQLException 같이 JDBC 전용 예외 같은 구체화에 의존성이 생기는 등 JdbcTempalte, JPA .. 데이터 접근 기술의 변경에 영향을 받게 된다.

 

스프링은 이러한 문제를 해결하기 위해 트랜잭션 추상화 인터페이스 TransactionManager를 제공하는데 트랜잭션 추상화, 커넥션 동기화 역할을 대신해 준다. 

 

 

커넥션은 트랜잭션 동기화 매니저가 스레드별 저장소인 스레드 로컬을 통해 동기화를 해서 파라미터로 전달하지 않아도 유지할 수 있다. 스레드 로컬은 사용 후 정리하는 것이 매우 중요하기 때문에 (+ 커넥션 반납 등) 개발자가 직접 하기보다는 제공되는 기술을 사용하는 것이 안전하다.

 

트랜잭션 매니저를 사용해도 커밋, 롤백 try-catch를 하는 코드가 남아있는데 스프링 AOP를 활용한 @Transactional을 사용하면 깔끔하게 처리가 가능해진다.

 

@Transactional을 정확히 이해하려면 스프링 AOP를 학습해야 되는데 일단은 왜 써야 하는지 정도만 알고 넘어갔다.

@Transactional을 클래스에 메서드에 사용하면 트랜잭션 AOP는 프록시를 만들어 스프링 컨테이너에 등록하는데 이 프록시가 트랜잭션을 관리하는 로직을 대신 처리해 주게 된다. 

 

한 가지 주의점은 외부에서 요청을 하면 프록시 객체가 요청을 먼저 받아서 트랜잭션을 처리하고, 실제 메서드를 호출해 주는데 만약 내부에서 메서드를 호출하는 경우 프록시를 거치지 않아서 트랜잭션이 적용되지 않는 문제가 생긴다.

이전에는 클래스에 @Transactional을 readOnly 설정으로 두고 데이터 삽입, 수정, 삭제 메서드만 따로 @Transacional을 선언해서 사용을 해서 그런지 이런 위험 요소를 인식하지 못했다.

 

클래스에 @Transactional을 선언하는 경우 트랜잭션이 의도하지 않은 곳까지 과도하게 적용이 돼서 메서드 단위로 적용을 한다. 트랜잭션은 주로 비즈니스 로직의 시작점에 걸기 때문에 외부에서 열어둔 곳을 시작점으로 해서 클래스에 @Transactional 애노테이션을 선언해도 public 메서드에만 적용이 된다.

 

 

추가적으로 스프링 트랜잭션 AOP는 예외의 종류에 따라 트랜잭션을 커밋하거나 롤백하는데 RuntimeException , Error와 그 하위 예외가 발생하면 롤백, 체크 예외와 그 하위 예외가 발생하면 커밋을 한다. (@Transactional에서 rollbackFor 옵션으로 변경 가능)

체크 예외의 경우 비즈니스적인 예외 상황에서 주로 사용한다고 하는데 예를 들면 회원의 주문 Order에서 잔고 부족의 경우 일단 커밋을 하고 추가 결제를 하도록 할 수도 있다. (생각해 보니 체크 예외는 사용한 적이 없는 거 같은데 중요한 비즈니스 예외 상황에서 사용하면 좋을 것 같다.)

 

간단 정리

@Transactional 사용하는 이유

 

- 애플리케이션에서 트랜잭션 관리

- 비즈니스 로직과 관련 없는 중복 코드 제거

- 예외 전파, 관리

 

JdbcTemplate은 템플릿 콜백 패턴을 사용해서 JDBC를 직접 사용할 때 발생하는 대부분의 반복 작업을 대신 처리해 준다.

 

- 커넥션 획득, 종료, statement, resultset 종료

- 트랜잭션을 다루기 위한 커넥션 동기화

- 예외 발생 시 스프링 예외로 변환

 

JdbcTemplate에서 tryForStream() 메서드를 사용하면 예외적으로 직접 리소스 종료를 해줘야 하는데 그렇지 않을 경우 커넥션 반납이 되지 않는 문제가 생긴다. 같이 공부하는 분이 커넥션 반납이 되지 않는다고 물어보셨을 때 @Transactional 역할을 잘 알고 있었으면 이 부분을 먼저 확인해 봤을 거 같은데 금붕어처럼 다 까먹고 말똥말똥 쳐다보고 있었다. @Transactional을 사용하면 트랜잭션 기능 외에도 DB 접근 기술마다 커넥션이 종료되지 않는 상황에서 안전하게 처리를 해주는 이점도 있는 것 같다.

 

 

[참고]

인프런 김영한님 DB 접근 기술 1,2편

Real MySQL 단톡방에서 어떤 분이 페이징을 할 때 order by에 대해 질문을 하셨는데 저자분께서 친절하게 답변을 해주셨다. 마침 코드스쿼드에서 미션으로 간단한 게시판 구현을 해보고 있어서 LIMIT 옵션에 대해서 공부를 해보았다.

Real MySQL 11장 LIMIT

더보기

MySQL의 LIMIT는 항상 쿼리의 가장 마지막에 실행되고 LIMIT에서 필요한 레코드 건수만 준비되면 즉시 쿼리를 종료한다.

 

ORDER BY나 GROUP BT, DISTINCT가 인덱스를 이용해 처리될 수 있다면 LIMIT 절은 꼭 필요한 만큼의 레코드만 읽게 만들어주기 때문에 쿼리의 작업량을 상당히 줄여준다.

 

LIMIT는 1개 또는 2개의 인자를 사용할 수 있는데 첫번째 인자에 지정된 위치부터 두번째 인자에 명시된 개수만큼의 레코드를 가져온다.

 

즉 LIMIT(시작 위치, 오프셋)으로 LIMIT 10과 같이 인자가 1개인 경우는 LIMIT 0, 10과 동일하다.

 

참고로 LIMIT의 인자로 표현식이나 별도의 서브쿼리는 사용할 수 없다.

 

LIMIT 쿼리에서 주의할 점은 몇 건을 읽을건지보다 그 결과를 만들어 내기 위해 어떤 작업을 했는지다.

 

SELECT * FROM salaries ORDER BY salary LIMIT 2000000, 10;

 

위의 쿼리는 salaries 테이블을 처음부터 읽으면서 2000010건의 레코드를 읽어서 2000000건은 버리고 마지막 10건만 반환한다. 그래서 이런 경우 WHERE 조건으로 읽어야 할 위치를 찾고 그 위치에서 10개만 읽는 형태의 쿼리를 사용하는 것이 좋다.

 

댓글 리스트 조회시 Request Parameter로 startId와 읽어올 개수 size를 전달 받는다. 더보기 버튼을 누르면 다음 댓글들을 더 보여주도록 구현을 했다.

 

이전에 LIMIT 조건의 주의점을 보긴 했었는데 까먹고 있다가 다시 책을 보면서 아차 싶었다. LIMIT에 시작 위치를 주는 경우 그 값이 점점 커진다면 성능이 저하될 수 있으니 WHERE 조건을 잘 활용하도록 주의해야겠다. (물론 지금은 전체 게시글이 아닌 특정 게시글의 댓글을 조회하는 것이기 때문에 큰 문제는 없을 것 같다.)

+ ORDER BY가 인덱스를 이용해 처리될 수 있으면 LIMIT 시 쿼리의 작업량을 많이 줄여준다.

 

 

더보기 버튼을 누르는 식으로 구현을 했기 때문에 댓글 리스트를 읽어올 때 전체 count를 불필요하게 읽을 필요가 없다. 대신 다음 댓글이 있는지 여부를 확인하기 위해 size + 1만큼 읽어온다. Dto로 변환할 때는 subList()를 사용해서 size 개수(마지막 페이지의 경우 size 이하의 개수)만큼 잘라주었다. (급하게 구현해서 네이밍이 맘에 안 든다..)

 

 

응답 결과는 다음처럼 댓글 리스트와 다음 댓글 여부(hasNext)를 반환해준다.

 

커서 기반 페이징이 간단한 것 같았는데 아래 글을 보니 복잡한 경우에서는 고려해야 될 부분이 많은 것 같다.. 갈 길이 멀다.

 

커서 기반 페이지네이션 (Cursor-based Pagination) 구현하기

사실 처음에는 이 주제로 포스트를 쓰려고 했던건 아니고 Apollo GraphQL 에서 커서 기반 페이지네이션 구현 을 주제로 글을 쓰려고 했습니다. 그런데 막상 찾아보니 백엔드-프론트엔드를 함께 고려

velog.io

 

 

 

 

[참고]

Real MySQL 8.0

서블릿은 웹 서버의 요청을 받아서 동적인 페이지를 생성하고 반환하는 과정을 편리하게 처리할 수 있도록 지원하는 자바 웹 프로그래밍 기술이다.

 

What Is a Servlet?

A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications accessed by means of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes.

The javax.servlet and javax.servlet.http packages provide interfaces and classes for writing servlets. All servlets must implement the Servlet interface, which defines life-cycle methods. When implementing a generic service, you can use or extend the GenericServlet class provided with the Java Servlet API. The HttpServlet class provides methods, such as doGet and doPost, for handling HTTP-specific services.

This chapter focuses on writing servlets that generate responses to HTTP requests.

 

서블릿은 인터페이스를 구현해서 사용해야 하는데 init(), destroy()와 같이 생명 주기를 관리하는 메서드가 있으며 일반적으로 기본적인 틀을 제공하는 GenericServlet을 상속 받아서 service() 추상 메서드를 구현한다.

 

HTTP 요청과 관련된 메소드를 제공하는 HttpServlet을 보면 GenericServlet을 상속 받아서 service()를 Override했다.

 

서블릿은 독립적으로 생성, 실행될 수 없고 관리를 해주는 무언가가 있어야 하는데 이러한 역할을 해주는 것이 서블릿 컨테이너이며 대표적으로 서블릿 컨테이너를 구현한 WAS(Web Application Server)인 톰캣이 있다. (Tomcat = Web Server + Servlet Container)

 

서블릿 컨테이너는 서블릿의 생명 주기를 관리하고 웹서버와 소켓으로 통신하며 요청을 받아서 응답을 전달하는 다양한 기능을 제공한다.

 

멀티 스레드를 지원하는 서블릿 컨테이너는 요청을 받으면 스레드를 생성하고 Request, Response 객체를 생성해서 서블릿의 service()를 실행한뒤 스레드를 종료시킨다. 이때, 서블릿은 요청 시마다 생성 되지 않고 최초 1회만 생성이 된다. 

 

위에 사진은 GenericServlet의 service() 추상 메서드로 HttpServlet은 GenericServlet을 상속 받아서 이 service() 메서드를 Http 요청을 처리하도록 구현하였다.

 

정리를 하면 서블릿 컨테이너가 웹 서버로부터 요청을 받으면 Request, Response 객체를 생성하고 매핑된 서블릿을 찾아서 service 메서드를 실행한다. 

 

ServletWebServerFactory servletWebServerFactory = new TomcatServletWebServerFactory();

WebServer webServer = servletWebServerFactory.getWebServer(servletContext -> {
    servletContext.addServlet("myServlet", new HttpServlet() {
        @Override
        protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
            //...
        }
    }).addMapping("/hello");
});

 

이렇게 각각의 서블릿에 url 매핑을 하면 중복되는 코드도 많고 비즈니스 로직과 뷰 로직이 결합 되어 있어서 유지보수 하기 어려운 코드가 된다. 그래서 MVC 패턴과 스프링MVC가 나오게 되는데 모든 요청을 받아서 공통 로직을 처리하고 컨트롤러의 핸들러 역할을 하는 프론트 컨트롤러인 DispatcherServlet이 있다.

 

 

처음 스프링 부트로 개발을 하면 기본적으로 톰캣이 내장되어 있고 서블릿 관련 설정을 지원해주기 때문에 이해가 부족한 경우가 많은데 코드 몽키가 되지 않으려면 잘 알아야 될 것 같다..!

 

다음에는 DispatcherServlet에 대해 정리를 해야겠다.

 

[참고]

 

What Is a Servlet? - The Java EE 5 Tutorial

What Is a Servlet? A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications accessed by means of a request-response programming model. Although servlets can respond to any type of request, the

docs.oracle.com

인프런 김영한님, 토비님 강의

망나니개발자님 블로그

+ Recent posts