모니터링 시스템 안정성을 높인 InnoDB Cluster 기반 DB 고가용성 구축 사례

서비스 운영에서 모니터링은 단순한 보조 시스템이 아니다. 24시간 운영되는 서비스의 상태를 가장 먼저 확인하고 이상 징후를 알려주는 핵심 운영 시스템이다.

서버 리소스와 애플리케이션 상태, DB 상태, 로그, 알람 등 다양한 운영 데이터는 모니터링 시스템을 통해 수집·집계된다. 운영자는 이를 바탕으로 이상 징후를 사전에 파악하고, 문제가 발생하면 신속하게 대응한다. 또한 장애 이후에는 축적된 지표와 로그, 알람 이력을 분석해 원인을 파악하고 재발 방지 대책을 수립한다.

그렇다면 이처럼 중요한 모니터링 시스템 자체에 문제가 발생한다면 어떻게 될까.

서비스 장애를 제때 인지하지 못하거나 초기 대응 시점을 놓칠 수 있다. 더 나아가 장애 당시의 데이터가 정상적으로 수집되지 않는다면 원인 분석과 재발 방지 대책 마련에도 어려움이 생긴다. 결국 모니터링 시스템의 안정성은 서비스 운영 안정성과 직결된다.

특히 모니터링 시스템의 DB는 다양한 운영 지표와 이벤트, 알람 데이터를 저장하고 조회하는 핵심 역할을 담당한다. 따라서 모니터링 서비스의 안정성을 확보하기 위해서는 DB 역시 장애 상황을 고려한 고가용성(High Availability, HA) 구조로 설계할 필요가 있었다.

이에 내부에서 운영 중인 모니터링 시스템의 DB를 MySQL InnoDB Cluster 기반의 고가용성 구조로 개선했다. 이번 글에서는 InnoDB Cluster를 도입하게 된 배경과 구성 방식, 그리고 운영 과정에서 확인한 효과를 소개한다.

단일 DB 구조의 한계

초기 단계의 모니터링 시스템은 단일 DB 구조만으로도 충분할 수 있다. 구조가 단순해 구축과 운영이 비교적 쉽고 관리 부담도 적기 때문이다.

하지만 서비스 규모가 커지고 모니터링 대상이 늘어나면 단일 DB 구조는 점차 한계를 드러낸다.

가장 큰 문제는 단일 장애 지점(Single Point of Failure, SPOF)이 존재한다는 점이다. DB에 문제가 발생하면 데이터 수집과 집계가 중단되고, 이는 모니터링 시스템 전체의 장애로 이어질 수 있다. 모니터링 시스템은 장애 상황일수록 안정적으로 동작해야 하지만, 단일 DB 구조에서는 정작 장애 발생 시 제 역할을 하지 못할 가능성이 크다.

유지보수 측면에서도 부담이 따른다. DB 패치나 설정 변경, 서버 점검 등을 진행할 때마다 서비스 영향을 최소화하기 위한 별도 절차가 필요하며, 작업 가능한 시간도 제한된다. 특히 24시간 운영되는 서비스에서는 짧은 점검이나 일시적인 DB 중단도 모니터링 공백으로 이어질 수 있어 운영 안정성 확보에 어려움이 있다.

이러한 한계를 해결하기 위해 고가용성(HA) 구성을 검토했다.

고가용성이란 서버나 DB와 같은 구성 요소에 장애가 발생하더라도 다른 구성 요소가 역할을 이어받아 서비스 중단을 최소화하는 운영 방식이다. 모니터링 DB 역시 단일 장애 지점에 의존하지 않고, 장애 상황에서도 데이터 수집과 조회를 지속할 수 있는 구조가 필요했다.

InnoDB Cluster를 선택한 이유

MySQL 환경에서 고가용성을 구현하는 방법은 다양하다. 과거에는 MHA(Master High Availability)나 MMM(MySQL Multi-Master Manager)과 같은 외부 HA 도구를 활용하는 방식이 널리 사용됐다. 이러한 방식은 특정 환경에서는 여전히 활용할 수 있지만, 장애 전환 절차와 애플리케이션의 접속 경로를 운영자가 직접 관리해야 하는 경우가 많다.

모니터링 시스템처럼 장애 감지와 운영 연속성이 중요한 환경에서는 단순히 장애 발생 시 다른 DB로 전환할 수 있는지만으로는 충분하지 않았다. 장애를 얼마나 빠르게 전환할 수 있는지, 애플리케이션의 접속 구조를 얼마나 단순하게 유지할 수 있는지, 운영과 복구 절차를 얼마나 표준화할 수 있는지도 함께 고려해야 했다.

이러한 요구사항을 충족하는 방안으로 MySQL InnoDB Cluster를 선택했다.

InnoDB Cluster는 MySQL에서 공식적으로 제공하는 고가용성 솔루션이다. MySQL Server, Group Replication, MySQL Router, MySQL Shell AdminAPI를 기반으로 동작하며, 클러스터 구성과 운영, 데이터 복제, 접속 라우팅, 장애 전환을 하나의 체계 안에서 통합 관리할 수 있다.

특히 다음과 같은 점이 모니터링 시스템 운영 환경에 적합하다고 판단했다.

결과적으로 InnoDB Cluster는 모니터링 시스템에 필요한 안정성, 자동 장애 전환, 단순한 접속 구조, 운영 표준화, 확장성을 모두 충족하는 구조라고 판단했다. 현재는 이를 모니터링 DB 환경에 적용해 안정적으로 운영하고 있다.

