사용자가 만족할 만큼만 시스템을 안정적으로 설계하세요. 직관적이지 않게 보일 수 있지만 100% 안정성을 목표로 하는 것이 가장 효과적인 전략이 아닌 경우가 많습니다. 안정성을 높이면 재정적 투자와 혁신에 대한 잠재적 제한 측면에서 비용이 크게 증가할 수 있습니다. 사용자가 현재 서비스 수준에 이미 만족하고 있다면 만족도를 더 높이려는 노력의 투자수익이 낮을 수 있습니다.
대신 다른 곳에 리소스를 더 잘 사용할 수 있습니다.
사용자가 만족하는 안정성 수준을 결정하고, 추가 개선 비용이 이점보다 커지는 지점을 결정해야 합니다. 이 수준의 충분한 안정성을 확보하면 리소스를 전략적으로 할당하고 사용자에게 더 큰 가치를 제공하는 기능과 개선사항에 집중할 수 있습니다.
권장사항
현실적인 안정성 타겟을 설정하려면 다음 하위 섹션의 권장사항을 고려하세요.
일부 실패를 허용하고 구성요소에 우선순위 지정
99.99% 업타임과 같은 고가용성을 목표로 하되 100% 업타임을 목표로 설정하지는 마세요. 일부 실패는 불가피함을 인정합니다.
100% 가동시간과 99.99% 목표의 차이는 허용되는 장애입니다.
이 격차를 흔히 오류 예산이라고 합니다. 오류 예산을 사용하면 위험을 감수하고 혁신할 수 있으며 이는 모든 비즈니스가 경쟁력을 유지하는 데 필수적입니다.
시스템에서 가장 중요한 구성요소의 안정성을 우선시합니다.
덜 중요한 구성요소는 장애에 대한 허용 범위가 더 높을 수 있음을 인정합니다.
신뢰성과 비용의 균형
시스템의 최적의 안정성 수준을 확인하려면 철저한 비용 편익 분석을 실행하세요.
시스템 요구사항, 장애의 결과, 특정 애플리케이션에 대한 조직의 위험 허용 범위와 같은 요소를 고려하세요. 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)와 같은 재해 복구 측정항목을 고려해야 합니다.
예산 및 기타 제약 조건 내에서 허용되는 안정성 수준을 결정합니다.
필수적인 안정성 기능을 저해하지 않으면서 효율성을 개선하고 비용을 절감할 방법을 찾아보세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-30(UTC)"],[[["\u003cp\u003eThis principle guides the establishment of achievable reliability goals for Google Cloud workloads, focusing on the scoping aspect of reliability within the Google Cloud Well-Architected Framework.\u003c/p\u003e\n"],["\u003cp\u003eStriving for 100% reliability may not be the most effective strategy, as it can lead to increased costs and limited innovation, recommending instead to determine sufficient reliability for user satisfaction.\u003c/p\u003e\n"],["\u003cp\u003eDetermining the level of reliability where users are satisfied helps allocate resources strategically to areas that will provide a higher value to the user.\u003c/p\u003e\n"],["\u003cp\u003eAccepting that some failures are inevitable and adopting an error budget allows for innovation and risk-taking, key for business competitiveness, while also prioritizing the reliability of critical components over less crucial ones.\u003c/p\u003e\n"],["\u003cp\u003eBalancing the reliability and the cost, organizations should determine the acceptable reliability level within the budget, considering factors such as system requirements, failure consequences, and disaster recovery metrics.\u003c/p\u003e\n"]]],[],null,["# Set realistic targets for reliability\n\nThis principle in the reliability pillar of the\n[Google Cloud Well-Architected Framework](/architecture/framework)\nhelps you define reliability goals that are technically feasible for your\nworkloads in Google Cloud.\n\nThis principle is relevant to the *scoping*\n[focus area](/architecture/framework/reliability#focus-areas)\nof reliability.\n\nPrinciple overview\n------------------\n\nDesign your systems to be just reliable enough for user happiness. It might\nseem counterintuitive, but a goal of 100% reliability is often not the most\neffective strategy. Higher reliability might result in a significantly higher\ncost, both in terms of financial investment and potential limitations on\ninnovation. If users are already happy with the current level of service, then\nefforts to further increase happiness might yield a low return on investment.\nInstead, you can better spend resources elsewhere.\n\nYou need to determine the level of reliability at which your users are happy,\nand determine the point where the cost of incremental improvements begin to\noutweigh the benefits. When you determine this level of *sufficient\nreliability*, you can allocate resources strategically and focus on features and\nimprovements that deliver greater value to your users.\n\nRecommendations\n---------------\n\nTo set realistic reliability targets, consider the recommendations in the\nfollowing subsections.\n\n### Accept some failure and prioritize components\n\nAim for high availability such as 99.99% uptime, but don't set a target of 100%\nuptime. Acknowledge that some failures are inevitable.\n\nThe gap between 100% uptime and a 99.99% target is the allowance for failure.\nThis gap is often called the *error budget*. The error budget can help you take\nrisks and innovate, which is fundamental to any business to stay competitive.\n\nPrioritize the reliability of the most critical components in the system.\nAccept that less critical components can have a higher tolerance for failure.\n\n### Balance reliability and cost\n\nTo determine the optimal reliability level for your system, conduct thorough\ncost-benefit analyses.\n\nConsider factors like system requirements, the consequences of failures, and\nyour organization's risk tolerance for the specific application. Remember to\nconsider your\n[disaster recovery metrics](/architecture/dr-scenarios-planning-guide#basics_of_dr_planning),\nsuch as the recovery time objective (RTO) and recovery point objective (RPO).\nDecide what level of reliability is acceptable within the budget and other\nconstraints.\n\nLook for ways to improve efficiency and reduce costs without compromising\nessential reliability features."]]