programmer story

[Spring Batch] ItemReader

미니시리 — Sun, 1 Dec 2024 23:00:44 +0900

Spring Batch에서 ItemReader는 데이터를 읽어오는 역할을 담당하며, 데이터 읽기 방식에는 Cursor 기반과 Page 기반의 두 가지 주요 옵션이 있습니다. 이 두 방식은 데이터 접근과 메모리 사용 방식에서 차이가 있으며, 각각의 특징과 사용 사례가 있습니다.

1. Cursor 기반

Cursor 기반 접근은 데이터베이스 커서를 열어 한 번에 한 개의 레코드를 순차적으로 읽어옵니다.

순차적 읽기
- 데이터를 하나씩 읽기 때문에 메모리 소비가 적습니다.
- 데이터베이스 커서가 열려 있는 상태에서 작업을 진행한다
지속적인 연결
- 데이터베이스와의 연결이 작업이 완료될 때까지 유지됩니다.
- 커밋 주기에 따라 트랜잭션이 갱신될 수 있다.

장점

메모리 효율적: 한 번에 한 레코드만 처리
간단한 설정: 대부분의 경우 기본적인 JdbcCursorItemReader 구현으로 충분하다

단점

데이터베이스 연결이 길게 유지됨: 대량 데이터 처리 시 문제가 될 수 있다.
네트워크 지연에 민감: 데이터베이스 커넥션이 안정적이어야 한다.

사용예시

데이터 양이 크지 않은 경우
트랜잭션 안전성이 중요한 경우
연속적인 데이터 처리에 적합

예시

@Bean
@StepScope
public JdbcCursorItemReader<MyEntity> cursorItemReader(DataSource dataSource) {
    JdbcCursorItemReader<MyEntity> reader = new JdbcCursorItemReader<>();
    reader.setDataSource(dataSource);
    reader.setSql("SELECT id, name, value FROM my_table");
    reader.setRowMapper(new BeanPropertyRowMapper<>(MyEntity.class));
    return reader;
}

2. Page 기반

Page 기반 접근은 데이터를 페이지 단위로 읽어옵니다. 한 번의 데이터베이스 호출로 여러 레코드를 가져옵니다.

배치 읽기
- 데이터베이스에서 설정된 크기(페이지 크기)만큼 데이터를 한 번에 가져옵니다.
- 커서 대신 LIMIT과 OFFSET을 사용해 페이징 처리한다.
끊어진 연결
- 각 페이지 요청마다 데이터베이스와 새 연결을 사용한다.
- 읽기 완료 후 커넥션이 닫힌다.

장점

데이터베이스 연결 효율적: 필요할 때만 연결을 열어 데이터를 읽음.
데이터 병렬 처리 가능: 페이지를 병렬 처리하거나 캐싱할 수 있음.

단점

페이징 쿼리의 성능 문제: 대량 데이터에서 OFFSET이 클 경우 성능 저하.
더 많은 메모리 필요: 한 페이지를 메모리에 로드한 후 처리.

사용 예시

데이터 양이 많거나 병렬 처리가 필요한 경우.
데이터베이스 연결 유지 시간을 최소화하려는 경우.
JpaPagingItemReader를 활용한 엔터프라이즈 애플리케이션.

예시

@Bean
@StepScope
public JpaPagingItemReader<MyEntity> pagingItemReader(EntityManagerFactory entityManagerFactory) {
    JpaPagingItemReader<MyEntity> reader = new JpaPagingItemReader<>();
    reader.setEntityManagerFactory(entityManagerFactory);
    reader.setQueryString("SELECT e FROM MyEntity e");
    reader.setPageSize(100);
    return reader;
}

3. Cursor 기반과 Page 기반의 비교

특징	Cursor 기반	Page 기반
데이터 처리 단위	레코드 단위 처리	페이지 단위 처리
데이터베이스 연결	작업 내내 연결 유지	페이지 요청 시 연결
메모리 소비	낮음	높음 (페이지 크기만큼 데이터 유지)
처리 속도	작은 데이터셋에 적합	대규모 데이터에 적합
병렬 처리	어려움	가능 (페이지 병렬 처리)
성능	커넥션 안정성이 중요	페이징 쿼리 성능이 중요
사용 사례	연속적인 읽기, 트랜잭션 중요 작업	대규모 데이터, 병렬 처리 필요 작업

4. 선택 기준

데이터 크기: 데이터가 크다면 Page 기반, 작다면 Cursor 기반
데이터베이스 연결 시간: 연결을 짧게 유지하고 싶다면 Page 기반
트랜잭션 요구사항: 트랜잭션이 중요한 경우 Cursor 기반
성능 요구: 페이징 쿼리가 최적화된 경우 Page 기반이 더 효율적이다

참고

https://joonfluence.tistory.com/834

[React] Life Cycle

미니시리 — Sun, 24 Nov 2024 23:25:35 +0900

라이프 사이클 메서드의 종류는 크게 마운트, 업데이트, 언마운트 종류로 나눌 수 있습니다.

1. 마운트

마운트는 컴포넌트가 페이지에 새로 추가될 때 발생하는 단계이다. 이 단계에서는 다음과 같은 메서드가 호출된다.

