시스템 아키텍트백엔드 아키텍트

마이크로서비스 간의 상호작용 계층을 올바르게 조직하여 트랜잭션 지원의 필요성을 고려하려면 어떻게 해야 하나요?

Hintsage AI 어시스턴트로 면접 통과

답변.

마이크로서비스 간의 상호작용 설계 시 분산 트랜잭션의 구현에 대한 질문이 종종 제기됩니다. 모놀리식에서는 내장된 메커니즘으로 충분하지만, 마이크로서비스에서는 서로 다른 데이터베이스, 기술, 데이터 교환 형식으로 인해 상황이 복잡해집니다. 주요 규칙은 긴 분산 트랜잭션을 피하는 것입니다. 이는 확장성이 떨어지고 성능 저하의 위험을 안고 있습니다.

전통적인 ACID 프로토콜 대신 SAGA 패턴을 사용하는 것이 권장됩니다. 이는 각 마이크로서비스가 자신의 변경 사항을 기록하고 필요 시 자신의 책임 범위 내에서 보상 작업을 발송하는 로컬 트랜잭션의 연쇄입니다.

Node.js와 REST를 사용한 간단한 SAGA 관리 구현 예:

// Express의 SAGA 조정기 app.post('/saga', async (req, res) => { try { await serviceA.transaction(); await serviceB.transaction(); res.send('ok'); } catch (err) { await serviceA.rollback(); res.status(500).send('rollback performed'); } });

주요 특징:

  • SAGA는 서비스 간의 장기적인 잠금을 최소화합니다.
  • 확장성 — 새로운 단계 및 보상 작업을 추가할 수 있습니다.
  • ‘각 서비스는 자체 저장소’ 아키텍처에 적합합니다.

함정 질문들.

전통적인 2단계 커밋(2PC)을 마이크로서비스 간에 트랜잭션 지원을 위해 사용할 수 있나요?

가능하지만 마이크로서비스 아키텍처에는 권장되지 않습니다. 2PC는 확장을 저해하고 서비스 간 기술적 및 조직적 연결을 강하게 만듭니다.

모든 SAGA 시나리오가 금융 거래에 적합한가요?

아니요. SAGA는 ACID의 엄격성이 중요한 시나리오에서 올바르게 구현하기가 더 어렵습니다. 예를 들어, 한 계좌의 잔액 재계산과 같은 경우입니다. 여기서는 위험을 평가하고 타협안을 선택하는 것이 중요합니다.

마이크로서비스가 롤백할 수 없는 경우 중간 단계의 실패 처리 방법은 무엇인가요?

이런 경우 수동 또는 자동 보상 프로토콜을 구현해야 하며, 별도의 이벤트 로그를 활용할 수 있습니다.