이전 글에서는 OCR 파이프라인을 API 서버와 GPU 워커 서버로 분리하고, GPU 리소스를 중앙 집중식으로 관리하는 구조까지 설계해보았습니다.
이번 글에서는 그 구조를 실제로 서버 운영 환경에 올리기 위해 반드시 마주치게 되는 문제, 바로 공유 스토리지(NFS)와 보안 설계에 대해 다뤄보려 합니다.
단순히 “파일을 공유한다” 수준이 아니라, 여러 서버가 동시에 접근해도 안전한지 root 권한 남용 위험은 없는지 컨테이너 환경에서도 파일 권한이 꼬이지 않는지 같은 운영 관점의 고민을 중심으로 정리해보려 합니다.
OCR 워커를 서버 한 대(Server 2)에만 올리는 구조를 선택하면서, 자연스럽게 생긴 요구사항이 있습니다.
Server 4 (운영), Server 5 (개발), Server 6 (온디맨드) 이 세 서버에서 들어오는 OCR 요청들이 모두 Server 2의 OCR 워커로 몰리게 되는 구조입니다. API 서버는 각자 다른 서버에 존재, OCR 워커는 단일 서버, 하지만 같은 파일을 바라봐야 함
이 상황에서 선택지는 두 가지였습니다.
- 파일을 API 요청 바디에 실어서 네트워크로 전달
- 모든 서버가 동일한 파일 경로를 바라보는 공유 스토리지 구성
OCR 파일은 크기가 크고, 처리 시간이 길며, 중간 결과나 재처리 가능성까지 고려해야 했기 때문에 두 번째 방식(공유 스토리지) 이 훨씬 운영 친화적이라 판단했습니다.
위 구조에서 중요한 점은 파일을 누가 소유하느냐가 아니라, 어떤 UID/GID로 접근하느냐입니다. 모든 서버와 컨테이너의 실행 유저를 UID 1001로 통일하고, NFS에서는 root_squash 옵션을 통해 클라이언트의 root 권한을 제거함으로써 공유 스토리지 환경에서도 최소 권한 원칙을 유지할 수 있도록 설계했습니다.
NFS에서 가장 중요한 보안 포인트
NFS는 설정을 잘못하면 서버 전체가 열리는 구조가 되기도 합니다.
NFS 기본 설정에서 가장 위험한 부분은 이겁니다.
클라이언트의 root = 서버의 root
이 상태로 두면, 컨테이너 내부 root, 서버 root, 다른 서버 root 가 모두 같은 권한이 되어버립니다.
해결책은 root_squash!!
/srv/nfs/ocr 10.0.0.0/24(rw,sync,no_subtree_check,root_squash)
이 설정 하나로, 클라이언트의 root 권한 → nobody (익명 유저) 서버 파일 시스템 직접 침범 차단 운영 서버에서 반드시 필요한 옵션입니다.
컨테이너 환경에서 NFS를 쓰다 보면 가장 많이 터지는 문제가 파일 권한 꼬임입니다.
그래서 선택한 방식이, 서버 2 / 4 / 5 / 6, 모든 컨테이너, OCR 워커 프로세스 모두 UID / GID 를 같은 값으로 통일시키자!
이렇게 하면, NFS 상의 파일 소유자가 항상 동일, 컨테이너 ↔ 호스트 ↔ 다른 서버 간 권한 충돌 없음, chmod/chown 문제 해결
접근 제어 – “누가 접근할 수 있는가”
- 내부 사설망 IP만 허용
- 외부 접근 차단
- 서버 IP 화이트리스트 방식