| 日時: | 2016-09-21 |
|---|---|
| 作: | @voluntas |
| バージョン: | 1.0.1 |
| url: | https://voluntas.github.io/ |
2016 年 6 月 24 日に行われる BPStudy の発表資料です
この発表では Erlang のソースコードは出てきません
Erlang/OTP の今と今後について、 Erlang/OTP を使っているユーザの視点からお話をします。
Erlang を知らない人向けのお話もします。ディープな Erlang ユーザの皆さんは退屈だと思いますので、その時は寝ててください。
@voluntas です。時雨堂という小さい会社を経営しています。 Erlang を書いてご飯を食べたりしています。
最近はリアルタイムな映像配信としての WebRTC を 2 年くらい追いかけてます。
$ git clone [email protected]:erlang/otp.git $ ag voluntas
やはりこれが一番気になるところでは無いでしょうか。何ができるとかよりもどんなところで使われているの？というのが自分も知りたいです。
細かい話をすると色々あるので、自分が紹介したいヤツだけ紹介することにします。
一番皆さんに身近な部分だと LINE だと思います。 LINE さんはロードバランサーとアプリケーションサーバの間にいるとのことです。詳しい技術的な話は私もしらないので省略します。
ただ、大規模な例としてとてもわかりやすいかと思います。
- Adopting SPDY in Line – Part 1: An Overview « LINE Engineers' Blog
- LINE Corporation | 募集職種一覧
- "Java/C、C++/Scala/Erlang中に一つ以上の言語に対する強い(extensive/strong)の力量および経験"
日本で Erlang の活躍を世に広めたと言っても過言ではないとおもいます。話を聞くとかなり大規模なレベルで Erlang を使用しています。
- なぜErlangにしたのか
- 【ニコニコ事業】大規模コンテンツ配信システム開発エンジニア C++/Erlang（正社員）｜募集職種一覧｜採用情報｜株式会社ドワンゴ
- Erlangでの開発経験が1年以上ある方
Erlang を使用しているときに一番取り上げられますが、日本ではいまいちメジャーではないので難しいです。 WhatsApp は Facebook に買収された LINE のようなサービスと考えてもらえれば良いです。
彼らはコアのシステムを全て Erlang で作っています。ユーザ数は 10 億ユーザを超えています。
個人的に熱いのが LoL というオンラインゲームのチャットシステムに採用された話です。LoL は 5 対 5 に分かれて戦うオンラインのゲームです。
同時接続 7000 万人を支える基盤として採用されています。1 日 2700 万プレイヤー。秒間 11000 メッセージだそうです。
昔はルーティングメッシュと呼ばれていした。簡単に言うと一番前にいるインテリジェンスなルーターです。 リクエストが来たらどの Dyno に送るかどうかを判断している部分です。
知ってる人は知っている、スマートフォンアプリのゲームです。人気もかなりあります。ここを開発している Machine Zone は基盤に Erlang を使っています。
- MZ - Senior Software Engineer, Core Platform
- Experience with writing production-quality software in Erlang OTP, highly scalable & concurrent systems a double plus
Erlang ではなく Elixir の例もせっかくなので。 Pinterest は Python の会社ですが、 Java で書かれたシステムの一部を Elixir で置き換えたようです。
- Introducing new open-source tools for the Elixir community | Pinterest Engineering
- Why Pinterest just open-sourced new tools for the Elixir programming language | VentureBeat | Dev | by Jordan Novet
さて、 Erlang を検討するというのは何を持ってして検討するといいのでしょうか。
Erlang を採用する最大の理由は安定性です。 OS 側のトラブルに巻き込まれたのを含まれない限り私がお手伝いしたサーバのほとんどで大変安定した動作をしています。
私が関わったので、話ができる内容ではユーザ数が最低でも数百万人を支えている認証や課金基盤では 2 年以上、特に障害が無く安定して稼働しています。
Erlang を実際に使っている人達のほとんどが安定性が欲しくて採用しています。
1 秒で 100 万リクエストを 1 つの TCP から送られた場合は処理できません。これは Erlang が軽量プロセスモデルを採用しており、さらに軽量プロセス 1 つの性能限界があるからです。
Erlang を選択した場合のほとんどがミドルウェアの開発になるのですが、上記で書いたように一定以上を超えると性能に限界がきます。残念ながら C/C++ で書かれたミドルウェアに性能は勝てません。
Erlang は一つのプロセスに負荷が集中するような処理は一定以上になると弱くなります。軽量プロセスで裁ける処理はがんばっても秒間 50000 メッセージ前後という認識です。
また暗号処理などの計算量が必要になるものは遅いです。 LINE や WhatsApp でもメッセージ経路が暗号化されていますが、その部分は C/C++ で書かれた TLS 終端を前段に置いています。
貴方が作ろうとしている何かが、計算処理が必要になるのであれば Erlang を採用するのは間違いです。
人に寄ります。ただ私にとって、サーバやミドルウェアを Python で書くよりは遙かに開発がしやすいです。ただウェブアプリを書くのには向いていませんので、ウェブアプリを書く場合は Elixir を検討すべきでしょう。
性能がつらくなってきても Erlang にしがみついている人のほとんどは開発効率や安定性が高いというのを実感しているからというのはあると思います。ただこれは残念ながら個人の感想です。
Erlang は独特な文法のため採用がしづらいと言われますが、慣れだと思います。慣れました。
また、初めての人でもそんなに大変ではありません。 Erlang 自体はとても簡単です。難しいのは綺麗にシステムを設計する部分ですが、これはどの言語を使っても同じじゃ無いでしょうか。
さて、 Erlang を学びたくなった場合どうするのがいいのでしょうか。
日本語で学びたい場合は良い本がでているのでそれを読むのが最適です。
まずはこの二冊を買えば間違いはありません。順番としてはプログラミング Erlang から読み始めていってください。
ただ、 プログラミング Erlang は古いです。それだけ注意してください。ただ Erlang という言語を学ぶのにはとても良いです。プログラミング Erlang を読み終えて、まだ Erlang を学ぶ意欲があれば すごい Erlang ゆかいに学ぼう！ を読みましょう。おなかいっぱいになるはずです。
本は良著が二冊あるので、正直困りません。実際に書き始めたらどうせドキュメントとソースがお友達になります。
Erlang は独特の言語なので学ぶだけで実際に仕事や何かに使う必要が無くても考え方が面白いと思います。
とりあえず学んでみるもとてもよい選択です。
それが Web アプリなら Elixir + Phoenix + Ecto を検討しましょう。 Erlang はウェブアプリを作るのに大変向いていません。できないの？と言われたらできます。ただしお勧めしません。
Elixir は私は残念ながら書いたこと無いのですが、 Erlang VM 上で動く言語ということで Erlang VM の恩恵を受けることは可能です。落ちにくいウェブアプリを作ることができるでしょう。
Web アプリ以外であれば、いくつかのソースを参考にしていくと良いと思います。 RabbitMQ や ejabberd などはよく使われるサーバですし、とても良い教材です。
まずは Erlang の場合はプロセスをどう配置するかという設計が重要になってくるので、既存のプロダクトのソースを読むというのはとても良い選択になります。
Erlang ですが歴史はそこそこ古いです。1986 年に登場しました。生まれてない人もいたりするのではないでしょうか。 OSS になったのは 1998 年です。
Erlang は GitHub 上で開発されています。それもかなり早い段階で GitHub の採用を決めました。また最近は機能追加なども全て GitHub 上でやりとりされ Pull-Request ベースになりました。
バグ一覧も公開されています。 http://bugs.erlang.org/projects/ERL
実は Erlang はついこの間まで EPL という独自のライセンスでした。MPL ライクなライセンスです。しかし最近 APL 2.0 に切り替えられました。
Erlang はエリクソンが開発し保有する言語だったのですが、今はかなり開かれており活発に開発されています。
時代に乗り遅れないための機能を追加したりしつつも、新しいチャレンジもしています。
Erlang のロードマップは年に 2 回ほど Erlang 関連のカンファレンスで発表されます。
安定的なリリースも Erlang の魅力の一つかもしれません。
今年の 6/22 に Erlang/OTP 19 がでました。このリリースはとても大きなリリースです。
ざっくり書いてます
- 暗号周りが大幅に書き換わりました
- 外部接続用の関数が 3~5 倍速くなりました
- 軽量プロセスのメッセージキューのハンドリングが設定できるようになりました
多くの機能が追加されてパフォーマンスも向上しています。また既存の Erlang に対する不満を解決してくれています。
Erlang/OTP 18 で時刻が入り、マップが正式版になり恩恵を受けた人もちらほらいるでしょう。 ただし 19 はそれ以上に大きな効果をもたらしてくれます。性能が課題になっていた部分もなんとかなる部分もあります。
Erlang は安定的なリリースを行ってきています。大きな変更がある場合は RC 版がでます。またユーザ数の割にドキュメントやテストが大変充実しています。
Erlang ユーザはなぜかドキュメントやテストを書く習慣を持っている人が多いです。不思議です。
若い人も居ますが、 50 ~60 代の人も沢山います。自分が一番驚いたのはかなり年配のエンジニアが現役で居続けていることです。日本だとすでに 35 最低年説で引退していないと行けない年齢です。
私が彼らと話した印象は、彼らが Erlang の専門家であることは間違いないのですが、それよりも他の沢山の事の専門家でした。私も Erlang を書いては居ますが、専門が Erlang かと言われるとノーです。 Erlang は私の専門を使ってプロダクトを作るための道具なのです。
彼らは道具としての Erlang を使い続けている熟達者という印象でした。ネットワークの専門家もいれば、広告の専門家もいて、いろいろな専門家の人が Erlang のユーザという印象でした。
基本は Emacs です。最近は VIM も頑張っていますし IDE も頑張っています。正直何でもイイと思います。
貴方が普段使っているのを使えば良いです。
Erlang はビルドツールが不在で基本 Makefile で頑張るというのでしたが rebar というビルドツールがでてから世界が変わりました。
rebar はアップデートして rebar3 になり、いまは Erlang の公式ビルドツールとしてリポジトリも erlang/rebar3 に置いてあります。
基本的には rebar3 を使えば良いのですが、色々問題が出たりもします。そのときは slack や GitHub issues で相談すれば良いと思います。ソースは黒魔術的なのが多いのでツライかもしれません。
大変遠回りをした感じはありますが Elixir のおかげで、 Erlang には公式のパッケージマネージャーが登場しました。
Hex です。これは Elixir の恩恵を Erlang が受けているとても良い例です。
Erlang を採用すると決めた場合に課題となるのはメンテナンスでしょうか。人に依存するために会社がいやがる事はおおいでしょう。最終的には判断をするのは偉い人です。そこはキモに命じておきましょう。
一番良い材料はさっさと Erlang でプロトタイプを作ってしまう事です。これができるのであれば一番です。
それが難しい場合は、貴方の情熱が全てです。
また珍しいパターンもあって会社の方針で Erlang や Elixir を採用するというパターンもあります。この場合一番良いのは Erlang や Elixir に詳しい人にお手伝いを依頼することです。
私自身いくつかの会社の Erlang のお手伝いをしています。お手伝い内容は基本的な書き方から始まり運用、設計方針まで相談を受けられます。宣伝になってしまうかもしれませんが、最初から知っている人がいるというのは大変大きいです。
Erlang で戦うということは Erlang を追いかけるということです。
一番手っ取り早いのが otp/erlang のコミットログと Pull-Request を読む事です。また Erlang メーリングリストの bugs を追いかけるのも良いでしょう。
最近は slack ができたのでそこを見てるだけでもおなかいっぱいになります。
さて、よく言われるのが日本語の情報がないという事ですが、ある一定までは最初の方に紹介した本で十分です。
それ以降は英語を駆使して GitHub などを見て貰う必要があります。公式ドキュメントも翻訳はされていません。英語はある程度はできる前提の言語という認識で良いと思います。
ユーザ数が少ない事もあると思いますが、英語での情報がある前提の世界だと思って頂いて良いです。それがツライ場合は選択しないのが賢明です。
最近はちらちら日本語情報がでていていますし、貴方が日本語の情報発信者になるのも良いでしょう。 Elixir 関連では翻訳も出てきていますし、 Elixir 本の翻訳もオーム社が行っており、夏頃発売する予定です。
Erlang の強さですが、大変落ちにくいというのが一番です。自分はいろいろなシステムを作ってきましたがとにかく落ちにくいです。
5 年以上前に 1 度だけロングラン負荷試験の最中に Erlang VM の GC バグを引いてセグフォで落ちました。これ以外ではメモリーリークのある VM を引いたくらいしかありません。メモリーリークはすぐに VM をアップデートしたら解決しました。
よく言われる何かあったらクラッシュさせればいいと言われますが、確かにそうです。 ただちょっと違うのは 別に正常系だけ書けばいい というわけではありません。
何かあったらクラッシュさせるというのは 想定外のエラーがきたとのためになんでもかんでも try/catch しなくていい というのが正しいです。
想定内範囲のエラーはキッチリ対応すべきです。そしてエラーも丁寧に書くべきでしょう。想定外のエラーが起きたときは Erlang VM が丁寧なクラッシュログを残してくれているのでそれを見ましょう。そして 想定内のエラー としてコードを修正しましょう、そのときにテストを書くのを忘れずに。
Erlang はメッセージパッシングを使うことですべて非同期で処理することができます。つまり別の計量プロセスに対して処理を依頼して、結果が戻ってくるかどうかは依頼したプロセス次第と言うことです。もちろん待つこともできます。
Erlang では基本的に非同期で実装して、同期にできそうなところだけ同期にしていきます。ここが Erlang プログラミングのキモだと私は思っています。
Erlang は早い言語ではありません。ボトルネックが色々あります。そこを解決できるように負荷試験を気軽にできるようにしましょう。
プロファイラから始まり軽量プロセスの情報を取得したりといった Erlang ベタベタなスキルから、負荷試験のノウハウという Erlang が関係ない部分の知識も必要になります。
Erlang にはプロファイラが 3 種類はいっていますし、VM の情報を気軽に取ることができます。
常にボトルネックを見つけられるようにしておくのはとても良い事です。
Erlang を使う場合ほとんどがネットワークサーバの開発になると思います。その場合は EtoE のテストを気軽にできる恩恵を受けるのが良いでしょう。
Erlang のテストでは自分自身をサーバとして起動し、クライアントからの実際のネットワークテストなども簡単にできます。さらにカバレッジも取れます。これらをビルドサーバに組み込み、常に EtoE テストができるようにすることも大事です。
Adopting SPDY in Line – Part 1: An Overview « LINE Engineers' Blog のURLが新しくなってました