넷플릭스에서는 높은 속도로 데이터를 제공하기 위해서 뿐만 아니라 멀티 리전의 데이터 가용성을 바탕으로한 전체 서비스 가용성 유지를 위해 캐시를 사용하고 있습니다. 이 앞의 세션에서 보았던 마이크로서비스 구조를 염두해 둘때 한가지 가장 간단한 변화는 외부 클라이언트로 부터 유입되는 단 하나의 요청에 대한 응답을 만들기 위해 다수의 내부 서비스들로 부터 데이터를 확보해야 하며, 이는 다수 서비스들에 대한 요청과 응답으로 이루어지게 됩니다. 내부 네트워크 성능, 데이터 저장소의 응답속도등의 복합적인 영향으로 인해 마이크로 서비스는 쉽게 느려질 수 있으며, 이는 보통 '팬아웃 효과'로 알려져 있습니다. 뿐만 아니라 다수 서비스간의 데이터 정합성 유지, 필요에 따라 각 서비스간 데이터의 다운타임 없는 이동, 증가하는 데이터량에 동시에 증가하는 데이터 소스의 부하, 그리고 이런 것들을 모두 감안한 데이터 복제 등을 처리해야 할 필요가 있습니다. 본 세션에서는 넷플릭스에서는 이런 문제를 어떤 방식으로 해결하는지, 그리고 스프링 부트, 스프링 클라우드를 비롯한 피보탈의 기술을 사용해서 어떻게 빠르고 쉽게 사용할 수 있는지에 대해 알아봅니다.

2. 숨겨진 마이크로서비스
정윤진
Principal Technologist, Pivotal

3. 마이크로 서비스 환경

4. https://sdtimes.com/apis/securing-microservices-the-api-gateway-authentication-and-authorization/
팬-아웃 효과

6. 마이크로 서비스 환경에서는
다양한 목적에 부합하기 위해 캐시의 사용이 매우 중요합니다.
● 웹 애플리케이션 간의 데이터 일관성 유지
● 요청에 대한 응답을 매우 낮은 지연시간으로 제공
● 온라인과 오프라인 서비스간 데이터의 연동
하지만 캐시를 주요 데이터베이스 처럼 사용하기는 어렵습니다.
● 휘발성을 가진 메모리가 주 저장소 Volatile
● 대부분 키:값 구조와 같은 단순한 데이터 구조를 지원 – Hard to keep complex data
● 클러스터로 구성되지 않아 고가용성의 확보가 기본이 아님 – Fragile

7. 데이터베이스 구간에서의 복제는

8. 데이터를 잃지 않는 캐시 클러스터
를 가질 수 있다면 어떤 일이 벌어
질까?
만약
https://medium.com/netflix-techblog/cache-warming-agility-for-a-stateful-
service-2d3b1da82642

9. 넷플릭스 EVCache

10. 넷플릭스 EVCache는 분산 캐시
분산 캐시 사용의 장점:
● 소스/데이터베이스로부터의 데이터 참조보다 훨씬 빠른 조회 속도를 제공
● 응답이 빠르기 때문에 더 적은 수량의 리소스로 더 많은 요청의 처리가 가능
● 프론트에 위치한 서버들의 부하를 감소
● 서버의 처리량을 극대화

11. EVCache 는 ”Memcached” 를 기본으로 만들어 졌습니다.
https://github.com/Netflix/evcache/wiki
https://github.com/Netflix/EVCache
https://medium.com/netflix-techblog/announcing-evcache-distributed-in-memory-datastore-for-cloud-c26a698c27f7
Memcached를 사용하여 얻은 장점은 :
● 간단하고 쉬운 Memcached 인터페이스를 그대로 사용할 수 있었습니다. (get, set, touch, etc.)
● 데이터 크기 또는 네트워크 요청의 증가에 따라 선형적인 확장을 기대할 수 있습니다. (vs getting a bigger box)
● 원하는 수량으로 데이터 복제를 구현할 수 있었습니다. (some clusters run with 2, others with 9)
● AWS 최적화를 통한 구조로 재시도, 폴백과 같은 메커니즘들이 문제 없이 동작할 수 있었습니다. (Optimization f
or AWS architecture)
● 원하는 크기의 데이터 사용에 제약이 없습니다. (with data chunking)
● 실시간에 근접한 글로벌 복제를 구현할 수 있었습니다. (Nearline)
● 데이터의 유실을 방지할 수 있었습니다.

12. EVCache의 기본 생김새
• 1개의 가용존에 3개의 인스턴스가 기본이 됩니다.
• 1개의 데이터는 3개의 인스턴스에 카테마 일관성 해싱 알
고리즘이 적용되어 분산 저장 됩니다.
• “Ketama Consistence Hashing algorithm”
카테마 라이브러리에 대한 자세한 설명은 아래의 링크에서
libketama: Consistent Hashing library for Memcached clients
https://www.metabrew.com/article/libketama-consistent-hashing-algo-memcac
hed-clients

13. 다수의 가용존에서의 EVCache
• 프로덕션에서의 EVCache 는 다수의 가용
존에 배포 됩니다.
• 이때 쓰기는 모든 가용존에 수행 됩니다.
• 하지만 읽기는 클라이언트가 위치한 가용
존의 EVCache 만을 사용합니다.

14. 넷플릭스의 플랫폼 도구와 연동되어 동작
• 사이드카 (Prana)
• EVCache 서버
• EVCache 클라이언트
• 유레카 (서비스 디스커
버리)
• 아카이어스 (설정 서버)

15. EVCache 사용 패턴 – Look aside

16. EVCache 사용 패턴 – 프로세스간 데이터 처리
오프라인과 온라인 또는 실시간에 가까운 애플리케이션 간에 동일한 데이터를 흐름에
따라 연속적으로 참조하는 형태로 사용할 수도 있음

