MSA 중앙 로그 관리와 동시성 문제 해결

게시 2026/06/09 업데이트 2026/06/09

읽는 시간 7분

For the English version of this post, see here.

오늘 배운 개념

MSA는 여러 가지 서비스가 독립적으로 동작하기 때문에, 문제가 발생했을 때 어느 서비스에서 어떤 요청이 실패했는지 추적하기 어렵다. 그래서 로그를 한곳에 모아 관리하는 중앙 로그 관리가 필요하다.

또한 여러 사용자가 동시에 같은 데이터를 수정하거나 조회할 때 데이터 불일치가 생길 수 있는데, 이를 동시성 문제라고 한다.

MSA에서는 서비스가 여러 개로 나뉘어 있기 때문에 각 서비스의 로그를 따로 확인하면 장애 원인을 찾기 어렵다.

예를 들어 쇼핑몰에서 주문이 실패했을 때, 문제가 회원 서비스인지, 주문 서비스인지, 결제 서비스인지 한눈에 알기 어렵다.

그래서 각 서비스의 로그를 중앙으로 모아 검색하고 분석할 수 있는 구조가 필요하다.

대표적으로 ELK Stack 같은 도구를 활용할 수 있다.

즉, 중앙 로그 관리는 MSA에서 분산된 서비스의 상태를 한곳에서 관찰하기 위한 체계라고 볼 수 있다.

동시성 문제는 여러 요청이나 트랜잭션이 동시에 같은 데이터에 접근하거나 수정할 때 데이터 정합성이 깨지는 문제를 말한다.

예를 들어 재고가 1개 남은 상품을 두 명의 사용자가 동시에 주문하면, 두 요청이 모두 재고가 있다고 판단해 주문에 성공할 수 있다. 이 경우 실제 재고보다 더 많이 판매되는 문제가 발생한다.

동시성 문제에는 대표적으로 다음과 같은 종류가 있다.

Lost Update
- 여러 트랜잭션이 같은 데이터를 동시에 수정하면서, 먼저 수행된 수정 결과가 나중 수정에 의해 덮어씌워지는 문제
Dirty Read
- 아직 커밋되지 않은 다른 트랜잭션의 변경 데이터를 읽는 문제
Non-repeatable Read
- 같은 트랜잭션 안에서 같은 데이터를 두 번 읽었는데, 중간에 다른 트랜잭션이 수정하여 결과가 달라지는 문제
Phantom Read
- 같은 조건으로 데이터를 조회했는데, 중간에 다른 트랜잭션이 데이터를 추가하거나 삭제해서 조회 결과의 행 개수가 달라지는 문제
Race Condition
- 여러 작업이 실행되는 순서에 따라 결과가 달라지는 문제

이러한 동시성 문제를 해결하기 위해 다음과 같은 방법을 사용할 수 있다.

트랜잭션 격리 수준
- 동시에 실행되는 트랜잭션들이 서로에게 어느 정도 영향을 줄 수 있는지 정하는 기준이다.
- 격리 수준을 높이면 데이터 정합성은 좋아지지만 성능은 떨어질 수 있다.
비관적 락
- 충돌이 자주 발생할 것이라고 보고, 데이터를 조회하거나 수정할 때 미리 잠금을 거는 방식이다.
- 재고 차감처럼 충돌 가능성이 높은 기능에 사용할 수 있다.
낙관적 락
- 충돌이 자주 발생하지 않는다고 보고, 수정 시점에 버전 정보를 비교해 충돌 여부를 확인하는 방식이다.
- 충돌이 발생하면 다시 시도하거나 사용자에게 실패를 안내할 수 있다.
분산 락
- 여러 서버 인스턴스가 동시에 같은 자원에 접근할 때, Redis 같은 외부 저장소를 이용해 공통 잠금을 관리하는 방식이다.
- MSA나 서버가 여러 대인 환경에서 사용할 수 있다.

정리하면, 동시성 문제는 단순한 코드 오류가 아니라 동시에 실행되는 요청들 사이에서 데이터 정합성을 어떻게 지킬 것인가에 대한 문제이다. 따라서 서비스의 특성에 따라 트랜잭션 격리 수준, 락 전략, 재시도 정책 등을 적절히 선택해야 한다.

MSA에서는 서비스가 분리되어 있기 때문에 단순히 기능을 나누는 것뿐 아니라, 운영 관점에서 로그 추적과 모니터링이 중요하다는 것을 알게 되었다.

또한 동시성 문제는 실제 서비스에서 재고, 쿠폰, 포인트, 예약 같은 기능에서 자주 발생할 수 있으며, 데이터 정합성을 지키기 위해 락이나 트랜잭션 격리 수준을 적절히 사용해야 한다는 점을 이해했다.