2019.03.12

IDG 블로그 | 페더레이티드 데이터베이스가 슬램덩크가 아닌 이유 2가지

David Linthicum | InfoWorld
데이터를 즉석에서 사용할 수 있는 역량은 클라우드에서 이기종 데이터를 사용하는 뛰어난 솔루션이다. 하지만 이렇게 하면 성능과 보안에 문제가 생기기 쉽다.

클라우드로 이전할 때 제일 먼저 해결해야 하는 문제인 경우가 많다. 규모가 큰 기업은 수십 개, 많은 경우 수백 개의 서로 다른 이기종 데이터베이스를 사용하는데, 이제 클라우드에서 이를 수백 개의 데이터 가상 뷰로 묶어내야만 하는 것이다.
 
ⓒGettyImagesBank


이런 방식이 좋은 점은 새로운 데이터베이스로 이전하지 않아도 된다는 것이다. 심지어 데이터를 호스팅한 곳에서 옮기지 않아도 된다. 결국, 해당 데이터에 의존하는 애플리케이션이 있기 마련이고, 가장 하기 싫은 일은 여분의 데이터를 저장하는 것이다.

이 때문에 데이터베이스를 이른바 ‘페더레이션(Federation)’한다. 이를 통해 데이터가 물리적으로 저장된 곳을 변경하지 않고도 데이터의 논리적인 중앙집중화를 구현할 수 있다.

하지만 문제가 일사천리로 해결되는 것은 아니다. 고려해야 할 장애물이 곳곳에 있는데, 필자는 다음 두 가지를 대표적인 해결 과제로 꼽는다.

우선, 성능이다. 중앙집중화되고 가상화된 뷰를 사용해 객체 데이터베이스와 관계형 데이터베이스, 심지어 비구조화 데이터로부터 데이터를 혼합할 수 있다. 하지만 해당 데이터 상에서 실시간 쿼리를 적절한 시간으로 실행하는 것은 전혀 다른 이야기다.

클라우드 기반 여유와 관계없이 페더레이티드 데이터베이스 시스템에는 불편한 진실이 있다. 가상 데이터베이스 활용을 최적화하는 데 드는 시간을 기꺼이 감수하지 않는다면, 성능 문제가 툭 튀어나와 페더레이티드 데이터베이스를 쓸모없게 만들 가능성이 크다. 페더레이티드 데이터베이스를 클라우드에 올리는 것도 도움이 되지 않는다. 성능을 강화하기 위해 가상 스토리지와 컴퓨트를 추가해도 마찬가지다.

이유는 수많은 서로 다른 데이터베이스 소스로부터 데이터를 필요한 곳에 가져오는 데 너무 많은 백그라운드 작업이 발생해야 하기 때문이다. 이런 문제는 보통 좋은 페더레이티드 데이터베이스 설계를 파악하고 데이터베이스를 튜닝하고, 단일 패턴 액세스 내에서 얼마나 많은 물리 데이터베이스를 연계할지 제한을 두는 과정에서 바로 잡는다.

둘째는 보안이다. 필자는 클라우드에서 구동하는 클라우드 기반 페더레이티드 데이터베이스 대부분이 악용할 수 있는 취약점이 있다고 확신하며, 데이터를 보유한 대부분 기업은 이를 모른다.

원인은 성능 문제와 마찬가지다. 너무나 많은 구동부가 있기 때문에 모든 데이터와 액세스 지점, 메타데이터 등등을 확실하게 잠그면서 쉽게 액세스할 수 있도록 하는 것은 매우 어려운 일이다.

페더레이티드 데이터베이스를 사용하는 시스템이 보통 때는 데이터를 암호화할지 몰라도, 즉석에서 사용할 때는 흔히 암호화하지 않는다. 아니면 그 반대일 수도 있다. 아니면 페더레이티드 데이터베이스 아키텍처를 우회해서 물리 데이터베이스로 직접 액세스하는 경로가 있을 수도 있다.

필자는 아직 물리 데이터베이스와 가상 데이터베이스 계층 모두에서 동작하는 중앙집중화된 보안을 갖춘 페더레이티드 데이터베이스 시스템을 본 적이 없다. 이런 허점을 바로 막아야 할 것이다. editor@itworld.co.kr


