조금 평범한 개발 이야기

개요 k8s 는 클러스트 노드에 대한 장애 내성을 가지고 있어 문제가 있다고 판단하면 컨테이너를 재시작 합니다. 문제가 있다는 것을 판단하는 기준은 다양한데 k8s worker 문제가 있어 활성 프로브 (LivenessProbe) 의 응답을 제대로 받지 못하거나 OOM 에러와 같이 컨테이너가 필요한 메모리를 충분히 확보하지 못했을때 발생 됩니다. 이렇게 다양한 기준으로 컨테이너가 종료되는데 원인을 파악하는 방법에 대해서 알아 보도록 하겠습니다. 컨테이너 상태 확인하기 컨테이너가 재시작 되면 재시작되기 직전의 종료 상태가 컨테이너 설정에 남는데 이를 먼저 확인해 봅니다. 컨텍스트에 있는 파드 리스트를 확인해 보겠습니다. (⎈ |jogeum-context:default)❯ kubectl get pods NA..

개요 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 메모리의 경우 이와 다르게 최대 메모리 를 넘어서는 오버커밋..

시작하기 자바를 주 프로그래밍 언어로 선택한 개발자들이 웹 프로그래밍을 하기 위해선 자연스럽게 스프링 프레임웍 (Spring Framework) 을 사용 합니다. 프레임웍(Framework) 이란 레고와 같이 미리 만들어진 개별 컴포넌트를 내가 원하는 형태로 가공해 프러덕(Product) 을 만드는걸 도와 주는 일종의 뼈대와 같은 기능을 제공 합니다. 스프링 프레임웍은 2003년에 최초에 발표되고 나서 웹 프로그래밍 관련해 한번도 이 기본 뼈대가 변경되지 않았고 Spring MVC 를 기반으로 하는 방법만 제공 되었습니다. 하지만 리액티브(Reactive) 프로그래밍 방식을 지원하기 위해 이 구조가 처음으로 변경이 됩니다. 이제 스프링 프레임웍은 고전적인 형태의 Spring MVC 와 리액티브 프로그래밍..

개요 자바에 변수가 선언되어 있고 여기에 값이 할당되지 않은 상태에서 변수를 참조하면 null pointer exception 이 발생 됩니다. 이게 의도했던 의도하지 않았던 unchecked exception 이 발생되기 때문에 시스템이 오류 상황을 미리 알기란 참 어려운 문제 입니다. 널오브젝트(NULL OBJECT) 패턴은 이와 같이 값이 null 일때 발생할 수 있는 문제를 최대한 방어하기 위한 패턴 입니다. 설명 먼저 계정 정보를 반환하는 service 함수가 있다고 가정해 보겠습니다. 이때 계정 정보가 없다면 null 을 반환 하는게 일반적인 함수 구현 방식인데 이때 null 을 반환 하는게 아니라 넬오브젝트를 반환하자는게 이 패턴의 핵심 입니다. 클래스다이어그램을 살펴보면 널오브젝트 Null..

개요 모노스테이트 (MONOSTATE) 패턴은 싱글톤 (SINGLETON) 패턴과 같이 동일하게 객체의 단일성을 구성하기 위한 패턴 입니다. 하지만 싱글톤 패턴은 단일 인스턴스를 제공하는 구조를 제공하고 모노스테이트는 단일 상태를 가지는 행위를 제공 하는점이 차이점 입니다. 설명 모노스테이트 패턴은 변수를 static 으로 구성하지만 메소드를 static 로 구성 하지 않는 특징을 가지고 있습니다. 이는 모노스테이트 클래스나 모노스테이트를 상속 받은 하위 클래스에서 생성되는 모든 인스턴스는 동일한 상태 변수를 가지게 된다는 것을 의미 합니다. 인스턴스를 많이 생성 하더라도 결국 하나의 상태 값을 서로 공유 하는 것이죠. 즉 어떤 클래스라도 변수를 static 으로 구성하고 이를 사용 한다면 모노스테이트 ..

개요 싱글톤 (SINGLETON) 패턴은 아주 단순한 형태의 패턴 입니다. 주로 프로그램에서 단일 인스턴스만 가져야 하는 객체가 있을 수 있는데 싱글톤 패턴은 이를 강제 함으로써 싱글톤 패턴 객체의 인스턴스가 프로그램에 단 하나만 있다는 것을 보장해 줄 수 있게 됩니다. 설명 싱글톤 패턴은 프로그램에 단일 인스턴스가 존재 한다는 것을 보장해 주기 위해서 클래스에 private 생성자로 생성을 외부에서 할 수 없게 제한하고 static 인스턴스 변수와 static 조회 함수를 이용해 단일 인스턴스를 제공해 주면 됩니다. 싱글톤은 static 키워드 특징으로 인해 호출되기 전까진 메모리에 생성이 되지 않습니다. 또한 한번 메모리에 생성이 되면 인스턴스를 제거하기가 어렵다는 문제도 같이 포함 하고 있습니다. ..