読者です 読者をやめる 読者になる 読者になる

inFablic

Fablic開発者ブログ

Elixir Conf Japan 2017 参加レポート

イベントレポート Elixir Erlang Ruby

Elixir

Elixir Conf Japan 2017

去る2017-04-01に、Elixir Conf Japan 2017に行ってきました。

Ruby界隈でも有名で、Elixir作者のJosé Valimさんが来日されるというだけでもすごいのに、他の発表者が豪華陣営すぎるので、開催が告知されたとき即座に参加を決定しました。

僕は昔Vancouverで2014年のErlang Factory Liteに参加したところその体験が悟りレベルで良さが高かったので、基本的にErlang関係のイベントはErlang書く人と 書かない人 の両方におすすめできると思ってます。今回のイベントはさらにそれどころかElixirなので、これはまさに行くべきで、行ってない人はもったいなかったです。

文責: id:ujihisa ujm

各セッション

発表内容のまとめは他サイトにありそうなので、ここには見聞きして思った僕の感想や、余談を書いていきます。

Opening Keynote by José Valim

南米なのでなんとなく名前Joséの読み方はホセと勝手に思ってたんですが、南米の中でもブラジルだったのでその逆のジョゼの方だったことにこの日はじめて気が付きました。

  • 昔、Ruby on Railsが3.0でthread-safeになるなど、webアプリバックエンドで単なるUNIXプロセス複数使ったparallel化の限界からthreadをも使ったconcurrent化への要求が高まっていた (Amdahl’s lawなどを引き合いに出しつつ)
    • とりあえずメモリ使用量に関しては複数プロセス使っててもそれがforkならwrite barrierで便利にはなった
  • でもthread-safeはあくまで最低限すぎる保証。thread使っても壊れないというだけで、これによって速度向上するとは言ってない (そしてたいてい速度向上してない)
    • 余談ながら、大江戸Ruby会議06の僕の発表は、Vimのthread safetyが話題。そう、Vimはこの最低限の保証すらない
  • JVMとかならこのあたりはずっと進んでるので、JVM上で動かすclojureやscalaは大幅に有利。また、goみたいに独自に別方向から攻めてる例も
  • 一方ErlangというかそのBEAM VMはconcurrentどころじゃなく離散システム含めて他のすべてを圧倒して、大幅に先導してる

→ まちがいなくErlangを採用するのがBest

  • でもErlangだけだとつらい
  • → Elixir!
  • しかもすでに静的型付けをどんどん導入する研究中 (NEW!)
    • この流れがRubyぽい
    • でもRubyよりだいぶ現実的にすみやかに導入できそう
    • すでにErlangレベルでの後付けの静的型チェッカDialyzerもあるわけで、今回それをより厳しくするような感じ

(Erlang) processを使うべきポイント

  • 状態を持たせるとき
  • Concurrentな計算させたいとき
  • failureをisolateしたいとき
  • distributed systemのとき

言い換えるとそれ以外のときはprocess使わないのがよい。 (※UNIX processじゃなくてErlangのアクターとしてのprocessのこと)

雑感

  • Elixirのプロトタイプがダメダメだった、とのJoseさんによる自省の分析が興味深かった
  • “解きたい問題に対して適切でない解法を試みていたため、いくらがんばって諸問題を修正しても、うまくいかなかった” を示す図がめちゃくちゃ良かった
    • 写真とっておけばよかった・・・。これスライド公開されたらここに貼ります (2017-04-04現在、José Valimさんのスライドはインターネットに未公開)

「Phoenix で作るスケーラブルなリアルタイムゲームサーバー」 by hdtkkj

  • 先程はElixir本体の話で、今回は実際にElixirを使うシステムの事例
  • websocketでchannelの双方向通信
    • topic-basedでやってる
  • Erlangが公式にサポートしてるHot code loadが使える
    • ※ただし完全に理解してた場合
    • ゲームはstatefulだし適用例としてはとても適切
    • 著者ujihisa自身、minecraftサーバ運用時にclojureのコードをゲームサーバ稼働したままデプロイするの何度か実装したためだいぶイメージできる
    • 関数の参照が死ぬと全体が死ぬ問題、あるあるすぎる

