슬기로운 개발생활

[Java] Apache POI 엑셀 다운로드 간단한 모듈화로 쉽게 사용하기

coco3o — Tue, 24 Sep 2024 11:41:12 +0900

지난 글에 이어서 이번에는 엑셀 다운로드 기존 구조의 문제점과 이를 해결하기 위해 간단한 모듈화로 변경한 내용을 정리하고자 한다.

기본적인 형태의 엑셀 다운로드

Java를 사용하여 엑셀 다운로드 기능을 개발하면 일반적으로 Apache POI 라이브러리를 통해 구현한다.
우선, 엑셀 다운로드 기능의 전체적인 구현 흐름을 먼저 보고 시작하자.

@PostMapping("api/v1/export/download/excel")
public void download(HttpServletResponse response) throws Exception {
	// 엑셀 파일 하나를 만든다.
	Workbook workbook = new SXSSFWorkbook();
	// 엑셀 파일 내부에 Sheet 를 하나 생성한다. (엑셀 파일 하나에는 여러 Sheet가 있을 수 있다.)
	Sheet sheet = workbook.createSheet();

	// 엑셀 렌더링에 필요한 DTO 를 가져온다.
	List<UserExcelDto> userExcelDtos = userService.getUserInfo();

	// 헤더를 생성한다.
	int rowIndex = 0;
	Row headerRow = sheet.createRow(rowIndex++);
	Cell headerCell1 = headerRow.createCell(0);
	headerCell1.setCellValue("이름");

	Cell headerCell2 = headerRow.createCell(1);
	headerCell2.setCellValue("이메일");

	Cell headerCell3 = headerRow.createCell(2);
	headerCell3.setCellValue("생년월일");

	Cell headerCell4 = headerRow.createCell(3);
	headerCell4.setCellValue("가입일시");

	// 바디에 데이터를 넣어준다.
	for (UserExcelDto dto : userExcelDtos) {
		Row bodyRow = sheet.createRow(rowIndex++);

		Cell bodyCell1 = bodyRow.createCell(0);
		bodyCell1.setCellValue(dto.getName());

		Cell bodyCell2 = bodyRow.createCell(1);
		bodyCell2.setCellValue(dto.getEmail());

		Cell bodyCell3 = bodyRow.createCell(2);
		bodyCell3.setCellValue(dto.getBirthday());

		Cell bodyCell4 = bodyRow.createCell(3);
		bodyCell4.setCellValue(dto.getRegistrationDate());
	}
    
    // 응답 설정
	response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");
	response.setHeader("Content-Disposition",
			String.format("attachment;filename=%s", URLEncoder.encode("테스트_유저_정보.xlsx", StandardCharsets.UTF_8)));
    
	// 엑셀 파일 작성
	workbook.write(response.getOutputStream());
	workbook.close();
}

기존 엑셀 다운로드 구조

기존 코드는 템플릿 메서드 패턴 기반으로 적절히 추상화된 abstract class를 상속받아 공통 기능은 사용하면서 엑셀의 헤더와 내용 등 렌더링 부분은 직접 구현하는 구조였다.

public abstract class ExcelFile { // (1)

    protected <T> void createCell(Row row, int columnCount, T value, CellStyle style) {

        Cell cell = row.createCell(columnCount);
        if (value instanceof Integer) {
            cell.setCellValue((Integer) value);
        }
        else if(value instanceof Long) {
            cell.setCellValue((Long) value);
        }
        else if (value instanceof Boolean) {
            cell.setCellValue((Boolean) value);
        }
        else {
            cell.setCellValue((String) value);
        }
        cell.setCellStyle(style);
    }

    protected CellStyle createCellStyle(Workbook wb, boolean isBold) {
        CellStyle style = wb.createCellStyle();
        Font font = wb.createFont();
        font.setBold(isBold);
        style.setFont(font);
        return style;
    }
}

public abstract class BaseExportExcelService extends ExcelFile { // (2)

    protected static final int IN_MEMORY_MAX_ROW_SIZE = 1000;

    protected SXSSFSheet sheet;

    public abstract void writeHeaderLine(SXSSFWorkbook wb);
    public abstract int writeDataLines(SXSSFWorkbook wb);

    public void writeExcel(HttpServletResponse response,
                           @Nullable String password) throws IOException {
        SXSSFWorkbook wb = new SXSSFWorkbook(IN_MEMORY_MAX_ROW_SIZE);

        writeHeaderLine(wb);
        writeDataLines(wb);
        exportWithEncryption(wb,
                response.getOutputStream(),
                baseExportDao.getPassword());
    }

    protected void exportWithEncryption(SXSSFWorkbook wb, 
                                        ServletOutputStream stream,
                                        String password) throws IOException {
        if (password == null || password.isBlank()) {
            wb.write(stream);
        } else {
            POIFSFileSystem fileSystem = new POIFSFileSystem();
            OutputStream encryptorStream = getEncryptorStream(fileSystem, password);
            workbook.write(encryptorStream);
            encryptorStream.close(); // this is necessary before writing out the FileSystem

            fileSystem.writeFilesystem(stream); // write the encrypted file to the response stream
            fileSystem.close();
        }
        wb.close();
        wb.dispose();
        stream.close();
    }
    private OutputStream getEncryptorStream(POIFSFileSystem fileSystem, String password) {
        try {
            Encryptor encryptor = new EncryptionInfo(EncryptionMode.agile).getEncryptor();
            encryptor.confirmPassword(password);
            return encryptor.getDataStream(fileSystem);
        } catch (IOException | GeneralSecurityException e) {
            throw new RuntimeException("Failed to obtain encrypted data stream from POIFSFileSystem.");
        }
    }
}

public abstract class BaseExportExcelSheetListService extends SXSSFExcelFile { // (3)

    public abstract Map<String, SheetInfo> writeDataLineMap(SXSSFWorkbook workbook);

    @Override
    public void writeExcel(HttpServletResponse response,
                           @Nullable String password) throws IOException {
        SXSSFWorkbook wb = new SXSSFWorkbook(IN_MEMORY_MAX_ROW_SIZE);
        
        writeHeaderLine(wb);
        writeDataLineMap(wb);
        exportWithEncryption(wb,
                response.getOutputStream(),
                password());
    }

    @Getter
    @Setter
    @Builder
    public static class SheetInfo {
        private String sheetName;
        private SXSSFSheet sheet;
        private LocalDateTime startDateTime;
        private LocalDateTime endDateTime;
        private Integer dataSize;
    }
}

1. 엑셀 파일에 꼭 필요한 기능을 구현해 놓은 최상위 클래스이다.
2. 단일 시트에 대한 엑셀을 구현할 수 있는 추상 클래스이며, 이를 상속받아 구현한다.
3. 멀티 시트에 대한 엑셀을 구현할 수 있는 추상 클래스이며, 이를 상속받아 구현한다.

위 추상 클래스를 상속받아 다음 예시와 같이 엑셀 다운로드를 구현할 수 있다.

@PostMapping("api/v1/export/download/excel")
public void download(HttpServletResponse response) throws Exception {
	exportExampleService.writeExcel(response, "password");
}

@Service
@RequiredArgsConstructor
public class ExportExampleService extends BaseExportExcelService {

    private final UserInfoRepository userInfoRepository;
    
    @Override
    public void writeHeaderLine(SXSSFWorkbook wb) {
        super.sheet = workbook.createSheet("Users");
        Row row = super.sheet.createRow(0);
        CellStyle style = createCellStyle(workbook, true);

        super.createCell(row, 0, "이름", style);
        super.createCell(row, 1, "이메일", style);
        super.createCell(row, 2, "생년월일", style);
        super.createCell(row, 3, "가입일시", style);
    }

    @Override
    public int writeDataLines(SXSSFWorkbook wb) {
        int rowCount = 1;

        CellStyle style = createCellStyle(workbook, false);

        List<UserExcelDto> data = userInfoRepository.getUserInfo();
        for (UserExcelDto dto : data) {
            Row row = super.sheet.createRow(rowCount++);
            int columnCount = 0;

            super.createCell(row, columnCount++, dto.getName(),style);
            super.createCell(row, columnCount++, dto.getEmail(),style);
            super.createCell(row, columnCount++, dto.getBirthday(),style);
            super.createCell(row, columnCount, dto.getRegistrationDate(),style);
        }
        return data.size();
    }
}

엑셀 다운로드 결과 예시

위의 코드를 관계도로 보면 아래와 같다.

이 방식은 추상 클래스를 활용하여 엑셀 다운로드 기능을 쉽게 개발할 수 있지만, 다음과 같은 단점들이 있었다.

구현 클래스의 증가
- 엑셀 다운로드를 구현할 때마다 구현 클래스가 계속해서 늘어난다.
반복적인 코드 작성
- 헤더와 바디에 대해서 Cell 하나하나마다 코드를 매번 직접 작성해야 한다.
휴먼 에러 가능성
- Column의 수가 많아질수록 오타나 실수 등의 휴먼 에러가 발생할 가능성이 높아진다.
여러 책임을 가진 구현 클래스
- 데이터 조작 및 엑셀 데이터 렌더링 등의 여러 책임을 갖고 있다.

실제로 내부 어드민에는 현재 약 30개 이상의 엑셀 다운로드 클래스가 있으며, 엑셀 다운로드 기능이 필요할 때마다 추가 작업을 해야 한다.

(실제로는 더 많다..)

따라서, 현재와 같은 방법은 생산성이 다소 떨어진다 판단했고, 개선 작업의 필요성을 느꼈다.

기존 구조를 간단한 모듈로 개선

개선 목표는 크게 다음과 같다.
1. 엑셀 다운로드를 구현 할 때마다 늘어나는 보일러플레이트 개선
2. Cell 작성 과정을 자동화하여 반복적인 작업을 제거
3. 기능별 책임을 분리

엑셀 다운로드 기능을 크게 데이터 헤더라인 작성, 데이터 바디라인 작성 그리고 엑셀 파일 생성으로 구분하고,
각 역할을 담당하는 클래스를 만들어 책임을 분리했다.
이를 간단히 요약하면 다음과 같다.

1. ExcelMetaData
- 엑셀 렌더링에 필요한 일종의 메타데이터(헤더 및 이름 정보)를 보관하는 객체
2. ExcelSheetData
- 엑셀 렌더링에 필요한 바디 데이터 정보를 담은 객체
3. SXSSFExcelFile
- 엑셀 파일 생성을 담당하는 객체

1. DTO 생성과 함께 데이터 헤더 값 설정하기

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ExcelColumn {

    String headerName() default "";

}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ExcelSheet {

    String name() default "";
}

@ExcelSheet(name = "Users")
public class UserExcelDto {
    @ExcelColumn(headerName = "이름")
    private final String name;
    @ExcelColumn(headerName = "이메일")
    private final String email;
    @ExcelColumn(headerName = "생년월일")
    private final String birthday;
    @ExcelColumn(headerName = "가입일시")
    private final String registrationDate;
}

기존엔 Column에 Cell을 일일이 작성해줘야 했다.
이를 커스텀 어노테이션을 통해 DTO 클래스에서 엑셀에 표시하고 싶은 필드를 @ExcelColumn으로,
시트 명을 @ExcelSheet으로 설정하도록 변경 했다.

이제 이 어노테이션이 달린 DTO를 받아서 엑셀에 그릴 수 있도록 도와주는 객체를 생성한다.

@Getter
public class ExcelMetadata { // (1)

    private final Map<String, String> excelHeaderNames;
    private final List<String> dataFieldNames;
    private final String sheetName;

    public ExcelMetadata(Map<String, String> excelHeaderNames,
                         List<String> dataFieldNames,
                         String sheetName) {
        this.excelHeaderNames = excelHeaderNames;
        this.dataFieldNames = dataFieldNames;
        this.sheetName = sheetName;
    }


