이 페이지에서는 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 클러스터 세부 정보, MySQL, Redis, 객체 저장소, 소프트웨어 버전, 네트워킹, DNS, 로드 밸런서 및 인그레스, SSL/TLS, 지원되는 CPU 아키텍처 등 W&B 배포의 여러 측면에 대한 요구 사항을 설명합니다.
W&B Server 애플리케이션은 여러 파드를 배포하는 Kubernetes Operator 형태로 배포됩니다. 따라서 W&B를 사용하려면 다음 요건을 갖춘 Kubernetes 클러스터가 필요합니다.
- 완전히 설정되어 정상적으로 작동하는 인그레스 컨트롤러
- Persistent Volume을 프로비저닝할 수 있는 기능
W&B는 클라우드, 온프레미스, 폐쇄망 환경의 OpenShift Kubernetes 클러스터 배포를 지원합니다. 구체적인 설정 지침은 Operator 가이드의 OpenShift 섹션을 참조하세요.
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 배포를 구성할 것을 권장합니다.
프로덕션 환경에서는 클라우드 제공업체가 장애 조치, 백업, 패치를 처리하므로, 관리형 MySQL 서비스를 사용하는 것이 고가용성을 구현하는 가장 간단한 방법입니다. 예를 들어 AWS에서는 클라우드 제공업체의 고가용성 옵션인 Aurora Multi-AZ를 사용하세요.
직접 관리하는 MySQL을 실행하는 경우, 실시간 복제 스트림을 수신하고 장애 발생 시 장애 조치를 인계할 수 있는 핫 스탠바이가 있는 프라이머리 데이터베이스를 사용하세요. W&B는 애플리케이션 데이터베이스에 대해 멀티 마스터 토폴로지나 읽기 전용 복제본을 지원하지 않습니다.
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
| 소프트웨어 | 최소 버전 |
|---|
| 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 |
배포 설정에 따라 추가 container registry가 필요할 수 있습니다:
- Weave 온라인 평가를 위해 Bufstream 및 etcd를 배포할 때는
https://gcr.io가 필요합니다.
IngressClass를 사용할 수 있어야 합니다. 일반적인 인그레스 컨트롤러 옵션은 다음과 같습니다.
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 서비스(활성화된 경우) |
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가 설정되어 있는지 확인하세요.
권장: Helm과 함께 W&B Kubernetes Operator 사용
- W&B 컴포넌트의 자동 업데이트 및 관리
- 간소화된 설정 및 배포
- 모든 배포 시나리오 지원(클라우드, 온프레미스, 폐쇄망 환경)
자세한 설치 지침은 다음 문서를 참조하세요.
Terraform은 W&B 프로덕션 deployment를 위한 인프라를 프로비저닝하는 데 권장되는 방법입니다. Terraform을 사용하면 필요한 리소스와 다른 리소스를 참조하는 방식, 그리고 리소스 간 의존성을 정의할 수 있습니다. W&B는 주요 클라우드 제공업체용 Terraform 모듈을 제공합니다. 자세한 내용은 Self-Managed 클라우드 계정 내에 W&B Server 배포을 참고하세요.
배포를 계획할 때는 다음의 일반 지침을 출발점으로 삼으세요. W&B는 새 배포의 모든 컴포넌트를 면밀히 모니터링하고, 관찰된 사용 패턴에 따라 조정할 것을 권장합니다. 시간 경과에 따라 프로덕션 배포도 계속 모니터링하고, 최적의 성능을 유지할 수 있도록 필요에 따라 조정하세요.
용량을 계획할 때는 두 가지 핵심 컴포넌트의 규모를 산정합니다. 하나는 W&B Operator 워크로드용 Kubernetes 클러스터이고, 다른 하나는 메타데이터용 MySQL 데이터베이스입니다. 권장 사항은 환경(Test/Dev 또는 Production)에 따라 달라지며, Kubernetes의 경우에는 제품 구성(Models only, Weave only 또는 Models and Weave)에 따라서도 달라집니다. W&B는 Test/Dev와 Production 모두 최소 3개의 worker node로 시작하고, Production에서는 cluster autoscaling을 활성화할 것을 권장합니다.
Models only
Weave only
Models 및 Weave
| 환경 | CPU | 메모리 | 디스크 |
|---|
| Test/Dev | 2 코어 | 16 GB | 100 GB |
| 프로덕션 | 8 코어 | 64 GB | 100 GB |
| 환경 | CPU | 메모리 | 디스크 |
|---|
| Test/Dev | 4 코어 | 32 GB | 100 GB |
| 프로덕션 | 12 코어 | 96 GB | 100 GB |
| 환경 | CPU | 메모리 | 디스크 |
|---|
| Test/Dev | 4 코어 | 32 GB | 100 GB |
| 프로덕션 | 16 코어 | 128 GB | 100 GB |
| 환경 | CPU | 메모리 | 디스크 |
|---|
| Test/Dev | 2 코어 | 16 GB | 100 GB |
| 프로덕션 | 8 코어 | 64 GB | 500 GB |
권장 관리형 서비스
- Kubernetes: Amazon EKS
- MySQL: Amazon RDS Aurora
- 객체 저장소: Amazon S3
| 환경 | 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 |
권장 관리형 서비스
- Kubernetes: Google Kubernetes Engine (GKE)
- MySQL: Google Cloud SQL for MySQL
- 객체 저장소: Google Cloud Storage (GCS)
| 환경 | 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 |
권장 관리형 서비스
- Kubernetes: Azure Kubernetes Service (AKS)
- MySQL: Azure Database for MySQL
- 객체 저장소: Azure Blob Storage
| 환경 | 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 |
