long transaction, group transaction

📘 OEA

1. 개요

트랜잭션 기반 적재 시스템을 운영하다 보면 두 가지 문제가 반복해서 부딪힙니다.

하나는 Long Transaction이 메모리를 오래 점유하는 문제이고, 다른 하나는 작은 트랜잭션이 너무 자주 COMMIT되면서 DB 부하를 키우는 문제입니다.

처음에는 이 두 문제를 별개의 현상으로 봤습니다. 하나는 메모리 문제이고, 다른 하나는 DB I/O 문제처럼 보였기 때문입니다. 그런데 운영 관점에서 다시 보면 둘 다 같은 질문으로 연결됩니다.

트랜잭션을 언제까지 메모리에 붙들고 있을 것인가. 그리고 DB에는 어떤 시점에 어떤 단위로 반영할 것인가.

기존 구조는 COMMIT이 도착할 때까지 트랜잭션 데이터를 메모리에 계속 쌓아두는 방식이었습니다. 이 방식은 구현이 단순하고 트랜잭션 경계도 직관적입니다. 하지만 트랜잭션이 길어지면 메모리 사용량이 커지고, 반대로 짧은 트랜잭션이 자주 들어오면 DB에는 잦은 COMMIT이 발생합니다.

이번 개선의 목적은 단순한 성능 튜닝이 아니었습니다.

핵심은 다음 세 가지였습니다.

• Long Transaction으로 인한 메모리 불안정을 줄일 것
• COMMIT 가능한 단위만 묶어서 DB 부하를 낮출 것
• 성능을 올리더라도 트랜잭션 무결성은 깨지지 않게 할 것

이를 위해 트랜잭션 처리 구조를 두 단계로 나눴습니다.

첫째, flush와 commit을 분리했습니다.

둘째, commit 가능한 트랜잭션만 그룹으로 묶는 방식을 도입했습니다.

---

2. 기존 구조의 한계

기존 구조는 단순했습니다.

• 트랜잭션 시작 후 들어오는 변경 데이터를 메모리에 적재한다.
• COMMIT이 도착하면 그 시점에 DB에 반영한다.
• 반영이 끝나면 checkpoint를 기록한다.

문제는 이 구조가 트랜잭션 길이에 지나치게 민감하다는 점이었습니다.

트랜잭션이 짧고 규칙적으로 끝나면 큰 문제가 없습니다. 하지만 운영 환경에서는 항상 그런 식으로만 데이터가 들어오지 않습니다. 특정 구간에서는 하나의 트랜잭션이 예상보다 길어질 수 있고, 반대로 아주 작은 트랜잭션이 짧은 간격으로 연달아 들어올 수도 있습니다.

이 구조에서는 두 가지 한계가 분명했습니다.

첫째, Long Transaction은 메모리 사용량을 계속 밀어 올립니다.

COMMIT이 오기 전까지는 데이터를 내려놓을 곳이 없기 때문에, 트랜잭션이 길수록 메모리 점유 시간이 함께 늘어납니다. 일정 수준을 넘어서면 GC 부담이 커지고, 최악의 경우 OOM 위험으로 이어질 수 있습니다.

둘째, 짧은 트랜잭션은 DB에 과도한 COMMIT 부하를 만듭니다.

트랜잭션 하나가 끝날 때마다 바로 COMMIT하면 DB 입장에서는 작은 작업을 매우 자주 처리해야 합니다. 데이터 반영 자체보다 COMMIT와 checkpoint 갱신이 더 자주 발생하면서 전체 처리 효율이 떨어질 수 있습니다.

결국 기존 구조는 단순했지만, 다음과 같은 트레이드오프를 전혀 흡수하지 못했습니다.

• 메모리 안정성 vs 트랜잭션 종료 대기
• DB 반영 시점 vs COMMIT 빈도
• 처리량 개선 vs 무결성 보장

이 문제는 로직 몇 줄을 손보는 수준이 아니라, 트랜잭션을 다루는 단위를 다시 정의하는 문제에 가까웠습니다.