    public String getHeaderName(String fieldName) {
        return excelHeaderNames.getOrDefault(fieldName,"");
    }
}

public class ExcelMetadataFactory { // (2)
    private ExcelMetadataFactory() {}

    private static class SingletonHolder {
        private static final ExcelMetadataFactory INSTANCE = new ExcelMetadataFactory();
    }

    public static ExcelMetadataFactory getInstance() {
        return SingletonHolder.INSTANCE;
    }

    public ExcelMetadata createMetadata(Class<?> clazz) {
        Map<String, String> headerNamesMap = new LinkedHashMap<>();
        List<String> dataFieldNamesList = new ArrayList<>();

        for (Field field : getAllFields(clazz)) {
            if (field.isAnnotationPresent(ExcelColumn.class)) {
                ExcelColumn columnAnnotation = field.getAnnotation(ExcelColumn.class);
                headerNamesMap.put(field.getName(), columnAnnotation.headerName());
                dataFieldNamesList.add(field.getName());
            }
        }

        if (headerNamesMap.isEmpty()) {
            throw new RuntimeException(String.format("Class %s has not @ExcelColumn at all", clazz));
        }

        return new ExcelMetadata(headerNamesMap, dataFieldNamesList, getSheetName(clazz));
    }

    private String getSheetName(Class<?> clazz) {
        ExcelSheet annotation = (ExcelSheet) getAnnotation(clazz, ExcelSheet.class);
        if(annotation != null) {
            return annotation.name();
        }
        return "Users";
    }
}

public final class SuperClassReflectionUtils { // (3)

    private SuperClassReflectionUtils() {}

    public static List<Field> getAllFields(Class<?> clazz) {
        List<Field> fields = new ArrayList<>();
        for (Class<?> clazzInClasses : getAllClassesIncludingSuperClasses(clazz, true)) {
            fields.addAll(Arrays.asList(clazzInClasses.getDeclaredFields()));
        }
        return fields;
    }

    public static Annotation getAnnotation(Class<?> clazz,
                                           Class<? extends Annotation> targetAnnotation) {
        for (Class<?> clazzInClasses : getAllClassesIncludingSuperClasses(clazz, false)) {
            if (clazzInClasses.isAnnotationPresent(targetAnnotation)) {
                return clazzInClasses.getAnnotation(targetAnnotation);
            }
        }
        return null;
    }

    public static Field getField(Class<?> clazz, String name) throws Exception {
        for (Class<?> clazzInClasses : getAllClassesIncludingSuperClasses(clazz, false)) {
            for (Field field : clazzInClasses.getDeclaredFields()) {
                if (field.getName().equals(name)) {
                    return clazzInClasses.getDeclaredField(name);
                }
            }
        }
        throw new NoSuchFieldException();
    }


    private static List<Class<?>> getAllClassesIncludingSuperClasses(Class<?> clazz, boolean fromSuper) {
        List<Class<?>> classes = new ArrayList<>();
        while (clazz != null) {
            classes.add(clazz);
            clazz = clazz.getSuperclass();
        }
        if (fromSuper) {
            Collections.reverse(classes);
        }
        return classes;
    }
}

1. 엑셀을 그릴 때 필요한 일종의 메타데이터를 보관하는 객체다.
2. Factory 객체가 DTO의 어노테이션을 파악하여 메타데이터를 정리하는 책임을 가진다.
3. 우아한 형제들 기술 블로그에 올라온 유틸리티 코드를 사용하였다.

2. 바디 데이터 정보를 담을 객체 만들기

@Getter
@AllArgsConstructor
public class ExcelSheetData { // (1)
    private final List<?> dataList;
    private final Class<?> type;

    public static ExcelSheetData of(List<?> dataList, Class<?> type) {
        return new ExcelSheetData(dataList, type);
    }
}

public class ExcelSheetDataGroup { // (2)
    private final List<ExcelSheetData> dataList;

    private ExcelSheetDataGroup(List<ExcelSheetData> data) {
        validateEmpty(data);
        this.dataList = new ArrayList<>(data);
    }

    public List<ExcelSheetData> getExcelSheetData() {
        return Collections.unmodifiableList(dataList);
    }

    public static ExcelSheetDataGroup of(ExcelSheetData... data) {
        List<ExcelSheetData> list = (data == null) ? List.of() : List.of(data);
        return new ExcelSheetDataGroup(list);
    }

    private void validateEmpty(List<ExcelSheetData> data) {
        if(data.isEmpty()) {
            throw new IllegalArgumentException("lists must not be empty");
        }
    }
}

1. 엑셀 단일 시트의 바디 데이터 정보를 담는 객체다.
2. 엑셀 멀티 시트의 각 시트별로 그려질 바디 데이터 정보를 담는 객체다.

3. 엑셀 생성을 위한 베이스 구조 만들기

public interface ExcelFile { // (1)

    void write(OutputStream stream) throws IOException;
    void writeWithEncryption(OutputStream stream, String password) throws IOException;

    default <T> void createCell(Row row, int column, T value, CellStyle style) {
        if(value == null) return; // avoid NPE
        
        Cell cell = row.createCell(column);
        if (value instanceof Integer) {
            cell.setCellValue((Integer) value);
        }
        else if(value instanceof Long) {
            cell.setCellValue((Long) value);
        }
        else if (value instanceof Boolean) {
            cell.setCellValue((Boolean) value);
        }
        else {
            cell.setCellValue((String) value);
        }
        cell.setCellStyle(style);
    }

    default CellStyle createCellStyle(Workbook wb, boolean isBold) {
        CellStyle style = wb.createCellStyle();
        Font font = wb.createFont();
        font.setBold(isBold);
        style.setFont(font);
        return style;
    }
}

public abstract class BaseSXSSFExcelFile implements ExcelFile { // (2)

    protected static final int ROW_ACCESS_WINDOW_SIZE = 1000;
    protected static final int ROW_START_INDEX = 0;
    protected static final int COLUMN_START_INDEX = 0;

    protected SXSSFWorkbook workbook;
    protected Sheet sheet;

    public BaseSXSSFExcelFile() {
        this.workbook = new SXSSFWorkbook(ROW_ACCESS_WINDOW_SIZE);
    }

    protected void renderHeaders(ExcelMetadata excelMetadata) {
        sheet = workbook.createSheet(excelMetadata.getSheetName());
        Row row = sheet.createRow(ROW_START_INDEX);
        int columnIndex = COLUMN_START_INDEX;
        CellStyle style = createCellStyle(workbook, true);

        for (String fieldName : excelMetadata.getDataFieldNames()) {
            createCell(row, columnIndex++, excelMetadata.getHeaderName(fieldName), style);
        }
    }

    protected void renderDataLines(ExcelSheetData data) {
        CellStyle style = createCellStyle(workbook, false);
        int rowIndex = ROW_START_INDEX + 1;
        List<Field> fields = getAllFields(data.getType());

        for (Object record : data.getDataList()) {
            Row row = sheet.createRow(rowIndex++);
            int columnIndex = COLUMN_START_INDEX;
            try {
                for (Field field : fields) {
                    field.setAccessible(true);
                    createCell(row, columnIndex++, field.get(record), style);
                }
            } catch (IllegalAccessException e) {
                throw new RuntimeException("Error accessing data field rendering data lines.", e);
            }
        }
    }

    @Override
    public void write(OutputStream stream) throws IOException {
        workbook.write(stream);
    }

    @Override
    public void writeWithEncryption(OutputStream stream, String password) throws IOException {
        if (password == null) {
            write(stream);
        } else {
            POIFSFileSystem fileSystem = new POIFSFileSystem();
            OutputStream encryptorStream = getEncryptorStream(fileSystem, password);
            workbook.write(encryptorStream);
            encryptorStream.close(); // this is necessary before writing out the FileSystem

            fileSystem.writeFilesystem(stream); // write the encrypted file to the response stream
            fileSystem.close();
        }

        workbook.close();
        workbook.dispose();
        stream.close();
    }

    private OutputStream getEncryptorStream(POIFSFileSystem fileSystem, String password) {
        try {
            Encryptor encryptor = new EncryptionInfo(EncryptionMode.agile).getEncryptor();
            encryptor.confirmPassword(password);
            return encryptor.getDataStream(fileSystem);
        } catch (IOException | GeneralSecurityException e) {
            throw new RuntimeException("Failed to obtain encrypted data stream from POIFSFileSystem.");
        }
    }
}

public class SXSSFExcelFile extends BaseSXSSFExcelFile { // (3)

    public SXSSFExcelFile(ExcelSheetData data, 
                          HttpServletResponse response) throws IOException {
        this(data, response, null);
    }
    public SXSSFExcelFile(ExcelSheetData data, 
                          HttpServletResponse response,
                          @Nullable String password) throws IOException {
        ExcelMetadata metadata = ExcelMetadataFactory.getInstance().createMetadata(data.getType());
        exportExcelFile(data, metadata, response.getOutputStream(), password);
    }

    private void exportExcelFile(ExcelSheetData data,
                                 ExcelMetadata metadata,
                                 ServletOutputStream stream,
                                 String password) throws IOException {
        renderHeaders(metadata);
        renderDataLines(data);
        writeWithEncryption(stream, password); // if password is null, encryption will not be applied.
    }
}

public class SXSSFMultiSheetExcelFile extends BaseSXSSFExcelFile { // (4)

    public SXSSFMultiSheetExcelFile(ExcelSheetDataGroup dataGroup,
                                    HttpServletResponse response) throws IOException {
        this(dataGroup, response, null);
    }
    public SXSSFMultiSheetExcelFile(ExcelSheetDataGroup dataGroup,
                                    HttpServletResponse response,
                                    @Nullable String password) throws IOException {
        exportExcelFile(dataGroup, response.getOutputStream(), password);
    }


    private void exportExcelFile(ExcelSheetDataGroup dataGroup,
                                 ServletOutputStream stream,
                                 String password) throws IOException {
        for (ExcelSheetData data : dataGroup.getExcelSheetData()) {
            ExcelMetadata metadata = ExcelMetadataFactory.getInstance().createMetadata(data.getType());
            renderHeaders(metadata);
            renderDataLines(data);
        }
        writeWithEncryption(stream, password); // if password is null, encryption will not be applied.
    }
}

1. 엑셀 파일이 꼭 가져야 할 인터페이스를 정의했다.
2. 인터페이스를 구현하며, 엑셀 데이터를 그려주는 클래스다.
3. 단일 시트 엑셀 파일을 생성시 사용하는 클래스다.
4. 멀티 시트 엑셀 파일을 생성시 사용하는 클래스다.

위 구조를 통해 다음과 같이 엑셀 파일을 생성할 수 있다.

@PostMapping("api/v1/export/download/excel")
public void download(HttpServletResponse response) throws Exception {
	List<UserExcelDto> userInfoList = userService.getUserInfo();
	new SXSSFExcelFile(ExcelSheetData.of(userInfoList, UserExcelDto.class), response);
}

개선된 구조의 객체간 관계도는 다음과 같다.

정리하며

새로 만든 구조는 기존보다 훨씬 간결해졌고, 코드의 복잡성을 크게 줄였다..

이제 엑셀 파일을 생성할 때마다 새로운 구현 클래스를 추가할 필요가 없으며, Cell마다 일일이 작성하는 번거로움도 사라졌다. 비록 best practice는 아닐 수 있지만, 기존 구조의 문제를 해결하고 효율성을 높였다는 점에서 긍정적인 결과를 얻었다고 생각한다.

참고 자료 :
우아한 형제들 기술 블로그

대용량 엑셀 다운로드 OOM(Out Of Memory) 해결 과정

coco3o — Fri, 16 Aug 2024 16:54:16 +0900