「Elixir から始める関数型言語」 by tuvistavie

発表資料: http://tuvistavie.com/slides/elixir-fp-intro/

(僕自身Elixirの言語は知ってたのと、普段からScalaやClojure書いてたので、僕個人にとってあまり新規性がなかったから流し聞きしてたのだけど、とてもよく整理して分かりやすく説明していたので、このあたりの経験ない人を連れてきたかったです・・・。)

「Rediscovery of OTP」 by cooldaemon

  • Elixirを全面的に導入するためにCTOになるという事例
  • ElixirとかErlangとかでよくわからないところがあれば時雨堂というコンサル会社で必ず優勝できるという学び
    • ただし後述する理由でRabbitMQ固有の質問は不可能

「Elixir はリアルタイムWeb に強いというのは本当か？」 by mururu

発表資料: https://speakerdeck.com/mururu/elixirkariarutaimuwebniqiang-i-toiufalsehaben-dang-ka

  • Phoenixの実用事例
  • visualixirがかなり便利そうなので、これをVim scriptで実装してVim上でうにょにうょ動くと便利そうだなと @thincaさんを煽るなどしました

visualixir

ランチ休憩 + サイン会

ちょうどいい機会なので、プログラミングElixirを買って、さっそくサインいただいてきました。

「Rubyist |> (^o^) |> Alchemist 〜Elixirの採用からサービス稼動までの記録〜」 by ohrdev

発表資料: https://www.slideshare.net/ohr486/elixirconfjapan2017sessionohr486

  • Railsアプリを部分的にElixirに置き換えた事例の話
  • elixirで内部apiサーバを作成、microservices
  • exq (sidekiqのElixir実装) があるので段階的移行が比較的容易
  • デプロイが難しい (いわゆるいまのimmutable infrastructureの流れにそのままだと乗れない。BEAM自体がそんな感じなので二重の抽象化になる)
  • あえていきなり並行に動くコードを書くのを避ける
  • 古典的なRed/Green/Refactorサイクルを拡張する感じ。この視点、すごく良い

「ニコニコを支えるErlang/Elixir 〜 大規模運用して初めて見えたアレやコレ」 by kojingharang

発表資料: http://niconare.nicovideo.jp/watch/kn2397

  • Erlangのあの密度で56万行はやばいw
    • Javaでいう200~300万行かな
  • うち自動生成されたコードが9万行とか。結局ほとんど人力
  • ニコニコ動画・ニコニコ生放送だけかと思いきや、ドワンゴが持つメディア系のすべてを抽象化したミドルウェアらしい
    • この抽象化が適切だったかどうかの疑問の声がtwitter上で多数
    • これの評価は実際むずかしい

LT

Closing Keynote by Voluntas

発表資料: https://gist.github.com/voluntas/81ab2fe15372c9c67f3e0b12b3f534fa

  • Erlangの強みは 落ちない こと
    • sequentialな速度を犠牲 (GoやNodejsの方が速い)
    • “Erlang/OTP を選択した場合、 90% は Golang で特に問題ないと思う、ただのこり 10 % で使い道がある”
    • 前述のcooldaemonさんの発表にあるように、あまりにも落ちないので、空気のように存在を忘れることができるのはメリット
      • もちろん、だからといってドキュメントがないのは将来秘伝のタレ化しそうで怖い
      • せっかくElixirでさくっと書けるのだから意図的に式年遷宮するのがよいのかもしれない
      • “適当に書いてもなんとなく動く” というメリットが活きてくる
  • “コンテナやmicroservicesに優しくしていく” の進捗に期待

おわりに、雑感

FablicではただちにElixirを使うシーンはいまのところなさそうです。ただ、このあたりの知見は、必要となったときにはすでに知っておかなければ正しい判断ができなくなるわけで、今回カンファレンスに参加した僕以外の人にもどんどん知見を広めていきたいと感じました。

Statefulでかつ落ちてほしくないようなミドルウェアが欲しいときに、ツール選定を行うにあたって、Elixirは間違いなく候補に入ることでしょう。Erlangの基本的な罠について把握した上で、各種テストで比較し、導入を検討していこうと思います。

infablic