문제

Google Sheets에 로그 데이터를 저장하는데, 일부 데이터가 누락되는 문제가 있었습니다.
또한, 호출 순서대로 데이터가 저장되지 않아서, 데이터를 검토할 때에는 추가적인 작업(예: 정렬)이 필요한 번거로움이 있었습니다.

해결 과정

1. 재현

Google Sheets에서 왜 이런 문제가 발생하는지 파악하기 위해 다음과 같이 재현봤습니다.

https://github.com/user-attachments/assets/76f2e9bf-17cc-4486-93e4-f1985a4a443f

2. 원인 파악

영상에서 보여지는 것처럼, Google Sheets에 동일한 행에 데이터가 덮어쓰기가 되면서 데이터 누락이 발생한 것이었습니다.
Google Sheets에 로그 저장 로직의 경우, @Async을 사용하여 비동기로 실행되는데, 이 @Async의 기본 동작 방식은 멀티스레드 방식으로 동작합니다.
그로 인해 Google Sheets API에 여러 스레드가 동시에 접근하면서, race condition 발생하여, 데이터가 덮어씌워지는 동시성 문제가 발생한 것이었습니다.

3. 다양한 해결 방법 모색

이를 해결하기 위해, 크게 3가지 방법을 생각했습니다.

항목	방법 1: 싱글 스레드	방법 2: Synchronized	방법 3: Lock
장점	1. 모든 작업이 단일 스레드에서 순차적으로 수행되기 때문에, 동시성 문제가 발생하지 않으며, 데이터의 일관성과 호출 순서가 보장됩니다. 2. 동기화와 관련된 복잡한 로직이 필요 없으므로, 코드가 단순하고 구현이 쉽습니다. 3. 문제 발생 시 재현이 쉬워 디버깅과 유지보수가 용이합니다. 4. 데드락 발생 가능성이 없으므로, 동시성 관련 오류 발생 확률이 낮습니다.	1. `synchronized` 방식은 비교적 간단한 동기화 방법으로, 자원의 동시 접근을 제어할 수 있습니다. 2. Lock을 사용하는 방식보다 구현이 단순하며, 기본적으로 자원 보호를 쉽게 구현할 수 있습니다. 3. 간단한 동기화가 필요한 경우 효율적일 수 있습니다.	1. Lock을 사용하면 세밀한 동시성 제어가 가능하며, 자원의 선택적 잠금과 해제가 가능합니다. 2. 동기화 블록보다 더 유연하고 높은 성능을 제공할 수 있습니다. 3. 특정 상황에서는 `synchronized` 방식보다 효율적일 수 있으며, 공정성(Fairness)을 제공하는 Lock도 사용 가능합니다. 4. 복잡한 동시성 제어가 필요한 경우, 더 강력한 제어 메커니즘을 제공합니다.
단점	1. 모든 작업이 순차적으로 처리되기 때문에 병렬 처리가 불가능하여, 다중 작업을 동시에 처리해야 하는 상황에서 성능이 저하될 수 있습니다. 2. CPU의 멀티코어 활용이 어렵고, 작업량이 많아질수록 성능 저하가 심각할 수 있습니다.	1. `synchronized` 블록 자체는 호출 순서를 보장하지 않습니다. 2. 동시성 문제를 완전히 해결하기 위해서는 추가적인 동기화 작업이 필요할 수 있어서, 방법 1보다 구현이 복잡하다. 3. 데드락이 발생할 수 있으며, 문제 발생 시 재현이 어렵습니다.	1. 호출 순서를 직접적으로 보장하지 않습니다. 2. 방법 1와 2이 비해 구현이 가장 복잡합니다. 3. 문제 발생 시 재현이 어렵습니다. 4. Lock을 잘못 관리하면 데드락이 발생할 수 있습니다.

4. 최종 해결책 선택

그 중 최종적으로 방법 1. 싱글 스레드을 선택하였습니다.

(1) 로그 저장 로직의 특징

