Airflow® 설치

Airflow® 설치 (Installation of Airflow®)

이 페이지에서는 Airflow®를 설치할 때 고려할 수 있는 다양한 설치 옵션을 설명해요. Airflow는 많은 구성 요소로 이루어져 있고, 여러 물리/가상 머신에 분산되어 배포되는 경우가 많아서 선택한 옵션에 따라 설치가 꽤 복잡해질 수 있어요. 설치할 때 필요한 사전 요구사항과 지원 정책, 그리고 각 설치 방법이 어떤 사용자에게 맞는지 아래에서 차근차근 살펴볼게요.

출처: 문서

본문

Airflow를 설치할 때 충족해야 하는 사전 요구사항(Prerequisites)과, Airflow·Python·Kubernetes 지원 정책을 확인하려면 지원 버전(Supported versions)도 함께 확인해 보세요.

Airflow는 추가 의존성(Dependencies)을 설치해야 하는데, 이는 extras와 프로바이더로 처리할 수 있어요.

Airflow를 설치할 때는 데이터베이스 설정(setup the database)도 해야 하며, Airflow를 업그레이드할 때도 데이터베이스를 최신 상태로 유지해야 해요.

개발 및 테스트를 위한 로컬 시작

프로덕션의 모든 복잡함 없이 Apache Airflow를 시험해 보고 싶으신가요? pipx가 설치되어 있다면 PyPI에서 직접 다음 명령으로 Airflow를 설치할 수 있어요:

pipx run apache-airflow standalone

Astral의 uv를 사용하면 비슷하게:

uvx apache-airflow standalone

이 명령은 자동 생성된 admin 비밀번호와 SQLite 데이터베이스를 갖춘 최소 시스템을 시작해서 바로 Airflow를 사용할 수 있게 해줘요. 복잡한 환경을 설정할 필요 없이 Airflow에 익숙해지고 시험해 보는 아주 좋은 방법이에요.

standalone 모드는 프로덕션용이 아니라는 점에 유의하세요. 하지만 로컬 개발을 시작하기엔 간단한 방법이에요.

릴리스 소스(Release sources) 사용

자세한 내용: Installing from Sources

이 옵션이 가장 잘 맞는 경우

대상 사용자

  • 소스에서 소프트웨어를 설치하고 빌드하는 데 익숙하며, 사용하는 소프트웨어의 무결성과 출처를 가능한 한 최저 수준까지 인식하고 있는 사용자.

사용자가 처리해야 할 것

  • Airflow와 그 구성 요소를 직접 빌드하고 설치해야 해요.
  • Airflow의 모든 구성 요소에 대한 배포를 직접 개발하고 처리해야 해요.
  • airflow db 명령으로 데이터베이스 스키마를 만들고 관리하며, Airflow와 Airflow 프로바이더의 자동 시작·복구, 유지보수, 정리, 업그레이드를 담당해야 해요.
  • 리소스를 관찰하고 문제에 대응할 수 있는 시스템 모니터링을 설정해야 해요.
  • 설치 모니터링과 피드백 루프를 기반으로 설치에 적절한 리소스(메모리, CPU 등)를 구성하고 관리해야 해요. 요구사항에 대한 참고 사항을 확인하세요.

Apache Airflow 커뮤니티가 이 방법에 대해 제공하는 것

  • 소프트웨어를 빌드하는 방법에 대한 안내가 있지만, 다양한 환경과 도구 때문에 배포와 환경에 특화된 문제가 생길 수 있고 이를 스스로 진단하고 해결해야 할 것으로 예상해야 해요.

도움을 구할 곳

  • Slack의 #user-troubleshooting 채널에서 빠른 일반 트러블슈팅 질문을 할 수 있어요. 더 긴 논의와 공유할 정보가 더 많다면 GitHub discussions를 이용하세요.
  • Slack의 #user-best-practices 채널에서 Airflow 사용 및 배포에 대한 모범 사례를 묻고 공유할 수 있어요.
  • Airflow 소프트웨어의 재현 가능한 문제에 대한 설명을 제공할 수 있다면 GitHub issues에 이슈를 열 수 있어요.
  • Airflow에 기여하고 싶다면 Airflow 자체 빌드를 위한 #contributors Slack 채널을 이용하세요.

PyPI 사용

자세한 내용: Installation from PyPI

