신뢰성 엔지니어링 환경에서의 모니터링

신뢰성 엔지니어링 그리고 DBA

 

지난 수년간, 데이터베이스 성능 모니터링은 단일 서버 성능에 대한 심층 분석에 의존했다. 이는, 사후 대응적인 측정에 더 중점을 경향으로 DBA가 게이트키핑으로서 역할할 때의 표준 운영 절차였다. 

하지만, 현대의 DBA는 다르다. 구글은 신뢰성 엔지니어링에 대해 다음과 같이 이야기 한다.

DBA의 역할은 더욱 복잡해지고 SRE(사이트 신뢰성 엔지니어) 또는 DBRE(데이터베이스 신뢰성 엔지니어)로 바뀌었으며, 팀은 시간을 최적해야합니다. 서비스 수준은 고객이 언제 불만을 느끼는지 정의하는 데에 도움이 되며, 성능 문제와 내부적으로 처리하는 작업 문제를 조율하여 시간을 보다 효율적으로 안배할 수 있습니다.

즉, 성공적인 고객 경험을 보장하기 위해 MySQL을 모니터링하는 것은 중요하다. 이 장에서는 이 모니터링을 효과적으로 수행하는 방법에 대해 알아볼 것이다.

 

서비스 수준 목표의 정의

 

데이터베이스 클러스터의 성능에 만족하는지 여부를 측정하는 데에는 여러가지 질문이 따라온다.

 

- 데이터 베이스의 성능이 만족스럽다는 것의 적절한 지표는 무엇일까?

- 데이터 베이스 성능이 저하된 시점을 언제라고 간주할 수 있을까?

- 데이터 베이스 장애가 발생하는 시점은 언제고, 최대한 빠르게 수습해야하는 시점은 언제일까?

 

이러한 질문들에 대해 명확한 답이 있는 경우도 있겠지만, 대게는 명확한 답을 찾기 어려운 경우가 많다. 가령, 스케줄링 작업으로 인해 대부분의 데이터베이스 디스크 I/O가 사용되고, 다른 작업들이 지연되는 경우가 있다. 조직 전체에 우리가 측정하는 항목과 그 이유를 공유하면 우선 순위 지정 대화를 유도할 수 있다. 또한, 성능 개선과 신뢰성에 더 많은 투자가 필요한지에 대해 근거를 제시해줄 수도 있다.

 

SRE ( Site Reliability Engeeniering, 사이트 신뢰성 엔지니어링 ) 실무에서는 고객 만족도에 대한 이러한 논의를 통해 SLI, SLO, SLA 측면에서 비즈니스에 적합한 사항을 파악할 수 있다.

 

- 서비스 수준 지표 ( SLI )

고객 만족도를 어떻게 측정하는가에 대한 답. 사용자의 관점에서 건강한 시스템을 나타냄. 가령, "고객 대면 API에 대한 응답 시간"과 같은 비즈니스 수준의 지표가 될 수도 있고, 보다 근본적인 "서비스가 가동 중인지 여부"가 될 수도 있다. 

 

- 서비스 수준 목표 ( SLO )

고객이 만족할 수 있게 SLI를 허용하는 최소 수준이 어느 정도인지에 대한 답. 즉, SLO는 주어진 SLI가 정상적인 서비스로 간주될 수 있게 하기 위한 목표 범위. 모든 것이 SLO가 의미하는 바를 따르도록 SLO를 일정 기간의 값으로 정의해야 한다.

 

- 서비스 수준 계약 ( SLA ) 

SLO가 가져올 결과에 동의할 의향이 있는지 여부에 대한 답. SLA는 하나 이상의 비즈니스 고객과의 계약에 포함된 SLO로, 해당 SLA가 준수되지 않을 경우, 비즈니스적 혹은 금전적 패널티를 받을 수도 있다. 이는 어디까지나 선택사항이다.

 

고객만족을 위해 필요한 것은 무엇일까?

 

일련의 메트릭을 SLI로 선택한 후, 목표를 100%로 잡는 것은 지양해야 한다. 핵심은 특정 메트릭이 고객이 수용할 수 있는 수준 아래로 떨어질 위험이 있는지 판단하고, 더 많은 관심과 리소스를 투자하는 것이 필요한지 여부를 결정하는 것이라고 볼 수 있다. 