로그 저장 로직의 경우, 시스템의 상태와 동작을 기록하는 중요한 자료로서 분석, 디버깅, 모니터링 등 다양한 용도로 사용됩니다.
만약, 데이터가 정확하게 저장되지 않으면, 문제 발생 시 원인 분석이 어려워질 수 있습니다.
또한, 로그 데이터가 호출된 순서대로 저장되지 않으면, 후속 데이터 검토 및 분석 작업이 복잡해집니다. 데이터가 저장된 순서가 어긋나면, 이를 다시 정렬하거나 필터링하는 추가 작업이 필요하게 되어 번거로움이 발생하기 때문입니다.
따라서, 로그 저장 로직의 경우, 빠른 처리 속도보다 1) 데이터가 정확히 저장되는 것과 2) 호출 순서대로 저장되는 것이 중요하다고 생각했습니다.

(2) 싱글 스레드가 적합하다고 생각한 이유

이에, 병렬 처리 작업이 불가능하여 성능이 다른 방법에 비해 부족하더라도, 데이터 일관성과 호출 순서를 보장해주고, 구현이 간단하며, 에측가능성이 높아 유지보수하기 쉬운 방법 1.싱글 스레드 방식을 선택했습니다.
방법 2. Synchronized 방식과 방법 3. Lock 방식은 둘다 호출 순서가 보장되지 않는 점, 구현이 방법 1에 비해 복잡하다는 점, 문제 발생시 재현이 어렵다는 점 때문에, 지금 상황에 적절하지 않다고 생각했습니다.
또한, 데이터의 양이 많을 경우, 싱글 스레드 방식이 적절하지 않을 수 있으나, 현재 데이터 양이 많지도 않고, 스터디 특성상 최대 스터디원이 10명까지만 모집되므로, 앞으로도 대량의 데이터 처리를 필요한 상황이 아니므로, 병럴 처리 작업이 불가능한 점이 단점이라고 생각하지 않았습니다.

(3) 싱글 스레드 구현

다음과 같이, ThreadPoolTaskExecutor를 활용하여 싱글 스레드 풀을 만들고, 로그 저장 작업이 이 스레드에서 순차적으로 처리되도록 설정하였습니다.

@Configuration
public class AsyncConfig implements AsyncConfigurer {

    @Bean(name = "logSaveHandlerExecutor")
    public TaskExecutor logSaveHandlerExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(1); // 순서 보장하기 위해서 1개
        executor.setMaxPoolSize(1);
        executor.setThreadNamePrefix("LogSaveHandler-"); // 스레드 이름 접두사
        executor.initialize();
        return executor;
    }
}

위에서 정의한 logSaveHandlerExecutor를 사용하여 로그 저장 메서드들이 모두 동일한 스레드에서 실행되도록 하였습니다.

@Service
public class LogDirectSaveGoogleSheetsService implements LogService {
     //... 생략
    @Async("logSaveHandlerExecutor") 
    public void saveJobLog(SaveJobLogDto saveJobLogDto) {
         //... 생략
    }

    @Async("logSaveHandlerExecutor")
    public void saveStepLog(SaveStepLogDto saveStepLogDto) {
          //... 생략
    }

    @Async("logSaveHandlerExecutor")
    public void saveTaskLog(SaveTaskLogDto saveTaskLogDto) {
              //... 생략    
     }
}

성과

https://github.com/user-attachments/assets/adf17393-bf23-4562-9357-f56b56997817

그 결과, 기존 방식보다 로그 저장 소요시간이 2배로 늘어났지만(평균 10초 -> 20초), 다음과 같은 성과를 얻었습니다.

1. 데이터 일관성 확보

싱글 스레드 방식을 도입함으로써, 데이터가 정확히 저장되었으며, 데이터 누락 문제를 해결할 수 있었습니다.

2. 호출 순서 유지

각 로그 항목이 호출 순서가 보장되어 순서대로 저장되었습니다.
이로 인해 추가적인 정렬 작업이 필요 없어졌으며, 데이터 검토와 분석 과정이 수월해졌습니다.

3. 구현의 용이 및 예측 가능성

코드가 간단해졌고, 동기화 관련 복잡한 문제를 신경 쓰지 않아도 되었습니다.
또한, 동시성 관련 문제 없이 예측 가능한 동작을 보장할 수 있었습니다.
이로 인해 유지보수와 디버깅이 쉬워졌고, 운영 및 관리가 용이해졌습니다.

참고용으로 추후에 삭제 필요!

싱글 스레드, Synchronized 방식, Lock 방식은 각각 서로 다른 동시성 제어 방법을 제공하며, 각 방식은 고유한 장단점을 가지고 있습니다. 아래에서 이 세 가지 방식의 상대적인 장단점을 비교해 보겠습니다.

