연산과 저장 사용량의 단위 및 귀속
Resource Management는 프로젝트와 온톨로지가 사용하는 연산 및 저장 자원을 종류별로 집계합니다. 실제 경과 시간, 할당한 연산량과 저장 기간은 서로 다른 값이므로 단위를 확인해 비교해야 합니다.
경과 시간과 compute-seconds
Wall-clock time은 시작부터 끝까지 시계로 잰 경과 시간입니다. Compute-second는 Foundry가 수행한 연산 작업량의 기본 단위이며 경과 시간 그 자체가 아닙니다.
여러 실행기가 병렬로 작업하면 경과 시간 1초 동안 여러 compute-seconds를 사용할 수 있습니다. 두 사람이 각각 8시간 일하면 경과 시간은 8시간이지만 작업량은 16인시인 것과 같은 구분입니다. 실행기 수와 크기, 데이터 크기 및 연산 복잡도가 사용량에 영향을 줍니다.
배치, 대화형과 지속 실행
병렬 배치 연산
배치는 일정 또는 수동 요청으로 백그라운드에서 실행합니다. 실행하지 않는 동안에는 배치 작업의 연산 자원을 소비하지 않으며, 자원이 할당된 시점부터 작업이 자원을 반환할 때까지 사용량을 측정합니다. 준비와 정리 시간도 실행 자원을 점유한다면 포함됩니다.
다음 배치 작업의 vCPU와 메모리 사용을 작업별로 측정하고 데이터셋 또는 객체 수준으로 집계합니다.
- Java, Python, SQL, Mesa와 GPU를 포함한 Transforms 작업
- Pipeline Builder
- Contour에서 저장한 데이터셋의 빌드. Contour Preview, Analysis와 Report 조회는 이 범주와 구분합니다.
- Code Workbook
- 온톨로지 및 시계열 등 색인 저장소 동기화
- Object Storage v1(Phonograph) 쓰기 반영 작업
- Data Health 검사
병렬 대화형 연산
대화형 질의는 사용자 세션 중 실시간으로 계산합니다. 빠른 응답을 위해 유휴 연산 자원을 항상 유지하므로 배치 실행보다 비용이 높습니다. 질의가 스케줄링된 백엔드의 사용량 중 해당 질의의 몫을 계산한 뒤 프로젝트별로 집계합니다.
현재 Contour 대시보드, 분석과 Preview, 온톨로지 질의, 시계열 질의와 Code Workspaces가 포함됩니다.
병렬 지속 실행 연산
지속 실행은 메시지를 언제든 받아 로직을 처리할 수 있는 장기 실행 작업입니다. 실제 메시지를 처리하는 순간뿐 아니라 작업을 받을 준비 상태로 유지하는 동안을 측정합니다. Streaming과 Foundry Machine Learning이 해당합니다.
지속 실행 작업 생성은 모든 환경에서 제공되지 않을 수 있으므로 필요한 경우 Palantir 담당자에게 문의합니다.
Core-seconds와 메모리 비율
Core-seconds는 할당한 vCPU 수와 점유 시간을 곱한 값입니다. 2개 코어를 3초 사용하면 6 core-seconds입니다. CPU 사용률이 낮아도 할당한 코어를 기준으로 측정하므로 필요한 만큼만 요청해야 합니다.
Spark 작업에서는 driver와 executor 수 및 코어를 함께 고려합니다. 예를 들어 spark.driver.cores가 3이고 spark.executor.cores가 2라면, 같은 시간 동안 유지된 구성의 계산은 다음과 같습니다.
core_seconds = (driver_cores + executor_cores * executor_count) * duration_seconds
실제로 서로 다른 시간 동안 할당된 자원은 각자의 점유 시간으로 계산합니다. 연산이 아직 할당되지 않은 대기 상태와 자원을 점유한 실행 준비 및 정리 시간을 구분합니다.
메모리도 하드웨어 용량을 차지합니다. 가상의 4코어, 32 GiB 머신에 1코어와 8 GiB를 요청하는 작업 네 개를 배치할 수 있지만, 하나가 16 GiB를 요구하면 나머지 세 개를 모두 같은 머신에 넣을 수 없습니다. 코어가 남더라도 메모리 때문에 추가 용량이 필요할 수 있습니다.
Foundry의 기본 메모리-코어 비율은 코어당 7.5 GiB입니다. 한 할당 단위의 환산 코어 수는 다음과 같습니다.
환산 코어 수 = max(할당 vCPU 수, 할당 메모리 GiB / 7.5)
compute_seconds = 각 할당 단위의 (환산 코어 수 * 점유 초 수)를 합산한 값
메모리 비율 계산 예
동일한 executor 두 개에 각각 1 vCPU와 12 GiB를 할당하고 5초 동안 유지했다고 가정합니다.
| 계산 | 값 |
|---|---|
| 두 executor의 core-seconds | 1 * 2 * 5 = 10 |
| executor당 메모리 환산 코어 | 12 / 7.5 = 1.6 |
| 두 executor의 compute-seconds | max(1, 1.6) * 2 * 5 = 16 |
이 계산은 예시의 executor 두 개에 대한 값입니다. 실제 작업의 전체 사용량에는 driver 등 다른 할당 자원도 포함합니다.
색인 질의와 Ontology volume
온톨로지와 시계열 같은 색인 저장소의 온디맨드 질의도 compute-seconds를 사용합니다. 질의가 쓰는 연산과 색인을 보관하는 용량은 별도 항목입니다.
Ontology volume은 업무 질의를 지원하는 색인 저장 형식의 크기를 gigabyte-months로 측정합니다. 다음 저장소가 대상입니다.
- Ontology objects v1과 v2
- Postgate의 Postgres 인터페이스. 모든 Foundry 구성에서 제공되는 것은 아닙니다.
- 온톨로지 매핑 없이 사용하는 이전 Lime 문서 저장소
원본 데이터셋과 색인 저장소는 배치 형식 및 압축이 달라 크기가 같지 않을 수 있습니다.
Foundry storage와 트랜잭션 이력
Foundry storage는 온톨로지 외의 일반 변환 계층 데이터를 측정하며 단위는 gigabyte-months입니다. 데이터셋마다 브랜치, 이전 트랜잭션과 뷰가 차지하는 공간을 고려합니다.
데이터셋에 커밋되었거나 중단된 트랜잭션이 추가한 실제 파일의 크기를 합산하고, Retention으로 삭제한 트랜잭션의 공간을 뺍니다. DELETE 트랜잭션으로 현재 뷰에서 파일을 제거해도 실제 저장 파일이 삭제되는 것은 아니므로 저장 사용량이 계속 발생할 수 있습니다.
브랜치를 갱신하거나 DELETE 트랜잭션을 커밋하는 것만으로 이 저장량을 줄이지 못합니다. 불필요한 이력의 실제 공간을 회수하려면 Retention을 적용해야 합니다.
온톨로지의 프로젝트 귀속
Ontology volume은 일반적으로 객체 입력 데이터소스가 있는 프로젝트에 귀속됩니다. 프로젝트의 상세 내역에는 Foundry 리소스와 객체가 함께 나타납니다.
객체가 여러 프로젝트의 입력 데이터소스를 사용하는 등 한 프로젝트로 연결할 수 없으면 온톨로지 자체에 귀속합니다.
객체의 Foundry compute는 데이터셋을 객체 유형으로 색인하고 동기화하는 비용이며, Ontology volume은 객체 유형 색인의 크기입니다. 객체 자체의 Foundry storage 항목은 비어 있습니다. 편집 결과를 별도 데이터셋으로 내보내 저장하는 경우에는 그 데이터셋의 저장 사용량으로 구분합니다.
Workshop 앱에 사용량을 귀속할 때에는 그 안의 임베디드 모듈에서 발생한 사용량도 포함합니다.
UTC와 완료 시각
Resource Management의 시각, 날짜 범위와 집계는 모두 UTC입니다. 작업 사용량은 끝난 UTC 날짜에 귀속합니다. 여러 날에 걸친 작업도 시작 날짜로 나누지 않고 완료 날짜에 전체 사용량을 반영합니다. 배치, 대화형과 지속 실행 연산 모두 이 귀속 기준을 고려해야 합니다.
Gigabyte-month 계산
Gigabyte-month는 저장 공간과 보관 시간을 결합한 단위입니다. 1 GB를 한 달 내내 보관하면 1 GB-month입니다. 공간은 매시간 측정하고 해당 달의 전체 시간으로 나누어 집계합니다. 메모리 계산의 GiB와 저장 지표의 GB 표기를 구분합니다.
30일인 달의 저장 이력 예시는 다음과 같습니다.
| 구간 | 저장량 | 기간 |
|---|---|---|
| 1일 00:00부터 4일 06:00 전까지 | 0 GB | 3.25일 |
| 4일 06:00부터 11일 00:00 전까지 | 3 GB | 6.75일 |
| 11일 00:00부터 21일 00:00 전까지 | 6 GB | 10일 |
| 21일 00:00부터 다음 달 1일 00:00 전까지 | 3 GB | 10일 |
(0 * 3.25 + 3 * 6.75 + 6 * 10 + 3 * 10) / 30 = 3.675 GB-months
같은 90 GB를 하루 저장해도 30일인 달에는 90 / 30 = 3, 31일인 달에는 90 / 31 ≈ 2.90 GB-months입니다. 일정한 저장량의 일간 또는 주간 집계는 월 길이에 따라 달라질 수 있지만 한 달 전체의 같은 용량 사용은 같은 GB-months가 됩니다.
애플리케이션별 사용 항목
다음 표는 연산, 온톨로지 용량과 일반 저장량의 발생 구분입니다. 쓰기 반영은 객체 집합의 사용자 편집이나 생성 객체를 저장하는 경우, export는 편집 결과를 지정한 쓰기 반영 데이터셋으로 저장하는 경우입니다. Other applications는 문서 안의 Contour board처럼 임베디드 앱에서 발생한 사용량을 뜻합니다.
데이터 변환
| 애플리케이션 | Foundry compute | Ontology volume | Foundry storage |
|---|---|---|---|
| Code Repositories: Python, Java, SQL, GPU, Mesa | 발생 | 없음 | 발생 |
| Streaming repositories | 발생 | 없음 | 없음 |
| Pipeline Builder | 발생 | 없음 | 발생 |
| Preparation | 발생 | 없음 | 발생 |
| Data Connection: Agent-based | 없음 | 없음 | 발생 |
| Data Connection: cloud ingest | 발생 | 없음 | 발생 |
| Data Health | 발생 | 없음 | 없음 |
| Dataset projections | 발생 | 없음 | 없음 |
| Object indexing: Phonograph2 | 발생 | 발생 | 없음 |
| Time series indexing | 발생 | 없음 | 없음 |
| Recipes | 발생 | 없음 | 없음 |
분석
| 애플리케이션 | Foundry compute | Ontology volume | Foundry storage |
|---|---|---|---|
| Code Workbook: Spark | 발생 | 없음 | 발생 |
| Code Workbook: GPU | 발생 | 없음 | 발생 |
| Contour analysis | 발생 | 없음 | 없음 |
| Contour builds and dashboards | 발생 | 없음 | 발생 |
| Reports | 임베디드 앱에서 발생 | 없음 | 없음 |
| Restricted Views | 발생 | 없음 | 없음 |
| Notepad | 임베디드 앱에서 발생 | 없음 | 없음 |
| Fusion | 없음 | 발생 | 쓰기 반영 시 발생 |
모델 및 AI 통합
| 애플리케이션 | Foundry compute | Ontology volume | Foundry storage |
|---|---|---|---|
| Foundry ML batch | 발생 | 없음 | 발생 |
| Foundry ML live | 발생 | 없음 | 없음 |
온톨로지와 애플리케이션
| 애플리케이션 | Foundry compute | Ontology volume | Foundry storage |
|---|---|---|---|
| Ontology objects | 발생 | 발생 | export 시 발생 |
| Ontology relationship tables | 발생 | 발생 | export 시 발생 |
| Ontology Actions | 발생 | 쓰기 반영 시 발생 | 없음 |
| Direct Object Storage v1 indices | 발생 | 발생 | export 시 발생 |
| Postgres indices | 발생 | 발생 | 없음 |
| Direct Lime indices | 발생 | 발생 | 없음 |
| Foundry Rules | 발생 | 발생 | 발생 |
이 분류로 사용량을 해석한 뒤 Analysis에서 날짜, 소스와 프로젝트를 맞춰 비교합니다. 큐 사용률은 모든 종류의 사용량을 포함하지 않으므로 전체 비용과 동일시하지 않습니다.