개요
이 페이지에서는 플랫폼 관리자가 W&B Kubernetes Operator를 사용하여 Kubernetes(클라우드 또는 온프레미스)에 W&B Server를 배포하고 관리하는 방법을 설명합니다. 이 가이드를 완료하면 Operator가 자동으로 관리하고 업그레이드하는 W&B Server 설치가 실행됩니다. W&B 배포를 직접 관리하며 클라우드, 온프레미스, 에어갭 환경 전반에서 사용할 수 있는 설치 방법이 필요한 경우 이 가이드를 사용하세요. W&B Kubernetes Operator는 Kubernetes(클라우드 또는 온프레미스)에 W&B Server를 배포하는 권장 방법입니다. Operator의 개요, W&B가 이를 사용하는 이유, 설정 계층 구조의 작동 방식은 Self-Managed를 참고하세요.시작하기 전에
Kubernetes Operator로 W&B를 배포하기 전에 인프라가 모든 요구 사항을 충족하는지 확인하세요.- 인프라 요구 사항 검토: 다음 항목에 대한 자세한 내용은 Self-Managed 인프라 요구 사항 페이지를 참조하세요.
- 소프트웨어 버전 요구 사항(Kubernetes, MySQL, Redis, Helm, ClickHouse)
- 하드웨어 요구 사항(CPU 아키텍처, 사이징 권장 사항)
- Kubernetes 클러스터 설정
- 네트워킹, SSL/TLS, DNS 요구 사항
- W&B Server 라이선스 획득: 요구 사항 페이지의 라이선스 섹션을 참조하세요.
- 외부 서비스 프로비저닝: 배포 전에 MySQL, Redis, 객체 저장소를 설정하세요.
MySQL 데이터베이스
W&B에는 외부 MySQL 데이터베이스가 필요합니다. 프로덕션 환경에서는 관리형 데이터베이스 서비스를 사용하는 것이 좋습니다. 관리형 데이터베이스 서비스는 자동 백업, 모니터링, 고가용성, 패치를 제공하며 운영 부담을 줄여줍니다. 사이징 권장 사항과 설정 매개변수를 포함한 MySQL 요구 사항은 레퍼런스 아키텍처를 참조하세요. 데이터베이스를 생성하는 SQL은 베어메탈 가이드를 참조하세요. 배포 환경의 데이터베이스 설정에 관한 질문은 지원팀 또는 담당 AISE에 문의하세요. 설정 매개변수와 데이터베이스 생성을 포함한 전체 MySQL 설정 지침은 요구 사항 페이지의 MySQL 섹션을 참조하세요. MySQL 8.0.x에서 업그레이드하는 경우 MySQL 8.4.x로 업그레이드를 참조하세요.Redis
W&B는 단일 노드 Redis 7.x 배포에 의존하며, W&B의 컴포넌트는 작업 큐잉과 데이터 캐싱에 이를 사용합니다. 테스트 및 개념 증명 작업의 경우, W&B Self-Managed에는 로컬 Redis 배포가 포함됩니다. 이 번들 배포는 프로덕션 용도로는 적합하지 않습니다. 프로덕션 배포의 경우, W&B는 다음 환경의 Redis 인스턴스에 연결할 수 있습니다:- Amazon ElastiCache
- Google Cloud Memorystore
- Azure Cache for Redis
- 클라우드 또는 온프레미스 인프라에서 자체 호스팅하는 Redis
객체 저장소
W&B를 사용하려면 사전 서명된 URL과 CORS를 지원하는 오브젝트 스토리지가 필요합니다. W&B에서 권장하는 스토리지 공급자는 다음과 같습니다.- Amazon S3: 확장성, 데이터 가용성, 보안, 성능을 제공하는 오브젝트 스토리지 서비스입니다.
- Google Cloud Storage: 대규모 비정형 데이터를 저장하기 위한 관리형 서비스입니다.
- Azure Blob Storage: 대규모 비정형 데이터를 위한 클라우드 기반 오브젝트 스토리지입니다.
- CoreWeave AI Object Storage: AI 워크로드에 최적화된 S3 호환 오브젝트 스토리지입니다.
- MinIO Enterprise (AIStor), NetApp StorageGRID 등의 엔터프라이즈 S3 호환 저장소 또는 기타 엔터프라이즈 솔루션
MinIO 오픈 소스는 유지 관리 모드로 전환되어 더 이상 활발히 개발되지 않으며, 사전 컴파일된 바이너리도 제공되지 않습니다. 프로덕션 배포에는 관리형 오브젝트 스토리지 서비스나 MinIO Enterprise (AIStor) 같은 엔터프라이즈 S3 호환 솔루션을 사용할 것을 권장합니다.
저장소 버킷 프로비저닝
W&B를 설정하기 전에 오브젝트 저장소 버킷을 프로비저닝하고 필수 IAM 정책, CORS 설정, 액세스 자격 증명을 구성해야 합니다. 다음 항목별 프로비저닝 절차는 Bring Your Own Bucket (BYOB) 가이드에서 단계별로 자세히 확인하세요.- Amazon S3 (IAM 정책 및 버킷 정책 포함)
- Google Cloud Storage (PubSub 알림 포함)
- Azure Blob Storage (관리 ID 포함)
- CoreWeave AI Object Storage
- S3 호환 저장소 (MinIO Enterprise, NetApp StorageGRID 및 기타 엔터프라이즈 솔루션)
OpenShift Kubernetes 클러스터
W&B는 클라우드, 온프레미스, 에어갭 환경의 OpenShift Kubernetes 클러스터에 배포하는 것을 지원합니다.공식 W&B Helm 차트를 사용하여 설치하는 것을 권장합니다.
권한 없는 사용자로 컨테이너 실행
OpenShift 및 유사한 오케스트레이터는 root로 실행되는 컨테이너를 거부하는 경우가 많으므로, W&B 컨테이너는 root 그룹에 속한 비 root 사용자로 실행되도록 설정해야 합니다. 기본적으로 컨테이너는$UID 값으로 999를 사용합니다. 오케스트레이터에서 컨테이너를 비 root 사용자로 실행하도록 요구하는 경우 $UID >= 100000과 $GID 값 0을 지정하세요.
파일 시스템 권한이 제대로 작동하려면 W&B가 root 그룹(
$GID=0)으로 시작되어야 합니다.app 또는 console과 같은 다른 컴포넌트에 맞춤형 보안 컨텍스트를 설정하세요. 자세한 내용은 맞춤형 보안 컨텍스트를 참조하세요.
W&B Server 애플리케이션 배포
클라우드, 온프레미스, 에어갭 환경을 포함한 모든 W&B Self-Managed 배포에는 Helm을 사용하는 W&B Kubernetes Operator가 권장 설치 방법입니다.
- Helm CLI
- Terraform
W&B는 W&B Kubernetes Operator를 Kubernetes 클러스터에 배포하기 위한 Helm chart를 제공합니다. 이 방식을 사용하면 Helm CLI 또는 ArgoCD와 같은 지속적 배포 도구로 W&B Server를 배포할 수 있습니다.배포 관련 고려 사항은 환경별 고려 사항 및 퍼블릭 클라우드에서 Terraform으로 배포를 참고하세요. 인터넷과 연결되지 않은 환경의 경우 에어갭 Kubernetes에 배포를 참고하세요.다음 단계에 따라 Helm CLI로 W&B Kubernetes Operator를 설치하세요.
-
W&B Helm 저장소를 추가합니다. W&B Helm chart는 W&B Helm 저장소에서 제공됩니다.
-
Kubernetes 클러스터에 Operator를 설치합니다.
-
W&B Server 설치가 트리거되도록 W&B operator 맞춤형 리소스를 설정합니다. W&B 배포 설정을 담은
operator.yaml파일을 생성하세요. 사용 가능한 모든 옵션은 설정 레퍼런스를 참고하세요. 다음은 최소 설정 예시입니다. -
맞춤형 설정으로 Operator를 시작하여 Operator가 W&B Server 애플리케이션을 설치, 설정 및 관리하도록 합니다.
배포가 완료될 때까지 기다리세요. 몇 분 정도 걸립니다.
- 웹 UI에서 설치를 확인하려면 첫 번째 Admin 사용자 계정을 생성한 다음 설치 확인에 설명된 확인 단계를 따르세요.
wandb-cr namespace에서 W&B Kubernetes Operator가 실행되고, operator가 operator.yaml 맞춤형 리소스를 기반으로 W&B Server 애플리케이션을 관리하게 됩니다.설치 확인
설치 확인을 위해 W&B는 W&B CLI 사용을 권장합니다.wandb verify 명령은 컴포넌트와 설정이 예상대로 작동하는지 확인하는 테스트를 실행합니다.
이 절차는 브라우저에서 첫 번째 Admin 사용자 계정을 생성한다고 가정합니다.
-
W&B CLI 설치:
-
W&B에 로그인:
예시:
-
설치 확인:
MCP 서버 활성화
W&B MCP 서버는operator-wandb의 선택적 하위 차트로 제공됩니다. 활성화하면 Operator가 클러스터 내에 MCP 서버를 배포하고 기존 ingress를 통해 <global.host>/mcp에 노출하므로, 모든 MCP 호환 클라이언트가 W&B API 키를 사용하여 연결할 수 있습니다. 이 서버는 W&B가 https://mcp.withwandb.com/mcp에서 호스팅 서비스로 운영하는 서버와 동일하지만, 사용자의 배포 데이터에 연결됩니다.
최종 사용자를 위한 클라이언트 설정 및 도구 목록은 Use the W&B MCP server를 참조하세요. 이 섹션에서는 Operator 측 활성화만 다룹니다.
사전 요구 사항
MCP 서버를 활성화하기 전에 배포가 다음 요구 사항을 충족하는지 확인하세요:- 차트 버전:
operator-wandb0.42.3이상.mcp-server하위 차트는0.42.1에서 도입되었지만, 다음 예시에서 사용하는 Datadog 및 개인정보 보호 필드는 이후에 추가되었습니다. - Weave Traces 활성화: MCP 서버는 트레이스 도구와
WF_TRACE_SERVER_URL기본값에 Weave Traces를 사용합니다.weave-trace.install: true를 설정하세요. Weave Traces가 활성화되지 않으면 Helm 렌더링이mcp-server requires weave-trace.install=true오류로 실패합니다. - 접근 가능한 ingress:
global.host는 이미 이름 확인이 가능하고 W&B ingress로 라우팅되어야 합니다. MCP 파드는global.host에서WANDB_BASE_URL을 읽으며<global.host>/mcp에서 사용할 수 있습니다. - 노드 용량: MCP 파드는 기본적으로 CPU
500m과 메모리1Gi를 요청합니다(제한은 CPU2와 메모리4Gi). 하위 차트를 활성화하기 전에 Node Pool에 충분한 여유 용량이 있는지 확인하세요.
하위 차트 활성화
mcp-server 하위 차트를 활성화하여 Operator가 클러스터 내 MCP 서버를 배포하고 기존 W&B ingress에 /mcp 경로를 추가하도록 하세요. 기존 WeightsAndBiases 맞춤형 리소스(CR)의 spec.values 블록에 기존 global, ingress 및 기타 재정의 설정과 함께 다음 내용을 추가하세요. Datadog 블록은 선택 사항이지만, Datadog Agent DaemonSet이 이미 클러스터에서 파드 로그와 트레이스를 수집하고 있다면 추가하는 것이 좋습니다.
weave-trace.install: true:mcp-server.env.WF_TRACE_SERVER_URL을 직접 설정하지 않는 한 필수입니다.datadog.mode: "agent": Datadog Agent DaemonSet이 로그 및 트레이스 수집을 담당하는 Kubernetes 배포에 사용하세요. 에이전트 모드에서는 MCP 파드에 Datadog API 키가 필요하지 않습니다.datadog.service,env,deploymentType,customer,extraTags: 배포의 관측성 명명 규칙에 맞게 설정하세요. 고객 태그를 원하지 않으면customer를 빈 문자열로 설정하세요.privacy.logLevel: 대부분의 Self-Managed Kubernetes 설치에는"standard"를 사용하세요. 이 설정은 로그에서 자유 형식 텍스트 매개변수 값을 가리는 동시에 운영자가 디버깅에 흔히 사용하는 배포 식별자는 유지합니다. entity, 프로젝트, run 또는 사용자 식별자가 평문 로그에 남아서는 안 되는 경우"strict"를 사용하세요. 해당 값을 평문으로 로깅하려는 명시적인 의도가 있을 때만"off"를 사용하세요.
wandb-mcp-server 배포와 Service를 생성하고, W&B ingress에 /mcp 경로를 추가합니다.
MCP 서버 확인
파드가Running 상태가 될 때까지 기다린 다음, 클러스터 내부와 ingress를 통해 상태 확인 엔드포인트를 확인하세요:
200 OK를 반환해야 합니다. 클러스터 내부 검사는 파드가 정상 상태인지 확인합니다. ingress 검사는 라우팅을 확인합니다. 클러스터 내부 검사는 200 OK를 반환하지만 ingress 검사는 404 Not Found를 반환하는 경우 문제 해결을 참조하세요. Datadog를 활성화한 경우 설정된 mcp-server.datadog.service 및 mcp-server.datadog.env 값으로 MCP 서버 로그도 Datadog에 표시되어야 합니다.
클라이언트 연결
MCP 서버가 정상 상태가 되면 W&B API 키를 Bearer 토큰으로 사용하여https://<HOST_URI>/mcp에 연결하도록 MCP 클라이언트를 설정하세요. IDE 및 에이전트 설정 방법은 Use the W&B MCP server를 참조하세요.
문제 해결
환경별 고려 사항
Kubernetes는 온프레미스에서 실행하든 클라우드에서 실행하든 동일합니다. 주요 차이는 명명 방식과 관리형 서비스에 있습니다(예: MySQL과 RDS, 또는 S3와 온프레미스 객체 저장소). 이 섹션에서는 환경에 따라 달라지는 고려 사항을 다룹니다.온프레미스 및 베어 메탈
온프레미스 또는 베어 메탈 Kubernetes에 배포할 때는 다음 사항에 유의하세요.로드 밸런서 설정
온프레미스 Kubernetes 클러스터는 일반적으로 로드 밸런서를 수동으로 설정해야 합니다. 다음 옵션을 사용할 수 있습니다:- 외부 로드 밸런서: F5 또는 HAProxy와 같은 기존 하드웨어 또는 소프트웨어 로드 밸런서를 설정하세요.
- Nginx Ingress 컨트롤러: NodePort 또는 호스트 네트워킹을 사용하여 nginx-ingress-controller를 배포하세요.
- MetalLB: 베어 메탈 Kubernetes 클러스터에서 MetalLB는 로드 밸런서 서비스를 제공합니다.
영구 저장소
Kubernetes 클러스터에 영구 볼륨용 StorageClass가 설정되어 있는지 확인하세요. W&B 컴포넌트는 캐싱 및 임시 데이터용으로 영구 저장소가 필요할 수 있습니다. 일반적으로 사용하는 온프레미스 저장소 옵션은 다음과 같습니다.- NFS 기반 저장소 클래스
- Ceph/Rook 저장소
- 로컬 영구 볼륨
- NetApp, Pure Storage 등의 엔터프라이즈 저장소 솔루션
DNS 및 인증서 관리
온프레미스 배포의 경우 다음 작업을 완료하세요:- 내부 DNS 레코드가 W&B 호스트 이름을 가리키도록 설정하세요.
- 내부 인증 기관(CA)에서 SSL/TLS 인증서를 발급받으세요.
- 자체 서명 인증서를 사용하는 경우 Operator가 CA 인증서를 신뢰하도록 설정하세요.
OpenShift 배포
W&B는 OpenShift Kubernetes 클러스터에서의 배포를 전체 지원합니다. OpenShift는 보안 정책이 더 엄격하므로 OpenShift 배포에는 추가 보안 컨텍스트 설정이 필요합니다. OpenShift 관련 설정에 대한 자세한 내용은 OpenShift Kubernetes 클러스터를 참조하세요. 에어갭 환경의 OpenShift 예시는 에어갭 Kubernetes에 배포를 참조하세요.온프레미스 및 S3 호환 객체 저장소
객체 저장소 버킷을 프로비저닝한 후(객체 저장소 프로비저닝 참조), W&B 맞춤형 리소스에서 설정하세요. AWS S3(온프레미스) 온프레미스 AWS S3의 경우(Outposts 또는 호환 저장소를 통해 사용):?tls=true를 추가하세요:
- 저장소 용량 및 성능: 디스크 용량을 주의 깊게 모니터링하세요. 일반적인 W&B 사용 시 수십~수백 기가바이트가 필요합니다. 사용량이 많으면 저장소 사용량이 페타바이트에 이를 수 있습니다.
- 내결함성: 물리적 디스크에는 최소한 RAID 배열을 사용하세요. S3 호환 저장소에는 분산 또는 고가용성 설정을 사용하세요.
- 가용성: 저장소를 계속 사용할 수 있도록 모니터링을 설정하세요.
- Amazon S3 on Outposts
- NetApp StorageGRID
- MinIO Enterprise (AIStor)
- Dell ObjectScale
Terraform을 사용하는 퍼블릭 클라우드
AWS, Google Cloud 또는 Azure에서 인프라와 애플리케이션 전체를 배포하려면 퍼블릭 클라우드에서 Terraform으로 배포를 참조하세요.퍼블릭 클라우드에 Terraform으로 배포하기
W&B는 W&B Multi-tenant Cloud 또는 W&B Dedicated Cloud 배포 유형과 같은 완전 관리형 배포 옵션을 권장합니다. 완전 관리형 서비스는 설정이 거의 또는 전혀 필요하지 않습니다.
- AWS
- Google Cloud
- Azure
W&B는 AWS에 플랫폼을 배포할 때 W&B Server AWS Terraform Module을 사용할 것을 권장합니다.Terraform 모듈은 다음 필수 컴포넌트를 배포합니다:
- 로드 밸런서
- AWS ID 및 액세스 관리(IAM)
- AWS 키 관리 시스템(KMS)
- Amazon Aurora MySQL
- Amazon VPC
- Amazon S3
- Amazon Route53
- Amazon Certificate Manager (ACM)
- Amazon Elastic Load Balancing (ALB)
- Amazon Secrets Manager
- Elastic Cache for Redis
- SQS
사전 요구 권한
Terraform을 실행하는 계정은 이전 섹션에 나열된 모든 컴포넌트를 생성할 수 있어야 하며, IAM 정책과 IAM 역할을 생성하고 리소스에 역할을 부여할 권한이 있어야 합니다.일반적인 단계
이 섹션의 단계는 모든 배포 옵션에 공통으로 적용됩니다.-
개발 환경을 준비하세요.
- Terraform을 설치하세요.
- W&B는 버전 관리를 위해 Git 저장소를 생성할 것을 권장합니다.
-
terraform.tfvars파일을 생성하세요. 설치 유형에 따라tvfars파일 내용을 사용자 지정하세요. 최소 권장 내용은 다음 예시와 같습니다.namespace변수는 Terraform이 생성하는 모든 리소스에 접두사로 붙는 문자열이므로 배포하기 전에tvfars파일에 변수를 정의하세요.subdomain과domain의 조합이 W&B 인스턴스의 FQDN을 구성합니다. 앞선 예시에서 W&B FQDN은wandb-aws.wandb.ml이며, DNSzone_id는 Terraform이 FQDN 레코드를 생성하는 위치입니다.allowed_inbound_cidr와allowed_inbound_ipv6_cidr도 모두 설정해야 합니다. 모듈에서 이는 필수 입력입니다. 다음 예시는 모든 소스에서 W&B 설치 환경에 액세스할 수 있도록 허용합니다. -
versions.tf파일을 생성하세요. 이 파일에는 AWS에 W&B를 배포하는 데 필요한 Terraform 및 Terraform 공급자 버전이 포함되어 있습니다:Terraform 공식 문서를 참고하여 AWS 공급자를 설정하세요. W&B는 이 문서의 시작 부분에서 언급한 원격 백엔드 설정도 추가할 것을 권장합니다. -
variables.tf파일을 생성하세요 Terraform에서는terraform.tfvars에 설정한 모든 옵션에 대해 해당하는 변수 선언이 필요합니다.
권장 배포
이는 모든 필수 컴포넌트를 생성하고 Kubernetes 클러스터에 W&B의 최신 버전을 설치하는 가장 간단한 배포 옵션 설정입니다.-
main.tf를 생성하세요 일반 단계에서 파일을 생성한 디렉터리에 다음 내용으로main.tf파일을 생성하세요: -
W&B 배포
W&B를 배포하려면 다음 명령어를 실행하세요:
Redis 활성화
Redis로 SQL 쿼리를 캐시하고 메트릭을 로드할 때 애플리케이션 응답 속도를 높이려면main.tf 파일에 create_elasticache_subnet = true 옵션을 추가하세요:메시지 브로커(큐) 활성화
SQS를 사용하는 외부 메시지 브로커를 활성화하려면main.tf 파일에 use_internal_queue = false 옵션을 추가하세요:W&B에는 내장 브로커가 포함되어 있으므로 이는 선택 사항입니다. 이 옵션은 성능을 개선하지 않습니다.
추가 자료
기타 배포 옵션
모든 설정을 같은 파일에 추가하여 여러 배포 옵션을 조합할 수 있습니다. 각 Terraform 모듈은 권장 배포 섹션의 표준 옵션 및 최소 설정과 조합할 수 있는 여러 옵션을 제공합니다. 사용 가능한 옵션의 전체 목록은 해당 클라우드 제공업체의 모듈 문서를 참고하세요:W&B 관리 콘솔에 액세스
W&B Kubernetes Operator에는 관리 콘솔이 함께 제공됩니다. 이 콘솔에서 배포 상태를 검토하고, 컴포넌트 메트릭을 확인하고, operator 수준의 설정을 조정할 수 있습니다. 관리 콘솔은${HOST_URI}/console에서 사용할 수 있습니다(예: https://wandb.company-name.com/console).
관리 콘솔에 로그인하는 방법은 두 가지입니다.
- 옵션 1(권장)
- 옵션 2
-
브라우저에서 W&B 애플리케이션을 열고 로그인합니다.
${HOST_URI}/(예:https://wandb.company-name.com/)에서 W&B 애플리케이션에 로그인하세요. -
콘솔에 액세스합니다. 오른쪽 상단의 아이콘을 클릭한 다음 System console을 클릭하세요. System console 항목은 Admin 권한이 있는 사용자에게만 표시됩니다.

W&B Kubernetes Operator 업데이트
이 섹션에서는 W&B Kubernetes Operator 자체를 업데이트하는 방법을 설명합니다. 버그 수정 사항과 새로운 조정(reconciliation) 기능을 적용하려면 operator를 주기적으로 업데이트하세요.- W&B Kubernetes Operator를 업데이트해도 W&B Server 애플리케이션은 업데이트되지 않습니다.
- W&B Kubernetes Operator를 사용하지 않는 Helm 차트를 사용 중이라면, 이 섹션의 단계에 따라 W&B Operator를 업데이트하기 전에 먼저 마이그레이션 지침을 참조하세요.
-
helm repo update로 저장소를 업데이트합니다. -
helm upgrade로 Helm 차트를 업데이트합니다.
W&B Server 애플리케이션 업데이트
W&B Kubernetes Operator를 사용하면 더 이상 W&B Server 애플리케이션을 직접 업데이트할 필요가 없습니다. W&B 소프트웨어의 새 버전이 릴리스되면 operator가 W&B Server 애플리케이션을 자동으로 업데이트합니다.MySQL을 8.4.x로 업그레이드
MySQL 8.0.x는 지원이 종료되었습니다. Self-Managed 배포에서는 보안 패치와 중요한 버그 수정이 제공되는 지원 대상 MySQL 버전을 실행해야 합니다. 커뮤니티 MySQL을 실행하는 경우 MySQL 8.4.x를 설치하거나 해당 버전으로 업그레이드하세요. 관리형 서비스를 사용하는 경우 공급자가 문서에서 지원 및 패치 제공 대상으로 명시한 엔진 버전을 실행하세요(예: Amazon RDS for MySQL, Google Cloud SQL for MySQL 또는 Azure Database for MySQL). W&B는 MySQL 8.4.0 및 현재 8.4.x 릴리스에서 플랫폼을 검증했습니다. 다음 단계는 W&B 관점에서의 작업 순서를 설명합니다. 백업과 버전별 업그레이드 경로를 포함한 MySQL 자체의 업그레이드 방법은 MySQL 배포판 또는 클라우드 제공업체의 문서를 따르세요. 동일한 순서가 표준 및 에어갭 Operator 배포에 적용됩니다. 에어갭 환경에서는 데이터베이스를 업그레이드하기 전에 내부 배포 절차를 통해 MySQL 8.4.x 소프트웨어를 획득하세요.시작하기 전에 유지 관리 시간을 계획하고 사용자에게 알리세요. 호환성이나 배포 토폴로지에 관한 질문이 있으면 Customer Support 또는 담당 W&B 팀에 문의하세요.
- 대상 버전과 그 사이의 모든 버전에 대한 MySQL 릴리스 노트 및 문서에서 요구 사항과 기타 세부 정보를 검토하세요.
- 유지 관리를 준비하세요. 업그레이드를 시작하기 전에 데이터베이스에 대해 MySQL Shell 업그레이드 검사기를 실행하여 대상 버전의 호환성 문제를 파악하고 수정할 수 있습니다. 진행하기 전에 검사기 출력에 나타난 오류나 경고를 모두 해결하세요. MySQL 배포판의 문서를 참고하세요.
- MySQL을 종료하고 MySQL 배포판의 문서에 따라 MySQL 데이터베이스의 전체 백업을 수행하세요. 업그레이드 중에는 MySQL을 사용할 수 없습니다. 데이터베이스를 사용할 수 없는 동안 W&B 클라이언트 애플리케이션은 연결할 수 없으며 일시적인 오류가 발생합니다.
- MySQL 배포판의 문서에 따라 MySQL을 8.4.x로 업그레이드하세요.
- MySQL을 다시 시작하고 정상적으로 작동하는지 확인하세요.
-
MySQL이 가동되면
wandb verify를 실행하여 W&B 배포를 검증하세요. 이 명령은 일련의 검사를 실행하고 결과를STDOUT에 보고합니다. 문제가 보고되면 필요한 사항을 조정한 후 다시 실행하세요. 설정 및 로그인 단계는 설치 확인을 참고하세요. - 검증이 완료되면 사용자는 정상적인 작업을 재개할 수 있습니다.
ClickHouse compatibility for upgrades
Self-Managed 배포는 외부 ClickHouse 클러스터를 사용하는 경우 W&B Server를 업그레이드하기 전에 ClickHouse 호환성을 확인해야 합니다.지원되는 ClickHouse 버전
W&B Weave는 ClickHouse Server와 ClickHouse Keeper 모두 지원되는 버전이 필요합니다.- Weave는 ClickHouse 25.8부터 25.12까지, 그리고 26.3 이상을 지원합니다.
- Weave는 ClickHouse 26.1 또는 26.2와 호환되지 않습니다.
Self-Managed 인스턴스를 W&B Operator로 마이그레이션
이 섹션에서는 W&B Server 설치를 직접 관리하던 방식에서 W&B Operator가 대신 관리하는 방식으로 마이그레이션하는 방법을 설명합니다. 마이그레이션하면 operator가 조정(reconciliation)과 W&B Server 업그레이드를 자동으로 처리하므로, 애플리케이션의 매니페스트 변경이나 Helm 업그레이드를 더 이상 직접 조율하지 않아도 됩니다. 마이그레이션 절차는 W&B Server를 설치한 방법에 따라 다릅니다.W&B Operator는 W&B Server의 기본 설치 방법이자 권장 설치 방법입니다. 궁금한 점이 있으면 Customer Support 또는 담당 W&B 팀에 문의하세요.
- 공식 W&B Cloud Terraform 모듈을 사용한 경우, 해당 문서로 이동하여 안내된 단계를 따르세요.
- W&B Non-Operator Helm 차트를 사용한 경우, operator-based Helm 차트로 마이그레이션을 참조하세요.
- W&B Non-Operator Helm 차트를 Terraform과 함께 사용한 경우, operator-based Terraform Helm 차트로 마이그레이션을 참조하세요.
- 매니페스트로 Kubernetes 리소스를 생성한 경우, operator-based Helm 차트로 마이그레이션을 참조하세요.
operator-based AWS Terraform 모듈로 마이그레이션
마이그레이션 프로세스에 대한 자세한 설명은 operator-wandb 차트 문서를 참조하세요.operator-based Google Cloud Terraform 모듈로 마이그레이션
질문이 있거나 지원이 필요하시면 Customer Support 또는 담당 W&B 팀에 문의하세요.Operator-based Azure Terraform 모듈로 마이그레이션
Customer Support 또는 담당 W&B 팀에 문의하여 질문이 있거나 도움이 필요하시면 도움을 받으세요.operator-based Helm 차트로 마이그레이션
operator-based Helm 차트로 마이그레이션하려면 다음 단계를 따르세요:-
현재 W&B 설정을 조회하세요. non-operator-based 버전의 Helm 차트로 W&B를 배포한 경우, 다음과 같이 값을 내보내세요:
Kubernetes 매니페스트로 W&B를 배포한 경우, 다음과 같이 값을 내보내세요:이제 다음 단계에 필요한 모든 설정 값을 확보했습니다.
-
operator.yaml이라는 파일을 만드세요. 설정 레퍼런스에 설명된 형식을 따르세요. 1단계의 값을 사용하세요. -
현재 배포를 0 파드로 스케일링하세요. 이 단계는 현재 배포를 중지합니다.
-
Helm 차트 저장소를 업데이트하세요:
-
새 Helm 차트를 설치하세요:
-
새 Helm 차트를 설정하고 W&B 애플리케이션 배포를 트리거하세요. 새 설정을 적용하세요.
배포가 완료되는 데 몇 분 정도 걸립니다.
- 설치를 확인하세요. 설치 확인의 단계를 따라 모든 것이 제대로 작동하는지 확인하세요.
- 이전 설치를 제거하세요. 이전 Helm 차트를 제거하거나 매니페스트로 생성한 리소스를 삭제하세요.
operator-based Terraform Helm 차트로 마이그레이션
operator-based Terraform Helm 차트로 마이그레이션하려면 다음 단계를 따르세요:- Terraform 설정을 준비하세요. Terraform 설정에서 이전 배포의 Terraform 코드를 Helm Terraform 모듈로 W&B 배포에 설명된 코드로 교체하세요. 이전과 동일한 변수를 설정하세요.
.tfvars파일이 있는 경우 변경하지 마세요. - Terraform run을 실행하세요.
terraform init,terraform plan,terraform apply를 실행하세요. - 설치 확인을 수행하세요. 설치 확인의 단계를 따라 모든 것이 제대로 작동하는지 확인하세요.
- 이전 설치를 제거하세요. 이전 Helm 차트를 제거하거나 매니페스트로 생성한 리소스를 삭제하세요.
W&B Server 설정 레퍼런스
이 섹션은WeightsAndBiases 맞춤형 리소스에서 지정하는 설정 옵션에 대한 레퍼런스입니다. operator.yaml 파일을 작성하거나 업데이트할 때 MySQL, Redis, ingress 또는 OIDC와 같은 특정 서브시스템의 YAML 스키마를 확인하는 데 참고하세요.
이 섹션에서는 W&B Server 애플리케이션의 설정 옵션을 설명합니다. 애플리케이션은 WeightsAndBiases라는 맞춤형 리소스 정의를 통해 설정을 받습니다. 일부 옵션은 아래 설정을 통해 지정할 수 있으며, 나머지 옵션은 환경 변수로 설정해야 합니다.
문서에서는 환경 변수 목록을 기본과 고급으로 나누어 제공합니다. 필요한 설정 옵션을 Helm 차트에서 지정할 수 없는 경우에만 환경 변수를 사용하세요.
기본 예시
이 예제는 W&B에 필요한 최소한의 값 집합을 정의합니다. 보다 현실적인 프로덕션 예시는 전체 예제를 참조하세요. 이 YAML 파일은 버전, 환경 변수, 데이터베이스와 같은 외부 리소스 및 기타 필요한 설정을 포함하여 W&B 배포의 원하는 상태를 정의합니다.전체 예제
이 예제 설정은 Google Cloud Storage를 사용하여 W&B를 Google Cloud Anthos에 배포합니다:Host
객체 저장소 (버킷)
AWSkmsKey는 null이어야 합니다.
accessKey와 secretKey를 시크릿에서 참조하려면:
MySQL
password를 참조하려면:
라이선스
license를 참조하려면:
Ingress
Kubernetes ingress 클래스를 파악하는 방법을 참조하세요. TLS 없이맞춤형 Kubernetes 서비스 계정
W&B 파드를 실행할 맞춤형 Kubernetes 서비스 계정을 지정하세요. 다음 스니펫은 지정된 이름의 서비스 계정을 배포의 일부로 생성합니다:create: false로 설정하세요:
외부 Redis
password를 참조하려면:
LDAP
global.extraEnv에서 환경 변수를 설정하여 LDAP를 설정하세요:
OIDC SSO
authMethod은 선택 사항입니다.
SMTP
환경 변수
요청 속도 제한 설정
Dedicated Cloud 및 Self-Managed 배포에서 Operator를 사용하는 경우,spec.values.global.extraEnv에서 환경 변수를 설정하여 요청 속도 제한을 선택적으로 설정할 수 있습니다. 레퍼런스로, 이 예제는 각 요청 속도 제한을 기본값으로 명시적으로 설정합니다. 실제로는 기본값을 override하기 위해서만 요청 속도 제한을 정의하세요.
맞춤형 인증 기관
customCACerts는 목록이며 여러 인증서를 포함할 수 있습니다. customCACerts에 지정된 인증 기관은 W&B Server 애플리케이션에만 적용됩니다.
ConfigMap을 사용하는 경우, ConfigMap의 각 키는
.crt로 끝나야 합니다(예시: my-cert.crt 또는 ca-cert1.crt). 이 명명 규칙은 update-ca-certificates가 각 인증서를 파싱하여 시스템 CA 저장소에 추가하는 데 필요합니다.맞춤형 security context
각 W&B 컴포넌트는 다음 형식의 맞춤형 security context 설정을 지원합니다:runAsGroup:의 유효한 값은 0뿐입니다. 다른 값은 오류입니다.app 섹션을 추가하세요:
console, weave, weave-trace, parquet에도 적용됩니다.
W&B Operator 설정 레퍼런스
이 섹션에서는 W&B Kubernetes Operator(wandb-controller-manager)의 설정 옵션에 대해 설명합니다. operator는 YAML 파일 형식으로 설정을 받습니다.
기본적으로 W&B Kubernetes Operator는 설정 파일이 필요하지 않습니다. 필요한 경우 설정 파일을 만드세요. 예를 들어, 맞춤형 인증 기관을 지정하거나 에어 갭 환경에 배포하는 등의 경우 설정 파일이 필요할 수 있습니다.
사양의 맞춤형 설정 전체 목록은 Helm 저장소에서 확인하세요.
맞춤형 CA
맞춤형 인증 기관(customCACerts)은 목록 형식이며 여러 인증서를 포함할 수 있습니다. 추가된 인증 기관은 W&B Kubernetes Operator(wandb-controller-manager)에만 적용됩니다.
ConfigMap의 각 키는
.crt로 끝나야 합니다(예시: my-cert.crt 또는 ca-cert1.crt). 이 명명 규칙은 update-ca-certificates가 각 인증서를 파싱하고 시스템 CA 저장소에 추가하는 데 필요합니다.자주 묻는 질문
각 파드의 목적과 역할
W&B Server 배포에는 다음 파드가 포함됩니다:wandb-app: GraphQL API와 프런트엔드 애플리케이션을 포함하는 W&B의 핵심입니다. W&B Platform의 대부분의 기능을 제공합니다.wandb-console:/console을 통해 액세스하는 관리 콘솔입니다.wandb-otel: 관리 콘솔에 표시할 메트릭과 로그를 Kubernetes 계층의 리소스에서 수집하는 OpenTelemetry 에이전트입니다.wandb-prometheus: 관리 콘솔에 표시할 메트릭을 다양한 컴포넌트에서 수집하는 Prometheus 서버입니다.wandb-parquet:wandb-app파드와 분리된 백엔드 마이크로서비스로, 데이터베이스 데이터를 Parquet 형식으로 객체 저장소에 내보냅니다.wandb-weave: UI에서 쿼리 table을 로드하고 다양한 핵심 앱 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.wandb-weave-trace: LLM 기반 애플리케이션을 추적하고, 실험하고, 평가하고, 배포하고, 개선하기 위한 프레임워크입니다. 이 프레임워크는wandb-app파드를 통해 액세스합니다.
W&B Operator Console 비밀번호 조회 방법
W&B 관리 콘솔 액세스를 참조하세요.Ingress가 작동하지 않을 때 W&B Operator Console에 액세스하는 방법
Kubernetes 클러스터에 연결할 수 있는 호스트에서 다음 명령어를 실행하세요:https://localhost:8082/ 콘솔에 액세스하세요.
비밀번호를 조회하는 방법(옵션 2)은 W&B 관리 콘솔에 액세스를 참조하세요.
