NoSQL은 데이터베이스 데브옵스를 단순화합니다

귀하의 조직은 데이터베이스 DevOps를 단순화하고 싶으십니까?
데이터베이스가 빠른 혁신의 걸림돌이 되고 있나요?
데이터베이스 라이선스 비용을 수백만 $$나 절감하고 싶으신가요?

계속 읽어보세요!

데이터베이스 데브옵스의 현황

데이터베이스 데브옵스의 현황 SQL Server 전문가들 사이의 DevOps 도입률에 관한 설문조사입니다. 1,000명이 넘는 SQL Server 전문가들이 설문에 응답했습니다. 응답자들은 전 세계에서 참여했으며, 다양한 직무, 기업 규모, 산업군을 대표합니다.

설문조사 결과에서 몇 가지 좋은 발견이 있었습니다. 여기서 강조할 만한 몇 가지 주요 결과는 다음과 같습니다.

DevOps 프로세스에 데이터베이스 변경 사항을 통합하는 데 있어 가장 큰 과제는 여전히 애플리케이션 변경 사항과 데이터베이스 변경 사항을 동기화하는 것입니다.

또 하나...

전통적인 부서별 칸막이식 데이터베이스 개발에서 확인된 가장 큰 단점은 변경 사항을 도입할 때 배포 실패나 가동 중단 위험이 커진다는 점입니다. 그 뒤를 이어 느린 개발 및 릴리스 주기, 그리고 급변하는 비즈니스 요구사항에 신속하게 대응하지 못하는 문제가 있습니다.

그리고 또 하나…

데이터베이스 변경 사항 전달 속도를 높이고 개발자가 부가가치가 더 높은 작업에 집중할 수 있도록 하는 것이 데이터베이스 변경 자동화를 추진하는 주요 동인입니다.

여기서 강조된 과제들은 SQL 서버만의 맥락에서 언급된 것이 아니라, 모든 관계형 데이터베이스에 적용될 수 있습니다. 여러분이 오라클, 포스트그레스, MySQL, 마리아DB 또는 그 밖의 다른 관계형 데이터베이스를 사용하고 있더라도 이러한 문제들에 직면하게 될 것입니다. 그 이유는 무엇일까요?

관계형 데이터베이스가 데이터베이스 데브옵스(Database DevOps)에 잘 맞지 않는 이유는 무엇인가요?

애플리케이션이 RDBMS의 여러 테이블에 있는 데이터를 조작하는 것은 흔한 일입니다. 예를 들어, 주문을 할 때는 고객(Customer), 주문(Order), 상품(Product) 테이블을 사용할 수 있습니다. 각 테이블에는 데이터베이스에 특화된 표준 데이터 타입을 가진 여러 열이 있습니다. 테이블은 기본 키, 참조 키, 외래 키 제약 조건을 가질 수 있습니다. 관계형 데이터베이스를 사용하여 애플리케이션을 구축하는 개발자는 일반적으로 자바 개발자를 위한 하이버네이트(Hibernate)나 자바 지속성 API(JPA)와 같은 객체 관계형 매퍼(ORM)를 사용합니다. 다른 언어에도 이와 유사한 ORM들이 있습니다. ORM은 기저의 복잡한 데이터베이스 구조를 추상화하여 프로그래머가 자신의 프로그래밍 언어를 사용하여 자연스럽게 애플리케이션을 구축할 수 있도록 해줍니다.

ORM은 또한 영속성 제공자(persistence provider)를 사용하며, 애플리케이션이 기반 데이터베이스로부터 독립적일 수 있도록 해줍니다. 이 영속성 제공자는 언어 고유의 클래스와 데이터베이스 구조 간의 바인딩을 생성합니다. 예를 들어, 클래스를 하나 또는 여러 개의 테이블에 매핑하고, 언어 데이터 타입을 데이터베이스에 정의된 타입에 바인딩하며, 테이블 간의 관계를 포착합니다. 이론적으로 프로그래머는 애플리케이션에서 다른 RDBMS를 사용하기 위해 다른 영속성 제공자를 사용할 수 있습니다. 하지만 이는 실제 경험과는 거리가 멉니다!

