EVO

블로그 이전했습니다.

EVO. — Sat, 26 Apr 2025 10:53:26 +0900

https://minsang-alt.github.io/

[이슈 #3] DB 설계 개선으로 끌어올린 코드 품질과 유지보수성

EVO. — Thu, 6 Mar 2025 23:31:09 +0900

리팩토링을 시작하게 된 배경

오래된 제 코드를 살펴보면서 리팩토링의 필요성을 느꼈습니다.

리팩토링을 하려는 이유는 숨겨진 버그나 취약점을 발견하고 수정하기 위함과 가독성을 높여 확장성을 향상시키기 위함 입니다. 리팩토링을 시작하려 했지만, 오래된 코드의 내용이 기억나지 않아서 먼저 코드를 보면서 어떤 요구사항이고 도메인이었는지 떠올려야 했습니다.

그러기 위해서는 먼저 테스트부터 작성할 필요성을 느꼈는데, 테스트 커버리지를 확인해보니 라인 커버리지가 25%에 불과했습니다. 제 생각엔 100%까지 목표로 잡지 않아도 핵심 비즈니스 로직에 대해 80%까지만 가도 충분히 리팩토링하는 데에는 도움이 될 것 같았습니다. 왜냐하면 커버리지가 높더라도 테스트 케이스가 부적절하게 작성되었다면 여전히 중요한 버그가 발생할 수 있기 때문입니다. 또한, 모든 코드를 테스트하는 것이 현실적이지 않을 수도 있습니다. 특히 예외 상황이나 경계 조건을 모두 다루기는 어렵습니다.

테스트를 작성하기 전에 가장 오래전부터 뜯어고치고 싶었던 것이 있었습니다. 바로 "DB 설계 구조 변경" 입니다.

DB 설계 구조 변경

문제상황

과거 테이블 구조는 다음과 같습니다.

Issue 테이블이 에픽(Epic), 스토리(Story), 테스크(Task) 테이블의 부모 역할을 하는 구조였고, number, content, title, status, label 등의 공통 필드를 가집니다. 에픽(Epic), 스토리(Story), 태스크(Task) 테이블은 각각 issue_id를 외래키(FK)로 사용하여 Issue를 상속받습니다. 즉, Issue 테이블의 데이터를 확장하는 형태 입니다.

또한, story 테이블은 epic_id를 FK를 가지면서 특정 에픽에 속하고 있고, Task 테이블은 story_id를 FK를 가지면서 특정 스토리에 속하는 설계입니다.

즉, 싱글테이블 전략 대신 JPA에서의 조인 테이블 상속 전략을 사용한 설계였고, 과거에는 정규화를 최대한 진행해서 데이터 중복과 이상현상을 방지하고, 불필요한 null값을 줄이기 위해 팀원과 회의를 하면서 조인형태의 구조를 선택했습니다.

이 방식은 객체지향적으로 봤을 때 상속 구조처럼 보이지만, 실제 운영에서는 복잡성을 증가시켰습니다. Join이 많아 성능 이슈 발생이 많았고 (예를들면, 프로젝트에 속한 에픽 통계 구하는 API는 한 애픽에 속한 스토리들의 상태가 필요하기 때문에 Issue, Epic, Story 테이블의 조인이 필요했습니다.), 가장 큰 문제점은 테이블이 분리되어 있어 INSERT/UPDATE가 복잡하여 테스트코드를 작성할때 개발자가 코드상에서 상속 구조를 항상 신경 써야하는 문제점이 있었습니다.

그래서 이 문제를 풀기 위해 단일 테이블 전략으로 바꿔, epic, story, task 테이블을 issue 하나로 통합하는 것이 목표였습니다. 그렇게 하기 위해선 다양한 고려사항이 있었습니다.

기존 테이블을 바로 삭제해버리고 차근차근 시작하면 매우 위험하다고 판단했습니다. 왜냐하면 이슈 테이블에는 약 200만건의 이슈데이터가 있었고, 운영상황이라고 가정했을 때 사용자 경험을 해치지 않으면서 안전하게 마이그레이션 하는게 중요하다고 생각했습니다.

데이터 마이그레이션은 어떻게 해야 할까?

마이그레이션을 수행하는 전략은 3가지가 존재합니다. (실제론 더 많을 수도 있습니다)

빅뱅 마이그레이션

빅뱅 마이그레이션은 하나의 소스 시스템에서 대상 데이터베이스로의 일회성 데이터 전송입니다. 사용자가 적게 이용하는 일반적으로 주말 또는 미리 정의된 가동 중지 시간 동안 수행됩니다. 이 기술은 더 빠르고 덜 복잡하다는 장점이 있어 데이터가 적은 소규모 기업에 더 적합합니다. 그러나 단점은 다운타임으로 인해 시스템을 24/7 운영하는 기업에게는 불편합니다.

트리클 마이그레이션

트리클 마이그레이션(증분 또는 단계적 마이그레이션이라고도 함)은 데이터를 작은 단위로 나누어 점진적으로 이전하는 전략입니다. 모든 데이터를 한 번에 옮기는 빅뱅 방식과 달리, 트리클 마이그레이션은 데이터를 여러 단계로 나누어 천천히 이동시킵니다. 이 접근법은 리스크를 분산시키고 문제 발생 시 영향 범위를 최소화할 수 있습니다. 단점으로는 구현이 복잡하고 전체 마이그레이션 기간이 길어질 수 있으며, 일정 기간 동안 두 시스템을 동시에 운영해야 하는 부담이 있습니다.

다운타임 없는 마이그레이션

이 전략은 서비스 중단 없이 원본 데이터베이스에서 대상 데이터베이스로 데이터를 지속적으로 동기화합니다. 마이그레이션 과정 중에도 사용자는 기존 시스템을 계속 이용할 수 있어 비즈니스 연속성을 유지할 수 있습니다. 주요 장점으로는 서비스 중단이 없고, 비즈니스 운영에 미치는 영향을 최소화할 수 있다는 점이 있습니다. 하지만 실시간 동기화를 위한 복잡한 도구와 인프라가 필요하고, 설정 및 관리가 까다로우며, 데이터 무결성을 보장하기 위한 추가적인 검증 작업이 필요합니다.

선택한 전략

현재 실제 운영 중인 시스템이 아니지만 운영상황이라 가정하여 약 200만 건의 이슈 데이터가 있어 규모가 작지 않고, 혹시 모를 문제에 대비하여 단계적으로 검증하면서 진행하기 위해 트리클 마이그레이션 방식을 선택했습니다. 이 방식은 각 단계마다 데이터 검증이 가능하고, 문제 발생 시 해당 단계만 롤백할 수 있어 전체 마이그레이션의 리스크를 줄일 수 있다는 장점이 있습니다. 또한 데이터 구조 변경이 복잡한 만큼, 점진적으로 진행하면서 각 단계의 결과를 확인하는 것이 안전하다고 판단했습니다.

트리클 마이그레이션은 어떻게 수행 해야할까?

트리클 마이그레이션을 위해 다음과 같은 단계별 접근법을 사용했습니다.

1. 데이터 분할

데이터를 논리적인 단위로 분리하기 위해 비즈니스 특성에 맞춰 프로젝트별로 나누는 방식을 선택했습니다. 이슈 수가 적은 프로젝트부터 차례대로 마이그레이션을 진행하여 초기에 발생할 수 있는 문제를 작은 규모에서 발견하고 해결할 수 있도록 했습니다. 이 접근법은 각 프로젝트의 특성에 맞게 마이그레이션을 조정할 수 있다는 장점도 있었습니다.

2. 프로젝트별 마이그레이션 윈도우 설정

각 프로젝트의 데이터 복제 시에는 해당 프로젝트에 대한 짧은 다운타임이 필요했습니다. 사용 패턴을 가정해, 프로젝트 이슈 작업은 주로 업무 시간에 집중되어 있을거라 판단했습니다. 따라서 사용량이 가장 적은 저녁~밤 시간대에 마이그레이션을 수행하기로 결정했습니다.

마이그레이션 진행 중에는 테이블을 읽기전용(Read-only) 상태로 변경했습니다. 이는 마이그레이션 중 데이터 무결성을 유지하고, 애플리케이션 코드가 실수로 기존 테이블을 수정하지 않도록 방지하기 위함이었습니다. 이 방법으로 데이터 일관성을 보장하면서도 사용자는 여전히 데이터를 조회할 수 있었습니다.

3. 새로운 테이블 구조 설계 및 생성

기존의 분산된 테이블 구조에서 단일 테이블로 전환하기 위해 새로운 new_issue 테이블을 설계했습니다.

새 테이블의 핵심 변경사항은 다음과 같습니다.

issue_type ENUM('EPIC', 'STORY', 'TASK') 칼럼 추가: 하나의 테이블에서 다양한 유형의 이슈를 구분할 수 있게 함
기존 epic, story, task 테이블에 있던 고유 필드들을 모두 통합
계층 구조를 표현하기 위한 parent_issue_id 필드 추가: 이 필드를 통해 Epic-Story-Task 간의 관계를 유지. Epic은 null 값을, Story는 연관된 Epic의 ID를, Task는 연관된 Story의 ID를 저장하도록 설계

이 구조는 다음과 같은 이점을 제공했습니다

조인 연산 없이 단일 테이블에서 모든 이슈 정보 조회 가능
계층 구조를 유지하면서도 쿼리 복잡도 감소
필요한 경우 이슈 타입별로 필터링하여 기존 동작 유지 가능

4. 프로젝트 ID 별로 배치스크립트 수행

약 200만 건의 이슈 데이터를 수동으로 마이그레이션하는 것은 비효율적이고 오류 가능성이 높았습니다. 특히 대량의 데이터가 있는 프로젝트에서는 수동 작업이 현실적으로 불가능했습니다. 따라서 프로젝트별 배치 처리 프로시저를 MySQL에서 구현했습니다. 특히 구현할땐 트랜잭션 기반 처리로 데이터 일관성 보장, 검증 로직 구현, 문제 발생 시 롤백 및 로그 기록을 하도록 했습니다.

5. 애플리케이션 코드 단계적 변경

데이터 구조 변경 후, 애플리케이션 코드를 새로운 테이블 구조에 맞게 수정했습니다.

(Domain -> Repository -> Service -> DTO 순으로 계층 수정)

리팩토링을 통한 성과

코드 구조 단순화와 중복 제거

기존에는 에픽, 스토리, 태스크의 부모를 가져오기 위해 유형은 다르지만 비슷한 로직을 중복해서 구현하고 있었습니다. 단일 이슈 테이블로 통합한 후에는 관련 클래스 수를 4개에서 1개로 줄일 수 있었습니다. 이는 코드의 가독성과 유지보수성을 크게 향상시켰습니다.

객체지향 원칙 적용과 다형성 활용

개선 전 코드에서는 각 이슈 타입(Epic, Story, Task)마다 별도의 생성 메서드를 구현하고 있었습니다. 추상 클래스인 Issue를 사용함에도 불구하고, Issue 타입으로 객체를 받으면 다른 로직을 수행할 때 정확한 타입을 확인하기 위해 instanceof로 클래스 타입을 체크하고 불필요한 타입 변환까지 발생했습니다. 이는 다형성을 제대로 활용하지 못하는 안티패턴이었습니다.

마이그레이션 후에는 Issue 클래스로 통일하고 타입을 내부 속성으로 관리함으로써 이러한 불필요한 타입 체크와 변환 과정이 해소되었습니다. 결과적으로 코드는 더 명확하고 객체지향적인 설계를 갖게 되었습니다.

테스트 커버리지 개선 24% -> 42%

리팩토링 이전에는 테스트 코드의 라인 커버리지가 24%에 불과했습니다. 개발 초기에는 규모가 작아 기능을 개발하고 Swagger로 빠르게 테스트하는 방식으로 진행했기 때문에 테스트 코드 작성에 충분한 시간을 투자하지 못했습니다.

이번 리팩토링에서는 코드 변경과 함께 다음과 같은 고민을 했습니다.

Repository에 작성한 네이티브 쿼리가 제대로 작성되었는지 정확히 확인하기 위해 TestContainer를 활용하여 실제 MySQL DB 환경에서 검증했습니다.
통합 테스트를 할 때 공통적인 더미 데이터가 자주 필요했는데, 이때 @SQL 어노테이션을 사용했습니다. 하지만 테스트 시간이 너무 길어지므로 꼭 필요할 때만 사용했습니다.
그 외에도 @SQL 없이 공통 더미 데이터는 팩토리 클래스를 통해 테스트마다 유연하게 사용할 수 있도록 했습니다.
비즈니스 로직만 확인할 때는 단위 테스트에서 Mock을 활용했습니다.

그 결과, 테스트 커버리지를 42%까지 높일 수 있었습니다. 아직 목표인 80%에는 미치지 못하지만, 앞으로 지속적인 리팩토링과 테스트 코드 작성을 통해 점진적으로 개선해 나가고 있습니다.

Jacoco 커버리지 결과

수정 전 DB 구조

개선된 DB 구조

[이슈 #2] 멤버 초대 이메일 발송 설계

EVO. — Mon, 23 Dec 2024 01:54:47 +0900

기능 요구사항

관리자는 이메일 주소를 입력하여 새로운 멤버를 초대할 수 있습니다.
초대 이메일은 지정된 템플릿 형식으로 발송되어야 합니다.
초대 링크는 10분간 유효합니다.
초대 링크는 1회만 사용가능합니다.
만료되거나 사용된 초대 링크는 더 이상 사용할 수 없습니다.

비기능 요구사항

초대 링크는 추측할 수 없는 안전한 토큰을 사용해야 합니다.
이메일 발송은 비동기로 처리되어야 합니다.
시스템은 초대 상태를 추적하고 관리할 수 있어야 합니다.

멤버 초대 플로우

프로젝트를 개설한 관리자는 본인 팀의 멤버들을 초대하기 위해 멤버 이메일을 작성하고 전송버튼을 누릅니다. 서버는 해당 이메일 받고, 그 이메일에 대한 초대토큰을 생성한 다음 템플릿에 담고 이메일 서비스를 사용해 해당 유저에게 이메일을 전달합니다.

유저는 이 이메일을 열고, 링크를 누르면 해당 사이트로 이동합니다. 그리고 링크에 담겨있는 토큰을 서버에게 전달해서 아직 유효한지 검사를 받고, 유효할 경우 회원가입 페이지로 이동하여 유저는 가입을 진행한다음 관리자의 프로젝트 멤버로 자동 가입됩니다.

해당 시스템에선 멤버 초대 이메일은 단건 처리가 나을까, 대량 발송 방식이 나을까

이 시스템에서는 멤버 초대 이메일을 단건으로 처리하는 것이 적합하다고 판단했습니다.

먼저, 초대 워크플로우를 보면 관리자가 초대할 멤버의 이메일을 입력하고 즉시 초대하는 방식입니다. 대부분의 경우 소규모로 초대가 이루어지며, 초대에 대한 즉각적인 피드백이 중요한 상황이 많습니다.

초대 코드 생성 포멧은 뭘로 할까 (토큰 포맷인 JWT vs 랜덤 문자열 생성 방식)

JWT는 토큰 자체에 유효기간, 초대한 프로젝트 ID, 초대된 이메일 등의 정보를 담을 수 있고, 서버에서 DB 조회 없이 토큰 검증이 가능한 장점이 있습니다. 또한, 서명을 통해 토큰의 무결성도 보장할 수 있습니다.

하지만 우리 시스템의 요구사항인 일회성 사용을 만족시키기 위해서는 토큰 사용 여부를 DB에 저장해야 합니다. JWT가 자체적으로 유효기간을 가지고 있더라도, 한번 발급된 토큰은 만료 전까지 계속 유효하기 때문에 블랙리스트 관리가 필수적입니다.

또한 JWT는 Base64로 인코딩되어 있어 누구나 디코딩이 가능하므로, 토큰이 탈취될 경우 이메일과 프로젝트 ID 같은 정보가 노출되고 해커가 초대받은 이메일로 먼저 가입할 수 있는 보안 위험이 있습니다.

반면 랜덤 문자열 방식은 토큰 자체로는 어떤 정보도 유추할 수 없어 보안성이 높습니다. 토큰 검증을 위해 항상 DB 조회가 필요하지만, 어차피 일회성 검증을 위해 DB를 사용해야 하므로 큰 단점이 되지 않습니다. 또한 토큰을 언제든 즉시 무효화할 수 있어 관리가 용이합니다.

따라서 JWT는 정보 포함과 무결성 보장이 장점이나 일회성 요구사항과 보안을 고려해 랜덤 문자열 방식을 선택하고 구현했습니다.

초대 토큰 생성은 뭘로 할까 (UUID.randomUUID() vs SecureRandom)

1. SecureRandom 기반 커스텀 토큰

SecureRandom은 암호학적으로 안전한 난수를 생성할 수 있는 Java의 기본 클래스입니다. 이를 이용해 길이도 맘대로, 문자구성도 맘대로 커스텀 토큰을 만들 수 있습니다.

2. UUID 버전 4

UUID 버전 4는 16바이트의 고정된 길이와 내부적으로 SecureRandom을 사용하지만, 표준화된 형식과 검증된 안정성을 제공합니다. UUID의 경우 중복이 발생할 확률이 10억분의 1이라, 분산환경에서도 안전하게 사용할 수가 있습니다.

3. 성능 차이

SecureRandom의 길이를 16,32,36,64로 증가하면서 각각 100만번 돌리면서, UUID를 사용했을 때 충돌개수와 생성시간, 메모리 사용량을 비교했습니다.

https://gist.github.com/minsang-alt/c76353772b58d0938ae21c701e046f74

UUID와 SecureRandom 성능차이

UUID와 SecureRandom 성능차이. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

그 결과 충돌은 둘 다 일어나지 않았고, 메모리 사용량은 당연히 UUID는 16바이트이기에 고정된 결과가 나오며, 생성시간은 UUID가 압도적으로 빨랐습니다.

최종 선택: UUID 버전 4

다음과 같은 요구사항을 고려했을 때 UUID가 가장 적합하다고 판단했습니다.

토큰의 유효기간이 일주일로 짧음
삭제되는 데이터이므로 저장공간 문제가 크지 않음
프로젝트 가입에 사용되므로 중복 발생 시 심각한 문제 발생
특별한 형식이나 커스터마이징이 불필요
생성시간 짧음

UUID는 이러한 요구사항을 모두 충족하면서도 다음과 같은 장점을 제공합니다.

구현이 매우 간단
충돌 가능성이 극히 낮음
데이터베이스 인덱싱에 적합한 형식

어떤 SMTP 릴레이 서비스를 사용할까

1. Gmail SMTP

프로토타입을 구축했을 땐 Gmail SMTP로 간단하게 구축했습니다. 하지만 사용했을 때 여러가지 문제점이 있었습니다.

첫번째, 하루에 최대 500건씩만 발송할 수 있습니다. 이는 개발단계에선 적절하지만 실제 운영단계에서는 매우 부족한 수치입니다.

두번째, Google의 스팸 필터링 정책이 너무 엄격해 보낸 이메일이 쉽게 스팸 메일로 분류가 됩니다. 이는 다음과 같은 기술적 한계 때문입니다

SPF 레코드나 DKIM 인증이 제한적
커스텀 도메인을 사용할 수 없어 이메일의 신뢰성이 떨어짐
IP 평판 관리가 불가능
이메일 전송 상태 모니터링이 제한적

마지막으로, 간헐적으로 발송이 10분정도 걸립니다. gmail 끼리는 빨리 오지만, gmail -> naver로 메일이 전송될때는 10분이상 걸리며, 만들었던 템플릿도 다 깨져 나왔습니다.

이러한 문제들 때문에 Gmail SMTP는 개발 환경이나 프로토타입 단계에서만 사용하기로 결정하고 다른 기술을 찾아봤습니다.

2. AWS SES (Simple Email Service)

AWS Simple Email Service(SES)는 검증된 이메일 전송 서비스입니다. 1000건 당 약 0.10 달러라 매우 싸며, Route53과 통합하여 커스텀 도메인을 만들 수 있습니다.

또한, 메일 전송의 신뢰성 측면에서도 강점이 있습니다. ISP는 SES 서비스를 거친 이메일을 신뢰하게 되어 메일 도달 가능성이 높아지며, SPF 및 DKIM과 같은 인증 메커니즘을 지원하여 보안성도 확보됩니다.

또한 상세한 이메일 분석과 추적 기능을 제공하여 발송된 이메일의 상태를 모니터링하기 쉽습니다.

3. SendGrid

SendGrid는 Twilio가 서비스하는 클라우드 기반 이메일 서비스입니다. 개발자 친화적인 API와 직관적인 UI로 인해 많은 개발자들이 선호하는 서비스입니다.

주요 장점으로는 우선 직관적인 UI와 쉬운 API 통합을 들 수 있습니다. RESTful API와 잘 정리된 문서를 제공하여 개발자들이 쉽게 구현할 수 있습니다. 또한 풍부한 이메일 템플릿 기능을 제공하여 다양한 디자인의 이메일을 손쉽게 만들 수 있습니다.

이메일 발송 방식에서도 유연성이 높습니다. SMTP와 API 방식을 모두 지원하여 프로젝트 상황에 맞는 방식을 선택할 수 있으며, 상세한 이메일 통계와 분석 기능을 제공하여 이메일 캠페인의 성과를 정확하게 측정할 수 있습니다.

하지만 몇 가지 단점도 있습니다. AWS SES에 비해 상대적으로 가격이 높으며, 무료 티어는 일일 100건으로 제한됩니다. 또한 스팸 방지를 위한 정책이 다소 엄격하여 초기 설정에 주의가 필요합니다.

SendGrid는 다음과 같은 프로젝트에 특히 적합합니다

이메일 마케팅 기능이 함께 필요한 경우
상세한 이메일 분석이 필요한 경우
개발 리소스가 부족하여 빠른 구현이 필요한 경우

최종선택: AWS SES

멤버 초대 이메일 서비스로 AWS SES를 선택했습니다.

우리 프로젝트의 멤버 초대 이메일은 템플릿이 정형화되어 있고 변경 가능성이 적습니다. SendGrid의 풍부한 템플릿 기능이나 마케팅 도구가 필요하지 않다고 판단했습니다.

그리고 AWS SES는 1000건당 약 0.10 달러로, 다른 서비스들에 비해 매우 저렴합니다. 초대 이메일의 특성상 많은 발송이 필요할 수 있어, 비용 측면에서 큰 장점이 있습니다.

마지막으로 이메일 신뢰성입니다. AWS SES는 SPF와 DKIM 같은 이메일 인증 메커니즘을 지원하고, ISP에서도 신뢰하는 서비스이기 때문에 초대 이메일이 스팸으로 분류될 가능성이 낮습니다.

Gmail SMTP 사용했을 때와 달리 Naver SMTP 쪽으로 보내는 메일도 금방 받을 수 있었습니다.

이러한 이유들을 고려했을 때, 단순하지만 안정적이고 비용 효율적인 AWS SES가 우리 프로젝트의 멤버 초대 시스템에 가장 적합한 선택이라고 판단했습니다.

초대 코드는 어떤 DB에 저장할까

데이터 특성

초대 코드의 데이터 구조는 매우 명확합니다(초대토큰, 이메일, 만료일 등). 또한 프로젝트-초대-사용자 간의 관계가 있는 데이터입니다.

토큰은 UUID로 생성되어 중복될 확률이 매우 낮습니다. 다만 초대 링크가 1회만 사용 가능해야 한다는 요구사항이 있어, 토큰 사용과 멤버 추가가 하나의 원자적 단위로 처리되어야 합니다.

접근 패턴

초대 토큰의 유효성을 확인하는 조회는 빈번하지 않을 것으로 예상됩니다. 또한 초대 토큰을 생성하는 쓰기 작업도 상대적으로 적을 것으로 예상됩니다. 만료된 토큰의 경우 삭제가 필요합니다.

확장성

초대 데이터는 10분 후 만료되어 삭제되므로 데이터 증가율이 제한적입니다. 따라서 스케일 아웃의 필요성이 당장은 높지 않습니다.

Redis를 최종 선택한 이유

초대 코드의 유효기간이 10분으로 매우 짧기 때문에 Redis의 장점을 활용할 수 있습니다

TTL 기능으로 만료 시간 자동 관리
인메모리 데이터베이스로 빠른 응답 속도
만료된 데이터 자동 삭제로 관리가 용이

로컬 캐시에 사용할까 Remote 캐시를 사용할까

초대 토큰은 생성 후 수정 없이 만료될 때까지 유지되는 일회성 데이터입니다. 따라서 네트워크 오버헤드가 없는 로컬 캐시가 성능면에서 유리할 수 있습니다. 하지만 서버가 2대 이상으로 증가하면 한 서버에서 생성된 토큰을 다른 서버와 공유해야 하는 복잡한 문제가 발생합니다. 이러한 데이터 동기화 이슈를 피하기 위해 원격 캐시를 선택했습니다.

UUID를 키로 사용하면 너무 크기가 크다

현재 레디스에서는 이메일 초대토큰뿐만 아니라, 이슈 번호를 저장하고 있습니다. 그리고 레디스의 메모리 용량은 80프로 이내로 유지해야하기 때문에(넘어가면 스왑메모리를 사용하는 시도가 일어나고 성능저하가 일어날 것입니다) 최대한 메모리를 아껴야 할 필요가 있습니다.

키는 UUID, 값은 해시값인 이메일주소,프로젝트ID,생성시간을 저장하고 있으며 한 행이 추가될때마다 256바이트를 차지하고 있습니다. 그중 UUID는 문자열로 저장하고 있기 때문에 36바이트를 차지합니다. 또한 prefix로 11바이트가 추가되어 키의 총 용량이 47바이트입니다.

따라서, 키를 Base64url로 36바이트인 UUID를 16바이트로 바꾸고 앞에 prefix를 한글자로 줄이고, 값은 불필요한 생성시간과 수신한 이메일을 제거하니 256바이트에서 120바이트로 줄였습니다.

ThreadPoolTaskExecutor 설정은 어떤 기준으로 설정했나요

이메일은 오래 걸리는 작업이기도 하기에 비동기처리가 필요했습니다. 이때 Async 어노테이션을 사용했을 때 사용하는 스레드 풀에 대한 설정이 필요합니다.

동작방식은 다음과 같습니다.

1. 처음에는 새 작업이 들어올 때마다 corePoolSize까지 새 스레드를 생성합니다
2. corePoolSize에 도달하면, 그 이후의 작업들은 큐에 저장됩니다
3. 큐가 가득 차면(queueCapacity 도달), 추가 스레드를 생성하되 maxPoolSize를 넘지 않게 합니다
4. maxPoolSize까지 스레드가 생성되고 큐도 가득 찬 상태에서 새 작업이 들어오면 거부 정책이 실행됩니다

스레드 생명주기
- core 스레드들은 계속 유지됩니다(특별한 설정이 없다면)
- core 초과 스레드들은 일정 시간 동안 유휴 상태면 종료됩니다

1. Core Pool Size (20개)
   - 이메일 전송은 CPU 연산이 거의 없는 I/O 바운드 작업
   - 대부분의 시간이 SMTP 서버와의 네트워크 통신 대기
   - 따라서 CPU 코어 수(예: 8코어)보다 많은 20개의 스레드로 설정하여 동시 처리량 확보

2. Queue Capacity (100개)
   - 큐 크기가 너무 크면 작업이 오래 대기하여 응답 지연 발생
   - 적정 수준의 백로그 유지를 위해 100개로 설정
   - 큐가 가득 차면 MaxPoolSize까지 스레드 증가

3. Max Pool Size (40개)
   - 부하 상황에서 Core Pool Size의 2배까지 스레드 확장
   - 일시적인 트래픽 증가 대응

4. 거부정책은 CallerRunsPolicy로 이메일 발송 시, 작업이 버려지는 것을 방지하면서 시스템에 과부하가 걸리는 것을 막을 수 있도록 했습니다.

5. 성능 검증
- Ngrinder를 통한 부하 테스트 진행

- 초당 10개 → 20개 → 30개로 점진적 증가
- 설정값의 적절성 확인

- 갑자기 많은 요청 (예: 초당 100건) 발생 테스트 (Queue가 가득 찼을 때의 동작 검증)

이메일 서비스가 장애 상황일 때 어떻게 대처할까요

이메일 서비스는 외부 서비스이기 때문에 언제든 장애가 발생할 수 있습니다. 특히 사용자 입장에서는 서비스 장애를 인지할 수 없어 메일이 도착하지 않으면 계속해서 재시도를 할 수 있죠.

이러한 상황에 대처하기 위해 다음과 같은 방안들을 구현했습니다.

1. 상태 추적 시스템 구현

이메일 발송 상태를 명확하게 추적하기 위해 다음과 같은 상태값을 정의했습니다.

public enum InvitationStatus {
    PENDING,    // 초기 상태
    SENDING,    // 발송 중
    SENT,       // 발송 완료
    RETRY,      // 재시도 대기
    FAILED      // 최종 실패
}

2. Redis를 활용한 상태 관리

이메일 상태는 Redis에 저장하여 관리합니다. 이때 두 가지 키를 사용합니다.

i:{token}: 초대 코드 정보 저장
status:{email}: 이메일 발송 상태 저장

private void storeInvitationStatus(String email, InvitationStatus status) {
    String statusKey = STATUS_PREFIX + email;
    redisTemplate.opsForValue()
        .set(statusKey, status.name(), EXPIRATION_MINUTES, TimeUnit.MINUTES);
}

3. 중복 발송 방지

동일한 이메일에 대한 중복 발송을 방지하기 위해 상태를 체크합니다

private boolean hasActiveInvitation(String email) {
    String statusKey = STATUS_PREFIX + email;
    String status = (String) redisTemplate.opsForValue().get(statusKey);
    return status != null && (InvitationStatus.isPendingOrSending(status));
}

4. 비동기 처리 및 재시도 메커니즘

이메일 발송은 비동기로 처리하며, 실패 시 자동으로 재시도합니다.

@Override
@Async("emailExecutor")
@Retry(maxRetries = 3, retryFor = {GeneralException.class}, delay = 1000)
public CompletableFuture<Void> sendEmail(String subject, Map<String, Object> variables, String... to) {
    return CompletableFuture.runAsync(() -> {
        // 이메일 발송 로직
    });
}

5. 외부 서비스 호출의 리드타임아웃과 커넥션 타임아웃 설정

외부서비스에서 커넥션을 맺는데 걸리는 시간에 대한 타임아웃과 처리하는데 걸리는 타임아웃을 추가적으로 설정해서 스레드가 오랜 시간동안 물고 있는 것을 방지하여 리소스를 낭비하지 않도록 했습니다.

    @Bean
    public AmazonSimpleEmailService amazonSimpleEmailService() {
        BasicAWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);
        return AmazonSimpleEmailServiceClientBuilder.standard()
            .withRegion(Regions.AP_NORTHEAST_2)
            .withCredentials(new AWSStaticCredentialsProvider(credentials))
            .withClientConfiguration(new ClientConfiguration()
                .withConnectionTimeout(3000)
                .withSocketTimeout(5000)
                .withRequestTimeout(10000))
            .build();
    }

@Async와 @Retryable 같이 사용할 때 주의할 점

# 프록시 순서 이해

프록시 순서를 이해해야 합니다. 순서가 잘못되면 에러가 발생 시, 재시도로직이 발생되지 않고 혹은 블로킹이 발생할 수 있습니다.

@Async
@Retryable
public CompletableFuture<String> method() { ... }

이 둘의 순서는 Async가 우선순위가 높기 때문에, @Async 프록시가 먼저 실행되어 새로운 스레드에서 작업이 실행되고 그 다음 @Retryable 프록시가 재시도 로직을 처리합니다.

// AsyncAnnotationBeanPostProcessor의 order
public static final int DEFAULT_ASYNC_ADVISOR_ORDER = Ordered.HIGHEST_PRECEDENCE + 2;

// RetryOperationsInterceptor의 order
private int order = Ordered.LOWEST_PRECEDENCE;

# 반환 타입 주의하기

// 잘못된 예시
@Async
@Retryable
public String wrongMethod() { ... }  // CompletableFuture로 감싸지 않음

// 올바른 예시
@Async
@Retryable
public CompletableFuture<String> correctMethod() { ... }

@Async 메서드는 CompletableFuture, Future, void 타입으로만 반환해야 합니다. String과 같은 일반 타입을 반환하면 실제 결과값을 기다려야 하므로 비동기 처리가 무의미해집니다.

# 예외처리 설계

발생한 예외에 대한 복구 로직 혹은 최종로직이 필요합니다. 따라서 @Recover을 사용하던가, 아니면 CompletableFuture을 반환하여 예외처리 로직을 구현해야합니다.

smtpService.sendEmail("AgileHub 초대 메일", variables, sendInviteMail.getEmail())
    .thenRun(() -> {
        storeInvitationStatus(sendInviteMail.getEmail(), InvitationStatus.SENT);
        log.info("이메일 전송 완료");
    })
    .exceptionally(e -> {
        // 여기서는 모든 재시도가 실패한 후의 최종 실패 처리
        log.error("이메일 전송 최종 실패", e);
        storeInvitationStatus(sendInviteMail.getEmail(), InvitationStatus.FAILED);
        return null;
    });

[이슈 #1] 커넥션 풀 고갈 문제를 Redis Atomic 연산으로 개선하기

EVO. — Sun, 1 Dec 2024 18:59:39 +0900

장애 상황

이슈 생성 API의 부하 테스트를 통해 안정적인 서비스 제공과 우수한 성능을 달성하는 것을 목표로 설정했습니다.

그러기 위해서 대규모 조직(1000명 이상)에서 50~100명의 사용자가 동시에 이슈를 생성하는 상황을 가정했을 때, 다음과 같이 요청-응답 시간(MTT)은 1~2초 이내, TPS는 30~40, 에러율은 0.1% 이하, 테스트 시간은 1분 이내인 성능 지표를 목표로 삼았습니다

TPS를 30~40으로 잡은 이유 (1000명 조직 기준 예상 시나리오)

- 1인당 하루 평균 5-10개 이슈 생성
- 8시간 근무 기준: 1000명 × 10개 ÷ 8시간 ÷ 3600초 ≈ 0.34 TPS
- 피크 타임(10배 부하) 고려: 약 3 TPS - 버퍼(10-20배)를 둬서 30-40 TPS 설정

가상 사용자(VUser)를 점진적으로 늘려가던 중, 20명인 시점에서 문제가 발생했습니다.

20명임에도 불구하고, 높은 에러율과 MTT가 제 눈에 봐도 정상적인 상황은 아니었습니다.

원인 분석

장애 발생 시 가장 먼저 해야 할 일은 뭘까

만약 배포 직후 장애가 발생했다면 가장 먼저 롤백을 진행합니다. 롤백 시에는 feature 브랜치에서 배포된 버전을 되돌리는 것이 아니라, master 브랜치에서 새로운 브랜치를 따서 배포를 진행합니다. 이때 리비전 없이 마스터를 바로 내보내는 것이 중요합니다.

문제가 된 feature 브랜치는 어떻게 할까요? 이 브랜치는 테스트 서버나 스테이징 서버에 배포하여 문제를 확인합니다. 특히 스테이징 서버는 운영 환경과 동일하게 구성되어 있기 때문에 정확한 테스트가 가능합니다.

배포와 관계없이 장애가 발생할 수도 있습니다. 이런 경우는 상황에 따라 대응 방법이 달라집니다. 트래픽 급증으로 인한 장애이고, AWS를 사용하고 있다면, 오토스케일링을 활용해 빠르게 서버를 증설하거나, 스팟 서버를 추가로 띄워서 대응할 수 있습니다.

인바운드나 아웃바운드 같은 정책 문제라면 즉시 인프라팀에 연락해서 상황을 전달합니다. 이런 문제는 개발팀 단독으로 해결하기 어렵기 때문이죠.

장애 원인은 어떻게 찾나요?

1. 로그 기반 분석

로그 시스템이 잘 구축된 회사라면 장애 발생 시의 로그가 남아있을 것입니다. 직접 로그를 분석하면 되고, 만약에 로그가 날아가면 배포 시점의 에러 로그를 최대한 수집해서 분석해야 합니다.

배포 시점의 에러 로그 최대한 수집이란?

보통 서비스에서는 로그를 저장하는 두 가지 방식이 있습니다.

1. 서버 로컬에 로그 저장

- 서버에 직접 로그 파일을 저장
- 서버가 재시작되거나 롤백되면 로그가 사라질 수 있음

2. 중앙 로그 시스템 사용 (ELK, CloudWatch 등)

- 로그를 외부 시스템에 실시간으로 저장
- 서버가 재시작되어도 로그가 보존됨

만약 중앙 로그 시스템이 없고 로컬에만 로그를 저장하는 상황이라면, 장애가 발생했을 때 롤백하기 전에 현재 서버의 로그를 다른 곳에 빠르게 복사해 두거나, 에러 메시지를 캡처해 두거나 로그 파일을 다운로드하여두는 등의 작업을 해야 합니다.

왜냐하면 롤백을 하면 서버가 재시작되면서 로컬의 로그가 모두 사라질 수 있기 때문입니다. 이렇게 미리 로그를 수집해두지 않으면, 나중에 어떤 에러가 발생했었는지 분석하기 어려워집니다.

2. 테스트 환경에서 재현

여러 개의 존(zone)이 있다면, 다른 존에 배포해서 동일한 상황을 재현해 볼 수 있습니다. 테스트 존에 같은 트래픽을 발생시켜 문제 상황을 재현하고 분석하는 거죠.

특수한 장애 상황별 대처법

OOM이나 힙 메모리가 가득 찬 경우: 힙덤프를 추출하여 분석
API 응답이 현저히 느려진 경우: 스레드덤프를 추출하고 분석기로 확인
갑작스러운 에러 로그 급증: 인프라 환경을 먼저 확인

그래서 내 서버의 장애는 어떻게 파악했는가

develop 브랜치로 테스트 서버에 배포해서 부하테스트를 진행 중이라, 롤백을 할 필요가 없었습니다. 서버도 재시작하지 않았기 때문에 SSH로 서버에 들어가, 로그파일을 확인해 보니 Could not open JPA EntityManager for Transaction 줄과 request timeout (30000ms) 줄이 동시에 찍혀 있었습니다.

EntityManager가 트랜잭션을 열수 없다는 것은 즉, db 커넥션이 없다는 건데, 아마 HikariPool에 생성된 커넥션이 고갈되었다는 것이고, 요청이 제대로 이루어지지 않아 대기하다가 타임아웃이 걸렸다는 추측을 했습니다.

JPA EntityManager와 DB 커넥션의 관계

EntityManager는 DB와의 연결을 위해 커넥션 풀(HikariCP)에서 커넥션을 가져와 사용합니다. 이때 사용 가능한 커넥션을 얻지 못하면 "Could not open JPA EntityManager for Transaction" 에러가 발생하게 되죠.

더 알고 싶다면?
EntityManager가 DB와 통신하는 전체 과정은 꽤 흥미롭습니다. DB와 HikariCP의 커넥션 수립(3-way handshake), 하이버네이트 세션 생성, EntityManager의 ThreadLocal 세션 관리 등 자세한 내용이 있습니다.

이 부분이 궁금하시다면 하이버네이트 공식 문서나 관련 기술 블로그들을 참고해 보세요.

더 정확한 원인을 찾기 위해 상황을 재연하여 커넥션 풀과 스레드 상태를 확인해 보면 좋을 것 같다는 생각이 들었습니다.

모니터링 도구 선택

스레드 덤프를 뜨기 위한 도구는 여러 가지 있습니다.

급하게 혹은, 특정 시점의 스레드 상태만 확인하기 위해서는 kill -3 PID, jstack 명령어를 활용하면 스레드 덤프를 생성할 수 있습니다.

JProfiler는 시스템 성능, 메모리 사용량, 잠재적인 메모리 누수, 스레드 프로파일링을 볼 수 있는 인터페이스를 제공합니다. 이는 원격 시스템에 아무것도 설치하지 않고도 원격시스템에서 실행되는 Java 애플리케이션을 프로파일링 할 수 있습니다.

또한, DB모니터링도 가능하며 DB 호출트리(SQL 쿼리 실행 경로, N+1 문제 식별), 커넥션 누수 감지(커넥션 풀 상태 모니터링)의 기능이 있습니다. 그리고 객체 인스턴스의 메모리 사용량을 볼 수 있는 데 라이브 객체 ,가비지 수집 객체 모두 선택하는 기능도 제공합니다.

YourKit는 스레드, 가비지 수집, 메모리 사용 및 메모리 누수를 시각화합니다. 또한 어떤 예외가 발생했고 각 예외가 발생한 횟수를 쉽게 확인할 수 있습니다. 조건부 프로파일링이 가능하며 SQL,NoSQL 호출을 프로파일링 가능합니다.

VisualVM은 메모리 및 CPU 프로파일링을 지원하고 SSH 터널링이 지원되지 않아 자격 증명(호스트 이름 및 IP 및 비밀번호)을 제공해야 합니다. 또한 실시간 프로파일링이 가능합니다. 추가적으로 스냅샷을 찍을 수 있습니다.

스레드 상태와 커넥션 풀 모니터링을 위해 VisualVM을 사용했습니다. 가장 많이 쓰이기도 하고, 사용법도 직관적이라 선택했습니다.

스레드 덤프 분석

부하테스트를 2분간 진행하며, 다음 에러가 로그에 찍힐 때 스레드 덤프를 찍었습니다.

해당 로그를 살펴보면, HikariPool에선 10개의 커넥션이 각 스레드에 할당되어 활성화 중입니다. 그리고 더 이상 커넥션은 없어 20개의 스레드가 대기 중인 상태이며, 커넥션을 기다리는 스레드들이 30초간 기다리다가 타임아웃이 발생하여 에러가 발생했습니다.

그래서 이 타임아웃이 왜 발생했는지, 왜 30초동안 커넥션을 받지 못했는지 알기 위해 그 시간대 근처의 스레드 덤프를 확인하기 위해 해당 덤프를 https://fastthread.io/ 에 분석해 봤습니다.

23개의 톰캣 스레드가 TIMED_WAITED 상태이고, 15번 스레드의 스택 트레이스를 확인해 보겠습니다.

이슈를 생성하기 전, 생성하려는 멤버가 프로젝트에 속한 멤버인지 확인하기 위해 먼저 프로젝트를 가져오기 위해 커넥션이 필요합니다. 이때 커넥션이 부족해 대기상태로 변한 상태를 보여주고 있습니다.

이번엔 1번 스레드의 스택 트레이스를 보겠습니다.

Epic 타입의 이슈를 생성하는 과정에 이슈번호를 생성하기 위해 커넥션이 필요한 상황입니다. handleExistingTransaction의 메소드가 호출한 것을 보아하니 이미 해당 스레드에선 트랜잭션을 갖고 있는 상태입니다.

handleExistingTransaction을 조금 더 살펴보면,

호출된 메소드의 트랜잭션 전파속성이 5번인 PROPAGATION_NEVER일 때는 트랜잭션이 이미 존재한다면서 예외가 발생합니다.

4번인 PROPAGATION_NOT_SUPPOERTED일 때는 진행 중이었던 트랜잭션은 중단(suspend)하고 트랜잭션 없이 진행됩니다.

3번인 PROPAGATION_REQUIRES_NEW 일 때는 새로운 트랜잭션이 시작됩니다.

IssueNumberGenerator의 generate 메소드는 전파속성이 PROPAGATION_REQUIRES_NEW 이기 때문에 새로운 커넥션을 기다리고 있습니다.

1번 스레드와 같은 애들이 10개, 15번 스레드와 같은 애들이 13개 존재했습니다. 원인을 찾았으니, 이제 그림을 그려 다시 전체적인 모습을 보여드리겠습니다.

트랜잭션 경계 설정 잘못으로 인해 발생한 커넥션 고갈 도식화

요청 전 idle 상태

Ngrinder Agent를 통해 WAS로 요청이 들어오면, Tomcat Thread Pool에서 요청을 처리하기 시작합니다.
각 스레드(1번, 15번 등)는 DB 작업을 위해 HikariCP의 커넥션 풀에 접근하게 됩니다.

1. 10개의 스레드가 첫 번째 트랜잭션에서 커넥션을 이미 보유한 상태
2. 동일한 스레드들이 두 번째 커넥션을 요청했지만 커넥션 풀이 고갈된 상태
3. 각 스레드는 30초, 10초, 20초 등 서로 다른 타임아웃 시점에 커넥션을 기다리는 중
4. 커넥션 타임아웃(30초)이 발생하면 예외가 발생하고 스레드는 보유하던 커넥션을 반납
5. 반납된 커넥션은 대기 중이던 다른 스레드(예: 15번)가 획득하여 같은 패턴을 반복

이러한 순환적인 대기 상태가 계속되면서 시스템의 성능이 저하되고 요청 처리가 지연되는 문제가 발생합니다.

문제해결 : 트랜잭션 전파 속성과 커넥션 풀 최적화

IssueNumberGenerator에서 이슈 번호를 생성할 때, 전파속성을 REQUIRES_NEW 로 한 이유는 동시성 문제를 막기 위해 비관적 락을 두고, 짧은 트랜잭션을 가져가 성능을 챙기기 위함이었습니다.

하지만 커넥션 풀 개수를 잘못 설정하면 요청이 증가할수록 커넥션 데드락이 발생하기 쉬워지고 개수 설정도 쉽지 않았습니다. 당장 성능보다 중요한 것은 장애가 발생하면 안 되는 것이기 때문에 이슈생성을 하나의 트랜잭션에서 수행하도록 REQUIRES_NEW -> REQUIRED 기본값 이 가장 적절하여 변경했습니다.

톰캣 스레드 풀과 HikariCP 커넥션 풀 설정

톰캣 스레드 풀 > HikariCP 커넥션 풀 일 때는 많은 스레드가 적은 수의 커넥션을 기다리는 상황이 발생하고 불필요한 스레드 생성과 컨텍스트 스위칭 오버헤드가 발생합니다.

톰캣 스레드 풀이 너무 작으면 커넥션 풀의 리소스가 충분히 활용되지 않아 전체적인 처리량이 감소합니다. 따라서 서로 매우 밀접한 관계를 갖고 있기 때문에 부하테스트를 통해 가장 적절한 개수를 찾았습니다.

maximum-pool-size와 minimum-pool-size를 동일하게 맞춰 항상 커넥션이 살아있도록 유지하고 connection-time-out은 기본설정 30초는 너무 길기 때문에 5초로 빠른 응답을 할 수 있도록 했습니다. (또한 3초는 너무 짧아 에러율이 높으므로 최적의 설정이 5초)

HikariCP의 max-lifetime은 50초로 둬, MySQL의 wait_timeout보다 짧게 줬습니다.

pool size는 부하테스트를 진행하여 최적의 개수가 8개임을 확인 (너무 많이 줘도 개선이 크게 일어나지 않고, 리소스는 많이 잡아먹는 상황이기 때문), 톰캣 스레드 최대 개수는 10개가 최적임을 확인했습니다.

HikariCP의 max-lifetime을 MySQL wait_timeout 보다 짧게 준 이유

MySQL 서버는 wait_timeout 시간 동안 유휴 상태인 연결을 자동으로 종료합니다. 이때 애플리케이션은 해당 연결이 끊어졌다는 사실을 즉시 알 수 없기 때문에, 끊어진 연결을 통해 쿼리를 실행하려고 시도하면 "The last packet successfully received from the server was X milliseconds ago" 같은 에러가 발생할 수 있습니다.

HikariCP의 max-lifetime을 MySQL의 wait_timeout보다 짧게 설정하면, 커넥션 풀이 MySQL 서버가 연결을 강제로 끊기 전에 선제적으로 연결을 갱신할 수 있습니다. 예를 들어 MySQL의 wait_timeout이 28800초(8시간)로 설정되어 있다면, HikariCP의 max-lifetime은 1800초(30분)이나 그 이하로 설정하는 것이 좋습니다.

결과

VUser 100인 상황에서도 더 이상 에러율이 발생하지 않았지만, MTT와 TPS는 처음 목표에 달성하지 못했습니다.

성능 개선: Redis atomic ICNR 연산

Redis를 사용한 이유

이슈 번호 생성 시 사용된 비관적 락이 이슈 생성 전체에 걸렸기 때문에 낮은 성능을 보여줍니다.

우선적으로 시도한 건, 이슈 생성 시 많은 조회 쿼리가 발생하기에 해당 쿼리 익스프레인을 확인했습니다.

가장 의심이 갔던 left join이 2번 진행됐지만, 인덱스 걸린 외래키로 조인하기 때문에 성능 상 문제가 없었습니다.

두 번째 낙관적락으로 Retry 3회로 바꾸고 성능을 측정했지만, 충돌 증가로 비관적락보다 성능이 더 저하되었습니다.

이를 해결하기 위해 NoSQL 중 Redis를 선택했습니다. 그 이유는 인메모리 기반으로 동작하여 디스크 I/O가 발생하지 않아 매우 빠른 속도를 보장하며, Redis의 INCR 명령어가 단일 스레드로 동작하고 원자성을 보장하기 때문에, 별도의 락 처리 없이도 동시성 문제를 해결할 수 있었습니다. 마지막으로 Redis는 이미 저희 시스템에서 캐시용도로 사용 중 이기 때문에, 추가적인 인프라 구축 없이 도입이 가능했습니다.

Redis의 캐싱 전략 선택 : Write-Behind

Redis의 캐싱 전략은 다음과 같습니다.

Cache-Aside (Lazy Loading): 데이터를 찾을 때 먼저 Redis를 확인하고, 없으면 DB에서 가져와 Redis에 저장합니다. 실시간성이 중요하지 않은 데이터에 적합합니다.
Write-Through: 데이터를 쓸 때 DB와 Redis에 동시에 작성합니다. 데이터 일관성은 보장되지만 쓰기 지연이 발생할 수 있습니다.
Write-Behind (Write-Back): 데이터를 먼저 Redis에 쓰고, 나중에 비동기적으로 DB에 기록합니다. 높은 쓰기 성능이 필요할 때 유용합니다.
Read-Through: 애플리케이션이 캐시 계층에만 요청하고, 캐시가 없으면 캐시가 직접 DB에서 로드합니다.

저희의 목적은 이슈 번호 생성을 Redis에 옮겨서 쓰기 성능을 높이기 위함이기 때문에, Write-Behind 전략을 이용했습니다.

출처: https://hackernoon.com/the-system-design-cheat-sheet-cache

동기화 전략은 Redis의 이슈 번호 데이터를 30초마다 스케줄러로 비동기식으로 DB에 동기화하는 방식으로 구현했습니다.

동기화 주기를 30초로 정한 이유는 뭔가요

동기화 주기는 서비스의 데이터 특성과 사용 패턴을 고려해서 30초로 정했습니다. Redis에서 생성된 순수 이슈 번호는 즉시 'PRJ-123'과 같은 형태로 가공되어 별도 테이블에 저장되고, 실제 서비스에서는 이 가공된 형태로만 조회됩니다.

따라서 Redis의 원본 번호가 RDB와 일시적으로 동기화가 안 되어도 서비스 동작에는 전혀 영향이 없었습니다.

이런 구조적 특성 덕분에 동기화 주기를 너무 짧게 가져갈 필요가 없었고, 30초 정도면 시스템 부하와 리소스 사용 측면에서 적절한 밸런스를 보여줬습니다.

Redis가 갑자기 장애가 발생한다면

Write-Behind 전략이기 때문에 더더욱이나 가용성에 신경 써야 했습니다. Redis Replication과 Redis Cluster 방식으로 고가용성을 보장할 수 있는데, 이슈 번호 생성이라는 단순한 카운터 용도였고, 데이터 크기도 크지 않아 Replication만으로도 충분한 가용성을 확보할 수 있었습니다.

Cluster는 복제 및 스케일아웃의 장점이 있지만, 구성이 복잡하고 관리 포인트가 늘어나는데 비해, 현재 요구사항에서는 그만한 이점이 없다고 판단했습니다.

또한 고가용성을 보장하려면 단순히 Replication을 쓰면 Master 노드가 내려갈 때 Replica 노드가 Master로 되기 위해서 수동으로 조작해야 하지만 Sentinel을 도입하여 자동 페일오버가 이뤄지도록 했습니다. Sentinel은 Master 노드의 헬스체크를 수행하다가 장애를 감지하면, Replica 중에서 새로운 Master를 선출하고 클라이언트에게 새로운 Master 정보를 전달합니다.

Replication에 대해 더 많은 내용은 다음 글에 정리했습니다.

https://evoblog.life/redis-replication/

Redis Replication 기본 개념

Redis 버전 7.0.15 기준으로 설명합니다. Redis Master Slave Architecture 기본적인 Redis Replication 구조는 Master-Replica 구조로 이루어져 있습니다. Master는 데이터를 저장하고, Replica는 Master의 데이터를 복제합

evoblog.life

최종 결과

최종적으로 100 VUser 기준 1분간 부하테스트 결과, TPS가 33에서 68로 증가하고 평균 응답시간이 2.9초에서 1.4초로 개선되어 당초 목표였던 응답시간 2초 이내를 달성할 수 있었습니다.

이번 경험을 통해, 프로젝트에 맞는 HikariPool과 톰캣 스레드의 설정의 중요성과 Redis 성능 개선 체감을 더 할 수 있었던 경험이었습니다.

이슈 번호 생성의 동시성 문제와 커넥션 풀 최적화 여정

EVO. — Sat, 9 Nov 2024 21:06:51 +0900

사전 지식

이슈란

이슈란 팀이 프로젝트를 진행하면서 관리해야 할 모든 종류의 작업, 버그, 개선사항, 요청 등을 포괄합니다.

1. 이슈 유형
- 스토리(Story): 사용자 요구사항이나 기능 개발을 의미합니다.
- 버그(Bug): 시스템 오류나 문제를 추적합니다.
- 태스크(Task): 구체적인 작업 단위를 나타냅니다.
- 에픽(Epic): 여러 스토리와 태스크를 포함하는 큰 단위의 작업입니다.

2. 설명 및 요약(Description & Summary)
- 작업의 목적, 세부 내용, 예상 결과 등을 기술합니다.

이슈번호(PROJECT-1 같은 형식)를 사용하는 이유

- 커뮤니케이션 효율성
짧고 명확한 참조: "PROJECT-123"처럼 간단히 이슈를 지칭할 수 있음
구두 커뮤니케이션: 회의나 대화에서 쉽게 언급 가능
"PROJECT-123 버그 수정했어요" vs "로그인 페이지에서 발생하는 validation 오류 수정했어요"

- 시스템적 이점
유니크한 식별자: UUID나 DB의 auto increment와 달리 사람이 읽기 쉬운 형태
프로젝트 구분: PROJECT-1, BACKEND-1 처럼 프로젝트별 구분이 즉각적으로 가능
정렬/필터링 용이성: 숫자 기반으로 순차적 정렬이 자연스러움

# 1. 문제 상황 (이슈 번호 생성 시 발생한 동시성 문제)

프로젝트의 이슈를 생성하는 과정에서 동시성 문제(Race Condition)가 발생했습니다. 여러 사용자가 동시에 이슈를 생성할 때, 같은 이슈 번호(예: PROJECT-1)가 중복 생성되는 현상이 발견되었습니다.

문제가 발생한 코드는 다음과 같습니다

int issueNumber = (int) (issueRepository.countByProjectKey(project.getKey()) + 1);

이슈 번호 생성 과정을 살펴보면

DB에서 현재 프로젝트의 총 이슈 개수를 조회합니다.
조회한 값에 1을 더해 새로운 이슈 번호를 생성합니다.
생성된 번호로 이슈를 저장합니다.

이 과정이 하나의 원자적인 단위로 실행되지 않기 때문에, 여러 사용자가 동시에 이슈를 생성할 때 같은 이슈 번호가 만들어질 수 있습니다.

아래 다이어그램에서 더 자세히 볼 수 있습니다.

1-1. synchronized나 ReentrantLock으로 해결이 될까?

이슈 생성 요청은 에픽, 스토리 등 이슈 타입에 따라 각각 다른 트랜잭션으로 처리됩니다.

하지만 이슈 번호를 생성할 때는 모두 동일한 DB 자원(프로젝트별 이슈 개수)에 접근합니다.

자바의 synchronized나 ReentrantLock은 단일 JVM 내의 메모리 공유자원만을 동기화 보장 하기 때문에 다음과 같은 한계가 있습니다

다중 서버 환경: 서버가 여러 대인 경우(Scale-out) 다른 서버의 락을 인식할 수 없습니다.
성능 이슈: 모든 이슈 생성 요청 메소드(프로젝트나 이슈 타입이 달라도)에 락을 걸게 되면 순차적으로 처리해야 하므로 심각한 성능 저하가 발생합니다.

따라서 애플리케이션 레벨의 락이 아닌, 데이터베이스 레벨의 동시성 제어(낙관적 락 또는 비관적 락)를 사용하는 것이 적절합니다.

1-2. 이슈 번호 관리를 위한 테이블 분리의 필요성

현재 이슈 테이블 구조입니다.

이 구조에서는 다음과 같은 문제가 있습니다.

낙관적 락 적용 불가
- 이슈 번호 생성을 위해 전체 이슈를 count하고 새 이슈를 저장하는 과정이 별도 작업
- count 쿼리와 이슈 저장 사이에 버전 관리가 불가능
비관적 락의 한계
- 이슈 테이블 전체에 락을 걸어야 함
- 다른 이슈 생성이 모두 대기 상태가 되어 심각한 성능 저하 발생
이슈 삭제 시 이슈 번호 생성 문제
- 이슈 삭제 후, 이슈를 생성할 때 똑같은 개수로 같은 이슈번호로 생성 문제

따라서 이슈 번호 관리를 위한 별도의 테이블 분리가 필요합니다.

1-3. 낙관적 락과 AOP를 활용한 이슈 번호 동시성 문제 해결

이슈 번호 생성의 동시성 문제를 해결하기 위해 두 가지 전략을 결합했습니다.

1. 낙관적 락 적용

2. AOP를 활용한 재시도 로직 구현

@Transactional과 함께 @Retry 사용 시 프록시를 만들 때 트랜잭션이 먼저 적용되고 커밋되도록 구성해야 합니다.

스프링 AOP에서 프록시는 기본적으로 @Order 값이 작은 것이 더 바깥쪽 프록시가 됩니다. @Transactional의 기본 순서는 가장 마지막(Ordered.LOWEST_PRECEDENCE)입니다.

프록시 실행 순서

@Retry (외부) → 재시도 로직 시작
@Transactional (내부) → 트랜잭션 시작
실제 메서드 실행
트랜잭션 커밋
실패시 재시도

이렇게 구성해야 각 재시도마다 새로운 트랜잭션이 생성되어 정상적으로 동작합니다.

3. 실제 사용

트랜잭션 전파 속성을 REQUIRES_NEW로 설정한 이유는 호출하는 상위 메서드의 트랜잭션과 분리하기 위해서입니다. 만약 기본 전파 속성(REQUIRED)을 사용하면 상위 트랜잭션에 참여하게 되어, 재시도(Retry) 시에도 같은 트랜잭션 컨텍스트를 사용하게 되므로 낙관적 락 충돌이 해결되지 않습니다.

4. 테스트

테스트 방법은 ForkJoinPool의 스레드로 (프로젝트에 속한 팀원이 10명이라 가정) 이슈를 생성하도록 합니다.

10명의 사용자가 이슈를 생성하려다보니 테스트코드가 간헐적으로 실패합니다. 따라서 10명이 동시에 감당할 수 있는 Retry 횟수를 5회로 증가시켰습니다.

테스트 결과는 테스트를 하기 위한 준비 과정과 삭제 과정이 모두 포함되어 있기 때문에 정확한 테스트는 아닙니다. 비관적 락과 성능을 비교하기 위해서 입니다.

1-4. 비관적락을 활용한 이슈 번호 동시성 문제 해결

비관적 락은 데이터베이스 수준의 X-Lock(배타적 잠금)을 사용하여 동시성을 제어하는 방식입니다. 트랜잭션이 시작될 때 lock을 걸어 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 막습니다.

데이터베이스에서의 동작

테스트 코드는 동일하게 유지됩니다. 비관적 락을 사용하면 동시 요청이 들어와도 순차적으로 처리되어 동시성 문제가 해결됩니다.

1-5. 이슈 번호 생성에 비관적 락 선택 이유

1. 트랜잭션 분리로 인한 안정성

이슈 번호 생성이 독립적인 트랜잭션으로 실행되고 다른 트랜잭션과 완전히 분리되어 데드락 발생 가능성이 없습니다.

또한 짧은 트랜잭션으로 락 유지 시간이 짧습니다.

2. 성능상 이점

비관적 락은 충돌 없이 한 번에 처리되고, 재시도가 필요가 없습니다. 앞에서도 낙관적 락은 800ms, 비관적락은 550ms 정도로 차이가 있습니다.

# 2. 문제 상황 (성능 테스트 결과 및 문제 상황)

2-1. 초기 성능 테스트 (VUser 10)

비관적 락으로 동시성 문제를 해결한 후, 실제 서비스에서의 성능을 확인하기 위해 nGrinder로 부하 테스트를 진행했습니다. 첫 테스트는 VUser 10명으로 진행했으며, 테스트의 정확성을 위해 이미지 업로드는 제외했습니다.

테스트 결과

- TPS(Transaction Per Second): 평균 65.9, 최대 68.5

- 평균 응답시간: 151ms

- 에러율: 0%

- 총 처리 건수: 3,562건

그래프에서 볼 수 있듯이 TPS가 안정적으로 유지되고 있으며, 응답시간도 매우 양호한 수준을 보여주었습니다.

2-2. VUser 20명의 동시 요청 시 Connection Pool 고갈

시스템의 한계를 확인하기 위해 VUser를 20명으로 증가시켜 테스트를 진행했습니다. 그 결과, DB Connection Pool 고갈 문제가 발생했습니다.

커넥션 풀이란

애플리케이션 서버가 띄워질 때 미리 서버와 DB가 연결된 커넥션을 미리 생성해 두고, 그 커넥션을 미리 만들어 둔 공간을 커넥션 풀이라 합니다.

조회를 할 때, 커넥션 풀에서 커넥션을 하나 빌려오고 DB 와 연결을 하고 DB 처리가 완료되면 커넥션을 반납합니다.

그 이 에러는 DB 처리를 위한 커넥션이 모자르다는 것이고, 커넥션 풀에 충분한 커넥션이 없거나, 빌려간 커넥션이 반납되지 않고 계속 사용중이거나 입니다.

실제 원인을 생각해보기 위해 다시 아까 수정한 코드를 반영해서 다이어그램을 그렸습니다.

커넥션 고갈의 문제점으로 파악되는 원인은

1. 낙관적 락 구현 시 적용했던 REQUIRES_NEW 옵션으로 인해 하나의 요청에서 2개의 Connection을 사용하게 됩니다. 현재는 비관적 락을 사용하고 있으므로 이 설정은 제거가 가능합니다.

2. 특히 이미지 업로드가 포함된 경우, S3 업로드 시간 동안 DB Connection이 불필요하게 유지됩니다.

3. 전체 이슈 생성 로직이 하나의 트랜잭션으로 묶여있어, Connection 유지 시간이 길어집니다. 이는 Connection Pool에서 사용 가능한 Connection 수를 제한하는 원인이 됩니다.

2-3. HikariCP 설정

기본 설정

1. max와 min을 동일하게 맞춰 항상 커넥션이 살아있도록 유지

이유

커넥션 생성은 비용이 큰 작업
갑자기 트래픽이 증가할 때 새로운 커넥션을 생성하는 시간 만큼 지연 발생
미리 커넥션을 생성해두면 즉시 응답 가능
특히 응답속도가 중요한 이슈 생성 시스템에서는 이 방식이 유리

2. connection-timeout을 3초로 유지

이유

시스템 상 안정성보다는 실시간 응답이 더 중요하다고 판단했습니다
validation-timeout과 statement-timeout을 각각 1초,2초로 두고 총 connection-timeout을 3초로 두었습니다.

3. DB(MySQL)의 wait_timeout과 HikariCP의 max-lifetime의 관계

wait_timeout이란, DB가 유휴 상태의 커넥션을 강제로 끊기까지 기다리는 시간 입니다.

MySQL의 기본 값은 SHOW VARIABLES LIKE '%wait_timeout%'; 확인해보면 28800초 = 8시간 입니다.

문제는 max-lifetime을 DB의 wait_timeout보다 작게 설정해야 합니다. 만약 HikariCP의 max-lifetime이 DB의 wait_timeout보다 크다면, 다음과 같은 에러를 볼 수가 있습니다.

1. DB에서 커넥션 타임아웃 발생 (wait_timeout)
2. 애플리케이션은 이를 모른 채 커넥션 사용 시도
3. 'Connection is closed' 에러 발생

4. Connection Pool과 스레드의 상관관계 (HikariCP 데드락)

스레드와 함께 Pool Locking 이라는 유명한 이슈가 발생할 수 있습니다.

Pool Locking이란, 커넥션 풀의 모든 커넥션이 사용 중이고, 새로운 요청들이 계속 들어오고, 커넥션을 얻기 위해 많은 스레드가 대기할 때

스레드 병목 현상 발생하며, 최악의 경우 데드락이 발생할 수 있으므로 적절한 풀 개수를 설정해야 합니다.

예를들어 현재 한 트랜잭션 (하나의 스레드)에서 커넥션을 물고 있는 상태로, 커넥션을 하나 더 사용하려고 시도하는 데, 모든 스레드가 커넥션을 하나 씩 들고 풀에 남은 커넥션이 없어 서로가 서로를 기다리는 데드락이 발생하게 됩니다.

이 문제는 유명한 문제로 (https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing) 공식이 존재합니다.

pool size = 최대 스레드 수 X (단일 스레드에서 최대 커넥션 수 - 1) + 1

하지만 공식이 여기에선 너무 극단적이므로 일반적으로 톰캣 스레드 수의 1/10 정도로 설정 (200/10 = 20) 했습니다.

hikari 설정

2-4. 트랜잭션 범위를 짧게 설정하기

기존 코드는 트랜잭션이 이슈생성 전체로 묶여있습니다.

실제 문제가 생길 수 있는 부분에만 트랜잭션을 둬서 짧게 가져가도록 다음과 같이 수정했습니다.

2-5. 문제 발생 원인과 성능 테스트 결과

기존에는 Hikari Pool의 설정을 하지 않았습니다. 즉, 커넥션 풀에 10개만 있는 상황이었고, VUser는 20인 상황에서 각 요청당 커넥션 2개 필요 (REQUIRES_NEW 때문) 했습니다.

이렇게 되면 5개의 요청만 정상 처리 가능 (10개 커넥션 ÷ 2)하고, 나머지는 커넥션을 기다리다 타임아웃이 생기며 심지어 첫 번째 커넥션을 잡고 두 번째를 기다리는 데드락 상황 발생한 것 이었습니다.

이 문제에 대한 다이어그램입니다.

앞서 Hikari Pool size를 늘리고, 트랜잭션 전파 옵션을 수정한 뒤 VUser 20으로 다시 테스트 했습니다.

VUser 10일 때와 달리 TPS도 절반으로 떨어지고, MTT도 증가했지만 커넥션 풀로 인한 에러는 더이상 발생하지 않았습니다.

# 3. 요약

주요 성과

1. 이슈 번호 생성 시 동시성 문제 해결

비관적 락을 활용하여 안정적인 이슈 번호 생성 구현
낙관적 락 대비 약 30% 향상된 성능 달성 (처리 시간 800ms → 550ms)
별도의 이슈 번호 관리 테이블 도입으로 구조적 개선

2. 커넥션 풀 관련 성능 문제 해결

HikariCP 최적화 설정 적용 (pool size, timeout 등)
트랜잭션 범위 최소화 및 전파 속성 수정
불필요한 REQUIRES_NEW 제거로 커넥션 사용량 절반으로 감소
VUser 20 환경에서도 안정적인 서비스 운영 가능

향후 개선 과제

1. 이미지 업로드 최적화

이미지 업로드 프로세스의 비동기 처리 구현
S3 업로드 작업을 메인 트랜잭션에서 분리
이미지 업로드 실패 시의 롤백 전략 수립

2. 확장성 개선

분산 환경에서의 락 처리 전략 검토 (Redis, ZooKeeper 등 활용)
마이크로서비스 아키텍처 고려 시 이슈 번호 생성 전략 재검토
대규모 트래픽 대비 이슈 생성 프로세스 스케일링 방안 수립

3. 모니터링 강화

커넥션 풀 사용량 실시간 모니터링 체계 구축

500만 건 데이터의 페이징 API 성능 최적화: TPS 4.3에서 219로 개선하기

EVO. — Sun, 22 Sep 2024 00:28:47 +0900

문제 사항 1. 책 조회 페이징 API (TPS 4.3)

책 조회에 대한 페이징 API를 구현한 뒤, Ngrinder를 통해 TPS를 확인해보니 4.3 으로 매우 낮은 상태였습니다. 책 ID(클러스터 인덱스)로 조회했을 때 최대 TPS는 약 230에 비해 현저히 낮은 상태였습니다. 이 문제점을 개선하기 위해 다음과 같은 과정을 진행했습니다.

테스트 환경

NCLOUD 애플리케이션 서버 (2CPU / 2GB)

NCLOUD ngrinder 에이전트 및 컨트롤러 서버 (2CPU / 2GB)

MySQL 마스터 / 슬레이브 이중화로 구성 (Book 테이블에는 500만건의 더미데이터 생성)

개선 전 상태

API를 호출하면 쿼리문이 2번 나갑니다. 처음은 OFFSET 방식으로 쿼리가 나가고, 그다음은 총 개수를 얻기위해 카운트 쿼리가 나갑니다.

첫번째 쿼리문의 EXPLAIN을 확인하면 테이블 풀 스캔에 filesort 방식으로 옵티마이저가 행동합니다.

MySQL EXPLAIN 결과에서 일반적으로 데이터가 많은 경우, Using Filesort와 Using Temporary 방식은 좋지 않습니다.

Filesort는 MySQL에서 내부적으로 테이블을 Sort Buffer에 옮겨 정렬하는 작업을 거칩니다. 정렬이 완료된 후, 결합이 필요한 데이터가 있다면 합치는 작업을 거친 후 데이터를 내려줍니다. (물론 단일 테이블인 경우엔 그대로 내려줍니다)

개선 과정 1. 인덱스 생성

옵티마이저의 filesort 방식이 아닌 인덱스 테이블을 사용할 수 있도록, created_at 칼럼에 인덱스를 생성했습니다.

CREATE INDEX idx_created_at ON book (created_at DESC);

이제 인덱스를 타고 duration이 0.0004925초로 개선이 되었지만, OFFSET에서는 큰 단점이 존재합니다. OFFSET에서 300만 + 로 넘어가면 즉 페이지수가 넘어갈수록 점점 쿼리속도가 느려지고 다시 duration을 확인하면 2.6909초로 대폭 느려지며, 옵티마이저가 다시 filesort로 행동했습니다.

이유는 OFFSET은 10개의 데이터만 조회한다고 해도 앞 300만 건의 데이터도 모두 읽습니다 즉 300만 + 10개의 데이터를 순차적으로 읽어들이고 300만건의 데이터는 버리고 10건만 보냅니다. 또한 이 300만건은 created_at의 인덱스 테이블에서만 읽는게 아니라 다른 칼럼도 읽기 위해 다시 테이블로 가서 데이터를 읽기 때문에 시간이 상당히 증가합니다.

개선 과정 2. 커버링 인덱스 사용

이때 다른 칼럼까지 복합으로 인덱스를 생성하면 그래도 시간이 줄어들지 않을까 예상하고, 모든 필요한 칼럼들. 즉, select절과 orderby절에서 사용하는 모든 칼럼들을 포함하는 복합 인덱스를 생성했습니다.

CREATE INDEX idx_book_cover ON book (created_at DESC, book_id, book_code, book_name, page_count, updated_at);

커버링 인덱스 방식으로 인덱스 풀 스캔을 뜻합니다. 이제 더이상 테이블 행에 접근하지 않으므로 효율적으로 되었습니다. duration을 확인해보면 0.000325초 이고, OFFSET이 300만 + 되어도 duration이 0.5792초로 이전에 비해 상당히 개선되었습니다.

하지만 커버링 인덱스는 너무 많은 인덱스가 필요하고(앞으로 조건 절이 추가되면 더 추가될 가능성이 있습니다), 인덱스 크기가 커지며, insert나 update가 일어나면 인덱스 테이블도 수정하기 때문에 새로운 성능문제가 발생할 요인이 있습니다.

개선 과정 3. NO-OFFSET 방식으로 개선 (TPS 4.3 -> 245, MTT 4,612.8 -> 81.3)

애초에 OFFSET을 사용하지 않으면 개선될 수 있습니다. 다만, 페이지 번호로 페이지네이션 구현이 불가능하고, 무한 스크롤 (더보기) 방식으로 페이지네이션을 구현해야 하기 때문에 함부로 결정할 수 없습니다. 만약 가능하다면 이 방식도 꽤 좋을 것 같아 어쨋든 진행했습니다.

NO-OFFSET 방식으로 개선하기 위해, 조건절 칼럼은 인덱스 적용이 필수 입니다. (이전에 생성했던 인덱스는 다 지웠습니다.)

CREATE INDEX idx_created_at ON book (created_at DESC);

OFFSET 대신 이제 where 절로 조회합니다.

SELECT * FROM BOOK WHERE created_at <= '2022-05-31 21:43:43.712214' ORDER BY created_at desc LIMIT 10;

인덱스 풀 스캔 방식이 아닌 인덱스 레인지 스캔과 커버링 인덱스 방식으로 동작됩니다. duration은 0.00044925초로 상당히 개선되었으며, 다만 페이지처럼 건너뛰는 방식을 할 수 없다는 단점이 존재합니다.

이를 스프링애플리케이션에서 구현하기 위해 동적으로 깔끔하게 쿼리를 짤 수 있는 QueryDSL를 사용했습니다.

클라이언트를 위해 다음 요청할 URL까지 만들어주면, API 응답값은 다음과 같이 작성됩니다.

다시 성능 테스트를 진행하고 확인한 결과, VUser 20일때 TPS 245. MTT 81.3 으로 개선되었습니다.

문제 사항 2. 책 검색 페이징 API (TPS 5.4)

위의 개선은 사실 무한 스크롤 방식 일때 뿐 개선이지, 보통은 페이지로 구현됩니다. 그래서 OFFSET 방식으로도 개선을 할 필요성이 있습니다. 아까 OFFSET 방식에서는 쿼리가 두번 발생했습니다. 이번에는 카운트 쿼리도 개선할 필요성이 있어보입니다.

다음은 카운트 쿼리 입니다.

책 검색 API에서는 다양한 조건이 들어갑니다. 이렇게 조건절에 여러개의 조건이 들어가면 성능이 급격히 안좋아지는 현상이 발생했습니다.

테이블 풀 스캔에 duration은 5.364 초 입니다. where 절의 book_name , page_count에 이미 인덱스를 생성한 상태에도 불구하고, 테이블 풀 스캔으로 진행되었습니다. 당연히도 조건이 한개일때는 적용되지만, 두개가 같이 들어가니 인덱스 테이블을 더이상 타지 않습니다.

EXPLAIN ANALYZE로 좀 더 확실히 해석했습니다.

Table scan on b1_0: 전체 테이블을 스캔합니다
Filter: ((b1_0.book_name like '%2%') and (b1_0.page_count < 300)): 테이블 스캔 후 두 조건으로 필터링합니다.
Aggregate: count(b1_0.book_id): 마지막으로 필터링된 행의 수를 집계합니다.

문제점은 인덱스를 사용하지 않고, 전체 테이블을 스캔하고 있다는 점과 필터링이 데이터를 읽은 후에 이루어집니다.

이 상태로 성능 테스트를 진행하면, 아까 OFFSET이 초반 페이지에서는 빠름에도 불구하고, TPS가 5.4 대로 나왔습니다.

개선과정 1. 커버링 인덱스 사용

1. 주로 책 이름과 페이지 카운트만 검색한다고 가정했습니다. (isbn인 book_code는 거의 검색안한다고 가정)

2. 복합인덱스를 생성할 때, 자주 검색되는 조건을 앞 순위에 넣었습니다. 책 이름이 가장 많이 검색한다고 생각되어 앞 순위로 지정했습니다. (추후에 여기서 큰 문제 발생)

3. 실제로 커버링 인덱스를 태우는 부분은 select를 제외한 나머지만 우선으로 수행

CREATE INDEX idx_book_covering_search ON book (book_name, page_count);

커버링 인덱스 및 인덱스 풀 스캔으로 duration 1.05s로 아까 5.364s에 비해 많이 개선되었습니다. (카운트 쿼리는 로우 개수를 읽지 select절이 필요없기 때문에 where절의 칼럼만으로 커버링 인덱스가 가능합니다)

QueryDSL에서는 다음과 같이 구현했습니다.

개선과정 2. like 절로 인해 인덱스 순서 변경 ( TPS 5.4 -> 18.9, MTT 1900 -> 528)

쿼리를 다시 보면 조건절에서 LIKE '%2%'로 검색이 진행되는데, 앞에 %가 붙으면 성능이 크게 저하됩니다. 만약에 '2%' 와 같이 검색한다면 0.0008초로 상당히 개선됩니다.

하지만, 앞에 %가 붙는 걸 유지하면서 조금 더 개선할 수 있는 사항이 존재합니다.

page_count를 먼저 검색하여 결과를 줄이고, 그 결과에 대해 LIKE 절을 적용하면 성능이 크게 개선될 것으로 예상되었습니다.

순서를 바꾸고 검색한 결과 카운트쿼리가 1.05s -> 0.6978s로 조금 개선되었고, 페이징 쿼리는 0.03s 로 나왔고, TPS를 다시 측정했습니다.

이전에 비해 조금 개선되었습니다 (TPS 5.4 -> 8.8 , MTT 1900 -> 1142)

여기서 한 가지 놓친 부분이 있었습니다. page_count를 먼저 검색하도록 했지만, index 생성 당시 book_name, page_count 순으로 생성했기 때문에 인덱스 테이블은 이 부분이 최적화되지 않았습니다.

CREATE INDEX idx_book_covering_search ON book (page_count, book_name);

인덱스 순서를 변경한 후, 다시 실행 시간을 측정한 결과 0.36초로, 이전의 0.69초에 비해 크게 개선되었습니다.

또한 TPS를 다시 측정한 결과, 전보다 더 개선되었습니다 (TPS 8.8 -> 18.9 , MTT 1142 -> 528)

개선과정 3. 캐시 적용 X , 페이지 건수 고정하기 (TPS 18.9 -> 219, MTT 528 -> 45.2)

앞서 18.9 TPS로 개선되긴 했지만, 최대 240이상 줄 수있는것에 비해 현저히 낮았습니다. 그렇다고, 쿼리 duration이 낮은거 아니냐고 하면 OFFSET페이징 API에서 초반 페이지에서는 약 30ms , 카운트 쿼리에서도 약 30ms로 굉장히 낮은 편인데도 불구하고 TPS가 낮았습니다.

캐시를 적용하는 방식으로도 개선할 방법이 있지만, 검색 API에서는 검색 조건에 따라 시시각각 바뀌기 때문에 불가능합니다. 또한, 카운트 테이블을 생성하는 방식도 같은 이유로 불가능합니다.

애초에 카운트 쿼리가 문제일 것이라고 생각이 들었기 때문에 한 가지 가정을 했습니다. 대부분의 요청이 검색 버튼을 클릭하고, 페이지 버튼을 통한 조회 요청이 거의 없을 경우

이럴 경우 검색 버튼을 클릭한 경우에만 Page 수를 고정하고 (카운트 쿼리는 발생하지 않게 하고), 다음 페이지로 이동하기 위해 페이지 버튼을 클릭했을 때만 실제 페이지 count 쿼리를 발생시켜 정확한 페이지 수를 사용하게 하면 됩니다.

이는 코드를 다음과 같이 구현하면 됩니다.

1. 검색버튼 클릭 여부(useBtn) 가 true 일 때, 10개의 페이지 수가 노출되도록 fixedPageCount 반환

2. 페이지 버튼 클릭했을 때 (useBtn = false), 실제 카운트 쿼리 발생 시켜 결과를 반환 (기존처럼 진행)

3. 페이지 버튼을 클릭했을 때, 전체 페이지수를 초과한 번호로 요청이 온 경우에는 마지막 페이지 결과를 반환

FixedPageRequest

검색 버튼을 클릭했을 때 , 쿼리는 이제 한 번만 나가고, 검색 버튼만을 눌렀을 때의 TPS 결과,

카운트 쿼리가 없어지니 역시나 TPS 18.9 -> 219, MTT 528 -> 45.2 로 개선되었습니다. 검색버튼 누르는 일이 많을 때 상당한 성능 개선을 볼 수 있습니다.

하지만 UX상에서 동적으로 페이지 번호가 바뀌는 상황이 불가능하거나 검색버튼 보다 페이지 번호를 누르는 일이 많으면 이 방식 역시 좋은 방식은 아닙니다. 그때는 첫페이지만 카운트쿼리를 하고, 그 후엔 프론트 영역에서 카운트를 캐싱하고 보내주는 방식으로 해결할 수 있을 것 같습니다.

Reference

https://jojoldu.tistory.com/530

클라우드 환경에 내 로컬 DB 연결하기

EVO. — Mon, 26 Aug 2024 13:44:42 +0900

문제 사항

애플리케이션 서버를 배포한 후, 성능 테스트를 수행하려면 반드시 데이터베이스(DB)가 필요합니다.

하지만 다음과 같은 어려움이 있습니다:

RDS를 이용한 성능 테스트: 쿼리 당 비용이 발생하여 예산이 제한적인 상황에서는 적합하지 않습니다.
개발 서버용 EC2에 MySQL 설치: EC2 프리 티어의 1CPU 1GiB 사양으로는 MySQL을 원활하게 운영하기 어렵습니다.
로컬 환경에서의 성능 테스트: 로컬 PC에서 Tomcat과 MySQL을 실행하여 테스트할 수 있지만, localhost 내에서 수행되므로 실제 네트워크 환경을 반영하지 못해 의미 있는 성능 테스트가 어렵습니다.

해결방안

로컬에 MySQL 도커 컨테이너를 설치하고 외부 접속이 가능하도록 설정하고 DDNS 도메인을 만들면, EC2에서 안정적으로 성능 테스트를 수행할 수 있습니다.

외부에서 로컬 DB를 접근하려면 몇가지 단계가 필요합니다.

이를 위해 다음 단계를 따르세요:

1. 도커 컨테이너의 포트 매핑 설정

컨테이너가 전역에서 접근 가능하도록 포트를 매핑합니다.
Master DB: 0.0.0.0:3306:3306
Slave DB: 0.0.0.0:3307:3306
도커를 사용하지 않는 경우, MySQL의 my.cnf 파일에서 bind-address를 '0.0.0.0'으로 설정하세요.

2. MySQL 사용자 권한 설정 모든 호스트에서 접근 가능한 사용자를 생성하고 권한을 부여합니다.

```java

CREATE USER 'username'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'username'@'%';
FLUSH PRIVILEGES;

```

이 명령어를 실행하면 생성된 사용자가 모든 호스트에서 MySQL에 접속하여 작업을 수행할 수 있습니다.

3. DDNS 설정

가정에서 사용하는 인터넷 연결은 대부분 동적 IP 주소를 사용합니다. 이는 IP 주소가 주기적으로 변경됨을 의미하며, 이로 인해 스프링 서버에서 고정 IP를 사용할 수 없습니다. 이 문제를 해결하기 위해 DDNS를 설정해야 합니다.

DDNS는 변경되는 IP 주소를 고정된 도메인 이름에 연결해주는 서비스입니다. 설정 방법은 공유기 제조사와 모델에 따라 약간의 차이가 있지만, 기본적인 절차는 유사합니다.

KT 공유기를 예로 들어 설정 방법을 설명드리겠습니다:

공유기 관리 페이지에 접속합니다. (일반적으로 192.168.0.1 또는 192.168.1.1 주소 사용)
관리자 로그인을 합니다.
DDNS 설정 메뉴를 찾아 접속합니다. (보통 '고급 설정' 또는 '네트워크 설정' 아래에 있습니다)

과거에는 DynDNS와 같은 서비스가 무료로 제공되었지만, 현재는 유료로 전환되었습니다.

따라서 무료 DDNS 서비스인 No-IP(no-ip.com)를 이용하는 방법을 안내해 드리겠습니다:

no-ip.com 회원가입:
- 사이트에 접속하여 회원가입을 진행합니다.
- 아이디는 이메일 주소를 사용합니다.
- 비밀번호는 특수문자 없이 영문자와 숫자만 사용하여 설정합니다. (상세한 가입 절차는 인터넷에서 쉽게 찾아볼 수 있으므로 생략합니다.)
호스트네임 설정:
- 로그인 후 'Dynamic DNS' > 'NO-IP Hostnames' 메뉴로 이동합니다.
- 원하는 도메인명을 입력합니다.
- IP 주소 란에는 현재 사용 중인 공유기의 기본 게이트웨이 주소를 입력합니다.

위와 같이 생성된 것을 확인했으면 다시 공유기 사이트로 접속한다음 다음처럼 입력합니다.

적용 시킨다음 만든 도메인에 접속해서 똑같이 공유기사이트에 접속하면 성공입니다.

4. 포트포워딩 설정

공유기를 거치기때문에 외부망에서 내부망으로 들어오려면 포트포워딩을 설정해야합니다.

다음과같이 소스IP주소와 소스포트는 적을 필요가 없고, 내부 IP주소는 맥북에서는 `ifconfig | grep "inet " | grep -v 127.0.0.1` 으로 확인해서 적습니다. 그리고 외부,내부 포트까지 적습니다.

5. no-ip client 설치

이제 ip가 변경되더라도 자동으로 DDNS 도메인에 매핑되도록 해야합니다.

영상보면 잘 설명되있으니 따라하면 됩니다. (Dynamic Update Client 접속)

https://my.noip.com/dynamic-dns/duc

6. 확인해보기

(참고로 윈도우는 방화벽 설정도 추가적으로 필요합니다)

이제 모든 설정이 끝났습니다. EC2에서 로컬 PC 3306,3307포트에 잘 접속이 되는지 확인이 필요합니다.

이렇게 telnet 명령어나 nc -zv로 확인해서 위처럼 결과가 나온다면 성공입니다.

Model has no value for 에러 발생

EVO. — Mon, 8 Jul 2024 01:31:59 +0900

문제 사항

컨트롤러에서 다음과 같이 redirectAttributes 로 리다이렉트를 한다.

직접 Postman으로 실행하면 정상적으로 리다이렉트 되지만

MockMVC로 테스트를 하면 {key} 부분을 동적으로 변환을 하지 못해 실패를 한다.

에러 내용

고민한 방법

디버깅

먼저 key가 null로 들어가는 것이 확인 된다.

RequestMappingHandlerAdapter 클래스에서 view 와 rediretModel 이 mavContainer에 담겨있는 것을 확인

DispatcherServlet 클래스까지 잘 전달되는게 확인 (물론 key는 null이라 이 부분을 확인해야한다)

그런데 DisPatcherServlet 클래스내에서 processDispatchResult 메서드가 실행된 후 예외 발생

Mock 테스트 내에서 문제가 발생한 것은 맞지만 예상대로 동적으로 값을 못넣는다거나 그런건 아닌 것 같고 아까 key에 null이 들어간 것 부터 확인이 필요한 것 같다.

문제의 원인은 여기서 발생했다.

mockito의 when 메서드 인자에 projectService.createProject(request)가 들어오면 project 를 반환해라는 의미이다.

먼저 OngoingStubbing 클래스를 통해 InnovocationContainerImpl에 request 클래스의 주소를 등록하고 return값도 등록해놓는다.(answer변수에 "project" 등록)

이제 api를 수행하다 createProject메서드를 만나면 MockHandlerImpl의 handler() 메서드 에서 값을 비교하기 시작한다.

먼저 같은 메서드인지 확인하고 인자를 매칭하는 것으로 보인다. argumentMatch(candidate)

좀만 더 깊게 들어가보면 이제 ArgumentMatcher(여기에는 InnovocationContainerImpl에 request 클래스의 주소을 등록한 matcher)와 인자값으로 들어온 argument(즉 request)를 비교하기 시작한다. 아래는 먼저 같은 클래스인지 부터 비교한다. 당연히 이건 true을 반환한다(둘 다 ProjectCreateRequest 이므로)

이제 오른쪽 matches 메서드를 실행하면 Equality의 areEqual메서드로 판단을 하는데,

빨간박스친 부분이 실행된다.

즉, 인자에 들어가는 객체는 Mockito에서 when().thenReturn을 사용할때 메서드의 파라미터로 넘어오는 클래스까지 equals를 사용하여 비교한다.

Request 객체 일치 문제: Mockito에서는 when(...) 구문에 전달된 인수와 실제 메서드 호출 시 사용된 인수가 정확히 일치해야 한다.

만약 인수가 객체인 경우, 객체의 동등성,동일성(equals)이 판단된다. projectService.createProject(request) 호출(perform실행)에 사용된 request 객체가 when(...) 구문에 사용된 객체와 정확히 일치하지 않는다면, Mockito는 설정된 반환 값을 무시하고 기본값인 null을 반환한다.

해결방법

다음과 테스트코드를 작성해도 되지만

when(projectService.createProject(any(ProjectCreateReq.class))).thenReturn("project");

dto에 equals 를 오버라이딩을 하여 객체간 값만 일치해도 동일성을 확보하는 습관을 갖는게 좋을 것 같다.

번외

추가적으로 왜 when절에 넣은 request와 perform에 수행되는 request와 같은 request인데 결국엔 주소값이 다른 객체로 변하는지 의문이 들 것이다.

나도 그 부분이 의아해서 다시 시간내서 찾아봤다.

아래는 perform 메서드 도중 수행되는 로직 중 HandlerMethodArgumentResolver 부분이다.

HandlerMethodArgumentResolver는 요청 데이터를 메서드의 매개변수로 변환할 때 사용하는 전략 인터페이스 이다.

다시 말해서 어떠한 요청이 컨트롤러에 들어왔을 때 요청 데이터로 부터 원하는 객체를 반환하는 역할을 수행한다.

다시 아래 코드를 보자

objectMapper을 통해 request를 직렬화하여 바이트로 변환한다음 해당 url을 요청한다.

그리고 나서 아까 resolveArgument 부분에서 HandlerMethodArgumentResolver의 resolveArgument 메서드를 요청한다.

jakson의 objectMapper로 직렬화한 객체의 HandlerMethodArgumentResolver 구현체는 RequestResponseBodyMethodProcessor 이므로 해당 부분에 브레이크포인트를 걸면

바이트스트림이 객체로 변환되었음을 알 수가 있다.

결론적으로 같은 객체가 아님을 확인했다. 따라서 반드시 equals를 오버라이딩해서 값만 같아도 동일성을 확보하던지 mokito의 any절을 활용해야 해당 문제를 해결할 수가 있다!

이슈 전체 조회 성능 개선하기

EVO. — Sat, 6 Jul 2024 21:51:10 +0900

준비 사항

프로젝트 1만개 생성
멤버 1만개 생성
프로젝트와 멤버 1대1 매칭
- 예를들어 1번 프로젝트는 1번 멤버, 2번 프로젝트는 2번 멤버, n번 프로젝트는 n번 멤버가 속합니다.
- 성능 비교를 위한 것은 프로젝트와 멤버가 아닌 이슈이기 때문에 최대한 간단하게 매칭 시켰습니다.
EPIC 이슈는 100개 생성
STORY 이슈는 에픽당 200개씩 총 2만개의 스토리 이슈 생성
TASK 이슈는 스토리당 200개씩 총 4만개의 테스크 이슈 생성
모든 이슈는 1번 프로젝트에 속하도록 합니다.

문제 사항

1. 로직 리팩토링

더미데이터를 넣고 이슈 전체 조회 API를 요청 했지만 쿼리가 돌다가 응답이 오지 않고 멈췄습니다.(성능측정을 해야지하고 몇 초나 걸릴까를 생각했는데 그냥 아예 팅겨버린..)

이유가 당연했습니다. 로직이 다음과 같이 구현되어있습니다.

/api/projects/{key}/issues 해당 API를 요청하면

generateCompleteEpicRootStructure(project, responses);
generateCompleteStoryRootStructure(project, responses);
generateCompleteTaskRootStructure(project, responses);

3번의 로직이 돕니다.

첫번째 로직은 프로젝트에 속한 에픽이 루트로 시작되어 조회.
두번째 로직은 부모 이슈가 없는 스토리가 루트로 시작되어 조회
세번째 로직은 부모 이슈가 없는 테스크가 루트로 시작되어 조회

이 세개의 로직은 비슷하며, 첫번째 로직만 보겠습니다.

findEpicsByProject(project) 는 프로젝트에 속한 에픽들을 모두 가져온다라는 로직입니다.

쿼리는 다음과 같이 JPQL로 작성되어있습니다.

@Query("SELECT e FROM Epic e WHERE e.project = :project")

두번째 쿼리를 보면 가져온 에픽들을 토대로 에픽아이디들만 묶어서 해당 에픽들을 부모이슈로 가지고 있는 스토리들을 모두 가져옵니다.

이때 in 절 한방쿼리로 성능을 개선했습니다.

@Query("SELECT s FROM Story s WHERE s.epic.id IN :epicIds")

세번째 쿼리를 보면 @Query("SELECT t FROM Task t WHERE t.story.id IN :storyIds")

가져온 스토리들을 토대로 테스크를 모두 가져오도록 합니다. 총 2만개의 스토리아이디가 in절에 들어가고 해당 스토리 아이디를 가지고 있는 테스크는 2만*200이므로 400만개의 테스크를 가져오게 됩니다.

당연히 400만개의 데이터를 준비하는 동안 타임아웃이 나고 네트워크는 끊기게 됩니다.

그런데 디비는 타임아웃과 같은 어떠한 예외도 터지지 않았습니다.

mysql에서 타임아웃을 확인하는 명령어는 다음과 같습니다.

show variables like 'interactive%';

28800초로 총 8시간입니다. 이렇게 긴 시간으로 기본값이 설정된 이유는 잘 모르겠지만 커넥션 타임아웃 관련해서도 조심해야 할 사항이 많은 것 같습니다.

https://netmarble.engineering/jdbc-timeout-for-game-server/

https://d2.naver.com/helloworld/1321

정확히 테스크에서 가져오는 곳에서 문제가 있는 지 확인해보기 위해 테스트코드를 작성해보겠습니다.

@SpringBootTest
@Profile("local")
class TaskRepositoryTest {

    @Autowired
    private TaskRepository taskRepository;

    @Test
    void 로컬에서_저장한_이슈들_정상적으로_가져오는지_조회() {
        // given
        List<Long> storyIds = new ArrayList<>();
        for (long i = 101L; i < 20100L; i++) {
            storyIds.add(i);
        }
        // when
        List<Task> tasks = taskRepository.findTasksByStoryIds(storyIds);
        // then
        assertThat(tasks.size()).isEqualTo(4_000_000L);
    }
}

이 상태로 실행해보면 당연하게도 OOM이 발생하고 실패합니다. 즉, 400만개의 데이터를 넣는 것은 불가능합니다.

따라서 아래처럼 한번에 가져오는 방식이었던 기존 UI에서 접이식 방식으로 바꾸고 API를 분리하는 방식으로 가도록 했습니다.

기존 API

- 프로젝트에 할당된 모든 이슈들을 관계가 맺어진채 가져오는 API

변화된 API

프로젝트에 할당된 에픽만 가져오는 API
에픽 아이디를 부모이슈로 요청해서 스토리들만 가져오는 API
스토리 아이디를 부모이슈로 요청해서 테스크들만 가져오는 API

예상 UI

세가지 API를 분리함으로써 좀 더 확장성이 커진 이점이 있었습니다. 예를들면 에픽을 조회할때 상단 이미지처럼 에픽에 속하는 스토리들의 상태에 대한 통계가 필요했는데 그 역시 쉽게 추가할 수 있었습니다.

가장 핵심인(사용자가 처음 진입할때 먼저보이게되는 API) 에픽만 가져오는 API를 보겠습니다.

전체 에픽 로드: 프로젝트의 시작 단계에서 전체 에픽을 불러오는 과정입니다.
DTO 변환 과정: AssigneeDto의 경우 이전에는 성능 문제로 인해 특정 데이터를 제공하지 못했지만, 최적화를 통해 이제는 필요한 모든 정보를 효율적으로 제공할 수 있습니다.
스토리 통계 로직: 각 에픽에 속하는 스토리들에 대한 통계를 취합하는 과정입니다. 이 단계에서는 QueryDsl과 Projection을 사용하여 데이터베이스에서 직접 필요한 데이터를 추출하고, 이를 DTO에 매핑합니다.

2. EXPLAIN ANALYZE로 쿼리가 잘못된 것을 파악후 쿼리 변경

이제 조회방식이 달라졌기 때문에 기존 에픽에 100만 개의 데이터를 더추가하고 스토리에는 200만개의 데이터를 추가한다음 에픽 10번에 해당 200만개의 데이터를 상위이슈로 정한채 성능을 진단했습니다.

에픽에 있는 스토리들의 통계를 가져오는 쿼리 입니다.

select
            s1_0.epic_id,
            count(s1_0.issue_id),
            sum(case 
                when (i1_0.status="DO") 
                    then 1 
                else 0 
            end),
            sum(case 
                when (i1_0.status="PROGRESS") 
                    then 1 
                else 0 
            end),
            sum(case 
                when (i1_0.status="DONE") 
                    then 1 
                else 0 
            end) 
        from
            story s1_0 
        left join
            issue i1_0 
                on s1_0.issue_id=i1_0.issue_id 
        left join
            epic e1_0 
                on e1_0.issue_id=s1_0.epic_id 
        where
            i1_0.project_id=1 
        group by
            s1_0.epic_id 
        order by
            s1_0.epic_id;

아래 EXPLAIN ANALYZE 로 확인하면

story의 epic_id 인덱스를 통해 커버링 인덱싱
epic 테이블의 PRIMARY 키(issue_id)를 통해 (issue_id = story의 epic_id)인 레코드를 찾는다.
그리고나서 1번의 결과와 2번의 결과를 조인한다.

여기서 3번 수행이 매우 이상합니다. P1에 속하는 에픽들을 조회하는 건데 에픽은 모두 포함해야 하지만 해당 부분을 보니 story테이블이 드라이빙 테이블이 되면 결과가 이상해질거라고 예상이 갔습니다.

따라서 P1에 속하는 EPIC을 여러개 생성하고 한 EPIC에만 STORY를 매핑시키고 다른 EPIC에는 어떠한 스토리도 넣지 않고 테스트를 해봤습니다. 역시 기대와 달리 이상하게 나왔습니다. 쿼리 부터 잘못된 것입니다.

3. SubQuery로 변경 후 성능 개선

재작성된 쿼리

SELECT
    e.issue_id AS epic_id,
    COUNT(s.issue_id) AS stories_count,
    SUM(CASE WHEN i.status = 'DO' THEN 1 ELSE 0 END) AS status_do,
    SUM(CASE WHEN i.status = 'PROGRESS' THEN 1 ELSE 0 END) AS status_progress,
    SUM(CASE WHEN i.status = 'DONE' THEN 1 ELSE 0 END) AS status_done
FROM
    epic e
    LEFT JOIN story s ON e.issue_id = s.epic_id
    LEFT JOIN issue i ON s.issue_id = i.issue_id
GROUP BY
    e.issue_id;

재작성된 쿼리를 보면 에픽과 스토리와 이슈를 LEFT JOIN 을 하여 통계를 내고 있습니다. 여기서 스토리와 이슈는 특정 칼럼만 필요한데 과연 모든 칼럼과 모든 데이터들을 조회할 필요가 있을까해서 서브 쿼리로 다시 변경했습니다.

서브 쿼리로 변경

SELECT
    e.issue_id AS epic_id,
    COUNT(DISTINCT s.issue_id) AS stories_count,
    SUM(CASE WHEN i.status = 'DO' THEN 1 ELSE 0 END) AS status_do,
    SUM(CASE WHEN i.status = 'PROGRESS' THEN 1 ELSE 0 END) AS status_progress,
    SUM(CASE WHEN i.status = 'DONE' THEN 1 ELSE 0 END) AS status_done
FROM
    epic e
    LEFT JOIN (SELECT issue_id, epic_id FROM story WHERE epic_id IS NOT NULL) s ON e.issue_id = s.epic_id
    LEFT JOIN (SELECT issue_id, status from issue WHERE project_id = 1) i ON i.issue_id = s.issue_id

GROUP BY
    e.issue_id;

LEFT JOIN 절에 서브쿼리를 이용하여 필요한 칼럼들만 추출하였더니 group by절을 통해 불러오는 데이터 양이 감소하여 기존 3.59s에서 1.25s 로 성능이 개선되었습니다.

4. native query와 projection으로 querydsl에서 지원하지 않는 from SubQuery 해결

Querydsl에서는 from 절에 SubQuery 를 지원하지 않습니다. → 네이티브 쿼리로 해결하던지 JOIN으로 합니다.

hibernate 6.1 부터는 from절에 서브쿼리 지원 (하지만 Querydsl은 여전히 지원안함 ->

추후에 알게된 사실: blaz-persistence 가 querydsl 익스텐션으로 from 절 서브쿼리 지원

https://javadoc.io/doc/com.blazebit/blaze-persistence-integration-querydsl-expressions/latest/com/blazebit/persistence/querydsl/package-summary.html)

현재 프로젝트는 hibernate 6.4.4 이므로 사용가능 합니다. 하지만 criteria은 자주 사용되지 않습니다. HQL로 객체지향적으로 쿼리를 작성할 수 있긴하지만 네이티브로 이번엔 작성해봤습니다.

따라서 아래 글을 참고하여 native query와 projection으로 위 성능을 챙길 수가 있게 되었습니다.

https://medium.com/swlh/spring-data-jpa-projection-support-for-native-queries-a13cd88ec166

Spring Data JPA Projection support for native queries

A basic guide for using Spring Data JPA projections for native queries and nested projection objects.

medium.com

배포 하는데 걸리던 시간 13분을 5분으로 줄이기

EVO. — Tue, 14 May 2024 16:27:12 +0900

문제사항

최근 애자일허브 프로젝트는 도커이미지를 만들어 DockerHub에 올리는 방식으로 배포를 하고 있습니다. Dockerfile을 만들어서 GitHub에 올려두고, GitHub Actions로 docker build와 push를 진행하는 방식입니다.

그런데 배포를 할때마다, 매번 빌드 시간이 10분 이상이었고, 코드가 조금만 추가되어도 1분씩 늘어나 최근에는 배포 한번 하는데 13분정도 걸립니다. 이정도의 시간은 매번 배포할때마다 다른 일을 해야하고, 나중에 테스트를 해보며 수정할게 생기면 다시 또 13분을 기다려야 하는 충분히 부담되는 시간입니다. 그리고 이런 사이클은 Continuous Deployment의 장점을 잘 살리지 못한다고 생각했습니다.

배경지식 - 도커 레이어와 캐시

도커 빌드 속도에 영향을 미치는 레이어(Layer)와 캐시(Cache)에 대해 알아보겠습니다.

도커 이미지는 빌드 시 Dockerfile의 명령어들을 차례로 실행하면서 레이어를 생성합니다. 이때 명령어(RUN, ADD, COPY)로 생성된 레이어는 이미지 크기를 커지게 하고, 이미지를 생성하는 시간도 길어지게 합니다. 이미지 크기를 줄이는 방법은 다양하게 있는데 뒤에서 알아보겠습니다.

https://docs.docker.com/build/cache/

크기를 줄이는 방법 외에도 도커 캐시가 있습니다. Dockerfile을 작성하고, docker build를 실행하게 되면 빌드 속도를 높이기 위해 캐시를 사용합니다. 첫 번째 빌드에서는 각 단계 별 캐시를 설정하고, 이후 동일한 명령어가 실행되면 만들어둔 레이어를 재사용합니다. 만약 레이어가 변경되면 해당 레이어포함 그 뒤 레이어들을 다시 빌드합니다.

https://docs.docker.com/build/cache/

멀티스테이지 빌드

멀티스테이지 빌드란, 최종 이미지에서 필요 없는 환경을 제거할 수 있도록 여러 단계에 걸쳐 이미지를 만드는 방법입니다.

아래의 Dockerfile 예시에서 볼 수 있듯이, 첫 번째 단계에서는 Gradle 8.3 버전과 함께 JDK가 포함된 상태로 애플리케이션이 빌드되어 이미지 크기가 매우 큽니다. 하지만 빌드가 완료된 후에는 JDK가 더 이상 필요하지 않으므로, FROM 명령어를 사용해 eclipse-temurin을 기반으로 한 JRE만 포함된 훨씬 가벼운 레이어로 전환합니다.

위와 같이 멀티스테이지 빌드로 바꾸면 기존 700MB 였던 이미지의 크기가 약 320 MB로 줄어듭니다.

또한 앞에서 도커는 캐시 전략에 의해 레이어에 변함이 없다면 빌드 속도는 빨라야합니다. 로컬에서 이미지 빌드를 반복한다면 시간이 줄어듬을 확인할 수 있습니다.

GitHub Actions를 이용한 빌드

애자일허브는 코드를 GitHub에 올리고, GitHub Actions로 도커 빌드 및 배포를 실행해주고 있습니다.

위 workflow를 사용해보겠습니다. main 브랜치로 push 할 때마다 docker build를 실행합니다.

동일한 코드는 아니여서 정확히 판단은 되지 않습니다. 도커 캐시를 잘 사용중인지 GitHub Actions 로그를 살펴보겠습니다.

의존성이 바뀌지 않았음에 불구하고 도커의 캐시가 적용되지 않았습니다.

빌드 시간을 보면 의존성만 빌드하는 RUN gradle dependencies --no-daemon의 시간은 2m 39s, RUN gradle clean build --no-daemon의 빌드 시간은 8m 13s로 매우 많은 시간이 걸렸습니다.

캐시가 동작하지 않는 겁니다.

GitHub Actions에서 도커 캐싱

GitHub Actions의 러너는 매번 새로운 가상환경에서 실행됩니다. 작업은 매번 새롭게 다시 시작되는거죠. GitHub에서는 캐싱을 제공하지만, Docker 레이어에 대한 내용은 없습니다.

도커에서 공식적으로 제공하는 buildx라는 CLI 플러그인을 사용하면 GitHub Cache API를 활용할 수 있습니다.

우선 buildx 설정을 해주고, docker/build-push-action@v5를 이용해 build와 push를 해주고 있습니다.

그리고 cache-from 과 cache-to에 type=gha라고 입력해줍니다. 이 부분에서 캐싱이 적용됩니다.

이렇게 설정하고 코드를 변경하지 않은 채 배포를 다시 해보고 비교해보겠습니다. 배포를 하면

아직 저장된 캐싱이 없으므로 앞과 거의 비슷하게 12m 13s 정도 걸렸습니다.

다시 배포를 하면

빌드 시간이 8m 41s로 약 4분정도 단축했습니다!

로그를 다시 한번만 확인해보면

CACHED가 적용된 것을 확인할 수 있습니다.

그러나 로그를 계속 살펴보니 RUN gradle clean build --no-daemon 은 여전히 캐싱이 적용되지 않고 7m 이상의 시간이 소요됐습니다. 이 부분도 캐싱이 적용되면 빌드시간이 훨씬 단축될것 같습니다.

그래서 gradle 빌드하기 전 clean하지 않고 빌드를 하면 캐싱이 적용되지 않을까 했지만 여전히 적용되지 않았습니다.

(참고로 도커 내 Gradle의 캐싱은 불가능 합니다. Gradle 빌드되면 .gradle 폴더에 Gradle Cache가 남아있지만 Docker가 그 경로를 마운트 하지 않는 이상 찾을 수 없습니다. 그리고 복잡하다고 하네요

(https://discuss.gradle.org/t/why-gradle-does-not-use-cache-in-docker/33902))

또한 시간이 오래걸리는 이유를 로그로 보니

테스트를 하는데에만 3분 넘게 보내고 있었습니다. SpringBootTest 어노테이션을 사용함에 따라 모든 빈을 띄우는 통합테스트이기 때문에 매우 느립니다.

Gradle 빌드 옵션 변경

저희 애자일허브는 main브랜치에 push하기 전, PR을 통해 CI 통합테스트를 먼저 진행하고, 리뷰와 모든 테스트가 통과할 시에 main 브랜치에 push할 수 있습니다.

따라서 빌드 속도를 높이기 위해 CD 워크플로에서는 테스트를 진행하지 않도록 하고, gradle의 병렬 빌드 옵션을 사용하도록 했습니다. (병렬 빌드는 서브모듈이 있을 때 유용한거라 이부분에 대한 시간은 영향이 없을 것 같습니다)

테스트를 제외하고 배포를 한 결과

최종적으로, 배포하는데 걸렸던 13분이 5분으로 8분 가량 줄어들었습니다!

의존성 라이브러리를 빌드하는 과정에서 CACHED 됨을 확인할 수 있었습니다.

gradle build를 로컬에서 수행하고 jar 파일만 활용해서 하는 방법이 있는데 도커 이미지를 만들 때 build를 하는 이유가 있나요?

애자일허브는 현재 jar을 위한 빌드 시스템이 별도의 프로세스로 처리되는 구조이기 때문입니다. 코드를 작성하고 PR 이후 CI를 통해서 테스트가 문제 없음을 확인하고 PR이 main 브랜치에 Merge 되면, main 브랜치 기준으로 docker image를 만드는 구조이기 때문입니다.

참고 자료

https://docs.gradle.org/8.1/release-notes.html

https://findstar.pe.kr/2022/05/13/gradle-docker-cache/

https://fe-developers.kakaoent.com/2022/220414-docker-cache/