트러블슈팅

https://github.com/ALLREVA/Allreva_BE 최근에 진행한 프로젝트이다 주제는 '공연 차대절 플랫폼' 으로 KOPIS 에서 공연 정보를 받아와서 해당 공연의 정보를 조회할 수 있고, 특정 공연의 차대절 및 수요조사 글을 등록할 수 있다 나는 트래픽이 많이 몰릴 것으로 예상되며 변경이 흔치 않은 '공연 상세 조회'에 캐싱을 도입하고자 하였다     ALLREVA 프로젝트에서 '공연' 도메인의 특성우선 캐싱 전략을 세우기 이전에 해당 프로젝트에서 캐싱을 적용하려고 하는 도메인의 특성이 무엇인지 살펴봐야한다 ALLREVA 프로젝트에서 내가 정리한 공연 도메인의 제일 중요한 특성들은 다음과 같다 정보의 갱신이 매우 드물게 발생한다우리는 KOPIS 로 '하루에 한 번' 특정 시각에 공연 데..

초기 요구사항최종 프로젝트에서 검색을 위해 MySQL 과 ElasticSearch 의 데이터를 sync 해야했다 이를 위해 적용할 수 있었던 기술은1. Debezium 의 CDC 2. Kafka 로 원자적 이벤트 발행 가 있었는데 우리는 그중에서 2번 'Kafka 로 원자적 이벤트 발행' 을 선택하였다 CDC 기술은 스키마에 의존적인데 프로젝트가 진행되면서 컬럼이 바뀔 가능성이 매우 높다고 생각하였다또한 실시간성 역시 필요하지 않다고 판단하였으며 비용적인 부분또한 문제가 되었다 따라서 우리는 Kafka 로 원자적 이벤트 발행을 하기 위해 Polling Publisher Pattern 을 적용하였다  카프카를 걷어내야만 했던 이유하지만 배포를 하면서 Kafka 가 자꾸 죽어버리는 문제가 발생하였다.또한 K..

트랜잭션 범위에 대한 고민 트랜잭션의 범위가 넓으면 편리할 수 있으나 읽기 성능이 저하되고, 데드락 발생 가능성이 높아진다.모든 프로젝트들이 마찬가지이겠으나 특히 티켓팅처럼 한순간에 많은 요청들이 몰리는 경우, 트랜잭션의 범위가 너무 넓다면 곤란하다. 그렇다면 트랜잭션의 범위가 지나치게 짧다면 어떨까? DB 를 사용하는 모든 상황에서 트랜잭션을 시작하고 끝맺는다면 역시 성능이 좋지 않을 것이다. 트랜잭션의 비용은 생각보다 크다. 그렇다면 적정수준이 어느정도일까? 소거법으로 트랜잭션에서 제거하는게 확실히 좋은 상황먼저 지워보자.(트랜잭션이 꼭 필요한 상황과 꼭 제거해야 하는 상황을 고려해보자) 토스 API 는 트랜잭션에서 제외하자우리 프로젝트에서 결제를 담당하고있는 토스 API..트랜잭션에서 제외하였을 때..