---

3. Long Transaction이 만든 메모리 문제

가장 먼저 손본 것은 Long Transaction 처리 방식이었습니다.

기존에는 COMMIT이 오기 전까지 모든 변경 데이터를 메모리에 유지했습니다. 이 방식은 트랜잭션 단위를 보존하기에는 깔끔하지만, 실제 운영에서는 ”언제 끝날지 모르는 트랜잭션”을 메모리로 버티는 구조가 됩니다.

이 구조가 위험한 이유는 단순히 메모리를 많이 쓴다는 데 있지 않습니다.

더 큰 문제는 메모리 사용량이 트랜잭션 길이에 직접 종속된다는 점입니다. 시스템이 처리량을 늘리기 위해 감당해야 하는 비용이 아니라, 특정 트랜잭션 하나의 길이에 의해 메모리 안정성이 흔들리는 구조는 운영하기 어렵습니다.

특히 CDC나 적재 파이프라인처럼 입력 패턴을 완전히 통제할 수 없는 시스템에서는 더 그렇습니다. 대부분의 트랜잭션이 짧더라도, 몇 개의 비정상적으로 긴 트랜잭션이 전체 프로세스의 메모리 곡선을 망가뜨릴 수 있습니다.

즉 문제는 ”가끔 긴 트랜잭션이 있다”가 아니라, 긴 트랜잭션 하나가 시스템 안정성을 위협할 수 있는 구조 자체였습니다.

---

4. flush와 commit을 분리한 이유

이 문제를 풀기 위해 선택한 방식은 COMMIT 전 선적재 구조였습니다.

핵심은 간단합니다.

• 트랜잭션 건수나 대기 시간이 임계치를 넘으면
• COMMIT이 오기 전이라도 DB에 먼저 flush한다.
• flush가 끝나면 메모리는 비운다.
• 다만 이 시점에는 commit하지 않는다.
• 최종 COMMIT이 도착했을 때만 실제 commit과 checkpoint 기록을 수행한다.

즉, 데이터 적재 시점과 트랜잭션 확정 시점을 분리한 것입니다.

이 구조에서 중요한 것은 flush를 commit처럼 다루지 않는다는 점입니다.

flush는 어디까지나 메모리 압력을 줄이기 위한 중간 적재입니다. 트랜잭션이 완료됐다는 뜻이 아닙니다. 그래서 flush 이후에도 해당 트랜잭션은 여전히 ”미완료 상태”로 관리되어야 하고, 최종 COMMIT 전까지는 checkpoint 역시 전진하면 안 됩니다.

이렇게 보면 이번 변경은 단순 최적화가 아닙니다. 구조적으로는 다음과 같은 의미가 있습니다.

• 메모리 사용량을 트랜잭션 전체 길이에서 분리한다.
• DB 적재와 트랜잭션 확정을 다른 이벤트로 관리한다.
• COMMIT 이전 데이터와 COMMIT 완료 데이터를 명확히 구분한다.

이 분리가 필요한 이유는 분명합니다.

메모리 안정성을 위해 데이터를 일찍 내려놓고 싶다고 해서, 트랜잭션 경계까지 함께 당겨오면 안 됩니다. 반대로 무결성을 지키겠다고 모든 데이터를 끝까지 메모리에 들고 있으면 운영 안정성이 나빠집니다.

결국 필요한 것은 둘 중 하나를 포기하는 방식이 아니라, flush와 commit의 책임을 분리하는 방식이었습니다.

---

5. 개선된 Long Transaction 처리 방식

개선 이후 Long Transaction의 흐름은 다음과 같습니다.

1. 트랜잭션 시작 후 변경 데이터가 들어오면 우선 메모리에 적재한다.
2. 적재 건수나 대기 시간이 기준치를 넘으면 현재까지의 데이터를 DB에 flush한다.
3. flush가 끝난 데이터는 메모리에서 제거한다.
4. 이후 들어오는 같은 트랜잭션의 후속 데이터는 다시 메모리에 적재한다.
5. 최종 COMMIT이 도착하면, 아직 남아 있는 데이터를 반영한 뒤 전체 트랜잭션을 commit하고 checkpoint를 기록한다.

