마이크로서비스에 적합한 데이터베이스 선택하기

애플리케이션이 마이크로서비스로 리팩터링하기 시작하는 대부분의 애플리케이션과 비슷하다면, 아마도 하나의 대규모 관계형 데이터베이스로 작동하고 있다고 가정해도 무방할 것입니다. 더구나 이런 데이터베이스가 Oracle Database일 가능성은 거의 절반에 이르며, 나머지 지분은 DB2, SQL Server, Informix 같은 다른 관계형 데이터베이스나 MySQL, Postgres 같은 오픈 소스 데이터베이스들이 나눠 갖습니다. 실제로 (일반적으로 비용이 많이 드는) 엔터프라이즈 관계형 데이터베이스에서 벗어나는 것은 마이크로서비스로 리팩토링할 때 흔히 내세우는 이점 중 하나입니다.

이제 많은 마이크로서비스에서는 NewSQL이나 NoSQL과 같은 다른 유형의 데이터베이스를 선택하는 데, 여기에는 매우 합리적인 이유가 있습니다. 하지만 현재 사용하고 있는 관계형 데이터베이스를 한꺼번에 포기하는 것은 종종 무모한 결정일 수 있습니다. 대신, 기존 Java 코드를 리팩토링할 때 점진적인 접근 방식을 권장하는 것처럼, 데이터베이스를 변경하는 데 있어 좀 더 점진적인 접근법을 고려하는 것이 좋습니다.

그러나 권장하는 코딩의 점진적 접근 방식과 마찬가지로 데이터베이스 리팩토링의 점진적 접근 방식을 따를 때 가장 큰 문제는 어디서부터 시작해야 할지 결정하는 것입니다. 점진적 접근 방식을 결정한 후 가장 먼저 결정해야 할 것은 하나의 큰 데이터베이스를 사용할지 아니면 여러 개의 작은 데이터베이스를 사용할지 정하는 것입니다. 처음에는 말도 안 되는 소리처럼 들릴 수 있습니다. 물론 하나의 큰 데이터베이스를 원하지 않을 겁니다. 이건 모놀리스에 있는 것입니다! 그럼 먼저 무슨 뜻인지 설명해 드리도록 하겠습니다.

기본적으로 데이터베이스 서버와 데이터베이스 스키마를 구분하는 것부터 시작해야 합니다. Oracle이나 Db2 같은 엔터프라이즈 규모의 데이터베이스에 익숙한 분들에게는 당연한 이야기일 것입니다. 엔터프라이즈 환경에서는 보통 하나의 큰 Oracle 서버(또는 여러 작은 서버들로 구성된 RAC)가 있으며, 여러 팀이 각각 독립적인 데이터베이스(각각 별도의 스키마로 표현됨)를 이 서버에서 호스팅합니다. 이렇게 하는 이유는 라이선싱이 CPU별로 이루어지는 경우가 많기 때문이며, 회사는 비용 대비 최대한의 사용량을 얻고자 하기 때문입니다. 여러 팀을 하나의 큰 서버에 모으는 것이 이를 위한 한 가지 방법입니다. MySQL이나 PostgreSQLSQL 같은 오픈소스 데이터베이스에 익숙한 분들에게는 그리 일반적이지 않을 것입니다. 이런 구분이 그다지 필요하지 않기 때문입니다.

이것이 중요한 이유는 마이크로서비스를 위한 데이터베이스를 구축할 때 데이터베이스에서의 결합을 줄이거나 없애는 것이 중요하기 때문입니다. 하지만 이는 실제로는 데이터베이스 스키마 수준에서의 결합을 의미합니다. 동일한 정보, 즉 동일한 스키마 내의 동일한 테이블을 사용하는 두 개의 서로 다른 마이크로서비스가 있는 경우 문제가 발생합니다. 그림 1을 보면 무슨 뜻인지 알 수 있습니다.

