조금 평범한 개발 이야기

개요 mybatis 와 같은 query template 엔진이 아니라 JPA 와 같은 ORM 을 사용하다 보면 기대하는 영속화 (DB 에 값을 쓰는) 시점과 실제 영속화 시점이 달라 당황 할 수 있습니다. 이것은 JPA 가 값 (Entity) 을 관리하는 방식이 조금 차이가 있기 때문 입니다. 이 문서에서는 JPA 에서 영속화 하는 시점에 대해서 설명하고 있습니다. 영속성 컨텍스트(Persistence Context) JPA 의 영속화에 대해 알아보기 위해선 가장 먼저 영속성 컨텍스트에 대해 이해해야 합니다. 자바는 OOP 개념을 가지고 데이터를 객체처럼 관리 하고 데이터베이스(RDB) 는 관계형으로 데이터를 관리 합니다. 그래서 이 간극을 매우기 위해 ORM 이라는 개념이 등장 했습니다. ORM 에서는..

개요 k8s 는 워커의 자원 (cpu, memory) 을 공유하기 때문에 리소스 제한을 통해 파드가 사용할 자원을 미리 정의 합니다. 이는 워커에 있는 파드들이 요구하는 자원이 워커의 자원을 넘어서는 오버커밋 상태가 되었을때 특정 파드가 종료되거나 이상 동작되는 것을 막기 위함 입니다. resources: requests: cpu: 1 memory: 1Gi limits: cpu: 1 memory: 1Gi SPRING BOOT 으로 구성되었고 xms, xmx 메모리 설정이 아래와 같이 run.sh 에 1g 로 설정된 이미지가 있다고 가정해 보겠습니다. # Dockerfile ENTRYPOINT ["./run.sh"] #!/usr/bin/env bash exec java \ -jar /usr/local/se..

리소스 오버커밋 k8s에 파드를 띄울때 리소스 제한을 설정하지 않으면 파드는 워커 vm 에 있는 cpu, memory 를 서로 공유 하게 됩니다. 즉 파드 하나가 worker 의 모든 자원을 사용할 수도 있다는 이야기 입니다. 일반적인 경우에는 문제가 없으나 일순간 파드들이 동시에 많은 cpu, memory 자원을 사용하려고 할때 문제가 발생 됩니다. CPU CPU 의 경우 워커 vm 이 가지는 최대 Core 를 넘어서는 요청이 들어오면 오버커밋 상황이 되며 기대하는 응답 보다 느리게 동작이 됩니다. 이 경우에는 초과되는 요청을 한 파드가 퇴거(evict) 대상으로 지정되지 않으며 단지 워커가 전체적으로 느리게 동작이 될 뿐입니다. MEMORY 메모리의 경우 이와 다르게 최대 메모리 를 넘어서는 오버커밋..