Set up Launch

• 1: Configure launch queue
• 2: Set up launch agent
• 3: Tutorial: Set up W&B Launch on Kubernetes
• 4: Tutorial: Set up W&B Launch on SageMaker
• 5: Tutorial: Set up W&B Launch on Vertex AI
• 6: Tutorial: Set up W&B Launch with Docker

이 페이지는 W&B Launch 설정에 필요한 개략적인 단계를 설명합니다.

1. 대기열 설정: 대기열은 FIFO이며 대기열 설정을 갖습니다. 대기열의 설정은 대상 리소스에서 작업이 실행되는 위치와 방법을 제어합니다.
2. 에이전트 설정: 에이전트는 사용자 시스템/인프라에서 실행되며 Launch 작업을 위해 하나 이상의 대기열을 폴링합니다. 작업이 풀되면 에이전트는 이미지가 빌드되어 사용 가능한지 확인합니다. 그런 다음 에이전트는 작업을 대상 리소스에 제출합니다.

대기열 설정

Launch 대기열은 특정 대상 리소스를 가리키도록 구성해야 하며, 해당 리소스에 특정한 추가 구성도 함께 설정해야 합니다. 예를 들어 Kubernetes 클러스터를 가리키는 Launch 대기열은 환경 변수를 포함하거나 Launch 대기열 구성에 사용자 정의 네임스페이스를 설정할 수 있습니다. 대기열을 생성할 때 사용하려는 대상 리소스와 해당 리소스에 사용할 구성을 모두 지정합니다.

에이전트가 대기열에서 작업을 받으면 대기열 구성도 함께 받습니다. 에이전트가 작업을 대상 리소스에 제출할 때 작업 자체의 재정의와 함께 대기열 구성을 포함합니다. 예를 들어 작업 구성을 사용하여 해당 작업 인스턴스에 대해서만 Amazon SageMaker 인스턴스 유형을 지정할 수 있습니다. 이 경우 대기열 구성 템플릿이 최종 사용자 인터페이스로 사용되는 것이 일반적입니다.

대기열 생성

1. wandb.ai/launch에서 Launch App으로 이동합니다.
2. 화면 오른쪽 상단의 대기열 생성 버튼을 클릭합니다.

3. Entity 드롭다운 메뉴에서 대기열이 속할 Entity를 선택합니다.
4. 대기열 필드에 대기열 이름을 입력합니다.
5. 리소스 드롭다운에서 이 대기열에 추가할 작업에 사용할 컴퓨팅 리소스를 선택합니다.
6. 이 대기열에 대해 우선 순위 지정을 허용할지 여부를 선택합니다. 우선 순위 지정이 활성화되면 팀의 사용자가 작업을 대기열에 추가할 때 Launch 작업의 우선 순위를 정의할 수 있습니다. 우선 순위가 높은 작업은 우선 순위가 낮은 작업보다 먼저 실행됩니다.
7. 구성 필드에 JSON 또는 YAML 형식으로 리소스 구성을 제공합니다. 구성 문서의 구조와 의미는 대기열이 가리키는 리소스 유형에 따라 달라집니다. 자세한 내용은 대상 리소스에 대한 전용 설정 페이지를 참조하십시오.

Launch 에이전트 설정

Launch 에이전트는 하나 이상의 Launch 대기열에서 작업을 폴링하는 장기 실행 프로세스입니다. Launch 에이전트는 선입선출(FIFO) 순서 또는 대기열에서 가져오는 우선 순위에 따라 작업을 디큐합니다. 에이전트가 대기열에서 작업을 디큐하면 해당 작업에 대한 이미지를 선택적으로 빌드합니다. 그런 다음 에이전트는 대기열 구성에 지정된 구성 옵션과 함께 작업을 대상 리소스에 제출합니다.

에이전트는 매우 유연하며 다양한 유스 케이스를 지원하도록 구성할 수 있습니다. 에이전트에 필요한 구성은 특정 유스 케이스에 따라 달라집니다. Docker, Amazon SageMaker, Kubernetes 또는 Vertex AI에 대한 전용 페이지를 참조하십시오.

W&B는 특정 사용자의 API 키 대신 서비스 계정의 API 키로 에이전트를 시작하는 것이 좋습니다. 서비스 계정의 API 키를 사용하면 다음과 같은 두 가지 이점이 있습니다.

1. 에이전트는 개별 사용자에 의존하지 않습니다.
2. Launch를 통해 생성된 run과 연결된 작성자는 에이전트와 연결된 사용자가 아닌 Launch 작업을 제출한 사용자로 Launch에서 간주합니다.

에이전트 구성

launch-config.yaml이라는 YAML 파일로 Launch 에이전트를 구성합니다. 기본적으로 W&B는 ~/.config/wandb/launch-config.yaml에서 구성 파일을 확인합니다. Launch 에이전트를 활성화할 때 다른 디렉토리를 선택적으로 지정할 수 있습니다.

Launch 에이전트의 구성 파일 내용은 Launch 에이전트의 환경, Launch 대기열의 대상 리소스, Docker 빌더 요구 사항, 클라우드 레지스트리 요구 사항 등에 따라 달라집니다.

유스 케이스와 관계없이 Launch 에이전트에 대한 핵심 구성 가능 옵션은 다음과 같습니다.

• max_jobs: 에이전트가 병렬로 실행할 수 있는 최대 작업 수
• entity: 대기열이 속한 Entity
• queues: 에이전트가 감시할 하나 이상의 대기열 이름

W&B CLI를 사용하여 Launch 에이전트에 대한 보편적인 구성 가능 옵션(구성 YAML 파일 대신)을 지정할 수 있습니다. 최대 작업 수, W&B Entity 및 Launch 대기열을 참조하십시오. 자세한 내용은 wandb launch-agent 명령을 참조하십시오.

다음 YAML 코드 조각은 핵심 Launch 에이전트 구성 키를 지정하는 방법을 보여줍니다.

# 수행할 동시 run의 최대 수입니다. -1 = 제한 없음
max_jobs: -1

entity: <entity-name>

# 폴링할 대기열 목록입니다.
queues:
  - <queue-name>

