이번 글에서는 Backend.AI의 스토리지 지원 기능 중 타 컨테이너 관리 솔루션에서는 보기 어려운 자동마운트 폴더 기능에 대해 소개합니다. 자동마운트 폴더를 활용하면 서로 다른 연산 세션 간에도 사용자가 설치한 프로그램이나 설정을 손쉽게 공유할 수 있습니다.
먼저 컨테이너가 파일시스템을 어떻게 다루는지 간단히 짚어보겠습니다. Backend.AI를 비롯한 대부분의 컨테이너 환경은 완전한 가상 디스크가 주어지는 가상머신(virtual machine) 환경과 달리 오버레이(overlay) 파일시스템이라는 개념으로 컨테이너만을 위한 가상의 파일시스템 뷰(view)를 만들어주는 방식으로 동작합니다. 이를 통해 호스트와 Linux kernel을 공유하면서도 아예 다른 배포판을 돌릴 수 있게 됩니다. (예: Ubuntu 호스트에서 CentOS 컨테이너 실행) 특히, 컨테이너가 실행 중인 동안 파일시스템에 가해진 모든 변경사항은 별도의 overlay layer로 유지되다가 컨테이너를 종료하는 시점에 삭제함으로써, 매우 적은 성능 오버헤드로 컨테이너 이미지를 항상 처음 빌드한 그 상태 그대로 유지하고 컨테이너 환경의 재현성(reproducibility)을 확보하는 중요한 역할을 합니다.
이 설명이 좀 어렵다면, '하드보안관'을 대신 떠올려볼 수 있습니다. 90년대 말에서 2000년대 초쯤 초중고 시절을 보냈다면 학교 컴퓨터실에 설치된 하드보안관이라는 프로그램을 기억하시는 분들이 많이 있을 것입니다. 컴퓨터를 끄거나 재부팅하면 처음 켤 때의 상태로 하드디스크 내용이 자동으로 되돌아가는 신기한(?) 프로그램이었죠. 아무래도 불특정 다수가 컴퓨터를 건드리다보면 개인 작업 파일을 지우지 않고 남겨두거나 인터넷에서 다운받은 프로그램을 통해 바이러스에 걸리는 등의 일이 발생하기 쉬웠기 때문에 컴퓨터 관리를 보다 쉽게 할 수 있게 해주는 프로그램으로 각광을 받았습니다. 말하자면, 컨테이너는 하드보안관이 기본으로 적용된 상태라고 생각하실 수 있습니다.
하지만 실제로 컨테이너 자체를 어플리케이션 배포용이 아닌 수시로 프로그램을 설치하거나 업데이트하는 개발 환경으로 활용하고자 하는 경우, 이러한 휘발성은 오히려 사용자 입장에서 불편함을 야기하기도 합니다.
Backend.AI가 그러한 대표적 사례라고 할 수 있는데, 이미 저희가 고객분들에게 NGC (NVIDIA GPU Cloud) 기반으로 각종 오픈소스 소프트웨어를 사전 설치한 컨테이너 이미지를 제공해드리고 있음에도 추가로 Python 패키지를 더 설치하고 싶다거나 하는 요구가 많이 발생합니다.
docker commit을 통한 컨테이너 이미지 생성 기능을 추가해달라고 요청하시는 경우도 있습니다.
하지만 Backend.AI에서 사용자 세션의 홈디렉토리(/home/work)는 보다 나은 I/O 성능을 위해 overlay layer가 아닌 별도의 임시 호스트 디렉토리(scratch directory)를 할당하는 방식으로, 엄밀히는 컨테이너용 overlay layer는 아니지만 컨테이너 종료 시 자동 삭제되는 특성을 공유합니다. (그림 1)
그러다보니 컨테이너를 "commit"하여 이미지를 만들더라도 홈디렉토리 내용은 포함되지 않고, 더군다나 이미 스토리지 폴더 기능을 통해 탑재한 폴더들은 이와 상관 없이 이미지에 포함하는 것이 불가능합니다. (그림 2, 그림 3)
이러한 이유로 Backend.AI에서는 docker commit에 대응하는 기능을 제공하지 않고, 대신 고객 요청에 따라 새로운 이미지를 만들어드리거나 자체적으로 추가 패키지에 대한 수요를 파악하여 업데이트하는 방식을 택하고 있습니다.1
docker commit의 결과
docker commit할 수 없는 이유그렇다면 컨테이너 이미지와 상관 없이 자신만의 추가 패키지나 설정을 편하게 불러와 사용할 방법이 없는 것일까요?
자동마운트 폴더가 바로 이러한 불편을 해소하기 위해 제공되는 기능입니다.
일반적인 Linux 어플리케이션의 경우 사용자별 설정이나 추가 데이터를 홈디렉토리 아래의 .local, .config 디렉토리를 통해 기록합니다.
Windows 환경으로 치면 사용자 디렉토리 아래에 숨겨져 있는 AppData 폴더와 같은 역할입니다.
이 점을 이용하여, Backend.AI에서 각 사용자가 .local, .config와 같이 점(dot)으로 시작하는 이름의 스토리지 폴더를 만들어두면, 그 사용자의 모든 세션에는 항상 그 스토리지 폴더들이 자동으로 탑재됩니다.
따라서 마치 개인적으로 설치한 프로그램이나 설정들을 연산 세션을 켜고 끔과 상관 없이 계속 가지고 다닐 수 있게 되는 것이죠. (그림 4)
예를 들면, Python에서 패키지를 설치할 때 pip install --user {pkgname}과 같이 --user 옵션을 주면 홈디렉토리 아래의 .local/lib/python3.9/site-packages/{pkgname}과 같은 경로에 설치됩니다.
(Python의 major.minor 버전 번호가 경로에 포함되어 있음을 주목해주시기 바랍니다!)
PATH 환경변수에 ~/.local/bin을 등록해두었다면 패키지와 함께 설치되는 스크립트나 명령어들도 마치 시스템 패키지로 설치한 것처럼 그대로 사용할 수 있습니다.
여기서 주의하실 점은 프로그램에 따라 버전을 구분하는 경우도 있다는 것입니다.
예를 들면 Python 3.8을 사용하는 컨테이너에서 pip install --user로 설치한 패키지는 Python 3.6을 사용하는 컨테이너에서는 두 Python 버전이 조회하는 설치 경로가 다르므로 서로 보이지 않게 됩니다.
하지만 같은 Python 버전을 사용하는 컨테이너라면 다른 이미지를 사용하더라도 앞서 설치한 패키지가 그대로 설치된 것처럼 동작하는 것을 볼 수 있습니다.
많은 Backend.AI 사용자들은 기존의 가상머신 개념에는 익숙하지만 휘발성 있는 파일시스템을 가진 컨테이너의 스토리지 관리 개념에 대해서는 생소해하시는 경우가 많습니다. 이번 블로그 글을 통해 Backend.AI의 세션 컨테이너에 스토리지가 어떤 구조로 연동되는지, 해당 구조의 단점을 보완하여 개인화된 개발환경을 만들 수 있도록 사용자 수준 패키지와 설정을 관리할 수 있게 도와주는 자동마운트 폴더 기능에 대해 살펴보았습니다. 앞으로 더욱 편리하게 Backend.AI를 활용하시기 바랍니다!
- Backend.AI 자체에서 기존 일반 컨테이너 이미지를 import하여 Backend.AI에서 사용할 수 있도록 metadata를 등록하는 기능이 제한적으로 제공되기는 하지만 실행 중인 세션을 거치는 방식은 아닙니다. 향후 해당 기능에 대해 보다 고도화된 사용자화를 제공할 예정입니다.↩