constructor : 컴포넌트가 생성될 때 호출
getDerivedStateFromProps : props에 있는 값을 state에 넣을 때 사용하는 메서드이다. 컴포넌트가 생성될 때와 새로운 props를 받았을 때 호출된다.
render : 컴포넌트가 렌더링될 때 호출된다. 즉, 우리가 준비한 UI를 렌더링해주는 메서드이다.
componentDidMount : 컴포넌트가 웹 브라우저상에 나타난 후 호출하는 메서드이다.

2. 업데이트

컴포넌트는 다음과 같은 총 네 가지 경우에 업데이트된다.

props의 변경
state의 변경
부모 컴포넌트 리렌더링
this.forceUpdate로 인한 강제 렌더링

이렇게 컴포넌트를 업데이트 할 경우 다음 메서드들을 호출한다.

getDerivedStateFromProps : 컴포넌트가 생성될 때와 새로운 props를 받았을 때 호출된다. props의 변화에 따라 state도 변화를 주고 싶을 때 사용한다.
shouldComponentUpdate : 컴포넌트가 업데이트되어야 하는지 여부를 결정한다. 이 메서드는 true 혹은 false 값을 반환행야하며, true를 반환하면 라이프사이클 메서드를 계속 실행하고, false를 반환하면 작업을 중지한다. 즉, false일 경우 컴포넌트가 리렌더링 되지 않는다.
render : 컴포넌트가 리렌더링될 때 호출된다.
getSnapshotBeforeUpdate : render() 메서드 호출 직후, 실제로 DOM에 반영되기 전에 호출되는 메서드이다.
componentDidUpdate : 컴포넌트가 업데이트된 후 호출된다.

3. 언마운트

업데이트는 컴포넌트의 state나 props가 변경될 때 발생하는 단계이다. 이 단계에서는 다음과 같은 메서드가 호출된다.

componentWillUnmount : 컴포넌트가 웹 브라우저상에서 사라지기 전에 호출되는 메서드이다.

메서드 종류

render()

render() 메소드는 Class Component의 필수적으로 들어가야 하는 메소드입니다.

React elements 일반적으로 JSX를 통해 생성됩니다.

return (

</div>

<span className="movie-title">{title}</span>

{genres.map((genre, idx) => {<MovieGenre genres={genre} index={idx}/>})}

</div>

{synopsis}

</p>

</div>

)

Array and Fragments Fragments를 사용하면 자식 컴포넌트들을 그룹화 할 수 있다. Fragments 를 자세히 알아 보실 수 있습니다.
Portals Portals 는 부모 Component의 DOM계층 외부에 존재하는 DOM 노드 자식에 렌더링하는 일급 방법을 제공한다. 자세히 알아 보고 싶다면 Portals 링크를 참조 하세요.
String and numbers 이들은 텍스트 노드로 DOM에 렌더링 됩니다.
Booleans or null 렌더링되면 안됩니다. 이 둘은 어떠한 판단이나 테스트를 위해 존재하며, 렌더링 될 요소는 아닙니다.

추가적으로 render() 는 순수한 함수입니다. 즉, 입력이 동일하면 출력 또한 항상 동일 하여야 합니다.

constructor()

State를 초기화 하지 않고 메소드를 바인딩 하지 않는 다면 constructor()를 쓸 필요 없습니다.
Component가 마운트 되기전에 constructor()가 먼저 호출 되며 구현 시에는 super()가 다른 구문들 맨 앞에 오게 해야 합니다.
그 이유는 그렇지 않으면 this.props 가 정의 되지 않아 오류가 발생 할 수 있습니다.
일반적으로 React의 constructor는 두 가지 용도로만 사용됩니다.

this.state Oject를 통해 local state (Component) 를 초기화 합니다.
이벤트 처리기 메소드를 바인딩 합니다.

constructor(props) {
  super(props);
  // Don't call this.setState() here!
  this.state = { counter: 0 };
  this.handleClick = this.handleClick.bind(this);
}

componentDidMount()

Component가 마운트 된 후 즉시 호출 됩니다. 그러므로 DOM 노드에서 필요한 초기화는 이 메소드에서 진행 되어야 합니다.

class App extends Component {
  state = {};


  /**
   * Life cycle of React
   */
  componentDidMount() {
    this._getMovies();
  }
}

componentDidUpdate()

State가 업데이트 발생 한 직후 호출 됩니다. 초기 렌더링에서는 호출 되지 않습니다.

 componentDidUpdate(prevProps, prevState, snapshot)

componentDidUpdate(prevProps) {
    // Typical usage (don't forget to compare props):
    if (this.props.userID !== prevProps.userID) {
      this.fetchData(this.props.userID);
    }
}

위 예제처럼 조건을 걸어 두지 않으면 무한 루프에 빠질 수 있습니다. 또는 조건을 제대로 정확하게 걸어 두지 않으면 불필요한 추가 렌더링이 발생 할 수 있습니다. 물론 유저들에게는 잘 보이지 않겠지만 이건 성능상 매우 치명적일 수 있습니다.

componentWillUnmount()

마운트가 해제되거나 소멸 되기 직전에 호출 됩니다.

 componentWillUnmount()