컨테이너 빌더 구성

Launch 에이전트는 이미지를 빌드하도록 구성할 수 있습니다. git 리포지토리 또는 코드 Artifacts에서 생성된 Launch 작업을 사용하려면 컨테이너 빌더를 사용하도록 에이전트를 구성해야 합니다. Launch 작업 생성 방법에 대한 자세한 내용은 Launch 작업 생성을 참조하십시오.

W&B Launch는 세 가지 빌더 옵션을 지원합니다.

• Docker: Docker 빌더는 로컬 Docker 데몬을 사용하여 이미지를 빌드합니다.
• Kaniko: Kaniko는 Docker 데몬을 사용할 수 없는 환경에서 이미지 빌드를 가능하게 하는 Google 프로젝트입니다.
• Noop: 에이전트는 작업을 빌드하려고 시도하지 않고 미리 빌드된 이미지만 가져옵니다.

에이전트가 Docker 데몬을 사용할 수 없는 환경(예: Kubernetes 클러스터)에서 폴링하는 경우 Kaniko 빌더를 사용하십시오.

Kaniko 빌더에 대한 자세한 내용은 Kubernetes 설정을 참조하십시오.

이미지 빌더를 지정하려면 에이전트 구성에 빌더 키를 포함하십시오. 예를 들어 다음 코드 조각은 Docker 또는 Kaniko를 사용하도록 지정하는 Launch 구성(launch-config.yaml)의 일부를 보여줍니다.

builder:
  type: docker | kaniko | noop

컨테이너 레지스트리 구성

경우에 따라 Launch 에이전트를 클라우드 레지스트리에 연결할 수 있습니다. Launch 에이전트를 클라우드 레지스트리에 연결하려는 일반적인 시나리오는 다음과 같습니다.

• 강력한 워크스테이션 또는 클러스터와 같이 빌드한 환경 이외의 환경에서 작업을 실행하려는 경우.
• 에이전트를 사용하여 이미지를 빌드하고 이러한 이미지를 Amazon SageMaker 또는 VertexAI에서 실행하려는 경우.
• Launch 에이전트가 이미지 리포지토리에서 가져오기 위한 자격 증명을 제공하도록 하려는 경우.

에이전트가 컨테이너 레지스트리와 상호 작용하도록 구성하는 방법에 대한 자세한 내용은 고급 에이전트 설정 페이지를 참조하십시오.

Launch 에이전트 활성화

launch-agent W&B CLI 명령으로 Launch 에이전트를 활성화합니다.

wandb launch-agent -q <queue-1> -q <queue-2> --max-jobs 5

일부 유스 케이스에서는 Kubernetes 클러스터 내에서 Launch 에이전트가 대기열을 폴링하도록 할 수 있습니다. 자세한 내용은 고급 대기열 설정 페이지를 참조하십시오.

1 - Configure launch queue

다음 페이지에서는 Launch Queue 옵션을 구성하는 방법을 설명합니다.

Queue Config 템플릿 설정

Queue Config 템플릿으로 컴퓨팅 소비에 대한 안전 장치를 관리하세요. 메모리 소비, GPU, 런타임 지속 시간과 같은 필드에 대한 기본값, 최소값 및 최대값을 설정합니다.

Config 템플릿으로 Queue를 구성한 후에는 팀 구성원이 지정한 범위 내에서만 정의한 필드를 변경할 수 있습니다.

Queue 템플릿 구성

기존 Queue에서 Queue 템플릿을 구성하거나 새 Queue를 만들 수 있습니다.

1. https://wandb.ai/launch의 Launch App으로 이동합니다.
2. 템플릿을 추가할 Queue 이름 옆에 있는 Queue 보기를 선택합니다.
3. Config 탭을 선택합니다. 그러면 Queue 생성 시기, Queue Config, 기존 Launch 시 재정의와 같은 Queue에 대한 정보가 표시됩니다.
4. Queue Config 섹션으로 이동합니다.
5. 템플릿을 만들 Config 키-값을 식별합니다.
6. Config의 값을 템플릿 필드로 바꿉니다. 템플릿 필드는 {{variable-name}} 형식을 취합니다.
7. 구성 파싱 버튼을 클릭합니다. 구성을 파싱하면 W&B에서 생성한 각 템플릿에 대해 Queue Config 아래에 타일을 자동으로 만듭니다.
8. 생성된 각 타일에 대해 먼저 Queue Config에서 허용할 수 있는 데이터 유형(문자열, 정수 또는 부동 소수점)을 지정해야 합니다. 이렇게 하려면 유형 드롭다운 메뉴에서 데이터 유형을 선택합니다.
9. 데이터 유형에 따라 각 타일에 나타나는 필드를 완성합니다.
10. Config 저장을 클릭합니다.

예를 들어 팀에서 사용할 수 있는 AWS 인스턴스를 제한하는 템플릿을 만들려고 한다고 가정합니다. 템플릿 필드를 추가하기 전에 Queue Config는 다음과 유사하게 보일 수 있습니다.

RoleArn: arn:aws:iam:region:account-id:resource-type/resource-id
ResourceConfig:
  InstanceType: ml.m4.xlarge
  InstanceCount: 1
  VolumeSizeInGB: 2
OutputDataConfig:
  S3OutputPath: s3://bucketname
StoppingCondition:
  MaxRuntimeInSeconds: 3600

InstanceType에 대한 템플릿 필드를 추가하면 Config는 다음과 같이 표시됩니다.

RoleArn: arn:aws:iam:region:account-id:resource-type/resource-id
ResourceConfig:
  InstanceType: "{{aws_instance}}"
  InstanceCount: 1
  VolumeSizeInGB: 2
OutputDataConfig:
  S3OutputPath: s3://bucketname
StoppingCondition:
  MaxRuntimeInSeconds: 3600

다음으로 구성 파싱을 클릭합니다. aws-instance라는 새 타일이 Queue Config 아래에 나타납니다.

