<div id="readability-page-1" class="page"><div><div><p id="d8fb"><strong>그런데 이제 GPU와 Neuron을 곁들인</strong></p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*IVZy9sar-X0kjjqg" width="700" height="350" role="presentation"></p></div></figure><p id="9b17">안녕하세요. 무신사 SRE(<a href="https://sre.google/" rel="noopener ugc nofollow" target="_blank">Site Reliability Engineering</a>) 팀에서 Amazon Web Services (이하 AWS) 기반 인프라 운영과 인프라 플랫폼 개발을 담당하고 있는 구본협입니다.</p><p id="55b4">무신사는 대량의 데이터를 모두 AWS에서 수집, 처리하고 있습니다. 무신사 개발 조직은 데이터에서 얻은 통찰력을 기반으로 고객과 비즈니스 요건에 실시간 대응할 수 있는 애플리케이션을 개발해 무신사라는 하나의 서비스를 만들어가고 있습니다.</p><p id="2524">이 때 수집되는 각양각색의 데이터는 데이터 파이프라인의 양과 복잡성을 동시에 증가시킬 수 있습니다. 그래서 무신사는 프로세스를 작은 테스크 단위로 나누어 해소할 수 있는 워크플로우 기반의 데이터플랫폼을 클라우드 인프라의 장점이 자연스럽게 이식된 상태로 사용하는 방법에 관해 고민하기 시작했습니다.</p><p id="b376">이러한 고민을 완벽히 해결한 것은 아니지만, 비슷한 고민을 하고 있을 개발자나 엔지니어 분들에게 무신사에서 시도한 방법이 도움이 되었으면 합니다.</p></div><div><h2 id="aa89"><strong>Apache Airflow 어떻게 사용하고 있을까?</strong></h2><p id="e9a5">Apache Airflow와 Amazon EKS를 만나기 전에 앞서, 개발팀마다 조금씩 다르게 사용하고 있는 데이터플랫폼 Apache Airflow을 어떤 방법으로 사용하고 구성했는지 간략하게 설명드리겠습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*V8G0Y6d9ooYV5-A6H_UZIg.png" width="700" height="427" role="presentation"></p></div><figcaption>여러 모습의 Apache Airflow는 모두 AWS에서 운영되고 있습니다.</figcaption></figure><h2 id="713b">1. Apache Airflow on Amazon Elastic Compute Cloud (이하 Amazon EC2)</h2><p id="9d3f">AWS EC2에 Ansible을 이용하여 Apache Airflow 구성에 필요한 모듈 서비스는 프로세스와 데몬으로 동작할 수 있도록 코드로 관리하고, Bash Operator를 통해 Amazon Simple Storage Service (이하 Amazon S3)에서 Directed Acyclic Graphs (이하 DAG’s) 코드의 싱크를 맞출 수 있도록 구현하여 사용하고 있습니다.</p><h2 id="871a">2. Amazon Managed Workflows for Apache AIrflow (이하 Amazon MWAA)</h2><p id="bc14">Amazon MWAA는 2021년 8월 31일에 서울 리전에 정식 출시되었는데요. 정식 출시 이후 바로 1주간의 PoC(Proof of Concept)를 거친 후, AWS 콘솔을 통하여 Amazon MWAA가 동작할 수 있도록 구성을 하였습니다. AWS 콘솔을 통하여 구성한 이유는 빠르게 적용하기 위함이었으나, 마찬가지로 코드로 관리될 수 있도록 Terraforming (테라포밍)을 진행하였습니다. (Amazon MWAA는 조금 더 편리하게, Amazon S3에서 DAG 파일을 관리할 수 있는 장점이 있습니다.)</p><h2 id="08df">3. Apache Airflow on Amazon EKS</h2><p id="7e24">Apache Airflow는 총 두가지의 Helm Chart를 지원하고 있는데요. (<a href="https://github.com/airflow-helm/charts/tree/main/charts/airflow" rel="noopener ugc nofollow" target="_blank">User Community</a>, <a href="https://airflow.apache.org/docs/helm-chart/stable/index.html" rel="noopener ugc nofollow" target="_blank">Offical</a>) 무신사는 User Community Helm Chart를 이용하여 Amazon EKS에 구성하였습니다. Python Operator, Kubernetes Operator를 사용하여 가능한 Kubernetes Native하게 DAG’s을 구성하였고, 나아가 GPU와 AWS Inferentia 칩을 이용한 학습을 위하여 nvidia-device-plugin과 neuron-device-plugin도 같이 사용하였는데요. 이와 관련한 자세한 이야기를 다음 문단에서 다뤄보도록 하겠습니다.</p></div><div><h2 id="b388">Apache Airflow on Amazon EKS 톺아보기</h2><p id="bb59">Apache Airflow가 Amazon EKS에서 안정적으로 랜딩되어 GPU와 Neuron을 함께 동적으로 사용할 수 있는 환경을 구성한 여정에 대해 이야기 해보겠습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*-TQP0b4TXQ9uHmSm" width="700" height="416" role="presentation"></p></div><figcaption>Apache Airflow, GPU, Neuron과 함께하는 Amazon EKS</figcaption></figure><h2 id="743f">1. Helm Chart를 이용한 Apache Airflow 설치</h2><p id="ccb8">Apache Airflow <a href="https://github.com/airflow-helm/charts/tree/main/charts/airflow" rel="noopener ugc nofollow" target="_blank">User Community</a> 의 Helm Chart를 사용하면서 어떤 부분을 커스터마이징했는지 아래의 <strong>value.yaml</strong> 파일을 같이 살펴보도록 하겠습니다.</p><pre><span id="528d">airflow:<br>  image:<br>    repository: xxxxxxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/apache/airflow<br>    tag: x.x.x-python3.x</span><span id="3aa2">// 최근 도커 허브의 이미지 풀 이슈로 인하여, SRE팀에서는 모든 Container 이미지를 Amazon Elastic Container Registry (이하 Amazon ECR) 저장하고 있습니다.</span><span id="161e">config:<br>  AIRFLOW__LOGGING__LOGGING_LEVEL: INFO<br>  AIRFLOW__LOGGING__REMOTE_LOGGING: "True"<br>  AIRFLOW__LOGGING__REMOTE_BASE_LOG_FOLDER: "s3://xxxxxx/airflow-log/"<br>  AIRFLOW__LOGGING__ENCRYPT_S3_LOGS: "False"<br>  AIRFLOW__LOGGING__REMOTE_LOG_CONN_ID: "aws_default"</span><span id="c7a4">// Apache Airflow의 리모트 로깅에 대한 전반적인 정의를 할 수 있고, 무신사는 Amazon S3를 사용했습니다. 추가로, Amazon CloudWatch를 사용한다면 “cloudwatch://”로 시작해야합니다.<br>또한, 리모트 로깅이 완료되려면 LOG_CONN_ID의 “aws_default” 값과 동일한 Airflow Web에서 Conn Id를 생성하고, Extra에 적절한 리전명을 설정해야 에러로그가 사라진 Airflow Web을 확인할 수 있습니다.</span><span id="ae42">securityContext:<br>      fsGroup: 65534</span><span id="08ba">// Amazon EKS에서 IAM roles for service accounts(이하 IRSA) 기능을 사용하기 위하여 컨테이너 유저가 루트가 아닌 상태(non-root user)로 실행되었을 경우, “fsGroup: 65534”를 통하여 컨테이너가 토큰을 읽을 수 있도록 설정해야합니다.</span><span id="c763">affinity:<br>      nodeAffinity:<br>        requiredDuringSchedulingIgnoredDuringExecution:<br>          nodeSelectorTerms:<br>          - matchExpressions:<br>            - key: xxxx<br>              operator: In<br>              values:<br>              - xxxx<br>    tolerations:<br>      - key: xxxx<br>        operator: Equal<br>        value: xxxx<br>        effect: NoSchedule</span><span id="e2e4">// Apache Airflow 모듈 서비스들을 특정 Amazon EKS Nodes에 랜딩하고자 하는 니즈가 있을 수도 있는데, 이때는 쿠버네티스(이하 K8s)의 Scheduling(스케줄링) 기능인 nodeAffinity (노드 어피니티), tolerations(톨러레이션), taint(테인트) 등을 적절히 사용한다면 보다 짜임새있는 Amazon EKS 운영이 가능합니다.</span><span id="9f20">gitSync:<br>    enabled: true<br>    image:<br>      repository: xxxxxxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/git-sync/git-sync<br>      tag: v3.x.x</span><span id="0115">// 마찬가지로 컨테이너 이미지를 Amazon ECR에 저장하고, 위의 “true” 옵션으로 인하여 Apache Airflow 모듈 서비스들과 함께 dags-git-sync가 사이드카 컨테이너로 운영됩니다.<br>dag-git-sync 사이드카 컨테이너를 활용한다면, 개발팀의 Git Repository(깃 레파지토리)와 DAG’s 코드를 자동으로 동기화하여 GitOps의 느낌도 살짝 엿볼 수 있습니다.</span><span id="a575">resources:<br>     requests:<br>       cpu: "xxm"<br>       memory: "xxMi"<br>     limits:<br>       cpu: "xxm"<br>       memory: "xxMi"</span><span id="c9be">// Pod (파드)의 리소스 사용량을 조금 더 효율적으로 관리하고자 한다면, 위와 같이 CPU와 메모리를 선언적으로 할당합니다.</span><span id="af16">repo: "<a href="https://xxx.xxx/airflow/dag.git" rel="noopener ugc nofollow" target="_blank">https://xxx.xxx/airflow/dag.git</a>"<br>    repoSubPath: "dags"<br>    branch: main</span><span id="787b">// DAG’s 코드가 저장되어있는 Git Repository의 주소와 어떤 브랜치를 기준으로 동기화할 지 설정합니다.</span><span id="7830">httpSecret: "xxxxx"<br>    httpSecretUsernameKey: xxxxx<br>    httpSecretPasswordKey: xxxxx</span><span id="a934">// 위의 Git Repository에 정상적으로 접근하여 동기화를 하려면 유효한 계정이 필요한데, 미리 생성된 계정의 정보로 K8s의 Secret(시크릿)을 사용하여 구성이 가능합니다.</span><span id="3d94">annotations:<br>    eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxx:role/xxxxx</span><span id="4b14">// eks.amazonaws.com/role-arn 어노테이션으로 하여금 IRSA 통해 Pod에 필요한 AWS Identity and Access Management(이하 IAM) 권한을 제어할 수 있습니다.</span><span id="d029">podLabels: {<br>    "app": "airflow"<br>  }</span><span id="0c7c">// Pod의 Labels(레이블)을 선언으로 Amazon EKS의 Security group for pods 기능을 사용할 때 Selector(셀렉터)를 보다 쉽게 적용할 수 있습니다.</span><span id="6975">externalDatabase:<br>  type: xxxx<br>  host: xxx<br>  port: xxxx<br>  database: xxxxx<br>  user: xxxxx</span><span id="7832">// Apache Airflow 모듈 서비스들에서 사용할 데이터베이스를 정할 수 있는데, 위의 옵션은 외부 데이터베이스를 사용하는 경우이며, postgresql를 모듈 서비스로 사용할 수 있습니다.</span><span id="1ee4">passwordSecret: "xxxxxx"<br>  passwordSecretKey: "xxxxxx"<br>  properties: "?charset=utf8"</span><span id="b2d7">// 마찬가지로 데이터베이스에 접근하여야 하는 경우 유효한 계정이 필요한데, 미리 생성된 계정의 정보로 K8s의 Secret(시크릿)을 사용하여 구성이 가능합니다.</span></pre><h2 id="0c69">2. 기억에 남는 트러블슈팅</h2><p id="8a78">무신사의 Amazon EKS 인프라는 기존 네트워크 구조, 관리 정책을 크게 벗어나지 않고 Pod의 IP를 AWS EC2와 같은 레이어로 인식할 수 있도록 사용이 가능한 Amazon VPC CNI의 Security group for pods 기능을 채택하고 있습니다.</p><p id="171f">이 기능을 사용하는데 있어 Apache Airflow와 어떤 부분에서 이슈가 있었는지 아래의 <strong>securitygrouppolicy.yaml</strong> 를 보면서 설명드리도록 하겠습니다.</p><pre><span id="6674">apiVersion: vpcresources.k8s.aws/v1beta1<br>kind: SecurityGroupPolicy<br>metadata:<br>  name: xxxx-sg<br>  namespace: 'xxxxx'<br>spec:<br>  podSelector:<br>    matchLabels:<br>      app: airflow<br>  securityGroups:<br>    groupIds:<br>      - sg-xxxxxxxxxx</span><span id="cc92">// 보통 위처럼 PodSelector의 matchLabels를 통하여 Pod에 Security Group을 매핑하고 있습니다.</span></pre><p id="91d8">문제는 위의 Pod에 Security Group (보안 그룹)을 매핑한 방식이었습니다. DAG’s Pod의 Labels이 사용하고 있는 Operators (Python Operator, Kubernetes Operator) 마다 조금씩 달라서 하나로 통일해야하는 Needs가 발생했습니다. 이는 K8s의 추가적인 Selector와 Labels 기능으로 해결하거나 Operators (Python Operator, Kubernetes Operator)를 사용하여 하나로 깔끔하게 통일할 수 있는 공통의 Custom labels을 작성하는 방법으로 해결할 수 있는데요.</p><p id="5cc8">무신사는 후자를 선택했습니다. 그 이유는 이미 Operators (Python Operator, Kubernetes Operator)로 K8s의 스펙을 사용하고 있었기에 적용이 조금 더 친숙했고, DAG’s Pod에서도 공통의 Custom Labels을 가지고 있으면 향후 필요 시 디스커버리 목적의 리소스 매니지먼트 포인트 중 하나로 사용할 수 있지 않을까 싶었습니다.</p><pre><span id="921b">python_op_resource_config = {"KubernetesExecutor": {<br>    "namespace": {"airflow"}, "labels": {"Environment": "devel"},<br>}}</span><span id="fc54">// Python Operator에서 KubernetesExecutor를 사용하여 Labels을 적용했습니다.</span><span id="5ebe">execute_train_detection_task = KubernetesPodOperator(<br>        labels={"train": "detection", "Environment": "devel"},</span><span id="c917">// Kubernetes Operator에서 KubernetsPodOperator를 사용하여 Labels을 적용했습니다.</span></pre></div><div><h2 id="a333">GPU, 그리고 Neuron.</h2><p id="dfc7">마지막으로 GPU와 Neuron을 사용하려면 필요한 것과 어떤 이유로 GPU와 Neuron를 사용하게 되었는지 이야기 해보겠습니다.</p><h2 id="5c17">1. GPU를 사용하려면?</h2><p id="ff8b">GPU를 지원하는 AWS EC2 인스턴스 타입 뿐만 아니라 AMI Type 또한 GPU를 지원해야합니다.</p><p id="8312">또한, GPU를 Amazon EKS에서 사용하려면 K8s 전용의 NVIDIA device plugin이 필요합니다.</p><p id="2604">이 아래의 명령어를 통하여 NVIDIA device plugin은 DaemonSet (데몬셋)으로 바로 설치·배포가 가능하지만, 앞서 간단하게 이야기한 K8s Scheduling을 함께 적용하다면 조금 더 리소스를 효율적으로 관리할 수 있습니다.</p><pre><span id="a712">$ kubectl create -f<br><a href="https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.10.0/nvidia-device-plugin.yml" rel="noopener ugc nofollow" target="_blank">https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.10.0/nvidia-device-plugin.yml</a></span><span id="4c22">// K8s 전용의 NVIDIA device plugin을 DaemonSet으로 배포하여 각 AWS EKS Worker Node에 Pod를 위치할 수 있도록 합니다.</span></pre><p id="a8ac">위의 구성으로 설치·배포가 정상적으로 완료되었다면, 아래처럼 Pod의 리소스 중 GPU를 선언적으로 할당하여 사용할 수 있도록 합니다.</p><pre><span id="f56f">resources:<br>  limits:<br>    nvidia.com/gpu: 1<br>  requests:<br>    nvidia.com/gpu</span><span id="4a60">// CPU와 달리 GPU는 Pod간의 GPU 공유를 지원하지 않고, K8s 공식 문서에서도 최소 1개이상의 GPU를 할당해야한다고 가이드하고 있습니다.</span></pre><h2 id="2271">2. Neuron을 사용하려면?</h2><p id="0c2f">AWS Neuron은 AWS Inferentia 칩을 사용하여 기계 학습 추론을 실행하기 위한 SDK입니다. Neuron을 지원하는 AWS EC2 인스턴스 타입과 AMI (이하 Amazon Machine Image) Type도 Neuron을 지원해야합니다.</p><p id="b6a6">또한, Neuron를 Amazon EKS에서 사용하려면 K8s 전용의 Neuron device plugin이 필요합니다. 이 아래의 명령어를 통하여 NVIDIA device plugin은 DaemonSet으로 바로 설치·배포가 가능하지만, 앞서 간단하게 이야기한 K8s Scheduling을 함께 적용하면 조금 더 리소스를 효율적으로 관리할 수 있습니다.</p><pre><span id="47b4">$ kubectl create -f https://awsdocs-neuron.readthedocs-hosted.com/en/latest/_downloads/46fb1da6e5e79c3310ebc0cbd6ad2353/k8s-neuron-device-plugin-rbac.yml</span><span id="603c">$ kubectl create -f https://awsdocs-neuron.readthedocs-hosted.com/en/latest/_downloads/f57f27621e52b305dba7d624c477977a/k8s-neuron-device-plugin.yml</span><span id="563d">// K8s 전용의 Neuron device plugin을 DaemonSet과 Role Based Access Control (역할 기반 권한 제어)를 배포하여 각 AWS EKS Worker Node에 Pod를 위치할 수 있도록 합니다.</span></pre><p id="f7b0">위의 구성으로 설치·배포가 정상적으로 완료되었다면, 아래처럼 Pod의 리소스 중 Neuron을 선언적으로 할당하여 사용할 수 있도록 합니다.</p><pre><span id="8ad3">resources:<br>  limits:<br>    aws.amazon.com/neuron: 1<br>  requests:<br>    aws.amazon.com/neuron: 1</span><span id="bc3e">// GPU와 마찬가지로 neuron 또한 최소 1개이상의 neuron 할당을 권장하고 있습니다.</span></pre><h2 id="fd89">3. 두가지를 고민한 이유</h2><p id="899f">GPU와 Neuron 중 하나를 선택하는 것은 비용과 효율 두가지 측면에서 모두 고민이었습니다.</p><p id="b7f2">GPU와 Neuron이 최대 1개만 지원하는 AWS EC2 인스턴스 타입을 여러대로 사용하려고 하니, K8s의 장점인 리소스 매니지먼트를 활용하지 못하는 것 같다는 생각도 들었습니다. 결국 GPU와 Neuron이 최소 1개를 초과하는 AWS EC2 인스턴스 타입을 찾아 비용과 효율을 고민하였으나, 생태계가 다른 두가지를 적절히 비교하기가 쉽지 않았습니다. 결론은 상황과 Needs에 맞춰 유연하게 사용하기 위해 GPU와 Neuron 두가지 모두 채택하여 사용하고 있습니다.</p></div><div><h2 id="a482"><strong>마치며</strong></h2><p id="8e7e">지금까지 비슷하지만 조금씩은 다른 워크플로우 기반의 데이터플랫폼을 무신사 인프라 환경에 적절하게 사용하기 위한 과정에 대해 소개해드렸습니다.</p><p id="4888">Apache Airflow와 Amazon EKS가 만나면서 큰 관점에서 개발 효율성과 생산성은 Apache Airflow의 DAG’s 코드 템플릿을 통하여 높아졌습니다. 또한, 리소스 매니지먼트와 유지 보수 비용은 Amazon EKS의 Kubernetes 통하여 낮아질 수 있다는 점도 기대할 수 있었습니다.</p><p id="df7d">이처럼 무신사 SRE팀은 무신사 개발 조직의 피드백을 무신사 인프라에 적절하면서도 효율적인 방식으로 이식하기 위해 노력하고 있습니다. 저희가 경험하고 시도한 방법들이 비슷한 고민을 하고 있는 개발자, 엔지니어분들에게 조금이나마 도움이 되었으면 합니다. 앞으로도 많은 관심과 응원 부탁드립니다!</p></div><div><h2 id="e2e2"><strong>참고</strong></h2><ul><li id="5730">Highly available Airflow cluster in Amazon AWS — <a href="https://getindata.com/blog/highly-available-airflow-amazon-aws/" rel="noopener ugc nofollow" target="_blank">https://getindata.com/blog/highly-available-airflow-amazon-aws/</a></li><li id="f98e">Kubernetes — <a href="https://kubernetes.io/" rel="noopener ugc nofollow" target="_blank">https://kubernetes.io/</a></li><li id="d7e5">Airflow Helm Chart (User Community) — <a href="https://github.com/airflow-helm/charts" rel="noopener ugc nofollow" target="_blank">https://github.com/airflow-helm/charts</a></li><li id="608d">Official Airflow Helm Chart — <a href="https://airflow.apache.org/docs/helm-chart/stable/index.html" rel="noopener ugc nofollow" target="_blank">https://airflow.apache.org/docs/helm-chart/stable/index.html</a></li><li id="83c2">NVIDIA k8s device plugin — <a href="https://github.com/NVIDIA/k8s-device-plugin" rel="noopener ugc nofollow" target="_blank">https://github.com/NVIDIA/k8s-device-plugin</a></li><li id="5c08">AWS Neuron — <a href="https://aws.amazon.com/machine-learning/neuron/" rel="noopener ugc nofollow" target="_blank">https://aws.amazon.com/machine-learning/neuron/</a></li></ul></div><div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*Dv_G5mloVd6toqUUucDzew.png" width="700" height="190" role="presentation"></p></div></figure></div></div></div>

