이 문서에서는 예약된 용량을 사용하여 만든 A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega Compute Engine 인스턴스를 모니터링하는 방법을 설명합니다. 특히 이 문서에서는 Cloud Monitoring 대시보드를 사용하여 독립형 컴퓨팅 인스턴스 또는 Slurm 클러스터의 성능 병목 현상을 식별하고 문제를 해결하는 방법을 설명합니다. 이러한 대시보드를 사용하면 워크로드의 다운타임과 성능 문제를 최소화할 수 있습니다.
사전 빌드된 Monitoring 대시보드를 만들어 독립형 컴퓨팅 인스턴스 또는 Slurm 클러스터를 모니터링할 때 다음을 모니터링할 수 있습니다.
컴퓨팅 인스턴스 상태
GPU 성능
네트워크 전송 효율성
블록과 하위 블록 간의 네트워크 효율성
머신러닝 (ML) 워크로드 효율성
낙오 항목 감지
시작하기 전에
아직 완료하지 않았다면 워크로드를 모니터링하기 전에 다음 단계를 완료하세요.
모니터링할 수 있는 워크로드 배포 지원되는 워크로드를 알아보려면 이 문서의 제한사항을 참고하세요. 워크로드를 배포하는 방법을 알아보려면 배포 옵션 개요를 참고하세요.
워크로드 모니터링을 위한 Google Cloud 서비스에 대해 알아보기:
이 문서의 측정항목은 Monitoring 대시보드를 사용합니다. 모니터링 대시보드, 모니터링 보관 기간, 모니터링 가격 책정에 대해 알아보세요.
이상치 감지는 Cloud Logging에 로그 항목도 제공합니다. Logging 인터페이스, Logging 보관 기간, Logging 가격 책정에 대해 알아봅니다.
When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
제한사항
이 문서의 측정항목은 다음 기준을 모두 충족하는 컴퓨팅 인스턴스에서 실행되는 워크로드에만 지원됩니다.
- 컴퓨팅 인스턴스는 독립형 Compute Engine 인스턴스 또는 Slurm 클러스터의 일부로 만들어야 합니다.
- 컴퓨팅 인스턴스는 예약된 용량을 사용하여 생성되어야 합니다.
- 컴퓨팅 인스턴스는 A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega 머신 시리즈를 사용해야 합니다.
- 하지만 straggler 감지는 A3 Mega 머신 시리즈를 사용하는 가상 머신 (VM) 인스턴스도 지원합니다.
ML 워크로드 측정항목을 모니터링하려면 워크로드 모니터링을 설정해야 합니다.
지연 감지 측정항목에는 다음과 같은 추가 제한사항이 있습니다.
- A3 Mega를 제외한 지원되는 머신 시리즈의 경우 지연 감지는 Collective Communication Analyzer (CoMMA) 라이브러리가 NCCL 원격 분석을 Google Cloud 서비스로 내보내도록 지원하는 컴퓨팅 인스턴스만 지원합니다. 자세한 내용은 CoMMA 개요를 참고하세요.
- 지각자 감지에는 일반적으로 지각자를 신고하는 데 최대 10분이 걸립니다.
- 이 문서의 다른 측정항목과 달리 클러스터, 블록, 하위 블록 또는 컴퓨팅 인스턴스로 프로젝트의 이상치 감지 측정항목을 필터링할 수 없습니다. 하지만 지연된 인스턴스로 의심되는 하나 이상의 컴퓨팅 인스턴스의 ID로 지연된 인스턴스 감지 로그에 대한 쿼리를 필터링할 수 있습니다.
필요한 역할
AI Hypercomputer 워크로드의 측정항목을 모니터링하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.
-
Cloud Monitoring에서 측정항목을 보려면 다음 단계를 따르세요.
프로젝트에 대한 Monitoring 편집자 (
roles/monitoring.editor) -
Logging에서 지연 감지 로그를 보려면 다음이 필요합니다.
프로젝트에 대한 로그 뷰어 (
roles/logging.viewer)
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
이러한 사전 정의된 역할에는 AI Hypercomputer 워크로드의 측정항목을 모니터링하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.
필수 권한
AI Hypercomputer 워크로드의 측정항목을 모니터링하려면 다음 권한이 필요합니다.
-
대시보드 보기: 프로젝트에 대한
monitoring.dashboards.get권한 -
대시보드 만들기: 프로젝트에 대한
monitoring.dashboards.create -
로그 항목 보기: 프로젝트에 대한
logging.logEntries.list권한
커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.
사용 가능한 측정항목
사용 사례에 따라 컴퓨팅 인스턴스 및 Slurm 클러스터를 모니터링하는 데 사용할 수 있는 측정항목은 다음과 같습니다.
컴퓨팅 인스턴스에 연결된 GPU의 상태, 성능, 네트워크 성능을 모니터링하려면 인프라 측정항목을 참고하세요.
ML 워크로드의 GPU 효율성을 모니터링하려면 ML 워크로드 측정항목을 참고하세요.
성능이 느린 ML 워크로드에서 의심되는 straggler 컴퓨팅 인스턴스를 모니터링하려면 Straggler 감지 측정항목을 참고하세요.
이러한 측정항목을 보는 방법을 알아보려면 이 문서의 측정항목 시각화를 참고하세요.
인프라 측정항목
컴퓨팅 인스턴스에 연결된 GPU의 상태, 성능, 네트워크 성능을 모니터링하려면 다음 측정항목을 사용하세요.
Compute Engine에서 사용 가능한 측정항목의 개요는 Google Cloud 측정항목을 참고하세요.
GPU 상태 측정항목
GPU 상태를 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 머신 상태 | machine/machine_status |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 컴퓨팅 인스턴스에서 사용하는 머신이 정상인지 또는 머신이 비정상이며 수리가 필요한지 여부입니다. |
| NVSwitch 상태 | instance/gpu/nvswitch_status |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 컴퓨팅 인스턴스에 연결된 NVIDIA GPU의 NVLink 스위치에 문제가 있는지 여부입니다. |
| VM 인프라 상태 | instance/gpu/infra_health |
A4X, A4, A3 Ultra 또는 A3 Mega | 컴퓨팅 인스턴스가 실행 중인 클러스터, 블록, 하위 블록, 호스트의 상태입니다. 이 측정항목에 컴퓨팅 인스턴스의 인프라가 비정상으로 표시되면 측정항목에 문제도 설명됩니다. |
| VM 실패 예측 점수 | instance/gpu/failure_prediction_score |
A4X, A4, A3 Ultra 또는 A3 Mega |
컴퓨팅 인스턴스가 실행되는 호스트가 향후 5시간 내에 성능이 저하될 가능성입니다. 값은 0.0에서 1.0 사이일 수 있습니다. 값이 일정한 기간 동안 1.0에 가까울수록 컴퓨팅 인스턴스가 저하될 가능성이 높습니다. 이 경우 작업을 다른 컴퓨팅 인스턴스로 이동하고 컴퓨팅 인스턴스에 문제가 발생하면 호스트가 잘못되었다고 신고하는 것이 좋습니다.
|
GPU 성능 측정항목
GPU의 성능을 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 누적 컨텍스트 사용률 | instance/gpu/accumulated_context_utilization_seconds |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | GPU가 워크로드를 처리하는 데 걸린 총 시간(초)입니다. |
| GPU 전력 소비량 | instance/gpu/power_consumption |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 호스트의 개별 GPU에서 소비되는 전력(와트(W)) 및 십진수 값입니다. GPU가 여러 개 연결된 컴퓨팅 인스턴스의 경우 이 측정항목은 호스트의 각 GPU에 대한 전력 소비량을 별도로 제공합니다. |
| SM 사용률 | instance/gpu/sm_utilization |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 0이 아닌 값은 GPU의 스트리밍 멀티 프로세서(SM)가 활발하게 사용되고 있음을 나타냅니다. |
| GPU 온도 | instance/gpu/temperature |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 호스트에 있는 개별 GPU의 온도(섭씨(℃)) 및 십진수 값입니다. GPU가 여러 개 연결된 컴퓨팅 인스턴스의 경우 이 측정항목은 호스트의 각 GPU 온도를 별도로 제공합니다. |
| GPU 열 마진 | instance/gpu/tlimit |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 높은 온도로 인해 속도를 늦춰야 하기 전에 개별 GPU가 갖는 열 여유 (℃) 및 십진수 값입니다. GPU가 여러 개 연결된 컴퓨팅 인스턴스의 경우 이 측정항목은 호스트의 각 GPU에 대한 열 여유를 별도로 제공합니다. |
GPU 네트워크 성능 측정항목
GPU의 네트워크 성능을 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 운송업체 변경사항 연결 | instance/gpu/link_carrier_changes |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 링크 캐리어가 1분 동안 변경되는 빈도입니다. |
| 네트워크 RTT | instance/gpu/network_rtt |
A4X, A4, A3 Ultra 또는 A3 Mega | 소스와 대상 간에 네트워크 데이터가 이동하는 데 걸리는 왕복 시간(마이크로초)입니다. |
| 블록 간 네트워크 트래픽 | instance/gpu/network/inter_block_tx |
A4X, A4, A3 Ultra 또는 A3 Mega | 블록 간 네트워크 트래픽의 바이트 수입니다. |
| 하위 블록 간 네트워크 트래픽 | instance/gpu/network/inter_subblock_tx |
A4X, A4, A3 Ultra 또는 A3 Mega | 하위 블록 간 네트워크 트래픽의 바이트 수입니다. |
| 서브 블록 내 네트워크 트래픽 | instance/gpu/network/intra_subblock_tx |
A4X, A4, A3 Ultra 또는 A3 Mega | 단일 하위 블록 내 네트워크 트래픽의 바이트 수입니다. |
| NVLink 활성 속도 | instance/gpu/nvlink_active_speed |
A4X Max, A4X, A4, A3 Ultra 또는 A3 Mega | 현재 액세스 링크 포트 속도(GBps)입니다. |
| 수신 처리량 바이트 수 | instance/gpu/throughput_rx_bytes |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 트래픽에서 수신된 바이트 수입니다. |
| 처리량 TX 바이트 | instance/gpu/throughput_tx_bytes |
A4X, A4, A3 Ultra 또는 A3 Mega | 네트워크 트래픽으로 전송된 바이트 수입니다. |
GPU 심각한 오류 측정항목
GPU에서 발생하여 컴퓨팅 인스턴스를 중지시키거나 성능에 부정적인 영향을 미칠 수 있는 오류를 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| NVLink 런타임 오류 | instance/gpu/nvlink_runtime_error |
A4X Max 또는 A4X | NVLink 런타임 오류가 발생했는지 여부입니다. |
| 수정 불가능한 DRAM ECC 오류 | instance/gpu/dram_uncorrectable_ecc_error_count |
A4X Max 또는 A4X | GPU 동적 랜덤 액세스 메모리 (DRAM)의 수정 불가능한 오류 수정 코드 (ECC) 수입니다. |
| 수정 불가능한 DRAM 행 리매핑 수 | instance/gpu/dram_uncorrectable_row_remapping_count |
A4X Max 또는 A4X | GPU DRAM에서 수정 불가능한 오류로 인해 수행된 행 리매핑 수입니다. |
| 수정 불가능한 DRAM 행 리매핑 실패 | instance/gpu/dram_row_remapping_failed |
A4X Max 또는 A4X | 다음 문제 중 하나로 인해 GPU DRAM의 행 리매핑이 실패했는지 여부입니다.
|
| 수정할 수 없는 PCIe 오류 | instance/gpu/pcie_fatal_error_count |
A4X Max 또는 A4X | 수정 불가능한 주변기기 상호 연결 익스프레스 (PCIe) 오류 수입니다. |
| 수정 불가능한 캐시 ECC 오류 | instance/gpu/cache_uncorrectable_ecc_error_count |
A4X Max 또는 A4X | 캐시 메모리에서 발생한 수정 불가능한 ECC 수입니다. |
ML 워크로드 측정항목
ML 워크로드의 생산성(특히 goodput)을 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 생산적인 시간 | workload/goodput_time |
A4X, A4, A3 Ultra 또는 A3 Mega | 워크로드가 굿풋 활동에 사용한 시간(초)입니다. 이러한 활동은 모델 학습 중 순방향 또는 역방향 패스와 같은 핵심적이고 유용한 작업입니다. |
| 비생산적인 시간 | workload/badput_time |
A4X, A4, A3 Ultra 또는 A3 Mega | 워크로드가 badput 활동에 소요한 시간(초)입니다. 이러한 활동은 학습을 위한 데이터 로드 또는 사전 처리와 같은 오버헤드 작업입니다. |
낙오 항목 감지 측정항목
이상치 감지 측정항목은 의심되는 이상치를 파악하고 찾아내는 데 도움이 됩니다. 낙오 항목은 단일 지점의 비정상 종료되지 않는 오류로, 결국 전체 워크로드의 속도를 저하시킵니다.
VM의 straggler 감지를 모니터링하려면 다음 측정항목을 사용하세요.
| 이름 | 측정항목 유형 | 지원되는 머신 시리즈 | 설명 |
|---|---|---|---|
| 낙오 항목으로 의심됨 | instance/gpu/straggler_status |
A4X, A4, A3 Ultra 또는 A3 Mega | VM이 워크로드의 성능에 영향을 주는 낙오 항목으로 의심되는지 여부입니다. 다른 측정항목에서 워크로드에 문제가 있음을 나타내는 경우에만 의심되는 이상치에 대해 조치를 취하는 것이 좋습니다. |
A4X, A4, A3 Ultra 또는 A3 Mega 인스턴스의 로그 항목에서 straggler 감지 측정항목을 확인할 수도 있습니다. 예를 들어 다음 쿼리를 사용할 수 있습니다.
| 설명 | 쿼리 |
|---|---|
| 특정 VM의 지연이 의심되는 로그 이 쿼리를 사용하여 프로젝트의 특정 워크로드에 의심되는 누락 항목이 있는지 확인합니다. |
logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
|
| 프로젝트의 낙오자 감지에서 가져온 모든 로그 의심되는 지연이 감지되지 않을 때 지연 감지 서비스가 실행 중인지 확인하려면 이 쿼리를 사용하세요. (제한사항으로 인해 특정 VM별로 의심되는 지연 없이 로그를 필터링할 수 없습니다.) |
|
낙오 항목 감지 측정항목은 다음과 같은 이유로 대규모 ML 워크로드에 특히 유용합니다.
대규모 ML 워크로드는 지연에 매우 취약합니다. 대규모 ML 워크로드는 동기식 대규모 분산 컴퓨팅을 사용합니다. (즉, 동시에 실행되는 상호 의존성이 높은 구성요소가 많습니다.) 이 아키텍처는 대규모 ML 워크로드를 지연된 작업과 같은 단일 장애점에 매우 취약하게 만듭니다.
대규모 ML 워크로드에서 낙오 항목을 파악하고 찾아내는 것은 매우 어렵습니다. 참고로 단일 장애점에는 다음 두 가지 유형이 있습니다.
중지 오류: 전체 시스템이 중지되는 오류입니다. 예를 들어 호스트 오류 및 유지보수 이벤트가 있습니다. 이러한 문제는 비교적 쉽게 감지하고 해결할 수 있습니다.
느린 실패: 비정상 종료 없이 심각한 성능 저하를 일으키는 실패입니다. 이러한 버그는 정확히 찾아내고 디버그하기가 매우 어렵습니다.
지연되는 작업은 느린 실패 특성으로 인해 특히 대규모 동기식 워크로드에서 눈에 띄거나 정확히 파악하기가 어렵습니다.
측정항목 보기
컴퓨팅 인스턴스 및 Slurm 클러스터의 측정항목을 보려면 다음과 같이 Monitoring 대시보드를 사용하세요.
인프라 측정항목과 straggler 감지 측정항목을 보려면 다음을 수행하세요.
인프라 상태 및 성능을 빠르게 개요로 확인하거나 기존 대시보드를 맞춤설정하려면 사전 빌드된 대시보드를 사용하세요.
특정 모니터링 요구사항의 경우 커스텀 대시보드를 만드세요.
ML 워크로드 측정항목을 보려면 워크로드 모니터링 설정 방법을 설명하는 문서를 참고하세요.
지연 감지 로그를 보려면 지연 감지 로그 보기를 참고하세요.
대시보드를 사용할 때 문제가 발생하면 느린 성능 문제 해결을 참고하세요.
사전 빌드된 대시보드 사용
AI Hypercomputer용으로 사전 빌드된 Monitoring 대시보드를 사용하여 컴퓨팅 인스턴스 및 Slurm 클러스터의 측정항목을 확인할 수 있습니다. 사전 빌드된 대시보드의 사본을 만들어 필요에 맞게 수정할 수도 있습니다.
AI 하이퍼컴퓨터용 사전 빌드된 대시보드를 사용하려면 다음 단계를 따르세요.
-
Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
이름 열에서 보려는 측정항목에 따라 다음 대시보드 중 하나의 이름을 클릭합니다.
컴퓨팅 인스턴스 상태, GPU 성능, straggler 감지를 모니터링하려면 클러스터 디렉터 상태 모니터링 대시보드를 사용하세요.
이러한 측정항목을 사용하여 문제를 식별하고 분석하는 방법에 대한 자세한 내용은 GCE 대화형 플레이북 - 클러스터 디렉터 상태 모니터링 플레이북 대시보드를 참고하세요.
네트워크 전송 효율성을 모니터링하려면 클러스터 디렉터 전송 효율성 대시보드를 사용하세요.
블록과 하위 블록 간의 네트워크 효율성을 모니터링하려면 클러스터 디렉터 블록 네트워크 대시보드를 사용하세요.
이러한 측정항목을 사용하여 문제를 식별하고 분석하는 방법을 자세히 알아보려면 GCE 대화형 플레이북 - Cluster Director 차단 네트워크 플레이북 대시보드도 사용하세요.
선택한 대시보드의 세부정보 페이지가 열립니다. 도구 모음의 시간 범위 선택기를 사용하여 데이터의 시간 범위를 변경할 수 있습니다.
선택사항: 대시보드의 사본을 만들어 필요에 맞게 맞춤설정하려면 대시보드 복사를 클릭합니다.
커스텀 대시보드 만들기
커스텀 모니터링 대시보드를 만들려면 다음 단계를 따르세요.
모니터링할 측정항목을 선택합니다. 아직 확인하지 않았다면 이 문서의 사용 가능한 측정항목을 참고하세요.
낙오 항목 감지 로그 보기
로그 탐색기를 사용하여 지연 감지 로그를 보려면 다음 단계를 완료하세요.
-
Google Cloud 콘솔에서 로그 탐색기 페이지로 이동합니다.
검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Logging인 결과를 선택합니다.
이 페이지는 기본적으로 프로젝트의 모든 로그를 쿼리합니다. 쿼리 중지를 클릭합니다.
툴바의 기간 선택기를 사용하여 분석할 기간을 선택합니다.
쿼리 창에 이상치 감지 로그 쿼리를 입력합니다.
쿼리 실행을 클릭합니다.
다음은 straggler 감지 로그 항목의 예입니다.
{
...
"jsonPayload": {
...
"@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
"suspectedStragglersDetection": {
"numNodes": 4,
"nodes": [
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_1"
},
{
"latencyMs": 9,
"instanceId": "INSTANCE_ID_2"
},
{
"instanceId": "INSTANCE_ID_3",
"latencyMs": 4
},
{
"instanceId": "INSTANCE_ID_4",
"latencyMs": 0
}
],
"message": "Suspected stragglers detected."
}
},
"resource": {
"type": "project",
"labels": {
"project_id": "PROJECT_NUMBER"
}
},
...
"severity": "INFO",
"logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
...
}
로그 항목에는 다음 필드가 포함됩니다.
numNodes: 프로젝트에서 감지된 의심스러운 지연 컴퓨팅 인스턴스의 수입니다. 이 예에서는 의심되는 4개의 straggler 컴퓨팅 인스턴스가 감지되었습니다.instanceId: 의심되는 지연으로 감지된 컴퓨팅 인스턴스의 ID입니다.