Docker 기본 정리 및 Airflow에서 Docker의 필요성

오늘은 전반적인 Docker 개념과 Airfow에서 Docker와 K8s가 필요한 이유에 대해 학습하였다.

새로 알게된 점은 다음과 같다.

 💡 새로 알게된 점 💡
1. Docker run과 exec 차이
2. Dockerfile에서 arg와 env 차이
3. Airflow 운영상의 이슈와 이를 Docker 및 K8S로 해결하는 법

이전에는 단순 K8s를 이용해서 컨테이너 관리를 하겠지라고만 생각했는데, 
"Airflow의 task를 Docker Image로 만들고 Worker를 Airflow 전용 worker가 아닌 K8s에서 할당받아서 실행하는 형태" 라는 것을 새롭게 알게되었다. 

이로 인해 Docker 학습의 중요성을 깨달았고, 이번주 학습도 신경써서 들어야겠다.  

---

01. Docker란

01-1. Docker Image와 Container

소프트웨어를 일관되게 빌드하고 실행하고 배포

{"originWidth":1530,"originHeight":479,"style":"alignCenter","width":710,"height":222,"caption":"Docker Best Practices in 2022

• Docker Image: 이렇게 독립적으로 완전하게 만들어진 패키지
• Docker Container: 이 Docker Image를 독립된 환경에서 실행한 것
  • 컨테이너는 Host OS위에 있는 도커 엔진의 위에서 작동됨
  • OS 및 다른 Docker container와 별도의 독립된 환경에서 실행됨
  • HostOS별 지원하는 컨테이너 OS
  HostOS 지원하는 컨테이너 OS

  HOST OS	지원하는 컨테이너 OS
  Mac	경량화된 리눅스 VM
  Windows	Windows, Linux
  Linux	Linux

 

01-2. VM이란

https://www.techtarget.com/searchitoperations/definition/virtual-machine-VM

 

• Host OS 위에 Hypervisors가 있고, 그 위에 VM 존재
  • VM은 자체 OS를 가지고 있음 (컴퓨터 하드웨어 단의 추상화)
• AWS EC2가 VM임

 

 

 

 

 

 

01-3. VM과 Container 비교

각각 장단점

특징	Container	VM
독립적이고 분리된 공간 제공	컨테이너단에서 독립적으로 실행가능	VM단에서 독립적으로 실행 가능
장점	lightweight (자원 소비 적음)
	빠름 (호스트 OS 사용함)
단점	Host OS를 사용하기에 Cross-platform compatibility를 항상 지원 X	각 VM은 자신만의 OS 필요함 (가상 하드웨어 위에서 동작)
	많은 수의 Docker Container를 관리 쉽지 X	자원(메모리 등) 많이 사용함
	GUI 소프트웨어 개발에 적합 X	시작하는 데 오래 걸림

https://www.redhat.com/ko/topics/containers/containers-vs-vms

https://www.oracle.com/kr/cloud/cloud-native/container-registry/what-is-docker

 

01-4. Docker로 소프트웨어 빌드하는 프로세스

1) 과정

https://www.oracle.com/cloud/cloud-native/container-registry/what-is-docker/

1. 대상 소프트웨어 선택
2. [Dockerization] Dockerfile로 Docker Image 빌드 (docker build)
   • 생성한 Docker Image는 Docker Hub와 같은 Docker Registry에 등록 가능함
3. Docker Image를 Docker Container으로 실행
   • Container를 통해 Docker Image안의 소프트웨어를 실행 (docker run)

 

2) Dockerfile

• Dockerfile : 소프트웨어를 어떻게 docker image로 빌드할 지 정리해둔 텍스트 파일
• docker build 명령어로 Dockerfile을 Docker image로 빌드함
  • FROM : 기본 OS
  • RUN : 빌드(docker build)시 실행되어야하는 명령들(ex. 소프트웨어 설치)이 지정됨.
  • ENTRYPOINT/CMD : 컨테이너 내에서 실행할 명령어
  • COPY : 로컬의 특정 파일을 컨테이너로 복사
  • WORKDIR : 컨테이너의 Working Directory 지정
  • ARG : Docker Image를 만들 때 사용되는 변수 지정. 최종 이미지에 쓰이지 X
  • ENV : 컨테이너가 실행될 때 사용되는 환경변수. 최종 이미지에 저장됨
  • USER : 컨테이너를 실행할 때 사용할 유저 ID
  • EXPOSE : 서비스 사용 포트번호

 

3) Docker Image 구성 요소

아래 정보와 실행 순서는 Dockerfile에 기술됨

Docker Image는 다수의 파일로 구성됨

• 기본 OS (리눅스라면 우분투, 데비안 등) 소프트웨어의 실행환경
• 소프트웨어 자체 (코드)
• 라이브러리
• 파일 시스템 스냅샷: 이는 스택화된 형태로 구현됨
• 환경 설정 변수 (ENV, ARG)
• 메타 데이터: 이미지 자체에 대한 정보 (버전, 작성자, 설명 등등)

