DB Function to Java Application 이관 (feat. 프로시저)

이번 포스팅에서는 전 직장에서 진행했던 DB Function 로직을 Java Application으로 이관하는 작업에 대해 정리하고자 합니다. 시간이 다소 흘렀지만, 이 작업 과정을 되돌아보고자 하는 목적도 있고, 유사한 작업을 진행할 때 참고할 수 있도록 트러블슈팅 및 고려 사항 등을 정리해 보려 합니다.

 

포스팅은 개요 - 과정 - 결과(성과) - 회고 순으로 구성하였습니다.

 

개요

기존의 DB Function은 쿠폰 발급 API를 처리하는 함수로, 외부 제휴사가 발급 요청을 하면 내부적으로 여러 프로시저들을 순차적으로 호출하여 검증, 로깅, INSERT, UPDATE 등 쿠폰 발급을 처리하는 로직이었습니다. 하지만 이 로직에는 여러 문제가 있었고, 이를 개선하기 위해 이번 작업을 진행하게 되었습니다.

 

DB Function이 가지고 있던 주요 문제점은 다음과 같습니다.

1. 디버깅의 어려움: DB 함수로 작성된 로직이라 디버깅이 거의 불가능한 상황이었습니다.
2. 슬로우 쿼리 발생: 간헐적으로 슬로우 쿼리가 발생하고 있으나 정확히 어느 지점에서 병목이 발생하는지 파악하기가 어려웠습니다.
3. 유지 보수의 어려움: 불필요한 쿼리문이나 무의미한 로그 테이블 저장, 불필요한 추가 조회 쿼리, 프로시저 내에 구현된 재시도(retry) 로직 등 비효율적인 부분이 다소 존재했습니다.
4. 오랜 기간 방치된 코드: 오랫동안 코드가 개선되지 않았기에 히스토리 관리가 되지 않고, 주석과 실제 로직이 불일치하는 등의 문제점이 존재했습니다.

이와 같은 문제들로 인해 DB Function 로직을 Java Application으로 개선하는 작업을 진행하게 되었습니다.

 

 

과정

개선 작업의 과정은 다음과 같습니다.

• 기존 로직 분석
• 이관 일정 수립
• 점진적 이관 (프로시저 단위)
• 개선
• 테스트
• 배포, 롤백, 모니터링
• 트러블 슈팅

 

또한 Java로 이관 작업을 진행하면서 고려해야 했던 사항들은 다음과 같습니다:

• 기존의 로직과 신규 로직의 결과가 동일한지 어떻게 검증할 것인가? (테스트)
• 운영 환경에는 어떻게 배포를 할 것인가? (배포 전략)
• 배포 후 장애가 발생했을 때 후처리 방식은 어떻게 해야 하는가? (데이터 정합성, 롤백 전략 등)

 

위 목록들을 바탕으로 구체적으로 정리해보겠습니다.

 

 

기존 로직 분석

 

기존 DB Function으로 작성된 로직은 다음과 같습니다.

(프로시저명, 필드명 등 주요 내용들은 블라인드 처리하였습니다 ^^;)

 

대략적으로 요청 정보 저장, 유효성 검증, 번호 조회 및 발급 처리, 시퀀스 조회, 쿠폰 발행 처리 등의 과정을 순차적으로 처리합니다.

 

이미지를 통해 큰 흐름은 파악할 수 있었으나, 앞서 말씀드린 것처럼 히스토리 관리가 제대로 이루어지지 않았습니다. 이로 인해, 프로시저 쿼리 처리 과정에서 이해되지 않는 부분에 대해서는 테스트 케이스를 추가하여 이해도를 높여갔습니다.

(실제 테스트 과정에서, 프로시저 로직이 별도의 트랜잭션에서 처리되어 스프링 테스트에서 사용하던 @Transactional이 롤백 되지 않는 이슈가 발생하기도 했습니다.)

 

이러한 과정에서 기존 프로시저 로직을 분석해 보니 주석과 실제 로직이 다른 경우도 많았고, 앞서 언급한 것처럼 사용되지 않는 코드나 비효율적인 로직들이 다수 존재했습니다. 이로 인해 개선 작업을 더욱 빠르게 진행할 필요성을 느끼게 된 것 같습니다.

 

 

이관 일정 수립

이관 일정은 각 프로시저의 규모에 따라 조금씩 다르게 잡았고, 다른 업무나 발생할 수 있는 사이드 이펙트도 여유 있는 일정을 설정하고 작업을 진행했습니다.

 

 

