• 복제 : 소스인 어느 서버에서 레플리카라 하는 하나 이상의 추가 서버로 데이터를 보내는 기능.
  • 기능적 샤딩 : 데이터 세트의 가동 시간, 성능, 액세스 제어를 별도로 관리하기 위해 특정 비즈니스 기능을 수행하는 특정 테이블을 전용 클러스터로 분할하는 것을 의미함.
  • 수평적 샤딩 : 단일 클러스터에서 안정적으로 제공할 수 있는 크기 이상으로 데이터 세트가 증가한 경우, 이를 여러 클러스터로 분할하여 여러 노드의 데이터를 제공하고 필요한 하위 집합을 찾는 조회 메터니즘에 따라 데이터를 제공.
  • 샤딩 : 같은 테이블 schema를 가진 데이터를 다수의 DB.(하나의 큰 테이블을 쪼개 각각 다른 DB에 분산)
  • 수평 파티셔닝 : 같은 DB에서 하나의 큰 테이블을 쪼개 분산,저장.
  • 수직 파티셔닝 : 테이블의 일부 열을 빼내는 형식으로 분할.
    1. 서비스 수준 목표의 정의
  • SLI(서비스 수준 지표) : 사용자의 관점에서 건강한 시스템의 정도.(고객의 만족도를 어떻게 측정할까)
  • SLO(서비스 수준 목표) : SLI가 정상적인 서비스로 간주 될 수 있게 하기 위한 목표 범위.(고객이 만족할 수 있게 SLI를 허용할 수 있는 최소 수준)
  • SLA(서비스 수준 계약) : 하나 이상의 비즈니스 고객과의 계약에 포함된 SLO. SLA는 선택 사항임.
    #모든 기능이 고객의 만족을 유지하기 위해 높은 가용성을 요구하는 것이 아님 -> 특정 기능의 영향이나 그로 인한 수익에 따라 다양한 SLI와 SLO 갖게 됨.
    => 데이터 세트가 서로 다른 이해 관계자에 의해 실행된 별개의 쿼리에서 병목 현상이 발생하여 성능이 저하되는 경우를 감지하는 것이 중요.
    => 합리적인 SLI와 SLO를 제시할 수 있도록 이해 관계자들의 요구를 분리하는 방법을 찾아야됨.

2. 측정 대상

  1. 모니터링 솔루션 : 쿼리 분석 및 모니터링 쿼리 대기 시간은 고객 경험에 중점을 두어야한다. so, 쿼리 응답 시간이 합의된 임계값보다 길어지면 가능한 한 빨리 경고할 수 있는 도구에 의존해야 한다. -> 해당 수준의 모니터링을 달성하기 위한 여러가지 방법 소개.
    • 상용 옵션 : mysql 성능을 프로파일링하는 특정 작업이 경쟁 우위인 벤더에게 비용을 지불하는 사례 중 하나.
    • 오픈 소스 옵션 : 확실한 오프 소스 옵션 = PMM(Percona Monitoring and Management). 클라/서버 쌍으로 작동하며 매트릭을 수집하여 서버 부분으로 보내는 클라이언트를 DB instance 에 설치. -> 장점 : mysql 성능 모니터링에 대한 Percona 커뮤니티의 오랜 경험 바탕으로 대시보드 구성 가능.

  2. 가용성 모니터링 : 가용성은 오류 없이 고객 요청에 응답할 수 있어야 함. 가용성을 나타내는 메트릭(저장된 데이터에 대해 수행되는 계산. 그결과가 리포트로 표시됨)을 선택할 때 ‘100% 가동’은 합리적이지 않으며, 여기에서 초점은 해당 컴포넌트의 장애가 불가피함을 이해하고 수용하는 가운데, 가능한 한 최고의 고객 경험을 제공하는 것이라는 데 초점을 맞추고 고객 지원 팀과 함께 기대치를 설정. 선호하는 가용성 확인 방법 : 클라이언트 or 원격의 엔드포인트에서 하는 것.
    • 대표적인 가용성 mysql 메트릭 : threads_running(현재 실행 중인 쿼리 수)
    • 가용성 mysql 매트릭2 : max_connections 에 얼마나 근접해 있는지 모니터링하여 진행 중인 작업의 과부화 확인 가능.
  3. 쿼리 지연 모니터링 : datadog(유료), solarwinds database performance monitor(유료), pmm(오픈 소스) 매트릭 요약 && 애플리케이션 개발자와의 협업.
  4. 오류 모니터링 : 모든 오류가 확실히 문제가 있다고는 말할 수 없지만, DB 쿼리를 처리하는 서비스 전체에 걸쳐 발생하는 오류의 비율은 문제를 일을키는 중요한 지표.
    • Lock wait timeout : 트랜잭션이 계속 재시도하고 여전히 실패하는 소스 노드의 행 잠금 경합이 증가하고 있다는 신호 가능성.
    • Aborted connections : 중단된 연결의 갑작스러운 급증을 보고하는 클라이언트는 클라이언트와 DB instance 사이에 있는 액세스 계층의 문제를 나타내는 지표 가능성.
    • Connection_errors_xxx : mysql 서버가 추적하는 방법. 서버 변수 집합. xxx = 다른 종류의 연결 error. 이 수치 중 하나라도 갑자기 증가하면 새롭고 특이한 무언가가 현재 고장 났음을 알려주는 지표.
  5. 사전 모니터링 : 정상 상태 모니터링 -> 변경 여부와 관계없이 시스템에서 예기치 않은 일이 발생하고 있음 알 수 있음.
    유용한 신호 예시
    • 디스크 증가 : 문제가 될 때까지는 신경쓰지 않아도 되는 일종의 메트릭. undo log가 크거나 table 변경이 있는 장기 실행 트랜잭션과 같은 작업은 전체 디스크가 너무 빨리 채워지는 원인이 될 수 있음.
    • 연결 증가 : 애플리케이션에서 하는 일이 많음 -> 연결 많이 필요. so, 레플리카를 추가하거나, 복제를 확장 수단으로 사용하거나, proxySQL과 같은 미들웨어 계층을 사용하여 늘어나는 frontend를 db에서 직접 연결 부하로부터 분리함으로써 당분간 이러한 연결 완화.
    • 복제 지연 : 원본에 기록 중인 데이터와 레플리카에서 사용 가능한 데이터 사이의 지연을 복제 지연이라고 함. -> 지연으로 인해 데이터가 불일치하는 것으로 보일 수 있음.
    • I/O 활용 : iostat 도구 사용. -> I/O 대기 상태를 모니터링할 수 있음.
      DB 서버의 IOwait에 thread가 많다면, 그 스레드들이 일부 디스크 리소스가 사용 가능해질 때를 기다리는 대기열에 있다는 것을 알려주길 원함.
      IOutil을 유의미한 기간 동안의 실행 그래프를 통해 추적하면 이 사실 확인 가능.(전체 시스템 디스크 액세스 용량의 백분율로 보고) -> 병목 현상 유발 미리 방지
    • 자동 증가 공간(잘 안알려짐) : 자동 증가 기본 키가 기본적으로 부호를 가진 정수로 생성되어 키 공간이 부족할 수 있다. 이 문제는 자동 증가 키가 가능한 최댓값에 도달할 정도로 충분히 삽입된 경우에 발생.
      키 공간 부족 모니터링 : PMM/Prometheus exporter -> -collect.auto_increment.columns 플래그 키기.
    • 백업 생성/복원 시간 : 재해 복구. 샤딩이나 파티셔닝 같은 작업은 데이터가 너무 클 때 시작하는게 아니라 성공적인 고객 경험을 제공하기 위한 목표를 정의할 때 시작해야함.

