Mesos Marathon 사용기 및 Spark 주의점

1 minute read

intro

Mesos-Marathon(이하 마라톤) 환경을 실제 서비스중인 환경에 적용할 일이 있어 실 환경에서 적용하면서 있던 일들을 적어보려 합니다.

먼저 적용했던 환경은 다음과 같습니다.

총 서버 3대, 각각 32 프로세서, 128GB 램을 사용중이었습니다.

모두 Centos7.2 환경이었습니다.

사실 기존의 서비스되던 환경을 마라톤 환경으로 바꾸기 위해서는 기존의 실행되던 스크립트를 마라톤에 올려야 했습니다.

물론 Health check 기능을 사용해서 기존 스크립트를 그대로 써도 되지만, stdout 으로 보기 위해서 기존의 쉘 스크립트를 수정해서 옮기기로 하였습니다.

그러나, 쉘 스크립트에서는 다음과 같이 많은 환경 변수들이 적용되어 있었습니다.

HOME_PATH=XXX
A=XXX
B=XXX

/command --A $A --B $B

기능중 마침 환경 변수를 설정할수 있는 기능이 있어 설정을 다음과 같이 손쉽게 할 수 있었습니다.

no_support_completion

해당 기능을 사용해본 결과 정상적으로 참조가 되었고, 작동도 정상적으로 되는것을 확인하였습니다.

마침 올리려던 프로그램은 Spark on Mesos 위에서 돌아가는 프로그램이었습니다.

한개당 약 32GB, 16 Processor 를 마라톤에 할당하고 5개를 띄웠는데 이중 3개만 돌아가게 된것이었습니다.

원인은 바로 Spark 에서 올리는 프로그램일 경우 마라톤에 할당된 메모리/프로세서 외의 Spark 에 올릴때 옵션으로 주는 메모리/프로세서가 또 따로 할당되기에 생긴 문제였습니다.

물론 단순한 프로세스같이 따로 JVM 을 거치거나 MESOS 에 의해 할당되지 않는 프로세스라면 상관이 없겠지만, Spark on mesos 같이 중복으로 메모리/프로세서가 할당되는 프로세스라면 조심해야 할듯 합니다.

결론적으로는 성공적으로 마라톤을 올리는데 성공하고 프로세스를 올리는것까지 확인하였으나, 문제점은 사실 다음과 같은 상황에 있엇습니다.

A, B, C 서버가 존재하고, A`, B`, C` 프로세스가 각각 실행되어야 할때(비슷한 양의 자원을 사용한다고 할 경우) 가장 이상적인 방안은 각자의 서버에 A - A` 와 같이 1 서버에 1개의 프로세스가 뜨는 것이 가장 이상적일것입니다.

서비스 중 B 서버가 죽게 될 경우 B` 프로세스는 A 혹은 C 서버에 재할당됩니다.

그다음 작업으로 B 서버를 살렸을 경우 다음과 같은 문제점이 발생되게 됩니다.

B` 프로세스가 A 서버로 이동했다고 했을때 B 서버가 다시 살아났을 경우 B` 프로세스는 B 서버로 다시 할당되지 못하고 해당 프로세스가 죽거나, 사용자가 재시작 시키기 전까진 재할당되지 못합니다.

이런 관점에서 봤을 때는 마라톤은 최초 실행시에는 균등하게 자원을 분배하려고 하나, 새로 서비스를 시작했을때는 재분배되는 기능이 없는듯 합니다.

사실 서비스를 다시 균등 분배하려면 서비스 정지 시점이 나오게 되니, 사용자가 인지하고 재할당하는게 맞지만,

다시 재할당 하는 기능을 제가 못찾은 건지 해당 기능이 필요해 보입니다.

다만, 마라톤을 통하여 HA(High Availability) 를 구현하기에는 좋다고 생각합니다.

메소스, 마라톤 둘다 HA 모드로 실행할수 있기 때문에 간단하게 HA를 구성하기에는 충분한 기능이라고 생각됩니다.

결론은 한번에 여러 서버에서 실행되어야 하거나, HA구조로 작동되어야 하는 등 실행을 관리하기에도 충분히 좋은 기능들이 많기에 실무에서도 적용해볼만한 가치가 충분히 있다고 생각합니다.