데이터 수집 처리량 권장사항

이 페이지에서는 Cloud Healthcare API로 데이터를 수집할 때 데이터 처리량을 최적화하기 위한 권장사항을 설명합니다. 이러한 권장사항은 대규모 시스템의 데이터 처리량 관리 경험이 있는 기술 실무자를 위한 것입니다.

데이터 처리량

데이터 처리량은 FHIR 리소스 또는 DICOM 인스턴스와 같은 리소스 또는 Cloud Healthcare API가 매초 수집하는 바이트 양을 나타냅니다.

데이터 처리량 제약조건

다음 목록은 데이터 처리량이 제약될 수 있는 이유를 설명합니다.

트래픽 급증을 유발하는 대규모 볼륨 요청에 대한 계획이 없습니다.
대역폭 제약조건에 따라 짧은 기간 동안 전송되는 대량의 데이터 볼륨 수집이 느려집니다.
동시에 발생하는 여러 트랜잭션으로 인해 동일한 Cloud Healthcare API 리소스가 변경되어 데이터 경합이 일어납니다.
소규모 요청이 너무 많이 수행됩니다. 자세한 내용은 소규모 가져오기 및 내보내기 요청 방지를 참조하세요.
동시에 실행되는 장기 실행 작업(LRO)이 너무 많고 대역폭이 제한적입니다.
동시에 예약된 LRO가 너무 많아서 오류가 발생합니다.

실패한 요청 재시도

클라이언트가 실패 후 요청을 빠르게 반복적으로 재시도하면 Cloud Healthcare API 할당량을 초과할 수 있습니다. 다음 섹션에서는 실패한 요청을 효율적으로 재시도하는 방법을 설명합니다.

지터 및 영구적인 재시도 큐와 함께 지수 백오프 사용

지터가 도입된 지수 백오프는 네트워크 애플리케이션의 표준 오류 처리 전략입니다. 클라이언트는 재시도 사이에 기하급수적으로 늘어나는 지연 시간과 작은 무작위 지연 시간을 사용해서 실패한 요청을 주기적으로 재시도합니다.

특히 실패 조건을 우회하기 위해 커스텀 로직을 사용할 때는 지수 백오프 구현이 각 재시도에 대해 멱등적인지 확인해야 합니다. 자세한 내용은 HTTP 사양에서 9.2.2 멱등성 메서드를 참조하세요.

대부분의 프로그래밍 언어는 지수 백오프 구현을 간소화하기 위한 라이브러리와 비슷한 재시도 전략을 제공합니다. 장기 또는 멀티 프로세스 재시도의 경우 영구 재시도 큐를 구현합니다. 이 큐는 최대 백오프 시간을 초과할 경우 재시도 메커니즘을 재설정합니다.

다음과 같은 요청을 재시도할 때 지수 백오프를 사용합니다.

FHIR 리소스 또는 FHIR 리소스 번들을 수정하는 작업
동기식 LRO 요청. LRO가 시작되거나 LRO가 실패할 때 오류가 있으면 재시도합니다.

LRO에는 다음 재시도 전략 구현이 요구될 수 있는 고유한 오류가 있습니다.
- 개별 번들을 사용해서 가져오기 또는 생성 작업이 실패한 데이터를 저장합니다.
- 처리하지 못한 데이터에 대해 동기식 요청을 사용합니다.

지수 백오프 예시 알고리즘

지수 백오프 알고리즘이 재시도 간 대기 시간을 최대 백오프 시간까지 늘려서 기하급수적으로 요청을 재시도합니다. 다음 알고리즘은 지터가 포함된 잘린 지수 백오프를 구현합니다.