가령, 고객이 2초 안에 페이지가 로드되는 것에 만족한다면 페이지가 750 밀리초 안에 로드되도록 목표를 설정할 필요는 없다. 이는 오히려 엔지니어링 팀에 무리를 줄 수 있다. 가동시간을 SLI 메트릭으로 생각한다면, 다운 타임이 발생하지 않는 것을 목표로 잡을 수도 있다. 하지만 이 목표를 달성하고 있는지 여부를 확인하고 추적하는 것 나아가 99.9% 이상의 가용성을 확보하는 것은 엔지니어링 시간을 매우 늘린다. 
엔지니어링 시간은 매우 한정되어 있기 때문에, SLO를 선택할 때 완벽을 추구하지 않도록 하자. 

 

측정 대상

 

온라인 스토어를 운영하고 있는 회사를 상정하자. 온라인 쇼핑 수요의 급증으로 인해 회사의 크래픽이 크게 증가하고 있다면, 데이터베이스 계층이 증가된 수요를 감당할 수 있어야 한다. 우리가 인프라 팀이라면, 무엇을 측정하고 모니터링 해야할까?

MySQL에서 유의미한 SLI와 SLO는 "가용성", "지연 시간" 그리고 "심각한 오류 제어" 라는 세 가지 테마 내에서 정의되어야 한다. 온라인 스토어의 예시에서 살펴보자면, "한 달에 걸쳐 측정된 시간의 최소 99.5%에서 페이지 로딩 속도가 수백 밀리초보다 빠르다는 것", "주어진 달에 간헐적 오류가 1%만 허용되는 안정적인 에크아웃 프로세스" 정도와 맵핑될 수 있다. 100%를 요구 사항으로 정의하지는 않기에, 팀은 새로운 기능과 복원력 사이에서 작업의 균형을 맞출 수 있도록 리소스를 분배해야한다. 가령, "데이터베이스 요청의 99.5%가 오류 없이 2밀리초 이내에 처리될 것을 예상하는 것" 은 명확한 SLO를 포함하는 SLI이며, 단순하지도 않다. 하지만 이 하나의 문장을 하나의 메트릭만을 활용하여 검증할 수는 없다. 아래는 좋은 메트릭 구성의 다양한 예시들이다.

 

모니터링 솔루션

 

쿼리 분석 및 모니터링 쿼리 대기 시간은 고객 경험과 가장 밀접하게 맞닿아있다. 즉, 쿼리 응답 시간이 합의된 임계값보다 길어지면 가능한한 빠르게 경고를 줄 수 있어야 한다. 이러한 모니터링을 하는 데에는 크게 두 가지 정도의 방법이 있다.

 

상용 옵션

MySQL 성능을 프로파일링하는 특정 작업이 벤더에게 비용을 지불하는 사례 중 하나이다. SolarWinds Database Performance Management와 같은 도구는 프로파일링 쿼리 성능을 자동화하고, 엔지니어링 조직의 구성원들이 엑세스 할 수 있도록 도와준다. ( 현재 사내에서 사용 중인 Google Cloud 내 MySQL 모니터링 도구 역시도 이러한 상용 옵션의 일환이 아닐까 싶다 )

 

오픈 소스 옵션

대표적인 오픈 소스 옵션으로는 PMM ( Percona Monitoring and Management )이 있다. 클라이언트/서버 쌍으로 작동하며 메트릭을 수집하여 서버 부분으로 보내는 클라이언트를 데이터베이스 인스턴스에 설치하는 방식이다. 서버 측에는 성능과 관련된 그래프를 볼 수 있는 대시보드 세트도 존재한다. PMM의 가장 큰 장점은, Percona 커뮤니티의 많은 리소스를 기반으로 대시보드를 구성할 수 있다는 점이다. MySQL에 익숙하지 않은 개발자도 쉽게 접근하고 모니터링을 구성할 수 있는 셈이다.

Percona Toolkit 패키지의 일부인 pt-query-digest와 같은 도구를 사용하면, 로그를 분석하고 데이터 베이스의 느린 로그 및 성능 스키마 출력을 중앙 집중된 위치로 전송할 수도 있다. 하지만 이것은 속도를 느려지게 할 수 있고, 적절하게 사용하지 못하면 결과적으로 고객 경험에 악영향을 줄 수 있다. 

