또한 서비스에서 원하는 규정 준수 대상을 정의합니다. 일반적으로 SLO는 사용자에게 필요하거나 의미 있는 수준 이하여야 합니다. 사용자가 서비스 성능 저하를 체감할 수 있는 지점을 고려합니다. 예를 들어 사용자가 서비스의 지연 시간 300ms과 500ms 간의 차이를 알 수 없는 경우 SLO에서 지연 시간 기준저ㅁ으로 더 높은 값을 사용합니다. 이보다 낮은 값은 충족하는 데 비용이 많이 들며 사용자는 차이를 느끼지 못합니다.
규정 준수 대상을 설정할 때 서비스의 최종 사용자 요구사항을 고려합니다. 예를 들어 직원이 휴가 시간을 예약하는 데 사용하는 내부 도구는 99% 가용성 목표(연간 최대 3일의 다운타임)로 충분할 수 있습니다. 그러나 온라인 상점의 중요한 서비스에는 99.999%의 가용성(연간 최대 5분의 다운타임)이 필요할 수 있습니다.
규정 준수 기간
SLO는 SLI의 대상을 정의하는 것 외에도 SLI가 측정된 기간을 지정합니다. 예를 들어 일일 99%의 가용성은 한 달 동안 99%의 가용성과 다릅니다. 첫 번째 SLO는 14분을 초과하는 연속 다운타임(24시간 * 1%)을 허용하지 않지만 두 번째 SLO는 최대 7시간(30일 * 1%)의 연속 다운타임을 허용합니다.
규정 준수 기간은 특히 사용자와의 서비스수준계약(SLA)에 SLO가 포함된 경우 특히 중요합니다. SLA는 일반적으로 SLO를 충족하지 못함에 따른 결과를 명시하는 서비스 사용자와의 계약입니다. 사용자와 SLA가 있는지 여부는 제품 또는 비즈니스 결정사항이지만 모니터링을 위해 SLO를 만들 때 규정 준수 기간을 지정해야 합니다.
SLO를 구성할 때 규정 준수 기간 유형을 선택합니다.
캘린더: 캘린더를 마침표 유형으로 선택할 때 기간 길이도 일, 주 또는 월 중에서 지정합니다.
기간은 겹치지 않으며 캘린더 시작일 및 종료일로 고정됩니다.
규정 준수는 기간이 끝날 때만 평가될 수 있습니다.
연속: 연속을 주기 유형으로 선택하는 경우 기간 길이의 일수도 지정(예: 30일)합니다. 캘린더 기간과 달리 연속 기간에는 시작일과 종료일이 고정되어 있지 않습니다. Cloud Service Mesh는 연속 규정 준수 기간이 있는 SLO를 지속적으로 평가합니다. 이전 계산에서 가장 오래된 데이터는 새 데이터로 대체되므로 현재 계산에서 제외됩니다. 연속 기간은 월 1회가 아니라 최근 30일의 규정 준수 측정값을 매일 제공하므로 더 많은 규정 준수 측정값을 제공합니다. 하지만 SLO 상태가 매일 변경됨에 따라 서비스는 규정 준수와 위반 사이를 오갈 수 있습니다.
오류 예산
또 다른 중요한 모니터링 개념은 오류 예산입니다. SLO는 규정 준수 기간 동안 서비스의 성공 여부를 측정하는 SLI 및 타겟 값을 지정합니다. SLO의 오류 예산은 서비스가 SLO를 위반하기 전에 정책을 준수하지 않을 수 있는 총 시간을 나타냅니다. 따라서 오류 예산은 100% - SLO%입니다. 예를 들어 연속 30일 가용성 SLO의 규정 준수 목표가 99.99%인 경우, 오류 예산은 30일의 허용 된 다운타임인 4분을 겨우 넘어서는 30일간 0.01%입니다. 100% SLO를 충족하는 데 필요한 서비스에는 오류 예산이 없습니다.
오류 예산을 사용하면 서비스가 SLO를 위반하기 전까지 남은 규정 준수 기간 동안 발생할 수 있는 비정상적인 SLI 측정 횟수를 추적할 수 있습니다. 오류 예산을 사용하여 새 버전 배포와 같은 유지보수 작업을 관리할 수 있습니다. 오류 예산이 거의 소진된 경우 새 업데이트 배포와 같은 위험한 작업은 수행하지 않는 것이 좋습니다. 반대로 규정 준수 기간이 끝날 무렵 전체 오류 예산이 많이 남아 있으면 SLO를 위반할 위험이 낮으므로 새 기능을 실행하는 것이 좋습니다.
캘린더 규정 준수 기간으로 SLO를 측정하는 경우 서비스 메시는 최댓값으로 오류 예산을 시작하고 시간 경과에 따라 예산을 줄여서 오류 예산이 0 미만으로 떨어지면 SLO 위반을 트리거합니다.
규정 준수 기간이 끝나면 Cloud Service Mesh에서 SLO 오류 예산을 재설정합니다.
연속 규정 준수 기간 동안 SLO를 측정할 경우 항상 효과적으로 규정 준수 기간 끝에 있게 됩니다. 처음부터 새로 시작하는 대신 이전 데이터 포인트가 연속적으로 삭제되고 새로운 데이터 포인트가 연속적으로 추가됩니다. 규정 준수 기간 동안 규정을 준수하지 않는 기간이 시작되고 SLO를 준수하는 경우 오류 예산이 증가합니다. 언제든지 error budget ≥ 0이면 규정을 준수하는 연속 SLO 기간을 나타내고 error budget < 0이면 정책을 위반하는 연속 SLO 기간을 나타냅니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Designing SLOs\n==============\n\n| **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis page provides information that you might need before\n[creating a service level objective (SLO)](/service-mesh/docs/observability/create-slo).\n\nFor an introduction to SLOs, see the\n[Service level objectives overview](/service-mesh/docs/observability/slo-overview).\n\nSLI type and compliance targets\n-------------------------------\n\nCloud Service Mesh supports the following types of service level indicators:\n\n- **Latency**: How long it takes a service to return a response to a request, measured in milliseconds.\n- **Availability**: The fraction of the time that a service responds successfully.\n- **Other**: Customizable SLO type based on your configurable metrics.\n\nYou also define the compliance target that you want from your service. In\ngeneral, SLOs shouldn't be higher than is necessary or meaningful for your\nusers. Consider at what point users might notice service degradation. For\nexample, if your users cannot tell the difference between a latency\nof 300ms or 500ms for your service, use the higher value as the latency\nthreshold in the SLO. The lower value is more expensive to meet, and your users\nwon't notice the difference.\n\nWhen you set a compliance target, consider the end-user requirements for your\nservice. For example, an internal tool used by employees to book vacation time\nmight be fine with a 99% availability target (\\~3 days of downtime per year). But\na critical service for an online store might need 99.999% availability (\\~5\nminutes of downtime per year).\n\nCompliance periods\n------------------\n\nIn addition to defining a target for an SLI, an SLO specifies a period of time\nin which the SLI is being measured. For example, 99% availability over a single\nday is different from 99% availability over a month. The first SLO would not\npermit more than 14 minutes of consecutive downtime (24 hrs \\* 1%), whereas the\nsecond SLO would allow consecutive downtime up to \\~7 hours (30 days \\* 1%).\n\nThe compliance period is particularly important when an SLO is included in a\nservice level agreement (SLA) with your users. An SLA is a contract with the\nusers of your service that typically specifies the consequences of not meeting\nthe SLOs. Whether or not you have an SLA with your users is a product or\nbusiness decision, but for monitoring purposes, you still need to specify a\ncompliance period for your SLOs when you create them.\n\nWhen you configure SLOs, you choose the type of compliance period:\n\n- **Calendar** : When you select **Calendar** as the **Period Type** , you\n also specify the **Period Length**, which can be a day, week or month.\n Periods are non-overlapping and fixed to the calendar start and end dates.\n Compliance can only be evaluated at the end of the period.\n\n- **Rolling** : When you select **Rolling** as the **Period Type** , you\n also specify the number of days for the **Period Length**, for example, 30\n days. Unlike Calendar periods, rolling periods don't have fixed start and\n end dates. Cloud Service Mesh continually evaluates SLOs with a rolling\n compliance period. The oldest data in the previous calculation drops out of\n the current calculation as it is replaced by new data. A rolling time period\n provides more compliance measurements because each day, you get a measure of\n compliance for the last 30 days, rather than one per month. However,\n services can hover between compliance and noncompliance as the SLO status\n changes daily.\n\nError budgets\n-------------\n\nAnother important monitoring concept is the error budget. An SLO specifies an\nSLI and a target value that measures success of the service in the compliance\nperiod. The error budget for an SLO represents the total amount of time that a\nservice can be noncompliant before it is in violation of its SLO. Thus, an error\nbudget is `100% - SLO%`. For example, if you have a rolling 30-day availability\nSLO with a 99.99% compliance target, your error budget is 0.01% of 30 days:\njust over 4 minutes of allowed downtime each 30 days. A service required to meet\na 100% SLO has no error budget.\n\nError budgets let you track how many bad SLI measurements are allowed to occur\nduring the remainder of your compliance period before the service violates the\nSLO. You can use the error budget to help manage maintenance tasks like\ndeployment of new versions. When the error budget is close to depleted, it's not\na good time to take risky actions like deploying new updates. Conversely,\nif you have a full error budget near the end of a compliance period, you might\nwant launch new features since the risk of violating the SLO is lower.\n\nIf you are measuring an SLO with a calendar compliance period, Service Mesh\nstarts the error budget at the maximum value and reduces the budget over time,\ntriggering an SLO violation when the error budget drops below 0.\nCloud Service Mesh resets the SLO's error budget at the end of the\ncompliance period.\n\nIf you are measuring an SLO over a rolling compliance period, you are\neffectively always at the end of a compliance period. Rather than starting from\nscratch, old data points are continuously dropped and new data points are\ncontinuously added. If a period of poor compliance rolls out of the compliance\nwindow, and if the SLO is compliant, the error budget goes up. At any point in\ntime, an `error budget ≥ 0` indicates a compliant rolling SLO window, and an\n`error budget \u003c 0` indicates a non-compliant rolling SLO window.\n\nWhat's next\n-----------\n\n- Learn more about SLOs from Site Reliability Engineering at Google:\n\n - [Site Reliability Engineering](https://sre.google/sre-book/service-level-objectives/)\n - [The Site Reliability Workbook](https://sre.google/workbook/implementing-slos/)\n- [Create SLOs](/service-mesh/docs/observability/create-slo)\n\n- [Monitor SLOs](/service-mesh/docs/observability/monitor-slo)"]]
