2018.06.20

데이터베이스의 중심 이동 “오픈소스로 시작하지만 AWS로 마무리”

Matt Asay | InfoWorld
클라우드는 원래 오픈소스의 천적으로 여겨졌다. 그러나 영리한 클라우드 서비스 업체들은 독점 서비스로의 진입 경로로 오픈소스를 사용하면서 보완적 관계에 있는 오픈소스 프로젝트에 대한 투자를 늘리고 있다. 구글이 대표적인 예다. 구글이 내놓은 텐서플로우와 쿠버네티스는 구글 클라우드 플랫폼을 기반으로 머신러닝과 컨테이너 기반 워크로드에 심취한 개발자 세대를 육성하기 위한 수단이다.

구글만 그런 것은 아니다. 아마존 웹 서비스에도 오픈소스 전략이 있다. 구글만큼 명확하지는 않지만 위력은 뒤지지 않는다. AWS 고객인 인포스카우트(InfoScout)에 따르면, AWS는 MySQL과 같은 온프레미스 데이터베이스와 아마존 오로라(Aurora) 등의 클라우드 서비스 사이에 자연스럽게 보이는 다리를 놓고 있는 것으로 보인다. 시작은 오픈소스로 하되 마무리는 AWS로 할 이유를 제공하는 것이다.

온프레미스 MySQL에서 클라우드 오로라로 이동
불과 몇 년 전만 해도 AWS와 같은 퍼블릭 클라우드 IaaS 플랫폼은 기업이 개발 및 테스트 워크로드 정도는 클라우드에서 실행할 수 있지만, 프로덕션은 항상 자체 데이터센터 내에 둘 것이라는 비관적인 전망에 직면해 있었다.

그 말은 아주 잠깐 동안은 사실이었지만 지금 관점에서 보면 완전한 헛소리였다. 캐피털 원(Capital One)과 같은 기업은 대부분의 데이터센터를 폐쇄하고 워크로드를 클라우드로 옮기는 중이다. 통제와 위험에 대한 우려도 보안 모델과 즉석 인프라 프로비저닝 기능, 피크 시간대의 구매 수요를 처리할 수 있는 탄력성, 고가용성, 혁신의 속도를 갖춘 AWS와 같은 퍼블릭 클라우드에 결국 굴복했다.

시대가 바뀐 것이다.

너무 많이 바뀌어서 이제 퍼블릭 클라우드가 프로덕션 워크로드를 처리하고 개발-테스트 워크로드는 온프레미스의 개발자 노트북에서 실행되는 상황이다. 이러한 전환이 가장 극명하게 드러나는 분야는 데이터 중력 탓에 클라우드로의 이동에 대한 저항이 가장 컸던 데이터베이스다.

인포스카우트의 엔지니어링 담당 이사 대나 포드가 말했듯이 기업이 MySQL을 도입한 이유는 MySQL이 수십년 동안 사용된, 다양한 워크로드를 위한 검증된 데이터베이스이기 때문이다. 그러나 프로덕션에서 MySQL 확장은 인포스카우트가 가진 데이터베이스 전문 기술의 한계를 넘는 일이다. 인포스카우트는 담당자를 전문 DBA로 육성할 만한 여력이 없었다.

그래서 아마존 오로라를 선택했다. 인포스카우트 CTO 존 브렐리그는 “오로라는 MySQL과 호환된다(완전한 프로토콜 호환성 제공)”면서 “덕분에 여전히 MySQL을 사용하는 개발 환경을 두면서 프로덕션을 거의 아무런 걸림돌 없이 오로라에 배포할 수 있다”고 말했다. “거의”라는 말의 구체적인 뜻을 묻자 브렐리그는 오로라가 MySQL 버전과 완벽하게 보조를 맞추지는 않는다고 설명했다. 참고로 오로라는 현재 MySQL 8.0을 지원하지 않는다. 버전 5.7을 지원하기 시작한 것도 최근의 일이다.

그러나 기업이 데이터베이스와 테이블의 스키마 구조를 어떻게 정의하느냐에 달린 문제이기도 하다. 인포스카우트의 경우 MySQL 개발 워크로드를 오로라 프로덕션 워크로드로 전환하는 과정에서 “약간의 조정”만 필요하다. 큰 작업은 필요 없다.

