관리자 계정으로 로그인 하면 왼쪽 사이드바 하단에 Administration 메뉴가 추가로 보입니다. Backend.AI 에 등록된 사용자 정보는 Users 탭에서 볼 수 있습니다. 슈퍼관리자 권한의 사용자는 모든 사용자의 정보를 확인하거나, 생성 및 삭제할 수 있습니다.
사용자 ID(이메일), 이름(사용자 이름), 역할, 소개는 컬럼 헤더의 검색창에 텍스트를 입력하여 조회 결과를 필터링할 수도 있습니다.
사용자는 '+ 사용자 추가' 버튼을 클릭하여 생성할 수 있습니다. 이 때 비밀번호는 8자 이상, 알파벳/특수문자/숫자를 각각 1개 이상 포함해야 합니다. 사용자 이름과 성명 필드에는 각각 최대 64자까지 입력할 수 있습니다.
이미 같은 이메일이나 사용자 이름이 있는 사용자가 존재한다면 사용자를 생성할 수 없습니다. 다른 이메일과 사용자 이름을 사용해 보십시오.
사용자가 생성되었는지 확인합니다.
Controls 패널의 초록색 버튼을 클릭하면 더 자세한 사용자 정보를 확인할 수 있습니다. 사용자가 속한 도메인과 프로젝트 정보도 확인할 수 있습니다.
'제어' 열의 '설정' 버튼을 클릭하면 이미 존재하는 사용자의 정보를 수정할 수 있습니다. 사용자의 이름, 비밀번호, 활성화 상태 등을 변경할 수 있습니다. 사용자 ID(이메일)는 변경할 수 없습니다.
사용자 생성/수정 대화 상자에는 다음과 같은 필드가 포함되어 있습니다.
-
이메일: 사용자의 이메일 주소로, 로그인 ID로 사용됩니다. 생성 후에는 변경할 수 없습니다.
-
사용자 이름: 사용자의 고유 식별자입니다 (최대 64자).
-
성명: 사용자의 표시 이름입니다 (최대 64자).
-
비밀번호: 8자 이상이어야 하며, 알파벳, 특수문자, 숫자를 각각 1개 이상 포함해야 합니다.
-
설명: 사용자에 대한 선택적 설명입니다 (최대 500자).
-
사용자 상태: 사용자의 상태를 나타냅니다. Inactive 사용자는 로그인할 수 없습니다. Before Verification은 이메일 인증이나 관리자의 승인과 같은 추가 단계를 거쳐야 계정을 활성화할 수 있는 상태를 나타냅니다. Inactive 사용자는 Inactive 탭에 별도로 표시됩니다.
-
역할: 사용자의 역할 (user, admin, superadmin). 현재 사용자의 권한에 따라 선택 가능한 옵션이 달라집니다.
-
도메인: 사용자가 속한 도메인입니다. 이 필드는 사용자 생성 화면과 수정 화면 모두에 표시됩니다.
-
프로젝트: 사용자가 속할 프로젝트를 하나 이상 선택합니다. 선택한 도메인에 따라 사용 가능한 프로젝트가 달라집니다.
-
비밀번호 변경 필요: 관리자가 사용자를 일괄 생성할 때 무작위 비밀번호를 선택한 경우, 이 필드를 ON으로 설정하여 비밀번호 변경이 필요함을 나타낼 수 있습니다. 사용자에게 비밀번호를 업데이트하라고 알리는 상단 바가 표시되지만, 이는 일종의 설명용 플래그로 실제 사용에는 영향을 미치지 않습니다.
-
sudo 세션 허용: 사용자가 연산 세션에서 sudo를 사용할 수 있도록 허용합니다. 이는 사용자가 root 권한이 필요한 패키지를 설치하거나 명령을 실행해야 할 때 유용합니다. 그러나 보안 문제를 일으킬 수 있으므로 모든 사용자에게 이 옵션을 활성화하는 것은 권장되지 않습니다.
-
이중 인증 사용: 사용자가 2단계 인증을 사용하는지 여부를 나타내는 플래그입니다. 2단계 인증을 사용하는 경우, 사용자는 로그인 시 추가로 OTP 코드를 입력해야 합니다. 관리자는 다른 사용자의 2단계 인증만 비활성화할 수 있습니다.
-
자원 정책: Backend.AI 버전 24.09부터, 사용자가 속한 사용자 자원 정책을 선택할 수 있습니다. 사용자 자원 정책에 대한 자세한 내용은 사용자 자원 정책 섹션을 참고하세요.
-
허용된 클라이언트 IP: 이 사용자 계정으로 시스템에 접근할 수 있는 IP 주소를 제한합니다. IP 주소 또는 CIDR 표기법으로 입력합니다 (예:
10.20.30.40,10.20.30.0/24). 비워두면 모든 IP에서 접근이 허용됩니다. -
컨테이너 UID: 컨테이너 내부 프로세스에 할당되는 숫자 사용자 ID입니다. 파일 권한 목적으로 컨테이너가 특정 UID와 일치해야 할 때 유용합니다.
-
컨테이너 GID: 컨테이너 내부 프로세스에 할당되는 기본 숫자 그룹 ID입니다.
-
보조 GID: 컨테이너 프로세스에 할당되는 추가 숫자 그룹 ID입니다. 여러 GID를 쉼표로 구분하여 입력합니다.
-
기본 액세스 키: (수정 시에만 사용 가능) 사용자의 keypair 중 API 인증에 사용될 기본 액세스 키를 선택합니다.
:::note 이 기능은 Backend.AI Manager 버전 26.2.0 이상에서만 사용할 수 있습니다. :::
여러 사용자 계정을 한 번에 생성해야 할 때 사용자 일괄 생성 기능을 사용할 수 있습니다.
Manager 26.2.0 이상에서는 Users 페이지의 사용자 추가 버튼 옆에 말줄임표(...)
드롭다운 버튼이 표시됩니다. 이 드롭다운 버튼을 클릭하고 사용자 일괄 생성을
선택하면 일괄 생성 대화 상자가 열립니다.
일괄 생성 대화 상자에는 다음 필드가 포함되어 있습니다. 대화 상자 상단의 안내 배너에 접두사 뒤에 zero-padded 순번이 붙어 이메일과 사용자명이 자동 생성된다는 설명이 표시됩니다.
- 이메일 접두사 (@ 앞): 자동 생성되는 이메일 주소의 접두사 부분입니다. 문자, 숫자, 점, 하이픈, 밑줄만 사용할 수 있습니다 (최대 30자).
- 이메일 접미사 (@ 뒤): 자동 생성되는 이메일 주소의 도메인 부분입니다.
이 필드에는
@접두사가 자동으로 표시됩니다 (최대 30자). - 생성할 사용자 수: 생성할 사용자 계정 수입니다 (1~100). 이 필드 하단에 생성될
이메일 주소의 실시간 미리보기가 표시됩니다. 4명 이하일 경우 모든 이메일이 표시되고,
5명 이상일 경우 처음 2개, 줄임표, 마지막 이메일이 표시됩니다 (예:
student01@example.com, student02@example.com ... student10@example.com). - 비밀번호: 생성되는 모든 사용자의 공유 초기 비밀번호입니다. 단일 사용자 생성과 동일한 비밀번호 규칙이 적용됩니다 (8자 이상, 알파벳/특수문자/숫자 각 1개 이상 포함).
- 비밀번호 변경 필요: 일괄 생성 시 기본값이 ON으로 설정됩니다. 활성화하면 각 사용자가 첫 로그인 시 비밀번호를 변경하라는 안내를 받게 됩니다.
- 도메인: 생성된 사용자가 속할 도메인입니다.
- 역할, 상태, 자원 정책, 프로젝트 등 기타 필드는 단일 사용자 생성과 동일합니다.
사용자 이름과 이메일 주소는 입력한 접두사와 접미사를 기반으로 자동 생성됩니다.
예를 들어, 이메일 접두사를 student, 이메일 접미사를 example.com, 생성할 사용자
수를 10으로 설정하면 다음과 같은 계정이 생성됩니다:
| 사용자 이름 | 이메일 |
|---|---|
student01 |
student01@example.com |
student02 |
student02@example.com |
| ... | ... |
student10 |
student10@example.com |
:::note
순번은 총 사용자 수에 따라 zero-padding이 적용됩니다. 예를 들어, 3명이면
student1 부터 student3, 10명이면 student01 부터 student10, 100명이면
student001 부터 student100이 됩니다.
:::
:::warning 생성하려는 사용자 이름이나 이메일 주소 중 일부가 이미 존재하는 경우, 작업이 부분적으로 성공할 수 있습니다. 경고 메시지에 성공적으로 생성된 사용자 수와 실패한 사용자 수가 표시됩니다. :::
슈퍼관리자라도 사용자 계정을 삭제하는 것은 허용되지 않습니다. 이는 사용자별 사용 통계 추적, 메트릭 보존, 실수로 인한 계정 손실을 방지하기 위함입니다. 대신 관리자는 사용자 계정을 비활성화하여 사용자가 로그인하지 못하도록 할 수 있습니다. Controls 패널의 삭제 아이콘을 클릭합니다. 확인을 요청하는 팝오버가 나타나며, Deactivate 버튼을 클릭하여 사용자를 비활성화할 수 있습니다.
사용자를 다시 활성화하려면 Users - Inactive 탭으로 이동하여 대상 사용자의 상태를 Active로 선택합니다.
:::note 사용자를 비활성화하거나 다시 활성화해도 사용자의 자격 증명은 변경되지 않습니다. 사용자 계정에는 여러 keypair가 있을 수 있으므로 어떤 자격 증명을 다시 활성화해야 할지 결정하기 어렵기 때문입니다. :::
각 사용자 계정은 일반적으로 하나 이상의 keypair를 가지고 있습니다. Keypair는 사용자가 로그인한 후 Backend.AI 서버에 대한 API 인증에 사용됩니다. 로그인은 사용자 이메일과 비밀번호를 통한 인증이 필요하지만, 사용자가 서버에 보내는 모든 요청은 keypair를 기반으로 인증됩니다.
사용자는 여러 개의 keypair를 가질 수 있지만, keypair 관리에 대한 사용자의 부담을 줄이기 위해 현재는 사용자의 keypair 중 하나만 사용하여 요청을 보냅니다. 또한 새 사용자를 생성하면 keypair가 자동으로 생성되므로 대부분의 경우 수동으로 keypair를 생성하고 할당할 필요가 없습니다.
Keypair는 Users 페이지의 Credentials 탭에서 확인할 수 있습니다. 활성 keypair는 즉시 표시되며, 비활성 keypair를 보려면 하단의 Inactive 패널을 클릭합니다.
Users 탭과 마찬가지로 Controls 패널의 버튼을 사용하여 keypair 세부 정보를 보거나 업데이트할 수 있습니다. 초록색 정보 아이콘 버튼을 클릭하면 keypair의 구체적인 세부 정보를 확인할 수 있습니다. 필요한 경우 복사 버튼을 클릭하여 secret key를 복사할 수 있습니다.
파란색 '설정 (톱니바퀴)' 버튼을 클릭하여 keypair의 자원 정책과 rate limit을 수정할 수 있습니다. 'Rate Limit' 값이 작으면 로그인과 같은 API 작업이 차단될 수 있으므로 주의하시기 바랍니다.
control 열의 빨간색 'Deactivate' 버튼이나 검은색 'Activate' 버튼을 클릭하여 keypair를 비활성화하거나 다시 활성화할 수도 있습니다. User 탭과 달리 Inactive 탭에서는 keypair를 영구적으로 삭제할 수 있습니다. 그러나 현재 사용자의 주요 액세스 키로 사용 중인 keypair는 영구적으로 삭제할 수 없습니다.
실수로 keypair를 삭제한 경우, 오른쪽 상단의 '+ ADD CREDENTIAL' 버튼을 클릭하여 사용자를 위한 keypair를 다시 생성할 수 있습니다.
Rate Limit 필드는 15분 동안 Backend.AI 서버에 보낼 수 있는 최대 요청 수를 지정하는 곳입니다. 예를 들어 1000으로 설정하면 keypair가 15분 동안 1000개가 넘는 API 요청을 보낼 경우 서버에서 오류를 발생시키고 요청을 수락하지 않습니다. 기본값을 사용하고 사용자의 패턴에 따라 API 요청 빈도가 높아지면 값을 증가시키는 것이 좋습니다.
Backend.AI는 사용자 자신의 스토리지 폴더 외에도 프로젝트를 위한 스토리지 폴더를 제공합니다. 프로젝트 스토리지 폴더는 특정 사용자가 아닌 특정 프로젝트에 속하는 폴더로, 해당 프로젝트의 모든 사용자가 액세스할 수 있습니다.
:::note 프로젝트 폴더는 관리자만 생성할 수 있습니다. 일반 사용자는 관리자가 생성한 프로젝트 폴더의 내용에만 액세스할 수 있습니다. 시스템 설정에 따라 프로젝트 폴더가 허용되지 않을 수 있습니다. :::
먼저 관리자 계정으로 로그인하여 프로젝트 폴더를 생성합니다. Data 페이지로 이동한 후 'Create Folder'를 클릭하여 폴더 생성 대화 상자를 엽니다. 폴더 이름을 입력하고 Type을 Project로 설정합니다. Type을 Project로 설정하면 헤더의 프로젝트 선택기에서 선택한 프로젝트에 자동으로 할당됩니다. Permission은 Read-Only로 설정합니다.
폴더가 생성되었는지 확인한 후 User B의 계정으로 로그인하여 Data & Storage 페이지에 방금 생성한 프로젝트 폴더가 별도의 초대 절차 없이 표시되는지 확인합니다. Permission 패널에도 R (Read Only)이 표시되는 것을 확인할 수 있습니다.
모델 스토어의 모델 카드는 관리자 모델 스토어 관리 인터페이스를 통해 생성하고 관리합니다. 각 모델 카드는 실제 모델 파일이 저장된 스토리지 폴더(vfolder)와 연결됩니다.
:::note Hugging Face의 Gated 모델을 사용하는 경우, 다운로드 전에 해당 모델에 대한 접근 권한을 먼저 요청해야 합니다. 자세한 내용은 Gated models 를 참고하세요. :::
먼저 프로젝트를 model-store로 설정합니다.
데이터 페이지로 이동하여 폴더 생성 버튼을 클릭합니다. 폴더를 다음과 같이 설정합니다:
- 사용 방식: Model
- 유형: Project
- 권한: Read-Write
폴더 생성 후, 모델 파일을 폴더에 다운로드합니다. 세션 생성 시 모델 폴더를 마운트하고 huggingface-cli 등의 도구를 사용하여 모델 가중치를 다운로드할 수 있습니다.
:::note 모델 파일은 수동으로 폴더에 다운로드해야 합니다. Hugging Face에서 다운로드하는 방법은 Downloading models 를 참고하세요. :::
폴더와 모델 파일이 준비되면, 관리자 모델 스토어 관리 인터페이스에서 모델 카드를 생성하고 해당 폴더와 연결합니다.
Custom 런타임 변형을 사용하는 경우, 모델 폴더에 model-definition.yaml 파일을 선택적으로 추가할 수 있습니다. 이 파일은 서빙 시 inference 서버를 어떻게 시작하고 운영할지를 Backend.AI에 알려줍니다 — 시작 명령어, 헬스 체크 설정, 모델 가중치 다운로드 등의 사전 시작 작업을 포함합니다.
:::note
vLLM, SGLang, NVIDIA NIM, Modular MAX 등의 런타임 변형에서는 model-definition.yaml 파일이 필요하지 않습니다. 이러한 변형은 선택한 설정에 따라 모델 구성을 자동으로 처리합니다.
:::
다음은 Custom 변형으로 vLLM 서버를 시작하는 model-definition.yaml 예시입니다:
models:
- name: "Llama-3.1-8B-Instruct"
model_path: "/models/Llama-3.1-8B-Instruct"
service:
pre_start_actions:
- action: run_command
args:
command:
- huggingface-cli
- download
- --local-dir
- /models/Llama-3.1-8B-Instruct
- --token
- hf_****
- meta-llama/Llama-3.1-8B-Instruct
start_command:
- /usr/bin/python
- -m
- vllm.entrypoints.openai.api_server
- --model
- /models/Llama-3.1-8B-Instruct
- --served-model-name
- Llama-3.1-8B-Instruct
- --tensor-parallel-size
- "1"
- --host
- "0.0.0.0"
- --port
- "8000"
- --max-model-len
- "4096"
port: 8000
health_check:
path: /v1/models
max_retries: 500모델 정의 파일 형식에 대한 자세한 설명은 모델 서빙 문서의 모델 정의 가이드 를 참고하세요.
:::note
모델 스토어에서 모델 카드의 Deploy 버튼을 활성화하려면 연결된 폴더에 service-definition.toml이 포함되어 있어야 합니다. model-definition.yaml은 Custom 런타임 변형을 사용할 때만 추가로 필요하며, vLLM, SGLang, NVIDIA NIM, Modular MAX 같은 프리셋 런타임 변형에는 필요하지 않습니다. 서비스 정의 파일에 대한 자세한 내용은 모델 서빙 문서의 서비스 정의 파일 섹션을 참고하세요.
:::
관리자 및 슈퍼관리자는 모든 프로젝트의 엔드포인트를 볼 수 있는 관리자 서빙 페이지에 접근할 수 있습니다. 이 페이지는 표준 엔드포인트 목록 열에 추가로 프로젝트 열을 표시하여, 관리자가 모든 프로젝트의 서비스를 관리할 수 있게 합니다.
관리자 서빙 페이지에는 두 개의 탭이 있습니다:
- Serving: 모든 프로젝트의 엔드포인트 목록을 표시하며, 사용자용 서빙 페이지와 동일한 라이프사이클 및 속성 필터를 제공합니다.
- Model Store Management: 슈퍼관리자에게만 제공됩니다. 아래 섹션을 참조하세요.
슈퍼관리자는 관리자 서빙 페이지의 모델 스토어 관리(Model Store Management) 탭을 통해 모델 카드를 관리할 수 있습니다.
목록은 다음 컬럼을 제공합니다:
- 이름(Name): 모델 카드의 고유 식별자입니다.
- 제목(Title): 사람이 읽을 수 있는 표시 이름입니다.
- 카테고리(Category): 모델 카테고리입니다 (예: LLM).
- 태스크(Task): 추론 태스크 유형입니다 (예: text-generation).
- 접근 수준(Access Level): 모델 카드가 공개적으로 접근 가능한 경우 녹색
Public태그가 표시되고, 그렇지 않으면 기본Private태그가 표시됩니다. - 도메인(Domain): 모델 카드를 소유한 도메인입니다.
- 프로젝트(Project): 모델 카드를 소유한 프로젝트입니다.
- 생성 시간(Created At): 모델 카드가 생성된 시간입니다.
상단의 속성 필터 바를 사용하여 이름으로 목록을 필터링할 수 있습니다. 각 행의 이름 셀에는 편집 및 삭제 액션 아이콘이 직접 표시됩니다.
여러 모델 카드를 한 번에 삭제하려면 체크박스로 삭제할 행을 선택한 후 선택 개수 옆의 빨간색 휴지통 버튼을 클릭합니다. 카드가 삭제되기 전에 확인 대화 상자가 표시됩니다.
모델 카드 생성(Create Model Card) 버튼을 클릭하여 생성 모달을 엽니다. 다음 필드를 입력합니다:
-
이름(Name) (필수): 모델 카드의 고유 식별자입니다.
-
제목(Title): 사람이 읽을 수 있는 표시 이름입니다.
-
설명(Description): 모델에 대한 상세 설명입니다.
-
작가(Author): 모델 생성자 또는 조직입니다.
-
모델 버전(Model Version): 모델 버전입니다.
-
태스크(Task): 추론 태스크 유형입니다 (예: text-generation).
-
카테고리(Category): 모델 카테고리입니다 (예: LLM).
-
프레임워크(Framework): 사용된 ML 프레임워크입니다 (예: PyTorch, TensorFlow).
-
라벨(Label): 분류 및 필터링을 위한 태그입니다.
-
라이선스(License): 모델이 배포되는 라이선스입니다.
-
아키텍처(Architecture): 모델 아키텍처입니다 (예: Transformer).
-
README: 모델에 대한 마크다운 README입니다.
-
도메인(Domain): 모델 카드를 연결할 도메인입니다.
-
프로젝트 ID(Project ID) (필수): 모델 카드를 소유하는 프로젝트입니다.
-
VFolder (필수): 모델 파일이 포함된 스토리지 폴더입니다.
-
접근 수준(Access Level): 사용자용 모델 스토어에서 모델 카드를 누가 볼 수 있는지를 제어합니다.
Internal: 모델 카드를 소유한 도메인과 프로젝트의 관리자에게만 표시됩니다. 일반 사용자는 모델 스토어에서 Internal 모델 카드를 볼 수 없습니다.Public: 해당 프로젝트에 접근 권한이 있는 모든 사용자에게 표시됩니다.
모델 카드 이름 옆의 편집 아이콘을 클릭하여 기존 모델 카드를 수정합니다. 이전에 입력한 필드가 채워진 상태로 편집 모달이 열립니다.
모델 카드 이름 옆의 삭제 아이콘을 클릭하여 개별 모델 카드를 삭제하거나, 행 체크박스로 여러 모델 카드를 선택한 후 선택 개수 옆의 빨간색 휴지통 버튼을 클릭하여 일괄 삭제를 수행할 수 있습니다.
Backend.AI는 관리자가 재사용 가능한 프로메테우스 쿼리 프리셋을 정의할 수 있게 해주며, 오토 스케일링 규칙을 비롯한 모니터링 기능이 이를 이름으로 참조할 수 있습니다. 하나의 프리셋은 메트릭 이름, PromQL 쿼리 템플릿, 선택적인 시간 범위, 선택적인 필터 / 그룹 레이블을 함께 묶어 관리하므로, 운영자가 동일한 쿼리를 규칙마다 다시 입력할 필요가 없습니다.
이 프리셋은 관리자 배포 페이지의 프로메테우스 프리셋 탭(/admin-deployments?tab=prometheus-preset)에서 관리합니다.
:::note
이 탭은 관리자 전용이며, Backend.AI 매니저가 prometheus-query-preset 기능을 지원한다고 알릴 때에만 표시됩니다. 사용 중인 환경에서 탭이 보이지 않는다면, 매니저 빌드가 아직 해당 기능을 지원하지 않는 것입니다.
:::
프리셋 테이블에는 클러스터에 등록된 모든 프로메테우스 쿼리 프리셋이 표시됩니다. 각 행에는 다음 정보가 포함됩니다.
- 이름: 프리셋을 식별하기 위한 고유한 이름이며, 사람이 읽기 쉬운 형태입니다. 해당 셀에서는 수정 및 삭제 인라인 액션도 제공합니다.
- ID: 프리셋의 내부 식별자입니다.
- 메트릭 이름: 이 프리셋이 보고하는 메트릭으로, 오토 스케일링 규칙 등 소비자 측에서 표시 라벨로 사용합니다.
- 쿼리 템플릿: 실행될 PromQL 표현식입니다. 셀은 복사 가능하며, 값 위에 마우스를 올린 뒤 복사 아이콘을 클릭하면 전체 템플릿을 클립보드로 복사할 수 있습니다. 결과를 Prometheus UI에서 직접 확인하고 싶을 때 유용합니다.
- 시간 범위: 쿼리가 범위 벡터를 사용할 때 적용되는 기본 조회 구간(예:
5m)입니다. - 카테고리: 프리셋이 속하는 선택적 카테고리(이름과 카테고리 ID가 함께 표시됩니다).
- 옵션: 소비자가 프리셋 위에 추가로 적용할 수 있는 필터 레이블과 그룹 레이블입니다.
- 생성일 / 수정일: 서버에서 자동으로 관리되는 타임스탬프입니다.
테이블 상단의 속성 필터로 목록을 검색하고 좁힐 수 있으며, 컬럼 헤더를 클릭하여 정렬 순서를 변경할 수 있습니다.
테이블에는 필요 없는 컬럼을 숨기거나 표시 순서를 바꿀 수 있는 컬럼 설정 컨트롤이 포함되어 있습니다. 선택한 설정은 브라우저별로 세션이 바뀌어도 유지되므로, 다음에 이 탭을 다시 방문해도 원하는 레이아웃으로 열립니다. 컬럼 설정을 초기화하면 Backend.AI의 기본 레이아웃으로 돌아갑니다.
테이블 우측 상단의 프리셋 추가 버튼을 클릭하여 프리셋 생성 모달을 엽니다.
모달에는 다음 필드가 있습니다.
- 이름: 프리셋의 고유한 이름입니다. 모든 프로메테우스 쿼리 프리셋 중에서 고유해야 합니다.
- 설명: 선택기 등에 함께 표시되는 자유 형식의 설명입니다.
- 카테고리: 연관된 프리셋을 묶기 위한 선택적 카테고리입니다. 비워두면 카테고리 없음으로 표시됩니다.
- 메트릭 이름: 소비자(예: 오토 스케일링 규칙)에서 표시되는 메트릭 라벨입니다.
- 쿼리 템플릿: 실행할 PromQL 표현식입니다. 입력하는 동안 필드 아래의 라이브 프리뷰 영역이 서버의
adminPrometheusQueryPresetPreview쿼리를 호출하여, 작성 중인 템플릿이 실제 Prometheus 인스턴스에서 어떤 값을 반환하는지 즉시 보여줍니다. 따라서 저장하기 전에 템플릿이 의도대로 동작하는지 확인할 수 있습니다. 프리뷰는 디바운스 처리되어 입력에 맞춰 자동으로 갱신됩니다. - 시간 범위: 범위 벡터에 사용할 기본 조회 구간(예:
5m)입니다. 범위 벡터를 사용하지 않으면 비워둡니다. - 필터 레이블: 소비자가 프리셋 위에 추가로 적용할 수 있는 선택적 레이블 셀렉터 목록입니다.
- 그룹 레이블: 쿼리 결과를 그룹화할 선택적 레이블 목록입니다.
생성을 클릭하여 프리셋을 저장합니다. 성공하면 프리셋이 목록에 나타나고 확인 토스트가 표시됩니다.
프리셋 행의 이름 셀에서 수정 액션을 클릭하면 프리셋 수정 모달이 열립니다. 모달에는 프리셋의 현재 값이 미리 채워져 있으며, 쿼리 템플릿의 라이브 프리뷰 영역을 포함하여 생성 다이얼로그와 동일한 필드가 제공됩니다.
저장을 클릭하여 변경 사항을 적용합니다. 해당 프리셋을 참조하는 소비자(예: 오토 스케일링 규칙)는 다음 메트릭 평가 시 자동으로 새 쿼리 템플릿을 적용합니다.
프리셋 행의 이름 셀에서 삭제 액션을 클릭하면 삭제 확인 모달이 열립니다.
:::danger 프로메테우스 쿼리 프리셋의 삭제는 영구적이며 되돌릴 수 없습니다. 삭제된 프리셋을 참조하는 오토 스케일링 규칙 등은 쿼리 템플릿을 잃게 되며, 다른 프리셋을 가리키도록 재구성하기 전까지 정상적으로 동작하지 않을 수 있습니다. :::
삭제는 되돌릴 수 없기 때문에, 다이얼로그는 삭제 버튼이 활성화되기 전에 확인 입력란에 프리셋 이름을 직접 입력하도록 요구합니다. 이 입력 확인 패턴(BAIConfirmModalWithInput)은 Backend.AI 전반에서 영구 삭제 작업에 일관되게 사용됩니다. 다이얼로그 제목에 표시된 프리셋 이름을 정확히 입력한 뒤 삭제를 클릭하여 확정합니다.
Backend.AI에서 관리자는 각 keypair, 사용자, 프로젝트에 사용 가능한 총 자원에 대한 제한을 설정할 수 있습니다. 자원 정책을 통해 허용되는 최대 자원과 기타 연산 세션 관련 설정을 정의할 수 있습니다. 또한 사용자 또는 연구 요구 사항과 같은 다양한 필요에 맞는 여러 자원 정책을 생성하고 개별적으로 적용할 수 있습니다.
Resource Policies 페이지에서 관리자는 등록된 모든 자원 정책의 목록을 볼 수 있습니다. 관리자는 이 페이지에서 keypair, 사용자, 프로젝트에 대해 설정된 자원 정책을 직접 검토할 수 있습니다. keypair에 대한 자원 정책을 먼저 살펴보겠습니다. 아래 그림에는 총 세 가지 정책(gardener, student, default)이 있습니다. 무한대 기호(∞)는 해당 자원에 자원 제한이 적용되지 않았음을 나타냅니다.
이 가이드에서 사용되는 사용자 계정은 현재 default 자원 정책에 할당되어 있습니다. 이는 Users 페이지의 Credentials 탭에서 확인할 수 있습니다. Resource Policies 패널에서 모든 자원 정책이 default로 설정되어 있음을 확인할 수도 있습니다.
자원 정책을 수정하려면 default 정책 그룹의 Control 열에서 '설정 (톱니바퀴)'를 클릭합니다. Update Resource Policy 대화 상자에서 목록의 자원 정책을 구분하는 기본 키 역할을 하는 Policy Name을 제외한 모든 옵션을 편집할 수 있습니다. CPU, RAM, fGPU 하단의 Unlimited 체크박스를 해제하고 자원 제한을 원하는 값으로 설정합니다. 할당된 자원이 전체 하드웨어 용량보다 적은지 확인하세요. 이 경우 CPU, RAM, fGPU를 각각 2, 4, 1로 설정합니다. OK 버튼을 클릭하여 업데이트된 자원 정책을 적용합니다.
자원 정책 대화 상자의 각 옵션에 대한 세부 정보는 아래 설명을 참조하세요.
-
Resource Policy
- CPU: 최대 CPU 코어 수를 지정합니다. (최대값: 512)
- Memory: 최대 메모리 양을 GB 단위로 지정합니다. 메모리를 GPU 메모리의 최대값보다 두 배 크게 설정하는 것이 좋습니다. (최대값: 1024)
- CUDA-capable GPU: 최대 물리적 GPU 수를 지정합니다. 서버에서 fractional GPU가 활성화된 경우 이 설정은 효과가 없습니다. (최대값: 64)
- CUDA-capable GPU (fractional): Fractional GPU (fGPU)는 GPU를 효율적으로 사용하기 위해 단일 GPU를 여러 파티션으로 분할하는 기능입니다. 필요한 최소 fGPU 양은 각 이미지에 따라 다릅니다. 서버에서 fractional GPU가 활성화되지 않은 경우 이 설정은 효과가 없습니다. (최대값: 256)
-
Sessions
- Cluster Size: 세션을 생성할 때 구성할 수 있는 멀티 컨테이너 또는 멀티 노드 수의 최대 제한을 설정합니다.
- Session Lifetime (sec.):
PENDING및RUNNING상태를 포함하여 활성 상태에서 예약된 연산 세션의 최대 수명을 제한합니다. 이 시간이 지나면 세션이 완전히 활용되고 있더라도 강제 종료됩니다. 이는 세션이 무기한으로 실행되는 것을 방지하는 데 유용합니다. - Max Pending Session Count: 동시에
PENDING상태에 있을 수 있는 최대 연산 세션 수입니다. - Concurrent Jobs: keypair당 최대 동시 연산 세션 수입니다. 예를 들어 이 값이 3으로 설정된 경우, 이 자원 정책에 바인딩된 사용자는 동시에 3개 이상의 연산 세션을 생성할 수 없습니다. (최대값: 100)
- Idle timeout (sec.): 사용자가 세션을 그대로 둘 수 있는 구성 가능한 기간입니다. idle timeout 동안 연산 세션에 아무런 활동이 없으면 세션이 자동으로 가비지 수집되고 삭제됩니다. "유휴"의 기준은 다양할 수 있으며 관리자가 설정합니다. (최대값: 15552000 (약 180일))
- Max Concurrent SFTP Sessions: 최대 동시 SFTP 세션 수입니다.
-
Folders
- Allowed hosts: Backend.AI는 많은 NFS 마운트 포인트를 지원합니다. 이 필드는 이들에 대한 접근성을 제한합니다. "data-1"이라는 NFS가 Backend.AI에 마운트되어 있더라도 자원 정책에서 허용하지 않으면 사용자가 액세스할 수 없습니다.
- (23.09.4 이후 더 이상 사용되지 않음) Max. #: 생성/초대할 수 있는 스토리지 폴더의 최대 수입니다. (최대값: 100).
keypair 자원 정책 목록에서 default 정책의 Resources 값이 업데이트되었는지 확인합니다.
'+ Create' 버튼을 클릭하여 새 자원 정책을 생성할 수 있습니다. 각 설정 값은 위에서 설명한 것과 동일합니다.
자원 정책을 생성하고 keypair와 연결하려면 Users 페이지의 Credentials 탭으로 이동하여 원하는 keypair의 Controls 열에 있는 톱니바퀴 버튼을 클릭하고 Select Policy 필드를 클릭하여 선택합니다.
Control 열의 휴지통 아이콘을 클릭하여 각 자원 keypair를 삭제할 수도 있습니다. 아이콘을 클릭하면 확인 팝업이 나타납니다. 'Delete' 버튼을 클릭하여 삭제합니다.
:::note 삭제할 자원 정책을 따르는 사용자(비활성 사용자 포함)가 있으면 삭제할 수 없습니다. 자원 정책을 삭제하기 전에 해당 자원 정책 아래에 남아있는 사용자가 없는지 확인하십시오. :::
특정 열을 숨기거나 표시하려면 테이블 오른쪽 하단의 '설정 (톱니바퀴)'를 클릭합니다. 표시하려는 열을 선택할 수 있는 대화 상자가 나타납니다.
버전 24.03부터 Backend.AI는 사용자 자원 정책 관리를 지원합니다. 각 사용자는 여러 keypair를 가질 수 있지만, 사용자는 하나의 사용자 자원 정책만 가질 수 있습니다. 사용자 자원 정책 페이지에서는 Max Folder Count 및 Max Folder Size와 같은 폴더 관련 다양한 설정에 대한 제한뿐만 아니라 Max Session Count Per Model Session 및 Max Customized Image Count와 같은 개별 자원 제한도 설정할 수 있습니다.
새 사용자 자원 정책을 생성하려면 Create 버튼을 클릭합니다.
- Name: 사용자 자원 정책의 이름입니다.
- Max Folder Count: 사용자가 생성할 수 있는 최대 폴더 수입니다. 사용자의 폴더 수가 이 값을 초과하면 새 폴더를 생성할 수 없습니다. Unlimited로 설정하면 "∞"로 표시됩니다.
- Max Folder Size: 사용자의 스토리지 공간의 최대 크기입니다. 사용자의 스토리지 공간이 이 값을 초과하면 새 데이터 폴더를 생성할 수 없습니다. Unlimited로 설정하면 "∞"로 표시됩니다.
- Max Session Count Per Model Session: 사용자가 생성한 모델 서비스당 사용 가능한 최대 세션 수입니다. 이 값을 증가시키면 세션 스케줄러에 과부하가 걸리고 잠재적으로 시스템 다운타임으로 이어질 수 있으므로 이 설정을 조정할 때 주의하시기 바랍니다.
- Max Customized Image Count: 사용자가 생성할 수 있는 최대 커스터마이징된 이미지 수입니다. 사용자의 커스터마이징된 이미지 수가 이 값을 초과하면 새 커스터마이징된 이미지를 생성할 수 없습니다. 커스터마이징된 이미지에 대해 자세히 알아보려면 My Environments 섹션을 참고하세요.
업데이트하려면 control 열의 '설정 (톱니바퀴)' 버튼을 클릭합니다. 삭제하려면 휴지통 버튼을 클릭합니다.
:::note 자원 정책을 변경하면 해당 정책을 사용하는 모든 사용자에게 영향을 미칠 수 있으므로 주의하여 사용하십시오. :::
keypair 자원 정책과 마찬가지로 테이블 오른쪽 하단의 '설정 (톱니바퀴)' 버튼을 클릭하여 원하는 열만 선택하고 표시할 수 있습니다.
버전 24.03부터 Backend.AI는 프로젝트 자원 정책 관리를 지원합니다. 프로젝트 자원 정책은 프로젝트의 스토리지 공간(쿼터) 및 폴더 관련 제한을 관리합니다.
'자원 정책' 페이지의 '프로젝트' 탭을 클릭하면 프로젝트 자원 정책 목록을 볼 수 있습니다.
새 프로젝트 자원 정책을 생성하려면 테이블 오른쪽 상단의 '+ 생성' 버튼을 클릭합니다.
- 이름: 프로젝트 자원 정책의 이름입니다.
- 최대 폴더 수: 관리자가 생성할 수 있는 최대 프로젝트 폴더 수입니다. 프로젝트 폴더 수가 이 값을 초과하면 관리자는 새 프로젝트 폴더를 생성할 수 없습니다. Unlimited로 설정하면 "∞"로 표시됩니다.
- 최대 폴더 크기: 프로젝트의 스토리지 공간의 최대 크기입니다. 프로젝트의 스토리지 공간이 이 값을 초과하면 관리자는 새 프로젝트 폴더를 생성할 수 없습니다. Unlimited로 설정하면 "∞"로 표시됩니다.
- 최대 네트워크 수: Backend.AI 버전 24.12부터 프로젝트에 생성할 수 있는 최대 네트워크 수입니다. Unlimited로 설정하면 "∞"로 표시됩니다.
각 필드의 의미는 사용자 자원 정책과 유사합니다. 차이점은 프로젝트 자원 정책은 프로젝트 폴더에 적용되고 사용자 자원 정책은 사용자 폴더에 적용된다는 점입니다.
변경하려면 '제어' 열의 '설정' 버튼을 클릭합니다. 자원 정책 이름은 편집할 수 없습니다. 삭제는 휴지통 아이콘 버튼을 클릭하여 수행할 수 있습니다.
:::note 자원 정책을 변경하면 해당 정책을 사용하는 모든 사용자에게 영향을 미칠 수 있으므로 주의하여 사용하십시오. :::
테이블 오른쪽 하단의 '설정' 버튼을 클릭하여 원하는 열만 선택하고 표시할 수 있습니다.
현재 자원 정책을 파일로 저장하려면 각 탭 오른쪽 상단의 '더보기' 버튼을 클릭한 후 'CSV로 내보내기' 메뉴를 선택합니다.
Backend.AI 버전 25.13.0부터 관리자 메뉴에서 대기 중인 세션을 통합적으로 확인할 수 있습니다. Admin Session 페이지에서는 선택한 자원 그룹 내의 모든 대기 중인 세션을 한눈에 확인할 수 있습니다. 상태 옆에 표시되는 인덱스 번호는 충분한 자원이 확보되면 세션이 생성될 대기열 위치를 나타냅니다.
Session 페이지와 마찬가지로 세션 이름을 클릭하면 세션에 대한 자세한 정보를 표시하는 drawer가 열립니다.
Backend.AI 코어 버전 26.2.0 이상에서 Fair Share 스케줄러 페이지를 Administration 메뉴에서 사용할 수 있습니다. 이 기능을 통해 관리자는 자원 그룹, 도메인, 프로젝트, 사용자의 계층 구조에 따라 Fair Share 스케줄링 가중치를 관리할 수 있습니다.
Fair Share 스케줄링은 과거 사용 이력을 기반으로 컴퓨팅 자원을 배분하여 사용자 간에 자원이 공정하게 분배되도록 합니다. 과거에 자원을 적게 사용한 사용자는 높은 스케줄링 우선순위를 받고, 많이 사용한 사용자는 낮은 우선순위를 받습니다. 관리자는 계층 구조의 각 단계에서 가중치를 조정하여 이 동작을 세밀하게 제어할 수 있습니다.
:::note
Fair Share 스케줄러는 자원 그룹의 스케줄러 타입이 FAIR_SHARE로 설정된 경우에만
사용할 수 있습니다. 자원 그룹의 스케줄러 타입을 설정하려면
자원 그룹 관리 섹션을 참고하세요.
:::
이 기능에 접근하려면 사이드바의 Administration 섹션에서 Scheduler 메뉴 항목을 클릭합니다. 페이지에는 Fair Share 설정 탭과 4단계 드릴다운 인터페이스가 표시됩니다.
페이지는 다음과 같은 4개의 계층적 단계로 구성됩니다:
- 자원 그룹: 각 자원 그룹의 핵심 Fair Share 파라미터를 설정합니다.
- 도메인: 자원 그룹 내 도메인별 가중치를 설정합니다.
- 프로젝트: 도메인 내 프로젝트별 가중치를 설정합니다.
- 사용자: 프로젝트 내 개별 사용자의 가중치를 설정합니다.
페이지 상단의 단계 표시줄은 현재 계층 구조에서의 위치를 보여줍니다. 완료된 단계에는 선택한 항목의 이름이 표시됩니다. 완료된 단계를 클릭하면 해당 레벨로 돌아갈 수 있습니다.
선택한 자원 그룹의 스케줄러 타입이 FAIR_SHARE로 설정되어 있지 않은 경우,
해당 자원 그룹에 Fair Share 스케줄러가 적용되어 있지 않다는 경고 알림이 표시됩니다.
각 단계에서 다음과 같은 공통 기능을 사용할 수 있습니다:
- 필터링: 속성 기반 검색 필터를 사용하여 이름으로 결과를 좁힐 수 있습니다. 사용자 단계에서는 이메일 및 활성 상태에 대한 추가 필터를 사용할 수 있습니다.
- 정렬: 컬럼 헤더를 클릭하여 해당 컬럼 기준으로 테이블을 정렬할 수 있습니다.
- 페이지네이션: 페이지 크기를 설정하여 결과를 탐색할 수 있습니다.
- 자동 새로고침: 데이터는 7초마다 자동으로 갱신됩니다. 수동 새로고침 버튼도 사용할 수 있습니다.
자원 그룹 단계에서는 모든 자원 그룹과 Fair Share 설정 정보가 테이블로 표시됩니다.
테이블에는 다음과 같은 컬럼이 포함됩니다:
- 이름: 자원 그룹의 이름입니다. 이름을 클릭하면 해당 자원 그룹의 도메인 레벨 설정으로 이동합니다.
- 제어: 자원 그룹 Fair Share 설정 모달을 여는 설정(톱니바퀴) 버튼입니다.
- 할당 정보: 자원 그룹에 할당된 각 자원 타입별 사용량/용량을 보여줍니다 (예: CPU, Memory, CUDA GPU).
- 자원별 가중치: 자원 타입별 가중치입니다. 기본 가중치를 사용하는 경우 "기본값"으로 표시됩니다.
- 가중치 기본값: 가중치가 지정되지 않은 도메인, 프로젝트, 사용자에 적용되는 기본 가중치 값입니다.
- 집계 단위: 사용량을 집계하는 기간(일 단위)입니다.
- 반감기: 과거 사용량의 반영 비율이 절반으로 줄어드는 기간(일 단위)입니다.
- 집계 기간: Fair Share 계산에 반영되는 사용량 기록의 조회 범위(일 단위)입니다.
자원 그룹의 제어 컬럼에 있는 설정(톱니바퀴) 버튼을 클릭하면 Fair Share 설정 모달이 열립니다.
:::warning 변경사항은 Fair Share 계산에 바로 반영되지 않으며, 계산 주기에 따라 약 5분 정도 소요될 수 있습니다. :::
모달에는 다음과 같은 필드가 포함됩니다:
- 자원 그룹: 자원 그룹 이름을 보여주는 읽기 전용 필드입니다.
- 반감기: 과거 사용량의 반영 비율이 절반으로 줄어드는 기간으로, 일 단위로 지정합니다 (최소 1). 예를 들어 7일로 설정하면 7일 전 사용량은 50%, 14일 전 사용량은 25%의 비율로 계산됩니다. 집계 단위의 배수로 설정하는 것을 권장합니다.
- 집계 기간: Fair Share 계산에 반영되는 사용량 기록의 조회 범위로, 일 단위로 지정합니다 (최소 1). 이 기간 이전의 사용량은 계산에서 제외됩니다. 반감기의 배수로 설정하는 것을 권장합니다.
- 가중치 기본값: 가중치가 지정되지 않은 도메인, 프로젝트, 사용자에 적용되는 기본값입니다 (최소 1, 단계 0.1).
- 자원별 가중치: 자원 타입별 가중치(예: CPU, Memory, GPU)이며 각각 최소 1, 단계 0.1입니다. 이 섹션은 자원 그룹에 자원별 가중치가 존재하는 경우에만 표시됩니다.
자원 그룹을 선택하면 도메인 단계에서 해당 자원 그룹 내 도메인의 Fair Share 가중치와 사용량을 테이블로 확인할 수 있습니다.
테이블에는 다음과 같은 컬럼이 포함됩니다:
- 이름: 도메인 이름입니다. 이름을 클릭하면 해당 도메인의 프로젝트 레벨 설정으로 이동합니다.
- 제어: 가중치 설정 모달을 여는 설정(톱니바퀴) 버튼입니다.
- 가중치: 현재 가중치 값입니다. 기본 가중치를 사용하는 경우 "기본값"으로 표시됩니다.
- 우선 순위 계수: Fair Share 스케줄러에 의해 계산된 스케줄링 우선순위입니다. 값이 높을수록 높은 우선순위를 갖습니다.
- 자원 할당: 자원 타입별 일 평균 감쇠 자원 사용량입니다 (CPU, Memory, GPU / Day).
- 수정일: 마지막 수정 시각입니다.
- 생성일: 생성 시각입니다.
테이블 왼쪽의 체크박스를 사용하여 여러 행을 선택할 수 있습니다. 행이 선택되면 두 개의 추가 버튼이 나타납니다:
- 사용량 그래프 (차트 아이콘): 선택한 항목의 사용량 기록 모달을 엽니다.
- 일괄 편집 (톱니바퀴 아이콘): 선택한 항목의 가중치를 한 번에 편집하는 모달을 엽니다.
도메인을 선택하면 프로젝트 단계에서 도메인 단계와 동일한 컬럼 구조의 프로젝트 테이블이 표시됩니다. 프로젝트 이름을 클릭하면 사용자 단계로 이동합니다.
행을 선택하면 동일한 일괄 작업(사용량 그래프 및 일괄 편집)을 사용할 수 있습니다.
프로젝트를 선택하면 사용자 단계에서 개별 사용자의 Fair Share 가중치와 사용량을 테이블로 확인할 수 있습니다.
테이블에는 다음과 같은 컬럼이 포함됩니다:
- 이메일: 사용자의 이메일 주소입니다.
- 이름: 사용자의 이름입니다.
- 제어: 가중치 설정 모달을 여는 설정(톱니바퀴) 버튼입니다.
- 가중치: 현재 가중치 값입니다. 기본 가중치를 사용하는 경우 "기본값"으로 표시됩니다.
- 우선 순위 계수: Fair Share 스케줄러에 의해 계산된 스케줄링 우선순위입니다.
- 자원 할당: 자원 타입별 일 평균 감쇠 자원 사용량입니다.
- 수정일: 마지막 수정 시각입니다.
- 생성일: 생성 시각입니다.
:::note 사용자 단계에서는 이메일, 이름, 활성 상태에 대한 추가 필터를 사용할 수 있습니다. :::
행을 선택하면 동일한 일괄 작업(사용량 그래프 및 일괄 편집)을 사용할 수 있습니다.
도메인, 프로젝트 또는 사용자의 Fair Share 가중치를 편집하려면 해당 행의 제어 컬럼에 있는 설정(톱니바퀴) 버튼을 클릭합니다. 가중치 설정 모달이 열립니다.
:::warning 변경사항은 Fair Share 계산에 바로 반영되지 않으며, 계산 주기에 따라 약 5분 정도 소요될 수 있습니다. :::
단일 편집 모드에서는 모달에 항목 이름(읽기 전용)과 가중치 입력 필드가 표시됩니다.
- 가중치: Fair Share 스케줄링 우선순위를 결정하는 배율입니다. 가중치가 높을수록 높은 우선순위를 받습니다. 기본값은 "1.0"이며, 가중치 "2.0"은 "1.0"보다 2배 높은 우선순위를 가집니다. 최소값은 1이고 단계는 0.1입니다.
여러 항목의 가중치를 한 번에 편집하려면 테이블의 체크박스로 원하는 행을 선택한 후 일괄 편집(톱니바퀴 아이콘) 버튼을 클릭합니다. 일괄 편집 모드에서는 모달에 선택한 모든 항목의 태그 목록과 모든 항목에 적용될 단일 가중치 입력 필드가 표시됩니다.
:::note
선택한 자원 그룹의 스케줄러 타입이 FAIR_SHARE로 설정되어 있지 않은 경우,
모달에 경고 알림이 표시됩니다.
:::
도메인, 프로젝트 또는 사용자의 사용량 기록을 확인하려면 테이블의 체크박스로 원하는 행을 선택한 후 사용량 그래프(차트 아이콘) 버튼을 클릭합니다. 사용량 기록 모달이 열립니다.
모달에는 다음 내용이 표시됩니다:
- 기간 선택: 사용량 기록의 날짜 범위를 선택합니다. 최근 7일, 최근 30일, 최근 90일의 프리셋을 사용할 수 있습니다.
- 새로고침 버튼: 사용량 데이터를 수동으로 갱신합니다.
- 컨텍스트 정보: 현재 단계에 따라 자원 그룹, 도메인, 프로젝트 정보를 표시합니다.
- 선택된 항목: 선택한 항목의 이름이 태그로 표시됩니다.
- 사용량 차트: 선택한 기간 동안의 일 평균 자원 사용량을 보여주는 차트입니다.
관리자는 Environments 페이지의 Images 탭에서 연산 세션 생성에 사용되는 이미지를
관리할 수 있습니다. 이 탭에서는 현재 Backend.AI 서버에 있는 모든 이미지의
메타 정보가 표시됩니다. 레지스트리, 아키텍처, 네임스페이스, 이미지 이름,
다이제스트, 각 이미지에 필요한 최소 자원 등의 정보를 확인할 수 있습니다. 하나
이상의 에이전트 노드에 다운로드된 이미지의 경우 Status 컬럼에 installed 태그가
표시됩니다.
:::note 특정 에이전트를 선택하여 이미지를 설치하는 기능은 현재 개발 중입니다. :::
이미지 목록에는 더 자세한 이미지 정보를 위한 추가 컬럼이 표시됩니다.
- 아키텍처: 이미지의 CPU 아키텍처입니다 (예: x86_64, aarch64).
- 네임스페이스: 레지스트리 내 이미지의 네임스페이스입니다.
- 기본 이미지 이름: 이미지의 기본 이름으로, 쉽게 식별할 수 있도록 별칭 태그가 함께 표시됩니다.
- 버전: 이미지의 버전 태그입니다.
- 태그: 이미지와 관련된 상세 태그로, 별칭이 포함된 이중 태그로 표시됩니다.
설치되지 않은 이미지를 여러 개 선택한 후 설치 버튼을 클릭하면 사용 가능한 에이전트 노드에 일괄 설치할 수 있습니다.
Controls 패널의 '설정 (톱니바퀴)'를 클릭하여 각 이미지의 최소 자원 요구 사항을 변경할 수 있습니다. 각 이미지에는 최소 작동을 위한 하드웨어 및 자원 요구 사항이 있습니다. (예를 들어 GPU 전용 이미지의 경우 최소 할당 GPU가 있어야 합니다.) 최소 자원 양의 기본값은 이미지의 메타데이터에 포함되어 제공됩니다. 각 이미지에 지정된 자원 양보다 적은 자원으로 연산 세션을 생성하려고 하면 요청이 취소되지 않고 이미지의 최소 자원 요구 사항으로 자동 조정된 후 생성됩니다.
:::note 최소 자원 요구 사항을 사전 정의된 값보다 작은 양으로 변경하지 마십시오! 이미지 메타데이터에 포함된 최소 자원 요구 사항은 테스트를 거쳐 결정된 값입니다. 변경하려는 최소 자원 양에 대해 확실하지 않다면 기본값으로 유지하십시오. :::
또한 Controls 열의 'Apps' 아이콘을 클릭하여 각 이미지에 지원되는 앱을 추가하거나 수정할 수 있습니다. 아이콘을 클릭하면 앱 이름과 해당 포트 번호가 표시됩니다.
이 인터페이스에서 아래의 '+ Add' 버튼을 클릭하여 지원되는 커스텀 애플리케이션을 추가할 수 있습니다. 애플리케이션을 삭제하려면 각 행의 오른쪽에 있는 '빨간색 휴지통' 버튼을 클릭하기만 하면 됩니다.
:::note 관리되는 앱을 변경한 후에는 이미지를 다시 설치해야 합니다.
Environments 페이지의 Registries 탭을 클릭하면 현재 연결된 Docker 레지스트리의 정보를 확인할 수 있습니다. cr.backend.ai가 기본으로 등록되어 있으며, Harbor에서 제공하는 레지스트리입니다.
:::note 오프라인 환경에서는 기본 레지스트리에 접근할 수 없으므로 오른쪽의 휴지통 아이콘을 클릭하여 삭제합니다. :::
Controls의 새로고침 아이콘을 클릭하면 연결된 레지스트리에서 Backend.AI용 이미지 메타데이터를 업데이트합니다. 레지스트리에 저장된 이미지 중 Backend.AI용 레이블이 없는 이미지 정보는 업데이트되지 않습니다.
'+ Add Registry' 버튼을 클릭하여 자신만의 프라이빗 Docker 레지스트리를 추가할 수 있습니다. 레지스트리 생성 대화 상자에는 다음과 같은 필드가 포함되어 있습니다:
- 레지스트리 이름: 레지스트리의 고유 이름입니다 (최대 50자). 레지스트리에 저장된 이미지 이름의 접두사와 일치해야 합니다.
- 레지스트리 주소: 레지스트리의 URL입니다.
http://또는https://와 같은 스킴이 명시적으로 포함되어야 합니다. - 사용자 이름: 선택 사항. 레지스트리에 별도의 인증 설정이 있는 경우 입력합니다.
- 비밀번호: 선택 사항. 기존 레지스트리를 편집할 때
Change Password체크박스를 선택하여 변경할 수 있습니다. - 레지스트리 유형: 레지스트리 유형을 선택합니다. 지원되는 유형:
docker,harbor,harbor2,github,gitlab,ecr,ecr-public. - 프로젝트 이름: 레지스트리의 프로젝트 또는 네임스페이스입니다 (필수). GitLab 레지스트리의 경우 네임스페이스와 프로젝트 이름을 포함한 전체 경로를 사용합니다.
- 추가 정보: 각 레지스트리 유형에 필요한 추가 설정을 위한 JSON 문자열입니다. 이 필드는 버전 24.09.3부터 사용 가능합니다.
GitLab 컨테이너 레지스트리를 추가할 때는 Extra Information 필드에 api_endpoint를 지정해야 합니다. 이는 GitLab이 컨테이너 레지스트리와 GitLab API에 별도의 엔드포인트를 사용하기 때문입니다.
**GitLab.com (공개 인스턴스)**의 경우:
- Registry URL:
https://registry.gitlab.com - Extra Information:
{"api_endpoint": "https://gitlab.com"}
자체 호스팅 (온프레미스) GitLab의 경우:
- Registry URL: GitLab 레지스트리 URL (예:
https://registry.example.com) - Extra Information:
{"api_endpoint": "https://gitlab.example.com"}
:::note
api_endpoint는 레지스트리 URL이 아닌 GitLab 인스턴스 URL을 가리켜야 합니다.
:::
추가 구성 참고 사항:
-
프로젝트 경로 형식: 프로젝트를 지정할 때 네임스페이스와 프로젝트 이름을 포함한 전체 경로를 사용합니다 (예:
namespace/project-name). 레지스트리가 올바르게 작동하려면 두 구성 요소가 모두 필요합니다. -
액세스 토큰 권한: 레지스트리에 사용되는 액세스 토큰에는
read_registry와read_api스코프가 모두 있어야 합니다.read_api스코프는 Backend.AI가 재스캔 작업 시 이미지 메타데이터를 위해 GitLab API를 쿼리하는 데 필요합니다.
기존 레지스트리의 정보를 업데이트할 수도 있습니다. 단, 레지스트리 이름은 변경할 수 없습니다.
레지스트리를 생성하고 이미지 메타데이터를 업데이트한 후에도 사용자가 이미지를 바로 사용할 수 있는 것은 아닙니다. 레지스트리 목록에서 Enabled 스위치를 토글하여 레지스트리를 활성화해야 사용자가 해당 레지스트리의 이미지에 접근할 수 있습니다.
다음에 나열된 사전 정의된 자원 프리셋은 연산 세션을 생성할 때 Resource allocation 패널에 표시됩니다. 슈퍼관리자는 이러한 자원 프리셋을 관리할 수 있습니다.
Environment 페이지의 Resource Presets 탭으로 이동합니다. 현재 정의된 자원 프리셋의 목록을 확인할 수 있습니다.
Controls 패널의 '설정 (톱니바퀴)'를 클릭하여 자원 프리셋에서 제공하는 CPU, RAM, fGPU 등의 자원을 설정할 수 있습니다. Create or Modify Resource Preset 모달에는 현재 사용 가능한 자원의 필드가 표시됩니다. 서버 설정에 따라 특정 자원이 표시되지 않을 수 있습니다. 원하는 값으로 자원을 설정한 후 저장하고, 연산 세션을 생성할 때 해당 프리셋이 표시되는지 확인합니다. 사용 가능한 자원이 프리셋에 정의된 자원 양보다 적으면 해당 프리셋이 표시되지 않습니다.
자원 프리셋 대화 상자에는 다음 항목이 포함됩니다:
- 자원 프리셋 이름: 프리셋의 고유 이름입니다 (영숫자, 마침표, 하이픈, 밑줄만 허용됩니다).
- 자원 그룹: (조건부) 프리셋을 특정 자원 그룹에 연결합니다.
- 자원 프리셋: 사용 가능한 각 자원 유형(CPU, 메모리, GPU 등)에 대한 동적 필드 묶음입니다. 메모리 필드는 동적 단위 입력(MiB, GiB, TiB, PiB)을 지원합니다.
- 공유 메모리: 프리셋에 할당된 공유 메모리 양입니다. 이 값은 메모리 값보다 작아야 합니다.
또한 Resource Presets 탭 오른쪽 상단의 '+ Create Presets' 버튼을 클릭하여 자원 프리셋을 생성할 수 있습니다. 이미 존재하는 것과 동일한 자원 프리셋 이름으로는 생성할 수 없습니다. 이름은 각 자원 프리셋을 구분하는 키 값이기 때문입니다.
슈퍼관리자는 Resources 페이지를 방문하여 현재 Backend.AI에 연결된 에이전트 워커 노드의 목록을 볼 수 있습니다. 에이전트 노드의 IP, 연결 시간, 현재 실제 사용 중인 자원 등을 확인할 수 있습니다. WebUI에서는 에이전트 노드를 직접 조작하는 기능을 제공하지 않습니다.
또한 Control 패널의 노트 아이콘을 클릭하여 에이전트 워커 노드의 자원에 대한 정확한 사용량을 확인할 수 있습니다.
Terminated 탭에서는 한번 연결되었다가 종료되거나 연결이 끊긴 에이전트의 정보를 확인할 수 있습니다. 이는 노드 관리를 위한 참고 자료로 사용할 수 있습니다. 목록이 비어 있다면 연결 끊김이나 종료가 발생하지 않았음을 의미합니다.
에이전트 서비스를 중지하지 않고 새로운 연산 세션이 해당 에이전트에 스케줄되는 것을 방지하고 싶을 수 있습니다. 이 경우 에이전트의 Schedulable 상태를 비활성화할 수 있습니다. 그러면 에이전트에 기존 세션을 보존하면서 새 세션의 생성을 차단할 수 있습니다.
에이전트는 자원 그룹(scaling group)이라는 단위로 그룹화할 수 있습니다. 예를 들어 V100 GPU가 장착된 에이전트 3대와 P100 GPU가 장착된 에이전트 2대가 있다고 가정합니다. 두 종류의 GPU를 사용자에게 별도로 노출하려면 V100 에이전트 3대를 하나의 자원 그룹으로, 나머지 P100 에이전트 2대를 다른 자원 그룹으로 그룹화할 수 있습니다.
특정 에이전트를 특정 자원 그룹에 추가하는 것은 현재 WebUI에서 처리되지 않으며, 설치 위치에서 에이전트 config 파일을 편집하고 에이전트 데몬을 재시작하여 수행할 수 있습니다. 자원 그룹의 관리는 Resource 페이지의 Resource Group 탭에서 가능합니다.
'제어' 열의 '설정' 버튼을 클릭하여 자원 그룹을 편집할 수 있습니다. '스케줄러 선택' 필드에서 연산 세션을 생성하기 위한 스케줄링 방법을 선택할 수 있습니다. 현재 FIFO, LIFO, DRF, FAIR_SHARE 네 가지 유형이 있습니다. FIFO와 LIFO는 작업 대기열에서 먼저 또는 마지막으로 대기열에 등록된 연산 세션을 생성하는 스케줄링 방법입니다. DRF는 Dominant Resource Fairness의 약자로, 각 사용자에게 가능한 한 공정하게 자원을 제공하는 것을 목표로 합니다. FAIR_SHARE는 과거 사용 패턴을 기반으로 연산 자원을 할당합니다. 자세한 내용은 Fair Share 스케줄러 섹션을 참고하세요. '활성' 상태를 끄면 자원 정책을 비활성화할 수 있습니다.
자원 그룹 편집 대화 상자에는 다음과 같은 추가 필드가 포함되어 있습니다:
- 허용된 세션 타입: 사용자가 세션 유형을 선택할 수 있으므로, 자원 그룹에서 특정 유형의 세션을 허용할 수 있습니다. 최소 하나의 세션 유형은 허용해야 합니다. 허용되는 세션 유형은 Interactive, Batch, Inference, System입니다.
- App Proxy 서버 주소: 자원 그룹의 에이전트가 사용할 App Proxy(이전 명칭 WSProxy) 주소를 설정합니다. 이 필드에 URL을 설정하면 App Proxy가 Jupyter와 같은 앱의 트래픽을 Manager를 우회하여 에이전트를 통해 연산 세션으로 직접 중계합니다 (v2 API). App Proxy에서 에이전트 노드로의 직접 연결이 가능하지 않은 경우 이 필드를 비워 두어 v1 API로 폴백하세요.
- App Proxy API 토큰: App Proxy 서버와의 인증을 위한 API 토큰입니다.
- 활성: 자원 그룹의 활성 상태를 전환합니다.
- 공개: 활성화하면 자원 그룹이 모든 사용자에게 표시됩니다.
- 대기 세션 유휴 시간:
연산 세션이 대기 세션 유휴 시간보다 오래
PENDING상태를 유지하면 취소됩니다. 세션이 무기한 PENDING 상태로 남는 것을 방지하려면 이 시간을 설정합니다. 이 기능을 적용하지 않으려면 이 값을 0으로 설정합니다. - 대기 세션 건너뛰기 재시도 횟수:
스케줄러가 PENDING 세션을 건너뛰기 전에 시도하는 재시도 횟수입니다. 하나의 PENDING 세션이 후속 세션의 스케줄링을 무기한으로 차단하는 상황(Head-of-line blocking, HOL)을 방지하기 위해 구성할 수 있습니다. 값이 지정되지 않으면 Etcd의 전역 값이 사용됩니다 (
num retries to skip, 기본값 3회).
'+ Create' 버튼을 클릭하여 새 자원 그룹을 생성할 수 있습니다. 다른 생성 옵션과 마찬가지로 이미 존재하는 이름으로는 자원 그룹을 생성할 수 없습니다. 이름은 키 값이기 때문입니다.
STORAGES 탭에서는 어떤 종류의 마운트 볼륨(일반적으로 NFS)이 존재하는지 확인할 수 있습니다. 23.03 버전부터 쿼터 관리를 지원하는 스토리지에서 사용자별/프로젝트별 쿼터 설정을 제공합니다. 이 기능을 사용하면 관리자가 사용자 및 프로젝트 기반 폴더별 정확한 스토리지 사용량을 쉽게 관리하고 모니터링할 수 있습니다.
쿼터를 설정하려면 먼저 resource 페이지의 storages 탭에 액세스해야 합니다. 그런 다음 control 열의 '설정 (톱니바퀴)'를 클릭합니다.
:::note 쿼터 설정은 쿼터 설정을 제공하는 스토리지(예: XFS, CephFS, NetApp, Purestorage 등)에서만 사용할 수 있습니다. 쿼터 설정 페이지에서 스토리지와 관계없이 스토리지 사용량을 볼 수 있지만, 내부적으로 쿼터 구성을 지원하지 않는 쿼터는 구성할 수 없습니다.
Quota setting 페이지에는 두 개의 패널이 있습니다.
-
Overview panel
- Usage: 선택한 스토리지의 실제 사용량을 표시합니다.
- Endpoint: 선택한 스토리지의 마운트 포인트를 나타냅니다.
- Backend Type: 스토리지의 유형입니다.
- Capabilities: 선택한 스토리지의 지원되는 기능입니다.
-
Quota Settings
- For User: 사용자별 쿼터 설정을 여기서 구성합니다.
- For Project: 프로젝트별 쿼터(프로젝트 폴더) 설정을 여기서 구성합니다.
- ID: 사용자 또는 프로젝트 ID에 해당합니다.
- Hard Limit (GB): 선택한 쿼터에 대해 현재 설정된 hard limit 쿼터입니다.
- Control: hard limit을 편집하거나 쿼터 설정을 삭제하는 기능을 제공합니다.
Backend.AI에는 사용자와 관리자(프로젝트)가 생성한 두 가지 유형의 vfolder가 있습니다. 이 섹션에서는 사용자별 현재 쿼터 설정을 확인하고 구성하는 방법을 보여드리고자 합니다. 먼저 quota settings 패널의 활성 탭이 For User인지 확인합니다. 그런 다음 쿼터를 확인하고 편집하려는 사용자를 선택합니다. 이미 쿼터를 설정한 경우 사용자 ID에 해당하는 쿼터 ID와 이미 설정된 구성을 테이블에서 볼 수 있습니다.
물론 쿼터를 편집하려면 control 열의 Edit 버튼을 클릭하기만 하면 됩니다. Edit 버튼을 클릭하면 쿼터 설정을 구성할 수 있는 작은 모달이 표시될 수 있습니다. 정확한 양을 입력한 후 변경 사항이 적용되도록 OK 버튼을 클릭하는 것을 잊지 마십시오.
프로젝트 폴더에 쿼터를 설정하는 것은 사용자 쿼터를 설정하는 것과 유사합니다. 프로젝트 쿼터 설정과 사용자 쿼터 설정의 차이점은 프로젝트 쿼터 설정을 확인하려면 프로젝트가 속한 도메인을 선택하는 한 가지 절차가 더 필요하다는 것입니다. 나머지는 동일합니다. 아래 그림과 같이 먼저 도메인을 선택한 다음 프로젝트를 선택해야 합니다.
쿼터를 해제하는 기능도 제공합니다. 쿼터 설정을 제거한 후에는 쿼터가 자동으로 사용자 또는 프로젝트 기본 쿼터를 따르게 되며, 이는 WebUI에서 설정할 수 없습니다. 기본 쿼터 설정을 변경하려면 관리자 전용 페이지에 액세스해야 할 수 있습니다. control 열의 Unset 버튼을 클릭하면 작은 snackbar 메시지가 표시되어 현재 쿼터 설정을 정말로 삭제할 것인지 확인합니다. snackbar 메시지의 OK 버튼을 클릭하면 쿼터 설정이 삭제되고 쿼터 유형(사용자/프로젝트)에 따라 해당 쿼터에 맞게 자동으로 재설정됩니다.
:::note
사용자/프로젝트별 구성이 없는 경우 사용자/프로젝트 자원 정책의 해당 값이 기본값으로 설정됩니다. 예를 들어 쿼터에 대한 hard limit 값이 설정되지 않은 경우 자원 정책의 max_vfolder_size 값이 기본값으로 사용됩니다.
:::
:::note 이 기능은 현재 기본 Session 페이지에서 사용할 수 없습니다. 이 기능을 사용하려면 User Setting 페이지의 'Switch back to the Classic UI' 섹션에서 'Classic Session list page' 옵션을 활성화하십시오. 자세한 내용은 Backend.AI 사용자 설정 섹션을 참고하세요. :::
관리자용 Session 페이지에는 추가 기능이 있습니다. FINISHED 탭의 오른쪽에 ...로 표시된 메뉴가 있습니다. 이 메뉴를 클릭하면 export CSV 하위 메뉴가 나타납니다.
이 메뉴를 클릭하면 지금까지 생성된 연산 세션의 정보를 CSV 형식으로 다운로드할 수 있습니다. 다음 대화 상자가 열리면 적절한 파일 이름을 입력하고(필요한 경우) EXPORT 버튼을 클릭하면 CSV 파일을 받을 수 있습니다. 파일 이름은 최대 255자까지 입력할 수 있습니다.
Configuration 페이지에서 Backend.AI 서버의 주요 설정을 볼 수 있습니다. 현재 설정을 변경하고 나열할 수 있는 여러 컨트롤을 제공합니다.
Digest, Tag, None 중 하나의 옵션을 선택하여 이미지 자동 설치 및 업데이트 규칙을 변경할 수 있습니다. Digest는 이미지의 무결성을 확인하고 중복된 레이어를 재사용하여 이미지 다운로드 효율성을 향상시키는 일종의 체크섬입니다. Tag는 이미지의 무결성을 보장하지 않기 때문에 개발 옵션 전용입니다.
:::note 각 규칙의 의미를 완전히 이해하지 않는 한 규칙 선택을 변경하지 마십시오. :::
Configuration 페이지에서는 플러그인 및 엔터프라이즈 기능의 상태도 표시됩니다:
플러그인:
- 오픈소스 CUDA GPU 지원: CUDA GPU 지원 상태.
- ROCm GPU 지원: ROCm GPU 지원 상태.
엔터프라이즈 기능:
- 분할 GPU: 세션 간 GPU 공유를 위한 GPU 가상화.
Backend.AI는 다양한 벤더의 AI 가속기를 폭넓게 지원합니다:
- NVIDIA
- Spark (GB10)
- Blackwell (B300, B200, RTX Pro 6000 등)
- Hopper (H200, H100 NVL 등)
- Grace Superchip (GB300, GB200, GH200 등)
- Turing (Titan RTX, RTX 8000, T4)
- Ampere (A100, A40, A10 등)
- Ada Lovelace (L40S, L4)
- Jetson (TX, Xavier, Orin, Thor 등)
- Intel
- Gaudi 3
- Gaudi 2
- Gaudi 1
- Arc
- AMD
- Instinct MI 시리즈 (MI300X 포함)
- MI300A
- MI250
- Rebellions
- ATOM Max
- ATOM+
- REBEL
- FuriosaAI
- RNGD
- Tenstorrent
- Wormhole n150s
- Wormhole n300s
- Google
- TPU v7 (Ironwood)
- Coral TPU v5p
- Coral TPU v5e
- TPU v4
- Graphcore
- C600 IPU
- Bow IPU
- HyperAccel
- LPU
- Groq
- LPU
- Cerebras
- WSE-3
- SambaNova
- SN40L
버전 20.09에 도입된 멀티 노드 클러스터 세션을 사용자가 시작하면 Backend.AI는 private 노드 간 통신을 지원하기 위해 오버레이 네트워크를 동적으로 생성합니다. 관리자는 해당 값이 네트워크 속도를 향상시킬 것이 확실한 경우 오버레이 네트워크의 Maximum Transmission Unit (MTU) 값을 설정할 수 있습니다.
:::note Backend.AI Cluster 세션에 대한 자세한 내용은 Backend.AI 클러스터 연산 세션 섹션을 참고하세요. :::
Scheduler의 config 버튼을 클릭하여 작업 스케줄러별 구성을 편집할 수 있습니다. 스케줄러 설정의 값은 각 자원 그룹에 스케줄러 설정이 없을 때 사용할 기본값입니다. 자원 그룹별 설정이 있는 경우 이 값은 무시됩니다.
현재 지원되는 스케줄링 방법에는 FIFO, LIFO, DRF가 있습니다. 각 스케줄링 방법은 위의 스케줄링 방법과 정확히 동일합니다. 스케줄러 옵션에는 세션 생성 재시도가 포함됩니다. 세션 생성 재시도는 실패한 경우 세션을 생성하기 위한 재시도 횟수를 나타냅니다. 시도 횟수 내에 세션을 생성할 수 없으면 요청이 무시되고 Backend.AI가 다음 요청을 처리합니다. 현재 스케줄러가 FIFO인 경우에만 변경이 가능합니다.
:::note 더 광범위한 설정 컨트롤을 계속 추가할 예정입니다. :::
:::note 시스템 설정은 기본 설정입니다. 자원 그룹에 특정 값이 있으면 시스템 설정에서 구성된 값이 재정의됩니다. :::
Maintenance 페이지로 이동하면 서버를 관리하는 몇 가지 버튼이 표시됩니다.
- RECALCULATE USAGE: 때때로 불안정한 네트워크 연결이나 Docker daemon의 컨테이너 관리 문제로 인해 Backend.AI가 점유한 자원이 컨테이너가 실제로 사용하는 자원과 일치하지 않는 경우가 있을 수 있습니다. 이 경우 RECALCULATE USAGE 버튼을 클릭하여 자원 점유율을 수동으로 수정합니다.
- RESCAN IMAGES: 등록된 모든 Docker registry에서 이미지 메타 정보를 업데이트합니다. Backend.AI에 연결된 docker registry에 새 이미지가 푸시될 때 사용할 수 있습니다.
:::note 사용하지 않는 이미지 제거 또는 정기 유지 관리 일정 등록과 같이 관리에 필요한 기타 설정을 계속 추가할 예정입니다. :::
Information 페이지에서 각 기능의 여러 상세 정보와 상태를 볼 수 있습니다. Manager 버전과 API 버전을 보려면 Core 패널을 확인하십시오. Backend.AI의 각 구성 요소가 호환되는지 여부를 확인하려면 Component 패널을 확인하십시오.
:::note 이 페이지는 현재 정보를 표시하기 위한 것입니다. :::
RBAC(역할 기반 접근 제어) 관리를 통해 슈퍼어드민은 세분화된 권한이 포함된 역할을 정의하고 사용자에게 할당할 수 있습니다. Backend.AI 시스템 전반에서 특정 사용자가 다양한 리소스에 대해 수행할 수 있는 작업을 제어할 수 있습니다.
:::note RBAC 관리는 슈퍼어드민만 사용할 수 있으며, Backend.AI Manager 25.4.0 이상 버전이 필요합니다. :::
역할, 권한 및 사용자 할당 관리에 대한 자세한 정보는 RBAC 관리 페이지를 참고하세요.















































































