[Netflix] EVCache - Intro
이번 포스팅에서는 Netflix에서 오래전에 개발한 EVCache에 대해 조금 자세히 알아보려고 한다.
EVCache는 이전 포스팅 (https://timewizhan.tistory.com/entry/Netflix-Distributed-Inmemory-Datastore?category=1026894)에서 간략히 살펴보았듯이 클라우드 환경에서 사용하는 Memcache 기반의 분산 캐시이다. 물론 캐시를 사용하는 목적 자체가 자주 사용하는 데이터를 더 빠르게 가져오는 용도이지만 Netflix에서는 어떤 배경을 가지고 개발을 시작했는지 알아보도록 하자.
Netflix 내부적으로 아래와 같은 요구 사항이 존재했다.
- 빠른 응답 시간 필요
- 세션 기반 앱을 Stateless로 저장 필요
- NoSQL 사용 필요
그래서 간단하게 (물론 내부적으로는 여러 고민이 필요 했을 수도 있다.) 이 요구 사항을 해결하기 위해 캐시를 적용하기로 했다. 사실 캐시 적용을 통해 데이터 접근 시간이 확연히 줄어 들고 더욱이 사용자가 급격하게 몰려도 트래픽을 완화시킬 수 있기 때문에 가장 안성맞춤의 선택이기도 하다
EVCache의 특징을 살펴보면 아래와 같다. (정확한 전달을 위해 원어를 그대로 사용하였다.)
- Elasticity and deployment ease
내부 용량(Capacity)를 모니터링하기 때문에 빠르게 용량을 조절할 수 있다. 더욱이 데이터를 예열(Warm-up) 하여 Cache hit 비율을 관리 할 수 있다.
- Latency
일반적으로 Latency는 밀리세컨즈(Milliseconds) 정도이다. (같은 AWS zone에 있으면 읽기 성능은 동일하게 지원한다.)
- Inconsistency
EVCache의 설계상 가장 중점인 부부은 속도이다. 때문에 데이터의 불일치(Inconsistency)는 어플리케이션에서 처리한다.
내부적으로는 짧은 주기의 데이터는 불일치를 허용하지만 시간 만료로 자연스레 삭제하고 오랫동안 유지해야하는 데이터는 consistency checker를 구현하여 관리한다.
- Availablity
EVCache는 consistent hashin 및 여러개의 AZ를 사용하고 있기 때문에 특정 지역의 인스턴스가 내려가도 cache miss가 최소화 된다.
- Total Cost of operations
전체적으로 EVCache의 비용은 매우 낮은 편이다.
그림 1. EVCache Server
위의 그림은 인스턴스 위에 올려져있는 EVCache 서버의 구조이다. 내부 구성이 단촐하긴하지만 하는 역할을 보면 아래와 같다.
- Java Sidecar : Discovery Service와 통신하는 앱
- Monitoring Apps : 내부 상태를 모니터링하고 리포팅하는 앱
- (memcached는 잘 알려져 있는 캐시 종류 중 하나라서 제외한다.)
이렇듯 EVCache 서버는 각각의 인스턴스에서 캐시를 효율적으로 관리하고 동작시키기 위해 그림 1과 같이 구성하였다.
반면에 클라이언트는 CRUD 쿼리를 서버에 전달하고 사용자가 요청하는 데이터가 효율적으로 캐시에 저장될 수 있도록 서버를 찾는 역할도 한다.
그럼 아래에서 실제 단일 환경 및 멀티 환경에서 서버와 클라이언트가 어떤식으로 동작하는지 확인해 보도록 하자.
그림 2. Single Zone Deployment
1. 인스턴스에 EVCache 서버가 올라갈 때, name service를 등록한다.
2. 클라이언트가 등록된 서비스를 확인하고 connection을 맺는다.
3. 서버에 CRUD 쿼리를 보낸다.
(클라이언트가 CRUD 쿼리를 보내는 서버는 consistent hashing에 의하여 데이터가 sharding된 서버이다. 해당 서버는 초기에 클라이언트가 connection을 맺은 서버 중 하나이다.)
그림 3. Multi Zone Deployment
멀티 환경이라고 해도 결국 단일 환경과 큰 차이는 없다.
다만 단일 환경은 AWS Zone 하나에서 적절한 서버를 찾는 것이지만 멀티 환경은 다른 AWS Zone을 사용한다.
(EVCache는 Read는 같은 AWS Zone을 사용하지만 Write, Update, Delete는 기존의 데이터가 다른 AWS Zone에 복제되기 때문에 다른 AWS Zone을 사용한다.)
여기까지 EVCache를 대략적으로 알아보았다.
Netflix에서는 이렇게 설계하여 구축한 EVCache를 25가지 이상의 use cace에 적용하였다. 예를 들어 사용자가 웹 페이지에 접근했을 때 기존 사용자의 성향을 반영하는 여러 정보를 EVCache에서 빠르게 가져온다. 아래 예시를 확인해보자.
그림 4. Use Case
위의 그림 4는 EVCache의 여러 use case 중의 하나이다. 내부 순서도를 보면 이제까지 알아본바와 크게 다르지 않다.
결국 캐시를 확인해서 없으면 채우고 이후부터는 캐시에만 접근해서 사용한다.
그림 5. Cache Hit Rate
지금까지 언급한 것을 바탕으로 운영 결과를 보면 그림 5에서 EVCache의 캐시 적중률을 확인 할 수 있다.
사실 캐시 적중률이 거의 100프로 육박하여 어느 정도의 신뢰를 가져가야 할지는 잘 모르겠으나 결론으로는 Netflix에서는 EVCache를 사용하여 분산 환경에서도 데이터 접근에 대한 반응 속도 및 관련 추가 작업 수행하였다는 것이다.