Monthly Archives: September 2012

서비스 로직 흐름을 변경하여 DB 튜닝을 해보자!

Overview

오래전 메가존(현 혜택존) 서비스를 담당하던 시기, 포인트 관련된 부분에서 심각한 성능 저하 및 유효성 취약 문제가 발생하였습니다. 장비 고도화를 통해 관련 문제를 해결하기에 앞서, 서비스 로직 및 테이블 재구성을 통한 최적화 작업을 통해 문제를 해결하였습니다.

이에 관해 간단하게 소개하도록 하겠습니다.

Problems

다음과 같이 크게 두 가지 문제가 있었습니다.

  1. 성능 이슈
    1. 로그 테이블은 거대한 한 개의 테이블로 구성
    2. 데이터 누적에 따라 성능이 급격하게 저하
  2. 유효성 이슈
    1. 자바 어플리케이션에서만 유효성 체크 – 비 정상적인 사용 존재
    2. 포인트가 현금처럼 사용될 수 있으므로 반드시 필요함

Solutions

1) 파티셔닝을 통한 성능 최적화

오라클 엔터프라이즈 버전에서는 테이블 파티셔닝을 제공하지만, 아쉽게도 오라클 스탠다드에서는 관련 기능이 없습니다. 즉, 어플리케이션 레벨에서 적당히 데이터 분산을 유도하는 방법 밖에는 없습니다. 데이터를 분산하는 방법으로는 여러가지가 존재하겠지만, 저는 월별로 테이블을 분산 저장하는 방식을 사용하였습니다.

매월 하단과 같은 스키마의 테이블을 MCHIP”YYYYMM” 형식으로 생성을 합니다.

물론 해당 월 다음 달로 생성을 해야겠죠?

 Name            Type
 --------------- ------------
 SEQ             NUMBER
 USER_NO         VARCHAR2(12)
 POINT           NUMBER
 ISSUE_DATE      DATE

그리고 인덱스 필요 시 데이터 테이블스페이스와는 “물리적으로 분리”된 전용의 테이블스페이스에 생성하여 DISK I/O 비효율도 최소화 유도하였습니다.

데이터 조회는 기본적으로 월별로만 가능하며, 최근 3개월 동안만 조회할 수 있도록 하였고, 필요 시 과거 테이블을 DROP하는 방식으로 변경하였습니다. 만약 최근 3개월 데이터가 필요할 시에는 “UNION ALL” 구문으로 데이터를 가져왔습니다.

다음은 쿼리를 월별로 생성하여 데이터를 저장하는 간단한 자바 프로그램입니다. 저는 SpringFramework 환경에서 구현했었는데, 그것보다는 알아보기 쉬운 단순 자바 프로그램으로 보여드리는 것이 좋을 것 같습니다. (설마 아래 있는 것을 그대로 쓰시는 것은 아니겠죠? ㅎㅎ)

import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
public class Test {
    public static void main(String[] args) {
        DateFormat df = new SimpleDateFormat("yyyyMM");
        Date date = new Date();

        // 현재 기준 년월 
        String yyyymm = df.format(date).toString();

        // 쿼리 생성
        String sql = "INSERT INTO MCHIP"+yyyymm+" \n" +
                "(SEQ, USER_NO, POINT, ISSUE_DATE) \n" +
                "VALUES \n" +
                "(SEQ_MCHIP.NEXTVAL, ?, ?, SYSDATE)";

        System.out.println(sql);
    }
}

위와 같이 쿼리를 생성하고, 원하는 테이블에 선별적으로 데이터를 넣습니다. 조회 시에도 위와 같은 방식으로 쿼리를 생성합니다. 만약 한달 이상의 데이터가 필요하다면 UNION ALL로 쿼리를 붙여서 데이터를 조회하면 되겠죠. ^^

2) 트리거를 사용한 유효성 체크

포인트 내역을 저장하는 테이블이 있었다면, 포인트 현황을 조회하기 위한 전용 테이블 또한 존재했습니다. 포인트 현황에 저장된 점수가 사용자가 현재 소지하고 있는 포인트이며, 이를 차감하여 서비스에서 사용하는 방식으로 사용하고 있었습니다.

개인 당 한 건의 데이터만 있기 때문에, 사용자 데이터를 조회하는 것에는 큰 무리가 없었지만, 유효성을 자바 어플리케이션에서만 체크했었기 때문에 여기저기 헛점이 많은 상태였습니다. 물론 내구성이 뛰어나게 개발되었다면 큰 문제는 없었겠지만, 협력사가 시간에 쫓겨서 급하게 개발한 산출물인지라.. 아무래도.. ^^;;