17. EVCache 사용 패턴 – 캐시 확장과 워밍
https://www.slideshare.net/ShashiShekarMadappa/evcache-at-netflix

18. 글로벌 리전간 복제 구성
https://medium.com/netflix-techblog/caching-for-a-global-netflix-7bcc457012f1
이 모든 동작은 개발자가 EVCache 클라이언트 라이브러리에 포함된 set() 을 수행하
면 자동으로 이루어지는 과정

19. 구성 요소 : Replication Message Queue
● 이 글로벌 복제의 핵심 구성 요소 입니다. 넷플릭스는 여기에 카프카를
사용하고 있습니다. 이 카프카 클러스터는 2개의 컨슈머를 가집니다. 바
로 다른 리전으로 복제를 담당하는 ‘복제 릴레이 클러스터＇입니다. 각
리전별로 독립된 복제 클러스터는 리전에 발생할 수 있는 지연 시간 이
슈로 부터 다른 리전의 복제를 보호합니다.
● 만약 대상 리전이 장시간 문제가 발생하여 복제 지연이 발생한 경우, 카
프카 큐의 버퍼가 꽉 차게 되어 결국 카프카는 오래된 메세지를 드랍 합
니다. 이런 장애 시나리오에서 드랍된 메세지는 절대 대상 리전으로 복
제 하지 않습니다. 복제 캐시를 사용하는 넷플릭스 서비스들은 이런 형
태의 장애를 처리할 수 있도록 디자인 되어 있습니다.

20. 구성요소: Replication Relay
● 복제 릴레이는 카프카 클러스터로 부터 메세지를 가져옵니다. 가져오는
메세지는 다른 리전에 위치한 복제 프락시와 안전한 연결을 구성하고,
복제 요청을 보냅니다.
● 이때 SET과 같은 명령으로 데이터가 필요하다면 로컬의 EVCache에서
데이터를 가져옵니다. 복제 프락시가 데이터를 성공적으로 저장했다는
메세지를 받을떄까지 대기하며, 타임아웃이나 실패가 발생한다면 재시
도 합니다.
● 일시적인 리전간 복제 지연은 매우 자연스럽게 핸들링되고 있습니다. 카
프카는 지속적으로 신규 메세지를 받으며 복제에 지연이 발생하면 완료
되는 동안 백로그를 버퍼로 사용합니다.

21. Replication Proxy
● 복제 프락시 클러스터는 대상 리전의 캐시에 복제 데이터를 저장
하기 위해 동작합니다. 복제 릴레이로 부터 타 리전의 데이터를 받
아 로컬 리전의 캐시에 저장합니다. 이 과정이 성공적이면 릴레이
클러스터에 응답을 리턴하여 복제에 이상이 없음을 알립니다.
● 복제 프락시가 위치한 로컬 리전의 캐시에 데이터를 저장할때는
일반 클라이언트가 사용하는 것과 동일한 EVCache 클라이언트를
사용합니다. 이 클라이언트 라이브러리는 샤딩 인스턴스 선택, 재
시도와 같은 복잡한 작업을 수행합니다.
● 다른 많은 넷플릭스 서비스들과 마찬가지로, 복제 릴레이와 복제
프락시 클러스터들은 다수의 가용존에 배포되어 리전 내에서 발
생할 수 있는 장애에 대비합니다.

22. Performance
• 초당 2천 5백만 요청 처리
• 매일 2조개의 데이터가 글로벌 복제
• 수천만개의 오브젝트를 저장
• 수만개의 Memcached 인스턴스
• 각각의 요청은 밀리세컨 단위의 응답성을 가짐

23. 데모 애플리케이션

24. Diagram
Web
kafka
memcached
Relay memcached
Web
(relay)
AWS-KR
Region
AWS-JP
Region

25. https://github.com/younjinjeong/spring-cloud-cross-region-replication-example

26. 엔터프라이즈 캐시

27. Pivotal Cloud Cache

28. 데이터베이스 오프로딩 레거시와 신규 마이크로 서비스에서 모두 사용

29. • 각 마이크로서비스 별로 캐시 클러스터를
준비해 사용
• 이벤트 기반의 메세징을 사용하여 캐시
클러스터간 데이터 복제

31. 결론

32. • 다수의 마이크로서비스로 이루어진 마이크로서비스 아키텍처는 필연적으로 내부에 팬-아웃 현상을
유발한다.
• 분산 캐시를 사용함으로 인해 낮은 지연시간을 제공하는 데이터 저장소를 높은 가용성으로 유지할
수 있다.
• 메세지 큐를 사용함으로서 캐시 워밍, 캐시의 확장 재구성, 글로벌 복제와 같은 구성이 가능해진다.
• 메세지 큐나 캐시에는 성능이나 목적의 수행에 맞는 다양한 도구, 예를 들면 래빗엠큐나 레디스등의
도구를 선택해서 사용할 수 있다. 이때 스프링 클라우드 스트림이나 스프링에서 지원하는 도구를 선
택한다면 더 용이할 것이다.
• 카프카에 유입되는 데이터는 캐시-캐시 복제 외에도 캐시-데이터베이스나 이기종 데이터베이스간 데
이터를 복제하는 등의 형태로 응용할 수 있다.
• 각 마이크로서비스 개발팀은 운영팀의 지원이 없이도 직접 캐시를 준비해서 사용할 수 있어야 한다.
• 오픈 소스의 직접 사용에 대한 지원이 필요한 경우 피보탈 클라우드 캐시(PCC)를 통해 동일한 효과를
노려볼 수 있다.

33. 고맙습니다.
Speaker Name
Contact information