모놀리식 애플리케이션에 해당하는 데이터베이스(모든 것이 서로 연결되어 뒤엉킨 '큰 진흙덩어리'라고도 함)는 모든 테이블을 서로 연결하는 하나의 큰 스키마를 가지고 있습니다. 이때 테이블을 분리하는 데 필요한 작업량이 엄청나게 많아집니다. 

그러나 마이크로서비스로 전환하면 서버 수준에서 하드웨어와 라이선스를 공유할 때 발생할 수 있는 문제가 훨씬 줄어든다는 점을 인식해야 합니다. 사실, 마이크로서비스로의 초기 리팩토링을 수행할 때, 새롭고 더욱 깔끔하게 분리된 스키마를 동일한 엔터프라이즈 서버에 유지하는 데는 많은 이점이 있습니다. 기업에서는 일반적으로 데이터베이스 백업 및 복원, 데이터베이스 서버 업데이트를 위한 절차를 이미 갖추고 있기에 팀에서 이를 활용할 수 있기 때문입니다. 

어떤 의미에서 엔터프라이즈 데이터베이스의 하드웨어 및 소프트웨어 제공과 관리를 통해 기업이 제공하는 것은 서비스형 데이터베이스(DBaaS)의 제한된 버전입니다. 이는 특히 모놀리스의 기능 영역을 좀 더 명확하게 분리하는 접근 방식과 잘 맞으며, 처음에는 '모듈러 모놀리스' 접근법을 사용하는 것입니다. 이는 그림 2에 나와 있습니다.

이 예시(진행 중인 리팩터링 작업을 보여 주기 위한 것)에서는 리팩터링된 애플리케이션의 특정 모듈에 해당하는 3개의 새 스키마(A, B, C)에 해당하는 테이블을 분리하여 데이터베이스가 어떻게 분할되었는지 확인할 수 있습니다. 이렇게 분리되면 별개의 마이크로서비스로 깔끔하게 분리할 수 있습니다. 그러나 D와 E는 여전히 리팩터링 중이며, 여전히 상호 연결된 테이블이 있는 단일 스키마를 공유하기 합니다.

결국 데이터베이스-서버 수준에서의 연결도 문제가 될 수 있습니다. 예를 들어, 엔터프라이즈 데이터베이스를 선택한다면 해당 데이터베이스의 사용 가능한 기능으로 제한됩니다. 관계형 모델에서도 모든 스키마가 모든 기능을 필요로 하는 것은 아니며, 기능에 따라서는 다른 서버에서 더 잘 지원되는 경우도 있습니다.(예를 들어, 더 나은 샤딩이 가능하다는 점이 NewSQL 데이터베이스를 사용하는 이유로 자주 언급됨) 마찬가지로 여러 마이크로서비스에서 공유하는 데이터베이스 서버를 업그레이드하면 여러 서비스가 한 번에 중단될 수 있습니다. 

하지만 문제는 이 결정은 미룰 수도 있는 사항이라는 것입니다. 프로젝트 시작 시점에 바로 내려야 하는 것이 아닙니다. 팀이 리팩터링을 처음 시작할 때 적어도 프로젝트의 초기 단계 동안 동일한 데이터베이스 서버를 유지하면 팀이 코드 및 데이터베이스 리팩터링에 필요한 경험을 쌓아 가면서 점진적으로 변경을 수행할 수 있습니다.

마지막 섹션에서 알 수 있듯이 리팩토링 프로세스를 진행할 때 데이터베이스 옵션에 대해 좀 더 신중하게 생각하는 것이 좋습니다. 모든 데이터 세트가 관계형 모델에 완벽하게 적합한 것은 아니기 때문입니다. 이러한 데이터 세트를 관리하기 위한 최선의 접근 방식을 결정하는 것은 '데이터베이스에 실제로 무엇을 저장하고 있는가?'라는 질문으로 귀결되는 경우가 많습니다.