거기에서 유형 드롭다운에서 문자열을 데이터 유형으로 선택합니다. 그러면 사용자가 선택할 수 있는 값을 지정할 수 있는 필드가 채워집니다. 예를 들어 다음 이미지에서 팀의 관리자는 사용자가 선택할 수 있는 두 가지 다른 AWS 인스턴스 유형(ml.m4.xlarge 및 ml.p3.xlarge)을 구성했습니다.

Launch 작업을 동적으로 구성

Queue Config는 에이전트가 Queue에서 작업을 뺄 때 평가되는 매크로를 사용하여 동적으로 구성할 수 있습니다. 다음 매크로를 설정할 수 있습니다.

Launch 에이전트를 사용하여 가속기(GPU)에서 실행되는 이미지를 빌드합니다.

Launch를 사용하여 가속기 환경에서 실행되는 이미지를 빌드하는 경우 가속기 기본 이미지를 지정해야 할 수 있습니다.

이 가속기 기본 이미지는 다음 요구 사항을 충족해야 합니다.

• Debian 호환성(Launch Dockerfile은 apt-get을 사용하여 Python을 가져옴)
• 호환 가능한 CPU 및 GPU 하드웨어 명령어 세트(CUDA 버전이 사용하려는 GPU에서 지원되는지 확인)
• 제공하는 가속기 버전과 ML 알고리즘에 설치된 패키지 간의 호환성
• 하드웨어와의 호환성을 설정하기 위해 추가 단계가 필요한 설치된 패키지

TensorFlow와 함께 GPU를 사용하는 방법

TensorFlow가 GPU를 제대로 활용하는지 확인합니다. 이를 위해 Queue 리소스 구성에서 builder.accelerator.base_image 키에 대한 Docker 이미지와 해당 이미지 태그를 지정합니다.

예를 들어 tensorflow/tensorflow:latest-gpu 기본 이미지는 TensorFlow가 GPU를 제대로 사용하는지 확인합니다. 이는 Queue의 리소스 구성을 사용하여 구성할 수 있습니다.

다음 JSON 스니펫은 Queue Config에서 TensorFlow 기본 이미지를 지정하는 방법을 보여줍니다.

{
    "builder": {
        "accelerator": {
            "base_image": "tensorflow/tensorflow:latest-gpu"
        }
    }
}

2 - Set up launch agent

고급 에이전트 설정

본 가이드는 다양한 환경에서 컨테이너 이미지를 빌드하기 위해 W&B Launch 에이전트를 설정하는 방법에 대한 정보를 제공합니다.

빌더

Launch 에이전트는 Docker 또는 Kaniko를 사용하여 이미지를 빌드할 수 있습니다.

• Kaniko: 권한이 필요한 컨테이너로 빌드를 실행하지 않고 Kubernetes에서 컨테이너 이미지를 빌드합니다.
• Docker: 로컬에서 docker build 코맨드를 실행하여 컨테이너 이미지를 빌드합니다.

빌더 유형은 launch 에이전트 설정에서 builder.type 키를 docker, kaniko 또는 noop(빌드 해제)으로 설정하여 제어할 수 있습니다. 기본적으로 에이전트 helm chart는 builder.type을 noop로 설정합니다. builder 섹션의 추가 키는 빌드 프로세스를 구성하는 데 사용됩니다.

에이전트 설정에 빌더가 지정되지 않고 작동하는 docker CLI가 발견되면 에이전트는 기본적으로 Docker를 사용합니다. Docker를 사용할 수 없으면 에이전트는 기본적으로 noop를 사용합니다.

컨테이너 레지스트리에 푸시

Launch 에이전트는 빌드하는 모든 이미지에 고유한 소스 해시로 태그를 지정합니다. 에이전트는 builder.destination 키에 지정된 레지스트리에 이미지를 푸시합니다.

예를 들어, builder.destination 키가 my-registry.example.com/my-repository로 설정된 경우 에이전트는 이미지를 my-registry.example.com/my-repository:<source-hash>로 태그 지정하고 푸시합니다. 이미지가 레지스트리에 존재하면 빌드는 건너뜁니다.

에이전트 설정

Helm chart를 통해 에이전트를 배포하는 경우 에이전트 설정은 values.yaml 파일의 agentConfig 키에 제공되어야 합니다.

wandb launch-agent로 에이전트를 직접 호출하는 경우 --config 플래그를 사용하여 에이전트 설정을 YAML 파일 경로로 제공할 수 있습니다. 기본적으로 설정은 ~/.config/wandb/launch-config.yaml에서 로드됩니다.

launch 에이전트 설정(launch-config.yaml) 내에서 대상 리소스 환경의 이름과 environment 및 registry 키에 대한 컨테이너 레지스트리를 각각 제공합니다.

다음 탭은 환경 및 레지스트리를 기반으로 launch 에이전트를 구성하는 방법을 보여줍니다.

• AWS
• GCP
• Azure

environment:
  type: aws
  region: <aws-region>
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 ECR 리포지토리의 URI입니다.
  # region이 환경에 구성한 region과 일치하는지 확인하십시오.
  destination: <account-id>.ecr.<aws-region>.amazonaws.com/<repository-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 S3 버킷을 지정합니다.
  build-context-store: s3://<bucket-name>/<path>

environment:
  type: gcp
  region: <gcp-region>
  project: <gcp-project-id>
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 Artifact Registry 리포지토리 및 이미지 이름의 URI입니다.
  # region 및 프로젝트가 환경에 구성한 것과 일치하는지 확인하십시오.
  uri: <region>-docker.pkg.dev/<project-id>/<repository-name>/<image-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 GCS 버킷을 지정합니다.
  build-context-store: gs://<bucket-name>/<path>

environment:
  type: azure
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 Azure Container Registry 리포지토리의 URI입니다.
  destination: https://<registry-name>.azurecr.io/<repository-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 Azure Blob Storage 컨테이너를 지정합니다.
  build-context-store: https://<storage-account-name>.blob.core.windows.net/<container-name>

에이전트 권한

필요한 에이전트 권한은 유스 케이스에 따라 다릅니다.

클라우드 레지스트리 권한

다음은 클라우드 레지스트리와 상호 작용하기 위해 launch 에이전트에서 일반적으로 요구하는 권한입니다.

• AWS
• GCP
• Azure