MUSINSA tech - Medium

그런데 이제 GPU와 Neuron을 곁들인
안녕하세요. 무신사 SRE(Site Reliability Engineering) 팀에서 Amazon Web Services (이하 AWS) 기반 인프라 운영과 인프라 플랫폼 개발을 담당하고 있는 구본협입니다.
무신사는 대량의 데이터를 모두 AWS에서 수집, 처리하고 있습니다. 무신사 개발 조직은 데이터에서 얻은 통찰력을 기반으로 고객과 비즈니스 요건에 실시간 대응할 수 있는 애플리케이션을 개발해 무신사라는 하나의 서비스를 만들어가고 있습니다.
이 때 수집되는 각양각색의 데이터는 데이터 파이프라인의 양과 복잡성을 동시에 증가시킬 수 있습니다. 그래서 무신사는 프로세스를 작은 테스크 단위로 나누어 해소할 수 있는 워크플로우 기반의 데이터플랫폼을 클라우드 인프라의 장점이 자연스럽게 이식된 상태로 사용하는 방법에 관해 고민하기 시작했습니다.
이러한 고민을 완벽히 해결한 것은 아니지만, 비슷한 고민을 하고 있을 개발자나 엔지니어 분들에게 무신사에서 시도한 방법이 도움이 되었으면 합니다.
Apache Airflow 어떻게 사용하고 있을까?
Apache Airflow와 Amazon EKS를 만나기 전에 앞서, 개발팀마다 조금씩 다르게 사용하고 있는 데이터플랫폼 Apache Airflow을 어떤 방법으로 사용하고 구성했는지 간략하게 설명드리겠습니다.
1. Apache Airflow on Amazon Elastic Compute Cloud (이하 Amazon EC2)
AWS EC2에 Ansible을 이용하여 Apache Airflow 구성에 필요한 모듈 서비스는 프로세스와 데몬으로 동작할 수 있도록 코드로 관리하고, Bash Operator를 통해 Amazon Simple Storage Service (이하 Amazon S3)에서 Directed Acyclic Graphs (이하 DAG’s) 코드의 싱크를 맞출 수 있도록 구현하여 사용하고 있습니다.
2. Amazon Managed Workflows for Apache AIrflow (이하 Amazon MWAA)
Amazon MWAA는 2021년 8월 31일에 서울 리전에 정식 출시되었는데요. 정식 출시 이후 바로 1주간의 PoC(Proof of Concept)를 거친 후, AWS 콘솔을 통하여 Amazon MWAA가 동작할 수 있도록 구성을 하였습니다. AWS 콘솔을 통하여 구성한 이유는 빠르게 적용하기 위함이었으나, 마찬가지로 코드로 관리될 수 있도록 Terraforming (테라포밍)을 진행하였습니다. (Amazon MWAA는 조금 더 편리하게, Amazon S3에서 DAG 파일을 관리할 수 있는 장점이 있습니다.)
3. Apache Airflow on Amazon EKS
Apache Airflow는 총 두가지의 Helm Chart를 지원하고 있는데요. (User Community, Offical) 무신사는 User Community Helm Chart를 이용하여 Amazon EKS에 구성하였습니다. Python Operator, Kubernetes Operator를 사용하여 가능한 Kubernetes Native하게 DAG’s을 구성하였고, 나아가 GPU와 AWS Inferentia 칩을 이용한 학습을 위하여 nvidia-device-plugin과 neuron-device-plugin도 같이 사용하였는데요. 이와 관련한 자세한 이야기를 다음 문단에서 다뤄보도록 하겠습니다.
Apache Airflow on Amazon EKS 톺아보기
Apache Airflow가 Amazon EKS에서 안정적으로 랜딩되어 GPU와 Neuron을 함께 동적으로 사용할 수 있는 환경을 구성한 여정에 대해 이야기 해보겠습니다.
1. Helm Chart를 이용한 Apache Airflow 설치
Apache Airflow User Community 의 Helm Chart를 사용하면서 어떤 부분을 커스터마이징했는지 아래의 value.yaml 파일을 같이 살펴보도록 하겠습니다.
airflow:
  image:
    repository: xxxxxxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/apache/airflow
    tag: x.x.x-python3.x
