트랜잭션 엔진 일람

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

튜링 머신

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

메모리(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)

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

레플리케이션 활성화된 Redis

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

단점:

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

블록체인?!

크게 퍼블릭 체인과 프라이빗 체인으로 나뉨. 퍼블릭의 경우 크게 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 발명자는 이미 페이스북에서 채갔다.

DB 정규화를 하지 않는 이유

DB 정규화를 하지 않는 이유는 한마디로 성능이다.

그렇다면 DB 정규화는 왜 성능을 해치는가?

1. DB 정규화는 테이블을 많이 나누게 하고, 테이블이 맣아지면 Join 이 많아진다. 그리고 Join 은 성능에 큰 악영향을 미친다.

1.1 Join 은 테이블 락 (Lock) 을 일으키고, 테이블 락은 병렬성의 큰 적이다.

아마 이 이유가 No-SQL 이 부상하게 된 가장 주된 원인이 아닐까 생각한다.

Python 의 GIL 이랑 같은 원리.

1.2 Join 은 여러 테이블을 가로지르는 다중 Disk-seeking 을 일으킨다. 한마디로 데이터 국지화의 적이다.

컴퓨터 하드웨어와 소프트웨어에서 많은 최적화장치들의 작동근거가 데이터 국지화이다. 이 가정이 깨질 경우 데이터 액세스가 굉장히 비싸진다.

DB 정규화는 공간을 가장 절약하는 방식이다 (i). 하지만 저장공간은 저렴하다 [1].

공간을 절약하는건 당연히 죄가 아니다. 심지어 공간을 절약해야 시간도 절약되는 경우가 많다. 그리고 이것 역시 “정규화가 성능에 좋다” 라고 주장하는 사람들의 한가지 근거이다.

하지만 알고리즘이란게 어느 선에 도달한 뒤에는 불가피하게 시간과 공간 사이의 트레이드오프에 직면하게 된다.

정규화는 공간 절약의 극한에 서있다.

이는 이론적으로도 당연하게 시간을 트레이딩 할 여지가 있음을 의미하지만, 많은 실천결과들이 역시 이 결론을 뒷받침해주고 있다.

또한 위의 1.2 와 결합시켜서 살펴보면 알게 되는데, 데이터 양을 줄인다고 무조건 시간이 절약되는게 아니라, 다수의 경우 데이터 국지화가 성능에 훨씬 큰 영향을 미친다. 이것은 실천적으로도 많이들 이중화 (Redundency) 로 정규화를 타파해 성능향상을 이룩하고 있는 산업현황과도 매칭된다.

또한 이 점은 저장 매개체의 랜덤 액세스와 순서적 액세스 사이의 수량급을 초월하는 성능 gap 의 배경속에서 더욱 확대된다. 이것은 물리적인 HDD 에서 유독 두드러지지만 SSD 에서도 상황은 비슷하다.

정규화는 쓰기에 최적화되어 있다. 하지만 읽기가 훨씬 중요하다.

Continue reading

슈퍼마리오 멀티플레이어 개발 후기

coolspeed

팀 합류 과제로 게임제작 미션을 받았다.

나는 과제로 “슈퍼마리오 멀티플레이어 게임”을 만들었다:

EnemyCD.gif

과제 결과물을 왓 스튜디오의 허락을 받고 소스코드를 Github 에 공개하였다:

https://github.com/coolspeed/MarioMultiplayer

관심 있으신 분들은 별표 하나씩 찍어 즐찾해주시길 부탁립니다.

게임 룰: 위의 GIF 움짤  그대로. 먼저 상대방을 밟는 쪽이 이긴다.

과제가 1차, 2차로 나뉘는데 1차에서는 싱글 플레이어 슈퍼마리오를 만들었고 2차에서는 그것을 멀티플레이어 게임으로 발전시켰다.

최종 클라이언트 Java (Processing) 1500 줄, 서버 C# 22줄로 짜여졌다.

클라이언트