서버가 갑자기 먹통이 된 경험을 했다.
운영 중인 서버의 CPU 사용률이 급격히 상승하며 서버가 죽어버렸다.
서버를 즉시 재가동하고 원인을 확인한 결과, OOM(Out Of Memory)으로 인해 서버가 중단된 것이었다.

왜 OOM(Out Of Memory)이 발생했는가?

관리자 페이지에서 엑셀 다운로드를 하는데 약 N만 건 이상의 Row를 다운로드하는 과정에 OOM이 발생했다.
현재 운영 중인 서버는 1개의 WAS 안에 서비스, 관리자 등 여러 프로젝트가 함께 돌아가고 있는 상황이다.
여러 요청에 대한 처리와 N만 건 이상의 Row를 다운받는 요청이 겹치면서 과부하가 발생한 것으로 보인다.
하지만, N만 건 정도의 데이터를 처리하면서 OOM이 발생하는 것은 이상하다고 생각하여 원인을 찾아보았다.

원인 파악

현재 엑셀 다운로드를 위해 Apache POI 라이브러리의 XSSFWorkbook을 사용하고 있는데,
문제의 원인은 XSSFWorkbook에서 확인되었다.

XSSFWorkbook 메모리 누수

메모리 효율성의 부족
- XSSFWorkbook 는 엑셀 파일 전체가 만들어질때까지 데이터를 메모리에 상주시키는 방식이다.
- 큰 데이터셋을 다룰 경우 상당한 양의 메모리를 소비하며, 서버의 메모리 용량에 따라 OOM(Out Of Memory) 에러가 발생할 수 있다.
대용량 데이터 처리시 성능 저하
- 작은 데이터셋에서는 문제가 되지 않지만, 수만 또는 수백만 데이터의 대용량 파일을 처리할 때 처리 속도가 현저히 느려지며 성능이 크게 떨어진다.
가비지 컬렉션 부담
- 대용량 파일을 처리하는 동안, XSSFWorkbook은 많은 수의 임시 객체를 생성할 수 있다.
- 이는 가비지 컬렉터에 부담을 주며, 시스템의 전체 성능에 영향을 줄 수 있다.

문제 해결 방법

1. 서버 메모리 증설하기 (돈으로 찍어 누르기 )

사실 이 방법이 제일 쉬운 방법이다.
OOM이 발생한 가장 직관적인 이유는 메모리가 부족한 것이다.

현재 운영 중인 서버의 메모리는 8GB 밖에 되지 않는다...

따라서 서버의 메모리를 증설하여 스케일업 하면 해결될 일이다.
하지만 이는 데이터가 계속 증가할 것을 고려하면 메모리 증설만으로는 근본적인 해결책이 될 수 없다.

2. 서버 내 여러 프로젝트 분리하기

현재 운영 중인 서버는 하나의 톰캣 서버에 여러 프로젝트가 돌아가고 있는 상황이다.
이 프로젝트들을 각각 독립된 서버로 분리하는 방법도 고려해 봤지만,
서버 비용과 들어갈 작업의 양이 많아 당장 진행하기엔 어려움이 있었다..

한정된 내부 자원 안에서 해결할 수 있는 방법이 없을까 고민하였고,
엑셀 다운로드를 지원하는 Apache POI 라이브러리 중 SXSSFWorkbook를 찾을 수 있었다.

3. SXSSFWorkbook 사용

SXSSFWorkbook은 지정한 Row만큼만 메모리에 로드하여 처리하다가 지정한 Row에 도달하면
임시 XML 파일로 디스크에 기록하고 메모리를 비워주는 스트리밍 방식이다.
즉, SXSSFWorkbook은 메모리에 있는 데이터를 디스크로 옮기면서 처리하기 때문에 메모리를 적게 먹어 대용량 데이터 처리에 매우 적합하다.

비록 디스크에 플러시한 Row는 다시 접근 할 수 없는 단점도 있지만, 현재 상황에서는 큰 문제가 되지 않았다.

너로 정했다!

아래와 같이 인자 값을 지정해주면 설정한 row 수만큼 작성 후 알아서 flush 해준다.

// auto disk flush
// 메모리에 1000개 rows를 유지하고, 초과 rows는 disk에 auto-flush
SXSSFWorkbook wb = new SXSSFWorkbook(1000);

// 인자 값 없이 생성시 default 100 
SXSSFWorkbook wb = new SXSSFWorkbook();

// auto-flushing 끄기 (모든 rows memory 유지)
SXSSFWorkbook wb = new SXSSFWorkbook(-1);

아래와 같이 flushRows 메서드로 데이터를 수동으로 디스크로 옮길 수도 있다.

// manually control
if(rownum % 100 == 0) {
    // 마지막 100개 rows를 제외한 all rows flush
    ((SXSSFSheet)sh).flushRows(100); 
    
    // 모든 rows disk flush
    ((SXSSFSheet)sh).flushRows(); // is a shortcut for ((SXSSFSheet)sh).flushRows(0)
}

wb.write(stream);
wb.close();
wb.dispose(); // 디스크에 저장한 임시파일 삭제

작업 완료 후엔 디스크에 저장된 임시파일을 삭제해줘야 한다.

XSSFWorkbook을 SXSSFWorkbook 라이브러리로 사용하도록 변경했다.

개선 전후 비교하기

로컬에서 약 10만 건의 데이터(약 6MB 용량)를 추출하는 API를 10회 연속으로 호출하는 테스트를 진행했으며,
VisualVM을 사용해 메모리 변화를 모니터링했다.

AS-IS

개선 전에는 요청을 처리하다가 서버가 죽었고,

TO-BE

개선 후에는 서버가 안정적으로 작업을 처리했다.
메모리 사용량 그래프도 전과 비교하면 상당히 안정적이며 기존보다 약 80%정도 절감되었다.
메모리 효율성이 향상되면서 다운로드 속도도 크게 개선됐으며,
10만 건의 데이터를 다운로드하는 데 77초에서 5초로 단축되어, 약 1400% 이상 성능이 개선되었다.

라이브러리를 변경하면서 엑셀 다운로드 코드 베이스 구조의 문제점도 몇 가지 보여 나중에 전반적으로 개선 후 다시 블로그에 정리해야겠다.

Service와 Repository를 완전히 분리하기 (with. DDD)

coco3o — Wed, 15 May 2024 19:45:20 +0900

Intro

개발 오픈 톡방에서 "Service와 Repository는 완벽히 분리되어야 한다."의 내용이 화두 되었다.
즉, "도메인은 특정 기술(인프라)에 의존하지 않고 순수하게 유지되어야 한다."는 말인데,
어떻게 하면 도메인과 인프라를 완벽히 분리할 수 있는지 알아보도록 하자.

Layered Architecture와 DDD(Domain Driven Design)

레이어드 아키텍처는 가장 흔하게 사용되는 아키텍처이다.
이름 그대로 프로그램 내에서 계층을 나누는 설계 방식이며, 의존의 방향성은 오직 위에서 아래로만 내려간다.
일반적으로 Presentation, Business, Persistence, DataBase의 4개 표준 레이어로 구성한다.
물론 규모에 따라 병합하기도 하며, 그 이상의 레이어로 구성하기도 한다.

스프링 기준 대표적인 예시

Controller - Service - Domain - Repository

각 계층은 어플리케이션 내에서 특정 역할과 관심사(화면 표시, 비즈니스 로직 수행, DB 작업 등) 별로 구분되며,
이는 레이어드 아키텍처의 강력한 기능인 '관심사의 분리(Separation of Concern)'를 의미한다.
특정 계층의 구성 요소는 해당 계층의 관련 기능만 수행해야 한다는 것이다.

DDD에서 Layered Architecture를 적용하면 아마 다음과 같은 구조가 일반적으로 사용될 것이다.

https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design

이제 DDD 관점에서 Repository를 생각해 보자.
우리는 JPA를 사용하는 세대이므로 JPA를 기준으로 글을 작성하겠다.

public class MemberService {
    @Autowired
    private MemberRepository memberRepository;
    ...
}

public interface MemberRepository extends JpaRepository<MemberEntity, Long> {
}

위 코드는 도메인이 인프라를 의존하고 있어 관심사 분리가 되지 않고 있다.
JpaRepository를 상속받은 인터페이스를 그대로 사용하면서 jpa 메서드가 서비스 도메인에 노출되어 내가 구현하지 않은 메서드를 사용할 수 있고, 반환값으로 엔티티를 받기 때문에 구현 기술에 의존하게 되면서 문제가 생긴다.

서비스 도메인은 인프라의 형태에 의존적이지 않아야 한다.

인프라의 구현이 jpa이든 mybatis이든 파일 시스템이든 상관없이 서비스의 구현은 동일해야 한다는 말이다.

구현 기술에 대한 의존 없이 도메인을 순수하게 유지하려면 어떻게 해야 할까?

이 부분은 의존성 역전 원칙(DIP, Dependency Inversion Principle)으로 해결할 수 있다.

현재 도메인 영역이 인프라를 의존하며, 고수준 모듈이 저수준 모듈을 의존하고 있는 것으로 보인다.
이는 반대로 저수준 모듈이 고수준 모듈에 의존하게 해야 한다 라는 의미로,
도메인 → 인프라 의존 관계를 인프라 → 도메인 의존 관계로 의존의 방향을 역전시키겠다는 이야기다.

하지만 한 가지 문제가 생긴다. 코드로 확인해 보자.

// domain layer
public interface MemberRepository {
    void save(Member member);
    Member findById(Long id);
}
// pojo class
public class Member {
    private Long id;
    private String name;
}


// infrastructure layer
interface MemberJpaRepository extends JpaRepository<MemberEntity, Long> {
    void save(MemberEntity entity);
    MemberEntity findById(Long id);
}
// jpa entity class
@Entity
class MemberEntity {
    @Id
    private Long id;
    private String name;
}

위와 같이 도메인에 존재하는 Repository와 인프라에 존재하는 Repository의 형태가 서로 달라져버린다.
그래서 다음과 같이 중간에 Adapter 클래스를 하나 두고, 해당 Adapter가 도메인의 Repository와 인프라의 Repository 사이의 규격을 맞춰주면 된다.

// adapter class (infra layer)
@Repository
public class MemberRepositoryImpl implements MemberRepository {
    // JpaRepository를 injection하여 필요한 기능만 래핑하여 노출한다. *SOLID 중 ISP 원칙 준수
    private final MemberJpaRepository memberJpaRepository;

    public MemberRepositoryImpl(MemberJpaRepository memberJpaRepository) {
        this.memberJpaRepository = memberJpaRepository;
    }

    @Override
    public void save(Member member) {
        // converting
        MemberEntity entity = MemberEntity.from(member);

        memberJpaRepository.save(entity);
    }

    @Override
    public Member findById(Long id) {
        MemberEntity entity = memberJpaRepository.findById(id).orElse(null);
        // converting
        return (entity != null) ? new Member(entity.getId(), entity.getName()) : null;
    }
}

@Service
public class MemberService {
    // MemberRepository가 jpa를 사용하는지 redis를 사용하는지 전혀 모름
    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    public void doSomething() {
        // TODO
    }

}

DIP를 이용해서 도메인 모델에 존재하는 Repository를 추상화로 만들고 실제 구현을 infrastructure에서 하게 한다. 도메인 관점에서 "나는 이런 것들을 이렇게 저장할 것이고, 이렇게 불러올 거야!"라는 명세를 만들어놓고 실제 구현 기술에 대한 부분을 분리시킨다는 것이다.
즉, domain layer에서는 저장하는 방법에 대해 관심을 갖고, infrastructure layer 에서는 실제로 어떻게 저장하는지에 대해 관심을 갖는다.
이로써 도메인은 어댑터 뒤에 어떤 기술을 사용하던 상관없이 데이터를 조작하는 데에 필요한 인터페이스만을 바라보고 협력하기 때문에 repository의 형태에 의존하지 않으면서 서비스의 구현은 일관성을 가진다.