마운트가 된 컴포넌트에 마운트가 해제 되면서 제거 되거나 정리 되어야 하는 요소들은 이 메소드에 작성 하여 주시면 됩니다.

참고

https://seungwoohong.tistory.com/m/22

[Spring] SELF_INTRODUCTION CHARACTER VARYING(255) 에러 수정

미니시리 — Sat, 16 Nov 2024 23:45:19 +0900

에러내용

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception 
[Request processing failed: org.springframework.dao.DataIntegrityViolationException: 
could not execute statement [Value too long for column "SELF_INTRODUCTION CHARACTER VARYING(255)":

원인

string을 JPA에서 쿼리문으로 변환할 때 VARCHAR(255)로 변환하는데 255자가 넘어가게 저장하면서 발생하는 에러

해결방법

@Lob
private String textStorage;

에러 발생했던 필드에 @Lob 어노테이션을 추가해주면 쿼리문으로 변환될 때 자동으로 BLOB나 CLOB로 변환해 주면서 에러 발생을 막아줄 수 있습니다.

진짜 중복과 가짜 중복을 구분하는 기준에 대한 고민

미니시리 — Sun, 10 Nov 2024 00:19:05 +0900

개발하다가 고민했던 적이 있던걸 타 블로그에서 잘 풀어 설명해주었어서 생각날 때마다 편하게 보기 위해 제 블로그에 적었습니다.

개발을 하다 보면 특정 기능에 대한 변경이 다른 기능에도 영향을 주게 되고, 이러한 사이드이펙트로 인해 시스템에 문제가 발생하는 경우가 자주 있다. 당연하게도 문제가 생긴 기능을 빠르게 복구하는 것이 가장 중요하겠지만, 이러한 문제가 생긴 근본적인 원인을 찾는 것 또한 중요하다. 대게 어떠한 기능에 대한 변경이 의도하지 않은 사이드이펙트를 유발하는 것은 단일 책임 원칙(SRP, Single Responsibility Principle)을 위반하기 때문일 것이다.
예를 들어 다음과 같이 배송 주소를 저장하는 ShippingAddress 라는 클래스가 존재하며, ShippingAddress 객체는 집 주소와 회사 주소를 관리하는 상황이라고 하자. 그리고 배송 주소는 255자를 넘지 말아야 한다는 정책이 존재한다고 하면, 이러한 비즈니스 정책에 대한 검증을 객체가 생성되는 시점에 진행할 수 있다.

data class ShippingAddress(
    val homeAddress: String,
    val companyAddress: String,
) {

    init {
        if (isAddressTooLong(homeAddress)) {
            throw IllegalArgumentException("home address is too Long")
        }
        
        if (isAddressTooLong(companyAddress)) {
            throw IllegalArgumentException("company address is too Long")
        }
    }

    private fun isAddressTooLong(address: String): Boolean {
        return address.length > 255
    }
}

이때 주소지가 너무 긴지를 검사하는 isAddressTooLong 메서드는 2번 호출되고 있는 상황이다. 그렇다면 isAddressTooLong는 SRP를 위반하는 것일까 아닐까?

SRP에 대한 사실과 오해

일단 먼저 SRP가 무엇이고 어떠한 의미를 지니는지부터 살펴볼 필요가 있다. 로버트 마틴은 SOLID 원칙 중에서 그 의미가 가장 전달되지 못한 원칙으로 SRP(Single Responsibility Principle, 단일 책임 원칙)를 뽑았다. 그리고 SRP는 “하나의 일만 해야한다”는 의미가 아니라 "단일 모듈은 변경의 이유가 하나, 오직 하나뿐 이여야 한다."는 것이라고 설명했다.

그렇다면 isAddressTooLong 메서드는 변경의 이유가 하나일까? 혹은 변경의 이유가 여러 개라서 SRP를 위반하는 상황일까? 해당 메서드가 SRP를 위반하는지는 비즈니스 정책에 따라 다를 것이다. 만약 집 주소와 회사 주소가 비즈니스적으로 동일한 주소라는 범주에 속하며, 주소지 길이를 1000자로 늘려달라는 요구사항이 들어왔을 때 모두 변경되어야 한다면 SRP를 준수하고 있는 것이다. 반면에 집 주소와 회사 주소가 비즈니스적으로 구분된 영역이며, 집 주소를 1000자로 늘려달라는 요구사항이 개별적으로 들어오는 상황이라면 SRP를 위반하는 상황이라고 볼 수 있다. 이러한 경우에는 다음과 같이 메서드를 분리하는 것이 적합한 상황이 될 수도 있다.

data class ShippingAddress(
    val homeAddress: String,
    val companyAddress: String,
) {

    init {
        if (isHomeAddressTooLong()) {
            throw IllegalArgumentException("home address is too Long")
        }

        if (isCompanyAddressTooLong()) {
            throw IllegalArgumentException("company address is too Long")
        }
    }

    private fun isHomeAddressTooLong(): Boolean {
        return homeAddress.length > 255
    }

    private fun isCompanyAddressTooLong(): Boolean {
        return companyAddress.length > 255
    }
}

중복 여부를 판단하는 기준

비즈니스를 고려하지 않고 위의 코드를 보면, 문자열 길이가 255가 넘는지를 검사하는 동일한 로직으로 보일 것이기 때문에 (가짜) 중복으로 해석될 수 있다. 하지만 우리가 작성한 코드들은 비즈니스 가치를 창출하기 위한 코드들이므로, 비즈니스적인 맥락을 고려하지 않으면 안 된다. 이렇듯 비즈니스적으로 다른 정책이며 코드는 비슷하게 보이지만 실질적인 의미가 다른 중복을 가짜 중복, 비즈니스적으로 동일한 정책이라서 중복에 해당하는 부분을 진짜 중복으로 구분할 수 있다. 이렇듯 중복이라는 것은 진짜 중복과 가짜 중복이라는 2가지의 내재적 개념을 갖는다.

따라서 해당 코드가 여러 개의 변경의 이유를 가지며 SRP를 위반하는지 혹은 중복에 해당하는 코드라서 중복을 제거해야 하는지 등을 판단하려면, 진짜 중복인지 가짜 중복인지를 먼저 구분해야 한다. 그리고 이를 위해서는 작성된 코드의 글자들 그 자체가 아니라 코드 이면의 비즈니스적인 부분도 반드시 함께 고려되어야 한다. 그렇기 때문에 개발자 역시 비즈니스를 잘 이해하고 있어야 불필요한 사이드이펙트를 예방할 수 있고, 비즈니스를 의도대로 문제 없이 구현할 수 있을 것이다.

[Spring] 가상 스레드를 이용한 부하테스트

미니시리 — Sun, 27 Oct 2024 23:00:35 +0900

Spring Property 설정

spring.threads.virtual.enabled=true
server.tomcat.threads.max=1
server.tomcat.threads.min-spare=1

Spring에서 JDK 21을 이용할 때 가상 스레드를 활용하기 위해서는 spring.threads.virtual.enabled=true를 활성화해줍니다.부하테스트를 위해 Thread는 1개로 유지합니다.

코드 작성

@GetMapping("/test")
public String test() throws InterruptedException {
  Thread.sleep(50);
  return "test";
}

간단히 위와 같은 Controller Method 하나를 작성해보고 Gatling에 Scala 코드로 동시 1000번 요청을 진행하는 방식으로 작성한 뒤 부하 테스트를 진행합니다.

package test
import scala.concurrent.duration._
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.jdbc.Predef._

class RecordedSimulation extends Simulation {

	val httpProtocol = http("testSimaulation")
		.get("http://127.0.0.1:8080/test")
    	.header("Client-Version", "1")
    
	val scn = scenario("Scenario1")
		.exec(httpProtocol)
    
    setUp( 
        scn.inject(atOnceUsers(1000)) 
    )
}

부하 테스트

1) 기존 Tomcat Thread를 활용한 방식

2) Virtual Thread를 활용한 방식