// 최근 도커 허브의 이미지 풀 이슈로 인하여, SRE팀에서는 모든 Container 이미지를 Amazon Elastic Container Registry (이하 Amazon ECR) 저장하고 있습니다.
config:
  AIRFLOW__LOGGING__LOGGING_LEVEL: INFO
  AIRFLOW__LOGGING__REMOTE_LOGGING: "True"
  AIRFLOW__LOGGING__REMOTE_BASE_LOG_FOLDER: "s3://xxxxxx/airflow-log/"
  AIRFLOW__LOGGING__ENCRYPT_S3_LOGS: "False"
  AIRFLOW__LOGGING__REMOTE_LOG_CONN_ID: "aws_default"
// Apache Airflow의 리모트 로깅에 대한 전반적인 정의를 할 수 있고, 무신사는 Amazon S3를 사용했습니다. 추가로, Amazon CloudWatch를 사용한다면 “cloudwatch://”로 시작해야합니다.
또한, 리모트 로깅이 완료되려면 LOG_CONN_ID의 “aws_default” 값과 동일한 Airflow Web에서 Conn Id를 생성하고, Extra에 적절한 리전명을 설정해야 에러로그가 사라진 Airflow Web을 확인할 수 있습니다.
securityContext:
      fsGroup: 65534