DBA가 아닌 고객에 투자할 여력 확보
여기서 순진한 개발자를 독점 소프트웨어 영역으로 유인하는 사악한 군주의 웃음 소리를 상상해 보자. ‘MySQL에서 오로라로의 전환’을 그렇게 받아들이는 사람이 분명 있을 것이다. 그러나 인포스카우트 엔지니어링 임원들이 하는 이야기를 들어보면, 이들은 결코 그렇게 생각하지 않는다. 포드는 “인포스카우트가 클라우드와 오로라의 가치를 높게 평가하는 이유는 코드와 인프라에 대한 부담을 덜고 비즈니스에 더 집중할 수 있게 해주기 때문”이라고 말했다.

이들과의 대화에서 끊임없이 반복해서 들은 이야기다. 브렐리그와 포드 모두 인포스카우트가 오픈소스에 크게 의존한다는 점을 강조했지만, AWS를 기반으로 한 시스템 구축을 통해 얻은 가치에 대해서도 마찬가지로 강조했다. 이들은 “AWS와 오로라를 좋아하는 이유는 스위치 조작 한 번으로 고객에 더 집중할 수 있게 됐기 때문이다. 우리는 기본적으로 오픈소스를 선택하지만, 고객을 위한 일에 더 많은 시간을 투자할 수 있게 해주는 다른 솔루션에도 관심이 있다”고 말했다.

인포스카우트와 같은 기업이 마스터 DBA 육성이 아닌 고객에게 도움이 되는 비즈니스 논리를 만드는 데 더 많은 시간을 투자할 수 있는 원동력은 클라우드에서 파생되는 비즈니스 민첩성이다. 오픈소스는 개발과 프로덕션 환경 간의 동일성을 확보하는 데 유용하다. 그러나 오로라와 같은 클라우드 서비스는 MySQL과 같은 오픈소스 데이터베이스를 프로덕션에서 확장하는 데 따르는 어려운 작업을 대부분 제거함으로써 이 파트너십의 수준을 한층 더 높여준다.

두 세계의 장점을 모두 취하는 것이다. 물론 특정 클라우드 데이터베이스 서비스로의 종속도 발생한다. 그러나 점점 더 많은 기업이 그 타협을 기꺼이 받아들이고 있다.  editor@itworld.co.kr


2018.06.20

데이터베이스의 중심 이동 “오픈소스로 시작하지만 AWS로 마무리”

Matt Asay | InfoWorld
클라우드는 원래 오픈소스의 천적으로 여겨졌다. 그러나 영리한 클라우드 서비스 업체들은 독점 서비스로의 진입 경로로 오픈소스를 사용하면서 보완적 관계에 있는 오픈소스 프로젝트에 대한 투자를 늘리고 있다. 구글이 대표적인 예다. 구글이 내놓은 텐서플로우와 쿠버네티스는 구글 클라우드 플랫폼을 기반으로 머신러닝과 컨테이너 기반 워크로드에 심취한 개발자 세대를 육성하기 위한 수단이다.

구글만 그런 것은 아니다. 아마존 웹 서비스에도 오픈소스 전략이 있다. 구글만큼 명확하지는 않지만 위력은 뒤지지 않는다. AWS 고객인 인포스카우트(InfoScout)에 따르면, AWS는 MySQL과 같은 온프레미스 데이터베이스와 아마존 오로라(Aurora) 등의 클라우드 서비스 사이에 자연스럽게 보이는 다리를 놓고 있는 것으로 보인다. 시작은 오픈소스로 하되 마무리는 AWS로 할 이유를 제공하는 것이다.

온프레미스 MySQL에서 클라우드 오로라로 이동
불과 몇 년 전만 해도 AWS와 같은 퍼블릭 클라우드 IaaS 플랫폼은 기업이 개발 및 테스트 워크로드 정도는 클라우드에서 실행할 수 있지만, 프로덕션은 항상 자체 데이터센터 내에 둘 것이라는 비관적인 전망에 직면해 있었다.

그 말은 아주 잠깐 동안은 사실이었지만 지금 관점에서 보면 완전한 헛소리였다. 캐피털 원(Capital One)과 같은 기업은 대부분의 데이터센터를 폐쇄하고 워크로드를 클라우드로 옮기는 중이다. 통제와 위험에 대한 우려도 보안 모델과 즉석 인프라 프로비저닝 기능, 피크 시간대의 구매 수요를 처리할 수 있는 탄력성, 고가용성, 혁신의 속도를 갖춘 AWS와 같은 퍼블릭 클라우드에 결국 굴복했다.

