Apache Spark 리소스 최적화: 하루 800만 건의 작업 실행에서 얻은 교훈

• 하루 약
  800만 건의 Spark 실행을 처리하는 Salesforce Data 360이 할당한 자원과 실제 작업량을 비교해 낭비를 줄인 사례. 작업이 성공했다는 사실만으로 적정한 자원을 사용했다고 판단할 수는 없음
  공통 작업 제출 경로에 계측 플러그인을 주입해 애플리케이션 코드 수정 없이 실행 데이터를 수집. Kafka와 Iceberg에 모은 데이터를 분석해 비용이 크고 반복적으로 자원을 낭비하는 워크로드부터 조사
  태스크를 처리하지 않은 실행기와, 작업을 받았지만 CPU가 유휴 상태인 실행기를 구분. 메모리 사용량과 스필, 셔플 실패를 함께 살펴 자원 과다 할당인지 다른 병목인지 판단
• 한 워크로드는
  초기 실행기를 40개에서 4개로 줄이고 동적 할당을 유지. 별도 워크로드 집단에서는 최대 실행기 수를 약 20% 낮췄으며, 각각 한 달 넘게 운영하며 성능과 실패율을 검증
• 대상 워크로드의 변경 전후
  각 4주 구간에서 주간 컴퓨팅 비용 환산치가 31% 감소. 실행 시간과 재시도, 메모리 부족, Kubernetes 부하도 확인했으며, 통제 실험이 아니므로 다른 변화의 영향도 있을 수 있음

실행 성공과 리소스 효율은 별개임

• Salesforce Data 360은 하루 약
  800만 건의 Apache Spark 워크로드 실행을 처리하며, 짧은 작업부터 수 시간 동안 테라바이트 데이터를 처리하는 작업까지 포함함
  성공한 실행은 해당 설정이 동작했다는 증거일 뿐, 할당 용량이 실제로 얼마나 필요했는지는 알려주지 않음

• 근거 없이 CPU, 메모리, 실행기 수를 줄이면 실행 지연, 비용이 큰 재시도, 운영 장애로 이어질 수 있음

• 사용하지 않는 용량을 메모리 압박이나 셔플 병목과 구분하면서 성능과 신뢰성을 유지해야 함

• 한 워크로드는 시작 시
  실행기 40개를 요청했지만 대부분이 초기에 유용한 작업을 하지 않아 불필요한 용량 할당과 파드/노드 생성 및 제거를 유발함

• 고정 리소스 프로필이나 테넌트와 데이터량 기반 추정은 제출 전 할당량을 정하는 데 도움이 되지만, 실행 중 실제 사용 양상은 보여주지 못함

• 요청한 리소스와 실제 작업량을 비교한
  실행 이력을 다음 할당 결정에 반영하고, 리소스 크기 조정이 해결해야 할 문제인지부터 확인해야 함

공통 제출 관문에서 안전하게 계측하기

Data Processing Controller(DPC) 는 Data 360의 수집, 세분화, 활성화를 지원하는 관리형 Spark 제출의 공통 관문임

• Agentforce 상호작용도 플랫폼에 데이터를 유입함

• 애플리케이션별 계측 작업 없이 동일한 기준으로 실행기별 태스크 배정, CPU/메모리 사용량, 스필, 재시도를 관측할 수 있는 통합 지점으로 활용함

• 오픈소스
  DataFlint Spark 플러그인을 확장하고, DPC가 제출 요청을 구성할 때 주입함

• Spark 리스너 훅이 애플리케이션 코드와 독립적으로 각 드라이버에서 원격 측정 데이터를 수집함

• 수집한 데이터는 Kafka를 통해 중앙 Iceberg 레이크하우스로 전송함

• 계측이 고객 연산에 영향을 주지 않도록
  전용 리스너 버스 큐를 사용함

• 계측 설정이나 초기화가 실패해도 작업 제출은 계속 진행함

• 내보내기 실패와 측정 공백은 알림으로 감시해 플랫폼 팀이 조사함

• 다른 플랫폼에서도 이에 상응하는
  공통 경계 지점을 활용하면 일관된 Spark 관측을 구현하면서 데이터 수집을 고객 연산과 격리할 수 있음

Silver 분석 계층으로 집계 의미와 비용 범위 맞추기

• 불완전한 실행이나 전체 워크로드의 평균만으로는
  특정 워크로드의 리소스 요구량을 판단할 수 없음
• 비교할 워크로드, 환경, 실행 경계를 정의하고 누락되거나 부분적으로 수집된 측정값을 식별해야 함

재시도와 스필은 집계 목적에 맞게 해석해야 함

• 재시도된 Spark 스테이지는 추가 과금 작업이지만, 모든 시도를 서로 다른 논리적 작업으로 세면 성공 실행 분석이 왜곡됨

• 메모리 스필과 디스크 스필은 같은 압박 사건을 서로 다른 형태로 나타내므로 독립적인 바이트로 더하면 잘못된 총량이 나옴

• 정제된 분석 계층인
  Silver가 애플리케이션, 잡, 스테이지 시도, 실행기와 관련 영역을 구조화함