자바 소스 전체를 뒤져서 모든 유효성을 체크하는 것은 거의 무리에 가까웠고, 그래서 제가 채택한 방식은 트리거였습니다. 트리거를 사용하여 사용자 포인트 유효성 여부를 DB레벨에서 체크해서 어플리케이션과 분리하자는 의도였죠.

MCHIP201209 테이블에 포인트가 내역이 들어가는 동시에 유효성 체크 후 정상적이면 포인트 현황 테이블에 반영하는 트리거입니다.

CREATE OR REPLACE TRIGGER TRG01_MCHIP201209
BEFORE INSERT
ON MCHIP201209
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
DECLARE
  POINT NUMBER;
BEGIN
  /*** 현재 사용자 포인트 조회 ***/
  SELECT POINT INTO POINT FROM MCHIP_INFO
  WHERE USER_NO = :NEW.USER_NO;
  … 중략…

  /*** 포인트 유효성 체크  ***/
  IF POINT - :NEW.POINT < 0 THEN
    RAISE_APPLICATION_ERROR(-20001,'Not enough point!!');
  END IF;

  /*** 포인트 현황 업데이트 ***/
  UPDATE MCHIP_INFO SET POINT = POINT + POINT_NEW
  WHERE USER_NO = :NEW.USER_NO;
END;
/

Conclusion

오래전에 성능을 최적화한 내용을 정리하였습니다.

당시 서버에 과부하로 인하여 서버 고도화 및 장비 도입을 위한 투자를 검토 중이었으나, 서비스 로직 재구성 이후 서버가 안정적이었기 때문에 기존 장비로 서비스를 진행하였습니다. 게다가 현재 기존 장비 사용률이 CPU 기준 80~90%였던 상황이 10~20%로 유지되는 쾌거를 거두었죠.

데이터 처리량을 최소로 유도하는 것이 성능 최적화의 첫걸음이라는 것을 느낀 경험이었습니다.

좋은 포스팅으로 다시 찾아뵐께요^^;

KTH에서 5년간의 생활을 마무리하며..

5년동안 재미있게 다녔던 KTH와 이별합니다. 시간이란 참으로 전광석화 순식간에 지나가네요. 입사한 당시가 엊그제 같은데..

대학 마지막 한 학기, 취업 자리를 알아볼 때, 취업 공고에서 가장 눈에 들어왔던 것은 “보라매”라는 지리적인 명칭이었습니다. 강남역에서 병특을 할 때나 역삼역에서 알바를 할 당시 모두 사람에게 치이는 생활 자체에 너무 치가 떨렸기 때문이죠.

면접 태그

2007년 면접 당시 이름표

일단 거리에서 매혹당한 후에 KTH가 도대체 무슨 일을 하는 회사였는지 찾아봤습니다.

당시 금전적인 가치보다는 제가 얻을 수 있는 경험의 가치를 최우선으로 생각을 해왔었기 때문에, 제가 반드시 거쳐가야할 회사라는 것을 예감했습니다. 포털/컨텐츠/IPTV/게임 등등 온갖 다양한 경험들을 얻을 수 있는 최고의 환경이라고 판단했기 때문이죠.

회사에 입사해 저를 포함해 인성 시험을 봤었다면 회사에 들어오지 못했을만한 세상 최고로 특이한 소중한 입사 동기들을 만났습니다. 그리고 아래와 같은 홍보 동영상도 함께 제작을 했었죠. ^^; 현직에 계신 분들 불쾌하신 내용이 있다면 죄송^^;;

주연&조연 : KTH 29기 공채
(성동찬, 남현우, 문재희, 양태종, 곽형석, 김원묵, 한진욱, 이진아, 황순재, 최여정)
영상편집 : 황순재
장소협찬 : 성동찬
특별출현 : 성동찬 부친, 성동현
음원협찬 : KTH

그리고 졸업 후 각 팀에 배치.. 처음 팀 이름은 “기술개발팀!!”

사실 나름 오랫동안 웹관련 업무를 해왔다고 생각해왔었기에, 웹이 아닌 다른 경험을 해보고 싶어서 기술개발팀에 1지망으로 지원을 했었습니다. 기술을 개발하는 차도남 스타일의 팀이름이었기에..^^ 그치만 여기서 2년이 넘게 웹프로그래밍을 본격적으로 경험하였습니다. 이런게 진정 피싱이죠!! ㅋ 흐흐~

