희상

• 카카오 로그인
• JWT 토큰 로직
  • Redis RT 관리
  • 블랙리스트
  • RTR 기법 도입
  • Cookie secure, HTTPOnly
• 장소 검색
  • 네이버 지도, 카카오 맵 API
• 대중교통 경로 검색
  • ODSay API
• ODSay API 사용 불가능 시 서비스 사용 불가한 상황 방지
  • 사용자가 사용하는 route의 경우 DB에 저장하고
  • ODSay API 사용 불가 시
• RabbitMQ를 통한 지연 메시지 발급
  • 3시간 뒤 사용자 상태 변경
  • 2시간 반 뒤 웹 푸시 알림(데모데이때는 10초)
  • 기존에는 TaskScheduler를 사용했으나 이는 메모리에 저장하는 방식이고 서버 장애 시 이벤트 유실 방지를 위해 RabbitMQ로 변경
• 사용자 위치 추적
  • Redis Geospatial 사용 저장
  • 5분에 한번씩 폴링 방식으로 사용자 위치 저장
• 성능 테스트
  • 할 일의 경우 900만개의 더미데이터
  • MySQL 쿼리 실행 계획 분석
  • 복합 인덱스, 커버링 인덱스 설정
  • HikariCP 최적화
  • InnoDBPool_SIze 튜닝

현원

• 비즈니스 로직(할일 관리)을 처리하기 위한 ERD 설계

  • 할 일 추가 체크 표시를 위한 ParentTodo 연관관계 자기 참조 관계(웹 뷰)

    • 또 다른 테이블을 만들지 않았던 이유(성능 체크) - 조연 연산 오버헤드를 막기 위해서 또 다른 테이블을 만들지 않았습니다.

  • 사용자 편의성을 위해 오늘/내일 데이터 동기화(스케줄 컬럼 값) → 데이터 삭제 문제 발생 →테이블 분리(스케줄 테이블 생성)

  • 결과적으로 많은 비즈니스 로직이 담긴 Todo과 Schedule 두가지 테이블로 해결(명료하게 설명)

    • todo 데이터를 조회하기 위해서 todolist 와 불가피한 조인이 발생을 하는데요. 이를 해결하고자 todo id 가 todolist 의 속성들을 결정할 수 있는지를 확인한 경우 todolist의 속성들이 todo id에 함수적으로 종속된다고 판단을 해서 todo 테이블로 병합을 했습니다. 병합한 이후에 todo를 삭제했을 때 date 값도 같이 삭제되어서 의도하지 않은 동작이 일어났습니다. 삭제 이상 문제인 것이죠. 할 일 과 스케줄의 라이프사이클을 분리하기 위하여 date 컬럼을 갖는 별도의 스케줄 테이블을 생성했습니다.

  • 할 일 타입별로 서로 다른 비즈니스 로직을 처리하기 위한 전략 패턴 사용

    여러 타입의 할 일이 존재하기 때문에 할 일 타입마다 같은 기능인데 로직이 달라져 서비스 코드가 무거워지는 문제가 발생을 했고 전략 패턴을 도입해서 클라이언트 코드(컨트롤러 계층)가 실행 중에 구현체를 결정 하도록 했습니다. 전략 패턴은 여러 알고리즘이나 로직을 캡슐화하고, 클라이언트가 실행 중에 구현체를 선택하는 디자인 패턴입니다.