Processing 으로 만들었다. 왜?

    1. Processing 이 좋아서. (유쾌한 시각적 프로그래밍)
    1. Unity 쓸줄 몰라서.
    1. 다른 엔진도 쓸줄 몰라서.
    1. 엔진부분이 더 재밌어서.
  1. 웹에다 배포하고 싶어서. (P5.js 를 통하여. 하지만 망했다. 그냥 일반 Processing 애플리케이션처럼 exe 파일로 빌드했다.)

서버

단순한 릴레이 서버.

big_mirror.png

넷코드

ZeroMQ 를 네트워크 라이브러리로 사용했다.

Continue reading

왜 그동안의 함수형 언어 홍보는 잘못됐는가?

그렇다. 함수형 프로그래밍과 그것을 포함하는 “선언식 프로그래밍” [1] 은 그동안 이른바 산업 프로그래밍과 산업 프로그래밍 언어의 혁신요소들의 주요 원천 중 하나였다[2]. 하지만 그동안의 함수형 언어 홍보에서는 중요한 오류들을 범했다.

예를 들어 함수형 에반젤리스트들은 아래와 같은 광고어들을 내세웠었다.

“함수형 언어에서 변수는 값이 바뀔 수 없어요. 그리고 이게 좋아요. 버그를 막아주니까.”

이걸 듣는 사람들의 반응은 아마도 당장 발이 묶인 느낌일 것이다. 그래서 “그러면 코딩을 어떻게 해요?” 라고 묻는다면, 이런 대답이 올 것이다. “변수 변경이 정말 필요할 때는 변경할 수도 있어요. 그리고 함수형 프로그래밍에서는 꼬리 재귀를 사용하지요.” 그러면서 아마도 계승(factorial)이나 피보나치 예제를 주머니에서 꺼낼 것이다.

이렇게 되면 프로그래머는 아마도 고개를 갸우뚱 하며 (말은 하지 않고) 생각할 것이다.

“그렇게 되면 어차피 명령식에서랑 똑같이 변하는 변수를 사용하지 않을까? 과연 참고 변수를 변하지 않게 사용할 수 있을까?”

“그리고 나는 일할 때 매일 계승을 짜진 않는단 말야..흠..”

Continue reading

프로그래밍 바벨탑 해결

Python 을 Go 로 번역해주는 트랜스컴파일러:

https://github.com/google/grumpy

Python 을 Go 로 트랜스컴파일한다는 것은 무엇을 의미하는가, Python이 최정적으로 네이티브 컴파일 됨을 의미합니다..

저는 어제 이 리포의 별수가 실시간으로 오르는 걸 보았습니다. 오늘은 어제 대비 별표가 많이 늘어났더라구요.

이런 갓 프로젝트를 누가 만들었나 했더니 갓 Google 님이 만들었더라구요.

이게 좀더 성숙해지면 구글은 python 으로 짜여진 유튜브를 네이티브 프로그램으로 서비스 하겠네요.

자 그러면 앞으로 이런 식으로 프로그래밍 바벨탑들이 다 해결 될 것인가?

 


하스스톤 역기획 해 python 코딩하는 알파고:

http://kotaku.com/google-deepmind-is-now-analysing-magic-and-hearthstone-1767628685

프로그래머들을 아예 다 해치울지도..? ㅋㅋㅋ

Linux 버전의 PowerShell?

마이크로소프트에서 최근에 PowerShell 로 CMD 를 대체하려 한다는 뉴스와 함께, 마소가 PowerShell 을 Linux 로도 포팅했다는 소식이 소개되면서 PowerShell 과 유닉스 파이프에 대한 토론이 있었습니다.

그것에 대해 적었던 내용들을 포스팅 합니다.

유닉스 철학의 포인트들중 일부: 바이너리 헤이터, 텍스트 성애자. 그것도 플랫하고 멍청한(KISS) 텍스트를.

McIlroy, the head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe, summarized the Unix philosophy as follows[1]:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

약간 유사한 예가 아닐까 하는게, 우리가 매일 짜는 프로그램들을 예로, 프로그램은 신택스적으로 괴앵장히 구조화된 예술품이지만, 우리는 오직 플랫한 텍스트 파일로만 컴파일러와 대화를 하죠.