이렇게 분리하면 복잡성을 낮추고 확장성을 높이는 이점을 취할 수 있다.
하지만 분리하는 것이 마냥 좋은 것만은 아니며, 다음과 같은 몇 가지 문제들이 있다.

너무 많은 컨버팅 코드
휴먼 에러
구현 기술의 강력한 기능 사용 불가

1. 너무 많은 컨버팅 코드

순수 도메인 객체와 영속성 객체는 분리되어야 한다.
즉, service ↔ repository의 파라미터와 반환 값은 외부에 의존적이지 않도록 컨버팅 작업이 필요하다.
만약, 하나의 애그리거트에 매우 많은 중첩 객체가 존재하면 어떻게 될까?

※ 애그리거트는 간략하게 말하자면, 같은 라이프 사이클을 가지는 관련된 객체들을 모아 하나의 단위로 취급하는 개념이다.

https://devlos.tistory.com/51#google_vignette

일반적으로 DDD에서는 하나의 애그리거트를 repository의 대상 엔티티로 삼는다.

Order라는 애그리거트가 존재할 때, 해당 애그리거트를 저장하고 로드하는 repository는 OrderRepository만 존재해야 한다는 소리다.

결국 해당 애그리거트에 포함되는 모든 entity와 value 들에 대해서 transaction consistency를 보장해야 하며, 컨버팅을 하느라 엄청난 시간을 쏟게 된다.

2. 휴먼 에러

위 컨버팅 문제와 직결된 문제인데, 아래 예시 코드에서 문제점을 찾아보자.

// domain pojo class
public class Order {
    private Long id;
    private String orderNum;
    private List<OrderItem> orderItems;
    private Long totalPrice;
    private String address;
    
    public Order(Long id, String orderNum, List<OrderItem> orderItems, Long totalPrice, String address) {
        this.id = id;
        this.orderNum = orderNum;
        this.orderItems = orderItems;
        this.totalPrice = totalPrice;
        this.address = address;
    }
    ...
}

위 코드는 domain의 Order이고, 아래는 infra의 Order이다.

// jpa entity class
@Entity
public class OrderEntity {
    @Id
    private Long id;
    private String orderNum;
    private List<OrderItem> orderItems;
    private Long totalPrice;
    
    public OrderEntity(Long id, String orderNum, List<OrderItem> orderItems, Long totalPrice) {
        this.id = id;
        this.orderNum = orderNum;
        this.orderItems = orderItems;
        this.totalPrice = totalPrice;
    }
    ...
}

Order객체에 address라는 필드가 추가되었는데, 누군가의 실수로 Entity에는 address가 없다.
이는 어쩌면 당연하겠지만 명시적으로 혹은 코드 상에서 domain과 infra의 연결이 분리되었기 때문에 발생하는 문제이다.
이를 컴파일 단에서 확인할 수 없으니 그만큼 안정성은 떨어질 수 있다.

3. 구현 기술의 강력한 기능 사용 불가

이 역시 컨버팅의 연장선이다.
Lazy Loading이나 Dirty Checking 같은 jpa에서 지원하는 기능은 영속성 계층에 의존하는 기능이다.
따라서 컨버팅 이후 해당 기능들을 사용할 수 없게 된다.

참고로 Aggregate에 대해서 Lazy Loading이 필요하지 않다고 보는 의견도 다수 존재한다.
aggregate에 value가 필요하면 한 번에 load 되어야 하고 필요하지 않으면 load 되지 않아야 하는데,
lazy loading이 필요하다는 것은 애그리거트의 설계가 잘못되었을 가능성이 있다는 말이다.

마무리

특정 기술에 의존하지 않는 순수한 도메인 모델 구조를 만들어봤다.
이 구조를 가지면 구현 기술이 변경되더라도 도메인이 받는 영향을 최소화할 수 있다.
하지만 구현 기술이 변경될 일이 잦을까..?
실제로 repository와 도메인 모델의 구현 기술은 거의 변경되지 않는다.
변경이 거의 없는 상황에서 변경을 미리 대비하는 것은 과하다고 생각할 수 있다.
물론 프로젝트의 요구사항이나 규모, 자원 등에 따라 다른 판단이 나올 수 있기 때문에 이 부분은 도메인 모델과 구현 기술을 완전히 분리하면서 얻는 이점과 개발 편의성과 실용성을 가져가면서 구조적인 유연함은 유지할 수 있도록 타협을 하는 것 중 선택해야 하는 문제라고 생각한다.

참고 자료 :
오픈 톡방
[DDD] Repository Pattern 이란, 이론편
[DDD] Repository Pattern - 실전편 (Spring 에서 DIP를 통해 Repository의 선언과 구현 분리시키기)

[Java] 자바가 Call by Value 방식인 이유

coco3o — Sat, 20 Apr 2024 19:42:33 +0900

Intro

프로그래밍을 하다 보면 함수 호출 방식인 'Call by Value'와 'Call by Reference' 키워드를 접하게 된다.

이 두 개념의 차이를 이해하고 특히 Java는 어떻게 'Call by Value' 방식을 사용하는지 알아보자

Call by Value / Call by Reference

Call by Value(값에 의한 호출)
- 값을 복사하여 처리한다.
- 변수의 복사본이 전달되며, 원래 값이 수정되지 않는다.
- 실제 인수는 다른 메모리 위치에 생성된다.
Call by Reference(참조에 의한 호출)
- 값의 주소를 참조하여 직접 값에 영향을 준다.
- 변수 자체가 전달되며, 원래 값이 수정된다.
- 실제 인수는 같은 메모리 위치에 생성된다.

자바의 Call by Value 동작 방식

자바의 데이터 타입은 다음과 같이 크게 두 가지로 나누어진다.

원시 타입(primitive type) - Numeric Type(byte, short, int, float, long, double, char), Boolean Type(boolean)
참조 타입(reference type) - Class Type, Interface Type, Array Type, Enum Type, 기타 참조 타입(String 등)

그래서 메소드 파라미터로 원시 타입을 전달하는 것과 참조 타입을 전달하는 것에는 동작 방식에 차이가 있다.

원시 타입(primitive type) 전달 방식

public class CallByExampleTest {

    @Test
    void primitiveTest() {
        int v = 10;
        
        add(v);
        
        assertThat(v).isEqualTo(10);
    }

    void add(int num) {
        num++;
    }
}

위 코드는 int 타입의 변수 v를 add 함수를 통해 1을 더해주고 있다.

하지만 결과 값은 여전히 10이다.

primitiveTest()의 v 변수와 add()의 num은 아예 연관 없는 변수이기 때문이다.

아래 그림으로 보면 한눈에 이해하기 쉬울 것이다.

자바에서 변수를 선언하면 기본적으로 Stack 메모리 영역에 할당된다.

Stack 영역 내부에 primitiveTest()와 add()의 영역이 각각 나뉘어 있고, 서로 다른 변수가 존재한다.

그래서 num 값에 1을 더해도 v 변수는 아무런 영향이 없다.

따라서 원시 타입의 전달은 값을 복사해서 전달하는 Call by Value 방식으로 동작한다는 것을 알 수 있다.

참조 타입(reference type) 전달 방식

참조 타입은 원시 타입과 조금 다르다.

변수는 Stack 영역에 생성되지만, 객체는 Heap 영역에 위치하며, Stack 영역에 있는 변수가 Heap 영역에 있는 객체를 바라보고 있는 형태다.

public class CallByExampleTest {

    @Test
    void referenceTest() {
        int[] arr = { 10 }; // 주소 : 0x001
        
        add(arr);

        assertThat(arr[0]).isEqualTo(11);
    }

    void add(int[] arrArg) {
        arrArg[0]++; // 주소 : 0x001
    }
}

변수의 참조(주소) 값을 복사해서 전달해 referenceTest() 영역과 add() 영역의 변수들은 모두 동일한 객체의 주소(0x001)를 바라보고 있다.

아래 단계별 그림을 보자.

add()에서 생긴 변수가 같은 주소 값을 참조하고 있기 때문에 값이 변경되었다.

결국 주소 값을 넘기고 원본 값이 변경되니까 Call by Reference 아닌가? 싶을 수 있지만,

자바의 참조와 Call by Reference의 참조는 약간 다른 의미를 가지고 있다.

자바에서 참조의 의미는 객체가 힙에 저장된 위치를 가리키는 메모리 주소이다.

실제 객체에 대한 참조가 아니라 객체에 접근하고 조작하는 방법이라고 볼 수 있다.

Call by Reference는 참조 자체를 넘기기 때문에 새로운 객체를 할당하면 원본 변수도 영향을 받는다.

다음 예시 코드를 보자.

public class CallByExampleTest {

    @Test
    void referenceTest() {
        int[] arr = { 10 }; // 0x001
        
        newArr(arr);

        assertThat(arr).isEqualTo("0x001");
    }

    void newArr(int[] arrArg) {
        arrArg = new int[]{ 20 }; // 0x002
    }
}

전달받은 값을 새로운 객체로 변경해도 원본 변수는 변하지 않는다.

따라서 참조 타입 역시 Call by Value 방식으로 동작함을 보여준다.

newArr()가 종료되고 사용되지 않는 객체(0x002)는 Garbage Collector에 의해 수거될 것이다.

결국 자바는 항상 Call by Value 방식으로 데이터를 전달하고, 핵심은 호출자 변수와 수신자 파라미터는 Stack 영역 내에서 각각 독립적으로 존재하는 다른 변수라는 것이다.

참고 자료

VisualVM Remote 연결로 JVM 메모리 사용량 모니터링 하기

coco3o — Wed, 21 Feb 2024 20:17:35 +0900

VisualVM은 JVM 기반 애플리케이션의 성능을 실시간으로 분석하기 위해 주로 사용하는 오픈소스 기반의 GUI 툴이다.

운영 환경

VisualVM - 2.1.7

OpenJDK - 11.0.21

Linux - CentOS7

WAS - Apache Tomcat 9.0.54

VisualVM 다운로드

JDK 1.7 이상의 경우 JAVA_HOME/bin 밑에 jvjsualvm.exe 파일이 포함 되어 있다.

별도로 필요할 경우 아래 링크를 통해 다운로드 받자.

https://visualvm.github.io/

VisualVM 간단 설명

Local
- 현재 로컬 컴퓨터에 JVM으로 돌아가는 Application 목록 및 pid
Remote
- 로컬 컴퓨터가 아닌 다른 서버에 있는 Application 목록 및 pid
VM CoreDumps
- 코어덤프 파일을 열어둔 목록 및 pid
Snapshots
- Application 데이터의 스냅샷 파일 목록

VisualVM 원격 연결 방법

1. setenv.sh 파일을 생성하여 JMX Remote 설정을 추가한다.

vi setenv.sh

# !/bin/bash

CATALINA_OPTS="-Dcom.sun.management.jmxremote=true \
-Dcom.sun.management.jmxremote.port=1099 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Djava.rmi.server.hostname=127.0.0.1"

-Dcom.sun.management.jmxremote=true \
- 모니터링 활성화
-Dcom.sun.management.jmxremote.port=[port] \
- JMX 원격 접속을 위한 포트 설정
-Dcom.sun.management.jmxremote.ssl=false \
- SSL 접속 설정
-Dcom.sun.management.jmxremote.authenticate=false \
- 접속 인증 설정 (활성화시 인증 관련 추가 설정 필요)
-Djava.rmi.server.hostname=[ip]
- 원격지 ip

2. 설정한 port 번호는 아래 명령어로 연결 허용 여부를 판단해야 한다.

