MySQL Replication이 가장 많이 활용되는 분야입니다.
MySQL Replication은 READ관련 Scale out만 가능합니다. 만약 WRITE 이슈가 있다면, MySQL 레벨에서는 Scale out이 불가합니다. 특히나 Replication 운영 시 마스터 트래픽이 과도하게 발생하면, Master와 Slave 간 데이터 동기화 지연 현상이 발생합니다. “반드시 알아야할 MySQL 특징 세 가지” 내용을 읽어보시면 이해가 조금더 수훨하겠네요.^^
MySQL Replication Scale Out
WRITE 관련 Scale out이 불가하다고 했었는데, 전혀 불가능한 것일까요? 그렇지 않아요~! 서버 구성을 적절하게 재배치한다면 WRITE 분산도 일부 가능합니다.
다중 마스터 구성 (하단 High Availability 참고)
기본적으로 MySQL에서는 다중으로 마스터를 구성할 수 없습니다. 각 슬레이브들은 오직 하나의 슬레이브만 가질 수 있습니다.
피라미드형 구성 (하단 Data Partitioning 참고)
역할에 따라서 서버를 재배치하는 방식입니다. 모든 서버가 가져야할 데이터 공유는 최상위 마스터에서 담당하고, 중간 슬레이브는 자신이 맡은 역할에 맞는 마스터 역할을 하는 것이죠.
High Availability
MySQL Replication 을 높은 가용성 구현을 위해서 사용할 수 있습니다. 아래와 같이 가상 아이피(Virtual IP)를 통해서 App서버들이 서비스를 제공하고 있다면 마스터 장비 장애 발생 시자동으로 Virtual IP가 유휴 슬레이브 장비로 Virtual IP를 넘겨서 장애를 빠르게 대비할 수 있습니다.
High Availability
일단 슬레이브로 마스터 역할이 넘어간 시점부터는 “현재 데이터의 기준”은 “신규 마스터”이어야 합니다. 데이터가 비동기적으로 복제되는 구조이기 때문에, 장애 후 IP가 넘어가는 일시적인 시점 동안 트랜잭션 유실은 발생할 수 있다는 점 있지 마세요^^
서버 한 대 효율을 조금 더 올리고자 한다면, 아래와 같이 구성해보는 것은 어떨까요?
High Availability : Multi-Master
문제는 동일 데이터 변경에 관한 이슈인데, 이것은 Service1 과 Service2 데이터베이스를 물리적으로 분리하시면 됩니다.
Data Partitioning
분명 MySQL Replication에서 Slave는 하나의 Thread로만 SQL을 실행하기 때문에, 서버 간 동기화 지연 현상이 발생합니다. 하지만 서버 구성을 조금만 변경한다면 어느정도는 해결할 수 있습니다.
Master Scale-out
Replicate_Do_DB 혹은 Replicate_Do_Table 옵션을 사용하여, 실제로 적용할 객체들만 선별적으로 동기화하는 것입니다. 서비스 단위로 기능을 나눌 수도 있고, 역할 별로 기능을 나눌 수 있습니다.
$ vi /etc/my.cnf
replicate-do-db=common
단, 서버 확장을 고려하여, 서비스 설계 단계부터 Database 또는 테이블을 최대한 물리적으로 분리하여 설계하는 것이 가장 중요합니다.
위에서 설명드린 것은 극히 일부일 뿐 더욱 다양한 케이스에 Replication을 활용할 수 잇습니다. 예를 들어 DB Major 버전 업그레이드(ex: 5.1.x -> 5.5.x), 테이블 구조 변경, 테스트 환경 구성 등이 바로 그것들입니다. MySQL Replication은 물리적으로 저장소가 분리된 영역에 데이터를 비동기적으로 복제하는 원리만 꼭 기억하세요. ^^
위 설명에서는 추상적으로 언급 드렸으나, 추후 실제 구성 사례를 정리해서 꼭 공유 드릴께요^^
Gizzard는 트위터에서 데이터를 분산 및 복제 관리하기 위한 자체 개발 프레임워크입니다. 클라이언트와 서버 사이에 위치하며 모든 데이터 요청을 처리하는 구조입니다. Gizzard 관련 몇 가지 키워드는 아래와 같습니다.
분산 관리(Sharding) – 분할(Partitioning)
– 복제(Replication)
부하분산(Load-Balancing)
장애복구(Fail-Over)
멱등성(idempotent) / 가환성(commutative) – 멱등성 : 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
– 가환성 : 연산의 순서를 바꾸어도 그 결과가 변하지 않는 일
분산 관리(Sharding)이란?
과거에는 서비스 성능 저하가 발생하면 곧바로 해당 서버에 CPU또는 Memory 사이즈를 증설하여 성능 이슈를 해결하였습니다. 하지만, 최근 Web 서비스에서 데이터 사이즈가 급증하여, 더 이상은 서버 성능 고도화만으로는 한계가 있기 때문에, 다수 장비에 데이터를 분산 위치(Data Sharding)하여 데이터를 처리하는 움직임이 일반화되고 있습니다.
Scale up VS Scale out
분산 처리는 Hadoop, Cassandra, MongoDB 등 NOSQL 분야에서 유행처럼 번져나가고 있으며, 최근에는 기존 RDBMS 를 활용한 분산 관리 기법도 방안이 모색되고 있습니다. 사실 RDBMS의 대표적인 선두 주자인 Oracle도 예전부터 Grid Control 원칙 하에 데이터 분산 관리에 초점을 맞추고 있습니다.
데이터 분산 즉 Data Sharding이란 데이터를 조각으로 관리하자는 것인데, Sharding을 크게 Partitioning(분할) 과 Replication(복제) 두 가지로 나눕니다.
“Partitioning”은 데이터를 조각화하여 다수 서버에 위치하는 것입니다. 물론 각각의 데이터 조각들은 서버에 저장할 수 있도록 충분히 작아야 하고, 데이터를 효과적으로 관리하고 질의가 가능해야 하겠죠.
“Replication”은 여러 서버에 데이터 복사본을 위치하는 것입니다. 이 기술은 각각의 장비에서 동작하고 질의 처리를 할 수 있으며, 데이터 복사본 추가만으로 “READ” 관련 트래픽을 효과적으로 처리할 수 있습니다. 또한 다른 Node 어딘가에는 복사본 데이터가 존재하기 때문에, 특정 데이터에 장애가 발생하거나 유실이 되어도 쉽게 데이터 복구를 할 수 있다는 이점이 있습니다.
Gizzard란 무엇일까요?
Gizzard는 데이터를 분할하여 관리하는 프레임워크입니다. 트위터에서 자체 개발한 또 다른 분산 데이터 저장소이고, 데이터를 쉽게 구성하고 관리하기 위한 미들웨어입니다. 장애 발생에 유연하게 대처할 수 있고, 분산 데이터를 쉽게 관리할 수 있으며, Scala기반으로 만들어져있기 때문에 Config가 쉽다고 합니다.(저는 아직 Scala를 써보지는 않아서.. 써보고 말씀드릴께요.^^)
사실 많은 오픈 소스 분산 데이터 관리 시스템이 많이 나오고는 있지만, 효과적으로 데이터 구조를 정의하고 시스템 장애에 유연하게 대처하거나 데이터 일관성 유지 문제를 해결하는데에는 많은 어려움이 있는 것은 사실입니다.
Gizzard Architect
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를 관리를 데이터 범위 관리를 통해서 수행합니다. 선행 테이블의 맵핑 정보 안에는 특정 데이터가 어떤 범위의 구역에 저장이 되어 있는 것에 대한 정보가 숫자 범위로 저장이 되어 있습니다.
Gizzard Partitioning
조금 더 자세하게 풀자면, 특정 데이터에 관한 키 값을 Hash 함수로 돌리고 결과 값을 Gizzard에 전달하면, Gizzard는 해당 데이터가 어떤 구역에 속할 지 숫자 정보를 생성합니다. 이러한 함수는 프로그래밍 가능하기 때문에 사용자 구미에 따라서 지역성 혹은 균형성 면에서 최적화할 수 있습니다.
Gizzard는 “Replication Tree”로 복제 데이터를 관리합니다.
선행 테이블에서 지칭하고 있는 각 데이터 조각들은 물리 혹인 논리적인 형태로 구현될 수 있습니다. 물리적인 형태는 특정 데이터 저장소를 의미하고, 논리적인 형태는 데이터 조각에 관한 Tree를 의미합니다. 트리 안의 각 Branch들은 데이터의 논리적인 변형을 나타내고, 각 Node들은 데이터 저장소를 의미합니다. 예를 들어서 아래와 같이 두 단계의 “Replicating Tree”가 있습니다. 하지만 이것들은 선행 테이블에 지칭을 해서 관리되는 오직 하나의 파티션에 저장될 뿐입니다.
Gizzard Replication
위 그림에서 Replicate라는 Branch 역할은 간단합니다. 단지 자신의 모든 자식 Node에 쓰기만 반복하고, 읽기 균형을 유지한다는 단순한 전략 하에 동작합니다. 데이터 저장소 요구사항에 맞게 추가적인 트랜잭션 혹은 Node 개수 전략을 추가하여 데이터 조각을 재구성할 수 있습니다. 그러나 Gizzard는 기본적으로 Replicating, Write-Only, Read-Only, Blocked 등 몇 가지 전략을 제공합니다.
복제 구성에 관한 세부 형상은 Partition에 따라 다양합니다. 자주 사용되는 데이터에는 더욱 많은 복제를 추가하면 될 것이고, 간헐적으로 사용되는 데이터에는 적은 데이터 복제를 가질 수 있도록 유도하면 됩니다. 한 데이터에 관해서 Primary/Secondary/Tertiary 유지할 수도 있고, 복제를 유지하지 않아도 되는 데이터인 경우에는 Striping Partitioning 구성하여 복제를 하나도 유지하지 않을 수도 있습니다.
Gizzard는 장애 상황에 강한 시스템입니다. 분산 시스템에서 장애 대처는 가장 큰 이슈입니다. 다수 컴퓨터가 동시에 동작하는 구조이기 때문에, 특정 장비에서 예기치 않게 언제든지 장애가 발생할 수 있습니다. Gizzard는 어떠한 장애 상황에서도 유연하게 대처할 수 있도록 디자인되었습니다. 만약 특정 파티션 내에 있는 복제 데이터가 유실되었을 지라도, Gizzard는 읽기/쓰기 요청을 남은 다른 정상적인 복제 데이터로 전환합니다.
Gizzard Failover
위와 같이, 데이터 조각 안의 “특정 복제 데이터 불능”이 발생하면 Gizzard는 최대한 빠르게 다른 정상적인 복제 데이터에 읽기/쓰기 작업을 시도할 것입니다. 그리고 문제가 발생했던 복제 데이터가 정상으로 돌아오면, 변경 이력을 다시 적용을 합니다. 여기서 가장 기본적인 원칙은 트랜잭션 단위 기록을 견고하게 구현한다는 것입니다. 모든 데이터 복제는 비 동기로 이루어지겠지만, 최대한 지연이 없이 진행됩니다.
Gizzard Failover
만약 “모든 복제 데이터 불능 상태”이 빠지면 해당 데이터에만 읽기 요청이 불가할 뿐 다른 정상적인 데이터에는 영향을 미치지 않습니다. 데이터 조각 안의 모든 복제 데이터가 불능에 빠지면, 일단은 “Error Queue”라는 곳에 상태를 기록하고 버퍼에 변경 내용을 쌓습니다. 그리고 파티션 정상화가 되면, 변경된 데이터를 다시 적용합니다. 최종 데이터 일관성은 “멱등성”과 “가환성” 원칙 하에 유지되기 때문에 이전 실패가 적용되기 전에 최근 변경 사항이 먼저 적용된다고 하더라도 결과적으로는 아무런 문제가 없습니다.
Gizzard는 데이터 이관 방안을 제시합니다.
경우에 따라서 데이터를 다른 장비로 데이터 이관 작업이 필요합니다. 로드발란싱을 위한 경우도 있고, 데이터가 적은 장비로 옮기는 경우도 있으며, 하드웨어 장애로 인한 경우도 있습니다. Gizzard에서 논리적인 Shard들을 다른 장비로 이관하는 방식을 설명하겠습니다.
Gizzard Data Migration
Original에서 Target로 이관한다고 가정했을 때, “Replicate Shard”가 Original 와 Target 사이에, “WriteOnly Shard”는 Target 앞에 위치할 것입니다. 그리고 Original 에서 Target으로 데이터가 복사됩니다. WriteOnly Shard는 Target이 사용 가능한 시점까지 유지하며, 전체 데이터가 복사되기 전까지 Target에서는 어떠한 데이터 조회도 불가합니다. 쓰기 작업이 순서에 관계없이 중복으로 발생할 수 있기 때문에 모든 쓰기 작업은 반드시 멱등성 및 가환성 원칙 하에 동작해야 합니다.
데이터 일관성은 멱등성 및 가환성 원칙 하에 유지합니다.
동일 데이터를 동시에 변경하려고 하면 데이터 충돌(Confliction) 이 발생합니다. Gizzard는 데이터는 적용 순서를 보장하지 않기 때문에 모델링 시 반드시 이러한 점을 염두 해야 합니다.
Gizzard Concurrency
높은 가용성과 데이터가 저장되는 순서를 보장하는 것보다 훨씬 간단한 방식입니다. 예를 들어, Rowz에서는 Timestamp를 기준으로 새로운 데이터 변경 요청 여부를 구분합니다.
타 시스템과 비교
GIZZARD Replicate VS MySQL Replication MySQL Replication과 가장 큰 차이는 Gizzard는 데이터가 저장되는 순서를 보장하지 않는다는 점입니다. 모든 데이터 일관성은 멱등성 및 가환성에 의거하에 보장되며, 일시적인 데이터 불일치는 허용합니다. 물론 일시적인 데이터 불일치를 허용한다는 점은 MySQL Replication도 마찬가지지만, 데이터를 순차적으로 적용한다는 점은 확연하게 다릅니다. 만약 데이터가 순차적으로 수행되다가 실패를 한다면, 그 이후 적용되어야하는 데이터는 실패했던 연산 처리 후 처리될 수 있습니다.
GIZZARD VS Cassandra
트위터에서 사용하고 있는 두 데이터 저장 스토어를 간단하게 비교해보았습니다. Gizzard는 데이터 일관성을 멱등성/가환성에 의거하여 유지합니다. 하지만 Cassandra는 데이터 일관성을 Gossip 통신과 Timestamp로 최신 데이터 결정한다는 가장 큰 차이가 있습니다. Cassandra에서 CorrencyLevel 설정 값에 따라서 동시성 레벨을 조정할 수 있는데, 서비스 특성 및 사용자 요구 사항에 따라서 다양하게 설정할 수 있습니다.
마치며..
최근 이슈가 되는 대용량 데이터 시스템을 보면 공통적인 부분이 데이터 분산 처리입니다. 이제는 과거 기가바이트 단위가 아닌 테라바이트 단위로 데이터가 증가하기 때문에, 분산 처리에 관한 기술은 지속적인 습득이 필요하겠네요. “하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어” 포스팅을 작성을 하면서 많은 생각을 하게 만든 새로운 경험이었습니다.^^
트위터는 하루 평균 2.5억 건의 트윗을 저장한다고 합니다. 과거 트위터는 “날짜 기준으로 데이터를 분할 관리”하여 저장을 하였고, 대략 3주에 한번씩 서버를 추가하여 Scale-out 하였습니다.
하지만 이 방식에는 다음과 같은 문제가 있었습니다.
부하 분산
고비용
복잡한 프로세스
문제를 해결하기 위해서 트위터에서 New Tweet Store를 고안했다고 합니다.
자, 그럼 기존 문제점부터 차근차근 알아보도록 합시다^^;
Problems
부하 분산(Load Balancing)
날짜 기준으로 데이터를 나눠서 분산 저장 및 관리하기 때문에, 시간이 지날수록 과거 데이터 조회 건수는 비약적으로 낮아집니다. 특히 대부분의 데이터 조회 요청은 현재 시각 기준으로 들어오기 때문에, 데이터 읽기 HOTSPOT이 발생할 수 밖에 없습니다.
Load Balancing Problem
고 비용(Expensive)
데이터는 나날이 쌓여만 가고 이를 위해서는, 매 3주에 걸쳐서 신규 노드를 추가해줘야 합니다. 신규 노드는 서버 한 대가 아닌 마스터/슬레이브로 구성되기 때문에 상당한 비용이 소요됩니다.
Expensive Problem
절차 복잡성(Logistically complicated)
무엇보다 가장 큰 문제는 신규 노드를 추가하는 것이 상당히 어렵다는 것입니다. 매 3주에 걸쳐서 신규 노드를 도입하는 것은 DBA 팀 입장에서는 상당히 부담되고 고된 일이었다고 합니다.
Logistically Complicated Problem
NEW Tweet Store
트위터는 당면한 문제를 해결하기 위해 데이터 분산 도구로는 Gizzard, 데이터 저장소로는 MySQL, 그리고 UUID 생성에는 SnowFlake등으로 새롭게 데이터 분산 재구성 하였습니다.
Twitter's New Tweet Store
결과적으로 기존의 과거 날짜 기반의 데이터 축적에서 점진적으로 데이터가 축적되는 효과를 가져왔으며, 3주에 한번씩 고된 업무를 기획하고 이행해야했던 복잡한 절차도 사라졌다고 합니다.
전체적인 트위터 동작에 관한 내용을 하단 그림으로 표현해봅시다.
New Tweet Store Architect
트윗이 저장되는 저장소를 T-Bird, 보조 인덱스가 저장되는 저장소를 T-flock라고 내부적으로 지칭합니다. 두 시스템 모두 Gizzard 기반으로 이루어져 있으며, Unique ID는 Snowflake로 생성을 합니다.
그러면 New Tweet Store에 적용된 Gizzard, MySQL, Snowflake에 관해서 알아보도록 하겠습니다.
Gizzard in New Tweet Store
Gizzard는 데이터를 분산 및 복제해주는 프레임워크입니다. 클라이언트와 서버 사이에 위치하며 모든 데이터 요청을 처리합니다. 데이터 분산 및 복제 관리 뿐만 아니라 데이터 이관, 장애 대처등 다양한 역할을 수행합니다.
Gizzard Architect
가장 큰 특징은 Write연산에 관해서는 “멱등성” 및 “가환성” 원칙에 의해 적용된다는 점입니다. 기본적으로 Gizzard는 데이터가 저장되는 순서를 보장하지 않습니다. 이 말은 곧 언제든지 예전 Write 연산이 중복되어 다시 수행될 수 있음을 의미하는데, 중복 적용될 지라도 최종적인 데이터 일관성을 보장합니다.
MySQL in New Tweet Store
MySQL이 저장소로 사용됩니다. 물론 Gizzard에서 다른 다양한 저장소를 지원하지만, 트위터에서는 일단 MySQL로 스토리지 엔진은 InnoDB로 선택해서 사용하였습니다. InnoDB 스토리지엔진을 사용한 이유는 행단위 잠금과 트랜잭션을 지원하기 때문데, 다른 스토리지 엔진 대비 데이터가 망가질 확률이 훨씬 적기 때문이 아닐까 추측해 봅니다.각 MySQL 서버에 관한 하드웨어 사양과 데이터 사이즈는 다음과 같습니다.MySQL 관련된 가장 특이한 사항은 정말 단순 데이터 저장 용도로만 사용된다는 점입니다. 일반적으로 MySQL에서 데이터 복구와 이중화를 위해서 Binary Log를 사용하지만, Gizzard와 함께 사용되는 MySQL은 이 기능마저 사용하지 않습니다. 게다가 데이터 복제를 위해서 MySQL 고유의 Replication 기능마저 사용하지 않는다는 점에서, MySQL은 new tweet store에서는 단순한 데이터 저장 수단인 것을 알 수 있었습니다.
그 이유는 Gizzard가 데이터 분산 및 복제 모두를 수행하기 때문입니다.
Snowflake in New Tweet Store
Snowflake는 New Tweet Store에서 고유 아이디 값(Unique ID)을 할당하는 역할을 합니다. 총 8Byte로 구성되어 있으며 시간 순으로 정렬 가능한 값입니다.
Snowflake
Time – 41 bits : millisecond이며 앞으로 최대 69년 사용할 수 있음
Machine id – 10 bits : 1024 대의 머신에 할당 가능
Sequence number – 12 bits : 머신당 같은 millisecond에 4096개 생성 가능
마치며..
작년 Amazon RDS에 서비스를 올리기 위해서 아래와 같이 구상을 한 적이 있습니다. Amazon RDS 상 제약사항을 회피하고자 한 것으로, 기본적으로 공통으로 필요한 정보만 공유하자는 컨셉이었습니다. 변경 로그는 멱등성을 가지며 주기적(1초)으로 각 서비스 DB에서 변경 로그들을 Pulling하여 데이터 일관성을 유지하자는 내용이었습니다.
Datastore Concept
트위터 사례는 참으로 많은 점을 느끼게 하였습니다. 결과적으로 새롭게 데이터 분산을 재구성하여 점진적인 데이터 증가와 더불어 DBA 팀 자체 업무가 크게 줄었다는 사실에서 깊은 찬사를 보냅니다.
MySQL 관련된 가장 특이한 사항은 정말 단순 데이터 저장 용도로만 사용된다는 점입니다. 일반적으로 MySQL에서 데이터 복구와 이중화를 위해서 Binary Log를 사용하지만, Gizzard와 함께 사용되는 MySQL은 이 기능마저 사용하지 않습니다. 게다가 데이터 복제를 위해서 MySQL 고유의 Replication 기능마저 사용하지 않는다는 점에서, MySQL은 new tweet store에서는 단순한 데이터 저장 수단인 것을 알 수 있었습니다.
