DBA, 더 이상 신권은 없다

참고: 이 엔지니어링 게시물은 DBA인 Silvia Botros가 작성했으며 원래 2016년 12월 Sysadvent 블로그에 게재되었습니다.

기업은 수년 동안 데이터베이스 관리자를 보유하고 필요로 했습니다. 데이터는 비즈니스의 가장 중요한 자산 중 하나입니다. 즉, 많은 기업이 일단 빠르게 확장할 수 있어야 하는 수준까지 성장하면 자산이 잘 관리되고 제품 요구 사항에 맞는 성능을 발휘하며 재해 발생 시 복원할 수 있는지 확인하는 사람이 필요합니다.

전통적인 의미에서 DBA의 역할은 데이터를 호스팅하는 서버에 액세스할 수 있는 유일한 사람, 새로운 기능을 위한 새 데이터베이스 클러스터를 생성하기 위해 찾아가는 사람, 새 스키마를 설계하는 사람 및 유일한 사람임을 의미합니다. 프로덕션 환경에서 데이터베이스와 관련된 문제가 발생할 때 연락할 사람입니다.

DBA는 전통적으로 고유한 역할을 수행하기 때문에 시간이 부족하기 때문에 일상적인 작업이 감당하기 어려울 때 큰 그림을 그리는 것이 더 어려워집니다. DBA 영역에서 모든 종류의 운영 작업을 위해 bash와 같은 깨지기 쉬운 도구에 의존하는 것이 일반적입니다. 새로 설치한 OS에서 새로운 DB 설정이 필요하십니까? 백업을 수행, 검증 또는 복원하시겠습니까? 파티션 또는 오래된 데이터를 회전하시겠습니까? 가장 일반적으로 사용되는 도구가 bash 스크립팅일 때 모든 것이 못처럼 보입니다. 나는 많은 독자들이 bash가 얼마나 강력한지 알려주기 위해 트윗을 준비하고 있을 것이라고 확신하지만, 내 추론을 평가할 때까지 논평을 보류하십시오.

이 모든 것이 DBA로서의 직무 설명처럼 들립니까? 작업 설명에서 서버 업그레이드, 백업 생성 및 테스트, 모니터링에 대해 자세히 설명합니까? 대부분의 일반적인 DBA 채용 공고에서는 '여러' 데이터베이스 서버를 구성 및 설정해야 하고(DBA가 직접 제작할 것으로 예상하기 때문에) (손으로 만든) 스크립트를 사용하여 데이터베이스 관리 작업을 자동화해야 한다고 말합니다.

성장하고 빠르게 변화하는 조직에서 종종 한 팀으로 구성된 팀을 위한 확장 가능한 접근 방식입니까?

저는 귀하의 업무가 백업을 수행 및 관리하거나, 데이터베이스를 생성 및 관리하거나, 쿼리를 최적화하는 것이 아님을 주장하기 위해 여기 있습니다. 업무 범위 내에서 이러한 모든 작업을 수행하지만 주요 목표는 비즈니스 데이터에 액세스하고 확장할 수 있도록 하는 것입니다. 이것은 기업이 현재의 제품을 실행하는 것뿐만 아니라 새로운 기능을 구축하고 고객에게 가치를 제공하기 위한 것입니다.

왜

내가 왜 이런 일을 하겠습니까? 전통적으로 DBA 역할을 계속 수행해야 한다는 주장이 있습니다. 바로 직업 보안이죠? 오늘날 많은 기술 조직은 다음 중 하나 이상을 수행합니다.

• 그들은 많은 소규모 팀으로 구성됩니다.
• 하나 또는 몇 개의 더 큰 서비스 대신 많은 마이크로 서비스를 생성하여 기능을 제공합니다.
• 그들은 기능 제공을 가속화하기 위해 애자일 방법론을 채택합니다.
• 그들은 하나의 리더십 아래 운영과 엔지니어링을 결합합니다.
• 설계 프로세스에서 가능한 한 빨리 운영 엔지니어를 개발자와 함께 포함합니다.
• 운영 내 DBA 사일로는 운영 팀이 자체 스택에서 프로덕션 문제를 디버그하는 데 도움이 되는 권한이 적고, 지원 없이 문제에 응답하고 수정할 수 없으며, 지원이 없는 경우 엔지니어링 팀과 더 긴밀하고 조기에 협업을 요구하는 데 솔직히 덜 신뢰할 수 있음을 의미합니다. 그들이 Tech Ops 내부에서 설교하는 것을 실천하지 않습니다.

