데이터베이스 다운타임 최소화

데이터베이스를 최신 보안 업데이트로 패치하는 것은 조직이 데이터를 보호하는 데 필수적입니다. 패치가 적용되지 않은 데이터베이스 시스템은 프런트엔드 애플리케이션을 포함한 핵심 시스템 운영에 대한 익스플로잇으로 이어질 수 있습니다. 해커는 종종 데이터베이스를 포함한 호스트를 공격의 시작 플랫폼으로 악용합니다.

그렇기 때문에 조직은 스스로를 보호하기 위해 취약점 패치를 우선시합니다. 그러나 이러한 데이터베이스 취약점을 패치하려면 보안 업데이트를 적용하기 위해 가동 중단 시간을 예약해야 하며, 이는 누구도 원치 않는 비즈니스 중단으로 이어질 수 있습니다.

다행히도 시스템을 운영 중단하거나 유지 보수 기간을 예약할 필요 없이 데이터베이스를 패치할 수 있습니다. 이를 라이브 패치가라고 하는데, 이에 대해 알아보기 전에 데이터베이스 다운타임에 대해 좀 더 자세히 살펴보겠습니다.

데이터베이스 가동 시간이 중요한 이유는 무엇인가요?

기업 애플리케이션, 클라이언트 대면 플랫폼, 데이터 분석은 데이터베이스 성능, 가동 시간, 보안에 크게 의존합니다. 클라이언트 데이터가 보안 취약성에 노출되거나 복제 작업 중에 데이터베이스가 충돌하면 데이터 무결성에 영향을 미치게 됩니다. 

또한 데이터베이스 무결성 문제는 소비자 신뢰 상실은 말할 것도 없고 규정 준수 및 개인정보 보호법 준수 실패로 이어질 수 있습니다. 여기에 데이터베이스 보안 사고로 인한 혼란을 수습하는 데 따른 재정적 손실까지 더하면 어떤 기업이라도 회생 불가능한 지경에 이를 수 있습니다. 예를 들어, 2022년 미국에서 발생한 단일 데이터 유출 사고로 인한 비용은 944만 달러(IBM).

기업의 매출은 고성능의 미션 크리티컬 애플리케이션과 데이터베이스 서비스에 의존합니다. 따라서 데이터베이스 중단이나 보안 침해로 인해 사용자, 파트너십, 공급망 에코시스템에 영향을 미치면 기업은 단순한 매출 손실 이상의 손실을 입게 됩니다. 

데이터베이스 다운타임의 원인은 무엇인가요?

네트워크, 데이터베이스 및 프런트엔드 애플리케이션 내에서 사이버 범죄자가 악용하는 일반적인 취약점을 포함하여 예측 가능한 상황과 예측할 수 없는 여러 상황으로 인해 모든 시스템이 다운타임을 일으킬 수 있습니다. 

조직은 종종 데이터베이스, 해당 프런트엔드 시스템 및 관련 네트워크에 대한 중요한 유지 보수를 수행하기 위해 변경 제어 기간을 예약합니다. 대부분의 경우 업그레이드가 실패하거나, 보안 운영팀 및 데이터베이스 관리자가 예정된 유지 보수 계획에 롤백 계획이 없거나, 정전이나 시설 파손 등 자연 재해가 발생하여 계획되지 않은 데이터 다운타임이 발생할 수 있습니다. 

유지 보수 관련 다운타임

모든 IT 시스템 업그레이드는 복잡한 과정입니다. 가장 포괄적인 변경 제어 및 유지 보수 기간 절차가 있더라도 계획된 유지 보수가 예기치 않은 중단으로 바뀔 수 있습니다. 예정된 중단 중에 다양한 보안 운영, 개발 운영 및 시스템 관리자가 모든 종속성을 파악하지 못하면 예기치 않은 생산 중단으로 이어질 수 있습니다.

어떤 작업 중에 이런 일이 발생할 수 있나요?