natstat -anl | grep [port]

만약 막혀 있다면 iptables 설정으로 port를 열어줘야 한다

# 1099 port 허용
iptables -I INPUT -p tcp --dport 1099 -j ACCEPT
# 추가한 설정 조회
iptables -nL
# 정책 저장
service iptables save
# iptables 재시작
service iptables restart

3. Tomcat을 구동한다.

4. VisualVM에서 Remote > Add Remote Host... 입력창이 뜨면 원격지의 IP를 입력

5. 등록한 Host > Add JMX Connection... 입력창이 뜨면 JVM 등록시 설정한 port 입력한 후 OK

6. 완료

HATEOAS까지 사용해야 완벽한 RESTful이다.

coco3o — Sat, 16 Dec 2023 17:15:23 +0900

나는 지금까지 REST API는 URI는 정보의 자원만 표현하고, 자원의 행위는 HTTP Method를 통해 명시한다는 것으로만 알고 사용하고 있었다.
위 내용도 물론 맞지만, 그건 반쪽짜리 REST API 였고, HATEOAS까지 알고 사용해야 진정한 REST API를 사용한다 할 수 있다.
그래서 이번엔 HATEOAS가 뭐고 어떤 특징이 있는지 알아보려 한다.

HATEOAS (Hypermidia As The Engine Of Application State)

HATEOAS(일명 헤이티오스)는 API를 실제로 "RESTful"하게 만드는 REST Appilcation Architecture의 제약 조건이다.
기본적으로 요청에 대해 서버는 응답에 데이터만 클라이언트에게 보내는데,
HATEOAS를 사용하면 응답에 데이터뿐만 아니라 해당 데이터와 관련된 요청에 필요한 URI를 응답에 포함하여 반환하며, 이는 REST API를 사용하는 클라이언트가 전적으로 서버와 동적인 상호작용이 가능하도록 해준다.

REST API 구현 단계

REST API를 구현하기 위한 단계가 존재하는데, 마지막 단계가 Hypermedia Controls - HATEOAS라는 개념을 통해서 자원에 호출 가능한 API 정보를 자원의 상태를 반영하여 표현하는 것이다.

https://grapeup.com/blog/how-to-build-hypermedia-api-with-spring-hateoas/#

레벨 0
HTTP 프로토콜을 사용하여 API를 구현하지만 모든 기능을 활용하지는 않는다. 또한 리소스에 대한 고유 주소는 제공되지 않는다.
method: POST URI: /movie
레벨 1
리소스에 대한 고유 식별자가 있지만 리소스에 대한 각 작업에는 고유한 URL이 있다.
method: POST URI: /movie/1/delete
레벨 2
동작을 설명하는 동사 대신 HTTP 메소드를 사용한다.
method: DELETE URI: /movie/1
레벨 3
HATEOAS가 도입되었다. 간단히 말해서 리소스에 하이퍼미디어를 도입하며, 이를 통해 가능한 작업에 대해 알려주는 응답에 링크를 배치할 수 있으므로 API를 통해 탐색할 수 있는 가능성이 추가된다.
method: DELETE URI: /movie/1

요즘 대부분의 프로젝트는 레벨 2를 사용하여 작성된다. 하지만 완벽한 RESTful API를 원한다면 HATEOAS를 고려해야 한다.

HATEOAS를 사용한 REST API 응답 형태

예를 들어, 게시글을 조회하는 URI가 있다고 가정해보자.

GET https://my-test-server.com/articles

기존 REST API application/json 응답 형태

{
    "id": 100,
    "subject": "게시글 100",
    "content": "내용",
    "self": "https://my-test-server.com/api/v1/articles/100"
}

여기서 해당 글을 조회한 사용자는 다음으로 어떤 행동을 할 수 있을까?

다음 게시글 조회
좋아요
댓글 달기
홈 이동

이런 행동들이 바로 상태 전이(State Transition)가 가능한 것들인데, 이것들을 응답 본문에 넣어줘야 한다는 소리다.

{
    "id": 100,
    "subject": "게시글 100",
    "content": "내용",
    "self": "https://my-test-server.com/api/articles/100",
    "next": "https://my-test-server.com/api/articles/101",
    "like": "https://my-test-server.com/api/articles/likes",
    "comment":"https://my-test-server.com/api/articles/100/comments",
    "home": "https://my-test-server.com/"
}

위와 같이 Hypermedia(링크)를 통해서 넣어주면, 클라이언트는 현재의 리소스에서 가능한 액션을 하이퍼미디어 링크를 참조하여 알 수 있고, 이를 따라가며 상태 전이를 쉽게 진행할 수 있다.

하지만 아직 진정한 REST API라고는 할 수 없으며,

다음과 같이 링크와 관련된 리소스의 관계를 명확히 표현하는 표준적인 방법을 제공한다.

HAL

Hypertext Application Language으로 JSON, XML 코드 내의 외부 리소스에 대한 링크를 추가하기 위한 특별한 데이터 타입이다.
이 HAL 타입을 이용한다면 쉽게 HATEOAS를 달성할 수 있으며, 두 가지의 특징만 이용하면 된다.
1. 리소스 : 일반적인 데이터 필드에 해당한다.
2. 링크 : 하이퍼미디어로 보통 _self 필드가 링크 필드가 된다.

application/hal+json HATEOAS 응답 형태

{
    ~리소스 영역~
    "id": 100,
    "subject": "게시글 100",
    "content": "내용"
    ~리소스 영역~
    
    ~링크 영역~
    "_links" : {
        "self": {
            "href": "https://my-test-server.com/api/articles/100"
        },
        "next": {
            "href": "https://my-test-server.com/api/articles/101"
        },
        "like": {
            "href": "https://my-test-server.com/api/articles/likes"
        },
        "comment": {
            "href": "https://my-test-server.com/api/articles/100/comments" 
        },
        "home": {
            "href": "https://my-test-server.com/"
        }
    }
    ~링크 영역~
}

HATEOAS를 사용하여 얻게 되는 가장 큰 장점은 서버와 클라이언트를 분리한다는 것이다.
클라이언트는 서버의 상태와 행동을 알 필요가 없으며, 서버 측의 변경에도 클라이언트에선 일일이 대응하지 않아도 된다.

마무리

이로써 우리는 HATEOAS로 보다 RESTful 한 API를 작성하는 방법을 배웠다.
하지만 모든 공공기관 또는 기업에서 사용하지 않는 것처럼 반드시 HATEOAS를 사용해야 하는 것은 아니다.
적재적소에 맞는 REST API를 설계하여 사용하는 게 더욱 중요하며, HATEOAS는 필요에 따라 적절히 사용하도록 하자.

참고
https://wonit.tistory.com/454
https://grapeup.com/blog/how-to-build-hypermedia-api-with-spring-hateoas/#

[Spring] ThreadPoolTaskExecutor 설정으로 비동기 처리 효과적으로 하기

coco3o — Tue, 5 Dec 2023 19:46:14 +0900

이전 글에 이어서 Spring Boot에서 ThreadPoolTaskExecutor 설정을 통해 비동기 처리를 효율적으로 수행하는 방법을 알아보려 한다.

ThreadPoolTaskExecutor

ThreadPoolTaskExecutor는 Spring에서 제공해주는 클래스로 자바에서 제공하는 ThreadPoolExecutor를 사용하기 쉽게 만들어 사용하도록 구현 되어 있어 스레드 풀을 쉽고 간단하게 설정하고 관리할 수 있다.

java.util.concurrent Executor를 최상위 인터페이스로 가진다.

Bean 등록

우선 ThreadPoolTaskExecutor를 사용하기 위해 Bean으로 등록한다.

@Configuration
public class ThreadPoolConfig {

    @Bean(name = "taskExecutor")
    public Executor taskExecutor() {
        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
        taskExecutor.initialize();

        return taskExecutor;
    }
}

ThreadPoolTaskExecutor를 생성하고 사용할 수 있도록 initialize()를 호출했다.

※ 명시적으로 적지 않아도 빈으로 등록될 때 initialize()한다.

Thread 설정

private static final int CORE_POOL_SIZE = 10;
private static final int MAX_POOL_SIZE = 30;

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
    taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
    taskExecutor.initialize();

    return taskExecutor;
}

setCorePoolSize
- 동시에 실행 할 기본 스레드의 수를 설정할 수 있다.
- 기본 값은 1이다.
setMaxPoolSize
- thread-pool의 사용할 수 있는 최대 스레드 수를 설정할 수 있다.
- 기본 값은 Integer.MAX_VALUE 이다.

최초 설정한 스레드의 수만큼 작업하다 더 이상 처리할 수 없을 경우 max size 만큼 스레드가 증가하겠지? 라고 예상할 수 있지만, 실제로는 그렇지 않다.

설정한 core size보다 많은 작업 요청이 들어오면 ThreadPoolTaskExecutor는 내부적으로 Integer.MAX_VALUE 만큼 LinkedBlockingQueue를 생성하고 task는 queue에서 대기하게 된다.

그리고 queue가 꽉 차게 되면 그 때 max size 만큼 스레드를 생성하여 task를 처리한다.

QueueCapacity

core size보다 많은 요청이 들어오면 Integer.MAX_VALUE 만큼 queue를 생성한다 했는데 이는 기본 설정 값이며,

작업에 맞게 queueCapacity 사이즈를 변경하여 사용할 수 있다.

private static final int CORE_POOL_SIZE = 10;
private static final int MAX_POOL_SIZE = 30;
private static final int QUEUE_CAPACITY = 100;

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
    taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
    taskExecutor.setQueueCapacity(QUEUE_CAPACITY);
    taskExecutor.initialize();

    return taskExecutor;
}

setQueueCapacity
- thread-pool executor의 작업 큐의 크기를 설정할 수 있다.
- 기본 값은 Integer.MAX_VALUE 이다.

위와 같이 설정하면 최초 10개의 스레드에서 처리하다가 처리 속도가 밀릴 경우 100개 사이즈의 큐에서 대기하고 그보다 많은 요청이 발생하면 최대 30개의 스레드를 생성해서 처리한다.

RejectedExecutionHandler

max size만큼 스레드를 생성하고, 설정한 queue가 가득 찬 상태에서 추가 작업이 들어올 경우 RejectedExecutionException 예외가 발생하게 된다.

더 이상 처리할 수 없다는 오류인데, 기본적으로 RejectedExecutionHandler 인터페이스를 구현한 몇 가지 클래스가 제공되며 이러한 예외가 발생하지 않도록 우리는 다음과 같이 설정하여 해결할 수 있다.

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
    taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
    taskExecutor.setQueueCapacity(QUEUE_CAPACITY);
    taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    taskExecutor.initialize();

    return taskExecutor;
}

ThreadPoolExecutor.AbortPolicy
- 기본 설정 값이다.
- reject 발생시 RejectedExecutionException을 발생시킨다.
ThreadPoolExecutor.CallerRunsPolicy
- shutdown 상태가 아닐 때, ThreadPoolTaskExecutor에 요청한 스레드에서 직접 처리한다.
ThreadPoolExecutor.DiscardPolicy
- reject된 작업을 무시한다.
- 모든 작업이 처리 될 필요가 없을 경우 사용한다.
ThreadPoolExecutor.DiscardOldsetPolicy
- 오래된 작업을 제거하고 reject된 작업을 실행시킨다.
- 역시 모든 작업이 처리 될 필요가 없을 경우 사용한다.

예외와 작업의 누락 없이 모두 처리하려면 CallerRunsPolicy로 설정하여 사용하자.

Shutdown

위와 같이 별도로 정의한 스레드 풀에서 작업이 이루어지고 있을 때 어플리케이션 종료를 요청하게되면 어플리케이션이 바로 종료된다. 이렇게 되면 아직 처리되지 못한 작업들은 유실되기 때문에 다음과 같이 설정하면 작업 유실을 방지할 수 있다.

