📊 디자인 패턴으로 레거시 코드 해치우기… (feat. Excel, OutOfMemory)

“해치웠나..? 🤨”

---

점점 쌓여가는 Old generation…

Grafana 로 서버를 모니터링 하던 중, 운영 서버의 Old Generation 영역이 점차 쌓이는 문제가 발생했습니다.

여기서 Old Generation 이란 JVM 의 heap memory 영역 중 하나로,

GC(Garbage Collection) 에 의해 회수되지 못하고 오래 살아남은 객체들이 모이는 영역입니다.

Old Generation 영역에서 발생하는 GC 는 major GC 혹은 full GC 라고 하는데,

이 과정에서 Stop - The - World(STW) 이벤트가 발생하여 Application 의 모든 thread 가 일시정지됩니다.

major GC 는 Young Generation 영역에서 발생하는 minor GC 에 비해 더 긴 STW 시간을 가집니다.

대용량의 데이터를 처리하는 과정에서 Old Generaiton 영역에서의 메모리 부족으로 인해

Out Of Memory (OOM) 가 발생하여 서버가 다운될 수 있습니다.

최근 우리 서비스에서도 이와 같은 문제가 있었는데요,

주 원인은 대규모 데이터를 Excel 파일로 변환하는 과정에서 발생했습니다.

Apache POI Library

heap dump

당시에 JVM heap dump 를 떠서 Old Gen 에 어떠한 객체가 쌓이고 있는지 확인하고자 했었습니다.

메모리를 가장 많이 사용하고 있던 객체는 Apache POI Library 관련 클래스들이었습니다.

우리 서비스의 Excel 파일 생성 API 에서 Apache POI 의 XSSFWorkbook 을 사용하고 있었습니다.

Stack overflow: POI OutOfMemory Exception with XLSX

Apache POI Library 의 XSSFWorkbook 은 Excel 관련 데이터들을 메모리에 모두 tree map 으로 로드하여 처리하기 때문에,

데이터의 양이 많아지면 메모리 사용량이 늘어나서 OOM 이 발생하게 된 것이죠.

SXSSFWorkbook

Apache 에서는 XSSFWorkbook 외에도 SXSSFWorkbook 을 제공하고 있습니다.

SXSSFWorkbook 은 Streaming 방식을 사용하기 때문에 필요한 데이터의 일부만 메모리에 로드하고 나머지는 임시파일로써 디스크에 저장하여 사용합니다.

즉, 모든 데이터를 메모리에 올리지 않아도 되기 때문에 XSSFWorkbook 에 비해 메모리 사용량을 크게 줄일 수 있으므로,

기존에 발생하던 OOM 문제를 해결할 수 있을 것으로 예상했습니다.

XSSFWorkbook 에서는 Excel read / write 를 모두 지원하는데 반해

SXSSFWorkbook 에서는 write 만 지원한다는 것도 주요한 차이점인데요,

우리 서비스의 요구사항은 Excel Write 였기 때문에

SXSSFWorkbook 으로 교체하여 서버 메모리의 부담을 줄이기로 결정했습니다

수많은 레거시 코드

프로젝트 전반에 걸쳐 흩어져 있는 엑셀 관련 코드들은 중복도와 복잡성이 매우 높았습니다.

이를 전부 다 걷어내고 리팩토링하여 엑셀 파일 관련 로직을 명확하고 재사용이 쉬운 형태로 개선하고자 했습니다.

평균적으로 200~300 라인에 달하는 액셀 파일 생성 서비스 코드들이 각 도메인(회원, 결제, 쿠폰, …) 별로 존재했습니다.

각 메서드마다 100 ~ 150 라인은 Excel 관련 초기화 로직이 중복되어 있었습니다.

이는 관리하기 어렵고,

다양한 문제를 유발할 수 있습니다.

시스템을 안정적으로 운영하기 위해서는 관리 포인트를 최소화하는 것이 좋은 것 같습니다.

이번 사례에서는 엑셀 관련 기능을 캡슐화 및 추상화하는 것이 핵심이었습니다.

내부 구현은 숨기고 외부에서는 단순한 메서드 호출만으로 엑셀 파일 렌더링이 가능하는 것이 이상적인 형태라고 판단했습니다.

하지만 엑셀 파일은 요구사항마다 헤더와 바디가 다르기 때문에 이를 적절하게 고려해줄 필요가 있었습니다.

Template Method Pattern

엑셀 파일 생성과 렌더링의 알고리즘 순서를 정의하고,

엑셀 데이터 요구사항 별로 세부 구현에 대한 커스터마이징이 필요했습니다.

이러한 상황을 쉽게 해결할 수 있는 디자인 패턴이 바로 Template method pattern 이었습니다.

Template method pattern

엑셀 파일을 생성하고 렌더링하는 알고리즘의 순서를 정의하고,

커스터마이징이 필요한 각각의 step 에 대해서만 subclass 에서 따로 구현하도록 하는 것입니다.

public abstract class ExcelViewTemplate<T> {

    private final SXSSFWorkbook workbook;
    private SXSSFSheet sheet;

    public ExcelViewTemplate() {
       // 초기화 로직 작성
    }

    public final void renderData(List<T> dataList) {
       // 렌더링 로직을 작성
    }

    protected abstract void renderHeader(Workbook workbook, Sheet sheet, CellStyle cellStyle);

    protected abstract void renderBody(Row row, T data, CellStyle cellStyle);

}

회원 데이터를 처리해야 한다고 가졍하죠.

public class UserExcelView extends ExcelViewTemplate<UserExcelDto> {
    @Override
    protected void renderHeader(Workbook workbook, Sheet sheet, CellStyle cellStyle) {
       // UserExcelDto 에 맞게 구현
    }

