KR101681651B1

KR101681651B1 - 데이터베이스 관리 시스템 및 방법

Info

Publication number: KR101681651B1
Application number: KR1020150100877A
Authority: KR
Inventors: 구범모
Original assignee: 주식회사 케이티
Priority date: 2015-07-16
Filing date: 2015-07-16
Publication date: 2016-12-01

Abstract

클라우드와 같은 분산 환경 내 데이터베이스 서비스 구축에 있어서, 전체 데이터베이스 서비스에 지연을 주지 않으면서 부하를 경감하며 특정 구성요소의 장애가 서비스 전체에 영향을 주지 않는 데이터베이스 관리 시스템 및 방법이 개시된다. 본 발명의 일 측면에 따른, 데이터베이스 관리 방법은, 각각 데이터베이스 서버를 포함하는 복수의 그룹을 생성하는 단계; 상기 각 그룹에 대응하는 식별 키를 생성하는 단계; 상기 식별 키 및 상기 각 그룹의 속성 정보를 포함하는 기술서를 생성하는 단계; 및 상기 기술서를 상기 데이터베이스 서버를 이용하려는 클라이언트로 배포하는 단계;를 포함한다.

Description

데이터베이스 관리 시스템 및 방법{SYSTEM AND METHOD FOR MANAGING DATABASE}

본 발명은, 데이터베이스 관리 시스템 및 방법에 관한 것으로, 보다 구체적으로, 클라우드(Cloud)와 같은 분산 환경 내 데이터베이스 서비스 구축에 있어서 데이터의 저장 용량과 처리 성능의 향상을 위해 동적 스케일 아웃(Scale-out)을 제공해 확장성과 가용성을 높일 수 있는 데이터베이스 관리 시스템 및 방법에 관한 것이다.

범용 장비에 가상화 기술을 이용한 클라우드(Cloud) 서비스가 각광받고 있다. 클라우드 서비스는 스케일러블(Scalable)하고 확장 가능한(Extensible)한 특징을 가지고 있다. 이를 이용해 비즈니스 초기에는 작은 규모로 시스템을 구축하여 운영하다가 필요시에 온-디맨드(On-demand) 형태로 가상 머신(VM:Virtual Machine)의 스케일 아웃(Scale-out)을 통해 서비스 수용 용량을 증대시킬 수 있다. 이러한 클라우드 서비스는, 그간 전용 장비를 사용하면서 초기에 많은 투자를 하는 서비스 프로바이더들에게 CAPEX(Capital Expenditure) 및 OPEX(Operating Expense) 측면에서 많은 이점을 주어 최근 각광을 받고 있다.

글로벌하게 다양한 코어 서비스 및 인프라가 클라우드 기반으로 구축되고 있으나, 데이터베이스 영역의 경우에는 기존 방식과 같이 향후의 사용량을 예측해 고용량 전용 장비를 도입하는 형태가 대부분이다. 온-디맨드 형태로, 필요시 가상 머신들을 스케일 아웃하는 방식은 데이터를 분산 저장하고 관리하여 처리하기에 많은 이슈들이 존재하기 때문이다.

대표적인 종래의 분산 환경에서의 데이터 관리 기술은, 한국등록특허 제10-1371202호와, 한국등록특허 제10-1365464호를 들 수 있다.

한국등록특허 제10-1371202호는, 멀티 메타데이터 서버 구조를 갖는 분산 파일 시스템 및 이를 이용한 데이터 처리 방법에 관한 것이다. 도 1은 이러한 멀티 메타데이터 서버 구조를 갖는 분산 파일 시스템을 나타낸 도면이다.

도 1에 도시된 분산 파일 시스템은 일반적인 분산 환경 구조로서, 클라이언트(10)는 쿼리 수행 전 메타데이터 서버(20)로 데이터의 위치 및 데이터 서버(30)의 상태에 대한 정보를 질의하여 답변을 받은 후 데이터 서버(30)로 쿼리를 전송한다. 도 1에 도시된 분산 파일 시스템은 단일 메타데이터 서버라는 단점을 극복하기 위해 다수의 메타데이터 서버(20)를 두는 구조로 데이터 서버(30)의 증가와 클라이언트(10)의 증가시 메타데이터 서버(20)로 몰리는 부하를 다수의 메타데이터 서버(20)를 통해 분산할 수 있는 장점을 갖는다. 하지만 클라이언트(10)의 증가와 데이터 서버(30)의 증가시 부하 분산을 위해 메타데이터 서버(20)의 증설은 끊임없이 함께 이루어져야 하며, 모든 메타데이터 서버(20)가 동일한 메타데이터 정보를 가진다는 측면에서 메타데이터 서버(20)의 증설만으로는 전체 서비스의 데이터 저장 용량을 증가시킬 수 없는 확장성(Scalability)의 한계가 있을 수 있다.

한국등록특허 제10-1365464호는 데이터베이스 미들웨어를 이용한 데이터 관리 시스템 및 방법에 관한 것이다. 도 2는 이러한 데이터 관리 시스템을 나타낸 도면이다.

도 2에 도시된 데이터 관리 시스템은 클라이언트(40)와 데이터베이스(60) 사이에 일종의 게이트웨이(ex, Middleware, Proxy, Router)(50)를 두어 분산 환경을 대처하는 구조이다. 이를 통해 데이터베이스(60)의 추가 및 삭제 등과 같은 형상의 변화에 대해, 클라이언트(40)는 고민할 필요가 없으며 클라이언트(40) 단의 복잡도를 줄일 수 있는 장점이 있다. 하지만 이러한 구조는 게이트웨이(50) 장애가 전체 서비스에 장애를 줄 수 있는 SOF(Single Of Failure) 구조로서 가용성(Availability)에 문제가 있을 수 있다. 또한 데이터베이스(60)의 증가와 클라이언트(40)의 증가가 게이트웨이(50)에 지속적으로 부하를 가중하는 구조라는 측면에서도 확장성(Scalability)에 한계가 있다.

