어? 되네? 어? 안되네?

OOM 원인 분석기, 근데 이제 데드락과 스레드

jimkwon — Mon, 12 May 2025 09:31:17 +0900

시리즈로 나오지 않기를 간절히 바라며 포스팅을 시작합니다..

문제 발생: Heap도 안 찼는데 OOM?

이틀에 한 번 꼴로 날라오는 OOM 발생 메일..
늘 그렇듯 원인 분석을 위해 힙 덤프 파일을 요청하려 했으나 예상 외의 답변이 돌아왔다.

예?

실제 OOM이 발생하는 시기의 Heap 메모리 영역을 확인해보니

최대 용량으로 지정해놓은 1Gib에 한참 밑도는 상황에서 터지는 것을 알 수 있었다.

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: GC Overhead limit exceeded
java.lang.OutOfMemoryError: Requested array size exceeds VM

애플리케이션 내부에서 OOM이 발생하여 종료된다면, 위처럼 로그 내부에서 힌트를 얻을 수 있겠지만,

현재는 ECS가 컨테이너를 모니터링하며 전체 메모리 사용량(힙 + 네이티브 + 스택 메모리)이 지정된 한도를 넘을 경우 컨테이너를 종료하는 상황이다.

→ 따라서 어플리케이션이 로그를 남기고 죽기 전에 ECS에서 먼저 컨테이너를 죽여버려서 덤프파일도, 로그도, 아무것도 얻지 못하는 상황..

빈 손으로 털레털레 데이터독으로 들어가 APM 항목을 훑어보던 중 특이한 점을 발견할 수 있었는데

바로 스레드의 수가 비정상적으로 높다는 것

단서 발견: DataDog에서 보인 ‘스레드 수’

확실히 스레드의 개수가 높아진 시점과 OOM이 발생한 시점이 비슷해보인다.

운영 환경의 인증 서버의 경우 동일대 시간으로 봤을 때 대략 70개 전후의 스레드 개수에 비해

문제가 발생하는 회원 서버의 경우에는 최대 2.28k의 개수까지 치솟고 있는 것을 확인할 수 있었다.

단순히 개수가 많다고 해서 OOM과 연관이 있는 것은 아니나, 스레드는 일정 시간이 지나면(자신이 해야 할 일을 다 했다면) 회수 되어야 한다.

인증 서버의 경우 잠시 증가된 스레드는 일정 시간 후에 회수되고 있으나, 회원 서버 의 경우 회수되는 것에 비해 증가 폭이 큰 것을 볼 수 있었다.

만약 스레드가 회수되지 못해 메모리에 남게 된다면 OOM의 주 원인이 될 수 있다.

문제 재현을 위한 부하 테스트 환경 구성

⚙️ 테스트 도구 & 환경 세팅

부하 테스트: Apache JMeter
JVM 모니터링: visualVM
JVM 옵션: -Xmn100m -Xmx300m

인텔리제이 내부의 플러그인을 설치하여 간편하게 연동하여 사용할 수 있다.
(설치 및 연동은 이곳을 참고하자)

테스트 대상 API 분석 및 선정

메모리가 급증하는 구간과 평탄한 구간 마다 가장 많이 호출됐던 API 리스트를 뽑아봤을 때
거의 순위가 차이가 없음을 발견했다.

→ 갑작스러운 메모리 폭증보다는, 빈번한 호출로 인해 서서히 쌓이는 메모리 누수일 가능성이 높다고 판단.

최종 테스트 대상 API 3종:

POST /v1/login
POST /v1/auth/member/log/{memberLogType}
GET /v1/auth/member

마지막으로 JMeter에 테스트 환경까지 구성해주면 테스트 진행 준비는 끝났다.

가장 자주 호출되는 login API부터 테스트했다.
100명의 유저(스레드)가 1초 안에 실행되고, 총 250회 반복.

결과는…

Heap은 안정적
GC는 Eden → Survivor에서 정상적으로 Minor GC 수행
Old 영역 진입 없음
테스트 후 스레드 수 복구 OK

→ 1번 API는 범인 아님 확정!

2차 테스트: Member Log API에서 데드락이?

이 API는 로그인/로그아웃 등 이벤트 로그를 남기는 기능이다.
테스트 중간에 갑자기 발생한 데드락 로그…

데드락 원인 분석

해당 API 내부 로직은 다음과 같다:

@Transactional
public MemberResponse.Result createMemberLog(...) {
    member.updateLastLoginDateTime();
    eventPublisherComponent.publishMemberEvent(...);
}

그리고 로그 저장은 이렇게 처리하고 있었음

@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
public void logEvent(MemberLogDto memberLogDto) {
    memberLogRepository.save(...);
}

데드락이 발생할 수 있는 이유는

@TransactionalEventListener 의 BEFORE_COMMIT 으로 커밋 직전에 해당 logEvent메소드가 실행된다.
MemberLog는 Member와 연관관계인 상태 (동일한 member를 참조할 수 있다.)
같은 트랜잭션 내부에서 아래와 같이 멤버를 수정하려고 할 때 데이터베이스에서 ‘잠금(Locking)’이 발생하면, MemberLog를 저장하려 할 때 동일한 테이블에 대한 잠금이 필요해질 수 있다

if(memberLogType.equals(MemberLogType.LOGIN)){
    member.updateLastLoginDateTime();  
}  // ---> 여기서 1차적으로 Member 테이블에 접근하여 락이 걸리고



final MemberLog memberLog = memberLogDto.toEntity();
memberLogRepository.save(memberLog);
  // ---> 로그 저장하는 시점에서 MemberLog와 연관관계인 Member 테이블에 접근하여 락이 걸림

( 실제로 운영환경에서도 데드락 이슈가 간간히 발생하고 있었다..! )

데드락 해결을 위한 코드 수정

다음과 같이 트랜잭션 종료 후 비동기로 로그를 처리하도록 수정했다:

@Async
@Transactional
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void logEvent(MemberLogDto memberLogDto) {
    memberLogRepository.save(...);
}

AFTER_COMMIT으로 바꾸고, 비동기로 처리하여 락 충돌 방지.

그런데... 또 Heap이 급등?

테스트를 다시 해보니 Heap이 급등하고, GC의 Old 영역도 확연히 증가하는 양상을 보였다

→ 데드락은 잡았지만 또 다른 문제가 숨어 있었다.

스레드 누수의 진짜 원인 - Async 설정

AsyncConfig를 살펴보니...

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {
    @Bean
    public Executor threadPoolTaskExecutor() {
        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
        taskExecutor.setTaskDecorator(new CustomDecorator());
        return taskExecutor;
    }
}

눈에 띈 문제점:

corePoolSize, maxPoolSize, queueCapacity 설정 없음
스레드 종료 처리 없음
RequestContextHolder를 통한 ThreadLocal 사용
비동기 종료 후 RequestAttributes 미정리

→ 스레드를 계속 생성하면서 회수가 안 되는 구조
→ RequestContextHolder가 스레드에 남아 있어서 누수 발생

✅ 최종 조치

부하 테스트를 통해 파악한 API에 대한 조치 내용은 다음과 같다.

1. 데드락 해결

@Component
@RequiredArgsConstructor
public class MemberLogListener {

    private final MemberLogRepository memberLogRepository;

    @Async
    @Transactional
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void logEvent(MemberLogDto memberLogDto) {
        final MemberLog memberLog = memberLogDto.toEntity();
        memberLogRepository.save(memberLog);
    }

}

→ AFTER_COMMIT을 사용하여 트랜잭션이 끝난 후에 이벤트를 처리하도록 설정
@Async 와 함께 비동기 이벤트 처리를 사용하여 트랜잭션이 끝난 후 별도의 스레드에서 이벤트를 처리

2. @Async 설정 수정

@Bean
public Executor threadPoolTaskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(2);
    taskExecutor.setMaxPoolSize(50);
    taskExecutor.setQueueCapacity(500);
    taskExecutor.setThreadNamePrefix("Async-");
    taskExecutor.setTaskDecorator(new CustomDecorator());
    return taskExecutor;
}

→ 스레드 풀 관련 설정 추가

public class CustomDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(@NotNull Runnable runnable) {
        RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();
        return () -> {
            try {
                RequestContextHolder.setRequestAttributes(requestAttributes);
                runnable.run();
            } finally {
                RequestContextHolder.resetRequestAttributes();  // 꼭 정리!!
            }
        };
    }
}

→ try-finally 작업을 통해 비동기 작업이 완료된 후, RequestAttributes를 정리하는 로직을 추가했음

테스트 결과

Heap: 안정적, GC도 Minor에서 반복 처리 잘됨
Old 영역 증가 없음
테스트 종료 후 스레드 수 정상 복구

근데 찝찝한 점 하나

애초에 OOM이 났던 시점에는 @Async가 적용되지 않았다는 것

테스트 중 데드락 이슈를 고치면서 @Async가 붙었기 때문에, 이 조치가 진짜 OOM을 해결한 것인지는 아직 확신할 수 없다.

하지만 이 외에도 @Async를 사용하는 코드가 서비스 곳곳에 있었기 때문에
전체적으로 누적된 메모리가 있었을 가능성은 매우 크다고 판단.

→ 결국 실제 PR 환경에 배포하고 나서 계속 메모리 추이 관찰 예정

번외

모니터링 도구를 보면, 기동 후 아무것도 하지 않아도 주기적으로 힙 메모리가 쌓이고 줄어드는 모양이 반복된다? (like 바트 머리)

이건 JVM 내부의 백그라운드 GC 최적화로 인해 자연스럽게 발생하는 패턴이다.

Spring Batch StepScope 사용 시 Entity Not Mapped 오류 해결법 (다중 데이터소스 환경)

jimkwon — Tue, 6 May 2025 19:23:20 +0900

Spring Batch에서 Entity Not Mapped 오류 발생

Spring Batch에서 여러 데이터소스를 설정하고,
그 중 하나(subEntityManagerFactory)를 이용해서 JpaPagingItemReader로 조회하려고 했다.
하지만 Batch 실행 중 다음 에러가 발생했다.

org.hibernate.hql.internal.ast.QuerySyntaxException: EntityA is not mapped

처음엔 Entity 매핑 문제를 의심했지만, 엔티티도 제대로 선언되어 있었고, Config도 문제없었다.
결국 원인은 EntityManagerFactory 주입 방식 문제였다.

Bean 주입 시점과 프록시로 발생한 문제 분석

Batch는 기본적으로 ApplicationContext 기동 시점에 모든 빈을 싱글톤으로 생성한다.
그런데 @StepScope를 사용하면 Step 실행 시점에 빈이 생성된다.
이때 필드에 주입되어 있던 EntityManagerFactory는 실제 객체가 아니라 프록시(Proxy) 객체다.
문제는 이 프록시가 내부적으로 기본 EntityManagerFactory를 바라볼 수도 있다는 점.

@StepScope
public JpaPagingItemReader<EntityA> entityReader() {
    ...
    .entityManagerFactory(entityManagerFactory) // ❌ 프록시 주입 → 실제 대상이 기본 DB일 수 있음
}

결과적으로 JpaPagingItemReader는 기본 DB를 바라보게 되고, EntityA를 찾지 못해 에러가 발생한다.

(Entity A는 기본 DB가 아닌 멀티데이터소스 설정으로 인해 다른 DB에 존재하고 있으니!)

진짜 핵심은 StepScope의 생성 타이밍 때문에, 필드 주입은 신뢰할 수 없다는 것.

StepScope란? Spring Batch에서의 Bean 생명주기 설명

Step 실행 시점에 Bean을 생성한다.

Step마다 새로운 객체가 만들어진다.

주로 ItemReader, ItemProcessor, ItemWriter 같은 Step 내부 컴포넌트에 붙인다.

StepExecutionContext 범위 안에서 관리된다.

✅ 사용하는 이유

매 Step 실행마다 다른 데이터를 주입하고 싶을 때 (예: JobParameter, 현재 날짜 등)

Step 실행 전에는 Bean을 생성하지 않고, Step 실행 시점에 생성하기 위해

✅ Bean 생성 타이밍

애플리케이션 기동 시점 → Proxy 객체만 등록

Step 실행 시점 → 실제 Bean 생성

기존 코드

@Slf4j
@Configuration
@RequiredArgsConstructor
public class SampleBatchJobConfig {

    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;

    @Qualifier("subEntityManagerFactory")
    private final EntityManagerFactory entityManagerFactory;

    @Bean
    @StepScope
    public JpaPagingItemReader<EntityA> entityReader() {
        Map<String, Object> params = new HashMap<>();
        params.put("targetDate", LocalDate.now());
        params.put("status", StatusType.ACTIVE);

        return new JpaPagingItemReaderBuilder<EntityA>()
                .name("entityReader")
                .entityManagerFactory(entityManagerFactory) // 문제 발생 지점
                .pageSize(100)
                .queryString("""
                    SELECT e
                    FROM EntityA e
                    WHERE e.expireDate < :targetDate
                    AND e.status = :status
                """)
                .parameterValues(params)
                .build();
    }
}

개선된 코드

@Slf4j
@Configuration
@RequiredArgsConstructor
public class SampleBatchJobConfig {