점진적 이관 (프로시저 단위)

이관은 위 일정처럼 프로시저 단위로 하나씩 이관하였습니다.

 

As-Is) 기존에는 애플리케이션이 DB Function을 호출하고, 그 안에서 여러 프로시저들을 내부적으로 호출하는 구조였습니다.

To-Be) 이를 애플리케이션이 각각의 프로시저들을 순차적으로 직접 호출하도록 수정했는데, 이 과정에서 예상치 않게 슬로우 쿼리의 원인을 바로 파악할 수 있었습니다.

 

경과 시간, 트랜잭션(URI), HTTP 호출 수, SQL 건수, SQL 시간

기존 로직에는 DB Function 호출만 모니터링에 잡히기에 SQL 쿼리 건수가 1회로만 기록되었기에 전체 쿼리 결과만 확인할 수 있었지만, 로직 변경 후에는 각 프로시저의 쿼리가 개별적으로 모니터링되었기 때문에, 어느 프로시저에서 병목이 발생하는지 정확히 파악할 수 있었습니다.

 

 

개선

슬로우 쿼리의 원인은 MAX() 함수 사용과 비효율적인 retry 로직 구현 등으로 인해 발생하고 있었습니다.

# 프로시저 로직
SELECT MAX(SEQ) FROM ... WHERE 상품_ID = ? AND ...

INSERT ...

# 예외 발생 시 (retry = 1)
SELECT MAX(SEQ) FROM ... WHERE 상품_ID = ? AND ...

INSERT ...

# 예외 발생 시 (retry = 2, SEQ = SEQ + 1)
SELECT MAX(SEQ) FROM ... WHERE 상품_ID = ? AND ...

INSERT ...

# 예외 발생 시 (retry = 3, SEQ = SEQ + 1)
SELECT MAX(SEQ) FROM ... WHERE 상품_ID = ? AND ...

INSERT ...

...

 

저렇게 구현된 히스토리까지는 알 수 없지만, 조회 조건에서 사용된 WHERE 절의 컬럼은 복합 인덱스로 설정되어 있었습니다. 하지만 SEQ가 인덱스에 포함되지 않았기 때문에 데이터가 증가할수록 성능이 저하되는 문제가 발생합니다. 이는 발급이 이루어질 때마다 해당 테이블에 누적해서 쌓이기 때문에, 발급량이 많은 상품일수록 더 많은 데이터가 쌓이는 상황이었습니다.

 

위에서 실행되는 `상품_ID`에 해당하는 상품들을 살펴보니, 발급량이 상대적으로 많은 상품들은 모두 동일한 SEQ 값을 반환하고 있었습니다. SEQ 값은 예를 들어 A01부터 Z99까지(A02, A03 ... Z99) 1씩 증가하면서 만들어지기 때문에, 발급이 자주 발생하는 경우 해당 상품의 SEQ 값은 모두 'Z99'로 동일한 결과를 반환합니다.

 

위 슬로우 쿼리를 개선하기 위해 1) 쿼리 개선, 2) 캐싱 적용, 3) 인덱스 추가 세 가지 방법으로 접근하였습니다.

 

사실 근본적인 해결책은 인덱스를 추가하는 것이지만, 인덱스 작업은 DBA 분이 진행해야 하기에 최소 1~2주가 소요되는 작업입니다. 또한 해당 테이블의 데이터는 수년~수십 년간 누적되었기에 인덱스 추가를 위해서는 과거 데이터 삭제가 먼저 필요했습니다. 이 작업 또한 2~3주는 소요되는 상황이었기에, 데이터 삭제 및 인덱스 작업이 처리되는 동안, 캐싱을 적용하여 개선하고자 했습니다.

 

1) 쿼리 개선

쿼리 개선은 이전에 읽었던 친절한 SQL 튜닝 내용에서 'Top N' 쿼리를 적용할 수 있을 것 같았습니다.

친절한 SQL 튜닝 일부

위 내용을 기반으로 기존 쿼리와 고민했던 쿼리는 다음과 같습니다.

 

# 기존
SELECT NVL(MAX(SEQ), '0')
FROM ...
WHERE 상품_ID = ? AND ...

SORT AGGREGATE는 전체 로우를 대상으로 집계를 수행할 때 나타나는 플랜입니다.

친절함 SQL 튜닝 - 5.1.2 Sort Aggregate

대략적으로 위와 같이 수행이 되는데요, 따라서 기존의 MAX(SEQ) 쿼리도 전체 로우를 대상으로 수행하는 것 같습니다.

 

