미리보기

데이터 요청/추출 프로세스를 자동화하여 부서 간 업무 비효율 문제를 해결

반복적인 데이터 추출 요청을 확인 하고 부서 간 업무 지연을 해결하기 위해 자동화 작업 계획

• 데이터 추출 요청 히스토리와 담당자와의 미팅을 통해 요청 패턴, 수요를 파악

•  Spring Batch 와 Jenkins 를 활용하여 데이터 추출 및 엑셀 파일 업로드 프로세스를 자동화

• 데이터 추출 관련 부서 간 협업 과정에서 존재하던 병목 지점 제거되어 업무 효율화

엑셀 파일 시 메모리 사용량을 최적화하여 운영 서버에서 발생하던 OOM 문제를 해결

• Heap dump 분석 을 통해 운영 환경에서 발생한 OOM 문제 원인을 진단

• 엑셀 파일 렌더링 시 비효율적인 힙 메모리 사용이 원인임을 확인

• Apache XSSFWorkbook 관련 인스턴스가 힙 메모리 대부분을 차지

• TreeMap 형태로 필요한 데이터를 모두 로드하는 Apache XSSFWorkbook 의 동작 방식이 원인으로 파악

• Stream 기반으로 동작하는 SXSSFWorkbook 으로 교체하여 메모리 사용량을 최적화

• 더불어 엑셀 데이터 렌더링을 위한 DB 쿼리의 비효율에 의해 API 응답 속도가 매우 느린 것을 확인

• 필요한 컬럼만 가져오도록 변경 및 발생하던 N+1 문제를 제거하여 쿼리 최적화

• 평균 API 응답 속도를 70 % 이하로 개선

  • 현재 대량의 데이터를 엑셀 파일로 렌더링 시도 하더라도 힙 메모리 사용량은 상당히 안정적임

  • Grafana 대시보드를 통해 매일 아침, 힙 메모리 사용량 등 서버 지표를 모니터링 중

2천 라인 이상의 엑셀 파일 렌더링 레거시 코드를 템플릿 메서드 패턴 기반으로 리팩토링

• 회원 수 증가에 따라, 관련 데이터를 엑셀 파일로 제공하는 내부 직원용 기능 개발 요청이 증가

• 기존 엑셀 관련 로직은 모두 하드 코딩 된 레거시 코드로, 개발 생산성을 저하 하는 요인

• 엑셀 관련 코드가 비즈니스 로직 곳곳에 침투하는 등 유지보수에 불리한 점 다수 파악

• 엑셀 파일 렌더링 로직을 추상화/분석

• 각 기능마다 데이터를 쿼리하고 처리하는 부분만 다르고, 엑셀 관련 로직(초기화/렌더링)은 동일함을 발견

• 템플릿 메서드 패턴을 적용한 리팩토링

  으로 엑셀 관련 로직의 응집성을 높이고 추상화

• 현재는 신규 엑셀 기능 개발 시, 관련 데이터 쿼리 작성에만 집중하면 되므로 개발 속도가 기존 대비

  크게 증가함

계층형 데이터 구조로부터 발생한 조회 성능 문제를 Redis 를 활용하여 평균응답시간 개선

• 카테고리 데이터는 스스로를 참조하는 계층형 구조로 설계되어 있었음

• 이때 각 카테고리의 루트를 찾으려면 DFS 를 수행해야 하므로 조회 성능이 우려 됨

• 카테고리 데이터 특성 상, read 연산만 발생

• 각 카테고리 별 루트 카테고리를 매핑한 데이터를 Redis 에 캐싱 하여 평균 응답속도를 90% 개선

 RSA 암호화를 적용하여 API 통신 간 민감한 데이터의 무방비 노출 가능성을 100% 차단

민감한 데이터를 요청받는 API 의 보안 취약점 발견

•  개발자 도구의 network 탭에서 raw data 노출

• 초기에는 매 API 요청마다 RSA 키페어를 생성하여 암/복호화를 진행하도록 구성

• 요청마다 RSA 키페어를 생성하는 것은 cost 문제가 있음

• 쓰레드 풀 개념에서 아이디어를 얻어, 미리 생성된 RSA 키페어를 Redis 에서 관리할 수 있도록 설계하여 cost optimization

• 일정 주기마다 Redis 에 저장된 키페어들을 Refresh 하도록 스케쥴러 구성

• 현재 이지태스크의 모든 API 의 민감한 데이터 요청은 network 탭에서 암호화되므로 보안성 강화됨

Redis pub/sub 기반의 message broker 로 교체하여, 채팅 시스템 확장성 개선