    private final JobBuilderFactory jobBuilderFactory;
    private final StepBuilderFactory stepBuilderFactory;

    @Bean
    @StepScope
    public JpaPagingItemReader<EntityA> entityReader(
            @Qualifier("subEntityManagerFactory") EntityManagerFactory subEntityManagerFactory) {

        Map<String, Object> params = new HashMap<>();
        params.put("targetDate", LocalDate.now());
        params.put("status", StatusType.ACTIVE);

        return new JpaPagingItemReaderBuilder<EntityA>()
                .name("entityReader")
                // ✅ 메소드 파라미터 주입
                .entityManagerFactory(subEntityManagerFactory) 
                .pageSize(100)
                .queryString("""
                    SELECT e
                    FROM EntityA e
                    WHERE e.expireDate < :targetDate
                    AND e.status = :status
                """)
                .parameterValues(params)
                .build();
    }
}

이렇게 수정된 코드에서는 @StepScope 빈에서 필드 주입 대신 메서드 파라미터 주입을 사용하여, EntityManagerFactory를 정확하게 주입할 수 있게 처리했다.

이를 통해 프록시 객체가 아닌 실제 subEntityManagerFactory가 주입되도록 설정한다.

StepScope에서 메서드 주입을 통한 문제 해결

@StepScope 빈에서는 필드 주입 대신 메소드 파라미터 주입을 사용한다.
@Qualifier를 메소드 파라미터에 붙여서 원하는 EntityManagerFactory를 정확히 지정한다.
프록시가 개입하지 않고, 실제 객체가 정확히 주입된다.

StepScope와 JobScope의 차이점 및 사용 시점

구분	StepScope	JobScope
생성 시점	Step 실행 시점	Job 시작 시점
스코프 범위	Step마다 새로운 객체 생성	Job마다 하나의 객체 생성
주 사용처	Reader, Processor, Writer 같은 Step 단위 컴포넌트	Job 전체 설정, 공통 값 공유할 때
예시	매 Step마다 날짜, 상태값 다르게 쓰고 싶을 때	전체 Job에서 파라미터를 공유할 때

한마디로 정리하면

@StepScope : Step이 실행될 때마다 다른 값을 쓸 수 있게 해주는 스코프
@JobScope : Job 단위로 한 번만 초기화되고 여러 Step이 공유하는 스코프

최종 정리

@StepScope가 붙은 Bean에서는 무조건 메소드 파라미터 주입을 쓰자.
특히 다중 데이터소스 환경에서는, 어떤 EntityManagerFactory가 주입되는지 명확히 해야 한다.
이걸 놓치면 Hibernate가 기본 DB를 바라보다가 원하는 Entity를 찾지 못해서 터진다.

느낀 점

처음엔 단순한 엔티티 매핑 문제라고 생각했다. (이 것 때문에 진짜 오만가지 설정을 다시 해보고 난리였음..ㅠ)
근데 진짜 원인은 Bean의 생성 시점 차이였고, 그걸 이해하니까 모든 게 풀렸다.

Batch + 다중 데이터소스 + StepScope 조합은 StepScope의 동작 방식을 이해하고 잘 써야 한다.
이제부터는 @StepScope 쓰면 무조건 파라미터 주입을 사용하는 습관을 들이자.

자바의 로봇청소기, 가비지 컬렉션

jimkwon — Tue, 9 Jul 2024 22:07:38 +0900

자바에는 가비지 컬렉션(Garbage Collection) 이라는 기능이 있습니다.

영문 뜻으로 짐작할 수 있듯이 사용하는 객체의 메모리를 주기적으로 검사해서 청소해주는 일을 합니다!

C와 C++같은 Unmanaged language는 free()와 같은 함수를 사용해서 직접 메모리를 해제하는 반면
Garbage Collector는 이러한 번거로운 일을 대신 해주고 있는 것이죠! (like 로봇청소기)

♻ 가비지 컬렉션 ( vs 가비지 컬렉터)

먼저, 헷갈릴 수 있는 두 용어를 정리하고 가겠습니다.

가비지 컬렉션

메모리 관리 프로세스로, 더 이상 사용되지 않는 메모리(객체)를 자동으로 찾아서 회수하는 작업
→ 청소

가비지 컬렉터

가비지 컬렉션을 수행하는 구성요소. 불필요한 메모리를 실제로 찾아내고 해제하는 주체
→ 청소기

♻ 가비지 컬렉션의 제거 기준

그렇담 가비지 컬렉션은 어떠한 기준으로 선정된 객체들을 지워버릴까요?

바로 도달성(Reachability) 이라는 개념을 통해 판단합니다.

Reachable : 객체가 참조되고 있는 상태
Unreachable : 객체가 참조되고 있지 않은 상태

객체에 유효한 참조가 없다면(Unreachable) 수거 대상으로 판단하고 지워버리게 됩니다.

청소좌..

♻ JVM 메모리에서의 객체들

Heap 영역 : 실질적으로 객체들이 생성되는 곳

이외의 Stack과 Method 영역에서는 Heap영역에서 생성된 객체의 주소를 참조하는 형식으로 구성됩니다.

보통 다음과 같은 상황에서 Heap에 있는 객체를 참조하는 변수들이 삭제됩니다.

변수의 Scope를 벗어남
→ 메소드 안에서 선언된 지역변수가 있을 때, 해당 메소드가 종료됨
참조가 다른 객체로 변경됨
→ 다른 Heap 영역의 객체를 참조하게됨
참조 변수가 null로 설정
→ 이전에 참조하면 객체에 대한 연결이 끊어짐
클래스 인스턴스의 소멸
→ 객체가 속한 클래스의 인스턴스가 소멸되면 내부의 참조변수도 같이 소멸

이러한 상황에서 2번 객체와 같이 Unreachable상태가 되며, 가비지 컬렉터의 수거 대상이 됩니다

♻ 가비지 컬렉션의 청소 과정

그렇다면 가비지 컬렉션은 어떠한 방식으로 청소를 하는지 좀 더 자세히 단계별로 살펴보겠습니다!

Mark And Sweep

가비지 컬렉션이 동작하는 아주 기초적인 청소과정으로, 다양한 GC에서 객체를 솎아내기 위해 사용되는 내부 알고리즘입니다.

1. Marking (마킹)
GC는 모든 객체를 순회하며 참조된 객체와 참조되지 않은 객체를 구분하여 마킹합니다.

2. Sweep (삭제)

참조되지 않은 객체들(Unreachable)을 Heap에서 제거합니다.

2-a . Compact (압축)

(GC 종류에 따라 해당 단계가 포함되기도, 안되기도함 )

Sweep 단계를 통해 신나는 대청소 후 분산된 객체들을 Heap 시작 주소로 모아 압축합니다.

이렇게 한 데 모아두면 새로운 메모리 할당이 훨씬 쉽고 빨라지겠죠?

GC의 Root Space

https://deepu.tech/memory-management-in-programming/

Mark And Sweep(청소)를 진행하기 위해서, GC는 루트 공간을 시작으로 참조를 통해 도달할 수 있는 모든 객체들을 “살아있는“ 객체로 간주하고, 이외의 죽은(ㄷㄷ)녀석들을 청소하는 것이죠

루트 공간(Root Space)은 다음과 같습니다!

Stack의 로컬 변수
Method Area의 Static 변수
Native Method Stack의 JNI 참조

♻ 가비지 컬렉션의 실제 동작 과정

아래는 Runtime Data Area에 대한 그림입니다
그게 무엇인고 하면 JVM이 프로그램을 수행하기 위해 OS로부터 할당받는 메모리라고 보시면 됩니다.

이 중 Heap과 Method Area는 모든 스레드가 공유하는 영역이죠!

https://jithub.tistory.com/40 자세한 내용은 이곳에서

가비지 컬렉션은 ‘객체의 메모리’를 주기적으로 청소합니다.

즉, 가비지 컬렉션의 대상이 되는 공간은 실제 객체가 존재하는 공간인 힙(heap)영역입니다.

그렇담 실제 힙 메모리의 구조는 어떻게 되는지 자세하게 파헤쳐 봅시다!

♻ GC의 weak generational hypothesis

https://docs.oracle.com/en/java/javase/16/gctuning/garbage-collector-implementation.html#GUID-23844E39-7499-400C-A579-032B68E53073

가비지 컬렉션의 수행(mark and sweep!)에서 매번 추적을 진행한다면, 상당한 부하가 있을겁니다!

위 그래프는 대부분의 응용 프로그램들의 object 수명을 나타낸 그래프인데요,

x축 : 측정된 object의 lifetime
y축 : lifetime이 있는 개체의 총 Byte

이 결과를 다음 사실을 알 수 있습니다!

대부분의 객체는 금방 소멸한다. (접근 불가능한 상태)
오래된 객체에서 새로운 객체로의 참조는 아주 적게 존재한다.

이를 weak generational hypothesis 이라고 합니다

힙 메모리 구조는 어디가고 이 가설을 난데없이 먼저 말하는가?

위 가설에 대한 전제를 토대로 Heap 영역이 처음 설계되었기 때문입니다.

♻ Heap의 Young과 Old 영역

효율적인 메모리 관리를 위해, 객체의 생존 기간에 때라 두 가지 물리적 영역으로 나눴습니다

초기(Java7)에는 Perm 영역도 존재했지만,
Java8버전 이후에는 Native Method Stack에 편입되어 사라집니다.

https://aws.amazon.com/blogs/big-data/understanding-the-jvmmemorypressure-metric-changes-in-amazon-opensearch-service/

Young 영역(Young Generation)

새롭게 생성된 객체가 할당(Allocation)되는 영역
대부분의 객체가 금방 Unreachable 상태가 되기 때문에, 많은 객체가 Young 영역에 생성되었다가 사라진다.
Young 영역에 대한 가비지 컬렉션(Garbage Collection)을 Minor GC라고 부른다.

Old 영역(Old Generation)

Young영역에서 Reachable 상태를 유지하여 살아남은 객체가 복사되는 영역
Young 영역보다 크게 할당되며, 영역의 크기가 큰 만큼 가비지는 적게 발생한다.
Old 영역에 대한 가비지 컬렉션(Garbage Collection)을 Major GC 또는 Full GC라고 부른다.
큰 객체들은 바로 Old 영역에 할당됨

♻ Young 영역의 분리 → Eden, Survival0, Survival1

더더더더욱 효율적인 GC를 위해 Young 영역도 다음과 같이 세가지로 나눕니다.

Eden

new를 통해 새로 생성된 객체가 위치.
정기적인 쓰레기 수집 후 살아남은 객체들은 Survivor 영역으로 보냄

Survivor 0 / Survivor 1

최소 1번의 GC 이상 살아남은 객체가 존재하는 영역
Survivor 영역에는 Survivor 0 또는 Survivor 1 둘 중 하나에는 꼭 비어 있어야 하는 특별한 규칙이 있다.

♻ Minor GC 과정 (in young Generation)

1. 먼저, 새로운 객체가 eden 영역에 할당됩니다.

2. eden공간이 가득 차면 GC가 시작됩니다!

3. 마킹작업을 통해 참조된 객체들은 첫 번째 생존공간 (S0)으로 이동합니다!

이때 살아남은 녀석들의 age값이 1씩 증가합니다.

age?
객체가 Survivor 영역에서 살아남은 횟수를 의미. Object Header에 기록된다.
age값이 특정 임계값에 다다르면 Old 영역으로 이동한다.
가장 일반적인 HotSpot JVM의 의 경우는 31이다. (객체 헤더의 age 영역이 6bit임)

4. 다음 마이너 GC단계에서도 Eden이 가득차면 3번과 같이 생존공간으로 이동됩니다!
이 때, 기존 S0공간에 있던 객체중 생존 + Eden에서 생존한 객체들은 모두 S1 공간으로 이동하게 됩니다!

5. 이후 Eden 영역이 가득 차면 4번과 동일한 프로세스가 반복됩니다.
다만, 이번엔 S1이 아닌 S0 공간으로 이동하게 됩니다.

이렇듯 GC가 발생할 때마다 (Eden영역의 공간이 가득차면) 다음 일이 반복되는 프로세스를 보여줍니다

Eden에서 살아남은 객체가 ‘전환된 Survivor공간으로 이동되고, age가 1 증가’
기존 Survivor공간에서도 살아남은 객체가 있으면 ‘전환된 Survivor공간으로 이동되고, age가 1 증가'

두 경우에 해당하면 age가 증가하고, 특정 임계치에 다다르면 드디어 Old 영역으로 이동하게 됩니다!

→ 이를 Promotion이라고 부릅니다.

♻ Major GC 과정 (in Old Generation)

1. 계속해서 마이너GC가 진행되면서, 끈질기게 살아남은 객체들은 점점 나이를 먹게됩니다.
만약 현재 예시의 JVM의 age임계값이 8이라고 가정하게 된다면,
Promotion이 발생하여 Old영역으로 이동합니다.

(Tenured는 Old영역과 같은 의미입니당)

2. 1번의 상황처럼 Promotion이 계속해서 발생할수록,
Old 영역은 계속해서 나이든 객체들이 자리를 잡게 됩니다.