Cloud Healthcare API에 요청을 전송합니다.
요청이 실패하면 1초 + random-fraction를 대기한 후 요청을 재시도합니다.
요청이 실패하면 2초 + random-fraction를 대기한 후 요청을 재시도합니다.
요청이 실패하면 4초 + random-fraction를 대기한 후 요청을 재시도합니다.
이 패턴을 계속 시도합니다. 재시도할 때마다 2ⁿ + random-fraction초 동안 대기합니다(최대 maximum-backoff시간).
deadline초가 지나면 요청 재시도를 중지합니다.

알고리즘을 구현할 때 다음 값을 사용합니다.

재시도를 하기 전 대기 시간은 min((2ⁿ + random-fraction), maximum-backoff)이며, n은 0에서 시작하고 재시도할 때마다 1씩 증가합니다.
random-fraction을 1보다 작거나 같은 임의의 소수 값으로 바꿉니다. 재시도할 때마다 다른 값을 사용하세요. 이 임의의 값을 추가하면 클라이언트가 동기화되고 동시에 많은 재시도를 전송할 수 없습니다.
maximum-backoff를 재시도 사이의 최대 대기 시간(초)으로 바꿉니다. 일반적인 값은 32초 또는 64초(2⁵ 또는 2⁶)입니다. 사용 사례에 가장 적합한 값을 선택하세요.
deadline을 재시도 전송을 유지할 최대 시간(초)으로 바꿉니다. 사용 사례에 맞는 값을 선택하세요.

클라이언트는 동일한 값을 백오프로 사용해서 maximum-backoff 시간에 도달한 후 재시도할 수 있습니다. 예를 들어 maximum-backoff 시간이 64초이면 64초마다 재시도합니다. 클라이언트가 무제한으로 재시도하지 않는지 확인해야 합니다.

트래픽 형태를 사용하여 클라이언트 측 비율 제한 구현

비율 제한은 과도한 요청으로 인해 과부하되지 않도록 방지하여 대규모 시스템을 보호합니다. 클라이언트 측 비율 제한이 충분하지 않으면 Cloud Healthcare API 할당량 시스템이 데이터 처리량을 제한할 수 있습니다. 자세한 내용은 할당량 관리를 위한 권장사항을 참조하세요.

재시도 간 전송 보장과 같은 추가 요구사항이 있으면 실패한 요청 재시도의 전략이 충분하지 않을 수 있습니다. 트래픽 형태는 대역폭 제약조건 내에서 클라이언트 측 요청의 비율을 유지하는 비율 제한 기법입니다. 이렇게 하면 시간 또는 분 단위로 부하 급증을 분산하여 처리량이 향상됩니다. 할당량이 제한된 경우 트래픽 형태는 푸시백을 방지하고 작업자 단위를 추적하기 때문에 재시도를 사용하는 것보다 높은 처리량을 달성할 수 있습니다.

fhir.executeBundle을 포함하여 동기식 만들기, 읽기, 업데이트, 삭제(CRUD) 작업에 대해 트래픽 형태를 구현할 수 있습니다.

트래픽 형태 요구사항

트래픽 형태를 구현하려면 시스템이 다음을 구현해야 합니다.

디스크 오류를 방지하기 위해 중복성이 있는 스토리지 지원 처리 큐
처리 큐에서 가져오기 위한 조정된 작업자
할당량 제한에 따라 작업자 수 및 처리 속도를 조정하는 전체 사용 감지
스토리지 지원 처리 큐의 재해 복구. 재해가 있을 때 시스템이 큐를 영구 삭제하거나 복구할 수 있어야 합니다.
사용량이 많은 시간 중 감소된 LRO. 자세한 내용은 효율적인 할당량 계획 및 사용과 큐에 추가 및 LRO 관리를 참조하세요.

다음 경우에는 트래픽 형태가 단일 파이프라인 단계에서만 필요할 수 있습니다.

이전 파이프라인 단계에서 가져오는 작업자 수를 제한합니다.
각 작업자를 개별적으로 제한합니다.
작업자 풀 조정자를 사용해서 초당 쿼리 수(QPS) 또는 초당 수집된 바이트 수와 같은 개별 작업 단위가 처리되는 비율을 조정합니다.

