MySQL 고가용성 이해

이 블로그 글의 AI 요약으로 바로 가기

많은 요청에 따라 이 블로그 게시물을 업데이트했습니다. 새로운 블로그 게시물은 다음 링크에서 확인하실 수 있습니다: https://tuxcare.com/ensuring-uptime-with-mysql-high-availability/

기업 환경에서 다운타임으로 인한 비용은 빠르게 증가합니다. 한 설문조사에서 응답자의 40%가 다운타임이 1시간만 발생해도 조직에 100만 달러 이상의 손실이 발생한다고 답했습니다. 데이터베이스 서비스를 지속적으로 사용할 수 있도록 보장하는 것은 분명 그만한 가치가 있습니다.

모든 형태와 규모의 이해관계자와의 관계를 원활하게 하는 것은 말할 것도 없고 조직에서 막대한 비용을 절약할 수 있습니다.

그렇다면 지속적인 가용성은 어떻게 보장할 수 있을까요? 지속적 가용성의 개념을 고가용성이라고 합니다. 이 글에서는 고가용성이란 무엇이며 MySQL 클러스터에서 이를 달성하는 방법에 대해 간략하게 설명합니다.

또한 시스템 관리자가 유지 관리 작업을 수행하기 위해 고가용성에 잘못 의존하는 고가용성의 어두운 면을 지적하고, 그렇게 하면 고가용성의 목표가 훼손되어 기업 운영이 위험에 처하는 이유를 설명합니다.

고가용성 소개

먼저 가용성에 대해 이야기해 보겠습니다. 데이터베이스와 같은 서비스를 사용자가 대부분의 시간 동안 사용할 수 없다면 서비스를 실행할 필요가 없습니다. 따라서 가용성이란 서비스에 액세스할 수 있는 정도를 의미합니다.

정상적으로 작동하는 서비스의 경우 필요할 때 사용할 수 있어야 하지만 1년에 하루나 이틀 또는 한 달에 몇 시간 정도의 다운타임도 예상할 수 있습니다.

일반적으로 이용 가능한 서비스는 많은 사용 사례 시나리오에 적합할 수 있지만, 서비스가 본질적으로 중요하거나 매우 많은 사용자가 서비스에 의존하는 경우에는 단순한 '가용성'만으로는 충분하지 않습니다.

이것이 바로 고가용성이 필요한 이유입니다. 가장 기본적인 용어로 고가용성은 유지 관리, 패치, 일반적인 오류 및 결함을 허용하는 경우에도 일반적으로 예상되는 수준보다 높은 수준, 더 구체적으로는 합의된 수준에서 가용성을 보장합니다.

고가용성이란 어떤 수준의 가용성을 의미하나요?

무엇이 고가용성에 해당하는지에 대한 합의된 정의는 없으며, 단지 특정(더 높은) 가용성 요건을 충족하기 위해 일반적으로 '가용성'으로 인정되는 수준을 초과하는 것일 뿐입니다. 실제로 조직은 운영상의 필요에 따라 고가용성 비용과 다운타임으로 인한 손실을 비교하여 필요한 가용성을 정의할 가능성이 높습니다.

필요한 가용성 수준은 백분율로 표현할 수 있습니다. 예를 들어 99.99% 또는 "99.9999%" 가용성은 연간 최대 52.60분의 다운타임을 수반하는 반면, "99.9999%" 가용성은 연간 다운타임을 31.56초로 제한합니다.

기본적으로 선택은 여러분의 몫이지만, 다시 한 번 말씀드리지만 장단점이 있습니다. 고가용성을 유지하려면 추가적인 물리적 리소스와 소프트웨어 라이선스가 필요하고 직원 리소스도 소모되므로 비용이 많이 듭니다. 하지만 운영 중단으로 인한 비용이나 불만족스러운 고객으로 인한 매출 손실의 위험을 피하기 위해 지불할 가치가 있는 대가라고 생각할 수도 있습니다.

고가용성은 실제로 어떻게 작동하나요?