# Top N
SELECT SEQ 
FROM ( 
	SELECT SEQ 
	FROM ...
	WHERE 상품_ID = ? AND ...
	ORDER BY SEQ DESC
)
WHERE ROWNUM = 1;

COUNT(STOPKEY)에서 ROWNUM으로 지정된 건수만큼 레코드를 얻으면 바로 멈출 것으로 예상을 했지만, 그 아래 부분에SORT(ORDER BY STOPKEY)가 존재하는 것으로 보아 위 쿼리에서는 데이터 정렬이 필요합니다. 그러나 SEQ가 인덱스로 설정이 되어 있지 않기 때문에 결국 SEQ 기준으로 데이터 정렬이 필요하고, 이로 인해 개선 효과를 보지 못했습니다.

 

기존 쿼리는 최댓값을 계산하지만, 두 번째 쿼리는 정렬된 데이터 중 첫 번째 값을 가져오는 방식이라고 이해했고, 그로 인해 SEQ가 기존 인덱스와 함께 복합 인덱스로 설정된다면 정렬 없이 빠르게 가져올 수 있기에, 결국 인덱스가 필요한 상황과 동일하다고 판단했습니다.

 

2) 캐싱 적용

상품 중 발급이 자주 발생하고 SEQ 값이 동일한 상품에 대해서는 캐싱을 적용하여 위의 슬로우 쿼리가 발생하는 프로시저 로직을 호출하지 않더라도 애플리케이션 단에서 빠르게 처리될 수 있도록 했습니다.

 

해당 데이터(SEQ)는 한 번 최댓값에 도달하면 값 자체가 갱신되지 않고, 상품 또한 추가되지 않는 상황이기 때문에 추가적인 작업 및 운영이 필요한 글로벌 캐싱은 크게 고려하지 않았습니다.
분산 서버를 운영 중이지만 데이터의 갱신이나 삭제 작업도 없었기에 로컬 캐시(EhCache, Caffeine) 등도 도입하지는 않았습니다.

 

3) 인덱스 추가

인덱스 추가를 위해서는 먼저 데이터 삭제가 필요한 상황이었습니다. 따라서 과거 n년치의 데이터를 먼저 삭제한 후, 이후에 SEQ 값에 대해 추가적인 복합 인덱스를 설정하였습니다.

 

 

개선 결과

As-Is) 캐싱 전

 

To-Be) 캐싱 후

위 작업들을 처리한 결과, 전체 트래픽 중 일부만 신규 로직으로 유입되고 있어 기존 로직과 신규 로직의 속도 차이가 확연하게 존재합니다.

 

 

테스트

테스트는 동일한 요청값으로 기존 로직과 신규 로직을 각각 호출한 후, 결과와 데이터 정합성이 동일한지를 비교하는 섀도잉 방식으로 검증을 했습니다.

섀도잉(shadowing)은, 동일한 요청에 대해 기존 서비스와 새로운 서비스의 응답이 일치하는지 비교하는 방법을 의미합니다.

데이터가 Insert나 Update 되는 테이블이 많지는 않았기에 직접 데이터를 확인할 수 있도록 SQL 템플릿을 만들고 각 호출마다 비교하며 작업을 진행했었는데요, 테스트를 진행할 때마다 매번 쿼리를 직접 실행해서 비교하는 작업이 번거로웠기에, 이를 간소화하기 위해 애플리케이션 내에서 비교하는 메서드를 구현했습니다. 이를 통해 API가 호출될 때마다 과거 로직과 신규 로직을 동시에 호출하고, 데이터 정합성을 자동으로 비교하여 좀 더 편리하게 비교할 수 있었습니다.

 

작업을 진행하며 뱅크샐러드는 어떻게 레거시 서비스를 박살 내는가 라는 포스팅을 참고했는데, 해당 블로그에서는 기존 서비스와 신규 서비스 응답에 대한 스탯(statsd)을 기록하고, 실제 값의 차이는 키바나(Kibana)에 로깅하여 모니터링 한 부분이 인상적이었습니다.

저희가 가장 먼저 시도했던 건 문제를 단순하게 바꾸어 프로젝트의 가시성을 확보하는 일이었습니다. 이를 위해 저희는 섀도잉shadowing을 도입했습니다. 섀도잉은 말 그대로 같은 요청에 대해 기존 서비스와 새로운 서비스의 응답이 일치하는지 비교하는 방법을 뜻합니다.