• 적정 리소스 산정에는 정의된 워크로드와 환경 범위 안에서 완료된 Spark 애플리케이션 실행을 사용함

• 신뢰성 조사에는 실패와 재시도도 포함함

• 비용은 Spark 애플리케이션별
  드라이버 파드와 모든 실행기 파드 비용의 합계로 계산해, 동일 워크로드의 변경 전후를 일관된 경계에서 비교함

낮은 사용률이 낭비인지 병목인지 구분하기

• 조사 우선순위는 비용이 크면서
  태스크를 하나도 완료하지 않은 실행기를 반복적으로 할당하는 워크로드에 맞춤

• 서비스 제공 비용, CPU 유휴 시간, 태스크 완료 수가 0인 실행기를 기준으로 Data 360 워크로드 상위 10개를 선정함

• 모든 저사용률 작업을 동등하게 취급하지 않고, 규모가 크고 반복되는 낭비에 집중함

• Silver를
  Trino로 조회할 수 있게 하고, 자연어 질문에서 SQL을 생성하는 에이전트 기반 프로파일링 스킬을 구축함

• 답변에 SQL, 계산식, 가정을 포함해 엔지니어가 권고의 근거를 검토할 수 있게 함

• 시작 시 유용한 작업이 없는 실행기는
  초기 할당 축소 실험의 근거가 됨

• 태스크를 받은 실행기의 높은 CPU 유휴 시간은 할당한 CPU가 상당 부분 사용되지 않는 별도 패턴임

• 두 신호를 CPU/메모리 최대 사용량, 실행기 동시성, 스필 양상과 함께 조사함

• 셔플이 많은 작업의
  데이터 가져오기 실패(fetch failure) 는 별도의 신뢰성 조사가 필요함

• CPU 사용률이 낮다는 사실만으로 용량을 제거해도 된다고 판단할 수 없음

• 태스크가 없는 실행기가 있다는 사실만으로 적정 대체 실행기 수를 확정할 수도 없음

• 먼저 리소스 크기 조정 실험이 필요한지 실행 동작 조사가 필요한지 판단해야 함. 작업 분배가 문제라면 파티션을 활용한 Spark 애플리케이션 최적화를 검토할 수 있음

운영 환경에서 두 가지 리소스 축소 검증하기

• 초기 실행기 40개를 사용하던 워크로드는
  initialExecutors

를 4로 축소하고 Spark 동적 할당은 유지함

• 시작 시 할당량을 줄이되 필요할 때 용량을 늘릴 수 있게 함

• 운영 환경에서 한 달 넘게 관찰한 결과, 허용할 수 없는 실행 시간 증가나 재시도/실패 악화 없이 낭비를 줄임

• 별도 워크로드 집단에서는
  실행기 유휴 시간이 90%를 초과해 최대 실행기 수 제한을 약 20% 낮춤

• 나머지 Spark 프로필은 그대로 유지함

• 한 달 넘게 운영을 관찰한 결과 실행 시간, 스필, 재시도, 실패가 허용 범위에 머무름

• 두 변경은
  해당 워크로드에서 검증된 설정이며, 모든 Spark 작업에 적용할 보편적인 설정은 아님

애플리케이션과 Kubernetes를 함께 검증한 비용 성과

• 변경은 하위 환경부터 운영 환경까지
  단계적으로 적용하고, 다음 단계로 넘어가기 전에 애플리케이션과 실행 플랫폼을 함께 점검함

• 애플리케이션 지표는 p95 실행 시간, 재시도, 메모리 부족(OOM), 스필을 확인함

• 플랫폼 지표는 파드/노드 생성 및 제거, IP 프리픽스 소비량, etcd 부담을 확인함

• 대상 Data 360 워크로드의 변경 전후
  각 4주 구간을 비교한 결과, 주간 컴퓨팅 비용 환산치가 31% 감소함

• 별도로 같은 환경에서 DPC 작업 시작 건수는 7% 넘게 증가함

• 통제 실험이 아닌 전후 비교이므로 같은 기간에 발생한 다른 변화도 비용 감소에 기여했을 수 있음

신뢰할 수 있는 실행 증거를 반복적인 최적화로 연결하기

• 다음 단계로
  Silver 상위의 워크로드 단위 집계를 탐색 중임

• SQL이나 자연어 스킬 없이도 자주 필요한 분석 결과를 확인할 수 있게 하는 것이 목표임

• 검증된 권고를 DPC가 자동 적용해 관측, 진단, 최적화의 피드백 주기를 단축하는 방안도 탐색 중임

• 시작점은
  비용이 큰 반복 워크로드 하나면 충분함

• 완료된 비교 가능한 실행에서 요청 용량과 실제 작업량을 대조하고, 유휴 상태의 원인을 조사한 뒤 해당 문제를 겨냥한 변경을 시험함

• 확대 적용 전 컴퓨팅 비용뿐 아니라 실행 시간, 스필, 재시도, 실패를 함께 평가해야 함

• 리소스 추정치를
  가설로 취급하고 실행 증거로 변경을 선택한 뒤, 후속 실행으로 효과를 검증하면 하루 800만 건의 실행 규모가 아니어도 반복 가능한 최적화를 수행할 수 있음

댓글과 토론