데이터베이스 용량 계획

참고: 이 게시물은 용량 계획에 대한 Julia Evans의 최근 게시물에서 영감을 받았습니다.

RDBMS

먼저 몇 가지 기본 규칙을 설정하겠습니다. 예...이 게시물은 한 번에 하나의 작성자와 2개 이상의 읽기 전용 복제본으로 MySQL을 사용하는 사람들을 대상으로 합니다. 여기에서 이야기할 많은 내용은 다중 작성자 클러스터 데이터 저장소에 다르게 적용되거나 전혀 적용되지 않지만 자체적인 절충안 및 주의 사항도 함께 제공됩니다. 따라서 ... 귀하의 마일리지는 확실히 다를 것입니다.

그러나 이 블로그 게시물은 자체 호스팅 물리적 호스트를 사용하는지 또는 마법과 같은 예약 인스턴스와 거의 즉각적인 프로비저닝을 사용할 수 있는 AWS에 있는지 여부에 관계없이 적용됩니다. "클라우드"에 있다고 해서 인프라의 능력과 한계를 알 수 있는 것은 아니며 팀과 고객에 대한 책임도 면제되지 않습니다.

샤딩

나는 이미 이전 게시물 중 하나에서 이에 대한 큰 획을 다루었고 주로 기능적 또는 수평적 샤딩의 이점에 중점을 두었습니다. 예, 데이터베이스 계층에 액세스하는 데 사용하는 항목이 확장해야 하는 유연성을 결정하기 때문에 절대적인 전제 조건입니다.

당신이 새로운 회사라면 첫 날에 기능적 샤딩이 필요하지 않을 수도 있지만 성장하기를 희망한다면(그리고 당신이 그럴 것으로 의심됩니다) 분할을 허용하지 않는 오픈 소스 ORM에 자신을 묶지 마십시오. 기능적으로 데이터를 줄입니다. 단일 스키마에서 모든 관계형 데이터로 회사를 시작하지 않는 경우 보너스 포인트.

읽기와 쓰기를 분할하는 기능

이것은 당신이 할 수 있어야 하는 것이지만 반드시 정해진 규칙으로 시행할 필요는 없습니다. 쓰기 직후에 읽어야 하고 지연/최종 일관성과 같은 허용 오차가 낮은 사용 사례가 있습니다. 그것들은 괜찮지만 동일한 애플리케이션에서 더 긴 시간 범위의 최종 일관성을 견딜 수 있는 읽기 시나리오도 있습니다. 이러한 읽기의 볼륨이 높을 때 실제로 필요하지 않은 경우 해당 볼륨이 단일 작성자에게 전달되기를 정말로 원하십니까? 스스로에게 호의를 베풀고 곧 성장기에 코드에서 읽기 또는 쓰기 IP 사용을 제어할 수 있는지 확인하십시오.

이제 실제 용량 계획에 대한 생각 프로세스에 대해... 데이터베이스 클러스터가 따라가지 못하는데 어떻게 해야 하나요?

시스템 병목 현상 확인

• 쓰기 또는 읽기에 병목 현상이 있습니까?
• 문제가 높은 CPU로 표시됩니까?
• IO 용량으로 표시되고 있습니까?
• 명확한 읽기 쿼리 원인이 없는 복제본에서 지연이 증가하고 있습니까?
• 자물쇠인가요?
• 그것이 무엇인지 어떻게 알 수 있습니까?

이들 각각은 그 자체로 게시물이 될 수 있습니다. 내가 말하려는 요점은 병목 현상이 어느 부분인지 알아낼 수 있으려면 시스템 및 DB 특정 메트릭에 익숙해야 한다는 것입니다.

베이스라인이 필요하다

최소한 몇 주 전에 시각화할 수 있는 기본 시스템 메트릭이 있는지 항상 확인하십시오. 많은 도구가 이를 제공합니다(Cacti, Munin, Graphite… 등). 어떤 시스템 메트릭에 주로 바인딩되는지 알고 나면 기준 값과 피크 값을 설정해야 합니다. 그렇지 않으면 현재 문제가 새로운 응용 프로그램 소스 버그인지 또는 실제 성장인지 판단하는 것은 원하는 것보다 훨씬 더 오류가 발생하기 쉽습니다.