{
  'Version': '2012-10-17',
  'Statement':
    [
      {
        'Effect': 'Allow',
        'Action':
          [
            'ecr:CreateRepository',
            'ecr:UploadLayerPart',
            'ecr:PutImage',
            'ecr:CompleteLayerUpload',
            'ecr:InitiateLayerUpload',
            'ecr:DescribeRepositories',
            'ecr:DescribeImages',
            'ecr:BatchCheckLayerAvailability',
            'ecr:BatchDeleteImage',
          ],
        'Resource': 'arn:aws:ecr:<region>:<account-id>:repository/<repository>',
      },
      {
        'Effect': 'Allow',
        'Action': 'ecr:GetAuthorizationToken',
        'Resource': '*',
      },
    ],
}

artifactregistry.dockerimages.list;
artifactregistry.repositories.downloadArtifacts;
artifactregistry.repositories.list;
artifactregistry.repositories.uploadArtifacts;

Kaniko의 스토리지 권한

에이전트가 Kaniko 빌더를 사용하는 경우 launch 에이전트는 클라우드 스토리지에 푸시할 수 있는 권한이 필요합니다. Kaniko는 빌드 job을 실행하는 pod 외부의 컨텍스트 저장소를 사용합니다.

• AWS
• GCP
• Azure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListObjectsInBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::<BUCKET-NAME>"]
    },
    {
      "Sid": "AllObjectActions",
      "Effect": "Allow",
      "Action": "s3:*Object",
      "Resource": ["arn:aws:s3:::<BUCKET-NAME>/*"]
    }
  ]
}

storage.buckets.get;
storage.objects.create;
storage.objects.delete;
storage.objects.get;

Kaniko 빌드 사용자 정의

에이전트 설정의 builder.kaniko-config 키에서 Kaniko job이 사용하는 Kubernetes Job 사양을 지정합니다. 예:

builder:
  type: kaniko
  build-context-store: <my-build-context-store>
  destination: <my-image-destination>
  build-job-name: wandb-image-build
  kaniko-config:
    spec:
      template:
        spec:
          containers:
          - args:
            - "--cache=false" # Args must be in the format "key=value"
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"

CoreWeave에 Launch 에이전트 배포

선택적으로 W&B Launch 에이전트를 CoreWeave Cloud 인프라에 배포합니다. CoreWeave는 GPU 가속 워크로드를 위해 특별히 구축된 클라우드 인프라입니다.

Launch 에이전트를 CoreWeave에 배포하는 방법에 대한 자세한 내용은 CoreWeave 설명서를 참조하세요.

3 - Tutorial: Set up W&B Launch on Kubernetes

W&B Launch 를 사용하여 ML 워크로드를 Kubernetes 클러스터로 푸시할 수 있습니다. 이를 통해 ML 엔지니어는 Kubernetes로 이미 관리하고 있는 리소스를 사용할 수 있는 간단한 인터페이스를 W&B 내에서 바로 이용할 수 있습니다.

W&B는 W&B가 관리하는 공식 Launch agent 이미지를 유지 관리하며, 이는 Helm chart를 통해 클러스터에 배포할 수 있습니다.

W&B는 Kaniko 빌더를 사용하여 Launch agent가 Kubernetes 클러스터에서 Docker 이미지를 빌드할 수 있도록 합니다. Launch agent용 Kaniko 설정 방법 또는 작업 빌드를 끄고 미리 빌드된 Docker 이미지만 사용하는 방법에 대한 자세한 내용은 고급 agent 설정을 참조하십시오.

Kubernetes용 대기열 설정

Kubernetes 대상 리소스에 대한 Launch 대기열 설정은 Kubernetes Job spec 또는 Kubernetes Custom Resource spec과 유사합니다.

Launch 대기열을 만들 때 Kubernetes 워크로드 리소스 spec의 모든 측면을 제어할 수 있습니다.

• Kubernetes job spec
• Custom resource spec

spec:
  template:
    spec:
      containers:
        - env:
            - name: MY_ENV_VAR
              value: some-value
          resources:
            requests:
              cpu: 1000m
              memory: 1Gi
metadata:
  labels:
    queue: k8s-test
namespace: wandb

kubernetes:
  kind: PyTorchJob
  spec:
    pytorchReplicaSpecs:
      Master:
        replicas: 1
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
      Worker:
        replicas: 2
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
    ttlSecondsAfterFinished: 600
  metadata:
    name: '${run_id}-pytorch-job'
  apiVersion: kubeflow.org/v1

보안상의 이유로 W&B는 지정되지 않은 경우 다음 리소스를 Launch 대기열에 삽입합니다.

• securityContext
• backOffLimit
• ttlSecondsAfterFinished

다음 YAML 스니펫은 이러한 값들이 Launch 대기열에 어떻게 나타나는지 보여줍니다.

spec:
  template:
    `backOffLimit`: 0
    ttlSecondsAfterFinished: 60
    securityContext:
      allowPrivilegeEscalation: False,
      capabilities:
        drop:
          - ALL,
      seccompProfile:
        type: "RuntimeDefault"

대기열 만들기

Kubernetes를 컴퓨팅 리소스로 사용하는 W&B App에서 대기열을 만듭니다.

1. Launch 페이지로 이동합니다.
2. 대기열 만들기 버튼을 클릭합니다.
3. 대기열을 만들려는 Entities를 선택합니다.
4. 이름 필드에 대기열 이름을 입력합니다.
5. 리소스로 Kubernetes를 선택합니다.
6. 설정 필드 내에서 이전 섹션에서 구성한 Kubernetes Job 워크플로우 spec 또는 Custom Resource spec을 제공합니다.

Helm으로 Launch agent 구성

W&B에서 제공하는 Helm chart를 사용하여 Launch agent를 Kubernetes 클러스터에 배포합니다. values.yaml 파일로 Launch agent의 행동을 제어합니다.

Launch agent 구성 파일(~/.config/wandb/launch-config.yaml)에 일반적으로 정의되는 내용을 values.yaml 파일의 launchConfig 키 내에 지정합니다.

