To your route, 투룻

개발부터 운영까지 폭넓은 기술 스택을 경험했습니다. Github Actions를 활용한 CI/CD 파이프라인 구축, 서버와 DB 다중화 구현, 모니터링 대시보드 개발, JMeter를 통한 성능 테스트 수행, 쿼리 최적화 등 다양한 기술적 도전과 트러블 슈팅을 수행했습니다.

협업 측면에서는 애자일을 실천했습니다. 데일리 스크럼으로 팀 진행 상황을 공유하고, 명확한 팀 컨벤션과 그라운드 룰을 수립하여 효율적인 협업 환경을 조성했습니다. 페어 프로그래밍과 코드 리뷰를 통해 코드 품질을 높이고, 테크 로그 작성으로 팀 내 지식 공유를 활성화했습니다. 스프린트 단위의 개발-피드백 사이클을 통해 지속적인 제품 개선을 이뤄냈습니다.

서비스 링크

https://www.touroot.kr/

깃허브 레포지토리

https://github.com/woowacourse-teams/2024-touroot

팀 구성

BE 5명
FE 3명

프로젝트 진행 내용

1. 역정규화로 동시성 문제 해결

문제 상황

여행기 작성 시 여행기 장소가 중복으로 저장되는 동시성 문제 발생
- 여행기 장소는 여러 여행기에서 공유하는 자원이므로 정규화되어 place 테이블에 저장됨
- 사용자가 작성한 여행기의 장소가 place 테이블에 없을 경우 이를 저장 후 반환하는 로직에서 동시성 문제가 발생

문제가 발생한 코드

public Place getPlace(String name, String latitude, String longitude) {
    return placeRepository.findByNameAndLatitudeAndLongitude(name, latitude, longitude)
            .orElseGet(() -> placeRepository.save(new Place(name, latitude, longitude)));
}

여러 트랜잭션이 동시에 find 호출해서 빈 값을 받고, 이에 따라 save를 여러 번 호출해 여행기 장소가 중복 저장됨

해결

여행기 장소 조회 시 S/X 락 사용
- 갭 락의 공유로 인한 데드락 발생
  - 해당 컬럼에 인덱스를 설정하지 않으면 데드락 문제가 해결되지만, 인덱스를 설정하지 못하는 것은 큰 단점이라 판단함
unique 제약 조건 + 전체 재시도
- 여행기 작성에 이미지 처리로 인한 S3 관련 로직도 섞여 있기 때문에 전체 재시도 시 성능 저하 발생
unique 제약 조건 + REQUIRES_NEW 로 부분 재시도
- 여행기 장소를 저장하는 부분만 재시도 하기 때문에 성능 문제 개선
- 코드 복잡성 증가 및 REQUIRES_NEW 로 인한 인지 비용 발생
- 커넥션 풀 부족으로 인한 데드락이 발생할 수 있기 때문에 히카리 풀 사이즈를 세밀하게 조정해야 함
READ_UNCOMMITED 와 함께 어플리케이션 단에서 synchronized 사용
- 낮은 격리 수준으로 데이터 정합성이 깨질 수 있음
- synchronized는 단일 서버에서만 유효하며 다중 서버 환경에서 사용 어려움
INSERT IGNORE 사용
- 데이터가 존재하더라도 매번 INSERT IGNORE 를 먼저 수행해야 함
  - REPEATABLE_READ 에서 조회 → 저장 → 조회 시 두번째 조회에서도 빈 값이 반환될 수 있기 때문
- INSERT IGNORE 는 데이터 중복 시 PK 인덱스에 supremum pseudo-record 락이 걸려 동시성 성능이 저하됨
  - Auto Increment 에서 새로운 데이터의 삽입을 막기 때문
- 또한 중복 에러 뿐만 아니라 다른 에러도 무시하기 때문에 제약 조건을 위반하는 데이터가 삽입될 위험성 존재
place 테이블 역정규화 (최종 선택)
- 현재 비즈니스에서는 역정규화로 인한 이상 현상이 발생하지 않을 것으로 판단
  - 여행기는 과거를 기록하는 데이터로, 장소가 변경되거나 삭제되더라도 영향 없음
- place 테이블이 별도의 비즈니스 요구사항에서 활용되지 않음
  - 불확실한 미래 요구사항에 대비한 정규화는 시스템의 복잡성만 증가시킨다고 판단