레이블이 mesos인 게시물을 표시합니다. 모든 게시물 표시
레이블이 mesos인 게시물을 표시합니다. 모든 게시물 표시

2022년 9월 4일 일요일

spark application resource manager - MESOS vs YARN

MESOS
메소스의 경우 마스터가 자원을 중계하는데 특이한 점은 mesos agent(slave)에 mesos excotur가 뜨고(자원을 먼저 점유) 그 안에서 다시 spark-excutor가 실행된다. 
즉 순서가 spark-submit을 할 때 클러스터 매니저를 mesos master로 지정을 하면 메소스 프레임워크가 실행되고 그 안에서 spark driver(spark context)가 실행되면서 mesos 마스터로부터 자원을 다시 할당받고 mesos agent(slave)에 다시 spark excutor를 실행하는 방식이다. 
만약에 deploy mode를 client mode로 하면(default) 실행한 서버(배치서버가 되겠지)에서 mesos framework가 수행되고 cluster mode로 하면 mesos agent 중에서 mesos framework가 수행된다.

메소스의 경우 fine-grained와 coarse-grained가 있는데 fine-grained는 각 태스크마다 spark excutor를 한개씩 만들어서 사용하고 후자는 통으로 점유한 후 공용으로 사용하는 방식인데 fine-grained는 spark 2.4.x 버전 문서를 보다보니 deprecated 되었더라! 이유는 fine-grained의 각 task를 시작할 때 overhead가 크고 spark 작업이 종료될 때 core는 반환하지만 memory를 계속 점유하고 있다고 한다. 결과적으로 default가 coarse-grained으로 사용하고 core, memory 옵션을 주고 적절히 자원을 분배(동적분배 포함)하는 것이 배치 입장에서 이득이다.

deploy mode는 default가 client mode인데 이는 해당 process를 kill했을 때 각 excutor의 작업들이 모두 kill이 되기 때문에 추천하고 만약 cluster mode로 하면 debug를 할 때 문제가 된다. 어차피 collect같은 작업이 사용될 때 넉넉한 배치서버의 자원을 활용하기 위해서라도 master와 배치서버를 동일 시 하는게 좋다. 또한 cluster mode로 할 때에는 별도로 mesos-displatcher를 띄우고 거기에 master를 지정해야한다. 어차피 권한이나 환경등 세팅을 master가 기준이라면 client를 사용하는게 맞고 추후에 agent를 추가할 때 이렇게 하는 편이 더 편하다. 문제발생 소지가 거의 없다.


YARN
메소스랑 구조가 조금 다르긴한데 node manager-mesos agent가 대응이고 리소스 매니저가 mesos master랑 대응한다고 보면 이해하기 쉽다. 메소스처럼 노드매니저가 자원을 리소스 매니저에게 보고하는 형태이다. 
리소스 매니저가 적절한 노드 매니저들을 고르고 각 node manager들은 필요한 자원을 담은 컨테이너를 만들고 그 위에 excutor를 실행하는 방식이다. 만약 deploy mode가 cluster mode라면 node manager 중 한 곳에 spark context(main)이 뜬다.


YARN vs MESOS
두 리소스 매니저의 차이라고 한다면 옵션에서의 차이가 있다. 클라이언트 모드라고 가정을 하고 예를 들어 mesos의 경우에는 total excutor memory 를 지정할 수 있고 yarn에서는 불가능하다. 즉 mesos의 경우에는 excutor memory와 total memory를 지정함으로써 excutor의 갯수를 조절할 수 있다. coarse-grained라서 잘 조절해야 한다.
반면에 YARN에만 있는 기능은 queue를 지정할 수 있다는 것이다. 즉 node manager를 각 queue에 할당하여 배치용, 분석용 등으로 클러스터를 나누어 사용할 수 있다. 장점이라면 queue를 나누더라도 YARN UI 한 곳에서 볼 수 있다는 것이 장점이다. 그런데 그렇게 따지면 mesos도 설치 시 구간을 분할해서 띄운다면 똑같이 사용할 수 있기는 하다. 

정리하면 옵션 넣는 것의 차이와 queue 나눌 수 있는지 여부가 차이라고 본다.
사용자 측면에서는 yarn과 mesos 어떻게 사용하느냐에 따라 양쪽 모두 똑같이 사용이 가능하기 때문에 딱히 뭐가 더 좋냐는 것은 무의미한 것 같다. 어차피 쓰는 사람 입장에서는 리소스 매니저보다 자원 배분을 잘하는 것이 더 중요하기 때문이다.

