출근하느라 바쁜 쭈니어

AWS ) LocalStack 을 활용한 AWS 환경 구축

짱쭈니어 — Sun, 4 Jan 2026 18:52:44 +0900

AWS LocalStack 이란

AWS 클라우드 환경을 로컬에서 흉내 낼 수 있게 해주는 오픈소스 플랫폼
즉 AWS 에서 제공하는 서비스들을 AWS 계정 없이, 인터넷없이, 비용없이 로컬에서 사용가능하다.
- S3
- SQS
- SNS
- DynamoDB
- Lambda
- API Gateway
- CloudWatch Logs
aws CLI 와 100프로 동일하게 동작하는 awslocal 명령어도 포함되어있다.
장점
- 비용절감 : 실제 aws 를 사용하는게 아니기에, 무료로 사용이 가능하다.
- 보안측면 : aws 실제 자격증명 (access keyd, secret key) 을 사용하지 않아서 테스트 중에 실수로 키 노출될 위험이 줄어든다.
동작방식 ️
- Docker 위에서 AWS API 와 동일한 형태의 Mock 서버를 띄운다.
- 예 ) 로컬에서 S3 요청을 보내면 실제 AWS 가 아닌 내가 띄어놓은 LocalStack의 S3 모듈이 응답한다

로컬환경 - LocalStack 실행

공식 이미지 사용

docker run --rm -it \
  -p 4566:4566 \
  -p 4571:4571 \
  localstack/localstack

2.직접 docker-compose.yml 생성 & 작성

프로젝트 폴더 생성 mkdir localstack-test
docker-compose.yml 생성 & 작성
docker-compose up -d 실행

version: "3.8" // 위 파일은 compose 스펙 3.8 기준 

services:
  localstack:  // localstack 컨테이너 정의 
    container_name: "localstack" // 컨테이너 이름 
    image: localstack/localstack:0.14.3 //사용할 도커 이미지
    ports:
      - "4566:4566" //s3, sqs 이든 4566  하나 포트 사용 
    environment: //환경변수 설정 시작
    //localstack에서 사용할 aws서비스
      - SERVICES=sns,sqs,s3,dynamodb,ssm,secretsmanager 
      - DEBUG=${DEBUG-} //디버그 설정 여부 
      - DATA_DIR=${DATA_DIR-} // 데이터 영속적으로 저장할 디렉터리 지정용
      - HOST_TMP_FOLDER=${TMPDIR:-/tmp/}localstack
      - DOCKER_HOST=unix:///var/run/docker.sock
      - AWS_ACCESS_KEY_ID=test
      - AWS_SECRET_ACCESS_KEY=test
      - AWS_DEFAULT_REGION=us-east-1
    volumes:
      - "${TMPDIR:-/tmp}/localstack:/tmp/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"

구분	설명
${VAR-}	VAR이 설정되어 있으면 그 값, 없으면 빈 문자열이라는 쉘 문법
- SERVICES=sns,sqs,s3,dynamodb,ssm,secretsmanager	여섯 가지를 Localstack 에서 활성화하겠다. (mock 으로 띄우겠다)
DATA_DIR=${DATA_DIR-}	컨테이너를 재시작하여도 리소스(S3 버킷/테이블) 유지할 수 있다 .
HOST_TMP_FOLDER=${TMPDIR:-/tmp/}localstack	호스트의 임시 폴더 위치를 LocalStack에게 알려주는 설정 /tmp/localstack 또는<TMPDIR>/localstack Localstack 이 내부에서 임시파일/마운트용으로 참고하는 값
DOCKER_HOST=unix:///var/run/docker.sock	LocalStack이 호스트의 Docker 데몬에 접근할 수 있게 하는 설정. - Localstack 이 내부에서 또 다른 컨테이너를 띄우거나, 도커 기능을 사용할 수 있는데 그 때 호스트의 도커 소캣으로 연결하기 위함 - 도커 소캣을 열어주는건 호스트 제어 권한을 넘겨주는 수준이여서 보안적으로 위험하지만, 로컬개발용으론 자주 쓰이는 패턴 그래도, 컨테이너가 호스트 Docker를 마음대로 만질 수 있다”는 건 인지하자
- AWS_ACCESS_KEY_ID=test - AWS_SECRET_ACCESS_KEY=test - AWS_DEFAULT_REGION=us-east-1	AWS가 아니라 LocalStack이기 때문에 아무 문자열이나 써도 완전 상관 없음 (test, dummy 등)
volumes: - "${TMPDIR:-/tmp}/localstack:/tmp/localstack" - "/var/run/docker.sock:/var/run/docker.sock"	1. 첫번째 라인 내 컴퓨터 /tmp/localstack 폴더에 localstack /tmp/localstack 데이터저장 2. 두번째 라인 LocalStack 컨테이너가호스트의 Docker를 조작할 수 있게 만드는 것. (실제 서버 환경에서 사용하지 말것!!)

LocalStack 내부 구성

[LocalStack 컨테이너 1개]
├─ LocalStack 메인 프로세스
├─ 모듈: S3 에뮬레이터
├─ 모듈: SQS 에뮬레이터
├─ 모듈: SNS 에뮬레이터
└─ 모듈: DynamoDB 에뮬레이터

단일 컨테이너 안에서 여러 AWS 기능을 모듈로 실행 (안에서 실행)
LocalStack 이 Docker 에 접근하는 이유는?
- 특정 서비스 ( 특히 Lambda : 클라우드 서비스) 실행시에 나의 도커를 활용하여서 추가 컨테이너를 자동으로 실행할 수 있다.
- 위의 케이스로 인해 LocalStack 에게 나의 “도커 조작 권한” 을 준다.

Spring Cloud - Gateway 에 대해 알아보자

짱쭈니어 — Sun, 4 Jan 2026 18:41:25 +0900

MSA 환경에서 ClientA 는 A 서버로, ClientB 는 B서버로 동적라우팅 이 필요하다
Spring Cloud Gateway 를 통해 동적라우팅을 구현할 수 있다

Spring MVC vs Spring WebFlux

Spring MVC : 전통적인 동기(블로킹) 웹 프레임워크
SpringWebFlux : 비동기(논블로킹) 리액티브 웹 프레임워크
- 리액티브 : 요청을 보내고 결과를 기다리지 않은 채 다음일을 먼저 처리

