이 페이지에서는 Cloud Run 서비스의 부하 테스트를 통해 프로덕션 사용 중에 성공적으로 확장되는지 확인하고 확장을 방해하는 병목 현상을 찾기 위한 권장사항을 제공합니다.
부하 테스트 전에 실행하는 테스트
부하 테스트를 진행하기 전에 개발 또는 소규모 테스트 환경에서 동시 실행 문제를 식별하고 해결합니다. 부하 테스트를 실행하기 전에 컨테이너 동시 실행을 측정하고 Cloud Run 서비스가 안정적으로 시작되는지 확인합니다.
수동 확장 실행의 소규모 증분 개수에 컨테이너 테스트의 초점을 맞춥니다. 최대 인스턴스를 확장하려는 값으로 설정하면 Cloud Run에서 수동 확장을 추정할 수 있습니다.
최근에 컨테이너 이미지를 빌드했거나 최근에 컨테이너 이미지를 변경한 경우 부하 테스트를 수행하기 전에 이를 독립적으로 테스트합니다.
또한 대규모 부하 테스트를 실행하기 전에 과도한 지연 시간 및 CPU 사용률과 같은 다른 종류의 성능 문제를 확인해야 합니다.
max instances의 적절한 사용
Cloud Run은 최대 인스턴스를 적용하여 서비스의 확장을 제한합니다. 기본 최대 인스턴스 수는 100개입니다. 부하 테스트가 이 기본값을 초과할 것으로 예상되면 Google 계정팀과 협력하여 새로운 최댓값을 설정하세요. 아직 계정팀이 없다면 Google Cloud 영업팀에 문의하세요.
선택 가능한 최대 인스턴스 수는 CPU 한도와 메모리 한도와 배포 리전에 따라 달라집니다.
이러한 한도는 할당량 한도로 관리되며 할당량 한도 상향 요청을 통해 늘릴 수 있습니다.
us-central1 리전의 부하 테스트
Google Cloud 리전 us-central1에서는 높은 할당량 한도를 제공하므로 us-central1에서 부하 테스트를 수행하는 것이 좋습니다. 할당량 한도에 도달할 것으로 예상되면 계정팀과 협력하여 테스트 시간 및 규모에 대한 세부정보를 포함한 지원 케이스를 제출하세요.
적절한 CPU 사용률 및 서비스 초기화 프로필 테스트
이상적인 시나리오에서 서비스의 테스트 버전을 Cloud Run에 배포하고 직접 부하 테스트를 수행합니다. 그러나 서비스의 테스트 버전을 배포할 수 없는 경우도 있습니다. 예를 들어 Cloud Run 서비스가 테스트 환경에서 복제하기 어려운 복잡한 생태계에 포함되어 있을 수 있습니다.
이러한 경우에는 CPU 사용량과 초기화 시간이 비슷한 보다 간단한 서비스로 시뮬레이션하여 서비스 성능을 추정하면 됩니다.
초기화 시간은 특히 빠른 확장 시에 중요합니다. 너무 단순한 서비스를 테스트해도 문제가 될 수 있습니다. 예를 들어 처리 없이 수신된 요청을 반환하는 간단한 hello world 서비스로는 테스트하지 마세요.
테스트 하네스를 사용한 부하 생성
JMeter와 같은 테스트 하네스를 사용하여 통제된 트래픽 급증을 유발하는 테스트 부하를 생성할 수 있습니다. JMeter 스레드 그룹 수와 JMeter 테스트의 요청 간 지연을 사용해 부하를 늘릴 수 있습니다.
JMeter를 사용하여 간단한 HTTP 요청을 보내거나 브라우저 세션을 기록할 수도 있습니다. Cloud Run을 사용하면 개발자 인증을 사용하여 인터넷 액세스 없이 서비스를 테스트할 수 있습니다. 프로젝트와 관련된 Virtual Private Cloud에 연결된 Compute Engine 가상 머신에서 실행되는 JMeter 등의 테스트 하네스에서 액세스할 수 있습니다.
속도 및 동시 실행을 제어할 수 없는 도구로는 부하를 생성하지 마세요. Pub/Sub는 트래픽 속도 및 클라이언트 수를 제어할 수 없으므로 부하 생성에 적합하지 않은 도구입니다. 속도와 동시 실행을 모르는 경우 무엇을 테스트 중인지 알 수 없습니다.
내보낸 로그를 사용하여 자세한 로그 분석 사용
트래픽 급증에 대한 Cloud Run 서비스의 대응을 이해하려면 초당 이벤트 분석을 수행해야 합니다. 데이터 모니터링의 세분화가 충분히 세밀하게 조정되지 않으므로 이를 위해서는 로그 분석이 필요합니다. 또한 로그 분석을 사용하면 요청의 지연 시간이 긴 이유를 조사할 수 있습니다.
로그를 쓸 때 Cloud Logging 클라이언트 라이브러리를 사용하는 대신 stdout에 직접 작성하면 로깅 성능을 높일 수 있습니다.
테스트를 시작하기 전에 로그 내보내기를 설정하려면 다음과 같이 대상 BigQuery 및 포함 필터를 사용해 로그 싱크를 만듭니다.
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
허위 콜드 스타트 방지
사용자가 경험하는 콜드 스타트를 최소화하려면 최소 인스턴스 수를 1 이상으로 설정하세요.
서비스가 선형적으로 수평 확장되는지 확인
다양한 부하에서 테스트를 반복하여 Cloud Run 서비스가 부하에 따라 선형적으로 수평 확장되고 프로덕션에서 예상되는 것보다 낮은 부하에서 이를 제한하는 병목 현상에 도달하지 않는지 확인합니다.
Colab에서 결과 분석 및 시각화
요약 모니터링 차트를 사용해 결과를 대략적으로 파악하면 내보낸 로그를 사용하는 자세한 로그 분석을 보완할 수 있습니다.
모니터링 차트는 다음 질문의 답을 찾는 데 도움이 될 수 있습니다.
- 새 인스턴스가 얼마나 빨리(초 단위) 생성되고 초기화되나요?
- 요청이 여러 인스턴스에 얼마나 균등하게 분산되나요?
- 서로 다른 백분위수의 지연 시간을 안정적인 상태의 값으로 얼마나 빨리 줄일 수 있나요?
BigQuery용 Google Cloud 콘솔 사용자 인터페이스를 사용하여 내보낸 로그 스키마와 미리보기 결과를 검사할 수 있습니다. BigQuery, Pandas, Matplotlab과 즉시 통합할 수 있는 Colab을 사용하여 쿼리를 실행하고 결과를 표시하세요. 또한 Colab은 Seaborn과 같은 풍부한 데이터 시각화 도구와도 쉽게 통합됩니다.
병목 현상 찾기
부하 테스트를 사용하면 비효율적인 코드와 확장 병목 현상이 모두 존재하는지 확인할 수 있습니다. 비효율적인 코드는 더 많은 트래픽을 처리해야 하기 때문에 비용이 증가하지만 반드시 확장을 방해하는 것은 아닙니다. 예를 들어 테이블 수준 잠금을 사용하는 데이터베이스 변환의 종속 항목은 한 번에 하나의 트랜잭션만 실행될 수 있으므로 Cloud Run 서비스의 확장을 방해하는 병목 현상을 초래할 수 있습니다.
클라이언트에서 경험한 성능 확인
JMeter에서 캡처한 로그를 쿼리할 수 있습니다. 로그에는 클라이언트에서 측정된 지연 시간이 포함됩니다. 그러나 JMeter와 같은 서버 테스트 도구는 브라우저 또는 모바일 클라이언트와 동일하지 않으므로 Selenium Webdriver , 모바일 클라이언트 테스트 프레임워크 등의 브라우저 기반 프레임워크로 테스트를 실행할 수도 있습니다. 이상점으로 결과를 왜곡할 수 있는 TLS 연결 초기화로 인해 최대 지연 시간이 과도하게 발생할 수 있으니 주의해야 합니다.
권장사항 요약
부하 테스트를 수행하여 Cloud Run으로 마이그레이션하는 것이 올바른 선택인지, 서비스가 최대 예상 트래픽으로 확장될 수 있는지 확인합니다. JMeter와 같은 하네스를 사용하여 테스트를 실행합니다. 세부 분석을 위해 로그를 BigQuery로 내보냅니다.