Foundry 사용량 최적화의 우선순위

사용량을 줄이려면 먼저 업무가 정상적으로 동작하는지, 줄이려는 지표가 무엇인지와 그 지표의 병목이 어디인지 정해야 합니다. 시각화까지의 시간, 데이터 갱신 지연과 총비용은 서로 다른 목표이며 한쪽의 개선이 다른 쪽을 악화시킬 수 있습니다.

최적화를 시작할 시점

다음 질문에 답할 수 있어야 변경의 효과를 판단할 수 있습니다.

• 업무 기능이 완성되어 필요한 결과를 내고 있습니까?
• 성공을 판단할 비용 또는 처리 시간 목표가 있습니까?
• 그 목표를 제한하는 구간을 확인했습니까?

가상 예로 비용이 큰 파이프라인을 Resource Management에서 조사했더니 연산 사용량이 대부분이고 매일 돌릴 필요가 없는 스케줄이 발견될 수 있습니다. 주말 실행을 제외하여 실행 횟수를 줄이면 약 28%의 감소를 기대할 수 있는 조건입니다. 반대로 저장 공간이 실제 비용에서 작은 비중인데 복잡한 저장 최적화에 집중하면 총비용은 거의 바뀌지 않을 수 있습니다.

Linter는 리소스의 안티패턴과 권장 변경을 찾아 줍니다. 권장 사항을 실제 병목과 업무 요건에 대조하여 선택합니다.

사용량의 세 구성요소

일반적인 사용량 모델은 Foundry compute, Ontology volume과 Foundry storage를 구분합니다. 계정별 계약은 다를 수 있으므로 실제 적용 조건을 확인합니다.

연산

동일 데이터에서도 처리 로직, 병렬화 수준, 계산 종류, 데이터 크기 및 형식과 갱신 빈도에 따라 사용량이 달라집니다. 상시 자원을 유지하는 스트리밍은 비용이 높아질 수 있지만 아주 낮은 지연을 얻기 위해 배치를 계속 돌리는 방식과의 실제 비교가 필요합니다.

온톨로지 용량

온톨로지 용량은 업무 객체와 그 인덱스 표현의 크기에 영향을 받습니다. 주요 요인은 객체 수, 객체의 속성 수와 값 크기, 객체 사이 링크 메타데이터입니다. 객체 유형당 수십억 개의 객체를 다루거나 객체에 수백 개의 속성을 두는 대규모 구성에서도 같은 요인이 용량을 결정합니다. 많은 객체 또는 큰 텍스트와 미디어 관련 속성을 유지하면 용량이 늘 수 있습니다.

온톨로지는 항공기나 차량 같은 공통 업무 개체를 표현합니다. 원천 행과 열을 그대로 복사하는 저장소와 달리 운영 조회를 위한 표현이므로 원천 파일 크기와 동일한 값으로 판단하지 않습니다.

일반 저장 공간

Foundry storage는 일반 데이터 통합 계층의 파일 저장을 측정합니다. 데이터셋의 여러 브랜치와 과거 트랜잭션도 공간을 사용합니다.

일반 데이터셋에서 DELETE 트랜잭션으로 현재 뷰에서 파일을 제외해도 실제 과거 파일이 물리적으로 제거되는 것은 아닙니다. 브랜치를 변경하는 것만으로 저장 비용이 줄지도 않습니다. 불필요한 트랜잭션의 실제 파일 정리는 Retention 정책으로 관리합니다. 이 설명을 Iceberg 스냅샷 유지보수 같은 다른 자산의 삭제 인터페이스와 혼용하지 않습니다.

Resource Management와 프로젝트 구성

먼저 Resource Management에서 사용량 유형별로 큰 항목을 찾습니다. 리소스 또는 프로젝트, 애플리케이션 소스와 사용자별로 나누어 어떤 구간이 사용량을 만드는지 조사할 수 있습니다.

프로젝트를 원천, 공통 변환, 온톨로지와 업무 활용 단계로 나누면 파이프라인의 어디에서 연산 및 저장이 늘었는지 파악하기 쉽습니다. 프로젝트 경계가 모호하면 큰 사용량이 하나의 묶음으로 합쳐져 개선 대상을 찾기 어렵습니다.

관리자는 프로젝트와 리소스 생성 권한을 조직 규모와 접근 정책에 맞춰 정하고, 권한을 가진 사용자에게 구조 및 사용량 관리 기준을 안내합니다. 무관한 리소스가 여러 프로젝트에 흩어지거나 같은 데이터를 중복 수집하지 않도록 책임과 생성 절차를 관리합니다.

자원 큐

프로젝트들을 자원 큐로 묶고 동시에 사용할 최대 vCPU 수를 제한할 수 있습니다. 이는 한 시점의 연산 할당량을 제어하는 방식입니다. 실행 시간이 길어질 수 있으므로 동시 자원 상한을 전체 기간의 사용량이나 비용 상한과 동일하게 보지는 않습니다.

큐의 범위와 한도를 업무 우선순위에 맞춰 정하고, 대기가 커진 경우 계산이 느린 것인지 할당을 기다리는 것인지 나누어 확인합니다.

증분 수집과 변환

SNAPSHOT은 현재 데이터셋 뷰를 새 트랜잭션의 데이터로 대체합니다. 이전 데이터는 과거 버전으로 남을 수 있지만 기본 조회와 하위 변환은 새 현재 뷰를 읽습니다. 원천 전체를 매번 가져오는 방식은 단순하지만 반복 전송과 저장 및 계산이 커질 수 있습니다.

