다음은 제 1 장의 추출물입니다.The following is an extract from Chapter 1 of 데이터베이스 성능 Scale (무료로 사용할 수있는 오픈 액세스 책).Joan의 고도로 환상화 된 모험을 너무 현실적인 데이터베이스 성능 과제로 따르십시오.You will laugh.You will cry.You will wonder how we worked this "cheesy story" into a deeply technical book. 데이터베이스 성능 Scale "하이브리드 클라우드", "서버없는"및 "에지 우선"과 같은 인상적인 버즈워드에 매료 된 Joan는 새로운 회사에 쉽게 가입하여 기술 스택을 잡기 시작했습니다. 그녀의 첫 번째 프로젝트는 최근 고객 수와 같은 속도로 확장되지 않는 데이터베이스 시스템의 내부 구현에서 업계 표준 데이터베이스 관리 솔루션 중 하나로 전환하기 시작했습니다. SQL 세계에서 알려진 보증. 산성 오늘날 매년 나타나는 몇 가지 새로운 데이터 보호 법률 때문에 회사의 이사회는 민감한 정보를 저장하기 위해 인기있는 클라우드 공급 업체 중 하나를 사용하는 대신 자체 데이터 센터를 유지할 것이라고 결정했습니다. 매우 높은 수준에서 회사의 주요 제품은 두 층으로 구성되었습니다 : 프론트엔드는 실제로 자신의 브라우저에서 실행되고 시스템의 나머지 부분과 통신하여 정보를 교환하고 유지하는 사용자의 입력 포인트입니다. 일반적으로 "백 엔드"로 알려져 있지만 실제로 로드 밸런서, 인증, 권한, 다중 캐시 레이어, 데이터베이스, 백업 등을 포함합니다. Joan의 첫 번째 소개 작업은 데이터베이스에서 다양한 통계를 수집하고 요약하는 매우 간단한 서비스를 구현하고 그 서비스를 전체 생태계와 통합하여 실시간으로 데이터베이스에서 데이터를 수집하고 DevOps 팀이 통계를 실시간으로 검사 할 수 있도록했습니다. 경영진을 감동시키고 요한을 고용하는 것이 이번 분기에 최선의 결정이라고 확신하기 위해 요한은 첫날에 개념의 실현을 제공하기로 결정했습니다! 회사의 말할 수없는 정책은 Rust에서 소프트웨어를 작성하는 것이었으므로 그녀는 짧은 crates.io 검색에서 데이터베이스에 대한 첫 번째 드라이버를 잡아 자기 조직 된 해커톤에 앉았습니다. Rust의 에르고노미에 초점을 맞춘 생태계가 뛰어난 개발자 경험을 제공함으로써 하루는 정말로 부드럽게 흘렀다.그러나 Joan은 실제 시스템에서 첫 번째 연기 테스트를 실행했습니다.실망과 무력감으로 변했을 때 그녀는 전체 데이터베이스 클러스터가 건강하고 작동 가능한 상태에 있다고보고했지만 (평균적으로) 세 번째 요청 중 하나가 오류로 끝났다는 것을 깨달았습니다. 불행히도, 드라이버 요안은 서둘러 그녀의 작품의 기초를 선택했다, 비록 오픈 소스 자체는 사전 컴파일 된, 유산 C 코드에 대한 단지 얇은 포장, 출처를 찾을 수없는. 그리고 그녀는 교육적 인 추측을했다. 회사가 사용하는 데이터베이스에서 키는 나중에 적절한 노드에 대한 경로 요청에 해시됩니다.If a hash value is calculated incorrectly, a request may be forwarded to the wrong node that can reject it and return an error instead. Wireshark 버그는 해시 키 구현에 있어야합니다.Bug must be in the hashing key implementation 소스 코드가 부재하기 때문에 주장을 확인할 수 없었기 때문에 Joan는 원래 선택한 드라이버를 버리고 데이터베이스 공급 업체가 지원하는 공식적으로 지원되는 오픈 소스 드라이버 중 하나에 솔루션을 다시 구현하여 견고한 사용자 기반과 정기적으로 업데이트 된 출시 일정을 선택했습니다. Joan's Diary of Lessons Learned, Part I에 대한 리뷰 보기 초기 수업에는 다음이 포함됩니다: The initial lessons include: 조심스럽게 드라이버를 선택하십시오.이 드라이버는 코드의 성능, 안정성 및 신뢰성의 핵심입니다. 드라이버도 버그가 있으며, 그들을 피하는 것은 불가능합니다.그러나 다음과 같은 좋은 관행이 있습니다. 좋은 이유가 없다면 공식적으로 지원되는 드라이버를 선호하십시오 (있다면); 오픈소스 드라이버에는 장점이 있습니다 : 그들은 커뮤니티에 의해 검증 될뿐만 아니라 코드의 깊은 검사를 허용하고 심지어 드라이버 코드를 수정하여 디버깅을위한 더 많은 통찰력을 얻을 수 있습니다. 그들은 합리적인 기간 내에 버그 수정 (보안 취약점 포함)을받을 가능성이 더 높기 때문에 잘 설립 된 출시 스케줄을 가진 드라이버에 의존하는 것이 좋습니다. Wireshark는 네트워크 패키지를 해석하기위한 훌륭한 오픈 소스 도구입니다; 당신이 당신의 프로그램의 캡 아래에서 을 원한다면 그것을 시도하십시오. 소개 작업은 마침내 성공적으로 완료되었으며 Joan은 첫 번째 실제 임무를받을 준비가되었습니다. Tuning 소개 작업에서 얻은 경험을 사용하여 Joan은 그녀의 새로운 임무에 접근하는 방법을 계획하기 시작했습니다 : 잘못된 행동 응용 프로그램. 응용 프로그램 중 하나는 전체 시스템에 안정성 문제를 일으켰으며 문제를 겪을 때마다 다른 워크로드를 방해했습니다. 이 특정 서비스는 오래된 시스템에서 백업 된 데이터를 새로운 데이터베이스에 주입하는 것에 책임이 있었습니다. 회사가 큰 서두르지 않았기 때문에 응용 프로그램은 낮은 우선 순위를 갖고 사용자의 작업 부하에 방해하지 않기 위해 낮은 동시로 작성되었습니다. 불행히도, 며칠마다 한 번씩 무언가가 변화를 일으키고있었습니다. 정상적으로 평화로운 응용 프로그램은 자신의 데이터베이스에 서비스 거부 공격을 시도하고, 백엔드가 생태계의 다른 부분에 문제를 일으킬만큼 충분히 과부하 될 때까지 요청으로 홍수하는 것처럼 보였습니다. Joan이 Grafana 대시보드에 제시된 메트릭스를 관찰하면서, 이 응용 프로그램이 생성한 요청의 비율이 anomaly의 시점에서 상승하기 시작했다는 것을 분명히 제안하면서, 그녀는 지구상에서이 워크로드가 어떻게 그렇게 행동 할 수 있는지 궁금해했습니다. 협력은 현장 코치와 함께 탑승 세션 동안 회사의 "영혼과 문화적 기초" 중 하나로 크게 홍보되었기 때문에 그녀는 동료 인 Tony와이 문제를 논의하는 것이 가장 좋다고 결정했습니다. "보세요, 토니, 나는이 주위에 내 머리를 포장 할 수 없습니다."그녀는 설명했다. "이 서비스는 100 명이 이미 비행 중이면 새로운 요청을 보내지 않습니다.그리고 로그에서 바로 여기를 살펴보십시오 : 100 명의 요청이 진행 중이며, 한 명은 타임 아웃 오류를 반환했습니다. “좋아요, 고맙습니다 토니, 당신은 소중한 - 최고의 언제나!”라고 결론을 내리고 코드를 고치기 위해 돌아왔다. 고무 고양이 원인에 대한 발견을 이끌어낸 관찰은 매우 간단했다: 요청은 데이터베이스 서버가 그러한 응답을 보내지 않았기 때문에 실제로 *시간 오류를 반환하지 않았습니다. 요청은 단순히 드라이버에 의해 타이밍 된 것으로 자격을 갖추고 버렸습니다.하지만 드라이버가 더 이상 특정 요청에 대한 응답을 기다리지 않는 유일한 사실은 데이터베이스가 그것을 처리하는 것을 의미하지 않습니다! 그 지식으로, 100 요청이 클라이언트 측에서 시간이 지났을 때, 응용 프로그램은 실수로 그들이 더 이상 진행되지 않는다고 생각할 수 있으며, 기꺼이 데이터베이스에 100 개의 추가 요청을 제출하여 비행 요청 (즉, 동기화)의 총 수를 200으로 증가시킬 수 있습니다. Joan's Diary of Lessons Learned, Part II에 해당되는 글 1건 수업은 계속됩니다 : 클라이언트 측 시간대는 프로그래머에게 편리하지만 서버 측 시간대와 나쁜 상호 작용을 할 수 있습니다. 손가락 규칙 : 서버 측 시간대보다 클라이언트 측 시간대가 두 배나 오래 걸리지 않는 한, 매우 좋은 이유가 없을 경우 일부 드라이버는 클라이언트 측 시간대가 서버 측 시간대보다 작다는 것을 감지하거나 심지어 서버 측 시간대가 일치하도록 수정하는 경우 경고를 발행할 수 있습니다. 예상치 못한 조건 하에서 실제로 스피크를 일으킬 수 있는 일련의 임무가 있습니다.일기 및 대시보드를 검사하는 것은 이러한 경우를 조사하는 데 도움이 되므로 데이터베이스 클러스터와 모든 클라이언트 응용 프로그램 모두에서 관찰 도구가 사용할 수 있는지 확인하세요. 클라이언트 측 타임오트가 적절하게 수정되면서 애플리케이션은 훨씬 덜 자주 그리고 더 적은 정도로 침몰했지만, 아직도 분산 시스템에서 완벽한 시민이 아니었습니다. 때때로 피해자 데이터베이스 노드를 선택하고 너무 많은 요청으로 그것을 괴롭히면서 다른 7 개 노드가 훨씬 적게 충전되어 작업 부하를 처리하는 데 도움이 될 수 있다는 사실을 무시했습니다. 다른 경우에는 조정에 의해서 예상했던 것보다 정확히 200 % 더 큰 것으로보고되었습니다. 두 개의 불규칙성이 시간이 지남에 따라 합병했을 때, 가난한 노드는 모든 요청을 처리 할 수 없었으며 공정한 부분을 포기해야했습니다. 운전자의 문서에 대한 긴 연구, 다행히 사용할 수 있었습니다. 형식과 합리적으로 최신 유지, 조안이 그 고통을 완화하는 데 도움이되었다. mdbook 첫 번째 문제는 단순히 "가장 적게 로드 된"데이터베이스 노드를 사용할 수있는 모든 데이터베이스 중에서 선택하기 위해 너무 열심히 노력한 비 기본 로드 밸런싱 정책의 잘못된 구성이었으며, 데이터베이스 자체가 때때로 업데이트 한 heuristics 및 통계를 기반으로했습니다. 불행히도이 정책은 또한 "최고의 노력"이었으며 데이터베이스에서 온 통계가 항상 합법적이라는 사실에 의존했지만 스트레스를받은 데이터베이스 노드는 시간에 업데이트 된 통계를 반환하지 않을 정도로 과부하 될 수있었습니다! 두 번째 문제는 또 다른 오류로 인해 발생했다: 과도한 추측적 리트리 정책. 데이터베이스에서 인정을받지 않고 미리 구성된 기간 동안 기다린 후, 드라이버는 성공 확률을 극대화하기 위해 추측적으로 요청을 재보냅니다. 이 메커니즘은 요청의 성공률을 높이는 데 매우 유용합니다. 그러나 원래 요청이 성공하면 추측적 요청이 헛되이 보낸다는 것을 의미합니다. 장점과 단점을 균형 잡기 위해, 추측적 리트리는 원래 요청이 실패했을 가능성이 매우 높을 경우에만 요청을 재보낼 수 있도록 구성되어야합니다. 그렇지 않으면 Joan의 경우와 마찬가지로 추측적 리트리는 전혀 성공률을 향상시키지 않고 보내진 요청 수를 두 배로 늘릴 수 있습니다. Whew, 아무것도 품질의 디버깅 세션처럼 동시에 endorphin 서두르고 도파민 히트를 제공하지 않습니다 놀라운 성공으로 끝납니다 (물론 깊은 기술적 인 책에서 치즈 스토리를 쓰는 것을 제외하고). 그 끝 당신이 지금까지 이르렀고 치즈 데이터베이스 성능 이야기를 충분히 얻을 수 없다면, 가난한 오래된 패트릭에게 무슨 일이 일어 났는지 보십시오. 그리고 당신이 이 유머 감각을 좋아한다면, Piotr의 . Editor’s note: 데이터베이스 성능의 이야기 : 패트릭의 불행한 녹색 페도라스 새로운 책을 작성하는 엔지니어링 블로그 게시물