이 옵션이 가장 잘 맞는 경우

  • 컨테이너와 Docker에 익숙하지 않고, 물리/가상 머신에 Apache Airflow를 설치하고 싶으며, 커스텀 배포 메커니즘으로 소프트웨어를 설치·실행하는 데 익숙한 경우 유용해요.
  • 공식적으로 지원되는 유일한 설치 메커니즘은 constraint 메커니즘을 사용하는 pip이에요. constraint 파일은 Apache Airflow 릴리스 관리자가 관리하며, PyPI에서 모든 프로바이더와 필요한 의존성을 갖춘 Airflow를 반복해서 설치할 수 있게 보장해요.
  • PyPI 설치의 경우 설치 페이지에 설명된 대로 PyPI에서 다운로드한 패키지의 무결성과 출처를 검증할 수도 있어요. 하지만 PyPI에서 다운로드한 소프트웨어는 이미 빌드되어 있어서 빌드 없이 설치할 수 있고, 소스에서 직접 빌드하지는 않아요.

대상 사용자

  • Python 애플리케이션 설치·구성, Python 환경·의존성 관리, 커스텀 배포 메커니즘으로 소프트웨어 실행에 익숙한 사용자.

사용자가 처리해야 할 것

  • Airflow의 모든 구성 요소를 직접 설치해야 해요.
  • Airflow의 모든 구성 요소에 대한 배포를 직접 개발하고 처리해야 해요.
  • airflow db 명령으로 데이터베이스 스키마를 만들고 관리하며, Airflow와 Airflow 프로바이더의 자동 시작·복구, 유지보수, 정리, 업그레이드를 담당해야 해요.
  • 리소스를 관찰하고 문제에 대응할 수 있는 시스템 모니터링을 설정해야 해요.
  • 설치 모니터링과 피드백 루프를 기반으로 설치에 적절한 리소스(메모리, CPU 등)를 구성하고 관리해야 해요.

Apache Airflow 커뮤니티가 이 방법에 대해 제공하는 것

  • 소프트웨어 설치 방법에 대한 Installation from PyPI 안내가 있지만, 다양한 환경과 도구 때문에 배포와 환경에 특화된 문제가 생길 수 있고 이를 스스로 진단하고 해결해야 할 것으로 예상해야 해요.
  • Airflow를 로컬에서 빠르게 시작해 테스트·개발에 사용할 수 있는 Quick Start 예시가 있어요. 하지만 이는 단지 참고용이에요. Quick Start가 프로덕션 설치 준비가 되었다고 기대하지 마세요. 이 방식을 따른다면 프로덕션 준비가 된 자체 배포를 직접 구축해야 해요.

도움을 구할 곳

  • Airflow Slack의 #user-troubleshooting 채널에서 빠른 일반 트러블슈팅 질문을 할 수 있어요. 더 긴 논의와 공유할 정보가 더 많다면 GitHub discussions를 이용하세요.
  • Slack의 #user-best-practices 채널에서 Airflow 사용 및 배포에 대한 모범 사례를 묻고 공유할 수 있어요.
  • Airflow 소프트웨어의 재현 가능한 문제에 대한 설명을 제공할 수 있다면 GitHub issues에 이슈를 열 수 있어요.

프로덕션 Docker 이미지 사용

자세한 내용: Docker Image for Apache Airflow

이 옵션이 가장 잘 맞는 경우

  • Container/Docker 스택에 익숙할 때 유용해요. 같은 물리/가상 머신에서 실행되는 다른 소프트웨어와 격리된 상태로 Airflow 구성 요소를 실행할 수 있고, 의존성 유지보수가 쉬워요.
  • 이미지는 Apache Airflow 릴리스 관리자가 빌드하며, PyPI에서 설치할 때 사용하는 것과 동일한 공식 릴리스 패키지와 공식 constraint 파일을 사용해요.

대상 사용자

  • 컨테이너와 Docker 스택에 익숙하고 자신만의 컨테이너 이미지를 빌드하는 방법을 이해하는 사용자.
  • 이미지를 확장하거나 커스터마이징하려면 constraint로 PyPI에서 프로바이더와 의존성을 설치하는 방법을 이해하는 사용자.
  • 여러 Docker 컨테이너를 연결해 Docker로 배포를 만들고 그러한 배포를 유지보수하는 방법을 아는 사용자.

