Dove

Header를 이용해 Spring Context에 timezone 세팅

dev.Dove — Sat, 23 Nov 2024 13:10:17 +0900

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/i18n/LocaleContextHolder.html

LocaleResolver를 사용하면, API를 처리하는 로직에서 다국어를 처리할 수 있다.

쿠키를 사용하는 CookieLocaleResolver의 경우 timezone, locale을 지원해 준다. 하지만, Accept-Language를 사용할 경우 AcceptHeaderLocaleResolver를 사용하는데, AcceptHeaderLocaleResolver는 locale만 지원한다.

들어가기 전

본 포스팅은 Spring Boot3기반으로 작성했습니다. 전체코드는 깃허브를 참고해 주세요.

https://github.com/Dove-kim/spring-boot-3-localization

GitHub - Dove-kim/spring-boot-3-localization: Spring Boot 3 국제화 구현

Spring Boot 3 국제화 구현. Contribute to Dove-kim/spring-boot-3-localization development by creating an account on GitHub.

github.com

Timezone.. 이 Header에 필요한가요?

한국계 미국인이 아랍권 국가에서 서비스를 사용할 경우 다음과 같이 정보를 생각할 수 있다.

1. 언어 - 한국어

2. 정책 - 미국

3. time zone - 아랍

1. App이 호출 할 때 쿠키를 사용하는 건 어떨까?

CookieLocaleResolver를 사용하면 timezone을 받을 수 있으나, 웹이 아닌 클라이언트도 쿠키를 세팅해야 하는 기이한 현상이 발생한다. 쿠키도 결국 헤더에 Set-Cookie로 값을 세팅하니, 쿠키의 원형은 결국 Header다.

플랫폼 간 API호출을 통일화하기 위해 쿠키보단 Header를 이용하는 것이 바람직해 보인다.

2. 클라이언트가 타임존을 확인해서 계산은 건 어떨까?

괜찮은 방법이다. 이건 개발 시작전 인터페이스를 협의할 때 클라이언트 개발자와 잘 협의하면 해결된다.

클라이언트에서 시간을 타임존에 계산할 경우 서버는 unix timestamp나 UTC+00:00 기준 시간을 제공하고 클라이언트가 계산을 한다.

하지만 일부 레거시 서비스의 경우 클라이언트의 수정이 여러가지 원인에 의해 불가해서 서버가 계산을 해 줘야 할 수 있다.

즉, 기본적으로 서버는 기준시간을 제공하여 클라이언트가 timezone을 계산하되 일부 API에서는 Header에 Timezone을 받을 수 있게 구현하는 걸 고려해 볼 수 있다.

LocaleResoler를 이용하면, 서비스 레이어에서 필요할 경우 timezone을 사용할 수 있다.

Header를 이용해 timezone을 받도록 세팅하기 위해 CookieLocaleResolver를 먼저 확인해 보자

CookieLocaleResolver 내부는 Header와 무엇이 다른가?

CookieLocaleResolver는 AbstractLocaleContextResolver를 상속받았고, AcceptHeaderLocaleResolver는 AbstractLocaleResolver를 상속받았다.

AbstractLocaleContextResolver는 AbstractLocaleResolver를 상속받고 timezone을 추가했다.

그러면 AbstractLocaleContextResolver를 상속받아서 특정 Header값을 timezone으로 매핑하고 LocaleContext로 세팅하면 될 듯하다.

구현해 보자

public class AcceptHeaderLocaleAndTimeZoneResolver extends AbstractLocaleContextResolver {
    public static final String LOCALE_HEADER_ATTRIBUTE_NAME = "Accept-Language";
    public static final String TIME_ZONE_HEADER_ATTRIBUTE_NAME = "Accept-TimeZone";


    @Override
    public LocaleContext resolveLocaleContext(final HttpServletRequest request) {
        Locale locale = resolveLocale(request);
        TimeZone timeZone = resolveTimeZone(request);

        return new TimeZoneAwareLocaleContext() {
            @Override
            @Nullable
            public Locale getLocale() {
                return locale;
            }

            @Override
            @Nullable
            public TimeZone getTimeZone() {
                return timeZone;
            }
        };
    }

    @Override
    public Locale resolveLocale(HttpServletRequest request) {
        Locale defaultLocale = getDefaultLocale();
        String acceptLanguage = request.getHeader(LOCALE_HEADER_ATTRIBUTE_NAME);

        if (StringUtils.hasText(acceptLanguage)) {
            return Locale.forLanguageTag(acceptLanguage);
        } else {
            return (defaultLocale != null) ? defaultLocale : request.getLocale();
        }
    }

    private TimeZone resolveTimeZone(HttpServletRequest request) {
        String timeZoneHeader = request.getHeader(TIME_ZONE_HEADER_ATTRIBUTE_NAME);

        if (StringUtils.hasText(timeZoneHeader)) {
            try {
                ZoneId zoneId = ZoneId.of(timeZoneHeader);
                return TimeZone.getTimeZone(zoneId);
            } catch (DateTimeException e) {
                // 유효하지 않은 timeZoneHeader 값을 무시하고 기본 TimeZone을 설정
                return getDefaultTimeZone() != null ? getDefaultTimeZone() : TimeZone.getDefault();
            }
        } else {
            return getDefaultTimeZone() != null ? getDefaultTimeZone() : TimeZone.getDefault();
        }
    }

    @Override
    public void setLocaleContext(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable LocaleContext localeContext) {
        throw new UnsupportedOperationException("Cannot change HTTP headers - use a different locale resolution strategy");
    }

    @Override
    public void setLocale(HttpServletRequest request, @Nullable HttpServletResponse response, @Nullable Locale locale) {
        throw new UnsupportedOperationException("Cannot change HTTP Accept-Language header - use a different locale resolution strategy");
    }


}

만든 구현체를 Bean으로 등록하면 끝난다.

@Configuration
@EnableWebMvc
@RequiredArgsConstructor
public class WebConfig implements WebMvcConfigurer {

    @Bean
    public LocaleResolver localeResolver() {
        return new AcceptHeaderLocaleAndTimeZoneResolver();
    }

}

테스트 코드도 작성해 보자

@WebMvcTest(MainController.class)
class MainControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void givenAcceptTimeZoneHeader_whenResolveTimeZone_thenTimeZoneIsSet() throws Exception {
        // Given
        String acceptTimeZone = "Europe/Paris";
        TimeZone expectedTimeZone = TimeZone.getTimeZone(acceptTimeZone);

        // When
        String response = mockMvc.perform(get("/").header("Accept-TimeZone", acceptTimeZone))
                .andExpect(status().isOk())
                .andReturn()
                .getResponse()
                .getContentAsString();

        // Then
        Assertions.assertEquals(response, expectedTimeZone.getID());
    }
}

Spring Boot 2.1부터는 이미 정의한 Bean의 Overrideing을 불허한다..?

Resolver를 등록하면 위 스크린샷처럼 에러가 발생한다.

The bean 'localeResolver', defined in class path resource [com/dove/config/WebConfig.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/web/servlet/config/annotation/DelegatingWebMvcConfiguration.class] and overriding is disabled.

Spring Boot 2.1부터 스프링은 이 정의된 Bean의 오버라이딩을 막았다.

이를 해결하기 위해 오버라이딩을 허용해 준다.

spring:
  main:
    allow-bean-definition-overriding: true

참고한 글

https://www.baeldung.com/spring-boot-bean-definition-override-exception#configuration-change-for-spring-boot

EC2를 이용한 AWS ECS 기반 Spring Boot 3 DataDog 적용

dev.Dove — Thu, 3 Oct 2024 16:53:06 +0900

글과 상관없는 DataDog live Seoul 2024

들어가기 전...

