Erlang 

-module(helloworld).
-export([start/0]).
start() ->
io:fwrite("Hello, world!\n").


홈페이지

1 개요

스웨덴의 에릭슨에서 개발한 함수형 병행성 프로그래밍 언어. 스웨덴 본토 발음으로 하면 에어랑이다. 얼랭, 에어랭, 엘랭, 엘랑 등 전세계 사람들이 자기들 알파벳 발음 스타일에 따라서 다양하게 발음한다. 이를 신경쓰는 사람은 아무도 없으니 안심해도 된다.[1] 오늘날 가장 널리쓰이는 병행성 프로그래밍 언어다.

2 역사

1986년 통신장비를 만드는 에릭슨사에서 교환기 및 대규모 네트워크 설비를 위한 언어로 개발하였다. 그 이유가 AT&T 연구소에서 Unix와 C언어를 개발 후 동종업계의 사용에 제약을 걸었기 때문이다. 조 암스트롱 연구원의 주도 하에 진행되었고, 함수형 언어 디자인을 선택한 것은 신뢰성과 안정성의 확보에 많은 도움이 되었다. 다른 함수형 언어들과 달리, 시작 단계부터 기업의 엄격한 릴리즈 프로세스를 반드시 통과해야 했던 Erlang의 개발은 고난의 연속이었다. 가령, 병행 프로세스 처리 및 멀티 코어 처리는 처음부터 계획된 것이 아니었다. 속도가 느려서 검증 시스템을 통과하지 못하자 당시로서는 어떻게든 쥐어 짜내다보니 한 선택일 뿐이다. 지금은 Erlang의 대표적인 특징이 되었다.[2] 개발 완료 직후 실제 작동에서 nine-nineth. 즉, 99.9999999%의 작동율이라는 경이적인 수준의 안정적인 운영을 기록하게 된다. 한 줄의 Erlang 코드는 여러 줄의 C 코드와 같은 가치를 가진 것으로 평가되었다.[3]

그런데 얼랭이 에릭슨에서 자리잡을 즈음 개발자들이 짤렸다. 에릭슨이 한참 삽을 푸던 시절에 효율성을 추구한다고 "오픈소스 비즈니스로 알아서 먹고사세요."하고 내보내 버린 것이다. 당시 기록을 보면 알 수 있지만 에릭슨의 경영진은 보통의 막장 경영진들이 그렇듯 장부상의 이익을 위해 꼬투리 잡을만한 부분이 있는 사원들을 그냥 다 해고했다[4].역시 IT기업에서는 경영학 배운 놈들이 문제 물론 에릭슨같은 기술 기업이 기술자 없이 돌아가는건 말도 안되므로 다음 CEO는 이들을 다시 회사로 모아야했다(...)

얼랭은 오늘날 병행성과 신뢰성이 요구되는 많은 분야에 활용되고 있다. Erlang VM 및 라이브러리는 하드웨어와 통신장비의 발전에 따라 꾸준히 업데이트 되고 있다.

3 특징

3.1 병행성

병행성 프로그래밍 언어인 Erlang은 가벼운 프로세스를 아주 빠르게 생성한다. 각각의 프로세스들은 메시지 패싱에 의해 작업을 지시받고 결과를 출력하며 ETS, DETS 메모리 영역을 제외하면 공유 메모리가 전혀 없도록 설계되어 있다. 이는 언뜻보기에 MPI와 유사하지만, MPI가 하나의 프로세스를 생성하는데 상당한 비용이 드는 것과 다르게 Erlang의 프로세스는 평범한 PC에서도 수십만개의 프로세스를 아무 문제 없이 실시간으로 생성하고, 실행하고, 지울 수 있다. 또한 서로다른 컴퓨터라 하여도 통신망을 통해 원격에서 프로세스가 제어될 수 있으므로 대량의 하드웨어를 묶는데 유리하다.

3.2 패턴 매칭

패턴매칭이라고 하면 보통의 함수형 언어들에서 가지고 있는 특징이긴 한데, Erlang의 패턴매칭은 Prolog의 것을 함수형 문법으로 고친 것이라서 통상적인 함수형 언어들 보다도 유연하다는 특징이 있다. 따라서 특정한 자료의 형태를 선언하거나 읽어들이는 작업이 아주 편리하다. 특히 내부 데이터 타입이 아닌 단순 바이너리 데이터를 패턴매칭하는 기능이 있어 프로토콜 개발에 매우 유용하다.