성능 스키마를 사용하여 MySQL 성능을 프로파일링 하는 것은 매우 유용할 수 있다. 이를 통해 병목 현상을 찾아 동일한 사양으로 인스턴스가 더 많은 작업을 수행하게 하거나 인프라 비용을 절감할 수 있기 때문이다. 나아가 왜 이렇게 작업 시간이 오래 걸리는지에 대한 답을 찾아줄 수도 있다.

 

PMM의 활용 예시

 

가용성 모니터링

 

가용성은 오류 없이 고객 요청에 응답할 수 있는지에 대한 지표이다. 하나의 기기로 된 단일 호스트 시스템 시대에는 가용성이 단순한 측정 기준이었다. 하지만, 오늘날 대부분의 아키텍처는 훨씬 더 복잡하고, 가용성 개념이 발전하여 분산 시스템이 실패하는 경우에 대한 보다 미묘한 반영을 포함한다.  가용성을 데이터베이스 아키텍처에 대한 SLI 및 SLO로 전환할 때는 아래와 같은 세부 사항들이 고려되어야 한다.

 

- 불가피한 치명적 오류를 처리할 때, 타협할 수 없는 기능은 무엇이고 있으면 좋은 기능은 무엇일까?
   가령, 장애가 발생하는 동안 고객이 장바구니에 새 아이템을 담을 수는 없지만, 기존 장바구니는 유지되고 확인이 가능함.
- 어떠한 유형의 장애를 '치명적'이라고 정의할까?
   가령, 목록 검색 실패는 치명적이지 않지만. 체크아웃 작업의 실패는 치명적임
- '저하된 기능'이란 어떤 상태를 의미할까?
   가령, 필요할 때 과거의 구매 이력을 기반으로 커스터마이징된 권장 사항 대신 일반적인 권장 사항을 로드하는 것
- 일련의 가능한 장애 시나리오를 고려할 때, 핵심 기능에 대해 보장할 수 있는 최단 MTTR( 평균 복구 시간 )은 얼마일까?
   가령, 장바구니 체크아웃 시스템을 지원하는 데이터베이스가 쓰기 작업에 실패한 경우, 새 소스 노드로 안전하게 피벗할 수 있는 속도

 

여기서 초점은 장애가 불가피함을 이해하고 수용하는 가운데, 가능한 한 최고의 고객 경험을 제공하는 것이라는 데 초점을 맞추고 사업 팀과 함께 그 기대치를 설정하는 데에 있다. 

가용성 확인 방법 중 가장 선호되는 것은 클라이언트 또는 원격의 엔드포인트에서 코드를 수행하는 것이다. 환경이 분리되어 있고, 클라이언트 로그에 엑세스할 수 없는 경우, 데이터베이스에서 작업을 수행하는 원격 코드를 구성할 수도 있다. 가령, `SELECT 1` 과 같은 구문을 통해 MySQL이 쿼리를 수신하고 구문을 분석하며 스토리지 계층에 엑세스 하는지 확인할 수 있다. 

이러한 가용성 원격 검증은 가용성 목표를 추적하는데에 유용하다. 다만, 이것이 문제가 발생하기 전에 상황을 파악하는 데에 도움을 주지는 않는다. 미리 문제를 파악하기 위해 사용될 수 있는 선행 지표로 대표적으로는 MySQL 상태 카운터 `Threads_running`이 있다. 이것은 주어진 데이터베이스 호스트에서 현재 실행 중인 쿼리 수를 추적한다. 실행 중인 스레드가 빠른 속도로 증가하고 감소하는 징후가 보이지 않으면, 쿼리가 신속하게 완료되지 않아 리소스를 누적하여 소비하고 있음을 나타낸다. `Threads_running`이 증가하도록 허용하는 경우, CPU lockup이 일어나거나, 메모리 로드가 심해져 운영 체제에 의해 전체 MySQL 프로세스가 종료될 수도 있다. 따라서 `Threads_running`이 임계치를 초과하는 경우, 서버가 불안정한 상태에 있다는 신호로 간주하고 대비해야한다. 이와 함께 `max_connections`에 얼마나 근접해 있는지 모니터링하여 진행 중인 작업의 과부하도 확인할 수 있다.

 