시스템의 다른 영역에서 비율 제한 구현

기존 프로그래밍 언어 및 프레임워크를 사용해서 트래픽 형태를 구현할 수 있습니다. 다음과 같은 오픈소스 프로젝트 및 사전 빌드된 솔루션을 고려하세요.

Apache Beam의 클라이언트 측 제한. numWorkers 및 maxNumWorkers 플래그를 사용한 제한 조절 방법은 수평 자동 확장을 참조하세요.
핵심 Java 라이브러리의 Google Guava 집합에서 가져온 Java RateLimiter 클래스
Python ratelimiter 모듈

흐름 제어의 경우 상위 레벨 Pub/Sub 클라이언트 라이브러리를 사용합니다.

비동기 및 동기 처리 중에서 선택

여러 레이어의 오류 처리에 표시된 Cloud Healthcare API에 요청을 래핑하는 클라이언트 측 프록시 레이어도 the Cloud Healthcare API를 사용하는 서비스 간에 제한을 조정할 수 있습니다. 필요한 트래픽 형태 유형에 따라 다음 옵션 중 하나를 사용합니다.

비동기

비동기식 처리를 사용해서 요청을 큐에 추가하고 작업자를 제어합니다. 프록시 레이어는 들어오는 요청을 큐에 기록하고 각 요청이 큐에 추가된 후 200 OK 응답을 반환합니다. 이 방식은 쓰기 요청에 적합하지만 클라이언트가 읽기 요청을 수신할 수 있는 경우 LRO 프레임워크의 읽기 요청에 사용될 수 있습니다.

동기식

동기 처리는 작업 단위가 이전의 단위 마감에 의존하는 경우 간단한 피드백 메커니즘을 제공합니다. 프록시 레이어가 QPS 또는 바이트 처리량 제한에 따라 아웃바운드 요청을 지연시키고 클라이언트는 작업을 중단하고 프록시 레이어 응답을 기다립니다.

프록시 레이어가 인스턴스 수를 기반으로 비율 제한을 조정하거나 몇 초마다 비율 제한을 조정하는 컨트롤러 프로세서로 조정할 수 있습니다. 프록시 레이어가 인스턴스 수와 해당 비율 제한을 추적할 수 있도록 각 프록시 인스턴스는 정기적으로 파일을 읽거나 비율 제한이 인코딩된 원격 프로시져 콜(RPC)을 수행할 수 있습니다.

동기 처리에는 일부 경우에 다음과 같은 단점이 있습니다.

클라이언트가 작업을 중지하고 응답을 기다리는 동안 클라이언트 및 프록시 레이어의 리소스를 사용할 수 없습니다. 그 결과 오류, 시간 초과, 낮은 데이터 처리량이 발생하여 확장이 어려울 수 있습니다.
클라이언트 및 프록시 레이어 연결이 해제되면 데이터가 요청한 대로 수정되었는지 확인하기 위해 추가 작업이 필요합니다.

Cloud Tasks 사용

Cloud Tasks를 사용하면 요청을 큐로 오프로드할 수 있습니다. Cloud Tasks는 다음 Google Cloud 할당량을 자동으로 설정하고 모니터링합니다.

RateLimits 객체를 사용하는 최대 버스트 크기 및 최대 요청 동시성
RetryConfig 객체를 사용하는 재시도 제한

Cloud Tasks에서 큐를 만들려면 큐 만들기를 참조하세요. Queue 리소스는 큐에 설정할 수 있는 옵션을 보여줍니다. 예를 들어 RetryConfig 객체를 사용해서 지수 백오프를 구현할 수 있습니다. 언어별 라이브러리는 Cloud Tasks 클라이언트 라이브러리를 참조하세요.

Cloud Tasks를 사용할 때는 다음을 고려하세요.