기존 MVC 작업은 Tomcat Thread 1개가 Sleep에 들어감에 따라 Sleep이 끝나야만 그 다음 작업이 처리 되므로 1000번째 요청인 하위 99퍼센트 요청은 55초째에 마무리된 것을 확인할 수 있습니다.
(Thread Sleep을 50ms로 줬으니 50ms * 1000 = 50000ms)
하지만 Virtual Thread를 사용한 방식은 하위 99퍼센트의 요청도 0.4초안에 끝나는 것을 확인할 수 있습니다.

왜 이런걸까?

가상 스레드 개념은 JVM에서 사용하는 Thread에 여러개의 가상 스레드를 붙인 뒤 kernel에 넘겨서 사용하는 개념입니다.
그러므로 가상 스레드는 OS Thread 내에서 실행됩니다.
하지만 가상 스레드에서 실행되는 코드가 블로킹 I/O 작업을 호출하면 자바 런타임은 다시 시작될 수 있을 때까지 가상 스레드를 일시 중지합니다.
그럼 OS Thread와 연결 됐었던 가상 스레드는 중지 상태에 돌아가지만 OS Thread는 다른 작업을 처리할 수 있는 구조라서 위와 같은 결과를 볼 수 있다고 보면 됩니다.

참고

https://stir.tistory.com/478

[Nginx] 특정 ip 허용/차단

미니시리 — Sun, 13 Oct 2024 23:00:43 +0900

서버에서 허용된 ip만 접속에 권한을 주려면 /etc/nginx 폴더 하위에 default.conf 를 열어 아래와 같이 ip를 허용하거나 차단하면된다.

server {
  ...
  
  location / {
    ...
    
    include 111.222.333.444;
    deny 444.333.222.111;
    
  }
  ...
}

include 나 deny 를 사용해서 허용/차단을 할 수 있고 all 을 쓰면 모든 접근을 허용/차단 을 할 수 있다.

허용 또는 차단해야 할 ip 가 많을 경우 따로 파일로 빼서 관리를 해도 된다.

vi allow_ip

allow 123.123.123.123;
allow 321.321.321.321;

server {
  ...
  
  location / {
    ...
    
    include conf.d/allow_ip;
    deny all;
    
  }
  ...
}

allow_ip 라는 파일에 ip 리스트업을 하고 conf 파일을 위와 같이 재작성 했다.
접근 허용한 ip 외에는 모두 거절하겠다고 선언하였다.

