요청 지연 시간 및 오류 처리 권장사항

이 페이지에서는 Cloud Healthcare API에서 요청 지연 시간을 최적화하고 오류를 처리하기 위한 권장사항에 대해 설명합니다. 시스템 아키텍처를 계획하고 설계할 때 이러한 권장사항을 구현합니다.

Google은 Cloud Healthcare API 서비스의 예상 업타임 및 클라이언트의 오류 처리 방법을 정의하는 서비스수준계약(SLA)을 제공합니다. 자세한 내용은 Cloud Healthcare 서비스수준계약(SLA)을 참조하세요.

재시도 로직 및 제한 시간 구현

요청 실패로 인한 지연과 오류를 처리하려면 적절한 재시도 로직과 제한 시간을 구현합니다. 제한 시간을 설정할 때 충분한 시간을 두어 다음을 수행합니다.

Cloud Healthcare API에서 요청을 처리하도록 합니다.
오류가 서비스나 클라이언트에서 발생했는지 확인합니다.

일부 오류를 재시도할 수 있지만 다른 오류는 재시도가 불가능하며 여러 번 재시도해도 유지됩니다. 예를 들어 요청 데이터 형식이 잘못된 경우 서버는 400 Bad Request 상태 코드로 응답합니다. 데이터를 수정하기 전에는 요청이 성공하지 않습니다.

이러한 상황을 처리하기 위해서는 최종 오류 상태를 계획해야 합니다.

재시도 로직 및 제한 시간에 대한 자세한 내용은 실패한 요청 재시도를 참조하세요.

여러 레이어에서 오류 처리

미들웨어가 Cloud Healthcare API와 상호작용할 때 클라이언트와 미들웨어에 재시도 로직 및 제한 시간을 구현합니다. 클라이언트에서 재시도 한도를 초과하여 오류가 발생하면 클라이언트, 미들웨어 또는 기본 Cloud Healthcare API 서비스에서 오류가 발생했는지 여부를 식별할 수 있어야 합니다. 이는 특히 최종 오류 상태를 계획할 때 중요합니다.

다음 상황을 살펴보세요.

요청을 전송할 때 미들웨어가 Cloud Healthcare API에서 500 Internal Server Error 오류를 수신합니다.
미들웨어 레이어는 요청을 5회 더 재시도하고 한도에 도달하면 재시도를 중지합니다.
클라이언트에 최종 500 Internal Server Error 오류가 수신됩니다.

미들웨어가 아닌 Cloud Healthcare API에서 오류가 발생했음을 이해하는 것이 중요합니다. 디버깅을 간소화하려면 클라이언트에 반환된 오류에 이 정보를 제공합니다.

다음 다이어그램에서는 요청을 클라이언트에서 Cloud Healthcare API로 전달할 때 미들웨어 프록시가 500 Internal Server Error 오류를 수신하는 시나리오를 보여줍니다. 클라이언트와 프록시 모두 오류 처리 및 재시도를 구현합니다.

클라이언트/미들웨어/서버 스택에서 오류를 처리하는 위치를 보여주는 다이어그램입니다. — **그림 1.** 재시도 로직 및 제한 시간을 구현하는 데 필요한 레이어는 **클라이언트** 및 **프록시**입니다.

그림 1은 다음 단계를 보여줍니다.

클라이언트가 미들웨어 프록시를 통해 Cloud Healthcare API에 유효한 요청을 보냅니다.
프록시가 요청을 Cloud Healthcare API로 전달합니다.
Cloud Healthcare API가 500 Internal Server Error 오류를 프록시에 반환합니다. 프록시는 재시도 한도에 도달할 때까지 요청을 5회 더 재시도합니다.
프록시는 클라이언트에 최종 오류 상태 500 Internal Server Error를 반환합니다.

앞에서 설명한 권장사항을 사용하면 프록시가 클라이언트에 다음 오류를 반환하도록 하여 최종 오류 상태를 디버깅할 수 있습니다.
```
Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error
```
Cloud Healthcare API에서 반환된 오류에 대한 정보를 더 추가합니다.

경우에 따라 클라이언트나 프록시가 재시도 한도를 초과하여 500 Internal Server Error 오류를 수신하며 재시도할 수 없습니다. 이러한 경우에는 개발자가 개입해서 오류가 프록시나 Cloud Healthcare API에서 시작되었는지 진단해야 할 수 있습니다.

재시도할 오류 선택

시스템 아키텍처에 따라 특정 오류를 재시도하고 다른 오류는 무시할 수 있습니다. 다음은 재시도 가능한 Cloud Healthcare API 오류 코드의 일부 목록입니다.

408 Request Timeout
425 Too Early
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

이러한 오류는 일반적으로 동일한 빈도로 발생하지 않으며 일부는 발생하지 않을 수 있습니다.

시스템 아키텍처 효과

시스템 아키텍처는 오류 재시도 방법과 시기에 영향을 줍니다.

예를 들어 직접 클라이언트-서버 아키텍처에서 Cloud Healthcare API로부터 401 UNAUTHENTICATED 오류를 수신하는 클라이언트는 요청을 다시 인증하고 재시도할 수 있습니다.