기존의 분산 처리 환경에 가상화 기술이 들어간 환경을 클라우드 환경으로 정의할 수 있다. 하나의 물리적인 서버 자원 전체가 아닌, 가상화를 통해 다수의 가상 머신(VM) 기반으로 자원을 공유하는 환경에서는 가상 머신 각각의 처리 용량이 기존 전용 서버(Dedication Server)에 비해 상대적으로 낮을 수 있기 때문에 스케일 인/아웃(Scale-in/out)으로 인해 그 형상이 더 빈번하게 변화될 수 있다. 또한 가상화를 통한 서버의 물리 자원 공유 과정에서 시스템 장애는 상대적으로 높을 수 있다는 측면을 고려할 때 클라우드 기반의 데이터베이스 서비스 구현은 SOF 및 개별 가상 머신들의 장애 대응 방법까지 구조(Architecture)의 설계 단계에서부터 고민이 필요하다.

본 발명은 상기와 같은 문제점을 해결하기 위해 제안된 것으로, 클라우드와 같은 분산 환경 내 데이터베이스 서비스 구축에 있어서, 전체 데이터베이스 서비스에 지연을 주지 않으면서 부하를 경감하며 특정 구성요소의 장애가 서비스 전체에 영향을 주지 않는 데이터베이스 관리 시스템 및 방법을 제공하는데 그 목적이 있다.

상기 목적을 달성하기 위한 본 발명의 일 측면에 따른, 데이터베이스 관리 방법은, 각각 데이터베이스 서버를 포함하는 복수의 그룹을 생성하는 단계; 상기 각 그룹에 대응하는 식별 키를 생성하는 단계; 상기 식별 키 및 상기 각 그룹의 속성 정보를 포함하는 기술서를 생성하는 단계; 및 상기 기술서를 상기 데이터베이스 서버를 이용하려는 클라이언트로 배포하는 단계;를 포함한다.

상기 식별 키는, 범위 값으로서, 데이터베이스 서버에 저장될 실제 데이터의 해쉬 값이고, 상기 속성 정보는, 상기 각 그룹에 속하는 데이터베이스 서버의 형상 정보 및 상태 정보를 포함할 수 있다.

상기 방법은, 상기 각 그룹 중 적어도 하나의 그룹에서 데이터베이스 서버의 정보 변경을 감지하는 단계; 및 상기 감지된 정보 변경을 반영하여 상기 기술서를 갱신한 후 상기 클라이언트로 배포하는 단계;를 더 포함할 수 있다.

상기 방법은, 신규 데이터베이스 서버를 포함하는 신규 그룹을 추가하는 단계; 및 상기 추가된 신규 그룹의 속성 정보를 반영하여 기술서를 갱신한 후 상기 클라이언트로 배포하는 단계;를 더 포함할 수 있다.

상기 방법은, 상기 그룹 중 분산 대상 그룹에 대한 신규 데이터베이스 서버를 생성하고, 상기 분산 대상 그룹의 데이터를 상기 신규 데이터베이스 서버로 복제하는 단계; 상기 분산 대상 그룹의 데이터베이스 서버에 대한 쓰기 금지를 포함하도록 상기 기술서를 갱신하여 상기 클라이언트로 배포하는 단계; 상기 신규 데이터베이스 서버를 신규 그룹으로 독립시키고, 상기 범위 값인 상기 식별 키를 분리하는 단계; 및 상기 쓰기 금지의 해제 및 상기 신규 그룹의 속성 정보를 반영하여 상기 기술서를 갱신한 후 상기 클라이언트로 배포하는 단계;를 더 포함할 수 있다.

상기 방법은, 상기 분산 대상 그룹과 상기 신규 그룹에 대해 자신의 그룹에 포함되지 않는 데이터를 삭제하도록 하는 단계;를 더 포함할 수 있다.

상기 삭제하도록 하는 단계는, 상기 식별 키의 범위에 해당하지 않는 해쉬 값을 갖는 데이터를 삭제할 수 있다.

상기 목적을 달성하기 위한 본 발명의 다른 측면에 따른, 각각 데이터베이스 서버를 포함하는 복수의 그룹을 관리하는 데이터베이스 관리 시스템은, 상기 각 그룹에 대응하는 식별 키를 생성하는 식별 키 관리 모듈; 상기 각 그룹에 포함된 데이터베이스 서버를 감시하고 관리하는 데이터베이스 감시 모듈; 및 상기 각 그룹의 속성 정보를 포함하는 기술서를 생성하여 상기 데이터베이스 서버를 이용하려는 클라이언트로 배포하는 기술서 관리 모듈;을 포함한다.

상기 데이터베이스 감시 모듈은, 상기 각 그룹 중 적어도 하나의 그룹에서 데이터베이스 서버의 정보 변경을 감지하고, 상기 기술서 관리 모듈은, 상기 감지된 정보 변경을 반영하여 상기 기술서를 갱신한 후 상기 클라이언트로 배포할 수 있다.

상기 데이터베이스 감시 모듈은, 신규 데이터베이스 서버를 포함하는 신규 그룹을 추가하고, 상기 기술서 관리 모듈은, 상기 추가된 신규 그룹의 속성 정보를 반영하여 기술서를 갱신한 후 상기 클라이언트로 배포할 수 있다.

상기 데이터베이스 감시 모듈은, 상기 그룹 중 분산 대상 그룹의 데이터를 신규 데이터베이스 서버에 복제하고, 해당 신규 데이터베이스 서버를 신규 그룹으로 독립시키며, 상기 식별 키 관리 모듈은, 상기 범위 값인 상기 식별 키를 상기 신규 그룹에 대응하여 분리하고, 상기 기술서 관리 모듈은, 상기 식별 키를 분리하는 동안, 상기 분산 대상 그룹에 대한 쓰기 금지를 위한 기술서를 배포하고, 상기 식별 키의 분리 완료 후 상기 쓰기 금지의 해제 및 상기 신규 그룹의 속성 정보를 반영한 기술서를 상기 클라이언트로 배포할 수 있다.