// Amazon EKS에서 IAM roles for service accounts(이하 IRSA) 기능을 사용하기 위하여 컨테이너 유저가 루트가 아닌 상태(non-root user)로 실행되었을 경우, “fsGroup: 65534”를 통하여 컨테이너가 토큰을 읽을 수 있도록 설정해야합니다.
affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: xxxx
              operator: In
              values:
              - xxxx
    tolerations:
      - key: xxxx
        operator: Equal
        value: xxxx
        effect: NoSchedule
// Apache Airflow 모듈 서비스들을 특정 Amazon EKS Nodes에 랜딩하고자 하는 니즈가 있을 수도 있는데, 이때는 쿠버네티스(이하 K8s)의 Scheduling(스케줄링) 기능인 nodeAffinity (노드 어피니티), tolerations(톨러레이션), taint(테인트) 등을 적절히 사용한다면 보다 짜임새있는 Amazon EKS 운영이 가능합니다.
gitSync:
    enabled: true
    image:
      repository: xxxxxxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com/git-sync/git-sync
      tag: v3.x.x
// 마찬가지로 컨테이너 이미지를 Amazon ECR에 저장하고, 위의 “true” 옵션으로 인하여 Apache Airflow 모듈 서비스들과 함께 dags-git-sync가 사이드카 컨테이너로 운영됩니다.
dag-git-sync 사이드카 컨테이너를 활용한다면, 개발팀의 Git Repository(깃 레파지토리)와 DAG’s 코드를 자동으로 동기화하여 GitOps의 느낌도 살짝 엿볼 수 있습니다.
resources:
     requests:
       cpu: "xxm"
       memory: "xxMi"
     limits:
       cpu: "xxm"
       memory: "xxMi"
