목표
이 자습서를 마치면 다음을 수행하게 됩니다.
- 외부 서비스 UI 사용 방법 이해
- API 호출과 같은 느린 외부 서비스 식별
- 트랜잭션 수준 성능 검토
외부 서비스를 살펴보는 이유
외부 서비스 기능을 사용하면 서비스의 업스트림 및 다운스트림 활동을 관찰할 수 있습니다. 이러한 업스트림 또는 다운스트림 외부 서비스는 계측한 자체 서비스이거나 타사 서비스 및 API 호출일 수 있습니다. 이러한 외부 서비스의 응답 시간이 느리면 앱이 지연되어 속도가 느려집니다.
느린 외부 서비스 식별
느린 외부 서비스를 식별하는 방법을 살펴보겠습니다.
외부 서비스 UI로 이동합니다. one.newrelic.com > (select an app) > Monitor > External services 로 이동합니다. 아직 활성화되어 있지 않으면 왼쪽 상단의 Show new view 토글한 다음 오른쪽 상단의 Map 클릭합니다.
업스트림 종속성이라고도 하는 애플리케이션의 종속성은 왼쪽에 나열됩니다. 오른쪽에는 다운스트림 서비스라고 하는 애플리케이션에 의존하는 서비스가 있습니다. 어떤 서비스가 정상인지, 각 서비스에 대한 처리량과 시간 소모량을 확인할 수 있습니다. 서비스를 선택하면 해당 서비스에 대한 자세한 정보를 볼 수 있습니다.
모든 업스트림 의존성/종속성 위로 마우스를 이동하고 응답 시간 또는 트레이스 수가 높은 항목을 식별해 보세요. 최근 기록에서 상당한 급증이 있었던 항목에 특히 주의하세요. 의심스러운 서비스를 발견하면 해당 서비스 위에 마우스를 올려놓고 View traces 버튼을 선택하여 자세히 알아보세요. 이 새 창에는 해당 프로세서의 사용 가능한 함수 호출, 데이터베이스 호출 및 외부 호출을 기록하는 해당 프로세서 트레이스에 대한 정보가 표시됩니다.
이 페이지에서 제공하는 정보를 활용하는 방법은 다양하므로 자유롭게 탐색하십시오. 다음은 워크플로의 예입니다.
지도에서 가장 두껍고 어두운 선을 찾아 상류 또는 하류 서비스로 이동합니다.
업스트림 또는 다운스트림 정점을 클릭합니다.
두 서비스 간 거래 내역을 확인하세요.
이 예에서 더 두꺼운 모서리(선) 중 하나는 Order-Composer 서비스에서 Order Status 서비스의 창고 엔드포인트로 이동합니다.
특정 프로세서가 가장 많은 시간을 소비하고 있다고 판단되면 해당 프로세서를 클릭하여 해당 프로세서의 독립성/종속성에 집중하세요.
이 드릴다운 보기에서는 Order-Composer 서비스와 Order-Status 서비스의 창고 간의 관계를 볼 수 있습니다.
이 흐름의 어느 지점에서나 시간 경과에 따른 변화를 보여주는 지원 성능 차트를 참조하십시오.
드릴다운에서 분산 추적을 보고 싶은 지점에 도달하면 오른쪽 상단의 List 클릭한 다음 표에서 Traces 클릭합니다.
팁
위에서 사용된 것과 같은 서비스 맵은 시스템 내의 복잡한 관계를 이해하는 데 강력합니다. 계측한 서비스가 많을수록 시스템에 대한 관찰 가능성이 높아집니다. 서비스 맵에 대해 자세히 알아보세요.
이전 단계의 맵 보기는 시스템의 시각적 보기에 적합하지만 문제가 있는 외부 서비스를 식별하는 데 어려움을 겪고 있는 경우 목록 보기가 데이터를 그래프와 표로 제공하여 더 유용할 수 있습니다.
먼저 오른쪽 상단의 List 선택하여 목록 보기로 이동합니다. 이 페이지에서는 느린 외부 서비스를 식별하는 데 사용할 수 있는 다양한 표와 그래프를 보여줍니다. 이 페이지를 사용하여 서비스를 분류하세요.
Response time 그래프를 살펴보세요. 여기에는 가장 느린 외부 서비스 5개가 표시됩니다. 이것들이 가장 느리긴 하지만, 나머지 서비스와 비교하면 느린 수준이라는 점을 유의하세요. 앱에 중단을 일으킬 만큼 느리지 않을 수도 있습니다.
Traced error count 을 살펴보세요. 오류가 많이 발생합니까? 그렇다면 그들은 어떤 서비스에서 왔습니까?
아래 표에서 서비스를 % change 으로 정렬합니다. 이는 최근에 호출된 기간이나 트레이가 얼마나 바뀌었는지에 따라 서비스 순위를 보여줍니다. 최근에 급격히 상승한 서비스가 있나요?
아래 표에서 해당 서비스 이름 옆에 있는 View traces 선택하여 위에 식별된 서비스를 더 자세히 살펴보세요. 이 정보를 사용하여 해당 서비스를 교체하고 API 호출을 최적화하거나 서비스 전반에 걸쳐 부하를 분산합니다.
작업 확인
문제의 범위를 지정했으므로 이제 솔루션을 식별할 시간입니다. 수정 사항은 문제에 따라 다르지만 다음은 몇 가지 예입니다.
- 실수로 API를 두 번 호출하고 있다는 것을 깨달았습니다. 중복된 통화를 제거하면 전체 응답 시간이 절반으로 줄어듭니다.
- 특정 API 호출은 매일 정오 경에 스로틀링을 시작하고 매일 해당 시간에 API의 무료 한도에 도달한다는 것을 알게 됩니다. 대체 API를 찾거나 액세스 권한을 업그레이드하십시오.
- 로드가 많은 경우 한도를 초과하는 다른 내부 서비스에 도달하여 응답 시간이 느려집니다. 이 로드를 더 많은 서비스에 분산시키거나 로드를 줄이거나 최적화하는 방법을 찾으십시오.
수정 사항을 개발 단계로 푸시한 다음 일반적인 로드 테스트를 실행하여 앱이 프로덕션 환경에서 어떻게 실행되는지 파악합니다.
외부 서비스를 모니터링할 때 차트를 주의 깊게 살펴보십시오.
- 외부 서비스가 허용 가능한 응답 시간에 도달하고 있습니까? 끝났어!
- 그들은 향상 되었습니까? 학습한 내용을 사용하여 그들이 정상 이상으로 개선된 이유를 파악하십시오.
- 여전히 응답 시간이 느린가요? 데이터베이스 문제가 있거나 트랜잭션이 느리게 실행 중일 수 있습니다.