그렇다면 이러한 사일로를 없애고 다른 사람들이 더 쉽게 디버깅하고 데이터베이스 계층을 확장하며 엔지니어가 확장 가능한 서비스를 설계할 수 있도록 하려면 어떻게 해야 할까요? 대부분의 떠오르는 상점에는 최대 한 명의 사내 DBA가 있습니다. 한 명의 DBA가 모든 설계 회의에 '출석'하고, 모든 스키마 변경을 승인하고, 계속해서 증가하는 데이터베이스 풋프린트를 위해 대기할 수 있습니까?

DBA는 더 이상 문지기나 마술사가 될 수 없습니다. DBA는 조직의 엔지니어에게 지식과 전문 지식의 원천이 될 수 있고 또 그래야 합니다. 그녀는 제공 팀이 기능을 제공할 뿐만 아니라 데이터베이스를 두려워하지 않도록 확장하고 권한을 부여하는 제품을 제공하도록 도와야 합니다. 그러나 DBA가 데이터 계층을 관리하는 일상적인 작업을 수행하면서 어떻게 이를 달성할 수 있습니까? DBA인 당신이 탁월함을 위해 자신을 설정할 수 있는 방법에는 여러 가지가 있습니다.

구성 관리

이것은 매우 중요한 것입니다. DBA는 데이터베이스 설정을 위해 bash와 같은 구식 도구를 선호하는 경향이 있습니다. 나는 이전에 이것을 언급했으며 bash 자체를 사용하는 것에 대해 아무런 반대가 없습니다. 실제로 많이 사용합니다. 그러나 클러스터 설정에 적합한 도구는 아닙니다. 특히 나머지 작업이 Bash를 사용하여 나머지 아키텍처를 관리하지 않는 경우. 운영 엔지니어도 Bash를 알고 있는 것은 사실이지만 Chef 또는 Puppet과 같은 도구를 사용하여 나머지 인프라를 관리하고 데이터베이스가 대부분 DBA가 작성한 손으로 만든 스크립트로 관리되는 경우 제공하는 데 방해가 됩니다. 긴급한 변경이 필요할 때 도움이 됩니다.

더욱이 엔지니어링 팀이 새로운 기능 'foo'에 필요한 새 클러스터 생성을 스스로 처리하고 소유하도록 돕는 것이 더 어려워집니다. 당신은 작업 완료를 위한 '차단기'가 됩니다. 회사의 구성 관리에 익숙해지는 것도 양방향 이점입니다. 인프라가 관리되는 방식에 익숙해지면 팀의 표준을 알게 되고 스택에 더 익숙해지며 궁극적으로 제품 규모에 영향을 미치는 변경 사항에 대해 협업할 수 있습니다.

엔지니어링 조직의 제품 및 인프라 전체에 맞춰진 DBA는 매우 중요합니다.

런북

이것은 기술적으로 작성해야 하는 문서의 하위 집합이지만 내 경험에 따르면 별도로 지적해야 한다고 생각하는 훨씬 더 유용한 것으로 입증되었습니다. 내가 런북을 말할 때 나는 구체적으로 DBA가 아닌 청중을 위해 작성된 문서를 말하는 것입니다. DBA로서 우리가 디버그하고 해결할 수 있는 간단한 프로덕션 DB 문제가 많이 있습니다. 우리는 그 근육 기억력을 과소평가하는 경향이 있으며 '그냥 페이지를 보내주세요'와 '일을 처리합니다'라는 패턴에 빠지게 됩니다.

