레퍼런스 아키텍처 - CoreWeave Docs

이 페이지에서는 W&B 배포를 위한 레퍼런스 아키텍처를 설명하고, 플랫폼을 프로덕션 환경에 배포할 때 권장되는 인프라와 리소스를 간략히 소개합니다. 안정적인 Self-Managed 설치에 필요한 컴포넌트의 규모를 산정하고, 이를 프로비저닝하고 통합하는 과정에서 계획 가이드로 활용하세요. 이 페이지는 자체 인프라에 W&B를 배포하고 운영하는 플랫폼 엔지니어, 사이트 신뢰성 엔지니어(SRE), 인프라 관리자를 대상으로 합니다. W&B를 배포할 환경에 따라 다양한 서비스를 활용하여 배포의 복원력을 높일 수 있습니다. 예를 들어, 주요 클라우드 제공업체는 관리형 데이터베이스 서비스를 제공하므로 데이터베이스 설정, 유지 관리, 고가용성 및 복원력 확보에 따르는 복잡성을 줄일 수 있습니다. 이 레퍼런스 아키텍처는 일반적인 배포 시나리오를 다루며, 성능과 안정성을 높이기 위해 W&B 배포를 클라우드 공급업체 서비스와 통합하는 방법을 보여줍니다.

시작하기 전에

프로덕션 환경에서 애플리케이션을 운영하다 보면 여러 가지 과제에 부딪히게 되며, W&B도 예외는 아닙니다. W&B는 이 과정을 최대한 간소화하고자 하지만, 아키텍처와 설계 결정에 따라 복잡한 문제가 생길 수 있습니다. 일반적으로 프로덕션 배포를 관리하려면 하드웨어, 운영 체제, 네트워킹, 저장소, 보안, W&B Platform 자체, 기타 의존성 등 다양한 컴포넌트를 관리해야 합니다. 이러한 책임은 환경의 초기 설정부터 지속적인 유지 관리까지 이어집니다. W&B를 Self-Managed 방식으로 운영하는 것이 팀과 요구 사항에 적합한지 신중하게 검토하세요. Self-Managed W&B를 배포하려면 먼저 프로덕션 수준의 애플리케이션을 운영하고 유지 관리하는 방법을 충분히 이해하고 있어야 합니다. 팀에 도움이 필요하다면 W&B Professional Services 팀과 파트너가 구현 및 최적화를 지원합니다. W&B를 직접 관리하지 않고 관리형 솔루션으로 운영하는 방법에 대해 자세히 알아보려면 W&B Multi-tenant Cloud 및 W&B Dedicated Cloud를 참고하세요.

인프라

W&B 배포는 애플리케이션 계층과 저장소 계층으로 구성됩니다. 다음 다이어그램은 두 계층이 어떻게 맞물려 동작하는지 보여 주며, 각 계층에 대한 자세한 내용은 이어지는 하위 섹션에서 설명합니다.

애플리케이션 계층

애플리케이션 계층은 노드 장애에 대비한 복원력을 갖춘 멀티 노드 Kubernetes 클러스터로 구성됩니다. 이 Kubernetes 클러스터에서 W&B 파드를 실행하고 유지 관리합니다.

저장소 계층

저장소 계층은 MySQL 데이터베이스와 오브젝트 저장소로 구성됩니다. MySQL 데이터베이스에는 메타데이터가 저장되고, 오브젝트 저장소에는 모델, 데이터셋 등의 아티팩트가 저장됩니다.

인프라 요구 사항

다음 섹션에서는 W&B 배포에 필요한 요구 사항을 자세히 설명합니다. Kubernetes 클러스터 세부 정보, MySQL, Redis, 오브젝트 저장소, 소프트웨어 버전, 네트워킹, DNS, 로드 밸런서 및 ingress, SSL/TLS, 지원되는 CPU 아키텍처에 대한 요구 사항을 다룹니다. 배포를 시작하기 전에 사용 중인 환경이 각 요구 사항을 모두 충족하는지 확인하세요.

Kubernetes

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

전체 설정이 완료되어 정상적으로 작동하는 ingress 컨트롤러
Persistent Volume 프로비저닝 기능

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

MySQL

