모놀리식 아키텍처에서 이벤트 기반으로 비즈니스 로직의 원자성 확보하기 (2)
·
Project
이번 포스팅은 이전 포스팅에 이어서 코드로 구현하는 과정을 담았습니다.구현 목표모놀리식 아키텍처에서 MSA로 전환하는 작업의 초석이 되도록 서비스 간 결합도를 낮추기외부 API 호출 응답을 받으면 이벤트를 발행하는 방식으로 서비스 간 결합도를 낮춥니다.`편지 서비스`는 `처리율 제한기 서비스`에 대한 의존성을 제거하고, 편지를 저장하는 책임만 집니다.`답장 서비스`는 `외부 API 호출 서비스`에 대한 의존성을 제거해 트랜잭션에서 분리하고, 답장을 저장하는 책임만 집니다.다만, 데이터베이스에 저장하는 로직은 하나의 트랜잭션에서 처리할 수 있도록 상위 계층에서 편지와 답장을 저장하도록 설계합니다. ⇒ 이벤트 발행의 주체를 퍼사드 서비스로 구현합니다.이벤트에 상태(Status)를 추적할 수 있도록 하기Spr..
모놀리식 아키텍처에서 이벤트 기반으로 비즈니스 로직의 원자성 확보하기 (1)
·
Project
이 포스팅에서는 프로젝트에서 기존 비즈니스 로직의 문제점을 확인하고, Spring Events를 활용해 비즈니스 로직을 원자적으로 처리하는 내용을 다룹니다. 제목에 "모놀리식 아키텍처"를 붙인 이유는 MVP 개발부터 채택한 모놀리식 아키텍처를 그대로 유지하면서 최소한의 변경으로 문제를 해결하는 과정을 강조하기 위함입니다.현재 서비스 규모가 작고, 이용자 수가 많지 않은 상황에서 오버 엔지니어링을 하지 않고 개선해 보겠습니다.문제의 발단: 클로바 스튜디오 서비스의 장애1월 13일 오후 9시 45분경 클로바 스튜디오에 장애가 발생했습니다.우리 서비스의 첫 MVP였던 달토의 답장 서비스는 클로바 스튜디오에 의존하고 있었는데, 팀에서는 10시 30분이 지나서야 장애 발생을 인지했습니다. 문제 발단은 클로바 스튜..
[올려올려 라디오] 신규 분석 기능 성능 테스트 (3)
·
Project
이전 포스팅에서 톰캣 스레드 풀을 늘리기 전에, 병목 지점은 데이터베이스 커넥션을 획득하는 부분에 있다는 것을 파악했었습니다.이번 포스팅에서는 데이터베이스 커넥션 풀의 크기를 조절과 캐시를 적용하는 각각의 과정을 담았습니다.데이터베이스 커넥션 풀 크기 조절하기HikariCP 설정 값 변경하기커넥션 풀 크기를 조절하는 방법은 이미지처럼 `application.yml`에서 간단하게 설정할 수 있습니다.hikariCP 설정 옵션에 대한 설명입니다.maximum-pool-size: 커넥션 풀의 최대 크기를 지정합니다. 커넥션 풀 크기만큼 커넥션이 담기면 idle 상태의 커넥션은 존재하지 않게 된다고 합니다.minimum-idle(default: same as maximumPoolSize): 커넥션 풀에 idle..
[올려올려 라디오] 신규 분석 기능 성능 테스트 (2)
·
Project
이번 포스팅에선 사용자 경험 향상을 위해 응답 속도와 TPS를 높일 수 있는 방법을 알아보겠습니다.응답 속도가 느린 이유이전의 부하 테스트 결과 지표에서 필요한 부분을 가져왔습니다.데일리 리포트와 위클리 리포트 각 테이블당 300만 건의 레코드가 들어있습니다.부하 테스트 결과 (트래픽 10배 늘었을 때를 가정)라벨표본 수평균최소값최대값표준편차오류 %처리량생성 가능 일자 조회(데일리 리포트)50003511750048.1396.340%423.51347생성 가능 일자 조회(위클리 리포트)500034832748319.76100.000%421.86973데일리 리포트 조회500035932757940.92100.000%427.31390총계150003531757938.5098.780%283.02955 평균 응답 속도는..
[올려올려 라디오] 신규 분석 기능 성능 테스트 (1)
·
Project
이번 포스팅에선 서비스 사용자 수를 늘리기 위해 새로 개발한 분석 기능에 대한 성능 테스트(Performance Testing) 이야기를 담아보려 합니다. 유저가 작성한 글을 기반으로 하는 신규 기능은 3가지입니다.데일리 리포트 또는 위클리 리포트를 받아볼 수 있는 날짜들을 조회하는 API리포트를 생성 요청하는 API날짜별로 생성된 리포트들을 조회하는 API이 기능들 가운데 외부 API를 사용하는 2번을 제외한 1번과 3번 조회 관련 API가 많이 사용될 것으로 예상됩니다.그래서 조회 API들에 대해 서비스가 예상되는 트래픽에서 얼마나 빠르고 안정적으로 응답하는지, 짧은 시간에 급격하게 몰리는 트래픽을 얼마나 견딜 수 있는지를 검증하기 위해 성능 테스트를 수행할 필요가 있습니다.어떤 테스트를 할 것인가?..