Cloud Tasks는 1회만 전송을 보장하지 않습니다. 1회만 전송에서 중복된 데이터가 포함된 요청은 중복 항목으로 인식되고 서버에서 무시됩니다. 자세한 내용은 람다 이후: Dataflow에서 단 한 번 처리, 1부를 참조하세요.
최대 태스크 크기는 Cloud Healthcare API의 최대 FHIR 번들 크기보다 상당히 작을 수 있습니다. 자세한 내용은 Cloud Tasks 할당량 및 한도과 Cloud Healthcare API 할당량 및 한도를 참조하세요.
Cloud Tasks에는 문제 및 제한사항이 있습니다.

FHIR 번들과 비율 제한 조합

지수 백오프 및 비율 제한을 사용해서 FHIR 번들을 재시도하면 높은 데이터 처리량을 유지하고 부하 급증을 관리하는 데 도움이 됩니다.

클라이언트는 배치 및 트랜잭션 FHIR 번들을 Cloud Tasks에 전송할 수 있고 Cloud Tasks는 번들의 요청을 Cloud Healthcare API로 전송합니다. 최대 큐 크기에 도달하거나 디스크 공간 부족으로 인해 비율 제한이 가득 차거나 할당량을 초과하면 클라이언트가 번들을 큐에 추가하기 위해 지수 백오프를 구현할 수 있습니다.

다음 리소스를 모니터링하여 비율 제한 큐가 가득 차는 것을 방지합니다.

Cloud Healthcare API의 FHIR 작업 할당량
비율 제한 할당량
비율 제한 오류

비율 제한 큐가 가득 차면 시스템이 작업자에게 알리고 요청을 전송하지 못하도록 클라이언트를 중지해야 합니다.

HTTP 영구(재사용 가능한 연결 유지) 연결 사용

기본적으로 Cloud Healthcare API는 각 CRUD 요청에 대해 새 TCP 연결을 엽니다. 이를 위해서는 오버헤드를 일으키고 성능을 저하시킬 수 있는 TCP 핸드셰이크가 필요합니다. 성능 향상을 위해서는 HTTP 연결 유지를 사용해서 여러 요청에 대해 TCP 연결을 연 상태로 유지합니다.

HTTP/1.1에서 HTTP 연결 유지를 사용하려면 Connection 헤더를 keep-alive로 설정합니다.

Connection: keep-alive

HTTP/2는 순차 및 동시 요청에 대해 하나의 TCP 연결을 사용하여, 오버헤드를 자동으로 방지합니다.

Python requests 라이브러리는 기본적으로 HTTP 연결 유지를 사용합니다. Node.js를 사용하는 경우 http.Agent 객체를 만들 때 keepAlive를 true로 설정한 후 요청에 객체를 전달합니다.

테스트 프레임워크 사용

테스트 프레임워크를 사용하면 코드 작동을 보장하고 다음을 수행하는 데 도움이 됩니다.

애플리케이션 또는 파이프라인에서 갑작스러운 트래픽 급증을 준비합니다.
지수 백오프 및 클라이언트 측 비율 제한으로 성능이 향상되는지 테스트합니다. 테스트를 통해 이러한 구현에 따라 개별적으로 처리되어야 하는 태스크 백로그가 발생하는지 여부를 확인할 수 있습니다.
높은 우선순위의 트래픽을 분리 및 제어합니다. 예를 들어 사용자가 응답을 기다리는 경우 사용자 경험이 저하되지 않도록 백그라운드 처리 태스크에 대한 워크로드를 줄일 수 있습니다.
트래픽 흐름 제어를 위해 동기 및 비동기 큐 전략을 테스트하거나 프록시 레이어가 푸시백을 처리하는지 테스트합니다.
재해 복구를 계획합니다. 일반적으로 이를 위해서는 재해가 종료된 후 들어오는 트래픽을 재설정하거나 큐를 사용해서 트래픽을 재개해야 합니다.

Cloud Monitoring 사용

