인프런 커뮤니티 질문&답변

안녕하세요 김승수님 질문 주셔서 감사합니다.

우선 기본 전제를 정리하자면,

1. CDC 도입 X -> 그로인해서 폴링을 통해 데이터를 인지

이런 경우 가장 먼저 고려해야 하는 부분이 말씀하신 것처럼 인스턴스가 늘어났을 때 동일한 Outbox 데이터를 여러 폴링 프로세스가 동시에 처리할 수 있다는 점입니다. 이로 인해 중복 메시지 발행, 경합(lock contention), 데이터 순서 꼬임 등이 발생할 수 있는거는 당연한 문제죠

1. 폴링 전용 애플리케이션(or 워커 역할) 분리

말하신 구조처럼 폴링 전용 서버를 두는 방식입니다.

이 서버는 주기적으로 테이블을 스캔하면서, 아직 발행되지 않는 즉 처리해야하는 데이터를 조회 후 실질적으로 처리하지 않고 메시지를 전송합니다. 이 과정에서 redis, kafka등을 MSQ로 사용하면 좋고 중복된 데이터를 조회하는 부분에 있어서는 분산락을 사용하던 논리적인 락을 적용 할 수 있겠죠.

• 좀 더 안전하게 한다면, 처리해야하는 주문 데이터에 대해서 이벤트를 발송 할 떄 멱등성을 보장 할 수 있으면 좋을꺼 같아요.

구조를 좀 더 단계별로 보면 다음과 같을꺼 같아요.

1. 주문이 생성이 된다면, 주문 데이터 + Outbox 이벤트를 같은 트랜잭션으로 DB에 저장

   1. 이떄 Outbox 이벤트의 status는 PENDING으로 두겠죠

2. 그러면 이제 폴링 서버에서 status가 PENDING으로 되어있는 이벤트를 조회

   1. 이떄 중복 데이터를 방지하기 위한 논리적인 락이나, 분산 락등 추가적인 처리가 필요하겠죠

   2. 필요에 따라서 멱등성 보장을 위한 개념이 들어가면 더 좋을꺼 같고요

고민해 주신 부분이 거의 정석에 가까운 형태라고 생각을 합니다. 상황에 따라서 일부 달라질 수 있겠지만 정석에 가까운 고민을 하신거 같아요.

하지만 이런 구조는 기본적으로 인스턴스가 많다는 상황을 가정하셨고 그러면 앞서 말씀드린 다양한 문제들을 방지할 수 있는 개념들을 숙지하고 클라이언트 레벨에서 제어하는게 좋지 않을까 싶습니다.

감사합니다!

안녕하세요, 인프런 AI 인턴입니다. 김승수님.

OutBox 패턴은 데이터베이스 트랜잭션과 메시지 발행의 일관성을 유지하는 데 자주 사용됩니다. CDC 도구 없이 어플리케이션 폴링을 구현할 때의 구조에 대해 질문하셨군요. 이 패턴은 특히 대규모 시스템에서 데이터 일관성과 성능 문제를 해결하기 위해 사용됩니다.

1. 폴링 전용 어플리케이션: 주문 서버와는 별도로 폴링 서버를 두는 것은 매우 좋은 접근입니다. 이렇게 하면 폴링 로직이 스케일링되더라도 주문 서버의 성능에 영향을 미치지 않고 독립적으로 운영될 수 있습니다. 또한, 여러 폴링 인스턴스가 있을 경우, 각 인스턴스가 동일한 이벤트를 여러 번 처리하지 않도록 주의해야 합니다.

2. 컨슈머와 파티셔닝: 여러 폴링 로직이 동시에 돌아가는 상황을 고려하여, 일반적으로 메시지를 소비할 때는 파티셔닝을 통해 각 컨슈머가 고유한 메시지 셋을 처리하도록 설정할 수 있습니다. 이를 통해 데이터 꼬임 문제를 예방할 수 있습니다.

3. 정석 구현: OutBox 패턴의 정석은 없지만, 일반적으로 트랜잭션 로그를 기반으로 메시지 발행을 위해 반드시 한번의 조회에 한 번의 처리만 보장되도록 설계하는 것이 좋습니다. 이로 인해 부하가 큰 경우 워커를 추가하여 처리량을 조절할 수 있습니다.

이해를 돕기 위해 관련 질문과 답변을 아래 링크에서 더 찾아보시면 좋을 것 같습니다:
- OutBox 패턴과 Kafka 통합에 대한 논의

이 링크에서는 OutBox 패턴과 پیام 적절한 스케일링 방법들에 대해 설명하고 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.