3. 그렇게 Old영역이 다 차게된다면, 해당 공간을 정리하고 압축하는 GC 과정이 진행됩니다.
이것이 Major GC (Old 영역에서 진행되는 GC)입니다!

이렇게 Minor GC와 Major GC의 동작과정을 자세하게 알아봤습니다 :)

♻ Stop-The-World

앞서 Heap 구조에 대해 설명할때 언급했듯이 Young 영역은 일반적으로 Old 영역보다 크기가 작습니다.
GC가 보통 0.5초에서 1초 사이에 끝나기 때문에 Minor GC는 애플리케이션에 크게 영향을 주지 않습니다.

하지만 Old 영역의 Major GC는 일반적으로 Minor GC보다 시간이 오래걸리며, 10배 이상의 시간을 사용하게 됩니다.

→ 여기서 Stop-The-World 가발생!

Stop-the-World 과정

자바 가상 머신(JVM)에서 가비지 컬렉션(Garbage Collection, GC)을 수행할 때 발생하는 현상입니다.

Stop-the-World가 발생하면, JVM 내에서 GC를 실행하는 쓰레드를 제외한 나머지 쓰레드가 가비지 컬렉션 작업이 완료될 때까지 멈춥니다.

이 과정은 가비지 컬렉터가 메모리 내의 객체들을 안전하게 검사하고, 사용되지 않는 객체를 제거하며, 필요시 메모리를 재배치(Compaction)할 수 있도록 하기 위해 필요하지요

다만, Major GC같은 경우 처리속도가 길기 때문에 stop-the-world 과정에서 멈춤 현상의 지속시간이 길어지고.. 애플리케이션 이용에 차질이 생기게 됩니다

따라서 자바 개발진들은 Stop-the-World의 영향을 최소화하기 위해 끊임 없이 가비지 컬렉션 알고리즘을 발전 시켜왔습니다!

그 알고리즘에 대해서는.. 분량 문제로 따로 다뤄보도록 하겠습니다

Reference

https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

Java Garbage Collection Basics

Java Overview Java is a programming language and computing platform first released by Sun Microsystems in 1995. It is the underlying technology that powers Java programs including utilities, games, and business applications. Java runs on more than 850 mill

www.oracle.com

https://inpa.tistory.com/entry/JAVA-%E2%98%95-%EA%B0%80%EB%B9%84%EC%A7%80-

%EC%BB%AC%EB%A0%89%EC%85%98GC-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC

☕ 가비지 컬렉션 동작 원리 & GC 종류 총정리

Garbage Collection(GC) 이란? 가비지 컬렉션(Garbage Collection, 이하 GC)은 자바의 메모리 관리 방법 중의 하나로 JVM(자바 가상 머신)의 Heap 영역에서 동적으로 할당했던 메모리 중 필요 없게 된 메모리 객

inpa.tistory.com

https://velog.io/@yyong3519/Garbage-Collection-%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81

Garbage Collection 모니터링

출처

velog.io

special thx to chatGPT!

Spring Security @EnabledWebSecurity 의 동작원리

jimkwon — Mon, 17 Jun 2024 17:08:34 +0900

Spring Security?

Spring의 공식문서에 따르면,
Spring Security는 강력하고 사용자 정의가 가능한 인증 및 액세스 제어 프레임워크입니다.
(Spring 기반 애플리케이션 보안을 위한 사실상의 표준)

Java 어플리케이션에 인증 및 권한 부여를 제공하는 데 중점을 둔 프레임 워크라고 할 수 있죠.

like 문지기

인증 및 권한 부여에 대한 포괄적이고 확장 가능한 지원
세션 고정, 클릭재킹, 크로스 사이트 요청 위조 등과 같은 공격으로부터 보호
서블릿 API 통합
Spring Web MVC와의 선택적 통합 등… 다양한 특징을 가지고 있습니다!

@ 어노테이션

그렇다면 제목의 EnabledWebSecurity앞에 붙어있는 @는 무엇일까요?

이해를 위해서는 메타데이터 라는 개념을 짚고 넘어갈 필요가 있습니다!

메타데이터란 데이터의 대한 속성정보로, 하위 레벨 데이터를 설명하는 또다른 데이터라고 보면 됩니다.

도서관을 예시로 들어보자면 표제,저자,주제명,분류기호 등이 포함되어 있는 목록이 메타데이터의 속한다고 볼 수 있습니다

어노테이션이란 이러한 메타데이터라고 볼 수 있는데요, 본래 주석이라는 의미를 가지고 있습니다!

프로그램 실행 관점에서보면 프로그램이 처리할 메인 데이터가 아니라 실행 과정에서 데이터를 어떻게 처리할것인지 알려주는 서브 데이터라고 볼 수 있습니다!

어노테이션은 크게 세 가지 용도로 사용됩니다.

코드 문법 에러 체크
코드 자동 생성 정보 제공
런타임시 특정 기능을 실행하는 정보 제공

@EnabledWebSecurity

@EnableWebSecurity 애노테이션은 Spring Security를 사용하는 웹 애플리케이션에서 보안 구성을 활성화하는 데 사용됩니다!
이 애노테이션은 WebSecurityConfigurerAdapter를 확장한 클래스를 정의하거나, SecurityConfigurerAdapter를 사용하여 보안 구성을 정의하는 데 필요한 메서드를 구현하는 클래스에 적용됩니다.

실제 RPM 코드에서 다음과 같이 사용되고 있지요

이 애노테이션을 사용하면 Spring Security가 제공하는 기본 보안 구성을 활성화하고, 웹 애플리케이션의 인증 및 권한 부여를 조절할 수 있습니다. 주로 사용자 인증, 권한 부여, HTTPS 설정, 로그인 페이지 커스터마이징 등과 관련된 보안 설정을 구성할 때 활용됩니다.

@EnabledWebSecurity 파헤치기

그렇담 해당 어노테이션이 어떻게 정의되어있는지 조금 더 파헤쳐보겠습니다.

해당 어노테이션에 설정된 값들을 하나씩 해석해보겠습니다!

@Retention(RetentionPolicy.RUNTIME)이 어노테이션의 유지 정책을 RUNTIME으로 지정합니다. 이는 런타임 시에도 어노테이션 정보가 유지되어야 함을 나타냅니다.

@Target(ElementType.TYPE)	이 어노테이션을 타입(ElementType.TYPE)에 적용할 수 있음을 나타냅니다. 즉, 클래스나 인터페이스에 이 어노테이션을 적용할 수 있습니다.
@Documented	Javadoc에 이 어노테이션 정보를 포함하도록 지정합니다. 즉, 문서화할 때 이 어노테이션 정보가 포함됩니다.
@Import({ WebSecurityConfiguration.class, SpringWebMvcImportSelector.class, OAuth2ImportSelector.class, HttpSecurityConfiguration.class })	해당 어노테이션이 사용될 때 가져와야 하는 구성 클래스 및 선택자들을 지정합니다. WebSecurityConfiguration, SpringWebMvcImportSelector, OAuth2ImportSelector, HttpSecurityConfiguration 등이 가져와지게 됩니다.
@EnableGlobalAuthentication	전역 인증을 활성화하는데 사용되는 어노테이션입니다. 이 어노테이션을 사용하면 전역적으로 인증 구성을 할 수 있습니다.
@Configuration	해당 어노테이션이 클래스가 구성 클래스임을 나타냅니다. 이 어노테이션이 붙은 클래스는 스프링 컨테이너에서 빈으로 등록될 수 있습니다.

이곳에서 Import 항목을 보면 WebSecurityConfiguration 클래스를 포함하고 있는데, 해당 클래스의 내부를 살펴보면

springSecurityFilterChain이라는 메소드가 빈을 등록하고 있는 것을 확인할 수 있습니다!

이 빈이 바로, 스프링 필터 체인을 정의하는 빈입니다.

필터체인?
-> 여러 개의 필터를 묶어놓은 것

이 필터 체인이 WebSecurityConfiguration에 의해 등록되는 것이며 이는 다시 EnableWebSecurity에 의해 등록되어지는 구조를 갖게 됩니다.

springSecurityFilterChain

Spring Security 에서 제공하는 인증,인가를 위한 필터들의 모음입니다.
Spring Security 에서 가장 핵심이 되는 기능을 제공하며, 거의 대부분의 서비스는 Security Filter Chain 에서 실행된다고 이해하면 됩니다.

@EnableGlobalAuthentication

애노테이션으로 정의된 EnabledWebSecurity 내부 구현을 살펴본 결과,

WebSecurityConfiguration.class,

SpringWebMvcImportSelector.class,

OAuth2ImportSelector.class,

HttpSecurityConfiguration.class들을 import해서 실행시켜주는 것을 알 수 있습니다!

그 외에 @EnableGlobalAuthentication 구현부를 살펴보면 다음과 같습니다.

해당 어노테이션은 AuthenticationConfiguration 클래스를 Import 하는데, 해당 클래스를 살펴보면

AuthenticationManagerBuilder를 통해 전역적으로 사용될 사용자 정보를 구성할 수 있습니다..!

@EnabledWebSecurity 동작원리

결론적으로 @EnableWebSecurity 어노테이션을 사용하게 되면 다음과 같은 설정정보들이 마법과 같이 추가됩니다.

짜잔-


WebSecurityConfiguration	스프링 필터 체인을 정의
SpringWebMvcImportSelector	Spring Security 설정에 Spring Web MVC와 관련된 구성을 추가 (웹 애플리케이션에서의 보안 설정과 웹 MVC 설정을 통합)
OAuth2ImportSelector	Spring Security 구성에 OAuth 2.0 인증 및 권한 부여를 위한 필수 구성을 자동으로 추가
HttpSecurityConfiguration	HttpSecurityConfiguration 클래스가 WebSecurityConfigurerAdapter를 확장하여 구현되며, HttpSecurity를 구성하여 보안 규칙을 적용
AuthenticationConfiguration	@EnableGlobalAuthentication 어노테이션이 포함하는 클래스로, 전역적으로 사용될 사용자 정보를 구성할 수 있게 함

다음과 같은 Security 기능들을 어노테이션 하나로 활성화시킬 수 있는 아주 유용한 녀석이라고 볼 수 있겠습니다

✨ 참고 (Reference)

https://blog.naver.com/PostView.naver?blogId=gngh0101&logNo=222056047335&parentCategoryNo=&categoryNo=32&viewDate=&isShowPopularPosts=false&from=postView

Spring Security EnableWebSecurity 내부 속으로 -1 (AuthenticationConfiguration)

Spring Security EnableWebSecurity 내부 속으로 -1 (AuthenticationConfiguration) EnableWebSe...

blog.naver.com

https://k39335.tistory.com/40

[JAVA] Annotation(어노테이션) 이란?

[JAVA] Annotation(어노테이션) 이란? Annotation어노테이션이란 본래 주석이란 뜻으로, 인터페이스를 기반으로 한 문법이다. 주석과는 그 역할이 다르지만 주석처럼 코드에 달아 클래스에 특별한 의미

k39335.tistory.com

https://spring.io/projects/spring-security/

Spring Security

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications. Spring Security is a framework that focuses on providing both authentication and authoriz

spring.io

RabbiqMQ란 무엇일까?

jimkwon — Wed, 15 Feb 2023 10:55:30 +0900

RabbitMQ

얼랭(Erlang)언어로 AMQP를 구현한 오픈소스 메세지 브로커.

*얼랭 : 함수형 프로그래밍 언어 (C와 비슷한 성격의 언어라고 볼 수 있겠다.)

메시지 브로커란?
Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할이며
응용 소프트웨어 간에 메시지를 교환할 수 있게 한다.

즉, 소프트웨어끼리 메세지를 서로 교환할 수 있도록 중간에서 알선해주는 녀석이다.(미들웨어 라고 칭함)

AMQP

client application과 middleware broker와의 메세지를 주고 받기 위한 프로토콜

메시지 브로커가 어플리케이션(소프트웨어) 사이에서 메시지를 중개해주는 녀석이라고 했다. 양측의 어플리케이션에서 받은 메세지를 퍼나르기위한 규칙이자 방법이 AMQP인것이다.

해당 프로토콜에 따른 MQ제품중 하나가 RabbitMQ다. (다른 친구로는 그렇게 유명한 Kafka가 있다)

RabbitMQ의 동작 방식

사실상, RabbitMQ의 동작은 AMQP를 따르기 때문에 AMQP에 대한 내용을 정리한다고 보면 된다.

AMQP의 라우팅 모델은 아래와 같은 3개의 중요한 component 들로 구성된다.

Exchange
Queue
Binding

AMQP는 이 3가지의 구성요소들이 서로 간에 어떻게 통신하는지를 정의한 프로토콜이라고 볼 수 있다. 전체적인 흐름은 아래의 그림과 함께 살펴보자.

출처 : https://docs.informatica.com/integration-cloud/cloud-application-integration/current-version/rabbitmq-connector-guide/introduction-to-rabbitmq-connector/rabbitmq-overview.html

Producer가 메세지를 생성하고 발송하여 Consumer에게 수신되는 그 사이의 과정이

