#Backend

Python의 멀티프로세싱과 Airflow, 그리고 관련된 문제 해결기 1편

Summary

Python fork vs spawn: 7.6배의 메모리 차이가 갈라놓은 Airflow 태스크 실행의 비밀

Airflow 3 PoC 과정에서 파헤친 멀티프로세싱 성능 제약과 내부 동작 아키텍처 완벽 가이드

본 아티클은 Airflow 3.0 PoC 진행 중 발견한 Python 멀티프로세싱의 한계를 다루는 시리즈의 1편입니다. Airflow가 분리된 태스크 실행을 위해 왜 멀티프로세싱을 선택했는지 설명하고, Python의 대표적 프로세스 생성 방식인 fork와 spawn의 메모리 및 실행 속도 차이를 실제 벤치마크 데이터를 통해 명쾌하게 비교합니다. 최종적으로 Airflow가 이 두 방식 중 어떤 타협점을 선택했는지와 supervisor 기반 태스크 실행 모델을 공유합니다.

01Airflow는 병렬성과 격리성을 충족하기 위해 단일 태스크당 독립된 프로세스를 띄워 실행하고 종료 시 폐기하는 모델을 채택함
02Python GIL 극복을 위해 필수적인 멀티프로세싱 기법인 fork와 spawn의 핵심 동작 메커니즘 차이 분석
03실제 Kubernetes Pod 환경에서 부모 프로세스의 메모리를 공유하는 COW(Copy-on-Write)의 메모리 절감 효과 실증
04동일 조건(10개 자식 프로세스) 하에서 fork 방식이 spawn 방식 대비 메모리 사용량은 약 7.6배 적고 프로세스 생성은 50배 빠름을 검증
05Airflow 3부터는 태스크가 메타 DB에 직접 접근하지 않고, supervisor와 소켓 통신을 하며 Execution API를 호출하도록 아키텍처가 변경됨

RECOMMENDATION

배치 워크플로 플랫폼을 운영하거나 대규모 Python 분산 프로세싱을 설계할 때, 자식 프로세스의 무거운 모듈 임포트 비용과 메모리 오버헤드를 제어하기 위해 반드시 프로세스 스타트 메소드(fork/spawn)의 동작 특성과 안정성 트레이드오프를 사전에 검토해야 합니다.

The Problem

Apache Airflow는 다수의 태스크를 병렬로 실행하면서도, 각 태스크의 독립성을 보장하고 부모 프로세스의 전역 모듈 오염을 방지하기 위해 격리성이 확보된 태스크 실행 환경이 필요합니다. 하지만 Python의 CPython 표준 구현체는 GIL(Global Interpreter Lock) 제약이 있어 단일 인터프리터 내에서 멀티코어 CPU의 병렬 처리 이점을 활용하지 못합니다.

The Solution

Airflow는 태스크당 독립된 프로세스를 생성하여 실행하고 종료 시 폐기하는 멀티프로세싱 방식을 도입하였으며, 이를 구현하기 위해 Python의 fork와 spawn 멀티프로세싱 방식의 물리적 메모리 점유(PSS/RSS) 및 프로세스 생성 속도 차이를 비교 분석합니다.

The Result

비교 실험 결과, fork 방식은 부모의 페이지 테이블만 복사하는 COW(Copy-on-Write) 방식을 사용하여 프로세스 생성(4.3ms) 및 모듈 임포트(0ms)가 매우 빠르고 총 메모리 사용량(120.8MB)도 적은 반면, spawn 방식은 새 인터프리터를 기동해 전체를 다시 임포트하므로 생성(206.6ms)과 임포트(2694.8ms)가 느리고 총 메모리(918.2MB)도 프로세스 수에 비례하여 급증함을 확인했습니다.

Trade-off

fork 방식은 자식 프로세스가 부모의 모든 메모리 공간과 파일 디스크립터를 공유하므로 리소스 효율이 극대화되지만, 멀티스레드 환경에서 fork를 수행할 시 데드락이 발생하거나 불안정한 상태를 초래할 수 있는 잠재적 위험(부작용)이 존재하며, spawn 방식은 완벽히 격리되나 리소스 비용이 급증하는 트레이드오프가 있습니다.