쿼리 지연 모니터링

 

데이터베이스 서버에서 쿼리 지연 시간을 직접 추적하는 것 뿐만 아니라, 쿼리 완료 시간까지 클라이언트가 보고하게 함으로써 고객 경험에 최대한 가까워질 수 있다. 대표적으로 유료 도구인 Datadog 또는 SolarWinds Database Performance Monitor를 사용하거나 오픈 소스인 PMM을 사용하여, 모든 메트릭을 일목요연하게 조회할 수 있다.

 

오류 모니터링

 

실행 중인 서비스에 MySQL 클라이언트에 오류가 존재한다고 해서 무언가 확실히 문제가 있는 것은 아니다. 분산 시스템에서는 클라이언트에 간헐적으로 오류가 발생할 수 있으며,  대부분의 경우 실패한 쿼리를 간단히 재시도하여 해결할 수 있다. 다만, 서비스 전체에 걸쳐 발생하는 오류의 비율은 문제를 일으키는 지표가 될 수 있다. 아래는 사소한 해프닝일 수도 있지만, 나중에는 문제의 징후가 될 수 있는 몇 가지 클라이언트 측 오류의 예시이다. 

 

Lock wait timeout

클라이언트가 이 오류의 급격한 증가를 보고하는 것은 트랜잭션이 계속 재시도하고 여전히 실패하는 소스 노드의 행 잠금 경합이 증가하고 있다는 신호이다. 쓰기 다운 타임의 전조 현상이 되기도 한다.

 

Aborted connections

중단된 연결의 갑작스러운 급증을 보고하는 오류이다. 클라이언트와 데이터베이스 인스턴스 사이에 있는 엑세스 계층의 문제를 나타내는 지표가 된다. 추후 클라이언트 측 재시도가 많이 발생하여 리소스가 소모될 수도 있다.

 

MySQL 서버가 에러를 추적하는 방법 중 하나는 `Connection_errors_%ERROR_NAME%` 라는 서버 변수 집합을 확인하는 것이다. 이 수치 중 하나라도 갑자기 증가하면, 새로운 무언가가 현재 문제가 있음을 알려주고 있다고 볼 수 있다. 

 

단일 인스턴스에서 문제가 발생하는 경우도 있다. 가령, MySQL 인스턴스가 읽기 전용 모두로 실행되고 있다는 오류가 발생했다면, 그것의 빈도가 높지 않더라도 문제가 있다는 신호가 될 수 있다. 이는 레플리카가 소스로 승격되었지만, 여전히 읽기 전용 모드로 실행 중임을 의미한다. 혹은 쓰기 트래픽을 레플리카로 보내는 엑세스 계층에 문제가 있음을 의미할 수도 있다. 두 가지 모두 재시도를 통해 문제가 해결되는 간헐적인 케이스에 해당되지는 않는다.

 

또 다른 서버측의 오류로는 '너무 많은 연결' 또는 OS 수준의 '새 스레드 작성 불가'가 있다. 이것은 서버 `max_connections` 변수 또는 MySQL 프로세스에서 열 수 있는 스레드 수에서 데이터베이스가 서버가 허용하도록 구성한 것보다 어플리케이션 계층이 더 많은 연결을 생성했다는 지표이다. 이 경우, 오류는 5xx 형태로 클라이언트에 즉시 반환되고, 고객에게까지 영향을 미칠 수 있다.  

 

사전 모니터링

 

회사를 다니다보면 다양한 CS 문의를 경험하게 된다. 여기에는 재현이 어려운 것들도 존재하고, 구성 요소에서 심각한 오류가 발생하지 않았지만 저절로 사라지는 것처럼 보이는 오류를 제보하는 고객도 존재한다. 서비스의 규모가 커질 수록 이러한 오류의 보고가 잦아질 수도 있다. 결국 우리는 이러한 행동을 추적하고, 사전 예방적인 모니터링을 지속해야한다. 모니터링을 통해 균형을 유지하는 일은 중요하다. 100% 꽉 찬 데이터베이스 디스크 공간에 대한 알림은 서비스가 이미 중단된 상황이므로 늦은 것이지만, 증가 속도가 지나치게 빠르지 않은 상황에서 80% 알림은 우리가 조치를 취할 수 있기 때문이다. 이러한 모니터링 과정에서 경고를 트리거하는데 사용하는 대시보드 및 스크립트를 정상 상태 모니터링( steady state monitoring )이라고 한다. 아래는 모니터링이 가능한 유용한 신호들이다.

 