그리고 방화벽이 있는 경우, 해당 서버를 방화벽에 등록하여 http, https 접근을 허용해주고
해당 ip만 접속되는지 확인해 보면 된다.

참고

https://jong-bae.tistory.com/108

[JavaScript] Event 버블링과 캡처링

미니시리 — Sun, 6 Oct 2024 23:00:03 +0900

이벤트 버블링이란

자바스크립트에서 이벤트가 발생한 자식 요소에서 시작해 부모 요소로 전파되는 방식이다. 물 속에서 발생한 기포 방울(Bubble)이 아래에서 위로 올라가는 이미지를 연상하면 쉽다. 즉, 가장 구체적인 요소에서 이벤트가 발생하면 그 이벤트가 상위 요소들로 차례차례 전달된다.

예를 들어, <div> 안에 있는 <button>을 클릭하면, 해당 버튼에 연결된 이벤트가 먼저 실행되고, 그 이벤트는 부모 요소인 <div>로 전파된다.

<div id="parent">
  <button id="child">Click Me</button>
</div>

<script>
  document.getElementById('child').addEventListener('click', () => {
    console.log('버튼 클릭됨');
  });

  document.getElementById('parent').addEventListener('click', () => {
    console.log('부모 div 클릭됨');
  });
</script>

이 코드를 실행하면 버튼을 클릭할 때, "버튼 클릭됨"과 "부모 div 클릭됨"이 차례대로 출력된다. 이는 이벤트가 자식 요소에서 부모 요소로 전파되기 때문이다.

이벤트 캡처링이란

이벤트 캡처링(Event Capturing)은 버블링과 반대되는 개념이다. 이벤트가 부모 요소에서 시작해 자식 요소로 전달된다. 자바스크립트에서는 기본적으로 이벤트 버블링이 먼저 일어나지만, 캡처링 단계를 사용하려면 addEventListener 메서드의 세 번째 인자로 true를 전달하면 된다.

<div id="parent">
  <button id="child">Click Me</button>
</div>

<script>
  document.getElementById('parent').addEventListener('click', () => {
    console.log('부모 div 클릭됨');
  }, true);

  document.getElementById('child').addEventListener('click', () => {
    console.log('버튼 클릭됨');
  });
</script>

이 코드를 실행하면 버튼을 클릭했을 때 "부모 div 클릭됨"이 먼저 출력되고, 그 다음에 "버튼 클릭됨"이 출력된다. 이는 캡처링 단계에서 부모 이벤트가 먼저 처리되기 때문이다.

차이점

버블링과 캡처링은 이벤트가 전파되는 순서에 따라 구분된다. 버블링은 자식 요소에서 부모 요소로 이벤트가 전달되는 방식이고, 캡처링은 부모 요소에서 자식 요소로 이벤트가 전달된다. 자바스크립트는 기본적으로 버블링 방식을 사용하지만, addEventListener의 옵션을 통해 캡처링을 적용할 수 있다.

혼합 사용 예시

<div id="outer">
  <div id="inner">
    <button id="btn">Click Me</button>
  </div>
</div>

<script>
  document.getElementById('outer').addEventListener('click', () => {
    console.log('외부 div 클릭됨');
  }, true); // 캡처링

  document.getElementById('inner').addEventListener('click', () => {
    console.log('내부 div 클릭됨');
  });

  document.getElementById('btn').addEventListener('click', () => {
    console.log('버튼 클릭됨');
  });
</script>

버튼을 클릭하면 "외부 div 클릭됨"이 먼저 출력되고, 그 다음에 "버튼 클릭됨", 마지막으로 " 내부 div 클릭됨"이 출력된다. 이처럼 캡처링과 버블링이 차례로 일어나며 이벤트가 전파되는 과정을 확인할 수 있다.

참고

https://joon2974.tistory.com/entry/JavaScript-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EB%B2%84%EB%B8%94%EB%A7%81%EA%B3%BC-%EC%BA%A1%EC%B2%98%EB%A7%81

[Mysql] Prepared Statement

미니시리 — Sun, 29 Sep 2024 23:00:37 +0900

Prepared statement는 orm 도구에서 많이 사용되는 것으로 binding query라고도 불린다. 이는 하기와 같이 값이 바인딩 되는 변수에 물음표를 사용해서 SQL 문장을 작성하고 prepare 단계를 먼저 수행한 후 변수의 값을 바인딩해서 쿼리를 실행하는 형태이다.

pstmt = connection.prepareStatement(
  "select * from exam_tab where id = ?"
);
pstmt.setInt(1, 1234);
rs = pstmt.executeQuery();

이처럼 prepared statement를 사용하여 쿼리를 작성하는 경우 빠르고 간단하게 sql injection 방지 처리를 구현할 수 있다. 그리고 쿼리 파싱 비용을 줄인다. 예를 들어 동일한 prepared statment 객체를 이용하는 경우 1번째 실행에서 쿼리의 parse-tree를 생성해서 cache하기 때문에 2번째 실행 이후부터는 쿼리 파싱 비용이 감소하는 것이다.(execution-plan은 cache되지 않음.) 하지만 parse-tree를 caching하는 메모리 공간이 추가로 필요하기 때문에 메모리 사용량이 조금 더 높아지고 1번째 쿼리 실행 시에는 실제 쿼리 실행 이전에 prepared statment 단계가 필요하기 때문에 mysql 서버로부터 통신이 한 번 더 필요해진다.(network round-trip)