앞서 언급한 세 가지 구성요소로 이루어져 있다.

RabbitMQ 구성요소

1) Exchange

Publisher가 보낸 메시지는 반드시 Exchange를 통해 Queue에 접근하게 된다. (큐에 직통으로 접근 불가)

exchange는 수신된 메시지를 적절한 기준에 맞는 Queue나 또다른 exchange로 라우팅한다. 즉 라우터의 기능을 수행하는데, 간단하게 말해서 길잡이 역할을 해준다는 것이다.

방금 언급한 ‘적절한 기준’을 exchange type이라고 한다.

exchange type은 메시지를 어떤 방법으로 라우팅 시킬지를 결정하며, AMQP에서는 해당 방법을 표준화하여 Standard Exchange Type을 제시한다. (표준화 된 방법을 기준으로 exchage가 메시지를 라우팅 하도록!)

2) Binding

Exchange와 큐와의 관계를 정의한 일종의 라우팅 테이블이다.

Exchange와 Queue를 연결짓는 행위라고 볼 수 있는데, Exchange는 Publisher로부터 수신한 메시지를 Binding에 따라 적절한 Queue나 또다른 Exchange로 라우팅하게 된다.

Binding과 Exchange Type의 차이점?
두 요소를 정리하다보면.. 매우 유사하게 느껴진다. exchange type은 메시지를 어떤 방법으로 라우팅 시킬지를 결정하는 것이다. 즉 전달받은 메세지를 분리하는 ‘방법’이 되고, binding을 이러한 방법을 이용해 실제로 어떤 메시지를 어떤 큐에 보낼지를 결정한다.

이메일정보가 들어오면 특정 큐로 보내는 broker가 있다고 가정해보자.

이메일 도메인 정보(@뒤에 오는 주소)를 보고 큐를 결정하겠다. → exchange type

naver는 1번큐, google은 2번큐, daum은 3번큐로 보내겠다 → binding

3) Queue

Producer들이 발송한 메세지들이 Consumer가 소비하기 전까지 보관되는 장소

메모리나 디스크에 메시지를 저장하고, 그것을 consumer에게 전달하는 역할을 한다.

큐는 Binding을 통해 Exchange에 bind(연결)된다.

Standard Exchange Type

Exchange Type은 메시지를 어떤 원칙이나 방법으로 라우팅할지를 결정하는 일종의 알고리즘이다.

AMQP는 4개의 Standard Exchange Type을 규정하여 표준화 된 방법으로 exchage가 메시지를 라우팅 하도록 설계했다.

Routing Key

Publisher에서 송신한 메시지 헤더에 포함되는 것으로 일종의 가상 주소라고 보면 된다.

Exchange가 어떤 큐로 메시지를 라우팅할지 결정하는 도구 중 하나다.

Direct Exchange

메시지의 라우팅 키를 큐에 1:N으로 매칭시키는 방법이다.

일반적으로 큐의 이름과 라우팅 키를 동일하게 작성하여 바인딩한다.

Topic Exchange

와일드카드를 이용해서 메시지를 큐에 매칭시키는 방법이다.

"*"는 하나의 단어, "#"은 0개 이상의 단어를 의미한다. “.” (dot)로 구별되는 단어의 리스트를 가져야한다.

(ex. “abc.apple.one”, “aaa.banana.two”)

Fanout Exchange

모든 메시지를 모든 큐로 라우팅하는 유형이다. 일종의 브로드캐스트 개념

Headers Exchange

이전 3개의 경우는 ‘라우팅 키’를 사용하여 결정했다면, 해당 Exchange Type은 key-value로 정의된 헤더에 의해 라우팅을 결정한다.

큐를 바인딩할 때 x-match라는 특정 argument를 기준으로 어떻게 바인딩할지를 결정한다.

x-match가 all → 바인딩 조건을 모두 충족시켜야 한다(AND), x-match가 any → 하나만 충족시키면 된다(OR)

각 Exchange Type을 표로 정리하면 다음과 같다.

타입	설명	특징
Direct	Routing key가 정확히 일치하는 Queue에 메세지 전송	Unicast
Topic	Routing key 패턴이 일치하는 Queue에 메세지 전송	Multicast
Headers	[key:value]로 이루어진 header 값을 기준으로 일치하는 Queue에 메세지 전송	Multicast
Fanout	해당 Exchange에 등록된 모든 Queue에 메세지 전송	Broadcast

** 보너스!

Prefetch Count

하나의 Queue에 여러 Consumer가 존재할 경우, Queue는 기본적으로 Round-Robin 방식으로 메세지를 분배한다.

(라운드-로빈 : 순서대로 한번씩 돌아가는 방식)

그런데, Consumer가 2개인 상황에서 홀수번째 메세지는 처리 시간이 짧고, 짝수번째 메세지는 처리 시간이 매우 긴 경우, 계속해서 하나의 Consumer만 일을 하게 되는 상황이 발생할 수 있다!

이를 예방하기 위해, prefetch count를 1로 설정해 두면, 하나의 메세지가 처리되기 전(Ack를 보내기 전)에는 새로운 메세지를 받지 않게 되므로, 작업을 분산시켜 좀 더 효율적으로 운영할 수 있다.

[Reference]

https://www.rabbitmq.com/

https://blog.dudaji.com/general/2020/05/25/rabbitmq.html

http://egloos.zum.com/killins/v/3025514

[Docker] 도커와 컨테이너

jimkwon — Fri, 12 Aug 2022 14:05:58 +0900

개발에 조금이라도 발을 담가봤다면 대부분 '도커'라는 개념을 들어본 적이 있을 것이다.

필자의 경우 주위에서 '도커 참 좋더라~' 라고 하는데, '그래서 도커가 뭔데..?' 라는 생각이 머리를 맴돌았다.

출처 : 대학일기

그 후 도커에 대한 내 생각의 흐름은 이렇게 흘러갔다.

대충 구글에 도커 검색 -> 아~ -> (1주일 뒤) 도커가 뭐더라? -> 대충 구글에 도커 검색 -> 아~

이 무한의 굴레를 끊고자.. 제대로 마음잡고 도커에 대해 공부하고 직접 실습해보며 어느 정도 감을 잡기 시작했다.

그 좌충우돌의 과정을 한 달이 지난 이제서야 포스팅으로 정리해보려 한다.

(포스팅으로 정리하는건 배우는 것과 별개로 정말 어렵고 번거롭다..흑흑.. 모든 블로거들에게 무한한 존경을..)

도커에 대한 개념을 쉽게 훑어보고, '정확한 용어'로 기억해 스스로 정의할 수 있도록 하는 것이 이 포스팅의 목표다.

컨테이너의 탄생과 진화과정

먼저, 도커를 제대로 이해하기 위해서는 컨테이너에 대한 이해가 필요하다.

도커 = 컨테이너?

꽤 많은 사람들이 위와 같이 도커와 컨테이너를 동일시하는 경우가 있었다. (필자도 마찬가지)

결론부터 말하자면 둘은 엄연히 다르다.

컨테이너의 탄생 배경을 훑어 보며 둘의 차이점에 대해 확실히 짚고 넘어가보자.

1. chroot의 탄생

컨테이너의 역사는 1979년 chroot를 발표 한 것으로부터 시작된다.

chroot는 프로세스의 루트 디렉토리를 변경하여 프로세스 마다 접근할 수 있는 디렉토리를 제한한다.

https://securityqueens.co.uk/im-in-chroot-jail-get-me-out-of-here/

윈도우나 리눅스에서 터미널을 켠 후, 'ls /' 명령어를 통해 가장 최상위 디렉토리에 대한 목록이 나오게 된다.

(위 사진의 경우 노란색 폴더로 명시된 bin, etc, home, usr)

여기서 만약 chroot 명령어를 통해 chroot디렉토리를 루트로 설정하면, 'ls /'로 조회했을 때, 위와 같이 빨간 사각형 안의 초록색 디렉토리 bin, etc, home, usr가 조회될것이다.

따라서 chroot를 통해 루트 디렉토리를 하위로 설정하게 되면, 해당 프로세스에서는 bob, alice와 같은 노란색 폴더에 접근이 제한된다. 이러한 방식으로 사용자 별로 격리된 공간을 할당 받아 주어진 일을 수행할 수 있게 되었다.

이를 chroot 감옥(JAIL)이라고 부른다. 사용자들을 지정된 감옥에 수감시켜 그 감옥 내에서만 일을 수행하도록 하는..

(뭔가 귀여우면서 섬짓한 느낌..)

2. FreeBSD Jail의 탄생

chroot는 위와 같이 단순히 파일 접근에 대한 제어만 가능했다. 이후 프로세스, 네트워크까지 분리할 수 있는 기술이 탄생했는데 그것이 FreeBSD가 출시한 Jail이다.

단순히 파일 엑세스를 제어하는 것을 넘어 Jail이라는 OS 가상화 환경에서 파일 시스템, 프로세스, 네트워크를 분리할 수 있는 획기적 기술을 제공했다. 이것이 바로 컨테이너의 시작이다!

3. Namespace, cgroup 그리고 LXC의 탄생

[Namespace]

시간이 흘러 이번엔 RedHat에서 시스템 자원을 논리적으로 분할하는 Namespace를 발표하게 된다.

Namespace는 lightweight(경량) 가상화 솔루션이다. (그게 뭔데..)

이는 한 시스템 내에서 '독립된 공간'을 '격리된 환경'에서 운영하는 가상화 기술이다.

즉, 프로세스 별로 시스템의 리소스를 분리해서 실행하도록 도와주는 기능을 제공한다.

아직도 말이 너무 어렵게 느껴진다면.. 이를 '아파트'로 추상화해서 생각해보자!

한 아파트에는 101호, 102호..등 호수마다 독립된 주거 환경을 제공해준다.

아파트 = 시스템

101호, 102호... = 프로세스

주거 환경 (거실, 안방, 주방...) = 리소스 (PID, IPC, Network, UID, Mount, UTS)

라고 치환하면,

Namespace는 개별 프로세스(101호) 마다 시스템(아파트)의 리소스(주거 환경)를 제공한다.

이 개념이 좀 더 직관적으로 와닿을 것이다.

또한 프로세스 끼리는 IP로 통신을 하는데, 이는 서로의 공간을 방문하기 위해 101호, 102호와 같이 호실을 알아야 방문할 수 있는 것과 똑같은 개념이다!

[cgroup]

이번엔 Google에서 프로세스 자원 이용량을 제어하는 cgroup을 발표했다.

이는 커널의 기능 중 하나로 네트워크, 시스템 메모리, cpu 시간과 같은 자원을 사용자 정의 프로세스에 할당 할 수 있는 기능을 지원한다.

즉, 한 프로세스 안에 사용자 원하는 만큼 자원을 할당해줄 수 있는 기능을 제공하는 것이다.

[LinuX Containers]

IBM에서 위의 두 기술 Namespace와 cgroup을 사용하여 LXC를 탄생시켰다.

이는 최초의 Linux 컨테이너 엔진으로 컨테이너 기술의 시초라고 볼 수 있다. (근본!)

Namespace를 통해 격리된 공간으로 구성된 환경을 만들고, cgroup을 통해 각 환경에 원하는 만큼 자원을 할당할 수 있도록 구현되어있다.

우리가 '컨테이너'라고 부르는 시초격인 이 엔진은 단일 Linux 커널에서 동작하며 처음으로 Linux 상에서 컨테이너 개념을 가장 완벽하게 구현했다고 한다.

여기서 '커널'이라는 단어가 언급되는데, 해당 개념이 컨테이너와 가상머신의 차이점을 비교할 때 자주 언급된다.
커널은 CPU, 메모리 등 운영체제의 핵심으로, 거의 모든 하드웨어를 제어하는 프로그램이다.
(쉽게 말해 컴퓨터의 뇌를 담당해 손, 발을 움직이듯 하드웨어를 제어한다고 보면 편하다)

도커의 탄생

컨테이너 (LXC)가 개발된 이후 2013년, 도커가 드디어 오픈 소스 소프트웨어로 공개된다.

도커는 Debian, SUSE 등 모든 Linux 배포판을 지원하며 컨테이너 기술 확산 박차를 가하게 되며,

도커의 시대가 열리기 시작한다.

도커에 대해 한 번이라도 찾아본 사람들은, 주로 가상머신과 비교하는 글들을 많이 봤을 것이다.

잠시 방금 다뤘던 LXC의 개념을 복기해보면, 이 엔진은 '단일 Linux 커널'에서 동작한다고 언급하였다.

다시 복습해보자!

커널은 CPU, 메모리 등 운영체제의 핵심으로, 거의 모든 하드웨어를 제어하는 프로그램이다.

(컴퓨터의 뇌를 담당해 사람의 손, 발을 움직이듯 하드웨어를 제어한다.)

단일 커널에서 동작한다는 개념은 컨테이너의와 가상머신을 구분하는 핵심 내용이다. 사진과 함께 얘기해보자.

출처 : https://cloud.google.com/containers/?hl=ko

도커의 내용을 다루며 이와 비슷한 사진을 수도 없이 봤는데, 그럼에도 한 번에 와닿지가 않았다.

