트랜잭션 엔진 일람

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

튜링 머신

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

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

Redux 공부 필기

  1. Redux의 혁신은 상태를 한곳에 몰아넣은 것, 상태와 ‘상태 변경자’들을 분리한 것이다. 맞다, WAS들이 이미 하고 있는 그것 맞다. (AWS Lambda가 왜 ‘람다’인지 생각해보라.)
  2. 상기 혁신을 통해 핫 리로딩(hot-reloading)을 지원한 것이 키 피처중 하나였다. 역시 WAS들이 이미 하고 있는 그것 맞다.
  3. 모듈화는 상태를 찢어놓음으로 달성한게 아니라 함수를 찢어놓음으로 달성한다. 찢어진 함수들은 ‘함수 합성’을 통해 다시 합쳐질 수 있다.
  4. 키 피처중 다른 하나는 시간 여행 디버깅(Time Travel Debugging)이다. (Redux라는 네이밍의 중의적 의미중 하나. 후술.) Visual Studio나 WinDbg에서 지원하는 그거 맞다. 다만 Redux가 먼저 나왔고 따라해도 VS와 WinDbg가 따라했을 것 같다.
  5. 시간여행의 비결이 뭐냐? 애플리케이션 상태를 1개의 불변(immutable) 객체에 저장하는 것이다. 상태가 바뀔 때 어떠카냐고? 불변형 객체를 하나 새로 만들면 된다.
  6. 그렇게 하게되면 메모리 사용량이 무식하게 늘어나지 않냐? 아니다. 최적화되어 필요한 부분만 증분으로 늘어난다. 즉 상태변경을 하는 일반 애플리케이션과 큰 차이가 없다. (특히 웹앱의 생명주기상 더욱 문제 안된다.)
  7. 메모리 사용량이 폭증하지 않는 마법의 비결이 뭐냐? 답은 의외로 간단했다. 얕은 복사(Shallow Copy)다. 진짜 천재다.
  8. 물론 이상 모두 Redux의 핵심을 짚었다고 할 수 없다. Flux – Redux 진화 라인의 핵심은 액션의 단방향 흐름이다. 즉 이벤트 소싱이다.
  9. 이벤트 소싱과 상태의 예측성 모두 게임 쪽에서 훨씬 일찍부터 태동하고있던 사상이었고, DB쪽에서는 옛날부터 이미 구현된 현실이었다.
  10. 물론 수렴 진화(Convergent evolution)에서 그 어떤 가지도 모두 동등하게 중요하고 대체불가하다.
  11. 함수형 프로그래밍 신도들은 immutable 의 승리가 보일 것이고, 데이터베이스 힙 가이들은 “THE LOG IS THE DATABASE”가 보일 것이고, 이벤트 소싱파들은 이벤트 소싱이 보일 것이고, CRDT연구자들은 CRDT가 보일 것이고, Redis 애호가들은 Redis가 보일 것이고, 블록체인 신도들은 블록체인이 보일 것이다.
  12. “Redux”는 “Reduce”(“맵리듀스”의 그 “리듀스” 맞다)와 같은 라틴어 어원을 갖는다. 위에서 언급한 것처럼 “(과거의 것을) 되찾음”이란 뜻이 있다. 그리고 reduce는 함수형 프로그래밍에서 잘 알려진 패턴인데 억지번역을 해보자면 ‘귀납 합병’ 같은거다. 필자도 지금 알게 된건데 “fold”가 더 표준적인 용어더라.
  13. 정말 블록체인으로 Redux를 구현한 사람이 있다.
  14. Redux는 놀랍도록 짧다. 핵심 코드 99줄 구현을 갖고있는 것으로 유명하다. 그도 그럴것이 React Europe이란 컨퍼런스에 ‘핫 리로딩’ 관련 기술공유를 하기 위해 PoC 목적으로 급조해 만들어졌다고 한다. (거봐 그냥 WAS를 본딴거라니까)
  15. Redux 발명자는 이미 페이스북에서 채갔다.

Kotlin언어 성공사례: Corda 블록체인(by R3)

Kotlin언어? 뭔 듣보잡? 성공사례가 있니?

찾아보니 있다.

corda_kotlin.png

CTO는 전 구글 시니어 엔지니어였다고 한다. CTO분이 얘기하신 Kotlin 선택 원인:

  1. 정적 타이핑 (그러고 보니 밀레니얼 세대 언어는 다 그런 것 같다)
  2. Java가 비즈니스 월드에서 중요해서. (하긴)
  3. 섹시해서 (구닥다리 Java랑 비교하니 그렇지)
  4. 배우기 쉬워서 그래서 구인이 쉬워서 (보통 Java구인을 하고 1~3일 트레이닝 시키면 코틀린 언어 코딩을 할 수 있다고 한다)
  5. IDE지원 잘되서
  6. 컴파일 속도가 빨라서 (Scala 저격하며)
  7. 문서화가 잘돼있어서
  8. 내가 할줄 알아서. 내가 좀 해봤는데 재밌어서

