When working on projects not using Erlang, the toughest thing is releasing without complete unit tests, integration tests, and stress tests for all APIs.
Erlang projects also need those tests before release.
But a huge plus is updating without service interruption after issues arise. Especially great for socket services needing to maintain session context!
So despite lower computation speed than C++ servers, Erlang can't be beat. And it's not drastically slower - for I/O heavy work differences are small. With excellent multi-core support, Erlang can even outperform servers lacking it.
A paper comparing Go, Erlang, and Akka is a must-read!
Recommendations:
- Use Erlang for socket services maintaining session context.
- For HTTP REST services Erlang isn't critical.
- Despite advantages, Erlang lacks explosive popularity due to difficult syntax and small community. Elixir helps but isn't sufficient yet and feels awkward to existing Erlang devs. Devs new or scared of Erlang can use Elixir.
실전에서 Erlang으로 서버를 만들지 않은 프로젝트를 접했을때,
가장 난감한 점은
"모든 API에 대한 유닛테스트와 전체 서비스에 대한 통합 테스트,그리고 스트레스 테스트를 반드시 통과해야 하지 않고서는 서비스 오픈이 겁난다"이다.
Erlang으로 했을 때에도, 유닛테스트,통합 테스트,스트레스 테스트를 하지 않는 것은 아니다.
Hot Code Reloading
그러나, 오픈후에 문제 상황 발생시에, 곧바로 원인을 파악하고, 서비스를 중단하지 않으면서 업데이트를 할 수 있다는 점은 엄청난 장점이 아닐 수 없다.
Session Context를 유지해야 하는 Socket 기반 서비스에서는 특히 그 장점이 빛이 난다.
Performance
따라서, C++ 서버(Native Binary를 지원하는)에 비해서 떨어지는 Computation 성능에도 Erlang을 선택하지 않을 수 없다.
그렇다고, 특별히 현저하게 성능이 떨어지는 것도 아니다. I/O bound job이 많은 경우에는 차이가 별로 나지 않을 뿐더러, Multi Core Support를 매우 훌륭하게 지원하기 때문에, Multi Core Support를 제대로 지원하지 않은 서버에 비하여 오히려 성능이 매우 우수하다.
Go , Erlang , Akka 를 비교한 논문이 있다. 꼭 읽어보길 바란다.
http://www.dcs.gla.ac.uk/~trinder/papers/sac-18.pdf
Recommendation
* Session Context를 유지해야 하는 Socket 기반 서비스에는 Erlang으로 구현한다.
* 그렇지 않은 http REST 기반 서비스는 Erlang이 아니어도 상관없을 듯 하다.
* 이러한 장점에도 불구하고, Erlang이 폭발적인 인기를 끌고 있지 못하는 이유는, 어려운 문법과 작은 커뮤니티일 것이다. Elixir가 그 단점을 커버하기 시작했지만, 충분하지 않고, 기존의 Erlang 개발자에게는 오히려 불편하다. Ruby 경험자나 Erlang을 처음 접하기 겁나는 개발자는 Elixir로 구현해도 될 듯하다.
댓글 없음:
댓글 쓰기