(OS를 직접 올리지 않아 자원이 절약...뭐시기..그렇구만.. 라는 모호한 결론으로 끝났다.)

시스템을 운영하는 운영 체제는 종류가 다양하다. 가상머신의 경우 그림 가운데에 놓인 Hypervisor가 '하드웨어'를 물리적으로 구분해서 가상화를 진행하므로 App1, App2, App3 환경에는 각기 다른 커널을 통해 하드웨어 제어가 이루어진다.

즉, 원래의 Host OS 위에 3개의 Guest OS가 통째로 올라가고, 각각의 Guest OS는 각기 다른 커널을 가지고 하드웨어 제어가 이루어지는 것이다.

본체를 이루는 두뇌와, 그 위의 쫄병 셋의 두뇌까지 올라가 있다고 생각해보라. 상당히 차지하는 공간도 무거울 것이고, 4개의 뇌까지 사용할 만큼의 일이 거의 없으니 불필요한 자원이 낭비되고 부팅이 상당히 오래 걸리게 되는 것이다.

반면에 컨테이너의 경우, 본체의 뇌를 같이 공유한다. 따라서 App1~3이 각기 작동하기 위해 필요한 최~소한의 OS만 받아와 구동되기 때문에 훨씬 가볍고 당연히 속도도 훨씬 빨라지게 되는 것이다.

도커 = 컨테이너?

이제 게시글의 맨 처음에서 다뤘던 이 질문에 대해 확실하게 대답할 수 있을 것이다.

(아니더라도 걱정하지 말라.. 필자도 수십번을 다시 찾아보면서 이해했으니..^_ㅜ)

컨테이너는 '격리된 공간에서 프로세스가 동작하게 해주는 가상화 기술'이고,

도커는 해당 기술을 사용자에게 편리하게 제공해주는 '플랫폼'이다.

(이제 어디가서 도커 = 컨테이너라고 말하지 말기로 나 스스로에게 약속ㅎ)

도커와 LXC의 차이

조금 더 세부적으로 둘의 차이를 다뤄보겠다.

LXC(LinuX Container)는 아까 컨테이너의 시초로 다룬 엔진이다.

도커도 물론 처음에는 LXC 기술을 기반으로 구축되었으나, 그 이후 종속 관계를 벗어나 독자적인 기술로 발전했다.

LXC는 가상화 기술로 자원의 경량화를 이뤄내는 유용한 방법이지만 사용자에 친숙하지 않다.

그 외의 차이점에 대해 그림과 함께 다뤄보자!

LXC는 하나의 컨테이너에 여러 응용프로그램을 띄우지만, 도커는 1컨테이너 = 1응용프로그램을 권장하고 그와 관련된 여러 툴을 제공한다.

애플리케이션의 기능을 분해해 MSA방식에 유용하고 필요한 기능들 중 필요한걸 골라서 재사용이 용이함
SOA 작동 방식처럼 각 컨테이너 별 기능을 모듈화 하여 여러 애플리케이션 사이에서 프로세스를 공유할 수 있다.

패션 쇼핑몰을 예로 들어서 생각해보자. 기능을 대략적으로 설계해보면 구매, 장바구니, 마이페이지 등이 존재할것이다.

이때 구매, 장바구니, 마이페이지가 한 어플리케이션이 있지않고 각각 독자적으로 만들어 분리된 환경(컨테이너)에서 돌아가도록 하는 것이 MSA 방식이다. (MSA 방식에 대한 자세한 글은 이곳을 참고해보자.)

이후 뷰티 쇼핑몰을 만들었을 때, 기존에 돌아가던 장바구니 기능을 그대로 가져와(필요하면 조금 수정해서) 재사용할 수 있으니 상당히 효율적인 방식이다.

또한 Docker에서는 컨테이너 생성 시 '도커 이미지'를 이용해 구축한다. 그림을 통해 도커 컨테이너 구조를 살펴보자.

맨 아래는 아까 언급했던 커널이다. Host OS에서 공유받아 사용한다.

그 위는 컨테이너를 구성하기 위한 Base Image이다. 이 이미지의 특성은 겹겹이 쌓이는 구조를 가지고 있다.

이를 layer형태로 쌓여있다고 하는데, 해당 방식의 이점이 뭐냐면

이후 새 컨테이너를 만들 때, 이전 컨테이너를 만들 당시 생성했던 layer가 중복될 경우 또 설치하지 않고 재사용하기 때문에 속도가 더 빠르고 효율성이 개선된다는 것이다.

(요리에 비교를 하면, 김치찌개(컨테이너1)와 김치볶음밥(컨테이너2)를 만들 때, 이미 김치찌개에 사용된 재료(김치)는 재설치 없이 바로 사용하게 되어 중복이 사라진다는 것이다.

이 방식을 통해 도커를 통해 가상화 환경을 구축하면 재사용성이 높아져 자원을 효율적으로 다룰 수 있게 되는 것이다.

도커는 만능이 아니다.

도커의 장점을 다시 정리해보자.

1. 한 서버에 여러 개의 컨테이너를 구동해 가상화가 가능하다.

(마치 여러 서버를 구매해서 돌리는 것 같지만, 한 서버 안에 여러 개의 컨테이너를 생성해 다양한 응용프로그램이 독립된 각각의 환경에서 돌아가는 것이 가능해진다.)

2. 필요한 리소스를 사용자가 할당 가능하므로 개발 환경에 구애받지 않는다.
(컨테이너 1은 CentOS가 돌아가고.. 컨테이너 2는 Ubuntu가 돌아가게 구현이 가능하다)

3. 2번 방법이 가능한 가상머신보다 심지어 훨씬 가볍고 빠르게 경량화가 되어있다.
(HostOS의 커널을 공유하기 때문의 일일이 OS를 새로 만들지 않아도 최소한의 OS로만 동작한다.)

이렇게만 보면 도커는 완벽해보인다. 완전 짱이잖아..? 하지만 이러한 도커에도 단점이 존재한다.

'독립된 환경'이 도커의 장점이자 단점이 될수 있다. 이게 무슨말일까?

도커의 권장사항은 1컨테이너 = 1응용프로그램이다.

그 의미는 개발자가 만들고자 하는 서비스의 규모가 커질수록 구현해야 할 응용프로그램이 늘어나고, 그 만큼 컨테이너의 수가 무수히 많아질 것이다. 문제는 컨테이너가 독립된 환경이기 때문에 각자 도생하는 녀석을 한 데 불러모으기가 상당히 어렵다는 것이다. (다 갠플하는 놈들이라 팀플이 쉽지않다...)

이렇게 갠플하는 녀석들을 하나로 그룹화하여 관리할 수 있는 시스템이 있는데, 그게 바로 쿠버네티스이다.

이 내용은 다음 포스팅에서 다루도록 하자.

이 글을 읽고 조금이라도 도커와 컨테이너의 이해에 도움이 됐으면 좋겠다.

[Spring Boot] 이메일 보내기 (3) - html 템플릿 적용 (feat. Thymeleaf)

jimkwon — Thu, 11 Aug 2022 14:18:58 +0900

++) 해당 포스팅은 이전 작성한 포스팅들과 연계되어 있으므로 먼저 보고 오는 것을 추천합니다!

https://born2bedeveloper.tistory.com/68?category=1038709

[Spring Boot] 이메일 보내기 (2) - 참조(cc), 첨부 파일

꽤 오래전에 구글 SMTP 서버를 이용한 Email 전송에 관한 내용을 다룬 적이 있었는데, 생각보다 조회수가 매우 높았다. 아마 이메일 전송이 부가적인 기능으로 다양하게 사용되기 떄문이겠지? 새로

born2bedeveloper.tistory.com

https://born2bedeveloper.tistory.com/14?category=1038709

[Spring Boot] EMail 보내기

기존 프로젝트를 베타 오픈하기 전에, 피드백을 받는 기능을 추가하면 좋겠다는 생각이 들었다. 일종의 고객센터 같은 느낌? 간단한 입력 form에 작성한 후 보내면, 관리자 계정으로 메일이 오도

born2bedeveloper.tistory.com

이번엔 html 템플릿을 적용한 이메일 전송에 대해 알아보도록 하자.

기존에 메일함을 보다 보면, 아래와 같이 텍스트 작성 외에 html문서형으로 작성된 메일을 받아본 적이 있을 것이다.

템플릿 기반 메일 전송에는 여러 방식이 있지만, 필자는 타임리프 템플릿 엔진을 이용하여 HTML 기반 이메일을 전송해볼것이다.

이메일 전송에 대한 기본적인 개념은 이전에 다뤘으니 생략하고 바로 구현으로 넘어가겠다.

환경 설정

구현에 필요한 라이브러리들이다.

build.gradle

	implementation 'org.springframework.boot:spring-boot-starter-mail'
	implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'

이전에 다룬 방식에서 크게 추가한 것은 없다.

application.properties

spring.thymeleaf.check-template-location=true
spring.thymeleaf.prefix=classpath:/templates/
spring.thymeleaf.suffix=.html
spring.thymeleaf.mode=HTML5
spring.thymeleaf.cache=false
spring.thymeleaf.order=0

## mail default settings
spring.mail.default-encoding=UTF-8
## mail custom settings
spring.mail.host=smtp.gmail.com
spring.mail.port=587
spring.mail.username=[이메일 계정]
spring.mail.password=[앱 비밀번호]
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.debug=true
spring.mail.properties.mail.smtp.starttls.enable=true
spring.mail.properties.mail.mime.charset=UTF-8
spring.mail.properties.mail.transport.protocol=smtp

필자는 구글 SMTP를 연동하였다. 이와 관련된 내용은 이곳에 자세히 나와있다.

또한 더 이상 보안 수준이 낮은 앱 허용을 지원하지 않으므로 앱 비밀번호를 생성해야 한다.

(그에 관한 내용도 윗 링크에 나와있다.)

화면 구현

POSTMAN을 통해 기능을 검증할 수 있지만, 이왕 타임리프를 쓰는 김에 view 부분도 간단하게 구현하였다.

templateMail.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="ko">
<head>
    <meta charset="UTF-8">
    <title>Send Mail</title>
    <script type="text/javascript" src="/scripts/jquery-ui/jquery.min.js"></script>
	<script type="text/javascript" src="/scripts/common/common-ui.js"></script>
	<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css">
	<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
	<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js"></script>
</head>
<body>
<h1>템플릿 메일 보내기</h1>
 <div class="container">
    <form th:action="@{/mail/template/send}" method="post">
        <table>
            <tr id="box" class="form-group">
                <td>메일 주소</td>
                <td>
                    <input type="text" class="form-control" name="address" placeholder="이메일 주소를 입력하세요">
                </td>
                <td>
					<input type="button" class="form-control" value="추가" onclick="add_textbox(this)">
				</td>
            </tr>
            <tr id="box2" class="form-group">
                <td>참조 메일 주소</td>
                <td>
                    <input type="text" class="form-control" name="ccAddress" placeholder="참조 수신인을 입력하세요">
                </td>
                <td>
					<input type="button" class="form-control" value="추가" onclick="add_textbox2(this)">
				</td>
            </tr>
            <tr class="form-group">
                <td>제목</td>
                <td>
                    <input type="text" class="form-control" name="title" placeholder="제목을 입력하세요">
                </td>
            </tr>
            <tr class="form-group">
                <td>템플릿 이름</td>
                <td>
                    <input type="text" class="form-control" name="template" placeholder="템플릿 이름을 입력하세요">
                </td>
            </tr>
        </table>
        <button class="btn btn-default">발송</button>
    </form>
 </div>
</body>
<script>
	const add_textbox = () => {
	    const box = document.getElementById("box");
	    const newP = document.createElement("tr");
	
	    newP.innerHTML = "<th>메일 주소</th><td><input type='text' name='address' ><input type='button' value='삭제' onclick='opt_remove(this)'></td>";
		box.parentNode.insertBefore(newP, box.nextSibling);
	}
	
	const add_textbox2 = () => {
	    const box = document.getElementById("box2");
	    const newP = document.createElement("tr");

	    newP.innerHTML = "<th>참조 메일 주소</th><td><input type='text' name='ccAddress' ><input type='button' value='삭제' onclick='opt_remove2(this)'></td>";
		box.parentNode.insertBefore(newP, box.nextSibling);
		}
	
	const opt_remove = (obj) => {
	     document.getElementById('box').parentElement.removeChild(obj.parentElement.parentElement);
	}
	const opt_remove2 = (obj) => {
	     document.getElementById('box2').parentElement.removeChild(obj.parentElement.parentElement);
	}
</script>
</html>

result.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="ko">
<head>
  <title>Bootstrap Example</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css">
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
  <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js"></script>
</head>
<body>

<div class="container">
  <h2>Email 전송 완료.</h2>    
</div>

</body>
</html>

(정말 최소한의 디자인만 넣었다..)

무료 템플릿 선정하기

물론, 직접 작성한 html 파일을 사용해서 메일을 보내도 되지만, 무료로 템플릿 테마를 가져올 수 있으니 괜찮은 놈으로 하나 골라서 사용해보자.

사이트는 많지만 필자는 아래 사이트를 참고하여 가져왔다.