디스크 증가

 

디스크 증가율 추적은 문제가 될 때까지는 신경쓰지 않아도 되는 메트릭 유형이다. 다만, 문제가 될 경우 문제 해결에 시간이 많이 걸리고 비즈니스에 영향을 줄 수 있다. 

디스크 증가를 모니터링하는 데에는 여러가지 방법이 있다. 가령, 모니터링 도구에서 디스크 공간 사용량 증가율을 추적할 수 있다. 이 때, 사용가능한 디스크 공간이 급격히 빨리 소진되어 가용성이 위험에 처하는 시나리오가 있기도 하다. 이는 주로 언두 로그가 크거나 테이블 변경이 있는  장기 실행 트랜잭션과 같은 작업으로 인해 전체 디스크가 너무 빠르게 채워지는 것이 원인이다. 

증가율을 추적할 수 없는 경우, 업무 시간 동안만 발생하는 낮은 경고와 업무 외 시간에 대한 경고로 더 높은 중요 값을 사용하여 다양한 임계값을 상정할 수도 있다. 이를 통해 팀은 업무 시간 중에 상황이 심각해지기 전 사전 조치를 취할 수 있다.

만약, 증가율을 모니터링할 수 없고, 동일한 메트릭에 대해 다양한 임계값을 설정할 수도 없는 경우라면 어떻게 할까? 이 경우, 담당 엔지니어를 호출하는 데 사용되는 디스크 공간에 대해 최소한의 단일 임계값을 결정하는 것이 중요하다. 당연하게도 이 임계값은 일부 작업과 디스크 여유 공간을 허용할 만큼 충분히 낮아야한다. 

 

연결 증가

 

비즈니스가 성장함에 따라 선형적으로 함께 성장하는 공통 계층은 어플리케이션 계층이다. 온라인 쇼핑몰 예시에서 살펴보자면, 로그인 / 쇼핑 카트 / 요청 처리 / 결제 등 더 많은 인스턴스가 필요하고, 이 인스턴스들이 테이터베이스 호스트에 대해 연결을 더 많이 열기 시작한다. 이 때, 레플리카를 추가하거나, 복제를 확장 수단으로 사용하거나, ProxySQL과 같은 미들웨어 계층을 사용하여 데이터베이스 연결 부하를 어느 정도 완화할 수 있다.

트래픽이 증가하는 동안 데이터베이스 서버는 `max_connections`를 설정하는 서버로 구성된 유한한 연결 풀을 지원한다. 서버에 대한 총 연결 수가 최대에 도달하면 데이터베이스는 더 이상 새로운 연결을 허용하지 않는다. 이것은 사용자가 겪는 오류로 곧바로 이어진다. 따라서 연결 증가를 모니터링하는 것은 중요하며, 이는 연결 증가가 데이터베이스 가용성을 위협할 정도로 리소스를 소모하는 것을 방지해준다.

연결 증가가 주는 위험은 크게 두 가지 형태로 나타난다. 

- 어플리케이션 계층이 사용하지 않는 많은 연결을 열어 합당한 이유 없이 연결이 최대화된다. `threads_connected`가 높다고 표시되지만, 실제로 threads_running은 낮다.

- 어플리케이션 계층이 현재 많은 연결을 사용하고 있으며 데이터베이스에 과부하가 걸릴 위험이 있다. `threads_running`과 `threads_connected`가 모두 높은 갚으로 측정된다.

