봐봐
공유데이터에는 락을 무조건 걸고보자는 주의가 러스트잖아.
물론 내가 자꾸 무조건 무조건 이러면서 러스트를 바보취급하는거같긴한데
러스트에서도 락을 풀고 프로그래머 재량껏 위험한 코드를 쓸수도 있음.
근데, 여하튼 안전한 코드
그리고 때에 따라서는 동시성문제를 제어하는것.
이거는 중요한 문제야.
러스트에서는 공유변수가 생길때마다 컴파일러단계에서 검증을하는데
우리 웹개발자들아
데이터베이스는 광범위한 공유공간인데
우리는 이거에 락을 안걸고 사용하고 있었다고.
여기서 락이라는 단어에 너무 발작하지마. 뭐 락프린지 뭔지 일단 통과시키고 롤백하는것도 나는 락이라고 부르는 중이야.
그래서
흐음... 아무생각없이 지내다가 일이 터지면 그때서야 해결책을 강구하는거 말고
좀 코딩스타일 그 자체로 동시성을 미리 컨트롤하고자 하는 욕구 없어?
이게 문제가 터지면 생각하는 방식은 뭐가 문제냐면
지금은 안전할 수 있어.
지금까지 코드로는 안전성을 보장할수있는데
미래에 코드가 바뀌면 그 검증을 또 다시 진행해야함.
이거 뭔말인지 알잖아 다들...
그래서 이걸 도구를 써서 잡아야하는거야.
자동으로 코드가 바뀐것에 대해서 문제가 잡히게끔 해야돼.
자 얘들아.
그러면 이런 방식을 생각해볼수있어.
아, 그러면 그냥 get 해올때마다 select for update 써버려!
그냥 싹다 락 걸어!!
이게 문제가 있어.
일단, db 에서 락은 내가 마음대로 해제할수가 없고
트랜잭션이 종료될때까지 유지돼.
그러니까 이렇게 락을 잡아버리면 범위가 너무 커짐.
그리고 우리 JPA쓰는 이유 뭐야.
모르면 메모해.
영속성컨텍스트에서 변경감지 자동으로 해주는거?
너희 이게 뭐 초보자들 코드 한줄 아끼자고 자동으로 해주는거 같니?
아니야
서비스1에서 서비스2를 호출해.
서비스2는 다른데에서 재활용돼.
서비스1이 끝나야 트랜잭션이 종료돼.
라고 가정해봐
이 상태에서
서비스2 에서 업데이트문을 발송해.
그러면 원래 서비스1이 끝날때까지 해당 row에는 업데이트 락이 걸린다고
서비스2에서 발송한 업데이트시점과
서비스1이 끝나는 시점까지 락이 걸리는거야.
근데, 서비스2에서 발송한 update문을 너는 서비스1에 옮겨놓을수 있겠니?
이걸 최적화 하려면
모든 로직마다
업데이트를 예약시킨담에
서비스1에서 해당 업데이트문을 날려야돼
너 이거 할수있어???
이거 진짜 굉장히 귀찮은일이고
심지어 서비스1 서비스2만 고려할게아니라
서비스 2는 재사용될거고
서비스1에다가 코드를 박자니 서비스2코드가 바뀔때마다 모든 서비스2를 호출하는 바깥 서비스 코드를 바꿀거니? 이게 지금 말이 된다고 생각해??
그래서 AOP쓴다고
이러려고 AOP쓰는거야
그리고 이래서 영속성컨텍스트 쓰는거야.
바깥 트랜잭션이 어딘지 스프링이 체크하고
그 시점에 업데이트해야하는것들 쭈루룩 체크하고 커밋 직전에 업데이트 날리는거야
왜?
커밋 직전에 업데이트 날려야 해당 row에 업데이트 락이 걸리는 시점이 최소화되니까.
나 솔직히 지금 너무 친절하게 설명한다 맞지??
여기까지
"어 뭐야 이거 진짜개발잔가?" 라는 생각이 들면 공부 다시하고 와.
내가 자바, 스프링이랑 JPA, 객체지향만 잘해도 취직 잘된다는거 개소리가아님.
일단 나는 뽑아 쓸거야
이 베이스가 되어있다는건
뭘해도 잘할거란뜻임. 물론 웹개발에 한정해서는.
여하튼
select for update는 그래서 안돼...
그래서 optimistic lock을 사용해야한다고
와 근데 이거 사용하면
이제 안전하게 코딩도 할수있고 참 좋다 그치??
근데 문제가 하나가 있어
일단
옵티미스틱 락 쓰기 전에
이게 진짜로 안전한지
기본블록으로 검증 똑바로해.
기본블록은 트랜잭션 격리수준, 그리고 DB row lock 과 table lock 이야. 이정도만해. 뭐 갭락 이런 짜잘한 규칙은 내가보기에 SQL 구현체들마다 다를거같고 필요할때 찾아보셈 큰 줄기는 아님.
여하튼 기본블록들로 제대로 검증해.
그나마 DB 동기화 블록들은 쉬움.
왜냐면 디비락이랑 격리수준 자체가 이미 하드웨어 OS수준의 동기화블록으로 만들어진 고수준 동기화블록이고
이것만가지고 디비쪽 동기화를 다 만들어냈으니까 쉬움.
그 밑바닥은 안건드려도됨. (물론 궁금해서 건드리고 싶어야 정상임.)
여하튼 옵티미스틱락을 쓰기로 했는데 여기까진 좋은데
분명히 네카라 이새끼들 옵티미스틱 락 안쓴단말이지?
나만,
나만 고집한다??
나만 이 규칙 고집한다??
그리고 러스트조차 풀때는 락을 풀고 그냥 위험하게 쓰기도 해
그니까 락을 푸는 방법이 중요함.
옵티미스틱 락 써보려고해봐. 락 푸는 방법이 없음 ㅋㅋㅋㅋㅋㅋ
씨발 그냥 업데이트하라고!! 이게 안됨.
내가 그래서 그 방법을 찾아냈다.
2편에서 얘기해줌.
그니까 그냥 요약하자면 이거임
엔티티별로
이게 동기화가 필요한지 아닌지 고민하고 필요하면 그냥 옵티미스틱 박아
그러면 자동으로 안전하게 검증해줌.
물론, 익셉션 튕기는 처리도 자동화 시켜놔. 상속이건 AOP건 뭐든 좋으니까 익셉션처리 자동화해.
어노테이션으로 리트라이인지 에러메세지반출인지 이런거 자동화시키는것도 좋고.
여기까지만 해
그 다음부터는 무비용으로 안전성 보장받을 수 있고
어 대표님, 새로만든 테이블에서 api가 유저 좀 몰리면 실패율이 너무 올라갑니다
라고 하면
그제서야 대응이 가능함.
이게 나는 데이터가 깨져서 엉망되는것보단 낫다고 본다.
중요한 데이터에 대해서는 트래픽같은거는 우리가 직접 만들어서 실험해볼수도 있는거고
데이터가 깨지는걸 인지도 못하고 먼 미래에 데이터가 오류인걸 깨닫는거보다는 훨씬 나아 진짜로
에러가 곧장 터지는게 맞다고 ㅇㅇㅇㅇ
여하튼 그냥 옵티미스틱 필요한곳에 박고 옵티미스틱 자동으로 설정되게 하고 실패율 체크해.
그리고?
옵티미스틱 풀고싶으면??
2편에 나올 방법을 쓰면 된다.
어때 깔끔하지?
우리 회사 오면
나랑 같이 이런거 고민하고 나랑 치고박고 싸울새끼 환영한다
러스트 변수레벨이랑 디비랑 왜 비교함. 프론트는 잘 모르니 디비 처리는 뭐 그렇다 쳐도 로직 복잡도만 늘고, 유지보수 안되어서 곧 사장될 코드 생산함.
차라리 데이터 원천의 안정성을 챙겨야한다면 그냥 디비쓰는게 맞다고 봄. 니 말대로면 대규모 msa 구조인 머기업에서 각 클라 서버단에서 지들만의 트랜잭션 룰 가져다가 개판날꺼 눈에 훤히보임.
업데이트마다 version = version + 1 해주기만 하면 됨. 이게 옵티미스틱이기때문에, 버전체크를 안하는애가 있더라도, 안전해야할 애들의 안전성은 보장됨. 버전만 올려주면 문제 없어. 튕기고 롤백할지 말지는 자유임. 양쪽에서 "아 이거 중요해" 하면 둘다 규칙 지키겠지
물론 jpa쓰는쪽에서는 그냥 아무 코드도 작성 안하면 자동으로 안전장치 걸어주는거고
만약 같은 테이블을 쓰는데 테이블에 떡하니 version 이라는 컬럼이 있는데 그거 무시한다?? 지금 이 옵티미스틱 락이라는게 jpa에서만 쓸수있는게 아니고 모든데에서 통용되는 규칙으로 만들수 있는건데 이걸 안지킨다? 그러면 같은 조직간 의사소통이 아니지않을까?
쟤가 락걸었으니까 내 업데이트가 무조건 막히겠네... 이런것도 아니고 그냥 version 만 업데이트했다고 표시만 해주면 됨
그리고 select for update 가 문제점이 update할지 안할지 모르는 상황이라면 무조건 update락이 걸려버리는데 이것도 문제가 있지. 옵티미스틱락은 내가 뽑은 대상에 일단 락 걸고봐도 업데이트를 안하면 락 안건것과 동일하게 처리됨
리스트로 뽑았는데 모든데에 락 다걸고볼래 아니면 옵티미스틱으로 유도리있게 처리할래?
그냥 락을 안쓴다고하면... 뭐 네카라가 그러고있는데 내가 말해서 뭐하겠음
근데 분산락이 해답인거같음 걔들이 손놓는건 아니고 뭐 분산락을 공부해봐야 알듯
근데 셀렉트 포 업데이트는 진짜 좀 별로임... 대량 쿼리에서 모든데에 다 락걸리고 조인된애들한테도 다 락걸리고 이건 문제 있음 진짜...
ㅇㅇ 서비스나 상황따라 어떤 락이 필요한지 결정되니까 이게 무조건 좋다고 우길순 없는 노릇일듯. 대부분 아토믹하게 처리되어야할 필요 있는 애들은 디비에 보관하는게 맞고, 클라나 서버는 레퍼런스만 들고 처리하는게 성능상 무조건 이점이 있다고 봤음. 니가 상정하는 상황이 뭔지 잘 모르겠어서 나도 애매하긴 한데, 대부분의 서비스는 1. 유저가 봐야하는 데이터가 무조건 원천과 동기화 되어야한다. (증권거래, 은행) 2. 데이터 업데이트는 늦어도 상관없고, 우린 무조건 빠르게 처리되어야 한다. (대부분의 CP) 일거라서 그 중간인 애매한 처리는 필요한 경우 찾기가 애매해 보였음.
중요할때 강력한 락을 걸기 인가 아니면 락을 일단 걸고볼건데, 따라서 약한 락을 걸것인가 의 차이 아닐까? 나는 후자스타일을 선호하는데 그게 엇나간 발상이라면 인정할게
나는 약간 광적인 컨트롤욕구가 있어서, 아주 작은거 아무도 신경 안쓰는거더라도 데이터가 정확하지 않게 들어간다면 그걸 전부 다 알고싶음
옵티미스틱 락 이거 그리고 내가보기에 비용이 진짜 적은데... 아닌가...
솔직히 함수형같은거 다뤄본 입장에서, 한번 뽑아온 데이터가 맘대로 변경되어있어서 내 캐쉬(내 메모리에 들어있는건 캐쉬)가 동기화가 안되어있는 현상이 발생한다는거 자체가 기분이 나쁨 나는
이게, 뭐 C나 자바 입장에서는 우리 원래 그래왔잖아 왜그래!! 중요한거는 우리도 다 처리한다고. 너 바보냐 모든데에 다 안전성 걸고늘어지는거 진짜 바보짓이야!! 라고 할 수도 있긴한데 최신 언어 철학은 좀 아니잖아??? 안전성을 개발자들이 컨트롤하기 어려워하기 시작했다는걸 인정하잖아?
중요한걸 처리한다는건 결국 사람이 문제인식을 먼저 하고나서 대응책을 찾은거임. 사람이 그냥 해피하게 넘어가면 그거 물밑에서 계속 줄줄 새는거임.. .난 그게 싫음
결제가 왜어려움??? 사람이 중요하다고 인식해서임. 로직이 어렵다기보다 사람이 중요하다고 인식해서임. 그런데에서만 초강력 안전도구를 박고 나머지는 안중요하니까 그냥 간다?? 사업가 마인드는 이게 맞지 근데 프로그래머로선 이거 좀... 그렇지 않음?? 중요한거에선 센거박아서 과투자해버리고말이야...
1. 너의 광적인 컨트롤 욕구는 너 개인의 것이지 팀이나 회사 서비스가 원하는 레벨은 아님 2. 옵티미스틱 락이 디비가 아닌 코드단에서 동작할 때 어느정도 성능인지 밴치마킹을 하고, 증명하는게 '좋을 것 같다'보다 백번 천번 나은 접근 방식 3. 함수형과 캐시 불일치가 무슨 상관관계가 있는지 모르겠음 4. 최신 언어철학이 뭔지 모르겠음. 임베디드, OS, 펌웨어, 백엔드, 프론트, ML 모두 다 각기 다른 언어 철학의 장점을 뽑아다 쓴다고 생각. 나는 CP 쪽이라 그런지 안정성을 업무 성과에서 챙겨본 경험이 얼마 없는듯.
너가 직장인이면 이런거 회사에 도입하자는거 미친짓이지. 근데 나는 이거 애들한테 시킬거고, 댓가? 있으면 내가 직접 맞을거야. 물론, 애들한테 검증시키겠지. 근데 애들한테서 "이러면 돈이 어쩌구저쩌구, 저 공부하기 싫습니다" 하는 이유가 나올리가 없고 애들이 제대로 반박하고 더 좋은방법 얘기하고 뭐여튼 그렇게 갈거임 대빵이 이런거 분위기 안만들면 밑에서 이런거 얘기하는거 눈치없는거지
5. 해피하게 넘어가는게 아니라 1. 처럼 각자 자기가 원하는 환경을 만드는게 아니라 다같이 고민해서 만들어나가는게 아키텍쳐나 로직이고, 너도 내생각엔 이 옵티미스틱 락을 코드단에 적용하는게 이런 장점이 있는것 같다정도면 될 듯. 6. 프로그래머도 결국에 고연봉을 받게되면 의사결정과 아키텍쳐 설계를 더 잘하기 위해 여러 팀간 커뮤니케이션을 해야한다고 생각함. 실력있는 프로그래머는 0.001ms 응답속도, 99.9999% 고가용성, 완전무결한 아토믹처리, 극한의 최적화 이런 것보다 상황에 맞는 판단을 내가 아는 지식과 알아낼 지식선에서 적절하게 선택하는거라고 생각함. 7. 님 컨텍스트 변화가 내가 리스팅한것처럼 너무 다이나믹하게 변해서 솔직히 소통하기 힘듦.
솔직히 회사에서 야 우리 함수형 쓰자 하는것부터가 눈치없는 미친짓 아님?? 이거는 대빵이 하자고 안하면 밑에서 하고 싶다고 말 못꺼낼 그런것들임
8. 개발할 때 적절히 써먹을만한 요소가 있다면 당연히 트라이해볼 수 있는 환경이 좋은 회사라고 생각함. 대빵이 하자고 하는거 검증도 없이 그냥 따라하는게 더 이상한 환경이지. 근데 이게 얼마나 큰 임팩트가 있는지, 당장 적용해야할 시급한 사안인지도 대빵이 판단할거고, 그 사안에 들어갈지는 의문.
이런 얘기가 안나오는 회사보다 나오는 회사가 훨씬 더 나음. 뭐 돈을 더 번다 주가가 어떻다 이런걸 떠나서 그냥 삶을 사는 이유같은거임. 물론 개소리에 다같이 시간낭비하고있는짓은 당연히 안됨. 나는 그냥 내가 그런 환경 만들거야. 왜냐? 한국에 그런곳 없잖아 ㅇㅇㅇ 미국도 솔직히 그닥 좋게생각하진 않고 난 이거 강요한적 없음 한번 써보랬지.
본문 마지막글 확인하셈. 너 그냥 태클만 걸고싶어서 안달난거같음
싸우잔게 이런식으로 싸우잔거 아님. 너 프로그래밍얘기하고있지 않잖아
내 수준 맞는 동료. 나랑 치고박고 싸워줄 동료가 없다고 내 방식이 틀린건 아니지. 근데 그래서 나 아무나 동료로 안받음. 캐리는 해줄수 있는데 동료급이 되려면 진짜 엄청 강한애여야함
그리고 내가 총대맬거니까 하는 얘긴데 틀려도 된다. 자기 얘기에 애착없고 책임없는애가 지껄이는 얘기따위는 당연히 그 깊이에서 내가 커트 미리 했을거고 내가 통과시킨 의견은, 내가 통과시키고 나서부터는 내 책임임
내가 통과시킬 의견 내뱉는애가 있음. 근데 나랑 분야도 다르고. 뭐 분야 같더라도 내가 지금 영입할 레벨이 아니지. 그래서 그 전까지는 그냥 나는 맞적수가 없다. 걍 그 뿐임
글구 나도 이거 그냥 해보라는거지 네카라 왜 병신이냐고 하는거 아님 ㅅㅂ 이걸 왜해 왜 네카라 러스트안쓰냐!!! 하는 샛긴 미친샛기지... 그냥 러스트얘기 좀 해도 되잖음
자기 할일 안하고 러스트만 하는샛기들이 꼴불견인거지 러스트자체는 흥미롭고 건설적인 주제가 맞아 미래이기도 하고
여튼 나중에 얘기가 좀 샌거같다만 첨에 플밍얘기나눠줘서 고마워
옵티미스틱 이거 변경감지때 version에 where하나 추가하는거 딱 그 비용이야 물론 롤백이 비용이지 근데 롤백? 싫으면 세팅해제해 난 일부러 롤백시킨거니까 이게 광적이니까 ㅋㅋㅋ 보통은 안하는게 맞겠지
니가 어느 분야에서 일하는지 모르니까 옵티미스틱 락이 필요한 상황에 대해서 내가 추정하려고 계속 질문했던거고, 프로그래밍 이야기했다가 딴 이야기했다가 하길래 뭘이야기 하고 싶은건지 리스팅해본거임. 니가 말한대로 지금 너가 상정한 서비스1, 2는 분산락이 더 적절해보임. 사실 서비스가 n개로 늘어날거고, 해당 서비스말고도 서비스b가 또 n개로 늘어나 같은 테이블을 찌른다고 생각해보면 부서가 다르고, 컨텍스트 공유가 안되었을 때 분산락만큼 아주 뚜렷한 구현체가 좋아보임. 더군다나 너가 제시한 케이스는 누군가 optimistic lock 걸고 안풀면 타임아웃도 걸어야하고, 익셉션 처리도 해야하고, 표준화되지 않은 처리들이 각기 서비스에 덕지덕지 붙을 가능성이 있어보임.
옵티미스틱 락 이거 함 보고와봐 나도 분산락 보고올게 옵티미스틱 락 이거 그냥 버전보고 롤백하는게 전부고 진짜 음.. 하 이거 그니까 그냥 락도아니야 ㅋㅋㅋ
오히려 셀렉트포업데이트가 타임아웃이라던지 외부세계에 영향을주지옵티미스틱 이거는읽어온당시의 버전이랑 체크하고 자기혼자 조용히롤백하는거야근데 이게 이론상 무비용인데jpa측에서변경감지 로직을 무조건 버전체크하도록해놔가지고내 해결책에는 비용이 있긴해
이거 옵티미스틱 써도 외부세계에 영향 하나도 안줘외부세계가 업데이트마다 버전을 올려주지않으면 옵티미스틱이 영향받는 구조임.양보하는 시스템임.그래서 외부시스템들한테나 버전관리쓰게 버전좀 올려주세요라고 부탁하는정도가 유일한 비용이야
솔직히 이 기능 나름 뭐 신경써서 나온걸거고 신기능이고 그래서 왜만들었을까 ㅈㄴ 고민도해보고 이해해보려했는데 생각보다 ㄱㅊ은거같음 근데 뭔가 미완성삘
넘 길어서 아래로 옮김
기억이 가물가물해서 좀 더 읽어보고옴. 근데 보니까 optimistic lock은 락 잡는 시간이 길면 안되겠네. 업데이트한다고 어느 서비스가 어플리케이션 단에서 락잡고 길게 트랜젝션 늘어뜨리고 있으면 그 사이에 들어온 애들은 리트라이 or 실패 할텐데, 그럼 서비스에 영향갈테니 서버 한계치가 있을 것 같은데. 아티클들 읽어보니 한결같이 conflict(동시 접근 충돌) 많이 나지 않는 환경에서 저비용으로 쓸 수 있다고 하네. 거기다가 롤백도 쉽지 않을거같고.
맞음. ㅇㅇ 이거 롤백자동화라고 걍 써놨는데 쉬운일이 아님. 그래서 나도 이걸 표현할때 일단 걸고보고 컨플릭트가 많이 나면 그때 락 제거하고 대응책을 찾아보자 고 얘기한거야 ㅎㅎ
데이터가 회사모르게 깨지고있는것보단 내부적으로 트래픽가짜로 발생시키고 컨플릭트계속뜨는곳 가서 대응하는거 어떨까? 하는 주장 ㅎㅎ 아이디어 자체는 약간 그니까 좀 꺼리가 있어보인다? 완성도가 무지떨어짐. 선례가있는것도아니고
글구 옵티미스틱 이거 설정 테이블별로 가능한데 테이블중 원하는것만 걸수도있으니까 뭐.. 근데 모든 기술이 다 그렇지 적재적소에 쓰면 감초일지도? 인데 그렇게따져서 모든 도구가 다 명도구라는 논리가 되면 안되니까
제목에 혁신 이거는 뭐 세상 변한다 보다는 새 개념 그런 느낌인데 내가 과장이 원래 많이 심함
근데 고마운게 이거 뭐 컨플릭트 일부러 만드는건 국룰이 아니고 컨플릭트없는곳에서 추가안전장치정도로만 고려해볼게 고마웡
딱보니까이거 함 해보면 컨플릭트 ㅈㄴ터져서 도저히 경고문으로 못쓰나보다. 경고가 모든데서 터지면 그건 경고가 아니지. 이거 아무데나 쓰면 컨플릭트 ㅈㄴ터지나봐