당시 힘든 일도 하고, 삽질도 많이 했었지만, 후회는 없습니다. 덕분에 DBA로 자연스럽게 업무 전향을 했고 여러 시스템에 대한 경험을 착실하게 쌓았기 때문이죠. 하지만 이제야 밝히지만.. 지금은 실장님이 되신 당시 기술개발팀장님!!(성함은 절~대 밝힐 수 없음!! ㅋ) 너무 힘들었어요!! 뼈를 너무 많이 깎았었나봐요. 그때는..ㅋ

물론 간간이 H에서 소중한 동기들과 여행도 다니기도 했고, 매번 아침마다 30분씩 모여서 잡담을 하다가 경고를 먹기도 했습니다. 근태가 안좋다고..ㅋㅋ

동기들과의 희귀한 컨셉의 그때 그사진

동기들과의 희귀한 컨셉의 그때 그사진

게으르고 힘들게 살아가는 것을 기피하는 제 천성때문인지.. 모든 것을 자동화 혹은 반자동화하면서 하나하나 제 업무를 줄여갔습니다. (아! 물론 사업팀에는 비밀이었죠!) 그리고 남는 시간에 타 서비스 DB튜닝도 참여하면서 역량도 키우고 단순 노가다성 일을 최소화할 수 있게 이것저것 툴을 만들다보니, 어느새 2년이 후딱 지났습니다.

웹을 하면서 가진 가장 값진 경험은 DB로 본격 전향했다는 것과 서버 캐시를 이곳 저곳 재미있게 적용해봤다는 점입니다. (아! 물론 남들이 모르는 사고도 여기저기 쳤지만, 경험이 부족한 하수들만이 누릴 수 있는 식겁한 경험들이죠!)

결혼식 식권

결혼식 식권

아!! 그 사이 저는 평생의 반려자와 귀여운 제 분신 아가 효주를 만났었네요. 사실 지금 제 블로그 주소 gywn.net은 딸 이름 효주.net에서 비롯되었습니다. ^^; 딸바보가 되었다능.. 부끄 -_-;;

DBA로 전향하고 DBA파트가 생기고, 본격적으로 회사에서 오라클 라이선스 관련 프로젝트와 성능 튜닝 프로젝트.. 그리고 MySQL.. 그렇게 DB하는 개발자에서 개발 하는 DBA로의 본격 삶은 이렇게 시작되었네요. ^^

오라클 라이선스 축소 프로젝트 이후 남은 몇 개 서버를 DBA 전용 테스트 서버로 용도 변경한 후에 수많은 테스트를 수행하였습니다. 그리고 테스트한 결과를 과감히(?) 사내 통계 수집 서버에 적용을 해보았죠. 함께 진행하던 친구.. 당시 많이 힘들었답니다. 많이도 벌려놔서..ㅋ 미안 신호야~! 그치만 재밌었잖어!

IT인프라실 워크샵

IT인프라실 워크샵

아마존 RDS도 경험을 해보고, 성능이 취약한 DB도 긴급 튜닝도 해주고.. 사내 표준을 세워 전체적으로 적용을 “강행”하기도 하고.. 그냥 하고 싶은 것, 재미있는 것 모든 것을 가리지 않고 시도했습니다. 일을 꽤 많이 벌여놔서 몸이 열개라도 모자를 지경이었지만, 이 시간.. 전 많이 배웠습니다.

그리고.. 제 인생의 또 다른 터닝 포인트가 되었던 사건.. 2011년 H3 발표.. 워낙 말재주도 없고 대중 앞에서 긴장을 하는 저로서는 위염이 날 정도로 많은 긴장 속에서 프리젠테이션을 준비하였습니다. 어찌나 PT 속에 “재미 요소”를 강조하시던지.. 천성이 재미없어서 죄송했습니다. ㅋㅋ

H3를 무사히 마치고 나서야, 드디어 조금은 남들이 볼만한 PT를 사람답게 만들 수 있는 역량이 생겼습니다. 물론.. 아직도 너~무 부족한 것은 사실입니다. ㅜㅜ 2012년은 이제 한 사람으로서 조금은 성장한 가장 커다란 기회였다고 생각합니다.

이것 말고도.. 장황하게 얘기할만한 수많은 이야기.. 추억.. 그치만 일단은 여기까지!!

한모씨와의 단란했던 한때

한모씨와의 단란했던 한때

