240208 TIL - 최종프로젝트 마무리

오늘은 길다면 길었고 짧다면 짧았던 최종프로젝트를 마무리하는 발표회가 있었다.

발표를 무사히 마무리하고 튜터님들이 찾아와서 우리 프로젝트와 관련된 질문들을 주셨는데

그 부분에 대한 정리를 휘발되기전에 정리를 해 두어야 할 것 같아서 정리를 해보겠다.

우선 질문을 굉장히 많이 받았는데 

• 좋아요의 동시성문제를 파악하고도 적절히 처리해주지 않은 결정
  
  • 이 부분은 사실 질문에 대한 답변이라기보다는 질책(?) 피드백(?)과 같은 부분이었다. 백엔드 개발자는 프론트단에서 비정상적인 상황에 대해서도 대응을 해주어야 한다고 하셨고, 이렇게 문제점을 파악하고도 처리하지 않은 것은 오히려 마이너스 포인트라고 하셨다. 
• 동시성 테스트에 대한 해결방안으로 적어주신  낙관적/비관적 락킹, syncronized 에 대해 설명(RateLimiting도 찾아볼것)
  • 낙관적 락킹 (Optimistic Locking) : 낙관적 락킹은 이름에서 알 수 있듯이 충돌이 발생하지 않을 것이라는 '낙관적'인 가정하에 동작합니다. 낙관적 락킹은 데이터를 읽을 때 락을 걸지 않고, 데이터를 실제로 변경(update, delete)하려는 시점에 충돌 여부를 확인합니다. 이 때 충돌이 감지되면, (예를 들어, 다른 트랜잭션이 먼저 해당 데이터를 수정했다면) 트랜잭션을 재시도하거나 오류를 반환합니다.
  • 비관적 락킹 (Pessimistic Locking) : 비관적 락킹은 충돌이 발생할 것이라는 '비관적'인 가정하에 동작합니다. 비관적 락킹은 데이터를 읽을 때부터 락을 걸어, 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 합니다. 이 방식은 동시성이 높은 상황에서는 대기 시간이 길어질 수 있지만, 데이터의 일관성을 보장합니다.
  • Synchronized : synchronized는 자바에서 사용하는 키워드로, 멀티스레딩 환경에서 하나의 스레드만이 특정 코드 블록을 실행할 수 있도록 하는 동기화 메커니즘이 있습니다. synchronized 블록이나 메소드에 진입하는 스레드는 해당 블록이나 메소드에 대한 락을 획득하며, 락을 획득하지 못한 다른 스레드들은 대기 상태가 됩니다.
  • 분산 락 (Distributed Lock) : 분산 락은 여러 노드로 구성된 분산 시스템에서 동시성을 관리하기 위한 기법입니다. 분산 락을 사용하면, 분산 시스템 내의 여러 노드에서 동일한 리소스에 대한 접근을 제어할 수 있습니다. 분산 락을 구현하는 방법은 다양하며, 주로 Redis, Zookeeper 등의 솔루션을 활용합니다.
• JMeter로 성능테스트를 진행해주셨는데 구체적으로 어떻게 테스트했는지, 그때의 수치가 어땠는지
  1. 저희가 한 성능테스트는 캐싱을 하였을때 하지 않았을 때의 차이를 비교한 테스트입니다. 아래 사진에서 위의 그래프는 캐싱을 하지 않은 상태에서 요청이 들어왔을 때의 응답 속도의 그래프이고 아래 그래프는 캐싱을 했을 때의 응답 속도 그래프입니다.

 

 

두 그래프를 보면 캐싱을 하지 않은 위쪽은 평균 9ms정도가 나오고 캐싱을 한 아래쪽은 평균 4ms 를 밑도는 것으로 나왔습니다. 이를 통해 캐싱을통해 응답속도부분에서 성능개선이 이루어졌다고 보았습니다. 

-> 이렇게 답변을 했는데 ThreadProperties에 대한 지적이 있었다. 사실 오늘 질문을 받고 급하게 자료를 준비하느라 JMeter 에 대한 이해가 부족하였고 테스트조건을 설정하는데 더 공부할 필요성을 느낌.

 

• 캐싱을 적용해주셨는데 캐싱된 데이터의 실제 값에 변동이 생긴다면?
  • 우선 데이터의 실제 값에 변동이 생길경우 @CacheEvict를 통해 캐시를 삭제해주는 과정이 있지만 현재 서비스에서는 @CacheEvict를 적용하는대신 캐시별로 만료시간을 정해주었습니다. -> 적절한 근거를 가지고 만료시켜주면 좋은 답변이 될것.
• (내질문은 아니였지만) multiplebag 문제 -> 이력서에 꼭 넣어주세요!
  • multiple bag
    • 문제 상황
      • 데이터 조회의 성능을 최적화 하기 위해 ‘지연 로딩’ 채택 → N+1문제 발생
      • N+1문제를 해결하고자 ‘fetchJoin’ 도입 → @OneToMany관계를 가진 컬렉션을 두 개 이상 조회하려고 했을 때 ‘MultipleBagException’ 발생
    • 해결 방안
      • List를 Set으로 변환
        • 데이터의 순서가 중요한 경우나 항목 검색이 필요한 경우에는 적합하지 않을 수 있음
      • 쿼리를 분기하여 사용
        • 각각의 쿼리가 처리하는 데이터의 양이 줄어들어 DB의 부하를 줄일 수 있음
        • 각 쿼리가 독립적으로 실행되므로 하나의 쿼리에 문제가 발생해도 다른 쿼리에는 영향을 미치지 않음
    • 해결
      • 쿼리를 분기하여 사용하는 방법을 채택 → ‘MultipleBagException’ 문제 해결 → 전반적인 성능 최적화

일단 기억에 남는 질문들을 이렇게 정리해 보았다. 전체적으로 내가 사용한 기술에 이해도가 깊지 않아서 답변을 제대로 하지 못한 것같다. 짧은 기간내에 부족한 실력으로 여러가지 새로운 기술들을 사용하다보니 생긴 문제같다. 이제 시간이 많은 것은 아니지만 급하게 배워야하는 부분은 없으니 지금까지 사용한 기술들에 대한 이해도를 늘리고 새로운 기술을 사용할 때도 최대한 이해도를 높여서 사용해야 할 것 같다고 느꼈다.