왜 우리는 Vert.x 보다 아카(akka) 를 우리의 클라우드 시스템을 위해 선택했나? (번역)

왜 우리는 Vert.x 보다 아카(akka) 를 우리의 클라우드 시스템을 위해 선택했나? 

원문 > https://techblog.king.com/why-we-choose-akka-for-our-cloud-device-solution/   번역의 질에 대해선 참아주세요 OTL 
전체를 번역하진 않았고 Vert.x 와 Akka비교에 관한 부분만 번역하였다.

우린 자동화 테스트를 반복적으로 실행 했다. 동일한 시간에 한 두개의 디바이스를 가지고 말이지..이런 진행과정은 꽤나 간단하다. 맘에드는 디바이스를 집어들고 게임 및 테스트로 빌드를 만들고 플레이를 누르고 커피잔을 집어들고..
이런 작업은 꽤 잘 되었지만 최대한 많은 수의 디바이스로 작업을 해서 우리의 게임이 잘 작동하는지 확인해야했다. 버그 없는 게임을 유저들은 사랑해 줄테니..

여기 우리회사를 위한 클라우드 디바이스 솔루션 개발에 관해서 썰을 풀어보겠다.

우리의 접근 방식

디바이스 클라우스 상에서 우린 다중분산디바이스에서 테스트 잡을 실행했는데 이것은 흡사 하둡에서의 맵/리듀스 작업방식과 비슷하다. 이런 방식을 차용하여 우린 분산해서 실행시키고 결과를 집약시켰다. 이것에 관한 구조에 관해선  아래 유명한 하둡 얀 맵/리듀스 아키텍처를 살펴보아라:

From our point of view it seems reasonable to start by using the same module structures and a similar assignment of responsibilities to them. Mainly because, as we stated before, the problem at hand has some important analogies.

So, we end up with three main modules:

Resource Manager:
This module is responsible for:

• Handle Resource Discovery and Assignment, in our case the resources refer to the devices connected to the cluster
• Schedule runs

The main difference with the YARN architecture is than we can create as many instances we need for the cloud.

Application Manager:
Each test running in the system is managed by a dedicated Application Manager. So, the main responsibility of this module is to manage an execution of a test (Please note that a test might run on several devices, so an execution of a test is actually spawning several individual tests for each selected device, which are actually executed in different Node Managers.)

시스템에서 실행되는 각 테스트는 전용 응용 프로그램 관리자에 의해 관리됩니다. 따라서이 모듈의 주된 책임은 테스트 실행을 관리하는 것입니다. 테스트는 여러 장치에서 실행될 수 있으므로 테스트 실행은 실제로 선택한 각 장치에 대한 여러 개별 테스트를 생성합니다. 다른 노드 관리자.)

• Negotiate Resources with Resource Managers
• Coordinate test execution with Node Managers

Node Manager:
Each device needs to be connected to a physical machine. Each of these machines contains a node manager which is responsible for:

• Executing a test in any of the connected devices
• Coordinate the device test execution with the Application Manager
• Gossip the actual available devices to the Resource Manager

Building distributed systems

Before we get to how we built a distributed system, here’s a little background about distributed systems, so you can understand our initial concerns and our thought process.

Our system is basically a bunch of processes talking to each other in order to coordinate themselves. Just like any other cluster of processes. These processes may be in the same machine or may not. In fact, most of the time they are in different machines. So, we needed interprocess communication.

Everyone wants a big, powerful, nice-looking cluster. But, as long as it grows, the more often the cluster begins to fail. In fact, the probability of failure increases with the number of processes. A process may fail because a programming error or it may fail because the machine running the process had a problem, because of network issues, or for whatever reason.

Here’s an example: Imagine we have a machine with a failure rate of three months running one process. That means, it is likely to have a problem within the next three months.

분산 시스템을 구축하기 전에 분산 시스템에 대한 약간의 배경 지식이 있으므로 초기 우려 사항과 생각 프로세스를 이해할 수 있습니다.

우리의 시스템은 기본적으로 서로 조화를 이루기 위해 서로 대화하는 과정입니다. 프로세스의 다른 클러스터처럼. 이러한 프로세스는 동일한 시스템에있을 수도 있고 그렇지 않을 수도 있습니다. 사실, 대부분 다른 컴퓨터에 있습니다. 그래서 우리는 프로세스 간 통신이 필요했습니다.

누구나 크고 강력한 멋진 클러스터를 원합니다. 그러나 성장하는 동안 클러스터가 더 자주 실패하기 시작합니다. 사실, 프로세스의 수에 따라 실패 확률이 증가합니다. 프로그래밍 오류 또는 프로세스를 실행하는 컴퓨터에 문제가 있거나 네트워크 문제로 인해 또는 어떤 이유로 인해 프로세스가 실패 할 수 있습니다.

예를 들면 다음과 같습니다. 하나의 프로세스를 3 개월 동안 실패한 시스템이 있다고 가정 해보십시오. 즉, 향후 3 개월 이내에 문제가 발생할 가능성이 있습니다.

Now, take a look at this table:

1 machine running one process	1 fail in 3 months
100 machines running one process	1 fail every 21,6 hours
1000 machines running one process	1 fail every 2,16 hours
10000 machines running one process	1 fail every 12,96 minutes

So, we really need a failure detector in order to be aware of the failing process and take action and also a recovery system in order to restart processes.

적합한  툴 선택하기 

자 이제 어떻게 분산 시스템을 구축 할까?

팀의 기술적 백그라운드와 시간적 제약등을 고려할때 우리는 자바언어 기반의 클러스터 시스템과 빠르게 개발 할 수 있는 프레임워크를 원했다. 

