데이터아키텍처전문가 - 국가공인자격 데이터베이스 선정에는 비밀이 있다 - 1부

데이터베이스를 구축하는 과정에서 데이터베이스에서 많은 부분을 놓치는 것 같다. 이렇게 무심코 놓치는 부분이 추후 우리에게는 크나큰 악 영향으로 다가온다는 것을 아는가? 많은 사이트에서 데이터베이스 선정의 비밀을 이해하지 못하는 것 같다. 분명한 것은 데이터베이스의 선정에는 비밀이 있다는 것이다. 이제부터 데이터베이스 선정의 비밀을 알아 보자.

많은 기업에서 프로젝트를 수행하게 되면 많은 하드웨어와 소프트웨어가 도입된다. 그 중에서도 데이터베이스의 도입은 많은 프로젝트에서 필수일 것이다. 시중에는 많은 데이터베이스 제품이 존재한다. 이처럼 많은 데이터베이스 중 과연 무엇을 기준으로 데이터베이스를 선정하는가? 많은 프로젝트를 지원하면서 데이터베이스를 도입하는 과정을 보았으며 이러한 데이터베이스를 선정하는 과정에는 매우 일반적인 기준이 존재한다. 물론, 다른 소프트웨어도 상황은 비슷할 것이다. 데이터베이스는 한번 선정되면 추후 다른 제품으로 변경하기 쉽지 않다. 그렇기 때문에 데이터베이스를 구축하기 위해 데이터베이스를 도입하는 경우에는 반드시 선정 기준이 존재해야 하며 선정 기준에 따라 데이터베이스가 선택되어야 할 것이다. 또한, 중요한 것은 이러한 선정 기준이 매우 자세히 구분되어 있어야 한다는 것이다. 그렇다면 어떤 항목을 선정 기준으로 데이터베이스를 선택해야 할까? 데이터베이스를 선정하기 위해서는 가용성, 성능, 상호 호환성, 지원 및 구축 비용 등을 고려해야 한다. 여기서는 이러한 일반적인 데이터베이스 선정 기준을 언급하고자 하는 것이 아니며 이러한 선정 기준 중 우리가 데이터베이스를 선정하는데 있어 쉽게 놓치는 부분만을 언급하려고 한다. 이제 우리가 놓치기 쉬운 데이터베이스 선정의 숨겨져 있는 비밀을 파헤쳐 보자.

데이터베이스 가용성 확보의 비밀은 가까운데 숨겨 있다.

시스템의 모든 항목에 대해서 제품을 선정해본 사람이라면 가용성이라는 용어를 안 들어본 사람은 없을 것이다. 하지만 많은 프로젝트 및 많은 고객사와의 회의를 통해서 느꼈던 것은 데이터베이스에 대해서는 가용성의 개념을 모르는 것 같았다. 어느 회의에 참석했을 때 고객사에서 시스템이 모두 이중화되어 가용성에는 이상이 없는가에 대해 질문을 했다. 본인은 데이터에 대해서는 이중화가 되어 있지 않다고 언급했다. 하지만 참석자 중 한명은 디스크가 미러(Mirror)로 되어 있으므로 이중화가 완벽하게 된 것이라고 했다. 과연 이러한 디스크 미러(Mirror)만 구성되어 있다면 데이터베이스는 이중화가 완벽하게 구현된 것인가? 가용성은 이중화와 매우 밀접한 관계를 가진다. 이중화라는 것은 무엇인가? 모든 항목에 대해 2개로 구성하는 것이 이중화이다. 이와 같이 구성하는 이유는 1개가 문제가 발생했을 경우 다른 하나로 서비스를 수행하기 위해서 이중화를 하는 것이다. 이것이 가용성의 근간이 되는 것은 당연한 이야기이다.

예를 들어, 서버를 한대만 가지고 있다면 해당 서버에 문제가 발생했을 경우 서비스를 제공할 수 있는 서버가 존재하지 않기 때문에 문제가 발생한 하나의 서버에 대해 문제를 해결할 때까지는 서비스를 수행하지 못할 것이다. 이와 같기 때문에 서버부터 시작하여 채널, 네트웍 장비 및 데이터베이스 서버 등을 2개씩 구축하여 이중화를 완료한 후 고객사에 가용성에는??객사에서도 모든 장비에 대해 2개씩 구매했으므로 이제부터는 어떠한 장애에도 서비스는 가능하다고 생각한다. 과연 여기까지만 수행한다면 모든 장애에 대해 서비스를 유지할 수 있는가?