상기 데이터베이스 감시 모듈은, 상기 분산 대상 그룹과 상기 신규 그룹에 대해 자신의 그룹에 포함되지 않는 데이터를 삭제할 수 있고, 상기 삭제는, 상기 식별 키의 범위에 해당하지 않는 해쉬 값을 갖는 데이터를 삭제하는 것일 수 있다.

본 발명은 데이터베이스 서버의 저장 용량과 처리 성능 증가를 위해 빈번하게 일어나는 스케일 아웃을 동적, 실시간으로 진행할 수 있어 전체 데이터베이스 서비스에 지연, 정지와 같은 영향을 주지 않는다.

또한, 본 발명은 데이터베이스 서버나 클라이언트 등에 부하가 가중시키지 않고, 특정 구성요소의 장애가 전체 서비스의 장애로 이어지지 않는다.

또한, 본 발명은, 데이터베이스의 스케일 아웃시 기존 데이터베이스 서버와 신규 데이터베이스 서버 간 데이터 이송(migration)이 이루어져 데이터베이스 서버 간의 밸런스를 맞춰준다. 이를 통해 기존 데이터베이스 서버에 저장되어 있던 데이터는 신규 데이터베이스 서버로 분산 저장되며, 기존 데이터베이스 서버에 몰렸던 데이터의 요청은 신규 데이터베이스 서버로 분산되어 데이터 처리의 부하를 줄일 수 있다.

또한, 본 발명에 따르면, 서비스 프로바이더들은 데이터베이스 서비스를 제공함에 있어서 클라우드 구축 목적에 맞게 최초에는 최소의 가상 머신만으로 데이터베이스 서비스를 제공해 CAPEX(Capital Expenditure) 및 OPEX(Operating Expense)를 줄일 수 있고, 서비스 운용 과정에서 필요시 스케일 아웃(Scale-out)을 통해 저장 용량 및 처리 용량을 증가시켜 실시간 대처가 가능하다.

도 1은 종래 기술에 따른 멀티 메타데이터 서버 구조를 갖는 분산 파일 시스템을 나타낸 도면이다.
도 2는 종래 기술에 따른 미들웨어를 이용한 데이터 관리 시스템을 나타낸 도면이다.
도 3은 본 발명의 일 실시예에 따른 데이터베이스 관리 시스템의 구성을 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 데이터베이스 매니저의 구성을 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 식별 키로서 사용되는 해쉬 값의 영역을 나타낸 도면이다.
도 6은 데이터베이스 서버의 감시, 추가 및 삭제의 예를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른 기술서의 변경을 나타낸 도면이다.
도 8은 본 발명의 일 실시예에 따른 클라이언트에서 쿼리를 처리하는 과정을 나타낸 도면이다.
도 9는 본 발명의 일 실시예에 따른 특정 서버에 부하가 집중될시 스케일 아웃을 통해 신규 서버 추가 및 데이터 마이그레이션한 경우를 나타낸 도면이다.
도 10 내지 도 16은 본 발명의 일 실시예에 따른 데이터베이스 서버의 스케일 아웃 과정을 설명하는 도면이다.

상술한 목적, 특징 및 장점은 첨부된 도면과 관련한 다음의 상세한 설명을 통하여 보다 분명해 질 것이며, 그에 따라 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명의 기술적 사상을 용이하게 실시할 수 있을 것이다. 또한, 본 발명을 설명함에 있어서 본 발명과 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에 그 상세한 설명을 생략하기로 한다. 이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 일 실시예를 상세히 설명하기로 한다.

도 3은 본 발명의 일 실시예에 따른 데이터베이스 관리 시스템의 구성을 나타낸 도면이다.

도 3을 참조하면, 본 실시예에 따른 데이터베이스 관리 시스템은, 데이터베이스 매니저(310), 데이터베이스 서버들의 집합(330-1,..., 330-N-1, 330-N) 및 클라이언트(350)들을 포함한다.

데이터베이스 매니저(310), 데이터베이스 서버들(330-1,..., 330-N-1, 330-N) 및 클라이언트(350)는, 물리적 장비를 가상화한 것으로서, 하이퍼바이저 상에서 적어도 하나 이상의 가상 머신(VM)으로 구현될 수 있다. 이러한 구성요소들은, 프로세서, 메모리 및 네트워크 인터페이스를 포함할 수 있다. 프로세서는 중앙 처리 유닛(central processing unit, CPU)이나 기타 칩셋, 마이크로프로세서 등으로 구현될 수 있으며, 메모리는 동적 랜덤 액세스 메모리(dynamic random access memory, DRAM), 램버스 DRAM(rambus DRAM, RDRAM), 동기식 DRAM(synchronous DRAM, SDRAM), 정적 RAM(static RAM, SRAM) 등의 RAM과 같은 매체로 구현될 수 있다. 네트워크 인터페이스는 프로세서 및/또는 메모리가 네트워크에 접근할 수 있도록 한다. 하이퍼바이저는 가상 머신이 하나 이상의 CPU 코어를 공유하게 하기 위해 가상 머신을 스케줄링하며, 가상 네트워크 인터페이스를 통해 입출력되는 패킷을 물리 네트워크 인터페이스를 통해 처리하는 역할을 한다. 가상 머신은 하이퍼바이저가 가상화시킨 장비이며, 가상 프로세서, 가상 메모리, 가상 네트워크 인터페이스 등으로 구성될 수 있다.

데이터베이스 서버들의 집합(330-1,..., 330-N-1, 330-N)은 복수의 그룹으로 나누어진다. 각 그룹(330-1,..., 330-N-1, 330-N)은, 복수의 데이터베이스 서버들을 포함하는데, 복수의 데이터베이스 서버 중 하나는 마스터이고 나머지는 슬레이브이다. 슬레이브 데이터베이스는 적어도 하나 이상이 존재한다. 그룹(330-1,..., 330-N-1, 330-N) 내의 마스터 데이터베이스 서버와 슬레이브 데이터베이스 서버는 저장 데이터가 동기화된다. 그룹(330-1,..., 330-N-1, 330-N) 내에서 마스터 데이터베이스 서버의 장애 발생시 슬레이브 데이터베이스 서버 중에 하나가 마스터 데이터베이스 서버의 역할을 수행한다. 이하에서는 데이터베이스 서버들의 각 집합을 데이터베이스 서버로 혼용하여 설명할 수 있다. 예를 들어, 그룹 1(330-1)의 데이터베이스 서버의 집합을, 데이터베이스 서버(330-1)로 설명할 수 있다.

