트랜잭션 엔진 일람

사람들이 말하는 프로그래밍은 대부분 원주율 계산이 아니라 소프트웨어 시스템 구축이다. 소프트웨어 시스템 구축에 있어서 애플리케이션 상태 관리가 핵심이다. 따라서 백엔드 프로그래밍에서 트랜잭션 엔진이야말로 핵심 요소다. 그 중요성이 너무 덜 강조된 것과 대조되게 말이다.

튜링 머신

당연히 모든 트랜잭션 처리 수단은 이 범주에서 벗어나지 못한다. 문제 연산을 위해 발명되었지만, 소프트웨어 시스템 구축에 더 많이 쓰이는 것 같다.

메모리(Random Access Memory)

메모리에서 당연히 트랜잭션을 처리할 수 있다. 문제는 트랜잭션 중간 상태에서 정전이나 고장이 발생할 경우, 트랜잭션의 원자적 적용에만 실패하는 것이 아니라, 원 상태마저 누락하는 재난이 발생해버린다.

우리가 사용하는 메모리 장치가 용량이 무한대이고 절대 정전이나 고장이 발생하지 않는 추상적인 “완벽한” 메모리라면 데이터베이스를 발명할 필요도 없었을 것이다.

관계형 데이터베이스(RDBMS)

흔히 백엔드 프로그래밍에 node.js를 써야 하나 python을 써야 하나 하는 토론이 발생하지만, 정작 중요한 부분은 왕왕 DBMS 쪽이라는 것이 간과되곤 한다. RDBMS는 오랜 역사 기간동안 트랜잭션 엔진 영역의 왕좌를 지켜왔다. 그러다 최근에 왕좌에서 끌려 내려왔는데, 스케일 문제 때문이었다. RDBMS는 수평확장성이 좋지 않았다.

여러 문서간 트랜잭션을 지원하지 않는 NoSQL

애플리케이션이 트랜잭션 처리 기능을 포함해야 한다. 이것을 잘하기 아주 어려움. 잘 해도 더러워짐. 확장성의 대가.

액터 모델(Actor Model)

애플리케이션이 트랜잭션 처리 기능을 포함해야 한다. 쉬운 확장성의 대가. 액터 모델은 상태 변경 명령을 전달하는 방식으로 작동한다. 다중 객체 상태의 동시 settlement에 약하다.

LMAX 아키텍처 (싱글 스레드, 이벤트 소싱을 통한 레플리케이션)

이 방식은 LMAX 외환 거래소, 한국거래소, 됴쿄증권거래소, 상하이증권거래소 같은 곳에 모두 적용되어 있다. 한마디로 높은 빈도의 트랜잭션 처리 영역을 장악하고 있다.

싱글스레드 모델. 수평확장 불가. 아이러니하게 TPS가 가장 높음 (6백만 TPS) . 저장공간 수평확장 불가한 것이 최대 단점.

참고: https://martinfowler.com/articles/lmax.html

고신뢰성 분산 키값 저장소 (a.k.a 분산 코디네이터)

Apache Zookeeper, etcd, Google Chubby 등 구현이 있다.

분산 저장소지만 기본적으로 중앙화된 저장소라고 봐야 한다. 다만 클라이언트에 데이터 누락의 위험 없이 최신 상태를 지속적으로 (최종 일관성) 동기화 해준다는 보장을 한다. (클라이언트로의) 분산 동기화에 특화되어 있는 저장 백엔드라고 봐야 한다.

장점:

  • 거의 완벽한 안전성.

단점:

  • 여러 문서간 트랜잭션 기능 미제공
  • TPS
  • 수평확장 불가

트랜잭션 기능 있는 클라우드 스케일 NoSQL DBMS

단점이 거의 없음. ACID + 확장성. 레이턴시를 대가로 CAP 모두 만족할 수 있음. 범용적임.

가상 액터 + 트랜잭션 패치(즉 Microsoft Orleans)

레플리케이션 불가. 하지만 상태 랜딩 (영구화) 백엔드가 레플리케이션 기능 있는 DB일 경우 레플리케이션 기능 생긴다. 단 레플리케이트 되려면 컨시스턴트한 쓰기를 해야 함. 이는 레이턴시를 대가로 함. 객체 데이터베이스(Object Database)라 할 정도의 높은 표현력이 킬링 포인트. 다른 장점: 투명한 분산 / 쉬운 수평확장. Stateless 서비스에 준하는 배포 민첩성.