수년간 기업들이 객체 관계형 매핑 프레임워크를 구축하고 유지 관리하며 종종 고생을 하는 것을 도왔지만, 실제로는 저장되는 데이터가 관계형 데이터 모델에 전혀 매핑되지 않는 경우가 많았습니다. 그러한 상황이 발생할 때마다, 관계형 모델을 '억지로 끼워' 맞추거나, 더 흔하게는 프로그램에서 무리한 방법을 사용해 코드가 관계형 데이터 저장소와 일치하도록 해야 했습니다.

하지만 이제는 복수 언어 지속성 선택의 시대로 진입함에 따라 이전에 내렸던 몇 가지 결정들을 다시 검토하고 더 나은 선택을 할 수 있게 되었습니다. 특히 관계형 모델이 최선의 선택이 아닌 것이 분명한 네 가지 사례를 살펴본 다음, 관계형 모델이 최선의 선택이지만 데이터를 다른 형식으로 변환하는 것이 올바른 접근 방식이 아니었던 경우를 살펴보고자 합니다.

엔터프라이즈 시스템의 지속성 코드를 살펴본 결과, 놀랍게도 실제로는 관계형 데이터베이스에 저장된 것이 직렬화된 Java 객체의 이진 표현이라는 사실을 발견한 적이 여러 번 있었습니다. '이진 대용량 객체(Binary Large Object)' 혹은 'Blob'이라 불리는 열에 저장되며, 이는 일반적으로 팀이 Java 객체를 관계형 테이블과 열에 매핑하는 복잡성에 좌절하여 포기한 결과입니다. Blob 스토리지에는 다음과 같은 몇 가지 단점이 있습니다. 열을 기준으로 쿼리할 수 없으며 속도가 느린 경우가 많습니다. Java 객체 자체의 구조 변경에 민감하므로 객체 구조가 크게 변경되면 이전 데이터를 읽지 못할 수 있습니다.

애플리케이션(또는 애플리케이션의 하위 집합)이 관계형 데이터베이스에서 Blob 스토리지를 사용하는 경우, 이는 이미 Memcached 또는 Redis와 같은 키-값 저장소를 사용하는 것이 더 나을 수 있다는 꽤 좋은 신호입니다. 반면에 한 발짝 물러나서 저장하고 있는 항목을 생각해 보는 게 좋을 수도 있습니다. 구조화된 Java 객체(아마도 심층적으로 구조화되었지만, 기본적으로 바이너리가 아닌)로 판명되면, Cloudant  또는 MongoDB같은 문서 저장소를 사용하는 것이 더 나을 수 있습니다. 또한 문서를 저장하는 방법(예를 들어 위에서 언급한 두 데이터베이스 모두 JSON 문서 저장소이며 JSON 구문 분석기는 널리 사용 가능하고 사용자 지정하기 쉬움)에 약간의 노력을 기울이면 스토리지 매커니즘이 훨씬 불투명한 Blob 스토어 방식에 비해 '스키마 드리프트' 문제를 훨씬 더 쉽게 처리할 수 있습니다.

몇 년 전 마틴 파울러(Martin Fowler)가 '엔터프라이즈 애플리케이션 아키텍처의 패턴(Patterns of Enterprise Application Architectures)'을 집필할 때, 많은 패턴에 대해 활발히 의견을 주고 받고 여러 차례 열띤 리뷰 회의를 가졌습니다. 특히 한 가지 패턴은 항상 유난히 눈에 띄었는데, 바로 활성 레코드 패턴이었습니다. Java 커뮤니티 출신이라 이 문제를 한 번도 접해본 적이 없었기 때문에 이상했습니다(마틴은 Microsoft .NET 프로그래밍 커뮤니티에서는 흔한 일이라고 확신했지만 말입니다). 하지만 특히 iBatis와 같은 오픈 소스 기술을 사용하여 Java를 몇 가지 구현하기 시작했을 때 정말 놀랐던 점은 객체가 단순할(플랫) 때 이를 사용하기에 가장 적합한 것 같다는 것이었습니다.