지금보다 더욱 재미있는 놀이(?)를 찾아 정든 터를 떠납니다. 대졸 신입사원으로 들어와 5년 간의 긴 여정을 마무리하고 저 이제 KTH 떠나요. 보잘 것 없는 능력을 가진 제게 감사할 정도로 좋은 기회를 주셨던 모든 분들, 함께 즐겁게 일했던 동료, 내 부사수 “임창선” <== 말 안하고 가면 삐질듯!! 여기에 창선처럼 이름을 안써줬다고 삐지실 분은 제게 트윗(@gywndi)로 날려주시면 이름에 밑줄과 굵은 글자로 강조하여 적어드리도록 하겠습니다!!

참고로 아래 사진은 꼭 넣어달라는 임창선 군의 완곡한 부탁으로 넣은 사진입니다.ㅋ

콜린, 창선과 함께

콜린, 창선과 함께

이렇게 떠나지만, 지금은 마지막이 아닌 새로운 시작이라고 생각해요. 새로운 재미를 찾아서, 뭉클한 배움을 위하여, 더 큰 가능성을 찾아서 다시 출발선 상에 제 발을 올립니다. 두렵지만 두렵지 않습니다. 이제 시작인걸요~! 제 인생은!! ^^

그동안 감사했습니다. 모든 분들.. 그리고 안녕 KTH(김태희!? 우웅 =_=;;ㅋ)

MariaDB/Galera Cluster 기술 노트!!

Overview

MariaDB에서 MariaDB/Galera Cluster 제품군을 새롭게 출시하였습니다.MariaDB/Galera는 MariaDB의 Synchronous 방식으로 동작하는 다중 마스터 클러스터입니다.

MariaDB/Galera Cluster은 Galera 라이브러리를 사용하여 노드 간 데이터 복제를 수행합니다. 물론 아직은 Alpha 버전으로 발표되기는 했지만, 조만간 안정적인 버전이 릴리즈 되면 상당한 물건이 될만한 놈입니다.

오늘은 이에 관해 간단하게 리뷰를 하겠습니다.

Feature & Benefits

먼저 MariaDB/Galera Cluster의 특징은 다음과 같이 몇 가지로 나눠볼 수 있습니다.

  • Synchronous 방식으로 노드 간 데이터 복제
  • Active-Active 방식의 다중 마스터 구성 – 모든 노드에서 읽기/쓰기가 가능
  • 클러스터 내 노드 자동 컨트롤 – 특정 노드 장애 시 자동으로 해당 노드 제거
  • 자동으로 신규 노드 추가
  • 완벽한 병렬적으로 데이터를 행단위로 복제
  • 기존의 MySQL 클라이언트 방식으로 동작

cluster-diagram1
출처 : http://www.percona.com/doc/percona-xtradb-cluster/_images/cluster-diagram1.png

이와 같은 특징에서 전통적인 Asynchronous 방식의 리플리케이션이 가지는 한계점이 해결됩니다.

  • 마스터/슬레이브간 데이터 동기화 지연 없음
  • 노드 간 유실되는 트랜잭션이 없음
  • 읽기/쓰기 모두 확장이 가능
  • 클라이언트의 대기 시간이 줄어듬 – 데이터는 로컬 노드에 존재

하지만 Replication이 가지는 본연의 한계점은 여전히 내재합니다.

  • 신규 노드 추가 시 부하 발생 – 신규 노드 추가 시 모든 데이터를 복사해야 함
  • 효과적인 쓰기 확장 솔루션에는 한계 – 서버 간 Group Communication시 트래픽 발생
  • 모든 서버 노드에 동일한 데이터를 유지해야 함 – 저장 공간 낭비

MariaDB/Galera Cluster

MariaDB/Galera cluster는 Galera 라이브러리를 사용하여 리플리케이션을 수행한다고 하는데 Galera Replication은 어떤 방식으로 동작할까요?

Galera Replication은 wsrep API로 노드 간 통신을 하며, MariaDB 측에서는 wsrep API에 맞게 내부적인 개선하였다고 합니다. MySQL-wsrep는 https://launchpad.net/codership-mysql에서 시작한 오픈소스 프로젝트입니다.

MySQL-wsrep는 MySQL의 InnoDB스토리지 엔진 내부에서 Write Set(기록 집합 : 트랜잭션의 기록하는 모든 논리적인 데이터 집합)을 추출하고 적용하는 구현됩니다. 노드 간 Write Set을 전송 및 통신을 위해서는 별도의 리플리케이션 플러그인을 사용하며, 리플리케이션 엔진은 wsrep에 정의된 Call/Callback 함수에 따라 동작합니다.

