주말에 Erlang OTP(Open Telecom Platform)에 대한 학습과 생각을 조금 해봤다.
OTP라는 줄임말이 주는 의미보다 더 큰 가능성과 기능을 가지고 있다는게 가장 처음 든 생각이였다.
대용량(large-scale), 에러에 강한(fault-tolerant) 분산 어플리케이션을 만들 수 있는 하나의 어플리케이션 운영체제라는 말이 맞을 정도다.
요걸 보다보니 이런 어플리케이션을 만들고 싶다는 생각이 불끈 불끈 솓아 오른다.
OTP를 보면서 이를 이용해 웹 크롤러 시스템을 만들면 어떨까 하는 생각이 가장 먼저 들었다.
OTP의 supervision tree를 이용해 다수의 크롤러 프로세스를 관리하는 그런 모습을 그려봤다. 무엇보다 크롤러 코드
업그레이드를 할때 굳이 크롤러 시스템을 셧다운 하지 않고도 가능하게 될테고, 어떠한 충돌이 일어날때에도 다시 살아나게끔 만들수
있을 것이다. 게다가 얼랭 프로세스는 굉장히 가벼우니 동적으로 웹페이지 다운로딩하는 프로세스의 개수를 자유롭게 핸들링 가능할것이다.
하지만 얼랭으로 이걸 만든다 하더라도 한가지 아쉬운 점이 있다.
이런 분산 어플리케이션을 가장 안정적으로 만들수 있는 언어라는데는 이견이 없지만 내부적으로 데이터 처리를 할 수 있는 라이브러리가 좀 부족하다는 것은 어쩔수 없는 현실인거 같다.
단적인 예로 텍스트 처리를 할 수 있는 정규식 라이브러리의 기능이 많이 빈약하다.(많은 정규식 옵션이 누락되어 있고 Search기능도 없다.)
따라서 예외가 많은 텍스트 처리를 할때 코드가 복잡해지는 측면이 없지않아 있을 것이다.
게다가 이뿐만 아니라 전반적으로 텍스트 처리 라이브러리의 기능이 많이 취약하다.
그래서 2가지 언어를 사용해서 이런 어플리케이션을 만들면 어떨까 고민이 된다.
메인 서버 클라이언트 로직의 얼개는 OTP와 얼랭으로 하고 내부적인 프로세싱 작업을 하는 것은 C++이나 Python같은 텍스트 처리가 편한 절차형 언어로 하는 것이다.
그런데, 이런 두가지 언어를 혼합해서 사용하기에 편한 방법이 얼랭에서는 거의 없다.
Python같은 편리성을 기대했던게 무리였나?
좋은 라이브러리를 기다리거나, 아니면 얼랭에서 두가지 언어를 혼용해서 쓰는것에 익숙해 지거나…
하지만 후자가 더 재미있을거 같다.
얼랭과 사랑에 빠지다.(from http://www.chetanmittal.com)
고감자님과 같은 분들이 ‘좋은 라이브러리’를 차곡차곡 만들어주시는 한 가지 방법이 더 있습니다!
(내가 하겠다는 얘기는 결코 안 함;;;;; )
네.. ㅠㅠ
제 개발팀은 그것 때문에 결국 자바로 돌아섰지요 (..) 하다못해 별거 없는 RSS 리더 만드는 것조차 인코딩 등등의 문제로 무수히 삽질했으니까요 -_-;; XML 파서도 뭐.. (한숨)
역시 아직 얼랭은 모든 영역에 가장 편한 언어는 안되는거 같습니다.
안녕하세요~ 얼랭 초보입니다. 궁금한 점이 있어서요~
실례가 안된다면 어쭙고 싶은데요. +_+
얼랭의 메세지 전달 방식의 병행성?이 기존의 락 기반의 쓰레드에 비해 단점이라고 할 부분이 어떤것이 있을까요? +_+
그리고 ‘좋은 라이브러리’의 부재의 문제가 있었군요.. 이것말고도 다른 단점이 있을까요?
읽어주셔서 감사합니다. :-]
제 경험상 말이죠…^^
얼랭에서는 수많은 동일한 작업을 하는 프로세스에 각각 메시지를 분배할때 그 시점이 가장 큰 병목이라 생각합니다.
아마도 제가 월간 마소에 쓴 map/reduce 플랫폼 기사를 보시면 더 이해하기 좋을 거라 생각합니다.
하지만 이는 작업의 특성을 잘 정의해주면서 프로세스의 개수 및 작업 영역을 잘 정의해주면 됩니다.
데이터의 전송 효율이 프로세싱 효율보다 좋지 않다면 큰 효과는 발휘하지 못하고, 프로세싱 효율이 더 좋다면 큰 효과를 보지 않을까요?
그러니까 전송 데이터는 작게, computation은 큰 그런 작업일때 엄청난 효과를 발휘합니다.
락 기반의 프로세싱도 역시나 병목이 있죠, 락으로 둘러쌓인 코드 부분이 그곳이죠. 이걸 임계영역이라고 하던가…?? ^^;
서로간의 장 단점이 있고 병목도 분명히 존재하나, 얼랭의 가장 큰 장점은 락기반 방식에서 빈번하게 나올 수 있는 디버깅이 힘든 에러들을 문법적으로 방지한다는 점이죠. 공유메모리가 없다는건 입력 인자가 같으면 결과가 같음을 보장합니다.
이점은 기존 절차형 언어와 가장 큰 차이점이고, 얼랭이 병행 프로그래밍에 강하게 만들어주는 장점입니다.
제가 어느 문서에서 봤는데 이 공유메모리 방식의 언어에서 병행 프로그래밍의 구현이 힘든 이유가 바로 포인터의 존재라는 점이 참 아이러니 하죠. 가장 큰 장점이 단점이 될수도 있다는게…
개인적으로는 얼래의 메세지 전달 방식의 단점은, 큰 데이터의 경우도, 공유 방식이
아니므로 메시지에 대량의 데이터를 실어보내야 하지 않을까? 하는 생각이듭니다.
락이 비용이 클지, 대량 데이터 전송에서 나오는 비용이 클지는 잘 모르겠군요. ^^
네..그렇게 생각하실 수 있겠지만, tail recursion으로 메시지를 던져 status를 유지할 경우 계속 유지만 시키는 데이터에 대해서 메시지로 던지면 되기 때문에 가비지 컬렉션 로직이 간단해진다고 생각합니다. 왜냐면 phase가 지나면 이전에 쓰던 변수들은 바로 메모리 해제를 해도 무방하므로 하나의 데이터만 유지하게 되거든요.
단지 메시지 전달하는 데이터만 신경쓰면 되는 장점이 있죠.
그래서 제 생각으로는 이건 큰 문제가 되지 않고 다른 스크립트 언어에 비해서 메시지 전달 방식의 얼랭이 가지는 메모리 관리의 특징이 될 수 있다는 생각이 됩니다. ^^
포인터 연산을 할수 있는 언어의 메모리 공유방식이 가지는 장점때문에 수많은 다른 에러의 원인이 된다는건 익히 아시는 부분이라 생각합니다.
프로그램이 복잡해질 수록 이는 더 큰 원흉으로 발전할 가능성이 많아지죠.
확실히 말씀하신데로.. String에 대한 처리나 Regular Expression같은 처리에 대해서 미흡한 것이 걸리네요 ㅠ.ㅠ
다행이도 얼랑의 Library를 공식적으로 등록하는 사이트에 가보면 Erlang Lexer등이 라이브러리 형태로 올라와 있는 것을 확인할 수 있기는 합니다만…
찾아서 사용법을 익히는 것도 약간은 큰 일이니 …
이런 얘길 들으면 또 얼랭에 대한 관심이 식기도 하고…