MySQL Server에서의 Prepared Statment

mysql server는 cache된 prepared statment는 하나의 커넥션 내에서만 공유가 되기 때문에 각각 100개의 커넥션에서 동일한 쿼리를 수행해도 prepared statment 객체는 1개가 아닌 100개 필요하다. 그리고 mysql server의 prepared statment는 클라이언트 측과 서버 측 prepared statment로 구분이 된다. 둘 모두 sql injection을 예방하는 효과는 있지만 client-side prepared statment는 실제 생각하는 prepared statment 기능과는 다르다.

mysql server의 java connection에서 실질적인 prepared statment인 server-side prepared statment는 기본값으로 비활성화 되어 있다. 즉 useServerPreStmts 값을 true로 활성화해야 사용할 수 있게 된다.

MySQL에서 PreparedStatment와 ConnectionPool의 관계

mysql server의 preparedStatment는 하나의 Connection 내에서만 공유된다. 즉 하나의 connection 안에서만 preparedStatment Cache가 재사용될 수 있는 것이다. 때문에 connection이 많으면 많을수록 더 많은 preparedStatment 객체가 필요해진다. 예를 들어 mysql server의 전체 connection 갯수가 1,000개이고 unique한 query pattern이 100개를 프로그램에서 사용한다고 가정하면 mysql server에서는 약 100,000개 정도의 preparedStatment 객체를 메모리에 캐시해야 한다.

또 mysql server는 약 16,000개 정도의 preparedStatment까지만 캐시할 수 있도록 설정되어 있다. 즉 16,000개의 캐시를 넘어서면 mysql server는 LRU 패턴을 이용해 캐시를 계속 정리하게 되고 클라이언트에서는 다시 preparedStatment 함수를 호출해서 쿼리 파싱 요청을 하게 된다. 그리고 connection pool이 자주 새로 생성되면 생성될수록 새로 파싱을 해야하기 때문에 쿼리 파싱 비용도 계속 높아질 것이다. 따라서 connection 갯수를 최소화하고 connecton 생명 주기를 최대한 길게 가져가야 preparedStatment가 실질적인 도움을 줄 수 있다.

결론적으로 connection이 많아지고 쿼리 패턴이 다양해지면 cache eviction이 발생하고 쿼리 파싱 횟수는 계속 증가하게 되므로 적절히 쿼리 파싱 횟수랑 preparedStatment 캐시 횟수를 확인해서 적절한 Max preparedStatment Count 변수를 설정하는 것이 필요하다. 그리고 쿼리가 복잡하면 복잡할수록 파싱 비용을 절약할 수 있는 preparedStatment가 도움이 되겠지만 일반적인 OLTP 환경은 쿼리들이 단순하기 때문에 preparedStatment의 장점이 줄어들 수 있다.

정리

server-side preparedStatment는 예상한 것처럼 성능을 크게 높여주지 않는다. 오히려 메모리 사용량만 높이고 필요한 preparedStatment 갯수 대비 max preparedStatment count가 너무 부족하면 쿼리 파싱 효율도 많이 떨어진다. 이처럼 mysql server에서는 server-side preparedStatment가 부작용이 심한 경우가 많다. 하지만 client-side preparedStatment는 server-side의 부작용을 가지지 않으면서 sql injection을 예방할 수 있는 효과도 있다.

[Linux] Ubuntu - OOM(Out Of Memory) 메모리 부족과 대응

미니시리 — Sun, 22 Sep 2024 23:00:10 +0900

OOM은 시스템 메모리 부족 상태를 의미하며, 서버에서 가용 가능한 메모리가 없는 상태를 뜻한다. 해당 장애가 발생했을 때 무선운 점은 모든 프로세스 (OS, APP)가 멈출뿐 아니라, 대응하기도 어렵다.

기본적으로 Linux 계열의 OS에서는 이러한 OOM 장애를 방지하기 위해 하나의 매커니즘이 동작하게 된다.

- OOM Killer

OOM Killer 는 Linux 커널이 메모리 부족상황에서 시스템을 안정적으로 유지하기 위해 Memory 를 회수하는 프로세스이다.
시스템 메모리가 부족하여 새로 메모리를 할당할 수 없는 상황에서 실행되게 된다.

OOM Killer 의 프로세스

메모리를 많이 사용하거나, 중요도가 낮은 프로세스를 선택, 강제종료
프로세스가 종료되어 메모리가 해제되면, 다른 프로세스가 사용할 수 있게 함.
System 의 중요한 프로세스는 보호된다(sshd 등)

즉 메모리 사용량, 프로세스 우선순위, oom_scope(값이 높을수록 OOM Killer 의 종료대상, 프로세스마다 보유) 해당 대상을 통해 OOM Killer 의 종료대상이 된다.

1. 메모리 사용량 확인

# 전체, 사용, 캐시, 스왑 메모리 확인
$ free -h 


# CPU/ MEM 동시 실시간 확인
$ top