연결 수에 대한 모니터링을 설정할 때 중요한 것은 결국 절대 수치가 아닌 백분율이다. `thread_connected/max_connections` 값은 어플리케이션 노드 수가 증가함에 따라 데이터베이스가 허용할 수 있는 최대 연결 풀에 얼마나 근접했는지 보여준다. 이와 별개로 `threads_running` 값을 통해 데이터베이스 호스트의 사용 현황을 추적하고 경고해야 한다. 일반적으로 `threads_running`이 100개의 스레드 이상으로 증가하면 CPU 사용량과 메모리 사용량이 증가하기 시작한다. 즉, 데이터베이스 호스트에서 부하가 많이 발생한다는 신호인 것이다. 여기에 대해 가장 빠른 솔루션은 kill process  명령어 또는 pt-kill과 같은 장동화를 통해 부하를 완화하는 것이다.  

 

복제 지연

 

MySQL에는 소스인 서버에서 레플리카라고 하는 하나 이상의 추가 서버로 데이터를 보내는 기본 복제 기능이 있다. 원본에 기록 중인 데이터와 레플리카에서 사용 가능한 데이터 사이의 지연을 복제 지연이라고 한다. 어플리케이션이 레플리카에서 데이터를 읽는 경우, 복제 지연으로 인해 데이터가 불일치하는 것처럼 보일 수 있다. 지연은 사고를 유발할 수 있는 심각한 SLI가 될 수 있는 메트릭 중하나이다. 또한 더 많은 아키텍처 변경이 필요함을 나타내는 장기적인 추세이기도 하다. 

 

I/O 활용

 

데이터베이스 엔지니어의 끝없는 노력 중 하나는 '메모리에서의 작업 처리가 더 빠르기 때문에 최대한 많은 작업을 메모리에서 수행하는 것'이다. 데이터베이스 인프라가 확장되고 데이터가 더 이상 메모리에 존재하지 않는다면, 차선책은 I/O 주기를 기다리며 ( 쿼리가 멈추는 것을 방지하기 위해 ) 디스크에서 너무 많은 데이터를 읽지 않도록 하는 것이다. 이는 SSD에서 거의 모든 것이 실행되는 요즘 시대에도 마찬가지다. 데이터 크기가 커지고 쿼리가 요청을 충족하기 위해 더 많은 데이터를 검색해야 하는 경우 I/O 대기 시간이 트래픽 증가에 걸림돌이 된다. 따라서 I/O 모니터링은 성능 저하가 고객에게까지 영향을 미치기 이전에 대처를 할 수 있게 한다.

모니터링의 대표적인 방법은 iostat과 같은 도구를 사용하는 것이다. iostat을 통해 대기열에 디스크 리소스가 사용 가능해질 때까지 기다리는 스레드가 전체 시스템 디스크 엑세스 용량 대비 어느 정도 있는지 알 수 있고, 이 값이 100%에 가까울 수록 전체 테이블 스캔을 하거나 비효율적인 쿼리 실행을 하고 있음을 알 수 있따. 

 

자동 증가 공간

 

MySQL을 사용할 때, 잘 알려지지 않는 지뢰 중 하나는 자동 증가 기본 키가 기본적으로 부호를 지닌 정수로 생성되어 키 공간이 부족할 수 있다는 것이다. 대부분의 프로젝트에서는 크게 문제되지 않겠지만, 만약 이 자동 증가 키가 가능한 최댓값에 도달할 정도로 충분히 삽입된 경우에 발생한다. 따라서 자동 증분을 기본 키로 사용하는 모든 테이블에 대해 남은 정수 공간을 모니터링하는 것은 심각한 문제를 확실하게 줄일 수 있는 가장 간단한 방법이다. 만약 팀이 PMM과 Prometheus exporter를 사용하고 있다면, 기본 제공되는
`--collect.auto_increment.columns` 플래그를 켜기만 하면 된다. 만약 이러한 도구들을 사용하고 있지 않다면, information_schema를 참조하여, 직접 SELECT 하는 쿼리문을 통해 모니터링이 가능하다. 

 

백업 생성/복원 시간

 

장기적인 관점에서 사전 모니터링은 허용되는 시간 내에 복구하는 것을 포함한다. 핵심은 비즈니스의 중요한 기능을 복원할 때, 백업에서 복원하는 데에 소요되는 시간이 허용 시간을 초과한다면 적절한 샤딩 혹은 '중요한 기능'의 정의 변경 등을 통해 백업 복원 시간을 단축해야한다. 재해 복구를 계획할 때 고려해야하는 사항은 아래와 같다.

