레퍼런스 아키텍처 - Weights & Biases Documentation

이 페이지에서는 W&B 배포를 위한 레퍼런스 아키텍처를 설명하고, 플랫폼의 프로덕션 배포를 지원하기 위해 권장되는 인프라와 리소스를 간략히 설명합니다. 선택한 W&B 배포 환경에 따라 다양한 서비스가 배포의 복원력을 높이는 데 도움이 될 수 있습니다. 예를 들어, 주요 클라우드 제공업체는 강력한 관리형 데이터베이스 서비스를 제공하므로 데이터베이스 설정, 유지 관리, 고가용성, 복원성과 관련된 복잡성을 줄일 수 있습니다. 이 레퍼런스 아키텍처는 몇 가지 일반적인 배포 시나리오를 다루고, 최적의 성능과 안정성을 위해 W&B 배포를 클라우드 벤더 서비스와 어떻게 통합할 수 있는지 보여줍니다.

시작하기 전에

프로덕션에서 애플리케이션을 운영하는 데에는 여러 가지 과제가 따르며, W&B도 예외는 아닙니다. 저희는 이 과정을 간소화하기 위해 노력하고 있지만, 각자의 아키텍처와 설계 결정에 따라 일부 복잡한 문제가 발생할 수 있습니다. 일반적으로 프로덕션 배포를 관리하려면 하드웨어, 운영 체제, 네트워킹, 저장소, 보안, W&B 플랫폼 자체, 그리고 기타 의존성을 비롯한 다양한 컴포넌트를 관리해야 합니다. 이러한 책임은 환경의 초기 설정뿐 아니라 지속적인 유지 관리에도 해당됩니다. W&B와 함께 Self-Managed 방식을 선택하는 것이 팀과 구체적인 요구 사항에 적합한지 신중히 검토하세요. Self-Managed W&B를 배포하기 전에, 프로덕션급 애플리케이션을 운영하고 유지 관리하는 방법을 충분히 이해하고 있어야 합니다. 팀에 도움이 필요하다면, Professional Services 팀과 파트너가 구현 및 최적화를 지원합니다. 직접 관리하는 대신 W&B를 실행할 수 있는 관리형 솔루션에 대해 자세히 알아보려면 W&B Multi-tenant Cloud 및 W&B Dedicated Cloud를 참고하세요.

인프라

애플리케이션 계층

애플리케이션 계층은 노드 장애에도 견딜 수 있는 다중 노드 Kubernetes 클러스터로 구성됩니다. Kubernetes 클러스터는 W&B의 파드를 실행하고 관리합니다.

저장소 계층

저장소 계층은 MySQL 데이터베이스와 객체 저장소로 구성됩니다. MySQL 데이터베이스는 메타데이터를 저장하고, 객체 저장소는 모델 및 데이터셋과 같은 아티팩트를 저장합니다.

인프라 요구 사항

Kubernetes

W&B Server 애플리케이션은 여러 파드를 배포하는 Kubernetes Operator 형태로 배포됩니다. 따라서 W&B를 사용하려면 다음 요건을 갖춘 Kubernetes 클러스터가 필요합니다.

완전히 설정되어 정상적으로 작동하는 인그레스 컨트롤러
Persistent Volume을 프로비저닝할 수 있는 기능

W&B는 클라우드, 온프레미스, 폐쇄망 환경의 OpenShift Kubernetes 클러스터 배포를 지원합니다. 구체적인 설정 지침은 Operator 가이드의 OpenShift 섹션을 참조하세요.

MySQL

