레퍼런스 아키텍처

W&B 레퍼런스 아키텍처

이 페이지에서는 W&B 배포를 위한 참조 아키텍처를 설명하고, 플랫폼의 프로덕션 배포를 지원하기 위해 권장되는 인프라와 리소스를 개괄합니다.

선택한 W&B 배포 환경에 따라, 배포의 안정성과 탄력성을 강화하는 데 도움이 되는 다양한 서비스를 활용할 수 있습니다.

예를 들어, 주요 클라우드 서비스 제공업체는 데이터베이스 구성, 유지 관리, 고가용성 및 복원성과 관련된 복잡성을 줄여 주는 견고한 관리형 데이터베이스 서비스를 제공합니다.

이 참조 아키텍처는 몇 가지 일반적인 배포 시나리오를 다루며, 최적의 성능과 안정성을 위해 W&B 배포를 클라우드 서비스 제공업체의 서비스와 통합하는 방법을 보여줍니다.

​

시작하기 전에

프로덕션 환경에서 애플리케이션을 실행하는 것은 고유한 여러 가지 과제를 수반하며, W&B도 예외는 아닙니다. W&B는 이 과정을 간소화하는 것을 목표로 하지만, 사용 중인 고유한 아키텍처와 설계 결정에 따라 특정 복잡성이 발생할 수 있습니다. 일반적으로 프로덕션 배포를 운영하려면 하드웨어, 운영 체제, 네트워크, 스토리지, 보안, W&B 플랫폼 자체, 그리고 기타 종속성 등 다양한 구성 요소를 관리해야 합니다. 이러한 책임은 환경의 초기 설정뿐만 아니라 이후 지속적인 유지 관리까지 포함합니다.

W&B의 Self-Managed 방식을 사용하는 것이 팀과 특정 요구사항에 적합한지 신중하게 검토하십시오.

프로덕션급 애플리케이션을 실행하고 유지 관리하는 방법에 대한 충분한 이해는 Self-Managed W&B를 배포하기 전에 갖추어야 할 중요한 전제 조건입니다. 팀에 도움이 필요한 경우, 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 애플리케이션은 여러 개의 Pod를 배포하는 Kubernetes Operator를 통해 배포됩니다. 이러한 이유로 W&B에는 다음 요구 사항을 충족하는 Kubernetes 클러스터가 필요합니다:

• 완전히 구성되어 정상 동작하는 Ingress 컨트롤러
• Persistent Volume을 프로비저닝할 수 있는 능력

W&B는 클라우드, 온프레미스, 망 분리(air-gapped) 환경의 OpenShift Kubernetes 클러스터 배포를 지원합니다. 구체적인 구성 방법은 Operator 가이드의 OpenShift 섹션을 참조하세요.

​

MySQL

W&B는 메타데이터를 MySQL 데이터베이스에 저장합니다. 데이터베이스의 성능 및 스토리지 요구 사항은 모델 파라미터와 관련 메타데이터의 구조와 크기에 따라 달라집니다. 예를 들어, 더 많은 학습 실행을 추적할수록 데이터베이스 크기가 커지고, 실행 테이블, 사용자 워크스페이스, 리포트에 대한 쿼리에 따라 데이터베이스 부하가 증가합니다.

W&B는 프로덕션 배포 환경에서 관리형 데이터베이스 서비스 사용을 강력히 권장합니다 (예: AWS RDS Aurora MySQL, Google Cloud SQL for MySQL, Azure Database for MySQL). 관리형 서비스는 자동 백업, 모니터링, 고가용성, 패치 적용을 제공하며 운영 복잡성을 크게 줄여줍니다. 구체적인 서비스 권장 사항은 아래 클라우드 제공업체 인스턴스 권장 사항 섹션을 참조하십시오.

직접 MySQL 데이터베이스를 구축(셀프 매니지드)하는 경우, 다음 사항을 고려하십시오:

• 백업: 데이터베이스를 주기적으로 별도의 위치(스토리지)로 백업해야 합니다. W&B는 최소 1주일 보존 기간을 가진 일일 백업을 권장합니다.
• 성능: 데이터베이스에는 SSD나 고성능 NAS와 같은 고속 스토리지 하드웨어가 필요합니다.
• 모니터링: 데이터베이스에는 충분한 CPU 리소스가 필요합니다. 데이터베이스 서버의 CPU 부하를 모니터링하십시오. CPU 사용률이 5분 이상 지속적으로 시스템의 90%를 초과하는 경우 CPU 용량 증설을 고려하십시오.
• 가용성: 요구되는 가용성과 내구성을 충족하기 위해, W&B는 기본 배포로부터 모든 업데이트를 실시간으로 스트리밍받고, 기본 서버에 장애가 발생하거나 손상되거나 지속적인 다운타임이 발생할 경우 즉시 페일오버할 수 있도록 별도 머신에 핫 스탠바이 서버 배포를 구성할 것을 권장합니다. 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는 작업 큐 처리와 데이터 캐싱을 위해 W&B 구성 요소에서 사용하는 단일 노드 Redis 7.x 배포에 의존합니다. 개념 증명(PoC)을 테스트하고 개발할 때의 편의를 위해 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

​

네트워크

네트워크로 구성된 배포 환경에서는 설치 및 실행 시간 둘 다 동안 다음 엔드포인트로의 아웃바운드 트래픽(egress)이 필요합니다:

• https://deploy.wandb.ai
• https://charts.wandb.ai
• https://quay.io (Prometheus 이미지에 사용)

배포 구성에 따라 추가 컨테이너 레지스트리가 필요할 수 있습니다:

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

에어갭(air-gapped) 배포에 대해 알아보려면 에어갭 인스턴스를 위한 Kubernetes operator를 참조하세요.

학습 인프라와 실험을 추적하는 각 시스템은 W&B 및 오브젝트 스토리지에 대한 접근 권한이 필요합니다.

​

DNS

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

​

로드 밸런서와 인그레스

W&B Kubernetes Operator는 Kubernetes 인그레스 컨트롤러를 사용해 서비스를 노출할 수 있습니다. 인그레스 컨트롤러는 서로 다른 포트에 대해 URL 경로를 기준으로 서비스 엔드포인트로 트래픽을 라우팅합니다. 인그레스 컨트롤러는 머신 러닝 워크로드를 실행하는 모든 머신과 웹 브라우저를 통해 서비스에 액세스하는 모든 머신에서 접근 가능해야 합니다.

​

Ingress 컨트롤러 요구 사항

Kubernetes 클러스터에는 사용 가능한 IngressClass가 있어야 합니다. 일반적인 Ingress 컨트롤러 옵션은 다음과 같습니다:

