작성
·
73
0
recovery() 를 스케줄로 구현한 부분에 있어서 궁금증이 있습니다.
설명에도 언급 되었듯이 k8s 환경과 같이 scale-out 형태로 서비스를 제공하면 동시성 이슈가 발생될 것으로 예상되는데요.
단순하게 하나의 unknown order 만 생성해서 테스트로 갈음하기에는 검증이 부족하다고 느껴지는데, 동시성 검증은 어떻게 진행하셨을까요?
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 고정훈님.
스케줄을 통해 recovery()
를 구현하는 부분에서 동시성 문제에 대해 질문해주셨군요. Kubernetes와 같은 환경에서는 여러 인스턴스가 동시에 작동할 가능성이 있어 동시성 문제가 나타날 수 있는 것은 올바른 우려입니다.
회복 로직의 동시성 문제를 해결하기 위해 다음과 같은 방법들을 적용해볼 수 있습니다:
분산 락 사용: Redis의 분산 락이나 데이터베이스 락을 활용하여 동시에 여러 인스턴스에서 동일한 데이터를 회복시키지 않도록 제어할 수 있습니다. 이를 통해 하나의 인스턴스만이 특정 시점에 회복 로직을 수행하도록 보장할 수 있습니다.
순차 처리: 메시지 큐를 이용하여 회복할 주문이나 작업을 하나의 큐로 관리하고 순차적으로 처리하면 동시성 이슈를 피할 수 있습니다.
테스트 시나리오 확장: 실제 시스템 환경과 유사하게 여러 인스턴스를 배포하여 동시에 여러 unknown order를 생성하고, 시스템이 이를 올바르게 처리하는지를 확인합니다. 실제 트래픽을 모방한 무작위의 동시에 발생하는 요청 시나리오를 시뮬레이션하는 것이 중요합니다.
자동 테스트 도구 사용: Gatling, JMeter 등을 이용하여 랜덤하고 동시적인 요청을 보내며 시스템의 견고성을 검증할 수 있습니다. 이러한 도구들은 여러 사용자가 동시에 접근하는 환경을 모방하는 데 유용합니다.
아래의 유사한 질문 링크에서 관련 정보와 해결 방법을 확인하실 수 있습니다:
- Ledger 및 Wallet 서비스에서 Kafka Consumer 문제 해결
- webflux 사용 이유와 관련한 논의 - Webflux 및 비동기 처리가 필요한 이유에 대한 설명 도움이 될 것입니다.
이해를 돕기 위해 기본적인 동시성 제어 개념을 함께 제공해드리는 점 참고 부탁드리며, 추가적으로 궁금한 점이 있으면 언제든지 질문해 주세요.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.