Transaction의 전파 (feat. REQUIRES_NEW의 문제점)

💡 Issue

• syft 발급을 마무리하고, database에 완성된 syft와 관련된 정보를 업데이트 해주어야 한다.

• 이를 위해, 2개의 service 로직을 분리한 뒤, 처음에는 첫번째 로직에 영향을 받는 Propagetion.REQUIRED (default) 로 진행을 했다.
  • 첫번째 로직 (SYFT 기본 정보 삽입) 이 무조건적으로 있어야, 2번째 로직 (SYFT 발급 정보 업데이트)가 가능하다고 생각했다.

• 하지만, k8s_resource_v1.0.0.tar와 같이 약 6gb가 넘는 파일을 sbom 발급에 추가시, HIKARIPool이 계속해서 만들어지면서 Connection Leak 현상을 겪었다.

/**	
	 * SYFT 응용 로직
	 * 
	 * @param type : SBOM 타입 (SPDX, CyclondDX)
	 * @param path : Solution, Dir, File 경로
	 * @param targetName : SBOM 발급 이름
	 */
	@Transactional(propagation = Propagation.REQUIRED)
	public void updateSbomInfo(Long sbomHistoryId, String result) {
	        File checkIfFile = new File(result);
	        if (checkIfFile.isFile()) {
	            String sbomName = Paths.get(result).getFileName().toString();
	            Map<String, Object> params = new HashMap<>();
	            params.put("sbomHistoryId", sbomHistoryId);
	            params.put("sbomPath", result);
	            params.put("sbomName", sbomName);
	            
	            syftMapper.insertSuccessSbomHistory(params);
	        } else {
	            syftMapper.insertFailSbomHistory(sbomHistoryId, result);
	        }
	    } catch (Exception e) {
	        System.out.println(e.getMessage());
	    }
	}

 

💡 Connection Leak

• HikariCP에서 풀 크기가 최대치에 도달한 후, 새로운 연결을 시도할 때 발생할 수 있는 상황

• 연결 풀에 대한 설정이 잘못되었거나, 애플리케이션의 연결 관리에 문제가 있을 때 발생한다.

  

 

💡 Connection Pool을 늘릴지, Requires_New를 시도할지 고민

• Connection Pool을 늘리는 것에 대한 고민
  • Connection Pool은 기본 설정에선 10개의 연결을 갖고 있으며, 유휴 상태에도 10개를 유지하도록 되어있다.
  • 다만, Connection Pool의 크기를 키우며느, 그만큼 동시에 여러 요청을 처리할 수 있으나, 유지하면서 웹서버의 CPU 및 메모리의 사용량이 증가하고 네트워크의 부하 역시 증가한다.
  • 또한, DB도 동시 처리가 가능한 연결의 제한이 있을 수 있으므로 여러 대의 웹서버를 사용하는 경우 이를 유의해야한다 !!
  ⇒ 결과적으로 SBOM은 앞으로 여러 프로젝트에 추가될 옵션이므로 네트워크의 부하를 최적화 하기 위해 Pool을 늘리지 않는 것으로 결정했다.
• 🔗 https://jaehee329.tistory.com/35

 

• Requires_New에 대한 고민
  • INSERT, UPDATE를 하는 로직이므로 Transactional을 삭제하는 것은 문제가 발생할 것이라 예상됐다.
  • 그러므로, syft 발급과 트랜잭션을 분리하여 새로운 트랜잭션을 구성하는 Requires_New를 선택했다.
  • 하지만, HikariPool을 확인해보면 오히려 외부 트랜잭션과 내부트랜잭션에서 각각 1개의 커넥션을 필요로하므로 오히려 커넥션 풀이 고갈되는 현상을 발견했다.

  

 

💡 Async를 활용한 분리

• 이러한 고민 끝에, 데드락의 위험을 최소화하면서 독립적인 트랜잭션으로 분리할 수 있는 @Async 를 도입하기로 결정했다.

• Async
  • 비동기적인 처리를 진행해서 새로운 스레드에서 작업을 수행하도록 한다.
  • 트랜잭션은 스레드 로컬이기 때문에, 두 요청에서 서로 다른 트랜잭션을 사용하게 된다.
  • 커넥션 풀이 가득 찬 상황이라도, 내부 트랜잭션은 외부 트랜잭션이 끝날 때까지 대기하다가 해당 커넥션을 가져간다.
  • 그렇기 때문에 내부 메서드의 결과를 외부 메서드에서 활용해야 할 경우, 적합하지 않다.

🔑 ⇒ 드디어 저장 완료 !!