https://unlayer.com/templates

Free HTML Email Templates and Editor

Browse hundreds of HTML email templates and choose the best for your business. Wide range of templates available for every industry and usage. Start for free.

unlayer.com

간단한 로그인으로 무료 템플릿을 본인 입맛에 맞게 수정하여 가져올 수 있다.

나는 이것도 귀찮다.. 싶으신 분들은 필자가 대충 가져온 템플릿을 아래에 둘 테니 파일로 저장해서 사용하시라!

(같이 첨부된 이미지는 src/main/resources/static/images 경로로 폴더를 만들어 넣어두면 된다)

템플릿예시.zip

0.10MB

받아온 템플릿의 경우, 위의 환경설정에서 classpath를 templates로 지정했으므로 src/main/resources/templates 경로 아래에 index.html을 넣어두면 된다.

잠깐! 만약 템플릿 지정 경로를 내가 원하는대로 지정하고 싶다면?

해당 내용은 아래의 포스팅에서 다뤘으니 참고하여 적용하면 된다.

https://born2bedeveloper.tistory.com/69?category=1038709

[Spring Boot] Thymeleaf 경로 변경 & 다중 경로 설정

이 포스팅은 타임리프 템플릿 엔진 사용 시, html등의 파일을 프로젝트 '내부'가 아닌 '외부' (ex. C드라이브)에 두고 관리할 수 있는 방법을 다룬다. Thymeleaf 경로 변경 별도의 설정이 없다면, 기본

born2bedeveloper.tistory.com

Service 구현

이제 템플릿 적용을 위한 준비가 끝났으니 본격적으로 로직을 구현해보자!

먼저 view의 form에서 받아온 값들을 저장할 DTO부터 생성하자.

MailDto

import java.util.ArrayList;
import java.util.List;

import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
 
@Getter
@Setter
@NoArgsConstructor
public class MailDto {
	private String from;
    private String[] address;
    private String[] ccAddress;
    private String title;
    private String content;
    private String template;
}

마지막 인자로 받아오는 template의 경우 확장성을 고려하여 받아왔는데,

여러개의 template이 있다고 가정하고, 원하는 템플릿 이름(ex.index)을 받아오면 해당 디자인으로 메일을 전송할 수 있도록 고려하였다.

MailService.java

import java.io.IOException;
import java.util.HashMap;
import java.util.List;

import javax.mail.MessagingException;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeUtility;

import org.apache.commons.io.IOUtils;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.core.io.ByteArrayResource;
import org.springframework.core.io.ClassPathResource;
import org.springframework.mail.javamail.JavaMailSender;
import org.springframework.mail.javamail.MimeMessageHelper;
import org.springframework.stereotype.Service;
import org.springframework.util.StringUtils;
import org.thymeleaf.context.Context;
import org.thymeleaf.spring5.SpringTemplateEngine;

import com.example.demo.dto.MailDto;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

@Slf4j
@Service
@RequiredArgsConstructor 
public class MailService {
	private final JavaMailSender emailSender;
    private final SpringTemplateEngine templateEngine;
    
        public void sendTemplateMessage(MailDto mailDto) throws MessagingException {	
    	MimeMessage message = emailSender.createMimeMessage();
        MimeMessageHelper helper = new MimeMessageHelper(message, true, "UTF-8");
        //메일 제목 설정
        helper.setSubject(mailDto.getTitle());

        //수신자 설정
        helper.setTo(mailDto.getAddress());
        
        //참조자 설정
        helper.setCc(mailDto.getCcAddress());

        //템플릿에 전달할 데이터 설정
        HashMap<String, String> emailValues = new HashMap<>();
    	emailValues.put("name", "jimin");
    	
        Context context = new Context();
        emailValues.forEach((key, value)->{
            context.setVariable(key, value);
        });
    	              
        //메일 내용 설정 : 템플릿 프로세스
        String html = templateEngine.process(mailDto.getTemplate(), context);
        helper.setText(html, true);
        
        //템플릿에 들어가는 이미지 cid로 삽입
        helper.addInline("image1", new ClassPathResource("static/images/image-1.jpeg"));

        //메일 보내기
        emailSender.send(message);
    }

여기서 주의깊게 봐야 할 것은 MimeMessageHelper 클래스의 addInline 메소드다.

만약, 해당 메소드 없이 html 템플릿 메일을 보내게 되면 아래와 같이 이미지가 적용되지 않는다.

(당연한 일임.. 이미지 경로가 프로젝트 내부에 있으니 메일로 보내버리면 받는 서버에서는 이미지 경로를 찾을수가 없다)

html 템플릿 안의 이미지를 전송하는 방법은 여러 가지가 있는데, 필자는 cid를 이용하여 이미지를 html안에 임베딩하여 보내는 방식을 사용할 것이다.

따라서 전송할 html 양식 안의 img 경로를 다음과 같이 설정해둔 후

<img src='cid:image'>

이메일 전송 전 addInline 메소드로 해당 cid를 적용해야한다!

helper.addInline("image", new ClassPathResource("static/images/image-1.jpeg"));

cid의 이름과 addInline의 첫 번째 인자를 서로 매칭해주고, 두 번째 인자에는 실제 저장되어 있는 이미지 경로를 넣어주면 된다.

(필자가 올려둔 index.html에서는 첫 번째 이미지만 임베딩 해둔 상태이니, 엑박이 불편한 분들은 직접 addInline을 통해 나머지 이미지를 임베딩 해보셔도 좋습니다 :D)

Controller 구현

import java.io.IOException;
import java.util.List;

import javax.mail.MessagingException;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;

import com.example.demo.domain.Email;
import com.example.demo.dto.MailDto;
import com.example.demo.service.MailService;

import lombok.extern.slf4j.Slf4j;

@Slf4j
@Controller
public class MailController {
	
	private final MailService mailService;
	
	 
    public MailController(MailService mailService) {
        this.mailService = mailService;
    }
	
	@GetMapping("/templateMail")
    public String templateMailSend() {
		return "templateMail";
	}
	
    @PostMapping("/mail/template/send")
    public String sendTemplateMail(MailDto mailDto, Model model) throws MessagingException {
    	mailService.sendTemplateMessage(mailDto);
        System.out.println("메일 전송 완료");
        return "result";
    }
    

}

이제 모든 준비가 끝났다! 설레는 테스트의 시간이다.

이메일 전송 구현

떨리는 마음으로 발송을 눌러보면..

완료 시 리다이렉트한 페이지로 이동한다! 직접 보낸 계정으로 들어가 메일을 확인해보자.

직접 적용한 템플릿에 무사히 이미지까지 잘 임베딩 된 것을 확인할 수 있다!

해당 포스팅을 마지막으로 이메일을 이만 종결하도록 하겠다.

이메일 정복! 끝!

[Spring Boot] Thymeleaf 경로 변경 & 다중 경로 설정

jimkwon — Thu, 11 Aug 2022 11:21:13 +0900

이 포스팅은 타임리프 템플릿 엔진 사용 시, html등의 파일을 프로젝트 '내부'가 아닌 '외부' (ex. C드라이브)에 두고 관리할 수 있는 방법을 다룬다.

Thymeleaf 경로 변경

별도의 설정이 없다면, 기본 경로는 src/main/resources/templates 로 설정된다.

만약 기본 경로값을 바꾸고 싶다면, application.properties 파일에서 간단하게 변경 가능하다.

spring.thymeleaf.prefix=classpath:/other-template/

위와 같이 설정하게 되면, 경로는 src/main/resources/other-template 폴더 안에 들어간 html파일을 기본 경로로 읽을 것이다.

Thymeleaf 다중 경로 설정

만약, 기존의 경로를 유지하면서 새로운 경로를 추가하고 싶다면?

ClassLoaderTemplateResolver 타입의 빈을 생성한 후 등록하면 가능하다!

@Bean
public ClassLoaderTemplateResolver secondaryTemplateResolver() {
    ClassLoaderTemplateResolver secondaryTemplateResolver = new ClassLoaderTemplateResolver();
    secondaryTemplateResolver.setPrefix("other-template/");
    secondaryTemplateResolver.setSuffix(".html");
    secondaryTemplateResolver.setTemplateMode(TemplateMode.HTML);
    secondaryTemplateResolver.setCharacterEncoding("UTF-8");
    secondaryTemplateResolver.setOrder(1);
    secondaryTemplateResolver.setCheckExistence(true);
        
    return secondaryTemplateResolver;
}

setPrefix : src/main/resources 아래의 새로운 경로를 추가해준다.

이제 타임리프 엔진이 src/main/resources/templates 과 src/main/resources/other-template 두 가지의 경로를 사용할 수 있게 되었다.

Thymeleaf 외부 경로 설정

프로젝트 내부가 아닌 C 드라이브와 같이 외부 경로로 설정하는 방법도 있다.

필자의 경우, 이메일 템플릿 엔진을 따로 외부 폴더를 두고 관리하고 싶었기 때문에 해당 방법을 유용하게 사용했다.

import javax.annotation.PostConstruct;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.thymeleaf.spring5.SpringTemplateEngine;
import org.thymeleaf.templateresolver.FileTemplateResolver;

@Configuration
public class ThymeleafExtension {

    @Autowired
    private SpringTemplateEngine templateEngine;

    @PostConstruct
    public void extension() {
        FileTemplateResolver resolver = new FileTemplateResolver();
        resolver.setPrefix("C:\\template\\");
        resolver.setSuffix(".html");
        resolver.setTemplateMode("HTML5");
        resolver.setOrder(templateEngine.getTemplateResolvers().size());
        resolver.setCacheable(false);
        templateEngine.addTemplateResolver(resolver);
    }
}

FileTemplateResolver를 사용하여 템플릿을 외부 파일에서 탐색 가능하도록 했다.

필자의 경우 C드라이브 아래 template폴더에 html파일을 두어 관리했다.

Error resolving template [hello], template might not exist or might not be accessible
by any of the configured Template Resolvers

타임리프를 사용하다보면 위의 에러를 참 많이 마주친다.. 대부분 경로 설정이 잘못됐거나 컨트롤러에서 해당 파일의 확장자 (.html)까지 붙여서 생기는 경우가 많으니 잘 살펴보시길 바란다.

(특히! src/main/resources 해당 경로 아래에 넣지 않아서 생기는 오류가 많다)

참고 링크

https://www.baeldung.com/spring-thymeleaf-template-directory

Changing the Thymeleaf Template Directory in Spring Boot | Baeldung

Learn about Thymeleaf template locations.

www.baeldung.com

[Spring Boot] 이메일 보내기 (2) - 참조(cc), 첨부 파일

jimkwon — Wed, 10 Aug 2022 18:02:26 +0900

꽤 오래전에 구글 SMTP 서버를 이용한 Email 전송에 관한 내용을 다룬 적이 있었는데, 생각보다 조회수가 매우 높았다. 아마 이메일 전송이 부가적인 기능으로 다양하게 사용되기 떄문이겠지?

새로운 프로젝트에서 Email 서비스를 다시 구현하게 됐는데, 좀 더 세부적인 기능이 추가적으로 필요하여 두 번째 시리즈를 쓰기로 결심했다.

이번엔 다중 송신, 다중 참조(CC), 첨부파일 전송 등 다양한 옵션을 사용하여 좀 더 세부적으로 이메일 전송을 구현해보도록 하겠다.

++) 이전 프로젝트를 참고하고 오는 것을 추천한다.

https://born2bedeveloper.tistory.com/14

[Spring Boot] EMail 보내기

born2bedeveloper.tistory.com

기본적인 개념은 이전 포스팅에서 다뤘기 때문에 구현 위주로 가겠다.

프로젝트 환경구성

이전 프로젝트에서 사용한 라이브러리, 설정 외에 더 추가할 것이 생겼다.

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-mail'
implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
implementation 'org.springframework.boot:spring-boot-starter-web'

implementation group: 'commons-io', name: 'commons-io', version: '2.11.0'

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

commons-io는 첨부 파일 구현에서 편리하게 쓸 메소드를 가져오는 데 쓰인다.
(이 포스팅 에서 파일 업로드, 다운로드 관련으로 유용하게 쓰였음)

application.properties

## mail default settings
spring.mail.default-encoding=UTF-8
## mail custom settings
spring.mail.host=smtp.gmail.com
spring.mail.port=587
spring.mail.username=[구글계정]
spring.mail.password=[앱 비밀번호]
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.debug=true
spring.mail.properties.mail.smtp.starttls.enable=true
spring.mail.properties.mail.mime.charset=UTF-8
spring.mail.properties.mail.transport.protocol=smtp

잠깐!
기존에는 메일 송신을 위해 보안 수준이 낮은 앱 및 Google계정 을 허용하여 날먹(?)으로 메일 송신이 가능했지만, 이제 더는 해당 방식을 지원하지 않는다.

따라서 2단계 인증을 설정한 후, 앱 비밀번호를 생성하여 해당 비밀번호를 기입해야만이 메일 송신이 가능하다.

그 방법은 이 포스팅 아래 부분에서 자세히 다루고 있으니 참고하자 ㅎㅎ

프로젝트 화면 구성 - view