데이터베이스에 매핑하려는 객체가 다른 객체와의 관계 없이 완전히 완전히 단순하다면(중첩 객체 정도의 제한된 예외만 있는 경우) 관계형 모델의 모든 기능을 활용하지 못하고 있을 가능성이 높습니다. 실제로는 문서를 저장할 가능성이 훨씬 더 높습니다. 이러한 사례를 보면 팀은 고객 만족도 설문조사, 문제 티켓 등 종이 문서의 전자 버전을 그대로 저장하는 경우가 많습니다. 이러한 상황에서는 Cloudant 또는 MongoDB와 같은 문서 데이터베이스가 가장 적합할 것입니다. 코드를 해당 유형의 데이터베이스에서 작동하는 자체 서비스로 분리하면 대규모 엔터프라이즈 데이터베이스의 일부로 동일한 작업을 수행하는 것보다 코드가 훨씬 더 간단해지고 유지 관리가 더 쉬운 경우가 많습니다.

ORM 시스템에서 자주 보이는 또 다른 패턴은 '테이블의 참조 데이터를 메모리 캐시로 끌어오는' 조합입니다. 참조 데이터는 자주(또는 전혀) 업데이트되지는 않지만, 지속적으로 읽히는 데이터로 구성됩니다. 미국 주 또는 캐나다 주 목록이 좋은 예이며, 다른 예로는 의료 코드 또는 표준 부품 목록이 있습니다. 이러한 종류의 데이터는 GUI의 드롭다운을 채우는 데 자주 사용됩니다.

일반적인 패턴은 사용할 때마다 테이블(일반적으로 2열 또는 최대 3열 플랫 테이블)에서 목록을 읽는 것으로 시작하는 것입니다. 그러나 매번 그렇게 하면 성능이 너무 나빠지기 때문에, 대신 애플리케이션이 시작할 때 Ehcache 같은 인메모리 캐시로 읽어들입니다.

이런 문제가 발생할 때마다 더 간단하고 빠른 캐싱 메커니즘으로 리팩토링해야 합니다. 다시 말하면, 이것은 Memcached나 Redis가 완벽하게 합리적일 수 있는 상황입니다. 참조 데이터가 나머지 데이터베이스 구조와 독립적인 경우(그리고 기껏해야 느슨하게 결합되어 있는 경우가 많습니다) 데이터와 해당 서비스를 시스템의 나머지 부분과 분리하는 것이 도움이 될 수 있습니다.

저희가 작업했던 한 고객 시스템에서는 프로그램이 조작하는 개체를 생성하기 위해 6~7개 정도의 매우 복잡한 조인 쿼리가 필요한 복잡한 재무 모델링을 수행했습니다. 업데이트는 더욱 복잡했는데, 무엇이 바뀌었는지, 데이터베이스 내 내용이 우리가 만들고 조작한 구조와 여전히 일치하는지 확인하기 위해 여러 단계의 낙관적 잠금 검사를 결합해야 했습니다.

돌이켜보면, 저희가 하고 있던 일은 그래프로 모델링하는 것이 더 자연스러웠을 것이라는 점이 분명합니다. 이와 같은 상황(이 경우에는 각각 다른 유형의 주식과 부채로 구성된 펀드의 트랜치를 모델링하고 있었는데, 각 펀드의 가격은 서로 다른 통화로 책정되고 만기는 서로 다르며 각 평가에 대한 규칙은 서로 다릅니다)은 사용자가 실제로 원하는 작업을 쉽게 수행할 수 있는 데이터 구조, 즉 그래프를 위아래로 이동하고 그래프의 일부를 마음대로 움직일 수 있는 데이터 구조가 절실히 필요한 상황이라고 할 수 있습니다.

이 경우 Apache Tinkerpop 또는 Neo4J와 같은 솔루션이 좋은 접근 방식이 될 수 있습니다. 솔루션을 그래프로 직접 모델링함으로써 복잡한 Java 및 SQL 코드를 많이 피할 수 있었고 동시에 런타임 성능을 개선할 수 있었습니다.

