[MSA]분산 트랜잭션(Distributed Transaction) 튜토리얼

목차

 

Distributed Transaction

 

분산 트랜잭션은 여러 개의 컴퓨터, 혹은 노드, 서버에 걸쳐 실행되는 트랜잭션이다.

 

정의상 두 개의 컴퓨터 사이의 트랜잭션도 분산 트랜잭션이라 부를 수 있지만,

 

보통 분산 트랜잭션이라고 하면 대규모 분산 시스템 혹은 네트워크에서 이루어지는 것을 가리키며

 

트랜잭션과 마찬가지로 데이터 일관성과 안정성을 보장하기 위해 사용된다.

 

하지만 분산 시스템은 그 특유의 복잡성 때문에 ACID원칙을 전부 지키기는 어려운데,

 

이를 최대한 보장하기 위한 기술에 대해 몇 가지 정리하고 넘어가겠다.

 

ACID

 

• Atomicity(원자성)
  각 트랜잭션 작업은 원자성을 지녀야 한다. 이 말은 트랜잭션이 전부 성공하거나 전부 실패해야 함을 뜻한다.
• Consistency(일관성)
  트랜잭션의 실행 전과 후, 데이터베이스의 로직을 비롯한 상태는 일관되어야 한다. 데이터베이스의 무결성 유지를 가리킨다.
• Isolation(고립성)
  각 트랜잭션은 서로의 영향을 받지 않고 독립적으로 실행되어야 한다. 동시성 제어가 이것을 보장한다.
• Durability(지속성)
  트랜잭션이 성공했다면, 해당 변경사항은 영구적으로 저장되는 것이 보장되어야 한다.
  이는 시스템의 장애 발생에도 데이터가 유실되지 않는 것을 가리킨다.

 

2PC(2-Phase Commit)

 

 

2PC는 말 그대로 두 단계로 이루어진 커밋을 의미한다.

 

위에 적었듯이 분산 시스템에서 여러 개의 노드가 함께 수행해야 하는 트랜잭션의 안정성을 보장하기 위한 방식이며,

 

무엇보다 가장 많이 사용되는 방식이다.

 

구체적으로 아래의 두 단계를 거쳐 커밋이 수행된다.

 

• Prepare Phase(Phase 1)
  요청을 보내는 주체(코디네이터 노드라고 부른다)가 대상 노드에게 준비 여부를 물어본다.
  개별 노드는 이에 대한 대답으로 Yes 혹은 No를 리턴하며,
  모든 노드가 준비가 된 상태라면 커밋 요청을, 그렇지 않다면 롤백 요청을 보낸다.
• Commit Phase(Phase 2)
  전송된 커밋 또는 롤백을 노드에서 처리 후 응답을 전송한다.
  이처럼 모든 노드가 동일한 트랜잭션을 사용하는 경우 2PC는 유용하다.

이 방식은 위에서 본 것처럼 모든 노드에서 트랜잭션의 일관성을 보장한다는 장점이 있다.

 

하지만 하나의 노드라도 실패하면 전체 노드가 롤백되기 때문에 성능이 낮고

 

하나의 노드라도 통신 장애가 발생하면 해당 트랜잭션을 Block 한 채 다른 트랜잭션의 처리도 지연시켜 가용성이 낮은 편인데,

 

이를 가리켜 Single Point of Failure(SPOF)라고 부른다.

 

3PC(3-Phase Commit)

 

 

3PC는 위와 같은 2PC의 단점을 보완하기 위해 개발된 알고리즘이다.

 

조금 구체적으로는 준비와 커밋 사이에 한 단계를 추가해 각 단계에서 코디네이터와 나머지 노드들이

 

일정 시간 이상 기다리다가 timeout이 발생하면 트랜잭션을 중지하고 롤백하도록 처리한다.

 

이는 2PC에서 발생하는 Blocking 문제를 최소화할 수 있다는 장점이 있으나,

 

여전히 개별 노드의 처리가 늦어진 경우 트랜잭션이 지연되는 문제점은 남아있다.

 

단계별 진행은 아래와 같다.

 

• Prepare Phase(Phase 1)
  코디네이터가 대상 노드에게 Prepare 신호를 보낸다.
  각 노드는 트랜잭션 준비가 끝나는대로 완료 신호를 전송한다.
  하나라도 준비가 되지 않으면 코디네이터는 작업을 취소하고 트랜잭션을 롤백한다.