W&B는 메타데이터를 MySQL 데이터베이스에 저장합니다. 데이터베이스의 성능 및 저장소 요구 사항은 모델 파라미터의 형태와 관련 메타데이터에 따라 달라집니다. 예를 들어, 더 많은 트레이닝 run을 추적할수록 데이터베이스 크기가 커지며, run 테이블, 사용자 Workspace, Reports의 쿼리에 따라 데이터베이스 부하도 증가합니다. W&B는 프로덕션 배포에 관리형 데이터베이스 서비스를 사용할 것을 강력히 권장합니다(예: AWS RDS Aurora MySQL, Google Cloud SQL for MySQL, Azure Database for MySQL). 관리형 서비스는 자동 백업, 모니터링, 고가용성, 패치 적용을 제공하며 오퍼레이션 복잡성을 크게 줄여 줍니다. 구체적인 서비스 권장 사항은 아래의 Cloud provider instance recommendations section을 참조하세요. Self-Managed MySQL 데이터베이스를 배포하기로 한 경우에는 다음 사항을 고려하세요:

백업: 데이터베이스를 별도의 시설에 정기적으로 백업해야 합니다. W&B는 최소 1주일 보관하는 일일 백업을 권장합니다.
성능: 데이터베이스에는 SSD 또는 가속 NAS와 같은 고속 저장소 하드웨어가 필요합니다.
모니터링: 데이터베이스에는 충분한 CPU 리소스가 필요합니다. 데이터베이스 서버의 CPU 부하를 모니터링하세요. CPU 사용률이 5분 넘게 시스템의 90%를 초과한 상태로 유지되면 CPU 용량 증설을 고려하세요.
가용성: 가용성과 내구성 요구 사항을 충족하려면, W&B는 기본 배포의 모든 업데이트를 실시간으로 스트리밍하고 기본 서버가 충돌하거나 손상되거나 장시간 다운타임이 발생할 경우 장애 조치할 수 있도록, 별도 머신에 hot standby Server 배포를 구성할 것을 권장합니다. W&B는 멀티 마스터 토폴로지나 읽기 전용 레플리카를 지원하지 않습니다.

MySQL 데이터베이스 생성

MySQL 데이터베이스와 사용자를 수동으로 생성하는 방법은 베어메탈 가이드의 MySQL 데이터베이스 섹션을 참조하세요.

MySQL 설정 매개변수

MySQL 인스턴스를 직접 운영하는 경우 다음과 같이 MySQL을 설정하세요:

binlog_format = 'ROW'
binlog_row_image = 'MINIMAL'
innodb_flush_log_at_trx_commit = 1
innodb_online_alter_log_max_size = 268435456
max_prepared_stmt_count = 1048576
sort_buffer_size = '67108864'
sync_binlog = 1

이 설정은 최적의 성능과 안정성을 위해 W&B의 검증을 거쳤습니다.

Redis

W&B는 작업 대기열 처리와 데이터 캐싱에 사용하는 단일 노드 Redis 7.x 배포에 의존합니다. 테스트와 개념 증명 개발의 편의를 위해 W&B Self-Managed에는 로컬 Redis 배포가 포함되어 있지만, 이는 프로덕션 배포에는 적합하지 않습니다. W&B는 다음 환경의 Redis 인스턴스에 연결할 수 있습니다:

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
클라우드 또는 온프레미스 인프라에서 호스팅되는 Redis 배포

객체 저장소

W&B를 사용하려면 사전 서명된 URL과 CORS를 지원하는 객체 저장소가 필요하며, 다음 중 하나에 배포해야 합니다:

CoreWeave AI Object Storage는 AI 워크로드에 최적화된 고성능 S3 호환 객체 저장소 서비스입니다.
Amazon S3는 업계 최고 수준의 확장성, 데이터 가용성, 보안, 성능을 제공하는 객체 저장소 서비스입니다.
Google Cloud Storage는 비정형 데이터를 대규모로 저장할 수 있는 관리형 서비스입니다.
Azure Blob Storage는 텍스트, 바이너리 데이터, 이미지, 비디오, 로그와 같은 대량의 비정형 데이터를 저장하기 위한 클라우드 기반 객체 저장소 솔루션입니다.
MinIO Enterprise (AIStor), NetApp StorageGRID 또는 클라우드나 온프레미스 인프라에 호스팅되는 기타 엔터프라이즈급 솔루션과 같은 S3 호환 저장소.

