MySQL 고가용성 이해: 사용해야 하는 좋은 이유와 나쁜 이유

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

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

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

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

고가용성 소개

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

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

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

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

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

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

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

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

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

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

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

MySQL에서 고가용성 구성

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

다음으로, 모든 노드가 데이터베이스에 포함된 데이터의 정확한 사본을 보유할 수 있도록 이러한 노드 간에 데이터를 복제할 수 있는 서비스가 필요합니다. 마지막으로, 모든 데이터베이스 요청이 데이터베이스 노드로 균등하게 전달되도록 하여 부하를 분산하는 동시에 한 노드가 오프라인 상태일 때도 요청을 처리할 수 있는 부하 분산 장치가 필요합니다.

예를 들어, MySQL은 고가용성을 지향하는 상용 제품을 제공합니다. MySQL InnoDB 클러스터. 이 제품은 MySQL 데이터베이스 환경에서 고가용성을 보장하기 위해 널리 사용되는 방법인 MySQL 그룹 복제를 기반으로 합니다.

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

고가용성에 의존해야 하는 이유...

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

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

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

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

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

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

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

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

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

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

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

마무리

고가용성은 많은 애플리케이션에 매우 중요하며, 다른 많은 애플리케이션에도 매우 유용합니다. 올바르게 구성된 MySQL 데이터베이스는 사실상 완벽한 가용성을 제공할 수 있지만, 그렇다고 해서 기술 팀이 가용성을 당연시할 수 있는 것은 아닙니다.

유지 보수 지름길을 택하기 위해 고가용성 아키텍처를 악용하는 것은 선택 사항이 아니며, 그 위험은 언뜻 보기보다 훨씬 큽니다.

대신 시스템 관리자는 고가용성 솔루션의 기능을 손상시키지 않으면서 유지 보수 작업을 수행하기 위해 이중화 및 실시간 패치를 비롯한 검증된 대안을 모색해야 합니다.