    @Override
    protected void renderBody(Row row, UserExcelDto data, CellStyle cellStyle) {
      // UserExcelDto 에 맞게 구현
    }

}

UserExcelDto 는 엑셀 데이터 용도로 사용하는 dto 클래스입니다. (예시로 보여주기 위한 코드입니다.)

각각의 헤더가 어떤 title 을 가지는지, 몇 번째 열에 해당하는 지 명시하기 위해서는 별도의 ExcelColumnInfo 클래스를 구현하여 사용할 수 있습니다.

public interface ExcelColumnInfo {
  
    String getText(); // 이름

    int getColumn(); // 열 순서

}

@Getter
@RequiredArgsConstructor
public enum UserExcelColumnInfo implements ExcelColumnInfo {

    YOUR_HEADER1("헤더1", 0),
    YOUR_HEADER2("헤더2", 1),
    ;

    private final String text;
    private final int column;

    public static List<UserExcelColumnInfo> getAllColumnInfos() {
        return Arrays.asList(values());
    }
}

필요에 따라 CellStyle 을 지정하는 필드를 별도로 넣어, 헤더별로 다른 폰트, 테두리, 배경을 지정할 수도 있습니다.

이와 같이 템플릿 메서드 패턴을 통해 추상화 한 ExcelView 클래스를 이용하면 서비스 로직이 매우 간단해집니다.

기존에는 엑셀 파일을 렌더링하는 메서드마다 200~300 라인이었다면

현재는 각각 30 라인 이하로 크게 줄일 수 있었습니다.

관리 포인트도 응집되어, 유지보수에도 더욱 유리해졌죠.

위와 같은 구조로 리팩토링한 후,

개발용으로 따로 띄워둔 서버에서 데이터 5만 개에 대하여 엑셀 파일 요청을 반복적으로 요청하며 서버 힙 메모리 사용량과 처리 속도를 모니터링 해본 결과,

기존의 레거시 API 와 달리 굉장히 안정적이었습니다.

처리 속도 또한 기존에는 40 ~ 1분 이상의 API 응답 속도였지만,

개선된 현재는 최대 10초 이내로 응답하고 있습니다. (데이터 5~6만개 기준)

---

본 작업의 진행 과정에서, 해결해야 했던 문제상황과 제가 풀고자 했던 방향과 정확히 일치한 사례 우아한 기술블로그; 엑셀 다운로드 모듈 개발기 를 발견하였고,

아주 많은 도움이 되었습니다.

해당 자료에서는 Reflection 과 Custom Annotation 을 이용하여, 엑셀 관련해서 한층 더 간편하게 작업할 수 있도록 고도화 하는 과정을 소개하고 있는데요..

(마지막에는 너무 간편해서 감동받음)

해당 작업에 소요할 수 있는 주어진 시간이 적었고

당장 다른 급한 이슈를 처리해야 했기에

엑셀 모듈을 추상화하는 단계까지만 고도화하기로 하였습니다.

지금은.. 당장 급한 불을 껐으니

더 급한 불을 끄고 다시 돌아와야겠네요.. 😅

---

오늘은 프로젝트 전체적으로 얽혀있던 레거시 코드를 제거하고

엑셀 모듈을 새로 개발한 후기에 대해서 이야기해보았습니다.

아직 회사에 합류한 지, 인턴으로는 4개월 되었고 정규직으로는 1~2주 밖에 되지 않았는데요,

그럼에도 자칫 잘못하면 프로젝트 전반적으로 문제가 발생할 수 있을만큼

영향범위가 컸던 작업을,

직접 계획하여 혼자 담당하여 배포까지 마무리지었는데요..

이것이 스타트업의 매력인걸까요..

무한한 자유와 책임이 공존하는 곳 같습니다.

이번 작업이 성공적으로 마무리되어 서버 안정화에 기여한 점이 정말 다행스럽네요.

새로운 엑셀 모듈로의 리팩토링 과정은 정말 재밌었고, 그렇게 어렵지 않았습니다.

다만 가장 힘겨웠던 부분은 중요한 비지니스 로직에도 얽혀있던 고대의 레거시 코드를 이해하고 제거하는 것이었습니다..

이럴때 도움이 되는 것은 디테일하게 잘 작성된 테스트 코드 일 텐데요,

우리 스타트업은 아직 초기 단계라

백엔드 개발 인력이 너무 적고, 요구사항은 정말 많은 탓에

슬프게도 테스트 커버리지가 아직은 매우 낮은데요..

이러한 상황에서의 과감한 리팩토링은 큰 부담으로 다가왔습니다.

비지니스 로직을 정말 다 알고 있지 않으면,

예상하지 못한 부분에서 장애가 발생할 수 있기 때문이었죠..

이 부담감을 온전히 느끼며,

매우 조심스럽게 레거시를 걷어내고 결국 모두 제거하는 데에 다행히 성공했습니다.

역시.. 잘 만들어진 테스트 코드가 얼마나 중요한 지 다시 한번 깨닫게 되는 계기였습니다.

이번 회사에 있는 동안,

테스트 환경을 처음부터 잘 구축하고

테스트 커버리지를 최소 7~80% 까지는 올리고 싶은 개인적인 목표가 있습니다.

정말 많은 요구사항과 프로젝트가 쏟아지는 환경에서,

테스트 코드를 작성하는 데에 쏟을 시간이 물리적으로 조금 부족하게 느껴지는 것은 사실이지만

장기적으로는 결국 개발 생산성을 가속화 해주는 것이 테스트 코드라고 생각하므로

꼭 해낼 수 있도록 해야겠습니다.

토스에서 올린 테스트 커버리지 100% 운영기 영상을 다시 한번 보면서 마음을 다 잡아야겠네요

---

Reference

우아한 기술블로그; 엑셀 다운로드 모듈 개발기