Continue reading

프로그래밍의 특급 비밀

coolspeed

This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren’t aware that they know.
– Eric S. Raymond, “The Art Of UNIX Programming”

벤처캐피탈 업계에는 이런 역학이 존재합니다: 최고로 잘한 투자는 수익이 나머지 모든 투자 수익의 합보다 많다. 나머지중 최고로 잘한 투자는 나머지 모든 투자 수익의 합보다 많다.

프로그래밍에도 비슷한 역학이 존재합니다.
프로그램은 90%의 실행시간을 10%의 코드 실행에 소모합니다.[1]

이것을 통해 우리는 놀라운 추론을 해낼 수 있습니다.
시스템을 성능이 낮지만 생산성이 좋은 언어로 짜고, 그중 10% 의 핫스팟만 찾아내 C++ 로 짜면 끝.

실제로 (일부) 천재 프로그래머들은 시스템을 어떻게 설계했을까요?

1. YouTube

검색창은 Go 프로그램. 웹 애플리케이션 서버는 느린 Python 으로 짰습니다.

2. GitHub

“GitHub” 의 “Hub” 은 느린 Ruby on Rails 이고, “Git” 은 C.

3. Instagram

사진 저장은 Amazon S3 (네이티브 코드 예상). 웹 프런트는 C코드 (NginX). 데이터베이스는 C (PostgreSQL).
웹 애플리케이션 서버는 Django (Python).

4. Uber

DB: C++(MySQL)
Index: C (Redis)
애플리케이션: Javascript

Continue reading

Python 을 사용하는 대기업들 지금은 어떻게 됐을까?

Google

Google 얘기는 빼놓을 수 없다. Python 언어의 발명자 Guido van Rossum 도 구글에 계시기 때문이다.

Google 은 Python 을 좋아하다가, Go 언어를 만들었다.

특히 Python 언어의 플래그쉽같은 존재였던 YouTube, 아직도 Python 인걸로 알고 있다. 하지만 YouTube 의 검색창의 모든 검색은 Go 언어로 구현된 프로그램을 통해 일어난다고 한다. (프록시만 하는지, 구현까지 하는지는 잘 모르겠지만, 구현이야 당연히 구글의 기존 C++ 프로그램이겠지 싶다) [1]

dl.google.com 이 Go 언어로 만들어졌다고 한다. Chrome 의 압축 프록시가 Go 언어로 구현되었다고 한다. [1]

Dropbox

Dropbox 는 빠른 Python 구현인 Pyston 을 개발하다가, 이미 구현된 빠른 Python 인 PyPy 를 만지작거리다가.. 결국 Go 언어로 갈아탔다. [7]

Uber

오래되진 않았지만, 요즘은 Uber 이야말로 핫하다고 할 수 있지 않은가. 성능 크리티클한 부분을 Go 로 만들었다. (Node.js 를 고려하다가 Go 를 선택했다고 함.) [2]

Pinterest

Gevent 로 Python 을 빠르게 하다가 [3], Elixir 로 갈아탔다. [4]

참고로 Pinterest 는 MAU (Monthly Active Users) 가 1 억에 달한다고 한다. [5]

Alexa 에 의하면 Pinterest 는 Netflix.com 보다 트래픽이 많다고 한다. [6]

여담

여담으로 Ruby on Rails 로 시작한걸로 유명한 Twitter 는 Scala 로 갈아탔고, GitHub 은 음 잘 모르겠는데 아직도 Ruby on Rails 인가..?

여담중의 여담으로 Elixir 은 Ruby on Rails 핵심 커미터였던 개발자가 Ruby 로 컨커런시 처리하는 것에 지쳐서 Erlang 으로 돌아선 것이라고 한다.

결론

결론은 반전이다. YouTube 도 Python 으로 만드는데, Python 이 너무 느리게 느껴질 정도로 성공하는 서비스부터 만들고 보자. 그때까지 언어 성능은 별로 중요하지 않다.

Continue reading