• Pre-Commit(Phase 2)
  코디네이터가 대상 노드에게 Pre-Commit 신호를 보낸다.
  각 노드는 완료 신호(ACK-Acknowledgement)를 전송한다.
  하나라도 신호를 받지 못하거나 전송하지 않으면 작업을 취소하고 트랜잭션을 롤백한다.
• Commit Phase(Phase 3)
  코디네이터가 각 노드에 Commit을 전송한다.
  노드는 커밋을 처리하고 완료 요청을 전송한다.
  하나라도 커밋 메시지를 받지 못하거나 처리하지 못하면 작업을 취소하고 트랜잭션을 롤백한다.

 

Saga Pattern

 

사가패턴은 각 서비스와 그에 속한 데이터베이스 사이의 데이터 일관성을 포기하고(!)

 

대신 최종 일관성(Eventual Consistency)을 선택하는 패턴이다.

 

최종 일관성이란 데이터 변경이 즉시 반영되는 것이 아닌 일정 시간을 두고 반영되는 것을 보장하는 것을 가리킨다.

 

주로 데이터를 비동기로 업데이트하며, 각 노드의 로컬에 레플리카를 유지한다.

 

이는 시스템 전체의 일관성을 일부 포기하는 대신 빠른 처리속도를 보장하며

 

특히 네트워크 장애와 같은 예측 불가능한 사태에 유연하게 대처할 수 있다.

 

 

이는 앞서 살펴본 2PC와 3PC가 데이터 일관성을 위해 지불해야 하는 오버헤드가 너무 크기 때문이며

 

대신 분산된 마이크로서비스 내부에서 각자의 데이터를 보호하며 트랜잭션을 처리하는 방법을 사용한다.

 

이름처럼 길게 늘어지는 트랜잭션이 특징이며, 다른 명칭으로는 Long-running Transaction이라고 불리기도 한다.

 

이 사가 패턴을 구현하는 방법은 크게 두 가지가 있는데, 하나씩 알아보자.

 

Choreography-Based Saga Pattern

 

코레오그래피란 안무를 말한다. 발레, 춤, 체조 등에서의 그 안무 말이다.

 

이름처럼 각 서비스, 혹은 노드가 각자의 작은 트랜잭션을 처리 혹은 롤백으로 책임지며 처리 후엔 다음 노드를 호출하는 식이다.

 

이를 위해 모든 노드는 패턴에 참여하는 모든 서비스와 통신하며 그 상태를 추적할 필요가 생긴다.

 

이를 바탕으로 장단점을 짧게 정리하면 아래와 같다.

 

• 장점
  
  
  • 중앙 집중식 코디네이터가 필요하지 않아 결합도가 낮고, 이는 높은 확장성과 분산처리라는 이름에 어울린다.
  • 마찬가지의 이유로 병목 현상이나 위에서 본 SPOF에서 자유로워 가용성이 높다.
  • 분산된 서비스의 책임이 명확하기 때문에 전체 구조를 파악하기가 쉽다.
• 단점
  
  
  • 모든 노드가 연결되어 있어야 하기 때문에 네트워크 비용과 복잡도가 높다.
  • 수많은 상황을 일일히 고려해야 하기 때문에 설계와 구현이 복잡하고 어렵다.
  • 새로운 서비스를 추가하는 경우 연동에 비용이 많이 든다.

 

Orchestration-Based Saga Pattern

 

쿠버네티스에서 많이 들어본 오케스트레이션 방식은, 이름 그대로 하나의 중앙 서비스(오케스트레이터)가

 

트랜잭션의 각 단계를 결정하고 관리하는 방식이다.

 

이 과정에서 각 서비스는 자신에게 주어진 요청만 처리 후 응답하며, 오케스트레이터는 다시 이 결과를 바탕으로

 

다음 단계를 결정하고 트랜잭션을 처리한다.

 

역시 장단점을 알아보면 아래와 같다.

 

• 장점
  
  
  • 중앙 집중식 코디네이터가 패턴을 관리하기 때문에 서비스 간 상호작용 구현이 간단하며 파악이 쉽다.
  • 마찬가지 이유로 소프트웨어의 일관성을 유지하기가 쉽고 서비스는 자신의 작업에만 집중해 구현이 쉽다.
  • 새로운 서비스를 추가할 때 오케스트레이터와의 연결만으로 충분해 구현이 쉽다.