데이터베이스 매니저(310)는, 클라이언트(350)들의 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 접속을 관리하고, 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 추가 및 삭제를 제어하며, 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 상태를 주기적으로 감시하고 장애 발생 여부를 판단한다. 도 4는 본 발명의 일 실시예에 따른 데이터베이스 매니저의 구성을 나타낸 도면이다. 도 4를 참조하면, 데이터베이스 매니저(310)는, 식별 키 관리 모듈(410), 데이터베이스 감시 모듈(430) 및 기술서 관리 모듈(450)을 포함한다. 데이터베이스 매니저(310)는, 장애 발생시 클라이언트(350)와 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 서비스에 영향을 주지 않지만, 상태 감시 및 판단 기능이 중단될 수 있기에 장애 상황을 대비해 구성 환경에 따라 다수를 운영(1+1, N+1, 마스터-슬레이브 등)할 수 있다.

상기 식별 키 관리 모듈(410)은 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 식별 키를 정의한다. 여기서 식별 키는 범위 값으로서 식별 키들의 전체 범위는 순환 구조로서 링을 형성할 수 있다. 그러나 여기에 제한되지 않는다. 식별 키는 실제 저장되는 데이터로부터 산출될 수 있는 값으로서, 예컨대 해쉬 값의 영역일 수 있다. 도 5는 본 발명의 일 실시예에 따른 식별 키로서 사용되는 해쉬 값의 영역을 나타낸 도면이다. 도 5의 예에서 해쉬 값의 영역은 4개의 영역으로 나누어진다. 각 영역은 각 데이터베이스 서버(330-1,..., 330-N-1, 330-N)에 대응한다. 즉, 식별 키 0은 해쉬 값이 0x00000000 이상이면서 0x40000000 미만의 값이다. 그리고 식별 키 1은 해쉬 값이 0x40000000 이상이면서 0x80000000 미만의 값이며, 식별 키 2는 해쉬 값이 0x80000000 이상이면서 0xB0000000 미만의 값이고, 식별 키 3은 해쉬 값이 0xB0000000 이상이면서 0xFFFFFFFF 이하의 값이다. 데이터베이스 서버의 스케일 아웃시 상기 식별 키의 범위를 나누어 신규 데이터베이스 서버에 할당할 수 있다.

데이터베이스 감시 모듈(430)은 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 삭제, 추가, 관리의 권한을 가지고, 또한 모든 데이터베이스 서버(330-1,..., 330-N-1, 330-N)의 상태를 주기적으로 감시하고 장애 여부를 판단한다. 도 6은 데이터베이스 서버의 감시, 추가 및 삭제의 예를 나타낸 도면이다. 도 6을 참조하면, 데이터베이스 서버들의 각 그룹(330-1,..., 330-N-1, 330-N) 내에는 기본적으로 하나의 마스터 데이터베이스 서버가 위치하게 되며, 마스터 데이터베이스 서버의 장애를 대비하여 슬레이브 데이터베이스 서버를 하나 이상 추가한다. 슬레이브 데이터베이스 서버는 마스터 데이터베이스 서버로부터 데이터를 복제하여 저장하고 또한 클라이언트로부터의 읽기(read) 요청을 처리할 수 있다. 또는 슬레이브 데이터베이스 서버는 정책적으로 읽기 요청을 허용하지 않고 단순히 복제만을 수행해 마스터 데이터베이스 서버의 장애 발생시 마스터 데이터베이스 서버의 역할을 수행하도록 할 수 있다. 이러한 데이터베이스 서버의 상태 감시, 추가/삭제/관리 등의 기능을 데이터베이스 감시 모듈(430)이 수행한다.

데이터베이스 감시 모듈(430)은, 데이터베이스 서버들의 상태 감시 중에, 도 6에 도시된 바와 같이, 특정 그룹, 예컨대 그룹 0 내의 마스터 데이터베이스 서버의 상태가 감지되지 않는다면 이를 장애로 판단하고, 해당 그룹 내에 위치한 슬레이브 데이터베이스 서버를 마스터 데이터베이스로 승격시키는 역할 변경 명령을 해당 슬레이브 데이터베이스 서버로 전송한다. 데이터베이스 감시 모듈(430)은 장애로부터 복구된 기존의 마스터 데이터베이스 서버의 상태가 감지되면 해당 기존의 마스터 데이터베이스 서버를 신규로 마스터 데이터베이스 서버로 된 데이터베이스 서버의 슬레이브로 그 역할을 수행하도록 역할 변경 명령을 전송한다. 즉, 데이터베이스 감시 모듈(430)은 데이터베이스 서버 간 역할(role)을 관리한다.

기술서 관리 모듈(450)은, 데이터베이스 서버들의 각 그룹(330-1,..., 330-N-1, 330-N) 내에 배치된 데이터베이스 서버들에 대한 속성 정보, 즉 형상(IP 주소 및 포트 등) 및 상태 정보(마스터/슬레이브, normal/dead 등) 그리고 각 그룹의 식별 키를 담고 있는 기술서를 생성 및 관리하고, 정해진 시간마다 모든 데이터베이스 서버들의 상태 정보(예컨대, 신규 데이터베이스 서버의 추가, 기존 데이터베이스 서버의 장애, 데이터베이스 서버의 역할 등)가 확인되면, 현재의 상태를 상기 기술서에 실시간 반영한다. 기술서의 예는 다음과 같다.

