이 페이지에서는 Cloud Load Balancing에서 제공되는 부하 분산기 유형을 검토하고 부하 분산기에서 SLI로 노출한 Cloud Monitoring 측정항목을 사용하는 방법을 설명합니다.
Cloud Load Balancing 서비스는 종종 Google Cloud에서 호스팅되는 애플리케이션의 첫 번째 진입점을 제공합니다. 부하 분산기는 노출하는 Google Cloud 서비스의 트래픽, 가용성, 지연 시간에 대한 정보를 제공하도록 자동으로 계측됩니다. 따라서 부하 분산기는 애플리케이션을 계측할 필요가 없는 훌륭한 SLI 측정항목 소스로 작동하는 경우가 많습니다.
시작할 때 안정성에 대한 기본 측정기준으로 가용성과 지연 시간에 집중하고 이러한 측정기준을 측정하고 알리도록 SLI와 SLO를 만들 수 있습니다. 이 페이지에서는 구현 예시를 제공합니다.
자세한 내용은 다음을 참조하세요.
가용성 SLI 및 SLO
UDP 이외 애플리케이션의 경우 요청 기반 가용성 SLI가 가장 적합합니다. 서비스 상호작용이 요청에 깔끔하게 매핑되기 때문입니다.
다음 가용성 예시와 같이 TimeSeriesRatio 구조를 사용하여 총 요청에 대한 양호한 요청의 비율을 설정하여 요청 기반 가용성 SLI를 표현합니다.
'양호' 또는 '유효' 중 원하는 결과를 얻으려면 사용 가능한 라벨을 사용하여 측정항목을 필터링합니다.
외부 레이어 7(HTTP/S) 부하 분산기
HTTP/S 부하 분산기는 HTTP/S를 통해 액세스되는 애플리케이션을 노출하고 트래픽을 여러 리전에 있는 리소스에 분산하는 데 사용됩니다.
외부 애플리케이션 부하 분산기는 https_lb_rule 모니터링 리소스 유형과 프리픽스 loadbalancing.googleapis.com이 있는 측정항목 유형을 사용하여 측정항목 데이터를 Monitoring에 기록합니다. 가용성 SLO와 가장 관련성이 높은 측정항목 유형은 https/request_count이며 response_code_class 측정항목 라벨을 사용하여 필터링할 수 있습니다.
4xx 오류 응답 코드를 '유효'로 반환하는 요청 수를 서비스 오류나 애플리케이션 오류가 아닌 클라이언트 오류로 나타낼 수 있으므로 이러한 요청을 계산하지 않으려면 다음과 같이 '총' 필터를 작성하면 됩니다.
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
또한 '양호' 요청 수를 계산하는 방법을 결정해야 합니다. 예를 들어 200 OK 성공 상태 응답 코드를 반환하는 요청 수만 계산하려면 다음과 같이 '양호' 필터를 작성하면 됩니다.
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
그러면 요청 기반 SLI를 다음과 같이 표현할 수 있습니다.
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
트래픽이 여러 백엔드에서 제공되는 애플리케이션의 경우 특정 백엔드에 SLI를 정의할 수 있습니다. 특정 백엔드의 가용성 SLI를 만들려면 이 예시와 같이 필터에 backend_target_name 리소스 라벨이 있는 https/backend_request_count 측정항목을 사용합니다.
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
내부 레이어 7(HTTP/S) 부하 분산기
내부 애플리케이션 부하 분산기는 internal_http_lb_rule 모니터링 리소스 유형과 프리픽스 loadbalancing.googleapis.com이 있는 측정항목 유형을 사용하여 측정항목 데이터를 Monitoring에 기록합니다. 가용성 SLO와 가장 관련성이 높은 측정항목 유형은 https/internal_request_count이며 response_code_class 측정항목 라벨을 사용하여 필터링할 수 있습니다.
다음에서는 요청 기반 가용성 SLI의 예시를 보여줍니다.
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Layer 3(TCP) 부하 분산기
TCP 부하 분산기는 요청 측정항목을 사용하는 애플리케이션이 요청-응답 모델을 따르지 않을 수 있으므로 요청 측정항목을 제공하지 않습니다. 이러한 부하 분산기에서 제공하는 loadbalancing.googleapis.com 측정항목 중 가용성 SLI에 적합한 측정항목은 없습니다.
이러한 부하 분산기의 가용성 SLI를 만들려면 커스텀 또는 로그 기반 측정항목을 만들어야 합니다. 자세한 내용은 커스텀 측정항목 사용 또는 로그 기반 측정항목 사용을 참조하세요.
지연 시간 SLI 및 SLO
요청-응답 애플리케이션의 경우 지연 시간 SLO를 작성하는 방법에는 두 가지가 있습니다.
- 요청 기반 SLO
- 기간 기반 SLO
요청 기반 지연 시간 SLO
요청 기반 SLO는 지연 시간 임곗값을 적용하고 특정 규정 준수 기간 내 임곗값으로 완료한 요청의 비율을 계산합니다. 요청 기반 SLO의 예시는 '1시간 내 100ms 이내로 요청의 99% 완료'입니다.
다음 지연 시간 예시와 같이 DistributionCut 구조를 사용하여 요청 기반 지연 시간 SLI를 표현합니다.
단일 요청 기반 SLO는 일반적인 성능과 사용자 환경 저하를 모두 캡처할 수 없습니다. 여기서 '꼬리'나 가장 느린 요청에서 응답 시간이 점점 길어집니다. 일반적인 성능의 SLO는 꼬리 지연 시간 이해를 지원하지 않습니다. 꼬리 지연 시간에 대한 자세한 내용은 사이트 안정성 엔지니어링의 6장: 분산 시스템 모니터링에 있는 '꼬리에 대한 걱정' 섹션을 참조하세요.
이러한 제한사항을 완화하려면 두 번째 SLO를 작성하여 특별히 꼬리 지연 시간에 집중하면 됩니다. 예를 들어 '1시간 동안 1,000ms 이내에 요청의 99.9% 완료'입니다. 두 SLO를 조합하면 일반적인 사용자 환경과 꼬리 지연 시간 모두에서 저하를 캡처할 수 있습니다.
기간 기반 지연 시간 SLO
기간 기반 SLO는 측정 기간의 양호 기준을 정의하고 총 간격 수에 대한 '양호' 간격 비율을 계산합니다. 기간 기반 SLO의 예시는 '95번째 백분위수 지연 시간 측정항목이 28일 기간 동안 1분 기간의 최소 99%에서 100ms 미만'입니다.
- '양호' 측정 기간은 요청의 95%에 100ms 미만 지연 시간이 있는 1분 스팬입니다.
- 규정 준수 측정은 이러한 '양호' 기간의 비율입니다. 규정 준수 기간 동안 계산된 이 비율이 최소 0.99 이상이면 서비스가 규정을 준수하는 것입니다.
사용 가능한 원시 측정항목이 지연 시간 백분위인 경우 즉, 다음 조건이 모두 참이면 기간 기반 SLO를 사용해야 합니다.
- 데이터는 기간(예: 1분 간격)으로 분류됩니다.
- 데이터는 백분위수 그룹(예: p50, p90, p95, p99)으로 표현됩니다.
이러한 종류의 데이터에서 각 백분위수 그룹은 해당 백분위수 위 또는 아래의 데이터 그룹을 나누는 시간을 나타냅니다. 예를 들어 p95 지연 시간 측정항목이 89ms인 1분 간격은 1분 동안 서비스가 89ms 이하의 응답 95%에 응답했음을 나타냅니다.
외부 애플리케이션 부하 분산기
외부 애플리케이션 부하 분산기는 다음 기본 측정항목 유형을 사용하여 지연 시간을 캡처합니다.
https/total_latencies: 프록시에서 요청을 수신한 시점부터 프록시가 마지막 응답 바이트의 클라이언트에서 ACK를 수신할 때까지가 계산된 지연 시간의 분포입니다. 전반적인 사용자 환경이 중요한 경우에 사용합니다.https/backend_latencies: 프록시에서 요청을 백엔드로 전송한 때부터 프록시가 백엔드에서 응답의 마지막 바이트를 수신할 때까지가 계산된 지연 시간의 분포입니다. 부하 분산기 뒤에 트래픽을 제공하는 특정 백엔드의 지연 시간을 측정하는 데 사용합니다.
이러한 측정항목은 https_lb_rule 모니터링 리소스 유형에서 작성됩니다.
총 지연 시간
이 예시 SLO는 요청의 99%가 1시간 동안 총 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
백엔드 지연 시간
이 예시 SLO는 'my-app-backend' 백엔드 대상에 대한 요청의 98%가 1시간 동안 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
내부 애플리케이션 부하 분산기
내부 애플리케이션 부하 분산기는 2가지 기본 측정항목 유형을 사용하여 지연 시간을 캡처합니다.
https/internal/total_latencies: 프록시에서 요청을 수신한 시점부터 프록시가 마지막 응답 바이트의 클라이언트에서 ACK를 수신할 때까지가 계산된 지연 시간의 분포입니다. 전반적인 사용자 환경이 중요한 경우에 사용합니다.https/internal/backend_latencies: 프록시에서 요청을 백엔드로 전송한 때부터 프록시가 백엔드에서 응답의 마지막 바이트를 수신할 때까지가 계산된 지연 시간의 분포입니다. 부하 분산기 뒤에 트래픽을 제공하는 특정 백엔드의 지연 시간을 측정하는 데 사용합니다.
이러한 측정항목은 internal_http_lb_rule 모니터링 리소스 유형에서 작성됩니다.
총 지연 시간
이 예시 SLO는 요청의 99%가 1시간 동안 총 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
이 예시 SLO는 요청의 99%가 1시간 동안 총 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
백엔드 지연 시간
이 예시 SLO는 'my-internal-backend' 백엔드 대상에 대한 요청의 98%가 1시간 동안 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
외부 Layer 3(TCP) 부하 분산기
외부 TCP 부하 분산기는 외부 부하 분산기 흐름의 TCP 연결을 통해 측정된 왕복 시간 분산을 기록하는 단일 측정항목 유형인 l3/external/rtt_latencies를 사용합니다.
이 측정항목은 tcp_lb_rule 리소스에 대해 작성됩니다.
이 예시 SLO는 요청의 99%가 1시간 동안 총 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
내부 Layer 3(TCP) 부하 분산기
내부 TCP 부하 분산기는 내부 부하 분산기 흐름의 TCP 연결을 통해 측정된 왕복 시간 분산을 기록하는 단일 측정항목 유형인 l3/internal/rtt_latencies를 사용합니다.
이 측정항목은 internal_tcp_lb_rule 리소스에 대해 작성됩니다.
이 예시 SLO는 요청의 99%가 1시간 동안 총 지연 시간의 0~100ms 사이에 속할 것으로 예상합니다.
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}