3.3 강력한 내장 기능

Erlang은 통신 인프라를 위한 언어인 만큼 Erlang자체만으로 통신망에서 요구되는 모든 기능들을 수행 할 수 있도록 다양한 내장 기능들을 포함하고 있다. 대표적인 것이 메모리 Key Value 저장소인 ETS[5], ETS의 디스크 저장소인 DETS, 트랜젝션이 지원되는 DBMS인 Mnesia[6], 에릭슨의 인프라 플랫폼인 OTP[7] 등이 있으며, 모두 인프라 구축용으로 검증되어있어 신뢰성이나 성능면에서 높은 수준을 자랑한다.

3.4 장애 허용

본래 인프라 구축을 위한 언어였기 때문에 장애허용 구조를 내장하고 있다는 것도 특징이다. 아이디어 자체는 아주 단순해서 병행 프로세스 가운데 일부를 감시자로 사용해서 오류가 발생한 프로세스를 깨끗하게 정리하고 재시작 시킨다는 것이다. 이때 프로세스는 아주 작은 작업 단위들이라서 하나의 프로세스가 전체 작동의 일부에 불과하므로 부분적인 장애를 무시하고 전체 프로그램은 계속 살아서 돌아가게 된다[8]. 또한 프로세스는 각자 자기만의 힙과 스택을 할당받아서 작동하기 때문에 한 프로세스에서 발생한 오류가 다른 프로세스에 영향을 줄 수 없다. 그래서 Java가 "write once, run everywhere"라면 Erlang은 "write once, run forever"가 특징이라고 말히기도 한다. 실제 Erlang으로 작성된 통신장비 소프트웨어는 가용성 99.9999999%를 찍기도 한다.

4 성능

인터넷 상에 돌아다니는 Erlang의 성능과 관련된 벤치마크들을 보면 함수 vs 함수 기반에서는 연산 속도나 메모리 사용량 등이 상당히 형편없게 나오는 경우가 많다. 여기에는 나름대로의 이유가 있다. 일단 Erlang은 기본적으로 동시성 제어를 위한 언어다. 함수 하나를 가지고 비교하면 느릴 수 밖에 없다. 그 대신 Erlang은 스케줄러를 미친듯이 최적화 하고 있다. 그 덕분에 동시성 제어는 수만 단위를 가볍게 여기며, SMP 시대 이후에는 수백만 단위도 실시간으로 처리한다. 얼랭 스타일로 코드를 작성해서, 여러개의 process로 연산을 쪼개서 MapReduce 처럼 만들면 결과적으로 C보다도 빠른 벤치마크 결과를 얻을 수 있다. 또한 Erlang은 통신장비용 언어기 때문에 메모리를 아끼는 것보다 실시간성의 유지를 중요하게 여긴다. 그래서 돌려야 하는 작업이 메모리를 많이 필요로 한다고 판단되면 그 즉시 비슷한 작업이 또 들어와도 실시간 처리능력을 유지할 수 있도록 메모리를 넉넉하게 퍼먹어 둔다. 애초에 통신장비는 하드웨어 가용 메모리 전부가 통신 애플리케이션용으로 붙어있기 때문에 아낄 필요가 없다. 물론 그렇다고 메모리 효율성이 나쁜건 아니다. 실 작업으로 내려가보면 메모리 사용 자체는 대단히 효율적이다.

5 기타

대다수의 사람들에게 생소한 프로그래밍 언어지만, 병행성 분야에서는 주류언어에 속한다. CouchDB, SimpleDB, Riak 등 NoSQL DB에서 맵리듀스의 구현 혹은 DBMS의 전체 구현을 위해 많이 사용되며, 채팅과 메시징, RabbitMQ, WhatsApp서버, 리그오브레전드 서버, 금융시스템, 게임서버[9]와 같은 분야에 이용된다. 이 중 WhatsApp의 사용 사례가 유명한데, 12코어(24 논리코어) 프로세서, 100GB 메모리의 하드웨어로 실 서비스에서 서버당 200만건 이상의 연결을 받았었고, 최근에는 개별 서버의 하드웨어를 좀더 줄이고 각각 100만개 정도의 연결을 수용하고 있다[10]. 또 다른 프로그래밍 언어들의 메시지 패싱 디자인에 많은 영향을 주는 언어기도 한데, 막상 Erlang과 비슷한 메시지 패싱을 구현했다는 언어치고 Erlang같이 메시지 패싱이 잘 활용되는 언어가 없다(...)[11]

