애플리케이션 아키텍처 전체를 조망하고 각 구성 요소가 서로 어떻게 연결되는지 이해하는 것은 매우 중요합니다. 관찰 가능성(Observability)이 먼저이고, 그다음이 모니터링입니다.
이 글에서는 아키텍처 중 데이터베이스 부분에 초점을 맞춰 데이터베이스 성능을 모니터링하고 최적화하는 방법을 살펴봅니다. 다음에서 소개하는 원칙 대부분은 사용하는 스택이나 PostgreSQL, MongoDB 등 어떤 데이터베이스를 쓰는지와 무관하게 적용할 수 있습니다.
데이터베이스 성능을 모니터링해야 하는 이유
어떤 쿼리가 아주 느려서 애플리케이션이 결과를 계속 기다려야 한다면 어떻게 될까요? 최종 사용자에게는 서비스가 멈춘 것처럼 보이고, 애플리케이션의 일부 기능도 마비됩니다.
교통 체증과 마찬가지로, 한 곳에서 발생한 문제가 다른 곳의 정체로 이어질 수 있습니다. 많은 쿼리가 처리 시간을 초과한다면, 그 원인은 다른 쿼리들이 병목을 일으키고 있기 때문일 수 있습니다.
목표는 문제가 애플리케이션의 다른 부분으로 번지기 전에 발생 지점을 파악하는 것입니다.
그다음 단계는 모니터링을 능동적으로 활용해 아키텍처를 최적화하고 속도를 개선하는 방법을 찾는 것입니다. 하지만 순서대로 진행해 보겠습니다. 먼저 1단계부터 시작합니다.
1단계: 데이터베이스 성능 측정하기(인스트루먼테이션)
데이터베이스 모니터링은 올바른 지표를 측정하는 것에서 시작합니다:
오류(Errors)
성능(Performance)
쿼리 소요 시간(duration)의 평균값과 90퍼센타일
전체 처리량(throughput) — 처리량이 문제가 될 때 트리거나 플래그를 설정할 수 있는 또 하나의 기준점
다행히 이런 데이터를 수집하는 일은 이미 준비되어 있습니다. 대부분의 APM 소프트웨어는 계측(instrumentation) 항목을 자유롭게 설정할 수 있게 해줍니다. 예를 들어 AppSignal을 사용하면 복잡한 설정 없이도 데이터 수집과 집계가 자동으로 이루어집니다. 번거로운 작업은 도구가 대신 처리해 주는 셈입니다!
2단계: 출발점 — 영향력 큰 쿼리 찾기
애플리케이션에 계측을 적용하고 실제 데이터가 들어오기 시작하면 패턴이 보이기 시작합니다. AppSignal에서는 내비게이션의 'Improve' 메뉴에서 가장 느린 API 요청과 가장 느린 쿼리를 확인할 수 있는 화면을 제공합니다.
이 화면은 최적화 작업의 훌륭한 출발점이 됩니다. 기본적으로 느린 쿼리는 '영향력(impact)' 순으로 정렬됩니다. 여기서 영향력은 처리량 × 평균 쿼리 시간으로 계산되며, 자주 실행되는 쿼리를 의미합니다.
정렬 기준을 전환해 보면 처리량이 가장 많은 쿼리, 가장 느리지만 밤에 한 번 돌아가는 배치 작업 수준이라 무시해도 되는 쿼리, 그리고 영향력이 가장 큰 쿼리를 구분할 수 있습니다.
잠깐, 개별 쿼리 몇 개 고쳐 보기
이제 수정할 만한 쿼리를 골라 자세히 들여다볼 차례입니다.
느린 쿼리를 클릭하면 오른쪽에 해당 쿼리의 세부 정보가 표시됩니다. 처리량과 응답 시간부터 쿼리 이름까지 한눈에 확인할 수 있습니다.
응답 시간 그래프의 피크 지점에 마우스를 올리고 'what happened here' 옵션을 클릭하면 해당 구간을 확대해서 볼 수 있습니다. 그 시점, 그 샘플에서 어떤 오류가 발생했는지, 호스트에서는 무슨 일이 있었는지 확인할 수 있습니다.
특히 N+1이라는 안티패턴은 눈에 잘 띄도록 표시해 두었습니다. N+1 안티패턴은 이전 쿼리의 결과 하나하나마다 새로운 쿼리가 실행될 때 발생합니다.
쿼리 수는 N + 1이며, N은 초기 쿼리 결과에 대해 실행되는 쿼리 수입니다. 초기 쿼리의 결과가 1개면 N+1 = 2, 결과가 1,000개면 N+1 = 1,001개의 쿼리가 실행됩니다. 상상만 해도 아찔하죠.
N+1 안티패턴을 따르는 쿼리가 있다면 운이 좋은 겁니다. 라벨로 표시되어 있어 빠르게 찾아낼 수 있습니다.
해결 방법은 이 글에서 다루지 않습니다. N+1 쿼리에 대해서는 별도의 블로그 포스트를 참고하세요.
자, 이제 심각한 문제 몇 가지를 고쳤다고 가정해 봅시다. 수정 과정에서 문제가 언제 발생했는지, 최악의 응답 시간이 언제였는지도 함께 파악했습니다.
3단계: 패턴 판단하기 — 무엇이 문제인가?
모니터링은 흔히 '무언가 잘못됐을 때'를 포착하는 일로 여겨집니다. 하지만 모니터링의 어려움 중 하나는 내 환경에서 무엇을 '잘못된 것'으로 정의할지 결정하는 일입니다. 스스로 해결되는 문제로 알림을 받는 것과, 스스로 해결되지 않는 문제를 놓치는 것 중 어느 쪽이 나을까요?
쿼리의 평균 처리량과 소요 시간을 살펴보겠습니다. 이는 APM 소프트웨어에서 설정할 수 있습니다. Node.js 모니터링에 AppSignal을 사용하고 PostgreSQL을 데이터베이스로 쓴다면, 가장 중요한 지표로 구성된 대시보드가 자동으로 생성됩니다.
node-postgres 대시보드에는 다음과 같은 데이터가 표시됩니다:
내 애플리케이션에 이런 설정을 적용하고 싶다면 추가 자료를 참고하세요.
시간 범위를 바꿔가며 그래프를 보면, 한 시간 평균에는 사라져 버리는 짧은 피크와, 더 넓은 시간 범위로 축소해도 높은 수준을 유지하는 피크를 구분할 수 있습니다.
'가장 느린 쿼리' 화면을 살펴본 경험이 있다면 주요 원인이 무엇인지, 언제 피크가 발생했는지 어렵지 않게 감을 잡을 수 있습니다.
처리량의 짧은 피크 중 일부는 괜찮을 수 있습니다. 예컨대 호스트가 다른 프로세스를 실행 중이라 특정 쿼리가 일시적으로 느려졌을 수도 있습니다.
주목해야 할 것은 지속되는 긴 쿼리 시간이나 치솟는 처리량입니다. 95퍼센타일과 평균값을 비교하면 느린 쿼리를 모든 사용자가 겪고 있는지, 아니면 극소수만 겪고 있는지 알 수 있으며, 이는 무엇을 고쳐야 할지 방향을 잡는 데 큰 도움이 됩니다.
4단계: 무엇이 당신을 잠 못 들게 해야 할까?
알림 설정은 보통 '시끄러운' 쪽에서 시작할 것을 권장합니다. PagerDuty처럼 잠을 깨우는 채널이 아니라 이메일이나 Slack처럼 잠재우지 않는 채널로 알림을 받도록 트리거를 설정하세요.
"event_duration" 지표에 커스텀 메트릭 트리거를 만들고 mean 필드를 선택하면 앱의 평균 쿼리 시간에 대한 알림을 받을 수 있습니다. 90번째 또는 95번째 백분위수를 선택하면 앱에서 발생하는 가장 느린 쿼리에 대한 알림을 받습니다.
그다음 알림을 받고 싶은 이벤트 유형과 네임스페이스에 대해 "group"과 "namespace" 태그를 설정합니다. 예를 들어 group은 "active_record"(Rails), "postgres"(Node.js), "ecto"(Elixir)로, namespace는 "web" 또는 "background"로 지정할 수 있습니다:
일주일 정도 지나면 패턴이 보이기 시작하고, 어떤 사례에 주의를 기울여야 하는지, 어떤 사례는 보통 저절로 해결되는지 감을 잡게 됩니다.
이후 트리거를 조정해 알림을 덜 시끄럽게 만들고, 특정 알림에만 즉각 대응해야 하는 경우를 위한 채널을 추가하면 됩니다.
5단계: 데이터베이스 모니터링 설정 완료
이론상으로는 이제 훌륭한 모니터링 체계를 갖춘 셈입니다. 필요한 데이터가 들어오고, 문제가 커지기 전에 경고해 주는 트리거를 설정했으며, 주요 원인들도 찾았습니다. 이제 끝난 걸까요?
현실은 다릅니다. 앱 사용량이 늘면서 새로운 병목이 생길 수 있습니다. 코드 변경이 데이터베이스에 영향을 미쳐 쿼리 시간이 늘어날 수도 있습니다. 페이로드가 큰 특정 필드가 문제를 일으킬 수도 있습니다. 아무리 경험이 많아도 새로운 문제와 병목은 언제든 발생합니다.
하지만 제대로 된 설정만 갖춰두면, 문제가 생겼을 때 경고를 받고 아키텍처를 깊이 파고들어 해결할 수 있다는 사실이 큰 위안이 됩니다.
그리고 다른 나사가 빠지기 전에 영향력 큰 쿼리들을 먼저 개선하는 일에서 즐거움을 찾을 수도 있습니다. 그것이 우리가 가장 좋아하는 일입니다. 물론 스트루프와플도 빼놓을 수 없죠.
AppSignal을 사용해 보세요, 스트루프와플을 드립니다 🍪
스트루프와플 얘기가 나온 김에 말씀드리면, 우리는 전 세계로 스트루프와플을 보냅니다. Ruby, Elixir, Node.js용 AppSignal APM 소프트웨어를 사용해 보세요. 무료 체험을 시작하고 연락해 주시면 스트루프와플 한 상자를 무료로 보내 드립니다.