Tecoble

다중 이미지 업로드 최적화: 병렬 스트림과 CompletableFuture

Thu, 23 Nov 2023 13:00:00 GMT

사이드 프로젝트로 sns 서비스를 개발하며 사용자가 다수의 이미지를 업로드하는 기능을 개발하게 되었다. 웹 애플리케이션에서 다중 이미지 업로드는 일반적이며, 이를 효율적으로 처리하는 것은 사용자 경험 향상에 중요한 역할을 한다.

그렇다면 서버 측에서는 여러 장의 이미지를 어떻게 효율적으로 업로드할 수 있을까?

이 글에서는 구체적인 이미지 저장 방법(로컬 스토리지 저장, 클라우드 서비스 사용, DB에 바이너리 데이터로 저장 등)을 떠나, 이미지 업로드 과정을 어떻게 하면 더 효율적이고 빠르게 처리할 수 있을지에 집중해 보고자 한다. 병렬 처리와 같은 기술을 활용하여 서버 성능을 최대한 활용하고, 사용자에게 빠른 응답 시간을 제공하는 방법을 예제 코드와 함께 살펴보자.

예제 코드 소개

이번 예제에서는 이미지 동반 포스트 업로드 서비스 를 구현했다. 전체 소스코드는 Github에서 확인 가능하다.

[요구사항]

한 포스트당 최대 10장의 이미지를 포함할 수 있다.

업로드 실패 시, 해당 포스트에 대한 모든 이미지 파일을 저장소에서 삭제한다.

클래스의 구조와 전체적인 코드의 흐름은 아래와 같다.

PostFacadeService는 전체 이미지 파일 업로드를 ImageStorageService에 요청한다.
ImageStorageService는 각 이미지 파일 업로드를 StorageClient에 요청한다.
이미지 업로드가 성공하면, PostFacadeService는 포스트 저장을 PostService에 요청한다.

이 포스트에서는 주로 ImageStorageService에 집중하여 여러 이미지 업로드 방법을 살펴본다.

순차적 업로드 방식

가장 기본적인 방법은 모든 이미지를 하나씩 순차적으로 업로드하는 것이다.

아래는 ImageStorageService에서 파일 업로드를 담당하는 uploadFiles() 코드이다.

public ImageUploadResponse uploadFiles(MultipartFile[] imageFiles) {
    validate(imageFiles);
    List<String> fileNames = new ArrayList<>();
    try {
        Arrays.stream(imageFiles)
            .map(storageClient::upload)
            .forEach(fileNames::add);
        return convertFileNamesToResponse(fileNames);
    } catch (Exception e) {
        executor.execute(() -> deleteFiles(fileNames));
        throw new InternalServerException("이미지 업로드 시 예외가 발생했습니다.");
    }
}

이미지 파일들을 순차적으로 StorageClient에 업로드 요청을 보내고, 업로드에 성공한 파일의 이름을 모아 반환한다.

[nio-8080-exec-1] : File Upload 시작 (871cb6aae189.png)
[nio-8080-exec-1] : File Upload 완료 (871cb6aae189.png)
[nio-8080-exec-1] : File Upload 시작 (1e17f3995ade.png)
[nio-8080-exec-1] : File Upload 완료 (1e17f3995ade.png)
[nio-8080-exec-1] : File Upload 시작 (587ab1b903d3.png)
[nio-8080-exec-1] : File Upload 완료 (587ab1b903d3.png)

위 로그에서 [nio-8080-exec-1]은 해당 작업이 진행된 스레드 이름을 나타낸다. 모든 요청이 단일 스레드에서 순차적으로 처리되는 것을 확인할 수 있다.

성능 측정

[PostFacadeService.createPost] 실행 시간(ms): 1396
[PostFacadeService.createPost] 실행 시간(ms): 1287
[PostFacadeService.createPost] 실행 시간(ms): 1251
[PostFacadeService.createPost] 실행 시간(ms): 1383
[PostFacadeService.createPost] 실행 시간(ms): 1338

10장의 354KB 이미지를 업로드하는 데에 평균 1331ms가 소요되었다.

다중 이미지 업로드 시, 단일 스레드를 사용하여 순차적으로 처리하는 방식은 간단하고 직관적이다. 이 방법을 사용하면, 각 이미지는 이전 이미지가 완전히 업로드된 후에 업로드된다. 그러나 이러한 단일 스레드 방식은 이미지 하나당 소요되는 시간이 누적되어 전체 업로드 시간이 길어지는 단점이 있다. 예를 들어, 이미지 하나를 업로드하는데 평균 130ms가 소요되고 10개의 이미지를 업로드한다면, 총소요 시간은 약 1300ms가 된다.

이에 비해, 여러 스레드를 사용하여 이미지를 병렬로 업로드하면 처리 시간을 단축할 수 있다. 이 방식에서는 여러 이미지가 동시에 업로드되므로, 10장의 이미지를 업로드하는 데 걸리는 시간을 1331ms에서 더 단축할 수 있을 것으로 예상된다.

이제 병렬 스트림을 활용한 이미지 업로드 방식에 대해 자세히 알아보자.

병렬 스트림을 활용한 업로드

Java 8부터는 컬렉션의 병렬 처리를 지원하는 “병렬 스트림(parallel stream)“이 도입되었다. 이를 활용하면, 여러 CPU 코어를 통해 작업을 효율적으로 분산시켜 더 빠르게 수행할 수 있다.

이를 활용하여 이미지 업로드를 병렬적으로 처리할 수 있다.

public ImageUploadResponse uploadFiles(MultipartFile[] imageFiles) {
    validate(imageFiles);
    List<String> fileNames = new ArrayList<>();
    try {
        Arrays.stream(imageFiles)
            .parallel() // 병렬 스트림 생성
            .map(storageClient::upload)
            .forEach(fileNames::add);
        return convertFileNamesToResponse(fileNames);
    } catch (Exception e) {
        executor.execute(() -> deleteFiles(fileNames));
        throw new InternalServerException("이미지 업로드 시 예외가 발생했습니다.");
    }
}

각 이미지 업로드 요청이 병렬 스레드에서 동시에 처리되는 것을 로그로 확인할 수 있다. 아래 로그에서 [onPool-worker-*]는 해당 작업이 진행된 스레드 이름이다.

[onPool-worker-6] : File Upload 시작 (871cb6aae189.png)
[onPool-worker-4] : File Upload 시작 (9af5a8a21538.png)
[onPool-worker-2] : File Upload 시작 (1e17f3995ade.png)
[onPool-worker-1] : File Upload 시작 (587ab1b903d3.png)
[onPool-worker-5] : File Upload 시작 (bdc9a80b2331.png)
[onPool-worker-7] : File Upload 시작 (faac3d412e3e.png)
[onPool-worker-3] : File Upload 시작 (85db46aad248.png)
[onPool-worker-1] : File Upload 완료 (587ab1b903d3.png)
[onPool-worker-1] : File Upload 시작 (3cf2f27aacb3.png)
[onPool-worker-5] : File Upload 완료 (bdc9a80b2331.png)
[onPool-worker-5] : File Upload 시작 (9343ba3a01d1.png)
[onPool-worker-2] : File Upload 완료 (1e17f3995ade.png)
...

성능 측정

[PostFacadeService.createPost] 실행 시간(ms): 256
[PostFacadeService.createPost] 실행 시간(ms): 223
[PostFacadeService.createPost] 실행 시간(ms): 213
[PostFacadeService.createPost] 실행 시간(ms): 217
[PostFacadeService.createPost] 실행 시간(ms): 238

병렬 스트림을 활용하니 처리 시간이 평균 1331ms에서 229ms로 약 5배 이상 단축되었다.

병렬 스트림 사용 시 주의점

병렬 처리 중 공유 자원에 대한 동시 접근 시 문제가 발생할 수 있다.

공유 자원과 `ConcurrentModificationException`

본 예제에서 이미지 파일들을 병렬로 업로드하는 작업 중 실패가 발생하면, 이미 업로드된 이미지들을 삭제하려고 한다. 이 과정에서 ConcurrentModificationException 예외가 발생할 수 있다. 이는 여러 스레드가 동시에 같은 컬렉션을 수정하려 할 때 발생하는 예외이다.

uploadFiles 메서드에서 파일 업로드가 성공하면 해당 파일의 이름을 fileNames 리스트에 추가한다. 만약 어떤 스레드의 업로드가 실패하면, 즉시 deleteFiles(fileNames) 메서드를 호출하여 삭제 작업을 시작한다. 이때 다른 스레드가 아직 업로드를 완료하지 않아 리스트에 새로운 요소를 추가하는 상황이 발생하면 ConcurrentModificationException 예외가 발생한다.

Exception in thread "taskExecutor-1" java.util.ConcurrentModificationException
at java.base/java.util.ArrayList.forEach(ArrayList.java:1513)
at practice.s3.application.ImageStorageService.deleteFiles(ImageStorageService.java:67)
at practice.s3.application.ImageStorageService.lambda$uploadFiles$0(ImageStorageService.java:38) <3 internal lines>

병렬 작업 종료 후 통합 예외 처리

이러한 문제를 방지하기 위해, 모든 병렬 작업이 끝난 후에 한꺼번에 예외를 처리하는 방식으로 코드를 개선했다.

public ImageUploadResponse uploadFiles(MultipartFile[] imageFiles) {
    validate(imageFiles);
    AtomicBoolean catchException = new AtomicBoolean(false);

    List<String> fileNames = Arrays.stream(imageFiles)
        .parallel()
        .map(file -> uploadFile(file, catchException))
        .filter(Objects::nonNull)
        .toList();
    handleException(catchException, fileNames);
    return convertFileNamesToResponse(fileNames);
}

private String uploadFile(MultipartFile file, AtomicBoolean catchException) {
    try {
        return storageClient.upload(file);
    } catch (Exception e) {
        catchException.set(true);
        return null;
    }
}

private void handleException(AtomicBoolean catchException, List<String> fileNames) {
    if (catchException.get()) {
        executor.execute(() -> deleteFiles(fileNames));
        throw new InternalServerException("이미지 업로드 시 예외가 발생했습니다.");
    }
}

여기서는 AtomicBoolean을 활용하여 예외 발생 여부를 각 스레드에서 안전하게 추적한다. 업로드 과정에서 예외가 발생하면, 해당 변수를 true로 설정하여 상태를 기록한다.

모든 병렬 작업이 종료된 후, 이 AtomicBoolean 상태를 검사함으로써 예외 발생 유무를 확인한다. 이렇게 함으로써 동시성 문제를 피하면서 안정적으로 예외를 처리할 수 있게 되었다.

병렬 스트림의 제약점

병렬 스트림은 내부적으로 ForkJoinPool을 사용하여 자동으로 작업을 여러 스레드에 분배한다. 이러한 분배는 시스템의 프로세서 수를 고려하여 스레드 수를 결정한다. 본 포스트의 성능 측정은 7개의 스레드가 활용된 환경에서 이루어졌다.

병렬 스트림의 스레드 수를 조절하는 것은 기술적으로 가능하나, 이 조정은 ForJoinPool.commonPool()에 대한 전역 설정을 변경하는 것이므로, 모든 병렬 스트림 작업에 영향을 미친다.

예를 들어, 작업 A에 최적화하기 위해 스레드 수를 10으로 설정한다면, 이는 작업 B,C,D 등 현재 진행 중인 다른 모든 병렬 스트림 작업에도 동일하게 적용된다. 따라서 각 작업의 특성에 따라 최적의 성능을 얻기 위해 병렬 스트림의 스레드 수를 독립적으로 조절하는 것이 쉽지 않다.

그렇다면, 더 세밀한 병렬 처리 제어를 원할 땐 어떻게 해야 할까?

CompletableFuture를 활용한 병렬 업로드

Java 8이 등장하면서, CompletableFuture는 비동기 프로그래밍에 큰 변화를 불러왔다. 이 클래스는 비동기 연산의 결과를 나타내는 것뿐만 아니라, 그 완료 시점과 연산의 수명 주기를 세부적으로 제어할 수 있게 해준다. 이는 단순히 결과를 기다리는 것을 넘어, 연산을 시작하고, 완료하며, 여러 작업을 결합하고, 예외를 처리하는 등의 복잡한 비동기 흐름을 명시적으로 제어할 수 있다는 의미다.

ForkJoinPool은 큰 작업을 작은 단위로 분할하여 병렬로 처리한 다음, 그 결과를 합치는 데 초점을 맞추고 있다. 반면, CompletableFuture는 기본적으로 사용하는 ForkJoinPool 외에도, 자체적으로 지정한 executor를 통해 스레드 풀을 직접 제어할 수 있다. 이를 통해 특정 작업에 최적화된 병렬 처리가 가능해지고, 복잡한 비동기 작업 흐름을 필요에 맞게 구성할 수 있게 된다.

예를 들어, 이미지 업로드 작업과 같이 I/O 집약적인 작업이 있을 때,CompletableFuture를 사용하여 특정 coreSize인 ThreadPoolTaskExecutor를 사용함으로써, 독립적인 스레드 풀을 구성하여 업로드를 병렬로 수행할 수 있다. 이는 각각의 작업이 다른 작업의 리소스 사용에 영향을 끼치지 않으면서 효율적으로 수행할 수 있도록 해준다. 이처럼 CompletableFuture는 복잡한 비동기 흐름을 잘 제어하고, 각 작업에 맞는 병렬 처리를 해야 하는 상황에서 유용한 도구이다.

본 예제에서는 한 포스트에 최대 10장의 이미지를 업로드하는 상황을 가정하여, coreSize가 10인 ThreadPoolTaskExecutor를 설정해 병렬 업로드를 실행했다.

@Configuration
public class AsyncConfig {

    @Bean
    public Executor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.initialize();
        return executor;
    }
}

@Autowired
private Executor executor:

public ImageUploadResponse uploadFiles(MultipartFile[] imageFiles) {
    validate(imageFiles);
    List<CompletableFuture<String>> futures = Arrays.stream(imageFiles)
        .map(file -> CompletableFuture.supplyAsync(() -> storageClient.upload(file), executor))
        .toList();

    List<String> fileNames = gatherFileNamesFromFutures(futures);
    return convertFileNamesToResponse(fileNames);
}

private List<String> gatherFileNamesFromFutures(List<CompletableFuture<String>> futures) {
    List<String> fileNames = new ArrayList<>();
    AtomicBoolean catchException = new AtomicBoolean(false);
    futures.forEach(future -> {
        try {
            fileNames.add(future.join());
        } catch (CompletionException e) {
            catchException.set(true);
        }
    });
    handleException(catchException, fileNames);
    return fileNames;
}

private void handleException(AtomicBoolean catchException, List<String> fileNames) {
    if (catchException.get()) {
        executor.execute(() -> deleteFiles(fileNames));
        throw new InternalServerException("이미지 업로드 시 예외가 발생했습니다.");
    }
}

uploadFiles 메서드는 이미지 파일들을 병렬로 업로드한다. CompletableFuture.supplyAsync()를 사용해 병렬 작업을 시작하며 그 결과를 CompletableFuture로 반환한다.

gatherFileNamesFromFutures 메서드는 join() 메서드를 사용해 각 CompletableFuture의 결과를 기다린 후, 해당 결과를 fileNames 리스트에 추가한다. join() 메서드는 CompletableFuture의 작업이 완료될 때까지 대기하고 그 결과를 반환한다.

만약 join() 메서드 수행 중 예외가 발생하면 CompletableException으로 감싸져 던져진다. 위 코드에서는 AtomicBoolean을 사용하여 예외 발생 여부를 관리한다.

이후의 예외 처리 전략은 병렬 스트림에서 사용된 방식과 동일하다.

성능 측정

// CommonForkJoinPool
[PostFacadeService.createPost] 실행 시간(ms): 312
[PostFacadeService.createPost] 실행 시간(ms): 261
[PostFacadeService.createPost] 실행 시간(ms): 322
[PostFacadeService.createPost] 실행 시간(ms): 251
[PostFacadeService.createPost] 실행 시간(ms): 241

// ThreadPoolTaskExecutor (coreSize 10)
[PostFacadeService.createPost] 실행 시간(ms): 182
[PostFacadeService.createPost] 실행 시간(ms): 161
[PostFacadeService.createPost] 실행 시간(ms): 197
[PostFacadeService.createPost] 실행 시간(ms): 191
[PostFacadeService.createPost] 실행 시간(ms): 179

스레드풀을 별도로 지정하지 않았을 때의 평균 처리 시간은 277ms였다. 반면, 커스텀 스레드풀을 적용했을 때의 평균 처리 시간은 182ms로 감소했으며, 이는 기존 병렬 스트림의 처리 시간 229ms와 비교하여 더 짧은 시간이다.

이 결과로부터 병렬 스트림과 CompletableFuture를 사용한 일반적인 처리에서 성능 차이는 크지 않지만, 특정 작업에 최적화된 executor를 사용하면 성능이 향상될 수 있다는 결론을 얻을 수 있다. 예를 들어, 대규모 파일 I/O 작업을 수행하는 경우에는 I/O 작업에 최적화된 스레드 풀 설정을 적용하여 디스크 접근과 네트워크 전송을 병렬로 처리할 수 있다. 고성능 컴퓨팅 작업에서는 CPU 사용률을 극대화할 수 있는 스레드 풀 구성으로 성능을 향상할 수 있다.

이처럼 실제 사용 시나리오와 요구 사항을 고려하여 성능 테스트를 실시하고, 테스트 결과를 바탕으로 특정 작업에 최적화된 스레드 풀을 선택하는 것이 중요하다.

마무리

이 글을 통해, 병렬 처리를 통해 다중 이미지를 효율적으로 업로드하는 기법들을 알아보았다. 그러나 이러한 기법들은 이미지 업로드에만 국한되지 않는다.

예를 들면, 웹 크롤링을 할 때 여러 사이트의 데이터를 동시에 수집하는 작업에서도 병렬 처리는 큰 이점을 가져다준다. 배치 작업에서도, 서로 독립적인 작업 항목들을 병렬로 처리함으로써 전체 작업 시간을 대폭 줄일 수 있다. 데이터베이스에서는 복잡한 쿼리나 대용량 데이터 처리를 병렬로 실행하여 응답 시간을 단축할 수 있다. 서버 측에서는 사용자의 다양한 요청을 동시에 처리하기 위해 요청 처리를 병렬로 수행하여, 더 빠른 서비스 제공이 가능해진다.

이처럼 병렬 처리는 단순히 업로드 시간을 단축하는 것을 넘어, 다양한 분야에서 응답성과 성능을 향상하는 핵심 기술이다.

본문에서는 특히 병렬 스트림과 CompletableFuture에 초점을 맞추어 알아보았는데, 이들은 각각의 사용 사례에 따라 장점이 있다.

병렬 스트림은 사용이 매우 간편하다는 장점이 있으나, 고정된 스레드 풀을 사용한다는 점에서 유연성이 다소 떨어진다. 반면, CompletableFuture는 보다 복잡한 비동기 작업을 우아하게 처리할 수 있으며, 특히 커스텀 스레드 풀을 사용하여 성능을 최적화할 수 있다.

이들 외에도 다양한 병렬 처리 방식이 존재한다. 상황과 요구 사항에 따라 가장 적합한 방법을 선택하고 적용하는 것이 중요하다. 따라서 다양한 방법을 시도하고, 성능 측정 결과를 바탕으로 자신에게 맞는 최적의 해결책을 찾는 것이 핵심이다.

JPA가 Fetch Join에 대한 On절을 지원하지 않는 이유

Thu, 23 Nov 2023 12:00:00 GMT

JPA가 Fetch Join에 대한 On절을 지원하지 않는 이유

집사의고민 프로젝트에서 조회 쿼리가 발생할 때 데이터가 삭제되는 상황이 발생하였습니다. 그래서 이번 글에서는 간단한 JPA의 Fetch Join 동작 원리와 유의해야 하는 부분들에 관해서 기술해보려고 합니다.

참고 ERD

아래와 같은 테이블 구조에서 발생하는 문제입니다. 참고로 테이블의 모든 컬럼을 명시하지는 않았습니다.

우선 쿼리가 정상적으로 동작하는지와 어떤 쿼리가 발생하는지를 알아보기 위해 간단한 테스트 코드를 작성하는 것으로 시작해 보겠습니다.

@DataJpaTest
@Import(QueryDslTestConfig.class)
@Sql(scripts = {"classpath:truncate.sql", "classpath:data.sql"})
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class PetFoodRepositoryImplTest {

    @Autowired
    private PetFoodQueryRepository petFoodQueryRepository;

    @Test
    void 키워드와_브랜드_이름으로_동적_조회한다() {
        // given
        final String keyword = "diet";
        final String brand = "베베";

        // when
        List<PetFood> petFoods = petFoodQueryRepository.searchPetFoodByDynamicValues(keyword, brand);

        // then
        assertAll(
                () -> assertThat(petFoods).extracting(petFood -> petFood.getKeyword().getName()).contains("diet"),
                () -> assertThat(petFoods).extracting(petFood -> petFood.getBrand().getName()).contains("퓨리나"),
                () -> assertThat(petFoods).hasSize(1)
        );
    }

}

쿼리 확인

Hibernate: 
// 1번
    select
        p1_0.id,
        p1_0.brand_id,
        p1_0.image_url,
        p1_0.keyword_id,
        p1_0.name,
        p1_0.purchase_link 
    from
        pet_food p1_0 
    join
        brand b1_0 
            on b1_0.id=p1_0.brand_id 
    join
        keyword k1_0 
            on k1_0.id=p1_0.keyword_id 
    where
        k1_0.name=? 
        and b1_0.name=?
Hibernate: 
// 2번
    select
        k1_0.id,
        k1_0.name 
    from
        keyword k1_0 
    where
        k1_0.id=?
petFood.getKeyword().getName() = 다이어트
Hibernate: 
// 3번
    select
        b1_0.id,
        b1_0.founded_year,
        b1_0.has_research_center,
        b1_0.has_resident_vet,
        b1_0.name,
        b1_0.nation 
    from
        brand b1_0 
    where
        b1_0.id=?
petFood.getBrand().getName() = 베베
=================================

총 1 + N(2)가 발생하여 3번의 쿼리가 발생했습니다. 이렇게 조회한 엔티티가 한 번, 그와 연관된 엔티티가 N번 조회되는 문제를 N+1 문제라고 합니다. Fetch Join 문법을 사용하여 이 문제를 해결할 수 있습니다. 이제 해당 쿼리를 개선해 보겠습니다.

Fetch Join으로 개선하기

위 문제를 해결하기 위해 PetFoodQueryRepository의 searchPetFoodByDynamicValues 메서드를 수정해 보겠습니다.

@Repository
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class PetFoodQueryRepository {

    private final JPAQueryFactory queryFactory;

    public List<PetFood> searchPetFoodByDynamicValues(String keywordName, String brandName) {
        return queryFactory
                .selectFrom(petFood)
                .join(petFood.keyword, keyword).on(equalsKeyword(keywordName))
                .join(petFood.brand, brand).on(equalsBrand(brandName))
                .fetchJoin()
                .fetch();
    }

    private BooleanExpression equalsKeyword(String keywordName) {
        if (hasText(keywordName)) {
            return keyword.name.eq(keywordName);
        }
        return null;
    }

    private BooleanExpression equalsBrand(String brandName) {
        if (hasText(brandName)) {
            return brand.name.eq(brandName);
        }
        return null;
    }

}

위와 같이 on절로 필터링을 진행하고 Fetch Join을 사용했습니다. 조인 조건은 다음과 같습니다.

키워드가 일치한 데이터만 Join
브랜드가 일치한 데이터만 Join

하지만 테스트 코드를 실행시키면 아래와 같은 에러가 발생합니다.

java.lang.IllegalArgumentException: org.hibernate.query.SemanticException: with-clause not allowed on fetched associations; use filters

에러를 자세히 읽어보면 not allowed on fetched associations이 발생하는 것을 확인할 수 있는데, 이는 fetch 구문에서 on절을 지원하지 않는다는 뜻입니다.

실제로 하이버네이트 공식 문서에는 이런 말이 있습니다.

“HQL(Hibernate Query Language)에서 Fetch Join에 별칭(Alias)이 필요한 유일한 이유는 추가 컬렉션(N방향)을 재귀적으로 조인하여 가져오는 경우밖에 없다.”

이 말은 Fetch Join에 on절이 필요한 경우는 거의 없다시피 하지만, 역설적으로 하이버네이트 상에서는 Fetch Join을 지원하긴 한다는 뜻입니다.

하지만 JPQL로 Fetch Join + on절을 사용하면 런타임 에러가 발생합니다.

JPQL에서는 Fetch Join에 on절을 지원하지 않을까요? 이 이유는 생각보다 간단하지만, 많은 분들이 간과하고 있을 것 같습니다.

Fetch Join의 한계

Fetch Join 문법은 N+1 문제를 방지하기 위해 연관관계가 맺어진 테이블의 모든 값들을 한 번에 가져옵니다. Fetch Join은 너무나 필수적인 기능이기도 하지만 다음과 같이 명확한 한계가 존재합니다.

Fetch Join의 대상은 별칭을 줄 수 없다.
- select절, where절, 서브쿼리 등에서 Fetch Join 대상을 사용할 수 없다.
- 하이버네이트 자체에서는 별칭을 지원하지만, 연관된 데이터 수에 대한 무결성이 깨질 수도 있다.(아래에서 자세하게 설명) JPQL과 querydsl에서 Fetch Join + on 문법을 지원하지 않는 이유도 위와 같다.
(참고) 2개 이상의 xToMany 관계에서는 모든 연관 엔티티에 Fetch Join을 적용할 수 없다.
- 대신 default_batch_fetch_size라는 차선책이 존재한다.
(참고) 페이지네이션 사용이 불가능하다.
- 컬렉션(xToMany) 관계에서 Fetch Join을 사용하면 페이징 처리가 불가능하다.

On절 대신 Where절로 사용하기

Fetch Join에서 on절을 지원하진 않지만, where절은 사용할 수 있습니다. 다만, 잘못 사용하면 꽤나 골치 아픈 일이 일어날 수도 있기 때문에 확실히 짚고 넘어가야 합니다.

Fetch Join의 On절을 지원하지 않는 이유는 무엇일까?

위에서 하이버네이트 자체에서는 별칭을 지원하지만, 연관된 데이터 수에 대한 무결성이 깨질 수도 있다고 했습니다. 이는 JPA에서 엔티티 객체 그래프와 DB의 데이터 일관성을 맞추어 주어야 하기 때문입니다. 예를 들어 아래와 같은 데이터가 있다고 가정해 보겠습니다.

brand1 - petFood1
brand1 - petFood2
brand1 - petFood3

만약 조인 대상(petFood)을 필터링의 주체로 사용하여 petFood3을 제외하고 조인한다면, JPA는 다음과 같은 결과를 반환해 줄 것입니다.

brand1 - [petFood1, petFood2]

얼핏 보면 잘못된 게 없습니다. 저희가 바라던 대로 데이터가 반환되었으니까요. 하지만 위와 같은 결과가 나오면 Fetch Join을 한 JPA의 입장에서 상당히 난처해집니다.

Fetch Join은 단 한 번의 쿼리로 join 대상 테이블 데이터까지 한 번에 가져오고 영속성 컨텍스트에 반영합니다. 그래서 임의로 데이터를 빼고 조회하면 db에는 해당하는 데이터가 없다고 판단합니다.

엔티티 값을 변경하면 db에 쉽게 반영되는 걸 알 수 있듯이, 이렇게 되면 최악의 경우에는 petFood3이 db에서 삭제될 수도 있습니다. 위 상황들을 고려해서 JPA는 이 상황을 방지하기 위해 별칭에 대한 조건절을 제공해주지 않습니다.

이해를 돕기 위해 쿼리문을 직접 작성해 보겠습니다. 예를 들어 brand(1)과 연관관계가 맺어진 petFood(N)을 Fetch Join으로 조회한다고 가정해 보겠습니다.

// 1번 쿼리
SELECT b FROM Brand b JOIN fetch b.petFoods pf ON pf.name = '베베'

1번 쿼리는 Fetch Join에 별칭을 사용했기 때문에 런타임에서 에러가 발생합니다. 따라서 N+1을 해결할 수 없습니다.

// 2번 쿼리
SELECT b FROM Brand b JOIN fetch b.petFoods pf WHERE pf.name = '베베'

사실 1번 쿼리와 2번 쿼리는 동일하게 동작하는 쿼리입니다. 그리고 조인과 무관하게 Brand 자체 데이터를 필터링하는 것이기 때문에, on절보다 where절을 사용하는 게 더 적절합니다.

Fetch Join과 Where절의 함정 그리고 Outer Join

“Fetch Join은 on을 지원하지 않지만, where로 해결할 수 있다.”라고 느껴질 수도 있는데, 반은 맞고 반은 틀린 말입니다. where절도 잘못 사용하게 된다면 on절과 똑같은 문제가 발생합니다.

우선 Brand와 PetFood 테이블에 대한 영속성 컨텍스트의 상황을 먼저 살펴보겠습니다. 우리가 Fetch Join을 사용할 때, 영속성 컨텍스트는 Fetch Join의 대상은 모두 존재한다고 가정합니다. 영속성 컨텍스트는 Fetch Join 실행 시 아래와 같이 베베 브랜드는 일료, 사료라는 데이터를 가지고 있죠.

그럼 여기에서 아래와 같은 Left Join Fetch 쿼리를 사용하게 되면 어떤 결과가 나올까요?

SELECT b FROM Brand b LEFT JOIN FETCH b.petFood pf WHERE pf.name='사료'

Fetch Join의 대상에 대한 조건을 걸었을 때 영속성 컨텍스트가 기대하는 객체 그래프의 상태와는 달라진 것을 볼 수 있습니다.

이로 인해 영속성 컨텍스트는 “원래는 베베 브랜드에는 일료, 사료라는 객체가 존재했는데, 일료 객체가 제거되었다.”라는 판단을 내리게 됩니다. 우리는 실제로 일료 객체를 삭제한 적이 없는데 말이죠.

위 그림처럼 베베 브랜드의 일료 데이터가 사라진 상태이기 때문에 저 상태에서 db에 flush가 된다면 실제 데이터베이스의 데이터가 삭제됩니다. 이렇게 잘못된 where절로 해결하려고 하다가 런타임 예외로 막아둔 것 마저 무시해 버리고 db 데이터를 삭제하게 될 수도 있으니 꼭 주의해서 사용해야 합니다.

검증 - Outer Fetch Join과 Where절 필터링

public interface BrandRepository extends JpaRepository<Brand, Long> {
  
    @Query("select b from Brand b left join fetch b.petFoods pf where pf.name = :petFoodName")
    Brand findBrandsByPetFoodName(@Param("petFoodName") final String petFoodName);
    
}

@Test 
void outer_fetch_join_test() {
    Brand brand = brandRepository.findBrandsByPetFoodName("사료");
    for (PetFood petFood : brand.getPetFoods()) {
        System.out.println("petFood.getName() = " + petFood.getName());
    }
}

petFood.getName() = 사료

위에서 봤던 그림처럼 brand는 데이터베이스 상에선 실제로 일료와 사료를 가지고 있지만, 조회해 보면 사료라는 데이터 단 하나만 가지고 있습니다. 그럼 여기서 좀 더 나가서 해당 영속성 컨텍스트를 데이터베이스에 flush 하게 되면 어떨까요?

@Service
@Transactional
@RequiredArgsConstructor
public class BrandService {
    
    private final BrandRepository brandRepository;
    
    public void getBrandByPetFoodName(final String petFoodName) {
        Brand brand = brandRepository.findBrandsByPetFoodName(petFoodName);
        brandRepository.saveAndFlush(brand);
    }
    
}

@Test
@Transactional
void outer_join_test() {
    brandRepository.findBrandsByPetFoodName("사료");
    List<Brand> brands = brandRepository.findAll();
    for (Brand brand : brands) {
        for (PetFood petFood : brand.getPetFoods()) {
            System.out.println(=======================);
            System.out.println("petFood.getName() = " + petFood.getName());
            System.out.println(=======================);
        }
    }
}

결과

=======================
petFood.getName() = 사료
=======================
petFood.getName() = 이료
=======================
petFood.getName() = 삼료
=======================

저희는 분명 값을 직접적으로 update 하거나 delete 하지 않았음에도 불구하고 데이터베이스에서 다시 조회했을 때 일료 데이터가 사라졌습니다. 실제 서비스에서 쿼리가 이렇게 나간다면, 유저들이 조회 쿼리 날릴 때마다 데이터가 사라집니다.

이런 문제를 방지하기 위한 몇 가지 방안이 있습니다.

outer Fetch Join에서 where절을 사용하지 않는다.
Fetch Join 대상에 where절을 사용하지 않는다.
하나의 트랜잭션이 무조건 조회만 수행하도록 한다.(DB에 Flush 될 일이 절대로 없도록)

만약 JPA를 사용하는 중 이런 쿼리가 발생한다면 위 3가지 중 하나를 잘 고민해 보고 적용해야 할 것 같습니다.

요약

JPA에서는 객체의 상태와 DB의 일관성 문제 때문에 다음과 같은 기능들을 제공하지 않는다.
- Fetch Join의 on절을 지원하지 않는다.
- Fetch Join 대상에 대해서는 별칭을 지원하지 않는다.
해당 문제를 해결하기 위해 where절을 사용하여 비즈니스를 풀어낼 수 있다.
- 단, Fetch Join의 컬렉션 결과 다(N) 쪽을 필터링 기준으로 작성하면 안 된다.
- 특히 Outer Join에 대해서는 더욱 조심해야 한다.

Fetch Join 문법은 JPA를 사용하는 개발자들에게 필수 문법인 만큼, Fetch Join의 side-effect도 간단하게 짚고 넘어가는게 좋아보입니다.

읽어주셔서 감사합니다.

데이터베이스 복제하기(리플리케이션) 2 - 테코와 알아보는 대규모 데이터 관리

Thu, 23 Nov 2023 12:00:00 GMT

테코의 고민 2 - 이벤트에 어떤 내용을 기록해야 해?

GTID 기반의 안정적인 복제 방식을 도입한 후 잘 운영되는 카페를 보며 행복한 나날을 보내는 테코.

그런데 어느 날, 데이터베이스에 저장된 회원 데이터를 전체적으로 업데이트하는 작업을 하던 도중

데이터베이스의 소스 서버와 리플리카 서버 A, 리플리카 서버 B는 데이터베이스의 여유 공간이 부족하다는 경고를 차례대로 보내왔어요.

데이터를 수정만 했지, 한꺼번에 대량으로 추가하는 작업은 하지 않았기 때문에 매우 의아해하던 테코는 그 원인이 바이너리 로그에 있음을 알아차리고 깊은 고민에 빠졌어요.

변경된 데이터를 기록한다면 - Row 포맷

테코네 서버의 데이터베이스는 바이너리 로그의 각 이벤트를 Row 포맷으로 기록하고 있었는데, 변경된 데이터를 그대로 바이너리 로그에 등록하는 특성상 매우 많은 데이터를 변경한 경우 그 대량의 데이터들이 전부 로그에 기록되면서 데이터베이스 공간에 과부하를 줄 수 있다는 문제가 있음을 알게 되었어요.

그렇다면 변경된 데이터를 그대로 바이너리 로그에 기록하는 대신 다른 방법을 쓸 수는 없을까. 차라리 실행한 SQL을 기록하는 게 낫지 않을까?

실행한 SQL을 기록한다면 - Statement 포맷

각 이벤트에서 실행한 SQL 문을 바이너리 로그에 기록하는 Statement 기반 바이너리 로그 포맷을 도입한다면 바이너리 로그의 용량이 크게 줄어들기 때문에 더 이상 용량 걱정을 하지 않아도 될 거예요.

하지만 Statement 포맷을 선뜻 적용하기에는 찝찝함이 느껴집니다.

SQL 문이 동일하다고 해도, 실행할 때마다 결과가 다르게 나타나는 몇몇 비 확정적(Non-Deterministic) 쿼리들이 있다면 소스 서버와 리플리카 서버의 데이터가 다르게 기록되는 정합성 문제가 일어날 수 있기 때문이었는데요!

Statement 포맷을 사용하게 된다면 데이터베이스의 저장 공간을 취하는 대신 데이터 정합성이 깨진다는 딜레마에 빠지고 만 테코.

데이터를 동일하고 안전하게 복제하면서도 바이너리 로그의 크기를 적당하게 유지할 수 있는 좋은 방법은 없을까요? 🥹

두 방법의 장점만 취할 수 있다면 - Mixed 포맷

이런 고민을 MySQL 개발자들도 당연히 했을 것!

테코가 겪고 있는 딜레마를 해소해 주기 위해 MySQL에서는 평소에는 Statement 포맷으로 기록하다가, 만약 Statement 포맷으로 복제했을 때 문제가 될 가능성이 있는 쿼리인 경우에는 Row 포맷으로 변환하여 기록해주는 Mixed 포맷을 제공하고 있습니다.

Mixed 포맷을 적용함으로써 바이너리 로그의 용량과 데이터 정합성을 성공적으로 지켜낸 테코!

시행착오를 겪으면서 많은 공부와 성장을 해내고 있습니다.

요약

MySQL 리플리케이션의 복제 데이터 포맷

Row 기반 바이너리 로그 포맷
Statement 기반 바이너리 로그 포맷
Mixed 포맷

자료 Real MySQL 8.0 2권 469p ~ 485p

테코의 고민 3 - 복제하는 동안 데이터에 차이가 있지 않을까

데이터의 리플리케이션을 처음 경험하는 테코는 이런 고민을 하기도 했습니다. ‘소스 서버에서 리플리카 서버로 데이터를 복제하는 데에도 시간이 걸리잖아. 복제하는 동안은 두 서버 사이의 데이터가 다를 텐데, 문제가 되지는 않을까?’

비동기

이런 고민이 들 만도 한 것이, 테코네 카페의 데이터베이스 리플리케이션은 비동기 복제(Asynchronous replication) 방식으로 동작하고 있었기 때문인데요!

이름에서 유추할 수 있듯, 소스 서버의 이벤트가 리플리카 서버들에게 잘 전송되었는지 확인하지 않기 때문에 서버들 간 데이터에 차이가 생길 가능성이 있습니다.

비동기 방식의 리플리케이션을 계속하기에는 찜찜한 테코. ‘동기 방식’ 같은 더 안전한 동기화 방법은 없을까 찾아보던 중 웃긴 이름의 동기화 방식을 알게 되었습니다.

‘반’동기

반동기(Semi-synchronous replication). 특이한 이름입니다. 왜 반만 동기일까요?

비동기 복제 대신 반동기 복제를 선택하면 소스 서버와 리플리카 서버 사이의 동기화를 ‘어느 정도’는 보장할 수 있겠네요!

하지만 반동기 복제 또한 정확히 어느 시점에 이벤트를 리플리카 서버로 전송하고 응답을 받느냐에 따라 AFTER_SYNC, AFTER_COMMIT이라는 두 종류로 나눌 수 있었습니다.

흔치 않은 장애 상황에서만 일어날 수 있는 문제이지만, 팬텀 리드와 같은 데이터 정합성 문제가 일어날 여지가 있는 방식이 AFTER_COMMIT이군요 🤨

데이터의 정합성을 지키려면 AFTER_SYNC 방식의 반동기 복제를 적용하면 되겠다는 결론을 내린 테코. 반동기 복제 적용 방법이 MySQL 문서에 자세히 나와 있으니 그대로 따라 하기만 하면 되지만, 적용하기 전 마지막으로 진지하게 고민해 보기로 합니다. 데이터베이스의 속도를 내리면서까지 꼭 정합성을 지켜야만 할까?

성능과 정합성 사이의 줄다리기

‘사용자가 소스 서버에 쓰기 작업을 하고, 리플리카 서버에서 그 데이터를 읽으려 하면 데이터가 없을 수도 있잖아!’라고 생각한다면 데이터 정합성을 위해 반동기 방식을 쓰는 게 안전해 보이지만,

사실 데이터의 리플리케이션 작업은 우리의 생각보다 훨씬 짧은 시간 안에 이루어진다고 해요.

테코는 자신이 운영하는 카페의 성격을 되짚어 보았을 때, 비동기 복제 방식을 계속 쓴다고 하더라도 큰 불편이 일어날 일이 없으며 오히려 반동기 복제를 사용했을 때 데이터베이스의 작업 처리 속도가 느려져서 불편해할 사람들이 더 많겠구나! 라는 결론을 내렸어요.

그렇게 비동기 복제 방식을 계속 사용하기로 마음먹은 테코는 더 새롭고 좋은 기술이 있다고 해도 무조건 적용하기 전에 그것이 본인에게 꼭 필요한 기술인지 고민하는 것이 중요하다는 깨달음을 얻었습니다. 😊

요약

MySQL 복제 동기화 방식

비동기
반동기

자료 Real MySQL 8.0 2권 pp.484~493

번외 - 리플리케이션 구조(토폴로지)

지금까지 리플리케이션을 설명하면서 예시로 들었던 테코네 카페 데이터베이스 설정은 소스 서버(쓰기용) + 리플리카 서버 1(읽기용) + 리플리카 서버 2(예비용) 이렇게 3대로 구성된 멀티 리플리카 복제 구성을 하고 있었습니다.

이런 멀티 리플리카 구성 외에도, 리플리케이션을 수행하는 목적에 따라 다양한 형태로 데이터베이스들을 두고 운영할 수 있어요.

일반적으로 사용되는 데이터베이스 구성 방식들을 간단히 알아본 후 포스트를 마무리하겠습니다. 🐋

싱글 리플리카 복제 구성

소스 서버 1 + 리플리카 서버 1로 구성된 가장 단순한 구성 방식을 싱글 리플리카 복제 구성이라고 불러요!

멀티 리플리카 복제 구성

싱글 리플리카 복제 구성에서, 다른 용도의 데이터베이스가 더 필요해서 여분의 리플리카 서버를 더 두기 시작한다면 멀티 리플리카 복제 구성이 돼요.

테코의 데이터베이스도 백업 용도 외에 읽기 작업을 수행하는 데이터베이스가 필요하게 되면서 멀티 리플리카 복제를 사용하게 됐었죠!

체인 복제 구성

만약 소스 서버는 하나인데, 복제를 해주어야 하는 리플리카 서버가 엄청나게 많아진다면 어떻게 해야 할까요? 예를 들어, 대규모 서비스를 지탱하는 기술이라는 서적에서 예시로 든 하테나라는 기업은 데이터베이스 서버만 25대였다고 해요.

만약 이 기업의 리플리케이션 구성이 소스 서버 1대와 리플리카 서버 24대로 이루어졌다면, 소스 서버에서 리플리카 서버들로 이벤트를 전송하는 작업 자체가 부하로 작용할 수도 있을 거예요.

이때는 리플리카 서버가 또다시 다른 리플리카 서버에 대한 소스 서버 역할을 하는, 사슬같은 구조의 체인 복제 구성을 생각해볼 수 있습니다.

MySQL 서버를 전체적으로 업그레이드하거나, 장비를 일괄적으로 바꿀 때 복제 그룹 단위의 교체를 할 수 있는데요! 대략 아래와 같은 과정을 통해 교체가 이루어집니다.

듀얼 소스 복제 구성

지금까지 알아본 복제 구성은 데이터 쓰기용 서버는 하나만 사용하고, 읽기용 서버만을 확장한다는 전제를 바탕으로 한 구성이었어요.

하지만 쓰기 작업을 아주 많이 하는 서비스인 경우에는 쓰기용 서버를 여러 개 두어야 할 수도 있습니다!

ACTIVE-PASSIVE와 ACTIVE-ACTIVE

요약

MySQL 리플리케이션의 복제 토폴로지

싱글 리플리카 복제 구성
멀티 리플리카 복제 구성
체인 복제 구성
듀얼 소스 복제 구성

자료 Real MySQL 8.0 2권 pp.494~503

이렇게 테코네 카페의 시행착오를 따라가 보면서 데이터베이스, 그중에서도 MySQL의 리플리케이션 작업에 대해 알아보았습니다.

참고 자료로 활용한 Real MySQL 8.0 2권에 훨씬 자세한 내용이 기록되어 있으니 참고하시길 바라요!

읽어주셔서 고마워요. 테코도 이제 행복하게 살아야 한다! 🙌🏻🙌🏻🙌🏻

도움을 주신 분

데이터베이스 복제하기(리플리케이션) 1 - 테코와 알아보는 대규모 데이터 관리

Thu, 23 Nov 2023 11:00:00 GMT

일상을 공유하는 작은 카페 사이트를 직접 개발해 운영하고 있는 테코(1세). 사이드 프로젝트로 만든 카페에 많은 사람들이 들어와 응원의 글을 남기자 테코는 행복해해요.

그런데 어느 날! 카카오톡에 ‘귀염둥이 우테코’ 신상 이모티콘이 출시되고, 이 이모티콘이 선풍적인 인기를 끌며 테코의 카페에 유례없이 많은 사람이 유입되기 시작했어요.

하지만 테코의 작은 서버와 데이터베이스로는 엄청나게 많은 사람으로 인한 트래픽을 감당하기에 너무나 버거웠고,

결국 테코의 데이터베이스에 과부하가 걸려 고장 나기에 이르렀어요.

데이터베이스를 뚝딱뚝딱 고쳐서 다시 가동하기까지 걸린 시간은 길어야 3시간 남짓. 하지만 그 3시간 동안 카페를 전혀 이용하지 못한 사용자들은 불만이 가득했어요.

짜증 한가득한 사람들에게 사과문을 쓰고 마음에 깊은 상처를 받은 테코는 다음에 또 데이터베이스 과부하가 생기더라도 카페를 내리지 않고 계속 서비스할 방법을 공부해 적용하기로 합니다.

데이터베이스를 하나 더 두자 - 스케일 아웃

테코는 생각했어요. 하나뿐인 데이터베이스가 고장 나면 이것을 완전히 고칠 때까지 카페를 정지할 수밖에 없구나.

만약 똑같은 데이터를 가지고 있는 예비용 데이터베이스 서버를 하나 더 둘 수 있다면, 원래 쓰던 하나가 고장 나더라도 예비용 서버로 카페를 운영하고 그동안 고장 난 쪽을 수리하면 되겠구나!

테코는 카페의 단일 장애점(SPOF) 에 해당하는 데이터베이스의 문제점을 해결하기 위해 데이터베이스에 대한 스케일 아웃을 도입해 보기로 했어요.

오! 어떻게 이런 생각을 해냈담. 테코는 자신이 천재가 아닌가 생각했어요.

실행력 강한 테코는 우선 데이터베이스 서버 2대를 추가로 구입해, 총 3대의 데이터베이스 서버를 가진 구조를 갖추었어요.

굿! 하지만 관리가 필요한 서버의 숫자가 늘어나자 테코는 이전까지 해본 적 없던 새로운 고민을 하게 되었습니다.

여러 개의 데이터베이스가 어떻게 데이터를 똑같이 가져? - 리플리케이션 개요

테코의 서버에 데이터베이스를 더 설치해서 데이터베이스가 총 세 개가 되긴 했는데,

실시간으로 데이터가 빠르게 생겼다 수정됐다 사라지는 상황에서 어떻게 다수의 데이터베이스 데이터를 똑같이 동기화, 즉 리플리케이션(Replication) 해주느냐는 문제가 생겼습니다.

데이터베이스의 리플리케이션 방법을 사흘 밤낮으로 조사한 테코는 자신의 서버에서 사용하고 있는 MySQL에서 리플리케이션 기능을 제공해 주고 있다는 것을 알게 되었고 이 기능을 공부해 보기로 하였어요!

MySQL의 리플리케이션

”MySQL 서버에서 일어나는 모든 변경 기록은 바이너리 로그(Binary Log) 라는 파일에 순서대로 기록된다. 그리고 이 바이너리 로그 안의 변경 기록 하나하나를 바이너리 로그 이벤트, 또는 짧게 이벤트(Event) 라고 한다.”

이 문장을 읽자마자 눈을 반짝이는 테코. 그렇다면 운영 중인 데이터베이스에서 기록한 모든 바이너리 로그를 예비용 데이터베이스로 가져와 똑같이 적용하면 간단하게 데이터 동기화를 해낼 수 있겠구나!

테코는 MySQL의 데이터 복제 과정을 조금 더 자세히 들여이다보았어요.

바이너리 로그 -> 바이너리 로그 덤프 스레드 -> 리플리케이션 I/O 스레드 -> 릴레이 로그 -> 리플리케이션 SQL 스레드로 이어지는 긴 여정을 통해 두 데이터베이스가 빠르게 동기화할 수 있도록 MySQL에서 도와주고 있었어요.

이 세 대의 서버 데이터를 동기화하기 위해서는 먼저 MySQL 리플리케이션의 중요한 전략 하나를 정해야 했습니다.

바로 소스 서버에 있는 바이너리 로그의 이벤트 하나하나를 리플리카 서버에서 어떤 방식으로 읽어올 것인가였습니다.

테코의 고민 1 - 바이너리 로그를 어떻게 식별할까

1. 바이너리 로그 이벤트의 이름과 위치를 통해 식별하자

바이너리 로그 파일 안에는 여러 개의 이벤트가 순서대로 저장되어 있습니다. ‘그럼 복제하려는 파일의 이름이랑, 복제해 올 이벤트의 위치만 정확하게 알 수 있다면 이걸 사용해 로그를 식별하면 되겠다!’라고 테코는 생각했어요.

그 생각을 그대로 재현한 바이너리 로그 파일 위치 기반 리플리케이션 을 적용해 두 데이터베이스의 동기화에 성공한 테코. 소스 서버에서 리플리카 서버로 데이터를 쇽쇽 복사해 주는 것을 지켜보면서 뿌듯해하고 있습니다.

위 방법의 문제점

그런데 어느 날, 또 다른 우테코 이모티콘 신상이 출시되면서 소스 서버가 또 터지고 말았어요!

테코는 하얗게 타버린 기존의 소스 서버 대신 읽기 전용으로 사용하던 리플리카 서버를 새로운 소스 서버로 대체하고, 백업용으로 사용하던 리플리카 서버를 읽기 전용 서버로 대체하려고 했습니다.

하지만 백업용 리플리카 서버의 상태를 보고 크게 당황한 테코. 백업용 리플리카 서버에는 소스 서버로부터의 동기화가 50분 정도 늦게 진행되어, 소스 서버가 가지고 있던 원본 데이터와 50분만큼의 차이가 있는 상태였어요.

‘헉, 그래도 A 서버는 소스 서버와 같은 데이터를 가지고 있으니까, A 서버의 바이너리 로그를 읽어서 데이터 동기화를 이어가면 되겠다!’라는 똑똑한 생각을 하는 테코.

하지만 바이너리 로그 위치 기반 리플리케이션의 치명적인 단점으로 인해 테코의 계획은 무용지물이 되었고, 결과적으로 과부하로 마비된 데이터베이스 서버는 1대인데 실제로 쓸 수 없게 된 서버는 2대가 되는 참혹한 상황을 맞게 되었어요.

결국 2대가 분담해야 할 대량의 부하를 1대가 감당하게 되었고, 또다시 테코의 카페는 새하얀 오류 화면만을 보여주게 되었습니다.

어떤 문제가 있었던 걸까요?

결국 또다시 반성문을 쓰게 된 테코. 바이너리 로그 파일 위치 기반 복제의 문제점을 몸소 깨닫게 되었네요.

2. 바이너리 로그 이름을 통일해서 사용하자

’특정 서버에서만 식별할 수 있는 이름과 위치 정보는 다른 서버에서 이용할 수 없다.’

뼈아픈 깨달음을 얻은 테코는 리플리카 서버에서 소스 서버의 이벤트를 읽어올 더 나은 방법을 생각해 내야 했어요.

놀랍게도, 5.5 버전 이후의 MySQL은 이 아이디어를 실현하여, 글로벌 트랜잭션 아이디(Global Transaction Identifier, GTID) 를 이용한 복제 방식을 제공하고 있었습니다.

GTID 기반 복제의 효과

어느날 우테코 컬렉션이 또 출시되어 소스 데이터베이스 서버가 또 고장났어요! 과연 GTID 기반 복제를 적용한 지금은 장애에 잘 대처할 수 있을까요?

와우! 바이너리 로그 파일 위치 기반 복제와 다르게 소스 서버의 GTID를 리플리카 서버에서도 이용할 수 있게 됨으로써 리플리카 서버 A로부터 리플리카 서버 B로의 데이터 동기화가 가능하게 되었어요.

만세를 부르는 테코!

요약

MySQL 리플리케이션의 복제 타입

바이너리 로그 파일 위치 기반 복제
글로벌 트랜잭션 아이디(GTID) 기반 복제

자료 Real MySQL 8.0 2권 pp.434~445

로컬에서도 프로덕션과 유사한 환경에서 테스트할 수 없을까? : Testcontainers 도입기

Tue, 21 Nov 2023 20:00:00 GMT

우아한테크코스 레벨3과 레벨4 동안 프로젝트를 진행하면서, 로컬 테스트 환경과 실제 운영 환경이 다른 기술적 어려움을 겪었습니다.
해당 어려움으로 비롯된 문제 상황과 단계적 해결 방안, 그리고 최종 해결 방안으로 도입한 Testcontainers에 대한 소개와 사용법을 공유하려 합니다.

문제 상황 : 로컬에서는 H2, 프로덕션에서는 MySQL

Spring Boot를 사용하여 프로젝트를 진행했습니다. 로컬 테스트 시에는 Spring Boot에 embedded 되어있는 H2를 사용했습니다. 개발 서버와 운영 서버에서는 MySQL을 사용했습니다. 그리고, Flyway를 통해 DB Schema 관리를 했습니다.

개발을 진행하며, 사용자분들의 니즈에 맞춰 프로젝트의 요구사항들이 추가되었습니다. 또, 리팩터링을 하며 패키지를 컨텍스트별로 분리했습니다.
이러한 과정 중에 외래키와 unique 제약조건을 해제하거나 칼럼을 변경해야 하는 상황이 있었습니다.
이 때 H2와 MySQL의 문법이 달라서, MySQL 문법으로 작성되어있는 Flyway용 migration File 내의 sql문을 H2에서 사용하지 못했습니다. 그래서 H2를 사용하는 로컬 profile로는 빌드가 불가능한 문제가 있었습니다.

⚠️ Wix에서 만든 embedded MySQL 오픈소스를 사용하면 간단하게 의존성을 추가함으로써 테스트 시에 경량화된 MySQL을 사용할 수 있지만,

벤더가 변경될 시 해당 데이터베이스의 embedded 라이브러리가 없다면 같은 문제가 발생

embedded MySQL을 사용하기 위해 추가적인 소스코드 생성 필요

Window 환경에서 MySQL 8.0 이상을 지원하지 않음

추후에 이야기 할, 다른 리소스(AWS S3)에 대한 의존성도 해결하고 싶었음

위와 같은 문제로 해당 방법으로는 문제를 해결하지 않았습니다.

1차 해결 방안 : 로컬에서 Flyway를 사용하지 않는 방법

우선 팀에서 도출한 해결방안은 ’Flyway를 로컬에서 사용하지 말자!‘였습니다. 처음에 저는 아래와 같은 이유로 반대했습니다.

Flyway의 migration File이 제대로 작동하는지 로컬에서 확인할 수 없다.
도메인에 변경이 있을 때마다 테스트를 위한 스키마를 다시 수정해야한다.

그러나 다른 할 일들이 많이 남았는데도 서비스 배포까지 시간이 얼마 남지 않았고(~~하루 전이었던 건 안 비밀…~~), 해당 방법이 가장 간단하므로 적용하자는 의견에 동의하였습니다.
무사히 배포를 했지만, 추후 개발을 진행하며 우려했던 상황이 발생했습니다. 매번 테이블의 변경 사항이 있을 때마다 Flyway의 migration file에 ddl도 작성하고, 로컬 테스트 용 스키마도 매번 수정하는 공수가 추가로 들어서 더욱더 개발 리소스가 많이 들었습니다. 그리고 가장 큰 문제는 배포하기 전까지 Flyway가 제대로 작동하는지 알 수 없다는 점이었습니다.

2차 해결 방안 : 벤더 별로 Flyway Migration File 각각 작성

Flyway를 H2와 MySQL에 동시에 사용할 수 있는 방법을 구글링하고 공식 문서를 읽어본 결과, 각 벤더사 별로 패키지를 따로 두면 각각에 맞는 패키지에서 migration file을 읽는다는 것을 알게 됐습니다. 그래서 H2용과 MySQL용 패키지를 따로 두는 방법으로 해결했습니다.
이제 배포를 하기 전에 Flyway가 제대로 작동하는지를 H2 한정으로는 확인할 수 있게 됐습니다. 다만 아직도 H2가 아닌 MySQL 환경에서 Flyway가 제대로 작동하는지는 확신할 수 없다는 점, 그리고 ddl을 두 가지 버전으로 짜기 때문에 공수가 든다는 점이 문제로 남아있었습니다.

3차 해결 방안 : Docker를 띄워볼까?

~~ddl을 매번 두 개씩 짜다가 지친~~ 팀에서 더 좋은 방법을 협의하게 되었고, docker등을 사용하여 컨테이너로 MySQL 환경을 로컬에 구축하자고 의견을 냈습니다. 해당 방법은 실제 운영환경과 유사한 환경에서 테스트를 진행할 수 있게 되는 장점이 있습니다. 그러나 저를 비롯한 팀원들이 docker를 거의 사용해보지 않아서, 데모데이가 얼마 남지 않은 상황에서 학습 비용을 고려해야 한다는 의견이 있었습니다.

최종 해결 방안 : Testcontainers를 사용하자

팀원들의 학습 비용도 줄이고(혹은 아예 없애고), 운영환경과 유사한 환경에서 테스트를 진행할 수 있는 방법을 찾기 위해 3~4일여간 구글링을 열심히 했습니다. 또, 다른 팀들의 코드와 블로그도 많이 찾아봤습니다. 그 결과, Testcontainers라는 새로운 기술을 찾아냈습니다.

공식문서와 StackOverFlow를 열심히 뒤지며 사용법을 알아냈습니다. 설정 파일에서 단 두 줄, 혹은 테스트에서 클래스 하나 정도만 추가하면 (docker가 실행되고 있다는 가정하에) 자동으로 컨테이너를 띄워주면서 테스트를 실행할 수 있었습니다. 해당 기술을 사용해서 팀원들의 학습 비용도 줄이고 더욱 실제 운영환경과 유사한 환경에서 테스트를 진행할 수 있게 되었습니다.
이제 그 혁신적인 라이브러리인 Testcontainers를 소개하겠습니다.

Testcontainers

Testcontainers의 공식 사이트에서는 다음과 같이 소개하고 있습니다.

Testcontainers is a library that provides easy and lightweight APIs for bootstrapping local development and test dependencies with real services wrapped in Docker containers. Using Testcontainers, you can write tests that depend on the same services you use in production without mocks or in-memory services.

즉, 도커 컨테이너로 래핑된 실제 서비스를 제공해서, 로컬 테스트 시에도 mocking이나 in-memory 서비스들을 사용하지 않고 운영환경에서 사용하는 실제 서비스에 종속되는 테스트를 작성할 수 있게 해주는 오픈 소스 라이브러리입니다.

Testcontainers의 장점

~~프로젝트의 아키텍쳐는 매우 간단해서~~, Testcontainers의 사용 효과를 극적으로 설명하기 위해 공식 사이트에서 소개하는 예시를 가져와봤습니다.

위의 도식에서 볼 수 있듯이, 현재 My Service는 데이터베이스, 다른 서비스, 이벤트/메세지 브로커, AWS S3 같은 다른 클라우드 서비스에 의존성을 가지고 있습니다. 여기서 다음과 같은 문제들이 발생합니다.

테스트를 실행하기 전에 인프라가 가동 중이고, 원하는 상태로 미리 구성되어 있는지 확인해야합니다.
데이터베이스, 이벤트/메세지 브로커 등 여러 사용자 또는 CI 파이프라인에 걸쳐 공유되는 리소스의 경우, 데이터와 구성의 변경 가능성으로 인해 테스트 시 멱등성을 보장할 수 없습니다.

⚠️ 멱등성이란?
연산을 여러 번 적용하더라도 결과가 바뀌지 않는 성질을 말합니다.

그래서 그동안 프로젝트에서도 아래와 같이 해당 리소스들을 mocking하는 방법으로 테스트를 작성했었습니다.

class FileUploaderTest {  
  
    @Mock  
    private FilePath filePath;  
      
    @Mock  
    private FileUrlMaker fileUrlMaker;  
      
    @InjectMocks  
    private FileUploader fileUploader;  
      
    @Test  
    void 파일의_URL을_반환한다() {  
        // given  
        UUID randomUUID = UUID.randomUUID();  
        String baseUrl = "https://example.com/files/";  
        String expectedFileUrl = baseUrl + randomUUID + ".jpg";  
        MultipartFile multipartFile = mock(MultipartFile.class);  
        given(multipartFile.getContentType()).willReturn(IMAGE.contentType());  
        given(fileUrlMaker.make(any())).willReturn(expectedFileUrl);  
          
        // when  
        String url = fileUploader.upload(multipartFile);  
          
        // then  
        assertThat(url).isEqualTo(expectedFileUrl);  
    }
}

프로젝트 내에서 생성된 파일이 저장소에 업로드 된 후 그 주소를 반환하는 기능에 대한 테스트입니다. 기존에는 서버에 저장을 하다가 AWS S3로 변경이 되었는데, 이 경우 모두 로컬에서 테스트할 적절한 방법이 없어서 위와 같이 관련 클래스들을 전부 mocking할 수 밖에 없었습니다.

그러나 위처럼 Testcontainers를 사용하면, 서비스가 의존하는 리소스들을 컨테이너로 래핑하여 제공해줍니다. 이렇게 되면 위에서 이야기했던 실제 리소스에 의존하여 테스트시 정확성이 보장되지 않는 문제들을 해결할 수 있고, 반복적인 테스트가 가능해집니다.

여기까지 읽다보면 한 가지 의문이 들 수도 있습니다.

그냥 Docker나 Docker Compose 쓰면 안 되나?

물론 Docker와 Testcontainers 모두 컨테이너를 사용하여 리소스를 래핑하는 것은 동일합니다. 그러나 Testcontainers를 사용하면 컨테이너의 설정과 사용이 혁신적으로 편리해집니다.

이를 설명하기 위해 위에서 언급한 장점들을 포함하여, Testcontainers를 사용하여 얻는 장점들을 아래에 정리해보겠습니다.

1. 격리된 인프라 제공

통합 테스트 시에 사용될 인프라 리소스들을 미리 준비하지 않아도 됩니다. Testcontainers를 사용하면 테스트를 실행하기 전에 자동으로 해당 리소스들을 제공합니다. 각 파이프라인이 격리된 서비스 집합으로 실행되므로 여러 빌드 파이프라인이 병렬로 실행되는 경우에도 테스트 데이터 오염이 발생하지 않습니다.

2. 로컬 및 CI 환경 모두에서 일관된 테스트

IDE에서 바로 통합 테스트를 실행할 수 있어서, 변경 사항을 push하고 CI 파이프라인이 완료될 때까지 기다릴 필요가 없습니다.

3. 대기 전략을 사용한 안정적인 테스트 설정

테스트를 실행하기 전에 컨테이너를 초기화해야합니다. Testcontainers를 사용하면 컨테이너와 그 안에 있는 어플리케이션이 완전히 초기화되었는지 확인하는 몇 가지 대기 전략을 제공합니다. 또, 모듈을 사용하여 해당 전략들을 직접 구현하거나 복합 전략을 생성할 수도 있습니다.

4. 고급 네트워킹 기능

Testcontainers를 사용하면 컨테이너의 포트를 사용 가능한 임의의 포트에 매핑하여 테스트가 해당 서비스에 안정적으로 연결되도록 해줍니다. 심지어 네트워크를 생성하고 여러 컨테이너를 함께 연결하여 각 컨테이너가 서로 통신하도록 할 수도 있습니다.

5. 자동 초기화

테스트 실행이 완료된 후, 생성된 모든 리소스(컨테이너, 볼륨, 네트워크 등)를 Ryuk Sidecar 컨테이너를 사용하여 자동으로 제거합니다. 필요한 컨테이너를 시작하는 동안 생성된 리소스에 일련의 라벨을 붙이고, Ryuk은 해당 라벨을 매칭하여 자동으로 리소스 정리를 수행해줍니다. 그래서 테스트가 비정상적으로 종료되더라도 안정적으로 작동합니다.

즉, Docker와 Docker Compose를 사용하여 직접 명령어를 사용하거나 서비스 종속성을 초기화하는 등의 행위를 하려면 Docker에 대한 내부 지식과 컨테이너에서 특정 기술을 실행하는 방법에 대한 지식이 필요합니다. 이러한 부분에 대한 지식이 없다면, 포트가 충돌하거나 테스트 시작 시에 컨테이너가 초기화되지 않는 문제, 또는 상호작용할 준비가 되지 않는 등의 문제가 발생할 수 있습니다.
Testcontainers를 사용하면 내부에서 이러한 설정을 전부 지원해주므로 개발자는 API를 통해 이러한 지식 없이도 컨테이너 기반의 테스트를 사용할 수 있게 됩니다.

Testcontainers가 지원하는 DB 및 인프라 리소스들 목록입니다. 웬만한 건 다 있네요!

Docker나 Docker Compose에 대한 학습 비용을 절감하면서도 컨테이너 기반 테스트를 사용할 수 있는 점이 저희 팀의 문제를 깔끔하게 해결하기 때문에 Testcontainers를 사용하기로 했습니다.
또, 프로젝트가 커져가면서 인프라 리소스가 추가될 가능성이 매우 높았기 때문에 해당 리소스에 대한 테스트를 위해서도 Testcontainers를 사용하기로 했습니다.

Testcontainers 사용법

MySQL 컨테이너를 띄우는 방법을 예시로 사용법을 설명하겠습니다. 다른 리소스(Kafka 등)에 대한 사용법은 참고 자료에 잇는 공식 문서에 자세하게 설명이 되어있습니다. MySQL 컨테이너를 띄우는 방법과 매우 유사하므로, 어렵지 않게 사용하실 수 있습니다.

우선, 의존성을 추가해줍니다.

testImplementation "org.testcontainers:testcontainers:1.19.1"  
testImplementation 'org.testcontainers:junit-jupiter:1.19.1'  
testImplementation 'org.testcontainers:mysql'

JUnit과 MySQL에 대한 모듈 의존성도 추가해줍니다. (이유는 to be continue…)

기본적인 사용 방법

기존에 존재하는 테스트에 대해서 MySQL 컨테이너를 띄워서 실행해보겠습니다. 우선, 기존의 테스트 코드입니다.

@ServiceTest  
class MenuGroupServiceTest {  
  
    @Autowired  
    private MenuGroupRepository menuGroupRepository;  
      
    @Autowired  
    private MenuGroupService menuGroupService;  
      
    @Test  
    void 메뉴_그룹을_등록한다() {  
        // ...
    }  
      
    @Test  
    void 메뉴_그룹들을_조회한다() {  
        // ...  
    }  
}

@SuppressWarnings("NonAsciiCharacters")  
@DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscores.class)  
@Target(ElementType.TYPE)  
@Retention(RetentionPolicy.RUNTIME)  
@SpringBootTest  
@Transactional  
public @interface ServiceTest {  
}

테스트를 실행하면, H2에서 해당 테스트를 진행하고 있음을 확인할 수 있습니다.

이제, MySQL 컨테이너를 띄우고 해당 컨테이너에서 테스트가 진행되도록 하겠습니다.
세 가지 방법이 존재하고, 세 방법 모두 “아주”.repeat(Integer.MAX_VALUE) 간단합니다.

첫 번째 방법 : 컨테이너에 대한 인스턴스 생성

테스트 클래스 내에서 `Testcontainers` 모듈이 제공하는 MySQLContainer 인스턴스를 생성합니다. 그 후, @BeforeEach, @AfterEach 등을 활용해서 해당 컨테이너에 대한 조작을 합니다.

@ServiceTest  
class MenuGroupServiceTest {  

    @Autowired  
    private MenuGroupRepository menuGroupRepository;  
      
    @Autowired  
    private MenuGroupService menuGroupService;  
  
    private MySQLContainer mySQLContainer = new MySQLContainer("mysql:8");  
    
    @BeforeEach  
    void setUp() {  
        mySQLContainer.start();  
    }  
      
    @AfterEach  
    void tearDown() {  
        mySQLContainer.stop();  
    }
      
    @Test  
    void 메뉴_그룹을_등록한다() {  
        // ...
    }  
      
    @Test  
    void 메뉴_그룹들을_조회한다() {  
        // ...  
    }  
}

원래 Testcontainers 모듈에는 Container라는 인터페이스와 구현체인 GenericContainer가 존재합니다. MySQL에 대한 의존성을 위에서 추가해줬기 때문에 (~~복선 ㄷㄷ~~) GenericContainer를 상속받은 MySQLContainer를 사용할 수 있게 되었고, 이를 통해 추가적인 설정없이 바로 MySQL 컨테이너를 띄울 수 있게 되었습니다.

이제 테스트를 실행해보면, MySQL 컨테이너가 띄워지는 것을 확인할 수 있습니다. (만약 Driver를 찾지 못하는 예외가 발생한다면 MySQL에 대한 의존성을 추가해주세요!)

implementation 'com.mysql:mysql-connector-j'

gif 파일입니다! 컨테이너가 올라가고 내려가는 시간이 오래 걸려서 편집을 했습니다.

글자가 너무 작아서, 아래에 설명을 적었습니다!

보시듯이, RYUK Sidecar 컨테이너가 먼저 띄워지고, 첫번째 테스트에 대한 컨테이너가 띄워집니다. (Testcontainers의 장점에서 설명했습니다!)
첫번째 테스트가 종료된 후, RYUK Sidecar 컨테이너는 그대로 있고 그 다음 테스트에 대한 컨테이너가 띄워지는 것을 볼 수 있습니다. (눈썰미가 좋으시다면, 위의 이미지의 스크롤 크기를 통해 첫번째 테스트 시에만 Ryuk 컨테이너가 실행됐음을 확인하실 수 있습니다. 저는 몰랐습니다.)

두 번째 방법 : JUnit5의 @ExtendWith 사용

JUnit5의 @ExtendWith을 통해서, 테스트 인스턴스의 생명주기를 Intercept하는 Extension을 사용하는 방법도 있습니다. 설명은 거창하지만, 어노테이션 두 개만 추가하면 됩니다.

@Testcontainers
@ServiceTest  
class MenuGroupServiceTest {  

    @Autowired  
    private MenuGroupRepository menuGroupRepository;  
      
    @Autowired  
    private MenuGroupService menuGroupService;  
  
    @Container
    private MySQLContainer mySQLContainer = new MySQLContainer("mysql:8");    
    
    @Test  
    void 메뉴_그룹을_등록한다() {  
        // ...
    }  
      
    @Test  
    void 메뉴_그룹들을_조회한다() {  
        // ...  
    }  
}

@Testcontainers와 @Container 모두 위에서 추가해준 Testcontainers JUnit 모듈에서 제공하는 기능입니다. (~~복선222 ㄷㄷ~~)

어떻게 어노테이션 두 개만 달면 자동으로 컨테이너가 올라갈까요?
이제, @Testcontainers에 대해 살펴보겠습니다.

@Target(ElementType.TYPE)  
@Retention(RetentionPolicy.RUNTIME)  
@ExtendWith(TestcontainersExtension.class)  
@Inherited  
public @interface Testcontainers {  
    /**  
    * Whether tests should be disabled (rather than failing) when Docker is not available. Defaults to  
    * {@code false}.  
    * @return if the tests should be disabled when Docker is not available  
    */  
    boolean disabledWithoutDocker() default false;  
      
    /**  
    * Whether containers should start in parallel. Defaults to {@code false}.  
    * @return if the containers should start in parallel  
    */  
    boolean parallel() default false;  
}

@ExtendWith(TestcontainersExtension.class)가 있는 것을 보니, TestcontainersExtension이라는 Extension이 테스트 인스턴스의 Life-Cycle을 intercept하는 것을 짐작할 수 있습니다.

public class TestcontainersExtension  
implements BeforeEachCallback, BeforeAllCallback, AfterEachCallback, AfterAllCallback, ExecutionCondition {  

	// ...
	
    @Override  
    public void beforeAll(ExtensionContext context) {  
      
        // ...  
        
        List<StoreAdapter> sharedContainersStoreAdapters = findSharedContainers(testClass);  
          
        // ...
    }  
      
    @Override  
    public void afterAll(ExtensionContext context) {  
        // ...
    }  
      
    @Override  
    public void beforeEach(final ExtensionContext context) {  
    
        // ... 
      
        List<StoreAdapter> restartContainers = collectParentTestInstances(context)  
            .parallelStream()  
            .flatMap(this::findRestartContainers)  
            .collect(Collectors.toList());  
  
        // ...
    
    }  
      
    @Override  
    public void afterEach(ExtensionContext context) {  
        // ...
    }  
      
    private List<StoreAdapter> findSharedContainers(Class<?> testClass) {  
        return ReflectionSupport  
            .findFields(testClass, isSharedContainer(), HierarchyTraversalMode.TOP_DOWN)  
            .stream()  
            .map(f -> getContainerInstance(null, f))  
            .collect(Collectors.toList());  
    }  
      
    private Predicate<Field> isSharedContainer() {  
        return isContainer().and(ModifierSupport::isStatic);  
    }  
      
    private Stream<StoreAdapter> findRestartContainers(Object testInstance) {  
        return ReflectionSupport  
            .findFields(testInstance.getClass(), isRestartContainer(), HierarchyTraversalMode.TOP_DOWN)  
            .stream()  
            .map(f -> getContainerInstance(testInstance, f));  
    }  
      
    private Predicate<Field> isRestartContainer() {  
        return isContainer().and(ModifierSupport::isNotStatic);  
    }  
      
    private static Predicate<Field> isContainer() {  
        return field -> {  
            boolean isAnnotatedWithContainer = AnnotationSupport.isAnnotated(field, Container.class);  
        
            // ...
        
      };  
    }  
}

예상대로, beforeAll과 beforeEach를 오버라이딩하면서 @Container가 붙은 정적/클래스 인스턴스로 컨테이너를 띄우고 있습니다. 그래서 @BeforeEach, @AfterEach가 붙은 setUp(), tearDown() 메서드 없이도 컨테이너가 자동으로 띄워지고, 내려집니다.

두 가지 방법의 공통된 장점

우선 장점으로는, 두 방법 모두 인스턴스를 직접 생성하여 사용하므로 조금 더 정교한 customizing이 가능합니다.

private MySQLContainer mySQLContainer = new MySQLContainer("mysql:8");  
  
{  
	  mySQLContainer.withUsername("리오")  
        .withPassword("짱짱")  
        .withDatabaseName("멋쟁이")  
        .withConfigurationOverride("귀요미");  
}

MySQLContainer의 Super Class인 JdbcDatabaseContainer와 GenericContainer는 훨씬 더 많은 메서드를 가지고 있습니다. 이러한 메서드들을 사용해서 컨테이너를 customizing하거나 원하는 정보를 얻을 수 있습니다.

두 가지 방법의 공통된 단점 및 해결방법

두 가지 방법 모두 테스트 메서드마다 컨테이너를 새로 띄웁니다. 각 컨테이너가 올라가고 내려가는 시간이 꽤 길기 때문에, 테스트의 수가 많아진다면 전체 테스트의 수행 시간이 굉장히 오래 걸리게 됩니다.

이를 해결하기 위해서는 하나의 컨테이너 인스턴스만 사용하도록 하면 됩니다.

class WithContainerTest {

	  protected static MySQLContainer mySQLContainer = new MySQLContainer("mysql:8");

    static {
        mySQLContainer.start();
    }
}

@Testcontainers
class WithContainerTest {

	  @Container  
	  protected static MySQLContainer mySQLContainer = new MySQLContainer("mysql:8");
}

@SpringBootTest
class SomeTest extends WithContainerTest {
	// ...
}

이렇게 클래스를 하나 생성한 후 MySQLContainer의 인스턴스를 static 메모리에 올리면(싱글턴 패턴이죠!), 이후 해당 클래스를 상속하는 테스트들은 하나의 MySQLContainer 인스턴스만 사용할 수 있게 되…지 않습니다!!! (주의!!!)

정확히 말하면, 두 번째 방법인 @Testcontainers를 사용하는 경우에 해당 방법이 작동하지 않습니다. JUnit의 Life-Cycle 관리는 클래스 단위로 이루어지기 때문입니다. 그래서, 다른 테스트 클래스가 실행되면 또 다른 Life-Cycle이 돌기 때문에 해당 static 컨테이너를 공유하지 못하고 새로 띄우게 됩니다.
다만, 한 클래스 내의 메서드들은 하나의 컨테이너를 공유할 수 있습니다. 위의 TextcontainersExtension의 코드에서 beforeAll() 메서드 내부에서도 findSharedContainer()로 static 인스턴스를 찾는 로직이 보이네요.
공식 문서에서도 ‘common misconfiguration’이라고 설명하며, Extension을 이용한 방법으로는 클래스 간 컨테이너 공유가 불가능하다고 합니다.

그래서, 전체 테스트에서 하나의 컨테이너만 사용하고 싶다면 처음 소개드린 대로 싱글턴 패턴을 사용해야 합니다! (~~그런데 과연 이 방법만 있을까요? 후훗…~~)

보시듯이 하나의 컨테이너만 띄워지고 이 컨테이너에서 모든 테스트가 실행되는 것을 확인할 수 있습니다.

추가적으로, 하나의 컨테이너를 사용하게 되면서 테스트 격리를 해야하는 상황이 있을 수 있습니다. 기존에 했던 방식대로 테이블들을 truncate 해주시면 됩니다. 저는 개인적으로 이 블로그에서 추천하는 방식이 가장 좋았습니다.

세 번째 방법 : Datasource URL 설정

프로젝트의 상황을 조금 더 고민해본 결과, 위의 두 방법보다도 훨씬 간단한 방법을 직접 찾아낼 수 있었습니다. 간단하기도 하고, Testcontainers의 라이브러리 사용을 위해 기존 테스트 코드가 오염되는 것이 싫으신 분들 (~~혹은 코드 몇 줄 더 치기 귀찮은 분들~~)을 위한 방법일 수 있습니다.

⚠️ 이 방법은 사용하시는 상황에 따라 적절하지 않은 방법일 수 있습니다. 이후에 설명하는 상황과 부합하는 경우에만 사용하세요.

현재 저희 프로젝트는 테스트 시 MySQL 컨테이너 하나만 띄우면 되는 상황입니다. 그래서 프로파일 설정 파일의 Datasource만 띄워지는 컨테이너로 설정하면 되지 않을까? 라는 생각을 했습니다.
Spring에서는 (스코프를 재설정하지 않는 이상) DataSource를 빈으로 등록하고, 여러 곳에서 참조할 때 재사용하는 것을 알고 있었기 때문에, 가능할 것으로 생각했습니다.

찾아보니 Datasource를 다음과 같이 Testcontainers가 띄워주는 MySQL 컨테이너로 설정하는 방법이 있었습니다.

spring:  
	datasource:  
		driver-class-name: org.testcontainers.jdbc.ContainerDatabaseDriver  
		url: jdbc:tc:mysql:8://test  
		username: root  
		password: test

(데이터베이스 이름과 username, password는 원하는대로 설정해도 됩니다!)

결과는…!

(성공적이었습니다! 315(+ɑ)에 달하는 커버리지 93%(Line 기준)의 테스트도 1분 안에 끝납니다!)

물론 위의 두 방법처럼 테스트 격리를 위해 truncate가 필요하긴 하지만, 코드로 인스턴스를 생성할 필요없이 간단하게 Testcontainers를 사용할 수 있었습니다.

올바른 방법인지 확인해보려고 공식문서를 열심히 뒤져서 JDBC 모듈 관련 문서를 찾아냈습니다. Testcontainers에서 지원하는 기능이 맞았고, 적절한 driver만 가지고 있다면 다른 벤더에도 적용할 수 있었습니다. (설명드린 첫번쨰 방법과 세번째 방법을 동시에 해야한다고 알려주는 다른 블로그 글들이 많으니 주의해주세요!)

마치며

Testcontainers를 사용하여 로컬에서도 실제 운영 환경과 유사한 환경에서 테스트를 수행하는 방법에 대해서 알아봤습니다. 개인적으로는 팀의 문제를 단계별로 해결해나가며 최선의 방법을 찾아냈고, 잘못 알려져있는 사용법들을 올바른 방법으로 소개해드릴 수 있었던 뜻깊은 경험이었습니다. 긴 글 읽어주셔서 감사합니다!

참고 자료

useLayoutEffect를 활용한 산발적 마커 렌더링 최적화

Tue, 21 Nov 2023 12:00:00 GMT

마커 렌더링 최적화

서비스 소개

마커 렌더링 최적화 설명에 앞서 잠시 저희 팀에서 진행했던 서비스에 대해 소개드리겠습니다.

저희 서비스의 출발점은 전기차 충전의 불편함이었습니다. 최근 들어 보조금과 저렴한 유지비용 등의 이유로 전기차의 수요는 점점 증가하고 있습니다. 하지만, 인프라는 그에 맞게 충분히 성장하지 못했습니다. 특히 충전에 관련된 불편함이 많이 대두되고 있습니다. 저희 서비스는 충전소 이용량 통계 정보를 제공함으로써 전기차 차주분들이 자발적으로 충전소를 분산 이용하는 것을 목표로 삼았습니다. 서비스의 주요 기능은 전국 6만개의 충전소와 그 내부 24만개의 충전기 정보 실시간 제공, 각 충전소 사용량 통계 정보 제공, 충전소 정보 불일치 신고 등이 있습니다.

저희는 이러한 기능을 지도를 기반으로 전달하고자 했습니다. 각 충전소의 위치를 지도상의 마커로 표현하고, 마커를 클릭할 시 해당하는 충전소의 세부 정보 및 사용량 통계를 볼 수 있도록 구성했습니다. 따라서 저희 서비스를 이용하는 사용자들이 가장 처음으로 접하는 중요 정보는 마커라고 할 수 있습니다. 프로젝트 초반에는 이렇게 중요한 마커가 산발적으로 렌더링되는 문제가 있었습니다. 저는 이를 개선하고자 했습니다.

이제 제가 어떻게 산발적 마커 렌더링을 개선했는지 살펴보도록 하겠습니다.

1. 개요

1-1. 마커 렌더링 방식 선택

제가 지도에 표현하고자 했던 마커는 다음과 같은 모양을 가지고 있는 마커였습니다.

디자인 유연성이나 기능 추가와 같은 확장성을 고려했을 때 위 마커를 구글 기본 마커로 구현하기보단 리액트 컴포넌트로 관리하는 것이 더 유리하다고 판단해 저는 마커를 리액트 컴포넌트로 관리해 보고자 했습니다.

하지만 지도는 리액트에서 제어하는 영역이 아니었기 때문에 리액트 컴포넌트로써 마커를 제어하기 위해 조금 특별한 방식이 필요했습니다.

DOM API인 createElement를 통해 DOM 요소를 생성한다.
생성된 DOM 요소를 마커 생성자 함수에 전달해 지도에 해당 DOM 요소를 마커로써 사용한다.
리액트 API인 createRoot를 이용해 전달한 DOM 요소를 리액트 root로 만든다.
root.render 호출에 원하는 마커 컴포넌트를 전달해 원하는 마커를 렌더링한다.

위와 같은 방식으로 저는 마커를 리액트 컴포넌트로써 제어할 수 있게 되었습니다.

1-2. 여러개의 마커를 제어하는 구조 설계

지도는 리액트를 기반으로 동작하지 않습니다. 그렇기 때문에 리액트의 기존 코드에 지도가 추가되면 자칫 코드 구조가 복잡하게 얽힐 가능성이 있습니다. 저는 최대한 기존에 리액트 코드를 작성하던 방식에서 크게 벗어나지 않게 지도를 제어하고자 했습니다.

리스트 컴포넌트를 만든다고 했을 때 대부분 다음과 같은 코드 구조를 떠올릴 것입니다.

function List() {
  return (
    <>
      {
        list.map((item) => <Item key={item.id} item={item} />)
      }
    </ㅣ>
  )
}

지도에 찍히는 마커를 생각해 보면 이 또한 지도에 어느 좌표에 위치한다는 것만 빼면 위 컴포넌트와 크게 다르지 않은 동작을 한다는 것을 알 수 있습니다. 그래서 제가 선택한 마커 렌더링 방식은 다음과 같습니다.

function MarkerContainer() {
  // station는 충전소 정보를 배열 형태로 저장하고 있습니다.
  const { stations } = useStations();

  return (
    <>
      {stations.map((station) => (
        <Marker key={station.id} station={station} />
      ))}
    </>
  );
}

function Marker({ station }) {
  const { renderMarker } = useMarker();

  useEffect(() => {
    const unmountMarker = renderMarker(station);

    return unmountMarker;
  }, []);

  return <></>;
}

간단하게 설명해 드리자면 MarkerContainer에서 서버에서 받아온 충전소 정보를 통해 Marker를 호출하고, Marker에서 구글 지도 API를 통해 마커를 렌더링하는 구조입니다.

마커 컴포넌트에서 호출한 renderMarker에서는 구글 지도 API의 호출이 일어나 마커를 생성하고, 전역적으로 관리되고 있는 마커 인스턴스 배열에 생성한 마커를 추가하는 기능을 수행합니다. 또한 지도 내 불필요하게 남아있는 마커를 삭제하기 위해 Marker가 unmount 될 때 호출되는 useEffect내 클린업 함수에 지도에서 마커를 제거하는 함수를 등록했습니다.

1-3. 산발적 렌더링 발생

앞서 말씀드린 방식들을 활용해 서비스를 구현하던 와중 충전소가 몰려있는 지역에서 마커가 렌더링 될 때 산발적으로 마커가 렌더링 되는 모습을 확인할 수 있었습니다.

퍼포먼스 탭을 통해 CPU 성능을 저하시킨 후 테스트해 본 결과 디바이스의 성능이 낮을수록 마커의 산발적 렌더링이 더욱 심해지는 것을 확인할 수 있었습니다. 앞서 말씀드렸듯 마커는 저희 서비스에서 가장 처음으로 접하는 중요 정보이기 때문에 이 부분은 꼭 개선이 필요한 부분이라고 판단되었습니다.

2. 문제 원인 분석

2-1. 잦은 상태 변경

다수의 컴포넌트에서 마커 인스턴스에 접근해야 하는 상황이 생겼기 때문에 저희는 마커 인스턴스 배열을 전역 상태로써 관리하는 방식을 선택했습니다. 이 때문에 마커를 렌더링할 때 전역 상태에 생성한 마커를 추가하는 동작이 수반되어야 했습니다. 저는 이 부분이 산발적 마커 렌더링이 발생한 지점이라고 생각했습니다.

앞서 이야기했듯 마커 생성은 전역 상태의 변경을 야기합니다. 이 때문에 마커를 하나 렌더링할 때마다 전역 상태의 변경이 한번 일어나게 됩니다. 잦은 상태의 변경은 잦은 리렌더링을 발생시킬 것이고, 이 지점에서 마커의 산발적 렌더링이 발생했다고 판단하게 되었습니다.

이를 고쳐보고자 저는 기존의 구조를 과감히 버리고 다음과 같은 렌더링 방식을 선택하게 되었습니다.

function MarkerContainer() {
  // station는 충전소 정보를 배열 형태로 저장하고 있습니다.
  const { stations } = useStations();

  // 마커 인스턴스를 다루는 커스텀 훅
  const { createMarkerInstances, getRemainedMarkers, removeUnmountMarkers, ... } = useMarker();

  // ... 마커 재생성 방지 및 영역 밖 마커 제거를 고려한 마커 렌더링 과정 구현 코드

  return <></>;
}

기존에는 MarkerContainer에서 Marker를 호출하고, Marker에서 마커 렌더링을 수행하는 방식이었습니다. 변경된 구조에서는 상태 변경을 최소화하기 위해 구글 지도 API 호출을 관리하는 커스텀 훅을 통해 MarkerContainer에서 모든 마커의 렌더링을 일괄적으로 처리하고, 모든 처리가 끝난 마커 인스턴스를 전역 상태에 한 번만 반영하는 방식을 채택했습니다.

위 구조로 리팩터링을 마치고 나니 예상했던 대로 마커의 산발적인 렌더링이 사라지게 되었습니다.

2-2. useEffect의 동작 원리

기존에는 마커를 한 가지 종류만 렌더링하면 됐었지만 클러스터링 기능이 추가됨에 따라 다음과 같이 여러 종류의 마커를 렌더링해야 했습니다.

마커 렌더링 최적화를 위해 만든 훅은 한 종류의 마커에 초점이 맞춰져 있어 마커의 종류만큼 훅이 필요하게 되었습니다. 또한 훅의 복잡도가 굉장히 높아 추후 유지보수를 위해선 개선이 필요한 상황이었습니다.

다른 기능의 개선이 대부분 완료된 시점에 가용할 수 있는 시간이 늘어남에 따라 유지보수성 향상을 위해 이전의 구조를 유지하되 산발적 렌더링이 발생하지 않게 하는 방법이 있을까 고민하는 시간을 가졌습니다.

일단 지난 마커 렌더링 최적화 이전 시점의 커밋으로 브랜치를 돌린 후 기존에 문제라고 생각했던 상태 변경을 일으키지 않으면서 전역 상태로 관리되는 마커 인스턴스 배열을 변화시키는 방법을 적용해 봤습니다. (이 방법은 글 가장 하단부에 소개하도록 하겠습니다.)

처음 생각과는 달리 전역 상태의 변경을 발생시키지 않았음에도 마커의 렌더링이 산발적으로 일어나는 모습을 확인할 수 있었습니다. 훅 분리를 통해 해결한 문제가 애초에 근본적인 문제의 해결을 했다고 볼 수 없는 상황이었습니다.

문제의 정확한 원인을 파악하고자 개발자 도구의 Performance 탭에서 함수의 호출 단위로 분석을 시도해 보았습니다.

위 이미지에서 performance 탭의 프레임 이미지 하단부를 보면 함수의 호출이 노란색 선으로 표시된 모습을 확인해 볼 수 있습니다. 이 부분이 마커의 렌더링에 관여하는 함수의 호출이 아닐까 싶어 해당 부분에 어떤 함수들의 호출이 있었는지 확인해 보았습니다.

자세히 보니 해당 부분에서 CarFfeineMarker의 렌더링이 이루어지는 것을 확인할 수 있었습니다. 또한 가장 상단을 보면 마커 렌더링 이전에 performWorkUntilDeadline이라는 메서드의 호출이 있는 것을 확인해 볼 수 있습니다. 저는 이 메서드가 마커의 산발적 렌더링의 원인일 것이라고 생각해 어떤 역할을 하는지 자세히 알아보았습니다.

자세히 알아보니 기존 코드의 문제점은 잦은 상태 변경이 아닌 useEffect 내부에서 호출되던 root.render에 있었습니다.

useEffect의 셋업함수는 리액트의 렌더, 커밋 단계를 거친 이후 브라우저에서의 렌더링이 완료된 시점에 처리됩니다.

등록된 셋업 함수들은 위와 같이 모두 한꺼번에 처리될 것 같지만 셋업 함수 내에서 리액트의 렌더링에 직접적으로 영향을 미치는 메서드 호출이 발생하게 된다면 위와 같이 동작하지 않습니다.

렌더링에 영향을 미치는 메서드 호출 시 리액트의 렌더, 커밋 단계를 거쳐 브라우저의 렌더링이 진행됩니다. 이 과정에서 리액트는 처리 시간이 오래 걸려 사용자에게 60프레임의 웹 페이지를 보여줄 수 없게 될 것을 고려해 메서드 처리에 5ms의 시간제한을 걸어주게 됩니다.

이것이 산발적인 마커 렌더링을 일으키는 원인이었습니다.

마커를 렌더링하기 위해 root.render를 호출하게 되면 리액트의 렌더링에 직접적으로 영향을 주기 때문에 해당 메서드의 처리 시간에 5ms의 시간제한을 걸어주게 되고, 그로 인해 한 번에 마커를 렌더링하지 못하고 몇 개씩 나누어 렌더링을 진행했기 때문에 산발적 렌더링이 발생했던 것이었습니다.

처음 해결했던 방식은 MarkerContainer에서 마커 렌더링을 일괄 처리하는 것을 위해 useEffect 내부에 있던 마커 렌더링 처리 로직을 외부로 꺼내서 수행했기 때문에 산발적 렌더링을 제어할 수 있던 것이었습니다. 애초에 잦은 상태 변경이 원인이 아니었던 것이었습니다.

3. 문제 해결

결국 원점으로 돌아와서 문제를 해결하기 위해선 브라우저 렌더링 이후 시점에 트리거 되는 셋업 함수들을 브라우저 렌더링 이전 시점에 모두 실행해야 했습니다.

리액트 공식 문서를 보면 이 같은 경우에 사용하는 훅이 존재합니다. 바로 useLayoutEffect입니다.

useLayoutEffect is a version of useEffect that fires before the browser repaints the screen.

공식 문서상에서는 useLayoutEffect를 브라우저가 화면을 그리기 전에 실행되는 useEffect라고 소개하고 있습니다.

The code inside useLayoutEffect and all state updates scheduled from it block the browser from repainting the screen. When used excessively, this makes your app slow. When possible, prefer useEffect.

공식 문서 하단부 주의 사항을 보면 useLayoutEffect는 모든 상태 업데이트가 완료될 때까지 브라우저의 렌더링을 막아 성능 저하의 여지가 있다는 문구가 적혀 있습니다.

저는 브라우저의 렌더링 이전 시점에 모든 마커 렌더링을 마치고 브라우저가 마커를 그리도록 하는 방법을 찾고 있었으므로 위 주의 사항이 제겐 꼭 필요한 기대 동작이었습니다. 어차피 화면에 렌더링 될 마커의 개수는 무한정 늘어나지 않고, 지도의 너무 넓은 영역을 보게 되면 클러스터링 마커가 기존 마커 대신 렌더링 되므로 마커의 개수가 너무 많아져 브라우저의 렌더링을 지연시킬 문제는 발생하지 않을 것이라 판단되었습니다. 그래서 저는 최종적으로 useLayoutEffect를 사용하기로 결정하게 되었습니다.

기존의 구조에서 useEffect가 사용되었던 부분을 useLayoutEffect로 수정하고, 훅의 내부 동작에서 상태 변경 또한 트리거 하지 않도록 수정해 보니 다음과 같이 산발적 렌더링이 개선된 모습을 확인해 볼 수 있었습니다.

4. 정리

산발적인 마커 렌더링 발생
잦은 상태 변경이 원인이라 판단, 상태를 한 번만 변경하는 구조로 수정
구조 수정에 사용한 훅의 복잡도가 너무 높음 + 다른 마커를 렌더링해야 하는 요구사항 발생
유지보수에 유리한 이전 구조로 돌아가고자 코드를 보다 보니 문제의 원인이 useEffect 동작에 있음을 인지
산발적 렌더링 개선을 위해 useLayoutEffect 도입

5. useSyncExternalStore를 활용한 전역 상태 관리 유틸

앞서 글 가장 하단부에서 소개하기로 했던 전역 상태의 변경을 리렌더링 없이 하는 방법에 대해 짧게 말씀드리며 글을 마치도록 하겠습니다.

일단 간단히 말씀드리자면 상태로써의 변경이 아닌 일반 자바스크립트 객체로써의 변경으로 전역 상태를 변경하는 방법을 사용했기 때문에 리렌더링이 일어나지 않으면서도 전역 상태의 변경을 수행할 수 있었습니다. 이를 이해하기 위해선 useSyncExternalStore에 대해 알아야 합니다.

useSyncExternalStore는 리액트 외부 환경과 리액트를 연결해 주는 훅입니다. 이를 통해 모듈 분리된 일반 자바스크립트 객체를 리액트의 상태처럼 다룰 수 있습니다. 저희 팀은 이를 이용한 전역 상태 관리 유틸을 만들어서 사용해 왔습니다. 해당 유틸의 동작 방식은 다음 이미지와 같습니다.

useSyncExternalStore의 인터페이스에 맞게 자바스크립트 객체에 접근하게 된다면 리액트의 상태로써 자바스크립트 객체를 사용할 수 있게 됩니다. 이러한 동작 과정에서 이미지에서 보시다시피 옵저버 패턴과 유사하게 전역 상태로 사용될 수 있게 됩니다.

useSyncExternalStore훅을 통해 수정하는 것이 아닌 직접 수정을 가하게 된다면 리렌더링 없이도 전역 상태의 최신 값을 변경할 수 있게 됩니다. 앞서 마커 인스턴스 배열을 리렌더링 없이 수정할 때도 이와 같은 방식을 사용했습니다.

※ 하지만 이는 리액트의 불변성을 해치는 행위이므로 정말 특수한 경우가 아니라면 지양하는 것이 좋습니다.

웹 어플리케이션의 역사

Tue, 21 Nov 2023 12:00:00 GMT

들어가면서

백엔드 개발자라면 웹 어플리케이션이라는 개념을 자주 접하게 됩니다. 그렇지만 웹 어플리케이션이 왜 등장했는지, 어떻게 지금의 형태에 이르렀는지에 대해 답하기는 쉬운 일이 아닐 것입니다.

좋은 엔지니어는 기술 그 자체에 매몰되는 것이 아니라 기술을 문제 해결을 위한 하나의 도구로써 활용합니다. 우리가 사용하는 도구가 ‘왜’ 등장했는지는 알아야 할 필요가 있습니다.

따라서 이번 아티클에서는 Spring을 사용하는 백엔드 개발자의 관점에서 웹 어플리케이션의 발전 과정을 살펴보려고 합니다. WWW의 등장부터 시간순으로 설명할 예정이니, 참고해주시면 감사하겠습니다.

WWW(World-Wide-Web)

웹 어플리케이션을 이해하기 위해서는 웹이란 도대체 무엇인지, 왜 등장했는지를 이해할 필요가 있습니다. WWW은 도대체 어떤 이유에서 등장했을까요?

1989년, 팀 버너스 리라는 사람이 CERN(유럽 입자 물리 연구소)이라는 기관에서 근무하고 있었습니다.

그런데 그는 근무를 하면서 한 가지 고민에 빠지게 되었습니다. 당시 CERN에서는 핵 소립자 실험의 성과를 전 세계의 연구자들과 공유하고자 하는 니즈가 있었는데, 쉽게 정보를 공유할 방법이 없었기 때문입니다.

사실 당대에 이메일이나 파일 전송과 같은 기술은 이미 존재했습니다. 그런데 수많은 연구자를 상대로 일일이 메일을 보내야 한다면 얼마나 번거로울까요? 따라서 팀 버너스 리는 보다 효율적인 정보 관리 방법을 고민하게 됩니다.

1989년, 팀 버너스 리는 ‘정보 관리(Information Management)’ 라는 이름의 제안서를 CERN의 경영진에게 제출합니다. 해당 제안서에서는 하이퍼텍스트(HyperText) 등의 개념을 소개하면서 ‘정보 관리 네트워크’의 필요성을 주장했습니다. 그리고 이 제안서가 바로 WWW의 개념적인 시초입니다.

하이퍼텍스트(HyperText)란 웹 페이지를 다른 웹 페이지로 연결하는 링크를 말합니다. 이런 하이퍼텍스트의 등장으로 참조하고 있는 다른 페이지에 대한 열람이 쉬워졌고, 정보의 전달 효율은 크게 향상되었습니다.

팀 버너스 리는 개념적인 모델의 WWW를 제안했을 뿐만 아니라, 실제로 구현까지 직접 참여했습니다. 그는 구현 과정에서 웹의 핵심 기술들을 많이 고안했는데, 대표적인 기술이 바로 HTML과 HTTP입니다. 그리고 최초의 웹 서버라고 불리는 CERN Httpd도 이 시점에 등장했습니다.

CGI

그런데 WWW를 사용하고자 하는 수요가 급속도로 늘어남에 따라 이슈가 하나 생기게 됩니다. 바로 동적 페이지에 대한 요구 또한 증대되었다는 것입니다.

하지만 초기 웹 서버 모델은 URL에 맞춰 페이지를 반환하기만 할 뿐, 동적인 페이지를 생성할 수 있는 능력은 없었습니다. 이런 동적 페이지를 생성하기 위해서는 외부 프로그램의 도움이 필요했습니다.

따라서 HTTP 요청이 들어오면 그에 걸맞은 적절한 프로그램을 수행하자는 아이디어가 부상하게 되었고, CGI라는 표준 인터페이스가 등장하게 됩니다.

CGI란, Common Gateway Interface의 약자로 서버와 애플리케이션 간에 데이터를 주고받는 방식을 의미합니다.

웹 서버는 동적 페이지를 원하는 클라이언트 요청이 들어오면 CGI 인터페이스를 통해 외부 프로그램을 실행시키면서 적절한 HTTP 응답을 반환할 수 있었습니다.

예를 들어, 사용자가 장바구니 조회 요청을 보내는 경우에는 다음과 같이 동적 페이지를 구성했습니다.

장바구니 조회 요청이 발생하면 웹 서버에 도달합니다.
웹 서버는 CGI 인터페이스를 사용해 외부 프로그램에 요청 처리를 위임합니다.
CGI 프로그램은 사용자의 장바구니 정보를 반환합니다.

이처럼 CGI의 등장 덕분에 사용자들은 정적 페이지만 사용하는 것이 아닌 동적 페이지도 접근할 수 있게 되었습니다.

하지만 CGI 방식에도 몇 가지 문제점들이 존재했습니다. 우선 요청마다 프로그램을 실행시켜야 하니 서버 리소스가 많이 소모되었습니다. 또한 HTTP 요청마다 스레드가 아닌 프로세스를 할당하는 구조였기 때문에 서버의 부하가 상당했습니다.

심지어 CGI 프로그램은 C, C++, Perl 등의 언어로 작성되는 경우가 많았기 때문에, 어플리케이션 확장에도 어려움을 겪었습니다.

이에 Java 진영에서는 이런 문제점들을 해결할 수 있는 Servlet이라는 모델을 제시했습니다.

Servlet

Servlet은 Java 코드를 사용해서 웹페이지를 동적으로 생성하는 기술을 의미합니다. ‘어떻게 Java 코드를 통해 동적 페이지를 생성하지?’ 라는 의문이 드실 수 있는데, 간단하게 HTTP 요청이 하나 들어오면 요청에 대응하는 클래스의 메소드를 호출하는 방식이라고 이해하셔도 됩니다.

이런 Servlet 방식은 CGI 방식과 대비해 상당히 경제적인데, 프로세스가 아닌 스레드 기반으로 동작하기 때문입니다. CGI 방식의 경우 요청마다 프로세스를 할당하지만, Servlet 방식은 스레드를 할당합니다.

조금 더 구체적으로 이야기하면, Java Application을 미리 띄워두기 때문에 매번 프로세스를 할당할 필요가 없는 것입니다. HTTP 요청이 들어오면 Java Application에게 ‘처리해줘’ 라고 의뢰를 하게 되고 Java Application은 스레드를 생성해서 요청 처리에 적합한 Servlet을 실행합니다.

또한 Servlet은 Java 진영의 기술이기 때문에 순수 Java 코드로 작성됩니다. 따라서 JVM 생태계에 친화적이고, Java의 특징 중 하나인 ‘플랫폼 독립성’ 가장 잘 누릴 수 있게 됩니다. Servlet을 한 번만 구현해두면 어느 플랫폼에서도 쉽게 재사용할 수 있습니다. 이처럼 Servlet은 앞서 설명해 드렸던 CGI의 문제점들을 극복하는 모델입니다.

Servlet을 사용하는 경우의 HTTP 요청 처리 방식은 CGI 방식과 크게 다르진 않습니다. 도식화하면 아래와 같습니다.

HTTP 요청이 발생하면 웹 서버에 도달합니다.
웹 서버는 Servlet Container에게 HTTP 요청을 토스합니다.
Servlet Container는 적절한 Servlet(Java 프로그램)을 선택하고 실행시킵니다.
Servlet은 요청에 걸맞은 동적 페이지를 반환합니다.

Servlet Container란 Servlet을 관리해주면서 동적 웹페이지를 제공하기 위한 기타 작업을 수행해주는 역할을 합니다. Servlet은 동적 페이지를 만들어내기 위한 프로그램에 불과하므로 이들을 초기화해주고 관리해주는 누군가가 필요하기 때문입니다.

그렇지만 서블릿 방식의 웹 어플리케이션도 문제점은 존재했습니다. 바로 자바 코드에서 HTML을 다루다보니 비즈니스 로직과 뷰의 영역 자체가 모호했다는 것입니다.

다음 코드를 보면 ‘뷰의 영역이 모호하다’ 라는 말이 이해가 될 것입니다. 아래 Servlet 코드에서는 로그인 처리를 위한 코드와 렌더링을 위한 코드가 공존합니다.

public class MyServlet extends HttpServlet {
	
	@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response) {
		String account = request.getHeader("account");
		String password = request.getHeader("password");
		
		// 비즈니스 로직
		validateCredential(account, password);

		// 뷰를 위한 로직
		out.write("<html>"); 
		out.write("<head> </head>");
		out.write("<body> Hello world! </body>");
		out.write("</html>");
	}

이처럼 뷰의 변경 지점과 비즈니스 로직의 수정 지점이 같아지다 보니, 유지 보수하는 데 어려움을 겪기 일쑤였습니다. 프로그래머는 Servlet 코드를 변경하고 싶어도 디자이너가 HTML 작업을 하고 있다면 기다려야 했습니다.

따라서 Java 코드와 HTML 코드의 분리를 더 명확히 하자는 요구가 생겨났고, JSP가 등장하게 됩니다.

JSP

JSP는 Java Server Page의 약자로(현재는 Jakarta Server Page라고도 불립니다) HTML 코드에 Java 코드를 넣어 동적 웹페이지를 생성하는 기술을 의미합니다.

<HTML>
<HEAD><TITLE>The Welcome User JSP</TITLE></HEAD>
<BODY>
		<% String user=request.getParameter("user"); %>
		<H3>Welcome <%= (user==null) ? "" : user %>!</H3>
		<P><B> Today is <%= new java.util.Date() %>. Have a nice day! :-)</B></P>
		<B>Enter name:</B>
		<FORM METHOD=get>
				<INPUT TYPE="text" NAME="user" SIZE=15>
				<INPUT TYPE="submit" VALUE="Submit name">
		</FORM>
</BODY>
</HTML>

위 코드는 간단한 JSP 파일 예시입니다. <% %> 블록 안에 Java 코드가 포함된 것을 확인하실 수 있습니다. <% %>와 같은 식별자들을 JSP 태그라고 하는데, JSP에서는 JSP 태그를 활용해 Java 코드를 HTML에 삽입할 수 있습니다.

JSP를 사용하는 경우 프로그래머는 JSP 태그로 감싸진 부분만 다루면 되고, 디자이너는 JSP 태그 이외의 HTML만 다루면 되므로 순수 Servlet을 사용하는 방법과 대비해 유지 보수성이 향상됩니다.

사실 위처럼 비즈니스 로직을 직접 JSP 페이지에 작성하기보다는 재사용 가능한 컴포넌트인 Java Beans를 사용하는 경우가 많았습니다. 참고로 Java Beans란 재사용할 수 있는 Java 클래스를 의미하는데, 자세한 설명은 본문의 주제를 벗어날 것 같아 생략하도록 하겠습니다.

아래 코드는 Java Beans를 활용해 JSP 프로그래밍을 한 예시입니다. userBean, dataBean이라는 Java Bean을 활용해 렌더링에 필요한 정보를 가져옵니다.

<HTML>
<HEAD><TITLE>The Welcome User JSP</TITLE></HEAD>
<BODY>
		<jsp:useBean id="userBean" class="mybeans.UserBean" scope="page" />
		<jsp:useBean id="dateBean" class="mybeans.DateBean" scope="page" />
		<% String user=request.getParameter("user"); %>
		<H3>Welcome <%= userBean.getName() %>!</H3>
		<P><B> Today is <%= dateBean.getDate() %>. Have a nice day! :-)</B></P>
		<B>Enter name:</B>
		<FORM METHOD=get>
				<INPUT TYPE="text" NAME="user" SIZE=15>
				<INPUT TYPE="submit" VALUE="Submit name">
		</FORM>
</BODY>
</HTML>

이런 JSP의 경우 어떤 방식으로 사용하느냐에 따라 모델 1 구조와 모델 2 구조로 나뉘었습니다. JSP를 통해 뷰의 구성과 제어 로직의 처리까지 모두 수행한다면 모델 1이라고 불렸고, 뷰의 구성만 담당한다면 모델 2라고 불렸습니다.

앞서 본 Java Beans를 활용하는 JSP 예시 코드가 모델 1에 해당합니다. JSP가 직접 Java Beans를 호출하는 등의 제어 로직을 담당하기 때문입니다.

모델 1의 경우에는 구조가 단순하여 간단한 페이지를 구성하는 데에 주로 사용되었지만, 규모가 큰 프로그램을 작성할 때에는 상당한 양의 Java 코드가 JSP 파일에 드러나게 되었습니다. 이는 시스템 규모가 크다면 JSP의 장점을 살릴 수 없었음을 의미합니다.

따라서 대안으로 모델 2가 등장하게 됩니다. 모델 2의 경우는 모델 1을 보완한 것으로 제어 로직 처리 자체는 서블릿이 하며 JSP는 렌더링만 담당하게 됩니다. 이를 통해 비즈니스 로직과 뷰의 책임을 명확하게 분리할 수 있게 됩니다.

코드로 나타내면 아래와 같습니다. 서블릿에서는 HTTP 요청을 받고, 적절한 제어 로직을 수행합니다. 그리고 request의 Attribute에 렌더링을 원하는 객체를 등록한 뒤, JSP 페이지로 포워딩합니다.

클라이언트를 거쳐 다시 HTTP 요청을 보내는 것이라면 리다이렉션, 서버 내에서만 이동하는 경우 포워딩이라고 부릅니다.

Servlet 코드

public class MyServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 비즈니스 로직 수행
        java.util.Date now = new java.util.Date();
        request.setAttribute("currentDateTime", now);

        // JSP 페이지로 리다이렉션
        request.getRequestDispatcher("myView.jsp")
					.forward(request, response);
    }
}

그리고 JSP 페이지에서는 단순히 currentDateTime 객체를 꺼내 렌더링만 수행합니다.

JSP 코드

<HTML>
<HEAD><TITLE>JSP Model 2 example</TITLE></HEAD>
<BODY>
    <H1>current date and time:</H1>
    <P><%= request.getAttribute("currentDateTime") %></P>
    <h2>login form:</h2>
    <FORM action="process.jsp" method="post">
        <INPUT type="text" name="name"><BR>
        <INPUT type="text" name="email"><BR>
        <INPUT type="submit" value="submit">
    </FORM>
</BODY>
</HTML>

이처럼 모델 2는 Servlet과 JSP의 관심사를 분리하여 유지 보수성을 향상시킨 모델입니다. Servlet은 제어 로직을 담당하고, JSP는 뷰 로직을 담당합니다. 그리고 이 구조는 현재 우리에게 익숙한 MVC 패턴과 유사합니다.

J2EE와 EJB

앞서서 우리는 동적 페이지를 구현하기 위한 방법으로 Servlet과 JSP를 살펴보았습니다. 사실 Servlet과 JSP는 J2EE에 포함되어 있는데, J2EE란 기업 환경의 어플리케이션을 구성하는 데 필요한 표준의 집합을 의미합니다.

많은 Java 개발자들은 이 J2EE라는 표준을 따르며 웹 어플리케이션을 구축해왔습니다. J2EE에는 JDBC, Servlet, JSP 등 JVM 진영에서 개발을 해보았다고 한다면 한 번쯤은 들어보았을만한 표준이 많이 존재합니다. 그렇지만 모든 표준이 항상 실용적이었던 건 아닙니다.

J2EE에는 EJB라는 기술이 존재합니다. EJB(Enterprise Java Beans)란 분산 애플리케이션을 지원하는 컴포넌트 객체이며, J2EE를 사용해 엔터프라이즈급 서버를 개발하는 경우 EJB로 비즈니스 로직을 처리했습니다. 그리고 이런 EJB 객체들을 관리하는 EJB 컨테이너라는 것도 존재했는데, EJB 컨테이너는 분산 트랜잭션 지원 등의 기술적인 지원을 해주었습니다.

하지만 EJB로부터 기술적인 지원을 받기 위해서는 EJB 컨테이너에 종속적인 코드들을 많이 작성해야 했고, 더는 순수한 비즈니스 로직을 작성하기가 어려웠습니다.

다음은 EJB를 사용하는 경우의 예시 코드입니다. HelloBean은 단순히 이름이 입력으로 들어왔을 때 “Hello”를 붙여 출력해주는 비즈니스 객체입니다. 해당 객체는 단순한 비즈니스 로직을 수행함에도 불구하고 SessionBean이라는 인터페이스를 구현해야 합니다. EJB와 관련된 코드가 상당 부분을 차지하고 있는 모습을 확인하실 수 있습니다.

import javax.ejb.*;

public class HelloBean implements SessionBean {

    public String sayHello(String myName) throws EJBException {
        return ("Hello " + myName);
    }

    /* ------------------------------------------------------
    * Begin EJB-required methods. The following methods are called
    * by the container, and never called by client code
    * ------------------------------------------------------- */

    public void ejbCreate() throws CreateException {
        // when bean is created
    }

    public void setSessionContext(SessionContext ctx) {

    }

		// Life Cycle Methods

    public void ejbActivate() {

    }

    public void ejbPassivate() {

    }

    public void ejbCreate() {

    }

    public void ejbRemove() {

    }
}

이런 형식의 웹 어플리케이션 개발은 유지 보수성에 있어 많은 문제를 불러왔고, 흔히 이 시기를 ‘추운 겨울’이라고 표현하기도 했습니다.

Spring

이처럼 J2EE 표준을 준수한 애플리케이션들이 너무나도 복잡해지니 로드 존슨이라는 사람이 나타나 ‘J2EE Development without EJB’ 라는 책을 출간합니다.

로드 존슨은 해당 저서에서 EJB의 문제점을 제시하면서 EJB를 사용하지 않고도 충분히 고품질의 애플리케이션을 개발할 방법이 존재함을 증명했습니다. 그리고 이 저서가 바로 Spring이라는 웹 프레임워크의 시작점입니다.

로드 존슨이 주장하는 Spring의 핵심 가치는 ‘POJO를 통해 순수한 비즈니스 로직을 작성하자’ 입니다. EJB를 사용하는 경우 앞서 말씀드렸듯이 특정 기술에 종속적인 코드를 작성하게 되었고, 객체 지향적이고 순수한 비즈니스 로직과는 거리가 멀어졌기 때문입니다.

Spring is essentially a technology dedicated to enabling you to build applications using POJOs. - Rod Johnson

Spring은 EJB의 문제점을 해결하기 위한 장치들을 여럿 가지고 있습니다. 대표적인 장치로는 제어의 역전(Inversion Of Control), 의존성 주입(Dependency Injection), 관점 지향 프로그래밍(Aspect Oriented Programming) 등이 있습니다. 이외에도 트랜잭션 추상화 같은 다양한 개발 편의 기술들을 제공하기도 합니다.

이런 Spring을 사용하면 EJB 스펙을 따르지 않아도 EJB와 비슷한 효과를 낼 수 있었습니다. 하지만 여기서 주의해야 할 점은, Spring 자체가 J2EE 사양을 대체하기 위해 등장한 프레임워크는 아니라는 것입니다. 로드 존슨의 저서 이름을 보시면 아시다시피, Spring은 J2EE 사양을 보완하기 위해 등장한 프레임워크임을 알아야 합니다.

현재는 Spring이 단순히 J2EE 사양을 보완할 뿐만 아니라, 독자적인 생태계를 구성하고 있습니다. Spring MVC 뿐만 아니라 Spring Batch, Spring Security, Spring Reactive 등과 같은 많은 기술이 생겨나고 있으며 그 입지를 단단히 하고 있습니다.

마치면서

WWW의 등장으로부터 Spring에 이르기까지의 역사를 훑어보았습니다. 이를 통해 시대적 배경 속에 각각의 기술들이 등장할 수밖에 없었던 이유를 확인할 수 있었습니다.

정보 공유를 위해 WWW가 탄생했으며, 동적 페이지에 대한 요구에 대응하기 위해 CGI, Servlet, JSP 등의 기술이 생겨났습니다. 또한, J2EE 사양의 한계를 극복하기 위해 웹 프레임워크인 Spring이 등장했었습니다.

역사를 보시면 아시다시피, 100% 완전무결한 기술은 없습니다. 그렇기 때문에 기술의 근본을 이해하려는 노력이 중요하다고 생각합니다.

이번 글을 통해 평소 웹 어플리케이션의 발전 과정에 대해 궁금하셨던 분들의 요구가 충족되었으면 하는 바람입니다.

감사합니다.

참고 자료

프로가 되기 위한 웹기술 입문 - 위키북스
Introduction to the Spring Framework - Rod Johnson
Information Management: A Proposal - Tim Berners-Lee, CERN
History of World Wide Web -Wikipedia
Web Server - Wikipedia
HTML - MDN Web Docs
Servlet Overview - Oracle
JSP Overview - Oracle
About the Model 2 Versus Model 1 Architecture - Oracle
Session Bean Interface - Oracle
Spring Framework Overview - Spring

어떤 경우에 한 방 조인 쿼리와 여러 개 쿼리 분리를 고려할 수 있을까?

Mon, 13 Nov 2023 12:00:00 GMT

최근에 프로젝트에서 리팩토링과 동시에 쿼리 개선을 하고 있는데요. 조인 한 방 쿼리로 한 번에 끝내는 게 여러 번 네트워크 타는 것보다 좋을 것 같아서 한 방 쿼리로 수정하고 있다가 다음과 같이 모든 쿼리가 조인이 덕지 덕지 붙어있는 코드를 보고 뭔가 이상함을 감지했습니다.

select * from pet_food p1_0
join brand b1_0 on b1_0.id=p1_0.brand_id
join pet_food_primary_ingredient p2_0 on p1_0.id=p2_0.pet_food_id
join primary_ingredient p3_0 on p3_0.id=p2_0.primary_ingredient_id
where p1_0.id=1

select * from review r1_0
join pet p1_0 on p1_0.id=r1_0.pet_id
join breed b1_0 on b1_0.id=p1_0.breed_id
join pet_size p2_0 on p2_0.id=b1_0.pet_size_id
left join helpful_reaction h1_0 on r1_0.id=h1_0.review_id
join adverse_reaction a1_0 on r1_0.id=a1_0.review_id
where r1_0.id=?

뭔가 아닌 거 같은데..? 물론 한 방 쿼리가 좋을 때도 있지만 항상 한 방 쿼리가 좋진 않을 것인데 언제 한 방 쿼리를 사용하고 언제 여러 개 쿼리를 사용할 수 있을지 궁금증이 생겼습니다.

조인(Join)으로 한 방 쿼리 vs 쿼리 여러 개

No Silver Bullet - 만병통치약은 없다.

어떤 성능 시나리오에서든 어느 솔루션이 더 빠른지 확인하기 위해 직접 솔루션을 테스트하고 측정해야 합니다. 즉, 최선의 경우는 없는데요. 하지만, 일반적으로 어떤 상황에서 쓰면 좋을지는 통계가 있을 것입니다. 테이블 관계를 기준으로 한번 살펴봅시다.

일대일 관계

일반적으로 일대일 관계 같은 많은 외부 레코드를 가리키지 않는 경우 다음과 같은 성능을 나타냅니다.

조인이 가장 빠른데 그 이유는 여러 개 쿼리가 발생하면 데이터베이스에 대한 각 쿼리에 고정 비용이 발생하기 때문입니다. 일대일 관계 같은 경우 중복도 발생하지 않아서 부담 없이 조인을 사용할 수 있을 것 같습니다.

그렇다고 해서, 일대다 관계에서는 절대 조인을 쓰지 말란 것이 아닙니다. 위에서 말한 것에 핵심 포인트는 일대일 관계뿐 아니라 일대다 관계에서도 많은 외부 레코드를 가리키지 않는 경우입니다. 한 방 조인으로 결괏값 주기 vs 여러 번 통신 + 애플리케이션에서 조합의 트레이드오프를 잘 고려해 봐야 됩니다.

일대다 관계

하지만, 참조된 레코드 중 다수가 동일할 수 있는 일대다 관계 같은 경우 조인 시에 중복이 엄청나게 발생할 수 있으니 잘 생각해 봐야 됩니다.

예를 들어봅시다.

위와 같은 관계에서 1개의 게시물이 있고 게시물에는 2개의 댓글과 2개의 태그가 있다고 가정해 봅시다.

SELECT post.id, comment.id, tag.id
FROM post
LEFT JOIN comment on post.id = comment.post_id
LEFT JOIN tag on tag.post_id = post.id;

-- post_id comment_id tag_id
-- 1        1           1
-- 1        1           2
-- 1        2           1
-- 1        2           2

위와 같은 쿼리를 실행하면 2 * 2로 4개의 결과가 나왔습니다. 여기서 댓글과 태그가 4개로 늘어난다면 어떻게 될까요?

SELECT post.id, comment.id, tag.id
FROM post
LEFT JOIN comment on post.id = comment.post_id
LEFT JOIN tag on tag.post_id = post.id;

-- post_id comment_id tag_id
-- 1        1           1
-- 1        1           2
-- 1        1           3
-- 1        1           4
-- 1        2           1
-- 1        2           2
-- 1        2           3
-- 1        2           4
-- 1        3           1
-- 1        3           2
-- 1        3           3
-- 1        3           4
-- 1        4           1
-- 1        4           2
-- 1        4           3
-- 1        4           4

각 행의 곱인 4 * 4 = 16개의 행이 나오게 됩니다. 그럼 만약에 각 데이터의 수가 1000개씩만 되어도 나오는 행의 수는 몇 개일까요..? 여기서 더 많은 테이블과 레코드들을 추가하면 수많은 중복된 데이터가 생겨날 것입니다. 실제 테스트를 해봅시다. 실험 환경은 다음과 같습니다.

Mac M1 Pro 16G 512GB
실험 데이터 수는 게시글 1개, 댓글 1000개, 태그 1000개

먼저 조인을 이용하여 100만(1000 * 1000)개의 테이블을 생성해 결괏값 100만 개를 내어줄 때는 12초가 걸렸습니다.

하지만, 두 개의 쿼리(1000 + 1000)로 분리하여 결괏값 100만 개를 내어 줄 때는 고작 0.2초밖에 안 걸린 걸 볼 수 있습니다.

여러 개의 테이블을 조인하는 경우도 아래의 벤치마크를 한번 봅시다. 두 경우 모두 동일한 결과(6 x 50 x 7 x 12 x 90 = 2268000)를 얻지만 여러 개의 쿼리가 훨씬 더 빠릅니다.

5개의 조인을 사용한 단일 쿼리

쿼리: 8.074508초

결과 크기: 2268000
연속 쿼리 5개

결합된 쿼리 시간: 0.00262초

결과 크기: 165(6 + 50 + 7 + 12 + 90)

또한, 중복 데이터로 인해 더 많은 메모리를 사용합니다. 적은 테이블의 수를 조인하는 경우 메모리 사용량이 적겠지만, 테이블이 점점 늘어날수록 차지하는 메모리가 기하급수적으로 늘기 때문에 잘 고려하면 좋을 것 같습니다.

조인이 적합한 지 여부 판단

조인을 사용해야 하는지는 조인이 적합한지에 따라 판단해 볼 수도 있습니다. 위의 예시로 사용한 테이블에서 댓글과 태그는 게시글과는 관련이 있지만 서로는 관련이 없습니다. 이 경우 두 개의 별도 쿼리를 사용하는 것이 더 좋습니다. 태그와 댓글을 결합하려고 하면 둘 사이에는 직접적인 관계가 없는데도 각 테이블행의 곱만큼 가능한 모든 조합이 생성됩니다. 또한, 두 쿼리를 병렬로 수행하여 이득을 얻을 수도 있습니다.

하지만, 여기서 만약에 다음과 같은 상황을 생각해 봅시다.

게시물에 댓글을 달고 댓글 작성자의 이름까지 원한다면? 조인을 고려해 볼 수 있습니다. 훨씬 더 자연스러운 쿼리일 뿐 아니라 데이터베이스 시스템에서 이와 같은 쿼리를 최적화하려고 노력하고 있다고 합니다.

서브쿼리(SubQuery)

조인 대신에 서브 쿼리를 이용하는 방법도 있습니다. 서브 쿼리와 조인의 성능을 비교해 봅시다. 우선 MySQL 5.5 버전에서 서브 쿼리는 못쓸 정도라고 평할 정도로 제대로 수행되지 않았습니다.

테스트 데이터

메인 테이블 100만 건
서브 테이블1 (Index O) 1000건
서브 테이블2 (Index X) 1000건

수행 시간

MySQL 5.5 + 서브 쿼리 + No Index에서 100만 건 & 1천 건 조회에 3분이 소요
MySQL 5.5 + 서브 쿼리 + Index에서 100만 건 & 1천 건 조회에 1.8초 소요
MySQL 5.5 + 조인 + No Index에서 100만 건 & 1천 건 조회에 11초 소요
MySQL 5.5 + 조인 + Index에서 100만 건 & 1천 건 조회에 0.139초 소요

MySQL 특정 버전(5.5이하)에서는 서브 쿼리 대신 조인이 압도적으로 빠른 것을 볼 수 있습니다.

MySQL에서는 무슨 일이 있었기에 5.5 버전에서는 서브 쿼리 성능이 좋지 않을까요?

최적화 부재: 초기 버전의 MySQL에서는 서브 쿼리에 대한 충분한 최적화가 이루어지지 않았습니다. 그 결과 서브 쿼리는 복잡한 연산을 필요로 하는 경우에 매우 비효율적으로 동작하게 되었습니다.
재귀적 처리: MySQL 5.5에서 서브 쿼리는 종종 재귀적으로 처리되었고, 이는 성능 문제를 야기했습니다. 특히, 상위 쿼리에서 서브 쿼리의 결과를 여러 번 재참조해야 할 때 이 문제가 두드러졌습니다.

5.6에서는 서브 쿼리 성능 개선이 많이 이루어졌습니다.

수행 시간

MySQL 5.6 + 서브 쿼리 + No Index에서 100만 건 & 1천 건 조회에 19초 소요
MySQL 5.6 + 서브 쿼리 + Index에서 100만 건 & 1천 건 조회에 0.18초 소요

3분에서 19초, 11초에서 0.18초 개선될 정도로 5.6에서는 최적화가 이루어졌지만 아직 모든 서브 쿼리가 다 최적화가 된 것은 아니라고 합니다.

즉, 웬만하면 최대한 조인을 이용하고 조인을 이용하기 어렵다면 5.6 이상은 서브 쿼리를 사용합니다. 5.5 이하는 절대 사용하지 않고 차라리 쿼리를 나눠서 2번(메인 쿼리, 서브 쿼리) 실행하고 애플리케이션에서 조립하면 좋을 것 같습니다. 물론, 스칼라 서브 쿼리 캐싱 등의 최적화 기술로 때때로 서브 쿼리가 조인보다 더 효율적일 때도 있습니다.

결론

사실 위의 내용은 어느 정도 통계에 기반에서 이렇다 할 뿐이지 자신의 상황에서는 전혀 다르게 동작(고려해야 할 변수가 많기 때문에)할 수도 있습니다. 그러므로 참고만 하고 EXPLAIN 같은 실행 계획이나 직접 테스트하여 측정해 사용하도록 합시다.

Don’t guess, measure!

참고:

레이어드 아키텍처에서 이미지 업로드하기

Mon, 13 Nov 2023 12:00:00 GMT

[Android] 레이어드 아키텍처에서 이미지 업로드하기

배경

저는 현재 ‘나아가’라는 우테코 프로젝트와 ‘ZOOC’이라는 사이드 프로젝트에서 안드로이드 개발을 담당하고 있습니다. 두 프로젝트에서 모두 이미지 업로드를 위해 multipart/form-data를 사용하고 있습니다.

프로젝트 동안 다른 팀원들의 이미지 업로드 기능 구현을 리뷰하면서 새로운 방식이 떠올랐습니다. 떠오른 것을 깊이 고민하고 비교하며 더 좋은 방안을 생각했고 그 결과를 팀에 제안했습니다. 이 글에서 해당 내용에 대해 나누려고 하며 단순한 이미지 업로드 기능 구현 방법뿐만 아니라, 아키텍처 관점에서 해당 구현을 어디에서 하면 좋을지가 그 내용입니다.

만약 이미 이미지 업로드 기능 구현 경험이 있고 아키텍처 관점만이 궁금하시다면 프로젝트 구조와 구현 예시부터 보셔도 좋습니다.

HTTP multipart/form-data란?

안드로이드 개발을 하다 보면 이미지 업로드 기능을 종종 마주치게 됩니다. 이미지 파일을 서버에 전송하는 방법은 여러 가지가 있지만, 그중에서 말씀드릴 내용은 multipart/form-data를 이용하는 것입니다.

안드로이드 개발을 하다 보면, TCP/IP 기반의 HTTP 프로토콜 통신 과정에서 JSON 데이터를 주로 주고받습니다. 클라이언트와 백엔드가 서로에게 필요한 데이터를 JSON 타입으로 주고받는 것이죠. 이때 주고받을 데이터의 타입을 (정확히는 MIME 타입을) HTTP 헤더에 Content-type으로 명시하게 되는데, JSON의 경우 Content-type이 application/json이 됩니다. 사진이나 mp3 같은 “파일”들의 Content-type은 어떻게 될까요? jpg나 jpeg 이미지 파일은 image/jpeg, mp3 파일은 audio/mpeg 형식으로 통신할 수 있습니다.

파일 종류	Content-type
jpg, jpeg	image/jpeg
mp3	audio/mpeg
json	application/json
…	…

그렇다면 multipart/form-data는 무엇일까요?

위의 화면처럼 생긴 일기를 작성하는 기능을 예시로 글을 진행하겠습니다. 해당 일기에는 사진, 제목, 내용 이렇게 세 가지 정보가 들어갑니다. 일기를 “생성”해야 하므로 서버로 POST 요청을 보내야 합니다. POST 요청을 보내기 위해 HTTP 요청의 본문인 body에 사진, 제목, 내용을 함께 담으려고 하는데 잠깐..! Content-type을 무엇으로 지정해야 할까요?

이렇게 여러 타입의 데이터를 한 번에 전송하고 싶을 때 우리는 multipart/form-data 형식을 활용합니다. multipart라는 말 그대로 바디에 해당하는 데이터가 여러 부분(타입)으로 이루어져 있다고 생각하시면 됩니다. 이럴 때 우리는 Content-type으로 multipart/form-data를 사용하게 됩니다.

이미지 가져오기

지금까지 multipart/form-data에 대해 간략하게 알아봤습니다. 이제 이미지 업로드 과정을 살펴볼 차례인데요, 이미지 파일을 서버에 전송하려면 우선 이미지가 있어야겠죠? 제가 진행 중인 두 프로젝트에서는 다른 방식으로 이미지를 가져옵니다.

디바이스에서 저장되어 있는 이미지를 가져오는 것
사진을 바로 촬영해서 가져오는 것

이미지를 가져오기 전에 먼저 알아야 할 개념이 있습니다. 안드로이드에서 이미지 정보를 가져올 때 Uri 객체로 가져오게 되는데, Uri에 대해 잠시 설명하고 넘어가겠습니다.

URI는 ‘Uniform Resource Identifier’로 한글로 하면 ‘통합 자원 식별자’입니다. 즉, 자원(리소스)를 식별하는 고유한 아이디라고 볼 수 있습니다. URI의 개념 자체는 웹에서 출발했지만 인터넷상의 자원에 국한되지는 않습니다.

안드로이드에서는 Uri라는 클래스가 존재하며 android.net 패키지에 있습니다. 이는 안드로이드 프레임워크 내의 자원에 대한 식별자이며 이를 통해 사진, 음성 파일 등의 디바이스 데이터에 접근할 수 있습니다. 지금부터 글에서 Uri라 함은 방금 설명한 안드로이드 프레임워크의 클래스를 지칭하는 것으로 하겠습니다.

디바이스에서 저장되어 있는 이미지 가져오기

존재하는 이미지를 가져올 때는 ActivityResultContracts.PickVisualMedia() 를 사용하고 있습니다. (공식문서)

private val launcher = registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri: Uri? ->
	uri?.let { // uri 사용하기 }                                                                  
}
                                                                                        
private fun selectImage() {
    launcher.launch(PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly))
}

위와 같이 launcher 를 선언하고 launch 함수를 호출하면 아래 사진과 같이 이미지를 가져올 수 있는 다이얼로그가 나옵니다. (Android 13 / One UI 5.1)

사진을 선택하면 launcher의 콜백에서 해당 사진의 Uri를 받을 수 있습니다.

사진을 바로 촬영해서 가져오기

앞선 방식이 디바이스에 이미 존재하는 사진을 가져온다면, 이번 방식은 사진을 직접 촬영하고 바로 가져옵니다. 다양한 방식이 존재하겠지만 해당 프로젝트에선 ActivityResultContracts.TakePicture()를 사용합니다.

private var imageUri: Uri? = null

private val launcher = registerForActivityResult(ActivityResultContracts.TakePicture()) { success: Boolean
    if(success) {
        // TODO: uri 사용하기
    }
}

private fun startCamera() {
    imageUri = createImageUri().getOrElse {
		// TODO: 오류 처리
       	return
    }
    launcher.launch(imageUri) // 매개변수로 전달한 Uri로 사진이 저장됩니다.
}

// uri 생성하기
private fun createImageUri(): Result<Uri> {
    val contentValues = getContentValues()
    val uri = contentResolver.insert(
            MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
            contentValues,
        ) ?: return Result.failure(// TODO: 원하시는 Throwable을 담으시면 됩니다!)
        return Result.success(uri)
}

private fun getContentValues(): ContentValues {
    return ContentValues().apply {
        // TODO: 원하시는 칼럼을 추가하시면 됩니다!
    }
}

권한과 관련한 코드 및 설명은 생략합니다

ActivityResultContracts.TakePicture() 를 사용하게 되면 콜백 함수는 성공 여부를 반환하게 되고, launcher.launch() 함수에 우리가 직접 생성한 Uri를 담고 해당 Uri로 사진이 저장됩니다. 사진을 저장하지 않고 보여주고 싶다면 ActivityResultContracts.TakePicturePreview() 도 존재하지만, 다음의 설명처럼 화질이 저하된 비트맵을 콜백으로 받아보실 수 있습니다.

An ActivityResultContract to take small a picture preview, returning it as a Bitmap.

프로젝트에 사용된 사진을 가져오는 두 가지 방법에 대해 알아보았습니다. 위 방법보다 좋은 방법들이 있을 수 있습니다. 다만 사진을 가져오는 것 자체가 글의 주제가 아니므로 넘어가도록 하겠습니다. 어찌 됐든 우리는 두 방식에서 모두 Uri를 얻었고 이제 Uri를 이용해서 이미지를 서버로 보내야 합니다!

두 프로젝트 모두 서버 통신에서 Retrofit 라이브러리를 사용 중입니다. 그래서 최종적으로 이미지 및 함께 전송할 데이터들을 Retrofit에서 지원하는 RequestBody 혹은 MultipartBody.Part 타입으로 만들어야 합니다.

Uri가 Part가 되는 과정

지금까지 보내고자 하는 이미지의 Uri를 얻었습니다. 이제 이미지를 보내기만 하면 됩니다! 어떻게 하면 될까요? imageUri.toPart() 하면 우리가 원하는 형태가 나올까요? 아쉽게도 그런 함수는 없습니다. 그럼 어떤 과정을 거쳐야 할지 지금부터 알아보겠습니다!

우선 최종적으로 서버에 어떤 형태로 데이터를 전송할지 보고 시작하면 좋을 것 같습니다. 그래서 API 명세서와 Retrofit을 통해 명세대로 작성한 서비스 인터페이스를 먼저 보도록 하죠!

interface DiaryService {
    @Multipart
    @POST("diary")
    fun postDiary(
        @Part("title") title: RequestBody,
        @Part("content") content: RequestBody,
        @Part photo: MultipartBody.Part,
    ): Response<DiaryDto>
}

API 명세서와 코드를 비교해서 보시면 postDiary()의 인자에 명세서의 Request Body가 들어가게 되고, 명세서의 Response Body가 DiaryDto가 됩니다. 그런데 코드를 살펴보면 title과 content는 키 값을 갖는데 왜 photo는 키 값이 없지? 라고 생각하실 수 있습니다. 이 부분은 뒤에서 MultipartBody.Part 타입에 대해 이야기할 때 알아볼 예정입니다.

postDiary()를 보시면 @Multipart 어노테이션이 있습니다. 이 어노테이션을 달아주는 것은 해당 함수의 Content-type이 multipart/form-data 라고 명시하는 것입니다. 그럼 Retrofit이 내부적으로 어노테이션을 통해 Content-type 을 지정해 줍니다.

@Part 어노테이션으로 각 part를 명시해 주고, 여러 part가 모여 하나의 multipart/form-data 형식을 이룹니다. 초반에 multipart/form-data에 관해 설명했던 내용이 코드로 보이는 부분입니다. 파일은 MultipartBody.Part로, title, content와 같은 문자열은 RequestBody로 보내고 있습니다.

그럼 MultipartBody.Part와 RequestBody 객체를 생성하려면 어떻게 해야 할까요? 아래 코드를 보시면 MultipartBody.Part를 만드는 팩토리 메서드들이 존재합니다.

class Part private constructor(
    @get:JvmName("headers") val headers: Headers?,
    @get:JvmName("body") val body: RequestBody
  ) {
    
    // ...
    
    companion object {
        @JvmStatic
      	fun create(body: RequestBody): Part = create(null, body)

      	@JvmStatic
      	fun create(headers: Headers?, body: RequestBody): Part {
            // ...
        	return Part(headers, body)
      	}
        
        @JvmStatic
      	fun createFormData(name: String, value: String): Part =
          	createFormData(name, null, value.toRequestBody())

      	@JvmStatic
      	fun createFormData(name: String, filename: String?, body: RequestBody): Part {
            val disposition = buildString {
          		append("form-data; name=")
          		appendQuotedString(name)

          		if (filename != null) {
            		append("; filename=")
            		appendQuotedString(filename)
          		}
        	}

        	val headers = Headers.Builder()
            	.addUnsafeNonAscii("Content-Disposition", disposition)
            	.build()

        	return create(headers, body)
        }
    }
}

총 네 개의 팩토리 메서드가 존재하는데요, 저희 대신 많은 일을 해주는 마지막 메서드를 사용할 예정입니다. 마지막 메서드를 호출하기 위해 필요한 인자들을 봅시다. String 타입의 name과 filename, 그리고 RequestBody 형태의 body가 필요합니다.

우선 name과 filename에 대해 알아봅시다. 여기서 name은 키 값입니다. 업로드된 데이터에서 백엔드가 원하는 값을 꺼내려면 키 값이 있어야겠죠? 앞에서 명세서를 볼 때 언급했던 photo에 대한 키 값입니다. 백엔드와 합의하신 키 값을 적어 주시면 됩니다. 여기서는 “imageFile”이 됩니다. filename은 말 그대로 파일명입니다. 전송하실 파일의 이름을 적어 주시면 됩니다.

이제 RequestBody를 생성하는 방법에 대해 알아봅시다. RequestBody는 추상 클래스이며 이를 구현하기 위해서는 두 개의 추상 메서드를 필수적으로 구현해야 합니다. 동반 객체를 보시면 아래와 같이 확장 함수로 RequestBody를 생성해 주는 메서드들이 구현되어 있습니다.

fun String.toRequestBody(contentType: MediaType? = null): RequestBody { ... }
fun ByteString.toRequestBody(contentType: MediaType? = null): RequestBody { ... }
fun ByteArray.toRequestBody(contentType: MediaType? = null,  offset: Int = 0,  byteCount: Int = size): RequestBody { ... }
fun File.asRequestBody(contentType: MediaType? = null): RequestBody { ... }

쭉 훑어보시면 다른 타입의 객체들을 RequestBody로 변환해 주는 함수들입니다. 이 중에 뭘 사용해야 할까요? 우선은 File에서 변환하는 마지막 메서드를 사용해 보겠습니다. 그렇다면 이제 남은 건 File 객체를 만드는 것입니다.

File 객체의 생성자들을 살펴보다 보면 아래와 같은 생성자를 발견할 수 있습니다!

public File(URI uri) { ... }

그럼 이제 File을 만들 수 있겠군요! 하지만 이것은 틀렸습니다. 이미지로부터 얻어온 것은 android.net 패키지의 Uri이고 위에 보이는 것은 java.net 패키지의 URI입니다. 헷갈리지 않도록 주의합시다! 다른 생성자를 둘러보면 아래와 같이 pathname을 받는 생성자가 있습니다.

public File(String pathname) { ... }

여기서 pathname이란 파일이 위치하는 절대 경로를 의미합니다. 우리에게 좀 더 익숙한 예시를 들자면 C:\Program Files\Android\Android Studio과 같은 것을 말합니다. 우리가 갖고 있던 Uri는 파일의 절대 경로가 아닌 안드로이드 프레임워크의 식별자이므로 pathname은 새로 얻어 와야 합니다.

그럼 우리가 가진 Uri로 pathname을 가져와야 합니다. Uri 객체를 살펴보면 getPath() 함수가 존재합니다. 하지만 해당 함수는 우리가 원하는 파일 경로를 주지 않습니다. (단순히 현재 식별자(URI)에서 path 부분만 떼어서 반환합니다) 그럼 파일 경로를 어떻게 가져올 수 있을까요? 프로젝트의 코드를 첨부합니다.

private fun Uri.getFilePath(): String? {
    val projection = arrayOf(MediaStore.Images.Media.DATA)
    val cursor = contentResolver.query(this, projection, null, null, null)
    cursor?.use {
        if (it.moveToFirst()) {
            val columnIndex = it.getColumnIndexOrThrow(MediaStore.Images.Media.DATA)
            return it.getString(columnIndex)
        }
    }
    return null
}

contentResolver를 통해서 MediaStore.Images.Media.DATA라는 칼럼을 읽어오면 파일 경로를 알 수 있습니다. uri, uri.getPath(), uri.getFilePath() 에 대해 로그를 찍어보면 다음과 같이 나옵니다. (예시로 제 프로젝트에서 로그를 찍어보았습니다)

첫 줄을 보시면 확실히 URI의 형태임을 알 수 있습니다. content가 scheme, media가 authority, picker부터가 path입니다. uri.getPath()는 URI에서 path 부분만 잘라서 반환합니다. uri.getFilePath는 URI 형태가 아닌 파일의 절대 경로를 반환하고 있습니다. 그러므로 저희가 사용할 것은 마지막 줄입니다. 파일 절대 경로를 알았으니 이제 File 객체를 만들 수 있습니다! val file = File(uri.getFilePath())

지금까지 살펴본 과정을 정리하면 이렇습니다.

Uri → File → RequestBody → MutlipartBody.Part

드디어 우리가 처음 받아왔던 Uri가 MultipartBody.Part 형식이 되었습니다. 이제 이미지를 업로드 하는 데는 문제가 없겠죠?

이제 진행했던 프로젝트에서 위의 일련의 과정을 어디서 어떻게 수행했는지를 알아봅시다!

프로젝트 구조와 구현 예시

일기 기능을 구현하면서 안드로이드에서 multipart/form-data 형태로 이미지를 업로드하는 방법을 알아보았습니다. 글의 제목이 ‘계층화 아키텍처’에서 이미지 업로드인 만큼, 앞으로 설명할 내용의 기반이 되는 프로젝트의 아키텍처 구조에 대해 먼저 말씀드리겠습니다.

UI 디자인 패턴으로 MVVM 패턴을 사용하였습니다.
Presentation, Domain, Data 이렇게 세 개의 Layer가 존재합니다.

MVVM 패턴을 사용하며 ViewModel은 AAC ViewModel로 구현하고 있습니다.

외부로부터 받아오는 데이터는 Data - Domain - Presentation Layer 방향으로 흐릅니다. 그러나 Domain Layer에 Repository 인터페이스를 두고, Data Layer에서 이를 구현하면서 의존성을 역전시킵니다. 그러므로 Domain Layer는 Presentation과 Data Layer를 모르고, Presentation과 Data Layer는 Domain Layer에 의존하게 됩니다. 완전히 클린 아키텍처라고 할 순 없지만 큰 틀을 따른다고 보시면 됩니다.

지금부터는 방금 설명한 프로젝트 구조로 위에서 봤던 일기 기능을 구현해 보겠습니다. (오류 처리 로직은 제외했습니다)

class DiaryVieModel(
    private val application: Application,
    private val diaryRepository: DiaryRepository,
) : ViewModel() {
    // ...
    
    private var imageUri: Uri = Uri.Empty
    
    fun writeDiary() {
        viewModelScope.launch {
            diaryRepository.postDiary(
                title = title.value ?: "",
                content = content.value ?: "",
                image = imageUri.getFilePath() ?: ""
	        )
        }
    }
    
    private fun Uri.getFilePath(): String? {
        val projection = arrayOf(MediaStore.Images.Media.DATA)
        val cursor = application.applicationContext.contentResolver.query(this, projection, null, null, null)
        cursor?.use {
            if (it.moveToFirst()) {
                val columnIndex = it.getColumnIndexOrThrow(MediaStore.Images.Media.DATA)
                return it.getString(columnIndex)
            }
        }
        return null
    }
    
    // ...
}

제가 프로젝트에서 처음 마주쳤던 ViewModel 코드입니다. 보시면 ViewModel에서 Application을 받아 applicationContext를 사용하고 있습니다. ContentResolver를 사용하려면 Context가 필수적이기 때문입니다. 또 Uri 객체를 imageUri라는 하나의 상태로 들고 있었습니다.

하지만 ViewModel에서 Context와 같은 안드로이드 의존성이 있는 객체를 참조하는 것은 그리 권장되지 않습니다. MVVM 안티패턴이라고도 볼 수 있습니다. 그 이유는 ViewModel에서 안드로이드 의존성을 가지면 유닛 테스트가 어려운 구조가 되기 때문입니다. 물론 Roboletric과 같은 라이브러리를 이용해 테스트해 볼 수도 있지만, 이는 유닛 테스트에 비해 훨씬 무거워 많은 시간이 소요됩니다.

이번에는 ViewModel에 주입 받은 Repository의 구현체를 보겠습니다.

class DefaultDiaryRepository(private val service: diaryService) : DiaryRepository {
    // ...
    
    override suspend fun postDiary(
        title: String,
        content: String,
        image: String,
    ): Result<Unit> {
        val titleRequestBody = title.toRequestBody("text/plain".toMediaTypeOrNull())
        val titlePart = MultipartBody.Part.createFormData("title", null, requestBody)
        
        val contentRequestbody = content.toRequestBody("text/plain".toMediaTypeOrNull())
        val contentPart = MultipartBody.Part.createFormData("content", null, requestBody)
       
        val file = File(image)
        val imageRequestBody = file.asRequestBody("image/jpeg".toMediaTypeOrNull())
        val imagePart = MultipartBody.Part.createFormData("imageFile", file.name, requestBody)

        service.postDiary(titlePart, contentPart, imagePart)
    }
}

ViewModel에서 받은 파일 경로를 통해 File 객체를 만들고 RequestBody와 MultipartBody.Part 객체를 만듭니다. 여기엔 크게 문제 될 만한 부분이 보이진 않습니다.

이제 위 코드들을 어떻게 개선할 수 있을지 이야기해 보겠습니다!

구현의 적절한 위치 찾기

이제 본격적으로 ‘계층화 아키텍처’에서 이미지 업로드하기라는 제목에 가까운 내용이 등장합니다. 글의 핵심 내용으로 앞서 보았던 과정들을 어디서 수행할지 알아봅시다!

우선 앞서 말했던 문제를 해결해 보겠습니다. ViewModel에서 안드로이드 의존성을 분리합니다.

Uri
context.contentResolver

contentResolver를 먼저 보겠습니다. contentResolver가 필요한 행동은 Uri로부터 파일 경로를 가져오는 것입니다. 이 행동을 다른 곳으로 옮기기 위해 연관된 행동을 한번 살펴보겠습니다.

Activity가 ViewModel에게 Uri를 넘겨준다.

ViewModel이 파일 경로를 Repository에게 넘겨준다.

연관된 행동들을 보니 contentResolver가 필요한 행동을 넘길 수 있는 곳이 보입니다.

Activity에서 처리하여 파일 절대 경로 혹은 File 객체를 ViewModel에게 넘긴다. (File은 안드로이드 의존성이 없는 자바 객체입니다)

Uri를 Repository에 넘기고 Repository에서 파일 경로를 가져오도록 한다.

Activity에서 처리하기

Activity는 그 자체로 Context이므로 contentResolver를 사용할 수 있습니다. ViewModel에 존재하던 getFilePath 함수의 로직을 (혹은 File 객체로의 변환까지) Activity로 옮기게 되면 아래와 같이 안드로이드 의존성으로부터 한결 깔끔해진 ViewModel을 만나볼 수 있습니다.

class DiaryVieModel(private val diaryRepository: DiaryRepository) : ViewModel() {
    // ...
    
    private lateinit var imageFilePath: String
    private lateinit var imageFile: File
    
    fun writeDiaryByPath() {
        viewModelScope.launch {
            diaryRepository.postDiaryByPath(
                title = title.value ?: "",
                content = content.value ?: "",
                imagePath = imageFilePath
	        )
        }
    }
    
    fun writeDiaryByFile() {
        viewModelScope.launch {
            diaryRepository.postDiaryByFile(
                title = title.value ?: "",
                content = content.value ?: "",
                imageFile = imageFile
	        )
        }
    }
    
    // ...
}

class DefaultDiaryRepository(private val service: DiaryService) : DiaryRepository {
    // ...
    
    override suspend fun postDiaryByPath(
        title: String,
        content: String,
        imagePath: String,
    ): Result<Unit> {
		// ...
       
        val file = File(image)
        val imageRequestBody = file.asRequestBody("image/jpeg".toMediaTypeOrNull())
        val imagePart = MultipartBody.Part.createFormData("imageFile", file.name, requestBody)

        service.postDiary(titlePart, contentPart, imagePart)
    }
    
    override suspend fun postDiaryByFile(
        title: String,
        content: String,
        imageFile: File,
    ): Result<Unit> {
		// ...
       
        val imageRequestBody = imageFile.asRequestBody("image/jpeg".toMediaTypeOrNull())
        val imagePart = MultipartBody.Part.createFormData("imageFile", file.name, requestBody)

        service.postDiary(titlePart, contentPart, imagePart)
    }
}

이제 앞선 ViewModel보다 훨씬 테스트에 용이한 ViewModel이 되었습니다. getFilePath 함수의 로직을 옮기면서 Uri도 자연스럽게 사라졌습니다. 그럼 이제 완성인 걸까요? 한 가지만 더 생각해 봅시다.

우리는 객체지향 프로그래밍을 할 때, 객체에 어떤 책임과 역할을 부여할지 고민합니다. 그럼 Uri로부터 파일 경로 혹은 File 객체를 가져오는 행동은 과연 Activity의 책임일까요?

사람마다 생각이 다르겠지만 저는 아니라고 생각합니다. 제가 정의한 Presentation Layer는 뷰와 뷰의 상태에 관련된 일을 해야 합니다. 그런 의미에서 Activity의 역할은 사진을 선택하는 것에서 끝났습니다.

그럼 Uri로부터 파일 절대 경로 혹은 File 객체를 가져오는 행동은 어디서 수행해야 할까요? 앞서 두 가지 선택지가 있었던 것이 기억나시나요? 그 두 번째 선택지를 보겠습니다.

Repository에서 처리하기 (Data Layer에서 처리하기)

Repository에서 수행하게 된다면 원래의 ViewModel에서 getFilePath 함수만 Repository로 넘어가게 됩니다.

여기서 두 가지 문제가 생깁니다.

ViewModel에 Uri는 그대로 남아있다.
Domain Layer에서 Uri 타입을 참조해야 한다.

이 부분을 해결하기 위해 Activity에서 Uri의 toString 함수를 사용해 String 타입으로 변환합니다. (ex. viewModel.setImage(uri.toString()))

class DiaryVieModel(private val diaryRepository: DiaryRepository) : ViewModel() {
    // ...
    private lateinit var imageUri: String
    
    fun wirteDiary() {
        viewModelScope.launch {
            diaryRepository.postDiaryByPath(
                title = title.value ?: "",
                content = content.value ?: "",
                imageUri = imageUri
	        )
        }
    }
    
    // ...
}

class DefaultDiaryRepository(
    private val contentResolver: ContentResolver,
    private val service: DiaryService,
) : DiaryRepository {
    // ...
    
    override suspend fun postDiary(
        title: String,
        content: String,
        imageUri: String,
    ): Result<Unit> {
		// ...
       
        val uri = Uri.parse(imageUri)
        val file = File(uri.getFilePath())
        val imageRequestBody = file.asRequestBody("image/jpeg".toMediaTypeOrNull())
        val imagePart = MultipartBody.Part.createFormData("imageFile", file.name, requestBody)

        service.postDiary(titlePart, contentPart, imagePart)
    }
    
    private fun Uri.getFilePath(): String? { ... }
}

Uri로부터 파일 경로와 File 객체를 가져오는 행동을 Repository에서 수행하였습니다. 이 행동을 수행하기 위해선 Uri라는 경로와 contentResolver를 통해 디바이스의 데이터에 접근해야 합니다. 이런 행동은 분명 Data Layer의 책임이라고 생각해 Repository로 옮겨보았습니다. (DataSource가 있다면 DataSource의 역할이라고 생각합니다. DataSource를 데이터의 출처라고 생각하며 contentResolver를 통해 디바이스의 데이터를 가져왔기 때문입니다. 그러나 현재 프로젝트에선 DataSource가 따로 존재하지 않아 Repository에서 수행하였습니다)

Repository에서 ContentResolver를 참조하는 부분에서 고개를 갸우뚱하시는 분들이 계실 수도 있습니다. Repository는 “저장소”이고 (DataSource가 있다면) DataSource는 저장소에서 필요한 데이터의 출처입니다. ContentResolver를 사용하여 디바이스의 데이터를 접근하는 행위는 Repository와 DataSource 즉, Data Layer의 역할이라고 볼 수 있습니다. 그러므로 Data Layer의 어디선가 ContentResolver를 참조하는 것은 생소할 수 있지만 이상하지 않다고 말씀드릴 수 있습니다.

여전히 낯설다면 Room과 같다고 생각해 보시면 좋습니다. Room은 안드로이드 프레임워크에서 제공하는 ORM으로 앱에서 로컬 데이터베이스가 필요할 때 많이 사용합니다. DataSource에서 Room을 사용하는 것이 생소하지 않다면 ContentResolver 또한 마찬가지입니다. Room과 ContentResolver 모두 디바이스에 데이터를 읽고 쓰는 역할을 하기 때문입니다. (저장할 위치와 저장할 내용이 다릅니다)

하지만 이런 구조에서도 한 가지 문제가 존재합니다. Activity에서 Uri를 String으로 변환하고 ViewModel에서 Domain Layer의 DiaryRepository 인터페이스의 postDiary 함수가 사용됩니다. 그리고 DiaryRepository의 구현체인 Data Layer의 DefaultDiaryRepository에서 String을 Uri로 파싱하게 됩니다.

interface DiaryRepository {
    //...
    
    suspend fun postDiary(
        title: String,
        content: String,
        imageUri: String,
    ): Result<Unit> 
}

그 과정에서 Domain Layer에서 postDiary 함수의 imageUri라는 매개변수가 Uri를 String으로 파싱한 것이라는 사실을 알고 있어야 합니다. 이렇게 되면서 Domain이 간접적으로나마 안드로이드에 대해 알고 있다고 말할 수도 있을 것입니다. 더해서 프로젝트를 처음 보는 개발자가 해당 인자에 Uri.toString()을 담고, Repository에서 Uri.parse(imageUri)를 수행해야 하는지 모를 수 있습니다.

결과적으로 말씀드린 두 가지 방식 모두 한 가지의 문제점을 안고 있습니다. 현재 두 프로젝트는 제가 ViewModel의 리팩터링을 제안한 뒤로 변화해 현재는 각각 다른 모습을 띠고 있습니다. 두 프로젝트가 각각 다른 방식을 채택하면서 두 방식 모두 사용되고 있는 것이죠.

이렇듯 정답은 없으며 이 글을 읽는 여러분이 더 적합하다고 판단되는 방식으로 진행하시기를 바랍니다! 또한 더 좋은 방식이 있다면 추천해 주시면 감사합니다!

추가 내용

이제 글에서 하고자 하는 주된 이야기는 끝났습니다. 하지만 몇 가지만 추가로 얘기해 보고자 합니다. 글을 예전에 구성되었던 프로젝트의 코드에 맞춰서 진행했는데, 몇 가지 개선할 수 있는 부분이 있었으나 글을 진행하느라 넘어갔습니다.

MediaStore.Images.Media.DATA

우리가 파일 경로를 가져오기 위해 사용했던 이 컬럼은 사실 Deprecated 되었습니다.

공식문서

저도 글을 작성하면서 찾아보다가 이 부분에 대해 알게 되었습니다. 일반적으로 Deprecated 된 것들은 IDE에서 취소선을 그려 주는데 프로젝트에서 작성한 코드에서는 취소선을 볼 수 없었기 때문입니다.

다음은 공식문서의 내용입니다.

From Android 11 onwards, this column is read-only for apps that target R and higher. On those devices, when creating or updating a uri, this column’s value is not accepted. Instead, to update the filesystem location of a file, use the values of the DISPLAY_NAME and RELATIVE_PATH columns.

Android 11부터, R 버전 이상을 대상으로 하는 앱의 경우 이 칼럼은 읽기 전용입니다. 이러한 디바이스에서는 uri를 생성하거나 업데이트할 때 이 칼럼의 값은 허용되지 않습니다. 대신 파일의 파일 시스템 위치를 업데이트하려면 DISPLAY_NAME과 RELATIVE_PATH 칼럼의 값을 사용하십시오.

Deprecated 된 것을 계속 사용할 수는 없으므로 새로운 방식을 알아봅시다. 다음 예시 코드처럼 캐시 파일을 통해 Uri 객체로 File 객체를 생성할 수 있습니다. (캐시 파일, 파일 스트림) 임시로 사용할 캐시 파일을 생성하고 Uri로 Bitmap을 만들어 저장합니다. 그리고 해당 파일을 MutlipartBody.Part로 변환해서 전송하면 됩니다. Uri만 알아도 Bitmap은 생성할 수 있으므로 절대 경로 없이 업로드할 파일을 생성할 수 있습니다!

private fun makeImageFile(uri: Uri): File {
    // 파일 스트림으로 uri로 접근해 비트맵을 디코딩
    val bitmap = contentResolver.openInputStream(uri).use {
        BitmapFactory.decodeStream(it)
    }

    // 캐시 파일 생성
    val tempFile = File.createTempFile("파일명", ".jpeg", cacheDir) ?: FILE_EMPTY

    // 파일 스트림을 통해 파일에 비트맵 저장
    FileOutputStream(tempFile).use {
        bitmap.compress(Bitmap.CompressFormat.JPEG, 100, it)
    }
    return tempFile
}

File을 거치지 않고 RequestBody 만들기

글에서 내내 Uri → File → RequestBody 의 과정을 거쳤습니다. 그러나 Uri → RequestBody의 과정도 가능합니다. 직접 RequestBody를 구현하면 됩니다.

RequestBody를 상속받으면 두 개의 추상 함수를 구현해야 합니다. 즉, 이것만 구현하면 RequestBody를 만들 수 있습니다.

class RequestBodyImpl : RequestBody() {
    override fun contentType(): MediaType? {
        TODO("Not yet implemented")
    }

    override fun writeTo(sink: BufferedSink) {
        TODO("Not yet implemented")
    }
}

바로 코드를 보겠습니다.

class ContentUriRequestBody(
    context: Context,
    private val uri: Uri,
) : RequestBody() {
    private val contentResolver = context.contentResolver

    private var fileName = ""
    private var size = -1L

    init {
        contentResolver.query(
            uri,
            arrayOf(MediaStore.Images.Media.SIZE, MediaStore.Images.Media.DISPLAY_NAME),
            null,
            null,
            null,
        )?.use { cursor ->
            if (cursor.moveToFirst()) {
                size = cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Images.Media.SIZE))
                fileName =
                    cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DISPLAY_NAME))
            }
        }
    }

    fun getFileName() = fileName

    override fun contentLength(): Long = size

    override fun contentType(): MediaType? =
        contentResolver.getType(uri)?.toMediaTypeOrNull()

    override fun writeTo(sink: BufferedSink) {
        contentResolver.openInputStream(uri)?.source()?.use { source ->
            sink.writeAll(source)
        }
    }
}

이런 식으로 Uri로 RequestBody를 바로 구현하면 파일 경로도, File 객체도 만들 필요가 없습니다. 콘텐츠 길이, 미디어 타입을 넘기고 Uri로 InputStream열어 파일을 가져옵니다. 두 프로젝트 중 Repository에서 처리하는 방법을 선택한 프로젝트 ‘ZOOC’의 경우 위의 ContentUriRequestBody 객체를 다음과 같이 사용하고 있습니다.

class DefaultDiaryRepository(
    private val context: Context,
    private val service: DiaryService,
) : DiaryRepository {
    // ...
    
    override suspend fun postDiary(
        title: String,
        content: String,
        imageUri: String,
    ): Result<Unit> {
		// ...
       
        val uri = Uri.parse(imageUri)
        val imageRequestBody = ContentUriRequestBody(context, imageUri)
        val imagePart = MultipartBody.Part.createFormData("imageFile", file.name, requestBody)

        service.postDiary(titlePart, contentPart, imagePart)
    }
}

프로젝트의 구조가 ContentUriRequestBody 객체를 사용할 수 있는 상태라면 사용해 보는 것을 추천 드립니다!

조금 더 개선된 구조

앞서 말씀드렸던 “Repository에서 처리하기 (Data Layer에서 처리하기)“에서 생각을 조금 더한 구조를 보여드리려고 합니다.

우선 Uri를 String으로 변환해서 옮기는 것에서 오는 혼동을 방지하기 위해 래핑 객체를 만들었습니다. (래핑 객체를 만들고 팀 내에서 약속하면 혼동을 방지할 수 있다고 생각합니다) 또 파일이나 Uri를 생성하는 역할을 분리하여 ContentRepository를 만들고 DiaryRepository에서 사용합니다. 또 RequestBody나 MultipartBody.Part로 변환하여 서버에 전송하는 행동은 RemoteDiaryDataSource로 옮겼습니다. ContentRepository는 다른 Repository에서도 사용 가능하게 되면서 재사용성도 증가했습니다.

data class TecobleUri(uri: String)

interface DiaryRepository() {
    // ...
    
    suspend fun postDiary(
        title: String,
        content: String,
        imageUri: TecobleUri,
    )
}

interface ContentRepository {
    fun getContent(uri: TecobleUri): File
}


class DefaultDiaryRepository(
    private val contentRepository: ContentRepository,
    private val remoteDiaryDataSource: RemoteDiaryDataSource,
): DiaryRepository {
    override suspend fun postDiary(
        title: String,
        content: String,
        imageUri: TecobleUri,
    ): Result<Unit> {
		// ...
       
        val imageFile = contentRepository.getContent(imageUri)
        remoteDiaryDataSource.postDiary(title, content, imageFile)
    }
}

글을 마치며

이렇게 multipart/form-data를 통한 이미지 전송 방법과 그 과정들이 어디에서 일어나는 것이 좋을지에 대해 이야기했습니다. 각각의 장단점이 있으니 더 적합하다고 생각하시는 방식을 사용해 주시면 될 것 같습니다. 저는 개인적으로 Data Layer에서 수행해 주는 후자가 더 적합하다고 생각합니다.

ContentResolver가 하는 모든 행동이 Presentation Layer가 아닌 Data Layer에 어울린다고 생각하기 때문입니다. 또한 Activity에서 작성한다고 한다면 사진을 다루는 여러 Activity에서 중복 코드가 발생할 것입니다. (물론 다른 객체로 빼볼 수도 있습니다) 이 모든 것들은 제 개인적인 견해일 뿐 다른 의견도 궁금하고 존중합니다! 읽어 주셔서 감사합니다!

공간 데이터 개념부터 적용까지

Tue, 24 Oct 2023 12:00:00 GMT

들어가며

성수동에 위치한 힙하고 트렌디한 카페를 쉽게 찾을 수 있는 요즘카페 서비스에 지도 기능을 추가하기로 했다.

기능 개발을 위해 공부하던 중 공간 데이터에 대해 알게 되었다..

공간 데이터는 좌표계를 통한 지리적인 위치 데이터를 의미한다. 좌표계라는 단어가 굉장히 생소하게 느껴지지만 한 번쯤은 들어봤을 위도와 경도 또한 가장 일반적으로 사용되는 좌표계 중 하나다. 좌표계는 지구 상의 특정 위치를 정확하게 나타내기 위해 사용되는 시스템으로, 각각의 목적에 따라 여러 종류가 존재한다. 이 글에서는 위도/경도 좌표계를 사용하는 공간 데이터를 다루고 있다.

공간 데이터에 대해 학습하고 적용하는 과정에서 수많은 시행착오를 거쳤다. 처음 접해본 개념인데다가, 레퍼런스도 여기저기 흩어져 있어 여간 애를 먹은 게 아니었다. 한 번에 정리된 글이 있으면 좋을 것 같아, 학습한 내용을 공유하고자 한다.

1. MySQL의 공간 데이터

1-1. 공간 데이터 타입

MySQL에서 제공하는 공간 데이터의 종류는 총 7가지이다. 단일 타입으로는 Point, LineString, Polygon 세 가지가 있고, 나머지 타입들은 이 세 가지 타입의 조합이다.

Point : 좌표 공간의 한 지점

LineString : 다수의 Point를 연결해 주는 선분

Polygon : 다수의 선분이 연결되어 닫혀있는 상태

각각의 컬럼에는 당연하게도 알맞은 데이터 타입만 입력할 수 있지만, geometry 타입에는 모든 공간 데이터 타입의 입력이 가능하다.

1-2. 공간 함수

공간 데이터들은 공간 함수를 통해 활용할 수 있다. 공간 함수에 대해선 공식 문서 에 잘 소개되어 있으니, 여기서는 대표적으로 사용 되는 몇 가지의 함수만 확인하려 한다.

함수명	설명
ST_GeomFromText(WKT[, SRID])	WKT와 SRID를 통해 geometry를 생성한다.
ST_Buffer((Multi) Point, Radius)	Point(또는 MultiPoint)로 부터 Radius를 반지름으로 갖는 원을 그린다.
ST_Contains(geom(a), geom(b))	b가 a에 포함되어 있으면 1을 반환, 아니면 0을 반환.
ST_Within(geom(a), geom(b))	a가 b에 포함되어 있으면 1을 반환, 아니면 0을 반환.(ST_contains와 인자가 반대)
ST_Distance(geom(a), geom(b))	a와 b 사이의 거리

WKT(Well-Known-Text)는 공간 데이터를 텍스트 형식으로 표현하는 방법 중 하나이다. WKT는 기하학적인 객체를 설명하기 위해 사용되며, 다양한 유형의 공간 개체를 나타낼 수 있다.
예) POINT(80 110) , LINESTRING(0 0, 10 10) , POLYGON(0 0, 10 10, 20 20, 0 0)

ST_

ST_ 라는 prefix가 붙어있는데, Spatial의 약어이다. 공간 함수라는 것을 명시적으로 보여주고, 다른 함수들과 네이밍이 겹치지 않게끔 하는 역할을 한다.

1-3. SRID

공간 데이터를 설명하며 빼놓을 수 없는 개념 중 하나인, SRID(Spatial Reference Identifier)는 데이터의 좌표계를 구분할 수 있는 식별 코드이다.
가장 흔하게 사용되는 값은 4326으로 위도(Latitude)와 경도(Longitude)를 사용하여 위치를 표현하는 WGS84 좌표계를 의미한다. 이는 GPS 및 다양한 GIS 솔루션에서 널리 사용된다고 한다.

MySQL에 입력되는 데이터에도 이 SRID 값을 지정해 줄 수가 있다.

mysql> DESC sridTest;
+-------+--------+------+-----+---------+----------------+
| Field | Type   | Null | Key | Default | Extra          |
+-------+--------+------+-----+---------+----------------+
| id    | bigint | NO   | PRI | NULL    | auto_increment |
| point | point  | YES  |     | NULL    |                |
+-------+--------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> INSERT INTO sridTest (point) VALUES (ST_PointFromText('POINT(10 20)'));
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO sridTest (point) VALUES (ST_PointFromText('POINT(10 20)', 4326));
Query OK, 1 row affected (0.00 sec)

mysql> select id, ST_SRID(point) AS SRID FROM sridTest;
+----+------+
| id | SRID |
+----+------+
|  2 |    0 |
|  3 | 4326 |
+----+------+
2 rows in set (0.00 sec)

위의 그림에서 첫 번째 데이터는 SRID 값을 지정해 주지 않아 기본값인 0으로 입력이 되었다. 문제는 MySQL에는 한 번 입력된 데이터의 SRID 값을 수정할 수 있는 방법이 없다.
즉, 해당 데이터를 지우고 다시 입력하거나, UPDATE 쿼리를 사용해야 한다.

한두 개의 데이터야 직접 수정하면 된다지만, 잘못 작성된 쿼리로 입력된 데이터가 100개, 1000개, 10000개가 된다면, 이를 수정하는 것은 제법 귀찮은 일이 될 것이 분명하다.
귀찮은 일의 발생을 막기 위해 처음부터 값을 잘 입력하는 것이 매우 중요한데, Table의 컬럼속성에 SRID 값을 설정해 준다면, 이러한 실수를 미리 방지할 수 있다.

CREATE TABLE sridTest2 (
	id bigint auto_increment primary key,
	point point SRID 4326
);

이런 식으로 Table 생성 시 SRID 값을 지정해 주거나,

ALTER TABLE sridTest2 MODIFY COLUMN point point SRID 4326;
ALTER TABLE [테이블명] MODIFY COLUMN [컬럼명] [컬럼유형] SRID [SRID 코드번호];

ALTER TABLE을 통해 SRID 값을 변경해 줄 수 있다.
물론, 두 번째 방법은 하나의 데이터라도 컬럼에 지정하려는 SRID값과 일치하지 않는다면 에러가 발생한다.

위와 같은 방법으로 컬럼에 직접 SRID 값을 지정해 주었다면, 데이터 삽입 시 다른 SRID 값을 입력하려 하면 에러가 발생한다.

mysql> INSERT INTO sridTest2 (point) VALUES (ST_PointFromText('POINT(10 20)'));
  
ERROR 3643 (HY000): The SRID of the geometry does not match the SRID of the column 'point'. 
The SRID of the geometry is 0, but the SRID of the column is 4326. 
Consider changing the SRID of the geometry or the SRID property of the column.

컬럼에 지정한 SRID 값과 일치하는 값을 입력해주면 정상적으로 데이터가 삽입된다.

mysql> INSERT INTO sridTest2 (point) VALUES (ST_PointFromText('POINT(10 20)', 4326));
Query OK, 1 row affected (0.01 sec)

mysql> SELECT id,
       ST_X(point) AS latitude,
       ST_Y(point) AS longitude,
       ST_SRID(point) AS SRID
       FROM sridTest2;
+----+----------+-----------+------+
| id | latitude | longitude | SRID |
+----+----------+-----------+------+
|  1 |       10 |        20 | 4326 |
+----+----------+-----------+------+
1 row in set (0.00 sec)

2. 공간 인덱스

데이터베이스에서 데이터를 빠르게 검색하고 조회 성능을 향상하기 위해 인덱스를 사용한다. 공간 데이터도 마찬가지로 조회 성능 향상을 위해 인덱스를 사용할 수 있다.

공간 인덱스를 거는 방법은 매우 쉽다. 일반적으로 인덱스를 거는 것처럼 명령어 한 줄 이면 해결된다.

CREATE SPATIAL INDEX idx_point ON sridTest2(point);
CREATE SPATIAL INDEX [인덱스 명] ON [테이블 명](컬럼 명);

mysql> SHOW INDEXES FROM sridTest2;
+-----------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table     | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+-----------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| sridTest2 |          0 | PRIMARY   |            1 | id          | A         |           1 |     NULL |   NULL |      | BTREE      |         |               | YES     | NULL       |
| sridTest2 |          1 | idx_point |            1 | point       | A         |           1 |       32 |   NULL |      | SPATIAL    |         |               | YES     | NULL       |
+-----------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
2 rows in set (0.00 sec)

생성된 인덱스를 확인해 보면 Index_type이 SPATIAL로 생성된 것을 확인해 볼 수 있다. 이대로도 충분히 사용은 가능하지만 그래도 이왕이면, 공간 인덱스의 원리를 얕게나마 이해해 보자.

2-1. MBR

MySQL의 공간 인덱스는 MBR의 포함관계를 바탕으로 트리 구조를 생성하여 이용하기에, MBR에 대한 이해가 필수적이다.

이름이 거창해서 그렇지 그냥 사각형을 그리는 방법이다. MBR(Minimum Bounding Rectangle)의 약어로 최소 경계 사각형을 의미한다. 글로 하는 설명보다는 그림을 보면 단박에 이해가 된다.

위 같은 도형들(점, 선분, 다각형)이 있을 때 각각을 감싸는 최소크기의 사각형을 그리면 다음과 같다.

여기서 보이는 빨간색 사각형이 각각의 도형에 대한 MBR이다.

2-2. R-Tree

인덱스가 B-Tree를 이용하는 것과 마찬가지로, 공간 인덱스는 R-Tree라는 트리 형태의 자료구조를 활용한다. R-Tree는 위에서 언급하였듯, MBR의 포함 관계를 트리로 표현한 것이다. 삽입 및 삭제 과정에서도 B-Tree와 마찬가지로 동적으로 재구성되어 leaf node들의 균형을 유지한다. 또한, 탐색 속도를 향상하기 위해 자식 노드들의 적정 개수를 유지하며, 삽입 과정에서 MBR의 크기가 작게 확장되는 분기를 선택한다.

균형유지
root node부터 모든 leaf node까지의 거리가 동일하게 유지된다.

R-Tree의 네이밍 유래
Rectangle(사각형) 과 B-Tree의 Tree를 섞어서 만들어진 네이밍이라고 한다.

우선은 MBR의 포함관계가 정확히 무엇을 의미하는지 그림을 통해 알아보자.

위의 그림과 같이 성수역 쪽에 몇 개의 공간 데이터를 입력했다고 가정해보자.

지도를 걷어 내고, 각각의 데이터들에 MBR을 그려보면 위와 같은 그림이 나온다. 그리고 이렇게 생성된 MBR들을 포함하는 MBR을 그리다 보면, 다음과 같은 그림이 나온다.

그리고 이 MBR들의 포함관계를 Tree 형태로 표현한 것이 R-Tree이다.

최상위 MBR인 A와 B가 R-Tree의 루트 노드에 저장되는 정보이며, 차상위 MBR인 C,F,D,E브랜치 노드가 된다. 그리고 각각의 데이터의 MBR이 리프노드에 저장된다.

2-2-1. Insert

새로운 데이터 X 가 추가되었다. 데이터가 추가되는 경우, MBR이 적게 확장되는 브랜치 노드를 따라 데이터가 삽입된다.

X 가 추가된 MBR 그림을 다시 보면, A MBR에는 X가 포함되어 있지 않아A MBR의 크기가 확장되어야 한다.
그러나 B MBR에는 이미 X 가 포함되어 있으므로 크기의 확장이 필요하지 않다.
D MBR과 E MBR의 경우에도 마찬가지의 방식으로 결정되어 위와 같이 데이터가 추가된다.

2-2-2. Split

이번에는 어떤 MBR에도 속하지 않는 Y데이터가 추가되었다.
위의 Insert 에서 설명했듯이 가장 적은 확장이 일어나는 MBR을 따라 데이터가 삽입된다.

그런데 만약 트리의 최대 노드 개수(M)가 4이고, 최소 노드 개수(m)가 2인 경우라면, E 노드에서 OverFlow가 발생했기에 트리의 분할이 일어나야 한다.

분할의 동작 순서는 다음과 같다.

분할이 필요한 노드(E) 의 자식 노드(O, P, Q, X, Y) 중 분할 알고리즘에 따라 두 개의 노드가 선택된다.
기준이 아닌 나머지 노드들은 분할 알고리즘에 따라 1에서 선택된 두 개의 노드 중의 하나를 선택한다.
2의 결과를 통해 노드를 분할한다.

분할 기준은 다양하지만, 대부분 Quadratic Split 방식이 일반적으로 사용된다.

R-Tree 분할 알고리즘

Plane Sweep

>   단순 추가 순으로 일정 비율을 새로운 노드에 삽입한다.

Linear Split

>   한 축 기준으로 가장 멀리 있는 두 노드를 A, B로 하고 나머지 노드는 두 노드에 추가할 때 증가하는 MBR이 적은 곳으로 삽입한다.

Quadratic Split

>  한 MBR에 속하면 낭비되는 공간이 가장 큰 두 노드를 A, B로 하고, 나머지 노드는 두 노드에 추가할 때 증가하는 MBR의 넓이가 적은 순서대로 찾아 삽입한다.

Exponential Split

>  모든 분할 경우에 대해 계산한 후 공간상 가장 효율적인 분할을 선택한다.

Quadratic Split방식에 따라, P 와 Y 를 A, B로 지정하고 MBR을 확장해 나가면 다음과 같이 트리가 분할된다.

2-2-3. Search

검색의 경우도 마찬가지로 검색하려는 공간 데이터가 포함된 MBR들을 따라서 검색한다.

위의 그림에서 분홍색 원안에 포함되어있는 모든 데이터를 반환하는 경우를 가정해보자.

분홍색 원에 A MBR 과 B MBR이 모두 걸쳐 있기 때문에, A 와 B 모두 확인을 해본다.
A 의 자식 노드들 중에는 분홍색 원의 범위에 포함되는 MBR이 없으므로 A 브랜치의 검색은 종료된다.
반면, B 의 자식 노드들 중에는 D 가 범위에 포함되어 있다.
그리고 D의 자식 노드 중 M이 범위에 포함되기에 M의 데이터를 반환한다.

2-3. 인덱스 적용 안 되는 경우

어느정도 공간 인덱스를 이해한 것 같으니, 실행계획을 통해 인덱스가 잘 적용되는지 확인해보자.
인덱스가 정상적으로 등록되어 있지만, 몇몇 경우에 등록된 인덱스가 적용되지 않는 경우가 있다.
만약, 인덱스 등록은 정상적으로 이뤄졌으나 실행계획을 확인했을 때 인덱스가 적용되지 않는다면, 아래 항목들을 확인해보자.

2-3-1. 공간 함수 오용

대표적인 공간 데이터의 사용 예시는 기준점으로부터 반경 nKM 내에 있는 데이터를 검색하는 경우이다.
공간함수를 사용해서 예시의 결과를 반환하는 쿼리를 작성해 보자.

SELECT * FROM example WHERE ST_DISTANCE(point, ST_GeomFromText('POINT(10 20)', 4326)) <= 5000;

ST_DISTANCE 함수를 활용해서 point 와 기준점(10, 20)의 거리가 5KM 이하인 모든 데이터를 가져오는 쿼리이다.
하지만 이 쿼리의 실행 계획을 확인해 보면 type이 ALL인 것을 확인할 수 있는데, 이는 곧, 인덱스가 적용되지 않았다는 의미이다.

mysql> EXPLAIN SELECT * FROM example WHERE ST_DISTANCE(point, ST_GeomFromText('POINT(10 20)', 4326)) <= 5000;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | example | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | Using where |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.01 sec)

R-Tree는 MBR들의 포함관계를 이용하여 만들어진 트리라고 했다.
하지만 위의 ST_DISTANCE를 사용한 쿼리는 포함관계를 확인하는 것이 아니라, 모든 데이터와 기준점과의 거리를 계산하여 반환하는 쿼리이다.

이러한 케이스는 ST_DISTANCE 대신 ST_CONTAINS와 ST_BUFFER를 활용하면 쉽게 해결할 수 있다.

SELECT * FROM example WHERE ST_CONTAINS(ST_BUFFER(ST_GeomFromText('POINT(10 20)', 4326), 5000), point);

ST_BUFFER 는 첫 번째 인자를 중심점으로 반지름이 두 번째 인자인 원을 그리는 함수이고,
ST_CONTAINS 는 첫 번째 인자가 두 번째 인자를 포함하는지 여부를 확인하는 함수이다.
즉, 위의 쿼리는 POINT(10 20)을 중심으로 반경 5KM 내에 있는 데이터를 조회하는 쿼리이다.

수정한 쿼리는 공간 데이터 간의 포함관계를 이용하므로, 인덱스가 잘 적용되는 것을 확인할 수 있다.

mysql> EXPLAIN SELECT * FROM example WHERE ST_CONTAINS(ST_BUFFER(ST_GeomFromText('POINT(10 20)', 4326), 5000), point);
+----+-------------+-----------+------------+-------+---------------+-----------+---------+------+------+----------+-------------+
| id | select_type | table     | partitions | type  | possible_keys | key       | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------+------------+-------+---------------+-----------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | sridTest2 | NULL       | range | idx_point     | idx_point | 34      | NULL |    1 |   100.00 | Using where |
+----+-------------+-----------+------------+-------+---------------+-----------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

2-3-2. SRID 미 적용

두 번째 이유는 어딘가에 SRID가 적용되지 않았거나 서로 상이한 값을 사용했기 때문이다. 다음 세 군데에 적용한 SRID 값이 모두 일치해야 인덱스가 정상적으로 동작한다.

테이블의 컬럼 속성
검색 쿼리의 SRID
삽입된 데이터

1-3 에서 얘기했듯, 테이블의 컬럼 속성에 SRID 값을 적용할 수 있다. 이 부분에 SRID 값이 적용되지 않았다면, 인덱스는 적용되지 않는다.

또한 검색 쿼리에 실수로 SRID를 미적용한 경우 역시 인덱스가 적용되지 않는다.

SELECT * FROM example WHERE ST_CONTAINS(ST_BUFFER(ST_GeomFromText('POINT(10 20)'), 5000), point);

위에서 사용한 쿼리를 예로 들어보자면, ST_GeomFromText 함수에 두 번째 인자로 SRID 값이 빠져있다. 이런 경우에는 SRID값이 default인 0으로 지정되는데, 이때 point 데이터의 SRID값이 0이 아니라면 인덱스는 적용되지 않는다. 포함관계를 이용한 검색의 경우에는 SRID 값이 일치해야 인덱스가 적용된다.

마지막으로 삽입된 데이터들이 같은 SRID 값을 갖고있는 지 확인해 봐야 한다.

mysql> SELECT DISTINCT ST_SRID(point) FROM example;
+----------------+
| ST_SRID(point) |
+----------------+
|              0 |
|           4326 |
+----------------+
2 rows in set (0.00 sec)

위 쿼리를 실행했을 때 만약 예시와 같이 row가 두 개 이상 나온다면 데이터들의 SRID값이 통일되지 않았다는 뜻이다. 안타깝게도 MySQL에서는 데이터의 SRID 값을 일괄적으로 변경할 수 있는 방법이 없다.
일일이 UPDATE문을 작성하거나, DELETE 후 새롭게 INSERT를 해줘야 한다.

위 쿼리가 2개 이상의 row를 반환한다면, 아.. 오늘은 야근이구나.. 라고 생각하면 된다.

하지만 다행히도, 1번의 내용인 컬럼 속성에 SRID 값이 설정되었다면, 나머지 2번 3번의 경우는 신경 쓰지 않아도 된다. MySQL은 기본적으로 STRICT SQL MODE가 활성화되어있기에 상이한 SRID 값의 삽입과 포함관계를 이용한 검색에 에러가 발생하기 때문이다. 하지만 항상 만약이란 건 존재하기에 인덱스가 적용되지 않는다면, 꼭 한 번 확인을 해보자.

3. JPA로 공간 데이터 사용하기

공간 데이터와 충분히 친해진 것 같은 기분이 든다.
hibernate 5.0 부터 Hibernate ORM애 정식 라이브러리가 된 Hibernate-spatial을 이용하여 JPA로 공간 데이터의 입/출력을 다뤄보자.

Hibernate 공식문서와 Baeldung을 함께 참고하면 좋다.

3-1. 설정

공간 데이터를 사용하기 위해서는 의존성을 하나 추가해야 한다.

implementation 'org.hibernate.orm:hibernate-spatial:{hibernate vesion}'

hibernate-spatial의 버전은 현재 프로젝트에 적용된 hibernate의 버전과 동일하게 작성해 주면 된다.
만약 사용하는 hibernate의 버전이 6.0 이전의 버전이라면, Dialect 설정을 따로 해주어야 한다.

spring.jpa.database-platform = org.hibernate.spatial.dialect.mysql.MySQL8SpatialDialect

hibernate 6.0 부터는 spatial 관련 Dialect는 모두 Deprecated이다.

Hibernate-spatial

Point, LineString 등의 데이터타입들은 java 표준 라이브러리도 아니고 JDBC의 사양도 아니다.
그렇기에 공간 데이터를 사용하기 위해서는 JTS라는 외부 라이브러리를 이용해서 공간 데이터를 사용해야 한다.

hinernate-spatial는 내부에 JTS 와 geolatte-geom 을 포함하고 있다.

3-2. JTS 공간 데이터 다루기

hibernate spatial은 JTS를 사용하여 공간 데이터에 대한 타입을 지원한다.
Point, LineString, Polygon 등의 공간 데이터를 사용하기 위해서는 JTS에서 제공하는 데이터 타입을 import해야 한다.

import org.locationtech.jts.geom.Point;

@Entity(name = "example")  
public class Coordinate {  
  
    @Id  
    @GeneratedValue(strategy = GenerationType.IDENTITY)  
    private Long id;  
  
    private Point point;
}

가장 흔하게 사용되는 Point와 Polygon을 생성해보면, 다른 타입에 대한 사용은 금새 익힐 수 있다.

공간 데이터를 생성하는 방법에는 크게 두가지가 있다.
첫 번째는 GeometryFactory 를 사용하는 것이고,
두 번째는 WKTReader를 사용하는 것이다.

WKT에 대한 설명은 1-2를 참고

@Test  
void createPointWithFactory() {  
    //given  
    final GeometryFactory geometryFactory = new GeometryFactory();  
    final Coordinate coordinate = new Coordinate(180, 90);  
  
    //when  
    final Point point = geometryFactory.createPoint(coordinate);  
    point.setSRID(4326); // SRID 설정  
  
    //then  
    assertThat(point.getX()).isEqualTo(180);  
    assertThat(point.getY()).isEqualTo(90);  
}  

@Test  
void createPointWithWKT() throws ParseException {  
    //given  
    final WKTReader wktReader = new WKTReader();  
    final Geometry read = wktReader.read("POINT(180 90)");  
  
    //when  
    final Point point = (Point) read;  
    point.setSRID(4326);  
  
    //then  
    assertThat(point.getX()).isEqualTo(180);  
    assertThat(point.getY()).isEqualTo(90);  
}

WKTReader를 사용하는 방식은 WKT 를 읽어서 공간 데이터를 생성하는데, WKT는 모든 공간 데이터 타입의 입력이 가능하다. 그렇기 때문에 read()의 반환 값이 추상클래스인 Geometry타입을 반환하기에 다운캐스팅이 필요하다.
또한, WKT를 파싱하는 과정에서 발생할 수 있는 ParseException도 처리해줘야 하기에 사용하기에 번거롭기 때문에 개인적으로는 GeometryFactory를 사용하는 방식을 선호한다.

어떠한 방식을 사용하든 꼭 한 가지 주의해야 할 점이 있다.
SRID 값이 4326이라는 가정하에, MySQL 에서 사용하는 WKT의 X, Y 값은 각각 위도와 경도이다.
예시) POINT(위도 경도)

그런데 new Coordinate()의 인자와 WKTReader가 읽는 WKT 모두 경도, 위도 순이다.
예시) new Coordinate(경도, 위도), wktReader.read("POINT(경도 위도)")

SRID 값에 따라 X, Y가 각각 의미하는 값이 달라질 수 있기에 이런 차이가 발생한 듯하다.

그런데 데이터의 삽입과정과 일반적인 조회에서는 X, Y에 그 어떤 값이 들어가도 예외가 발생하지 않는다.

@Test
void selectWithSpatialException() {
    //given
    final Point point = geometryFactory.createPoint(new Coordinate(10, 110));
    point.setSRID(4326);
    final CoordinateEntity coordinateEntity = repository.save(new CoordinateEntity(point));

    //when
    final CoordinateEntity saved = repository.findById(coordinateEntity.getId()).get();

    //then
    assertSoftly(softAssertions -> {
        assertThat(saved.getPoint().getX()).isEqualTo(10);
        assertThat(saved.getPoint().getY()).isEqualTo(110);
    });
}

예외는 MySQL에서 ST_X 또는 ST_Y를 통해 point의 값을 위도 경도로 변환하려 할 때 발생한다.

@Query(value = """
        SELECT co.id AS id, st_x(co.point) AS latitude, st_y(co.point) AS longitude
        FROM example AS co
        WHERE co.id = :id
        """)
Optional<CoordinateDto> findCoordinatesById(@Param("id") final Long id);

공간함수인 ST_X 와 ST_Y 를 이용해 위도, 경도 값을 변환하여 반환받는 쿼리이다.
JPA에서 사용 가능한 공간함수에 대한 설명은 3-3에서 조금 더 자세히 다룬다.

위 메서드를 실행시켜보면, 위도 범위를 벗어났다는 예외가 발생한다.

Caused by: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: 
A parameter of function st_x contains a geometry with latitude 110.000000, 
which is out of range. It must be within [-90.000000, 90.000000].
	at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:104)
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:916)
	at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:972)
	at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
	at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)
	at org.hibernate.sql.results.jdbc.internal.DeferredResultSetAccess.executeQuery(DeferredResultSetAccess.java:217)
	... 111 more

데이터를 삽입하는 순간에는 문제가 발생하지 않지만, 공간함수를 사용한 조회에서는 예외가 발생할 수 있다는 것은 문제사항에 대한 인지를 늦추게 된다. 이를 방지 하기 위해 공간 데이터를 사용하는 엔티티를 생성하는 시점에 위도 경도 범위에 따른 검증 절차를 추가해주는 것이 바람직하다고 생각한다.

다음은 Polygon 을 생성하는 코드이다.

@Test  
void createPolygonWithFactory() {  
    //given  
    final GeometryFactory geometryFactory = new GeometryFactory();  
    final Coordinate[] coordinates = new Coordinate[]{  
            new Coordinate(0, 0),  
            new Coordinate(10, 0),  
            new Coordinate(10, 10),  
            new Coordinate(0, 10),  
            new Coordinate(0, 0),  
    };  
    
    //when  
    final Polygon polygon = geometryFactory.createPolygon(coordinates);  
    polygon.setSRID(4326); // SRID 설정  
  
    //then  
    assertThat(polygon.getCoordinates()).hasSize(5);  
}  
  
@Test  
void createPolygonWithWKT() throws ParseException {  
    //given  
    final WKTReader wktReader = new WKTReader();  
    final Geometry read = wktReader.read("POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))");  
  
    //when  
    final Polygon polygon = (Polygon) read;  
    polygon.setSRID(4326);  
  
    //then  
    assertThat(polygon.getCoordinates()).hasSize(5);  
}

Polygon을 생성할 때는 주의해야 할 점들이 있다.

마지막 좌표는 항상 시작점 이어야 한다. Polygon은 다각형의 모양인데, 마지막 좌표가 시작점이 아니라면 닫혀있는 형태가 아니게 된다.
구멍 뚫린 Polygon이 생성 가능하다. Polygon 내부에 구멍이 뚫려 튜브 또는 도넛 형태의 Polygon을 생성 할 수 있다.

GeometryFactory 에서는 구멍을 위해 두 번째 인자로 LinearRing[] 을 받는다.

public Polygon createPolygon(LinearRing shell, LinearRing[] holes) {  
  return new Polygon(shell, holes, this);  
}

위에 내가 사용한 예시처럼 Coordinate[] 하나만 인자로 사용하게 되면 구멍이 없는 Polygon이 생성된다.

public Polygon createPolygon(Coordinate[] shell) {  
  return createPolygon(createLinearRing(shell));  
}

public Polygon createPolygon(LinearRing shell) {  
  return createPolygon(shell, null);  
}

WKT에서는 POLYGON((0 0, 10 0, 10 10, 0 10, 0 0), (2 2, 2 4, 4 4, 4 2)) 이런 방식으로 구멍이 뚫린 Polygon을 생성할 수 있다.

위에 내가 사용한 예시처럼 하나의 인자만 넣어준다면, 구멍이 없는 Polygon이 생성된다.

3-3. 공간함수를 사용한 조회

기본적인 CRUD는 여타 다른 데이터와 동일하게 DataJpa가 마법처럼 해결해 준다.

@Entity(name = "example")  
public class Coordinate {  
  
    @Id  
    @GeneratedValue(strategy = GenerationType.IDENTITY)  
    private Long id;  
  
    private Point point;
}


public interface CoordinateRepo extends JpaRepository<CoordinateEntity, Long> {
}

우리가 궁금한 건

SELECT * FROM example WHERE ST_CONTAINS(ST_BUFFER(ST_GeomFromText('POINT(10 20)', 4326), 5000), point);

이런 쿼리를 적용하는 방법이다.

hibernate 공식 문서Table 5. Hibernate Spatial dialect function support 항목을 참고하면 공간 함수 별로 지원 여부가 표시되어 있는데, 다른 DB는 모르겠지만 MySQL은 5.6 이전 버전으로 표가 만들어져 있다.

표를 믿지 말고, MySQL 공식 문서와 비교를 해가며 사용해야 한다.

hibernate에서 지원하고 MySQL도 지원하는 공간 함수라면, JPQL이 사용 가능하다.

위에서 얘기한 예시를 이용해 기준점으로부터 반경 5Km 내에 위치한 데이터들을 가져오는 기능을 만들어 보자.

@Query("""  
        SELECT co  
        FROM example AS co  
        WHERE st_contains(st_buffer(:center, :radius), co.point)  
        """)  
List<CoordinateEntity> findAllWithInCircleArea(@Param("center") final Point center,  
                                               @Param("radius") final int radius);

MySQL의 ST_COTAINS와 ST_BUFFER는 hibernate에서 지원을 해주기 때문에 JPQL로 사용이 가능하다. 기준점과 반지름을 인자로 받아 쿼리를 생성한다.

@Test  
void findAllWithInCircle() {  
    //given  
    final Point point = geometryFactory.createPoint(new Coordinate(20, 10));  
    point.setSRID(4326);  
    final CoordinateEntity ce1 = repository.save(new CoordinateEntity(point));  
  
    final Point point2 = geometryFactory.createPoint(new Coordinate(40, 40));  
    point2.setSRID(4326);  
    repository.save(new CoordinateEntity(point2));  
  
    //when  
    final List<CoordinateEntity> allContainArea = repository.findAllWithInCircleArea(point, 5000);  
  
    //then  
    assertSoftly(softAssertions -> {  
        assertThat(allContainArea).hasSize(1);  
        assertThat(allContainArea.get(0)).isEqualTo(ce1);  
        assertThat(allContainArea.get(0).getPoint().getX()).isEqualTo(20);  
        assertThat(allContainArea.get(0).getPoint().getY()).isEqualTo(10);  
    });
}

테스트를 실행시켜 정상적으로 동작하는 것을 확인 할 수 있다.

나오며

MySQL 에서의 공간 데이터, 공간 함수, 공간 인덱스 그리고 DataJpa에서의 적용까지 알아보았다.

물론 공간 데이터와 관련된 복잡한 기능개발을 위해서는 부족한 글일 수 있다. 그래도 이 글이 낯설기만 했던 공간 데이터와 한 걸음 더 가까워질 수 있는 기회가 되면 좋겠다.

참고 자료

8.4 R-Tree 인덱스 | Real MySQL 8.0
11.4 Spatial Data Types | MySQL
12.16 Spatial Analysis Functions | MySQL
19. Spatial | Hibernate
Introduction to Hibernate Spatial | Baeldung

JPA Cascade는 무엇이고 언제 사용해야 할까?

Mon, 16 Oct 2023 12:00:00 GMT

들어가면서

JPA를 사용한 개발을 진행하면서 가장 많이 들었던 고민 중 하나는 JPA Cascade를 언제 사용해야 하는가 였습니다. ‘Cascade는 위험하니 조심해서 사용해야 한다!’ 와 같은 이야기도 많이 들었을뿐더러, 언제 어떻게 사용해야 할지 명확한 가이드라인을 찾기도 어려웠기 때문입니다. 따라서 이번 아티클에서 JPA Cascade에 대한 개념을 알아보고, 어떤 부분에서 위험하다고 일컬어지는 것인지까지 확인해 보도록 하겠습니다.

JPA Cascade란?

어떤 JPA 엔티티는 다른 엔티티의 존재에 깊게 연관되어 있기도 합니다. 가장 대표적인 예시로는 ‘댓글’과 ‘게시물’의 관계가 있습니다. ‘댓글’ 엔티티는 ‘게시물’ 엔티티가 없다면 존재 의의가 없기 때문입니다.

게시판 어플리케이션을 만들어 본다고 가정해 봅시다. 게시물을 삭제하는 비즈니스 로직은 어떻게 작성할 수 있을까요?

// PostService.java
@Transactional
public void deletePost(Long postId) {
    Post post = postRepository.findById(postId);
    List<Comment> comments = post.getComments();

    commentRepository.deleteAll(comments);
    postRepository.delete(post);
}

위와 같이 비즈니스 로직을 작성할 수 있을 것 같습니다. 그런데 여기서 몇 가지 의문점이 생깁니다.

게시물을 삭제할 때 댓글을 삭제하는 로직을 번거롭게 항상 작성해 줘야 할까?
실수로 댓글 삭제 로직을 빼먹을 수도 있지 않을까?
보다 좋은 방법이 없을까?

이런 문제점들을 해결하기 위해 JPA Cascade가 등장했습니다. JPA Cascade를 활용하면 ‘어떤 엔티티와 다른 엔티티가 밀접한 연관성이 있을 때’에 대한 관리가 매우 수월해집니다. 즉, A라는 엔티티에 어떤 작업을 수행했을 때, 그 작업이 연관된 B라는 엔티티도 이루어져야 한다면 JPA Cascade를 유용하게 사용할 수 있다는 의미입니다.

Cascade는 ‘폭포수가 흐르다’ 라는 사전적 의미를 갖고 있습니다.

JPA Cascade Types

JPA에서는 총 6개의 Cascade Type을 지원하는데, 예제 코드와 함께 하나씩 살펴보겠습니다.

예제 코드에서 사용하는 엔티티는 앞서 설명드렸던 ‘게시물(Post)‘과 ‘댓글(Comment)‘이며, 실습 환경은 다음과 같습니다. Post 엔티티의 물음표로 표시된 부분(CascadeType)을 바꿔가면서 실습을 진행할 예정입니다.

Post 엔티티

@Entity
public class Post {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @OneToMany(mappedBy = "post", cascade = ?)
    private List<Comment> comments = new ArrayList<>();

    // 생성자 생략

    public void addComment(Comment comment) {
        comments.add(comment);
    }
  ...
}

Comment 엔티티

@Entity
public class Comment {

    @Id
    @GeneratedValue
    private Long id;

    private String value;

    @ManyToOne
    @JoinColumn(name = "post_id")
    private Post post;
    ...
}

1. PERSIST

먼저 PERSIST 옵션을 살펴보도록 하겠습니다. 이는 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 옵션입니다.

Post post = new Post();
Comment comment = new Comment();

post.addComment(comment);

entityManger.persist(post); // post, comment 둘 다 영속화

2. MERGE

엔티티 상태를 병합할 때 연관된 엔티티도 함께 병합하는 옵션입니다.

Post post = new Post("this is post");
Comment comment = new Comment("this is comment");

post.addComment(comment);

entityManager.persist(post);
entityManager.persist(comment);

entityManager.flush();
entityManager.clear(); // 영속성 컨텍스트로부터 분리

post.setTitle("this is changed post");
comment.setValue("this is changed comment");

entityManager.merge(post); // post, comment 모두 변경사항 반영

3. REMOVE

엔티티를 제거할 때 연관된 엔티티들도 함께 제거합니다.

Post post = new Post();
Comment comment = new Comment();

post.addComment(comment);

entityManager.persist(post);
entityManager.persist(comment);

entityManager.remove(post); // post, comment 모두 삭제

4. REFRESH

엔티티를 새로고침할 때, 연관된 엔티티들도 함께 새로고침합니다. 여기서 ‘새로고침’ 한다는 말의 의미는 데이터베이스로부터 실제 레코드의 값을 즉시 로딩해 덮어씌운다는 의미입니다.

Post post = new Post("this is post");
Comment comment = new Comment("this is comment");

post.addComment(comment);

entityManager.persist(post);
entityManager.persist(comment);

entityManager.flush(); // 데이터베이스에 반영

post.setTitle("this is changed post");
comment.setValue("this is changed comment");

entityManager.refresh(post); // 데이터베이스로부터 post, comment의 원본 값 즉시 로딩

System.out.println(post.getTitle()); // this is post
System.out.println(comment.getValue()); // this is comment

5. DETACH

엔티티를 영속성 컨텍스트로부터 분리하면 연관된 엔티티들도 분리됩니다.

Post post = new Post("this is post");
Comment comment = new Comment("this is comment");

post.addComment(comment);

entityManager.persist(post);
entityManager.persist(comment);

entityManager.detach(post); // post, comment 모두 영속성 컨텍스트로부터 분리됨

6. ALL

위에서 언급한 모든 Cascade Type들이 적용됩니다.

JPA의 구현체인 Hibernate의 경우에는 추가로 3개의 Cascade Types(REPLICATE, SAVE_UPDATE, LOCK)을 지원하는데, 이번 아티클에서는 다루지 않겠습니다.

JPA Cascade가 위험한 이유

보시다시피 Cascade의 개념 자체는 어렵지 않습니다. 단순히 EntityManager의 어떤 작업이 수행되면 해당하는 작업을 연관된 엔티티들에 전파하겠다는 의미입니다. 그렇다면 ‘Cascade는 위험하다’라고 일컬어지는 이유는 무엇일까요?

연관관계 매핑과 함께 Cascade를 잘못 사용하게 되면 의도치 못한 결과를 불러올 수 있기 때문입니다.

1. 참조 무결성 제약조건 위반 가능성

CascadeType.REMOVE 혹은 CascadeType.ALL 옵션을 사용하면 엔티티 삭제 시 연관된 엔티티들이 전부 삭제가 되기 때문에 의도치 않게 참조 무결성 제약조건을 위반할 수도 있습니다.

참조 무결성 제약조건이란, 관계형 데이터베이스(RDB)에서 릴레이션(relation)은 참조할 수 없는 외래 키(foreign key)를 가져서는 안 된다는 조건을 의미합니다.

이를 위반하는 경우 데이터의 모순이 발생하게 됩니다.

예를 들어 아래와 같이 Comment와 Post가 다대일로 매핑이 된 상태이고 Comment 엔티티의 필드 post에 CascadeType.REMOVE를 지정한 상태라고 가정해 보겠습니다.

// Comment.java
@Entity
public class Comment {

    @ManyToOne(cascade = CascadeType.REMOVE)
    @JoinColumn(name = "post_id")
    private Post post;
    // ...생략
}

그렇다면 다음과 같은 문제가 발생할 수 있습니다.

@Test
void remove_bad_case() {
    Post post = new Post();
    Comment comment1 = new Comment();
    Comment comment2 = new Comment();

    comment1.setPost(post);
    comment2.setPost(post);

    postRepository.save(post);
    commentRepository.save(comment1);
    commentRepository.save(comment2);

    commentRepository.delete(comment1); // 관련된 엔티티(post)도 삭제

    assertThatThrownBy(() -> entityManager.flush())
            .isInstanceOf(PersistenceException.class);
    // comment2 가 참조하는 post 엔티티가 삭제되었으므로 외래키 관련 예외 발생
    // 만약 외래키 제약조건이 없다면 예외가 발생하지 않음
}

comment1을 삭제했을 뿐이지만, 연관된 엔티티인 post까지 삭제되었고 기존에 post를 참조하고 있던 comment2는 참조하고 있는 값이 사라져 참조 무결성 제약조건 위반 예외가 발생합니다.

flush 시점에 참조 무결성 제약조건 위반 예외가 발생하는 이유는 ‘영속성 컨텍스트’에서는 외래키 제약조건이 존재하지 않기 때문입니다. 데이터베이스에 직접 쿼리를 날리고 나서야 예외가 발생하게 됩니다.

실제 운영 환경에서는 개발 편의성을 위해 외래키 제약조건을 사용하지 않는 경우도 많은데, 그런 경우에는 예외도 발생하지 않아서 데이터 정합성에 문제가 생길 가능성이 큽니다.

2. 양방향 연관관계 매핑 시 충돌 가능성

양방향 연관관계 매핑을 하는 경우에도 유의해야 합니다. Comment, Post가 다대일 관계로 구성되어 있고 연관관계의 주인은 Comment라고 가정하겠습니다. 이 경우 아래와 같이 Post의 comments 필드에 CascadeType.PERSIST를 지정하는 경우 문제가 생길 수 있습니다.

// Post.java
@Entity
public class Post {

    @OneToMany(mappedBy = "post", cascade = CascadeType.PERSIST)
    private List<Comment> comments = new ArrayList<>();

테스트 코드를 통해 문제 상황을 보여드리면 다음과 같습니다.

@Test
void bidirectional_bad_case() {
    Post post = new Post();
    Comment comment1 = new Comment();
    Comment comment2 = new Comment();

    post.addComment(comment1);
    post.addComment(comment2);

    commentRepository.delete(comment1);
    postRepository.save(post);

    assertThat(commentRepository.existsById(comment1.getId())).isTrue();
  }

이상하게 commentRepository.delete(comment1) 을 호출했음에도 삭제가 되지 않는 모습을 확인할 수 있습니다. delete 를 호출해 comment1이 삭제된 상태에서 post를 save 하니 다시 comment1 값이 복원된 것입니다.

이처럼 영속화에 대한 관리 지점이 두 곳이면 데이터값을 예측할 수 없는 문제가 발생합니다. ‘영속성 전이(cascade)는 관리하는 부모가 단 하나일 때 사용해야 한다’ 라는 주장이 나온 배경도 비슷한 맥락입니다.

이를 해결하기 위해서는 다음과 같이 post에서도 comment를 제거하도록 편의 메소드를 구현해야 합니다.

// Post.java
public void deleteComment(Comment comment) {
    comments.remove(comment);
}

@Test
void bidirectional_good_case() {
    Post post = new Post();
    Comment comment1 = new Comment();
    Comment comment2 = new Comment();

    post.addComment(comment1);
    post.addComment(comment2);

    post.deleteComment(comment1);
    commentRepository.delete(comment1);
    postRepository.save(post);

    assertThat(commentRepository.existsById(comment1.getId())).isFalse();
  }

이는 비단 CascadeType.PERSIST만의 문제는 아니며, 다른 CascadeType을 사용하면서 양방향 연관관계 매핑을 적용하는 경우에는 항상 염두에 둬야 하는 부분입니다.

언제 사용해야 할까?

JPA Cascade는 엔티티 간 관계가 명확할 때 사용하는 것을 권장합니다. 단순히 편해서, 비즈니스 로직이 깔끔해진다고 해서 JPA Cascade를 사용하는 것은 추후 큰 문제를 야기할 수도 있습니다. 특히 Cascade 오용으로 인한 문제가 발생하는 경우, 앞서 설명한 예시처럼 예외가 발생하지 않는 경우도 있기 때문에 발견되지 못한 채로 운영 환경에 오랫동안 잠식할 확률이 높습니다.

‘게시물’과 ‘댓글’의 관계처럼 부모 - 자식 구조가 명확하다면 Cascade를 사용하는 것은 괜찮은 선택입니다. 하지만 하나의 자식에 여러 부모가 대응되는 경우(‘수강 중인 수업’과 ‘학생’의 관계 등)에는 사용하지 않는 것이 좋습니다. 여러 부모가 대응되는 순간 예상하지 못한 충돌 문제가 발생할 확률이 높아지고, 이로 인해 비즈니스 로직을 작성하는 개발자는 항상 JPA Cascade의 부수효과를 경계해야 하기 때문입니다.

JPA Cascade는 개발 편의성을 높일 수 있는 기술입니다. 하지만 이를 오용하는 경우 데이터 정합성을 깨뜨릴 수 있을뿐더러 최악의 경우에는 데이터 손실까지 발생하게 됩니다. 따라서 JPA Cascade에 대한 정확한 개념과 발생할 수 있는 문제상황들을 먼저 익힌 뒤 유의해서 사용하시면 좋을 것 같습니다.

참고 자료

https://www.baeldung.com/jpa-cascade-types

자바 ORM 표준 JPA 프로그래밍 - 김영한

정보통신 용어사전 - 참조 무결성 제약조건

전송 제어 프로토콜이란?

Wed, 11 Oct 2023 12:00:00 GMT

OSI 7계층과 전송제어 프로토콜

데이터 통신은 여러 단계로 진행되는데, OSI 참조 모델은 그 과정을 7개 계층으로 나눈다. 1계층(물리 계층)은 ‘케이블이 연결된 상대에 대한 전기·기계적 신호 전달’ 제어를 담당한다. 2계층(데이터링크 계층)은 네트워크 내부에서 데이터를 주고받는 방식을, 3계층(네트워크 계층)은 네트워크 간에 데이터 송수신 방식을 제어한다. 즉, 하나의 컴퓨터에서 다른 컴퓨터로 데이터를 주고받는 방식을 결정하는 일이 1계층부터 3계층의 역할이다.

5계층은(세션 계층) 두 통신장치 간 연결과 통신 시작 및 종료 시점을 결정하며, 6계층(표현 계층) 애플리케이션 목적에 맞는 데이터 형식으로 변환한다. 7계층(응용 계층)은 실제 네트워크 서비스를 사용자에게 제공하는 역할을 담당한다. 간단히 정리하자면 1계층부터 3계층은 데이터 전송, 4계층부터 7계층은 전송된 데이터를 애플리케이션 목적에 맞게 처리하는 과정을 제어한다.

그렇다면 4계층의 역할은 무엇일까? 3계층 이하에서는 ‘데이터 전달’만 제어할 뿐, 신뢰할 수 있는 데이터 전달을 보장하지 못한다. 데이터를 수신할 대상이 존재하지 않거나, 전송 중인 데이터가 분실·손상되는 문제를 다루지 않는다. 따라서 데이터를 안전하게 전송하기 위하여 전달되기 전과, 전달된 후의 데이터에 대한 처리를 4계층(전송계층)이 제어한다. 이러한 처리를 담당하는 프로토콜이 전송제어프로토콜(TCP, Transmission Control Protocol)이다. 그렇다면 TCP는 안전한 데이터 전송을 위해 구체적으로 어떤 역할을 담당할까?

TCP 헤더와 포트 번호

물건이 상자에 포장되어 택배로 보내지듯이, 데이터도 송신에 필요한 제어 정보와 함께 전송된다. 데이터의 앞부분에 위치하는 제어 정보를 헤더(Header)라고 한다. 데이터가 안전하게 전달되도록 제어하는 역할을 TCP 헤더가 담당한다.

위 사진은 TCP 헤더가 제어하는 정보를 나타낸다. 우선 TCP 헤더에는 송신처와 수신처의 포트 번호가 포함된다. 앞서 편의상 컴퓨터 간에 데이터를 주고받는다고 설명했지만, 실제로 데이터를 주고받는 주체는 애플리케이션이다. 컴퓨터 내 존재하는 다양한 애플리케이션 중 데이터 송수신이 필요한 애플리케이션을 구분하기 위해 포트 번호를 지정한다.

세그먼트 분할과 시퀀스 번호

데이터와 헤더가 통합된 상태를 프로토콜 데이터 유닛(PDU, Protocol Data Unit)이라고 한다. 7계층부터 5계층까지 거쳐 전송된 데이터(메시지)에 4계층의 전송 제어 헤더를 결합한 것이 4계층 PDU 즉, 세그먼트이다.

하나의 데이터는 여러 개의 세그먼트로 분할되어 전송된다. 각각의 세그먼트에 번호를 부여하는데 이것을 ‘시퀀스 번호’라고 한다. 여러 개로 분할 전송된 데이터가 최종적으로 순서에 맞게 결합하여 수신되는 만큼 시퀀스 번호는 중요한 의미를 가진다.

커넥션과 3-Way Handshake

수신처 IP주소로 데이터를 전송했지만, 실제 수신처가 존재하지 않을 경우 데이터 전송에 실패할 것이다. 또 수신처가 존재하지만, 데이터를 받을 준비가 되지 않은 경우도 마찬가지다. 본격적으로 데이터를 주고받기 전, 송신자와 수신자 간 데이터 전송 가능 여부를 확인한다면 데이터의 전송을 보장할 수 있다. 이처럼 송·수신자 간에 데이터를 확실하게 주고받을 수 있는 가상 경로를 ‘커넥션’이라고 한다.

커넥션을 확보하는 방법으로 쓰리웨이 핸드쉐이크(3-Way Handshake)가 있다. 위 그림처럼 애플리케이션 A는 B에 데이터 송신 허가를 요청(SYN)한다. B는 요청에 대한 허가(ACK)를 A에 알린다. 이로써 A는 B에 대한 송신로를 확보한다.

하지만 아직 반대의 송신로(B → A)는 확보되지 못한 상황이다. 따라서 B는 A에 허가 사실(ACK)을 전달함과 동시에 데이터 송신 허가 요청(SYN)을 함께 보낸다. A가 B의 요청을 수락(ACK)함으로써 양방향 커넥션이 확립된다. 연결 설정에 사용되는 제어 비트인 SYN과, 데이터 수신 성공을 의미하는 ACK 같은 정보는 TCP 헤더의 플래그에 담긴다.

TCP 연결을 초기화하는 3-Way Handshake와는 반대로 연결을 종료하는 절차를 4-Way Handshake라고 한다. 애플리케이션 A는 B에 연결을 종료하겠다는 의미로 FIN 플래그를 전송한다. B는 FIN 플래그에 대 확인 메시지 ACK를 보낸다. B는 일정 시간 대기 후 연결 종료 준비를 마치면 연결 종료 요청을 위해 FIN 플래그를 A에 보낸다. 마지막으로 A가 확인 응답 메시지 ACK를 보내면서 연결은 종료된다.

확인 응답과 에러 복구

수신처에서 데이터를 받았다는 응답을 보내준다면 송신처는 분실 여부를 확인할 수 있다. 이처럼 세그먼트를 수신하면, 응답 정보를 송신처에 전달하는데 이를 ‘확인응답’이라고 한다.

TCP 헤더에 시퀀스 번호와 확인응답 번호가 포함되는데, 앞서 설명했듯이 시퀀스 번호는 세그먼트의 순서를 나타낸다. 확인응답 번호는 다음에 받고자 하는 데이터의 시퀀스 번호를 의미한다. 수신처는 세그먼트의 시퀀스 번호를 통해 해당 데이터의 순서를 파악하고, 다음에 받을 시퀀스 번호를 확인응답 번호에 명시하여 응답한다.

데이터가 전송 도중에 분실되는 경우가 발생할 수 있다. 세그먼트 송신 후 일정 기간 확인 응답이 돌아오지 않는다면 송신처는 해당 세그먼트를 재전송한다. 송신처가 확인 응답을 기다리는 시간을 RTO(Retransmission Timeout)라고 한다. RTO의 초깃값은 1초로 설정되는데, 실제 확인응답이 돌아오는 시간을 반영하여 조정될 수 있다.

윈도우 제어

하나의 세그먼트를 송신하고 확인 응답을 보내는 과정이 시간 비용면에서 비효율적일 수 있다. 한 개의 세그먼트에 관한 확인 응답을 받기까지 다음 세그먼트를 보내지 못하고 기다려야 하기 때문이다. 따라서 복수의 세그먼트를 한 번에 전송하고 확인응답을 받는 방식을 통해 시간 효율을 높일 수 있다.

복수의 세그먼트를 정확하고 효율적으로 송신하기 위해 ‘윈도우 제어’를 사용한다. ‘윈도우 제어’는 송신자와 수신자 간 데이터 전송 속도를 조절하는 ‘흐름 제어(Flow Control)’의 한 형태다. 복수의 세그먼트를 안정적으로 처리하기 위해 수신한 데이터를 일시적으로 보관하는 버퍼(Buffer)가 필요하다. 수신처의 버퍼 용량 이상으로 데이터가 송신된다면, 데이터를 처리할 수 없어서 파기하는 ‘오버플로’가 발생할 수 있다. 따라서 데이터 수신처는 어느 정도 버퍼량을 가졌는지 상대방에게 알려주게 된다.

위 그림에서 송신처는 한 번에 3개의 세그먼트를 전송한다. 하나의 세그먼트 데이터양이 1000 옥텟이고, 수신처의 기본 버퍼량이 3000 옥텟이라고 가정하자. 수신처는 세그먼트를 버퍼에 임시 보관하며, 각 세그먼트를 저장할 때마다 버퍼량이 1000 옥텟씩 감소한다. 3개의 세그먼트 모두가 버퍼에 저장되면 버퍼량은 0이되고 데이터 처리가 실행되면서 버퍼량은 다시 3000 옥텟으로 복구된다.

송신처가 보낸 각각의 세그먼트에 대응하여 수신처는 확인응답 번호와 윈도우 사이즈 정보를 TCP 헤더에 포함하여 전송한다. 앞서 설명했듯이 확인응답 번호는 다음 순서로 받고자 하는 데이터 시퀀스 번호를 의미한다. 데이터 통신에서 윈도우(Window)는 한 번에 전송하거나 수신할 수 있은 데이터 프레임를 나타내는 개념이며, 윈도우 사이즈는 해당 데이터 프레임의 수를 의미한다. 위 그림에서 수신처가 송신처에 마지막으로 보낸 확인응답 번호는 3001이며 윈도우 사이즈는 3000 옥텟이다. 이는 송신처가 시퀀스 번호가 3001인 데이터부터 세그먼트(데이터양 1000 옥텟) 3개를 한 번에 보내도 좋다는 의미다.
이처럼 윈도우 사이즈로 버퍼량을 전달하여 수용 가능한 데이터를 송수신하는 과정을 윈도우 제어라고 한다.

TCP의 단점과 UDP

앞서 설명한 TCP의 역할인 3-Way Handshake, 에러 복구, 흐름 제어 방식은 데이터 전송을 확실하게 보장한다는 장점이 있다. 하지만 안정적인 데이터 전송을 위한 확인 요청과 응답 과정에서 시간이 소요된다는 단점이 있다. UDP를 통하여 이러한 단점을 보완할 수 있다.

UDP(User Datagram Protocol)는 TCP와 마찬가지로 전송 계층에 속하는 프로토콜이다. UDP는 앞서 설명한 TCP의 ‘3-Way Handshake’와 같은 연결 설정 과정을 생략한다. 게다가 ‘확인응답’ 과정을 거치지 않기 때문에 데이터 도착 여부를 검증하지 않는다. 이와 같은 제어 과정이 생략되는 만큼 신속한 데이터 전송이 가능하다. 이처럼 UDP는 데이터 전송의 신뢰성보다는 신속성이 중요한 애플리케이션에서 주로 사용된다.

위 그림은 UDP 헤더를 나타낸다. TCP 헤더에 포함됐던 확인 응답 번호, 시퀀스 번호, 윈도우 사이즈, 제어 비트, 등이 빠져 있음을 알 수 있다. 데이터의 확실한 전송을 보장하기 위한 절차가 UDP에는 생략됐다는 사실을 UDP 헤더를 통해서도 알 수 있다.

이처럼 ‘빠른 전송’이 필요한 경우 UDP를, ‘정확한 전송’이 필요한 경우에는 TCP를 사용할 수 있다. 각각의 장단점을 제대로 파악하여 서비스 환경에 맞는 프로토콜을 선택할 필요가 있을 것이다.

참고

위키피디아
정보통신 기술 용어 해설
3-Way Handshake
tcp window
‘성공과 실패를 결정하는 1%의 네트워크 원리’ / Tsutomu Tone / 성안당
‘하루 3분 네트워크 교실’/ 아미노 에이지 / 영진닷컴

무한스크롤 기능에서 동시성 이슈 해결하기

Wed, 11 Oct 2023 12:00:00 GMT

안녕하세요. 우아한테크코스 5기 BE 연어입니다. 팀 프로젝트에서 열심히 요즘카페라는 서비스를 만들고 있습니다.

요즘카페는 스크롤 내리면서 성수동의 카페들을 하나씩 볼 수 있는 숏폼 형식의 서비스입니다. 최근에 무한 스크롤 기능을 추가하면서 예상치 못한 동시성 문제를 맞닥뜨렸는데요.

이 글에서는 ObjectOptimisticLockingFailureException이 왜 발생했고, 관련 개념들과 해결 방법에 대해서 다뤄보고자 합니다.

목차는 아래의 순서와 같습니다.

문제 발생
배경 설명
Entity Manager
DB Isolation Level
문제 원인
해결 방안
정리

문제 발생

평소처럼 선릉 캠퍼스에 도착해서 로그를 보고 있었습니다.

그런데 처음 보는 예외가 발생해 있었고, 어떤 행동을 하면 발생하는지 알기 위해 이런저런 행동을 해봤습니다.

기대했던 동작

회원이 스크롤을 엄청 빠르게 내려도
로그에는 예외가 발생하지 않고
새 카페가 중복 없이 나온다

문제가 발생하는 행동

회원이 스크롤을 엄청 빠르게 내리면
로그에는 위와 같이 ObjectOptimisticLockingFailureException이 발생해 있고
스크롤을 내려도 계속 똑같은 카페 화면이 보인다

왜 문제가 발생했을까요…?

배경 설명

요즘카페에서는 회원에게 아직 보여주지 않은 카페들을 우선으로 보여주는 로직이 존재합니다.

회원마다 아직 보지 않은 카페 목록 UnViewedCafe를 가지고 있습니다. 이는 Member:Cafe = N:M 인 다대다 관계를 중간에서 1:N, M:1 로 해결해 주는 테이블입니다.

회원이 스크롤을 내릴 때마다 새로운 카페들을 보여주게 되는데 이때 아래의 두 API가 필요합니다.

A. 회원이 아직 보지 않은 카페 목록을 조회하는 API

회원이 다음 카페를 보기 위해 스크롤을 내리면, 아직 보지 않은 카페들 중 랜덤으로 5개를 응답으로 보내줍니다. 해당 회원의 UnViewedCafe 테이블에서 5개를 조회해 와서 그대로 리턴하는 방식입니다.

B. 회원이 해당 카페를 봤다는 처리를 하기 위한 API

회원이 다음 카페를 보기 위해 스크롤을 내리면, 해당 카페 ID를 서버로 보내서 UnViewedCafe 테이블에서 제거합니다 UnViewedCafe 테이블에서 (memberId, cafeId) 조합의 데이터를 삭제하는 방식입니다. 또한 해당 회원의 UnViewedCafe가 0개가 됐을 때는 전체 카페들을 가져와서 다시 채워줍니다. 따라서 무한 스크롤이 가능해지게 됩니다.

위의 두 API를 가지고 프론트엔드에서는 아래와 같은 방식으로 동작합니다.

카페 목록에서 스크롤을 내려 추가로 볼 수 있는 남은 카페가 3개 이하일 때마다 A를 요청합니다.
스크롤을 내려 다음 카페를 볼 때마다 B를 요청합니다.

대체 왜 ObjectOptimisticLockingFailureException이 발생했고, 스크롤을 내려도 똑같은 카페 화면만 보였을까요? 이유를 알기 위해서 먼저 JPA의 Entity Manager, DB Isolation Level에 대해 알아야 합니다. 아래에서 하나씩 간단히 살펴보겠습니다.

Entity Manager

JPA를 쓰신다면 다들 들어보셨을 용어입니다.

Spring Data JPA를 사용하신다면 보통 아래의 방법들로 DB와 소통할 것입니다.

JPA Repository Interface
JPQL
Native Query
Entity Manager

위의 방법들은 공통점이 있습니다. Spring Container에서 관리되는 Entity Manager를 통해 쿼리를 수행한다는 점인데요.

그럼 이제부터 이 Entity Manager의 특징에 대해서 하나씩 살펴봅시다.

`Entity Manager`는 항상 트랜잭션 내에서 동작합니다.

보통 서비스 레이어에서 @Transactional으로 메서드를 하나의 작업 단위로 관리하는데요. 이때 내부적으로 하나의 Entity Manager가 할당되고 이 Entity Manager가 영속성 컨텍스트, 실제 DB와 소통하게 됩니다.

`Entity Manager`는 싱글톤이 아닙니다.

기본적으로 멀티 스레드 방식으로 동작하는 스프링을 사용할 때 여러 요청을 동시에 처리합니다. 이때 실제 DB와 소통하는 Entity Manager를 싱글톤으로 쓴다면 여러 동시성 문제가 발생할 수 있겠죠?

따라서 Spring에서는 DB와 연결을 관리하는 객체인 Entity Manager Factory를 싱글톤으로 관리합니다. 그리고 Entity Manager가 필요할 때마다 Entity Manager Factory가 생성하는 방식으로 다수의 Entity Manager 인스턴스를 관리합니다.

`Entity Manager`는 자신만의 1차 캐시를 관리합니다.

JPA를 쓸 때 변경 감지를 사용하시나요? 쓰기 트랜잭션 범위 내에서 영속 상태의 인스턴스는 스냅샷이 관리됩니다. Entity Manager는 이 스냅샷을 관리하다가 최종적으로 트랜잭션이 커밋될 때 DB로 Flush 해줍니다.

정리해 보면,

Entity Manager Factory에서 관리하는 Entity Manager는 트랜잭션별로 생성되고 소멸합니다. 또한 1차 캐시를 각각 생성해서 관리합니다. 따라서 한 엔티티를 여러 스레드에서 동시에 수정해도 자신들만의 캐시에서 관리하기 때문에 서로 간섭이 없습니다.

그렇다면 동시에 아무리 요청이 많이 들어와도 동시성 이슈가 없지 않나요?

문제는 1차 캐시에서 DB로 Flush될 때 발생합니다.

Spring Data JPA의 기본 구현체인 Hibernate는 Flush를 한 이후 실제 DB에서 영향 받은 데이터의 수를 리턴 받습니다.

이때, 기존 상태에서 예상되는 변경할 데이터의 수와 실제 변경된 데이터의 수가 다르면 StaleObjectStateException이 Hibernate에서 발생합니다. 그리고 위 런타임 예외가 JPA 레벨로 올라오면, 더 일반적인 예외인 ObjectOptimisitcLockingFailureException으로 Wrapping 됩니다.

동시에 여러 요청이 동일한 데이터를 변경하려고 할 때, Application 레벨에서는 문제가 없지만 DB로 Flush될 때 발생하게 되겠죠?

DB Isolation Level

데이터베이스에는 **격리 수준(Isolation Level)**이라는 개념이 존재합니다. 이는 트랜잭션의 작업이 다른 트랜잭션의 작업과 어떤 관계를 맺는지 정의합니다.

간단히 살펴보면 크게 4가지 단계가 있습니다. (더 자세한 설명은 트랜잭션 격리 수준에서 보실 수 있습니다.)

Uncommitted Read
- 다른 트랜잭션에서 현재 수정 중인 내용도 볼 수 있습니다.
Committed Read
- 다른 트랜잭션에서 커밋을 하면, 그 내용도 볼 수 있습니다.
Repeatable Read
- 한 번 읽어온 정보에 대해서는, 다른 트랜잭션에서 수정하더라도 이전에 읽었던 상태로 보입니다.
Serializable
- 읽어온 정보에 대해서 현재 트랜잭션이 끝날 때까지, 다른 트랜잭션에서는 읽기조차 불가능합니다.

저희는 어떤 격리 수준을 사용하고 있을까요? 이를 위해 저희가 사용하는 MySQL에 대해서도 간단하게 살펴봅시다.

MySQL은 MySQL 엔진과 스토리지 엔진으로 구현돼 있습니다. 간단히 MySQL 엔진은 핵심 본체이고, 스토리지 엔진은 주로 읽기, 쓰기 등의 작업을 처리하는 일꾼입니다.

스토리지 엔진은 여러 종류가 있고, MySQL에서도 여러 가지를 기본으로 제공하는데요. 테이블 별로 어떤 스토리지 엔진을 사용할지 설정할 수 있습니다. MySQL에서는 기본적으로 테이블을 만들 때 스토리지 엔진을 지정하지 않으면, InnoDB 스토리지 엔진을 사용하게 됩니다.

그리고 격리 수준은 각 트랜잭션별로 설정할 수 있습니다. InnoDB에서는 트랜잭션을 수행할 때 격리 수준을 따로 지정하지 않으면, Repeatable Read 수준을 사용하게 됩니다.

결론은 Repeatable Read 특성상 최초 조회한 시점 이후로 어떤 수정이 발생해도 똑같은 결과만 보이게 되겠죠?

드디어 살펴보는 문제 원인

여기까지 먼 길 오시느라 고생하셨습니다!

다시 문제를 리마인드 해봅시다.

회원이 스크롤을 엄청 빠르게 내리면 ObjectOptimisticLockingFailureException 예외가 발생해 있고 스크롤을 내려도 계속 똑같은 카페 화면이 보인다

먼저 프론트엔드에서는 아래와 같은 방식으로 동작합니다.

회원이 스크롤을 내려서 다음 카페를 조회할 때마다 서버에게 해당 카페를 봤다는 요청을 합니다.
스크롤을 내려 추가로 볼 수 있는 남은 카페가 3개 이하일 때마다 서버에게 다음 카페 5개를 요청합니다.

그리고 서버의 `UnViewedCafe` 테이블에 해당 회원의 남은 카페가 3개일 경우를 생각해 봅시다.

스크롤을 내릴 때, 추가로 볼 수 있는 남은 카페 목록이 3개 이하라면 다음 카페 조회 요청을 보냅니다.
- 이때 스크롤 속도가 빠르다면 남은 카페 목록이 3개, 2개, 1개일 때 다음 카페 요청을 동시에 3번 보내게 됩니다.
- 또한 스크롤을 내리면서 조회한 카페를 봤다는 요청을 동시에 3번 보냅니다.

위의 상황에서

서버는 봤다는 요청이 들어올 때마다 해당 카페를 회원의 UnViewedCafe 테이블에서 제거합니다.
- 마지막 1개의 카페가 제거되어 0개가 됐을 때, 새로 전체 카페 목록을 회원의 UnViewedCafe에 채웁니다.
서버는 다음 카페 조회 요청이 들어올 때, 남아 있는 카페들을 보냅니다.
- 봤다는 요청이 처리되는 시점에 따라 동일한 3개를 3번 보냈을 수도 있고 3개, 2개, 2개를 보냈을 수도 있고 2개, 2개, 1개를 보냈을 수도 있습니다.

위의 행동들이 어떠한 순서로 처리될지는 매번 다릅니다.

결론적으로 발생하는 문제는 아래와 같습니다.

회원이 스크롤을 움직일 때마다 동일한 카페에 대해서 봤다는 요청이 동시에 발생할 수 있습니다.
- ObjectOptimisticLockingFailureException이 발생합니다.
스크롤을 내려도 새로 카페가 채워지지 않은 시점이라면 2개, 1개의 카페만 계속해서 보일 수 있습니다.
- 서버에서 회원의 UnViewedCafe 목록에 새 카페가 채워질 때까지(해당 트랜잭션이 커밋되기 전까지) 계속해서 동일한 카페들만 응답하게 됩니다.

해결 방안

문제를 해결하기 위한 두 선택지가 있었습니다.

Serializable 격리 수준 사용하기
조회 요청 때 UnViewedCafe에서 다음 카페들을 제거하고 응답하기

1. Serializable 격리 수준 사용하기

Serializable 격리 수준을 사용한다면, 제일 먼저 도착한 첫 요청만 처리되고 나머지 요청은 기다렸다가 처리될 수 있습니다. 하지만 이는 매우 비효율적인 방안입니다.

한 가지 극단적 예시를 보자면 아래와 같습니다. 카페를 제거하려고 할 때, 해당 카페를 조회하고 있는 회원이 있거나 새로 카페 목록이 채워지는 회원이 존재하면 평생 제거가 불가능합니다.

2. 조회 요청 때 `UnViewedCafe`에서 다음 카페들을 제거하고 응답하기

이 글을 보시는 여러분은 아래와 같은 의문이 들었을 수 있을 것 같습니다.

왜 저런 식으로 카페를 봤다는 처리를 하지…? 그냥 조회 요청 때 UnViewedCafe에서 제거하면서 응답하면 되지 않았나?

이렇게 구현했다면, 조회 요청이 동시에 들어와도 가장 먼저 도착한 요청이 남은 카페 목록을 제거하고 응답받았을 것입니다. 그리고 다른 요청들은 예외가 발생하고 500으로 응답받게 됩니다. 사용자 입장에서는 첫 요청의 응답으로 카페들을 잘 받았기 때문에 예외가 발생해도 지장이 없습니다.

하지만 사용 도중에 브라우저를 종료하면 아직 보지 않은 카페는 UnviewedCafe가 새로 채워질 때까지 볼 수 없습니다. 이러한 상황이 반복되면 불행하게도 평생 못 보는 카페가 생길 수도 있습니다.

무한 스크롤 기능을 구현할 때 이 방식을 먼저 고려했으나 회원이 특정 카페를 못 보게 되는 경험은 막아야 한다고 생각했기 때문에 선택하지 않았습니다.

선택과 근거

각 해결 방안의 트레이드 오프를 고려해 본 결과, 2번 방안(조회 요청 때 UnViewedCafe에서 다음 카페들을 제거하고 응답하기)을 선택하게 되었습니다.

회원이 특정 카페를 평생 보지 못할 수도 있다는 단점이 존재하나, 스크롤을 내릴 때 계속 같은 카페만 보이는 상황이 더 문제 된다고 판단했습니다. 회원 스스로는 특정 카페를 보지 못했다는 사실을 인지하기 어렵지만, 같은 카페만 보이는 경험은 사용자가 인지할 수 있는 단점이기에 사용자 이탈률로 직결됩니다.

따라서 2번 방안인 조회 요청 때 UnViewedCafe에서 다음 카페들을 제거하고 응답하는 방식으로 로직을 개선했습니다.

봤다는 요청 API를 제거하고 조회 요청 때 삭제하고 응답하도록 변경했습니다.
- 더 이상 중복된 카페 화면이 나오지 않습니다.
남은 UnViewedCafe가 0개일 때 새로 채우지 않고, 20개 이하일 때 채웁니다.
- 카페를 다시 채울 때까지 기다려야 하는 경우가 줄어듭니다.
새로 카페를 채울 때 UnViewedCafe에 남아 있는 카페는 중복해서 추가하지 않습니다.
- 새로 채웠을 때 기존 리스트와 중복된 카페가 연속으로 보일 수 있는 상황이 발생하지 않습니다.

하지만 StaleObjectStateException에 대해 깔끔하게 해결하지 못한 상황입니다. 여전히 조회 요청이 동시에 온다면 이후 트랜잭션들은 예외가 발생하고 롤백 됩니다. UnViewedCafe 테이블의 동일한 데이터를 동시에 제거하려고 했기 때문입니다.

위의 남은 문제를 해결하려면 어떤 방법이 있을까요?

DB의 처리 속도를 개선해서 문제 발생 확률을 줄일 수도 있고, 격리 수준을 조정하거나 비관적 락, 낙관적 락 등을 사용할 수도 있습니다.

하지만 동시성 문제를 해결하는 방법은 간단하지 않습니다. 제시한 방법들을 사용해도 완벽히 해결하지 못할 수도 있고, 다른 문제들이 발생할 수 있습니다.

저희는 회원의 경험을 최우선시하는 방향으로 아래의 대안을 생각해 봤습니다.

엔티티에 버전을 매기는 낙관적 락을 사용해서 충돌을 감지합니다.
충돌이 감지되면 해당 트랜잭션을 재시도 합니다.

이제 StaleObjectStateException이 발생해도 재시도하므로 롤백 문제를 해결할 수 있게 됐군요. 회원 입장에서는 요청의 재시도 여부와 관계없이 항상 카페를 조회할 수 있습니다. 👍

정리

지금까지 무한 스크롤 기능에서 발생한 동시성 이슈를 살펴봤습니다. DB에서 동일한 데이터를 제거하려고 할 때 StaleObjectStateException이 발생하는 것이 원인이었습니다.

서버 측에서 이를 해결하기 위해 아래의 방법들을 살펴봤습니다.

Serializable 격리 수준 사용
비즈니스 로직 변경

2번을 선택해서 예외가 발생하는 확률을 훨씬 줄이고 성능은 그대로 유지할 수 있었습니다. 그러나 근본적인 문제인 StaleObjectStateExcpetion은 해결되지 않았고, 추가로 낙관적 잠금을 사용하게 됐습니다.

위의 방법이 모든 상황에서 정답은 아닙니다.

각자가 Trade-Off 사이에서 고민한 선택이 결과적으로도 최고의 선택이었기를 바랍니다. 지금까지 긴 글 읽어주셔서 정말 감사합니다😃 다 같이 힘내서 더 성장해 보아요🤍

참고

백은빈, 이성욱 지음, Real MySQL 8.0
Managing Entities
Hibernate Caching

낙관적 업데이트로 사용자 경험을 개선해보자!

Thu, 05 Oct 2023 12:00:00 GMT

들어가며: 낙관적 업데이트, 왜 필요할까?

장바구니에 상품을 추가했는데, 왜 화면에는 바로 반영되지 않을까?

낙관적 업데이트의 필요성을 처음 느낀 순간은, 장바구니에 상품 추가하기 기능을 만들 때였습니다.

‘장바구니 상품 추가’를 위해 POST 요청을 보내고, 이에 대한 응답이 오기까지 3초의 지연 시간이 있다고 해봅시다. 그리고 개발자 네로 씨는 이 응답을 기다렸다가, 응답에 따라 상태를 업데이트하여 UI를 변경하려고 합니다.

이러한 로직이라면, 화면을 보고 있는 사용자들은 위 그림처럼 3초를 기다렸다가, 3초 뒤에야 해당 상품이 장바구니에 담긴 것을 볼 수 있습니다.

사용자들은 이러한 기다림에 대해 불편함을 느꼈고, 네로 씨는 서버와의 통신과 상관없이, 화면(또는 UI) 먼저 바꿔줄 수는 없을까? 라는 생각을 하게 됩니다.

따라서 네로 씨는 서버의 응답이 오기 전에 상태를 먼저 바꿔서, 업데이트된 상태를 화면에 반영해 주기로 했습니다.

사용자들은 이제 위 그림처럼, 장바구니 아이콘을 누른 순간 즉시 ‘아 장바구니에 상품이 추가되었네!’ 라고 느끼게 됩니다.

바로 ‘낙관적 업데이트’를 통해 지연 시간에 대한 불편을 해소한 것이죠!

낙관적 업데이트는 무엇인가?

낙관적 업데이트가 등장하기 이전에는…

낙관적 업데이트(Optimistic Update)는 웹 애플리케이션에서 사용자 경험을 향상시키기 위해 사용되는 개념입니다. 주로 네트워크 요청이나 데이터 업데이트와 관련하여 사용됩니다.

프론트엔드의 일반적인 상태 업데이트 방식은 다음과 같습니다.

사용자가 어떤 동작(예: 게시글 작성, 댓글 수정, 북마크)을 수행합니다.
서버에 해당 변경 사항(mutation)을 요청하고 응답을 기다립니다.
서버의 응답에 따라 UI를 업데이트합니다.

하지만 이 접근 방식은, 장바구니 예시처럼 사용자가 서버의 응답을 기다려야 하므로 네트워크 지연이나 서버 응답 속도가 느릴 경우에는 사용자 경험이 저하될 수 있습니다.

사용자 경험 향상을 위한 방법, 낙관적 업데이트

낙관적 업데이트는 이러한 문제를 해결하기 위한 방법으로, 사용자의 동작에 대한 응답을 기다리지 않고 미리 UI를 업데이트하는 것입니다.

사용자가 어떤 동작을 수행했을 때, 서버 요청을 보내기 전에 먼저 UI를 업데이트합니다. 서버 응답 성공 시 새로운(업데이트된) 상태를 화면에 그리고, 실패 시에는 오류 메시지를 보여주고 기존의 상태를 유지합니다.

그 결과, 사용자는 동작에 대한 빠른 피드백을 받으므로 애플리케이션이 더 빠르게 반응한다고 느끼게 됩니다.

혹자는 아래와 같은 의문을 가질 수도 있습니다.

요청에 대한 응답이 빠르게 오도록, 서버의 성능을 높이면 되지 않나요? 🤔

서버의 응답이 아무리 빠르더라도, 사용자가 어떤 네트워크 환경에 처해 있느냐에 따라 애플리케이션의 응답 속도가 달라집니다. 예를 들어 지하철의 공공 와이파이로 접속한 경우, 어떨 때는 네트워크가 불안정할 수도 있죠.

따라서 서버의 응답에만 의존하여 상태(또는 UI)를 업데이트하는 것이 아니라, 낙관적 업데이트 와 같은 로직을 통해 각기 다른 사용자들의 환경에 대비하는 것이 좀 더 바람직해 보입니다.

커뮤니티/SNS 서비스 속 낙관적 업데이트

VoTogether(보투게더)라는 투표 중심의 커뮤니티 서비스를 만들면서, 투표 선택지 수정 기능과 댓글 수정 기능을 구현해야 했습니다.

그런데 투표 선택지 수정 및 댓글 수정 API 요청을 한 뒤, 이에 대한 응답이 성공적으로 오기 전까지는 사용자가 바라보는 UI가 즉각적으로 수정되지 않았습니다.

사용자는 UI가 업데이트되기를 몇 초간 기다려야 하는데, 이러한 기다림은 사용자 경험을 저하할 수 있다고 생각했습니다.

VoTogether 팀은 서버 데이터로 UI를 업데이트하는 경우가 많았기 때문에 TanStack Query나 swr 같은 서버 상태 관리 라이브러리를 도입하였고, TanStack Query가 제공하는 메서드 중 useMutation(onMutate, onError, onSettled)을 이용하여 ‘낙관적 업데이트’를 구현하기로 하였습니다.

TanStack Query를 사용하지 않고도 낙관적 업데이트를 구현할 수는 있지만, VoTogether 팀은 서버 상태에 대한 관리를 TanStack Query를 이용하고 있기에 공식 문서의 설명을 참고하여 낙관적 업데이트를 구현해 보았습니다!

상태 관리 라이브러리 없이 구현하기

먼저 TanStack Query 를 사용하지 않고, react의 setState(useState)으로만 투표 선택지 수정 기능을 구현해 봅시다.

투표 선택지 컴포넌트(VoteOptionList.tsx, styled-components 코드는 생략됨)

import React from 'react';

interface Props {
  options: string[];
  selectedOption: string;
  onChange: (option: string) => void;
}

const updateSelectedOptionApi = async (newOption: string) => {
  try {
    const response = await fetch('/api/updateSelectedOption', {
      method: 'PUT',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ newOption }),
    });
    if (!response.ok) {
      throw new Error('투표 선택지 수정 오류 발생');
    }
    alert(`투표한 선택지는 : ${newOption}`);
  } catch (error) {
    console.error('API error:', error);
    alert('투표 선택지 수정 중 오류가 발생했어요');
    throw error;
  }
};

export default function VoteOptionList({ options, selectedOption, onChange }: Props) {
  const handleOptionClick = async (option: string) => {
    onChange(option); // 선택한 선택지 바로 반영

    try {
      await updateSelectedOptionApi(option); // 선택한 선택지 수정 API 요청 호출
    } catch (error) {
      console.error('투표 선택지 수정 오류:', error);
      onChange(selectedOption); // 업데이트 실패 시 선택지 원래대로 돌리기
    }
  };

  return (
    <VoteListContainer>
      {options.map((option, index) => (
        <VoteItem key={index} onClick={() => handleOptionClick(option)}>
          <OptionRadio
            type="radio"
            name="voteOption"
            value={option}
            checked={selectedOption === option}
            onChange={() => handleOptionClick(option)}
          />
          <OptionLabel>{option}</OptionLabel>
        </VoteItem>
      ))}
    </VoteListContainer>
  );
}

App.tsx (VoteOptionList 컴포넌트의 상위 요소)

import React, { useState } from 'react';
import VoteOptionList from './VoteOptionList';

function App() {
  const options = ['취업하기', '창업하기', '대학원 진학하기'];
  const [selectedOption, setSelectedOption] = useState<string>(options[0]);

  const handleOptionChange = (option: string) => {
    setSelectedOption(option); // 선택한 선택지를 수정
  };

  return (
    <div>
      <h1>진로가 고민됩니다🤔🥺</h1>
      <VoteOptionList
        options={options}
        selectedOption={selectedOption}
        onChange={handleOptionChange}
      />
      <p>투표한 선택지: {selectedOption}</p>
    </div>
  );
}

export default App;

위의 코드로 구현한 결과물은 아래와 같습니다.

처음에는 ‘취업하기’라는 선택지였고, ‘창업하기’라는 선택지로 먼저 낙관적 업데이트를 진행합니다. 그 후 API 요청을 보내고, 응답을 기다리다가 오류가 발생하여 원래의 선택지(’취업하기’)로 되돌리는 모습입니다.

const handleOptionClick = async (option: string) => {
  onChange(option); // 선택한 선택지 바로 반영

  try {
    await updateSelectedOptionApi(option); // 선택한 선택지 수정 API 요청 호출
  } catch (error) {
    console.error('투표 선택지 수정 오류:', error);
    onChange(selectedOption); // 업데이트 실패 시 선택지 원래대로 돌리기
  }
};

자세한 코드는 링크에서 참고할 수 있습니다.

TanStack Query로 구현하기

이제 TanStack Query를 이용하여 선택지 수정 기능에 대한 낙관적 업데이트를 구현해 봅시다.

useEditVote.ts

import { useMutation, useQueryClient } from '@tanstack/react-query';
// 선택지 수정 API 요청에 쓰이는 fetch 메서드
export async function updateSelectedOptionApi(newOption: string): Promise<void> {
  const response = await fetch('/api/updateSelectedOption', {
    method: 'PUT',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ newOption }),
  });

  if (!response.ok) {
    throw new Error('Failed to update selected option');
  }
}
// 선택지 수정 쿼리
export const useEditVote = (postId: string) => {
  const queryClient = useQueryClient();
  const queryKey = ['posts', postId, 'option'];

  const { mutate, isLoading, isError, error } = useMutation(
    (newOption: string) => updateSelectedOptionApi(newOption),
    {
      onMutate: async (newOption: string) => {
        // 선택지 데이터에 대한 모든 퀴리요청을 취소하여 이전 서버 데이터가 낙관적 업데이트를 덮어쓰지 않도록 함 -> refetch 취소시킴
        await queryClient.cancelQueries(queryKey);

        const prevOption = queryClient.getQueryData(queryKey); // 기존 선택지 데이터의 snapshot
        queryClient.setQueryData(queryKey, newOption); // 새로운 선택지 데이터로 낙관적 업데이트 실시

        return { prevOption }; // context를 return, context 예시에는 이전 스냅샷, 새로운 값(또는 롤백하는 함수)이 있음
      },
      onError: (error, _, context) => {
        // 캐시를 저장된 값으로 롤백
        queryClient.setQueryData(queryKey, context?.prevOption);
        window.console.log('선택지 수정에 실패했습니다. 다시 시도해주세요.', error);
      },
      onSuccess: () => {
        // 쿼리 함수의 성공하면 -> 기존 선택지 데이터 무효화
        queryClient.invalidateQueries(queryKey);
      },
    },
  );

  return { mutate, isLoading, isError, error };
};

VoteOptionList.tsx

export default function VoteOptionList({
  options,
  selectedOption,
  onChange,
}: Props) {
  const postIdExample = "1234";
  const { mutate } = useEditVote(postIdExample);

  const handleOptionClick = (option: string) => {
    onChange(option);
    mutate(option);
  };
// .. 중략

자세한 코드는 링크에서 참고할 수 있습니다.

TanStack Query의 공식 문서는 어떠한 매커니즘으로 낙관적 업데이트를 구현하는지 아래와 같이 설명하고 있습니다.

낙관적으로 상태를 업데이트한 후 변경 작업을 수행할 때, 변경 작업이 실패할 가능성이 있습니다. 이러한 실패 케이스 대부분에서는 낙관적인 쿼리를 다시 가져와서 실제 서버 상태로 되돌릴 수 있습니다. 그러나 어떤 상황에서는 다시 가져오기가 올바르게 작동하지 않을 수 있으며, 변경 작업 오류가 다시 가져오기가 불가능한 종류의 서버 문제를 나타낼 수 있습니다. 이 경우에는 대신 업데이트를 롤백할 수 있습니다. 이를 위해 useMutation의 onMutate 핸들러 옵션을 사용하여 나중에 오류 및 onSettled 핸들러로 전달될 값을 반환할 수 있습니다. 대부분의 경우 롤백 함수를 전달하는 것이 가장 유용합니다.

이러한 업데이트 및 롤백에 대한 자세한 코드는, 이 예시 코드에서 확인하실 수 있습니다.

서버의 응답이 성공한 경우

 onSuccess: () => {
      // 쿼리 함수의 성공하면 -> 기존 선택지 데이터 무효화
      queryClient.invalidateQueries(queryKey);
 },

서버의 응답이 실패한 경우

onError: (error, _, context) => {
      // 캐시를 저장된 값으로 롤백
      queryClient.setQueryData(queryKey, context?.prevOption);
      window.console.log(
        "선택지 수정에 실패했습니다. 다시 시도해주세요.",
        error
      );
},

TanStack Query에서 진행되는 낙관적 업데이트는 흐름도는 아래와 같습니다.

낙관적 업데이트는 언제 필요할까?

낙관적 업데이트가 필요한 경우

위 이미지의 메시지 전송, 좋아요, 즐겨찾기, 투두리스트 체크, 장바구니 담기, 게시글 비공개, 파일 업로드, 북마크 등은 모두, 낙관적 업데이트가 필요한 기능들입니다.

이러한 기능들의 공통점은, 모두 기존의 데이터에 업데이트(mutate)를 일으킨다는 점입니다. 사용자의 동작에 따라 발생한 데이터 업데이트는, 지연 시간(latency) 없이 즉각적인 피드백을 화면에 띄워야 사용자 만족도를 높일 수 있습니다.

낙관적 업데이트가 굳이 필요한가요? 사용자가 기다리게 하는 것 역시 사용자 경험이 될 수 있지 않나요?

위와 같은 궁금증이 들 수도 있습니다. 사실 지연 시간 또한 사용자 경험이 될 수 있습니다. 웹 애플리케이션 개념이 등장한 지 얼마 되지 않은 시절에는, 사용자들은 기다림이 문제가 된다는 것을 인지조차 하지 않았습니다.

그러나 세월이 흘러 지금처럼 매일 새로운 콘텐츠가 쏟아져 나오고, 데이터를 업데이트하는 기능들이 다양해지면서 피드백 없는 기다림은 불편 사항이 될 수밖에 없었죠.

낙관적 업데이트를 지양해야 하는 경우

물론 낙관적 업데이트가 모든 상태의 업데이트에 필요한 것은 아닙니다. 낙관적 업데이트가 필요하지 않거나, 심지어 사용을 지양해야 하는 경우도 존재합니다.

예를 들어 장바구니에 상품을 담고 결제를 진행한다고 해봅시다.

사용자가 결제 버튼을 클릭하면 어떻게 될까요? 일반적으로 결제 요청이 서버로 전송되고, ‘로딩 중’ 같은 문구나 로딩 스피너가 보일 것입니다.

만약 결제 기능에 낙관적 업데이트를 적용한다면, 결제 응답과 상관없이 장바구니의 상품을 먼저 제거하는 등 UI 먼저 업데이트하게 됩니다. 그 결과는 사용자는 결제했음에도 장바구니에 아직 상품들이 남아 있는 것을 발견합니다.

장바구니의 상품들 상태는 서버의 데이터를 GET 요청하여 보여주는데, 아직 서버의 데이터는 완전하게 업데이트를 끝내지 못했기 때문입니다.

이렇듯 서버 데이터와 화면의 상태 간 일관성이 중요한 경우, 낙관적 업데이트를 지양해야 합니다. 결제나 계정 정보 관리 등의 기능들은 일정 시간의 지연 시간이 필연적이라는 사실을, 많은 사용자가 그동안의 사용자 경험으로 인지하고 있는 부분입니다. 따라서 이러한 상황에는 낙관적 업데이트를 하여 사용자 경험을 저하하기보다는, 중요한 작업의 신뢰성을 유지하기 위해 ‘로딩 중’처럼 서버 응답을 기다리도록 하는 것이 안전합니다.

마치며

낙관적 업데이트는 사용자 경험을 개선하고 더 빠른 애플리케이션 응답을 제공하기 위한 좋은 전략 중 하나입니다.

TanStack Query는 낙관적 업데이트 기능을 제공하고 있고, 이러한 기능을 라이브러리 없이 직접 구현해 보는 것도 좋은 학습이 될 것이라 생각합니다!

나아가 낙관적 업데이트는 데이터의 종류를 고려해 보고 신중하게 구현해야 합니다. 만약 꼭 필요한 경우라면, 서버 응답 실패의 경우에도 오류 메시지를 사용자에게 보여주는 등 적절한 대처가 필요합니다.

참고 자료

https://tanstack.com/query/v4/docs/react/guides/optimistic-updates

https://ilxanlar.medium.com/better-ux-with-optimistic-ui-b72665e1afdf

https://uxplanet.org/faster-user-experience-optimistic-ui-41b151feaa28

https://uncertainty.oopy.io/optimistic-ui-with-react-query

AWS 로그인부터 시작하는 인프라 구축하기 1편

Wed, 04 Oct 2023 12:00:00 GMT

AWS 로그인부터 시작하는 인프라 구축하기 1편 :

AWS 로그인 / EC2 / VPC 이해하기

0. 들어가기

AWS를 처음 접한다면, 아래의 사진(인스턴스 생성 설정)에 나온 이야기들은 별나라 이야기 같을 것입니다.

IAM 사용자, EC2 인스턴스 생성 시 설정하는 VPC, 서브넷, 보안그룹 등 온통 낯선 단어들에 한숨부터 나왔을지도요. 일단 필요하니 블로그에 잘 설명된 대로 EC2 만드는 법을 따라해보지만 문득, 마치 알 수 없는 언어로 된 설명서를 읽는 기분이 들지 않았나요?

IAM 로그인 부터, EC2 인스턴스, 인스턴스 생성에 필요한 VPC, 서브넷과 보안그룹에 대한 개념 정의, 생성된 EC2 인스턴스가 어떻게 인터넷과 통신하는 지까지. 이해에 앞서 단순히 블로그를 보며 따라했던 것들을 하나하나 되짚어보며 알아보도록 합시다.

1. AWS 로그인 이해하기 : 루트사용자? vs IAM사용자?
2. EC2 이해하기 : AMI와 인스턴스 유형은 뭘까?
3. VPC 이해하기 : 가상 사설 네트워크(VPC) 생성에 필요한 Region과 IPv4 CIDR블록이 뭘까?
4. 서브넷 이해하기 : 서브넷 생성에 필요한 가용영역(AZ)와 CDIR 블록이 뭘까?
5. 보안그룹 이해하기 : EC2 인스턴스의 인바운드 아웃바운드 규칙이 뭐지?
6. EC2 생성 완료하기 : public IP 활성화 vs 비활성화?
7. 라우팅 테이블과 인터넷 게이트웨이 이해하기 : 가상 네트워크 속에 들어있는 EC2 인스턴스와 실제 인터넷은 어떻게 통신하는 걸까?

1. AWS 로그인 이해하기 : 루트사용자? vs IAM사용자?

루트 사용자는, 처음 AWS계정을 생성하고, 단일 로그인을 통해 모든 AWS 서비스 및 리소스에 대한 완전한 접근 권한을 가진 사용자를 말합니다. 한편 IAM(Identity and Access Management) 사용자는 이러한 루트사용자 계정의 리소스를 관리하고 사용할 수 있는 권한을 가진 “가상의 사용자” 를 말합니다.

좀 더 자세히 말하자면, 루트사용자가 IAM 사용자를 생성 하면, IAM 사용자가 사용할 ID와 비밀번호가 만들어집니다. 루트 사용자 계정에 접근 할 가상의 사용자를 만드는 것이죠. 이때, 루트 사용자는 IAM사용자가 어디까지 접근할 수 있는지 적절하게 권한을 부여할 수 있습니다.

IAM 사용자들은 부여받은 권한 정도에 따라, 인스턴스를 생성하거나 종료하고, 데이터베이스를 관리하고, 스토리지를 사용하고, 네트워크를 설정하는 등 다양한 작업을 수행할 수 있습니다.

즉, 루트 사용자의 계정의 리소스를 권한에 맞게 이용하는 “가상의 신분”을 IAM 사용자라고 할 수 있습니다.

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

2. EC2 이해하기 : AMI와 인스턴스 유형은 뭘까?

IAM 사용자라는 가상의 신분으로 루트 사용자의 계정에 접속했습니다. 루트 사용자의 EC2 서비스를 이용해봅시다.

EC2 서비스를 사용하는 것은, 우리가 PC방에서 돈을 내고 컴퓨터를 이용하듯 사용할 만큼 AWS PC방의 컴퓨터를 빌리는 것과 같습니다.
대신 우리가 빌리는 컴퓨터는 가상 컴퓨터로 제공되고, 각각의 컴퓨터는 인스턴스로 부르기로 한 것이죠.

PC방은 대체로 게임을 하러가는데, 게임에는 윈도우 기반의 고사양의 컴퓨터가 필요하죠?

우리도 필요한 목적에 따라 가상의 컴퓨터인 EC2 인스턴스의 운영체제와 사양을 설정해야 합니다.

첫째, 애플리케이션 및 OS 이미지(Amazon Machine Image) 를 설정해야 한다.

우리 컴퓨터에 윈도우 OS가 설정되어 있으면, 우리는 그 기본 설정과 소프트웨어, 데이터를 가지고 있는 컴퓨터를 사용할 수 있습니다.

이와 비슷하게, ****AMI******는 가상 컴퓨터를 실행하기 위해 어떤 운영 체제(OS)를 사용하고, 어떤 소프트웨어들을 설치해 놓을 것인지 등을 담고 있는 이미지(자원을 생성, 구성하는 데 사용되는 설정과 값을 포함하는 파일)** 입니다.

커스텀 PC처럼 AWS에서 제공하는 공식 AMI뿐만 아니라 사용자가 직접 정의한 AMI를 생성할 수도 있습니다.

둘째, 인스턴스 유형 (서버의 사양)을 설정해야한다.

사용할 목적에 따라 컴퓨터의 사양도 달라야겠죠?

인스턴스 유형 설정을 통해 CPU, 메모리, 스토리지 및 네트워킹 용량 등 컴퓨터 사양을 선택할 수 있습니다.

예) Amazon EC2 T4g 인스턴스

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

3. VPC 이해하기 (1)
: 리전과 가용영역, 가상 사설 네트워크(VPC)란?

인스턴스를 생성하기 위해서는 VPC를 설정해야 합니다.

5단계를 거쳐 VPC의 개념, VPC 생성에 필요한 것들을 배우고 서브넷과 CIDR에 대해서도 가볍게 익혀봅시다.

리전(Region)과 가용 영역(AZ: Availability Zone)

AWS 서비스들을 제공하기 위해서는 실제 데이터를 저장할 데이터 센터가 필요하겠죠?

가용 영역(Availability Zone) 은 같은 지역 내에서 물리적으로 독립된 데이터 센터들의 그룹을 말합니다.
리전(Region)은 가용 영역이 2개 이상 구성된 지리적 영역입니다. 국가/도시 단위 별로 서비스를 제공하기 위한 단위로 사용됩니다.

예를 들어, AWS 서울 리전 (ap-northeast-2)은 현재 3개의 가용 영역(서울에 위치해 있는 데이터 센터 그룹)을 보유하고 있는데요. 이렇게 지역별로 서비스를 제공함으로써 네트워크 속도를 높이고, 데이터 지역성을 고려한 서비스를 제공할 수 있습니다.

VPC 개념 이해하기

VPC(Virtual Private Cloud) 는 가상 사설 네트워크입니다.
쉽게 말하자면, AWS클라우드에서 독립된 “나만의 개인 네트워크 망”을 만드는 것이지요.

나만의 네트워크 망을 만들기 위해서는,

첫째, 내 네트워크 망이 어느 지역에 속할지 설정해야합니다.
즉, 하나의 “리전”을 선택해야 합니다.

둘째, 내 네트워크 망이 사용 할 IP 주소 범위를 설정해야 합니다.
후술할 “IPv4 CIDR 블록” 설정을 통해 IP주소 대역을 설정하면, 이 VPC 내에서 사용되는 모든 리소스들은 사용자가 지정한 IP 주소 범위 내에서 IP주소를 할당받게 됩니다.

VPC에 IP 주소 범위를 정해야하는 이유?

만약 우테코라는 기업 네트워크가 있다고 가정해봅시다. 이 기업 네트워크에 연결될 장치들(컴퓨터, 휴대폰 등)의 수가 최대 50개라면, IP주소 개수가 50개면 되겠죠?

IP주소는 소중한 자원이기 때문에 이를 효율적으로 할당하고 관리하기 위해 IP주소가 50개만 나올 수있는 네트워크 주소 범위를 정하는 것입니다.

즉, 주소 범위를 정하면, 범위만큼의 IP주소 개수를 할당할 수 있는 것입니다.

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

VPC 이해하기(1) : VPC는 인스턴스가 속한 가상 네트워크 망으로, 리전, IP주소 범위를 설정해야한다.

4. VPC 이해하기 (2)
: VPC의 IPv4 CIDR 블록 이해하기

IPv4 CIDR 블록은 CIDR 표기법을 사용하여 표현된 IPv4 주소 범위를 말합니다. CIDR란 무엇일까요?
결론부터 말하자면, CIDR란 서브넷 마스크를 사용해 IP 주소 범위를 표현하는 주소 체계 입니다. CIDR 주소체계를 통해 네트워크의 IP주소 할당을 더 효율적으로 관리할 수 있게 되었습니다.

구체적인 설명에 앞서 이해를 돕기 위해 간단히 비유를 들어보겠습니다. 이 부분을 읽지 않고 바로 아래로 넘어가도 좋습니다.

우리가 도시의 주소를 관리하는 기관에 근무하고 있다고 상상해봅시다.
예전에는 도시를 크기에 따라 ‘클래스’ 로 나눠서 도시마다 가질 수 있는 주소 범위를 할당했습니다.
큰 도시에는 A클래스라는 큰 주소 공간을, 중간 도시에는 B클래스 중간 크기의 주소 공간을, 작은 도시는 C클래스라는 작은 크기의 주소공간을 주소를 할당하는 식이었어요.
그런데 실제 도시의 크기와는 상관 없이 미리 정해진 클래스의 주소 공간이 할당되어 주소들이 낭비되는 경우가 생겼습니다.
예를 들어, C클래스인 도시에 100개의 주소를 할당한다면, 50개의 주소만 필요한 작은 도시는 50개를 낭비하는 셈이죠
> CIDR은 이 문제를 해결하기 위해, 도시의 크기와 상관없이 도시가 필요한 만큼의 주소 공간을 할당해주는 방식입니다.

첫째, IP 주소의 구조

IP주소의 구조는 192.168.1.0 과 같이 .을 구분자로 한 4개의 숫자로 이루어져 있고, 네트워크 ID와 호스트 ID로 구성됩니다.

예를 들어, 데이터는 IP주소를 통해, 선릉 캠퍼스 중 이레라는 사람을 찾아와야 합니다. “네트워크 ID는 집 주소 = 서울시 강남구 선릉역 성담빌딩 13층”, “호스트 ID는 내 이름 = 이레”로 이루어진 꼴입니다.

둘째, 네트워크 내에서 IP주소를 할당하는 방법 (old.ver)

이전에는 고정된 크기의 IP 주소 범위(A,B,C 클래스) 을 사용하여 네트워크를 구성했습니다.
무슨 소리냐구요?

IP 주소의 첫 번째 숫자를 네트워크 ID로 사용하고, 나머지 세 개의 숫자를 호스트 ID로 사용하는 IP 주소범위를 A 클래스
IP 주소의 첫 번째와 두 번째 숫자를 네트워크 ID로 사용하고, 나머지 두 개의 숫자를 호스트 ID로 사용하는 IP 주소범위를 B 클래스
IP 주소의 세 개의 숫자를 네트워크 ID로 사용하고, 나머지 한 개의 숫자를 호스트 ID로 사용하는 IP 주소범위를 C 클래스 와 같이 고정된 주소 범위(클래스)를 통해 네트워크의 크기를 결정했습니다.

즉, 하나의 네트워크가 선택할 수 있는 IP주소 범위는 A,B,C 세 가지 중 하나였던 것입니다.

셋째, 고정된 주소 범위로 네트워크를 구성하는 것의 문제점

예를 들어, 우테코 회사는 IP주소가 50개만 필요합니다. 그 중 C클래스가 가장 작은 네트워크 규모(=IP 주소범위)를 갖고 있기 때문에, 우테코 회사는 C클래스의 네트워크 망을 구성하게 됩니다.
하지만, C 클래스의 주소범위는 192.0.0.0 ~ 223.255.255.255 이고, IP 주소의 처음 세 개의 숫자가 네트워크 ID로 사용되면, 호스트 ID의 개수는 0~255로 256개가 됩니다.
우테코 회사에서는 IP주소가 50개만 필요하다고 했는데, 나머지 106개의 소중한 IP주소 자원은 쓰이지 않고 버려지는 거죠!

넷째, IP주소를 효율적으로 할당하는 새로운 방식 : CIDR (new.ver)

그래서 등장한 것이 CIDR(Classless Inter-Domain Routing)라는 클래스 없는 IP주소 할당 방식입니다. 네트워크에 연결된 장치 수(호스트 수)에 따라 효율적으로 사용할 수 있는 서브넷(Subnet) 을 만드는 것이죠. 쉽게 말하자면 서브넷은 IP주소 범위(블록)을 더 작은 범위(블록)으로 나누어 네트워크를 구성하는 것을 말합니다.

다섯째, 더 큰 네트워크를 분할한 더 작은 하위 네트워크 : 서브넷

서브넷을 만든다는 것 은 호스트ID 영역을 더 잘게 쪼개어 네트워크ID 영역을 늘리는 작업(서브네팅) 을 뜻합니다.

예를 들어, 우테코는 50개의 IP주소만이 필요합니다.
IP주소 범위가 192.167.10. 0~ 192.167.10. 255인 네트워크는 호스트 IP 범위가 (0~255)로 256개의 IP를 할당할 수 있습니다. 이 네트워크를 더 작은 범위의 네트워크(서브넷)으로 분할해, 우테코가 가져가도록 하게 하면 될 것입니다.
호스트ID 영역을 1/4로 줄여서, 우테코는 64개의 호스트 수를 갖는 네트워크(서브넷)를 구성하게 됩니다. 호스트ID 영역이 3/4인 나머지 네트워크(서브넷)는 다른 기관이 쓸 수 있을테고요.

네트워크 ID영역을 늘려 더 작은 네트워크(서브넷)를 구성함으로써, IP 주소 낭비가 획기적으로 줄어들었습니다!

여섯째, CIDR(Classless Inter-Domain Routing)이란?

지금까지, 고정된 주소범위(클래스)에 국한되지 않고, 네트워크 ID영역의 크기 조절을 통해 IP주소를 유연하게 할당하는 방식에 대해 배웠습니다. 이렇게 잘게 쪼개어진 네트워크까지 표현하기 위한 IP주소 체계를 CIDR이라고 합니다.

앞서, CIDR란 서브넷 마스크를 사용해 IP 주소 범위를 표현하는 주소 체계 라고 설명드렸습니다. 서브넷 마스크란 해당 네트워크의 네트워크 ID 부분의 비트 수를 말하는데요. 서브넷 마스크를 통해 호스트 ID의 비트 수, 즉 IP 주소 범위를 알 수 있게 됩니다.

예를 들어, 줄어든 우테코의 네트워크 IP 주소 범위 는 192.167.10.0~ 192.167.10.63인데요. 이를 CIDR 형식으로 나타내면, “192.167.10.0/26” 으로 표현할 수 있습니다.

CIDR 주소의 “/26”는 네트워크 ID부분의 비트 수(서브넷 마스크의 길이)를 의미합니다. 즉, 192.167.10.0/26 는 네트워크 ID 영역이 26비트이고 호스트 ID 영역이 6비트인 네트워크 를 표현하는 것이지요.

예시 사진을 보면, IP주소에서 하나의 숫자는 8비트인데요.
호스트 ID영역을 6비트로 잘게 쪼개면, 네트워크 ID의 영역은 8*3 =24 에서 → 8*3+2 =26 비트가 됩니다.
이처럼 서브넷 마스크를 설정하면 6비트로 표현되는 호스트 ID 영역과 나머지 26비트로 표현되는 네트워크 ID 영역을 가지는 서브넷을 생성할 수 있는 것 입니다. (이 계산법에 대해 좀더 자세히 공부하고 싶으신 분들은 서브넷 마스크와 서브네팅 계산법을 공부하시면 됩니다.)

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

VPC 이해하기(1) : VPC는 인스턴스가 속한 가상 네트워크 망으로, 리전, IP주소 범위를 설정해야한다.

VPC 이해하기(2) : VPC의 IP주소범위는 CIDR방식으로 나타낸다.

5. VPC 생성하기 및 인스턴스에 적용하기

VPC를 생성하기 위해서는

첫째, 리전을 적용해야하는데, 사용자가 선택한 리전으로 자동 적용됩니다.

둘째, IPv4 CIDR 블록으로 VPC의 IP 대역(네트워크 주소범위)을 설정해야 합니다.

참고로, IPv4 CIDR 블록이 192.168.0.0/16라는 것은, 네트워크 ID 영역이 16비트라는 뜻입니다.
이 네트워크에서 IP 주소 할당 가능한 호스트 수는 2의 16승(=16비트)으로, 65,536개가 됩니다!

이를 통해, 생성된 VPC 입니다.

인스턴스 생성 시, 인스턴스의 네트워크 설정>VPC에서 생성한 VPC(MY_VPC)를 적용합니다.

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

VPC 이해하기(1) : VPC는 인스턴스가 속한 가상 네트워크 망으로, 리전, IP주소 범위를 설정해야한다.

VPC 이해하기(2) : VPC의 IP주소범위는 CIDR방식으로 나타낸다.

VPC 생성하기 : 리전과 IP주소범위를 설정한 VPC를 생성한다.

인스턴스 생성 시, 미리 생성된 VPC를 설정해 인스턴스가 속할 네트워크 망을 정한다.

AWS 로그인부터 시작하는 인프라 구축하기 2편

Wed, 04 Oct 2023 12:00:00 GMT

AWS 로그인부터 시작하는 인프라 구축하기 2편 :

서브넷 / 보안그룹 / 퍼블릭vs프라이빗 인스턴스 / 라우팅 테이블과 인터넷 게이트웨이

6. 서브넷 이해하기

인스턴스를 생성할 때, 설정한 VPC에 따라 선택할 수 있는 서브넷 목록이 바뀌는 것을 볼 수 있습니다. 서브넷은 VPC에 종속되는 것일까요?
앞서, 네트워크 내의 IP주소를 효율적으로 할당하기 위해 서브넷이라는 용어가 나왔는데요.

네트워크에서의 서브넷, AWS에서의 서브넷 개념을 이해하고, AWS에서 서브넷을 만들어봅시다.

6-(1).네트워크에서 서브넷 이해하기

네트워크에서 서브넷이란, 큰 네트워크를 더 작은 네트워크로 분할한 것을 말합니다.

더 큰 네트워크에서 호스트ID 영역을 줄여서 더 작은 네트워크(호스트 수가 더 적은)로 분할해 생긴 작은 네트워크 대역을 서브넷이라고 하는 것이죠.

서브넷은 독립적인 네트워크로 간주되며, 각 서브넷은 자체적으로 라우팅과 보안 설정을 가지고 있습니다.

1. 자체적인 라우팅을 가진다.

서브넷은 독립적인 작은 네트워크이므로, 자신의 네트워크 주소범위 를 가지고 있습니다. 따라서, 자체적인 라우팅 테이블을 사용해, 서브넷 내부의 호스트(네트워크 장치)들 사이에서 통신과 다른 서브넷으로의 통신을 처리합니다. (*라우팅 테이블 = 다른 호스트(네트워크장비)로 데이터 전송할 때 어떤 경로 선택해야 하는지 지시하는 경로표)

2. 자체적인 보안설정을 가진다

서브넷은 독립적인 보안그룹을 구성하여, 원하는 트래픽을 허용하거나 차단 합니다. 즉, 특정 포트나 프로토콜 통신을 제한하거나 허용할 수 있습니다.

6-(2).AWS에서 서브넷 이해하기

VPC가 가상 네트워크이고 논리적인 IP대역을 의미한다면,

서브넷은 VPC의 IP주소 범위를 나누어 실제 리소스(예: EC2 인스턴스, S3가 서브넷에 설치됨)가 배치되는 물리적인 주소 범위를 말합니다.

하나의 VPC에 여러개의 서브넷이 생길 수 있으며, VPC를 잘게 나눈 것이기 때문에 VPC보다 대역폭(IP주소범위)이 낮아야 합니다.
서브넷 한 개는 하나의 가용영역(Availability Zone: 데이터 센터 그룹)에만 속합니다. (하나의 가용영역에 여러개의 서브넷은 가능합니다)
*참고로, VPC를 생성할 때는 사용할 가용영역(AZ)의 개수만 선택하게 됩니다. 이후, 서브넷을 생성할 때, 어느 가용영역에 생성할지 선택하면 됩니다.

6-(3). 서브넷 생성하기 및 인스턴스에 적용하기

첫째, 어떤 VPC의 서브넷인지 설정합니다.

둘째, 서브넷이 상주할 데이터베이스 센터 그룹인 가용영역을 설정합니다.

(예시 : 서울 리전의 -2a)

셋째, VPC의 IP주소 범위를 분할한, 서브넷 IPv4 CIDR 블록을 설정합니다.

설정한 VPC의 주소 범위가 192.168.0.0/16이기 때문에, 서브넷의 대역폭은 VPC의 대역폭보다 좁은 CIDR블록을 설정해야 합니다.
더 좁은 대역폭이란 IP 주소 범위에서 사용 가능한 IP 주소의 개수가 적다는 것을 의미합니다.
“/16”이라는 것은 VPC의 서브넷 마스크의 길이가 네트워크ID가 16비트라는 말로, 65,536개의 IP 주소를 가집니다.
따라서 서브넷은 VPC보다 네트워크ID 영역의 비트수가 높은 “/17”부터 아마존의 정책에 따라 “/28”까지 필요한 IP 개수에 따라 서브넷의 CIDR 블록을 설정할 수 있습니다.
생성 완료된 서브넷을 확인해봅시다!
- 생성한 VPC(vpc-0dde~ = 192.168.0.0/16)의 서브넷임을 확인할 수 있습니다.
- 서브넷 IPv4 CIDR 블록은 192.168.0.0/24로, VPC의 대역폭보다 좁은 CIDR블록이 잘 생성되어있음을 볼 수 있습니다.
  네트워크ID의 길이가 늘어남(16->24bit)에 따라 호스트ID의 수가 줄어들은 것이죠!
- 가용영역(리전 내의 데이터 센터)도 우리가 설정한 ap-northeast-2a로 잘 생성 된 것을 볼 수 있습니다.

넷째, 인스턴스 생성시, 네트워크>서브넷에서 생성한 서브넷을 적용합니다.

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

VPC 이해하기(1) : VPC는 인스턴스가 속한 가상 네트워크 망으로, 리전, IP주소 범위를 설정해야한다.

VPC 이해하기(2) : VPC의 IP주소범위는 CIDR방식으로 나타낸다.

VPC 생성하기 : 리전과 IP주소범위를 설정한 VPC를 생성한다.

인스턴스 생성 시, 미리 생성된 VPC를 설정해 인스턴스가 속할 네트워크 망을 정한다.

인스턴스 생성 세 번째 설정, 인스턴스의 Subnet을 설정했습니다.

서브넷 이해하기(1) : 네트워크에서 서브넷은 큰 네트워크를 더 작은 네트워크로 분할한 것이다.

서브넷 이해하기(2) : AWS에서 서브넷은 VPC의 IP주소 범위를 나눈 네트워크로, 실제 리소스가 배치된다.

서브넷 생성하기 : VPC, 가용영역, IP주소 범위을 설정해, 서브넷을 생성한다.

인스턴스 생성 시, 미리 생성된 서브넷을 설정해 인스턴스가 배치 될 네트워크 망을 정한다.

7. 보안그룹 이해하기

7-(1).보안그룹은 인바운드 아웃바운드 규칙을 통해 EC2 인스턴스의 트래픽 규칙을 설정한다

어떤 서브넷(네트워크, IP주소범위)에 인스턴스를 생성할지 결정하고 나면, 인스턴스의 보안 규칙 을 설정해야하는데요.
보안 그룹은 연결된 리소스(인스턴스)에 도달하고 나갈 수 있는 트래픽을 제어하는 방화벽 규칙 세트 라고 할 수 있습니다.
예를 들어, 보안 그룹을 EC2 인스턴스와 연결하면 인스턴스에 대한 인바운드(도달하는 트래픽) 및 아웃바운드(나가는 트래픽) 트래픽을 제어하는 것입니다.

인바운드 규칙은 외부에서 - > 인스턴스로 오는 트래픽에 관한 규칙 을 설정합니다.
아웃바운드 규칙은 인스턴스에서 - > 외부로 가는 트래픽에 관한 규칙 을 설정합니다.

인바운드, 아웃바운드 규칙을 통해 어떤 IP 주소, 포트 또는 프로토콜의 트래픽을 허용할지 또는 차단할지를 설정하는 것입니다.

7-(2).보안그룹은 AWS 리소스(EC2 등)에 직접 적용된다.

보안 그룹을 생성할 떄 어떤 VPC에 생성될지 지정함으로써, VPC에 여러 보안그룹을 생성하고 하나의 서브넷은 VPC에 생성된 여러 보안 그룹을 사용할 수 있습니다.

여러 보안 그룹을 사용하면 같은 VPC 내에서도 서로 다른 리소스 또는 그룹에 대해 다른 보안 규칙을 적용할 수 있는데요.
예를 들어, 같은 VPC 내에 웹 서버 그룹과 데이터베이스 서버 그룹이 있다면, 웹 서버 그룹에는 웹 트래픽을 허용하는 규칙을 설정하고 데이터베이스 서버 그룹에는 특정한 IP 주소만 데이터베이스 접근을 허용하는 규칙을 설정할 수 있습니다.

이렇게 여러 보안 그룹을 사용함으로써, 네트워크 리소스를 보다 세부적으로 제어하고 보호할 수 있는 것이죠.

7-(3). 보안그룹 생성하기 및 인스턴스 적용하기

아래와 같이, VPC(vpc-0dde~)에 보안그룹을 생성했습니다!

인스턴스 생성 시, 인스턴스의 네트워크 설정>방화벽(보안그룹)에서 생성한 보안그룹(MY_VPC_SECURITY_GROUP)를 적용합니다.

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

VPC 이해하기(1) : VPC는 인스턴스가 속한 가상 네트워크 망으로, 리전, IP주소 범위를 설정해야한다.

VPC 이해하기(2) : VPC의 IP주소범위는 CIDR방식으로 나타낸다.

VPC 생성하기 : 리전과 IP주소범위를 설정한 VPC를 생성한다.

인스턴스 생성 시, 미리 생성된 VPC를 설정해 인스턴스가 속할 네트워크 망을 정한다.

인스턴스 생성 세 번째 설정, 인스턴스의 Subnet을 설정했습니다.

서브넷 이해하기(1) : 네트워크에서 서브넷은 큰 네트워크를 더 작은 네트워크로 분할한 것이다.

서브넷 이해하기(2) : AWS에서 서브넷은 VPC의 IP주소 범위를 나눈 네트워크로, 실제 리소스가 배치된다.

서브넷 생성하기 : VPC, 가용영역, IP주소 범위을 설정해, 서브넷을 생성한다.

인스턴스 생성 시, 미리 생성된 서브넷을 설정해 인스턴스가 배치 될 네트워크 망을 정한다.

인스턴스 생성 네 번째 설정, 인스턴스의 보안그룹을 설정했습니다.

8. EC2 생성 완료하기

public IP 활성화 vs 비활성화

인스턴스의 마지막 네트워크 설정입니다. 바로 인스턴스에 퍼블릭 IP 주소를 줄 것인가 인데요.

퍼블릭 IP 주소란 외부 인터넷과 통신할 수 있는 공인 IP 주소입니다. EC2 인스턴스가 퍼블릭 IP 주소를 갖게 되면, 이 주소를 사용하여 외부에서 인스턴스에 접근할 수 있게 됩니다.

“퍼블릭 IP 주소 활성화” 옵션을 선택하면 해당 리전(Region)의 AWS에서 관리하는 퍼블릭IP 주소 풀에서 하나의 퍼블릭 IP 주소를 할당받는데요. 이 주소는 EC2 인스턴스와 통신하는 외부 클라이언트들이 사용할 수 있게 됩니다. 주의해야 할 점은 퍼블릭 IP 주소는 고정되지 않고 인스턴스를 중지하고 다시 시작하면 변경될 수 있다는 것입니다.

[퍼블릭 인스턴스가 생성된 예시]

반면, “퍼블릭 IP 주소 비활성화” 옵션을 선택하면, 서브넷의 IP주소 범위 내에서 사설IP주소가 자동으로 할당됩니다. 퍼블릭IP주소가 없기 때문에, 해당 인스턴스는 인터넷에서 또는 인터넷으로 직접 접근을 할 수 없는데요.

다만, 같은 VPC(내부 네트워크)에서는 프라이빗 IP 주소를 통해 해당 인스턴스에 접근 할 수 있습니다. 즉, 프라이빗 IP를 가진 인스턴스는 VPC 내의 리소스 간에 내부 네트워크 통신을 위해 사용됩니다

[프라이빗 인스턴스가 생성된 예시]

지금까지 가이드

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

VPC 이해하기(1) : VPC는 인스턴스가 속한 가상 네트워크 망으로, 리전, IP주소 범위를 설정해야한다.

VPC 이해하기(2) : VPC의 IP주소범위는 CIDR방식으로 나타낸다.

VPC 생성하기 : 리전과 IP주소범위를 설정한 VPC를 생성한다.

인스턴스 생성 시, 미리 생성된 VPC를 설정해 인스턴스가 속할 네트워크 망을 정한다.

인스턴스 생성 세 번째 설정, 인스턴스의 Subnet을 설정했습니다.

서브넷 이해하기(1) : 네트워크에서 서브넷은 큰 네트워크를 더 작은 네트워크로 분할한 것이다.

서브넷 이해하기(2) : AWS에서 서브넷은 VPC의 IP주소 범위를 나눈 네트워크로, 실제 리소스가 배치된다.

서브넷 생성하기 : VPC, 가용영역, IP주소 범위을 설정해, 서브넷을 생성한다.

인스턴스 생성 시, 미리 생성된 서브넷을 설정해 인스턴스가 배치 될 네트워크 망을 정한다.

인스턴스 생성 네 번째 설정, 인스턴스의 보안그룹을 설정했습니다.

인스턴스 생성 다섯 번째 설정, 인스턴스의 PUBLIC IP주소 활성화 옵션을 설정했습니다.

EC2 생성 이후, 새로운 의문점

인스턴스의 스토리지 용량까지 결정하고 나면 인스턴스 생성이 완료됩니다.
이렇게 생성된 인스턴스를 사용하면서 아래와 같은 궁금점이 들지 않으셨나요?

1. 같은 VPC 내의 서브넷들 사이에서 통신(= 각 서브넷에 배치된 인스턴스 간 통신)은 왜 프라이빗 IP주소로 실행되는 걸까요?

2. VPC는 나만의, 내가 설정한 가상 네트워킹 환경(VPC)입니다.
VPC는 기본적으로 private 환경인데, 어떻게 인스턴스들이 인터넷에 접속할 수 있는 걸까요?

9. EC2 인스턴스와 인터넷의 통신 이해하기

설명에 앞서 결론부터 말하자면,

첫째, VPC에 인터넷 게이트웨이라는 것을 생성해, VPC 내의 리소스가 인터넷에 액세스할 수 있게 됩니다.
둘째, 서브넷에 연결된 라우팅 테이블에 “0.0.0.0/0” 목적지를 인터넷 게이트웨이로 설정합니다.

여기서, “0.0.0.0/0”은 모든 IP 주소로 아웃바운드 트래픽에 대한 설정이라고 이해하면 됩니다.
즉, 모든 IP 주소를 목적지로 하는 트래픽을 인터넷 게이트웨이를 통해 라우팅하도록 설정하는 것을 의미합니다.
셋째, 이로써 퍼블릭 서브넷 내의 모든 “퍼블릭 인스턴스” 들이 외부 인터넷과 통신할 수 있게 되는 것입니다.
아래 사진을 보면, 두 개의 서브넷에 연결된 각각의 EC2들은 자신이 소속된 서브넷이 아닌 다른 네트워크로 요쳥을 보낼 때,
1) VPC 라우터의 라우팅 테이블에 적힌 규칙에 따라 트래픽을 특정경로로 이동시키는데,
2) VPC 내의 서브넷 끼리는 내부적으로 통신하고
3) VPC 외부와의 통신은 인터넷 게이트웨이를 통해 인터넷과 연결합니다.

퍼블릭 IP만 있으면 되는 것 아닌가? 퍼블릭 서브넷은 뭐고, 라우팅 테이블, 인터넷 게이트웨이는 뭘까? 하는 생각이 들 것입니다.

다음 장을 읽으며 퍼블릭 서브넷의 개념과 라우팅 테이블, 게이트웨이에 대해 이해해 봅시다.

10. 퍼블릭 서브넷 vs 프라이빗 서브넷

처음 서브넷을 생성할 때, 프라이빗 서브넷인지 퍼블릿 서브넷인지 설정하는 칸이 없지 않았나요? 따라서, 처음 서브넷을 생성하면 모두 프라이빗 서브넷이 됩니다.

프라이빗 서브넷이란,
생성되는 인스턴스들이 외부와 통신할 수 없는 서브넷을 말합니다.
프라이빗 서브넷의 트래픽 규칙을 적어둔 라우팅 테이블에는 “0.0.0.0”, 모든 IP주소에 대한 인터넷 게이트웨이로의 라우팅 규칙이 없습니다. 즉, 해당 서브넷 내의 인스턴스들은 직접적으로 인터넷에 접근할 수 없게 됩니다.
이로 인해 프라이빗 서브넷 내에 생성되는 인스턴스들은 기본적으로 퍼블릭 IP주소를 가질 수 없습니다.
퍼블릭 서브넷이란, 생성되는 인스턴스 퍼블릭 IP주소를 가질 수 있고, 퍼블릭 IP주소를 통해 외부 인터넷과 직접 통신할 수 있는 서브넷을 말합니다.

서브넷의 트래픽 규칙을 적어둔 라우팅 테이블에 “0.0.0.0”, 모든 IP주소를 목적지로 하는 트래픽을 인터넷 게이트웨이로 라우팅하는 설정을하면, 퍼블릭 서브넷이 됩니다.

퍼블릭 서브넷에서 인스턴스를 생성하면 해당 인스턴스에는 퍼블릭 IP 주소를 할당할 수 있게 되는 것입니다.

지금까지 가이드

[ 인스턴스 생성 ]

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

인스턴스 생성 세 번째 설정, 인스턴스의 Subnet을 설정했습니다.

인스턴스 생성 네 번째 설정, 인스턴스의 보안그룹을 설정했습니다.

인스턴스 생성 다섯 번째 설정, 인스턴스의 PUBLIC IP주소 활성화 옵션을 설정했습니다.

[인스턴스의 인터넷 통신]

프라이빗 서브넷에 연결된 라우팅 테이블에 인터넷 게이트웨이로 라우팅하는 트래픽 규칙을 더해, 퍼블릭 서브넷으로 만든다.

11. 라우팅 테이블이란?

서브넷은 서로 다른 네트워크 영역을 가지고 있습니다.
따라서, 한 서브넷에서 다른 서브넷으로 데이터를 전송하려면( = 다른 네트워크로 데이터를 전송하려면) 라우팅을 해야합니다.

(*라우팅이란, 네트워크에서 데이터를 출발지에서 목적지로 이동시키는 것을 말합니다.)

즉, VPC 안에서 네트워크 요청이 발생하면, 어떤 네트워크 경로를 통해 트래픽을 전송할지 결정해야하는데요.

라우팅 테이블에는 네트워크 내에서 발생하는 트래픽의 이동 경로 규칙이 적혀져 있습니다.
다시말해, 목적지의 IP 주소 범위에 따라 어느 인터페이스로 데이터를 보낼 지에 대한 정보가 저장되있습니다. 일종의 표지판 역할을 하는 것이지요.

라우팅 테이블 편집하기

서브넷의 라우팅 테이블에 목적지를 0.0.0.0/0로하는 트래픽에 대한 인터넷 게이트웨이로 라우팅하겠다는 규칙을 추가합니다.
이를 통해, 서브넷 인스턴스에서 발생한 트래픽 중 특정 목적지로의 트래픽을 특정 경로로 전송할 수 있게 되는 겁니다.
이 규칙을 적용함으로써 프라이빗 서브넷이 퍼블릭 서브넷이 됩니다.

서브넷의 라우팅 테이블 살펴보기

이 라우팅 테이블의 규칙들을 해석하자면,

첫째 줄은, 대상(Destination)이 “0.0.0.0/0” 에 대해서 대상(Target, 트래픽을 전송할 때 사용할 게이트웨이, 네트워크 인터페이스)을 인터넷 게이트웨이로 설정한다는 말인데요.
서브넷에서 모든 퍼블릭 IP주소를 대상(Destination)으로 하는 통신에 대해 인터넷 게이트웨이라는 특정 경로로 라우팅하게 하는 것 입니다.
이로써 VPC 내의 모든 퍼블릭 IP를 가진 인스턴스가 외부 인터넷과 통신할 수 있게 됩니다.
둘째 줄은, VPC 내부 IP 주소 범위(192.168.0.0/16) 내의 리소스를 목적지로하는 모든 트래픽에 대해서 로컬 라우팅이 자동으로 설정된 것인데요.
로컬 라우팅이란, VPC 내부 통신이 발생했을 때, 트래픽이 외부로 나가지 않고 네트워크 내부에서 트래픽을 라우팅하는 것을 의미합니다.
모든 서브넷에 동일한 로컬 라우팅이 적용됨으로써, VPC내의 자유로운 내부통신이 가능해진 것이죠!

특정 IP 대역을 대상(Destination)으로 설정한 것에 우선순위가 있으므로,
로컬 라우팅에 의해 우리가 같은 VPC 내의 서브넷들 사이에서 통신(= 각 서브넷에 배치된 인스턴스 간 통신)은 왜 프라이빗 IP주소로 실행되게 됩니다.

지금까지 가이드

[ 인스턴스 생성 ]

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

인스턴스 생성 세 번째 설정, 인스턴스의 Subnet을 설정했습니다.

인스턴스 생성 네 번째 설정, 인스턴스의 보안그룹을 설정했습니다.

인스턴스 생성 다섯 번째 설정, 인스턴스의 PUBLIC IP주소 활성화 옵션을 설정했습니다.

[인스턴스의 인터넷 통신]

프라이빗 서브넷에 연결된 라우팅 테이블에 인터넷 게이트웨이로 라우팅하는 트래픽 규칙을 더해, 퍼블릭 서브넷으로 만든다.

서브넷에는 서브넷에서 발생하는 트래픽 경로 규칙이 담긴 라우팅 테이블이 있다.

12. 인터넷 게이트웨이란?

VPC는 나만의, 내가 설정한 가상 네트워킹 환경(VPC)입니다. VPC는 기본적으로 private한 환경인데, 어떻게 인스턴스들이 인터넷에 접속할 수 있는 걸까요?
바로, 라우팅 테이블에 규칙으로 설정해 놓은 “모든 IP주소에 대해서 인터넷 게이트 웨이로 연결한다”는 설정 때문입니다.

인터넷 게이트 웨이란, VPC에서 호스팅하는 리소스와 인터넷 간의 통신을 가능하게 해주는 AWS 컴포넌트인데요. VPC의 리소스와 인터넷 간의 통신을 활성화하기 VPC에 연결된 통로라고 할 수 있습니다.

위의 그림 처럼 VPC 내부의 리소스(인스턴스 등)는 VPC에 연결된 인터넷 게이트웨이를 통해 외부 인터넷과 통신할 수 있는데요.

이때, 리소스는 퍼블릭 IP주소를 가지고 있어야 합니다. 인터넷 상에서 퍼블릭 IP주소가 고유한 식별자 역할을 해주기 때문이죠.
또, 리소스(인스턴스)가 배치된 서브넷의 라우팅 테이블에 ‘0.0.0.0/0’ 목적지는 인터넷 게이트 웨이로 라우팅한다는 설정이 있어야 합니다.

지금까지 가이드

[ 인스턴스 생성 ]

루트 사용자의 리소스에 접근할 수 있는 가상의 신분으로(IAM) 로그인 했습니다.

인스턴스 생성 첫 번째 설정, 인스턴스의 운영체제와 사양을 설정했습니다.

인스턴스 생성 두 번째 설정, 인스턴스의 VPC를 설정했습니다.

인스턴스 생성 세 번째 설정, 인스턴스의 Subnet을 설정했습니다.

인스턴스 생성 네 번째 설정, 인스턴스의 보안그룹을 설정했습니다.

인스턴스 생성 다섯 번째 설정, 인스턴스의 PUBLIC IP주소 활성화 옵션을 설정했습니다.

[인스턴스의 인터넷 통신]

프라이빗 서브넷에 연결된 라우팅 테이블에 인터넷 게이트웨이로 라우팅하는 트래픽 규칙을 더해, 퍼블릭 서브넷으로 만든다.

서브넷에는 서브넷에서 발생하는 트래픽 경로 규칙이 담긴 라우팅 테이블이 있다.

인터넷 게이트웨이란 인스턴스와 인터넷 간의 통신을 연결해주는 통로이다.

13.인스턴스의 네트워크 연결 총 정리하기

1) MY_VPC에는 퍼블릭 서브넷 2개와 프라이빗 서브넷 1개가 존재합니다.

인터넷 게이트 웨이에 대한 라우팅 규칙이 있는 라우팅 테이블(MY_ROUTING_TABLE)과 연결된 퍼블릭 서브넷
VPC 내부 통신에 대한 규칙만 있는 기본 라우팅 테이블(rtb-04fe7cca6a359e13f) 프라이빗 서브넷

2)퍼블릭 서브넷 내에서 생성한 리소스(예: 인스턴스) 중 퍼블릭 IP를 가지고 있는 리소스만 외부 인터넷과 통신할 수 있습니다

3)맵 상에는 나오지 않았지만 각각의 인스턴스들은 MY_VPC에 등록된 보안그룹을 선택해 각각의 인바운드 규칙과 아웃바운드 규칙을 설정 합니다.

정리

지금까지 AWS의 인스턴스 생성을 위해서 아래와 같은 절차를 거쳤습니다.

ami(os, 소프트웨어 설치 이미지)와 컴퓨서 사양 결정
네트워크 설정
- vpc 생성 및 인스턴스에 적용 : vpc의 리전 설정, ip 주소 범위 설정, 가용영역(리전 내의 데이터 센터) 개수 설정
- subnet 생성 및 인스턴스에 적용 : vpc 설정, 가용영역 선택, IPv4 CIDR(서브넷 네트워크 주소 범위) 설정
- 보안 그룹 생성 및 인스턴스에 적용 : 어떤 VPC에 생성될 것인지 설정, 인바운드-아웃바운드 규칙 추가
- 인스턴스의 퍼블릭 IP주소 활성화/ 비활성화 옵션 설정 : 퍼블릭 서브넷 내에서만 가능하며, 퍼블릭 IP주소 활성화하면 퍼블릭 인스턴스가 됨
스토리지 설정

그리고 한 서브넷 내의 인스턴스가 어떻게 다른 서브넷의 인스턴스와, 또는 외부 인터넷과 통신하는지 알아보았습니다.

프라이빗 서브넷 생성 : 동일 VPC 내부통신(인스턴스의 프라이빗 IP를 통한)의 로컬라우팅만 가능한 상태
로컬 라우팅 : VPC 내부 통신이 발생했을 때, VPC 내부에서 서브넷 간의 트래픽을 라우팅하는 것
퍼블릭 서브넷 생성 : 서브넷의 라우팅 테이블에 모든 IP주소(목적지)에 대해 인터넷 게이트웨이로의 라우팅 설정
인터넷 게이트웨이를 통해, 퍼블릭 서브넷의 퍼블릭 인스턴스가 인터넷과 통신할 수 있다.

선착순 티켓 예매의 동시성 문제: 잠금으로 안전하게 처리하기

Mon, 18 Sep 2023 12:00:00 GMT

들어가며

대학 축제 티케팅 서비스 페스타고를 개발하면서 아래와 같은 고민을 하게 되었다.

티켓 오픈 시간에 많은 사용자가 동시에 티켓 예매를 요청하면 어떠한 문제가 발생할까? 그리고 그 문제를 어떻게 해결할 수 있을까?

여기서 가장 중요한 것은 요청 순서에 따라 티켓을 발급하되, 준비된 수량만큼만 발급하는 것이다.

이번 글에서는 위와 같이 ‘동시성’에 대한 고민을 한 경험을 공유하고자 한다.

참고로, 이번 글에서는 개념에 대한 깊은 설명은 따로 하지 않는다. 모르는 개념이 있다면 아래 참고자료에서 개념을 익히도록 하자.

예제 코드

아래는 티켓 예매 상황을 간략하게 구현한 예제 코드이다. (실제로는 더 복잡한 요구사항이 존재하나, 이를 단순화하여 작성하였다.)

아래 예제 코드는 MySQL 8.0 innoDB 스토리지 엔진 기반으로 동작한다.

먼저 사용자가 “티켓 예매” 요청 시 호출되는 TicketingService의 ticketing 메서드이다.

@Transactional
public void ticketing(long ticketId) {
    Ticket ticket = ticketRepository.findById(ticketId)
        .orElseThrow(() -> new IllegalArgumentException("Ticket Not Found."));
    ticket.increaseReservedAmount();
    int ticketNumber = ticket.getReservedAmount();
    reservationRepository.save(new Reservation(ticket, ticketNumber));
}

아래는 Ticket 도메인 코드 중 일부이다. increaseReservedAmount 메서드 호출 시 예매 수량과 총수량을 비교해 예매 가능 여부를 판단하고, 불가능할 시 예외가 발생한다.

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

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

    private int totalAmount;

    private int reservedAmount = 0;

		/***/

    public void increaseReservedAmount() {
        if (reservedAmount >= totalAmount) {
            throw new IllegalArgumentException("Sold out.");
        }
        reservedAmount++;
    }
}

순차적 예매

모든 사용자가 순차적으로 요청한다고 가정하자.

해당 테스트에서는 10장의 티켓을 30명의 사용자가 예매하는 상황을 가정했다.

@Test
void 티켓_순차적_예매_테스트() {
    // given
    int memberCount = 30;
    int ticketAmount = 10;
    Ticket ticket = ticketRepository.save(new Ticket(ticketAmount));

    AtomicInteger successCount = new AtomicInteger();
    AtomicInteger failCount = new AtomicInteger();

    // when
    for (int i = 0; i < memberCount; i++) {
        try {
            ticketingService.ticketing(ticket.getId());
            successCount.incrementAndGet();
        } catch (Exception e) {
            failCount.incrementAndGet();
        }
    }

    System.out.println("successCount = " + successCount);
    System.out.println("failCount = " + failCount);

    // then
    long reservationCount = reservationRepository.count();
    assertThat(reservationCount)
        .isEqualTo(Math.min(memberCount, ticketAmount));
}

실행 결과

해당 테스트는 당연하게도 성공했다. 예상한 수량인 10장만 정확하게 예매되었다.

티켓 예매 내역을 기록하는 Reservation 테이블을 조회해보니, 1~10번 티켓이 각각 한 장씩 예매된 것을 확인할 수 있었다.

아주 성공적이다.

하지만, 티케팅 상황에서는 다수의 사용자가 순차적으로 요청하기보다, 동시에 요청을 하는 상황이 더 일반적이다.

동시 예매

동시에 여러 요청이 발생한 상황을 테스트한 코드는 아래와 같다.

순차 요청 테스트와 같이 10장의 티켓을 30명의 사용자가 예매하는 상황을 가정했다.

@Test
void 티켓_동시_예매_테스트() throws InterruptedException {
    // given
    int memberCount = 30;
    int ticketAmount = 10;
    Ticket ticket = ticketRepository.save(new Ticket(ticketAmount));

    ExecutorService executorService = Executors.newFixedThreadPool(30);
    CountDownLatch latch = new CountDownLatch(memberCount);

    AtomicInteger successCount = new AtomicInteger();
    AtomicInteger failCount = new AtomicInteger();

    // when
    for (int i = 0; i < memberCount; i++) {
        executorService.submit(() -> {
            try {
                ticketingService.ticketing(ticket.getId());
                successCount.incrementAndGet();
            } catch (Exception e) {
                System.out.println(e.getMessage());
                failCount.incrementAndGet();
            } finally {
                latch.countDown();
            }
        });
    }

    latch.await();

    System.out.println("successCount = " + successCount);
    System.out.println("failCount = " + failCount);

    // then
    long reservationCount = reservationRepository.count();
    assertThat(reservationCount)
        .isEqualTo(Math.min(memberCount, ticketAmount));
}

실행 결과

정확히 10장의 티켓이 예매되는 것을 기대했으나, 테스트 결과는 그렇지 않았다.

10장보다 적은 6장만 예매되었음을 확인할 수 있었다.

티켓의 수량보다 많은 요청이 있었는데, 왜 더 적게 예매되었을까?

출력문을 보니 아래와 같이 Deadlock found when trying to get lock; try restarting transaction이라는 문구와 함께 SQL Error가 발생했음을 확인할 수 있었다.

lock을 얻어오는 과정에서 Deadlock 즉, 교착 상태가 발생했다. lock을 얻어오는 행위를 따로 하지 않았는데 왜 교착 상태가 발생했을까?

교착 상태가 발생한 이유

티켓 예매 내역을 의미하는 Reservation 엔티티를 보자.

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

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

    @ManyToOne(fetch = FetchType.LAZY)
    private Ticket ticket;

    private int ticketNumber;
}

Reservation 엔티티에 Ticket 엔티티와의 연관관계를 설정해 줌으로써, DB의 reservation 테이블에 외래 키 칼럼 ticketId가 추가되었다.

MySQL 공식문서에 아래와 같은 내용이 있다.

If a FOREIGN KEY constraint is defined on a table, any insert, update, or delete that requires the constraint condition to be checked sets shared record-level locks on the records that it looks at to check the constraint. InnoDB also sets these locks in the case where the constraint fails.

즉, 외래 키 제약 조건이 있는 테이블에서 레코드를 삽입, 갱신, 삭제할 때 해당 제약 조건을 위반하는지 확인하기 위해 관련된 레코드들에 공유 잠금(S lock)을 설정한다는 뜻이다.

공유 잠금이란 다른 트랜잭션의 데이터 변경을 막고 데이터 일관성을 유지하는 잠금 유형이다. 여러 트랜잭션이 동시에 공유 잠금을 얻을 수 있다. 그러나 공유 잠금을 설정한 트랜잭션이 있을 때, 다른 트랜잭션은 해당 데이터에 대해 배타적 잠금(X lock)을 얻지 못한다.

배타적 잠금은 한 번에 하나의 트랜잭션만이 특정 데이터에 대한 쓰기 작업을 수행할 수 있도록 하는 잠금 유형이다. 다른 트랜잭션들은 쓰기 작업이 끝날 때까지 대기해야 하며, 이를 통해 데이터 충돌 문제를 방지한다.

실제로 innodb의 로그를 확인해보니, 여러 트랜잭션에서 데이터에 잠금을 거는 과정에서 교착 상태가 발생했음을 알 수 있었다. 아래는 로그 내용을 간략화한 것이다.

LATEST DETECTED DEADLOCK
------------------------
Transaction 1 (ID 20238):
- Holding S Lock on data ID 1 in table `ticket`, Waiting for X Lock
Transaction 2 (ID 20240):
- Holding S Lock on data ID 1 in table `ticket`, Waiting for X Lock
Transaction 2 Rolled Back

로그를 토대로 아래와 같이 교착 상태가 걸리는 과정을 알 수 있었다.

트랜잭션 1이 id=1인 데이터에 공유 잠금을 얻었다.
트랜잭션 2가 id=1인 데이터에 공유 잠금을 얻었다.
트랜잭션 1이 id=1인 데이터에 배타적 잠금을 얻고싶지만, 트랜잭션 2에서 해당 데이터에 공유 잠금을 걸어두었기 때문에 대기한다.
트랜잭션 2가 id=1인 데이터에 배타적 잠금을 얻고싶지만, 트랜잭션 1에서 해당 데이터에 공유 잠금을 걸어두었기 때문에 대기한다.
무한 대기상태에 빠진다. 즉, 교착 상태가 발생한다.

연관관계 제거

실제로 교착 상태의 위험성 때문에 외래 키를 사용할 때는 신중해야 한다.

교착 상태의 문제를 해결하기 위해 Ticket과 Reservation간의 외래 키 관계를 제거했다.

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

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

    private Long ticketId;

    private int ticketNumber;

    public Reservation(Ticket ticket, int ticketNumber) {
        this.ticketId = ticket.getId();
        this.ticketNumber = ticketNumber;
    }
}

연관관계 제거 후 다시 동시 예매 테스트를 실행하니, 교착 상태는 발생하지 않았다.

하지만 총 수량은 10장뿐이지만, 30명의 사용자 모두 예매에 성공하는 결과가 발생했다.

어떻게 티켓의 수량보다 많은 사용자가 티켓을 예매할 수 있었을까?

DB의 reservation 테이블을 확인하니 그 이유를 알 수 있었다.

1~10번 티켓이 각각 한 장씩 예매된게 아니라 1번 티켓 10장, 2번 티켓 9장, 3번 티켓 9장, 4번 티켓 2장이 예매되었다. 즉, 하나의 티켓이 여러 사용자에게 발급되는 문제가 발생했다.

순차적으로 예매를 요청할 때는 발생하지 않았던 문제였는데, 동시에 예매를 요청하는 상황에서는 왜 이와 같은 문제가 발생했을까?

순차적 예매 실행 흐름

순차적 예매 시 위 그림과 같이 한 스레드의 작업이 끝난 후 다음 스레드에서의 작업이 시작되기 때문에 충돌이 일어나지 않는다.

동시 예매 실행 흐름

순차적 예매와 달리, 동시 예매 시 위 그림과 같이 한 스레드가 데이터를 읽고 이를 갱신하기 전, 다른 스레드에서 데이터를 읽기 때문에 충돌이 발생한다. 이 이유로 여러 개의 트랜잭션에서 동일한 티켓을 예매할 수 있었다.

이제부터 위 문제 상황에 대한 해결책을 알아보자.

해결책

synchronized

java에서 한 자원에 synchronized 키워드를 붙이면, 멀티 스레드 환경에서 단일 스레드만이 해당 자원에 접근가능하도록 보장한다.

그렇다면 ticketing 메서드에 synchronized 키워드를 붙임으로써, 동시에 들어오는 요청들을 순차적으로 처리할 수 있지 않을까?

한 번 실험해보자.

아래와 같이 ticketing 메서드에 synchronized 키워드를 붙여주고, 동시 예매 테스트를 실행하였다.

@Transactional
public synchronized void ticketing(long ticketId) {
    Ticket ticket = ticketRepository.findById(ticketId)
        .orElseThrow(() -> new IllegalArgumentException("Ticket Not Found."));
    ticket.increaseReservedAmount();
    int ticketNumber = ticket.getReservedAmount();
    reservationRepository.save(new Reservation(ticket, ticketNumber));
}

여전히 결과는 옳지 않았다. 요청이 순차적으로 진행되지 않고, 병렬적으로 진행되었다.

@Transactional 키워드와 synchronized 키워드를 동시에 사용하면 어떤 문제가 발생하는 것일까?

@Transactional이 붙은 메서드가 호출되면, Spring은 프록시 객체를 생성한다.

해당 프록시 객체는 원본 객체를 감싸며, 메서드 호출 전 후로 transaction begin, commit을 수행한다.

여기서 프록시 객체에서 수행되는 transaction begin, commit 코드는 synchronized의 영향을 받지 않는다.

즉, 위 그림과 같이 T1 스레드에서 commit 되기 전 T2 스레드는 메서드를 시작할 수 있다.

이와 별개로 synchronized 키워드에는 몇 가지 단점이 존재한다.

한 스레드가 메서드 작업을 완료할 때까지 다른 스레드들은 대기해야 한다. 이로 인해 프로그램의 성능이 저하될 수 있다.

또한 이는 하나의 프로세스 안에서만 보장이 되기 때문에, 서버가 여러 대인 분산 환경에서는 데이터의 정합성을 보장할 수 없다.

따라서, synchronized 키워드는 우리 문제 상황의 해결책으로 적절하지 않다.

잠금

잠금(Locking) 은 데이터가 읽힌 후 사용될 때까지 데이터가 변경되는 것을 방지하기 위한 조치이다.

잠금 전략으로는 여러 트랜잭션 간 충돌이 일어나지 않을 것이라 가정하는 낙관적 잠금(Optimistic Lock) , 여러 트랜잭션 간 충돌이 일어날 것이라 가정하는 비관적 잠금(Pessimistic Lock) 이 있다.

낙관적 잠금과 비관적 잠금을 통해 문제상황 해결을 시도해 보자.

낙관적 잠금

우선 우리의 코드에 낙관적 잠금을 적용해 보자.

낙관적 잠금은 아래와 같이 @Version 어노테이션을 통해 처리할 수 있다.

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

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

    private int totalAmount;

    private int reservedAmount = 0;

    @Version
    private Integer version;

		/***/
}

DB의 Ticket 테이블에는 아래와 같이 version 칼럼이 추가되었다.

이제 동시 예매 테스트를 실행해 보자.

결과는 여전히 실패이다. 10장이 아닌 5장만 예매되었다.

reservation 테이블을 조회하니, 잠금을 걸지 않은 코드와 차이점을 발견할 수 있었다.

한 티켓이 여러 번 발급된 이전과 달리, 1~5번 티켓이 각각 한 장씩만 발급되었다.

사용자 수를 100명으로 늘리고 다시 테스트를 실행하니 10장이 다 발급되었다.

위와 같은 상황이 발생한 이유에 대해 알아보자.

낙관적 잠금을 사용하면 아래와 같이 버전 정보가 update문의 조건으로 포함된다.

일부 요청에서 데이터를 읽어왔을 때의 버전 정보와 현재 DB의 버전 정보가 일치하지 않아 요청에 실패한 것이다.

위 그림과 같이 트랜잭션 1과 트랜잭션 3은 버전 충돌이 없어 티켓 예매에 성공하였지만, 트랜잭션 2는 트랜잭션 1에서 업데이트한 버전과 충돌이 생겨 update문이 성공적으로 수행되지 못하였다.

낙관적 잠금은 버전 불일치 시 처리를 어플리케이션 레벨에서 담당하게 된다. 이는 티켓 예매 요청이 버전 충돌로 인해 실패할 경우, 직접 예외를 처리하여 재시도하는 로직을 구현해야 함을 뜻한다.

이러한 재시도 로직을 AOP를 통해 구현해보자.

먼저 @Retry 어노테이션을 정의한다.

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

다음은 낙관적 잠금 재시도 로직을 구현한 Aspect이다. 최대 1000번까지 0.1초 간격으로 재시도하도록 했다.

@Order(Ordered.LOWEST_PRECEDENCE - 1)
@Aspect
@Component
public class OptimisticLockRetryAspect {

    private static final int MAX_RETRIES = 1000;
    private static final int RETRY_DELAY_MS = 100;

    @Pointcut("@annotation(Retry)")
    public void retry() {
    }

    @Around("retry()")
    public Object retryOptimisticLock(ProceedingJoinPoint joinPoint) throws Throwable {
        Exception exceptionHolder = null;
        for (int attempt = 0; attempt < MAX_RETRIES; attempt++) {
            try {
                return joinPoint.proceed();
            } catch (OptimisticLockException | ObjectOptimisticLockingFailureException | StaleObjectStateException e) {
                exceptionHolder = e;
                Thread.sleep(RETRY_DELAY_MS);
            }
        }
        throw exceptionHolder;
    }
}

다음과 같이 ticketing 메서드에 @Retry 어노테이션을 적용하면 낙관적 잠금에서 버전이 맞지 않을 때 재시도한다.

@Retry
@Transactional
public void ticketing(long ticketId, long memberId) {
    Ticket ticket = ticketRepository.findByIdForUpdate(ticketId)
        .orElseThrow(() -> new IllegalArgumentException("Ticket Not Found."));
    ticket.increaseReservedAmount();
    int sequence = ticket.getReservedAmount();
    reservationRepository.save(new Reservation(ticket, sequence, memberId));
}

테스트 실행 결과 성공적으로 10장의 티켓이 예매되었지만, 이때 주의할 점이 있다.

그것은 요청이 들어온 순서대로 처리되는 것이 아니라, 재시도의 타이밍에 따라 결정된다는 점이다.

이는 요청의 순서에 따라 티켓 번호를 할당해야하는 상황에서는 적절하지 않다.

비관적 잠금

그러면 이제 비관적 잠금을 통해 해결해 보자.

아래와 같은 방법으로 비관적 잠금을 적용해 보았다. 우리는 Ticket의 reservedAmount를 갱신해줘야 하기 때문에 PESSIMISTIC_WRITE 즉, 배타적 잠금을 걸었다.

public interface TicketRepository extends JpaRepository<Ticket, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select t from Ticket t where t.id = :id")
    Optional<Ticket> findByIdForUpdate(@Param("id") Long id);
}

@Transactional
public void ticketing(long ticketId) {
    Ticket ticket = ticketRepository.findByIdForUpdate(ticketId)
        .orElseThrow(() -> new IllegalArgumentException("Ticket Not Found."));
    ticket.increaseReservedAmount();
    int sequence = ticket.getReservedAmount();
    reservationRepository.save(new Reservation(ticket, sequence));
}

테스트 실행 결과 정확히 10장만 발급하는 데 성공했다.

또한 출력 쿼리문에서 select for update문을 통해서 DB의 특정 row에 잠금을 거는 것을 확인할 수 있었다.

이렇게 비관적 잠금을 통해 동시 예매에서 발생하는 문제상황을 해결할 수 있었다.

하지만 모든 상황에서 비관적 잠금이 효율적인 해결책인 건 아니다.

비관적 잠금은 단일 DB 환경에만 적용 가능하다. 분산 DB 환경에서는 동시성 제어의 효력을 잃는다.

또한, 많은 대기 시간이 발생한다는 단점도 존재한다. 한 트랜잭션이 완료되기 전까지 다른 트랜잭션들은 대기상태에 빠진다. 동시에 많은 요청이 들어왔을 때, 사실상 하나의 요청씩만 작업할 수 있으므로 요청의 수가 많아지면 대기 시간이 길어진다.

우리는 단일 DB 환경이고, 몇만 건의 동시 요청이 예상되는 상황은 아니므로 위의 단점들이 치명적이진 않다고 판단했다. 따라서 간단하게 적용할 수 있고 데이터의 정합성을 보장하는 비관적 잠금을 통한 해결책을 채택했다.

마무리

티켓 예매 예제를 통해 동시 예매 상황에서 발생할 수 있는 문제 상황과 그에 대한 해결책들을 알아봤다.

메세지큐 도입이나 분산 잠금 등의 다른 해결책들도 많이 존재하지만, 우선 가장 간단하게 해결할 수 있는 방법인 비관적 잠금을 통해 해결했다.

서비스가 커지며 분산 DB 환경이 되거나, 현 상황에서 발생할 수 있는 문제가 발견된다면 그때 다른 구조를 도입하도록 하자.

참고 자료

JDBC와 DataSource 이해하기

Mon, 07 Aug 2023 12:00:00 GMT

JDBC란?

JDBC(Java Database Connectivity)는 자바 프로그래밍 언어를 사용해 데이터베이스에 접근할 수 있도록 하는 자바 API이다.
이를 통해서 우리는 데이터베이스에 접속하고, SQL을 실행하고, 이를 통해 데이터를 가져오거나 삭제하는 등 데이터를 다룰 수 있게 된다.
단순하게 데이터베이스와 통신할 수 있는 기술이구나! 라고 생각할 수도 있지만 그보다 더 중요하게 이해해야 할 것이 있다.

JDBC가 등장하게 된 배경

JDBC가 등장하게 된 이유는 무엇일까? 바로 결론부터 말하자면 데이터베이스 접근의 표준화를 위해서다.
데이터베이스에는 Oracle Database, MySQL, PostgreSQL 와 같이 여러 종류의 데이터베이스가 있다는 사실을 알고 있을 것이다.
각각 데이터베이스마다 SQL를 전달하거나 결과를 응답받는 방법들이 다 다르고 데이터베이스의 종류는 수십 개가 존재한다.
JDBC가 존재하기 전에는 이런 데이터베이스마다 존재하는 고유한 API를 직접 사용했었다.
이에 따라 개발자는 기존의 데이터베이스를 다른 데이터베이스로 교체해야 하는 경우에는 데이터베이스에 맞게 기존의 코드를 모두 수정해야 했으며 심지어 각각의 데이터베이스를 사용하는 방법도 새로 학습해야 했다.
따라서 표준이라는 게 필요했으며 JDBC의 표준 인터페이스 덕분에 개발자는 데이터베이스를 쉽게 변경할 수 있게 되었고 변경에 유연하게 대처할 수 있게 되었다.

JDBC를 알아야 하는 이유

JDBC는 JDK 1.1 버전에 출시된 매우 오래된 기술이며 사용하는 방법도 많이 복잡하다.
그래서 JDBC를 직접 사용하기보다는 데이터베이스 접근을 더 편리하게 하고 개발 생산성을 높이기 위한 기술인 SQL Mapper와 ORM(Object-Relational Mapping)을 주로 사용하게 된다.
응?? 그렇다면 JDBC를 굳이 알아야 하나? 라는 의문점이 들 수도 있다.
사실 SQL Mapper나 ORM은 JDBC를 기반으로 동작한다. 이들의 기술은 JDBC의 기능과 개념을 내부적으로 활용하여 데이터베이스와의 상호작용을 처리한다.
따라서 JDBC를 이해하면 SQL Mapper나 ORM이 어떻게 동작하는지 더 잘 이해할 수 있는 베이스가 되며 또한 문제가 발생했을 때 근본적인 문제를 해결할 수 있다.

JDBC 동작 흐름

그러면 이제 JDBC가 어떤 식으로 구성되어 있고 흐름은 어떻게 흘러가는지 알아보자.

먼저 JDBC API를 사용하기 위해서는 JDBC 드라이버를 먼저 로딩한 후 데이터베이스와 연결해야 한다.
JDBC 드라이버는 JDBC 인터페이스를 구현한 구현체라고 생각할 수 있으며
특정 데이터베이스 벤더(Oracle, MySQL, PostgreSQL 등)에 대한 연결과 데이터베이스에 대한 작업을 가능하게 해준다.
(JDBC 드라이버의 구현체를 이용해서 특정 벤더의 데이터베이스에 접근할 수 있음)
JDBC가 제공하는 DriverManager가 드라이버들을 관리하고 Connection을 획득하는 기능을 제공한다.
이 획득한 Connection을 통해서 데이터베이스에 SQL을 실행하고 결과를 응답받을 수 있다.

위의 과정을 코드로 간단하게 살펴보자.

DriverManager를 통해 Connection 획득
Connection을 통해 Statement 생성
질의 수행 및 Statement를 통해 ResultSet 생성
ResultSet을 통해 데이터 획득
리소스 정리

import java.sql.*;

public class Jdbc {
    public static void main(String[] args) {
        // 0. 데이터베이스 연결 정보 설정
        String url = "jdbc:mysql://localhost:3306/mydatabase";
        String username = "myusername";
        String password = "mypassword";

        Connection connection = null;
        Statement statement = null;
        ResultSet resultSet = null;

        try {
            // 1. DriverManger를 통해 Connection 획득
            connection = DriverManager.getConnection(url, username, password);

            // 2. Connection을 통해 Statement 생성
            statement = connection.createStatement();
            String sql = "SELECT * FROM users";

            // 3. 질의 수행 및 Statement를 통해 ResultSet 생성
            resultSet = statement.executeQuery(sql);

            // 4. ResultSet을 통해 데이터 획득
            while (resultSet.next()) {
                int id = resultSet.getInt("id");
                String name = resultSet.getString("name");
                int age = resultSet.getInt("age");

                System.out.println("ID: " + id + ", Name: " + name + ", Age: " + age);
            }
        } catch (SQLException e) {
            e.printStackTrace();
        } finally {
            // 5. 리소스 정리
            try {
                if (resultSet != null) {
                    resultSet.close();
                }
                if (statement != null) {
                    statement.close();
                }
                if (connection != null) {
                    connection.close();
                }
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
    }
}

참고로 DriverManager를 사용하기 전에 Class.forName("com.mysql.jdbc.Driver"); 을 통해 해당 드라이버를 불러와야 하는데
JDBC 4.0 버전 이후부터는 JDBC 드라이버 자동 로딩이 도입되어 생략이 가능하다.
해당 코드에 관한 자세한 설명은 생략하기로 하고 다음으로 넘어가 보자.

커넥션 풀과 DataSource

위의 과정에서 우리는 DriverManager를 통해 데이터베이스 커넥션을 획득했다.
JDBC 드라이버가 데이터베이스와 연결을 맺고 부가 정보를 데이터베이스에 전달한 후 연결 응답을 받으면 커넥션를 생성해 넘겨준다.
커넥션을 사용하고 나면 해당 커넥션을 종료시킨다.

DriverManger 사용시 ▼

하지만 이렇게 매번 커넥션을 생성하기 위해서는 네트워크와 연결하고 서버의 자원을 사용해야 한다.
SQL을 실행할 때마다 커넥션을 획득해야 하므로 연결하는 데에 추가적인 시간이 걸리며 매번 리소스를 사용하게 된다.
그래서 이러한 문제점을 해결하기 위해 커넥션 풀(Connection Pool)을 사용하게 된다.

커넥션 풀 사용시 ▼

데이터베이스와의 연결이 필요할 때마다 매번 새로운 커넥션을 생성하는 대신 미리 생성된 커넥션을 커넥션풀에 보관하고 필요할 때마다 커넥션을 꺼내서 사용하는 것이다.
커넥션 풀을 통해 커넥션을 사용하고 나면 커넥션을 종료하지 않고 커넥션 풀에 반납한다.
이와 같은 방법으로 커넥션을 재사용하게 되면 리소스를 효율적으로 활용할 수 있으며 성능을 높일 수 있다.

이처럼 커넥션을 획득할 때 DriverManager를 통해서 커넥션을 획득하거나 커넥션풀을 통해서 커넥션을 획득하는 등 여러 방법이 존재한다.
그래서 DataSource 인터페이스를 통해서 커넥션을 획득하는 방법을 추상화한다.
어떤 방식으로 커넥션을 획득하는지 상관없이 DataSource 인터페이스를 통해 일관된 방식으로 데이터베이스와 통신할 수 있는 것이다.
또한 인터페이스를 구현한 구현체를 쉽게 교체할 수 있어 애플리케이션의 유연성을 높일 수 있다.
스프링과 스프링 부트에서는 DataSource 인터페이스를 구현한 여러 구현체를 제공하는데
대표적으로 JDBC DriverManager 기반으로 한 DriverManagerDataSource와 HikariCP 커넥션 풀을 기반으로 한 HikariDataSource가 있다.
그래서 만약에 DB에 연결할 때마다 커넥션을 생성해서 획득하는 게 아닌 미리 커넥션을 생성해 놓은 커넥션풀을 사용해서 커넥션을 획득하고 싶은 경우
DataSource의 구현체 DriverManagerDataSource를 HikariDataSource로 바꾸어 끼기만 하면 되는 것이다..! 이로써 커넥션을 획득할 때 리소스를 효율적으로 활용할 수 있고 빠른 속도로 커넥션을 획득할 수 있다.

마치며

지금까지 JDBC와 DataSource에 대해서 알아보았다.
개발을 하면서 데이터 접근 기술을 처음 사용할 때 대부분 JDBC가 아닌 SQL Mapper와 ORM을 먼저 접하게 된다.
그래서 JDBC의 전체적인 동작 흐름에 대한 이해가 부족한 채로 다른 기술을 사용하는 경우가 있으며
또한 JDBC를 직접 사용하지 않는다고 해서 JDBC에 대한 학습을 넘어가는 경우가 있다.
필자 역시 그랬으며 필자와 비슷한 다른 분들에게도 많은 도움이 되기를 바라며 글을 마치도록 하겠다.

참고

What is JDBC? - JDBC 개념
JDBC Programming by Examples with MySQL - JDBC 사용법
JDBC와 커넥션풀

React 18 - 동시성 렌더링

Mon, 31 Jul 2023 12:00:00 GMT

들어가며

2022년 3월, React 18이 발표되었습니다.

여러 변경 사항이 있었지만 그 중 핵심은 Concurrency(동시성)입니다.

기존 experimental 버전에서만 동작하던 ‘concurrent mode’를 공식 지원하게 되었고, 따라서 명칭도 ‘concurrent features’가 되었습니다.

This means there is no concurrent mode, only concurrent features. - React 18 and concurrent features

이 글에선 React의 Concurrency에 대해 가볍게 살펴보고, 이를 사용하기 위해 추가된 useTransition hook과 useDeferredValue hook에 대해서 알아보겠습니다.

Concurrency?

React 공식 문서에선 Concurrency를 다음과 같이 설명하고 있습니다.

Concurrency is not a feature, per se. It’s a new behind-the-scenes mechanism that enables React to prepare multiple versions of your UI at the same time.

즉, 동시성 그 자체로는 기능이 아니고, React에서 여러 버전의 UI를 동시에 준비할 수 있도록 하는 메커니즘이라는 겁니다.

그렇다면 어떤 메커니즘인지, Concurrency와 함께 자주 언급되는 Parallelism(병렬성)과 비교해 보면 이해가 쉬울 것 같습니다.

- DEVIEW 2021, Inside React (동시성을 구현하는 기술)

위에서 설명하고자 하는 것을 간단히 표로 만들어 보겠습니다.

Concurrency	Parallelism
싱글 코어에서도 작동	멀티 코어에서만 작동
동시에 실행되는 것처럼 보임	실제로 동시에 실행 됨
논리적 개념	물리적 개념

요약하자면, 실제론 동시에 실행하지는 않지만, CPU가 현재 실행중인 프로세스를 중단하고 다른 프로세스를 실행하는 작업인 context switching을 하면서 ‘동시에 실행되는 것처럼 보이게 하는 것’이 바로 Concurrency라고 할 수 있겠습니다.

그렇다면 왜 React에서 Concurrency가 필요하게 된 걸까요? 🤔

Blocking Rendering

React 18 이전까지는 렌더링 시 발생하는 문제점이 하나 있었습니다.

브라우저의 메인 스레드는 싱글 스레드이기 때문에 한 번에 한 가지의 작업만 할 수 있습니다.

HTML을 파싱하거나 JS를 실행하거나 화면에 렌더링하는 등, 모든 작업을 하나씩 처리해 나갑니다.

그런데 만약 연산이 오래 걸리는 화면을 렌더링해야 한다면 어떻게 될까요?

페이지 지연이 발생하여 사용자가 불편을 겪는 Blocking Rendering이 발생하게 됩니다.

다음은 해당 문제가 발생하는 예시 코드입니다.

const App = () => {
  const [text, setText] = useState('');

  const filteredItems = filterItems(text);

  const updateFilter = e => {
    setText(e.target.value);
  };

  return (
    <div className="container">
      <input type="text" onChange={updateFilter} />
      <List items={filteredItems} />
    </div>
  );
};

List는 1부터 10000까지의 숫자를 리스트로 출력하는 컴포넌트입니다.

숫자를 입력받을 수 있고, 입력한 숫자를 포함한 것만 필터링하여 출력합니다.

따라서 입력값이 바뀔 때마다 리스트도 업데이트되기 때문에 새로 렌더링해야 합니다.

차이점을 확인하기 쉬운 무거운 작업으로 만들기 위해, 크롬 개발자 도구로 CPU 성능 제한을 걸고 테스트해 보았습니다.

숫자를 입력하거나, 백스페이스를 계속 눌러도 인풋 창은 매우 느리게 응답하는 것을 확인할 수 있습니다.

누가 보더라도 바람직하지 못한 UX인 것 같습니다.

이러한 문제를 해결하기 위해 추가된 기능이 바로 useTransition hook입니다.

`useTransition`과 `useDeferredValue`

바로 예시코드부터 살펴봅시다.

const App = () => {
  const [text, setText] = useState('');
  const [isPending, startTransition] = useTransition();
  const filteredItems = filterItems(text);

  const updateFilter = e => {
    startTransition(() => {
      setText(e.target.value);
    });
  };

  return (
    <div className="container">
      <input type="text" name="user-input" onChange={updateFilter} />
      <label htmlFor="user-input" className={isPending ? 'show' : 'hide'}>
        pending...
      </label>
      <List items={filteredItems} />
    </div>
  );
};

useTransition은 2개의 원소를 가진 배열을 반환합니다.

isPending이라는 boolean 값과, startTransition 함수입니다.

간단하게 코드를 설명하자면, 우선 startTransition으로 setText를 래핑하여 상태 업데이트를 낮은 우선순위로 설정합니다.

그러면 더 우선순위가 높은 이벤트(input값 변경)가 있는 경우 setText는 지연 시키고 이전 값을 보여주게 됩니다.

또한 isPending을 이용하여 현재 지연된 상태라는 것도 보여주고 있습니다.

useTransition을 적용하니 리스트 렌더링과는 별개로, 인풋 창 반응이 빨라졌습니다!

이로써 조금 더 나은 사용자 경험을 제공할 수 있을 것 같습니다.

그런데 비슷한 기능을 하는 또 다른 hook이 있습니다.

바로 useDeferredValue입니다.

이 함수는 useTransition과 비슷하게 우선순위를 낮춰서 concurrent features를 사용할 수 있는 hook입니다.

차이점으론 ‘상태를 업데이트하는 코드’를 래핑하여 우선순위를 낮추는 useTransition과 달리 useDeferredValue는 ‘값’의 업데이트 우선순위를 낮춘다는 것입니다.

It’s useful when the value comes “from above” and you don’t actually have control over the corresponding setState call.

또한 React 팀원인 Dan Abramov의 말에 따르면 useDeferredValue는 상태를 props로 받는 등 제어할 수 없을 때 사용하는 것을 권장하고 있습니다.

그러면 이제 예제 코드에 적용해 보겠습니다.

사실 현재 코드에선 상태를 App에서 제어할 수 있지만, 그렇게 하지 않고 하위 컴포넌트인 List에서 useDeferredValue를 사용해 보겠습니다.

const List = ({ items }) => {
  return (
    <ul>
      {items.map(item => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
};

const List = ({ items }) => {
  const deferredItems = useDeferredValue(items);

  return (
    <ul>
      {deferredItems.map(item => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
};

위에는 기존 List 컴포넌트 코드고, 아래가 바꾼 코드입니다.

기존에 props로 받던 items를 useDeferredValue로 래핑하였습니다.

이후 App에서 useTransition을 사용하지 않고 실행해도,

결과적으로 startTransition을 사용했을 때와 유사한 결과를 얻을 수 있었습니다.

🤔 어디서 본 것 같은데?

hook을 살펴보다 보니 비슷한 기능을 봤던 것 같습니다.

바로 ‘debounce’와 ‘throttle’입니다.

다만 두 방법 Blocking Rendering을 해결하기엔 아쉬운 점이 있습니다.

여러 번 발생하는 이벤트에서 가장 마지막 또는 제일 처음 이벤트만을 실행하도록 하는 debounce와,

여러 번 발생하는 이벤트를 일정 시간 동안 한 번만 실행되도록 만드는 throttle 모두 개발자가 timeout을 지정해 줘야 합니다.

그 말인즉슨, 만약 사용자의 기기 성능은 뛰어난데 timeout이 길게 설정되어 오래 기다리게 되거나,

반대로 오래된 기기를 사용하는데 너무 자주 이벤트가 실행되어 화면이 버벅대면, 사용자는 매우 불쾌한 경험을 하게 된다는 것입니다.

그러므로 concurrent features를 잘 활용한다면, debounce와 throttle을 대체하거나, 혹은 함께 사용하여 더 좋은 사용자 경험을 제공할 수 있을 것입니다.

마무리

지금까지 React 18에 concurrent features가 추가된 배경과, 관련 hook들을 알아보았습니다.

물론 언제나 useTransition, useDeferredValue를 사용하는 것이 좋은 최적화 방법은 아닐 것입니다.

lazy loading, pagination 등의 기법을 사용하거나, 서버 사이드에서 연산하는 등 다양한 방법이 존재합니다.

따라서 무작정 남용하지 않고, 최적화할 수 있는 다른 방법은 없는지 충분히 고민한 후, 적용해야 하겠습니다.

어쨌든 프론트엔드 개발을 하다보면 UX를 우선하여 생각하게 되는 경우가 많은 만큼,

멋진 UX를 위해 고려할 수 있는 수단이 늘어나는 것은 언제나 환영입니다! 😆

참고 자료

@Configuration은 어떻게 빈을 등록하고, 싱글톤으로 관리할까?

Wed, 28 Jun 2023 12:00:00 GMT

어노테이션을 사용해서 빈을 생성하는 방법은 크게 두 가지가 있다.

@Configuration과 @Bean을 사용해 빈 설정 정보 클래스 생성
@Component와 이를 상속한 @Repository, @Controller 어노테이션등을 사용해 자바 컴포넌트 생성

@Configuration은 어떻게 빈을 등록하고, 싱글톤으로 관리하는지 알아보자!

@Configuration이란?

@Configuration은 빈을 등록할 수 있는 어노테이션 중 하나이다.

Spring 공식 문서에서는 다음과 같이 설명하고 있다.

Indicates that a class declares one or more @Bean methods and may be processed by the Spring container to generate bean definitions and service requests for those beans at runtime

@Configuration 어노테이션을 사용하면, 하나 이상의 @Bean이 붙은 메서드가 포함된 빈 설정용 클래스를 만들 수 있다.
스프링 컨테이너는 @Bean이 붙은 메서드를 통해 빈을 생성한다.

@Configuration으로 어떻게 빈을 등록하는지 자세히 살펴보자!

@Configuration 사용 예시

// 빈으로 등록할 클래스
public class MyBean {

    public void sayHello() {
        System.out.println("안녕하세요, MyBean입니다.");
    }
}

@Configuration
public class Config {

    @Bean
    public MyBean myBean() {
        return new MyBean();
    }
}

ApplicationContext는 @Configuration이 붙은 클래스 내부에서 @Bean이 붙은 메서드들을 찾는다.

@Bean 이 붙은 메서드들은 자바 객체를 반환하는 메서드이다.
반환된 자바 객체는 스프링 컨테이너에 빈으로 등록된다.
빈의 이름은 @Bean이 붙은 메서드 이름이 된다. (이 코드의 경우 메서드명과 같은 myBean 빈이 생성된다.)

등록한 빈 가져오기 - getBean()

앞서 말했듯이, ApplicationContext는 @Configuration 클래스가 정의한 빈에 대한 정보를 전부 읽어서 등록한다.

ApplicationContext의 getBean()메서드를 통해 빈에 대한 정보를 가져올 수 있다.

getBean()에 들어가는 인자는 다음과 같다.

getBean(빈의 이름, 빈의 타입);

getBean(빈의 이름)만으로도 빈을 가져올 수 있긴 하지만 Object 타입으로 반환되기 때문에 타입 변환이 필요하다. 빈의 타입을 안다면 명시해 주는 게 좋다.

getBean() 사용 예시

// getBean()을 사용해서 빈 객체를 불러올 수 있음
@SpringBootTest
public class ConfigTest {
    @Autowired
    ApplicationContext applicationContext;

    @Test
    public void test(){
        MyBean bean = applicationContext.getBean("myBean", MyBean.class);
        bean.sayHello();
    }
}

// 실행 결과
안녕하세요, MyBean입니다.

Configuration의 속성

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {

	@AliasFor(annotation = Component.class)
	String value() default "";

	boolean proxyBeanMethods() default true;

}

@Configuration에는 두 개의 속성이 존재한다. 속성 value는 @Configuration이 붙은 클래스가 빈으로 등록될 때의 이름을 설정할 수 있게 해준다.

우리가 이번에 자세히 알아볼 속성은 proxyBeanMethods이다. proxyBeanMethods는 @Configuration이 빈을 싱글톤으로 관리하는 것과 연관이 있는 속성이다. 아래에서 더 살펴보자!

proxyBeanMethods

빈에 대한 프록시 객체를 생성할지 여부를 결정한다.

디폴트 값은 true이다. 즉, 디폴트로 빈에 대한 프록시 객체가 생성된다.

`proxyBeanMethods = true`일 때의 config빈의 상태

`proxyBeanMethods = false`일 때의 config빈의 상태

두 config의 차이가 보이는가? 프록시 객체로 생성한 빈의 클래스 이름을 보면 $$EnhancerBySpringCGLIB&& 라는 게 추가된 것을 알 수 있다.

CGLIB?

cglib is a powerful, high performance and quality Code Generation Library. It is used to extend Java classes and implements interfaces at runtime.

Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

바이트 코드를 가지고 프록시 객체를 만들어주는 라이브러리이다. 런타임 시에 자바 클래스를 상속하고 인터페이스를 구현해 동적 프록시 객체를 만든다.

즉, proxyBeanMethods가 true인 상태에서 사용되는 config 빈은 우리가 직접 생성한 객체가 아니라 CGLIB 라이브러리에서 생성해 준 프록시 객체임을 의미한다.

왜 프록시 객체를 생성할까?

Spring 공식 문서 - Configuration : proxyBeanMethods

Specify whether @Bean methods should get proxied in order to enforce bean lifecycle behavior, e.g. to return shared singleton bean instances even in case of direct @Bean method calls in user code. This feature requires method interception, implemented through a runtime-generated CGLIB subclass which comes with limitations such as the configuration class and its methods not being allowed to declare final.

스프링은 싱글톤 타입인 빈을 만들기 위해 프록시 객체를 생성한다. CGLIB라이브러리를 사용해 Configuration 클래스를 그대로 사용하지 않고, Configuration을 상속한 프록시 객체를 새로 만든다고 한다.

아래는 그 예시이다.

@Configuration
public class Config { // 정의한 Configuration 클래스

    @Bean
    public MyBean MyBean() {
        return new MyBean();
    }
}

public class ConfigExt extends Config { // 실제로 빈을 반환하는 데 사용되는 클래스
	private Map<String, Object> beans = ...;

    @Override
    public MyBean MyBean() {
        if(!beans.containsKey("MyBean")) {
            beans.put("MyBean", super.MyBean());
        }

        return (MyBean) beans.get("MyBean")
    }
}

물론 실제 코드는 이보다 더욱 복잡하다고 한다. 예시용으로 참고만 하자.

기존 클래스를 상속해야 하므로, Configuration은 final 클래스로 생성할 수 없다고 한다.

proxyBeanMethods 적용 예시

`proxyBeanMethods = true` 일 때

사용 예시를 위해 빈으로 등록할 세 개의 클래스를 생성했다. (BabyBean, MotherBean, FatherBean)

세 클래스는 모두 생성이 될 때, BabyBean을 출력한다.

public class BabyBean {

    public BabyBean(){
        System.out.println("애기 빈 : " + this);
    }

}

public class MotherBean {

    public MotherBean(BabyBean babyBean) {
        System.out.println("엄마 빈 : " + babyBean);
    }

}

public class FatherBean {

    public FatherBean(BabyBean babyBean) {
        System.out.println("아빠 빈 : " + babyBean);
    }

}

세 클래스를 @Configuration을 사용해 빈으로 등록해 보자.

@Configuration
public class Config {

    @Bean
    public BabyBean babyBean() {
        return new BabyBean();
    }

    @Bean
    public MotherBean motherBean() {
        return new MotherBean(babyBean());
    }

    @Bean
    public FatherBean fatherBean() {
        return new FatherBean(babyBean());
    }
}

// 실행 결과

애기 빈 : com.example.controlleradvicetest.config.BabyBean@2d0566ba
엄마 빈 : com.example.controlleradvicetest.config.BabyBean@2d0566ba
아빠 빈 : com.example.controlleradvicetest.config.BabyBean@2d0566ba

실행 결과를 보면, FatherBean, MotherBean, BabyBean 생성자로 출력된 BabyBean 객체가 전부 같은 것을 확인할 수 있다.
이는 BabyBean 객체는 한 번 생성된다는 것을 의미한다. (싱글톤)

`proxyBeanMethods = false` 일 때

동일한 @Configuration 클래스 내에서는 proxyBeanMethod가 false 이면 아예 할당이 안 되는 것을 볼 수 있다.

@Cofiguration 클래스를 두 개로 분리해서 의존성을 주입해 주면 작동하지 않을까?

@Configuration(proxyBeanMethods = false) // babyBean 프록시 객체를 생성하지 않는 @Configuration 클래스
public class Config {

    @Bean
    public BabyBean babyBean() {
        return new BabyBean();
    }
}

@Configuration
public class ParentConfig {
    @Autowired
    Config config; // babyBean을 생성하는 @Configuration 빈 객체를 주입받는다

    @Bean
    public MotherBean motherBean() {
        return new MotherBean(config.babyBean()); // babyBean 주입
    }

    @Bean
    public FatherBean fatherBean() {
        return new FatherBean(config.babyBean()); // babyBean 주입
    }
}

public class ConfigTest {

    @Test
    public void test(){
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(Config.class, ParentConfig.class);
        BabyBean babyBean = context.getBean("babyBean", BabyBean.class);
        System.out.println(babyBean);

        MotherBean motherBean = context.getBean("motherBean", MotherBean.class);
        FatherBean fatherBean = context.getBean("fatherBean", FatherBean.class);
    }
}

// 실행 결과

애기 빈 : com.example.controlleradvicetest.config.BabyBean@c8b96ec

애기 빈 : com.example.controlleradvicetest.config.BabyBean@2fa7ae9
엄마 빈 : com.example.controlleradvicetest.config.BabyBean@2fa7ae9

애기 빈 : com.example.controlleradvicetest.config.BabyBean@7577b641
아빠 빈 : com.example.controlleradvicetest.config.BabyBean@7577b641

proxyBeanMethods = false로 설정하니, babyBean이 싱글톤으로 생성되지 않는 것을 볼 수 있다.
motherBean과 fatherBean에 babyBean을 주입할 때, config에서 새로운 babyBean객체를 생성해 주입해 주는 것을 알 수 있다.

@Configuration vs @Component

@Configuration은 내부적으로 @Component를 상속받고 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {
    ...
}

@Component를 사용해서 원하는 클래스를 빈으로 등록할 수 있는데 @Configuration이 왜 필요한 걸까?

포인트는 @Component는 구현한 클래스 위에 선언해야 하지만, @Configuration은 @Bean이 붙은 메서드 내부에서 생성한 객체를 빈으로 등록할 수 있다는 점이다.

외부에서 구현한 클래스를 빈으로 등록하고 싶은데, 이 클래스가 read-only로 쓰였다면 @Component를 클래스 위에 선언할 수 없다. @Configuration을 사용하면, 메서드 내부에서 해당 클래스를 호출해 반환함으로써 빈으로 등록할 수 있다.

또, 하나의 클래스에서 빈들을 관리하고 싶거나, 특정 패키지 내부에 있는 빈들만 스프링 컨테이너에 등록하고 싶은 경우는 @Configuration을 사용하면 편리하게 관리할 수 있다.

마무리

@Configuration으로 빈을 등록하는 방법과 @Configuration이 빈을 싱글톤으로 관리하는 방법에 대해 알아보았다.

@Configuration은 @Bean이 붙은 메소드에서 호출한 객체를 빈으로 등록할 수 있기에 외부 라이브러리의 클래스도 빈으로 등록하는 것이 가능하다. 또한 @Configuration은 빈 객체를 프록시 객체로 만들어 싱글톤으로 관리한다는 것을 알 수 있었다.

여러 개의 빈을 함께 관리하고 싶을 때, 외부 라이브러리 등 개발자가 관리할 수 없는 클래스를 빈으로 등록하고 싶은 경우에는 @Configuration을 활용해 보도록 하자.

참고

최범균 지음, 스프링5 프로그래밍 입문
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/Configuration.html
https://github.com/cglib/cglib/wiki

이미지 사이즈 최적화

Thu, 08 Jun 2023 12:00:00 GMT

들어가며

사용하고자 하는 서비스의 기능은 잘 구현되어 있지만, 사용자에게 제공하는 시간이 느리다면 좋은 서비스라고 할 수 있을까? 사용자의 경험을 고려해 봤을 때, 기능적인 측면도 중요하지만 다양한 기기와 네트워크 환경에서도 원활하게 제공하기 위해서 속도는 중요한 요소이다. 실제로, BBC는 페이지 로드 시간이 1초 추가될 때마다 사용자 수가 추가로 10% 감소한다는 것을 발견했다. 속도 향상을 위해 최적화에 관심을 가지게 되었고, 이 중 이미지를 최적화하는 간단한 방법을 작성해 본다.

웹 페이지 용량에서 이미지가 차지하는 비중

웹 페이지를 보여주기 위해 서버에 리소스(HTML, CSS, Javascript, 이미지, 동영상, 폰트 등)를 요청해 받아온다. 그렇다면 웹 페이지 용량에서 이미지가 차지하는 비중은 얼마일까?

출처: Web Almanac

위의 통계에서 이미지가 웹 페이지 용량의 가장 큰 비중을 차지하는 것을 볼 수 있다. 이미지가 많은 페이지라면 이 용량을 줄이는 것만으로 성능 향상을 가져올 수 있을 것이다. 이미지의 용량을 줄이는 여러 가지 방법 중, 이미지 사이즈 설정을 통한 방법에 대해 알아보자.

렌더링 사이즈에 맞추기

특정 크기로 보이는 이미지에서 이미지 사이즈 설정 전후 웹페이지 로딩 속도 차이를 비교해 보았다. (아래의 내용은 리액트 개발 환경에서 진행했다.)

직경 60px 크기의 원에 이미지를 넣는다고 가정해 보자. 상단의 이미지는 원본 이미지로 용량이 389kb이고, 하단의 이미지는 크기를 축소한 이미지로 용량이 12.8kb이다. 보이는 크기에 맞게 축소했을 뿐인데 용량을 97%나 줄일 수 있다. 이번엔, 여러 네트워크 상황에서 두 이미지를 받아오는 시간을 비교해 보자.

원본 이미지가 현재 사용하는 네트워크 속도에서 2배, Fast 3G 환경에서 4배, Slow 3G 환경에서 4배 더 오래 걸리는 것을 확인할 수 있다.

반응형 이미지

이번에는 데스크톱과 모바일 환경에서 이미지를 생각해 보자. 두 환경은 화면의 크기가 다르므로, 보이는 이미지의 크기도 다르다. 데스크톱의 큰 화면과 모바일의 작은 화면을 비교했을 때, 데스크톱의 큰 이미지는 모바일에서 필요하지 않을 수 있다. 이런 상황에서 반응형 이미지를 사용할 수 있다. 반응형 이미지는 환경에 맞게 적절한 사이즈를 제공해 용량을 줄이는 방법이다.

반응형 이미지는 아래와 같이 사용할 수 있다.

<img
  srcset="horong-480w.jpg 480w, horong-800w.jpg 800w"
  sizes="(max-width: 480px) 440px,
            800px"
  src="horong-800w.jpg"
  alt="밥상 위에 올라간 호롱이"
/>

srcset: 브라우저에 제시할 이미지 목록과 크기를 정의한다. 480w, 800w는 이미지의 고유 픽셀 너비로 단위는 w를 사용한다.
sizes: 화면 크기 조건을 정의한다. 특정 크기일 때 이미지를 크기를 나타낸다.

위와 같이 작성하면 브라우저는 다음과 같이 확인한다.

기기 너비 확인
sizes 목록에서 조건 확인
해당 조건에서 이미지 크기 확인
크기에 근접한 srcset에 작성한 이미지를 불러온다.

69.1kb의 이미지를 모바일 환경에서 29kb로 용량을 58% 줄였다!

실전 적용

테코블에 글을 올리기 전 프로필을 만들었다. 프로필 배경에 적용하고 싶은 사진이 있는데 사진의 크기가 3.7mb이다..! 용량을 줄이기 위해 위에서 작성한 내용을 적용해 보았다.

렌더링 사이즈에 맞추기
- 이미지 자르기: 2,560x2,560 -> 2,560x1,280, 3.7mb -> 2.2mb
- 이미지 사이즈 축소: 2,560x1,280 -> 1240x620, 2.2mb -> 1.3mb
이미지 압축: 75%, 1.3mb -> 227kb

이미지 압축을 하면 불필요한 용량을 줄일 수 있다. 보통 75% 정도(이미지 내용과 용도에 따라 다를 수 있다)의 압축은 사용자가 차이를 인지하지 못해 동일하게 보인다. 비슷한 품질로 용량을 줄일 수 있는 방법이다.

위의 과정을 거쳐 이미지의 용량이 98% 감소했다!

나오며

리소스의 용량은 페이지 로드 속도에 큰 영향을 준다. 그중 이미지는 가장 큰 비율을 차지하고 있다. 이미지 최적화 방법 중에 이미지 사이즈를 줄이는 방법을 정리해 보면 다음과 같다.

렌더링 사이즈에 맞추기: 원본 이미지를 렌더링 되는 사이즈에 맞게 축소하여 용량을 줄인다.
반응형 이미지: 스크린 크기에 맞게 이미지를 제공해 용량을 줄인다.

이외에도 알맞은 이미지 포맷 사용하기, 이미지 압축 등을 통해 이미지의 용량을 줄일 수 있다. 간단한 방법으로 속도와 성능을 높이고 사용자 경험을 개선해 보자!

참고

ExceptionHandler와 ControllerAdvice를 알아보자

Sun, 21 May 2023 12:00:00 GMT

콘솔 애플리케이션을 구현할 때, 우리는 예외를 핸들링하기 위해 try / catch문을 사용했습니다.

그러나 웹 애플리케이션에서는 예외 처리 방법이 조금 다릅니다.

이번 글에서는 스프링을 사용한 웹 애플리케이션 적용할 수 있는 예외 처리 방법인 @ExceptionHandler와 @ControllerAdvice에 대해 알아보겠습니다.

스프링부트의 기본적인 예외 처리

@RestController
public class SimpleController {

    @GetMapping(path = "/errorExample")
    public String invokeError() {
        throw new IllegalArgumentException();
    }
}

라는 예시에서 예외를 던지는 메서드를 호출하는 URL /errorExample에 요청을 보내봅시다.

웹으로 요청을 보낸다면 스프링부트가 제공하는 기본 에러 페이지가 표시됩니다.

BasicErrorController 는 요청의 Accept 헤더 값이 text/html일 때, 예외가 발생하면 /error 라는 경로로 재요청을 보내줍니다.

해당 페이지는 /error 경로에 등록된 기본 에러 페이지입니다.

만약 기본 에러 페이지가 아닌 스스로 작성한 커스텀 페이지를 보여주고 싶다면 뷰 템플릿 경로에 커스텀 페이지 파일을 만들어서 넣어두면 됩니다.

오류 페이지 파일명에 따라 표시되는 웹페이지를 다르게 설정할 수 있습니다.

4xx.html: 400대 오류 페이지
5xx.html: 500대 오류 페이지
404.html: 404 오류 페이지

만약 페이지 변경뿐 아니라 더 상세하게 예외의 내용을 응답에 담고 싶다면, BasicErrorController를 상속한 @Controller 클래스를 만들어 errorHtml() 메서드와 error() 메서드를 재정의해주면 됩니다.

다만 이 방법은 url만 알면 누구나 마음대로 error 페이지에 접근할 수 있다는 단점이 있습니다.

이러한 단점을 @ExceptionHandler를 사용해 해결할 수 있습니다.

@ExceptionHandler

@ExceptionHandler 어노테이션을 사용하면 value로 원하는 예외를 지정하고 이를 핸들링 할 수 있습니다.

예외에 대한 세부적인 정보 또한 응답으로 전달해 줄 수 있습니다.

@RestController
public class SimpleController {

    // ...

    @ExceptionHandler(value = IllegalArgumentException.class)
    public ResponseEntity<String> invokeError(IllegalArgumentException e) {
         ...
				return new ResponseEntity<>("error Message", HttpStatus.BAD_REQUEST);
    }
}

위 처럼 컨트롤러별로 반환하고자 하는 body와 메시지를 예외별로 적절하게 선택하여 세밀한 정보를 제공할 수 있습니다.

@ExceptionHandler는 value 속성으로 지정한 예외뿐 아니라 예외의 자식 클래스도 전부 캐치해 지정된 응답을 반환하게 됩니다. (value 속성을 지정하지 않는다면 메서드의 파라미터에 있는 예외가 자동으로 지정됩니다.)

만약 자식 클래스는 다른 예외 처리를 적용하고 싶다면 다음과 코드를 같이 작성하여 처리할 수 있습니다.

@RestController
public class SimpleController {

    // ...

    @ExceptionHandler(value = IllegalArgumentException.class)
    public ResponseEntity<String> invokeError(IllegalArgumentException e) {
         ...
				return new ResponseEntity<>("부모 클래스", HttpStatus.BAD_REQUEST);
    }

		@ExceptionHandler(value = IllegalArgumentExtendsException.class)
    public ResponseEntity<String> invokeError(IllegalArgumentException e) {
         ...
				return new ResponseEntity<>("자식 클래스", HttpStatus.BAD_REQUEST);
    }
}

@ExceptionHandler는 코드를 작성한 컨트롤러에서만 발생하는 예외만 처리됩니다.

만약 같은 예외에 대해 여러 컨트롤러에서 같은 처리를 하고 싶다면 컨트롤러마다 같은 메서드를 작성해 주어야만 합니다.

즉, 코드의 중복이 발생할 수밖에 없습니다.

ControllerAdvice

@ControllerAdvice는 @Component 어노테이션의 특수한 케이스로, 스프링 부트 애플리케이션에서 전역적으로 예외를 핸들링할 수 있게 해주는 어노테이션입니다.

이를 통해 코드의 중복을 해결할 수 있습니다.

또한, 하나의 클래스 내에서 정상 동작 시 호출되는 코드와 예외를 처리하는 코드를 분리할 수 있습니다.

다음은 @ControllerAdvice 와 @RestConrollerAdvice 의 구현의 일부입니다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@ControllerAdvice
@ResponseBody
public @interface RestControllerAdvice {
    ...
}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface ControllerAdvice {
    ...
}

@Component어노테이션을 붙이면 Component Scan 과정을 거쳐 Bean으로 등록됩니다.

즉, 이 어노테이션을 사용하는 ControllerAdvice 또한 Bean으로 관리된다는 것을 알 수 있습니다.

또한, @RestControllerAdvice는 @ResponseBody 어노테이션이 붙어있으므로 응답을 Json으로 처리한다는 것을 알 수 있습니다.

@ControllerAdvice 어노테이션을 통해 예외를 핸들링하는 클래스를 구현해 보았습니다.

@ControllerAdvice
public class SimpleControllerAdvice {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> IllegalArgumentException() {
        return ResponseEntity.badRequest().build();
    }
}

위 처럼 코드를 작성하게 되면 애플리케이션 내의 모든 컨트롤러에서 발생하는 IllegalArgumentException을 해당 메서드가 처리하게 됩니다.

주의점

여러 ControllerAdvice가 있을 때 @Order어노테이션으로 순서를 지정하지 않는다면 Spring은 ControllerAdvice를 임의의 순서로 호출합니다. 즉, 사용자가 예상하지 못한 예외 처리가 발생할 수 있습니다.

basePackages

만약 여러 ControllerAdvice를 세분화하고 싶다면 basePackages 속성을 이용할 수 있습니다.

작성된 패키지와 하위 패키지에서 발생하는 예외는 해당 ControllerAdvice에서 처리하도록 지정할 수 있습니다.

@ControllerAdvice(basePackages = {"org.woowa.tmp.pkg"}
public class SimpleControllerAdvice {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> IllegalArgumentException() {
        return ResponseEntity.badRequest().build();
    }
}

basePackages 속성을 통해 뷰와 모델을 이용해 직접 페이지를 반환하는 Controller는 예외가 발생하면 직접 예외 페이지를 응답하게 하고, JSON 형식으로 데이터를 주고받는 Controller는 예외가 발생하면 예외에 대한 정보를 JSON 형식으로 응답하게 할 수도 있습니다.

assignableTypes

assignableTypes 속성을 이용하면 클래스 단위로도 ControllerAdvice를 적용할 수 있습니다.

클래스 단위로 사용되는 만큼 basePackages 속성보다 조금 더 세밀하게 처리를 분리해 주고 싶을 때 사용하면 유용합니다.

@ControllerAdvice(assignableTypes = {SimpleController.class}
public class SimpleControllerAdvice {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> IllegalArgumentException() {
        return ResponseEntity.badRequest().build();
    }
}

ResponseEntityExceptionHandler

Spring은 스프링 예외를 미리 처리해 둔 ResponseEntityExceptionHandler를 추상 클래스로 제공하고 있습니다.

ResponseEntityExceptionHandler에는 스프링 예외에 대한 ExceptionHandler가 모두 구현되어 있습니다.

하지만 에러 메시지는 반환하지 않으므로 스프링 예외에 대한 에러 응답을 보내려면 이 클래스를 상속하여 아래 메서드를 오버라이딩 해야 합니다.

public abstract class ResponseEntityExceptionHandler {
    ...

    protected ResponseEntity<Object> handleExceptionInternal(
			Exception ex, @Nullable Object body, HttpHeaders headers, HttpStatus status, WebRequest request) {

		if (HttpStatus.INTERNAL_SERVER_ERROR.equals(status)) {
			request.setAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE, ex, WebRequest.SCOPE_REQUEST);
		}
		return new ResponseEntity<>(body, headers, status);
	}
}

마무리

스프링에서는 @ExceptionHandler @ControllerAdvice를 통해 편리한 예외 처리 기능들을 제공합니다.

또한 여러 가지 속성을 통해 직접 메서드를 오버라이딩하는 것처럼 상세하게 세부 사항들을 지정해 줄 수도 있습니다.

코드가 더 간결해지고, 에러 처리 코드의 위치를 사용자가 유연하게 관리할 수 있다는 장점도 있습니다.

참고

DAO와 Repository

Mon, 15 May 2023 12:00:00 GMT

DAO를 사용해서 DB에 접근할 때, 대부분 DAO 클래스에 Spring의 @Repository를 달아 둡니다. 왜 DAO를 Repository라고 하지? DAO가 Repository의 일종인가? 싶었는데, DAO와 Repository라는 클래스를 함께 사용하는 코드도 꽤 있어서 매우 혼란스러웠습니다.

조금 찾아보니, Spring 공식 문서의 @Repository에 대한 설명은 다음과 같습니다.

Teams implementing traditional Jakarta EE patterns such as “Data Access Object” may also apply this stereotype to DAO classes, though care should be taken to understand the distinction between Data Access Object and DDD-style repositories before doing so.

위의 설명에 따르면 DAO 클래스에 @Repository를 사용할 수 있지만, DAO와 DDD에서 정의된 Repository의 차이를 잘 알고 조심해서 사용해야 한다고 합니다.
그러면 두 개념이 어떻게 다를까요? 나름대로 이해한 바를 아래의 차례로 정리해보겠습니다.

DAO 패턴과 Repository 패턴의 등장 배경
DAO 패턴
Repository 패턴

DAO와 Repository의 등장 배경

Application을 구현할 때, 영속성(Data Persistence)을 가진 영구저장소를 필요로 하는 경우가 많습니다. Application에서 영구저장소에 접근하기 위해서는 각 영구저장소 벤더가 제공하는 API를 사용합니다.
이 때, 만약 영구저장소의 API가 다른 비즈니스 로직들과 함께 존재한다면 어떤 문제들이 발생할까요?

구현체와 로직이 너무 강한 결합을 가진다.
만약 기존의 영구저장소와 다른 벤더의 영구저장소를 사용하게 된다면, 비즈니스 로직들 내부에서 기존 영구저장소의 API를 사용한 모든 부분을 변경해야 합니다. 즉, 객체지향의 5원칙 중 확장에 대해서는 열려있고 수정에는 닫혀 있어야 한다는 OCP(개방-폐쇄 원칙)를 위반하게 됩니다.
계층화가 깨진다.
보통 웹 Application의 구조는 아래와 같은 Layered Architecture로 되어있습니다. 영구저장소는 Infrastructure 계층에 속하고, 비즈니스 로직들은 Application 계층에 속하는데, 영구저장소에 대한 API가 Application 계층에 속하게 되면 계층화가 깨지게 됩니다. 그 결과, Layered Architecture의 이점인 모듈화, 유연성 등이 사라지게 되는 문제가 발생합니다.

그러므로 비즈니스 로직과 영구저장소의 API를 분리할 필요가 있습니다.
즉, 데이터에 접근하는 행위를 추상화, 캡슐화해서 비즈니스 로직과 데이터 접근 로직을 분리해야 합니다. 이를 구현하기 위한 방법으로 DAO 패턴과 Repository 패턴이 등장했습니다.

DAO 패턴

DAO(Data Access Object)는 이름 그대로 데이터에 접근하기 위한 객체입니다. 이름부터 자신이 영속성 계층과 연관이 있음을 버젓이 나타내고 있습니다. 그 자체가 영속성의 추상화이기 때문에 도메인 계층이 아닌 영속성 계층에 속합니다. 그래서 도메인 패키지에 DAO가 있으면 어색한 느낌을 줍니다. 일반적으로 DAO는 DB의 테이블과 일치합니다. 즉, 테이블 중심이라고 할 수 있습니다. 필연적으로, DAO와 매핑되는 엔티티는 테이블의 칼럼과 (거의) 동일한 필드를 가지게 됩니다. 아래의 코드 예시를 살펴보겠습니다.

public class Car {
    
    private final Long id;
    private final String name;
    private final int position;

    public Car(String name, int position) {
        this.id = null;
        this.name = name;
        this.position = position;
    }
    
    //...
  
}

위와 같이 Car라는 클래스가 존재한다고 하겠습니다.

이제 Car 인스턴스의 데이터를 DAO를 사용하여 영속성 계층에 CRUD를 해보겠습니다. 이 때, 일반적이지는 않지만 MySQL과 MongoDB 모두 사용하는 Application이라고 가정하겠습니다. 각 영구저장소의 벤더에 따라서 DAO를 만들어야 하므로 저는 DAO 인터페이스를 하나 만들어서 추상화하려고 합니다. 그리고 각 영구저장소의 벤더에 따라 DAO 인터페이스의 구현체를 만듭니다. 각 구현체에서는 해당하는 영구저장소의 API들을 사용합니다.

public interface CarDao {
    void create(Car car);

    Car read(Long id);

    void update(Car car);

    void delete(Long id);
}

public class MySQLCarDao implements CarDao {

    //DB connection etc...

    @Override
    public void create(Car car) {
        String sql = "INSERT INTO CARS(id, name, position) VALUES(?, ?, ?)";
        //parameter binding etc...
    }

    @Override
    public Car read(Long id) {
        String sql = "SELECT * FROM CARS WHERE id = ?";
        //parameter binding etc...
    }

    //...
  
}

public class MongoDBCarDao implements CarDao {

    //DB connection etc...

    @Override
    public void create(Car car) {
        //doc -> Document 인스턴스
        doc.put(car.getName(), car.getPosition());
        //etc...
    }

    @Override
    public Car read(Long id) {
        //MongoCollection의 find() 메서드 이용
        Document doc = collection.find(eq("id", id));
        //etc...
    }

    //...
}

이처럼, 직접적인 DB와의 상호작용을 추상화하고 쿼리를 실행하는 객체를 DAO라고 하고, DAO를 이용하여 데이터에 접근하는 패턴을 DAO 패턴이라고 합니다.

Repository 패턴

네이버 사전에 등록된 Repository의 의미는 아래와 같습니다.

저장소라는 뜻이네요. Spring 공식 문서에 있는 @Repository에 대한 설명도 다음과 같습니다.

Indicates that an annotated class is a “Repository”, originally defined by Domain-Driven Design (Evans, 2003) as “a mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects”.

즉, Repository는 단순히 저장소라는 의미입니다. 이름에서는 전혀 영속성 계층과 연관이 있음을 알 수 없습니다. (그리고 실제로 연관이 없을 수도 있습니다!) 그저 객체들의 집합(Collection)의 관리를 추상화한 메커니즘일 뿐입니다. 도메인과 아주 밀접한 관계가 있고, 영속성 계층과의 연관이 불확실하므로 Repository의 인터페이스는 도메인 계층에 속해야합니다. 무슨 말인지 감이 오시나요?

조금 더 명확한 설명을 위해 코드를 한번 작성해보겠습니다.

public class Cars {

    private final List<Car> cars = new ArrayList<>();
    
    public void save(Car car) {
        cars.add(car);
    }
    
    public Car read(int index) {
        return cars.get(index);
    }
    
    public void delete(int index) {
        cars.remove(index);
    }
}

Car의 일급컬렉션인 Cars는 필드로 Car의 리스트를 가지고 있습니다. 그리고 이 리스트에 Car를 저장하고, 가져오고, 삭제하는 메서드를 제공하고 있습니다.
그러면 우리는 이 Cars를 Car의 In-memory Repository라고 부를 수 있습니다. 말 그대로 저장소(Car 리스트)의 관리 역할을 하니까요!
그러면 이 Cars라는 클래스는 어디에 위치해야 할까요? Car가 존재하는 도메인 패키지에 있는 것이 자연스럽겠죠?

이처럼, 객체의 정보를 가진 저장소에 대한 관리에 대한 책임을 위임받은 인터페이스인 Repository를 사용한 패턴을 Repository 패턴이라고 합니다.
저장소는 In-memory에 위치할 수도 있고, Application 외부의 어떤 file이 될 수도 있습니다. 어디에 저장하는지가 중요한 것이 아니라, 그냥 어떤 저장소에 데이터를 넣고, 읽어오고, 삭제하는 역할을 해주는 것이 Repository의 역할이니까요.

마찬가지로, Car의 데이터를 영속성 계층에 저장할 때에도 Repository 패턴을 사용할 수 있습니다.

public class CarDatabaseRepository {
    
    public void save(Car car) {
        // Database에 Car를 저장
    }
    
    public Car find(Long id) {
        // Database에서 Car를 조회
    }
    
    public void delete(Long id) {
        // Database에서 Car를 삭제
    }
}

여기서, DAO와 Repository가 혼동이 생깁니다. Repository가 관리하는 저장소가 영속성 계층에 위치할 때, 이 Repository는 DAO와 동일하게 보이거든요. CarDao와 CarDatabaseRepository가 비슷하게 보이지 않나요?
그러나 ”영속성 계층에 위치한 저장소를 관리하는 Repository는 DAO다!“라고 하기 어려운 개념적인 이유가 있습니다.

혹시 CarDao와 CarDatabaseRepository의 차이를 눈치채셨나요?
네, CarDatabaseRepository에는 Update에 관한 메서드가 존재하지 않습니다. 왜 그럴까요? 아래의 코드로 해당 개념을 설명하겠습니다.

public void updateName() {
    Car car1 = new Car("머스탱", 3);
    Car car2 = new Car("박스터", 1);
  
    Cars cars = new Cars();
  
    cars.save(car1);
    cars.save(car2);
  
    car1.setName("리오의 머스탱");
    car2.setName("박스터의 박스터");
  
    Car savedCar1 = cars.read(0);
    Car savedCar2 = cars.read(1);
  
    System.out.println(savedCar1.getName()); // 리오의 머스탱
    System.out.println(savedCar2.getName()); // 박스터의 박스터
}

위의 코드에서 마지막 출력 때 주석에 달린 대로 각 Car들의 변경된 이름이 나오는 것이 너무나 자연스러워보입니다. savedCar1이 Car1과 동일하고, savedCar2가 Car2와 동일할테니까요. 이게 바로 Repository에는 Update 메서드가 없는 이유입니다.

StackOverFlow의 글 에 이런 내용이 있습니다.

A method like Update is appropriate on a DAO, but not a Repository. When using a Repository, changes to entities are usually tracked by a separate UnitOfWork.

CRUD는 DB의 가장 기본적인 기능이고, DAO는 DB의 테이블과 밀접하게 연관되어 있습니다. 그러므로 DAO에 Update 메서드가 존재하는 것이 너무나 당연합니다.
그러나 Repository는 다릅니다. 위의 코드에서처럼 Car1과 Car2가 Cars 내부의 Car리스트에 담긴다고 해서 새로운 객체가 되는 것이 아니기 때문에, 이름을 변경하면 당연히 변경된 이름이 나올 겁니다.
그런데 저장소가 영속성 계층에 위치한다면 어떨까요? application에서 Car1과 Car2의 이름을 바꾸면 자동으로 DB Row 내용도 변할까요? 당연히 바뀌지 않을 겁니다. 그치만 Repository 패턴을 사용한다면 DB의 내용도 당연하게 바뀌어야 합니다. 저장소가 어디에 위치하냐에 따라서 Repository의 책임이 달라지면 안되니까요. 그러므로 외부 저장소(DB나 File 등)에 대한 Repository는 Update 메서드 없이 객체의 변경이 저장소에 반영되도록하는 기능을 지원해야합니다.
이것이 Repository가 Update 메서드를 지원하지 않는 이유이고, JPA의 영속성 컨텍스트에서 변경 감지가 이루어지는 이유입니다. 인용한 문장에 있는 UnitOfWork라는 디자인 패턴의 개념을 간단하게 설명해봤습니다. 더 자세히 알고 싶으시다면 링크된 블로그를 참고해주세요!

마치며

이상으로 DAO와 Repository에 대해 알아봤습니다.
간단한 어노테이션이라도 정확하게 개념을 알아서 적절하게 사용할 수 있도록 노력하려고 합니다. 긴 글 읽어주셔서 감사합니다!

참고

데드락 해결 모험기

Mon, 21 Nov 2022 15:00:00 GMT

용어 설명

Cycle이란, 사용자가 특정 챌린지에 도전할 때 생성되는 객체이다. 비즈니스 규칙 상 하루에 한번씩 총 3일을 인증해야 하며, 하루에 여러번 인증을 할 수는 없다. 아직 인증을 하지 않은 상황에서 활동을 인증하게 되면 인증 내역인 CycleDetail이라는 객체가 생성된다. 따라서, 3일 동안 정상적으로 하루헤 한번씩 3번 인증을 하게 되면 총 3개의 CycleDetail이 생성되고, 하나의 Cycle은 최대 3개의 CycleDetail을 가지게 된다

문제 상황(1)

QA 시 일반적 시나리오에서는 Cycle의 인증이 예상한대로 동작했으나, “하나의 계정에 두 기기가 접속하여 동일한 Cycle을 인증하는 경우”가 궁금해져 QA를 진행하게 되었다. 이 때 “한번에 하나의 인증만 이루어져야 한다”라는 비즈니스 로직에 의해 인증하려는 Cycle에 대응되는 CycleDetail이 하나만 있는 것을 기대했으나, 실제로는 2개 이상의 CycleDetail이 남아있는 문제가 발생하게 되었다.

전형적인 동시성 문제로 판단 되었고, 이에 대한 해결책은 lock을 거는 것으로 알고 있었다. 하지만 이미 mysql 내부에서 우리도 모르는 lock을 비일비재하게 걸고 있기 때문에 추가적으로 lock을 걸었을 때 다른 쿼리들이 예상치 못하게 대기하는 상황이 발생할 수 있을 수 있다. 따라서, 최대한 lock을 지양한 채로 해당 문제를 풀고 싶었다.

문제가 되는 부분은 CycleDetail이 두번 이상 삽입되는 것이 문제이기 때문에 이것을 방지한다면, 문제를 해결하는 것과 같다고 판단하여 CycleDetail의 외래키인 cycle_id와 현재 몇번째 인증인지를 나타내는 progress를 복합 unique 제약조건을 걸게 되면 삽입이 한번만 이루어질 것이라고 예상하였다

문제 상황(2)

결과적으로는 하나의 기기는 성공하고 다른 기기는 실패하는 것을 확인하였으나, 문제는 에러 메세지였다. 실패한 쪽에서의 예상되는 에러 메세지는 미리 정의한 커스텀한 에러 메세지인 “인증 시간이 지났습니다” 였으나, 실제 에러 메세지는 “알 수 없는 에러가 발생하였습니다”가 나타났다. 로그를 분석해보니, 데드락이 발생하였다는 에러 로그를 마주하게 되었다.

가설 수립 및 원인 규명

따라서, 실제 Mysql에서 어떤 쿼리가 데드락을 발생시켰는지 알고자 DB 서버에 접속하여 확인해보았다. 이 때 데드락을 발생시킨 직접적인 원인이 되는 쿼리는 Cycle의 progress를 바꾸는 Update문과 CycleDetail을 insert하는 쿼리였다

문제를 해결하기 위한 unique 제약조건이 추가된 설정을 기준으로 트랜잭션의 각 흐름에 따른 lock의 획득 과정을 그림으로 도식화하면 다음과 같다

먼저 트랜잭션 1이 insert문을 통해 이유는 알 수 없지만 Cycle에 대한 shared lock을 걸게 된다. 설명의 편의를 위해 트랜잭션 1이 Cycle에 대해 건 shared lock을 초록색 타원으로 표기하였다

이후 트랜잭션 2가 역시 insert문을 통해 이번에도 이유는 알 수 없지만 Cycle에 대한 shared lock을 걸게 된다. 이 때 shared lock은 말 그대로 lock간의 공유가 가능하기 때문에 여기서 데드락이 발생하지는 않는다. 마찬가지로 설명의 편의를 위해 트랜잭션 2가 Cycle에 대해 건 shared lock을 파란색 타원으로 표기하였다

먼저 insert한 트랜잭션 1에 의해 unique 제약조건으로 생성된 인덱스에 CycleDetail이 삽입이 되고, 이에 대한 exclusive lock이 걸리게 된다. 따라서 트랜잭션 2에서의 insert 쿼리는 첫번째 트랜잭션이 획득한 exclusive lock에 의해 대기하게 된다

이후 트랜잭션 1이 Cycle의 상황을 바꾸려한다. 이 때 데드락이 발생하게 되는데, 그 이유는 트랜잭션 1의 입장에서는 update하기 위해서는 트랜잭션 2의 Cycle에 대한 shared lock을 풀어야 하고, 트랜잭션 2의 입장에서는 insert하기 위해서는 트랜잭션 1의 CycleDetail에 대한 exclusive lock을 풀어야 하기 때문이다. 따라서, unqiue 제약조건으로는 데드락 문제를 해결할 수 없었다

그런데 사실 Cycle에 대한 shared lock이 애초에 없었다면 데드락이 발생하지는 않았을 것이다. 따라서 왜 설정하지도 않은 shared lock이 발생하는지에 대해 알아보기로 하였다. 여러 가설이 있었으나 가장 유력한 가설은 학부 시절 데이터베이스 개론에 배웠던 “참조 무결성 원칙”이 공유락을 발생시킨다는 가설이었다

참조 무결성이란 외래키는 참조할 수 없는 값을 가질 수 없다는 규칙이다. CycleDetail을 삽입할 때 왜래키인 cycle_id를 참조하고 있다. 해당 쿼리를 보는 개발자의 입장에서는 모든 맥락을 이해하기 때문에 insert 쿼리에 참조하는 cycle_id는 존재한다는 사실을 알지만, DB입장에서는 전혀 그렇지 않기 때문에 현재 쿼리가 참조 무결성을 위반할 수 있다고 생각할 수 있다. 실제로 문제 해결을 위해 참고하던 Real MySQL에서도 외래키와 데드락의 연관성에 대해 지적하고 있었다.

“외래키는 부모테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하므로 잠금이 여러 테이블로 전파되고, 그로인해 데드락이 발생할 수 있다. 그래서 실무에서는 잘 사용하지 않는다.”

해결책

Optimistic lock

unique 제약 조건에 의해서도 문제 상황을 풀 수는 없었다. 또한 insert와 delete의 쿼리를 바꿔버리게 되면 Cycle에 대한 shared lock을 두 트랜잭션 모두 들고 있을 필요가 없기 때문에 데드락이 발생하지 않을 수 있다는 생각이 들었다. 하지만, JPA는 insert 쿼리에 대해서는 쓰기 지연을 하지 않고 즉시 DB로 보내기 때문에 굳이 update를 먼저 실행시키고 싶다면 강제적으로 flush를 해줘야 한다. 하지만 그렇게 되면 도메인 레벨에서 DB 관련된 로직이 불필요하게 들어가게 되기 때문에 도메인의 책임이라는 관점에서는 부자연스럽다고 판단하였다

그런데, 데드락을 발생시키는 상황 자체가 상당히 낮은 확률로 이루어지기 때문에 Optimistic lock을 사용하는 것이 좀 더 자연스럽다고 판단하여 Optimistic lock을 해당 문제를 해결해보려고 시도했다. 또한, 기존의 unique 제약조건에 의해 insert시 오히려 추가적인 배타 락이 발생하며 데드락 문제를 해결하지 못하기 때문에 unique 제약 조건은 제거하기로 하였다. 그러나 결론적으로 Optimistic lock도 데드락을 해결해주지 못했다

초기 상황은 위 그림과 같다. 초기의 Cycle의 version은 0으로 초기화 된 상황이다. 단순히 조회만 하였기 때문에 version의 변화는 없다

이후 트랜잭션 1이 CycleDetail을 삽입하게 된다. 이 때 참조 무결성 원칙에 의해 트랜잭션 1은 Cycle에 대한 shared lock을 점유하게 된다. 이 때 주의해야 할 점은 비록 CycleDetail이 삽입된다고 하더라도 Cycle의 version은 증가하지 않는다는 점이다. 설명의 편의를 위해 트랜잭션 1이 Cycle에 대해 건 shared lock을 주황색 타원으로 표기하였다

트랜잭션 2 역시 후속과정으로 CycleDetail을 삽입하게 된다. 같은 논리에 의해 트랜잭션 2 역시 Cycle에 대한 shared lock을 획득한다. 설명의 편의를 위해 트랜잭션 2가 Cycle에 대해 건 shared lock을 청록색 타원으로 표기하였다

위 그림 8에서는 트랜잭션 2가 트랜잭션 1이 점유한 shared lock에 의해 update 쿼리가 대기하는 모습이다. 결국 versioning도 쿼리가 실행되어야 하기 때문에 대기에 의해 versioning이 이루어지지 않는다

현재 트랜잭션 1이 바꾸려는 Cycle의 version이 최신이므로, 트랜잭션 1의 update문이 실행되게 된다. 그러나, 트랜잭션 1도 update문이 위 그림 8에서의 논리에 의해 대기하게 된다. 따라서, 양 측이 commit이나 rollback이 되지 않는 이상 두 트랜잭션 모두 update 쿼리가 무한히 대기하게 된다. 따라서, Optimistic lock으로도 데드락을 해결할 수 없다. 결국 최종적으로 mysql에서 트랜잭션 1과 2 중 임의의 트랜잭션을 rollback하게 되고, 최종적으로는 Cycle의 versioning이 0에서 1로 이루어진다
Pessimistic lock

따라서, “데드락을 해결”하기 위해서는 남은 선택지가 Pessimistic lock밖에 없었고, 해당 방법으로 동시성 문제를 해결하게 되었다. Pessimistic lock이 데드락을 해결하는 방법은 아래 그림과 같다

위 그림은 트랜잭션 1이 Cycle에 대한 exclusive lock을 거는 모습을 도식화한 모습이다. 설명의 편의를 위해 트랜잭션 1이 Cycle에 대해 건 exclusive lock을 보라색 타원으로 표기하였다

exclusive lock은 exclusive lock 사이의 공유를 허용하지 않으므로 트랜잭션 2의 Cycle에 대한 select문은 대기하게 된다

이후 트랜잭션 1은 insert와 update를 정상적으로 진행되게 된다. 이 때 데드락은 발생하지 않는데, 트랜잭션 2가 select 조차 하지 못하고 대기 중이기 때문이다. 따라서 트랜잭션 1은 무사히 커밋되게 된다

트랜잭션 1이 커밋되었기 때문에 보라색 타원으로 나타내었던 트랜잭션 1의 Cycle에 대한 exclusive lock이 해제되었다. 따라서 트랜잭션 2는 비로소 select 쿼리를 실행할 수 있다. 그러나, 이미 상태가 바뀐 Cycle에 대해 트랜잭션 2가 update를 하려하는 순간, 서비스 레이어에서 작성된 방어 로직에 의해 DB에서 예외가 발생하지 않고 Application단에서 정의된 커스텀 예외가 발생하게 된다. 따라서 데드락은 발생하지 않는다. 아래는 Pessimistic lock을 설정한 코드이다
- Repository Layer
- Service Layer
- Test code

의문점

첫번째 의문점

그런데 데드락을 해결한 이후, 한가지 의문점이 들었다. “과연 아무것도 하지 않았을 때, 즉 락이나 unqiue 제약조건, versioning 따위를 하지 않았을 때도 데드락이 발생하는가?”이다. 실제로 테스트를 해본 결과 동시성 문제와 데드락 문제가 동시에 발생하는 것을 알 수 있었다. 동시성과 데드락이 양립할 수 없다고 생각했으나, 아래와 같은 흐름이라면 충분히 양립할 수 있다는 것을 파악하였다

우선 트랜잭션 1과 트랜잭션 2의 관계부터 살펴보자. 트랜잭션 1은 트랜잭션 2보다 더 빨리 insert를 하였고 그에 따라 Cycle에 대한 shared lock을 획득한다. 트랜잭션 2는 트랜잭션 1이 update문을 실행하기 전에 동일한 Cycle에 대한 shared lock을 역시 획득한다. 따라서 트랜잭션 1이 update를 수행하게 되면 트랜잭션 2가 가진 shared lock에 의해 update가 대기하게 된다. 이후 트랜잭션 2가 update를 수행하려는 순간, 서로의 shared lock을 놓아야 update가 어느 한쪽에서라도 진행되기 때문에 데드락이 발생한다. 데드락이 발생하였기 때문에 mysql에서는 트랜잭션 1과 트랜잭션 2 중 어느 하나를 롤백시켜야 한다. 이 때 설명의 편의를 위해 트랜잭션 2를 rollback한다고 하자. 따라서, 트랜잭션 1은 정상적으로 커밋이 된다 다음으로 트랜잭션 1과 트랜잭션 3의 관계를 살펴보자. 트랜잭션 3은 트랜잭션 1이 commit되기 이전에 시작이 됨을 알 수 있다. 따라서, mysql의 기본 트랜잭션 격리 속성인 REPEATABLE READ에 의해 아직 상태가 바뀌지 않은 Cycle을 획득하게 된다. 이후 트랜잭션 1이 커밋이 되고, 그 이후에 트랜잭션 3이 insert를 수행하면서 Cycle에 대한 shared lock을 획득하게 된다. 이 시점에는 이미 트랜잭션 1이 commit 되었기 때문에 현재 Cycle에 대한 shared lock은 트랜잭션 3만 가지고 있다 따라서, 트랜잭션 3은 무난하게 update 쿼리까지 수행하게 되고, commit까지 완료된다. 따라서, 같은 Cycle에 대해 트랜잭션 1과 트랜잭션 3에서 수행한 insert에 의해 동시성 문제가 발생하게 된다. 왜냐하면 “하루에 한번만 인증할 수 있다”라는 규칙에 의해 insert가 한번만 정상적으로 이루어져야 하기 때문이다. 따라서, 위 경우라면 충분히 데드락과 동시성 문제가 양립할 수 있다
두번째 의문점

추가로, “이 문제를 DB에 의존하여 풀지 않고 application단에서 풀 수 없을까?”라는 의문점도 생각해보았다. 자바에서의 대표적 동시성 처리 방법인 synchronized와 동시성을 지원하는 자료구조인ConcurrentMap을 이용하여 문제를 해결할 수 있다고 생각했다. 코드는 아래와 같다
- Concurrency Layer
- Controller Layer
- Service Layer
- Test code
  
  위 코드가 정상적으로 동작하는 이유는 SyncManager 객체가 멀티스레드에 의해 각자 생성된다고 하더라도, 특정 id에 대한 lock 객체(여기서는 Object 객체)는 static 변수인 ConcurrentMap에 의해 공유되기 때문이다. 또한, 특정 id가 ConcurrentMap가 없다면 computeIfAbsent를 통해 락 객체를 삽입하게 되는데, ConcurrentMap의 특성 상, computeIfAbsent는 각 id별로 atomic하기 때문에 lock 객체의 동일성을 보장할 수 있다
  
  여기서 어차피 lock 객체가 같다면 SyncManager의 getLock을 접근 제어자를 private에서 public으로 바꾸고 Service Layer에서 별도의 synchronized block으로 처리하면 되지 않느냐고 생각할 수 있다. 하지만, 이미 비즈니스 로직을 담당하는 메소드에 @Transactional이 붙어있기 때문에 원하는 대로 동작하지 않는다. 이유를 간단히 말하면 @Transactional은 프록시로 동작하기 때문이다. 따라서, 프록시로 진행되는 부분은 동시성 제어를 받지 않는다
  
  위 그림에서 스레드 1이 먼저 lock 객체를 획득하여 비즈니스 로직을 진행하게 된다. 따라서 스레드 2는 프록시 객체에서 target 객체의 메소드를 실행할 수 없기 때문에 대기하게 된다. 이 때 스레드 1에서 실행했던 비즈니스 로직이 끝나게 된다. 이후는 다시 프록시가 주체가 되어 진행이 된다. 그런데, 바로 비즈니스 로직이 끝나고 프록시의 로직이 실행되는 순간, lock 객체에 대한 획득을 잃어버리게 되므로 스레드 2의 target 객체가 비즈니스 로직을 실행할 수 있는 빌미를 제공한다. 왜냐면 스레드 1의 현재 실행 주체는 프록시이기 때문이다. 따라서, 경우에 따라 동시성 문제가 발생할 수도 있고 데드락 문제가 발생할 수도 있다.
  
  결국 원하는 결과를 만들어내기 위해서는 비즈니스 로직 외부에서 synchronized로 Service Layer의 비즈니스 로직을 감싸주어야 한다. 그렇기 때문에 Controller Layer에서 Concurrent Layer를 통해 Service Layer의 로직을 실행하는 흐름으로 진행된다
세번째 의문점

하나의 WAS와 하나의 DB라면 synchronized로 해결할 수 있고, 복수의 WAS와 하나의 DB라면 DB lock을 통해 해결할 수 있음을 파악하였다.
그렇다면 최종적으로 “복수의 WAS와 복수의 DB라면 해당 문제를 어떻게 해결할 수 있을까?”라는 의문이 발생하였다. 코치님들에게 자문한 결과,
“분산 락”을 통해 해결할 수 있다고 하셨다. 구현하는 방법은 Redis나 ZooKeeper, 혹은 mysql에서도 named lock을 통해 직접 구현할 수 있다고 한다

마무리

그럼에도 불구하고 현재 exclusive lock을 걸어서 해결한 것이 최선인지는 솔직히 의문이다. 결국 lock을 건다는 것은 성능상으로 매우 위험한 선택이기 때문이다. 이미 이에 대해 팀에서 많은 논의를 거쳤고 각종 테스트를 통해 lock에 의한 유의미한 성능 저하는 관찰되지 않았으나, 예상치 못한 부분에서 성능 저하가 발생할 수 있는 가능성이 있다는 점은 부인할 수 없다.

결국 데드락의 직접적 원인인 “외래키 제약조건”을 아예 삭제하는 것이 가장 문제를 근본적으로 해결하는 방법이라고 생각한다. 즉, 테이블을 최초에 잘못 설계한 측면이 있다고 생각한다. 결국 처음 설계할 때부터 외래키 제약이 없도록 설계했으면 데드락이 발생하지 않고 단순히 동시성 문제에서 끝났을 것이기 때문이다.

외래키를 없애면 데드락 문제를 해결할 수 있지만 그럼에도 불구하고 발생가능성이 있는 동시성 문제를 반드시 죄악시해야 하는 것인가에 대한 의문이 남는다. 사실 하나의 Cycle에 대해 동시에 여러번 인증이 이루어져도 금전적이거나 프로젝트 사이트에서 이용상 불편한 점, 혹은 다른 사용자에게 피해를 입히는 점이 없다면 사실 데이터 정합성이 맞지 않더라도 사용자에게는 하루에 하나만 인증되는 것처럼 보여주기만 해도 문제가 없다

어쨌든 처음으로 동시성 문제를 마주하였는데 생각보다 알아야 할 내용이 많았다. 또한 전공 시간에 배운 “참조 무결성 원칙”이 직접적인 원인으로 나타난 문제 상황을 마주하여 흥미로웠다. 일상적으로 쓰이는 쿼리에 mysql이 어떻게 내부적으로 lock을 수행하는지도 조금이나마 알게 되어 흥미로웠으나, 이해하는 과정이 매우 어려웠다. 마지막으로 synchronized와 @Transactional을 같이 사용할 때의 문제까지 추가되어 해결하고 글을 작성하기까지 오랜 시간이 걸려서 해결하는 내내 힘들었다. 그러나, 하나의 문제의 원인을 파악하고, 그에 대한 여러 해결책을 적용해보고 각 결과의 원인을 파악하는 것은 재미있었고 결과적으로 lock에 대한 학습을 많이 하게 된 계기가 되어 뿌듯하고 쉽게 하기 힘든 경험을 해서 좋았다. 마지막으로 해당 문제 해결에 도움을 주신 구구 코치님, 토미 코치님, 제이슨 코치님, 관심가지고 논의해준 스모디 백엔드 크루들인 토닉,더즈,조조그린에게 감사한 마음을 전하고 싶다

Reference

백은빈, 이성욱 지음 Real MySQL 8.0
김연희 지음, 데이테베이스 개론 2판
synchronized와 @Transactional 을 동시에 사용 시 문제점

AOP에 대한 사실과 오해 그런데 트랜잭션을 사알짝 곁들인..

Tue, 15 Nov 2022 13:10:00 GMT

들어가며

트랜잭션을 공부하다보면서 자연스럽게 AOP에 대해 접하게 되었습니다. AOP를 사용하게 되면서 직접 경험했던 사실과 오해에 대해서 공유하려고 합니다.

첫 번째 사실: public이외의 메서드는 AOP가 걸리지 않는다.

실제 인텔리제이에서 private 메서드에 @Transactional 을 선언하면 위와 같이 컴파일 에러를 띄워줍니다. 해석해보자면 private을 사용하지 말라는군요!

왜 private 메서드에는 `@Transactional`이 붙을 수 없을까요?🤔

해당 원인을 파악하려면 먼저 프록시에 대해서 알아봐야합니다. 스프링 aop에서 프록시는 크게 JDK Dynamic proxy또는 CGLIB으로 작동합니다. 그리고 spring boot 1.4 버전 이후부터는 default로 CGLIB을 사용합니다.

CGLIB은 동적으로 상속을 통해 프록시를 생성합니다. 따라서 private 메서드는 상속이 불가능하기 때문에 프록시로 만들어지지 않는것이죠!

그러면 아래처럼 protected나 public으로 메서드를 만들면 정상적으로 트랜잭션이 동작할까요? 정답은 protected일 때 또한 정상 동작하지 않습니다🥲

분명히 인텔리제이로 확인을 해보면 컴파일 에러는 나오지 않는데 말이죠. 해당 이유는 앞서 말했던 JDK Dynamic proxy 가 원인이었기 때문입니다. JDK Dynamic proxy는 인터페이스를 기반으로 동작합니다. 따라서 protected 메서드에서는 프록시가 동작할 수 없는 것이죠. 그래서 스프링에서는 일관된 AOP적용을 위해서 protected로 선언된 메서드 또한 트랜잭션이 걸리지 않도록 한 것입니다. 즉, 프록시 설정에 따라 트랜잭션이 적용되었다 안되었다 하는 변칙적인 결과를 막기 위함인거죠.

두 번째 사실: 같은 클래스내에서 트랜잭션이 걸린 메소드를 호출하면 트랜잭션이 작동하지 않는다.

public class A {
    public void init() {
        this.progress();
    }

    @Transactional
    public void progress() {
    }
}

예를들어 다음과 같은 상황에서 progress()는 정상적으로 트랜잭션이 적용될까요?

이번에도 안됩니다.

Spring AOP에서 프록시의 동작 과정을 보면 프록시를 통해 들어오는 외부 메서드 호출을 인터셉트 하여 작동합니다. 바로 이러한 성격때문에 self-invocation이 라고 불리는 현상이 발생합니다.

프록시의 내부 빈에서 프록시를 호출 했다는 것이죠. 그림으로 보면 이해하는데 도움이 될것같아서 그려봤습니다.

main메서드에서 그림과 같이 A의 init()를 호출하고 init()에서 progress()를 호출하면 그림과 같이 프록시 내부에서 호출하게 됩니다. 따라서 proxy가 인터셉트하지 못해서 트랜잭션이 동작하지 않는것입니다.

오해: 그렇다면 내부 메서드에서 호출은 AOP적용이 불가능하다

해당 주장은 사실이 아닙니다. 공식문서를 잘 보면 해결 방법이 있습니다.

self-invocation(in effect, a method within the target object calling another method of the target object) does not lead to an actual transaction at runtime…

타겟 내에서 타겟의 다른 메서드를 호출할 때, 런타임에 실제 트랜잭션이 작동하지 않는다고 합니다. 즉, 런타임 시점에 작동은 안 하지만 이것을 컴파일 시점에 적용하면 된다는 것이죠.

그렇다면 어떻게 컴파일 시점에 프록시를 적용할 수 있을까요?

스프링에서 AOP를 구현하는 방식에는 스프링 AOP도 있지만 AspectJ라는 강력한 도구도 있습니다. AspectJ는 스프링AOP와 다르게 컴파일 시점에 위빙이 이루어집니다. 따라서 AspectJ를 사용하면 self-invocation문제를 해결할수 있는것이죠!

그런데 만약 Spring AOP를 쓰고있는 상황에서 이런 문제가 발생하면 어떡하죠? 이럴경우 다른 방법도 존재합니다!

첫번째 방법은 `AopContext를 이용하는 방법`입니다.

AopContext의 currentProxy() 메서드는 현재 AOP proxy를 반환합니다. 이번엔 코드로 확인해봅시다.

@Aspect
@Component
public class AopService {

    @Pointcut("execution(void kitchenpos.application.MenuService*.progress(..))")
    public void pointCut() {

    }

    @Before("pointCut()")
    public void before() {
        System.err.println("aop works!!");
    }
}

우선 aop를 적용해줍니다. progress() 메서드가 동작하기 전에 aop works!! 라는 에러 메시지를 출력해주는 aop입니다.

public void init(){
    this.progress();
}

public void progress(){
    System.out.println("PROGRESS");
}

그리고 다음과 같이 실행을 해주면 아래와 같이 적용되지 않습니다.

이번에는 AopContext를 활용하여 아래와 같이 수정해보겠습니다.

public void init() {
    ((MenuService)AopContext.currentProxy()).progress();
}

public void progress() {
    System.out.println("PROGRESS");
}

그리고 @EnableAspectJAutoProxy(exposeProxy = true) 옵션을 적용해서 작동시켜 봅니다.

aop가 작동하는 것을 확인할 수 있습니다.

두 번째 방법은 `자기 자신을 호출하는 방법`입니다.

내부에서 프록시를 호출하면 인터셉터가 작동하지 않으므로 외부에서 호출하는 방식으로 해결하는 것입니다.

@Resource
@Autowired
@Inject

등 여러 방법이 있습니다.

모두 적용이 가능하지만 이번 예시에서는 @Resource 어노테이션을 사용하여 AOP를 적용해보겠습니다.

public class MenuService {
    @Resource(name = "menuService")
    MenuService self;
    
    ...
}

위와 같이 @Resuroce 를 통해 빈 객체로 등록해주고 이번에는 self.progress()를 호출해줍니다.

public void init(){
    self.progress();
}

public void progress(){
    System.out.println("PROGRESS");
}

해당 방법이 성공한 이유는 외부에서 내부 빈으로 호출을 하므로 아래와 같이 aop가 정상 동작합니다.

*주의: 해당 방식은 2.6 보다 낮은 버전에서 가능합니다. 스프링 부트 2.6 버전부터는 기본적으로 순환 참조를 금지하도록 변경되었습니다. 만약 2.6 버전 이상에서 실습해보고 싶으시다면 아래의 설정을 추가하시면 됩니다.

spring:
  main:
    allow-circular-references: true

Spring Boot 2.6 Release Notes

마무리

지금까지 트랜잭션과 AOP에 대한 사실과 오해를 잠깐 맛보았습니다.

AOP는 내용이 많고 어렵기도 해서 추가적인 학습들이 필요합니다.

AOP를 사용하면 부가 기능을 따로 추출하여 비즈니스 로직에만 집중할 수 있는 장점이 생기지만 잘못 사용하면 그만큼 side-effect가 생깁니다.

이 글을 읽고 낯설었던 aop에 대해 한걸음 가까워졌으면 좋겠습니다!

References

스프링 이벤트 적용기

Mon, 14 Nov 2022 13:10:00 GMT

상황

스모디 프로젝트를 하면서 랭킹 기능을 도입하기로 했습니다. 랭킹 기능은 유저가 활동을 했을 때, 활동에 따라 랭킹 점수를 부여해야 합니다. 저희 서비스는 챌린지에 도전하고 매일 챌린지에 해당하는 활동을 인증하여 총 3회 인증 시 성공하는 사이클로 이루어져 있습니다. 위 기능을 추가하기 위해선 기존 인증을 하는 서비스 로직에 랭킹 점수를 올리는 기능을 추가해야 합니다. 더즈와 페어로 구현하면서 이벤트 적용, 트랜잭션 분리, 비동기 처리 등 활동과 랭킹 관련 로직을 분리하는 과정을 글로 정리했습니다.

용어 정리

인증: 사용자가 챌린지에 관련된 글과 이미지로 인증
사이클(Cycle): 총 3번의 인증으로 이루어져 있으며 3번의 인증을 마치면 챌린지에 대해 한 번의 사이클을 성공(NOTHING -> FIRST -> SECOND -> SUCCESS)
랭킹 정책: 3번의 인증에 따라 점수를 부여한다. (FIRST:10점, SECOND:30점, SUCCESS:60점)

인증을 하면 해당 사용자의 랭킹 점수를 올려주어야 합니다.

@Transactional
public ProgressResponse increaseProgress(TokenPayload tokenPayload, ProgressRequest progressRequest) {
    // 인증
    Cycle cycle = cycleService.increaseProgress(
        tokenPayload.getId(),
        progressRequest.getCycleId(),
        progressRequest.getProgressTime(),
        new Image(progressRequest.getProgressImage(), imageStrategy),
        progressRequest.getDescription()
    );
	// 랭킹 관련 로직 추가
    return new ProgressResponse(cycle); // response dto 반환
}

사용자가 글과 이미지로 인증을 하면 위 서비스 메서드가 호출됩니다. 기존 활동 로직이 끝나면 랭킹 로직 관련 로직 부분에 구현해주어야 합니다.

인증과 랭킹 로직은 같은 트랜잭션인가?

페어인 더즈와 이에 대해 많은 이야기를 했습니다. 2가지 의견이 있었습니다.

같은 트랜잭션이다!

트랜잭션을 합치게 되면 랭킹 관련 로직에서 에러가 발생했을 때 인증한 기록들도 롤백됩니다. 랭킹 점수에는 정합성이 맞지만, 트랜잭션의 전파가 넓어지고 랭킹 점수를 올릴 때 에러가 발생했는데 인증했던 기록도 롤백된다는 것이 맞는가라는 의문이 있습니다.

다른 트랜잭션이다!

트랜잭션을 분리하면 랭킹 관련 로직에서 에러가 발생하더라도 인증했던 기록에는 영향을 주지 않습니다. 하지만, 인증을 하고 랭킹 점수가 올라가지 않아 점수가 누락되는 상황이 생길 수 있습니다.

트랜잭션은 분리하되 점수가 누락되는 상황을 예방하자!

트랜잭션을 분리했을 때 문제가 되는 상황은 점수가 누락되는 것 입니다. 점수가 누락되는 문제만 해결된다면 트랜잭션을 분리하는 것이 좋겠다고 결정했습니다.

1. 관심사 분리

이벤트를 사용하여 인증 로직과 랭킹 로직간의 결합도를 끊고 관심사를 분리할 수 있습니다.

Spring에서 이벤트 사용 방법

• Event publication, namely to beans that implement the ApplicationListener interface, through the use of the ApplicationEventPublisher interface. -spring docs-

Spring의 ApplicationContext 는 이벤트를 활용할 수 있습니다. BeanFactory 에서 향상된 기능 중 하나입니다. ApplicationEventPublisher 인터페이스로 이벤트를 ApplicationContext 에 넘겨주고 이를 Listener 가 받아서 처리하는 구조로 되어있습니다. 여기선 어노테이션 기반의 Listener 로 설명하겠습니다.

ApplicationEventPublisher

@FunctionalInterface
public interface ApplicationEventPublisher {

	default void publishEvent(ApplicationEvent event) {
		publishEvent((Object) event);
	}

	void publishEvent(Object event);
}

ApplicationContext 에 이벤트를 발행해주는 인터페이스입니다. publishEvent(Object event) 메서드의 event 는 ApplicationEvent 추상 클래스를 상속한 객체여도 되지만, 직접 구현한 POJO로도 동작을 합니다. 이 객체에는 이벤트에 필요한 데이터를 저장할 수 있습니다.

@EventListener

ApplicationContext 에서 이벤트가 발행되면 @EventListener 가 붙은 적합한 메서드를 찾아 실행합니다. publicEvent(Object event) 로 발행했던 event 를 파라미터로 받는 메서드를 모두 실행합니다. 이 때 반드시 이벤트를 받을 메서드의 파라미터는 event 만 가지고 있어야 합니다.

이벤트로 랭킹 로직 분리

@Transactional
public ProgressResponse increaseProgress(TokenPayload tokenPayload, ProgressRequest progressRequest) {
    // 인증
    Cycle cycle = cycleService.increaseProgress(
        tokenPayload.getId(),
        progressRequest.getCycleId(),
        progressRequest.getProgressTime(),
        new Image(progressRequest.getProgressImage(), imageStrategy),
        progressRequest.getDescription()
    );
	// 이벤트 발행
    applicationEventPublisher.publishEvent(new CycleProgressEvent(cycle));
    return new ProgressResponse(cycle);
}

// 이벤트를 발행한 시점에 실행
@EventListener
public void handle(CycleProgressEvent event) {
		Cycle cycle = event.getCycle();
    // 1~2번 과정
    List<RankingActivity> activities = findTargetActivities(cycle);
	// 3번
    updateActivities(cycle.getLatestCycleDetail(), activities);
}

private List<RankingActivity> findTargetActivities(Cycle cycle) {
	// 1번
    LocalDateTime latestProgressTime = cycle.getLatestProgressTime();
    List<RankingPeriod> inProgressPeriods = rankingService.findInProgressPeriod(latestProgressTime);
    addPeriodIfAbsent(inProgressPeriods, latestProgressTime);
    Member member = cycle.getMember();
	// 2번
    List<RankingActivity> myActivities = rankingService.findAllActivity(inProgressPeriods, member);
    addActivityIfAbsent(inProgressPeriods, member, myActivities);
    return myActivities;
}

인증 로직에서 CycleProgressEvent(cycle) 을 발행하면 위 이벤트 메서드가 실행됩니다.

인증한 사이클의 최근 인증한 시간 즉 방금 인증한 시간을 조회하고 이에 맞는 주간 랭킹 기간(RankingPeriod)을 조회한다.
- 만약 랭킹 기간이 없다면 그 주의 랭킹 기간을 생성한다.
랭킹 기간들을 순회하면서 사용자가 참여중인 랭킹 활동을 조회한다.
- 만약 랭킹 기간에 참여중이지 않는다면 랭킹 활동을 생성한다.
인증한 활동에 대한 점수를 랭킹 활동에 추가한다.

2. 트랜잭션 분리

이벤트를 활용하여 로직을 분리했지만, 위 로직은 활동과 랭킹이 같은 트랜잭션으로 묶여있습니다. 그리고 로직은 분리했지만, 동기적으로 실행하게 됩니다.

@Transactional
public ProgressResponse increaseProgress(TokenPayload tokenPayload, ProgressRequest progressRequest) {
    // 인증
	Cycle cycle = cycleService.increaseProgress(
        tokenPayload.getId(),
        progressRequest.getCycleId(),
        progressRequest.getProgressTime(),
        new Image(progressRequest.getProgressImage(), imageStrategy),
        progressRequest.getDescription()
    );
	// 이벤트 발행 (랭킹 로직 처리)
    applicationEventPublisher.publishEvent(new CycleProgressEvent(cycle));
	// 이벤트 처리가 끝나면 이어서 실행
    return new ProgressResponse(cycle);
}

@EventListener 는 발행되자마자 실행됩니다. 하나의 스레드에서 실행되기 때문에 이벤트 처리가 끝나야 이벤트를 발행한 곳의 남은 로직을 처리하고 트랜잭션을 커밋할지 롤백할지 결정하게 됩니다.

`@TransactionalEventListener`를 사용하여 이벤트 발행 시점 결정하기

이 어노테이션을 사용하면 이벤트 발행 시점을 결정할 수 있습니다.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void afterCommit(Event event) {
	// 이벤트 발행 주체가 커밋되면 실행 (default)
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
public void afterRollBack(Event event) {
	// 이벤트 발행 주체가 롤백되면 실행
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMPLETION)
public void afterCompletion(Event event) {
	// 이벤트 발행 주체가 끝나면 실행 (롤백, 커밋)
}

@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
public void beforeCommit(Event event){
	// 이벤트 발행 주체가 커밋되기 전에 실행
}

phase 를 적어주지 않으면 default로 커밋 후에 실행하게 됩니다.

그럼 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 을 사용해서 이벤트 발행 주체가 커밋하고 실행하도록 하면 되겠네요?

커밋 후에 이벤트를 발행해서 이벤트에서 에러가 발생하더라도 이벤트를 발행한 주체는 이미 커밋이 됐기 때문에 영향을 주지 못합니다. 하지만, 같은 트랜잭션으로 묶여있는 상황에서 이벤트를 발행하기 전에 커밋이 됐기 때문에 조회는 가능하지만, 쓰기는 불가능합니다. 트랜잭션이 사라진 것이 아니라 이벤트가 이미 커밋된 트랜잭션에 참여한 상황이 발생한 것 입니다.

@TransactionalEventListener // default = TransactionPhase.AFTER_COMMIT
public void handle(CycleProgressEvent event) {
	Cycle cycle = event.getCycle();
    // 1~2번 과정
    List<RankingActivity> activities = findTargetActivities(cycle); // insert 쿼리 발생
	// 3번
    updateActivities(cycle.getLatestCycleDetail(), activities); // update 쿼리 발생
}

1~3번 과정에서 랭킹 활동과 기간이 없다면 생성하는 로직도 포함되어 있고 활동의 점수들을 추가도 하여 insert, update 쿼리문을 사용해야 합니다. 만약 위 처럼 작성되어 있고 랭킹 관련 서비스 로직이 @Transactional 로 되어 있으면 insert와 update 쿼리문을 실행하지 못하게 됩니다.

private List<RankingActivity> findTargetActivities(Cycle cycle) {
		// 1번
    LocalDateTime latestProgressTime = cycle.getLatestProgressTime();
    List<RankingPeriod> inProgressPeriods = rankingService.findInProgressPeriod(latestProgressTime);
    addPeriodIfAbsent(inProgressPeriods, latestProgressTime); // insert 쿼리 발생
    Member member = cycle.getMember();
		// 2번
    List<RankingActivity> myActivities = rankingService.findAllActivity(inProgressPeriods, member);
    addActivityIfAbsent(inProgressPeriods, member, myActivities); // insert 쿼리 발생
    return myActivities;
}

// 만약 이번주 랭킹 기간이 없다면 생성한다. -> Insert 쿼리 발생
private void addPeriodIfAbsent(List<RankingPeriod> periods, LocalDateTime progressTime) {
    if (periods.isEmpty()) {
        periods.add(rankingService.createWeeklyPeriod(getMonday(progressTime)));
    }
}

// 만약 이번주 랭킹 활동이 없다면 생성한다. -> Insert 쿼리 발생
private void addActivity(Member member,
                         List<RankingActivity> myActivities,
                         List<RankingPeriod> myPeriods,
                         RankingPeriod inProgressPeriod) {
    if (!myPeriods.contains(inProgressPeriod)) {
        myActivities.add(rankingService.createFirstActivity(member, inProgressPeriod));
    }
}

// 활동 점수들을 업데이트 한다. -> Update 쿼리 발생
private void updateActivities(CycleDetail cycleDetail, List<RankingActivity> activities) {
    Progress progress = cycleDetail.getProgress();
    for (RankingActivity activity : activities) {
        activity.plusPoint(progress);
    }
}

RankingService.createWeeklyPeriod() → insert 쿼리
RankingService.createFirstActivity() → insert 쿼리
RankingActivity의 상태 변경으로 인한 변경 감지 -> update 쿼리

Propagation.REQUIRES_NEW

트랜잭션 전파 속성을 REQUIRES_NEW 로 바꾸면 트랜잭션을 분리할 수 있습니다.

@Transactional(propagation = Propagation.REQUIRES_NEW)
@TransactionalEventListener // default = TransactionPhase.AFTER_COMMIT
public void handle(CycleProgressEvent event) {
		Cycle cycle = event.getCycle();
    // 1~2번 과정
    List<RankingActivity> activities = findTargetActivities(cycle);
		// 3번
    updateActivities(cycle.getLatestCycleDetail(), activities);
}

3. 비동기 적용

앞서 말한 트랜잭션 전파 레벨을 수정하는 것으로 트랜잭션도 분리도 할 수 있었습니다. 그런데 만약 이벤트를 발행했을 때 해당 이벤트를 여러번 처리하게 된다면 어떻게 될까요?

활동을 인증한다.
인증을 했다는 이벤트를 발행한다.
1. 인증을 했다는 푸시 알림을 사용자에게 보낸다.
2. 인증에 맞는 랭킹 점수를 올린다.

위 상황은 하나의 스레드에서 실행하게 됩니다. 따라서 인증, 푸시 알림, 랭킹 중 하나라도 예상치 못한 에러가 발생하면 순서에 따라 서로 영향을 줄 수 있는 것이죠.

인증한다.
푸시 알림을 보낸다. (에러)
랭킹 점수를 올린다. (무시)

위 문제는 푸시 알림에서 에러 처리를 해주면 해결할 수 있습니다.

하나의 스레드, 다수의 커넥션

# application.properties
spring.datasource.hikari.maximum-pool-size=1

데이터 커넥션 풀 사이즈를 1로 설정하고 앞선 로직을 실행하면 커넥션을 얻기 위해 계속 기다리게 됩니다.

트랜잭션을 분리하게 되면 분리된 트랜잭션은 기존의 커넥션과 다른 커넥션으로 연결됩니다. 그럼 이벤트에 따라 실행되는 로직이 n개라면 n개의 커넥션으로 연결됩니다. 이 스레드가 끝나지 않는 이상 다수의 커넥션은 연결되어 있는 상태고 이는 성능에 문제가 발생할 수 있습니다.

트랜잭션 분리와 더불어 더 확실하게 이벤트가 서로 영향을 주지 않으려면 비동기를 사용해야 합니다.

@Async
@TransactionalEventListener // default = TransactionPhase.AFTER_COMMIT
public void handle(CycleProgressEvent event) {
		Cycle cycle = event.getCycle();
    // 1~2번 과정
    List<RankingActivity> activities = findTargetActivities(cycle);
		// 3번
    updateActivities(cycle.getLatestCycleDetail(), activities);
}

@SpringBootApplication
@EnableAsync
public class SmodyApplication {

    public static void main(String[] args) {
        SpringApplication.run(SmodyApplication.class, args);
    }
}

메서드에 @Async 를 붙이고 @SpringBootApplication 이 붙은 main 메서드가 있는 클래스에 @EnableAsync 를 붙여주면 쉽게 비동기로 처리할 수 있습니다.

위 처럼 구현하면 매번 이벤트가 발생할 때 마다 새로운 스레드를 생성하게 됩니다. 스레드를 생성하는 작업도 비용이 들 수 있고 메모리 영역을 차지하기 때문에 비동기 처리를 위한 스레드 풀도 설정하여 보다 효율적으로 사용할 수 있습니다.

@Configuration
public class AsyncConfig {

    @Bean
    public TaskExecutor asyncExecutor() {
        ThreadPoolTaskExecutor asyncExecutor = new ThreadPoolTaskExecutor();
        asyncExecutor.setThreadNamePrefix("async-pool");
        asyncExecutor.setCorePoolSize(10);
        asyncExecutor.initialize();
        return asyncExecutor;
    }
}

Event listeners are encouraged to be as efficient as possible, individually using asynchronous execution for longer-running and potentially blocking operations.

@EventListener 의 설명에 보면 비동기로 사용할 것을 권장하고 있습니다. 그래도 이벤트를 적용하게 된다면 무조건 비동기를 사용하는 것 보다 비즈니스 정책을 고려하여 적절하게 비동기, 트랜잭션 분리를 하는 것이 좋을 것 같습니다.

참고

트랜잭션 격리 수준

Mon, 07 Nov 2022 13:10:00 GMT

Transaction Isolation Level

애플리케이션을 개발 중 데이터베이스를 도입하면 격리 수준에 대한 이해가 자연스럽게 요구됩니다. 격리 수준은 데이터베이스의 ACID 성질 중 Isolation 에 해당하며, 여러 트랜잭션이 동시에 변경을 수행할 때 성능과 안정성, 일관성 및 재현성 간의 규형을 미세하게 조정하는 설정입니다. SQL:1992 표준에서 제공하는 4가지 격리 수준의 종류는 아래와 같습니다.

READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE

MySQL 의 InnoDB 는 MVCC 와 2-Phase Locking 의 장점을 적절히 조합하여 트랜잭션 모델을 구현하였는데요. 이를 이해하기 위해선 InnoDB 의 Locking, Consistent Non-Locking Read, Locking Read 등과 같은 개념이 선행되어야 합니다.

CREATE TABLE test (
  id BIGINT(20) NOT NULL AUTO_INCREMENT,
  name VARCHAR(255) NOT NULL,
  age BIGINT(20) NOT NULL,
  PRIMARY KEY (id)
);

insert into test (id, name, age) values (1, 'quaritch', 25);
insert into test (id, name, age) values (2, 'orca', 26);
insert into test (id, name, age) values (3, 'chan', 26);
insert into test (id, name, age) values (6, 'ori', 27);
insert into test (id, name, age) values (10, 'awesomeo', 26);

이 글에선 여러 예시들이 사용될 예정입니다. 모든 예시는 위 테이블을 바탕으로 진행되는 점을 참고하며 읽으시면 좀 더 원활한 이해가 가능할 것 같습니다.

InnoDB Locking

MySQL 의 InnoDB 에선 다양한 Locking 기법을 사용합니다. 그 중 InnoDB 의 트랜잭션 격리 수준을 구현하기 위해 사용되는 대표적인 3가지 Lock 에 대해 우선 살펴보고자 합니다.

Record Lock

Record Lock 은 인덱스 레코드에 설정되는 Lock 입니다. 테이블에 인덱스가 정의되지 않았어도 InnoDB 에선 숨겨진 Clustered Index 를 생성하기 때문에 이를 활용하여 Record Lock 을 적용할 수 있습니다.

예를 들어, SELECT name FROM test WHERE id = 1 FOR UPDATE; 라는 쿼리를 실행하면 id 가 1 에 해당하는 레코드에 Record Lock 이 설정되기 때문에 다른 트랜잭션이 id 가 1 인 레코드를 변경하는 작업을 수행할 수 없습니다.

아래는 해당 상황을 연출하고 SHOW ENGINE INNODB STATUS 를 통해 Record Lock 이 설정된 것을 확인한 로그입니다.

RECORD LOCKS space id 10 page no 4 n bits 72 index PRIMARY of table `transaction_test`.`test`
trx id 3162 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 8; hex 8000000000000001; asc         ;;
 1: len 6; hex 000000000c4b; asc      K;;
 2: len 7; hex 820000008e0110; asc        ;;
 3: len 8; hex 7175617269746368; asc quaritch;;
 4: len 8; hex 8000000000000019; asc         ;;

Gap Lock

Gap Lock 은 인덱스 레코드 간의 Gap 혹은 첫 번째 또는 마지막 인덱스 레코드 전/후의 Gap 에 설정되는 Lock 입니다. Gap 자체에 Lock 이 설정되었기 때문에 삽입하려는 곳의 값 존재 여부와 관계 없이 다른 트랜잭션에서 데이터를 삽입할 수 없습니다.

예를 들어, SELECT name FROM test WHERE id >= 1 FOR UPDATE; 라는 쿼리를 실행하고 다른 트랜잭션이 id 가 8 인 데이터를 삽입하려고 할 경우 해당 id 값은 Gap Lock 이 설정된 상태이기 때문에 삽입 작업을 수행할 수 없습니다.

아래는 해당 상황을 연출하고 Gap Lock 이 설정된 것을 확인한 결과입니다.

RECORD LOCKS space id 11 page no 4 n bits 72 index PRIMARY of table `transaction_test`.`test`
trx id 3194 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 8; hex 800000000000000a; asc         ;;
 1: len 6; hex 000000000c74; asc      t;;
 2: len 7; hex 82000000ab0110; asc        ;;
 3: len 4; hex 6f726361; asc orca;;
 4: len 8; hex 800000000000001a; asc         ;;

Next-Key Lock

Next-Key Lock 은 Record Lock 과 해당 인덱스 레코드 앞의 Gap 에 대한 Gap Lock 이 조합된 Lock 입니다. 예시에 해당하는 Next-Key Lock 은 아래 명시된 것과 같이 적용됩니다.

(negative infinity, 1]
(1, 2]
(2, 3]
(3, 6]
(6, 10]
(10, positive infinity)

마지막 범위에 대한 Next-Key Lock 은 실제 인덱스의 가장 큰 값과 가장 높은 값을 갖는 허위 인덱스, supremum pseudo-record 를 통해 Lock 을 설정합니다.

실제로 SELECT … FROM performance_schema.data_locks; 를 통해 확인해보면 supremum pseudo-record 가 LOCK_DATA 로 잡혀있는 것을 확인할 수 있습니다.

Consistent Non-Locking Reads

MySQL 의 InnoDB 는 동시성 성능을 최대화하기 위해 Multiversion Concurrency Control, MVCC 라는 개념을 도입했습니다. 이는 격리 수준에 따라 상이하지만, 특정 시점의 Snapshot 정보를 바탕으로 Locking 이 필요하지 않은 Consistent Read 를 제공한다는 공통점이 있습니다. 이를 MySQL 에선 Consistent Non-Locking Read 라고 합니다.

REPEATALBE READ 격리 수준에선 최초 SELECT 문이 수행된 시점을 기준으로 Snapshot 이 생성되어 다른 트랜잭션에 의해 해당 데이터가 변경되어도 Undo Log 에 저장된 내용을 기반으로 기존 데이터를 재구성합니다.
READ COMMITTED 격리 수준에선 각 SELECT 문 마다 Snapshot 이 초기화되기 때문에 다른 트랜잭션의 커밋에 의해 해당 데이터가 변경되면 같은 읽기 작업이라도 다른 결과를 반환할 수 있습니다.

Locking Reads

기본적인 SELECT 문을 통해 조회한 데이터는 기본적으로 Non-Locking Read 입니다. 때문에 다른 트랜잭션에 의해 변경될 가능성이 높습니다. InnoDB 는 이를 해결하기 위해 두 가지 Locking Read 를 제공합니다.

SELECT … FOR SHARE 는 읽은 Row 에 S-Lock 을 설정합니다. 다른 트랜잭션이 Row 를 읽을 순 있지만, S-Lock 을 설정한 트랜잭션이 커밋되기 전까지 Row 를 수정할 수 없습니다. 아직 커밋되지 않은 다른 트랜잭션에 의해 해당 Row 가 변경될 경우, 트랜잭션이 종료될 때까지 기다린 뒤 가장 최신화된 값을 사용하여 쿼리를 수행합니다.
SELECT … FOR UPDATE 는 검색에서 발견한 인덱스 레코드에 대해 UPDATE 문을 실행한 것과 동일하게 Row 및 관련 인덱스에 Lock 을 설정합니다. 다른 트랜잭션은 해당 Row 를 UPDATE 또는 SELECT ... FOR SHARE 를 수행하는 것이 제한됩니다.

FOR SHARE 혹은 FOR UPDATE 로 설정된 모든 Lock 은 트랜잭션이 커밋 또는 롤백될 때 반환됩니다.

여기까지 InnoDB 의 Locking, Consistent Non-Locking Read, Locking Read 등에 대해 알아보았습니다. 이제 InnoDB 가 4가지 트랜잭션 격리 수준을 이를 통해 어떻게 구현했는지 살펴보겠습니다.

READ UNCOMMITTED

먼저 READ UNCOMMITTED 입니다. 트랜잭션의 변경 내용이 커밋이나 롤백 여부와 관계 없이 다른 트랜잭션에 보이는 가장 낮은 수준의 격리 레벨입니다. READ UNCOMMITTED 격리 수준에서 일반적인 SELECT 문은 Non-Locking Read 로 수행되지만 MVCC 를 사용하지 않아 Consistent Read 를 보장하지않습니다.

Dirty Read

READ UNCOMMITTED 격리 수준에서 발생할 수 있는 읽기 부정합 현상입니다. 다른 트랜잭션에 의해 영향 받은 Row 를 읽을 수 있기 때문에 발생하는 현상입니다. 커밋 또는 롤백에 관계 없이 보여지기 때문에 부정확한 데이터를 사용할 수 있는 위험한 상황이 발생할 수 있습니다.

이는 데이터베이스의 ACID 성질을 준수하지 못하기에 이를 해결하기 위해 InnoDB 에선 MVCC 를 통한 Consistent Read 를 제공합니다.

READ COMMITTED

READ COMMITTED 격리 수준부터 MVCC 가 사용되어 Consistent Read 를 지원하지만 동일한 트랜잭션 내에서 각 SELECT 문은 자체적으로 새로운 Snapshot 을 생성하기 때문에 완전한 Consistent Read 를 보장하진 않습니다.

Locking Read UPDATE DELETE 문의 경우 Record Lock 만을 설정하고 Gap Lock 은 설정하지 않기에 다른 트랜잭션에서 자유롭게 Gap 에 접근할 수 있습니다. Gap Lock 을 설정하지 않기 때문에 범위 검색과 같은 쿼리에서 Phantom Read 현상 역시 발생할 수 있습니다.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
UPDATE test SET name = 'meatsby' WHERE name = 'quaritch';

추가적으로 위 그럼처럼 UPDATE 쿼리를 위한 풀 테이블 스캔 시 READ COMMITTED 는 스캔 중 마주치는 모든 인덱스 레코드에 X-Lock 을 설정하고 WHERE 절이 수행될 때 조건에 부합하지 않는 인덱스 레코드의 X-Lock 을 반환하는 특징을 가지고 있습니다.

변경할 인덱스 레코드를 제외한 다른 인덱스 레코드의 Lock 을 반환하기 때문에 다른 트랜잭션과의 충돌로 인한 데드락 발생 확률을 현저히 줄였다고 MySQL 은 소개합니다.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
UPDATE test SET name = 'meatsby' WHERE name = 'quaritch';

반면 REPEATABLE READ 에선 스캔 중 마주치는 모든 인덱스 레코드에 X-Lock 을 설정하여 커밋 또는 롤백까지 Lock 을 반환하지 않습니다.

Non-Repeatable Read

READ COMMITTED 격리 수준까지 발생할 수 있는 읽기 부정합 현상입니다. 앞서 설명한 것 처럼 READ COMMITTED 격리 수준에서 SELECT 문은 항상 Snapshot 을 초기화하기 때문에 한 트랜잭션에서 동일한 SELECT 문을 수행해도 일관된 데이터를 반환하지 않는 문제가 발생할 수 있습니다.

REPEATABLE READ

InnoDB 에서 기본값으로 제공하는 격리 레벨로, READ COMMITTED 격리 수준과는 달리 처음 생성된 Snapshot 을 통해 Consistent Read 를 보장합니다. 즉, 동일한 트랜잭션 내의 일반적인 SELECT 문의 일관성을 보장합니다.

Locking Read UPDATE DELETE 문의 경우 검색 조건에 따라 사용하는 Lock 이 달라집니다.

고유한 검색 조건이 있는 고유 인덱스에 대한 쿼리는 Record Lock 이 적용됩니다.
범위 검색 조건과 같은 다른 검색 조건의 경우 스캔한 인덱스 범위에 Gap Lock 또는 Next-Key Lock 을 설정하여 다른 트랜잭션이 해당 범위에 접근하는 것을 제한합니다.

아래 예시를 통해 위 두 상황을 좀 더 자세히 살펴보겠습니다.

# Session A
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT * FROM test WHERE id = 6 FOR UPDATE;

현재 예시에선 id 가 인덱스로 작용하고 있기 때문에 고유한 id 조건을 통해 FOR UPDATE 를 수행할 경우 해당하는 인덱스 레코드에만 Record Lock 이 설정됩니다.

# Session B
INSERT INTO test (id, name, age) VALUES (5, 'test', 26);

때문에 다른 트랜잭션이 Gap 에 데이터를 삽입할 때 아무 제한 없이 정상적으로 데이터가 삽입됩니다.

# Session A
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT * FROM test WHERE age = 25 FOR UPDATE;

반면 age 와 같이 현재 테이블 상태에선 고유하지만 인덱스가 아닌 조건을 통해 FOR UPDATE 를 수행할 경우 풀 테이블 스캔을 통해 해당 인덱스 레코드를 탐색하기 때문에 그 과정에서 마주친 모든 인덱스 레코드에 X-Lock 이 적용됩니다.

# Session B
INSERT INTO test (id, name, age) VALUES (5, 'test', 26);

이 상태에서 다른 트랜잭션이 Gap 에 id 가 5 인 데이터를 삽입하려고 할 경우 id 가 6 인 인덱스 레코드의 Gap Lock 으로 인해 데이터 삽입이 제한됩니다. 이를 통해 InnoDB 에선 REPEATABLE READ 수준에서도 Phantom Read 현상을 방지할 수 있습니다.

Phantom Read

A : START TRANSACTION;
A : SELECT * FROM test; # 최초 Snapshot 생성

B : INSERT INTO test (id, name, age) VALUES (5, 'test', 26); # Lock 이 걸려있지 않기 때문에 Gap 에 데이터 삽입 가능

A : SELECT * FROM test; # 최초 Snapshot 을 그대로 사용
A : UPDATE test SET name = 'twenty-six' WHERE age = 26; # Locking Read 를 통해 새롭게 읽은 후 UPDATE
A : SELECT * FROM test; # Snapshot 이 초기화되어 Phantom Read 발생

여전히 이런 구조에도 불구하고 REPEATABLE READ 에서 Phantom Read 가 발생할 수 있는 상황이 있습니다.

위 상황처럼 다른 트랜잭션이 추가한 레코드에 UPDATE 쿼리를 수행하게 될 경우, 첫 SELECT 쿼리로 생성된 Snapshot 에는 존재하지 않지만 실제 디스크에는 데이터가 존재하기 때문에 해당 레코드가 영향을 받아 이후 SELECT 쿼리를 수행할 때 Snapshot 이 초기화되는 시점에 해당 현상을 발견할 수 있습니다.

즉, Consistent Non-Locking Read 와 Locking Read 의 조합 때문에 발생할 수 있는 현상입니다.

앞서 설명한 것 처럼 일반적인 SELECT 문은 Non-Locking Read 를 기반으로 하기 때문에 UPDATE 를 위한 SELECT 는 SELECT … FOR UPDATE 와 같이 Locking Read 를 사용하는 것이 더 적합합니다.

따라서, 위 예시에서 연출하는 상황 자체가 부적절하다고 생각하지만, 여전히 발생할 수 있는 특정 상황이 존재한다는 사실을 알고있는 것이 좋을 것 같습니다.

SERIALIZABLE

마지막 SERIALIZABLE 은 가장 높은 수준의 격리 레벨입니다. 이름처럼 직렬화된 방식처럼 작동해야합니다. InnoDB 에선 이를 구현하기 위해 일반적인 SELECT 문을 모두 SELECT … FOR SHARE 문으로 변환하여 S-Lock 을 통한 Locking Read 를 수행하게끔 합니다.

글 초반부 설명되어있듯이 S-Lock 은 다른 트랜잭션도 독립적으로 설정이 가능하여 S-Lock 이 설정된 레코드를 읽을 수 있지만 최초로 S-Lock 을 설정한 트랜잭션이 종료되기 전까진 변경을 가할 수 없습니다.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
START TRANSACTION;
SELECT * FROM test;

위 그림처럼 단순히 SELECT 문을 수행해도 모든 레코드에 S-Lock 이 설정된 것을 확인할 수 있습니다.

마무리

여기까지 MySQL 의 InnoDB 가 4가지 격리 수준을 구현한 방법에 대해 알아보았습니다. 격리 수준은 동시성과 격리성의 Trade-Off 인 만큼 자세히 알고 사용하면 더 좋은 효과를 나타낼 수 있을 것 같습니다.

MySQL 은 다른 DBMS 벤더들과는 달리 InnoDB 를 통해 REPEATABLE READ 에서도 충분한 격리성을 보여주고 있습니다. 하지만 여러가지 Locking 기법을 활용하여 격리 수준을 구현했기 때문에 Locking 으로 인해 발생할 수 있는 여러 문제점 역시 충분히 이해하는 것이 중요하다고 생각합니다.

References

interface vs type alias

Mon, 07 Nov 2022 13:10:00 GMT

what is the difference between interface and type alias?

typescript를 공부해본 사람이라면 위의 키워드를 사용해서 구글링을 해본 적이 있을 것이다.
(최소한, 나는 그렇다…🙄)

실제로, 아래와 같이 단순히 interface와 type alias의 차이가 무엇인지에 대해 물어보는 전세계 개발자들을 찾을 수 있다.

이런 질문들을 할 수밖에 없는 게, type alias는 interface가 하는 것을 거의 다 대체 할 수 있는 것처럼 보이기 때문이다. 예를 들어, 아래와 같은 Person이라는 interface가 있는 데, 이는 객체에 대한 타입을 설정해준 것이다.

interface Person = {
	name: string;
	age: number;
}

interface Person extends

똑같은 타입을 type alias를 활용해서도 똑같이 만들 수 있다.

type Person = {
  name: string;
  age: number;
};

오늘은, type alias와 interface가 각각 왜 존재하는 지 살펴보는 시간을 가져보려한다.

type alias와 interface의 정의

먼저, 둘의 정의를 보면 무엇이 다른 지 알 수 있지 않을까해서 공식문서에서 정의를 찾아보았다.

A type alias is exactly that - a name for any type. An interface declaration is another way to name an object type

즉, 둘 다 타입에 이름을 부여해주는 것이지만 type alias는 모든(any) 타입에 이름을 달아줄 수 있지만, interface는 오직 객체 타입에만 가능하다는 것이다. 이것이, type alias와 interface에 가장 명확한 차이가 아닐까한다.

하지만, 이렇다고 의문점이 해결된 것은 아니다. 위의 정의만 보더라도, type alias가 object에 대한 type을 선언해주는 interface를 대체할 수 있는 것처럼 보이기 때문이다.

interface의 존재의 의의에 대한 의문이 생기는 상황이다. 그래서, 많은 사람들이 혼란을 겪는 것 같다. 자세히 말하면, object에 대한 타입을 선언하는 데 type alias와 interface 중에 무엇을 사용해야하나에 대한 혼란이다.

Differences Between Type Aliases and Interfaces (typescript 공식문서)

typescript 공식문서에 type alias와 interface의 차이에 관한 내용이 있다.

Type aliases and interfaces are very similar, and in many cases you can choose between them freely. Almost all features of an interface are available in type, the key distinction is that a type cannot be re-opened to add new properties vs an interface which is always extendable.

해석을 해보면, interface의 대부분의 기능들은 type에서도 가능하고, 중요한 차이점이라고 한다면 type alias는 새로운 프로퍼티에 열려있지 않다는 것이고, interface는 항상 열려있다는 점이라는 것이다.

type cannot be re-opened to add new properties vs an interface which is always extendable??

typescript 공식문서의 설명(type alias와 interface의 차이점)에서 중요한 키워드를 발견한 것 같다.

type alias는 새로운 프로퍼티에 열려있지 않다는 것이고, interface는 항상 열려있다

아래의 예시를 봐보자

왼쪽은 interface로 타입을 선언 했을 때의 코드이다.

interface 키워드를 통해서 선언된 Window라는 타입을 선언한 후, 바로 아래에서 다시 다른 프로퍼티를 가진 Window 타입을 선언해주었다. 선언된 타입의 이름과 같은 이름으로 새로운 타입을 선언했지만, 에러가 나지 않고 나중에 선언된 타입의 프로퍼티를 가지고 있는 것을 볼 수 있다. 그래서, interface는 확장 가능하다라고 설명하는 것 같다. (이를, 선언 병합이라고 한다.)

이에 반해, 오른쪽 코드를 보면 type alias를 통해서 Window 타입을 선언해주고, 다시 아래에서 Window 타입을 재선언 해주고 있다. interface에서는 에러가 나지 않앗지만, 여기서는 식별자 ‘Window’가 중복된다라는 에러를 보여주고 있다. 그래서, type은 새로운 프로퍼티를 추가할 수 없다고 하는 것 같다.

이제, interface와 type alias가 object에 대한 타입을 선언하는 과정에서 어떻게 다른 지는 알 것 같다. 근데, 왜 굳이 확장 가능한 방법과 확장 가능하지 않은 방법으로 나눠놓았을까?라는 의문이 강하게 들었다.

왜 굳이 확장 가능한 방법과 확장 가능하지 않은 방법으로 나눠놓았을까?

typescript 개발자들이 두 가지 방법을 모두 제공했다는 것은 각각 필요하기 때문에 만들 것이라고 추론이 가능하다.

확장 가능하지 않도록 타입을 선언할 수 있는(type alias) 방법이 존재하는 이유는 조금 명확한 것 같다. 타입의 속성들이 추후에 추가될 수도 있다면, 개발자들은 타입이 변할 수도 있다는 생각을 하면서 개발을 해야하기 때문이다. (마치 let보다는 const를 활용하여 상수로 선언해주는 게 좋은 이유가 비슷한 맥락이 아닐까 한다.)

그렇다면, 확장 가능한 방법은 어느 상황에서 필요할까?

먼저, interface를 활용하면 선언 병합(Declaration merging)이라는 것이 가능하다. 아래의 코드처럼, 기존에 선언된 타입을 확장해서 다른 속성을 추가로 선언할 수 있는 것이다.

interface Person {
  name: string;
}

interface Person {
  age: number;
}

const user: Person = {
  name: 'al-bur',
  age: 21,
};

이는, 라이브러리를 사용하는 상황에서 추가적으로 타입의 속성들을 선언할 때 유용하다.

// @emotion/react/types
export interface Theme {}

// emotion.d.ts
import '@emotion/react';

declare module '@emotion/react' {
  export interface Theme {
    colors: typeof Colors;
  }
}

emotion의 types를 보면 interface 키워드를 통해 Theme이라는 타입을 제공해준다. emotion 라이브러리를 사용하는 개발자는 해당 타입에 선언 병합을 활용해 본인들이 원하는 속성들을 선언해 사용해줄 수 있다.

결론

type-alias는 모든 타입을 선언할 때 사용될 수 있고, interface는 객체에 대한 타입을 선언할 때 사용될 수 있다. 둘 다 객체에 대한 타입을 선언하는 데 사용될 수 있는데, 확장 측면에서 사용 용도가 달라진다. 확장이 불가능한 타입을 선언하려면 type-alias를 사용하면 되고, 확장이 가능한 타입을 선언하려면 선언 병합이 가능한 interface를 사용하면 된다.

이외에도 여러 차이점들이 있을 텐데, 꾸준히 탐구해보려고한다

Reference

https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#differences-between-type-aliases-and-interfaces

무중단 배포

Tue, 01 Nov 2022 12:00:00 GMT

무중단 배포를 도입하게 된 계기

프로젝트를 론칭한 이후, 사용자의 피드백을 반영하다보니 운영 환경으로의 배포가 점차 잦아졌습니다. 문제는 배포를 할 때마다 기존 서버를 내리고 새롭게 띄우는 과정에서 평균 20초 이상의 다운타임이 발생한다는 것이었습니다.

운영 서버는 사용자의 경험과 직결되는데, 배포할때마다 서버가 20초 이상 다운되는 것은 큰 문제라고 생각했습니다. 기능이 점점 많아짐에 따라 다운타임도 비례해 증가할 것이라고 판단했고, 따라서 운영 서버의 다운타임을 개선하고자 무중단 배포를 프로젝트에 도입하기로 결정했습니다.

무중단 배포란

서비스가 운영 중일 때 새로운 버전을 배포하기 위해서는 1)기존 서비스를 종료하고 2)새로운 서비스를 시작해야 합니다. 1번과 2번 사이의 과정에서 다운타임이 필연적으로 발생하며, 다운타임 동안 사용자들은 서비스를 이용할 수 없게 됩니다. 이 다운타임을 해결해주는 방법이 바로 무중단 배포입니다. 즉, 말그대로 중단이 없는 배포를 무중단 배포라고 합니다.

무중단 배포 구현 방식

무중단 배포를 구현하는 방식에는 여러가지가 있습니다.

AWS에서 Blue-Greem 무중단 배포
도커를 이용한 무중단 배포
L4, L7 스위치를 이용한 무중단 배포
Nginx를 이용한 무중단 배포

대표적으로 위와 같은 방법들이 있는데 저희 프로젝트에서는 제일 마지막에 있는 Nginx를 이용한 무중단 배포 방식을 선택했습니다.

무중단 배포 구현 방식으로 Nginx 방식을 선택한 이유

Nginx를 이용하여 무중단 배포를 구현하면 저희 프로젝트에서 다음 2가지 장점이 존재했습니다.

Nginx 서버를 이미 이용하고 있어 환경 구축을 따로 안해줘도 된다.
쉽고 저렴하다.

위와 같은 이유로 Nginx를 이용한 무중단 배포를 적용해 보기로 결정했습니다.

무중단 배포 전략

구현 방식을 정했으니 이제 배포 전략을 정해야 합니다. 배포 전략에는 대표적으로 3가지가 존재합니다.

Rolling 배포
Canary 배포
Blue/Green 배포

각 배포 전략에 대한 자세한 설명은 이 글에선 생략하겠습니다. 위 세 가지 전략중 저희 프로젝트에서 선택한 전략은 Blue/Green 배포이었습니다.

Blue/Green 배포를 선택한 이유

우선 롤링 배포와 비교해 봤을 때, 좀 더 신속하게 롤백이 가능하다고 생각했습니다. 또한 롤링 배포는 두 대 이상의 WAS 서버를 이용해 로드 벨런싱을 이용했을 때 큰 이점이 있다고 판단했는데, 저희는 추가 서버 증설에 제약이 있는 상황이었습니다. 마지막으로 롤링 배포에서는 구버전과 신버전의 공존으로 인한 호환성 문제도 발생할 수 있다는 단점도 존재했습니다.

카나리 배포와 비교해 봤을 때는 카나리 방식의 최대 이점인 A/B 테스트가 현재 서비스에선 필요가 없었기 때문에 선택하지 않습니다.

Blue/Green 배포 전략을 취함으로써 신속하게 롤백이 가능하다는 점과 배포하는 속도가 다른 배포법들에 비해 빠르다는 이점을 얻을 수 있었습니다.

Blue/Green 배포 적용

우선 무중단 배포 적용 전의 인프라 구조와 배포 스크립트를 살펴 봅시다.

무중단 배포 전, 인프라 구조와 배포 스크립트

인프라 구조

배포 스크립트

PID=$(pgrep -f teatime)

if [ -n $PID ]; then
        kill -9 $PID
	sleep 5
fi

nohup java -jar -Dspring.profiles.active=dev teatime-0.0.1-SNAPSHOT.jar 1>stdout.txt 2>err.txt &

적용 전 인프라 구조와 배포 스크립트에 대해 간략하게 알아보자면 다음 순서로 동작합니다.

젠킨스에서 WAS 서버로 jar 파일이 전송되고 배포 스크립트가 실행된다.
배포 스크립트에 의해 현재 구동 중인 8080포트의 서버가 kill된다.
새로운 jar파일로 8080포트에 새로운 서버를 띄운다.

여기서 한가지 문제점이 발생합니다❗️
앞서 언급했듯이 기존 서버가 죽고 새로운 서버가 띄워지는 사이에 다운타임이 발생하는 것입니다.

다음으로 무중단 배포 적용 후의 인프라 구조와 배포 스크립트를 살펴 봅시다.

무중단 배포 후, 인프라 구조와 배포 스크립트

인프라 구조

배포 스크립트

# 현재 profile 찾기
function find_current_profile()
{
		RESPONSE_CODE=$(curl -o /dev/null -w "%{http_code}" http://{WAS ip주소}:8080)

    if [ ${RESPONSE_CODE} != 404 ] # 404가 아니면
    then
        CURRENT_PROFILE=prod2
    else
        CURRENT_PROFILE=prod1
    fi

		echo "${CURRENT_PROFILE}"
}

# 현재 port 찾기
function find_current_port()
{
    CURRENT_PROFILE=$(find_current_profile)

    if [ ${CURRENT_PROFILE} == prod1 ]
    then
      echo "8080"
    else
      echo "8081"
    fi
}

# 쉬고 있는 profile 찾기: dev1이 사용중이면 dev2가 쉬고 있고, 반대면 dev1이 쉬고 있음
function find_idle_profile()
{
    CURRENT_PROFILE=$(find_current_profile)

    if [ ${CURRENT_PROFILE} == prod1 ]
    then
      IDLE_PROFILE=prod2
    else
      IDLE_PROFILE=prod1
    fi
	
    echo "${IDLE_PROFILE}"
}

# 쉬고 있는 profile의 port 찾기
function find_idle_port()
{
    IDLE_PROFILE=$(find_idle_profile)

    if [ ${IDLE_PROFILE} == prod1 ]
    then
      echo "8080"
    else
      echo "8081"
    fi
}

# idle profile로 jar 파일 실행

REPOSITORY=/home/ubuntu/jar

echo "> Build 파일 복사"
echo "> cp $REPOSITORY/*.jar $REPOSITORY/"

cp $REPOSITORY/*.jar $REPOSITORY/

echo "> 새 어플리케이션 배포"
JAR_NAME=$(ls -tr $REPOSITORY/*.jar | tail -n 1)

echo "> JAR Name: $JAR_NAME"

echo "> $JAR_NAME 에 실행권한 추가"

chmod +x $JAR_NAME

echo "> $JAR_NAME 실행"

CURRENT_PORT=$(find_current_port)
IDLE_PROFILE=$(find_idle_profile)
IDLE_PORT=$(find_idle_port)

echo "> $JAR_NAME 를 profile=$IDLE_PROFILE 로 실행합니다."
nohup java -jar -Dspring.profiles.active=$IDLE_PROFILE $JAR_NAME 1>stdout.txt 2>err.txt &

# health check

echo "> Health Check Start!"
echo "> IDLE_PORT: $IDLE_PORT"
echo "> curl -s http://{WAS ip주소}:$IDLE_PORT "
sleep 10

for RETRY_COUNT in {1..10}
do
  RESPONSE=$(curl -s http://{WAS ip주소}:${IDLE_PORT})
  UP_COUNT=$(echo ${RESPONSE} | grep "timestamp" | wc -l)

  if [ ${UP_COUNT} -ge 1 ]
  then # $up_count >= 1 
      echo "> Health check 성공"

      # 기존 포트에서 idle port로 switch

			echo "> 전환할 Port: $IDLE_PORT"
			echo "> Port 전환"
			echo "set \$service_url http://{WAS ip주소}:${IDLE_PORT};" | ssh -i key-teatime.cer ubuntu@{ngnix1 ip주소} sudo tee /etc/nginx/conf.d/service-prod-url.inc
			echo "set \$service_url http://{WAS ip주소}:${IDLE_PORT};" | ssh -i key-teatime.cer ubuntu@{ngnix2 ip주소} sudo tee /etc/nginx/conf.d/service-prod-url.inc

			echo "> 엔진엑스 Reload"
			ssh -i key-teatime.cer ubuntu@{ngnix1 ip주소} sudo service nginx reload
			ssh -i key-teatime.cer ubuntu@{ngnix2 ip주소} sudo service nginx reload
      break

  else
      echo "> Health check의 응답을 알 수 없거나 혹은 실행 상태가 아닙니다."
      echo "> Health check: ${RESPONSE}"
  fi

  if [ ${RETRY_COUNT} -eq 10 ]
  then
    echo "> Health check 실패. "
    echo "> 엔진엑스에 연결하지 않고 배포를 종료합니다."
    exit 1
  fi

  echo "> Health check 연결 실패. 재시도..."
  sleep 10
done

# 기존 포트 stop

CURRENT_PID=$(lsof -ti tcp:${CURRENT_PORT}

if [ -z ${CURRENT_PID} ]
then
  echo "> 현재 구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
  echo "> kill -15 $CURRENT_PID"
  kill -15 ${CURRENT_PID}
  sleep 5
fi

Blue/Green 무중단 배포 적용 후 변경된 인프라 구조와 배포 스크립트입니다. 배포 스크립트가 약간 길어 보기 불편할 수 있어 간단하게 정리하면 다음과 같습니다.

현재 8080포트로 서버가 구동 중인 상황에서의 배포 동작 순서입니다.

idle port를 찾는다. 즉 8081포트에 새롭게 배포될 서버가 띄워져야 한다는 사실을 인지한다.
idle port(8081포트)로 jar 파일 실행한다.
health check를 통해 8081포트에 서버가 띄워 질 때까지 current port(8080포트)의 서버를 kill 하지 않는다.
8081포트에 서버가 잘 띄워졌으면 Nginx에서 가리키고 있는 WAS 포트를 current port(8080) -> idle port(8081)로 스위칭해준다.
current port(8080포트)를 kill한다.

8081포트에 서버가 띄워진 후의 인프라 구조

위와 같은 flow로 Blue/Green 배포를 적용하여 결론적으로 평균 20초이상의 다운 타임을 0.2초로 줄였습니다. 여기서 0.2초의 다운 타임이 존재하는 이유는 proxy switching을 하고 nginx를 reload하는 과정이 0.1초인데, 저희 프로젝트에선 nginx를 두 대 이용하기 때문에 0.2초의 다운타임이 발생했습니다.

추후 고민해 볼 점

무중단 배포를 구현한 뒤 추가로 고민해보면 좋을 점들입니다.

1. Health check

  RESPONSE=$(curl -s http://{WAS ip주소}:${IDLE_PORT})
  UP_COUNT=$(echo ${RESPONSE} | grep "timestamp" | wc -l)

  if [ ${UP_COUNT} -ge 1 ]
  then # $up_count >= 1 
      echo "> Health check 성공"
      ...
  else
	   echo "> Health check 실패"
       ...

현재 Health check를 위와 같이 진행하고 있습니다. 신버전이 배포된 포트의 {WAS ip주소}:{IDLE_PORT}로 요청을 보내 응답에 timestamp라는 문자열이 존재하면 새로운 서버가 띄워졌다고 판단하고 있습니다.

위와 같이 ubuntu os로 띄워진 ec2 서버의 해당 포트가 띄워졌을 때, 보이는 화면에 너무 종속적인 health check가 될 수도 있다는 생각이 들었습니다. 추후에 팀원들과 논의 끝에 더 좋은 방법으로 개선해야 될 것 같습니다.

2. WAS 서버 증설

현재 무중단 배포를 통해 운영 서버의 다운 타임 문제는 해결 됐으나, WAS ec2 자체가 다운되면 서비스가 무한정 중단될 수 있는 상황입니다. 이렇게 시스템 구성 요소 중에서 장애가 발생하면 전체 시스템이 다운되는 지점을 SPOF(single point of failure, 단일 장애 지점)이라고 합니다. 따라서 WAS 서버를 한 대 더 증설하는 것이 안전하다고 판단됩니다.

테스트코드 성능 개선기

Thu, 27 Oct 2022 13:10:00 GMT

들어가며

코드를 수정하면, 검토 요청(PR) 과정의 첫 번째에 전체 테스트 코드가 잘 돌아가는지 확인하는 과정이 주기적으로 일어나고 있어요.

혼자 개발하며 테스트 코드를 접했을 때는 비지니스 로직의 안정성을 보장해주고, 문서화 기능도 있어 테스트는 무조건 많으면 좋은 것이라고 생각했었어요. 그러나 프로젝트가 진행되면서 요구사항이 계속 추가되다보니 테스트 개수와 유지보수 포인트가 늘어났습니다. 이에따라 속도가 저하되어 개발 생산성이 낮아지는 경험을 했습니다.

‘이것이 단순히 테스트 개수의 문제 일까?‘하는 궁금증이 들었고, 속도를 개선을 진행하며 느꼈던 점을 공유하고자 합니다.

마틴 파울러의 테스트 피라미드에 맞춰서 테스트 비율 조정하기

테스트 피라미드는 상위 계층의 테스트일수록 비용이 높기 때문에 최대한 적은 비율로 유지하는 것이 좋다는 것을 나타내요.

인수 테스트(UI Test)

인수 테스트는 사용자 스토리(시나리오)에 맞춰 수행하는 테스트이다. 시나리오에서 요구하는 것은 누가, 어떤 목적으로, 무엇을 하는가이다. 이는 API를 통해 드러난다. 인수 테스트는 소프트웨어 인수를 목적으로 하는 테스트이다. 소프트웨어를 인수하기 전에 명세한 요구사항(인수 조건)대로 잘 작동하는지 검증이 필요하다.

저희 프로젝트에서는 RestAssured 를 사용하여 실제 HTTP 요청을 보내 인수 테스트를 진행하고 있어요. 네트워크 응답 대기 시간이 소요되기 때문에 인수 테스트를 실행하는데 가장 오랜 시간이 걸렸어요.

왜그럴까 살펴보니 인수테스트에서 검증하는 대다수의 행위를 통합테스트에서 중복해서 검증하고 있었어요. 예외 케이스 까지도요. 저희가 인수테스트를 진행한 목적은 서비스의 요구사항이 제대로 동작하는 가를 확인하기 위함이었는데 말이죠.

따라서 인수테스트에서는 API의 성공 사례들만 검증하고, 예외 처리에 대해서는 통합테스트로 내리면 테스트 시간도 줄일 수 있고, 테스트 목적에도 더 부합하지 않을까 생각되었습니다.

통합 테스트(Integration Test)

통합 테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈들을 모아 이들이 의도대로 협력하는지 확인하는 테스트이다. @SpringBootTest 를 사용하여 작성할 수 있다. 통합 테스트는 단위 테스트와 달리 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어 검증할 때 사용한다. 이는 DB에 접근하거나 전체 코드와 다양한 환경이 제대로 작동하는지 확인하는데 필요한 모든 작업을 수행할 수 있다.

통합테스트는 @SpringBootTest 애너테이션을 사용하여 여러 객체들이 서로 잘 협력하는지, 협력하는 과정에서 side effect 가 발생하지는 않는지 확인하는 용도로 작성했어요.

그런데 코드를 살펴보니, 객체 간 협력이 아닌 도메인 로직의 검증이 Service 나 Controller 에 작성되어 있었습니다. 즉 여러 객체 사이의 상호 작용이 아니라 단일 객체에 대한 테스트가 진행되고 있었습니다.

해당 테스트 계층의 책임이 아니라고 판단되어 각 단위로 적절하게 책임을 내려주었습니다.

단위 테스트(Unit Test)

단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트이다.

단위 테스트는 테스트 피라미드 가장 아래에 위치하는 테스트 입니다. 독립적인 객체 테스트이기 때문에 테스트 비용이 가장 적습니다. 비즈니스를 구성할 때 각 도메인이 유효성 검증에 대한 책임과 행위에 대한 책임 등 적절한 책임을 가지고 있으면 객체 끼리 메세지를 주고 받기 수월해지고 객체지향적임에 한걸음 다가갈 수 있게 되는 것 같아요.

따라서 단위 테스트는 꼼꼼하게 작성해주면 좋아요.

테스트 피라미드에 맞춰서 테스트 비율 조정해보며

불필요한 테스트 비용을 제거하니 같은 로직을 더 빠르게 테스트 할 수 있게 되었어요. 😀여기서 주의할 점은 모든 경우에 항상 피라미드형 테스트 비율을 유지할 수는 없다는 점이예요. 도메인이 간단해 필요한 테스트의 양이 많지 않은 경우에 API 개수만큼 인수테스트를 작성한다고 가정하면 아래처럼 인수 테스트의 비율과 단위 테스트의 비율이 비슷할 수도 있겠죠? 따라서 현재 가지고 있는 도메인의 특성을 파악해서 테스트 비율을 조정하겠다는 유연한 사고를 한다면 더 좋겠네요.

Application Context 를 살펴보자.

그 다음으로는 Application Context 에 대한 학습을 진행했어요. 전체 테스트를 돌리면 스프링 부트가 여러번 띄워지는 경우를 보셨을거예요. 애플리케이션을 로드할 때 Application Context에 빈을 등록하기 위해서 @Bean 으로 선언된 객체들을 찾는 등의 작업이 진행되기 때문에 시간이 오래 걸려요. 따라서 Application Context 재사용하면, 전체 테스트를 돌리는 시간도 줄겠다고 생각했어요.

현재 아래와 같은 항목에 대해서 Application Context를 사용하고 있어요.

Acceptance Test
Service Test
DataJpa Test
WebMvc Test

따라서 각 계층마다 한번씩만 Application Context가 띄워지는 것을 목표로 삼고 리팩터링을 진행해봤어요.

@DirtiesContext 걷어내기

Use this annotation if a test has modified the context — for example, by modifying the state of a singleton bean, modifying the state of an embedded database, etc. Subsequent tests that request the same context will be supplied a new context.

데이터 격리를 위해 사용했던 @DirtiesContext 때문에 모든 테스트가 종료되고 Context 를 재생성하기 때문에 시간이 오래 걸렸어요.

데이터 격리라는 목적은 Bean 재생성 없이 DB를 수동으로 초기화 해주면 되겠다는 생각으로 이어졌고, DirtiesContext 를 걷어내고, DataBaseCleaner 를 사용해서 Context 재생성을 줄였습니다.

public class DatabaseCleaner {

    private EntityManager entityManager;
    private List<String> tableNames;

....

@Transactional
    public void tableClear() {
        entityManager.flush();
        entityManager.clear();

        entityManager.createNativeQuery("SET REFERENTIAL_INTEGRITY FALSE").executeUpdate();

        for (String tableName : tableNames) {
            entityManager.createNativeQuery("TRUNCATE TABLE " + tableName + " RESTART IDENTITY ").executeUpdate();
        }

        entityManager.createNativeQuery("SET REFERENTIAL_INTEGRITY TRUE").executeUpdate();
    }

Context Caching

Once the TestContext framework loads an ApplicationContext (or WebApplicationContext) for a test, that context is cached and reused for all subsequent tests that declare the same unique context configuration within the same test suite. To understand how caching works, it is important to understand what is meant by “unique” and “test suite.”

또한 SpringBootTest 를 사용하면서 Context를 캐싱할 수 있다는 점을 발견하게 되었어요.

‘동일한 고유 컨텍스트 구성을 선언하는 모든 후속 테스트에 재사용 된다’는 부분에서 고유 컨텍스트 구성이 무엇을 의미하는지 살펴봤어요. 그중에서 아래 부분이 눈에 띄었어요.

contextCustomizers(from ContextCustomizerFactory) – this includes @DynamicPropertySource methods as well as various features from Spring Boot’s testing support such as @MockBean and @SpyBean.

바로 테스트 격리를 위해서 사용했던 MockBean, SpyBean 이 객체마다 다르게 선언되어 있었던 점이 문제였는데요.

@MockBean , @SpyBean

When you are using @SpyBean to spy on a bean that is proxied by Spring, you may need to remove Spring’s proxy in some situations, for example when setting expectations using given or when. Use AopTestUtils.getTargetObject(yourProxiedSpy)to do so.

해당 어노테이션을 사용하면 대리 객체가 생성되어 실제 객체가 아니라, 대리 객체가 생성되고 있었어요. 따라서 당연하게 Context 에 생성되는 기존 객체가 아닌 대리 객체가 추가 되기 때문에 고유 컨텍스트 구성이 오염되었다고 판단해서 새로운 Context 를 띄우게 되는 것이었어요!

재사용 가능한 테스트 구조 🤔

처음부터 필요한 대리 객체가 무엇인지 파악한 뒤 Mock, Spy 한번에 선언하여 Context 에 올려두고, Test Class 들이 상속 받아 사용하는 형태로 구현한다면 컨텍스트 초기화를 한번만 하는 것이 가능해질 것 같았어요.

@WebMvcTest
@Import({...})
public class WebMvcTestSupporter {

    protected MockMvc mockMvc;

    @Autowired
    protected Class realClassA;

    @MockBean
    protected Class classA;

   @MockBean
    protected Class classB;

   @SpyBean
    protected Class classC;
}

...

public class ControllerTestA extends WebMvcTestSupporter {
  @Test
	void testA() {}
}

구조를 변경했더니 정말 Context 초기화가 한번만 이뤄졌습니다. 여기서 그럼 격리하고 싶은 객체 전부 최상위 객체에 테스트 더블을 사용하면 생각하실 수도 있는데요. 실제 객체가 필요한 상태인데 테스트 더블을 사용하는 것이 아닌지 유의하여 객체를 설계해야 유의미한 테스트가 가능하다는 점을 주의 하셨으면 좋겠습니다.

결론

테스트 피라미드를 참고해서 계층별 테스트 비율을 조절하자
불필요한 설정을 제거하자 (ControllerTest → WebMvcTest 로 내린다든가) ✍🏻
데이터 격리 방식으로 DirtiesContext 걷어내자
재사용 가능한 테스트 구조를 고민해보자

테스트 코드 성능 개선을 하고자 했던 리팩토링을 통해 더욱 객체지향적인 코드 작성이 가능해지고, 전체 테스트가 돌아가는 속도가 향상되어 팀의 개발 생산성이 한층 좋아졌습니다. 제가 접근한 개선 방향이 정답이 아닐 수도 있지만, 해당 내용을 경험하며 재미를 느끼고, 팀에 생산성을 향상 시키는데 기여 했다는 느낌에 행복했습니다. 오늘도 즐거운 학습 하시길 바랍니다. 👏

참고자료

OpenID와 OAuth2.0

Mon, 24 Oct 2022 13:10:00 GMT

요즘 많은 서비스가 소셜 로그인을 지원합니다. 저만 해도 새로운 서비스를 이용할 때, 네이버 또는 카카오 로그인이 있으면 거기에 손이 먼저 가는데요. 번거로운 개인 정보 입력을 생략할 수 있는 소셜 로그인은 사용자 입장에서 참 고맙습니다. 개발자 입장에서도 신규 유저들의 가입 장벽을 낮추고, 인증/인가를 대신 처리해주니 정말 좋죠.
이번 우테코 4기 레벨3 프로젝트에도 거의 모든 팀이 소셜 로그인을 적용했는데요, 제가 속한 줍줍 팀도 Slack 소셜 로그인을 도입했습니다.
그런데 Slack은 OAuth2.0과 OpenID Connect를 이용한 두 가지 로그인 방식을 제공하고 있어서, 둘 중 하나를 선택해야 했습니다. 여러분은 이 둘의 차이를 아시나요?

OAuth2.0와 OpenID Connect

이 둘을 완벽하게 분리해서 얘기하기는 힘듭니다. OpenID는 OAuth 프로토콜 위에서 동작하기 떄문이죠. HTTP 통신이 소켓 통신 위에서 동작하는 것과 유사합니다. 아직 OAuth가 생소한 분들은 같은 테코블의 글 OAuth 개념 및 동작 방식 이해하기를 먼저 읽으시는 걸 추천합니다.

OpenID를 관리하는 비영리 재단인 OpenID Foundation에서 직접 정의한 OpenID의 개념은 다음과 같습니다.

OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에서 동작하는 간단한 ID 레이어입니다. 이를 통해 클라이언트는 인증 서버에서 수행한 인증을 기반으로 최종 사용자의 신원을 확인할 수 있을 뿐만 아니라, 최종 사용자에 대한 기본 프로필 정보를 상호 운용 가능하며 REST와 유사한 방식으로 얻을 수 있습니다. OpenID Connect를 사용하면 웹 기반, 모바일, 자바스크립트 클라이언트 등을 포함한 모든 유형의 클라이언트에서 인증 세션과 최종 사용자에 대한 정보를 요청하고 받을 수 있습니다. 스펙은 확장 가능하므로 필요에 따라 참가자들에게 ID 데이터 암호화, OpenID 제공자 확인, 로그아웃 등을 이용할 수 있습니다.

최종 사용자, 인증 서버등 생소한 용어가 보이네요. 더 쉬운 이해를 위해 OpenID가 동작하는 과정을 예시로 간단히 살펴보겠습니다.

최종 사용자(서비스 유저)가 소셜 로그인 버튼을 클릭합니다.
웹사이트나 앱 등이 클라이언트로써 OpenID 제공자에 ID token과 access token을 요청합니다.
OpenID 제공자는 승인 페이지에서 최종 사용자의 승인을 요청합니다.
최종 사용자는 승인 버튼을 눌러 허가합니다.
OpenID 제공자는 일회용 인증 코드(Authorization code)를 클라이언트에 발급합니다.
클라이언트는 발급받은 인증 코드와 클라이언트 정보로 ID token과 access token을 다시 요청합니다. 이 떄 클라이언트 정보는 Client ID와 Client secret을 의미합니다.
OpenID 제공자는 ID token과 access token을 클라이언트에 발급합니다.
클라이언트는 access token으로 자원 서버에 필요한 자원을 요청합니다.

OAuth절차를 이미 알고 계시다면 차이점이 없다고 생각하실 수 있습니다. 사실 절차상 보이는 차이점은 access token과 함께 하이라이트 된 ID token을 추가 요청/발급한다는 것 밖에 없습니다. OAuth 위에서 동작한다는 의미가 이제 명확히 보이시나요?

OpenID의 차별점

OpenID Connect는 어떤 차별점을 추가해 사용자에게 어필하고 있을까요?

스코프(Scopes): OpenID Connect의 변경 사항 중 가장 핵심적인 부분입니다. OAuth 2.0애서 제공자가 원하는 대로 요청 범위를 설정할 수 있었습니다. 이는 유연한 사용이 가능했지만, 상호 운용을 거의 완벽히 불가능하게 만들었습니다. OpenID Connect는 이 요청 범위를 openid, 프로필, 이메일, 주소로 표준화했습니다.
클레임: 요청 범위를 표준화 한 것에 더해, OpenID Connet는 요청 범위에 속하는 클레임의 종류도 표준화 했습니다. 사용자의 특정 정보와 인증의 세트가 이에 속합니다. 예를 들어 given_name과 family_name이라는 이름의 클레임을 지정한다면, 외부의 다른 시스템에서 반복과 예측 가능한 형식으로 사용자 정보를 받을 수 있습니다.
ID token
OpenID Connect에서 스코프는 특정한 정보 세트를 요청하는데 사용가능합니다. 이 정보는 클레임 값들로 만들 수 있습니다. ID token의 ID 정보는 상호 운용성에 중점을 둡니다. ID token을 통해 서드 파티 어플리케이션이 여러 웹 어플리케이션에 대해 동일한 인증 정보를 제공받을 수 있습니다.
이 ID token은 JWT로 생성됩니다.
사용자 정보 요청 엔드포인트 통일
ID token에 이어, OpenID Connect 구현을 통해 표준화된 엔드포인트를 제공합니다. 예를 들어 엔드포인트 중 /userinfo를 통해 사용자 메타데이터 정보를 검증할 수 있습니다. OpenID Connect는 엔드포인트 통일로 상호 운용성을 보장하기에 엔터프라이즈급 솔루션에 적합합니다. 상기한 차별점들을 종합해 볼 때, 결국 OpenID는 OAuth 스펙을 통일해 클라이언트간의 상호 운용성을 보장하는 것을 최우선 가치로 둠을 알 수 있습니다.

무엇을 선택할까?

사실 일반 OAuth2.0와 확장된 OpenID Connect 중 무엇을 선택할지, 웹 개발자 입장에서 기술 본연의 특성을 놓고 논의할 일은 적다고 생각합니다. OAuth 제공사가 각자의 이유로 제공하는 것에 따를 수 밖에 없으니까요. 저희는 서비스 이용자의 특성을 고려해 적절한 제공사를 고르는 것이 더 중요하게 보입니다. 예를 들어 개발자를 위한 서비스라면 GitHub 로그인이 우선시 될 것 같습니다. 아쉽게도 GitHub은 OpenID를 지원하지 않아서, 일반 OAuth를 사용할 수 밖에 없겠네요. 반면, Google 로그인은 OpenID가 적용된 OAuth가 기본 사양이니 OpenID를 쓰지 않을 수가 없습니다.

잘 쓰이는 다른 소셜 로그인도 살펴볼까요? 카카오 로그인은 OAuth를 기본으로, 선택에 따라 OpenID를 활성화 할 수 있습니다! 카카오 로그인을 쓴다면 이제 개발 상황과 기술 특성을 놓고 얘기할 수 있겠네요. 저희가 프로젝트에 적용했던 Slack은 기본 OAuth와 OpenID를 둘 다 지원했지만, 기본 OAuth는 레거시 시스템으로 부르고 OpenID 사용을 권장하고 있었습니다. 하지만 OAuth 특징인 요청 스코프를 명확하게 보여준다는 것이, 사용자에게 더 신뢰를 줄 거라 생각해 OAuth를 채택했습니다.

이상으로 OpenID에 대해 알아봤는데요, 앞으로 소셜 로그인 방식을 두고 선택을 해야할 때 도움이 되었으면 좋겠습니다.

References

JPA의 동적 쿼리

Mon, 24 Oct 2022 12:00:00 GMT

F12 프로젝트를 진행하면서 검색기능을 개발하는 과정에서 고민했던 부분을 소개해드리려고 합니다.

F12 서비스에는 회원을 검색할 수 있는 기능과 제품을 검색할 수 있는 기능이 존재합니다. 이 글에서는 좀 더 복잡한 조건이 들어가 있는 회원을 검색하는 기능을 개발했던 과정을 살펴보면서 JPA에서 동적 쿼리를 생성하고 적용하는 방법을 살펴본 다음 프로젝트에서 선택했던 방법에 대해 설명드리겠습니다.

F12의 회원 검색 기능

F12 프로젝트에서는 서비스를 이용하는 회원을 검색하는 기능이 있습니다. 검색할 수 있는 방법 중 가장 간단한 방법은 회원의 깃허브 아이디를 통해서 검색하는 것입니다. 검색하면 사용자가 검색한 아이디와 일치하는 회원을 찾아주는 방식입니다. 추가로 경력과 직군을 선택해서 검색 결과를 필터링할 수도 있습니다.

다양한 조건을 이용해서 회원을 검색하는 기능을 구현하는 방법이 여러 가지가 있었습니다. 구현 방법을 선택하기에 앞서 방법들의 장단점을 살펴보았었습니다. 저희 팀에서 고려했던 방식들을 하나씩 살펴보면서 최종적으로 F12 팀에서 선택했던 방법까지 살펴보도록 하겠습니다.

동적 쿼리를 사용하지 않는 경우

현재 Member의 검색 조건은 gitHubId, careerLevel, jobType 총 3가지입니다. 따라서 사용자가 검색을 하기 위해서 입력할 수 있는 조건의 경우의 수는 총 8가지입니다.

// 1. 검색 조건 없이 모두 조회
Slice<Member> findAll(Pageable pageable);
// 2. 깃허브 아이디 선택 조회
Slice<Member> findByGitHubId(String keyword, Pageable pageable);
// 3. 깃허브 아이디와 경력 선택 조회
Slice<Member> findByGitHubIdAndCareerLevel(String keyword, CareerLevel careerLevel, Pageable pageable);
// 4. 깃허브 아이디와 직군 선택 조회
Slice<Member> findByGitHubIdAndJobType(String keyword, JobType jobType, Pageable pageable);
// 5. 깃허브 아이디, 경력, 직군 선택 조회
Slice<Member> findByGitHubIdAndCareerLevelAndJobType(String keyword, CareerLevel careerLevel, JobType jobType, Pageable pageable);
// 6. 경력 선택 조회
Slice<Member> findByCareerLevel(CareerLevel careerLevel, Pageable pageable);
// 7. 경력, 직군 선택 조회
Slice<Member> findByCareerLevelAndJobType(CareerLevel careerLevel, JobType jobType, Pageable pageable);
// 8. 직군 선택 조회
Slice<Member> findByJobType(JobType jobType, Pageable pageable);

다음과 같이 모든 경우의 수에 대응할 수 있도록 Repository에서 모두 구현해보았습니다. 조건의 유무에 따라 사용되는 쿼리가 다르니 사용할 수 있는 메서드를 모두 만들어줘야 하는 상황입니다.

그런데 Repository의 함수만 늘어나는 것일까요? 이를 호출하는 Service 레이어에서도 들어오는 요청에 따라서 알맞은 Repository 함수를 호출하는 분기 처리가 되어야 합니다. 극단적인 예시일 수 있으나 이를 사용하는 서비스 로직을 잠시 살펴보겠습니다.

// 1번
if (!StringUtils.hasText(gitHubId) && careerLevel == null && jobType == null) {
    slice = memberRepository.findAll(pageable);
}
// 2번
if (StringUtils.hasText(gitHubId) && careerLevel == null && jobType == null) {
    slice = memberRepository.findByGitHubId(gitHubId, pageable);
}

...
  
// 8번
if (!StringUtils.hasText(gitHubId) && careerLevel == null && jobType != null) {
    slice = memberRepository.findByJobType(jobType, pageable);
}

현재는 8개의 경우의 수이기 때문에 아직은 분기 처리할 수 있고, 모두 정의하고 사용하는 것이 좋을 수도 있습니다. 하지만, 주석이 없다면 어떤 조건에서 실행되는 함수인지 판단하기 힘들 것이고 반복되는 코드가 증가하고 있는 모습을 볼 수 있습니다. 또한 서비스의 정책으로 회원의 검색조건이 추가된다면 기하급수적으로 생성해야 할 함수들이 늘어나기 때문에 관리하기 점점 어려울 것입니다.

이러한 단점을 해결하기 위해 JPA의 동적 쿼리를 활용하기로 했습니다. JPA에서 동적 쿼리를 생성하는 방법은 JPQL, Criteria, Specification, Querydsl 이렇게 4가지가 있습니다. 예시를 보면서 각각의 장단점을 알아보겠습니다.

JPQL

JPA에서는 JPQL을 통해 동적쿼리를 생성할 수 있습니다.

public Slice<Member> findWithSearchConditions(final String gitHubId, final CareerLevel careerLevel,
                                                  final JobType jobType,
                                                  final Pageable pageable) {
    // 조건에 따라서 where문을 다르게 가지는 JPQL 생성
    String jpql = "select m from Member m";
    String whereSql = " where ";
    List<String> whereCondition = new ArrayList<>();
    if (StringUtils.hasText(gitHubId)) {
        whereCondition.add("m.gitHubId like concat('%',:gitHubId,'%')");
    }
    if (careerLevel != null) {
        whereCondition.add("m.careerLevel = :careerLevel");
    }
    if (jobType != null) {
        whereCondition.add("m.jobType = :jobType");
    }
    if (!whereCondition.isEmpty()) {
        jpql += whereSql;
        jpql += String.join(" and ", whereCondition);
    }
    jpql += whereSql;
    jpql += String.join(" and ", whereCondition);
		
    // 조건에 따라서 각각의 where문에 parameter 설정
    TypedQuery<Member> query = entityManager.createQuery(jpql, Member.class);
    if (StringUtils.hasText(gitHubId)) {
        query.setParameter("gitHubId", gitHubId);
    }
    if (careerLevel != null) {
        query.setParameter("careerLevel", careerLevel);
    }
    if (jobType != null) {
        query.setParameter("jobType", jobType);
    }
    List<Member> members = query.setFirstResult((int) pageable.getOffset())
            .setMaxResults(pageable.getPageSize() + 1)
            .getResultList();
    return toSlice(pageable, members);
}

Slice<Member> slice = memberRepository.findWithSearchConditions(gitHubId, careerLevel, jobType, pageable);

if 문이 많고 함수가 복잡해 보이지만, 동적 쿼리를 이용하지 않을 때와 비교해서 Repository의 메서드와 Service의 코드가 줄어들었습니다.

하지만 여전히 단점은 존재합니다. 각 조건에 따라서 if 문을 사용한 방식으로 쿼리를 생성하고 있지만, 문자열을 통해서 하고 있다는 것입니다. 문자열을 통해서 쿼리를 만들게 되면 작성한 문자열 쿼리 중 띄어쓰기 혹은 알파벳의 오류가 있을 경우 이를 컴파일 타임에서 잡아주지 못한다는 단점이 존재합니다. 즉, 쿼리를 동적으로 생성하다 보니 개발자가 실수할 수 있는 포인트는 더 늘어났지만 쿼리를 실행하기 전까지는 오류를 찾을 수 없다는 것이죠.

Criteria

Criteria는 JPQL을 문자열이 아닌 자바 코드로 작성하도록 도와주는 빌더 클래스 API입니다. 문법적인 오류를 컴파일 단계에서 잡을 수 있으므로 JPQL보다 좀 더 안전하게 동적 쿼리를 생성할 수 있도록 도와줍니다.

public Slice<Member> findWithSearchConditions(final String gitHubId, final CareerLevel careerLevel,
                                                  final JobType jobType,
                                                  final Pageable pageable) {
    CriteriaBuilder builder = entityManager.getCriteriaBuilder();
    CriteriaQuery<Member> cq = builder.createQuery(Member.class);

    Root<Member> root = cq.from(Member.class);
    List<Predicate> predicates = new ArrayList<>();

    if (StringUtils.hasText(gitHubId)) {
        predicates.add(builder.like(root.get("gitHubId"), "%" + gitHubId + "%"));
    }
    if (careerLevel != null) {
        predicates.add(builder.equal(root.get("careerLevel"), careerLevel));
    }
    if (jobType != null) {
        predicates.add(builder.equal(root.get("jobType"), jobType));
    }
    cq.where(predicates.toArray(new Predicate[0]));

    TypedQuery<Member> query = entityManager.createQuery(cq);
    List<Member> members = query.setFirstResult((int) pageable.getOffset())
            .setMaxResults(pageable.getPageSize() + 1)
            .getResultList();
    return toSlice(pageable, members);
}

JPQL을 이용해서 동적쿼리를 생성하는 것보다 훨씬 간단해졌습니다. 또한 문자열을 통해서 쿼리를 생성하지 않아 개발자가 실수할 수 있는 포인트도 줄었습니다. 이처럼 JPA에서 제공하는 Critera를 사용하게 되면 동적 쿼리를 더 간단하고 안전하게 생성할 수 있다는 장점이 있습니다.

하지만 쿼리를 생성하기 위한 코드가 어려워졌습니다. 그리고 생성해야 하는 Predicate가 많아진다면 관리하기 어려워지고 직관적으로 이해하기 힘들다는 단점이 발생합니다.

JPA Specification & Criteria

Spring Data JPA에서는 Criteria의 사용성을 높이기 위해서 org.springframework.data.jpa.domain.Specification으로 해결법을 제공하고 있습니다. Specification을 사용하기 위해서는 Repository에서 org.springframework.data.jpa.repository.JpaSpecificationExecutor을 상속 받아야 합니다.

Specifiation을 사용한 동적 쿼리를 방식을 살펴보겠습니다.

public interface MemberRepository extends JpaRepository<Member, Long>, JpaSpecificationExecutor<Member> {

    Page<Member> findAll(Specification<Member> spec, Pageable pageable);
}

Slice<Member> slice = memberRepository.findAll(MemberSpec.searchWith(gitHubId, careerLevel, jobType), pageable);

기존의 Spring Data JPA와 달라진 점은 Specification<Member> spec을 받아서 사용하고 있다는 점입니다. Specification을 이용해서 동적 쿼리를 구현할 수 있게 되는 것입니다. 동적 쿼리를 이용했기 때문에 Service 로직도 깔끔해진 모습을 볼 수 있습니다.

파라미터로 사용되는 Specification을 생성하는 코드도 함께 보겠습니다.

public static Specification<Member> searchWith(final String gitHubId, final CareerLevel careerLevel,
                                                   final JobType jobType) {
    return ((root, query, builder) -> {
        List<Predicate> predicates = new ArrayList<>();
        if (StringUtils.hasText(gitHubId)) {
            predicates.add(builder.like(root.get("gitHubId"), "%" + gitHubId + "%"));
        }
        if (careerLevel != null) {
            predicates.add(builder.equal(root.get("careerLevel"), careerLevel));
        }
        if (jobType != null) {
            predicates.add(builder.equal(root.get("jobType"), jobType));
        }
        return builder.and(predicates.toArray(new Predicate[0]));
    });
}

MemberSpec 클래스를 만들고 정적 메서드를 활용해서 다양한 검색 조건을 조합해서 생성해주는 모습을 볼 수 있습니다. Criteria만 활용하는 것보다 코드가 훨씬 간단해진 모습을 볼 수 있습니다.

CriteriaBuilder builder = entityManager.getCriteriaBuilder();
CriteriaQuery<Member> cq = builder.createQuery(Member.class);
Root<Member> root = cq.from(Member.class);

위와 같은 CriteriaQuery를 작성을 위한 준비 코드를 작성하지 않아도 되고, Spring Data JPA를 활용한 쿼리를 사용할 수 있으니 이전보다 보기 좋고 쉬운 코드가 완성되었습니다.

하지만 여전히 Criteria를 통한 동적 쿼리 생성 방식은 복잡하고 장황해 보입니다. 무엇보다 코드의 형태가 SQL스럽지 않습니다.

Querydsl

Querydsl은 Criteria의 복잡함을 개선할 수 있는 JPQL 빌더 역할을 하는 오픈 소스 프로젝트입니다. 문자열이 아닌 자바 코드로 쿼리를 생성하는 것임에도 불구하고, 더 쉽고 간결하며 형태도 SQL과 비슷하게 개발할 수 있다는 것이 Querydsl의 장점입니다.

Querydsl을 활용해서 동적 쿼리를 만드는 코드를 살펴보겠습니다.

public Slice<Member> findWithSearchConditions(final String gitHubId, final CareerLevel careerLevel,
                                                  final JobType jobType,
                                                  final Pageable pageable) {
    BooleanBuilder builder = new BooleanBuilder();
    if (StringUtils.hasText(gitHubId)) {
        builder.and(member.gitHubId.contains(gitHubId));
    }
    if (careerLevel != null) {
        builder.and(member.careerLevel.eq(careerLevel));
    }
    if (jobType != null) {
        builder.and(member.jobType.eq(jobType));
    }
    JPAQuery<Member> jpaQuery = jpaQueryFactory.selectFrom(member)
            .where(builder)
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize() + 1)
            .orderBy(makeOrderSpecifiers(member, pageable));

    return toSlice(pageable, jpaQuery.fetch());
}

Criteria와 비교했을 때 불필요한 Predicate를 생성하는 과정이 없어 더 간결하고 가독성이 좋아졌습니다. 그리고 더 SQL스럽게 코드가 작성된 것을 볼 수 있습니다.

하지만 여전히 BooleanBuilder를 통해서 조건을 생성하는 코드가 있어서 코드가 복잡해 보입니다. Querydsl에서도 Specification을 사용한 것과 마찬가지로 BooleanBuilder를 생성하는 과정을 분리하면 최종적으로는 다음과 같은 코드가 완성됩니다.

public Slice<Member> findWithSearchConditions(final String gitHubId, final CareerLevel careerLevel,
                                               final JobType jobType,
                                               final Pageable pageable) {
    JPAQuery<Member> jpaQuery = jpaQueryFactory.selectFrom(member)
            .where(
                    toContainsExpression(gitHubId),
                    eqCareerLevel(careerLevel),
                    eqJobType(jobType)
            )
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize() + 1)
            .orderBy(makeOrderSpecifiers(member, pageable));

    return toSlice(pageable, jpaQuery.fetch());
}

private BooleanExpression toContainsExpression(final String gitHubId) {
    if (StringUtils.hasText(gitHubId)) {
        return null;
    }
    return member.gitHubId.contains(gitHubId);
}

private BooleanExpression eqCareerLevel(final CareerLevel careerLevel) {
    if (careerLevel == null) {
        return null;
    }
    return member.careerLevel.eq(careerLevel);
}

private BooleanExpression eqJobType(final JobType jobType) {
    if (jobType == null) {
        return null;
    }
    return member.jobType.eq(jobType);
}

Where 문에 어떤 조건들이 들어가는지 확인할 수 있어 훨씬 가독성이 좋아졌습니다. 이처럼 Querydsl을 통해서 동적 쿼리를 생성하는 방식이 Spring Data Specification에 비해서 가독성이 더 좋다는 것을 확인해 보았습니다.

하지만 Querydsl에도 단점이 없는 것은 아닙니다. Criteria보다는 쉽지만, SQL 작성을 위해서 새로운 방법에 적응하고 공부하는 시간이 필요하기 마련입니다. 또한 Q.Class에 의존하여 쿼리를 생성하는 것도 단점이라고 볼 수 있습니다. Q.Class를 생성하는 방법이 Gradle의 플러그인을 활용하는 방법에서 Annotation Processor로 바뀐 것처럼 어떤 버전과 빌드 방식을 사용하는가에 따라서 신경을 쓰고 다르게 설정해주어야 하기 때문입니다.

정리

지금까지 검색 기능을 개발하기 위해 JPA에서 선택할 수 있는 대안들에 대해서 살펴보았습니다. 프로젝트 초반에는 Service 레이어에서 if 문을 통해서 각 쿼리를 실행하는 것이 직관적이고 코드를 작성하기 편했었습니다. 하지만 검색에 대한 조건이 점차 늘어남에 따라서 동적 쿼리의 필요성을 느꼈습니다.

최종적으로 저희 팀은 Querydsl을 활용해서 동적 쿼리를 생성하는 방법을 선택했습니다. 그 이유는 SQL 문을 생성함에 있어서 컴파일 타임에 오류를 잡아줄 수 있어야 했고, 여러 개발자가 같이 프로젝트를 진행하기 위해서는 가독성이 중요하다고 느꼈기 때문입니다.

프로젝트의 상황에 따라 달라지겠지만, 동적 쿼리의 적용을 고민하는 개발자가 있다면 이 글이 조금이나마 도움이 되었으면 합니다.

긴 글 끝까지 읽어주셔서 감사합니다.

Reference

김영한 지음, 자바 ORM 표준 JPA 프로그래밍
이동욱님 블로그 Querydsl 다이나믹 쿼리 사용하기
Spring.io blog Specification and Querydsl
Baeldung Criteria and Specification

Git Merge

Sun, 23 Oct 2022 12:00:00 GMT

dev와 feature branch로 merge 관련된 여러 개념을 이해해봅시다!

dev : base branch
feature : dev branch에서 나눠진 하위 branch

오늘 생각해볼 내용은 이렇습니다.

merge
- fast-forward merge
- non fast-forward merge

Github에서의 여러 가지의 merge
- merge
- rebase and merge
- squash and merge

fast-forward merge

feature branch를 dev branch로 병합할 때, dev branch에 새로운 작업 내역이 없다면 merge commit 없이 HEAD만 변경할 수 있습니다.
이를 fast-forward(빨리 감기) merge라고 부릅니다.

현재 branch(feature)의 HEAD를 대상 branch(dev)의 HEAD로 옮깁니다.
이는 github에서 지원하지 않습니다. - 참고
- 즉, github에서 merge를 진행할 경우 fast-forward 옵션은 활용할 수 없습니다.

fast-forward merge의 결과물은 이와 같습니다.

정리하자면, 상위 branch에 변경사항이 없을 때만 fast-forward merge가 가능합니다.
하지만 github에서 fast-forward option을 지원하지 않습니다.

non fast-forward merge

만약 merge하려는 상위 branch에 변경사항이 있다면?
이런 경우에는 양쪽의 변경을 가져오는 merge commit이 있어야 합니다.

feature branch에서 작업을 완료하고 dev branch로 합치려고 하는데, dev branch에 다른 협업자들이 작업한 결과물이 새로 commit 되어 dev branch가 달라졌다면?

feature branch를 dev에 merge하기 위해서는 dev branch 내의 변경 내용과 feature branch 내의 변경 내용을 하나로 통합할 필요가 있습니다.
따라서 양쪽의 변경을 가져온 merge commit을 실행하게 됩니다.

이를 non fast-forward merge라고 합니다.
non fast-forward merge를 하게 되면 branch가 그대로 남기 때문에, 해당 branch로 작업한 내용들을 확인하기에 유용합니다.

Github에서의 여러가지 merge

저는 보통 github 페이지에서 쉽고 간단하게 버튼 하나로 merge를 진행합니다.
github 페이지에서 할 수 있는 merge는 세 가지가 존재합니다.

create a merge commit
squash and merge
rebase and merge

위와 같이 존재하는데, merge 버튼 옆에 있는 토글을 열면 merge option 들을 확인할 수 있습니다.
기본으로는 create a merge commit으로 설정되어 있습니다.

1️⃣ create a merge commit

앞에서 설명한 non fast-forward 입니다.
base branch로 merge를 진행할 때, merge commit을 통해 코드를 합칩니다.

merge 버튼을 누르면, merge commit을 작성하는 칸이 나옵니다.

2️⃣ squash and merge

다음은 squash and merge인데,
squash의 사전적 의미는 과일 같은 것을 쭈욱 으깨는 것을 말합니다.
과일 대신.. commit을 생각해봅시다!

dev branch로 merge하는 상황을 가정했을 때,

위와 같이 merge되는 것을 squash merge라고 합니다. feature branch의 x, y, z 커밋을 하나로 쭈욱 합쳐서 dev branch로 병합될 수 있도록 해줍니다.

x, y, z를 합쳐서 새로운 commit을 만듭니다.
이 새로운 commit은 dev branch의 HEAD를 parent로 갖습니다.

❓ 잠깐 ! squash and merge는 어떨 때 유용할까요?

저는 진행하고 있는 프로젝트에서 대댓글 기능 구현 역할을 맡았습니다.
저는 프론트로서 대댓글 기능 구현을 하기 위해, 여러 commit을 진행할 것 입니다.
 UI 만들어야지 ..
 mocking 해야지 ..
 함수 연결해야 하지 ..
 어 스타일.. 맘에 안 드네 고쳐서 commit 해야지 ..
위와 같이, 한 기능당 여러 commit이 발생할 수 있는데,
이 commit들이 dev branch commit 내역에 그대로 남는다면, 기능 별로 commit log를 확인하는 데에 있어 불편함을 겪게 되고, 미관상으로도 좋지 않습니다.

sqaush and merge 기능을 활용하면, 제가 feature/대댓글 branch에서 작업한 내용들이 하나의 커밋으로 합쳐지게 됩니다.

예를 들면, 기능(feature) 하나로 commit이 쭈욱 합쳐집니다. (dev branch commit log가 아주 예뻐지겠죠 ?!)

제가 feature branch에서 진행한 commit들은 합쳐진 commit 하나 속의 details로 남겨집니다.

3️⃣ rebase and merge

rebase and merge를 알기 전에, 우선 rebase가 뭔지 알아야합니다.

rebase

두 개의 공통 base를 가진 branch에서 (A, B),
한 branch(A)의 base를 다른 branch(B)의 최신 commit으로 base를 옮기는 작업을 말합니다.

이름에서 알 수 있듯이 re(다시) base를 설정하는 것 입니다.

예시로 이해해봅시다!

현재 저는 feature branch에서 작업을 진행하고 있습니다.
(feature branch는 dev branch로부터 파생된 branch이며 b commit까지 쌓인 이후, 저는 feature branch를 생성했습니다.)

feature branch에서 x, y commit을 하며 열심히 작업하고 있는 도중,
저의 동료 개발자가 c, d라는 작업을 완료해서 dev에 merge를 했습니다.

dev branch는 그 전과 작업 내용(feature branch를 생성하던 시기)이 달라졌기 때문에,
제가 작업을 완료하고 dev branch로 merge할 시기에 충돌이 날 가능성이 있습니다. 이때 rebase를 활용할 수 있습니다.

rebase를 활용하면 제 branch(feature)의 base commit은 b지만.
dev의 최신 작업 내용인 d로 base commit을 변경할 수 있습니다.
즉, 전과 달리 위와 같은 그림이 됩니다.

❓ base를 바꾼다는 것은 알겠는데, rebase를 활용하면 얻는 이점은 무엇이 있을까요?

1. dev branch의 최신 변경사항을 즉각 반영할 수 있습니다. (즉, 최신 dev의 최신 commit을 반영하면서 작업을 해야할 때 좋습니다.)

예를 들어, 저는 대댓글 기능을 작업하고 있고, 동료 개발자는 댓글 부분의 오류를 수정하고 있다고 가정해봅시다.
대댓글을 작업하는 동시에, 동료 개발자가 dev branch로 merge 완료된 작업을 rebase를 통해 버그가 수정된 작업본을 바로 이어받아 진행할 수 있습니다.

2. merge commit 이력을 남기지 않아, 깔끔한 commit history를 유지할 수 있습니다.

만약 동료 개발자가 한 작업(dev에 merge됨)이 저의 코드와 충돌이 발생한다면 어떻게 할까요?
rebase를 활용하지 않는다면, 충돌을 해결한 merge commit을 push 해야 해서 commit history가 더럽혀질 수 있습니다.
하지만 rebase를 활용하면, 제 commit들이 마치 충돌이 발생하지 않았던 것처럼 동료 개발자 commit 뒤에 위치하게 되므로 깔끔하게 commit history를 유지할 수 있습니다.

❓ 어.. 그런데 rebase를 했더니 계속 같은 충돌을 해결하래요 ㅠㅠ 왜이래요 이거!

제가 처음 rebase를 알았을 때, 계속 충돌이 나서 저는 ‘내가 뭘 잘못 만졌구나..’라고만 생각했습니다.
하지만 이는 rebase의 과정을 생각해보면 이해할 수 있습니다.

위 그림에서 다시 생각해봅시다.

만약 동료 개발자가 dev로 merge한 PR의 작업(c, d)들이 나의 코드와 충돌이 나는 작업이었다면?
rebase를 딱 시작했을 때, 제 commit은 x, y가 존재합니다.
제 commit인 x, y는 모두 b를 기준으로 작업했기 때문에 x, y 둘 다 d의 뒤로 보내주기 위해서는 x, y commit 둘 다 충돌을 해결해주어야 합니다.

이런 이유로 계속 충돌을 해결하라는 메시지가 뜨는 것 입니다.
이는 rebase의 단점으로 꼽히는데요. commit 마다 충돌 처리를 해주어야 하기 때문입니다.

다시 rebase and merge로 돌아와봅시다.

rebase and merge를 진행하면 위와 같은 그림이 그려질 것 입니다.
x commit의 base를 b에서 d로 변경하며 merge가 됩니다.
rebase and merge를 활용하면 merge commit 없이 merge를 진행할 수 있고,
squash merge와는 다르게 하나의 커밋으로 합쳐지지 않고 PR의 commit 하나하나 살아서 dev branch로 merge 됩니다.

다양한 merge, 어떻게 활용하면 좋을까요?

저희 팀에서는 rebase를 한 후, squash and merge하는 전략을 채택하고 있습니다.
만약 slack에서 동료 개발자 혹은 저의 PR이 merge되었다는 알림이 오면 rebase를 진행합니다.

git fetch origin dev
git rebase origin/dev

위와 같이 입력하고 rebase를 진행하며 충돌이 있다면, 충돌을 하나하나 해결해줍니다.
(만약 IDE에 현재 작업 내용이 있다면 stash를 활용합니다.)

rebase를 활용하면, 최신 작업 내용을 가져올 수 있고, 충돌 해결을 위한 commit이 없어져서 활용하고 있습니다.
이후, squash and merge를 진행하는데, dev에 기능 별로 commit이 쌓이기 때문에 commit log가 깔끔해지는 이유로 사용하고 있습니다.

이 방식은 주의해야할 점이 있습니다.

하지만 이 방식에는 주의해야할 점이 있습니다.
만약 main을 서비스용 branch로 사용하고,
dev를 개발용 branch로 사용한다고 하면
dev branch를 main branch로 merge할 때 squash merge를 사용하면 안됩니다.

dev에 a, b, c commit이 있고 main에 squash merge를 한다고 가정해봅시다.

squash merge 이후 상황은 위와 같습니다.
main branch는 서비스용 branch기 때문에, 추후 개발 기간동안 구현된 기능은 dev branch에 merge 될 것이고,
개발 완료된 기능들이 서비스로 release 될 때, dev에서 다시 main으로 merge가 될 것 입니다.

main으로의 release 이후 새로운 커밋 d, e가 dev에 merge 되었습니다.
d, e를 release 하기 위해서는 우리는 다시 main으로 merge를 할 것 입니다.
d, e를 포함한 PR을 작성하는 순간 충돌이 발생하게 됩니다!

이는 main에 squash merge된 a, b, c commit이 a, b, c commit을 포함하고 있다는 사실을 알 수 없기 때문에 발생하는 현상입니다.
PR에 포함된 commit을 살펴보면 d, e 뿐만 아니라, 이전에 이미 main에 merge한 commit인 a, b, c도 commit 내역에 포함되어 있는 것을 볼 수 있습니다.
즉, main branch의 a, b, c commit 이전 조상을 main과 dev의 공통 조상으로 인식하게 됩니다.
이런 이유로 충돌이 발생합니다.

feature branch의 경우 해당 기능 구현 이후 사용되지 않을 branch이기 때문에 dev로의 squash merge 이후 발생할 문제가 없습니다.
하지만 dev branch의 경우 main에 merge된 이후라고 해도 이전 dev branch를 삭제하고 새로운 dev branch를 main에서 파생시키지 않는 이상 재활용되게 됩니다.
그렇기 때문에 두개의 base를 맞춰 주는 것이 중요합니다.

참고

슬랙 소셜 로그인과 알림을 위한 앱 설치 가이드

Sat, 22 Oct 2022 12:00:00 GMT

슬랙 소셜 로그인과 알림을 위한 앱 설치 가이드

구글, 깃허브, 카카오, 네이버와 같은 서비스는 소셜 로그인을 제공합니다. 슬랙도 해당 기능을 지원하지만 사용자가 많지 않아 한글로 작성된 가이드를 찾기 어렵습니다. 슬랙은 앱을 배포하면 워크스페이스에 봇을 설치해 사용자에게 알림을 보낼 수 있는 기능을 제공합니다. 위 글에서 꼭꼭 프로젝트 에 슬랙 로그인과 알림을 지원하기 위해 탐구한 내용을 공유합니다.

슬랙은 OAuth2, OpenId Connect 방식의 소셜 로그인을 지원합니다. 해당 글은 OAuth2 표준의 동작 방식을 알고 있는 사람을 대상으로 작성하였습니다. 만약 OAuth 동작 방식을 모른다면 OAuth2 동작 방식을 검색하거나 OAuth 개념 및 동작 방식 이해하기 를 참고해주세요.

슬랙 소셜 로그인

OpenId Connect를 사용하는 방법입니다. 슬랙은 해당 엔드포엔트에서 사용자 정보를 요청할 수 있는 엑세스 토큰을 제공합니다.

슬랙 로그인 과정

Resource Owner가 슬랙으로 로그인 버튼을 눌러 Slack Authorization Server의 엔드포인트로 접속하여 로그인하고 정보 제공을 승인합니다.

Slack Authorization Server의 엔드포인트

GET https://slack.com/openid/connect/authorize?
 scope=email openid profile
&client_id=4274003xxxxxx.xxxxxxxxxxxxx
&redirect_uri=https://kkogkkog.com/redirect
&response_type=code

Slack Authorization Server는 설정한 Client의 URL로 리다이렉트시킵니다. 이때 QueryString으로 Authorization code를 전달합니다.

GET https://kkogkkog.com/redirect?code=12345678.90ab

Client는 Resource Owner를 거치지 않고 ClientId, Client Secret, Code를 Slack Authorization Server에 전달 합니다. 만약 올바른 코드이면 엑세스 토큰을 반환합니다.

OpenId Connect 표준에 따라 id_token의 payload 부분에도 유저 정보가 인코딩되어 있습니다.

POST https://slack.com/api/openid.connect.token
Content-Type: application/x-www-form-urlencoded;charset=UTF-8

client_id="4274003xxxxxx.xxxxxxxxxxxxx"
&client_secret="3001a9f1xxxxxxxxxxxxxxxxxxxxxxxx"
&redirect_uri="https://kkogkkog.com/redirect"
&code="12345678.90ab"

Content-Type: application/json;charset=UTF-8

{
    "ok": true,
    "access_token": "xoxp-1234",
    "token_type": "Bearer",
    "id_token": "eyJhbGcMjY5OTA2MzcWNrLmNvbVwvdGVhbV9p..."
}

이제 엑세스 토큰으로 Resource Server에서 유저 정보와 같은 자원을 가져와 내가 만든 서버에서 사용할 수 있습니다.

GET https://slack.com/api/openid.connect.userInfo
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Authorization: Bearer {Access Token}

Content-Type: application/json;charset=UTF-8

{
    "ok": true,
    "sub": "U0R7JM",
    "https://slack.com/user_id": "U0R7JM",
    "https://slack.com/team_id": "T0R7GR",
    "email": "krane@slack-corp.com",
    "name": "krane",
    "picture": "https://secure.gravatar.com/....png",
    "locale": "en-US",
    "https://slack.com/team_name": "kraneflannel",
}

슬랙 앱 설정

슬랙 로그인을 위한 앱 설정 과정입니다.

https://api.slack.com/apps 에 접속하여 Go to Slack 버튼을 클릭합니다.
등록하고자 하는 워크스페이스에 소속된 계정으로 로그인합니다.
로그인 후 앱을 설정할 워크스페이스를 선택합니다.
https://api.slack.com/apps 에 접속하여 Create an App 버튼을 클릭하여 앱을 생성합니다.
초기 화면에서 OAuth & Permissions 탭을 선택합니다.
Https로 시작하는 Client의 Redirect Url을 설정합니다.
Open Id connect를 사용하기 위한 openid, profile, email Scopes를 추가합니다.
Install to Workspace를 클릭하여 앱을 설치합니다. 앞으로 변경사항이 있을 때 마다 앱 재설치가 필요합니다.
이제 슬랙 로그인을 사용하기 위한 설정을 완료하였습니다. Basic Information에서 Client Id와 Client Secret을 기억해둡니다.

3, 4 과정 예시 코드

→ 예시 코드이며 실제 서비스마다 다르게 활용할 수 있다.

백엔드 WAS에서 프론트엔드 Client로부터 인가 코드를 받는 컨트롤러 예시이다.


@RestController
public class SlackController {

  @GetMapping("/code")
  public ResponseEntity<SlackOpenIdConnectUserInfo> login(@RequestParam String code) {
    SlackOpenIdConnectTokenResponse response = slackOpenIdConnectToken(code);
    String accessToken = response.getAccessToken();

    SlackOpenIdConnectUserInfo userInfo = slackConnectUserInfo(accessToken);
    return ResponseEntity.ok(userInfo);
  }
}

openid connect token docs

private SlackOpenIdConnectTokenResponse slackOpenIdConnectToken(final String code){
  RestTemplate restTemplate=new RestTemplate();
  String requestUrl="https://slack.com/api/openid.connect.token";

  MultiValueMap<String, String> parameters=new LinkedMultiValueMap<>();
  parameters.add("client_id","4274003xxxxxx.xxxxxxxxxxxxx");
  parameters.add("client_secret","3001a9f1xxxxxxxxxxxxxxxxxxxxxxxx);
  parameters.add("redirect_uri","https://kkogkkog.com/redirect");
  parameters.add("code",code);

  HttpHeaders headers=new HttpHeaders();
  headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
  headers.setAccept(Collections.singletonList(MediaType.APPLICATION_JSON));

  HttpEntity<MultiValueMap<String, String>>httpEntity=new HttpEntity<>(parameters,headers);

  return restTemplate.postForObject(requestUrl,httpEntity,SlackOpenIdConnectTokenResponse.class);
  }

public class SlackOpenIdConnectTokenResponse {

 private String ok;

 @JsonProperty("access_token")
 private String accessToken;


 public SlackOpenIdConnectTokenResponse() {
 }

 public String getOk() {
   return ok;
 }

 public String getAccessToken() {
   return accessToken;
 }
}

openid connect userInfo docs

private SlackOpenIdConnectUserInfo slackConnectUserInfo(final String token){
  RestTemplate restTemplate=new RestTemplate();
  String requestUrl="https://slack.com/api/openid.connect.userInfo";

  HttpHeaders headers=new HttpHeaders();
  headers.setBearerAuth(token);
  headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
  headers.setAccept(Collections.singletonList(MediaType.APPLICATION_JSON));

  HttpEntity<MultiValueMap<String, String>>httpEntity=new HttpEntity<>(headers);

  return restTemplate.postForObject(requestUrl,httpEntity,SlackOpenIdConnectUserInfo.class);
  }

private SlackOpenIdConnectUserInfo slackConnectUserInfo(final String token){
  RestTemplate restTemplate=new RestTemplate();
  String requestUrl="https://slack.com/api/openid.connect.userInfo";

  HttpHeaders headers=new HttpHeaders();
  headers.setBearerAuth(token);
  headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
  headers.setAccept(Collections.singletonList(MediaType.APPLICATION_JSON));

  HttpEntity<MultiValueMap<String, String>>httpEntity=new HttpEntity<>(headers);

  return restTemplate.postForObject(requestUrl,httpEntity,SlackOpenIdConnectUserInfo.class);
  }

슬랙 앱 설치

슬랙은 토큰 종류를 Bot과 User로 구분합니다. 알림을 보낼 수 있는 Bot Token 또한 OAuth 엔드포인트를 사용하여 User Token과 같은 방식으로 얻을 수 있습니다.

앱 설치 과정

Add To Slack 버튼을 눌러 Slack Authorization Server의 엔드포인트로 접속하여 앱 설치를 승인합니다.

GET https://slack.com/oauth/v2/authorize?
client_id=4274003xxxxxx.xxxxxxxxxxxxx
&scope=chat:write,users:read,users:read.email
&user_scope=openid,profile,email

Slack Authorization Server는 설정한 Client의 URL로 리다이렉트시킵니다. 유저 로그인과 마찬가지로 Slack App에서 Redirect Uri를 미리 등록해야 합니다.

GET https://kkogkkog.com/redirect/download?code=12345678.90ab

Client는 Resource Owner를 거치지 않고 ClientId, Client Secret, Code를 Slack Authorization Server에 전달 합니다. 만약 올바른 코드이면 봇 엑세스 토큰을 반환합니다. 이 시점에 워크스페이스에 앱이 설치됩니다.

POST https://slack.com/api/oauth.v2.access
Content-Type: application/x-www-form-urlencoded;charset=UTF-8

client_id="4274003xxxxxx.xxxxxxxxxxxxx"
&client_secret="3001a9f1xxxxxxxxxxxxxxxxxxxxxxxx"
&redirect_uri="https://kkogkkog.com/redirect/download"
&code="12345678.90ab"

Content-Type: application/json;charset=UTF-8

{
    "ok": true,
    "access_token": "xoxb-17653672481-19874698323-pdFZKVeTuE8sk7oOcBrzbqgy",
    "token_type": "bot",
    "scope": "chat:write,users:read,users:read.email",
    "bot_user_id": "U0KRQLJ9H",
    "team": {
        "name": "Slack Softball Team",
        "id": "T9TK3CUKW"
    }
}

슬랙 앱 배포 설정

OAuth & Permissions 탭을 선택하고 chat:write, users:read, users:read.email Scopes를 추가합니다. 앱을 배포하고 나면 해당 스코프를 사용하는 이유를 작성해야 합니다.
초기 화면에서 Distribute App을 클릭하고 안내 사항을 체크한 후 Activate Public Distribution을 눌러 앱을 배포합니다.
배포가 완료되면 Add to Slack 버튼을 받을 수 있습니다.

슬랙 알림 보내기

이제 사용자가 로그인할 때 받았던 User Id와(channel) 사용자 워크스페이스의 봇 엑세스 토큰이 있으면 DM을 보낼 수 있습니다.

Slack Chat PostMessage Docs

POST https://slack.com/api/openid.connect.token
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
or Content-Type: application/json;charset=UTF-8
Authorization: Bearer {Access Token} => BotToken

{
channel: "U0R7JM", # userID 또는 ChannelID 입력

1개 이상 필수
text: "Hello World!",
blocks: ,
attachments:
}

Content-Type: application/json;charset=UTF-8

{
    "ok": true,
    "channel": "C123456",
    "message": {
        "text": "Here's a message for you",
        "username": "ecto1",
        "bot_id": "B123456",
        "attachments": [
            {
                "text": "This is an attachment",
                "id": 1,
                "fallback": "This is an attachment's fallback"
            }
        ]
    }
}

JPA Hibernate 프록시 제대로 알고 쓰기

Mon, 17 Oct 2022 13:10:00 GMT

JPA를 사용할 때 장점이 뭘까요? 많은 장점들이 있겠지만, 그 중 하나로 객체 그래프를 통해 연관관계를 탐색할 수 있다는 것을 꼽을 수 있습니다. 하지만 엔티티들은 데이터베이스에 저장되어 있기 때문에 한 객체 조회 시 연관되어 있는 엔티티들을 모두 조회하는 것 보다는 필요한 연관관계만 조회해 오는 것이 효과적입니다. 이런 상황을 위해 JPA는 지연 로딩이라는 방식을 지원하는데요, 그 중에서도 우리가 일반적으로 가장 많이 사용하는 JPA 구현체인 하이버네이트(Hibernate)는 프록시 객체를 통해 지연 로딩을 구현하고 있습니다. JPA 프록시는 지연 로딩이 가능하게 해주는 고마운 기술이지만 잘못 사용하면 예상하지 못한 예외들을 만나게 될 수 있습니다. 오늘 이 시간에는 JPA를 사용하며 만나는 예외에 당황하지 않기 위해 JPA 프록시에 대해 알아보는 시간을 갖도록 하겠습니다.

JPA 프록시(Proxy) 란?

JPA 프록시에 대해 알아보기에 앞서, 프록시란 무엇일까요? 프록시는 ‘대신하다‘라는 의미를 가지고 있는 단어인데요, 동작을 대신해주는 가짜 객체의 개념이라고 생각하시면 되겠습니다. 프록시는 JPA 하이버네이트에만 존재하는 개념은 아닙니다. 대표적으로 스프링에서도 초기화를 지연시켜준다든가, 트랜잭션을 적용한다든가 하는 부가 기능을 추가할 때 프록시 기술을 사용하는 것을 생각하면 이해하기 쉽습니다.

위에서 설명했듯이 하이버네이트는 지연 로딩을 구현하기 위해 프록시를 사용합니다. (JPA 명세에는 지연 로딩의 구현 방법은 나와있지 않습니다. 즉, 구현체에 지연 로딩의 방법을 위임합니다. 때문에 이후로 설명하는 모든 내용은 하이버네이트 기준입니다.) 지연 로딩을 하려면 연관된 엔티티의 실제 데이터가 필요할 때 까지 조회를 미뤄야 합니다. 그렇다고 해당 엔티티를 연관관계로 가지고 있는 엔티티의 필드에 null 값을 넣어 둘 수는 없겠죠? 하이버네이트는 지연 로딩을 사용하는 연관관계 자리에 프록시 객체를 주입하여 실제 객체가 들어있는 것처럼 동작하도록 합니다. 덕분에 우리는 연관관계 자리에 프록시 객체가 들어있든 실제 객체가 들어있든 신경쓰지 않고 사용할 수 있습니다. 참고로 프록시 객체는 지연 로딩을 사용하는 것 외에도 em.getReference를 호출하여 프록시를 호출할 수도 있습니다.

프록시는 실제 객체의 상속본이다

프록시가 어떻게 실제 객체처럼 동작을 할 수 있을까요? 이는 프록시가 실제 객체를 상속한 타입을 가지고 있기 때문입니다. 그리고 프록시 객체는 실제 객체에 대한 참조를 보관하여, 프록시 객체의 메서드를 호출했을 때 실제 객체의 메서드를 호출합니다. 그래서 실제 객체 타입 자리에 들어가도 문제 없이 사용할 수 있는 것이죠. 프록시 객체가 실제 객체의 상속본인 것은 JPA 엔티티 생성의 중요한 규칙을 만들어내기도 했습니다. 바로 ‘기본 생성자는 최소 protected 접근 제한자를 가져야 한다.’ 는 규칙과 ‘엔티티 클래스는 final로 정의할 수 없다. 입니다.’ 만약 기본 생성자가 private이면 프록시 생성 시 super를 호출할 수 없을 것이고, 엔티티를 final로 선언한다면 상속이 불가능하게 되겠죠?

프록시의 초기화

그런데 최초 지연 로딩 시점에는 당연히 참조 값이 없습니다. 때문에 실제 객체의 메서드를 호출할 필요가 있을 때 데이터베이스를 조회해서 참조 값을 채우게 되는데요, 이를 프록시 객체를 초기화한다고 합니다. 앞서 말씀드렸듯이 실제 객체의 메서드를 호출할 필요가 있을 때 select 쿼리를 실행하여 실제 객체를 데이터베이스에서 조회해오고, 참조 값을 저장하게 됩니다. 예를 들어볼까요? 다음과 같은 두 엔티티가 있습니다.

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

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

    @Column
    private String name;

    @JoinColumn(name = "team_id")
    @ManyToOne(fetch = FetchType.LAZY)
    private Team team;

    public Member(String name, Team team) {
        this.name = name;
        this.team = team;
    }
    ...
}

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

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

    @Column
    private String name;

    public Team(String name) {
        this.name = name;
    }
    ...
}

(간략한 코드를 위해 Lombok을 사용한 점 이해 부탁드립니다) Member의 연관관계 Team은 지연 로딩으로 설정되어 있기 때문에, Member를 조회해오게 되면 team 필드 자리에는 프록시가 들어가 있습니다. 이 때 프록시 Team의 getName 메서드를 호출하게 되면 select 쿼리가 실행되고 프록시가 초기화됩니다.

System.out.println("========");
Team team = member.getTeam();
System.out.println(team.getName()); // 이 시점에 프록시 초기화!

단, 이 때 프록시가 실제 객체를 참조하게 되는 것이지 프록시가 실제 객체로 바뀌지는 않는다는 점을 주의하셔야합니다. 참고로 프록시를 초기화하지 못하는 경우도 있습니다. 프록시의 초기화는 영속성 컨텍스트의 도움을 받습니다. 때문에 영속성 컨텍스트의 관리를 받지 못하는 상황, 즉 준영속 상태의 프록시를 초기화 한다거나 OSIV 옵션이 꺼져 있는 상황에(기본값으로는 켜져 있습니다.) 트랜잭션 바깥에서 프록시를 초기화 하려 하는 경우 LazyInitializationException을 만나게 되실 수 있습니다. 때문에 프록시를 초기화할 때는 반드시 프록시가 영속 상태여야 한다는 점에 주의해주세요!

id를 조회할 때는 프록시가 초기화되지 않는다

그런데 getName이 아닌 getId를 호출할 때도 초기화될까요? 테스트해보도록 하겠습니다.

System.out.println("========");
Team team = member.getTeam();
System.out.println(team.getId());

id를 그대로 출력하고 select 쿼리는 발생하지 않습니다! 우리는 여기서 식별자를 조회할 때는 프록시를 초기화하지 않는다 라는 사실을 유추할 수 있습니다. 좀 더 자세히 들어가볼까요? 프록시 초기화 과정은 프록시 객체 내부의 ByteBuddyInterceptor라는 클래스가, 정확히는 상위의 추상 클래스인 AbstractLazyInitializer가 담당하게 됩니다. AbstractLazyInitializer의 초기화 로직을 확인해보도록 하겠습니다.

@Override
public final Serializable getIdentifier() {
    if (isUninitialized() && isInitializeProxyWhenAccessingIdentifier() ) {
        initialize();
    }
    return id;
}

엔티티의 식별자를 조회하는 메서드를 호출하게 되면 최종적으로는 AbstractLazyInitializer의 getIdentifier 메서드를 호출하게 되는데요, 이 때 if 문 바깥쪽을 보면 그대로 id를 반환하는 것을 알 수 있습니다. AbstractLazyInitializer가 id 값을 가지고 있기 때문에 가능한 일입니다. if문 안쪽은 초기화되지 않았을 것과, 식별자 접근시 프록시를 초기화 하는 옵션을 켰을 때 true가 되는 조건문인데요, hibernate.jpa.compliance.proxy 라는 설정값을 true로 해 줘야만 해당 옵션이 켜집니다. 기본 설정값은 false이기 때문에 일반적으로는 id의 getter를 호출하게 되면 프록시가 초기화되지 않는 것이죠. 그런데 주의하실 점이 있습니다. 제가 호출한 메서드는 getId로, 자바 빈 규약에 맞는 get + 필드명 이기 때문에 getIdentifier 메서드가 호출된 것입니다. 만약 findId와 같이 getter에 대한 자바 빈 규약을 만족시키지 못하거나, getTeamId와 같이 식별자 이름과 매칭되지 않을 경우 getIdentifier 메서드를 호출하지 못하고 프록시가 초기화되게 됩니다. 또하나 주의하실 점은, id값은 프록시가 아니라 프록시 내부의 인터셉터에 들어있고, 프록시 객체가 가진 필드값들은 모두 null이라는 것입니다. 일반적으로는 필드로 꺼내 쓰기 때문에 상관 없겠지만, 만약 필드가 public이어서 바로 접근한다면 null에 접근하게 되는 것입니다.

프록시의 equals를 재정의 할 때는 instanceof와 getId를 사용할 것

우리는 흔히 equals / hashcode 메서드를 만들 때 인텔리제이의 기능을 빌리곤 합니다. 그리고 보통 JPA 엔티티의 equals는 id값만 비교해서 재정의하게 되죠. 결국 다음과 같은 메서드가 만들어질 것입니다!

@Override
public boolean equals(Object o) {
    if (this == o) {
        return true;
    }
    if (o == null || getClass() != o.getClass()) {
        return false;
    }
    Team team = (Team) o;
    return Objects.equals(id, team.id);
}

이렇게 equals를 재정의하게 된다면, 프록시 객체의 equals를 호출했을 때 문제가 생기게 됩니다! 다음 테스트 코드를 통해 확인해보겠습니다.

Team team = member.getTeam();
Team sameTeam = member.getTeam();
assertThat(team).isEqualTo(sameTeam);

주소값도 같은 객체인데 equals 메서드를 통해 동등성을 비교하는 isEqualTo를 통과하지 못합니다. 주소값이 같기 때문에 ==로 비교하면 같은 객체라고 하는데, 정작 동등성은 만족시키지 못하는 것이죠. 어떻게 된 일일까요? 답은 getClass에 있습니다. sameTeam을 인수로 하여 team의 equals를 호출합니다. getId가 아닌 메서드를 호출했으니 프록시 team이 초기화되고 프록시 team 내부의 실제 객체의 equals를 호출합니다. 그렇다면 getClass는 어떻게 될까요? equals 안에서 호출되는 getClass의 결과는 Team.class인 반면, 인수로 전달받은 sameTeam의 getClass의 결과로는 프록시 타입이 나오게 되어 equals 결과값이 false가 나오게 됩니다.

때문에 일반적으로 equals를 비교하던 것처럼(물론 애초에 리스코프 치환 원칙을 위반하는 코드이기는 합니다!) getClass를 비교하는 것으로 equals를 작성해서는 안되고, o instanceof Team과 같은 형태로 코드를 작성해주셔야 합니다! 프록시는 원본 객체의 상속이라고 했었죠? 때문에 instanceof를 통과하게 됩니다. 그리고 또 하나 수정해줘야 하는 부분이 있습니다. 일반적인 객체의 상속관계라면 문제가 없겠지만, 위에서 설명드렸듯이 프록시의 필드값은 모두 null입니다. 그래서 team.id는 사실 null인 것이죠. 그래서 Objects.equals(id, team.id)는 id값과 null을 비교하게 되어 false가 반환되게 됩니다. 하지만 getId는 실제 id를 반환하므로, 우리는 equals 코드를 다음과 같이 고칠 수 있습니다.

@Override
public boolean equals(Object o) {
    if (this == o) {
        return true;
    }
    if (!(o instanceof Team)) {
        return false;
    }
    Team team = (Team) o;
    return Objects.equals(id, team.getId());
}

프록시의 equals 부분은 간과하고 넘어가기 쉬운 부분이면서, 많은 버그를 발생시키는 부분이니 꼭 주의해주시길 바랍니다 :)

프록시가 생성되면 영속성 컨텍스트는 프록시를 반환한다

프록시로 만들어진 엔티티에 대한 조회가 들어온다면, 영속성 컨텍스트는 실제 엔티티와 프록시 객체 중 어떤 객체를 반환해야 할까요? 영속성 컨텍스트의 특징으로 동일성 보장이 있습니다. 그런데 위에서 한 번 프록시로 만들어진 객체는 프록시 초기화를 하더라도 실제 엔티티로 변환되지 않고 참조값만 가지게 된다고 언급했습니다. 때문에 동일성을 보장해주기 위해서 한 트랜잭션 내에서 최초 생성이 프록시로 된 엔티티는 이후 초기화 여부에 상관 없이 영속성 컨텍스트가 무조건 같은 프록시 객체를 반환해주게 됩니다.

Team team = teamRepository.findById(1L).get();
assertThat(team).isInstanceOf(HibernateProxy.class);

반대로 영속성 컨텍스트에 최초로 저장될 때 실제 엔티티로 저장될 경우, 이후로는 프록시가 아닌 실제 엔티티가 반환됩니다. 이는 지연 로딩으로 인해 프록시가 들어갈 자리에도 마찬가지로, 이미 영속성 컨텍스트에 엔티티가 저장된 상태에서 해당 엔티티를 FetchType.LAZY로 가지고 있는 엔티티를 조회하는 경우라면, 프록시 객체를 반환하는 대신 실제 엔티티를 반환해주게 됩니다.

System.out.println("========");
Team team = teamRepository.findById(1L).get();
Member member = memberRepository.findById(1L).get();
assertThat(member.getTeam()).isNotInstanceOf(HibernateProxy.class)

정리

JPA Hibernate의 프록시는 지연 로딩을 통해 불필요한 데이터 조회를 방지해주는 고마운 기술입니다. 하지만 그만큼 기술에 대한 이해를 하고 사용하지 못하면 예상치 못한 결과로 오히려 버그와 씨름하느라 더 많은 자원을 낭비할수도 있는 기술입니다. 대부분의 기술이 버그와 부작용을 막으려면 그 기술에 대해 깊게 이해해야 하겠지만, 제 생각에 프록시는 눈으로 보이는 부분이 많지 않기 때문에 더더욱 그렇습니다. 물론 이 글을 끝까지 정독해주신 여러분이라면 큰 문제 없이 프록시를 다루게 되실 수 있을 겁니다. 프록시에 대해서 제대로 알고, 편하고 안전하게 JPA를 사용해보도록 합시다!

참고 자료

자바 ORM 표준 JPA 프로그래밍 (김영한 저)

함수 오버로딩

Sat, 15 Oct 2022 12:00:00 GMT

서언

TypeScript에는 Function Overloading 기능이 있습니다. 이번에 Function Overloading의 강력함을 깨닫고, 이를 공유하고자 아티클을 씁니다. 함수 오버로딩이 왜 필요한지 이해하고, useRef 예시와 저희 프로젝트에 적용해본 예시를 설명드리겠습니다.

타입스크립트에서 함수 오버로딩이 왜 필요한가?

자바스크립트는 인자의 개수와 타입 제한이 없습니다. 코드 예시를 보겠습니다.

function add(a, b, c) {
  if (b) {
    if (c) {
      return a + b + c;
    }
    return a + b;
  }
  return a;
}

console.log(add(1, 2, 3)); // 6
console.log(add(1, 2)); // 3
console.log(add(1)); // 1

console.log(add('시', '지', '프')); // 시지프
console.log(add('시', '짚')); // 시짚
console.log(add('짚')); // 짚

add 함수만 보고는 숫자를 더하는 함수인지, 문자를 더하는 함수인지 역할을 파악하기 어렵습니다. 가령 저는 숫자를 더하기 위해 만들었지만, 다른 팀원은 문자를 합치기 위해 사용하고 있다면 소통이 원활히 이루어졌다고 말하기 어려울 것입니다. 이때 타입스크립트가 강력한 역할을 합니다. 타입스크립트가 즉, JSDoc과 같이 코드 명세 역할을 하여 더 나은 협업을 이끌 수 있습니다.

위 코드에 타입을 얹어봅시다.

function add(a: number | string, b?: number | string, c?: number | string): number | string {
  if (b) {
    if (c) {
      return a + b + c;
      // Operator '+' cannot be applied to types 'string | number' and 'string | number'.
    }
    return a + b;
  }
  return a;
}

가장 먼저 떠오르는 것은 위와 같이 타이핑하는 것인데요. 공교롭게도 이러한 타이핑은 에러를 발생시킵니다. string | number에 ’+’ 연산을 할 수 없다는 것입니다. 다른 방식의 해결이 필요합니다.

저는 타입스크립트에서 무분별한 <유니온> 사용을 경계해야 한다고 생각합니다. 무분별한 유니온은 가짓수 확장을 곱절로 늘립니다. 위 케이스를 보면, add 함수가 가질 수 있는 a, b, c, ReturnType의 가짓수를 고려하면 최대 2⁴ = 16개 입니다.

과연 add 함수가 16가지를 모두 커버하는 것이 좋은 타이핑일까요? 아닐 것입니다.

우리가 저 함수를 정의한 의도는 (1) 숫자 끼리 연산하여 숫자를 반환하거나, (2) 문자끼리 연산하여 문자를 반환하는, 2가지일 것입니다.

이런 16가지 함수 타입을 2가지로 좁혀주는 방법이 바로 함수 오버로드(function overload)입니다.

함수 오버로드는 어떻게 사용하는가?

함수 오버로드는 오버로드 시그니처(overload signature)를 활용합니다.

아래와 같이 overload signature와 implementation signature를 정의합니다.

function add(a: string, b?: string, c?: string): string; // (1) overload signature
function add(a: number, b?: number, c?: number): number; // (2) overload signature
function add(a: any, b?: any, c?: any): any {
  // (3) implementation signature
  if (b) {
    if (c) {
      return a + b + c;
    }
    return a + b;
  }
  return a;
}

add 함수는 (1) 또는 (2) 함수 타입으로 실현됩니다. 이는 args, return의 타입에 따라 동적으로 정해집니다.

숫자를 넣으면 (1) 오버로드 시그니처로 실현되고,

console.log(add(1, 2));

문자를 넣으면 (2) 오버로드 시그니처로 실현됩니다.

console.log(add('시', '지', '프'));

이때 주의할 점은, (3) 구현부 타입은 절대 실현되지 않습니다. 구현부는 모든 오버로드 시그니처를 포괄하는 타입일 뿐입니다. add 함수가 실제로 받아올 수 있는 모든 인자타입과 모든 ReturnType을 적어줍니다.

아래와 같이 string | number로 타이핑해도 되지만, 여전히 구현부에서 string | number에 대해 ’+’ 연산을 수행할 수 없으므로 에러가 발생합니다.

function add(a: string | number, b?: string | number, c?: string | number): string | number {

정리하자면, 실행 시그니처는 오버로드 시그니처의 타입을 포함하고 있어야 합니다.

useRef를 통해 함수 오버로드 익히기

함수 오버로드를 공부한 후, 가장 밀접하게 다가오는 장점은 아마 .d.ts 파일을 읽어낼 수 있다는 것입니다. 라이브러리 함수 중 다수가 함수 오버로드로 정의되어 있습니다. d.ts 파일을 보면, 하나의 타입만을 가지는 함수는 아마 드물 것입니다.

가령 React 라이브러리의 index.d.ts를 들어가보면, useRef의 타입을 확인할 수 있습니다.

function useRef<T>(initialValue: T): MutableRefObject<T>; // (1)
function useRef<T>(initialValue: T | null): RefObject<T>; // (2)
function useRef<T = undefined>(): MutableRefObject<T | undefined>; // (3)

useRef는 3가지 오버로드 시그니처로 정의 되어 있습니다. 뭔가 비슷한 형태이지만, 어디에 null이나 undefined이 포함되어 있습니다.

(2) 초기값에 null이 포함되는지, (3) 초기값이 비어있는지(undefined), (1) null도 undefined도 아닌 제네릭 T 타입인지에 따라 ReturnType이 달라집니다.

MutableRefObject 또는 RefObject를 반환합니다.

MutableRefObject는 말 그대로 변할 수 있는 Ref 객체이고, RefObject는 불변 Ref 객체입니다. d.ts를 읽어보면 특별한 것 없습니다.

current가 불변(readonly)이냐 아니냐를 정의하는 인터페이스일 뿐입니다.

interface MutableRefObject<T> {
  current: T;
}

interface RefObject<T> {
  readonly current: T | null;
}

RefObject는 DOM에 ref를 걸어줄 때 사용됩니다. 그러므로 우리가 이 RefObject를 사용하려면 null 값을 넣어줘야하는 것입니다.

const inputRef = useRef<HTMLInputElement>(null); // RefObject

useRef에 DOM이 아닌 일반 변수값을 지정하고 싶을 때에는 초기값을 명확히 넣어주거나, undefined으로 할당하면 됩니다.

const numberRef = useRef<number>(0); // MutableRefObject
const timerRef = useRef<NodeJS.Timeout>(); // MutableRefObject

이처럼 함수 오버로딩을 이해하면, 라이브러리 제작자의 의도를 파악하고, 함수를 적재적소에 잘 사용할 수 있습니다.

다음은 직접 함수 오버로딩을 활용해본 경험을 공유하겠습니다.

함수 오버로드로 undefined 또는 null을 제거하기

가상의 함수를 하나 정의해보겠습니다. 쿠폰 리스트를 받아서, 보낸 쿠폰만 필터링해서 반환하는 함수입니다.

interface Coupon {
  isSent: boolean;
}

function filterSentCoupon(coupons: Coupon[] | undefined): Coupon[] | undefined {
  return coupons?.filter(coupon => coupon.isSent);
}

이 함수가 실현될 수 있는 케이스는 몇 가지 일까요? 인자 타입 2가지와 리턴 타입 2가지를 조합하면 4가지 경우로 실현될 수 있습니다.

하지만 실제로 이 함수는 2가지 케이스에 사용됩니다.

Coupon[] | undefined 이 들어오면, Coupon[] | undefined를 반환한다.
Coupon[] 이 들어오면 Coupon[] 을 반환한다.

지금은 (2)의 경우에도 undefined일 가능성도 포함하여 반환합니다. 타입 내로잉이 얼마나 까다롭고 성가신 작업인데, Coupon[]을 넣었더니 undefined를 더해서 뱉어주다니, 이는 여간 나쁜 타이핑이 아닙니다.

저희는 이를 함수 오버로드로 통해 해결했습니다.

function filterSentCoupon(coupons: Coupon[]): Coupon[];
function filterSentCoupon(coupons: Coupon[] | undefined): Coupon[] | undefined;
function filterSentCoupon(coupons: Coupon[] | undefined): Coupon[] | undefined {
  return coupons?.filter(coupon => coupon.isSent);
}

이제 Coupon[] 타입만 인자로 들어갈 경우, undefined을 더해서 뱉어주는 일이 없을 것입니다.

마치며

함수 오버로딩은 제네릭이나 구별된 유니온에 비해 덜 주목 받는 것 같습니다. 함수의 타입을 제대로 정의하기 위해, 제네릭, 구별된 유니온 뿐만 아니라 함수 오버로딩도 필수적으로 이해해야 합니다. 이번 아티클을 통해, 라이브러리의 .d.ts 코드를 더 수월하게 읽고, 함수 타입을 좁혀나갈 수 있길 바랍니다.

참고

https://www.typescriptlang.org/docs/handbook/2/functions.html#function-overloads

Spring에서 Server-Sent-Events 구현하기

Tue, 11 Oct 2022 12:00:00 GMT

웹 애플리케이션을 개발하다보면 클라이언트의 요청이 없어도 서버에서 데이터를 전달해줘야 하는 경우가 있습니다.

대표적으로 뉴스피드나 댓글 알림처럼 실시간으로 서버의 변경사항을 웹 브라우저에 갱신해줘야 하는 경우를 예로 들 수 있을 것 같습니다.

제가 참여한 프로젝트에서도 이와 비슷한 요구사항이 있었습니다.

아래처럼 다른 클라이언트의 요청(체크리스트 버튼 클릭)으로 발생한 변경 사항을 해당 화면을 보고 있는 모든 클라이언트에게 전달해주어야 했는데요.

전통적인 Client-Server 모델의 HTTP 통신에서는 이런 기능을 구현하기가 조금 난감합니다. 클라이언트의 요청이 있어야만 서버가 응답을 할 수 있기 때문이죠.

HTTP를 기반으로 이 문제를 해결하려면 세 가지 방법을 고려해볼 수 있습니다.

Short Polling

클라이언트가 주기적으로 서버로 요청을 보내는 방법입니다. 일정 시간마다 서버에 요청을 보내 데이터가 갱신되었는지 확인하고 만약 갱신되었다면 데이터를 응답 받습니다.

클라이언트와 서버 모두 구현이 단순하다는 것이 특징입니다. 서버가 요청에 대한 부담이 크지 않고 요청 주기를 넉넉하게 잡아도 될 정도로 실시간성이 중요하지 않다면 고려해 볼 만한 방법입니다.

Long Polling

요청을 보내고 서버에서 변경이 일어날 때까지 대기하는 방법입니다.

실시간 메시지 전달이 중요하지만 서버의 상태가 빈번하게 변하지 않는 경우에 적합합니다. 서버로부터 응답을 받고 나면 다시 연결 요청을 하기 때문에, 상태가 빈번하게 바뀐다면 연결 요청도 늘어나게 됩니다.

Server-Sent Events(SSE)

서버와 한번 연결을 맺고나면 일정 시간동안 서버에서 변경이 발생할 때마다 데이터를 전송받는 방법입니다.

응답마다 다시 요청을 해야하는 Long polling 방식보다 효율적입니다(상황에 따라 달라질 수 있습니다). SSE는 서버에서 클라이언트로 text message를 보내는 브라우저 기반 웹 애플리케이션 기술이며 HTTP의 persistent connections을 기반으로하는 HTML5 표준 기술입니다.

이 외에도 웹소켓을 이용해 서버와 양방향 통신을 하는 방법이 있습니다. 서비스 상황에 맞게 적절한 방법을 선택하면 됩니다.

저희 팀은 구현이 간단한 short polling으로 해당 기능을 구현했었습니다. 하지만 사용자에게 높은 실시간성을 제공하기 위해 0.1초마다 서버에 요청을 보내다보니 서버에도 부담이 크고, 변경 사항이 없는데도 DOM을 계속 교체해야 하는 문제가 있었습니다. 이를 해결하기 위해 SSE로 구현을 변경하기로 결정했습니다.

서비스 특성 상 SSE보다는 WebSocket이 더 적절하다는 의견도 있었으나, 지금 당장은 새로운 라이브러리 추가나 프로토콜 학습 없이 바로 적용할 수 있는 SSE를 적용하기로 했습니다.

SSE 통신 개요

SSE를 이용하는 통신의 개요는 다음과 같습니다.

Client: SSE Subscribe 요청

우선 클라이언트에서 서버의 이벤트를 구독하기 위한 요청을 보내야합니다.

GET /connect HTTP/1.1
Accept: text/event-stream
Cache-Control: no-cache

이벤트의 미디어 타입은 text/event-stream이 표준으로 정해져있습니다. 이벤트는 캐싱하지 않으며 지속적 연결을 사용해야합니다(HTTP 1.1에서는 기본적으로 지속 연결을 사용합니다).

Server: Subscription에 대한 응답

HTTP/1.1 200
Content-Type: text/event-stream;charset=UTF-8
Transfer-Encoding: chunked

응답의 미디어 타입은 text/event-stream 입니다. 이때 Transfer-Encoding 헤더의 값을 chuncked로 설정합니다. 서버는 동적으로 생성된 컨텐츠를 스트리밍하기 때문에 본문의 크기를 미리 알 수 없기 때문입니다.

Server: 이벤트 전달

클라이언트에서 subscribe를 하고나면 서버는 해당 클라이언트에게 비동기적으로 데이터를 전송할 수 있습니다. 이때 데이터는 UTF-8로 인코딩된 텍스트 데이터만 가능합니다(바이너리 데이터는 전송 불가능).

서로 다른 이벤트는 줄바꿈 문자 두개(\n\n)로 구분되며 각각의 이벤트는 한 개 이상의 name: value 필드로 구성되며 이들은 줄바꿈 문자 하나로 구분됩니다.

event: type1
data: An event of type1.

event: type2
data: An event of type2.

코드로 살펴봅시다

사용된 예시 코드는 여기서 확인하실 수 있습니다.

기본적인 흐름을 먼저 설명하면 다음과 같습니다.

클라이언트에서 SSE 연결 요청을 보낸다.
서버에서는 클라이언트와 매핑되는 SSE 통신 객체를 만든다.
서버에서 이벤트가 발생하면 해당 객체를 통해 클라이언트로 데이터를 전달한다.

그림으로 보면 다음과 같습니다.

우선 클라이언트에서는 EventSource라는 인터페이스로 SSE 연결 요청을 할 수 있습니다.

const sse = new EventSource("http://localhost:8080/connect");

spring framework 4.2부터 SSE 통신을 지원하는 SseEmitter API를 제공합니다. 이를 이용해 SSE 구독 요청에 대한 응답을 할 수 있습니다.

import java.io.IOException;  
import lombok.extern.slf4j.Slf4j;  
import org.springframework.http.MediaType;  
import org.springframework.http.ResponseEntity;  
import org.springframework.web.bind.annotation.GetMapping;  
import org.springframework.web.bind.annotation.RestController;  
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;  
  
@RestController  
@Slf4j  
public class SseController {  
  
    private final SseEmitters sseEmitters;  
  
    public SseController(SseEmitters sseEmitters) {  
        this.sseEmitters = sseEmitters;  
    }  
  
    @GetMapping(value = "/connect", produces = MediaType.TEXT_EVENT_STREAM_VALUE)  
    public ResponseEntity<SseEmitter> connect() {  
        SseEmitter emitter = new SseEmitter();  
        sseEmitters.add(emitter);
        try {  
            emitter.send(SseEmitter.event()  
                    .name("connect")  
                    .data("connected!"));  
        } catch (IOException e) {  
            throw new RuntimeException(e);  
        }  
        return ResponseEntity.ok(emitter);  
    }  
}

생성자를 통해 만료시간을 설정할 수 있습니다. 디폴트 값은 서버에 따라 다릅니다. 스프링 부트의 내장 톰캣을 사용하면 30초로 설정됩니다. 만료시간이 되면 브라우저에서 자동으로 서버에 재연결 요청을 보냅니다.

SseEmitter emitter = new SseEmitter(60 * 1000L);

이때 생성된 SseEmitter 객체는 향후 이벤트가 발생했을 때, 해당 클라이언트로 이벤트를 전송하기 위해 사용되므로 서버에서 저장하고 있어야 합니다.

sseEmitters.add(emitter);

주의해야할 점은 Emitter를 생성하고 나서 만료 시간까지 아무런 데이터도 보내지 않으면 재연결 요청시 503 Service Unavailable 에러가 발생할 수 있습니다. 따라서 처음 SSE 연결 시 더미 데이터를 전달해주는 것이 안전합니다.

emitter.send(SseEmitter.event()  
        .name("connect")         // 해당 이벤트의 이름 지정
        .data("connected!"));    // 503 에러 방지를 위한 더미 데이터

이벤트 이름을 설정해주면 클라이언트에서 해당 이름으로 이벤트를 받을 수 있습니다.


const sse = new EventSource("http://localhost:8080/connect");

sse.addEventListener('connect', (e) => {
	const { data: receivedConnectData } = e;
	console.log('connect event data: ',receivedConnectData);  // "connected!"
});

SseEmitter를 생성할 때는 비동기 요청이 완료되거나 타임아웃 발생 시 실행할 콜백을 등록할 수 있습니다. 타임아웃이 발생하면 브라우저에서 재연결 요청을 보내는데, 이때 새로운 Emitter 객체를 다시 생성하기 때문에(SseController의 connect()메서드 참조) 기존의 Emitter를 제거해주어야 합니다. 따라서 onCompletion 콜백에서 자기 자신을 지우도록 등록합니다.

@Component  
@Slf4j  
public class SseEmitters {  
  
    private final List<SseEmitter> emitters = new CopyOnWriteArrayList<>();  
  
    SseEmitter add(SseEmitter emitter) {  
        this.emitters.add(emitter);  
        log.info("new emitter added: {}", emitter);  
        log.info("emitter list size: {}", emitters.size());  
        emitter.onCompletion(() -> {  
            log.info("onCompletion callback");  
            this.emitters.remove(emitter);    // 만료되면 리스트에서 삭제
        });  
        emitter.onTimeout(() -> {  
            log.info("onTimeout callback");  
            emitter.complete();  
        });  
  
        return emitter;  
    }  
}

주의할 점은 이 콜백이 SseEmitter를 관리하는 다른 스레드에서 실행된다는 것입니다. 따라서 thread-safe한 자료구조를 사용하지 않으면 ConcurrnetModificationException이 발생할 수 있습니다. 여기서는 thread-safe한 자료구조인 CopyOnWriteArrayList를 사용하였습니다.

이제 서버에서 무언가 변경 사항이 생겼을 때, 클라이언트의 요청이 없어도 데이터를 전송할 수 있습니다. 본 예시에서는 누군가 /count를 호출하면 서버에 저장된 숫자를 1 증가시키고 이를 SSE 커넥션이 열려있는 모든 클라이언트에게 전달하도록 해보겠습니다.

@RestController  
@Slf4j  
public class SseController {  
  
    private final SseEmitters sseEmitters;  
  
    public SseController(SseEmitters sseEmitters) {  
        this.sseEmitters = sseEmitters;  
    }  

	// ...
  
    @PostMapping("/count")  
    public ResponseEntity<Void> count() {  
        sseEmitters.count();  
        return ResponseEntity.ok().build();  
    }  
}

@Component  
@Slf4j  
public class SseEmitters {  
  
    private static final AtomicLong counter = new AtomicLong();  
  
    private final List<SseEmitter> emitters = new CopyOnWriteArrayList<>();  
  
	// ...
	
    public void count() {  
        long count = counter.incrementAndGet();  
        emitters.forEach(emitter -> {  
            try {  
                emitter.send(SseEmitter.event()  
                        .name("count")  
                        .data(count));  
            } catch (IOException e) {  
                throw new RuntimeException(e);  
            }  
        });  
    }  
}

클라이언트에서는 `count`라는 이름의 이벤트가 발생할 때 콘솔에 변경된 데이터를 출력하도록 이벤트 리스너를 등록해둡니다.

sse.addEventListener('count', e => {  
    const { data: receivedCount } = e;  
    console.log("count event data",receivedCount);  
    setCount(receivedCount);  
});

이제 만약 다른 브라우저에서 count를 호출한다면 내 브라우저에 서버에서 변경된 값이 찍히게 됩니다.

주의점

스프링에서도 API를 지원해주고 있기 때문에 SSE 통신을 구현하는 것 자체는 굉장히 쉽습니다. 하지만 기능을 구현하고 서비스에 배포하기까지 여러 어려움들을 겪었는데요, SSE 통신을 구현하면서 진행한 트러블슈팅을 공유하면서 글을 마치도록 하겠습니다.

503 Service Unavailable

위에서 언급했듯이 처음에 SSE 응답을 할 때 아무런 이벤트도 보내지 않으면 재연결 요청을 보낼때나, 아니면 연결 요청 자체에서 오류가 발생합니다.

따라서 첫 SSE 응답을 보낼 시에는 반드시 더미 데이터라도 넣어서 데이터를 전달해야합니다.

헤더에 토큰 전달

SSE 연결 요청을 할 때 헤더에 JWT를 담아서 보내줘야했는데, EventSource 인터페이스는 기본적으로 헤더 전달을 지원하지 않는 문제가 있었습니다. event-source-polyfill 을 사용하면 헤더를 함께 보낼 수 있습니다.

JPA 사용시 Connection 고갈 문제

SSE 통신을 하는 동안은 HTTP Connection이 계속 열려있습니다. 만약 SSE 연결 응답 API에서 JPA를 사용하고 open-in-view 속성을 true로 설정했다면, HTTP Connection이 열려있는 동안 DB Connection도 같이 열려있게 됩니다.

즉 DB Connection Pool에서 최대 10개의 Connection을 사용할 수 있다면, 10명의 클라이언트가 SSE 연결 요청을 하는 순간 DB 커넥션도 고갈되게 됩니다. 따라서 이 경우 open-in-view 설정을 반드시 false로 설정해야 합니다.

ConcurrentModificationException

마찬가지로 위에서 언급했듯이, onCompletion, onTimeout 콜백은 별도의 스레드에서 호출됩니다. 만약 이 콜백을 통해 SseEmitter 객체가 담긴 컬렉션에 연산을 한다면 해당 컬렉션은 thread-safe한 자료구조를 사용해야합니다. 처음에 그냥 ArrayList를 사용했다가 SseEmitter가 만료될 때마다 ConcurrentModificationException이 발생하는 문제를 겪었었습니다.

Nginx 사용시 주의할 점

로컬에서 잘 동작하는 것을 확인하고 배포를 했더니 SSE 통신이 동작하지 않는 문제가 발생했었습니다.

저희 팀은 리버스 프록시로 Nginx를 사용하고 있었는데요

원인을 찾아보던 중 Nginx는 기본적으로 Upstream으로 요청을 보낼때 HTTP/1.0 버전을 사용한다는 것을 확인했습니다.

HTTP/1.1은 지속 연결이 기본이기 때문에 헤더를 따로 설정해줄 필요가 없지만, Nginx에서 백엔드 WAS로 요청을 보낼 때는 HTTP/1.0을 사용하고 Connection: close 헤더를 사용하게 됩니다.

SSE는 지속 연결이 되어 있어야 동작하는데 Nginx에서 지속 연결을 닫아버려 제대로 동작하지 않았습니다.

따라서 아래와 같이 nginx 설정을 추가해야 제대로 동작합니다.

proxy_set_header Connection '';
proxy_http_version 1.1;

또 Nginx의 proxy buffering 기능도 조심해야 하는데요, SSE 통신에서 서버는 기본적으로 응답에 Transfer-Encoding: chunked를 사용합니다. SSE는 서버에서 동적으로 생성된 컨텐츠를 스트리밍하기 때문에 본문의 크기를 미리 알 수 없기 때문입니다.

Nginx는 서버의 응답을 버퍼에 저장해두었다가 버퍼가 차거나 서버가 응답 데이터를 모두 보내면 클라이언트로 전송하게 됩니다.

참고: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

문제는 버퍼링 기능을 활성화하면 SSE 통신 시 원하는대로 동작하지 않거나 실시간성이 떨어지게 된다는 것입니다. 따라서 SSE 응답에 대해서는 proxy buffering 설정을 비활성화 해주는 것이 좋습니다.

하지만 Nginx의 설정 파일에서 버퍼링을 비활성화하면 다른 모든 API 응답에 대해서도 버퍼링을 하지 않기 때문에 비효율적일 수 있습니다. 이때 nginx의 X-accel 기능을 활용하면 좋습니다.

백엔드의 응답 헤더에 X-accel로 시작하는 헤더가 있으면 Nginx가 이 정보를 이용해 내부적인 처리를 따로 하도록 만들 수 있습니다. 따라서 SSE 응답을 반환하는 API의 헤더에 X-Accel-Buffering: no를 붙여주면 SSE 응답만 버퍼링을 하지 않도록 설정할 수 있습니다.

스케일 아웃 시 문제

SseEmitter 객체는 서버의 메모리에 저장되어 있습니다. 따라서 서버 인스턴스를 늘리는 경우 기능이 제대로 동작하지 않습니다.

이런 경우 Redis Pub/Sub같은 메시지 브로커나 분산 캐시를 통해 문제를 해결할 수 있습니다.

마무리

Server-Sent Events는 HTTP를 기반으로 동작하기 때문에 특별한 라이브러리나 프로토콜 추가 없이 빠르게 도입할 수 있다는 장점이 있습니다. 또한 서버에서 클라이언트로의 단방향 통신만 가능하기 때문에 클라이언트의 상호작용 없이 서버로부터 데이터가 전달되어야 하는 상황에 적합합니다. 대표적으로 스포츠 중계 서비스나 SNS 피드 같은 성격의 서비스에서 사용을 고려해볼 수 있습니다.

참고자료

테스트 자동화 라이브러리 개발기

Tue, 11 Oct 2022 12:00:00 GMT

cypress-ci는 Cypress 테스트 자동화 라이브러리로, CI Provider에서 서버 실행과 테스트 실행을 자동화하기 위한 여러가지 기능을 지원하고 있습니다.

개발 배경

체크메이트 팀에서는 Jenkins와 Cypress로 빌드 전 E2E 테스트를 하고 있습니다. 그러나 기존 테스트 자동화 코드가 Shell Script로 짜여져 있어 Cypress의 모듈 API를 사용할 수 없어 멀티 리포트를 직접 구현하기 위해 라이브러리를 개발하게 되었습니다.

기존 스크립트

요구사항

라이브러리 개발 시 다음과 같은 요구사항이 있었습니다.

Node.js, TypeScript로 개발
기존 Jenkins 머신에 빠른 적용을 위한 non-docker 셋업
기존 Cypress configuration 파일을 읽어와 필요한 부분만 확장하여 적용할 수 있어야 함
서버 시작 후 통신 가능한 상태가 되면 테스트 실행
테스트 실패 혹은 에러 발생 시 빌드 실패 판정
멀티 리포트 (콘솔 출력 + 파일 출력)
Graceful shutdown

non-docker 셋업

Cypress는 headless 브라우저 테스트를 지원합니다. Headless 브라우저란 GUI 없이 백그라운드에서 실행되는 브라우저를 말합니다. CI에서는 렌더링을 하지 않아 얻는 성능상의 이점, 머신의 GPU 미지원 등의 이유로 headless 테스트가 필수적입니다.

Headless 브라우저 테스트

Cypress는 headless 브라우저 테스트를 위해 여러가지 의존성을 요구합니다. 그 중 하나로 가상 메모리에서 그래픽 작업을 수행하는 in-memory 디스플레이 서버인 XVFB가 있습니다. Cypress는 Cypress, OS, 브라우저 별 docker 이미지를 지원하지만 이를 사용하지 않는 경우 공식 문서에서 필요로 하는 의존성을 설치할 수 있게 스크립트를 제공하고 있습니다.

기존 Cypress configuration 파일 사용

Cypress는 configuration 파일 확장자로 json(구버전에서 사용), js, ts을 지원합니다. 체크메이트 프론트엔드는 타입스크립트로 개발하고 있어 ts 파일로 설정 파일을 관리하고 있습니다. 그런데 빌드된 js 파일에서는 ts 파일을 불러올 수 없었습니다. 이를 위해 ts-import 라이브러리를 사용했습니다. ts-import는 node_modules 내 자신의 캐시 디렉토리에 컴파일한 js를 저장하여 js에서 ts를 import할 수 있게 합니다.

Polling

처음에는 서버와 테스트 모두 동시에 시작하여 Promise.race를 통해 관리하는 방법을 사용했습니다. 하지만 서버와 Cypress의 콘솔 출력이 섞이고 서버 실행이 늦어지면 Cypress의 테스트가 timeout되는 문제가 있었습니다. 콘솔 출력이 순서대로 출력되게 하기 위해 서버가 통신 가능한 상태가 가능한지 알아낼 필요가 있었습니다.

서버 및 테스트 실행 시퀀스

서버는 다른 프로세스에서 실행되기 때문에 Node.js적인 방법 대신 시스템 계층에서 접근해야 했습니다. 체크메이트에서는 일정한 간격으로 서버에 HTML GET 요청을 보내 응답(상태 코드 200~206, 304)을 검사하는 방식을 선택했습니다. 이를 위해 CLI argument로 GET 요청을 보낼 url과 timeout 시간을 입력받도록 했습니다.

Graceful shutdown

Graceful shutdown은 작업을 모두 처리한 후 종료되도록 하는 것을 말합니다. 서버 프로세스의 경우 다른 프로세스에서 실행되기 때문에, 테스트 종료 후 혹은 어떤 에러 발생 시 종료하게끔 시그널을 보내야했습니다. 이를 위해 SIGTERM을 보내 서버를 종료시켰습니다. CI가 아닌 로컬 머신에서 사용할 경우 서버를 종료하기 위해 Ctrl-C로 인터럽트할 필요가 없는 장점도 있습니다.

더 이상의 Ctrl-C는 없다

CLI

CLI를 위한 라이브러리로는 commander를 사용했습니다. commander는 옵션, 기본값, 도움말, 버전 등의 argument를 파싱해 쉽고 빠르게 CLI 프로그램을 만들 수 있게 도와주는 Node.js 라이브러리입니다. 다음과 같은 형태로 사용할 수 있습니다.

import { program } from 'commander';

program
  .option('-s, --serve <serve>', 'script to run server', 'start')
  .option('-u, --url <url>', 'url to test', 'http://localhost:3000')
  .option('-t, --timeout <timeout>', 'maximum time in ms to wait for a server response', '60000')
  .version('0.2.6')
  .parse();

-s로 입력받는 서버 시작 명령어는 npm 스크립트의 경우 npm run을 생략할 수 있게끔 정규화를 거치도록 했습니다. 이를 위해 process 객체의 cwd 함수로 현재 Node 프로세스가 동작하는 디렉토리를 찾아 package.json을 임포트해 scripts 객체에서 해당 명령어가 있는지 검사하여 있다면 npm run을 추가했습니다.


cypress-ci -s start
cypress-ci -s "npm run start" # normalized

마치며

라이브러리 개발이 불필요했다는 생각도 듭니다. 특히 기존 Jenkins 머신에 바로 올리기 위해 non-docker 셋업으로 구현했지만 결국 docker의 편리함을 더 느꼈습니다. 서버와 테스트 자동 실행은 start-server-and-test 라이브러리와 기능에서 큰 차이가 없고 해당 라이브러리의 경우 테스트 실행 명령어를 인자로 받아 테스트 라이브러리에 의존적이지 않은 장점이 있습니다. 만들며 Node.js, 프로세스, npm 등에 대해 많은 공부가 되었고 멀티 리포트가 가능해졌다는 것에 의의를 두고자 합니다. 본 라이브러리는 다음 링크에서 확인하실 수 있습니다.

https://github.com/greenblues1190/cypress-ci

참고

좋아요 개수 조회 최적화하기

Mon, 10 Oct 2022 13:10:00 GMT

속닥속닥 프로젝트(https://github.com/woowacourse-teams/2022-sokdak)를 진행하면서 현재는 문제가 되지 않지만 시간이 갈수록 데이터가 쌓이면서 문제가 될 수도 있겠다라고 생각한 부분이 있습니다. 게시글에 대한 ‘좋아요’ 기능인데요, 현재 구조에서는 게시글을 조회할 때, ‘좋아요’ 테이블과 함께 조인을 해서 가져오고 있습니다. 단순히 좋아요 개수만 저장하지 않는 이유는, 한번 좋아요 버튼을 누른 사람은 두 번째 누를 때 취소할 수 있어야 하기 때문입니다.

하지만 이런 방식이라면 만약 게시글 하나에 좋아요가 100만개가 된다면 게시글을 조회 한번 할때마다 100만개를 조인하게되어 오버헤드가 커지게 됩니다. 실제로 유튜브, 인스타의 경우 좋아요 개수가 100만개를 훌쩍 넘는 경우가 많은데요, 어떻게 이런 문제를 처리할 수 있는지 궁금했습니다. 현재 속닥속닥에는 ‘좋아요’ 개수가 딱 정확하게 나와야 하는 비즈니스적 요구 사항은 없지만, 게시글의 성격에 따라 충분히 발생할 수 있는 요구사항이라고 생각했습니다.

실제로 저희가 테스트를 해본 결과 게시글의 좋아요 개수를 조회하는데에만 0.68초가 걸렸습니다.

그래서 저희는 반정규화를 선택했습니다. post 테이블에 like_count 컬럼을 추가함으로서 likes 테이블을 조인하지 않고도 해당 게시글의 좋아요 개수를 알 수 있습니다. 이렇게 해서 해당 게시글의 좋아요 개수를 가져오는데 시간을 0.0013으로 줄일 수 있었습니다.

하지만 이렇게 되면 좋아요 개수에 대한 정보가 두 테이블에 나타나게 되어 데이터 정합성을 맞추는 것이 중요한 문제가 됩니다. 데이터 정합성이 안맞는다는 말에 대해 풀어보자면, 좋아요를 누를때는 like 테이블에서 삽입, 삭제가 일어나게 되는데, post 테이블의 like_count 에 대해서도 수정을 해주어야 됩니다. 한 가지 데이터에 대해, 두 테이블에서 수정이 이루어지니 데이터가 맞지 않을수도 있게 됩니다.

예를 들어 A 사용자가 좋아요를 누른다면, likes 테이블에 삽입을 해주고, post 테이블의 like_count에 기존 like_count + 1을 해줍니다. 그런데, 이 트랜잭션이 커밋되기 전에 B 사용자가 좋아요를 누른다면, 변화된 like_count 에 + 1 을 해주는 것이 아니라, 커밋되기 전 상태의 like_count에 + 1 을 해주어 데이터가 맞지 않게 되는 것입니다. 다시 말해, 좋아요가 0개인 상태에서 2명이 좋아요를 눌렀으므로 2개가 되어야 하는데, 1 개가 되는 것입니다. 이를 갱신 분실(Lost Update)라고 합니다.

화면 왼쪽은 A 트랜잭션, 오른쪽은 B 트랜잭션입니다. 자바 코드로 예시를 작성할 수도 있지만 보다 직관적으로 트랜잭션의 흐름을 보기 위해 MySQL 쿼리로 예시를 만들어봤습니다. 이 트랜잭션은 좋아요 개수를 조회하고, 좋아요의 개수를 1 증가하는 쿼리입니다. 처음 post의 like_count에는 1,000,001개의 데이터가 있었으므로 두 트랜잭션이 정상적으로 실행됐으면 1,000,003개가 되어야합니다. 하지만 A 트랜잭션에서 4번째 줄까지 실행하고 B 트랜잭션이 나머지를 실행하면 like_count는 1,000,002개로 하나의 write 요청이 다른 요청에 의해 덮어쓰여진 것을 알 수 있습니다.

1. Lock

첫번째로 락을 거는 방법을 생각했습니다. 조회 쿼리에 락을 걸어 데이터 정합성을 맞추는 것이죠. A 트랜잭션이 like_count 를 변경하는 업데이트 작업을 하고 커밋을 할 때 까지 B 트랜잭션은 like_count에 대한 조회에 대한 접근이 불가능합니다. 결과적으로 A 트랜잭션이 커밋 되고 나서 B 트랜잭션은 like_count를 얻기 때문에 정확한 like_count 데이터에서 1을 더하게 되고, 데이터 정합성이 맞게 됩니다. 기존 100,001 개의 좋아요 개수에서 두 트랜잭션이 커밋된 후에 100,003 개가 된 것을 볼 수 있습니다.

하지만, 락을 거는 방법은 서비스의 확장성을 고려했을 때 적절하지 않다고 생각했습니다. 조회에 대한 락을 걸게 되면 트랜잭션이 끝나는 것을 다 기다려야 하기 때문에 성능이 매우 나빠지게 될 것이기 때문입니다.

2. Native Query

두번째 방법은 네이티브 쿼리를 이용해 post 테이블의 like_count 데이터 자체를 읽어 1을 더해주는 것입니다. update 명령어는 그 자체로 atomic 합니다. 따라서 값을 읽고 그 읽은 값을 증가시키는 과정을 분리하지 않고 한번에 업데이트 하도록 하면 동시성 문제를 해결할 수 있습니다.

하지만, 한 트랜잭션이 업데이트를 진행하고 있는 경우에는 다른 트랜잭션에서 해당 row에 대해서는 update 작업을 하지 못합니다. 게시글 수정같이 업데이트가 빈번하지 않은 작업이라면 괜찮겠지만, 좋아요는 클릭 한번으로 수정이 되는 변경이 쉬운 작업입니다. 여러 사용자가 동시에 좋아요를 여러번 누르는 상황이 발생한다면, 서버에 무리가 갈 것이라고 판단되었습니다.

3. Sync Schedule

세번째 방법은 특정 주기마다 좋아요 개수를 맞추어 주는 것입니다. 처음에 문제였던 것이 동시에 사용자 요청이 들어올 때 같은 like_count 를 얻어 좋아요 개수가 맞지 않는다는 것인데, 이렇게 맞지 않았던 데이터를 주기적으로 한번씩 맞추어 주는 것입니다. like_count 는 데이터가 정확하지 않더라도, like 테이블을 통해서 정확한 좋아요 개수를 얻을 수 있기 때문에 가능한 방법입니다. 이 방법을 사용한다면 like_count 에 대한 접근을 할 때 다른 트랜잭션이 커밋되기를 기다리지 않아도 되기 때문에 성능적으로 이점이 있습니다.

그러나 매 주기마다 데이터 정합성이 맞추어 지기는 하지만, 업데이트 주기가 오기 전까지는 데이터가 맞지 않을 수 있기 때문에, 정확한 좋아요 개수를 요구하지 않는 환경에서 사용하기에 좋다고 생각됩니다. 이렇게 시간이 지나서 최종적으로 같은 데이터로 동기화하는 것을 궁극적 일관성(Eventual Consistency)라고 합니다.

실제 인스타나 유튜브를 보면 좋아요 개수가 한 자리 수까지 정확하게 표시되지 않습니다. 일정 크기의 단위로 끊어서 표시하는데요 여기에는 사용자의 편의성을 배려한 이유도 있을 수 있습니다. 실제로 사용자들은 좋아요가 몇 개인지 한 자리 수까지 그렇게 궁금하지 않을 것입니다. 이런 경우라면 sync schedule을 이용해 성능을 최적화 할 수 있을 것입니다.

결론

저희 속닥속닥은 마지막 방법인 Sync schedule 방법을 선택했습니다. 락을 활용한 방법과 네이티브 쿼리를 사용한 방법은 성능적으로 문제가 발생할 것으로 판단되었기 때문입니다. Sync Schedule 방법은 업데이트 주기가 오기 전에는 데이터의 정합성이 맞지 않아 사용자에게 좋아요 개수가 부정확하게 표시될 수 있습니다. 하지만, 속닥속닥은 좋아요 개수가 일시적으로 부정확하게 표기 되더라도 큰 문제가 되지 않는다고 생각했습니다.

속닥속닥은 Sync Schedule 방법을 선택했지만, 이 방법이 정답인 것은 아닙니다. 상황에 따라 적합한 방법을 택하는 것이 좋은 서비스를 만드는 길이라 생각합니다.

참고 및 출처

https://en.wikipedia.org/wiki/Concurrency_control

https://en.wikipedia.org/wiki/Eventual_consistency

서비스 추상화

Mon, 10 Oct 2022 12:00:00 GMT

😘 서론

우아한테크코스에서 사용하는 협업 도구 중 하나인 Slack은 무료 프리티어 사용 시 3개월이 지난 메시지들을 보여주지 않습니다. 레벨 3 팀 프로젝트인 줍줍에서는 이 사라지는 메시지들을 백업해주는 서비스를 제공합니다. Slack의 메시지에 대한 정보를 주로 다루다 보니 Slack 라이브러리에 의존적인 로직이 많습니다. 이 포스팅에서는 외부 라이브러리(Slack 라이브러리)를 사용하는 로직을 어떻게, 왜 추상화했는지에 관해 이야기하려고 합니다.

🤔 왜 서비스를 추상화해야 하는가?

기존의 테스트에서는 Slack 라이브러리를 호출하는 부분은 모킹 처리해두었습니다. 테스트 코드를 리팩토링하다 보니 모킹 작업이 계속 반복되는 지루한 작업으로 느껴졌습니다. 반복되는 모킹 작업을 제거하기 위해 테스트 방식을 목에서 스텁으로 변경해야겠다는 결심을 하게 되었습니다. (테스트에 대한 이야기는 2기_스티치의 Test Double을 알아보자를 참고 바랍니다.)

Slack 라이브러리의 스텁용 객체를 만들기 위해서는 MethodsClient라는 인터페이스를 구현해야 합니다. 해당 인터페이스는 약 250개의 메서드를 갖고 있으며 그중 저희 서비스에서 실제로 사용하는 메서드는 약 10개 정도에 불과합니다. 이를 모두 구현하는 것은 불필요하고 번거로운 작업이기에 더 간편한 방법을 고민하게 되었습니다. 이때 떠오른 방법이 서비스를 추상화해 필요한 부분만 사용하도록 만드는 것이었습니다. 자세한 설명은 아래 예제 코드를 보며 살펴보겠습니다.

😆 예제 코드

0. 기존 코드

예제로 채널을 생성하는 ChannelCreateService의 기존 로직을 가져와 보았습니다. 로직 대부분이 Slack 라이브러리에 의존하고 있습니다.


@Transactional
@Service
public class ChannelCreatedService {

  private MethodsClient slackClient;
  private ChannelRepository channels;

  public ChannelCreatedService(final MethodsClient slackClient, final ChannelRepository channels) {
    this.slackClient = slackClient;
    this.channels = channels;
  }

  public Channel execute(final String channelSlackId) {
    try {
      // slack api를 호출하는 부분
      Conversation conversation = slackClient
        .conversationsInfo(request -> request.channel(channelSlackId))
        .getChannel();

      // slack의 response를 우리 도메인인 channel 형태로 변환
      Channel channel = toChannel(conversation);

      // channel을 저장하고 return
      return channels.save(channel);

    } catch (IOException | SlackApiException e) { // slack api 호출로 인해 발생할 수 있는 exception
      throw new SlackApiCallException();
    }
  }
}

1. 외부 라이브러리를 쓰는 로직 추상화

위 로직을 아래처럼 두 개의 클래스로 분리하여 역할을 나눠주었습니다.

ChannelCreateService

채널 저장 로직을 가진 클래스


@Transactional
@Service
public class ChannelCreatedService {

  private CallSlackApi slackClient;
  private ChannelRepository channels;

  public ChannelCreatedService(final CallSlackApi slackClient, final ChannelRepository channels) {
    this.slackClient = slackClient;
    this.channels = channels;
  }

  public Channel execute(final String channelSlackId) {
    Channel channel = slackClient.callChannel(channelSlackId);
    return channels.save(channel);
  }
}

CallSlackApi

Slack 라이브러리를 호출하고 결괏값을 반환하는 클래스


@Component
public class CallSlackApi {

  private final MethodsClient methodsClient;

  public CallSlackApi(final MethodsClient methodsClient) {
    this.methodsClient = methodsClient;
  }

  public Channel callChannel(final String channelSlackId) {
    try {
      // `Slack 라이브러리`를 호출
      Conversation conversation = methodsClient.conversationsInfo(
          request -> request.channel(channelSlackId))
        .getChannel();

      // 결과값을 우리가 사용하는 객체 형태로 변경
      return new Channel(conversation.getId(), conversation.getName());

    } catch (IOException | SlackApiException e) {
      throw new SlackApiCallException();
    }
  }
}

2. 추상화한 로직 인터페이스로 분리

좀 더 편리한 스텁 객체를 만들기 위해 ExternalClient라는 인터페이스를 만들었습니다. 기존의 CallSlackApi에 존재하던 로직은 ExternalClient 인터페이스의 구현체인 SlackClient로 옮겼습니다.

ExternalClient

외부 라이브러리의 로직을 추상화한 인터페이스

public interface ExternalClient {
  Channel callChannel(String channelSlackId);
}

SlackClient

Slack 라이브러리를 호출하는 ExternalClient의 구현체


@Component
public class SlackClient implements ExternalClient {

  private MethodsClient methodsClient;

  public SlackClient(final MethodsClient methodsClient) {
    this.methodsClient = slackClient;
  }

  public Channel callChannel(final String channelSlackId) {
    try {
      Conversation conversation = methodsClient.conversationsInfo(
          request -> request.channel(channelSlackId))
        .getChannel();

      return new Channel(conversation.getId(), conversation.getName());

    } catch (IOException | SlackApiException e) {
      throw new SlackApiCallException();
    }
  }
}

3. 스텁용 객체 생성 및 적용

스텁용 객체를 생성한 뒤 @Component를 이용해 bean으로 등록하였습니다.


@Primary // SlackClient 보다 우선 순위가 높은 bean으로 등록하기 위해 붙였다.
@Component
public class FakeClient implements ExternalClient {

  private List<Channel> channels = List.of( ...); // 채널 데이터 초기화

  @Override
  public Channel callChannel(final String channelSlackId) {
    return channels.stream()
      .filter(it -> it.isSameSlackId(channelSlackId))
      .findAny()
      .orElseThrow(() -> new SlackApiCallException());
  }
}

4. 테스트 코드에서 모킹 제거

스텁을 적용하였으니 이제 모킹한 코드들을 제거해주는 일만 남았습니다. 전후 코드를 비교하여 코드가 얼마나 깔끔해졌는지 확인해보겠습니다.

AS-IS (목 적용)


@Test
void execute() {
  // given
  Workspace workspace = workspaces.save(WorkspaceFixture.JUPJUP.create());
  Channel channel = ChannelFixture.QNA.create(workspace);
  String request = createRequest(channel);

  given(slackClient.conversationsInfo((RequestConfigurator<ConversationsInfoRequestBuilder>) any()))
    .willReturn(setUpChannelMockData(channel));

  // when
  channelCreatedService.execute(request);

  // then
  Optional<Channel> actual = channels.findBySlackId(channel.getSlackId());
  assertThat(actual).isNotEmpty();
}

private ConversationsInfoResponse setUpChannelMockData(final Channel channel) {
  Conversation conversation = new Conversation();
  conversation.setId(channel.getSlackId());
  conversation.setName(channel.getName());

  ConversationsInfoResponse conversationsInfoResponse = new ConversationsInfoResponse();
  conversationsInfoResponse.setChannel(conversation);
  conversationsInfoResponse.setOk(true);

  return conversationsInfoResponse;
}

TO-BE (스텁 적용)


@Test
void execute() {
  // given
  Workspace workspace = workspaces.save(WorkspaceFixture.JUPJUP.create());
  Channel channel = ChannelFixture.QNA.create(workspace);
  String request = createRequest(channel);

  // when
  channelCreatedService.execute(request);

  // then
  Optional<Channel> actual = channels.findBySlackId(channel.getSlackId());
  assertThat(actual).isNotEmpty();
}

😉 마무리

해당 글에서는 테스트를 간편화하기 위해 서비스 추상화를 진행해보았습니다. 서비스 추상화는 이 외에도 다양한 목적으로 진행할 수 있습니다.

객체 지향적인 코드는 단일 책임 원칙을 준수합니다. 기존의 ChannelCreateService에서는 ‘Slack 라이브러리 호출’, ‘예외 처리’, ‘채널 저장’ 3가지 역할을 하고 있었습니다. 개선된 ChannelCreateService에서는 SlackClient를 통해 채널 정보를 가져오고 이를 DB에 ‘저장’하는 역할을 합니다. ‘Slack 라이브러리 호출’과 이로 인한 ‘예외 처리’의 책임은 SlackClient으로 옮겨갔습니다. 이렇듯 서비스를 추상화하면 이전보다 코드가 간결해지고 작업의 목적이 분명하게 드러납니다.

각 오브젝트의 책임과 역할이 더 분명하게 분리되면 변경 사항이 생기는 경우 변경 포인트를 쉽게 찾아낼 수 있습니다. 이제 Slack 라이브러리와 관련된 오류가 발생하면 ChannelCreateService가 아닌 SlackClient를 살피면 됩니다. 의존되는 외부 라이브러리가 Slack이 아닌 카카오톡, 라인 등으로 바뀔 수도 있습니다. 이 경우에도 ExternalClient의 구현체를 생성하면 쉽게 대체할 수 있습니다.

Reference & Source

토비의 스프링 3.1 / 이일민
대표 이미지: 피에트 몬드리안의 추상화 작 브로드웨이 부기우기

Spring Profile: yml 파일 하나로 프로퍼티 관리하기

Tue, 04 Oct 2022 17:00:00 GMT

서비스를 개발하다보면 하나의 서버 애플리케이션을 다양한 환경에서 실행할 일이 생깁니다. 그리고 H2 DB를 사용하는 테스트 환경과 MySQL DB를 사용하는 배포 환경에서 사용되는 환경변수 값이 서로 다른 것은 당연한 일이겠죠.

해당 글에서는 일반적인 스프링 부트 애플리케이션에서 하나의 application.yml 파일을 통해 각 프로파일별로 프로퍼티 설정들을 관리하고, 환경변수를 주입하는 몇 가지 방법에 대해 설명하고자 합니다.

인프라를 다뤄본 경험이 어느 정도 있다는 가정하에서 작성하였습니다.

프로퍼티와 JVM 시스템 파라미터

우선 스프링 애플리케이션이 실행되는 포트 번호를 수정하는 예시를 통해 프로퍼티를 설정하는 방법에 대해 가볍게 알아봅시다.

기본적으로 스프링 부트 애플리케이션을 실행하면 8080 포트에서 톰캣 서버가 디폴트로 실행됩니다.

이때 모종의 이유로 포트번호를 8080 대신 5000 포트로 수정하고 싶다면 main/resources 경로에 application.yml 파일(이하, yml 파일)을 생성하고 아래와 같이 포트 번호를 기재해주면 됩니다.

server.port: 5000

한편 이미 배포된 서버를 다른 포트 번호에서 실행되도록 수정해야 하는 경우도 존재합니다. 이 경우 yml 파일의 값을 수정하고 애플리케이션을 다시 빌드하여 재실행시키는 방법이 있겠죠. 그러나 JVM 시스템 파라미터를 활용하면 이미 빌드된 애플리케이션에 특정 프로퍼티 값을 주입하여 실행하는 것도 가능합니다.

이해를 위해 우선 스프링 부트 애플리케이션을 jar 파일로 빌드하고, 실행시키고, 종료시키는 명령어를 배워봅시다.

# gradle을 사용하여 애플리케이션 빌드
./gradlew build
# 빌드된 .jar 파일이 있는 장소로 이동
cd build/libs
# 빌드된 .jar 파일 실행
java -jar 애플리케이션-0.0.1-SNAPSHOT.jar &
# 특정 포트번호에서 실행되는 프로세스를 종료
kill $(lsof -t -i:포트번호)

위의 명령어를 실행한다면 빌드될 때 포함된 yml 파일에 설정한 server.port 프로퍼티 값을 활용하게 됩니다. 저희의 경우 위에서 설정한 5000 포트가 그대로 활용되겠죠.

그런데 해당 .jar 파일을 실행시키는 명령어에 다음과 같이 -Dserver.port=7000라는 내용을 추가하면 어떻게 될까요?

# -Dkey=value 형식으로 JVM 시스템 파라미터 활용
java -Dserver.port=7000 -jar 애플리케이션-0.0.1-SNAPSHOT.jar &

이 경우 5000 포트에서 실행되던 애플리케이션이 7000 포트에서 실행됩니다. 이는 yml 파일에 포함된 server.port 프로퍼티 값이 7000이라는 값으로 완전히 덮어써진 체 실행되는 것을 의미합니다. yml 파일에 server.port 정보를 기재하지 않은 경우에도 JVM 시스템 파라미터를 통해 프로퍼티 값을 전달한다면 마찬가지로 7000 포트로 실행됩니다.

환경변수의 활용

이번에는 yml 파일의 프로퍼티 값을 전달받아 스프링 애플리케이션 내부에서 사용하는 경우를 다뤄보겠습니다.

다음과 같이 security.jwt.token.secret-key라는 환경변수를 주입받아 사용하는 스프링 빈을 하나 정의해봅시다. security.jwt.token.secret-key는 스프링에서 별도로 존재하는 프로퍼티가 아니라 개발자가 임의로 만든 프로퍼티입니다.

@Component
public class ComponentWithSecretKey {

    private final String secretKey;

    public ComponentWithSecretKey(@Value("${security.jwt.token.secret-key}") String secretKey) {
        this.secretKey = secretKey;
    }
}

이 상태에서 별도의 작업 없이 즉시 애플리케이션을 실행하는 경우, 예외가 발생하며 서버는 즉시 종료합니다.

이때 yml 파일에 다음과 같이 환경변수 값을 추가하고 애플리케이션을 실행하게 되면 애플리케이션은 문제 없이 동작합니다.

security.jwt.token.secret-key: secret_value_that_is_really_long

그런데 개발 과정에서 환경변수를 다룰 때 저희는 다양한 문제 상황에 직면하게 됩니다. 동일한 환경변수에 상황에 따라 다른 값이 주입되어야 하는 경우도 존재할 수 있으며, 이러한 값들을 어떻게 외부로 노출되지 않도록 관리할 것인가에 대해서도 고민해야 합니다. 이러한 문제에 대한 다양한 해결방안 중 가장 관리 포인트를 최소화하는 방안은 스프링 프로파일을 활용하는 것이라고 생각합니다.

스프링 프로파일과 환경변수

이제부터 본격적으로 스프링 프로파일을 활용하여 하나의 yml 파일 내에 다양한 프로퍼티 값들을 관리하는 방법에 대해 알아보도록 하겠습니다.

설명을 위해 yml로부터 두 가지 환경변수를 주입받아 사용하는 스프링 빈을 만들어봅시다.

@Component
public class ComponentWithSecretKey {

    private final String commonData;
    private final String secretKey;

    public ComponentWithSecretKey(@Value("${common.data}") String commonData,
                                  @Value("${security.jwt.token.secret-key}") String secretKey) {
        this.commonData = commonData;
        this.secretKey = secretKey;
    }
}

그리고 yml 파일에 다음과 같이 작성해봅시다.

# 디폴트로 사용하는 프로파일은 test
spring.profiles.active: test
common.data: "모든_프로파일들에서_공통으로_사용되는_데이터"

---
# 현재 프로파일이 prod인 경우, 해당 프로퍼티들을 사용
spring.config.activate.on-profile: prod
security.jwt.token.secret-key: "prod 프로파일일 때 사용되는 secret key"

---
# 현재 프로파일이 test인 경우, 해당 프로퍼티들을 사용
spring.config.activate.on-profile: test
security.jwt.token.secret-key: "test_프로파일일_때_사용되는_secret_key"

설명하자면 ---는 yml 파일 내에서 프로파일 영역별 경계를 설정하는 기능입니다.

특정 영역에 spring.config.activate.on-profile 프로퍼티를 설정하는 경우, 해당 프로파일이 선택되었을 때만 해당 영역의 프로퍼티들이 사용됩니다.

반대로 spring.config.activate.on-profile 프로퍼티가 없는 영역의 프로퍼티들은 활성화된 프로파일과 무관하게 모든 프로파일들에서 공통적으로 사용됩니다. 위의 경우 가독성을 위해 yml 파일의 최상단에 위치시켰으나, 아래쪽에 있어도 동일하게 동작합니다.

그리고 spring.profiles.active는 디폴트로 사용될 프로파일을 명시하는 기능입니다. 해당 값을 명시하지 않는 경우 default 프로파일이 사용되며, JVM 시스템 프로퍼티를 통해 덮어쓸 수 있습니다. 프로파일명으로는 주로 dev, prod, test, local 등이 사용되지만 예약어는 아니므로 아무 이름이나 자유롭게 사용하면 됩니다.

이론만이 아니라 실제로 실행했을 때의 동작방식을 생각해봅시다.

우선 위와 같이 설정한 프로젝트를 있는 그대로 실행하게 되면 최상단 영역의 설정에 따라 common.data 값은 "모든_프로파일들에서_공통으로_사용되는_데이터"가 그대로 주입되며, 자동으로 test 프로파일이 선택됩니다. 이에 따라 security.jwt.token.secret-key 프로퍼티에는 test 프로파일 섹션에 설정한 "test_프로파일일_때_사용되는_secret_key"라는 내용이 주입됩니다.

이 상태에서 사용될 프로파일을 수정하여 인텔리제이에서 실행하는 방법은 간단합니다. 우측 상단에서 Edit Configurations를 선택하고, Active profiles에 실행할 때 활성화시킬 프로파일을 기재하는 것입니다.

이처럼 prod 프로파일을 활성화시킨 상태로 애플리케이션을 재실행하게 되면, 최상단 영역에 설정한 common.data 프로퍼티는 하드코딩한 값이 그대로 주입됩니다. 그러나 spring.profiles.active 프로퍼티의 값은 test 대신 외부로부터 주입받은 prod로 덮어씌어져 실행됩니다. 이에 따라 security.jwt.token.secret-key 프로퍼티에는 prod 프로파일 섹션에 설정한 "prod 프로파일일 때 사용되는 secret key"라는 내용이 주입됩니다.

환경변수 하드코딩의 문제점

그런데 문제는 DB 관련 정보(주소, 사용자명, 비밀번호)와 같이 외부로부터 숨겨야 하는 프로퍼티 값이 존재하는 경우입니다.

이러한 상황에서 yml 파일에 모든 비밀 정보를 직접적으로 하드코딩하고, yml 파일 자체를 .gitignore에 추가하여 깃의 관리 대상에서 완전히 누락시키는 방안을 생각해볼 수 있습니다. 그러나 해당 방법의 문제점은 개발 프로세스가 굉장히 번거로워진다는 점입니다. 예를 들어 개발자마다 로컬 머신에 자신만의 yml 파일을 관리하여 작업을 하고, Jenkins 등 빌드 작업이 수행되는 곳에 yml 파일을 만들어 올려놓는다면 yml 파일의 내용이 수정될 때마다 수작업으로 모든 yml 파일들을 고쳐야 합니다.

특히 yml 파일에서 외부에 숨겨야 하는 비밀 정보는 극히 일부분에 불과합니다. 외부에 노출되어도 상관 없는 기본적인 설정들이 조금 수정될 때마다 모든 컴퓨터에서 관리되는 yml 파일들을 전부 수정해야 한다면 이는 너무나도 큰 비용입니다.

바로 이러한 점 때문에 우리는 깃헙에 yml 파일을 올려놓은 상태에서 오직 숨겨야 하는 비밀정보들만을 yml 파일 내에서 숨길 방법이 필요합니다.

yml 파일 내 환경변수 설정

이를 위해 저희는 yml 파일 내에서 외부로부터 환경변수를 받도록 설정하고 프로그램이 실행될 때 적절한 값을 주입해주는 방법을 생각해볼 수 있습니다.

설정하는 방법 자체는 간단합니다. 아래 예시와 같이 환경변수의 이름(secret-key)을 프로퍼티의 ‘값’에 해당되는 부분에 ${환경변수} 형식으로 추가하면 됩니다.

spring.profiles.active: test
common.data: '모든_프로파일들에서_공통으로_사용되는_데이터'

---

spring.config.activate.on-profile: prod
security.jwt.token.secret-key: ${secret-key}
---

spring.config.activate.on-profile: test
security.jwt.token.secret-key: "test_프로파일일_때_사용되는_secret_key"

해당 프로젝트는 기본적으로 디폴트 프로파일인 test를 사용하므로 이전과 마찬가지로 별도의 작업 없이도 언제나 문제 없이 빌드 및 실행될 수 있습니다. 다만, prod 프로파일을 활성화시키는 경우 외부로부터 secret-key에 해당되는 환경변수를 전달받아야만 실행됩니다.

인텔리제이에서의 환경변수 설정(2021.3 버전 기준)

그러면 인텔리제이에서 환경변수를 주입하여 실행해보겠습니다. 우선 위에서와 마찬가지로 우측 상단의 Edit Configurations를 선택하면 Active profiles 칸에 활성화시킬 프로파일을 기재할 수 있습니다.

다음으로 Modify options를 선택하면 아래와 같이 환경변수를 입력할 수 있는 칸이 추가됩니다. 이를 통해 다음과 같이 secret-key 환경변수의 값을 자유롭게 설정할 수 있습니다.

이처럼 인텔리제이에서 환경변수를 설정하는 방법은 각 프로젝트에 한정된 시스템 환경변수를 설정할 수 있다는 특징을 지녔습니다. 개발자의 로컬 컴퓨터에서 프로그램을 실행하며 개발하고 싶을 때 사용할 수 있는 최선의 방법입니다.

최신 버전에서는 Profile을 아래에서 서술할 Enviroment Variable의 설정 방식대로 수정할 수 있습니다

JVM 시스템 파라미터를 통한 환경변수 설정

한편 개발한 애플리케이션의 빌드 결과물을 원격 서버에서 실행하기 위해서는 리눅스 환경에서 특정 프로파일을 활성화시키고 적절한 환경변수 값을 주입해줄 수 있어야 합니다.

우선 개인적으로 선호하는 JVM 시스템 파라미터를 통해 실행 명령어 한 줄에 모든 환경변수를 전달하는 방법을 다뤄보겠습니다.

아래와 같은 명령어를 통해 prod 프로파일을 활성화시키도록 주입하고, 환경변수 secret-key의 값을 주입할 수 있습니다. secret-key에 전달된 값은 그대로 security.jwt.token.secret-key 프로퍼티의 값으로 사용됩니다.

java -jar -Dspring.profiles.active=prod -Dsecret-key='prod_프로파일의_secret_key_값' 애플리케이션.jar &

물론 아래와 같이 환경변수 secret-key를 사용하지 않고 security.jwt.token.secret-key 프로퍼티 자체에 대해 값을 주입하는 것도 가능합니다. 그러나 아래에서 확인할 수 있듯 이러한 프로퍼티명은 일반적으로 굉장히 길기 때문에 가독성이 굉장히 낮아지며 휴먼 에러가 발생하기 쉬워집니다.

java -jar -Dspring.profiles.active=prod -Dsecurity.jwt.token.secret-key='prod_프로파일의_secret_key_값' 애플리케이션.jar &

해당 방법은 실행되는 명령어 자체에 모든 정보가 포함되기 때문에 주입해야 하는 프로퍼티의 개수가 얼마되지 않을 때 굉장히 관리하기 편리합니다.

운영체제 내 시스템 환경변수 설정

다음은 운영체제 자체에 시스템 환경변수를 설정하는 방법입니다. yml 파일의 {환경변수} 문법은 JVM 파라미터만이 아니라 시스템 환경변수 값을 전달받을 수 있습니다.

다만, 시스템 환경변수의 경우 기본적으로 CONSTANT_CASE 형식으로 작성해야 합니다. 현재 프로젝트의 경우 secret-key 대신 SECRET_KEY로 환경변수명을 수정해야 합니다.

# 생략
---
spring.config.activate.on-profile: prod
security.jwt.token.secret-key: ${SECRET_KEY}---
# 생략

운영체제의 시스템 환경변수를 설정하는 방법은 환경에 따라 조금씩 차이가 있습니다. 그래도 일반적으로 맥이나 리눅스 환경에서는 .bash_profile 파일을 수정하여 환경변수를 등록하면 됩니다. 환경변수마다 export VARIABLE_NAME="value" 형식으로 한줄씩 나열하여 복수의 환경변수를 설정할 수 있습니다.

export SECRET_KEY="secret_key_at_bash_profile"

해당 세션에서 .bash_profile이 즉시 적용되도록 아래 명령어를 실행해봅시다.

source .bash_profile

이 상태로 아래 명령어를 통해 prod 프로파일을 활성화시켜 애플리케이션을 실행시켜봅시다. .bash_profile 파일에 설정해놓은 시스템 환경변수 SECRET_KEY가 문제 없이 등록되었다면, 자동으로 운영체제의 환경변수 값을 주입받아 사용하게 됩니다.

java -Dspring.profiles.active=prod -jar 애플리케이션.jar &

만일 시스템 환경변수를 무시하고 다른 값을 주입하여 실행하고 싶은 경우, JVM 시스템 파라미터로 값을 넘기면 됩니다.

java -jar -Dspring.profiles.active=prod -Dsecurity.jwt.token.secret-key='시스템_환경변수와는_다른_값' 애플리케이션.jar &

또한 운영체제에 등록한 시스템 환경변수를 제거하고 싶은 경우, 우선 .bash_profile 파일에 추가했던 export VARIABLE_NAME="value" 부분을 제거해야 합니다. 이후 unset VARIABLE_NAME 명령어를 통해 특정한 이름의 환경변수를 제거할 수 있습니다. SECRET_KEY라는 이름의 환경변수를 제거하려는 경우, 아래와 같이 작성하면 됩니다.

unset SECRET_KEY

당연한 얘기지만 해당 방법은 EC2 인스턴스와 같은 원격 서버에서 사용해야 합니다.

개발자의 로컬 머신에서는 인텔리제이를 활용하여 개별 프로젝트에 대한 시스템 환경변수를 개별적으로 설정하는 것이 이상적입니다. 예를 들어 로컬에서 작업 중인 복수의 프로젝트에서 전부 DB_URL이라는 환경변수를 사용하는 경우를 생각해봅시다. 운영체제의 시스템 환경변수로 DB_URL이라는 값을 설정하는 경우, 다른 프로젝트를 실행할 때마다 매번 시스템 환경변수인 DB_URL 값을 수정해주는 등의 작업을 해야 할 것입니다.

맺으며

해당 글은 스프링 개발자라면 알아야 하는 환경변수에 관한 기본기를 제공하는 데 초점을 맞추었습니다. 다만, 이러한 기법들이 언제나 best practice가 아니라는 점에 유의해야 합니다. 예를 들어 복수의 서버를 운영하는 경우, 각 서버에서 사용될 환경변수를 실행 시점에 맞춤형으로 주입해주는 작업 자체가 번거로울 수 있습니다. 또한 협업하는 개발자들 사이에 환경변수 정보를 어떻게 공유하고 관리할 것인지에 대한 논의 또한 필요합니다.

이런 경우에는 git submodule을 활용해 비공개 저장소에 프로파일별로 하드코딩된 yml 파일들을 관리하고, 빌드 결과물 자체에 적절한 프로퍼티들이 포함되도록 하는 것이 더 적절할 수 있습니다. 그러나 빌드 결과물에 환경변수들을 저장하더라도 특정한 프로파일을 활성화시키거나, 다른 값으로 덮어쓰는 등의 작업을 위해서는 JVM 시스템 파라미터와 같은 기본적인 지식이 필요하다고 생각합니다.

참고문서

Baeldung: Spring Profiles

공식 팀에서의 에러 헨들링

Fri, 30 Sep 2022 12:00:00 GMT

현재 팀에서의 에러 핸들링

공식에서 비동기 통신에 대하여 제대로 된 에러 관리 방식이 없어서 잡지 못하는 에러도 많았고, 컴포넌트내에 에러 로직이 무더기로 있는 경우가 있었다. 그래서 지금부터 공식팀이 에러를 처리한 방식에 대해서 알아볼 것이다!

일반적인 에러 처리 방식들

먼저 일반적으로 하는 에러처리 방식에 대해서 조사해보았다.

try / catch
ErrorBoundary
react query에서의 onError 이렇게 크게 3가지 방식으로 처리를 많이하는데 이번에는 ErrorBoundary를 이용하여 에러를 처리하기로 하였습니다.

에러 바운더리 공식문서

왜 ErrorBoundary를 이용했는가? ErrorBoundary를 이용할시 선언적으로 에러를 처리할수 있다는 장점이 있습니다. try / catch방식을 이용하면 컴포넌트내에 내가 실패했을때 어떤 처리를 할지 남아있게 됩니다. 이렇게 되면 화면을 렌더하는게 주 목적인 컴포넌트가 에러에 대한 처리까지 가지게 됩니다.

Errorboundary를 이용하게 되면 에러에 대한 로직을 부모에 위임할수 있으므로 컴포넌트내에서는 성공했을 때만을 신경쓰면 됩니다.

커스텀 에러 코드

현재 공식에서는 프로젝트에서 커스텀 에러 코드를 이용하여 에러를 구분하고 처리하고 있습니다.

에러 번호	설명	메시지
0000	예상하지 못한 서버 예외가 발생할 때	알 수 없는 에러가 발생했습니다.
0001	요청 데이터가 잘못된 경우	요청 데이터가 잘못되었습니다.
1001	깃허브에서 응답받은 토큰이 null일 때	Github API에서 Accesstoken을 받는것에 실패했습니다.
1002	깃허브에서 유저 정보를 불러오는 것에 실패할 경우	Github API에서 사용자 정보를 받는 것에 실패했습니다.
1003	프론트에서 요청하는 토큰이 null일 때	토큰이 존재하지 않습니다.
1004	토큰 타입이 잘못되었을 때	토큰 타입이 올바르지 않습니다.
1005	유효하지 않은 토큰일 때	accessToken 이 유효하지 않습니다.
1006	http servlet request가 null일 때,	인증할 수 있는 사용자 데이터가 없습니다.
1007	권한이 없는 경우 : 작성자가 아닐 때 (수정, 삭제)	작성자가 아니므로 권한이 없습니다.
1008	권한이 없는 경우 : 회원이 아닐 때 (수정, 삭제)	회원이 아니므로 권한이 없습니다.
1009	리프레시 토큰이 유효하지 않을 때	리프레시 토큰이 유효하지 않습니다.
1010	유효한 액세스 토큰으로 리프레시 토큰을 발급받을 수 없다.	“유효한 액세스 토큰으로 리프레시 토큰을 발급할 수 없습니다.”
1011	리프레시 토큰을 요청할 때, 액세스 토큰이 유효하지 않는 경우	권한이 없는 유저입니다. 재로그인을 해주세요
…	…	…
5009	투표 항목수가 2보다 작거나 5보다 클 때	투표 항목 수는 2이상 5이하여야 합니다.
6001	해시태그 이름이 비었을 때	해시태그 이름은 비어있을 수 없습니다.
6002	해시태그 이름이 2자 미만이거나 20자 초과일 때	해시태그 이름은 2자 이상 20자 이하입니다.
6003	해시태그 이름이 중복될 때(대소문자 구분x)	해시태그 이름은 중복될 수 없습니다.
6004	한 게시글당 태그가 5개 초과일 때	해시태그는 한 게시글 당 최대 5개입니다.

이렇게 커스텀 에러코드에 따라서 어떤 로직을 실행할지 어떤 ui를 보여줄지를 유연하게 설정할 수 있습니다.

프로젝트에서 발생할수 있는 에러의 종류

서버문제로 인한 500번대 에러
런타임 환경에서의 에러
일반적인 API요청에 대한 에러
네트워크 문제로 인한 에러
현재 공식에서 발생할 수 있는 에러는 다음 4개로 나누어 보았습니다. 공식에서는 react-query를 이용하기에 error.response.data에서 에러를 잡을수 있습니다. 그래서 발생할수 있는 4가지 상황에서 다음과 같이 잡을 수 있도록 처리하였습니다.
서버문제로 인한 500번대 에러

error.response.data.errorCode === ‘0000’ → 서버 에러 화면을 보여준다.
런타임 환경에서의 에러

타입스크립트를 이용해서 컴파일 환경에서 최대한 잡아주었다. → 잡지못한 에러(error.response === undefined)는 개발자가 알 수 있도록 에러를 던져줌
일반적인 API요청에 대한 에러

error.response.data.errorCode → 에러코드에 따라 로직을 수행하거나 대체 화면을 보여준다.
네트워크 문제로 인한 에러

error.response.data === undefined → 다시 ‘0000’ 커스텀 에러를 던져서 서버 에러 화면을 보여준다.

그래서 어떻게 에러를 처리했을까?

에러를 처리하는 방식으로는 ErrorBoundary를 에러를 구분할 수 있는 것은 커스텀 에러코드로 마지막으로 어디서 에러가 발생할 수 있는지까지 조사하였습니다. 그렇다면 어떻게 깔끔하게 여러 군데에서 발생하는 에러를 잡아줄 수 있을까?

공식에서는 ErrorBoundary를 이용한 중앙집중식 에러핸들링을 시도하였습니다. Error의 특징인 버블링되어 올라간다는 것을 이용하여 여러 컴포넌트에서 발생하는 에러들을 하나의 전역 공간에서 처리해주었습니다. 여기서 하나의 에러바운더리에서 모두 처리하는 것이 아니라 관심사의 분리를 위하여 2개의 ErrorBoundary로 나누었습니다. 에러가 발생할 시 대체화면을 보여주는 FallbackErrorBoundary, 화면을 바꾸지 않고 특정 로직을 수행하는 LogicErrorBoundary 2개로 나누어서 관리하였고 각각은 CommonErrorBoundary라는 공용으로 사용되는 메서드를 포함한 ErrorBoundary를 상속하여 구현하였습니다.

예시

LogicErrorBoundary

class LogicErrorBoundary extends CommonErrorBoundary<LogicErrorBoundaryProps> {
	constructor(props: LogicErrorBoundaryProps & ErrorBoundaryProps) {
		super(props);
	}
	componentDidUpdate(_: never, prevState: ErrorBoundaryState) {
		if (prevState.error === this.state.error || !this.state.error) {
			return;
		}
		const { showSnackBar, navigate } = this.props;
		const errorCode = this.state.error.errorCode;
		if (
			typeof errorCode === 'undefined' ||
			typeof showSnackBar === 'undefined' ||
			typeof navigate === 'undefined'
		) {
			throw new CustomError('9999', '빠진 인자가 없는지 확인해주세요');
		}
		const errorMessage = ErrorMessage[errorCode];
		if (isExpiredTokenError(errorCode)) {
			navigate(URL.REFRESH_TOKEN_HANDLER);
		}
		if (isVoteError(errorCode)) {
			navigate(-1);
		}
		if (isNotAccessVoteError(errorCode)) {
			navigate(URL.CATEGORY_DISCUSSION);
		}
		if (isCommentError(errorCode)) {
			queryClient.invalidateQueries('comments');
		}
		if (isAlreayLoginRefreshTokenError(errorCode)) {
			navigate(URL.HOME);
		}
		if (isInvalidRefreshTokenError(errorCode)) {
			localStorage.removeItem(ACCESSTOKEN_KEY);
			window.location.href = URL.HOME;
		}
      // 모든 에러에 대해서는 스낵바를 보여준다.
		showSnackBar(errorMessage);
      // Server에러나 NotFound에러는 LogicErrorBoundary의 부모인 FallbackErrorBoundary에게 에러를 던져 처리를 위임한다.
		if (isServerError(errorCode) || isNotFoundArticleError(errorCode)) {
			throw new CustomError(errorCode);
		}
		if (this.state.error !== null && prevState.error !== null) {
			this.reset();
		}
	}

FallbackErrorBoundary

class FallbackErrorBoundary extends CommonErrorBoundary<FallbackErrorBoundaryProps> {
  constructor(props: FallbackErrorBoundaryProps & ErrorBoundaryProps) {
    super(props);
  }
  componentDidUpdate(_: never, prevState: ErrorBoundaryState) {
    if (prevState.error === this.state.error || !this.state.error) {
      return;
    }
    if (prevState.error !== null) {
      this.reset();
    }
  }
  render() {
    const { children, serverErrorFallback, NotFoundErrorFallback } = this.props;
    if (this.state.error) {
      if (String(this.state.error.errorCode) === '0000') {
        return serverErrorFallback;
      }
      return NotFoundErrorFallback;
    }
    return children;
  }
}

중앙집중식 에러 핸들링의 장점?

에러를 추가하거나 수정할때 더 편하게 처리할 수 있었습니다.
컴포넌트를 만들때 마다 에러를 잡기위해 에러바운더리로 감싸야 한다는 것도 신경쓰지 않아도 됩니다.

class에서 hook을 사용하고 싶어..

위의 LogicErrorBoundary를 보면 showSnackBar, navigate 라는것을 이용하여 에러가 발생한 후처리를 합니다. 하지만 showSnackBar는 useSnackBar라는 커스텀 훅에서, navigate는 useNavigate라는 react-router-dom의 내장 훅을 이용합니다. 하지만 class형 컴포넌트에서는 이러한 훅을 이용할 수 없었기에 class에서 훅을 쓸 수 있게하는 연결체 HOC를 만들어서 처리하였습니다.

import { useNavigate } from 'react-router-dom';
import useSnackBar from '@/hooks/common/useSnackBar';
function WithHooksHOC<F>(Component: React.ComponentType<F>) {
	return function Hoc(props: F) {
		const { showSnackBar } = useSnackBar();
		const navigate = useNavigate();
		return <Component {...props} showSnackBar={showSnackBar} navigate={navigate} />;
	};
}
export default WithHooksHOC;
// LogicErrorBoundary
export default WithHooksHOC(LogicErrorBoundary);

이렇게 이용할시 LogicErrorBoundary내에서도 훅에서 리턴하는 값을 props로 받아서 이용할 수가 있게됩니다.

에러도 선언적으로 던지자!

에러 바운더리는 Promise에러를 잡을수 없습니다. 사실 try/catch도 동일합니다.

try {
  // 비동기 에러 발생!
} catch (err) {
  console.log(err.message);
}

이런 방식으로 코드를 작성을 한다면 catch에서 에러가 잡히길 기대하지만 사실은 Uncaught promise Error의 메시지를 만나게 될것입니다. 이에 대해서 설명하기 위해 잠시 이벤트 루프 개념이 나오게 됩니다. try에서 실행한 비동기 로직은 callback queue에 들어가게 되고, 이 callback queue는 모든 콜스택이 비어야 실행을 합니다. 그래서 실제로 에러가 던져지는 시점은 catch문까지 모두 끝난시점이기때문에 에러를 잡을수 없는것입니다.

그래서 에러를 선언적으로 던지자랑은 무슨 상관..? 에러 바운더리에서 에러를 잡게 하기위해서 error를 상태로 관리하여 component의 useEffect에서 던져주면 promise가 벗겨진 상태로 에러를 던지게 됩니다.

const [error, setError] = useState(null);
try {
  fetch('some url').catch(err => {
    setError(err);
  });
} catch (err) {
  //
}
useEffect(() => {
  if (error) {
    throw new Error(error.message);
  }
}, [error]);

하지만 공식에서는 react-query를 이용하기 때문에 이렇게 복잡한 과정없이 error를 받을 수 있습니다.

ex)

useEffect(() => {
  if (error) {
    if (!error.response) {
      throw new CustomError('9999', '런타임 에러');
    }
    if (typeof error.response.data === 'undefined') {
      throw new CustomError('0000', '네트워크에 에러가 발생하였습니다.');
    } // 네트워크 에러
    throw new CustomError(
      error.response.data.errorCode,
      ErrorMessage[error.response.data.errorCode],
    ); // 일반 API에러
  }
}, [error]);

하지만 이 역시 컴포넌트마다 커스텀 에러를 던지는 로직이 있기 때문에 모처럼 에러를 선언적으로 처리한 보람이 없습니다. 그래서 에러를 던지는것 마저도 useThrowCustomError라는 커스텀 훅을 이용하여 처리하였습니다.

마무리

이렇게 하여서 에러를 선언적으로 처리하여 컴포넌트내에서의 가독성을, 중앙집중식으로 에러를 관리하여 에러처리의 수정, 확장등이 간편해지도록 관리하였습니다. 추후 Sentry라는 라이브러리를 이용하여 미처 잡지 못한 에러들에 대해서 추적할 수 있도록 할 예정입니다.

Life of Pixel

Mon, 26 Sep 2022 12:00:00 GMT

이 글은 Google Chrome 개발자 Steve Kobes의 Life of Pixel영상을 보고 정리한 내용입니다. 사용된 이미지들은 Steve Kobes의 허락 하에 slide show에서 가져왔습니다.

이 글의 목표

어떤 과정을 통해 HTML파일이 화면에 그려지고, page가 되는지 이해합니다.
composite에 대해 이해합니다.
왜 layer를 분리하는것이 더 빠른 렌더링을 가능하게 하는지 이해합니다.

간단 요약

HTML content(index.html)를 불러옵니다.
HTML Parser가 index.html을 parsing 하면서 DOM을 생성합니다. (DOM)
style 자원을 만나면 CSS Parser가 parsing 후, 각 DOM 노드에 computedStyle을 적용합니다. (style)
DOM과 computedStyle을 바탕으로 각 노드의 position과 size를 계산합니다. (layout)
layout tree를 바탕으로 layer tree를 생성합니다. (comp.assign)
노드를 어떻게 그릴지에 대한 작업 순서를 정합니다. (paint)
작업 순서를 compositor thread (=impl) 에게 전달합니다. (commit)
GPU process에서 paint 단계 때 정한 작업 순서들을 바탕으로 bitmap을 생성합니다. (rasterization)
이제 bitmap을 OpenGL을 통해 화면에 그립니다.

그림에 나오는 중간에 prepaint, tiling, SKIA는 아래 쪽에서 추가로 설명하겠습니다.

화면에 그려지는 과정

Parsing

HTMLParser는 HTML tag를 읽으면서 DOM Tree를 생성합니다.

조금 더 구체적인 parsing 과정은 다음과 같습니다.

from : https://web.dev/critical-rendering-path-constructing-the-object-model/

DOM

DOM은 두 가지를 의미합니다.

HTML Tag를 parsing 해서 만든 C++로 이루어진 트리 형태의 자료 구조 (내부 구현체)
이 내부 구현체에 Javascript로 접근해서 조작할 수 있도록 만든 API

Style Calculation

CSSParser는 CSS코드를 파싱하면서 StyleRule을 생성하고 그것을 StyleSheetContents에 담습니다.

다시 말해서,

.fancy-button {
  background: green;
  border: 3px solid red;
  font-size: 1em;
}

이런 css코드를 파싱해서

이런 StyleRule을 만들어 내는것이라 추측됩니다.

StyleResolver는 StyleRule이 담겨있는 StyleSheetContents를 바탕으로 각 노드(Element)에 대한 ComputedStyle을 구해서 적용합니다.

ComputedStyle은 CSS selector 우선순위까지 다 고려(cascading)해서 최종적으로 노드에 적용될 CSS값들의 모음입니다. dev-tools에서 쉽게 확인 가능합니다.

쉽게 말하자면

CSS코드를 파싱하고, DOM의 각 노드에 대한 ComputedStyle을 구해서 적용합니다.

from : https://developer.chrome.com/blog/inside-browser-part3/#subresource-loading

Layout

이제 DOM을 만들었고 각 노드에 대한 style도 알았으니, 위치와 사이즈 값도 알아낼 수 있습니다.

너무 어려운 Layout 과정

그런데 이 과정은 꽤나 어렵습니다. 고려해야 할 것이 많기 때문입니다.

이렇게 라인이 넘어가는 것도 고려해주어야하고,

font도 고려해주어야 합니다. 이 외에도 overflow나 float속성도 고려해서 위치 값을 계산해야 합니다.

제가 어디서 읽은 바로는 크롬 브라우저 개발자의 대부분이 이 layout계산쪽에서 일을 한다고 합니다. 그 정도로 복잡하고 어려운 일이라고 합니다.

Layout Tree 생성

메인 스레드에서 이 레이아웃을 계산하면서 레이아웃 트리를 생성합니다. 레이아웃 트리의 LayoutObject들은 각각 DOM Tree의 노드와 연결되어 있습니다.

우리가 흔히 아는 reflow가 바로 여기서 발생합니다. 즉, reflow는 layout tree를 순회하면서 각 LayoutObject의 위칫값과 사이즈를 다시 계산하는 것을 의미합니다.

예를 들어서, DOM Element의 width/height/top/right 등을 바꾸면 이 layout tree를 순회하면서 LayoutObject의 위칫값과 사이즈를 다시 계산합니다.

Paint

이제 각 노드의 스타일과 위칫값을 알았으니, 화면에 그리는 일만 남았습니다. 하지만! 이름과 달리 paint 단계는 화면에 그리는 일을 하는 단계가 아닙니다.

paint 단계에서는 화면에 무엇을 어떤 순서로 그려야 할지에 대한 정보를 기록하는 일이 이뤄집니다.

PO즉, Paint Operation은 “[100, 200]에 가로가 200px, 세로가 140px인 사각형을 그려!” 라는 작업 내용입니다. 이것들이 쌓여서 DisplayItem에 들어가고, 이 DisplayItem의 목록은 PaintArtifact에 들어갑니다.

DisplayItem을 조금 더 확대해보면 이렇게 생겼습니다.

위 설명에 대한 조금 더 쉬운 그림은 다음과 같습니다.

from : https://developer.chrome.com/blog/inside-browser-part3/#subresource-loading

z-index를 고려하라

z-index도 잘 고려돼서 그려질 수 있도록 PO가 구성됩니다.

Raster

이제 어떤 순서로 그려야 할지 알았기 때문에, 화면에 그리는 일만 남았다고 생각할 수 있지만, 아직 조금 더 남았습니다.

위에서 구한 정보들(DisplayItem)을 바탕으로 bitmap을 만드는 일을 rasterization이라고 부릅니다.

그리고 이 rasterization은 일반적으로 GPU 안에서 이뤄집니다.

현재 사용 중인 크롬 브라우저에서 GPU 가속이 사용되고 있는지 확인하려면 chrome://gpu/ 요기로 들어가면 됩니다.

Rasterization에 Hardware accelerated가 되어있는 것을 볼 수 있습니다.

raster to screen

이렇게 rasterization 되고 나서 screen에 pixel로 그려지는 작업도 GPU에서 일어납니다.

SKIA

다양한 하드웨어 및 소프트웨어 플랫폼에서 작동하는 공통 API를 제공하는 오픈 소스 2D 그래픽 라이브러리입니다. 구글 크롬, 크롬 OS, 안드로이드, Flutter 등 여러 제품의 그래픽 엔진 역할을 합니다. 구글에서 만들었습니다.

OpenGL

그래픽 카드와 통신할 수 있도록 지원해주는 API 또는 표준 규격입니다. 이 API는 GPU에게 직접적으로 명령을 내리는 command로 변환됩니다.

Skia와 OpenGL의 관계

Skia 라이브러리에서 제공하는 API를 사용하면 OpenGL API로 변환됩니다. 즉, Skia는 조금 더 고수준의 API이죠.

쉽게 설명하자면

Paint이후 GPU에서 rasterization이 이뤄지고 화면에 pixel로 그려집니다.

화면에 그린 이후 변화 발생

DOM -> style -> layout -> paint -> raster -> GPU -> 화면에 그리기! 까지 왔습니다. 그런데 사용자가 스크롤을 하거나, 줌인/아웃을 하거나 Javascript로 style을 동적으로 바꾸면 브라우저는 이를 어떻게 처리할까요?

Frame

초당 60 frame을 그리지 못하면, 화면이 뚝뚝 끊겨 보이는(janky) 현상이 발생합니다.

Invalidation

렌더링이 빠르게 되도록 하는 여러 방법 중 하나는, 변했는지 변하지 않았는지 체크하고 변한 부분만 업데이트하는 것입니다. 예를 들어서

DOM노드의 style에 변화가 가해졌으니 다음 프레임때 computedStyle을 다시 구할 필요가 있기 때문에, 표시(mark)해 놓습니다.(SetNeedsStyleRecalc 호출)

마찬가지로 Layout에 변화가 가해졌다면, 다음 프래임 때 layout을 다시 계산하도록 표시해 놓습니다(SetNeedsLayout).

변화가 없다면 이전 프레임에서 계산된 결과(DOM Node, LayoutObject 등)를 그대로 사용합니다.

이렇게 변화가 가해졌을 때 다음 프레임에 새로 계산하도록 표시하는 것을 invalidation이라고 부릅니다. (slide에는 granular asynchronous invalidations 라고 적혀있습니다)

repaint

하지만 스크롤이나 애니메이션 같은 경우에는 위의 optimization이 큰 효과를 못봅니다. 너무 많이 변하기 때문입니다. 예를 들어서, 스크롤 같은 경우

매 스크롤 이벤트마다 repaint와 rasterization이 계속 발생합니다. 이는 비용이 많이 들어갑니다.

jank

scroll으로 인한 repaint - rasterization 외에도 우리가 신경 써야할 것이 있습니다. 바로 Javascript도 main thread에서 실행된다는 것입니다.

(scroll로 인한 repaint - rasterization은 어쩔 수 없는 것인데 왜 신경 써야 하나?..라고 생각하실 수 있습니다. 이는 아래 compositor쪽에 이야기가 다시 나옵니다.)

그래서 아무리 rendering pipeline이 빠르게 진행된다고 하더라도 javascript 코드 실행이 너무 오래 걸리면 jank가 발생합니다.

Compositing

그래서 invalidation 같은 최적화 기능도 있지만, scroll로 인한 repaint + rasterization과 Javascript 코드를 실행하는 비용이 많이 들어서 rendering이 늦어지는 문제를 완화하기 위해 compositing이 나왔습니다.

먼저 메인 스레드에서 page를 여러 layer로 나누고 compositor thread에서 이를 합성합니다. 이렇게 layer를 나누면 rasterizing이 각 layer에서 독립적으로 발생합니다.

예시

BBB layer를 rasterizing해서 만든 bitmap만 transform하면, 매 animation frame마다 전체 페이지를 rasterizing 하지 않아도 됩니다.

그리고 부모가 layer라면 자식들도 그 layer의 subtree가 됩니다.

이렇게 layer를 분리해서 rasterizing 후 생성된 bitmap만 변형하게 된다면, 매 animation frame 마다 전체 페이지를 rasterizing 하지 않아도 되기 때문에 효율적입니다.

threaded input

main thread가 바쁠 때 compositor thread는 browser process로부터 사용자의 스크롤 입력을 받아 bitmap을 transform 합니다.

물론 사용자가 특정 레이어가 아닌 전체 페이지를 스크롤링하면 compositor thread에서 처리하지 않고 main thread로 일을 넘깁니다. 왜냐하면 전체 페이지를 다시 그리는 render pipeline을 거쳐야 하기 때문입니다.

추가로 Javascript에서 scroll event listener를 걸어놓은 경우에는 사용자 입력을 main thread에서 처리하도록 task queue에 넣습니다.

Layer는 어떻게 만들어지는가?

Layer는 transform같은 CSS property를 바탕으로 layout object에서 생성됩니다.

main thread에서 DOM -> style -> layout 이후에 layer가 만들어지고, 이 단계를 compositing assignments라고 부릅니다.

그리고 paint 단계에서 각 레이어는 자신만의 DisplayItemList를 가지게 됩니다. 즉 “무엇을 어떤 순서로 그릴 것인지”에 대한 정보인 DisplayItemList가 레이어마다 따로따로 설정된다는 의미입니다.

pre-paint

paint전에 pre-paint 단계가 있습니다.

이 단계에서 property tree를 생성합니다. 참고로 property tree는 아래처럼 생겼습니다.

Property tree에 대하여 (Naver D2 글)

“레이아웃 트리와 다음에 설명할 페인트 트리 사이에 한 가지 작업이 더 있다. 레이아웃 트리를 순회하면서 속성 트리(property tree)를 만드는 작업이다. 속성 트리는 clip, transform, opacity 등의 속성 정보만 가진 트리이다. 기존에는 이런 정보를 분리하지 않고 노드마다 가지고 있었다. 그래서 특정 노드의 속성이 변경되면 해당 노드의 하위 노드에도 이 값을 다시 반영하면서 노드를 순회해야 했다. 최신 Chrome에서는 이런 속성만 별도로 관리하고 각 노드에서는 속성 트리의 노드를 참조하는 방식으로 변경되고 있다.”

Commit

paint가 완료되면, 이제 이렇게 만든 레이어들을 하나의 프레임으로 만들기 위해서 레이어들과 property tree를 compositor thread에게 넘겨줘야 합니다. 이 단계를 commit이라 부릅니다.

tiling

paint 이후에 layer의 paint operation을 bitmap으로 만드는 작업인 rasterization을 합니다. 그런데 layer가 너무 큰 경우는 어떨까요?

사용자에게 보이는 view port보다 엄~청 큰 layer의 경우, 이 layer를 rasterizing 하는 것은 너무 비용이 큽니다. 그래서 compositor thread에서 이 layer는 작은 tile 들로 나눠집니다. 이 tile 들은 render process 안에 있는 여러 raster thread에서 비동기적으로 rasterzied 됩니다.

그런데 아래쪽에서는 rasterization은 Skia를 통해 GPU에서 일어난다고 하는데, 아마도 render process의 raster thread가 GPU Process의 SKIA를 사용해서 rasterization 한다는 의미 같습니다.

Layer 그리기

layer의 모든 tile 들이 rasterizing되면 compositor thread는 각 tile에 대한 DrawQuad를 생성합니다. DrawQuad는 tile을 rasterizing 한 bitmap을 참조하고 있고, tile을 스크린의 어느 위치에 그려야 하는지에 대한 instruction를 가지고 있습니다. 이때 이 위칫값은 property tree를 고려해서 계산됩니다.

이렇게 만든 DrawQuad를 묶어서 CompositorFrame 객체에 넣습니다. 그리고 이 CompositorFrame은 GPU Process에게 넘겨집니다.

지금까지 우리는 renderer process 안에서 main thread + compositor thread + raster thread를 활용해 DOM -> style -> layout -> layer -> pre-paint -> paint -> commit -> tiling 과정을 통해 최종적으로 CompositorFrame을 만들었습니다.

남은 일은 이 CompositorFrame(=animation frame)을 화면에 그리기만 하면 됩니다.

Display(viz)

GPU Process는 CompositorFrame을 받아서 SKIA API를 사용해 OpenGL(혹은 Vulkan) API를 부르고, OpenGL은 그래픽카드를 사용해 화면에 tile을 그립니다.

정리

브라우저는 web content를 받습니다.
DOM Tree를 만듭니다.
style을 계산합니다(resolve styles).
layout을 계산합니다.
layer를 만듭니다.
property tree를 만듭니다.
layer를 paint합니다.
layer + DisplayItemList(paint operations) + property tree를 compositor thread로 commit(복사/붙여넣기)합니다.
layer를 여러 작은 조각(tile)로 나눕니다.
SKIA library를 사용해 tile을 rasterizing 합니다.
DrawQuads를 생성합니다.
Skia와 OpenGL를 통해 DrawQuads를 실제 스크린에 그립니다. (pixel화)

질문

external CSS도 HTML parser를 block 하나요?

from : https://web.dev/preload-scanner

네, blocking 합니다. 관련글

In this case, the parser runs into a <link> element for an external CSS file, which blocks the browser from parsing the rest of the document—or even rendering any of it—until the CSS is downloaded and parsed.

inline style 도 parser를 block 하나요?

네 block합니다! 관련 글

Similar to inlining code in a <script> tag, inline critical styles required for the first paint inside a <style> block at the head of the HTML page

style자원을 가져오고 parsing할때까지 왜 HTML Parser는 멈춰있나요?

flash of unstyled content (FOUC) 문제 때문에 그렇습니다.

from : https://web.dev/preload-scanner

그러니까, style.css파일을 다운받고 있는데, HTML Parser가 다 파싱하고 rendering까지 끝나면 스타일이 적용되지 않은 사이트가 사용자에게 보일것이고, 후에 style.css파일 다운로드가 끝나고 파싱하고 적용하면 그때 스타일이 적용된 사이트가 보일것입니다.

이는 사용자에게 번쩍! 하는 느낌을 주기 때문에 별로 좋지 않습니다. 그래서 style.css파일을 다운받고 파싱이 끝날때까지 HTML Parser는 기다립니다.

참고

이론과 실습을 통해 이해하는 Docker 기초

Sun, 25 Sep 2022 12:00:00 GMT

본 포스팅은 도커에 대한 자세한 개념, 도커 기본 명령어, 컨테이너 실행 실습, 도커 컴포즈, 도커 이미지 빌드, 도커 허브에 이미지 배포 등 전반적인 도커 기초에 대한 내용을 다룬다.

도커 (Docker)

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼이다. 솔로몬 하익스가 개발했으며, 2013년에 처음 발표되었다. 고 (Go) 언어로 개발되고 있다.

해상 운송업의 컨테이너

선박을 이용하여 수출입하는 해상 운송업의 모습을 상상해보자. 모든 선적물은 거대한 상자모양의 컨테이너를 통해 패키징 된 후 화물선에 선적된다. 컨테이너는 국제적으로 표준화, 규격화된 크기를 갖고있다. 컨테이너와 관련된 보관, 운송과 관련한 장비, 제도, 프로세스 등은 모두 국제 표준에 맞게 설계된다.

이런 표준화의 특징으로 인해 해상 운송업자는 컨테이너 안에 어떤 물건이 담겨져 있는지 전혀 알 필요가 없다. 그저 컨테이너 단위로 선적하여 운송하고 하역하고 보관하면 그만이다. 따라서 한국에서 수출한 물건을 저 멀리 미국에서도 ‘장소에 구애 받지 않고’ 손쉽게 하역하고, 운송할 수 있는 것 이다.

만약 해상 운송업에서 컨테이너를 사용하지 않는다면 어떻게 될까? 제각기 다른 물건의 크기, 모양, 심지어 액체/고체 여부에 대응하기 위해 서로 다른 운송 장비, 보관 방법, 프로세스가 필요할 것이다.

도커의 컨테이너

도커의 컨테이너도 마찬가지이다. 도커는 서비스를 운용하는데 필요한 실행환경, 라이브러리, 소프트웨어, 시스템 도구, 코드 등을 컨테이너라는 표준화된 단위로 추상화한다. 이렇게 만들어진 컨테이너는 컴퓨팅 환경에 구애받지 않고 서비스가 실행될 수 있도록 한다.

실제 컨테이너의 특성처럼, 서비스 관리자는 도커라이징(Dockerizing) 된 컨테이너가 어떤 런타임을 필요로 하는지, 어떤 라이브러리와 코드를 필요로 하는지 전혀 알 필요가 없다. 그저 컨테이너를 어딘가에서 가져와서 서비스를 운영할 컴퓨팅 환경에서 실행하기만 하면 된다. 실행된 서비스는 컴퓨팅 환경과 독립된 가상의 환경에서 실행되며, 일관된 결과를 보장한다.

전통적인 서버관리

우리가 새로운 서비스를 개발하고 있는 개발자라고 생각해보자. 우리가 런칭하려는 서비스는 규모가 상당하여, 시스템 환경 설정부터, 방화벽, 네트워크 등의 많은 설정이 필요하다. 또한 Java, Python, Node.js 등 많은 프로그래밍 언어를 사용하고, 각각의 언어는 또 많은 라이브러리 의존성을 갖는다. 여기서 끝이 아니다. PostgreSQL, MariaDB, Redis 등 여러개의 DBMS 도 사용한다. 하지만, 우리는 유능한 개발자다. 이 많은 것들을 우리의 로컬 개발환경에 완벽하게 셋업했다.

우리는 서비스를 완성했고, 이제 서비스를 배포해야할 상황이 찾아왔다. 어라, 급하게 개발하다보니 개발서버 환경을 어떻게 설정했는지, 어떤 언어와 라이브러리를 설치했는지, DBMS 는 무엇을 사용하는지, 각각의 버전은 무엇인지 전혀 기록해두지 않았다. 하지만, 우리는 불굴의 개발자이다. 서버의 모든 환경설정과 Git 로그를 뒤져내어 서버를 세팅하는 매뉴얼을 작성하는데 성공했다.

자, 이제 토씨하나 틀리지 않고 메뉴얼대로 프로덕션 서버에도 개발환경과 동일한 환경을 구축하면 된다. 결국 서버를 모두 세팅하였고, 서비스를 실행해보았다. 어라, 오류가 발생한다. 수 시간의 삽질 끝에 오류의 원인을 알아내었다. 어떤 라이브러리의 버전이 개발환경과 달라 발생한 오류였다. 아까 서버를 세팅할 때 실수를 한 모양이다. 어찌됐든 성공적으로 서비스를 배포하는데 성공하였다.

서비스는 성공적이었고, DAU는 치솟았다. 슬슬 서버를 확장해야할 것 같다. 경제적 이유로 확장의 형태는 수평 확장으로 결정되었다. 또 다른 서버에 이전과 똑같은 프로세스대로 환경을 셋업해야한다. 정신이 아득해진다.

위와 같이 컨테이너를 사용하지 않은 전통적인 서버 관리방식에서는 밑 바닥부터 수작업으로 모든것을 세팅해야한다. 이런 환경에서 만약 개발언어를 Python 에서 Go 로 교체하는 등 서버 환경과 개발 환경이 바뀐다면? 운용중인 모든 서버에도 변경 사항을 적용해야한다. 생각만해도 끔찍하다.

도커를 사용한 서버관리

도커를 사용하면, 위와 같이 귀찮고 고통스러운 작업을 반복할 필요 없다. 도커를 사용하면 OS 환경설정, 언어, 라이브러리, 시스템 도구 등이 설치된 환경을 그대로 이미지로 빌드할 수 있다. 이미지는 후술할 Dockerfile 이란 것을 이용하여 만들 수 있다. 개발 환경에서 만들어진 이미지를 그대로 프로덕션 서버에 전달하고, 이미지를 기반으로 컨테이너를 생성하고 실행하면 끝이다.

이런 컨테이너의 특징은 곧, 도커의 중요한 특징인 표준성과 상통한다. Java, node.js, Python 등 다양한 언어와 프레임워크를 사용한 서비스들은 제각기 다른 배포 방법을 가지고 있다. 하지만 이를 도커를 통해 패키징하여 컨테이너를 만든다면, 어떤 언어, 프레임워크, 런타임을 사용하던 관계없이 모두 동일한 배포 프로세스를 갖게 된다.

이런 표준성 덕분에 도커는 높은 확장성과 이식성을 갖는다. 도커가 설치된 환경이라면 어디서든 컨테이너를 실행할 수 있으며, 이를 통해 프로덕션 서버는 물론, 개발 및 테스트 서버 구축과 운영도 아주 쉬워진다. 컨테이너의 설정은 보통 환경변수로 제어하므로, 환경(개발, 테스트, 프로덕션 등)에 따라 환경 변수를 다르게 설정하여 관리할 수 있다.

단, 도커의 컨테이너는 삭제되면 모든 데이터가 초기화된다. 이를 막기 위해 외부 저장장치에 링크를 하거나, AWS S3 등 별도의 클라우드 스토리지를 사용해야할 필요가 있다.

이 모든 설정은 코드와 설정파일 기반으로 관리되어 Git 등을 사용하면 히스토리가 남게 되며, 재현과 추적이 가능하다.

컨테이너 vs VM (Virtual Machine)

그렇다면, 도커 같은 컨테이너 기반의 가상화 플랫폼과 VM의 차이점은 무엇일까?

위 그림의 왼쪽은 도커의 구조를, 오른쪽은 VM 의 구조를 나타낸다. 가장 먼저 눈에 들어오는 차이점은 하이퍼바이저 (Hypervisor) 의 유무이다. 하이퍼바이저란 Virtual Box 나 VM Ware 와 같은 가상 머신을 생성하고 실행하는 프로세스이다. 하이퍼바이저는 하드웨어를 에뮬레이션하여 하나의 컴퓨터에서 다수의 운영체제를 운영할 수 있게 해주는 소프트웨어이다.

하이퍼바이저 자체를 실행하는 측을 호스트 운영체제 (Host OS) 라고 하며, 하이퍼바이저가 구동하는 가상화된 OS 를 게스트 운영체제 (Guest OS) 라고 한다. 게스트는 호스트로부터 일정량의 리소스를 할당을 받아 구동된다. 운영체제 자체를 가상화하여 실행하는 특징으로 도커에 비해 상대적으로 무겁다. 호스트 운영체제와 게스트 운영체제의 기능 중복으로 인해 약 10 ~ 20% 의 오버헤드 (Overhead) 를 갖는다고 한다.

하지만, 도커와 같은 컨테이너 기반 가상화 플랫폼은 게스트 운영체제 없이, 프로세스를 격리하는 방식으로 호스트 운영체제의 모든 기능과 리소스를 컨테이너간 공유한다. 운영체제 위에 또 다른 운영체제를 구동하지 않아도 되며, 리소스도 공유해서 사용하므로 오버헤드는 3 ~ 5% 이내라고 한다. 또한 운영체제를 별도로 가상화 하지 않으므로 이미지 파일의 용량도 하이퍼바이저에 비해 낮다.

도커 시작하기

(참고) 본 포스트는 Mac 환경을 기준으로 작성되었다.

설치

도커를 사용하기 위해서는 도커를 먼저 설치해야한다. Mac 이나 Windows 를 사용하는 유저는 Docker 웹사이트 에 접속하여 Docker Desktop 을 OS 에 맞게 다운로드하여 설치하면 된다.

리눅스 환경에서는 sudo 권한으로 아래의 명령을 입력하면 도커를 설치할 수 있다.

curl -fsSL https://get.docker.com/ | sudo sh

설치되었는지 확인하기 위해서 docker version 명령을 입력해본다. 아래와 같이 버전정보가 표시된다면 성공적으로 설치된 것이다.

$ docker version
Client:
 Cloud integration: v1.0.22
 Version:           20.10.11
 (생략)

Server: Docker Engine - Community
 Engine:
  Version:          20.10.11
 (생략)

컨테이너를 실행하기 전에…

본격적으로 도커를 맛보기 위해 여러가지 도커 이미지를 다운받고, 컨테이너를 실행해보며 대략적인 사용방법을 익혀본다. 일단 첫번째로는 순수하게 아무것도 설치되지 않는 Ubuntu 와 CentOS 이미지를 받아와 컨테이너를 실행해볼 것이다.

잠깐 다음으로 넘어가기 전에 짚고 넘어가야할 것이 있다. 위에서 도커는 분명 Guest OS 를 구동하지 않는다고 했는데, 어떻게 Ubuntu, CentOS 를 구분지어 구동할 수 있는 것일까? 도커 컨테이너는 Kernel 데이터를 갖고 있지 않다. 다만 컨테이너가 필요로 하는 Kernel 은 Host OS 의 것을 그대로 사용하고, Kernel 외의 데이터만을 패키징하여 컨테이너가 가지고 있는다. 이를테면, Ubuntu 와 CentOS 의 차이점만을 컨테이너에 패키징되어 담고 있는 것 이다. Ubuntu와 CentOS 는 서로 다른 리눅스 배포판이지만, 같은 Linux Kernel 을 사용하기에 이것이 가능하다.

이렇게 말한다면 또 Mac 과 Windows 사용자는 궁금해 할 것이다. ‘내가 사용하는 OS 는 Linux Kernel 기반이 아닌데, 어떻게 도커가 동작하나요?’ 사실 정확히 이야기하자면, Docker 는 Linux 환경에서만 네이티브로 동작한다. Linux 이외의 환경에서 도커를 사용할때에는 도커 자체가 OS 에서 지원하는 가상화 환경에서 구동된다.

이때 가상화 기술로 Mac 은 xhyve, Windows 는 Hyper-V 를 사용하여 별도의 Linux 환경을 만들 수 있다. Docker 의 핵심인 Docker Engine 은 이 가상화 환경의 Linux 위에서 돌아가게 된다.

자, 어려운 이야기는 여기서 끝내고 직접 도커를 다뤄보자.

Ubuntu 컨테이너 올리기

제일 처음으로 할 것은 우분투 이미지를 사용하여 컨테이너를 올려보는 것 이다. 자세한 명령은 더 아래에서 정리해볼테니 명령어를 외우기보단 따라하며 도커가 무엇인지 직관적으로 이해하는 것에 집중하자.

Docker Desktop 을 실행한 다음 터미널에서 아래 명령을 입력한다.

$ docker run ubuntu:latest

위 명령을 입력하여, 우분투의 최신 버전 이미지를 다운받고, 컨테이너를 실행할 수 있다. 처음 명령을 입력하는 경우 이미지를 다운로드 해야하므로 조금 기다려야한다. 아래와 같이 출력되면, 이미지 다운로드가 끝나고 컨테이너가 올라간 상태일 것이다.

Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
bbf2fb66fa6e: Pull complete
Digest: sha256:669e010b58baf5beb2836b253c1fd5768333f0d1dbcb834f7c07a4dc93f474be
Status: Downloaded newer image for ubuntu:latest

컨테이너가 올라갔는지 확인하기 위해 Docker Desktop 창을 열어 확인해보자.

리스트에 무언가 생긴것을 볼 수 있다. 컨테이너 이름은 별도로 지정해주지 않는 이상 임의의 이름으로 설정되므로 사진과 다른 이름일 것 이다. 우측에 ubuntu:latest 라고 써있는 것을 보니 우리가 생성한 컨테이너가 맞는 것 같다.

하지만 이렇게 실행되는 컨테이너도 프로세스의 일종이기 때문에, 우분투에 실행되고 있는 프로세스가 없다면 컨테이너도 종료되어 아무것도 할 수 없다. Docker Desktop 에서 우리가 생성한 컨테이너에 마우스를 올리고 휴지통 버튼을 클릭하여 컨테이너를 일단 삭제해보자. 혹은 아래 명령을 입력하여 컨테이너를 삭제할수 있다.

$ docker rm {컨테이너_이름}

그리고, 아래 명령을 입력하여 도커 컨테이너가 올라가자마자 쉘을 실행하도록 하자. 쉘은 프로세스이므로 우분투 컨테이너가 바로 종료되지 않을 것 이다.

$ docker run -it ubuntu:latest /bin/sh

-it 옵션은 컨테이너를 종료하지 않은 상태로 터미널의 입력을 컨테이너 내부로 전달하기 위해 사용된다. 또한 docker run 명령에서 이미지 이름 다음으로 적는것은 컨테이너가 실행된 직후 이어서 실행되는 명령이다. /bin/sh 을 입력하였으므로 쉘이 실행된다.

# echo "hello, docker"
hello, docker

터미널에 위와 같이 입력하여 컨테이너 내부로 명령을 전달해보자. 우분투 쉘에서 hello, docker 라는 문자열이 그대로 출력되면 성공이다.

CentOS 컨테이너 올리기

이번에는 다른 Linux 배포판인 CentOS 이미지를 사용해보자. 아래 명령으로 CentOS 이미지를 다운받고 컨테이너를 실행하자.

$ docker pull centos:centos8.4.2105

이미지 명을 작성할때 : 뒤에 오는 centos8.4.2105 는 태그라고 한다. 이번에는 centos8.4.2105 태그를 사용하여 명시적으로 사용할 이미지의 버전을 입력해주었다.

$ docker run -it --rm centos:centos8.4.2105 /bin/sh

위에서 한 것 처럼 run 명령을 이용해 컨테이너를 실행할 수 있다. --rm 옵션이 추가되었는데, 이는 컨테이너가 종료되면 컨테이너를 삭제하라는 의미이다.

Nginx 웹서버 구축하기

이번에는 Nginx 라는 웹 서버를 이용하여, 웹 서버를 올려보고 직접 html 파일을 서빙해보자. 이번엔 컨테이너 내부의 저장공간과 Host OS 저장공간을 이어주어 서빙할 html 파일을 손쉽게 전달해 볼 것이다. 이를 볼륨 마운트 (Volume Mount) 라고 한다. 볼륨 마운트는 -v 옵션을 통해 할 수 있다.

또한, Nginx 의 기본 HTTP 포트는 80을 외부에서 3000으로 접근할 수 있도록 외부포트와 내부포트를 바인딩 해줄 것 이다. 이는 -p 옵션을 통해 가능하다. 적당한 디렉토리를 만들고, 그 디렉토리에서 아래의 명령을 입력하자.

$ docker run --rm -p 3000:80 \
  -v $(pwd)/:/usr/share/nginx/html/ \
  nginx

한번 localhost:3000 에 접속해보자. 아래와 같이 403 Forbidden 화면이 출력되면 성공이다.

현재 이 컨테이너의 /usr/share/nginx/html/ 디렉토리는 Nginx 가 서빙할 정적 파일이 위치하는 디렉토리이다. 그 디렉토리는 명령을 실행한 현재 Host OS의 디렉토리와 연결되어 있는 상황이다. 현재 디렉토리에 아래와 같이 index.html 파일을 생성해보자.

<html>
  <head>
    <title>Docker</title>
  </head>
  <body>
    <h1>Hello, Docker!</h1>
  </body>
</html>

그리고 다시 접속해보면, 아래와 같이 우리가 만든 HTML 파일이 서빙될 것이다.

PostgreSQL DB서버 구축하기

이번엔 RDBMS 중 하나인 PostgreSQL 컨테이너를 올려보자. 이야기 했지만 컨테이너는 삭제되면, 데이터도 함께 삭제된다. PostgreSQL 은 DBMS 이므로 꼭 볼륨 마운트를 해줘야한다. 적당한 디렉토리를 만들고, 아래 명령을 실행하자.

$ docker run --name postgres -d \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=password \
  -v $(pwd)/data/:/var/lib/postgresql/data/ postgres:14.1

이번엔 --name 옵션을 통해 컨테이너의 이름을 우리가 직접 postgres 로 설정해주었다.

-d 옵션은 Detached Mode 로 컨테이너를 실행하는 옵션으로, 컨테이너가 백그라운드 모드로 돌아가도록 설정해준다.

-e 옵션을 통해 컨테이너가 사용하는 환경변수를 설정할 수 있다. 우리는 POSTGRES_PASSWORD 를 password 로 설정하여, PostgreSQL 접속에 사용하는 비밀번호를 설정하였다.

우리는 -d 옵션을 사용하여 컨테이너를 백그라운드에서 실행했다. 외부에서 컨테이너에 명령을 내리는 방법은 exec 을 사용하는 방법이 있다. 일단 아래 명령을 통해 현재 실행중인 컨테이너 리스트를 확인해보자.

$ docker ps

CONTAINER ID   IMAGE           COMMAND                  CREATED         STATUS         PORTS                    NAMES
9ccd0f78bcf3   postgres:14.1   "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   0.0.0.0:5432->5432/tcp   postgres

가장 오른쪽 NAMES 에 우리가 올린 postgres 를 확인할 수 있다. 이 컨테이너에 접속하여 명령을 실행해보자.

$ docker exec -it postgres /bin/sh

docker run 과 비슷하지만, 이미지 이름 대신 postgres 라는 컨테이너 이름을 넣어줬다. 그리고 마찬가지로 쉘을 실행해준다.

# psql -U postgres
psql (14.1 (Debian 14.1-1.pgdg110+1))
Type "help" for help.

postgres=# CREATE DATABASE hello_docker;
CREATE DATABASE
postgres=# \l
                                  List of databases
     Name     |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
--------------+----------+----------+------------+------------+-----------------------
 hello_docker | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 postgres     | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 template0    | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
              |          |          |            |            | postgres=CTc/postgres
 template1    | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
              |          |          |            |            | postgres=CTc/postgres

PostgreSQL 이 정상적으로 설치되고 실행되는 모습을 확인할 수 있다.

Ghost 블로그 구축하기

이번엔 Ghost 라는 오픈소스 블로깅 플랫폼을 사용하여 블로그를 구축해보자.

$ docker run -d --name ghost-blog \
  -e url=http://localhost:3001 \
  -p 3001:2368 \
  -v $(pwd)/content/:/var/lib/ghost/content/ \
  ghost:4.34.3

위 명령을 입력한 후 아래와 같이 Ghost 블로그가 localhost:3001 에서 접속이 되면 성공적으로 설치가 완료된 상황이다.

Ghost 이미지에는 Ghost 뿐 아니라 DB 도 포함되어 빌드되었기 때문에, 어드민 페이지인 http://localhost:3001/ghost/ 에 접속하여 계정을 생성하고, 글을 작성할수도 있다.

본 포스팅은 Ghost 에 대한 포스팅이 아니므로 이 과정은 생략하도록 하겠다. 궁금하다면 어드민 페이지에 접속해보고 여러가지 시도해보면 좋겠다.

리눅스 배포판, 웹서버, DB 서버, 블로깅 플랫폼 등 여러가지를 도커 명령 한줄로 세팅해보며 도커가 무엇인지, 도커가 왜 인기가 있는 것인지 직관적으로 이해할 수 있는 시간이 되었으면 좋겠다.

자주 쓰는 명령어

자주 사용되는 도커의 명령어를 알아보자.

docker run

위에서 알아보았듯 run 명령은 도커 이미지를 다운받고, 컨테이너를 실행하는 명령이다. 아래의 포맷을 갖는다.

$ docker run <옵션> <이미지 이름:태그> <명령어> <인자>

자주 사용되는 옵션은 아래와 같다.

옵션	설명
`-d`	컨테이너를 백그라운드에서 실행 (Detached Mode)
`-p`	호스트 포트와 컨테이너 내부의 포트를 바인드한다.
`-v`	컨테이너 내부의 디렉토리를 호스트로 마운트 (연결) 한다.
`-e`	컨테이너에서 사용되는 환경변수를 설정한다.
`--name`	컨테이너의 이름을 설정한다.
`--rm`	컨테이너가 종료될 경우 컨테이너 자체를 삭제한다.
`-it`	터미널 입력을 위한 옵션. `-i` 옵션과 `-t` 옵션은 주로 함께 사용된다.
`-w`	WORKDIR 를 설정한다.

docker ps

현재 실행되고 있는 컨테이너를 확인한다.

$ docker ps <옵션>

-a 옵션을 붙이면 Stop 상태의 컨테이너도 볼 수 있다.

docker stop

실행중인 컨테이너를 중지한다.

$ docker stop <옵션> <컨테이너 이름> <컨테이너 이름...>

docker rm

컨테이너를 제거한다.

$ docker rm <옵션> <컨테이너 이름> <컨테이너 이름...>

docker logs

컨테이너에 기록된 로그를 확인할 수 있다.

$ docker logs <옵션> <컨테이너 이름>

-f 옵션을 사용하면, 로그를 일회성으로 보여주고 끝내지 않고 기다리며 새롭게 발생한 로그도 출력해준다.

docker images

현재 설치된 이미지 리스트를 출력한다.

$ docker images <옵션> <레포지토리 이름>

레포지토리를 넘겨주면 특정 레포지토리의 이미지만 필터링하여 볼 수 있다.

docker rmi

현재 설치된 이미지를 제거한다.

$ docker rmi <옵션> <이미지 이름> <이미지 이름...>

docker pull

이미지를 도커 레지스트리로부터 다운로드한다. run 명령을 사용할 때, 대상 이미지가 설치되지 않은 이미지일 경우 자동으로 pull 해준다.

$ docker pull <옵션> <이미지 이름:태그>

도커 컴포즈 (Docker Compose)

지금까지 우리는 도커를 모두 CLI 으로 조작했다. 물론 간단한 작업은 명령어만 사용해서 조작해도 상관없다. 하지만 컨테이너를 실행할때마다 모든 옵션을 넣어주고, 환경변수를 입력해주는 것은 귀찮다. 이를 해결하기 위해 도커에서는 도커 컴포즈 (Docker Compose) 라는 것을 제공한다. 도커 컴포즈는 여러 컨테이너를 모아 하나의 어플리케이션을 구성할 때 사용된다.

도커 컴포즈는 도커 데스크톱을 설치하면 기본으로 제공된다. 리눅스 환경인 경우 도커 공식 웹사이트 를 참고하여 설치하자.

버전확인

아래의 명령을 입력하여 도커 컴포즈 버전이 출력되면 제대로 설치가 되었다는 의미이다.

$ docker-compose version

docker-compose version 1.29.2, build 5becea4c
docker-py version: 5.0.0
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1h  22 Sep 2020

MySQL 컨테이너 실행하기

이번엔 도커 컴포즈를 이용하여 Wordpress 서버를 실행해볼 것이다. 일단, MySQL 컨테이너를 실행해보자. 도커 컴포즈 설정 파일은 YAML 포맷을 사용하여 작성한다. 적당한 디렉토리에서 docker-compose.yml 파일을 생성하고 아래의 내용을 입력해보자.

version: '3' # docker-compose 파일 규격 버전
services:
  mysql-db: # 컨테이너 이름
    image: mysql:5.7 # 이미지
    volumes: # -v 옵션
      - ./mysql:/var/lib/mysql
    environment: # -e 옵션
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

첫번째로 version 는 도커 컴포즈 파일의 규격버전을 명시한다. “3” 을 입력하였으므로, 3.X 버전대의 가장 최신 버전을 사용하게 된다. 관련된 자세한 내용은 도커 공식 웹사이트의 가이드 문서를 참고하자.

그 아래로는 services 를 명시하게 된다. 서비스란 도커 컴포즈에서 컨테이너를 의미한다. 우리는 MySQL 의 서비스 이름을 mysql-db 로 정했다. 컨테이너 이름 다음으로 올 것은 우리가 docker run 을 실행하며 넣어준 여러 옵션을 YAML 포맷으로 넣어주면 된다.

이제 docker-compose.yml 이 있는 디렉토리에서 터미널로 아래 명령을 입력하여 컨테이너를 실행하자.

$ docker-compose up

이미지를 Pull 하고 컨테이너가 실행되면 성공이다.

M1 맥북 사용자는 위 명령이 제대로 작동하지 않을 것 이다. 맥북 사용자는 도커 컴포즈 파일의 environment 옵션 아래에 platform: linux/x86_64 를 추가하자.

Wordpress 컨테이너 실행하기

Wordpress 를 실행할 새로운 서비스를 추가하자. docker-compose.yml 에 아래 내용을 이어서 작성하자.

services:
  # ...
  wordpress:
    image: wordpress:latest
    volumes:
      - ./wordpress-html:/var/www/html
    ports:
      - 3000:80
    restart: always
    environment:
      WORDPRESS_DB_HOST: mysql-db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress

다시 docker-compose up 명령으로 실행해보자. 그리고 localhost:3000 에 접속하여 워드프레스가 제대로 동작하는지 확인해보자. 워드프레스 설치와 사용방법은 워드프레스 공식 문서 를 확인하자.

그런데, 환경변수를 살펴보면 WORDPRESS_DB_HOST 에 IP 주소나 도메인 대신 mysql-db 를 넣은 것을 알 수 있다. IP 주소를 넣어주지 않았는데, 어떻게 Wordpress 와 MySQL 은 정상적으로 통신할 수 있는 것 일까? 이를 이해하기 위해서는 도커 네트워크에 대해 이해해야한다.

도커 네트워크

도커는 컨테이너에 내부 IP 를 순차적으로 할당한다. 이 IP 는 컨테이너가 실행될 때 마다 달라진다. 하지만 우리가 워드프레스와 MySQL 컨테이너를 함께 실행한 것을 생각해보자. 워드프레스의 환경변수를 MySQL 컨테이너를 실행할때마다 바꿔주는 것은 매우 번거로운 일이다.

도커 네트워크는 실행 중인 각각의 컨테이너를 연결하는 논리적인 네트워크이다. 같은 네트워크로 연결된 컨테이너는 별도의 IP 를 지정해줄 필요 없이 컨테이너의 이름만으로 손쉽게 통신할 수 있다.

그런데, 우리는 별도의 네트워크를 생성하고 설정한 적이 없다. 그렇다면 어떻게 MySQL 과 Wordpress 컨테이너끼리 통신을 하는것일까?

기본적으로 도커 컴포즈를 사용해 여러 컨테이너를 올리면, 사용자가 별도의 네트워크를 생성하고 설정하지 않아도 <디렉토리 이름>_default 라는 네트워크를 생성하고 컨테이너를 연결한다. 따라서 최초로 docker-compose up 하였을 때, 아래 메세지가 출력되는 것을 확인해볼 수 있다.

Creating network "<디렉토리 이름>_default" with the default driver

도커 네트워크에 대한 깊은 내용은 별도의 포스팅으로 다뤄보겠다. 지금은 도커 컴포즈를 사용하며, 컴포넌트 간 통신이 네트워크를 통해 이뤄지고 있다는 것만 이해하고 넘어가자.

도커 이미지 빌드하기 (Dockerfile)

지금까지는 다른사람이 빌드해 놓은 이미지를 다운로드 받아서 사용하기만 했다. 이제는 우리가 직접 간단한 node.js 앱을 작성하고, 도커 이미지로 빌드해보자. node.js 를 배운적이 없다면, node.js 부분은 이해하지 않고 그냥 따라서 작성만해도 괜찮다.

node.js 프로젝트 생성

일단 도커라이징할 node.js 서버를 아주 간단하게 작성해보자. 적절한 디렉토리를 생성하고 아래 과정을 따라오자.

$ npm init && npm install express

먼저 node.js 앱을 초기화해주고, 웹서버 작성을 위한 express 프레임워크를 설치한다. 그 다음 server.js 파일을 생성한 다음 아래 코드를 그대로 작성한다.

const express = require('express');

const PORT = 8080;
const HOST = '0.0.0.0';

const app = express();
app.get('/', (req, res) => {
  res.send('Hello Docker');
});

app.listen(PORT, HOST);
console.log(`Running on http://${HOST}:${PORT}`);

우리가 빌드할 간단한 서버가 완성되었다.

Dockerfile 작성

이미지를 빌드하기 위해서는 Dockerfile 이라는 파일을 작성해야한다. Dockerfile 은 도커 이미지를 빌드하기 위한 스크립트 파일이다. 도커는 Dockerfile 을 읽고 순차적으로 명령을 실행하여 이미지를 빌드한다.

# 사용할 이미지 입력
FROM node:16.13.2

# 작업디렉토리 설정
WORKDIR /usr/src/app

# 앱 의존성 설치
COPY package*.json ./
RUN npm install

# 앱 소스 추가
COPY ./server.js ./server.js

EXPOSE 8080
CMD [ "node", "server.js" ]

FROM 에 명시된 이미지를 베이스로 작성된 스크립트가 순차적으로 실행되며, 새로운 이미지가 빌드된다. WORKDIR 을 통해 컨테이너의 작업 디렉토리를 설정했다. 모든 명령이 WORKDIR 경로를 기준으로 실행된다.

COPY 를 통해 npm 패키지 관련 파일을 복사하였고, RUN 명령을 통해 npm install 명령을 직접 실행해 node.js 의 의존성 모듈을 설치하였다. 또한 COPY 명령을 다시한번 사용해 현재 디렉토리의 server.js 를 이미지로 복사한다.

EXPOSE 를 통해 외부로 8080 포트를 노출한다. 마지막으로 CMD 를 통해 컨테이너가 실행된 직후 실행될 명령도 정의해주면 끝이다. RUN 은 이미지 빌드 단계에서 실행되는 명령이고, CMD 는 컨테이너가 실행된 이후 실행될 명령을 정의한다.

Dockerfile 은 파일이므로 Git 을 통해 관리 가능하여 이미지 변화 히스토리를 추적할 수 있다.

자세한 Dockerfile 사용 방법을 알고싶다면, 도커 공식 웹사이트 문서 를 참조하자.

이미지 빌드하기

$ docker build -t node-app ./

위 명령을 입력하여 Dockerfile 을 기반으로 이미지를 빌드할 수 있다.

-t node-app 은 이미지의 이름을 설정하는 옵션이며, ./ 은 Dockerfile 의 경로를 나타낸다. 빌드 과정은 다소 오랜 시간이 소요되니 조금 기다리자.

$ docker images

REPOSITORY              TAG              IMAGE ID       CREATED          SIZE
node-app                latest           401a74e859b2   39 seconds ago   855MB
...

위 명령으로 성공적으로 이미지가 빌드되어 node-app 이미지가 조회되는지 확인해보자.

$ docker run -p 3000:8080 node-app

이미지가 조회된다면, 위 명령으로 도커 컨테이너를 실행할 수 있을 것이다.

도커 이미지의 레이어 구조

마지막으로 도커 이미지의 구조에 대해서 가볍게 이해하고 넘어가자.

도커 이미지는 위 그림과 같이 여러개의 Layer 가 겹겹히 쌓여있는 구조로 되어있다. 과연 정말인지 직전에 설치해둔 Wordpress 이미지로 확인해보자.

$ docker inspect wordpress

inspect 명령은 Low Level 에서 컨테이너 혹은 이미지의 정보를 가져오는 명령이다. 굉장히 긴 무언가가 출력될 텐데, Layers 라는 부분만 살펴보자.

"Layers": [
	"sha256:f9b44a5812beb5294f1cf3b76cf9c29f1e53bf8eec7cece1b002fc5b5fbae8f2",
	"sha256:243aed6552599c7fb8a7939cef784eb2f84ce49708cefe11cf1057f2a27ba42f",
	"sha256:4d66bbee2601b1b779aedfe699c91920d637a5f51f91e87c1c04c3bbe9be34a4",
	"sha256:45dad0035575a38c893da7e0e9f394f2b4a2407b9694e21b53cbdf462c7a8a5b",
	"sha256:a8ccc2628dd85db2b3648ebddef84047a402104dbeeb14958514fd136aa19813",
	"sha256:8857c07576848e6d0b2416c84c561b0591536ccd6900cc7b653bdc2186025145",
	"sha256:6a7f6ea65ec22a59eb3361c2944edfee08d042ec49fbcbbadd8ac1516ac53b04",
...

위와 같이 이미지가 굉장히 많은 레이어로 구성되어 있는 모습을 살펴볼 수 있다. 도커를 통해 내려받은 이미지를 구성하는 레이어는 모두 읽기 전용이다.

위 이미지처럼 도커 이미지는 Dockerfile의 FROM 에 명시한 베이스 이미지 위에 또 다른 레이어가 얹혀져 빌드된다.

도커 허브에 배포하기

그런데, 우리가 다운로드한 이미지는 어디서 오는 것 일까? 우리가 다운로드한 이미지는 모두 도커 레지스트리 (Docker Registry) 로부터 온다. 도커 레지스트리란 도커 이미지를 관리하는 저장소를 의미한다.

도커 레지스트리 중 가장 유명한 것은 도커에서 공식으로 운영하는 도커 허브 (Docker Hub) 이다. 이제, 우리가 빌드한 이미지를 도커 허브에 배포하여 누구나 이미지를 Pull 받을 수 있도록 해보자. 일단 가장 먼저 도커 허브에 가입해야한다. 도커 허브 가입 과정은 생략한다.

도커 허브에 가입했다면, 이제 본격적으로 도커 허브에 우리의 이미지를 배포해보자. 그 전에 이미지의 이름을 조금 수정할 필요가 있다. 도커 허브에 이미지를 배포할 때에는 만들어둔 이미지의 이름을 사용자명(소문자)/이미지명:태그 형태로 바꿔야한다.

$ docker tag node-app <사용자명>/node-app

위 명령으로 이미지 이름을 변경하자. 반드시 사용자명은 모두 소문자로 입력하자.

$ docker login

위와 같이 입력하여 도커 허브에 먼저 로그인하자.

$ docker push <사용자명>/node-app

위 명령으로 도커 허브의 자신의 레포지토리에 이미지를 업로드할 수 있다.

$ docker rmi <사용자명>/node-app
$ docker run <사용자명>/node-app

이제 제대로 우리의 이미지가 업로드 됐는지 확인하기 위해 로컬에 설치된 이미지를 제거하고, 도커 허브에 등록된 이미지를 run 해보자. 제대로 node.js 앱이 실행된다면 성공이다.

참고

이미지 출처

https://pixabay.com/ko/photos/%ed%8f%ac%ed%8a%b8-%ec%bb%a8%ed%85%8c%ec%9d%b4%eb%84%88-%ec%84%a0%eb%b0%95-%eb%b0%a4-7418239/

트랜잭션 내에 외부 리소스 요청이 담기게 되면 어떤 문제가 발생할까?

Tue, 20 Sep 2022 00:00:00 GMT

트랜잭션 처리를 위해서는 데이터베이스와 통신하기 위한 커넥션이 필요하다. 하지만 커넥션 생성을 위해서 많은 비용이 필요하다. 이러한 비용을 절감하기 위해 커넥션을 미리 생성한 뒤 커넥션 풀을 통해 관리한다.

커넥션 풀의 개수는 제한되어 있다. 만약 동시에 데이터베이스 처리 로직이 담긴 요청을 커넥션 풀의 개수 이상으로 받았다고 가정하자. 커넥션을 획득하지 못한 요청은 다른 데이터베이스 커넥션이 반납될 때까지 기다리게 될 것이다. 결국 이러한 상황이 길어지면 병목 현상이 발생하게 된다.

불필요한 로직이 섞인 트랜잭션

먼저 간단한 예시를 위해 아래와 같은 요구사항을 줬다고 가정한다.

회원가입을 진행한다.
회원가입은 외부 OAuth를 통해 진행된다.
우리는 전달받은 인가 코드를 기반으로 회원 정보를 조회한 뒤 회원가입을 진행한다.
회원가입이 완료되면 NEWBIE라는 칭호를 획득할 수 있다. (회원은 여러 개의 칭호를 가질 수 있다고 가정한다. 회원 : 칭호 = 1 : N)
회원가입이 완료되면 가입한 email을 통해 가입 완료 메일을 전송한다.

위 과정을 코드로 표현하면 아래와 같다.

@RequiredArgsConstructor
@Service
public class MemberService {

    private static final String NEWBIE = "뉴비";
    private static final String CONGRATULATIONS_MESSAGE = "가입을 축하드립니다!";

    private final MemberRepository memberRepository;
    private final HonorRepository honorRepository;
    private final OAuthClient oAuthClient;
    private final EmailSender emailSender;

    @Transactional
    public Member register(final String code) {
        Member member = oAuthClient.getMember(code); // 1

        Member savedMember = memberRepository.save(member); // 2
        honorRepository.save(new Honor(savedMember, NEWBIE)); // 3

        emailSender.send(savedMember.getEmail(), CONGRATULATIONS_MESSAGE); // 4

        return savedMember;
    }
}

1: 외부 서비스에서 인가 코드를 전달하여 회원 정보를 조회한다.
2: 조회한 회원 정보를 기반으로 저장한다.
3: 가입과 동시에 NEWBIE 칭호를 획득한다.
4: 가입 축하 메일을 전송한다.

이 모든 과정은 하나의 논리적인 작업 단위이기 때문에 하나의 트랜잭션으로 묶여 진행된다.

위 로직 중 데이터베이스 트랜잭션이 실질적으로 사용되는 부분은 어디일까? 바로 2, 3이다. MemberRepository와 HonorRepository는 member와 honor를 적절히 영속시키기 위해 데이터베이스 커넥션을 활용한다. 외부 서비스를 통해 회원 정보를 조회하는 1과 메일을 전송하기 위한 4는 데이터베이스와 관련된 처리가 아니므로 데이터베이스를 활용한 트랜잭션이라 보기 어렵다.

또한 외부 서비스는 우리가 제어할 수 없는 영역에 가깝다. 데이터베이스의 커넥션과 요청 처리를 위한 스레드는 외부 서비스에서 적절한 응답이 올 때까지 계속 대기해야 한다. 특히 데이터베이스의 커넥션은 한정된 개수를 가지고 있다. 대기 시간이 길어질수록 병목 현상이 발생할 가능성이 커진다.

위 코드를 그림으로 표현하면 아래와 같다.

실질적으로 데이터베이스의 트랜잭션이 필요한 부분은 파란 화살표지만, 데이터베이스 커넥션을 사용하지 않는 시간까지 불필요하게 낭비되고 있는 것을 확인할 수 있다.

외부 리소스 요청 로직 분리하기

트랜잭션은 필요한 부분에 최소한으로 적용되어야 하므로, 제어할 수 없는 외부 요청 로직을 분리해야 한다. 먼저 작성된 코드에서 트랜잭션이 필요한 로직만 남겨둔다.

@RequiredArgsConstructor
@Service
public class MemberService {

    private static final String NEWBIE = "뉴비";
    private static final String CONGRATULATIONS_MESSAGE = "가입을 축하드립니다!";

    private final MemberRepository memberRepository;
    private final HonorRepository honorRepository;

    @Transactional
    public Member save(final Member member) {
        Member savedMember = memberRepository.save(member);
        honorRepository.save(new Honor(savedMember, NEWBIE));
        return savedMember;
    }
}

트랜잭션이 불필요한 로직을 상위 클래스로 분리하여 작성한다.

@RequiredArgsConstructor
@Component
public class MemberRegister {

    private static final String CONGRATULATIONS_MESSAGE = "가입을 축하드립니다!";

    private final MemberService memberService;
    private final OAuthClient oAuthClient;
    private final EmailSender emailSender;

    public Member register(final String code) {
        Member member = oAuthClient.getMember(code);
        Member savedMember = memberService.save(member);
        emailSender.send(savedMember.getEmail(), CONGRATULATIONS_MESSAGE);
        return savedMember;
    }
}

기존에 memberService를 호출하던 부분을 memberRegister를 의존하도록 변경한다.

@RequiredArgsConstructor
@RequestMapping("/members")
@RestController
public class MemberController {

    private final MemberRegister memberRegister;

    @PostMapping
    public ResponseEntity<MemberResponse> register(@RequestBody MemberRegisterRequest request) {
        Member savedMember = memberRegister.register(request.getCode());
        MemberResponse response = new MemberResponse(savedMember);
        return ResponseEntity.ok(response);
    }
}

위 로직을 그림으로 표현하면 아래와 같다.

불필요하게 낭비되던 데이터베이스 커넥션 유지 시간이 줄어든 것을 확인할 수 있다.

정리

지금까지 트랜잭션 내의 외부 리소스 요청에 대한 로직을 분리해야 하는 이유와 방법에 대해 간단히 알아보았다.

제어할 수 없는 영역인 외부 리소스에 대한 요청을 트랜잭션에서 분리하지 않으면 응답이 올 때까지 요청 스레드가 대기하게 된다. 이때 요청에 데이터베이스 로직이 포함되면 커넥션도 함께 대기하게 된다. 한정된 개수를 가진 커넥션을 빠르게 반납하지 않으면 병목 현상이 일어날 수 있다.

이런 상황을 피하기 위해서는 트랜잭션이 활성화된 범위를 최소화해야한다. 이러한 개선 작업을 통해 불필요하게 낭비되는 서버 자원을 적절히 아낄 수 있다.

Referernces.

구구의 Servlet & Servlet Container 강의
백은빈, 이성욱 지음, 『Real MySQL 8.0』 (위키북스, 2021), 158-160.

이미지 스토리지 서버 구축 및 최적화

Tue, 13 Sep 2022 12:00:00 GMT

레벨 3 프로젝트 과정 중 이미지 서버를 개발하고 개선해나가는 과정을 이야기하려 합니다.

왜 이미지 서버를 만들어야 하는가?

레벨 3 프로젝트인 공책에서는 특정 공간에 관해서 설명하는 이미지를 올려 보여주어야 합니다. 글보다는 이미지를 제공함으로써 처음 보는 공간에 대해서도 가시적으로 확인하기 쉽게 하기 위함이죠.

이에 따라 공간의 관리자가 특정 공간을 추가할 때 본인이 원하는 이미지를 올려야 하기 때문에 서버 측에서 이미지를 저장할 수 있도록 하는 기능이 필요했습니다.

기존에 이미 RDB를 사용하고 있었기 때문에 이미지 데이터를 단순히 binary로 전환하여 RDB에 저장하는 방법을 고려했었습니다. 다만 아래의 문제점이 거론되었어요.

binary 로 관리하게 되는 경우 너무 큰 데이터 파일로 인하여 관리가 힘들다.
binary의 크기가 크기 때문에 입출력 시 database에 병목현상이 발생하여 다른 데이터에 영향을 준다.

저희 팀에서는 이런 문제점을 고려하여 이미지 스토리지 서버를 따로 두어 관리하는 방향으로 결정하였습니다.

이미지 스토리지 서버

이미지 스토리지 서버는 MVP로 개발했기 때문에 아래의 두 가지 기능만을 제공하고 있었습니다.

이미지를 업로드한다.
이미지를 제공한다.

따라서 업로드할 수 있는 웹 애플리케이션 서버(WAS)와 업로드된 이미지를 제공할 수 있는 웹 서버(WS)를 구축하였습니다.

MVP(Minimum Viable Product): 고객의 피드백을 받아 최소한의 기능(features)을 구현한 제품

인증된 사용자만 사용할 수 있게끔 다른 처리는 해두었지만, 대체적인 구조는 위와 같습니다.

// image upload api
@PostMapping("/api/image-upload")  
public ResponseEntity<String> uploadImage(@RequestPart MultipartFile file) {  
  
    ImageSaveResponse imageSaveResponse = imageService.storeImage(file);  
    return ResponseEntity.ok(imageSaveResponse.getImagePath());  
}

이미지 파일을 HTTP 메시지 바디에 담아 이미지를 업로드하는 API를 호출하면, 서버에서는 MultipartFile 타입으로 이미지를 받아 저장하고, 이미지의 경로를 반환합니다. 이후에는 해당 경로를 통해 이미지를 요청하게 됩니다.

Nginx 설정은 nginx.conf 혹은 include한 서버 설정 파일을 통해 설정할 수 있습니다.

server {
	server_name image.gongcheck.shop;

	location /images {
		alias /home/ubuntu/images/;
	}

	# ...
}

WS(nginx)에서는 요청받은 이미지 경로를 통해 이미지를 반환합니다.

단순 이미지 업로드 서버로서의 문제점

위의 이미지 서버는 단순히 이미지 업로드와 이미지 제공만을 담당하고 있습니다. 잘 운영되고 있다는 생각 중에 운영상황에서 문제를 발견합니다.

원본 이미지를 저장하다보니 이미지의 크기가 너무 커서 이미지 로딩 시간이 너무 길다.

위 스크린샷은 저희 서비스에서 여러 이미지 파일을 요청하는 페이지를 요청할 때 걸리는 시간들을 나타내고 있습니다.

위처럼 로딩하는데 최대 8.59 초까지 걸리는 이미지도 존재합니다. 이 문제가 단순히 네트워크 환경의 문제인지 이미지 크기의 문제인지 객관적으로 판단하기 위해 웹 페이지 성능 분석 도구인 lighthouse를 통해 확실한 지표를 확인해보았습니다.

여러 지표 중 이미지와 관련된 지표를 보면 다음과 같습니다.

이미지의 크기를 사용하는만큼 줄여서 사용하여야 한다.
이미지 파일 형식을 webp로 전환하여야 한다.

WebP: 웹사이트의 트래픽 감소 및 시간 단축을 겨냥해 만들어진 이미지 포맷으로, 2010년 9월 구글이 공개하였다.

화면에 필요한 만큼의 크기가 아니라 원본 이미지의 크기를 그대로 사용하기 때문에 이미지를 최적화하여 전달받아야 조금 더 빠르다는 것입니다. 또한 기존의 이미지를 webp 확장자로 변환하여 더 좋은 이미지 압축률을 가진 파일 형식을 제공하도록 하자라는 것이죠.

정확한 리포트를 전달받았으니 이제는 서버를 고칠 차례입니다. 클라이언트에게 하나의 이미지 파일에 대해 여러가지 크기의 이미지를 제공할 수 있도록 서버 내부에는 원본 이미지 파일을 저장한 후, 클라이언트가 요청한 크기에 맞게 이미지를 변환하여 webp 확장자로 반환하도록 설계했습니다.

@GetMapping("/api/resize/{imageUrl}")  
public ResponseEntity<byte[]> getResizeImage(@PathVariable String imageUrl,  
                                             @RequestParam(required = false, defaultValue = DEFAULT_RESIZE_WIDTH) int width,  
                                             @RequestParam(required = false, defaultValue = DEFAULT_WEBP) boolean webp) {  
    ImageResponse response = imageService.resizeImage(imageUrl, width, webp);  
    return ResponseEntity.ok()  
            .contentType(response.getContentType())  
            .body(response.getBytes());  
}

변경하고자 하는 크기의 가로 길이를 입력받고, webp로 변환할지 말지 여부를 입력받습니다. 여기에서 webp에 대한 반환 여부를 넣은 이유는 브라우저마다 호환 여부가 다른데요. 프론트 페이지에서 이를 판단하여 호환되는 곳에서만 webp를 반환하게 하기 위해 이렇게 API를 설계했습니다.

webp와 관련된 변환 로직은 대표적으로는 2가지가 있습니다. C로 작성된 코덱 파일을 이용하여 활용하는 방법과 이를 래핑한 바이너리 파일을 실행하는 방법인데요. 해당 api 내에서는 바이너리 파일을 실행하는 방법을 사용하였으며 본 포스팅에서는 다루지 않습니다.

이제 이미지 크기로 인한 문제를 해결했습니다. 이미지도 잘 업로드하고 있고, 이미지 크기에 맞게 최적화된 이미지를 전달해주고 있기 때문입니다. 그러나 클라이언트가 이미지를 요청할 때마다 크기를 변환하는 로직을 수행해야한다는 새로운 문제가 발생하였습니다.

이미지 서버 최적화

이러한 문제를 해결하고자 캐싱과 etag를 적용하였습니다.

nginx를 이용한 캐싱

저희 팀은 Nginx의 reverse proxy cache 기능을 활용하기로 결정했습니다.

Nginx에서는 특정 요청에 대해서 중간에 처리를 해줄 수 있는 reverse proxy 서버와 처리된 요청을 캐싱할 수 있는 기능을 제공합니다. 이를 이용하여 저희는 WAS에서 반환된 자원을 Nginx에 캐싱하도록 만들었습니다.

(4)에서 캐싱된 이미지는 이후 같은 요청이 들어올 때, WAS까지 가지 않고 바로 Nginx에서 처리해줄 수 있습니다.

proxy_cache_path /home/ubuntu/cache levels=1:2 keys_zone=my_zone:20m inactive=60m;
proxy_cache_key "$scheme$request_method$host$request_uri";

server {
	server_name image.gongcheck.day;

	location ~* ^/images/(.*)\.(?:png|gif|jpg|jpeg)$ {
		rewrite ^/images/(.*)$ /api/resize/$1 break;

		proxy_cache my_zone;
        add_header X-Proxy-Cache $upstream_cache_status;
		expires 1M;

        include /etc/nginx/proxy_params;
		proxy_pass http://localhost:8080;
	}
	
	#...

간단하게 저희팀에서 사용하는 nginx의 conf를 살펴보겠습니다.

proxy_cache_path : 캐싱할 데이터를 저장할 경로를 설정합니다. 데이터를 저장할 크기, 캐시 레벨 등을 설정할 수 있습니다.
proxy_cache_key : 캐싱할 요청의 key입니다. 동일한 key라면 동일한 값을 반환합니다.
location : 유저가 요청한 URI를 원하는 경로로 매핑하기 위한 설정을 정의합니다.
rewrite : WAS로 전달하기 위해 요청을 api 스펙에 맞게 수정하여 reverse proxy 요청합니다.
add_header X-Proxy-Cache : header에 cache 상태를 반환합니다.
proxy_pass : reverse proxy 전달할 서버 url입니다.

이렇게 Nginx의 reverse proxy cache를 활용하여 불필요한 요청이 WAS로 넘어가지 않도록 만들었습니다.

Http Header를 이용한 캐싱 적용

이미지는 브라우저단에서 캐싱되어 사용될 수도 있습니다. 현재 정적 파일에 대해 필요한 범위에 따라 Cache-Control을 조절하여 브라우저에서 어떻게 캐싱하여 사용할 것인지를 판별할 수 있습니다.

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>

(출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control)

저희 서비스의 경우 이미지 파일이 수정될 일이 거의 없기 때문에 no-cache 값을 사용하지 않고 max-age로 최소한의 갱신 기간만 설정하였습니다.

만료 기간이 다 되었을 경우 WAS로 다시 리소스를 요청하게 됩니다. 하지만 만료 기간이 다 되었음에도 리소스에 변경 사항이 없다면 어떨까요? 굳이 WAS로 다시 요청할 필요 없이 브라우저에 캐시된 값을 사용하도록 만들면 됩니다. etag를 사용하면 이를 구현할 수 있습니다.

이미지마다 etag를 만들어서 반환한다면 이미지에 대한 특정 식별자가 생깁니다. HTTP 통신 시 해당 식별자의 컨텐츠가 변경되었는지 아닌지를 판단할 수 있습니다. 이렇게 WAS에서 이미지에 대한 반환 값으로 etag를 달아주면, max-age가 지난 후에 다시 요청이 올 때, 만약 해당 컨텐츠가 수정되지 않았다면 WS가 304 응답을 통해 브라우저의 캐시를 사용하도록 만들 수 있습니다.

개선된 결과물

글 초반부에서 이미지가 최악의 상황에는 8초가 걸렸던 것을 기억하시나요?

이미지 스토리지 서버 최적화를 통해 평균적으로 초 단위가 걸리던 응답을 10ms대로 줄일 수 있었습니다.

마무리

많은 개선이 이루어졌지만, 아직도 풀어나가야 할 과제들이 많습니다. 하나의 인스턴스 내에 WS와 WAS가 공존하고 있어서 이를 분리해야 하고, 이미지 스토리지를 확장하게 된다면 어떻게 경로 설정을 하고 캐싱을 할 것 인지 등을 고민해야할 것 같습니다.

아직 많이 부족한 글이지만 새롭게 이미지 서버를 개발하는 분들에게 도움이 되었으면 좋겠습니다. 감사합니다 🙇‍♂️

참고 자료

HashMap vs HashTable vs ConcurrentHashMap

Fri, 26 Nov 2021 12:00:00 GMT

이미지 출처: Top 35 Data Structure & Algorithms Interview Questions and Answers in 2021

각 자료구조는 필요에 따라 선택되고 활용된다. Map 인터페이스의 구현체로는 HashMap, HashTable, ConcurrentHashMap 등이 있다. Map 인터페이스를 구현하면, <Key, Value> 형태를 띈다. 그렇다면 이 셋은 무슨 특징을 가지고, 서로 어떤 차이가 있을까? 이번 글에서 해당 구현체를 비교하며 확인해보자.

HashMap

key와 value에 null을 허용한다.
동기화를 보장하지 않는다.

HashMap은 thread-safe하지 않아, 싱글 쓰레드 환경에서 사용하는 게 좋다. 한편, 동기화 처리를 하지 않기 때문에 데이터를 탐색하는 속도가 빠르다. 결국 HashTable과 ConcurrentHashMap보다 데이터를 찾는 속도는 빠르지만, 신뢰성과 안정성이 떨어진다.

public class HashMap<K,V> extends AbstractMap<K,V> implements Map<K,V>, Cloneable, Serializable {

    ...

    public V put(K key, V value) {
        return putVal(hash(key), key, value, false, true);
    }

    final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
        if ((p = tab[i = (n - 1) & hash]) == null)
            tab[i] = newNode(hash, key, value, null);
        else {
            Node<K,V> e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        if (binCount >= TREEIFY_THRESHOLD - 1)
                            treeifyBin(tab, hash);
                        break;
                    }
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            if (e != null) {
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
        if (++size > threshold)
            resize();
        afterNodeInsertion(evict);
        return null;
    }

    ...
}

HashTable

key와 value에 null을 허용하지 않는다.
동기화를 보장한다.

HashTable은 thread-safe하기 때문에, 멀티 쓰레드 환경에서 사용할 수 있다. 이는 데이터를 다루는 메소드(get(), put(), remove() 등)에 synchronized 키워드가 붙어 있다. 해당 키워드는 메소드를 호출하기 전에 쓰레드간 동기화 락을 건다. 그래서 멀티 쓰레드 환경에서도 데이터의 무결성을 보장한다. 그러나, 쓰레드간 동기화 락은 매우 느린 동작이라는 단점이 있다.

public class Hashtable<K,V> extends Dictionary<K,V> implements Map<K,V>, Cloneable, java.io.Serializable {

    ...

    public synchronized V put(K key, V value) {
        if (value == null) {
            throw new NullPointerException();
        }
        
        Entry<?,?> tab[] = table;
        int hash = key.hashCode();
        int index = (hash & 0x7FFFFFFF) % tab.length;
        @SuppressWarnings("unchecked")
        Entry<K,V> entry = (Entry<K,V>)tab[index];
        for(; entry != null ; entry = entry.next) {
            if ((entry.hash == hash) && entry.key.equals(key)) {
                V old = entry.value;
                entry.value = value;
                return old;
            }
        }

        addEntry(hash, key, value, index);
        return null;
    }

    ...
}

ConcurrentHashMap

key와 value에 null을 허용하지 않는다.
동기화를 보장한다.

ConcurrentHashMap은 thread-safe하기 때문에, 멀티 쓰레드 환경에서 사용할 수 있다. 이 구현체는 HashMap의 동기화 문제를 보완하기 위해 나타났다. 동기화 처리를 할 때, 어떤 Entry를 조작하는 경우에 해당 Entry에 대해서만 락을 건다. 그래서 HashTable보다 데이터를 다루는 속도가 빠르다. 즉, Entry 아이템별로 락을 걸어 멀티 쓰레드 환경에서의 성능을 향상시킨다.

public class ConcurrentHashMap<K,V> extends AbstractMap<K,V> implements ConcurrentMap<K,V>, Serializable {

    ...

    public V put(K key, V value) {
        return putVal(key, value, false);
    }

    final V putVal(K key, V value, boolean onlyIfAbsent) {
        if (key == null || value == null) {
            throw new NullPointerException();
        }
        int hash = spread(key.hashCode());
        int binCount = 0;
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh;
            if (tab == null || (n = tab.length) == 0)
                tab = initTable();
            else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
                if (casTabAt(tab, i, null,
                             new Node<K,V>(hash, key, value, null)))
                    break;
            }
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            else {
                V oldVal = null;
                synchronized (f) {
                    if (tabAt(tab, i) == f) {
                        if (fh >= 0) {
                            binCount = 1;
                            for (Node<K,V> e = f;; ++binCount) {
                                K ek;
                                if (e.hash == hash &&
                                    ((ek = e.key) == key ||
                                     (ek != null && key.equals(ek)))) {
                                    oldVal = e.val;
                                    if (!onlyIfAbsent)
                                        e.val = value;
                                    break;
                                }
                                Node<K,V> pred = e;
                                if ((e = e.next) == null) {
                                    pred.next = new Node<K,V>(hash, key,
                                                              value, null);
                                    break;
                                }
                            }
                        }
                        else if (f instanceof TreeBin) {
                            Node<K,V> p;
                            binCount = 2;
                            if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
                                                           value)) != null) {
                                oldVal = p.val;
                                if (!onlyIfAbsent)
                                    p.val = value;
                            }
                        }
                    }
                }
                if (binCount != 0) {
                    if (binCount >= TREEIFY_THRESHOLD)
                        treeifyBin(tab, i);
                    if (oldVal != null)
                        return oldVal;
                    break;
                }
            }
        }
        addCount(1L, binCount);
        return null;
    }

    ...
}

정리

	HashMap	HashTable	ConcurrentHashMap
key와 value에 null 허용	O	X	X
동기화 보장(Thread-safe)	X	O	O
추천 환경	싱글 쓰레드	멀티 쓰레드	멀티 쓰레드

결론

싱글 쓰레드 환경이면 HashMap을, 멀티 쓰레드 환경이면 HashTable이 아닌 ConcurrentHashMap을 쓰자. 그 이유는 HashTable보다 ConcurrentHashMap이 성능적으로 우수하기 때문이다. 앞에서도 언급했듯이 HashTable은 쓰레드간 락을 걸어 데이터를 다루는 속도가 느리다. 반면, ConcurrentHashMap은 Entry 아이템별로 락을 걸어 데이터를 다루는 속도가 빠르다.

References

HashMap, HashTable, ConcurrentHashMap 내부 코드
Hashtable, HashMap, ConcurrentHashMap 비교
[Java] HashTable, Hashmap, ConCurrentHashMap 차이
HashMap, Hashtable, ConcurrentHashMap 동기화 처리 방식

SpringBoot 존재하지 않는 API 요청의 응답 커스마이징하기

Wed, 24 Nov 2021 12:00:00 GMT

SpringBoot 에서 존재하지 않는 api 요청에 대한 에러메시지를 커스터마이징한 과정을 소개한다.

배경

프로젝트를 진행하면서 api의 url을 실수로 잘못 입력했을 때, 에러의 원인을 확인하지 못해 디버깅 과정에 많은 시간을 사용했다.

이런 상황에 해당하는 적절한 에러 메시지를 응답해야 한다 생각했고, 코드를 하나씩 분석하기 시작했다.

DispatcherServlet 들여다보기

DispatcherServlet의 doDispatch 메소드를 확인해보면, mappedHandler가 존재하지 않은 때, noHandlerFound 메소드가 실행된다. 메소드 내부를 보면 throwExceptionIfNoHandlerFound에 값에 따라, Exception을 throw하는 지의 여부가 결정된다. 기본 설정은 false 이기 때문에 프론트 404의 응답만을 보냈다.

public class DispatcherServlet {
  protected void doDispatch(...) throws Exception {
      // Determine handler for the current request.
      mappedHandler = getHandler(processedRequest);
      if (mappedHandler == null) {
          noHandlerFound(processedRequest, response);
          return;
      }
  }
  
  protected void noHandlerFound(HttpServletRequest request, HttpServletResponse response) throws Exception {
    if (this.throwExceptionIfNoHandlerFound) {
      throw new NoHandlerFoundException(request.getMethod(), getRequestUri(request),
        new ServletServerHttpRequest(request).getHeaders());
    }
    else {
      response.sendError(HttpServletResponse.SC_NOT_FOUND);
    }
  }
}

그렇다면 해당 설정을 true로 바꿔주면 간단하게 해결할 수 있을 것으로 보인다. 이 설정은 어디서 진행될까?

DispatcherServletAutoConfiguration 설정 확인하기

Springboot에서는 이런 상황을 미리 예견했다는 듯이, 이와 관련한 설정을 모두 진행할 수 있도록 작성되어있다. setThrowExceptionIfNoHandle메소드가 사용되는 곳을 확인하면 DispatcherServletAutoConfig에서 DispatcherServlet Bean을 생성할 때 적용한다. 또 이는 WebMvcProperties의 properties에 따라 설정되는 것을 확인할 수 있다.

// DispatcherServletAutoConfiguration
@Bean(name = DEFAULT_DISPATCHER_SERVLET_BEAN_NAME)
public DispatcherServlet dispatcherServlet(WebMvcProperties webMvcProperties) {
  DispatcherServlet dispatcherServlet = new DispatcherServlet();
  dispatcherServlet.setDispatchOptionsRequest(webMvcProperties.isDispatchOptionsRequest());
  dispatcherServlet.setDispatchTraceRequest(webMvcProperties.isDispatchTraceRequest());
  dispatcherServlet.setThrowExceptionIfNoHandlerFound(webMvcProperties.isThrowExceptionIfNoHandlerFound());
  dispatcherServlet.setPublishEvents(webMvcProperties.isPublishRequestHandledEvents());
  dispatcherServlet.setEnableLoggingRequestDetails(webMvcProperties.isLogRequestDetails());
  return dispatcherServlet;
}

WebMvcProperties 설정하기

@ConfigurationProperties(prefix = "spring.mvc")
public class WebMvcProperties {
  private boolean throwExceptionIfNoHandlerFound = false;
  // 생략
}

@ConfigurationProperties의 설정은 외부 properties에 prefix에 해당하는 값들을 읽어드려 사용할 수 있다. 즉, application.properties에 spring.mvc.throw-exception-if-no-handler-found=true의 설정을 진행하면 된다.

하지만, 이 경우에도 기존의 404의 에러메시지를 응답한다. 문제는 아직 해결되지 않았다.

ResourceHttpRequestHandler 가 매핑되고 있었다.

매핑된 핸들러가 없다고 생각하고, 코드만을 기반으로 지금까지의 작업을 진행했다. 실제로는 핸들러가 매핑되고 있었다.

DEBUG로그를 확인해본 결과, 존재하지 않는 api에 ResourceHttpRequestHandler 가 매핑되고 있었다. 즉, 기본적으로 해당하는 URL이 없으면 resource를 조회하도록 설계되어 있고, 존재하지 않았을 때 404의 에러 메시지를 응답하는 것이다.

모든 경우에서의 ResourceHandler 매핑 끄기

WebMvcAutoConfiguration의 addResourceHandler 메소드를 살펴보면 된다. ResourceProperties의 addMapping을 false로 설정하면 간단하게 해당 설정을 진행할 수 있다. SpringBoot의 버전에 따라, properties를 관리하는 방식이 다르므로 확인해보고 버전에 맞게 설정을 진행하면 된다.

2.3.3 버전: spring.resources.add-mappings=false
2.4.5 버전: spring.web.resources.add-mappings=false

만약, Resource에 접근하는 방식이 기존에 있었다면 별도로 이 설정을 진행해주어야 한다. 우리 팀 같은 경우, swagger를 사용했기 때문에 아래의 설정을 추가해주었다.

public class SwaggerConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("swagger-ui.html")
                .addResourceLocations("classpath:/META-INF/resources/");
        registry.addResourceHandler("/webjars/**")
                .addResourceLocations("classpath:/META-INF/resources/webjars/");
    }
}

NoHandlerFoundException 처리하기

지금까지 과정을 진행함으로써, 잘못된 url의 요청이 왔을 때 NoHandlerFoundException을 throw하도록 수정했다.

이를 아래처럼 ControllerAdvice의 @ExceptionHandler에서 처리하도록 로직을 구현하면 된다.

예외 처리가 어떤 방식으로 동작하는지 궁금한 분은 SpringBoot 예외 처리에 관한 고찰 을 확인해보기 추천한다.

@RestControllerAdvice
public class ControllerAdvice {
    @ExceptionHandler(NoHandlerFoundException.class)
    public ResponseEntity<ExceptionResponse> noHandlerFoundHandle(NoHandlerFoundException exception) {
        ExceptionResponse response = ExceptionResponse.of(exception.getMessage());
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(response);
    }
}

정리

존재하지 않는 url의 api의 응답을 커스터마이징 해보았다. DispatcherServlet에서의 코드를 분석해 가며 어떤 방식으로 상황을 해결해나갔는지의 과정을 보여주고 싶었다. 코드를 분석해 가며 문제 해결의 단계를 나눠가며 진행해보기를 추천한다.

웹어셈블리(WebAssembly)에 대해 알아보자

Wed, 24 Nov 2021 12:00:00 GMT

최근에 Developer-Roadmap을 둘러보다 웹어셈블리(WebAssembly)라는 개념에 대해 접하게 되었다.

웹 개발을 공부하는 입장에서 처음 접하는 용어에 대한 호기심이 생겼고, 이번 시간을 통해 웹어셈블리에 대해 함께 알아보려고 한다.

웹어셈블리

웹어셈블리는 2017년에 처음 발표되었고, 현재는 최신 브라우저에서 대부분 사용 가능하며 웹 표준으로 개발되고 있다. 일반적으로 웹 어플리케이션을 개발할 때에는 HTML, CSS, 자바스크립트를 사용하지만, 이들과 함께 웹어셈블리도 사용 가능하다.

웹어셈블리는 어떠한 ‘새로운 언어’가 아니다. MDN 문서를 보면 웹어셈블리에 대해 ‘최신 웹 브라우저에서 실행할 수 있는 새로운 유형의 코드’라고 설명하고 있다. 웹어셈블리 파일인 wasm은 직접 코드를 작성하는 것이 아니라 C, C ++, RUST 등의 언어를 컴파일하여 만들게 된다.

이를 통해 기존에 C, C ++, RUST 언어로 작성된 코드를 웹에서도 네이티브에 가까운 속도로 실행 가능하게 되었고, 자바스크립트만으로는 어려웠던 고성능의 애플리케이션도 구현할 수 있게 되었다.

웹어셈블리와 자바스크립트

웹어셈블리를 사용하면 기존에 자바스크립트만으로 개발하는 것보다 고성능의 애플리케이션을 구현할 수 있다고 한다. 이게 가능한 이유는 웹어셈블리와 자바스크립트가 브라우저에서 처리되는 과정이 다르기 때문이라고 한다.

자바스크립트 처리 과정

웹어셈블리 처리 과정

위의 그림은 웹어셈블리와 자바스크립트 처리 과정을 비교하기 위한 그림이다. 각 과정을 살펴보면서 어떤 차이가 있는지 살펴보자.

구문해석 (Parsing)

자바스크립트 파일이 브라우저에 전달되면, *추상 구문 트리(AST: Abstract Syntax Tree)로 변환이 된다. 그리고 이로 부터 바이트 코드를 생성한다. 반면, 웹어셈블리 파일은 이미 바이트 코드 형태이기 때문에, 변환 과정이 필요 없이 해석(decode)만 하여 검증 과정만 거치면 됩니다.

*추상 구문 트리(AST: Abstract Syntax Tree)는 컴파일러에 널리 사용되는 자료 구조이다. 컴파일러가 요구하는 여러 단계를 통해 프로그램의 중간 표현의 역할을 한다.
컴파일 및 최적화 (Compile + Optimize)

자바스크립트와 웹어셈블리 모두 컴파일 과정을 거친다. 차이가 있다면 웹어셈블리는 이미 많은 최적화가 진행된 상태이기 때문에 기계 코드와 훨씬 가까운 상태에서 시작한다. 그렇기 때문에 자바스크립트에 비해 최적화 과정이 적다.
재-최적화 (Reoptimizing)

재-최적화는 웹어셈블리에서는 일어나지 않고, 자바스크립트에서만 일어나는 과정이다. 자바스크립트는 컴파일 과정에서 간혹 여러 이유로 인해 기존 최적화를 버리고 다시 최적화를 하는데 이를 재-최적화라고 한다. 웹어셈블리에서는 타입과 같은 것들이 명시적이기 때문에 재-최적화 단계가 필요없다고 한다.
실행 (execute)

자바스크립트의 경우에도 컴파일러의 최적화 방식을 알고 있다면 그에 친화적인 형태의 코드 패턴으로 작성해 성능을 향상시킬 수도 있다. 그러나 대다수 개발자들은 컴파일러의 내부 동작을 알지 못하며, 브라우저에 따라 최적화 방식은 다르게 접근해야 하기 때문에 실제로는 어려운 일이다. 반면 웹어셈블리은 컴파일러를 위해 최적화 되어있기 때문에 자바스크립트에 비해 일반적으로 빠르다.
가비지 컬렉션 (Garbage Collection)

자바스크립트에서는 가비지 컬렉터가 더이상 필요없는 오래된 변수들을 메모리에서 제거하는 작업을 자동으로 해준다. 하지만 가비지 컬렉터를 직접 제어할 수 없기 때문에, 코드 실행을 방해하는 요인이 될 수도 있다. 웹어셈블리는 메모리를 수동으로 관리하기 때문에 성능에 있어서 더 안정적이다.

이러한 차이들에 의해서 일반적으로 웹어셈블리가 자바스크립트보다 더 좋은 성능을 나타낸다고 한다. 그래서 웹어셈블리를 이용하면 게임이나 VR/AR 처럼 높은 성능을 요구하는 프로그램도 웹으로 구현이 가능하고, 프로젝트를 하면서 많이 사용했던 피그마도 웹어셈블리로 구현되어 있다고 한다.

마무리

이번 시간에는 웹어셈블리에 대한 개념과 웹어셈블리가 자바스크립트에 비해 더 높은 성능을 낼 수 있는 이유에 대해서 살펴보았다. 웹어셈블리에 대해 더 자세한 내용들이 궁금하다면 카툰으로 소개하는 웹어셈블리을 정주행 해보는 것을 추천한다.

참고 링크

MDN

WebAssembly

기타 사이트

DIP : 변경에 유연하고 테스트하기 좋은 코드 설계

Sun, 21 Nov 2021 12:00:00 GMT

1. 들어가며

클린 코드 관련 저서들이 공통적으로 강조하는 내용은 단연 변경에 유연하고 테스트하기 좋은 코드의 중요성입니다. 소프트웨어는 항상 변경이 발생하기 쉽습니다. 요구 사항이 변경될 때마다 코드를 대거 수정해야 한다면 유지보수 측면에서 좋지 않습니다. 요구 사항 변경에 유연하게 대처할 수 있는 구조의 코드는 소프트웨어의 지속적인 성장을 위한 초석입니다.

a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.

어떻게 하면 작성한 코드 구조가 좋고 나쁜지를 판별할 수 있을까요? 저희 프로젝트 팀은 테스트하기 쉬운 코드 구조를 지표로 삼았습니다. 만약 작성한 코드가 테스트하기 어렵다면 코드에서 냄새가 난다고 간주했습니다. 코드 냄새는 컴퓨터 프로그래밍 코드에서 더 심오한 문제를 일으킬 가능성이 있는 프로그램 소스 코드의 특징을 가리킵니다. 테스트하기 어려운 코드는 설계가 잘못되었음을 시사하며, 설계를 개선할 경우 문제가 해결될 공산이 큽니다.

이번 글에서는 프로젝트 Pick-Git 개발 중 DIP를 통해 변경에 유연하고 테스트하기 좋은 코드를 설계한 사례를 공유하고자 합니다.

2. Backgrounds

프로젝트 Pick-Git은 Github Repo 기반 개발 장려 SNS이며, 어플리케이션 특성상 GitHub Open API를 사용해 클라이언트의 GitHub 통계 정보를 시각화합니다.

프로젝트 아키텍쳐는 Presentation - Application - Domain - Infrastructure 순의 Layered Architecture를 기반으로 구성되었습니다. 상위 계층은 인접한 하위 계층만을 의존하는 것이 특징입니다.

3. Problems

UserService.java

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Service
public class UserService {

    private final UserRepository userRepository;
    private final GitHubContributionCalculator gitHubContributionCalculator;

    public ContributionResponseDto calculateContributions(ContributionRequestDto requestDto) {
        User user = userRepository.findByName(requestDto.getUsername())
            .orElseThrow(InvalidUserException::new);

        Contribution contribution = gitHubContributionCalculator
            .calculate(requestDto.getAccessToken(), user.getName());

        return ContributionResponseDto.builder()
            .starsCount(contribution.getStarsCount())
            .commitsCount(contribution.getCommitsCount())
            .prsCount(contribution.getPrsCount())
            .issuesCount(contribution.getIssuesCount())
            .reposCount(contribution.getReposCount())
            .build();
    }
}

GitHubContributionCalculator.java

@RequiredArgsConstructor
@Component
public class GithubContributionCalculator {

    @Value("${github.contribution.url}")
    private final String url;

    public Contribution calculate(String accessToken, String username) {
        HttpHeaders httpHeaders = new HttpHeaders();
        httpHeaders.setBearerAuth(accessToken);
        RequestEntity<Void> requestEntity = RequestEntity
            .get(url)
            .headers(httpHeaders)
            .build();
        RestTemplate restTemplate = new RestTemplate();
        return restTemplate.exchange(requestEntity, Contribution.class)
            .getBody();
    }
}

GitHub Open API를 바탕으로 클라이언트의 연동된 GitHub 계정의 통계 정보를 조회하는 예제 코드입니다. 위 서비스 로직은 Application 계층이 Domain 계층만 의존하는 것이 아니라, Infrastructure 구현 기술까지 직접 의존하는 문제가 있습니다.

3.1. 변경의 가능성

서두에서 언급했듯이, 소프트웨어는 항상 변경이 발생하기 쉽습니다. 만약 요구사항 변경으로 인해 현재 프로젝트가 더이상 GitHub 플랫폼 연동을 지원하지 않고 GitLab 등 다른 플랫폼을 지원하게 된다면 어떻게 될까요?

UserService.java

Contribution contribution = gitHubContributionCalculator
    .calculate(requestDto.getAccessToken(), user.getName());

GithubContributionCalculator 뿐만 아니라 GitHub API 관련 Infrastructure 구현체를 사용하는 코드들이 전부 수정되어야 합니다. 만약 프로젝트 전역에 걸쳐 GitHub API 관련 Infrastructure 구현체를 사용하는 곳이 1000곳이라면, 1000번의 코드 수정이 발생하는 것입니다. 이는 코드가 변경에 유연하지 못하며 유지보수하기 힘들다는 점을 시사합니다.

3.2. 테스트하기 어려운 구조

UserServiceIntegrationTest.java

@Autowired
private UserRepository userRepository;

@Autowired
private UserService userService;

@MockBean
private GitHubContributionCalculator gitHubContributionCalculator;

@DisplayName("사용자는 활동 통계를 조회할 수 있다.")
@Test
void calculateContributions_LoginUser_Success() {
    // given
    userRepository.save(UserFactory.user());
    ContributionRequestDto requestDto = ContributionRequestDto.builder()
            .accessToken("access-token")
            .username("test-user-61")
            .build();
    ContributionResponseDto contributions = getExpectedContributionResponseDto();
    given(gitHubContributionCalculator.calculate("access-token", "test-user-61")).willReturn(contributions);

    // when
    ContributionResponseDto responseDto = userService.calculateContributions(requestDto);

    // then
    assertThat(responseDto)
        .usingRecursiveComparison()
        .isEqualTo(contributions);
}

GitHubContributionCalculator는 RestTemplate을 통해 GitHub로 API 요청을 보냅니다. 이 때, GitHub OAuth 로그인을 통해 얻은 실제 Access Token을 Header에 담습니다. 이에 대한 테스트 코드는 어떻게 작성할까요? 외부 API와의 통신은 직접 테스트하기 현실적으로 번거롭고 어려움이 많습니다. 외부 브라우저를 통해 로그인하고 실제 GitHub Access Token을 가져와 테스트 코드에 입력해야하기 때문입니다.

따라서 주로 Mocking하는 방식을 주로 사용합니다. 그러나 슬라이스 테스트가 아닌 통합 테스트에 매번 Mockito 혹은 RestClientTest 작업을 해주는 것 또한 번거롭습니다.

4. DIP(Dependency Inversion Principle)

우리가 다루는 모듈은 고수준 모듈과 저수준 모듈로 나눌 수 있습니다. 고수준 모듈이란 의미있는 단일 기능을 제공하는 모듈이며, 저수준 모듈은 고수준 모듈의 기능을 구현하기 위해 필요한 하위 기능의 실제 구현인 모듈입니다. Layered Architecture 상에서 Application 및 Domain 등의 고수준 모듈은 Infrastructure라는 저수준 모듈을 의존합니다. 그 결과, 앞서 언급한 것처럼 구현 부분의 변경에 유연하지 못하고 테스트하기 어렵다는 문제점이 발생합니다.

DIP(Dependency Inversion Principle)이란 의존 관계를 역전시켜서 저수준 모듈이 고수준 모듈에 의존하도록 구현하는 것을 의미합니다. 고수준 모듈이 저수준 모듈을 직접 의존하는 것이 아니라, 저수준 모듈이 인터페이스 등 추상을 매개체로 고수준 모듈을 참조하도록 합니다. 이를 통해 구현 기술과 관련된 종속성을 쉽게 제거할 수 있습니다.

PlatformContributionCalculator.java

public interface PlatformContributionCalculator {

    Contribution calculate(String accessToken, String username);
}

GitHubContributionCalculator.java

@RequiredArgsConstructor
@Component
public class GithubContributionCalculator implements PlatformContributionCalculator {

    // ...
}

UserService.java

@RequiredArgsConstructor
@Transactional
@Service
public class UserService {

    private final UserRepository userRepository;
    private final PlatformContributionCalculator platformContributionCalculator;

    public ContributionResponseDto calculateContributions(ContributionRequestDto requestDto) {
        User user = userRepository.findByName(requestDto.getUsername())
            .orElseThrow(InvalidUserException::new);

        Contribution contribution = platformContributionCalculator
            .calculate(requestDto.getAccessToken(), user.getName());

        return ContributionResponseDto.builder()
            .starsCount(contribution.getStarsCount())
            .commitsCount(contribution.getCommitsCount())
            .prsCount(contribution.getPrsCount())
            .issuesCount(contribution.getIssuesCount())
            .reposCount(contribution.getReposCount())
            .build();
    }
}

Application 계층이 Infrastructure 계층의 구현체가 아닌 Domain 계층의 PlatformContributionCalculator 인터페이스를 의존하도록 코드를 변경했습니다. 만약 요구사항 변경으로 인해 저수준 모듈이 GitHub 플랫폼 연동에서 GitLab 플랫폼 연동으로 변경되더라도, 고수준 모듈에서의 변경을 최소화할 수 있게 됩니다.

UserServiceIntegrationTest.java

@Autowired
private UserRepository userRepository;

private UserService userService;

@BeforeEach
void setUp() {
    PlatformContributionCalculator platformContributionCalculator = (accessToken, username) -> {
        // do something
    };
    userService = new UserService(userRepository, platformContributionCalculator);        
}

또한 테스트를 진행할 때 PlatformContributionCalculator에 적합한 Mock Object를 주입할 수 있게 됩니다. 따라서 GitHub 서버가 아닌 Mock 서버로 API 요청을 보내게끔 테스트 대역을 조절함으로써, Access Token으로 인한 문제에서 벗어나 자동화된 테스트를 쉽게 작성할 수 있습니다.

InfrastructureTestConfiguration.java

@TestConfiguration
public class InfrastructureTestConfiguration {

    @Bean
    public PlatformContributionCalculator platformContributionCalculator() {
        return new MockContributionCalculator();
    }
}

테스트 클래스에 정의하는 것이 번거롭다면 대역을 테스트용 Bean으로 주입해 여러 통합 테스트에서 사용할 수 있습니다.

5. 마치며

어떤 경우에 인터페이스를 추출하고 DIP를 적용해야할지 등에 대해 아직 감이 잡히지 않는다면, 우아한형제들 기술 블로그의 안정된 의존관계 원칙과 안정된 추상화 원칙에 대하여 글을 참고하시면 큰 도움이 되실겁니다. 의존은 안정적인 쪽(Presentation -> Application -> Domain -> Infrastructure)으로 향해야 한다는 글입니다.

안정성이란 추상성을 내포한다고 말하기 때문에 따라서 의존 관계는 추상성의 방향으로 흘러야 합니다. 안정된 추상화 원칙은 안정적인 패키지는 그 안정성 때문에 확장이 불가능하지 않도록 추상적이기도 해야하며, 거꾸로 이 원칙에 따르면 불안정한 패키지는 구체적이어야 하는데, 그 불안정성이 그 패키지 안의 구체적인 코드가 쉽게 변경될 수 있도록 허용하기 때문입니다.

Email 발송, Push, SMS 발송, Logging 등등 인프라성 코드는 거의 불안정성이 0에 가깝습니다(안정적). 호출자는 매우 많은데 그 자신이 의존하는 것은 별로 많지 않은 경우가 많습니다. 그러면서도 그 구현체는 시스템의 성장에 따라 바뀌기 쉽습니다(Email의 경우 SMTP → DB → MQ). 안정성이 높으면 변경 대응을 위해 추상적이어야 합니다. 따라서 인프라성 Service는 거의 무조건 interface를 구현해야 합니다.

DIP가 항상 만능은 아닙니다. Runtime에 의존 대상이 결정되기 때문에 코드를 이해하거나 디버깅하기 어려워집니다. 처음부터 모든 의존 관계에 인터페이스를 추출하여 DIP를 적용하면 코드의 복잡도가 높아집니다. 특정 모듈의 변경 가능성 및 의존도 등을 다각도로 검토하여 인터페이스 추출과 DIP를 고려해야 합니다.

References

함수형 인터페이스와 람다를 이용한 코드 중복 제거

Sun, 21 Nov 2021 12:00:00 GMT

image origin: keefcode

코드를 작성하다 보면 비슷한 로직의 중복 코드가 생길 수 있고, 그로 하여금 관리 지점이 늘어나기 때문에 대부분 리팩터링의 대상으로 취급한다.

이번 글에서는 함수형 인터페이스와 람다에 대해 알아보고, 이를 이용해 코드의 중복을 제거하는 방법을 다룰 것이다.

함수형 인터페이스(Functional Interface)

public interface Comparator<T> {
    int compare(T o1, T o2);
}

위 코드는 Java API의 함수형 인터페이스인 Comparator이다. 이처럼 추상 메서드를 단 하나만 가지고 있는 인터페이스를 함수형 인터페이스라고 한다. 또한 인터페이스에서 모든 메서드는 암시적으로 추상 메서드이기 때문에 abstract 키워드를 쓰지 않는다.

Java 8 부터 인터페이스는 default method 를 포함할 수 있는데, 여러 개의 디폴트 메서드가 있더라도 추상 메서드가 오직 하나면 함수형 인터페이스이다. 즉, default method 또는 static method는 여러 개가 존재해도 함수형 인터페이스일 수 있다.

그리고 @FunctionalInterface 어노테이션을 사용할 수 있는데, 이 어노테이션은 해당 인터페이스가 함수형 인터페이스 조건에 맞는지 컴파일 시점에 검사할 수 있게 한다. @FunctionalInterface 어노테이션이 없어도 함수형 인터페이스로 동작하고 사용하는 데 문제는 없지만, 인터페이스 검증과 유지보수를 위해 붙여주는 게 좋다.

람다(Lambda)

람다는 쉽게 말해서 메서드에 전달할 수 있는 ‘동작’이라고 이해하면 된다.

메서드와 비슷하지만 특정 클래스에 종속되지 않으며 이름을 갖지 않는다.

쉽게 말해 메서드를 하나의 식으로 표현한 것이다.

int min(int x, int y) {
    return x < y ? x : y;
}

위 메서드를 람다로 표현하면 아래와 같다.

(x, y) -> x < y ? x : y;

핵심은 간결하고, 유연하다는 것이다. 메서드를 람다 표현식으로 표현하면 클래스 작성 및 객체 생성을 하지 않아도 메서드처럼 사용할 수 있다.

람다 표현식은 위와 같이 람다 파라미터, 화살표, 람다 바디로 이루어져있다.

화살표는 람다 파라미터와 람다 바디를 구분하며 람다 바디는 람다의 반환값에 해당하는 표현식이다.

람다 표현식에는 return이 함축되어 있으므로 return문과 세미 콜론을 명시적으로 사용하지 않아도 된다.

함수형 인터페이스와 람다를 이용한 코드 중복 제거

함수형 인터페이스에 람다 표현식을 접목할 수 있다.

함수형 인터페이스가 가지고 있는 추상 메서드의 구현을 람다 표현식으로 직접 전달할 수 있다.

함수형 인터페이스는 어떤 식으로든 구현될 수 있는 추상 메서드를 가지고 있고, 람다는 그 추상 메서드를 구현함과 동시에 전달할 수 있는 것이다.

실제로 사이드 프로젝트를 하면서 활용한 부분을 얘기해보려고 한다.

기존의 중복 코드

다음 코드는 여러 축구 경기의 총 헤딩 시도 횟수와 , 총 중거리 슛 시도 횟수를 계산하는 로직이다.

이때, 지표의 종류만 다를 뿐 각 지표의 횟수를 가져오는 로직에서 거의 동일하다고 볼 수 있을 정도의 중복을 볼 수 있다.

public int getTotalHeaderAttempt() {
    // 각 경기의 총 헤딩 시도 횟수를 가져와 더한다.
    int sumOfHeaderAttempt = 0;
    for (Match match : matches) {
        sumOfHeaderAttempt += match.getHeaderAttempt();
    }
    return sumOfHeaderAttempt;
}

public int getTotalMiddleShootAttempt() {
    // 각 경기의 총 중거리 슛 시도 횟수를 가져와 더한다.
    int sumOfMiddleShootAttempt = 0;
    for (Match match : matches) {
        sumOfMiddleShootAttempt += match.getMiddleShootAttempt();
    }
    return sumOfMiddleShootAttempt;
}

개선된 코드

@FunctionalInterface
public interface Counter { 
    int getCountOfStat(Match match);
}

먼저, 함수형 인터페이스 Counter를 만들었다. 각 지표의 횟수를 셀 수 있도록 구현될 수 있는 추상 메서드인 getCountOfStat를 가지도록 하였다.

총 헤딩 시도 횟수를 가져오도록 하고 싶을 땐 추상 메서드의 구현으로써 Match.getHeaderAttempt()를 전달하고, 총 중거리 슛 시도 횟수를 가져오도록 하고 싶을 땐 Match.getMiddleShootAttempt()를 전달하면 될 것이다.

실제로 함수형 인터페이스에 추상 메서드의 구현을 전달하는 부분을 살펴보자.

private int calculateTotalCount(List<Match> matches, Counter counter) {
    int count = 0;
    for (Match match : matches) {
        count += counter.getCountOfStat(match);
    }
    return count;
}

public double getTotalHeaderAttempt() {
    return calculateTotalCount(matches, match -> getHeaderAttemptCount());
}

public double getTotalMiddleShootAttempt() {
    return calculateTotalCount(matches, match -> getMiddleShootAttemptCount());
}

calcualteTotalCount 메서드에서 함수형 인터페이스를 파라미터로 받아 그 구현을 실행하는 것을 볼 수 있다.

getTotalHeaderAttempt와 getTotalMiddleShootAttempt 메서드는 calcualteTotalCount 메서드로 함수형 인터페이스의 추상 메서드 구현체를 람다를 이용하여 전달하고 있음을 볼 수 있다. 참고로 람다식은 메서드 참조를 이용하여 불필요한 매개 변수를 제거할 수도 있다.

마무리

함수형 인터페이스와 람다를 이용하여 중복 코드를 제거하는 방법에 대해 알아보았다.

다만, Java는 기본적으로 많이 사용되는 함수형 인터페이스를 제공하기 때문에 매번 함수형 인터페이스를 직접 만들어서 사용하는 건 불필요한 작업일 수 있다.

이 글에서는 연습 삼아 별도의 함수형 인터페이스를 만들었지만, Java에서 제공하는 ToIntFunction을 사용해도 무리가 없었다.

기본적으로 제공되는 것만 사용해도 웬만한 람다식은 다 만들 수 있기 때문에, 어떤 게 있는지 잘 파악해서 활용하자.

Reference

모던 자바 인 액션

리액트에서 도넛 차트를 만들어보자!

Wed, 10 Nov 2021 12:00:00 GMT

리액트에서 도넛 차트를 만들어보자

도넛 차트

Canvas? DIV? SVG?

도넛 차트는 Canvas, DIV(html, css), SVG 등 크게 3가지 방법을 사용하여 만들 수 있습니다. 각각의 특징을 간단하게 살펴보면, Canvas를 이용한 방식의 특징은 비트맵 영역을 활용하는 것입니다. 즉, 자바스크립트 코드로 화면 위에 픽셀을 그려 넣는 방법입니다. 이와 같은 방식은 픽셀을 다루게 되어 도형의 크기에 따라 해상도를 따로 고려해야 하는 단점이 있습니다. 다음으로 DIV를 이용한 방법입니다. DIV로 도넛 차트를 그리는 경우, 원을 나타내기 위해 radius를 조절하여 그리게 됩니다. 이 방식은 화면의 크기에 상관없이 도형의 크기가 고정되어 있어 반응형에 취약하다는 단점이 있습니다. 마지막으로 SVG를 사용하는 방법입니다. SVG는 벡터 형식으로, 화면의 크기에 따라 그 크기가 유동적으로 변하는 특징이 있습닌다. 또한, SVG 태그 중 하나인 <circle>과 stroke, stroke-width 등의 속성으로 쉽게 도형을 표현할 수 있다는 장점이 있습니다.

세 가지 방법 중에서 SVG를 이용해 도넛 차트를 만들 경우, 반응형을 지원하면서 이미 내장되어 있는 속성인 stroke, stroke-width 등을 활용하여 쉽게 만들 수 있다는 장점이 있어 SVG를 선택했습니다.

stroke-dasharray

도넛 차트를 그리기 앞서 먼저 stroke-dasharray의 개념을 먼저 알아보겠습니다.

stroke-dasharray 속성은 도형 둘레의 dash와 gap을 정의하는 패턴으로, 도형 둘레의 stroke의 길이와 각각의 stroke 사이 공백의 패턴을 정의합니다. 예시를 통해 알아보겠습니다.

stroke-dasharray 속성이 적용되지 않은 기본 <line>은 다음과 같습니다.

<svg viexBox="0 0 100 100">
  <line x1="0" y1="5" x2="100" y2="5" stroke="green" strokeDasharray="0" />
</svg>

이 기본 svg line에 다양한 stroke-dasharray 값을 적용해보겠습니다.

결과는 위와 같습니다. 하나의 값만 할당하고 있는 stroke-dasharray="5"는 각 stroke의 길이와 각각의 stroke 사이 공백의 길이를 5로 정의한다는 의미입니다. stroke 사이 공백의 길이도 따로 정의할 수 있는데, stroke-dasharray="5 10"과 같이 두 개의 값 사이에 공백을 두어 할당하면(공백 대신 ,도 가능합니다) , 첫 번째 값은 각 stroke의 길이, 두 번째 값은 각각의 stroke 사이 공백의 길이를 의미하게 됩니다.

추가적으로 패턴은 아래의 예시처럼 svg 도형의 길이까지만 적용되어, 길이를 넘어가는 부분은 잘리게 됩니다.

그럼 도넛에도 적용해 보겠습니다.

도넛의 둘레의 길이가 약 565인 원이 있습니다. 이 도넛에 stroke-dasharray="20", stroke-dasharray="40", stroke-dasharray="60" stroke-dasharray="40 20"을 각각 적용해 살펴보겠습니다.

위의 svg line 예시와 동일합니다. 다만 svg circle은 stroke-dasharray 패턴이 시계 3시 방향에서 시작한다는 특징이 있습니다.

stroke-dashoffset

이번에는 stroke-dashoffset 속성을 알아보겠습니다. stroke-dashoffset은 dash array를 렌더링 할 때 offset을 정의하는 속성입니다. 예시로 확인해 보겠습니다.

svg line의 기본 형태는 stroke-dasharray="10 5"입니다. 여기에 stroke-dashoffset 속성을 적용하면 할당되는 값에 따라 화면에 보이는 패턴이 변경됩니다. 두 번째 그림에서 네모 박스는 실제로 화면에서 보이는 영역입니다. 양수인 경우, 할당된 값만큼 네모 박스가 오른쪽으로 이동하여 박스 안에 속한 패턴이 화면에 보이게 됩니다. 음수인 경우, 그 반대인 왼쪽으로 이동합니다.

stroke-dashoffset 값에 따라 네모 박스가 이동한다고 하여 화면에 보이는 영역 자체가 이동한다고 착각할 수 있습니다. 하지만, 첫 번째 그림과 같이 화면에 보이는 영역의 위치는 동일하고 영역 내 패턴의 모습만 달라지게 됩니다.

직접 만들어보기

만들고자 하는 차트는 75%를 표시하고 있는 도넛 차트입니다. 바로 진행해 보겠습니다.

환경은 CRA를 이용하여 구성했고, 전체적인 코드를 보여주기 위해서 도넛 차트를 컴포넌트로 따로 분리하지 않았습니다.

// App.js

const App = () => (
  <div style={{ marginTop: '50px', marginLeft: '50px' }}>
    <div style={{ width: '200px', height: '200px' }}>
      <svg viewBox="0 0 200 200">
        <circle cx="100" cy="100" r="90" fill="none" stroke="beige" strokeWidth="20" />
        <circle
          cx="100"
          cy="100"
          r="90"
          fill="none"
          stroke="green"
          strokeWidth="20"
          strokeDasharray={2 * Math.PI * 90 * 0.75}
        />
      </svg>
    </div>
  </div>
);

export default App;

설명하기 앞서, 올바른 속성은 위 코드처럼 strokeDasharray={2 * Math.PI * 90 * 0.75}인데, 이해를 돕기 위해서 stroke-dasharray="2πr * 0.75"라고 표현하겠습니다.

75%의 도넛 차트를 그리기 위해서 stroke-dasharray="2πr * 0.75" 속성을 사용했습니다. 전체 원의 둘레 공식인 2 πr에 0.75를 곱한 값입니다.

둘레의 길이는 2* Math.PI * 반지름 또는 document.getElementById().getTotalLength() 등으로 구할 수 있습니다.

다음 과정은 도넛 차트를 반시계 방향으로 90° 회전시키는 것입니다. svg에서 도형을 회전시키기 위한 방법으로 stroke-dasharray와 stroke-dashoffset 속성을 활용할 수 있는데, stroke-dasharray 속성으로 먼저 패턴을 정의하고, stroke-dashoffset 속성을 이용해서 패턴에서 화면에 보이는 영역을 조정하는 방식입니다.

먼저 현재 도넛 차트에 정의되어 있는 패턴을 확인해 보겠습니다.

패턴은 위 그림과 같이 stroke-dasharray="2πr * 0.75"로, stroke의 길이와 stroke 사이 간격 모두 2πr * 0.75로 정의되어 있고, 화면에 보이는 영역은 빨간 네모 박스 부분입니다. 하지만 최종적으로 화면에 보여야 하는 영역은 다음과 같습니다.

circle에서 stroke가 3시 방향에서 시작되므로, 12시 방향을 0°라고 했을 때, 3시 방향인 90°에서 9시 방향인 270°까지 색이 채워지고, 270°에서 360(0)°까지 공백, 0°에서 90°까지 다시 색이 채워져야 합니다.

현재 정의되어 있는 패턴으로는 stroke-dashoffset을 조정해도 목표로 하는 패턴을 표현할 수 없기 때문에, 패턴을 다시 정의합니다.

stroke의 길이는 전체 둘레의 75%에 해당하는 2πr * 0.75, 각 stroke 사이 공백은 전체 둘레의 25%에 해당하는 2πr * 0.25로 stroke-dasharray="2πr * 0.75, 2πr * 0.25"로 변경합니다.

각 stroke 사이 공백을 2πr * 0.25로 한 이유는 stroke-dasharray의 첫 번째 값과 두 번째 값을 합쳐 원 전체 둘레의 길이가 나오게 하기 위함입니다. 이렇게 하면 패턴이 반복되는 길이의 기준이 전체 원 둘레가 되어, 이후 stroke-dashoffset 속성을 적용하기 용이합니다.

그러고는 stroke-dashoffset="2πr * 0.25" 속성을 적용하여, 원하는 패턴이 화면에 보이도록 조정합니다. 위 그림에서 화면에 보이는 영역인 빨간 네모 박스의 시작이 180°로 되어 있고 그 위에 있는 도형의 모양도 이전 그림과 동일한데, 이는 이전 그림에서 stroke-dashoffset 속성을 적용하여 화면에 보이는 영역이 이동했다는 것을 나타내기 위함입니다. 실제로는 stroke-dashoffset의 조정과 동시에 다음과 같이 패턴이 변경됩니다.

최종 코드는 다음과 같습니다.

// App.js

const App = () => (
  <div style={{ marginTop: '50px', marginLeft: '50px' }}>
    <div style={{ width: '200px', height: '200px' }}>
      <svg viewBox="0 0 200 200">
        <circle cx="100" cy="100" r="90" fill="none" stroke="beige" strokeWidth="20" />
        <circle
          cx="100"
          cy="100"
          r="90"
          fill="none"
          stroke="green"
          strokeWidth="20"
          strokeDasharray={`${2 * Math.PI * 90 * 0.75} ${2 * Math.PI * 90 * 0.25}`}
          strokeDashoffset={2 * Math.PI * 90 * 0.25}
        />
      </svg>
    </div>
  </div>
);

export default App;

위 과정을 보면 stroke-dasharray와 stroke-dashoffset 속성을 이용해서 도넛 차트 만드는 방법이 굉장히 복잡해보입니다. 하지만, 다음과 같이 계산하여 쉽게 만들 수 있습니다.

// React

// x = 원의 전체 둘레 길이
// a = 데이터에 해당하는 원의 둘레 길이 ex) 63% -> x * 0.63

<circle strokeDasharray="<a> <x - a>" strokeDashoffset="<0.25 * x>" />

애니메이션

애니메이션은 @keyframes를 이용하여 간단히 구현할 수 있습니다. 다음 예시는 스타일 라이브러리로는 emotion을 사용했습니다.

// App.js

import { AnimatedCircle } from './App.styles';

const App = () => (
  <div style={{ marginTop: '50px', marginLeft: '50px' }}>
    <div style={{ width: '200px', height: '200px' }}>
      <svg viewBox="0 0 200 200">
        <circle cx="100" cy="100" r="90" fill="none" stroke="beige" strokeWidth="20" />
        <AnimatedCircle
          cx="100"
          cy="100"
          r="90"
          fill="none"
          stroke="green"
          strokeWidth="20"
          strokeDasharray={`${2 * Math.PI * 90 * 0.75} ${2 * Math.PI * 90 * 0.25}`}
          strokeDashoffset={2 * Math.PI * 90 * 0.25}
        />
      </svg>
    </div>
  </div>
);

export default App;

// App.styles.js

import styled from '@emotion/styled';

const AnimatedCircle = styled.circle`
  animation: circle-fill-animation 2s ease;

  @keyframes circle-fill-animation {
    0% {
      stroke-dasharray: 0 ${2 * Math.PI * 90};
    }
  }
`;

export { AnimatedCircle };

App.styles.js 파일의 @keyframes에서 0%는 애니메이션의 시작을 의미합니다. 즉, 애니메이션 초기에는 stroke-dasharray: 0 ${2 * Math.PI * 90} 속성으로 각 stroke의 길이를 정의하지 않고, stroke 사이 공백을 원 전체 둘레로 정의하는 것을 의미합니다.

참조

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-dasharray

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-dashoffset

https://developer.mozilla.org/ko/docs/Web/CSS/@keyframes

웹 소켓에 대해 알아보자! - 테스트 편

Wed, 10 Nov 2021 12:00:00 GMT

이 글은 웹 소켓으로 만든 채팅방을 어떻게 테스트할지 고민하는 독자를 위해 작성되었다.

웹 소켓은 어떻게 테스트하면 좋을까?

Babble 팀의 데모데이 날 부스에서 질문을 받았다. “웹 소켓은 테스트를 어떻게 해야 할 지 감이 안 잡히는데 어떻게 구현하셨나요?” 테스트 코드에 정해진 정답은 없지만, 우리 팀도 웹 소켓 테스트 작성에 꽤 많이 고민했던 적이 있다. 고생해준 프로젝트 팀원 덕에 블로킹 큐를 이용하여 메시지를 저장하고 테스트를 해보는 방식으로 웹 소켓 테스트를 구현했다. 이 방법을 한번 알아보자.

사전에 웹 소켓 구현에 필요한 코드량이 많기 때문에 코드만 언급하고 테스트 코드 구현으로 넘어간다. 웹 소켓 실습에 대해 연습하고 싶다면 여기를 먼저 참고하는 것을 추천한다.

프로젝트 설명

이 코드는 Babble 팀에서 사용하는 도메인 모델과는 차이가 있다. 순전히 테스트를 실습해보기 위해 만든 코드다.

단순히 채팅하는 프로그램이 아니라 채팅방이 있고 사용자가 채팅방에 들어오거나 나가면서 1:N 의 채팅을 하는 프로그램이다. 채팅방을 위한 도메인부터 컨트롤러까지 모든 코드가 있기 때문에 자세한 구현은 예제 저장소에서 확인한다.

테스트 코드 만들기

핵심 기능이라고 할 수 있는 채팅방 입장, 채팅방에서 주고받는 메시지가 올바르게 송수신 되는지, 채팅 방 퇴장을 확인하는 테스트는 어떻게 구현할 수 있을까?

웹 소켓 테스트 코드에 대해 살펴본다. rest-assured 를 사용한 api 테스트를 진행한다. rest-assured 는 given, when, then 패턴으로 테스트 코드를 작성하며 Json Data 를 쉽게 검증할 수 있다.

채팅방 관련 기능 테스트

메시지를 큐에 저장하고 채팅 송수신이 끝난 후 실제로 받은 메시지가 큐에 올바르게 들어있는지 확인하는 방식으로 테스트를 만들었다.

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class WebSocketChattingTest {

    @LocalServerPort
    private int port;
    private BlockingQueue<SessionResponse> users;
    private BlockingQueue<MessageResponse> messages;
    @Autowired
    private UserRepository userRepository;
    @Autowired
    private RoomRepository roomRepository;

    @BeforeEach
    public void setUp() {
        RestAssured.port = port;
        users = new LinkedBlockingDeque<>();
        messages = new LinkedBlockingDeque<>();
        유저_삽입();
        방_생성();
    }

    private void 유저_삽입() {
        userRepository.save(new User("와일더"));
        userRepository.save(new User("마이클"));
        userRepository.save(new User("제이슨"));
        userRepository.save(new User("오스카"));
    }

    private void 방_생성() {
        roomRepository.save(new Room(2));
        roomRepository.save(new Room(4));
        roomRepository.save(new Room(5));
    }

    @DisplayName("유저가 입장하고 메시지를 보내면 해당 방에 메시지가 브로드 캐스팅된다.")
    @Test
    void enterUserAndBroadCastMessage() throws InterruptedException, ExecutionException, TimeoutException {
        Room room = roomRepository.findAll().get(0);
        User user = userRepository.findAll().get(0);
     	  UserResponse expectedUser = UserResponse.from(user);
        MessageResponse expected = new MessageResponse(user.getId(), "채팅을 보내 봅니다.");

        // Settings
        WebSocketStompClient webSocketStompClient = 웹_소켓_STOMP_CLIENT();
        webSocketStompClient.setMessageConverter(new MappingJackson2MessageConverter());

        // Connection
        ListenableFuture<StompSession> connect = webSocketStompClient
            .connect("ws://localhost:" + port + "/ws-connection", new StompSessionHandlerAdapter() {
            });
        StompSession stompSession = connect.get(60, TimeUnit.SECONDS);

        stompSession.subscribe(String.format("/sub/rooms/%s", room.getId()), new StompFrameHandlerImpl(new SessionResponse(), users));
        stompSession.send(String.format("/pub/rooms/%s", room.getId()), new SessionRequest(user.getId(), "1A2B3C4D"));

        stompSession.subscribe(String.format("/sub/rooms/%s/chat", room.getId()), new StompFrameHandlerImpl(new MessageResponse(), messages));
        stompSession.send(String.format("/sub/rooms/%s/chat", room.getId()), new MessageRequest(user.getId(), "채팅을 보내 봅니다."));

        MessageResponse response = messages.poll(5, TimeUnit.SECONDS);

        // Then
        assertThat(response).usingRecursiveComparison().isEqualTo(expected);
    }

    private WebSocketStompClient 웹_소켓_STOMP_CLIENT() {
        StandardWebSocketClient standardWebSocketClient = new StandardWebSocketClient();
        WebSocketTransport webSocketTransport = new WebSocketTransport(standardWebSocketClient);
        List<Transport> transports = Collections.singletonList(webSocketTransport);
        SockJsClient sockJsClient = new SockJsClient(transports);

        return new WebSocketStompClient(sockJsClient);
    }
}

벌써 머리가 아프기 시작한다. 안 그래도 낯선 Web Socket 이란 기술을 테스트해 보려고 하다가 머리가 새하얗게 될 것만 같다. 이쯤 되면 그냥 Postman 으로 테스트를 하고 싶어진다. 그래도 참고 테스트 코드를 구현해볼 의지가 있는 독자는 참고하길 바란다. 핵심이 되는 부분을 살펴보자.

웹 소켓은 스레드에서 동작하기 때문에 BlockingQueue 에 담아둔다. BlockingQueue를 사용하지 않으면 메시지를 주고 받고 나서 데이터가 남아있지 않다.

테스트 코드에서 사용할 WebSocketStompClient 를 만든다.

    private WebSocketStompClient 웹_소켓_STOMP_CLIENT() {
        StandardWebSocketClient standardWebSocketClient = new StandardWebSocketClient();
        WebSocketTransport webSocketTransport = new WebSocketTransport(standardWebSocketClient);
        List<Transport> transports = Collections.singletonList(webSocketTransport);
        SockJsClient sockJsClient = new SockJsClient(transports);

        return new WebSocketStompClient(sockJsClient);
    }

위에서 만든 Client 에 MessageConverter 를 적용한다. StringMessageConverter, SimpleMessageConverter 등 여러 MessageConverter 구현체가 있다. 여기서는 JSON 을 지원하는 MappingJackson2MessageConverter 클래스를 사용했다.

// Settings
WebSocketStompClient webSocketStompClient = 웹_소켓_STOMP_CLIENT();
webSocketStompClient.setMessageConverter(new MappingJackson2MessageConverter());

다음은 연결 요청 부분이다.

// Connection
ListenableFuture<StompSession> connect = webSocketStompClient
            .connect("ws://localhost:" + port + "/ws-connection", new StompSessionHandlerAdapter() {
            });
        StompSession stompSession = connect.get(60, TimeUnit.SECONDS);

방 입장 및 채팅을 보내는 부분이다. 컨트롤러에서 설정해둔 @MessageMapping 의 URI 로 접근한다. 여기서 StompFrameHandlerImpl 클래스는 직접 구현한 것이니 뒤에서 다루도록 한다. TimeOut 시간은 너무 짧게 설정하면 디버깅 모드로 내부를 살펴볼 때 데이터가 남아있지 않기 때문에 적당하게 시간을 설정한다.

stompSession.subscribe(String.format("/sub/rooms/%s", room.getId()), new StompFrameHandlerImpl(new SessionResponse(), users));
        stompSession.send(String.format("/pub/rooms/%s", room.getId()), new SessionRequest(user.getId(), "1A2B3C4D"));

        stompSession.subscribe(String.format("/sub/rooms/%s/chat", room.getId()), new StompFrameHandlerImpl(new MessageResponse(), messages));
        stompSession.send(String.format("/sub/rooms/%s/chat", room.getId()), new MessageRequest(user.getId(), "채팅을 보내 봅니다."));

BlockingQueue 에 저장되어 있던 메시지를 꺼낸다. 미리 만들어둔 값과 비교한다.

MessageResponse response = messages.poll(5, TimeUnit.SECONDS);

// Then
        assertThat(sessionResponse.getUserResponses().get(0)).usingRecursiveComparison().isEqualTo(expectedUser);
assertThat(messageResponse).usingRecursiveComparison().isEqualTo(expectedMessage);

StompFrameHandlerImpl 클래스는 직접만든 StompFrameHandler 구현체다.

public class StompFrameHandlerImpl<T> implements StompFrameHandler {

    private final T response;
    private final BlockingQueue<T> responses;

    public StompFrameHandlerImpl(final T response, final BlockingQueue<T> responses) {
        this.response = response;
        this.responses = responses;
    }

    @Override
    public Type getPayloadType(final StompHeaders headers) {
        return response.getClass();
    }

    @Override
    public void handleFrame(final StompHeaders headers, final Object payload) {
        System.out.println(payload);
        responses.offer((T) payload);
    }
}

Stomp Frame 을 어떻게 처리할지 지정해주는 부분이다. 위의 객체를 생성할 때 payload 를 받을 클래스의 타입을 지정하고, payload 가 담길 BlockingQueue 를 넣어준다. 테스트를 실행하면 테스트가 성공적으로 동작하는 것을 확인할 수 있다.

결론

Blocking Queue 에 담긴 메시지를 통해 테스트하는 방식을 알아봤다. 오늘 알아본 테스트 코드 하나면 방 입장, 채팅, 퇴장 등 웬만한 테스트를 응용할 수 있으리라 생각한다. 웹 소켓은 양방향 통신이라는 매력적인 기술이지만 참고할 레퍼런스가 상당히 적다는 점이 아쉽다. 프로젝트에 웹 소켓을 적용하려는 모든 분을 응원한다.

참고

Testing WebSockets for beginners

쿠버네티스 입문하기

Sun, 07 Nov 2021 12:00:00 GMT

기존에 웹 서버를 이용해 로드밸런싱, 포트포워딩, 헬스체킹, 무중단 배포 등 안정적인 인프라를 구성하고 있었다. 지금의 인프라 구조도 좋은데 쿠버네티스라는 기술을 적용함으로써 얻는 이점은 무엇일까?

이미지가 변경되면 기존 컨테이너를 새로운 컨테이너로 어떻게 변경할지, 부하가 들어오면 어떻게 부하를 분산할지, 컨테이너가 예기치 못하게 중단될 경우 어떻게 대처할지 등을 웹 서버에서 처리하려면 개발자가직접 설정을 해주고 수정해주어야 했다.

하지만 쿠버네티스는 일정한 상태를 입력해두면 내부적으로 Master node의 관리 하에 다양한 컨테이너를 구동한다. 컨테이너 단위로 서비스를 관리하니 서로 다른 컨테이너 간 영향을 끼치지 않고 os를 매번 새로 시작할 필요도 없다는 장점을 갖고 있다. 뿐만 아니라, 서버의 리소스를 내부적으로 원하는 상태로 알아서 관리하며 컨테이너 증설 시 내장 컨트롤러가 최적의 노드를 찾아 배치하고 자동으로 리소스 확장이 가능하다.

정리하자면, 쿠버네티스를 이용해 아래와 같은 기능을 누릴 수 있다.

무중단 배포
health checking
Reverse proxy 감지
컨테이너 scale-out
여러 node에서 컨테이너를 관리하며 ip 중복 방지

이렇게 컨테이너의 배포, 관리, 확장, 네트워킹 등을 자동화하는 것을 컨테이너 오케스트레이션이라고 한다.

쿠버네티스 배포 인프라 구성

kubectl 명령어가 입력되면 아래와 같은 흐름으로 처리가 진행된다.

kubectl을 이용해 명령하면 api server에 전달된다.
인증/권한승인/승인제어 등의 확인절차를 거친다.
api server가 object를 적절히 변형(mutate)한다.
api server가 유효성 검사(validate)한다.
etcd에 명령이 기록된다.
응답

출처: https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca

kubectl api-resources 를 입력해 쿠버네티스에서 사용할 수 있는 오브젝트들에 대해 조회할 수 있다. 그 오브젝트 설명이 보고싶다면 kubectl explain {오브젝트명} 을 이용한다.

쿠버네티스에서 모든 리소스는 오브젝트의 형태로 관리한다. 각 오브젝트를 원하는 상태로 유지하는데, 그 상태를 yml로 관리할 수 있다. 쿠버네티스 오브젝트에는 구성단위가 되는 기본 오브젝트와 이를 생성하고 관리하는 역할을 하는 컨트롤러가 존재한다.

이제부터 쿠버네티스의 각 요소에 대해서 알아보도록 하자.

1. Master Node

모든 Workder Node들을 제어하고 전체 클러스터를 관리해주는 컨트롤러로, 전체적인 제어/관리를 하기 위한 관리 서버이다.

Api server

k8s(쿠버네티스)의 모든 구성 요소는 api server와 통신한다.

etcd와 통신할 수 있는 유일한 요소이다.
etcd

위에서 언급한 쿠버네티스가 바라는 오브젝트(pod, service, replicaset)들을 k-v 형태로 저장한다.

etcd 인스턴스는 과반 투표를 하는 RAFT 알고리즘을 사용하기 때문에 홀수로 구성해야 한다.
scheduler

pod를 어느 node에 배치할지 판단하는 역할을 수행한다.

스케줄될 수 있는 모든 노드의 목록과 affinity의 명세를 확인하고 우선순위를 지정해준다.

node가 요청을 이행할 수 있는지, 리소스가 부족하지 않은지, node가 PodSpec의 Node Selector에 맞는 라벨을 가질 수 있는지, port가 이미 사용되고 있는지, 볼륨이 마운트 되는지 확인한다.

2. Worker Node

컨테이너가 배포될 장소로 master node로부터 파드를 관리하도록 명령받는 주체이다.

기본 설정을 위한 구성요소
- kubelet
  
  pod 내 컨테이너 실행을 직접 관리할 뿐만 아니라 마스터와 워커 노드 간의 통신 역할도 담당하는 에이전트이다.
  
  node 상태, Podspec에 맞춰 Pod들이 정상적으로 동작하는지 확인하고 cAdvisor를 통해 정보를 수집한다.
- kube-proxy
  
  가상 네트워크 관리
- DNS pod
  
  ip가 중복인 경우 각 service endpoint를 아는 dns pod가 worker node에 존재
서비스를 위한 구성요소
- Cluster
  
  컨테이너를 실행하기 위한 주체이다. 내부에 하나 이상의 master node, worker node가 존재해야 한다.
- Pod
  
  컨테이너의 집합으로 컨테이너 실행을 담당한다. 컨테이너 어플리케이션을 배포하기 위한 기본 단위로 컨테이너의 생성, 운영, 제거 등을 관리한다.
  
  보통 하나의 pod에 하나의 컨테이너(온전한 어플리케이션)만 실행한다. 하지만 설정 리로더나 로그 수집 등을 위한 추가 컨테이너가 포함될 수 있고 이를 사이드카 컨테이너라고 부른다. 이렇게 만들어진 하나의 포드가 완전한 애플리케이션으로 동작하는 것이다.
- Replicaset
  
  복제 담당으로 pod의 갯수가 부족할 경우 복제해서 생성하는 일을 담당한다. 정해진 수의 동일한 포드가 항상 실행되도록 관리한다. 노드 장애 등의 이유로 포드를 사용할 수 없으면 다른 노드에서 포드를 다시 생성한다.
- Deployment
  
  replicaset과 pod의 정보를 정의하는 오브젝트로 replicaset의 상위 오브젝트라 deployment가 생성되면 replicaset도 함께 생성된다.
  
  배포 담당으로 배포되고 있는상태를 확인하고 replicaset의 변경 사항을 저장하는 revision을 남겨 롤백할 수 있다.
  
  rolling update, scale out이 가능하다.
- Service
  
  deployment를 통해 생성된 포드에 접근하도록 도와주는 Endpoint이다. 여러 개의 포드에 쉽게 접근할 수 있도록 고유한 도메인 이름 부여하고 요청을 분산하는 로드밸런서 기능 수행한다.
  
  하나의 애플리케이션 묶음으로 Pod를 그룹핑하고 라벨로 분류해준다. Pod가 새로 생성되더라도 service를 통해 동일 도메인으로 접근할 수 있다.
  
  상황에 따라 맞는 type을 지정해 사용한다.
  - ClusterIP
    
    쿠버네티스 내부에서만 포드들에 접근할 때 사용하는 type
  - NodePort
    
    포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 동일하게 개방해, 외부에서 포드에 접근 가능하도록 하는 type
  - LoadBalancer
    
    플랫폼에서 제공하는 로드 밸런서를 동적으로 프로비저닝해 포드에 연결하고 외부에서 접근 가능하도록 하는 type
- Ingress
  
  Service의 NodePort + LoadBalancer를 합쳐논 요소이다. 외부에서 들어온 요청을 어떠한 서비스로 라우팅해주고, 같은 ip에 대해 다른 도메인 이름으로 요청이 들어왔을 때 가상 호스트 기반의 요청 처리, SSL/TLS 보안 연결 처리의 역할을 수행한다.
  
  외부의 요청을 대신 응답해주는 Reverse Proxy의 역할을 담당한다. Ingress를 이용해 각 Deployment에 대해 일일히 설정을 적용할 필요 없이 외부 요청에 대한 처리를 편리하게 관리할 수 있다.

Network

Pod 내 컨테이너들은 하나의 veth0을 공유하며 외부에서 같은 ip로 접근해 port로 컨테이너 구분된다.

컨테이너를 생성하면 veth 생성되고 컨테이너 내 eth0과 연결한다.
veth들은 docke0을 통해 컨테이너들간 통신 가능하다.
컨테이너는 gateway인 docker0을 거쳐 외부와 통신한다.

출처: https://medium.com/google-cloud/understanding-kubernetes-networking-pods-7117dd28727

이렇게 쿠버네티스의 구성 요소에 대해서 간략히 알아보았다.

쿠버네티스를 적용하면 편리한 면도 있지만, 프로젝트에 서비스 간 통신이 필요한지, 비용적인 여유가 되는지 등 다양한 고려가 필요하다.

상황에 알맞게 적용할 수 있어야 한다.

출처

Hash와 HashMap

Fri, 05 Nov 2021 12:00:00 GMT

서비스를 개발하거나 알고리즘, 자료구조를 공부하면서 Map, Set 등의 자료구조를 자주 이용했었다. Map 이나 Set 자료구조를 사용하면 자료의 양이 엄청 많아도 검색하는데 O(1) 만큼의 시간복잡도를 가지게 된다. 이렇게 빠른 검색을 위해 Map, Set을 구현하려고 보면 HashMap, HashSet 이라는 구현체를 통해 생성했을 것이다. 처음에는 그냥 당연히 Map과 Set 을 사용하려면 이렇게 써야 한다고 생각했었다. 하지만 계속해서 쓰다 보니 앞에 Hash가 의미하는 것이 뭔지가 궁금해졌다. 그렇다면 이번 글에서는 Hash의 개념과 Map에 대하여 살펴보자.

해싱이란?

해싱은 산술적인 연산을 이용하여 키가 있는 위치를 계산하여 찾아가는 검색 방식이다. 키값을 원소 위치로 변환하는 함수를 해시 함수(Hash Function)라 한다. 해시 함수에 의해 계산된 주소에 저장할 값을 저장한 표를 해시 테이블(Hash Table)이라 한다. 해시 테이블은 빠른 검색 속도를 제공하는데 이유는 내부적으로 버킷(배열)을 사용하여 데이터를 저장하기 때문이다. 해시 테이블은 각각의 key 값에 해시 함수를 적용해 배열의 고유한 인덱스를 생성한 후 인덱스를 이용해 값을 저장한다. 실제 값이 저장되는 장소를 버킷이라 한다.

어떤 수업을 듣는 10명의 학생에게 자리를 배정한다고 생각해보자. 이때 자리가 딱 10자리가 있고 10명의 학생은 각각 다른 이름을 가지고 있다. 그리고 좌석 번호를 생성하는 번호 생성기에 이름을 입력하면 좌석 번호가 나오게 된다. 이때 번호 생성기가 해시 함수의 역할을 한다. 그리고 좌석 번호와 학생 정보를 기록한 테이블은 해시 테이블이 된다.

해시 충돌

앞서 번호 생성기를 통하여 10명의 학생을 각각 자리에 앉혔다. 10명의 학생을 각각의 자리에 안내할 수 있었던 것은 사실 번호 생성기의 성능이 좋아 겹치지 않았다. 하지만 수업의 퀄리티가 좋아져 학생의 수가 갑자기 엄청나게 늘어났다. 기존의 번호 생성기는 0~20까지의 번호밖에 만들지 못했는데 학생의 수가 어느덧 30명이 되었다. 이제 필연적으로 겹치는 번호가 생성될 수밖에 없다. 그럼 이미 좌석 배정이 받은 학생이 있는 자리에 새로운 학생을 배정하게 되는데 이러한 경우가 해시 충돌 상황이다.

이러한 해시 충돌을 해결하는 방법에는 크게 두 가지 방법이 있다.

Open Addressing
Separate Chaining

Open Addressing은 이미 자리에 누군가가 있으면 다른 곳으로 배정하는 방식이다. 다른 곳에 배정하는 방식에 따라 Linear Probing과 Quadratic Probing 등의 방법이 있다.

Separate Chaining은 해시 테이블의 구조를 변경하여 하나 이상의 키값을 저장할 수 있도록 하는 방법이다. 이때 주로 사용하는 자료구조로 연결 리스트를 사용한다.

HashMap 에서의 Separate Chaining

HashMap에서 사용하는 충돌기법 방식은 Separate Chaining이다. Java 8 이전에의 HashMap에서는 단순히 연결 리스트를 사용하였다. 하지만 Java 8 이후부터는 데이터의 개수가 많아지면 연결 리스트가 아닌 트리 자료구조를 사용한다. 정확히 말하자면 레드 블랙 트리 자료구조이다. 그렇다면 데이터의 개수가 많아진다는 기준점은 무엇일까?

하나의 해시 버킷에 8개의 키-값 쌍이 모이면 연결 리스트를 트리로 변경하게 된다. 또한 버킷의 데이터를 삭제하여 개수가 6개에 이르면 다시 연결 리스트로 변경한다. 그럼 왜 6과 7 또는 7과 8이 아닌 6과 8이 기준이겠냐는 의문이 생길 수 있다. 이유는 차이가 1일 경우 삽입/삭제가 반복되어 일어나면 불필요하게 트리와 연결 리스트로 변경하는 일이 발생하기 때문이다.

해시 버킷의 확장

앞서 버킷에 관해 설명했듯이 버킷은 결국 배열로 구성되어 있다. 우리가 HashMap을 구현할 때 따로 버킷의 개수를 지정 해주지 않았다면 기본값인 16으로 버킷의 개수가 지정된다. 해시 버킷의 개수가 일정 개수 이상이 되면 버킷의 개수를 2배로 늘리게 된다. 버킷을 늘리면 해시 충돌의 가능성도 낮아져 해시 충돌로 인한 문제를 해결할 수도 있다. 하지만 두 배로 증가할 때마다 새로운 Separate Chaining을 구성해야 하는 문제가 있다. 가장 좋은 것은 버킷의 개수를 예측할 수 있다면 지정하여 HashMap을 생성하는 것이다. 따라서 데이터의 개수가 예측 가능하다면 지정하여 생성자의 인자로 넣어주면 불필요한 Separate Chaining을 줄일 수 있다.

Load Factor

해시 버킷의 개수가 일정 개수 이상이 되면 버킷의 수를 두 배로 늘린다 했는데 그럼 일정 개수는 어떻게 정할까? HashMap 클래스에 들어가 load factor 부분을 살펴보면 0.75f이라고 설정된 것을 볼 수 있다.

이 의미는 데이터의 개수가 현재 버킷 개수의 0.75 즉 3/4 이 되었을 때 두 배로 확장한다는 뜻이다.

정리

이번 글을 통하여 Hash와 HashMap에 대하여 알아보았다. 프로그래밍을 하는 사람이라면 배열이나 리스트만큼 자주 쓰는 자료구조인 Map일 것이다. 하지만 그 어떤 방식으로 Map이 구현되어 있는지는 관심 있게 보지 않으면 모르고 지나갔을 부분일 것 같다. HashMap은 해시 함수를 통하여 해시 테이블을 만들고 이를 기반으로 검색 시 빠른 속도를 낸다. 또한 해시 충돌을 방지하는 방법으로 open addressing과 separate chaining 방법이 있었다. 자바에서는 separate chaining을 이용하여 해시 충돌을 해결하였다.

참고

Java HashMap은 어떻게 동작하는가?

당신의 컴포넌트는 안녕하신가요

Mon, 01 Nov 2021 12:00:00 GMT

❗ 원지혁님의 컴포넌트, 다시 생각하기에서 얻은 인사이트를 정리한 글임을 밝힙니다.
❗ 필자의 생각도 많이 들어가 있으니 원본 영상도 함께 보는 것을 추천합니다!

🎯 개요

당신의 컴포넌트는 안녕하신가요?

조금 관심을 끌기 위한 멘트로 글을 시작했는데, 컴포넌트가 잘 지내는지 헬스 체크를 해보자는 의미였다. 잘 안 지낼 수도 있으므로… 🤣 아무튼, 이를 확인하기 위해 컴포넌트가 무엇인지부터 알아보도록 하자.

리액트 공식 홈페이지에서는 컴포넌트를 다음과 같이 표현하고 있다.

Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.

(컴포넌트는 UI를 독립적이고, 재사용 가능한 부분으로 분리해주며 각각을 고립시켜 생각할 수 있게 해줍니다.)

**‘독립적’, ‘재사용 가능하도록 분리’, ‘고립시켜 생각’**이라는 말들이 나오는데 우리가 만드는 컴포넌트가 완벽히 이러한 특징을 가지느냐고 자신에게 반문해보면 아마 아닐 것이다.

사실 위의 설명은 컴포넌트의 최대 목표를 의미하는 말이 아닐까 생각한다. 이러한 목표를 완벽하게 지키면 가장 좋겠지만, 개발하면서 위의 특징들을 못 지키는 사태가 빈번하다. 그래서 나는 이러한 특징들을 어느 정도 지키고 있는지 확인하는 것을 컴포넌트의 헬스 체크라고 명명하고, 주기적으로 이러한 헬스 체크가 이루어져야 한다고 생각한다.

그렇다면 헬스 체크에서 가장 중요한 개념은 무엇일까? 바로 의존성이다. 의존성을 잘 관리한 컴포넌트를 만들게 되면 유지보수 효율이 굉장히 올라가는데, 오늘은 컴포넌트 의존성에 대해서 얘기해볼 생각이다.

🙌 의존성이란?

의존성을 네이버 국어사전에 검색해보면 다음과 같이 설명하고 있다.

다른 것에 의지하여 생활하거나 존재하는 성질.

개발에서는 어떨까? 개발에서의 의존성이란 어떤 것과 다른 것이 변경에 있어서 서로 영향을 주고받는 관계를 의미한다.

예시로 자전거 조립 회사와 자전거 안장 제조 회사를 생각해보면 좋을 것 같다. 조립 회사가 안장 제조 회사에서 만드는 A 안장을 사용하고 있다고 가정해보자. 당연히 조립 회사는 안장 제조 회사에 의존한다. 안장 제조 회사에서 A 안장의 소재를 바꾸기라도 한다면 당연하게도 조립된 자전거의 안장도 소재가 변경될 것이다.

그렇다면 안장 제조 회사는 조립 회사에 의존되지 않을까? 아니다, 의존된다. 예를 들어 조립 회사가 안장 제조 회사에 A 안장의 소재를 바꾸어 A` 안장으로 바꾸어 달라는 요청을 한다. 당연히 될 줄 알았건만, 안장 제조 회사에서는 거절을 한다.

A 안장이 다른 조립 회사에서도 쓰고 있어서 그건 좀 곤란할 것 같아요 😥

그렇다. 우린 망했다. 안장 제조 회사도 조립 회사에 의존되어 함부로 수정할 수 없는 처지가 된 것이다. 이처럼 의존성이란 한 방향으로 이루어지는 것이 아닌, 양방향으로 영향을 주고받는 관계를 의미한다.

🤔 의존성 관리, 왜 중요한가요?

영향, 변경, 수정과 같은 얘기를 했는데, 약오르게 무언가 감이 잡힐 듯 말듯 한다. 🤔 의존성 관리가 중요한 이유는, 의존성 관리가 잘 되었을 때 예상치 못한 변경에 유연하게 대처할 수 있기 때문에 유지보수 효율이 굉장히 올라가기 때문이다.

혹시 유저 정보에 블로그 주소라는 데이터가 하나 추가되었을 뿐인데 매우 많은 컴포넌트를 수정해야 하는 경우, 또는 해당 변경 사항이 생겼을 때 어떤 컴포넌트를 수정해야 하는지 분명하게 알 수 없는 경우가 있었는지 한 번 생각해보자. 그것이 바로 의존성 관리를 해야할 때라는 신호이다.

그렇다면 의존성 관리는 어떻게 하는 걸까? 정답은 없지만, 의존성 관리의 가장 큰 줄기는 불필요한 의존성을 제거하거나 약화시키고, 불가피하게 강하게 의존되는 요소들은 가깝게 두는 것에 있다.

아니 뜬구름 잡지 말고 좀 더 자세히 알려주세요 ㅠ 😭

다행히도 선배 개발자분들이 많은 고민을 하셨고 우리에게 인사이트를 주고 있다. 같이 따라가 보자.

📜 컴포넌트의 많은 의존성

(출처 - 컴포넌트, 다시 생각하기)

컴포넌트가 의존하는 것은 대체로 다음과 같다.

1. 스타일

css-in-js의 경우 import하여 가져온 styles.ts 파일이라고 할 수 있다.

2. 로직

custom hook들을 의미한다.

3. 전역 상태

redux, react-query, recoil 등이 여기에 해당한다.

4. props(상위 컴포넌트 의존성)

props도 변경되면 상위 컴포넌트도 같이 변경되기 때문에 서로 의존한다고 할 수 있다.

5. 👑 서버 데이터 스키마

가장 중요하다고 생각한다. 전역 상태, 로직, 스타일 등의 변경은 많은 경우 서버 데이터 스키마의 변경에서부터 시작된다. 게시물 내용에 좋아요 개수가 추가된다든가 하는 경우가 있다.

😵 의존성 관리를 위한 4개의 원칙

이제 앞에서 살펴본 컴포넌트의 복잡한 의존성을 잘 관리할 수 있는 4개의 원칙에 대해서 알아보자.

여기 소개된 4개의 원칙이 항상 정답은 아니므로 더 개선하기 위해서는 어떻게 할 수 있을지 열린 마음으로 바라보면 좋을 것 같다.

스스로 드는 회초리가 가장 값진 법. 필자가 개발에 참여한 놀토 - 놀러오세요 토이프로젝트라는 플랫폼의 나쁜 예시를 알아보고 개선하면서 원칙을 소개해보도록 하겠다.

1. 비슷한 관심사라면 함께 두기

비슷한 관심사, 즉 깊은 의존성을 지닌 것들끼리는 한 폴더에 같이 두는 것이 좋다. 그래야 어떤 컴포넌트를 수정할 때, 컴포넌트가 의존하는 파일을 찾느라 고생하지 않아도 된다. 집중력이 분산되지 않고, 효율적으로 컴포넌트를 수정할 수 있다.

👎 나쁜 예시

OAuth 로그인을 처리하는 페이지 컴포넌트다. useOAuthLogin이라는 커스텀 훅은 OAuth에서만 쓰이고 있지만, 해당 훅 파일은 hooks 폴더에 따로 떨어져 있다.

👍 개선해보기

의존성이 깊은 파일끼리 모아주기 위해 얼른 OAuth 폴더로 넣어주자.

2. 데이터를 Id 기반으로 정리하기

클라이언트에서 데이터를 Id를 통해 전역적으로 관리하면 큰 이점이 있다. 바로 상위 컴포넌트에서 해당 데이터의 스키마를 알 필요가 없고, Id만 내려주면 하위 컴포넌트가 원하는 데이터에 바로 접근할 수 있다는 점이다. 이렇게 되면 상위 컴포넌트는 데이터 스키마에 의존하지 않기 때문에, 데이터 스키마의 변경이 일어나도 상위 컴포넌트를 수정할 필요가 없다

👎 나쁜 예시

예시로 인기 있는 토이 프로젝트를 나타내는 HotFeedsContent와 LargeFeedCard 컴포넌트를 확인해보자.

우선 컴포넌트를 모델 기준으로 나눈 것이 아니라 현재 UI 형태를 기준으로 나눈 것부터 문제다. Large라는 모호한 네이밍으로 컴포넌트를 만들었기 때문에 해당 컴포넌트에서 데이터를 가져오기에 애매해졌다. 그래서 상위 컴포넌트에서 feed를 prop으로 받아오고 있다. 이렇게 되면 상위 컴포넌트인 HotFeedsContent가 feed 데이터 스키마를 알고 있어야 하는 것이므로 하위 컴포넌트와의 의존성이 강해진다.

👍 개선해보기

LargeFeedCard -> HotFeedCard로 컴포넌트 네임을 수정하기 컴포넌트를 모델 관점에서 바라보기 위해서 네임을 수정
HotFeedCard의 prop으로 feedId를 받아오도록 수정 기존에는 feed를 그대로 상위 컴포넌트에서 주입하고 있었기 때문에 feed 데이터 스키마가 변경되면 상위 컴포넌트도 같이 변경해야 했다.

feedId를 prop으로 받도록 수정하여 의존성을 느슨하게 만들어주었다. useData는 전역 상태 저장소에 접근할 수 있는 훅으로 가정했다.

3. 의존성을 그대로 드러내기

의존성을 prop 구조에 그대로 드러내면 컴포넌트 의존 구조가 명확히 보이고 어떻게 의존성을 느슨하게 만들어야 하는지 눈에 보인다. 그래서 의존 관계를 prop 구조나 이름에 그대로 드러내는 것이 좋다.

👎 나쁜 예시

토이 프로젝트를 나타내는 RegularFeedCard 컴포넌트를 확인해보자.

author 같은 경우는 의존 구조가 명확하지만 thumbnailUrl은 다른 목적의 모델임에도 의존 관계가 표현되지 않고 있다.

👍 개선해보기

feed와 thumbnail의 의존 구조를 명확하게 표현해주기 thumbnail도 따로 의존 관계를 prop에 표현해 주었다.
컴포넌트가 2개 이상의 모델에 의존하고 있는 것이 보인다면 Id 기반으로 정리하여 의존성을 약화시키자. thumbnail의 의존 관계를 prop 구조에 표현해주니 RegularFeedCard 컴포넌트가 feed 외에도 thumbnail, author 등, 2개 이상의 모델에 의존되고 있다는 것이 보인다.

하나의 모델에만 의존되게 하기 위해 2번 원칙인 Id 기반으로 정리하고, 각 컴포넌트에서 필요한 데이터 스키마를 컴포넌트 내부에서 정의해준다. 이렇게 만들면 RegularFeedCard와 Thumbnail은 서로 데이터 스키마에 대해 알 필요가 없으므로 의존 관계를 느슨하게 만들 수 있다.

4. 컴포넌트의 재사용 기준은 모델이다.

개발할 때 편리한 것보다 변경할 때 편리하기 위해서의 관점으로 컴포넌트를 나누는 것이 좋다. 보통 모델(데이터의 목적)에 따라 변경이 자주 이루어지므로 모델이 같다면 재사용하고, 다르다면 컴포넌트를 분리하도록 하자. 모델이 다르지만 현재 UI가 같다고 컴포넌트를 재사용하게 되면, 추후 모델에 따라 다른 UI 변경점이 생길 때 곤란해진다.

👎 나쁜 예시

진행 중인 프로젝트와 완성된 프로젝트의 UI가 같다는 이유 때문에, RegularFeedCard 컴포넌트로 재사용되고 있다. 하지만 진행중 프로젝트와 완성된 프로젝트의 모델은 다르다. 현재는 UI가 같지만, 모델이 다르기 때문에 충분히 다른 방식으로 변화할 가능성이 있다. 예를 들어 완성된 프로젝트의 모델은 배포 url을 가지기 때문에 나중에는 서비스로 이동하기라는 버튼이 완성된 프로젝트 카드에만 추가될 수도 있을 것이다.

👍 개선해보기

RegularFeedCard를 ProgressFeedCard, CompleteFeedCard 2개의 컴포넌트로 분리한다. 이렇게 분리하게 되면 모델에 따라 카드의 형태가 달라진다 해도 쉽게 변경할 수 있을 것이다.

🎉 마무리 - 사실 이보다 더 중요한 것

사실 4개의 원칙보다도 본인의 경험에서 불편함을 찾는 자세가 굉장히 중요하다고 생각한다. 4개의 원칙을 완벽하게 적용해도 분명히 어딘가 유지 보수하기 불편한 점이 있을 것이다. 거기서 스스로 개선까지 할 수 있으면 금상첨화지만, 불편함을 찾는 것만으로도 성장할 준비가 되어있다는 의미이기 때문에 괜찮은 경험이라고 생각한다. 그 상태에서 누군가 조금 이끌어주는 것만으로도 크게 성장할 수 있을 것이다.

나도 컴포넌트 기반으로 개발을 하면서 간혹 파일을 찾기 위해서 폴더를 굉장히 많이 뛰어넘는다든가, 하나의 수정 사항이 생길 때 여러 컴포넌트를 수정해야 하는 등 불편함을 많이 느끼고 있었는데 마침 좋은 영상을 접하게되어 큰 인사이트를 얻을 수 있었다.

앞으로는 컴포넌트 개발을 하면서 컴포넌트 의존성을 도식화하는 습관을 지녀야겠다. 도식화하여 어떤 부분에서 의존성이 강한지 한눈에 파악하고, 어떻게 더 나은 방법으로 개선할 수 있을지 고민하는 사람이 되고 싶다.

Tecoble

다중 이미지 업로드 최적화: 병렬 스트림과 CompletableFuture

예제 코드 소개

순차적 업로드 방식

성능 측정

병렬 스트림을 활용한 업로드

성능 측정

병렬 스트림 사용 시 주의점

공유 자원과 ConcurrentModificationException

병렬 작업 종료 후 통합 예외 처리

병렬 스트림의 제약점

CompletableFuture를 활용한 병렬 업로드

성능 측정

마무리

JPA가 Fetch Join에 대한 On절을 지원하지 않는 이유

JPA가 Fetch Join에 대한 On절을 지원하지 않는 이유

참고 ERD

쿼리 확인

Fetch Join으로 개선하기

Fetch Join의 한계

On절 대신 Where절로 사용하기

Fetch Join의 On절을 지원하지 않는 이유는 무엇일까?

Fetch Join과 Where절의 함정 그리고 Outer Join

검증 - Outer Fetch Join과 Where절 필터링

결과

요약

데이터베이스 복제하기(리플리케이션) 2 - 테코와 알아보는 대규모 데이터 관리

테코의 고민 2 - 이벤트에 어떤 내용을 기록해야 해?

변경된 데이터를 기록한다면 - Row 포맷

실행한 SQL을 기록한다면 - Statement 포맷

두 방법의 장점만 취할 수 있다면 - Mixed 포맷

요약

테코의 고민 3 - 복제하는 동안 데이터에 차이가 있지 않을까

비동기

‘반’동기

성능과 정합성 사이의 줄다리기

요약

번외 - 리플리케이션 구조(토폴로지)

싱글 리플리카 복제 구성

멀티 리플리카 복제 구성

체인 복제 구성

듀얼 소스 복제 구성

ACTIVE-PASSIVE와 ACTIVE-ACTIVE

요약

데이터베이스 복제하기(리플리케이션) 1 - 테코와 알아보는 대규모 데이터 관리

데이터베이스를 하나 더 두자 - 스케일 아웃

여러 개의 데이터베이스가 어떻게 데이터를 똑같이 가져? - 리플리케이션 개요

MySQL의 리플리케이션

테코의 고민 1 - 바이너리 로그를 어떻게 식별할까

1. 바이너리 로그 이벤트의 이름과 위치를 통해 식별하자

위 방법의 문제점

2. 바이너리 로그 이름을 통일해서 사용하자

GTID 기반 복제의 효과

요약

로컬에서도 프로덕션과 유사한 환경에서 테스트할 수 없을까? : Testcontainers 도입기

문제 상황 : 로컬에서는 H2, 프로덕션에서는 MySQL

1차 해결 방안 : 로컬에서 Flyway를 사용하지 않는 방법

2차 해결 방안 : 벤더 별로 Flyway Migration File 각각 작성

3차 해결 방안 : Docker를 띄워볼까?

최종 해결 방안 : Testcontainers를 사용하자

Testcontainers

Testcontainers의 장점

1. 격리된 인프라 제공

2. 로컬 및 CI 환경 모두에서 일관된 테스트

3. 대기 전략을 사용한 안정적인 테스트 설정

4. 고급 네트워킹 기능

5. 자동 초기화

Testcontainers 사용법

기본적인 사용 방법

첫 번째 방법 : 컨테이너에 대한 인스턴스 생성

두 번째 방법 : JUnit5의 @ExtendWith 사용

두 가지 방법의 공통된 장점

두 가지 방법의 공통된 단점 및 해결방법

세 번째 방법 : Datasource URL 설정

마치며

참고 자료

useLayoutEffect를 활용한 산발적 마커 렌더링 최적화

마커 렌더링 최적화

서비스 소개

1. 개요

공유 자원과 `ConcurrentModificationException`