> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-docs-sandboxes-integrations-placement.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 레퍼런스 아키텍처 > Kubernetes, MySQL, 객체 저장소 및 네트워킹을 포괄하는 Self-Managed W&B 배포용 레퍼런스 아키텍처를 검토하세요. 이 페이지에서는 W\&B 배포를 위한 레퍼런스 아키텍처를 설명하고, 플랫폼의 프로덕션 배포를 지원하기 위해 권장되는 인프라와 리소스를 간략히 설명합니다. 신뢰할 수 있는 Self-Managed 설치에 필요한 컴포넌트의 규모를 산정하고, 프로비저닝하고, 통합하기 위한 계획 가이드로 활용하세요. 이 페이지는 자체 인프라에서 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](/ko/platform/hosting/hosting-options/multi_tenant_cloud) 및 [W\&B Dedicated Cloud](/ko/platform/hosting/hosting-options/dedicated-cloud)를 참고하세요.
## 인프라
W\&B 배포 환경은 애플리케이션 계층과 저장소 계층으로 구성됩니다. 다음 다이어그램은 이러한 계층이 서로 어떻게 맞물리는지 보여주며, 이어지는 하위 섹션에서는 각 계층을 설명합니다. W&B 인프라 다이어그램
### 애플리케이션 계층
애플리케이션 계층은 노드 장애에도 견딜 수 있는 다중 노드 Kubernetes 클러스터로 구성됩니다. Kubernetes 클러스터는 W\&B 파드를 실행하고 관리합니다.
### 저장소 계층
저장소 계층은 MySQL 데이터베이스와 객체 저장소로 구성됩니다. MySQL 데이터베이스는 메타데이터를 저장하고, 객체 저장소는 모델 및 데이터셋과 같은 아티팩트를 저장합니다.
## 인프라 요구 사항
다음 섹션에서는 Kubernetes 클러스터 세부 정보, MySQL, Redis, 객체 저장소, 소프트웨어 버전, 네트워킹, DNS, 로드 밸런서 및 인그레스, SSL/TLS, 지원되는 CPU 아키텍처를 포함한 W\&B 배포에 대한 요구 사항을 설명합니다. 배포를 시작하기 전에 환경이 이러한 각 요구 사항을 충족하는지 확인하세요.
### Kubernetes
W\&B는 여러 파드를 배포하는 [Kubernetes Operator](/ko/platform/hosting/self-managed/operator) 형태로 W\&B Server 애플리케이션을 배포합니다. 따라서 W\&B를 사용하려면 다음 요건을 갖춘 Kubernetes 클러스터가 필요합니다. * 완전히 설정되어 정상적으로 작동하는 인그레스 컨트롤러 * Persistent Volume을 프로비저닝할 수 있는 기능 W\&B는 클라우드, 온프레미스, 폐쇄망 환경의 [OpenShift Kubernetes 클러스터](https://www.redhat.com/en/technologies/cloud-computing/openshift) 배포를 지원합니다. 구체적인 설정 지침은 Operator 가이드의 [OpenShift 섹션](/ko/platform/hosting/self-managed/operator#openshift-kubernetes-clusters)을 참조하세요.
### MySQL
MySQL 8.0.x는 2026년 4월에 수명 주기가 종료됩니다. W\&B 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 릴리스를 기준으로 플랫폼을 검증했습니다. 아직 MySQL 8.0.x를 사용 중이라면 [Upgrade MySQL to 8.4.x](/ko/platform/hosting/self-managed/operator#upgrade-mysql-to-84x)의 단계를 따라 업그레이드를 계획하세요. 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는 별도 머신에 핫 스탠바이 배포를 구성할 것을 권장합니다. standby는 기본 배포의 모든 업데이트를 실시간으로 스트리밍하며, 기본 서버가 충돌하거나 손상되거나 장시간 다운타임이 발생할 경우 장애 조치할 준비가 되어 있습니다.
#### MySQL 토폴로지
프로덕션 환경에서는 클라우드 제공업체가 장애 조치, 백업, 패치를 처리하므로, 관리형 MySQL 서비스를 사용하는 것이 고가용성을 구현하는 가장 간단한 방법입니다. 예를 들어 AWS에서는 클라우드 제공업체의 고가용성 옵션인 Aurora Multi-AZ를 사용하세요. 직접 관리하는 MySQL을 실행하는 경우, 실시간 복제 스트림을 수신하고 장애 발생 시 장애 조치를 인계할 수 있는 핫 스탠바이가 있는 프라이머리 데이터베이스를 사용하세요. W\&B는 애플리케이션 데이터베이스에 대해 멀티 프라이머리 토폴로지나 읽기 전용 복제본을 지원하지 않습니다.
#### MySQL 데이터베이스 생성
MySQL 데이터베이스와 사용자를 수동으로 생성하는 방법은 [베어메탈 가이드의 MySQL 데이터베이스 섹션](/ko/platform/hosting/self-managed/operator#mysql-database)을 참조하세요.
#### MySQL 설정 매개변수
이 매개변수는 W\&B가 대규모로 수행하는 쓰기 패턴과 스키마 변경에 맞게 MySQL을 최적화합니다. MySQL 인스턴스를 직접 운영하는 경우 다음과 같이 MySQL을 설정하세요: ```ini theme={null} 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](https://aws.amazon.com/elasticache/). * [Google Cloud Memory Store](https://cloud.google.com/memorystore?hl=en). * [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache). * 클라우드 또는 온프레미스 인프라에서 호스팅되는 Redis 배포.
### 객체 저장소
W\&B를 사용하려면 사전 서명된 URL과 CORS를 지원하는 객체 저장소가 필요하며, 다음 중 하나에 배포해야 합니다: * [CoreWeave AI Object Storage](https://docs.coreweave.com/products/storage/object-storage)는 AI 워크로드에 최적화된 S3 호환 객체 저장소 서비스입니다. * [Amazon S3](https://aws.amazon.com/s3/)는 확장성, 데이터 가용성, 보안, 성능을 제공하는 객체 저장소 서비스입니다. * [Google Cloud Storage](https://cloud.google.com/storage)는 비정형 데이터를 대규모로 저장할 수 있는 관리형 서비스입니다. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs)는 텍스트, 바이너리 데이터, 이미지, 비디오, 로그와 같은 비정형 데이터를 저장하기 위한 클라우드 기반 객체 저장소 솔루션입니다. * [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor), [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) 또는 클라우드나 온프레미스 인프라에 호스팅되는 기타 엔터프라이즈급 솔루션과 같은 S3 호환 저장소.
### 버전
| 소프트웨어 | 최소 버전 | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Kubernetes | v1.34 이상 ([지원되는 Kubernetes 버전](https://kubernetes.io/releases/patch-releases/)) | | Helm | v3.x | | MySQL | W\&B Self-Managed 배포에서는 보안 패치와 중요한 버그 수정이 제공되는 지원되는 MySQL 버전을 실행해야 합니다. **MySQL 8.4.x**를 설치하거나 업그레이드하세요. 또는 공급자가 지원되며 패치가 적용된 것으로 문서화한 관리형 서비스 버전을 사용하세요.
Aurora MySQL 버전 string은 커뮤니티 MySQL 버전과 다릅니다. 전체 엔진 버전 string을 보려면 `SELECT version()`을 사용하고, Aurora 버전을 보려면 `SELECT aurora_version()`을 사용하세요. [Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html)는 MySQL 8.0.x와 호환되며 계속 지원됩니다. 대상 버전을 선택할 때는 [Amazon Aurora versioning](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.Versioning.html) 및 클라우드 제공업체 문서를 참조하세요. | | Redis | v7.x |
### 네트워킹
네트워크에 연결된 배포 환경에서는 설치 중과 런타임 중 *모두* 다음 endpoint로의 아웃바운드 연결을 허용하세요: * `https://deploy.wandb.ai` * `https://charts.wandb.ai` * `https://quay.io` (Prometheus 이미지에 사용) 추가 container registry가 배포 설정에 따라 필요할 수 있습니다: * Weave 온라인 평가를 위해 Bufstream 및 etcd를 배포하는 경우 `https://gcr.io` air-gapped 배포에 대해 알아보려면 [air-gapped 인스턴스용 Kubernetes operator](/ko/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped)를 참고하세요. 트레이닝 인프라와 각 실험 추적 시스템에 W\&B 및 객체 저장소에 대한 액세스 권한을 부여하세요.
### DNS
W\&B 배포 환경의 정규화된 도메인 이름(FQDN)은 `A` 레코드를 통해 인그레스 또는 로드 밸런서의 IP 주소로 해석되어야 합니다.
### 로드 밸런서 및 인그레스
W\&B Kubernetes Operator는 Kubernetes 인그레스 컨트롤러를 사용해 서비스를 외부에 노출할 수 있으며, 이 컨트롤러는 서로 다른 포트를 사용하는 URL 경로에 따라 서비스 엔드포인트로 라우팅합니다. 인그레스 컨트롤러는 머신 러닝 워크로드를 실행하거나 웹 브라우저를 통해 서비스에 접속하는 모든 머신에서 접근할 수 있어야 합니다.
#### 인그레스 컨트롤러 요구 사항
Kubernetes 클러스터에서 `IngressClass`를 사용할 수 있어야 합니다. 일반적인 인그레스 컨트롤러 옵션은 다음과 같습니다. * [Nginx Ingress Controller](https://kubernetes.github.io/ingress-nginx/). * [Istio](https://istio.io). * [Traefik](https://traefik.io/). * 클라우드 제공업체 인그레스 컨트롤러(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가 생성한 인그레스 리소스의 예입니다: ```yaml theme={null} 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](https://letsencrypt.org)와 같은 서비스를 사용해 로드 밸런서에 신뢰할 수 있는 인증서를 제공하세요. Caddy 및 Cloudflare와 같은 서비스는 SSL을 대신 관리해 줍니다. 보안 정책상 신뢰할 수 있는 네트워크 내부에서도 SSL 통신이 필요하다면, Istio와 [사이드카 컨테이너](https://istio.io/latest/docs/reference/config/networking/sidecar/) 같은 도구를 사용하는 것을 고려하세요.
### 지원되는 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 배포](/ko/platform/hosting/self-managed/operator) - 기본 설치 가이드. * [폐쇄망 인스턴스를 위한 Kubernetes Operator](/ko/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) - 외부와 분리된 환경용.
### 인프라 프로비저닝
Terraform은 W\&B 프로덕션 deployment를 위한 인프라를 프로비저닝하는 데 권장되는 방법입니다. Terraform을 사용하면 필요한 리소스와 다른 리소스를 참조하는 방식, 그리고 리소스 간 의존성을 정의할 수 있습니다. W\&B는 주요 클라우드 제공업체용 Terraform 모듈을 제공합니다. 자세한 내용은 [Self-Managed 클라우드 계정 내에 W\&B Server 배포](/ko/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-Self-Managed-cloud-accounts)을 참고하세요.
## 사이징
배포를 계획할 때는 다음 지침을 출발점으로 삼으세요. W\&B는 배포의 모든 컴포넌트를 면밀히 모니터링하고, 관찰된 사용 패턴에 따라 조정할 것을 권장합니다. 시간 경과에 따라 프로덕션 배포도 계속 모니터링하고, 성능을 유지할 수 있도록 필요에 따라 조정하세요. 용량을 계획할 때는 두 가지 핵심 컴포넌트의 규모를 산정합니다. 하나는 W\&B Operator 워크로드용 Kubernetes 클러스터이고, 다른 하나는 메타데이터용 MySQL 데이터베이스입니다. 권장 사항은 **환경**(Test/Dev 또는 프로덕션)에 따라 달라지며, Kubernetes의 경우에는 **제품 구성**(Models only, Weave only 또는 Models and Weave)에 따라서도 달라집니다. W\&B는 Test/Dev와 프로덕션 모두 최소 3개의 워커 노드로 시작하고, 프로덕션에서는 cluster autoscaling을 활성화할 것을 권장합니다. 다음 섹션에서는 Kubernetes 클러스터와 MySQL 데이터베이스에 대한 노드별 용량 산정 권장 사항을 제공합니다.
### Kubernetes 사이징
| 환경 | CPU | 메모리 | 디스크 | | -------- | ---- | ----- | ------ | | Test/Dev | 2 코어 | 16 GB | 100 GB | | 프로덕션 | 8 코어 | 64 GB | 100 GB | 수치는 Kubernetes 워커 노드당 기준입니다. | 환경 | CPU | 메모리 | 디스크 | | -------- | ----- | ----- | ------ | | Test/Dev | 4 코어 | 32 GB | 100 GB | | 프로덕션 | 12 코어 | 96 GB | 100 GB | 수치는 Kubernetes 워커 노드당 기준입니다. | 환경 | CPU | 메모리 | 디스크 | | -------- | ----- | ------ | ------ | | Test/Dev | 4 코어 | 32 GB | 100 GB | | 프로덕션 | 16 코어 | 128 GB | 100 GB | 수치는 Kubernetes 워커 노드당 기준입니다.
### MySQL 사이징
이 권장 사항은 제품 구성에 따라 달라지지 않습니다. 토폴로지 및 가용성에 대한 지침은 [MySQL](#mysql) 아래의 [MySQL topology](#mysql-topology)를 참조하세요. | 환경 | CPU | 메모리 | 디스크 | | -------- | ---- | ----- | ------ | | Test/Dev | 2 코어 | 16 GB | 100 GB | | 프로덕션 | 8 코어 | 64 GB | 500 GB | 수치는 MySQL 노드당 기준입니다.
## 클라우드 제공업체 인스턴스 권장 사항
이전 크기 조정 표에서 노드별 CPU, 메모리, 디스크 요구 사항을 확인한 후, 다음 권장 사항을 참고하여 해당 요구 사항을 충족하는 구체적인 클라우드 제공업체 인스턴스 유형과 관리형 서비스를 선택하세요. 이 권장 사항은 클라우드 인프라에서 실행되는 W\&B Self-Managed 배포의 각 노드에 적용됩니다. **권장 관리형 서비스** * **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 |