// free -h 커맨드는 단순 사용량, 가용량 들을 한눈에 파악하기 쉽고
// top 커맨드의 경우 사용량이 높은 프로세스나 더 자세한 내역을 확인하기 좋다.

2. Cache/buff 메모리 사용량이 높은 경우

Cache/buff 메모리 사용량이 높고 자주 사용되고 있다면, 자주 사용하는 프로그램, 파일등에 메모리 접근 속도를 높일 수 있다는 장점이 존재하지만, 다른 프로세스들이 메모리 사용률을 확보하지 못하거나 OOM 장애가 발생할 수 있는 여지가 존재한다.
Cache/buff 메모리를 해제시켜주면 top 커맨드 사진처럼 가용가능한 메모리 자원이 생기기 때문에, 일정 주기로 Cache/buff 를 비워주는것이 좋다고 판단했다.

2-1. Cache/buff 메모리 clear

- Cache/buff 메모리를 정리하기 위해서는 2가지의 커맨드가 필요하게 된다.

# 메모리에서 disk 로 저장 & 동기화
$ sync


# Cache/buff 메모리 정리
$ sysctl -w vm.drop_caches=3

- Linux 의 작업대상이 되는 데이터들은, System Memory 에서 작업이 이루어지기 때문에, 작업대상은 Memory 에 존재하게 된다.
따라서 별도의 저장이 없거나, 중간에 시스템이 다운되는 현상이 발생하게 되면, 저장되지 않은 작업대상들은 사라진다.
이런 상황을 막기위해 Memory 의 작업대상 및 내역을 Disk 에 동기화(저장) 작업을 우선적으로 실행 해야 한다.(Flushing)

- 2번째 명령어는 파일 시스템의 PageCache, dentries, inodes 캐시를 모두 해제하는 명령어 이다.

PageCahce: 파일 데이터 캐시
inodes: 파일 시스템에서 파일에 대한 메타데이터 저장 구조체, 파일의 속성, 위치 정보를 담고있다.
dentries: 디렉토리 Entry Cache, 파일명과 inodes 를 매핑하는 역할.

vm.drop_caches=3 작업의 경우 위의 3가지 항목을 해제 하게 되며, 숫자 옵션의 경우 아래와 같다.

drop_caches=1: PageCache 해제
drop_caches=2: dentries, inodes 해제
drop_caches=3: PageCache, dentries, inodes 모두 해제

2-2. 위의 작업 한번에 진행하기

2번의 명령어를 사용하지 않고, 한번에 진행하면 더욱 편리할 수 있다.

$ sync && echo3 > /proc/sys/vm/drop_caches

3. Crontab 으로 주기적 Cache/buff 해제

- 너무 잦은 Cache/buff Clear 는 오히려 시스템의 성능에 영향을 미칠 수 있는 항목이기 때문에 일정, 특정 주기로 해당 작업을 자동화 하고 싶을 수 있다.

Linux 의 Crontab 기능을 사용하여 자동화 시킬 수 있다.(스케줄링)

# CronTab 설정
$ crontab -e


# 매주 일요일 1시에 실행 - 분 시 일 월 요일
$ 0 1 * * 0 sync && echo3 > /proc/sys/vm/drop_caches


# sudo 권한으로 실행 시키고 싶은 경우
$ sudo crontab -e

$ 0 1 * * 0 /bin/sync && /sbin/sysctl -w vm.drop_caches=3

옵션의 경우 주석의 예시를 보고 설정 해주면 된다.
crontab 작성후 필히 저장해야한다.
crontab 의 경우 기본적으로 nano 편집기를 사용하여 작성이 된다./
vi, vim 의 사용법이 더욱 익숙한 사람들은 아래처럼 하면된다.

# 한번만 vim 으로 실행
$ EDITOR=vim crontab -e


# 기본 편집기를 vim 으로 설정
$ export VISUAL=vim
$ export EDITOR=vim

이후 크론탭이 정상적으로 등록 되었는지 확인 하게 되면 끝난다.

# CronTab list 
$ crontab -l

# Sudo
$ sudo crontab -l

해당 Crontab 이 실행됬는지 확인 하려면 log 로 확인도 가능하다.

$ grep CRON /var/log/syslog


# 혹은 
grep drop_caches /var/log/syslog

참고

https://lucas-owner.tistory.com/76

NAT란

미니시리 — Sun, 15 Sep 2024 23:00:17 +0900

NAT는 네트워크 주소 변환(Network Address Translation)의 줄임말 입니다.
NAT를 사용하는 이유는 주로 사설 네트워크에 속한 여러 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위해서 입니다. IP에는 퍼블릭 IP와 프라이빗 IP가 있는데 이것들은 IPv4 주소의 낭비를 막고 공인 인터넷을 사용하지 않아도 되는 엔드포인트들에게 어떤 망이든 중복 사용이 가능한 IP를 주기 위해서 입니다.

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