1) Synchronous vs. Asynchronous

먼저 Synchronous와 Asynchronous 리플리케이션의 차이점에 대해서 설명하겠습니다.

리플리케이션의 두 가지 방식의 가장 기본적인 차이점은 클러스터 내 특정 노드에서 데이터 변경이 발생하였을 때 다른 노드들에 동시에 데이터 변경이 적용되는 것을 보장는지 여부에 있습니다.

Asynchronous 방식의 Replication은 마스터 노드에서 발생한 변화가 슬레이브 노드에 동시에 적용되는 것을 보장하지 않습니다. 마스터/슬레이브 간 데이터 동기화 지연은 언제든 발생할 수 있으며, 마스터 노드가 갑자기 다운되는 경우 가장 최근의 변경 사항이 슬레이브 노드에서는 일부 유실될 수도 있는 가능성도 있습니다.

Synchronous 방식의 Replication은 Asynchronous에 비해 다음과 같은 강점을 가집니다.

  • 노드 장애 시에도 데이터 유실 없이 높은 가용성 달성
  • 트랜잭션은 모든 노드에서 동시 다발적으로 발생
  • 클러스트 내 모든 노드 간 데이터 일관성을 보장

그러나 Synchronous Replication 수행을 위해서는 2단계 Commit 필요하거나 분산 잠금과 같은 상당히 느린 방식으로 동작합니다.

Synchronous 방식의 Replication은 성능 이슈와 및 복잡한 구현 내부적으로 요구되기 때문에 여전히 Asynchronous 방식의 Replication이 널리 사용되고 있습니다. 오픈 소스 대명사로 불리는 MySQL과 PostgreSQL이 Asynchronous 방식으로만 데이터 복제가 이루어지는 것 또한 그와 같은 이유에서입니다.

2) Certification Based Replication Method

성능 저하 없이 Synchronous하게 데이터베이스 리플리케이션을 구현하기 위해 “Group Communication and Transaction Ordering techniques”이라는 새로운 방식이 고안되었습니다. 이것은 많은 연구자들(Database State Machine Approach and Don’t Be Lazy, Be Consistent)이 제안했던 방식으로, 프로토타입 구현해본 결과 상당한 발전 가능성을 보여주었던 바가 있습니다.

Galera Replication은 높은 가용성과 성능이 필요한 어플리케이션에서는 상당히 쉽고 확장 가능한 Synchronous 방식의 리플리케이션을 제공하며 다음과 같은 특징이 있습니다.

  • 높은 가용성
  • 높은 투명성(알기 쉽다는 의미)
  • 높은 확장성(어플리케이션에 따라 거의 선형적인 확장까지도 가능)

Galera 리플리케이션은 분할된 라이브러리와 같이 동작하고, wsrep API로 동작하는 시스템이라면 어떠한 트랜잭션과도 연관되어 동작할 수 있는 구조입니다.

3) Galera Replication implementation

Galera Replication의 가장 큰 특징은 트랜잭션이 커밋되는 시점에 다른 노드에 유효한 트랜잭션인지 여부를 체크하는 방식으로 동작한다는 점입니다. 클러스트 내에서 트랜잭션은 모든 서버에 동시에 반영되거나 전부 반영되지 않는 경우 둘 중 하나입니다.

트랜잭션 커밋이 가능한 여부는 네트워크를 통해서 다른 노드와의 통신에서 결정합니다. 그렇기 때문에 커밋 시 커밋 요청에 대한 응답 시간이 존재하죠. 커밋 요청에 대한 응답 시간은 다음 요소에 영향을 받습니다.

  • 네트워크 왕복 시간
  • 타 노드에서 유효성 체크 시간
  • 각 노드에서 데이터 반영 시간

여기서 재미있는 사실은 트랜잭션을 시작하는 시점(BEGIN)에는 자신의 노드에서는 Pessimistic Locking으로 동작하나, 노드 사이에서는 Optimistic Locking Model로 동작한다는 점입니다. 먼저 트랜잭션을 자신의 노드에 수행을 하고, 커밋을 한 시점에 다른 노드로부터 해당 트랜잭션에 대한 유효성을 받는다는 것이죠. 보통 InnoDB와 같이 트랜잭션을 지원하는 시스템인 경우 SQL이 시작되는 시점에서 Lock 감지를 하나, 여기서는 커밋되는 시점에 노드 간 트랜잭션 유효성 체크를 합니다.