구분	Spring MVC	Spring WebFlux
처리방식	동기(Blocking)	비동기(Non-blocking)
대표의존성	spring-boot-starter-web	spring-boot-starter-webflux
HTTP server	기본 : 톰캣	기본 : Netty
변수 주요 타입	String, List	Mono, Flux
요청 처리방법	요청마다 쓰레드 할당 하나의 요청이 들어왔을 때 스레드 하나가 끝날때까지 처리하는 방식 요청이 끝날때까지 스레드를 점유 (DB 조회할때 스레드 하나가 계속 기다리는)	쓰레드를 재활용
성능	단순요청에 빠름	고동시성 상황에 강함 실시간처리, 대규모 요청 처리(채팅)

원래 자바는 동기 /블로킹 언어

// 예: 데이터를 가져올때까지 기다림 -> 동기/블로킹 언어
String result = userRepository.findById(id);

리액티브 프로그래밍

요청이 들어오면 작업시켜놓고, 기다리지 않고 다음일을 먼저 처리 ( 비동기 논블로킹방식)
API 들의 동시처리(동시성) 원할 때
데이터의 흐름(스트림) 와 변화(이벤트) 반응하는 방식
- 결과가 준비되면 이벤트로 반응하여 처리한다.

Mono vs Flux - WebFlux 사용하는 변수타입

Mono : 0 개 또는 1개의 데이터를 비동기로 처리

Flux : 0 개 이상의 데이터 (스트림)을 비동기로 처리

사용환경 Mono/Flux 사용여부

사용환경	Mono/Flux 사용여부
일반 java 프로젝트	❌
spring mvc	❌
spring webflux	✅ 기본으로 사용 논블로킹

전통적인 Java 스타일 (명령형 코드)

for(String s : strList){
	System.out.println(s);
}

리액티브 스트림 기반(함수형 스타일)

list.stream()
	.filter(s -> !s.equals("b"))
	.forEach(System.out::println); // ***spring mvc 에서도 리액티브 스타일로 작성 가능***

Spring WebFlux vs Spring Cloud Gateway

Spring WebFlux : 비동기/논블로킹 리액티브 웹 프레임워크
Spring Cloud Gateway : WebFlux 위에 만든 API Gateway 서버, 라우팅과 필터링에 특화됨
- 필터를 수행하고 라우팅하여 다른 서버에 전달 ( = 프록시 역할을 수행)
- 자체 컨트롤러가 거의 없음
- cloud Gateway 는 webflux 환경에서만 유효
API Gateway 서버 : 클라이언트의 API 요청을 받아 1개 이상의 백엔드 서비스로 전달하고 응답을 취합해 클라이언트에 반환하는 중개자 역할의 서버 (길 안내 역할)
- 트래픽 관리, 인증, 로깅, 모니터링같은 보안 및 관리 기능을 단일 진입점에서 처리할 수 있음
- MSA환경에서 백엔드 서비스들의 복잡성을 관리하고 확장성을 높임
-참고 네트워크 프록시 : 클라이언트와 실제 서버 사이에 위치하여 클라이언트 요청을 대신 서버에 전달, 서버 응답을 받아 다시 클라이언트에게 전달하는 중간자 역할을 수행
Spring Cloud Gateway Proxy : 네트워크 프록시와 동일한 역할 수행

Spring Cloud Gateway 흐름

클라이언트 → 요청 도착
GlobalFilter 실행 ( 공통필터 실행 )
동적라우팅 → client A 는 A서버, B는 B 서버 Target 되는곳으로 라우팅 ( gateway 를 통해 들어왔다면, 나가는것도 gateway 를 통해야한다)
Gateway가 백엔드서비스로 응답받음 (client A 는 A서버, B는 B 서버)
응답 받은 후에 필터처리 ( 적용할 수도 있고, 안해도 되고 ex : 응답 로깅 , 응답 헤더 조작 등등)
클라이언트에게 응답 반환

GlobalFilter 실행하는 방법

전역필터를 설정하는 방법은 크게 2가지가 있다.

Spring Cloud Gateway - default-filters 설정

 // application.yml 설정
  cloud:
    gateway:
      default-filters:
        - name: DetailedRequestResponseLogFilter

gateway 에서 공통필터 default-filters 모든 route 공통적
- 별도 적용하지 않아도 자동적용

Spring Cloud Gateway - GlobalFilter로도 전역필터로도 가능

@Component
public class CustomGlobalFilter implements GlobalFilter, Ordered {
	
}

GlobalFilter 로도 모든 라우터에 필터 자동적용 가능
default-filter , GlobalFilter 둘 다 함께 동시에 사용 가능하다.
- 기준이 조금 다르긴함
- default-filter : 모든 route 정의에 공통적 적용필터
- GlobalFilter: 모든 요청에 실행되는 전역필터

등록된 GlobalFilter 들이 순서대로 실행된다. 순서를 적용하는 방법은 2가지 :

애노테이션 사용 @Order(-1) (우선순위 낮을수록 먼저 실행)
Ordered 인터페이스 구현

/**
* 아래 메서드형태로 필터 메서드 구성 
* ServerWebExchange: 요청과응답을 캡슐화한 객체,불변(immutable)객체처럼 설계(변경불가)
* 필터를 요청에 적용할 수도 있고, 응답을 해주기전에도 필터적용이 가능하다 
* GatewayFilterChain = 여러 필터들을 차례대로 실행시키는 “줄 담당자”
*/
Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
	...
		chain.filter(exchange);
}

// 1. Order 애노테이션 적용**
@Component
@Order(-1) // 낮을수록 우선순위 높음
public class AuthGlobalFilter implements GlobalFilter {

	@Override
	 Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
		
      // 예: 헤더 검사
      String auth = exchange.getRequest()
						      .getHeaders()
						      .getFirst("Authorization");

      if (auth == null) {
          exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
          return exchange.getResponse().setComplete();
      }

      // 다음 필터로 넘어감 (chain 너 다음으로 넘어가 exchange 가지고) 
      return chain.filter(exchange);
	}
}

//-----------------------------------------------//

// 2. Ordered 인터페이스 구현
@Component
public class AuthGlobalFilter implements GlobalFilter,Ordered {

	@Override
	 Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
						...
		chain.filter(exchange);
	}
	
	@Override
	public int getOrder() {
	    return Integer.MIN_VALUE; // return 0; 이렇게도 가능, 낮을수록 우선순위 높음 
	}
}

2-2. chain.filter(exchange) 호출

각 GlobalFilter 는 자신이 작업을 마친 뒤에, 반드시 chain.filter(exchange) 를 호출해야한다. 위 호출을 통해 다음필터 또는 라우터/컨트롤러로 요청이 넘어갈 수 있다.

