오류 복구: 대규모 환경에서의 우아한 성능 저하

SchemaBridge Team · 2026-01-16 · Resilience, Error Handling, Fault Tolerance

대규모 환경에서 재시도와 백오프를 처리하는 방법. 관리형 복원력이 "재시도 폭풍(Retry Storm)"을 방지하는 원리.

"재시도 폭풍(Retry Storm)": 순진한 오류 처리가 실패하는 이유

분산 시스템 초창기에는 "오류 처리"란 대개 코드를 try/catch로 감싸고, 어쩌면 세 번 재시도하는 간단한 while 루프를 추가하는 것을 의미했습니다. 이는 실패가 드물고 국지적인 작고 고립된 환경에서는 효과가 있습니다. 하지만 상호 연결된 마이크로서비스 메시 안에서 대규모로 운영될 경우, 순진한 재시도는 재시도 폭풍(Retry Storm)(또는 "천둥 무리, Thundering Herd")이라 불리는 시스템적 붕괴로 이어지는 지름길입니다.

블랙 프라이데이 세일 동안 과도한 부하로 인해 주 데이터베이스가 다소 느려지는 시나리오를 상상해 보세요. 쿼리 지연 시간이 10ms에서 1100ms로 증가합니다. API에는 표준 1초 타임아웃이 설정되어 있습니다. 갑자기 천 개의 동시 워커가 일제히 이 타임아웃에 도달합니다. 이들 모두 오류를 캐치하고, 여러분의 단순한 루프 로직에 따라 즉시 쿼리를 재시도합니다.

이제 이미 최초의 1,000개 요청을 처리하느라 버거워하던 여러분의 데이터베이스는 한꺼번에 추가로 1,000개의 요청을 받게 됩니다. 부하가 즉시 두 배로 뜁니다. 데이터베이스 CPU는 100%까지 치솟고, 지연 시간은 5초로 늘어납니다. 워커들은 다시 실패하고, 다시 재시도합니다. 시스템은 실패의 양의 피드백 루프(Positive Feedback Loop)에 빠져듭니다. 여러분은 사실상 스스로의 인프라에 DDoS 공격을 가한 셈입니다. 사소한 성능 저하를 전체 시스템 장애로 바꿔버린 것입니다.

실패를 받아들이기: 오류는 API의 일부다

SchemaBridge에서 우리는 오류가 "예외적"이라는 관념에서 벗어납니다. 이벤트 기반 세계에서 실패는 성공만큼이나 흔한 일입니다. 네트워크는 분할되고, 파드는 불규칙하게 동작하며, 타사 API에는 유지보수 시간대가 있습니다. 우리는 오류 복구를 코드 안의 catch 블록이 아니라 인프라 안의 관리형 생애주기(Managed Lifecycle)로 취급합니다.

오류 분류 매트릭스

효과적으로 복구하려면 먼저 무언가가 왜 실패했는지 이해해야 합니다. 모든 오류가 동등하게 만들어진 것은 아닙니다. SchemaBridge는 오류를 세 가지 뚜렷한 범주로 분류하며, 각 범주는 고유한 복구 전략을 가집니다.

| :--- | :--- | :--- | :--- |

게이트웨이 수준에서 오류를 분류함으로써, 우리는 엔진이 (결코 성공할 리 없는) "잘못된 비밀번호" 오류를 맹목적으로 재시도하는 일을 방지하면서, (100ms 안에 성공할 가능성이 높은) "네트워크 일시 장애"는 적극적으로 처리합니다.

영속적 재시도의 해부: 백오프의 수학

버텍스가 일시적 오류로 실패하면, SchemaBridge는 엔진 수준에서 강제되는 정교한 백오프(Backoff) 전략을 사용합니다.

지수 백오프: 시스템 식히기

1초마다 재시도하는 대신, 우리는 대기 시간을 지수적으로 늘립니다.

$$Wait = Base \times 2^{Attempt}$$

시도 1회차: 1초 대기
시도 2회차: 2초 대기
시도 3회차: 4초 대기
시도 4회차: 8초 대기

이 단순한 수학적 증가는 실패한 서비스에 가해지는 부하가 시간이 지남에 따라 빠르게 감소하도록 보장합니다. 서비스가 1분간 다운되더라도, 수백 개의 요청으로 두들겨 맞는 대신 아주 소량의 요청만 받게 됩니다.

점진적 롤백: 배포에서의 안전성

때로는 재시도가 무의미합니다. 배포가 버그를 유입시켰다면, 아무리 재시도해도 고쳐지지 않습니다. 롤백(Roll Back)이 필요합니다.

SchemaBridge는 자동 롤백을 동반한 점진적 트래픽 전환(Gradual Dial-Up with Auto-Rollback)을 지원합니다. 새로운 워크플로를 배포하거나 인프라 구성을 변경할 때, 우리의 gradual_deploy 시스템은 새 인스턴스의 상태를 모니터링합니다.

1단계: 트래픽의 1%는 새 버전으로, 99%는 기존 버전으로 라우팅됩니다.
헬스 체크: 새 버전의 오류율이 임계값을 초과하면, 시스템은 자동으로 롤백을 트리거하여 트래픽의 100%를 안정적인 버전으로 되돌립니다.