많은 사람들이 흔히 잊는 가용성이 하나 존재한다. 그것이 바로 데이터의 가용성이다. 데이터의 가용성을 확보하기 위해서는 데이터를 이중화해야 할 것이다. 이 경우 많은 사람들이 생각하는 것이 디스크 미러(Mirror)이다. 디스크 미러(Mirror)는 당연히 디스크에 대해 가용성을 확보하는 방법이 맞다. 하지만 데이터의 가용성은 디스크 미러(Mirror)로만 해결할 수 없다. 디스크 미러(Mirror)로만 데이터의 가용성을 구성한다면 하나만 알고 둘은 모르는 것이다. 데이터는 디스크를 미러(Mirror)로 구성하여 동일한 데이터를 실시간으로 복사한다고 해도 이는 완전환 이중화가 아니다. 왜냐하면 데이터는 디스크에 저장되기 때문에 디스크의 이중화 뿐만 아니라 데이터 자체의 이중화가 필요하다는 것이다. 따라서, 디스크는 디스크 미러(Mirror)로 이중화가 될 수 있지만 데이터 자체는 이중화가 되지 않는 것이다. 왜 이와 같은 현상이 발생하는가? 데이터가 저장되어 있는 디스크가 물리적으로 문제가 발생한다면 디스크 미러(Mirror)로 해결이 가능하다, 하지만 데이터 자체에 논리적인 문제가 발생한다면 디스크 미러(Mirror)로는 해결할 수 없다는 것을 아는가?

예를 들어, 사용자의 실수로 중요한 대용량 테이블을 삭제했다고 가정하자. 디스크 미러(Mirror)로만 구성되어 있다면 이와 같은 경우 중요한 대용량 테이블을 복구할 때 까지 서비스를 유지할 수 없게 된다. 대부분의 데이터베이스가 테이블을 복구하는 것은 쉽지 않기 때문에 어쩌면 많은 시간 동안 서비스를 수행하지 못하게 된다. 과연 이와 같은 현상이 발생한다면 해당 시스템이 가용성을 고려한 것인가?

데이터의 이중화를 통한 가용성을 확보하기 위해서는 데이터베이스의 선택과 구성이 매우 중요하다. 디스크 미러(Mirror)를 제외한 데이터 자체의 이중화가 바로 우리들이 간과하고 있는 데이터베이스의 가용성이다. 데이터베이스는 메모리 영역인 인스턴스 영역과 디스크 영역인 데이터 영역으로 구성된다. 따라서 가용성 또한 2가지 모두를 고려해야 할 것이다. 인스턴스 영역은 서버를 여러 대 도입함으로써 해결이 가능하다. 반면에 디스크 영역에 저장되어 있는 데이터에 대한 이중화는 많이 고려하지 않는 것 같다. 이제부터 잊고있는 데이터의 이중화를 고려해야 할 것이다. 또한, 이러한 데이터의 이중화는 어떤 데이터베이스를 선택하는가에 따라 구성 방식 및 사용 방법이 달라진다는 것을 명심하길 바란다.

데이터의 가용성에서 인스턴스 영역과 데이터 영역에 대해 가용성을 확보해야 한다는 것이 가용성의 비밀이다. 특히, 흔히 잊고있는 데이터 자체의 이중화가 매우 중요하다. 이제 우리는 눈앞에 있는 데이터 자체의 이중화에도 관심을 가져야 할 것이다.

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

인스턴스의 가용성과 데이터의 가용성을 확보해라.

데이터베이스는 서버에서 수행되는 인스턴스 영역과 디스크에 저장되어 있는 데이터 영역으로 구분하여 가용성을 확보해야 할 것이다. 인스턴스의 가용성과 데이터의 가용성은 어떤 데이터베이스를 선정하는가에 따라 많은 변화가 발생한다. 많은 사이트에서는 인스턴스 영역의 가용성만을 고려하는 경우가 많다. 인스턴스의 가용성도 매우 중요하다. 인스터스의 가용성이 확보되지 않는다면 장애 발생시 데이터베이스로 접속조차 안되기 때문이다. 만약, 원하는 데이터가 장애에 의해 존재하지 않거나 또는 잘못되어 있다면 데이터베이스로 접속만 하면 무엇을 하겠는가? 이제 우리는 가용성을 고려하여 데이터베이스를 선정할 경우 인스턴스 가용성과 함께 반드시 데이터 가용성을 검토해야 할 것이다.

첫 번째로 인스턴스의 가용성을 확인해 보자. 데이터베이스의 실제 작업은 서버의 메모리에서 수행하기 때문에 서버가 문제가 발생한다면 이는 어떠한 서비스도 수행할 수 없게 된다. 그렇기 때문에 인스턴스 가용성을 구현하기 위해서는 서버의 추가 도입은 필수일 것이다.

