Overview

바로 이전 “하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어” 포스팅에서 트위터의 새로운 저장 스토어에 관해서 전반적으로 설명 드렸는데요, 이번에는 그 중 Gizzard에 관해서 심층 분석(?)을 해볼까합니다.

Gizzard는 트위터에서 데이터를 분산 및 복제 관리하기 위한 자체 개발 프레임워크입니다. 클라이언트와 서버 사이에 위치하며 모든 데이터 요청을 처리하는 구조입니다. Gizzard 관련 몇 가지 키워드는 아래와 같습니다.

1. 분산 관리(Sharding)
   – 분할(Partitioning)
   – 복제(Replication)
2. 부하분산(Load-Balancing)
3. 장애복구(Fail-Over)
4. 멱등성(idempotent) / 가환성(commutative)
   – 멱등성 : 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
   – 가환성 : 연산의 순서를 바꾸어도 그 결과가 변하지 않는 일

분산 관리(Sharding)이란?

과거에는 서비스 성능 저하가 발생하면 곧바로 해당 서버에 CPU또는 Memory 사이즈를 증설하여 성능 이슈를 해결하였습니다. 하지만, 최근 Web 서비스에서 데이터 사이즈가 급증하여, 더 이상은 서버 성능 고도화만으로는 한계가 있기 때문에, 다수 장비에 데이터를 분산 위치(Data Sharding)하여 데이터를 처리하는 움직임이 일반화되고 있습니다.

분산 처리는 Hadoop, Cassandra, MongoDB 등 NOSQL 분야에서 유행처럼 번져나가고 있으며, 최근에는 기존 RDBMS 를 활용한 분산 관리 기법도 방안이 모색되고 있습니다. 사실 RDBMS의 대표적인 선두 주자인 Oracle도 예전부터 Grid Control 원칙 하에 데이터 분산 관리에 초점을 맞추고 있습니다.

데이터 분산 즉 Data Sharding이란 데이터를 조각으로 관리하자는 것인데,  Sharding을 크게 Partitioning(분할) 과 Replication(복제) 두 가지로 나눕니다.

“Partitioning”은 데이터를 조각화하여 다수 서버에 위치하는 것입니다. 물론 각각의 데이터 조각들은 서버에 저장할 수 있도록 충분히 작아야 하고, 데이터를 효과적으로 관리하고 질의가 가능해야 하겠죠.

“Replication”은 여러 서버에 데이터 복사본을 위치하는 것입니다. 이 기술은 각각의 장비에서 동작하고 질의 처리를 할 수 있으며, 데이터 복사본 추가만으로 “READ” 관련 트래픽을 효과적으로 처리할 수 있습니다. 또한 다른 Node 어딘가에는 복사본 데이터가 존재하기 때문에, 특정 데이터에 장애가 발생하거나 유실이 되어도 쉽게 데이터 복구를 할 수 있다는 이점이 있습니다.

Gizzard란 무엇일까요?

Gizzard는 데이터를 분할하여 관리하는 프레임워크입니다. 트위터에서 자체 개발한 또 다른 분산 데이터 저장소이고, 데이터를 쉽게 구성하고 관리하기 위한 미들웨어입니다. 장애 발생에 유연하게 대처할 수 있고, 분산 데이터를 쉽게 관리할 수 있으며, Scala기반으로 만들어져있기 때문에 Config가 쉽다고 합니다.(저는 아직 Scala를 써보지는 않아서.. 써보고 말씀드릴께요.^^)

사실 많은 오픈 소스 분산 데이터 관리 시스템이 많이 나오고는 있지만, 효과적으로 데이터 구조를 정의하고 시스템 장애에 유연하게 대처하거나 데이터 일관성 유지 문제를 해결하는데에는 많은 어려움이 있는 것은 사실입니다.

Gizzard는 트위터에 최적화된 오픈 소스 분산 관리 프레임워크입니다. 물론 앞선 문제를 모든 시스템 상황과 사용자 요구사항을 충족하지는 못하지만, 대부분 데이터 저장소에 존재하는 문제점을 “어느정도” 유연하게 대처합니다.

Gizzard는 데이터를 분할/복제 관리하고, 네트워크 상에서 어플리케이션(PHP/JAVA/Ruby)와 저장소(MySQL/ Lucene/Redis) 사이에 위치합니다.

Partitioning 구성 정보는 데이터 저장 위치를 정의하는 선행 맵핑 테이블에 저장이 됩니다. 그리고 Partition 내부적으로 데이터 조각에 관한 Replication(복제)를 유지하는데, 이것은 “Replicate Tree”로 제어됩니다. 또한 쉬운 Migration과 Load-balancing이 가능하고, 장애 시 유연하게 대처합니다. 멱등성과 가환성 원칙에 의해서 복제 데이터 간 일관성을 유지한다는 특징도 있습니다.

Gizzard를 자세히 살펴봅시다.