기술서 관리 모듈(450)은 클라이언트(350)에 위치한 프록시 모듈(351)들에게 상기 기술서를 전송한다. 또한, 기술서 관리 모듈(450)은 상기 기술서에 변경이 있을 때 실시간으로 그 변경된 기술서를 클라이언트(350)에 위치한 프록시 모듈(351)들에게 전송한다. 따라서 클라이언트(350)에 위치한 프록시 모듈(351)은 전체 데이터베이스 서버들의 형상 및 상태를 감시할 필요없이 본연의 역할만을 수행하면 된다.

도 7은 본 발명의 일 실시예에 따른 기술서의 변경을 나타낸 도면이다. 도 7의 (a)는 변경 전의 기술서이고, 도 7의 (b)는 변경 후의 기술서이다. 도 7을 참조하면, 식별 키의 범위가 0x00000000 ~ 0x40000000인 그룹 0의 마스터 데이터베이스 서버가 정상 상태(nomal)였다가 장애가 발생하는 경우, 도 7의 (b)에 도시된 바와 같이, 기술서에는 해당 마스터 데이터베이스 서버의 역할은 삭제되고 상태는 (dead)로 갱신된다. 그리고 슬레이브 역할이던 데이터베이스 서버가 마스터 데이터베이스 서버의 역할로 변경된다. 또한 식별 키의 범위가 0xB0000000 ~ 0xFFFFFFFF인 그룹 3은 마스터 데이터베이스 서버만 존재했는데 새로운 슬레이브 데이터베이스 서버가 추가된다. 따라서 도 7의 (b)에 도시된 바와 같이, 기술서에는 해당 그룹 3의 슬레이브 데이터베이스 서버의 형상 정보 및 상태 정보가 반영된다.

상기 기술서의 실시간 전송 방법은 다양하게 있을 수 있지만 서버들의 성능, 네트워크의 부하 및 서버들의 개수를 고려하여 필요에 따라서는 구독(Subscribe)과 알림(Noti)를 통해 전송하거나, 또는 푸시 형태로 전송하거나, 또는 클라인트(350)의 프록시 모듈(351)이 주기적으로 변화를 감지(Polling)하는 형태로 구현이 가능하다.

프록시 모듈(351)은, 상기 데이터베이스 매니저(310)로부터 전송되어 수신된 상기 기술서를 이용하여, 데이터를 저장할 또는 데이터를 읽을 데이터베이스 서버(330-1,..., 330-N-1, 330-N)를 선택하고, 그 선택한 데이터베이스 서버(330-1,..., 330-N-1, 330-N)에 데이터를 쓰거나(write) 또는 데이터베이스 서버(330-1,..., 330-N-1, 330-N)로부터 데이터를 읽는다(read). 이때 클라이언트(350)는 상술한 바와 같이 프록시 모듈(351)을 포함하고, 프록시 모듈(351)은 다음과 같은 역할을 수행한다.

프록시 모듈(351)은 데이터베이스 매니저(310)와의 접속 관리를 수행하고, 또한 데이터베이스 매니저(310)로부터 상기 기술서를 수신하며, 또한 그 기술서에 포함되어 있는 모든 데이터베이스 서버들과의 접속 관리를 수행한다. 접속 관리라 하면 최초 접속과 접속 실패, 및 이상 상태가 감지되면 주기적 또는 동적(1초, 3초, 5초, 10초 등)으로 재접속을 시도하는 것 등을 의미한다. 프록시 모듈(351)은 데이터베이스 매니저(310)로부터 변경된 상기 기술서를 수신하면, 새롭게 추가된 데이터베이스 서버들과, 삭제된 데이터베이스 서버들을 확인하여 접속 관리 대상에 반영한다.

프록시 모듈(351)은, 클라이언트(350)의 쿼리를 분석하고 그 쿼리를 적절한 데이터베이스 서버(330-1,..., 330-N-1, 330-N)로 전송한다. 예를 들어 도 8을 참조하여 설명한다. 도 8은 본 발명의 일 실시예에 따른 클라이언트에서 쿼리를 처리하는 과정을 나타낸 도면이다.

도 8에서 클라이언트(350)에서는 2개의 쿼리가 발생한다. 먼저 프록시 모듈(351)은 쿼리 내 데이터에 대해 해쉬 알고리즘(Hash Algorithm)을 적용하여 해쉬 값을 계산한다. 그리고 프록시 모듈(351)은 그 계산한 해쉬 값이 상기 기술서 내의 어느 식별 키, 즉 어느 데이터베이스 서버의 그룹(330-1,..., 330-N-1, 330-N)에 속하는지 확인한다.

도 8에서 쓰기 동작 쿼리(Write Operation Query) (1)은, 데이터로서 'user_phone_num#A2413'이 포함되어 있고, 그 데이터 'user_phone_num#A2413'에 대한 해쉬 값은 '0xB3F7B3CA'이다. 그 해쉬 값 '0xB3F7B3CA'는 그룹 3의 식별 키 범위에 속한다. 따라서, 상기 데이터 'user_phone_num#A2413'은 그룹 3 영역에 저장되어야 하는 값이고, 프록시 모듈(351)은 상기 쓰기 동작 쿼리 (1)을 해당 그룹 3의 마스터 데이터베이스 서버로 전송 후 처리 결과를 클라리언트(350)에게 알려준다.

도 8에서 읽기 동작 쿼리(Read Operation Query) (2)는, 데이터로서 'user_address#A23'이 포함되어 있고 그 데이터 'user_address#A23'에 대한 해쉬 값은 '0x1360183C'이다. 그 해쉬 값은 '0x1360183C'는 그룹 0의 식별 키 범위에 속한다. 따라서, 프록시 모듈(351)은 상기 읽기 동작 쿼리를 그룹 0의 데이터베이스 서버로 전송한다. 이때 읽기(Read)의 경우에는 해당 그룹 0 영역에 위치한 마스터 데이터베이스 서버와 슬레이브 데이터베이스 서버 모두에게 쿼리를 전송할 수 있다. 하지만 기술서에는 그룹 0의 슬레이브 데이터베이스 서버의 상태가 'dead'로서 장애로 분류하고 있기 때문에, 마스터 데이터베이스 서버로 해당 읽기 동작 쿼리를 전달하고, 처리 결과를 클라이언트(350)에게 알려준다.