레거시 서비스가 기존과 동일하게 모든 HTTP 요청을 처리하여 적절한 응답을 반환하되, 이때 해당 HTTP 요청을 신규 서비스로도 동일하게 요청을 보내도록 했습니다. 이후 신규 서비스의 응답과 기존 서비스의 응답이 일치하는지 여부를 판단해 이를 스탯statsd을 찍도록 처리했고, 실제로 어떤 값이 어떻게 다른지는 키바나Kibana를 통해 검색해볼 수 있도록 로깅했습니다.

https://blog.banksalad.com/tech/how-banksalald-decomposes-legacy-services/

장애에 민감한 API이거나 트래픽이 많은 API라면 위와 같이 완전 자동화의 방법도 고려해볼 수 있을 것 같습니다.

 

 

배포, 롤백, 모니터링

배포는 일부 트래픽만 신규 API로 유입하고, 점진적으로 트래픽의 비중을 높이는 카나리 배포와 비슷한 전략을 사용했습니다.

전사에서 사용 중인 배포 도구는 커스텀 설정이 불가능하기에 애플리케이션 레벨에서 랜덤으로 일부 요청(5%)만 신규 API로 유입되도록 구현하고, 이후 신규 로직이 호출되는 비율을 점진적으로 늘렸습니다.

 

초기 5%의 트래픽만 신규 로직에 할당되었기에, 신규 로직이 언제 호출되는지 계속 모니터링을 해야 했는데요, 지금 돌이켜보면 신규 로직이 호출될 때 슬랙 메시지와 같은 알림을 설정했더라면 이러한 비효율적인 모니터링을 피할 수 있었을 것 같네요. 😂 

롤백 또한 기존에 전사에서 사용 중인 배포 도구를 그대로 활용했습니다. 문제 발생 시 롤백에는 최대 2~3분 정도 소요될 수 있었지만, 해당 API가 그 정도로 민감하지는 않았고, 클라이언트 측에서 3회의 재시도(Retry) 로직이 존재했기 때문에 신규 로직에서 실패하더라도 이후 기존 로직이 호출될 가능성이 높았습니다. 따라서 장애 발생 시 즉각적인 롤백이 반드시 필요한 상황은 아니었습니다.

 

롤백 전략에 대해서는 6년 묵은 레거시, RootController 리팩토링하기 포스팅을 참고했는데, 빠른 트러블 슈팅이 필요한 상황이라면 Feature Flag 등을 활용하여 빠르게 대응할 수 있는 방법을 고려해 볼 수 있을 것 같습니다.

이렇게 큰 작업을 진행할 때 예상치 못한 변수가 있기 마련입니다. 29CM 앱은 여러 플랫폼이 함께 만들고 다양한 서비스를 제공하고 있기 때문에 모든 케이스를 완벽하게 커버하기 쉽지 않습니다. RootController 특성상 앱 사용이 불가능한 경우가 생길 수도 있기 때문에 빠른 트러블 슈팅이 필요했습니다. 하지만 모바일 어플리케이션 배포 프로세스 특성상 FE 나 BE 처럼 빠르게 대응할 수 없죠.

이를 해결하기 위해 원격으로 코드를 분기할 수 있는 Remote Flag 기능을 사용했습니다. 적절한 분기 로직을 구현하고 원격으로 ON/OFF 를 할 수 있다면 이슈가 발생했을 때 새로운 배포없이 빠르게 대응할 수 있죠.

이 작업의 핵심 전략은 말 그대로 롤백의 여지를 두고 개발하는 것에 있습니다. 저희는 Amplitude 의 Flag 기능을 통해 실시간으로 기능의 ON/OFF 여부를 결정할 수 있게 개발합니다. 개발의 안정성을 위해, 데이터의 정합성을 위해, 실험 결과를 즉시 반영하기 위해 적절한 분기 로직을 개발하는데 신경씁니다.

 

 

트러블 슈팅

해당 작업을 진행하며 발생한 문제는 크게 두 가지 정도가 있었는데요, 1. 동시성 문제 와 2. 예상치 못한 트래픽 유입 입니다.

두 가지 문제에 대해 살펴보겠습니다.

 

1. 동시성 문제

특정 프로시저를 Java Application으로 이관하는 과정에서 동시성 문제가 발생했습니다.

로컬 및 개발 서버에서 충분히 테스트를 진행했다고 생각했지만, 운영 환경에서 발생한 예상치 못한 이슈였었는데요,

 

Whatap의 히트맵 트랜잭션 ;;;;

해당 프로시저의 로직은 다음과 같습니다.