시대가 바뀐 것이다.

너무 많이 바뀌어서 이제 퍼블릭 클라우드가 프로덕션 워크로드를 처리하고 개발-테스트 워크로드는 온프레미스의 개발자 노트북에서 실행되는 상황이다. 이러한 전환이 가장 극명하게 드러나는 분야는 데이터 중력 탓에 클라우드로의 이동에 대한 저항이 가장 컸던 데이터베이스다.

인포스카우트의 엔지니어링 담당 이사 대나 포드가 말했듯이 기업이 MySQL을 도입한 이유는 MySQL이 수십년 동안 사용된, 다양한 워크로드를 위한 검증된 데이터베이스이기 때문이다. 그러나 프로덕션에서 MySQL 확장은 인포스카우트가 가진 데이터베이스 전문 기술의 한계를 넘는 일이다. 인포스카우트는 담당자를 전문 DBA로 육성할 만한 여력이 없었다.

그래서 아마존 오로라를 선택했다. 인포스카우트 CTO 존 브렐리그는 “오로라는 MySQL과 호환된다(완전한 프로토콜 호환성 제공)”면서 “덕분에 여전히 MySQL을 사용하는 개발 환경을 두면서 프로덕션을 거의 아무런 걸림돌 없이 오로라에 배포할 수 있다”고 말했다. “거의”라는 말의 구체적인 뜻을 묻자 브렐리그는 오로라가 MySQL 버전과 완벽하게 보조를 맞추지는 않는다고 설명했다. 참고로 오로라는 현재 MySQL 8.0을 지원하지 않는다. 버전 5.7을 지원하기 시작한 것도 최근의 일이다.

그러나 기업이 데이터베이스와 테이블의 스키마 구조를 어떻게 정의하느냐에 달린 문제이기도 하다. 인포스카우트의 경우 MySQL 개발 워크로드를 오로라 프로덕션 워크로드로 전환하는 과정에서 “약간의 조정”만 필요하다. 큰 작업은 필요 없다.

DBA가 아닌 고객에 투자할 여력 확보
여기서 순진한 개발자를 독점 소프트웨어 영역으로 유인하는 사악한 군주의 웃음 소리를 상상해 보자. ‘MySQL에서 오로라로의 전환’을 그렇게 받아들이는 사람이 분명 있을 것이다. 그러나 인포스카우트 엔지니어링 임원들이 하는 이야기를 들어보면, 이들은 결코 그렇게 생각하지 않는다. 포드는 “인포스카우트가 클라우드와 오로라의 가치를 높게 평가하는 이유는 코드와 인프라에 대한 부담을 덜고 비즈니스에 더 집중할 수 있게 해주기 때문”이라고 말했다.

이들과의 대화에서 끊임없이 반복해서 들은 이야기다. 브렐리그와 포드 모두 인포스카우트가 오픈소스에 크게 의존한다는 점을 강조했지만, AWS를 기반으로 한 시스템 구축을 통해 얻은 가치에 대해서도 마찬가지로 강조했다. 이들은 “AWS와 오로라를 좋아하는 이유는 스위치 조작 한 번으로 고객에 더 집중할 수 있게 됐기 때문이다. 우리는 기본적으로 오픈소스를 선택하지만, 고객을 위한 일에 더 많은 시간을 투자할 수 있게 해주는 다른 솔루션에도 관심이 있다”고 말했다.

인포스카우트와 같은 기업이 마스터 DBA 육성이 아닌 고객에게 도움이 되는 비즈니스 논리를 만드는 데 더 많은 시간을 투자할 수 있는 원동력은 클라우드에서 파생되는 비즈니스 민첩성이다. 오픈소스는 개발과 프로덕션 환경 간의 동일성을 확보하는 데 유용하다. 그러나 오로라와 같은 클라우드 서비스는 MySQL과 같은 오픈소스 데이터베이스를 프로덕션에서 확장하는 데 따르는 어려운 작업을 대부분 제거함으로써 이 파트너십의 수준을 한층 더 높여준다.

두 세계의 장점을 모두 취하는 것이다. 물론 특정 클라우드 데이터베이스 서비스로의 종속도 발생한다. 그러나 점점 더 많은 기업이 그 타협을 기꺼이 받아들이고 있다.  editor@itworld.co.kr


X