W&B는 메타데이터를 MySQL 데이터베이스에 저장합니다. 데이터베이스의 성능 및 저장소 요구 사항은 모델 매개변수와 관련 메타데이터의 형태에 따라 달라집니다. 예를 들어, 추적하는 트레이닝 run이 많아질수록 데이터베이스 크기가 커지며, run table, 사용자 워크스페이스, 리포트에서 실행되는 쿼리가 많아질수록 데이터베이스 부하가 증가합니다. 프로덕션 배포에는 관리형 데이터베이스 서비스(예: 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 용량 추가를 고려하세요.
가용성: 가용성 및 내구성 요구 사항을 충족하려면 별도의 머신에 핫 스탠바이 배포를 구성할 것을 권장합니다. 스탠바이는 기본 배포의 모든 업데이트를 실시간으로 스트리밍하며, 기본 서버에 크래시나 데이터 손상, 장시간 다운타임이 발생하면 즉시 장애 조치(failover)를 수행할 수 있습니다.

MySQL 토폴로지

프로덕션 환경에서는 관리형 MySQL 서비스를 사용하는 것이 고가용성을 확보하는 가장 단순한 방법입니다. 장애 조치, 백업, 패치 적용을 클라우드 제공업체가 대신 처리하기 때문입니다. AWS의 Aurora Multi-AZ와 같은 해당 제공업체의 고가용성 옵션을 사용하세요. MySQL을 직접 관리하는 경우에는 기본(primary) 데이터베이스와 핫 스탠바이를 함께 구성하세요. 핫 스탠바이는 실시간 복제 스트림을 수신하고, 장애 발생 시 기본 데이터베이스의 역할을 넘겨받을 수 있어야 합니다. W&B는 애플리케이션 데이터베이스에 대해 다중 기본(multi-primary) 토폴로지나 읽기 전용 레플리카를 지원하지 않습니다.

MySQL 데이터베이스 생성

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

MySQL 설정 매개변수

다음 매개변수는 W&B가 대규모로 수행하는 쓰기 패턴과 스키마 변경에 맞게 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 컴포넌트는 이를 작업 큐잉과 데이터 캐싱에 사용합니다. W&B Self-Managed에는 테스트 및 개념 증명(PoC) 개발 시 편의를 위한 로컬 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.34 이상(지원되는 Kubernetes 버전)
Helm	v3.x
MySQL	W&B Self-Managed 배포에서는 보안 패치와 중요 버그 수정이 제공되는, 지원되는 MySQL 버전을 실행해야 합니다. MySQL 8.4.x를 설치하거나 해당 버전으로 업그레이드하세요. 또는 공급자가 지원 및 패치 대상으로 명시한 관리형 서비스 버전을 사용하세요. Aurora MySQL의 버전 문자열은 커뮤니티 MySQL 버전과 다릅니다. 전체 엔진 버전 문자열은 `SELECT version()`으로, Aurora 버전은 `SELECT aurora_version()`으로 확인하세요. Aurora MySQL 버전 3은 MySQL 8.0.x와 호환되며 계속 지원됩니다. 대상 버전을 선택할 때는 Amazon Aurora 버전 관리 및 클라우드 제공업체의 문서를 참조하세요.
Redis	v7.x
ClickHouse	Self-Managed 배포에서 Weave를 사용하려면 필요합니다. Weave를 사용하지 않는 배포에서는 필요하지 않습니다. 업그레이드를 위한 ClickHouse 호환성 및 지원되는 W&B Server 릴리스를 참조하세요.

네트워킹

네트워크에 연결된 배포에서는 설치 시와 런타임 모두 다음 엔드포인트로의 이그레스(egress) 트래픽을 허용하세요.

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

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

Weave 온라인 평가를 위해 Bufstream과 etcd를 배포하는 경우: https://gcr.io

에어갭 배포에 대한 자세한 내용은 에어갭 인스턴스용 Kubernetes operator를 참고하세요. 트레이닝 인프라와 각 실험 추적 시스템이 W&B 및 오브젝트 저장소에 액세스할 수 있도록 권한을 부여하세요.

DNS

W&B 배포의 완전 수식된 도메인 이름(FQDN)은 A 레코드를 통해 ingress 또는 로드 밸런서의 IP 주소로 확인되어야 합니다.

로드 밸런서 및 ingress

W&B Kubernetes Operator는 Kubernetes ingress 컨트롤러를 사용해 서비스를 노출할 수 있습니다. ingress 컨트롤러는 URL 경로를 기준으로 트래픽을 서로 다른 포트의 서비스 엔드포인트로 라우팅합니다. 머신 러닝 페이로드를 실행하거나 웹 브라우저로 서비스에 액세스하는 모든 머신에서 ingress 컨트롤러에 액세스할 수 있어야 합니다.

Ingress 컨트롤러 요구 사항

Kubernetes 클러스터에서 사용 가능한 IngressClass가 있어야 합니다. 주로 사용되는 ingress 컨트롤러는 다음과 같습니다.

Nginx Ingress Controller.
Istio.
Traefik.
클라우드 제공업체의 ingress 컨트롤러(AWS ALB, GCP Ingress, Azure Application Gateway).

W&B 서비스 라우팅

W&B Operator는 경로에 따라 요청을 여러 백엔드 서비스로 자동 라우팅합니다.

경로	서비스	기본 포트	용도
`/`	`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	System Console
`/traces`	`wandb-weave-trace`	8722	Weave 트레이싱 서비스(활성화한 경우)

ingress 설정 예시

다음은 W&B Operator가 생성하는 ingress 리소스의 예시입니다.

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가 ingress 설정을 자동으로 생성하고 관리하므로 일반적으로 ingress 리소스를 직접 생성할 필요는 없습니다. 클러스터에 정상 작동하는 ingress 컨트롤러가 있고 적절한 IngressClass가 설정되어 있는지 확인하세요.

SSL/TLS

W&B는 클라이언트와 서버 간의 보안 통신을 위해 유효한 서명된 SSL/TLS 인증서가 필요합니다. SSL/TLS 종료는 ingress 또는 로드 밸런서에서 이루어져야 합니다. W&B Server 애플리케이션은 SSL 또는 TLS 연결을 종료하지 않습니다.

W&B는 자체 서명된 인증서 또는 맞춤형 CA를 지원하지 않습니다. 자체 서명된 인증서는 사용자에게 문제를 일으키며 지원되지 않습니다.

가능하면 Let’s Encrypt와 같은 서비스를 사용하여 로드 밸런서에 신뢰할 수 있는 인증서를 제공하세요. Caddy 및 Cloudflare와 같은 서비스는 SSL을 관리해 줍니다. 보안 정책에서 신뢰할 수 있는 네트워크 내에서 SSL 통신이 필요한 경우, Istio 및 sidecar containers와 같은 도구 사용을 고려하세요.

지원되는 CPU 아키텍처

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

배포 방법

인프라가 위의 요구 사항을 충족하면 W&B 설치 방법과 기반 리소스 프로비저닝 방법을 선택하세요. 다음 섹션에서는 권장 배포 방법과 권장 인프라 프로비저닝 방식을 설명합니다.

Helm을 사용한 W&B Kubernetes Operator

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

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

자세한 설치 방법은 다음을 참조하세요.

온프레미스에 W&B Platform 배포 - 기본 설치 가이드
에어갭 인스턴스용 Kubernetes operator - 네트워크가 분리된 환경용

인프라 프로비저닝

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

사이징

배포를 계획할 때 다음 가이드라인을 출발점으로 활용하세요. W&B는 배포의 모든 컴포넌트를 면밀히 모니터링하고, 관찰된 사용 패턴에 따라 조정할 것을 권장합니다. 프로덕션 배포는 이후에도 계속 모니터링하면서 성능이 유지되도록 필요에 따라 조정하세요. 용량을 계획할 때는 두 가지 핵심 컴포넌트의 규모를 산정합니다. 하나는 W&B Operator 워크로드를 실행할 Kubernetes 클러스터이고, 다른 하나는 메타데이터를 저장할 MySQL 데이터베이스입니다. 권장 사항은 환경(테스트/개발 또는 프로덕션)에 따라 달라지며, Kubernetes의 경우에는 제품 구성(Models 전용, Weave only, 또는 Models와 Weave)에 따라서도 달라집니다. W&B는 테스트/개발과 프로덕션 모두 최소 3개의 워커 노드로 시작하고, 프로덕션에서는 클러스터 오토스케일링을 활성화할 것을 권장합니다. 다음 섹션에서는 Kubernetes 클러스터와 MySQL 데이터베이스의 노드별 사이징 권장 사항을 설명합니다.

Kubernetes 사이징

Models 전용
Weave only
Models 및 Weave

환경	CPU	메모리	디스크
테스트/개발	2코어	16 GB	100 GB
프로덕션	8코어	64 GB	100 GB

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

환경	CPU	메모리	디스크
테스트/개발	4코어	32 GB	100 GB
프로덕션	12코어	96 GB	100 GB

환경	CPU	메모리	디스크
테스트/개발	4코어	32 GB	100 GB
프로덕션	16코어	128 GB	100 GB

MySQL 사이징

이 권장 사항은 제품 구성에 관계없이 동일합니다. 토폴로지 및 가용성 관련 지침은 MySQL 섹션의 MySQL 토폴로지를 참조하세요.

환경	CPU	메모리	디스크
테스트/개발	2코어	16 GB	100 GB
프로덕션	8코어	64 GB	500 GB

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

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

앞의 사이징 표에서 노드별 CPU, 메모리, 디스크 요구 사항을 확인했다면, 다음 권장 사항을 참고하여 이를 충족하는 클라우드 제공업체의 인스턴스 유형과 관리형 서비스를 선택하세요. 이 권장 사항은 클라우드 인프라에 W&B를 Self-Managed 방식으로 배포할 때 각 노드에 적용됩니다.

AWS
Google Cloud
Azure

권장 관리형 서비스

Kubernetes: Amazon EKS
MySQL: Amazon RDS Aurora
오브젝트 저장소: Amazon S3

환경	K8s (Models 전용)	K8s (Weave 전용)	K8s (Models&Weave)	MySQL
테스트/개발	r6i.large	r6i.xlarge	r6i.xlarge	db.r6g.large
프로덕션	r6i.2xlarge	r6i.4xlarge	r6i.4xlarge	db.r6g.2xlarge

권장 관리형 서비스

Kubernetes: Google Kubernetes Engine (GKE)
MySQL: Google Cloud SQL for MySQL
오브젝트 저장소: Google Cloud Storage (GCS)

환경	K8s (Models 전용)	K8s (Weave 전용)	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

권장 관리형 서비스

Kubernetes: Azure Kubernetes Service (AKS)
MySQL: Azure Database for MySQL
오브젝트 저장소: Azure Blob Storage

환경	K8s (Models 전용)	K8s (Weave 전용)	K8s (Models&Weave)	MySQL
테스트/개발	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

​시작하기 전에

​인프라

​애플리케이션 계층

​저장소 계층

​인프라 요구 사항

​Kubernetes

​MySQL

​MySQL 토폴로지

​MySQL 데이터베이스 생성

​MySQL 설정 매개변수

​Redis

​오브젝트 저장소

​버전

​네트워킹

​DNS

​로드 밸런서 및 ingress

​Ingress 컨트롤러 요구 사항

​W&B 서비스 라우팅

​ingress 설정 예시

​SSL/TLS

​지원되는 CPU 아키텍처

​배포 방법

​Helm을 사용한 W&B Kubernetes Operator

​인프라 프로비저닝

​사이징

​Kubernetes 사이징

​MySQL 사이징

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

시작하기 전에

인프라

애플리케이션 계층

저장소 계층

인프라 요구 사항

Kubernetes

MySQL

MySQL 토폴로지

MySQL 데이터베이스 생성

MySQL 설정 매개변수

Redis

오브젝트 저장소

버전

네트워킹

DNS

로드 밸런서 및 ingress

Ingress 컨트롤러 요구 사항

W&B 서비스 라우팅

ingress 설정 예시

SSL/TLS

지원되는 CPU 아키텍처

배포 방법

Helm을 사용한 W&B Kubernetes Operator

인프라 프로비저닝

사이징

Kubernetes 사이징

MySQL 사이징

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