배포 자산에 cas-add-nfs-mount.yaml 이라는 예제가 있다 보니, "CAS Disk Cache 를 NFS 로 잡으라는 뜻인가" 하고 혼동하기 쉽다. 둘은 목적이 완전히 다르다.
| CAS Disk Cache | cas-add-nfs-mount 로 붙이는 볼륨 |
|
|---|---|---|
| 성격 | CAS 엔진 내부용 스크래치 · 캐시 | 사용자 · 업무 데이터 경로 |
| 지속성 | 휘발성. 날아가도 무방 | 영속. 날아가면 안 된다 |
| 기본 구성 | emptyDir |
PV · PVC |
| 지정 방법 | CASENV_CAS_DISK_CACHE 환경 변수 |
트랜스포머로 파드에 마운트 추가 |
| 권장 스토리지 | 노드 로컬 SSD · NVMe | NFS 등 공유 스토리지 |
CAS 는 테이블을 메모리에 올릴 때 블록 단위로 정리한다. 이 블록이 다음 두 경로로 Disk Cache 를 쓴다.
업로드한 파일의 임시 저장에도 쓰인다. 성격이 스크래치라서 지연에 매우 민감하고, 잃어버려도 되는 데이터다.
경로는 환경 변수로 지정한다.
CASENV_CAS_DISK_CACHE=/cas/cache
기술적으로 불가능하지는 않지만 권장되지 않는다. 이유는 성격의 불일치다.
선호 순서는 다음과 같다.
hostPath 로 쓴다.로컬 디스크가 아예 없고, 캐시로 인한 성능 향상을 기대하지 않으며, 단지 디스크 공간 확보가 목적이고, NFS 가 전용 네트워크에 충분한 IOPS 를 갖췄다면 타협할 수 있다. 그 경우에도 차선책임을 기록해 둔다.
CAS 가 읽고 쓸 공유 디렉터리(PATH 기반 caslib 의 대상)를 파드에 붙일 때 쓰는 것이 cas-add-nfs-mount.yaml 이다. NFS 가 아닌 호스트 경로를 붙일 때는 cas-add-host-mount.yaml 을 쓴다.
예제 파일을 site-config 로 복사해 값을 고치고, 배포 루트의 kustomization.yaml 의 transformers: 에 추가한 뒤 빌드한다.
$deploy/sas-bases/examples/cas/configure/cas-add-nfs-mount.yaml
→ $deploy/site-config/cas-add-nfs-mount.yaml
kustomize build $deploy | kubectl apply -f -
MPP CAS 는 컨트롤러 1대에 워커 N대 구조이고, 테이블은 워커 메모리에 분산된다. 워커 하나가 빠지면 그 워커가 들고 있던 조각이 사라지므로 일관성을 지키기 위해 세션이 종료된다. 파드가 다시 떠서 클러스터에 재합류해도 이미 끝난 세션은 자동으로 살아나지 않고, 메모리에 올려 두었던 테이블은 다시 적재해야 한다.
Disk Cache 에 저장되는 내결함성용 블록 복사본이 이 상황을 완화하지만, 워커가 2대뿐이면 효과가 제한적이다. 남은 워커 한 대가 전체를 떠안아야 해서 메모리 여유가 없으면 그대로 실패한다. 복제로 메모리 사용량도 늘어난다. 워커를 3대 이상 둘 때 의미가 생긴다.
정리하면 워커 2대 구성은 병렬 처리로 성능을 나누는 구성이지 고가용성 구성이 아니다. 중요 업무라면 워커 수를 늘리고, 세션 종료 시 테이블을 다시 올리는 절차를 자동화해 두는 편이 현실적이다.