성능 튜닝

성능 튜닝 (API와 UI) (Performance tuning)

API와 UI 워크로드에서 Airflow 성능을 개선하는 실용적인 팁을 모은 문서예요. 느린 쿼리를 위한 커스텀 메타데이터 인덱스 추가와, 역방향 프록시에서 HTTP/2를 활성화하는 방법을 살펴볼게요.

출처: 문서

이 가이드는 API와 UI 워크로드에서 Airflow 성능을 개선하는 실용적인 팁을 모아둔 것이에요.

일부 API 호출이나 특정 UI 뷰에서 느려짐을 발견했다면, 쿼리 플랜을 검사하고 워크로드에 맞는 인덱스를 직접 추가해 보세요. 특정 정렬 기준으로 목록을 조회하는 엔드포인트와 UI 테이블 뷰는, 메타데이터 양이 많다면 추가 인덱스의 이점을 볼 가능성이 높아요.

start_date, 타임스탬프(예: dttm), 상태 필드 같은 컬럼에 대한 빈번한 스캔·조회로 인해 느린 API list/detail 엔드포인트.
대규모 목록을 로드하거나 메타데이터 테이블에 무거운 필터링을 수행하는 UI 페이지.

느린 엔드포인트에 대해 쿼리 플래너(예: EXPLAIN/EXPLAIN ANALYZE)를 검사하고 누락된 인덱스를 찾아내요.
가장 흔한 정렬 로직, 일반적으로 API 호출에서 사용되는 order_by 쿼리 파라미터에 맞는 단일 또는 복합 인덱스를 선호해요. 복합 인덱스는 다중 기준 정렬을 커버할 수 있어요.
최적의 인덱스는 API와 UI를 어떻게 사용하느냐에 달려 있어요. 기본으로 배포할 수 있는 만능 세트는 없어요.

Airflow 데이터베이스 업그레이드와의 충돌을 피하려면, Airflow DB 업그레이드를 실행하기 전에 커스텀 인덱스를 삭제하고 업그레이드가 성공한 후 다시 적용해요.

브라우저는 origin별 동시 HTTP/1.1 연결을 6개로 제한해요. Grid 페이지 같은 뷰는 한 번에 많은 API 요청을 보낼 수 있는데, 이러면 연결 슬롯이 생길 때까지 일부 요청이 대기열에 쌓이고 지연될 수 있어요.

역방향 프록시(예: Nginx) 레이어에서 HTTP/2를 활성화하면, HTTP/2가 많은 요청을 단일 TCP 연결로 다중화하기 때문에 이 제한이 사라져요.

HTTP/2는 Airflow API 서버 앞에 있는 역방향 프록시에서 구성돼요. Nginx의 경우 listen 줄에 http2 지시문을 추가해요:

server {
    listen 443 ssl http2;
    # ... existing Airflow proxy configuration ...
}

역방향 프록시 뒤에서 Airflow를 실행하는 방법에 대한 자세한 내용은 역방향 프록시 뒤에서 Airflow 실행하기를 참고하세요.