Scale-up 서버에서의 도커 컨테이너를 이용한 아파치 스파크 시스템 확장성 개선 정리

Scale-Up에서 확장성 문제가 나타난다

자바 가상 머신의 GC(Garbage Collection)에 의한 오버헤드 

scale-up 서버의 NUMA(Non Un-iform Memory Access) 메모리 구조에 따른 메모리 접근 지연(Memory Access Latency) 시간 문제 

공유 메모리 시스템(Shared Memory System)

scale-up 서버를 파티셔닝(partitioning)하여 하나의 서버를 분산 시스템(Distributed System)

메모리를 사용하기 때문에 맵리듀스보다 빠르다는 장점

그러나 도커는 게스트 OS를 설치하지 않고, OS 이미지가 동작하도록 CPU와 메모리 영역만 가상화한다. 

자바 가상 머신에서 GC가 호출되면, 자바 가상 머신에서 수행되는 쓰레드들은 멈추고 GC 작업을 완료하고 동작하는데, 자바에선 이를‘stop-the-world’라고 부른다. 

따라서 코어가 많아질수록 직렬화(serialization) 되는 코어들이 늘어나 오버헤드(overhead)가 발생하여 처리량이 떨어진다. 

또 다른 문제는 NUMA 메모리 구조다. 

즉 코어마다 메모리에 접근하는 거리가 다르다. 

그러므로 메모리 접근 지연 시간에 의한 오버헤드도 확장성 문제의 원인중 하나로 볼 수 있다. 

본 논문에서는 확장성의 문제점 중 한 가지로 GC를 지적하고 있기 때문에 하나의 GC가 아닌 두 종류의 GC로 실험을 하였다. 하나는 Parallel GC이고, 다른 하나는 G1 GC로 설정하여 실험하였다. 

실험 결과 GC 종류에 따른 성능차이는 크다. 

Parallel GC는 GC를 처리하는 쓰레드를 여러 개를 생성해 병렬 처리함으로써 분산 처리하는 스파크에서는 G1 GC보다 더 좋은 성능을 보인다. 

하지만 아무리 Parallel GC라도 여전히 확장성 문제를 가지고 있다. 

따라서 코어수가 많은 scale-up 서버에서 하나의 단일노드로 시스템을 구성하게 되면 GC가 발생하는 동안 더 큰 오버헤드가 발생할 수 있다. 

두 번째 고려 사항은 메모리 접근 지연 시간[15]이다. 

원격 메모리 접근에 따른 접근 시간이 높아지기 때문에 성능을 저하시킨다.

 리눅스는 이러한 문제를 해결하기 위해 커널 내부에 automatic NUMA balancing[17]이라는 기능이 있으나, 스파크 확장성에는 별다른 영향을 주지 못하였다. 

세 번째 고려 사항은 운영 체제 자체의 저해 요소이다. 

NUMA의 영향 뿐만 아니라, 공유 메모리 시스템의 환경 때문에 발생하는 확장성 저해 요소를 생각 해야한다. 

자바 가상 머신 위에서 동작하는 쓰레드간의 공유하는 single address space 때문에 발생하는 문제로 공유 메모리에 대한 락(lock)이 있다.

그림 11.과 같이 분산 처리 환경에서는 여러 워커 노드에서 하나의 job에 대한 task들을 나눠서 처리하는데, 이 때 모든 워커 노드의 task들이 동일한 시간에 수행이 완료되지 않고 먼저 끝나는 노드와 그렇지 않은 노드가 발생한다. 

---

---

하나의 도커 컨테이너는 분산 처리 시스템의 워커 노드의 역할을 하게 되며, 독립된 CPU와 메모리를 사용하게 된다. 

이렇게 파티셔닝을 통해 가져올 수 있는 효과는 자바 가상 머신의 GC의 영향을 시스템 전체가 받는 것이 아닌 GC가 수행되는 컨테이너의 부분만 영향을 받음으로 전체적인 오버헤드를 줄일 수 있다. 

또 각 컨테이너는 할당된 소켓의 메모리만 접근하기 때문에 메모리 접근 지연 문제를 해결함과 동시에 공유 메모리 시스템에서 발생할 수 있는 락 문제도 해결 할 수 있다. 