오라클의 경우는 RAC 아키텍쳐를 오라클 9i부터 제공하여 인스턴스 가용성에서는 매우 탁월한 기능을 제공하게 되었다. RAC를 사용할 경우 장애 발생시에도 서비스 정지가 거의 발생하지 않게 된다. 물론, 데이터베이스 작업 시에도 서비스 정지가 발생하지 않게 된다. 이처럼 오라클은 인스턴스 가용성에서는 RAC를 제공하여 서버 도입만으로 인스턴스 가용성을 제공하게 된다. 이는 다른 데이터베이스에 비해 탁월한 인스턴스 가용성을 제공하는 기능이 된다.

SYBASE, MS-SQL 및 UDB의 경우는 복제 개념을 사용하여 인스턴스 가용성을 보장하게 된다. 그렇기 때문에 인스턴스 가용성을 위해 서버도 도입되어야 하지만 디스크도 동일하게 추가되어야 한다는 것이다. 또한, 이와 같은 복제 개념을 이용하는 인스턴스 이중화는 어느 정도의 서비스 정지가 발생하게 된다. 하지만 디스크를 가용성을 위해 도입하여 데이터를 복제하기 때문에 데이터 가용성까지 구성되는 장점을 가지게 된다.

두 번째로 데이터 가용성에 대해 확인해 보자. 데이터의 가용성은 앞서 언급한 것과 같이 디스크 미러(Mirror)로만 해결할 수 없다. 디스크 미러는 물리적인 디스크의 가용성을 확보하는 것이다. 보통의 경우는 디스크의 물리적인 장애 보다는 데이터의 논리적인 장애가 더 많이 발생하게 되므로 더욱 중요한 것은 데이터의 이중화이다. 이는 데이터베이스에서 제공하는 아키텍쳐를 사용해야 할 것이다.

오라클의 경우는 STANDBY DB 아키텍쳐를 제공하여 데이터 가용성을 확보하게 된다. STANDBY DB는 운영 시스템과 동일하게 시스템을 구성하여 별도의 장소에 위치시키게 된다. 그리고 운영 데이터베이스의 데이터를 STANDBY DB로 복제를 수행하여 보관하게 된다. 이후 데이터에 장애가 발생하면 STANDBY DB를 이용하여 서비스를 수행하게 된다. 이와 같은 구성을 가지므로 STANDBY DB에서 서비스를 수행하기 까지는 서비스 정지가 발생하게 될 것이다. SYBASE, MS-SQL 및 UDB의 경우는 복제를 이용하게 된다. 인스턴스 가용성을 구성하게 되면 데이터 가용성은 자동으로 구성된다. 따라서, 이러한 점은 오라클에 비해 장점이 될 것이다.

디스크의 가용성이 구성된다면 이는 DR(Disaster Recovery)로서도 사용이 가능하다. 오라클의 경우도 디스크 복제 방식으로 구성하고자 한다면 다른 업체의 복제 솔루션을 도입하면 가능하다. 물론, 이와 같이 복제 솔루션을 도입하는 경우 추가 비용이 발생하게 된다. 어떤 사이트에서는 이러한 데이터의 가용성을 고려하지 않고 인스턴스 가용성만 확보한 후 디스크 복제 솔루션을 이용하는 사이트도 많다. 물론, 데이터 가용성을 무조건 데이터베이스의 기능을 이용할 필요는 없다. 이처럼 디스크 복제 솔루션을 이용할 수도 있다. 하지만 이와 같이 구성한 대부분의 사이트가 데이터 가용성을 위한 것이 아니라 데이터 백업을 위해 사용하는 경우가 많다. 이처럼 이미 비용은 비용대로 추가했지만 여러 기능으로 사용할 수 있는 구성을 제대로 사용하지 못하는 현실이 너무 슬픈 것 같다.

결국, 데이터베이스마다 지원하는 가용성의 방법 및 그 수준은 차이가 발생한다. 가용성의 수준이 높다고 좋고 가용성이 낮다고 안 좋은 데이터베이스는 아니다. 이는 업무에 따라 달라질 것이다. 업무가 중요하지 않다면 가용성의 수준이 낮은 데이터베이스를 선정해도 될 것이다. 하지만 매우 중요한 업무의 데이터베이스인 경우 매우 높은 수준의 가용성을 원한다면 그만큼 인스턴스 가용성과 데이터 가용성을 면밀히 검토해야 할 것이다. 올바른 데이터베이스 선정으로 원하는 인스턴스 가용성과 데이터 가용성을 구성하는 것이 가용성의 비밀을 알아내는 방법이다.