컨테이너를 사용하는 데이터 변환

컨테이너 이미지에 프로그램과 운영체제 라이브러리를 묶으면, Foundry의 Python 패키지 환경만으로 준비하기 어려운 실행 환경을 데이터 파이프라인에 연결할 수 있습니다. 이미지는 먼저 Foundry의 Docker Artifacts 저장소에 등록합니다. 이후 실행 방식에 따라 경량 변환의 실행 환경으로 사용하거나 Spark 실행기 옆에 사이드카로 띄웁니다. 모델 자산도 컨테이너 이미지를 사용할 수 있으며, 모델의 입력과 출력은 컨테이너 모델 등록에서 별도로 구성합니다.

실행 방식 선택

BYOC는 오래된 언어나 특정 버전의 런타임을 이미지에 포함할 수 있습니다. 사용 기간이 끝난 런타임을 넣을 때에는 이미지의 취약점과 공급망 위험도 함께 관리해야 합니다. 컨테이너를 사용해도 Foundry의 권한과 감사 정책은 적용됩니다.

사용 전 관리자 설정

컨테이너 워크플로는 기본적으로 비활성화되어 있습니다. 리소스 관리 권한이 있는 관리자가 Control Panel의 컨테이너 관리 화면에서 Settings를 열어 해당 워크플로를 허용해야 합니다. 이 기능에는 Rubix 기반 실행 환경이 필요하며, Rubix를 사용하지 않는 환경에서는 활성화 스위치를 사용할 수 없습니다.

이미지 작성자는 운영체제 패키지와 외부 실행 파일을 포함한 이미지 내용에 책임을 집니다. 관리자는 실행 중인 이미지에서 발견한 취약점을 확인하고, 취약점을 회수 대상으로 지정해 관련 작업을 중지할 수 있습니다. 그러므로 배포할 이미지 이름과 버전을 명확하게 관리하고, 이미지에 비밀값을 굽지 않아야 합니다.

이미지가 만족해야 하는 조건

Foundry는 seccomp로 컨테이너의 시스템 호출을 제한합니다. 자동 차단 대상에는 새 세션을 만드는 setsid()가 포함되며, 차단된 호출을 실행하면 해당 프로세스가 종료되고 보안 사고 대응팀에 알림이 전달됩니다. 금지된 호출이 필요한 사용 사례는 Palantir 지원팀과 협의해야 합니다. CLI 실행 규약은 새 세션을 만들지 않고 프로세스 그룹을 구성합니다.

Artifacts 저장소에 이미지 등록

1. Foundry에서 Artifacts 저장소를 만들고 저장소 유형을 Docker로 지정합니다.
2. 저장소 화면의 업로드 안내에서 토큰을 발급하고, 안내된 레지스트리 인증 절차를 수행합니다. 토큰을 Dockerfile, 소스 파일이나 이미지 태그에 넣지 않습니다.
3. 업로드 안내에 나온 레지스트리 주소와 저장소 경로를 확인합니다. 아래 명령의 FOUNDRY_CONTAINER_REGISTRY는 이미지 이름 앞에 붙는 전체 경로이며, 실제 환경의 값으로 설정해야 합니다.
4. 해당 예제의 Dockerfile이 있는 로컬 폴더에서 이미지를 빌드합니다. 예를 들어 CLI 예제의 이미지 이름은 simple-cli, 버전은 0.0.1입니다.
5. 동일한 이름과 버전으로 이미지를 푸시합니다. 자세한 저장소 인증과 게시 권한은 아티팩트 게시에 적용된 조건을 따릅니다.

다음 명령은 레지스트리 인증이 끝났고 환경 변수에 실제 저장소 경로를 설정한 상태에서 사용합니다. docker push는 원격 저장소에 이미지를 게시합니다.

: "${FOUNDRY_CONTAINER_REGISTRY:?Artifacts 저장소에 표시된 이미지 경로를 설정하세요}"
IMAGE="${FOUNDRY_CONTAINER_REGISTRY}/simple-cli:0.0.1"
docker build --platform linux/amd64 --tag "$IMAGE" .
docker push "$IMAGE"

코드 저장소에서는 Settings > Libraries에 이미지가 들어 있는 Artifacts 저장소를 로컬 backing repository로 추가합니다. 사이드카 변환에는 Libraries에서 transforms-sidecar도 추가하고 변경 사항을 커밋합니다. 저장소 라이브러리 설정에서 패키지와 아티팩트 저장소를 구분해 관리할 수 있습니다.

Spark 실행기와 사이드카의 관계

일반 Spark 변환은 드라이버가 실행 계획을 만들고 여러 실행기에 작업을 분배합니다.

transforms-sidecar 라이브러리의 @sidecar는 각 실행기 옆에 사용자 이미지의 컨테이너 하나를 실행합니다. 컨테이너는 드라이버 옆에 있는 서버가 아니므로, 실행기와 연결되는 통신은 Spark 작업 함수 안에서 수행합니다.

입력을 여러 파티션으로 처리하면 여러 실행기와 사이드카 쌍이 작업에 참여합니다. 파티션 개수, 입력 행 개수와 실행기 개수는 서로 다른 값입니다. Spark는 한 실행기에 여러 작업을 순차 배정할 수 있고 실패한 작업을 다시 실행할 수도 있습니다.

공유 볼륨은 @sidecar의 volumes=[Volume("shared")]처럼 선언합니다. 이름이 shared인 볼륨은 실행기와 사이드카에서 /opt/palantir/sidecars/shared-volumes/shared로 접근합니다. 이 볼륨으로 입력 준비, 실행 시작, 결과 전달과 결과 회수 완료를 알릴 수 있습니다. 각 실행기와 사이드카 쌍의 로컬 공유 공간이므로, 모든 실행기가 하나의 전역 작업 디렉터리를 공유한다고 가정하지 않습니다.

Foundry는 컨테이너를 실행하지만 사용자 프로그램의 파일 준비 여부나 결과 회수 완료 시점까지 자동으로 알지는 못합니다. 파일 기반 프로그램에는 요청 단위 시작 및 종료 규약을 구현해야 합니다. 사이드카를 사용하는 변환도 파이프라인의 일정, 브랜치와 데이터 건강 검사에 연결됩니다.

사이드카 리소스 프로필

@sidecar의 resource_profile은 사이드카 컨테이너에 할당할 CPU, 메모리와 GPU를 지정합니다. Spark 실행기의 프로필과 별도 설정입니다. 예를 들어 resource_profile="LARGE_CPU_LARGE_MEMORY_GPU_ENABLED"를 지정하면 해당 사이드카에 표의 GPU 프로필을 적용합니다.

공유 메모리 항목은 파일 교환용 Volume과 구분합니다. GPU 항목은 NVIDIA GPU의 수를 지정하며, 특정 GPU 모델을 선택한다는 뜻은 아닙니다.