버전

소프트웨어	최소 버전
Kubernetes	v1.32 이상 (지원되는 Kubernetes 버전)
Helm	v3.x
MySQL	v8.0.x가 필요하며 v8.0.32 이상이어야 합니다. v8.0.44 이상을 권장합니다. Aurora MySQL 3.x 릴리스는 v3.05.2 이상이어야 합니다.
Redis	v7.x

네트워킹

네트워크에 연결된 배포 환경에서는 설치 중과 런타임 중 모두 다음 endpoint로의 아웃바운드 연결이 필요합니다:

배포 설정에 따라 추가 container registry가 필요할 수 있습니다:

Weave 온라인 평가를 위해 Bufstream 및 etcd를 배포할 때는 https://gcr.io가 필요합니다.

air-gapped 배포에 대해 알아보려면 air-gapped 인스턴스용 Kubernetes operator를 참고하세요. 트레이닝 인프라와 Experiments 요구 사항을 추적하는 각 시스템에는 W&B 및 객체 저장소에 대한 액세스가 필요합니다.

DNS

W&B 배포 환경의 정규화된 도메인 이름(FQDN)은 A 레코드를 통해 인그레스/로드 밸런서의 IP 주소로 해석되어야 합니다.

로드 밸런서 및 인그레스

W&B Kubernetes Operator는 Kubernetes 인그레스 컨트롤러를 사용해 서비스를 외부에 노출할 수 있으며, 이 컨트롤러는 서로 다른 포트를 사용하는 URL 경로에 따라 서비스 엔드포인트로 라우팅합니다. 인그레스 컨트롤러는 머신 러닝 워크로드를 실행하거나 웹 브라우저를 통해 서비스에 접속하는 모든 머신에서 접근할 수 있어야 합니다.

인그레스 컨트롤러 요구 사항

Kubernetes 클러스터에서 IngressClass를 사용할 수 있어야 합니다. 일반적인 인그레스 컨트롤러 옵션은 다음과 같습니다.

Nginx Ingress Controller
Istio
Traefik
클라우드 제공업체 인그레스 컨트롤러(AWS ALB, GCP Ingress, Azure Application Gateway)

W&B 서비스 라우팅

W&B Operator는 경로를 기준으로 요청을 여러 백엔드 서비스에 자동으로 라우팅합니다:

Path	Service	Default port	Purpose
`/`	`wandb-app`	8080	메인 웹 애플리케이션 UI
`/api`	`wandb-api`	8081	API 서비스
`/graphql`	`wandb-api`	8081	GraphQL API 엔드포인트
`/graphql2`	`wandb-api`	8081	GraphQL API v2 엔드포인트
`/console`	`wandb-console`	8082	시스템 콘솔
`/traces`	`wandb-weave-trace`	8722	Weave Tracing 서비스(활성화된 경우)

인그레스 설정 예시

다음은 W&B Operator가 생성한 인그레스 리소스의 예입니다:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wandb
  namespace: wandb
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
spec:
  ingressClassName: nginx
  rules:
  - host: wandb.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wandb-app
            port:
              number: 8080
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: wandb-api
            port:
              number: 8081
      - path: /graphql
        pathType: Prefix
        backend:
          service:
            name: wandb-api
            port:
              number: 8081
      - path: /graphql2
        pathType: Prefix
        backend:
          service:
            name: wandb-api
            port:
              number: 8081
      - path: /console
        pathType: Prefix
        backend:
          service:
            name: wandb-console
            port:
              number: 8082
  tls:
  - hosts:
    - wandb.example.com
    secretName: wandb-tls

W&B Operator가 인그레스 설정을 자동으로 생성하고 관리합니다. 일반적으로 인그레스 리소스를 수동으로 생성할 필요는 없습니다. 클러스터에 정상적으로 작동하는 인그레스 컨트롤러가 있고, 적절한 IngressClass가 설정되어 있는지 확인하세요.

