Observability와 Failure Recovery in Distributed Financial Systems: 올바른 시스템도 깨지는 경우

Source: Dev.to

위의 링크에 포함된 글 전체를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

초록

금융 시스템은 종종 정확성 보장이라는 관점에서 설명됩니다. 엔지니어들은 트랜잭션 불변식, 임계값 암호화, 그리고 결정론적 상태 머신에 대해 논의합니다. 이러한 특성들은 필수적이지만, 프로덕션 환경에서 금융 인프라를 운영하기에 충분하지는 않습니다. 분산 환경의 현실은 시스템 충돌, 메시지 지연, 상태에 대한 일관되지 않은 관찰, 그리고 운영상의 불확실성을 초래합니다.

본 기사에서는 분산 금융 시스템에서 관측성(observability) 과 복구(recovery)를 살펴봅니다. 정확성 보장만으로는 시스템을 운영할 수 없는 이유, 분산 장애가 금융 인프라 전반에 어떻게 전파되는지, 그리고 관측성을 사후적인 모니터링이 아니라 일급(First‑class) 아키텍처 원시(primitives) 로 다루어야 하는 이유를 탐구합니다.

금융 시스템은 모든 것이 정상적으로 작동할 때의 행동으로 평가되지 않습니다. 불가피하게 무언가가 실패했을 때 어떻게 동작하는지가 평가 기준이 됩니다.

운영 금융 시스템의 불편한 현실

실제 운영 환경에서 처음으로 금융 시스템을 운영하면 즉시 명확해지는 점이 있습니다:

정확성은 운용 가능성과 동일하지 않다.

• 가치 보존을 강제하는 원장을 설계할 수 있습니다.
• 임계값 암호화를 이용한 보관 인프라를 구축할 수 있습니다.
• 강력한 트랜잭션 보장을 적용할 수 있습니다.

그럼에도 첫 번째 프로덕션 사고는 다른 질문을 던집니다.

“시스템이 정확한가?”가 아니라
“실제로 무슨 일이 일어났는가?”

분산 시스템에서는 그 질문에 대한 답이 드물게 명확합니다.

• 트랜잭션이 원장에 커밋되었지만 하위 서비스에서는 관찰되지 않을 수 있습니다.
• 보관 서명 라운드가 부분적으로 실행된 뒤 노드 충돌로 중단될 수 있습니다.
• 정산 어댑터가 작업을 재시도하는 동안 다른 구성 요소는 트랜잭션이 이미 완료되었다고 믿을 수 있습니다.

시스템 자체는 여전히 정확할 수 있지만, 운영자는 더 이상 시스템 상태를 파악하지 못합니다. 바로 그 순간이 관측 가능성이 아키텍처가 되는 시점입니다.

Distributed systems hide failure in time

In centralized systems, failures are usually visible immediately: a process crashes, a request fails, and the error is returned to the caller.

Distributed systems behave differently. Failures can be delayed, reordered, or partially observed.

• A transaction may be accepted by one subsystem while another subsystem has not yet observed the event.
• A message may be delivered twice due to a network retry.
• A service may process an event after a significant delay because a queue was temporarily unavailable.

The result is temporal uncertainty. Different components may hold different views of reality at the same moment. Financial infrastructure cannot tolerate this ambiguity without strong mechanisms for tracing and reconstruction. Without observability, engineers are left debugging a system whose behavior cannot be reconstructed.

모니터링과 관측성의 차이

금융 인프라에서는 모니터링만으로는 충분하지 않습니다. 서비스가 실행 중이거나 지연 시간이 기대 범위 내에 있다는 것을 아는 것만으로는 부족합니다. 엔지니어는 여러 서비스에 걸친 금융 거래의 전체 라이프사이클을 재구성할 수 있어야 합니다.

출금 요청을 고려해 보세요. 라이프사이클에는 다음이 포함될 수 있습니다:

1. 원장 검증
2. 위험 평가
3. 규정 준수 검사
4. 보관 서명
5. 정산 전파

어떤 단계에서든 실패가 발생하면, 엔지니어는 실패가 어디서 발생했는지와 시스템이 거래 상태에 대해 무엇을 믿고 있는지를 파악해야 합니다. 이는 로그만으로는 부족하고, 아키텍처 수준의 계측이 필요합니다.

시스템 불변량으로서의 이벤트 추적성

프로덕션 금융 시스템에서는 모든 트랜잭션이 추적 가능한 이벤트 체인을 생성해야 합니다. 각 전환은 서비스 경계를 넘어 전파되는 안정적인 식별자와 연결되어야 합니다.

TransactionID = global identifier for the financial operation
TraceID       = request lifecycle across services
EventID       = unique identifier for a state transition

각 서브시스템은 이러한 식별자와 연결된 이벤트를 발생시킵니다.

• Ledger는 다음과 같은 이벤트를 발생시킬 수 있습니다

  • TransactionValidated
  • TransactionCommitted

• Custody는 다음과 같은 이벤트를 발생시킬 수 있습니다

  • SigningRoundStarted
  • SignatureProduced

• Settlement infrastructure는 다음과 같은 이벤트를 발생시킬 수 있습니다

  • BroadcastInitiated
  • BroadcastConfirmed