이는 잘못된 코드(또는 잘못된 구성)가 절대로 전체 플릿을 다운시킬 수 없도록 보장합니다.

사람이 개입하는 복구: "수동 게이트(Manual Gate)" 전략

일부 실패는 루프가 아니라 두뇌를 필요로 합니다. 수동 은행 대사(reconciliation)에서 송장 금액이 $0.01 차이로 맞지 않아 워크플로가 실패했다면, 어떤 코드도 무엇을 해야 할지 결정할 수 없고 결정해서도 안 됩니다.

SchemaBridge 워크플로는 중단 상태(Halted State)로 진입할 수 있습니다.

가시성: 워크플로는 운영 대시보드에서 빨간색으로 표시됩니다.
포렌식: 운영자는 정확한 변수 값과 오류 메시지(예: "불일치: 100.00 대 100.01")를 확인할 수 있습니다.
개입: 운영자는 상태를 수동으로 편집(예: 승인 금액 갱신)한 뒤 "이 버텍스에서 재개"를 클릭할 수 있습니다.

엔진은 수정된 상태를 재구성하여 여정을 계속 진행합니다. 이는 "오류"를 공황과 데이터베이스 해킹의 원천에서 표준적인 운영 워크플로로 바꿔놓습니다.

사례 연구: 6시간의 결제 게이트웨이 장애를 견뎌내다

우리는 매일 자정마다 1,000만 달러 규모의 갱신을 처리하는 구독형 SaaS 기업과 협업했습니다. 어느 날 밤, 그들의 주 결제 게이트웨이가 US-East 리전에서 6시간에 달하는 대규모 장애를 겪었습니다.

기존 방식 (SchemaBridge 도입 전)

그들의 레거시 시스템은 단순한 cron 작업을 사용했습니다. 게이트웨이가 다운되자, cron 작업은 세 번 재시도한 뒤 구독을 "실패 / 결제 거절"로 표시했습니다. 엔지니어들이 오전 6시에 일어났을 때는, 시스템이 결제를 처리할 수 없다고 잘못 판단하여 이미 5만 개의 고객 계정이 비활성화된 뒤였습니다. 지원 문의 큐는 아수라장이 되었고, 사용자들이 "계정 취소" 이메일을 받으면서 이탈률이 급증했습니다.

SchemaBridge 방식

그들은 최근 청구 엔진을 SchemaBridge로 마이그레이션한 상태였습니다.

1. 자동 백오프: 게이트웨이로부터 503 응답이 도착하기 시작하자, 엔진은 자동으로 지수 백오프로 전환했습니다.

2. 우아한 복구: 6시간 뒤 게이트웨이가 다시 온라인 상태가 되자, 엔진은 이후 한 시간에 걸쳐 밀려있던 5만 건의 워크플로를 자연스럽게 "소진(drain)"시켰습니다.

결과

단 한 명의 고객도 잘못 비활성화되지 않았습니다. 이메일도 전혀 발송되지 않았습니다. 고객 지원팀은 다음 날 아침 리포트를 보기 전까지 장애가 있었다는 사실조차 몰랐습니다. 이것이 바로 복원력의 비즈니스 가치입니다.

장애 허용 설계를 위한 전문가 체크리스트

진정으로 "파괴 불가능한" 시스템을 구축하려면 다음 원칙을 따르세요.

1. 모든 쓰기에 대한 보상 트랜잭션을 정의하세요: 레코드를 생성한다면, 실패 시 이를 삭제하거나 보관 처리할 계획을 세우세요. 대칭성이 일관성의 핵심입니다.

2. 모든 재시도에 지터를 사용하세요: 재시도가 복구를 죽이는 천둥 무리 현상을 방지하세요. 무작위성이 여러분의 친구입니다.

3. 중단 상태를 받아들이세요: 로직이 벽에 부딪혔을 때 사람의 도움을 요청하는 것을 두려워하지 마세요. "일시 정지된" 워크플로가 "고장 난" 워크플로보다 낫습니다.

4. 오류 경로를 감사하세요: 우리는 흔히 "정상 경로(Happy Path)"만 테스트하고 "실패 경로(Failure Path)"는 무시합니다. SchemaBridge의 "카오스 인젝터(Chaos Injector)"를 사용해 스테이징 환경에서 사가(saga)를 시각적으로 검증하세요.

결론: 실패는 복원력을 위한 기회다

오류 복구는 버그를 막는 것이 아니라 재난을 막는 것에 관한 것입니다. 오류 처리를 일련의 취약한 코드 블록에서 관리형의 영속적인 생애주기로 전환함으로써, 여러분은 "재시도 폭풍"에 대한 두려움 없이 복잡한 통합을 구축할 자유를 얻습니다. "취약함(Fragile)"에서 "반취약함(Anti-Fragile)"으로 나아가는 것입니다.

11부에서는 "워크플로로서의 인프라(Infrastructure as Workflow)"의 세계를 탐구하며, 시각적 로직을 사용해 클라우드 리소스를 관리하는 방법을 알아보겠습니다.