올바른 데이터 아키텍처를 구축하는 5가지 원칙

견고한 아키텍처를 설계하는 것은 최신 애플리케이션 구축에 있어서 가장 어렵지만, 가장 중요한 부분이기도 하다. 
 

합리적인 데이터 아키텍처를 만들지 못하면 애플리케이션에 많은 문제가 발생한다. 성능이나 데이터 무결성, 데이터 주권 및 안전, 확장성 문제가 대표적이다. 데이터 아키텍처가 부실하면 애플리케이션은 물론 이를 사용하는 기업까지 부실해진다.

적절한 데이터 아키텍처 구축은 모든 최신 아키텍처를 오래 안정적으로 운영하는 데 필수적이다. 애플리케이션 현대화 작업에 도움이 되는 데이터 아키텍처 설계(혹은 재설계) 원칙 5가지를 소개한다. 

1. 적절한 종류의 데이터베이스를 사용할 것 

데이터 아키텍처 설계에서 가장 중요한 것은 데이터 저장 및 접근에 필요한 데이터베이스의 종류를 파악하는 것이다. 사용해야 할 데이터베이스 종류를 결정하려면 다음과 같은 사항을 고려해야 한다.
 

• 저장할 데이터가 고도로 구조화된 데이터인가, 단순 키 값 데이터인가?
• 데이터 유지 기간이 영구적인가, 일시적인가?
• 데이터 접근이 무작위인가, 순차적인가?
• 고정 스키마나 유연 스키마를 사용하는가, 단순 플랫 파일인가?
• SQL 질의를 지원하는 관계형 데이터베이스를 사용해야 하는가? 

답변에 따라 SQL 데이터베이스, 단순 키 값 저장소, 메모리 상주 캐시, 단순 개체 저장소, 혹은 고도로 구조화된 데이터 저장소를 선택할 수 있다.

선택한 데이터베이스 종류에 따라 데이터베이스의 궁극적인 기능과 해당 애플리케이션 사용례에서의 성능 수준이 결정된다. 확장성이나 가용성처럼 애플리케이션에 필수 불가결한 요소는 데이터베이스 종류에 따라 크게 달라진다. 

2. 데이터를 적절한 장소에 저장할 것

‘데이터를 어디에 저장해야 하는가’라는 질문은 매우 단순하지만 중요하다. 데이터 저장 장소는 데이터와 애플리케이션에 따라 프론트엔드에 위치할 수도, 백엔드에 위치할 수도 있다. 또한 사용자가 로컬에 저장할 데이터와 최대한 많은 사용자와 공유해야 하는 데이터처럼 사용 방식에 따라서도 장소가 달라진다. 

대부분 데이터는 백엔드에 저장한다. 단, 반드시 엣지나 클라이언트에 저장해야 하는 데이터도 있다. 성능, 가용성, 신뢰성, 확장성 최적화를 위해 데이터를 프론트엔드에 저장해야 하는 경우도 있다. 

3. 처음부터 확장을 염두에 둘 것 

오늘날 애플리케이션은 증가하는 사용자 수요에 맞춰 확장할 수 있어야 한다. 모든 기업과 모든 애플리케이션에 해당하는 중요한 요소다.

확장 가능한 애플리케이션을 구축할 때 가장 어려운 부분은 데이터 저장소 확장이다. 데이터 저장소 확장은 사용자 기반이 증가하면서 데이터 저장 용량을 늘리는 경우나, 성능 저하 없이 애플리케이션 동시 사용자 수를 늘리는 경우에 필요하다. 어느 상황이든 애플리케이션 설계 단계부터 계획하지 않으면 확장이 어렵다. 

하지만 대부분 애플리케이션 아키텍처는 데이터 확장을 나중 일로 미룰 수 있는 부차적인 요건으로 여기는 경향이 있다. 애플리케이션 개발자가 기본 애플리케이션 아키텍처를 설계한 후에 데이터 확장을 생각하는 것이다.

데이터 아키텍처에 맞춰 억지로 확장하는 것은 데이터 집합의 규모가 클수록 쉽지 않다. 확장성 구축이 가장 쉬운 시점은 시작 단계, 즉 애플리케이션 확장이 필요하기 전이다. 나중으로 미루면 확장이 더욱 어려워지고 대대적인 데이터 리팩터링 작업 없이 불가능할 수도 있다. 

4. 데이터를 여러 서비스에 분산할 것

여러 클라우드 전문가는 대형 애플리케이션용 데이터 집합 관리에 중앙집중형 모델이 적합하다고 말한다. 데이터를 중앙집중화해야 머신러닝 같은 고급 애널리틱스를 쉽게 적용해 데이터에서 유용한 정보를 더 많이 도출할 수 있다는 주장이다.