특정 데이터 구조에 대해 NoSQL 데이터베이스가 올바른 논리적 접근 방식인 경우가 많지만, 관계형 모델의 유연성과 능력을 능가하기는 어려운 경우가 많습니다. 관계형 데이터베이스의 가장 큰 장점은 동일한 데이터를 다양한 목적에 따라 다양한 형태로 매우 효과적으로 '분할'할 수 있다는 점입니다. 데이터베이스 뷰 같은 트릭은 동일한 데이터를 여러 매핑할 수 있게 해주는데, 이는 복잡한 데이터 모델의 관련 쿼리 집합을 구현할 때 종종 유용합니다. 

NoSQL과 SQL의 비교에 대해 더 깊이 알고 싶다면 "SQL과 NoSQL 비교: 차이점은 무엇인가요?"를 참고하세요.

이전 글에서 설명한 것처럼 마이크로서비스의 '하한'이 해당 데이터에서 작동하는 관련 서비스 집합과 함께 집계로 그룹화된 엔티티 집합인 경우, 관련 쿼리 집합을 나타내는 뷰를 구현하는 것은 SQL을 사용하는 것이 가장 쉽고 간단한 경우가 많습니다.

이전 글에서 간단한 계정/라인 항목 예제로 이어진 고객 예시에서 이 사실을 처음 확인했습니다. 이 사례의 경우, 한 은행이 문서 지향 NoSQL 데이터베이스에서 이와 같은 간단한 모델을 작동시키기 위해 매우 열심히 노력했지만 CAP 정리에 의해 패배한 적이 있습니다. 하지만 팀은 잘못된 이유로 해당 데이터 모델을 선택했습니다. 그들은 아키텍처 일관성에 대한 잘못된 욕구 때문에 다양한 마이크로서비스에 모두 문서 지향 데이터베이스를 사용하기로 결정했습니다.

이 경우, ACID 모드의 모든 속성이 필요했지만 샤딩(예: 파티셔닝)은 필요하지 않았습니다. 기존 시스템은 관계형 모델에서 수년 동안 완전히 수용 가능한 수준의 성능으로 작동해 왔으며 엄청난 성장을 예상하지 않았기 때문입니다. 그러나 시스템의 핵심에는 ACID 트랜잭션이 필요하고 파티셔닝이 필요하지 않았지만, 시스템의 다른 모든 부분에 반드시 그런 것은 아니었습니다. SQL 데이터베이스의 뛰어난 기능이 몇 가지 있는데, ACID 트랜잭션도 그 중 하나입니다. 마이크로서비스 시스템에서는 이러한 ACID 트랜잭션이 작동하는 가장 작은 데이터 세트를 중심으로 그룹화하는 것이 일반적으로 올바른 접근 방식입니다.

그러나 SQL이 반드시 기존 SQL 데이터베이스를 의미하는 것은 아닙니다. 많은 마이크로서비스 아키텍처에서 SQL을 사용할 수 있고, 실제로 그렇게 하고 있지만, 마이크로서비스를 구현하는 많은 팀에게 유용한 선택이 될 수 있는 최소 두 가지 유형의 다른 데이터베이스에도 SQL이 구현되어 있습니다. 첫 번째는 MySQL 및 Postgres와 같은 오픈 소스 데이터베이스의 도메인인 '작은 SQL'입니다. 마이크로서비스를 구현하는 많은 팀에게 이러한 데이터베이스는 여러 가지 이유로 매우 합리적인 선택입니다.

1. 기존 애플리케이션을 마이크로서비스로 리팩토링하는 팀은 일반적으로 SQL 및 객체 관계형 매핑 프레임워크(예: Hibernate 또는 Spring Persistence)에 대한 경험이 있습니다. 마이크로서비스 접근 방식의 범위 내에서 이러한 지식을 활용하는 것은 확실히 합리적입니다.
2. 이러한 데이터베이스는 오픈 소스 커뮤니티와 이를 지원하는 많은 공급업체에서 매우 잘 지원되고 있습니다. 이에 대한 문서와 튜토리얼을 찾는 것은 비교적 쉽고, 이에 능숙한 개발자를 찾는 것도 비교적 쉽습니다.
3. 이러한 데이터베이스는 작고 가벼워서 컨테이너화하기 쉽고, 애플리케이션 코드에 사용하는 것과 동일한 GitOps 메커니즘을 통해 배포하고 업데이트할 수 있습니다.
4. 이러한 데이터베이스는 대부분 또는 모든 하이퍼스칼라 퍼블릭 클라우드의 SaaS 버전에서 지원됩니다.

