3. AWS 서버리스의 Latency 문제 분석과 개선을 위한 Caching 전략

 

 

서버리스 컴퓨팅이 개발, 배포, 세분화된 비용 과금의 간편함으로 인해 주목을 받고 있지만, 데이터베이스, 파일 저장소, 또는 하나 이상의 서버리스 함수를 포함하는 복잡한 서비스를 구현 시 요청을 처리하는 데 있어서의 지연 시간 문제가 발생할 수 있습니다. 본 포스트에서는 지연 문제가 발생 할 수 있는 상황 예시와 이에 대한 해결책으로 Caching 기법을 소개하고자 합니다.

서버리스 아키텍처의 지연 문제

서버리스 컴퓨팅은 '서버리스 애플리케이션' 또는 'Function as a Service (FaaS)'의 개념을 통해 가능해졌으며, 이를 통해 애플리케이션 개발자와 소프트웨어 서비스 제공자는 서비스 수준 계약 협상 중에 서버 사양을 추정할 필요가 없고, 서비스를 클라우드 서비스 플랫폼에 안전하게 맡길 수 있습니다. 서버리스 플랫폼을 사용하면 애플리케이션 개발자는 서버 설정, 운영 체제 및 런타임 환경 설치 및 업데이트, 액세스 제어 정책 관리, 프로비저닝, 적절한 크기 조정, 확장성, 가용성 등에 시간을 소비하는 대신 핵심 제품과 비즈니스 로직에 집중할 수 있습니다. 그러나 서버리스 컴퓨팅은 상태를 유지하지 않으므로, 모든 요청에 대해 새로운 인스턴스를 생성해야 합니다. 이는 데이터베이스 연결이나 파일 시스템 접근과 같은 작업에 대한 지연 시간을 증가시킬 수 있습니다.

 

성능 지연 분석

Study 1. 단일 람다 함수 & 1개 DB를 포함하는 App

서버리스 함수가 상태를 유지하지 않으며 VM과 달리 데이터를 저장할 수 없기 때문에, 키-값 및 문서 데이터베이스인 Amazon DynamoDB를 사용했습니다. 서비스에 액세스하기 위해 API 게이트웨이를 통해 HTTP 요청을 수락할 수 있는 람다 함수 연결이 필요합니다.

이러한 설정의 성능을 VM 기반 접근법과 비교하기 위해, 동일한 기능을 가진 App을 Amazon EC2 서비스의 VM에서 구현하였습니다. 이를 구성하기 위해 Python Flask 웹 프레임워크와 MongoDB 데이터베이스를 사용했습니다. Flask 애플리케이션은 Nginx 웹 서버와 uWSGI 애플리케이션 서버를 통해 제공되는 구조이며, 이 모든 구성 요소는 하나의 vCPU와 1GB 메모리를 가진 동일한 VM에서 실행되었습니다.

 

서버리스 설정과 서버 기반 설정을 모두 다섯 개의 리전에서 배포 됐으며(뭄바이, 런던, 캘리포니아, 캐나다 센트럴, 싱가포르), 공정한 비교를 위해 엔드 유저로부터의 네트워크 품질 지연 요소를 제외하고, 서버리스 설정과 VM 기반 설정에 의해 사용자 요청(로드 테스트)을 처리하는 데 걸리는 시간 만을 고려하였습니다. 서버리스 설정에 대해 CloudWatch 로그를 사용하고, 서버 기반 설정에 대해 Nginx 로그를 사용하여 서비스의 응답 시간을 측정했습니다.

 

Study 2. 다수 람다 함수 & 데이터 분석 파이프라인을 포함하는 App

여러 개의 Lambda 함수가 포함되어 있으며, 이는 데이터 분석 파이프라인, 데이터 마이닝 워크플로우, 그리고 복잡한 단계와 프로세스를 포함하는 다른 애플리케이션을 대상으로 분석이 이루어졌습니다. 구성 요소는 Lambda 함수, DynamoDB, S3, Redis 입니다. 각각의 구성 요소 사이에 간선이 존재하면, 한 컴포넌트가 다른 컴포넌트를 동기적으로 호출하고 그 응답을 기다린다는 것을 의미합니다. 즉, 한 컴포넌트가 다른 컴포넌트에 의존한다는 것을 뜻합니다.

이러한 구성에서 Lambda 함수, 데이터베이스, 그리고 다른 서비스들은 대부분 다른 호스트에 배포되어 네트워크를 통해 통신해야 하며, 이로 인해 일정한 지연이 발생합니다. 이러한 지연은 각 컴포넌트 간에 발생하며, 애플리케이션의 전체 응답 시간에 심각한 캐스케이딩 효과를 미칩니다.

 

Study 2에서는 서버리스 컴포넌트들을 통한 네트워크 호출로 인한 오버헤드만을 모니터링하는 복잡한 서버리스 아키텍처의 지연을 비교했습니다. 이를 위해, 1에서 5까지의 Critical Path 길이를 가진 서버리스 아키텍처를 배포하고
분석했습니다.

 

성능 지연 분석 결과

1) Study 1 결과

서버리스 구조와 VM 기반 구조를 다섯 개의 리전에 배포하였고, 서버리스 아키텍처의 응답 시간이 VM 기반 구조보다 훨씬 높다는 것을 확인하였습니다. 높은 지연 시간은 람다 함수의 처리 시간이 아니라 데이터베이스 접근의 지연 때문이라는 분석 결과로 해석 될 수 있습니다.

 