SSL/TLS

W&B는 클라이언트와 서버 간의 보안 통신을 위해 유효한 공인 SSL/TLS 인증서를 요구합니다. SSL/TLS 종료는 인그레스/로드 밸런서에서 이루어져야 합니다. W&B Server 애플리케이션은 SSL 또는 TLS 연결을 종료하지 않습니다. 중요: W&B는 자체 서명 인증서와 사용자 지정 CA를 지원하지 않습니다. 자체 서명 인증서를 사용하면 사용자에게 문제가 발생할 수 있으며, 지원되지 않습니다. 가능하다면 Let’s Encrypt와 같은 서비스를 사용해 로드 밸런서에 신뢰할 수 있는 인증서를 제공하는 것이 좋습니다. Caddy 및 Cloudflare와 같은 서비스는 SSL을 대신 관리해 줍니다. 보안 정책상 신뢰할 수 있는 네트워크 내부에서도 SSL 통신이 필요하다면, Istio와 사이드카 컨테이너 같은 도구를 사용하는 것을 고려하세요.

지원되는 CPU 아키텍처

W&B는 Intel 및 AMD의 64비트 아키텍처에서 실행됩니다. ARM은 지원되지 않습니다.

배포 방법

권장: Helm과 함께 W&B Kubernetes Operator 사용

W&B Self-Managed의 권장 설치 방법은 Helm을 통해 W&B Kubernetes Operator를 배포하는 것입니다. 이 방식의 장점은 다음과 같습니다.

W&B 컴포넌트의 자동 업데이트 및 관리
간소화된 설정 및 배포
모든 배포 시나리오 지원(클라우드, 온프레미스, 폐쇄망 환경)

자세한 설치 지침은 다음 문서를 참조하세요.

온프레미스에서 W&B Platform 배포 - 기본 설치 가이드
폐쇄망 인스턴스를 위한 Kubernetes Operator - 외부와 분리된 환경용

인프라 프로비저닝

Terraform은 W&B 프로덕션 deployment를 위한 인프라를 프로비저닝하는 데 권장되는 방법입니다. Terraform을 사용하면 필요한 리소스와 다른 리소스를 참조하는 방식, 그리고 리소스 간 의존성을 정의할 수 있습니다. W&B는 주요 클라우드 제공업체용 Terraform 모듈을 제공합니다. 자세한 내용은 Self-Managed 클라우드 계정 내에 W&B Server 배포을 참고하세요.

용량 산정

배포를 계획할 때는 다음의 일반 지침을 출발점으로 삼으세요. W&B는 새 배포의 모든 컴포넌트를 면밀히 모니터링하고, 관찰된 사용 패턴에 따라 조정할 것을 권장합니다. 시간 경과에 따라 프로덕션 배포도 계속 모니터링하고, 최적의 성능을 유지할 수 있도록 필요에 따라 조정하세요.

Models 전용

Kubernetes

환경	CPU	메모리	디스크
Test/Dev	2 코어	16 GB	100 GB
프로덕션	8 코어	64 GB	100 GB

표의 수치는 Kubernetes 워커 노드 1개당 기준입니다.

MySQL

환경	CPU	메모리	디스크
Test/Dev	2코어	16 GB	100 GB
프로덕션	8코어	64 GB	500 GB

수치는 MySQL 노드당 기준입니다.

Weave 전용

Kubernetes

환경	CPU	메모리	디스크
Test/Dev	4코어	32 GB	100 GB
프로덕션	12코어	96 GB	100 GB

수치는 Kubernetes 워커 노드 기준입니다.

MySQL

환경	CPU	메모리	디스크
Test/Dev	2 코어	16 GB	100 GB
프로덕션	8 코어	64 GB	500 GB

수치는 MySQL 노드당 기준입니다.

