저는 발전적인 사람입니다. 개발 도중에 마주한 문제점에 대해 표면적으로만 해결하려고 하지 않고, 근본적인 원인을 찾기 위해 노력합니다.
해당 프로젝트는 프롭테크 플랫폼으로, 주 차별점은 매물 속의 옵션들을 관리해주는 기능이었습니다. 매물 계약 과정에서 세입자가 될 사람이 매물 내부의 수리해야 할 부분들을 등록하면, 집주인/중개인의 공증절차가 끝난 뒤에 임대차 계약서의 특이사항으로 관리됩니다. 이는 후에 변상 책임 관련 분쟁의 증거로 사용되는 것이 주목적입니다.
모두가 공증하였는지를 체크하기 위해, 집주인/중개인의 각 확인 컬럼과 모두가 확인했다는 tot_confirm 컬럼이 존재하였는데, tot_confirm 컬럼은 집주인이나 중개인의 확인 절차가 있을 때마다 체크하여 변경되는 식으로 로직이 구성되어 있었습니다. 하지만 집주인과 중개인이 동시에 확인절차를 거칠 때는 모든 확인 컬럼이 true로 바뀌었음에도 tot_confirm 컬럼은 변화가 없었습니다.
문제의 원인을 찾기 위해 트랜잭션에 대해 깊이 있게 공부하게 되었습니다. DB는 mysql을 사용하고 있었기 때문에 트랜잭션 격리 수준이 repeatable_read였고, 이 때문에 update 쿼리문이 날아갈 때 해당 row 자체를 lock을 걸어버리기 때문에 멀티 스레드 환경에서 동시에 수정을 하는 것은 불가능하였습니다.
하지만 문제는 JPA에서 제공하는 변경감지 기능이었습니다. 해당 기능은 select 쿼리가 발생할 때의 시점을 스냅샷을 찍은 뒤 트랜잭션 커밋 시점에 해당 스냅샷과 현재 엔티티를 비교하여 이때 엔티티가 변경되었을 시 update쿼리를 날리기 때문에 두 스레드가 동시에 select 문을 날린 뒤에는 다른 스레드에서 update 쿼리를 날린 결과가 반영되지 않는 문제점이 발생했습니다.
따라서 해당 필드에 대한 lock을 거는 것으로 문제를 해결할 수 있다는 판단하에 optimistic lock과 pessimistic lock을 고민하게 되었고, 해당 api는 최대 세 사람만 동시에 호출할 수 있었기 때문에 성능이 뛰어난 optimistic lock을 도입하여 version 체크를 통해 동시성 이슈를 해결하였습니다.
https://github.com/algosipdahack/E-State-Twin-Back/commit/c581676665003946b7863714b36aa159200c6aa7
ALB를 통해 수신된 외부 트래픽을 스프링 부트 서버가 올려진 EC2로 전달해 주는 과정에서 웹서버로 접속이 되지 않았습니다. EC2의 보안 그룹에 8080포트를 열어두었기 때문에 접속이 되어야 한다고 생각했지만, 계속해서 80포트로 접속이 되는 상황이 발생했습니다.
이를 해결하기 위해 제가 이해한 내용을 1) 블로그 포스팅을 통해 다시 한번 정립하는 시간을 가지게 되었고, 브라우저는 80포트가 기본 포트이기 때문에 80, 8080포트를 두 개 다 열어놓을 경우 자동으로 80포트로 접속이 된다는 사실을 알게 되었습니다.
해당 경험들을 바탕으로 빠른 트러블 슈팅을 위해서는 개념 정립이 중요하다는 것을 알게 되었습니다. 따라서 매일 작성하는 TIL을 통해 하루 동안 배운 개념을 저의 언어로 정리하고, 블로그 포스팅을 통해 주제에 대한 전체적인 흐름을 정리하였습니다. 또한, 테스트 코드를 통해 다양한 문제 상황에 대해 미리 대면해볼 수 있었을 뿐 아니라 초반 설계대로 잘 구현을 했는지 검증을 할 수 있었습니다. 이를 통해 2) 불필요한 SQL문이 다수 발생되고 있다는 것을 알게 되어 전체적인 로직 검증을 통해 성능 개선 또한 이루어 낼 수 있었습니다.