이러한 '소규모 SQL' 데이터베이스 사용의 가장 큰 단점은 엔터프라이즈 데이터베이스가 지원할 수 있는 것과 동일한 수준의 규모(특히 샤딩과 관련하여)를 지원하지 않는 경우가 많다는 것입니다. 그러나 이 문제는 소규모 SQL 데이터베이스의 장점과 NoSQL 데이터베이스의 확장성을 결합한 새로운 데이터베이스 공급업체와 오픈 소스 프로젝트에 의해 훌륭하게 해결되었습니다. 종종 'NewSQL' 데이터베이스라고 불리는 여기에는 CockroachDB, Apache Trofidion 및 Clustrix가 포함됩니다.

모든 ACID 트랜잭션, 관계형 모델을 완벽하게 지원하는 SQL 엔진, 광범위한 확장 및 샤딩 기능이 필요한 경우 NewSQL 데이터베이스는 팀에 적합한 선택이 될 수 있습니다. 이러한 데이터베이스는 기존의 '소규모 SQL' 솔루션보다 설정 및 관리가 더 복잡한 경우가 많기 때문에 이러한 선택에는 대가가 따릅니다. 또한 이러한 데이터베이스에서는 기술을 갖춘 사람을 찾기가 더 어렵습니다. 하지만 그럼에도 불구하고 옵션을 검토할 때는 신중하게 고려해야 합니다.

코딩 문제로 가장할 수 있는 다양한 데이터베이스 모델링 문제를 둘러보았습니다. 이러한 특정 문제 중 하나 이상을 겪고 있다면 기존 엔터프라이즈 데이터 저장소를 분리하고 다른 유형의 데이터 저장소로 다시 구상하는 것이 더 나을 수 있습니다. 어떤 경우든 천천히 점진적으로 진행하라는 것이 저희의 조언입니다. 모든 애플리케이션에 모든 유형의 데이터 모델이 필요한 것은 아니며, 광범위한 규모로 구현하기 전에 시간이 지남에 따라 선택한 데이터베이스의 능력에 대한 기술을 쌓고 이해해야 한다는 점을 명심하세요.

마지막으로, 전체 마이크로서비스 접근 방식은 각 마이크로서비스를 구축하는 팀이 자신에게 적합한 데이터 저장소에 대한 결정을 스스로 내릴 수 있다는 아이디어를 기반으로 한다는 사실을 인식해야 합니다. 많은 사례에서 알 수 있듯이 우리가 직면한 가장 큰 문제는 단일 데이터 표현과 스토리지 접근 방식을 모든 상황에 적용하려는 것입니다. 

저는 팀이 NoSQL 데이터베이스를 사용하지 말았어야 하는 상황에서 CAP 정리의 현실을 처리해야 하는 것을 여러 번 보았습니다. 마찬가지로 NoSQL 데이터베이스에서 복잡한 보고를 수행하려는 시도는 종종 좌절감을 안겨줍니다. 반면에 우리가 살펴본 상황은 관계형 모델이 모든 것을 포괄하지 못한다는 점을 지적합니다. 다른 모델도 각자의 자리를 차지하고 있습니다. 저희가 드릴 수 있는 최선의 조언은 팀이 각 마이크로서비스에 적합한 모델을 선택하는 데 필요한 자율성을 확보하라는 것입니다.

IBM® Garage는 더 빠르게 움직이고, 더 스마트하게 작업하고, 혁신을 통해 중단 없는 업무 환경을 구축할 수 있도록 설계되었습니다.