• 단점
  
  
  • 오케스트레이터 자체에서 병목현상이나 SPOF가 발생할 가능성이 있다.
  • 오케스트레이터에서 오류가 발생하면 전체 패턴이 정지한다.
  • 각 마이크로서비스의 상태를 추적하기 위해 별도의 데이터베이스가 필요할 수 있다.

 

Optimistic Concurrency Control (OCC)

 

OCC는 이름대로 다소 낙관적으로 동시성을 제어하는 방법을 가리킨다.

 

여기서 '낙관적'의 의미는, 어떤 트랜잭션은 서로에게 영향을 끼치지 않고도 처리될 수 있다고 가정한다는 뜻이다.

 

실제로 이 방법을 사용하면 트랜잭션들이 락을 획득하지 않은 채 데이터베이스에 접근하는데,

 

커밋이 완수되기 전에 각 트랜잭션이 서로에게 영향을 끼치지 않았음을 확인하게 된다.

 

이는 구체적으로는 아래와 같은 과정을 거친다.

 

1. 데이터베이스의 각 로우(Row)에는 버전 정보가 할당된다.
2. 트랜잭션 시작 시 DB는 해당 트랜잭션에게 버전 정보를 할당한다.
3. 트랜잭션이 버전 정보와 데이터를 가져와 수정하고 커밋 시도를 한다.
4. 트랜잭션의 버전 정보와 디비의 버전 정보가 일치하는 경우에만 데이터를 수정하고, 나머지는 충돌로 간주해 롤백한다.
5. 성공적으로 커밋이 수행되면 데이터의 버전 정보를 업데이트해 다음 트랜잭션과의 충돌을 대비한다.

위와 같은 방식으로 동시성과 일관성을 함께 보장하는 방식이며,

 

추측할 수 있겠지만 적은 충돌이 예상되는 시스템, 혹은 데이터 수정이 많지 않은 시스템에서 좋은 효율을 보인다.

 

 

Multi-Version Concurrency Control (MVCC)

 

MVCC 역시 분산 트랜잭션에서 동시성을 제어하는 기술이다.

 

OCC와 비슷하게 디비로 여러 트랜잭션의 동시 액세스를 허용하는데,

 

버전 정보를 할당하는 OCC와는 다르게 MVCC는 이름대로 여러 버전의 데이터를 동시에 유지한다.

 

즉 여러 메타데이터를 가진 자신만의 디비 스냅샷을 트랜잭션이 가져와서 작업을 수행하게 되며,

 

이 과정에서 다른 트랜잭션의 영향은 배제된다.

 

다만 커밋 과정에서 다른 트랜잭션이 동일한 데이터를 수정했다면 충돌이 발생하며,

 

처음 커밋된 트랜잭션을 제외한 나머지는 롤백되는 것은 동일하다.

 

OCC에 비해 충돌이 적게 일어난다는 장점이 있으나, 여러 버전의 디비를 유지해야 하는 만큼 

 

디비의 용량이 크고 일단 충돌이 발생하면 롤백 비용이 크다는 단점이 있다.

 

Distributed Lock Manager (DLM)

 

DLM은 이름대로 분산 환경에서 락을 관리하는 일종의 서비스를 가리킨다.

 

여러 클라이언트에서 동시에 접근하는 데이터에 대해 일관성을 유지하기 위해 락을 사용하는데,

 

클라이언트가 획득하고 해제하는 락의 상태와 그 클라이언트들을 추적해 데이터베이스의 일관성을 유지한다.

 

Saga Pattern과 비슷하게 DLM도 중앙집중식과 분산식으로 나뉘는데,

 

먼저 중앙집중식은 구현과 락 관리가 쉽지만 SPOF의 위험이 있으며, 락 서비스에 따라

 

클라이언트의 처리량 역시 제한된다는 단점이 있다.

 

이어서 분산식은 락 서비스를 분산함으로써 SPOF와 처리량 문제를 해결하지만

 

구현과 락 관리가 어렵고, 관리와 추적에 대한 오버헤드가 발생한다는 단점이 있다.

 

추가로 DLM은 디비에서는 레코드 락(특정 로우(Row)에 대한 락)을, 파일 시스템에서는 파일 락을 사용한다고 한다.