chain.filter(exchange) 호출하면 Spring 내부 필터체인이 다음이 어디인지 이미 알고있어서, 다음경로를 명시하지 않아도 알아서 다음으로 이동한다 → 관리하는 곳 : GatewayFilterChain (필터순서관리자)

3. 동적 라우팅

RouteLocatorBuilder : Spring Cloud Gateway 에서 라우팅 규칙을 자바코드로 정의할 때 사용하는 빌더 클래스

@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()  // 이제 여러개 routes 등록할거야
        .route("dysignic_route", r -> r
            .path("/dynamic/**")  // 1. 이 endpoint 로 요청이 왔을 때, 
            .filters(f -> f.stripPrefix(1)) //3. 추가필터적용( 접두사(앞)부분을 잘라내)
            .uri("<http://localhost:8081>")) // 2. 여기로 라우팅하되 
         .route("user_route", r -> r
            .path("/user/**")
            .filters(f -> f.stripPrefix(1))
            .uri("<http://localhost:8082>"))
        .build();
}

client 가 /dynamic/** 로 요청을 보냈을 때 http://localhost:8081로 요청을 전달(proxy) 하되, prefix /dynamic 을 잘라낸 상태로 보냄

구분	설명
RouteLocator	Spring Cloud Gateway 가 사용하는 라우팅 객체
builder.routes()	여러 개의 라우트를 구성하기 위한 시작점 ( 여러개 route 등록할거야!)
.route("dynamic_route", r -> r	하나의 라우트를 정의
”dynamic_route” 는 이 라우트의 고유한 ID ( 로그, 모니터링, 에러 메시지에서 사용가능)
.path("/dynamic/**")	요청경로가 “/dynamic/**” 이라면 해당 라우트를 사용하겠단 뜻 (이런 endpoint 로 들어오면)
.filters(f -> f.stripPrefix(1))	filter : 라우팅 전/후로 요청/응답을 조작하는 역할을 수행
.filters : 이 라우트에 적용할 필터를 설정
stripPrefix(1): 경로의 앞에서 1개의 경로 조각제거
(ex: /dynamic/hello → /hello)
.uri("http://localhost:8081"))	실제로 요청을 보낼 백엔드 서버
위의 조건에 맞는 요청이 오면 이 주소로 프록시(전달) 된다.
.build()	위에서 정의한 모든 라우트를 최종적으로 빌드해서 RouteLocator 객체로 반환

//Example code 

// 환경설정값 주입 - @Value 애노테이션 이용하여 프로퍼티 주입 
@Value("${api.url.member}")
private String memberServiceUrl;

@Value("${api.url.cusmer}")
	private String cusmerServiceUrl;

@Bean
	public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
		return builder.routes()
				.route("order", r -> r //id
						.path("/order/**") // 요청된 경로
						.and()
						 //Body있는경우 -> 이렇게 조건을 추가해도 된다.
						.readBody(String.class, i -> !StringUtils.isEmpty(i))
						// 필터 없을 수도 있다
						.uri("<https://cookie.service.order.com>")
				)
				// Body가 없는 경우 (get요청)
				.route("member", r -> r
					//.path("/member/**", "/sign/**", "/info/**") // 가변인자(여러개)는 불가
						.path("/member/**")
						.or()
						.path("/sign/**")
						.or()
						.path("/info/**")
						// 또는 .path("/{segment:member|sign|info}/**") 정규식 사용 
							.and()
							.uri(memberServiceUrl)) //환경설정값 주입 
				.route("cusmer server", r -> r
						.path("/cusmer/**")
						.and()
						.readBody(String.class, i -> !StringUtils.isEmpty(i))
						.filters(f -> f.rewritePath("/v2/cusmer"))
						.uri(cusmerServiceUrl))
						}

f.rewritePath("/v2/cusmer"))

RewritePath 적용한다면 요청 URL의 Path 부분을 다른 Path로 치환하는 기능이다. 도메인(uri)은 변경하지 않으며, 변경된 Path는 uri와 합쳐져 최종 호출 주소가 된다.

사용자가 https://jun.supermarket.com/cusmer/check 요청
rewrite 만나서 뒤에 path 가 v2/cusmer/check 로 변경
도메인까지 적용하면 https://jun.service.cusmer.com/v2/cusmer/check

라우팅을 적용하는 파일은? (라우팅 관련 코드 작성하는 위치)
- 별도의 @Configuration 클래스로 분리 - 정석적인 방법

// 별도의 @Configuration 클래스
@Configuration
public class GatewayRouteConfig {

    @Bean
    public RouteLocator routeLocator(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("user-service", r -> r
                .path("/user/**")
                .uri("<https://user.jun.com>"))
            .build();
    }
}

4.Gateway가 백엔드서비스로 응답받음 (client A 는 A서버, B는 B 서버)
5. 응답 받은 후에 필터처리 ( 적용할 수도 있고, 안해도 되고 ex : 응답 로깅 , 응답 헤더 조작 등등)

post (응답 후) 필터 : .then(Mono.fromRunnable(() -> {} 으로 적용! (응답 받은 후 실행하라)

 @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        long start = System.currentTimeMillis(); // 시작할 때 시간

        // pre (요청 전)
        return chain.filter(exchange)
            // post (응답 후)
            .then(Mono.fromRunnable(() -> {  //응답받은 후 실행해라
                long time = System.currentTimeMillis() - start;
                var res = exchange.getResponse();
                var req = exchange.getRequest();

                // 이 값을 로그로 만들어 로그추적에 용이하게 만들수도 있음!
                System.out.printf("[POST] %s %s -> %s (%dms)%n",
                        req.getMethod(), req.getURI().getPath(), status, time);

                // 예: 응답 헤더 추가
                res.getHeaders().add("X-Gateway-Processed", "true");
                res.getHeaders().add("X-Response-Time-Ms", String.valueOf(took));
            }));
    }

특정 라우트에서만 응답필터 적용도 가능

.route("customer", r -> r
    .path("/cusmer/**")
    .filters(f -> f.filter((exchange, chain) ->
        // pre filter
        chain.filter(exchange) // 다음필터로 넘겨라(없다면 라우팅)
            // post filter
            .then(Mono.fromRunnable(() -> {
                exchange.getResponse().getHeaders()
                        .add("X-Customer-Route", "handled");
            }))
    ))
    .uri("<https://jungha.service.cusmer.com>"))

Spring Cloud Gateway 는 MSA 의 입구 역할을 수행한다.
동적라우팅뿐만 아니라 공통필터, Prefilter, Postfilter 사용도 가능하다.
JWT 인증을 수행하기도 하며, 인증되지 않는다면 바로 return 도 가능하다.
기존에 api 가 v1 → v2 로 변경되더라도 해당 api 를 요청하는곳(프론트)을 변경할 필요도 없다.
공통필터에 로그를 남기어서 로그를 ELK 에 보낸다면 로그 도표화도 가능하다. 사용자마다
즉 Spring Cloud Gateway 덕분에 MSA 각 서비스는 비즈니스 로직만 집중하여 수행할 수도 있다.

Spring AOP 가 필요한 경우, 무엇인가, 관련 용어

짱쭈니어 — Tue, 15 Apr 2025 18:30:26 +0900

인프런 스프링 입문 - 김영한 강의를 참고하였습니다.

a. Spring AOP 가 필요한 경우

ex) 모든 메서드의 호출 시간을 측정 ( 인프런 스프링 입문 - 김영한 강의)
ex) 사용자 무슨 액션을 하는지 로그를 쌓는 경우

/**
* 사용자 상품 주문
* - 상황 : 사용자가 몇시에, 어떤 액션을 했는지 알기 위해서 사용자 로그를 쌓아야한다. 
* - 핵심 로직 (상품 주문) + 부가 로직 (로그 쌓기) 
*/

