Quick Overview with ChatGPT 🤖 모바일 애플리케이션과 클라우드 컴퓨팅의 발전으로 기업은 더 복잡한 애플리케이션을 구축하고 관리하고 있습니다. 포스트그레SQL 같은 관계형 데이터베이스는 트랜잭션의 일관성을 유지하며 현대 애플리케이션에서 많이 사용됩니다. 대규모 시스템에서는 성능 유지를 위해 수직 및 수평 확장을 고려해야 하며, 특히 샤딩 기술이 효과적입니다. |
모바일 애플리케이션과 클라우드 컴퓨팅이 부상하면서 많은 기업이 전통적인 클라이언트-서버 모델에서 익숙했던 것보다 더 복잡한 애플리케이션을 구축, 배포, 관리하게 되었습니다. 현대 애플리케이션의 아키텍처는 데이터와 인프라, 2가지 측면에서 다양합니다.
노SQL(NoSQL) 데이터베이스, 애저 블롭 스토리지(Azure Blob Storage)와 같은 클라우드 객체 저장소는 현대 웹 설계의 초석이 되었지만, 많은 애플리케이션 기능은 트랜잭션의 원자성과 일관성을 보장하기 위해 관계형 데이터베이스를 사용합니다. 포스트그레SQL(PostgreSQL)은 유연함, 확장의 용이함, 탄탄한 개발자 커뮤니티와 같은 여러 이유로 현대 앱의 RDBMS로 광범위하게 사용되며, 기업이 새로운 기능을 신속하게 배포할 수 있도록 해줍니다.
대규모 애플리케이션을 위한 데이터베이스 설계
데이터베이스 관리자(DBA)는 업타임, 보안, 성능을 관리해야 하는 과제에 직면합니다. 데이터 웨어하우스, 금융 시스템 또는 고객 관계 관리 시스템과 같은 일상적인 시스템도 다루기가 어려운데, 주요 웹사이트 또는 고객 대면 애플리케이션의 기반이 되는 데이터베이스와 같은 대규모 시스템에는 또 다른 접근 방식이 필요합니다. 포스트그레SQL은 비용과 유연함을 이유로 선호되는 경우가 많지만 대규모에서 성능을 유지하기 위해서는 구체적인 전략이 필요합니다. 이 백서에서는 확장 가능한 시스템을 구축하기 위한 몇 가지 접근 방식을 살펴보겠습니다.
시스템 확장에는 크게 수직 확장과 수평 확장, 2가지 접근 방식이 있습니다. 수직 확장은 하드웨어에 CPU, 메모리, IO 리소스를 더 추가하는 방식입니다. 효과적일 수 있으나 추가할 수 있는 하드웨어의 양에 한계가 있고, 특히 클라우드와 온프레미스의 초대형 서버의 경우 비용이 기하급수적으로 증가합니다. 수평 확장은 일반적으로 웹 서버와 같이 애플리케이션에 영향을 미치지 않으면서 부가적인 인스턴스를 추가할 수 있는 무상태(non-stateful) 애플리케이션에 효과적입니다. 데이터베이스 워크로드의 수평 확장은 매우 강력하지만 신중한 계획이 필요합니다.
🤓데이터베이스 용어 정리
-테이블 파티셔닝(Table Partitioning) : 하나의 물리적 테이블에 대해 여러 개의 가상 테이블을 생성하는 기술입니다. 테이블은 일반적으로 파티셔닝 키(보통 날짜 범위지만 다른 데이터 값일 수도 있음)라는 하나의 열을 기준으로 분할됩니다. 이 패턴은 예를 들어 데이터 웨어하우스 팩트 테이블과 같은 큰 테이블에서 인덱스와 통계 유지관리를 더 효율적으로 하기 위해 일반적으로 사용됩니다. 또한 파티셔닝으로 특정 유형의 쿼리(특히 파티셔닝 키를 기준으로 필터링하는 쿼리)의 성능을 높일 수 있습니다.
-샤딩(Sharding) : 샤딩은 테이블 파티셔닝과 비슷한 개념이지만 데이터가 하나의 데이터베이스가 아닌 여러 데이터베이스에 걸쳐 분할되는 방법입니다. 이 개념은 거의 무한한 수평 확장을 가능하게 해주지만, 신중한 계획(스키마 설계)과 몇 가지 인프라 구성요소(예를 들어 샤드 맵 데이터베이스)가 필요합니다. 샤딩은 대규모 시스템에 일반적으로 사용됩니다.
-테넌트(Tenant) : 일반적으로 테넌트는 내부 또는 외부 고객이라고 할 수 있습니다.
-싱글 테넌트(Single-tenant) : 싱글 테넌트 데이터베이스 또는 시스템은 각 고객에게 완전한 전용 리소스 집합이 제공되는 아키텍처입니다. 이 아키텍처는 보안 및 성능 관점에서 간편하지만 비용이 높고 고객 수가 많아질 경우 확장이 쉽지 않습니다.
-멀티 테넌트(Multi-tenant) : 멀티 테넌트 아키텍처에서는 고객 데이터 간에 일정 수준 리소스가 공유됩니다. 이는 여러 고객의 데이터가 동일한 테이블에 존재함을 의미할 수 있지만, 비즈니스 및 규정 요구사항에 따라 데이터 보호를 위한 행 수준 보안을 제공하거나 덜 복잡한 데이터베이스 설계를 사용할 수 있습니다.
|
테이블 파티셔닝은 데이터 웨어하우스와 같은 대규모 시스템에 일반적으로 사용되는 기법입니다. 테이블을 가상 파티션으로 분할함으로써 재구성, 통계 업데이트와 같은 작업의 영향을 줄일 수 있습니다. 파티셔닝은 본질적으로 쿼리 성능에는 도움이 되지 않으므로 대규모 시스템에서는 샤딩이 더 나은 방법입니다.
고객 대면 애플리케이션을 위한 데이터베이스를 설계하고 구축하는 작업은 전통적인 클라이언트-서버 데이터베이스를 만드는 것과는 다릅니다. 클라이언트-서버 환경에서 워크로드는 일반적으로 완전히 예측 가능합니다. 애플리케이션 서버의 수와 크기에 따라 워크로드 수신에 일정한 제한이 적용되기 때문입니다. 고객 대면 시스템의 경우 사용률의 변동 폭이 훨씬 더 클 수 있습니다(예를 들어 도박 또는 티켓 사이트를 지원하기 위한 애플리케이션).
이런 애플리케이션은 피크 기간에 막대한 수요가 몰리고 그 외의 시간에는 사실상 아무런 활동이 없을 수 있습니다. 이 설계 패턴은 특히 테이블 파티셔닝을 사용해서 테이블을 여러 가상 테이블로 분할한 경험이 있는 DBA에게 익숙할 수 있습니다. 데이터베이스 샤딩은 여러 데이터베이스를 사용하는 비슷한 개념입니다.
대규모 시스템에 샤딩 사용하기
더 나은 접근 방법은 샤딩을 사용해 여러 인스턴스에 걸쳐 데이터베이스를 분할하는 것입니다. 이 경우 거의 무한대로 확장이 가능합니다. 그러나 여러 인스턴스에 걸쳐 데이터베이스를 분할하기 위해서는 광범위한 계획과 사전 검토, 그리고 적절한 개발 툴이 필요합니다. 예를 들어 이 패턴에서는 쿼리를 적절한 파티션 또는 샤드로 라우팅하기 위한 명령 및 제어 데이터베이스가 필요합니다. 비즈니스 요구사항 및 고객 유형에 따라 각 고객별로 전용 파티션을 만들면 면밀하게 성능을 제어할 수 있습니다. 또는 고객 그룹을 성능 요구사항이 낮은 하나의 데이터베이스로 풀링하는 방법도 있습니다.
멀티 테넌트 데이터베이스 관리
시스템 복잡성의 전형적인 예로 멀티 테넌트 시스템이 있습니다. 여러 형태가 있지만, 기본적인 예로 온라인 소매점의 계정 관리 시스템을 들 수 있습니다. 이 온라인 소매점에는 수백만 개의 계정이 존재할 수 있으며 범위를 사용해서(예를 들어 Node1에는 CustomerID 1 ~ 1,000,000, Node2에는 1,000,001~ 2,000,000 등) 여러 데이터베이스에 걸쳐 이런 계정을 분할하는 것이 효율적인 접근 방법일 수 있습니다. 또 다른 방법은 각 고객에게 데이터베이스를 제공하는 방법으로, 이는 고유한 고객의 수가 훨씬 적은 B2B 시나리오에서 더 일반적입니다.
멀티 테넌트 데이터베이스 관리는 비즈니스 과제인 동시에 기술적 과제이기도 합니다. 가장 어려운 부분은 출시 후 몇 년이 지난 애플리케이션에 대한 비즈니스 요구사항을 파악하는 것입니다. 멀티 테넌시의 기본적인 패턴을 살펴봅시다.
샤딩된 데이터베이스, 샤딩된 스키마 : 이 패턴은 규모 측면에서는 가장 적합하지 않습니다. 사실상 모든 고객을 하나의 데이터베이스에 두므로 서로 다른 고객 데이터가 섞이게 됩니다. 데이터베이스를 구축하기만 하면 되므로 구현하기는 쉽습니다 그러나 한 고객의 데이터를 가져오려면 복잡한 보안 및 데이터 정리가 필요할 수 있다는 점에서 단점이 많으며 효과적으로 확장되지 않습니다.
여러 고객에 걸쳐 샤딩된 데이터베이스 : 이 샤딩 패턴은 개별 소비자가 고객인 비즈니스에 가장 적합합니다. 이 구현에서 가장 쉬운 패턴은 고객 ID 번호에 대해 범위 기반 파티셔닝 모델을 사용해서 각 샤드의 고객 수를 거의 비슷하게 맞추는 것입니다. 이 패턴을 사용하면 각 샤드의 성능이 비슷하므로 인프라 설계도 간소화할 수 있습니다.
고객별로 하나의 데이터베이스 : 이 패턴은 대부분의 고객이 B2B이고 크기가 동일한 대규모 앱에 가장 효과적입니다. 높은 데이터 격리 수준을 제공하므로 보안을 관리하기가 상대적으로 쉽습니다. 또한 각 고객의 데이터베이스를 해당 고객의 요구사항에 따라 확장할 수 있습니다. 쿠버네티스와 같은 컨테이너 기반 인프라에서는 이 패턴을 쉽게 구현할 수 있습니다. 더 전통적인 가상 머신 기반 인프라의 경우 대규모 고객 전용 VM 용량을 두고 소규모 고객에는 샤딩된 VM을 사용할 수 있습니다.
동일한 애플리케이션을 위한 여러 개의 데이터베이스를 관리할 경우 애플리케이션의 복잡성이 높아집니다. 이 샤딩 패턴을 구축하려면 애플리케이션 설계의 초기 단계에 계획해야 합니다. 하나의 컴퓨터에 모든 고객 데이터를 호스팅하는 경우 해당 컴퓨터에 더 큰 용량이 필요하고 단일 실패 지점이 발생합니다. 비용과 장기적인 성장 관점에서 샤딩을 사용해서 인프라를 효율적으로 관리하기 위한 확장성과 유연성을 확보하는 것이 합리적입니다.
2부에서는 멀티 테넌트 포스트그레SQL 데이터베이스 관리에 대해 살펴봅니다. 본 백서 원문은 퀘스트소프트웨어 홈페이지에서 다운로드할 수 있습니다.
포스트그레SQL 도입 및 데이터베이스 관리에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다. 😀
Quick Overview with ChatGPT 🤖
모바일 애플리케이션과 클라우드 컴퓨팅의 발전으로 기업은 더 복잡한 애플리케이션을 구축하고 관리하고 있습니다. 포스트그레SQL 같은 관계형 데이터베이스는 트랜잭션의 일관성을 유지하며 현대 애플리케이션에서 많이 사용됩니다. 대규모 시스템에서는 성능 유지를 위해 수직 및 수평 확장을 고려해야 하며, 특히 샤딩 기술이 효과적입니다.
모바일 애플리케이션과 클라우드 컴퓨팅이 부상하면서 많은 기업이 전통적인 클라이언트-서버 모델에서 익숙했던 것보다 더 복잡한 애플리케이션을 구축, 배포, 관리하게 되었습니다. 현대 애플리케이션의 아키텍처는 데이터와 인프라, 2가지 측면에서 다양합니다.
노SQL(NoSQL) 데이터베이스, 애저 블롭 스토리지(Azure Blob Storage)와 같은 클라우드 객체 저장소는 현대 웹 설계의 초석이 되었지만, 많은 애플리케이션 기능은 트랜잭션의 원자성과 일관성을 보장하기 위해 관계형 데이터베이스를 사용합니다. 포스트그레SQL(PostgreSQL)은 유연함, 확장의 용이함, 탄탄한 개발자 커뮤니티와 같은 여러 이유로 현대 앱의 RDBMS로 광범위하게 사용되며, 기업이 새로운 기능을 신속하게 배포할 수 있도록 해줍니다.
대규모 애플리케이션을 위한 데이터베이스 설계
데이터베이스 관리자(DBA)는 업타임, 보안, 성능을 관리해야 하는 과제에 직면합니다. 데이터 웨어하우스, 금융 시스템 또는 고객 관계 관리 시스템과 같은 일상적인 시스템도 다루기가 어려운데, 주요 웹사이트 또는 고객 대면 애플리케이션의 기반이 되는 데이터베이스와 같은 대규모 시스템에는 또 다른 접근 방식이 필요합니다. 포스트그레SQL은 비용과 유연함을 이유로 선호되는 경우가 많지만 대규모에서 성능을 유지하기 위해서는 구체적인 전략이 필요합니다. 이 백서에서는 확장 가능한 시스템을 구축하기 위한 몇 가지 접근 방식을 살펴보겠습니다.
시스템 확장에는 크게 수직 확장과 수평 확장, 2가지 접근 방식이 있습니다. 수직 확장은 하드웨어에 CPU, 메모리, IO 리소스를 더 추가하는 방식입니다. 효과적일 수 있으나 추가할 수 있는 하드웨어의 양에 한계가 있고, 특히 클라우드와 온프레미스의 초대형 서버의 경우 비용이 기하급수적으로 증가합니다. 수평 확장은 일반적으로 웹 서버와 같이 애플리케이션에 영향을 미치지 않으면서 부가적인 인스턴스를 추가할 수 있는 무상태(non-stateful) 애플리케이션에 효과적입니다. 데이터베이스 워크로드의 수평 확장은 매우 강력하지만 신중한 계획이 필요합니다.
🤓데이터베이스 용어 정리
-테이블 파티셔닝(Table Partitioning) : 하나의 물리적 테이블에 대해 여러 개의 가상 테이블을 생성하는 기술입니다. 테이블은 일반적으로 파티셔닝 키(보통 날짜 범위지만 다른 데이터 값일 수도 있음)라는 하나의 열을 기준으로 분할됩니다. 이 패턴은 예를 들어 데이터 웨어하우스 팩트 테이블과 같은 큰 테이블에서 인덱스와 통계 유지관리를 더 효율적으로 하기 위해 일반적으로 사용됩니다. 또한 파티셔닝으로 특정 유형의 쿼리(특히 파티셔닝 키를 기준으로 필터링하는 쿼리)의 성능을 높일 수 있습니다.
-샤딩(Sharding) : 샤딩은 테이블 파티셔닝과 비슷한 개념이지만 데이터가 하나의 데이터베이스가 아닌 여러 데이터베이스에 걸쳐 분할되는 방법입니다. 이 개념은 거의 무한한 수평 확장을 가능하게 해주지만, 신중한 계획(스키마 설계)과 몇 가지 인프라 구성요소(예를 들어 샤드 맵 데이터베이스)가 필요합니다. 샤딩은 대규모 시스템에 일반적으로 사용됩니다.
-테넌트(Tenant) : 일반적으로 테넌트는 내부 또는 외부 고객이라고 할 수 있습니다.
-싱글 테넌트(Single-tenant) : 싱글 테넌트 데이터베이스 또는 시스템은 각 고객에게 완전한 전용 리소스 집합이 제공되는 아키텍처입니다. 이 아키텍처는 보안 및 성능 관점에서 간편하지만 비용이 높고 고객 수가 많아질 경우 확장이 쉽지 않습니다.
-멀티 테넌트(Multi-tenant) : 멀티 테넌트 아키텍처에서는 고객 데이터 간에 일정 수준 리소스가 공유됩니다. 이는 여러 고객의 데이터가 동일한 테이블에 존재함을 의미할 수 있지만, 비즈니스 및 규정 요구사항에 따라 데이터 보호를 위한 행 수준 보안을 제공하거나 덜 복잡한 데이터베이스 설계를 사용할 수 있습니다.
테이블 파티셔닝은 데이터 웨어하우스와 같은 대규모 시스템에 일반적으로 사용되는 기법입니다. 테이블을 가상 파티션으로 분할함으로써 재구성, 통계 업데이트와 같은 작업의 영향을 줄일 수 있습니다. 파티셔닝은 본질적으로 쿼리 성능에는 도움이 되지 않으므로 대규모 시스템에서는 샤딩이 더 나은 방법입니다.
고객 대면 애플리케이션을 위한 데이터베이스를 설계하고 구축하는 작업은 전통적인 클라이언트-서버 데이터베이스를 만드는 것과는 다릅니다. 클라이언트-서버 환경에서 워크로드는 일반적으로 완전히 예측 가능합니다. 애플리케이션 서버의 수와 크기에 따라 워크로드 수신에 일정한 제한이 적용되기 때문입니다. 고객 대면 시스템의 경우 사용률의 변동 폭이 훨씬 더 클 수 있습니다(예를 들어 도박 또는 티켓 사이트를 지원하기 위한 애플리케이션).
이런 애플리케이션은 피크 기간에 막대한 수요가 몰리고 그 외의 시간에는 사실상 아무런 활동이 없을 수 있습니다. 이 설계 패턴은 특히 테이블 파티셔닝을 사용해서 테이블을 여러 가상 테이블로 분할한 경험이 있는 DBA에게 익숙할 수 있습니다. 데이터베이스 샤딩은 여러 데이터베이스를 사용하는 비슷한 개념입니다.
대규모 시스템에 샤딩 사용하기
더 나은 접근 방법은 샤딩을 사용해 여러 인스턴스에 걸쳐 데이터베이스를 분할하는 것입니다. 이 경우 거의 무한대로 확장이 가능합니다. 그러나 여러 인스턴스에 걸쳐 데이터베이스를 분할하기 위해서는 광범위한 계획과 사전 검토, 그리고 적절한 개발 툴이 필요합니다. 예를 들어 이 패턴에서는 쿼리를 적절한 파티션 또는 샤드로 라우팅하기 위한 명령 및 제어 데이터베이스가 필요합니다. 비즈니스 요구사항 및 고객 유형에 따라 각 고객별로 전용 파티션을 만들면 면밀하게 성능을 제어할 수 있습니다. 또는 고객 그룹을 성능 요구사항이 낮은 하나의 데이터베이스로 풀링하는 방법도 있습니다.
멀티 테넌트 데이터베이스 관리
시스템 복잡성의 전형적인 예로 멀티 테넌트 시스템이 있습니다. 여러 형태가 있지만, 기본적인 예로 온라인 소매점의 계정 관리 시스템을 들 수 있습니다. 이 온라인 소매점에는 수백만 개의 계정이 존재할 수 있으며 범위를 사용해서(예를 들어 Node1에는 CustomerID 1 ~ 1,000,000, Node2에는 1,000,001~ 2,000,000 등) 여러 데이터베이스에 걸쳐 이런 계정을 분할하는 것이 효율적인 접근 방법일 수 있습니다. 또 다른 방법은 각 고객에게 데이터베이스를 제공하는 방법으로, 이는 고유한 고객의 수가 훨씬 적은 B2B 시나리오에서 더 일반적입니다.
멀티 테넌트 데이터베이스 관리는 비즈니스 과제인 동시에 기술적 과제이기도 합니다. 가장 어려운 부분은 출시 후 몇 년이 지난 애플리케이션에 대한 비즈니스 요구사항을 파악하는 것입니다. 멀티 테넌시의 기본적인 패턴을 살펴봅시다.
샤딩된 데이터베이스, 샤딩된 스키마 : 이 패턴은 규모 측면에서는 가장 적합하지 않습니다. 사실상 모든 고객을 하나의 데이터베이스에 두므로 서로 다른 고객 데이터가 섞이게 됩니다. 데이터베이스를 구축하기만 하면 되므로 구현하기는 쉽습니다 그러나 한 고객의 데이터를 가져오려면 복잡한 보안 및 데이터 정리가 필요할 수 있다는 점에서 단점이 많으며 효과적으로 확장되지 않습니다.
여러 고객에 걸쳐 샤딩된 데이터베이스 : 이 샤딩 패턴은 개별 소비자가 고객인 비즈니스에 가장 적합합니다. 이 구현에서 가장 쉬운 패턴은 고객 ID 번호에 대해 범위 기반 파티셔닝 모델을 사용해서 각 샤드의 고객 수를 거의 비슷하게 맞추는 것입니다. 이 패턴을 사용하면 각 샤드의 성능이 비슷하므로 인프라 설계도 간소화할 수 있습니다.
고객별로 하나의 데이터베이스 : 이 패턴은 대부분의 고객이 B2B이고 크기가 동일한 대규모 앱에 가장 효과적입니다. 높은 데이터 격리 수준을 제공하므로 보안을 관리하기가 상대적으로 쉽습니다. 또한 각 고객의 데이터베이스를 해당 고객의 요구사항에 따라 확장할 수 있습니다. 쿠버네티스와 같은 컨테이너 기반 인프라에서는 이 패턴을 쉽게 구현할 수 있습니다. 더 전통적인 가상 머신 기반 인프라의 경우 대규모 고객 전용 VM 용량을 두고 소규모 고객에는 샤딩된 VM을 사용할 수 있습니다.
동일한 애플리케이션을 위한 여러 개의 데이터베이스를 관리할 경우 애플리케이션의 복잡성이 높아집니다. 이 샤딩 패턴을 구축하려면 애플리케이션 설계의 초기 단계에 계획해야 합니다. 하나의 컴퓨터에 모든 고객 데이터를 호스팅하는 경우 해당 컴퓨터에 더 큰 용량이 필요하고 단일 실패 지점이 발생합니다. 비용과 장기적인 성장 관점에서 샤딩을 사용해서 인프라를 효율적으로 관리하기 위한 확장성과 유연성을 확보하는 것이 합리적입니다.
2부에서는 멀티 테넌트 포스트그레SQL 데이터베이스 관리에 대해 살펴봅니다. 본 백서 원문은 퀘스트소프트웨어 홈페이지에서 다운로드할 수 있습니다.
포스트그레SQL 도입 및 데이터베이스 관리에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다. 😀