Cloud Monitoring을 사용해서 테스트 및 프로덕션 환경을 모니터링합니다. 다음 권장사항을 따르세요.

Cloud Tasks를 Cloud 감사 로그와 같은 다른 Google Cloud 로깅 및 모니터링 서비스와 통합합니다.
Cloud Monitoring API를 사용해서 커스텀 측정항목을 만들어서 재시도, 큐 크기, 큐 기간과 같은 주요 측정항목을 추적합니다.
해당 환경의 서비스 수준 지표(SLI) 및 서비스 수준 목표(SLO)를 만듭니다. 권장사항은 SLI 소개를 참조하세요.
Google Cloud Observability를 사용하여 알림 정책을 만듭니다. 알림 정책은 시스템 부담이 크거나 작업자 개입이 필요한 경우와 같은 문제를 알립니다.
알림 정책으로 알림이 전송되었을 때 시스템 관리자가 수행할 작업을 알 수 있도록 운영 플레이북을 만듭니다.
스테이징 환경에서 운영 플레이북을 사용해서 다음과 같은 시나리오에 대응합니다.
- 비율 제한으로 인한 백로그
- 할당량 제한 초과로 인한 푸시백
- 들어오는 트래픽 급증

`429 Resource Exhausted operation_too_costly` 오류 방지

FHIR 리소스에 대해 매일 수천 개의 동시 업데이트를 수행하면 잠금 경합 및 지연 시간이 발생하고 트랜잭션이 완료되지 않을 수 있습니다. 트랜잭션을 완료할 수 없으면 429 Resource Exhausted operation_too_costly 오류 백로그가 발생할 수 있습니다.

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

오류에서 '비용'은 청구 비용이 아니라 리소스 사용량 및 데이터 처리량을 나타냅니다.

429 Too Many Requests 오류가 항상 할당량 문제를 나타내지는 않습니다. 이 오류는 Cloud Healthcare API FHIR 서버가 데이터베이스 레코드에서 과도한 잠금 경합을 감지할 때 발생할 수 있습니다. 이러한 문제는 FHIR 번들의 여러 작업 또는 CRUD 작업의 조합으로 인해 발생할 수 있습니다.

다음 상황을 살펴보세요.

환자 리소스 및 기타 FHIR 리소스를 업데이트하는 FHIR 트랜잭션 번들이 트랜잭션이 완료될 때까지 환자 리소스를 잠급니다.
여러 FHIR 번들이 환자 리소스를 동시에 업데이트하려고 시도하면 잠금 경합이 발생합니다. 오류 응답에는 Resource type: PATIENT 문구가 있는 diagnostics 필드가 포함됩니다.

지수 백오프로 환자 리소스 업데이트를 재시도할 수 있지만 잠금 경합 기간이 길어지면 시간 초과, 처리량 감소, 리소스 사용량 증가로 이어질 수 있습니다.
Cloud Healthcare API FHIR 서버가 결국 트랜잭션 백로그를 감지하고 operation_too_costly 오류를 반환하여 부하를 차단합니다. 이렇게 하면 트래픽이 제한되고 추가 오류가 방지됩니다.

operation_too_costly 오류는 Google Cloud 프로젝트의 모든 FHIR CRUD 작업을 제한하여 프로젝트에 연결된 모든 애플리케이션에 영향을 줍니다.

`429 Too Many Requests` 오류 문제 해결

429 Too Many Requests 오류를 문제 해결하려면 Cloud Logging을 검색합니다. operation_too_costly가 포함된 오류는 잠금 경합을 나타냅니다. 리소스 소진으로 인해 오류가 발생한 경우 할당량 문제를 확인합니다.

제한이 발생하면 높은 잠금 경합 수준으로 인해 트랜잭션 번들이 실패하고 다음 오류가 발생할 수 있습니다.

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

이 오류를 문제 해결하려면 diagnostics 필드에서 누적된 높은 부하로 인해 중단된 FHIR 트랜잭션 번들로 이동합니다.

