네트워크 지연 시간 최적화

이 문서에서는 Cloud Healthcare API 사용에 대한 권장사항을 설명합니다. 이 페이지의 가이드라인은 서비스의 효율성, 정확성, 최적의 응답 시간을 향상시킬 수 있도록 설계되었습니다.

지연 시간 성능 이해

Cloud Healthcare API 성능은 다음 사이의 지연 시간으로 측정됩니다.

  1. Cloud Healthcare API에 요청을 보낼 때
  2. 요청에 대한 전체 응답을 받을 때

지연 시간은 다음 세 가지 구성요소로 구성됩니다.

  • 왕복 시간(RTT)
  • 서버 처리 지연 시간
  • 서버 처리량

개발자와 요청을 보내는 서버 간의 지리적 거리는 RTT와 서버 처리량에 상당한 영향을 미칠 수 있습니다. 실시간 대시보드에서 Google Cloud 네트워크에서 측정된 리전 간 지연 시간과 처리량을 확인할 수 있습니다. 대시보드는 Cloud Healthcare API 서버에 요청할 때 클라이언트가 여러 위치에서 기대할 수 있는 성능을 보여줍니다.

지연 시간 성능 측정

다음 도구와 대시 보드는 Cloud Healthcare API 서버와의 요청 성능을 측정하는 방법을 제공합니다.

  • Google Cloud Console 지연 시간 측정 항목: Google Cloud Console에서 Cloud Healthcare API 요청의 서버 측 지연 시간을 볼 수 있습니다. 자세한 내용은 Google Cloud 측정항목을 참조하세요.

  • Cloud Logging 커스텀 측정 항목: Logging을 사용하여 배포 측정항목을 만들 수 있습니다. 배포 측정항목을 사용하면 애플리케이션에서 엔드 투 엔드 지연 시간을 구성 및 이해할 수 있습니다. 또한 커스텀 정의 지연 시간 측정을 모니터링하고 보고할 수 있습니다.

  • Chrome 네트워크 패널: Chrome DevTools에서 네트워크 활동을 검사하여 브라우저에서 전송된 HTTP 요청의 성능 세부정보를 확인할 수 있습니다.

요청 지연 시간 줄이기

이 섹션에서는 Cloud Healthcare API로 전송되는 요청의 지연 시간을 줄일 수 있는 다양한 방법을 설명합니다.

가장 가까운 리전 위치로 요청 전송

RTT와 서버 처리량 성능을 최적화하려면 요청을 클라이언트에서 가장 가까운 Cloud Healthcare API 리전 위치로 보냅니다. 사용 가능한 리전 목록은 리전을 참조하세요.

응답 본문 압축

클라이언트에 대역폭이 제한되어 있는 경우 각 요청에 필요한 대역폭을 줄이는 간단한 방법은 gzip 압축을 사용 설정하는 것입니다. gzip은 데이터 압축 형식이며 일반적으로 파일 크기를 줄입니다. 이렇게 하면 압축되지 않은 경우보다 공간을 적게 사용하므로 파일을 고속으로 전송하고 저장할 수 있습니다. 파일을 압축하면 비용과 전송 시간 모두 줄일 수 있습니다.

gzip 압축을 사용 설정하려면 결과를 추출하도록 CPU 시간이 추가로 필요하지만 일반적으로 gzip 압축을 사용하면 대역폭이 절약됩니다. 그러나 제한된 대역폭이 문제가 되지 않으면 gzip 압축을 사용할 필요는 없습니다.

gzip으로 인코딩된 응답을 받으려면 요청에 Accept-Encoding 헤더를 설정해야 합니다.

다음 샘플은 gzip 압축을 사용 설정할 수 있도록 적절하게 구성된 HTTP 헤더를 보여줍니다.

Accept-Encoding: gzip

준비 요청 전송

클라이언트가 세션 중에 처음으로 Cloud Healthcare API 서버에 요청을 보내면 클라이언트는 서버와 TCP 핸드셰이크를 수행하여 HTTP 요청에 대한 연결을 설정합니다. 이후의 모든 요청은 이러한 설정된 연결을 계속 사용할 수 있으며 이를 통해 클라이언트는 일반적으로 요청과 연결된 TCP 오버헤드를 피할 수 있습니다. 이렇게 하면 요청을 보낼 때 성능이 향상됩니다.

HTTP/1.1 또는 HTTP/2와 동시에 요청 보내기

일련의 요청에 대해 최상의 성능을 얻으려면 동시에 요청을 보냅니다. 동시 요청을 보낼 때는 다음 가이드라인을 사용합니다.

  • 동시 요청을 보낼 때 동시 요청 수에 적합한 숫자를 찾아야 합니다. 적합한 숫자는 하드웨어와 네트워크 기능을 비롯한 여러 가지 요인과 전송되는 요청 수에 따라 달라집니다. 테스트를 수행하여 적합한 숫자를 찾습니다.
  • 가능하면 HTTP/2를 사용하여 클라이언트의 요청을 보냅니다. HTTP/2는 여러 요청을 순차적으로 또는 동시에 전송할 때 TCP 연결 하나만 필요하므로 HTTP/1.1보다 성능이 우수합니다. 따라서 TCP 핸드셰이크 오버헤드를 방지할 수 있습니다.

  • HTTP/2를 사용할 수 없으면 영구 연결로 HTTP/1.1을 사용합니다. 준비 요청이 이미 전송된 경우 TCP 핸드셰이크 오버헤드를 방지할 수 있습니다. 영구 연결을 사용하려면 HTTP 라이브러리의 연결 풀로 최적화된 연결을 관리해야 할 수 있습니다.

    예를 들어 자바용 Google HTTP 클라이언트 라이브러리를 사용하여 동시 요청 20개가 포함된 연결 풀을 설정하려면 코드에 다음이 포함됩니다.

    PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
// Support 20 concurrent requests.
cm.setDefaultMaxPerRoute(20);
cm.setMaxTotal(100);
HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();

    Node.js를 사용하여 동시 요청 20개가 포함된 연결 풀을 설정하려면 코드에 다음이 포함됩니다.

    require('http').globalAgent.maxSockets = 20