// Pod (파드)의 리소스 사용량을 조금 더 효율적으로 관리하고자 한다면, 위와 같이 CPU와 메모리를 선언적으로 할당합니다.
repo: "https://xxx.xxx/airflow/dag.git"
    repoSubPath: "dags"
    branch: main
// DAG’s 코드가 저장되어있는 Git Repository의 주소와 어떤 브랜치를 기준으로 동기화할 지 설정합니다.
httpSecret: "xxxxx"
    httpSecretUsernameKey: xxxxx
    httpSecretPasswordKey: xxxxx
// 위의 Git Repository에 정상적으로 접근하여 동기화를 하려면 유효한 계정이 필요한데, 미리 생성된 계정의 정보로 K8s의 Secret(시크릿)을 사용하여 구성이 가능합니다.
annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxx:role/xxxxx
// eks.amazonaws.com/role-arn 어노테이션으로 하여금 IRSA 통해 Pod에 필요한 AWS Identity and Access Management(이하 IAM) 권한을 제어할 수 있습니다.
podLabels: {
    "app": "airflow"
  }
// Pod의 Labels(레이블)을 선언으로 Amazon EKS의 Security group for pods 기능을 사용할 때 Selector(셀렉터)를 보다 쉽게 적용할 수 있습니다.
externalDatabase:
  type: xxxx
  host: xxx
  port: xxxx
  database: xxxxx
  user: xxxxx
