AWS에서 'Unstoppable' 서버리스 결제 시스템 구축 (Circuit Breaker 패턴)
Source: Dev.to
결제 게이트웨이가 다운되면 어떻게 될까요? 전통적인 앱에서는 사용자가 스피너를 보고 “500 Server Error”를 보게 되며, 매출을 잃게 됩니다.
저는 절대 크래시되지 않는 시스템을 만들고 싶었습니다. 백엔드 데이터베이스가 불타고 있더라도 사용자의 주문은 받아들여지고, 대기열에 쌓이며, 시스템이 회복되면 자동으로 처리되어야 합니다.
Tech Stack
- Frontend: Python (Streamlit) – 스토어 & 관리자 대시보드.
- Orchestration: AWS Step Functions – 로직을 담당하는 “두뇌”.
- Compute: AWS Lambda (Java 11) – 비즈니스 로직을 담당하는 “워커”.
- State Store: Amazon DynamoDB – 회로 상태(Open/Closed)와 주문 이력을 저장.
- Resiliency: Amazon SQS – 실패한 주문을 위한 “주차장”.
- Observability: Grafana Cloud (Loki) – 로그 집계.
- Infrastructure: Terraform – 완전한 IaC.
Note: Terraform을 사용해 리소스를 관리하세요. 리소스 생성, 삭제, 업데이트 등 모든 작업을 별도 파일로 분리하는 것이 베스트 프랙티스입니다.
Problem: Cascading Failures
마이크로서비스 환경에서 Service A가 Service B를 호출하고 Service B가 멈추면, Service A도 결국 멈춥니다. “Pay” 버튼을 대량 클릭하면 재시도 때문에 데이터베이스에 부하가 걸려 스스로를 DDoS하는 효과가 나타납니다.
Solution: Circuit Breaker – 서지(전압 급증) 시 차단되는 가정용 차단기와 같은 개념으로 시스템을 보호합니다.
High‑Level Architecture
시스템은 세 가지 뚜렷한 상태를 처리합니다:
| Path | Description |
|---|---|
| Green (Closed) | 백엔드가 정상이며 주문이 즉시 처리됩니다. |
| Red (Open) | 백엔드가 오류를 일으키고 회로가 차단되어 트래픽이 백엔드에 도달하지 않습니다. |
| Yellow (Recovery) | 주문이 SQS 대기열로 라우팅되어 나중에 자동으로 재시도됩니다. |
Logic Flow
핵심은 트래픽 컨트롤러 역할을 하는 AWS Step Functions 상태 머신입니다.
-
The Check – 각 “Pay” 클릭 시 워크플로우가 DynamoDB에서 회로 상태를 확인합니다.
- OPEN이면 백엔드를 건너뜁니다.
- CLOSED이면 Java Lambda로 진행합니다.
-
The Execution – Lambda가 결제를 처리합니다.
- Success: 주문 이력을 COMPLETED 로 업데이트하고 EventBridge 이벤트를 발생시켜 SNS를 통해 고객에게 이메일을 보냅니다.
- Failure: 오류를 잡아내고 지수 백오프(1 초, 그 다음 2 초)로 재시도합니다.
-
The “Trip” – 백엔드가 반복적으로 실패하면 상태 머신이:
- DynamoDB에 OPEN 상태를 기록합니다.
- SNS로 “Critical: Circuit Tripped” 알림을 보냅니다.
- 대시보드에서 주문을 FAILED 로 표시합니다.
-
Self‑Healing (Auto‑Retry) – 회로가 OPEN 상태일 때 새로운 주문은 QUEUED 로 표시되고 Amazon SQS로 전송됩니다.
- “Retry Handler” Lambda가 대기열을 감시하며 일정 시간(예: 30 초) 대기 후 주문을 상태 머신에 다시 제출합니다.
- 백엔드가 복구되면 주문이 처리되고, 그렇지 않으면 다시 대기열로 돌아갑니다.
Low‑Level Diagram
Tested Data Scenarios
Success
Chaos Mode
Observability & Monitoring
- **Grafana Cloud (Loki)**를 연동해 CloudWatch 로그를 수집합니다.
- Streamlit Dashboard는 실시간 주문 상태(PENDING → COMPLETED 또는 FAILED)를 보여줍니다.
- Grafana Explore를 이용해
{service="order-processor"}와 같은 쿼리로 특정 스택 트레이스를 손쉽게 찾을 수 있습니다.
Key Learnings & Trade‑offs
| Aspect | Insight |
|---|---|
| Complexity vs. Reliability | 큐와 상태 머신 등 구성 요소가 늘어나 복잡도가 증가하지만, 고가용성을 제공해 프론트엔드에서는 절대 크래시를 보지 못합니다. |
| “Ghost” Data | Catch 블록에서 원본 입력을 오류 메시지로 교체합니다. ResultPath를 사용하면 원본 주문 ID를 보존해 실패 후에도 데이터베이스 업데이트가 가능합니다. |
| Cost Optimization | 표준 Step Functions 워크플로우는 규모가 커지면 비용이 많이 들 수 있습니다. Express Workflows와 ARM64 (Graviton) Lambda를 사용하면 비용을 약 40 % 절감할 수 있습니다. |
Application Screenshots
Order‑placing UI
Admin UI
Conclusion
이 프로젝트는 이벤트‑드리븐 아키텍처와 Circuit Breaker 패턴을 결합해 시스템이 점진적으로 감소하도록 설계할 수 있음을 보여줍니다. 장애 발생 시 매출을 잃는 대신 트래픽이 “일시 정지”되고, 폭풍이 지나면 자동으로 처리됩니다.
Technologies used: AWS, Java, Python, Terraform, Grafana.