APPEND는 현재 뷰에 새 파일을 누적합니다. 수집 조건을 함께 구성하여 이전 파일을 다시 가져오지 않고 새 데이터만 수집하면 반복 비용을 줄일 수 있습니다. APPEND라는 쓰기 유형 자체가 원천의 중복 파일을 자동으로 판별하는 것은 아닙니다.

하위 변환도 증분 처리로 작성하여 과거 데이터를 매번 다시 계산하지 않도록 합니다. 스냅샷 전환과 장기 파일 누적에 대한 조건은 그대로 관리해야 합니다.

스케줄 중복 제거

Data Lineage의 노드 색상을 Schedule Count로 바꾸고 여러 스케줄이 연결된 데이터셋에서 Manage schedule을 확인합니다. 소유자와 목적을 비교하여 불필요한 중복 실행을 합칩니다. 일반적으로 데이터셋마다 하나의 예약 빌드를 두는 것이 좋습니다.

전체 빌드를 여러 단계에 중복 설정하기보다 원천 갱신을 트리거로 삼고 최종 출력을 대상으로 하는 연결 빌드로 후속 변환을 묶을 수 있습니다. 원시 Data Connection 동기화의 강제 빌드는 별도 범위로 관리합니다. 일별 정리와 시간별 증분처럼 의도적으로 다른 목적을 가진 스케줄은 매개변수화의 예외 조건을 구분합니다.

불필요한 빈도와 시각 조정

Time since last built 색상으로 자주 갱신되는 데이터를 찾고 실제 소비 요구와 비교합니다.

• 매일 갱신하던 데이터가 주말에는 필요하지 않다면 월요일부터 금요일까지로 줄일 수 있습니다. 실행당 비용이 비슷하다면 주 7회에서 5회가 되어 약 28.6%의 배치 연산을 줄이는 계산입니다.
• 하루 세 번 새 데이터가 필요한지, 야간 한 번이면 충분한지 확인합니다.
• 입력이 바뀌지 않아도 정해진 시각에 실행해야 하는지, 입력 변경 이벤트로 실행해도 되는지 판단합니다.
• 모든 빌드를 같은 시각에 몰지 않고 원천 도착 및 업무 완료 요구에 맞춰 분산합니다.

격일 실행으로 바꿔 횟수를 절반으로 줄이면 비슷한 실행당 비용의 배치에서는 사용량도 대략 절반이 될 수 있습니다. 다만 증분 처리에서는 한 번에 처리할 데이터가 늘어날 수 있어 횟수 비율만으로 총비용을 확정하지 않습니다.

실패 중단과 재시도 비용

Abort build on failure는 실패한 빌드의 나머지 작업을 취소하여 불필요한 연산을 줄일 수 있습니다. 재시도는 일시적인 오류를 복구하지만 반복해서 실패하는 작업의 비용과 감지 지연도 늘립니다.

비용 관리 관점에서는 총 시도 횟수를 3회 이하로 제한하는 선택을 검토할 수 있습니다. 안정성 관점의 스케줄 운영 기준은 최초 시도 뒤 재시도를 세 번 이상 두는 구성을 권장하므로, 어느 지표를 우선할지 업무 SLA와 오류 특성에 맞춰 정합니다. 총 시도 횟수와 재시도 횟수는 서로 다릅니다.

시도 상한은 관리자 설정을 따릅니다. 상한 5회를 사용하는 구성 예시도 있지만 모든 플랫폼의 고정 상한으로 간주하지 않습니다. 재시도 사이에는 보통 1~3분의 간격을 두어 일시적인 문제가 해소될 시간을 줍니다. 멱등적이지 않은 외부 부수 효과가 있다면 재실행의 안전성도 먼저 확인합니다.

Spark 조정은 확인한 병목에 적용

모든 작업의 설정을 일괄 재정의하기보다 병목이 확인된 작업에 한정하여 조정합니다. 기본 구성을 사용하면 동적 실행기 할당이나 관리형 프로필 같은 개선을 적용받기 쉽습니다. 동적 할당이 켜져 있으면 필요한 실행기를 늘리고 불필요한 실행기를 줄일 수 있으므로 고정 실행기 수를 항상 지정할 필요는 없습니다.

Data Lineage의 Spark 사용량 색상과 Spark details로 큰 드라이버, 낮은 병렬성과 많은 작은 태스크를 확인합니다. 알아야 할 기본 자원은 드라이버 코어 및 JVM 메모리, 실행기 코어 및 메모리와 실행기 수입니다. JVM 밖의 메모리는 별도로 구분합니다.

• 필요한 행과 열만 읽도록 일찍 필터링하고 선택합니다.
• 실행기 간 shuffle을 줄입니다.
• count, collect, take 같은 action을 불필요하게 반복하지 않습니다. filter, select 같은 지연 변환과 달리 실제 실행을 요구하고 최적화 및 재사용 범위에 영향을 줄 수 있습니다.
• shuffle로 다시 분배하는 repartition과 기존 파티션을 합치는 coalesce를 구분합니다.
• 키 쏠림을 확인합니다. 조인 유형에 맞는 작은 쪽의 브로드캐스트 또는 업무상 올바른 join salting을 검토할 수 있습니다.
• 병렬성이 낮은 구간과 과도한 작은 태스크를 함께 봅니다. 태스크당 30~60초는 시작 부담을 판단하는 경험적 참고이며 전체 스테이지 시간과 업무 특성에 따라 달라집니다.

구체적인 코드와 파일 배치는 Spark 최적화, 단일 출력과 여러 출력의 실행 경계는 다중 출력 변환에서 설명합니다.