일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- kafka streams
- Elk
- confluent
- scala 2.10
- spring-batch
- reactive
- 한빛미디어
- coursera
- Elasticsearch
- enablekafkastreams
- statestore
- Kafka
- Logstash
- gradle
- aws
- schema registry
- 카프카
- 플레이 프레임워크
- RabbitMQ
- kafka interactive query
- springboot
- scala
- spring-kafka
- Spring
- spring-cloud-stream
- avo
- play framework
- kafkastream
- kafkastreams
- Slick
- Today
- Total
b
결제가 장애가 나면 어떻게 되는가? 본문
https://deview.kr/2019/schedule/305 에서 소개한 11번가의 주문/결제 시스템에 관련된 이야기이다. 실제로 '결제'단계에서 장애가 났을때 11번가의 주문/결제는 어떻게 진행이 되었을까?
아래의 예는 지난 11월 11일 오후 1시경의 11번가 스토리이다.
단순화해서 "주문 -> 결제 처리 -> 11번가 데이터베이스에 저장" 흐름대로 주문/결제가 처리된다고 생각하자.
13:00 정각 기프티콘을 절반 가격에 한정 판매 하면서 주문은 미친듯이 들어온다.
12시 59분에 비해 약 4배의 속도로 주문/결제가 들어왔다.
당연히 주문 처리량 보다 높아졌다. 13:01분 부터 주문유입량 >> 주문처리량이 되었다. 원래대로라면 다른 주문들은 다 Rejection 하거나, 고객에게 1분 이상의 대기화면을 보여줬어야만 했다.
하지만 11번가는 결제 성능이 넘어서더라도 주문를 받는다 그리고 kafka 에 우선 저장한다,
결제가 되던 안되던 느리던 빠르던 우선 주문은 가능하다. (물론 다른 경우로 주문을 못 받는 경우는 존재한다 ㅠ)
위의 그래프처럼 주문유입량 >> 주문처리량이 되면, Kafka 에서 주문 데이터를 더이상 fetch 하지 않는다. 정확히는 처음에는 fetch 많이 했지만 이후에는 fetch 한 주문 데이터를 다 처리하느라 일정 시간 주문 데이터를 가져오지 않았고, 그것을 다 처리한 이후에 다시 데이터를 fetch 하였다
이제부터 문제다.
결제까지 성공하면, 그 후에 오라클 데이터베이스에 '결제 성공' 이라는 데이터를 update 쳐야한다. 하지만, '결제 제 이후 Process' 영역에서 문제가 발생햇다. 정확한 상황을 설명할 수는 없지만, '결제 후 성공 결과를 오라클 데이터베이스에 저장하고 결제 프로세스를 완료하는데 5초 이상씩 걸렸다' 정도로 표현 하면 될듯하다. (원래는 눈깜짝할새에 처리되어야 한다) 그래서 실제 결제는 1-2분 정도의 지연이 있었지만, 데이터베이스 반영에는 10분이 넘게 걸렸다.
쉽게 예를 들면, 13:00:01에 주문을 한 고객의 결제는 13:01:00에 결제가 성공되었고, 실제 데이터베이스에는 13:10:00에 반영이 되었다 정도로 이해하면 된다.
좌측 그래프는 결제 결과는 오라클에 반영하는 처리속도를 나타낸다.
원래는 처리속도가 항상 바닥에 깔려 있어야 했지만, 데이터베이스에 저장하는 과정에서 장애 수준으로 응답 시간이 느려졌고, 결제 결과를 오라클에 저장하는데 5 ~ 10초가 걸렸다. 하지만, 제일 위에서 보여준 것처럼 주문& 결제는 문제 없이 계속 진행되었다 (문제는 오라클에 저장되는 부분)
데이터베이스에 반영되는 속도가 느려졌지만, '결제 정보'는 Kafka에 안전하게 저장이 되어 있었다. 데이터베이스가 느리면, 데이터베이스에 저정하지 않거나, 좀 더 조금씩 저장하면 된다. 좌측은 데이터베이스에 저장하는 Kafka Conser의 fetch metric 이다.
일반적인 마이크로서비스 아키텍쳐나, 모노리틱이었다면 전체 장애, 그리고 단 한명의 고객도 주문을 하지 못했을 것이다. 하지만, 11번가는 안정적으로 주문을 하고, 결제를 처리할 수 있었다.