이 방식의 장점은 분명합니다.

우선 Long Transaction이 길어져도 메모리가 무한정 커지지 않습니다. 메모리는 전체 트랜잭션 길이보다 flush 임계치에 더 직접적으로 영향을 받게 됩니다. 운영 측면에서는 이것만으로도 시스템을 훨씬 예측 가능하게 만들 수 있습니다.

동시에 트랜잭션 무결성도 유지할 수 있습니다. DB에 먼저 적재된 데이터가 있더라도, 최종 commit 전까지는 완료된 트랜잭션으로 취급하지 않기 때문입니다.

정리하면 이 구조의 핵심은 다음과 같습니다.

• 메모리는 오래 붙들지 않는다.
• DB에는 미리 적재할 수 있다.
• 하지만 트랜잭션 완료 판정은 COMMIT에서만 한다.

이 세 가지를 분리하지 않으면 Long Transaction 문제는 메모리와 무결성 중 하나를 희생하는 방향으로 흐르기 쉽습니다.

---

6. Group Transaction이 필요한 이유

Long Transaction 문제를 정리하고 나면, 반대쪽 끝에 있는 작은 트랜잭션들이 보입니다.

이 경우 문제는 메모리가 아니라 COMMIT 빈도입니다.

작은 트랜잭션이 자주 들어오면 각 트랜잭션은 금방 끝납니다. 개별 트랜잭션만 놓고 보면 부담이 작아 보이지만, 시스템 전체로 보면 DB는 매우 짧은 간격으로 반복적인 COMMIT과 checkpoint 갱신을 수행하게 됩니다.

이 상황에서는 데이터 반영 자체보다 작은 단위의 완료 처리를 너무 자주 수행하는 비용이 더 눈에 띄기 시작합니다.

특히 적재 시스템은 단건 응답 시간을 겨루는 시스템이 아니라, 일정 구간 동안 안정적으로 처리량을 유지하는 쪽이 더 중요할 때가 많습니다. 그런 환경에서 작은 트랜잭션을 모두 즉시 COMMIT하는 방식은 구현은 단순하지만, 운영 효율은 그만큼 떨어질 수 있습니다.

그래서 도입한 것이 Group Transaction 방식입니다.

---

7. Group Commit을 어떻게 설계했는가

여기서 중요한 점은 ”트랜잭션을 무조건 묶는다”가 아니라는 것입니다.

묶을 수 있는 것은 이미 COMMIT 조건을 충족한 트랜잭션뿐입니다.

개선된 방식은 다음과 같습니다.

• 개별 트랜잭션의 데이터 반영은 기존 규칙대로 처리한다.
• COMMIT이 도착해 완료 가능한 상태가 된 트랜잭션은 즉시 단건 commit하지 않고 대기열에 둔다.
• 이 대기열은 건수 기준 또는 timeout 기준으로 모아서 일괄 commit한다.
• 다만 아직 COMMIT이 오지 않은 트랜잭션은 timeout이 지나도 절대 commit하지 않는다.

즉, 그룹핑의 기준은 시간이나 건수이지만, 커밋 가능 여부의 기준은 항상 트랜잭션 상태입니다.

이 차이가 중요합니다.

성능만 보면 timeout이 왔을 때 대기 중인 것들을 한 번에 밀어 넣고 싶어질 수 있습니다. 하지만 그 안에 아직 COMMIT되지 않은 트랜잭션이 섞이면, 그 순간부터 시스템은 처리량은 얻더라도 무결성을 잃게 됩니다.

그래서 Group Commit은 배치 최적화가 아니라, 무결성 경계를 유지한 상태에서만 허용되는 배치 전략으로 설계되어야 합니다.

---

8. timeout이 와도 커밋하면 안 되는 이유

이 부분은 생각보다 자주 오해됩니다.