@Transactional
public List<Order> saveOrder(Long goodsId){
	
	log.debug("== 사용자 {} 상품 주문 시작 ==",goodsId);
	
	orderRepository.save(goodsId);
	
	log.debug("== 사용자 {} 상품 주문 저장 완료, 사용자 로그에도 저장 필요 ==",goodsId);
	
	userLogsRepository.save('order',goodsId);  //주문과 관련 없는 부가 로직을 메서드에 작성
	
}

사용자 로그를 쌓아달라는 요청에 따라서, 위의 코드처럼 로직을 짜게 된다면 메서드내에서 핵심 관심 사항(core concern) 과 공통 관심 사항(cross-cutting concern) 이 혼용되게 된다
사용자 로그 로직은 애플리케이션의 공통 관심 사항이다.
핵심 관심 사항의 로직과 공통 관심 사항 로직이 섞이게 되면 유지보수가 어렵다.
- 만약 코드가 복잡하다면, 핵심 관심 사항과 공통 관심 사항 구분하기 어려울 수도 있다.
- 또한 공통 관심 사항 로직이 변경된다면, 작성한 모든 메서드를 찾아가서 수정해야한다.
그래서 이런 경우에 필요한게 AOP ( Aspect Oriented Programming)

b. AOP 는 무엇인가

AOP는Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다
- 모듈화 : 어떤 공통된 로직이나 기능을 하나의 단위로 묶는것로직을 기준으로
  핵심 관점, 공통 부가 관점으로 나누어 즉 관점을 기준으로 모듈화 하겠다.
이렇게 흩어진 관심사들을 핵심 로직에서 분리하여서 재사용 하겠다 ⇒ AOP의 취지
- 흩어진 관심사 (Crosscutting Concers) : 소스 코드상 다른 부분에서 반복해서 사용되는 코드들
주로 로깅, 보안, 트랜잭션과 같은 공통 기능들을 AOP 로 적용함

c. AOP 관련 용어 정리

Aspect : 공통 관심사를 모듈화한 객체, 즉 AOP 를 적용할 객체
- Spring AOP 에서 Aspect 를 구현하는 방식은 2가지
  - 스키마 기반 접근 :xml 기반 설정
  - @AspectJ 스타일 : 애노테이션 기반 설정
    - @AspectJ 방식이 Spring 생태계에서 표준처럼 자리 잡고 있는 상태
Target : 핵심 관심사를 담고 있는 모듈 (ex: 상품저장, 회원가입) ⇒ 핵심 기능
Advice: Aspect의 동작을 정의하는 실제 코드, Aspect가 어떻게 동작할 건지 정의한 코드
- 내가 AOP 를 언제! 적용하고 싶다 설정하는건 ⇒ Advice + Point Cut 을 조합으로 정의
- 실행 시점에 따라서 여러 종류로 나눔
  - @Before : 타겟 메서드 실행 이전에 동작
  - @After : 타겟 메서드 실행 후 성공 /실패 여부에 상관없이 동작
  - @AfterReturning : 타겟 메서드 정상 실행 완료시 동작
  - @AfterThrowing : 타겟 메서드 예외 발생하면 동작
  - @Around : 타겟 메서드 실행 전후에 모두 동작
    - 타겟 메서드 실행을 직접 제어 proceed() 메서드 통해서 할 수 있다.
    - 가장 강력한 어드바이스로 로깅, 성능 모니터링 등등에 사용
Join Point : Advice가 적용될 수 있는 특정 지점
Point Cut: Joinpoint 중에서 Advice를 실제로 적용할 대상을 필터링하는 조건을 표현식
- ex) 나는 특정 컨트롤러가 실행될 때 Advice 부르겠다. ⇒ 이거를 표현식으로 표현
- 포인트 컷 표현식 (외울 필요는 없고 사용할때 정의를 다시 찾아봐서 사용할 것)
ProceedingJoinPoint : Spring AOP 가 구현될 때 사용되는 중요한 인터페이스
- JoinPoint 를 확장한 것으로, 메서드 호출 제어/실행을 할 수 있음
  - proceed() : 실제 타겟 메서드를 실행 // 호출하지 않으면 타겟 메서드 실행 안됌
- 주로 @Around Advice 에서 사용함

DB Replication 에 대해

짱쭈니어 — Thu, 13 Mar 2025 18:39:42 +0900

a. DB Replication 란

동일한 DB를 복제하여, Master/Slave 구조를 활용하여 DB 의 부하를 분산시키는기술
DB를 오랫동안 점유하는 쿼리는 DeadLock 이 발생할 확률 ⬆️
- ⇒ 성능저하 ⇒ 분산시켜서 성능을 올리자!

Master - Slave 구조

Insert/Update/Delete는 Master DB 로 바라보게 구성
Select 는 Slave DB를 바라보게 구성
- 왜 Select 일까?
  - 인덱스 없는 여러개 조인, 너무 많은 데이터로 ⇒ full Scan 을 생길 수 있음
  - 모든 테이블을 읽어야하는 full Scan 과 동시에 쓰기작업이 일어난다면 DeadLock 발생할 가능성 높아짐!
    - 다만, 락이 걸리는 방식과 데이터베이스마다 트랜잭션 격리수준은 다름!!