InnoDB Cluster 기반 운영 구조

실제 운영 구조에서는 모니터링 애플리케이션이 MySQL 인스턴스에 직접 접속하지 않고, MySQL Router를 통해 DB 클러스터에 접근하도록 구성했다. Router는 클러스터의 구성 상태를 기반으로 요청을 적절한 MySQL 서버로 전달한다.

클러스터 내부에서는 Group Replication이 동작한다. Single-primary 모드에서는 하나의 Primary 노드가 쓰기 요청을 처리하고, Secondary 노드는 Primary의 데이터를 실시간으로 복제하며 장애 상황에 대비한다.

Primary 노드에 장애가 발생하면 클러스터는 가용한 Secondary 노드 가운데 하나를 새로운 Primary로 자동 승격한다. 이후 MySQL Router는 변경된 클러스터 상태를 인식해 별도의 애플리케이션 설정 변경 없이 새로운 Primary로 요청을 전달한다.

이러한 구조를 통해 특정 DB 노드에 장애가 발생하더라도 클러스터는 가용한 노드를 중심으로 서비스를 유지할 수 있다. 모니터링 애플리케이션 역시 Router를 통해 정상 노드에 지속적으로 연결되므로, 모니터링 데이터의 수집과 조회, 장애 감지 기능이 중단될 가능성을 줄일 수 있다.

구성 요소별 역할

이 구성에서 중요한 점은 각각의 요소가 독립적으로 동작하는 것이 아니라 하나의 고가용성 구조 안에서 유기적으로 연동된다는 것이다.

MySQL Server는 실제 데이터를 저장하고 처리하며, Group Replication은 노드 간 데이터를 동기화하고 클러스터 상태를 유지한다. MySQL Router는 애플리케이션의 DB 접속 경로를 단순화하고, 클러스터 상태에 따라 요청을 적절한 노드로 전달한다. 또한 MySQL Shell AdminAPI는 클러스터 구성과 상태 확인, 복구 작업 등 운영에 필요한 관리 기능을 일관된 방식으로 제공한다.

실제 운영 과정에서는 단순히 클러스터를 구축하는 데 그치지 않았다. 장애 전환이 정상적으로 수행되는지, 애플리케이션이 Router를 통해 안정적으로 연결되는지, 복구 절차가 운영 환경에 맞게 정리되어 있는지를 함께 검증했다.

아울러 클러스터와 Router의 상태를 모니터링 항목에 포함해 모니터링 시스템 자체의 안정성도 지속적으로 확인할 수 있도록 구성했다. 이는 장애 상황에서도 운영자가 시스템 상태를 빠르게 파악하고 대응할 수 있는 기반이 되고 있다.

운영 중 확인한 효과

InnoDB Cluster를 적용한 이후 가장 큰 변화는 DB 장애 상황에서도 모니터링 시스템을 보다 안정적으로 운영할 수 있게 됐다는 점이다.

기존 단일 DB 구조에서는 DB 장애가 발생하면 모니터링 시스템 전체가 영향을 받을 가능성이 컸다. 반면 클러스터를 구축한 이후에는 특정 DB 노드에 장애가 발생하더라도 다른 노드가 역할을 이어받아 서비스를 지속할 수 있는 기반을 마련했다.

운영과 유지보수 측면에서도 개선 효과를 확인할 수 있었다.

DB 점검이나 노드 단위 작업이 필요한 경우에도 전체 모니터링 시스템의 중단을 전제로 하지 않고, 클러스터 상태를 확인하면서 순차적으로 작업을 진행할 수 있었다. 물론 모든 작업을 무중단으로 수행할 수 있는 것은 아니지만, 단일 DB 구조와 비교하면 작업 범위를 훨씬 유연하게 관리할 수 있었다.

또한 데이터가 증가하면서 발생하는 조회 요청도 분산할 수 있어 대시보드 조회나 모니터링 데이터 확인 과정에서 DB 부하를 줄이는 데 도움이 됐다.

결과적으로 InnoDB Cluster 도입은 장애 대응뿐 아니라 운영 효율성과 유지보수 편의성, 확장성 측면에서도 의미 있는 개선 효과를 가져왔다.

마무리

게임 서비스는 24시간 쉬지 않고 운영된다. 사용자는 언제든 서비스를 이용할 수 있으며, 운영자는 언제든 발생할 수 있는 장애에 대비해야 한다. 이러한 환경에서 모니터링 시스템은 서비스 상태를 실시간으로 확인하고 이상 징후를 빠르게 파악하기 위한 핵심 운영 기반이 된다.

이번 작업은 InnoDB Cluster를 기반으로 모니터링 시스템의 DB를 고가용성 구조로 전환해 운영 안정성을 높이는 데 목적이 있었다. 기존 단일 DB 구조에서 발생할 수 있는 장애 위험을 줄이고, 특정 DB 노드에 문제가 발생하더라도 모니터링 체계를 안정적으로 유지할 수 있는 기반을 마련했다.

안정적인 서비스 운영은 장애가 발생하지 않는 상태만을 의미하지 않는다. 장애가 발생했을 때 이를 신속하게 인지하고, 영향을 최소화하며, 빠르게 정상 상태로 복구할 수 있는 체계를 갖추는 것 역시 중요한 운영 역량이다.

모니터링 시스템은 이러한 운영 체계의 출발점이다. 앞으로도 모니터링 환경을 지속적으로 개선하고 운영 경험을 축적해 더욱 안정적인 게임 서비스 운영을 지원할 수 있는 기반을 강화해 나갈 예정이다.