하지만 전체적인 확장성 저해 요소 문제점들을 파티셔닝으로 개선했다고 하더라도 시스템을 몇 개의 파티션으로 나눌지, 컨테이너의 코어의 수는 몇 개씩 할당할지 정하는 것은 중요하다. 

이유는 스파크의 워크로드 알고리즘마다 시스템의 어느 자원을 어떻게 사용할지 다 다르고, 서버 환경에 따라 파티셔닝을 크게 적게 나누었을 때 혹은 작게 많이 나누었을 때 성능이 좋을 수도 있기 때문이다. 

따라서 워크로드에 따른 효율적인 파티셔닝을 결정해주는 프레임워크(Decision Engine)가 필요하다.

워크로드 종류, 시스템에서 이용한 가능한 코어 수, 데이터 타입

Evaluation은 제친다.

본 논문에서는 분산 처리 시스템인 아파치 스파크를 하나의 scale-up 서버에서 구성하였을 때, 성능에 대한 확장성 문제를 발견하고 이에 대한 해결책으로 도커 컨테이너를 이용한 파티셔닝을 제안했다. 

그 결과 공유 메모리 시스템을 분산 시스템처럼 구성하였고, 스파크 벤치마크인 4개의 워크로드(WordCount, Grep, Naive Bayes, K-means)에서 적용한 결과, 120코어에서 파티셔닝 하지 않았을 때보다 확장성을 가지며 처리량이 각각 최대 1.6배, 1.5배, 1.7배, 1.1배 향상되었다.

 scale-up 서버에서의 확장성 문제의 원인은 첫째로 자바 가상 머신의 GC이다. 스파크는 기본적으로 자바 가상 머신 위에서 동작하기 때문에 자바 가상 머신의 GC에 의해 영향을 받는다. 

이에 분산 처리 시스템을 성능이 좋은 시스템이라도 하나의 서버로 구성하면 GC의 오버헤드가 더 커질 수 있다. 

두 번째는 scale-up 서버의 NUMA 메모리 구조 때문이다. 이런 메모리 구조에서는 메모리 접근 지연 시간 때문에 오버헤드가 발생한다. 

세 번째는 공유 메모리 시스템의 공유메모리 접근 때문에 락이 발생하여 확장성 저해 요소가 있다.

 이러한 확장성 문제의 원인들을 도커 컨테이너 파티셔닝 기법으로, 하나의 scale-up 서버를 분산 처리 환경의 시스템처럼 구성하여 확장성을 개선할 수 있었다. 

하지만 scale-up 서버의 환경에 따라 파티셔닝 기법을 다르게 적용해야 하는 것을 확인 할 수 있었고, 분산 처리 환경에서의 일반적인 문제인 뒤처진 task에 대한 문제는 파티셔닝 방법을 적용해도 여전히 존재하는 것을 확인 할 수 있었다.

 이러한 이슈들을 해결하기 위해 향후 연구로는 5장에서 제안한 프레임워크를 실제로 구현해 볼 필요성이 있다. 본

 논문의 실험에서는 수동으로 도커 컨테이너를 생성해 일일이 실행해서 성능을 확인했지만, 이것을 어떤 파티셔닝을 사용할지 자동으로 결정해주는 프레임워크가 있다면 더 효율적일 수 있다. 

또한 뒤처진 task에 대한 문제를 본 논문에서는 코어 수를 많게 파티셔닝 함으로써 이 문제를 완화할 수 있었지만, 향후 연구로 근본적인 해결할 방법을 연구해 볼 필요가 있다. 

실제로 분산 처리 환경에서는 이 문제를 해결하기는 어렵지만, scale-up 서버에서는 하나의 공유 메모리 시스템을 분산 처리 시스템처럼 도커를 활용해 파티셔닝 한 것이므로 수행 완료된 task들을 모니터링하고 있다가 아직 수행이 완료되지 못한 컨테이너에게 코어를 할당하는 방법 등으로 해결하는 방법을 연구해 볼 수 있다.

 따라서 이 문제도 도커를 활용해 해결할 수 있는 가능성이 높다.