- 복구 대상에 포함되는 기능을 구체화하고, 필요에 다라 기능 하위 집합을 실행하는 데이터가 실제로 구현되기 위해 별도의 클러스터에 있어야하는지 여부

- 데이터를 여러 개 혹은 더 작은 인스턴스로 기능적으로 분할할 수 없는 경우 전체 데이터 세트가 백업을 통해 복구되는 대상 하위에 존재하도록 하기

- 자동화된 테스트 방법을 사용

 

 

장기적인 성능 측정

 

비즈니스 케이던스

 

비즈니스 케이던스 ( Cadence )는 피크 트래픽 시간이 평균보다 훨씬 크다는 것을 의미할 수 있으며, 데이터베이스 인프라가 준비되지 않은 경우 많은 결과를 초래할 수 있다. 인프라 측면에서 이는 초당 더 많은 요청을 수행해야 하며, 어플리케이션 레벨에서 더 많은 연결 부하가 생기거나 쓰기 작업의 간헐적 실패하가 발생할 수 있음을 상기시킨다. 

 

케이던스 ( Cadence ) 란? 
A regular and repeated patter of activity. 즉, 규칙적이고 반복되는 어떠한 행동

비즈니스 케이던스의 대표적인 예시
- 전자상거래 사이트: 11월 말부터 연말까지 평소와 다르게 훨씬 더 많이 쇼핑 카트의 아이템이 쌓이고 동시 판매가 더 많이 일어난다. 
- 인사 관리 소프트웨어: 미국의 경우, 11월은 많은 근로자가 'Open enrollment'라고 해서 자사의 복리후생을 선택하는 기간인데, 이것이 많은 트래픽을 발생시킨다. 
- 온라인 생화 판매 업체: 밸런타이데이에 1년 중 가장 많이 트래픽이 발생한다.

이렇듯, 비즈니스 주기는 비즈니스가 대상으로 하는 고객의 요구에 따라 크게 달라질 수 있고, 평소 동일한 오류가 이 시기에는 큰 영향을 미칠 수도 있다.  

 

효과적인 메트릭 추적

 

특정 시점에 데이터 저장소 인프라의 상태를 측정할 수 있을 뿐만 아니라 장기적으로 성능 향상 또는 저하 추세를 파악할 수 있어야 한다. 즉, SLI와 SLO를 식별하는 것뿐만 아니라 어떤 SLI와 SLO가 장기적인 추세에도 중요한 고강도 신호 메트릭으로 남아 있는지도 확인할 수 있어야 한다.

 

성능 점검을 위한 모니터링 도구 사용

 

좋은 SLI를 선택하더라도, 그것을 추적할 수 없다면 의미가 없다. 모니터링 도구 분야는 빠르게 성장하고 있으며, 이를 어떻게 수행해야 하는지에 대해서는 여전히 의견이 분분하다. 그럼에도 불구하고 핵심은 투명성을 높이고 산출물보다는 결과를 추적하는 데 중점을 두는 것이다. 특정 도구를 추천하는 대신, 도구를 판단할 때 고려해야할 몇 가지 측면에 대해 보자. 

 

1. 평균을 맹신하지 마라. 

많은 솔루션이 기본적으로 장기 데이터를 평균으로 집계하는데, 이는 큰 문제다. ( 대표적으로 Graphite가 있다 ) 몇 주 이상의 긴 기간 동안 메트릭 추세를 확인해야 하는 경우, 평균은 최고치를 완화해버린다. 결국 이는 잘못된 보안 정보를 주게 된다. 가령, 연결 수가 비즈니스 케이던스에 max_connections에 가깝게 도달했지만, 한 달을 평균으로 보았을 때는 문제가 없이 느끼는 것이 예시가 될 것 같다.

 

2. 백분위수와 친하게 지내라.

백분위수는 주어진 시간 범위에서 데이터 요소를 정렬하고 대상 백분위수에 따라 가장 높은 값을 제거하는 방식이다. 가령, 95%를 찾고 있다면 상위 5%를 지우는 것이다. 이는 SLI와 SLO를 시각적으로 더 유사하게 만드는 훌륭한 방법이다. 

 

3. 긴 보존 기간 및 성능

긴 시간 범위를 표시하려고 할 때 모니터링 도구의 성능이 중요하다.