스케일 아웃

위에서 설명한 바와 같이, 해쉬 기반의 데이터 저장을 통해 전체 데이터베이스 서버들의 그룹(330-1,..., 330-N-1, 330-N)에 부하가 분산되지만 상황에 따라서는 특정 그룹에 데이터 저장 용량의 증가 또는 처리 용량이 집중될 수 있다. 도 9는 본 발명의 일 실시예에 따른 특정 서버에 부하가 집중될 시 스케일 아웃을 통해 신규 서버 추가 및 데이터 마이그레이션한 경우를 나타낸 도면이다. 도 9의 (a)에 도시된 바와 같이, 특정 마스터 데이터베이스 서버인 DB#3에 데이터 저장 용량의 증가 또는 처리 용량이 집중되는 경우, 도 9의 (b)에 도시된 바와 같이, 신규 마스터 데이터베이스 서버(DB#3-2)를 추가한 후 기존에 마스터 데이터베이스 서버(DB#3-1)에 있던 데이터 일부를 신규 마스터 데이터베이스 서버(DB#3-2)로 마이그레이션하여, 데이터 저장 공간 및 처리 용량을 증가시켜 부하 분산 효과를 가져올 수 있다. 이 과정에서 추가된 데이터베이스 서버(DB#3-2)로 인해 변경된 데이터베이스 서버의 형상 정보와 데이터 마이그레이션으로 인해 변경된 데이터의 저장 위치 정보는 클라이언트로 전달된다.

이러한 데이터베이스 서버의 그룹의 분리와 스케일 아웃을 통한 신규 데이터베이스 서버의 추가는 데이터베이스를 사용하는 클라이언트(350)의 증가로 전 영역에 걸쳐 데이터 저장 용량 및 처리 용량이 증가 한다면 모든 그룹에서 수행될 수 있다. 구체적으로, 예를 들어 설명하면 다음과 같다.

도 10 내지 도 16은 본 발명의 일 실시예에 따른 데이터베이스 서버의 스케일 아웃 과정을 설명하는 도면이다.

도 10을 참조하면, 데이터베이스 서버들의 그룹은 그룹 0과 그룹 1의 두 개로 구성되어 있고, 이들의 식별 키도 두 개로 구성되어 있다. 즉 식별 키가 0x00000000 이상이면서 0x80000000 미만의 값이면 그룹 0을 지시하고, 식별 키가 0x80000000 이상이면서 0xFFFFFFFF 이하의 값이면 그룹 1을 지시한다. 데이터베이스 매니저(310)의 기술서 관리 모듈(450)은 데이터베이스 서버들에 대한 형상(IP 주소 및 포트 등) 및 상태 정보(마스터/슬레이브, normal/dead 등) 그리고 각 그룹의 식별 키를 담고 있는 기술서를 클라이언트(350)에 배포한다. 클라이언트(350)는 상기 기술서를 이용하여 데이터를 특정 그룹의 데이터베이스 서버에 쓰기하거나, 특정 그룹의 데이터베이스 서버로부터 데이터를 읽기한다. 이때 그룹 0과 그룹 1 모두 가용성이 부족하다고 판단한 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 해당 그룹 0, 1의 데이터베이스 서버와 동일한 형상을 갖고 있는 이미지로 가상 머신(1001, 1002), 즉 새로운 데이터베이스 서버를 생성하여 스케일 아웃한다(①).

도 11을 참조하면, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 새로 생성한 데이터베이스 서버(1001, 1002)를 각각 그룹 0과 그룹 1의 슬레이브 데이터베이스 서버로 지정한다(②). 그리고 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 그룹 0과 그룹 1의 각 마스터 데이터베이스 서버와 새로 생성한 각 슬레이브 데이터베이스 서버(1001, 1002) 간 데이터 복제(replication)를 명령한다(③).

도 12를 참조하면, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 복제 완료 후 기존 데이터베이스 서버들에 대해 잠시 동안 쓰기 금지(write block)를 행한다. 구체적으로, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은, 기술서 관리 모듈(450)로 각 그룹의 마스터 데이터베이스 서버의 상태 정보를 'block'으로 변경할 것을 요청하고, 기술서 관리 모듈(450)은 기술서에 각 그룹의 마스터 데이터베이스 서버의 상태 정보를 'block'으로 변경한 후 해당 기술서를 클라이언트(350)에 위치한 프록시 모듈(351)들에게 전송한다(④). 이는 클라이언트(350)로부터의 데이터 쓰기가 지속적으로 발생하는 환경에서 마스터 데이터베이스 서버로부터 신규 슬레이브 데이터베이스 서버(1001, 1002)로의 데이터 복제 과정에서 데이터 불일치가 발생할 수 있기에, 짧은 시간 동안(1~2 초 이내) 쓰기 동작을 금지하는 것이다. 그러나 망부하 상황에 따라, 또는 최한시에 데이터 복제를 하는 경우, 이 과정을 생략할 수도 있다.

도 13을 참조하면, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은, 상기 쓰기 금지 동안, 상기 새로 생성한 데이터베이스 서버(1001, 1002), 즉 각 그룹마다 새로 생성하여 슬레이브로 지정한 데이터베이스 서버를 마스터 데이터베이스 서버로 승격시킨다(⑤). 이때, 해당 승격된 마스터 데이터베이스 서버의 정보는 클라이언트(350)에서는 보이지 않는다. 즉 데이터베이스 매니저(310)는 아직 기술서에 해당 승격된 마스터 데이터베이스 서버의 정보를 갱신하지 않았기 때문이다.

