데이터베이스 환경에 대한 간략한 개요

소프트웨어 라이선스는 간단히 말해서, 복잡합니다. 지적 재산권뿐만 아니라(이를 위해서는 Besen & Raskind의 “An Introduction to the Law and Economics of Intellectual Property”와 Rosen의 Open Source Licensing: Software Freedom and Intellectual Property Law를 확인하는 것을 권장) 특히 라이선스에 관심을 가져야 하는 이유와 비즈니스에 영향을 미칠 수 있는 오픈 소스 데이터베이스 환경의 동향에 대해 확인해야 합니다.

준비되셨나요?

먼저 라이선스에 대해 알아보겠습니다.

모든 소프트웨어 라이선스에는 사용자가 준수해야 하는 기술 사용 방법에 대한 규칙과 규정이 포함되어 있습니다. 즉, 채택한 소프트웨어의 라이선스가 비즈니스 수행 방식에 실질적인 영향을 미칠 수 있습니다. 이러한 규칙을 무시하거나 위반하면 법적 위험, 재정적 손실에 노출될 수 있으며, 솔직히 회사의 평판이 훼손될 수 있습니다. 소프트웨어를 구매하든 오픈 소스 기술을 채택하든 라이선스는 궁극적으로 코드 사용을 어느 정도 제한합니다. 즉, 장기적인 법적 위험을 완화할 수 있도록 제품을 개발할 때 이러한 제약 사항을 숙지하세요.

다음으로, 라이선스는 고정되어 있지 않다는 점에 유의하세요. 실제로 현재 오픈 소스 데이터베이스 프로젝트를 지원하는 많은 회사에서 데이터베이스 라이선스를 더 제한적으로 변경하는 중입니다. 사용 사례에 따라 데이터베이스를 무료로 사용해 온 경우, 이제 법적 조치에 노출될 수 있습니다. 겁을 주려는 것이 아니라 경계를 늦추지 말라는 의미입니다. 이러한 변화가 발생하면 적절하게 대응하는 것이 중요합니다. 경우에 따라 라이선스 변경으로 인해 서비스를 다시 설계하거나, 다른 데이터베이스를 채택하거나, 공급업체와 상업적 계약을 체결해야 할 수도 있습니다.

이 문제 영역을 좀 더 살펴보겠습니다.

Hacker News나 TechCrunch를 자주 방문하는 사람들이라면 오픈 소스 및 상용 데이터베이스 소프트웨어에 대한 대화가 낯설지 않을 것입니다. 요점을 말하자면, 지난 3년 동안 주요 퍼블릭 클라우드 공급업체의 성장과 오픈 소스 중심 데이터베이스 제공업체의 시장 성공 또는 실패와 같은 요인이 복합적으로 작용하여 논쟁이 벌어졌습니다.

즉, 자유 소프트웨어와 독점 소프트웨어 사이의 관계는 이분법적인 것이 아니라 엄밀히 말해 스펙트럼에 속합니다.

참고: 그림에 표시된 거리는 비과학적이며, 상대성이 더 중요합니다.

위의 스펙트럼을 살펴보면 맨 왼쪽에는 Oracle, IBM Db2 및 Microsoft SQL Server와 같은 상용 또는 독점 데이터베이스 소프트웨어 라이선스가 있습니다. 이들은 모든 산업 분야에서 워크로드를 지원하며 강력하고 기능이 풍부한 기술입니다. 이 소프트웨어를 공급업체로부터 또는 클라우드 서비스로 구매하면 프리미엄을 지불해야 다음 기능을 이용할 수 있습니다.

• 코드 수준 지원

• 강력한 툴링 에코시스템

• 전문 서비스 및 컨설턴트

• 해당 데이터베이스의 로드맵에 대한 가시성 및 영향력

오른쪽에는 퍼블릭 도메인 소프트웨어가 있습니다. 이 소프트웨어는 저작권이 전혀 없으므로 제한 없이 수정, 배포 또는 판매할 수 있습니다. 스펙트럼의 오른쪽 끝에 있는 프로젝트는 Apache Software Foundation 또는 Linux Foundation과 같이 공정하고 편향되지 않은 제3자 표준에 의해 관리되는 경우가 많습니다.

오픈 소스 이니셔티브(Open Source Initiative)는 일반적으로 허용되는 오픈 소스 라이선스와 그렇지 않은 라이선스 목록을 관리합니다. 일반적으로 오픈 소스 소프트웨어는 '코드 포크' 기능이 특징입니다. 즉, 프로젝트(소프트웨어)의 방향이 필요하거나 원하는 것과 상충되는 경우, 적합하다고 생각되는 대로 코드를 수정하거나 편집할 수 있습니다.