얼랭을 개발한 에릭슨의 경우 SGSN-MME[12] 설비를 얼랭으로 개발한다. 세대별로 다르긴 하지만 LTE에 사용되는 MME의 경우 에릭슨 장비의 세계시장 점유율이 50%를 넘는다. 상업적으로 상당히 크게 성공한 덕분에 에릭슨에서도 얼랭의 장기적인 개량에 꽤 투자를 하고 있다.

다른 언어들 처럼 Erlang도 범용 프로그래밍 언어로 소개 되기는 하지만 디자인과 기능은 본래의 교환기에 요구되었던 네트워크를 통한 데이터의 실시간 병행 처리와 고가용성에 몰빵되어 있다. 다른 부분들은 어느 수준이냐 하면 얼랭의 코어 개발자가 컨퍼런스에서 "우리 그래픽 라이브러리[13]는 썪었음 ㅋ"하고 비웃는 수준이다. 앞으로 개량할 여지가 있긴 하겠지만 현 시점에서는 갈길이 멀다.

얼랭의 타입 시스템은 함수형 언어에서는 비교적 비주류에 속하는 강타입[14]에 동적타입을 따르고 있다.
  1. ↑ 기원이 통신공학에서 유명한 덴마크 수학자인 Agner Krarup Erlang의 이름에서 따온 이름이다.
  2. ↑ 현재와 같은 모습을 가지기 위해서는 거쳐간 과정은 HOPL학회의 History of erlang에 자세히 기록되어 있다. 눈물 없인 볼 수 없다. 요약하면 절차형 언어들이 시도하는 최적화를 시도하는 대신, 동시성 제어를 이용하여 효율성을 올린다는 접근들의 연속이다. 당시 검증을 통과하기 위해 적용해야 했던 이러한 시도들은 Erlang 사용 목적과 장단점이 매우 뚜렷한 언어로서 만들어 주었고, 이 부분은 범용언어로서의 Erlang의 한계라 할 수 있다.
  3. ↑ IT제품 생명 주기의 대다수가 유지보수라는 점을 생각해보면 굉장한 이점이다. 실은 여기 함정이 하나 있는데, 한 명의 Erlang 프로그래머의 퇴사는 여러 명의 프로그래머의 퇴사(+ 재구인/교육 비용)와 동일한 효과를 가져온다는 것.
  4. ↑ 당시 해고된 인원이 2만명이 넘는다.
  5. ↑ Erlang Term Storage
  6. ↑ 본래는 기억상실을 의미하는 Amnesia였는데, DBMS이름으로 부적절한 의미라 생각되어 A를 빼버렸다고 한다. 하지만 A를 뺀다고 적절한 이름이 되는건지는 의문이다. 우선 a-라는 접두어는 반대의 뜻을 나타내는 것이 맞다...
  7. ↑ Open Telecom Platform
  8. ↑ 진짜 무시하는건 아니고 장애를 복구 하는 시스템이 존재한다. 더불어서 sasl 혹은 기타 로그 관련된 모듈를 띄워두면 자동으로 오류 추적결과를 기록 및 보고하게 된다.
  9. ↑ 콜오브듀티의 멀티플레이 서버 등에 쓰인다.
  10. ↑ 2014년 자료 기준 동접자 1억 5천만명을 채팅서버 150대로 수용하고 있다.
  11. ↑ 다른 언어들이 나빠서가 아니고 Erlang이 대단히 극단적인 디자인을 가지고 있기 때문이다.
  12. ↑ 이동 통신망에서 데이터 패킷을 중계하는 설비다.
  13. ↑ wx를 쓴다
  14. ↑ 실수와 정수의 자동 변환이 있으므로 학문적 의미의 강타입은 아니다.