1. 비동기 처리에 대한 고민
이번 주 비동기 처리에 대해 고민하게 된 이유는 MSA 환경에서의 결제 처리 방법을 고려하면서 시작되었습니다. MSA 구조에서는 여러 서비스가 분리되어 운영되며, 각 서비스 간 통신을 어떻게 처리할지에 대한 선택이 중요합니다. 특히, 결제와 같은 중요한 비즈니스 로직에서는 비동기 방식(WebFlux, Kafka)을 사용할지, 아니면 동기 방식으로 처리할지에 대한 고민이 필요했습니다.
1-1. MSA에서의 결제 처리
MSA 구조에서는 결제 요청이 여러 서비스(예: 사용자 서비스, 티켓 서비스, 결제 서비스)로 분리되어 처리됩니다.
이때, 각 서비스 간의 데이터 일관성과 안정성을 유지하면서, 효율적으로 결제를 처리하는 것이 중요한 과제였습니다.
결제 요청을 비동기적으로 처리할 수 있는 방법들을 찾다가, WebFlux와 Kafka를 고려하게 되었습니다.
1-2. 동기 vs 비동기
결제 시스템에서는 빠른 응답 시간과 데이터 일관성, 안정성이 중요합니다. 이를 위해 동기 방식과 비동기 방식을 각각 분석하였습니다.
동기 처리는 모든 작업을 하나의 트랜잭션으로 묶어 처리하여 데이터 일관성을 보장할 수 있지만, 외부 API 통신과 결제 시스템의 트래픽을 처리할 때 성능 상의 이슈가 발생할 수 있습니다.
비동기 처리는 성능을 최적화할 수 있지만, 트랜잭션 경계를 설정하고 데이터 일관성을 유지하는 것이 어려워질 수 있습니다.
2. 비동기 처리 방식의 비교: WebFlux vs Kafka
2-1. WebFlux를 통한 비동기 처리
WebFlux 장점:
- 고성능 논블로킹 I/O: 서버 자원을 효율적으로 사용하여 많은 요청을 동시에 처리할 수 있습니다.
- 빠른 응답: WebFlux는 서버와 클라이언트 간의 데이터를 비동기적으로 처리하므로, 외부 결제 API와 통신하면서도 서버의 응답이 빠릅니다.
- 간단한 구현: 별도의 메시지 브로커 없이 비동기 처리를 할 수 있기 때문에 설정과 유지 보수가 간편합니다.
WebFlux 단점:
- 복잡한 에러 처리: 비동기 흐름을 제어하고, 에러 처리 로직을 추가하는 것이 복잡할 수 있습니다.
- 장애 복구 어려움: 서버 장애 시 메시지 브로커가 없기 때문에, 데이터 복구와 재시도 처리가 까다롭습니다.
2-2. Kafka를 통한 비동기 처리
Kafka 장점:
- 확장성: Kafka는 여러 컨슈머 그룹과 함께 대량의 데이터를 병렬로 처리할 수 있어, 트래픽이 증가하더라도 안정적으로 처리 가능합니다.
- 장애 복구: Kafka는 메시지 큐 기반으로 메시지를 보관하므로, 장애 발생 시 데이터 손실 없이 복구할 수 있습니다. 이는 결제와 같은 중요한 시스템에서 매우 유리합니다.
- 내구성: 메시지를 디스크에 저장하여, 결제 기록이 손실되지 않도록 보장합니다.
Kafka 단점:
- 복잡한 설정: Kafka는 설정과 운영이 복잡하며, 브로커와 컨슈머를 관리해야 합니다.
- 추가적인 지연: 메시지 큐를 사용하는 방식이기 때문에 실시간으로 데이터를 처리하기보다는, 약간의 지연이 발생할 수 있습니다.
3. 비동기 vs 동기 방식에 대한 최종 결론: 동기 처리 선택
결제 시스템의 요구사항을 분석한 결과, 동기 처리 방식이 적합하다고 결정하게 되었습니다.
- 데이터 일관성 보장: 결제 프로세스에서 데이터가 손실되거나 불일치하면 안 되기 때문에, 모든 작업을 하나의 트랜잭션으로 묶어 처리할 수 있는 동기 방식이 더 안정적입니다.
- 장애 복구의 용이성: 비동기 방식에서는 장애 발생 시 재시도나 복구가 복잡하지만, 동기 방식에서는 예외 처리를 통해 쉽게 처리할 수 있습니다.
- 응답 시간: 결제 시스템에서는 실시간으로 응답해야 하는 상황이 많기 때문에, 비동기 처리 방식에서 발생하는 지연 시간이 문제가 될 수 있습니다.
따라서 동기 방식을 선택하여 결제 트랜잭션을 처리하며, 외부 결제 API 호출은 트랜잭션 내에서 이루어지도록 구현하게 되었습니다. 비록 성능 상의 이슈가 있을 수 있지만, 결제 시스템의 특성상 데이터 일관성과 안정성을 최우선으로 고려해야 했기 때문에 이러한 결정을 내리게 되었습니다.