API 를 통해 변경되는 데이터는 Master DB를 통해서 반영되고, Slave에는 Replication을 통해 반영된다.

b. DB Replication 방법 종류

DB 데이터를 복제하는 방법
- 동기 : Master에 데이터변경이 있는 경우, Slave까지 동시에 적용되야 API 끝
- 비동기 : Master에 반영된 후에 API끝, Slave알아서복제
  - Master는 Slave하고 무관하게 단일DB처럼 행동
- 두개를 반반씩 합친 세미 복제 방법도 있긴하다

c. Mysql Replication 동작 원리

Mysql은 기본적으로 비동기 복제 방식 사용

Master 에 변경된 데이터에 대한 이력을 바이너리 로그에 기록한다.
Replication Master Thread가 바이너리 로그를 비동기적으로 읽어 Slave에 전송

d. Replication DB Config 설정

application.yml설정

Yml에 Master,Slave DB 모두 설정한다.
밑에 예시처럼 application.yml 에다가 DB정보를 모두 입력한다.

spring:
  datasource:
    master:
      hikari:
        driver-class-name: net.sf.log4jdbc.sql.jdbcapi.DriverSpy
        username: ##root##
        password: ##password##
        jdbc-url: jdbc:log4jdbc:mysql://~ masterDB주소
    
    slave:
      hikari:
        driver-class-name: net.sf.log4jdbc.sql.jdbcapi.DriverSpy
        username: ##root##
        password: ##password##
        jdbc-url: jdbc:log4jdbc:mysql://~ slaveDB주소
      max-lifetime: 28797000
      maximum-pool-size: 50
      validation-timeout: 2000
      connection-timeout: 30000

2. DataBaseConfig 설정

Default DB 설정 필요

// ... import 관련 코드 삭제 

@Configuration
@Profile({"도입하고 싶은 환경"}) // replication 을 모든 환경에 적용한다면 삭제해도 된다.
public class DataBaseConfig {
    public static final String MASTER_DATASOURCE = "masterDataSource";
    public static final String SLAVE_DATASOURCE = "slaveDataSource";

    @Bean(MASTER_DATASOURCE)
    @ConfigurationProperties(prefix = "spring.datasource.master.hikari") 
    public DataSource masterDataSource() {
        return DataSourceBuilder
            .create()
            .type(HikariDataSource.class)
            .build();
    }

    @Bean(SLAVE_DATASOURCE)
    @ConfigurationProperties(prefix = "spring.datasource.slave.hikari")
    public DataSource slaveDataSource() {
        return DataSourceBuilder
            .create()
            .type(HikariDataSource.class)
            .build();
    }

    @Primary
    @Bean
    @DependsOn({MASTER_DATASOURCE, SLAVE_DATASOURCE})
    public DataSource routingDataSource(
        @Qualifier(MASTER_DATASOURCE) DataSource masterDataSource,
        @Qualifier(SLAVE_DATASOURCE) DataSource slaveDataSource) {

        Map<Object, Object> datasourceMap = new HashMap<>() {
            {
                put("master", masterDataSource);
                put("slave", slaveDataSource);
            }
        };
        RoutingDataSource routingDataSource = new RoutingDataSource(); // 라우팅 관련도 구현필요
        routingDataSource.setDefaultTargetDataSource(masterDataSource); //default 를 설정해야함
        routingDataSource.setTargetDataSources(datasourceMap);
        routingDataSource.afterPropertiesSet();
        //LazyConnection 을 통해서, 트랜잭션이 시작되기 전까지는 실제 커넥션 결정되지 않음
        return new LazyConnectionDataSourceProxy(routingDataSource);
    }
}

3. Routing 관련 구현

AbstractRoutingDataSource : Spring Framework 에서 제공하며 멀티 데이터 소스를 동적으로 라우팅할 수 있도록 지원하는 추상클래스

// ... import 관련 코드 삭제 

// AbstractRoutingDataSource 상속받아서 라우팅 규칙을 정의

public class RoutingDataSource extends AbstractRoutingDataSource {

	// determineCurrentLookupKey() : 현재 어떤 데이터 소스를 사용할지 결정하는 메서드 
    @Override
    protected Object determineCurrentLookupKey() {
    
    // readOnly 이면 SlaveDB 바라보게 한다
        boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();

        //@Transaction(readOnly = true) 이면 slave DB
        if (readOnly) {
            return "slave";
        } else {
            return "master";
        }
    }
}

4. DB 연결 확인

//... import 삭제 

@Slf4j
@Service
@RequiredArgsConstructor
public class ClusterCheckServiceImpl implements CheckService{

    @Override
    public String findCustomer(Long userId) {
        log.info("1명 Customer 고객 조회 ==> masterDB 로 연결 ");
        log.info("@Transactional 애노테이션 달지 않으면,setDefault DB로 연결");
        return null;
    }

    @Override
    @Transactional(readOnly = true)
    public List<String> findCustomerList() {
        log.info("Customer 고객리스트 조회 ==> slaveDB 로 연결 ");
        return null;
    }

    @Override
    @Transactional
    public List<String> createCustomer() {
        log.info("Customer 고객리스트 신규 저장  ==> masterDB 로 연결 ");
        log.info("@Transactional  ==> readOnly 작성안하게 된다면, 기본값 false이므로 ==> masterDB로 연결 ");
        return null;
    }
}

e. 결론

DB 부하를 줄이기 위해서, Replication 방법을 사용할 수 있다.
- 사실상 DB 부하에 영향이 큰건 Read, 이거를 분리시키자!
- application 에 따라서 slave 가 n개가 될 수 있다.
동적으로 Data source 를 변경하기 위해서는 DataBaseConfig 를 따로 생성해놔야한다.
- 나는 SlaveDB 를 바라보게한 기준을 @Transational(readOnly = true) 로 기준을 잡아놨다.
- @Transational(readOnly = true) 를 사용하지 않으면 Default 인 MasterDB 로 향하게 한다.
- 잡아놓은 기준을 적극 사용해서 DefaultDB 와 연결되지 않게 하자 -> SlaveDB 로 향하게 하자!

@Column(updateable = false) 작동 확인

짱쭈니어 — Fri, 14 Feb 2025 14:14:15 +0900

@Column(updateable = false)

JPA 엔티티속 수정되지 않은 컬럼에다가 @Column(updateable = false) 설정을 하곤한다.
- 위 애노테이션이 과연 어떻게 작동하는가? 알아보려 한다.

@Column(updateable = false) 테스트 코드 작성

테스트할 Customer 엔티티 생성