도 14를 참조하면, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 승격된 마스터 데이터베이스 서버(1001, 1002)를 별도의 그룹으로 분리한다. 이때, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 식별 키 관리 모듈(410)로 식별 키 분리 요청을 전송하고, 식별 키 관리 모듈(410)은 기존 그룹 0과 그룹 1의 각 식별 키 영역을 반으로 분리해 전체 식별 키 영역을 2개에서 4개로 만든다. 도 14에 도시된 바와 같이, 그룹은 2개에서 4개로 증가하고, 식별 키 영역도 2개에서 4개로 변경된다. 데이터베이스 매니저(310)의 기술서 관리 모듈(450)은 추가된 그룹의 데이터베이스(1001, 1002)들에 대한 형상(IP 주소 및 포트 등) 및 상태 정보(마스터/슬레이브, normal/dead 등) 그리고 식별 키를 기술서에 추가하여 갱신한다(⑥).

이어서, 도 15를 참조하면, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 쓰기 금지를 해제한다. 구체적으로, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은, 기술서 관리 모듈(450)로 각 그룹의 마스터 데이터베이스 서버의 상태 정보를 'normal'으로 변경할 것을 요청하고, 기술서 관리 모듈(450)은 기술서에 각 그룹의 마스터 데이터베이스 서버의 상태 정보를 'normal'으로 변경한 후 해당 갱신된 기술서를 클라이언트(350)로 전송한다(⑦). 갱신된 기술서를 수신한 클라이언트(350)는 그 기술서를 바탕으로 쓰기/읽기 동작을 수행한다.

다음으로, 도 16을 참조하면, 데이터베이스 매니저(310)의 데이터베이스 감시 모듈(430)은 백그라운드 작업을 통해 자신의 그룹 영역에 해당하지 않는 데이터 삭제를 각 그룹으로 요청하여 데이터 리밸런싱을 완료한다(⑧). 구체적으로, 그룹 0은, 기존 0x00000000 이상에서 0x80000000 미만의 데이터 중에서 0x40000000 이상의 데이터를 삭제 처리한다. 그룹 1은, 그룹 0으로부터 분리되었으므로, 기존 0x00000000 이상에서 0x80000000 미만의 데이터 중에서 0x40000000 미만의 데이터를 삭제 처리한다. 그룹 2는, 기존 0x80000000 이상에서 0xFFFFFFFF 이하의 데이터 중에서 0xB0000000 이상의 데이터를 삭제 처리한다. 그룹 3은, 그룹 2로부터 분리되었으므로, 기존 0x80000000 이상에서 0xFFFFFFFF 이하의 데이터 중에서 0xB0000000 미만의 데이터를 삭제 처리한다.

이상과 같은 실시예를 통해 본 실시예에 따른 데이터 관리 시스템은, 데이터베이스 서버의 저장 용량과 처리 성능 증가를 위해 빈번하게 일어나는 스케일 아웃을 동적, 실시간으로 진행할 수 있어 전체 데이터베이스 서비스에 지연, 정지와 같은 영향을 주지 않는다.

또한, 본 실시예에 따른 데이터 관리 시스템은, 데이터베이스 서버나 클라이언트 등에 부하가 가중시키지 않고, 특정 구성요소의 장애가 전체 서비스의 장애로 이어지지 않는다.

또한, 본 실시예에 따른 데이터 관리 시스템은, 데이터베이스의 스케일 아웃시 기존 데이터베이스 서버와 신규 데이터베이스 서버 간 데이터 이송(migration)이 이루어져 데이터베이스 서버 간의 밸런스를 맞춰준다. 이를 통해 기존 데이터베이스 서버에 저장되어 있던 데이터는 신규 데이터베이스 서버로 분산 저장되며, 기존 데이터베이스 서버에 몰렸던 데이터의 요청은 신규 데이터베이스 서버로 분산되어 데이터 처리의 부하를 줄일 수 있다.

또한, 본 실시예에 따른 데이터 관리 시스템은, 서비스 프로바이더들은 데이터베이스 서비스를 제공함에 있어서 클라우드 구축 목적에 맞게 최초에는 최소의 가상 머신만으로 데이터베이스 서비스를 제공해 CAPEX(Capital Expenditure) 및 OPEX(Operating Expense)를 줄일 수 있고, 서비스 운용 과정에서 필요시 스케일 아웃(Scale-out)을 통해 저장 용량 및 처리 용량을 증가시켜 실시간 대처가 가능하다.

본 명세서는 많은 특징을 포함하는 반면, 그러한 특징은 본 발명의 범위 또는 특허청구범위를 제한하는 것으로 해석되어서는 안 된다. 또한, 본 명세서에서 개별적인 실시예에서 설명된 특징들은 단일 실시예에서 결합되어 구현될 수 있다. 반대로, 본 명세서에서 단일 실시예에서 설명된 다양한 특징들은 개별적으로 다양한 실시예에서 구현되거나, 적절히 결합되어 구현될 수 있다.

도면에서 동작들이 특정한 순서로 설명되었으나, 그러한 동작들이 도시된 바와 같은 특정한 순서로 수행되는 것으로, 또는 일련의 연속된 순서, 또는 원하는 결과를 얻기 위해 모든 설명된 동작이 수행되는 것으로 이해되어서는 안 된다. 특정 환경에서 멀티태스킹 및 병렬 프로세싱이 유리할 수 있다. 아울러, 상술한 실시예에서 다양한 시스템 구성요소의 구분은 모든 실시예에서 그러한 구분을 요구하지 않는 것으로 이해되어야 한다. 상술한 프로그램 구성요소 및 시스템은 일반적으로 단일 소프트웨어 제품 또는 멀티플 소프트웨어 제품에 패키지로 구현될 수 있다.

이상에서 설명한 본 발명은, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니다.

310 : 데이터베이스 매니저
330-1, 330-1,..., 330-N : 데이터베이스 서버
350 : 클라이언트
351 : 프록시 모듈

Claims