private static final int CORE_POOL_SIZE = 30;
private static final int MAX_POOL_SIZE = 50;
private static final int QUEUE_CAPACITY = 100;
private static final boolean WAIT_TASK_COMPLETE = true;

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
    taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
    taskExecutor.setQueueCapacity(QUEUE_CAPACITY);
    taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    taskExecutor.setWaitForTasksToCompleteOnShutdown(WAIT_TASK_COMPLETE);
    taskExecutor.initialize();

    return taskExecutor;
}

setWaitForTasksToCompleteOnShutdown
- true 설정시 어플리케이션 종료 요청시 queue에 남아 있는 모든 작업들이 완료될 때까지 기다린 후 종료된다.

Timeout

만약 모든 작업이 처리되길 기다리기 힘든 경우라면 setAwaitTerminationSeconds 설정을 통해 최대 종료 대기 시간을 설정할 수 있다.

private static final int CORE_POOL_SIZE = 30;
private static final int MAX_POOL_SIZE = 50;
private static final int QUEUE_CAPACITY = 100;
private static final boolean WAIT_TASK_COMPLETE = true;
private static final int AWAIT_TERMINATION_SECONDS = 30;

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
    taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
    taskExecutor.setQueueCapacity(QUEUE_CAPACITY);
    taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    taskExecutor.setWaitForTasksToCompleteOnShutdown(WAIT_TASK_COMPLETE);
    taskExecutor.setAwaitTerminationSeconds(AWAIT_TERMINATION_SECONDS);
    taskExecutor.initialize();

    return taskExecutor;
}

ThreadName

private static final int CORE_POOL_SIZE = 30;
private static final int MAX_POOL_SIZE = 50;
private static final int QUEUE_CAPACITY = 100;
private static final String THREAD_NAME_PREFIX = "executor-";
private static final boolean WAIT_TASK_COMPLETE = true;
private static final int AWAIT_TERMINATION_SECONDS = 30;

@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
    taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
    taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
    taskExecutor.setQueueCapacity(QUEUE_CAPACITY);
    taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    taskExecutor.setWaitForTasksToCompleteOnShutdown(WAIT_TASK_COMPLETE);
    taskExecutor.setAwaitTerminationSeconds(AWAIT_TERMINATION_SECONDS);
    taskExecutor.setThreadNamePrefix(THREAD_NAME_PREFIX);
    taskExecutor.initialize();

    return taskExecutor;
}

setThreadNamePrefix
- 스레드의 이름을 설정한다.

ThreadPoolTaskExecutor 동작 원리

여기까지 내용을 복기하며 ThreadPoolTaskExecutor의 동작 원리를 생각 해보자.

현재 점유하고 있는 스레드의 수가 corePoolSize만큼 있고, 추가 요청이 오면 LinkedBlockingQueue를 생성하고, 요청을 큐에 넣는다.
queue에 담긴 요청이 queueCapacity의 수만큼 있을 때 요청이 오면 maxPoolSize 만큼 스레드를 생성하여 처리한다.
현재 점유하고 있는 스레드의 수가 maxPoolSize 만큼 있고, 큐에 담긴 요청이 queueCapacity의 수 만큼 있을 때 추가 요청이 오면 RejectedExecution 전략에 따라 처리된다.

ThreadPoolTaskExecutor 사용법

1. Executor의 execute()

다음과 같이 Executor를 주입한 뒤 처리하고자 하는 작업을 Runnable 인터페이스의 run()메소드에 정의하고,

Executor.execute()의 인자로 넘겨주면 된다.

@Slf4j
@Service
public class TestService {

    private final Executor executor;

    public TestService(@Qualifier("taskExecutor") Executor executor) {
        this.executor = executor;
    }