1) Study 2 결과

Study 2에서 구성한 애플리케이션의 가장 작은 구조는 길이가 1인 것으로, 하나의 람다 함수와 데이터베이스(DynamoDB)만을 포함합니다. 길이가 2인 아키텍처의 경우, 두 개의 람다 함수와 마지막에 하나의 데이터베이스를 포함합니다.
이와 같은 방식으로 길이가 3, 4, 5인 경로를 배포하였습니다. 각 람다 함수는 계산이 거의 없으며 개별 응답 시간은 5ms 미만으로 나타났습니다. 이를 통해 서버리스 구성 요소를 네트워크 호출을 통해 연결하는 오버헤드만을 모니터링 할 수 있었습니다.

 

결과적으로, 시스템의 응답 시간은 서버리스 아키텍처가 확장됨에 따라 지속적으로 증가하였습니다. 시스템의 평균 지연 시간은 길이가 1인 경우의 50ms에서 길이가 5인 경우의 430ms로 7.6배 증가하였습니다.
따라서 서버리스 아키텍처가 확장됨에 따라 더 많은 지연 오버헤드가 발생하게 됩니다.

 

결과에서 알 수 있는 것처럼 서버리스 아키텍처가 확장됨에 따라, 네트워크 호출로 인한 오버헤드가 전체 응답 시간에 미치는 영향이 증가함을 확인할 수 있습니다. 이러한 결과는 서버리스 아키텍처의 성능 향상을 위한 캐싱 전략의 필요성을 강조합니다.

 

Caching 기법

서버리스 아키텍처의 지연 시간을 줄이기 위한 캐싱 전략으로 두 가지 기법을 고려할 수 있습니다.

1) 외부 캐시

AWS는 Redis와 Memcache와 같은 외부 캐시 서비스를 제공합니다. 이러한 외부 캐시는 계산/검색 시간을 줄일 수 있지만,
이들 캐시는 다른 컴포넌트와 마찬가지로 동일한 컨테이너나 호스트에 호스팅되지 않으므로 네트워크 호출의 오버헤드가 있습니다.

2) 내부 캐시

 

이 방법은 람다 컨테이너의 메모리 지속성과 자바스크립트의 비동기 함수 호출을 활용하여 네트워크 호출을 피하고 지연 시간을 더욱 줄이는 방법입니다.

람다 함수에서는 VM 기반과 달리 함수 내에 메모리 캐시 서비스를 설치할 수 없습니다. 대신 AWS 람다는 짧은 간격으로 연속적인 여러 요청 간에 람다 컨테이너의 메모리를 공유합니다. 이를 활용하여 내부 캐시를 구현할 수 있습니다. 캐시 업데이트에 대해서는 자바스크립트의 비동기 함수 호출을 사용합니다.

이 두 가지 캐싱 전략은 서버리스 아키텍처의 응답 시간을 크게 향상시킬 수 있습니다. 특히, 내부 캐시는 네트워크 호출을 피함으로써 응답 시간을 더욱 단축시킬 수 있습니다. 하지만 이러한 캐시 전략은 요청 빈도가 일정 수준 이하로 떨어지면 캐시가 냉각되어 전체 캐시가 무효화될 수 있다는 제약이 있습니다.

따라서 캐시를 유지하려면 요청 빈도가 특정 임계값 아래로 떨어지지 않아야 합니다.

 

Caching 적용 결과

Study 1의 애플리케이션을 바탕으로 Redis 기반 캐시와 인메모리 내부 캐싱을 구현하여 이들의 성능을 비교하였습니다.

 

 

1) 성능 비교

서버리스 아키텍처와 VM 기반 설정을 비교한 결과, 서버리스 아키텍처의 응답 시간이 VM 기반 설정보다 훨씬 높았습니다.
높은 지연 시간의 원인은 람다 함수의 처리 시간이 아니라 데이터베이스 접근의 지연 때문이었습니다. 서버리스 아키텍처에서 데이터베이스 접근 시간은  VM 기반 아키텍처의 약 14배였습니다.

 

2) 캐싱 전략

Redis 캐시를 사용하면 DynamoDB에서 직접 데이터를 가져오는 것에 비해 응답 시간이 향상됩니다.
인메모리 캐시는 응답 시간을 더욱 향상시킵니다. 히트 비율이 0.9인 인메모리 내부 캐시는 응답 시간을 약 45ms 줄입니다. 이는 실시간 애플리케이션에서 significant improvement에 해당 됩니다. 이 결과는 서버리스 아키텍처의 성능을 향상시키는 데 캐싱 전략이 중요한 역할을 할 수 있음을 보여줍니다.

 

결론

본 포스트에서 서버리스는 복잡한 서비스를 빠르게 개발하고 배포하는데 적합하지만, 서버리스 컴포넌트 간의 지연 시간이 중요한 문제로 작용하여 서비스의 품질이 저하될 수 있다는 점을 다뤘습니다.
이에 대한 해결책으로 응답 시간을 크게 향상시키는 캐싱 전략을 제안하고 비교하였습니다.
결과로서, 람다 세션 사이에서 warm state가 유지되고 여러 복제된 함수 컨테이너 인스턴스의 경우 일관성이 유지되는 인메모리 캐싱 시스템이 최적의 대안이 될 수 있음을 증명하였습니다.