예를 들어, Kaniko Docker 이미지 빌더를 사용하는 EKS에서 Launch agent를 실행할 수 있도록 하는 Launch agent 구성이 있다고 가정합니다.

queues:
	- <queue name>
max_jobs: <n concurrent jobs>
environment:
	type: aws
	region: us-east-1
registry:
	type: ecr
	uri: <my-registry-uri>
builder:
	type: kaniko
	build-context-store: <s3-bucket-uri>

values.yaml 파일 내에서 다음과 같이 보일 수 있습니다.

agent:
  labels: {}
  # W&B API 키.
  apiKey: ''
  # agent에 사용할 컨테이너 이미지.
  image: wandb/launch-agent:latest
  # agent 이미지에 대한 이미지 풀 정책.
  imagePullPolicy: Always
  # agent spec에 대한 리소스 블록.
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi

# Launch agent를 배포할 네임스페이스
namespace: wandb

# W&B api URL (여기에 설정하십시오)
baseUrl: https://api.wandb.ai

# Launch agent가 배포할 수 있는 추가 대상 네임스페이스
additionalTargetNamespaces:
  - default
  - wandb

# 이것은 Launch agent 구성의 리터럴 내용으로 설정해야 합니다.
launchConfig: |
  queues:
    - <queue name>
  max_jobs: <n concurrent jobs>
  environment:
    type: aws
    region: <aws-region>
  registry:
    type: ecr
    uri: <my-registry-uri>
  builder:
    type: kaniko
    build-context-store: <s3-bucket-uri>  

# git 자격 증명 파일의 내용. 이것은 k8s secret에 저장됩니다
# agent 컨테이너에 마운트됩니다. 비공개 리포를 복제하려면 이것을 설정하십시오.
gitCreds: |

# wandb 서비스 계정에 대한 어노테이션. gcp에서 워크로드 아이덴티티를 설정할 때 유용합니다.
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account:
    azure.workload.identity/client-id:

# azure와 함께 kaniko를 사용하는 경우 azure 스토리지에 대한 엑세스 키로 설정합니다.
azureStorageAccessKey: ''

레지스트리, 환경 및 필요한 agent 권한에 대한 자세한 내용은 고급 agent 설정을 참조하십시오.

4 - Tutorial: Set up W&B Launch on SageMaker

W&B Launch 를 사용하여 제공된 또는 사용자 지정 알고리즘을 사용하여 Amazon SageMaker 에 launch 작업을 제출하여 SageMaker 플랫폼에서 기계 학습 모델을 트레이닝할 수 있습니다. SageMaker 는 컴퓨팅 리소스를 가동 및 해제하는 작업을 처리하므로 EKS 클러스터가 없는 팀에게 적합한 선택이 될 수 있습니다.

Amazon SageMaker 에 연결된 W&B Launch 대기열로 전송된 Launch 작업은 CreateTrainingJob API를 통해 SageMaker 트레이닝 작업으로 실행됩니다. launch 대기열 설정을 사용하여 CreateTrainingJob API 로 전송되는 인수를 제어합니다.

Amazon SageMaker 는 Docker 이미지를 사용하여 트레이닝 작업을 실행합니다. SageMaker 가 가져오는 이미지는 Amazon Elastic Container Registry (ECR)에 저장해야 합니다. 즉, 트레이닝에 사용하는 이미지는 ECR 에 저장해야 합니다.

전제 조건

시작하기 전에 다음 전제 조건을 충족하는지 확인하십시오.

• Launch 에이전트가 Docker 이미지를 빌드하도록 할지 결정합니다.
• AWS 리소스를 설정하고 S3, ECR 및 Sagemaker IAM 역할에 대한 정보를 수집합니다.
• Launch 에이전트에 대한 IAM 역할을 만듭니다.

Launch 에이전트가 Docker 이미지를 빌드하도록 할지 결정

W&B Launch 에이전트가 Docker 이미지를 빌드하도록 할지 결정합니다. 다음 두 가지 옵션 중에서 선택할 수 있습니다.

• Launch 에이전트가 Docker 이미지를 빌드하고, 이미지를 Amazon ECR 에 푸시하고, 사용자를 위해 SageMaker 트레이닝 작업을 제출하도록 허용합니다. 이 옵션은 ML 엔지니어가 트레이닝 코드를 빠르게 반복하는 데 약간의 단순성을 제공할 수 있습니다.
• Launch 에이전트는 트레이닝 또는 추론 스크립트가 포함된 기존 Docker 이미지를 사용합니다. 이 옵션은 기존 CI 시스템과 잘 작동합니다. 이 옵션을 선택하는 경우 Docker 이미지를 Amazon ECR 의 컨테이너 레지스트리에 수동으로 업로드해야 합니다.

AWS 리소스 설정

선호하는 AWS 리전에서 다음 AWS 리소스가 구성되어 있는지 확인합니다.

1. 컨테이너 이미지를 저장할 ECR 레포지토리.
2. SageMaker 트레이닝 작업에 대한 입력 및 출력을 저장할 하나 이상의 S3 버킷.
3. SageMaker 가 트레이닝 작업을 실행하고 Amazon ECR 및 Amazon S3 와 상호 작용할 수 있도록 허용하는 Amazon SageMaker 에 대한 IAM 역할.

이러한 리소스에 대한 ARN 을 기록해 두십시오. Launch 대기열 설정을 정의할 때 ARN 이 필요합니다.

Launch 에이전트에 대한 IAM 정책 만들기

1. AWS 의 IAM 화면에서 새 정책을 만듭니다.
2. JSON 정책 편집기로 전환한 다음 사용 사례에 따라 다음 정책을 붙여넣습니다. <> 로 묶인 값을 자신의 값으로 대체합니다.