    public void executeThreads() {
        Runnable runnable = () -> {
            try {
                log.info("executing Thread Name .. [{}]", Thread.currentThread().getName());
                Thread.sleep(1000); // 1초간 정지
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        };

        for (int i = 0; i < 10; i++) {
            executor.execute(runnable);
        }
    }
}

19:26:42.247 [INFO ] [executor-9] com.coco.demo.TestService - executing Thread Name .. [executor-9]
19:26:42.248 [INFO ] [executor-8] com.coco.demo.TestService - executing Thread Name .. [executor-8]
19:26:42.250 [INFO ] [executor-10] com.coco.demo.TestService - executing Thread Name .. [executor-10]
19:26:42.250 [INFO ] [executor-7] com.coco.demo.TestService - executing Thread Name .. [executor-7]
19:26:42.251 [INFO ] [executor-6] com.coco.demo.TestService - executing Thread Name .. [executor-6]
19:26:42.251 [INFO ] [executor-5] com.coco.demo.TestService - executing Thread Name .. [executor-5]
19:26:42.251 [INFO ] [executor-4] com.coco.demo.TestService - executing Thread Name .. [executor-4]
19:26:42.251 [INFO ] [executor-3] com.coco.demo.TestService - executing Thread Name .. [executor-3]
19:26:42.251 [INFO ] [executor-2] com.coco.demo.TestService - executing Thread Name .. [executor-2]
19:26:42.252 [INFO ] [executor-1] com.coco.demo.TestService - executing Thread Name .. [executor-1]

2. CompletableFuture

CompletableFuture의 xxxAsync가 붙은 메소드는 기본적으로 ForkJoinPool의 commonPool을 사용하며,
두 번째 인수를 받는 오버로드 메소드에서 커스텀한 Thread Executor를 사용할 수 있다.

public void executeThreads() {
    CompletableFuture<Void> cf = null;

    for(int i = 0; i < 10; i++){
        cf = CompletableFuture.runAsync(() -> {
        try {
            log.info("executing Thread Name .. [{}]", Thread.currentThread().getName());
            Thread.sleep(1000); // 1초간 정지
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        }, executor);
    }

    cf.join();
}

19:37:16.229 [INFO ] [executor-2] com.coco.demo.TestService - executing Thread Name .. [executor-2]
19:37:16.229 [INFO ] [executor-1] com.coco.demo.TestService - executing Thread Name .. [executor-1]
19:37:16.229 [INFO ] [executor-5] com.coco.demo.TestService - executing Thread Name .. [executor-5]
19:37:16.229 [INFO ] [executor-6] com.coco.demo.TestService - executing Thread Name .. [executor-6]
19:37:16.229 [INFO ] [executor-4] com.coco.demo.TestService - executing Thread Name .. [executor-4]
19:37:16.230 [INFO ] [executor-8] com.coco.demo.TestService - executing Thread Name .. [executor-8]
19:37:16.230 [INFO ] [executor-7] com.coco.demo.TestService - executing Thread Name .. [executor-7]
19:37:16.230 [INFO ] [executor-10] com.coco.demo.TestService - executing Thread Name .. [executor-10]
19:37:16.230 [INFO ] [executor-9] com.coco.demo.TestService - executing Thread Name .. [executor-9]

참고

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/scheduling/concurrent/ThreadPoolTaskExecutor.html

https://kapentaz.github.io/spring/Spring-ThreadPoolTaskExecutor-%EC%84%A4%EC%A0%95/#

[Java] CompletableFuture 사용법

coco3o — Mon, 27 Nov 2023 20:44:06 +0900

Future

Java5부터 사용되던 Future 인터페이스는 java.util.concurrency 패키지에서 비동기 작업의 결과 값을 받는 용도로 사용했다. 하지만 여러 Future의 결괏값을 조합하거나, 예외를 효과적으로 핸들링할 수가 없었다.

그리고 Future는 오직 get 호출로만 작업 완료가 가능한데, get은 작업이 완료될 때까지 대기하는 블로킹호출이므로 비동기 작업 응답에 추가 작업을 하기 적합하지 않다.

public interface Future<V> {
    ...
    V get() throws InterruptedException, ExecutionException;

    V get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException;
}

get() - 작업이 완료될 때까지 대기
get(long timeout, TimeUnit unit) - 작업이 완료될 때까지 설정한 시간 동안 대기하며, 시간 내 작업 미완료 시 TimeoutException 발생

CompletableFuture

Java8에서는 이러한 문제들을 모두 해결한 CompletableFuture가 소개되었다.

public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {
    ...
}

CompletableFuture 클래스는 Future 인터페이스를 구현함과 동시에 CompletionStage 인터페이스를 구현한다.

CompletionStage의 특징을 살펴보면 CompletableFuture의 장점을 알 수 있다.

CompletionStage는 결국은 계산이 완료될 것이라는 의미의 약속이다.

계산의 완료는 단일 단계의 완료뿐만 아니라 다른 여러 단계 혹은 다른 여러 단계 중의 하나로 이어질 수 있음도 포함한다.

또한, 각 단계에서 발생한 에러를 관리하고 전달할 수 있다.

※ 비동기 연산 Step을 제공해서 체이닝 형태로 조합이 가능하며, 완료 후 콜백이 가능하다.

기본적인 사용 방법

- runAsync

반환 값이 없는 경우 비동기 작업 실행

CompletableFuture<Void> cf = CompletableFuture.runAsync(() -> System.out.println("Hello World!"));
cf.join(); // Hello World!

runAsync()는 Runnable 타입을 파라미터로 전달하기 때문에 어떤 결과 값을 담지 않는다.

- supplyAsync

반환 값이 있는 경우 비동기 작업 실행

CompletableFuture<String> cf = CompletableFuture.supplyAsync(() ->  "Hello World!");
System.out.println(cf.join()); // Hello World!

반면, supplyAsync()는 supplier 타입을 넘기기 때문에 반환 값이 존재한다.

또한, 결과를 get() 또는 join() 메소드로 가져올 수 있는데 각 차이점은 다음과 같다.

get() - Future 인터페이스에 정의된 메소드로 checked exception인 InterruptedException과 ExecutionException을 던지므로 예외 처리 로직이 반드시 필요하다.
join() - CompletableFuture에 정의되어 있으며, checked exception을 발생시키지 않는 대신 unchecked CompletionException이 발생된다.

일반적으로 join()을 사용하는 것이 권장되지만, 예외 처리에 대한 추가 로직이 필요할 때 혹은 timeout 설정을 해야 하는 경우 get()을 사용하자.

runAsync와 supplyAsync는 기본적으로 ForkJoinPool의 commonPool()을 사용해 작업을 실행한 스레드를 스레드 풀로부터 얻어 실행시킨다. 만약 원하는 스레드 풀을 사용하려면, ExecutorService를 파라미터로 넘겨주면 된다.

작업 콜백

비동기 실행이 끝난 후에 다음과 같이 체이닝 형태로 작성하여 전달 받은 작업 콜백을 실행시켜 준다.

- thenApply

함수형 인터페이스 Function 타입을 파라미터로 받으며, 반환 값을 받아서 다른 값을 반환해주는 콜백이다.

thenApply는 앞선 계산의 결과를 콜백 함수로 전달된 Function을 실행한다.

CompletableFuture<String> cf = CompletableFuture.supplyAsync(() -> {
    return "hello world!";
}).thenApply(s -> {
    return s.toUpperCase();
});
System.out.println(cf.join()); // HELLO WORLD!

- thenAccept

함수형 인터페이스 Consumer를 파라미터로 받으며, 반환 값을 받아 처리하고 값을 반환하지 않는 콜백이다.

CompletableFuture<Void> cf = CompletableFuture.supplyAsync(() -> {
    return "hello world!";
}).thenAccept(System.out::println);

cf.join(); // hello world!

- thenRun

함수형 인터페이스 Runnable을 파라미터로 받으며, 반환 값을 받지 않고 그냥 다른 작업을 처리하고 값을 반환하지 않는 콜백이다.

CompletableFuture<Void> cf = CompletableFuture.supplyAsync(() -> {
    return "hello world!";
}).thenRun(() -> System.out.println("hello coco world!"));

cf.join(); // hello coco world!;

비동기 작업 콜백

- thenApplyAsync

앞선 계산의 결과를 콜백 함수로 전달된 Function을 별도의 스레드에서 비동기적으로 실행한다.

CompletableFuture<String> cf = CompletableFuture.supplyAsync(() -> {
    return "hello world!";
}).thenApplyAsync(s -> {
    return s.toUpperCase();
});
System.out.println(cf.join()); // HELLO WORLD!

- thenAcceptAsync

앞선 계산의 결과를 콜백 함수로 전달된 Consumer를 별도의 스레드에서 비동기적으로 실행한다.

CompletableFuture<Void> cf = CompletableFuture.supplyAsync(() -> {
    return "hello world!";
}).thenAcceptAsync(System.out::println);

cf.join(); // hello world!

- thenRunAsync

앞선 계산의 결과와 상관없이 주어진 작업을 별도의 스레드에서 비동기적으로 실행한다.

CompletableFuture<Void> cf = CompletableFuture.supplyAsync(() -> {
    return "hello world!";
}).thenRunAsync(() -> System.out.println("hello coco world!"));

cf.join(); // hello coco world!

※ xxxAsync가 붙은 메소드는 기본적으로 ForkJoinPool의 commonPool을 사용하며,
두 번째 인수를 받는 오버로드 메소드에서 다른 Thread Executor를 선택적으로 사용할 수도 있다.

비동기 작업 콜백 메소드들은 주로 병렬로 수행되는 작업이나 I/O 작업과 같이 시간이 오래 걸리는 작업을 할 때 유용하게 활용된다.

다른 비동기 작업과 조합하기

- thenCompose

두 작업을 이어서 실행하도록 조합하며, 앞선 작업의 결과를 받아서 사용할 수 있다.

함수형 인터페이스 Function을 파라미터로 받는다.

CompletableFuture<String> hello = CompletableFuture.supplyAsync(() -> {
    return "Hello";
});

CompletableFuture<String> helloWorld = hello.thenCompose(this::world);

System.out.println(helloWorld.join()); // Hello World!



private CompletableFuture<String> world(String message) {
    return CompletableFuture.supplyAsync(() -> {
        return message + " " + "World!";
    });
}

- thenCombine

각 작업을 독립적으로 실행하고, 모두 완료되었을 때 결과를 받아서 사용할 수 있다.

함수형 인터페이스 Function을 파라미터로 받는다.

CompletableFuture<String> hello = CompletableFuture.supplyAsync(() -> {
    return "Hello";
});

CompletableFuture<String> world = CompletableFuture.supplyAsync(() -> {
    return "World!";
});

CompletableFuture<String> cf = hello.thenCombine(world, (h, w) -> h + " " + w);
System.out.println(cf.join()); // Hello World!

- allOf

여러 작업들을 동시에 실행하고, 모든 작업 결과에 콜백을 실행한다.

CompletableFuture<String> hello = CompletableFuture.supplyAsync(() -> {
    return "Hello";
});

CompletableFuture<String> world = CompletableFuture.supplyAsync(() -> {
    return "World!";
});

List<CompletableFuture<String>> futures = List.of(hello, world);
CompletableFuture<List<String>> result = CompletableFuture.allOf(futures.toArray(new CompletableFuture[futures.size()]))
        .thenApply(v -> futures.stream()
                .map(CompletableFuture::join)
                .collect(Collectors.toList()));

System.out.println(result.join()); // [Hello, World!]
result.join().forEach(System.out::println);
// Hello
// World!

- anyOf

여러 작업들 중에 가장 빨리 끝난 하나의 결과에 콜백을 실행한다.

CompletableFuture<String> hello = CompletableFuture.supplyAsync(() -> {
    try {
        Thread.sleep(100);
    } catch (InterruptedException e) {}

    return "Hello";
});

CompletableFuture<String> world = CompletableFuture.supplyAsync(() -> {
    return "World!";
});

CompletableFuture<Void> anyOfFuture = CompletableFuture.anyOf(hello, world)
        .thenAccept(System.out::println);

anyOfFuture.join(); // World!

에러 핸들링

Future에서 에러 핸들링 할 수 없던 문제를 CompletableFuture는 어떻게 해결했는지 알아보자.

- exceptionally

발생한 에러를 받아서 예외를 처리한다.

함수형 인터페이스 Function을 파라미터로 받는다.

CompletableFuture<String> cf = CompletableFuture.supplyAsync(() -> {
    int divisionByZero = 2 / 0;
    return "success";
}).exceptionally(e -> { // e is wrapped with CompletionException
    return e.toString();
});

System.out.println(cf.join()); // java.util.concurrent.CompletionException: java.lang.ArithmeticException: / by zero

- handle

(결과값, 에러)를 반환받아 에러가 발생한 경우와 아닌 경우 모두를 처리할 수 있다.

함수형 인터페이스 BiFunction을 파라미터로 받는다.

CompletableFuture<String> cf = CompletableFuture.supplyAsync(() -> {
    int divisionByZero = 2 / 0;
    return "success";
}).handle((result, e) -> { // e is wrapped with CompletionException
    return e == null ? result : e.toString();
});;

System.out.println(cf.join()); // java.util.concurrent.CompletionException: java.lang.ArithmeticException: / by zero

여기까지 비동기 처리를 위한 CompletableFuture 사용 방법에 대해 알아보았고, 다음 글에 이어서 ThreadPoolTaskExecutor 설정으로 보다 효과적으로 비동기 처리 하는 방법을 알아보도록 하자.

참고

https://stackoverflow.com/questions/45490316/completablefuturet-class-join-vs-get

https://mangkyu.tistory.com/263

https://devidea.tistory.com/34

[Error] Failed to parse multipart servlet request; nested exception is java.lang.IllegalStateException: The multi-part request contained parameter data (excluding uploaded files) that exceeded the limit for maxPostSize set on the associated connector

coco3o — Fri, 10 Nov 2023 16:17:21 +0900

Multi-part POST 요청을 하는 코드에서 다음과 같은 에러가 발생했다.

Failed to parse multipart servlet request; nested exception is java.lang.IllegalStateException: The multi-part request contained parameter data (excluding uploaded files) that exceeded the limit for maxPostSize set on the associated connector

원인 분석

해당 에러는 멀티파트 요청 파라미터의 제한된 데이터 크기를 초과한 요청을 했을 때 발생하는 에러였고,
프로젝트엔 다음과 같이 멀티파트 관련 설정이 적용되어 있는 상황이었다.

server:
  servlet:
    multipart:
      max-file-size: 30MB
      max-request-size: 30MB

위 설정을 초과한 요청을 보내는지 확인해 봤는데 요청 데이터 크기는 2194344바이트(2.19MB)였다.
왜 설정 용량에 한참 못 미치는 요청에 대해 에러가 발생했는지 찾아보았다.

알고보니 max-file-size 설정은 요청 파일 하나당 허용 사이즈이고,
max-request-size 설정은multipart/form-data 요청에서 전체 파일의 허용 사이즈였다.

~~max-request-size가 전체 데이터~~ 요청 ~~사이즈 설정인줄..~~

즉, 위 속성은 파일 업로드와 관련된 설정이었고, 나는 파일을 포함한 http form 데이터 크기가 초과되어 에러가 발생한 것이었다.

문제 해결

다음과 같이 tomcat의 max-http-form-post-size 속성을 추가했다.

server:
  tomcat:
    max-http-form-post-size: 10MB

※ Spring Boot 2.1.x 버전부터 server.tomcat.max-http-post-size > server.tomcat.max-http-form-post-size로 변경됨

max-http-form-post-size는 파일을 포함한 전체 데이터 요청의 허용 사이즈를 설정하며, 기본 설정 값은 2MB이다.

설정 후 테스트 해보니 정상적으로 처리되었고, 기분 좋게 운영 서버에 반영하니 다시 같은 에러가 발생했다.
tomcat server.xml 외부 설정이 Spring boot application의 내부 설정을 덮어씌우는 것 같았고, ~~(뇌피셜)~~
tomcat/config server.xml안에 있는 Connector 태그에 아래 속성을 추가한 뒤 tomcat을 재시작하니 해결되었다.

<Connector ... maxPostSize="10000000" />

maxPostSize는 바이트 단위로 설정할 수 있고, "-1"으로 설정시 제한을 비활성화할 수 있으며, Tomcat 7.0.63 이전 버전은 "0"으로 설정해야 한다.

주의

server.xml에는 세 가지 Connector 태그가 존재하며, 사용하고 있는 방식에 맞는 태그에 속성을 추가해야 한다.
1. 기본(8080)
2. SSL(443)
3. AJP(아파치와 연동: 8009)

<Connector port="8080" ... /> 
<Connector SSLEnabled="true" protocol="HTTP/1.1" ... /> 
<Connector port="8009" protocol="AJP/1.3" ... />

예를 들어 SSL(443) 설정을 한 후 443 포트를 이용하여 통신(Submit) 하고 있는데, 기본(8080) 커넥터에만 설정한 경우 설정 값이 적용되지 않음에 주의해야 한다.

reference :
https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/autoconfigure/web/servlet/MultipartProperties.html
https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.server.server.tomcat.max-http-form-post-size
https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#HTTP/1.1_and_HTTP/1.0_Support
https://jiurinie.tistory.com/133

[Java] 병렬 스트림(ParallelStream) 사용 방법 및 주의사항

coco3o — Mon, 6 Nov 2023 20:46:15 +0900

ParallelStream

Java8에서 등장한 Stream은 병렬 처리를 쉽게 할 수 있도록 메소드를 제공해 준다.
개발자가 직접 스레드 혹은 스레드풀을 생성하거나 관리할 필요 없이 parallelStream(), parallel()만 사용하면 알아서 ForkJoinFramework 관리 방식을 이용하여 작업들을 분할하고, 병렬적으로 처리하게 된다.

Fork / Join Framework

Fork / Join Framework는 작업들을 분할 가능한 만큼 쪼개고, 쪼개진 작업들을 Work Thread를 통해 작업 후 결과를 합치는 과정으로 결과를 만들어 낸다.
즉, 분할 정복(Divide and Conquer) 알고리즘과 흡사하며, Fork를 통해 Task를 분담하고 Join을 통해 결과를 합친다.

Fork / Join Framework의 중심은 AbstractExecutorService 클래스를 확장한 ForkJoinPool이다.

ForkJoinPool을 알아보기 위해 JavaDoc에서 일부 발췌한 내용이다.

An ExecutorService for running ForkJoinTasks. A ForkJoinPool provides the entry point for submissions from non-ForkJoinTask clients,

as well as management and monitoring operations. A ForkJoinPool differs from other kinds of ExecutorService mainly by virtue of employing work-stealing: all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks
(eventually blocking waiting for work if none exist). This enables efficient processing when most tasks spawn other subtasks (as do most ForkJoinTasks), as well as when many small tasks are submitted to the pool from external clients. Especially when setting asyncMode to true in constructors, ForkJoinPools may also be appropriate for use with event-style tasks that are never joined.

위 내용을 정리하면 다음과 같다.

다른 종류의 ExecutorService와는 다르게 Work-Stealing 메커니즘을 사용한다.
이를 통해 대부분의 Task가 하위 Task를 생성하는 경우, 외부 클라이언트에 의한 Small Task가 많을 경우 효과적일 수 있다.

http://www.h-online.com/developer/features/The-fork-join-framework-in-Java-7-1762357.html

1. task를 보낸다. (submit)
2. inbound queue에 task가 들어가고, A와 B 스레드가 가져다가 task를 처리한다.
3. A와 B는 각자 큐가 있으며, 위 그림의 B처럼 큐에 task가 없으면 A의 task를 steal 하여 처리한다.

work-stealing 메커니즘을 사용하기 때문에 CPU 자원이 놀지 않고 최적의 성능을 낼 수 있게 된다.

스레드 자신의 task queue로 deque를 사용한다. deque는 양 쪽 끝으로 넣고 뺄 수 있는 구조이며,
각 스레드는 deque의 한쪽 끝에서만 일하고 나머지 반대쪽에서는 task를 훔치러 온 다른 스레드가 접근한다.

그리고, Fork / Join Framework의 Work Thread의 수는 해당 어플리케이션이 구동되는 서버의 스펙에 따라 결정된다.
Runtime.getRuntime().availableProcessors()으로 JVM에서 이용 가능한 CPU Core 개수를 확인할 수 있으며,
스레드가 N개 생성되었을 때, 하나는 메인 스레드로 스트림을 처리하는 기본 스레드와 나머지 N-1개의 스레드가 ForkJoinPool 스레드이다.

예제 코드로 확인해보기

우선 순차적으로 실행 중인 thread 이름을 출력해보자.

public static void main(String[] arg) {

    List<Integer> numbers = Arrays.asList(1, 2, 3, 4);

    long start = System.currentTimeMillis();
    numbers.forEach(number -> {
        try {
            Thread.sleep(3000);
            System.out.println(number + ": " + Thread.currentThread().getName());
        } catch (InterruptedException e) {}
	});
    long duration = (System.currentTimeMillis() - start);
    double seconds = duration / 1000.0;

    System.out.printf("Done in %.2f sec\n", seconds);
}

1: main
2: main
3: main
4: main
Done in 12.05 sec

위 테스트를 진행했을 때 4개의 Elements에 대해서 각각 3초간 delay 되면서 총 12.05초가 걸렸다.

다음은 병렬 스트림을 이용하여 실행 중인 thread 이름을 출력하는 메소드를 호출해보자.
사용법은 간단한데, parallelStream() 또는 stream().parallel() 만 붙여주면 된다.

public static void main(String[] arg) {

    List<Integer> numbers = Arrays.asList(1, 2, 3, 4);

    long start = System.currentTimeMillis();
    numbers.parallelStream().forEach(number -> {
        try {
            Thread.sleep(3000);
            System.out.println(number + ": " + Thread.currentThread().getName());
        } catch (InterruptedException e) {}
    });
    long duration = (System.currentTimeMillis() - start);
    double seconds = duration / 1000.0;

    System.out.printf("Done in %.2f sec\n", seconds);
}

3: main
1: ForkJoinPool.commonPool-worker-2
2: ForkJoinPool.commonPool-worker-1
4: ForkJoinPool.commonPool-worker-3
Done in 3.04 sec

※ 현재 사용 중인 PC의 코어 수는 4개이다.

메인 스레드를 포함한 4개의 스레드가 병렬 처리되면서 12.05초가 걸렸던 작업이 3.04초만에 완료되었다.
그리고 numbers의 size를 5개로 설정하면 결과를 얻는 데까지 6초의 시간이 걸릴 것이다.
4개의 스레드가 동시 작업 할 동안 남은 1개의 작업을 처리하지 못하기 때문이다.

ParallelStream 크기 제어

ParallelStream에서 개발자가 임의로 Thread Pool의 크기를 조절하는 방법은 두 가지가 있다.

1. Property 설정

java.util.concurrent.ForkJoinPool.common.parallelism Property값을 설정하는 방법이다.

System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism","6");

public static void main(String[] arg) {
    System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism","6");

    List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);

    long start = System.currentTimeMillis();
    
    numbers.parallelStream().forEach(number -> {
        try {
            Thread.sleep(3000);
            System.out.println(number + ": " + Thread.currentThread().getName());
        } catch (InterruptedException e) {}
    });    
    
    long duration = (System.currentTimeMillis() - start);
    double seconds = duration / 1000.0;

    System.out.printf("Done in %.2f sec\n", seconds);
}

4: main
3: ForkJoinPool.commonPool-worker-2
2: ForkJoinPool.commonPool-worker-3
1: ForkJoinPool.commonPool-worker-1
6: ForkJoinPool.commonPool-worker-4
5: ForkJoinPool.commonPool-worker-5
Done in 3.07 sec

이 방법은 현재 실행되는 프로세스의 모든 ForkJoinPool의 commonPool에 설정이 적용되며, JVM 전체에 영향을 미칠 수 있기 때문에 가급적 사용하지 않는 것을 권장한다.

2. ForkJoinPool 설정

두 번째 방법은 commonPool을 사용하지 않고 개발자가 정의한 ForkJoinPool을 사용하는 방법이다.

ForkJoinPool forkJoinPool = new ForkJoinPool(6);

forkJoinPool.submit(() -> numbers.parallelStream()
        .forEach(number -> {
            try {
                Thread.sleep(3000);
                System.out.println(number + ": " + Thread.currentThread().getName());
            } catch (InterruptedException e) {}
        })
).get();

ForkJoinPool 생성자에 스레드 개수를 지정하여 사용할 수 있으며, 지정한 수만큼 스레드를 이용하여 처리한다.

ParallelStream 사용 전 꼭 알아야 할 주의사항

1. Thread Pool을 공유

parallelStream은 내부적으로 common ForkJoinPool을 사용하여 작업을 병렬화 시킨다.
parallelStream 별로 Thread Pool을 만드는 게 아니라는 것이다.
별도의 설정이 없다면 하나의 Thread Pool을 모든 parallelStream이 공유하게 되고,
Thread Pool을 사용하는 다른 Thread에 영향을 줄 수 있으며, 반대로 영향을 받을 수 있다.

Thread Pool은 미리 스레드를 생성하여 보관하고 필요할 때 빌려주고 사용하지 않으면 반납하여 Thread의 숫자를 유지하는 역할을 한다.
그런데 만약 Thread를 사용 중인 곳에서 아래 이미지처럼 Thread를 반납하지 않고 계속 점유 중이라면 어떻게 될까?

이렇게 되면 Thread 1, 2, 3은 사용할 수 없으며 Thread 4 한 개 만을 이용해서 모든 요청을 처리하게 된다.
특히 Thread 1, 2, 3 이 sleep과 같이 아무런 일을 하지 않으면서 점유를 하고 있다면 이는 문제가 크다.

만약, Thread 4까지 점유 중이게 되면 더 이상 요청은 처리되지 않고 Thread Pool Queue에 쌓이게 되며, 일정시간 이상 되면 요청이 Drop 되는 현상까지 발생할 것이다.

병렬 스트림은 Thread Pool을 global하게 공유하기 때문에 만약 A메서드에서 4개의 Thread를 모두 점유하면 다른 병렬 스트림의 요청은 처리되지 않고 대기하게 된다.
또한, blocking I/O 가 발생하는 작업을 하게 되면 Thread Pool 내부의 스레드들은 block 되며, 이때 Thread Pool을 공유하는 다른 쪽의 병렬 Stream은 스레드를 얻을 때까지 계속해서 기다리게 되면서 문제가 발생한다.

이 문제는 각 parallelStream마다 커스텀(new ForkJoinPool(int n))하여 독립적인 Thread Pool로 분리하여 사용하면 해결할 수 있다.

2. Custom Thread Pool 사용 시 Memory Leak 주의

ForkJoinPool customForkJoinPool = new ForkJoinPool(Runtime.getRuntime().availableProcessors());

※ 별도의 스레드 풀 생성 시 정석은 실행 중인 CPU 코어 수를 기준으로 생성하는 것이다.

물리적인 코어 수를 초과하여 생성할 경우, 생성은 되지만 스레드 관리 오버헤드와 스레드 간의 빈번한 컨텍스트 스위칭(Context-Switching) 등의 문제로 성능 저하가 발생할 수 있다.

Parallel Stream 별로 ForkJoinPool을 인스턴스화하여 사용하면 OOME(OutOfMemoryError)이 발생할 수 있다.
default로 사용되는 Common ForkJoinPool은 정적(static)이기 때문에 메모리 누수가 발생하지 않지만,
Custom 한 ForkJoinPool 객체는 참조 해제되지 않거나, GC(Garbage Collection)로 수집되지 않을 수 있다.
따라서 Custom ForkJoinPool을 사용한 후 다음과 같이 스레드 풀을 명시적으로 종료해야 한다.

ForkJoinPool customForkJoinPool = new ForkJoinPool(Runtime.getRuntime().availableProcessors());
// do something..
customForkJoinPool.shutdown();

3. Collection 별 성능 차이

parallelStream은 분할되는 작업의 단위가 균등하게 나누어져야 하며, 나누어지는 작업의 비용이 높지 않아야 순차적 방식보다 효율적으로 이루어질 수 있다.
array, arrayList와 같이 전체 사이즈를 알 수 있는 경우에는 분할 처리가 빠르고 비용이 적게 들지만,
linkedList와 같이 사이즈를 정확히 알 수 없는 데이터 구조는 분할되지 않고 순차 처리를 하므로 성능 효과를 보기 어렵다.

4. 병렬 처리 시 작업의 독립성

병렬로 처리되는 작업이 독립적이지 않다면, 수행 성능에 영향이 있을 수 있다.
예를 들어, stream()의 중간 연산 중에 sorted()나 distinct()와 같은 작업을 수행할 경우
내부적으로 상태에 대한 변수를 각 작업들이 공유(synchronized)하게 되어 있다.

※ 내부적으로 어떤 공용 변수를 만들어 놓고 각 worker들이 이 변수에 접근할 경우, 동기화 작업 등을 통해 변수를 안전하게 유지하며 처리한다. 기존 Thread 작업 시 개발자가 해줘야 했던 동기화 등의 작업을 모두 수행하고 있는 것이다.

이러한 경우 순차적으로 실행하는 것이 보다 효과적이며,
각각 완전히 분리된 task들에 대해서 병렬로 처리하는 경우에 성능상 이점이 있을 수 있다.

5. 요소의 수 그리고 요소당 처리 시간

컬렉션에 요소의 수가 적고 요소당 처리 시간이 짧으면 순차 처리가 오히려 빠를 수 있다.
병렬 처리는 작업들을 분할(fork)하고 다시 합치는(join) 비용, 스레드 간의 컨텍스트 스위칭 비용도 포함되기 때문이다.

정리하면

parallelStream()은 세부 설정이나 복잡한 로직 없이 기존 stream()을 쓰듯 사용할 수 있는 편리함을 제공하지만,
병렬 처리가 무조건 더 나은 결과를 보장한다고 할 순 없다.

처리 성능에 영향을 미치는 부분들, 분할 및 병합 과정에서의 비용, 멀티 스레드 환경에서의 컨텍스트 스위칭 비용 등에 대해 충분히 고려해야 하기 때문에 신중해야 한다.

또한, I/O를 기다리는 작업에는 적합하지 않고, (이 경우 CompletableFuture가 적합)
분할이 잘 이루어질 수 있는 데이터 구조 혹은 작업이 독립적이면서 CPU 사용이 높은 작업에 적합하다.

특정 로직의 성능 개선을 위해 parallelStream()을 적용하고자 한다면, 이것이 정말로 성능 개선을 해줄 수 있는가 혹 예상치 못한 장애를 발생시키지는 않을까에 대해 충분히 고민하고 적용하는 것이 좋을 것 같다.

Reference :
https://www.baeldung.com/java-when-to-use-parallel-stream
https://www.baeldung.com/java-8-parallel-streams-custom-threadpool#bd-beware-of-the-memory-leak
https://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html
https://sabarada.tistory.com/102
https://m.blog.naver.com/tmondev/220945933678