위의 IP 주소들은 프라이빗 네트워크에서 사용 가능한 IP 대역이다.
같은 공간에 있는 공유기에 연결된 단말들이 사설 IP를 보유하게 됩니다. 그리고 사설 IP를 출발지 주소로 유지한 상태로 외부 인터넷으로 나갈 수 없기 때문에 인터넷은 공인 IP로만 통신이 가능합니다.
프라이빗 IP가 외부로 나가기 위해선 공유기가 프라이빗 IP를 가지고 있는 내 컴퓨터의 IP를 공유기 자신의 공인 IP로 변환하게 됩니다.
공유기를 지나서 외부 인터넷으로 나아갈 때 공유기의 공인 IP를 가지고 원하는 목적지 주소로 향하는 것이고 이것이 우리가 주로 사용하는 NAT이다.

더 이해하기 쉽게 NAT 통신 과정을 아주 간단하게 시각적으로 설명해보면

1. 내부 네트워크에서 요청 시작

내부 장치 > 컴퓨터 A가 있다고 가정
게이트웨이 > A 컴퓨터는 내부 IP 주소를 가진 공유기로 요청을 보낸다.

A 컴퓨터 (내부 IP: 192.168.1.2)
    |
    | 요청
    |
게이트웨이 (공유기)

2. NAT 변환

NAT 장비: 공유기는 A 컴퓨터의 내부 IP 주소를 기록하고 이를 공인 IP 주소로 변환한다.
변환 테이블: NAT 장비는 내부 IP를 공인 IP와 매핑한다.

A 컴퓨터 (내부 IP: 192.168.1.2)
    |
    | 변환
    |
게이트웨이 (공인 IP: 203.0.113.5)

3. 외부 네트워크로 요청 전송

요청 전송: NAT 장비는 변환된 공인 IP 주소로 외부 인터넷에 요청을 보낸다.

외부 서버 (예: 위키피디아)
    |
    | 요청 수신
    |
공인 IP: 203.0.113.5

4. 서버 응답

서버 응답: 외부 서버가 요청을 처리하고 응답을 NAT 장비의 공인 IP 주소로 보낸다.

외부 서버 (응답)
    |
    | 응답
    |
공인 IP: 203.0.113.5

5. NAT 장비에서 응답 변환

응답 수신: A 컴퓨터가 응답을 받아서 요청한 웹 페이지를 표시한다.

게이트웨이 (공인 IP: 203.0.113.5)
    |
    | 변환
    |
A 컴퓨터 (내부 IP: 192.168.1.2)

6. 내부 네트워크에서 응답 수신

응답 수신: A 컴퓨터가 응답을 받아서 요청한 웹 페이지를 표시한다.

A 컴퓨터 (내부 IP: 192.168.1.2)
    |
    | 응답
    |
게이트웨이 (공유기)

종합적 그림

내부 네트워크 NAT 장비 (공유기) 외부 네트워크

A 컴퓨터                   →     [192.168.1.2]      →       외부 서버
(192.168.1.2)                변환        [203.0.113.5]    응답
  요청                                        ↓
                      →     [203.0.113.5]    →        응답
                                    변환

↓
A 컴퓨터 (192.168.1.2:12345)

NAT의 주요 형태

1. Static NAT:

Static NAT는 내부 네트워크의 특정 장치에 대해 고정된 공인 IP 주소를 매핑한다.
서버와 같이 외부에서 특정 IP 주소로 접근해야 하는 장치에 사용된다.
예를 들면 회사의 웹 서버를 외부에서 접근 가능하게 하려는 경우에 유용하다.

2. Dynamic NAT:

Dynamic NAT는 내부 네트워크의 사설 IP 주소를 공인 IP 주소 풀에서 동적으로 할당한다.
내부 장치들이 외부 네트워크와 연결할 때 공인 IP 주소를 동적으로 할당받아 사용한다,
공인 IP 주소가 제한적일 때 사용한다.

3. PAT:

여러 내부 장치가 하나의 공인 IP 주소를 공유할 수 있도록 하며 포트 번호를 통해 트래픽을 구분한다.
가정이나 소규모 사무실 네트워크에서 흔히 사용된다.
내부 네트워크의 장치들이 동일한 공인 IP 주소를 사용하되 포트 번호를 통해 각 장치의 트래픽을 구분한다.

NAT의 장단점

장점:

IP 주소 절약: 여러 장치가 하나의 공인 IP 주소를 공유함으로써 공인 IP 주소를 절약할 수 있다.
보안: 외부 네트워크에서 내부 네트워크의 사설 IP 주소를 직접 접근할 수 없게 하여 보안성을 높인다.
유연성: 내부 네트워크의 IP 주소를 변경해도 외부에서 접근하는 공인 IP 주소는 변경할 필요가 없어 관리가 용이하다.

단점:

트래픽 감시와 모니터링의 어려움: NAT는 패킷을 변환하므로, 네트워크 트래픽을 모니터링하고 분석하는 데 어려움이 있을 수 있다.
P2P와 일부 애플리케이션의 문제: NAT가 적용된 네트워크에서는 피어 투 피어 연결이나 일부 애플리케이션에서 문제가 발생할 수 있다.(P2P 연결에서는 두 장치가 직접적으로 서로의 IP 주소와 포트 번호를 알고 있어야 한다. NAT에선 그럴 수 없으므로 직접적인 P2P 연결이 어렵다)

참고

https://hskhsmm.tistory.com/entry/what-is-nat