귀하의 운영 팀이 귀하가 유일한 DBA인 저와 같다면 DB 관련 이벤트 페이지가 표시될 때 팀의 다른 누군가가 첫 번째 방어선임을 의미할 수 있습니다. 초기 디버깅, 데이터 수집을 수행하는 방법에 대한 몇 가지 간단한 문서는 나머지 운영 팀이 데이터베이스 계층에 익숙해지고 이를 모니터링하고 디버깅하는 방법에 더 익숙해지도록 하는 데 큰 도움이 될 수 있습니다. 그 이벤트가 여전히 DBA를 호출하는 결과를 가져오더라도 천천히, 그러나 확실히, 런북은 모든 사람이 습득한 지식을 추가할 수 있는 장소가 됩니다.

또한 관련 Runbook 섹션에 대한 링크(앵커 사용!)를 호출기로 이동하는 페이지 설명에 추가합니다. 이것은 시작할 장소를 찾기 위해 새벽 3시에 데이터베이스 호스트에 의해 호출되는 누군가에게 매우 유용합니다. 이러한 것들이 작게 보일 수 있지만 내 경험상 필요할 때 데이터베이스 계층에서 작업하는 운영 팀의 정신적 장벽을 깨는 데 많은 도움이 되었습니다.

개인적인 취향으로, 나는 이것을 내 셰프 요리책 리포지토리에 마크다운 문서로 씁니다. 이것은 pull request, review, merge 패턴에 자연스럽게 속하며 데이터베이스의 요리책 패턴의 필수적인 부분이 됩니다. 엔지니어링 팀이 자체적으로 만들기 시작하면서 새로운 데이터베이스 클러스터가 여기저기서 생겨나면서 런북은 친숙한 템플릿이 됩니다.

시계

우리는 터미널 화면을 좋아합니다. 우리는 그들을 사랑합니다. MySQL 랜드에서 가장 인기 있는 도구는 여전히 db 호스트에 직접 존재하고 이에 대한 사전 지식과 사용 방법이 필요한 터미널 도구입니다. 나는 innotop과 MySQL 셸과 같은 것에 대해 이야기하고 있습니다. 이것들은 훌륭하고 여전히 유용하지만 DBA를 위해 만들어졌습니다. "지금 복제 지연이 있습니까?"와 같은 질문에 대한 게이트키퍼가 되고 싶지 않다면 모든 팀 구성원이 현재 및 역사적으로 사용 가능하고 쉽게 소화할 수 있는 클러스터 상태를 만들려면 더 나은 도구가 필요합니다. 이 분야에 몇 가지 예가 있습니다.

오케스트레이터

우리는 읽기 전용 복제본을 사용하여 해당 로드를 기본에서 분산시킵니다. 즉, 지연이 특정 임계값에 도달하면 고객 지원 이벤트가 됩니다. 회사의 모든 사람이 주어진 시간에 클러스터에 지연이 발생하는지 여부, 해당 클러스터의 서버가 무엇인지, 호스트가 다운되었는지 여부를 쉽게 알 수 있도록 하는 것이 중요합니다. Orchestrator는 클러스터와 클러스터 상태를 브라우저 창에서 멀리 볼 수 있도록 해주기 때문에 그런 면에서 훌륭한 도구입니다.

그라파나/그라파이트

DB 계층에 대한 메트릭은 나머지 인프라에 대한 메트릭이 있는 동일한 위치에 있어야 합니다. 팀이 이러한 메트릭을 나란히 병치할 수 있는 것이 중요합니다. 그리고 모든 DB 클러스터에 대한 기록 지표를 쉽게 볼 수 있는 방법을 갖는 것이 중요합니다. 선인장이나 무닌, 또는 수년에 걸쳐 작성한 장인의 템플릿에 대한 개인적인 선호도가 있을 수 있지만 문제를 조사하는 데 사용하는 메트릭이 나머지 인프라 메트릭과 동일한 위치에 있지 않으면 장벽이 설정됩니다. 다른 바쁜 엔지니어들은 다른 곳에서 사용하는 것보다 귀하의 도구를 사용하는 경향이 줄어들 것입니다. Graphite는 최신 인프라 팀에서 메트릭을 수집하는 데 널리 사용되며 Grafana는 메트릭 및 분석을 위해 널리 사용되는 대시보드 프론트엔드입니다.