대규모 번들 방지

429 Too Many Requests 오류는 대규모 트랜잭션 번들에서 발생할 가능성이 높습니다. 모든 크기의 번들이 처리량 병목 현상을 일으킬 수 있습니다. 여러 번들을 시도해서 최적 크기를 찾습니다.

재시도가 지원되는 대규모 번들은 성능 이득이 저하될 수 있고 여러 오류에 더 취약합니다. 클라이언트는 트랜잭션에서 실패한 FHIR 리소스 하위 집합을 관리하기 위한 추가 로직을 구현해야 합니다.

일괄 번들은 크기가 크거나 QPS가 높은 경우 429 Too Many Requests 및 413 Request Entity Too Large 오류와 처리량 병목 현상이 발생할 수 있습니다.

트랜잭션이 수천 개 있는 대규모 번들 사용을 방지합니다. 대신 다음 단계를 따릅니다.

데이터 일관성을 지원하는 더 작은 트랜잭션 번들을 사용합니다. FHIR 리소스가 서로 종속되지 않은 경우 이를 개별적으로 업데이트합니다. 예를 들어 FHIR 리소스가 동일 번들에 있는 다른 리소스의 특정 버전에 의존하지 않을 수 있습니다.
번들에서 일괄 처리를 사용하고 개별 요청을 방지합니다. 일괄 처리로 성능을 향상시킬 수 있지만 대규모 배치는 오류를 일으키고 데이터 처리량을 저하시킬 수 있습니다. 비슷한 크기의 배치 번들은 FHIR 리소스 업데이트 간에 잠금을 유지하지 않기 때문에 경합이 덜 발생합니다.

소규모 트랜잭션 번들은 한 번에 잠금을 몇 개만 포함하고 빠르게 완료되기 때문에 경합을 방지합니다. 그 결과 누적된 트랜잭션의 백로그가 방지됩니다.

LRO 처리량

LRO 데이터 처리량을 참조하세요.

FHIR 데이터 스토리지 옵션

FHIR 데이터 볼륨이 작거나 중간 정도이면 fhir.create를 사용하여 데이터를 저장합니다. 대량의 FHIR 리소스를 저장하려면 fhir.executeBundle 또는 fhirStores.import를 사용합니다. 각 메서드에 대한 자세한 내용은 FHIR 가져오기 옵션을 참조하세요.

FHIR 리소스 가져오기

FHIR 가져오기를 사용할지 여부를 결정할 때는 다음을 고려하세요.

FHIR 가져오기는 가져오는 데이터의 총 크기를 제한하지 않습니다. FHIR 번들이 50MB를 초과하면 FHIR 리소스를 Cloud Storage에 업로드하고 이를 가져올 수 있습니다. 동시에 높은 지연 시간 또는 대규모 가져오기를 방지합니다. 그렇지 않으면 처리량이 제한될 수 있습니다.
FHIR 가져오기는 FHIR 번들을 사용하는 것보다 덜 복잡합니다. 예를 들어 다음을 수행할 필요가 없습니다.
- 큰 번들을 작은 번들로 분할
- 일정 관리
- 리소스 또는 번들 수준에서 임시 오류 재시도
FHIR 가져오기는 참조 무결성을 적용하지 않습니다. 자세한 내용은 FHIR 참조 무결성을 참조하세요.
데이터 최신 상태에 대한 우선순위가 높은 경우에는 FHIR 가져오기를 사용하지 마세요. 가져오기는 빠를 수 있지만 몇 시간 또는 며칠 동안 지연될 수 있습니다.
FHIR 가져오기는 Google Cloud 프로젝트에 LRO가 적을 때 성능이 뛰어납니다.
FHIR 가져오기는 애플리케이션이 리소스 하위 집합에서 대량 오류 및 실패를 처리할 수 있을 때 높은 데이터 처리량을 달성할 수 있습니다.