오픈 소스 기술을 사용하면 라이선스 비용이 전혀 들지 않고, 개발 투명성이 높아지며, 다양한 이해관계자, 이해관계자, 문제 공간에서 혁신을 이끌어낼 수 있다는 점으로 인해 특히 매력적입니다. 상용 소프트웨어와 비교하여, 오픈 소스 소프트웨어를 사용하면 로드맵 영향력, 버그 수정 또는 보안 패치 관련 보장, 계약 등을 포기하고, 특정 벤더에 종속되지 않으며 비즈니스 유연성을 향상할 수 있습니다. (이는 사용자와 사용자 팀이 신중하게 고려해야 할 절충점이라는 것을 알 수 있습니다.)

위 차트의 여정을 왼쪽에서 오른쪽으로 따라가다 보면 Apache 2.0, MPL, GPL 3.0 등 다양한 라이선스 허용 수준을 확인할 수 있습니다.

라이선스에 매핑된 데이터베이스의 예

• Apache 2.0: Apache Cassandra, Apache CouchDB

• Mozilla 퍼블릭 라이센스: RabbitMQ

• BSD: Redis

• GPL 3.0: Neo4j

• 독점: IBM Db2, Microsoft SQL Server

배경 지식을 위한 간략한 역사

2000년대 후반, 대부분의 초기 데이터베이스 공급업체는 채택과 개발자 마인드 공유에 쉽게 접근하기 위해 '오픈 소스'로 시장에 진출했습니다. Mongo Inc., Redis Labs, Elastic과 같이 이 진영에 속한 기업을 알 수도 있습니다. 이 회사들은 MongoDB, Redis, Elasticsearch와 같은 커뮤니티 프로젝트를 개발했지만, Enterprise 라이선스 버전, 관리형 클라우드 구현 또는 전문 서비스를 통해 투자를 수익화할 방법을 모색했습니다.

그러나 클라우드 컴퓨팅의 패러다임 변화로 인해 주요 공급업체가 이러한 기술을 일류 플랫폼 네이티브 매니지드 서비스로 쉽게 제공할 수 있게 되면서, 이러한 비즈니스 모델은 불안정해졌습니다. 이러한 서비스는 각 클라우드에서 보안, 규정 준수, 모니터링 및 로깅을 위한 강력한 통합 기능을 제공하지만 소프트웨어 제작자에게는 보상을 보장하지 않습니다.

최근 몇 년 동안 기업들은 시장 출시 경로를 재평가하고 있습니다. 이제 개발 투자를 보호하는 라이선스 모델을 채택하는 기업이 늘고 있습니다. 예를 들어, MongoDB, Redis Labs, Confluent는 정도의 차이는 있으나, 다른 회사가 보상 없이 서비스로 실행하지 못하도록 코드 일부의 라이선스를 변경했습니다.

“그럼 당신의 조언은 무엇입니까?” 좋은 질문입니다.

상용 데이터베이스와 오픈 소스 데이터베이스를 모두 사용해야 하는 데는 그럴 만한 이유가 있습니다. 중요한 것은 자신과 회사가 어떤 상황에 처하게 될지 알고 있어야 한다는 것입니다. 애플리케이션을 구축하기 전에 라이선스를 검토하여 프로젝트가 규정을 준수하는지 확인하고, 오픈 소스 프로젝트를 위한 라이선스를 선택하려는 경우 Github의 '라이선스 선택(Choose a License)' 웹페이지를 확인하세요.
소송당하고 싶은 사람은 없기 때문에, 한 가지 중요한 고려 사항은 라이선스입니다. 나머지 하나는 데이터 모델 계열이지만, 다른 이유가 있습니다. 애플리케이션을 구축할 때 데이터 모델 유형에 대해 잘 알면 작업에 적합한 도구를 선택하는 데 도움이 됩니다.

이제 라이선스에 대한 이해를 마쳤으므로 데이터베이스를 선택할 때 고려해야 할 또 다른 중요 고려 사항인 데이터 모델에 대해 이야기해 보겠습니다.

제가 IBM에 처음 입사했을 때, 업무에 빠르게 익숙해져야 했기 때문에 Martin Fowler의 NoSQL Distilled를 참고했습니다.

그의 글과 업계 전반에서 사람들은 데이터베이스를 문서, 키-값, 그래프, 관계형 및 와이드 컬럼 형식의 5가지 ‘데이터 모델’ 계열로 분류하는 경향이 있습니다. 다음은 사용 사례와 데이터베이스별 예시를 포함하여 각각에 대한 간략한 개요입니다. 이를 통해 데이터 세트와 비즈니스 요구 사항에 따라 어떤 데이터베이스가 필요한지 결정할 수 있습니다.

1. 문서

