서버리스에서 쿠버네티스로 - Airflow 운영 경험기
Airflow를 Kubernetes(K8s)로 마이그레이션하고 운영하면서 발생한 주요 이슈들과 해결 방법들을 다음과 같이 정리해드리겠습니다
1.
CPU 과부하 문제
•
문제상황:
◦
GitSync로 DAG 추가 시 스케줄러의 CPU 사용량이 급증
◦
개발용 0.4 → 2.7 core (675% 증가)
◦
운영용 0.25 → 0.45 core (80% 증가)
•
해결방법:
◦
min_file_process_interval 값을 조정하여 DAG 파일 구문분석 주기 늘림
◦
파일 I/O 빈도를 줄여 CPU 부하 감소
◦
DAG 변경이 빈번하지 않아 반영 지연이 크게 문제되지 않음
2.
OOM(Out of Memory) 문제
•
문제상황:
◦
워커가 태스크 처리 중 메모리 부족으로 파드/노드가 비정상 종료
◦
자원 경합 발생 시 메모리는 압축 불가능한 자원이라 시스템 장애로 이어짐
•
해결방법:
◦
자원 제한 정책(Resource Limits) 도입
resources:
limits:
cpu: 1000m
memory: 4Gi
requests:
cpu: 500m
memory: 2Gi
YAML
복사
◦
K8s의 Taint와 Tolerations을 사용하여 애플리케이션별 노드 분리
◦
자원 격리를 통해 안정성 확보
•
ResourceQuota와 LimitRange를 채택하지 않은 주요 이유는 데이터 애플리케이션의 특성 때문이었습니다.
1.
데이터 애플리케이션의 불규칙한 리소스 요구사항
•
각 컴포넌트별로 필요한 리소스 요구사항이 매우 다양함
•
워크로드의 성격에 따라 리소스 사용량이 크게 달라짐
•
고정된 쿼터나 제한을 설정하기가 어려움
2.
네임스페이스 단위 제한의 한계
•
ResourceQuota는 네임스페이스 전체에 대한 제한을 걸게 됨
•
데이터 파이프라인의 경우 각 작업마다 필요한 리소스가 크게 다를 수 있음
•
네임스페이스 전체에 동일한 제한을 걸면 유연성이 떨어짐
3.
대안으로 선택한 방식
•
대신 Taint와 Tolerations을 사용하여 애플리케이션별로 노드를 분리
•
이를 통해 각 애플리케이션의 특성에 맞는 리소스 관리가 가능
•
더 유연하고 세밀한 리소스 관리가 가능
◦
따라서 데이터 애플리케이션의 다양한 워크로드 특성을 고려할 때, ResourceQuota나 LimitRange보다는 노드 분리 전략이 더 적합한 선택이었습니다.
3.
실행 로그 유실 문제
•
문제상황:
◦
DAG 실행 지연 시 로그가 생성되지 않는 현상
◦
404 에러로 로그 조회 불가
•
원인분석:
◦
태스크가 scheduled 상태에서 워커에 할당되지 못함
◦
BigQuery 문제로 인한 작업 지연
◦
워커의 동시 처리 가능 태스크 수 한계
•
해결방법:
◦
워커 수를 1대에서 2대로 스케일아웃
◦
동시 처리 능력 향상으로 작업 지연 현상 감소
4.
주요 성과
•
비용 최적화: 관리형 서비스 대비 50% 비용 절감
•
안정성 향상: 자원 격리를 통한 시스템 안정성 확보
•
기술 역량 강화: K8s와 Airflow 운영 노하우 축적
5.
핵심 교훈
•
단계적 전환: 관리형 서비스에서 시작하여 점진적으로 직접 관리로 전환
•
모니터링 중요성: 로그 수집과 모니터링 고도화의 필요성
•
지속적 개선: 문제해결 과정에서 얻은 경험을 통한 성장