필자는 타임리프 뷰 템플릿으로 간단하게 화면을 구성했다.

js부분을 추가해서 여러 명의 수신인과 참조인을 가능하도록 했으니 편하게 가져다 쓰면 된다!

textMail.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="ko">
<head>
    <meta charset="UTF-8">
    <title>Send Mail</title>
    <script type="text/javascript" src="/scripts/jquery-ui/jquery.min.js"></script>
	<script type="text/javascript" src="/scripts/common/common-ui.js"></script>
	<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css">
	<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
	<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js"></script>
</head>
<body>
<div class="container">
<div style="float: left; width: 50%;">
    <h1>텍스트 메일 보내기</h1>
 
    <form th:action="@{/mail/send}" method="post" enctype="multipart/form-data">
        <table>
            <tr class="form-group">
                <td>보내는 사람</td>
                <td>
                    <input type="text" class="form-control" name="from" placeholder="이메일 주소를 입력하세요">
                </td>
            </tr>
            <tr id="box" class="form-group">
                <td>받는 사람</td>
                <td>
                    <input type="text" class="form-control" name="address" placeholder="이메일 주소를 입력하세요">
                </td>
                <td>
					<input type="button" class="form-control" value="추가" onclick="add_textbox(this)">
				</td>
            </tr>
            <tr id="box2" class="form-group">        
                <td>참조 메일 주소</td>
                <td>
                    <input type="text" class="form-control" name="ccAddress" placeholder="참조 수신인을 입력하세요">
                </td>
                <td>
					<input type="button" class="form-control" value="추가" onclick="add_textbox2(this)">
				</td>
            </tr>
            <tr class="form-group">
                <td>제목</td>
                <td>
                    <input type="text" class="form-control" name="title" placeholder="제목을 입력하세요">
                </td>
            </tr>
            <tr class="form-group">
                <td>내용</td>
                <td>
                    <textarea class="form-control" name="content" placeholder="보낼 내용을 입력하세요"> </textarea>
                </td>
            </tr>
            <tr class="form-group">
            	<td>첨부 파일 </td>
            	<td>
            		<input type="file" name="file" class="file-input" />
            	</td>
            </tr>
        </table>
        <button class="btn btn-default">발송</button>
    </form>

 </div>
 </div>
</body>
<script>
	const add_textbox = (obj) => {
	    const box = obj.parentElement.parentElement; 
	    const newP = document.createElement("tr");
	
	    newP.innerHTML = "<tr class='form-group'><td>메일 주소</td><td><input type='text' class='form-control' name='address' ></td><td><input type='button' class='form-control' value='삭제' onclick='opt_remove(this)'></td></tr>";
		box.parentNode.insertBefore(newP, box.nextSibling);
	}
	
	const add_textbox2 = (obj) => {
	    const box = obj.parentElement.parentElement; 
	    const newP = document.createElement("tr");

	    newP.innerHTML = "<tr class='form-group'><td>참조 메일 주소</td><td><input type='text' class='form-control' name='ccAddress' ></td><td><input type='button' class='form-control' value='삭제' onclick='opt_remove2(this)'></td></tr>";
		box.parentNode.insertBefore(newP, box.nextSibling);
		}
	
	const opt_remove = (obj) => {
		obj.parentElement.parentElement.parentElement.removeChild(obj.parentElement.parentElement);
	}
	const opt_remove2 = (obj) => {
		obj.parentElement.parentElement.parentElement.removeChild(obj.parentElement.parentElement);
	}
</script>
</html>

form 타입은 꼭 multipart로 지정해야 첨부파일이 잘 넘어간다. 아니면 null처리되니 주의!

result.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="ko">
<head>
  <title>Bootstrap Example</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css">
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
  <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js"></script>
</head>
<body>

<div class="container">
  <h2>Email 전송 완료.</h2>    
</div>

</body>
</html>

DTO 구현

view에서 받아올 데이터를 맵핑할 DTO를 구현하자.

package com.example.demo.dto;

import java.util.ArrayList;
import java.util.List;

import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
 
@Getter
@Setter
@NoArgsConstructor
public class MailDto {
	private String from;
    private String[] address;
    private String[] ccAddress;
    private String title;
    private String content;
}

Controller 구현

package com.example.demo.controller;

import java.io.IOException;
import java.util.List;

import javax.mail.MessagingException;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.multipart.MultipartFile;

import com.example.demo.domain.Email;
import com.example.demo.dto.MailDto;
import com.example.demo.service.MailService;

import lombok.extern.slf4j.Slf4j;

@Slf4j
@Controller
public class MailController {
	
	private final MailService mailService;
	
	 
    public MailController(MailService mailService) {
        this.mailService = mailService;
    }
	
	@GetMapping("/textMail")
    public String mailSend() {
		return "textMail";
	}
    
    @PostMapping("/mail/send")
    public String sendMail(MailDto mailDto, MultipartFile file) throws MessagingException, IOException {
    	mailService.sendMultipleMessage(mailDto, file);
        System.out.println("메일 전송 완료");
        return "result";
    }

}

첨부파일의 경우 MultipartFile 형식으로 받아온다.

Service 구현

package com.example.demo.service;

import java.io.IOException;
import java.util.HashMap;
import java.util.List;

import javax.mail.MessagingException;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeUtility;

import org.apache.commons.io.IOUtils;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.core.io.ByteArrayResource;
import org.springframework.core.io.ClassPathResource;
import org.springframework.mail.javamail.JavaMailSender;
import org.springframework.mail.javamail.MimeMessageHelper;
import org.springframework.stereotype.Service;
import org.springframework.util.StringUtils;
import org.springframework.web.multipart.MultipartFile;

import com.example.demo.dto.MailDto;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

@Slf4j
@Service
@RequiredArgsConstructor 
public class MailService {
 
    private final JavaMailSender emailSender;
    
    public void sendMultipleMessage(MailDto mailDto, MultipartFile file) throws MessagingException, IOException {
    	MimeMessage message = emailSender.createMimeMessage();
        MimeMessageHelper helper = new MimeMessageHelper(message, true);
        //메일 제목 설정
        helper.setSubject(mailDto.getTitle());

        //참조자 설정
        helper.setCc(mailDto.getCcAddress());        
        
        helper.setText(mailDto.getContent(), false);
        
        helper.setFrom(mailDto.getFrom());
        
        //첨부 파일 설정
        String fileName = StringUtils.cleanPath(file.getOriginalFilename());
        
        helper.addAttachment(MimeUtility.encodeText(fileName, "UTF-8", "B"), new ByteArrayResource(IOUtils.toByteArray(file.getInputStream())));
                       
        //수신자 개별 전송       
//        for(String s : mailDto.getAddress()) {
//        	helper.setTo(s);
//        	emailSender.send(message);
//        }
        //수신자 한번에 전송
        helper.setTo(mailDto.getAddress());
        emailSender.send(message);
        log.info("mail multiple send complete.");
   
        
    }

}

기존에 text기반 메일을 보냈을 때와 달리 첨부파일을 담기 위해 MimeMessage 객체를 사용하고 있다.

MimeMessageHelperclass
MIME 메시지를 만들기 위한 클래스
HTML 레이아웃에서 이미지, 일반적인 메일 첨부 파일 및 텍스트 내용을 지원

MIME이란?
Multipurpose Internet Mail Extensions의 약자이다.
기존 UUEncoding 방식은 ASCII(텍스트) 파일만 지원하여 음악, 워드 파일 등의 바이너리 파일을 전송할 수 없음
이러한 방식을 보안하여 나온 인코딩 방식이다.

참조, 수신인을 설정할때도 간단하다. setTo와 setCc 메소드를 활용하면 된다.

이 때, 수신인이나 참조인지 다중(여러 명)일 경우와 단일일 경우의 메소드가 둘 다 구현되어 있다.

따라서

A방식 메일 : 수신인[a, b, c, d....] 제목: "제목" 내용 : "내용"

B방식 메일 : 수신인[a] 제목: "제목" 내용: "내용" , 수신인[b] 제목: "제목" 내용: "내용"....

한 번에 여러 수신인에게 메일을 보내는 A 방식의 경우 setTo에 수신인 리스트를 넣어두고,

각 수신인에게 하나의 메일을 여러개 보내는 B 방식의 경우 setTo에 개별 수신인을 넣어 전송하면 된다.

(코드에 주석처리되어있으니 편한대로 사용하시라!)

실행 결과

이제 프로젝트를 구동하여 메일이 정상적으로 보내지는지 확인해보자.

완료다! 직접 메일을 확인해보자.

참조도 무사히 달렸고, 파일도 잘 첨부되었다!!

다음 포스팅은 html template를 적용한 이메일 전송을 다뤄볼 예정이다!

[Spring Boot] SMS 전송 - NAVER SMS API 연동

jimkwon — Wed, 10 Aug 2022 15:08:09 +0900

진행중인 프로젝트 내에 SMS 서비스를 구현할 일이 생겼다.

개인 공부용 무료 SMS 서비스를 찾다가 NAVER CLOUD PLATFORM에서 지원하는 SMS API 서비스를 알게 됐다.

대부분 coolsms를 많이들 이용했는데 개인적으로 네이버가 친숙한 플랫폼이기도 하고, 매월 50건의 무료메세지 발송 및 첫 가입 시 10만 크레딧을 제공한다고 하여 선택하게 됐다. 해당 크레딧은 네이버 클라우드 플랫폼에서 제공하는 다른 솔루션에도 사용할 수 있으니 유용하게 쓰시길 바란다. (단, 실제로 결제가 가능한 카드를 연동해야 한다.)

또한 네이버에서 API 문서를 잘 구성해놓은 것도 채택에 큰 비중을 차지했다. 따라서 필자는 네이버 클라우드 플랫폼에서 제공하는 NAVER API 가이드에 따라 차근차근 진행해볼 예정이다.

NAVER SMS API 사용을 위한 환경구성

먼저, 네이버 클라우드 플랫폼에 가입해야 한다.

https://www.ncloud.com/

NAVER CLOUD PLATFORM

cloud computing services for corporations, IaaS, PaaS, SaaS, with Global region and Security Technology Certification

www.ncloud.com

해당 링크로 들어가 가입한 후, 이곳을 클릭해 콘솔로 편하게 이동해보자.

Simple & Easy Notification Service (SMS 서비스의 이름이다.) 의 Home을 찾아가 프로젝트 생성하기를 누른다.

원하는 설정값을 입력하여 생성해보자. (필자는 SMS만 다룰것이므로 한 곳만 체크했다)

생성한 후에는 왼쪽 NAV바의 Project를 클릭하면 방금 만든 프로젝트를 조회할 수 있다.

만들어진 프로젝트의 SMS 버튼을 눌러 발신 번호를 등록하자.

(++2015년부터 발신번호 사전등록제가 시행되어 사전등록된 발신번호로만 문자 발송이 가능하다.)

SMS > CallingNumber 에서 발신번호 등록이 가능하다.

등록이 완료되었다. 해당 발신번호는 이후 API 요청에 필요하므로 까먹지 말고 기억해두자~ (보통 본인 번호를 넣을테니 까먹을 이유는 없겠지만)

환경 변수 설정하기 - KEY & ServiceId

이제 본격적인 API 요청을 위한 KEY와 ID값을 발급받아야 한다.

일반적인 경우와 다르게, 네이버는 토근 발급 없이 헤더에 명시한 값들만 넣어주면 한번에 API 기능들을 요청할 수 있다!

즉, 대부분의 경우는

발급받은 key 값으로 서비스에 token 요청
획득한 token을 헤더에 넣어 API 요청을 위한 입장권처럼 사용

네이버 SMS API의 경우 1번 요청을 패스하고 헤더에 규정된 값을 넣어 바로 본격적인 요청이 가능하다.

먼저, KEY값을 구해보자.

마이페이지 > 계정 관리 > 인증키관리 > 신규 API 인증키 생성

생성된 AccessKey와 SecretKey를 잘 백업해두자.

다음은 ServiceId를 가져오자. 해당 값은 SMS서비스 프로젝트를 만들때 이미 발급되었다.

프로젝트 콘솔화면 << 으로 들어가 서비스ID(열쇠모양)를 클릭하면 서비스ID를 발급받을 수 있다.

이제 필요한 환경구성은 끝났다!

SMS 전송을 위한 헤더 구성

아까 언급한대로, SMS API 요청을 하기 위해선 NAVER에서 지정해둔 포맷에 따라 헤더를 구현해야 한다.

각 헤더를 좀 더 풀어 설명해보자면

현재 시간, JAVA에서는 System.currentTimeMillis()로 간단하게 구현 가능
아까 발급받은 AccessKey값
아까 발급받은 SecretKey값을 적절하게 암호화 한 것

띠용? 암호화라고? 걱정하지마라 링크로 들어가면 암호화하는 코드도 아~주 상세하게 나와있다!

아래 링크의 makeSigniture() 메소드를 거의 그대로 참고하면 된다.

https://api.ncloud-docs.com/docs/common-ncpapi

Ncloud API

api.ncloud-docs.com

그 외에 헤더에 관련된 자세한 정보도 나와있으니 참고하면 된다.