이 경우 데이터는 행과 열이 아닌 JSON과 유사한 문서에서 모델링됩니다. 이러한 데이터베이스는 본질적으로 트랜잭션 일관성보다 가용성을 중시합니다. 문서 데이터베이스는 단순성과 확장성은 물론 개발 과정에서 빠른 반복에 적합합니다.

비즈니스 사용 사례:

• 빠른 반복이 필요한 모바일 앱

• 이벤트 로깅, 온라인 쇼핑, 콘텐츠 관리, 심층 분석 처리

• 제품 속성이 포함된 소매 카탈로그

예시:

• MongoDB

• Apache CouchDB

• Firebase

2. 키-값 

이 유형의 모델은 데이터베이스의 각 항목이 해당 값과 함께 속성 이름(키라고 함)으로 저장되는 비관계형 데이터베이스의 가장 기본적인 유형을 나타냅니다.

비즈니스 사용 사례:

• 사용자 기본 설정 및 프로필 저장소

• 검색 데이터를 기반으로 한 제품 추천

• 장바구니

예시:

• DynamoDB

• Redis

• ETCD

3. 그래프

여기서 데이터는 정점과 모서리(값과 연결)로 모델링됩니다. 사람들이 정보를 생각하고 처리하는 방식과 유사하게, 그래프 데이터베이스는 개별 데이터 단위 간의 관계를 기억합니다. 이러한 데이터베이스는 데이터 및 관계의 지속성, 탐색 및 시각화를 보다 직관적으로 만듭니다.

비즈니스 사용 사례:

• 사기 탐지

• 실시간 추천 엔진

• Master Data Management

• 네트워크 및 IT 운영

• ID 및 액세스 관리

예시:

• Neo4j

• JanusGraph

• AWS Neptune

4. 관계형 

R.F.Codd가 IBM에 있는 동안 도입한 관계형 모델은 업계의 거물입니다. 데이터를 테이블에 행과 열로 저장하며, 분석 및 탐색을 위한 정교한 쿼리 엔진이 있는 경우가 많습니다. 관계형 데이터베이스는 트랜잭션 보장 및 ACID(원자성, 일관성, 격리, 내구성) 준수를 지원하는 반면, 다른 4개 계열에 있는 대부분의 데이터베이스는 최종적으로 일관성을 유지합니다.

비즈니스 사용 사례:

• 전자 상거래

• 전사적 자원 관리

• 고객 관계 관리

예시:

• PostgreSQL

• IBM Db2

5. 와이드 컬럼형

열 계열의 저장소를 사용하면 행 키, 열 이름, 셀 타임스탬프를 사용하여 매우 빠르게 데이터에 액세스할 수 있습니다. 이러한 유형의 데이터베이스의 유연한 스키마는 열이 레코드 간에 일관성이 있을 필요가 없으며, 모든 단일 레코드에 열을 추가할 필요 없이 특정 행에 열을 추가할 수 있음을 의미합니다. 와이드 컬럼 저장소는 Google의 BigTable 논문에서 파생되었습니다. 이러한 데이터 모델은 디스크의 데이터 압축이 개선되고 CPU가 더 효율적으로 사용되므로 데이터 웨어하우징 기술 및 분석 액세스 패턴과 더 관련이 있는 컬럼 지향 스토리지 모델과 혼동해서는 안 됩니다.

비즈니스 사용 사례:

• 보안 및 주식 시장 분석

• 클릭스트림 분석

• IoT 및 원격 측정

예시:

• Apache Cassandra

• DataStax Enterprise

• Google Cloud BigTable

간단히 요약하자면, 각 기본 데이터 모델에는 장단점이 있다는 것입니다(여기서는 표면적으로만 다루었습니다). 하지만 의심스러울 때는 PostgreSQL과 같이 실전에서 검증되고 널리 사용되는 모델을 선택하세요. 데이터 모델 계열의 원형에 대해 자세히 알아보려면 Martin Fowler의 책 NoSQL Distilled에서 특히 8~11장을 읽어보세요.

데이터베이스에 대해 자세히 알아볼 준비가 되셨나요?

휴! 여기에서는 내용을 짧게 다루었지만, 자세히 살펴보고 싶다면 시간을 투자할 만한 몇 가지 제안 사항을 소개합니다.

• 15분: Ben Anderson의 “How to Choose a Database”

• 15분: Ben Anderson과 Brad Nicholson의 “SQL vs. NoSQL Databases: What’s the Difference?”

• 3시간: Jepsen analyses of distributed systems safety

• 일주일: Martin Kleppman의 Designing Data-Intensive Applications.

구축을 시작하고 싶으신가요? IBM Cloud는 팀이 빠르게 움직일 수 있도록 지원하는 광범위한 관리형 데이터베이스 서비스 를 제공합니다.