시스템에 클라이언트와 Cloud Healthcare API 사이에 미들웨어 레이어가 있다고 가정해 보겠습니다. 클라이언트가 올바르게 인증되었고 만료된 인증 토큰으로 인해 문제가 발생한 경우 미들웨어는 토큰을 새로고침하고 요청을 재시도해야 합니다.

최종 오류 상태를 분석한 후 발견 항목에 따라 클라이언트에서 재시도하는 오류를 조정할 수 있습니다.

최종 오류 상태 계획

재시도 로직과 제한 시간을 구현한 후에도 클라이언트나 미들웨어는 재시도가 소진될 때까지 오류를 수신할 수 있습니다. 재시도와 제한 시간이 소진되기 전에 반환되는 마지막 오류가 최종 오류 상태입니다. 데이터 일관성 오류의 최종 오류 상태가 발생할 수 있습니다.

최종 오류 상태에 사람이 개입해야 하는 경우가 있습니다. 요청의 최종 오류 상태를 확인할 수 있는 방법을 구현해보세요. 그렇지 않으면 사람이 검토할 수 있도록 최종 오류 상태를 로깅합니다.

최종 오류 상태를 처리하는 방법을 계획할 때 다음 사항을 고려합니다.

FHIR 트랜잭션이나 번들을 성공적으로 완료할 수 없을 때 중지해야 하는 처리 종속 항목이 있나요?
여러 가상 머신(VM) 인스턴스가 영구적으로 실패하기 시작하면 클라이언트에서 실패한 요청을 보고해야 합니다. 문제가 해결되면 클라이언트에서 요청을 재시도해야 합니다.
시스템 안정성을 보장하려면 모니터링, 알림 시스템, 서비스 수준 목표(SLO)가 필요합니다. 자세한 내용은 테스트 및 모니터링을 참조하세요.

지연 시간 증가 계획

Cloud Healthcare API는 확장 가능하고 성능이 뛰어난 서비스이지만 다음과 같은 이유로 인해 요청 지연 시간이 달라질 수 있습니다.

중요하지 않은 것으로 보이는 요청 간 사소한 차이로 인해 처리 시간이 추가될 수 있습니다.
비슷한 요청에서 지연 시간이 다를 수 있습니다. 예를 들어 데이터 스토리지에 레코드를 추가하는 두 가지 비슷한 요청에서 한 요청이 추가 스토리지 할당과 같은 추가 태스크를 트리거하는 임곗값을 초과할 경우 이러한 요청의 지연 시간이 다를 수 있습니다.
Cloud Healthcare API는 많은 요청을 동시에 처리합니다. 1초 미만의 시간으로 측정되는 클라이언트가 요청을 전송하는 시간이 Cloud Healthcare API가 평소보다 많은 로드로 작동하는 시간과 일치할 수 있습니다.
디스크와 같은 Cloud Healthcare API 물리적 리소스에서 여러 요청을 처리하는 경우 다른 요청을 처리하기 전에 큐에 추가된 태스크를 완료해야 합니다.
경우에 따라 Cloud Healthcare API가 서버 측에서 오류를 재시도하여 클라이언트 지연 시간이 증가할 수 있습니다.
리전 또는 멀티 리전 위치에 있는 여러 데이터 센터에 여러 데이터 사본이 있을 수 있습니다. 요청이 원래 요청 또는 재시도에 따라 여러 데이터 센터를 통해 라우팅될 경우 지연 시간이 증가할 수 있습니다.

백분위수 지연 시간 사용 계획

요청의 백분위수 지연 시간을 분석하여 지연 시간 증가를 계획할 수 있습니다. 다음 예시에서는 50번째 백분위수 지연 시간 및 99번째 백분위수 지연 시간에 대해 설명합니다.

50번째 백분위수 지연 시간은 요청의 가장 빠른 50%에 대한 최대 지연 시간(초)입니다. 예를 들어 50번째 백분위수 지연 시간이 0.5초라면 Cloud Healthcare API가 0.5초 내에 요청의 50%를 처리한 것입니다. 50번째 백분위수 지연 시간을 '지연 시간 중앙값'이라고도 부릅니다.
99번째 백분위수 지연 시간은 요청의 가장 빠른 99%에 대한 최대 지연 시간(초)입니다. 예를 들어 99번째 백분위수 지연 시간이 2초인 경우 Cloud Healthcare API가 2초 내에 요청의 99%를 처리한 것입니다.

Cloud Healthcare API가 소수의 요청만 처리할 때 간격에 대한 백분위수 지연 시간을 분석하는 경우 이상점 요청이 큰 영향을 받을 수 있으므로 백분위수 지연 시간이 유용하지 않거나 전체 성능을 나타내지 못을 수 있습니다.

예를 들어 Cloud Healthcare API의 한 프로세스에서 100분 동안 요청 100개를 처리한다고 가정해 보겠습니다. 100분 동안의 99번째 백분위수 지연 시간은 가장 느린 단일 요청을 기반으로 합니다. 단일 요청을 사용하는 지연 시간 측정은 성능 문제가 있는지 이해하는 데 부족합니다.

더 긴 기간(예: 24시간) 동안 더 큰 요청 샘플을 수집하면 시스템의 전체 동작에 대한 유용한 정보를 얻을 수 있습니다. 이러한 샘플을 사용하여 시스템이 과도한 트래픽에 대응하는 방법을 결정할 수 있습니다.