레플리케이션 활성화된 Redis

장점: 높은 TPS (백만 TPS), 안전성.

단점:

  • 레플리카 랙 기간동안의 아주 미약한 데이터 불안전성 (크로스 리전 20ms 대. 베어 메탈 로컬 네트워크 1ms 대)
  • Redis의 자료형 표현력의 한계 (메모리 주소 쓸 수 없음)
  • 그로 인한 프로그래밍 표현력 부족. 애플리케이션 상태 의존적인 트랜젹션은 제한된 lua로 짜야 함.
  • 수평확장 불가 (수평확장 시 트랜잭션 불가)
  • 수직 확장의 공간 한계가 낮음(메모리 한계). 콜드 데이터를 디스크로 랜딩 시키는 기제(와 온디맨드 로딩 기제)가 필요할 경우 애플리케이션 단에서 제공해야 함.

블록체인?!

크게 퍼블릭 체인과 프라이빗 체인으로 나뉨. 퍼블릭의 경우 크게 POW와 POS로 나뉨. 각각 아주 많은 종류가 있다. 종류에 따라 TPS, 데이터 redundancy 수준, 분산 공격 가능성 모두 다름. 단점도 각각 다름. 장점이 뭐냐 라고 한다면, 퍼블릭 프라이빗을 막론하고 한가지로 요약할 수 있음. 가트너의 평가를빌자면:

멀티 파티 신뢰 문제를 해결함.

(It allows untrusted parties to exchange commercial transactions.)

Gartner Top 10 Strategic Technology Trends for 2018

즉 트랜잭션 엔진의 멀티 파티 소유가 가능해짐. 그중 “파티”의 뜻은? RFC 7519(JSON Web Token)의 서언에서 말하는 “two parties”의 “파티”와 같은 뜻. 한발 나아가 그 어떤 파티에도 소유되지 않은 트랜젹션 엔진이 탄생했음을 의미. 역사상 처음으로 애플리케이션의 상태에 대한 글로벌 컨센서스를 독점 외의 수단으로 달성할 수 있게 됨.

단점: 블록체인 트릴레마(불가능 삼각형)각자 단점이 모두 다르지만, 공통된 단점: 레이턴시. 아직까지 효과적인 수평확장이나 계층화된 확장 솔루션이 구현 및 실천에서 성공한 기록이 없음(이론과 소규모실천에는 많음). 애플리케이션 상태의 비밀성 부재. 결정론성 요구 때문에 상단 애플리케이션에서 외부 상태 참조 불가.

결론

CAP 이론이 소프트웨어 개발, 그중에서도 트랜잭션 엔진에 무엇을 의미하는지 지금까지도 업계가 오해해왔던 만큼, 업계가 이 영역에 대해 모르는 것도 많을 것이다. 많은 토론이 필요한 이유다.

싱글스레드 모델이 액터 모델(Actor-Model)보다 나은 X가지 이유

1. 액션(동작) 순서 컨트롤이 된다. 액션의 페이스를 컨트롤할 수 있다. 예를 들어 30fps 로 모든 몹의 x좌표 더하기 1. 액터 모델에서는 비동기라서 그 액션이 어느 프레임에 들어갈찌 모른다.

2. 디버깅이 쉽다.
2.1 액터 모델에서는 글로벌 상태에 브레이크 포인트를 찍은 후에 매개인의 메일박스를 검사해야 하는 번거로움이..
서버의 경우 클라와 달리 브포보다 로그가 더 유용할 경우가 많다. 예를 들어서 Joe Armstrong 과 Richard Stallman 등 분들이 모두 printf 디버깅 방식을 더 선호한다는 소문이… 하지만 서버가 클라만큼 상태가 복잡할 경우, 브포(==시간정지) 를 통한 글로벌 상태 파악이 극히 중요해질 때가 있다.
2.2 그리고 액터 모델은 비결정론적이라서 어떤 버그들이 어떤때는 재현되고 어떤 때는 재현되지 않을 수 있다. (그러고보니 2.2 항목은 LMAX 의 장점만 말하면 다 나오네.)

3. 반경 10메터안 모든 몹들에게 범위공격. 액터모델의 경우 남의 좌표를 알 수 없어서 일일이 물어야 한다. “님 좌표 얼마임?” (그렇지 않으면 좌표를 좌표테이블에 등록해야 하는데, 그러면 액터모델이 아니게 됨) (IO 오버헤드, 코딩 코스트)