위 그림에서 커밋되는 시점에 마스터 노드에서 슬레이브 노드에 이벤트를 날립니다. 그리고 슬레이브 노드에서 유효성 체크 후 데이터를 정상적으로 반영하게되면 실제 마스터 노드에서 커밋 완료가 되는 것이죠. 그렇지 않은 경우는 롤백 처리됩니다. 이 모든 것은 클러스터 내부에서 동시에 이루어집니다.

4) Galera Replication VS MySQL Replication

CAP 모델 관점에서 본다면 MySQL Replication은 “Availability”과 “Partitioning tolerance”로 동작하지만 Galera Replication에서는  “Consistency”과 “Availability” 로 동작한다는 점에서 차이가 있습니다. MySQL Replication은 데이터 일관성을 보장하지 않음에 반해 Galera Replication은 데이터 일관성을 보장합니다.

C – Consistency (모든 노드의 데이터 일관성 유지)
A – Availability (모든 노드에서 항시 Read/Write이 가능해야 함)
P – Partitioning tolerance (내부 네트워크 단절 시에도 정상적으로 작동해야함)

5) Limitations

현재는 Alpha 버전으로 릴리즈되었고, 추후 안정적인 버전이 나오겠지만, 태생적으로 가지는 한계가 있습니다.

데이터 일관성 유지를 위해서 트랜잭션이 필요한 만큼, 트랜잭션이 기능이 있는 스토리지 엔진에서만 동작합니다. 현재까지는 오직 InnoDB에서만 가능하다고 하네요. MyISAM과 같이 커밋/롤백 개념이 없는 스토리지 엔진은 데이터 복제가 이뤄질 수 없다는 점이죠.

Row 기반으로 데이터 복제가 이루어지기 때문에 반드시 Primary Key가 있어야 합니다. Oracle RAC와 같이 공유 스토리지에서 동일한 데이터 파일을 사용한다면 Rowid가 같으므로 큰 문제가 없겠지만, 물리적으로 스토리지가 독립적인 구조이기 때문이죠. 이것은 기존 MySQL Replication에서도 주의하고 사용해야할 사항이기도 합니다.

최대 가능한 트랜잭션 사이즈는 wsrep_max_ws_rows와 wsrep_max_ws_size에 정의된 설정 값에 제약을 받으며, LOAD DATA INFILE 처리 시 매 1만 건 시 커밋이 자동으로 이루어집니다.

트랜잭션 유효성이 커밋되는 시점에서 이루어지며, 동일한 행에 두 개의 노드에서 데이터 변경을 시도한다면 오직 하나의 노드에서만 데이터 변경이 가능합니다.

또한 원거리 리플리케이션 경우 커밋에 대한 응답 요청으로 인하여 전반적인 시스템 성능 저하가 발생합니다.

Conclusion

MariaDB/Galera Cluster은 전통적인 MySQL Replication이 가지는 가장 큰 문제점이었던 데이터 동기화 지연과 노드 간 트랜잭션 유실 가능에 대한 해결책을 제시합니다.

또한 노드 내부에서는 InnoDB 고유의 트랜잭션으로 동작하고, 실제 커밋이 발생하는 시점에 다른 노드에게 유효성을 체크 및 동시 커밋한다는 점에서 재미있는 방식으로 동작하죠. 결국 기존 MySQL 아키텍트는 그대로 유지하고, Replication 동작에 관한 방법만 수정하여 RDBMS 기반의 분산 DBMS 를 내놨다는 점에서 상당히 흥미로운 제품입니다.

그러나, 동일한 데이터 변경 이슈가 많은 서비스 경우 노드 간 데이터 충돌이 자주 발생 가능성이 있을 것으로 판단됩니다. 데이터 충돌이 발생하여 자주 트랜잭션 롤백이 발생하면 사용자 별로 원활한 서비스 사용이 불가하니, 이에 대한 대책을 어플리케이션 레벨에서 적절하게 고려하여 서비스 설계를 해야 하겠죠. 예를 들어 노드 단위로 주로 변경할 데이터를 나눠서 처리하는 방식으로 서비스 설계가 이뤄져야하지 않을까 생각합니다.

Synchronous 방식으로 노드 간 데이터 복제가 이루어진다는 점에서 아주 반가운 소식이기는 하지만, 기존과 같이 데이터를 설계하면 오히려 서비스 안정성이 크게 떨어질 수도 있다는 점에서 새로운 변화가 예상됩니다.

관련 벤치마크와 안정성 검토가 반드시 필요합니다. 데이터는 거짓말을 하지 않으니..^^

감사합니다.