// Apache Airflow 모듈 서비스들에서 사용할 데이터베이스를 정할 수 있는데, 위의 옵션은 외부 데이터베이스를 사용하는 경우이며, postgresql를 모듈 서비스로 사용할 수 있습니다.
passwordSecret: "xxxxxx"
  passwordSecretKey: "xxxxxx"
  properties: "?charset=utf8"
// 마찬가지로 데이터베이스에 접근하여야 하는 경우 유효한 계정이 필요한데, 미리 생성된 계정의 정보로 K8s의 Secret(시크릿)을 사용하여 구성이 가능합니다.
2. 기억에 남는 트러블슈팅
무신사의 Amazon EKS 인프라는 기존 네트워크 구조, 관리 정책을 크게 벗어나지 않고 Pod의 IP를 AWS EC2와 같은 레이어로 인식할 수 있도록 사용이 가능한 Amazon VPC CNI의 Security group for pods 기능을 채택하고 있습니다.
이 기능을 사용하는데 있어 Apache Airflow와 어떤 부분에서 이슈가 있었는지 아래의 securitygrouppolicy.yaml 를 보면서 설명드리도록 하겠습니다.
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: xxxx-sg
  namespace: 'xxxxx'
spec:
  podSelector:
    matchLabels:
      app: airflow
  securityGroups:
    groupIds:
      - sg-xxxxxxxxxx