@NoArgsConstructor
@AllArgsConstructor
@Builder
@Getter
@Entity
public class Customer{
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String firstName;

    private String lastName;

    @Column(updatable = false)
    private String createBy; //생성자

    @Column(updatable = false)
    private LocalDateTime createdDate; //생성 시간

    private String lastModifiedBy; //수정자

    private LocalDateTime lastModifiedDate; //수정 시간

  	// 테스트하기 위해서 생성, 수정시간 업데이트
    void updatePlusDay(Integer plusDay){
        createdDate = LocalDateTime.now().plusDays(plusDay);
        lastModifiedDate = LocalDateTime.now().plusDays(plusDay);
    }
}

2. 테스트 코드 작성

	@Test
	@Transactional
	@Rollback(value = true)
	void testCreatedDateNotUpdateAble(){
		// 1. save a new customer
		LocalDateTime now = LocalDateTime.now();
		customerRepository.save(Customer.builder()
			.firstName("star")
			.lastName("Moon")
			.build());

		// 2. DB 반영
		entityManager.flush();
		entityManager.clear();

		log.info("----- 최초 고객 정보 확인 -----");
                Customer savedCustomer = customerRepository.findById(1L);
		System.out.println(savedCustomer.toString());

		//3. 생성 시간 , 수정 시간 변경
		savedCustomer.updatePlusDay(2);

		entityManager.flush();
		entityManager.clear();

		// 4. 결과 확인
		log.info("----- 고객 정보 생성 시간 확인 -----");
		Customer checkedCustomer = customerRepository.findById(1L);
		System.out.println(checkedCustomer.toString());

		assertThat(checkedCustomer.getCreatedDate().truncatedTo(ChronoUnit.DAYS))
			.isEqualTo(now.truncatedTo(ChronoUnit.DAYS));
	}

3. 결과

updatePlusDay 메서드에서 생성,수정시간을 업데이트 치고 있다 => 하지만 @Column(updateable = false) 에 의해서 수정시간만 업데이트 된다.
createDate = 2025-02-03 , lastModifiedDate = 2025-02-05 로 수정시간만 업데이트가 되었다.

실제 update 쿼리가 나갈때 @Column(updateable = false) 컬럼은 제외하고 수행된다.

생성정보 컬럼 제외 업데이트쿼리로 나감

Redis +Spring Cache 조회했을때 성능비교

짱쭈니어 — Fri, 14 Feb 2025 11:23:16 +0900

Cache

자주 사용하는 데이터를 빠르게 접근하기 위한 임시저장공간
데이터 조회 속도 향상과 성능최적화를 목적으로 한다. --> DB 부하를 줄일 수 있다.

Spring Cache 동작 방식

캐시 애노테이션이 적용된 메서드를 호출
캐싱된 데이터가 있는지 확인
1. 있으면 바로 반환
2. 없으면 DB 조회 후에, 결과 캐싱에 저장
이후 같은 메서드, 같은 키 값 호출시 캐시에서 값 가져옴

Spring Cache 저장 위치

기본 저장소 (JVM memory) 또는 외부 캐시 저장소 (Redis.. 등등) 필요
기본 저장소 (JVM memory)
- 간단한 개발단계에서만 사용, 실무에서는 외부 캐시 저장소 사용
- JVM Heap memory 에 저장되기에, 서버 재시작시 캐싱된 데이터 없어짐
Redis
- 인메모리 데이터 저장소 (RAM 메모리에 저장한다)
  - <-> Mysql 은 디스크기반 저장소
- 인메모리 데이터 저장소이기에, 초고속 데이터 처리 가능
  - RAM 메모리이면 휘발성데이터일까? -> NO!
    - Redis 는 이것을 방지하기 위해 영속성 옵션을 제공한다.
- Redis는 인메모리 방식의 초고속 성능을 유지하면서도, 영속성을 보장합니다!

Spring Cache 관련 애노테이션

애노테이션명	역할 / 기능
@Cacheable	캐싱된 값 있는지 조회 -> 없으면 DB 조회 후 캐싱 저장(있으면 캐싱된 값 바로 반환)
@CachePut	항상 DB 조회 후 캐싱 저장한다.
@CacheEvict	캐싱된 데이터 삭제한다.
@Caching	여러개의 캐시 애노테이션을 조합한다.
@CachingConfig	클래스레벨에서 공통 캐시 설정을 지정한다.

Redis + Spring Cache 구현

테스트할 수 있는 레디스 준비 (저는 로컬에 컨테이너 형태로 띄웠습니다)
의존성 추가

//cache
implementation 'org.springframework.boot:spring-boot-starter-cache'

//redis
implementation 'org.springframework.boot:spring-boot-starter-data-redis'

3. application.yml 에 redis 정보 추가

spring:
  data:
    redis:
      host: (본인이 사용하는 레디스 쓰기)
      port: (본인이 사용하는 레디스 쓰기)

4. Redis 관련 Config 설정

import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.StringRedisSerializer;

import java.time.Duration;

@Configuration // spring의 설정클래스 나타내는 애노케이션
@EnableCaching // 캐시 활성화
public class RedisConfig {

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
        RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(10)) // TTL 10분 설정
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

        return RedisCacheManager.builder(redisConnectionFactory)
                .cacheDefaults(redisCacheConfiguration)
                .build();
    }
}

코드	설명
EnableCaching	캐시 관련 애노테이션을 동작할 수 있도록 한다.
RedisCacheManager	SpringCache 에서 Redis 를 캐시저장소로 사용할 수 있게 한다 (다른 저장소를 사용한다면 다른것일듯)
RedisConnectionFactory	Redis 서버와 연결을 관리하는 객체 application.yml 에 입력한 Redis 로 연결할 수 있게 한다. Lettce라는 클라이언트 사용 (Spring 2.x 부터는 기본 Redis 연결하는 클라이언트)
entryTtl	TTL (Time-to-live) 유효시간을 설정할 수 있다. 10 분동안 유지 -> 후에는 자동 삭제
serializeKeysWith	바이너리 -> 문자열로 변환하여 key 값을 저장한다.
serializeValuesWith	바이너리 -> Json 으로 변환하여 value 값을 저장한다.

만약 직렬화/역직렬화 설정을 하지 않으면,Redis에 데이터가 바이너리 형태로 저장된다 ⇒ 사람이 읽기 어려움

직렬화 (Serialization)	Java 객체 → JSON 문자열 변환
역직렬화 (Deserialization)	JSON 문자열 → Java 객체 변환

5. @Cacheable 적용된 메서드 생성하기