3. 장기적인 성능 측정

[1] 비즈니스 케이던스 배우기 : 비즈니스 Cadence는 피크 트래픽 시간이 평균보다 훨씬 크다는 것을 의미할 수 있음. 비즈니스 주기는 비즈니가 대상으로 하는 고객의 요구에 따라 크게 달라짐. 엔지니어링 조직의 다른 부서와 동일한 도구를 최대한 많이 사용하는 것부터 시작 -> 전체 스택의 성능에 투자하고 엔지니어가 작성하는 기능과 이를 지원하는 DB간에 느낄 수 있는 간극을 줄이는데 도움.
[2] 효과적인 메트릭 추정 : 특정 시점에 데이터 저장소 인프라의 상태를 측정할 수 있을 뿐만 아니라 정기적으로 성능 향상 또는 저하 추세를 파악할 수 있어야 함.
[3] 성능 점검을 위한 모니터링 도구 사용

  • 평균을 맹신하지 말자 : 몇 주 이상의 기간 동안 메트릭의 추세를 확인해야 하는 경우 평균은 최고치를 완화. -> 잘못된 보안 정보. so, 월별 데이터를 추세화 할 때 항상 최고점을 확인해야 뷰에서 간헐적으로 급증하는 데이터의 정확도를 유지 가능.
  • 백분위수는 우리에게 많은 도움을 준다 : 백분위수는 주어진 시간 범위에서 데이터 요소를 정렬하고 대상 백분위수에 따라 가장 높은 값을 제거하는 방식(95%찾을려면 상위 5%제거).=> SLI,SLO와 시각적으로 더 유사하게 만드는 good method.
  • 긴 보존 기간 및 성능 : 비즈니스 메트릭 동향에 대한 솔루션을 평가하는 경우 더 긴 시간 범위의 데이터 기간을 요청할 때 사용자 경험이 어떻게 달라지는지 테스트해야함. 메트릭 솔루션은 수집속도나 데이터 유지 기간이 아니라 가용한 데이터를 만드는 데만 효과적.

    [4] 전체 아키텍처링에 SLO 사용하기 : 장단기 메트릭을 모두 처리할 수 있고 유용한 방식으로 변경 추세를 추적할 수 있는 메트릭 솔루션을 갖는 것은 DB의 인프라의 운영방식에 대한 장기적인 비즈니스 영향 추세와 함께 전술적 성능 메트릭을 추적하는 데 매우 중요한 부분임.