인프라: AWS ECS, AWS EC2, AWS Linux 2023

서버: Spring Boot 3(Java 17), Micrometer Tracing

결말 미리 보기

DataDog에 서버의 정보를 보내려면 DataDog agent를 이용해야 하고 EC2 내 서비스들은 APM을 이용해 Agent에게 정보를 보내도록 설정한다.

EC2 인스턴스 타입을 c5.large 기준 ENI 제한이 3이다. 이로 인해 ECS 서비스 2개를 실행하고 DataDog agent는 각 ec2에서 2개의 서버 정보를 수집한다. 인스턴스 타입을 변경해서 단일 EC2에 더 많은 서비스를 기동 하면, DataDog host 비용을 절약할 수 있다. DataDog은 agent의 수로 host 수를 측정한다.

infrastructure 수집을 포기한다면 단일 agent만 서비스로 실행하고 모든 서비스의 정보를 수집할 수도 있다. 다만 이러면, Datadog을 사용하는 이유가.. 있을까?

1. DataDog agent ECS 내 등록, 실행

1. datadog-agent.json 파일을 만든다.

본 글에서는 agent 내 별도 기능을 미설정했습니다. 문서를 통해 로그 수집, 프로세스 데이터 수집, 네트워크 정보 수집이 가능하다.

공식문서는 memory를 256으로 세팅하는 json을 보여준다. 본 글에서는 512를 했다. 중요한 건 EC2 기반 ECS에서는 서비스 실행을 위해 task에 설정한 메모리가 EC2 내 여유자원으로 있어야 서비스가 실행된다. c5a.large은 4GB의 메모리를 설정되어 있으나, 실제 사용가능한 메모리는 약 3800MB다. datadog agent를 ec2에서 실행할 경우 512MB를 제외한 용량에서 서비스 메모리를 설정해야 한다.

datadog-agent.json

{
    "family": "datadog-agent-task",
    "containerDefinitions": [
        {
            "name": "datadog-agent",
            "image": "public.ecr.aws/datadog/agent:latest",
            "cpu": 100,
            "memory": 512,
            "portMappings": [
                {
                    "containerPort": 8126,
                    "hostPort": 8126,
                    "protocol": "tcp"
                }
            ],
            "essential": true,
            "environment": [
                {
                    "name": "DD_SITE",
                    "value": "datadoghq.com"
                },
                {
                    "name": "DD_API_KEY",
                    "value": "{datadog api key}"
                }
            ],
            "mountPoints": [
                {
                    "sourceVolume": "docker_sock",
                    "containerPath": "/var/run/docker.sock",
                    "readOnly": true
                },
                {
                    "sourceVolume": "cgroup",
                    "containerPath": "/host/sys/fs/cgroup",
                    "readOnly": true
                },
                {
                    "sourceVolume": "proc",
                    "containerPath": "/host/proc",
                    "readOnly": true
                },
                {
                    "sourceVolume": "pointdir",
                    "containerPath": "/opt/datadog-agent/run",
                    "readOnly": false
                },
                {
                    "sourceVolume": "containers_root",
                    "containerPath": "/var/lib/docker/containers",
                    "readOnly": true
                }
            ],
            "volumesFrom": [],
            "systemControls": []
        }
    ],
    "volumes": [
        {
            "name": "docker_sock",
            "host": {
                "sourcePath": "/var/run/docker.sock"
            }
        },
        {
            "name": "proc",
            "host": {
                "sourcePath": "/proc/"
            }
        },
        {
            "name": "cgroup",
            "host": {
                "sourcePath": "/sys/fs/cgroup/"
            }
        },
        {
            "name": "pointdir",
            "host": {
                "sourcePath": "/opt/datadog-agent/run"
            }
        },
        {
            "name": "containers_root",
            "host": {
                "sourcePath": "/var/lib/docker/containers"
            }
        }
    ]
}

2. json 파일을 이용해 task 등록

aws ecs register-task-definition --cli-input-json datadog-agent.json

명령어를 통해 ECS task에 DataDog agent를 등록한다.

3. DataDog Agent deamon 실행

위 사진처럼 서비스를 생성하면 각 EC2에 DataDog agent가 실행된다.

2. Spring Boot 3 trace id 설정

개발, 운영 모두 DataDog을 못 사용할 수 도 있다. 또는 spring boot를 이용해 MSA 환경을 구성한 경우 서버에서 Spring Cloud Sleuth를 사용한다. Spring Boot3에서 sleuth는 더 이상 사용이 불가하다. 대신 Micrometer Tracing를 사용하여 log를 설정할 수 있다.

1. (선택) Micrometer 설정

build.gradle에 micrometer를 설정한다. datadog을 이용하기에 io.zipkin.reporter2는 제외한다. openfeign 사용을 위한 라이브러리도 추가한다.

    // Micrometer Tracing
    implementation('io.micrometer:micrometer-tracing-bridge-brave') {
        exclude group: 'io.zipkin.reporter2'
    }
    implementation 'io.github.openfeign:feign-micrometer'

logback은 다음과 같이 설정한다.

%X{traceId},%X{spanId}

2. logback 설정

datadog traceid는 dd.traceId로 설정해야 주입받을 수 있다.

출처: https://docs.datadoghq.com/ko/tracing/other_telemetry/connect_logs_and_traces/java/?tab=log4j2

Correlating Java Logs and Traces

Connect your Java logs and traces to correlate them in Datadog.

docs.datadoghq.com

<property name="LOG_PATTERN"
  value="%clr(%d{yyyy-MM-dd HH:m:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) [%clr(${springAppName:-}){yellow},%X{dd.trace_id},%X{dd.span_id:-} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
   
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>${LOG_PATTERN}</pattern>
        <charset>utf8</charset>
    </encoder>
</appender>

3. Dockerfile을 이용한 datadog apm 설정

Dockerfile에 apm을 설정하는 건 다음 코드를 참고하면 된다.

서버에서 traceId를 출력하도록 주입을 위해 DD_LOGS_INJECTION를 설정한다. 추가로 W3C기반 traceid를 사용하기 위해 DD_TRACE_PROPAGATION_STYLE도 설정한다.

DD_AGENT_HOST는 Amazon Linux 2023 기준으로 작성했다. 다른 OS는 문서를 참고...

#!/bin/bash
FROM amazoncorretto:17
WORKDIR /app

ENV VERSION="{버전}"
ENV APP_NAME="{artifact 이름}"

COPY build/libs/${APP_NAME}-${VERSION}.jar .

#DataDog 설정
ENV DD_SERVICE={서비스 명}
ENV DD_LOGS_INJECTION=true 
ENV DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED=true
ENV DD_TRACE_PROPAGATION_STYLE=tracecontext,datadog
ENV DD_ENV=prod
ENV DD_TRACE_SAMPLE_RATE=1
ENV DD_VERSION=1.0.0

ADD 'https://dtdg.co/latest-java-tracer' dd-java-agent.jar

