탄력성을 사용하면 시스템의 여러 구성요소를 독립적으로 확장할 수 있습니다. 이 타겟팅된 확장 기능을 사용하면 리소스를 과도하게 프로비저닝하거나 부족하게 프로비저닝하지 않고 필요한 곳에 정확하게 할당하여 성능과 비용 효율성을 개선할 수 있습니다.
원칙 개요
시스템의 성능 요구사항은 시스템이 언제 어떻게 수직으로 확장되거나 수평으로 확장되는지에 직접적인 영향을 미칩니다. 시스템의 용량을 평가하고 시스템이 기준에서 처리해야 하는 부하를 결정해야 합니다.
그런 다음 시스템이 부하 증가 및 감소에 어떻게 대응해야 하는지 결정해야 합니다.
부하가 증가하면 시스템은 수평으로 확장하거나, 수직으로 확장하거나, 둘 다 실행해야 합니다. 수평 확장의 경우 시스템이 증가한 수요를 충족할 수 있는 충분한 전체 용량을 갖도록 복제본 노드를 추가합니다. 수직 확장의 경우 애플리케이션의 기존 구성요소를 용량, 메모리, 스토리지가 더 많은 구성요소로 대체합니다.
부하가 감소하면 시스템은 축소되어야 합니다 (가로, 세로 또는 둘 다).
시스템이 확장되거나 축소되는 상황을 정의합니다. 트래픽이 많은 것으로 알려진 기간에 시스템을 수동으로 확장할 계획을 세우세요. 부하의 증가 또는 감소에 대응하는 자동 확장과 같은 도구를 사용합니다.
권장사항
탄력성을 활용하려면 다음 섹션의 권장사항을 고려하세요.
최대 부하 기간 계획
예상되는 고객 수요 증가 기간과 같은 알려진 이벤트에 대해 효율적인 확장 경로를 계획해야 합니다.
트래픽이 많은 것으로 알려진 기간 전에 시스템을 확장하는 것이 좋습니다. 예를 들어 소매 조직의 경우 시즌별 할인 기간에 수요가 증가할 것으로 예상됩니다. 시스템이 증가된 부하를 즉시 처리하거나 기존 한도를 즉시 조정할 수 있도록 이러한 판매 전에 시스템을 수동으로 확장하는 것이 좋습니다. 그렇지 않으면 시스템에서 실시간 변경사항에 따라 리소스를 추가하는 데 몇 분 정도 걸릴 수 있습니다. 애플리케이션의 용량이 충분히 빠르게 증가하지 않아 일부 사용자에게 지연이 발생할 수 있습니다.
수요 또는 트래픽의 급증과 같은 알 수 없거나 예상치 못한 이벤트의 경우 자동 확장 기능을 사용하여 측정항목을 기반으로 탄력적 확장을 트리거할 수 있습니다. 이러한 측정항목에는 CPU 사용률, 부하 분산기 처리 용량, 지연 시간, Cloud Monitoring에서 정의한 커스텀 측정항목이 포함될 수 있습니다.
예를 들어 Compute Engine 관리형 인스턴스 그룹 (MIG)에서 실행되는 애플리케이션을 생각해 보세요. 이 애플리케이션에는 평균 CPU 사용률이 75%에 도달할 때까지 각 인스턴스가 최적으로 실행되어야 한다는 요구사항이 있습니다. 이 예에서는 CPU 사용률이 기준점에 도달하면 인스턴스를 더 많이 만드는 자동 확장 정책을 정의할 수 있습니다.
새로 생성된 인스턴스는 부하를 흡수하여 MIG에 구성된 최대 인스턴스 수에 도달할 때까지 평균 CPU 사용률이 최적의 비율로 유지되도록 지원합니다. 수요가 감소하면 자동 확장 정책에서 더 이상 필요하지 않은 인스턴스를 삭제합니다.
시스템 구성요소에 Compute Engine이 포함된 경우 예측 자동 확장이 워크로드에 적합한지 평가해야 합니다. 예측 자동 확장은 측정항목의 과거 추세(예: CPU 사용률)를 기반으로 향후 부하를 예측합니다.
예측은 몇 분마다 다시 계산되므로 자동 확장 처리에서 최근의 부하 변동에 맞게 예측을 빠르게 조정할 수 있습니다. 예측 자동 확장을 사용하지 않으면 자동 확장 처리는 실시간으로 부하에서 관찰된 변경사항을 기준으로 대응적으로 그룹만 확장할 수 있습니다. 예측 자동 확장은 실시간 데이터와 이전 데이터를 모두 사용하여 현재 및 예상 부하에 대응합니다.
서버리스 아키텍처 구현
다음과 같이 본질적으로 탄력적인 서버리스 서비스를 사용하여 서버리스 아키텍처를 구현하는 것이 좋습니다.
규칙을 미세 조정해야 하는 다른 서비스 (예: Compute Engine)의 자동 확장과 달리 서버리스 자동 확장은 즉시 실행되며 리소스를 0으로 축소할 수 있습니다.
Kubernetes에 Autopilot 모드 사용
Kubernetes에 대한 더 큰 제어가 필요한 복잡한 애플리케이션의 경우 Google Kubernetes Engine (GKE)의 Autopilot 모드를 고려하세요.
Autopilot 모드는 기본적으로 자동화와 확장성을 제공합니다.
GKE는 트래픽에 따라 노드와 리소스를 자동으로 확장합니다. GKE는 노드를 관리하고, 애플리케이션에 새 노드를 만들고, 자동 업그레이드와 복구를 구성합니다.
[[["이해하기 쉬움","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-06(UTC)"],[[["\u003cp\u003eElasticity allows systems to dynamically adjust resources based on workload changes, enabling independent scaling of different components for improved performance and cost efficiency.\u003c/p\u003e\n"],["\u003cp\u003eSystems should be designed to scale both horizontally by adding replica nodes and vertically by increasing capacity, memory, and storage, in response to increases and decreases in load.\u003c/p\u003e\n"],["\u003cp\u003ePlanning for peak load periods involves manually scaling systems ahead of known high-traffic events, and using autoscaling for unexpected surges, triggered by metrics like CPU utilization.\u003c/p\u003e\n"],["\u003cp\u003ePredictive autoscaling can be used in Compute Engine, which forecasts future load based on historical trends and adapts rapidly to recent changes in load, improving responsiveness.\u003c/p\u003e\n"],["\u003cp\u003eImplementing serverless architectures, such as Cloud Run, BigQuery, and Spanner, provides inherent elasticity with instant autoscaling that can scale down to zero resources, and using Autopilot mode in GKE provides automation and scalability by default.\u003c/p\u003e\n"]]],[],null,["# Take advantage of elasticity\n\nThis principle in the performance optimization pillar of the\n[Google Cloud Well-Architected Framework](/architecture/framework)\nprovides recommendations to help you incorporate elasticity, which is the ability\nto adjust resources dynamically based on changes in workload requirements.\n\nElasticity allows different components of\na system to scale independently. This targeted scaling can help improve performance and\ncost efficiency by allocating resources precisely where they're needed, without\nover provisioning or under provisioning your resources.\n\nPrinciple overview\n------------------\n\nThe performance requirements of a system directly influence when and how the\nsystem scales vertically or scales horizontally. You need to evaluate the system's\ncapacity and determine the load that the system is expected to handle at baseline.\nThen, you need to determine how you want the system to respond to increases and decreases\nin the load.\n\nWhen the load increases, the system must scale out horizontally, scale up\nvertically, or both. For horizontal scaling, add replica nodes to ensure that\nthe system has sufficient overall capacity to fulfill the increased demand. For\nvertical scaling, replace the application's existing components with components\nthat contain more capacity, more memory, and more storage.\n\nWhen the load decreases, the system must scale down (horizontally, vertically,\nor both).\n\nDefine the *circumstances* in which the system scales up or scales down. Plan to\nmanually scale up systems for known periods of high traffic. Use tools like\nautoscaling, which responds to increases or decreases in the load.\n\nRecommendations\n---------------\n\nTo take advantage of elasticity, consider the recommendations in the following\nsections.\n\n### Plan for peak load periods\n\nYou need to plan an efficient scaling path for known events, such as expected\nperiods of increased customer demand.\n\nConsider scaling up your system ahead of known periods of high traffic. For\nexample, if you're a retail organization, you expect demand to increase during\nseasonal sales. We recommend that you manually scale up or scale out your systems before\nthose sales to ensure that your system can immediately handle the increased load\nor immediately adjust existing limits. Otherwise, the system might take several minutes to\nadd resources in response to real-time changes. Your application's capacity\nmight not increase quickly enough and cause some users to experience delays.\n\nFor unknown or unexpected events, such as a sudden surge in demand or traffic,\nyou can use autoscaling features to trigger elastic scaling that's based on\nmetrics. These metrics can include CPU utilization, load balancer serving\ncapacity, latency, and even custom metrics that you define in\n[Cloud Monitoring](/monitoring/docs/monitoring-overview).\n\nFor example, consider an application that runs on a\n[Compute Engine](/compute/docs/overview)\nmanaged instance group (MIG). This application has a requirement that each instance performs\noptimally until the average CPU utilization reaches 75%. In this example, you\nmight define an\n[autoscaling policy](/compute/docs/autoscaler#autoscaling_policy)\nthat creates more instances when the CPU utilization reaches the threshold.\nThese newly-created instances help absorb the load, which helps ensure that the average\nCPU utilization remains at an optimal rate until the maximum number of instances\nthat you've configured for the MIG is reached. When the demand decreases, the\nautoscaling policy removes the instances that are no longer needed.\n\nPlan\n[resource slot reservations in BigQuery](/bigquery/docs/reservations-intro#reservations)\nor adjust the limits for autoscaling configurations in Spanner by using the\n[managed autoscaler](/spanner/docs/managed-autoscaler).\n\n### Use predictive scaling\n\nIf your system components include Compute Engine, you must evaluate whether\n[predictive autoscaling](/compute/docs/autoscaler#predictive_mode)\nis suitable for your workload. Predictive autoscaling forecasts the future load\nbased on your metrics' historical trends---for example, CPU utilization.\nForecasts are recomputed every few minutes, so the autoscaler rapidly adapts its\nforecast to very recent changes in load. Without predictive autoscaling, an\nautoscaler can only scale a group reactively, based on observed real-time changes\nin load. Predictive autoscaling works with both real-time data and\nhistorical data to respond to both the current and the forecasted load.\n\n### Implement serverless architectures\n\nConsider implementing a serverless architecture with serverless services that\nare inherently elastic, such as the following:\n\n- [Cloud Run](/run/docs)\n- [Cloud Run functions](/functions/docs)\n- [BigQuery](/bigquery/docs)\n- [Spanner](/spanner/docs)\n- [Eventarc](/eventarc/docs)\n- [Workflows](/workflows/docs)\n- [Pub/Sub](/pubsub/docs)\n\nUnlike autoscaling in other services that require fine-tuning rules (for\nexample, Compute Engine), serverless autoscaling is instant and can\nscale down to zero resources.\n\n### Use Autopilot mode for Kubernetes\n\nFor complex applications that require greater control over Kubernetes, consider\n[Autopilot mode in Google Kubernetes Engine (GKE)](/kubernetes-engine/docs/concepts/autopilot-overview).\nAutopilot mode provides automation and scalability by default.\nGKE automatically scales nodes and resources based on\ntraffic. GKE manages nodes, creates new nodes for your applications, and\nconfigures automatic upgrades and repairs."]]