• Nginx Ingress Controller
• Istio
• Traefik
• 클라우드 제공자 Ingress 컨트롤러(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 트레이싱 서비스(활성화된 경우)

​

예시 인그레스 구성

다음은 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 종료(termination)는 반드시 인그레스/로드 밸런서에서 이루어져야 합니다. W&B Server 애플리케이션은 SSL 또는 TLS 연결을 종료하지 않습니다.

중요: W&B는 자체 서명 인증서 및 커스텀 CA(인증 기관)를 지원하지 않습니다. 자체 서명 인증서를 사용하면 사용자에게 문제가 발생하므로 지원되지 않습니다.

가능하다면 Let’s Encrypt와 같은 서비스를 사용하여 로드 밸런서에 신뢰할 수 있는 인증서를 제공하는 것이 좋습니다. Caddy 및 Cloudflare와 같은 서비스는 SSL을 대신 관리해 줍니다.

보안 정책상 신뢰할 수 있는 내부 네트워크 내에서도 SSL 통신이 필요한 경우, Istio 및 sidecar 컨테이너와 같은 도구의 사용을 고려하십시오.

​

지원되는 CPU 아키텍처

W&B는 Intel 및 AMD 64비트 아키텍처에서 동작합니다. ARM 아키텍처는 지원되지 않습니다.

​

배포 방식

​

추천: Helm을 사용하는 W&B Kubernetes Operator

W&B Self-Managed 배포에 권장되는 설치 방법은 Helm을 통해 배포되는 W&B Kubernetes Operator를 사용하는 것입니다. 이 방법은 다음과 같은 이점을 제공합니다:

• W&B 구성 요소의 자동 업데이트 및 관리
• 구성 및 배포 작업 단순화
• 모든 배포 시나리오(클라우드, 온프레미스, 에어갭 환경) 지원

자세한 설치 방법은 다음 문서를 참조하세요:

• Run W&B Server on Kubernetes (Operator) - 주요 설치 가이드
• Deploy W&B Platform On-premises - 데이터센터/베어 메탈 환경 관련 고려 사항
• Kubernetes operator for air-gapped instances - 격리된(인터넷 미연결) 환경용 가이드

​

인프라 프로비저닝

Terraform은 W&B 프로덕션 환경 배포를 위한 인프라를 프로비저닝하는 데 권장되는 도구입니다. Terraform을 사용하면 필요한 리소스, 다른 리소스에 대한 참조, 및 종속 관계를 정의할 수 있습니다. W&B는 주요 클라우드 서비스 제공자용 Terraform 모듈을 제공합니다. 자세한 내용은 자체 관리형 클라우드 계정 내에 W&B Server 배포를 참고하세요.

​

규모 산정

배포를 계획할 때는 다음 일반적인 지침을 출발점으로 사용하십시오. W&B는 새로운 배포의 모든 구성 요소를 면밀히 모니터링하고, 실제 사용 패턴에 따라 조정할 것을 권장합니다. 운영 중인 프로덕션 배포 환경도 지속적으로 모니터링하고, 최적의 성능을 유지할 수 있도록 필요에 따라 조정하십시오.

​

모델 전용

​

Kubernetes

Environment	CPU	Memory	Disk
Test/Dev	2 cores	16 GB	100 GB
Production	8 cores	64 GB	100 GB

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

​

MySQL

환경	CPU	메모리	디스크
테스트/개발	2 cores	16 GB	100 GB
운영	8 cores	64 GB	500 GB

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

​

Weave 전용

​

Kubernetes

Environment	CPU	Memory	Disk
Test/Dev	4 cores	32 GB	100 GB
Production	12 cores	96 GB	100 GB

위 사양은 Kubernetes 워커 노드 1개 기준입니다.

​

MySQL

Environment	CPU	Memory	Disk
Test/Dev	2코어	16 GB	100 GB
Production	8코어	64 GB	500 GB

위 사양은 MySQL 노드당 기준입니다.

​

모델과 Weave

​

Kubernetes

환경	CPU	메모리	디스크
테스트/개발	4코어	32 GB	100 GB
운영	16코어	128 GB	100 GB

숫자는 Kubernetes 워커 노드 한 개 기준입니다.

​

MySQL

Environment	CPU	Memory	Disk
Test/Dev	2 cores	16 GB	100 GB
Production	8 cores	64 GB	500 GB

위 사양은 MySQL 노드 1개 기준입니다.

​

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

​

서비스

| 클라우드 | 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

| Environment | K8s (Models only) | K8s (Weave only) | K8s (Models&Weave) | MySQL |
| ----------- | ------------------ | ------------------ | ------------------- | ------------------ |
| 테스트/개발 | r6i.large | r6i.xlarge | r6i.xlarge | db.r6g.large | | 운영 | r6i.2xlarge | r6i.4xlarge | r6i.4xlarge | db.r6g.2xlarge |

​

Google Cloud

| Environment | K8s (Models only) | K8s (Weave only) | K8s (Models&Weave) | MySQL |
| ----------- | ------------------ | ------------------ | ------------------- | ------------------ |
| 테스트/개발 | 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

| Environment | K8s (Models only) | K8s (Weave only) | K8s (Models&Weave) | MySQL |
| ----------- | ------------------ | ------------------ | ------------------- | ------------------- |
| Test/Dev | Standard_E2_v5 | Standard_E4_v5 | Standard_E4_v5 | MO_Standard_E2ds_v4 | | Production | Standard_E8_v5 | Standard_E16_v5 | Standard_E16_v5 | MO_Standard_E8ds_v4 |