2022년 회고

 올해는 블로그 포스팅을 열심히 못했다. 개인적으로 지금까지 경험했던 내용들을 리마인드하자는 마인드로 한해를 보낸 것 같다. 

대부분의 시간을 MLOps pipeline 구축하고 대부분을 최적화 하는데 시간을 많이 할애했다. 결국에는 MLops도 데이터엔지니어링의 한 부분이라고 생각이 들고 기존에 수집-저장-가공-처리 부분에서 가공-처리 부분에 속하는 부분이지 않을까 생각이 든다. 

SSG.COM에서 현대카드로 이직한지 2년 정도가 되었는데 확실히 금융권과 e커머스와는 분위기가 많이 다르지만 배울 부분도 많았다. 그리고 기술스택이나 개발의 자율성보다 제일 중요한 것은 역시 좋은 사람들과 일하는 것이고 만족하게 한해를 보냈다. 그리고 개발적인 부분은 할 수 있는 부분 안에서 내가 어떻게든 새로운 걸 찾아서 한다면 꾸준히 성장 할 수 있다고 생각한다.

결론은 올해는 리마인드의 해였다면 내년에는 새로운 것을 찾아서 재밌는 일들을 해봐야겠다. 2023년 계묘년도 화이팅해보자.

블로그 조회수는 포스팅이 없어서 유지만 되고 있다. 내년에는 포스팅 좀 열심히 해봐야겠다.

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를 추천하고 싶다. 

airflow multi cluster 구축 및 고려할 점

다수의 모델을 트레이닝 및 전/후 처리하기 위한 상황을 가정하였다. (최소 100개이상)

대부분의 스케쥴러가 muti cluster를 통해 worker를 옆으로 확장시킬 수 있는 구조이다.

airflow 역시 celery excutor를 통해 손쉽게 확장이 가능한 구조이다.

고사양의 서버 1대라면 문제없이 local excutor로 한 대의 서버에서 모든 작업을 처리할 수 있겠지만 그렇지 않을 경우에는 celery excutor를 통해 다중 서버에서 worker가 작업을 처리할 수 있다. 

포스팅을 위해 집 컴퓨터로 vm을 띄워서 3대 클러스터로 구성을 했는데 큰 문제없이 잘 수행이 되었다. 

node 1: postgresql, redis, airflow webserver, airflow scheduler, airflow flower, airflow worker(queue1)

node 2: airflow worker(queue2)

node 3: airflow worker(queue3)

celery excutor를 활용하기 위해 airflow meta db는 postgresql.

queue 역할은 redis.

그리고 queue ui를 위한 airflow flower.

그리고 queue 이름을 q1, q2, q3으로하여 구동했다.

airflow worker -q q1 -D

airflow worker -q q2 -D

airflow worker -q q3 -D

이렇게 구성 후 가장 기본인 dag 파일에서 bash operator를 사용하여 q1, q2, q3에 분배 테스트를 진행했는데 잘 되었다. 하지만 실무에서는 dag가 훨씬 복잡할 것이다.

그리고 subdag을 병렬로 heavy하게(수천개) 돌릴 경우 parallel 옵션을 넉넉히 주고 pool도 잘 나눠서 조절해야 task들이 멍때리지 않는다. 잘못 설계할 경우 상위 task들이 pool을 다 잡아먹고 process가 full차서 멍때리는걸 경험했다. -중요-