여기 그에 걸맞는 적절한 후보들이 있다:

• Quasar
• Akka
• Vertx
• Norbert

이것들 모두는 꽤나 클러스터 구축에 적합하고 자바로 구현 할 수 있다.

4개의 후보를  노드간 통신, 고장감지, 회복 시스템, 프로그래밍 모델등에 관해서 별을 주면서 평가했다.

노드간 통신 

Quasar 와  Akka 는 메세지를 액터사이에서 완벽한 투명성을 가지고 전달된다. 아카는 또한 FIFO 메세지로 액터간 전송된다. Akka는 계층간의 액터에게도 메세지를 보낼 수 있다. eventbus 식도 지원한다.
Vertx 는 Pub/Sub 방식의 중앙 EventBus 이다.
Norbert 는  client/server 접근이 필요하며 p2p 방식은 안된다. 우리 목적에 맞지 않는다.

그래서 점수는 :

• 5 points for Akka
• 3 points for Quasar
• 2 points for Vertx
• 1 point for Norbert

고장 감지

Quasar 와 Vertx 는 인메모리데이터그리드 데이터베이스를 클러스터 상태를 관리하기 위해 사요한다.
Quasar 는 Galaxy   그리고  Vertx 는  Hazelcast 

Norbert 는 Zookeeper 를 사용한다.
Akka 는 Gossip-based Membership 프로토콜을 이용한다.

모두 괜찮긴 했지만 Akka 는 서드파티 소프트웨어가 필요 없다. 이걸 참고. cluster-aware routers and metrics.
고로 Akka 만 별 5개 나머지는 별 4개다.

회복 시스템 

Quasar 는 Hazelcast  를 내부 액터 상태를 유지하기 위해 사용하고 실패에 대하여 이것을 제공한다.-> ‘Migrating Actors’ 

Akka 는 여러개의 퍼시스턴스 시스템을 사용 할 수 있다. (퍼시스턴스 액터와 함께)

Vertx 와 Norbert 는 회복 시스템을 제공하지 않는다.

Akka 는 매우 유연한 방식을 가지고 있다. 그래서 아카 5점 Quasar 4 점. 나머지 0점 

프로그래밍 모델

Quasar 와 Akka 는 부모,자식으로 계층화되는l actor model.이다.

Vertx 는  actor-like 모델을 사용하며 계층적이진 않다 

액터 시스템 파라다임은 동시성 이슈를 간단하게 해준다. 우리 개발 속도를 향상 시켜 줄 것이다. 우리의 목적에 부합한다. Resource Manager, Application Manager, and Node Manager, to an actor Hierarch

위에 2개는 별 2개 나머지는 별 1개를 주었다.

Final score

Quasar	17
Akka	20
Vertx	8
Norbert	6

Building it: first architectural design

Once we chose Akka, we laid out our first architectural layout. In the following Architecture diagram,  you will see a mix of a runtime component views with a logical deploy view.

If you recall the modules from the ‘Main Software Modules’ section, you will see in the above diagram that we have a Resource Manager node coordinating with a ApplicationManager who is actually running a Test Execution. The Application Manager itself is coordinating the execution with the Node Manager, and finally the Node Manager is executing the test and sending the device info to the ResourceManager. This is the basic interaction within in the system.

'Main Software Modules'섹션에서 모듈을 호출하면 위 다이어그램에서 실제로 Test Execution을 실행하는 ApplicationManager와 조정되는 Resource Manager 노드가 있음을 알 수 있습니다. 응용 프로그램 관리자 자체가 노드 관리자와의 실행을 조정하고 노드 관리자가 테스트를 실행하고 장치 정보를 ResourceManager로 보냅니다. 이것은 시스템 내의 기본 상호 작용입니다.

Conclusion

After six months, we ended up with a working proof of concept. That is, we built the core systems and a simple test (without third-party platform integration) that runs with almost no failure in Android and only some failures in iOS. It should be noted that iOS is a more restrictive platform than Android. So more variables might fail when running a test on that platform. The most significant one is the rights restriction and management, based on certificates that iOS imposes in what we can do in order to ensure the successful execution of a test.

6 개월 후, 우리는 개념 증명으로 끝을 맺었습니다. 즉, 우리는 Android 시스템에서 거의 실패하지 않고 iOS의 일부 오류만으로 실행되는 핵심 시스템과 간단한 테스트 (타사 플랫폼 통합없이)를 구축했습니다. iOS는 Android보다 더 제한적인 플랫폼이라는 점에 유의해야합니다. 따라서 해당 플랫폼에서 테스트를 실행할 때 더 많은 변수가 실패 할 수 있습니다. 가장 중요한 것은 iOS가 테스트를 성공적으로 수행하기 위해 할 수있는 일에 부과하는 인증서를 기반으로 권한 제한 및 관리입니다.

Tests for Candy Crush, Bubble Witch 2, and Pyramid have been already launched and successfully executed.

Next steps are to make the system more reliable and robust, as well as add some essential features for game studios. So, we plan to add:

• Facebook, Apple Store, and Google Store integration: So the test can include some parts which interact with these platforms.
• Configuration management: So we can choose which framework to use for executing the test. Right now we only support TestNG test.
• Monitoring System: In order to track the cluster status, both visually and programmatically.
• Audit System: In order to track Test executions and be able to react to failures.
• Eventual Messaging Consistent System: Akka guarantees at most one message delivery semantics. That means, an Actor might receive a message or not. We need to make sure than at some point the Actor receives the message. So we need an Eventual Consistency message model.
• Improve execution engines in the NodeManager, especially for iOS devices.