사용자가 처리해야 할 것

  • 추가 의존성을 추가하려면 Container/Docker 이미지를 커스터마이징하거나 확장할 수 있어야 해요. 여러 컨테이너로 구성된 배포(예: docker-compose 사용)를 조립하고 서로 연결되도록 해야 해요.
  • airflow db 명령으로 데이터베이스 스키마를 만들고 관리하며, Airflow와 Airflow 프로바이더의 자동 시작·복구, 유지보수, 정리, 업그레이드를 담당해야 해요.
  • 커스텀 의존성에 대한 자체 커스터마이징과 확장을 관리해야 해요. 공식 Airflow Docker 이미지에서 참조 이미지의 일부인 Airflow와 Airflow 프로바이더 업그레이드는 커뮤니티가 처리해요. 릴리스되면 베이스 이미지를 업그레이드해 해당 변경사항을 반영해야 해요. 다만 직접 추가한 의존성과 프로바이더로 커스텀 이미지를 빌드하는 파이프라인을 만들고, 새 버전의 Airflow 이미지가 릴리스될 때 커스터마이징 단계와 이미지 빌드를 반복해야 해요.
  • 올바른 배포 메커니즘을 선택해야 해요. 컨테이너 배포에는 다양한 옵션이 있어요. 자체 커스텀 메커니즘, 커스텀 Kubernetes 배포, 커스텀 Docker Compose, 커스텀 Helm 차트 등을 사용할 수 있으며, 경험과 기대에 따라 선택해야 해요.
  • 리소스를 관찰하고 문제에 대응할 수 있는 시스템 모니터링을 설정해야 해요.
  • 설치 모니터링과 피드백 루프를 기반으로 설치에 적절한 리소스(메모리, CPU 등)를 구성하고 관리해야 해요.

Apache Airflow 커뮤니티가 이 방법에 대해 제공하는 것

  • 이미지를 빌드하고 커스터마이징하는 방법에 대한 안내: Building the image
  • 로컬 테스트·개발용으로 Airflow를 빠르게 시작할 수 있는 Running Airflow in Docker 예시가 있어요. 하지만 이는 단지 참고용이에요. 이 docker-compose.yml 파일을 프로덕션 설치에 사용하리라 기대하지 마세요. Docker Compose와 그 기능에 익숙해지고, 배포에 Docker Compose를 선택한다면 그것으로 프로덕션 준비가 된 배포를 직접 구축해야 해요.
  • Docker 이미지는 Airflow를 빌드하는 사람들이 관리하며, Airflow의 새로운 기능과 역량이 릴리스될 때마다 업데이트를 유지하기로 약속했어요.

도움을 구할 곳

  • 공식 Docker 이미지에 대한 빠른 질문은 Airflow Slack의 #production-docker-image 채널이 있어요.
  • Airflow Slack의 #user-troubleshooting 채널에서 빠른 일반 트러블슈팅 질문을, 더 긴 논의와 공유할 정보가 더 많다면 GitHub discussions를 이용하세요.
  • Slack의 #user-best-practices 채널에서 Airflow 사용 및 배포에 대한 모범 사례를 묻고 공유할 수 있어요.
  • Airflow 소프트웨어의 재현 가능한 문제에 대한 설명을 제공할 수 있다면 GitHub issues에 이슈를 열 수 있어요.

공식 Airflow Helm Chart 사용

자세한 내용: Helm Chart for Apache Airflow

이 옵션이 가장 잘 맞는 경우

  • Container/Docker 스택에 익숙할 뿐만 아니라 Kubernetes를 사용하고, 커뮤니티 관리형 Kubernetes 설치 메커니즘인 Helm 차트로 Airflow를 설치·유지보수하려는 경우 유용해요.
  • Airflow 구성 요소를 같은 물리/가상 머신의 다른 소프트웨어와 격리해 실행하고 의존성을 관리하는 기능뿐 아니라, 표준화되고 커뮤니티가 유지보수할 방식으로 Airflow를 더 쉽게 유지·구성·업그레이드할 수 있는 기능도 제공해요.
  • 이 차트는 공식 Airflow 프로덕션 Docker 이미지를 사용해 Airflow를 실행해요.

대상 사용자

  • 컨테이너와 Docker 스택에 익숙하고 자신만의 컨테이너 이미지를 빌드하는 방법을 이해하는 사용자.
  • 이미지를 확장하거나 커스터마이징하려면 constraint로 PyPI에서 프로바이더와 의존성을 설치하는 방법을 이해하는 사용자.
  • Kubernetes로 인프라를 관리하고, Helm 차트로 Kubernetes에서 애플리케이션을 관리하는 사용자.

