극한의 동시성 문제는 보통 어떻게 해결하나요?

Question

보통 좌석 예매 나 , 잔고 또는 제품의 재고 등 에서 사이트에 트래픽이 없다면 충돌 횟수는 적을 텐데 선착순 으로 한번에 트래픽이 과도하게 몰리는 상태에서 하나의 좌석이 두 사람에게 배정된다든지재고가 없음에도 결제가 된다던지 등등 이러한 동시성 문제가 발생할거 같습니다.이러한 상태에서 락 을 걸어 동시성 문제를 해결할수도 있으나 느낌상 이로 인해 처리 속도가 상당히 저하될거 같습니다.그렇다면 이를 해결하기 위해 어떤 방법이 있을까요?Front → MQ - > Server → DB 이런식로 중간에 MQ 를 두고 순차적으로 처리하면 동시성 문제는 해결될수도 있을거 같으나 이 것 보다는 Front <→ Redis(Cashe) 형식으로 하나 두고 제품의 재고 나 좌석 여부를 체크 한후 성공한 요청에 대해서만 백엔드 서버로 넘기는 방식이 조금더 좋을거 같습니다.

Kyeongrok Kim · Accepted Answer

백엔드 쪽에서 주문 처리 할 때 쓰는 것을 본적이 있는 LMAX Disruptor라고 링버퍼 기반 고성능 저지연 메시징 라이브러리가 있습니다. 제가 옛날에 금융권에 잠시 발을 담궜을 때 이걸로 구현이 되어 있었습니다. 이걸 한번 잘 이해 해보시고 현 상황에 맞으면 도입을 고려 해보시기 바랍니다.이 라이브러리가 단순히 링버퍼라서 빠른게 아니고 Java인데 하드웨어를 직접 제어하는 것처럼 써서 빠릅니다. 링버퍼를 한 번 채우고 계속 재사용(덮어쓰기)하고 CPU의 프리페처가 쉴틈을 안주는 방식과 False Sharing과 캐시 라인패딩 이라는 기술이 들어갔는데 이건 아래 설명을 한번 읽어 보십쇼 저도 깊이 판건 아니라서 잘 모르겠습니다.False Sharing과 캐시 라인 패딩 ArrayBlockingQueue를 보면 head, tail, count 같은 필드가 나란히 선언돼 있습니다. 이들은 십중팔구 같은 64바이트 캐시 라인에 들어갑니다.문제는 프로듀서 스레드가 tail을, 컨슈머 스레드가 head를 쓴다는 것. 서로 다른 변수를 건드리는데도 캐시 일관성 프로토콜(MESI)은 캐시 라인 단위로 동작하기 때문에, 프로듀서가 tail을 쓰는 순간 컨슈머 코어의 그 라인 전체가 무효화(Invalid)됩니다. 컨슈머는 head를 읽으려고 다시 L3나 메모리까지 갔다 와야 하죠. 논리적으로는 아무 공유도 없는데 하드웨어 레벨에서 핑퐁이 벌어집니다. 이게 false sharing입니다.

더미 · Answer

프론트에서 MQ 나 REDIS 를 직접 쏘는경우는 없습니다

코가더 · Answer

Front —> 요청 인거조?

엽토군 · Answer

하나의 좌석이 두 사람에게 배정된다든지 재고가 없음에도 결제가 된다던지여기서는 ‘~든지’가 맞고 ‘~던지’는 틀립니다.말씀하시는 종류의 “동시성”은 기술적 동시성이라기보단 운영상의 동시성이라고 간주함이 더 타당하지 않나 합니다.사실 현실 세계에서는 DB 트랜잭션 충돌 수준으로 정밀한 자원 경쟁은 볼 일이 별로 없죠. “트래픽이 몰”린다 한들 그것들도 대체로는 ms 단위로 나뉘어서 인입되는걸요.현실에서 일어나는 문제는 보통 ‘자원 점유 우선권’의 문제이고, 그런 차원의 문제는 기획/운영 차원에서 풀고 있지 않나 합니다. 왜냐면 실제로 자원을 점유하고 소비하는 과정은 상당히 비동시적/비동기적이기 때문입니다.예컨대 극장 티켓 예매라면, 굉장히 많은 온라인 예매 시스템이 한 번 누군가 클릭하고 넘어갔던 좌석은 이후 10분간 무조건 선택 불가로 남죠 (그래서 이미 완료된 예매를 결제수단만 바꾸는 게 불편하잖아요? 아까 내가 골랐던 좌석을 이제는 못 고른다니.) 이게 왜 그런가 생각해 보면, 좌석 선택의 동시성 문제를 해결하지 못해서가 아니라, 애초에 좌석 선택이라는 게 비동시적/비동기적 이라서인 듯합니다. 좌석을 선택한다고 바로 커밋이 아니고, 팝콘 고르고 카드 골라서 예매 확정하기까지 10분 정도 시간이 걸리더라는 거죠.장바구니 문제도 비슷합니다. 이론서에서 흔히 장바구니를 예시로 들기는 하지만, 실제 쇼핑 과정은 험난하잖아요 쿠폰 고르고 지불수단 고르고 최종 금액 맞는지 확인하고. 이러다 보니 가끔 보면, 어떤 쇼핑몰/상품은, 누군가 체크아웃으로 넘어가 있을 동안에는 상품을 임시로 재고 소진 처리를 하는 경우가 있습니다. 그건 동시성 문제를 해결한 게 아니라 상품 인도 계약 체결 횟수 제약이라는 문제를 해결하는 접근법이겠지요.요컨대, 기술적 동시성 문제와 운영상 자원 점유 우선권의 문제는 서로 다른 것이고, 그 두 가지 문제는 접근하는/푸는 법도 서로 각각 다르지 않겠느냐 하는 말씀입니다.아닐 수도 있구요.

farmer kweon · Answer

극장의 경우는 DB에서 해당 좌석을 먼저 진입한 사용자에게 바로 배정하고 일정시간내 구매로 이어지지 않으면 해제시켜버립니다. 갑갑할 것 같습니다만, 예매 수단이 전용앱, POS, 통신사 등 다양하기 때문에 비용면에서 좋을 수 있어요.

극한의 동시성 문제는 보통 어떻게 해결하나요?

5개의 답변

Q&A 목록