1. 싱글 스레드 방식

장점:

간단하고 안전: 코드가 순차적으로 실행되기 때문에, 동기화 문제, 데드락, 레이스 컨디션과 같은 복잡한 오류가 발생하지 않습니다.
예측 가능성: 실행 흐름이 명확하고 예측 가능하여, 오류를 추적하고 수정하기 쉽습니다.
디버깅 용이: 스레드 간의 상호작용이 없으므로, 디버깅과 유지보수가 훨씬 간단합니다.
낮은 리소스 사용: 스레드를 생성하고 관리하는 데 추가적인 리소스가 필요하지 않아, 리소스 소비가 적습니다.

단점:

성능 제한: 병렬 처리가 불가능하므로, 여러 작업을 동시에 처리해야 하는 상황에서 성능이 낮을 수 있습니다. CPU의 멀티코어 활용이 어려움.
확장성 부족: 작업량이 많아지거나, 다중 작업 처리가 필요한 경우 성능이 급격히 저하될 수 있습니다.

2. Synchronized 방식

장점:

구현의 간편함: 자바에서 제공하는 기본 동기화 메커니즘으로, 간단한 키워드(synchronized)를 사용하여 동기화를 쉽게 구현할 수 있습니다.
자동 릴리스: 블록이 끝나면 락이 자동으로 해제되기 때문에, 락 해제를 잊는 문제를 피할 수 있습니다.
적절한 성능: 자바의 최신 버전에서는 Synchronized의 성능이 많이 개선되어, 대부분의 상황에서 충분히 효율적입니다.

단점:

데드락 위험: 잘못된 동기화 구조로 인해 데드락이 발생할 수 있습니다.
제한된 제어: 락을 명시적으로 제어할 수 없기 때문에, 락의 상태를 확인하거나, 타임아웃을 설정하는 등의 세밀한 제어가 어렵습니다.
경합 비용: 여러 스레드가 동시에 Synchronized 블록에 접근하려고 할 때, 경합으로 인해 성능이 저하될 수 있습니다.

3. Lock 방식

장점:

정교한 제어: 락의 상태를 명시적으로 제어할 수 있으며, tryLock() 등을 통해 락을 획득할 수 없는 경우 대기하지 않고 다른 작업을 수행할 수 있습니다.
데드락 방지 기능: 타임아웃을 설정하여 데드락을 피할 수 있는 기능을 제공합니다.
재진입 가능성: ReentrantLock과 같은 락을 사용하면, 동일한 스레드가 동일한 락을 여러 번 획득할 수 있습니다.

단점:

구현 복잡성: 락을 명시적으로 획득하고 해제해야 하므로, 구현이 복잡해질 수 있으며, 락 해제를 깜빡하면 심각한 오류가 발생할 수 있습니다.
오버헤드: 락을 수동으로 관리해야 하므로, 잘못된 사용으로 인한 오버헤드가 발생할 수 있습니다.
데드락 가능성: 잘못된 락 순서로 인해 여전히 데드락이 발생할 수 있습니다.

결론: 상황에 따른 선택

싱글 스레드 방식: 데이터의 정확성, 안정성, 예측 가능성이 중요하고, 성능보다는 코드의 간결함과 안전성이 우선시되는 경우 적합합니다. 특히 병렬 처리가 필요 없는 작업에서 유리합니다.
Synchronized 방식: 동시성이 필요한 간단한 애플리케이션에서, 비교적 적은 복잡성으로 안전한 동기화를 제공할 수 있습니다. 자바에서 쉽게 사용할 수 있는 기본 동기화 방식으로, 많은 경우에 적절한 성능과 안정성을 제공합니다.
Lock 방식: 고성능이 요구되거나, 복잡한 동기화 제어가 필요한 경우 유리합니다. 정확한 락 관리가 필요하거나, 데드락 방지와 같은 고급 기능이 필요한 상황에서 적합합니다. 그러나 구현의 복잡성이 더해지는 점을 고려해야 합니다.

이러한 장단점을 바탕으로, 시스템의 요구 사항에 맞춰 적절한 동시성 제어 방법을 선택하는 것이 중요합니다.

daadaadaah / review-study-app

멀티 스레드 -> 싱글 스레드로 동시성 문제 해결 #76

문제