성능 최적화는 일반적으로 지연 시간 및 처리량과 관련된 주요 측정항목을 식별하는 것으로 시작합니다. 이러한 측정항목을 캡처하고 추적하는 모니터링을 추가하면 애플리케이션의 약점이 드러납니다. 측정항목을 사용하면 실적 측정항목을 개선하기 위해 최적화를 수행할 수 있습니다.
또한 많은 모니터링 도구에서 특정 기준이 충족될 때 알림을 받도록 측정항목에 대한 알림을 설정할 수 있습니다. 예를 들어 실패한 요청의 비율이 정상 수준의 x% 이상 증가하면 알림을 받도록 설정할 수 있습니다. 모니터링 도구를 사용하면 정상적인 성능을 파악하고 지연 시간, 오류 수, 기타 주요 측정항목의 비정상적인 급증을 식별할 수 있습니다. 이러한 측정항목을 모니터링하는 기능은 비즈니스에 중요한 기간이나 새 코드가 프로덕션에 푸시된 후에 특히 중요합니다.
지연 시간 측정항목 식별
사용자는 모바일 앱에 훨씬 더 높은 기준을 기대하므로 UI의 응답성을 최대한 높여야 합니다. 지연 시간은 백엔드 서비스에 대해서도 측정하고 추적해야 합니다. 특히 지연 시간을 확인하지 않으면 처리량 문제가 발생할 수 있기 때문입니다.
추적할 측정항목은 다음과 같습니다.
요청 기간
서브시스템 세부사항 (예: API 호출)의 요청 기간
작업 기간
처리량 측정항목 식별
처리량은 특정 기간 동안 처리된 총 요청 수를 측정한 값입니다. 처리량은 하위 시스템의 지연 시간에 영향을 받을 수 있으므로 지연 시간을 최적화하여 처리량을 개선해야 할 수 있습니다.
추적할 수 있는 측정항목은 다음과 같습니다.
초당 쿼리 수
초당 전송된 데이터 크기
초당 I/O 작업 수
리소스 사용률(예: CPU 또는 메모리 사용량)
처리 백로그 크기(예: pub/sub 또는 스레드 수)
평균뿐만 아니라
성능을 측정할 때 흔히 저지르는 실수는 평균 사례만 살펴보는 것입니다. 이는 유용하지만 지연 시간의 분포에 관한 통계는 제공하지 않습니다. 추적하기에 더 나은 측정항목은 측정항목의 50번째/75번째/90번째/99번째 백분위수와 같은 성능 백분위수입니다.
일반적으로 최적화는 두 단계로 진행할 수 있습니다. 먼저 90번째 백분위수 지연 시간에 최적화합니다. 그런 다음 99번째 백분위수(테일 지연 시간이라고도 함)를 고려합니다. 이는 완료하는 데 훨씬 더 오래 걸리는 요청의 작은 부분입니다.
자세한 결과를 위한 서버 측 모니터링
일반적으로 측정항목을 추적하는 데는 서버 측 프로파일링이 선호됩니다. 서버 측은 일반적으로 계측하기가 훨씬 쉽고, 더 세부적인 데이터에 액세스할 수 있으며, 연결 문제로 인한 교란이 적습니다.
엔드 투 엔드 가시성을 위한 브라우저 모니터링
브라우저 프로파일링을 통해 최종 사용자 환경에 대한 추가 정보를 얻을 수 있습니다.
느린 요청이 있는 페이지를 표시할 수 있으므로 서버 측 모니터링과 연관시켜 추가 분석을 할 수 있습니다.
Google 애널리틱스는 페이지 타이밍 보고서에서 페이지 로드 시간을 기본적으로 모니터링합니다. 이를 통해 사이트의 사용자 환경을 이해하는 데 유용한 여러 뷰를 확인할 수 있습니다. 특히 다음 뷰를 확인할 수 있습니다.
Python 클라이언트 라이브러리의 맞춤 인터셉터에서 Google Cloud Logging에 로깅하는 예는 로깅 가이드를 참고하세요.
Google Cloud에서 이 데이터를 사용할 수 있으므로 로깅된 데이터를 기반으로 측정항목을 빌드하여 Google Cloud Monitoring을 통해 애플리케이션을 파악할 수 있습니다. 사용자 정의 로그 기반 측정항목에 관한 가이드에 따라 Google Cloud Logging에 전송된 로그를 사용하여 측정항목을 빌드합니다.
또는 Monitoring 클라이언트 라이브러리를 사용하여 코드에서 측정항목을 정의하고 로그와 별도로 Monitoring으로 직접 보낼 수 있습니다.
로그 기반 측정항목 예
애플리케이션의 오류율을 더 잘 이해하기 위해 is_fault 값을 모니터링한다고 가정해 보겠습니다. 로그에서 is_fault 값을 새 카운터 측정항목ErrorCount으로 추출할 수 있습니다.
Cloud Logging에서 라벨을 사용하면 로그의 다른 데이터를 기반으로 측정항목을 카테고리로 그룹화할 수 있습니다. Google Ads API 메서드별로 오류 수가 어떻게 분류되는지 확인하기 위해 Cloud Logging에 전송되는 method 필드의 라벨을 구성할 수 있습니다.
ErrorCount 측정항목과 Method 라벨이 구성되면 Monitoring 대시보드에서 새 차트를 만들어Method별로 그룹화된 ErrorCount를 모니터링할 수 있습니다.
알림
Cloud Monitoring 및 기타 도구에서 측정항목에 의해 알림이 트리거되는 시점과 방법을 지정하는 알림 정책을 구성할 수 있습니다. Cloud Monitoring 알림 설정에 관한 안내는 알림 가이드를 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[[["\u003cp\u003ePerformance optimization involves identifying key metrics like latency and throughput to pinpoint areas for improvement.\u003c/p\u003e\n"],["\u003cp\u003eMonitoring tools enable tracking of these metrics, setting up alerts for thresholds, and visualizing performance trends.\u003c/p\u003e\n"],["\u003cp\u003eOptimizing for latency percentiles, such as the 90th and 99th, offers a comprehensive approach to performance enhancement.\u003c/p\u003e\n"],["\u003cp\u003eServer-side and browser monitoring provide different perspectives, with server-side offering granular data and browser monitoring reflecting user experience.\u003c/p\u003e\n"],["\u003cp\u003eLeverage tools like Google Cloud Logging and Monitoring to capture, track, and analyze performance metrics, facilitating efficient optimization strategies.\u003c/p\u003e\n"]]],[],null,["# Monitoring\n\nPerformance optimization starts with identifying key metrics, usually related to\nlatency and throughput. The addition of monitoring to capture and track these\nmetrics exposes weak points in the application. With metrics, optimization can\nbe undertaken to improve performance metrics.\n\nAdditionally, many monitoring tools let you set up alerts for your metrics, so\nthat you are notified when a certain threshold is met. For example, you might\nset up an alert to notify you when the percentage of failed requests increases\nby more than *x*% of the normal levels. Monitoring tools can help you identify\nwhat normal performance looks like and identify unusual spikes in latency, error\nquantities, and other key metrics. The ability to monitor these metrics is\nespecially important during business critical timeframes, or after new code has\nbeen pushed to production.\n\nIdentify latency metrics\n------------------------\n\nEnsure that you keep your UI as responsive as you can, noting that users expect\neven higher standards from [mobile apps](/web/fundamentals/performance/why-performance-matters). Latency should also be measured\nand tracked for backend services, particularly since it can lead to throughput\nissues if left unchecked.\n\nSuggested metrics to track include the following:\n\n- Request duration\n- Request duration at subsystem granularity (such as API calls)\n- Job duration\n\nIdentify throughput metrics\n---------------------------\n\nThroughput is a measure of the total number of requests served over a given\nperiod of time. Throughput can be affected by latency of subsystems, so you\nmight need to optimize for latency to improve throughput.\n\nHere are some suggested metrics to track:\n\n- Queries per second\n- Size of data transferred per second\n- Number of I/O operations per second\n- Resource utilization, such as CPU or memory usage\n- Size of processing backlog, such as pub/sub or number of threads\n\nNot just the mean\n-----------------\n\nA common mistake in measuring performance is only looking at the mean (average)\ncase. While this is useful, it doesn't provide insight into the distribution of\nlatency. A better metric to track is the performance percentiles, for example\nthe 50th/75th/90th/99th percentile for a metric.\n\nGenerally, optimizing can be done in two steps. First, optimize for 90th\npercentile latency. Then, consider the 99th percentile---also known as tail\nlatency: the small portion of requests which take much longer to complete.\n\nServer-side monitoring for detailed results\n-------------------------------------------\n\nServer-side profiling is generally preferred for tracking metrics. The server\nside is usually much easier to instrument, allows access to more granular data,\nand is less subject to perturbation from connectivity issues.\n\nBrowser monitoring for end-to-end visibility\n--------------------------------------------\n\nBrowser profiling can provide additional insights into the end user experience.\nIt can show which pages have slow requests, which you can then correlate to\nserver-side monitoring for further analysis.\n\n[Google Analytics](/analytics) provides out-of-the-box monitoring for page load\ntimes in the [page timings report](//support.google.com/analytics/answer/1205784#PageTimings). This provides several useful views\nfor understanding the user experience on your site, in particular:\n\n- Page load times\n- Redirect load times\n- Server response times\n\nMonitoring in the cloud\n-----------------------\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nThere are many tools you can use to capture and monitor performance metrics for\nyour application. For example, you can use [Google Cloud Logging](//cloud.google.com/logging) to log\nperformance metrics to your [Google Cloud Project](/google-ads/api/docs/oauth/cloud-project), then set up\ndashboards in [Google Cloud Monitoring](//cloud.google.com/monitoring) to monitor and segment the logged\nmetrics.\n\nCheck out the [Logging guide](/google-ads/api/docs/productionize/logging) for an [example](/google-ads/api/docs/productionize/logging#option_4_implement_a_custom_grpc_logging_interceptor) of logging to\nGoogle Cloud Logging from a custom interceptor in the Python client library.\nWith that data available in Google Cloud, you can build metrics on top of the\nlogged data to gain visibility into your application through Google Cloud\nMonitoring. Follow the [guide](//cloud.google.com/logging/docs/logs-based-metrics#user-defined_metrics) for user-defined log-based metrics to\nbuild metrics using the logs sent to Google Cloud Logging.\n\nAlternatively, you could use the Monitoring client [libraries](//cloud.google.com/monitoring/docs/reference/libraries) to define\nmetrics in your code and send them directly to Monitoring, separate from the\nlogs.\n\n### Log-based metrics example\n\nSuppose you want to monitor the `is_fault` value to better understand error\nrates in your application. You can extract the `is_fault` value from the logs\ninto a new [counter metric](//cloud.google.com/logging/docs/logs-based-metrics/counter-metrics), `ErrorCount`.\n\nIn Cloud Logging, [labels](//cloud.google.com/logging/docs/logs-based-metrics/labels) let you group your metrics into categories\nbased on other data in the logs. You can configure a label for the [`method`\nfield sent to Cloud Logging](/google-ads/api/docs/productionize/logging#option_4_implement_a_custom_grpc_logging_interceptor) in order to look at how the error count is\nbroken down by the Google Ads API method.\n\nWith the `ErrorCount` metric and the `Method` label configured, you can [create\na new\nchart](//cloud.google.com/logging/docs/logs-based-metrics/charts-and-alerts) in\na Monitoring dashboard to monitor `ErrorCount`, grouped by `Method`.\n\n### Alerts\n\nIt's possible in Cloud Monitoring and in other tools to configure alert policies\nthat specify when and how alerts should be triggered by your metrics. For\ninstructions on setting up Cloud Monitoring alerts, follow the\n[alerts guide](//cloud.google.com/logging/docs/logs-based-metrics/charts-and-alerts#alert-on-lbm)."]]
