해결된 질문
작성
·
70
0
몇 챕터/몇 강을 수강 중이신가요? 4강 트랜잭션과 락
트랜잭션과 락 관련 챕터를 수강 중입니다. 쿠폰 동시성 발급 사례를 보여주셨는데, 락이 필요하고, 왜 동시성 문제가 일어나고 어떻게 해결하는지에 대해 이해하고 있습니다.
쿠폰 동시성 발급 사례에서 코드를 보면 단순히 max값을 보고 current값을 증가하는 코드를 이용해 "락이 걸려있지 않아 의도대로 동작하지 않음"을 보여주시는 것 같습니다. 이런 사례 관련해서 많은 사람들이 "낙관적 락", "비관적 락"에 대해 공부하고, "비관적 락으로 해결"로 마무리를 하는 것 같습니다.
근데 저는 비관적 락이 아니라, query를 직접 작성해서 SELECT와 UPDATE를 한번에 사용할 수 있지 않을까 라는 관점에서 "원자적 업데이트"를 사용했습니다.
비관적 락: select + for update -> update
원자적 업데이트: update + where current < n
물론 select와 update를 한 번에 해결하는 상황이 아니라, 로직이 중간에 추가되면 비관적 락을 써야된다는 것을 알고 있습니다. 하지만 다른 사람들의 블로그를 보면 하나의 쿼리로 해결할 수 있는 상황을 비관적 락으로 해결하는 게 맞는건가 라는 의문이 들었습니다. 아무튼 이런 배경에서 질문은 아래와 같습니다.
비관적 락이 아니라 원자적 업데이트 라는 말을 이력서에 쓰면 더 도움이 될까요? 실제는 SQL 쿼리 하나 작성한건데, 비관적 락이 더 있어보이는 느낌인 거 같다...?
비관적 락으로 해결해야 되는 상황을 만들고 싶은데, select와 update 사이에 어떤 로직을 추가해야할까요? 기획을 변경 가능한 상황입니다!
외부 API: 결제말고 다른 거... 문자 알림?
다른 테이블 조회 또는 업데이트: SQL join문 잘 짜면 해결되는 거 아닌가...
위 내용과 관련해서 작성한 블로그 글입니다.
https://velog.io/@suhwani/QRworld-동시성-해결-원자적-업데이트
감사합니다!
답변 2
0
안녕하세요 수환님 좋은 질문 해주셔서 감사합니다!!!
너무 좋은 관점의 고민이고 생각의 흐름입니다!!! 블로그 너무 잘봤습니다 👍👍
1. 원자적 업데이트의 성능 이점
우선, 원자적 업데이트를 쓰면 좋은 이유를 성능상 이점 관점에서 파악해보는 것도 좋을 것 같아요. 실제로 락 걸리는 시간이나 처리량을 측정해서 비교해보면 더 설득력 있는 데이터가 나올 것 같습니다!
2. 비관적 락을 써야만 하는 경우
원자적 행위에서 모든 걸 처리해주지 못하는 경우입니다. 우리 수업에서 진행했던 것과 비슷한 사례로 보면, Event의 숫자를 업데이트하고 EventParticipant를 Insert해야 됩니다. 즉, 특정 모델 업데이트 후에 관계형 데이터를 넣어줘야 하는 경우 처럼 하나의 엔티티 기준으로 원자적 연산을 하지 못하는 경우에 락이 필요하다고 봐주시면 될 것 같습니다!
이와 비슷하게 다른 엔티티를 추가하거나 수정해야만 하는 비즈니스 규칙이 존재하는 것을 가정해보면 좋을 것 같습니다.
3. 이력서 작성 관점
제 생각에는 특정 키워드가 있어보이다기 보다는 각각을 비교해서 부하를 얼마만큼 단계적으로 개선했다는 내용을 쓰는게 더 있어보일 것 같습니다!!
그래서 어떻게 이 사고의 흐름을 나아갔는지 이력서에 명시해보길 추천드립니다. "처음엔 이렇게 생각했는데, 성능 측정해보니 이런 결과가 나와서 이 방식으로 바꿨다" 이런 식의 문제 해결 과정을 보여주는 거죠.
실제 프로젝트에 적용해서 수치를 만들어보시고, 이런 경험을 쌓아서 이력서에 써보시면 너무 좋을 것 같습니다!! 또 빠이팅해보시져 !!!
0
안녕하세요, 인프런 AI 인턴입니다. 정수환님.
트랜잭션과 락을 다루며 동시성 문제를 해결하기 위해 비관적 락과 원자적 업데이트를 어떻게 사용하는지가 중요한 질문인 것 같습니다. 두 접근 방식에 대해 각각 설명드리면서, 이력서 작성 시 유용한 팁을 제공해 드리겠습니다.
비관적 락은 데이터의 동시 접근을 막기 위해 SELECT ... FOR UPDATE
를 사용하는 방식입니다. 트랜잭션 내에서 다른 트랜잭션이 참조하는 데이터를 잠금으로써 서로 다른 세션에서의 데이터 불일치를 방지할 수 있습니다. 이 방식은 동시성 이슈 발생 가능성이 높은 환경에서 효과적입니다.
원자적 업데이트는 UPDATE ... WHERE
조건을 사용하여 데이터 변경을 원자적으로 수행하는 방법입니다. 즉, 조건에 맞는 경우에만 업데이트가 진행되므로 임계구역을 최소화할 수 있습니다. 동시성 문제를 줄이기 위해 이 방식을 많이 사용하며, 쿼리 하나로 작업을 완료합니다.
이력서 작성 시에는 두 가지 방법의 차이와 동시성 문제 해결에 쓴 방법이 실질적으로 어떤 면에서 더 좋은지 설명하면 도움이 됩니다. “원자적 업데이트”라는 키워드가 기술적 깊이를 드러낼 수 있으며, 특정 상황에서 비관적 락과 대비해 어떤 장점이 있었는지를 구체적 사례로 설명하면 좋습니다.
비관적 락이 필요한 경우, 일반적으로 쿼리 실행 간에 부가적인 작업이 필요한 상황입니다. 예를 들어, 다음과 같은 로직을 추가해 상황을 설정할 수 있습니다:
외부 API 호출: 예를 들어, 조건에 맞는 사용자가 있을 때 문자 알림을 보내기 위한 API 호출이 필요한 경우입니다. 이 경우 결과를 조회한 후에 API가 실행될 필요가 있어 락이 필요할 수 있습니다.
다른 테이블의 데이터 연계: 거래나 주문 시스템에서 다른 테이블과 연결된 데이터를 업데이트하거나 조회할 때 여러 데이터의 일관성을 유지하기 위해 비관적 락을 사용하는 것이 적절합니다.
이와 같은 시나리오를 기획해서 비관적 락의 필요성을 실제 사례로 구현한다면, 이력서에서 좋은 프로젝트 경험을 쌓을 수 있습니다.
유사한 질문과 답변이 있는 자료는 다음을 참조해 주세요:
- 효과적인 비관적 락 사용법과 고려사항
저는 질문자님의 이해를 돕고자, 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드립니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.