Azure HackFest 2018.11.28 - Batch

in Etc / Cloud on Review, Azure


2018년 11월 28일, 29일 양일간 Microsoft와 직방의 HackFest가 진행되었습니다.

풀고자 하는 문제는 다음과 같았습니다.

직방에서는 현재 시세를 머신러닝을 이용하여 생성하는데 AWS Batch 서비스 사용하여 진행하고 있습니다. 다양한 모델을 개발하기 위해서는 여러가지 실험이 필요한데, 그 과정을 자동화하고 싶었습니다. n개의 Train Data를 m개의 Model로 학습하여 m x n개의 결과를 만들어 내는 과정을 자동화하고자 Azure Batch에서 구현으로 이번 HackFest를 진행했습니다.

As-Is

시세 데이터 생성을 위한 데이터 전처리 및 여러 과정들을 AWS Batch를 이용하여 진행합니다. 그 결과 생성된 Train Data를 S3에 저장을 하며 이것을 이용하여 Model을 훈련 시킬 때 AWS Batch를 이용하거나 EC2 상에서 실행을 시켜 그 결과를 다시 S3에 저장합니다. AWS Batch 실행은 미리 만들어 놓은 Python Script로 실행을 하며, Model이나 학습방법에 수정이 필요한 경우에는 EC2에서 Jupyter Notebook을 실행한 다음 접속해서 진행합니다. 아직 여러 개의 Train Data로 여러 Model에서 학습을 하는 과정은 자동화하지 않은 상태입니다.

To-Be

아직 자동화하지 않은 m x n개의 결과를 만드는 과정을 Azure Batch를 이용하여 구현하고자 합니다. S3에 저장되어 있는 parquet형식의 Train Data를 Azure Blob Storage (이하 BS로 표기)로 복사를 해와서 해당 BS를 Azure Batch에서 Azure Container Registry에 등록된 Docker Image 실행시 연결(mount)하여 Model을 훈련시킵니다. 그 결과를 다시 BS에 저장을 한 뒤, S3로 복사를 하게 합니다.

이 과정을 최대한 자동화하는 것을 목표로 합니다. 단, 이번 범위에서 Azure에 Infrastructure를 배포하는 것을 Code화하는 것은 제외하였습니다. 그것까지 준비하기에는 시간이 부족할거라는 판단이었습니다. 그래서 관련 세팅은 Azure Portal에서 직접하였습니다.

사용한 Azure Service

Azure Blob Storage

Azure Blob Storage는 AWS S3와 같은 Network Storage입니다. 생성시 Storage Account를 먼저 생성하여 그 안에 추가를 하는 형태입니다.

Portal에서 직접 작업하는 것 보다는 Azure Storage Expoler를 다운로드 받아서 사용하는 것이 훨씬 더 편리합니다.

Data Factory

Azure Data Factory는 데이터 파이프라인을 만들어서 실행 (즉시 실행 / 예약 실행 / 스케줄링) 및 모니터링하는 툴입니다.

S3 와 BS의 데이터 연동을 위하여 사용하였습니다. 하지만 S3에서 BS로의 복사는 지원하였으나 그 반대를 지원하지 않았습니다. 그래서 할수없이 BS에서 S3로의 복사를 위해서는 AWS SDK를 이용해서 업로드하는 코드를 사용했는데, 해당 코드에 AWS의 credential 정보가 당연히 필요합니다. credential 정보를 Data Factory, 다시 S3로 복사하는 코드 이 두군데 두는것 자체가 관리 포인트가 늘어나는 것이라서 HackFest 과정에서는 Data Factory를 사용했지만, 실제 운영시에는 사용하지 않을것 같습니다.

Azure Container Registry

Azure Container Registry는 Private Docker Image를 관리하는 서비스입니다. AWS ECR과 거의 비슷합니다.. ECR은 하나의 Registry에 하나의 이미지를 버전별로 관리가 가능한 형태이지만, ACR은 하나의 Registry내에 여러 개의 Repository를 둘 수 있다습니다.

사용은 ECR이 더 편리합니다. 큰 문제는 아니지만, ECR은 View Push Commands 상에 나온 명령어를 그대로 Copy & Paste만 하면 되는데, ACR에서는 Quick Start를 눌러서 나오는 Script를 참고하여 수정을 해야하는 불편함이 있습니다.

Azure Batch

Azure Batch는 배치작업에 최적화된 서비스입니다. 작업간의 dependency 적용이 가능하며, 해당 작업 동안 VM을 많이 사용해서 빠르게 작업완료한 뒤 모두 내리는 방식으로 수행이 가능합니다. Portal에서는 Key만 생성한 뒤 Task, Pool의 배포 및 삭제는 Batch Shipyard를 통해서 했으며, 상태 확인은 Azure Batch Explorer를 이용하였습니다.

Azure Virtual Machine