• 데이터베이스 및 네트워크 업그레이드: 데이터베이스 패치는 조직에 중요합니다. 데이터베이스 업그레이드와 네트워크 유지 보수 루틴이 복잡해지면 예기치 않은 중단과 기술적 문제가 발생할 수 있습니다.
• 정기 유지 보수: 데이터베이스 시스템 유지 보수에는 패치 및 업그레이드의 여러 단계가 포함됩니다:
  1. 오픈 소스 데이터베이스에 보안 패치 적용하기
  2. 데이터 테이블 및 저장 프로시저 업데이트
  3. 패치를 적용하기 전에 백업 시스템으로 데이터 복제 수행하기

데이터베이스 시스템은 조직 내 대부분의 애플리케이션 스택에서 가장 아래에 위치하므로, 프론트엔드든 백엔드든 모든 시스템은 필연적으로 어딘가에서 데이터베이스에 포함된 데이터를 작업하거나 추가 또는 수정합니다. 이러한 종속성이 간접적인 경우, 데이터베이스가 중단되면 언뜻 보기에는 데이터베이스와 연결되지 않은 것처럼 보이는 시스템(API 또는 타사 게이트웨이 애플리케이션)에도 중단이 발생할 수 있습니다.

데이터베이스 패치의 복잡성으로 인해 예기치 않은 다운타임이 발생할 수 있습니다. 공급업체 패치는 때때로 데이터베이스 테이블이나 저장 프로시저에 예기치 않은 손상을 일으켜 예기치 않은 중단으로 이어지기도 합니다. SecOps 및 SQL 데이터베이스 엔지니어는 종종 개발/QA/스테이징 플랫폼 내에서 공급업체 패치와 업데이트를 테스트하여 업그레이드 소프트웨어가 예상대로 작동하는지 검증합니다. 종종 QA에서 발견되지 않은 문제가 프로덕션 시스템에서 발견되어 예기치 않은 다운타임을 유발합니다. 

이를 방지하기 위해 시스템 관리자와 SQL DBA는 계획되지 않은 프로덕션 중단을 방지하기 위해 아주 사소한 유지 보수 루틴이라도 변경 제어 창을 요청해야 합니다.

위에서 언급한 데이터베이스 업그레이드와 마찬가지로, 다른 플랫폼으로 마이그레이션을 결정할 때도 예기치 않은 중단이 발생할 수 있습니다. 단순히 클라우드로 마이그레이션하는 것은 예측할 수 없는 네트워크 지연으로 인한 불완전한 데이터 복제를 포함하여 데이터베이스 운영에 여러 가지 위험을 초래할 수 있습니다. 마이그레이션 데이터 복제를 완료하지 못하면 애플리케이션 및 데이터베이스 운영을 정상 상태로 되돌리려는 조직에 심각한 영향을 미칠 수 있습니다.

다른 유형의 예기치 않은 다운타임은 어떻게 되나요?

많은 경우, 데이터베이스 다운타임은 IT/SecOps 팀이 통제할 수 없는 이벤트의 결과로 발생할 수 있습니다:

• 정전/자연 재해: 변경 제어 기간 동안 데이터베이스 및 기타 IT 시스템에 예기치 않은 문제가 발생하는 것 외에도 지진, 홍수, 화재 등의 자연재해로 인해 정전이 발생하고 중요 시설에 대한 접근이 불가능해질 수 있습니다. 이러한 자연재해의 영향과 기간은 예측하기 어렵습니다.
• 서버 또는 스토리지 장애: 데이터베이스 시스템은 연결을 위해 네트워크, 데이터베이스 애플리케이션을 호스팅하는 서버, 실제 데이터 파일을 저장하는 스토리지 계층에 의존합니다. 이러한 계층에서 장애가 발생하면 프로덕션 중단이 발생할 수 있습니다. 스토리지 클러스터와 서버는 HA 설계와 페일오버를 지원합니다. 그러나 조직은 고객 또는 보안 규정에서 요구하는 경우 초기 설정 후에만 이러한 기능을 테스트하는 경우가 많습니다.
• 인적 오류: 데이터베이스, 네트워크, 애플리케이션, 운영 등 모든 중요 시스템은 엔지니어에 의해 유지 보수됩니다. 인적 오류는 조직이 사이버 범죄 공격에 노출되는 주요 요인입니다. 패치 및 구성 오류로 인해 취약점이 악용되어 데이터 손실 및 시스템 사용 불가로 이어질 수 있습니다.

