비동기+싱글 스레드로 비즈니스 로직의 성능 4.5배 향상(평균 45초 -> 10초 단축)

[daadaadaah]

기존 방식

• 기존 방식은 비즈니스 로직인 Github 작업과 부가 기능인 Logging 작업이 동기 방식으로 동작해서, 부가 기능인 Logging 작업의 지연이 비즈니스 로직인 Github 작업에도 영향을 미쳤습니다.

해결 과정

• https://github.com/daadaadaah/review-study-app/issues/75 참고

성과

As-is

To-be

• 그 결과, 부가 기능인 Logging 작업의 지연이 비즈니스 로직의 수행 시간에 영향을 미치지 않게 되어, 비즈니스 로직의 성능 4.5배 향상(평균 45초 -> 10초로 단축)

[daadaadaah]

이 개선 사항은 동기 -> 비동기로 변경함으로서 성능 향상된걸 따로 뺀 것이다. 싱글 스레드로 안하면, 더 빠른 성능을 얻을 수 있지만, 데이터 일관성 때문에 싱글 스레드로 제한했다. 따라서, #75에 포함시키면, 싱글 스레드 내용을 추가해야 이 내용을 따로

[daadaadaah]

만약, #75 에 포함시킨다면, 다음과 같이 #75 를 변경할 것 같다.

2.@Async로 비즈니스 로직과 Logging 로직을 디커플링하여 장애 격리 및 성능 4.5배 향상 (평균 45초→10초 단축)

문제

• 기존 방식은 다음과 같은 문제가 있었습니다.

  1. 장애 전파 문제: 부가 기능인 Logging 로직에 문제가 발생할 경우, 비즈니스 로직인 Github 작업이 중단되었습니다.

  2. 핵심 로직 총 작업 수행시간 지연 문제: 부가 기능인 Logging 작업의 지연이 비즈니스 로직인 Github 작업의 지연을 초래했습니다.

해결 과정

1. (원인) 위와 같은 문제가 발생하는 원인은 관심사가 다른 두 로직간의 강한 결합력 때문이라고 생각했습니다. 왜냐하면, 비즈니스 로직인 Github 작업과 부가 기능 로직인 Google Sheets Logging 작업이 동기 방식으로 이루어지다 보니, 한 쪽의 문제가 다른 쪽에 영향을 주었기 때문입니다.
2. (해결책) 따라서, 이 강한 결합력을 끊어내기 위해, 비즈니스 로직인 Github 작업과 부가 기능 로직인 Google Sheets Logging 작업을 디커플링 시켜야겠다고 생각을 했고, @Async 어노테이션을 도입하여 비동기 방식으로 변경했습니다.

성과 -> 성능 향상은 싱글스레드 적용했을 때의 성능

• 그 결과, 각 로직이 독립적으로 실행될 수 있게 되었고, 다음과 같은 성과를 얻었습니다.

  1. 장애 격리를 통한 서버 안정성 향상: 부가 기능인 Logging 로직에 문제가 발생하더라도 비즈니스 로직인 Github 작업이 계속 진행되어 서버의 안정성이 향상되었습니다.

  2. 핵심 로직 총 작업 수행시간 4.5배 성능 향상: 비즈니스 로직 수행 시간이 평균 45초에서 10초로 단축되었으며, 부가 기능인 Logging 작업의 지연이 비즈니스 로직의 수행 시간에 영향을 미치지 않게 되었습니다.