사용자가 처리해야 할 것

  • 추가 의존성을 추가하려면 Container/Docker 이미지를 커스터마이징하거나 확장할 수 있어야 해요. 여러 컨테이너로 구성된 배포(예: Docker Compose 사용)를 조립하고 서로 연결되도록 해야 해요.
  • 데이터베이스 설정을 담당해야 해요.
  • Helm 차트가 데이터베이스 스키마를 관리하고, 애플리케이션 구성 요소의 시작·복구·재시작을 자동화하고 서로 연결하므로 그 부분은 걱정하지 않아도 돼요.
  • 커스텀 의존성에 대한 자체 커스터마이징과 확장을 관리해야 해요. 공식 Airflow Docker 이미지에서 참조 이미지의 일부인 Airflow와 Airflow 프로바이더 업그레이드는 커뮤니티가 처리해요. 다만 직접 추가한 의존성과 프로바이더로 커스텀 이미지를 빌드하는 파이프라인을 만들고, 새 버전의 Airflow 이미지가 릴리스될 때 커스터마이징 단계와 이미지 빌드를 반복해야 해요.
  • 리소스를 관찰하고 문제에 대응할 수 있는 시스템 모니터링을 설정해야 해요.
  • 설치 모니터링과 피드백 루프를 기반으로 설치에 적절한 리소스(메모리, CPU 등)를 구성하고 관리해야 해요.

Apache Airflow 커뮤니티가 이 방법에 대해 제공하는 것

  • 이미지를 빌드하고 커스터마이징하는 방법에 대한 안내: Building the image
  • Helm 차트 구성·설치 방법에 대한 전체 문서: Helm Chart for Apache Airflow
  • Helm 차트는 Airflow를 빌드하는 사람들이 관리하며, Airflow의 새로운 기능과 역량이 릴리스될 때마다 업데이트를 유지하기로 약속했어요.

도움을 구할 곳

  • 공식 Docker 이미지에 대한 빠른 질문은 Airflow Slack의 #production-docker-image 채널이 있어요.
  • 공식 Helm 차트에 대한 빠른 질문은 Slack의 #helm-chart-official 채널이 있어요.
  • Airflow Slack의 #user-troubleshooting 채널에서 빠른 일반 트러블슈팅 질문을, 더 긴 논의와 공유할 정보가 더 많다면 GitHub discussions를 이용하세요.
  • Slack의 #user-best-practices 채널에서 Airflow 사용 및 배포에 대한 모범 사례를 묻고 공유할 수 있어요.
  • Airflow 소프트웨어의 재현 가능한 문제에 대한 설명을 제공할 수 있다면 GitHub issues에 이슈를 열 수 있어요.

관리형 Airflow 서비스 사용

Ecosystem 페이지에서 Airflow용 관리형 서비스를 모두 찾을 수 있어요.

이 옵션이 가장 잘 맞는 경우

  • 다른 사람이 Airflow 설치를 관리해 주기를 원할 때 사용할 수 있는 관리형 Airflow 서비스가 있어요.

대상 사용자

  • Airflow를 관리받고 싶고 그에 대한 비용을 지불하고 싶은 사용자.

사용자가 처리해야 할 것

  • 관리형 서비스는 일반적으로 Airflow를 실행하는 데 필요한 모든 것을 제공해요. 자세한 내용은 관리형 서비스의 문서를 참조하세요.

Apache Airflow 커뮤니티가 이 방법에 대해 제공하는 것

  • Airflow 커뮤니티는 관리형 서비스에 대한 특정 문서를 제공하지 않아요. 자세한 내용은 관리형 서비스의 문서를 참조하세요.

도움을 구할 곳

  • 첫 번째 선택은 관리형 서비스가 제공하는 지원이어야 해요. Apache Airflow Slack에는 사용자 그룹별 전용 채널이 몇 개 있어요. 질문이 관리형 서비스보다 Airflow에 더 관련된 것이라고 판단되면 그 채널을 사용할 수 있어요.

타사(3rd-party) 이미지, 차트, 배포 사용

Ecosystem 페이지에서 모든 타사 배포 옵션을 찾을 수 있어요.

이 옵션이 가장 잘 맞는 경우

  • 앞서 언급한 공식 방법 중 어느 것도 맞지 않거나, 예전부터 그 방법을 사용해 온 경우 유용해요. 다만 변경을 고려할 때마다 Apache Airflow 커뮤니티나 관리형 서비스가 공식적으로 지원하는 방법 중 하나로 전환하는 것을 고려하는 것이 좋아요.

대상 사용자

  • 예전부터 다른 설치 방법을 사용해 왔거나 공식 방법이 다른 이유로 충분하지 않다고 느끼는 사용자.

사용자가 처리해야 할 것

  • 타사가 무엇을 제공하는지에 따라 달라요. 타사의 문서를 살펴보세요.

Apache Airflow 커뮤니티가 이 방법에 대해 제공하는 것

  • Airflow 커뮤니티는 타사 방법에 대한 특정 문서를 제공하지 않아요. 자세한 내용은 관리형 서비스의 문서를 참조하세요.