데이터베이스 및 시스템의 가동 시간 측정

기술 업계의 조직은 가용 및 허용 가능한 다운타임 수준을 기준으로 '5-9' 척도를 사용하여 스스로를 측정하는 경우가 많습니다. 조직은 5-9 가용성을 해당 시장에서 경쟁 우위로 홍보합니다. 

또한 조직은 포괄적인 패치 관리, 보안 운영 및 전반적인 IT 관리 프로세스를 통해 99.999%의 가용성을 제공하기 위해 노력할 것입니다. 

AWS 는 허용 가능한 가동 중단 시간 수준을 보여주는 차트 분석 자료를 웹사이트에 게시했습니다:

0.001%의 다운타임이 발생한다는 것뿐만 아니라 다운타임이 언제 발생하는지 아는 것도 중요한 요소입니다. 정규 업무 시간 외의 시간이나 연휴 기간 중 판매 활동이 가장 왕성한 시기에 가동 중단이 발생하는 것은 매우 다릅니다. 그리고 수년 동안 IT 실무자들이 배운 한 가지가 있다면, 머피의 법칙에 따르면 중단은 항상 가장 예상치 못하고 원치 않을 때 발생한다는 것입니다.

패치 관리를 현대화하여 운영 중단 최소화

데이터베이스 보안 패치의 복잡성과 인적 오류의 위험을 줄이려는 조직은 TuxCare를 통해 라이브 패치를 채택하여 취약성 패치 접근 방식을 디지털 방식으로 전환했습니다. 데이터베이스용 라이브 패치 솔루션인 DBCare를 사용하면 재부팅하거나 다운타임을 예약할 필요 없이 데이터베이스 시스템에 패치를 배포할 수 있으므로 패치 관련 중단을 완전히 없앨 수 있습니다.

또한 DBCare는 온프레미스 데이터 센터에 있든 AWS Aurora 또는 관계형 데이터베이스 서비스(RDS) 제품 내에 있든 상관없이 MySQL, MariaDB 및 PostgreSQL을 지원합니다.

TuxCare 라이브 패치의 또 다른 중요한 구성 요소는 완전한 자동화를 지원하고 폐쇄 루프 에어 갭 배포 옵션을 지원한다는 점입니다. 당사의 라이브 패치 기술은 사람의 개입을 최소화하면서 최신 보안 업데이트를 제공하므로 오류가 줄어들고 취약성 노출이 감소합니다.

또한 TuxCare는 단일 배포판 또는 일부 배포판에서만 작동하는 많은 라이브 패치 대안과 달리 공유 라이브러리, 가상 머신 환경, IoT 장치 및 모든 인기 엔터프라이즈 Linux 배포판에 대한 라이브 패치를 제공합니다.

스케줄 전문가와의 대화를 통해 TuxCare의 실시간 패치 자동화가 어떻게 작동하는지에 대한 맞춤형 설명을 들을 수 있습니다.

요약

기사 이름

데이터베이스 다운타임 최소화

설명

유지 보수 기간을 예약할 필요 없이 데이터베이스를 패치 상태로 유지할 수 있습니다. 하지만 그 전에 데이터베이스 다운타임에 대해 자세히 알아보겠습니다.

작성자

존 고멀리

게시자 이름

TuxCare

게시자 로고