4. 로드밸런싱따위 필요없다. 액터모델의 경우 (스케쥴러에 따라 다르지만) (어차피 스케쥴러 연구하는 사람은 없으니) 액터 로드밸런싱이 필요한 경우가 있다(Skynet 역사 참조). 반면 싱글스레드 모델에서 프로그래머는 신이고, 로드밸런싱따위 필요없다.

5. 트랜잭션?

6. 클라도 싱글스레드 모델이잖아.

7. CPU 성능에 좋다 (동일언어) (사실 이건 가장 중요하지 않은 원인이다) (늘여쓰면 글한편감이라 자세한 내용은 생략한다).

결론: 두 모델이 서로 다른 문제 도메인 (Problem Domain) 에 적합할 것 같다는거다:

  • 액터모델은 격리성, 분산성과 faul-tolerance 가 골(goal)에서 제일 중요한 경우 또는 message-passing 자체가 문제를 잘 모델링할 경우 (IM, Instant Messenger: e.g. Facebook Messenger, Whatsapp, etc.)
  • 싱글스레드 모델은 글로벌 상태 컨트롤이 중요한 경우. 예를 들어 게임. (시뮬레이팅 문제?)

적재적소(適材適所).

길게 쓰면 아무도 안읽으니 이번에도 후딱 끝내는 미덕을 발양하겠다.

(끝)

한눈에 보는 MQ

  • coolspeed

요즘 MQ에 빠져 MQ덕질 좀 했습니다.
길게 쓰면 아무도 안읽고, 쓰는 사람도 귀찮아지니 알맹이만 적겠습니다.

ActiveMQ – 정통 MQ, 기능 많음, 트랜잭션 지원.

RocketMQ – 알리바바에서 오픈한 MQ. 지구상 가장 분주한 전자상거래 시스템중 하나인 알리바바의 인프라로 매일 높은 워크로드에서 사용되고 검증되고 있음. 세계 기록을 갱신한 쇼핑몰 오더 처리 성능.

Java로 개발됨. 활발한 개발과 (중국내) 활발한 커뮤니티. 트랜잭션 지원(그러니 전자상거래에 쓰일 수 있지).

단점: 클라이언트 언어는 Java 와 C++ 만 지원.

Apache Kafka – LinkedIn 에서 오픈. Scala 언어로 개발됨. 개발팀은 나가서 새로 회사를 차렸다는데 현재는 개발과 커뮤니티가 모두 그다지 활발하지 않음.
최대 장점은 성능. 특히 batch 모드를 켰을 때 (redis pipeline모드랑 유사).
단점: 트랜잭션 지원하지 않음.

RabbitMQ – Erlang 으로 개발됨. 성능 좋음. (거의) 모든 언어 클라이언트 제공.
AMQP의 여러 기능을 지원하는 만큼 ActiveMQ에 버금가는 다양한 피쳐.
Erlang으로 개발된 만큼 fault-tolerance 가 짱임.

ZeroMQ – 사실은 MQ가 아님. Zero * MQ == zero != MQ?
네트워크 라이브러리? 네트워크 프로토콜 스택상의 새로운 레이어? Linux커널에 들어가는 것을 목표로 한다.
끊기면 자동 재연결하는 고급 소켓. Listen 과 accept 순서 무관인 고급 소켓.

(거의) 모든 언어 클라이언트 제공. 라이트한 만큼 성능이 장점.

“ZeroMQ” 에서 “Zero”는 broker가 없음을 의미. 그만큼 분산식 차원에서 더욱 철저하다.

(무엇보다 얘는 정말 MQ가 아니기에 MQ리스트 안에 넣어서 비교하는 자체가 어색하다. MQ같은 네트워크 라이브러리.)

차세대 Go언어 게임서버 Century 뼈대

소스코드 주소: https://github.com/coolspeed/century

Amazon Gamelyft 때문에 맥나서 안짤려다가 블로그글 에서 쳐놓은 허풍들이 죄가 되여 끄적여보았습니다.

일단 현재는 실행 가능한 채팅서버이구요.

벤치마크결과는 8만5천 TPS 씩이나 나와서 벤치마크 프로그램을 의심하는 중입니다.

그 어떤 비평도 다 저에게 다 도움이 될 것이니 어떤 비평이든 아끼지 말고 주시기 바랍니다.
(라고 쓰고 “칭찬과 좋은 비평만 듣겠다” 라고 읽는다.)