PayPal 은 어떻게 하루에 10억 request 를 단 8개 VM 으로 처리하는가?
이 글은 highscability.com 에서 소개된 글에 대한 번역입니다. 원문을 최대한 전달하기 위해서 노력했습니다. ^^;;
원문은 다음에서 확인하실 수 있습니다.
PayPal 의 성과
최근에 PayPal 은 자신들이 운영하던 VM(Virtual Machine) 의 사이즈를 큰 폭으로 줄이게 되었습니다. 기존에는 몇 백대 규모의 VM 을 운영하여 서비스를 하고 있었는데 단지 8 개의 VM 으로 서비스를 할 수 있게 되었습니다. 자신들이 제공하던 성능과 규모는 그대로 유지한 채 VM 의 규모를 줄였다는 점에서 놀랍습니다. 실제 그 들의 성과는 다음과 같습니다.
- 90% 에 달하는 CPU 사용량에도 반응성은 그대로 유지하였습니다.
- 각 VM 들이 처리하는 transaction 의 크기는 기존에 비해 큰 폭으로 증가했습니다.
- 각 transaction 을 처리하가 위한 job 들의 처리시간 또한 기존의 1/10 수준으로 떨어졌습니다.
- 운영하는 VM 이 줄어 들게 되어 실제 서비스를 운영하기 위한 비용이 큰 폭으로 감소 했습니다.
이런 놀라운 성과를 어떻게 낼 수 있게 되었는지 좀 더 살펴 보겠습니다. PayPal 은 기존에 JVM 을 기반으로 전통적인 방식으로 개발을 했습니다. 이번 성능 개선 및 VM 사이즈를 줄이기 위해서 최근에 자신들의 전통적인 방식을 버리고 Actor model 개발 방법을 도입하였습니다. Actor model 도입은 Akka framework 의 도움을 통해서 이루어졌습니다. Akka 를 기반으로 한 개발 framework 을 자신들이 개발하였는데, 그 이름은 “squbs" 입니다. 발음은 “큐브” 라고 읽습니다. 이 프로젝트에 대해서 더 자세히 알고 싶으시다면 다음 링크를 참고하시면 됩니다(squbs: A New, Reactive Way for PayPal to Build Applications). 그리고 내부에서 개발 및 활용하는 것 이외에도 open source 로 모두 사용할 수 있도록 공개하였습니다.(관련 github : squbs on GitHub.)PayPal 이 단순히 Actor model 을 기반으로 한 개발 방법론을 도입함으로써 위에서 설명한 성과들을 얻은 것은 아닙니다. 그들의 근본적인 개선은 기존에 사용하던 Stateless Web Application Server 형태의 개발 방법론에서 Stateful Web Application Server 형태로 전환한 것이 가장 큰 개선 요인이었다고 합니다. Stateful service 에 관련하여 더 많은 내용을 알고 싶으실 경우에는 다음 문서를 참고하시면 됩니다.(Making The Case For Building Scalable Stateful Services In The Modern Era)
많은 VM 을 사용할 때의 문제점
어떤 것들이 PayPal 이 Akka 를 선택하게 되었는지 알아볼텐데요. 그 동기를 알아보기 이전에 많은 VM 을 사용할 때의 문제점들이 어떤것인지 부터 보도록 하겠습니다.
- 각 서비스들이 사이즈가 작은 VM 들을 사용할 경우 각 VM 들은 그만큼 작은 throughput 을 보여주게 됩니다.
: Actor 기반의 reactive system 은 적은 리소스를 굉장히 효율적으로 사용합니다. 기존의 auto-scaling 방식을 사용하는 방식보다는 훨씬 시스템 리소스를 적게 사용하게 되어 실제 사용되는 VM 의 양을 줄일 수 있게됩니다. - VM 의 갯수가 많아 질수록 network 을 사용하게 되는 양이 많아지게 되어 network bandwidth 를 많이 차지하게 되고 각 패킷들이 거쳐가야 할 routing infra 들의 부담도 같이 커지게 됩니다.
: 최근 서비스들은 각각이 서로 연결되어 가는 추세입니다. 연결되는 서비스가 많아질수록 한 번의 request 가 많은 VM 을 거쳐서 결과를 많들어 낼 가능성이 커지게 되는데요, 이로인해 request 의 latency 는 올라가게 되고 실제 request 를 발생시킨 client 는 느려진 만큼의 손해를 보게됩니다. - 관리하는 VM 이 늘어나면 모니터링, 관리, 비효율적인 캐슁등으로 인한 비용이 증가하게 됩니다.
- VM 이 갯수가 많아질수록 새로운 코드를 배포하기 위한 시간도 같이 늘어 나게 됩니다.
- 하나의 VM 이 사용하는 CPU 갯수는 더 증가하게 됩니다. CPU 의 성능이 계속 올라가는 데는 한계가 있기 때문이죠.
- Micro service 를 구성하는 nano service 가 많아질수록 layer 가 많아지고 복잡도가 올라가게 됩니다.
: 서비스를 micro service 구조로 구성하고 운영할 때는 관리가 쉽고 빠르게 구성할 수 있는 loosely-coupled 된 nano service 들을 활용하게 됩니다.
무엇을 원하는가?
VM 이 많은 시스템에서의 문제점들로 인해서 PayPal 은 다음과 같은 특징을 갖는 시스템을 원하게 되었습니다.
- Scale In/Out 과 Up/Down 을 할 수 있으며 몇 천만 request 를 하루에 처리할 수 있어야 함
- 세밀하게 컨트롤 가능한 "Low latency” time 을 제공해야 함
- Resilient to failure
- Service 에 적용하는 것의 유연성
- scalability 와 간결함을 권장하고 실패와 error 를 없애는데 노력하는 Programming model 과 문화
PayPal 이 좀 더 얇은 개발 stack을 원하는 건 명백합니다. 변화가 많고 layer 가 많은 stack 을 원하지 않습니다. 일반적으로 Akka 와 state 를 기반으로하는 시스템은 많은 개발스택을 하나의 기술로 사용하고자 할 때 더 좋습니다. Actor model 로 개발을 할 수 있는 건 Erlang 과 Akka 두 가지가 많이 사용되는데, PayPal 은 이미 Java 기반의 경험을 많이 보유하고 있어, JVM 위에서 돌아가는 Akka 를 선택하게 되었습니다.그럼 Akka 를 사용해서 할 수 있는 건 아래와 같습니다.
- 쉽게 추론할 수 있는 code 를 작성할 수 있습니다.
- 쉽게 테스트할 수 있는 code 를 작성할 수 있습니다.
- 에러와 실패 시나리오에 대하여 기존의 JVM 기반의 개발 방법론 들에 비교해서 더 자연스럽게 처리할 수 있습니다.
- 더 빠르고 resilient(회복력 있는)하고 더 간단한 코드를 작성할 수 있습니다. 이렇게 작성된 코드는 간결한 error 처리와 더 적은 버그를 생산합니다.
PayPal 의 시도 및 내재화
PayPal 은 위의 내용으로 바탕으로 바로 Akka 를 기반으로 한 자신의 framework 을 만들었습니다. 그 이름은 앞서 언급한 “squbs” 입니다. “squbs” 를 통해서 “cubes” 라고 불리는 nano-serivce 를 개발할 수 있는 모듈화된 레이어를 제공합니다. 이렇게 개발된 각 “cube” 들은 서로 대칭입니다. 각 “cube” 들 간의 관계는 약하고 대칭이 됩니다. 대칭 된다는 말은 서로 관련성 있게 만들어 진 게 아니라 독립적으로 만들어 졌다고 이해하면 될 것 같습니다. 그래서 각 “cube” 들끼리는 Akka 에서 제공하는 message interface 만을 가지고 있습니다.대부분의 서비스들은 비슷한 일들을 처리하기 때문에 Orchestrator Pattern 과 Perpetual Stream Pattern 와 같은 패턴으로 추상화 할 수 있었습니다. 대부분의 서비스들이 하는 일들은 request 를 받고, database 에 read/write 를 하고, 다른 서비스들을 호출하고, rule engine 을 호출하고 cache 에서 데이터를 fetch 하고 write 하는 것들입니다.“squbs” 는 PayPal 이 akka 기반 reactive application 개발을 하기 위한 기준이 되어 왔습니다. Stateful 시스템을 고려해본적이 없더라도, 다른 뷰를 가질 수 있도록 소개를 해보는 것도 좋을 것 같습니다. PayPal, Facebook, Uber 그리고 Microsoft 에서는 이미 잘 동작하고 있는 시스템이니 같은 문제 혹은 고민을 가지고 있다면 좋은 솔루션이 될 수도 있을 것 같습니다.번역한 이 글 안에는 그들이 구체적으로 어떻게 성과를 만들어 냈는지, Stateful Application 구조를 어떻게 활용했는지 정확하진 않더라도 다음 글에서 한 번 다뤄보고자 합니다.부족한 내용은 다음 글에서 더 채워보도록 하겠습니다. 지금 당장 궁금하신 분들은 본문내에 들어있는 링크들을 통해서 직접 확인하실 수 있습니다.(To be continued...)