이번 작업에 Azure Virtual Machine를 사용한 이유는 Batch Shipyard를 실행하는 용도였습니다. 개인PC에 Batch Shipyard를 설치해서 실행해도 되지만, 내가 아닌 다른 사람이 작업을 하는 경우도 고려해야하기 때문에 VM에 설치 및 관련 설정을 다 해두었습니다.

HackFest 진행

2018년 11월 28일에는 직방(종각역 위치)에서 진행하였습니다. Microsoft Korea, SCK Corp, DS-eTrade 3사에서 엔지니어분들이 오셔서 도와주셨습니다. 오전 시간에는 Azure 서비스들에 대한 교육을 해 주셨으며, 오후에는 준비해오신 Tutorial을 진행하면서 Azure 사용에 대해서 전반적으로 이해하는 시간을 가졌습니다.

HackFest 사진

29일에는 Microsoft 광화문 오피스 11층으로 가서 진행을 하였습니다. 전날 진행하던 Tutorial을 마저 진행한 뒤, 직방에서 구축하고자 했던 Batch 시스템 구축을 성공하였습니다. 모든 구축이 완료 된 뒤 회고 시간을 가졌으며, 앞으로 더 시스템을 개선하기 위한 사항들에 대해서도 조언을 들을 수 있었습니다.

Azure vs AWS ?

이번 HackFest를 진행하면서 Azure 서비스를 이용하면서 느낀점을 그동안 많이 사용해 왔던 AWS와 비교해가면서 설명하고자 합니다. 어디까지나 개인적인 판단입니다.

한마디로 AWS는 친절하다. 그냥 시키는대로 사용하면 된다. 라고 표현할수 있습니다. 단 시키는대로 해야지, 거기에 수정을 해야하는 것은 지원되지 않을 수도 있습니다.

Azure는 뭘 좋아하는지 몰라서 모두 준비했어.라는 표현이 가장 적절한것 같습니다. 굉장히 다양한 설정이 가능합니다. 하지만, 각 설정의 default값이 내가 예상한 그 값이 아닐때가 종종 있어서 좀 당황한 적이 있었습니다.

  1. Azure Batch 관련 작업시 ACR에서 가져온 Docker Image에서의 default_working_dir의 default값이 batch였습니다. ECR을 포함하여 개인PC상의 Docker 사용시에도 container 기준으로 실행되는데 왜 기본설정 자체를 그렇게 하지 않았는지 이해가 되지 않습니다.

  2. Azure Batch의 Pool을 생성할 때도 vm_count값이 늘 켜져있는 VM의 개수였으며, autoscale값을 추가로 설정가능하였습니다. Batch Job이라면 Service나 App같이 항시 떠있어야 할 것이 아니라 실행할때만 자원을 사용하고 다시 해제하는 식으로 동작하는게 대부분일텐데 왜 저렇게 설정을 했는지 이해가 되지 않습니다. AWS Batch의 경우에는 Job Queue에 설정한 EC2들을 평상시에는 모두 사용하고 있지 않다가 작업을 실행할때 필요한 만큼만 순서대로 켜서 동작하며 작업완료 후 일정 시간동안 추가로 요청하는 작업이 없으면 해제하는 방식으로 동작합니다. Azure Batch의 경우에도 기본 설정 자체를 autoscale에서 설정하는 값대로 하고, 추가로 늘 켜져있어야 하는 VM의 설정이 가능하게 하는 것이 더 이해하기 쉽지 않을까 생각됩니다.

AWS Batch에서는 수행하기 힘든 것 중 Azure Batch에서 지원되는 것들도 있었습니다. m x n 실행을 위해서 해당 작업을 별도의 Script로 작업할 필요 없이 jobs.yaml상의 설정만으로 가능했습니다. AWS Batch에서는 작업 간의 dependency 설정이 하나의 작업밖에 설정이 안되어서 여러개의 작업이 모두 끝난 후에 실행을 해야하는 작업에 대해서는 병렬성을 최대한 살려서 할 수 있는 방법이 없었는데, Azure에서 가능한지에 대해서는 아직 찾아보지 않았습니다. 아마도 뭘 좋아할지 몰라서 모두 준비해둔 Azure에서는 되지 않을까라고 예상은 됩니다.

마치며…

이번 HackFest를 통해서 Azure Batch를 수행하기 위해서 필요한 서비스 및 사용방법에 대해서 전반적으로 익힐수 있었습니다. Batch 작업의 경우 항시 동작해야하는 Service와는 달라서 특정 Cloud Platform 상에서 꼭 수행해야 한다는 제약사항이 훨씬 더 적기 때문에 기존 회사내에서 주로 사용하는 Cloud Platform과는 별도로 구축하기 가장 적합합니다. 이번 기회를 통해서 여러 가지 작업들을 Azure 상에서 적용을 해봐야 겠습니다.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)