• Gizzard는 네트워크 서비스 미들웨어입니다.
  클라이언트(PHP/Ruby/JAVA)와 데이터 저장소(Partitioning과 Replication으로 구성) 사이에 위치하고 모든 데이터 질의는 오직 Gizzard를 통해서 이루어집니다. 특별한 인스턴스는 형태가 없는 구조이고,  JVM위에서 실행되며, 상당히 효율적입니다. 트위터에서 사용하고 있는 Gizzard는 머신 당 초당 10,000 쿼리를 수용할 수 있다고 합니다.

• Gizzard는 어떤 종류의 데이터 저장소에도 적용할 수 있습니다.
  Gizzard는 애초에 네트워크를 통해서 데이터 저장소에 복제하도록 디자인되었습니다. 그렇기 때문에 데이터 저장소를 SQL Server, Lucene, Redis 등 어떠한 솔루션을 선택해도 큰 문제가 없습니다. 그리고 Gizzard는 모든 쓰기 작업을 “멱등성” 및 “가환성”의 원칙에 의거하여 동작하기 때문에, 저장소 자체에 관한 제약을 걸지는 않습니다. 즉, 저장 시스템 자체에 존재하는 제약 사항에는 여전히 의존한다고 볼 수 있습니다. 예를 들어 RDBMS 에서 Unique 조건이 있는 경우 Gizzard에서는 정상적으로 Writing을 시도하나, 데이터베이스 내부에서는  제약사항에 걸려 데이터 입력이 막히게 됩니다.
  Gizzard에 관한 중요한 사실은 순차적으로 데이터가 적용된다는 것을 보장하지 않는다는 것입니다. 그렇기 때문에 쓰기 연산 적용 순서와 관계없이 데이터 일관성을 유지할 수 있도록  설계하는 것이 가장 중요합니다.

• Gizzard는 데이터 맵핑 선행 테이블에서 데이터 조각을 관리합니다.
  Gizzard는 특정 Shard를 관리를 데이터 범위 관리를 통해서 수행합니다. 선행 테이블의 맵핑 정보 안에는 특정 데이터가 어떤 범위의 구역에 저장이 되어 있는 것에 대한 정보가 숫자 범위로 저장이 되어 있습니다.

  

  조금 더 자세하게 풀자면, 특정 데이터에 관한 키 값을 Hash 함수로 돌리고 결과 값을 Gizzard에 전달하면, Gizzard는 해당 데이터가 어떤 구역에 속할 지 숫자 정보를 생성합니다. 이러한 함수는 프로그래밍 가능하기 때문에 사용자 구미에 따라서 지역성 혹은 균형성 면에서 최적화할 수 있습니다.

• Gizzard는 “Replication Tree”로 복제 데이터를 관리합니다.
  선행 테이블에서 지칭하고 있는 각 데이터 조각들은 물리 혹인 논리적인 형태로 구현될 수 있습니다. 물리적인 형태는 특정 데이터 저장소를 의미하고, 논리적인 형태는 데이터 조각에 관한 Tree를 의미합니다. 트리 안의 각 Branch들은 데이터의 논리적인 변형을 나타내고, 각 Node들은 데이터 저장소를 의미합니다. 예를 들어서 아래와 같이 두 단계의 “Replicating Tree”가 있습니다. 하지만 이것들은 선행 테이블에 지칭을 해서 관리되는 오직 하나의 파티션에 저장될 뿐입니다.

  

  위 그림에서 Replicate라는 Branch 역할은 간단합니다. 단지 자신의 모든 자식 Node에 쓰기만 반복하고, 읽기 균형을 유지한다는 단순한 전략 하에 동작합니다. 데이터 저장소 요구사항에 맞게 추가적인 트랜잭션 혹은 Node 개수 전략을 추가하여 데이터 조각을 재구성할 수 있습니다. 그러나 Gizzard는 기본적으로 Replicating, Write-Only, Read-Only, Blocked 등 몇 가지 전략을 제공합니다.
  복제 구성에 관한 세부 형상은 Partition에 따라 다양합니다. 자주 사용되는 데이터에는 더욱 많은 복제를 추가하면 될 것이고, 간헐적으로 사용되는 데이터에는 적은 데이터 복제를 가질 수 있도록 유도하면 됩니다. 한 데이터에 관해서 Primary/Secondary/Tertiary 유지할 수도 있고, 복제를 유지하지 않아도 되는 데이터인 경우에는 Striping Partitioning 구성하여 복제를 하나도 유지하지 않을 수도 있습니다.