@Service
@RequiredArgsConstructor
public class BookServiceImpl implements BookService {

    private final BookRepository bookRepository;

    @Override
    @Cacheable(value = "BOOKSTORE", key = "#bookId")
    @Transactional(readOnly = true)
    public BookReadResponse findBook(Long bookId) {

      return bookRepository.findById(bookId)
          .map(BookReadResponse::toModel)
          .orElseThrow(() -> new HttpClientErrorException(HttpStatus.BAD_REQUEST, "찾는 책이 없습니다."));

    }
}

redis 에 저장된 데이터

키를 BOOKSTORE::#bookId 로 했기에 -> BOOKSTORE::1 이 키 값이 된다.
value는 json 형식으로 DB 조회된 값이 반영된다.

Cache 성능 확인

캐싱된 데이터를 가져오는게 정말 빠른건지 성능을 확인하기 위해서 AOP 사용

@Aspect
@Component
@Slf4j
public class ApiTrackingAspect {

    @Pointcut("execution(* test.api.erp.book.controller..*.*(..))")
    private void trackingController() { /* Point CUT이므로 로직 없음 */ }
    
    
    @Around("trackingController()")
    public Object checkCachePerformance(ProceedingJoinPoint joinPoint) throws Throwable{
        long start = System.currentTimeMillis();

        log.info("API 실행");
        Object proceed = joinPoint.proceed();
        
        long executionTime = System.currentTimeMillis() - start;
        System.out.println(joinPoint.getSignature() + " executed in " + executionTime + "ms");

        return proceed;
    }

결과 확인
208ms -> 28ms 로 10배정도 줄여진것을 확인할 수 있었다.
단순하게 컬럼 2개가진 데이터를 캐싱해도 10배 성능차이를 가지는데, 데이터가 클수록 성능차이를 크게 효과 볼 수 있을 것 같다.

M:N 다대다 연관 관계

짱쭈니어 — Mon, 10 Feb 2025 14:54:38 +0900

관계형 DB 에서 M:N 연관관계

- 비즈니스 서비스를 DB 를 모델링 하는 과정에서 다대다 관계가 나올 수 있다.
  - 1개의 주문은 N개의 상품을 주문한다.
  - 1개의 상품은 M개 주문에 포함될 수 있다.
  - 이렇게 되면 관계형DB 입장에서는 관계를 표시할 수가 없다.
    - 하나의 레코드에서 하나의 FK 만 가져야 하기 때문이다.
    - “콩나물” 상품을 M개 주문했다면 상품테이블에 주문 외래키로 뭐를 가져야할지?
    - 1번 주문에 여러개 상품을 주문했다면, 주문테이블에 상품 외래키로 뭐를 가져야할지?
      - 즉 서로의 외래키가 애매해진다..

주문과 상품의 다대다 관계

b. 다대다 연관관계 해소를 위한 중간테이블 필요

하나의 레코드에서 한 개의 FK 명시를 위해서는 중간테이블이 필요하다
- 중간테이블을 만들어서, 1:N 관계를 2개를 만든다.
- 1개 주문에 N개의 주문 상품을, 1개의 상품은 N개의 주문 상품을 바라보게 만든다.

c. 사용하다가 추후 다대다 관계가 생겼다면?

기존
- a, b 테이블 기존에는 두 테이블간의 관계정립이 필요하지 않은 채, 따로 놀고 있는 테이블
  - 새로 생겨야하는 기능으로, 두 테이블간의 관계 정립이 필요해짐
그러나, M:N 관계이다보니, 외래키로 연관관계 매핑이 안되어서 원하는 값을 찾을 수가 없없다
- 중간 테이블을 생성하여서 두 테이블간의 연관관계를 1:N 관계 2개로 풀기로 하였다.

d. 다대다 관계 해소를 위한 중간테이블 생성 방법

새로운 테이블을 기존의 테이블들의 PK 를 외래키로 가져야한다.

// 가상의 예를 들었습니다. 
create table goods_location
(
    goods_id          bigint unsigned        not null ,
    location_seq      int unsigned           not null comment '순번',
   // ... 내용 생략
    primary key (goods_id, location_seq)
)comment '상품_위치';

// 가상의 예를 들었습니다.
create table location_info
(
    location_id    varchar(30)                  not null ,
    label_no        char(3) charset utf8mb4      not null ,
     // ... 내용 생략
    primary key (location_id, label_no)
);

이렇게 테이블들이 있을때, 새로운 테이블을 위 테이블들과 연관관계를 맺어야한다.
- 그러기 위해, 새로운 테이블은 위 테이블들의 PK 를 외래키로 가져야한다.

create table goods_location_info
(
   goods_location_info_id bigint unsigned not null AUTO_INCREMENT PRIMARY KEY
    
    goods_id        bigint unsigned       not null ,
    location_seq    int unsigned          not null comment '순번' ,
    
    location_id     varchar(20)   not null ,
    label_no        char(3)       not null ,

    foreign key (goods_id,location_seq) references 
    goods_location (goods_id, location_seq),
    
    foreign key (location_id, label_no) references 
    location_info (location_id, label_no)
) ;

객체 연관관계, 영속성 컨텍스트

짱쭈니어 — Mon, 10 Feb 2025 14:37:41 +0900

a. 객체 설계 단계에서는 단방향 연관관계로 끝내야 한다.

단방향으로만으로도 관계 매핑이 완료된거임 → 양뱡향으로 해버리면 객체 입장에서 고려할것이 많아짐
- 양방향은 사실 단방향의 2개일 뿐
테이블 설계하면서 객체 설계 같이 진행할 것 → 이미 테이블간의 관계는 이미 정해짐
- 무엇이 1:1 관계이고, 1:N 관계인지 N:M 관계인지는 테이블 설계하면서 나올것임 이때 → 외래키를 갖고 있는 객체가 주인으로 단방향 연관관계 맺으면 됌
- 다중성이 헷갈릴때에는 반대로 생각해보기
  - 다중성 : @ManyToMany 인지, @OneToMany인지..
- 실무에서 다대다는 지양해야함!
양방향은 언제 ?
- 설계 단계에선 하지 않음, 실무하다가 정말 필요하다 생각되면 그 때 추가하면 된다.
  - 테이블 수정할 필요도 없고! (테이블 영향도 없음) mappedBy 관계 맺으면 끝
  - 단, 양방향하게 되면 무한호출 조심
    - 무한호출을 야기하는 toString()이나 JSON 변환을 하지 않기
  - 또한 양방향 관계시, 연관관계 편의 메서드 필요하면 생성
    - 두개의 테이블에서 공통된 컬럼 값 업데이트를 일일히 하지 않고, 메서드 생성하여 두개의 컬럼 모두 업데이트!
- Order 1 : OrderItem N 관계에서 order.getOrderItem 필요한 경우에 양방향 하면 되는데
  - orderItem.findByOrder() 이렇게 find 한번 하는게 나을 수 있음
  - 최대한 양방향 피할수있으면 피하기 (고려해야할게 많아지기 때문에)

b. 양방향 매핑 규칙

2관계중 외래키가 있는곳으로 주인으로 하여, 관계중 주인을 정해야 한다.
주인이 아니면 읽기만 가능, mappedBy 속성으로 주인을 지정해줘야함

// order : orderItem 1:N 관계 

@Entity
@Table (name ="`order`")
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Order{

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY) 
  private Long order_id;