1. 요청 데이터를 기반으로 발급 가능한 상품의 쿠폰 번호 조회
2. 조회한 쿠폰 번호가 중복된 쿠폰인지 체크 (쿠폰 번호를 PK로 사용하는 가지는 테이블에 INSERT) --> 동시성 문제 발생
3. 발급 가능한 쿠폰 번호라면, 쿠폰 테이블에서 발급 처리 (Update)

동시성이 발생하는 경우는 2번 단계에서 비슷한 시간에 동일한 상품에 대한 발급 요청이 들어올 때 발생합니다.

 

해당 프로시저가 처리되고 난 후 슬로우 쿼리가 발생하여 트랜잭션이 계속 대기하는 상황이고, 그로 인해 요청 A와 B가 동일한 상품에 대해 요청을 할 경우, 동일한 쿼리 조건으로 인해 동일 쿠폰 번호를 조회하고, 두 요청 모두 커밋이 되지 않은 채 슬로우 쿼리로 인해 웨이팅이 발생하여 최종적으로 늦게 요청 온 B의 경우 커밋 시점에서 PK 예외가 발생합니다.

 

위 이미지가 발생한 이유에 대한 설명인데요, 대략적으로는 다음과 같습니다.

• 요청 A가 프로시저를 호출하여 쿠폰 번호(1234)를 조회하고, INSERT 성공 (Commit 전)
• 이후 A는 슬로우 쿼리로 인해 Waiting
• 요청 B가 동일한 상품으로 프로시저를 호출 후 동일한 쿠폰 번호(1234)조회, INSERT 성공 (Commit 전)
• B도 마찬가지로 슬로우 쿼리로 인해 Waiting
• 먼저 호출한 A의 슬로우 쿼리가 종료된 후 Commit에 성공
• 뒤늦게 호출한 B의 경우 슬로우 쿼리 종료 후 Commit을 시도하지만, 이 시점에서 PK 예외 발생

동일한 쿠폰 번호를 조회하는 요청 A, 요청 B

 

위 문제를 통해 기존 프로시저 로직에서 이해하지 못했던 부분이 하나 해결되었습니다.

해당 프로시저의 로직은 위와 동일하게 쿠폰 번호 조회 -> INSERT -> PK Exception 발생 시 동일하게 쿠폰 번호 조회 -> INSERT ... 의 로직으로 애플리케이션의 Retry 로직이 프로시저 내에 구현되어 있었습니다.

 

이 동시성 문제를 해결하기 위해 가장 먼저 접근한 방법은 트랜잭션을 분리하는 방법인데요, (SELECT-INSERT-UPDATE) 로직과 슬로우 쿼리가 발생하는 로직에 대해 트랜잭션을 분리하여 INSERT 로직을 수행한 후 즉시 Commit을 처리하면 해결되지 않을까 생각했습니다.

위와 같이 전파 속성을 REQUIRES_NEW 로 설정하여, 슬로우 쿼리가 발생하기 전 Commit이 먼저 처리되면, 다른 트랜잭션에서 쿠폰 번호를 조회할 때 다른 쿠폰 번호를 조회할 것이라고 생각했습니다.

Spring Transaction Propagation

 

 

하지만 트랜잭션을 분리하더라도 동일한 문제가 발생했습니다. 요청 A(빨간색), 요청 B(파란색)을 시간대별로 정리해보면 다음과 같습니다.

• [11:00:15.707, exec-50] 발급요청
• [11:00:15.710, exec-51] 발급 요청
• [11:00:15.790, exec-50] 쿠폰 발급 성공
• [11:00:15.843, exec-51] 쿠폰 발급 실패 (PK 예외 발생)

트랜잭션을 분리했음에도 두 요청이 0.003초라는 매우 짧은 시간 차이로 왔기에 커밋 자체가 0.003초 안에 완료되지 못하면서 동일한 문제가 발생했습니다.

 

다음으로는 기존 프로시저 로직과 비슷하게 쿠폰 번호 조회 시 N개를 조회 하고, 동일한 로직을 수행하되 PK 에러가 발생하면 try-catch로 예외를 잡고, 다음 쿠폰 번호로 처리하도록 작업을 했습니다.

위 방식을 적용한 이후로 동일한 문제는 발생하지 않았습니다.

(참고로 트랜잭션의 전파 속성을 REQUIRES_NEW로 설정하지 않으면, try-catch로 예외를 처리하더라도 rollback-only marked로 인해 롤백이 발생하여, 예상했던 로직과 다르게 작동할 수 있습니다. 이와 관련하서는 응? 이게 왜 롤백되는거지? 를 참고해주세요!)

 

