da-nyee

회사 기술 블로그 기고

Fri, 31 Jan 2025 17:46:26 +0900

작년 11월, 회사 기술 블로그에 글 한 편 기고했다.
주제는 주니어 서버 개발자가 유저향 서비스를 개발하며 마주쳤던 이슈와 해결 방안.

회사 입사할 때 회사에서 이건 해봐야지 하고 정했던 나름의 목표가 있는데, 그 중 하나가 기술 블로그 기고였다.
업무도 하고 글도 쓰고 과정이 순탄하지만은 않았지만, 목표를 하나 이뤄서 뿌듯하다.
한편으론 부족할 수도 있는 글인데 생각보다 사람들이 관심을 많이 가져줘서 신기하기도 했다.

언젠가 기회가 또 생기면 그때는 더 맛있는 주제로 써봐야겠다.

내용이 궁금하다면 여기로 🙈

[MySQL] CROSS JOIN

Sun, 23 Jul 2023 00:56:40 +0900

CROSS JOIN

Cartesian Product (n * m)
on/where절(조건절)을 거의 사용하지 않는다.
CROSS JOIN + ON/WHERE은 INNER JOIN과 동일한 결과를 반환한다.
따라서 이런 경우에는 직관적인 INNER JOIN을 사용하는 게 낫다.

References

[Java] 객체지향적으로 입력 유효성 검증하기

Tue, 04 Oct 2022 03:03:40 +0900

스프링에 의존하지 않고, 즉 bean validation을 사용하지 않고 입력 유효성을 검증할 수 있는 방법은 없을까?
물론 있다.
조건문을 나열해서 확인할 수도 있고, 유효성 검증을 위한 객체를 생성해서 확인할 수도 있다.

이번 글에서는 유효성 검증을 위한 객체를 생성해서 확인하는 방법을 위주로 살펴보려고 한다.
단순한 로직이라면 조건문을 나열하는 방법이 빠르고 쉬울 수 있다.
하지만 유지보수와 확장성의 관점에서, 아무리 단순한 로직이더라도 유효성 검증을 위한 객체를 생성하는 것이 더 좋다고 생각한다.

절차지향적인 코드

절차지향적으로 코드를 작성하면 어떤 문제가 있을까?

유효성 검증 로직이 간단한 경우에는 딱히 문제가 없을 수 있다.
하지만 유효성 검증 로직이 조금이라도 복잡해지면, 새로운 로직을 추가하거나 기존 로직을 수정할 때 어려움을 겪을 수 있다.

이 방법은 코드의 전체적인 가독성을 낮추고, 개발자가 실수할 가능성을 높인다.
결국 유지보수하기 어려운 코드로 만든다.