데이터베이스 변경이 있으면 ORM 클래스를 업데이트해야 하며, 그렇지 않으면 애플리케이션이 작동하지 않을 수 있습니다. 예를 들어, 새 테이블을 추가하는 것은 새로운 Java 클래스를 의미하거나 기존 클래스를 업데이트해야 함을 의미합니다. 컬럼의 데이터 타입 변경은 클래스 정의를 업데이트해야 하며, 그렇지 않으면 애플리케이션이 컴파일조차 되지 않습니다. 새 컬럼을 추가한다는 것은 클래스에 새 필드를 추가하는 것을 의미합니다. 모든 변경 사항은 클래스를 업데이트하고 애플리케이션을 다시 패키징해야 합니다.

비즈니스의 진화하는 요구를 충족하기 위해 데이터베이스 구조의 변경은 항상 필요합니다. 그러나 DBA가 데이터베이스를 변경하고 ORM 클래스가 업데이트되지 않으면 괴리가 발생합니다. 애플리케이션 배포는 데이터베이스 스키마 업데이트와 조율되어야 합니다. 다음과 같은 도구들이 있습니다: 플라이웨이, Liquibase 그리고 애플리케이션과 데이터베이스 배포를 통합하는 다른 도구들도 있습니다. 하지만 개발자들은 대개 운영 데이터베이스에 직접 어떠한 변경도 가하는 것이 허용되지 않습니다. 이러한 단절은 애플리케이션이 작동하지 않고 비즈니스가 타격을 입는 결과로 이어질 수 있습니다. 데브옵스(DevOps) 관행은 애플리케이션을 구축하는 개발자와 데이터베이스 스크립트를 업데이트하는 DBA(데이터베이스 관리자) 간의 긴밀한 협업을 필요로 하므로 이러한 문제를 해결하는 데 확실히 도움이 될 수 있습니다.

그러나 설문조사 보고서에 따르면, 응답자 중 50% 이상이 현재 데브옵스를 도입하지 않은 것으로 나타났습니다.

데이터베이스 변경 사항을 데브옵스 프로세스에 통합한다고 하더라도 과제들은 존재합니다.

애플리케이션과 데이터베이스 변경 사항을 동기화하는 것, 즉 ORM 클래스를 백엔드 데이터베이스 구조와 동기화해야 하는 것이 가장 큰 과제입니다. DBA는 애플리케이션 개발에 최적화되지 않을 수도 있는 특정한 방식으로 데이터베이스를 구조화하려고 할 수 있습니다. 원활한 데이터베이스 데브옵스를 보장하기 위해 애플리케이션과 데이터베이스 개발 전반에 걸쳐 일관성을 적용하는 것이 그다음으로 중요한 과제입니다.

격리된 개발 방식은 비즈니스의 신속한 혁신과 가치 제공 능력에 심각한 문제를 야기합니다.

이 그림에서 볼 수 있듯이, 변경 사항 도입 시 발생하는 배포 실패, 느린 개발·출시 주기, 비즈니스 요구 사항에 대응하지 못하는 점 등이 단점의 60% 이상을 차지합니다.

데이터베이스 변경 사항의 전달 속도는 데이터베이스 데브옵스에서 가장 큰 관심사입니다.

그래서 무슨 일을 하세요?

NoSQL이 데이터베이스 DevOps를 어떻게 단순화하나요?

NoSQL 문서 데이터베이스는 데이터베이스 데브옵스를 간소화하는 데 도움이 됩니다!

NoSQL이 데이터베이스 데브옵스를 어떻게 단순화하나요?