애플리케이션이나 데이터베이스에 제공하는 Lock을 이용하면 더 깔끔하게 해결할 수 있었을 것 같은데, 이와 같이 처리한 이유는 다음과 같습니다.

• 모든 케이스에서 동시성 문제가 발생하는 것이 아닌, 특정 제휴사나 상품에 대해서만 발생합니다.
• 과거 히스토리를 살펴본 결과, 특정 제휴사에서 발급 처리량을 늘리기 위해 병렬로 발급 API를 호출하는 상황이 있었고, 병렬로 처리하는 스레드 수는 최대 3개였기 때문에 이 수는 추가 요청이 없으면 증가하지 않습니다.

만약 Lock을 적용한다면, 특정 상품에 대해서는 동시성이 빈번하게 발생하는 상황이기에 특정 상품에 대해서만 부분적으로(특정 상품, 제휴사 등) 비관적 락을 적용해 볼 수 있을 것 같습니다.

 

 

2. 예상치 못한 트래픽 유입

위 문제는 쿠폰 발급 시 발생하던 슬로우 쿼리가 개선됨에 따라 쿠폰의 생성 속도가 발급 속도를 따라가지 못하여 발생한 이슈인데요, 클라이언트에 존재하는 리트라이(최대 3회) 로직으로 인해 3배의 트래픽이 유입되었습니다.

 

현재 구조는 대략적으로 위와 같은데요,

외부 제휴사가 발급 요청을 위해 내부 서버에 요청하고, 내부 서버에서 다시 발급 서버로 API 요청을 보내는 구조입니다.

(내부 서버 없이 외부 제휴사에서 바로 발급 서버에 요청하는 게 가장 단순하지만, 정확한 히스토리를 알 수는 없지만 과거 사업 계약으로 인해 내부 서버를 경유하는 구조가 되었고, B2B와 B2C에 따라 처리 방식이 다르게 되어있는 것으로 들었던 것 같습니다..;)

 

외부 제휴사에서는 요청한 수량만큼 쿠폰을 받지 못하면 무한히 요청을 반복하는 프로세스로 구현되어 있습니다. 과거에는 슬로우 쿼리로 인해(?) 쿠폰이 생성되는 시간을 어느 정도 확보할 수 있었지만, 현재는 API 응답이 즉시 이루어지기 때문에 요청 빈도가 더욱 증가하게 된 상황입니다.

 

따라서 위의 문제를 개선하기 위해 적용한(적용할 수 있는) 방법은 다음과 같습니다.

• 외부 제휴사에서 발급 요청 시 에러가 발생하면 충분한 간격을 두고 재시도하도록 변경
• 쿠폰 잔여량이 부족할 경우 내부 팀에서는 Retry 로직을 제거한다.
• Rate Limiter 등을 구현하고, 많은 호출량에 대해 적절하게 제어한다.
• 대량 발급이 필요한 경우, 쿠폰 풀을 사전에 충분히 확보하고 자체 모니터링을 강화한다.

 

사실 근본적인 해결책은 쿠폰 생성 로직을 개편해야 하지만, 당시에는 여러 제약이 존재했고 미래에는 시스템 통합 등의 계획도 있었기에 해당 작업을 진행하지는 못했습니다.

 

 

결과(성과)

As-Is

 

To-Be

기존 API의 트랜잭션과 신규 API의 트랜잭션 성능 비교 입니다.

 

평균 처리 시간이 약 1,500ms에서 25ms로 개선되었습니다. (캐싱적용, 과거 데이터 삭제, 인덱스 적용)

최대 처리 시간도 60,000ms에서 1,400ms로 개선되었습니다. (슬로우 쿼리 개선 및 프로시저 내 비효율적인 Retry 로직 제거 등)

 

 

회고

작업을 하고나서 꽤나 시간이 지나서 작성하게 되어서, 정확히 기억나지 않거나 자료가 없는 부분도 존재합니다.

 

작업하면서 깨닫고, 얻게된 교훈은 다음과 같습니다.

• 크고 복잡한 문제는 (항상) 가능한 작은 단위로 분할하고 접근하자.
• 코드 내 (오래된) 주석을 신뢰하지 말고 경계하자..
• 미래의 제3자 (혹은 본인)를 위해 코드 가독성에 충분히 신경 쓰자.
• 운영 환경에서는 항상 사이드 이펙트가 발생할 수 있음을 염두에 두고 작업하자.