FHIR 번들 사용

다음과 같은 경우에는 FHIR 가져오기 대신 FHIR 번들을 사용하세요.

청구 비용 또는 네트워크 대역폭에서 Cloud Storage에 데이터를 저장하고 가져오는 파이프라인을 빌드하는 비용이 너무 높습니다.
참조 무결성을 적용해야 합니다.
FHIR 프로필 검증을 적용해야 합니다.
FHIR 리소스가 저장될 때 Pub/Sub 알림을 보내야 합니다. FHIR 가져오기는 Pub/Sub 알림을 지원하지 않습니다.
데이터 최신 상태가 중요하고 데이터를 초 또는 분 단위로 수집해야 합니다. 그러나 잘 구성된 시스템에서도 다음으로 인해 데이터 처리량이 제한될 수 있습니다.
- 파이프라인 처리의 업스트림 지연. 파이프라인은 데이터 수집 전 데이터 처리에 더 많은 시간이 필요할 수 있습니다.
- 백오프, 재시도, 트래픽 형태 프록시 레이어

FHIR 번들은 다음과 같은 제한이 있습니다.

할당량 및 청구는 각 작업이 독립적으로 실행된 것처럼 번들의 각 작업에 적용됩니다. 예를 들어 번들에 10개의 POST 작업, 5개의 GET 작업, 1개의 DELETE 작업이 포함된 경우, 이러한 작업이 독립적으로 실행된 것처럼 번들에 적용되는 할당량 및 청구가 동일합니다.
대규모 트랜잭션 번들은 잠금 경합으로 이어지는 트랜잭션 충돌이 발생할 가능성이 높습니다. 자세한 내용은 429 Resource Exhausted operation_too_costly 오류 방지를 참조하세요.
배치 번들은 데이터 처리량을 향상시킬 수 있지만 참조 무결성과 같은 트랜잭션 일관성 기능이 없습니다.
대규모 배치 번들은 처리량이 줄어들 수 있습니다 자세한 내용은 대규모 번들 방지를 참조하세요.

DICOM 데이터 스토리지 옵션

사진 보관 및 커뮤니케이션 시스템(PACS)에서 Cloud Healthcare API로 데이터를 전송할 때는 다음 방법을 사용해서 높은 데이터 처리량을 달성할 수 있습니다.

DICOM 메시지 서비스 요소(DIMSE) 프로토콜을 사용하는 오픈소스 Cloud Healthcare API DICOM 어댑터

이 어댑터는 PACS를 Cloud Healthcare API와 동기화할 때 데이터 처리량을 최적화합니다. 동기화 전에 성능 테스트를 실행하고 어댑터가 최대 데이터 처리량을 지속할 수 있는지 확인합니다.

Storage Transfer Service 또는 다른 전송 옵션을 사용해서 Cloud Storage로 DICOM 파일을 업로드할 수 없는 경우 이 어댑터를 사용합니다. 예를 들어 다음과 같은 Storage Transfer Service 요구사항을 충족하지 못할 수 있습니다.

에이전트 풀에서 소스 데이터를 검색하기 위해 에이전트를 호스팅하는 모든 머신에 파일 시스템을 마운트합니다.
일회성 배치 로드 대신 정기적으로 데이터를 전송하는 경우 시간에 따라 데이터 크기 변화를 측정하여 변경된 내용을 확인해야 합니다.
에이전트 전송 성능 극대화
Cloud Storage 스토리지 비용 지불 및 할당
Cloud Storage에 대한 데이터 전송 검증
데이터를 Cloud Healthcare API로 가져오고 가져오기 오류를 해결한 후 Cloud Storage 리소스 삭제
의료 시스템의 네트워크 및 스토리지 용량에 따른 배치 수집 간격 예약

