1. 개요
동시성 제어를 진행하면서 싱글톤 방법이 적당한 방법이 아니라는 것을 깨닫게 되면서 정말 여러가지를 배울 수 있었다.
특히 관련한 많은 여러 이론이나 제어 방법들을 찾아보면서, 당연히 통용되는 개념이나 방안들이 나에겐 "정말 그럴까" 라는 생각이 자꾸 드는 순간들이 많았다.
2. 내가 생각한 동시성 제어의 모순점
나는 당연히, 동시성 제어, 즉 다수의 스레드가 한 자원에 접근한다면 최초 자원의 상태는 모든 자원에게 동일한 상태, 동일한 참조값이어야 한다고 생각하였다.
이게 개발자마다 생각이 모두 다를 수는 있겠지만, 정말 여러 방안을 찾아본 바로는 반은 맞고 반은 틀리다.
즉 내가 생각한 동시성 제어의 모순점은, 출발을 어떻게 하느냐에 따라, 어떠한 과정을 통해 결과를 원하는 지에 대해 의문점을 제기한다.
만약, 주문과 같이 한건 한건의 멱등성과 결과 보장을 중요시 한다면 애초부터 접근하는 자원에 대해 싱글톤으로 일관성을 확보하는 것이 좋다.
반면 최종적인 자원의 제약사항(영화티켓 수 등)이나 최종 결과에 대한 정합성이 중요하다면 최초 자원의 상태보다는 전체 트랜잭션의 일관성과, 말 그대로 통상적으로 생각하는 동시성 제어(최종 결과의 정합성을 확보하는)가 더 중요할 것이다.
또한 흔히, 따닥 이슈나 악의적인 중복 처리 등 동시성 제어와 더불어 동시 요청에 대한 방안으로 redis lock을 활용하여 java 레벨에서의 lock이 가능할 것이다.
보통은 java와 dbms의 조합으로 해결방안을 찾지만, 항상 100% 동시성 제어를 진행할 수는 없다고 한다.
best practice는 존재할 수 없으니 차선책, 환경과 트래픽을 고려한 차선책을 고려해야 할텐데 이를 위해선 많은 시행착오와 경험이 필요할 것이다.
하도 깊게 박힌 잘못된 개념으로 고생을 좀 하였는데, 그래도 더 많은 것을 얻을 수 있었던 계기였다.
3. 참고자료
동시요청이슈 및 redis lock - https://tech.kakaopay.com/post/troubleshooting-logs-as-a-junior-developer/
