Privacy-First Telemetry 도입이 논의되고 있습니다

정보공유
1

최근 커뮤니티에서 AIP-89: Privacy-First Telemetry for Apache Airflow 에 대한 논의가 시작되고 있는데요. Airflow 사용자로 알아야하는 정보이기에 공유되면 좋을 것 같아서 이 글을 통해서 정리를 해보았습니다 :wink:

먼저, 이 제안은 사용자 동의 기반(Opt-in)의 프라이버시 중심 Telemetry 시스템을 Airflow에 도입하는 것을 목표로 하고 있습니다.

배경

Airflow는 2.10.0 버전에서 Scarf 기반 Telemetry를 도입했지만,
프라이버시와 투명성에 대한 커뮤니티의 우려로 해당 기능은 Airflow 2.10.2에서 제거되었습니다.

그 이후 Airflow는 어떤 형태의 사용 통계도 수집하지 않게 되었는데요.
이로 인해, 메인테이너들은 다음과 같은 어려움을 겪어왔습니다:

  • 기능별 사용 현황이나 버전 분포를 파악하기 어려움
  • 비활성화된 기능이나 API의 폐지 판단 근거 부족
  • 실제 사용 데이터를 기반으로 한 리소스 우선순위 설정의 어려움
  • 실제 배포 패턴에 대한 이해 부족으로 성능 최적화에 어려움

AIP-89는 이러한 문제를 해결하기 위해, “프라이버시를 해치지 않으면서도 Airflow 발전 방향을 데이터로 뒷받침할 수 있는 구조”를 제안하고 있습니다.

AIP-89: Privacy-First Telemetry for Apache Airflow

AIP-89의 핵심 목표

  • Privacy by Design: 개인식별정보 없이 최소 데이터만 수집.
  • Transparency: 어떤 데이터가 전송되는지 사용자가 직접 확인 가능.
  • 기본값으로 Opt-in: 명시적 동의 없이는 어떠한 데이터도 전송되지 않음
  • Community Governance: 수집 항목 변경은 AIP + Dev List 투표 필요.
  • 통계적 유용성 확보: Differential Privacy로 노이즈 추가해 익명성 보장.

수집 데이터

유형 항목 설명
설치 정보 Airflow/Python 버전, OS, 아키텍처, 설치 방식 패치 버전은 반올림 처리
사용 환경 Executor, DB 백엔드, Provider 목록, 활성 기능 예: KubernetesExecutor, postgres
집계 통계 DAG/Task 개수 구간, 7일간 실행 수 ±10% Gaussian noise 추가
Operator 사용 상위 10개 Operator 비율만 전송 예: PythonOperator 45%
기술적 메타데이터 시간, 일일 세션 ID, 국가 수준 Geo 정보 IP는 즉시 익명화(마지막 두 옥텟이 0으로 설정됨) 후 폐기

수집되지 않는 데이터

  • DAG/Task 이름, 코드, 로그 내용
  • 변수명, 커넥션 정보, 사용자 ID/email
  • 전체 IP 주소, 호스트명, UUID 등

사용자 제어 방식(5가지 방법)

Scarf 사전 이후 기본적으론 Opt-in 방식으로 진행됩니다.
이렇게 진행하면 참여율은 낮지만 사용자 신뢰와 명시적 동의를 우선시 하기 위해 이런 방식으로 진행합니다.

  1. 환경 변수: AIRFLOW__TELEMETRY__ENABLED=false
  2. airflow.cfg 설정: [telemetry] enabled=false
  3. CLI 명령: airflow config set telemetry.enabled false
  4. 웹 UI: Admin > Telemetry Settings 토글
  5. DB 직접 수정: airflow_settings 테이블

투명성 기능

  • airflow telemetry --debug → 전송 예정 JSON 미리보기
  • Web UI에서 현재 상태, 마지막 전송 시각, 최근 90일 내 기록 열람 가능
  • airflow version 출력 시 Telemetry ON/OFF 표시

기술적 보호 장치

  • Differential Privacy: ±10% 노이즈 추가
  • 일일 세션 ID: 날짜별 해시로 교체, 장기 추적 불가
  • ASF Matomo 인스턴스(https://analytics.apache.org/) 사용
  • TLS 1.2+ 전송, 쿠키 미사용, 실패 시 조용히 무시
  • 90일 내 원시 데이터 삭제, 집계본만 보존

데이터 사용 예시

  • 기능 사용률 통계 (예: Executor 분포, Provider 활성도)
  • 버전 채택 현황 (Python 3.9/3.10 비율)
  • 운영 환경 추세 (Docker vs Kubernetes 배포)
  • 향후 3.x 버전 개발 우선순위 설정 근거

거버넌스

  • 새 수집 항목 추가 → AIP 또는 GitHub Discussion → 개발자 리스트 투표(72h Lazy Consensus)
  • 변경 시: 문서 업데이트 + 릴리스노트 + 일회성 Web UI 알림

대응된 커뮤니티 우려

  • “왜 Opt-out 아니냐?” → Scarf 사건 이후 신뢰 회복이 우선.
  • “보내는 내용은 어떻게 확인하나?” → Debug 모드 및 공개 소스코드로 직접 검증 가능.
  • “데이터 판매?” → 절대 없음, 법적 및 공개적 약속 명시.

투명성 & 데이터 접근

이렇게 수집한 데이터는 생성 예정인 Apache Software Foundation의 Matomo 인스턴스( https://analytics.apache.org/ )을 통해 배포된다고 합니다.

  • ASF에서 호스팅 및 관리
  • ASF 개인정보 보호정책을 준수합니다
  • 데이터는 Apache Airflow 프로젝트가 소유합니다.

Airflow프로젝트의 약속

  1. Airflow 개선에 필요한 최소한의 데이터를 수집합니다.
  2. 우리는 개인 정보를 수집하지 않으며 며칠 동안 세션을 연관시키지 않습니다.
  3. 원시 데이터는 90일 후에 삭제하고 집계 데이터만 보관합니다.
  4. 우리는 개인 수준의 데이터를 판매하거나 공유하지 않습니다.
  5. 기능 저하 없이 언제든지 옵트아웃할 수 있습니다.
  6. 지문 분석을 방지하기 위해 모든 계산에 통계적 노이즈를 추가합니다.
  7. 우리는 커뮤니티 검토를 위해 모든 원격 측정 코드를 게시합니다.

Airflow Summit 에서 발표 및 설문조사 요약

Airflow Summit에서 이 주제로 발표를 진행했고, 라이브 설문조사를 진행했다고 합니다.
표본은 22~34명으로 작았지만 결과는 다음과 같다고 합니다:

  • 81%가 opt-in 방식 선호
  • 보안과 프라이버시를 가장 중요한 우려사항으로 꼽음
  • 제안된 데이터 수집 범위는 대부분 참석자들이 “공유해도 괜찮다”고 응답한 부분들과 일치함

앞으로?

앞으로 2주 동안 메일링 리스트를 통해 커뮤니티 피드백을 수집할 예정이라고 합니다.
이후 전체적인 방향에 대한 합의가 이루어지면 투표를 진행할 계획이며,
논의 과정에서 우려 사항이 제기될 경우 해당 피드백을 반영해 AIP를 보완해 나갈 예정이라고 합니다.

https://lists.apache.org/thread/6o74lt6rdrvrykj4x8o8oxh14o12pzk8

3개의 좋아요