애플리케이션 아키텍처의 특정 측면뿐만 아니라 전체 애플리케이션 아키텍처를 살펴보고 서로 다른 부분이 연결되는 방식을 이해하는 것이 중요합니다. 관찰 가능성이 먼저이고 모니터링이 뒤따릅니다.
이 게시물에서는 아키텍처의 데이터베이스 부분을 자세히 살펴보고 데이터베이스 성능을 모니터링하고 최적화하는 방법을 보여줍니다. 다음 원칙의 대부분은 스택에 관계없이 또는 PostgreSQL, MongoDB 또는 기타 데이터베이스의 성능을 모니터링하고 최적화할지 여부에 관계없이 적용됩니다.
데이터베이스 성능을 모니터링하는 이유
쿼리가 매우 느리고 앱이 결과를 기다려야 한다고 가정해 보겠습니다. 이로 인해 최종 사용자 및/또는 앱의 일부에서 작업이 중단됩니다.
교통 체증과 같이 다른 곳에서 일어나는 일의 영향으로 부품이 정지할 수 있습니다. 많은 쿼리를 해결하는 데 너무 오래 걸리는 경우 다른 쿼리가 방해가 되기 때문일 수 있습니다.
목표는 앱의 다른 부분에서 문제가 발생하기 전에 문제의 원인을 찾는 것입니다.
다음 단계는 모니터링을 사전에 사용하여 아키텍처를 최적화하고 작업을 더 빠르게 만드는 방법을 확인하는 것입니다. 하지만 우리는 앞서가고 있습니다. 1단계부터 시작하겠습니다.
1단계:AKA Instrumenting 데이터베이스 성능 측정
데이터베이스 모니터링은 올바른 항목을 측정하는 것으로 시작됩니다.
-
오류
-
성능
-
검색어 기간의 평균 및 90번째 백분위수
-
총 처리량 - 처리량이 문제일 때 트리거/플래그를 설정하는 또 다른 방법을 제공합니다.
다행히도 해당 데이터를 가져오는 작업은 이미 완료되었습니다. APM 소프트웨어를 사용하면 계측 및 측정하려는 항목을 구성할 수 있습니다. AppSignal을 사용하면 별도의 설정 없이 자동으로 데이터 수집 및 집계가 이루어집니다. 우리가 당신을 위해 무거운 일을 해냈습니다!
2단계:시작점 - 영향력이 큰 쿼리 찾기
앱이 계측되고 실제 데이터가 들어오기 시작하면 패턴이 나타나는 것을 볼 수 있습니다. AppSignal에서 탐색의 '개선' 아래에 가장 느린 API 요청과 가장 느린 쿼리에 대한 화면을 구축했습니다.
이 화면은 최적화를 위한 훌륭한 출발점이 될 것입니다. 기본적으로 느린 쿼리는 영향을 기준으로 정렬됩니다. 자주 하는 쿼리입니다. 영향은 처리량 x 평균 쿼리 시간입니다.
이러한 정렬 사이를 전환하면 가장 볼륨이 큰 쿼리, 가장 느린 쿼리(그러나 쉽게 무시할 수 있는 야간 작업일 수 있음) 및 가장 영향력 있는 쿼리에 대한 아이디어를 얻을 수 있습니다.
빠른 단계:일부 개별 쿼리 수정
이제 수정에 대한 몇 가지 쿼리를 찾을 수 있습니다.
느린 쿼리를 클릭하면 쿼리의 처리량과 응답 시간부터 쿼리 이름 자체에 이르기까지 오른쪽에 모든 세부 정보가 표시됩니다.
피크의 응답 시간 위로 마우스를 가져간 다음 '여기에서 발생한 일' 옵션을 클릭하여 확대할 수 있습니다. 해당 샘플에서 해당 시점에 어떤 오류가 발생했는지, 호스트에서 어떤 일이 발생했는지 확인할 수 있습니다.
우리는 하나의 특정 안티 패턴인 N+1에 대해 매우 잘 보이도록 만들었습니다. N+1안티 패턴은 이전 쿼리의 모든 결과에 대해 쿼리가 실행될 때 발생합니다.
쿼리 수는 N + 1이며 N은 초기 쿼리 결과에 대한 쿼리 수입니다. 해당 초기 쿼리에 하나의 결과가 있으면 N+1 =2입니다. 결과가 1,000개이면 N+1 =1,001개 쿼리입니다. 붐.
쿼리가 N+1 안티 패턴을 따르는 경우 이는 다행스러운 일입니다. 여기에 레이블이 지정되어 있어 빠르게 찾을 수 있습니다.
여기에서 문제를 해결하는 방법에 대해서는 다루지 않겠습니다. N+1 쿼리에 대한 별도의 블로그 게시물을 작성했습니다.
자, 이제 우리가 몇 가지 이상한 것을 수정했다고 가정하고 수정하면서 문제가 발생한 시점과 최악의 응답 시간을 알아차렸습니다.
3단계:찾기 패턴 결정 - 무엇이 잘못되었나요?
모니터링은 종종 일이 잘못될 때를 살펴보는 것입니다. 그러나 모니터링과 관련된 복잡성 중 일부는 설정에 대해 '잘못된' 것으로 간주되어야 하는 항목을 정의하는 것입니다. 또한 자동으로 해결되는 문제에 대해 알림을 받거나 그렇지 않은 문제를 놓치겠습니까?
평균적으로 쿼리의 처리량과 지속 시간을 살펴보겠습니다. APM 소프트웨어에서 설정할 수 있습니다. AppSignal을 사용하여 Node.js를 모니터링하고 PostgreSQL을 데이터베이스로 사용하는 경우 가장 중요한 지표가 포함된 대시보드가 자동으로 생성됩니다.
node-postgres 대시보드에는 다음과 같은 데이터가 표시됩니다.
앱에 대해 이를 설정하려면 추가 정보를 참조하세요.
다른 시간 범위 사이를 전환하면 평균 1시간 내에 사라지는 짧은 피크와 더 확장된 시간 범위로 축소할 때 높은 상태를 유지하는 피크를 볼 수 있습니다.
가장 느린 쿼리 화면을 본 경험을 통해 이제 주요 원인과 정점에 도달한 시점에 대한 아이디어를 얻었습니다.
처리량의 특정 짧은 피크는 괜찮을 수 있습니다. 예를 들어 호스트가 쿼리를 느리게 만드는 다른 프로세스를 실행하고 있을 수 있습니다.
더 길어진 쿼리 시간이나 최대 처리량을 확대하고 싶을 것입니다. 평균과 95번째 백분위수를 비교하면 느린 쿼리가 모든 사람에게 발생하는지 아니면 작은 하위 집합에서만 발생하는지 알 수 있습니다. 이는 때때로 수정 사항을 안내하는 데 도움이 될 수 있습니다.
4단계:유지해야 하는 것 밤에 일어나세요?
일반적으로 스펙트럼의 시끄러운 부분에서 시작하는 것이 좋습니다. PagerDuty가 아니라 email 또는 Slack과 같이 사용자를 깨우지 않는 채널에서 사용자에게 경고하는 트리거를 설정합니다.
"event_duration" 측정항목에 대한 사용자 지정 측정항목 트리거를 만들고 평균 필드를 선택하여 앱의 평균 쿼리 시간에 대한 알림을 받습니다. 앱에서 발생하는 가장 느린 쿼리에 대한 알림을 받으려면 90번째 또는 95번째 백분위수를 선택하세요.
그런 다음 경고를 받고자 하는 이벤트 유형과 어떤 네임스페이스에 대해 "그룹" 및 "네임스페이스" 태그를 구성합니다. 예를 들어 그룹의 경우 "active_record"(Rails) 또는 "postgres"(Node.js) 또는 "ecto"(Elixir), 네임스페이스의 경우 "web" 또는 "background":
일주일이 지나면 몇 가지 패턴이 보이기 시작하고 어떤 경우에 주의가 필요한지, 어떤 경우가 일반적으로 저절로 해결되는지 알 수 있습니다.
그런 다음 소음이 덜하도록 트리거를 조정하고 특정 알림으로 깨우고 싶을 때 채널을 추가할 수 있습니다.
5단계:데이터베이스 모니터링 설정 완료
이제 이론상으로 좋은 모니터링 설정이 있어야 합니다. 올바른 데이터가 들어오고 비트가 팬에 도달하기 전에 경고하도록 트리거를 설정했으며 몇 가지 큰 범인을 찾았습니다. 끝내야겠죠?
실제로 앱 사용량이 증가하고 새로운 병목 현상이 발생할 수 있습니다. Orcode 변경 사항이 데이터베이스에 영향을 주어 기간이 길어질 수 있습니다. 또는 거대한 페이로드가 있는 특정 필드가 무언가를 트리거합니다. 그러나 경험이 있어도 새로운 문제와 병목 현상이 발생합니다.
그러나 적절한 설정을 사용하면 경고를 받고 이러한 문제를 해결하기 위해 아키텍처를 자세히 살펴보는 방법을 알게 된다는 사실에서 위안을 찾을 수 있습니다.
그리고 아마도 다른 나사가 풀리기 전에 큰 '영향력 있는' 쿼리를 개선하는 기쁨을 찾을 수 있을 것입니다. 그것은 우리가 가장 사랑하는 것입니다 - 그것은, 그리고 스트룹와플입니다.
AppSignal을 사용해 보고 Stroopwafels를 받으세요 🍪
스트룹 와플이라고 하면 전 세계로 보냅니다. Ruby, Elixir 및 Node.js용 AppSignal APM 소프트웨어를 사용해 보십시오. 무료 평가판을 설정하고 저희에게 연락하시면 집으로 스트룹 와플 한 상자를 보내드립니다.