NGINX의 성능을 이해하는 것은 매우 어려울 수 있습니다. 따라야 할 데이터 포인트가 많으며 어떤 것이 귀하와 관련이 있고 어떤 것을 무시할 수 있는지 아는 것이 까다로울 수 있습니다.
이 기사에서는 AppSignal을 사용하여 NGINX를 모니터링하고 애플리케이션 성능에 대한 가시성을 확대하는 방법을 설명합니다.
모든 측정항목을 마법처럼 만들기
AppSignal을 사용하면 처리량부터 응답 시간까지 성능 지표를 갖춘 맞춤형 대시보드를 생성할 수 있습니다. 대시보드를 수동으로 생성하는 데는 시간이 걸리며 어떤 측정항목이 실제로 중요한지 파악하기 어려울 수 있습니다. 이러한 이유로 AppSignal은 Magic Dashboard를 통해 프로세스를 자동화했습니다. AppSignal을 설치하면 당사 에이전트가 귀하의 인프라를 스캔하고 NGINX 대시보드를 포함하여 가장 중요한 대시보드를 자동으로 생성합니다.
매직 대시보드는 애플리케이션의 대시보드 목록 아래에 자동으로 나타납니다. 대시보드가 설정되면 이를 선별하여 애플리케이션의 고유한 상황에 맞는 측정항목을 표시할 수 있습니다.
Magic 대시보드로 NGINX 측정항목 시각화
트래픽이 많아 중단이 발생하여 애플리케이션의 가용성이 위협받을 때 매직 대시보드가 NGINX 작업을 활용하는 데 어떻게 도움이 되는지 살펴보겠습니다.
사용자가 사진을 업로드하고 동료 사용자의 사진을 보고 좋아요를 표시할 수 있는 SnapGram이라는 애플리케이션이 있다고 가정해 보세요. 귀하의 애플리케이션에는 전용 사용자 수가 적고 가용성 문제 없이 비교적 안정적입니다.
주요 경쟁업체가 예기치 않게 고양이와 카푸치노 사진 공유를 금지하여 사용자가 SnapGram으로 마이그레이션하게 되면서 이 모든 것이 바뀌었습니다. 몇 시간 내에 활성 사용자 수가 수백 명에서 수천 명으로 급증합니다. 갑자기 수천 명의 사람들이 SnapGram을 사용할 수 없다고 불평하고 있습니다. 그러나 애플리케이션의 로그를 확인하면 모든 것이 잘 실행되고 있는 것으로 보이며 오류 사건이 급증하지도 않습니다.
NGINX 매직 대시보드는 또 다른 이야기를 들려줍니다:
처리량 그래프를 통해 애플리케이션이 수신하는 요청 수에 대한 빠른 통찰력을 얻을 수 있습니다. 그래프를 보면 SnapGram이 "인터넷을 파괴"하고 있음을 알 수 있습니다. 즉, 많은 요청을 받고 있습니다. 요청 시간 그래프도 올라가기 때문에 SnapGram이 요청에 응답하는 데 시간이 더 오래 걸립니다. 연결 우리 애플리케이션에 대한 연결 상태를 나타내는 차트는 많은 사람들이 SnapGram의 응답을 기다리고 있음을 보여줍니다. 수요를 따라잡을 수 없습니다.
SnapGram이 수요를 따라잡을 수 없기 때문에 상태 코드 차트는 시간 초과가 급증했음을 보여줍니다. SnapGram과 상호작용을 시도하는 대부분의 사람들은 시간 초과 오류를 받습니다. 이는 SnapGram의 애플리케이션 프로세스가 요청을 받기 전에 발생하기 때문에 로그를 분석하는 것만으로는 당면한 문제를 알 수 없습니다(SnapGram이 성공적으로 처리할 수 있는 요청의 제한된 비율만 볼 수 있습니다).
이제 문제가 코드에 있지 않다는 것을 알았으므로 추가 서버를 실행하여 SnapGram의 가용성을 향상시켜 애플리케이션이 트래픽을 더 잘 처리할 수 있습니다. 각각의 새 서버는 Magic Dashboard의 업스트림 응답 시간에 서로 다른 표시로 나타납니다. 및 업스트림 상태 코드 그래프를 통해 프로세스별 통찰력을 얻을 수 있습니다.
SnapGram의 로드를 더욱 줄이려면 업스트림 캐싱도 활성화하세요. 점점 더 많은 요청이 캐시됨에 따라 애플리케이션에 대한 스트레스가 줄어들면서 요청 시간(및 업스트림 요청 시간)도 줄어듭니다. SnapGram이 안정화되고 사용자 요청이 처리되면 사용자가 불평을 멈추고 고양이와 카푸치노 사진 공유로 돌아가는 것을 볼 수 있습니다.
더 많은 측정항목 =더 많은 마법
SnapGram은 읽기 쉬운 측정항목에 액세스하면 애플리케이션을 안정적으로 유지하고 NGINX 통합을 최대한 활용하는 데 어떻게 도움이 되는지 보여주는 간단한 예일 뿐입니다.
NGINX 매직 대시보드는 다음 측정항목을 추적할 수 있습니다:
- 요청 시간: NGINX 서버가 요청에 응답하는 데 걸리는 시간(분당 평균 및 95번째 백분위수).
- 처리량: NGINX 서버가 처리하는 요청 수.
- 요청 길이: NGINX 서버가 클라이언트로부터 받은 요청의 바이트 길이(분당 평균 및 95번째 백분위수)
- 응답 길이: NGINX 서버가 클라이언트에 전송한 응답의 바이트 단위 길이(분당 평균 및 95번째 백분위수)
- 상태 코드: NGINX 서버에서 보낸 응답의 상태 코드 수.
- 연결: 현재 NGINX 서버에서 처리 중인 연결의 게이지로, 분당 한 번씩 측정되고 연결 상태별로 분류됩니다.
- 업스트림 상태 코드: NGINX 서버가 프록시하는 업스트림 서버에서 보낸 응답의 상태 코드 수입니다.
- 업스트림 응답 시간: NGINX 서버가 프록시하는 업스트림 서버의 요청에 응답하는 데 걸린 시간(분당 평균 및 95번째 백분위수).
- 업스트림 캐시 상태: 업스트림 서버에서 프록시된 캐시된 요청을 처리할 때 캐시 상태(예:HIT 또는 MISS)
NGINX 및 AppSignal을 시작할 준비가 되었다면 NGINX 측정항목 문서에서 AppSignal 통합 구성에 대해 자세히 알아보세요.
AppSignal의 매직 대시보드는 애플리케이션 모니터링을 최대한 활용하는 데 도움이 되는 수많은 개발자 중심 기능 중 하나일 뿐입니다. 개발자들은 다음과 같은 이유로 모니터링을 즐겨 사용합니다.
- 탐색하기 쉬운 직관적인 인터페이스
- 간단하고 예측 가능한 가격 책정
- 개발자 간 지원.
신규 체험판 사용자라면 스트룹와플 한 상자도 무료로 받으실 수 있습니다. 데이터 푸시를 시작한 후 저희에게 연락하시면 패키지를 보내드리겠습니다 🍪!
코너 제임스
AppSignal의 개발자 마케팅 관리자. 카놀리를 너무 좋아해서 이름을 코놀리로 바꾸는 것을 고려 중인 팟캐스트 중독자. 그는 색깔에 'u'가 있다고 생각합니다. 마이크 위에 있거나, 무대 위에 있거나, 근무 외 시간에 소파에 누워 있는 그를 볼 수 있습니다.
Connor James의 모든 기사