데이터베이스 관리 시스템의 데이터베이스 매니저에 의한 데이터베이스 관리 방법에 있어서,
각각 데이터베이스 서버를 포함하는 복수의 그룹을 생성하는 단계;
상기 각 그룹에 대응하는 식별 키를 생성하는 단계;
상기 식별 키 및 상기 각 그룹의 속성 정보를 포함하는 기술서를 생성하는 단계; 및
상기 기술서를 상기 데이터베이스 서버를 이용하려는 클라이언트로 배포하는 단계;를 포함하는 데이터베이스 관리 방법.
제 1 항에 있어서,
상기 식별 키는, 범위 값으로서, 데이터베이스 서버에 저장될 실제 데이터의 해쉬 값이고,
상기 속성 정보는, 상기 각 그룹에 속하는 데이터베이스 서버의 형상 정보 및 상태 정보를 포함하는 것을 특징으로 하는 데이터베이스 관리 방법.
제 2 항에 있어서,
상기 각 그룹 중 적어도 하나의 그룹에서 데이터베이스 서버의 정보 변경을 감지하는 단계; 및
상기 감지된 정보 변경을 반영하여 상기 기술서를 갱신한 후 상기 클라이언트로 배포하는 단계;를 더 포함하는 것을 특징으로 하는 데이터베이스 관리 방법.
제 2 항에 있어서,
신규 데이터베이스 서버를 포함하는 신규 그룹을 추가하는 단계; 및
상기 추가된 신규 그룹의 속성 정보를 반영하여 기술서를 갱신한 후 상기 클라이언트로 배포하는 단계;를 더 포함하는 것을 특징으로 하는 데이터베이스 관리 방법.
제 2 항에 있어서,
상기 그룹 중 분산 대상 그룹에 대한 신규 데이터베이스 서버를 생성하고, 상기 분산 대상 그룹의 데이터를 상기 신규 데이터베이스 서버로 복제하는 단계;
상기 분산 대상 그룹의 데이터베이스 서버에 대한 쓰기 금지를 포함하도록 상기 기술서를 갱신하여 상기 클라이언트로 배포하는 단계;
상기 신규 데이터베이스 서버를 신규 그룹으로 독립시키고, 상기 범위 값인 상기 식별 키를 분리하는 단계; 및
상기 쓰기 금지의 해제 및 상기 신규 그룹의 속성 정보를 반영하여 상기 기술서를 갱신한 후 상기 클라이언트로 배포하는 단계;를 더 포함하는 것을 특징으로 하는 데이터베이스 관리 방법.
제 5 항에 있어서,
상기 분산 대상 그룹과 상기 신규 그룹에 대해 자신의 그룹에 포함되지 않는 데이터를 삭제하도록 하는 단계;를 더 포함하는 것을 특징으로 하는 데이터베이스 관리 방법.
제 6 항에 있어서,
상기 삭제하도록 하는 단계는,
상기 식별 키의 범위에 해당하지 않는 해쉬 값을 갖는 데이터를 삭제하는 것을 특징으로 하는 데이터베이스 관리 방법.
각각 데이터베이스 서버를 포함하는 복수의 그룹을 관리하는 데이터베이스 관리 시스템에 있어서,
상기 각 그룹에 대응하는 식별 키를 생성하는 식별 키 관리 모듈;
상기 각 그룹에 포함된 데이터베이스 서버를 감시하고 관리하는 데이터베이스 감시 모듈; 및
상기 각 그룹의 속성 정보를 포함하는 기술서를 생성하여 상기 데이터베이스 서버를 이용하려는 클라이언트로 배포하는 기술서 관리 모듈;을 포함하는 데이터베이스 관리 시스템.
제 8 항에 있어서,
상기 식별 키는, 범위 값으로서, 데이터베이스 서버에 저장될 실제 데이터의 해쉬 값이고,
상기 속성 정보는, 상기 각 그룹에 속하는 데이터베이스 서버의 형상 정보 및 상태 정보를 포함하는 것을 특징으로 하는 데이터베이스 관리 시스템.
제 9 항에 있어서,
상기 데이터베이스 감시 모듈은,
상기 각 그룹 중 적어도 하나의 그룹에서 데이터베이스 서버의 정보 변경을 감지하고,
상기 기술서 관리 모듈은,
상기 감지된 정보 변경을 반영하여 상기 기술서를 갱신한 후 상기 클라이언트로 배포하는 것을 특징으로 하는 데이터베이스 관리 시스템.
제 10 항에 있어서,
상기 데이터베이스 감시 모듈은,
신규 데이터베이스 서버를 포함하는 신규 그룹을 추가하고,
상기 기술서 관리 모듈은,
상기 추가된 신규 그룹의 속성 정보를 반영하여 기술서를 갱신한 후 상기 클라이언트로 배포하는 것을 특징으로 하는 데이터베이스 관리 시스템.
제 9 항에 있어서,
상기 데이터베이스 감시 모듈은, 상기 그룹 중 분산 대상 그룹의 데이터를 신규 데이터베이스 서버에 복제하고, 해당 신규 데이터베이스 서버를 신규 그룹으로 독립시키며,
상기 식별 키 관리 모듈은, 상기 범위 값인 상기 식별 키를 상기 신규 그룹에 대응하여 분리하고,
상기 기술서 관리 모듈은, 상기 식별 키를 분리하는 동안, 상기 분산 대상 그룹에 대한 쓰기 금지를 위한 기술서를 배포하고, 상기 식별 키의 분리 완료 후 상기 쓰기 금지의 해제 및 상기 신규 그룹의 속성 정보를 반영한 기술서를 상기 클라이언트로 배포하는 것을 특징으로 하는 데이터베이스 관리 시스템.
제 12 항에 있어서,
상기 데이터베이스 감시 모듈은,
상기 분산 대상 그룹과 상기 신규 그룹에 대해 자신의 그룹에 포함되지 않는 데이터를 삭제하도록 하는 것을 특징으로 하는 데이터베이스 관리 시스템.
제 13 항에 있어서,
상기 삭제는,
상기 식별 키의 범위에 해당하지 않는 해쉬 값을 갖는 데이터를 삭제하는 것을 특징으로 하는 데이터베이스 관리 시스템.
하드웨어와 결합되어 제 1 항 내지 제 7 항 중 어느 한 항에 따른 방법을 실행시키기 위하여 컴퓨터 판독 가능한 기록매체에 기록된 프로그램.