기존의 채팅 시스템은 Spring Simple message broker 을 사용함에 따라 확장성, 고가용성, 모니터링 측면에서 개선이 필요했음

• 채팅 시스템 개편 프로젝트에 참여하여, Redis 기반의 외부 Message broker 로의 전환을 주도

사이드 프로젝트로 정부 재난 문자 기반 알림 백엔드 서버를 개발하고 있습니다.

Java 로 구현하였고, 현재는 Kotlin 으로 마이그레이션을 시도하고 있습니다.

• java github repository (https://github.com/Team-NumberOne/Backend)

• kotlin github repository (https://github.com/Team-NumberOne/Daepiro_Backend)

 팀 구성

• 백엔드(2), 안드로이드(2), 기획(3), 디자인(1)

테스트 컨테이너 기반으로 운영 환경과 유사한 테스트 환경을 구축

( https://versatile0010.github.io/test/sideproject/test-container-java )

• 운영 환경에서는 MySQL 을 사용하지만 테스트 환경에서는 H2 DB 를 사용하는 환경 불일치 발생

• MySQL 에서는 지원하지만 H2 에서는 호환되지 않는 Syntax 에 의해, 주요 비즈니스 로직을

  제대로 테스트 할 수 없는 문제

• 운영 환경과 최대한 유사한 테스트 환경을 구축하는 것이 안정적인 서비스 개발에 유리하다고 판단

• 테스트 컨테이너 라이브러리를 사용하여 테스트 코드 실행 시, 테스트

  용도의 MySQL 컨테이너가

  동작 하도록 조치

모놀리틱 구조에서 멀티모듈 구조로 전환

( https://versatile0010.github.io/architecture/sideproject/daepiro-multimodule-bluegreen )

• 초기에는 짧은 개발 시간으로 인해

  모놀리틱 구조

  로 구현

• 서비스가 고도화됨에 따라

  코드 중복 이 자주 발생했고, 각 기능 간 영향 범위 파악이 어려워짐

• 멀티모듈 구조로 아키텍쳐를 전환하여 코드 중복을 줄이고 응집성을 높임

• 기능 간 의존성이 명확하게 드러나므로, 관리 포인트가 최소화

Google Jib 을 활용하여 효율적인 컨테이너 배포 프로세스 구성

( https://versatile0010.github.io/infra/jib )

• 배포 소요 시간이 길어지면 개발 생산성이 저하되어 긴급한 이슈 대응이 어려워 짐

• 기존 Docker 컨테이너 기반의 배포 프로세스 중 자바 애플리케이션 이미지 빌드 과정이 병목점으로 판단

• 한 라인만 수정하더라도 jar 레이어를 새롭게 빌드해야 하므로 캐싱 레이어를 전혀 활용하지 못함

• 이 외에 DockerFile 을 최적화하여 이미지 빌드 타임을 줄이고자 구상하였지만 DockerFile 에 대한

  관리 포인트가 증가 되는 것을 우려

• DockerFile 없이 gradle 에서 간단한 설정만으로도 자바 이미지를 매우 효율적으로 빌드

  하도록 지원하는

  Google Jib 를 도입하여 배포 소요 시간을 최대 50% 단축

AWS Secret Manager 기반으로 안전하고 편리하게 프로젝트 환경 변수를 관리

• DB password 와 같은 환경 변수는 yml 파일 형태로 로컬에서만 관리

• 환경 변수의 수정 발생 시 동료 개발자에게 구두로 알려야 하는 문제 발생

• Github Secrets 를 활용하여 key-value 형태로 주입받도록 하고, 환경변수 yml 파일은 git ignore 에서

  제거하여 git 을 통해 version control 되도록 하는 방법을 고려함

• 팀 회의를 진행하며 Github Secrets 에서 제공하는 환경 변수 등록/수정 기능은 다소 번거롭다고 판단

• 이에 동일한 기능을 훨씬 간단하게 적용할 수 있는 AWS Secret Manager 을 도입하여 해당 문제 해결

블루 그린 무중단 배포 플로우 구성

• 배포할 때 마다 발생하는 downtime 으로 인해 라이브 배포가 어려워짐에 따라 적극적인 개발이 어려워짐

• 도커 컨테이너와 nginx 을 활용한 블루 그린 무중단 배포

  가 이루어지도록 개선

• 배포 대상 브랜치에서 commit 으로 트리거링되면 기존 버전의 컨테이너를 유지한 상태에서 새로운 버전의

   컨테이너를 동작시킴

• health check 되면 nginx 에서 traffic 을 새로운 컨테이너로 전환하도록 배포 스크립트 구성함