timeout이 왔다는 것은 ”오래 기다렸다”는 뜻이지, ”트랜잭션이 끝났다”는 뜻이 아닙니다.

시스템 입장에서 기다림의 길이와 트랜잭션 완료 여부는 전혀 다른 신호입니다. 그런데 둘을 같은 것으로 취급하면, 아직 끝나지 않은 트랜잭션을 시스템이 임의로 확정해버리는 문제가 생깁니다.

이렇게 되면 다음과 같은 문제가 발생할 수 있습니다.

• 일부 변경만 반영된 상태에서 트랜잭션이 종료된 것처럼 보일 수 있다.
• 이후 들어온 실제 COMMIT 이벤트와 시스템 상태가 어긋날 수 있다.
• checkpoint가 앞서 나가면서 재처리 기준점이 깨질 수 있다.

결국 timeout은 배치 윈도우를 닫는 기준일 수는 있어도, 트랜잭션 완료를 판정하는 기준이 될 수는 없습니다.

그래서 이번 구조에서는 다음 원칙을 유지했습니다.

• timeout은 이미 commit 가능한 것들을 모아 반영하는 기준
• COMMIT 이벤트는 트랜잭션 완료를 판정하는 유일한 기준

이 원칙이 있어야 Group Commit을 적용해도 트랜잭션 의미가 흔들리지 않습니다.

---

9. 이번 개선이 가진 의미

이번 작업의 핵심은 성능 수치를 조금 올린 데 있지 않습니다.

더 중요한 것은 트랜잭션 처리 구조를 다음처럼 분리했다는 점입니다.

• 메모리 관점에서는 flush를 통해 Long Transaction 압력을 낮추고
• DB 관점에서는 Group Commit을 통해 잦은 완료 비용을 줄이고
• 무결성 관점에서는 commit 가능한 경계만 엄격하게 인정한 것

즉, 하나의 기법으로 모든 문제를 해결한 것이 아니라, 각 문제를 서로 다른 책임으로 나눠 다뤘습니다.

이런 종류의 개선은 보통 코드 몇 줄로 설명되지 않습니다. 중요한 것은 어떤 함수를 추가했는지가 아니라, 시스템이 트랜잭션을 어떤 상태로 인식하고 어떤 이벤트를 기준으로 다음 단계로 넘기는지입니다.

이번 구조를 통해 얻은 것은 크게 두 가지입니다.

첫째, Long Transaction이 들어와도 메모리 사용량을 더 안정적으로 관리할 수 있게 됐습니다.

둘째, 짧은 트랜잭션이 많아도 DB에 불필요한 COMMIT 압력을 덜 주게 됐습니다.

그리고 그 두 가지를 얻는 과정에서 가장 중요하게 지킨 것은, 성능 개선이 트랜잭션 의미를 침범하지 않게 하는 것이었습니다.

---

10. 결론

트랜잭션 처리 시스템에서 성능과 무결성은 자주 충돌하는 것처럼 보입니다.

메모리를 아끼려면 빨리 내려놓고 싶고, DB 부하를 줄이려면 묶어서 처리하고 싶습니다. 하지만 그 과정에서 트랜잭션 완료의 의미까지 흐려지면, 결국 시스템은 빨라지는 대신 신뢰를 잃게 됩니다.

이번 개선은 그 충돌을 피하는 방향으로 구조를 다시 잡는 작업이었습니다.

Long Transaction에 대해서는 COMMIT 전 선적재를 통해 메모리 압력을 분산했고, 작은 트랜잭션에 대해서는 commit 가능한 것만 묶는 Group Commit을 통해 DB 부하를 줄였습니다. 그리고 그 두 구조를 관통하는 원칙으로 flush와 commit을 분리하고, COMMIT 이벤트만 최종 확정 기준으로 사용했습니다.

운영 시스템에서는 단순히 빠른 구조보다, 왜 안전한지 설명할 수 있는 구조가 더 오래 갑니다.

이번 개선은 바로 그 지점을 정리한 작업이었습니다.