그러면서 하는 말이 Kotlin이 없었다면 Scala 썼을 것이라 한다.

마지막에 내린 결론이: 잘한 것 같다.


 

개인적으로 Kotlin이 정말 반갑다. JVM팬으로서 항상 언어가 아쉬웠는데, Java는 구닥다리고, Scala는 너무 복잡하고* Groovy는 언어가 아쉽고, (Scala 와 Groovy공통점이 모두 창립자가 포기했다는 점..) Clojure는 대중성을 전혀 염두에 두지 않은 것 같고. 그런 점에서 Kotlin은 JVM에게 복음과도 같았다.

특히 실행 가능한 환경이  JVM / Javascript VM / Native 로 다양해서 플랫폼에 발목 잡히는 일이 없도록 했다는 점도 칭찬하고 싶다. (마이크로소프트가 최근에야 터득한 점)

JVM, V8엔진, 네이티브 세가지 모두 점점 중요해지는 플랫폼인 것 같다. 아 WASM(Web Assembly)까지 지원하면 더욱 좋겠지만. 이게 미래가 될 수도 있으니. 걱정할 필요가 없는게 컴파일러 플랫폼이 LLVM이어서 WASM이 GC만 지원하면 WASM으로 컴파일 하는 것도 식은 죽 먹기일 거라는 점.

최근 홍민희님의 PyConKr 2017 발표 <파이썬과 다이아스포라>를 보고, 최근에 읽은 <사피엔스>와 결부해서 느낀 점이: 성공한 언어들은 모두 대중성을 키 피처로 치밀하게 기획된 것 같다는 점이다. 민족의 용광로처럼 말이다. (적어도 대량 전파됨을 성공의 척도로 본다면 그렇다)

심지어 Rust도 너무 결백증스러운 면이 있어서 대중성이 의심스럽다.

다행히 Kotlin은 대중성을 키 피처로 설계된 듯하다. 그것의 일환으로 Java월드 레거시에 대한 포용성도 잘 설계된 것 같다.

미래가 지켜볼만하지 않은가!

* 참고로 R3 Corda의 경쟁상대인 IBM hyperledger fabric 은 Go언어로 만들었다.

부록

* TIOBE 프로그래밍 언어 유행도 인덱스에 따르면 Scala는 D언어나 COBOL언어보다 인기가 적다: https://www.tiobe.com/tiobe-index/

 

블록체인은 성능이 개판인가?

개판이 아니다. 이건 미래 얘기가 아니라 현재 얘기다.

성능문제를 앓고 있는 것은 비트코인 네트워크이지 현역 블록체인 기술이 아니다.

다들 아시다싶이

비트코인 네트워크는 7 TPS 성능상한에 시달리고 있고, 이더리움 네트워크도 25 TPS 의 성능상한과 그리 멀지 않았다.

하지만 현역 Bitshares 블록체인DPoS 기술로 테스트 네트워크에서 3000 TPS 성능을 내기도 했다(그리고 출처). 비평자들은 이것이 어느정도 중앙화의 타협으로 이뤄낸 치팅이라고 하지만, 여기에서도 종교전쟁이 등장하는데, DPoS 파의 주장에 따르면 블록 생산노드수의 시점에서 DPoS 만큼 탈중앙화된 시스템도 없다고 한다.

3000 TPS 라면 Reddit 의 쓰기성능 요구를 커버하고도 남는다 [1]. 읽기는 어차피 캐싱과 CDN 으로 해결할거니까.

오프체인 연동도 현역기술이다

오프체인에 데이터를 두고 온체인에는 메타데이터만을 두는 것으로도 어마어마한 성능향상을 가져온다. 흔히들 알고있다싶이 블록체인은 공간사용에 있어서 비효율적이다. 하지만 오프체인 데이터를 통해 Sia coin 이나 Storj 같은 클라우드 (fog) 스토리지 블록체인도 현역이다.

여기까지는 현역 얘기고 지금부터는 미래 얘기다.

이더리움은 최초의 튜링 컴플릿 블록체인이다. 따라서 이더리움의 성능 확장 문제만 해결 하면 사실상 이더리움의 도미네이션이 예상된다. 따라서 이더리움의 성능 확장 로드맵을 살펴보기로 하겠다.

2017년 6, 7월쯤에 Raiden 네트워크 출시가 예정되어 있다

Raiden 네트워크는 비트코인쪽의 SegWit 과 라이트닝 네트워크 기술을 베꼈다 모티브로 한다. 이 기술은 외계기술인데, 요즘 블록체인 기술을 좀 안다 하는 사람들은 모두 이 기술을 이해할 것이다. 이 기술때문이 아니었다면 크립토커런시 시장이 시총 현재 10% 일때 자금유입이 멈췄을 것이라 생각된다.

이 기술이 왜 대단하냐면 이 기술이 (일부 까다롭지 않은 전제조건하에서) 성능을 거의 무한으로 끌어올릴 수 있기 때문이다. Too good to be true? Do your research.

Continue reading