대용량 시스템을 위한 데이터베이스 아키텍쳐(Query Off Loading & Sharding)

RDBMS는 2차원 테이블 구조의 데이타를 KEY 값을 중심으로 여러개의 컬럼으로 저장되며, 저장된 각각의 row는 다른 테이블의 로우와 관계를 가질 수 있다. 대용량 처리를 위해 고려할만한 아키텍처에  Query Off loading과 Sharding이라는 기법이 있다.

Query off Loading 처리량을 증가시키기 위한 설계기법 DB 트랜젝션의 70~90%는 대부분 READ성이 많다. 그러므로 READ 성 트랜잭션과 나머지 트랜잭션(CREATE, DELETE, UPDATE)로 분리한다. 애플리케이션은 Master DB에 쓰기 작업(UPDATE)을 하고 Master DB의 내용을 중간의 Staging DB에 저장. 이 내용은 N개의 Slave  DB에 복제한다. 트랜젝션이 많은 읽기 작업은 Slave DB에서 작업한다. Application을 DB에 대한 쓰기 로직과 읽기 로직을 분리해서 구현해야 하며,이 분리된 로직은 쓰기 DB로 접근하기 위한 DB Connection과 읽기 DB로 접근하기 위한 DB Connection을 이용해서 접근 읽기 DB의 경우에는 N개의 Slave DB로 부터 읽기 때문에, Application이 이 N개의 Slave DB에 대한 요청을 Load Balacing을 해야 한다. 특정 Slave DB 장애시 다른 Slave DB 인스턴스에 접근을 할 수 있도록 HA (High Availability) 기능을 제공해야 한다. Connection Pool 자체에 Load Balancing과 HA 기능을 가지고 있는 Connection Pool을 이용하거나 또는 JDBC Driver와 같이 DBMS용 Driver 자체에 Load Balancing과 HA 기능을 사용 Staging DB 역할 Staging DB는 Slave DB로 복제하기 위한 중간 경유지 역할 Master DB에서 Slave DB로 바로 복제를 하게 되면, Master DB가 쓰기 트렌젝션 이외에 복제에 대한 부분을 처리해야 하기 때문에 성능 저하를 유발할 수 있다. 이를 방지 하기 위해서 중간에 Staging DB를 넣는 것 CDC (Change Data Capture) 기술 DBMS들은 공통적으로 Create/Update/Delete와 같은 쓰기 관련 작업을 수행할때, 데이타를 실제로 저장하기 전에 먼저 해당 작업에 대한 request를 BackLog라는 곳에 저장 실제로 데이타를 쓰기전에 장애가 났을때, restart하면서 이 BackLog를 읽어서 복구를 위한 용도로 사용 CDC는 이 Back Log를 이용해서 데이타를 복제하는데, Source DB로 부터 이 Back Log를 읽어서, 복제를 하고자하는 Target DB에 replay 하는 형식 대표적인 CDC 제품으로는 Oracle의 Golden Gate, Quest의 Share Flex가 있고, 오픈소스 제품으로는 Galera가 있다.

Sharding Sharding은 데이타베이스의 용량 한계를 극복하기 위한 기술 인터넷의 발전등에 따라서 저장해야 하는 데이타의 양도 급격하게 늘어났다. 데이타 베이스 시스템은 이러한 용량 증가를 따라가지 못했다. 이로 인해 데이터를 여러개의 데이터베이스에 나눠담는 아키텍처가 Sharding이다. Sharding은 데이터를 분산하는 방식에 따라서 Vertical(수직적) Sharding과 Horizontal(수평적) Sharding으로 나뉘어진다. 데이타를 분산 저장할때 위와 같이 meaningful한 데이터를 사용하는 경우에는 데이터의 몰림 현상이라는 것이 발생할 수 있다. meaningful한 데이타를 KEY로 사용할 경우에는 데이터 몰림현상을 고려하여 각 Shard 서버의 성능을 비 대칭적으로 설계 Vertical Sharding Vertical Sharding은 연속된 데이타에 대해서 범위별로 데이타를 나누는 방법 horizontal Sharding Horizontal Sharding은  연속된 키가 아니라 “Category”와 같은 종류에 따라서 데이타를 수평적으로 분리하는 방법 Hash Sharding 방식 meaningful 하지 않은 KEY를 사용해서 Sharding을 할 수 있다. 10개의 Shard를 갖는 데이타 베이스에서, 사용자 레코드를 등록할때, KEY를 Sequence를 이용해서 순차적으로 부여한다. 첫번째 사용자는 1, 두번째는 2, 다음은 3,4,5,6.. 등으로.. 그리고 이 ID를 10으로 나눈 나머지 값을 가지고 Shard를 결정하면, 데이타를 모든 Shard에 걸쳐서 골고루 분산 시켜 배치 Sharding을 구현하는 방법 DBMS 단에서 제공하는 방법으로는 Microsoft SQL Server Azure의 federation model[2]이나 RDBMS는 아니지만 NoSQL중 MogoDB의 경우 1.6부터 Sharding을 DB단에서 지원 프레임웍단에서는 자바의 Hibernate의 경우 Hibernate Shard[3]라는 기능을 통해서 Sharding을 지원한다.  프로그래밍 언어인 Grail의 경우에도 자체 프레임웍에서“Grails Sharding Plug in”을 통한 Sharding 을 지원 직접 Application에서 구현할 경우 Key에 따라서 DB Instance를 선택적으로 고를 수 있는 구조를 가져야 하며, 특히 다른 Shard간의 데이타 Join등은 불가능하기 때문에,구현상에 이에 대한 고려가 필요 Sharding 이라는 것이 데이타를 분산 저장함으로써 시스템의 전체 용량을 늘릴 수 는 있지만 Application의 복잡도가 올라가고, 데이타 편중 방지등 여러가지 요소를 고려한후에 설계, 반영해야 한다.

참고 : http://bcho.tistory.com/670