이러한 이벤트들은 시스템 동작의 추적 가능한 타임라인을 형성합니다. 이 타임라인이 없으면 사고 분석이 추측에 의존하게 됩니다.

실패 후 시스템 상태 재구성

분산 금융 시스템에서의 실패는 거의 깨끗하게 일어나지 않습니다.

• 보관 서명 프로세스가 중간에 실패할 수 있습니다.
• 정산 방송이 블록체인에 성공적으로 전파되었지만 내부 서비스가 결과를 영구 저장하기 전에 충돌할 수 있습니다.

복구를 위해서는 영구 기록으로부터 시스템 상태를 재구성할 수 있어야 합니다. 시스템은 다음과 같은 질문에 답할 수 있을 만큼 충분한 정보를 보존해야 합니다:

• 트랜잭션이 보관 서명 단계에 도달했는가?
• 서명이 생성되었지만 기록되지 않았는가?
• 트랜잭션이 네트워크에 방송되었는가?

아키텍처는 결정론적 재구성을 지원해야 합니다. 실제로 이는 상태 전환을 단순히 가변 데이터베이스 행을 업데이트하는 대신 이벤트로 기록한다는 의미가 많습니다. 시스템이 가변 상태에만 의존한다면 과거를 재구성하는 것이 매우 어려워집니다.

멱등성 및 안전한 재시도

한 번 실패가 발생하면 시스템은 작업을 안전하게 재시도해야 합니다. 분산 시스템에서는 재시도가 불가피합니다: 네트워크가 메시지를 손실하고, 서비스가 재시작되며, 타임아웃이 반복 시도를 트리거합니다.

금융 인프라스트럭처는 재시도가 중복된 효과를 만들 수 없도록 보장해야 합니다.

• 예시: 정산 어댑터가 트랜잭션 전송을 재시도할 수 있습니다.
• 시스템은 재시도 작업이 중복된 원장 변형을 발생시키지 않도록 해야 합니다.

이는 금융 워크플로우에서 부수 효과를 수행하는 모든 구성 요소에 대한 전형적인 요구 사항입니다.

멱등성 보장

Operation(TransactionID) applied multiple times
must produce the same final state as applying it once

멱등성이 없으면 복구 절차 자체가 시스템 상태를 손상시킬 수 있습니다.

운영 안전으로서의 가시성

가시성은 엔지니어가 사고를 디버깅하는 데만 도움이 되는 것이 아니라, 운영 실수를 적극적으로 방지합니다.

운영자가 실패한 트랜잭션을 수동으로 재실행하려는 상황을 생각해 보십시오. 완전한 추적 가능성이 없으면, 운영자는 해당 트랜잭션이 이미 하위 구성 요소에서 성공했음을 인지하지 못할 수 있습니다. 이는 가장 위험한 생산 오류 유형 중 하나입니다.

시스템은 인간 개입이 추가적인 불일치를 초래하지 않도록 충분한 가시성을 제공해야 합니다. 고신뢰 금융 인프라에서는 가시성이 운영 오류에 대한 방지턱 역할을 합니다.

관측성 부족의 비용

많은 분산 시스템이 알고리즘이 잘못되어 실패하는 것이 아니라, 엔지니어가 실패를 충분히 빠르게 진단하지 못하기 때문에 실패합니다. 관측성이 약하면:

• 사고 해결에 더 오랜 시간이 걸림
• 복구 절차가 수동으로 전환됨
• 조정 작업이 필요해짐
• 시스템에 대한 신뢰도가 저하됨

금융 인프라에서는 이러한 신뢰도 저하가 실제적인 결과를 초래합니다. 복구 지연은 고객 자금, 결제 시점, 규제 준수 등에 영향을 미칠 수 있습니다.

따라서 관측성은 단순히 개발자의 편의성이 아니라, 시스템 신뢰성 계약의 일부입니다.

금융 시스템은 스스로를 설명해야 합니다

잘 설계된 금융 시스템은 언제든지 다음 질문에 답할 수 있어야 합니다:

“이 거래에 무슨 일이 있었나요?”

시스템이 그 질문에 정확히 답하지 못한다면, 아키텍처가 불완전한 것입니다.

• 원장 정확성은 금융 무결성을 보호합니다.
• 보관 아키텍처는 서명 권한을 보호합니다.
• 핵심 아키텍처는 시스템 구성을 보호합니다.
• 관측 가능성은 운영 이해를 보호합니다.

관측 가능성이 없으면, 엔지니어는 눈이 먼 상태로 작업하게 됩니다.

결론

금융 인프라를 구축하려면 올바른 알고리즘을 설계하는 것 이상이 필요합니다. 장애가 발생해도 이해할 수 있는 시스템을 구축해야 합니다.

분산 금융 시스템은 구성 요소가 충돌하고, 네트워크가 메시지를 지연시키며, 서비스가 서로 다른 시점에 상태 전이를 관찰한다는 가정을 해야 합니다. 관측성(observability)은 이러한 불확실한 환경에서 진실을 재구성하는 메커니즘을 제공합니다.

자신의 동작을 설명할 수 없는 시스템은 안전하게 운영될 수 없습니다. 금융 인프라에서 관측성은 디버깅 도구가 아니라 아키텍처의 일부입니다.