• 스키마 유연성 개발자는 빠르게 변화하는 정형, 반정형 및 비정형 데이터를 저장할 수 있는 단일 데이터베이스가 필요합니다. NoSQL 문서 데이터베이스는 개발자가 JSON 데이터를 직접 조작하고 그로부터 의미를 도출할 수 있도록 허용함으로써 스키마 유연성을 제공합니다.
• 임피던스 불일치 없음 애플리케이션용 ORM이 없으므로 도메인 클래스와 데이터베이스 구조 간의 임피던스 불일치가 없습니다. 애플리케이션 코드만 업데이트하면 되며 스키마 변경과의 조율이 필요하지 않습니다.
• 확장성 – 보고서에서 언급된 단점 중 하나는 변화하는 비즈니스 요구사항에 적응하지 못한다는 점입니다. 이는 확장성이 주요 DevOps 과제임을 강조합니다. 데이터의 양, 쿼리의 수, 또는 애플리케이션을 지원하는 데 필요한 인덱스의 유형이 변경되면 데이터베이스는 그 변화를 수용할 수 있도록 변경되어야 합니다. 몇 주나 몇 달이 아니라 바로 오늘 말입니다! NoSQL 데이터베이스는 범용 하드웨어에서 실행되며 RDBMS의 스케일 업(scale-up) 방식과 달리 스케일 아웃(scale-out) 아키텍처를 가집니다. 샤딩(sharding)은 RDBMS의 확장성에 도움이 될 수 있지만, 이는 이제 처리해야 하는 추가적인 복잡성입니다.

자세히 알아보기 기업이 NoSQL로 전환하는 이유.

어느 NoSQL 데이터베이스 GE, Marriott, Verizon, United, LinkedIn, DIRECTV 및 많은 다른 사람들?

다른 것에는 어떤 것이 있나요? Couchbase의 장점?

• 동질 분산 아키텍처 – 마스터/슬레이브 없음
• SQL 유사 쿼리 언어 JSON 문서를 쿼리하기 위해
• vBucket을 사용한 자동 샤딩
• 메모리 우선 아키텍처 추가적인 캐싱 레이어의 필요성을 줄여줍니다
• 데이터센터 간 복제
• 다중 SDK
• 서버 또는 모바일 기기의 데이터베이스, 그들 사이에 완벽한 동기화가 이루어진 상태로
• 다른 컨테이너 오케스트레이션 프레임워크

NoSQL은 결코 만병통치약이 아닙니다. 복잡한 트랜잭션 로직이나 실시간 데이터 웨어하우징이 필요한 시스템을 구축하는 경우 RDBMS가 더 나은 선택일 수 있습니다. 하지만 NoSQL은 확장성과 민첩성 문제를 해결하고 데이터베이스 DevOps를 단순화합니다.

관계형 데이터베이스에서 NoSQL로 마이그레이션하는 방법에 관한 훌륭한 영상입니다:

메리어트가 관계형 데이터베이스에서 NoSQL로 전환한 이유를 보여주는 또 다른 흥미로운 동영상입니다:

더 많은 동영상을 이용할 수 있습니다 카우치베이스 커넥트 2016.

그리고 몇 가지 관련 블로그가 더 있습니다:

• 관계형 데이터베이스에서 NoSQL로의 전환: 시작하는 방법 (백서)
• 오라클 데이터베이스에서 코치베이스로 전환하기
• MySQL에서 Couchbase로 이전하기
• SQL Server에서 Couchbase로 전환 – 파트 1 (데이터 모델링), 제 2부 (데이터 마이그레이션), 파트 3(예정)
• MongoDB에서 Couchbase로 이전하기
• Mongoose REST API를 사용하는 MongoDB를 Ottoman을 사용하는 Couchbase로 마이그레이션하기
• 관계형 데이터베이스에서 Couchbase로 마이그레이션하기
• 기업이 오라클을 Couchbase로 교체하는 상위 5가지 이유

문의하기:

• 카우치베이스 개발자 포털
• 카우치베이스 포럼
• @couchhasedev 그리고 카우치베이스