도움을 구할 곳

  • 타사가 무엇을 제공하는지에 따라 달라요. 사용 중인 타사 배포의 문서를 살펴보세요.

최소 요구사항에 대한 참고 사항

프로덕션 시스템을 위한 Airflow의 최소 요구사항에 대한 질문이 많은데, 이 질문에 간단한 답을 주는 것은 불가능해요.

Airflow가 필요로 하는 요구사항은 다음을 포함한 많은 요소에 달려 있어요 (그 외에도 많음):

  • Airflow가 설치된 배포 방식 (위의 Airflow 설치 방법 참고)
  • Airflow와 완전히 독립적인 배포 환경의 요구사항(예: Kubernetes, Docker, Helm 등) — 예를 들어 DNS 리소스, 더 많거나 적은 pods와 containers와 노드/리소스 공유, 특정 기술/클라우드/모니터링 통합 선택 등
  • 배포가 실행되는 데이터베이스, 하드웨어, 네트워크 등의 기술적 세부 사항
  • Dag, 구성, 플러그인, 설정 등에 추가하는 코드의 복잡성 (Airflow는 Dag 작성자와 배포 관리자가 제공하는 코드를 실행한다는 점을 유의하세요)
  • 설치하고 사용하는 프로바이더의 수와 선택 (Airflow에는 80개 이상의 프로바이더가 있고, 배포 관리자의 선택으로 설치할 수 있으며, 사용하면 더 많은 리소스가 필요할 수 있어요)
  • Airflow를 튜닝할 때 사용하는 파라미터 선택. Airflow에는 필요에 맞게 미세 조정할 수 있는 많은 구성 파라미터가 있어요.
  • 각 인스턴스의 병렬성까지 고려한 DagRun과 태스크 인스턴스의 수
  • 실행하는 태스크의 복잡성

위의 "Dag" 특성은 시간이 지남에 따라 변하고, 하루 중 언제나 주중 언제냐에 따라 달라질 수 있으므로, 시스템을 지속적으로 모니터링하고 파라미터를 조정해 원활하게 작동하게 할 준비가 되어 있어야 해요.

일부 개발 "퀵 스타트"에 대한 특정 최소 요구사항(예: Running Airflow in Docker 퀵 스타트 가이드)은 제공할 수 있지만, 프로덕션 시스템에 대한 최소 요구사항은 제공할 수 없어요.

Airflow 인스턴스의 리소스 할당을 생각하는 가장 좋은 방법은 프로세스 제어 이론 관점에서 생각하는 것이에요. 여기서 두 가지 유형의 시스템이 있어요:

  1. 거의 완전히 예측 가능하고, knob과 변수가 적어서 knob 값을 확실히 설정하고 시스템의 동작을 쉽게 파악할 수 있는 시스템
  2. 변수가 많아 예측하기 어렵고, 시스템이 원활히 작동하도록 지속적으로 모니터링하고 knob을 조정해야 하는 복잡한 시스템

Airflow(그리고 일반적으로 클라우드 서비스에서 실행되며 리소스를 담당하는 여러 계층과 동작을 제어하는 여러 파라미터를 가진 현대 시스템)는 복잡한 시스템이며 훨씬 두 번째 범주에 더 가깝습니다. 프로덕션에서 Airflow를 직접 실행하기로 결정했다면, 시스템이 원활히 작동하도록 모니터/관찰/조정 피드백 루프를 준비해야 해요.

이를 실천하려면 시스템을 모니터링하고 파라미터를 조정할 수 있는 좋은 모니터링 시스템이 필수예요.

리소스 사용을 최적화하는 데 사용할 수 있는 몇 가지 지침도 있어요. Fine-tuning your Scheduler performance는 스케줄러를 미세 조정하기에 좋은 출발점이에요. 또한 Best Practices 가이드를 따라 Airflow를 가장 효율적인 방식으로 사용하고 있는지 확인할 수 있어요.

또한 관리형 Airflow 서비스가 제공하는 중요한 이점 중 하나는 많은 의견(opinionated) 선택을 하고 시스템을 미세 조정해 주므로 그 부분을 크게 걱정하지 않아도 된다는 점이에요. 이러한 관리형 서비스에서는 보통 조정할 knob과 선택 사항이 훨씬 적고, 여러분이 지불하는 것 중 하나는 관리형 서비스 제공자가 시스템을 관리하고 유료 지원을 제공하며 필요에 따라 시스템을 확장하고 올바른 리소스를 할당할 수 있게 해준다는 점이에요 — 가질 수 있는 배포 종류에 따른 선택을 따르는 방식으로요.

더 알아보기 (Learn more)