만약 두개를 병행해서 쓴다는 것은 굳이..? 인것같고 만약 여러 팀과 나눠서 사용한다면 yarn, 단일 팀에서 모든 배치를 관할한다면 mesos를 추천하고 싶다. 

2020년 12월 4일 금요일

apache mesos를 세팅하면서

resource manager 중에 yarn vs mesos 뭐가 더 좋은지는 모르겠지만 mesos가 ui 부분에서는 확실히 이쁜 것 같다. 자원도 이쁘게 할당하고 현재 connect된 agent(slave)와 task 각각의 상태를 보는 것이 편리하다. 


물론 사용할 기능적인 측면에서 yarn과 mesos는 100% 같다고 볼 수 있기는 하지만 가장 큰 차이점은 ui의 깔끔함 정도라고 생각을 한다. 찾아봐도 딱히 어떤 것이 좋다 할 수는 없고 대부분의 배치를 mesos로 돌리기 때문에 그런 것 일테지만 어쨌든 개인적으로는 mesos가 더 마음에 든다.

포스팅 시점으로 1.11.0 버전이 최신이다. 설치는 가이드 문서를 참고다. 



완전히 새로 세팅된 OS에서 깔끔하게 offline으로 설치를 하려고 빌드를 하고 실행을 해보면 결국 libaprutil-1.so.0 등의 수 많은 dependency가 없다는 에러때문에 실행이 되지않는다. 따라서 결국에는 가이드 문서에서 요구하는 dependency를 만족시키기 위해서는 초반에 OS를 설치하고 /usr/lib64에 설치될 dependency를 마구마구 설치해도록하자. 


mesos의 경우 zookeeper를 활용하여 HA를 구성하고 마스터는 2대 이상으로 구성을 한다.
master 3대, 나머지는 agent로 생각을하고 그냥 올리면 된다.

빌드를 한 곳에 실행 스크립트가 생기고 각 마스터 3대에서 아래처럼 마스터를 실행한다.
./mesos-master.sh --work_dir=/data01/sw/mesos --logging_level=ERROR --log_dir=/appData01/mesos/log --zk=zk://master1:2181,master2:2181,master3:2181/mesos --quorum=2 --cluster=test-mesos-cluster &
마스터가 3대이기 때문에 quorum은 2로 한다. 만약 2대일 경우 1로 주면 된다.

나머지 서버에서는 agent를 실행한다.
./mesos-slave.sh --master=zk://master1:2181,master2:2181,master3:2181/mesos --work_dir=/data01/mesos --resources='cpus:40;mem:112640' --logging_level=ERROR --no-systemd_enable_support &

resources 옵션을 통해서 해당 서버에서 cpu, gpu, memory, disk 등을 얼마나 포함할건지를 줄 수 있다. 위처럼 하면 --resources='cpus:40;mem:112640' 옵션을 주면 각 agent에서 cpu가 40개, memory가 110G씩 올라온다.
위 링크 문서에서 보면 --resources='cpus:24;gpus:2;mem:24576;disk:409600;ports:[21000-24000,30000-34000];bugs(debug_role):{a,b,c}' 옵션을 줄 수 있는데 port range와 role을 줄 수 있는데 이를 잘 사용한다면 설계할 때 최적으로 설계를 할 수 있을 것이다. 하지만 mesos cluster를 분리해서 운영하는게 더 관리하기는 편해보인다.

마지막으로 spark job을 수행할 때 --master 옵션을 다음처럼 주면 된다. 
--master mesos://zk://master1:2181,master2:2181,master3:2181/mesos

즉 전체를 예로 들면 다음과 같다.

bin/spark-submit \
--master mesos://zk://master1:2181,master2:2181,master3:2181/mesos \
--executor-memory 32G \
--driver-memory 32G \
--class "aaa" \
--total-executor-cores 300 \
/jar_path/test-assembly-1.0.jar

그리고 코드 상에서는 예를 들어 spark.executor.cores 같은 옵션을 통해 각 익스큐터당 자원을 잘 할당할 수 있고 이는 task가 한쪽 서버에 안몰리고 이쁘게 잘 펼쳐져서 배치가 돌 것 이다. 이 부분은 추후에 포스팅을 이어서 해보려고 한다.




2022년 회고

 올해는 블로그 포스팅을 열심히 못했다. 개인적으로 지금까지 경험했던 내용들을 리마인드하자는 마인드로 한해를 보낸 것 같다.  대부분의 시간을 MLOps pipeline 구축하고 대부분을 최적화 하는데 시간을 많이 할애했다. 결국에는 MLops도 데이...