쿼리 성능

우리는 VividCortex를 사용하여 중요한 클러스터에 대한 쿼리를 추적합니다. 이 기사는 유료 서비스에 대한 광고가 아니지만 실행 중인 쿼리에 대한 배포 및 코드 변경의 영향을 검사할 수 있는 기능을 만들어야 합니다. 쿼리 성능은 로그에 대한 특별한 액세스 및 수동 크런칭이 필요하지 않은 것입니다. VividCortex가 가능성이 없다면(심지어, 정말 훌륭합니다!), 느린 로그만 캡처하여 비 DBA가 검사할 수 있도록 읽기 쉬운 웹 페이지에 넣을 수 있는 다른 제품과 오픈 소스 도구가 있습니다. 코드의 효과를 확인하십시오. 여기서 중요한 점은 데이터를 볼 수 있는 수단을 제공하면 엔지니어가 해당 데이터를 사용하고 작업을 효율적으로 유지하기 위해 최선을 다한다는 것입니다. 그러나 특별한 DBA 트릭이 아니라 해당 액세스를 사용할 수 있도록 하는 것은 귀하의 작업의 일부입니다.

호출기 피로를 이겨내십시오

많은 조직에서 데이터베이스 계층 확장을 스택 설계의 초기 필수 요소로 포함하지 않으며 그렇게 해서는 안 됩니다. 회사 초창기에는 아직 API를 사용하는 사람이 아무도 없는 경우 API 호출을 조절하는 방법에 대해 걱정할 필요가 없습니다. 그러나 몇 년 후 제품이 인기를 얻고 소수의 고객이 수천 행의 테이블에 부딪쳤던 API 호출이 이제 수백만 행의 테이블이 되었고 몇 명의 고객이 귀하의 시간대에서 매일 아침 오전 6시에 해당 API를 플러딩하는 크론 작업을 구축했습니다.

인프라를 보호하기 위해 모든 제품의 애플리케이션 계층을 변경하는 데 많은 작업이 필요하며, 그 사이에 가짜 데이터베이스 활동으로 인해 호출기 피로가 발생하도록 허용하는 것은 귀하와 나머지 운영 조직 모두에게 큰 위험이 됩니다. 계획되지 않은 볼륨으로 인해 데이터베이스 호스트가 크게 중단되는 것을 방지하는 데 사용할 수 있는 pt-kill과 같은 도구에 익숙해지십시오. 해당 도구의 사용을 알리고 해당 작업과 그 효과를 지분 보유 엔지니어링 팀에 전달하지만 직접 변경할 수 없는 것으로부터 고통을 흡수하려고 시도하고 흡수하는 것은 건강에 좋지 않으며 궁극적으로 엔지니어링 팀을 돕는 데 도움이 되지 않습니다. ' 성장통에 대처하는 방법을 배웁니다.

DBA의 작업은 다른 운영 팀과 비교하여 그녀의 역할에 고유한 방식으로 많이 있지만 이것이 아무도 접근할 수 없는 마법의 성직자가 되어야 한다는 것을 의미하지는 않습니다. 이러한 단계는 작업을 투명하게 만드는 데 큰 도움이 되지만 가장 중요한 것은 데이터베이스 호스트의 황금 정원에 대한 게이트키퍼가 아니라 조언을 제공하고 함께 일하는 엔지니어를 성장시키고 더 많은 것을 제공할 수 있는 주제 전문가로서 작업에 접근하는 것입니다. 백업 및 쿼리 튜닝보다 비즈니스에 가치가 있습니다(하지만 그것도 재미있습니다!).

계속해서 많은 것을 가르쳐주는 Sendgrid의 훌륭한 운영 팀과 이 게시물의 제목을 만들어준 자선 전공자에게 특별한 감사를 드립니다. 여기에서 DBA에 대한 더 많은 게시물을 확인하십시오.