[항해플러스] Back-end 6기 - 6주차 회고

이번 주에는 분산 환경을 고려한 다양한 동시성 제어 방식을 분석하고 도입하는 작업을 진행했습니다.

 

개인적으로는 굉장히 어려운 주제였고, 고민도 많았습니다. 단순히 Redis를 이용해 락을 걸기는 어렵지 않았지만, 분산 락을 잡은 후 트랜잭션을 어떻게 유지할지, 이후의 과정에서 만약 실패가 발생하면 어떻게 처리할지 등 다양한 요소를 고려해야 했기 때문에 많은 고민이 필요했습니다.

 

나름 고생한 덕분에, 과제도 무사히 통과하고 새로운 뱃지를 얻었습니다. 단순히 목표를 설정하는 것과는 달리 소소한 보상체계가 있어서 재밌게 진행하는듯한 느낌이네요.. ㅎㅎ 뱃지가 전부가 아니긴 하지만, 과제를 통과해야 인정을 받는 느낌인지라 인정을 뱃지를 얻기위함이 아닌 인정을 받기위한 과제를 수행해나가는 것이 중요하다고 느꼈습니다.

 

제가 선택한 방식은 트랜잭션 범위를 최대한 작게 가져가며, 재고라는 도메인 ID를 기반으로 락을 거는 방식입니다. 현재 도입한 락 방식에서는 기존의 @Transactional 어노테이션을 제거했으며, 이를 발전시키기 위해 Redis 락을 관리하는 Service를 별도로 두듯이, 상위 트랜잭션을 관리하는 Service도 별도로 구현할 계획입니다.

 

추가적으로, 항해에 참여하고싶다면 다음 추천 코드를 통해, 다음 과정에 대한 할인을 받아보는 것도 좋을 것 같습니다 ㅎㅎ

 

추천인 이름: 이철진

추천인 코드: rYq2PX

---

 

과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제

이번 주는 기술적으로 가장 어려운 한 주였습니다. 여러 가지 락 방식을 분석하고 현재 시나리오에 가장 적합한 동시성 제어 방법을 선택해야 했기 때문에, 효율성과 적합성을 모두 고려하는 데 많은 고민이 필요했습니다. 특히 구현 과정에서 트랜잭션 로직에 영향을 주지 않도록 해야 한다는 점에서 난관이 있었습니다.

 

문제를 해결하기 위한 시도

우선 가장 의지를 했던 부분은 멘토링이었습니다. 여러 멘토링 세션을 청강하고 Q&A를 진행하면서 고민하던 부분들을 보완할 수 있었던 것 같습니다. 또한 팀원들과의 리뷰 시간을 통해 동시성 제어 도입 방향을 합리적으로 정할 수 있었습니다.

 

문제를 해결하기 위해 시도하며 새롭게 알게된 사실

분산 락을 구현하기 위해 Lettuce가 아닌 Redisson을 사용할 예정이라는 점은 알고 있었지만, 분산 락의 개념 자체가 Redisson 사용 여부가 아닌, Pub/Sub 락 지원 여부에 따라 나뉜다는 것을 새롭게 알게 되었습니다. 또한, Redisson이 제공하는 다양한 동시성 제어 방식의 락들을 하나씩 조사하며 비교해보는 시간을 가졌습니다.

---

Keep : 현재 만족하고 계속 유지할 부분

이번주는 고민이 많아져서 만족한 부분이 업습니다. 개인적으로는 코드로 먼저 다가가는 습관이 더 필요하다고 느낀 주였습니다.

Problem : 개선이 필요하다고 생각하는 문제점

이번 주는 며칠씩 고민만 하며 시간을 보내다 보니, 스스로에게 실망이 많았던 한 주였습니다. 결국 실제 개발 작업은 당일 저녁에 시작하게 되어 일정이 매우 빠듯했습니다. 아직 고민이 많아 결정이 늦어지는 점이 제게는 큰 단점인 것 같습니다.

Try : 문제점을 해결하기 위해 시도해야 할 것

우선 해당 방식으로 동작하는 코드를 작성한 후, 문제 해결을 위한 분석과 리팩터링을 진행하는 Top-Down 방식에 좀 더 익숙해질 필요가 있을 것 같습니다.