먼저 프로젝트의 환경설정 파일에서 아까 발급받은 KEY값과 serviceID를 설정하자.

(직접 코드에 그대로 붙여넣어 사용하는 것은 지양하도록 하자.. 아주 별로다..)

application.properties

마지막 senderPhone은 아까 프로젝트에서 설정한 발신번호를 기입하면 된다.

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
implementation 'org.springframework.boot:spring-boot-starter-web'
implementation group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.5.13'
    
compileOnly 'org.projectlombok:lombok'
annotationProcessor 'org.projectlombok:lombok'

프로젝트에 필요한 Dependency들도 미리 설정해두자.

(maven인 경우 httpclient, thymeleaf, spring-web, lombok을 해당 형식에 맞게 설정하면 된다.)

이제 3가지 헤더 중 암호화가 필요한 마지막 헤더 구성을 위한 메소드를 Service단에 구현해보자.

SmsService.java

@Slf4j
@RequiredArgsConstructor 
@Service
public class SmsService {
	
	@Value("${naver-cloud-sms.accessKey}")
	private String accessKey;
	
	@Value("${naver-cloud-sms.secretKey}")
	private String secretKey;
	
	@Value("${naver-cloud-sms.serviceId}")
	private String serviceId;

	@Value("${naver-cloud-sms.senderPhone}")
	private String phone;

....
}

먼저 설정한 환경 변수들을 맨 위에 선언해주고,

public String makeSignature(Long time) throws NoSuchAlgorithmException, UnsupportedEncodingException, InvalidKeyException {
		String space = " ";
        String newLine = "\n";
        String method = "POST";
        String url = "/sms/v2/services/"+ this.serviceId+"/messages";
        String timestamp = time.toString();
        String accessKey = this.accessKey;
        String secretKey = this.secretKey;

        String message = new StringBuilder()
                .append(method)
                .append(space)
                .append(url)
                .append(newLine)
                .append(timestamp)
                .append(newLine)
                .append(accessKey)
                .toString();

        SecretKeySpec signingKey = new SecretKeySpec(secretKey.getBytes("UTF-8"), "HmacSHA256");
        Mac mac = Mac.getInstance("HmacSHA256");
        mac.init(signingKey);

        byte[] rawHmac = mac.doFinal(message.getBytes("UTF-8"));
        String encodeBase64String = Base64.encodeBase64String(rawHmac);

        return encodeBase64String;
	}

Signature 필드 값 생성을 위한 메서드를 작성하자.

이제 API요청을 위한 헤더 구성이 끝났다.

메시지 발송 - Request & Response 생성

헤더 구성이 끝났으니, 메시지 요청을 위한 Request 객체와 API 요청 반환값을 담아올 Response 객체를 생성해두자.

요청, 반환에 쓰이는 필드값은 공식 문서에 아주 상세히 나와있다. 참고하자.

https://api.ncloud-docs.com/docs/ai-application-service-sens-smsv2#메시지발송

SMS API

api.ncloud-docs.com

메시지 요청에 필요한 항목이 많아보이지만, 공식 문서에서 보면 알 수 있듯이 모두 필수 값이 아니다.

SMS전송이기 때문에 LMS, MMS등에 필요한 요청 항목은 모두 제외했다. 또한 요청 항목의 messages부분은 DTO로 관리하여 그때 그때 맞는 발신자(to)와 내용(content)를 담도록 구현 하자.

(subject의 경우는 LMS, MMS에서만 사용 가능하므로 제외한다.)

MessageDTO

@AllArgsConstructor
@NoArgsConstructor
@Setter
@Getter
@Builder
public class MessageDTO {
	String to;
	String content;
}

SmsRequestDTO

@AllArgsConstructor
@NoArgsConstructor
@Setter
@Getter
@Builder
public class SmsRequestDTO {
	String type;
	String contentType;
	String countryCode;
	String from;
	String content;
	List<MessageDTO> messages;
	
}

SmsResponseDTO

@AllArgsConstructor
@NoArgsConstructor
@Setter
@Getter
@Builder
public class SmsResponseDTO {
	String requestId;
	LocalDateTime requestTime;
	String statusCode;
	String statusName;
}

메시지 발송 - Service 메소드 생성

이제 정말로 메시지 발송을 구현할 시간이다! Service단에 메시지 발송 메소드를 추가하자.

SmsService.java

public SmsResponseDTO sendSms(MessageDTO messageDto) throws JsonProcessingException, RestClientException, URISyntaxException, InvalidKeyException, NoSuchAlgorithmException, UnsupportedEncodingException {
		Long time = System.currentTimeMillis();
		
		HttpHeaders headers = new HttpHeaders();
		headers.setContentType(MediaType.APPLICATION_JSON);
		headers.set("x-ncp-apigw-timestamp", time.toString());
		headers.set("x-ncp-iam-access-key", accessKey);
		headers.set("x-ncp-apigw-signature-v2", makeSignature(time));
		
		List<MessageDTO> messages = new ArrayList<>();
		messages.add(messageDto);
		
		SmsRequestDTO request = SmsRequestDTO.builder()
				.type("SMS")
				.contentType("COMM")
				.countryCode("82")
				.from(phone)
				.content(messageDto.getContent())
				.messages(messages)
				.build();
		
		ObjectMapper objectMapper = new ObjectMapper();
		String body = objectMapper.writeValueAsString(request);
		HttpEntity<String> httpBody = new HttpEntity<>(body, headers);
		
		RestTemplate restTemplate = new RestTemplate();
	    restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestFactory());
	    SmsResponseDTO response = restTemplate.postForObject(new URI("https://sens.apigw.ntruss.com/sms/v2/services/"+ serviceId +"/messages"), httpBody, SmsResponseDTO.class);

	    return response;	
	}

8번째 줄에서 아까 선언해둔 makeSignature 메소드를 사용해 3 번째 헤더를 생성하는 것을 볼 수 있다!

메시지 발송 - Controller

해당 API 동작을 테스트하는 방법은 POSTMAN 등 여러 방식이 있겠지만,

필자는 view를 직접 만들어 테스트해보도록 하겠다.

(귀찮은 사람들은 postman을 통해 controller에서 설정한 url로 테스트 가능하다.)

SmsController.java

package com.example.demo.controller;

import java.io.UnsupportedEncodingException;
import java.net.URISyntaxException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.client.RestClientException;

import com.example.demo.dto.MessageDTO;
import com.example.demo.dto.SmsResponseDTO;
import com.example.demo.service.SmsService;
import com.fasterxml.jackson.core.JsonProcessingException;

import lombok.RequiredArgsConstructor;

@Controller
@RequiredArgsConstructor
public class SmsController {
	
	private final SmsService smsService;
	
	@GetMapping("/send")
	public String getSmsPage() {
		return "sendSms";
	}
	
	@PostMapping("/sms/send")
	public String sendSms(MessageDTO messageDto, Model model) throws JsonProcessingException, RestClientException, URISyntaxException, InvalidKeyException, NoSuchAlgorithmException, UnsupportedEncodingException {
		SmsResponseDTO response = smsService.sendSms(messageDto);
		model.addAttribute("response", response);
		return "result";
	}

	
}

메시지 발송 - View

타임리프 view 템플릿을 사용하였다!

sendSms.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="ko">
<head>
    <meta charset="UTF-8">
    <title>Send Mail</title>
    <script type="text/javascript" src="/scripts/jquery-ui/jquery.min.js"></script>
	<script type="text/javascript" src="/scripts/common/common-ui.js"></script>
	<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css">
	<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
	<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js"></script>
</head>
<body>
<div>
    <h1>텍스트 메일 보내기</h1>
 
    <form th:action="@{/sms/send}" method="post">
        <table>
            <tr class="form-group">
                <td>발송할 전화번호</td>
                <td>
                    <input type="text" class="form-control" name="to" placeholder="이메일 주소를 입력하세요">
                </td>
            </tr>
            <tr class="form-group">        
                <td>내용</td>
                <td>
                    <textarea class="form-control" name="content" placeholder="보낼 내용을 입력하세요"> </textarea>
                </td>
            </tr>
        </table>
        <button class="btn btn-default">발송</button>
    </form>

 </div>
 </body>
 </html>

result.html

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="ko">
<head>
  <title>Bootstrap Example</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/css/bootstrap.min.css">
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
  <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.4.1/js/bootstrap.min.js"></script>
</head>
<body>

<div class="container">
  <h2>SMS 내역 조회</h2>        
  <table class="table table-bordered">
    <thead>
      <tr>
        <th>requestId</th>
        <th>요청 시간</th>
        <th>Status Code</th>
        <th>Status Name</th>
      </tr>
    </thead>
    <tbody>
      <tr >
        <td th:text="${response.requestId}"></td>
        <td th:text="${response.requestTime}"></td>
        <td th:text="${response.statusCode}"></td>
        <td th:text="${response.statusName}"></td>
      </tr>
    </tbody>
  </table>
</div>

</body>
</html>

실행 결과

이제 실행결과를 확인해보자.

전송

무사히 전송된 것을 볼 수 있다.

직접 NAVER CLOUD PLATFORM 콘솔 화면에 들어가도 전송 내역을 더 깔끔한 ui로 확인 가능하다.

개발하며 외부 API를 사용할수록 기본적인 작동 방식이 다 비슷하구나.. 라는 점을 느낀다.

각 서비스 주체에서 발급받은 KEY값을 가지고 제시하는 규격에 맞게 요청하면 손쉽게 받아올 수 있는 것 같다.

따라서 API 공식문서를 잘! 읽어봐야 한다는 점을 새삼 느꼈다.

(사실 필자의 경우 예시에 나와있는 url을 그대로 가져다 써서 401오류로 1시간을 날렸다..)

NAVER SMS API 정복!

어? 되네? 어? 안되네?

OOM 원인 분석기, 근데 이제 데드락과 스레드

문제 발생: Heap도 안 찼는데 OOM?

단서 발견: DataDog에서 보인 ‘스레드 수’

문제 재현을 위한 부하 테스트 환경 구성

⚙️ 테스트 도구 & 환경 세팅

테스트 대상 API 분석 및 선정

2차 테스트: Member Log API에서 데드락이?

데드락 원인 분석

데드락 해결을 위한 코드 수정

그런데... 또 Heap이 급등?

스레드 누수의 진짜 원인 - Async 설정

✅ 최종 조치

1. 데드락 해결

→ AFTER_COMMIT을 사용하여 트랜잭션이 끝난 후에 이벤트를 처리하도록 설정 @Async 와 함께 비동기 이벤트 처리를 사용하여 트랜잭션이 끝난 후 별도의 스레드에서 이벤트를 처리

2. @Async 설정 수정

테스트 결과

근데 찝찝한 점 하나

번외

Spring Batch StepScope 사용 시 Entity Not Mapped 오류 해결법 (다중 데이터소스 환경)

Spring Batch에서 Entity Not Mapped 오류 발생

Bean 주입 시점과 프록시로 발생한 문제 분석

StepScope란? Spring Batch에서의 Bean 생명주기 설명

기존 코드

개선된 코드

StepScope에서 메서드 주입을 통한 문제 해결

StepScope와 JobScope의 차이점 및 사용 시점

한마디로 정리하면

최종 정리

느낀 점

자바의 로봇청소기, 가비지 컬렉션

♻ 가비지 컬렉션 ( vs 가비지 컬렉터)

가비지 컬렉션

가비지 컬렉터

♻ 가비지 컬렉션의 제거 기준

♻ JVM 메모리에서의 객체들

♻ 가비지 컬렉션의 청소 과정

Mark And Sweep

♻ 가비지 컬렉션의 실제 동작 과정

♻ GC의 weak generational hypothesis

♻ Heap의 Young과 Old 영역

Young 영역(Young Generation)

Old 영역(Old Generation)

♻ Young 영역의 분리 → Eden, Survival0, Survival1

Eden

Survivor 0 / Survivor 1

♻ Minor GC 과정 (in young Generation)

♻ Major GC 과정 (in Old Generation)

♻ Stop-The-World

Reference

Spring Security @EnabledWebSecurity 의 동작원리

Spring Security?

@ 어노테이션

@EnabledWebSecurity

@EnabledWebSecurity 파헤치기

@EnableGlobalAuthentication

@EnabledWebSecurity 동작원리

WebSecurityConfiguration

SpringWebMvcImportSelector

OAuth2ImportSelector

HttpSecurityConfiguration

AuthenticationConfiguration

✨ 참고 (Reference)

RabbiqMQ란 무엇일까?

RabbitMQ

AMQP

RabbitMQ의 동작 방식

RabbitMQ 구성요소

1) Exchange

2) Binding

3) Queue

Standard Exchange Type

Direct Exchange

Topic Exchange

Fanout Exchange

Headers Exchange

Prefetch Count

[Docker] 도커와 컨테이너

컨테이너의 탄생과 진화과정

1. chroot의 탄생

→ AFTER_COMMIT을 사용하여 트랜잭션이 끝난 후에 이벤트를 처리하도록 설정
@Async 와 함께 비동기 이벤트 처리를 사용하여 트랜잭션이 끝난 후 별도의 스레드에서 이벤트를 처리