개발자

"클라우드 쓴다고 해도" DB 설계가 여전히 개발자에 중요한 이유

Matt Yonkovit | InfoWorld 2022.07.29
오늘날 소프트웨어 개발자에게는 많은 선택지가 존재한다. 다양한 툴과 서비스를 활용해 새로운 애플리케이션을 빠르게 만들어 전 세계 고객에게 서비스를 출시하고 이후 확장해서 늘어난 수요에 대응할 수 있다. 마이크로서비스 아키텍처와 애자일 개발은 고객 요구와 비즈니스 요구를 충족해야 할 때 기민하게 움직이면서 새로운 서비스를 가동할 수 있도록 한다.
 
ⓒ Getty Images Bank

데이터도 마찬가지다. 개발자는 자신의 애플리케이션에서 생성하는 데이터를 지원해야 하는데, 이는 곧 데이터베이스 구현을 의미한다. 데이터베이스 설계를 적절히 선택하느냐가 애플리케이션에서 큰 차이로 이어질 수 있다. 적절한 설계는 장기적으로 애플리케이션이 가용성과 성능, 확장성을 갖추도록 하는 데 도움이 된다. 그러나 개발자는 데이터베이스를 직접 구현하고 관리하기를 원하지는 않는다. 대다수 기업이 (IDC에 따르면 90%) 현재 데이터베이스와 데이터 워크로드를 클라우드로 옮기는 것도 이 때문이다.

이때 기업은 여러 옵션 중에서 선택할 수 있다. 관리형 서비스, 클라우드 기반 데이터베이스 설치, 서비스형 데이터베이스(DBaaS) 등이 포함된다. 이들 서비스를 제공하는 업체들은 하나 같이 데이터 관리 부담을 덜어주고 새로운 애플리케이션과 업데이트를 더 빠르게 제공해 개발자가 원하는 것을 누릴 수 있다고 주장한다. “스키마리스”, “완전 관리형”과 같은 홍보 문구를 보면 데이터베이스를 그냥 넘겨주면 될 것처럼 안일함에 빠질 정도다.

그러나 클라우드 기반 데이터베이스의 설계와 구현 방법의 선택 측면에서도 개발자의 책임은 전통적인 온프레미스 시스템에 대한 것과 다르지 않다. DBaaS 제품의 기본 설정이 자신의 애플리케이션에 맞을 것이라고 무작정 단정하지 말아야 할 책임도 포함된다.
 

적절한 데이터베이스 선택하기

따라서 개발자와 애플리케이션 설계자는 애플리케이션 프로젝트의 장기적인 미래를 내다보고 이러한 프로젝트가 갖게 될 기본적인 요구사항을 확실히 파악해야 한다.

가장 먼저 판단해야 할 것은 프로젝트에 사용할 데이터베이스 설계다. 현재 데이터베이스 종류가 매우 많아서 선택하기가 까다롭다. 예를 들어 DB 엔진 순위에 포함된 데이터베이스의 종류만 359개에 이른다. 따라서 자신이 이미 알고 있는 데이터베이스, 또는 다양한 요구사항을 충족할 것을 예상되는 데이터베이스를 선택하는 쪽으로 기울기 쉽다. 예를 들어 전에 몽고DB를 사용해 문제가 없었다면, 다음 프로젝트에서도 같은 데이터베이스를 사용하는 식이다.

그러나 한 애플리케이션에서 잘 작동한 데이터베이스가 다른 애플리케이션에서도 효과적일 것이라는 보장은 없다. 그래프, 시계열 데이터베이스와 같이 특정 사용 사례에 더 적합한 데이터베이스와 데이터 관리 접근 방식이 있고, 사용할 프로그래밍 언어나 소프트웨어 개발 리소스에 따라 다른 선택이 더 적절할 수도 있다. 적합하지 않은 데이터베이스를 억지로 사용할 수는 있겠지만, 잘못된 선택은 심각하게 성능을 저해하고 오히려 비용을 늘릴 수 있다.

적절한 데이터베이스를 선택하기 위해서는 애플리케이션 워크로드가 어떻게 작동하고 어떤 방식으로 증가하며 액세스 패턴이 어떻게 변화할지에 대한 이해가 필요하다. 어느 데이터베이스를 선택하든 규모가 커지면 더 많은 쿼리와 더 많은 저장된 데이터를 처리해야 한다. 처음부터 적절한 접근 방식을 택하면 이 데이터를 대상으로 더 많은 쿼리를 더 쉽게 처리할 수 있다. 이것을 무시하고 데이터베이스 서비스 업체에 관리를 맡기면 처음에는 괜찮을 수 있지만 이후 성능과 비용에서 예상치 못한 상황에 부닥칠 수 있다. 따라서 사전 계획에 충분한 시간을 들이는 것이 장기적으로는 큰 폭의 비용 절감을 얻는 방법이다.
 

