해결된 질문
작성
·
130
·
수정됨
0
안녕하세요.
우선 니즈에 맞는 좋은 강의를 찾아서 기분이 좋네요. 감사합니다.
게시글 , 댓글 , 좋아요 수 를 따로 테이블을 만들어 관리한다는 것은 처음 알게되었고 좋은 방법이라고 생각합니다.
강의에서는 비관적 락, 낙관적 락을 이용해서 동시성 문제를 해결하셨는데, 실무에서도 COUNT 테이블에 비관적 락, 낙관적 락을 많이 사용하나요 ?
대규모 트래픽에서는 성능 문제로 비관적 락을 잘 사용하지 않을 것 같았거든요.
낙관적 락을 사용하기에는 충돌이 많을 것 같구요.
(그저 제 상상입니다. ㅎㅎ;)
의견 부탁드립니다.
감사합니다.
답변 2
1
자라A3님, 안녕하세요!
저도 스스로 고민도 많이 하시고 열심히 배우려는 수강생 분 만나서 기분이 좋네요. 감사합니다.
아주 좋은 질문입니다!
강의에서는 잠깐의 레코드 락은 크게 문제될 여지가 없다고 판단하여 비관적 락으로 처리했습니다.
물론, 위처럼 판단이 될 수 있다면 실제로도 그렇게 처리하는 경우도 많습니다.
하지만 트래픽이 정말 많고 치명적일 수 있는 상황에서는 잠깐의 병목도 문제가 될 수 있는데요,
이 경우에는 비관적 락은 최대한 지양하려고 하고, 낙관적 락을 사용해 볼 수 있습니다.
낙관적 락에 대한 충돌 문제가 우려될 수 있는데, 사실 이러한 충돌은 그렇게 잦지 않을 수 있습니다.(기능 및 트래픽마다 다르겠지만)
그래서 1~2회 정도 서버에서 직접 재시도를 취하는걸로 충분할 수도 있고,
클라이언트에게 특정 에러 코드를 기준으로 재시도를 해달라고 요청할 수도 있습니다.
만약, 사용자가 직접 재시도를 하는게 큰 부담도 없고, 사용성에도 별 문제가 없다면,
그냥 사용자에게 일시적인 오류로 인해 직접 재시도를 해달라고 안내를 해줄 수도 있습니다.
그런데 비관적 락으로 인한 병목과 낙관적 락으로 인한 재시도에 대한 우려까지 모두 막고 싶다?
그 경우 비동기 큐에 데이터를 쌓아두고, 순차적으로 처리할 수도 있습니다.
대신 이 경우에는 데이터가 반영되기까지 일시적인 지연이 생길 수 있으나, 최종적으로는 데이터 일관성(Eventually Consistency)은 맞춰지게 됩니다.
이를 위한 시스템을 구축하는게 큰 수고가 들 수 있고, 사용자에게 지연이 치명적인 경우 이 방법은 사용하기 어려울 수는 있고요.
각 방법이 모두 장단점이 있기 때문에,
시스템 구성이나, 도메인, 서비스 정책, 사용자 입장을 모두 고려하면서 적절한 방식을 선택하게 되는 것 같습니다.
병목이 문제되지 않고 재시도를 하고 싶지않다면, 비관적 락. (구현 비교적 쉬움)
병목을 없애고 싶지만 재시도에 대한 부담이 허용된다면, 낙관적 락. (구현 비교적 쉬움)
병목과 재시도 모두 없애고 싶지만 일시적인 지연이 허용된다면, 비동기 처리로 최종적 일관성. (구현 비교적 어려움)
원래 이러한 부분을 설명하는 장표도 있었는데, 너무 과한 내용까지 전달하려는 건가 싶어서 제거했던게 아쉽네요.. ㅎㅎㅎ
좋은 질문 남겨주셔서 감사하고, 혹시 더 궁금한 점 있으시면 편히 문의 주세요!
0
안녕하세요, 인프런 AI 인턴입니다. 자라A3님.
질문해주신 내용은 데이터베이스에서의 동시성 문제를 해결하기 위한 방법 에 대한 것으로, 특히 비관적 락과 낙관적 락의 사용에 관한 것입니다. 여러 트랜잭션이 동시에 변경을 시도할 때 발생할 수 있는 문제를 해결하기 위해 락을 사용합니다.
비관적 락(Pessimistic Lock):
낙관적 락(Optimistic Lock):
위 설명이 도움이 되셨길 바라며, 비슷한 주제를 다룬 다른 유사한 상황에 대한 더 많은 정보를 얻기 위해 데이터베이스 락의 실무 적용 사례 (게시글 제목) 이라는 게시글을 확인하시기를 추천드립니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
각 방법에 대해 비교해서 설명해주시니 이해가 쉽네요.
감사합니다.