성능 최적화는 일반적으로 지연 시간 및 처리량과 관련된 주요 측정항목을 식별하는 것으로 시작됩니다. 이러한 측정항목을 캡처하고 추적하기 위해 모니터링을 추가하면 애플리케이션의 약점이 드러납니다. 측정항목을 사용하면 실적 측정항목을 개선하기 위해 최적화를 수행할 수 있습니다.
또한 많은 모니터링 도구를 사용하면 측정항목에 대한 알림을 설정하여 특정 기준점이 충족되면 알림을 받을 수 있습니다. 예를 들어 실패한 요청의 비율이 정상 수준의 X% 이상 증가하면 알림을 받도록 알림을 설정할 수 있습니다. 모니터링 도구를 사용하면 정상적인 성능을 파악하고 지연 시간, 오류 수량, 기타 주요 측정항목의 비정상적인 급증을 식별할 수 있습니다. 이러한 측정항목을 모니터링하는 기능은 비즈니스에 중요한 기간 동안 또는 새 코드가 프로덕션에 푸시된 후에 특히 중요합니다.
지연 시간 측정항목 식별
사용자는 모바일 앱에 더 높은 기준을 기대하므로 UI를 최대한 반응성이 높게 유지해야 합니다. 백엔드 서비스의 지연 시간도 측정하고 추적해야 합니다. 특히 지연 시간을 확인하지 않으면 처리량 문제가 발생할 수 있습니다.
추적할 추천 측정항목은 다음과 같습니다.
- 요청 기간
- 하위 시스템 세분화 수준의 요청 기간 (예: API 호출)
- 작업 기간
처리량 측정항목 식별
처리량은 일정 기간 동안 처리된 총 요청 수를 측정한 값입니다. 처리량은 하위 시스템의 지연 시간에 영향을 받을 수 있으므로 처리량을 개선하려면 지연 시간을 최적화해야 할 수 있습니다.
다음은 추적할 수 있는 몇 가지 측정항목입니다.
- 초당 쿼리 수
- 초당 데이터 전송 크기
- 초당 I/O 작업 수
- 리소스 사용률(예: CPU 또는 메모리 사용량)
- 처리 백로그 크기(예: Pub/Sub 또는 스레드 수)
평균만으로는 부족합니다
성능 측정에서 흔히 저지르는 실수는 평균 사례만 살펴보는 것입니다. 이 방법은 유용하지만 지연 시간 분포에 대한 유용한 정보를 제공하지는 않습니다. 추적하기에 더 나은 측정항목은 성능 백분위수입니다. 예를 들어 측정항목의 50번째, 75번째, 90번째, 99번째 백분위수입니다.
일반적으로 최적화는 두 단계로 진행됩니다. 먼저 90번째 백분위수 지연 시간에 맞게 최적화합니다. 그런 다음 99번째 백분위수(꼬리 지연 시간이라고도 함)를 고려합니다. 이는 완료하는 데 훨씬 더 오래 걸리는 소수의 요청입니다.
자세한 결과를 위한 서버 측 모니터링
측정항목을 추적할 때는 일반적으로 서버 측 프로파일링이 선호됩니다. 서버 측은 일반적으로 계측하기가 훨씬 쉽고, 더 세분화된 데이터에 액세스할 수 있으며, 연결 문제로 인한 교란의 영향을 덜 받습니다.
엔드 투 엔드 가시성을 위한 브라우저 모니터링
Google Ads API 통합이 최종 사용자에게 웹 프런트엔드를 제공하는 경우 브라우저 프로파일링을 통해 사용자 환경에 대한 추가 정보를 얻을 수 있습니다. 요청이 느린 페이지를 표시할 수 있으며, 이를 서버 측 모니터링과 연결하여 추가 분석을 수행할 수 있습니다.
Google 애널리틱스는 애널리틱스 페이지 시간 보고서에서 페이지 로드 시간에 대한 즉시 사용 가능한 모니터링도 제공합니다. 이렇게 하면 사이트의 사용자 환경을 이해하는 데 유용한 여러 보기가 제공됩니다. 특히 다음을 확인할 수 있습니다.
- 페이지 로드 시간
- 리디렉션 로드 시간
- 서버 응답 시간
클라우드에서의 모니터링
애플리케이션의 성능 측정항목을 캡처하고 모니터링하는 데 사용할 수 있는 도구는 다양합니다. 예를 들어 Google Cloud Logging을 사용하여 성능 측정항목을 Google Cloud 프로젝트에 로깅한 다음 Google Cloud Monitoring에서 대시보드를 설정하여 로깅된 측정항목을 모니터링하고 세분화할 수 있습니다.
Python 클라이언트 라이브러리용으로 작성된 커스텀 gRPC 로깅 인터셉터 예시는 로깅 가이드를 참고하세요. 이 예시에서 인터셉터는 logger.log_struct()를 호출하여 구조화된 로그 데이터의 Python 사전을 Cloud Logging으로 전송하고, Cloud Logging은 이를 로그 항목의 jsonPayload 필드에 저장합니다.
logger.log_struct({
"method": method_name,
"elapsed_ms": elapsed_milliseconds,
"is_fault": is_fault,
})
Google Cloud에서 해당 데이터를 사용할 수 있으면 로깅된 데이터를 기반으로 측정항목을 빌드하여 Google Cloud Monitoring을 통해 애플리케이션을 파악할 수 있습니다. 사용자 정의 로그 기반 측정항목 가이드에 따라 Google Cloud Logging으로 전송된 로그를 사용하여 측정항목을 빌드합니다.
또는 Cloud Monitoring 클라이언트 라이브러리를 사용하여 코드에서 측정항목을 정의하고 로그와 별개로 Monitoring에 직접 전송할 수 있습니다.
로그 기반 측정항목 예시
애플리케이션의 오류율을 더 잘 이해하기 위해 is_fault 값을 모니터링한다고 가정해 보겠습니다. logger.log_struct()는 각 Cloud Logging 항목의 jsonPayload 아래에 구조화된 사전 필드를 작성하므로 실패한 요청과 일치하는 필터(예: jsonPayload.is_fault = true)를 사용하여 ErrorCount라는 카운터 측정항목을 만들 수 있습니다.
Cloud Logging에서 라벨을 사용하면 로그의 다른 데이터를 기반으로 측정항목을 카테고리로 그룹화할 수 있습니다. Cloud Logging으로 전송된 jsonPayload.method 필드에 Method라는 STRING 라벨을 구성하여 Google Ads API 메서드별로 오류 수를 분류할 수 있습니다.
ErrorCount 측정항목과 Method 라벨을 구성하면 Cloud Monitoring에서 새 차트를 만들어 Method로 그룹화된 ErrorCount를 모니터링할 수 있습니다.
알림
Cloud Monitoring 및 기타 도구에서 측정항목으로 알림을 트리거해야 하는 시점과 방법을 지정하는 알림 정책을 구성할 수 있습니다. Cloud Monitoring 알림 설정에 대한 안내는 로그 기반 측정항목에 대한 알림 가이드를 참조하세요.