단일 배치 로드로 DICOM 저장소를 채우도록 Storage Transfer Service를 사용하는 것이 좋습니다. Storage Transfer Service를 정기적으로 사용하려면 동기 가져오기 파이프라인과 같은 추가 작업이 필요합니다. 자세한 내용은 Storage Transfer Service 파일 시스템 전송 세부정보를 참조하세요.

dicomStores.import

이 방법을 사용하여 대량의 DICOM 데이터 볼륨을 저장합니다.

DICOMweb 트랜잭션 저장

이 방법을 사용하여 DICOM 데이터를 프로그래매틱 방식으로 저장합니다.

할당량 관리로 데이터 처리량 최적화

다음 섹션에서는 데이터 처리량 최적화를 위한 할당량 관리 및 계획 방법을 설명합니다. 할당량 관리에 대한 일반 권장사항은 할당량 관리 권장사항을 참조하세요.

예측 가능한 트래픽의 할당량 계획

먼저 클라이언트 애플리케이션의 일반적인 일일 트래픽을 분석하여 할당량 요구사항을 계획합니다. 트래픽이 예측 가능하더라도 평균적으로 필요한 것보다 많은 할당량을 계획해야 합니다. 이렇게 하면 오류를 방지하고 트래픽 급증 또는 일일 사용량이 이따금 증가하더라도 안전하게 여유를 제공할 수 있습니다.

다음 다이어그램은 크기가 일관적이고 예측 가능한 패턴으로 전송되는 Cloud Healthcare API에 대한 요청을 보여줍니다.

최대 사용 시간과 일반적인 사용 시간 사이의 할당량 사용 비교 — **그림 1.** Google Cloud 프로젝트에서 데이터 세트 및 데이터 저장소 간의 시간별 API 로드 집계.

대규모 볼륨 요청에 대한 할당량 계획

최대 사용 시간 중에는 대규모 배치 작업을 예약하지 않아야 합니다. 자세한 내용은 일관적으로 낮은 볼륨의 트랜잭션 선호를 참조하세요.

다음 다이어그램은 예측 가능한 트래픽 패턴을 보여줍니다. 하지만 최대 트래픽 기간 중의 대규모 볼륨 일괄 요청은 사용 가능한 할당량을 초과합니다. 그 결과 프로젝트의 모든 요청에 대해 429 Resource Exhausted 오류가 발생할 수 있습니다.

최대 사용 시간과 최대 사용량이 더 높은 일반적인 사용 시간 사이의 할당량 비교 — **그림 2.** 최대 사용 시간 중 대규모 일괄 작업으로 인한 불규칙한 리소스 사용량 분산

시스템에 추가적인 유연성 할당량이 있으면 소규모 트래픽 급증으로 오류가 발생하거나 예측 가능한 최대 부하로 오류가 발생하지 않습니다. 소규모 급증은 많은 데이터 저장소, 애플리케이션, Google Cloud 프로젝트 내에서 부하를 일으키는 기타 클라이언트 사이에 분산되어야 합니다.

단일 대규모 일괄 작업이 트래픽 급증을 일으키지 않도록 방지하기 위해서는 대규모 번들 방지를 참조하세요.

추가 할당량 요청

높은 데이터 처리량을 유지하고 429 Resource Exhausted 오류를 방지하기 위해서는 이 페이지의 권장사항, 특히 할당량 관리로 데이터 처리량 최적화를 참조하세요. 이러한 권장사항은 클라이언트 애플리케이션을 강력하게 만들고 요청 볼륨 변화에 따라 확장 가능하도록 만듭니다. 권장사항을 구현하지 않고 추가 할당량을 요청하면 장기적으로 오류 방지 가능성이 저하됩니다.

권장사항을 구현해도 여전히 추가 할당량이 필요하면 추가 할당량 요청 권장사항을 참조하세요.

데이터 수집 처리량 리소스

데이터 수집 처리량에 대한 자세한 내용은 Google Cloud에서 워크로드에 대한 트래픽 및 로드 관리를 참조하세요.