그러나 기본 서버 메트릭은 여기까지만 가능합니다. 어느 시점에서 컨텍스트 기반 메트릭도 필요하다는 것을 알게 될 것입니다. 쿼리 성능 및 앱 측 인지 성능은 애플리케이션이 쿼리에 대한 응답 시간으로 보는 것을 알려줍니다. 이 컨텍스트 헤비 트래킹을 수행하는 많은 도구가 있습니다. 일부는 Anemometer와 같은 오픈 소스 및 Vivid Cortex와 같은 상용 도구입니다(SendGrid에서 이를 사용합니다. 여기에서 이에 대해 설명합니다.). 앱 관점에서 이러한 메트릭을 추적하고 statsd 메트릭으로 던지는 것만으로도 좋은 첫 번째 단계가 될 것입니다. 그러나 초기에는 앱이 인식하는 것이 고객이 인식하는 것이라는 사실에 익숙해져야 합니다. 그리고 먼저 알 수 있는 방법을 찾아야 합니다.

비즈니스의 트래픽 패턴 알아보기

특정 주중(예: 마케팅)에 극한 피크가 발생하기 쉬운 비즈니스입니까? 게임처럼 트래픽을 3배 또는 4배 늘리는 정기적인 출시가 있습니까? 이러한 종류의 질문은 여유 여유를 얼마나 유지해야 하는지 또는 탄력적 성장에 투자해야 하는지 여부를 결정합니다.

사용 중인 용량에 대한 원시 트래픽 수의 비율 결정

이것은 단순히 "코드 최적화를 하지 않았다면 얼마나 많은 이메일/판매/온라인 사용자/무엇이든"에 대한 답입니다. 우리가 지금 가지고 있는 데이터베이스 인스턴스로 서비스를 제공할 수 있습니까?

이상적으로는 1년 성장 계획을 위한 수학을 간단한 수학 방정식으로 만드는 특정 값입니다. 그러나 인생은 결코 이상적이지 않으며 이 값은 계절에 따라 또는 새로운 주요 고객 가입과 같은 완전히 외부적인 행복 요인에 따라 달라집니다. 초기 스타트업에서 이 수치는 더 빠르게 움직이는 목표지만 회사가 초기 단계에서 보다 예측 가능한 비즈니스 성장 패턴을 갖춘 보다 안정적인 비즈니스로 전환함에 따라 안정화되어야 합니다.

정말 기계를 더 사야 합니까?

이것이 진정한 용량인지 판단할 방법을 찾아야 합니다. 더 많은 동시 쓰기 로드를 지원하거나 읽기 전용 복제본을 추가하기 위해 쓰기를 분할해야 합니다. 코드 기반 성능 병목 현상(최근 배포의 이 새로운 쿼리는 실제로 결과를 더 저렴한 곳에 캐시할 수 있고 데이터베이스를 훨씬 능가하지 않을 수 있음).

어떻게 합니까? 쿼리에 익숙해져야 합니다. 이를 위한 초기 단계는 innotop, 느린 로그 및 Percona Toolkit의 pt-query-digest의 조합입니다. DB 로그를 중앙 위치로 배송하고 다이제스트 부분을 자동화하여 이를 자동화할 수 있습니다.

그러나 이것이 전체 그림이 아닙니다. 임계값을 너무 낮추면 느린 로그는 성능 집약적입니다. 덜 선택적인 샘플링으로 살 수 있다면 애플리케이션과 데이터 저장소 간의 전체 대화를 감지해야 합니다. 오픈 소스 랜드에서는 tcpdump와 같은 기본 기능을 사용하거나 Datadog, New Relic 또는 VividCortex와 같은 호스팅 제품을 사용할 수 있습니다.

전화하다

용량 계획은 90%가 과학이고 10%가 예술일 수 있지만 10%가 우리가 할 수 있는 한 많은 그림을 위해 노력하지 않아야 한다는 것을 의미해서는 안 됩니다. 엔지니어로서 우리는 때때로 누락된 10%에 집착하지만 우리가 작업을 수행했다면 90%가 스택의 상태에 대한 더 나은 아이디어를 얻을 수 있고 성능을 최적화하고 용량을 계획하는 데 시간을 보다 효율적으로 사용할 수 있다는 것을 깨닫지 못할 수 있습니다. 결과적으로 우리 제품에 대한 훨씬 더 나은 투자 수익을 가져옵니다.