그러나 이 전략은 잘못됐다. 중앙집중형 데이터는 쉽게 확장할 수 없다. 오히려 개별 서비스 내부에 데이터를 분산해서 저장하는 것이 가장 효과적인 데이터 확장 방법이다. 분산 서비스가 수십 개에서 수백 개로 구성된 애플리케이션이라면 데이터도 수십 곳에서 수백 곳에 나누어 저장하는 것이다.

분산형 모델은 확장이 쉽고 전체 서비스 소유권 모델을 지원한다. 서비스 소유권 모델은 개발팀이 더욱 독자적으로 작업하고, 서비스 간 보다 탄탄한 SLA(Service Level Agreement)를 구축하는 방법이다. 결과적으로 데이터 변경의 안전성과 효율성이 높아지고 고품질 서비스를 촉진한다.

애널리틱스나 머신러닝을 전체 데이터에 적용해야 하는 상황에도 분산형 데이터 모델을 추천한다. 이 경우 데이터를 효과적으로 활용하기 위해서는 관련 데이터 복사본을 백엔드 데이터 웨어하우스 시스템에 전송해야 한다. 해당 데이터 웨어하우스 시스템에서 데이터를 애널리틱스 목적에 맞게 적절히 구조화하고, 이를 애널리틱스 및 머신러닝 알고리즘에 적용하는 것이다. 알고리즘이 적용된 데이터 웨어하우스는 개별 서비스 내에 저장된 애플리케이션 데이터와 별도로 구별된다.

5. 데이터를 지리적으로 분산할 것

마지막으로 데이터의 사용 주체와 지리적 위치를 결정해야 한다. 데이터 및 사용자 위치를 결정하는 것은 점점 중요한 요소로 자리 잡고 있다. 글로벌 상거래로 인해 비즈니스 기회가 늘어나지만 국가별 데이터 관리 정책이 달라 전 세계적인 데이터 관리가 어렵기 때문이다.

따라서 데이터 아키텍처를 만들기 전에 다음과 같은 사항을 고려해야 한다.
 

• 데이터를 전 세계에서 접근하도록 설계하는 것이 중요한가? 아니면 지역 버전의 데이터가 비즈니스에 더 중요한가? 예컨대 미국과 독일에서 이용 가능한 데이터가 같은가, 다른가? 여러 애플리케이션 사례를 볼 때 2가지 모델을 조합하는 것이 중요하다. 광역화가 필요한 데이터와 지역화가 필요한 데이터를 구별하면 문제없이 조합할 수 있다. 

 

• 저장 가능한 데이터의 종류와 위치에 지역별로 제한이 있는가? 사용자가 거주 국가 외부로 데이터를 반출하지 못하도록 제한하는 지역이 있고, 국경 및 지역 경계를 넘어 이동할 수 있도록 허용하는 지역이 있다. 개인정보보호 정책이 다른 지역보다 상대적으로 엄격한 곳도 있다. 데이터의 어떤 부분에 어떤 정책이 적용되는지를 살펴봐야 한다. 

 

• 여러 지역에서 접근하는 데이터의 경우, 각 지역에 정확히 같은 데이터가 표시되는 것이 얼마나 중요한가? 즉, 지역 간 데이터를 정확히 동기화해야 할 필요가 있는가? 동기화 모델에 따라 데이터 집합에 가해지는 부담도 달라진다. 최종 일관성 모델(eventual consistency model)의 성능은 ACID(Atomicity, Consistency, Isolation, Durability)를 준수하는 트랜잭션 무결성 모델과 성능 특성이 매우 다르다. 

답변에 따라 데이터를 전 세계적으로 제한 없이 제공해야 하는지, 일정 지역에서만 제공해도 되는지, 해당 데이터를 사용할 수 있는 곳과 불가능한 곳은 어디인지, 지역 간 데이터를 언제 어떻게 동기화할 것인지 등을 결정할 수 있다.

데이터 아키텍처는 확장성, 가용성, 접근성이 높은 최신 애플리케이션 설계에 필수다. 데이터 아키텍처가 잘못되면 확장성과 가용성 문제는 물론이고 준법 문제까지 일으킬 수 있다. 애플리케이션 규모가 커진 후에 데이터 아키텍처를 변경하는 것은 어렵고 골치 아픈 일이다. 따라서 사전에 핵심 데이터 요건을 해결하는 것이 훨씬 쉬우며, 데이터 아키텍처를 설계하는 과정에서 앞서 살펴본 5가지 원칙을 따르면 심각한 문제를 예방할 수 있다. editor@itworld.co.kr