public class Validator { public void validate(Request request) { if (request == null) { // Do something } if (request.getA()) { // Do something } if (request.getB()) { // DO something } if (request.getA() > 0) { // Do something } ... } } 

객체지향적인 코드

한편, 객체지향적으로 코드를 작성하면 어떨까?

설명을 위해 간단한 회원가입 프로젝트를 생성했다.
자세한 코드는 여기를 확인하자.

회원가입 정책은 다음과 같다.
▪️ 개인유저와 기업유저가 가입할 수 있다.
▪️ 개인유저는 아이디, 비밀번호, 이름이 필수값이다.
▪️ 기업유저는 아이디, 비밀번호가 필수값이다.

객체 의존관계는 다음과 같다.

각 필드마다 validator 클래스를 만들고, 모든 validator를 하나로 묶는 인터페이스로 validator를 한 단계 추상화한다.
인터페이스는 validate()와 isSatisfiedBy()를 가지고, 구현체는 유효성 검증 로직과 유효성 검증 조건을 구현한다.

isSatisfiedBy()를 예로 들면, 아이디는 모든 유저에서 유효성을 검증하므로 무조건 true를 반환한다.
한편 이름은 개인유저에서만 유효성을 검증하므로 개인유저면 true, 기업유저면 false를 반환한다.

// SignUpValidator.java public interface SignUpValidator { List<InvalidResponse> validate(ValidationRequest request); boolean isSatisfiedBy(boolean isCompany); } // IdValidator.java @Component public class IdValidator implements SignUpValidator { private static final InvalidResponse INVALID_RESPONSE = new InvalidResponse("id", "유효하지 않은 id"); @Override public List<InvalidResponse> validate(ValidationRequest request) { String id = request.getId(); if (id == null || isBlank(id)) { return Collections.singletonList(INVALID_RESPONSE); } if (isLowercaseOrNumber(id)) { return Collections.emptyList(); } return Collections.singletonList(INVALID_RESPONSE); } private boolean isBlank(String id) { return id.trim().isEmpty(); } private boolean isLowercaseOrNumber(String id) { return id.matches("[a-z0-9]+"); } @Override public boolean isSatisfiedBy(boolean isCompany) { return true; } } // PasswordValidator.java ... // NameValidator.java @Component public class NameValidator implements SignUpValidator { private static final InvalidResponse INVALID_RESPONSE = new InvalidResponse("name", "유효하지 않은 name"); @Override public List<InvalidResponse> validate(ValidationRequest request) { String name = request.getName(); if (name == null || isBlank(name)) { return Collections.singletonList(INVALID_RESPONSE); } if (isKorean(name)) { return Collections.emptyList(); } return Collections.singletonList(INVALID_RESPONSE); } private boolean isBlank(String name) { return name.trim().isEmpty(); } private boolean isKorean(String id) { return id.matches("[가-힣]+"); } @Override public boolean isSatisfiedBy(boolean isCompany) { return !isCompany; } } 

모든 validator를 완성했다면, 필드 validator를 사용하는 클라이언트 클래스를 생성한다.
이 클래스는 List로 validator를 조합한다.
validate()에서 stream을 흘려 어떤 validator에게 유효성 검증을 위임할지 결정한다.(filter)
유효성 검증을 하고(map), 전체 유효성 검증 결과를 모아서 반환한다.(collect)

// SignUpValidation.java @Component @RequiredArgsConstructor public class SignUpValidation { private final List<SignUpValidator> validators; public List<InvalidResponse> validate(ValidationRequest request) { if (request == null) { return Collections.singletonList(new InvalidResponse("request", "유효하지 않은 request")); } return validators.stream() .filter(validator -> validator.isSatisfiedBy(request.isCompany())) .map(validator -> validator.validate(request)) .flatMap(Collection::stream) .collect(Collectors.toList()); } } 

만약 중복되는 메서드가 있다면?

추가적으로, 모든 validator에 중복되는 메서드가 있다면 어떻게 해야 할까?
이때는 인터페이스와 구현체 사이에 추상 메서드를 둬서 해결할 수 있다.

단, 클래스는 단 1번만 상속할 수 있기 때문에 최대한 인터페이스를 활용하는 걸 추천한다.
구현은 n번 할 수 있다.

public interface Validator { void duplicateValidate(); } public abstract class AAAValidator implements Validator { @Override protected void duplicateValidate() { ... } } public class BBBValidator extends AAAValidator { ... } public class CCCValidator extends AAAValidator { ... } 

결론

이번 예제를 만들면서 좀 더 확장에 유연하고 응집도가 높은 코드를 작성하기 위해 노력했다.

필드 validator는 현재 3개가 있지만, 기획이 변경되면 새로운 validator가 추가될 수 있다.
이때 상위 인터페이스를 구현하면 변경에 쉽게 대처할 수 있다.

각 validator는 특정 필드 입력값에 대한 유효성 검증이라는 책임만 다하면 되기 때문에 응집도가 높다.
클라이언트 클래스는 모든 validator를 사용하지만, 인터페이스에 의존하기 때문에 직접적인 결합도는 낮다.

결과적으로 절차지향적인 코드보다 유지보수하기 좋고 가독성이 뛰어난 코드가 됐다.

물론 이 방식이 최선은 아닐 수 있다.
그렇지만, 한 번쯤 활용해봐도 좋을 것 같다.

[Web] 정규표현식 (Regular Expressions)

Fri, 19 Aug 2022 01:45:01 +0900

정규표현식

문자열에서 특정 패턴을 만족하는 부분을 찾아낼 때 사용한다.

\d

숫자 대표문자
digit
1글자만 찾는다.

\w

글자 대표문자
word
a, b, c, 가, 나, 다, 1, 2, 3과 같은 문자와 숫자를 포함한다.
특수문자는 포함하지 않지만, _는 포함한다.
1글자만 찾는다.

+

1개 이상

*

0개 이상
e.g. [1-9]\d*는 자연수

?

있거나 없거나
e.g. \d+-?\d+-?\d+는 전화번호(숫자-숫자-숫자 or 숫자숫자숫자)

[]

속한 것 중에 하나
e.g. [- ]?는 - or (공백)이 있거나 없거나
\d+[- ]?\d+[- ]?\d+는 전화번호(숫자-숫자-숫자 or 숫자숫자숫자 or 숫자 숫자 숫자)

{숫자}

숫자번 반복
e.g. \d{2}는 숫자가 2번 반복

{숫자1, 숫자2}

숫자1부터 숫자2까지 반복
e.g. \w{2,3}은 문자가 2-3번 반복

[어떤 것-어떤 것]

범위 지정
e.g. [a-z]는 소문자 알파벳만 선택
[가-힣]은 한글만 선택

[어떤 것-어떤 것]+

범위 지정인데 1개 이상
e.g. [a-z]+는 소문자 알파벳이 1개 이상
[가-힣]+는 한글이 1개 이상(한글 단어)

다양한 대표문자

\s

공백 문자
e.g. 스페이스, 탭, 뉴라인

\S

공백 문자를 제외한 문자

\D

숫자를 제외한 문자

\W

글자 대표문자를 제외한 문자
e.g. 특수문자, 공백 등

\대문자 알파벳이면 반대(여집합)의 의미인 것 같다.

프로그래밍 언어와 정규표현식 사용

Java, C#

대표문자를 표현할 때 \를 2번 써야 한다.
escape 때문이다.
e.g. \\d, \\w 등등

JavaScript, Python

대표문자를 표현할 때 \를 1번만 써도 된다.
raw string을 지원하기 때문이다.
e.g. \d, \w 등등

Reference

프로그래머스 스쿨 - 정규표현식

[Java] Optional.orElse() vs Optional.orElseGet()

Sat, 06 Aug 2022 02:35:11 +0900

요즘 Spring Reactive로 작성된 코드를 Spring MVC로 변경하면서 Optional을 자주 활용하고 있다.
예를 들면 switchIfEmpty()를 orElseGet()으로 대체한다.
문득 orElse()도 있는데, orElseGet() 대신 사용해도 괜찮지 않나? 라는 생각이 들었다.
하지만 두 메소드가 따로 구현된 이유가 있을 것이고, 둘의 차이를 잘 모르는데 아무거나 쓸 수는 없었다.
그래서 이번 기회에 제대로 이해하고, 어떤 상황에 어떤 것을 써야 하는지 알아야겠다 싶어 정리해본다.

orElse()

메소드 시그니처를 보면, 매개변수로 T를 받고 리턴값으로 T를 반환한다.
메소드 구현을 보면, 값이 null이 아니면 값을 반환하고 null이면 매개변수를 반환한다.

public T orElse(T other) { return this.value != null ? this.value : other; } 

orElseGet()

메소드 시그니처를 보면, 매개변수로 Supplier를 받고 리턴값으로 T를 반환한다.
(참고로 Supplier는 매개변수를 받지 않고 리턴값을 반환하는 함수형 인터페이스이다.)
메소드 구현을 보면, 값이 null이 아니면 값을 반환하고 null이면 Supplier의 get()을 호출한다.

public T orElseGet(Supplier<? extends T> supplier) { return this.value != null ? this.value : supplier.get(); } 

학습 테스트

소스코드를 까보기만 했을 때는 값이 null일 때 처리하는 로직이 다른 것 외에는 무슨 차이가 있는지 파악하기 어려웠다.
좀 더 깊이 있게 이해하기 위해 학습 테스트를 진행했다.

코드 작성

다음과 같이 애플리케이션을 만들었다.
요새 어디든지 떠나고 싶어서, 여행지를 정해주는 매우 간단한 애플리케이션을 구현해봤다.

// Application.java public class Application { public static void main(String[] args) { Trip trip = new Trip(); // 로직 } } // Trip.java public class Trip { public String choose() { System.out.println("여행지 선택 중"); Destination destination = new Destination(); String city = destination.choose(); System.out.println("여행지 선택 완료"); return city; } } // Destination.java public class Destination { public String choose() { return "Victoria, Canada"; } } 

값이 null이 아닐 때

orElse()

Optional의 값이 null이 아닌데, orElse()의 trip.choose()가 실행됐다.
결과는 기대대로 ‘San Francisco, USA’로 나왔다.

// Application.java public class Application { public static void main(String[] args) { Trip trip = new Trip(); String city = Optional.of("San Francisco, USA").orElse(trip.choose()); System.out.println(city); } } 

> Task :Application.main() 여행지 선택 중 여행지 선택 완료 San Francisco, USA 

orElseGet()

Optional의 값이 null이 아니어서, orElseGet()의 trip.choose()는 실행되지 않았다.
결과는 예상대로 ‘San Francisco, USA’로 나왔다.

// Application.java public class Application { public static void main(String[] args) { Trip trip = new Trip(); Object city = Optional.of("San Francisco, USA").orElseGet(trip::choose); System.out.println(city.toString()); } } 

1 2 > Task :Application.main() San Francisco, USA

값이 null일 때

orElse()

Optional의 값이 null이어서, orElse()의 trip.choose()가 실행됐다.
결과는 기대대로 ‘Victoria, Canada’가 나왔다.

public class Application { public static void main(String[] args) { Trip trip = new Trip(); String city = Optional.empty().orElse(trip.choose()); System.out.println(city); } } 

> Task :Application.main() 여행지 선택 중 여행지 선택 완료 Victoria, Canada 

orElseGet()

Optional의 값이 null이어서, orElseGet()의 trip.choose()가 실행됐다.
결과는 예상대로 ‘Victoria, Canada’가 나왔다.

public class Application { public static void main(String[] args) { Trip trip = new Trip(); Object city = Optional.empty().orElseGet(trip::choose); System.out.println(city.toString()); } } 

> Task :Application.main() 여행지 선택 중 여행지 선택 완료 Victoria, Canada 

결론

orElse()는 Optional의 값이 무엇이든 항상 로직이 실행된다.
orElseGet()은 Optional의 값이 null일 때만 로직이 실행된다.

만약 요번 예제처럼 orElse()/orElseGet()에 어떤 객체를 생성하는 코드가 들어갈 때 orElse()를 쓴다면, Optional의 값이 null이 아닌 경우 불필요한 객체가 계속 생성되는 문제가 발생한다.
이는 성능에 영향을 주고, 힙 메모리 공간을 불필요하게 차지하게 만든다.
그러므로 Optional의 값이 null일 때만 호출되는 orElseGet()을 쓰는 게 좋다.

그동안 두 메소드의 차이를 정확하게 인지하지 못하고 사용해왔다.
요번 기회에 확실하게 알게 됐고, 앞으로는 orElseGet()을 지향하며 상황에 맞는 메소드를 써야겠다.

References

Optional 내부 코드 & 학습 테스트
Java Optional – orElse() vs orElseGet()

[Spring] Spring WebFlux + Swagger 3.0 적용

Sun, 24 Jul 2022 00:52:56 +0900

의존성 추가

build.gradle에 필요한 의존성을 추가한다.

// webflux implementation 'org.springframework.boot:spring-boot-starter-webflux' // swagger implementation 'io.springfox:springfox-boot-starter:3.0.0' implementation 'io.springfox:springfox-swagger-ui:3.0.0' 

Swagger 설정

SwaggerConfig 클래스를 생성하고, Swagger 설정에 필요한 코드를 작성한다.

// SwaggerConfig.java @Configuration @EnableSwagger2 public class SwaggerConfig { @Bean public Docket api() { return new Docket(DocumentationType.SWAGGER_2) .useDefaultResponseMessages(false) .consumes(getConsumeContentTypes()) .produces(getProduceContentTypes()) .apiInfo(apiInfo()) .select() .apis(RequestHandlerSelectors.basePackage("com.example.gommunity")) .paths(PathSelectors.any()) .build(); } private Set<String> getConsumeContentTypes() { Set<String> consumeContentTypes = new HashSet<>(); consumeContentTypes.add("application/json;charset=UTF-8"); consumeContentTypes.add("application/x-www-form-urlencoded"); return consumeContentTypes; } private Set<String> getProduceContentTypes() { Set<String> produceContentTypes = new HashSet<>(); produceContentTypes.add("application/json;charset=UTF-8"); return produceContentTypes; } private ApiInfo apiInfo() { return new ApiInfoBuilder() .title("Gommunity API") .description("Gommunity API") .build(); } } 

문서 커스터마이징

Controller, Request/Response DTO에 Swagger 어노테이션을 붙여 문서를 커스터마이징한다.

// UserCommandController.java @Api(tags = {"유저 등록, 수정"}) @RequiredArgsConstructor @RestController @RequestMapping("/api/users") public class UserCommandController { private final UserCommandService userCommandService; @PutMapping public ResponseEntity<Mono<UserUpsertResponse>> upsertUser( @Valid @RequestBody UserUpsertRequest request ) { return ResponseEntity.ok(userCommandService.upsertUser(request)); } } // UserUpsertRequest.java @Getter @NoArgsConstructor @AllArgsConstructor public class UserUpsertRequest { @ApiModelProperty(value = "유저 id") private String id; @ApiModelProperty(value = "유저 이름", example = "다니") @NotBlank private String name; @ApiModelProperty(value = "유저 나이", example = "26") @NotNull private Integer age; } // UserUpsertResponse.java @Builder @Getter @NoArgsConstructor @AllArgsConstructor public class UserUpsertResponse { @ApiModelProperty(value = "유저 id") private String id; } 

실행 결과

여기까지 진행하고 애플리케이션을 실행하면, 아래처럼 Swagger 문서가 생성된다.

하지만 여기에는 한 가지 문제가 있다.
Request Body는 잘 나오지만, Response Body는 빈 배열( {} )로 나온다.

WebFlux는 Mono<T> 또는 Flux<T>로 응답하는데, 이와 관련된 설정을 하지 않아 생기는 문제이다.

해결 방법

SwaggerConfig 클래스의 api()에 Mono<T>, Flux<T>와 관련된 설정을 추가한다.

// SwaggerConfig.java @Bean public Docket api() { return new Docket(DocumentationType.SWAGGER_2) .useDefaultResponseMessages(false) .consumes(getConsumeContentTypes()) .produces(getProduceContentTypes()) .apiInfo(apiInfo()) .select() .apis(RequestHandlerSelectors.basePackage("com.example.gommunity")) .paths(PathSelectors.any()) .build() .genericModelSubstitutes(Mono.class, Flux.class); // 이 부분을 추가한다. } 

최종 결과

애플리케이션을 다시 실행해보면, 이제 Response Body도 잘 나오는 것을 확인할 수 있다.

Reference

spring-boot-starter-webflux swagger 3 설정

[MySQL] Lock 이모저모

Thu, 30 Jun 2022 02:09:11 +0900

InnoDB 스토리지 엔진을 기준으로 설명한다.

읽기 잠금

Shared Lock(S Lock)
T1 트랜잭션은 r1 행을 읽을 때 S Lock을 획득한다.
T2 트랜잭션은 해당 행을 읽을 수 있지만(이때도 S Lock을 획득), 쓸 수는 없다.
어떤 행에 S Lock이 걸리면, 해당 행에 S Lock은 걸 수 있고 X Lock은 걸 수 없다.(한 행에 여러 S Lock을 걸 수 있다.)

쓰기 잠금

Exclusive Lock(X Lock)
T1 트랜잭션은 r1 행에 쓸 때 X Lock을 획득한다.
T2 트랜잭션은 해당 행을 읽을 수 없고, 쓸 수도 없다. T1이 커밋/롤백할 때까지(X Lock을 풀 때까지) 기다려야 한다.
어떤 행에 X Lock이 걸리면, 해당 행에 S Lock과 X Lock을 모두 걸 수 없다.

비관적 잠금

Pessimistic Lock
SELECT … FOR UPDATE 쿼리
어떤 행을 읽고 쓰는 쿼리이다.
어떤 트랜잭션이 해당 행에 대해 X Lock을 걸어, 해당 트랜잭션이 끝날 때까지 다른 트랜잭션은 접근할 수 없다.
쉽게 `이 행은 내꺼니까 연산이 끝날 때까지 접근할 수 없어`로 생각할 수 있다.
비관적 잠금은 동시성 문제를 해결할 수 있는 방안 중 하나이다.
데이터 안정성을 확보할 수 있지만, 성능에 영향을 줄 수 있다.

미세팁

InnoDB 스토리지 엔진에서는 Gap Lock과 Next Key Lock으로 Repeatable Read 격리 수준에서도 Phantom Read가 발생하지 않는다. 따라서 Serializable 격리 수준까지 올리지 않아도 된다.
하지만 SELECT … FOR UPDATE 쿼리를 쓰면 Repeatable Read 격리 수준에서도 Phantom Read가 발생할 수 있다.(예외적인 상황)
SELECT … FOR UPDATE 쿼리는 SELECT하는 행에 X Lock을 걸어야 한다.
그런데 Undo Log의 행에는 잠금을 걸 수 없다.
결국 해당 쿼리로 가져오는 행은 Undo Log의 변경 전 데이터가 아니고, 현재 테이블의 데이터여서 Phantom Read가 나타날 수 있다.

References

[Spring] @Transactional(rollbackFor={exceptionClass})

Mon, 23 May 2022 04:03:30 +0900

스프링에서 @Transactional을 사용하면 기본적으로 모든 예외에 대해 롤백하는 줄 알았다.
근데 아니었다.

@Transactional에는 rollbackFor 옵션이 있다.
요 옵션의 주석을 보면 다음과 같다.

By default, a transaction will be rolling back on RuntimeException and Error but not on checked exceptions (business exceptions). See org.springframework.transaction.interceptor.DefaultTransactionAttribute.rollbackOn(Throwable) for a detailed explanation.

기본적으로 RuntimeException과 Error에 대해서만 롤백하고, Exception에 대해서는 롤백하지 않는다.
즉 unchecked exception이 발생하면 롤백하고, checked exception이 발생하면 커밋한다.

주석을 따라 DefaultTransactionAttribute 클래스를 확인했다.
요 클래스에는 많은 메소드가 있는데, 그 중 rollbackOn()의 주석을 읽어봤다.

The default behavior is as with EJB: rollback on unchecked exception ({@link RuntimeException}), assuming an unexpected outcome outside of any business rules. Additionally, we also attempt to rollback on {@link Error} which is clearly an unexpected outcome as well. By contrast, a checked exception is considered a business exception and therefore a regular expected outcome of the transactional business method, i.e. a kind of alternative return value which still allows for regular completion of resource operations.

This is largely consistent with TransactionTemplate’s default behavior, except that TransactionTemplate also rolls back on undeclared checked exceptions (a corner case). For declarative transactions, we expect checked exceptions to be intentionally declared as business exceptions, leading to a commit by default.

결국 unchecked exception은 비즈니스상 예상하지 못해 롤백하고, checked exception은 의도했을 수 있어 커밋한다.

여기까지 @Transactional의 기본적인 롤백 전략을 이해했다.

요 전략이 실제로 잘 적용되는 건지 궁금했다.
직접 코드를 통해 확인하고 싶었다.
그래서 학습 테스트를 진행했다.

학습 테스트는 아래에서 볼 수 있다.

학습 테스트

코드 작성

Member 엔티티를 생성했다.

// Member.java @Entity public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; protected Member() { } public Member(String name) { this.name = name; } // getter } 

MemberController에 Member를 저장하는 API를 만들었다.

// MemberController.java @RestController public class MemberController { private final MemberService memberService; public MemberController(MemberService memberService) { this.memberService = memberService; } @PostMapping("/api/members") public ResponseEntity<Void> save(String name) throws Exception { memberService.save(name); return ResponseEntity.ok().build(); } } 

MemberService에 각 예외를 분기 처리하는 로직을 구현했다.

// MemberService.java @Service @Transactional public class MemberService { private static final Logger LOG = LoggerFactory.getLogger(MemberService.class); private final MemberRepository memberRepository; public MemberService(MemberRepository memberRepository) { this.memberRepository = memberRepository; } public void save(String name) throws Exception { Member member = new Member(name); memberRepository.save(member); // 예외는 아무거나 던졌다. if ("커밋".equals(name)) { LOG.info("[Exception] member 저장 성공 - 커밋 O, 롤백 X"); throw new ActionException(); } if ("롤백 1".equals(name)) { LOG.info("[RuntimeException] member 저장 실패 - 커밋 X, 롤백 O"); throw new IllegalStateException(); } if ("롤백 2".equals(name)) { LOG.info("[Error] member 저장 실패 - 커밋 X, 롤백 O"); throw new IllegalAccessError(); } LOG.info("member 저장 성공 - 커밋 O, 롤백 X"); } } 

MemberRepository도 정의했다.

// MemberRepository.java public interface MemberRepository extends JpaRepository<Member, Long> { } 

결과 확인

포스트맨에서 API를 호출하고, DB에서 결과를 확인했다.

localhost:8080/api/members?name=다니
localhost:8080/api/members?name=롤백 1
localhost:8080/api/members?name=롤백 2
localhost:8080/api/members?name=커밋

주석 내용대로 unchecked exception은 롤백됐고, checked exception은 커밋됐다.
ID 값이 1, 4인 걸 보면 알 수 있다.

rollbackFor 추가

어떤 예외가 발생해도 롤백하고 싶어 rollbackFor에 Exception.class를 지정했다.
Exception.class는 모든 예외의 상단에 위치해 있기 때문이다.

@Service @Transactional(rollbackFor = {Exception.class}) public class MemberService { ... } 

localhost:8080/api/members?name=다니
localhost:8080/api/members?name=롤백 1
localhost:8080/api/members?name=롤백 2
localhost:8080/api/members?name=커밋
localhost:8080/api/members?name=데이지

요기서는 Exception.class를 롤백 조건에 명시하여 모든 예외에 대해 롤백이 일어났다.
ID 값이 1, 5인 것을 보면 알 수 있다.

결론

@Transactional의 기본적인 롤백 전략은 unchecked exception이다.
하지만 커스텀하게 변경할 수 있다.
특정 예외에 대해 롤백하고 싶다면, 해당 예외 클래스를 rollbackFor에 적어주면 된다.

새로운 사실을 알았으니 앞으로 잘 활용해야겠다.
요것과 관련한 이슈가 생겼을 때, 디버깅을 좀 더 쉽게 할 수 있을 것 같다.

References

Transactional 내부 코드
DefaultTransactionAttribute 내부 코드
Spring 학습 테스트
응? 이게 왜 롤백되는거지?

[Redis] HyperLogLog

Tue, 26 Apr 2022 02:42:06 +0900

실시간 unique count는 어떻게 계산할까?

애플리케이션에서 자료구조를 사용해서 데이터를 저장하고, 같은 데이터가 들어오면 저장하지 않는 방법이 있다.
하지만 이 방법은 대용량 데이터를 다루는 애플리케이션에서는 적절하지 않다.
메모리 공간을 많이 차지해서 다소 무거울 수 있고, 더 중요한 비즈니스 로직을 처리하기 위한 리소스를 쓰기 때문이다.

그렇다면 더 효율적인 방식은 없을까?

Redis를 활용하면 조금 더 쉽고 가볍게 문제를 해결할 수 있다.
물론 Set과 같은 자료구조를 쓰는 방식은 아니다.
Redis에는 HyperLogLog 자료형이 있다.
이 자료형은 unique count를 세고, 메모리를 적게 차지하고 결과의 오차율도 낮다.

이어지는 내용에서 HyperLogLog의 개념과 명령어를 알아보자.

HyperLogLog?

Redis에 있는 자료형
key : value 형태로 데이터를 저장한다.
- key는 고유한 값이다.
- value는 unique count 값이다.
HyperLogLog는 특정 데이터를 저장하지 않고, unique count를 계산해서 저장한다.
따라서 어떤 데이터가 저장되었는지 확인할 수 없다.

명령어

PFADD

1개의 key와 n개의 value를 한번에 입력할 수 있다.
key에 value가 없으면 1을, 있으면 0을 반환한다.

# src/redis-cli PFADD {key} {value1} {value2} .. % src/redis-cli PFADD woowacourse dani suri (integer) 1 % src/redis-cli PFADD woowacourse dani (integer) 0 % src/redis-cli PFADD woowacourse pomo (integer) 1 % src/redis-cli PFADD woowacourse mazzi (integer) 1 % src/redis-cli PFADD woowacourse suri pomo mazzi (integer) 0 % src/redis-cli PFADD backend dani better solong (integer) 1 % src/redis-cli PFADD frontend sunny ella (integer) 1 

PFCOUNT

key에 몇 개의 value가 저장되었는지, 즉 unique count를 센다.

# src/redis-cli PFCOUNT {key} % src/redis-cli PFCOUNT woowacourse (integer) 4 

PFMERGE

2개 이상의 key를 1개의 key로 합친다.
이때도 unique count를 구해서, 전체 value에서 중복되는 value는 1번만 더한다.
- e.g. woowacourse와 backend에 각각 dani가 있어, 둘을 합칠 때 dani는 1번만 count됐다.

# src/redis-cli PFMERGE {key1} {key2} {key3} .. % src/redis-cli PFMERGE woowacourse backend frontend OK % src/redis-cli PFCOUNT woowacourse (integer) 8 

References

[Fintech] VAN vs PG, 그리고 간편 결제

Wed, 06 Apr 2022 03:20:02 +0900

VAN

이미지 출처: PG와 VAN 무엇이 다를까?

Value Added Network
오프라인 결제 (카드 단말기, POS 단말기)
가맹점은 VAN사 덕분에 카드사와 편리하게 결제를 연동할 수 있다.
하지만 VAN사가 매출 정산은 따로 해주지 않아, 각 카드사마다 매출을 정산받아야 한다.
만약 VAN사가 없었다면? 가맹점은 각 카드사와 결제 계약을 맺고 사용해야 한다.
가맹점마다 쓸 수 있는 카드가 달랐을 것이다.
e.g. NHN한국사이버결제, 나이스정보통신, 한국정보통신

PG

이미지 출처: PG와 VAN 무엇이 다를까?

Payment Gateway
온라인 결제
가맹점은 PG사 덕분에 카드사와 편리하게 결제를 연동하고, 매출을 정산받을 수 있다.
즉 PG사를 통해 여러 카드사와 한번에 거래하고, PG사와 계약한 정산일에 전체 매출액을 한번에 정산받는다.
e.g. NHN한국사이버결제, KG이니시스

간편 결제

앱에 카드를 등록해두면
- 온라인에서는 6자리 비밀번호만 입력해서
- 오프라인에서는 QR 코드와 같은 것을 사용해서 결제할 수 있게 하는 서비스
간편 결제는 양면시장이다. 가맹점과 유저를 동시에 모아야 한다. 그래서 마케팅을 많이 한다.
기업은 왜 간편 결제에 집중할까? 양면시장은 어느 한쪽에 경쟁력이 클수록 다른 한쪽에 협상력을 강하게 갖는다.
- 유저가 많다면, 가맹점이 먼저 찾을 수 있다. (저 간편 결제를 쓰면 매출에 도움이 되겠구나)
- 가맹점이 많다면, 유저는 편리해서 더 많이 이용할 수 있다.
요즘은 오프라인 가맹점을 유치하기 위해 힘쓰는데, 이는 O2O(Online to Offline) 때문이다.
O2O는 온라인에서 결제하고 오프라인에서 재화/서비스를 받는 것을 의미한다.
- 유저는 계산대에 줄을 서서 기다리지 않아도 된다.
- 유저는 카드/현금을 소지하지 않아도 된다. 모바일로 편리하게 결제할 수 있다.
e.g. 카카오페이, 네이버페이, 토스페이