데이터베이스 설계에서 고려해야 할 것들

스키마리스 방식은 많은 개발자에게 매력적이다. 데이터 정리를 데이터베이스 서비스 업체에 맡기고 직접 관여할 필요가 없기 때문이다. 그러나 실제로는 그렇게 되지 않는다. 모든 데이터베이스 제공업체(JSON을 사용하거나 객체를 추가하는 기능을 사용한 '스키마리스' 접근 방식을 제공하는 업체 포함)는 어떤 형태로든 스키마 검증을 권장한다. 스키마리스 데이터베이스는 정보를 비구조적 데이터로 저장하는데, 이 경우 규모가 증가함에 따라 성능과 비용에 큰 영향을 미치기 때문이다.

사소한 의사 결정도 데이터베이스의 규모가 커지면 큰 영향을 미칠 수 있다. 데이터 형식이 대표적이다. 애플리케이션에 거주 국가 등의 데이터를 입력 받는 양식이 있다고 하자. 이 경우 어떤 형식을 사용해야 할까?

국가 이름의 길이는 다양하므로 평균 12자 입력을 가정하자. 이 데이터를 UTF 문자 집합을 사용하는 변수 문자(varchar) 형식으로 저장할 경우 문자당 3바이트, 또는 전체 입력 기준 39바이트가 된다. 크게 느껴지지 않을 수 있지만 같은 필드에 int 또는 enum을 사용하는 경우와 비교해 보자. int의 경우 전체 입력 항목에 4바이트만 있으면 되고 enum은 불과 1바이트다. 1억 개의 데이터를 입력받는다고 했을 때, varchar 옵션은 3,700MB의 공간을 차지하는 반면 enum은 이보다 97.5% 줄어든 95MB만 있으면 된다.

저장하는 데이터의 크기는 단순히 디스크 공간을 늘리는 것이 아니다. 다뤄야 할 데이터가 많아지면 보통 메모리에서 데이터를 처리하기 위해 사용하는 머신 이미지도 커진다. 데이터에 대해 효율성이 떨어지는 접근 방식을 택할 경우 데이터 처리를 위한 CPU와 메모리 리소스까지 늘여야 하는 것이다. 디스크에 테라바이트 단위의 데이터를 저장하는 비용은 비교적 저렴하지만 CPU 및 계산 시간의 비용은 상당하다. 따라서 처음부터 가능한 한 가장 효율적인 접근 방식을 선택해야 한다.

그 외에, 데이터 액세스 패턴을 고려하는 것도 중요하다. 데이터를 검색하는 방법은 이후 데이터 설계에도 영향을 미친다. 애플리케이션에서 일반적인 검색 요청이 예상된다면 성능을 개선할 수 있는 인덱스를 생성할 수 있다. 마찬가지로, 시간이 지나면서 사용자 행동이 바뀌고 특정 쿼리의 사용 빈도가 더 높아지는 상황도 발생할 수 있다. 이 경우 현재 구현된 쿼리와 인덱스가 미래의 요구에 대응하지 못하게 되므로 이를 관리하기 위해서는 패턴을 재점검해야 한다.

물론 이런 미래의 요건까지 미리 고려해 데이터베이스 설계에 반영하는 것은 쉽지 않다. 이때는 가능한 한 예외적인 사례 또는 불확실한 요구 사항을 반영하려 하지 말고 최대한 단순하게 배포하는 것이 좋다. 이것이 오히려 더 일이 쉬워질 수 있다. 앞으로 언제든 데이터베이스 스키마 또는 배포를 확장할 수 있으므로 지금 당장은 미래의 요구사항에 너무 집착할 필요가 없다.
 

빌드하기 전에 고려해야 할 것

코딩을 시작하기 전에 결정하는 사항은 프로젝트가 진행되는 도중에 내리는 결정에 비해 확장성과 안정성에 훨씬 더 큰 영향을 준다. 따라서 데이터와 이 데이터를 관리하는 데 사용할 방법을 선택하는 데 있어 충분한 주의를 기울여야 한다.

모든 책임을 클라우드 서비스 또는 서드 파티 제공업체에 넘기기보다는 자신이 달성하고자 하는 목표와 이 목표에 이르기 위한 최선의 방법을 파악해야 한다. 외부 서비스를 사용한다고 해서 이런 방법에 대한 결정 책임까지 없어지는 것은 아니다. 유연성을 포기하는 대신 성능과 비용상의 이점을 얻는 것일 뿐이다. 따라서 단순히 클라우드 리소스를 더 추가하는 것은 확장을 위한 효율적인 방법이 아니다. 데이터베이스와 설계 선택은 새로운 애플리케이션 또는 서비스의 장기적인 성공에 영향을 미친다는 것을 명확히 이해해야 한다.
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.