고가용성 인프라의 정확한 성격은 워크로드에 따라 달라집니다. 그러나 대체로 서비스나 디바이스에 장애가 발생하더라도 워크로드가 중단되지 않도록 내결함성이 있는 경우 고가용성이 달성된다고 볼 수 있습니다. 일반적으로 이는 모든 서비스와 디바이스가 네트워크와 애플리케이션 수준에서 완전히 이중화되어 있어 단일 장애 지점이 없음을 의미합니다.

서비스에 따라 일반적으로 여기에는 여러 노드가 포함될 수 있습니다. 예를 들어 MySQL 클러스터에는 데이터가 저장되는 여러 노드가 포함됩니다. 그런 다음 여러 노드를 부하 분산 도구와 결합하여 한 노드에 장애가 발생하면 요청이 다른 노드로 간단히 전달되도록 합니다. 사용자는 성능이 약간 저하되더라도 사용 가능한 서비스에 계속 액세스할 수 있습니다.

MySQL에서 고가용성 구성

물론 고가용성 MySQL 데이터베이스로 가는 길은 MySQL 구현에 따라 달라집니다. 대체로 여러 노드가 있는 일종의 MySQL 클러스터를 만들어야 합니다. 즉, 데이터가 여러 MySQL 서버에 상주해야 합니다.

다음으로, 모든 노드가 데이터베이스에 포함된 데이터의 정확한 사본을 가지고 있도록 이러한 노드 간에 데이터를 복제할 수 있는 서비스가 필요합니다. 마지막으로, 모든 데이터베이스 요청이 데이터베이스 노드에 고르게 전달되도록 하여 부하를 분산하는 동시에 한 노드가 오프라인 상태일 경우에도 요청이 충족되도록 하는 로드 밸런서가 필요합니다.

예를 들어, MySQL은 고가용성을 목표로 하는 상용 제품인 MySQL InnoDB Cluster를 제공합니다. 이는 MySQL 데이터베이스 환경에서 고가용성을 보장하는 널리 사용되는 방식인 MySQL Group Replication을 기반으로 합니다. 구버전을 사용 중인 경우, 지속적인 보안 업데이트를 받을 수 있도록 MySQL의 지원 종료(EOL ) 상태를 확인하는 것이 매우 중요합니다.

또 다른 대안으로는 수년 동안 MySQL 고가용성을 제공해 온 Galera가 있습니다. 예를 들어 MySQL의 MariaDB 포크를 사용하는 경우 다음과 같이 할 수 있습니다, 고가용성을 위해 MariaDB 환경을 구성할 수 있습니다. 를 위해 여러 노드를 실행하는 동시에 로드 밸런싱을 위해 HAProxy에 의존할 수 있습니다. 또는 MariaDB의 자체 MaxScale 제품인.

특히 MariaDB 10.6을 사용 중이라면, 이 버전의 지원 종료( EOL ) 시점이 2026년 7월이라는 점을 알아두는 것이 좋습니다. 고가용성(HA) 설정을 계획하기 전에 MariaDB 10.6의 지원 종료가 귀하의 환경에 어떤 영향을 미치는지 미리 확인해 보시기 바랍니다.

고가용성을 사용해야 하는 좋은 이유...

장기적으로 최고의 결과를 제공하기 때문에 엔터프라이즈급 워크로드에서 고가용성 원칙을 사용하는 경우가 점점 더 많아지고 있습니다. 다음은 운영에 고가용성 설정을 고려해야 하는 여러 가지 좋은 이유 중 일부에 불과합니다:

중요한 애플리케이션. 군사 애플리케이션이나 에너지 네트워크처럼 다운타임을 감당할 수 없는 애플리케이션도 있습니다. 이러한 시나리오에서는 고가용성이 필수이므로 매우 높은 수준의 가용성을 보장할 수밖에 없지만, 위험을 평가하여 필요한 가용성 보장 수준을 정확히 결정할 수 있습니다.
노크 효과. 시스템이 워크로드의 핵심인 경우, 잠깐의 다운타임이라도 연결되고 동기화된 시스템이 연쇄적으로 다운되면서 훨씬 더 광범위한 문제로 이어질 수 있습니다. 데이터베이스와 같은 몇 가지 핵심 영역에 고가용성에 투자하는 것은 복구가 매우 어려울 수 있는 훨씬 더 큰 노크온 문제로 인한 비용을 고려할 때 그만한 가치가 있기 때문에 고려할 가치가 있습니다.
매출 손실. 고가용성은 비록 9분의 1 수준일지라도 매출 손실을 방지할 수 있습니다. 주요 온라인 소매업체의 경우, 단 몇 시간의 매출 손실과 관련 평판 손상이 합쳐지면 수익에 매우 큰 영향을 미칠 수 있습니다.
고객의 기대치 및 SLA. 고객에게 일정 수준의 가동 시간을 보장하는 서비스 수준 계약에 구속될 수 있습니다. 이 경우 고객의 워크로드를 지원하는 서비스에 필요한 수준의 가동 시간이 있는지 확인해야 하며, 고가용성을 통해 이를 보장해야 합니다. 그렇게 하지 않으면 계약이 해지되거나 계약에 따라 위약금이 부과될 수 있습니다.

이는 고가용성이 필요한 몇 가지 타당한 이유이며, 오늘날과 같이 기술이 우선시되는 세상에서는 고가용성 플랫폼 없이는 운영할 수 없는 워크로드가 많이 존재합니다.

... 그리고 고가용성에 의존해야 하는 잘못된 이유

안타깝게도 고가용성의 보급이 증가함에 따라 고가용성이 악용되기도 합니다. 고가용성은 시스템을 매우 견고하게 만들기 때문에 기술팀은 패치와 같은 시스템 관리자 작업을 수행할 때 고가용성 인프라가 단순히 시스템을 오프라인으로 전환하는 부담을 덜어줄 것이라고 생각하여 지름길을 택하고 싶은 유혹에 빠질 수 있습니다.

실제로는 금방 더 복잡해질 수 있습니다. 예를 들어 MySQL 클러스터를 생각해 보세요. 예, 시스템을 재시작하여 패치를 적용하면 고가용성 덕분에 MySQL 클러스터는 계속 실행됩니다. 하지만 패치를 위해 노드 하나를 중단했다가 재부팅하면 데이터가 백로그에 쌓이게 되고 이를 처리해야 한다는 점을 기억하세요. 이 프로세스를 완료하는 데 시간이 오래 걸릴 수 있습니다.

말할 필요도 없이 모든 데이터베이스 호스트는 동일한 데이터를 볼 수 있어야 합니다. 재동기화 중에 노드를 패치하기 위해 이미 노드를 분리한 상태에서 다른 노드가 다운되면 유효한 쿼럼이 손실될 수 있습니다. 즉, 데이터에 대한 '진실'을 보유한 서버의 수가 허용 가능한 수준 이하로 떨어지게 됩니다. 이러한 상태에서 복구하는 것은 어렵고 복잡할 수 있으며 심지어 데이터 손실로 이어질 수도 있습니다.

유지 관리를 위해 고가용성에 의존하지 마세요

고가용성은 장애가 발생하더라도 시스템을 계속 가동하고 실행하기 위해 존재합니다. 장애에 대한 이러한 고유의 보호 기능은 아무도 알아채지 못하기를 바라며 무책임한 방식으로 시스템 유지 관리를 수행하기 위해 고가용성의 견고함에 의존하는 무임승차가 아닙니다.

대신 기술팀은 단순히 고가용성 인프라가 압력을 흡수해 주기를 바라기보다는 패치 중인 시스템에 완전한 이중화를 설정하는 등 다른 솔루션에 의존해야 합니다. 또는 가능한 경우 라이브 패치에 의존하는 대신 패치를 설치하기 위해 서비스를 다시 시작할 필요가 없도록 하는 것입니다.

그럼에도 불구하고 유지 관리 작업을 위해 고가용성에 의존하는 것은 우려스러운 조짐을 보이고 있습니다. 조금만 주위를 둘러보면 패치 작업을 실행하기 위해 고가용성에 의존하도록 지시하는 공식 공급업체의 지침과 패치를 위해 한 노드를 오프라인으로 전환하는 동안 다른 노드에 문제가 생기지 않기를 바라는 사용자도 쉽게 찾을 수 있습니다.