일평균 700건 이상의 요청에서 "세션 점유 중" 오류를 10건 이하로

회사에서 홈택스 데이터를 스크래핑하는 일을 맡았다. 사용자에게 제공해야 하는 세금 정보는 크게 두 가지, **세와 **세. 문제는 이 두 스크래핑이 동시에 실행되면 서로의 세션을 덮어쓰는 문제가 발생한다는 점이었다. 세션 충돌은 곧 사용자 경험의 악화로 이어지고, 안정성이 생명인 서비스에서는 반드시 해결해야 할 사안이었다.

[Z5004]: [LOGIN-999] 통합인증(중복 로그인) 오류입니다.

 

그래서 선택한 해법이 Redis 기반의 분산락이었다. 우리 회사 인프라는 AWS의 관리형 ElastiCache를 사용하고 있고, Latency 측면에서도 EKS 내에서의 접근이라 꽤 빠른 편이었다.

 

처음에는 Redis I/O 비용을 줄이자는 생각으로. 락 획득 여부를 Redis에 일일이 물어보는 대신, 로컬 메모리에서 상태를 관리하면 더 효율적일 거라고 생각했다. 실제로 응답 속도는 빨라졌고, 서비스 초반엔 큰 문제가 없어 보였다. 실제로 시스템을 모니터링하고 있었는데 락 평균 유지시간이 대체로 2분에서 4분정도로 예상하는 범위안에 들어오고 있었다.

 

그런데 이상한 일이 생겼다. 모니터링 시스템에서는 락이 4분 이상 점유되는 경우가 거의 없었는데, 애플리케이션 로그에서는 특정 요청들이 계속 sleeping 상태로 대기하고 있는 것이었다. 

황급히 다시 그라파나를 확인했었지만 락 대기자가 많지 않았었고, 상당히 모순적인 로그였다.  중성의 원인은 Redis가 아니었다. 진짜 문제는 우리가 락 상태를 Redis와 통신하지 않고, 애플리케이션 내 로컬 해시맵으로 관리하고 있었던 방식에 있었다.  락을 잡지 못했을 때도 finally 블럭에서 로컬 락을 해제하지 않고 남겨둔 코드가 누적되면서, 가짜로 "락을 점유 중"인 상태가 계속 유지되고 있었던 것이다. 이 상태에서 들어오는 요청은 모두 대기 상태에 들어가며, 마치 실제 락을 점유 중인 것처럼 오인하게 만들었다.

 

문제를 해결하기 위해 로컬 락 관리 로직을 전면 재정비했다. 락 획득에 실패했을 경우에도 반드시 finally 블럭에서 로컬 락을 정리하도록 수정했고, 락이 점유된 시간과 재시도 횟수에 대한 로그를 추가로 남기도록 했다.

  private async lockAndScrapeCompanyData(
    company: Company, userCache:boolean
  ): Promise<Record<string, any> | CompanyLockAcquireFailException> {
    await this.companyRedisLockService.acquireLock(company);
    try{
      const scraped = await this.scrapeLambdaHometaxData(company, {
        useCache: userCache,
      });
      return scraped;
    }finally {
      await this.companyRedisLockService.releaseLock(company);
    }
  }

 

그 결과는 숫자로도 드러났다. 기존에는 하루 평균 700건 이상의 요청에서 "세션 점유 중" 오류가 발생했는데, 수정 이후에는 10건 이하로 급감했다.