2019.03.12

IDG 블로그 | 페더레이티드 데이터베이스가 슬램덩크가 아닌 이유 2가지

David Linthicum | InfoWorld
데이터를 즉석에서 사용할 수 있는 역량은 클라우드에서 이기종 데이터를 사용하는 뛰어난 솔루션이다. 하지만 이렇게 하면 성능과 보안에 문제가 생기기 쉽다.

클라우드로 이전할 때 제일 먼저 해결해야 하는 문제인 경우가 많다. 규모가 큰 기업은 수십 개, 많은 경우 수백 개의 서로 다른 이기종 데이터베이스를 사용하는데, 이제 클라우드에서 이를 수백 개의 데이터 가상 뷰로 묶어내야만 하는 것이다.
 
ⓒGettyImagesBank


이런 방식이 좋은 점은 새로운 데이터베이스로 이전하지 않아도 된다는 것이다. 심지어 데이터를 호스팅한 곳에서 옮기지 않아도 된다. 결국, 해당 데이터에 의존하는 애플리케이션이 있기 마련이고, 가장 하기 싫은 일은 여분의 데이터를 저장하는 것이다.

이 때문에 데이터베이스를 이른바 ‘페더레이션(Federation)’한다. 이를 통해 데이터가 물리적으로 저장된 곳을 변경하지 않고도 데이터의 논리적인 중앙집중화를 구현할 수 있다.

하지만 문제가 일사천리로 해결되는 것은 아니다. 고려해야 할 장애물이 곳곳에 있는데, 필자는 다음 두 가지를 대표적인 해결 과제로 꼽는다.

우선, 성능이다. 중앙집중화되고 가상화된 뷰를 사용해 객체 데이터베이스와 관계형 데이터베이스, 심지어 비구조화 데이터로부터 데이터를 혼합할 수 있다. 하지만 해당 데이터 상에서 실시간 쿼리를 적절한 시간으로 실행하는 것은 전혀 다른 이야기다.

클라우드 기반 여유와 관계없이 페더레이티드 데이터베이스 시스템에는 불편한 진실이 있다. 가상 데이터베이스 활용을 최적화하는 데 드는 시간을 기꺼이 감수하지 않는다면, 성능 문제가 툭 튀어나와 페더레이티드 데이터베이스를 쓸모없게 만들 가능성이 크다. 페더레이티드 데이터베이스를 클라우드에 올리는 것도 도움이 되지 않는다. 성능을 강화하기 위해 가상 스토리지와 컴퓨트를 추가해도 마찬가지다.

이유는 수많은 서로 다른 데이터베이스 소스로부터 데이터를 필요한 곳에 가져오는 데 너무 많은 백그라운드 작업이 발생해야 하기 때문이다. 이런 문제는 보통 좋은 페더레이티드 데이터베이스 설계를 파악하고 데이터베이스를 튜닝하고, 단일 패턴 액세스 내에서 얼마나 많은 물리 데이터베이스를 연계할지 제한을 두는 과정에서 바로 잡는다.

둘째는 보안이다. 필자는 클라우드에서 구동하는 클라우드 기반 페더레이티드 데이터베이스 대부분이 악용할 수 있는 취약점이 있다고 확신하며, 데이터를 보유한 대부분 기업은 이를 모른다.

원인은 성능 문제와 마찬가지다. 너무나 많은 구동부가 있기 때문에 모든 데이터와 액세스 지점, 메타데이터 등등을 확실하게 잠그면서 쉽게 액세스할 수 있도록 하는 것은 매우 어려운 일이다.

페더레이티드 데이터베이스를 사용하는 시스템이 보통 때는 데이터를 암호화할지 몰라도, 즉석에서 사용할 때는 흔히 암호화하지 않는다. 아니면 그 반대일 수도 있다. 아니면 페더레이티드 데이터베이스 아키텍처를 우회해서 물리 데이터베이스로 직접 액세스하는 경로가 있을 수도 있다.

필자는 아직 물리 데이터베이스와 가상 데이터베이스 계층 모두에서 동작하는 중앙집중화된 보안을 갖춘 페더레이티드 데이터베이스 시스템을 본 적이 없다. 이런 허점을 바로 막아야 할 것이다. editor@itworld.co.kr


X