// 보통 위처럼 PodSelector의 matchLabels를 통하여 Pod에 Security Group을 매핑하고 있습니다.
문제는 위의 Pod에 Security Group (보안 그룹)을 매핑한 방식이었습니다. DAG’s Pod의 Labels이 사용하고 있는 Operators (Python Operator, Kubernetes Operator) 마다 조금씩 달라서 하나로 통일해야하는 Needs가 발생했습니다. 이는 K8s의 추가적인 Selector와 Labels 기능으로 해결하거나 Operators (Python Operator, Kubernetes Operator)를 사용하여 하나로 깔끔하게 통일할 수 있는 공통의 Custom labels을 작성하는 방법으로 해결할 수 있는데요.
무신사는 후자를 선택했습니다. 그 이유는 이미 Operators (Python Operator, Kubernetes Operator)로 K8s의 스펙을 사용하고 있었기에 적용이 조금 더 친숙했고, DAG’s Pod에서도 공통의 Custom Labels을 가지고 있으면 향후 필요 시 디스커버리 목적의 리소스 매니지먼트 포인트 중 하나로 사용할 수 있지 않을까 싶었습니다.
python_op_resource_config = {"KubernetesExecutor": {
    "namespace": {"airflow"}, "labels": {"Environment": "devel"},
}}
// Python Operator에서 KubernetesExecutor를 사용하여 Labels을 적용했습니다.
execute_train_detection_task = KubernetesPodOperator(
        labels={"train": "detection", "Environment": "devel"},
// Kubernetes Operator에서 KubernetsPodOperator를 사용하여 Labels을 적용했습니다.
GPU, 그리고 Neuron.
마지막으로 GPU와 Neuron을 사용하려면 필요한 것과 어떤 이유로 GPU와 Neuron를 사용하게 되었는지 이야기 해보겠습니다.
1. GPU를 사용하려면?
GPU를 지원하는 AWS EC2 인스턴스 타입 뿐만 아니라 AMI Type 또한 GPU를 지원해야합니다.
또한, GPU를 Amazon EKS에서 사용하려면 K8s 전용의 NVIDIA device plugin이 필요합니다.
이 아래의 명령어를 통하여 NVIDIA device plugin은 DaemonSet (데몬셋)으로 바로 설치·배포가 가능하지만, 앞서 간단하게 이야기한 K8s Scheduling을 함께 적용하다면 조금 더 리소스를 효율적으로 관리할 수 있습니다.
$ kubectl create -f
https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.10.0/nvidia-device-plugin.yml
// K8s 전용의 NVIDIA device plugin을 DaemonSet으로 배포하여 각 AWS EKS Worker Node에 Pod를 위치할 수 있도록 합니다.
위의 구성으로 설치·배포가 정상적으로 완료되었다면, 아래처럼 Pod의 리소스 중 GPU를 선언적으로 할당하여 사용할 수 있도록 합니다.
resources:
  limits:
    nvidia.com/gpu: 1
  requests:
    nvidia.com/gpu
// CPU와 달리 GPU는 Pod간의 GPU 공유를 지원하지 않고, K8s 공식 문서에서도 최소 1개이상의 GPU를 할당해야한다고 가이드하고 있습니다.
2. Neuron을 사용하려면?
AWS Neuron은 AWS Inferentia 칩을 사용하여 기계 학습 추론을 실행하기 위한 SDK입니다. Neuron을 지원하는 AWS EC2 인스턴스 타입과 AMI (이하 Amazon Machine Image) Type도 Neuron을 지원해야합니다.
또한, Neuron를 Amazon EKS에서 사용하려면 K8s 전용의 Neuron device plugin이 필요합니다. 이 아래의 명령어를 통하여 NVIDIA device plugin은 DaemonSet으로 바로 설치·배포가 가능하지만, 앞서 간단하게 이야기한 K8s Scheduling을 함께 적용하면 조금 더 리소스를 효율적으로 관리할 수 있습니다.
$ kubectl create -f https://awsdocs-neuron.readthedocs-hosted.com/en/latest/_downloads/46fb1da6e5e79c3310ebc0cbd6ad2353/k8s-neuron-device-plugin-rbac.yml
$ kubectl create -f https://awsdocs-neuron.readthedocs-hosted.com/en/latest/_downloads/f57f27621e52b305dba7d624c477977a/k8s-neuron-device-plugin.yml
// K8s 전용의 Neuron device plugin을 DaemonSet과 Role Based Access Control (역할 기반 권한 제어)를 배포하여 각 AWS EKS Worker Node에 Pod를 위치할 수 있도록 합니다.
위의 구성으로 설치·배포가 정상적으로 완료되었다면, 아래처럼 Pod의 리소스 중 Neuron을 선언적으로 할당하여 사용할 수 있도록 합니다.
resources:
  limits:
    aws.amazon.com/neuron: 1
  requests:
    aws.amazon.com/neuron: 1
// GPU와 마찬가지로 neuron 또한 최소 1개이상의 neuron 할당을 권장하고 있습니다.
3. 두가지를 고민한 이유
GPU와 Neuron 중 하나를 선택하는 것은 비용과 효율 두가지 측면에서 모두 고민이었습니다.
GPU와 Neuron이 최대 1개만 지원하는 AWS EC2 인스턴스 타입을 여러대로 사용하려고 하니, K8s의 장점인 리소스 매니지먼트를 활용하지 못하는 것 같다는 생각도 들었습니다. 결국 GPU와 Neuron이 최소 1개를 초과하는 AWS EC2 인스턴스 타입을 찾아 비용과 효율을 고민하였으나, 생태계가 다른 두가지를 적절히 비교하기가 쉽지 않았습니다. 결론은 상황과 Needs에 맞춰 유연하게 사용하기 위해 GPU와 Neuron 두가지 모두 채택하여 사용하고 있습니다.
마치며
지금까지 비슷하지만 조금씩은 다른 워크플로우 기반의 데이터플랫폼을 무신사 인프라 환경에 적절하게 사용하기 위한 과정에 대해 소개해드렸습니다.
Apache Airflow와 Amazon EKS가 만나면서 큰 관점에서 개발 효율성과 생산성은 Apache Airflow의 DAG’s 코드 템플릿을 통하여 높아졌습니다. 또한, 리소스 매니지먼트와 유지 보수 비용은 Amazon EKS의 Kubernetes 통하여 낮아질 수 있다는 점도 기대할 수 있었습니다.
이처럼 무신사 SRE팀은 무신사 개발 조직의 피드백을 무신사 인프라에 적절하면서도 효율적인 방식으로 이식하기 위해 노력하고 있습니다. 저희가 경험하고 시도한 방법들이 비슷한 고민을 하고 있는 개발자, 엔지니어분들에게 조금이나마 도움이 되었으면 합니다. 앞으로도 많은 관심과 응원 부탁드립니다!
참고
Highly available Airflow cluster in Amazon AWS — https://getindata.com/blog/highly-available-airflow-amazon-aws/
Kubernetes — https://kubernetes.io/
Airflow Helm Chart (User Community) — https://github.com/airflow-helm/charts
Official Airflow Helm Chart — https://airflow.apache.org/docs/helm-chart/stable/index.html
NVIDIA k8s device plugin — https://github.com/NVIDIA/k8s-device-plugin
AWS Neuron — https://aws.amazon.com/machine-learning/neuron/
Apache Airflow와 Amazon EKS가 만났을 때 벌어지는 일 was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apache Airflow와 Amazon EKS가 만났을 때 벌어지는 일

댓글