• Gizzard는 장애 상황에 강한 시스템입니다.
  분산 시스템에서 장애 대처는 가장 큰 이슈입니다. 다수 컴퓨터가 동시에 동작하는 구조이기 때문에, 특정 장비에서 예기치 않게 언제든지 장애가 발생할 수 있습니다. Gizzard는 어떠한 장애 상황에서도 유연하게 대처할 수 있도록 디자인되었습니다. 만약 특정 파티션 내에 있는 복제 데이터가 유실되었을 지라도, Gizzard는 읽기/쓰기 요청을 남은 다른 정상적인 복제 데이터로 전환합니다.

  

  위와 같이, 데이터 조각 안의 “특정 복제 데이터 불능”이 발생하면  Gizzard는 최대한 빠르게 다른 정상적인 복제 데이터에 읽기/쓰기 작업을 시도할 것입니다. 그리고 문제가 발생했던 복제 데이터가 정상으로 돌아오면, 변경 이력을 다시 적용을 합니다. 여기서 가장 기본적인 원칙은 트랜잭션 단위 기록을 견고하게 구현한다는 것입니다. 모든 데이터 복제는 비 동기로 이루어지겠지만, 최대한 지연이 없이 진행됩니다.

  

  만약 “모든 복제 데이터 불능 상태”이 빠지면 해당 데이터에만 읽기 요청이 불가할 뿐 다른 정상적인 데이터에는 영향을 미치지 않습니다. 데이터 조각 안의 모든 복제 데이터가 불능에 빠지면, 일단은 “Error Queue”라는 곳에 상태를 기록하고 버퍼에 변경 내용을 쌓습니다. 그리고 파티션 정상화가 되면, 변경된 데이터를 다시 적용합니다. 최종 데이터 일관성은 “멱등성”과 “가환성” 원칙 하에 유지되기 때문에 이전 실패가 적용되기 전에 최근 변경 사항이 먼저 적용된다고 하더라도 결과적으로는 아무런 문제가 없습니다.

• Gizzard는 데이터 이관 방안을 제시합니다.
  경우에 따라서 데이터를 다른 장비로 데이터 이관 작업이 필요합니다. 로드발란싱을 위한 경우도 있고, 데이터가 적은 장비로 옮기는 경우도 있으며, 하드웨어 장애로 인한 경우도 있습니다. Gizzard에서 논리적인 Shard들을 다른 장비로 이관하는 방식을 설명하겠습니다.

  

  Original에서 Target로 이관한다고 가정했을 때, “Replicate Shard”가 Original 와 Target 사이에, “WriteOnly Shard”는 Target 앞에 위치할 것입니다. 그리고 Original 에서 Target으로 데이터가 복사됩니다. WriteOnly Shard는 Target이 사용 가능한 시점까지 유지하며, 전체 데이터가 복사되기 전까지 Target에서는 어떠한 데이터 조회도 불가합니다. 쓰기 작업이 순서에 관계없이 중복으로 발생할 수 있기 때문에 모든 쓰기 작업은 반드시 멱등성 및 가환성 원칙 하에 동작해야 합니다.

• 데이터 일관성은 멱등성 및 가환성 원칙 하에 유지합니다.
  동일 데이터를 동시에 변경하려고 하면 데이터 충돌(Confliction) 이 발생합니다. Gizzard는 데이터는 적용 순서를 보장하지 않기 때문에 모델링 시 반드시 이러한 점을 염두 해야 합니다.

  

  높은 가용성과 데이터가 저장되는 순서를 보장하는 것보다 훨씬 간단한 방식입니다. 예를 들어, Rowz에서는 Timestamp를 기준으로 새로운 데이터 변경 요청 여부를 구분합니다.

타 시스템과 비교

• GIZZARD Replicate VS MySQL Replication
  MySQL Replication과 가장 큰 차이는 Gizzard는 데이터가 저장되는 순서를 보장하지 않는다는 점입니다. 모든 데이터 일관성은 멱등성 및 가환성에 의거하에 보장되며, 일시적인 데이터 불일치는 허용합니다. 물론 일시적인 데이터 불일치를 허용한다는 점은 MySQL Replication도 마찬가지지만, 데이터를 순차적으로 적용한다는 점은 확연하게 다릅니다. 만약 데이터가 순차적으로 수행되다가 실패를 한다면, 그 이후 적용되어야하는 데이터는 실패했던 연산 처리 후 처리될 수 있습니다.
  

• GIZZARD VS Cassandra
  트위터에서 사용하고 있는 두 데이터 저장 스토어를 간단하게 비교해보았습니다. Gizzard는 데이터 일관성을 멱등성/가환성에 의거하여 유지합니다. 하지만 Cassandra는 데이터 일관성을 Gossip 통신과 Timestamp로 최신 데이터 결정한다는 가장 큰 차이가 있습니다. Cassandra에서 CorrencyLevel 설정 값에 따라서 동시성 레벨을 조정할 수 있는데, 서비스 특성 및 사용자 요구 사항에 따라서 다양하게 설정할 수 있습니다.
  

마치며..

최근 이슈가 되는 대용량 데이터 시스템을 보면 공통적인 부분이 데이터 분산 처리입니다. 이제는 과거 기가바이트 단위가 아닌 테라바이트 단위로 데이터가 증가하기 때문에, 분산 처리에 관한 기술은 지속적인 습득이 필요하겠네요. “하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어” 포스팅을 작성을 하면서 많은 생각을 하게 만든 새로운 경험이었습니다.^^

읽어주셔서 감사합니다.

참고자료)
How Twitter Stores 250 Million Tweets A Day Using MySQL
Gizzard: a library for creating distributed datastores