CMD export DD_AGENT_HOST=$(TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600");curl http://169.254.169.254/latest/meta-data/local-ipv4 -H "X-aws-ec2-metadata-token: $TOKEN"); \
    java -javaagent:dd-java-agent.jar \
    -jar \
    -Djava.net.preferIPv4Stack=true -Dspring.profiles.active=prod \
    ${APP_NAME}-${VERSION}.jar;

번외. Datadog console에서 보이는 traceid와 서버 traceid가 다르다!

https://docs.datadoghq.com/ko/tracing/guide/span_and_trace_id_format/

Trace and Span ID Formats

Datadog, the leading service for cloud-scale monitoring.

docs.datadoghq.com

trace id의 형식이 달라 생긴 문제다. 아래 설정을 통해 128비트 Trace ID는 32자의 소문자 16진수로 보이며 로그의 traceid를 datadog에서 동일하게 보여준다.

DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED=true

참고한 글

https://docs.datadoghq.com/ko/containers/amazon_ecs/apm/?tab=ec2%EB%A9%94%ED%83%80%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%97%94%EB%93%9C%ED%8F%AC%EC%9D%B8%ED%8A%B8

ECS 애플리케이션 추적

Datadog, the leading service for cloud-scale monitoring.

docs.datadoghq.com

https://docs.datadoghq.com/ko/tracing/guide/span_and_trace_id_format/

Trace and Span ID Formats

Datadog, the leading service for cloud-scale monitoring.

docs.datadoghq.com

https://docs.datadoghq.com/ko/tracing/trace_collection/automatic_instrumentation/dd_libraries/java/?tab=wget

Tracing Java Applications

Datadog, the leading service for cloud-scale monitoring.

docs.datadoghq.com

https://docs.datadoghq.com/ko/containers/

컨테이너 모니터링

컨테이너화된 인프라스트럭처에서 데이터를 수집하기 위한 에이전트 설치 및 설정

docs.datadoghq.com

기본적인 AWS VPC 구성기

dev.Dove — Sat, 27 Jul 2024 18:20:47 +0900

구성할 VPC

2024년 7월 기준 AWS Console ui를 스크린샷으로 캡처했습니다. 추후 ui는 변경될 수 있습니다.

1. VPC 생성

1. VPC 서비스에서 Virtual Private Cloud > VPC > VPC 생성 클릭

2. VPC 생성 정보 입력 후 "생성" 버튼 클릭

- 생성할 리소스: VPC만

- 이름 태그: 원하는 VPC이름 입력

- IPv4 CIDR: 원하는 IP를 입력(x.x.0.0에 /16 선택 시 x.x.0.0 ~ x.x.255.255)

3. 생성한 VPC 확인

2. VPC 서브넷 생성

1. VPC 서비스에서 Virtual Private Cloud > 서브넷 > 서브넷 생성 클릭

2. VPC ID에 앞서 만든 VPC 선택

3. 퍼블릭 서브넷으로 만들 정보입력 이후 서브넷 생성 클릭

- 서브넷 이름: 퍼블릭 서브넷 이름 입력

- 가용영역: 서울 기준 a, b, c, d 중 하나 선택 가능

- IPv4 서브넷 CIDR 블록: 원하는 IP 영역을 입력 https://ko.rakko.tools/tools/27/를 이용하면 보다 편하게 계산 가능

4.다시 서브넷 생성 클릭 이후 3번과 동일하게 프라이빗 서브넷으로 만들 정보입력 이후 서브넷 생성 클릭

3. 라우팅 테이블 생성

1. VPC 서비스에서 Virtual Private Cloud > 라우팅 테이블 > 라우팅 테이블 생성 클릭

2. 퍼블릭, 프라이빗 서브넷 2개용 라우팅 테이블을 2개 생성

3. 만들어진 라우팅 테이블의 ID를 클릭한다.

4. 서브넷 연결 > 서브넷 연결 편집 클릭

5. 각 라우팅 테이블에서 서브넷을 하나씩 선택 후 연결 저장 클릭

6. 서브넷 연결 확인

4. 퍼블릭 서브넷을 위한 인터넷 게이트웨이 생성

1. VPC 서비스에서 Virtual Private Cloud > 인터넷 게이트웨이 > 인터넷 게이트웨이 생성 클릭

2. 이름 태그 입력 후 인터넷 게이트웨이 생성 클릭

3. 안내창의 VPC에 연결 버튼 또는 작업 > VPC에 연결 버튼 클릭

4. 앞서 만든 VPC 선택 후 인터넷 게이트웨이 연결

5. VPC 서비스에서 Virtual Private Cloud > 라우팅 테이블 > 앞서 만든 퍼블릭 서브넷용 라우팅 테이블 ID 클릭

6. 라우팅 > 라우팅 편집 클릭

7. 라우팅 추가 클릭

8. 앞서 만든 인터넷 게이트웨이 정보 입력 후 변경 사항 저장 클릭
- 대상: 모든 인터넷의 접근을 위해 0.0.0.0 입력 후 앞서 만든 인터넷 게이트웨이 선택

5. 프라이빗 서브넷용 NAT 게이트웨이 생성

프라이빗 서브넷에서 인터넷에 접근할 일이 없다면 작업 안 하길 추천한다. NAT 게이트웨이는 생성하면 사용여부와 관계없이 요금이 발생한다.

1. VPC 서비스에서 Virtual Private Cloud > NAT 게이트웨이 > NAT 게이트웨이 생 클릭

2. NAT 게이트웨이 정보 입력 후 NAT 게이트웨이 생성 클릭

- 이름: 원하는 게이트웨이 이름 입력

- 서브넷: NAT 게이트웨이를 위치할 퍼블릭 서브넷 선택

- 탄력적 IP 할당: 탄력적 IP 할당 버튼을 클릭하면 자동으로 세팅된다.

탄력적 IP 할당 버튼을 클릭하면 EC2 서비스에서 탄력적 IP가 만들어진다.
추후 NAT 게이트웨이를 지워도 탄력적 IP는 살아있으며, AWS 미사용하는 탄력적 IP에 대해 과금을 하니, 주의가 필요하다.

3. VPC 서비스에서 Virtual Private Cloud > 라우팅 테이블 > 앞서 만든 프라이빗 서브넷용 라우팅 테이블 ID 클릭

5. 라우팅 > 라우팅 편집 클릭

6. 라우팅 추가 클릭 후 라우팅 정보 입력 후 변경 사항 저장 클릭

- 대상: 모든 인터넷의 접근을 위해 0.0.0.0 입력 후 앞서 만든 NAT 게이트웨이 선택

6. 만든 VPC 확인

VPC > 만든 VPC 클릭 > 리소스 맵에 들어가면 만들었던 VPC를 GUI로 볼 수 있다.

AWS SQS 256KB 이상 대용량 메시지 처리와 Spring Boot

dev.Dove — Sat, 6 Jul 2024 15:29:52 +0900

출처: https://aws.amazon.com/ko/sqs/

들어가기 전..

Spring Boot 3.3.1(Java 17)을 기준으로 구현했습니다.

2024년 7월 기준 AWS SQS 대용량 전송 라이브러리는 Java, Python만 있습니다.

소스는 GitHub에서 확인 가능합니다.
https://github.com/Dove-kim/spring-boot-3-aws-sqs-bigmessage

GitHub - Dove-kim/spring-boot-3-aws-sqs-bigmessage: AWS SQS에서 256KB 이상의 메시지 전송 기능 구현

AWS SQS에서 256KB 이상의 메시지 전송 기능 구현. Contribute to Dove-kim/spring-boot-3-aws-sqs-bigmessage development by creating an account on GitHub.

github.com

보낼 수 있는 크기의 제한..?

출처: https://aws.amazon.com/ko/sqs/features/

AWS SQS 완전 관리형에 백만건당 요금을 부과하기에 꽤 저렴하다.

하지만.. 큰 메시지를 보낼 때는 제약이 있고 AWS는 S3를 이용해 큰 메시지를 전송하도록 안내한다.

다행히 Java는 라이브러리를 제공해 준다. 라이브러리를 사용하면 큰 용량의 메시지도 편리하게 보낼 수 있다.

단점으로는 S3를 추가로 사용하는 이유로 S3 저장비용과 데이터를 가져오는 비용을 감수해야 한다.

간단한 SQS와 S3 만들기

1. 원하는 이름의 표준 대기열을 하나 만든다.

2. 메시지 동시 처리를 막기 위해 표시 제한 시간과 기타 설정값을 세팅한다.

3. 다른 설정은 변경 없이 "대기열 생성" 버튼 클릭

4. S3 버킷을 만든다.

스프링에서 SQS 확장 클라이언트 라이브러리 적용해 보기

1. build.gradle 수정

https://spring.io/projects/spring-cloud-aws보다 AWS SDK를 직접 사용하는 것을 개인적으로 선호합니다.

implementation platform("software.amazon.awssdk:bom:2.21.1")
implementation "software.amazon.awssdk:sqs"
implementation "software.amazon.awssdk:s3"

implementation 'com.amazonaws:amazon-sqs-java-extended-client-lib:2.1.1'

2. S3, SQS 클라이언트 bean 등록

DefaultCredentialsProvider.create()를 통해 서버가 기동 되는 환경에서 AWS CLI나 IAM 역할로 서버에게 AWS 접근을 가능하게 도와준다.

@Configuration
public class AwsConfig {

    @Bean
    public SqsClient sqsClient() {
        return SqsClient.builder()
                .region(Region.AP_NORTHEAST_2)
                .credentialsProvider(DefaultCredentialsProvider.create())
                .build();
    }

    @Bean
    public S3Client s3Client() {
        return S3Client.builder()
                .region(Region.AP_NORTHEAST_2)
                .credentialsProvider(DefaultCredentialsProvider.create())
                .build();
    }
}

3. AWS SQS 확장 라이브러리 클라이언트에 사전에 만든 S3를 세팅한다.

ExtendedClientConfiguration extendedClientConfig = new ExtendedClientConfiguration()
	.withPayloadSupportEnabled(s3Client, BUCKET_NAME);
this.sqsExtended = new AmazonSQSExtendedClient(SqsClient.builder().build(), extendedClientConfig);

4. SQS에서 메시지를 풀링 한다.

// SQS queue url
this.queueUrl = sqsClient.getQueueUrl(builder -> builder
        .queueName(SQS_QUEUE_NAME).build());
ReceiveMessageRequest receiveMessageRequest = ReceiveMessageRequest.builder()
                .queueUrl(queueUrl.queueUrl())
                .maxNumberOfMessages(10)
                .waitTimeSeconds(0)
                .build();
        
ReceiveMessageResponse receiveMessageResponse = sqsExtended
	.receiveMessage(receiveMessageRequest);

5. 읽고 처리한 메시지는 지운다.

DeleteMessageRequest deleteMessageRequest = DeleteMessageRequest.builder()
                .queueUrl(queueUrl.queueUrl())
                .receiptHandle(message.receiptHandle())
                .build();
sqsExtended.deleteMessage(deleteMessageRequest);

질문 1. S3는 어떻게 작동을 도와줄까?

간단하게 메시지를 publish 할 수 있는 컨트롤러를 만들고 postman으로 날려보자.

간단한 컨트롤러에 약 353KB의 메시지 전송

IDE에서 브레이크 포인트로 메시지 처리를 멈추고

S3에 가보니, 전송한 데이터가 파일로 만들어져 있다.

열어보니, 전송한 내용이다.

이후 SQS client를 이용해 SQS 메시지를 지우면 S3에 있던 데이터도 같이 지워진다.

질문 2. 256KB보다 작은 사이즈의 메시지도 S3가 관여하는가?

PayloadStorageConfigurationBase에서 AmazonSQSExtendedClient를 세팅할 때 항상 S3를 사용할지 옵션이 있다.

AmazonSQSExtendedClient는 설정 값에 따라 설정이 false이면, 메시지의 크기에 맞춰 S3를 사용할지 결정한다.

즉, 라이브러리에서 256KB보다 작은 메시지는 SQS만 이용하고 256KB보다 클 경우만 S3에 메시지를 저장하고 사용한다.

질문 3. SQS에서는 일정 시간이 지나면 처리 못한 메시지가 사라지는데 S3도 사라지게 할 수 있을까?

S3 버킷에서 수명주기를 설정하면 SQS에서 메시지 보존 기간만큼 S3에서도 파일을 저장할 수 있다.

참고한 문서

https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-s3-messages.html

자바와 아마존 S3를 사용하여 대용량 Amazon SQS 메시지 관리 - Amazon Simple Queue Service

Java용 Amazon SQS 확장 클라이언트 라이브러리를 사용하면 Amazon S3에 AWS SDK for Java만 사용하여 Amazon SQS 메시지를 관리할 수 있습니다. Amazon SQS 콘솔 AWS CLI, Amazon SQS HTTP API 또는 기타 SDK로는 이 작업을

docs.aws.amazon.com

https://aws.amazon.com/ko/sqs/pricing/

Amazon SQS 요금 | 메시지 대기열 서비스 | AWS

* 프리 티어 사용량은 매달 GovCloud 리전을 제외한 모든 리전의 사용량을 합산하여 계산되며, 청구서에 자동으로 적용됩니다. 사용되지 않은 프리 티어는 다음 달로 이월되지 않습니다. 제약 조건

aws.amazon.com

https://spring.io/projects/spring-cloud-aws

Spring Cloud for Amazon Web Services

Spring Cloud for Amazon Web Services is a community-run project. The website is https://awspring.io/ and the source repository is located at https://github.com/awspring/spring-cloud-aws. Spring Cloud for Amazon Web Services, eases the integration with host

spring.io

AWS Bedrock + Spring Boot + Amazon Bedrock Guardrails를 이용해 간단한 AI 사용해보기

dev.Dove — Sun, 16 Jun 2024 18:13:31 +0900

출처: https://aws.amazon.com/ko/bedrock/?gclid=CjwKCAjwmrqzBhAoEiwAXVpgog6_EsXEYtqJQ5fNPU4BEh78xmY_rgkERvlGPEUTpz9-mYdTeHp3VRoCLXIQAvD_BwE&trk=24a8f13a-f5db-4127-bcb7-8b2876aa4265&sc_channel=ps&ef_id=CjwKCAjwmrqzBhAoEiwAXVpgog6_EsXEYtqJQ5fNPU4BEh78xmY_rgkERvlGPEUTpz9-mYdTeHp3VRoCLXIQAvD_BwE:G:s&s_kwcid=AL!4422!3!692062155749!e!!g!!amazon%20bedrock!21058131112!157173586057

들어가기전..

본게시물은 2024년 6월에 작성했습니다.

Java 11, Spring Boot3를 사용했으며, 자세한 소스는 GitHub에 올렸습니다.

spring-boot-3-aws-bedrock/src/main/java/com/dpot/bedrock/domain/aichat/service at main · Dove-kim/spring-boot-3-aws-bedrock

AWS Bedrock + Spring Boot 3. Contribute to Dove-kim/spring-boot-3-aws-bedrock development by creating an account on GitHub.

github.com

AWS Bedrock FM 사용 신청

한국어를 사용할 수 있으며 토큰제한이 가장 큰(2024년 6월 기준) Cluade 3 모델을 사용해 보자.

먼저, 사용하려는 모델의 액세스를 요청해야 사용이 가능하다. 2024년 6월 기준 미국 버지니아 북부에서 가장 많은 모델을 사용할 수 있다.

원하는 모델의 권한요청을 하고 잠시 기다리면 요청한 모델의 권한이 부여된다.

이제 AWS Bedrock에서 제공업체 > 사용할 모델을 누르면 modelId 및 API 요청 가이드라인을 볼 수 있다.

AWS Bedrock Spring Boot3에서 사용하기

AWS SDK v2 for Java와 bedrock runtime을 import 한다.

	implementation platform('software.amazon.awssdk:bom:2.26.3')
	implementation 'software.amazon.awssdk:bedrockruntime'

AWS Bedrock client도 bean으로 등록한다.

@Configuration
public class AwsConfig {
    @Bean
    public BedrockRuntimeClient bedrockRuntimeClient() {
        return BedrockRuntimeClient.builder()
                .credentialsProvider(DefaultCredentialsProvider.create())
                .region(Region.US_EAST_1)
                .build();
    }
}

선언한 client를 이용해 AWS Bedrock에게 converse api로 요청할 서비스를 만든다.

-> converse api 문서: https://docs.aws.amazon.com/ko_kr/bedrock/latest/APIReference/API_runtime_Converse.html

/**
 * AWS Bedrock Claude3 Sonnet FM을 이용해서 AI와 채팅한다.
 */
@Slf4j
@Service
@RequiredArgsConstructor
public class Claude3SonnetCatChatService implements AiChatService {
    private final String MODEL_ID = "anthropic.claude-3-sonnet-20240229-v1:0";

    private final String SYSTEM_PROMPT = "너는 고양이야 한국어로 질문하면 '낭'으로 문장을 구성해서 대답하고 다른 나라 언어로 그 언어에 맞춰서 고양이 울음소리로 문장을 구성해서 대답해";

    private final BedrockRuntimeClient bedrockRuntimeClient;

    @Override
    public String send(String message) {
        // AI에게 전할 message 생성
        Message requestMessage = Message.builder()
                .content(ContentBlock.fromText(message))
                .role(ConversationRole.USER)
                .build();

        // 프롬프트
        SystemContentBlock systemContentBlock = SystemContentBlock.builder()
                .text(SYSTEM_PROMPT)
                .build();

        try {
            // AI 요청을 날린다.
            ConverseResponse response = bedrockRuntimeClient.converse(request -> request
                    .modelId(MODEL_ID)
                    .messages(requestMessage)
                    .system(systemContentBlock)
                    .inferenceConfig(config -> config
                            .maxTokens(512)
                            .temperature(0.5F)
                            .topP(0.9F)));




            // 응답값을 return
            return response.output().message().content().get(0).text();
        } catch (SdkClientException e) {
            log.error(e.toString(), e);
            throw new RuntimeException(e);
        }

    }
}

이제 간단하게 controller를 만들어서 대화를 시작하면 AI가 답변을 준다.

? AI가 이상하게 답변한다.

FM을 사용할 때는 프롬프트를 어떻게 작성하냐에 따라 AI가 의도한 대로 작동할 수도 못 할 수 도 있다.

private final String SYSTEM_PROMPT = "너는 고양이야 한국어로 질문하면 "+
            " '낭'으로 문장을 구성해서 대답하고 다른 나라 언어로 그 언어에 맞춰서 "+
            "고양이 울음소리로 문장을 구성해서 대답해";

위 프롬프트를 통해 고양이 같은 사람 AI를 만들고 싶었지만. 진짜 고양이 울음소리만 하는 상황을 마주했다.

프롬프트를 수정해서 보다 정확하게 작성할 필요가 있다.

private final String SYSTEM_PROMPT = "너는 고양이고 이름은 'WoongCat'이야. " +
        "모든 문장이 끝면 고양이같은 말투를 써야해 " +
        "Q1: 안녕 너는 누구야? " +
        "A1: 난 고양이 웅캣이다냥. 반갑다냥";

이렇게 작성하면, AI에게 역할을 부여하고 예시를 보여주어 AI의 답변을 의도한 방향으로 만들도록 할 수 있다.

이제야 말을 하는 고양이 같다. 의도한 방향으로 AI가 잘 답변하는 듯하다.

AI에게 이상한 질문을 한다면..?

AI에게 폭력적인 말을 하거나, 불법적인 행위의 질문 나아가서 AI가 의도한 기능 외 다른 기능을 수행한다면, 개발자는 이를 사전에 막아야 한다.

고양이가 갑자기 AI 쳇봇이되는 마법~

이를 해결하기 위해 AWS는 가드레일을 제공해 준다.

FM에 입력 출력값의 필터강도를 GUI로 쉽게 설정이 가능하다.

특정 주제에 대해 필터도 가능하다.

완성된 가드레일은 다음과 같다.

이제 이걸 서비스 코드로 녹이면 다음과 같다. 단, 가드레일 사용 시 converse API 호출은 가드레일 세팅을 미지원한다. 고로 invoke 방식으로 변환해 구현한다.

/**
 * AWS Bedrock Claude3 Sonnet FM을 이용해서 AI와 채팅한다.
 * With AWS Bedrock Guardrail
 */
@Slf4j
@Service
@RequiredArgsConstructor
public class Claude3SonnetCatChatWithGuardRailService implements AiChatService {
    private final String MODEL_ID = "anthropic.claude-3-sonnet-20240229-v1:0";

    private final String SYSTEM_PROMPT = "너는 고양이고 이름은 'WoongCat'이야. " +
            "모든 문장이 끝면 고양이같은 말투를 써야해 " +
            "Q1: 안녕 너는 누구야? " +
            "A1: 난 고양이 웅캣이다냥. 반갑다냥";

    private final BedrockRuntimeClient bedrockRuntimeClient;

    @Override
    public String send(String message) {
        // AI에게 전할 message 생성
        String nativeRequestTemplate = """
                {
                    "anthropic_version": "bedrock-2023-05-31",
                    "max_tokens": 512,
                    "temperature": 0.5,
                    "topP": 0.9,
                    "system": "{{system_prompt}}",
                    "messages": [{
                        "role": "user",
                        "content": "{{prompt}}"
                    }]
                }""";


        String nativeRequest = nativeRequestTemplate
                .replace("{{prompt}}", message)
                .replace("{{system_prompt}}", SYSTEM_PROMPT);

        try {

            // AI 요청을 날린다.
            InvokeModelResponse invokeModelResponse = bedrockRuntimeClient.invokeModel(InvokeModelRequest.builder()
                    .modelId(MODEL_ID)
                    .body(SdkBytes.fromUtf8String(nativeRequest))
                    .guardrailIdentifier("s3bowsoa37sy")
                    .guardrailVersion("DRAFT")
                    .build());

            // Decode the response body.
            JSONObject responseBody = new JSONObject(invokeModelResponse.body().asUtf8String());

            // 응답값을 return
            return responseBody.getJSONArray("content").getJSONObject(0).getString("text");
        } catch (SdkClientException e) {
            log.error(e.toString(), e);
            throw new RuntimeException(e);
        }

    }
}

이제는 의도한 대화만 하도록 필터링이 가능하다..!

참고한 자료

Java 2.x용 SDK를 사용하는 Amazon Bedrock 런타임 예제 - AWS SDK for Java 2.x

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

Use the Converse API - Amazon Bedrock

Use the Converse API You can use the Amazon Bedrock Converse API to create conversational applications that send and receive messages to and from an Amazon Bedrock model. For example, you can create a chat bot that maintains a conversation over many turns

docs.aws.amazon.com

ConverseRequest (AWS SDK for Java - 1.12.744)

Inference parameters to pass to the model. Converse supports a base set of inference parameters. If you need to pass additional parameters that the model supports, use the additionalModelRequestFields request field.

docs.aws.amazon.com

AWS SNS과 FCM 그리고 Spring Boot를 곁들인..

dev.Dove — Wed, 8 May 2024 23:45:08 +0900

시작하기 앞서

본 글은 2024년 4월 말~ 5월 1주 차에 작성했습니다.

Spring boot 2, Java 17과 AWS SDK v2를 사용했습니다.

언제 이런 기능이 생긴거지..?

..??????

회사에서 AWS SNS를 이용해 Slack메시지 전송을 구현하려다 우연히 모바일 푸시를 발견했다.

새 기능 알럿을 보니, FCM 사용이 가능하다는데, 기존 FCM만 사용하는 것과 차이가 궁금하다.

퇴근하고 조금씩 조사한 내용을 정리해 보자

AWS SNS 모바일 푸시

모바일 푸시 알림 - Amazon Simple Notification Service

docs.aws.amazon.com

공식 문서를 보니, 푸시 메시지 플랫폼을 AWS SNS로 연결해서 AWS 인프라로 Push 알림을 전송할 수 있는 것 같다.

구현해보자

0. Firebase에서 FCM을 전송할 프로젝트를 먼저 구성해야 한다.

프로젝트 생성 후 설정, "서비스 계정"에서 "새 비공개 키 생성"을 통해 json키를 먼저 받는다.

1. AWS SNS에서 "푸시 알림"을 선택하고 "플랫폼 어플리 케이션 생성"을 선택한다.

2. 푸시 알림 플랫폼을 "FCM"으로 선택하고 자격증명은 "토큰"으로 한 뒤 Firebase에서 미리 받은 json키를 업로드한다.

3. Spring Boot에서 사용하기 위해 AWS SDK v2를 gradle에 추가한다.

    implementation "software.amazon.awssdk:lambda:2.20.122"

4. FCM에서 발급받은 토큰을 AWS SNS에 엔드포인트로 만들고 전송한다.

CreatePlatformEndpointResponse platformEndpoint = snsClient.createPlatformEndpoint(CreatePlatformEndpointRequest.builder()
            .platformApplicationArn("{aws sns 콘솔에서 확인 가능한 arn 값}")
            .token(token)
            .build());


Notification notification = new Notification("제목", "내용");
PublishResponse publishResponse = snsClient.publish(
	PublishRequest.builder()
        .targetArn(platformEndpoint.endpointArn())
        .message(notification.toJson())
        .build()
);

AWS SNS를 사용할 이유가 있는가..?

결국 FCM를 AWS SNS로 감싸서 사용하는 형태니, 다음과 같은 특징을 가지고 있다.

1. AWS 인프라와 연계성이 좋다. (장점)

>> spring boot가 아닌 AWS Lambda로 서버리스 환경을 구성하면, 고가용성에 대한 고민이 사라진다.

>> Cloud Watch 연동이 가능하다.

2. AWS 내 인프라 사용에 제약을 인지하고 사용해야 한다.

>> push를 topic기반으로 전송할 경우 AWS는 구독자의 수를 제한하고 FCM은 최대 구독수를 제한다.

>> 이건 프로젝트의 성격에 따라 FCM도 AWS 도 둘 다 좋은 선택지가 될 수 있다.

https://docs.aws.amazon.com/ko_kr/general/latest/gr/sns.html

https://firebase.google.com/docs/cloud-messaging/android/topic-messaging?hl=ko

3. 비용

>> FCM은 무료다. AWS SNS는 백만건당. $0.5를 청구한다.(한국 리전 기준)

https://aws.amazon.com/ko/sns/pricing/

정리

AWS SNS는 기존 AWS 인프라를 사용하길 원하며, 다양한 주제(몇 만개)를 만들어서 앱을 일괄로 묶어서 푸시 전송할 경우에는 사용할 가치가 있어 보인다. 다만, 프로젝트의 규모가 작으면(구독할 주제가 적을 경우) 굳이 부가적은 AWS SNS 비용을 지불하며 사용할 필요는 없어 보인다.

참고한 사이트

SDK for Java 2.x를 사용하는 Amazon SNS 예제 - AWS SDK for Java 2.x

docs.aws.amazon.com

SubscribeRequest (AWS SDK for Java - 2.25.47)

Sets whether the response from the Subscribe request includes the subscription ARN, even if the subscription is not yet confirmed. If you set this parameter to true, the response includes the ARN in all cases, even if the subscription is not yet confirmed.

sdk.amazonaws.com

JPA IdentifierGenerator의 connection에 대해..

dev.Dove — Mon, 4 Sep 2023 20:24:39 +0900

본 글은 Spring Boot 2.7.13(Java 17), Hibernate 5.6.15 기준으로 작성됨

JPA에서 ID를 커스텀하게 만들 때 IdentifierGenerator, Configurable를 implements 받아서 ID생성기를 구현한다.

구글링을 하다보면, session.connection();이나 session.getJdbcConnectionAccess().obtainConnection();를 사용해서 DB connection을 가져온다.

session.connection()과 session.getJdbcConnectionAccess().obtainConnection()는 뭔 차이일까?

1단계 일단, 둘 다 디버깅 걸어보자

session.connection()

application.yml로 설정한 hikari-pool이 보인다.

session.getJdbcConnectionAccess().obtainConnection()

어..? hikaripool의 클래스 주소까지 같네..??

2단계, 문서와 코드를 까보자

session.connection()

출처: https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/engine/spi/SharedSessionContractImplementor.java

하이버네이트가 관리하는 JDBC 커넥션

session.getJdbcConnectionAccess().obtainConnection()

getJdbcConnectionAccess에 해당하는 JdbcConnectionAccess 인터페이스에 보면,

/**
 * Provides centralized access to JDBC connections.  Centralized to hide the complexity of accounting for contextual
 * (multi-tenant) versus non-contextual access.
 *
 * @author Steve Ebersole
 */
public interface JdbcConnectionAccess extends Serializable {

파파고를 통하면,

중앙 접근이 가능한 JDBC

어떤 걸 써야 하지...??

datasource를 빈으로 등록해서 스프링 서버를 구동하면, 둘 다 문제없는 소스다.

하지만, hibernate가 관리하는 JDBC보단 중앙 접근 가능한 방식이 조금 더 좋은 코드로 보인다.

추가로, Jboss 사이트의 hibernate문서를 보면, connection()은 4.x버전부터 제거예정이라고 명시했다.

제거될 함수보다는 session.getJdbcConnectionAccess().obtainConnection()를 쓰는 것이 좋을듯하다.

https://docs.jboss.org/hibernate/core/3.5/api/org/hibernate/Session.html#connection()

여담...

아니.. hibernate 5.x버전 쓰는데, @Deprecated 어노테이션 없던데..;;;

단일 책임 원칙과 클린코드 V2

dev.Dove — Wed, 9 Aug 2023 19:37:55 +0900

해당 게시글은 과거 개인 블로그에 작성한 내용을 옮긴 내용입니다.
https://tech.dpot.xyz/post/52

알죠..? 알면서.. (출처:https://www.huffingtonpost.kr/entry/solid_kr_5a9df0e2e4b0479c02564332)

개발하며 다른 개발자와 협업하는 상황이 많이 온다. 서비스의 기획, 설계를 함께하면 상관없어도, 프로젝트 중간에 개발자가 참여하면 서비스의 전반적 이해를 위해 적지 않은 시간이 필요하다.

이러한 상황에서 SOLID의 S인 단일 책임 원칙에 준수하여 작성한 소스는 빛난다. 실무에서 개발하며, 느낀 단일책임원칙을 준수하기 위한 간단한 규칙을 정리해 보려 한다.

1. Setter 금지

생각해 보면 Lombok 찬양론을 말하던 개발자였다. @Data하나면 모든 것을 만들어주던 라이브러리의 문제는 생각하지도 않고 사용했던 것부터 클린코드와 이별한 듯하다.

JPA와 lombok을 같이 사용할 경우 영속성이 유지된 엔티티에서 update쿼리를 위해 set을 무차별적으로 사용하거나 insert를 위해 서비스단에서 여러 번의 setter을 사용한다.

예시1) 책을 빌리면 빌렸다고 상태를 바꿔야 해요

public void rent01() {
    BookRent bookRent = new BookRent();
    bookRent.setRentDateTime(LocalDateTime.now());
    bookRent.setIsRent(true);
}

예시2)책임은 클래스가 서비스는 호출만

public void rent02() {
    BookRent bookRent = new BookRent();
    bookRent.rent();
}
public class BookRent {
    @Id
    private Long id;

    @Column
    private LocalDateTime rentDateTime;

    @Column
    private Boolean isRent;

    public BookRent rent(){
        this.rentDateTime = LocalDateTime.now();
        this.isRent = true;

        return this;
    }
}

위 2개의 소스를 보면 더욱 이해가 쉽다. 예시 1번의 경우 새로 프로젝트에 참여한 개발자에게 책을 대여할 때 시간과 상태를 바꿔야 한다고 말해야 한다. 하지만, 예시 2번을 보면 책을 대여하는 메소드를 알려주면 끝난다.

당연히, 값의 오류는 방지되고 수정이 필요한 값만 설정할 수 있다. 조금 생각해보면, id 칼럼 역시 jpa가 persist될때 자동으로 세팅 되며, 개발자는 수정할 일이 없다. 하지만, @Setter는 잘못 사용하면 id도 변경 가능한 것처럼 보여주기에 자칫 원치 않는 상황을 만들 수 있다.

2. DTO에서는 다양한 생성자 사용

DTO세팅의 책임도 DTO가 가져가도록.

public class BookInfoDto {
    private String bookName;

    private LocalDateTime createdAt;

    private Boolean rentAble = false;

    public BookInfoDto(Book book) {
        this.bookName = book.getBookName();
        this.createdAt = book.getCreatedAt();

        List<BookRent> bookRentList = book.getBookRentList();
        if(!bookRentList.isEmpty()){
            this.rentAble = true;
        }
    }

}

서비스단에서 DTO를 만들고 값을 넣을 때도 set보다 생성자를 쓰길 권장한다. 또한, 다양한 객체를 받는 생성자를 만들어서 어떠한 값을 받아도 DTO안에서 모든 변환 로직을 관리 할 수 있다.

이 방법을 통해 혹시라도 여러 서비스에서 DTO를 사용할 수 있으며, DTO의 값이 옳바르지 않음을 보장한다.

3. validation을 통한 올바른 값만 받기

Validation은 생각보다 강력합니다.

@JsonProperty('repeatDay')
@Pattern(regexp = '[1-7](\\|[1-7]{1}){0,6}')
@Schema(description = '반복 요일. 1~7: 월~일', example = '1|2|3|4|5|6|7')
private String repeatDayStr;//반복 요일

@JsonProperty('startDate')
@DateTimeFormat(pattern = 'yyyy-MM-dd')
@Schema(description = '시작 일자', example = 'YYYY-MM-DD')
private LocalDate startDate;//시작 일자

종종 client가 이상한 값을 보낼 때가 존재한다. 이상한 값의 정의는 다음과 같다. 날짜를 받아야 하는데 이상한 형식으로 주기도 하고 새로운 client 개발자는 Long 타입의 id 대신 string 0을 주는 일도 있다. 물론, 서비스단에서 이러한 값이 틀렸음을 예외 처리하면 된다. 하지만 서비스에서는 서비스 로직의 문제만 예외 처리해야 한다고 생각하기에 틀린 값이 아닌 이상한 값은 아예 안 받는 것을 고려해 볼 수 있다.

더욱이, Validation은 다양한 어노테이션을 지원한다. 가볍게는 숫자 타입의 변수 확인부터 필자가 많이 사용하는 @Pattern까지 어지간한 값은 모두 검사할 수 있다. Validation을 통해 컨트롤러단에 들어온 요청의 값은 틀릴 수 있어도, 이상할 수 없음이 보장되었다.

Spring Boot로 개발하며 의존성 역전은 autowired로, 인터페이스 분리 원칙은 Repository를 만들며, OCP와 LSP는 엔티티에서 공통 컬럼을 분리하면 자연스럽게 적용하게 된다. 하지만 SRP (단일 책임 원칙)은 자연스럽게 되는 것이 아닌 신경을 써야 준수하게 되는 원칙인 것 같다.

물론, 서비스단에서 보기에 너무 소스가 흩뿌려진다고 할 수 있지만, 유지보수를 하거나 기획이 변경되었을 때 변경된 객체만 건드리면 되니 단일 책임 원칙을 준수하며 코딩하는 습관을 기르는 것이 좋다.

Linode Objects Storage 구성 및 Spring Cloud aws와 연동

dev.Dove — Wed, 12 Jul 2023 00:14:01 +0900

출처: https://www.linode.com/products/object-storage/

Akamai사에서 Linode를 인수하며, Akamai에서 AWS S3와 같은 Object Storage를 서비스하고 있다.

Naver Cloud도 S3와 호환되는 저장소를 제공하고 Linode도 S3와 호환되는 Object Storage서비스를 제공한다.

S3와 호환되는 저장소라면, AWS SDK로 연결이 가능할 터, 연결해 보자..

1. Linode Object 만들어보자

1. AWS, GCP, NCP 모두 비슷한 구조를 가진 듯하다. Linode도 버킷이라는 명칭을 사용하며 생성할 수 있는 버튼이 존재하니 누르자.

2. 버킷의 명칭을 label에 적고, 리전을 골라주면 된다. 2023년 7월 기준 4개 중에서 선택가능하다.

3. 버킷을 만드려 하니, 안내문구가 나온다. 요금에 대한 설명이다. aws s3와는 다르게 1TB까지 네트워크비용이 기본요금에 포함되어 있다.

4. 버킷에 접글할 때 필요한 액세스키와 시크릿 키를 만들자.

5. Create Access Key를 누르면 key를 만들어서 보여준다. 따로 잘 저장해 두자.

2. Spring Cloud AWS와 연결

Spring Cloud for Amazon Web Services

spring.io

먼저, 본 글에서 사용하는 spring cloud aws는 amazon sdk를 이용해 spring 환경에서 편하게 사용할 수 있게 도와주는 프로젝트다. AWS의 crendential을 yml설정을 통해 자동으로 bean설정을 도와준다.

단, 해당 프로젝트는 community-run project라고 spring 공식홈페이지에서 공지한다. 3 버전부터는 aws 내 일부 서비스만 사용가능한 점이 아쉬운 점으로 꼽힌다.

aws sdk로 linode obect storage연결은 너무 쉽다. s3연결 생성 시, endpoint만 linode로 변경하면 끝나니, 본글에서는 spring cloud aws기반으로 연결해보려 한다.

추가로 본문에서의 예시는 spring boot 2.7.12(java 17), gradle 7.6.1을 기반으로 한 코드임을 알린다.

1. spring cloud aws를 추가한다.

implementation 'org.springframework.cloud:spring-cloud-starter-aws:2.2.6.RELEASE'

2. application.yml을 세팅한다.

- 예제는 EC2가 아닌 환경에서 구동할 예정임으로 cloud.aws.stack.auto는 false처리하여 자동으로 spring cloud aws 가 AWS CloudFormation를 세팅하는 것을 막는다.

- cloud.aws.region.static은 없을 경우 spring cloud aws가 에러를 유발하기에 linode에서 사용할 기본 리전으로 세팅한다.

cloud:
  aws:
    stack:
      auto: false
    region:
      static: {리전코드}
  linode:
    bucket: {버킷명}
    region: {리전코드}
    credential:
      accessKey: {accessKey}
      secretKey: {secretKey}

3. yml에 추가한 설정값을 Java class에 바인딩한다.

@Getter
@Setter
@Component
@ConfigurationProperties(prefix = "cloud.linode")
public class LinodeProperties {
    private String bucket;
    private String region;
    private Credentials credentials;
}

public record Credentials(
        String accessKey,
        String secretKey
) {
}

4. 바인딩 한 설정값으로 AmazonS3 Bean을 재 정의한다.

@Configuration
@RequiredArgsConstructor
public class LinodeConfig {
    private final LinodeProperties linodeProperties;

    @Bean
    public AmazonS3 amazonS3() {
        AWSCredentials credentials = new BasicAWSCredentials(
                linodeProperties.getCredentials().accessKey(),
                linodeProperties.getCredentials().secretKey()
        );

        return AmazonS3ClientBuilder.standard()
                .withEndpointConfiguration(new AwsClientBuilder.EndpointConfiguration("https://ap-south-1.linodeobjects.com", linodeProperties.getRegion()))
                .withCredentials(new AWSStaticCredentialsProvider(credentials))
                .build();
    }
}

5. 원하는 곳에서 AmazonS3을 주입받아서 사용한다.

@Slf4j
@Component
@RequiredArgsConstructor
public class AwsS3 {
    private final AmazonS3 amazonS3;

    /**
     * 단일 파일을 가져온다.
     *
     * @param key
     * @return
     */
    public S3Object getObject(String bucket, String key) {
        return amazonS3.getObject(bucket, key);
    }

}

3. 마치며..

AWS와 호환되는 클라우드 환경이면 AWS SDK로 편하게 사용할 수 있다.

AWS SDK기반으로 개발하면, 어떤 클라우드 환경의 버킷도 대응할 수 있다.

~~AWS SDK가 만능인 건가...~~

MultipartFile 업로드에 관하여

dev.Dove — Tue, 30 May 2023 23:07:25 +0900

어디에서든지 파일을 다루는 시스템을 설계하고 구현할 일이 생긴다.

도메인은 다르고 파일의 형태는 다르지만, 뭔가 항상 다루는 MultipartFile.

한번 구현해 보자.

설계

필요한 기능은 다음과 같다.

단일 파일 업로드
업로드한 전체 파일 조회
업로드한 파일 제거

이번 구현에서 고려하지 않을 기능은 다음과 같다.

DB
다중 파일 업로드
API controller

예제 소스에서는 서버가 실행되는 위치에 업로드한 파일을 저장할 예정이다.

단순 업로드 구현

@Slf4j
@Service
public class FileService {
    @Value("${file.upload-path}")
    private String uploadDirectory;

    public boolean saveFile(MultipartFile multipartFile) {
        //파일이 없으면 별도의 처리를 한다.
        if (multipartFile == null || multipartFile.isEmpty()) {
            return false;
        }

        String fileName = multipartFile.getOriginalFilename();
        File targetFile = new File(uploadDirectory, fileName);
        try{
            FileCopyUtils.copy(multipartFile.getInputStream(), new FileOutputStream(targetFile));

            //저장을 완료하면, multipartFile로 만든 파일은 제거한다.
            targetFile.delete();
        }catch (IOException ioException){
            //파일 저장 실패시 에러 핸들링.
            log.error(ioException.toString(),ioException);
            return false;
        }
        
        return true;

    }
}

MultipartFile를 받아서 파일로 원하는 위치에 저장한다.
파라미터로 받은 MultipartFile를 File객체로 변환하며, 원하는 위치에 실제 파일이 만들어진다.

허나.. 용량이 좀 큰 파일을 업로드하면, FileSizeLimitExceededException 에러를 만난다..

해결해 보자

큰 용량을 업로드해 보자

결론부터 말하면, Spring Boot에 있는 내장 톰캣에서 업로드 용량에 제한을 걸어서 나오는 에러다.

mulipart 설정을 세팅하는 로직

YAML 또는 properties를 통한 mulipart설정이 없다면, connector에서 값을 가져와 세팅한다.

connector를 보니, Spring Boot 2.7.12(Java 17) 기준 2MB다.

그러면, YAML 또는 properties를 통해 업로드 제한을 변경해 보자!

Spring Boot 2.7 기준 설정

application.yml에 설정을 추가하면 보다 큰 용량도 업로드 가능하다.

출처: https://docs.spring.io/spring-boot/docs/2.7.x/api/org/springframework/boot/web/servlet/MultipartConfigFactory.html

공식 문서를 보면 max-file-size는 MultipartFile 1개의 최대 업로드 사이즈, max-request-sizes는 multipart/form-data한 개의 요청의 최대 업로드 사이즈 설정이다.

만일.. 파일이 5GB, 10GB처럼 크면 어떻게 될까..?

MultipartFile이 커지면 힙메모리에 부하가 갈 것이다. 메모리 부족현상은 당연히 발생할 것이다.

분할 업로드 구현

하나의 파일을 분할해서 업로드하면, 서버의 트래픽은 증가하지만, 각 요청의 응답 속도는 빨라진다.

추후 서버를 증설하면 증가된 서버 트래픽도 해결된다.

분할 업로드를 직접 IDC에 업로드하는 방법보다는 AWS S3를 이용해서 간단하게 구현해 보자.

AWS S3에서도 큰 파일을 업로드할 때 파일을 분할해서 업로드할 수 있게 SDK를 제공한다.

AWS S3의 분할 파일 업로드 프로세스는 다음과 같다.

분할 파일을 업로드한다고 S3에게 알려준다.
분할 파일을 업로드한다.
분할 파일을 다 업로드했다고 S3에게 알려준다.

1번 과정에서 S3는 id를 제공한다. id를 이용해서 분할파일을 업로드하고 3번 과정을 통해 S3는 분할 파일을 합쳐서 하나의 온전한 파일로 만든다.

이를 간단하게 구현하면 다음과 같다.

@Service
@RequiredArgsConstructor
public class ChunkedFileService {
    private final AmazonS3Client amazonS3Client;

    public InitiateMultipartUploadResult initiateUploadChunkedFile() {
        //S3 분할 파일 업로드 init
        InitiateMultipartUploadResult initiateMultipartUploadResult = amazonS3Client.initiateMultipartUpload(
                new InitiateMultipartUploadRequest("버킷 명", "업로드 위치"));

        //필요할 경우 DB에 분할 파일 업로드 정보 저장.

        return initiateMultipartUploadResult;
    }


    /**
     * 분할 파일을 업로드한다.
     *
     */
    public UploadPartResult uploadChunkedFile(String uploadId, Integer chunkSeq, MultipartFile multipartFile) throws IOException {
        ObjectMetadata objectMetadata = new ObjectMetadata();
        objectMetadata.setContentType(multipartFile.getContentType());
        objectMetadata.setContentLength(multipartFile.getSize());

        UploadPartRequest uploadPartRequest = new UploadPartRequest()
                .withBucketName("버킷 명")
                .withKey("업로드 위치")
                .withUploadId(uploadId)//initiateMultipartUpload를 통해 받은 id
                .withPartNumber(chunkSeq) // 순차적인 part number (1~10,000)
                .withInputStream(multipartFile.getInputStream())
                .withObjectMetadata(objectMetadata)
                .withPartSize(multipartFile.getSize()); // chunk file size

        return amazonS3Client.uploadPart(uploadPartRequest);
    }

    /**
     * 업로드 한 분할 파일을 하나의 파일로 합친다.
     */
    public CompleteMultipartUploadResult mergeChunkedFile(String uploadId, List<PartETag> eTagList) {
        CompleteMultipartUploadRequest completeRequest = new CompleteMultipartUploadRequest(
                "버킷 명",
                "업로드 위치",
                uploadId,
                eTagList);//분할 파일을 업로드 하는 과정에서 받은 eTag들의 list

        return amazonS3Client.completeMultipartUpload(completeRequest);
    }
}

마무리

대용량의 파일을 업로드할 때, S3를 이용하면, upload id, etag 등 다양한 값을 사용하게 된다.

클라이언트에게 upload id, etag 등 필요한 값을 주는 방법도 있고 원한다면 서버가 DB에 upload id, etag를 저장하고 관리하는 방법도 고려할 수 있다.