---

02. Airflow에서 Docker의 필요성

02-1. Airflow 운영상의 어려움

• 관리해야 하는 DAG의 수가 많아지면, 다음 이슈들이 발생함
  1. 데이터 품질 이슈
  2. 데이터 리니지 이슈
  3. DAG 들간 라이브러리/모듈 (버전) 충돌
  4. Worker의 부족
  5. Worker 서버들의 관리와 활용 이슈

(자세히) 상세 이슈 설명 및 해결법

이슈 1. 라이브러리 충돌

• 라이브러리/모듈의 충돌 이슈가 발생하기 시작함
• 해결 : DAG혹은 Task 별로 Docker container 등의 별도의 독립공간 만들어줘야 됨
  • Docker Image: 해당 소프트웨어를 실행하는데 필요한 모든 라이브러리 등이 하나로 패키지 된것
  • Docker Container : Docker Image 기반으로 작게 분리된 공간
• → Dag 혹은 Task 코드를 Docker Image로 만들고 이를 독립된 공간(Docker Container)안에서 실행

이슈 2. Worker의 부족

• Scale Up과 Scale Out으로 Worker 증가
• 해결 : K8s와 같은 컨테이너 기술 활용
  • Airflow가 dag나 task 실행할 때 마다 자체 할당된 Worker를 쓰는 것이 아닌, K8s에서 필요한 성능의 자원을 할당받아 작업 후 return하는 형태
  • K8s는 “공용 서버 클러스터” 역할

이슈 3. 낮은 Server Utilization 이슈

• 보통 서비스는 특정 시점에만 서비스 사용량이 증가하는 형태
• 그러기에 서비스별로 전용 서버 할당하는 것은 여러 이슈 만들어냄
• 해결 : K8s와 같은 공용 서버 클러스터가 있다면, 서비스가 필요할 때마다 On-demand 형식으로 쓰고 return하는 형식으로 관리 가능
  • 서비스별로 Capacity 관리 하는 것이 편해짐
  • utilization이 높아짐

 

02-2. 해결법

1. Task나 DAG 를 Docker Image로 만들어서 Docker Container 형태로 실행
   • 라이브러리/모듈 이슈 방지
   • 개발환경과 프로덕션 환경 동일하게 유지
2. Airflow Worker를 K8s에서 필요한 대로 동적으로 할당
   • 전용 서버를 Airflow에 할당하지 않고 Container Orchestration 서비스를 통해 할당해서 사용하고 리턴
3. Airflow에서 이를 해결하는 방법
   1. Airflow Operator로 kubernetes PodOperator 사용
      • task를 Docker Image로 만들고, Worker를 Airflow 전용 worker가 아닌 K8s에서 할당받아서 실행하는 형태
   2. Airflow Operator로 DockerOperator 사용
      • 실행이 되는 것 자체가 Docker Image이고, Docker Container가 Worker 위에서 launch됨
   3. Airflow Executor로 아래 목록 사용함
      1. Kubernetes Executor
         • 모든 DAG 코드가 Docker Image로 빌드되어 K8s에서 실행됨
      2. CeleryKuberenetesExecutor
         • CeleryExecutor와 KubernetesExecutor를 동시에 사용
      3. Local Kubernetes Executor
         • LocalExecutor와 KubernetesExecutor를 동시에 사용

추가개념 1) Airflow Operator란?

• operator는 단일 작업 수행 역할 (ex. PythonOperator, BashOperator)
• Dag가 operator의 집합
• operator ==(비슷) task (task는 operator로 구현됨)

추가개념 2) Airflow Executor는?

Executor는 Task들을 관리하고 실행하는 역할을 수행

[ 종류 ]

• Sequential Executor: 디폴트로 설치되며 Sqlite와 같은 싱글스레드 DB에서만 사용가능 (병렬처리X)
• Local Executor: task들을 Airflow 마스터 노드안에서 실행
  • 메타데이터 DB를 Sqlite가 아닌 MySQL이나 PostgreSQL을 이용하여, task를 스레드를 이용하여 병렬 처리 가능함
  • Worker노드가 1개이며, 이것은 Airflow 마스터 노드임
• Celery Executor: 다수의 Worker 노드가 있는 경우 사용되며 Celery 큐를 사용해 task들을 worker 노드로 분산하여 실행
• Kubernetes Executor : K8s 클러스터를 사용하여 task들을 독립된 환경에서 사용
  • 이때 Task나 DAG는 모두 Docker Image로 구현이 되어있어야 함
• Local Kubernetes Executor와 Celery Kubernetes Executor도 존재
  • Local Kubernetes Executor : Local 과 Kubernetes Executor 모두 지원해줌
  • Celery Kubernetes Executor : Celery 와 Kubernetes Executor 모두 지원해줌

---