 // OrderItem 엔티티에 Order 엔티티 부르는 변수명을 mappedBy 해줘야함 
  @OneToMany(mappedBy = "order") 
  private List<OrderItem> orderItem = new ArrayList<>(); 

}

@Entity
@Table (name ="order_item")
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class OrderItem{
 ...
 
 @ManyToOne
 @JoinColumn (name = "order_id") //외래키 컬럼  
 private Order order;

}

c. 영속성 컨텍스트

영속성 컨텍스트를 이해해야 실제 JPA가 어떻게 작동하는지 알 수 있다.
API 요청에 따라 EntityManagerFactory 는 EntityManager 생성
EntityManager.persist(entity);
- DB 저장이 아닌, 영속성 컨텍스트에 저장을 하겠다.
- 엔티티 매니저를 통해서 영속성 컨텍스트에 접근!
영속상태
- em.persist() 한 상태
- 객체를 저장하여서 , 영속성 컨텍스트가 관리하는 상태 ⇒ But 아직 DB 저장 전
비영속상태
- 객체 생성만 한 상태
트랜잭션 커밋 했을때 영속성 컨텍스트안에 있는 쿼리 날림
JPA 는 영속성컨텍스트 덕분에 조금이나마 효율! → SQL 을 모아서 보내기 때문에
- 마이바티스는 DB 로 바로 쿼리 보냄
- 효율이 있긴 하나, 크진 않음 → 영속성 컨텍스트가 트랜잭션 커밋을 할때 DB에 보내고 비워지기에, 하나의 트랜잭션안의 쿼리만 같이 DB 에 전송하는것이기 때문이다 (많은 처리를 하는 API 의 경우는 도움됌)

Member member = new Member(); // 비영속상태
member.setName("haha"); 
em.persist(member); // 영속상태 -> 이때 save 쿼리 안나감 / 커밋될때 나감

String whatName = member.getName(); // 영컨에서 값 가져오는것

c-1. 트랜잭션 커밋될때, 영속성컨텍스트 동작 과정

flush() 호출
Entity 와 스냅샷 비교
1. 스냅샷: DB 에서 가져와서 1차 캐시한 엔티티
바뀐 값에 대해 Update query 쓰기지연SQL 저장소에 저장
flush() : SQL query 디비에 전송
Commit

e. flush()

flush() 가 하는일
1. 변경감지 (더티체킹)
2. 수정된 엔티티를 쓰기 지연 SQL 저장소에 등록
3. 쓰기 지연소 SQL 저장소의 쿼리를 데이터베이스에 전송한다.
flush() 가 호출되는 순간 : 영속성 컨텍스트의 변경 내용 즉시 DB 반영
- em.flush() : 직접호출하는 방법 (사용할 일 없음/ 테스트할때 사용)
- transaction commit : flush 자동호출
- JPQL 쿼리 실행 : flush 자동호출
  - JPQL 쿼리 실행되기전에 flush 한 후에 JPQL 쿼리 실행
flush() 되어도 영속성 컨텍스트가 비워져도 1차 캐시는 값 유효하다.

Member firstMemeber = new Member();
firstMember.setName("ha");
memberRepository.save(firstMemeber);

em.flush(); //flush()를 해도 영속성 컨텍스트에 1차 캐시 값은 남아있다. 

System.out.println(firstMember.getName) //영속성 컨텍스트에서 캐시 값 가져오는거 -> DB 조회 안함

java 코딩테스트 준비 - 문자열

짱쭈니어 — Thu, 2 Feb 2023 13:01:50 +0900

값 입력받기

사용자가 직접 값을 입력할 때, System.in.read(), Scanner 를 사용할 수 있다.

System.in.read()
Scanner

1. System.in.read() 사용법

//System.in.read() 입력 받기 
//정수, 문자 다 저장하는데, char 로 저장된 값은 아스키코드로 저장

import java.io.IOException;
public class Main{
	public static void main(String[] args)throws IOException{
     		char c1 = System.in.read();
    }
}

2. Scanner 사용 법

//Scanner 객체는 유니코드로 문자를 입력받는다. 
import java.util.Scanner;
public class Main{
	public static void main(String[] args){
    	Scanner sc = new Scanner(System.in);
       
    }
}

주어진 글자의 아스키 코드값을 출력

----백준 11654번-----

주어진 글자의 아스키 코드값을 출력하라

//글자를 아스키 코드 값으로 받기 
public class Main{
	public static void main(String[] args)throws Exception{
    	int a = System.in.read();
        System.out.print(a);
    }
}

String 을 자르고 싶을 때 Split, charAt

String을 자르고 싶을 때, Split, charAt 가 있다.

인덱스를 지정해서 자르고 싶다면, charAt 를 사용하면 된다

String str ='number';
String[] arr = str.split("");

for(String s:arr){

}

for(int i=0; i<str.length(); i++){
	str.charAt(i);
}

글자를 숫자로 변경하고 싶다면

char, String 형을 int 형으로 바로 변환하면, 해당 숫자가 아스키코드값이 나오게 된다

만약에 글자 '1' 을 숫자 '1' 로 갖고싶다면 -'0' 을 해주어야한다.

String num1 = '1';
int num2 =num1.charAt(0)-'0';

aria-controls 속성 사용

짱쭈니어 — Wed, 5 Oct 2022 17:46:39 +0900

aria-controls 속성은 요소간의 관계를 나타내는데 사용한다.

aria-controls : 원인과 결과 관계를 만드는 요소

현재 요소에 의해 제어되는 요소를 식별한다.

현재 button 은 information div 를 제어한다.

<button onclick="showInfo();" aria-controls="I">Show info</button>
<div id="I">Information.</div>