Rubix 실행 기반과 서비스 운영

Rubix는 AIP, Foundry와 Apollo가 사용하는 보안 강화, 자동 확장 및 고가용 Kubernetes 실행 기반입니다. 수명이 짧은 노드, 보안이 기본 설정에 반영된 네트워크, 수요에 따른 확장과 규제 환경에 필요한 통제를 결합합니다.

FedRAMP High, DoD DISA IL-5/IL-6와 CMMC 같은 기준을 충족하는 환경을 운영하는 데 필요한 기능을 제공하도록 설계되었습니다. Palantir 서비스에서 시작했지만 다른 소프트웨어 기업의 제품을 다양한 환경에 배포하는 기반으로도 사용합니다.

워크로드 보안

워크로드는 필요한 조건에 따라 격리합니다. 높은 권한이 필요한 운영 작업과 제한된 애플리케이션 실행을 구분하고 환경 전반에 암호화를 강제합니다. 워크로드 사이의 모든 상호작용은 변경 불가능한 구성에 따라 인증, 인가와 로그 기록을 거칩니다.

이 실행 기반은 Spark 처리에서 출발해 시스템 연결, 데이터 통합, 모델 관리, 애플리케이션 개발, 에이전트와 개발 도구의 런타임으로 확대되었습니다.

단기 수명과 고가용성

Rubix 노드의 수명은 48시간을 넘지 않도록 제한합니다. 서비스는 개별 노드가 교체되거나 실패해도 다른 노드로 이어서 동작하도록 설계해야 합니다. Ontology Manager 같은 사용자용 서비스와 스트리밍 처리 백엔드에 같은 운영 원칙이 적용됩니다.

노드를 자주 교체하면 한 노드의 침해만으로 장기간 거점을 유지하기 어려워집니다. 운영 측면에서는 정책에 따라 교체할 노드를 고르고, 워크로드를 비운 뒤 종료하는 절차로 불안정화를 줄입니다. 컨테이너에 적용하는 MMDP의 72시간 순환 기준과 노드 수명은 대상이 다릅니다.

여러 인프라에서 사용하는 공통 기반

AWS, Azure, Google Cloud, Oracle Cloud와 온프레미스에 공통 운영 인터페이스를 제공합니다. 서비스 개발팀은 제공자별 차이를 실행 기반에 맡기고 기능을 개발할 수 있습니다.

고객의 컨테이너 모델, 사용자 정의 앱과 Kubernetes 호환 워크로드도 Compute Modules 등의 경로로 이 기반을 사용합니다. 워크로드 배치와 수요 감지 및 자동 확장은 연산 자원을 조정하고 비용을 관리하는 데 쓰입니다.

Apollo와 배포 이후 운영

Day 2 운영은 처음 설치한 이후의 업그레이드, 롤백과 지속적인 관리입니다. Apollo는 환경에 있는 서비스들의 설치 및 변경 계획을 계산해 전달합니다.

무중단 갱신을 지원하려면 서비스가 다중 노드와 blue/green 배포 구조를 갖춰야 합니다. 기존 blue 환경을 유지하면서 새 green 환경을 만들고 일정 기간 상태를 관찰합니다. 새 환경이 정상이라면 트래픽을 점진적으로 옮기고 이전 노드를 제거합니다.

Rubix API는 Apollo의 배포 계획을 서비스 생성, 상태 관찰, 제품 리비전과 구성 관리 같은 리소스 수준 명령으로 연결합니다. 노드 교체와 배포 절차를 함께 설계해야 실행 환경이 계속 갱신되는 동안 서비스 가용성을 유지할 수 있습니다.

외부 소프트웨어의 규제 환경 배포

FedStart는 외부 개발팀이 자기 소프트웨어를 규제 환경에 배포하고 FedRAMP 준수 절차를 진행하도록 지원합니다. Mission Manager는 정부기관의 공급업체 온보딩과 관리를 지원하는 제공 방식입니다. Rubix의 공통 실행 기반을 이용하되 실제 배포 및 인증의 범위는 해당 환경과 프로그램의 조건에 따릅니다.