• 에이전트가 미리 빌드된 Docker 이미지 제출
• 에이전트가 Docker 이미지를 빌드하고 제출

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogStreams",
        "SageMaker:AddTags",
        "SageMaker:CreateTrainingJob",
        "SageMaker:DescribeTrainingJob"
      ],
      "Resource": "arn:aws:sagemaker:<region>:<account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<account-id>:role/<RoleArn-from-queue-config>"
    },
  {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "<ARN-OF-KMS-KEY>",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "SageMaker.<region>.amazonaws.com",
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogStreams",
        "SageMaker:AddTags",
        "SageMaker:CreateTrainingJob",
        "SageMaker:DescribeTrainingJob"
      ],
      "Resource": "arn:aws:sagemaker:<region>:<account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<account-id>:role/<RoleArn-from-queue-config>"
    },
     {
    "Effect": "Allow",
    "Action": [
      "ecr:CreateRepository",
      "ecr:UploadLayerPart",
      "ecr:PutImage",
      "ecr:CompleteLayerUpload",
      "ecr:InitiateLayerUpload",
      "ecr:DescribeRepositories",
      "ecr:DescribeImages",
      "ecr:BatchCheckLayerAvailability",
      "ecr:BatchDeleteImage"
    ],
    "Resource": "arn:aws:ecr:<region>:<account-id>:repository/<repository>"
  },
  {
    "Effect": "Allow",
    "Action": "ecr:GetAuthorizationToken",
    "Resource": "*"
  },
  {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "<ARN-OF-KMS-KEY>",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "SageMaker.<region>.amazonaws.com",
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

3. 다음을 클릭합니다.
4. 정책에 이름과 설명을 지정합니다.
5. 정책 생성을 클릭합니다.

Launch 에이전트에 대한 IAM 역할 만들기

Launch 에이전트는 Amazon SageMaker 트레이닝 작업을 생성할 수 있는 권한이 필요합니다. 아래 절차에 따라 IAM 역할을 만듭니다.

1. AWS 의 IAM 화면에서 새 역할을 만듭니다.
2. 신뢰할 수 있는 엔터티의 경우 AWS 계정(또는 조직의 정책에 적합한 다른 옵션)을 선택합니다.
3. 권한 화면을 스크롤하여 위에서 방금 만든 정책 이름을 선택합니다.
4. 역할에 이름과 설명을 지정합니다.
5. 역할 생성을 선택합니다.
6. 역할에 대한 ARN 을 기록해 둡니다. launch 에이전트를 설정할 때 ARN 을 지정합니다.

IAM 역할을 만드는 방법에 대한 자세한 내용은 AWS Identity and Access Management 설명서를 참조하십시오.

SageMaker 에 대한 Launch 대기열 구성

다음으로 SageMaker 를 컴퓨팅 리소스로 사용하는 W&B App 에서 대기열을 만듭니다.

1. Launch App으로 이동합니다.
2. 대기열 생성 버튼을 클릭합니다.
3. 대기열을 만들려는 Entities를 선택합니다.
4. 이름 필드에 대기열 이름을 제공합니다.
5. 리소스로 SageMaker 를 선택합니다.
6. 설정 필드 내에서 SageMaker 작업에 대한 정보를 제공합니다. 기본적으로 W&B 는 YAML 및 JSON CreateTrainingJob 요청 본문을 채웁니다.

{
  "RoleArn": "<REQUIRED>", 
  "ResourceConfig": {
      "InstanceType": "ml.m4.xlarge",
      "InstanceCount": 1,
      "VolumeSizeInGB": 2
  },
  "OutputDataConfig": {
      "S3OutputPath": "<REQUIRED>"
  },
  "StoppingCondition": {
      "MaxRuntimeInSeconds": 3600
  }
}

최소한 다음을 지정해야 합니다.

• RoleArn: SageMaker 실행 IAM 역할의 ARN ( 전제 조건 참조). launch 에이전트 IAM 역할과 혼동하지 마십시오.
• OutputDataConfig.S3OutputPath: SageMaker 출력이 저장될 Amazon S3 URI.
• ResourceConfig: 리소스 구성에 대한 필수 사양입니다. 리소스 구성에 대한 옵션은 여기에 설명되어 있습니다.
• StoppingCondition: 트레이닝 작업에 대한 중지 조건에 대한 필수 사양입니다. 옵션은 여기에 설명되어 있습니다.

7. 대기열 생성 버튼을 클릭합니다.

Launch 에이전트 설정

다음 섹션에서는 에이전트를 배포할 수 있는 위치와 배포 위치에 따라 에이전트를 구성하는 방법을 설명합니다.

Amazon SageMaker 에 대해 Launch 에이전트를 배포하는 방법에 대한 몇 가지 옵션이 있습니다. 대기열: 로컬 시스템, EC2 인스턴스 또는 EKS 클러스터에서. 에이전트를 배포하는 위치에 따라 Launch 에이전트를 적절하게 구성합니다.

Launch 에이전트를 실행할 위치 결정

프로덕션 워크로드 및 이미 EKS 클러스터가 있는 고객의 경우 W&B 는 이 Helm 차트를 사용하여 Launch 에이전트를 EKS 클러스터에 배포하는 것이 좋습니다.

현재 EKS 클러스터가 없는 프로덕션 워크로드의 경우 EC2 인스턴스가 좋은 옵션입니다. launch 에이전트 인스턴스가 항상 실행되지만 에이전트는 상대적으로 저렴한 t2.micro 크기의 EC2 인스턴스 이상이 필요하지 않습니다.

실험적 또는 단독 사용 사례의 경우 로컬 시스템에서 Launch 에이전트를 실행하는 것이 시작하는 빠른 방법이 될 수 있습니다.

사용 사례에 따라 다음 탭에 제공된 지침에 따라 Launch 에이전트를 올바르게 구성합니다.

• EKS
• EC2
• 로컬 시스템

sudo yum install python311 -y && python3 -m ensurepip --upgrade && pip3 install wandb && pip3 install wandb[launch]

sudo yum update -y && sudo yum install -y docker python3 && sudo systemctl start docker && sudo systemctl enable docker && sudo usermod -a -G docker ec2-user

newgrp docker

[profile SageMaker-agent]
role_arn = arn:aws:iam::<account-id>:role/<agent-role-name>
source_profile = default                                                                   

[default]
aws_access_key_id=<access-key-id>
aws_secret_access_key=<secret-access-key>
aws_session_token=<session-token>

Launch 에이전트 구성

launch-config.yaml 이라는 YAML 구성 파일로 launch 에이전트를 구성합니다.

기본적으로 W&B 는 ~/.config/wandb/launch-config.yaml 에서 구성 파일을 확인합니다. -c 플래그로 launch 에이전트를 활성화할 때 선택적으로 다른 디렉토리를 지정할 수 있습니다.

다음 YAML 스니펫은 핵심 구성 에이전트 옵션을 지정하는 방법을 보여줍니다.

max_jobs: -1
queues:
  - <queue-name>
environment:
  type: aws
  region: <your-region>
registry:
  type: ecr
  uri: <ecr-repo-arn>
builder: 
  type: docker

이제 wandb launch-agent 로 에이전트를 시작합니다.

(선택 사항) Launch 작업 Docker 이미지를 Amazon ECR 로 푸시

launch 작업이 포함된 Docker 이미지를 Amazon ECR 레포지토리로 업로드합니다. 이미지 기반 작업을 사용하는 경우 새 launch 작업을 제출하기 전에 Docker 이미지가 ECR 레지스트리에 있어야 합니다.

5 - Tutorial: Set up W&B Launch on Vertex AI

W&B Launch 를 사용하여 Vertex AI 트레이닝 작업으로 실행하기 위한 작업을 제출할 수 있습니다. Vertex AI 트레이닝 작업을 통해 Vertex AI 플랫폼에서 제공되거나 사용자 정의된 알고리즘을 사용하여 기계학습 모델을 트레이닝할 수 있습니다. Launch 작업이 시작되면 Vertex AI는 기본 인프라, 확장 및 오케스트레이션을 관리합니다.

W&B Launch 는 google-cloud-aiplatform SDK의 CustomJob 클래스를 통해 Vertex AI와 연동됩니다. CustomJob 의 파라미터는 Launch 대기열 설정으로 제어할 수 있습니다. Vertex AI는 GCP 외부의 개인 레지스트리에서 이미지를 가져오도록 구성할 수 없습니다. 즉, W&B Launch 와 함께 Vertex AI를 사용하려면 컨테이너 이미지를 GCP 또는 공용 레지스트리에 저장해야 합니다. Vertex 작업에 컨테이너 이미지를 엑세스할 수 있도록 설정하는 방법에 대한 자세한 내용은 Vertex AI 설명서를 참조하십시오.

전제 조건

1. Vertex AI API가 활성화된 GCP 프로젝트를 만들거나 엑세스합니다. API 활성화에 대한 자세한 내용은 GCP API Console 문서를 참조하십시오.
2. Vertex에서 실행하려는 이미지를 저장할 GCP Artifact Registry 저장소를 만듭니다. 자세한 내용은 GCP Artifact Registry 문서를 참조하십시오.
3. Vertex AI가 메타데이터를 저장할 스테이징 GCS 버킷을 만듭니다. 이 버킷은 스테이징 버킷으로 사용하려면 Vertex AI 워크로드와 동일한 리전에 있어야 합니다. 동일한 버킷을 스테이징 및 빌드 컨텍스트에 사용할 수 있습니다.
4. Vertex AI 작업을 시작하는 데 필요한 권한이 있는 서비스 계정을 만듭니다. 서비스 계정에 권한을 할당하는 방법에 대한 자세한 내용은 GCP IAM 문서를 참조하십시오.
5. Vertex 작업을 관리할 수 있는 권한을 서비스 계정에 부여합니다.

Vertex AI에 대한 대기열 구성

Vertex AI 리소스에 대한 대기열 구성은 Vertex AI Python SDK의 CustomJob 생성자와 CustomJob 의 run 메소드에 대한 입력을 지정합니다. 리소스 구성은 spec 및 run 키 아래에 저장됩니다.

• spec 키에는 Vertex AI Python SDK의 CustomJob 생성자의 명명된 인수에 대한 값이 포함되어 있습니다.
• run 키에는 Vertex AI Python SDK의 CustomJob 클래스의 run 메소드의 명명된 인수에 대한 값이 포함되어 있습니다.

실행 환경의 사용자 정의는 주로 spec.worker_pool_specs 목록에서 발생합니다. 작업자 풀 사양은 작업을 실행할 작업자 그룹을 정의합니다. 기본 구성의 작업자 사양은 가속기가 없는 단일 n1-standard-4 머신을 요청합니다. 필요에 따라 머신 유형, 가속기 유형 및 수를 변경할 수 있습니다.

사용 가능한 머신 유형 및 가속기 유형에 대한 자세한 내용은 Vertex AI 설명서를 참조하십시오.

대기열 만들기

Vertex AI를 컴퓨팅 리소스로 사용하는 W&B App 에서 대기열을 만듭니다.

1. Launch 페이지로 이동합니다.
2. 대기열 만들기 버튼을 클릭합니다.
3. 대기열을 만들려는 Entity 를 선택합니다.
4. 이름 필드에 대기열 이름을 입력합니다.
5. 리소스 로 GCP Vertex 를 선택합니다.
6. 설정 필드 내에서 이전 섹션에서 정의한 Vertex AI CustomJob 에 대한 정보를 제공합니다. 기본적으로 W&B는 다음과 유사한 YAML 및 JSON 요청 본문을 채웁니다.

spec:
  worker_pool_specs:
    - machine_spec:
        machine_type: n1-standard-4
        accelerator_type: ACCELERATOR_TYPE_UNSPECIFIED
        accelerator_count: 0
      replica_count: 1
      container_spec:
        image_uri: ${image_uri}
  staging_bucket: <REQUIRED>
run:
  restart_job_on_worker_restart: false

7. 대기열을 구성한 후 대기열 만들기 버튼을 클릭합니다.

최소한 다음을 지정해야 합니다.

• spec.worker_pool_specs : 비어 있지 않은 작업자 풀 사양 목록
• spec.staging_bucket : Vertex AI 자산 및 메타데이터를 스테이징하는 데 사용될 GCS 버킷

Launch 에이전트 구성

Launch 에이전트는 기본적으로 ~/.config/wandb/launch-config.yaml 에 있는 구성 파일을 통해 구성할 수 있습니다.

max_jobs: <n-concurrent-jobs>
queues:
  - <queue-name>

Launch 에이전트가 Vertex AI에서 실행되는 이미지를 빌드하도록 하려면 고급 에이전트 설정을 참조하십시오.

에이전트 권한 설정

이 서비스 계정으로 인증하는 방법은 여러 가지가 있습니다. 이는 Workload Identity, 다운로드된 서비스 계정 JSON, 환경 변수, Google Cloud Platform 코맨드라인 툴 또는 이러한 방법의 조합을 통해 수행할 수 있습니다.

6 - Tutorial: Set up W&B Launch with Docker

다음 가이드는 로컬 장치에서 Docker를 사용하도록 W&B Launch를 구성하여 Launch 에이전트 환경과 대기열의 대상 리소스 모두에 대해 설명합니다.

Docker를 사용하여 작업을 실행하고 동일한 로컬 장치에서 Launch 에이전트의 환경으로 사용하는 것은 컴퓨팅이 Kubernetes와 같은 클러스터 관리 시스템이 없는 장치에 설치된 경우에 특히 유용합니다.

Docker 대기열을 사용하여 강력한 워크스테이션에서 워크로드를 실행할 수도 있습니다.

W&B Launch와 함께 Docker를 사용하면 W&B는 먼저 이미지를 빌드한 다음 해당 이미지에서 컨테이너를 빌드하고 실행합니다. 이미지는 Docker docker run <image-uri> 코맨드로 빌드됩니다. 대기열 설정은 docker run 코맨드에 전달되는 추가 인수로 해석됩니다.

Docker 대기열 구성

Launch 대기열 설정(Docker 대상 리소스의 경우)은 docker run CLI 코맨드에 정의된 것과 동일한 옵션을 허용합니다.

에이전트는 대기열 설정에 정의된 옵션을 수신합니다. 그런 다음 에이전트는 수신된 옵션을 Launch 작업의 설정에서 가져온 재정의와 병합하여 대상 리소스(이 경우 로컬 장치)에서 실행되는 최종 docker run 코맨드를 생성합니다.

다음과 같은 두 가지 구문 변환이 수행됩니다.

1. 반복되는 옵션은 대기열 설정에 목록으로 정의됩니다.
2. 플래그 옵션은 대기열 설정에 값 true가 있는 부울로 정의됩니다.

예를 들어, 다음 대기열 설정은 다음과 같습니다.

{
  "env": ["MY_ENV_VAR=value", "MY_EXISTING_ENV_VAR"],
  "volume": "/mnt/datasets:/mnt/datasets",
  "rm": true,
  "gpus": "all"
}

다음과 같은 docker run 코맨드가 생성됩니다.

docker run \
  --env MY_ENV_VAR=value \
  --env MY_EXISTING_ENV_VAR \
  --volume "/mnt/datasets:/mnt/datasets" \
  --rm <image-uri> \
  --gpus all

볼륨은 문자열 목록 또는 단일 문자열로 지정할 수 있습니다. 여러 볼륨을 지정하는 경우 목록을 사용하세요.

Docker는 값이 할당되지 않은 환경 변수를 Launch 에이전트 환경에서 자동으로 전달합니다. 즉, Launch 에이전트에 환경 변수 MY_EXISTING_ENV_VAR가 있는 경우 해당 환경 변수를 컨테이너에서 사용할 수 있습니다. 이는 대기열 설정에서 게시하지 않고 다른 구성 키를 사용하려는 경우에 유용합니다.

docker run 코맨드의 --gpus 플래그를 사용하면 Docker 컨테이너에서 사용할 수 있는 GPU를 지정할 수 있습니다. gpus 플래그를 사용하는 방법에 대한 자세한 내용은 Docker 설명서를 참조하세요.

대기열 생성

W&B CLI를 사용하여 Docker를 컴퓨팅 리소스로 사용하는 대기열을 만듭니다.

1. Launch 페이지로 이동합니다.
2. Create Queue 버튼을 클릭합니다.
3. 대기열을 만들려는 Entity를 선택합니다.
4. Name 필드에 대기열 이름을 입력합니다.
5. Resource로 Docker를 선택합니다.
6. Configuration 필드에 Docker 대기열 설정을 정의합니다.
7. Create Queue 버튼을 클릭하여 대기열을 만듭니다.

로컬 장치에서 Launch 에이전트 구성

launch-config.yaml이라는 YAML 구성 파일로 Launch 에이전트를 구성합니다. 기본적으로 W&B는 ~/.config/wandb/launch-config.yaml에서 구성 파일을 확인합니다. Launch 에이전트를 활성화할 때 다른 디렉토리를 선택적으로 지정할 수 있습니다.

핵심 에이전트 구성 옵션

다음 탭은 W&B CLI와 YAML 구성 파일로 핵심 구성 에이전트 옵션을 지정하는 방법을 보여줍니다.

• W&B CLI
• Config file

wandb launch-agent -q <queue-name> --max-jobs <n>

max_jobs: <n concurrent jobs>
queues:
	- <queue-name>

Docker 이미지 빌더

장치의 Launch 에이전트를 구성하여 Docker 이미지를 빌드할 수 있습니다. 기본적으로 이러한 이미지는 장치의 로컬 이미지 리포지토리에 저장됩니다. Launch 에이전트가 Docker 이미지를 빌드할 수 있도록 하려면 Launch 에이전트 구성에서 builder 키를 docker로 설정합니다.

builder:
	type: docker

에이전트가 Docker 이미지를 빌드하지 않고 레지스트리에서 미리 빌드된 이미지를 대신 사용하려면 Launch 에이전트 구성에서 builder 키를 noop로 설정합니다.

builder:
  type: noop

컨테이너 레지스트리

Launch는 Dockerhub, Google Container Registry, Azure Container Registry 및 Amazon ECR과 같은 외부 컨테이너 레지스트리를 사용합니다. 빌드한 환경과 다른 환경에서 작업을 실행하려면 컨테이너 레지스트리에서 풀할 수 있도록 에이전트를 구성합니다.

Launch 에이전트를 클라우드 레지스트리에 연결하는 방법에 대한 자세한 내용은 고급 에이전트 설정 페이지를 참조하세요.