Models 및 Weave

Kubernetes

환경	CPU	메모리	디스크
Test/Dev	4 코어	32 GB	100 GB
프로덕션	16 코어	128 GB	100 GB

수치는 Kubernetes 워커 노드당 기준입니다.

MySQL

환경	CPU	메모리	디스크
Test/Dev	2 코어	16 GB	100 GB
프로덕션	8 코어	64 GB	500 GB

수치는 MySQL 노드당 기준입니다.

클라우드 제공업체별 인스턴스 권장 사항

서비스

클라우드	Kubernetes	MySQL	객체 저장소
AWS	EKS	RDS Aurora	S3
Google Cloud	GKE	Google Cloud SQL - Mysql	Google Cloud Storage (GCS)
Azure	AKS	Azure Database for Mysql	Azure Blob Storage

머신 유형

이 권장 사항은 클라우드 인프라상의 W&B Self-Managed 배포의 각 노드에 적용됩니다.

AWS

환경	K8s (Models 전용)	K8s (Weave 전용)	K8s (Models&Weave)	MySQL
Test/Dev	r6i.large	r6i.xlarge	r6i.xlarge	db.r6g.large
프로덕션	r6i.2xlarge	r6i.4xlarge	r6i.4xlarge	db.r6g.2xlarge

Google Cloud

환경	K8s (Models 전용)	K8s (Weave 전용)	K8s (Models&Weave)	MySQL
Test/Dev	n2-highmem-2	n2-highmem-4	n2-highmem-4	db-n1-highmem-2
프로덕션	n2-highmem-8	n2-highmem-16	n2-highmem-16	db-n1-highmem-8

Azure

환경	K8s (Models 전용)	K8s (Weave 전용)	K8s (Models&Weave)	MySQL
Test/Dev	Standard_E2_v5	Standard_E4_v5	Standard_E4_v5	MO_Standard_E2ds_v4
프로덕션	Standard_E8_v5	Standard_E16_v5	Standard_E16_v5	MO_Standard_E8ds_v4

W&B에 오신 것을 환영합니다

제품

플랫폼 세부 정보

리소스

​시작하기 전에

​인프라

​애플리케이션 계층

​저장소 계층

​인프라 요구 사항

​Kubernetes

​MySQL

​MySQL 데이터베이스 생성

​MySQL 설정 매개변수

​Redis

​객체 저장소

​버전

​네트워킹

​DNS

​로드 밸런서 및 인그레스

​인그레스 컨트롤러 요구 사항

​W&B 서비스 라우팅

​인그레스 설정 예시

​SSL/TLS

​지원되는 CPU 아키텍처

​배포 방법

​권장: Helm과 함께 W&B Kubernetes Operator 사용

​인프라 프로비저닝

​용량 산정

​Models 전용

​Kubernetes

​MySQL

​Weave 전용

​Kubernetes

​MySQL

​Models 및 Weave

​Kubernetes

​MySQL

​클라우드 제공업체별 인스턴스 권장 사항

​서비스

​머신 유형

​AWS

​Google Cloud

​Azure

시작하기 전에

인프라

애플리케이션 계층

저장소 계층

인프라 요구 사항

Kubernetes

MySQL

MySQL 데이터베이스 생성

MySQL 설정 매개변수

Redis

객체 저장소

버전

네트워킹

DNS

로드 밸런서 및 인그레스

인그레스 컨트롤러 요구 사항

W&B 서비스 라우팅

인그레스 설정 예시

SSL/TLS

지원되는 CPU 아키텍처

배포 방법

권장: Helm과 함께 W&B Kubernetes Operator 사용

인프라 프로비저닝

용량 산정

Models 전용

Kubernetes

MySQL

Weave 전용

Kubernetes

MySQL

Models 및 Weave

Kubernetes

MySQL

클라우드 제공업체별 인스턴스 권장 사항

서비스

머신 유형

AWS

Google Cloud

Azure