자바 Oom 문제를 해결하기 위한 방법론

Question

단순히 JVM 옵션을 바꾸는 대신, 리액트(React)처럼 선언적이고 불변(immutable)한 상태 관리 철학을 백엔드에 적용해보면 어떨까 하는 생각을 했습니다.즉, 상태를 계속 쌓지 말고 이벤트 단위로 반응하게 만들면,GC 부담과 메모리 누수를 구조적으로 줄일 수 있지 않을까 하는 접근이에요.여기에 스냅샷(snapshot)을 더하면 장애 복구도 빠르고,반응형(Reactive Streams) 구조를 결합하면 과부하 시 자동으로 백프레셔가 걸리니까OOM이 “예외”가 아니라 “불가능한 상태”가 될 수 있습니다.혹시 비슷한 고민을 해보신 분이나, 이런 접근에 대한 의견이 있을까요?

집킨 · Accepted Answer

자바의 String이 불변 객체입니다불변이라서 전역에서 공유가 가능하고 constant pool 로 쓰면서 메모리 절약이 가능하죠근데 사실 불변객체의 가장 큰 이점은 메모리 효율보단 버그를 비약적으로 줄여준다는 점입니다대부분의 OOM을 힙덤프 떠서 조사해보면 객체의 레퍼런스를 잡고 안놔주는 코드 때문입니다불변이 아니라서 발생한다 라고 보기엔 조금 약하죠그리고 자바진영에도 netty기반 reactive 개발이 가능한데 이건 메모리 절약보단 cpu극대화에 초점이 맞춰져있습니다스냅샷은 어떤걸 말씀하시는건지 몰라서 패스..

HJOW · Answer

근본적으로 백엔드는 React 의 경우와는 다르게 접근해야 합니다.자바 백엔드라고 말씀하셨으니백엔드에 적용해보면 어떨까 하는 생각을 했습니다.사실 근데 자바뿐만 아니라 백엔드는 전부 해당사항인데,이미 님 말대로 개발하고 있습니다.이를 이해하려면, 백엔드 코드가 어떤 식으로 생겼는지를 보면 됩니다.서블릿도, 요즘의 스프링 기반 웹도 마찬가지로,요청이 들어오면, 지정된 메소드가 호출되고, 그 안에서 업무를 처리하고 응답 내보내면 끝나는 구조입니다.변수 전부 메소드 안에서 선언합니다.장기 저장 데이터는 대부분 DB에 저장하고, 극히 일부, DB계정정보 등은 상수로 처리합니다.인증 관련 사항만 세션 이라는 개념으로 메모리에 보관을 했지만, 요새는 이조차도 JWT토큰으로 대체되는 추세.즉, 전역변수 같은 개념은 이미 메인 코드에서는 잘 쓰이지 않습니다.종종 쓰는 전역변수 또한 static final 을 붙여 상수로 만들어 쓰죠. 상수이므로 불변입니다.자바 코드에서 OOM이 발생하려면 두가지 중 하나가 만족해야 합니다.진짜로 데이터량이 어마어마하고 그게 다 메모리에 상주하는 경우순환 참조 등의 문제로 GC 되지 않는 데이터가 존재하고 계속 누적되는 경우순환 참조는 이미 척결 대상입니다.순환참조라 함은, 두 객체가, 멤버변수(필드) 가 있어그 필드로 서로를 보고 있음을 뜻합니다.이러면 GC 대상에서 제외됩니다. 다른 변수에서 가리키고 있는 객체이기 때문에 쓰고있다고 판단하기 때문.이런 구조를 쓸 일 사실 별로 없고요,간혹 쓰더라도 "사용 중단" 메소드를 따로 만들어 둬서, 다 쓰고나서 그걸 호출해 순환참조를 끊는 방식을 씁니다.근데 자바 백엔드에서는 심지어, 순환참조가 발생할 일이 더더욱 없습니다.스프링을 쓰기 때문에.VO를 제외하면 객체 생성 및 생존주기를 스프링이 관리를 해주기 때문입니다.순환 참조가 필요한 경우도, 실제 객체를 넣지 않고, 대신 스프링으로부터 주입받아 쓰면 됩니다.자바 기반 백엔드 프로젝트에서는 앞의 경우 (실제로 데이터 양 자체가 많은 경우) 가 많이 발생합니다.말그대로, 변수에 들어간 데이터 양 자체가 무진장 커서입니다.백엔드가 특히 이에 취약한데, 이유는 DB에서 데이터를 조회하고, 가공해서 응답하는 동안,조회한 데이터를 변수에다 계속 담아두어야 하기 때문입니다.근데 백엔드 프로젝트에서는 요청이 한명한테만 들어오는 게 아니죠? 여러명이 호출을 하고, 그 각각을 처리해 주어야 하므로, 데이터의 양은 사람 수만큼 배로 증가합니다.그 각각의 데이터들은, 응답을 보내기 전까지는 계속 들고 있어야만 하죠.여하튼 OOM 관련 문제는 이렇게 처리합니다.한번에 다루어야 하는 데이터 양 자체를 줄인다. 이를테면 페이징을 도입한다.스크롤을 내리면 추가 데이터를 불러오는 것도 일종의 페이징이다.DB 데이터를 조회해 내려보내거나, 반대로, 많은 DB 데이터를 등록/수정할 때 사용한다.임시파일을 활용한다. 또는 임시파일을 활용하는 패키지나 라이브러리를 활용한다.파일관련 처리를 할 때 사용한다. ( 특히 아파치 POI )서버에 메모리를 더 큰 것을 꽂는다. 그리고 WAS에 할당한 메모리량 자체를 늘린다.그리고 OOM이 "불가능한 상태"는 절대로 만들 수 없습니다.그리고 프론트엔드, React 도 마찬가지로, 메모리 초과 오류가 원천적으로 불가능한 것은 아닙니다.코드를 잘못짜서 발생하는 메모리 문제만 방어할 뿐이죠. 데이터 자체가 왕창 크면 어쩌겠어요.

자바 Oom 문제를 해결하기 위한 방법론

2개의 답변

Q&A 목록